Can I get FCPX to link to Proxies created by Redcine-X?

[Paul Munger]

Wow, Joe, that was very in-depth and super fascinating! Ok, so now it all makes sense…and means I’m stuck, LOL! Because I’m editing a feature film and I can’t be stuck on final export to Colorist depending on a “proxy cheat” method that may or may NOT work. Alright, well, thank you all for your help.

[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.

[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

[Jeremy Garchow]

[Joe Marler] “(matching file suffix, pixel aspect ratio, audio config and timecode”

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.

I certainly do not know the ins and outs of sql or fcpx’s internal structure. I just do what works. 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. It’s definitely odd.

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

Depending on the drive format chosen on the red (UDF or FAT32) the QuickTime movies don’t follow the same spanned format as the r3ds (or MXF) FAT32 4GB chunks of media). The camera generates proxies don’t seem to have the same metadata as the RCX generated proxies. Somehow, fcpx knows how to relink to the rcx generated proxies and the spanned r3ds but can’t do this with camera generated proxies. Again, I don’t know why this is, or how it works in fcpx, but it seems to work.

This is why, with Ref especially, I use RCX to generate ‘proxies’ before editing and are usually high quality 444 redlogfilm proxies. On quicker jobs, I’ll even send those to grade rather than go through an r3d relink and file transfer.

[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