[FFmpeg-devel] [PATCH] Lost VBR header

Peter Belkner pbelkner at snafu.de
Sun Apr 17 15:36:12 CEST 2011

On 17.04.2011 14:32, Reimar Döffinger wrote:
> On Sun, Apr 17, 2011 at 02:02:56PM +0200, Peter Belkner wrote:
>>     * 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.
> And as far as I can tell if you concatenate two MP3 files with
> -acodec copy you end up with a VBR header in the middle.

If you take this argument serious than you have to check for the VBR 
header and possible skip it in /each/ demuxer for each format/container 
possibly wrapping a MP3 stream, e.g. MKV too. Also you have to introduce 
VBR header calculation into each muxer potentially writing MP3, not only 
the MP3 muxer.

MP3 concatenation is known to be error prone:


Do you think having no VBR header written in /all/ cases, even the most 
comon ones, is better than having a wrong VBR header written only in 
rare cases?

Maybe the MP3 muxer can figure out if it's going to concatenate two MP3s 
and suppresses writing the vbr header in these cases? This would retain 
the current state of affairs. Anyway, I think the MP3 demuxer is the 
wrong place to fix this.

To get filtering out VBR headers from MP3s during stream copy fixed is a 
major reason while I'm here. This makes my R128GAIN 
(http://r128gain.sourceforge.net/ ) pretty useless for a lot of 
potential users:


I really would appreciate if the simple solution I've provided would 
find its way into FFmpeg.


More information about the ffmpeg-devel mailing list