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
