Long takes, no lockits

[Jim Gilchrist]

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.

Hey soundguy,

Cut it out, OK?

Philip Perkins knows what he's talking about.

When Phil talks about making a bunch of cameras, both toy and otherwise, play nice together with the tracks he's recording he has considerable experience doing same, often editing, syncing and doing the sound mix.

Telling somebody who is a major source for this group (which is a major source for sound mixers and recordists) to Google how to do this will be a waste of time for him as he will have contributed to most of the hits that result from that search as many will have come from this forum.

Tale a look at Phil's IMDB page here.

Best regards,

Jim

[ccsnd]

Phillip does not know what he is talking about. Time code is not word clock. syncing one does not do anything to the other. I don't care if he has imdb credits. He is wrong.

[Philip Perkins]

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.

Yes, time code on a BWF file is merely additional information added to the metadata. But TC as a signal stream contains clocking information as field-rate. A professional recorder can use this information as an external clock for its sample rate. Sound Devices recorders do this automatically, an HDP2 can be made to do this via its menus, as can various computer audio interfaces. In other words, the recorder can derive its sample clock from the field rate of the TC. A recorder like an SD machine has its own TC generator locked to its own internal clock, which is why it can serve as a master clock on a project--the TC and WC it makes are in sync. In the case of a jam-sync between a recorder (which then runs on its own clock) and Lockits sending both sync and TC to cameras, we stay in sync because the clocks in the Lockits (making TC in sync with the video sync signals they output) and the clock in the recorder are of high enough quality (ie TXCO) that they will drift away from each other only very very slowly. In situations where absolute set and forget sync is required, a master sync generator would generate trilevel sync that would drive the cameras and drive a TC generator whose TC would be distributed to the cameras and to audio as well. Audio would NOT be receiving word clock from the video rig--only TC. Audio would input this TC, the sample rate of the audio systems would lock to the field rate of the TC, and the result will be audio files in dead sync with the video recordings. Thus while TC and WC are not the same thing, the former can be made to serve the function of the latter in appropriately equipped devices.

Feel free to disagree, but please stop shouting.

phil p

[Toy Robot]

Angry threads are often the most informational.

[Marc Wielage]

Phil is correct: timecode can be as accurate as word clock, depending on the specific equipment used. When I've worn my post hat, I've had to do tons and tons of major live concert TV shows (Garth Brooks, Barbra Streisand, Linda Ronstadt, John Fogerty, Rolling Stones, Fleetwood Mac, you name it), worrying about sync and keeping multiple cameras kosher. And those projects were all based on timecode, not word clock.

We all know that timecode and word clock are different. As far as I'm concerned, word clock is essentially like a genlock video sync reference signal. If word clock is sample accurate, then it'll work -- it's just not as convenient and precise as timecode in terms of locating where you are in terms of picture and track.

For your purposes (and for your editor), I think word clock would work, but I think that giving each camera has an audio scratch track as a backup is a wise move. It's not unusual to have to jig and jog things a little bit here and there in the edit. In fact, I'm often very surprised by how many "grab" shots editors will use from a completely different song or take, just because the moment works for the song.

[ccsnd]

Lets use an extreme example.

lets say you have your timecode setup correctly at 23.976. Everything is set up absolutely perfect except for one thing. You recorded at 44 instead of 48.

When the editor imports all the footage to a timeline set up for 48, your timestamped file starts right exactly when it should because your timecode is correct. You hit record at exactly this minute/second/frame and that is exactly where it got put in the timeline. Very quickly the audio and video will drift apart despite starting at exactly the same time. This is because the clocking speed of the wordclock was way off. Every file starts at exactly the right time because your time code was right, but every file itself drifts.

You recorded your audio at 44,000 samples / second and you are playing back at 48,000 samples / second. Again, the file starts at the right time, right in sync with the clap but by the end of the take you are several frames off.

Now a device with a bad wordclock is the exact same thing, but just less severe. With timecode set up correctly the files start exactly in sync, but by the end of a 2 hour long take, you are several frames off. even if your wordclock was set to record at 48,000 samples per second, that doesn't neccisarrily mean that at the end of a 30 second take that you recorded (48,000 x 30) 1440000 samples. lets say a poor quality wordclock actually recorded 1430900 samples of audio, which comes out to an average of 47696.6666666/second. (a really bad wordclock)

When you pull that file into your timeline, your timeline will want to play the file back at 48,000 samples / second. that file will play back slightly quicker than it was recorded. For your 30 second takes that difference might not be noticeable and just fine and dandy, but when you record like that for two hours, you can bet you will notice it by the end of the take.

The time code only says when the file starts. It does not sync the wordclock or keep track throughout the length of the file. Timecode has no say how long a file is or should be, or how many samples of audio are taken. When you hit record it only makes a record of the exact minute/second/frame you hit record and put it into the metadata. Nothing else.

[al mcguire]

> keeping multiple cameras kosher<

let me pre-apologize if I offend anyone but how can you tell if you are working with a kosher camera ?

is the mat box trimmed back ?

[Philip Perkins]

Lets use an extreme example.

lets say you have your timecode setup correctly at 23.976. Everything is set up absolutely perfect except for one thing. You recorded at 44 instead of 48.

When the editor imports all the footage to a timeline set up for 48, your timestamped file starts right exactly when it should because your timecode is correct. You hit record at exactly this minute/second/frame and that is exactly where it got put in the timeline. Very quickly the audio and video will drift apart despite starting at exactly the same time. This is because the clocking speed of the wordclock was way off. Every file starts at exactly the right time because your time code was right, but every file itself drifts.

You recorded your audio at 44,000 samples / second and you are playing back at 48,000 samples / second. Again, the file starts at the right time, right in sync with the clap but by the end of the take you are several frames off.

Now a device with a bad wordclock is the exact same thing, but just less severe. With timecode set up correctly the files start exactly in sync, but by the end of a 2 hour long take, you are several frames off. even if your wordclock was set to record at 48,000 samples per second, that doesn't neccisarrily mean that at the end of a 30 second take that you recorded (48,000 x 30) 1440000 samples. lets say a poor quality wordclock actually recorded 1430900 samples of audio, which comes out to an average of 47696.6666666/second. (a really bad wordclock)

When you pull that file into your timeline, your timeline will want to play the file back at 48,000 samples / second. that file will play back slightly quicker than it was recorded. For your 30 second takes that difference might not be noticeable and just fine and dandy, but when you record like that for two hours, you can bet you will notice it by the end of the take.

The time code only says when the file starts. It does not sync the wordclock or keep track throughout the length of the file. Timecode has no say how long a file is or should be, or how many samples of audio are taken. When you hit record it only makes a record of the exact minute/second/frame you hit record and put it into the metadata. Nothing else.

We are talking about two very different usages of time code, possibly being used at the same time. We are in agreement that a digital recorder in its normal state (on its internal clock) will only use its timecode to stamp the file's metadata, the actual speed of recording is dependent on the sample clock of the machine. However, the usage I have been describing uses timecode in a 2nd, different way, as a continuous data signal, that has a clock rate with in it: field-rate. The setups I've been describing use the incoming TC stream in two ways: first as a source of the file time stamp, and second as a data stream from which the recorder can extract field-rate with which it references its internal clock. As I've said, this is often how large multicam shoots record audio in sync with video cameras--the video dept is not sending word clock to the sound dept, usually only TC. In a professional recorder like SD, the time code generator IS continually synced the the recorder's word clock--the same clock references both. This is why one can use an SD recorder as the master sync generator for uses like computer based recording--one can take both the TC and the WC out to your computer audio interface which will then maintain perfect sync with the audio recorder, and even if the file start times are different a given timecode address (as counted in from the time stamp) will be referring to the same instant of recorded time. One can also do this same kind of setup with timecode only, if the receiving device can use the incoming TC as its clock reference. (Not all can.) You give an example of editorial pulling in two files recorded at 44.1 and 48k respectively--in the case of Final Cut this is done all the time--48k projects often have 44.1k music or SFX files from CDs used in them, and the Final Cut system sample rate converts the 44.1 file for playback on the fly (and later renders them for export).

phil p

[studiomprd]

" The time code only says when the file starts. "

SMPTE TC really involves a lot more than that, as the specifications call for clocking/timing signals at specified rates, and accuracies.

I'm not buying into the 44 / 48 stuff, (did you mean 44.1 ?? still not buying in) a 44.1 would be converted to 48, or vice-versa...

[Max Hirtenstein]

One can also do this same kind of setup with timecode only, if the receiving device can use the incoming TC as its clock reference. (Not all can.)

Thanks Phil, that answers a question I had in an earlier thread. I'd be grateful if someone could elaborate on which devices can do this. I'm guessing not too many cameras can?

[studiomprd]

" which devices can do this. "

something you determine one by one as your need arises

[ccsnd]

" The time code only says when the file starts. "

SMPTE TC really involves a lot more than that, as the specifications call for clocking/timing signals at specified rates, and accuracies.

I'm not buying into the 44 / 48 stuff, (did you mean 44.1 ?? still not buying in) a 44.1 would be converted to 48, or vice-versa...

it was just an extreme example... It will not convert for the jitter issue. Also if somehow there was an error in the file header.

[Philip Perkins]

Thanks Phil, that answers a question I had in an earlier thread. I'd be grateful if someone could elaborate on which devices can do this. I'm guessing not too many cameras can?

My experience doing this is with audio devices: hardware file recorders like SD, and certain computer interfaces like MOTU Traveler. Some cameras seem to do ok with this as well. I was on several crews with very experienced video engineers who wanted only the TC signal from my Lockits connected to their cameras (multiple cameras), with no sync signal connected. This was contrary to my experience (which says you need both), but these guys were LA episodic professionals so I did things their way. I never heard back about sync issues, either way. These cameras were Sony 900s. In tests the Canon C300 did ok with this, the REDs did not (ie drifted anyway). I try to stay out of camera tech unless asked, although I do go down to a close-by rental house to do tests when I can. But I do make sure that the audio is locked to as steady a clock as I can manage all the time, no matter what the situation is (so if there is time-drift it is all on the camera side).

phil p

[ccsnd]

jamming timecode or a constant time code connection will. not. help your word clock.

Lets try it this way.

They are 2 different types of streams. Timecode is a data stream with the 1's and 0's (on,off) that is then red by your recorder.

wordclock is simply a stream of 1's and 0's that signal when to take a sample of audio. at 48k, a on and off mode are repeated 48,000 times in a second. the 1 signal is the cue for the sample.

one cannot be read by the other.

If this was not the case why do most timecode generators also have a WC out as well?

[Philip Perkins]

jamming timecode or a constant time code connection will. not. help your word clock.

Lets try it this way.

They are 2 different types of streams. Timecode is a data stream with the 1's and 0's (on,off) that is then red by your recorder.

wordclock is simply a stream of 1's and 0's that signal when to take a sample of audio. at 48k, a on and off mode are repeated 48,000 times in a second. the 1 signal is the cue for the sample.

one cannot be read by the other.

If this was not the case why do most timecode generators also have a WC out as well?

There are lots of TC generators w/o WC outputs! Lockits are somewhat unusual in that you have a choice of WC or video sync. The Denecke boxes (SBT, SB3) can not make word clock, to name 2.

As I've explained, while WC and TC are two different types of data streams, much of the equipment sound people use can use TC to serve the function of both. In that case the TC is acting as a reference governing the generation of the recorder's sample rate, as word clock would if it was available. On video shoots, word clock @ 48k is usually NOT available, and of the recorders we've discussed in this thread, only the HDP2 can take video Tri-Level sync directly. So we take TC, and use it in place of word clock. This incoming TC is entering the recorder through a timecode input, not through a WC input. On some recent multicam video shoots video has had an AJA GEN10 sync generator, from which I COULD get AES black (if they can spare an output), but has been a great deal less hassle to take just a TC feed (from their generator being fed by the GEN10) than a TC feed and an AES feed (since I was moving around). But on most video jobs I end up on, even with 2 or 3 cams, they are not using a central sync+TC generation system, they want to just use Lockits, and have them jammed to my recorder's code. That seems to be more or less the Standard Drill, for me anyhow, these days.

phil p

[ccsnd]

the sbt is made to go on to the camera. It sends a genlock sync (rather than WC) as well as timecode. Those are both separate as well. Here is the picture clearly showing both.

As for the SB3. It does have both TC and WC. I know this for fact without doing the research because that is how it is set up in my cart. but for those of you that do not want to browse away from this page, here is the picture of the SB3 as well.

[Philip Perkins]

the sbt is made to go on to the camera. It sends a genlock sync (rather than WC) as well as timecode. Those are both separate as well. Here is the picture clearly showing both.

As for the SB3. It does have both TC and WC. I know this for fact without doing the research because that is how it is set up in my cart. but for those of you that do not want to browse away from this page, here is the picture of the SB3 as well.

Thanks, I apologise, I was thinking of the SB2. OK--tell us how you have your SB3 hooked up--is it feeding a recorder? Is it the master TC generator on your shoots? Do you jam lockits or cameras from it? Yes, the SBT is meant to go on a camera, and does not have WC output--I have one of these too. Your SB3 is doing the exact same thing that the internal electronics of an SD or etc recorder is doing, as far as synchronizing TC to clock. The difference is that the recorder can take one of these signals and make the other one in dead sync to the first, and the SB3 cannot.

phil p

[ccsnd]

The SB 2 has a square wav gen at 48k. it functions the same as a WC gen.

I use metacorder on my cart, so the way I have it really doesn't count for this conversation. the WC out goes into my preamp (which outputs via toslink to my apogee I/O. TC out goes into a unused input on my IO.

WC is not needed on SD or Zax units because the clocks are already as good as, if not better than anything else around. There is no WC on the nomad, and WC that is on the top of the shelf devices is for digital connectivity.

connecting a TC source to my nomad has no effect on its internal WC

[Philip Perkins]

I used Metacorder too, then BR for many years. When used without something like an SD recorder to "translate" the incoming TC from video into WC that my Traveler could use, I would take the TC directly to a Traveler input (in addition to the Mac audio input used by Metacorder to get its timestamp), and in its menus tell it to clock itself to the TC. I am not at all familiar with the Nomad, what I said about the SD 7xx recorders came from SD themselves.

phil p

[Marc Wielage]

> keeping multiple cameras kosher< let me pre-apologize if I offend anyone but how can you tell if you are working with a kosher camera ? is the mat box trimmed back ?

Red assures me they have a licensed Rabbi on hand to bless every camera that comes out of the factory.

[ccsnd]

I don't know how you would get 2 binary streams from one. I think you are mistaken. The only thing I can think of is something with the clink function which is a entirely different protocol. I think you are mistaken.

From the SD website.

Word Source

Internal Sync: internal word clock generator

External Sync Input: Word Clock, AES3, or Video (NTSC, PAL, and Tri-Level)

Word Clock Output: Square wave, running at sample rate, 3.3 V p-p, 75 ohm

[Philip Perkins]

The methods I've described in this thread were well tested and then have been used for about a decade's worth of shoots and recordings with a wide range of gear. Perhaps I succeeded in spite of myself. Perhaps I haven't been able to clearly articulate what I'm doing. Thanks for trying to help.

phil p

[Marc Wielage]

Phil's methods obviously work, because the shows were edited, finished, and aired. If nothing else, this illustrates that there's several different ways of doing this right.

The trick is, there's more ways of screwing this up nowadays than ever before, mainly because we're being forced to work with cheap cameras designed with more attention paid to picture quality than timecode stability. When you throw more and more cameras into the situation -- especially from different manufacturers, some referenced, some not referenced, some with no timecode at all, things can go horribly wrong.

That reminds me: they had a couple of non-time-coded cameras on the set of Shine a Light, including a DV camcorder bolted to the neck of Keith Richards' guitar, and those we had to sync up completely by eye. They drifted as well, but they worked fine for short bursts (:30 seconds or so, here and there). I wouldn't want to shoot a whole concert on those...

[johnpaul215]

So a real world question. If shooting scripted drama on 2 Red cameras (takes max at maybe 4 or 5 minutes), Do you need more than TC? I own 2 SB-3 boxes. Initially bought for jamming a RED on a single camera job, but I have used them for 2 camera shoots, and I know that camera never hooked up anything to the WC output. Should that work fine, or is post just not sending me an angry email and fixing it? I follow that the TC should make it so each clip starts "on time", but at what point does it require something more extensive (WC, or upgrades to a SB-T).

I would have jammed the SB-3 with a Zaxcom Fusion.

When I work on multi-cam reality, they never use more than just TC ports on sync boxes. Those takes can be a full camera load (tape, disc, card whatever). Does their post just deal with it?

Sorry for what may be noob questions. I don't do post. I've never been able to find really good reads to explain all of this and how it works in modern camera/sound hardware.

[Jeff Wexler]

So a real world question. If shooting scripted drama on 2 Red cameras (takes max at maybe 4 or 5 minutes), Do you need more than TC?

I can only speak from my last experience (which was actually my first experience) shooting scripted dramatic movie with 2 RED cameras. I jammed Denecke sync boxes (provided by the Camera Dept., SB-2s I think) from my Deva and they connected them to the cameras --- TC only as far as I know. Takes were typically no longer than 4 or 5 minutes (camera fans would halt the take if they ran much longer). No problems syncing.