2017-05-31 12:37 GMT+02:00 Rodolfo Medina <[email protected]>:
> Further tests show that changes in tags are actually detected by the > reader but > with a delay: in a first moment they are not, then I `play' again with tags > using ffmpeg and then the reader finally reads them... > 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. What I'd suggest first is to try transcoding mp3 to mp3 instead of using stream copy, just to make sure this actually destroy the existing id3v1 tags. If it does, then ffmpeg most likely just ignore these tag when reading, making any attempt to "just" modify them kinda futile when copying. (also, on your output file, you can open the file with some form of text editor and jump at the end of the file, to check if multiple TAG section are present. They'll be mostly in plain text. _______________________________________________ ffmpeg-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
