metatagged comments from iTunes in Amarok

[Bryan Larsen]

Jeff Mitchell wrote:
> On Monday 05 March 2007, Bryan Larsen wrote:
>> iTunes is one of the most popular MP3 players & rippers, if not the most
>> popular.  "Might makes right" has a kernel of truth, unfortunately.
> 
> iTunes reports "waltz" because it knows how to deal with the rest of the 
> comment junk.  But comments that are meaningful only to iTunes shouldn't be 
> expected to be meaningful elsewhere.

And iTunes doesn't expect it to be.  That's why their fields are 
appropriately tagged with a content descriptor like 
"iTunes_CDDB_TrackNumber".  The user comments are located in an 
unlabelled COMM field.

> 
> As Scott suggested, they're using the wrong frame.
> 
> COMM:
> This frame is intended for any kind of full text information that
>    does not fit in any other frame. It consists of a frame header
>    followed by encoding, language and content descriptors and is ended
>    with the actual comment as a text string. Newline characters are
>    allowed in the comment text string. There may be more than one
>    comment frame in each tag, but only one with the same language and
>    content descriptor.
> 
> GEOB:
> In this frame any type of file can be encapsulated. After the header,
>    'Frame size' and 'Encoding' follows 'MIME type' [MIME] represented as
>    as a terminated string encoded with ISO 8859-1 [ISO-8859-1]. The
>    filename is case sensitive and is encoded as 'Encoding'. Then follows
>    a content description as terminated string, encoded as 'Encoding'.
>    The last thing in the frame is the actual object. The first two
>    strings may be omitted, leaving only their terminations. MIME type is
>    always an ISO-8859-1 text string. There may be more than one "GEOB"
>    frame in each tag, but only one with the same content descriptor.
> 
> The intent of the Comment field is for textual information, not binary data 
> like normalization information.

What about CDDB lookup ID's?  I think Apple made the right call on that 
one.  It's not binary data, it's information that a knowledgeable user 
can turn into a URL.  In fact, it looks like iTunes is more right than 
TagLib here.  COMM is not for "comments" it's for "any kind of full text 
information."  Unless the content descriptor says "comment" we can't 
necessarily assume that it is a comment.

> 
> Might doesn't make right when the might sucks.  You'd be using Windows if that 
> were true.  Complain to Apple, please.
> 

There are third party programs out there that rely on and create this 
information.  Apple isn't going to change this for a whiny open source 
developer.

Apple may be wrong to write files in this format, but it's also a bug in 
my opinion for TagLib not to do the right thing for cleanly labelled 
fields in a very popular interpretration of a standard, whether or not 
this interpretation is wrong.

This is the DRUMS principle: be strict in what you emit, and lax in what 
you accept.  For good or ill, it's an established principle in internet 
standards, such as the one TagLib implements.

Bryan