Open sktt opened 3 years ago
After heaps of debugging.
It should be off by 1. At least in some implementations. But not by others. The added byte comes from unsynchronizing, ie removing byte patterns that looks like audio synchronization frames by adding an extra \x00
to it.
It turns out, however, that the spec is not clear on whether tags should be un-unsynced (ie removing that added \x00 byte) before or after parsing the id3 tags.
libid3tag (eg. libmad) for example assumes (just like MP3/Tag) that the idv3 tags are "un-unsynced" before parsing them. Whereas libmpg123 (eg. ffmpeg) appear to assume that they should be parsed "as-is".
Edit:
It seems that the few mp3s with special characters that I checked (russian, korean, chinese) don't set the unsynchronisation flag. So my proposed solution would be disable id3v2_unsync. flac2all
(which sets tags using with lame) for example does not enable unsync as it seems.
If the input flac contains strange multibyte characters it results in the output mp3 to have bad id3v2.3 tags.
Some tag parsers do not care about this.
mediainfo
shows the full tags. butffprobe
won't it stops outputting tags after the first bad tag.How to reproduce?
Make an empty directory for the test input
Find a random flac, eg.
Add the problematic tag
Convert like normal
Check the tags in ffprobe:
ffprobe -v quiet -show_format -print_format ini output-dir/sample1.mp3
title
is missing its last character andartist
is completely missing. The problem seems to be the’
character in the title, which is 3 bytes long.Tags not gone, however:
mediainfo -f --Details=1 output-lol/sample1.mp3 | grep TIT2 --after=10
Here Size=25 seems to be off by 1. This seems to result in some media players showing the correct tags (they don't care about the Size header) for example VLC. Others will instead just render the tags until the faulty frame, for example deadbeef.