when I try to edit the barcode to UPC code with the check digit missing (and additionally checking the confirmation box “I confirm that this is the barcode as it appears on the release.”) the website will complain as soon as I enter the next page in the edit dialog. When going back to the previous page the confirmation box “I confirm that this is the barcode as it appears on the release.” is again UNSELECTED.
What has changed recently because it was possible before ?
If the check digit is not printed, it’s better to remove it.
Otherwise I or someone else with the release in hands will create a duplicate.
There is a ticket to allow multiple barcodes.
With this we could add the fake bar code (with check digit) in addition to the printed one.
No, that’s not correct. The printed barcode is the bar-code. If it scans as a full number with the check digit, that should be used, and that’s not fake, as per the guideline, linked above
A barcode/UPC or EAN is just that, it is an identifier and a searchable object like the discid, just because a lot of “packages” do not display the full barcode does not mean that you put apply a BOGUS barcode to a release. Cover art is a image and a completely different subject. If this database wishes to include “printed” barcode then create a field for it, please do not confuse people about what a barcode/UPC/EAN is .
I have seen annotations noting that the barcode digits as printed don’t match the scanned barcode, which seems like a good way to handle the discrepancy.
I have several CD’s like that, some weird scheme which I never bothered to wast my time looking up. There is a difference between the non-matching barcode and the missing check digit. I use a scanner and when it does not scan and I have to manually type it in I always run it against http://www.upcitemdb.com/ for the validation and a product match.
Then when I search for my release I don’t find it and I create a duplicate.
My eyes don’t include a bar code decoder, I always only read numbers.
Until the day we have multiple barcodes, we should store the only one that we can actually see, IMO.
To further jesus2099’s approach:
Different printed versions of a hypothesized single “idealized” barcode all qualify as separate Releases.
If the field was “EAN” or “UPC” then I can see the sense of normalizing the printed numbers. on the product.
However a barcode seems pretty obviously what is printed on the product.
As it is a typo on the cover I would stick with typing in the full barcode. With the added “9” on the end. If you don’t have your own barcode scanner to hand the Discogs link confirms the 9 on the end.
When you look at the cover image you can actually see where it has been badly cropped on the right of the barcode.
A “barcode” is the “code in the bars” and not the human readable bit underneath. I agree that the annotation field is the place to explain the discrepancies.
The last couple of albums I have added to MB have actually had multiple barcodes due to the way they were packaged. In those cases I used the annotations to point out the barcode discrepancies.
I have entered at least a dozen “releases” like that. In all cases the package had a barcode and the individual components had barcodes. I always use the package barcode because that is the “release” barcode not the individual parts of the release which is true to the way MB treats multiple medium releases. If I can prove the individual albums that make up the package were first released I enter the individual albums as a releases then the package as a release. It would be nice to have barcode and catalog entries for the mediums in the package.
Over the years many manufacturers have left off the check digit (right most digit) and sometimes the front leading “0” off the “printed barcode”. Maybe the problem with this discussion is the use of the word BARCODE which refers to many different schemes over its early years instead of UPC or EAN.
If MB intent is for the UPC/EAN then all instances of “barcode” (documentation, web, Picard) should be changed to UPC/EAN in order to clarify this. MB could also change the DB to allow for multiple “barcodes” (printed, scanned, user made up) as they do with the label catalog string.
If there is no firm direction here I fear edit/voting wars on the barcode.
I don’t agree. That will confuse things changing to an obscure TLA. Personally I have no idea what a “UPC/EAN” is. I believe more people would recognise it as a “barcode”. And as your Wiki example points out - barcodes are not human readable.
Keep the language closer to plain English and it is more likely people will supply the data.
Sorry, my apologies I assumed everyone knew that barcode we talk about is a code that represents a 12 digit UPC (Universal Product Code) or 13 digit EAN (European Article Number).
My point on documentation change was, if the term barcode means the printed numbers to people and not the numbers that the actual code represents then change the terminology to something more precise.
The numbers the barcode represents are “almost” useless without the check digit. You can paste the 12/13 digit barcode from your CD package into amazon search and it will give you the CD. I have used this many times to determine the correct amazon page to use for a release.
I always search the bar code as printed (I do not have laser eyes) and Amazon always recognise it.
A check digit is only a modulo, a formula that allows checking if you input an incorrect digit, it is just a checksum and not part of the actual reference/ID.
On the other hand, if someone changes my barcode to something invisible, I do not find my release any more, in MB.
If there was a jesus209 walking around that would be a different Release version to jesus2099.
Categorizing jesus209 as jesus2099 is going to create confusion.
