Time Code

gkantziper

gkantziper

Esteemed Member
I don't think anyone has figured out a way to jam time code with the HVX and OTHER types of cameras yet but I was hoping someone could point me in the right direction to seek out someone to develop this product for everyone to purchase. I don't know how much interest there would be in the product but it sure would be convienient for me to be able to do it. It would most likely be a box that has a firewire cable on one end and a BNC on the other allowing full size cameras to jam to the HVX. Any help would be appreciated.
 
I could see a small adapter that monitors the firewire output, strips out the TC information, then exports it to a BNC. However, this wouldn't eliminate drift problems unless they were always connected.

A few years ago, I produced a reality show with a Fostex PD-6 recording the audio, one Sony CineAlta, and three DVX-100s. (We needed six isolated channels of audio and used this project to test out this workflow.) While we didn't have an elegant way to jam sync the DVXs, we did get close manually. We'd hoped we could sync the audio one time for each tape and be good to go. The problem was that, even when we initially sync'd imported footage with the Broadcast WAVs from the PD-6, the DVXs would drift in an unpredictable manner, as many as 20 frames ahead or behind over a 45 minute tape.

So, even if you could get the initial sync down with an external box, how can you ensure it's truly frame accurate 45 minutes into the tape? And what if you're using two HVXs?
 
Barry has a procedure and a few notes about time syncing in his book. (One of his cautions concerns turning off the camera, changing the batteries, or switching to VCR mode, all of which may interrupt the clock progression.) According to Barry you can sync it with any DV device that does timecode over 1394, which should include the newer 'to disk' audio recording devices. If you can find a audio recording devise that can do both firewire and legacy time syncing then it may be able to serve as a timecode bridge between platforms.

The problem with building an 'adapter' would be that it would have to be a full-on microprocessor that could account for the latency that it is introducing into the stream. I do not know the timecode APIs but I assume that they are similar to the NNTP protocol which uses a series of challenges and responses to determine latency and sets the target computer's time by adding the latency to the time sent by the source computer. For it to be possible both API's must support challenge and response behavior.

The only other way to approach it would be to make a dedicated 'master of time' devise that would support both interfaces and APIs. Still a microprocessor, still difficult to build, but probably the best approach.

Bob
 
Last edited:
You must log in or register to reply here.
Back
Top