History:Waiting For Moderation

From MusicBrainz Wiki
Revision as of 08:21, 15 February 2008 by Dmppanda (talk | contribs) (+ header (Imported from MoinMoin))
Jump to navigationJump to search
Status: This Page is Glorious History!

The content of this page either is bit-rotted, or has lost its reason to exist due to some new features having been implemented in MusicBrainz, or maybe just described something that never made it in (or made it in a different way), or possibly is meant to store information and memories about our Glorious Past. We still keep this page to honor the brave editors who, during the prehistoric times (prehistoric for you, newcomer!), struggled hard to build a better present and dreamed of an even better future. We also keep it for archival purposes because possibly it still contains crazy thoughts and ideas that may be reused someday. If you're not into looking at either the past or the future, you should just disregard entirely this page content and look for an up to date documentation page elsewhere.

Status: IIRC this page is pretty old, but it still describes a valid problem. There are a lot of proposals like DataQuality, SurvivalOfTheFittest or ReleaseLocking (QualityAndQuantity) that deal with this. It would be good to find a page and list them all there. --DonRedman

The problem

I have a lot of apparently unpopular MP3s from EMusic that I run through the tagger. If they're really unpopular, nobody's entered them yet, so I can add them to the database myself. Since they appear and stay, I can go ahead and tag my files correctly.

Unfortunately, more often, I find that someone has made a very poor shot at entering the data (maybe just imported crap from FreeDB). OK, I go, and I mod it -- but I cannot tag my MP3s with the corrected data until it passes moderation.

So, I have a lot of untagged MP3s. MusicBrainz benefitted, I guess, but I didn't, because I have to come back after a week or more (usually more) and re-match my files. This is made even worse if someone has made a dumb (in my view, of course) moderation against my changes, and they've been rejected.

Client-side solution

Some CDDB-aware apps store successful database retrievals on the local system. This is obviously motivated by the common usage pattern of playing a CD over and over again; you don't want to make constant DB hits here.

A tagger application (maybe any MusicBrainz-aware application?) could benefit from a shared local store that keeps successful hits, and uses them in preference to the database proper. Of course, then we have to get the data back to the server somehow. The current web interface is right out; the app would need to be able to edit everything itself and submit mods back.

Server-side solutions

The server could be extended to let me snarf RDFs that have unapproved mods attached to them, maybe with a flag passed to mq.



My personal policy in cases like this is to do the edits on the database, then click 'listen' for the file in question. This tosses the file to WinAmp. I then (back in MusicBrainz) remove that file from the list. (Probably don't need to do that step, but I prefer not to use one device to alter a file while it is under scrutiny by another device.) Back in WinAmp I then hand fix the TAG.

This benefits me, in that I have a good TAG and that file can then be sorted into whatever folder it's headed for. It benefits the next person, because the info is there to find, they just need to vote for it (at that point it has probably expired, and a single vote gets it approved). True, some people will not take the time to notice that the un-fixed data is not quite on, but if you did, they hopefully will.

Not a perfect solution, I know, but this holds me until the Powers That Be think up a better one.

--Jinxie