Joe Clark: Accessibility | Design | Writing

Keeping tabs on the most expensive captioning software in the world

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.

Default blinkrate

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.

Incorrect encoding with zero blinkrate

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.

Incorrect apostrophe

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.

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.

Other errors

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.

And one more question

When starting up Swift for a day’s work, does the program still give you the option of “Line 21 subtitling”?

Document history

Homepage: Joe Clark Homepage: Joe Clark Media access (captioning, Web accessibility, etc.) Graphic and industrial design Journalism, articles, book