In this page, I will document and track some significant bugs in Swift, the most expensive captioning software in the world (it costs about $12,000 a seat).
I’ve known the manufacturers of Swift, Softel, for many years. They endorsed my research project. And I’ve reported all these bugs to Softel, sometimes more than once. I’ve even offered to send in videotapes depicting the bugs in question. Thus far, I only occasionally receive a response, I almost never receive a substantive response, and most bugs remain unfixed.
Here is a term that is barely known in the captioning business; the underlying concept is even less widely known. Blinkrate is the number of blank frames between pop-on captions. One caption appears, then another caption appears. The number of frames in which no caption appears between those two captions is the blinkrate. (It can also be written as two words.)
The correct blinkrate in Line 21 is 2, not 0 (too fast) or 4 (too slow). Vitac kind of gets away with a blinkrate of 1. Because Swift is British “subtitling” software in drag, until recently it used a blinkrate of 0 as standard equipment. (British captioners also do not understand blinkrate. I’ve seen the same range of values there as here, although the default seems to be 0, hence Swift’s default setting. In Australia, I was given an incomplete explanation about why the particular scanning modes of PAL video influence blinkrate.)
Not only can I tell you about the history of usage of different blinkrate values, I have tapes from various eras demonstrating what was actually used. I can sit you down and convince you that any value other than 2 is incorrect.
Softel sent out an advisory on 2006.06.11 as follows (errant British single quotes replaced):
I am sending this message out to Softel-USA’s current Canadian customer base [sic]. Its intention is to simply make you aware of the option of “Blink between pop-on captions” that is available under Swift’s Line 21 Preference tab. The option was implemented in the v4.273 release of Swift. Some of you may already be familiar with this option being that version 4.279 is now the current released version of Swift.
With this option enabled/checked, Line 21 pop-on caption files will automatically be set so that a mandatory minimum two-frame separation will exist between captions. The result is a “blinking” effect that some may find helpful in determining when one pop-on caption disappears and the next appears.
(Note that captioners do not have a choice in the matter. It’s blinkrate=0 or blinkrate=2.)
I then asked Softel to send that advisory to Comprehensive Distributors/Mijo, the captioner down on Queen St. East in Toronto that thinks it knows what it’s doing. To this day, even after spending $300,000 on a Swift system, Mijo uses a blinkrate of 0, among many other atrocities, as we shall see.
Apart from correctness and the actual ability to read captioning, there’s a serious reason why zero blinkrate must be eliminated. Zero blinkrate correlates almost 100% with an encoding failure in which one caption displays, a second is transmitted, then the second caption is displayed for a split-second and replaced by the first caption. The first caption appears to flash momentarily and stays onscreen roughly twice as long as needed.
In the case of a long pause between captions, the first caption after the pause may appear instantly, then be replaced by the second caption, which appears as normal.
I’ve seen this once or twice with blinkrates other than 0, but I see it every day with zero blinkrate. Captions from Comprehensive Distributors/Mijo are the worst culprit.
No matter how they try to dress it up, Softel is a British company cashing in on U.S. and Canadian business. Softel has a U.S. sales office and a Canadian sales agent, but fundamentally they see live in a Bizarro world in which captioning is subtitling.
And in which an apostrophe isn’t an apostrophe.
Some history will be in order.
The character set for Line 21 captioning is available in three versions – the original, now nearly 30 years old; the so-called TeleCaption II upgrade; and the FCC upgrade. Characters have been swapped in and out of the same positions over time, and new characters and capabilities have been added.
In the TeleCaption II era, it finally became possible to start a caption line at any of the 32 horizontal character positions rather than at screen left or one of seven tab stops. (That was one of the many antitypographic design choices made by the semiliterate engineers who invented the system.)
Also in that era, and much more so after the FCC upgrade, it became possible to send an unaccented character, a backspace command, and an accented character. Advanced decoders would display the accented character and ignore the backspacing; old decoders would generate some other character for the accented one, delete it, and display the unaccented. Admittedly a hack, but effective at ensuring that at least a base character makes it through most of the time.
Softel has decided that the old Line 21 apostrophe character (at position 27), in full and unconflicted use before Swift came along, really means something else. So an apostrophe, by default, is transmitted as three characters – some other character, a backspace, and neutral apostrophe. (At least, the character displayed in this erroneous manner is identical to old captions’ neutral apostrophe.)
Now, there is another complication here that has nothing to do with Softel. Unicode, the global standard for character encoding, unwisely chose not to differentiate several characters. ’ can be used as an apostrophe or as a single closing quotation mark – two distinct semantics that are lost completely, because there is only one character for both uses. Similarly, neutral apostrophe ', which can also act as an opening or closing single quotation mark, is provided as exactly one character.
Thus, computer software, when given a string of characters that includes ’ or ', cannot tell what the actual semantics are. One effect of this confusion is errors in conversion from neutral to curled quotation marks – oft-seen errors like ‘80s hair bands or rock ‘n’ roll. Another error, one that causes human readers to suffer, is confusion about exactly when a single-quoted passage actually ends (because a word-ending apostrophe can be misinterpreted as the closing single quote).
Until Swift came along, there were two simple characters in Line 21, neutral single and neutral double quote, and they were used for all applications of single and double quotes and apostrophes, respectively. As with the Unicode case, you could not differentiate opening from closing quotation marks, or apostrophe from closing single quote.
The FCC revision added curled quotation marks in another range of characters, but nobody uses them – among other reasons, few speakers on TV or in the movies utter the nested quotations that would demand them typographically. None of the pre-FCC captions used curled quotes; we always made do with neutral quotation marks, even for rare nested quotations.
So what’s happening today with Swift? A character is transmitted, it’s backspaced away, and the original oldschool neutral apostrophe is transmitted. In pop-on captions you never notice it. In scrollup captioning, every instance of an apostrophe stutters. You can see a noticeable flash as something happens to what should be a single character but is, in fact, three. It’s maddening, it’s a flat-out mistake, and it never happened before Swift came along. You can spot the phenomenon on any number of CBC programs and promos.
What is Softel’s explanation?
Internally, Swift uses Unicode to represent all characters. Unfortunately, [Line 21] has a somewhat limited character set. As you state in your article, the base character... represents a closing single quotation mark rather than an apostrophe or neutral single quotation mark. [Actually, I never said that, and no, it’s ambiguously an apostrophe or either kind of single quotation mark.]
The specification adds an apostrophe character... which can also be used as a neutral single quotation mark. [No, that’s the one that was already there – at position 27 – and in use before Swift got it wrong.] Unfortunately, this extended character, and several others including the accompanying opening-single-quotation mark character, are in the backspacing-characters range.... This is only visible during real-time captioning. [Actually, it is barely visible then, but distractingly evident in scrollup captioning.] It is not, as far as I am aware, possible to encode a neutral single quotation mark without it deleting the previous character and we certainly do not encode a backspace character into the outgoing caption stream.
In fact, this behaviour is brought about because the captioner probably has Swift’s smart-quotes feature turned off rather than on. If the smart-quotes feature is turned on the quotes would be rendered as opening and closing single quotes and only the opening quote would be rendered in this way. We have a policy that if the user entered a neutral single quote, that is what should be broadcast, so that is what you get. [...]
I hope that this goes some way towards explaining the behaviour of Swift in this circumstance.
Softel has this quite backwards in every respect. If I “enter a neutral single quote,” that is now and always has been one character, not three.
Softel maintains that its software is working properly. They’re way the hell over in England and aren’t watching my TV shows. The software is broken, and Softel is so convinced of itself it deigns to attempt to teach me that up is down.
For quite a while, many captioners (including nobody’s first choice of captioner, NCI), were exhibiting a problem of dropped pairs of letters. The error disappeared after I reported it.
When starting up Swift for a day’s work, does the program still give you the option of “Line 21 subtitling”?