Sorry for that. I had previously answered from my phone, and that had refused to download the log.
But I have now looked into the log and debugged the behavior. The result is rather interesting:
Nearly all of the found AcoustIDs contain a single MusicBrainz recording that has a very high number of submission, but which no longer exists as it got merged into another recording. Track "38338eff-b530-498c-a2ef-07e01d642187" | AcoustID is a good example:
The first track ID 8855169b-b148-4896-9ed3-a1065dc60cf4 has the most submissions (94), but the recording itself on MB got merged into Hocus Pocus (U.S. single version).
It was recently already noticed in Why does acoustID sometimes not show merged recordings? that AcoustId currently does not deal well with merges. Instead of also merging the recordings on the AcoustId side they just end up as essentially dead links. Not sure if this is currently by design or a bug, @lukz might be able to say more about this.
But it is also Picard who has some trouble making sense of the data. There are two issues:
-
Picard considers the submission count, relative to the highest submission. In cases where there is a recording with a significantly higher score this gets a much better ranking. This makes it prefer the recording with the high submission count even if it has no metadata associated.
-
There seems to be a general, unintentional bias towards recordings without releases. The reason is, that if there is no recording the entire similarity check for recordings gets skipped. But as similarities get multiplied and you usually never get a 100% score additional release comparison lowers the result compared to no release at all.
It definitely should be the other way around: matches with releases should be preferred. Also a recording MBID without any metadata definitely also should get a lesser match then one with well matching metadata. I’ll add a ticket and see we can get a fix out for a 2.10.1 release.