Is there a script to automatically add Relationships/Discogs based on Barcode?

Sometimes it happens that there is a Barcode on the release but no Relationships.

Example:

https://musicbrainz.org/release/1f127b0b-63c8-434e-bea3-d4def91dff01

Is it a good idea to automatically add a link to Discogs based on the Barcode?

  • Check history - anything that the original submitter says that can contradict the Discogs page?
  • Is everything on the MB page matching?
  • How many Discogs options are there?

This release looks pretty safe to link to the Discogs page. Everything matches.

You can’t “automatically” link as sometimes there are multiple releases to choose between.

3 Likes

That is, painstaking all the time. :wink:

In Poland we say “Benedictine work”.

Just realised you asked the question in the title. Don’t think there is a script. Personally I just add a Discogs Search to my browser so I can do a quick Right click \ search. Vivaldi browser has “Search With…” on the context menu making the lookup trivial to do.

A script is not going to work as on many occasions you will get multiple matches. Maybe a reissue, alternate manufacturers, different artwork and various other reasons.

And yes - quality work always takes time. Humans need to check the results otherwise we get a chaotic mess. Better to have no link than a bad link.

4 Likes

That’s true.
I can’t add anything.
EOT :wink:

1 Like

Ivan, just so everyone understands me correctly. :wink:

I can manually copy the Barcode, paste it into Discogs, choose the right release, copy and paste a link with “release” into MB.

That’s not a problem.

I thought that such a script could automatically fill the entire database. :wink:

And you usually can’t, because one barcode will often give you several Discogs releases.

Then I check the link with “master” and if possible country, year, etc.

But you know that. :wink:

Exactly - a human can look and check and make an intelligent decision.

A script cannot make that decision when you get a “One to Many” mapping like is often the case.

I thought we already established that in post number 2. :wink: