• zin over 8 years ago

  • mirva over 8 years ago

    First, stripped of extra characters ≠ scanned.

    "Scanned" shouldn't be added unless the barcode has been actually scanned, IMVHO, since it indicates that a barcode scanner has been used. But - AFAIK, it's still ok to add the stripped version, just probably should be left without a description.

    And, if the barcode had been scanned, it would have 13 characters, not 12, 13 is the standard for EAN. ;)
  • uzumaki over 8 years ago

    I agree, as printed is the only version there is, the machine-readable version is in bars. Was discussed previously: http://www.discogs.com/help/forums/topic/209513
  • jweijde over 8 years ago

    I never understood the purpose of adding text and scanned barcodes.
    In my opinion the whole thing is ridiculous.
  • hafler3o over 8 years ago

    uzumaki
    as printed is the only version there is,

    +1
  • Myriad over 8 years ago


    mirva
    "Scanned" shouldn't be added unless the barcode has been actually scanned, IMVHO

    I agree. Claiming that you've scanned the barcode when you've just removed spaces/dashes is false and could be compromising database accuracy.
  • CyberFrog over 8 years ago

    jweijde
    I never understood the purpose of adding text and scanned barcodes.
    In my opinion the whole thing is ridiculous.

    I don't understand it, either.
  • Electro-Magnetic over 8 years ago

    I would like to get to the bottom of this too.

    Previously I used to only enter the printed version with spaces and dashes exactly how it appears on the release - which I always tried to enforce. But then we were told it's up to personal preference and a barcode without spaces cannot be replaced by a barcode with spaces and vice versa. It is acceptable to add both however.

    But now due to common entry of both ‘Printed’ and ‘Scanned’ by many other users (who don’t have a scanner - as in the OP’s example) I have also fallen into the practice of entering ‘Printed’ for as on release and ‘Scanned’ for barcodes without spaces and dashes, even though it hasn't been physically scanned with a scanning device.

    My question: What exactly is the correct description to use for entering the barcode without any spaces or dashes when it hasn’t been scanned by a scanning device?

    Barcode (Printed): 5 016025 612024 >
    Barcode (No Spaces): 5016025612024>
    Barcode (Scanned): 5016025612024

    or

    Barcode (Printed): 0 42281 42872 2
    Barcode (No Spaces): 042281428722
    Barcode (Scanned): 042281428722

    ?
  • rassel over 8 years ago

    We definitely need more possibilities to add Barcodes!
    Barcode (Printed): 5 016025 612024 >
    Barcode (No Spaces): 5016025612024>
    Barcode (Scanned): 5016025612024

    and
    Barcode (HEX): 48FE26CBEF8
    Barcode (BIN): 1001000111111100010011011001011111011111000
    Barcode (Rounded): 5016026000000
    Barcode (Random): 4702159304912
    Barcode (SQRT): 2168446.288

    :P
  • Staff 3.1k

    nik over 8 years ago

    jweijde
    I never understood the purpose of adding text and scanned barcodes.
    In my opinion the whole thing is ridiculous.


    CyberFrog
    I don't understand it, either.


    I don't see the problem in allowing different data sources to be entered if necessary. There is sometimes a discrepancy between the scanned and human readable codes, and that needs to be recorded.

    mirva
    "Scanned" shouldn't be added unless the barcode has been actually scanned, IMVHO, since it indicates that a barcode scanner has been used.


    That is correct, I have stated that on the release.

    Electro-Magnetic
    What exactly is the correct description to use for entering the barcode without any spaces or dashes when it hasn’t been scanned by a scanning device?


    Certainly not 'Scanned' for human readable code with the spaces and / or dashes removed. I'm not sure that all versions even need qualified in the description field.

    Barcode (As Printed): 5 016025 612024 >
    Barcode : 5016025612024>
    Barcode (Scanned): 5016025612024

    Note the guideline, however:

    5.2 Barcodes can be sourced from both the barcode text (the numbers printed below the barcode) or by reading the barcode itself with a barcode scanner. If there is a discrepancy between these two sources, both barcode variations can be entered into separate barcode fields.

    http://www.discogs.com/help/submission-guidelines-release-barcode.html
  • hafler3o over 8 years ago

    It is recommended to enter them without the spaces and dashes (for usability and searching), but the choice is exclusively up to the submitter. Ultimately, the barcode can be entered both ways on the same release, please do not delete one version in favour of the other.

    contradicts the 1st para. of 5.2.

    Why did you not just make the RSG
    "Barcodes can ONLY be sourced from the barcode text (the numbers printed below the barcode)".
    As I suggested long ago. END of story and ridiculous updates.
  • stalkism over 8 years ago

    ^^^^
    +∞
  • mirva over 8 years ago

    uzumaki
    as printed is the only version there is

    -1

    Some users have scanners, and are used to use them, so it should be allowed. We shouldn't disallow that just because some people are not aware of the guidelines.
  • LabelCollector over 8 years ago

    hafler3o
    "Barcodes can ONLY be sourced from the barcode text (the numbers printed below the barcode)".
    As I suggested long ago. END of story and ridiculous updates.

    Yes!

    mirva
    Some users have scanners, and are used to use them, so it should be allowed. We shouldn't disallow that just because some people are not aware of the guidelines.

    Let's draw the line at what is visible with the naked eye without having to use equipment.
  • mirva over 8 years ago

    LabelCollector
    Let's draw the line at what is visible with the naked eye without having to use equipment.

    1) You don't have to use any equipment, other than your eyes.
    2) You can enter the barcode as it is exactly printed, if that is your preference.

    So, where's the problem?
  • stalkism over 8 years ago

    the problem are pedantic and completely riciculous "updates" with fictionally scanned barcodes that are exactly the same as the printed one except for the blank spaces (as described above). if there are actual discrepancies between the scanned and printed barcode, it can still be entered as as that, other than that it's like adding notes that all song titles on a release are written in lower case.
  • Electro-Magnetic over 8 years ago

    As I didn't use an actual scanner I have removed 'Scanned' from the barcode description in my 5 recent submissions where I entered both 'Printed' and 'Scanned'. Example: http://www.discogs.com/history?release=2462787#latest

    But, from my next new submission onwards I will only add one barcode - as on release (including spaces and dashes) as I used to. Much simpler.

    And of course it's less "ridiculous", which is a favourite word on this thread today ;-)
  • cvalda44 over 8 years ago

    hafler3o
    "Barcodes can ONLY be sourced from the barcode text (the numbers printed below the barcode)".
    As I suggested long ago. END of story and ridiculous updates.

    Supported.
    Human barcode (printed version) should finally get priority and entered just as "Barcode".
    But if someone has a scanner (hey mirva!), allow to add it as well as Barcode (scanned)
  • Electro-Magnetic over 8 years ago

    stalkism
    the problem are pedantic and completely riciculous "updates" with fictionally scanned barcodes that are exactly the same as the printed one except for the blank spaces (as described above).

    Indeed, all of us have probably come across rankhunting-like edits to releases in our collections where the only change made by the user was to add a fictionally scanned barcode when the 'as on release' barcode was already entered. No doubt the majority of 'Barcode (Scanned)' entries in Discogs were made by fictional scanning.

    In many cases
    Barcode (Scanned): 042281428722
    should really be
    Barcode (Fictionally Scanned): 042281428722

    I'm really glad this thread was created and I was able to revert the fictional scanning I happened to enter on my last 5 submissions. It surely won't happen again.
  • mirva over 8 years ago

    stalkism
    the problem are pedantic and completely ridiculous "updates" with fictionally scanned barcodes that are exactly the same as the printed one except for the blank spaces (as described above).

    And it has been stated that this shouldn't be done. No scanner → you can't add the scanned barcode. Though, as I stated in my first post, stripped of extra characters ≠ scanned.

    And it's not the first time people are trying to falsify information here... though in this case I think it's more out of ignorance than anything. Just because someone doesn't know how things work shouldn't have an effect in how things actually work.
    Electro-Magnetic
    as on release (including spaces and dashes)

    Note that all, the scanned, the stripped barcode and the "as printed" barcode are as on release. ;)

    But all this has been discussed before, but I will repeat myself if necessary. ;) You have to remember that the rest of the world prefers the stripped barcodes, not even necessarily scanned. Most people also know that the spaces and the hyphens are just there to help with the reading, like training wheels help you when you're learning to ride the bike - but they are not actually part of the barcode, like the training wheels are not really part of the bike. But anyways.
    nik
    Barcode (As Printed): 5 016025 612024 >
    Barcode : 5016025612024>
    Barcode (Scanned): 5016025612024

    I like this, that is the way the are entered. But none of the three versions is really an incorrect form, though the undescribed and the scanned version are probably the most used versions. I think people should be allowed to enter the barcode in any correct manner, there's no reason to restrict it, IMHO.

    But - I have to say that I'm not a big fan of entering several version of the barcode, unless it's absolutely necessary. I'd think that in most cases only one version is enough.

    Isn't the guideline a bit contradictory in this matter though:
    RSG
    5.2 Barcodes can be sourced from both the barcode text (the numbers printed below the barcode) or by reading the barcode itself with a barcode scanner. If there is a discrepancy between these two sources, both barcode variations can be entered into separate barcode fields.

    Usually, the human readable code will include spaces, dashes, or other characters. These characters only serve to make the barcode easier to read, they are not necessary for computers to parse. It is recommended to enter them without the spaces and dashes (for usability and searching), but the choice is exclusively up to the submitter. Ultimately, the barcode can be entered both ways on the same release, please do not delete one version in favour of the other.

    I'd shorten the last sentence into "Please do not delete one version in favour of the other." Or is it intentional to allow several versions in general, or just when there's a discrepancy?

    (And cvalda44, I'm still waiting for the possibility to have the scanner implemented into my eyes, would make things so much easier! :))
  • Electro-Magnetic over 8 years ago

    Thanks mirva. Of course when I wrote "as on release" I should have written "as printed on release". Oh, and I like mine with training wheels! ;-)
  • ccj over 8 years ago

    Can I just say how confused I am as an average "non-barcode specialist" user.

    I go to a shop, either of two things happens:
    (A) Scanner working: they scan the barcode, then price comes-up.
    (B) Scanner NOT working: they type number under barcode, then price comes-up.

    ie.
    (A) -> the scanner reads a single line of numbers "1234567890"
    (B) -> the human reads a spaced line of numbers "1 2345 6789 0"

    Both are entered as a string, BUT, the barcode is printed for human readability; just with spaces/dashes/bracket-on-end.

    Can we not just enter them both ways and be done. Putting the word "Printed" next to the one that is as printed UNDER the striped barcode, that 99% of users can actually read as we don't have scanners.
    (with the ">" on the end of many gets entered on BOTH versions for simple-to-understandness)

    The reason for this as previously discussed is that each and every scanner can read the actual barcode in different ways ANYWAY. So having those with these devices enter some way it shows up on THEIR scanner can be wrong when you use another scanner. Hence avoids ambiguity as the number printed under the barcode is then ALWAYS used.

    In the *rare* instance that the number is not printed under the stripped barcode (usually some fancy design choice!), then it should be decided HOW the barcode is going to be read across ALL such releases —that do not have the numbers printed underneath— to avoid "my scanner shows a different number" ambiguity.
    _____________________
    This cuts the "I don't agree" arguments one way or another, and ends the endless crap of indecision and plain difficulty for most punters to understand, as the rules will be clear.
  • cvalda44 over 8 years ago

    mirva
    (And cvalda44, I'm still waiting for the possibility to have the scanner implemented into my eyes, would make things so much easier! :))

    I thought you have already did :) Good luck for the upgrade! :)
  • ccj over 8 years ago

    No answer on the "different scanners give different results" — as raised across forum threads on barcode understanding ?
  • mirva over 8 years ago

    ccj
    The reason for this as previously discussed is that each and every scanner can read the actual barcode in different ways ANYWAY.

    I'm not really sure what you mean by this. The scanner I have, and the scanners I have previously used at work (retail, storage + factory) have always read the barcode in the same way.
  • ccj over 8 years ago

    See first few posts here for starters: http://www.discogs.com/help/forums/topic/209513 (may be some more further down there too)
  • ccj over 8 years ago

    No answer?
  • mirva over 8 years ago

    Ah, that. That's not really different scanners reading the barcode in a different way, it's that the same scanner can be configured differently. But, tbh, I have never seen a barcode scanner configured differently, so I have no idea how common it is.

    (Btw, I participated in the thread as well, and there are other points to this discussion, as demonstrated in that thread.)

    I'm still not sure if it should have an effect on anything. I don't think banning scanners, or rather scanned barcodes, is a good solution. What's the big deal anyways, I've never really understood why people are so passionate about just having one version, especially since no variation is "more correct" than the other.
    cvalda44
    Good luck for the upgrade! :)

    Thanks, I'm just waiting for the technology to advance to the required level. It might take a couple of centuries, but I'm patient. :)
  • newmusicmark over 8 years ago

    1) Barcode is a visual image. So whatever is put there is an interpretation and not the actual barcode. That means all the entries are wrong in Discogs. The actual barcode is the image.

    2) Putting spaces and dashes is a waste of time. They don't mean anything so why list them? And how do you know it is only one space between the first two numbers? It's another interpretation.

    3) Scanning all the barcodes to find out if a release has a different barcode number than what is printed beneath the barcode image is also a waste of time. Do you know how often that happens? There are over 2 million releases in discogs. Less than 1 percent would still be 20,000 entries. I'd say it is less than 2,000. So why bother with that? Even if they did differ, what use is it; what would you do with that info? More likely you will find barcodes that don't scan because the graphic designer thought it would be cool to do the barcode in color or invert the black and white bars (which doesn't work).

    I'm for putting the whole barcode number without spaces. All extra work should be concentrated to Discog's main purpose, adding release and adding the credits. That is the incredibly useful and what I love about Discogs! :)
  • mirva over 8 years ago

    Well said. :)
  • cvalda44 over 8 years ago

    newmusicmark
    Putting spaces and dashes is a waste of time. They don't mean anything so why list them?

    What about "as on release" thing ? We represent all other identifiers exactly as on release, even more, an extra space in the Cat# may be interpreted as Cat# variation. The human barcode - a string of symbols - is also an identifier and should be entered exactly as it appears. The machine barcode is another identifier read from the visual image.
  • LabelCollector over 8 years ago

    Yippie, there is an extra number in the scanned barcode compared to the text version! And how am I supposed to vote correct on a scanned barcode when I don't have a scanner?

    What is next? Someone adds encriptions to the run out groove etchings no one else can see because he has a very special electron microscope?

    I'm against using equipment that only a few have. Use your eyes instead.
  • ccj over 8 years ago

    You haven't thought that point of view through... What about barcodes *without* numbers underneath?
  • ccj over 8 years ago

    ccj edited over 8 years ago
    mirva
    Ah, that. That's not really different scanners reading the barcode in a different way, it's that the same scanner can be configured differently. But, tbh, I have never seen a barcode scanner configured differently, so I have no idea how common it is.

    (Btw, I participated in the thread as well, and there are other points to this discussion, as demonstrated in that thread.)

    I'm still not sure if it should have an effect on anything. I don't think banning scanners, or rather scanned barcodes, is a good solution. What's the big deal anyways, I've never really understood why people are so passionate about just having one version, especially since no variation is "more correct" than the other.
    newmusicmark
    1) Barcode is a visual image. So whatever is put there is an interpretation and not the actual barcode. That means all the entries are wrong in Discogs. The actual barcode is the image.

    2) Putting spaces and dashes is a waste of time. They don't mean anything so why list them? And how do you know it is only one space between the first two numbers? It's another interpretation.

    3) Scanning all the barcodes to find out if a release has a different barcode number than what is printed beneath the barcode image is also a waste of time. Do you know how often that happens? There are over 2 million releases in discogs. Less than 1 percent would still be 20,000 entries. I'd say it is less than 2,000. So why bother with that? Even if they did differ, what use is it; what would you do with that info? More likely you will find barcodes that don't scan because the graphic designer thought it would be cool to do the barcode in color or invert the black and white bars (which doesn't work).

    I'm for putting the whole barcode number without spaces. All extra work should be concentrated to Discog's main purpose, adding release and adding the credits. That is the incredibly useful and what I love about Discogs! :)
    cvalda44
    What about "as on release" thing ? We represent all other identifiers exactly as on release, even more, an extra space in the Cat# may be interpreted as Cat# variation. The human barcode - a string of symbols - is also an identifier and should be entered exactly as it appears. The machine barcode is another identifier read from the visual image.


    So there we have it, several points of view that mostly contradict one another... not very useful getting to a conclusion.
    And the RSG on top, that does NOT draw together any clear conclusions on the topic; unhelpfully for most users to get to grips with without having to "interpret" them heavily. This means that different users are "interpreting" them, when submitting AND (just as crucially) voting on them.
    _____________________

    These are most of the key points I can draw together:
    (A) how barcode appears in human readable form on release (ie. the under the stripe numbers/characters)
    (B) how barcodes are read by scanners (ie. the stripes)
    (C) how internet (eg. Google)/other apps (eg. smart phone apps) search and display such barcodes
    (D) ease of barcode data-entry for users
    (E) ease of users understanding the RSG rules on data-entry of barcodes

    Additional points:
    (F) issue: barcodes without human readable line — entered how?
    (G) issue: additional non-number characters & entering them
    (H) KEEPING *EVERYONE* REASONABLY HAPPY, by everyone compromising on what they want!!

    Answers (using examples) to add to clarify in the RSG:

    (1) number *without* spaces or non-number characters:
    - enter the number without any spaces on the release, with "Text" as descriptor, eg. 0123456790 (Text)

    Reasoning: it's "text as printed on release" by human reading, is easily searchable on Discogs/Google, no spaces appear so none need or can to be entered.

    (2) number *with* spaces or non-number characters:
    - enter the number with the spaces/chars on the release, with "Text" as descriptor, eg. 0 12-34-5679 0> (Text)
    - also enter without the spaces or other chars, with "String" as descriptor, eg. 0123456790 (String)

    Reasoning: both "text as printed on release" by human reading and string, thus easily searchable under both terms on Discogs/Google, spaces & chars appear on a version so should be reflected on a version for possible release identification by users.

    (3) number *without* spaces or non-number characters, though different number appears when manually scanned:
    - enter the number without any spaces on the release, with "Text" as descriptor, eg. 0123456790 (Text)
    - also enter the scan result (always without the spaces), with "Scan" as descriptor, eg. 0123456793 (Scan)

    Reasoning: both "text as printed on release by human reading" & string by human reading and scanned different version, thus easily searchable under both terms on Discogs/Google, no spaces & chars appear so none need or can to be entered.
    (note: if a > is on the barcode, add it under Text version.)

    (4) number *with* spaces or non-number characters, though different number appears when manually scanned:
    - enter the number with the spaces/chars on the release, with "Text" as descriptor, eg. 0 12-34-5679 0> (Text)
    - also enter without the spaces or other chars, with "String" as descriptor, eg. 0123456790 (String)
    - also enter the scan result (always without the spaces), with "Scan" as descriptor, eg. 0123456793 (Scan)

    Reasoning: all appear, with "text as printed on release" by human reading and string and scanned, thus easily searchable under all terms on Discogs/Google, spaces & chars appear on a version so should be reflected on a version for release identification by users.

    (5) barcode appears as stripe with NO number underneath:
    - users with barcode scanners can read and enter the scan result (always without the spaces), with "Scan" as descriptor, eg. 0123456790 (Scan)

    Reasoning: no "text as printed on release" by human reading, thus can be searchable under the scanned string on Discogs/Google, scanners have no spaces & chars so none need or can to be entered.

    Additional note:
    Sometimes the graphic designer on a release can use fake barcode on the artwork of a release (either just bars or with numbers). These may or may not be readable visually by human eye or by a scanner, but in most circumstances should not be entered in the BAOI fields, though can be added to the release notes.


    This I believe allows for ALL relevant points of views on the topic, WITHOUT bias for one or another. Clearly any RSG update would be without my reasoning parts above, but the other parts could very easily be used to get rid of user doubts in the RSG.
    Views please...?

  • zevulon over 8 years ago

    I couldn't even bother to read all this nonsense.

    There are several barcode scanner apps/programs "out there" for mobiles/PCs etc.
    Do use any of these, and Scanned will be correct, that's what I do.

    Short version: A "barcode" that isn't in a consecutive row of numbers is not a barcode, it's just an artwork interpretation of the barcode.

    However - an artwork barcode can be handy because:
    1. People perceive it as a barcode out of lack of knowledge
    2. It can actually point out a difference to other editions of a release with the same barcode (re-releases - I've stumbled upon one example recently)

    Again,
    A barcode is a standard that was constructed OUTSIDE of Discogs, hence "as on release" does NOT comply, and if altered, it ceases to be a barcode
  • ccj over 8 years ago

    ccj edited over 8 years ago
    @ Zevulon, that's EXACTLY the reason for having what I put above!

    Everyone has there OWN POINT OF VIEW and there are SEVERAL ISSUES with one way or another. Hence my clear reasoning above, if you bother to read the bottom half properly before making the same comment.
  • hafler3o over 8 years ago

    ccj
    What about barcodes *without* numbers underneath?

    lol! We can get them where we get the ASIN from ;) (that's a bit tongue in cheek)

    In honesty, your post above pretty much encapsulates where we are, the barcode string (or rope) is long enough to have us all in knots. Which is why I'm all in favour of as few actual guidelines (ie. keeping things restrictive on how we enter and where the information comes from).

    Unfortunately this does not give Joe Average his 'feel good factor' on the database, nor does it sit well with the demands of the marketplace, every possible permutation of barcode/label/company needs to be entered onto a release in order for Discogs to effectively climb to the top of the Google search results, and sod other considerations (considerations is synonymous with contributors / divide & conquer)!
  • Staff 3.1k

    nik over 8 years ago

    hafler3o
    It is recommended to enter them without the spaces and dashes (for usability and searching), but the choice is exclusively up to the submitter. Ultimately, the barcode can be entered both ways on the same release, please do not delete one version in favour of the other.

    contradicts the 1st para. of 5.2.


    mirva
    Isn't the guideline a bit contradictory in this matter though:

    I'd shorten the last sentence into "Please do not delete one version in favour of the other." Or is it intentional to allow several versions in general, or just when there's a discrepancy?


    5.2 Barcodes can be sourced from both the barcode text (the numbers printed below the barcode) or by reading the barcode itself with a barcode scanner. If there is a discrepancy between these two sources, both barcode variations can be entered into separate barcode fields.

    Usually, the human readable code will include spaces, dashes, or other characters. These characters only serve to make the barcode easier to read, they are not necessary for computers to parse. It is recommended to enter them without the spaces and dashes (for usability and searching), but the choice is exclusively up to the submitter. Ultimately, the barcode can be entered both ways on the same release, please do not delete one version in favour of the other.


    "Both ways" refers to the entering of the human readable barcode.

    "If there is a discrepancy between these two sources, both barcode variations can be entered into separate barcode fields" refers to the scanned barcode versus the human readable one.

    newmusicmark
    Putting spaces and dashes is a waste of time. They don't mean anything so why list them? And how do you know it is only one space between the first two numbers? It's another interpretation.


    This was allowed for two reasons:

    1. Some users may find it easier to enter the data that way, and cause less errors.

    2, The string may be easier to find using various search terms, methods, and engines.

    newmusicmark
    Scanning all the barcodes to find out if a release has a different barcode number than what is printed beneath the barcode image is also a waste of time. Do you know how often that happens? There are over 2 million releases in discogs. Less than 1 percent would still be 20,000 entries. I'd say it is less than 2,000. So why bother with that? Even if they did differ, what use is it; what would you do with that info?


    This is obviously useful information if someone is searching for one version of the barcode, and the release does have both versions, then the release will be found. If there is only one version, then the release may not be found. I don';t understand why it would not be advantageous to catalog both versions of the barcode, even if this is a one in a million occurrence.

    ccj
    the RSG on top, that does NOT draw together any clear conclusions on the topic; unhelpfully for most users to get to grips with without having to "interpret" them heavily. This means that different users are "interpreting" them, when submitting AND (just as crucially) voting on them.


    I don't understand where any ambiguity comes from, the guidelines were written after quite a bit of discussion, to cover all bases in as compact a form as possible;

    Barcodes can be sourced from both the barcode text (the numbers printed below the barcode) or by reading the barcode itself with a barcode scanner. If there is a discrepancy between these two sources, both barcode variations can be entered into separate barcode fields.


    That seems clear, is there any possible way to state that in a clearer manner?

    Usually, the human readable code will include spaces, dashes, or other characters. These characters only serve to make the barcode easier to read, they are not necessary for computers to parse. It is recommended to enter them without the spaces and dashes (for usability and searching), but the choice is exclusively up to the submitter. Ultimately, the barcode can be entered both ways on the same release, please do not delete one version in favour of the other.


    This deals with only the human readable part of the barcode. Again, this was written after a lot of discussion. It seems clear to me, although I can see if someone just scanned over it (pun not intended), they may misunderstand it.

    The 'Description' field can be used to indicate the source of the barcode, for example "Scanned" and "Text". In the case of multiple barcodes on a release, they can all be entered in separate barcode fields - please use the 'Description' field to provide any further information, if possible.


    That is the final paragraph, and again seems clear enough.

    If there are problems, I think it is more down to people not reading / understanding the guidelines properly, than any inherent fault in the guidelines themselves. Still, if anyone can think of improvements to the text (that keep the same meaning), then we can look into that.
  • mirva over 8 years ago

    nik
    "Both ways" refers to the entering of the human readable barcode.

    "If there is a discrepancy between these two sources, both barcode variations can be entered into separate barcode fields" refers to the scanned barcode versus the human readable one.

    Ah, then I have misunderstood the guideline, it seems. So:
    1) it's always allowed to enter both versions of the human readable barcode (the version with hyphens/spaces, and the stripped version), and
    2) it's allowed to enter both the human readable and scanned one when there's a discrepancy between the two; when there's no discrepancy you can only add either or, but not both?

    That's what the guideline says, no? And, doesn't that lead to a situation where when you add the scanned barcode, and there's no discrepancy, you can't add the human readable one, and vice versa? Or is it just too early?
  • hafler3o over 8 years ago

    mirva
    Ah, then I have misunderstood the guideline, it seems.

    Me too, although it's not so early here!

    Add what a scanner says (as 'Scanned') - fine.

    Add the barcode as presented on the release to human (non scanner modified) eyes (as 'Printed') - fine.

    Now adding a version of the barcode with the spaces/dots/slashes/colons stripped out by humans if the spaces/dots/slashes/colons appear (as they mostly do); why we need to do that? It's like mucking around with the cat#s all over again (and we add the cat# from the release not from the label press sheet). Ok we allow it to be done but if we don't stop it how should we document it? 'Compacted'? 'Spaces removed'? 'Shortform'? All pretty rubbish, someone think of something better please...
  • mirva over 8 years ago

    hafler3o
    Now adding a version of the barcode with the spaces stripped out by humans, if the spaces/dots/slashes/colons appear (as they mostly do); why we need to do that

    Well, my question would be exactly the opposite, why would we need to add the spaces and hyphens, since it's known that they are not part of the barcode? ;)
  • ahlbomper over 8 years ago

    mirva
    why would we need to add the spaces and hyphens, since it's known that they are not part of the barcode?

    if the human readable code contains spaces i think it's natural to enter it with spaces, so it looks (more or less) as on release.

    if the spaces are there to be seen, they are there to be seen.
  • zin over 8 years ago

    IMO all we need in the guidelines is: enter the barcode "as printed on release", that's it, why make our lives more difficult ? Obviously scanned version MAY be added, providing one OWNS a scanner and can check it.
  • hafler3o over 8 years ago


    zin
    "as printed on release"

    exactement! cat#s as found, barcodes as found etc, as few exceptions to this as possible makes data entry & checking easy and lightens the RSG.
  • DaveRowat over 8 years ago

    zin
    IMO all we need in the guidelines is: enter the barcode "as printed on release", that's it, why make our lives more difficult ? Obviously scanned version MAY be added, providing one OWNS a scanner and can check it.

    I'm not sure why this isn't the rules, given the spirit of many other aspects of the site... :)

    I understand the desire to write what appears in print below the barcode, and I understand the desire to enter in what the scanner actually reads, but I'm not sure I understand the benefit to adding in the stripped down single string version if it is not necessarily the actual scanned version (though, I am at work and I haven't a chance to really go through this entire thread in detail). Isn't it really a fabrication since we can't guarantee it is the same as the actual scanned version unless we have a scanner? (apart from future mirva with her barcode scanning eyes)

    If we are anticipating that people will search using the stripped down version, then why can't there just be a "shadow" barcode that always strips away the extras for searching purposes but isn't required to actually type in. That way, everyone can just enter it how it appears to the human eye (with the spaces and/or dashes), and those who search for the string will still find it. In fact, I thought there already was some sort of shadow barcode system in place anyways...
  • ahlbomper over 8 years ago

    zin
    IMO all we need in the guidelines is: enter the barcode "as printed on release", that's it, why make our lives more difficult ? Obviously scanned version MAY be added, providing one OWNS a scanner and can check it.

    exactly the way i see it.
  • plastiq over 8 years ago

    ccj
    as an average "non-barcode specialist" user

    (and probably in the vast majority of users)
    zin
    all we need in the guidelines is: enter the barcode "as printed on release", that's it

    Yes
  • mirva over 8 years ago

    zin
    IMO all we need in the guidelines is: enter the barcode "as printed on release"

    Yes, if this still allows users to strip the hyphens and spaces that are not part of the barcode.

    Otherwise, no. Why? For the reasons stated in this thread, and in the previous threads.
    DaveRowat
    In fact, I thought there already was some sort of shadow barcode system in place anyways...

    Nope. These search results still apply, more or less: http://www.discogs.com/help/forums/topic/209513#2605018

    IMHO, it's should be possible to be able to find the release with any search engine (especially since the Discogs engine isn't the best one), and with any variation. How it should be done, well, don't ask me.

    Catalog numbers are different from barcodes, since the hyphens, spaces and whatever characters there are, are usually actually part of the catalog number, they are definitely not there to make the typing and reading of, for example, "BS-77" easier.
  • DaveRowat over 8 years ago

    mirva
    Nope. These search results still apply, more or less: http://www.discogs.com/help/fo...topic/209513#2605018

    Ah yes, I remember that thread and that test :)

    I just did a quick Discogs only search:
    Matthew Sweet - In Reverse (which has the barcode printed as it appears)
    1. Discogs search as it appears: no results (hmmm, that is unfortunate)
    2. Discogs search as one string: 1 result, the exact one.

    ...and I was confused when I saw the single string in the search result under #2, but not on the actual release page (I don't think). There needs to be some tweaking to make things more "searchable" for sure.
    mirva
    IMHO, it's should be possible to be able to find the release with any search engine (especially since the Discogs engine isn't the best one), and with any variation. How it should be done, well, don't ask me.

    Absolutely agree.
    mirva
    Catalog numbers are different from barcodes, since the hyphens, spaces and whatever characters there are, are usually actually part of the catalog number, they are definitely not there to make the typing and reading of, for example, "BS-77" easier.

    Well, yes, they are definitely different. I was just suggesting that there is a system already implemented with cat#s that could possibly be easily adapted here, if deemed useful.

    Anyways, apart from aiding the search function, I understand the importance of entering the string of numbers as one.

    I mean, I'm kinda playing devils advocate here, but for the Barcode field to literally be a correct presentation of the barcode, we would have to "type in" a bunch of lines and spaces that we can't do. It seems the two logical options are to type in either (or both):
    1) the numbers that those lines and spaces represent and are read by a barcode scanner, or
    2) the notation of the barcode placed by the manufacturer/label/whoever right below it, which I hope everyone can agree is at least related to the barcode.

    But, with the understanding that a "stripped" version of the notated barcode is not always as simple as just "removing the dashes and spaces", then why enter in a single string if it hasn't been at least confirmed via scanning?

    If the goal is to aide in the searching function (which IS an important goal) then shouldn't we be fixing the search engine instead of entering in "made up" numbers? I just think that if each page had the barcode represented by #2 above, then the shadow system could also have the single string version embedded in the release page to aide in searching (I know very little about programming, but I think this is something that is possible, and perhaps even quite common around the Interwebz, no?)

    And while this is really nit-picky, the dashes and spaces ARE important as visual cues on the printed sleeves that could possible tell us something about the release (not sure what though :)

    Anyways, if there is another reason for preferring "one string" numbers that aren't derived from a scanner that I missed, then I apologize. When I get home from work, I will take a more detailed read through the thread.

    :)
  • mirva over 8 years ago

    DaveRowat
    But, with the understanding that a "stripped" version of the notated barcode is not always as simple as just "removing the dashes and spaces", then why enter in a single string if it hasn't been at least confirmed via scanning?

    Why then enter it at all if hasn't been confirmed via scanning? ;) I mean if it's missing a digit, it's missing a digit from all the human readable versions. And, again, the hyphens and spaces do not mean anything.

    Usually the missing number from the printed text is either the check digit or the leading zero, when it comes to EANs. But these are not usually required when typing in the code manually, they are both somewhat redundant, and the systems are usually smart enough. Like the release that is mentioned in the first post, the full 13-digit EAN is 0724388380621, the first zero is missing from the human readable form.

    There are ways to learn to spot these, and some people say you can even learn to calculate the check digit in your head. My head is not capable of doing this yet though, it will be included in the forthcoming upgrade.
    DaveRowat
    And while this is really nit-picky, the dashes and spaces ARE important as visual cues on the printed sleeves that could possible tell us something about the release (not sure what though :)

    XD
    DaveRowat
    I just did a quick Discogs only search:
    Matthew Sweet - In Reverse (which has the barcode printed as it appears)
    1. Discogs search as it appears: no results (hmmm, that is unfortunate)
    2. Discogs search as one string: 1 result, the exact one.

    And:
    3. Google search, with decorations: no results
    4. Google search, without decorations: 105 results, no Discogs - the search results consists of several online record stores, and a UPC database
  • ccj over 8 years ago

    ccj edited over 8 years ago
    After all this, one question we all have for Nik then...
    Is there a shadow system planned for barcodes or can one possibly be implemented?

    As it keeps both camps happy, due to string entry being nik "easier to find using various search terms, methods, and engines":

    Mirva happy:
    • as single string search works when searching on Discogs and most other engines ( mirva "Google search, without decorations: 105 results, no Discogs - the search results consists of several online record stores"). Google engine's repeated re-caching Discogs pages will fix missing string searches.
    • plus an additional scanned string allowed to be entered, if different.

    DaveRowat happy:
    • as spaced entry can appear on release page as printed on release ( nik "Some users may find it easier to enter the data that way, and cause less errors").
    • plus shadow string works when searching on Discogs and most other engines.

    So spaced/non-spaced "number under barcode as appears on release" version is the only version needed to be added, and ALL search results work.

    In addition also:
    • either improve the Discogs search engine to find the spaced version of a barcode.
    • or add a note in the BAOI RSG section saying "when searching using barcode, entering the number as a single string gets best results", or similar.

    ^^^ And his answer to any of the above (if he were to answer), I'm sure would be: NO ^^^^
    _________________________________________________________________________

    So this leaves us with this, as a clarification of the RSG (as current RSG is lacking dealing with these search concerns):
    Main Rule:
    (1) number *without* spaces or non-number characters in middle (eg. 0123456790 or 0123456790>):
    - enter the number without any spaces on the release, with "Text" as descriptor, eg's. 0123456790 (Text) or 0123456790> (Text)

    (2) number *with* spaces or non-number characters (eg. 0 12-34-5679 0>):
    - enter the number with the spaces/chars on the release, with "Text" as descriptor, eg. 0 12-34-5679 0> (Text)
    - also enter without the spaces or other chars, with "String" as descriptor, eg. 0123456790 (String)

    Additional Rules:
    (3) in addition to main rule (1) and (2) above, for users with scanners, if a different number appears when manually scanned:
    - also enter the scan result (always without the spaces), with "Scan" as descriptor, eg. 0123456793 (Scan)

    (4) barcode appears as stripe with NO number underneath:
    - users with barcode scanners can read and enter the scan result (always without the spaces), with "Scan" as descriptor, eg. 0123456790 (Scan)

    (5) fake barcodes:
    Sometimes the graphic designer on a release can use fake barcode(s) on the release artwork (bars, with or without numbers). These may or may not be readable visually by human eye or by a scanner, but in most circumstances should not be entered in the barcode fields, though can be added to the release notes.

  • blach over 8 years ago

    The above may seem a good idea. It even might make the Guidelines some day. And from that day it will set the standard for new submissions. However making updates like http://www.discogs.com/history?release=55410#latest on other users submissions without adding anything new of value - just re-arranging existing data - and resulting in "Recent changes affecting releases in your Discogs collection" notifications to potentially 28 owners, - well to me that is SPAM.

    stalkism
    the problem are pedantic and completely riciculous "updates"


    Guidelines
    10.1.7. Please don't edit releases to move about credits between sections because of personal preferences, as this can lead to errors being introduced.


  • ccj over 8 years ago

    Both points discussed endlessly.

    re. removal of needless info.
    For example, "Label Code, on CD and Backcover", the "on CD and Backcover" part is redundant as it's the same all over the release.
    If it was different on the CD and the backcover, then doing so would be fine. Remember there is the pix option if a user wants to have a look at where such details are printed on a release.

    re. barcodes &, so-called, needless edits.
    If you read the thread above, there are search parameters effecting why this is done, plus the "what about the text numbers AS PRINTED ON RELEASE" arguments, plus the "what if the scan is completely different" arguments. Hence such dual BC terms being done.

    If someone wants to edit something to improve the data, then unfortunately it's tough luck on the email front, which we all know is a pain but can't be changed; you either opt in for emails or don't.
    There is no "this is a big edit" email, "this is a small edit" email, option on receiving them. Your only option if you don't like the emails, is to turn them off.
  • Staff 3.1k

    nik over 8 years ago

    ccj
    Is there a shadow system planned for barcodes


    No

    ccj
    can one possibly be implemented?


    It could be, but there are, as usual, masses of things to do with the site, this doesn't strike me as urgent.

    ccj
    enter the number without any spaces on the release, with "Text" as descriptor


    ccj
    enter without the spaces or other chars, with "String" as descriptor


    I don't think it is really necessary. It is ok to add' Scan' as the descriptor to a scanned barcode, but I think we can assume hat the majority of barcodes will be entered from the human readable text portion.

  • ccj over 8 years ago

    nik
    I don't think it is really necessary. It is ok to add' Scan' as the descriptor to a scanned barcode, but I think we can assume hat the majority of barcodes will be entered from the human readable text portion.

    Yeah, but as explained, if you don't add "String" then many users will get confused as to whether a single line of numbers should have "Text" or nothing next to them. That's why I wrote them that way above, so there is no ambiguity as to source or entry method for users.
    (Remember it's got to be easily understood by the general "non barcode expert" users with as little ambiguity as possible, lol ;-)

  • Marana over 8 years ago

    My 2 cents for the topic after scrolling it through..

    I agree with the things ccj said/suggested.
    I'd enter all the 3 versions of barcodes (or more, if there exists more),
    but if they are consistent with one-another, combine the descriptions into a single barcode entry..
    For example if the scanned barcode is the same as the stripped barcode, use both (Scan/String) in the description. And add the barcode with spaces to it's own barcode field with (Text) description.
    This removes the doubt, if the entered barcode is the only variation, versus it been entered only as Barcode, without description.

    The bottom line is, that all 3 versions are well justified, so none of them should be ruled out. We only need to conclude, how to present them.
    ccj's suggestion is perfect.

    Barcode (Text) -> for majority of users, who don't know about barcodes
    Barcode (String) -> for searchability
    Barcode (Scan) -> for people who own or have access to a scanner

    My suggestion is to combine the description fields, if 2 or more versions of the barcode are identical. (No removing of descriptions)

    Barcode (Scan/String)
    Barcode (Scan/Text)
    Barcode (Scan/String/Text)
    Barcode (String/Text)
  • Electro-Magnetic over 8 years ago

    Marana

    Barcode (Text) -> for majority of users, who don't know about barcodes
    Barcode (String) -> for searchability
    Barcode (Scan) -> for people who own or have access to a scanner


    I think it's best to present them as quoted above - with one description. I've already encountered users updating releases with the (Text) and (String) specifically pointing to this thread. Simple and easy to understand.

    However some users still prefer entering (Printed) instead of (Text). If we are aiming to standardise, which term to use?

Log In You must be logged in to post.