MusicBrainz Inconsistency Case Study

[touchatou]

Hi everyone,

at this time I have a very moderate trust on the Picard/AcousticID accuracy,

An interesting use case

here the good title is a live version of “love twist” by Culture Club, finally I have a Green result as Love is Cold recorded version, I am not sure that the acousticID/FingerPrint is good.

I think the acousticID prior to find the result, but I don’t understand how this is AcousticID is generated, there is a process to fix wrong Acoustic ID ? there is another way to force another/different way to find the result with Picard with other information (other ids, title, filename, …)

the problem with this kind of error, when I use such songkong, Jaikoz product, that generate a mess in the audio file collection, I am lucky that I made a copy of original audio file storage, so when I detect an error I can check with the original.

I found an answer if I very this : Track "6dc1e6c9-18de-42bd-a26a-e212bf66c3c6" | AcoustID
here Love Is Cold

this is the acoustic id for this tune : Track "6dc1e6c9-18de-42bd-a26a-e212bf66c3c6" | AcoustID but is does not match with the reality of this song : Love Twist

How it’s possible to have the wrong acoustic id and how to fix it

Thank you

[foxgrrl]

If you register as an editor on MusicBrainz, you can unlink any AcoustID from any recording it may have been erroneously attached to…

So, about that erroneous attachment… How does this happen? Well, anybody can get an API key to submit new AcoustIDs from Picard… And then submitting new AcoudID association with Picard is really simple, really really simple… so easy that you can do it by accident. And, I think that Picard’s UI does not make it easy to see what exactly it is you are doing when you submit AcoustIDs… Even if you enable the obscure, hard-to-see, column that shows a red or grey colored squiggle next to a track when it thinks there’s a new AcoustID to submit… the data is still very opaque.

I have personally, accidentally, submitted acoustIDs for the wrong tracks, and then had to immediate go to the MusicBrainz web site to unlink them so that in the future no one else would be confused by my mistake.

I have seen some very very wrong links between AcoustIDs and recording MBIDs before. And I speculate that how this may have happened, is that in older versions of Picard, if you just dumped a few thousand MP3s or whatever into it, and then had some identified, and some not (yet)… you could hit a button to have Picard try and match things up, and many times it would get things spectacularity wrong. It mostly seemed to match things up based on time duration… so, two songs that just happened to be the same length would be associated in Picard… and if the user didn’t notice, and they hit the “Submit AcoustIDs” button… now everyone else in the future will be confused as to why this recording is so badly misidentified.

Also if you drag and drop a bunch of recordings onto the wrong album in Picard, it’ll try to do this associating too, and then if you don’t notice before hitting “Submit AcoustIDs” (like, you thought you were submitting something else…) then things will also be mixed up.

Oh yeah, there’s these docs too: AcoustID - MusicBrainz Wiki but they don’t go into a lot of detail…

Something else that’s not well documented about AcoustIDs, is that they only identify the first 120 seconds of any recording… if you have two different recordings, which are identical for the first two minutes, and then diverge, AcoustID will be unable to tell them apart.

(Also AcoustID ignores any recording shorter then 30 seconds in total duration.)

[foxgrrl]

Oh, also! There is another program besides Picard, which you can use to submit new AcoustIDs… and it does not require any MBIDs, so it doesn’t actually link the AcoustIDs to any particular recordings, but it does submit whatever random strings are currently attached to the audio files at the time… no matter how possibly wrong the info the those tags may be!

If you look in the AcoustID database directly, you’ll notice a lot of AcoustIDs have a list of artist names and song titles, with a bunch of slight variations in spelling and capitalization, (and occasionally something completely obviously wrong), and a count of how many times that particular tag has been seen by users…

Well, that’s where that data comes from.

And, I think, Picard uses some of that data too when it tries to “guess” what a recording is, if there is currently no AcoustID linked to any MBID recording…

And then once Picard does that… whatever wrong info someone once had in a file somewhere, is close enough for Picard to put the two together… and then… if the user hits “Submit AcoustID” without noticing the error… it now becomes officially linked together in the database.

This is pure speculation by me… but also explains the evidence…

The program is called “acoustid-fingerprinter.app” on OS X… and it was last updated in 2011.

[IvanDobsky]

Like @foxgrrl I spend too much time looking at recordings and AcoustIDs attached. Totally agree with those findings. I think one of the biggest ways things get tangled are VA collections as you can see a number of legit recordings all associated on one AcoustID, and then suddenly you have a very unrelated track attached. This is the Picard users who get Picard hunting through hundreds of tracks in one hit.

There are counts of the number of submissions for an acoustID source, so this helps to spot the rogues and disable them.

It can be funny when working on a live release and realise you are then finding it has been associated to a totally different concert by just one uploader. Manual corrections is then the only way to fix.

Another odd one I was fixing last month involved some audio books with ten CDs where it was clear that one user had managed to attach ALL the CD2 to CD10 to CD1 in error. (Probably as the tracks were all called Part 1, Part 2, etc).

Some people trust computers a little too much to be perfect, and can punch “Submit AcoustID” buttons before checking the data.

If you have good tagging, you are normally safer with the Lookup buttons in Picard. Scan can give some very “interesting” results. If you are keen and spot errors, then you can help disable the bad matches. And the more you submit Good AcoustID data the easier it is for others to spot the bad stuff.

[chaban]

MusicBrainz Case Study : The reality of MusicBrainz Database Consistency

[outsidecontext]

What you really should do if you know that AcoustID is for s different recording:

1. Load the exact version of the release that contains the song you own, see Retrieving Album information — MusicBrainz Picard v2.6.3 documentation

2. Generate the fingerprint for your file, then drag and drop it onto the proper track. Submit the fingerprint. See also Submitting Acoustic Fingerprints — MusicBrainz Picard v2.6.3 documentation

3. Unlink the wrongly associated fingerprint from the other recording at Recording “Love Is Cold (You Were Never No Good)” by Culture Club - Fingerprints - MusicBrainz

MusicBrainz needs the help of everyone to gather the data. You have the audio, you can improve the situation. That’s much better spend time