Version: (using KDE Devel) Installed from: Compiled sources Compiler: gcc 3.2.3 OS: Linux n the file mpegheader.cpp line 249 of taglib-1.4 the calculation of the frame length is wrong. At this time it is implemented as follows: if(d->layer == 1) d->frameLength = 24000 * 2 * d->bitrate / d->sampleRate + int(d->isPadded); else d->frameLength = 72000 * d->bitrate / d->sampleRate + int(d->isPadded); This must be replaced by: if(d->layer == 1) d->frameLength = 24000 * 2 * d->bitrate / d->sampleRate + (int(d->isPadded) * 4); else d->frameLength = 72000 * 2 * d->bitrate / d->sampleRate + int(d->isPadded); See http://www.dv.co.yu/mpgscript/mpeghdr.htm section 'How to calculate frame length' for details.
*** Bug 130626 has been marked as a duplicate of this bug. ***
Well, to be accurate with the document (and other mp3 files that I checked), it should be: if(d->layer == 1) d->frameLength = (12000 * d->bitrate / d->sampleRate + int(d->isPadded)) * 4; else d->frameLength = 144000 * d->bitrate / d->sampleRate + int(d->isPadded);
*** Bug 135459 has been marked as a duplicate of this bug. ***
Forgot to close this one the other day.
I dont see how this is closed ? I see no change in svn trunk.
Oops. I had too many windows open and marked the wrong one closed.
Haha :-). Probably you need a coffee break ;-). (To mention about the patch in https://bugs.kde.org/show_bug.cgi?id=135459) BTW, using "lame" as frame of reference (since most mpeg files in OSS world are lame encoded), the fix should be in both mpegproperties.cpp and mpegheader.cpp. Check the patch https://bugs.kde.org/attachment.cgi?id=18092&action=view for a proposed fix.
Did this fix ever make it into trunk? I believe several bugs are waiting on the fix: A KDE Bug: http://bugs.kde.org/show_bug.cgi?id=128388 and a Kubuntu bug: https://launchpad.net/ubuntu/+source/amarok/+bug/63851 Please consider including this fix in the next release. Thanks for your hard work!
did some investigations and wrote a small program to find out why VBR mp3 files are still geting miscalculated. Keep in mind that TagLib has been compiled with --enable-debug *Some of my files have invalid headers or invalid sample rates. This must be wrong. Otherwise XMMS or Realplayer would not be able to calculate the songlength. Lines 216 to 231 in mpegheader.cpp are responsible for that. I do not know if a header/frame can have a sample reate of 0. * To estimate the duration of VBR files, you have to know the average bitrate of the whole file. It often differs a lot from the bitrate of the first frame, because the lowest bitrate available is used for silence in music titles (especially at the beginning). To get this average bitrate, you must go through all the frames in the file and calculate it, by summarizing the bitrates of each frame and dividing it through the number of frames. Because this isn't a good practice (very slow), there exists additional VBR headers within the data section of the first frame (XING header). * TagLib looks for a XING header in order to calcuate the the song length. Unfortunately a XING header is not mandatory in VBR files. If it is missing a VBR file is treated as a CBR file which is wrong. In other words: If a XING header is found the file is VBR encoded. Otherwise it can be a CBR or a VBR file. To dedect the song length correct for both cases you must go through all the frames in the file and summarize the bitrates. Lines 206 to 216 in mpegproperties.cpp must be changed Please fix the bug as soons as possible.
*** This bug has been marked as a duplicate of 130185 ***
Did the proposed patch/fix from https://bugs.kde.org/attachment.cgi?id=18092&action=view make it into the SVN trunk? It still seems to be incorrect in the source I downloaded about a week ago.