Even if we store 077779199020 and on your release it is printed as 7777-91990-2 you can still easily see it’s representing the same barcode. Definitely no need to produce duplicates (at least not intentionally, can happen by mistake of course).
1 Like
This is not a duplicate.
Ask discogs why they store it, then.
If something we may not need to store, it’s the invisible machine code.
Maybe the scanned barcode could be automatically built and no need to store it in order to display it and to make it reachable by search but the readable code is important disambiguation stuff and no in a big release group, if I don’t see my printed bar code, I cannot decide which one my edition is.
I don’t know and don’t want to know the rules that I can add a zero at the end and/or at the beginning, etc. It is absolutely not intuitive.
It’s no different from Spotify/iTunes where they apparently have UPC/EAN codes which we store in the “barcode” field even though they are not directly visible accessible to the naked eye.
I don’t know what you mean @Hawke.
This topic is about seeing something on the release in hands and not seeing it on MB, thus creating a duplicate MB release.
Eh, my point was that it is not particularly unusual for MB to request/require data that is not immediately obvious to the naked eye.
I don’t mind that a hidden data (scanned barcode) is added to MB release (same as ISRC that’s only readable with some softwares). It’s great.
But the big problem here is that important release visible data is willingly hidden on MB.
OK, then I think we agree: the way I read it, seemed like you were advocating storing the human-readable UPC in the MB barcode field. This definitely makes sense as a separate field, IMO. (maybe some kind of “barcode variant”)
1 Like
Discogs does not assume one is more important, or even that there are exactly two. It allows for entering multiple barcodes, with optional descriptions for each. The ordering of fields within the “Barcode and Other Identifiers” section appears to be determined by the individual editor.
That approach is very flexible, but it does mean that some releases are tagged with “Barcode (printed)” and others as “Barcode (text)” or “Barcode (string)”…their guidelines suggest “Scanned” and “Text” for the cases we’re discussing.
4 Likes
I’ll also point out that you don’t need a scanner to read the encoded barcode. The distinctions between thin and thick lines are large enough that most people can read them if you really wanted to. It’s the decoding into the number that’s best done by a computer. I’ve been reading the circular barcodes on the bottom of some CDs that way, since I didn’t have any way to make my scanner track the curve. You can transcribe it into zeros and ones visually and then make the computer decode that into the actual values if you find or write the appropriate tool.
I don’t have a particular opinion about this disagreement one way or the other but the insistence that the barcode itself is somehow hidden or invisible is weird, it’s just encoded.
Not many people are able to read the Matrix, encoded, like you.
On an unrelated note, what do you do if the printed code is completely different from the scanned code?
For this release
I put what the online stores have used as the product code and what is seen from the Amazon cover image which is 4534530110923, but upon scanning the code it actually shows that the code encoded is 9537532770923.
How about this case? Unless it was an error.
You are mistaken… the barcode on this obi and the barcode on this interior are not 9537532770923.
4534530110923
9537532770923
1 Like
Re-scanning it now gives me the correct reading. I wonder what causes the misreading as I used the barcode scanner apps used by the MB apps and got the wrong value which was still a valid barcode nonetheless. Must have been because I scan it directly from the screen which might’ve caused some bars to appear thicker or thinner. Thanks anyway for correcting me.
You can get plenty of free apps in places like the Google Play store that will read barcodes.