Login

**MrBrown** · 2019-04-23, 03:41 PM

sorry, I just found some things in German, but maybe that also help someone. (Hi TomArrow! Smile

)
https://curdt.home.hdm-stuttgart.de/PDF/AC3.pdf
this (and your link) indecates that the error correction is also part of the AC-3 Bitstream. Thus we may not even need to worry about that. We may just need to figuere out, which bits are used for Software, wich for other informations, and hus get the AC-3 Bitstream out of the rest. Maybe the Problem is also how this bitstream is allignet in the Square.
Also, for the German reading People here: This might also be interesting: https://opus4.kobv.de/opus4-filmuniversi...erDipl.pdf

Sorry, These are not in english... Sad

meantux · (This post was last modified: 2019-04-24, 05:56 AM by meantux.)

Using openCV to detect the corners in an attempt to improve the precision and I draw a black dot where I detected a white area and vice-versa.

My next step: determinate a local median value for a better separation of white vs black.
For the moment this is the best I can do:

davidferguson · 2021-07-12, 03:29 PM

@TomArrow and others, did anything ever come out of this? I'm interested in trying to work out the Dolby Digital on film format too. I did find some things in my research not mentioned in this thread, most of which comes from this Dolby patent (which has now expired). The most interesting parts are:

As you've already found, each dolby digital "fixel" (that's what Dolby calls the QR code like squares), is 76x76.
Each corner is a 7x7 sync pattern ("cross-multiplied 7-bit Barker code (1110010)") - but there seems to be a black border on the innder side so it's more like 8x8 I think.
And the middle is the 12x12 sync center of the Dolby double D logo

The signal carried in the Dolby Digital stream contains the following streams. Based on what TimArrow said previously about there being three types of block, maybe all of these aren't in each, and instead the data ones are in the software and directory ones? Although I also know that there's a bit of metadata in every block, so that might not be the case.
- x5 20kHz audio channels
- x1 125 Hz subwoofer channel
- x1 2400 bps data channel
- x1 9600 bps data channel

In terms of physical encoding, the black dots are 1s and the opaque dots are 0s. The bytes are arranged in 2x4 groups, ie 2 horizontal, 4 vertical, and therefore each block is 38 bytes wide, and 19 bytes high. This makes sense as the corners and center patterns fit into their own bytes then.

During the decoding, the data is error corrected using reed solomon encoding. There are "two levels of protection", "inner EDC codes and outer EDC codes". The data is passed through reed solomon correction *twice*, the first for outer EDC, and the second for inner.

The bit that concerns me most in the patent is this quote:

Quote:The digital information, after encoding, may be randomized prior to its application as symbols on the film so that the blocks of symbols will not be likely to contain large transmissive or opaque areas. The occurrence of a large area of opaque or transmissive symbols would therefore most likely indicate a large surface defect.

If it is randomized, then there must be a way of recovering the original order, but it doesn't seem to be described in the patent.

I'm a 35mm film collector, so I'm lucky enough to have a projector, and dolby digital reader and decoder (in fact I have two decoders, one I don't mind taking apart and looking at). There are a couple of extra things I've found when looking at the boards in it.

The reed solomon chip is a AHA4010-01, which looks like a relatively standard chip.

The AC3 decoding itself is done by a Zoran ZR38500 - which is actually a consumer AC3 decoder chip that's also found in DVD players and the like. Unfortunately, this chip also supports a "user designed program in external boot-strap ROM [to] add distinctions to industry standard decoder functions" - and I believe this is used in this case to read the non-standard datastream. Certainly, when I hooked up my logic analyser, it didn't resemble standard AC3 frames. And I can't get hold of the programmers guide for the Zoran chip, and dumping the ROM is beyond my capabilities at the moment.

2021-07-12, 04:32 PM

Interesting stuff! Sadly I have not pursued this further. Sometimes I tend to open up 100 cans of worms and then I just can't get deeper into each, though I really wish I had the time and energy to pursue this further. Maybe some day, or maybe someone else will have a go.

It's not much, but a few days ago someone on 35mmforum said (if I recall correctly) that the reading is circular from the inside to the outside.

Do you have any way to capture the raw digital datastream coming out of the decoder or anything like that? Might be easier to work from there perhaps than from images (edit: and also more straightforward to capture?). Or is that what you're saying, that you have already capture the digital data?

**PDB** · 2021-07-12, 05:42 PM

(2021-07-12, 03:29 PM)davidferguson Wrote: I'm a 35mm film collector

Do you have any cool prints?

davidferguson · 2021-07-12, 09:10 PM

(2021-07-12, 04:32 PM)TomArrow Wrote: Do you have any way to capture the raw digital datastream coming out of the decoder or anything like that? Might be easier to work from there perhaps than from images (edit: and also more straightforward to capture?). Or is that what you're saying, that you have already capture the digital data?

I did capture some in the past but couldn't make much sense of it. I tried again tonight using my cheap logic analyser, and there is some interesting data. I'm capturing after the reed solomon decoding, just before the data is fed into the AC3 decoder. I can see there's about 92 packets in a second, which is about right for 24fps (it should be 96, but I could have missed a few). Each packet has about 489 bytes in it (that's a rough number, I need to figure out a couple of issues with the capturing and decoding), which would about figure if there's 672 data bytes in each block, then ~30% are for reed solomon error correction. At some point I'll put some of the captures here if anyone wants to take a look at them.

What I really want to do is look at the data before it goes to the reed solomon decoder. However, that chip takes in a parallel data signal, so I need 9 inputs on my logic analyser (8 signals + clock), but I only have 8. I know where I can borrow a 16 channel analyser from though, so at some point I'll try and get that and take a look.

(2021-07-12, 04:32 PM)PDB Wrote: Do you have any cool prints?

I've only been collecting a couple of years, so only have about a dozen feature films, along with some trailers, adverts, logos and shorts. I have some of my favourite films (mid/late 2000s CGI), but they're probably not of much interest to people on here (although some of the shorts, cinema logos and adverts may well be).

davidferguson · 2021-07-12, 10:21 PM

Okay, I did a 10 second capture of the input to the Zoran AC3 decoder chip (reminder, this is after the reed solomon decoding has been applied). You can read about this chip in the datasheet, but it has an SPI data input, which is what I've captured here. You can download the capture here (54mb) - it needs the Saleae Logic software to be opened. I use Logic 1, not sure if Logic 2 will work.

Channel 3 is data, 7 is clock, and 0 is "frame synchronisation" (ie. tells you when a frame starts). A frame is 16 bits long. You'll want to look at figure 8 in the datasheet for more information.

The two images below show the capture, one zoomed out so you can see what I assume are each data block, and one zoomed in for illustration of the three channels (data, clock, frame sync).

[Image: zoomed-out.png]

This is where I have to say that I don't really know what I'm doing, as reverse engineering isn't exactly my area. So... who wants to try their hand at seeing if this is decodable? Big Grin

**zoidberg** · 2021-07-12, 11:04 PM

Given that the print reader is basically an exciter lamp and CCD (with some sort of flywheel to maintain constant speed of the film) the signal fed to the decoder will basically be a video signal, so knowing how the CCD captures and sends the image for the decoder to parse before decoding to audio is going to be part of the solution (given that AC-3 on 35mm prints was between the sprockets, the CCD signal is going to alternate between reading real data and then the nothingness within the sprocketholes). The signal will most likely be binary ie on/off, low/high etc. Interestingly PCM audio was initially stored and played back from videotape which was partly the reason the 44.1kHz sampling rate was settled upon.

CDS used a similar system with a CCD acting as a reader of the 'bits' printed into the space reserved for the optical track, although the density of the individual bits was much higher (looking like a grey strip on the film) as the audio was uncompressed 16-bit using a form of delta-modulation. Ironically the advances in print stock required to make CDS possible paved the way for AC-3/SDDS to swoop in later.

2021-07-13, 01:01 PM

@davidferguson

I wrote some code to translate a "binary.bin" (exported from Logic 1.x via the binary export at 8 bit) into raw binary data.

The result is a file with the ending .ac3, but it doesn't play (yet?). For what it's worth, MPC-HC does open the file and shows 1 second as length, but doesn't really do any audio. ffmpeg says it recognizes some kind of ac3 but isn't able to decode it either. Mind you, I'm not 100% sure I did the file generation correctly, that might very well also be a source of error. For example it's possible that some fuckery with endianness must be done, but this should just be the bits straight as they were captured, into binary data.

Method: I took the raw data from the logic analyzer export. Whenever the block channel was active, I interpreted the data at that point as the beginning of a new byte. Then each clock cycle triggered a new reading. The value actually saved into the file was that of the data channel of course.

But what I did find:
[Image: NjE03wN.png]

There is a repeating pattern every 512 bytes. The above image is the file opened in Photoshop as raw input. It's plausible to assume that the alignment of this picture isn't correct since I just wrote the binary data into the file exactly as it was captured.

I tried a similar thing with AC3 encoded via ffmpeg, but I wasn't able to get this nice of a repetition. Best I got was with 1950 pixels width:
[Image: 1smHNqT.png]

I've attached the decoded "AC-3" file in a zip to this post. Maybe someone has another idea. The repeating pattern has me optimistic. I wonder if this is already the raw ac-3 data stream or if it is still capsuled in some kind of transport format for the purpose of error correction.

Edit: Here's the parsing code btw: https://github.com/TomArrow/DolbyDigitalSerialParser

**dvdmike** · 2021-07-13, 01:27 PM

(2021-07-12, 11:04 PM)zoidberg Wrote: Given that the print reader is basically an exciter lamp and CCD (with some sort of flywheel to maintain constant speed of the film) the signal fed to the decoder will basically be a video signal, so knowing how the CCD captures and sends the image for the decoder to parse before decoding to audio is going to be part of the solution (given that AC-3 on 35mm prints was between the sprockets, the CCD signal is going to alternate between reading real data and then the nothingness within the sprocketholes). The signal will most likely be binary ie on/off, low/high etc. Interestingly PCM audio was initially stored and played back from videotape which was partly the reason the 44.1kHz sampling rate was settled upon.

CDS used a similar system with a CCD acting as a reader of the 'bits' printed into the space reserved for the optical track, although the density of the individual bits was much higher (looking like a grey strip on the film) as the audio was uncompressed 16-bit using a form of delta-modulation. Ironically the advances in print stock required to make CDS possible paved the way for AC-3/SDDS to swoop in later.

I wish CDS got more of a push, so sad.
We lost out having SDDS at home as everyone drunk the Dolby kool aid.

Login
Username:
Password:	Lost Password?
	Remember me

Possibly Related Threads…
Thread		Author	Replies	Views	Last Post
	[Proposal] ALIEN : Theatrical 4.1 DTS HD to sync to 35mm scan	ash_82	0	151	2024-11-08, 04:29 PM Last Post: ash_82
	Dolby Digital Plus - any known preservations	Bigrob	18	13,221	2023-01-25, 05:27 PM Last Post: Hydra Spectre
	35mm VS 70mm Mixes (And where to find them?)	LucasGodzilla	39	13,632	2022-06-05, 04:08 PM Last Post: Bigrob
	Jurassic Park LD DTS & PCM synced to 35mm	marin888	4	5,212	2020-03-28, 10:08 PM Last Post: marin888