[Ryan Holmes]

Partitioning won’t help. It’s still 1 physical drive (1 spinning disk with 1 needle). Partitioning just fools the OS into thinking there is 2 different drives. An actual physical second disk is what is typically recommended – something either Thunderbolt or Firewire based.

I don’t think your export times are way out of line. 1.5 hour for a 10 minute clip may be justifiable given the codec your source material is in (which is?), the codec you’re going to (h.264), the amount of vfx/titles processing required, and the internal HD. If you’re on a deadline you can look into some hardware accelerators to speed up that h.264 workflow – https://www.matrox.com/video/en/products/mxo2_mini_max/

Ryan Holmes
http://www.ryanholmes.me
vimeo.com/ryanholmes

[Ryan Holmes]

How big are your PSD’s (i.e. actual dimensions, dpi is irrelevant in video except that you get a certain physical resolution)? If they are over 4096×4096 FCP will have problems with that.

Assuming you’re running all these files off the boot drive of your iMac keep in mind that that 1 drive is responsible for running any/all OS functions, feeding Compressor the file, and writing a new file to disk. If you hang around here for any length of time you’ll hear it said often that using your boot drive as your media drive is a bad idea.

Ryan Holmes
http://www.ryanholmes.me
vimeo.com/ryanholmes

[Ryan Holmes]

A bunch of things contribute to exporting time: what’s the codec of your source material? how much VFX are on the shot (title, vfx, matte, etc.)? Are you exporting out a h.264 mp4? Where are you exporting the files to – what drive? Internal HD? External HD?

Generally, for FCP7 I’ve noticed that it takes anywhere from 2-4X the length of your sequence to transcode to h.264 mp4. So if you have a 1 minute sequence it can take anywhere from 2-4 minutes to transcode. I’ve seen it take longer if you “Send To…” Compressor from within FCP. I usually export out a self-contained (some use a reference file) Quicktime mov and then import that into Compressor.

Ryan Holmes
http://www.ryanholmes.me
vimeo.com/ryanholmes

[Ryan Holmes]

[Ben Edwards] “PP has low CPU and disk utilization and memory is not topping out.”

This is because Adobe utilizes your GPU (i.e. video card) to do most of the heavy lifting. It doesn’t tax the CPU until exporting. RAM is still important though. The more the better. However, playback, realtime effects, color correction, etc. happens on the GPU. This is part of the Mercury Playback Engine – https://www.adobe.com/products/premiere/mercury-playback-engine.html

Others will disagree with me, but I don’t like relying on hacked gear when I’m trying to make a living from it (cameras, computers, video cards, you name it). I need it to be stable, robust, and rock-solid. Hacking a GPU (while it works, friends of mine on the Mac side do the same thing) seems like asking for trouble. what I would do (and what I do in my environment) is spend the $$$$ for a qualified, tested, proven card. Since you’re a Windows user there’s almost 24 different qualified cards, so your chances of finding one that meets your price point is pretty good. Adobe lists them all on that link above.

My order of importance for your problem:
(1) Qualified GPU
(2) More RAM
(3) Clean off space on your hard drive or buy some new ones (anything over 50% full will take a serious playback speed hit)

Ryan Holmes
http://www.ryanholmes.me
vimeo.com/ryanholmes

[Ryan Holmes]

Are you using an internal hard disk? Or an external one?

If internal – is it the primary drive (which houses applications, operating system, etc.)? How full is it?

If external – what type of drive? How is connected (Firewire, USB, eSATA)? How full is it?

It’s a bad idea to edit video off the internal boot drive of the computer. That disk is already spinning for operating system related tasks. Asking it to read video files as well is a large challenge task, and it will often come up short.

If whatever drive you have the media on is even half full you’ll start to notice a degradation in performance. This is just the nature of spinning drives. If you can clear off space on your hard drive that may help.

If it’s an external drive – connect it by firewire or eSATA. USB is a poor connection for video editing needs. It works better to transfer data, but not to edit video from (even a compressed format like DNxHD 36).

Ryan Holmes
http://www.ryanholmes.me
vimeo.com/ryanholmes

[Ryan Holmes]

Jeff – Very good point. Sorry I missed that.

Quick conversion for you:

36 Mbps = 4.50 MB/s
145 Mbps = 18.13 MB/s
220 Mbps = 27.50 MB/s

If you had a codec running at 85 MB/s (megabytes) then that’s equivalent to 680 Mbps (megabits). Bits and bytes matter! 😉

Ryan Holmes
http://www.ryanholmes.me
vimeo.com/ryanholmes

[Ryan Holmes]

Ben,
I’m assuming you mean DNxHD (not DHxHD)…Avid’s codec. If so, then when you transcode from h.264 DSLR footage you’ll likely go with DNxHD 145 (as there is no 120). DNxHD 36 is meant for offline editing….though in some cases this may be sufficient. Depends on the footage, the client, the budget, and the post-prodution process.

DNxHD 145 will do great with compositing or color correction needed. Remember you’re footage is only ever as good as the original capture format. In your case, a DSLR shooting to the h.264 codec. Currently that is only an 8-bit codec. So even if you transcode to DNxHD 220, you’re not going to be adding data or picture quality to your image.

If you setup a RAID0 with 2 or more disks you should be fine on playback with DNxHD. It is a pretty efficient codec (similar to Apple ProRes).

Ryan Holmes
http://www.ryanholmes.me
vimeo.com/ryanholmes

[Ryan Holmes]

Are you viewing the footage on a computer monitor or broadcast reference monitor?

Your computer display (and your LCD, plasma, LED TV) is a progressive scan monitor. So when you preview interlaced footage on there you tend to see the scan lines (odd and even). If you pause it then it’s really pronounced. But even when it plays you’ll see the interlacing in any motion areas (running, cars driving by, hand waving, etc.).

Preview your footage on an interlaced monitor and you shouldn’t have any problems. If your final delivery is intended for progressive displays (projectors, YouTube, Vimeo, etc.) then you’ll need to de-interlace your material before final delivery.

Ryan Holmes
http://www.ryanholmes.me
vimeo.com/ryanholmes

[Ryan Holmes]

[Alex Udell] “Make a new Project and then IMPORT your previous project.
“

Sorry, I mistyped above (referencing XML export/import). What you’ve listed is also still a “workaround.” Albeit slightly shorter than what I described above. Still not as fast as I’d like….

Just my $.02

Ryan Holmes
http://www.ryanholmes.me
vimeo.com/ryanholmes

[Ryan Holmes]

Agreed. That is a “workaround” for the limitation that currently exists. If speed is one of my primary concerns (and it is ;-), then the extra steps to export out a XML, create a new project, reimport that file, just to re-export another XML means I’m wasting time.

If you’re doing this just once a day, maybe no big deal. But what if it’s multiple times in a day? In a week? What if you have to reconform because the edits changed? Well now that time starts to add up. Since we can already export a XML out of PPro why not just enable it to export a single sequence as well? Leave it to the user to decide via a dialog box if they want the whole project (for moving to another NLE) or just a sequence for VFX or color grading.

I’m just looking for the maximum amount of efficiency in my software. I don’t like to do things that I think the software/hardware should be able to take care of.

Just my $.02

Ryan Holmes
http://www.ryanholmes.me
vimeo.com/ryanholmes