[FFmpeg-devel] [PATCH] Lost VBR header

Peter Belkner pbelkner at snafu.de
Sun Apr 17 14:02:56 CEST 2011

On 16.04.2011 16:36, Michael Niedermayer wrote:
> On Fri, Apr 15, 2011 at 12:19:32PM +0200, Peter Belkner wrote:
>> Hi,
>> FFmpeg is known for eating up the VBR header of MP3 files in case of
>> stream copy as e.g.
>>     ffmpeg -i a.mp3 -acodec copy -y b.mp3
>> The patch fixes this provided the "-acodec" switch is given in front of
>> the "-i" switch:
>>     ffmpeg -acode copy -i a.mp3 -y b.mp3
>> Apart from this subtility the patch should improve "libavformat.a" in
>> order that third party client code may copy MP3s without losing the VBR
>> header (as. e.g. my R128GAIN, see below).
>> I really would apreciate if you could apply the patch or provide an
>> equivalent solution.
> If the muxer simply generates a vbr header which should be quite
> trivial for it to do (just counting packets and their sizes for
> duration and buikding a simple index too)

Apart that there's something I like with this idea I disagree:

    * I consider it close to impossible to generate a VBR header from
      encoded MP3 frames. As far as I can see the lame header contains
      information like replay gain and peak value wich is not accessible
      without decoding the frame.
    * Even if the VBR header logical is metadata (and from that point of
      view seem to belong to the container/format) it technical belongs
      to the byte stream. If I request a tool to binary copy the byte
      stream I expect the byte stream to remain untouched. That's
      exactly what third party tools do:

        lame -V2 a.wav a.mp3
        mkvmerge a.mp3 -o a.mkv
        mkvextract tracks a.mkv 1:b.mp3

    A binary diff shows that a.mp3 and b.mp3 are indeed identical:

        diff --binary a.mp3 b.mp3

    * That's what I expect from FFmpeg too (at least in an ideal world)
      and /not/ that implicitely a (possibly different) VBR header is

        lame -V2 a.wav a.mp3
        ffmpeg -i a.mp3 -acodec copy -y a.mkv
        ffmpeg -i a.mkv -acodec copy -y b.mp3

    * The easyist way to come close to it is to let the MP3 demuxer seek
      back after having tried to read the VBR header not only if not
      found but /always/. In case of FFmpeg generated MP3s this will be
      the case anyway, because up to now FFmpeg /never/ writes a VBR
      header (which I consider a long standing seriuos bug).
    * As a better way to skip the VBR header seems to me to let it the
      MP3 decoder do. That's not only the place where it belongs to from
      a theoretical point of view (see above), but also MP3 streams
      coming from other formats than MP3 (as e.g. MKV, generated using
      lame/mkvmerge as above) will profit from it.

The new patch (complete rewrite, see below) implements that.

> then
> not only would it be unneeded to preserve on stream copy but it would
> be created even if the source file did not had one to begin with
> [...]


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lost-vbr-header-v2.patch
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20110417/f60e8a5f/attachment.ksh>

More information about the ffmpeg-devel mailing list