Welcome, Guest
Username Password: Remember me

TOPIC: ultra low cost timecode workflow: a modest proposal

Re: ultra low cost timecode workflow: a modest proposal 1 month, 3 weeks ago #220741

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 12783
  • 1 month, 3 weeks ago
If MTC timecode is actually midi timecode, then it isn't SMPTE T/C at all. Midi apparently uses a weird structure of multiple code packets per frame. I only know about it because of one my sons has worked with midi instruments. I'm not particularly motivated to research it either. RWAV, as I see it we don't currently know whether the code is actually T/C as you or I would know it.

Motosega, If I was attempting to do this I would just use an LTC feed and forget about the MTC code altogether. The fewer variables that you have, the fewer chances that you have for things to go wrong. Assuming that the TentacleSync software is reliable (and I have no reason to believe otherwise) and assuming its conversion process is lossless in theory you should end up with a series of master audio and video clips with appropriate timestamps. If that's the case they should be fine for Lightworks.

I don't know whether the software will handle T/C dropouts or not, but that would be better determined by making a test recording with deliberately broken timecode and seeing what happens when you convert it. If all that the software does is grab the start T/C and use that to write the appropriate header data you should be fine.

But regardless of how you do it, if at all possible USE A SLATE!!!

Re: ultra low cost timecode workflow: a modest proposal 1 month, 3 weeks ago #220742

  • RWAV
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 6718
  • 1 month, 3 weeks ago
The discussion seems to be about LTC
The Phil Rees device was a MTC to LTC bi directional (?) converter,
The objective is to have matching LTC across all devices and all files created by those devices.
The intention is that all devices recording at the same time will have the same time code.

The problem is not with LW - the problem is that not all acquisition devices record timecode.

The objective is to have running time-code linked to each file
If a video file dopes not have timecode when ingested into LW - the imported LW clip will start with timecode 0:0:0:0

If at any time or place in that clip one can associate the preferred T/C with the clip - and if one modifies the LW timecode for that clip - that will be the new timecode.

There are multiple ways to show or record the time-of-day when cameras are used.

There are multiple options for sound recorders with time-of-day timecode capability. With that as a stable recorded sound with T/C start point may be there might be cheaper and more reliable next steps than TentacleSync.
BETA System
Microsoft Windows 7 Professional 64BIT
HP Z800 Workstation

Re: ultra low cost timecode workflow: a modest proposal 1 month, 3 weeks ago #220743

  • RWAV
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 6718
  • 1 month, 3 weeks ago
motosega wrote:
i will use the Tentaclesync timecode tool to export to a format that Lightworks can read timecode from. apparently it'll work with any ltc timecode.
tentaclesync.com/timecode-tool


After a quick review of the OP's post an a peruse of the TentacleSync website.

There is no problem.

The Tentaclesync timecode tool export will be in a format with embedded timecode - so no further need for a LTC audio track.

"Our Timecode Tool for Windows users reads audio timecode and prepares your footage for editing. The tool quickly converts audio timecode to file timecode and exports this so you can sync and edit your footage inside your favourite editing program.

FEATURES
Reads and analyses any timecode recorded on audio tracks, even from competitor’s products
Transcode your material to more editing-friendly codecs like DNxHD or XDCAM422"
BETA System
Microsoft Windows 7 Professional 64BIT
HP Z800 Workstation

Re: ultra low cost timecode workflow: a modest proposal 1 month, 3 weeks ago #220744

  • hugly
  • OFFLINE
  • Platinum Boarder
  • Posts: 25433
  • 1 month, 3 weeks ago
In a perfect world, a reference signal from an atomic clock would be on air, worldwide, and each recording device would have a receiver and the ability to record some standardized timecode, SMPTE or not. I can imagine that China's officials have started investigating the opportunities already.

However, since this isn't a perfect world, we'll have to wait for it, if it ever comes.

For the time being, syncing by waveform appears to be the cheapest and most convenient way to sync picture to separately recorded sound, in particular with low cost recording devices, iPhones, GoPros and such.

On many forums, PluralEyes is considered to be the state of the art, but Syncaila seems to be pretty close in terms of features and, there is a free limited version and, the full version is on 30% sale currently and, XML exchange seems to work with Lightworks.

Software like this can be a life saver, in particular for editors who have to use what they get, which sometimes isn't what they would wish to get.

www.lwks.com/index.php?option=com_kunena&func=view&catid=23&id=220122&Itemid=81#220196
It's better to travel well than to arrive...
Last Edit: 1 month, 3 weeks ago by hugly.

Re: ultra low cost timecode workflow: a modest proposal 1 month, 3 weeks ago #220750

  • motosega
  • Pro User
  • OFFLINE
  • Expert Boarder
  • Posts: 146
  • 1 month, 3 weeks ago
ok, it looks like i'm coming at this with a lot of pre concieved ideas that come from the use of smpte in audio recording.

In the audio world smpte timecode is often used to sync a midi sequencer to a multitrack analog tape recorder. the important part here is that the midi sequencer can speed up and slow down to stay in sync with the multitrack tape recorder which will be drifting slightly all the time. when syncing multiple analog tape recorders together they need to be equipped with a servo controlled motor than can speed up and slow down to keep themselves in time, which is expensive.

i'm starting to understand that this is a bit different to how it all works in film, especially in terms of computer based NLE workflow.

correct me if i get any of this wrong:

smtpe ltc timecode on an audio track is called AUX timecode. but pro equipment tends to have integrated timecode support which connects via a bnc connector. and pro digital cameras will write smpte timecode directly into their video files.

since all the video tracks are playing from the same "clock" they will never drift out of sync. Since the frame rate will never change, all that is needed is a timestamp at the START of the clip.

With just a start timecode that corresponds to the time of day when the video started recording, it is possible to make a kemroll in lightworks, which is as i understand it a sequence that contains all the days clips, positioned on the corresponding start times.

if this is the case then i only need to get the start timecode from the aux timecode for each clip and put that in the clips metadata.

i could "just" build a script with ltcdump and ffmpeg to read
the aux timecode and use it to set the start Timecode position in a video file. github.com/x42/ltc-tools
ltcdump reads the first timestamp from an ltc timecode in an audio file.
and ffmpeg can insert a timecode into a video file.

unfortunatly it turns out that the tenaclesync software is only a 14 day trial unless you plug in a tentacle sync module. so i can rule it out for anything more than testing.

Re: ultra low cost timecode workflow: a modest proposal 1 month, 3 weeks ago #220752

  • motosega
  • Pro User
  • OFFLINE
  • Expert Boarder
  • Posts: 146
  • 1 month, 3 weeks ago
there are already at least four globally available atomic clock signals, gps, glonass, galileo and beidou. satnav is just a clock signal and a bit of maths.

and there's already an android app that can produce ltc timecode synced to the gps clock. i think you need a rooted phone though.

Re: ultra low cost timecode workflow: a modest proposal 1 month, 3 weeks ago #220753

  • hugly
  • OFFLINE
  • Platinum Boarder
  • Posts: 25433
  • 1 month, 3 weeks ago
I had several comments, but the most important is:

motosega wrote:
since all the video tracks are playing from the same "clock" they will never drift out of sync. Since the frame rate will never change, all that is needed is a timestamp at the START of the clip.

That's wrong, at least with SMPTE timecode (including LTC).

SMPT timecode is supposed to label frames (or audio samples referencing video frames). The recording speed of devices, no matter if audio recorders or video cameras, is controlled by their internal clock generators, one per device, not by the external time code generator. If the internal clock generators drift, the content will drift. There are devices which allow connecting an external clock generator to bypass ** the internal clock, in a addition to the time code signal. Cameras equipped with such a genlock interface are used for TV broadcast multicam live recordings, for instance.

However, with contemporary devices, even consumer gear, this sync drift is neglectable, at least for recordings of short duration. If you encounter continuous sync drift with some of your recordings, you have a different problem.

Edit ** "Bypass" is perhaps the wrong word in this context, "stabilize" or "synchronize" might describe better what it does.
It's better to travel well than to arrive...
Last Edit: 1 month, 3 weeks ago by hugly.

Re: ultra low cost timecode workflow: a modest proposal 1 month, 3 weeks ago #220756

  • pfbr6a
  • Pro User
  • OFFLINE
  • Platinum Boarder
  • Posts: 598
  • 1 month, 3 weeks ago
motosega wrote:
"and pro digital cameras will write smpte timecode directly into their video files."

This is sort of my specialist subject, so (nervously) I'd like to weigh in here and try to help simplify things.

Firstly, SMPTE timecode on audio tracks really should, at this point, be utterly obsolete - it's been pointless since the beginning of digital recording - but sadly many people at the recording end (mainly professionals who really should know better) insist on using horrible hacky workflows that the poor bastards in post-production then have to deal with as best they can. This has been the situation for over twenty years now.

Anyway, enough of that. From first principles, it's all incredibly simple. Everything you record is a sample of something - video, audio, data or anything else. Each sample is recorded at a particular instant in time, and if you manage to *label* every sample accurately with that instant, and maintain the label down the entire workflow, then all problems of synchronisation go away entirely and forever.

What do we mean by "time" here? Anything that is agreed as being the same point of reference for all samples will do, and there are many variations of how to achieve that. By *far* the best way is to label all samples with the world-time when they were created, because this (ignoring relativistic effects) means that all samples with the same label, wherever they were recorded, are by definition in synch. I can make a recording in Australia, and you can make one in Greenland, and if they have the same label they can be synchronised perfectly.

So how can this be achieved? Ideally, every device that makes samples will have an accurate world-clock and use that do generate labels in whatever format is appropriate for the kind of samples it is making. Then all that the rest of the workflow software has to do is read those labels, and the entire job is done.

In practice, that's now very often actually the case. Most cameras (except for some higher-end cinema stuff) have an internal clock, and label every sample. Many, perhaps most, of those clocks are accurate and stable enough to serve as a reliable reference for the kind of synchronisation issues we are talking about.

Specifically, any device that has a GPS receiver also has access to an ultra-accurate clock, and certainly *could* produce a label that is perfect for all purposes. Whether it *does* is up to the designers, but there's a good chance that the cameras you use can do this all on their own.

That's not hard to test: point them all at the same thing and see if the frame when a particular thing happens has the same timecode on each recording.

Even if that isn't automatically the case (the camera doesn't have, or isn't using, the GPS clock), most internal clocks are more than stable enough to hold synch for a period of time long enough to cover a shooting period. If you synchronise them carefully at the beginning, you would be unlucky if your particular devices drift enough to be a problem in this respect. Again, this is easy to test: shoot the same thing with all of them, ingest the files, read the timcodes and note the differences. Then do the same thing a few hours later: the differnces should be unchanged.

All your devices produce digital files, and all digital file-formats in common use have places where timecode labels go, so there is never any real need to waste any of the tracks that record the main data. The formats of the timecode labels vary, and there may be more than one.

As an example, any Quicktime-style file will have a timecode track, which most usually encodes a single timecode that labels the start of the recording and relies on the frame-rate being stable to calculate the rest. This is also true for BWAV audio recordings, and is how Lightworks has traditionally operated.

On the other hand, the video-format itself will probably have a place for a timestamp in the header of each frame: smartphone or action cameras typically have only a nominal frame-rate, and in practice take the time they need. However, when each sample is labelled in this way with world-time, frame-rate can in principle be regarded as completely irrelevant in almost all aspects of post-production (as can time itself, but that's a separate discussion).

Unfortunately, while software is all moving towards this paradigm, most of it - including Lightworks - hasn't got there yet, so we still have to rely on the cameras having a "fixed-enough" frame-rate. Audio, of course, always has a fixed sample-rate - it would sound awful otherwise without pointlessly-heroic efforts to compensate.

So (and I'm sorry this became so long, but I'm really only scratching the surface), if I were you I would ask myself the following questions:

1) Do my devices have an automatically-accurate timestamp? As mentioned above, that's easy to test.

2) If they don't, do they have a stable one that can be synchronised (by setting the date/time on all of them) at the begining of a shooting-period. Remeber, even if you can't get them all perfectly synchronised, you can measure their offset, and as long as they are stable you can simple apply that consistently. That's admittedly slightly tedious, and it could be automated-out - but again that's a separate discussion.

3) Cases 1) or 2) should be true for most cameras. If your cameras expect a separate clock-source, you will be able to find a source that provides the time in a form that will be injected into the file-headers. No need for SMPTE.

4) Any audio-recorder worth using should either do this itself, or be easy to connect to something that does. If it doesn't, it'll be cheaper to find something else that does. Again, forget SMPTE.

I hope this is helpful: I'm happy to go into any of it in greater depth if that's of any use.

Re: ultra low cost timecode workflow: a modest proposal 1 month, 3 weeks ago #220758

  • hugly
  • OFFLINE
  • Platinum Boarder
  • Posts: 25433
  • 1 month, 3 weeks ago
pfbr6a wrote:
No need for SMPTE.

I agree to many of your statements, but the editing business is using the SMPE T/C notation almost everywhere. I believe, as long as constant frame rates are industry standard, and I don't see them disappear in the near future, that will not change.
It's better to travel well than to arrive...
Last Edit: 1 month, 3 weeks ago by hugly.

Re: ultra low cost timecode workflow: a modest proposal 1 month, 3 weeks ago #220760

  • pfbr6a
  • Pro User
  • OFFLINE
  • Platinum Boarder
  • Posts: 598
  • 1 month, 3 weeks ago
I'd draw a clear distinction between the *time* of a labelled frame and the *notation* by which it's made use of. Those are completely independent things, and the same time will be notated in different ways for different purposes.

For example, as far as I can tell LW itself handles time as fractional seconds (doubles): any point on a timeline has an implicit label derived from the start-label (converted to seconds) plus the position of the point, also in seconds.

Internally, calculations are all done using these fractional seconds: but for display and similar purposes, they may be converted to a format appropriate to the type of the label, typically a similar layout to traditional SMPTE HH:MM:SS:FF.

As long as people want to use that notation, they should - and as you say that's probably forever because it is natural and convenient. But you can do that irrespective of whether SMPTE or any other formatted timecode is used internally, and there's every reason never to do that.

For example, if you label audio samples with SMPTE, then the intrinsic accuracy is one frame and you have to go through hoops to improve that. Why would you want to? The sample was actually made at (say) a number of microseconds after some agreed baseline, and you can simply store that instead.

Then, if you want to see a SMPTE timecode, the conversion is trivial - meanwhile, you have sub-sample accuracy in your timings, which is what you need for serious purposes.
Last Edit: 1 month, 3 weeks ago by pfbr6a.

Re: ultra low cost timecode workflow: a modest proposal 1 month, 3 weeks ago #220794

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 12783
  • 1 month, 3 weeks ago
pfbr6a wrote:
Firstly, SMPTE timecode on audio tracks really should, at this point, be utterly obsolete - it's been pointless since the beginning of digital recording - but sadly many people at the recording end (mainly professionals who really should know better) insist on using horrible hacky workflows that the poor bastards in post-production then have to deal with as best they can.

Unfortunately very true!!!

And the reason that it's still around is probably as much due to the fact that professionals tend to be extremely conservative as for any technical reason. They are reluctant to risk jeopardising their ability to earn a living by being seen to indulge in needless technical experiments - especially if there's a risk of something going wrong with a technology that they don't really understand. They find a workflow that works, and they stick with it.

You really can't blame them, but it can be frustrating.
Last Edit: 1 month, 3 weeks ago by jwrl.

Re: ultra low cost timecode workflow: a modest proposal 1 month, 3 weeks ago #220820

  • pfbr6a
  • Pro User
  • OFFLINE
  • Platinum Boarder
  • Posts: 598
  • 1 month, 3 weeks ago
jwrl wrote: ".. They find a workflow that works, and they stick with it. You really can't blame them, but it can be frustrating."

I completely agree with you that you *couldn't* blame them for the first few years of digital recording, but it's been twenty years now since location audio became digital, and ten since the same became true of video.

At this point, I most certainly *do* blame them for making everyone else's life difficult, and it's hard to attribute to anything other than laziness, incompetence, or worse yet greed - because sadly there are people out there deliberately making things seem more difficult than they really are, and then getting highly-paid for solving the non-existent problems.

The industry has been hurt by these sins, I've personally been put through a lot of pain by them, and I feel no impetus whatsoever to forgive them anymore

Re: ultra low cost timecode workflow: a modest proposal 1 month, 3 weeks ago #220861

  • motosega
  • Pro User
  • OFFLINE
  • Expert Boarder
  • Posts: 146
  • 1 month, 3 weeks ago
ok, thanks everybody for the help, it looks like i have some testing to do.


it looks like i'll end up either just using the time of day from the cameras, taking a shot of a clapperboard at the beginning of the shoot, working out the time offset and using that to correct the start timecode for each clip.

Or, running ltc timecode and using ltc tools to get the start time from my clips.

This really depends on how all the cameras work, some are pretty far on the consumer side and only one of them is actually mine. a canon eos750d.

Re: ultra low cost timecode workflow: a modest proposal 1 month, 3 weeks ago #220862

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 12783
  • 1 month, 3 weeks ago
pfbr6a wrote:
I completely agree with you that you *couldn't* blame them for the first few years of digital recording, but it's been twenty years now since location audio became digital, and ten since the same became true of video.

You left out my reference to "a technology that they don't really understand". In a lot of cases I suspect that may also have something to do with it. People who use digital media don't always understand that it contains an inherent clock.

Let us know how it works out for you, motosega. It sounds like you could be in for some interesting times.
Last Edit: 1 month, 3 weeks ago by jwrl.

Re: ultra low cost timecode workflow: a modest proposal 1 month, 2 weeks ago #220883

  • briandrys
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 10040
  • 1 month, 2 weeks ago
Given how quickly you can get fired on a film production, the conservative nature of things is understandable.
Time to create page: 0.53 seconds
Scroll To Top