Hi, here are precisions about methods used to get length of an mp3 file :
- if present, an "ID3v2" file "metadata header" may (or may not) contain a
"TLEN" frame, indicating length of the mp3 file in milliseconds
- 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
- 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...
- 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 headers).
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 : http://sourceforge.net/p/exiftool/code/ci/master/tree/lib/Image/ExifTool/MPE... Cheers, Nicolas