While watching tonight’s playoff baseball game on TBS, they showed a graphic with the TV schedule for the upcoming NLCS. They marked games 5, 6, and 7 with an asterisk, since it’s a best of 7 game, and the asterisk denotes the games will be played if necessary.
At the bottom of the graphic, to indicate what the asterisk means, they usually put:
*IF NECESSARY
but this particular graphic said
*IH NGEGUUCTY
which, apart from the first letter in each word and the last letter in the word “necessary” is the phrase IF NECESSARY shifted two letters forward (the F --> H, E --> G, and so on).
How would such a mistake occur? I assumed someone typed the graphic up using, well, a keyboard, but that wouldn’t lead to such a bizarre yet rule-driven typo.
I’d like to know, too, but the first thing that comes to mind is that bit 1 (counting the LSB [Least Significant Bit] as 0) got flipped[sup]*[/sup] in a binary word or byte and shifted the ASCII interpretation up 2 steps in the table.
Yes, flipped with a carry into bit 2 – it wasn’t just toggled – but you know what I mean, right?
I checked if the ASCII for the letters that were changed were all even, or all odd, but they weren’t. The ones that were left unchanged had both even and odd ASCII representations as well.
Guessing: A few specialties in the world still use non-standard keyboards; the phone company only went qwerty in the last few years. But more specifically, I suspect that captioners probably use the same ones as a court transcriptionist, something like a stenotype (meant for very, very fast keyboarding). These might be more prone to “ordered letter” errors than a regular keyboard.
Perhaps, but this wasn’t a caption (if you’re talking about closed captioning). It was simply a footnote on what I assume was a previously-prepared graphic. To be clear, it was part of the graphic.
I’m thinking about the first letter of each of the two words. They did not suffer the fate of the other letters. Maybe it’s because they were typed in upper-case?
In other words, despite the fact that the final product was displayed in all caps, maybe it was entered as “If Necessary”, and the problem (whether a bitwise function in the computer, or the physical keyboard) only affected the lower-case letters.
Except the “y” at the end of “Necessary” wasn’t shifted either. (And it isn’t that the first and last letters escaped, as the “f” in “If” WAS shifted.)
My guess is that the error is actually in the font…
Don’t think of this like its a windows font . Don’t think its a simple font A-Z.
Its a video production software (or device.), which would have a complicated font system. Its corrupted the font for some reason.
of course, it may be a hacker type who editted it just to make it a minimal error to help get his hack air time .
WAG
One of the joys of working in an office with me is that I will remap your keyboard if you leave your computer unattended and unlocked. If I can’t get into the software, I will pop keys off and shift them around.
Yes, I am an asshole to work with. Perhaps the typist got pranked and either didn’t notice, or if they were new, (intern?) thought it was odd, but didn’t want to admit they were having trouble typing a simple message into the system.
This could be, if it was passed through a function to automatically convert lower-case to upper-case. One way of doing that is to add a constant to the numerical value of the letters, and if the wrong constant were used, it would lead to a mangling like this (perhaps the letters were encoded in some way other than ASCII, for instance)?
This still leaves us wondering why the Y wasn’t shifted. My best guess is that it’s related to the fact that Y is at the end of the alphabet, not to the fact that it’s at the end of the word: Y can’t be shifted to the letter two places after it, because there is no letter two places after it. Though I would still expect it to be shifted either to some non-letter character (possibly something unprintable), or to Z.
Y is character #121 in the ASCII table. Two chars up is 123, or “{”, so that’s quite printable.
ASCII Char Y is 79Hex, or 0101 1001B, so flipping bit #1 (LSB is bit 0) or adding 2D (10B) would produce the same result, 0101 1011B, or 7BHex (123Dec), ASCII “{”.
I’m not sure that I buy your theory of lower-to-upper conversion gone wrong. Lower to upper can be done by zeroing bit 6, and it’s a stretch to suggest that they just used the wrong bit. Even reversing the 4-bit halves of a byte by mistake wouldn’t do that.
My theory is that it was due to a translation routine from a word processor file to HTML. I see this kind of error all over the place where the wrong table was used – not so wrong as to render gibberish, but wrong enough that a sharp eye can spot something askew on some of the rarer characters.
Didn’t see this mentioned, but all the correct letters would be typed with the right hand while all the incorrect ones are typed with the left. I don’t know how that helps to explain anything, though.
Just to close this out, because I looked into it, closed captioning is generally done using a stenotype. But the writing seems to be done phonetically, and using a highly specialized keyboard. Here’s a description of how they are used, and it doesn’t seem like slipping a key on a stenotype would lead to anything like what showed up.