Results of video syncronizing tests

[Richard Fairbanks]

I promised I would put up a more detailed discussion of video sync from within Pro Tools. Rather than clog up the DUC, I've decided to post a somewhat long page on my website. Much easier to maintain, too.

Video to audio synchronization within a Pro Tools workflow

Please don't shoot me, I'm just the messenger.

[philper]

Thanks. Confirms some suspicions I had.

Philip Perkins CAS

[Sonsey]

Richard...

Thanks for the great service. And here I thought I was just losing my mind with the sync issues on DV. Just one quick question with your DV tests as I'm not likely to be able to get new hardware in here right away... Did you check the different Playback Priority settings with the DV boxes? Just trying to get the least amount of drift until I can upgrade...

Thanks again for laying this out in such a straight forward manner... Makes it so much easier to go to the boss with your article in hand

[Richard Fairbanks]

Did you check the different Playback Priority settings with the DV boxes?

Yes I did, and there was no difference. I neglected to mention it, I'm glad you asked me about it.

[ProToolsguy56]

Good article.

The 4ms delay you speak of on standard NTSC TV, can this be eliminated if the TV has a video sync input on it to receive house sync?

I want to test if the SYNC I/O can accurately resolve to the frame edge corresponding to the grid in the pro tools software window / timeline. Any ideas how to test this?

Another thing Richard, how reliable is the Sync IO? Does it ever jam up when feeding it erratic messed up horrible LTC? LTC variable speed by the way from a scrubbing/rev master machine controlling the SyncIO?

I'm considering buying the Sync IO but want to know more about it.

[Richard Fairbanks]

No, the composite video signal itself is "house sync". It is made up of timing and image data combined. Professional monitors have a separate "sync" input, but using it should show exactly the same result.

Believe me, 4ms is not an issue to worry about. I consider it as close to perfect as is practical. If you understand how the video signal is put together you will see that a couple of milliseconds are used at the very beginning of an NTSC frame for control and sync signals. The first 20 scan lines are used for things like closed captions, VITC, control, time of day, whatever. In addition all consumer monitors "overscan", which means they expand the size of the image to more than cover their screens. This can be another 10-20 lines wasted above the viewable screen. It is likely you will never see anything at all until the 40th scan line or even later! The 40th scan line occurs about 2.5ms after the video frame edge. In an ideal world this is what my gear would show, but I have given some allowance for using the entire image as a whole. The whole image is not fully built until around 15ms have passed. Depending on exactly how much of the image you take in to measure with, and where that part is within the whole (upper left corner where the image building begins vs. lower right where it finishes, for instance) the timing will vary, relative to the exact frame edge. The whole idea of where the video image visually happens is a somewhat arbitrary "fuzzy line".

More about the video signal

The SyncIO with Pro Tools is very good at resolving to the frame edge, when Pro Tools wants to do so. As pointed out in my article (you read it, right?), I only see this happen when PT is "online" and generating or chasing timecode. An advantage to using V10, MOJO, AVoption, or AVXL is that PT always resolves to video frame edges without having to be online. Any of those options force audio and video frame edges to be aligned whenever there is video.

What I am about to say is not aimed at you, ProToolsguy56. As a rule I cannot answer whether any piece of gear is "right for me". My point is to help people understand what is REALLY involved in getting audio and video to sync together. It is not as straightforward as you might think.

[ProToolsguy56]

Nice. That explains the delay thing.

>The SyncIO with Pro Tools is very good at resolving to the frame edge, when Pro Tools wants to do so. >As pointed out in my article (you read it, right?), I only see this happen when PT is "online" and >generating or chasing timecode

Yes, this is exactly my inquiry. Now, exactly how did you test if it is "very good" at resolving to the frame edge.

You also say that it will only happen if pro tools is ONLINE and generating or chasing TC. Does this mean if you have a SYNC I/O, have it fed house sync, have nothing connected to the LTC or VITC ports, but use the transport within pro tools software..but hit ONLINE, that you will be aligned with video?

[TVPostSound]

The SyncIO with Pro Tools is very good at resolving to the frame edge, when Pro Tools wants to do so. As pointed out in my article (you read it, right?), I only see this happen when PT is "online" and generating or chasing timecode.

I dont agree here, when loopsync is properly cabled, and the SYNC I/O is the video reference to my 192, the 192 becomes loop, and the SYNC I/O becomes loop master, locking the 192 to the SYNC I/O

[Chief Technician]

how reliable is the Sync IO?

As a master clock when fed blackburst, it is very reliable. I have observed (posted in some other thread recently) that it is less tolerant of blackburst signal errors than other devices I've used, including VTRs. Basically, this means that if something is not proper with your blackburst signal, the SYNC I/O will let you know (by not synchronizing with it). I consider this alone to make it very reliable.

Does it ever jam up when feeding it erratic messed up horrible LTC?

I think you mean to say "Does PT ever jam up when fed erratic messed up horrible LTC?". If its fed erratic LTC, it will certainly have to take some time to re-lock to the SMPTE timecode. If you are referring to the process of loading dailies, where discontiguous timecode is the norm, v6.4 and later (not v6.4.1) has a function called RecordLock where PT will sync to incoming TC, stop when the TC is gone, and resync when it resumes.

LTC variable speed by the way from a scrubbing/rev master machine controlling the SyncIO?

SMPTE cannot be read reliably at less than 1/10th of playback speed. If you are controlling a machine and expect PT to follow at such a slow speed, you will need to use VITC to maintain synchronization (or work with non-linear picture).

[ProToolsguy56]

>I consider this alone to make it very reliable.

For me the Sync IO would be slaved to other devices, both word clock, and LTC so it would only be used chasing. And of course house sync fed to it. What i mean by reliable is, does it ever crash or freeze...the actual SYNC I/O? And when I say freeze I mean, does it ever have to be turned off then on again to get it unfrozen?

>I think you mean to say "Does PT ever jam up when fed erratic messed up horrible LTC?"

I meant to say does the SYNC I/O or Pro Tools ever jam or freeze when fed horrible erratic back and forth, scrub, shuttle LTC.

>SMPTE cannot be read reliably at less than 1/10th of playback speed. If you are controlling a machine >and expect PT to follow at such a slow speed

My main concern is that the DAW won't freeze or somehow have to be re-booted. Not that if it can follow LTC at slow speeds. Also, when SYNC I/O is slaved to P2 working with Serial Time Code is it possible to super slowly move frame by frame in slow mo or can one only get this with VITC?