[Joe Marler]

[Mandy Leonardo] “…I just copied a 200G library from my computer to an external drive. I then moved the original Library from the folder in “movies” on my computer to the trash and emptied it but it didn’t free up space. Any ideas what happened or how I can get that space back?This feels so beyond my scope to figure out. Where/how do I use those commands to figure that out?”

If your 200GB library was managed, IOW media was internal, then Finder would show 200GB occupied by the library bundle. Likewise in Finder doing a CMD+I on that library would show 200GB. Was this your case — was the library itself 200GB at the Finder level?

John mentioned another possibility — if you had external media, the library itself wasn’t that big, so deleting it didn’t clear up much space. In this scenario FCPX might have shown 200GB media space consumed *within* the app. Within FCPX if you clicked on the library then in the Inspector at bottom right examine the media space consumed, that might be 200GB, but the library bundle itself — what you see in Finder — could be quite small. In this case deleting the library bundle wouldn’t save much space, since most of the space is consumed by media files external to the library.

However I assume your library itself was taking 200GB otherwise you wouldn’t notice this at the Finder level. This would imply your media was internal, IOW a managed library.

But if that media was copied from files in a library on the same disk volume, when FCPX copies that into the 2nd library, it will use “hard links” if possible to avoid making duplicate copies of the files. Hard links are different from symbolic links which appear as little arrow-icons in Finder. They look and behave exactly like a file, except they don’t take up more space because the app in conjunction with the HFS+ file system knows only a single physical version of the file is needed.

Consider this scenario: You have a managed library to which you gradually copy files or events from other libraries within FCPX. All those exist on the same disk volume. When you drag/drop a file, project or event between libraries, FCPX invisibly uses hard links and does not actually create duplicate files. However if you examine those newly-enlarged libraries, at the Finder level they will show the extra space. But if you noticed your total space remaining on the volume, it would not decrease. Then if you delete that new library (and empty the trash) where you copied the files, you don’t get any space back because there was never additional space used. Only when the last copy of the files or the last library containing those files is deleted (and the trash emptied) is the space freed up.

This isn’t related to the issue of hard links, but here are some general space-management tools:

OmniDiskSweeper (free, and full-featured): https://www.omnigroup.com/more

Final Cut Library Manager (inexpensive), which allows tracking library space consumption and supports easy and safe deletion of non-essential FCPX files: https://www.arcticwhiteness.com/finalcutlibrarymanager/

[Joe Marler]

The following is the only explanation I can think of. FCPX will when possible use “hard links” for identical files on the same volume. E.g, if you copy a library or within FCPX create a new library and copy the same files there, these will be hard links not duplicate copies of the files. Hard links are a UNIX filesystem feature, as contrasted with soft links or symbolic links which point from the library to external media files. Soft links can be recognized in Finder by the arrow icon, but hard links appear exactly like a real file.

They will appear as separate files both within FCPX and Finder and appear to take the same per-file space, but the overall volume space consumption will not increase — because under the covers there is only one physical copy of the files.

If a library containing the same files as other libraries on the same volume is moved (not copied) to another volume, space will be required on that volume. However on the original volume the “link count” of the contained files will simply be decremented by one, the files will be logically deleted but there were never two physical copies to begin with. Thus it won’t free up space since that space was never occupied.

The only way I know to investigate this is using the terminal commands ls -i which will show whether the same file in two different libraries have the same inode number, and ls -h which shows the link count of each file. If the inode number is the same, there is only one file despite the appearance of two files. If after deleting or moving the library and contained files if the link count decrements by one that indicates there were multiple hard links to the same file.

This can be confusing but it’s an optimization which actually saves space.

[Joe Marler]

[Glenn Payne] “The footage is prores 4444 so under the rendering option I’ll select the 4444 setting and cut the footage as is, with no proxy or created optimized files. Does this sound workable to you guys??

I’m not sure you need 4444 as the project render format. The default is 422LT, which would be considerably faster since the render files are smaller. If needed you can change the render format to 4444 before final export. Maybe others could comment on this.

[Glenn Payne] “…My team was running the mixer’s scratch track into the camera but occasionally they’d lose the feed. The film takes place in a car so the various mics were inside the vehicle with the actors. The camera was outside the car at times…So if we lost audio to the camera or were recording basically no sound on the outside of the car then I won’t be able to auto sync or really even manually sync the audio since the audio inside the car (with the mics) and the audio outside the car (camera audio) won’t match for syncing. The car was super sound proof so I’m not sure if you can even hear the slate clapping when the windows were rolled up. My only idea at the moment is to crank up the audio all the way so I can just barely make out the slate clapping, then visually sync it….”

When you slate, all cameras should be framing the slate. In fact some smart slates have a flashing light to notify distracted camera operators to pay attention. If your cameras all visually captured the slate it’s just a straightforward manual sync.

If they did not, then it’s harder. If your outside cameras had only a single audio source from the recorder, then you may have no camera audio at all. Higher-end cameras often have split audio inputs, so one channel of stereo audio can record wired input, and the other channel nat sound from an on-board mic. In that case there’s a chance it might have weakly recorded the slate. Or maybe pre-roll or post-roll footage captured a car door slamming or other sound/visual to support a sync.

If the clocks of all cameras and recorders were accurately set before shooting, the clip date/time should be accurate within a few seconds. This should at least allow matching clip to clip, which is better than not knowing what clip goes with what take. If the clocks were not set right AND if the cameras did not frame the slate, AND if the outside cameras have no audio whatsoever, then you’re possibly facing a time-consuming situation.

If the shoot was recent and the camera and recorder settings have not been modified since, you can sometimes inspect them and derive the time offset to local time, then update that in FCPX. E.g, if cam 1 is set to 9:45AM but the actual time is 10AM, then in FCPX you just do Modify>”Update clip date and time”, and update all those clips +15 min. Do that for each batch of clips from each device and they’ll at least sort chronologically adjacent in the Event Browser.

Short of using wired or wireless SMPTE timecode, a “cheap” way to avoid such cases is if all cameras support free run timecode and allow manual reset to zero by either button or IR/wireless remote command. This way no matter how many times the cameras are stopped/started, the onboard timecode will stay fairly close since the drift rate is usually fairly slow. Then in post you sync by timecode and touch up any mis-sync by a few frames if needed.

This situation illustrates why all camera operators should ideally monitor audio. If you lose camera audio and nobody notices, and if the camera operators are not framing the slate, then it’s a lot harder. You then have to inspect each angle while listening to the audio and try to match it by observation and listening. It can take a while.

[Joe Marler]

[Glenn Payne] “I’ve used the multi-cam function for other projects, but this one is single cam…

Even for single-cam projects with external audio Sam Mestman recommends building it as multicam:

https://www.fcpworks.com/sync-or-multicam-clips/

[Glenn Payne] …I hear mixed thoughts on proxy versus editing the straight footage. I’m always up for getting new opinions on it. We shot in Prores 444 4k.

If you shot in ProRes 444 4k, you can probably edit that directly without proxies, and without optimized media for multicam. In my testing, if the source media is ProRes 444, FCPX does not create optimized media — even *if* FCPX preferences>Playback>”Create optimized media for multicam clips” is enabled. It’s smart enough to know it’s already optimized. So if all your material is ProRes 444, you should never have seen additional space consumption when creating a multicam clip. But if you want to be sure you can turn off that preference.

[Glenn Payne] “…If it’s possible to use the built-in syncing option in fcpx and not have it create a brand new clip (for storage space purposes) I’d absolutely love that…”

For ProRes 444 it should never create a new clip on disk when creating or syncing a multicam clip. If any clip in the MC is not ProRes it will create disk-based optimized media, but ONLY if the above option is on. It does create a new multicam clip in the event browser but (if the above option is off or if all your media is ProRes) these are simply links to the original media. No new physical file is created on disk.

You can also save space by turning off background rendering, which is in FCPX preferences>playback>Background render. On a contemporary machine you generally don’t need that for most codecs, and certainly not for ProRes.

The main issues for effective synchronization of external audio in FCPX are:

(1) Use multicam not sync clips (even for single camera)

(2) Before creating multicam, ensure all video and audio are labeled properly in the Inspector. The below video is old but the basic principle still applies even on 10.4. If your cameras and recorders do not emit name/angle metadata which FCPX can import, each batch of clips from a camera or recorder must be labeled in the Inspector with a camera name or angle name. Without this the multicam sync will not be reliable.

Batch renaming and multicam sync (10.0.6 but the part about labeling camera name or angle still applies):
https://www.youtube.com/watch?v=viDC5XR35GE

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]

[Glenn Payne] “…For previous projects I’ve used the audio syncing option built into fcpx and I’ve loved it. The problem is that it seems to create a brand new file each time is syncs and with this footage being 4k I don’t have the storage space to duplicate it all while keeping the originals…A friend suggested plural eyes (which I’ve toyed with briefly in the past). Would you guys suggest going that direction…”

FCPX does create optimized media when you create a multicam clip (which takes considerable space if the originals are H264) — but only if this option is selected in FCP preferences>playback. Depending on your machine and whether you’re using proxies, this may not be needed. I personally never use it.

If your material is 4k H264 you’ll normally need proxies for smooth multicam editing. If proxies are available you don’t need optimized media for multicam so you can turn off that option in FCPX preferences. That solves your space problem.

If FCPX audio sync is sufficient, I recommend that over Plural Eyes. Provided you tag the name or angle of each batch of camera or recorder clips in the Inspector metadata, FCPX sync by audio usually works pretty well.

Plural Eyes is more capable from a pure syncing standpoint and can do drift correction on long takes. However it is not optimally designed for FCPX workflow. You must either import and sync everything in Plural Eyes, then export to FCPX, otherwise you can only sync by putting “tracks” of connected clips on the timeline and round tripping to Plural Eyes. You cannot export clips from the Event Browser to Plural Eyes, and you cannot export a non-synced multicam clip from the Event Browser to Plural Eyes.

I think Red Giant could make Plural Eyes more compatible with FCPX workflow but they focus on all the other track-oriented NLEs.

The sync algorithms in Plural Eyes are very sophisticated and it can search through hundreds of files looking for a waveform match. So in difficult cases it can come in handy.

[Joe Marler]

[Soumendra Jena] “…sony a7s2 and gh5…exported file is just 29Mbps bitrate which is very low quality, even though my eyes cannot see the downgrade in quality, but I guess Im still losing quality because it doesnt look very very crisp when I watch my videos on 4K monitors or 4K HDR displays.
“
I edit a lot of 4k H264 documentary material from the A7R2, A7R3 and GH5. It’s my impression the default FCPX 4k H264 30 mbps export is pretty good for most cases. OTOH when I’ve compared ProRes 422 to 30 mbps H264, the ProRes version seems a little better (on my 5k iMac screen) but I haven’t studied it on a large 50+ inch screen.

That said, 30 mbps is a little lower than what Youtube recommends for 4k H264 uploads: https://support.google.com/youtube/answer/1722171?hl=en

As already stated you should take a small piece of the timeline and export it to ProRes 422, then play it back-to-back with the 30 mbps 4k H264 version via computer and HDMI on a large screen — and when viewed at a normal distance.

ProRes is so large it’s probably not feasible to use the entire two hr timeline, but this will show whether the 4k H264 version is visually lower quality.

If there is a significant difference, then you can explore increasing the H264 bit rate via Compressor. If there is not a significant difference (when viewed at normal distance from the screen) then you can be satisfied with the current behavior. If there’s a difference that’s only apparent when viewed two feet from a 50-inch screen, nobody will notice that.

Besides sharpness I also suggest you check difficult encoding cases like moving water, fireworks, camera strobes, etc. Also check single-color gradients like a blue sky or blue underwater ocean scene. There are other aspects to image quality besides sharpness. You can take a screen capture of these and compare the same frame.

[Joe Marler]

To search for keywords across events, create a library-wide smart collection which contains those keyword collections. When positioned at the library level, do CMD+F, then add a filter criteria for keywords, select the keywords you want and save that as a new library smart collection.

[Joe Marler]

[eric Thompson] ” 2 angles sync up and the 3rd angle is on the same timeline in it’s entirety after the first two on the same clip. “

If the camera does not export camera name metadata which FCPX recognizes, you have to name the clips from each camera and audio device in the Inspector metadata before you create the multicam clip. Assuming each camera has audio and is using different filename syntax, the approximate procedure is:

1. Import all clips
2. In Event Browser at top left select List View (it’s the button above the red X at left)
3. In Event Browser, click on clip name to sort by name. All the clips from each camera should be grouped together.
4. Select a group of clips from one camera/recorder (Click on 1st, go to last and Shift-click).
5. In Inspector at upper right, click on Info button. If Inspector pane is not on, turn it on with Window>Show Inspector
6. At bottom of Inspector Pane, click the drop-down box and select “General”. This shows more details.
7. In the Inspector Pane, enter a camera or angle name. When you press Enter it will add that camera/angle name to all the clips you have selected in a single step.
8. Repeat step 4 and 7 for each camera/recorder.
9. In Event Browser, select all clips from all the cameras you added camera name info to.
10. Right-click on the selected group and select “New Multicam Clip”, then set checkbox “use audio for synchronization”

[Joe Marler]

[Michael Gissing] “Phillip prefers to spend time with his cat than watch the Apple render bar.”

That was an *Adobe* Premiere render bar, which Philip described as “painful”. Philip’s machine was a mid-range 2013 6-core D500 Mac Pro. That may have been OK in 2013 for 1080 content, but it’s not OK for large amounts of H264 4k if Premiere is being used, and even FCPX can be sluggish since Xeon doesn’t have Quick Sync acceleration for H264. From his blog it’s obvious he shoots a lot of H264 4k from his drones and smaller cameras, and this is shown in the outtakes from his Master Class.

Ironically despite the vast increase in hardware performance of his 10-core GTX1080Ti Windows machine, it wasn’t that much faster than the 6-core nMP at exporting 4k from the Panasonic EV1 — about 50 sec vs 65 sec. I suspect a 12-core D700 nMP would have been faster.

He uses Neat Video a lot and that’s slow on any machine. His 10-core Windows machine was much faster than the 6-core nMP: 50 sec vs 3.5 min — but he’s comparing a four-year-old mid-range Mac Pro to a fairly high end Windows machine. Neat Video has previously said their algorithm scales poorly across dual GPUs. So in this case Philip was effectively using a single D500 GPU vs a GTX-1080 Ti, which is about 3.5x faster. It would be interesting to see that exact test on a 10-core Vega64 iMac Pro.

But this is a problem largely of Apple’s own making. Yes FCPX is blinding fast, esp on certain workflows and hardware, such as handling H264 on a 2017 top-spec iMac. But even FCPX can struggle on a 12-core D700 nMP if using 4k H264, or if using compute-intensive effects like Neat Video.

For years there’s been a smugness in the FCPX community about how fast and efficient that software is, and if people struggling with Premiere performance issues on Macs would just switch to FCPX, everything would be great.

Well they aren’t going to switch — for perfectly valid reasons they like Premiere — I used it for years myself and still have a CC subscription. Philip Bloom likes Premiere, he’s used to it, and he’s not going to change no matter how much faster or better FCPX is. Rather he’ll just get better hardware, and if Apple doesn’t make that hardware, they lose him as a customer. Philip’s video perfectly described his dilemma and decision process.

What should scare Apple is how easy it is for people like Philip to move to Windows. He spends all his time in Premiere and that UI “surface” dominates the user experience. The underlying OS isn’t that visible to someone editing video 10 hrs a day. They’re smart enough to realize that PC hardware is cheaper, faster and upgradeable while maintaining largely the same experience at the application level.

I think Apple finally realized this and thus we have the iMac Pro and a new “modular” Mac Pro on the way. Had they moved quicker in this area Philip Bloom (and all those he represents) might still be an Apple customers.

There’s a line of reasoning that Apple doesn’t really care about competing in this area because the iPhone revenue dwarfs Mac products. But that’s only as a percentage of total revenue. Mac-related revenue is nonetheless very high. If it was a separate company it would be bigger than Time Warner, Facebook, McDonald’s or Northrop Grumman. Apple’s Mac revenue is not that much smaller than Oracle’s total revenue.

[Joe Marler]

[Cherin Bower] “I am purchasing a new iMac pro…I shoot around 10 TB of 4k and slo mo footage each year…
I had an imac, but I don’t use it because my laptops performed better. Here are its specs:
iMac Retina 5k, 27-inch, Late 2015…3.2 GHz Intel core i5….AMD Radeon R9 M380 2048 MB….1 TB?

…I have over 100 TB of footage I’m dealing with on external drives and about 30 TB of that is 4k to edit. I run final cut pro x with some 3d graphics while compressing/converting footage in compressor or edit ready and copying/transferring large video files or libraries at any given time. I also render and convert in Apple ProRes 422 where I can….

Cherin, using FCPX, a top-spec 2017 iMac 27 could handle this if you used proxy files. I know this because I’m editing a 20 TB documentary on one and have about 300 TB of on-line storage, mostly 4k H264.

The 2017 iMac is about 2x faster than a top-spec 2015 iMac at H264. It generates ProRes proxies from 4k H264 about 2x faster than a 12-core D700 Mac Pro. It might be 3x faster than your 3.2Ghz i5 with R9 M380.

That said, documentaries shot on H264 with a high shooting ratio are technically very challenging. A top-spec 2017 iMac could do this (using proxy) but it can be a struggle and the proxy workflow for external proxies (ie outside the library) is complicated and tricky.

For this class of endeavor, an iMac Pro would definitely give more performance headroom and the possibility of editing native 4k XAVC-L MXF files without transcoding to proxy. I have not tested this, only mentioning the possibility. The limited early reviews indicate that Apple has somehow added hardware acceleration for H264 encode/decode to the Xeon-based iMac Pro. Nobody yet knows how this was done, whether a custom Xeon design or using the special transcode logic on the Vega GPU.

You will often hear people say “just transcode to ProRes”. That may be OK for scripted narratives but for large-scale documentaries with many cameras it doesn’t work. E.g, we can’t put HDMI recorders on our fleet of drones, our 12 GoPros or our motion control cameras. We have several HDMI recorders but IMO they don’t work well in the rough-and-tumble field documentary environment.

This is where an iMac Pro could make a huge difference. If it can smoothly and rapidly edit all your camera-native content, then suddenly you have eliminated all transcoding, and all the associated time and space. It would be a gigantic improvement and simplification of your post production workflow. I don’t know for certain it will do that for your 4k XAVC-L MXF content, but my 2017 iMac is on the borderline of being able to smoothly edit camera native 4k H264 XAVC-S without proxy (single cam, not multicam).

Likewise the 4k H264 video from GoPros and DJI drones is highly compressed and can be difficult to edit. However I suspect an iMac Pro can smoothly edit that without proxies or optimized media — because my 2017 iMac nearly can. So there is a performance threshold, that if obtained, is absolutely transformative when dealing with large amounts of this type of material.

That said, if you edit collaboratively with anyone not having an iMac Pro or want to edit on a laptop, you’ll need to generate proxies for that.

Another issue is compute-intensive effects. E.g, Digital Anarchy Flicker Free can miraculously de-flicker a time lapse or banding caused by fluorescent lights but it’s extremely CPU-intensive and slow to run. Likewise Neat Video. Running plugins like these on 4k material is agonizing but sometimes necessary. This is another area an iMac Pro would help.

I don’t know the optimal iMac Pro config for your case but even a base model would be much faster than anything you have. I’d personally get an 8 or 10-core model with Vega 64 GPU and at least 32GB. For FCPX 32GB is probably enough and according to the latest info Apple and 3rd party service providers can upgrade the iMac Pro memory. That said 64GB and 2TB SSD would give plenty of “elbow room”.

In general I would not suggest transcoding to the 4k video sharing presets of Compressor for later editing. By default that uses only 19 megabit/sec for 4k. Even if using a higher bitrate, you are transcoding one H264 format to another for editing. By contrast if using proxy you are editing a ProRes version of the original camera files — there is no generation loss or lower quality from diminished bit rate.

I know there’s a tendency to browse the camera files using Finder, and some codecs make that very difficult. However another solution is just ingest everything to FCPX and browse it there. If using “leave files in place” this is very fast and takes no additional disk space — provided the machine is fast enough without proxies. The iMac Pro might be that machine.