Problems with DTS 70mm Playback

[Michael Zarits]

In any case I doubt it would take 20 seconds to eventually go to the next reel.

My thought was that in platter mode it only switches to P2 when there's no timecode present at P1 and that the tail leader of P1 has timecode for another ~20 sec, thus P2 kicks in only when P1's timecoded tail leader runs out 20 sec after the LFOA.

[Randy Stankey]

I never used DTS on anything but platters and I never would have thought of this until Michael mentioned it. I think he might be right.

One way to test this hypothesis would be to slide a business card (or similar) into the reader just after the changeover. If you can get a helper, have them slide the card into place when you make a call-out. Otherwise, just have the card handy and do it yourself.

If the sound switches over more like it should then you can look at the settings (jumpers? DIP switches?) on your player and make changes if you think appropriate.

If the sound doesn't switch any better then you have eliminated one possibility without having to make changes to your system.

As Thomas Edison is quoted as saying, "I haven't failed one hundred times. I have succeeded in finding one hundred ways that don't work."

[Marco Giustini]

Steve,

Jerry already confirmed the XD20 is on the latest version - but great catch! There is nothing else on FT in term of software, besides a very old 2.00.43 I think. I kind of assumed that the latest version was the one to use.

Michael,
interesting. If I check the logs again, I see that there isn't a "TC: DROP" message at the end of Reel 2. The file ends. THEN, there is an edit from 2 to 3 AFTER the end of file.
So you might be right, the reel reaches the end, the sound file ends. The TimeCode continues. Only when the TimeCode physically disappears from the reader, then does the player consider P2 and there is an edit.

On other prints, the Timecode is stopped earlier and the XD20 happily moves to the following reel.

[6] [Sep 11 17:50:01] SndTrk: Edit from 19:12:26(0320) to 00:03:12(0740) [29]
[6] [Sep 11 18:00:13] TC: Edit from R02 10:12:17 to R02 10:12:19 [29]
[6] [Sep 11 18:07:45] SndTrk: EOF (17:41:06(0988)) [29]
[6] [Sep 11 18:07:46] DTS Audio OFF [29]
[6] [Sep 11 18:07:46] Format OUT: P4-SR-D [29]
[6] [Sep 11 18:07:53] TC: Edit from R02 17:50:04 to R02 17:50:06 [29]
[6] [Sep 11 18:07:53] TC: Edit from R02 17:50:08 to R03 00:20:03 [29]
[6] [Sep 11 18:07:54] SndTrk: Check - SN:14197 R:3 L:LAST[1] [29]
[6] [Sep 11 18:07:54] SndTrk: Open 413168976486a6680fb5f95a93aa08a2.snd "Joker " C:5 SN:14197/0 R:3 L: ENG [29]
[6] [Sep 11 18:07:54] Nar: Check S:14197 R:3 [29]
[6] [Sep 11 18:07:54] SndTrk: Edit from 17:41:06(0592) to 00:19:12(1180) [29]
[6] [Sep 11 18:07:55] DTS Audio ON [29]​

Randy,
Yes, I have recommended Jerry to do similar tests earlier in the thread to get more data points.

I am going to drop this here but I have this weird feeling that both heads are plugged to the same input! I don't even know if that would work but...

[Steve Guttag]

Marco...he said "Latest Version" but did not specify what version that was. Don't assume. It could be the latest version that he is aware of or the newest they had on site. So, Jerry, what version are you running, can you confirm?

[Marco Giustini]

ahah - I have to assume something sometimes or I lose my sanity.

Here I am assuming that if Jerry is not sure about what the latest version is, he would ask!

I would be "Supremely Disappointed" (cit.) if he's not running the latest version!

[Markus Lemm]

I've been creeping this topic for a few days. Thought I would throw in an idea on something to check.

It seems that the problem occurs when there is film running through both readers at the same time.

On the DB9 at the back of the XD20 usually one reader goes back to pin 1 and the other projector to pin 2. But if someone made a custom cable and accidentally got both readers on one pin or both pins are touching, then you would get a double signal and the result would be the problem you are experiencing.

Basically you get an overlap of tail reel 1 with head leader of reel 2 signal on 1 pin. DTS would count that as unreadable and drop out after 4 seconds (about 1 second after the change over).

Then the tail leader of reel 1 would continue to overlap with the head of reel 2 until reel 1 passes through the reader, again causing unreadable signal, another 10-15 seconds depending on the tail leader length and what's printed on it.

Then it would have a clean signal from reel 2 and DTS would kick in again.

My suggestion is check the DB9 on the back of the XD20 and check pin 1 and 2, see if they are both being used and not touching each other.

[Michael Zarits]

For my understanding a 'double' input from both readers on the same pin should render the signal unreadable but there is valid timecode until R02 17:50:08 which is already way into the tail leader of R2 with R3 already running for ~14 seconds since FFOA on the other projector at this point:

[6] [Sep 11 18:07:53] TC: Edit from R02 17:50:08 to R03 00:20:03 [29]

LFOA of R2 is already at 17:34:05 - This is the moment R3 timecode kicks in and would render the timecode unreadable but there is no event in the logs at all.

[Marco Giustini]

Markus

All inputs are very welcome of course. However...

I am going to drop this here but I have this weird feeling that both heads are plugged to the same input! I don't even know if that would work but...

Let's suppose the timecode input is pulled high (or low) by the timecode board in the player and the reader is pulling it low (or high) to create the data stream, what you (we) suggest might be possible.

What doesn't work in my head is that if that was the case, then when P2 starts, BOTH timecode would become garbage and the player would report a TC: DROP - which it doesn't. (Michael also mentioned that while i was composing this message!)
But at this stage, I feel it's wise to take a look at that cable!

[Markus Lemm]

Thanks Marco, I guess I missed your comment about the same input suggestion. Sorry.

Agreed, checked the cable and how the DB9 is wired.

Only other thing would be to wipe the hard drive on the XD20 and do a clean install. Could be just a bunch of corrupt sectors on the drive.

[Ryan Gallagher]

Thanks Marco, I guess I missed your comment about the same input suggestion. Sorry.

Agreed, checked the cable and how the DB9 is wired.

Only other thing would be to wipe the hard drive on the XD20 and do a clean install. Could be just a bunch of corrupt sectors on the drive.

Yeah I had suggested re-ingesting the soundtrack also, similar direction of inquiry. But Jerry did say he tested with two distinct XD20 processors... so HDD issues seem unlikely, unless he's just got an incorrect soundtrack file (also seems unlikely).

There is always the possibility that there was a bug in a firmware version. I see that Film-Tech has 2.2.06 for the XD10 and XD20. I'm curious if that is what is in use on this unit and if not, try updating to that. I seem to recall that Brad has worked out what the ideal firmware are the most solid.

I just downloaded it and check out the big improvement for the XD20:

image.png

So, if you are not on 2.2.06, I suspect that we've found the issue.

But we may all just be running in circles troubleshooting a KNOWN XD20 BUG, as Steve pointed out, we never actually got Jerry to confirm exactly which version he is on other than citing "latest" in his response. Considering how "spot on" that release note sounds to this particular behavior, I think circling back to that basic question is definitely worth while. It would also explain why XD10s seem to have no problem with these prints in question (in other booths), even perhaps on older versions.

And if he's on 2.2.06 already, I think the next logical tests would be to actually confirm the timecode cabling is correct (again), as has been suggested.

If everything is as intended with the cabling, try the LED block test with a helper in the booth to see if the timecode changeover can be forced to occur sooner without the dropout?

Distinguishing between excessive timecode on a tail after the file ends triggering the bug versus overlapping timecode on the same pin might be tricky, as the blockage card kinda tests both situations. If one wanted to get "real serious", one could add a breakout board before the processor to give you test points for a scope on the timecode pins and actually confirm that the signal does indeed change over to the other reader/pin and is not all coming in on a single pin (or shorted to both pins etc).

If that test works, perhaps there is still some buggy behavior with the XD20 in this area, being exacerbated by these unusual prints as Brad suggested, but keeping an eye out for tails with excessive timecode and just covering them with a stripe of artist tape or cue tape might be the low-tech solution? If they have an existing splice, just take the tail off and add a length any suitable leader without DTS in it's place? Or just bite the bullet and score an XD10, if it is an XD20 specific problem that cannot be solved without undesirable modifications to prints.

Jerry already said he is intending to test with an XD10 soon, so we may know soon if the problem vanished. If so, very likely it was not the cable or readers, and maybe DTS/Datasat have an issue with the XD20 playing past the first frame of picture, which comes to a head when printed reel timecode is longer than the reel file?

[Marco Giustini]

I really don't think there is such thing as "excessive timecode" here, the system should be designed to operate change-overs WHILE the ending reel is still running.

However there aren't many XD20s, I have never seen one myself! So who knows, maybe this is something DTS would have fixed by software if they were still around!

In any case checking timecode with an oscilloscope is also a good idea. It should give more data points to this situation.

[Ryan Gallagher]

I have specific interest in learning if the XD20 is ultimately to blame, as I have one sitting in front of me slated to maybe become our cold or hot spare processor in my booth.

[Mike B. Smith]

The XD20 was one of the best film-based products DTS made, it was always very reliable but it also could be complicated in configuration. How it’s configured can affect how it reacts to automation cues and what it will do or not do with loss of time code. Most cases it’s best to set Format automation for DTS-6D emulation.
Sound change over with the DTS is independent from your normal change over which in most cases includes douser and switching Projector optical. It does not follow an Even Odd pattern but simply looks for the correct reel and serial number and confirms the audio track matches.
What I’m understanding is the same system works fine when configured for 35mm film playback, that should eliminate quite a few things however, my first thought would be to check the “Y” timecode cable, I have seen on rare occasion factory cables not being correct.
My other suggestion is to check the automation, disconnect the automation cable from the XD20, select DTS format on your audio processor, now perform the change over and see what happens, no format switching should occur on the audio processor but the DTS audio should switch to the incoming projector when the change over occurs.

[Marco Giustini]

Thanks Mike - if I remember right you were part of DTS in the past.

Did I dream that even/odd pattern with older players or was that actually a thing?

Good point about the automation, I am unfamiliar myself with the new automation schemes introduced with the XD10 where the player would only be activated when the proper format is selected on the Sound Processor. It would be worth take a look at that, Jerry: how is your automation set on the XD20?

The Y-Cable was not pre-made by the factory so it's certainly worth double-checking that.

[Ryan Gallagher]

I really don't think there is such thing as "excessive timecode" here, the system should be designed to operate change-overs WHILE the ending reel is still running.

The "excessive timecode" relates more to Brad's input an memory that there were a handful of modern 70mm prints where Fotokem was doing unusual or inconsistent things with timecode on the tails. Perhaps there is some out of bounds behavior when a print is unusual like this that is specific to the XD20s, it would require Jerry reporting on the presence of non-presence of timecode all the way out through the tails on his testing print. But I think getting confirmation of v2.2.06 first is the first step.

The XD20 was one of the best film-based products DTS made, it was always very reliable but it also could be complicated in configuration. How it’s configured can affect how it reacts to automation cues and what it will do or not do with loss of time code. Most cases it’s best to set Format automation for DTS-6D emulation.

This is a good line of inquiry too, My XD20 here installed factory defaulted to "DTS-6D emulation" in automation format->"operating mode"... but perhaps Jerry's is configured otherwise. If he is using it for 35mm there is a good chance he is using the automation features to control the fail-over format too. So doing a test without automation physically connected for 70mm and the default or alternative automation formats seems worth while too. Way back in the thread someone also wondered if the automation might have an impact too.