I have an album (“Recess” by Skrillex) that finds two different releases for the same files, depending on whether I click Lookup or Scan.
The Lookup method finds a Great Britain release, but the Scan method finds a US release. The original file metadata does not indicate which one could be right, and the auCDtect log does not say which release it might be. The track timings are identical.
Which one of these is correct? Why does one lookup method choose a different release than the other, if the tracks are identical. Every post on here says to trust the Lookup method, if the tracks have been clustered before looking them up.
HOWEVER, it is incredibly rare for EVERY track in an album to show up on the same release, when identifying via the SCAN method, unless that is the exact release. However, we are talking about a digital studio that is unlikely to use different track times or remastering for different releases, so it is extremely likely that the AcoustID are identical for both releases.
What are the considerations that go into the ID routines of these two features (Lookup, and Scan)?
If the tracks are the same across release versions, the scan and lookup probably just pick one at random. You can right-click on the loaded release to change the version, so in the end it doesn’t really matter. According to our data, the US and UK releases have a different catalogue number, so just pick the one that matches with the release you have.
Scan finds recordings, which are shared among all the versions we have (I’m not sure whether Lookup does differently). But yeah, as the above poster said, you can just switch versions by right-clicking
So basically the files provide no clue which exact edition of the album the files where taken from, which means Picard has to guess. The reason the results are different are that scan and lookup operate on different data. Scan uses acoustic fingerprinting with AcoustId, lookup the existing metadata.
As you said yourself the files themselves do not provide any clue which one is “correct”. Regarding the data given both are correct. If the exact edition is important to you, e.g. you want to use the exact version from your CD shelf, you have to select the proper version. Picard can only operate on the given data in the files.
Yes, I’m aware of that, but why is there a difference. If it cannot tell the difference between the releases, why does one process default to a certain release, but the other default to another release? If the releases are in fact identical, then this is a peculiar behavior from the program. Or is one of them technically more accurate for this given instance? And if this instance has no definitive answer as to which one is more accurate, then how can I trust the program to make correct matches on other releases that might have dire consequences if they are confused? This example is sort of a proof of concept that has no dire consequences. But if the problem happens here, it may happen on something important in the future.
Also curious to know if anyone who knows Picard code like the back of their hand knows why a different release might be ‘randomly’ picked with each method (assuming all tracks have the same DiscID’s and the tags don’t differentiate between releases). But only out of curiosity - in a practical sense I don’t see how it matters.
If your existing tags are good, use lookup, if they’re not good, use scan (imo). They are supposed to give different results because they are different tools for different use cases.
As an aside:
[quote=“AMDphreak, post:5, topic:177806”]
how can I trust the program to make correct matches[/quote]
Unless our database is 100% perfect (it’s not), and your information/tags are 100% correct, you can’t, and shouldn’t.
If it’s really important to you, check your matches manually, and back up your music folder just in case.
That said, Picard/MB is perfect for people who are very picky with their data, so a hearty welcome to the community @AMDphreak, you’ll be right at home here
As @aerozol said, you shouldn’t trust any automatic method if you want to get the exactly right release for all your albums. Even if your own files and tags are good, there might be a mistake in the MB database which results in you getting the wrong release.
I use MB mostly for two things:
Tagging some random files in which case I only care that the artist and all the titles are correct (= the release group is right). Taggers are good at doing that automatically.
Tagging my own rips. In that case I use the right release MBID as an anchor for my rip. If MB doesn’t have the right release yet, I have to add it first of course.
IF the tracks are identical between releases it seems to me that if the AcousticID data for release A had been added to the database but not the AcousticID for release B, then when you searched by AcousticID you’d get a result of release A.
As to why release B is the result for Lookup - maybe Lookup orders results by country and country for release B is higher on the list than country for release A. ?
When I look both releases up in the browser (first and second) both releases use the same recording-IDs, so why isn’t Picard just picking the same version for all the songs. Now granted the bonus songs were also scanned last, so the first ones were already sorted into the “wrong” release, but it could change the release.
Of course changing the release manually is possible (even though it would be nice if the header would show the same name as the right-click - Other Version menu shows), but it’s kind of weird at first because at first I thought it would be mismatching or something (and I don’t really want to compare different releases by hand for every album )
Always ‘cluster’ your tracks first, then Picard will try to keep them together. (Pretty sure this works for scan as well as lookup? Someone correct me if I’m wrong, I don’t use scan that much)
If you scanned the bonus tracks separately, then it’s not unexpected to have the regular tracks appear in the release without the bonus tracks - after all 99% of people who scan just those tracks will be wanting that result. Automatically grouping the tracks together after both have been scanned and matched makes sense for your user case, but would be really annoyingly in some cases - once something’s been matched I usually want it to stay put until I move it.
Unfortunately you are going to have to manually check some stuff with MB, if you care about versions etc! But that’s unavoidable I’m sorry to say.
If you’re not that fussy you should only have to check releases on the right side that are highlighted red or orange, or don’t have a gold CD symbol.
Not sure if that was helpful at all! Let us know any other thoughts and questions, it’s appreciated
Unfortunately clustering doesn’t help with scan It sure does with lookup, but when scanning it doesn’t seem to use the cluster. Though that kind of makes sense since Scan is really more useful if we don’t know the grouping already.
Makes sense, however I didn’t scan them separately, they were just the last on the list to be scanned
True, turns out I was talking out of my butt then
I guess taking clustering into account when scanning would solve your problem then?
As a side note, those tracks have the same fingerprints/are the same recordings, but they have slightly different track lengths. Perhaps that is taken into account/ your non bonus tracks match the other track lengths.
But honestly I doubt it, I think it’s tricky because ‘scan’ has been specifically set up to ignore existing information - which is useful but also means it’s doing an immense amount of guess work. Your result isn’t really that bad for scan haha, some people get tracks all over the place, esp. if their files are a mess to start with
edit: not meaning to make light of your issue, if you have any concrete suggestions or ideas try searching https://tickets.metabrainz.org where you can either create new tickets or vote for others
)
It sure does with lookup, but when scanning it doesn’t seem to use the cluster. Though that kind of makes sense since Scan is really more useful if we 
