Creative Communities of the World Forums

The peer to peer support community for media production professionals.

Activity Forums Apple Final Cut Pro Legacy 23.98 workflow using 29.97 BWFs. HELP!

  • 23.98 workflow using 29.97 BWFs. HELP!

    Posted by Jeff Berger on August 28, 2008 at 6:33 pm

    Sorry for re-posting this (kinda) but I might be able to articulate our problem a little better now.

    We’re doing an HDCam multi-cam shoot using a fostex 606 recorder for 8 track audio and posting in final cut pro. The cameras are running at 23.98 and the audio is recording at 29.97. Our ideal workflow would be to capture the 23.98 footage at 29.97 (downconverted), import the broadcast wav files produced by the fostex, and then in fcp ‘merge’ them. Once the audio was merged separately to each camera’s footage, we would make multiclips. Then we would copy the media to firewire drives and share them across two additional computers. At the end of it all we’ll output an edl and online in an avid ds. Here are the issues we’ve been having:

    When we first tried to make a merged clip, the audio would be out of sync. Even if we left it as it was and tried to make a mulitclip, the multiclip would create brand new timecode that did not reflect either the video or the audio’s timecode.

    We figured out a solution for that, which was to digitize the footage at 23.98, merge the clips (worked), make multiclips (worked), but when we tried to relink the footage using the same project on another computer the multiclips were not longer in sync. Which we realized meant if we tried to share edits, the footage would be all wonky and not reflect the footage it was supposed to.

    We figured out that the multiclip problem was something inherent to final cut pro 6, and that is has yet to be fixed by apple, so we downgraded all our systems to final cut pro 5 thinking that would solve the problem.

    But then the codec we used that finally worked was not available (the Apple preres codec) in final cut 5, only in 6.

    It’s kind of like we’re in a catch-22 to get this footage to work, merge, multiclip, and be shared on several computers. We’re not sure if the problem lies with the broadcast wav files, final cut pro, or something in our workflow. The few workarounds we’ve found are to multiclip the 2 video and audio, which means as we pull clips we have to re-pull the 8 track audio and manually sync it in the cut (it doesn’t multiclip exactly in sync), but that slows down our editing Any help or direction would be greatly appreciated.

    thanks

    jeff

    Jon Frost replied 14 years, 3 months ago 3 Members · 5 Replies
  • 5 Replies
  • Steven Gonzales

    August 29, 2008 at 2:05 am

    What are all the specs on your audio? Audio doesn’t really use a frame rate such as 29.97. Audio rate is determined by sample rate and clock source. Audio can also have timecode, and that timecode can be set to 29.97, and sometimes that timecode information can be used by devices to alter the sample rate.

    What is the sample rate of the audio (usually 48,000 or 44,100)? How many bits is the audio (usually 16 bit or 24 bit)?

    Was there any device during the shoot that was giving the same clock to the video cameras and the sound recorder to keep them in sync?

    When you merge the clips and they are out of sync, does the audio drift until it is early in relation to image, or does it drift until it is late in relation to the image?

    My first guess is that the sequence you are using to sync is set to a different sample rate for audio than the audio clips, they are thus being played out too quickly or too slowly.

  • Jeff Berger

    August 29, 2008 at 10:52 pm

    The audio is at 48k 24 bits. The Fostex and the cameras were synced using lock-it boxes on set. The sync isn’t that there is any drift, it’s just that the audio, when merged is 4-7 frames before the video. It maintains that offeset throughout the new clip. The timecode given at the clap for both clips is identical though, so I’m not sure why it won’t sync up better.

    jeff

  • Steven Gonzales

    August 30, 2008 at 1:21 pm

    Are you creating your merge clips based on timecode? Perhaps there is some offset during the capture of the video, so that the timecode mapped to each frame of video in Final Cut is actual advanced by 4 to 7 frames (don’t know why it would vary).

    So the frame labeled 01:00:00:05 of video is actually frame 01:00:00:01 because there is some delay between the frame FCP thinks it is getting, and the video frame actually being delivered.

    When you sync this frame with frame 01:00:00:05 of video, there is a match between final cut timecode label and the sound timecode label, but the actual video frames are wrong.

    I’ve had issues like this in the past, which I would troubleshoot by taking video from the monitor output of the deck, and turning on the timecode display of the deck. Then after capture I would compare the timecode tagged to the file with the timecode displayed to see if they were the same.

  • Steven Gonzales

    August 30, 2008 at 1:31 pm

    Another thought, is it could be something with the 24 frame timecode and 30 frame timecode.

    While you were recorded in sync between video and audio, the video camera was recording 24 frame timecode and the audio recorder was recording 30 frame timecode.

    When you were just about to click to the next second, the audio was on frame number :23, about to go to 00 and add another second.

    The video was on frame :29, about to go to another second.

    So if during syncing, these frames were set to match, then you would get frame :23 from audio, but it might match to frame :23 of video, which is 4 frames earlier.

    I haven’t captured from this type of video deck or seen how it downconverts, but perhaps the problem is in this area.

  • Jon Frost

    February 8, 2012 at 10:10 pm

    You could re-record your BWFs in Nuendo at 23.98 frame rate to a new file… and not lose any quality. Make sure you are recording @ 48K – 24-Bit resolution or whatever resolution you originally recorded your audio at.

    Jon Frost

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