Re: [core-dev] patches - better usability on other OSes, support for russian mp3 tags

On Aug 9, 2004, at 10:14 AM, Eugene Romanenko wrote:

> Also, in case if Unicode not used, mp3 tags readed with latin-1 
> charset. I believe it incorrect, system default charset must be used, 
> with special cases for countries like Russia, where different OSes use 
> different charsets, but mp3 tags always encoded with Cp1251.

Hi Eugene,

According to http://www.id3.org/id3v2.3.0.html#sec3.3

"If nothing else is said a string is represented as ISO-8859-1 
characters in the range $20 - $FF. Such strings are represented as 
<text string>, or <full text string> if newlines are allowed, in the 
frame descriptions. All Unicode strings use 16-bit unicode 2.0 (ISO/IEC 
10646-1:1993, UCS-2). Unicode strings must begin with the Unicode BOM 
($FF FE or $FE FF) to identify the byte order.

  All numeric strings and URLs are always encoded as ISO-8859-1. 
Terminated strings are terminated with $00 if encoded with ISO-8859-1 
and $00 00 if encoded as unicode. If nothing else is said newline 
character is forbidden. In ISO-8859-1 a new line is represented, when 
allowed, with $0A only. Frames that allow different types of text 
encoding have a text encoding description byte directly after the frame 
size. If ISO-8859-1 is used this byte should be $00, if Unicode is used 
it should be $01. Strings dependent on encoding is represented as <text 
string according to encoding>, or <full text string according to 
encoding> if newlines are allowed. Any empty Unicode strings which are 
NULL-terminated may have the Unicode BOM followed by a Unicode NULL 
($FF FE 00 00 or $FE FF 00 00)."

In short, if the encoding description byte right after frame size is 
$00 the string is supposed to be Latin-1, if $01 Unicode and for 
everything else a custom value (the   values are unfortunately not 
specified by the ID3v2 ppls).

The problem is that many devs ignore the spec or they just don't know 
it better and use the system encoding without setting (at least) the 
encoding description byte.

So what options do we have? Conform the ID3v2 specification, use the 
system encoding instead of Latin-1, figure out the right encoding 
somehow or my favorite at the moment a StringSetting/System Property 
with the encoding for tags where the encoding description byte is $00 
(well, actually !$01).

That way we'd still have the choice to decide between Latin-1 and a 
custom encoding (I'd prefer Latin-1 even if it's a disadvantage for 
me).

A note about the patch. I'd suggest the following addition for the 
MP3DataEditor in particular for the Tag writer: "if (CHARSET is not 
Latin-1) then use Unicode"; so that we don't assist the spreading of 
non ID3v2 conform Tags...

Cheers!
  Roger

_______________________________________________
core-dev mailing list
[email protected]
http://www.limewire.org/mailman/listinfo/core-dev