GNOME Bugzilla – Bug 171889
gst-lame: erroneous VBR mp3 files when ripping and encoding on the fly
Last modified: 2006-01-22 15:58:41 UTC
Hi, I used the following pipeline to encode VBR mp3 files with sound juicer: audio/x-raw-int,rate=44100,channels=2 ! lame name=enc vbr=4 preset=1001 However the created mp3 files are erroneous: -If I open them with beep-media-player or XMMS, the length of the tracks displayed in the playlist always "jumps" (Totem also displays wrong times for the tracks) -If I try to view the properties of these mp3s, nautilus hangs -beep-media-player/XMMS/Totem say, that these files are CBR mp3s with 32 kbps -"file" says something like this: bla.mp3: MPEG ADTS, layer III, v1, 32 kBits, 44.1 kHz, JntStereo whereas proper VBR files look like this: blah.mp3: MP3 file with ID3 version 2.3.0 tag According to this [1] post this seems to happen only if one rips and encodes audio tracks on the fly. [1] http://mail.gnome.org/archives/gnome-list/2005-March/msg00111.html
Hi similar situation, GStreamer 0.8.8-1 Ubuntu on Hoary (5.04). My pipeline is: audio/x-raw-int,rate=44100,channels=2 ! lame name=enc vbr=4 vbr-quality=5 I'm seeing weird lengths which are grossly wrong, ~4 min files coming up as ~2mins - ~18mins and anything in between... Totem isn't playing these files properly, nor is my iPod. They are trying to play the length of the file so sometimes cutting songs short and other times playing "silence" or white noise... example output of file 01 - The Hollow.mp3: MPEG ADTS, layer III, v1, 32 kBits, 44.1 kHz, JntStereo which we all know is wrong :(
Ping, is there any change on this? Also has anyone tested with 0.10?
I will test this as soon as Sound Juicer with 0.10 hits Dapper (I'm assuming relatively soon). This problem goes back to when I used grip, however, so I suspect it's a more general problem with LAME. Google turns up scattered reports of it over the years, with no real solutions. The 'on-the-fly' comment from the above reporter is the most logical explanation I've seen suggested yet, as I imagine the file length/bitrate/etc needs to be written to the front of the file, and perhaps LAME isn't being made to go back and do this properly when the data is streamed in. I've never had this problem with CD Ex on Windows, though, which uses LAME.
Just tried this with Sound Juicer 2.13.3 with Gstreamer 10.2, same problem. My pipeline is: audio/x-raw-int,rate=44100,channels=2 ! lame name=enc preset=1001 (preset 1001 is alt-preset-standard in normal lame lingo). Erroneous track length is reported in Beep Media Player and Banshee as before. Beep says it's 32 kbps, Banshee tells me: Encoding: MPEG Version 1 (ISO/IEC 11172-3) || Layer III VBR: No Bitrate: 0 KB/sec (although it's saying that for my other VBR: Yes files as well)
Dupping to bug #322461. Bug #314253 has more info. *** This bug has been marked as a duplicate of 322461 ***