2013 MacPro 6 core VS 2012 3.2 MacPro

[John Heagy]

[Bret Williams] “Well, not if it wasn’t rendered you couldn’t. And the audio always had to be recompressed. It didn’t reference audio. A 1hr video would had taken a little bit just for the audio alone.”

Correct… In our case all media is converted to ProRes so no rendering except transitions, titles, etc. Yes it does flatten the audio, no re-compression though. Even with nothing rendered a ref movie takes less than 5min to create typically. There’s no way around render time. One pays that price whether ref or self contained.

Apple wants to kill ref.mov because of security concerns. Basically the treat of a ref mov pointing to suspect files. Not sure how a FCP xml or any project file from any media app which points to source files is any safer.

John

[Erik Lindahl]

Would be more valid with a compression test from a proper encoder like Episode Pro or even Adobe Media Encoder. Apples Compressor is quite sub-par (or has been before).

[Bret Williams]

Ref was nice, but since it was referencing render files, that disappeared easily if changes were made, that I found if I used reference files that apps like AE or DVDSP were often trying to search for render files that were gone. So I quit using them a long time ago. Too much trouble and drive space was too cheap.

Now we don’t have to spend the time transcoding to ProRes, so there’s the time saving on the front end.

[Gary Huff]

[Erik Lindahl] ” Would be more valid with a compression test from a proper encoder like Episode Pro or even Adobe Media Encoder. Apples Compressor is quite sub-par (or has been before).”

Agreed. Compressor isn’t the best way to check this.

[John Heagy]

[Bret Williams] “I used reference files that apps like AE or DVDSP were often trying to search for render files that were gone.”

True enough.. FCP ref.mov are not good long term. We use them in conjuction with our Episode engine to offload flattening or encoding, after which they are deleted. Besides saving the editor time it allows quick re-dos.

[Bret Williams] “Now we don’t have to spend the time transcoding to ProRes, so there’s the time saving on the front end.”

True again… but we find saving time on the back end far more valuable. It takes time for all the media to accumulate, time we use to encode to ProRes and tag with embedded metadata. As a project proceeds, workflow pipelines start sprouting invoking other apps, and the final timeline gets more complex as the deadline nears. It’s all this later work we strive to lubricate so there are fewer issues and renders as deadline pressure and project complexity increases.

John

[Jeremy Garchow]

[John Heagy] “True again… but we find saving time on the back end far more valuable. It takes time for all the media to accumulate, time we use to encode to ProRes and tag with embedded metadata. As a project proceeds, workflow pipelines start sprouting invoking other apps, and the final timeline gets more complex as the deadline nears. It’s all this later work we strive to lubricate so there are fewer issues and renders as deadline pressure and project complexity increases.”

Here’s hoping that developers will plug in to FCPX so that ref files won’t be as necessary?

I miss ref files, too.

“Export integration with third-party apps

Developers can plug directly into the Share interface within Final Cut Pro, allowing for seamless export to third-party systems such as Sienna, Vizrt, Primestream FORK, axle, and Cantemo Portal.”

[Keith Koby]

[Jeremy Garchow] “Here’s hoping that developers will plug in to FCPX so that ref files won’t be as necessary?

I miss ref files, too.

“Export integration with third-party apps

Developers can plug directly into the Share interface within Final Cut Pro, allowing for seamless export to third-party systems such as Sienna, Vizrt, Primestream FORK, axle, and Cantemo Portal.””

I think that means exporting the file from fcpx and having a MAM be aware of it instantly. What John would want would be to export an xml and have episode engine read it like an edl and use it as a source.

Does the fcpxml point to render files? I’m under the impression that it does not. Otherwise, you could in theory convert fcpxml to edl and feed edl to episode engine.

I’m curious to see what they (telestream) have in store for nab.

[Jeremy Garchow]

[Keith Koby] “What John would want would be to export an xml and have episode engine read it like an edl and use it as a source. “

That’s what I would want, too.

Compressor can do it without render files so I was hoping telestream (or anyone) can do it. Making multiple encodes of one file is a much slower process with FCPX as you have to wait for the master to export first.

[John Heagy]

I like discussing what John wants 😉

So no, fcpxmls do not point to render files so that won’t do unless the option of including them was added so it did link to current render files.

Some sort of aaf variant might do, but the glacial progress of aaf.xml says that isn’t likely.

There is the mxf reference format OP1b, but I don’t know if that supports other wrappers besides .mxf

I understand Apple wants to kill QT ref due to security concerns. Apparently Apple is concerned that the referenced files could point to a suspect file and be opened. What I don’t understand is how files listed in a fcpmxl, or really any project file from any other app, would not have the same issue?

John