[FFmpeg-devel] [PATCH] Lost VBR header
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:
> 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
> 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
> 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
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel