Hi.
In Picard 2.9.* I only had 11 results [standalone recordings].
In Picard 2.10 I have 357 results [standalone recordings].
Here you can find hits without an album such as:
Gary Moore - Still Got the Blues 04:13
The Stranglers - Something Better Change 03:28
Billy Idol - Hot in the City 03:37
David Bowie - All the Young Dudes 03:57
I think you may be suggesting that the fuzzy matching algorithm in Picard 2.10 is worse than that in 2.9. @outsidecontext may be able to give better insight into whether this might be the case.
But Picard is designed to save the release and/or track MBID and then not have to guess the next time you load the file, and this doesn’t seem to be happening.
Also use of MP3Tag in parallel with Picard may cause other issues - I have never done this so I have no idea what they may be, but I can foresee that this is a potential problem.
Picard and Mp3tag are separate, independent programs.
I run Picard to the end, save the results, open Mp3tag.
Besides, Windows and the processor are multitasking. 
Thank you for educating me @Echelon69:
I am not sure quite why you came here and asked for help if you are of the opinion that people who try to help you are less knowledgeable than you rather than more knowledgeable, and then you then insult them like this!
It is normal here to use screenshots of Picard if you have a Picard problem.
Nobody is insulting anyone.
Mp3tag is simply better for viewing id3tag.
There was actually no change in matching / lookup between Picard 2.9 and 2.10. Are you sure you cannot reproduce this with 2.9 right now?
How do you get the results? Do you use lookup or scan?
One way how this can happen is using Scan (AcoustID fingerprinting). If that is used Picard gets all the release information from AcoustID, which operates a MusicBrainz database mirror for that. If that mirror is not up-to-date, e.g. for just created releases or due to some error) then there is no release information and Picard sorts the results into standalone recordings. Ideally Picard should in such case do another request against the MusicBrainz API to get the missing information. There is an existing ticket for this, which I’d like to get done for one of the next versions.
Another way to get standalone recordings loaded is if you load files with existing MusicBrainz recording ID in the tags but without release ID. Then Picard automatically loads the recording only for those files. So if your files automatically got sorted that way after loading them into Picard check the existing tags in the files.
Well, you were mansplaining to me how Picard and MP3Tag are different programmes and how Windows and processors can multi-task, with a clear assumption that I (and everyone else except you) wouldn’t know that. I accept that you may not have intended it as an insult, in which case presumably instead you have zero sensitivity for others, nevertheless when I spent my valuable time trying to help and you mansplain to me like that, then absolutely I consider that an insult.
Perhaps, but by showing the files in MP3Tag you are A) giving us LESS information rather than more because we don’t get to see what Picard thinks of the file, and B) you are expecting us to be experts in MP3Tag when this is a support forum for Picard and NOT for MP3Tag. And yet again, you have mansplained to one of the long-time Picard support volunteers about how you know best what information is useful to those of us supporting you with your Picard question and you have declined to accept the advice offered.
Sorry - but I am not helping you further if this is your attitude.
You did not describe what did you do to get those results so what sort of advice do you expect?
Are your different Picard versions set to use exact same preferences? To begin with, I’d have a real close look there.
This result with 11 standalone recordings is from a copy on an external drive, made with Picard 2.9.
I have circa 15,000 MP3 files.
Always in this order:
I completely clear tags using Mp3Tag
I upload the catalog to Picard
Click Scan and if something remains in the left panel, click Lookup
I always use the same settings in Options:
Sliders right for LP, single, EP. Compilation slider to the left.
Convert Unicode to ASCII
Use genres from MB
I don’t change anything else.
Given your workflow and the use of scan the problem very certainly is AcoustID not returning the full information as described above. So in this case the primary problem lies within AcoustID. I’m unsure why it is so many, though. Usually this only happens for freshly added releases until AcoustID has synced its database mirror. If you could share a full debug log of auch a scan action which results in standalone recordings I could take a look.
To save the general issue we will, as I described previously, need to implement the additional lookup in Picard to get full release information (which we’ll do, but I can’t promise a release date).
However, I’d suggest to reconsider your workflow. By removing all tags before tagging with Picard you make it maximally difficult for Picard to properly tag your files. It can then only rely on the acoustic fingerprint and maybe the title and artist it guessed from the filename. Also this approach causes you unnecessary work when you apply it to previously already tagged files.
I’d rather recommend to properly tag the files once, taking care to tag them to the proper releases and recordings. Make sure you keep the MusicBrainz recording and release IDs. Then when you want to update the tags in the files you can drag the files into Picard any time and it can match them to the correct release automatically.
How to create debug log?
@outsidecontext one more question:
After setting up Verbosity, should I add my music catalog or repeat my steps with clearing the tag?
The steps are correct.
Try loading some files that in your last run got identified as standalone recordings. Load them into Picard, if they get loaded on the right pane drag them to the left pane. Then use scan. If they again end up as standalone recording share the full log.
If the this time don’t get loaded as standalone try it with different files. Or maybe try the full tag clearing thing first. It should theoretically not be relevant, but if we are dealing with a bug it still might be related
The whole operation takes 2 hours, so tomorrow.
Good night
Hello.
Today, as agreed, I made a debug log.
First, I cleared the tags of 15,000 MP3 files using Mp3Tag.
I added the catalog to Picard.
I only clicked Scan (not Lookup) to make it easier to investigate.
After Scan finished, there were 91 files left in the left panel.
I saved the changes and took a screenshot.
Then I clicked and opened Help->Debug
However, for an hour the new window did not open, the hourglass was spinning, there was no response on the upper Picard beam.
My computer is a Lenovo laptop, i5-11400, SSD, 16GB, broadband 600Mb
I had to stop it.
It was probably too big a log.
The second approach was this:
Using Mp3Tag I only extracted the files with the standalone album and copied them to another directory.
This time there were 357 files, but without their source directories.
I cleared the tags and uploaded the catalog to Picard.
I pressed Scan.
I opened the Debug window and saved the log.
I made an appointment with @outsidecontext
Secondly, I want to always have up-to-date tags from Music Brainz.
Don’t delete your old tags. You are making everything so much harder and more likely to fail. You are less likely to get “updated” tags, and more likely to get plain wrong tags this way.
Also work in smaller batches. Picard is much happier with one or two albums at a time. Especially if you are starting from no tags. Picard needs its results checking and it is impossible for you to check all 15000 tracks you are throwing into Picard.
Impossible?
You’re wrong.
Picard can do it within 2 hours and the results are very satisfactory.
With Picard 2.9 only 50 unclustered remain.
With Picard 2.10 it’s the same, only the number [standalone recordings] increased from 11 to 357.
