[FFmpeg-devel] [PATCH] Lost VBR header

[Michael Niedermayer]

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
start



[...]
-- 
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>