Music tagging and these cassettes have a lot in common
How do you sort your music? Traditionally we’re stuck to the same, old, unconnected “Artist, Album, Track” (A2T) system without the flexibility of custom tags that provide meaningful information to the user and curator of a digital music library. This conundrum has wracked my mind for years now, how to make a system that actually fixes the static “search-only” system of today and opens it up to be more browseable, where you can not only label things in your own private library but also open up the possibility for community input for common information like genre tags or mood. These features are totally lacking on any of the desktop-based media players and I’d like to go ahead and discuss at least a couple ways of going about making meaningful, “semantic” connections between the media tucked away on our computers while still using these antiquated jukeboxes.
Please bear in mind that the order of which these options are presented is pretty much arbitrary based on the order of which I think of them.
Option 1: Playlists
These are meaningful to the user of at least this computer
This first option involves setting up numerous playlists, they sit in folders that bear descriptive titles such as “mood” or “tempo”, and then the playlist contains entries to songs stored on the file system or off in The Cloud. These playlists are static, require constant attention to ensure their up-to-date-ness and don’t contain any more information than what we already had to work with. We have the added flexibility of many playlists pointing to a single file, but we still lack the ability to provide new information for these files. At least this is a start though, we’ve added a new bit of information that doesn’t travel with the songs themselves which is the first step in a truly dynamic and useful library.
Option 2: File Duplication
Yes, this has happened to me before.
Who thinks that having multiple copies of the same song in the same library is a very good idea? Well, it depends, perhaps different albums actually contain the same song, verbatim. What happens when you make a change to the metadata of one file? It doesn’t effect the remainder of the duplicates. This mode has a significant level of data security though maintenance may be more difficult and requires more disk space to do this. By the way, that was just for songs that appear identically in multiple albums. We completely ignored the concept of extra data by storing them in separate folders. The Folder or Directory paradigm is great but without symbolic links (which most modern operating systems support) file duplication would lead to enormously large libraries containing dozens of duplicates of songs. A folder containing songs with A2T metadata named “Sad” might have songs that are duplicates from other folders such as “slow” or “really like.” Now the problem of file duplication can come to fruition. I think this idea will have to be put to pasture.
Option 3: Tags
Ok, so after that abysmal and difficult to work with model in option 2 and the slightly more flexible model in option 1, let’s come up with a better, more effective idea. Let’s utilize a tag that a lot of people don’t: the comment frame. You can store a lot of text in the comment frame, XML for instance, or even writing in a new frame called the GEOB
4.15. General encapsulated object
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.
Text encoding $xx
MIME type $00
Filename $00 (00)
Content description $00 (00)
Encapsulated object
One could encode an XML representation of the tag data in base64 and include it in the GEOB tag of an mp3, have a music player read this data and… voila, problem solved. You build a specification that’s flexible, handle the information through a fairly strong database and be able to sort and archive music in a variety of different ways. No more trying to figure out if an album is exclusively “dream pop” or “shoegaze.” Here’s an example.
<?xml version="1.0" standalone="no"?>
<song>
<title>Elmo's World</title>
<artist>Elmo</artist>
<album>Noise</album>
<tags>
<personal>haha</personal>
<public>sesame street</public>
</tags>
This is all well and good but you have to have the software utilize this data. Alas, we’re at an impasse. Of those three examples the best solution is also the most complicated, the worst solution is the simplest, just copy your files. A common ground for this is probably just going to continue using the present systems that are in place. Playlists help though they might be too cumbersome still.
There is also this other notion that perhaps, perhaps, I’m just a bit too picky about this stuff and that most people really don’t mind if their music is slightly off. Truth is, how am I to know how accurately or well my music is categorized? Beats me.
