If AcoustID returns linked recording MBIDs without any additional metadata these can end up being used even if there are linked recordings with metadata. This leads to many instances where recordings are loaded as non-album tracks.

The situation can happen if recordings got merged in MB but AcoustID has not yet applied the merge to its own data. In this case it returns only the recording MBID without any additional information.

On Picard side two issues seem to exist with the matching algorithm when comparing metadata:

• AcoustID submission count is highly ranked, leading to a higher score if there are many submissions, even if there is no other metadata
• In general existing releases seem to cause a lower score then no release at all, giving Picard a bias towards non-album tracks. That's because the release matching score is usually below 1.0 and is calculated into the overall matching score.

Some affected AcoustIDs currently are:

• https://acoustid.org/track/b1eb0783-f5f3-4428-9733-2fbfd8e30d93
• https://acoustid.org/track/38338eff-b530-498c-a2ef-07e01d642187
• https://acoustid.org/track/dd38fbf0-a8da-405d-93a4-377eafa104fd
• https://acoustid.org/track/91684050-2987-48e9-807a-4f7354305511
• https://acoustid.org/track/1cc7cd8a-50c7-4951-a8fa-557c6b2b41e6

For more details see the discussion at https://community.metabrainz.org/t/worse-results-in-picard-2-10/663668/34

Note that the underlying issue of recordings not getting merged on AcoustID side is also a bug which should be resolved in AcoustID server, see https://github.com/acoustid/acoustid-server/issues/114 . But the matching issues are independent of that.