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

Birkir A. Barkarson birkirb at stoicviking.net
Tue Nov 8 17:46:18 PST 2005


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



More information about the ID3v2 mailing list