It used to be clear in my mind - replace all FFE? and FFF? with FF00E? and FF00F?, and if any replacements have been made then flag the tag as needing deunsynchronization, and replace all FF00 with FF0000. Simple, right?
Investigating some reports of APICs written by getID3() that were not readable by other programs (such as iTunes) I found something strange - all the other tag-writing programs I tried ignore unsynchronization completely and say no deunsynchronization is needed because the data is written as-is (not unsynchronized). That is ID3v2-legal, at the expense of breaking non-ID3v2-aware mp3 decoders. I think it may stem from some ambiguity in the ID3v2.3 specs:
QUOTE
The only purpose of the 'unsynchronisation scheme' is to make the ID3v2 tag as compatible as possible with existing software. There is no use in 'unsynchronising' tags if the file is only to be processed by new software. Unsynchronisation may only be made with MPEG 2 layer I, II and III and MPEG 2.5 files.
To confuse things further, the same passage in ID3v2.4 has changed to:QUOTE
Unsynchronisation is only useful with tags in MPEG 1/2 layer I, II and III, MPEG 2.5 and AAC files.
So while writing non-unsynchronized tags is not ID3v2-illegal, the fact that all the software I've tried can't read unsynchronized binary data puzzles me - are they all bad programmers or did I miss something obvious?
