Timecode offset when laying back to DA98???

[dcaudio]

Hello,

When I layback to DA98 it seems that my audio is earlier by about 2 frames when I jog the DA98 over a 2pop. Instead of being at 00:59:58:00 the pop seems to be at 00:59:57:23 (I am working in PAL 25fps).

When I record what I have laidback into PT's the 2pop lines up and things look in sync. If I do an external timecode offset via session setup I can get the DA98 to look okay, but when I play that back and record into protools the 2pop is 2 frames late!

Alas, if I set a Time Code Reader Offset of -4000 samples then the tape looks good and the rerecording looks good.

But I am not sure why the offset is needed. For one, I have never had this problem before in the many shows that I have laidback in the same fashion. The difference might coincide with an update to 7.3, but I am not sure if that is when the problem crept up.

Any ideas?

I have it setup so Protools slaves the DA98. I also record tracks internally when I layback to DA98, but I have tested it both recording and not recording.

PT HD Mac 10.4.9, Delay Compensation ON

[Richard Fairbanks]

Do you have delay compensation turned on? That will definitely mess around with sync to live timecode! You'd think it would work correctly but in my tests it does not, they designed the feature in a way that fails with live timecode. One way to get around it is to print stems with ADC on, then turn it off to layback those stems to tape. The other way is to change the reader's offset like you did. I'll have to check my notes, which are not here at home, to say exactly what value worked in the offset. It might have been something like double the number of samples reported on the session setup window.

Of course, if your stems are pulled from sends that need less compensation than a final mix output, you have to figure that difference into the offset value.

I have no idea what happens if Pro Tools generates code with ADC turned on. Is the code in sync with the ADC'd audio?

[minister]

Do you have delay compensation turned on? That will definitely mess around with sync to live timecode!

I started noticig this the other day when a few tracks were exceeding ADC, my MTC (out of the Sync I/O) was going wonky on me. I shut off ADC, nudged my tracks, et voilá, solid sync.

[Richard Fairbanks]

I checked my notes. PT simply delays all tracks to match the longest delay through the system, just like the manual says. It does not pull everything forward so that delayed audio emerges in sync to external timecodes. You can force that to happen by using Timecode Reader Offset, using negative numbers to pull the audio earlier. Type in the same number of samples as total ADC delay (as reported on the Session Setup window) except make sure the number you enter is negative. This is a manual process that is a "sticky" setting. It is not saved with the session but stays in place when you open your next session. Really a bad workflow thing. I also think it did not work perfectly for me every time, but this might be because of the complexity of routings for various stems and submixes.

While I was doing those tests I also noticed another odd thing about ADC when using MOJO. ADC works when you have picture from MOJO, so the final audio emerges in sync with picture when you are working offline in a normal manner. That's good, as it should be. When locking to external code, ADC tries to drag the MOJO video out of sync with the audio, but somehow never lets it go out by more than a frame. It seemed like the audio could move more than a frame out of sync but not the MOJO picture. It is really weird. Good thing that is not a very normal situation.

I think somewhere along the way PT behavior has changed in this department, I thought I checked these things a couple years ago with different outcome. I don't know for certain, but my recent tests were performed with 7.3.1, cs2 maybe. I am certain this is the way PT is NOW.

[TVPostSound]

Call Tascam/Teac in Los Angeles (Montebello), I remember this problem from a place Ive worked in the past.
There is a firmware upgrade to fix that issue. The firmware FYI will also fix the 9 pin timecode problem where the workaround
was to patch LTC.

[Richard Fairbanks]

Did I misunderstand the first post? Is the problem ONLY with DA98, and not a different type of machine such as HDCam?

[dcaudio]

I have not been able to attempt this with another machine. I will try to see what happens with a digibeta, but nonetheless something is very weird with protools. This is not the weird part but just a little clarification on PT's behavior: I just entered a Time Code Reader Offset of -100,000 samples just to see how thing behave. The video track, being played out a Mojo, seems to play in sync with the Timecode of the DA98--cool. But the Protools timeline timecode plays back offset earlier(by 2 seconds in this case). This is crazy behavior, because how can I watch video to check for sync if it is by design being played back at a different time than the timeline.

And this is driving me extra crazy: no matter what the Time Code Reader Offset is set to when I check what I have laidback to DA98 by recording it into Protools it lines up as it should-- 2pop at 58! I feel real tired and maybe it is user error, but I would love DIGI to clarify the way these factors interact:

ADC, Mojo video, Time Code Reader Offset, External Time Code Offsets, and how all these things act while PT's is master and slave, and if and how these variables interact differently when protools is just playing back vs. recording simultaneously or just recording. Also does the setting for adjust after record pass under I/O effect these variables?

These are two many variables for me to think about. But I think it would be easier to understand ADC always could make processing delays disappear as relates to external timecode (i.e. certain tracks play back EARLIER to compensate for processing delays on that track).

[marspe]

If you have the "Confidence Mode" enabled on the DA-98 then you are actually monitoring off of the Repro head and not the Sync head. In that case, everything will be 2 Frames behind. Actually, it will only SEEM 2 Frames behind. It is being recorded correctly, as you've found out when you sync the 2-pops later, it just appears 2 frames behind during the layback.

[TVPostSound]

"Confidence Mode" I believe is 2400ms which is 7 frames.

[Richard Fairbanks]

But I think it would be easier to understand ADC always could make processing delays disappear as relates to external timecode (i.e. certain tracks play back EARLIER to compensate for processing delays on that track).

You pegged the problem, it is intuitive to think that tracks would begin to playback earlier so that they emerge in sync to timecode. I used to believe that is what happened. Unfortunately, that is not the way it actually works now. As the manual states, delays are added as needed so all audio emerges in sync with other tracks, and....well, there is no "and". The audio is delayed, period. When chasing external code the audio is out of sync, delayed, relative to the timecode position. You MUST type in a negative timecode reader offset to make your entire session playback early by the same amount as the audio is delayed by ADC. Confusingly, MOJO picture ignores that setting and follows its own rules.

If any of our readers are chasing PT to code on a dub stage, are you aware of this behavior?

Heaven only knows what is happening if you are generating SMPTE instead of chasing it, such as you might want to do while laying stems out to several blank DA98 tapes. I have not checked that scenario. Maybe someone else can check it out and let us know for certain.

I would love DIGI to clarify the way these factors interact: ADC, Mojo video, Time Code Reader Offset, External Time Code Offsets, and how all these things act while PT's is master and slave, and if and how these variables interact differently when protools is just playing back vs. recording simultaneously or just recording. Also does the setting for adjust after record pass under I/O effect these variables?

I would like some clarification also, or to know that it is a fixable problem that is being put on a list somewhere.