Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

pudge (1)

pudge
  (email not shown publicly)
http://pudge.net/
AOL IM: Crimethnk (Add Buddy, Send Message)

I run this joint, see?

Journal of pudge (1)

Wednesday February 12, 2003
09:58 PM

Stupid iTunes

[ #10555 ]
I have been getting a lot of complaints about ID3v2 tags of certain MP3s not being able to be read by MP3::Info. In pretty much every case, the file was written by iTunes. It turns out that iTunes is saving comments in a tag "COM ". My regex was looking for tags matching /^[A-Z0-9]{4}$/. Because, that is what, you know, EVERY TAG NAME MATCHES. ID3v2.3.0 and ID3v2.4.0 specify that the comment field is "COMM", not "COM ". I guess they did this so their own comments wouldn't interfere with the user's comments, or something; you can have multiple comments fields. But that space broke MP3::Info. And it is certainly broken:

The frame ID is made out of the characters capital A-Z and 0-9. Identifiers beginning with "X", "Y" and "Z" are for experimental frames and free for everyone to use, without the need to set the experimental bit in the tag header. Bear in mind that someone else might have used the same identifier as you. All other identifiers are either used or reserved for future use.

-- ID3 tag version 2.4.0 - Main Structure: 4. ID3v2 frame overview

So 1. it must not have a space there and 2. it must begin with X, Y, or Z if it is different from the standard set of frame IDs.

Oh well, I tracked it down, all better. Will upload sometime soon (more fixes to make).

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • iTunes doesn't store all comments in the 'COM ' tag. It stores textual comments (ie the ones edited via the command-I tag inspector) in a proper 'COMM' header. What it does store in 'COM ' is the CDDB2 discid.

    I suspect that's why it defaults to id3v2.2, where tag IDs are three letters (and 'COM' is therefore valid). Why it *doesn't* convert this particular 'COM ' to 'COMM' I don't know.

    This also explains why it only occurs on some mp3s, as only mp3s ripped by a CDDB2 client writing id3v2.2 tags which are
    • You didn't write it up! Eye keel j00! No, that's OK, it didn't take me long to find it. But yes, I noticed that it stored the user-specified comment in COMM. It's quite broken.

      I am adding a new type of "mode" for get_mp3tag() which returns all the ID3v2 information it can. It is dissimilar from the plain get_mp3tag in that it returns more than just the ID3v1 frame types, and different from the older "raw_v2" mode in that it does the text encoding (and other manipulative) stuff to the data. It also co
  • I've been writing stuff to put music imported by iTunes in the right directories to match the rest of the collection, and found the 'TCP' frame, that contains the 'compilation' value (for various artists albums, you can't store the album in a folder by artist, so if this is set, I store it under 'various artists'. Can't find that in the spec anywhere either..