Different results using Cluster and Scan in Picard v1.4.2

I have an album with two discs. Disc 1 has 11 tracks, Disc 2 has 5 tracks.
It was tagged with metadata with Picard v1.4.2 from this album released in Germany:

If I drag & drop the 16 tracks from the windows file explorer to the left side of Picard in the section “Unmatched Files” and with the deactivated option General -> Ignore MBIDs when loading new files the German album will be found immediately on the right side and all the 16 tracks appears green.

If I activate the option General -> Ignore MBIDs when loading new files and d&d the same files, the tracks remain on the left side (as expected). The result differs now if I

a) select this 16 tracks and press the Lookup button: No reaction at all

b) select this 16 tracks and press the Scan button: I get the 16 track album, but track 1.06 has two entries and track 1.11 remains empty

c) select this 16 tracks and press the Cluster button: Two albums will be created on the left side: One with 11 tracks, the other with 5 tracks. If I press the Lookup button for the first album, I get a Russian release with 11 tracks on the right side. If I press the Lookup button for the second album, this 5 tracks will be added “randomly” to existing tracks in this Russian release on the right side.

d) select this 16 tracks and press the Cluster button: Two albums will be created on the left side: One with 11 tracks, the other with 5 tracks. If I press the Scan button for the first album, I get a Russian release with 11 tracks on the right side. Track 1.06 has two entries and track 1.11 remains empty. If I press the Scan button for the second album, I get an additional German release on the right side with 16 tracks, the 5 tracks are the matching 5 last tracks.

You get another different result If you DEactivate the option General -> Ignore MBIDs when loading new files and d&d the same files. Then manually drag & drop the matched files back from the right to the left “Unmatched Files” side. Whatever you try Scan with/without Cluster the russian 16 track album remains on the right side and the tracks will be matched again Track 1.06 has two entries and track 1.11 remains empty.

Can someone explain the different behaviours?
Do we have some magic priorities for the mentioned General Option?
What about keeping/clear an album on the right side and the influence for tracks on the left side?

Basically everything above is expected. First of all the “Ignore MBIDs when loading new files” is completely irrelevant for Scan and Lookup, it only determines whether files added to Picard will automatically load the release on the right pane, if there are existing MBIDs in the files, or if they will be loaded only in the left pane as if they had no MBIDs included.

Now the other actions Scan, Lookup of single files and Lookup of a cluster all do different thing, hence different results are expected. That’s why those options exist :slight_smile:

Scan does match fingerprints, and it does lookup track by track based on the fingerprint only. It might load all files from a single release, but it might also load different releases which contain recordings with matching fingerprints. It is best used in cases where the existing metadata is bad and does not help in looking up the files (think of “Track 01.mp3”). In some cases it will give you perfect results, in other cases it might at least help you to figure out which recording it is and you can then use this info to manually look for a matching release. Clustering has no effect on Scan.

Lookup without clustering does a file by file lookup based on existing metadata of the file. It will use album title information, but it has still some tendency to load multiple releases if it finds multiple matches. E.g. if you have a release with 11 tracks, one of them a bonus track, Lookup might load the 10 track version first, assigning 10 tracks to it, then process track 11 and in addition load the 11 track version and assign this single track to it. It also might load compilations. The settings in Metadata > Preferred releases can be used to influence this and prioritize albums. The track title, track length and release type have great influence on this matching.

Lookup with clustering also uses existing metadata, but treats the cluster as a release and tries to find a release that matches it. The album title, album artist and number of tracks have a great influence in this matching.

Given the above we can try to explain the results you got:

Not sure here, but can happen. Totally depends on the existing metadata, without seeing this I can’t tell.

It matches by fingerprints. It got the correct album, but both track 6 and 11 have the same fingerprint attached. Actually it is now unlinked for “Silver swan”, but I can’t see when this unlinking happened. If it was recently this should work now, if this was already unlinked when you tried something somewhere is not working as it should.

Clsutering clusters by album title, so I suspect your tracks had different album titles. Something like “QNTAL V: Silver Swan Disc 1” or so? The first disc matching is easily explained by this, track number has a big influence on the matching, so the 11 track release matches better. As for getting the Russian version, try setting the preferred release countries in options. It does not have a big impact on the matching, but for two mostly identical releases it will then prefer the one from preferred release countries. For the second disc there is no really good match, and Picard has a tendency to prefer already loaded releases to avoid clustering. So it will ruse the existing release, as this is also in the matches, and then it will assign the tracks one by one to that release. For this again it uses the existing metadata. I don’t think this is really “randomly”, as the tracks on disc 2 are mostly variations of tracks on the first (e.g. “Von der Elben (single edit)” should likely have been matched to track 4. Also existing tracknumbers come into play. Again it’s hard to tell exactly, that depends on the metadata.

This is very much a), because clustering has no effect on Scan. The last 5 tracks are no suprirse, since this is what you got in a) also. For the first 11 tracks maybe the Russian release was already loaded? Again once Picard has loaded releases by Scan it does a file by file comparisson to figure out which matches best, and this is based on existing metadata and it does prioritize already loaded releases.

4 Likes

Thank you very much for your detailed explanation!

This was my first unlinking attempt :blush: And the implication is exactly as you say.

2 Likes

Just for the records: You can see this change in the “editing history” right at the bottom of the AcoustID page.

2 Likes

Cool, never saw that. But you need to be logged into acoustid.org (which is easy, because one can login with the musicbrainz.org account).

2 Likes