R-44 Word clock sync experiments / Lockit

[RichT]

I've been looking around to see what the R-44 CTRL SYNC cable actually transmits/receives and came across this in the Roland FAQ:

"When two R-44s are connected via the CONTROL SYNC terminals, they share the audio clock.
Therefore, delay due to time passing does not occur with recorded data.
In addition, the operation information is also sent, and start and stop operations are also synchronized. However, there is a time lag between two R-44s and the recording start time can slightly differ.

Reference:
The clock synchronization jitter is 1000ppm or less.
Difference of recording start time between two R-44s is approximately 10msec.
If pre-recording is set, the time lag becomes larger.
Because a time lag occurs with the recording star[sic] time as mentioned above, you need to use DAW or other tools to strictly align the phases after recording."

Which appears to be word clock.

By getting a BNC cable, attached to my soundcard (RME multiface) with a bare connector and touching that against the ring of a 1/8" TRS minijack I found the following:

R-44 set as master: RME will sync to word clock (and change sample rate)

R-44 as slave- when in recording mode the sample rate will flash if sample rates do not match (eg 44.1k and 48k). It will record a file labelled as the rate it was set at (rather than incoming clock). Doesn't display anything different when sample rates are the same.

I can't do pull-up/down of sample rates on my soundcard so can't test these.

So, given that you can output/input Word Clock, with minijack-BNC connectors you should be able to:

Sync multiple R-44's (more than 2) using BNC 'T' connectors, although the remote control probably won't work.

Connect an R-44 as master to an Ambient Lockit box and maintain accurate sync with cameras (would this work as slave also?)

 

[sonidista]

Hey Rich,
very interesting topic that has been floating around in the back of my head for quite some time. Could you elaborate a little on this part:

Connect an R-44 as master to an Ambient Lockit box and maintain accurate sync with cameras (would this work as slave also?)

does the Lockit sync with word clock only? Since the R-44 doesnt output proper TC (Time of day is just hh:mm:ss)

This sounds very interesting. However - what kind of

 

[RichT]

I was thinking it could work in terms of making sure there was no drift between wordclock signals between equipment, so R-44 files could be manually aligned in post and not timestretched. As the R-44 doesn't send or receive TC I don't think there's a way of syncing that.

I'm also talking theoretically as I'm yet to use a Lockit to try this. I'm assuming that it can lock to an incoming frame rate (or have it set on the box) and adjust the word clock to generate the appropriate pull up/down in sample rate.

 

[Steve House]

I was thinking it could work in terms of making sure there was no drift between wordclock signals between equipment, so R-44 files could be manually aligned in post and not timestretched. As the R-44 doesn't send or receive TC I don't think there's a way of syncing that.

...

Just an FYI for the thread's readers, timecode doesn't prevent "drift" where audio and video are in sync at the start of a clip but drift out of sync as it plays towards the end. In a file-based workflow, TC establishes a single alignment point just like a clapper slate but does not contain any speed reference or control information.

 

[RichT]

Just an FYI for the thread's readers, timecode doesn't prevent "drift" where audio and video are in sync at the start of a clip but drift out of sync as it plays towards the end. In a file-based workflow, TC establishes a single alignment point just like a clapper slate but does not contain any speed reference or control information.

Thanks for clarifying that Steve, TC is quite new to me (I'm from a music recording background)

 

[Steve House]

Thanks for clarifying that Steve, TC is quite new to me (I'm from a music recording background)

Yep, things chaged as file-based recording edged out DAT. In a file-based double system setup, TC doesn't do anything that banging an old-fashioned clapper slate doesn't do. It just does it a little faster and more conveniently than syncing manually, if one has a large number of clips to sync up.

 

[sonidista]

Well, since Lockits are actually able to generate TC, you could do the following:
Use the Lockit as TC master, jam it with the cameras once (drift should be small enough to only jam once a day) and then constantly send the Lockits output to a channel of your R-44 (or Tascam DR-680 or other non-TC recorder, for that matter). Thus you have the TC on one of your audio tracks which then can be converted by your editing suite into proper TC. In theory this has to work. I never tried it though.

 

[Steve House]

Well, since Lockits are actually able to generate TC, you could do the following:
Use the Lockit as TC master, jam it with the cameras once (drift should be small enough to only jam once a day) and then constantly send the Lockits output to a channel of your R-44 (or Tascam DR-680 or other non-TC recorder, for that matter). Thus you have the TC on one of your audio tracks which then can be converted by your editing suite into proper TC. In theory this has to work. I never tried it though.

You can't jam a Lockit to a camera or other that doesn't have a timecode output - there's no way for the Lockit to read the device's TC clock.

 

[sonidista]

You can't jam a Lockit to a camera or other that doesn't have a timecode output - there's no way for the Lockit to read the device's TC clock.

I wrote that the Lockit generates TC so it can be used as a master and its output jammed to the cameras once and to an audio track of the recorder constantly.

 

[Steve House]

How do you jam to a camera that has no timecode I/O connection? The Lockit has the necessary port but it's the rare prosumer camera that does. If you're jamming a Lockit to a camera, the process is to physically connect the Lockit to the TC I/O of the camera with a cable so the two TC clocks are set identically. You could use the Lockit as the Master and jam its code into the camera or you can use the camera as the Master and jam its TC clock into the Lockit. In either case there must be a physical cable connection between the camera and the Lockit. Then you can disconnect the cable and the Lockit continues keeping accurate time on its own.

You're also suggesting that syncronized timecode between the camera and the recorder will prevent loss of sync over the duration of a shot ("sync drift"). It won't. With file-based workflows such as our OP's recording into an Edirol R-44, timecode does not provide any speed control at all. It is nothing more than a slate, providing a single position reference to allow for aligning the audio and video files in post. It does NOT provide any speed information or control to the slave device. To prevent drift, the camera and the audio recorder sample clocks must share a single common timebase reference. The timecode clock is essentially a time-of-day counter and runs much slower than the sampling clock; it does not control the sample rate clock so no matter what the TC reads or what it is set to in terms of frame rate etc it has no effect on the actual sample rate used for recording. The proper way to use Lockits to prevent drift requires two Lockits and a camera that has a genlock input. The two Lockits are tuned to each other so they both run at an identical rate. One is set to output video sync and is connected to the camera's genlock input. The other is set to output wordclock and is connected to the recorder's wordclock input. This sort of arrangement will hold sync typically to within 1 frame or less every 24 hours. But again, you can only do this with a truly professional camera as there are only a few high-end prosumer cameras that have genlock.

 

[sonidista]

On a job recently I used a wireless transmitter and receiver to send TC from the recorder's TC out (788T) to the non-TC camera (to an audio channel, as a pure audio signal). I have no idea how to handle this in post but I read something about it somewhere and the camera op said it should work that way. This is NOT a TC stamp or something, instead a sine wave or something like that that can be transformed/read back into TC somehow, don't ask me how.
If someone can clear this up for us it'd be appreciated!

 

[Steve House]

On a job recently I used a wireless transmitter and receiver to send TC from the recorder's TC out (788T) to the non-TC camera (to an audio channel, as a pure audio signal). I have no idea how to handle this in post but I read something about it somewhere and the camera op said it should work that way. This is NOT a TC stamp or something, instead a sine wave or something like that that can be transformed/read back into TC somehow, don't ask me how.
If someone can clear this up for us it'd be appreciated!

A few, but by far not all, NLEs can read and interpret linear timecode recorded to an audio track and display it on a supplemental timeline. Avid/ProTools can do this and I think there's an add-in for FCP. But what you did is NOT the same thing as jamming code from one device to another. When one jam syncs, the code from the master device such as the audio recorder is pushed into the actual TC clock of the slave devices, using code coming from the master to set the TC generator in the slave to read the same. Then the devices can go their separate way and for a period of time the two clocks will be ticking over displaying identical times. How long you can go before you need to re-jam depends on the quality of the clocks - with pro gear like the SD recorders, you'd re-jam every 4 hours or so just to be safe and of course whenever the camera battery is changed or it is otherwise powered down. Had you been jamming when you sent code from the recorder to the camera, you would NOT have been recording code to an audio track. Instead you would have been setting the camera's internal timecode generator to gnerate code that is identical to the TC in the audio recorder and record it as VITC in the video portion of the file. Note also, the SD788T does record its TC in the audio file as a single timestamp in the BWF file header, marking the value in its TC generator at the moment of the first audio sample. Although its TC generator runs continuously, it does NOT record code continuously for the duration of the audio file as any sort of track parallel to the audio. When you play back a file on the recorder, it takes the recorded timestamp and calculates the running displayed value on the fly by adding the elapsed number of samples played times the sample rate to the starting TC value.

 

[Noiz2]

I hope you slated well.

TC is of much less use today than it was a decade or so ago. Your TC audio track can be plugged into a LTC (Linear Time Code) reader and can be used to link the audio to the picture. Nuendo can I believe interpret the audio directly but Protools to the best of my knowledge, can't. We always used TC readers to convert the "audio" TC into MTC (MIDI Time Code) to drive Pro Tools. In the good old days a "Synchronizer" would be used to keep your analog tape deck in sync with the TC track. But as Steve pointed out file based recorders only have a start TC stamp so you can get them to start in the right place but they won't nec stay in sync. To do that last step you would have needed to lock the two devices to "word clock". So for you the TC gets you a way to get the files "sort of" in sync and if you don't have a guide track on the video then it's the best you got. In the future it would probably be better to get a guide track o the video and use Pluraleyes (or just do it by hand).

As a general historical point TC was not used much in filmmaking until you were doing sound post to video. And then it was just for editorial video syncing and to lock the DAW to picture on the stage. It got a bit more common with the use of DAT recorders but even then not often for production recording. Video on the other hand (having no sprocket holes) used TC a lot. I did a fair amount of music work early on and used TC all the time and was quite surprised by the lack of TC use in big budget films and the generally poor understanding of TC in general in the film world.

I love TC and the rock and roll of synchronizers but I haven't used TC for anything important since I got rid of the 3/4" deck quite a few years ago. I have a box full of TC readers and window burners etc, none of them have even been plugged in in years.

 

[sonidista]

Thanks Steve and Noiz for providing useful information about TC.

But what you did is NOT the same thing as jamming code from one device to another.

Actually I did, there were three cameras shooting at the same time. Two of them got jammed from my 788T via cable once, then again after two hours. The third cam had no TC in/out, so I sent the TC to the audio track as described previously. In this case the TC on that camera, if translated in post should theoretically be more accurate than the other two cams because it has constant information sent from the 788T instead of being stamped just once during jamming?

Noiz, I also think that TC doesn't get used a lot in fiction nowadays. This was my second time using TC after doing sound for almost 5 years. But it is very useful for multi camera and especially documentary shoots and I think it is often used in this field.

 

[binba]

Interesting topic... so much confusion. Timecode between devices will match timecode metadata. Sync/reference/genlock/wordclock between devices will match their synchronization, with sub-frame accuracy.

That's the key thing to remember (especially with audio): timecode is just metadata, labels that get attached to the data. Sending timecode between devices by its own has no bearing on sync. You need to separately determine how the devices derive their sync, which usually is not through a timecode spigot.

Back to the topic: we just got an R44, and own a Sound Devices PIX240 recorder which has a LockIt built-in. The PIX can send word clock out over BNC that is slaved to incoming video signal. Based on the first post, we could run word clock out from the PIX and slave the R44 to it, creating a sync chain between the camera, PIX, and the R44 (with the camera serving as the master clock). Note this has nothing to do with timecode.

I did a sync test, free-running an R44 alongside a Sony EX1 camera, and the drift was about 50ms/hour, or 1-1.5 frames. I find this very respectable, but if you run very long takes then slaving the recorder to the camera could be helpful.