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.