[Joe Marler]

[Brandon Lanski] “Why would it behave this way and if i really wanted my waveforms back, does anyone know what I can do?”

You need to relink your media using this procedure: https://support.apple.com/kb/PH12701?locale=en_US

Just answering the prompt about media location is not sufficient if the folder names or folder structure is different.

If it’s not relinked you can get cases where some files are present and others are red (missing). This often happens with audio files. E.g, if you have proxies the video will still show up in proxy mode (even with missing or restructured media folders), but there’s no such thing as audio proxies so they will be red.

If the audio played but clips were red that might be an issue with waveform generation, or the waveform cache doesn’t match the replaced audio files. Again the solution is relink everything.

[Joe Marler]

[Jeremy Garchow] “But at that point in time, if you listen to camera A and camera A’s audio, is the audio in sync with the video? Or is the audio out of sync on the camera recording (not the console recording).”

This is a good question. If (by chance) Cam A video and Cam A audio are ever out of sync, this implies something unusual.

However I think his problem is the one discussed in this frame.io article. Note Brandon is trying to sync 24 fps and 23.98 fps material with external sound recorded at an unknown frame rate.

“When using an external sound recorder, it too must have 23.98fps as an available choice, or there will be drift between the sound and picture…Whatever you do, be consistent. Don’t mix footage with different frame rates..”

https://blog.frame.io/2017/07/17/timecode-and-frame-rates/

Of course audio doesn’t have a real frame rate — it’s recorded in samples. But it does have metadata which may contain a frame rate, and which various software can interpret differently, especially when conforming differing frame rates. This is the point Tangier was making in his earlier post.

Brandon might be able to laboriously work around the problem, but the underlying issue should ideally be investigated and resolved. A better workaround might be to use WaveAgent to modify the file metadata then re-import. To know what file to change, first use WaveAgent to examine all the files and write down which is the oddball group. If they are all 24 fps except for the one 23.98 fps camera, maybe try to change that one’s metadata to 24 fps. But I really don’t know — this could require trial and error. If that doesn’t work, some files might require resampling or even re-encoding.

Besides this issue, Jeremy’s statement is correct that long term sync (over hours) is not assured unless you have common timecode. The quartz oscillators in regular cameras are like a cheap wristwatch. They are pretty good but can drift over several hours. So Brandon may have two different issues — a more rapid drift problem caused by the 23.98/24 conform, and a slower drift problem caused by a camera timebase.

[Joe Marler]

[Roger Sherman] “Is there a way to do the reverse: Go to the clip in an event and reveal in timeline?”

You can create a smart collection for used media, which by default is restricted to the current project. Then you can immediately see if that clip was used in the timeline, then use that clip name in the timeline index and jump to the clip.

You can also turn on viewing used media ranges (View>Browser>Used Media Ranges), but this isn’t necessary for the above to work.

[Joe Marler]

Sorry to hear about these problems, normally FCPX works very reliably, even on huge projects.

I understand you’re on FCPX 10.3.1 and High Sierra 10.13.6. What are your machine specs? Just a standard question — even an underpowered machine shouldn’t cause this.

Also where is your media, and on what type of hard drives?

Is there any chance you don’t have sufficient free space on either your system drive or media drive? Being almost out of space can cause FCPX to act erratically. Ideally you want at least 20% free space. BTW all your media should be on HFS formatted drives, not on exFAT or anything else.

What type of media (inc’l resolution) and codec are you using? If you’re not sure, what camera did it come from? Is any of it AVCHD? Sometimes if AVCHD clips are copied out of the package and imported with “leave files in place” that can cause erratic slowdowns.

What is the history of the problem onset? Did it happen suddenly after some change, or gradually? If it happened suddenly what was the change?

Here are some other troubleshooting steps:

– Make sure everything is backed up

– Make sure you have installed the latest Apple Pro Video Formats: https://support.apple.com/kb/dl1947?locale=en_US

– FCPX automatically creates periodic library backups which are in /Movies/Final Cut Backups. Use Finder to copy those to a safe place, just in case they are needed later. These don’t include media or cache so they are pretty small.

– In FCPX delete all render files and proxies, then restart FCPX and observe the behavior. It it’s still a problem don’t recreate the proxies while you are still troubleshooting. It just takes more time and there’s a deeper issue.

– Some compute-intensive plugins can cause erratic behavior, especially if the plugin version conflicts with the FCPX version. I suggest making a snapshot duplicate of your current project (right-click, pick “create snapshot”), then open that and delete all effects from that test project. Method: select the project in the Event Browser and use the command Edit>Remove Effects to remove all effects from the test project. See if the behavior is any better on the test project with no effects.

– Run Apple Diagnostics on your hardware. This is not guaranteed to find all problems and a clean pass doesn’t mean everything’s OK, but it’s easy to run. If it finds something there’s definitely a hardware problem: https://support.apple.com/en-us/HT202731

– Run Disk Utility First Aid on all volumes, including the system volume. https://support.apple.com/guide/disk-utility/dskutl1040/16.0/mac/10.13

– If the above tests are OK, drop and rebuild all Spotlight indexes. FCPX uses these to rapidly locate files. Normally this won’t cause the problems you are seeing but it’s easy to do and eliminates one thing: https://support.apple.com/en-us/HT201716

– Run Blackmagic Disk Test on each drive, including both system and external. Tell us what the performance of each one is. Normally even a slow disk won’t cause this behavior, but if you get an abnormally slow number (say 20 MB/sec) for some unknown reason, that could cause problems: https://itunes.apple.com/us/app/blackmagic-disk-speed-test/id425264550?mt=12

[Joe Marler]

I agree with what Joby said. If Odille has the original media and the original library, just delete the current proxies and generate new ones.

If the library was also lost during the drive crash, what is he using now? A file-level backup of the library, or was the library in /Movies on the system drive and is OK? There are also auto-saved backup libraries which FCPX puts by default in /Movies/Final Cut Backups.

The #1 goal is verify and relink the original media and verify any projects are still valid. Proxies are merely generated files — whether they are good or damaged in some way, they can be regenerated.

If the original library or a “good enough” backup of it is available, and if they show red (missing) clips due to the media file locations being different — that’s with the viewer in “original media” mode, not proxy mode — you can relink to media files which are in a different folder structure. Note: this is relinking to the original media files, not necessarily to the proxies. FCPX will search all files on an entire disk volume to achieve this. Procedure: https://support.apple.com/kb/PH12701?locale=en_US

After a successful relink to the original files and verifying the projects are OK, then drop all proxies and recreate them.

If the original library exists and internal proxies were used, they will normally be present before the media relink if the viewer is in proxy mode. I don’t know why his proxies look funny, but the best procedure is probably relink the original files, drop and recreate the proxies.

To be doubly cautious it’s often good to make a file-level backup of the library before doing anything else. That ensures you can at least revert back to the previous state.

It might also be good to sequester any existing FCPX library backups, which are by default stored in /Movies/Final Cut Backups. These contain only the edit commands, not proxies, media, or cache. In case something is wrong with his current library, saving these will ensure they are later available for troubleshooting.

[Joe Marler]

There are several types of proxies, and I can’t tell which you are using without more information.

There are camera-generated proxies. Normally FCPX cannot use camera-generated proxies.

There are some hacks to produce externally-generated proxies via various transcoding tools, but I’m not sure of the relink behavior in those cases: https://www.fcp.co/final-cut-pro/tutorials/2124-streamlining-cloud-proxy-workflow-in-final-cut-pro-x

There are FCPX-generated internal proxies which are stored inside the library.

There are FCPX-generated external proxies which are stored outside the library. This procedure is described in Ripple Training’s FCPX 10.4 Media Management tutorial: https://www.rippletraining.com/products/final-cut-pro/media-management-in-final-cut-pro-10-4/

It sounds like maybe you’re using external FCPX-created proxies, ie outside the library? The library embeds the original disk volume name when they were created. In my experience relinking to external proxies is unreliable. The trick of re-creating the existing proxies which kicks off an invisible proxy relink doesn’t always work either.

In that case The shortest workaround is rename your disk volume to the original volume name when the proxies were created. You can do that by doing “Get Info” on the drive and changing the name. For internal proxies relink seems more reliable, but you could also try this method for that situation.

However if you’ve already unsuccessfully tried other relink steps, this might not work. Before trying steps like relinking, loading XMLs, it’s often best to make a file-level backup of the library. That way you can revert to the original state if it doesn’t work.

As long as your original media is OK and you can relink to that, you can just drop any existing proxies using File>Delete Generated Library Files, select “proxy”. Then you can select all the clips in the Event Browser, right-click, select “Transcode” and regenerate new proxies.

[Joe Marler]

His timelines show zero multicam. I have edited small amounts of single-camera 4k H264 on my 2013 top-spec MacBook Air, without proxies. It is probably assisted by the low screen resolution. The previous MBA was 1440×900, vs the 2018 model at 2560 x 1600, roughly 3x the pixels, and the same as his 2016 13″ MBP.

For more substantial amounts of multicam 4k H264, I don’t even like using my top-spec 2016 MacBook Pro. From his prior videos it appears he has a 2016 top-spec 13″ MBP.

He said he used “better performance”, which means he wasn’t using proxies or optimized media.

It appears starting with Kaby Lake, either Quick Sync or how FCPX uses it was greatly improved. My 2017 i7 iMac is about 2x faster on scrubbing and exporting 4k H264 than my otherwise identical 2015 i7 iMac. I’ve always wanted to do an H264 FCPX performance test on the Skylake 2016 vs Kaby Lake 2017 MBP to see if there’s a similar improvement, but never have. According to AnnandTech, the Kaby Lake Quick Sync AVC (meaning H264) encoding performance received a boost over Skylake: https://www.anandtech.com/show/10610/intel-announces-7th-gen-kaby-lake-14nm-plus-six-notebook-skus-desktop-coming-in-january/3

I’d expect this to help the 2018 MBA compensate for its slower clock rate, at least when decoding/encoding H264.

Of course this only helps if both application and system software layers support this. Premiere (even 2019) apparently does not use Quick Sync for decoding, only encoding. FCPX and Resolve also use it for decoding which may explain why timeline and other scrubbing operations are so fast on those vs. Premiere. The implication is (apart from exporting) I’d be hesitant to expect his good FCPX results on the 2018 MBA if you are using Premiere.

It’s interesting his export test was about 2x faster on his 2016 dual-core 13″ MBP. His MBP is a 3.3Ghz i7 model with 16GB RAM, which had integrated IRIS graphics 550. The IRIS graphics units don’t have any VRAM but allocate up to 1.5GB of system RAM. The higher-end IRIS units have an “eDRAM cache” to minimize contention for system RAM. His 2018 MBA gas a 1.6Ghz dual-core i5 with integrated Intel UHD graphics 617, which has no eDRAM cache.

Since he’s comparing two dual-core laptops, maybe the higher clock rate alone helps explain the approx. 2x better encode time on the 2016 13″ MBP. His timeline showed no render dots so it appeared both were fully rendered before export. If it was fully rendered (meaning no effects to compute), it should mostly be an encode test. I’m actually surprised the MBA wasn’t closer to the 2016 MBP on that one test.

I wonder how much more popular the 2018 MBA would be if it had an SD card slot?

[Joe Marler]

[Brandon Lanski] “Did my audio sync in Plural Eyes. Everything checked out but when I brought my XML to fcpx everything was slightly out of sync, same with Davinci. Premiere oddly enough opened it fine. “

If possible, I’d suggest not using PE but just FCPX. From a workflow standpoint there are several advantages to this. See procedure I outlined in this post:

https://forums.creativecow.net/thread/344/52517#52614

PE can correct sync drift but this is designed for “natural” sync drift from a poor crystal timebase on one recorder. It’s not designed to fix a metadata problem, which you may have. The fact that Premiere doesn’t show the problem yet both Resolve and FCPX do indicates it’s probably not hardware-based drift. Each NLE is interpreting some metadata differently. This doesn’t necessarily mean Premiere is doing it “right” and the other NLEs “wrong”, it could be a grey area in how metadata is interpreted in certain edge cases.

Tangier’s linked post is a good example of this — I suggest reading that closely. You could download the free Wave Agent app and examine your problem files. You said only one camera was drifting. What does Wave Agent show for that file vs your other A/V and audio files?

I suggest making a backup copy of your files, make a test library in FCPX, then import the simplest test case which reproduces the problem if synced in FCPX — say one camera and the polyphonic .wav file. Then examine those in Wave Agent.

If all audio sources are at 48Khz or 96Khz sample rates, there’s usually no problem. If one is at 44.1Khz, that might cause sync drift. I think in that case the 44.1Khz source must be re-sampled, not just change the metadata.

However in Tangier’s case he just changed the metadata sample rate to 48.048Khz and that fixed it.

Doing these tests will involve trial and error, but you really need to figure out the ultimate cause, not just try and work around it by stretching timelines.

Note: On High Sierra, the Wave Agent .dmg may not install, so you might need to locate the resultant .mpkg file, then right click, select “Open”, and answer the security prompt.

[Joe Marler]

The slow loading problem caused by many project snapshots is mentioned in this recent article. They state some libraries took 15 minutes to load. This was on an Xsan, so that may have been part of the problem.

https://www.fcp.co/final-cut-pro/articles/2121-refuge-in-the-heartland-a-case-study-in-shared-workflow-with-student-editors

The short-term solution was “created a clean library for the final timelines”. Longer term maybe they will migrate to a higher-performance NAS like LumaForge.

If your media is all on two locally attached Lacie D2 Thunderbolt drives, the performance might be OK but ultimately those are “merely” single-spindle 7200 rpm drives. You have a very substantial library and loading many projects during library initialization takes lots of I/O, at least as FCPX is currently designed.

I suspect there is further optimization possible in future versions of FCPX — I don’t see why it’s pre-loading so many project snapshots rather than load them on demand. I’ve seen it also do likewise for regular projects, but in my case (and the above-referenced case) it was snapshots. However until that is improved the solution is probably limit total number of snapshots, projects, improve I/O or copy the projects to another library.

In FCPX any project can reference any media within the library, so in theory you could copy your projects to another event. That doesn’t copy any media. I don’t know if it would speed up library loading, but you could try it.

Another possibility is copying some of the projects to another library, which will also copy associated media. However due to hard link optimization, if they (and associated media) are copied within FCPX to another library on the same drive volume, it won’t take up any more space.

[Joe Marler]

[John Irvine] “Regarding Compressor – is it worth having? I would need to upgrade my OSX to the latest version (not a bad idea) and spend £50, but is it a more reliable platform for exporting and does it do DVD authoring?”

Compressor gives very flexible export options. It’s very inexpensive. It can be used for time lapse generation: it can import a still image sequence and transcode to a 4k or native-resolution ProRes file that FCPX can then edit efficiently. Procedure linked below in MacBreak Studio #353.

If you are not already on High Sierra 10.13.6 and FCPX 10.4.3, those would be good first steps in troubleshooting your “unable to share” problem. You can spend lots of time debugging some odd behavior only to have it fixed by running the latest app and OS versions. However I would not at this point suggest Mojave until FCPX is updated.

Re export to DVD, I haven’t burned a DVD in three years so I’m not familiar with the current software. This Larry Jordan article says Compressor can do it, but the best Apple authoring app was DVD Studio Pro which is long unavailable and compatibility with the latest (much less future) macOS unknown: https://larryjordan.com/articles/optimize-compressor-4-3-to-burn-dvds/

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

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.