KDE and Amarok - Song length displayed incorrectly

Am I correct in saying this bug only affects VBR files?

It sounds like this can either be fixed by building a SVN snapshot of taglib or wait for a new release, since the bug has been fixed in SVN. Which would be better?

There is still the bug in xine-lib with miscalculating the length of the files though.

Hello Andrew,

thank you for your fast reply. The Amarok team hasn't replied to my email for over 4 month now.

I have checked my stream ripper recorded files. The metadata in the KDE file dialog lets me assume a VBR encoded file. But XMMS displays a constant bitrate at any time. So I do not know what is true. I could offer you a file to find this out.

The up comming (K)Unbuntu 6.10 is indented to be a version with brand new features unlike Dapper is. I have not tested if the SVN version works. It was a comment of woman who tried that successfully. Assuming the SVN version
works, there should be no reason why not using it. There has not been realeased a new version for over 4 month now which fixes the bug.

Of course, there is still the xine-engine issue. I going to send a bug report
to the xine development team by the end of this week.

Now that edgy is out, would you mind testing to see if this bug is still in effect? Thanks.

The bug is still there. My Edgy is up-to-date.

I also have this problem with mono vbr mp3 on xubutu 6.10, track lengths are much shorter than they should be. A taglib built from svn produces the correct track length.

This is a problem for people that use amarok as a podcast and sync their library with a player like an ipod. Ipods use a database on the player and amarok inserts the wrong time into the database. The ipod then stops playing the file at the much shorter time in the database instead of playing the whole track. It appears quite a few podcasts use mono vbr mp3s.

http://bugs.kde.org/show_bug.cgi?id=130625#c8

I sent this further upstream with a request to put the patch into trunk, so it can make its way into Ubuntu repositories after the next taglib release. Until that happens, it appears the only fix will be to build taglib from source and include the patch mentioned ( https://bugs.kde.org/attachment.cgi?id=18092&action=view )

I can confirm the iPod problems from David Dent. Many VBR songs do not work.

But now my question:
I try to compile taglib 1.4 from source. The patches are included:
How always I do

./configure --prefix=/usr
make
make install

Amarok still displays song lengths incorrectly.
Maybe I compile in a wrong way

I also tried make uninstall to make sure the old version is complelty deleted. But a make install has no effect in Amarok later on.

What's wrong. Could someone provide a *.deb?

Ignore my comment above. Taglib was installed properly.

I 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

I hope the Taglib Team can fix that ugly bug ASAP.

During the last weeks I put many efforts into hacking taglib.
I am happy to announce a taglib-1.4 hack release for that issue.

All MP3 VBR files should now have a correct song length, thus making it possible to use Amarok as an Ipod synchronizing tool.

Currently Amarok complies with taglib 1.4. My hack is binary compatible to version 1.4. Amarok does not need to be recompiled.

You can find my hack attached to this comment or on http://www.rafreider.de/taglib-1.4-vbr-hack.tar.gz

Workaround:

Add XING headers to the files. This can be done with the <a href="http://kde-apps.org/content/show.php?content=31539">mp3fix / mp3fixer</a> utility which will run nicely as a script out of Amarok.

Tobias: I have archives of the Amarok mailing list going back two years and I have no record of an email from you to the list, which is probably why you never got a reply.

Anyways, as has already been discussed here, this is a TagLib bug, not an Amarok bug. There are reasons that it wasn't fixed before, one of which is that it takes an order of magnitude (or several) longer to calculate the correct length of a VBR file without a Xing header than with one -- and you'll incur this penalty every time the file is scanned or read. So really, the best answer by far is to pop a Xing header onto your file (in your case, once it's finished being ripped from a stream).

That being said, Scott Wheeler is currently in bugfixing mode (perhaps for an upcoming release?) and before he releases (or just when he gets the time) he likes to go and close all open bugs. The time it takes him to do that usually relates to the complexity of the patch and how long it takes him to verify correct functionality. http://bugs.kde.org/show_bug.cgi?id=130185 is still open so I guess he hasn't gotten to that yet.

So the best answer that anyone can give you right now is: We don't know when TagLib 1.5 will be released, but chances are this problem will be fixed, either through your patch or something similar, before then.

sending to taglib, then.

This bug has since been fixed.

Strange, I still have this problem with Amarok 2.3.1 and libtag1c2a 1.6.3

I still see almost all the track lengths as 0:00 in the playlist view, and some other, on another hand, are strangely long (like more than 2 hours instead a couple of minutes)
But when I play the song, the progress bar shows the correct time.

Am I the only one experiencing this ?

(I installed Amarok from the PPA, but the taglib is the default one shipped with Lucid)