[Joe Marler]

[Christian Friis] “in the ‘original media’ folder on the hd that I copy to, all I find is ‘alias’ files (movie files with a ‘hook arrow’ showing that these are merely paths to the files). “

After the copy, you must select the destination library, then in Inspector press “Consolidate”.

However the best practice is don’t drag or copy bare clips or projects across libraries but do it inside an event. Sam Mestman discusses this from 06:30 to 11:00 in the below video, but you may want to watch Sam’s whole talk from 02:00 to 11:00. He demonstrates this on a Lumaforge NAS but it also applies to direct attached storage.

https://hazu.io/pixelcorps/fcvug-7

[Joe Marler]

[Mauricio Lleras] “Right, so essentially this would create two sets of files, the Fcpx image proxies and then low res exports.
I was wondering if I could use the fcpx create proxies command to get review dailies with sync sound in just one step…”

Proxies are ProRes 422 so they are about 50-60% the size of H264 originals, even though they are 1/4 the pixel resolution. Depending on clip size and bandwidth, not necessarily easy to distribute. By contrast dailies at 1080p or 720p H264 are much smaller and easier to distribute, plus they can include whatever double system audio you want.

My 2017 iMac can export 60 sec of 720p H264 from a 4k timeline in about 34 sec, so that’s pretty fast. Sizes for 60 sec clip:

4k H264 original: 646 MB
Proxy: 334 MB
1080p/29.97: 150.4 MB, export time: 38 sec
720p/29.97: 90.5 MB, export time: 34 sec

[Joe Marler]

[Mauricio Lleras] “wondered if proxies created after having sync done would retain the audio or if they are necessarily image only..”

Proxies contain the original camera audio but there’s no such thing as “audio proxies” for double system audio. If distributing a proxy-only library, the original audio files must also be included and the recipient must relink them. Same situation with photos or graphics.

However if you are only distributing lower-res dailies for viewing (not editing), this isn’t an issue because those exported files will contain whatever double system sound you chose to export. Typically this would be a mixdown of the the selected “high quality” channels in a stereo track, but it’s also possible to export an MXF with multichannel audio.

[Joe Marler]

[Brett Sherman] “When I drag a clip from another library into the timeline I’m currently working on, the clip shows up on the timeline as black. “

Are these proxies, and was it dragging clips or a project? If you drag/drop a project involving proxies across libraries, and you answer “no” to the proxy question, the clip will be black (in proxy mode), yet the transcode to proxy option is greyed out. In that case the solution is delete all proxies in the event and rebuild them including the black clip.

Regardless of whether proxies are involved, can you try it again and click both proxy and optimized checkboxes for the copy, regardless of whether you have those?

There’s a separate case where symlinks may not work properly if dragging clips between non-managed libraries vs dragging an event. However that doesn’t cause black clips but rather duplicates which are incorrectly linked to the wrong media location. The best practice is don’t drag or copy bare clips or projects across libraries but do it inside an event. Sam Mestman discusses this from 06:30 to 11:00 in the below video, but you may want to watch Sam’s whole talk from 02:00 to 11:00. He demonstrates this on a Lumaforge NAS but it’s not unique to a NAS.

https://hazu.io/pixelcorps/fcvug-7

[Joe Marler]

[Andrew Clark] “** So the OS compresses files that are on an external drive too? I am running the latest Mojave OS 10.14.3 and it uses the new APFS format. Maybe the OS along with APFS cannot communicate well an external drive that is in the exFAT format?!”

I don’t think you should have FCPX system files, FCPX media files or macOS system files on an external exFAT drive. You created a symlink which redirects something in /Library to an external exFAT drive. That might be the problem. In theory the symlink just resolves to a volume+path reference, but we don’t know what kind of filesystem calls Software Update is making on the source file (what the symlink resolves to). You can be fairly certain they didn’t thoroughly test filesystem operations in /Library on an exFAT volume, since that was intended to only exist on an APFS or HFS+ system volume.

If you back up, format the external SSD as APFS or HFS+, then restore your data to it, that might work better.

[Joe Marler]

[Andrew Clark] “When creating a Symbolic Link for the “Final Cut Pro Sound Effects” folder to an external connected SSD, all shows up and works fine in FCPX but… Software Update thinks that this folder no longer exists and wants to update FCPX stating “Final Cut Pro X Supplemental Content 1.0” … and wants me to install it.[]

I don’t know the answer but here is some speculation:

(1) While most file operations work identically against a symlink vs the linked source file/folder, not all do. E.g, if you delete a symlink it only deletes the link not the linked source file/folder. Maybe Software Update is trying to delete that before updating, or use some odd combination of relative and absolute paths which the symlink trips up.

(2) Since the above folder is a system item, they might be doing some attribute check. E.g, the Cocoa file manager framework has a method attributesOfItem(atPath:) which will return different values if executed against a symlink vs the source folder. To make that work against a symlink they’d have to add additional code, which was probably not envisioned. https://developer.apple.com/documentation/foundation/filemanager/1410452-attributesofitem

[Andrew Clark] “…Another thing is the size. When I do a “Get Info” on the folder (located on the external SSD of course), it shows two different sizes. One on the top of the info window stating 463.2MB and the other under the “General” section stating 945.8MB.”

This is likely due to HFS+ file compression. I think starting with Snow Leopard that certain system files are automatically compressed to save space. This is transparent and invisible to normal Finder and terminal operations. However compression can cause top-line vs “general info” returned by Get Info to differ. E.g, if I do Get Info on /Library/Developer, that returns 958.5 MB vs 366.7 MB on disk.

[Joe Marler]

There are many factors involved, I will only list some of them. Maybe others with experience using concurrent collaborative workflows on shared storage could also advise.

For optimum efficiency your editors need to coordinate with each other and use the same procedure — otherwise they will be duplicating work (and possibly clips). This coordination might include consistent, uniform keywording and rating standards. E.g, you don’t want one using the keyword “happy” and another using “laughter” for the same clip type. Likewise one might use “tight” favorites very sparingly, and another use those loosely. Similar with rejects. If they are only working on their own material, this is less an issue but if their individual work is later blended it could cause problems.

Before ingest, if your clip filenames are not globally unique I recommend batch renaming them to add a unique suffix. This avoids lots of problems later on. There are various tools for this but I use “A Better Finder Rename”, and use a two-step rename (1) Add an underscore “_” to the end of the existing filename, then (2) Add a sequence number to the end starting with a user-specified value.

Remember the last sequence number used so if new material comes in you start with the next available sequence number. In the above tool the rename steps Category:Text>Add text to end, and Category:Sequence Numbers>Add sequence number to end.

For proper multi-cam sync, each batch of files from each camera must be labeled in the inspector after import. If you have multiple cameras shooting the same codec and filename format, it can be very difficult to tell what is Cam A vs Cam B on a multicam shoot. For this reason during offload it’s best to place all files from a given camera in a folder named for that camera or camera+operator, e.g, KevinDVX200. Then during import use FCPX preference “Assign keywords from folders” and also from Finder tags (if you use those). Then after import the clips from each camera must be batch labeled before the MC sync. Sam Mestman described the procedure here: https://blog.wemakemovies.org/2012/10/fcpx-batch-renaming-advanced-multicam-sync/

However — after labeling each batch of clips within FCPX and *before* trying to sync the multicams, scrutinize the audio and video clips to see if the time of day seems rational. If the clips from one camera or recorder have inconsistent time of day, that can make finding the clips for a single MC shoot difficult. If you determine that one device was, say, +1 hr off, this can be batch updated by selecting all those clips (which is easy if the above folder naming and ingest procedure is used), then update the TOD to be correct. The procedure was shown in MacBreak Studio #223, from 02:00 to 04:00:

https://www.youtube.com/watch?v=azJ4J41JaZk

For multcam material it’s vital to understand that keywords and ratings should not be done on the parent or constituent clips, but rather on the MC clip itself. Otherwise that work is wasted since the ratings/keywords aren’t inherited by the MC clip. I find it’s usually best to reject all the parent clips after the MC clip is built then run the Event Browser using “hide rejects”. This prevents an editor from accidentally editing a parent clip into a timeline which then must be painstakingly frame-matched to the MC clip.

Re how to coordinate the various pre-edit prep work between multiple editors on the same event, that can be difficult. In general it’s easier if they work in separate FCPX events on logically (not necessarily physically) separate copies of the data. If the data and libraries are on shared storage, I think this can be set up so multiple libraries all point to a single set of media, avoiding physical duplication. It can help if the data can be partitioned by some characteristic, such as date or shooting day. That way each editor works on non-overlapping clips. The work of each editor can then be merged several different ways, e.g, with the utility MergeX: https://www.merge.software

There are various possible pitfalls involving passing data from one editor to the next when using shared storage. An important tip was described by Sam Mestman in the FCPX Virtual User Group #7. See from 02:00 to 11:00 on this video. Without following this procedure it’s easy to create duplicate clip references which cannot easily be removed:

https://hazu.io/pixelcorps/fcvug-7

These are just some suggestions. Multi-editor workflow can be complex and entail unseen issues. Ideally someone like a tech-savvy 1st Asst. Editor should thoroughly test and validate the workflow before putting it in production.

Some contents or functionalities here are not available due to your cookie preferences!

This happens because the functionality/content marked as “Google Youtube” uses cookies that you choosed to keep disabled. In order to view this content or use this functionality, please enable cookies: click here to open your cookie preferences.

[Joe Marler]

[Jeremy Garchow] “Suffix is less important. I can link between MXF and mov or r3d and mov easily as long as the audio is the same. Even frame size doesn’t matter. If the audio channels don’t match, then fcpx simply won’t relink.”

That’s odd, in my tests importing 1080p .mov proxies (as regular media) generated by FCPX from 4k .mp4 files from Sony Alpha cameras, it will not relink to the original 4k files unless I rename the suffix from .mp4 to .mov.

[Jeremy Garchow] “…Fcpx’s proxy relink is way more strict than even the original media link as you mention. It’s location dependent, original relink is not. “

The basic problem is there IS no proxy relink. For original media there is the “magic” relink courtesy of FCPX storing inodes (provided by the HFS+ file system) for each orig. media file. If those are relocated or renamed within the same volume, relink automatically happens and the symlinks are rebuilt with the new location and file name when FCPX starts. However there is no procedural step or menu — it just happens.

I said previously this works for proxies, but I re-tested it and it does not. However the “proxy cheat” trick will usually work — if you delete the proxy symlinks inside the library and copy aliases from the new proxy location via click/drag while holding OPT+CMD to the proxy folder inside the library, the red proxy clips will start working again. Internally FCPX scans those and rebuilds true symlinks to the revised proxy location. However this doesn’t always work for a renamed disk volume.

Path resolution by inode only works within a volume. If the drive name changes, a manual relink is required — even for orig. media files. FCPX only provides that for media files not proxies. Why they don’t provide proxy relink is unknown — especially since the above “proxy cheat” method is essentially doing that. The fact this doesn’t work reliably on a changed drive name could indicate there’s some deficiency in the SQL schema or inode resolution for this case, so maybe they decided not to formally document and support that.

Using aliases instead of true symlinks is also not the problem cause. I also built new symlinks using the Symbolic Linker utility and those behaved just like aliases: https://github.com/nickzman/symboliclinker/releases

[Joe Marler]

Even if this method proves reliable, it still might not work for my doc group. When FCPX generates proxies (whether internal or external) those are rearranged in date-named folders, with the original folder names lost. Yet before ingest our data wrangler puts lots of work into the folder hierarchy, which in turn produces keyword collections upon import. Those keyword collections are vital since they have info on shooting location, camera name, etc. Without camera name info the clips cannot be prepped for multicam sync.

We could change our ingest procedures to not store any info in folder names, only finder tags. If that survives the round trip to proxies and eventual relink to 4k media, that might work.

FindrCat can tag the media files with keyword names; not sure that works with proxies. Without that, proxies distributed as original media would not retain metadata from the original media folders : https://intelligentassistance.com/findrcat.html

[Joe Marler]

[Paul Munger] ” Ok, so now it all makes sense…and means I’m stuck, LOL! “

Jeremy’s method might work but I haven’t thoroughly tested it. In simple testing it seems to work. If you create external proxies with FCPX or any utility like RCX that can produce files with the the right characteristics (matching file suffix, pixel aspect ratio, audio config and timecode), you can then import and edit proxies as regular media, then later relink to the original high res media. The project must also be adjusted from 1080p to 4k.

If your camera-generated proxies won’t relink to the original R3D files, I don’t know why. Maybe Jeremy could advise.

Outside of RED, this could be a useful technique — assuming it proves robust at high stress and diverse conditions. That’s always a possible issue, e.g, the above “proxy cheat” technique *seems* to work, but I’ve tested that extensively and it is not reliable when dealing with several thousand files if the drive volume name has changed.

Outside of the camera-generated proxy case, why would anyone do this? Because normal FCPX proxies cannot be relinked and are unreliable if the drive name has changed. The library can easily get messed up so changing the drive name back doesn’t fix it. The proxies then won’t work even if the symlinks are rebuilt by hand as either aliases or actual symbolic links.

In a large project using “lean” libraries and proxy-only workflow for downstream editors, it could take a week to generate proxies. Those are sent to editors with a note the drive must retain the given name. What if they have two or three of those drives? Then what if they reboot their computer and the drives mount in a different sequence, giving them a different internal ID? The proxies turn red (maybe permanently). They can be sent new proxies but the fault isn’t there — it’s inside the library. Proxy symlinks can be rebuilt manually using various methods but the upstream pointers inside the library SQL tables cannot be rebuilt. Regenerating new FCPX proxies just to refresh the internal pointers could take a week which isn’t practical.

Using FCPX-generated proxies as orig. media would mean you can’t rapidly switch between regular and proxy mode, but at least the “proxies” could be relinked since FCPX thinks it’s regular media. Then when editing is finished that library can be relinked to the orig. 4k media (presumably).

I’ll test this more tomorrow. Thanks to Jeremy for mentioning this.