Creating iTunes compatible COMM frames

patrick machielse patrick at
Wed Jan 27 14:55:08 CET 2010

Op 27 jan 2010, om 07:04 heeft Dudy Kohen het volgende geschreven:

> On Tue, Jan 26, 2010 at 11:42 PM, patrick machielse <patrick at> wrote:
>> > It turns out that new comment frames by default do not have a language set, and TagLib writes out 'XXX'
>> > in place of the 3-character language code:
>> >
>> > //  commentsframe.cpp
>> > ByteVector CommentsFrame::renderFields() const
>> > {
>> >    //...
>> >    v.append(d->language.size() == 3 ? d->language : "XXX");
>> >
>> >
>> > The ID3V2.4 spec says it should be an ISO 639-2 code. "XXX" isn't valid.
>> Is this a bug in TagLib? I can't find a response to my original message in the list archives.
> This is the standard when the language is not defined or invalid.
> It's not correct to set a default language in a library, so you should set the language before writing.


"  The three byte language field, present in several frames, is used to
   describe the language of the frame's content, according to ISO-639-2
   [ISO-639-2]. The language should be represented in lower case. If the
   language is not known the string "XXX" should be used."

This seems to me a contradictory part of the specification, since ISO-639-2 defines a code for "undetermined language" as well ('und') and using XXX is not complient with ISO-639-2.

'should be used' suggests that this requirement has the nature of a recommendation. TagLib possibly could write out zeroes for better interoperability without violating the v2.4 specification proper. If that is not appropriate, I want to suggest implementing a default value of zeroes (if that works) or 'eng' as part of the TagLib "iTunes Hacks".

Patrick Machielse
Hieper Software
info at

More information about the taglib-devel mailing list