SRD Read Errors during changeover, and missing Bias data?

[Ryan Gallagher]

We noticed a couple things we had not seen before on a new CineLab 35mm SRD print. Expert conclusions?

We were running WinDRAS just to keep an eye on things, and we noticed the following quirky behavior:

1. WinDRAS was not drawing the bias graph, as it has with ever other print. What can cause this?

2. During a subsequent projector motor ramp up within a changeover sequence, SRD would error out and fail over for a good chunk of reads until the changeover actually occurred. We are used to seeing some errors at poorly timed changeovers, but this was a different situation. I assume maybe the sproket codes were printed in the leader well before sound start, and maybe that was the cause? I did not think to check that until after the print was packed and onto the next festival venue.

Equipment was a CP650 and Dolby 702s.

Title was "Normal".
Normal (2025) - IMDb (Technical: Normal (2025) - Technical specifications - IMDb)

BTW it was Scope 2.39 without any annoying lab under sizing.

IMHO the print felt a little "dark" compared to some scope films we have played, but there were also some serious color pallet/tone choices going on in this film in the cooler temp ranges that may have given that impression.

Other than the weirdness at the changeovers, this print ran with excellent 0-1 error range. Great tracking.

[David Ferguson]

2. During a subsequent projector motor ramp up within a changeover sequence, SRD would error out and fail over for a good chunk of reads until the changeover actually occurred..

SR•D is supposed to buffer the changeover part of the audio data during the reel playback, so that if the blocks during a changeover are scratched, dirty, have tape on them, etc. then the audio can be played from that. This is called the “splice cache”. But it sounds like this didn’t happen for you - or perhaps it did. I think the processor will still show errors during these bad block reads, and there isn’t a visible indication that it is reading from the splice cache.

Did the audio drop out? Or did the processor just show errors?

[Marcel Birgelen]

I remember doing a changeover with two Kinoton FP30Es, where one side was consistently borking on the Dolby Digital... Later we figured out the left machine was configured to run at 25fps for whatever reason, whereas the other one was running at the correct 24 fps, so the CP500 wasn't able to sync both sources. The errors we got from the CP500 weren't really all that descriptive either.

Maybe the projector had a bad time during ramp-up and it took more time than in the splice cache is able to buffer, to get to a stable speed?

[Ryan Gallagher]

No drops, and to be honest I don’t think our reversion count was incrementing during these, although that memory is less clear. I assumed it was reverting based on how many bad blocks were noticed in the histogram after the fact, but it may not have exceeded a cache.

The 24 vs 25 fps is an interesting note, but our operator controllers can really only do 24 or 30fps, unless you use variable manual mode. 30fps is noticeably different sounding on the machine, so one catches leaving the knob in the wrong position quite promptly!

It was only the week before that I checked how matched our sprocket RPMs were with a tach. Still matching, have not ever had to adjust that, both have v-belts.

[Marcel Birgelen]

Unless you can recreate what happened, it will be difficult to figure out what exactly caused it. I guess we've all had some "random", unexplainable dropouts of SRD over the years.

Regarding the 25fps thing: You won't that easily register the difference between 24fps and 25fps, but 25fps v.s. 30fps is easily noticeable in pitch and also projector sound. This 25fps is somewhat of an oddity, but more common here than in the U.S. due to the PAL 50Hz base frequency. Before capturing to video was the default, capturing stuff on film at 25fps was pretty much all there was to archive stuff. So, a lot of stuff was filmed for 25fps, especially stuff like newsreels. It's pretty rare to find anything in color that's supposed to be played back at 25fps. A lot of 24fps stuff also ended up sped up to 25fps. As a matter of fact, this latter practice never really ended.

[Marco Giustini]

SRD buffers the data around reel changes but not by much if memory serves. Is WinDRAS reporting errors the moment you turn on the second projector? What does the processor error rate say? I've seen discrepancies over the year.

I've also seen WinDRAS not drawing some of the graphs - which version are you using?

How are your "Motor" start wired? What do the M and P indicators say on the front panel when you start the second projector and then do the changeover?

[Lyle Romer]

From what I remember the buffered data was called "splice caching" or something like that and was designed to prevent dropouts when a splice messed up the data. It wasn't necessary for changeovers using 2 projectors because the data stream would be available for the projector being changed over to and the system was designed to handle that.

[Marcel Birgelen]

The splice cache also works for little change-over inconsistencies. Apparently, every 3 out of 128 data-frames are used for special payloads, like the infamous software update form EC9 to EC11, but also the "splice cache". The splice cache contains a number of frames from the end of the current reel and the start of the next one. I'm not sure how many frames exactly, but this buffer is used to overcome read errors at splices and also small issues during changeover. Normally, during a change-over, there is an overlap between left and right and therefore there should be no loss-of-data similar to a splice, but a delayed ramp-up or early cut-off could cause such an issue.

Besides using error-correction to repair damaged frames, SRD also compensates for entirely lost frames, at least to an extend, by interpolating them, instead of producing silence or doing an immediate failover to digital. All in all, it's a remarkably robust protocol for the time it has been designed.

[Ryan Gallagher]

The latest available version of dolby alignment software (WinDRAS 1.042)

Yeah realize I missed my opportunity to diagnose only thinking about it after the fact. I feel like I even witnessed one of those bad blocks sequences while my counterpart was threading. This print had tons of black before countdown from the lab. I wonder if there was dolby code on all that black and as he was bumping projector forward through the black it got confused as well. I don't know enough about how the CP650 would attempt to recognize code coming from the other projector, well before the changeover.

I did not notice what the P1 & P2 lights were doing during the block reading glitch.

Noted on the cache, yeah a splice type cache makes the most sense.

[David Ferguson]

Apparently, every 3 out of 128 data-frames are used for special payloads

Correct, these "bogus blocks" (as Dolby Called them) are the result of an audio sample rate calculation that I can't quite remember off the top of my head right now. You can actually identify which blocks are bogus ones, if you either scan the blocks and blow them up, or use a good enough magnifier.

like the infamous software update form EC9 to EC11

I'm still trying to find data on this. EC9 was still well in use into the 2010s, and while there were reports of "bad updates" bricking processors, I have only heard about this third hand (actually more like eight-hand or higher!) and simultaneously, I have heard first hand from Dolby employees that this never actually happened. Whether that's a rose-tinted view of it, or whether it's true and failures were down to other issues, I'm not sure. If you have first-hand info, let me know!

[Paul Finn]

I believe the CP650 recognizes each projector running from the individual "motor run" input signal lead from each machine. This is true for all DD processors or digital adapters.

Paul Finn

[Marcel Birgelen]

I'm still trying to find data on this. EC9 was still well in use into the 2010s, and while there were reports of "bad updates" bricking processors, I have only heard about this third hand (actually more like eight-hand or higher!) and simultaneously, I have heard first hand from Dolby employees that this never actually happened. Whether that's a rose-tinted view of it, or whether it's true and failures were down to other issues, I'm not sure. If you have first-hand info, let me know!

I think we're using the same sources and details are sketchy. I'm by no means a specialist in this, what I know, I know because I've did some half-assed attempts at trying to decode SRD a while back.

Regarding EC9 still in use in the 2010s: I guess there were a few labs that simply never upgraded. Keeping stuff at EC9 ensured it worked on all SRD equipment out there.

But, according to "lore", every EC11 movie to this time, still has the EC9 to EC11 software update in there, in those "bogus blocks". Unfortunately, Sam Chavez has since left us, someone like him could probably have shed some light on this...

AFAIK, Dolby never licensed their optical format to somebody else. Since the format is essentially dead, it would be nice if they would donate it to the world... but I guess that will never happen.

[David Ferguson]

Unfortunately, Sam Chavez has since left us, someone like him could probably have shed some light on this...

AFAIK, Dolby never licensed their optical format to somebody else. Since the format is essentially dead, it would be nice if they would donate it to the world... but I guess that will never happen.

I actually did ask Sam, and he was going to answer a few things, but sadly that never happened.

Dolby did license it to one place: Cinevation for the Cinevator. However they are even harder to get info out of than Dolby - they won't even tell me what labs have a Cinevator (and that was me wondering where I could get film printed!). Dolby won't donate it to the world, I asked them about this and there's still enough commercial use, plus it would have to go through an expensive internal legal review, so that won't happen. But never say never...

[Ryan Gallagher]

I believe the CP650 recognizes each projector running from the individual "motor run" input signal lead from each machine. This is true for all DD processors or digital adapters.

Paul Finn

I'll have to play with that with two reels to see if we can cause the same error blocks behavior I was noticing while treading/advancing. We have a big sound changeover button that is separated from everything else too. I've never thought to check if the 702s will output sound regardless of which projector the changeover button is pointed at. Is that what you are saying would happen as long as it is is wired to the motor start that way (ie one takes over as soon as the dolby code is present, rather than waiting for a manual change)?

[Tony Bandiera Jr]

I had a conversation with Sam some years ago, and he did caution me that, despite what the DRAS manual claims, using DRAS while running features for the public isn't a good idea. He had experienced problems with sound dropouts and other errors. (Most were with platter operations and he didn't say if changeover operations were affected.)

He explained that DRAS is somewhat "intrusive" and intercepts the reader's digital data before it hits the processor's D-A chips and could cause problems.

It is intended for use ONLY as an alignment aid in conjunction with an oscilloscope, and NOT as a continuous use QA tool.

I have also had issues with sound dropouts during my own testing and alignments with it, even on test loops or prints that were otherwise "error free".