[ID3 Dev] New genre coding idea?

Tom Sorensen tsorensen at gmail.com
Mon Mar 6 05:21:51 PST 2006

On 3/4/06, Pat Furrie <pfurrie at hotmail.com> wrote:
> 4)       Programs like iTunes seem to allow multiple genres, but in reality
> users are only creating a new genre which is the composite of existing
> types.  However there is no cross-referencing: I can give an MP3 the "genre"
> of "rock soundtrack" but if I list everything in the "rock" or "soundtrack"
> genres, it doesn't show up.  Additionally, "soundtrack, rock" is not
> equivalent to "rock, soundtrack" in the iTunes world.

Except that you're wrong here. If you want to talk about how iTunes
does it, you're correct initially -- if you want to list a song as
belonging to both the "rock" and "soundtrack" genres then iTunes
simply mashes them together with a space (think ID3V2.4, but with
spaces instead of nulls separating the genres).

Now if I filter my tracks, inside of iTunes, by genre and I ask for
"rock" (or "Rock" or "ROCK" or whatever -- iTunes is case-insensitive)
then it *will* list the song I have tagged as "rock soundtrack". If I
ask for "soundtrack" then it will list it as well. iTunes does a
substring search for matching.

And this works for most things. There's a rather limited case where
you may want two words to be uniquely joined, or where substring
matching may do the Wrong Thing (e.g. -- search for Classic and you
get not only "Classical" but also "Classic Rock", which probably don't
work together), but they're solvable through the use of regular
expressions, quoting, and other methods.

> 1)       Because the length of the field is unknown, padding must be used,
> and the possibility still exists of needing to re-write the rest of the file
> due to exceeding the space given by any padding.

The ID3V2 standard recommends padding to 2K or 4K. I'm seriously
doubting that genres is what's going to cause you to exceed that.

> 2)       Any spelling errors create additional genres when they shouldn't
> exist (does "soundtrack" equal "sound track"?)

This is an issue, although it's solvable through a soundex search.

> 3)       What works for English doesn't work for other languages.
> Localization is difficult.

This is a false issue. If we're going to concern ourselves over this
then we'd better think about how to deal with auto-translating the
title, artist, and other textual data to other languages too. They are
not necessarily the same, particularly for Asian languages.

> Bitmap Disadvantages

As pointed out, the biggest disadvantage is that it breaks backwards
compatability. You're talking about ID3V3 now, not ID3V2.

Genres are endlessly mutable -- new ones are created all the time,
even if they're just fusions or twists of existing ones. Trying to
hardcode that is an excercise in futility. If you're concerned over
pattern matching, then use more loose search methods as suggested
above. If you're concerned over I18N, then just start weeping now.
This is the least of your worries.

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