[FFmpeg-devel] [PATCH] Lost VBR header

[Peter Belkner]

Hi,

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 
containing

    * 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

    http://patches.ffmpeg.org/patch/1891/

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

Peter
-------------- 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>