Why are there 5min and 10min tracks still on the page with an 8 min track? I punched the “burn the artist” button and expected all of those to have vanished as outside the margin.
The good thing is I don’t think I have seen anything wrong yet. In fact, it is more a case of seeing stuff your script has missed. Or multiple examples like the one above. Or versions of that where different tracks by different artists are involved.
I think it may be worth re-running your detection scripts and see if they pick stuff up again after the first blast of deletes. Something makes them skip matches.
Hi, okay these ones are being missed because the acoustid only links to a single mb recording. The original reports looked for cases where there was a bad match and a good match for an Acoustid and hence were only interested in acoustids that matched multiple mbrecordings
and the later reports rely on an interim table used by the earlier reports so not including any acoustids that only link to one mbrecording, I will modify the script and rerun.
You misunderstand how the button works, the reports are listed in artist order, so if you click on Unlink by Artist it will unlink all the records for the same artist shown on the Albunack report, but it will not unlink any other pairings shown on that Acoustid page if they are not listed in the report that you selected Unlink by Artist for. The reasoning for this is that often there is enough information on the report to work out if all pairings for an artist are invalid without needing to check each individual Acoustid page,
Thanks, makes sense. I am looking in too much of a human way. The positive from this shows your scripts are erring on the side of “these are definitely wrong”
You have had me looking at so many of these variations now I hit them like a machine cleaning up. I can also see how often so many of the problems come from just one or two bad uploads from a single user. Picard (and other apps) need to hide the Submit AcoustID buttons deeper so only geeks who know what they are use them
Now that does not surprise me. I thought it looked a little small. I’ll be back another day this week to punch through a bit more…
Okay what I have done is split the over 30% difference into those with single submission for the pairing and those with multiple submissions, so split the 250,000 into 194,000 and 58,000. Because extra reports have been created the reports numbering has changed, all accessible from JThink
My own view is the 194,000 can be auto deleted because they are way out on fingerprint length and each one has only ever been submitted by one user, but Il wait for you to take a look later in the week and see what you think.
The ones with multiple sources are more problematic, what Im not sure about is if the same user can submit the same pairs multiple times or if they have to be from different users.
Also to differentiate between the new records and the old added a No of others Mbids this Acoustid linked to column, this will be zero for these new records. But also realized these tracks havent been check for pairs that are actually already disabled but not marked as such in database (because of problem with Acoustid datafeed) so I need to query Acoustid for all these to find out if still active, may take some time…
No, except if the Acoustid developer does it, but why would you want to do that, fingerprints themselves are not wrong just what they may link to on MusicBrainz
There is an instrumental track, wrong linked with the fingerprint of the main song (with vocals) (or it could be vice versa??). I want the fingerprint gone so that a new fingerprint can be created for the instrumental.
We may not be the best people to help. We are just removing links between Fingerprints and Musicbrainz Recordings. Looking for bad data. We are not the AcoustIDs Hamsters.
What happens when you submit the data from Picard? If the instrumental is different enough it should make separate fingerprints. But this is one of those areas where multiple recordings can link to a common pool of Fingerprints if the Instrumental looks close enough to the “with vocals” version. Don’t think there is much that can be done about it. The maths will just see it as “the same”.
I’ve seen it happen with concerts too when some tracks can be performed in a very similar manner which starts to cross-pollute the fingerprints due to too many similarities.
That’s what happened. When I submitted the instrumental, it linked to the “with vocals” track. The algorithm(?) didn’t create a seperate acoustid for it.
I think you just mean the fingerprint has incorrectly been linked to a MB recording that is the vocal version, that doesn’t mean the fingerprint itself is the same as the fingerprint would be if you had the vocal version of track as well.
So you can unlink this, just need to login to Acoustid first (can use mb account to do this).
Then what you want to do is correctly link the fingeprint to the correct musicbrainz id, are using Picard or something else ?
Do you have the vocal version as well then you check that it does in fact have a different fingerprint.
So I have been napalming that report, but not quite as simple as pressing one button. Instead I have private version of reports that split the pages into 5000 records each (larger pages seem to be too large/slow) , then I can press button once for each page. However sometimes it only disables the first record then stops (and I couldn’t get it work at all for a week, any ideas ?) but if it does work it will continue for the whole page, so its been a bit of a battle but now at the last 10,000 for the first >30% report.
Also for the earlier reports the only records left had been checked they were either clearly valid, or it was not possible to know if they were valid or not, so I have now moved these records into an internal acoustid_mbid_checked table so they are no longer shown in reports.
Next week I will update my database with the latest Acoustid data and the latest MusicBrainz data, will be interesting to see how many potential invalid matches come up in these first reports.
Okay fixed my problem by using a GreaseMonkey script instead, now just napalming the Acoustid links to songs that vary by at least 30% from fingerprint length, multiple submissions, and not covered in earlier report report
I checked some records in this report and when there are multiple submissions but no other mbids linked to the same acoustid there is rarely any user submitted metadata so I think the same user is just resubmitting the same wrong link in Picard.
When acoustid is linked to other mbid then usually case that matching to the right song but wrong version of the song (wrong length) when there is one matching length available.
I can also see how often so many of the problems come from just one or two bad uploads from a single user. Picard (and other apps) need to hide the Submit AcoustID buttons deeper so only geeks who know what they are use them