After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 42227 - time display problems with variable bitrate
time display problems with variable bitrate
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: [obsolete] Views: Music View
unspecified
Other Linux
: Normal normal
: old
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2000-08-20 16:55 UTC by Bjoern Ganslandt
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Sample VBR MP3 file from Bjoern Ganslandt _lt;bganslan@gmx.net_gt; (595.43 KB, audio/mp3)
2001-09-10 00:37 UTC, Unknown User
Details

Description Bjoern Ganslandt 2001-09-10 00:37:50 UTC
When playing mp3's with variable bitrate (created with Lame) the time keeps on
jumping back and forth



------- Additional Comments From andy@eazel.com 2000-08-20 14:00:20 ----

I'll investigate this further - an outside contributor supposedly made it work 
with variable bit rate a few months ago, but perhaps not in every case.




------- Additional Comments From linuxfan@ionet.net 2000-09-19 12:55:35 ----

Andy,

Your latest changes to the music view don't fix this problem.

Josh



------- Additional Comments From don@eazel.com 2000-12-28 18:04:30 ----

I'm one of the LAME developers actually. ;)  In the LAME 3.8.7 tarball, there is
a nasty bug which can cause the Xing VBR header _not_ to be written to the MP3
file if an ID3 version 2 tag is also being written.  MP3s without the Xing VBR
header (like older MusicMatch VBR files) will exhibit this annoying behavior.

Here's a patch to LAME 3.8.7 (also available on my website at
http://blivet.com/vbr-header-fix.patch) to fix this particular problem:


--- lame3.87/lame.c.orig        Mon Sep 25 17:09:26 2000
+++ lame3.87/lame.c     Tue Nov 28 21:43:14 2000
@@ -653,11 +653,10 @@
   
 
   /* Write id3v2 tag into the bitstream */
-  /* Can not have a id3v2 tag and a Xing VBR header */
+  /* this tag must be before the Xing VBR header */
+  /* does id3v2 and Xing header really work??? */
   if (!gfp->ogg) {
     int ret = id3tag_write_v2(gfp,&gfp->tag_spec);
-    if (ret > 0) 
-      gfp->bWriteVbrTag = 0;
   }
 
   /* Write initial VBR Header to bitstream */


However, before we go down this track of blaming Mark Taylor, the LAME project
leader, for his typo in 3.8.7 ;), I'd like to find out:

1) Do you have any of these bad MP3 files available?
2) Do they exhibit the same behavior in XMMS?

In the meantime, I'm moving this bug to 1.0.1.

(Andy, feel free to re-assign this bug to me. ;)




------- Additional Comments From don@eazel.com 2001-01-02 08:56:13 ----

Created an attachment (id=1101)
Sample VBR MP3 file from Bjoern Ganslandt <bganslan@gmx.net>




------- Additional Comments From don@eazel.com 2001-01-02 08:59:10 ----

Bjoern Ganslandt <bganslan@gmx.net> sent me an email saying:

"I encoded the mp3-files quite a while ago, so it's not the fault of lame
3.8.7. I didn't observe the errors in XMMS, so it seems to be a Nautilus
problem."

To which I replied:

"Thanks for sending me the sample!  I'll attach it to the bug report.

Yep, you appear to have encoded the 37 second file with LAME version 
3.50 at an average bitrate of 130 kbs and without either ID3 version 1
or version 2 tags.  So this couldn't the bug I know about in LAME.
Which means it's a bug in Nautilus because I don't see the problem in 
XMMS either.  Ugh.  We'll look into it.  Thanks again."




------- Bug moved to this database by unknown@bugzilla.gnome.org 2001-09-09 20:37 -------
Comment 1 John Fleck 2002-01-05 04:12:08 UTC
Changing to "old" target milestone for all bugs laying around with no milestone set.
Comment 2 Andrew Sobala 2002-05-10 17:32:30 UTC
Cannot reproduce in nautilus 1.1.15 : appears to be resolved (?)
Comment 3 Vincent Untz 2002-10-31 13:44:45 UTC
Trusting Andrew's comment, I close the bug.