[FFmpeg-devel] [PATCH] Lost VBR header
pbelkner at snafu.de
Sun Apr 17 14:02:56 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)
Apart that there's something I like with this idea I disagree:
* I consider it close to impossible to generate a VBR header from
encoded MP3 frames. As far as I can see the lame header contains
information like replay gain and peak value wich is not accessible
without decoding the frame.
* Even if the VBR header logical is metadata (and from that point of
view seem to belong to the container/format) it technical belongs
to the byte stream. If I request a tool to binary copy the byte
stream I expect the byte stream to remain untouched. That's
exactly what third party tools do:
lame -V2 a.wav a.mp3
mkvmerge a.mp3 -o a.mkv
mkvextract tracks a.mkv 1:b.mp3
A binary diff shows that a.mp3 and b.mp3 are indeed identical:
diff --binary a.mp3 b.mp3
* That's what I expect from FFmpeg too (at least in an ideal world)
and /not/ that implicitely a (possibly different) VBR header is
lame -V2 a.wav a.mp3
ffmpeg -i a.mp3 -acodec copy -y a.mkv
ffmpeg -i a.mkv -acodec copy -y b.mp3
* The easyist way to come close to it is to let the MP3 demuxer seek
back after having tried to read the VBR header not only if not
found but /always/. In case of FFmpeg generated MP3s this will be
the case anyway, because up to now FFmpeg /never/ writes a VBR
header (which I consider a long standing seriuos bug).
* As a better way to skip the VBR header seems to me to let it the
MP3 decoder do. That's not only the place where it belongs to from
a theoretical point of view (see above), but also MP3 streams
coming from other formats than MP3 (as e.g. MKV, generated using
lame/mkvmerge as above) will profit from it.
The new patch (complete rewrite, see below) implements that.
> 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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the ffmpeg-devel