[ID3 Dev] Worst cases of "ID3 offenders"?

[Birkir A. Barkarson]

Exactly!

Since the standard (2.3) specificies only ISO8859-1 and Unicode as valid 
character sets then all non ISO8859-1 text SHOULD be converted to 
unicode and stored as such.

How about dropping ISO8859-1 all together in the next version since so 
many libraries use windows ANSI instead of ISO8859-1.

BAB

Robert Manson wrote:
>>I often work with non english character sets so it's a big issue to get
> 
> 
>>them displayed correctly.  I noted some ID3 editors write any character
> 
> 
>>sets to the tags, spoofing them as ISO8859-1, usually opting for the 
>>system default character set.  Others will break unicode tags if they 
>>contain non english characters.
> 
> 
> ID3 tag libraries should not write text encoded in ISO8859-1 due to the
> fact that so many files have been tagged as being IS08859-1 when in fact
> the text was encoded in whatever the windows "ANSI" code page was.  Try
> converting shift-jis to iso latin 1 and see what happens.
> 
> -----Original Message-----
> From: Birkir A. Barkarson [mailto:birkirb at stoicviking.net] 
> Sent: Tuesday, November 08, 2005 5:46 PM
> To: id3v2 at id3.org
> Subject: Re: [ID3 Dev] Worst cases of "ID3 offenders"?
> 
> I made these notes a few weeks back when working on a ID3 library.
> 
> iTunes
> 	Generally will play any MP3 even if it fails to parse the tag.
> 
> Windows Media Player
> 	Does not seem to support extended headers.
> 	Does not seem to support unsynchronization.
> 	Very sensitive to ill formatted tags and won't play an MP3 if
> such a 
> tag is detected.
> 
> Quicktime Player
> 	Similar to iTunes but doesn't correctly display unicode
> characters.
> 
> VLC Media Player
> 	Sensitive to ill formatted tags and will crash with a memory
> read error.
> 
> WinAmp 5 Lite
> 	General compatability, but will not display unicode characters
> in 
> default mode.
> 
> 
> I often work with non english character sets so it's a big issue to get 
> them displayed correctly.  I noted some ID3 editors write any character 
> sets to the tags, spoofing them as ISO8859-1, usually opting for the 
> system default character set.  Others will break unicode tags if they 
> contain non english characters.
> 
> BAB
> 
> Mitchell S. Honnert wrote:
> 
>>In testing out my ID3 tag library, I've come across dozens of cases of
> 
> 
>>mangled v2.3 tags.  If there's some way that a tag can be screwed up, 
>>I've probably seen it.  I've done my best to have my lib gracefully 
>>handle these exceptions, but they're frustrating none-the-less.  It's 
>>not so bad when the offending file looks like it's just the victim of 
>>simple file corruption, but when it's obvious that the author of the 
>>app/lib/encoder that wrote the frame decided to just reformat a
> 
> standard 
> 
>>frame or make up their own frame, I really cringe.
>>
>>
>>
>>What's even more frustrating it to get a bug report from a user of my 
>>library only to have it turn out that it's one of these renegade 
>>frames.  I've posted the common offenders I know about to my library's
> 
> 
>>page, but I'm curious to see if any of you know of any more.  Here are
> 
> 
>>the bigger ones I know about.
>>
>>
>>
>>- WinAmp will record apparently gibberish bytes in the Language field
> 
> of 
> 
>>the Comments (COMM) frame.  I don't see any pattern to the bytes, so
> 
> I'm 
> 
>>guessing that it's just some uninitialized variable that's getting 
>>written the Language bytes.
>>
>>
>>
>>- WinAmp ignores the Description field of the Comments (COMM) frame.
> 
> It 
> 
>>displays whichever COMM frame happens to be read last.  (So your 
>>Comments frame written in another app may "disappear" in WinAmp.)
>>
>>
>>
>>- iTunes adds an extra nullchar to the end of the Comments frame.
>>
>>
>>
>>- iTunes uses a non-standard frame (TCMP) to record the "Part of a 
>>compilation" flag.
>>
>>
>>
>>- Some app/lib/encoder adds a non-standard NCON frame to the ID3 v2.3 
>>tag. I've seen the errant frame hundreds of times, but I've never been
> 
> 
>>able to track down its source. (Man, I wish I could find the culprit
> 
> who 
> 
>>is writing NCON frames.  Gah!)
>>
>>
>>
>>
>>
>>
>>So, does anyone know of any other popular applications, libraries, or 
>>encoders that write non-standard, corrupted ID3 tags?
>>
>>
>>
>>(Part of me just wanted to vent about applications that break the 
>>standard I work so hard to adhere to, but I do still think it would
> 
> help 
> 
>>reduce some of the support requests I get or at least lessen the 
>>perception of people that use my lib that it's broken when it's really
> 
> 
>>the tag that's broken.)
>>
>>
>>
>>Thanks,
>>
>>
>>
>>Mitchell S. Honnert
>>
>>UltraID3Lib - http://home.fuse.net/honnert/hundred/?UltraID3Lib
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
>>For additional commands, e-mail: id3v2-help at id3.org
>>
>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
> 
> 
> 

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