FCPX doesn't read timecode from Sony A7S3

WOW! QTchange64 from Videotoolshed is the MUCH better option.. It saved my butt right now!! It just makes TC readable plus you can set File-TC to start from zero if you already f*** up and started editing with those files in FCPx starting from 0. Then any other application will see the 0 timecode as well. NO rewrap is needed as in editready you can perform the switch on the files you are currently editing with (if you want to zero them out, NOT if you want to set them to sony TC for sure).. And best of all: You can revert your changes so ALL Sony Metadata will be readable again. I would always keep backups before and perfom this only on a single copy of my files I am editing with but its great that you dont have to deal with different rewrapped file formats. And its only 30 euros - MUCH less then editready AND you have great support from a guy who really knows what he is talking about. So give him a chance - I dont work for him nor do I earn money by promoting this tool, I am just so glad I found this. Otherwise my documentary I started on with 20 hours of footage would be in REAL trouble.
www.videotoolshed.com/handcrafted-timecode-tools/qtchange/

FinalCutdown wrote:

...Is there any way to zero out the TC of the originals so it is identical in all applications? Moving the XML-Files does not help.

You can zero out the TC or preset TC to any value using the 3rd-party QTChange utility:  www.videotoolshed.com/handcrafted-timecode-tools/qtchange/

You can also zero out or preset TC on clips using EditReady. This can be done via rewrap or passthrough. 

The EditReady menu option for this is Clip>Edit Metadata.

Or you could rewrap the clips with Editready or use QTChange to preprocess the clips before import, and you would avoid many (but not all) of these problems. The default QTChange operation is to read the MP4 source TC (which it can -- even on Sony MP4), then re-write that on the metadata of each clip in Quicktime format so that FCP can read it. That does not rewrap or alter the image data, only affects the clip metadata. Obviously, that should be tested and done with care, but in my tests, it works OK.

But -- even after that's done -- if you export an H264 MP4 from FCP using the Computer>H264 preset, then re-import that MP4, FCP cannot read source TC from its own exported clip; it shows as 00:00. Worse, Resolve also shows it as 00:00. If you export as ProRes, the TC works OK in FCP and in Resolve.

If you export that file using the Video & Audio>H264 preset, then FCP or Resolve can read the TC.

To review, to avoid these problems, preprocess the Sony MP4 files with either EditReady or QTChange before import. Then if you export files for hand off to someone using Resolve or some other utility, use ProRes or the FCP Video & Audio>H264 preset.

If some other combination of round-trip processing happened, and the TC of the returned files no longer matches the TC in the FCP library for those clips, there are two main cases:

(1) Files showed valid non-zero source TC in FCP upon import, but the round-trip returned files show 00:00-based TC, now relink fails. I'd examine the TC in those clips using Resolve, EditReady, QTChange, etc, and verify it is really 00:00, or whether FCP is just *showing* it as 00:00. If there is real TC on the clips, you can process those with EditReady or QTChange and they will probably relink, assuming something else didn't get changed such as audio config.

If those returned files really have 00:00 TC, yet when originally imported to FCP they had valid non-zero TC, that is a harder problem. Provided your original media files have valid TC, you can use QTChange to read the TC from *all* of them, save that, then load all the returned files which lack TC, and tell QTChange to bulk apply the original TC values to the returned files. See QTChange documentation; I have never tested that.

(2) Files showed 00:00 TC in FCP upon original import, but the round-trip returned files show a valid non-zero source TC, so relink fails. You can use EditReady or QTChange to batch rewrite the TC on all clips to start at 00:00, after which it will probably relink.

My team has six A7SIII/FX3 cameras but these are some of the reasons (besides variable ND) that we instead normally use the FX6 cameras. They have true timecode support and the MXF container format handles it well.

You are absolutely right, for me the usual workflow would be:

1. Copy the FX3-cards to 4 hard drives with hedge WITHOUT renaming them - just set your camera to include the date into the filename. Otherwise its harder to read the TC.
2. Use QCchange on ONE drive with the files you want to link in FCPx to make the Sony-TC readable.
3. Just drag the files into your project to link them.
4. If you need gyro-data, use another version of the file from another drive and stabilize in Catalyst browse - export as prores and import again.

In my case I f** up, although you warned me before
So I already edited with those original files in FCPx with 00:00 Timecode detected. (Its the first time I dont use LTC Audio-Timecode and Tentacle sync to convert it to real timecode.. thats why I didnt think about the issue)
Now I will just use QTChange to zero out the timecode.. as long as filenames are unique there should be no problem even on longer projects.

Personally I dont see any advantage using editready - QTchange is quicker, keeps the same filetype, cheaper and can even revert any changes.

FinalCutdown wrote:

...Use QCchange on ONE drive with the files you want to link in FCPx to make the Sony-TC readable...

BTW QTChange formerly did not have the feature to rewrite TC on Sony MP4 clips. In February I had several discussions with the developer and he agreed to add that. I don't have any business or financial relationship with him, but I envisioned this might be needed and he was agreeable to adding it.

I know the developer from other forums.. he knows a lot and reacts quickly..

I just checked QTchange64 with a folder where I automatically renamed the files with hedge during backup plus I hid the xml-files in a different folder. The tool is still able to read the timecode. But still I wouldnt rename while backing up anymore - it was only necessary on my old cameras like the a7 III because they were not able to add the date to the filename.. which could cause massive issues if you have a documentary with five files called c0001 from different card.

joema wrote:

FinalCutdown wrote:

...Is there any way to zero out the TC of the originals so it is identical in all applications? Moving the XML-Files does not help.

But -- even after that's done -- if you export an H264 MP4 from FCP using the Computer>H264 preset, then re-import that MP4, FCP cannot read source TC from its own exported clip; it shows as 00:00. Worse, Resolve also shows it as 00:00. If you export as ProRes, the TC works OK in FCP and in Resolve.

If you export that file using the Video & Audio>H264 preset, then FCP or Resolve can read the TC.

To review, to avoid these problems, preprocess the Sony MP4 files with either EditReady or QTChange before import. Then if you export files for hand off to someone using Resolve or some other utility, use ProRes or the FCP Video & Audio>H264 preset.

Thanks again for those hints.
For me its not an issue as I only work with original clips and I don't retranscode in the workflow - I only export the final file.
I am always using file export and then set the codec so I have more control over audio channel mapping and so on. Plus you only get mxf export through file export.
I think the direct h264 preset is just for a very quick preview or if you are editing for YouTube.

You’ve put your finger on the problem. Apple just doesn’t care. None of the other major NLE has a problem reading timecode from the Sony A7S3, one of the most popular DSLRs out there. It reminds me of the time when FCPX was first released and wasn’t quite ready for prime time yet because of numerous problems like this. If Apple fixed the problem, we wouldn't need any of the workarounds suggested in this thread.

By the way: I managed to zero out the timecode using "QTchange" on my documentary so I can continue working on the project. For some reason the proxies went offline so I had to delete and recreate the. Could be the reason that "change reel name" was activated, I don't really know. But it's a minor issue. Now I hope everything will work out till the end and next time I will us QTchange before starting on the project to finally work with timecode. If anyone notices that a new FCPx version adds TC support, give us an update!

Beware! When I zeroed out the timecode my FCPx created proxies did not connect anymore, I had to recreate some of them... Then after a while FCPx crashed every time I closed the library.. I had to copy all contents to a new library and relink all my files. Now it seems to be stable again. But messing with timecode during the edit is always a risk!