Hey, guys...sorry to miss some of the party...I'll play a little catch up now...
ivan40 wrote on Sat, 29 May 2004 21:05 |
Hey click. Wazz--uupp;
|
N'much...just chillin...oh...I guess that wasn't the question you were looking to have answered...
Quote: |
you have more experience then me with this audio for video stuff so,answer this question for me will ya? How long will audio against video run together without drifting? { With no sync} I know it depends on the stability of the transports and so on but, it can't be long can it? I guess if you do enough slates [Click sounds} on the audio that are matched to visual cues on the video, you could keep it together.
|
It won't be long at all...in fact, depending on the frame rate in use, the audio versus the video drift will probably become noticable after a few seconds. Fully intolerable not to long after that. The reasoning is in how the frame rates versus audio rates got developed.
I won't go into the details of why audio started with 44.1k and then, as technology allowed, expaneded to 48K and above. If you're not too sure, do a google search on the Nyquist theorem and the spectrum of hearing for the average human ear. For film, however, they use a few different rates for different things. I'll assume 29.97 DF (drop frame) for the next bit, as this seems to be used alot for video work in North America (24 fps is widely used as well, but when and why is beyond me...ask a video guy on that one.) In drop frame counting, you drop the 0th and 1st frame of the first second of every minute except for any minute that is divisible by 10 (and you thought audio was complex! At least we count from 1-10 all the time!). As a result, there is a perpetual accounting being done in the camera time to fix issues with the line rates of the screen.
If your audio, being as simple as we audio guys like it, doesn't account for this, then each minute (except for those divisible by 10) the audio will slip farther ahead than the video. Needless to say, it won't be long before it becomes painfully apparent that the audio is out with the video.
Quote: |
I guess one thing to do is load the audio AND video into a DAW and just keep movin' hacked up bits of the program until it's all locked up but man, What a pain in the ass!! I don't know if my idea will work or not but it's all I could think of.
|
Some programs automatically take care of this internally if they are capable of loading video into your audio project. It asumes that the video is master and slaves the audio now-time to the video now-time. It will slightly speed up or slow down the audio in order to account for the drop frames. Again, this is something that I'd prefer to avoid...its better to be in sync as it is happening. If you have a device to read the video black burst and generates a word clock and LTC for your multitrack, you are 100% done with sync issues. When you edit in post, you set your multitrack to slave playback to video and voila...the machine will do your work for you. (I'm basing this, by the way on the DA-x8 series. I haven't used other variants of multitracks with video sync.)
Quote: |
Another question I have for you clicktrack is this. Can the Composite video out put of the camera generate a clock signal? I don't know how this stuff works as well as I should. I've done some post scoring but, that was easy enough as the video sent over was 3/4" sony with time code on the screen and we just printed everything to dat and the post house did finals {jingle stuff for auto industry} so, dose the video out have to be digital to have clock info in it? Thanks for your reply.
HEY debuys, are you still out there? hope some of this is helping. Don't let it overwhelm you bro. You can do it. We'll hang and answer.
|
You've got me on this one. I would assume so, but I'm not sure if a clock can be generated by it. Again a blackbust signal to a black box (MOTU box, JL Cooper box) that generates clock and LTC will be all you need to get this done easily.
Quote: |
Remember that, just having time code on the video camera isn't enough. You need to have code from the cam and from the adats running into a box that can compare the two codes and control the speed of the adats.
|
Amen. That's the word. In my earlier discussion yesterday I inferred the LTC (SMPTE or MIDI Time Code) as well as the word clcok, but you are correct that both are needed. The word clock is the stable count to lock all digital signals to. The LTC is the count of clocks that gets applied to tape, and that both devices will refer to. Hope this wasn't too misleading.
Believe it or not, this stuff isn't too complex. Let the machines do the work for you. All you need to care about is that the multitrack is slaved to the incoming video and once that's done, you're good to go. The machine does the rest of the work for you.
Cheers