AMC to Add Onscreen Captions at Some Locations

[Leo Enticknap]

I'd have thought that the problem would largely solve itself with the move from theater complexes containing a smaller number of larger auditoria, to a larger number of smaller ones, with the growing popularity of the hybrid movie theater/restaurant. A 16-plex with 100 seats in each house gives you a lot more programming flexibility than an 8-plex with 200 seats per house, enabling you to offer both the OCAP and CCAP versions of a movie at attractive show times.

Tons of data showing that home watchers are increasingly using captions, even young people, all the time. I don't think it will hurt attendance at all, and maybe will increase it as more people (particularly older patrons) struggle to understand dialog in these weird modern mixes with often unintelligible dialogue for even the best of hearers.

I think HOH subtitles are used for home viewing more, because the audio quality in a typical TV is usually pretty nasty, and there will also be restrictions on how loud you can have it. If you live in an apartment with thin walls, playing a 7.1 system at the SMPTE RP-200 reference level is not an option, unless you really want to p!ss off your neighbors. Likewise, when my young son is trying to sleep immediately above the living room, if I'm going to watch a movie, it will be almost silent with the CCAPs on (or, as Scott suggests, actually silent, with the amplifier not even switched on. I saw The Iron Horse this way on Saturday). None of those restrictions apply in a movie theater.

If demand for OCAPs in theaters is increasing, it has to be because either audio mixing in movies is not being done competently, or poor hearing is becoming a major public health issue. We all know that a properly tuned 5.1 or 7.1 theater audio system should be able to reproduce intelligible dialogue without any problem. It was possible to do that using tube amplification and the Academy curve of the 1930s!

Might as well just bring back silent movies with intertitles, then. And I say this as a silent movie fan. It would be easier to make translated versions for foreign markets, too.

It was claimed in the 19-teens and '20s that movies were responsible for a huge improvement in literacy rates among populations where the ability to read was by no means universal, thanks to the desire to be able to read the intertitles. The USSR even had linguistics experts vet the text of intertitles (Eisenstein and Kuleshov both mention this in some of their writings) with this in mind.

[Scott Norwood]

I'd be curious on statistics (which probably do not exist) on who is going to these captioned shows. Are they people who are a) actually deaf or hard of hearing? b) just wanted a convenient show time and were willing to put up with them? or c) actually prefer captions for whatever reason?

[Steve Guttag]

We have one site, in particular, that is located quite near a school for the deaf. Not surprisingly, they schedule a larger variety of OCAP shows, have more than ADA requires (by quite a spread) of headsets and caption devices. But, that is just a smart business that is catering to their client base. I suspect that they would have done that, even without an ADA since, as I said, they far exceed the minimum requirements. But that is one site and it isn't typical of most populations. I do not think that most business will put up hurdles to prevent potential customers from coming in. However, they do resent being forced to purchase something that never gets used.

I've sat in on the meetings when it comes to open captions versus closed...if you are in the deaf community, it is 100%, open captions is what they want. That is the only way that their eyes are focused and looking, reasonably at the same place. Rear Window is reasonably well accepted because it can be simulated and also keep one's eyes focused at nearly the same distance. Caption devices are way down on the approval scale. They are pretty much in the "better than nothing" side of things.

[Martin McCaffery]

Back in the Olden Days (35mm) before open caption was much of a thing, we showed a monthly open caption movie provided by a non-profit organization that was trying to get Hollywood to have open caption prints of all movies available. These were standard hit movies of the time (Forrest Gump, etc).

We never did too well with them, but we had a grant so we weren't losing money. We had a couple who used to attend all of our foreign movies so they could watch with subtitles. They really liked the open captioned films. The thing I really noticed was the numbers of people who were not deaf, but came with what was probably a deaf member of their family. I can only assume it was their chance to have family movie night (afternoon). So there is a little more than just appealing to the hearing impaired.

Eventually, the company who was distributing the open captioned films decided they needed to give them to the major chains instead of us. Here that meant Carmike, which may have shown them a couple of times, but got rid of them very quickly.

[Leo Enticknap]

if you are in the deaf community, it is 100%, open captions is what they want. That is the only way that their eyes are focused and looking, reasonably at the same place.

We (MiT) are working with a company that has developed a system that uses augmented reality headsets with wifi receivers to address this problem. I can't write too much about it publicly right now (though you will have seen the demo at Cinemacon), but we are trying to get the chains and studios interested. It has many advantages, the main one being eyes focused and looking at the same place. Others include sign language video being an option as well as subtitles, and the ability also to use them as an option for foreign language subtitles as well as HOH ones. This is an issue for theaters that play Mexican films in these parts (which are growing in popularity): native Spanish speakers don't want the distraction of English subtitles, but the movie is unsellable to an English-speaking audience without them. That is technically possible with existing CCAP technology, but I've never come across a DCP of a foreign language movie that offers the subtitles as CCAPs rather than on-screen subtitles. The main barrier still to overcome is the relative cost and fragility of the headsets.

[Buck Wilson]

Interesting discussion. Regal is now following AMC and sneaking in OC shows at some locations per an email I read recently.

That 'green strip' at the bottom of the screen with polarized glasses seems like a fantastic solution. Would in theory be a reliable setup with low cost glasses that the patron could just keep with them so as to not have to ask every time they come in. Wonder if something like that could actually be set up by a theater that wanted it?

[Harold Hallikainen]

I don't know that anyone is going to manufacture the system. I THINK the Zola patent (mentioned earlier) has expired. I recall the prototype system at USL that used a modified LCD computer video projector. You could experiment with an old projector by removing the polarizer between the LCD and lens. Aim that at a silver screen and try polarized glasses and see if you can see the image with polarized glasses. If the digital cinema server has an RS232 port that supports Rear Window, it should not to be difficult to write software to convert the Rear Window text into something to drive the projector. Rear Window text is sent backwards (right to left) and has a bunch of different control characters that have to be dealt with. Implementing ST 430-10 on the computer would be a bit of work. The caption board in the UPC-28C does have an RS232 output (on the header that plugs into the main board). It can output Rear Window formatted text. I COULD also make that do plain text. That board, and the UPC-28C also output captions on a web page, so a browser could be pointed to that web page and the projector driven with it. If you already have a UPC-28C or CCE-100, that's probably the simplest way to get live captions to the projector.

[Steve Guttag]

Harold, how accessible is the RS232 connector on a UPC28C? How difficult would it be to essentially have a CCE-100 by kludging in an RS232 cable to the panel?

[Harold Hallikainen]

I don't have a schematic anymore, but, as I recall, the caption board plugs onto the main board with a 5 pin header. Two pins are +5V, two pins are ground, and one pin is the RS232 output.

[Marcel Birgelen]

How is the text encapsulated if being sent over RS232? I guess it's plain ASCII or does it support Unicode as well? Unicode support would be elemental for international implementations.

Marcel, I do not agree that the technology of the industry has really been all that much in motion. Sure...there is a very, very gradual trend line up. But, really, look at it over its history. It took nearly ½ a century before it went to a wide screen (I'm not talking about attempts but actually adopting something with semi regular use). Until around the late 1980s, you had a better than 80% chance of hearing a movie in Mono...sound which came on line in the 1920s. Around 1985 or so, there was a stronger trend to stereo sound (4.0 in today's lingo).

I didn't want to put a qualification onto any of the recent and more distant developments in this industry as much of them are obviously debatable. While, if you look over time, progress in the field seems to have been slow, I think it's easy to forget the many sidesteps that have been taken over the years, many of which gone and went before they even captured a footnote in cinematic history. The fact that so many "gimmicks" have gone and went is probably more a testament to the core principle of cinema than anything else: Present a good movie with a minimum amount of distractions and people will come to see it.

[Harold Hallikainen]

Here's some code I used to drive Rear Window. Any Rear Window output would be similar.

// Rear Window Defines
#define RRdim "\x01\x20\x7f\x2f" // dim the display - seems to crash display!
#define RRL1 "\x01\x20\x20\x20" // select line 1 - appears to load buffer but not display until RRbright
#define RRL2 "\x01\x20\x21\x20" // select line 2
#define RRL3 "\x01\x20\x22\x20" // select line 3
#define RRbright "\x01\x20\x7f\x20" // make display bright - appears to latch received data to LEDs


void RwDisplayCaption(uint8_t *string){
// send full screen string to RW display. Do some UTF-8 substitutions and substitute RW line control strings for newlines. Send each line backwards.
uint8_t LocalString[50]; // build each line here
uint8_t LineNum=0;
uint8_t *psrc, *pdest;
uint8_t n;
psrc=string; // point to incoming string
while(*psrc){ // loop until end of string
pdest=LocalString; // point to start of local string
while((*psrc!='\n')&&(*psrc!=0)){ // copy over line of string stopping on newline or null
*pdest++=*psrc++;
if((pdest-LocalString)>sizeof(LocalString)) break; // don't overrun
}
*pdest=0; // terminate LocalString
if(*psrc!=0) psrc++; // move off \n in source string IF we're not at end of caption (point to null). hh 2/8/11
StringSub(LocalString,"\xe2\x99\xaa","\x7f"); // substitute music note for UTF8 music note
StringSub(LocalString,"\xe2\x80\x86","..."); // substitute three periods for HORIZONTAL ELLIPSIS. hh 11/23/10
StringSub(LocalString,"\x09",""); // get rid of any remaining format codes
StringSub(LocalString,"\x0c","");
StringSub(LocalString,"\x12","");
StringSub(LocalString,"\x0d",""); // get rid of cr
switch(LineNum){ // get us on the correct line
case 0:
printf(RRL1); // select line 1
break;
case 1:
printf(RRL2);
break;
case 2:
printf(RRL3);
break;
}
n=strlen(LocalString); // if n>0, n-1 is index of last character of string
while(n){
n--;
printf("%c",LocalString[n]); // work our way back through string printing backwards
}
LineNum++; // get ready for next line
}
printf(RRbright); // back to full brightness - Appears to latch the data we just sent
}


void RwDisplayBlank(void){
// Blank the RW display
uint8_t LineLength=0;;
uint8_t n;
if(ConfigData.Rs232use==Rs232useRearWindow32x3) LineLength=32;
if(ConfigData.Rs232use==Rs232useRearWindow32x2) LineLength=32;
if(ConfigData.Rs232use==Rs232useRearWindowDebug) LineLength=32;
if(LineLength){ // we're driving a rear window display on our serial port
printf(RRL1); // select line 1
for(n=0;n<LineLength;n++) printf(" ");
printf(RRL2); // select line 2
for(n=0;n<LineLength;n++) printf(" ");
printf(RRL3); // select line 3
for(n=0;n<LineLength;n++) printf(" ");
printf(RRbright); // latch in spaces previously loaded
}
}

Sorry that the copy/paste did not carry indentation.

In general, text is sent right to left with surrounding control codes. Some Unicode code points have to be remapped. The data is 9.6kbps 8N1.

Harold

[Marcel Birgelen]

Interesting... so, in your case the display did support some Unicode apparently.
I guess there isn't really a well-formed standard between LED display vendors. Back in January, I was hacking an old LED display system for a customer that had been fallen into disuse after they switched to digital years ago. It used to display the movie running on each screen above the entrance. Those things only talked ModBus (RS485), which made some sense as otherwise you'd have as many serial connections as you'd have screens. The interface was a thing built in Turbo Pascal and interfaced with their old ticket sales system. None of those displays would do Unicode (probably because of the age of those things) and since they were from three different vendors, spoke three slightly different control protocols...

What I find intriguing is this:

while(n){ n--; printf("%c",LocalString[n]); // work our way back through string printing backwards }

You printed the text on there backwards? So, you needed to load mirrored glyphs into it I guess? I'd expected the thing to have a native "mirrored" mode, but I guess it's just a generic LED display, without that functionality.

[Harold Hallikainen]

The Rear Window display has a set of DIP switches. The standard Rear Window setting switches the glyphs to "mirrored." I don't have access to the DIP switch settings anymore, so I can't remember what they all did. It was possible to have it display non-mirrored and left to right through DIP switch settings, even though the data came in right to left. I used that mode for some demonstrations. The display generally used ASCII. The very commonly used musical note character was code 0x7f while it was \xe2\x80\x86 in UTF-8 Unicode. So I replaced that and also the
HORIZONTAL ELLIPSIS .

Harold