DTS/DD/THX 35mm preservations

[deleted user]

Yeah you're right, they aren't technically QR codes. But they obviously follow a similar principle in terms of how the data is stored (black dots on white background for bits).

I'd also wager that it was actually invented a few years earlier already, first print seems to have been 1991 already and from the moment you register a patent to the moment you develop working hardware can easily take a few years I think. I searched around a bit on Google Patents earlier and I think I found a patent for SDDS (if I'm not mistaken) by Sony, but sadly no SR-D so far. The patents of course don't include the name of the final product, they are just named something like "method to optically store digital audio on photographic film" and such.

[deleted user]

Finally found something that could give some new information: https://patents.google.com/patent/EP0643...g:19850101

This is a Dolby Patent called Dynamic Loader. Here's from the synopsis: "Although the invention has many applications, the invention is more particularly described in connection with a motion picture application in which film stock carries a conventional analog SVA soundtrack and a digital soundtrack with a digital representation of the software required to properly process the digital soundtrack."

This is exactly that mechanism they use to update cinema processors with software updates. Now, I don't know into how much detail this will go, but with a LOT of luck this could even show us a way to get the dolby decoding software from the data blocks themselves. Though to be realistic, I think at best this will help find out more about the format.

Also, funny tidbit: This patent apparently expired yesterday! Can you believe it?!?

[deleted user]

Okay, I got the files from the guy! Here's a single sample:


I also loaded a few hundred into a stack and applied a mean (average) to it:


You can see that some areas vary a lot and others vary less.

And then I applied a filter that's even more fascinating. It's called "Variance" and has this formula: variance = (sum( (value-mean)2 ) over non-transparent pixels ) / ( number of non-transparent pixels - 1)
So essentially I think it gives you an idea of how much each pixel varies. And the result is quite astonishing in my opinion:


I'll leave the conclusion-drawing to yourselves.

[deleted user]

Further hint from the Dynamic Loader patent:



Edit: YES! I believe I found it! Or at least something very very close to it. It even has the corresponding graphic of such a block inside it! https://patents.google.com/patent/CA2079...g:19920101

And it appears to also have expired yesterday!

[meantux]

I'm the guy that Tom invited here, I transfer 35mm films with my Gugusse Roller..

I cherish the naïve magic thinking idea (or should I say wish) that the job of translating the dolby frames in audio data will only be to serialize the bits in bytes and then pass it on as an ac3 file into ffmpeg. Maybe the AC3 library will recognize this data as its own and will even handle the error correction itself.

I hope.

[deleted user]

I'm the guy that Tom invited here, I transfer 35mm films with my Gugusse Roller..

I cherish the naïve magic thinking idea (or should I say wish) that the job of translating the dolby frames in audio data will only be to serialize the bits in bytes and then pass it on as an ac3 file into ffmpeg. Maybe the AC3 library will recognize this data as its own and will even handle the error correction itself.

I hope.

Welcome! Guys, fyi, this is the guy who captured those Dolby Digtal frames on Youtube and provided me with some of them for experimenting.

Yeah I have the same magical thinking idea, haha. But I think that with that patent PDF I linked, it could actually be achievable. I haven't read far into it yet, but I will as soon as I find time. It seems like it documents the format of those data blocks.

[MrBrown]

I'm the guy that Tom invited here, I transfer 35mm films with my Gugusse Roller..

I cherish the naïve magic thinking idea (or should I say wish) that the job of translating the dolby frames in audio data will only be to serialize the bits in bytes and then pass it on as an ac3 file into ffmpeg. Maybe the AC3 library will recognize this data as its own and will even handle the error correction itself.

I hope.

Yeahm, it may be a bit naïve, but I have some reasoning keeping the thought simple:
1.: It was invented in a time, when not every houshold had a Computer. Speaking of the power to work with scanned/photographed AC3 stream Pictures. 
2.: The AC3 on LDs came afterwards, but there is still no really need to change the Encoding or Decoding Technology. It still was save that for playback a Dolby AC3 Decoding was needed, because, still, Computer Technology wasn't that far in private homes, that t really was in danger to be misused.

So, I would guess, that they might just used the same Encoding Technology, and such a black White coding would be the easy way to transform just a stream of bits.
You NEED some Controlling parts, like how big the single dots are, you Need the Definition of what's a 1 and a whats a 0.
My guess would be:
White = 1 and Black = 0
Why? There need to be a sensor reading it with the White part there Comes more light to the sensor, the sensor dot is more triggered, and you got a Peak of power.
while black dots stay powerless.

I can imagine the Dolby sensor was like a sensor in a dslr, and a small processor translated it in bitstream.
It may be that there is a error correction System, but I imagine it would be Kind of sinple, too.

I cann imagine the Inventors where hyped about that method, but did not really think of "protecting" the data, just transferring and processing...

I hope that it might be that simple, but it is worth some tries and Errors. like calling every third dot a error correction dot. Or maybe every third "code".

BTW: The Corners have a size of 8*8 dots. so 256 dots are lost due to Corners in each code Segment...
8 Dots can be one bit.. so if each dot is a bit: 32 byte are lost in each square...

Edit 2:
If I am not wrong, each second has 516096 Bits... after removing the edges and the DD Logo...

Edit 3:
Just a thinking:
Couldn't that patent from 1991 be used from its holders, to sue the "Inventors" of QR-Codes, because technically a QR-Code is not that much different...


So, if Dolby in theatres is 320kbps, thats 320000 bits per second, if I am not wrong. If we think of a rato of 2 bits and 1 error correction bit, thats exactly 480000 bits you need per second.
So, if I calculated correctly the coded bitrate in the squares is indeed 516096 bits per second.
(After substracting the Corners and the Dolby Logo we have 5376 (data)bits per square, thats 21504 bits per movie Frame and thus 516069 bits per second.)
So, 36096 bits per second that are just "too much" to have a 320000 bps stream with additionall 160000 bips error correction. 
After recalculation, there 376 bits in each square that are just "too much" in the error corrected bitstream.
What could be done with these 376 dots in each image?
It still might be worth a try to create one big bitstream out of the single Frames, reduced by the Corners and the Center.
It really might be that easy that a normal AC3 Decoding recognize these Patterns and error correction. I am sure that a bitstream from LaserDisc etc. need These error correction and informations, too.

[deleted user]

There needs to definitely be some form of error correction imo because one of those dots easily gets lost through dust or similar. But it's possible that it's already implemented in the base format, not sure. You're right, they use a CCD sensor, similar to a DSLR. Though DSLRs use CMOS these days but that's just because they succeeded CCD sensors due to some advantages.

I should note something else I found out yesterday while reading about the dynamic loader. Apparently the data comes in blocks and the blocks can have different data types. From what I understood so far, there are 3 types of blocks: Software Blocks, Audio Blocks and Directory Blocks. The Software Block contain software versions/updates for the cinema processor or even specific software to play a particular print if it has some special coding. The Directory Blocks contain information about which software versions are compatible with the audio on this print. And the audio blocks of course contain the audio information.

So, most likely not all the information is actually audio information.

What I don't know (yet) is whether for example an audio block always means an entire visual 76*76 block or whether they can be subdivided into little data blocks.

[MrBrown]

Maybe if we had some more Blocks from different movies.
I can imagine that the audio in more silent scenes, when the audio is not changing that extreme... Or not at all, just show that behavior in the data. Watching the YouTube clip, and listening to the sounds I imagine that a big part of the not changing area is audio, because the sound doesn't change that much, and when it does start to change the blocks also start to go "much wilder"...
Somehow I assume the Directory blocks should be at the beginning of a Segment, to control it... And knew what to do with it.
The Software Blocks should be the ones that varying the most, even in absolute audio silence. Maybe until a point of "end".
If you check out the overplay patterns, you see that mostly there blocks of 2*4 blocks that seem to be changing every single square. That would be a byte. Maybe it is indeed not a sequence of bit, but more a sequence of byte-blocks. Also in the example there much area with 2 byte blocks unchanged and 1 byte block changing...

[deleted user]

Be sure to check out this information about AC-3 headers as well: http://www.stnsoft.com/DVD/ac3hdr.html

There's quite a few headers that need to be included, including all the information about sample rate, channels, dialnorm and so on and so forth.

And one part suggests that the data in AC-3 may be saved in 16-bit words.