[gstreamer-bugs] [Bug 322461] [lame] creates bogus metadata when using variable bitrate

[GStreamer (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=322461
 GStreamer | gst-plugins-ugly | Ver: HEAD CVS





------- Comment #12 from mmacleod at ieee.org  2006-04-06 13:12 UTC -------
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.


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.