[ID3 Dev] Contextual Granularity in id3 Tags

[Tom Corelis]

Hello everyone,

I've been lurking the id3 mailing list for some time now and have a
suggestion I would like to submit for consideration. I'm not sure if
this has come up in the past (I have looked a bit), so please forgive
me if the point has already been discussed, or if I'm barking up the
wrong tree.

The topic is a little complicated and kind of suggests sweeping
changes. Perhaps something for v3?

In any case....

Among some genres of music, it is very common to have a single track
with multiple artists or bands involved (aka context). For example,
take the following tracks:

1.	Deepsky feat. Jes Brieden vs. Yilmaz Altanhan - Ghost vs. Eighties
(AvB mashup)
2.	Markus Schulz Feat Departure - Without You Near (Coldharbour Mix)

The first example has three (possibly four) different artists, each
with a different relationship to this version of the song. The second
example also has three different artists, although the artists'
relationships are much simpler. Given the current id3v2 tagging
scheme, artist information that is identified by the computer as
artist information is limited to a single string of text. This creates
a problem for people's music libraries, which (afaik) distinguish
artists by the artist string irregardless of context, even if we human
beings know the artists are the same: "Deepsky" is a different artist
than "Deepsky feat. Jes Brieden" and the computer has no way to
identify "Jes Brieden" should the user want to pull her up. This, in
turn, creates a problem for those of us who use Smart Playlists or
some other form of procedural playlist generation, or more
importantly, those of us using portable music players.

Ideally, I think the best way to address this would be to break up the
individual tags into pieces that are then reassembled, or some sort of
contextual tagging. id3 already does this, of course, but I am
suggesting additional granularity beyond a single "artist" string--and
given the modularity of id3v2 in it's current form, it's one I see as
at least possible on the protocol end.

Now, I'm not a master programmer or anything, and implementing a
scheme such as this can potentially be very complex. However, I have
an idea--and merely that, an idea--of how one might go about doing
this...

Break up a file's tag into its relevant chunks. Whereas things
normally look like:

	Artist: Deepsky feat. Jes Brieden vs. Yilmaz Altanhan
	Title:  Ghost vs. Eighties (AvB mashup)

Under this new scheme one breaks up the tag into all the relevant
chunks of information: (please forgive my bad pseudocode)
	
	Artist[1]: Deepsky
	Glue[artist[1], artist[2]]: feat.
	Artist[2]: Jes Brieden
	Glue[artist[2]][artist[3]]: vs.
	Artist[3]: Yilmaz Altanhan
	Title[1]: Ghost vs. Eighties
	Title[2]: (AvB Mashup)

With an additional field that contains information for reassembly, like:

	Artist.reassembly: %artist[1]% %glue[artist[1], artist[2]%
%artist[2]% %glue[artist[2], artist[3]%
	Title.reassembly: %title[1]% %title[2]%
		Etc etc...

So, essentially the final display string should contain the same

	Deepsky 	feat. Jes Brieden vs. 	Yilmaz Altanhan - Ghost vs. Eighties
(AvB mashup)
	artist[1]	glue	artist[2]--	glue	artist[3]------	title[1]---------- title[2]----

While it is definitely more complex, I think it does a very good job
of storing relevant contextual information that allows to properly
identify the song while allowing the computer to properly categorize
it with other tracks from "Deepsky."

I have a library of roughly 8100+ tracks (which is small by some
people's opinions), with music from all kinds of different contexts.
Compilations, mashups, regular music, and so on, and the current id3
tag system doesn't do a very job of working with music that breaks out
of the single-artist CD format.

I'd like to see what the general consensus thinks of an idea like
this... perhaps it's something easily done and implemented, perhaps
not. Perhaps you have a better way of addressing convoluted song
infos. Either way I'd like to pitch the idea out into the open for
consideration...

Thanks,

Tom

PS:
The reasoning behind all this may be a bit confusing. So imagine this:
you have a bunch of music that was written by artist Deepsky. Deepsky,
like many electronic producers, tends to work with other artists,
oftentimes producing music that results from a collaborative effort.
So in your mp3 player, you are presented with your list of artists,
and you wanted to quickly pull up all music by Deepsky. Most mp3
players (hardware and software), as far as I know, would list all the
relevant Deepsky music as such:

1. Deepsky
2. Deepsky feat. Jes Brieden
3. Deepsky vs. Sasha
4. Paul Oakenfold presents Deepsky
...and so on.

Depending on how intelligent your mp3 player is, entries 1, 2, 3, and
4 would produce their own lists that are exclusive to each entry.
While most software players (iTunes, Winamp, etc) are smart enough to
realize that entries 2, 3, and 4 contain "Deepsky" and include 2, 3,
and 4 in the list of search results for entry 1, many hardware players
(iPods, Nomad, etc) are not this smart. Many don't have a search
function at all, and you have no choice but to scroll through a list
of artists where there is no additional matching beyond the exact
name. I have a 4G iPod Photo and Archos AV300 currently, and I
previously owned a Nomad Jukebox 3, and all of them work(ed) this way.
It's a real nuisance, because in order to generate a quick playlist of
all songs by "Deepsky" it meant manually adding them into a temporary
playlist, and I have yet to find a single player that handles temp
playlists smoothly. On top of that, I think we as collectors may be
able to better address our music collections if the software
explicitly knows all of the context in a given song.

This phenomenon is also observable on sites like last.fm, although
last.fm tends to crosslink user's audioscrobbler submissions with
their artist database to clean up the results.

---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org