[ID3 Dev] Non-destructive Improvements to ID3v23

Paul Taylor paul_t100 at fastmail.fm
Mon Apr 12 08:26:09 PDT 2010

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 

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.


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

More information about the ID3v2 mailing list