Prevent Linking Short Fingerprints to Longer Recordings

[sound.and.vision]

Hi all,

I know this is often a bit of a difficult thing to approach, and I expressed my frustrations in todays community meeting (happens on Monday evenings on Discord btw).

I generally work on a lot of “mainstream” data in MusicBrainz, including typical Top40/Billboard style compilations and it’s always beneficial (in my eyes) to merge these recordings into the existing entity in the database wherever possible.

For many editors, this is made possible by Acoustid and it does the job relatively well as a form of “proof” that two recordings are the same. However as we’ve seen recently (Who the heck is Metro Station?), there is a fair amount of accidental vandalism occurring where well meaning but ultimately inexperienced users of Picard are submitting entirely wrong fingerprints to MusicBrainz recordings.

This then has a knock on effect when another user comes along and uses Picard and hits the Scan button and it connects various local digital tracks to the completely wrong entity.

It also makes the life of editors like myself who are trying to “clean up” the database unnecessarily difficult as I have to sit and slowly pick off (unlink) these obviously incorrect links.

I’ve suggested various controls that have generally been rebuffed (such as not permitting fresh accounts to submit fingerprint data, or rate limiting the amount of fingerprints that can be submitted in one batch) however I hope that this “data validation control” might be welcomed.

At the moment it is entirely possible for someone to fingerprint:

untitled.mp3 - duration 0:44 and then link it to Great Song by Popular Artist - duration 4:43.

Obviously a recording that is 44 seconds long is not going to be the same recording as one that is 4:43 in length.

I get that the Chromaprint only fingerprints the first 30 seconds (?) but Acoustid is obviously picking up more metadata including the duration of the original source file (sometimes it looks like ID3 tags are also submitted).

I’m not sure how it could happen, but I would like to see that if there is a +/- 60s difference (possibly lower) between the fingerprint and the recording entity, that the relationship cannot be made.

I feel that this would stop a good portion of these obviously invalid relationships being made.

[IvanDobsky]

I also spend a lot of time in AcoustID, trying to tidy up and merge recordings, and it is sometimes quite stunning as to the volume of mess in there.

@sound.and.vision

I’ve suggested various controls that have generally been rebuffed (such as not permitting fresh accounts to submit fingerprint data, or rate limiting the amount of fingerprints that can be submitted in one batch) however I hope that this “data validation control” might be welcomed.

Agree with this… I am also all for hiding the Submit Fingerprint button in the default Picard. A noob who runs the app without reading instructions is throwing 1000s of tracks at it, then punching Submit Fingerprint not realising what it does. And they hit it twice. It is a pattern you see a lot.

The bulk hectic tagging army should not be using this button. Especially those ones you see who are trying to label their compilation tracks back as the original album and single names. It is this crew where a lot of damage comes from

@sound.and.vision

I’m not sure how it could happen, but I would like to see that if there is a +/- 60s difference (possibly lower) between the fingerprint and the recording entity, that the relationship cannot be made.

You need to work on a percentage. 60s on a 10 minute prog track, or some 12" remix is not much. 10% or 15% difference is going to be more than a fade out difference.

I don’t think Picard submits actual metadata, it links a recording MBID. But other apps do supply metadata. I know when I do my cleanups in AcoustID it is that metadata from the other apps that makes it easier to clean up the duff Picard submissions that link a recording. It is the recording MBID from which the track and artist names are then pulled.

I find album tracks submitted as 12" tracks, or compilations in general some of the hardest to untangle. Remixes getting constantly mixed up with original album tracks. But these do often stand out due to that track length.

I get amazed as to how often totally unrelated tracks are included with a couple of acoustIDs. But you can’t reject on a “different” artist name as I had a track this week which was “Tubearmy” or “Gary Numan” depending on which name compilations used.

[outsidecontext]

I generally agree with the above. Just noting that since Picard 2.8 (released in May 2022) it does not submit the MBID for linking when the duration difference is more than 30 seconds.

@IvanDobsky

I don’t think Picard submits actual metadata, it links a recording MBID.

Right, usually only MBID. Except if it does not submit the MBID (see above), then it submits metadata instead. In the early days AcoustID also accepted fingerprints without both MBID and metadata, but that turned out to be little useful, so this is no longer possible.

[IvanDobsky]

An example I just cleaned up

Here we have a one fingerprint added of a track 20seconds off, totally different name to the track with 559 samples, and no match to any of the “other apps and their metadata”.

This is an easy one to visually fix.

But it gets harder when remixes have different names, and meta data starts popping up in different languages. Getting an algorithm to fix this is tricky.

Edit: I posted just as @outsidecontext did. Great to see that the idea is already in place. Good to see you have our back on this one. I just made myself laugh when looking at the above example. I suggested “10% to 15% margin”… and the first one I trip over has Sho Nuff 90% the size of Going Out of My Head.