11 Comments

The alignment marks in the corners are a cross-multiplied Barker-code. This has a high enough correlation peak that pixel (fixel) centres can be located at around 0.1 feature size. The DD in the centre was included as a safety precaution – there were concerns that this would be a high-wear part of the film because of the shape of the sprocket-drive system. The original matrix was 76×76, not sure if it morphed to 78×78, possibly covered by the patents (which make interesting reading) including US Patent 5,757,465. I trust the statute of limitations is up on this one :) - Mark Atherton

Expand full comment

SDDS occupies the space outside the sprocket holes on BOTH sides of the film. It also had more data as the speaker layout was left/left center/center/right center, right, surround left, surround-right, and subwoofer. There was also 'backup' tracks encoded- left+center, center, right+center and subwoofer. It was 12 total channels at about 2.2mbps ATRAC compression IIRC. An interesting side note, the two sides of the film were NOT synchronous(about 17 frames difference), so if a splice was made, it could read over the edit.

The timecode track was for DTS. It used an external CD data disc.

Also, Jelmer is correct- damage to the sprocket holes was not uncommon, and you could often hear the sound in the theater 'collapse' to standard Dolby Surround, due to damage on the film from poorly maintained projectors, or careless staff.

Expand full comment

There was also a Kodak keyKode feet/frame/pulldown barcode system that was placed on the film photographically.

Expand full comment

Take a minute to read https://en.wikipedia.org/wiki/Dolby_Digital#Cinema. It explains all you need to know.

(BTW, don't call these matrixes. You'll get confused between the digital part, which is referred to as "blocks," and the analog part, which is matrixed. See https://en.wikipedia.org/wiki/Dolby_Stereo)

Expand full comment

The Dolby-data between the 'holes' is somewhat easily damaged by a slipping sprocket; I would not be surprised if the format would be able to cope with the loss of at least one of the matrixes before an audible glitch would be noticeable. That would suggest ECC not just within one matrix, but across multiple matrixes.

I think the original decoding equipment contains a significant (adjustable delay) buffer not just to cope for some badass ECC, but also to accommodate different styles of projector/equipment setups.

Expand full comment

When a block was so degraded it could not be recovered, the processor simply re-played the prior block. If the quality of multiple blocks was too bad, the processor automatically switched to the optical soundtrack, and would go back to digital once the quality of the blocks improved.

I might note that, perhaps surprisingly, the wear of the blocks (being in between the sprocket holes) was VERY low. Prints could run essentially forever with little degradation. The only place a film projector is specifically allowed to touch the film print is *outside* of the sprocket holes.

Expand full comment

Just one sidenote: Decoding QR codes isn't as hard as described here. While the encoder needs to try up to eight masking patterns, the decoder doesn't, as the chosen masking pattern is indicated by the code's format info.

Expand full comment

> Given that we have a data rate of ~584Kb/s I suspect audio data is stored uncompressed.

A CD is 1.4Mb/s I think, and high quality MP3 is 320 Kb/s. Given that some of the ~584Kb/s will be taken up with ECC checksums, and it's also going have more channels than a stereo CD or MP3; suggests it's compressed quite a lot?

Expand full comment

In my post by ~584Kb/s I mean Kilobytes/s, I should use KB. I'll update the post. This is significantly higher than CDs which would be 88.2KB/s.

I suspect you're right though, and there is some compression... Perhaps Dolby AC-3? I'd like to better understand this.

Expand full comment

After all of the error correction is done, there is around 312 kbits per second of usable audio data bits. The film holds encoded audio data using a precursor to AC-3 encoding (but is very close to AC-3).

An interesting side note: The blocks also carried software, so that the decoding equipment (such as the DA-10 and DA-20) could have their firmware automatically upgraded in the field, just by playing a newly-released film! Pretty advanced for early 1990 electronics.

Expand full comment

Ah I see - that makes more sense

Expand full comment