[ID3 Dev] Non-destructive Improvements to ID3v23

[Paul Taylor]

The following features of ID3v24 could be used in ID3v23 without causing 
much of a problem, Im proposing that we should document ID3 V23.1 with 
these additions. At the moment developers and users  are a stuck with 
the common consensus being that applications should still use ID3v23 
rather than ID3v24, but use of ID3v23 makes certain things more 
difficult then they would be if using ID3v24.

1. All text information frames supports multiple strings, stored as a 
null separated list, where null is represented by the termination code 
for the charater encoding

This would allow things like multiple genres, and apps that didnt 
understand multiple values would still continue to read just the first 
value.

2.  Frames that allow different types of text encoding contains a 
textencoding description byte. Possible encodings:

     $00   ISO-8859-1 [ISO-8859-1]. Terminated with $00.
     $01   UTF-16 [UTF-16] encoded Unicode [UNICODE] with BOM. All
           strings in the same frame SHALL have the same byteorder.
           Terminated with $00 00.
     $02   UTF-16BE [UTF-16] encoded Unicode [UNICODE] without BOM.
           Terminated with $00 00.
     $03   UTF-8 [UTF-8] encoded Unicode [UNICODE]. Terminated with $00.

This would allow UTF8 to be used, which is much less problematic for 
applications, there is no BOM to consider, its more space efficient, and 
even apps that cannot decode the UTF8 will display a better 
approximation of the right value than if they cannot read UTF16.


Paul


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