Jump to content

How precise is Timecode sync?


Recommended Posts

Interesting article, thanks!

Unfortunately, it's not written with enough audio knowledge to fully address the problems we were exploring in this thread.

 

I'm intrigued by the idea of using synchronized internet time as a timecode source for all media, but I'm very much unconvinced it can serve the purpose that syncing word clocks serves.  It touts that "millisecond" precision would solve the "not narrow enough resolution" issue (i.e. timecode only represents frame-labels, not sample labels), but uniquely labelling audio at the sample level can't be done with millisecond precision — microsecond precision is required.  I'm not sure how precise internet time sync is, but given that IP latency is measured in milliseconds (and latency is variable packet to packet), I very much doubt it provides adequate precision for sample-accuracy.  It's also highly unlikely they would stay in sync with millisecond precision for very long without re-jamming, which just brings us back to all the problems we have been discussing here, namely, how long will two clocks maintain precision before they drift.

 

Maintaining timecode with millisecond or microsecond precision based on a common internet source sounds like a great idea from a post workflow point of view, but it sounds like an engineering nightmare to implement with the promised accuracy if it is possible at all.

 

-----

 

I did appreciate that the article succinctly spelled out the problem I was trying to solve when I started this thread (and still don't have a complete answer for) under the heading "The Problem of Size".  Namely, a timecode frame is ~2,000 samples long, which leaves it unclear how sample-level precision can be achieved with timecode sync, since a timecode stamp only identifies a sample to within +/- ~2,000 samples.  Word clock can make sure that clocks don't drift, but because the wordclock signal doesn't carry *label* information, it can make sure that samples are the same length, but there is no mechanism that can identify two samples on different recorders as representing the same point in time.  Labelling is the purpose of jamming timecode, and SMPTE timecode doesn't have an (obvious) way to label samples with better than frame-level precision.  Additionally, my understanding at the moment is that there's no "standard" for how precisely "jamming" timecode across devices is required to be beyond basic frame-level precision.

 

One of these days, I'm going to actually test all my different timecode equipment and see what I can learn about how precisely they jam and how much they drift.

Link to comment
Share on other sites

On 11/12/2022 at 7:02 AM, The Documentary Sound Guy said:

The Problem of Size".  Namely, a timecode frame is ~2,000 samples long, which leaves it unclear how sample-level precision can be achieved with timecode sync, since a timecode stamp only identifies a sample to within +/- ~2,000 samples.

 

Not really.
Imagine the following scenario:
You're standing on a track, a high speed train is coming towards you, traveling at 100 meters per second. The train is 100 meters away.

When will you get hit?
Does it matter how long the train is?

 

Now, unless you have digitized the timecode (assuming LTC, timecode can also travel as metadata, or in old fashioned 422), a bit has a length measured in time, not in samples. Samples is only relevant in this matter if you know the samplerate. Normal LTC has  a 'sample rate' of 80 per frame (80 bits...)

Thus, in theory, timecode COULD be used for syncing like Wordclock, as every piece of equipment knows exactly when a new 'frame' starts. (Note, 'video' frame, an audio frame in the digital world would mean sample), like the engine of the train, that's the part that will hit you.

I've discussed this some years ago with Ambient, and we agreed that this indeed 'could' be implemented, but afaik, no one ever made something like this in hardware.
My software LTC convert however does this.
Since it knows highly accurate what the relation is between video (always starts at a full frame) and audio, it is possible to do subframe accurate syncing.
But only if you either go over XML or change the BWF timestamp instead of the video timestamp.

Following this logic, it is also possible to sync two files and correct for speed changes, by measuring the time between the first and last found LTC frames, and do a tiny bit of math.

But there is no need for this. If you don't have long recordings, with any half decent piece of equipment you will stay in sync. Speed differences without wordclock / genlock will only occur after half an hour, or way more.
For very long recordings, just bring the good stuff.

More important for phase / timing issues are your precious wireless thingies.
A typical wireless mic will introduce 19 msecs of delay, and that is about half a video frame, thus, A LOT.
(What I don't get is why not everyone is shooting Mono Wave, and give a -19msec BWF offset to the tx/rx files, and while we're at it, compensate for the distance of the boom to the subject.)

As said, there are plugins that will take care of this in post. And normally post WILL give an offset every now and then.
(Blowing up a building is normally  filmed from far away, say 300 meters. Sound travels at 300 meters per second, so to get the sound in sync with the image, you have to give it an offset. Is that logical? Yes and no, it's not how it is perceived in the real world, but it is in movies, like spaceships exploding, space is vacuum, carries no sound, but go to the theater...)

Conclusion,
Get friends with some post guys, ask what they like, and indeed, test test test.
(And then test more : - )

Link to comment
Share on other sites

On 11/11/2022 at 7:08 PM, PCMsoundie said:

 

Audinate says:
"Digital audio requires synchronization for accurate playback of audio samples. Dante uses Precision Time Protocol (PTP version 1, IEEE 1588-2002) by default for time synchronization. This generates a few small packets, a few times per second. One clock leader is elected on a per subnet basis that sends multicast sync and follow up messages to all followers. Follower devices send delay requests back to the leader to determine network delay."

 

Here is the update on that protocol:

IEEE SA - IEEE 1588-2019

 

Gotham Sound did a Dante setup for multitrack audio for location sound in a Youtube Video and found that the PTP in Dante was still unreliable and they needed to use Wordclock for reliability over say 18 hours.

For Digital audio the gold standard for staying in sync between multiple digital audio devices is wordclock.

 

The main problem with Dante clock sync is, I am pretty sure, the appalling state of the computer industry and, hence, most of the networking products. 

 

You can't imagine how much disregard there is for standards, let alone bugs implementing complicated specifications for seldom used protocols. 

 

That protocol is based on multicast, which performance can vary widely.

 

 

On 11/12/2022 at 7:02 AM, The Documentary Sound Guy said:

Interesting article, thanks!

Unfortunately, it's not written with enough audio knowledge to fully address the problems we were exploring in this thread.

 

I'm intrigued by the idea of using synchronized internet time as a timecode source for all media, but I'm very much unconvinced it can serve the purpose that syncing word clocks serves.  It touts that "millisecond" precision would solve the "not narrow enough resolution" issue (i.e. timecode only represents frame-labels, not sample labels), but uniquely labelling audio at the sample level can't be done with millisecond precision — microsecond precision is required.  I'm not sure how precise internet time sync is, but given that IP latency is measured in milliseconds (and latency is variable packet to packet), I very much doubt it provides adequate precision for sample-accuracy.  It's also highly unlikely they would stay in sync with millisecond precision for very long without re-jamming, which just brings us back to all the problems we have been discussing here, namely, how long will two clocks maintain precision before they drift.

 

Internet time synchronization (the NTP protocol) uses statistics to achieve sub millisecond accuracy. In proper implementations it does it without "jumps", by carefully adjusting the clock frequency so that time is a monotonic funtion (I mean, each and every second exists, it won't adjust a clock sledgehammer style changing the second number).

 

Still, hardware accuracy matters. If you don't have a good TCXO NTP will not make miracles although sometimes it really looks like magic.

 

These techniques can be also used with a GPS clock reference which benefits from the accuracy of the GPS satellite clock. 

 

 

On 11/12/2022 at 7:02 AM, The Documentary Sound Guy said:

 

Maintaining timecode with millisecond or microsecond precision based on a common internet source sounds like a great idea from a post workflow point of view, but it sounds like an engineering nightmare to implement with the promised accuracy if it is possible at all.

 

 

On 11/12/2022 at 7:02 AM, The Documentary Sound Guy said:

 

I did appreciate that the article succinctly spelled out the problem I was trying to solve when I started this thread (and still don't have a complete answer for) under the heading "The Problem of Size".  Namely, a timecode frame is ~2,000 samples long, which leaves it unclear how sample-level precision can be achieved with timecode sync, since a timecode stamp only identifies a sample to within +/- ~2,000 samples.  Word clock can make sure that clocks don't drift, but because the wordclock signal doesn't carry *label* information, it can make sure that samples are the same length, but there is no mechanism that can identify two samples on different recorders as representing the same point in time. 

 

Maybe labelling each and every sample is overkill and it's better to focus on avoiding clock drift in the first place anyway. If you have an accurate label

for the first sample in a video frame and clock drift it really small, well, we can say you nailed it.

 

For a nice application of wide area clock synchronization for non audio purposes you can have a look at a nice website called Blitzortung. 

 

And this is dealing with radio waves travelling at the speed of light rather than sound.

 

In a very succint way, sensors receive and timestamp the radio signals originated by thunderstorms and send the timestamped information to a central server where the positions of the discharges are computed.

 

Especially the real time map is spectacular.

 

https://map.blitzortung.org/#1/17.6/8


And, by the way, this website can be incredibly useful for outdoors shots, etc.

 

 

Link to comment
Share on other sites

On 11/11/2022 at 9:31 PM, Jim Feeley said:

The site says it's a 28-minute read.

 

If you are a very slow reader... I did read it all, and it's not really interesting for normal production, as we all rely on stuff that is available today.
Most stuff nowadays just works, and if you need enhancements in your workflow, people like me are available to improve it.
But with off the shelf products, it IS possible to create something. (And that has been the case since the stone age, see cave paintings.)

The article isn't that interesting to me, and in some points plain wrong. (Don't get me started on how to use math to solve 'issues'.)
The interesting point is the TLX project, where some smart people are trying to solve problems before they exist. (I don't think that ever worked fully, but there are a lot of examples where things have been made 'quite' future proof, but sadly a lot other examples where a new standard was outdated the day it was introduced.)

What we all know, we have two standards, that's not practical, let's introduce a new one to overcome that, now we have three standards...
 

Link to comment
Share on other sites

9 hours ago, Bouke said:

 

What we all know, we have two standards, that's not practical, let's introduce a new one to overcome that, now we have three standards...
 


I definitely had the same thought when I read it!

11 hours ago, Bouke said:

Now, unless you have digitized the timecode (assuming LTC, timecode can also travel as metadata, or in old fashioned 422), a bit has a length measured in time, not in samples. Samples is only relevant in this matter if you know the samplerate. Normal LTC has  a 'sample rate' of 80 per frame (80 bits...)

 

This is new information to me, and is the actual practical answer to the question I originally asked about how precise timecode (meaning LTC) is.  Thank you!  Do you have a source for further reading?

11 hours ago, Bouke said:

Following this logic, it is also possible to sync two files and correct for speed changes, by measuring the time between the first and last found LTC frames, and do a tiny bit of math.

I wish this was universally true.  Experience teaches me that it's not ... if the clocks are drifting at variable rates, sometimes drift is beyond correction with a linear speed change.  I'm pretty sure the circumstances I experienced this under was an equipment malfunction, so it's probably very rare, but it did happen...

Link to comment
Share on other sites

10 hours ago, borjam said:

Maybe labelling each and every sample is overkill and it's better to focus on avoiding clock drift in the first place anyway. If you have an accurate label

for the first sample in a video frame and clock drift it really small, well, we can say you nailed it.

It's overkill for video sync.  My context here was syncing between audio recorders and maintaining phase accuracy between them.

I don't think you need to label every sample ... the first will suffice (i.e. in a metadata timestamp, so that future labels can be extrapolated as long as long as clock drift is accounted for).  The problem I'm trying to solve isn't drift (that's what wordclock is for).  The problem is a labelling problem:  How do you know when a sample labelled 01:23:45:23 matches another sample from a different recorder with the same label if there are ~2,000 samples that share that label on each recorder (whether they are directly labelled or the label is extrapolated).

The logical solution is to align the *first* sample from each recorder that bears that label (i.e. try to synchronize based on when the label changes rather than solely relying on the number represented by the label).  The problem is that it's not clear that jamming across devices provides a guarantee that two separately jammed LTC sources will change labels at the point in time which represents the same sample in both devices.  In essence, the *timecode* clocks need their word clocks locked to provide this guarantee, which isn't how they are designed.

I think the closest it's possible to get is to use the same LTC source for both recorders in a master-slave configuration (aka continuous jamming), but even then, if there's any processing latency in the slave recorder, there will be a sync offset even if the wordclocks are jammed and there is no drift.

Link to comment
Share on other sites

4 hours ago, The Documentary Sound Guy said:
16 hours ago, Bouke said:

Normal LTC has  a 'sample rate' of 80 per frame (80 bits...)

 

This is new information to me, and is the actual practical answer to the question I originally asked about how precise timecode (meaning LTC) is.  Thank you!  Do you have a source for further reading?

 

You totally did NOT understand a word I've written, start over please

 

4 hours ago, The Documentary Sound Guy said:

How do you know when a sample labelled 01:23:45:23 matches another sample from a different recorder with the same label if there are ~2,000 samples that share that label on each recorder (whether they are directly labelled or the label is extrapolated).

 

this is NOT the case with BWF files. BWF files DO NOT have timecode, but a frame label, where each sample is a frame.
This has been written in this thread several times by several people.
Please, start over from the beginning, you have not grasped even a bit.

 

 

Link to comment
Share on other sites

  • 1 month later...
On 8/4/2022 at 5:40 AM, The Documentary Sound Guy said:

Ok, thanks for confirming.  I'll consider my options with a DAW setup, I think you're right, jamming together two recorders of different brands and quality is asking for trouble.

Since I clearly don't own any recorders that support word-clock sync, it probably makes sense to rent a recorder with enough tracks (I think I'm at 23 at the latest count).  But, failing that, what recorders are out there that *do* support word-clock sync?  Sound Devices?  I'm guessing the 788.  Any others?

Jamming two recorders of different brands and quality is not asking for trouble at all..... so long as you are able to send word clock from one machine to the other, or from a generator to both recorders. Some portable TC generators can make TC and wordclock or sync pulses. Good luck, sb

Link to comment
Share on other sites

1 hour ago, Bash said:

Jamming two recorders of different brands and quality is not asking for trouble at all..... so long as you are able to send word clock from one machine to the other, or from a generator to both recorders. Some portable TC generators can make TC and wordclock or sync pulses. Good luck, sb

I do this all the time, with WC+TC.  The sets of files form the 2 (or 3 or 4) disparate machines snap into dead sync in the DAW via their TC.

Link to comment
Share on other sites

Yeah, unfortunately, despite our best efforts we failed to (collectively) say in this thread, simply and concisely, what we intended to - and the thread ended up a bit of a mess with the original poster seemingly grasping much of what was said incorrectly and much of the rest not at all. I nearly had another go myself to straighten it out but had no time ... and thought also, "what could I do here to summarise - facts, technology, workflow - without just adding another layer of confusion"? A bit of a shame - it doesn't always work out as we would like.

 

Jez

Link to comment
Share on other sites

  • 1 month later...
On 11/11/2022 at 3:31 PM, Jim Feeley said:

In July, frame.io posted a long article about the history, current state and limitations of, and possible future of timecode. The site says it's a 28-minute read. I have not yet read the whole thing.

 

Timecode is Not Time: Reinventing SMPTE ST-12 for the Cloud Era

In the world of video, timecode is everywhere.

It’s the universal language we can use to describe a single frame of video. It’s easy to understand, simple to implement, and readable.

Every video workflow either relies on timecode, or at least need to be compatible with it. And yet timecode is, in its current state, insufficient for the future of video workflows.

 

[then after a long discussion, towards the end of the article:]

 

The TLX Project being developed at SMPTE is the most comprehensive of the proposed solutions. “TLX” comes from “Extensible Time Label”. It addresses many of the limitations we discussed as well as many of the requirements outlined here.

The goal of TLX is to create a time label that has high precision (solving for the “too narrow” problem), a persistent media identifier, and can be extended with custom information. TLX has the concept of a “digital birth certificate,” which provides a media identity that is unique and transportable. Additionally, it would provide a “Precision Time Stamp” based on IEEE 1588 Precision Time Protocol. This would give the media a specific and unique time identity.

 

The whole article can be read here:

https://blog.frame.io/2022/07/11/reinventing-timecode-for-the-cloud/

 

The article above embeds this 65-minute webcast from SMPTE's former Director of Standards & Engineering:

Beyond SMPTE Time Code - the TLX Project

https://www.smpte.org/webcast/beyond-smpte-time-code-the-tlx-project

 

 

Thanks for this! Great read.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...