Unusual genre suggestions

[ewx]

Found the following matches. Choose one:
 1.) jazz 8f087b0b System Of A Down / Mezmerize
 2.) rock 8f087b0b System of a Down / Mezmerize
 3.) classical 8f087b0b System Of A Down / Mezmerize
 0.) none of the above:

Comments

[mair_in_grenderich]

lj-poll to decide :>

[sesquipedality.livejournal.com]

This is why I wish more rippers supported Musicbrainz. As it is, I tend to end up correcting afterwards.

[aardvark179.livejournal.com]

CD tagging databases being useless shocker.

The thing is I'm not sure that Musicbrainz is the right answer, at least not in the way id3 tags are currently used. Most people will not notice errors when they are ripping tracks, and if you notice them afterwards then your tag editor has to feed those changes back to the database. Maybe the right thing is for the tags to hold the disc id numbers, and check for updates whenever the track is played—or at some minimum interval. Unfortunately this would hammer the track databases, and would depend on reliable disambiguation of disc ids.

Without something like the above I'd either have to run iEatBrainz over my library on a regular basis or go through 1500+ CDs worth of tracks looking for tpyos correcting them, and submitting the updates. Life is too short for either of those.

Oh, and I'm ignoring the fact that the genre tag is a hopeless thing anyway.

[ewx.livejournal.com]

I like the idea of remembering only the disc IDs, though DisOrder's filename-based approach wouldn't get on well with it.

If we have, to pick a number out of the air, 20M people playing a track ever 3m or so that's about 100,000 queries/second. Assuming 50bytes/query (say a 20 byte disc ID and some transport overhead) that's about 80Mbit/s inbound data, which is unreasonable without a fairly serious funding model.

There's outbound data to worry about too, but of course you only need to reply to queries that would get a different answer to what you told the same client last time, and the queries can have a serial number to support this.

So outbound bandwidth requirements might be trivial in comparison to inbound. Being the opposite of web service, that might actually be a useful fact.

In practice things aren't going to change so often you need to requery every time you play a track, so the local cache can have some fairly severe rate limiting - for instance, only re-check a given response once a month, and even then only when it actually plays.

Also, anyone who regularly plays whole albums will divide the query load they offer by around 10.

Rechecks don't need to be reliable, as long as they get there eventually. That means you can use UDP for the queries and not both with retries for the rechecks, and you can have multiple servers which aren't all bang up to date all the time. (They could even user serial numbers in the future as a kickoff for fetching updates, allowing extra servers to be added without the central operators having to do the work.)