[FFmpeg-devel] [PATCH] Lost VBR header

Michael Niedermayer michaelni at gmx.at
Thu Apr 28 21:43:06 CEST 2011

On Mon, Apr 25, 2011 at 08:16:57PM +0200, Peter Belkner wrote:
> 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

>  mp3enc.c |  207 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 204 insertions(+), 3 deletions(-)
> aa51991f05325cb170e63017cff030625d0b5e55  mp3enc_xing.patch

This patch results in differnt output when the resulting mp3 is decoded
also there are error messages and 3456 samples (6*576) missing at the

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20110428/258044c3/attachment.asc>

More information about the ffmpeg-devel mailing list