Label / catalog number pair already exists but cannot be found

I’m trying to tag “Retro 80’s” which is catalog number MUS2 51274 by Madacy and Warner Custom Products. Barcode 628261127429

Search Musicbrainz for any of that and no results. Try looking up single tracks by artist, track name, and track number, get millions of “hits”.

I have the original CD but looking up by disc ID also fails.

Try and import that and Musicbrainz says it already exists. Picard wants to scatter the tracks across a whole bunch of albums.

When adding a release says the label / catalog pair already exists, there needs to be a link to open that so that the user can click the Tagger button.

If anyone can excavate this release from the database I’ll have a disc ID and AcoustID to add to it.

Thank you.

1 Like

Just tried it. I think the error message is a bit confusing, and also a bit buggy. What’s that is telling you is that the same label / cat no. combination is already entered in the editor. I suppose you tried to import this via Discogs import script. In that case you probably see this:

grafik

That is because technically you have not yet selected a label, so the editor sees two entries with no label and the same cat. no. Once you have selected the labels this goes away:

grafik

If you’d add a duplicate again the warning would show up again:

grafik

Remember to cluster before lookup when trying to lookup albums.

4 Likes

You can add it, it’s not already in MB. :slight_smile:

2 Likes

That’s what it’s doing after clustering. Would be nice if Picard would include the number of tracks present when deciding which data to pull. When an album has been released several times with varying numbers of bonus or extra tracks it tends to either choose one with more or less than the number of tracks that have been clustered.

For example, 16 tracks in a cluster, all have exactly the same artist and album name, all data except track name and number identical, but Picard will either pull data for an older release with 14 tracks and ignore 15 and 16 or also pull the data for the 16 track release and put 15 and 16 there. Or if the rip is from the 14 track release it will only pull data for the 16 track version, leaving it “incomplete” - despite the data for the correct 14 track release being in the database.

If you look up a cluster Picard will load exactly one release, so it actually cannot distribute the files over mutliple releases. If that happens it means you looked up individual files.

When a cluster is looked up the number of tracks is one of the most important criteria by which the proper release gets selected.

1 Like

That is exactly NOT what it’s doing. Right now I have Best of Bobby Goldsboro Volume 1 and 2 clustered. Picard wants to scatter the tracks across seven albums, none of which are the ones the rips are from.

Edit: Now that I have imported these two from Discogs and submitted AcoustID, Picard should not get these discs wrong.

Sounds like you are trying with Scan (AcoustID fingerprinting) and not Lookup. Scan will indeed lookup recording individually based on their acoustic fingerprint.

Try with Lookup first, that looks up the cluster as a whole. And Check the settings in Options > Metadata > Preferred releases. If you are looking up compilations, but have a stong preference for albums set there results will probably be not the best.

If the release has not been in MB before it is rather unsurprising when Picard did not find it :slight_smile:

If Scan then gives you any better results depends, though. Acoustic fingerprint can identify the recording, on itself it cannot tell on which release that is. Hence Picard uses existing metadata and your preferred release type settings to choose between the releases containing an identified recording. Especially for compilations of popular artists the same recording likely appears on a multitude of often quite similar releases.

1 Like