Sync/TC Instability When Recording From VTR

[Tom Smith]

Okay, here's a weird one that I'm hoping the more experienced of you can shed some light on...

Recorded about 2 minutes of audio via AES audio into Pro Tools (HD 7.3, Sync I/O, digital only 192) from an SRW-5500 tape. Everything sync'd, time code matched, happy indicator lights everywhere.

Made a few edits in the captured region, inserted it back into the same tape. Next day, client wants another change near the previous one so I ingested the same section as the day before with an additional few minutes at the head and tails so I'd have the audio for the latest change.

This is in the same Pro Tools session I'd used previously, same deck, same tape, and under the same conditions. But I saw immediately that the region I just recorded was somewhere between one quarter and one half frame later than what I had recorded the previous day.

I then ran some tests using a scratch tape. In PT, I created about a 2 minute long region with 1 frame long audio pops every second and layed it back to the tape. Disconnected the deck from PT & used a remote controller to play and jog the tape to verify my pops were recorded in the right spots. It all looked good.

Then I re-recorded the same section back into the same PT session. The new region was 2072 samples late. I re-recorded to new tracks in PT four more times while trying different sync settings in PT. Every time, the recorded region was later than the original one. The tightest I could get it was 470 samples late. Pretty small, but enough to bother me. And the fact that I got different values for each pass is especially disturbing to me (even two subsequent passes with the same settings were 400 samples different).

The way things are sync'd in this facility seems a bit odd to me: Sync is distributed through some kind of generator/router (an Evertz something I thnk) and when laying back to an SRW deck, PT is locked to an SD reference while the deck is locked to an HD ref. Both reference signals are generated by the Evertz and, I'm told, are phase aligned. The Sync I/O seems happy but...

Am I expecting too much from what I'm trying to do? I was expecting "near" sample accuracy but maybe 470 samples IS near and I'm just being fussy.

Anyone have any ideas on this?

[Postman]

MmmHmm, yeah, no, that doesn't sound right. What frame rate? Are you using machine control or chasing code. LTC or serial TC?

[Tom Smith]

Yes, using machine control, 23.976FPS, serial time code, typical normal stuff...

[Chief Technician]

Originally Posted by Tom Smith

Yes, using machine control, 23.976FPS, serial time code, typical normal stuff...

Ah, while this all appears to be typical normal stuff, there are key pieces of information here that lead me to believe your problem lies in the way you are working. The first is that you are using a SYNC I/O, and not a SYNC|HD. The primary difference is that the SYNC I/O cannot lock to tri-level sync. This, in turn, makes it impossible to use 23.976 serial timecode reliably, as the timecode address of each 23.976 frame has no relationship to each sync pulse at 29.97. This relationship of timecode addresses corresponding to frame edges is required for serial timecode to work properly. Try all of your tests while using LTC from the VTR as your positional reference. I think you will then get the results you expect.

[hummerZ]

and the HDCAM-SR decks suck.

[Tom Smith]

Originally Posted by Chief Technician

Ah, while this all appears to be typical normal stuff, there are key pieces of information here that lead me to believe your problem lies in the way you are working. The first is that you are using a SYNC I/O, and not a SYNC|HD. The primary difference is that the SYNC I/O cannot lock to tri-level sync. This, in turn, makes it impossible to use 23.976 serial timecode reliably, as the timecode address of each 23.976 frame has no relationship to each sync pulse at 29.97. This relationship of timecode addresses corresponding to frame edges is required for serial timecode to work properly. Try all of your tests while using LTC from the VTR as your positional reference. I think you will then get the results you expect.

Well, I suspected it was on me. Funny thing is that I explicitly chose to use serial time code thinking it would minimize or eliminate the disparity between the two time codes (in retrospect, I don't know where I got that idea).

I've just about got the shop I'm working at to upgrade to a Sync HD, but I think that'll take a couple of months to push through with the money people.

In the mean time, do you think it would better to run my PT sessions at 29.97? The deck can be clocked from an SD ref, translate TC and has a format converter built in (which I use all the time anyway since the tapes are 4:4:4 and my pix monitor will only do 4:2:2)...

[Chief Technician]

Originally Posted by Tom Smith

In the mean time, do you think it would better to run my PT sessions at 29.97?

No.

The deck can be clocked from an SD ref, translate TC and has a format converter built in (which I use all the time anyway since the tapes are 4:4:4 and my pix monitor will only do 4:2:2)...

I know. We have an SRW-5500. I say no above because of my testing with an AJ-HD3700B (D-5 HD). The timecode converter on that deck certainly works, but I could not get the spot-on results I was looking for. I don't have notes in front of me, but my session was at timecode rate A and my tape was at timecode rate B. Every so often, frame addresses are supposed to match. I believe it is every 3 seconds. So when I laid audio beeps to the tape, and then brought it back into Pro Tools, they should have matched every 3 seconds. They did not, though they were not egregiously off. I don't recall this phenomenon happening when using the same timecode rate for the session as what is on the tape.

[quadraphonics]

This is an issue when running Serial Time code without locking tri-level sync. I have run tests with the SRW-5500 recording back sync pops and the variation is +- .75 frame.

Randall

Originally Posted by Tom Smith

Yes, using machine control, 23.976FPS, serial time code, typical normal stuff...

[Tom Smith]

Originally Posted by quadraphonics

This is an issue when running Serial Time code without locking tri-level sync. I have run tests with the SRW-5500 recording back sync pops and the variation is +- .75 frame.

Randall

That seems to be about the same variance (from pass to pass) that I'm experiencing. In my situation, that is on top of a consistent four frame delay.

I also found out from engineering that the sync situation is a bit more unusual than I first thought: as I understand it, HD sync and SD sync signals are coming from two separate sources, each referenced to a common source, then sort of "hand aligned" (using an o-scope I presume, and tweaking some trim pot somewhere).

I'm really pushing them to acquire a Sync HD, but in the mean time I'm trying to develop a work around to get us through the current job.

[quadraphonics]

We use a Brainstorm box here which will output HD and SD video black.
As for the sync to and from PT, when doing what you describe I reference to AES and use LTC for time code referece. I just keep in mind that I will have to nudge the input 4 frames prior to laying it back.

Randall

Originally Posted by Tom Smith

That seems to be about the same variance (from pass to pass) that I'm experiencing. In my situation, that is on top of a consistent four frame delay.

I also found out from engineering that the sync situation is a bit more unusual than I first thought: as I understand it, HD sync and SD sync signals are coming from two separate sources, each referenced to a common source, then sort of "hand aligned" (using an o-scope I presume, and tweaking some trim pot somewhere).

I'm really pushing them to acquire a Sync HD, but in the mean time I'm trying to develop a work around to get us through the current job.