So I’m trying to rename and retag a CD, 100 Best Relaxing Classics, which I have on my disk sorted to subfolders CD1-6. I drag “100 Best Relaxing Classics” from the left field (file browser) to the center field (Unmatched Files), then find the release on browser and have “100 Best Relaxing Classics (0/100; 1 image)” in the right field.
Now if I click and drag the Unmatched Files on top of the right field, amazingly Picard will not match all of them, not even at 1% similarity setting, or 0%!
This seems to be due to some different tagging/naming convention on my files. How can I force Picard to overwrite the tags and names in a 1:1 fashion?
Each folder has exactly the same number and length of tracks as MB database, 100 Best Relaxing Classics .
I’m using the Tagger link from web because Lookup finds many irrelevant matches and is very slow even with Scanning off (one shouldn’t have to resort to such when there’s a ready match in MB database, right?!?), and after that I’m still stuck with this matching issue. All of this is just an example, I’d still have 10,000+ cd’s which need the same treatment, which is why this issue really makes me despair…it’s not feasible to do this with any amount of manual input.
Once you have your release clustered, try clicking on “Look up in Browser”. This has the side effect of a green tagger link next to releases. Once you do that the tagger link should appear on 100 Best Relaxing Classics, and clicking on that will load the release into Picard. From there you can drag the files to match them to what is in MusicBrainz.
Edit: Had to move the image because the local copy generated by the system doesn’t want to appear inline.
Well I tried to say that it does not match them. I drag my files from the center field onto the right field with MB data, and it does not match them up. Clustering just makes it worse, MUCH worse.
I don’t know what to say really, my collection is divided into CD# just like MB data shows for the release, yet it won’t match them up. I’ve tried with really tight match% (90%) and really loose or non-existent (0-10%) and always the same thing: after matching, there’s unmatched tracks left in the right field even after manually pruning the doubles (green and green or green and yellow squares).
I really don’t even need this “matching” stuff, I just want new tags to my files which are in exactly the same order as what MB finds for the release.
You can always manually drag a file to its Track entry in the right-hand pane do match them manually, you don’t need to have Picard do that for you. Also, instead of “pruning” (by which I believe you mean “deleting”) the red and yellow duplicates, move them to their proper track instead. Probably someone, at some point, submitted AcoustIDs for the wrong tracks, and thus a Scan operation gets confused. You may want to go to https://acoustid.org/ and unlink any badly linked AcoustID→Recording MBID entries.
I can’t say much about this without more details, but yes, it can happen that Picard is not able to match existing files to the proper track, even if you drag that that file to the release. That happens when the existing metadata is very different from what is on MusicBrainz and Picard lacks certainty to properly match the file. But without seeing the metadata I cannot tell you much more. Maybe you can manually drag an unmatched file to the proper track and post a screenshot of the metadata comparison?
You can manually drag the files to the correct track, but I understand that’s a tedious work for a hundred songs release. You can also try the scan option after you have loaded the proper release into Picard, sometimes this helps matching the files.
When tagging my collection extreme cases like this were really rare. Usually it matched all songs of a release, sometimes it could not match 1 or 2 files and put them under unmatched files of the release.
It seems that what I really needed to solve this was Foobar2000 with the foo_musicbrainz addon, it lets me select a MB id and overwrite the existing data 1:1 without any fuss. As a sidenote, Mp3tag refused to find any results.
Just wondering why Picard doesn’t offer similar functionality, like a forced match when amount of tracks, their numbering and lengths are equal. Because it truly seems that the matcher can get very confused sometimes, in this case it was about wrongly converted charsets which left a mess behind in the tags.
Maybe I don’t understand what you mean by “forced match”, but isn’t this exactly what happens when you drag a file to a Track in the right-hand pane? If not, it’d be far more helpful if you’d show us the metadata you’re giving to picard (eyeD3, ffprobe/avprobe, etc. should be able to dump this - upload this to a pastebin), since we’ve pretty much been as helpful as we can be without some concrete/specific data to work with.
I did just try to tag exactly same album and I didn’t have similar problems. Of course our tags and files aren’t identical but I can confirm that there’s correct fingerprints for all of these recordings.
Before you totally give up you should try this: instead of lookup use scan. Scan will most likely detects many incorrect releases but don’t care about that. After scanning has finished move all the files to correct release manually. Because of fingerprints Picard is now able to tell correct tracks.
Yes, that is exactly what happens, but dragging 100 files to each individual tracks is no fun. Actually often you don’t have to do this, just drag all files to the release. That’s what @k1976 did.
But Picard applies its usual matching heuristics, and if these fails the files will be placed in an unmatched files submenu below the release. So @k1976 is basically for a more dumb approach, were Picard will match the files e.g. just by track number, even if the rest of the metadata matches only poorly. Makes sense in some cases.
@k1976: I am currently not sure, but maybe lowering the matching thresholds in the advanced options would have helped.
I tried match thresholds down to 1% and 0%, it didn’t help.
I’m sorry @Freso but I don’t quite have the time to learn using debugging tools which I most probably won’t ever need again, since it seems I’m not the only one who knows that this kind of mismatch may indeed happen sometimes.
Yes, we know this can happen, and always will happen if there is just not enough existing information to do the matching. But since we know basically nothing about your existing tags I can’t say whether Picard could do better in this case.
Also the scan approach as described by @ListMyCDs.com and myself could have helped, as in many cases the audio fingerprint is the only information available.
A possible case would be when the ripping software only does freedb, doesn’t find the release and just uses track n as track name and "unknown"as artist.
Why then waste time setting better titles just to get picard to replace them with the fully-correct ones? The whole point would be to use picard to fix it.
And yes, while scan can then do wonders, that’s not always the case for compilations. So I do see the value in some option to enable looking only at track lengths (plus possibly disc/track numbers) when dropping a cluster on a release.
