Creative Communities of the World Forums

The peer to peer support community for media production professionals.

Activity Forums Apple Final Cut Pro Legacy Capturing Issue With a Different Type of Timecode?

  • Capturing Issue With a Different Type of Timecode?

    Posted by Chris Parkhurst on September 12, 2007 at 8:21 pm

    Am trying to log and capture footage via FCP version 6. However, the footaget that I’m capturing doesn’t have the regular time code base. Instead, for this two camera set-up, we used a daytime time code (ie continuous time code based on the actual time of day). Basically, this ensured that both cameras were always reading the same time code (for editing purposes).

    This is the first time I’ve tried to capture this type of time-coded footage and I’m having some issues. FCP doesn’t seem to want to read the in and out points in the usual fashion. Because we were using this type of time code, Final Cut now thinks there are actual gaps between when the camera was activated and when it wasn’t. This wouldn’t be normally interpreted this way if we had been using standard time coding because the time code simply picks up at the exact frame it left off. But because we are using actual time, FCP thinks there are gaps. Throws the whole idea of in and out points. Instead I’ve been having to simply use the Capture Now feature and capture entire tapes, which I’d rather not have to do.

    Does anyone know if there is a setting somewhere that allows me to normally log and capture with this type of time code instead of having to simply capture the entire tape?

    In advance, thanks for your help!

    Mark Raudonis replied 18 years, 9 months ago 4 Members · 7 Replies
  • 7 Replies
  • Mark Raudonis

    September 13, 2007 at 12:01 am

    Welcome to the wonderful world of “Time of Day” timecode.

    What you’re experiencing is normal operations. The deck will abort at a timecode break, create a new clip, navigate across the break (which can take up to three minutes depending on what kind of deck you use), increment the clipname (182A02-2), then continue onto the next break.

    We’ve been using “TOD” code for years. For our workflow, the advantages outweigh the disadvantages. You need to have a very good reason to use “TOD” code. Most people hate it.

    I’ve grown accustomed to the issues involved, so it really doesn’t bother me. However, we do have continual conversations with every new cameraperson about the importance of “preroll” in what they’re shooting. If you need media within 5 seconds of the change of code, you’re screwed.

    By the way… thinking that your multiple cameras will stay in sync through out this who shoot is crazy. Without something like a “lok-it box”, it just ain’t gonna happen. It’ll be close, but not close enough to sync by numbers. You’re still going to have to sync by hand.

    Good luck.

    Mark

  • Chris Parkhurst

    September 13, 2007 at 12:23 am

    Appreciate the candid response, but five seconds pre-roll would have done nothing for me. It’s not at all a pre-roll issue.

  • Chris Parkhurst

    September 13, 2007 at 12:26 am

    Mark,

    Thanks for the thoughtful and intelligent response. While not necessarily a solution to my problem – doesn’t sound like there is one – I at least now understand what we’re dealing with. Very thorough and informative, all that one could hope for in a response! Thanks again, man.

  • Chris Parkhurst

    September 13, 2007 at 12:29 am

    I stand corrected, given the thoughtful response by Mark.

  • Ernie Santella

    September 13, 2007 at 1:10 am

    Could it be a VITC vs. LTC issue? Did you try switching the deck to read the other?

  • Will Macneil

    September 13, 2007 at 9:53 am

    Are you trying to batch capture? If that’s the case, you’ll probably just need to tweak your inpoints. Move them all at least 20 seconds later if you can. And make sure your outpoints actually *exist* on tape. It’s very easy to round an outpoint off to a even number and in the process step past the recorded segment. When the system passes the sequetial code and hits a break, it will simply throw out the clip.

    TOD is a PAIN! A slightly more reliable option is to Jam Sync the cameras or VTRs. This just means one recorder generates its own continuous code and the rest read this and regenerate it to tape.

    W

  • Mark Raudonis

    September 13, 2007 at 1:37 pm

    [Will MacNeil] “A slightly more reliable option is to Jam Sync the cameras or VTRs. This just means one recorder generates its own continuous code and the rest read this and regenerate it to tape.

    Will,

    You’re correct to use the term “slightly more” reliable. Every time there’s a battery change, the code usually goes off anywhere from a few frames to a few seconds. Hardwiring the cameras to a common code generator prevents this, but most people don’t want the cameras “tethered” . Hence the use of the “Lok-it” box.

    Mark

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