Welcome, Guest
Username Password: Remember me
Anything that doesn't fit into any other category.
  • Page:
  • 1
  • 2

TOPIC: The ultimate timecode sync device

Re: The ultimate timecode sync device 2 weeks, 4 days ago #222353

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 12769
  • 2 weeks, 4 days ago
pfbr6a wrote:
SMPTE timecode doesn't even give you the date (barring futzing about with the userbits).

Back in the '70s a company that I knew of here in Australia did exactly that, I believe using some sort of day count in user bits. I don't know the details because I didn't work for or with them though. I don't even know if it was their original work - it may have been "borrowed" from elsewhere.

But there's nothing new under the sun.
Last Edit: 2 weeks, 4 days ago by jwrl.

Re: The ultimate timecode sync device 2 weeks, 4 days ago #222354

  • RWAV
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 6717
  • 2 weeks, 4 days ago
hugly wrote:
One of the drawbacks of SMPTE timecode is that it doesn't include the date. If it would include the date, something like UTC (or whatever time reference) would be suitable for everything.

Actually SMPTE timecode does include date information.
It is entered in user bits fields in acquisition devices like cameras and sound recorders. Generally these devices have dedicated, accessible, easy to navigate date entry procedures.
By definition date needs to change only once in every 24 hours.
By definition that makes it less than onerous

Some productions' SOP is to enter date in sound and video SMPTE coded media - in general most do not require it since all production details and media are sorted and categorised by date anyway.

hugly wrote:
It would even be possible to synchronize recordings simultaneously captured in New York and Melbourne and then, the precision of a satellite based atomic clock (e.g. provided by the GPS) would be a real benefit.


Live broadcast switching between widely separated sources is common practice - it does not require everyone to work on UTC time. It does require all locations be sync locked - standard operating procedure for many years- (wordclock sync is also the information required for real-time conversion between frame rates). nothing to do with timecode.
If one of the locations cues in a pre-recored segment - that runs to it's own timecode - again nothing to do with UTC

This image is hidden for guests. Please log in or register to see it.


jwrl wrote:
I believe using some sort of day count in user bits. I don't know the details because I didn't work for or with them though

Might that have been something made possible by fiddling with incrementing user bits??? Have only been aware of auto incrementing user bits as a 'take' counter?? Perhaps also a 'shot' counter????
BETA System
Microsoft Windows 7 Professional 64BIT
HP Z800 Workstation

Re: The ultimate timecode sync device 2 weeks, 4 days ago #222356

  • hugly
  • OFFLINE
  • Platinum Boarder
  • Posts: 25378
  • 2 weeks, 4 days ago
Since the usage of the user bits is standardized nowhere, people working together on the same database have to agree what the bits and possible combinations mean in a particular context.

The SMPTE TC standard is out there for over 50 years, more or less unmodified, but I'm not aware of any commonly accepted agreement what the user bits should be used for. That's probably the reason that no NLE I'm aware of extracts date information from user bits of SMPTE timecode.
It's better to travel well than to arrive...
Last Edit: 2 weeks, 4 days ago by hugly.

Re: The ultimate timecode sync device 2 weeks, 4 days ago #222359

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 12769
  • 2 weeks, 4 days ago
jwrl wrote:
I believe using some sort of day count in user bits. I don't know the details because I didn't work for or with them though

RWAV wrote:
Might that have been something made possible by fiddling with incrementing user bits??? Have only been aware of auto incrementing user bits as a 'take' counter?? Perhaps also a 'shot' counter????

Could have been. It's too long ago for me to be really positive one way or the other. In the '90s it wasn't uncommon to encode shot and take data in user bits, but very rarely did I ever see it used. Most people I knew (me included) ignored it and relied on the slate and the PA's notes instead.

I know that a Sydney-based post production company also in the '70s used a modified in-house timecode generator that would roll over from 23:59:59:24 to 24:00:00:00 and continue counting. We had to sort out one of their projects. What a mess!

And people wonder why we get a little nervous about the need for valid reliable timecode that has meaning...
Last Edit: 2 weeks, 4 days ago by jwrl.

Re: The ultimate timecode sync device 2 weeks, 3 days ago #222376

  • motosega
  • Pro User
  • OFFLINE
  • Expert Boarder
  • Posts: 145
  • 2 weeks, 3 days ago
In my spare time i was looking into into the difficulties of making something like this from easily available parts and software.

parts cost is really pretty low for a module like this, which is basically just a gps receiver and a small embedded computer with an accurate rtc module.
small embedded computer = €15 for a raspberry pi zero.
gps receiver module = 20€-60€ depending on quality(it'd be hard to say what the cheapest suitable model is without testing)
precision rtc module = 10€ seedstudio makes a cheap one.
battery = 20€ lipo and charger.
case, switches, leds and various connectors: 20€

thats less than 100€ per module.

as far as software is concerned, there is existing open source software available (ltctools)that would enable the creation of a system that constantly updated it's system clock to the Gps time. and when timecode generation started, run from its own internal clock. (kind of half way between this and tentacle sync).

it looks like there isn't an open source solution that can correct it's time dynamically from an external time source though.(would you even want timecode that drifts like that?)

the time to get this all up and running would probably be a few evenings of writing messy little bash scripts to tie it all together.

the commercial solutions are about as cheap as we could reasonably expect them to be, since the companies who make them need to design hardware,develop software, do testing and get paid.

it's only a matter of time until somebody does an opensource version though.

Re: The ultimate timecode sync device 2 weeks, 3 days ago #222377

  • hugly
  • OFFLINE
  • Platinum Boarder
  • Posts: 25378
  • 2 weeks, 3 days ago
By the way, modern consumer gear tend to capture in variable frame rates, some even ignore that there has been standard frame rates for decades. They work with the time stamps on each frame and the clock reference is the system clock of the playback/recording devices. That isn't supported by SMPTE timecode either.
It's better to travel well than to arrive...
Last Edit: 2 weeks, 3 days ago by hugly.

Re: The ultimate timecode sync device 2 weeks, 3 days ago #222432

  • RWAV
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 6717
  • 2 weeks, 3 days ago
Consumer equipment does not support SMPTE timecode. Parallel universes -
BETA System
Microsoft Windows 7 Professional 64BIT
HP Z800 Workstation

Re: The ultimate timecode sync device 2 weeks, 2 days ago #222462

  • motosega
  • Pro User
  • OFFLINE
  • Expert Boarder
  • Posts: 145
  • 2 weeks, 2 days ago
i just realised that these are the same people who made the opensource LTCSync tool.

github.com/arikrupnik/ltcsync
  • Page:
  • 1
  • 2
Time to create page: 0.36 seconds
Scroll To Top