Offline / Online Workflow for 4K Sony FS7 II footage

lizjperl wrote: haha yes I have space for proxies! just not the "rewrap" copies But you're saying once FCP rewraps into its own "original media" I can delete that? If I want to relink to the 4k in FCP how would I do that without the original media? ....

I am personally afraid of relinking to anything other than the media which existed when the proxies were built. IOW don't try deleting rewrapped media then relinking to the camera-native files.

There are two scenarios: (1) Relink fails to original media (really bad), but very rare. In general FCPX proxy relink to original media is very reliable. (2) More common cases where the proxies themselves become invalidated, unlinked, or duplicate clips appear. IOW relink from the library to the proxies themselves fails. If you can afford to discard the proxies, relink to the original media, then rebuild the proxies, it's not so bad. But if dealing with multi-terabyte media, the proxy rebuild can take days. I'm still investigating the bounds of this issue.

In general I recommend building the proxies within FCPX. You can't share proxies with Resolve, so if Resolve needs proxies it must build its own. Maybe people who round-trip between FCPX and Resolve could comment whether they've used proxies on either/both side and how that worked.

Re how to handle the need to rewrap tree-oriented media (XAVC-L in your case), there is no single good answer. With AVCHD I re-wrap with EditReady. With XAVC-S I just copy the video files to a folder and import in place. If we get an XAVC-L camera, I'll have to decide whether to rewrap internally, externally, or copy the files outside the tree and import in place.

In general I prefer minimal folder-level organization before import since FCPX has such capable metadata tools. But however minimal the folder organization is, if you don't import "in place", those folders are changed upon FCPX import and rewrap. The media is essentially placed in a single-level series of date-named folders. IOW your familiar folder tree no longer looks that way after import and rewrap.

Furthermore since FCPX does not try to reproduce the folder tree on import (as Lightroom does), it will sometimes append a "uniquifier" suffix to duplicate file names. This is another common issue with Sony cameras that do not allow user-customizable filename presets, and which revert to C0001 for each new card.

Ideally camera filenames should be unique but if the camera doesn't support this renaming them before import might be desirable. However with some Sony formats, file-specific metadata is embedded within the XML and BIM files so a proper rename requires Sony's Catalyst Prepare software, which is now only available by subscription.

These are yet more reasons why many people just give up and only save the video files themselves. It is not the best practice but considering how FCPX, Sony cameras and Sony Catalyst Prepare software works, it can be the most expedient solution.

About dragging files from the finder or using the import window, there is one very important thing to keep in mind that we found out a couple of weeks ago.

This is the same file from the same location.


If you drag and drop, the timecode will be: 00:00:00:00.
If you use the import window and copy the files to the Library, the timecode will be: 02:44:53:16.

DaVinci Resolve will read the 02:44:53:16 timecode from the original files when you import the files to it, so if you import your files to FCPX with "drag-n-drop", DaVinci won't be able to relink the files because the timecode will be different.

Coming back from the future here.

There may be a few more users of FS7 II's etc now that more and more are coming onto the 2nd hand market.

I have use the "Create Camera Archive" feature and imported from there. Are there any downsides to that?

And also (new FS7 II user here!) is there any way to import the acquisition metadata, such as Aperture, EI, shutter speed etc? Catalyst Browse can see it.

My team has several FX6s but we don't use the FCP camera archive feature. Rather our DIT offloads the cards using Hedge, makes on-site redundant copies, then we import the MXF to FCP using "leave files in place" for dailies.

Yes there are cases where you'd like to preserve the original camera metadata. However much of that is  unfortunately non-standardized, hence the use of vendor-specific proprietary tools such as Catalyst Browse. In some cases you can rewrap or transcode the MXF material using EditReady and it will put some of that in the Quicktime file header. However the ability of each NLE to interpret and present that varies. The rewrapped or transcoded files themselves can examined with tools like MediaInfo and Invisor which shows some of that info, but it won't show (for example) SLog3 as the original gamma profile.

MediaInfo:  apps.apple.com/us/app/mediainfo/id510620098?mt=12
Invisor:  apps.apple.com/us/app/invisor-media-file...or/id442947586?mt=12

This is not unique to Sony cameras. E.g, while R3D from RED Cinema cameras has extensive metadata that can be viewed in FCP or Resolve, if using internal ProRes recording, much less of that metadata can be interpreted by the NLE.

The metadata in the *original* camera files can be interpreted because RED wrote the workflow package you install on FCP and that package understands their R3D format. Likewise with BRAW files read by Resolve. They made the codec and the NLE so they can interpret all the metadata.

However when you record ProRes internally on a RED or Blackmagic camera, they write a lot of stuff to the file header but FCP or Resolve cannot interpret or present it. That metadata can be viewed with MediaInfo or Invisor but there is apparently no EXIF-like broad standardization to allow NLEs to access that. The previously-mentioned utilities mostly do that through reverse engineering.

It is similar with ProRes material that is externally recorded on an Atomos device. Our FX6 cameras produce the same quality using the internal 10-bit 4:2:2 XAVC-I codec as externally recorded ProRes 422, so I prefer the MXF file which has richer metadata. However that doesn't fit into a large post production workflow as well so we sometimes record ProRes 422 externally for that or use dual internal/external recording.