If you use cluster and then lookup it should match to the release group in Picard. Then you are a single right click away from checking that it’s the right version.
It’s not as automated as we would all like, but let me stress that even if Picard did some extra wizardry with cat no’s from cue sheets I would still always check the versions for every album when tagging. There is no automated system or program that will be able to deal with the duplication of this data on popular albums, mistakes in printing or manufacturing, or errors by users who’ve entered the data into the database.
But anyway, that one click isn’t so bad, and as IvanDobsky said it definitely becomes part of the fun!
I don’t know enough about CUE sheet data etc, but it sounds like you have a pretty good grasp on it? Unlike other platforms here you are welcome to create a ticket outlining your proposal, or even code/get it coded yourself. It sounds interesting. Not sure if it’s off-topic I always thought pre-gap info would be interesting to store somewhere Maybe there’s a sensible place/way to store your info/strings in the DB (and then these can then be used by Picard). That said, I have to assume that if any of this is the killer app that would solve all tagging issues then it would be implemented already. Maybe there’s an existing ticket? The bug tracker is https://tickets.metabrainz.org
(I think this is where you would report documentation issues/suggestions as well?)
Take a bit to familiarize yourself first though. When you enter or edit a MB release the barcode field won’t let you enter dashes. It also automatically checks and recommends a checksum if you haven’t put that digit/s in (though you can click ‘my release doesn’t have this printed’ instead). I think that was a unanswered question if yours.
One of the reasons for jokingly mentioning Uden is that even with a catalogue number \ barcode match. And then narrowing down the text on the back of the case is England and not Australia. You then find that large releases are pressed in multiple plants across Europe over many years. And now you are focusing on the unreadable bits of scratched text on the inner ring of the CD.
Matching the catalogue number is only the start. I came here to just tag some files, and have ended up knowing so much more detail about the production of CDs than any sane person should need to know.
Just to add some information to this, because I can see the confusion:
The CD itself can contain the so called Media Catalog Number (MCN). This field is supposed to be filled with the EAN or UPC, which is an article number that usually is also present on the packaging in machine readable form as a barcode. This is what is supposed to go into the barcode field on MusicBrainz.
Not all CDs do contain the MCN. I don’t know any exact dates, but if you have CDs from the 1990s they pretty likely do not have this. Current CDs usually do have the MCN (if they have a barcode at all).
In your example the actual EAN is 0093624657729, that is what is encoded by the barcode and also what is present on the disc itself. Usually the number is also printed in human readable form below the actual barcode. Often it ads hyphens for readability, sometimes the last digit is omitted, as in your example with 09362-46577-2. The last digit is a checksum that can be calculated from the other digits and is used to verify whether the EAN / UPC has been read correctly and is valid.
MusicBrainz currently only stores the normalized version of the barcode, e.g. 0093624657729. I think there is an open ticket to allow to also store it as printed.
Ideally one would of course expect that the EAN / UPC that is read from the CD is identical to the one on the packaging. But that does not need to be so. E.g. sometimes the very same disc is made available in different packaging, e.g. there might be the standard version in a jewel case and a limited version which comes in a digipack with a bonus disc. But because the main CD is otherwise identical, they do a single pressing with a single EAN on the disc, but each edition gets a different EAN on the packaging. For MusicBrainz the barcode field should be filled with what is on the packaging (and this is also what the label and stores care about, because they need to differentiate the products).
As for the catalogue number field, that is something separate. This is supposed to hold the catalogue number as issued by the label or publisher. Like an EAN it is also a way to identify a specific product for stock keeping and sales, but it is internal to one company. Hence sometimes there are multiple catalogue numbers when multiple labels are involved. Usually the catalogue number is printed on the spine. Today labels deal differently with this:
Many use a number derived in some way from the EAN, e.g. this release has the catalogue number “9981592” and the EAN barcode 5051099815926 or this release has the catalogue number “NB 3797-2” and barcode 727361379728
Some have their own unique numbering scheme, e.g. this release has the catalogue number “CDMFN 152”
Some just use the EAN or actually don’t use a separate catalogue number at all anymore.
EAN/UPC are only around since sometime in the 1970s. So earlier releases won’t have a barcode. But they usually do have a catalogue number, because somehow the companies needed to do their stock keeping anyway.
A CD from a popular artist like Eric Clapton can be trickier to get an exact match on as so many editions will have been printed over the years. Discogs lists 17 variations of editions with that barcode
Understood, but even after ive picked the exact match released by Reprise Records, it is listed with Duck Records as well. I manually edit it…
Does your copy not have a duck to the right of the barcode?
That’s Clapton’s own label. So I would have thought the duck was hiding on your copy too?
But this is kinda the point. You find a good balance of matching that fits your need, and let the loonatics like us worry about which manufacturing plant the CD came from.
First, i checked a number of my cds for the catalog number read from the CD-TEXT section by EAC. My observation is that the inclusion of Catalogue number varies. It doesn’t appear to vary by age. All of my Coldplay cds have a catalogue number, but none of my Adeles. They cover the same range of years and are quite recent. None of my Springsteens have them. I’m not sure what the correlation is. It could be the record company or something else. However, the observation means that the idea of using the Catalog Number wont work,as there arent enough CDs with Catalog numbers, so apologies for dragging you down that rabbit hole!
It would be great to be able to use the barcode on the artwork, but that also wont work as shown by australian release of Clapton. It would narrow it down, but for it to work MB would need to store the exact match - 13 digits always with no dashes or spaces. I dont know how many entries are like this.
This is very likely. Some part of the manufacturing is choosing to add them or not.
an excuse to learn something new…
MB always drops the extra zero and strips the dashes. So 12 digits is what you’ll find and be able to match reliably.
Yes, barcodes narrow it down enough for the human eye to then make that last decision. If you know your CDs are generally USA releases, then you’ll have an answer for the majority of editions. And Barcodes are usually different either side of the pond.
If the main aim is accurate track lists, then barcodes and a guess on country will get you there.
If you know your CDs are generally USA releases, then you’ll have an answer for the majority of editions. And Barcodes are usually different either side of the pond.
Not so quick! …My U.S. release of Dire Straits, Brothers in Arms was manufactured for Warner Brothers by Polydor in West Germany. Same bar code.
Not many manufacturing plants were up and running back then… and yes it has the MCN filled in with full detail on each track including the Performer field on each track.
Understand that its deterministic, but i feel this is wrong and causes confusion. The bar code field should be exactly what the bar code reads as… ie 13 digits.
This is the history you’ll start learning for different eras of your collection. I guess there is an FBI stamp on the back of the artwork making it a USA version? Or a made in USA printed on the paperwork?
Bigger the band, bigger the release, the bigger the puzzle will be.
And talking of rabbit holes - Brothers in Arms also has the puzzle that the tracks on the CD are shorter edits than the vinyl. This is why that EAC log can be handy for the TOCs to get exact track time matches.
I think different scanner give different results as there are always two zeros up front (I think?). As the site is built around someone typing with CD case in hand this is why a standard 12 digit version is used. You could also argue that it is equally confusing to strip the dashes out when typed. The way things are implemented you have a happy middle ground.
You are talking to the wrong person about barcodes. Not really something I am that interested in. Just used to the mainly European disks I enter being dropped to 12 digits removing the extra zero. I guess those South African and Japanese example you have in the Brothers in Arms page are due to country differences. Other people are better experts. I have never had a problem with my disks and the way MB does things.
Are your lookups actually failing due to typing extra zeros? I’ll leave the barcodes to others now.
Bought my first CD player in 1988 meaning majority of my CDs are late 1980s and 1990s. So I am more interested in the manufacturing and details of SID codes. And the little differences on rear covers.
12 digits is a UPC code, the EAN is 13 digits. But you can take a 12 digits UPC, prepend a 0 and et voilà you got a valid EAN. Or the other way around: any 13 digit EAN with a leading zero is also a UPC if you strip the leading zero.
That’s why some barcode scanners will always read 13 digits in all cases.
I tried two apps on my phone they both return 13 digits with the leading 00s for the CD barcode.
on a box of granola, they return 13 digits beginning with a 5…
I get the logic of what people will type in, but keeping it simple and just storing the 13 digits seems the easiest way to do the match without any added logic. Maybe it should be a separate field.
It would be great to be able to use the barcode on the artwork, but that also wont work as shown by australian release of Clapton. It would narrow it down, but for it to work MB would need to store the exact match - 13 digits always with no dashes or spaces.
I don’t really get where the problem is. MusicBrainz does store the barcode without additional dashes or spaces. Being able to search for this is exactly the reason why this is done. If you use the barcode you got from the barcode scanner (which presumably is just exactly as it was read from the barcode) you should be able to do a search for this on MusicBrainz and find corresponding releases.
If you use an Android phone you can also use the MusicBrainz app to search for releases by barcode. Or you use my Picard Barcode Scanner app to search by barcode and load the result directly into Picard.
Maybe there’s a sensible place/way to store your info/strings in the DB (and then these can then be used by Picard). That said, I have to assume that if any of this is the killer app that would solve all tagging issues then it would be implemented already. Maybe there’s an existing ticket? The bug tracker is https://tickets.metabrainz.org
an excuse to learn something new… 
…My U.S. release of Dire Straits, Brothers in Arms was manufactured for Warner Brothers by Polydor in West Germany. Same bar code.