[FFmpeg-devel] [PATCH] Lost VBR header

Peter Belkner pbelkner at snafu.de
Mon Apr 25 20:16:57 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)
> 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

The patch below provides exactly that to the MP3 muxer. A XING header 

    * the numer of frames,
    * the size, and
    * a TOC

is generated.

It's based on an idea by Anton Khirnov (restricted to the number of 
frames) found at


The TOC is generated as found in lame's "VbrTag.c".

According to my tests the following reproduces the number of frames, the 
size and the TOC in "c.mp3" from "b.mp3" (except a shift due to shorter 
XING header generated by FFmpeg):

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

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mp3enc_xing.patch
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20110425/411e8f6d/attachment.ksh>

More information about the ffmpeg-devel mailing list