Timecode delivery, connection and drift

[bristolrecords]

Hi,
I'm putting this here in this forum, because it seems the closest place to 'correct'. Admin's please let me know if there's a better place.

I've more recently become involved with smaller scale film making and the associated equipment. Timecode sync between cameras and location audio is being addressed a little better now, than a few years ago. Decent, temperature compensated crystals are getting more commonplace and several manufacturers are now making timecode devices that can wirelessly sync with one another. There are several systems, from all the well known specialists, several of which have their own proprietory system for wirelessly networking, so, we have a common sync method (LTC) accompanied by wireless incompatabilities. Great!

So, the normal topology of timecode sharing between devices in studios was a master clock syncing with other devices via cable, often recording timecode to a sync track in the case of linear media.
Multiple devices could jam sync and maintain good timing for long periods, each with their own timecode clocks.
In the case of digital media, timecode tracks are embedded in metadata, but it's possible to read and write LTC recorded as an audio track.
In the case of my audio and video editing software (Davinci Resolve Studio) it's possible to select either the embedded timecode metadata from video, or to read an audio track.

I'm floating this because (after a moment of horizontal thinking, it occurs to me that it would perhaps be useful to use a slightly different topology in the case of location work, where multiple cameras and audio devices would gain advantage from continuous sync. I'm hoping that maybe there are kind folk here at Group DIY, who might have some insight into this subject.

My suggestion would be, for the purposes of sync, to have one central clock transmitting timecode on a one-to-many basis, in a similar way that the old analog mic transmitters did, each device recording the timecode to a separate track, as devices also used to.
I'm sure that this would work. Digital devices all have fairly accurate clocks, certainly good enough to maintain sync for a few minutes at a time.
The common problem with location devices, is transmission becoming intermittent, as I'm sure many of us have experienced.
The time code track should be expected to have gaps in the LTC in a system such as the one I'm describing.

My interest is to understand how LTC systems handle drift and loss of signal. To be clear, I'd like to understand if it might be possible to make use of LTC tracks recorded with gaps in the LTC with accuracy, in post production, by accomodating for the gaps and the minor drift in software, after the fact.
If this could work reliably, timecode sync on locations could become very useful in a few ways:
Lav and location mics could all record their own audio and transmit only for the purpose of monitoring, which is less mission critical, unless live transmission is under way.
Locally recorded audio can be recorded more reliably. Almost no chance of dropouts and with 32bit recording, no chance of peaking.
Copies of the very same timecode track could be compared by editing software, perhaps with the potential to accommodate and perhaps even repair the timecode tracks in post production.

My question to those who might respond to this:
Am I barking up entirely the wrong tree, or does this make sense...
and why?

 

[Barry Hufker]

Everything you mention has been solved in modern film/video production. The use of a master clock for many devices ("master" and "slaves" -- although the term "slaves" has rightfully fallen out of favor). Each device refers to the master clock for accurate timing. And when timecode is lost the "jam sync" mode keeps the sync going until it is restored or drifts so far out of sync it can't be restored at the moment.

BTW, my favorite timecode system is from Tentacle. I use my master recorder as the reference, then connect a Tentacle pod to the device to set timecode for it (which I verify with my iPad, which has the Tentacle app on it). This system works well. I use "continuous timecode" for all devices so they never lose sync between takes.

 

[Tubetec]

Tape used be a bit funny about time code record level , typically it came directly out of the tape machine to trs jack and into whatever time code reader/generator ,but you backed the levels off a good bit at the record side .maybe around -12db .
The other thing about tape machines was you needed to set a pre-roll so the mechanics and tape transport stabilised by the time the music started .
All those problems become a non issue with digital audio .

 

[Barry Hufker]

And for tape, you kept an open track between timecode and audio to prevent timecode bleed into your signal, as it is very hard, if not impossible, to remove.

 

[bristolrecords]

Everything you mention has been solved in modern film/video production. The use of a master clock for many devices ("master" and "slaves" -- although the term "slaves" has rightfully fallen out of favor). Each device refers to the master clock for accurate timing. And when timecode is lost the "jam sync" mode keeps the sync going until it is restored or drifts so far out of sync it can't be restored at the moment.

BTW, my favorite timecode system is from Tentacle. I use my master recorder as the reference, then connect a Tentacle pod to the device to set timecode for it (which I verify with my iPad, which has the Tentacle app on it). This system works well. I use "continuous timecode" for all devices so they never lose sync between takes.

I have 3 ninja V recorders, so the Atomos solution looked good for me until it became apparent that the Xsync module had become obsolete. I opted for the Deity timecode solution, which caters for both camera timecode connection over SDI and the old fashioned way, with LTC to an audio track. I have 3 units, which sync wirelessely over 3G. Control is via the Sidas app for android. I jamsync my Zoom F6, which has good, accurate timecode, The 3 networked timecode devices can then reside on my 3 cameras, 1 recording a timecode track to cam.3's audio track, while the other channel records a reference mic in the Deity. The others connected to the timecode IO.

My question was a specific technical one. I'm interested to know if LTC recorded as a digital audio track, along side audio on other tracks, can currently be repaired in post, if the recording of the LTC on the audio track has interruptions in it (probably due to temporary loss of signal).
My reason for this line of exploration is that then, only one clock would be necessary, not a number of slave clocks synced. This may be particularly useful for keeping the cost and size of compact devices such as lav units, whilst still maintaining reliability. For example, a lav unit which could receive and record LTC on a track, whilst transmitting audio for monitoring purposes and simultaneously recording it's input on another audio track, requires no slave clock, just the recording of the LTC, which could be repaired in post if there are any dropouts in the time code. My reason for asking specifically about repairing the timecode track, rather than just compensating for it, is so that the repaired recordings could more reliably be copied and transferred to other systems if the need arose.

Of course, if it works reliably, this topology could simplify the use of timecode dramatically. No slave clocks, just an extra track recorded instead, no need for jam syncing devices, no need to monitor the sync between devices, no need to re-sync over the course of a shooting day.
The idea would be that because transmission of all separated sources of sound would only be for monitoring purposes, audio dropouts would no longer be critical events. The continuity of the local recording would be the critical thing, along with the ability to use the recorded LTC track reliably for frame accurate sync in post. One clock for all, no slave clocks.
Just hit record and go.

 

[bristolrecords]

Tape used be a bit funny about time code record level , typically it came directly out of the tape machine to trs jack and into whatever time code reader/generator ,but you backed the levels off a good bit at the record side .maybe around -12db .
The other thing about tape machines was you needed to set a pre-roll so the mechanics and tape transport stabilised by the time the music started .
All those problems become a non issue with digital audio .

I remember. We still use -12dB today.

 

[bristolrecords]

And for tape, you kept an open track between timecode and audio to prevent timecode bleed into your signal, as it is very hard, if not impossible, to remove.

It was a horrible noise. On small track-width systems, sometiimes a gap of one track was not enough!

 

[gyraf]

I don't see why it should be too hard to do read, then do simple time-interpolation between dropout's start and end, then splicing in new smpte where missing.

Not sure about the situation if you're using lossy coding (mp3 etc) for transmission or storing - those are prone to weird waveform artefacts at messed bitrates that could give you spooky waveforms. But should be detectable thus correctable with relatively simple means.

There's most probably not a plugin already existing out there, but absolutely possible at today's processing power

/Jakob E.

on a similar note, a friend once hacked a DAT-machine so he could put in timecode in the LSB. Worked pretty well despite the format's horrible weaknesses

 

[Tubetec]

With old fashioned tape you were subject to all kinds of imprecission , usually the time code was very reliable but ocassionally if the capstan started slipping against the tape , the locate would hunt back and forth .
Of course a modern digital playback system has none of the physical problems associated with tape , so you would think it to be very reliable and never expect any damaged time code . .

 

[JohnRoberts]

And for tape, you kept an open track between timecode and audio to prevent timecode bleed into your signal, as it is very hard, if not impossible, to remove.

That's why we often put the SMPTE time code on an edge track.

Some people put drum tracks next to the timecode so you could more easily gate out the low level timecode leakage.

JR

 

[Ricardus]

And for tape, you kept an open track between timecode and audio to prevent timecode bleed into your signal, as it is very hard, if not impossible, to remove.

The reverse is also true. I assisted on a session where the main engineer put some really loud guitar tracks next to the timecode, and the muted chugging the guitarist did bled into the timecode enough where it wasn't readable at times by the console computer.

 

[JohnRoberts]

The reverse is also true. I assisted on a session where the main engineer put some really loud guitar tracks next to the timecode, and the muted chugging the guitarist did bled into the timecode enough where it wasn't readable at times by the console computer.

just taking a wild guess, that engineer might have been printing to tape a little too hot....

It was an old school trick to print drum tracks hot to get some free tape compression, but not right next to timecode.

JR

 

[Tubetec]

Typically kick drum went down on channel one of the multitrack , ch24 was used for timecode as far as I remember .

 

[JohnRoberts]

Typically kick drum went down on channel one of the multitrack , ch24 was used for timecode as far as I remember .

yup if the kick was getting squashed there could be some splatter on the next track.

Both put on edge tracks for the same reason.

JR

 

[Ricardus]

just taking a wild guess, that engineer might have been printing to tape a little too hot....

It was an old school trick to print drum tracks hot to get some free tape compression, but not right next to timecode.

JR

They were SUPER hot. Sounded great, but don't print next to the timecode, man!

 

[Tubetec]

When you go to line up a tapemachine the outside edge tracks were often a little less stable at HF , that wont have much effect on a kick drum , if things are poorly aligned mechanically it might effect the time code .

 

[One F Sound]

If the recording devices record and RESOLVE to the incoming timecode then you should be fine if the devices re-resolve after a dropout. It's been a while since I've been down this road but I recall some devices having a choice of lock and release or continual jam sync feature in case of dropouts. But if everything is resolved continually to a word clock then once you throw it on the edl it's all going to run at the same speed, you just need to find the offset if the timecode is missing.

For good old analog tapes with serious enough timecode dropouts we used the Adam Smith Zeta 3 synchronizer that was able to resolve to incoming timecode and generate the same timecode. Lynx synchronizers didn't have this feature I think. Of course the good old Brainstorm SR xx (whatever # it was 30 years ago) was welcomed with open arms.

 

[Walrus]

Lynx 1’s didn’t, but I believe the Lynx 2 did.

 

[bristolrecords]

I don't see why it should be too hard to do read, then do simple time-interpolation between dropout's start and end, then splicing in new smpte where missing.

Not sure about the situation if you're using lossy coding (mp3 etc) for transmission or storing - those are prone to weird waveform artefacts at messed bitrates that could give you spooky waveforms. But should be detectable thus correctable with relatively simple means.

There's most probably not a plugin already existing out there, but absolutely possible at today's processing power

/Jakob E.

on a similar note, a friend once hacked a DAT-machine so he could put in timecode in the LSB. Worked pretty well despite the format's horrible weaknesses

I think it very unlikely that anyone would be using lossy codecs. The standard expected for location recording is usually 24/48 .wav. even for a lav.
The DAT/LSB idea is an interesting one.
Most importantly though, It seems the barking may not be up the wrong tree. I think I'll pursue some experiments on the recording side.

 

[The Documentary Sound Guy]

I've read your post start-to-finish twice, and I can't for the life of me figure out what problem you are trying to solve.

Not to mention, the workflow you mention with each audio source recording its own audio already exists and works perfectly fine with digital timestamps.

Zaxcom has had recording (and timecode clocks) build into their transmitters for well over a decade now, maybe two. More recently, Sound Devices is doing it with their A20-mini transmitters, and I believe Wisycom is doing the same with their MTP-60s.

All of these work just fine with their timecode-synced internal clocks. The exact mechanism to maintain sync varies a bit, but with the wireless jamming that is now available on most timecode systems, I can assure you that the timestamped digital files sync just fine without resorting to LTC.

Why on earth would you want to reinvent that with LTC and deal with dropout and the added expense of adding full-range receiver circuit (and the added issues around interference next to a transmitter) instead of a clock?

We've known that we can transmit LTC as a wireless audio signal for decades now. The standard music video workflow in the heyday of MTV used to broadcast an LTC signal in sync with the playback track so that every take could be synced in reference to the master song. Before we had timecode boxes, we used to stick Comtek receivers on the back of the timecode slate that would receive audio LTC broadcast from the sound cart. As far as I know, the first "portable" timecode boxes were designed to attach to the back of a timecode slate to replace this workflow because of all the trouble it caused. I own a Denecke TS-1 slate from the late '80's that is designed to work with either a Comtek M72 receiver or a DCode sync box, which I believe was one of the first battery-powered sync boxes that would hold sync for long periods of time.

And I haven't even gotten started on what happens if the LTC signal drifts relative to the recording clock, which means even if the timecode is "accurate" when broadcast, it won't correctly identify the frame that it was recorded with (for that you want genlock / word clock sync), which is a whole other can of worms.