[FFmpeg-user] id3 tags not really removed?

[Moritz Barsnick]

On Wed, May 31, 2017 at 13:10:18 +0200, Cley Faye wrote:
> A shot in the dark here since I didn't have the patience to look at how
> -write_id3v1 work; but if I remember correctly, id3v1 tags are actually
> appended at the end of the mp3 stream in such a way that some older player
> would even play them, causing a small burst of audio at the end of such
> file.
> 
> If ffmpeg really doesn't handle them when reading the stream, it would
> explain why 1- they get copied during stream copy, 2- why older tag would
> still show up first, and maybe also 3- why the new tag would show up after
> initial playing of the file, if the reader actually move from the end of
> the file to detect them after reading.

That was my assumption, and why I suggested using the additional
option. But I have had enough of shooting in the dark. I created a file
with both v1 and v2 ID3 tags:
$ ffmpeg -f lavfi -i anoisesrc -c:a libmp3lame -metadata title='Where is this found?' -write_id3v1 1 -t 1 -ac:a 1 -b:a 24k tmp/id3tagtest.mp3

and converted it in three different ways:
$ ffmpeg -i tmp/id3tagtest.mp3 -metadata title='This is the new tag!' -c copy tmp/id3tagtest_copied_and_new_matadate_no_explicit_id3v1.mp3
$ ffmpeg -i tmp/id3tagtest.mp3 -write_id3v1 1 -metadata title='This is the new tag!' -c copy tmp/id3tagtest_copied_and_new_matadate_explicit_id3v1.mp3
$ ffmpeg -i tmp/id3tagtest.mp3 -map_metadata -1 -c copy tmp/id3tagtest_copied_and_map_metadata_minus_1.mp3

and apparently ffmpeg *always* overwrites or at least deletes the old
ID3v1 tag. None of the three resulting files contained a leak of the
old tag. (Inspected with "strings".) Period, 'nuff said.

So, unless I missed something, it's the player's fault.

Moritz