GNOME Bugzilla – Bug 322461
[lame] creates bogus metadata when using variable bitrate
Last modified: 2006-04-06 14:18:32 UTC
Version details: gstreamer-plugins-mp3-0.8.8-0 Distribution/Version: Fedora Core 5 test1 I ran into this using sound-juicer for GUI and the gstreamer pipeline: audio/x-raw-int,rate=44100,channels=2 ! lame name=enc vbr=4 vbr-quality=6 This I assumed would produce the exact same results as ripping with lame directly, using the lame command line flags: lame -V6 --new-vbr However, when comparing the files, there are some differences in the file metadata. Most noticably, the track length in the gstreamer track is wrong and keeps changing during playback. The bittrated is also reported as constant and 32 kbit/s, while the file size, compared with the track encoded by lame directly, indicates that the track is in deed ripped at variable bittrated using the V6 setting. Both files attached.
Files to big for attachment. Gstreamer file here: http://pifler.serveftp.com/sindre/gstreamer/gstreamer.mp3 ripped with pipeline: audio/x-raw-int,rate=44100,channels=2 ! lame name=enc vbr=4 vbr-quality=6 Lame here: http://pifler.serveftp.com/sindre/gstreamer/lame.mp3 Ripped with lame -V6 --vbr-new %w %m
*** Bug 322460 has been marked as a duplicate of this bug. ***
*** Bug 314253 has been marked as a duplicate of this bug. ***
#314253 has more detail on the cause.
*** Bug 171889 has been marked as a duplicate of this bug. ***
The version on this should be changed to 0.10.x, as per my results in Bug 171889.
*** Bug 327906 has been marked as a duplicate of this bug. ***
Not sure apps will properly get the bitrate, but apart from that, the patches from bug #330317 fix this bug.
The xingheader property has now been disabled in the lame encoder element (as it was broken and non-fixable for us anyway), so I guess this bug is obsolete now. The mad mp3 decoder should pick up xingheaders and post appropriate tag messages with the bitrate from the xing header on the bus since gst-plugins-ugly 0.10.2 (gstmad.c, revision 1.152).
I can confirm that this does NOT fix the incorrect VBR bitrate issue with Beep Media Player, Banshee. Can we get this reopened? I've been doing all my ripping in Windows for years because of this bug. Using xingmux with gstreamer-plugins-ugly 0.10.3 and Sound Juicer 2.14.1 allows Beep to read at least the Name/Title/Album information, id3mux does not even get that right (and it is now recommended in the Sound Juicer help file).
Any idea how banshee and bmp get what you call the "VBR bitrate"? (I guess you mean average bitrate of the track). I'm pretty sure grip would get that right if you don't want to reboot to windows to rip a cd. xingmux and id3mux have nothing to do with each other. xingmux adds a xingheader, which is mainly useful to calculate the actual length of a VBR file, id3mux adds id3v2 tags (ie artist, album, title information) to mp3 files. The id3mux recommended in s-j 2.14.1 corresponds to an internal s-j plugin, which will be called tagid3v2mux in official gstreamer releases. And xingmux doesn't known anything about title/album/artist, so it doesn't write anything related to that to an mp3 stream.
See Bug 171889 for a more detailed description of the issue (and may be the better one to reopen). The best explanation I've ever found is from this e-mail: http://mail.gnome.org/archives/gnome-list/2005-March/msg00111.html "I have encountered exactly the same thing using command-line cdparanoia and lame in a pipe (having cdparanoia output to stdout and lame encode from stdin). If I rip a whole wav and run it through lame, the resulting mp3 is OK. Lame being the only common thing, maybe the problem is in it." For the record, I always had exactly the same problem with Grip. I'm assuming the problem is the VBR info needs to be written to the front of the file, but as we're feeding LAME the data through a pipe it can't do that (as it can't calculate the value until the end). This seems to have a fairly thorough (if obtuse) description of the VBR fields Lame uses. It talks about an xing style VBR field: http://gabriel.mp3-tech.org/mp3infotag.html Note that CD Ex (the program I use on windows) uses LAME for on the fly encoding, so it must be possible to get right. This tool: http://www.burnworld.com/software/mp3/mp3tagstudio.htm advertises the ability to fix broken VBR header information. Banshee (using gstreamer) lists the bit rate for both the correct and incorrect VBR files as 0 in the "advanced properties", but says "VBR: yes" for the correct ones and "VBR: no" for the incorrect, as well as being able to calculate the time correctly for the correct files. I can whip out the hex editor when I get a minute if it will help.
I know about those gstlame limitations, and I know that the command-line lame tool gets it right since this is what made me write xingmux. If you have time to figure out which field needs to be present for banshee to figure out the bitrate, that would really help (ie it would make it much easier for me to add this information to xingmux). I guess you can check the output of gst-launch-0.10 -t playbin uri="file:///tmp/good.mp3" and then bad.mp3, and look at the gstreamer code parsing the xing header (probably somewhere in the mad gstreamer plugin) if you want to really figure out what gstreamer is doing.
mmacleod: I think there are different issues here. One is what the lame element produces. This issue has been 'resolved' in that it doesn't (and shouldn't) produce xing headers any longer. For that there will be xingmux in future. What banshee and other GStreamer-based players recognise VBR-wise is a different issue. If you have a file with an xing-header that other non-GStreamer players read fine but GStreamer doesn't read, then please open a new bug against mad so it can be fixed. That is a different issue than the original issue here though, isn't it? Finally, it is possible of course to scan an entire mp3 file at start-up to find out the exact length and average bitrate for VBR files, but so far the decision has been not to do that (as it might be slow if the file isn't local or rather large). This could certainly be implemented conditionally, e.g. when an index is set on mad.
> What banshee and other GStreamer-based players recognise VBR-wise is a > different issue. If you have a file with an xing-header that other > non-GStreamer players read fine but GStreamer doesn't read, then please open a > new bug against mad so it can be fixed. That is a different issue than the > original issue here though, isn't it? The issue continues to be that gstreamer/grip produced via Lame VBR files are not read correctly by _either_ Gstreamer players, Beep 0.x, XMMS, or Winamp, but those produced by CD Ex via Lame are. As I said I've had this problem for a long time, as have others. I'm really not trying to harp on the Gstreamer people (I love it), it's just more that you guys are actually ripping everything apart and looking at it again, and I'd like to see this finally fixed for good. And I got all excited when I saw all the "metadata works now" comments in the related bugs and changelog. I'll try to have a look at the output/code some time in the next couple of weeks. Trying to wrap up my thesis and course work at the moment. My feeling is these other players aren't recalculating the average bitrate on every load, but they could be. I'd settle for players not being permanently convinced the files are 32 kbps CBR, though.