35mm Kill Bill The Whole Bloody Affair

[Markus Lemm]

Kill Bill The Whole Bloody Affair

16 Reels
Scope
SR / SRD Cyan (*see note below)
Kodak 2383
Intermission at end of reel 7


*some reels have DTS (Only reels 3,4,16 are SR/SRD only)

[Ryan Gallagher]

Kill Bill The Whole Bloody Affair

*some reels have DTS (Only reels 3,4,16 are SR/SRD only)

That bit is interesting. Wonder if it is even intended to be used...

[Brad Miller]

No, the DTS should not be used on the 35mm Whole Bloody Affair print.

[David Ferguson]

I'm curious to know the reasoning behind this. Subtitling? A test? Something else?

[Markus Lemm]

The serial number on the DTS track, at least on Kill Bill 1, is the same as the 2003 release. The reel numbers don't match and obviously reel 3 and 4 are missing DTS altogether. So it wouldn't work.

To bad they didn't print the DTS track from the 70mm release on the 35mm prints.

[Michael Zarits]

No problem with a dts-tach

[Marco Giustini]

is that reading the speed of the film running and translating it into DTS timecode?

I like the two extremes here: the average cinema struggled to run DTS because it was some extra steps to do but there is someone around willing to build a device to create DTS timecode from an encoder

[Michael Zarits]

is that reading the speed of the film running and translating it into DTS timecode?

Yes. Basically, it counts the number of frames running through the projector and sends the corresponding timecode.

To explain the term “tach” here, we need to take a quick dive: to produce a readable timecode, it must be continuous. You can’t check a frame number, then send the timecode block, then wait for the next frame, etc. Since the DTS processor’s detection of whether a bit is 0 or 1 is time-related, the timecode is not allowed to have gaps between blocks—not even start/stop bits, as those are time-critical as well.

So the “tach” part is actually responsible for determining the optimum speed at which it sends the 48 bits of a timecode block, so that the next block appends seamlessly AND with precise timing. Basically, at exactly 24 fps, it is supposed to send one bit every 10⁵/144 µs, and the tach’s job is to adjust that value 60 times within a physical 35mm 4-perf frame to a duration it assumes the next frame will take to pass the gate, based on how long it took for the previous frame.

[Ryan Gallagher]

Yes. Basically, it counts the number of frames running through the projector and sends the corresponding timecode.

To explain the term “tach” here, we need to take a quick dive: to produce a readable timecode, it must be continuous. You can’t check a frame number, then send the timecode block, then wait for the next frame, etc. Since the DTS processor’s detection of whether a bit is 0 or 1 is time-related, the timecode is not allowed to have gaps between blocks—not even start/stop bits, as those are time-critical as well.

So the “tach” part is actually responsible for determining the optimum speed at which it sends the 48 bits of a timecode block, so that the next block appends seamlessly AND with precise timing. Basically, at exactly 24 fps, it is supposed to send one bit every 10⁵/144 µs, and the tach’s job is to adjust that value 60 times within a physical 35mm 4-perf frame to a duration it assumes the next frame will take to pass the gate, based on how long it took for the previous frame.

Does your tach implementation/concept measure rpm or time between frames, I feel like the concept of “shaft encoder” is the better fit if the latter (which seems more robust). Reacting to measured RPM feels like it might allow drift to build over time. Tachs really are acting like shaft encoders of course, there is just an extra translation step to the units.

[Michael Zarits]

That’s what I wanted to point out: it is essentially a shaft encoder that counts every frame passing the gate, and the “tach” part is merely an underlying process that translates the pulse interval into a data interval. A drift, as such, does not exist; the system is accurate to the interval received from the sensor.

In my setup, I pick up a one-frame interval from the projector, but it can be any defined interval; it is simply a value that must be set in the software according to the sensor being used.

[Marco Giustini]

that is very cool, Michael!

[Ryan Gallagher]

That’s what I wanted to point out: it is essentially a shaft encoder that counts every frame passing the gate, and the “tach” part is merely an underlying process that translates the pulse interval into a data interval. A drift, as such, does not exist; the system is accurate to the interval received from the sensor.

In my setup, I pick up a one-frame interval from the projector, but it can be any defined interval; it is simply a value that must be set in the software according to the sensor being used.

Thanks for clarifying. I expect something like this excels on platter driven shows with no missing frames... but what of change-over configurations... does a poorly timed change-over cause the frame equivalent desync? How does it know when to start the sending soundtrack bits (even on platters)?

[Michael Zarits]

When preparing a print for tach playback for the first time (I will retain the term “tach”, although we acknowledge it is technically a shaft encoder), I scan the print frame by frame and align it with an existing DTS or with another source from which I encode a new disc.

During this process, I determine the FFOA, LFOA, and any potentially missing frames for each reel. This information is then encoded into a QR code that is kept together with the print:

5_low.jpg

When showing the print, I simply scan the QR code with a barcode scanner, thread to picture start in the gate (or to any other predefined rundown leader length), and link the tach to the generator, like IMAX projectors are linked to the sound system. From that point on, the generator outputs timecode exactly as if it were derived from the print itself, including any potentially missing frames.

In case a splice occurs in the middle of a sentence, I can adjust the splice in timecode slightly around its actual position to allow the sentence to finish, provided the picture permits (for example, if the lip movements are not visible). The audio splice is then executed at the point where the sentence is complete, ensuring a natural flow.

In addition to generating timecode, the system is also used to create automation pulses, allowing the prints to remain free of cue foils. The QR code additionally contains cue points such as credit offsets, etc. The system also automatically switches the D600 reader LED on and off depending on whether the projector is in motion, thereby reducing unnecessary LED wear.

In the unlikely event that one or more frames are removed from a reel, or if the print is altered in any way for any reason, of course, the QR code must be updated accordingly.


Here is the main interface, slightly modified over time:

6_low.jpg


First prototype, in operation for two years in my setup and used on nearly every show:

23-12-26_02-45-51_3252_800x600.jpg


And here is a demo of a German-dubbed, non-DTS print ...

7_330x424.jpg

... running with the original English DTS disc using the tach:

My current configuration is set up for platter mode, but it would work the same way for changeovers. I would also equip the second machine with a tach, allowing the DTS processor to receive timecode via Pin 2. If I ever require the tach to operate in changeover mode, I would upgrade the software to “dual tach”, enabling a single interface to handle both projectors.

[Marco Giustini]

oh wow - this is more than a tinkering project. Hats off!

[Ryan Gallagher]

Yeah no kidding, but I guess if you have access to a lot of dubbed prints, that had DTS in their original language, this is worth it. How do you manage when the dubbed version is an edit too?

So do you also have a way to do Austrian/German subtitles digitally on top of such a print? Seems like a stretch, but not after what you've just shared.