Tascam HD-P2 Sync DVX-100B

[Ted Spencer]

Only speaking for Avid MC, don't know how FCP does it, but as long as you have TC at the start of camera roll then Avid will fill out the remaining TC regardless of w/l drops or interference. Not 100% bulletproof but far better then standard w/l audio to camera. I have never had a single TC issue using this method to coordinate multicam shoots with prosumer cameras.

Cheers

That sounds like one of the jam-sync flavors, sometimes called "freewheeling" (see my next post) which is a very good thing to have in this wireless LTC scenario. The MOTU inteface will do the same thing, which would likewise pretty much bail you out. Better to have it solid, which would guarantee perfect lock at all times, but granted that especially for shorter clips, it might be overkill.

The issue is also much less hyper-critical in audio to video sync than it is in audio to audio situations (for music), which is more where I come from historically. A-to-A sync drift can be easily detected in the single-millisecond range (there are about 42 ms in a 24 fps frame). Jam sync will help you there, but you really don't want *any* errors with music synchronization if there's any way they can be avoided. Audio to video will generally look fine (which is what counts) with up to a half frame or so of out of sync-ness.

On that point it is truly horrifying to me how much badly synced A-to-V is put out on the airwaves, especially in Hi-Def. The audio for McCarver and Buck on the Fox HD broadcast of the World Series (I mean...the freakin' *World Series*...) had to be at least 5 frames earlier than the picture. I know it's due to the HD video signal's latency, but the solution is an absolute no-brainer - insert a digital delay on the audio feed, probably about 200ms or so. How this glaring oversight so often gets onto major network broacasts is beyond me.

But I digress...

I'm going to set up my HVX/MOTU/iBook G4 rig and try a few things, including a demo of the "Boom Recorder" software. I'll chime in again when I have.

 

[Ted Spencer]

Jam syncing (if folks are unclear on the term) is setting a TC generator by "jamming" in TC from another source.

Well, technically, the term for that is "regenerate" or "reshape" (feeding device A's TC into device B, and instructing B to generate new TC that matches A's).

"Jam Sync" (sometimes called "freewheeling"), strictly speaking, is a process that enables a chase-locked playback or recording device (aka the "Slave"), when set to do so, to ignore incoming timecode dropouts or inconsistencies from the "Master" (the device generating the TC) and carry on playing as if all was well, until it sees the correct code again, at which point it will ease itself (over the course of a second or so usually) back into hard lockup with the Master. The allowable dropout time can usually be set anywhere from a single frame to infinite.

Jam Sync not only deals with dropouts that way (fairly common) but, even more crucially, for handling edited timecode, like on a cut piece of tape (much less common, especially nowadays). So a tape edit causing a time code jump of any amount, a second, 8 minutes, whatever, will be ignored *numerically* as such by the Slave, but still used for sync as long as the Master's TC flow is uninterrupted. If the Master is stopped and restarted after the edit however, the Slave will then lock to the original code (now "wrong" due to the edit).

We used to use that type of Jam Sync all the time in the analog tape days of music recording (sadly, all but dead now, although I will never let go of my 2" 24 track!). Editing a tape that had preexisting LTC on it needed for lockup to a computer (or any number of other devices) wouldn't have been feasable in its absence. It usually took some additional steps to complete the job (like recording a new, regenerated TC track from the edited, Jam Sync-ed original), but it was the availability of Jam-Sync that made it all possible.