[ID3 Dev] Which byte order should be used when using UTF16 BOM with ID3v23

[Paul Taylor]

Hi Mathias
Mathias Kunter wrote:
> Yes, unsynchronized tags aren't supported very well. However, de facto 
> all software and hardware mp3 players support ID3 version 2 tags 
> today, at least for skipping them if they're present within an mp3 
> file. It therefore shouldn't often be nescessary to unsynchronize an 
> ID3 tag at all.
>
If you have an APIC frame its very likely to have bytes that fall foul 
of the unsynchronization schema , and if you don't do Unsychronization 
then that image WILL NOT display correctly in iTunes. So this is one 
example where unsysnchronization is needed for newer software not for 
the music to play okay, but for the metadata to display okay.
> If you need to ensure compatibility with (old) software or hardware 
> mp3 implementations which don't support ID3 version 2 tags and 
> therefore actually scan the tag for a mp3 synchronization pattern, I 
> would avoid using the 0xFF 0xFE byte order mark. You then may don't 
> use any byte order mark at all and encode the string as big endian (as 
> specified by the unicode standard), or explicitely use the big endian 
> 0xFE 0xFF byte order mark - most applications which support UTF-16 
> should also be able to actually decode a big endian string!
Ok I'll take another look at BE ( I thought it caused problems for 
WIndows but perhaps my diagnosis was wrong) , but I don't think you can 
just drop the BOM thats breaking the ID3 standard

>
> Mathias K.
Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org