Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

[Andreas Cadhalpun]

Hi,

On 19.12.2015 23:55, Christoph Anton Mitterer wrote:
> On Sat, 2015-12-19 at 23:24 +0100, Andreas Cadhalpun wrote:
>> Now I'm a bit skeptical about "LAME adding some special tags".
> IIRC, the LAME tag isn't actually an ID3 tag, but padded in some other
> parts of the MP3 header which aren't used.
> http://gabriel.mp3-tech.org/mp3infotag.html
> http://wiki.hydrogenaud.io/index.php?title=LAME#VBR_header_and_LAME_tag
> http://libzplay.sourceforge.net/LAMETAG.html

Thanks for this clarification. I was indeed confused by the ID3 tags
mentioned in the initial report.

> What I would assume that ffmpeg does, is, that it simply drops or
> somehow mangles up the LAMEtag,... or actually modifies the audio
> stream so that it doesn't fit to the LAMEtag anymore.

Indeed, FFmpeg parses the XING/LAME header when demuxing and then
writes a new one when muxing.

On 20.12.2015 06:52, Peter Belkner wrote:
> AFAIK it's the so called LAME or XING header.
> I myself was adding the first version of it to FFmpeg some time ago

Oh cool! What a coincidence!

> but unfortunately not based on my proposal (just copy it) but the way
> the FFmpeg team wants to have it. Meanwhile it's changed anyway.

Well, simply copying would have its problems, e.g. if it's actually
transcoded, the copied header would most likely be quite wrong...

On the other hand, parsing the header has its own problems, as this
bug shows: While the demuxer reads the correct gapless values from
the XING/LAME header, they are never propagated to the muxer and
not written to the output.

I've hacked together a patch[1] that makes this work, but don't get too
excited: It can't be committed as is, because it uses private
libavformat fields outside of libavformat.

Best regards,
Andreas


1: https://ffmpeg.org/pipermail/ffmpeg-devel/2015-December/185657.html