GNOME Bugzilla – Bug 127887
[patch] Variable bitrate mp3s displays wrong duration.
Last modified: 2004-12-22 21:47:04 UTC
Description of Problem: Variable bitrate mp3s reports duration much longer than they are. A 4 minutes file is reported as a 4150 minutes file. Steps to reproduce the problem: 1. Make variable bitrate mp3: ("$ lame -v test.wav") 2. Add "test.wav.mp3" to the colection. Actual Results: Wrong (much longer) duration displayed. Plays ok. Expected Results: Correct duration displayed. How often does this happen? Always Additional Information: Using: Rhythmbox 0.6.1 Gstreamer 0.6.3
Please make a test file available. This is supposed to be fixed already.
Created attachment 21793 [details] Variable bitrate mp3 displays too _small_ time
Created attachment 21794 [details] Fixed bitrate displays the correct running time.
The error does not seems occur in small files. And sometimes the displayed time is too _small_. Like in these test files.
Created attachment 21795 [details] Screenshot of the error.
*** Bug 127904 has been marked as a duplicate of this bug. ***
I can confirm the problem with latest cvs and the 2 attached files (I deleted ~/.gnome2/rhythmbox before the test). xmms detects the correct length.
Created attachment 21848 [details] [review] fix Xing header parsing with mpeg 2 streams
Merge fix from xine-lib. We can all thank Thibaut Mattern :)
* commited walters@rhythmbox.org--2003b/rhythmbox--mainline--0.6--patch-345 Thanks!
Reopening, wasn't merged on HEAD (0.7).
Sorry, I'd forgotten to run tla-cvs-sync for the 0.7 branch; done now!
*** Bug 128157 has been marked as a duplicate of this bug. ***
This one's still alive in 0.6.2.
I am still seeing this on .6.3, using both gstreamer and xine. For me, the Mp3s that have problems were encoded with lame with the following arguments: -h -V 2 --add-id3v2 --tl %d --tt %n --ta %a --ty %y --tn %t --tg %g %w %m
Bug still here in 0.6.4 according to the debian bug submitter (bug #224456). I've added it to the Cc of bugzilla bug report because it's more an upstream problem than a debian one. "Even with gstreamer 0.6.4 and rhythmbox 0.6.4, my entire library of 12,000+ MP3s, all of which were encoded with 'lame --alt-preset' (i.e. they're all VBR-encoded), report playing times in the thousands of minutes. I rebuild my library with each new release of Rhythmbox hoping this problem has been fixed, but as of yet it hasn't. Clearly, this bug is still extant. More information available upon request."
Ok, so this bug report is quite confusing, it's mixing mp3s whose length is too short with mp3s whose length is 1000 times too long. These are different issues imo. Worse, the latest comments say "this is not fixed" without saying if they are talking about the length being reported as too short or far too long. I believe #1 was actually fixed by hadess's patch, and #2 is a dupe of 130819. I'm closing this bug now, things should work properly in next rhythmbox release. If you reopen please: * describe exactly how your mp3 length is miscalculated * tell which backend you are using (gstreamer/xine) * tell which version of rhythmbox and gstreamer you are using