[PD] get data from mp3 files

Nicolas Lhommet nlhommet at gmail.com
Thu Apr 9 22:58:46 CEST 2015

Hi, here are precisions about methods used to get length of an mp3 file :
1) if present, an "ID3v2" file "metadata header" may (or may not) contain a
"TLEN" frame, indicating length of the mp3 file in milliseconds

2) if Variable Bit Rate encoding (VBR) was used, chances are that the
encoder added a Xing header providing the total number of encoded frames,
which is enough to get duration once samplerate and mpeg version have been
obtained from header of a single mp3 frame.
INDEED : no matter the number of channels or bitrate variation, a frame of
an MPEG Layer III audio file ALWAYS contains 1152 audio samples per channel
(for mpeg1 version, but low quality mpeg2 and 2.5 audio formats have 576
samples per frame), therefore :
total duration = number of mp3 frames * 1152 / samplerate

3) without these global headers (which are not part of MP3 standard), all
mp3 frames of the file must be found and counted. Like when playing it,
each frame header is identified (by a "frame sync" pattern at start of
header) then parsed to determine this frame's bitrate needed to calcultate
its size, in order to get next frame position, and so on...

4) if bitrate stays the same after parsing header of several frames, the
file was probably encoded with constant rate (CBR) so  it is reasonable to
expect that bitrate and frame length will remain unchanged with subsequent
frames. In this case, to save time, the number of frames can be
extrapolated from total audio data size (file size without metadata

Looking at their source code (links below), previously mentionned utilities
appear to proceed in this order to find play duration. But it seems that
exiftool, in absence of a Xing header, will always extrapolate, parsing
only the first mp3 frame to get bitrate (and assuming that it is constant)
but this sole value could be far from actual average bitrate of a VBR
encoded file, resulting in a wrong estimation.

By contrast, soxi (or sox --i), has a more appropriate approach for this
case (and its verbosity can be maxed out with -V6 option to clearly see how
duration is actually measured) :  its parses 25 frames to establish bitrate
situation before extrapolating when constant... or proceeding to full count
of frames otherwise, which is the always the most accurate strategy :

Some dubious MP3s from the interweb may be truncated, with erroneous
metadata headers, or occasionnaly with gaps and ancillary data inserted
between (possibly invalid) audio frames... then real play duration will
correspond to frames actually "validated" and decoded by some mp3 player.
For accuracy, it seems like a good idea to always parse all frames, and in
that sense, Martin was kind of right when he said "there's no way to
determine the length except by playing it" :)

Another command, mp3info (windows binary available), despite the fact it
will only decode the old ID3v1 header to get artist/title metadata (most
files with ID3v2 headers come with v1 headers at end of file anyway), has
nice parameters like -p ("printf"-style custom output format with many
options) and -F to force "full scan", meaning count of all valid mp3 frames
for duration calculation (see "Speed Considerations" in manpage, with
similar explanations :
http://manpages.ubuntu.com/manpages/hardy/man1/mp3info.1.html )

references :
sox : https://github.com/uklauer/sox/blob/master/src/mp3-util.h
exiftool :
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150409/fcc50fe3/attachment-0001.html>

More information about the Pd-list mailing list