Verifying existing PUID <-> MB Unique ID match

[jdoering]

I’ve just started using this (great) tool. I’ve also read a bunch of the posts on here with regard to manual MB correction, etc. However, I can’t tell if there’s a supported way to do what I want (I don’t think there is).

I’m trying to verify existing tagged files with both PUIDs and MB Unique IDs. Because the Unique IDs may not have been written at the same time as the PUIDs; I want to know whether or not the mappings match MB data.

I don’t want to use the manual flow as that would require me to look at each record; I’m not interested in records where the mapping exists in MB.

I don’t think the automatic flow is doing what I want as I believe it is sometimes suggesting changes to the MB Unique IDs even when the mapping does exist (either because some other match criteria have a higher weighting due to factors other than the PUID or equal “100” ratings getting prioritized by order returned or something).

So basically I want to auto-flag all MB-ID<->PUID mappings that do not exist in MB without considering any other data about the track. I’d then perform manual MB correction on those tracks only (and possible end up submitting new mappings to MB in the process I believe).

Am I missing something that can be accomplished with current features?

One related feature I’d like is to be able to detect duplicates based on MB-ID+PUID; this would provide a little more assurance of true duplication for first-pass deletion. MB-ID duplicates with PUID mismatches would warrant a bit more inspection for incorrect MB-ID, etc.

-Jeff

[paultaylor]

[quote=jdoering]I’m trying to verify existing tagged files with both PUIDs and MB Unique IDs. Because the Unique IDs may not have been written at the same time as the PUIDs; I want to know whether or not the mappings match MB data.

So basically I want to auto-flag all MB-ID<->PUID mappings that do not exist in MB without considering any other data about the track. I’d then perform manual MB correction on those tracks only (and possible end up submitting new mappings to MB in the process I believe).
[/quote]
You cant verify existing MBID/PUID pairs (Ill add to wishlist), but if you are only using Jaikoz you can enable ‘MusicBrainz Settings\Auto Match\Do not match if dont have Acoustic Id’ to only correct tracks where a Puid is calculated and finds a match.

I don’t think the automatic flow is doing what I want as I believe it is sometimes suggesting changes to the MB Unique IDs even when the mapping does exist (either because some other match criteria have a higher weighting due to factors other than the PUID or equal “100” ratings getting prioritized by order returned or something).

When matching the Puid always take precedence over metadata, so if a Puid can be found AND it matches a MusicBrainz Id in the MB database then that is the record that will be selected. The only way an existing MB id would be replaced by another would be if the Puid matched multiple MusicBrainzIds - then it uses the metadata to try and find the best fit, is this what is happening. If you have already marked got a record with a MusicBrainz Id you can use the ‘MusicBrainz Settings\Manual Match\Do not match online if already have musicbrainz id’ option so that it will be ignored in subsequent corrects from muscbrainz.

[quote]
One related feature I’d like is to be able to detect duplicates based on MB-ID+PUID; this would provide a little more assurance of true duplication for first-pass deletion. MB-ID duplicates with PUID mismatches would warrant a bit more inspection for incorrect MB-ID, etc.
-Jeff[/quote]
I think you can do this, have you looked at the filters. ‘Action/Filter MusicBrainz Ids/Duplicate MuscBrainz Ids’ that would show only records where there was more than one record with the same MusicBrainz Id. You could also enable ‘Action/Filter MusicIP Acoustic Ids/Duplicate MuscIP Acoustic Ids’ then the only records that would be displayed would be ones with duplicates of both.

[jdoering]

Thanks for the feedback.

I may be over-thinking a corner case but the MB-ID+PUID duplication scenario I imagined was to distinguish the combined case from independent duplication of the individual tags. E.g.

File 1: ID = XYZ, PUID = 123
File 2: ID = ABC, PUID = 456
File 3: ID = XYZ, PUID = 789
File 4: ID = ABC, PUID = 345

Strange case; but I believe it’s possible in my collection to have two albums that should have a PUID-collision (because different albums had a duplicate song) but then I have MB-ID collision with non-matching PUID as well (duplicate song from same album but not really from same original so PUID mismatch).

This is different from MB-ID+PUID match which is very really strong indication of a duplicate with no need for additional checking before delete.

Again, yes probably a corner case - I can use the combined filter approach and manually check for the special-case of MB-ID+PUID matches.

-Jeff

[paultaylor]

[quote=jdoering]Thanks for the feedback.

I may be over-thinking a corner case but the MB-ID+PUID duplication scenario I imagined was to distinguish the combined case from independent duplication of the individual tags. E.g.

File 1: ID = XYZ, PUID = 123
File 2: ID = ABC, PUID = 456
File 3: ID = XYZ, PUID = 789
File 4: ID = ABC, PUID = 345

[/quote]

What about ‘Action/Filter MusicBrainz Ids/Duplicate MuscBrainz Ids’ ‘Action/Filter MusicIP Acoustic Ids/ MusicIP Acoustic Ids Exists’ combination instead ?

[jdoering]

That’s going to show me all four files. I should have given a more complete example:

File 1: ID = XYZ, PUID = 123
File 2: ID = ABC, PUID = 456
File 3: ID = XYZ, PUID = 789
File 4: ID = ABC, PUID = 345
File 5: ID = XYZ,PUID = 789

I want to only see Files 3 & 5; I’ll pretty blindly delete one of them. I want to look more closely at files 1,2, & 4 in a separate filtering pass since the difference in PUID<->MB-ID mapping warrants further investigation to account for possible earlier tagging mistakes, etc.

Yes, a corner case:) I did just create files with the pattern above and the combined use of both duplicate filters results in all five files being display. So the filters are consider independently as I expected.

-Jeff