When I'm not focusing on school (which is always), I'm thinking about an Audiogalaxy Revival Project... There was something about the way Audiogalaxy gave me music, and I want to recapture that magic. And here's what I came up with so far.
Bittorrent is great! I love the way it maxes out download speeds, and I don't think it should stop. Yes, it's better for large files, yet at the same time, I guess the algorithm could scale for lower end files. The load is either peer-loading or group-loading. Peer loading would be fine, I guess, if the files are light... MP3s are light, right? I dunno. That is flexible.
What I did settle on, however, is the inherent volatile nature of MP3s. Large, Bittorrent-friendly files satisfy hash algorithms easily because those files don't change. What does change frequently are MP3s. And MP3s are composed of two sections, data and meta-data. The data section, hopefully, doesn't change. But the meta-data, the ID3 tags, change all the time. Since at least one part changes often, the actual MP3 file has many hash keys, which is bad for file sharing. So what can we do?
We openly embrace the fact that MP3s are different. I wondered about this when I was using Audiogalaxy, but with the way information was presented, Audiogalaxy didn't really let you choose what you wanted, unless you really dug through the menus. What I propose is as follows...
Let the ID3 tags have first priority in defining how an MP3 is indexed, Audiogalaxy style. This is primarily by Artist, Song Title, and Album. Then, as a second priority, let the structure of the file name, Artist Dash Song Title define the meta data for the MP3. Then, when an MP3 is downloaded from the Audiogalaxy service, let it rewrite the meta-data section of the MP3 in both ID3 and file name. Thus, when the service re-indexes this new information, it will consistently contribute back to the pool of information already there.
The hash algorithm should only concentrate on the data section of the MP3, since the ID3 is volatile. If there are... Multiple hash keys for one MP3 key, a la Artist and Song Title pair, then the Audiogalaxy service should do a simple random choice to decide which song to deliver to the user. Why.
Because popular songs stay and dumb songs don't. There's no real way for the service itself to judge the quality of an MP3 other than by the number of users who have it. So... By choosing a random MP3, Audiogalaxy is giving each file an equal chance at survival, while at the same time, reinforcing the statistic by which each MP3 exists in percentage.
That's all I have for now. I'm proud of myself.
Posted by Mark Canlas at November 29, 2004 11:49 AM