This happens when I do lookup, after having tried Scan a few times. I started out with several hundred and got down to 84 with Scan. The problem is that lookup doesn’t seem to understand that the vital clue is the title of the song. And we aren’t talking niche songs either, we’re talking top ten hits, mostly. After I found a few very, very strange artists I started checking them and they all turned out to be fails in the Lookup. I don’t know if it’s the . in front of the title, which makes it hard for Lookup to understand it. A . should just be omitted from a lookup, in my book, not sure how it works with Picard.
Maybe some pre-processing with MP3tag is needed?
Problem here is Picard expects only the Title in the Title tag. You have an Artist in there as well.
MP3Tag will let you pull that data out and put back in the correct tags. There is a Filename to Tags option. You can use that to split the artist and track titles from the filename into the tags.
That will then reduce the guesswork for Picard.
1 Like
It’s searching MusicBrainz for songs with the track title “.Roxette- Must Have Been Love”, track number 2 and a length of 260 seconds. This gives the following results: https://musicbrainz.org/ws/2/recording?limit=25&query=track%3A(.Roxette-%20Must%20Have%20Been%20Love)%20tnum%3A(2)%20qdur%3A(260)&fmt=json
The very first result at this moment is a track called “It Must Have Been Love (Roxette) Musikhjälpen 11-12-2019” (because it also contains Roxette in the name) by a Swedish band on a bootleg release. Obviously with your settings Picard skips this. Instead it takes the second one, track name, length and track number are sufficiently close.
As I suggested in the other thread, try the “Tags from filename” functionality to set artist and title. If I understand it correctly your files are named like “2.Roxette- Must Have Been Love.mp3”, so use a naming string like %tracknumber%.%artist%- %title% for the tags from filenames.
Also you might want to re-check your preferred releases settings. As I understand it you want only albums, and have lowered the scores for singles and compilations. But if I look at the releases containing this song on https://musicbrainz.org/recording/8ec61a82-726f-42ec-99f1-d295140fac8b I see only compilations and singles there.
Also most of those don’t have this track on position 2. You probably got this from some compilation. If you don’t want the track number to be considered unset it before lookup.
You get what you ask for. If the input data is not well suited to find the release you’d like to have you won’t get proper results.
5 Likes
I guess it’s just the way Picard’s search engine is set up. I probably expected it to think more like a human. You see that inside the string there’s the name Roxette, so you automatically understands that that’s the name of the band, then you guess the rest is the title of a song. I guess making a search engine think that way takes too much programming, and CPU work. 
Butt then you get something like this:
where the Band name, the song title, and the album already are in the tags, but still Picard chooses something else. And even the length is closer to what the tags says (1 second off in stead of 6 seconds). Why is that? Oh, and even the year matches.
Your track numbers are causing confusions. Picard is trying to hunt down the album for you.
1 Like
But the other tags, aren’t they way more important? It even has the correct album, song, and artist, all of whom should be way, way, way more important than a track number.
You are asking Picard to find an album for you. You give it some facts. It can’t know that one of your facts is a lie, so it attempts to take your facts as truths and does its best with that data.
Remember - computers are dumb. They can only work on the data you provide them.
I again point to MP3TAG as that can wipe out all those track numbers in one click. Then you can feed Picard only truths.
If you told me the name of the song had ‘Roxette’ in it, I would think the name of the song had ‘Roxette’ in it. If you told me you were looking for a song that was track number two, I would assume you were looking for a track number two.
Luckily outsidecontext has given you good methods of avoiding this miscommunication, try his suggestions 
(Or mp3tag)
There are actually two parts to this answer: First, the MusicBrainz server is actually able to handle such a search query. E.g. you can just search for Roxette Must Have Been Love, and MB will be able to find something rather reasonable. Arguably MB’s full text search is maybe not always the best, but it works.
But Picard actually does search for specific fields, so it explicitly asks for a title with “Roxette Must Have Been Love”, and that gives quite different results because it expects “Roxette” being part of the title.
You can actually play around with that inside Picard: if you select the file and use “Find similar tracks” Picard will open a search, by default with advanced query syntax searching individual fields. But you can for example disable advanced query syntax and change the search to “Roxette Must Have Been Love” and you’ll get different results.
“Find similar tracks” is by the way another tool Picard offers you that could help you find what you want.
I can’t see an album called “Los Lobos Soundrack” in Los Lobos - MusicBrainz or by search, and that might be the reason already. Either the album name is different or the release is just missing and should be added.
Ok, two things here: First, Picard explicitly asks the MusicBrainz search server for recordings that appear on releases with the specified track number, and the search server tries to satisfy this.
But the second part to the search is that Picard takes the search results and applies its own weighting and filtering, which depends for one part on defined weights for some fields, on another part on user settings (mainly those under “preferred releases”). And here the track number is currently not considered for file by file lookups.
Overall you have files that:
- have incomplete or no tags
- or have been tagged against some specific compilation they were taken from
In both cases you can expect imperfect matches. For incomplete or wrong tags (e.g. the title containing the artist name) the results can be quite off. Try setting at least artist and title reasonable correct. “Tags from filenames” is a tool that can help here a lot if the files have some structured names.
If the files have been tagged against some compilation or something but you would like to tag them against the album or single release then unsetting some misleading tags can help. E.g. track number and album name.
1 Like
Here you are guv: Release group “La Bamba: Original Motion Picture Soundtrack” by Various Artists - MusicBrainz
Track 1 is the item that is hiding away from enquiries… with the different album title I can see the algorithm preferring that track 11 match
1 Like
Look at the picture. The tags where already there. This wasn’t one of the files with sub-par tags!
I can see the tags, but remember to think more dumb \ literally. A computer can’t really comprehend things. Algorithms are just pattern matching.
Track 11 is a match for Track 11. Title and Artists are matches. Time is close. But the album title uses different words, so failed the match. “La bamba: original motion picture soundtrack” is not an exact match to “La bamba soundtrack”. So the algorithm focused on the track number in preference.
Delete those bogus numbers and you’ll have a much better chance of good matches. I expect if the track 11 wasn’t there to mislead it then it would have got the right result here.
2 Likes
I was able to find this release in Picard with lookup, see:
Note the track length, my original length was way of because I just took a random file and just updated the tags to fake your search (I had no other file available quickly). So my search actually got a penalty for serious track length mismatch.
I had to tweak preferred release types like this for this to work:
So I completely turned off most types, added a big preference for albums, but kept single, EP, live and soundtrack. Single and EP I kept as this might be a good fallback if no album is found. And live and soundtrack are sometimes important secondary types, e.g. in this case we look for album + soundtrack.
I also lowered the threshold for file lookups in Options > Advanced > Matching from the default 70% to 60%, otherwise I got no match at all. But I think this was due to the track length mismatch penalty.
2 Likes
It’s not that I don’t find them. I’m finished now, using Picard and Google. The last one was the worst. Together, by Tierra, 1973. Phew.
There is definitely a legit problem here.
I can have a track that has a 100 match score within the “Search for similar tracks” dialogue (using the default search query), but the “Match” functionality says that there’s no match above the threshold. If I load the matching track from the “Search for similar tracks dialogue”, the only modified tag is Genre, which goes from null to having a value.
The default query was
track:(Lune) artist:(Tim Green) release:(Eastbound Silhouette) tnum:(4) tracks:(0) qdur:(283)
I tried playing around with the “Ignore tags” setting, ignoring everything except for track title and artist name, but this made no difference. The only way that I was able to get the track to match with the first 100 match score item listed in the “Search for similar tracks” dialogue was to reduce the threshold setting from 70% to 60%.
FWIW I have an example track that had the following fields matching exactly:
- Title (“Name” in the similar tracks dialogue)
- Length
- Artist
- Album (“Release” in the similar tracks dialogue)
Perhaps there is a mapping issue between Title>Name or Album>Release?
The only potential mismatch is the following field:
- Date (2022 in original tags, but 2022-10-28 in the similar tracks dialog)
Perhaps there is a match % issue with the date value?
The other tags that already existed on my track (that do not appear as columns in the “Search for similar tracks” dialogue) were:
- Track Number (set)
- AcousticID Fingerprint (set)
- Disc Number (set)
- Total Discs (set)
- Total Tracks (set)
Perhaps there is an issue whereby additional original fields reduce the match %?
The columns that appear in the similar tracks dialogue that weren’t already tags on my track were:
- Country (set)
- Type (null)
Perhaps there is an issue with null values, or Preferred Release Country/Type?
This issue has left me perplexed