History:Waiting For Moderation: Difference between revisions

From MusicBrainz Wiki
Jump to navigationJump to search
(added links to RDF page (Imported from MoinMoin))
 
((Imported from MoinMoin))
(One intermediate revision by the same user not shown)
Line 1: Line 1:
'''Status:''' ''IIRC this page is pretty old, but it still describes a valid problem. There are a lot of proposals like [[Survival Of The Fittest|SurvivalOfTheFittest]] or [[Album Locking|AlbumLocking]] ([[Quality And Quantity|QualityAndQuantity]]) that deal with this. It would be good to find a page and list them all there. --[[User:DonRedman|DonRedman]]''
'''Status:''' ''IIRC this page is pretty old, but it still describes a valid problem. There are a lot of proposals like [[Survival Of The Fittest|SurvivalOfTheFittest]] or [[Release Locking|ReleaseLocking]] ([[Quality And Quantity|QualityAndQuantity]]) that deal with this. It would be good to find a page and list them all there. --[[User:DonRedman|DonRedman]]''


==The problem==
==The problem==
Line 30: Line 30:


--[[User:Jinxie|Jinxie]]
--[[User:Jinxie|Jinxie]]
[[Category:To Be Reviewed]] [[Category:History]]

[[Category:To Be Reviewed]]

Revision as of 17:18, 31 January 2007

Status: IIRC this page is pretty old, but it still describes a valid problem. There are a lot of proposals like 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