Re: [Banshee-List] Trouble playing MP3 files ripped with grip

[Christophe Fergeau <teuf gnome org>]

Le mercredi 04 janvier 2006 �0:54 -0500, Aaron Bockover a �it :
> Maybe I could actually test VBR under Lame, but it seems silly for all
> the VBR options to be in lame if it doesn't work.
> 

It's not about VBR working/not working, this is working both with
GStreamer and lame, but it's about generating a usable VBR file. The mp3
file format is a raw stream of encoded music frames, and there is no way
to store metadata about the whole stream in it. In particular, when you
have a VBR file, you can't guess its actual length by just looking at
the mp3 frames. So VBR mp3 encoders generally put a Xing header frame
(called that way probably because Xing were the first to add such a
frame) which contain metadata giving in particular the length of the
stream.

The Xing VBR header is a dummy mp3 frame that comes first in the mp3
stream (after the id3v2 tag), but it can only be written after encoding
the full stream (for things like average bitrate, seek tables, ...). 

And from what I gather, Nico complained because grip writes this header
properly, while GStreamer doesn't (and that's also why I'm still using
grip to rip my CDs instead of using sound-juicer for example).

> How does VBR work under Grip though. Grip just uses command-line
> versions of encoders, right? I was assuming a command-line lame was
> being used, and if there was going to be an issue with VBR at all with
> lame, it was going to be in the gstreamer plugin, not in lame itself.
> Worth looking into.
> 

The fonctions in lame which writes this header are PutLameVBR and
PutVbrTag in libmp3lame/VbrTag.c, and they both take a FILE * argument
which they use to write the header at the appropriate place. A GStreamer
plug-in can't use those functions since it only handles in-memory
buffers, and that's why it's working fine with the command-line lame
binary.

To make GStreamer properly write this header, one first needs to tweak
lame API to add a public function which writes the Xing Header to an
memory buffer, and then change the existing libmp3lame functions to use
that new helper function. That's why I said there were issues with lame
which prevent GStreamer from writing this header (the information going
in this header require intimate knowledge of what went on during the
encoding process, so it would probably tricky for gstreamer to generate
it by itself).

Hope that helps,

Christophe

> --Aaron
> 
> 
> 
> On Wed, 2006-01-04 at 10:29 +0100, Christophe Fergeau wrote:
> > Le mardi 03 janvier 2006 �3:19 +0100, Nico Kaiser a �it :
> > 
> > > 
> > > Great! I did not knew I can change this pipeline for Banshee. I'll
> > > have a look at that. When I once used this for Sound Juicer it created
> > > VBR files without VBR header, so the length was not displayed
> > > correctly.
> > 
> > As far as I know, gstreamer lame element can't write the Xing VBR header
> > properly (ie with all the info about the real length of the encoded
> > file), and I couldn't find an appropriate API in liblame to get the
> > gstreamer lame element to write this header properly :-/ 
> > 
> > Christophe
> > 
> > _______________________________________________
> > Banshee-list mailing list
> > Banshee-list gnome org
> > http://mail.gnome.org/mailman/listinfo/banshee-list
>