When I last purchased a recorder (4 years ago, a PortaDisc) timecode was not really an option for my budget. So we continued to slate and sync in post and I was always quite happy about this traditional approach, maybe just because I didn't know what I was missing. Now things look different and recorders with timecode (Tascam HD-P2, Sound Devices 702T or even Mixer + Zaxcom ZFR100/stereo adapter) come within reach. The problem is I am a complete greenhorn when it comes to timecode workflow with semi-professional cameras like the Z1/V1 /H1 or XH-A1.

Could anybody outline a possible workflow for me, let's say with a 702T, a XH-A1 and a Mac with FCP?
Yes: Free-run tc, jam every 2 or 3 hours, etc. (I read many of your posts, Oleg). But how exactly? How do I get to the TC from the XH-A1? Lanc? What device do I need?
And how does it work in post? Avid only? What about FCP? How do I get the TC out of the Broadcast Wave metadata?

Please steer me into the right direction.

Martin

Alas, there's no easy way to get to the timecode coming from the LANC terminal on the A1. Now the -G1 and the -H1 are another matter, they have TC out, but with the -A1 it's a problem and you'll drop back to the way it's done in film. To get the advantages of code, you need to add a TC capable slate (Deneke or Ambient) into the mix. The 702T becomes the master time reference. You set the recorder to use TOD code and jam the slate from it every 3-4 hours. You slate each take in the old-fashioned way, with the code displayed on the slate visible in the frame. Meanwhile, the 702T has marked the first frame of audio with the corresponding TC (file based recorders DO NOT record continuous timecode but rather use it as a time reference for the first frame, code later in the file is calculated during playback from the timestamp of the first frame and the sample rate). When you drop the video into your editor, you match the number visible on the slate with the same TC number in the timeline. When you import the audio file onto the timeline, the NLE will place it so its timestamp will line up to the time reference in the NLE's timeline. Picture and sound fall into sync, at least for the start of the take. Note that this DOES NOT guarantee the sync won't drift over the course of a long take but the clocks on camera and recorder are good enough that this shouldn't be a problem over takes of a reasonable length The fix for that requires a more sophisticated camera than the -A1, one that acccepts genlock or external tri-level sync, plus Lockit boxes or similar hardware that generate tri-level sync and wordclock to slave both camera and recorder sample rate clocks to a common master. Hope this helps...

if you use the HD-P2, it can sync its clock to the signal on the analog video out of the camera. (not timecode, but clock, to prevent drift).

It's one of the real features that's missing from the prosumer cameras in my opinion. There's really no way to get the timecodes to sync between video recorder and audio recorder. The exception is Canon's XL-H1, and maybe the new JVC HD-250 (not sure about that one). It's something that I'd happily trade a whole stack of "features" for.

The workflow that Steve describes works just fine, although I usually find that I have to adjust the sync on each take by a little bit. It may, or may not, save you any time over doing it the way you've been doing it with a standard dumb slate, although a 702 will get you better sound than the PortaDisc.

if you use the HD-P2, it can sync its clock to the signal on the analog video out of the camera. (not timecode, but clock, to prevent drift).


Rumor has it that Sound Devices is working on adding sync to video blackburst to their recorders sometime in the future but it's not there yet. Likewise, it's also rumored that a box like the Lockit is coming from Ambient that would accept video and generate wordclock to allow you to sync a recorder to the camera but that too is presently only a rumor. Rosendahl used to sell a box that get timecode from a LANC terminal but it's no longer available for some reason. Unfortunately, even if you find one and can get timecode from the camera, the SD recorders don't slave their sample clocks to incoming code so although the recorder's timecode can then be jammed to the camera, all it does is set the time and you can still have drift because the its sample rate clock is still running on its own. You can use something like a MOTU Timepiece to generate wordclock from a video signal but a) they're pricey; and b) now you have to have AC mains power available. Fine for the studio but not practical for the field.

Thank guys, indeed, this helps. Has anybody seen or used this?
http://www.zeitx.com/site3/lanclump.htm

Martin

Thank guys, indeed, this helps. Has anybody seen or used this?
http://www.zeitx.com/site3/lanclump.htm

Martin

That's something new on the market - hope it's not vapourware because there's a lot of folks who are looking for something like that. (I wondered because when you check prices the site doesn't list 'em so I wonder if it's actually available yet.)

I sent them an e-mail yesterday but haven't received an answer. I'll let you know...
M.

I sent them an e-mail yesterday but haven't received an answer. I'll let you know...
M.

Thanks - I also tried to DL the user manual from that site but the link on the page is a dead end. I may be mixing that manufacturer up with someone else but it's nagging in my mind that I've seen complaints about delay after delay on delivery of orders for their TC slates.

what about the procedure with Tascam Hd-p2, SD 302 with Hvx200 ?? Since the HD-P2 cant generate TC internally ? If i have to guess, i probarbly need a slate that is capable of generating TC.

No answer yet concerning the lanc?lump, but found this:

http://groups.google.com/group/rec.arts.movies.production.sound/msg/c9c56737129285e5?hl=en&

doesn‘t sound to promising...

A short update on what I found up to now:

- no small, portable lanc-TC box currently available. No anser from zeitX.
- this means: recording timecode as audio to the camera is the way to go for non-tc prosumer cams, e.g. with a denecke or ambient clockit box jam sync'd to the recorder or feeding the recorders timecode back to the camera as audio channel.

- this has been standard practice on Avid for years. But with FCP? - Well there are 1.5 options at the moment: First, there is this:
http://www.gallery.co.uk/timetoolscasestudy.html
expensive, but working.
Second (and much more promising) there is auxTC:
http://videotoolshed.com/?page=products&pID=26

it's still in beta but the developers seem very active. I got a response within hours.

A short update on what I found up to now:

- no small, portable lanc-TC box currently available. No anser from zeitX.
- this means: recording timecode as audio to the camera is the way to go for non-tc prosumer cams, e.g. with a denecke or ambient clockit box jam sync'd to the recorder or feeding the recorders timecode back to the camera as audio channel.

- this has been standard practice on Avid for years. But with FCP? - Well there are 1.5 options at the moment: First, there is this:
http://www.gallery.co.uk/timetoolscasestudy.html
expensive, but working.
Second (and much more promising) there is auxTC:
http://videotoolshed.com/?page=products&pID=26

it's still in beta but the developers seem very active. I got a response within hours.

I'm not an expert but IMHO you're adding an unnecessary level of complication by recording LTC on a camera audio track or indeed recording LTC at all, beit on the audio recorder or in the camera. The "practice for years" in Avid developed where FILM was being shot and then telecined to video for editing on the Avid. The timecode reference on an audio track was used during the telecine process to make sure the speeds matched, with picture speed during the conversion to digital controlled by the sound's TC. But when you shoot on video you don't have that conversion process to worry about and there's nothing for the recorded TC to control. Code is used strictly to line up sound and picture in the NLE and you really only need one reference point for that.

REmember there's two separate clocks involved here - The timecode clock which records the hour:min:sec:frame location of an instant of sound and the sample clock used in the digitization process, 48kHz typically. For two digital devices (like, say, a DV/HDV video camera and a file-based audio recorder generating a BWF file output <grin>) to run at exactly the same speeds their sample clocks must be syncronized - what the time of day clock says in each device is irrelevant. The 702T does not sync its sample clock to timecode, either from an external source or its own. Its sample clock, which is what needs to be slaved to picture in order to prevent sync drift over the duration of a take, is not connected to TC in any manner. The sample clock can be slaved to wordclock but that's not practical with the A1 as there's no readily portable video to wordclock converter to feed camera clock to the recorder and since the camera doesn't have genlock input, using 2 synced Lockit boxes with one feeding genlock to the camera and the other feeding wordclock to the recorder isn't possible either.

Forget about recording a TC track in the camera - it won't have any function except to waste an audio track and it has a downside in that it can easily bleed over to the other tracks and ruin what might otherwise be acceptable sound. Since there's no speed conversions or A/D conversions down the line, there's nothing for it to control, nothing for it to do.

Set the audio recorder to free-run at the same frame rate you're using in the camera - 29.97 FPS if the camera is NTSC and 25 FPS if you're shooting PAL. (24P is a little different for the precise frame rates to use.) Jam a TC slate with the recorder as its master and clap the sticks for each take, that's really all you need to do. Tighter sync, where the sound and video sample clocks are locked together needs an upgraded camera that has genlock sync input plus the Lockits. Timecode OUT on the camera can be used to jam the recorder and use record-run code with audio chasing picture, eliminating the need for the TC slate in the process, but doesn't prevent drift.

I'm not an expert but IMHO you're adding an unnecessary level of complication by recording LTC on a camera audio track or indeed recording LTC at all, beit on the audio recorder or in the camera. The "practice for years" in Avid developed where FILM was being shot and then telecined to video for editing on the Avid.
(snipsnip)


I am not an expert either, just trying to evaluate if I should buy and SD702 or 702T next week. The background: I need dual system audio and I want dual system audio, it's just way better. If there is a way to simplify the process on location it would be very helpful. I am doing documentaries, situations are often highly unplannable, you come and things happen. A cable from a mixer to the camera is not an option, a wireless link to unreliable (and beyond my budget to go Zaxcom or Lectrosonic). I have been working with dual system audio in similar situations before (with traditional clapper board, slate) and I do know it is working and I am not afraid to sync considerable amounts of footage in post. We had 90 hours on my last project. With a simple fieldlog, a database and an AppleScript/XML/FCP workflow it was astonishingly smooth. BUT: in the field, when things happen quick and you can't slow them down, a timecode based dual system workflow where you jam sync once in 2 or 3 hours would be worth a lot.


REmember there's two separate clocks involved here - The timecode clock which records the hour:min:sec:frame location of an instant of sound and the sample clock used in the digitization process, 48kHz typically. For two digital devices (like, say, a DV/HDV video camera and a file-based audio recorder generating a BWF file output <grin>) to run at exactly the same speeds their sample clocks must be syncronized - what the time of day clock says in each device is irrelevant. The 702T does not sync its sample clock to timecode, either from an external source or its own. Its sample clock, which is what needs to be slaved to picture in order to prevent sync drift over the duration of a take, is not connected to TC in any manner. The sample clock can be slaved to wordclock but that's not practical with the A1 as there's no readily portable video to wordclock converter to feed camera clock to the recorder and since the camera doesn't have genlock input, using 2 synced Lockit boxes with one feeding genlock to the camera and the other feeding wordclock to the recorder isn't possible either.


Forget about recording a TC track in the camera - it won't have any function except to waste an audio track and it has a downside in that it can easily bleed over to the other tracks and ruin what might otherwise be acceptable sound. Since there's no speed conversions or A/D conversions down the line, there's nothing for it to control, nothing for it to do.


What do you mean by speed conversions or A/D conversions?

What you say about spilling over of the rrrr-LTC on one channel to the other is exaclty the concern I woke up with this morning. Do you have any experience with this? It will most probably be a Canon XH-A1 and I don't know anybody with an A1 and a timecode generator who could try it out. The people I know who work this way mostly used a Sony Z1.

(the problem with the mic/line switch for BOTH channels in the Canon XH-series is also to be taken into account, I know. But let's not go into that in this thread)

Still, I have asked around and people seem to do it: jam-sync a Sound Devices 702T or 744 with a clockit box every 2 or 3 or even more hours, let them free run, record LTC to channel 2 of the camcorder, use Avid to sync. It seams to work, from what I hear. Have you had other experiences? Or do you know anybody who has?



Set the audio recorder to free-run at the same frame rate you're using in the camera - 29.97 FPS if the camera is NTSC and 25 FPS if you're shooting PAL. (24P is a little different for the precise frame rates to use.) Jam a TC slate with the recorder as its master and clap the sticks for each take, that's really all you need to do. Tighter sync, where the sound and video sample clocks are locked together needs an upgraded camera that has genlock sync input plus the Lockits. Timecode OUT on the camera can be used to jam the recorder and use record-run code with audio chasing picture, eliminating the need for the TC slate in the process, but doesn't prevent drift.

Timecode out on the camera would require at least a Canon XH-G1. I considered this but I would still have to go free-run on the camera and would loose a) the possibilty to re-capture and b) a few seconds at the beginning of each clip, right?
The clockit-box option seems to be a) cheaper, and b) working on whatever camera we end up. Right?

Maybe it's just a year or so too early. The thing is that I have to decide this week which SD I'll go for - 702 or 702T.

thanks for your help and comments.

Martin

I am not an expert either, just trying to evaluate if I should buy and SD702 or 702T next week. The background: I need dual system audio and I want dual system audio, it's just way better.
No disagreement there and I'm not suggesting not to go dual system by a long shot, not am I suggesting to forgo a timecode-based workflow. I'm just saying that timecode and its role is very different for dual system video with audio being recorded on a file-based recorder versus film or video where audio is recorded on a DAT or analog recorder.

The first concern with sync sound where timecode is used is to align the separately recorded picture and audio files in post. File-based recorders such as the 702T or 744T do not record continuous TC into the audio datafile. They record a single timestamp that marks the TC of the first frame of audio. When you play back an audio file on them, they take the timestamp and based on the sample rate regenerate what the code would have been later into the file had it actually been recorded. If the timestamped code at start of file is 01:03:15;00, 48000 samples later it knows the code would have been 01:03:16;00 and that's what it displays during playback. But when you copy that BWF file onto your workstation's hard drive, the only timecode reference present in the entire file is that single timestamp. Then when you import the file into your NLE software such as FCP, it will read that timestamp and position the first frame of audio at the corresponding time marker in the editing timeline. When picture is imported onto the same timeline and you used a TC slate slaved to the audio recorder at the start of the scene, aligning the numbers on the slate with the matching frame on the timeline will cause audio and video to fall into sync. Of course it doesn't matter which order you import the files - the idea is that when picture is aligned to the editor's timeline on its timestamp as represented by the TC slate's frame and the audio is aligned to the editor's timeline based on its timestamp in the file header, picture and sound will automatically be in sync at the start of the take. At no point in this process would timecode recorded on one of the video clip's audio tracks in the camera have any purpose unless the NLE was able to position the video clip on the timeline based on that code, something none the NLE's I'm familiar with will do. But a timestamp on the picture in the form of the image of a TC slate does that nicely anyway, making any recorded code redundent even if it could be read.

The second concern with sync sound is once sound and picture are aligned at the start of the take, how do they STAY in sync over the duration of the shot? For that to happen, they must playback at exactly the same speed. Video expects there to be 48000 samples of audio for every second of video. Two clocks are involved in that - one clock in the camera and another clock in the audio recorder. It is crucial to note that these are actually separate clocks from the timecode TOD clock, though the timecode clock and the sample rate clock might use a common timebase within the device. If they're running at exactly the same rate, 1 second of audio will always match 1 second of video and sync is maintained.

There are three ways to achieve that match - send a sync clock such as video blackburst from the camera to the sound recorder, slaving the audio sample clock to the camera; send clock from the sound recorder to the camera, slaving the camera's video clock to the recorder; or slaving both camera and recorder to a third common reference. None work with the equipment mix of a file-based recorder and the Canon XL-A1 for location work.

For the first method, you need to get timecode or video sync from the camera, send it through a converter that generates digital wordclock, and slaves the audio recorder to it. There's nothing at present that reads TC from the camera's LANC or 1394 ports and the only devices that read video and output wordclock require AC power (MOTU Timepiece).

For the second method to work, you need to be able to drive the camera's video sync clock from an external source and that requires genlock capability.

Sync with Lockits is the third method and again it requires you use a camera that is capable of slaving to an external sync source.

The good news is that the clocks in modern cameras and digital recorders are good enough, accurate enough in their speeds, that you can expect to maintain sync within a frame over shots of reasonable length, say 10 to 20 minutes.

What do you mean by speed conversions or A/D conversions?

That is in reference mainly to the film workflow where footage shot at 24 FPS is telecined to NTSC video at 29.97 FPS for editing on the Avid, the Avid creating an Edit Decision List referencing the original timecodes so that picture and sound originals can ultimately be conformed to each other. The telecine process preparing the materials for the Avid requires frame rate changes in both the picture and sound and that's where LTC enters the picture as well as forming basis for the reference marks in the EDL. Plus if the audio is recorded on DAT, it isn't directly imported as the original data file the same way a BWF is. Instead it goes through a file conversion process or is played back and re-digitized hence it goes through a digital to analog conversion on the playback deck and immediately another analog to digital conversion as it's recorded for the Avid and also transferred to magenetic perf film. LTC recorded on the DAT controls that process but you're not going to be doing any of those steps.

Timecode out on the camera would require at least a Canon XH-G1. I considered this but I would still have to go free-run on the camera and would loose a) the possibilty to re-capture and b) a few seconds at the beginning of each clip, right?
The clockit-box option seems to be a) cheaper, and b) working on whatever camera we end up. Right?
...
Martin

See above - the clockit/Lockit box would have no purpose with this camera since it doesn't have a genlock sync input and that's what the lockits drive. I can't repeat it often enough - recording timecode on the in-camera audio (or on a track in the audio recorder, for that matter) serves no useful purpose at any point in the process as best I can determine.

For further references, take a look at Wolf Seeberg's books "Sync Sound with Timecode for Film and Video" and "24P for Sound and Video Assist."

I emailed Zeitx a few days ago, and received this reply this morning:

"The Lanc-Lump is currently out of stock until later this month....
Price is £120 (~$230)."

I just received the same message. Let's see...

Thanks Steve for this long answer. It is really incredible what I learn here, I really appreciate this.

Two things I still don't get:
In Avid there is a function called "Read Audio Timecode". You can use it to fill in AuxTC1 read from the LTC recorded to one of the audio channels. Then you can sync your Video to the audio based on the timestamp in the BWF header.
(In FCP there is no such function (yet) but there are the 1.5 software solutions I mentioned before, which auxTC looking very promising.)

Do you agree with me up to here? If yes, why do you say that timecode recorded to an audio channel of the camera serves no useful purpuse?

The second thing is about two devices _staying_ in sync: Ambient speaks of a drift of less than 1 frame per 24 hours. Even if this may not be a real world figure it still should be ok for a couple of hours, at least from what I read on these forums and here from my friends. So worldclock has no real world relevance for this kind of setup. I do not need perfect snyc, < 1 frame is enough.
Do I see something wrong here? You seem to know much more about these things than I do. Please correct me.


Martin

Thanks Steve for this long answer. It is really incredible what I learn here, I really appreciate this.

Two things I still don't get:
In Avid there is a function called "Read Audio Timecode". You can use it to fill in AuxTC1 read from the LTC recorded to one of the audio channels. Then you can sync your Video to the audio based on the timestamp in the BWF header.
(In FCP there is no such function (yet) but there are the 1.5 software solutions I mentioned before, which auxTC looking very promising.)

Do you agree with me up to here? If yes, why do you say that timecode recorded to an audio channel of the camera serves no useful purpuse?

The second thing is about two devices _staying_ in sync: Ambient speaks of a drift of less than 1 frame per 24 hours. Even if this may not be a real world figure it still should be ok for a couple of hours, at least from what I read on these forums and here from my friends. So worldclock has no real world relevance for this kind of setup. I do not need perfect snyc, < 1 frame is enough.
Do I see something wrong here? You seem to know much more about these things than I do. Please correct me.


Martin

I can't speak with first-hand knowledge about things Avid and don't know what you mean when you refer to "fill in AuxTC1."

I doubt Ambient is fudging their figures but that's talking about a set of Lockit boxes tuned to a Clockit master staying together within a 1 frame tolerance for 24 hours. The question is, what is that precision going to be used for? If you're genlock syncing a camera to one of them or have several cameras and use syncronized Lockits on each so they're all synced to the master while a Lockit generating wordclock takes care of syncing the audio recorder, you're golden. But that's not what you're talking about doing.

I can't speak with first-hand knowledge about things Avid and don't know what you mean when you refer to "fill in AuxTC1."


I mean: FPC and Avid allow for auxilliary timecode, meaning you can have a timecode referring to your reel as well as a timecode referring to an external source associated with one single clip. So the "Read Audio Timecode" takes LTC from audio channel 1 or 2 and makes it available as auxiliary tc for sync purposes.

I mean: FPC and Avid allow for auxilliary timecode, meaning you can have a timecode referring to your reel as well as a timecode referring to an external source associated with one single clip. So the "Read Audio Timecode" takes LTC from audio channel 1 or 2 and makes it available as auxiliary tc for sync purposes.

And what does that get you that a TC slate visible in frame at the start of the take and lined up with the corresponding time mark in the NLE's timeline doesn't? Without the camera and audio recorder's sample clocks being slaved to each other during the shot, the audio and picture can still drift out of out sync with longer shots and the LTC recorded in the camera doesn't do anything to help bring them back together. All it seems you've achieved for all the trouble and expense is at best you've saved a couple of mouse clicks in the process of matching the start marks for picture and sound for each clip imported.

Without the wordclock being jammed the audio will drift on very long takes but sending TC to channel two does provide a quicker post workflow in Avid, not sure about FCP. After you use channel two to set AuxTC you can then just use AutoSync and Avid matches all your audio and video instantly. No need to hand sync each clip.

I have used this workflow many times and it works seemlessly, except as you pointed out, the drift you get on long takes. But that will also happen if you sync to slate. If you slate the head and tail on a long take you can determine the drift and adjust all your long takes as needed.

William

Just FYI, Zeitx has not had the best reputation for delivering product.
There was a time code slate that had a very attractive price point, but many (all?) folks that tried to order it never got their slate. Just a heads-up if you are considering ordering from them.