[Joe Marler]

[John Irvine] “Last night I removed all effects from my clips on the timeline and then tried burning a DVD file to my hard drive – hooray, it worked! Ah, but not quite: although it completed the process and said ‘Sharing successful’, the resultant video only plays for 40 minutes out of about 100. So it’s useless…”

When troubleshooting an render or encode problem, I suggest not burning a DVD. This introduces additional complexity and time. Focus on getting the export to a disk file working, then (and only then) try burning the DVD. Use whatever the fastest export parameters are for your specific hardware. On an iMac it’s Master File>Computer>H.264 Fast Encode, and the lowest available resolution, 854×480. Even on a Mac Pro (which doesn’t have Quick Sync) this might be faster than ProRes output. Once the problem is resolved you can use your preferred export type.

I have seen cases where corruption in a timeline will halt exporting and the resultant video is truncated. I resolved it by making a copy of the project, then successively deleting part of the timeline to narrow down the problem area. This is obviously easier if the behavior is consistent, IOW it tends to halt at the same place each time.

Close examination of that timeline region showed some anomalous black frames. I deleted the clip from the timeline *and* Event Browser, re-imported it, added it back to the timeline, then the problem was solved. This is a rare case and I’ve only seen it once.

[John Irvine] “…at least part of the problem lies with the effects on the clips. Can I burn the effects to the clips? I guess I would have to take each clip one at a time and export it as a new clip with effects burned in? Wow, that’s a big job and I’d lose all my edits!..”

You can render clips with the effects and re-import them, then you can frame-match the head/tail timecode from the timeline clip to the new clip in the Browser, then draw a range on it and do a 3-point edit to overwrite the old clip. I have done this hundreds of times and it’s not that bad once you get the procedure, but it should not generally be necessary. It is not clear your problems are due to all the effects, so exporting and replacing all those clips is probably not required.

Your initial goal should be examine whether exporting from a test copy of your timeline with no effects to a disk file will halt or truncate the output file. If that happens the whole issue about burning in effects is a non-issue — it’s happening with zero effects.

[John Irvine] “…. it seems that FCPX is not fit for purpose. You create a big project and then it can’t handle it. How very unprofessional, I’d say. Does anyone have any experience of Apple’s Compressor software? Is that a more professional platform for exporting and DVD creation?”

FCPX can handle gigantic projects — I have edited a documentary where the library contained 8,500 4k clips, 220 hours, and 20 terabytes. I’ve tested complex two-hour timelines and both performance and reliability was generally good, at least on my iMac Pro. I sometimes had crashes on my 2017 iMac 27 when doing heavy FCPX color correction but never lost any data or edits. It’s possible that machine had a hardware issue since the call stack would always crash in a GPU function.

When I edited with Premiere I would sometimes have crashes or unexplained render halts also. I’ve never used any NLE software on either Windows or Mac which did not occasionally crash when under high stress.

I suggest deleting all your render files, and also proxy or optimized media if possible. A render or corruption problem can become embedded in those generated files. You can delete only the render/proxy/optimized media from the timeline, not the entire library. Select the project thumbnail in the Browser, then File>Delete Generated Project Files. Once the problem is solved if you need the proxy or optimized files for subsequent editing performance, you can rebuild those.

After deleting all render files and rebooting both macOS and FCPX, you need to first validate whether you can export a test timeline to a *file* (not a DVD) with no effects applied. If that still halts it’s not the effects. If it halts at a certain point such as +40 min into the timeline, zoom way in and inspect that region closely. Make sure there are no visible black frames. Make sure playback works on that region with no skipping, lagging or other anomalies.

If that works and doesn’t show visible problems, draw a range box around the problem region, say 10 min long, then try to export that one problem region.

If that works but exporting the full timeline to a file still halts at the same place, import a new copy of the clip, copy the timeline clip attributes with CMD+C, then match the timecode from the timeline clip to the new copy in the Event Browser and do a 3-point replace edit. You then add the original clip attributes to the new clip via Edit>Paste Attributes and select which ones you want added. The avoids having to manually add them by hand. You can also do a connect edit (Q key) on top of the old clip, then use the V key to disable the original clip to verify the sync. If OK use the P key (Position Mode), and drag down the new connected clip to overwrite the original clip. Then re-try the export.

Note there is a difference between the export truncating the output file randomly vs the same approximate location each time. If it’s the same approximate location that could imply corruption in a generated file for that one clip. If it’s in a random location each time that might be a system problem.

[Joe Marler]

[Christopher Dunning] “when I export an XML of the Multicam from the Browser, I don’t get the info. When I export an XML of the Multicam clip dropped into a Project Timeline, I get SOME of the Keyword Ranges and Notes and Markers, but not all.

Is there any simple way to export the Notes, Keywords, Source In, and Source Out for a series of Keyword Ranges created in a Multicam Clip in the Browser?”

The problem is some of those are stored as event-level attributes, not clip-level. The solution is export the entire event XML and send to the recipient — but that person must use the 3rd-party tool MergeX to combine those with his current event and not overwrite work he has done: https://www.merge.software

I’ve done this as part of a collaborative workflow and it works fairly well. However —

When loading event XMLs, it’s a good idea to previously back up the library at the file level. If something unexpected happens, you can revert to the previous version. Inspect closely the library and event status after loading the merged XML which MergeX produces. Look for things like spurious duplicate clips, duplicate keywords, etc. One you are confident of the workflow, stringent checking is not required.

There is a bug in FCPX XML processing that can create spurious duplicate clips if the original disk filenames were not unique — even if they were kept in separate unique folders. This is especially a problem for Sony Alpha cameras which reset to C00001 with each fresh SD card, and do not allow camera-level control of the video filename. During ingest FCPX is supposed to internally append a unique suffix but it doesn’t always work right when combined with XML processing.

The solution is rename all media filenames to be globally unique before ingest. This can be done with Finder or more powerful tools like A Better Finder Rename: https://www.publicspace.net/ABetterFinderRename/

[Joe Marler]

[Brandon Lanski] “I didn’t realize syncing audio in Final Cut was so easy. “

Normally it works well and you usually don’t need PE. There’s also a conflict between the optimal FCPX workflow and PE. In FCPX you normally ingest, organize things first in the Event Browser, create and sync multicams, etc, and only then add to a timeline.

With PE you must either (1) Put footage on a timeline and round-trip to PE, or (2) Sync in PE and import the XML to FCPX.

#1 is problematic due to various PE limitations: Export from a non-synced or mis-synced multicam clip is not allowed, export from a single timeline with all clips in one lane is not allowed, IOW you can’t just append clips to a timeline to get it into PE. You have to build a timeline by hand with connected clips to get Plural Eyes to accept the XML.

#2 can be problematic on large libraries because even finding the correct clips to sync is more cumbersome at the file level than within FCPX using the skimmer. PE will not allow exporting from the Event Browser. It’s a cross-platform product and other NLEs don’t have an Event Browser.

The core algorithms of PE are very powerful, and it can do continuous correction of sync drift. If someone forgets to set the audio recorder time of day, and if the files are not stored in a folder with the video, PE can search through hundreds of files for a waveform match. However in most cases using FCPX’s sync produces a smoother workflow.

To make the FCPX sync work properly, the clips must be labeled with an angle name or camera name in the Inspector before doing the sync. This isn’t that difficult and the entire batch of clips shot by one camera can be named in a single step. Procedure:

(1) Set Event Browser to List View to better see the clip data. Pick menu View>Browser>Toggle Filmstrip/List View or press OPT+CMD+2.

(1a) If you determine that time of day is incorrect for certain clips since the operator did not set the camera or recorder clock, the clips will not sort adjacent to each other chronologically. This can complicate picking all clips from a given take to sync in a multicam. This can be fixed and adjusted for all clips from that camera. Select the batch of problem clips and Modify>Adjust Content Created Date and Time.

(2) After clip time of day is correct, in the Event Browser, select all clips from a given audio recorder or camera. If the Inspector is not on, use CMD+4 to show it.

(3) In the Inspector, click the “i” button to show information about the clip. This will reveal a “Camera Name” edit box at the bottom.

(4) Enter a Camera Name for that group of clips and press return. This batch labels all selected clips with that camera name.

(5) Repeat for each camera or audio recorder. Note all clips from a given device can be labeled in one step, so this is quick.

(6) Select all clips in the Event Browser you wish to sync

(7) Right-click and select either “New Multicam Clip” or “Synchronize Clips”. Some experienced editors suggest using multicam clips even for single-camera situations: https://www.fcpworks.com/sync-or-multicam-clips/

(8) For either multicam or sync clips make sure the checkbox “use audio for synchronization” is checked.

This will create a new multicam or sync clip which is synchronized using audio. You can double-click the multicam clip and open it in the Angle Editor to verify or adjust the sync. If the sync is not correct you can drag the problem clip left/right or use the comma/period keys for single frame adjustment or left and right angle bracket for 10-frame adjustments.

If you later want to add another camera to an existing multicam, click on down arrow next to the angle name at left of the timeline when in the Angle Editor, and select “Add Angle”, then drag the new clip from the Event Browser to the new lane on the timeline.

If a clip is synced incorrectly you can selectively re-sync that one clip within the multicam. In the Angle Editor, click down arrow next to the angle name for the master audio you wish to sync to, and select “Set Monitoring Angle”. Then select the clip which is synced wrong, and on that lane’s name select the down arrow and pick “Sync Selection to Monitoring Angle”. Only that one clip will be re-synced.

Likewise if you forget to add a clip to the multicam during the initial sync, it’s not necessary to rebuild the multicam. Just drag/drop the additional clip to the proper angle in the Angle Editor, then use the above procedure to sync that one clip within the multicam.

https://support.apple.com/kb/PH12661?locale=en_US&viewlocale=en_US

[Joe Marler]

If that doesn’t fix it, boot into Safe Mode, run Disk Utility First Aid on all volumes, then try the export again: https://support.apple.com/en-us/HT201262

Also, what export options were you using?

Maybe there’s a problem with your render files. Can you delete those file File>Delete Generated Library Files, and select “Render Files”, “All”, and try the export? You need not re-render the timeline before exporting. If by chance you have the Background Render preference enabled, try disabling that before deleting the render files. Sometimes the constant background rendering can cause a problem.

On an iMac, iMac Pro or MacBook Pro, the fastest export is H264 at 1080p (or even lower), done via File>Share>Master File>Settings, and select Format: Computer, Video codec: H264 Faster Encode, and Resolution 1080p (or even less for testing). For troubleshooting purposes you don’t care what output resolution or codec, you just want it done quickly to try different steps.

Mac Pros don’t have Quick Sync or AMD encode acceleration, so H264 encoding will be software only. On those machines I don’t remember which is faster on a fully rendered timeline, H264 at 1080p or ProRes 422. I suppose you could try both.

If that doesn’t work, use Range Mode via the R key, draw a small range on the timeline and export that. It will only export the drawn range. Try to narrow down where in the timeline or how much of the timeline is required to create the problem.

If that doesn’t work, make a duplicate of the project, select the project in the Event Browser and use the command Edit>Remove Effects to remove all effects from the test project. Then delete the current render files and try to export it. This can help determine if it’s an effect problem or a render or encode problem.

If it goes away when effects are removed, make another copy of the original project, and use the Range tool to select part of the timeline and then use Edit>Remove Effects to selectively remove effects from various timeline ranges until you find the problem.

[Joe Marler]

I’ve seen occasional sluggish behavior when loading large libraries due to loading many project snapshots, but I don’t remember seeing it on regular projects. But then I’ve never had 300+ projects in a library.

I’ve also never seen it hang FCPX — the worse I’ve seen is taking one minute to load vs 5 seconds. That was on a library with 8,500 clips, 220 hours, and 20 terabytes, but probably no more than 30-40 projects including snapshots. Hardware was a top-spec 2017 iMac 27 and four-drive 32 TB OWC Thunderbolt array in RAID-0.

If you have any AVCHD material whatsoever which was imported using “leave files in place” instead of re-wrapping, this can cause unpredictable slowdowns due to generating many small random I/Os. I don’t remember it manifesting during project or library loading, but any such material should ideally be removed and re-imported using FCPX re-wrapping or externally re-wrapped with EditReady. Note externally re-wrapped material will have a different filename and characteristics so will not relink. If your film is using six year old material, it may include some AVCHD, so I suggest checking this. Usually the filename suffix is .M2TS, .MTS or .M2T.

The 3rd party utility Library File Manager allows exporting a .XLS spreadsheet with the name of each media file used in a library. This is one way to inspect the location and type of files used: https://www.arcticwhiteness.com/finalcutlibrarymanager/

I’m not saying this is the problem — it just came to mind. I have seen intermittent slow loading behavior on libraries with no AVCHD material but it was never really bad or hung FCPX. There can be some unpredictable referencing and loading of project snapshots, even when the user doesn’t open the snapshot. It might be some kind of pre-loading or project pre-fetch optimization which bogs down library initialization when there are many projects or snapshots.

Make sure you have plenty of spare disk space on the system drive and media drives.

Another step which might help is rebuild all Spotlight indexes on all drives, including the media drives. Apparently FCPX uses these to expedite file access. I’ve seen cases where rebuilding these helps performance when loading a library or scrolling the Event Browser. Procedure: https://support.apple.com/en-us/HT201716

While you’re doing that you may as well run Disk Utility First Aid on all volumes, just to ensure the file system is OK.

A standard FCPX troubleshooting step is reset user preferences, which is described here: https://support.apple.com/en-us/HT203477

You could also delete your render files using the procedure mentioned here: https://support.apple.com/kb/PH12704?locale=en_US

However I’m not sure those are needed when loading the library. Also I think this only deletes generated render files, not other generated files stored in the render folder such as audio peak data and video thumbnails. Those are used during library initialization but I think the only way to delete them is the manual procedure mentioned here. Anything like these steps should be approached very carefully and only after you verify good backups, especially file-level backups of the library file.

https://www.girafxmedia.com/index.php/2016/09/08/fixing-corrupted-final-cut-pro-x-project/

[Joe Marler]

[Dave Smith] “What I have seen is the inability to use a clip from a project in one event… in another project in another event (in the same library) without ‘copying’ the clip to the new event.”

I don’t see that behavior. If clip1 is used in project1 in event1, then you create event2 and inside that project2, you can open project2 and from the Event Browser go back to event1 and drag/drop or use the E key to add clip1 from event1 to project2 in event2. You need not copy the media to event2. This is within the same library. Obviously clips must be duplicated if dragged/dropped between libraries, however even then no more space is consumed if on the same disk volume.

If you previously duplicated clips between events, it’s still not taking up more space. FCPX doesn’t physically duplicate the media at a file level. Even though within FCPX two duplicate clips appear, one in each event, if you look inside the library package there is only one clip in one event. This isn’t an alias or even a hard link, but the behavior is similar to an alias. FCPX gives the illusion of that clip being in two different events and you can use it as if it were there. But it’s not really duplicated at the file level. This illustrates why thinking of events strictly as file-level folders is misleading. For all we know a future version of FCPX could totally eliminate the folder aspect of events (at the file level) and handle it all via a database, yet the appearance and behavior within FCPX would be unchanged.

Even if you drag/drop clips between libraries on the same disk volume, the media files, proxy files or optimized media files are not truly duplicated, courtesy of hard links. They will show as duplicated both in FCPX and at the file level. However each one is actually hard linked to a single copy of the file, so won’t take up any more space. This can be confirmed by going inside the library and using the terminal command ls -i which shows both copies of the files have the same inode — they are actually the same file. Also the reference count of the file (shown by ls -l) increments each time files are copied across libraries within FCPX but no more disk space is consumed, if on the same disk volume.

It is conceivable if you are using an older version of FCPX or your media files are not on HFS+ or APFS, this behavior might be different. In general all FCPX media should be on HFS+ or APFS, not on exFAT or NTFS. I don’t know the behavior if on a NAS.

[Joe Marler]

[Dave Smith] “I started using one Library and creating a new event for each new video…. except now I’m realizing events seem to have the same restriction: In order to use an already-used clip from a previous event I have to copy the footage again into the new event within the same library. So much duplication of 4k footage is going to suck up my 4tb of storage space pretty quick. “

Any media managed by FCPX on the same disk volume, whether inside the library or using external storage, will automatically be hard linked to a single copy of the media. If you copy media within FCPX to another event, that may appear at the Finder level to be another file in another disk folder, but it is actually a single file. It doesn’t take any more space. This can be verified with the terminal commands ls -i to list the file inode and ls -l to list the file reference count. This only applies if the media is on the same disk volume.

[Dave Smith] “…In the situation where I’d be creating 40 or more 5 minute videos potentially sharing many clips, is the recommended approach to have one library, one event, and consider each video a project? Seems like I’ll have to be a keyword organizing wizard in the scenario… but how else to get the job done without duplicating footage over and over?…”

You don’t necessarily need multiple events. Practically speaking, an event is just a tag or label. You click on it and it shows that label’s contents, similar to clicking on a keyword collection. It’s true in the current file-level implementation, an event is a folder with media files inside. However there’s no reason future versions could not change this and still retain the same user-facing event/folder metaphor. Gmail does that already — what you may perceive as a folder in the sidebar is actually just a label. It’s all managed invisibly by a database.

I have used a single event for very large projects, so there is generally not a performance issue.

However you can also have multiple events and combine those in a single project (aka timeline) without duplicating the media to the other events. You can add any clip to any project in any event and FCPX will never complain about copying media across events. That is only the case with multiple libraries.

You can even have one event with all your projects and those can reference clips from other events. Some people do that — have all their projects in one event.

Before FCPX had library-wide smart collections there was a reason to be careful about having your data spread across too many events. In those days you couldn’t search across multiple events using a smart collection. Today you can. You can also effectively have library-wide keyword collections by creating a smart collection at the highest level right under the library, pressing + and adding keywords as search items. E.g, you could have a keyword “cat” in several different events. Within each event if you click the keyword collection “cat” it will only show you the clips or ranges with that keyword within one event. But if you create a library-wide smart collection using the keyword “cat”, that will then show you all clips or ranges with that keyword across all events.

So you can go either way — have a single event and keyword everything or use multiple events and pull clips/ranges for a given project. You don’t need to duplicate media by copying that within FCPX. However the media you have already duplicated is not taking up any more space if it’s on the same disk volume. But it’s not a good idea to have duplicate clips from a management standpoint, even if no more space is used.

Another reason you don’t need duplicate clips is the clips themselves are never edited or changed. The edits are recorded as metadata within the library. You can have multiple timelines in multiple events referencing the same clip in yet another event, and all the edits are stored as metadata, the clip itself is not physically changed. You don’t need a separate copy of the clip for each timeline or project.

[Joe Marler]

[Neil Goodman] “…Davinci notoriously takes significant more juice to run smooth than either of the two apps… I pay no mind to what codec it is…all 3 NLE’s work damn near flawlessly on a 2010 Cheesgrater that I have at work and just as flawless at home on a 2017 peced up Imac….

NLE responsiveness can be very affected by codec and resolution. Using a low-compression all-intraframe codec at 1080p, almost any NLE on any hardware will feel fast.

Unfortunately lots of material today is shot on interframe 4k H264, and that is often difficult to handle. If you have the time to transcode all that to a mezzanine codec or proxies, it works well — on nearly any hardware & NLE, including Premiere. Likewise if you’re dealing with modest amounts of scripted narrative material, then playback performance when scrubbing through that may not be vital. But with high shooting ratios on large-scale field documentary, or news gathering, transcoding everything is not ideal.

Adobe realizes this so their Premiere intro video says: “allows editors to work with 4k and beyond, without time-consuming transcoding…whether it’s a mobile device, action camera, DSLR or almost any other source”, and “never needing to render until your work is complete” : https://helpx.adobe.com/premiere-pro/how-to/what-is-premiere-pro-cc.html?set=premiere-pro–get-started–overview

Unfortunately Premiere does not handle 4k H264 “like mercury”, at least on Macs. The playback engines in Resolve 15 and FCPX are much more responsive on the same hardware.

[Neil Goodman] “….but getting caught in these – my NLE can render this .2 seconds faster than yours stuff is toxic and at the end of the day is really meaningless…”

It’s not about 0.2 sec render time difference. On my top-spec 2017 iMac 27, Premiere’s viewer update rate when fast forwarding 4k H264 (at 1/4 resolution) can degrade to once every five seconds. Both Resolve 15 and FCPX update over 20 times per second, or 100 times faster. This is for various 8-bit 4k H264 material I’ve tested, including from the Panasonic DVX200, GH5, Sony A7RIII and DJI Inspire 2.

[Joe Marler]

[Neil Goodman] “what makes you think Adobe and Avid don’t work well on Macs? Kind of weird since Davinci notoriously takes significant more juice to run smooth than either of the two apps “

I haven’t tested Avid performance recently, but I just tested PP 12.1.2, Resolve 15.1.1 and FCPX 10.4.3 on my 2017 iMac 27. Each codec is a different case, but with 8-bit 4k H264 at 100 mbps, Resolve 15 is much faster than Premiere — especially in timeline responsiveness without proxies. It’s nearly as fast as FCPX. Resolve’s “skimmer” is very responsive, far quicker than Premiere’s “Hover Scrub”.

Premiere at long last is finally using Quick Sync for H264 export, so it’s roughly competitive with FCPX and Resolve on that one task. However Premiere doesn’t use Quick Sync for decoding (only encoding), so timeline operations are very sluggish and laggy. It is so slow when doing JKL commands, it feels like the keyboard is broken.

Blackmagic has recently made tremendous progress in improving Resolve performance. It is shocking how fluid and responsive their “skimmer” is — it feels almost like FCPX.

Even though FCPX is a real speed demon, when exporting 4k H264 to 1080p H264, Resolve 15 is actually twice as fast as FCPX, with both NLEs doing single-pass export at 20 mbps. Examination of the final material and studying the file header with Invisor shows Resolve isn’t taking any short cuts — the material is valid, good quality and plays OK. I don’t know how they are reaching that performance level. On 4k H264 export, Resolve 15 and FCPX are roughly equal on a 2017 iMac, and Premiere is a little slower, but much faster than it used to be.

On all three NLEs IF you create proxies, they all feel fast. However both FCPX and Resolve 15 are fast enough on a 2017 i7 iMac 27 to smoothly edit a single stream of 4k H264 without proxies — Premiere is not.

[Joe Marler]

[Cat Heller] “trying to make a video where 144 small clips play at once…mostly shot on smartphones…resize them to 11% and desaturate them..”

The below article discussed doing this for 64 concurrent videos on a top spec 2013 Mac Pro. You are doing over twice that.

“Building a 64 layer chessboard project in Final Cut Pro X”: https://www.fcp.co/final-cut-pro/articles/1472-building-a-64-layer-chessboard-project-in-final-cut-pro-x

If I understand correctly, you are playing 144 concurrent video streams simultaneously. Is that right? If so that is extremely challenging — on any NLE or any hardware. This would especially be so for H264 which is likely what the smart phones use. Some may even be HEVC which is much more compute-intensive than H264. If any of those are 4k it’s even harder.

It might be best to transcode everything to 1080p ProRes or create proxies for everything (proxies are 1/2 the linear and 1/4 the area resolution), so proxy of 4k is 1080p and proxy of 1080p is 960×540. This is usually adequate resolution for editing and will greatly increase performance.

If you are already using proxies, the only solution might be get a faster machine. You will also likely need a high bandwidth I/O system. Even if all your content is 1080p/30 H264 at the iPhone spec of 130 MB/min, this still equates to 2.2 MB/sec * 144 or 317 MB/sec, with nothing left over for anything else such as cache, library I/O, etc.

Or — if your video tiles are always small and never grow to a larger size, you could possibly use Compressor or Handbrake to transcode those before ingest to a lower resolution, such as 480×270 or smaller. That would decrease the CPU and I/O burden.