Creative Communities of the World Forums

The peer to peer support community for media production professionals.

Activity Forums Creative Community Conversations Can we perhaps hold the triumphalism …?

  • Oliver Peters

    March 19, 2016 at 11:47 pm

    [Bill Davis] “Are you saying that modern timepieces lose accuracy if they aren’t hooked up to a reliable constant timing source? That’s not my experience at all.”

    I don’t know, Bill. I see no clocks in typical appliances and modern automobiles that run accurately. If you start two cameras in sync (using TC) at the beginning of the day, they will be significantly out of sync by the end of the day if you don’t resync them periodically.

    – Oliver

    Oliver Peters Post Production Services, LLC
    Orlando, FL
    http://www.oliverpeters.com

  • Tim Wilson

    March 20, 2016 at 12:05 am

    [Oliver Peters] “I see no clocks in typical appliances and modern automobiles that run accurately. “

    Right, because they’re not constantly polling the network. They only check in periodically. For example, in my computer, it’s once every 22 hours.

    I don’t see any evidence that my car ever checks the network, even though many, many pf my car’s systems are connected to networks (GPS, mfr-installed satellite internet for built-in internal wifi, and mfr-installed satellite radio among them).

    In the interim, they use internal clocks, which may or may not be consistent.

    I can only guess at how often cameras ask networks what time itis, but even if you manually reset the time of day every time you set white balance, who the hell white balances anymore? LOL Kidding aside, unless the source is continuously calibrated, audio drift is quite likely, and quite well documented.

    Audio drift is notorious even on timecoded sources that aren’t connected to house sync. Pluraleyes has a whole set of features just to address this single aspect of reality.

    At the risk of invoking the tired “Apple doesn’t develop feature sets with professional workflows in mind” trope, the fact is that all of these issues were addressed a long time ago, with rock solid, well-developed feature sets.

    Tossing out the careful management of timecoded sources because you want a more flexible way of editing them is the very definition of throwing out the baby with the bathwater.

  • Marcus Moore

    March 20, 2016 at 2:13 pm

    SnL syncs purely by matching TC- so my first thought would be timecode drift between the camera and the recorder.

  • Mike Warmels

    March 20, 2016 at 2:29 pm

    Yes, there was. But it would be nice to be able to see that immediately. Now you first have to go into the synched clip and check the TC of both the video and audio separately. A multiple TC window would give me that info at one glance.

  • Marcus Moore

    March 20, 2016 at 3:25 pm

    In he scenario I’m imagining (we actually had this happen a few days on our show with a bad cable) you wouldn’t see the TC descrepancy in the windows, because SnL has actually matched them correctly. Because of sync loss on set, you have to do manual offsets to the clips after creating the Sync Clips, the offset getting wider the longer the drift was undiscovered.

  • Mike Warmels

    March 20, 2016 at 3:36 pm

    Yes, that’s bad stuff. It’s in cases like this the multiple timecode windows are invaluable. You can spot something’s wrong immediately and also where the problems are.

    Not synch with identical timecodes: that means trouble in the in timecode registration! Which makes you check immediately if it gets worse. In fact, you can even spot that immediately. I think I’ll post another feature request.

  • Bill Davis

    March 20, 2016 at 9:10 pm

    [Jeremy Garchow] “So call it whatever you want, but seeing the relative time of EACH clip, including audio, would be very useful to a great number of people.”

    I’m not arguing any different.

    I just think a system where ALL the cameras are locked to universal time of day – to the tiniest fraction of a subframe no matter what timekeeper your workflow prefers – has the potential to allow all that and more.

    What it takes is a consensus that the old system (which nobody’s arguing was a bad thing at ALL) might give way to something better.

    I think ALL the cameras – no matter where they are geographically located (time zones, etc) and no matter HOW the camera operators set them (rec run, free run, or just building in a simple wi-fi or satellite reader to perfect the already existing CLOCK TIME in most cameras)) would be a great advantage.

    Then whether you wanted to use traditional disconnected timecode OR more universal UTC – you’d be OK..

    That’s all.

    Know someone who teaches video editing in elementary school, high school or college? Tell them to check out http://www.StartEditingNow.com – video editing curriculum complete with licensed practice content.

  • Jeremy Garchow

    March 21, 2016 at 3:34 pm

    [Bill Davis] “I just think a system where ALL the cameras are locked to universal time of day – to the tiniest fraction of a subframe no matter what timekeeper your workflow prefers – has the potential to allow all that and more.

    What it takes is a consensus that the old system (which nobody’s arguing was a bad thing at ALL) might give way to something better. “

    But why are you assuming all the source material is camera based?

    If I edit a promo from an existing trailer, or cut down, or rough cut of a movie, that is making an edit from an edit. And when the master edit changes, or is returned to me with slight differences, what good is a GPS clock going to do me?

  • Bill Davis

    March 21, 2016 at 11:15 pm

    [Jeremy Garchow] “And when the master edit changes, or is returned to me with slight differences, what good is a GPS clock going to do me?”

    Presuming the GPS time signal is embedded into the footage in exactly the same way 00:00:00:00 based timecode is today – it’s going to do you precisely the same good that VITC and tape track based timecode did back in the day. There’s literally NO functional difference if the camera manufacturers support it. Again, most already do. They just give you the OPTION to run time of day instead of isolated Timecode. Most of us pass it over, because for so long cameras were disconnected devices – and there was too much instability and drift. So you HAD to take a house time hack or Gunlock to a master clock to do stuff like Multiple camera shooting. But today that’s changed. If they can put a chip in a cel phone that keeps super accurate time – updated when there’s web access – then it’s got to be reasonably simple for a camera manufacturer to do the same.

    So you lose nothing and gain a lot.

    IF we can overcome the inertia of “that’s how TC works and always has – so don’t mess with it.”

    Which seems to be a popular position in certain circles around here. That’s all. .

    ; )

    Know someone who teaches video editing in elementary school, high school or college? Tell them to check out http://www.StartEditingNow.com – video editing curriculum complete with licensed practice content.

  • Oliver Peters

    March 21, 2016 at 11:51 pm

    [Bill Davis] “Presuming the GPS time signal is embedded into the footage in exactly the same way 00:00:00:00 based timecode is today”

    Except that GPS is not human readable unless you mean only the clock signal. Then there is no correlation to frames – only fractions of seconds. Plus this requires a camera with cell or wifi capability to sync to the network or accurate GPS reception. Not an option in many locations. Great for the military, not so great for the average videographer.

    – Oliver

    Oliver Peters Post Production Services, LLC
    Orlando, FL
    http://www.oliverpeters.com

Page 4 of 9

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy