Long takes, no lockits

[Richard Thomas]

I've been talking to a producer about a gig coming up on Saturday, recording some live music to 2 C300's.

I've strongly suggested hiring in some lockit boxes to keep both the cameras and audio in sync, but they seem pretty confident they won't need them (and I'm not).

They're not looking at using the whole take, and just using excerpts for a promo video, will it be manageable in the edit to send them a scratch track to each camera, even though it's very likely the files on each machine will be different lengths?

[Jim Gilchrist]

My experience with the C300 platform is that it's less than stable and lots of different operator actions (going into playback, changing media, rebooting and so on) can cause the camera to drop code, from resets back to zero to dropping several seconds. I'd strap a sync box to them myself.

Best regards,

Jim

[Philip Perkins]

I've done a lot of concert shoots with X number of prosumer cameras, most of them much more primitive than a C300, with no sync I/O. What we found was that if we locked the AUDIO down--really stable clock, and sent an audio scratch track to as many of the cams as we could (wireless is good), with the cam mics on on the others, then the cameras were close enough to make an edit possible with some fiddling (which they will end up doing anyhow, trust me). So I'd clock your rig really well, jam the C300s and

hope for the best.

phil p

[Marc Wielage]

Make sure the editor is aware they will need to make manual audio sync pull-ups here and there. It's doable, it's fixable, and I've had to do it myself many times on concert shows in the last 15-20 years. Not that big a deal: just listen until you can hear it's getting out of sync, chop a few frames, and move on.

It's better if you're shooting with a whole bunch of cameras, since it increases your chance of being able to cover up the edit pull-up, but you can still fake it. I'm always amazed in concert shows how many shots are flown-in throughout the show that did not happen chronologically, or were even completely faked (like shot at a totally different shows). I can think of many huge, world-class artists who've used these tricks in their concert shows -- and it looked absolutely fine on the air.

[ccsnd]

copy/paste

So first thing to mention, time code and clock source are two very different things independent of each other. The similarity between the two are that they both use a clock (does not need to be the same clock)

Lets start with timecode.

Timecode is little more than an arbitrary number that gets added to the meta data when you hit record. Syncing the camera and whatever devices does nothing more than to make this number the same across multiple devices. Time code drift should not do anything to the length or quality of a file.

Next is word clock.

A word clock is a device whose sole purpose is to control the frequency that a digital sample (or word) of audio is taken. at 48,000hz, this happens 48,000 times in 1 second. No clock is made exactly the same and all have some amount of jitter. (a slight difference in the amount of time from one sample to the next.) It is for this reason that when you try to connect two digital signals together (adat or whatever) you get clicks and pops. Those clicks and pops are the direct effect of jitter within 2 different clocks. Using a common word clock like a big ben runs the sample rate from one common device eliminating this process. A good quality word clock has very low amounts of jitter compared with a poor quality word clock. In all word clocks there will be some kind of drift. It is the length of the recording and quality of the clock itself that will dictate how bad your drift is.

[Richard Thomas]

Thanks very much guys, especially Phil and Marc. I'll clock my gear with an SB-3 and send scratch to the cameras. I've made sure production know what the files will be like.

[ccsnd]

an sb3 will not solve your sync problems as I stated above. You need genlock.

[Marc Wielage]

Correct -- all cameras should be running with common genlock and timecode. One SB-T or Ambient Lockit per camera will do the job.

[Philip Perkins]

an sb3 will not solve your sync problems as I stated above. You need genlock.

He doesn't need genlock to lock down any sound recording system that will clock itself to incoming TC, which is nearly all of them. Genlocking cameras to the audio clock, to each other, is preferable, but we get away without a lot of the time and the cut works out anyhow, if laboriously.

phil p

[ccsnd]

He needs genlock because the camera clocks and the audio clocks are different and of different qualities. running an hour long take on different clocks will generate a different number of frames and samples for each device including audio. Who cares if the time code number is correct of not, what matters more is if all devices have takes of the same length.

Time code and word clock are two very different things. Just because one is good, does not mean the other is good as well.

In this case, genlock is infinitely more important than timecode.

[Glen Trew]

I've been talking to a producer about a gig coming up on Saturday, recording some live music to 2 C300's.

I've strongly suggested hiring in some lockit boxes to keep both the cameras and audio in sync, but they seem pretty confident they won't need them (and I'm not).

Gen-lock is to keep the cameras locked together, not to keep sound in sync with picture, unless a sync signal (AES or word clock) is used to slave the clock of the audio recorder, which is not what's being discussed here . Genlocking a camera (such as with trilevel sync from a Denecke SBT or Ambient Lockit) will not keep picture in sync with sound. For the scenario described in the original post, a Denecke SB3, jammed from the audio recorder, connected to each camera for a common timecode source is all that's needed.

Glen Trew

[Philip Perkins]

Gen-lock is to keep the cameras locked together, not to keep sound in sync with picture, unless a sync signal (AES or word clock) is used to slave the clock of the audio recorder, which is not what's being discussed here . Genlocking a camera (such as with trilevel sync from a Denecke SBT or Ambient Lockit) will not keep picture in sync with sound. For the scenario described in the original post, a Denecke SB3, jammed from the audio recorder, connected to each camera for a common timecode source is all that's needed.

Glen Trew

If the source of the genlock is a generator that also makes TC (that is in sync with the video sync signal) then that can be used very well to keep audio recorders in sync with cameras, since the audio devices can lock their own clocks to the incoming TC. We've done concert shoots in dozens of different variations on this method, with cameras that were genlocked, with cameras that weren't, and with lots of different combos of both, some with Lockits some w/o. If the audio was really steadily clocked then the sync could be worked out in post very easily, and was, with all those cameras, over takes up to 2 hours or so. Our recent tests with the C300 (the cameras the OP was using) indicated that it held TC sync quite well over an hour or two. That doesn't mean that two C300s would be in genlock style frame-sync if they weren't connected that way, but the point is that in a digital-file-based workflow that is not important most of the time anymore. (Except for 3D.)

phil p

[Marc Wielage]

Yeah, the trick with 3D is that the timecode phase can drift slightly over time, essentially creating a subframe slippage. Once the timecode slips too far, the actual shutter of the camera gets out of sync, wreaking havoc with 3D accuracy. I know of a few major features where timecode issues like this cost well over $100,000 to fix.

I agree with Phil that genlock is not 100% mandatory in a concert, and you can get away without it for non-critical purposes. A frame or two out in an hour is trivial for any reasonably-competent editor. It's a bit of a headache if you have a dozen cameras, especially if they're stopping and starting, but if everybody starts at the same time, and roll/card/drive changes are infrequent, it's not that much of a nightmare. I don't have a lot of experience with the C300 -- it's a really tiny camera, and my biggest objection is that there's no place to mount anything on it! -- but it seems to be stable and make decent pictures.

I have done concert post projects where camera and sound timecode led to many issues. In the analog days, we'd create a "base tape" that just had all the sound for the entire concert, then we'd laboriously drop the picture in as an insert edit, one camera at a time, and make adjustments to make sure it stayed in sync. If the picture drifted, we'd find an appropriate place to do a pull-up (like a whip-pan or something that would obviously not be used), and make an edit.

I seem to recall a Van Halen project I got involved in during the mid-1980s, and it was a combination of standard def video, mini-DV, super 8mm, and 16mm, and that was kind of a cluster-F. But we sorted it all out, and it worked out fine. In that case, the syncing issues probably added 1 full day to the post schedule, so it wasn't a deal killer.

[Richard Thomas]

Ok, job was done today. I did stongly suggest genlocking the cameras to production but they didn't hire lockits.

I could only get hold of sb-2's from the rental company (all the sb-3's were out) but we ended up running 2 HD-P2's (with one run by another recordist) clocked with them running LTC as clock source (thanks Phil, for your post about them successfully syncing audio clock to TC).

I also jammed both cameras before each hour long roll and sent a scratch track (in addition to mics on the cameras).

Now to find out how it goes (no news is good news, right?). Post know the cameras aren't synched, but sound should be.

[ccsnd]

timecode isn't the issue here, it never was. the issue is the jitter and drift between all devices. the hdP2 is not known for its wordclock accuracy and i assure you that there WILL be drift issues.

[Richard Thomas]

According to the manual and Phil it will sync its audio clock to TC rate. Have dropped the audio files from both recorders into nuendo, had a quick listen and they seem to be in sync throughout

[ccsnd]

These go to 11

............................ I give up.

[Philip Perkins]

............................ I give up.

Well, may you should. Have you used the equipment being discussed here in this kind of situation? Some of the rest of us, now incl the OP, have, and it has worked out well. The HDP2 has perfectly fine wordclock (and TC) accuracy when it is on an external clock. That clock can be word clock, trilevel or SD video sync or timecode. Jitter doesn't really come into play in this situation, in my experience. I've recorded large ensembles across two computer-based recording rigs, an SD recorder and an HDP2 all roped together with wordclock and/or TC, along with several video cameras and it worked out very well: we had no jitter issues and the mixes went fine.

phil p

[ccsnd]

Well, may you should. Have you used the equipment being discussed here in this kind of situation?

Sure have. Not only have I owned and used all of this equipment, I have helped many others solve the problems that long takes with low quality wordclocks cause.

The HDP2 has perfectly fine wordclock (and TC) accuracy when it is on an external clock. That clock can be word clock, trilevel or SD video sync or timecode. Jitter doesn't really come into play in this situation

Jitter plays a huge roll in a situation where you have a device with a not so good word clock over long takes. That clock cannot be trilevel or sdvideo sync or timecode. Again, all of these are completely different things. Wordclock is wordclock, timecode is timecode.

I've recorded large ensembles across two computer-based recording rigs, an SD recorder and an HDP2 all roped together with wordclock and/or TC, along with several video cameras and it worked out very well: we had no jitter issues and the mixes went fine.

phil p

if it worked out fine you would have had to had wordclock roped together. TIME CODE WOULD HAVE DONE NOTHING FOR YOU. (other than giving you an arbitrary number entered into the metadata)

to reiterate, just because you synced time code, does not make your word clock magically better.

[Glen Trew]

If the source of the genlock is a generator that also makes TC (that is in sync with the video sync signal) then that can be used very well to keep audio recorders in sync with cameras, since the audio devices can lock their own clocks to the incoming TC. We've done concert shoots in dozens of different variations on this method, with cameras that were genlocked, with cameras that weren't, and with lots of different combos of both, some with Lockits some w/o. If the audio was really steadily clocked then the sync could be worked out in post very easily, and was, with all those cameras, over takes up to 2 hours or so. Our recent tests with the C300 (the cameras the OP was using) indicated that it held TC sync quite well over an hour or two. That doesn't mean that two C300s would be in genlock style frame-sync if they weren't connected that way, but the point is that in a digital-file-based workflow that is not important most of the time anymore. (Except for 3D.)

phil p

Genlocking the cameras will keep the cameras in sync, but using using a trilevel sync/timecode generator to send timecode to the audio recorder will not keep the cameras in sync with the audio recorder. The timecode at the beginning of each file will be the same, on picture and sound, which will get sound and picture started in sync, but continuing sync is dependent on how close the sound recorders internal clock sync oscilator is to the camera's genlock signal. But with this method, it should be no surprise that sound and picture maintain lip sync for a one or two hour take, because this is well within the tolerance of the internal clocks of all of the commonly used timecode audio recorders. This also means that an external timecode generator for the audio recorder is not needed. While it can be a nice thing to have as a jam reference in case the audio recorder's timecode get reset, it is not needed to maintain sync over a long 1 or 2 hour take.

Glen Trew

[ccsnd]

Glen, my last experience with the dr680 (which I believe has the same clocks) is that it was about 1 frame slow after about 14 minutes.

48/24

We were using an f3 and a 5d. we all cut when the 5d hit it's 4gig mark. Every take had this drift.

[Richard Thomas]

to reiterate, just because you synced time code, does not make your word clock magically better.

I know the difference between TC and wordclock. Note, I never even mentioned TC in the original post- it was more a question of how much hassle it would be for post by going with what the producer wanted.

We're talking about setting up the recorders to sync their audio clocks (ie wordclock) from a TC signal. It'll be re-clocking at 25 times a second rather than 48000. I didn't know they could do this until Phil mentioned it (and thought they needed wordclock sync). MOTU audio interfaces will also do this, and some other sound recorders.

I stated that I wanted to get everything in tri-level/wordclock sync, but the situation meant this couldn't happen and did what I could with the equipment available. I think the editor's going to be able to get what they need from what we've done for a 5-10min promo (from 2hrs of footage), even if the cameras drift.

My original plan was to use a 744T and SB-T's on the cameras, but couldn't make the cable runs and needed to separate the two recorders and the producer didn't think they needed sync boxes. 702T's weren't available and 2 744Ts were too expensive.

[Philip Perkins]

Genlocking the cameras will keep the cameras in sync, but using using a trilevel sync/timecode generator to send timecode to the audio recorder will not keep the cameras in sync with the audio recorder. The timecode at the beginning of each file will be the same, on picture and sound, which will get sound and picture started in sync, but continuing sync is dependent on how close the sound recorders internal clock sync oscilator is to the camera's genlock signal. But with this method, it should be no surprise that sound and picture maintain lip sync for a one or two hour take, because this is well within the tolerance of the internal clocks of all of the commonly used timecode audio recorders. This also means that an external timecode generator for the audio recorder is not needed. While it can be a nice thing to have as a jam reference in case the audio recorder's timecode get reset, it is not needed to maintain sync over a long 1 or 2 hour take.

Glen Trew

If the TC is being generated by the device also making the sync signal, and the audio recorder is BOTH jam synced to the TC AND is referencing its own sample clock to the incoming TC (as most professional recorders do) then the audio recorders will be in in dead sync with cameras that are also on the same clock/TC (ie jammed Lockits) for a fairly long period of time. If one used as Lockit on the recorder to generate external TC, the sync lock would be even tighter, but that has proven to be unnecessary in practice (ditto with hard-wiring the TC). With an HDP2, the TC (and thus clock ref) has to be from an external source, like another Lockit, but if you do that and set up the HDP2 correctly then the setup will be as accurate as any. They all stay in sync, and if the clocks are good (Lockits in good repair) then there is very low jitter. The audio from all those devices (incl camera audio) can be combined in a mix without problems. I have done this--it worked very well. The DR680 cannot be clocked in the same way as an HDP2 at all--it only has the ability to take external SPDIF, not WC, video sync or TC, and its internal clock is not very accurate at all so it is much harder to integrate into a system like that described here.

In the lower-budg world we get by pretty well by making sure the audio is as accurately and steadily clocked possible, and doing whatever can be done (sometimes about nothing) to sync the array of cameras in play.

(Roughly set their internal TC generators if possible, ie "3-2-1-GO sync"; audio scratch tracks, slates, TC displays,

etc etc).

phil p

[ccsnd]

If the TC is being generated by the device also making the sync signal, and the audio recorder is BOTH jam synced to the TC AND is referencing its own sample clock to the incoming TC (as most professional recorders do) then the audio recorders will be in in dead sync with cameras that are also on the same clock/TC (ie jammed Lockits) for a fairly long period of time. If one used as Lockit on the recorder to generate external TC, the sync lock would be even tighter, but that has proven to be unnecessary in practice (ditto with hard-wiring the TC).

TIME CODE AND WORDCLOCK ARE TWO DIFFERENT THINGS. THE ONLY THING TIMECODE DOES IS ADD A NUMBER INTO THE METADATA. THE WORDCLOCK DOES NOT SYNC TO THE TIMECODE CLOCK. NO PROFESSIONAL RECORDER DOES THAT.

TRY A GOOGLE SEARCH FOR THIS INFORMATION, BECAUSE YOU ARE CLEARLY NOT GETTING IT WHEN BOTH I AND GLEN HAVE TRIED EXPLAINING IT TO YOU SEVERAL TIMES.

[ccsnd]

also, unless you have a constant connection, a poor timecode clock will still be a poor timecode clock. Jamming the device does not make a TC clock more accurate, it only makes the numbers the same. how long those numbers stay the same is up to the recorder's own tc clock. this is why we keep sync boxes on the red cameras

and again, having a constant connection to timecode sync does nothing for your wordclock. that is a completely independent separate thing.