[Joe Marler]

[Herb Sevush] “A third aspect of speed has to do with how the program helps in organizing the project, what tools does it give you for sorting, labeling and finding clips and information, how flexible to ingest and get to work, how easy to export and finish.”

The importance and benefit of this varies hugely based on project size. E.g, in the previously-mentioned Audi commercial by Thomas Grove Carter, he keyworded and marked favorite and rejected ranges before starting the timeline phase of editing. However he could have probably just used bins without a huge penalty — it was a little project.

By contrast when Ken Burns edited The Civil War, he said “it took more than two years of absolutely solid work, with ten or twelve of us working six days a week, ten hours a day”.

https://archive.org/stream/Documentary_Filmmakers_Speak/Documentary_Filmmakers_Speak_djvu.txt

It was edited on a flatbed Steenbeck editing platform. It was 50,000 ft of 16mm film, which at 24 fps and 36 feet per min equates to 23 hours of material. Obviously part of that time was expended due to film-based linear editing, but part was not having an integrated DAM.

When it was restored they “re-edited” it using Avid but the content was essentially locked, it was mainly a clean-up and restoration job.

https://www.digitalcinemareport.com/article/restoring-ken-burns%E2%80%99-civil-war#.Vl7wn_nntaQ

Had the technology been available in 1988, the editing phase of The Civil War could likely have happened faster than two years. We know this because recent movies with high shooting ratios such as Gone Girl (200:1 ratio, 500 hrs of base material) were edited in much shorter periods — about 10 months in this case. I don’t know what DAM they used on Gone Girl but you can be certain it wasn’t looking through clip bins.

Although described as “DAM Lite”, at least FCP X has significant organizational capability. On larger projects where this is properly leveraged, the overall editing task can proceed much faster. On small projects it makes less difference. Whatever the degree of this contribution on a given project, it is part of “editing speed” since the product has been delivered to the editing team until they are finished.

[Joe Marler]

[Tangier Clarke] “isolates processed clips used for synchronization or muilticams? “

If you enable View>Show Used Media Ranges, then double-click on the multicam clip in the timeline or CTRL-click “open in timeline” on a synchronized or compound clip in the browser, the base clips composing those will have an orange stripe.

You can also create a Smart Collection to only show Used Media. E.g, with a synchronized or compound clip opened in the timeline, then press CMD-F in Event Browser, press the + key, select “Used Media”, then press the “New Library Smart Collection button” and name it.

Then anytime you double-click on a multicam clip in the timeline or CTRL-click on a synchronized or multicam clip in the browser to open in timeline, you can click on your “Used Media” smart collection to suppress all other clips in the browser except those used in those objects.

[Joe Marler]

[Bill Davis] “whether or not a 50% time savings is possible”

It’s interesting most of these discussions center around alleged speed advantages during timeline-oriented editing operations — as if that was all delivering a video product consisted of. Maybe that’s understandable since historically that’s all editing software could do.

With broader capability this evaluation becomes more complex. E.g, what if an FCP X editor needed to do spectral audio correction? If he spends lots of time tweaking with the EQ when a Premiere user can use Audition, does that make FCP X slower? Or is that just saving cost not time because the FCP X guy can buy SoundSoap or Izotope?

OTOH what if you have a big documentary with 50 hrs of material. I have personally seen cases where Premiere editors spent weeks viewing the material before importing, copying favorite clips into folders and making hand-written timecode notes. They are technically not editing since it hasn’t been imported, but it is nonetheless time expended. That task is often performed by the assistant editor, so maybe it should be counted.

With FCP X you could import the whole thing and do the initial pass in skimmer marking range-based favorites, rejects, keywords and even notes. That is a gigantic improvement; I’m tempted to say 10:1 depending on complexity. Or do we just say the Premiere guy can go buy CatDV so it’s only saving cost not time?

In this PBS interview, documentary editor Colin Nusbaum stressed that “a piece of footage… is always more useful when it is categorized and can be found in more ways or places than one”: https://www.pbs.org/pov/blog/news/2014/05/how-to-survive-as-an-assistant-editor/

How broad — functionally — is the scope of the performance comparison, and how does it vary based on project size and complexity?

[Joe Marler]

[Oliver Peters] “With mixed formats and older machines, I find Premiere/FCP7/MC to be waaaaaaay more responsive.”

I am currently testing 4k H264 on Premiere CC and FCP X on a variety of machines. In general FCP X is much more responsive, although it depends how you define that.

Premiere JKL response to user input in a 4k H264 timeline is very sluggish, even on a top-spec 2015 iMac. It’s likewise on a 4Ghz Windows machine, so it’s not the OS. Also the program monitor update rate in fast forward or reverse is very laggy, often several seconds. By contrast JKL response on FCP using identical media and hardware is much faster — by about 10x.

OTOH in Premiere when the playhead starts moving at any FF speed, it moves very consistently and smoothly. They are apparently running that on a separate high-priority thread. Even though the program monitor lags severely, the playhead keeps moving. By contrast FCP X on the same material has a jerky playhead, but the lags are much smaller — 1/2 sec or less vs up to 4-5 sec for Premiere — and the viewer stays in sync with the playhead. That is with Premiere on 1/4 res and FCP X viewer on “performance”. I personally prefer a higher viewer update rate than a smoothly-moving playhead.

In Premiere if you give up on JKL and just drag the playhead it’s somewhat better. The playhead response is very smooth and lag-free and you can hear the audio. However program monitor update is sluggish, with up to 1 sec delays. In FCP X dragging the skimmer across the timeline has much faster updates on the viewer — about 10Hz or 10x faster than Premiere.

Multicam H264 4k is similar but with magnified effects. In general it’s borderline unusable on Premiere and sluggish but usable on FCP X. That is with both on a 4Ghz i7 Skylake CPU with 32GB RAM and 1TB SSD. With FCP there is built-in seamless proxy mode, so it’s easy to just use that, which makes editing 4k lightning fast. With Premiere you’d have to manually transcode before import, copy around files by hand and deal with re-sync issues.

However the general UI responsiveness of Premiere is very good. E.g, I don’t recollect it lagging severely when dragging an effect to the timeline. FCP X can get in states (apparently when running a compute-intensive plugin) where the UI itself becomes quite choppy when dragging an effect to the timeline. It’s as if the UI thread is not decoupled from the background processing, like in the old days of cooperative multitasking.

[Joe Marler]

[Phil Lowe] “…People who have never edited for news don’t understand how critical every second can be. A few seconds can mean the difference between making or missing deadline… Apple never designed FCPX as a news editor…every second wasted trying to find a clip just to find a shot is a second closer to missing a deadline, and in news, every second often matters.”

Here is the largest broadcaster in Detroit using FCP X in their news operations. When doing hands-on evaluation of other options, their editors preferred FCP X due to speed and ease of use. It has been so successful that E.W. Scripps Co. is now rolling out the same workflow to all their stations in the U.S.

One of their field reporters said his tight schedule means he must edit and complete every piece on his MacBook Pro in the truck before sending it back to the station. He said the speed and flexibility of FCP X makes it easier to meet his severe news deadlines. There’s a photo in the below articles of him editing in the truck using FCP X.

I suggest you gives these guys a call; they might be happy to share ideas on using FCP X with another news professional.

https://www.apple.com/final-cut-pro/in-action/scripps/
https://www.tvnewscheck.com/playout/2014/07/wxyz-chooses-apples-final-cut-pro-x/

[Joe Marler]

[Phil Lowe] “I work in text (list) mode. Always have. Always will.”

Ah, I begin to see the problem. If your goal is the fastest possible survey of the material and making selects, I suggest you use the browser’s filmstrip view. It is optimal in that case.

As a test I just re-imported 200GB of a documentary I recently worked on, which was about 20 hr of 1080p material to produce a final 17 min product. With “leave files in place” it took FCP X about 5 min to import. Using filmstrip view I blitzed through the material making selection ranges and marking favorites and rejects. I cannot imagine a faster way to work. You can then append those to a timeline and start adjusting it.

For documentary work I would normally do more extensive keywording but I can understand in a time-critical news gathering situation that may not be possible. However you can accomplish your goal — making a rapid 1st-pass selection to the timeline — by working from the browser in filmstrip mode, marking favorites or just appending ranges straight to the timeline. Whether the material is selected from the browser or from an intermediate timeline, the issue is how do that the fastest possible way. Generally, that way is using the browser in filmstrip mode, not making selects from the browser to an intermediate timeline and then more selects from there to a final timeline.

List view is provided for cases where you need to access clip metadata — say enter notes, rename favorite tags, access keywords, etc. I think you said you don’t have time to keyword anything so you may not need list view.

[Phil Lowe] …check out this link at the 3:08 mark and watch him scroll down and drag, scroll down and drag, and scroll down and drag. This is the workflow I’m trying to avoid by having all the clips on one sequence:”

The editor in that video said: “What I like about the browser in FCP X is you can just whiz through everything. I used to work with one big timeline with all my rushes on it….but with FCP X I don’t have to do that because I can just see everything nicely (in the browser filmstrip mode), and just drag across it.”

He said he’s only been using FCP X for one month, but he has already grasped the right idea.

[Joe Marler]

[Craig Alan] “I was talking to OWC support and the only thing he added to the picture is that all drives within a raid need to be the same firmware. He said the enclosure does not determine what firmware to use but just that the internal drives match.”

Well, you’d think OWC would know, but I asked Lloyd Chambers who wrote this review and has extensive experience in system-level I/O. He said you can mix and match freely in the Thunderbay 4: https://macperformanceguide.com/Reviews-OWC-Thunderbay.html

[Craig Alan] “I assume stripe size is an option when you configure the raid using Promise utility?
If so what stripe size do you recommend?…So unless there is a real reason to create a new raid 5 using a different raid format and copying over from the one with stripe 128K, I’ll leave this as is and consider your suggestion as I reformat the rest of them.”

The main implication of my tests were the R4 was very slow to format using a 128KB stripe size. To a lesser degree this can also effect your I/O efficiency since you ideally want the average I/O size to match the stripe size.

In general a larger stripe size is better for images and video. You can crudely approximate I/O size on a given workload by running those tasks while watching Activity Monitor. In Activity Monitor select “Disk” and divide “Data read/sec” by “Reads in/sec”. E.g, 100 megabytes/sec divided by 100 reads/sec = 1 megabyte I/O size. It fluctuates a lot — you just want a rough number. Ditto for writes, but typically reads predominate so are more important. In general it’s not that critical so I wouldn’t worry about it. Maybe next time you reformat (if ever) use 256KB or 512KB stripe size.

[Joe Marler]

[Phil Lowe] “Every time you have to pull an individual clip into the browser – I don’t care how fast you can “skim” it once there – it’s wasting time.”

Can you explain what you mean here? In FCP X you don’t generally “pull individual clips” into the browser — you import everything — it’s *all* visible in the browser. Then you rapidly skim through it and make range selections.

Do you mean initially examining material external to FCP X, importing individual clips as you find them? That can be done and it formerly was the common practice. However it’s usually not the optimal workflow with FCP X.

That became the common practice when import was expensive due to transcoding and when editing software was slow and had limited ability to scan through material. With FCP X that’s no longer the case.

The best procedure is often to just import *everything* and use “leave files in place” and turn off all the import analysis options. It won’t transcode anything or take up extra space. It is very fast.

I have used all kinds of external tools to scan through video material but IMO the best approach (with FCP X) is just import everything. It avoids redundant evaluation passes, and the skimming ability is faster than any other tool I’ve seen. It doesn’t take up space because it’s not transcoding anything. Once your selects are done you can easily copy only the used material to another library to archive that (if required).

[Joe Marler]

[Phil Lowe] “”200 clips…speed review” them by simply skimming…bring that timeline into the viewer, set an in & out to cut into a different timeline that I’m working on….Who has time to keyword when you’re cutting under heavy deadline pressure”

In FCP X the skimmer and event browser are designed for this (hence the names). It is extremely fast. One way or another you have to examine the material. Why import it to an initial timeline for this? Within the event browser you can skim, set I/O points, mark favorites and rejects.

You don’t have to keyword anything. For your case maybe simply using favorites and rejects is enough. Just make sure you have Skimming and Audio Skimming enabled.

Note: this process is marking *ranges* not clips, and they remain marked in the browser and can be selectively shown by clicking on “Favorites” in the filter drop-down at top left of the browser. In the browser they can be viewed as a list, sorted by various criteria, bulk added to the timeline, etc. Other editing software without this capability may have to edit ranges into an intermediary timeline but that is not needed with FCP X.

While FCP X is designed to work that way, there are two methods of editing into an intermediate timeline then putting that in a final timeline. (1) Make intermediate timeline into a compound clip (which places it into the browser) create final project timeline and add compound clip from browser. (2) As of 10.2 you can edit a timeline and essentially re-inject that into the browser via a Library Smart Collection. Use: File>New Library Smart Collection, then double-click on it and give the filter criteria Used Media. The search scope will be restricted to the current project but span all events in the library. Any edits to that project timeline will be reflected back to that Library Smart Collection and visible in the browser. When finished editing that intermediate timeline, you could then tag those clips in the Library Smart Collection, switch to a final project, query those tags and put them in the final timeline. I’m not recommending that workflow, but you could do it.

You can keep track of what clips you’ve used or not used in the timeline with Used Media Ranges:

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

If you wanted to use keywords this can be done very quickly:

MacBreak Studio “Warp Speed Keywording”: https://www.youtube.com/watch?v=azJ4J41JaZk

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]

[Shawn Miller] “So, Premiere PPro performed roughly the same on both platforms, while FCPX was generally more responsive dealing with 4K H.264. Overall, how responsive would you say a project like that is (in FCPX)… good enough to get by while editing remotely for a day or two, or good enough to carry through a long(ish) project. Say, maybe a month of 8 hour edit sessions? At what point would you make the decision to transcode for better performance? “

FCP X was much more responsive, although to some degree this depends on how you measure it. In Premiere CC once the playhead starts moving it is very smooth, even on 4k. They apparently run that on a separate high-priority thread. However the program monitor can lag by several seconds — even on single-cam 4k and it’s worse on multicam. By contrast on FCP X the playhead is not as smooth — it jerks and lags on H264 4k but the viewer stays in sync and the lag is typically much smaller — 1/2 second or less. Using proxy mode it is totally fluid.

In other areas Premiere’s UI response seems very good. I don’t recollect cases where it just hangs trying to select an option or tab. By contrast FCP X can sometimes get in states where the UI itself seems laggy. E.g, if a compute-intensive plugin is running and you try to drag another effect to the timeline, the drag operation can be choppy. It almost feels like the old days of cooperative multitasking vs preemptive. IMO the UI should be on a separate thread and should never lag because of background processing.

Re suitability of H264 4k on FCP X without proxy, this is a different decision process than Premiere. With FCP X it is totally integrated and seamless, there are no files to move or sync issues. You would typically not hesitate, just select the material within the FCP X browser, pick transcode to proxy, then “flip the switch” in the viewer to proxy mode. It doesn’t take that much space and you never see or manage the files themselves. Before final export, just change the viewer back to original media. I’ve never seen it lose sync or have any problem. This assumes you keep the native media with you. However if you want to copy the proxy files to an old laptop, edit those then copy them back, that’s not as automatic, but still quite simple. This MacBreak Studio reviews the procedure:

https://www.youtube.com/watch?v=UN-ArQnHQTc

With Premiere it requires manual transcoding before import so it’s a bigger decision. There are two sub-options: (1) Transcode to lower-compression 4k (about 8x the file size) and use those for the remainder of the workflow, or (2) Transcode to 1080p proxy. A lot of people do #2 so it’s viable but I personally don’t like the complexity. Tony Northrup describes the process here: https://www.rangefinderonline.com/features/how-to/Getting-Acquainted-with-Offline-Video-Editing-to-Ease-You-Into-4K-8988.shtml

Re how responsive H264 4k is in FCP X, it’s not bad on a higher-end machine but slower than 1080. In general I edit very small single-cam 4k projects without transcoding but since it’s so easy I don’t hesitate to transcode to proxy. It makes things a lot quicker and smoother, especially since effects are only applied to the 1/4 res proxy files until the final render and export.

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.