Wow Tom, looks like some progress! Those patterns look promising. Interesting that ffmpeg recognises it as some form of AC3, since it doesn't have the standard AC3 packet header. MPC-HC must be getting something wrong, as it should be about 10 seconds in length, not 1 second.

(2021-07-13, 01:01 PM)TomArrow Wrote: 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.

Did you look at the frame sync channel at all? If you look at figure 8 in the datasheet (shown below), you'll see that it shows the start of a 16 bit frame on the falling edge of frame sync. If that's not what you did, maybe that could be a cause of error?



I'm also not convinced that my logic analyser is working 100% - I'm pretty sure there shouldn't be those random spikes in the data channel between the blocks. Once I get this better logic analyser (probably not for a few days at least), I'll see if that makes any difference.

I would suspect at this point that there is little to no error correction in the data - as I was capturing it after it has gone through the reed somonon decoder (twice).

---

(2021-07-13, 01:01 PM)dvdmike Wrote: I wish CDS got more of a push, so sad.

Because CDS had no backup analogue track, it required a dual inventory of prints and meant that a digital failure meant no sound at all. Both of these made it unviable.

Well it's possible that MPC-HC just thought of it as AC-3 by accident because the file ending is that, idk. But I did a few earlier tries where I did the decoding incorrectly and those weren't recognized at all. It interpreted it as Quad (4.0) with 44100 kHz. Where ffmpeg interpreted it as 2.1. However ffmpeg also threw an error message saying it might not actually be ac-3 and only misdetected. It also wasn't able to actually decode any audio.

What you call sync channel, I called the block channel. Aka I interpreted each pulse that had the sync channel active as the first bit of a new 2-byte part, as mentioned in my description of the method. You can have a look at the code too, I linked it in the last post.

I think the random spikes are likely correct. They do, after all, align nicely with the clock. And that's not a given, since the signal is oversampled by your logic analyzer. For each clock state, there appear to be between 3 and 5 samples or so captured. So about 8 per data bit? If that is noise, it sure is the strangest noise I've ever seen.

Does the sync signal mark the first bit of the new 16bit word or the last bit of the previous?

If you look at figure 8 in my previous post, to me it looks like the falling edge of the sync signal marks the start of a new 16 bit word. But you should probably read the datasheet yourself in case I'm misreading or misunderstanding something!

I know ac3 packets normally have a header detailing the bit rate, number of channels, etc. It's possible/likely this is missing from these blocks, as such information is fixed in the cinema implementation of Dolby Digital (always 5.1, 48 kHz, 16 bit, 320 kbps).

I stumbled on this Forum,

Here is something i found out after watching the Youtube video.
This data is the same in all „Data fields“ (as Dolby calls them)






ASCii
01000100 D
01001111 O
01001100 L
01000010 B
01011001 Y
00100000
01010010 S
01110010 R
00101010 *
01000100 D

I also found this in the patent, which indicates that the regular pattern in the post before is data if the data block is good or has errors

(2024-07-19, 02:39 AM)SG_UNAM Wrote: ASCii
01000100 D
01001111 O
01001100 L
01000010 B
01011001 Y
00100000
01010010 S
01110010 R
00101010 *
01000100 D

Yes, in all SRD blocks containing audio data, the text "DOLBY SR*D". You'll note that 3 out of every 96 blocks don't contain this - those are the non-audio "bogus blocks". Every block also contains a reel and block number. I have previously written up everything I know about the SRD format at https://github.com/davidferguson/dolby-s...ing-Format

(2024-07-19, 10:21 AM)davidferguson Wrote:

(2024-07-19, 02:39 AM)SG_UNAM Wrote: ASCii
01000100 D
01001111 O
01001100 L
01000010 B
01011001 Y
00100000
01010010 S
01110010 R
00101010 *
01000100 D

Yes, in all SRD blocks containing audio data, the text "DOLBY SR*D". You'll note that 3 out of every 96 blocks don't contain this - those are the non-audio "bogus blocks". Every block also contains a reel and block number. I have previously written up everything I know about the SRD format at https://github.com/davidferguson/dolby-s...ing-Format

I‘ve read through you git, can you send me the Printmaster?
How did you get the Printmaster or if you have created it, can you send some info about lenght and the
original file from which the printmaster was created from.
I want to print a test film for reverse engineering.

(2024-07-19, 12:07 PM)SG_UNAM Wrote: you git

bit harsh

Yeah watch the language.

Haha, I'm assuming that "you git" was supposed to be "your git", meaning my github page on the format description of Dolby Digital on film.

I just sent you an email about the printmaster, hope that we can keep working out this format.