[Joe Marler]

[Noam Osband] ” if I’m getting this to be able to work on the road – again, not as my main squeeze – should I care if it’s 5400 or 7200 rpm?”

Personally I’d always get the 7200 rpm drive. The only two single-platter drives that I’m aware of are the 1TB HGST Touro S (USB 3.0) and the 1TB G-Tech G-Drive Mobile with Thunderbolt: https://www.g-technology.com/products/g-drive-mobile-thunderbolt-1-tb-portable-hard-drive.

The Touro S is not expensive and it’s very fast. The performance of other 5400 rpm drives varies a lot. Some are pretty fast, others less so.

I have several dozen 1TB portable drives from various manufacturers. For casual data transfer or archival storage almost any one is OK. However if I’m actually editing in the field or downloading data from my entire shooting team, or duplicating data for backup in the field, I want the fastest one which is 7200 rpm.

[Joe Marler]

[Noam Osband] “basic editing work while traveling….If that’s what I’m doing, should I care whether it is USB 2.0 or thunderbolt?”

I have over 100TB of material on various external drives and test them frequently. There is a huge performance difference between USB 2.0 and 3.0. I would suggest not using 2.0 — it’s just too slow.

Likewise the speed difference of USB flash drives varies hugely. I have tested an older USB 2.0 flash drive at 20 MB/sec vs a new SanDisk Extreme Pro at 240 MB/sec. With larger file sizes typical of HD and 4k material, it is very frustrating to be waiting around during a field assignment while data transfers.

Re bus-powered USB 3.0 drives, most are 5400 rpm and cover a range of performance from fairly slow to not so bad. A couple of companies make 7200 rpm bus-powered USB 3.0 drives, which are relatively fast. The fastest one I’ve tested is the 1TB HGST Touro S: https://www.touropro.com/en/product/touro-s/

G-Drive and some other companies make a bus-powered 7200 rpm Thunderbolt drive. They are supposedly fast but I’ve never tested one vs the HGST Touro S: https://www.g-technology.com/products/g-drive-mobile-thunderbolt-1-tb-portable-hard-drive

Seagate makes a 4TB bus-powered USB 3.0 drive called the Backup Plus Fast that is probably the fastest one: https://www.seagate.com/external-hard-drives/portable-hard-drives/performance/backup-plus-fast-hdd/ However it is interally RAID0, and it may pull more power than some USB ports can supply. However I think most Apple computers can supply extra DC power to USB since they can charge an iPad.

Re USB 3.0 vs Thunderbolt, I prefer Thunderbolt for AC-powered drives but for portable USB 3.0 drives I don’t think it makes much performance difference. From a reliability standpoint I think Thunderbolt drives have fewer spontaneous disconnects but most of my USB 3 drives do OK. USB 3 is very handy because (assuming it’s formatted exFAT) it can be used on either Mac or Windows.

[Joe Marler]

I’ve edited a lot of 4k GH4 camera native material on a top-spec 2013 iMac 27 with no problem — for single cam. However if doing multicam, I definitely needed to generate proxies for decent editing performance. Even just two or three 4k H.264 streams is a big CPU burden that bogs down scrubbing, JKL editing, etc.

You can try it with camera native material, then (if needed) generate proxies later without disrupting any work done to that point. FCP X makes this very easy.

[Joe Marler]

[Chris Frantz] “Encode a 50 min prores 422(HQ) file, embed 8 channels of audio, then drop it in a timeline of your choice and whatever settings you want. Tell me it doesn’t beachball or take 10-20 minutes to draw the waveforms. If one works, two or three certainly will not. Work can’t be done with these types of files, which make up a ton of long form stuff. “

If this is a reproducible scenario that happens on any X system under these conditions, I’d hope it would be fixed fairly quickly. When a problem is encountered on mainstream tasks, customers with enterprise support on high end products can’t be told “I’m sorry that’s just totally broken, it may be fixed in the next major version”. That is what hot fixes are for.

That in turn raises the question whether Apple distributes private FCP X hotfixes to enterprise customers. If yes why cannot other customers get those. If no, then how are those customers coping? Either way this implies there is some solution for the rest of us.

If it is *not* reproducible that implies it’s something unique to your system, which gives hope of some procedural workaround.

[Joe Marler]

[Rikki Blow] “…3 cam and several audio non-contiguous shoots…i don’t know how else to find matching audio and/or alternative angles for the sections i choose for the final edit -“

For situations like this I use PluralEyes. Provided you have audio, it works very well. It pre-syncs everything automatically, then produces a XML you import to FCP X as a multicam project. Non-synced material will also be placed in the project based on date/time and you can manually position those as needed.

[Joe Marler]

[Sverker Hahn] “In one scene I have a sudden change in exposure somewhere in the middle of it.”

I have used Digital Anarchy’s Flicker Free plugin and it works very well. In my case a DJI Phantom Vision 2+ drone had a lot of exposure fluctuation due to auto ISO. It fixed those almost totally. However it is mainly designed to fix multiple exposure fluctuations, not to smoothly bridge between two different exposures. There is an eval version, so you could try it:

https://www.digitalanarchy.com/Flicker/main.html

[Joe Marler]

[John Rofrano] “HD just isn’t that taxing on disk i/o.
“

Yes and this is commonly misunderstood. The data rate just isn’t that high for typical long-GOP encoded material such as H.264. However if transcoding to optimized media, the data rate will be much higher. Multiple streams of optimized HD material will tax a single-disk, and 4k is higher still.

My main recommendation is don’t edit from a 5400 rpm bus-powered USB 3.0 drive. The 7200 rpm HGST Touro S is one of the fastest bus-powered USB 3 drives — you could probably get by with that but it’s not ideal: https://amzn.com/B00IVFDQ48

When you add up camera media, imported media (for AVCHD/XAVC), optimized media, render files, analysis files, etc, the data volume is much greater than first appears. So the issue is more than “can I edit on this?” If ingesting and organizing a significant multi-cam shoot, just moving the data around (inc’l backup) takes a lot of space and I/O, much more than the creative editing phase. RAID helps deal with this.

[Joe Marler]

We have edited AVCHD documentary material from the XA10 family (HFG10 and HFG30) on a similar iMac. It is not that bad but as Noah said using proxy or optimized media will make editing more responsive. Transcoding costs disk space hence I/O bandwidth but reduces CPU demands.

We usually don’t use proxy or optimized media for AVCHD, and the newer Canon camcorders allow switching to MP4 which we prefer. While many codecs are superficially similar the CPU demands on FCP X vary greatly. E.g, a 30 megabit/sec H.264 .mov file from a Canon DSLR isn’t that bad. However a 30 megabit/sec H.264 .mp4 file from a GoPro can be sluggish.

A significant complication with AVCHD and XAVC is you cannot import to FCP X with the “leave files in place” option. It will copy the data either (a) inside the library or (b) external to the library. So after the import the data exists redundantly in two locations (1) Your camera native files, and (2) One of the above two locations. After import the camera native files are not needed except possibly for backup, but the peak storage requirement can be greater than other codecs since you can’t use “leave files in place”. This MacBreak Studio video summarizes the new media management options: https://www.youtube.com/watch?v=wGogEwnX9yE&index=35&list=PL607BE2B2BFE9BE1A

In general I think your 2011 iMac will be perform OK on the native files, but you’ll need to test this. This will also vary based on whether it’s a single stream or multicam, which is more demanding.

Also, simple edits aren’t what takes so much CPU, it is effects. If using many effects this might necessitate transcoding to proxy/optimized to free up CPU cycles for the effects. You’ll have to experiment.

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]

Max thanks for all the work on this comparison. It was well written, well shot, and will help a lot of people.

I don’t know what is Adobe’s problem with implementing Quick Sync. They said the CC “rent only” model would allow adding features faster, vs waiting for the next major version. It has now been two years and still no Quick Sync. Your tests plus many others show how important this is for H.264 exporting.

This is further important since interframe encoding doesn’t really benefit from GPU acceleration, no matter how powerful. The core algorithm is intrinsically sequential and cannot be easily parallelized for GPU assist. This is also a problem for the Mac Pro since Xeon doesn’t have Quick Sync.

Supposedly Skylake will further enhance Quick Sync to include HVEC/H.265 and maybe VP9. Encoding to H.265 is much more CPU intensive than H.264, so the Quick Sync advantage on H.265 may be further magnified. Maybe Adobe will have it by then. Until Intel adds it to Xeon there is no good answer for Xeon-based systems.

Your main goal was not Premiere vs FCP but 2014 vs 2015 MBP, and you achieved that well. My only recommendation would be adding one test to neutralize the Quick Sync advantage to better assess performance without this influencing the results so much. On FCP X that would be using multi-pass encoding, then you’d have to use the closest equivalent on Premiere. It would just be interesting to see it changes the 2014 vs 2015 MBP difference, and whether FCP X was still faster than Premiere at H.264 export without this advantage.

[Joe Marler]

There’s something funny going on. My previous test was 47 sec for Compressor export an 07:30 H.264 storyline to single-pass H.264 at 720p. However when I switch to a slightly longer 09:30 timeline — using the same Compressor preset, it takes 12:30. That same storyline takes about 03:20 to export using FCP X to single-pass H.264 at 720p.

The first storyline is a 720p/30 H.264 video which was previously exported from Premiere Pro CS6. The 2nd (slow) storyline is a 09:30 multicam project I did in FCP X. The source material is a mix of 1080p/30 AVCHD, MP4 from Canon camcorders, 1080p/30 H.264 from a GoPro and H.264 from a Canon 5D3.

I then exported the 2nd 09:30 MC storyline, re-imported it, then exported that to single-pass H.264 using both FCP X and Compressor.
FCP X: 01:36
Compressor: 01:26

I then loaded another library with a 07:30 single-cam project composed of various material from Canon camcorders, Nikon and Canon DSLRs, and exported that to single-pass H.264 using both FCP X and Compressor:
FCP X: 01:21
Compressor: 01:20

All of the above is using unoptimized material.

So there is something about the MC storyline I have which makes export about 4x slower with Compressor than with FCP X. It’s suspicious that is roughly the same difference as Quick Sync makes, but I am definitely using a single-pass H.264 preset. I tested with and without CBR and it made not difference.

I’ll do more testing if I have time, but I am concerned about the wide variation in export performance.