Reading Dolby Digital AC3 from an entirely digital film scan

[Marcel Birgelen]

I was wondering if someone knows of a way to read Dolby AC3 from an existing film scan, where the space between the sprocket also has been scanned. The scan is sufficiently sharp in order to resolve the individual "pixels" of the data stream. While, in this case, the digital stream can be captured from another medium, I was asking myself in general if it's possible to interpret Dolby Digital directly from film, without having it to feed to any external reader.

If anybody has some pointers towards some of the specifications or other means of reading this directly from the scan, I'm all ears.

[Mark Gulbrandsen]

Just fired off a copy of your post to a film restoration friend in the UK. We'll see what she says...

[Lyle Romer]

It would be relatively easy if you had the specification from Dolby for how the data is encoded. It isn't straight AC-3 because there is FEC built into it and also a low bitrate data channel. I guess with some time and effort and a modified DA-10 or DA-20 (or the cards from a CP-500) and a reader you could reverse engineer how the bitstream is encoded.

Once you know how the data is laid out it's just a matter of setting up a program to do visual recognition on each block and running an algorithm to strip out the AC-3 stream. If you know any engineers at Dolby they might be willing to get you the info. It's not like it is technology that needs to be protected anymore. I don't think the spec is in the patents.

[Randy Stankey]

I'm guessing that the squares of digital code could be treated similarly to QR code and read that way.
That would result in strings of characters that could, then be decoded into digital sound data.

In my estimation, decoding the squares into characters would be the easy part. Concatenating those strings and decoding them into sound would be the hard part which depends upon knowing the encoding scheme.

While I'm confident that it can be done, I'm not confident about the amount of work needed to get there.

[Mark Gulbrandsen]

In theory, with the proper optics it could likely be played back on a DA-20, and the analog output then stored for archival purposes. Just a larger Cat 702 kind of a thing, or with well designed optics, just feed the digital track right into a modified CAT 702 or BACP reader via a light pipe.

[David Ferguson]

The answer to this is "no, not right now", but there are a couple of people who are experimenting with trying to do this, myself included (my interest in film projection is the tech side of things, so I find this sort of thing fascinating).

I have an online wiki which describes everything that is publicly known about the SR-D format, and probably the most relevant page for you to have a look at is the Physical Encoding page. This goes over what data streams are contained, what sort of error correction is used, how the bits are arranged into bytes, and describes how to decode a couple of the data (not audio) bytes - the only ones I've so far been able to work out. The wiki also contains pages on the SR-D workflow from audio post house to release print, info about the various decoders, and more. And if you know something that isn't listed there, please add it!

But to over a couple of points from this thread:

I was wondering if someone knows of a way to read Dolby AC3 from an existing film scan

The data format isn't actually AC-3, it can best be described as AC-3-like. An engineer from Dolby described it to me as "a pre-cursor of what became AC3", and he said that there were differences made for the AC-3 version, but he couldn't recall exactly what. So it's not going to be as simple as "send the decoded data to a AC-3 decoder".

It would be relatively easy if you had the specification from Dolby for how the data is encoded. [...] If you know any engineers at Dolby they might be willing to get you the info. It's not like it is technology that needs to be protected anymore.

It probably would, but when I asked some people at Dolby, I was told that "even though the general consensus within the industry is that ‘film is dead’, we would be subject to a legal review in order to be able to release any private information, which even for a one off would be a costly and long process". So that sounds like a "no, not going to happen" sort of answer, sadly. Maybe if you were asking from an archive/academic point of view you'd have more luck, rather than me just asking "because I want to know"?

In my estimation, decoding the squares into characters would be the easy part. Concatenating those strings and decoding them into sound would be the hard part which depends upon knowing the encoding scheme.

Reading a scanned SRD into a bit (or byte, now that I know how bytes are encoded) array is easy - I have python code that already does that. The hard part, as you've guessed, is then how to decode the audio from that.

I guess with some time and effort and a modified DA-10 or DA-20 (or the cards from a CP-500) and a reader you could reverse engineer how the bitstream is encoded.

I should preface this and say that I'm not a hardware guy - I dabble in hobby electronics, but reverse engineering something as complex as that is no easy task. I've used my logic analyser to observe the data stream going into the Zoran chip on a DA-20, but where I've got stuck is that the documentation that describes the instruction set of the Zoran chip in the DA-20/CP500 is nowhere to be found. Zoran were bought by CSR, who were bought by Qualcomm, and Qualcomm have no documentation for this chip. So I can see that a data stream goes in, and audio digital pcm audio comes out, but I don't know what it's doing to make that happen.

Where i may have more luck is with a DA-10 (I have a working one of them, maybe the last one out there?) as that uses Motorola DSP56000 (lots of them) in sequence to process the audio. That chip is very well understood, so I'm sure it would be possible to read the instructions that are being passed to them, and see how it's being decoded. However sadly that is beyond my current reverse engineering ability. I also don't want to damage/break the DA-10 because of its rarity.

If anyone wants to help, either by contributing towards the wiki, or in other ways, it would be great! Mark, if your film restoration friend has any knowledge of this, I'd be interested too. So far I just know of myself and a few others who are looking into this because we're all interested in knowing how it works.

[Lyle Romer]

If Dolby was still a closely held private company I'd guess they would give out the info at this point. Being a publicly traded corporation makes things like that far more complicated. Does the Zoran chip get the raw data stream as input and do all of the error correction? I thought I remembered that there was a card in the DA20/CP500 that does the error correction (the one that has the LED error rate display). I always assumed that the output of that card was the error corrected AC-3 stream + the low bitrate data channel.

[David Ferguson]

Does the Zoran chip get the raw data stream as input and do all of the error correction? I thought I remembered that there was a card in the DA20/CP500 that does the error correction (the one that has the LED error rate display). I always assumed that the output of that card was the error corrected AC-3 stream + the low bitrate data channel.

No, the Zoran chip doesn't do the error correction, on the DA-20 and CP500 (but I'm not sure about the DA-10, I'd have to check mine), it is done by a AHA4010-01 chip that's on one of the boards. As I mention in the wiki doc, the data is passed through this chip twice for each SR-D block, but I haven't yet been able to capture this because I don't have a logic analyser with enough pins for it - mine only has 8, and ideally I need 17 (8 input, 8 output, 1 clock) which is a really annoying number of pins to get a logic analyser for.

The Zoran does take in a stream, and output 3 PCM pairs, but the stream it takes in doesn't resemble consumer AC-3 data as far as I can tell. I did have a capture of that somewhere, but I can't seem to find where that file is now... maybe I'll have to do another one.

[Lyle Romer]

No, the Zoran chip doesn't do the error correction, on the DA-20 and CP500 (but I'm not sure about the DA-10, I'd have to check mine), it is done by a AHA4010-01 chip that's on one of the boards. As I mention in the wiki doc, the data is passed through this chip twice for each SR-D block, but I haven't yet been able to capture this because I don't have a logic analyser with enough pins for it - mine only has 8, and ideally I need 17 (8 input, 8 output, 1 clock) which is a really annoying number of pins to get a logic analyser for.

The Zoran does take in a stream, and output 3 PCM pairs, but the stream it takes in doesn't resemble consumer AC-3 data as far as I can tell. I did have a capture of that somewhere, but I can't seem to find where that file is now... maybe I'll have to do another one.

If nothing else this is a fun and challenging project. I'm surprised the AC-3 data would look different from consumer data. I thought that back in the early consumer era, the consumer products used the same Zoran chip and that was a big part of what made the DA-20 and CP-500 so much more affordable because they could piggyback on the consumer production volume.

[Marcel Birgelen]

@David

Thanks for that info dump, I guess my Google capabilities let me down or I just didn't put in sufficient efforts.

I actually fed some of the scanned "fixes blocks" or how you want to call them through the Python script and I got an output...

The output indeed doesn't look like it's AC3 or nor does it look like it's AC3 embedded into something else.

What I remember about the Zoran chip is that it was more like a programmable microcontroller with some specific DSP operations for Fast Fourier transforms, etc. So the thing could probably be easily reprogrammed to support both EC9/11 and "consumer AC3". Running at 25 Mhz and with a 32-bit bus, it was pretty high-end for 1993.

I guess that even for archival purposes, it would be good if Dolby opened up their EC9/EC11 format to the world. It's not like they're currently actively selling or supporting any products that rely on this technology anymore and as such, it has become, what I'd call "abandonware".

[David Ferguson]

I thought that back in the early consumer era, the consumer products used the same Zoran chip and that was a big part of what made the DA-20 and CP-500 so much more affordable

What I remember about the Zoran chip is that it was more like a programmable microcontroller with some specific DSP operations for Fast Fourier transforms, etc. So the thing could probably be easily reprogrammed to support both EC9/11 and "consumer AC3". Running at 25 Mhz and with a 32-bit bus, it was pretty high-end for 1993.

Yes, that is my understanding too - the Zoran chip is a DSP that has ASIC circuitry and functions for doing the transforms needed for AC-3. You'll note that the DA20 has one cat 675 card with the Zoran chip on it, doing all the AC-3 decoding. However, the C500 has three cat 675 cards, one for AC-3, another for the matrix decoding, and another for the equaliser functions. So they are definitely not just AC-3 chips - they are fully programable DSPs, that just happen to have some AC-3 decoding ability.

If you read the datasheet for the Zoran chip (the datasheet is available, but the other documents are not), you'll see it can operate in a few different modes, which allow for accepting various types of AC-3 bitstream. However - it also has the ability to load from "user designed program in external boot-strap ROM, internal masked ROM or downl-loaded from host [...] to add product distinctions to industry standard decoder functions". I assume this is what Dolby is doing for all three of the cat 675 cards, loading in their own program that operates the Zoran chip exactly how they want it to.

So yes - the introduction of the Zoran chip did significantly reduce the cost of the DA20 compared to the DA10, however it's not just an off-the-shelf usage sadly.

Thanks for that info dump, I guess my Google capabilities let me down or I just didn't put in sufficient efforts.

I actually fed some of the scanned "fixes blocks" or how you want to call them through the Python script and I got an output...

I think that's my fault you didn't find it - it was only after I had written lots of info there, that I realised that Google doesn't crawl GitHub wikis! Quite frustrating, and I will probably move it somewhere else at some point.

And I think you're the first person other than myself to use the python script - hope it worked out okay for you! I'd also be interested to see a couple of your scanned images to see how well my script works on them - I suspect it currently works very well on the images I have, but maybe less well on other images that aren't quite the same as what I used for testing?

I guess that even for archival purposes, it would be good if Dolby opened up their EC9/EC11 format to the world. It's not like they're currently actively selling or supporting any products that rely on this technology anymore and as such, it has become, what I'd call "abandonware".

It would be nice, and if anyone has contacts at Dolby, maybe we could try a group approach? Perhaps if an official archive is asking for it, it'll be better received than just a guy who wants the spec because "I like the technology"! In my brief quest to try and find out more about SR-D I managed to get about as high as you can get at Dolby, and while there was comments from people glad of the interest, there didn't seem to be much enthusiasm to release any of this stuff.

[Lyle Romer]

It would require a DA-10 or DA-20 but I think it would be possible to extract the post video processing bit stream from the scanned images (which is pre-error correction) and feed that to the DSP cards and then extract the input to the DAC card and then process the PCM streams into whatever format you want to store it in.

It wouldn't be the the ideal software only solution that would be easily achieved with help from Dolby but I think it would work and not require a film reader.

[Scott Norwood]

I think that feeding the scans of the SRD blocks to a DA20 is probably the path of least resistance. The cat. 699/700/701/702 just contains a small camera (and optics and a light source). If you could play the image of the scanned blocks at the right speed and with the same resolution and scan rate into the DA20, it should output the sound just as if it had been read by the cat. 702 camera.

That said, if this is for restoration purposes, it might be easier and would definitely be better to go back to the 6-track printmaster (or DA88 or whatever) that is pre-AC3-compression, assuming that such a thing still exists.

[Marcel Birgelen]

The thing is, the output from the CAT699-702 is an analog video signal, not a digital signal. If you want to feed this back to a DA20, then you need to replicate this analog signal from the already scanned and digitized data, which is a bit of a detour, actually, a rather hefty one. Creating an analog signal that passes muster for the DA20 input circuitry will probably require quite some reverse engineering too.

I'd also rather want to go the route of decoding the digital data stream. I think David's idea may be worth a shot. I'll try to contact some people who I know at certain archives, maybe a group effort, asking Dolby to release this codec for archival purposes, may trigger something...

And I think you're the first person other than myself to use the python script - hope it worked out okay for you! I'd also be interested to see a couple of your scanned images to see how well my script works on them - I suspect it currently works very well on the images I have, but maybe less well on other images that aren't quite the same as what I used for testing?

I'll ask the owner of the print if he's fine with sharing some of the imagery. At least over at this side of the pond it's still legal to reverse engineer such things.

[Marco Giustini]

Would a Dolby Digital simulator - those boxes to test the input of a sound processor - be of any help maybe? Whatever it's generating, it happens digitally inside.