I’m with you on this approach.
I wonder if a version of “credited as” named something like, but better than, “human readable code as printed on CA” could be included?
I’m with you on this approach.
That is an interesting approach, and useful if you could the query the CA. I understand the desire to be able to search on the printed barcode.
Note that this is not the situation we are discussing here. The situation with the printed version of the barcode being different than the machine readable is more like jesus2099 having a sticker on the shirt that reads “jesus209” (sorry @jesus2099, I don’t know who would do this ). You would probably then identify him as jesus209, but he would still be jesus2099.
But apart from that I agree that we should probably have both, the machine readable and the human readable as printed barcode.
I am not fully convinced by this argument. You can easily turn it around: If you change the barcode of the release to the printed version I can no longer find it with my scanned bar code. Only having both would IMHO solve this dilemma.
I think we have more people without barcode scanners than people with barcode scanners.
I don’t have one. Only my bare eyes (and glasses sometimes).
Until we can have several barcodes on a single release, I think we should keep the one that can be seen by the most people (printed).
Scanned barcode can be set on a pseudo release in the meantime… or in the annotation.
This specific issue does not necessarily require multiple barcodes. Just a checkbox “the printed numbers do not match the scanned value”, which when checked add another input box for the scanned value (based on the reasoning that scanning is rarer than reading) and only that one will need to be valid as upc/ean. This also keeps the two values semantically linked.
Excellent, those barcodes pairs.
But as we also need multiple barcodes for some releases, it could even be then, multiple barcodes pairs like this!
Except that, for MB, when jesus2099 has the 209 sticker on he is a different Release to when he has the 2099 sticker on.
Collapsing/normalizing away the distinguishing feature of a Release appears problematic.
Yes, exactly this is the problem when we don’t keep such distinguishing info as printed.
Yes, of course two separate releases with different barcodes printed on them would be different releases. But that’s not the case we are discussing here. The situation here is that a single release has a printed human readable barcode with digits being left out (usually the last digit, some labels also leave out a leading 0). This means the human readable version of the barcode is different from the barcode represented by the bars themselves. Essentially the very same physical release has two different representations of the same barcode printed on it.
There seem to be 4 things being discussed here.
The OP can’t enter non-standardized barcodes but used to be able to.
How to deal with discrepancies between the machine and human readable barcodes.
Whether either the machine or human readable barcode should take precedent over the other.
The possibility for confusion and the resulting creation of duplicate Release if the machine readable barcode is presented as “gospel” and db search results do not indicate to the searcher that the Release in hand is actually the same Release as the one in the db showing with a different barcode.
I’d say so. The multiple-barcodes is to me a different use case (mostly for the not uncommon case where every disc in a multi-disc release has its own barcode).
What do we do, then, when an edition prints the check digit and the other does not print it?
How does the second release will look different in MB if we force the check digits?
This is our case.
And this is our case because when it has an added digit, I don’t see my edition in MB, so I have to create it to complete my MB collection.
It’s been suggested a couple of times to add a note to the annotation for now.
It sure is better than nothing, of course, but let’s not forget that it’s neither seen from the release search, from the /release-group page nor from the /artist/releases page.
This is really a bug in MB.
My releases are edited progressively away of the printed barcode and I can do nothing against it as the guidelines say to favour machine read code over readable code.
Furthermore, releases are generally being altered their barcode without adding annotation that says this code is not visible on release.
In fact Zastai idea is very good.
And in the readable barcode we could even write the same spacing and lettering than prints, like 7777-91990-2 or T4988 012 20633 6, eliminating the need of inconsistent annotations.
This way not only we would get rid of this bug but we would even allow the improvement or the data.
If the only difference between the releases is the lack of a check digit, perhaps disambiguation would be appropriate. I’ve seen it used to indicated different barcode placement. There definitely should be two releases and with no other obvious differences, that is how I would do it.
So how often is this really an issue? how often are people finding broken bar codes they cannot enter?
I find the fact the check digit is required is very handy as it double checks for typos. No doubt it has improved the accuracy of this field over a free text box.
Maybe have an “override” tick box. Or “I know this isn’t a full barcode, but it is what is on the page” tick box for those few rare occasions where the barcode is incorrect on the artwork.
The barcode is just that, a barcode. That is, the pattern of bars and spaces printed on the release. It is not the human-readable printed next to it. Do you have any examples of a UPC/EAN barcode on a release that actually scans without a check digit? It is my understanding that this is impossible, it simply won’t scan.
I don’t care the scanned barcodes, I cannot scan, I only need the human readable text, that’s what says to me if it is my edition or another.
BTW, Discogs has it very simply:
Barcode (Printed): 7777-91990-2
Barcode (Scanned): 077779199020
It does not belong the annotation, it belongs an actual field like the scanned barcodes as it is more important than the scanned barcodes.
(they put it first, they also think it’s more important for humans)
And in the release group page, it’s the printed code that should be visible, the machine scan code has no reason to appear visually prominently as it is a hidden search hint for some guys with a scanner, so it should be only visible on release page.
It does already exist, it is what I used on my such releases.
But this option is useless if the fields says to ignore it and type the full invisible digits.