No, it's not EAC that's ruining FLAC files by adding ID3 tags.

Apparently, it's EasyTAG. Thanks, fuckers.

Tags: tagging

54 4C 45 4E 00 00 00 05 20 01 00 00 00 01 03

For the uninitiated sane: That frame is of type TLEN, which is only useful for VBR MP3s, which this is not. It then indicates it's of length 5. It then indicates that it has a data length indicator (which is normally only used when the data is compressed or encrypted, so you know the decompressed sized; this frame is neither). So then it wastes another 4 bytes telling you it's not really of length 5, but of length 1. Then that one byte tells you the encoding of the text is UTF-8.

Then there's no text.

So 4 + 4 + 2 + 4 + 1 = 15 bytes to tell me that it doesn't know the length of the file, but damned if it doesn't know its ignorance is in UTF-8.

Anyway, that's then followed by an entire additional ID3 tag, as if anything too stupid to parse the first one is going to bother to look for a second. What's really amazing, though, is that the content of the two tags is different, and the second tag is also full of mojibake.

Where'd this come from? Banshee's CD ripper.

Update: Apparently this is the result of one GStreamer developer leaving some non-functional code in the LAME element, another developer asking what happens if that code suddenly starts working and two things start writing ID3 tags, a third (Banshee) developer deciding to ignore the bug and use the problematic pipeline anyway, and a fourth unknown developer making the LAME code functional again; GNOME bug #329184.

Tags: tagging

So, the end result of the past two weeks of thinking and talking to a few sane and some insane people are the following standards:

1. Ogg Vorbis tag names don't have spaces. albumartist, originaldate, recordingdate.
2. Keys with "parameters" should use key:foo@bar.
3. The foobar2000 community is absolutely as frustrating as I remember back when I was first implementing Musepack support.

Tags: tagging

I dug this up while trying to use Google in place of user consensus (it's so much easier to deal with).

Removing the identity of artists is one of digital music's largest threats to jazz preservation. A full understanding of jazz goes beyond the "Great Man" theory and recognizes the influence of side players - the wide network of people that developed this musical language together. Selling songs and albums separated from names disrespects the artists and hinders the education of new listeners...

Will online music stores someday have a feature like this? Or will they continue to discard names, ensuring that listening to jazz in five hundred years will be similar to viewing a painting in a museum by an "Unknown Dutch Master"? — itunes versus jazz preservation

Sometimes, really small commits feel really good.

Tags: tagging
Current Music: Beyond Good & Evil OST - 3/31 - Home Sweet Home

album artist or albumartist?

Votes backed up by real-world file statistics get extra weight. Your vote will affect Quod Libet 0.19.

Whichever one we don't pick will get read and converted to the one we do on save.

Update: Maybe it's not entirely clear what I want.

In Vorbis, tag names can have spaces (I'm not aware of any, but APEv2 has record date, debut album). They can also not (tracknumber). They can also have a _ (replaygain_track_gain, musicbrainz_trackid). Given that they can have spaces, I think removing them is pretty dumb. But the trend seems to be towards underscores. Except I've never seen album_artist.

Quod Libet can, of course, translate them to anything it wants. But it would be nice if we could match at least one actual on-disk format.

Tags: tagging

There are some keys we can't define a nice mapping for, even though they're extremely close to Vorbis ones.

TFLT, which identifies the file type using some stupidly terse method. With any luck, no other format will adopt ID3.

TLAN is for language, but the spec demands a three-letter ISO language code. I sort of understand why, because it lets you translate the tag values into the user's native language. Except you'd think they'd have learned their lesson after the ID3v1 genre list. So, no go; we demand freeform frames if we're not going to need to parse them.

TPRO for the production copyright. It has some lame requirements like TCOP, except that Vorbis recommends the same copyright tag format. But I'm not going to put up with that crap twice.

TOWN; Huh? "Owner or licensee?" No thanks.

TRSN and TRSO are for Internet radio stations only. As far as I know they're totally unused, and it's not something we'll ever want to write in a file; the streaming server should handle that.

TOFN, TDLY are horrible things that do not belong anywhere.

TDEN, TSSE, for encoder settings, are things that should be encoded in the stream itself if they're important. Vorbis and Musepack both do, for example, and I'm pretty sure LAME does as well.

W* is a mess. ID3v2 defines no less than eight URL types, ranging from "where the album can be bought" to "where the album can be paid for" (no, really). WOAR, the "official artist/performer webpage", is the only one I think matters. WCOP (copyright information) is potentially useful, but in practice USER (license terms) does the same thing. If eight's not enough, there's also WXXX to define your own.

Of the remaining (all non-textual) frames, the only interesting ones left are RVA2, COMM, and USER. All are easy enough.

So what's left? TOAL, TSST (see the last entry), TOPE, TENC, TKEY, TMED, TDOR, TSOA, TSOP, and TSOT.

Tags: tagging

I spent three hours today on about 40 lines of code, for a feature I expect maybe two people will use. Well, that's not quite accurate. I spent about 10 minutes on that code, then three hours trying to get GTK+ to properly indicate that a drop on the sidebar won't work unless it's likely to be an RSS feed (where "likely" means "is known not to be an audio file in the library"). It looks like the best way to handle that was a really disgusting hack, which ended up not working in my case anyway.

On the plus side, the past two weeks have caught a dozen bugs in edge cases, and I've fixed and written test cases for most of them.

So on that note I'm going to write something optimistic.

Tagging Keys That Work
There's a huge list of tags that I can actually translate, unambiguously, into something else. In the core Vorbis tag list we have TIT2, TIT3, TPE1, TALB, TRCK, TPUB, TSRC, TCON, TENC, and TCOP. After a simple extension we also get TPE2, TPE3, TPE4, TCOM, TBPM, TMOO, TPOS, and TOLY. We even have some harder mappings; RVA2 and a COMM with an empty description are easy enough.

Now to get unoptimistic: Tag keys QL does something with right now, that are ambiguous.

TIT3 and Ogg's "version" are clearly the same. But APEv2 has "subtitle". And a version isn't really a subtitle, even if usually you want them treated the same way.

TSST is "part". In my mind, this corresponds to something like "disc name" or some kind of sub-album. However, some people have told me this is what TIT1, "grouping", is for (and don't know what TSST is for). iTunes uses TIT1 in a completely ambiguous manner; sometimes for things like sub-album, and sometimes for things like "Podcasts". So I think it's mostly for user-defined groupings that don't fit into TCON (genre). But I've come under fire for this before.

Regardless though, "part" is a horrible name.

WOAR is "website". ID3v2 actually defines half a dozen URL frames. WOAR is the only one I see used regularly, and the most general.

That only leaves a zillion more frames to figure out appropriate Vorbis mappings for.

Tags: quod libet, tagging

For a while, but mostly due to iTunes, people like collecting dumb statistics about how they listen to their music. The ones they care most about are rating and play count (though I really have no idea why, especially for play count). They want these saved and shared, but at the same time they don't want other people who touch the files ruining their obsessively-gotten play counts.

One (I guess the sole) advantage of ID3 is that it lets you store structured data, like associating an email address with a rating and a play count. In Vorbis, you need to come up with something yourself, in an unstructured (but parsable) way.

So. ID3 uses POPM, which keys both ratings (out of 255) and play counts to an email. In Vorbis (and so APE) we have a couple of options. First we need to decide the format of the rating. x/255 is arbitrary and kind of dumb; QL uses a 0-1 scale, which should be accurate enough for daily use, and is easily understandable and displayed (it's just a percentage). We also probably want to split rating and play count into two Vorbis keys, because really, they're not related.

So we have a few options that immediately present themselves:
rating=foo@bar 0.123
rating foo@bar=0.123
rating[foo@bar]=0.123
rating:foo@bar=0.123

The first is the most obvious; a rating key linked to an email and a rating. But that sucks, because the email is really part of the key, and you want to be able to do things like "delete/get the rating key for this user" taking advantage of the hash-table-like representation a Vorbis comment can have. So that's not so good.

The second is the least noisy, but also not very clear. I bet a lot of software doesn't properly support tag names with spaces (it complicates QL's parsers a little, too), though they're going to run into trouble at "album artist".

So it's down to the third (suggested by Michael), and the fourth, which is like a cross between the two. The advantage of third is that it makes it clear that foo@bar is some kind of parameter to rating (at least, to people familiar with most formal syntaxes). The advantage of the fourth is that it doesn't involve chopping off the last character, and it looks much more like the kind of markers used in other things (TXXX and COMM frames, for example, inside and outside of QL).

Tags: tagging

ID3 contains basically three different dates, TDRC, TDRL, and TDOR for recording date, release date, and original release date (< 2.4 split up the year and month/day and time into different frames, but the basic organization was the same). There's also TDTG for tagging date, but there's no ambiguity there. It uses the standard YYYY-MM-DD HH:MM:SS format which is oh-so-readable-and-collatable, with each part after the year optional.

Vorbis says "date" should be the recording date (a few older programs wrote "year" but I rarely see that now); it doesn't specify a format, but in practice everyone uses the same basic thing, which is YYYY-MM-DD.

APEv2 says "year" should be the release date and time for compatibility with older APEv1 tags; again, it uses YYYY-MM-DD; recording date and time should be in "Record date".

Pretty good so far. Sane, parsable formats; all support multiple values; all use the same format, even, for the content.

Non-problem: In practice, everyone uses Vorbis's "date" for the release date (since that's, you know, easily known; Wikipedia has some nice flamewars about the dates certain albums were recorded). That's fine; Vorbis can use "record date" for that, and we can keep the world going like it is now.

Problem: In practice, everyone used TYER for writing ID3 years in 2.3 (probably id3lib's fault, though I can't really fault people for writing the year they want recorded to a frame named YER). TYER translates into TDRC. So now everyone uses TDRC for writing release dates. TDRL is unused. So there's no way to tag recording dates in MP3s, because we're already using that frame for release dates. We could just use TDRL for that and completely invert the meaning, but ew.

Proposals?
Based on existing practice "date" should be the release date.

"date" and "record date" are the (human-readable) names to use for Vorbis; "date" and "record date" for APEv2, with the former being mapped to "year" internally.

TDRC is "date" for MP3s. There's no way around this. Unfortunately this still leaves no alternative for "record date" except a custom TXXX frame (which I'll get to later).

TDOR, and "original release date", are available in all formats still (this is #495). "Original release date" is a perfectly acceptable name, I guess, but it's very long.

Tags: tagging
Current Music: 浜崎あゆみ - ayumi hamasaki RMX WORKS from ayu-mi-x 5 non stop mega mix - 1/1 - Free & Easy, Real me, eve

Over the next few time_periods (weeks, maybe months) I'm going to be trying to create a real cross-format tagging standard rather than the hacky stuff I have now. In practice, this means:

• Figuring out what tag names correspond between ID3, Vorbis, and APEv2. This is mostly done in Quod Libet already, but it needs some review.
• Creating an extended Vorbis tag list that covers the keys present in ID3 and APEv2 that aren't yet standardized properly in Vorbis. Ditto for APEv2, though I expect this to be easier since its default tag set is nicely large already.
• Beating my head against several problems caused by the differing formats and existing practice.
• Implementing it in Mutagen, Ex Falso, and Quod Libet.
• Somehow proposing this as a real standard and getting software authors besides Quod Libet to support the new tags.

If you don't think this is going to interest you, you can probably ignore the next few weeks of posts. Otherwise, required reading to play along from home:

• ID3v2.3, ID3v2.4 frame list.
• A comparison of ID3 versions. The links are busted, but it's a good reference.
• Official Vorbis tag list.
• Unofficial Vorbis tag list; this appears to have no real-world uptake (mostly for lack of editors). Its author is also a big enough asshole I feel dirty even acknowledging its existence.
• APE key list. The foobar2000 community has their own highly dynamic and annoying key list, which is more influenced by their obsessions and TAGZ than common sense. So I'm going to stick to this instead.

Tags: tagging
Current Music: 浜崎あゆみ - ayumi hamasaki RMX WORKS from ayu-mi-x 5 non stop mega mix - 1/1 - Free & Easy, Real me, eve