TOPIC:

Greetings, I am having problems with Final Cut not correctly syncing footage I have. I am using a camera with timecode. The timecode is working correctly but the timeline is just connecting all the clips together and not putting each clips timecode with the correct timeline timecode location. I

I want the clips to show exactly with the corresponding timecode timeline. How do I make that happen?


Thanks

It's possibly caused by the clips not being labeled as either camera name or angle name. Some cameras automatically store name or angle metadata in each clip, but many do not.

As a standard multicam practice, all A/V and audio clips from a given device should be batch-labeled in a single step for each group. That is done in the Inspector's Info tab. In the Event Browser, select all clips from a given device then enter a camera name.

Serge M demonstrates the procedure in this tutorial. He uses the "Extended" view in Inspector and he assigns both camera name and angle name but that is not always necessary. Usually you can just assign a camera name.

I basically want Final not to automatically connect all the clips together. I want there to be empty space when the camera is not on. For each clips time code to correspond with the timeline time code.

I have also changed the camera angles and camera name.

I don't have audio that matches across the two cameras because I am Motovlogging and there is too much wind.
The DJI Action 3 is recording timecode.
I just want the clips timecode to correctly correspond with Final Cut tineline timecode.

I attached three screenshots.

Thanks

If your cameras and audio recorder were all using timecode and configured correctly and if the clips from each device were labeled in FCP before creating the multicam, they should automatically be spaced on the timeline according to timecode. However, various things could prevent that.

With a multicam clip, there are three different timecode entities:

(1) The timecode of the individual "parent" clips: Those can be seen by skimming the clip in the Event Browser. That timecode came from the camera. If skimming the clip in the Browser does not display the expected timecode, the camera was either not set correctly, or did not support timecode, or FCP could not read the timecode.

A common misconception is if a camera does not have a hardware input for timecode, it does not support timecode. Many cameras support true SMPTE timecode but they don't have TC input or jam sync. Those can sometimes be preset to a specific timecode value via menu, RF or IR remote. Dave Dugdale discusses this procedure on Sony mirrorless cameras:

Unfortunately, timecode support in the MP4 container format is not fully standardized, so some FCP will not read. For those, you can often rewrap them with EditReady before import, after which FCP can read it: hedge.video/editready/benefits

(2) Multicam timecode: The multicam clip itself has a separate timecode which by default is derived from the earliest timecode of the clip inside it. You can override this when the multicam clip is created by picking "Use Custom Settings" and entering a different value (e.g., 00:00:00) in the starting timecode field.

Within the multicam you can skim each clip to see clip timecode unless that is the monitoring angle. In that case, it will instead display the multicam timecode. If you select a different monitoring angle (the little TV icon at the left of each track), you can then skim the clip itself and see the *other* clip timecodes.

(3) Timeline or program timecode: That always starts at 00:00 and goes to the end of the timeline. In the timeline, clip skimming will show the clip timecode of the multicam clip, whereas skimming above the clip will show timeline timecode.

If the cameras and audio recorder all support timecode and if they were properly set, you should be able to skim those in the Event Browser after import and see rational timecode values. In the Inspector, if you uniquely label the clips from each device *before* creating the multicam clip, they should be properly spaced inside the multicam according to timecode -- if all the clips from all the devices support timecode, if the devices were properly set and if FCP can read that timecode.

I just checked a XAVC-SI clip from a Sony A7SIII, and FCP cannot read the timecode from that unless it is rewrapped with EditReady. Resolve Studio 18.1.2 can read it. Premiere Pro formerly could read it, but the current version 23.1.2 seems to show incorrect values. They can all read timecode from the pro formats such as Sony MXF since timecode is more standardized with those.

Another item: if you have cameras such as the DJI Action 3 which has timecode support but FCP will not read clip aka source timecode from the MP4, there is a 3rd-party utility that may be better than EditReady for that task.

It is called QtChange and it's 29.95 Euros or about $32.30 USD. It can read the time of day from the camera file and use that to re-write the clip timecode without re-encoding the clip. In my tests with Sony MP4 files it enables FCP to read clip timecode from those: www.videotoolshed.com/product/qtchange/

That of course assumes the camera time of day was correctly set. If the camera TOD is not set properly you can often batch update those clips after import to FCP. Procedure:

(1) Determine by inspecting the camera clock and comparing to "wall clock" time how far off the camera clock was during shooting.

(2) After those clips are imported to FCP, select them all in the Event Browser and do Modify>Adjust Content Created Date and Time.

(3) Enter the time difference that you previously calculated. It will update the correct creation date/time on all the clips you selected. Do not pick the "Change file creation dates as well", since that does not work due to a permissions issue.

That said, the clip creation date/time shown in FCP is derived from the file date/time on disk but they are stored separately. So fixing an erroneous clip date/time within FCP will not allow QtChange to use the file TOD to fix timecode, since it assumes TOD was correct. There are other utilities which can alter file creation date/time, such as "A Better Finder Attributes": www.publicspace.net/ABetterFinderAttributes/index.html

QtChange does write to the clip, so you might want to make a backup of all media in advance. It has been reliable in my testing but backups are always good.

EditReady is also a good tool and when using the "rewrap" mode it is very fast. The difference is it can enable FCP to read clip timecode -- IF the clip contains correct timecode. By contrast QtChange will create that clip timecode whether it existed on the clip or not. But QtChange must have file date/time to use as a guide.

Another case is if FCP can read clip timecode but it's wrong. E.g, if the jam sync didn't work, or camera timecode was not set properly. If it is off by a certain amount, all clips from the camera will be off the same amount. In that case QtChange can alter the clip timecode plus or minus the amount to correct them. You must deduce that number and enter it in the utility.