[FFmpeg-devel] [PATCH] Lost VBR header
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:
>> 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)
> 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
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...
More information about the ffmpeg-devel