Creative Community Conversations (was FCPX Debates) Forum
Back to Premiere. sigh.
Back to Premiere. sigh.
by Tom Sefton on May 1, 2020 at 12:39:43 pm

Had to revisit Premiere 2020 for a collaborative edit. My god it is slow compared with FCP. Scrubbing, previewing rushes, start stop on timeline all feel like the keyboard has been covered with treacle, and as a final complaint, how on earth do you cope with the media re-link tool in Premiere; it just doesn't work anywhere near as well as FCP.

This is on a brand new Mac Pro with afterburner and copious RAM installed, and a project made up entirely of ProRes assets. It's not even close to Resolve, which is fast becoming our no2 editor...

Co-owner at Pollen Studio
www.pollenstudio.co.uk


Re: Back to Premiere. sigh.
by Eric Santiago on May 1, 2020 at 1:44:21 pm

You just deal with it ☹

I work equally now in Premiere and FCPX.

The feeling is mutual.

Throw in a few days of Avid here and there and you get to really appreciate how much faster you are in FCPX.

And no, nothing to do with familiarity, started in Premier in 1994 and Avid 2001.


Re: Back to Premiere. sigh.
by Scott Witthaus on May 1, 2020 at 5:07:12 pm

[Eric Santiago] "you get to really appreciate how much faster you are in FCPX.
"


Just coming back to X from Premiere gig. I so agree!


Re: Back to Premiere. sigh.
by Jeremy Garchow on May 1, 2020 at 5:47:34 pm

[Tom Sefton] "treacle"

trea·cle
/ˈtrēk(ə)l/

noun
noun: treacle; plural noun: treacles
1.
BRITISH
a thick, sticky dark syrup made from partly refined sugar; molasses.
2.
cloying sentimentality or flattery.
"enough of this treacle—let's get back to business"


Just adding to my son's e-learning for the day as my new job of teacher's intern continues....


Re: Back to Premiere. sigh.
by Joe Marler on May 1, 2020 at 6:43:19 pm

[Tom Sefton] "all feel like the keyboard has been covered with treacle"

Premiere has actually gotten much faster at a few things like H264 export. It is currently much faster than FCPX at 10-bit HEVC export, so it's not slower on every single thing.

But on the "high touch" and "common path" UI interactions (e.g. viewer update rate and lag time on JKL input) it can be quite sluggish, at least when tested on identical Mac hardware vs FCPX and Resolve. It is worse with some codecs than others.

When testing 4k 10-bit 4:2:2 400 mbps H264 All-I from a GH5, I examined the viewer (aka program monitor) update rate on a 10-core Vega 64 iMac Pro running Mojave 10.14.6 when fast forwarding at 4x speed in the timeline, with Premiere set on 1/4 resolution and the FCPX viewer on "better performance". I don't remember how I configured Resolve but it wasn't anything special. This was done by shooting the screen during 4x FF with a camera at 240 fps and counting real-world update rate.

Resolve Studio 16.1.0.055: 28 frames/sec
FCPX 10.4.7: 20 frames/sec
Premiere Pro 13.1.5: 2 frames/sec

Some performance differences can vary based on minor things. Even though the above test showed Resolve had a quicker viewer update rate than FCPX, this was only during continuous playback. If you grabbed the playhead and moved it back and forth, FCPX was faster.

It's ironic the Premiere playback engine is code-named Mercury. It's like having a pet turtle named "Lightning".

Years ago a database called FoxBase was famous for being super fast. The CEO would walk among his developers with a stopwatch on a lanyard around his neck and demand impromptu timed performance tests of their code. I suppose nobody at Adobe has ever done that.

Before Resolve got so fast, you could claim that FCPX was single-platform and their performance advantage derived mostly from that. However Resolve is multi-platform and it has become a real speed demon, but in general interactive use FCPX is still a little more responsive.


Re: Back to Premiere. sigh.
by David Cherniack on May 3, 2020 at 5:01:12 pm

[Joe Marler] "It's ironic the Premiere playback engine is code-named Mercury. It's like having a pet turtle named "Lightning"."

The Mercury Playback Engine is what, 12-13 years old? FCX and Resolve very obviously benefit from later development. Likely there's a group of Adobe engineers working on an update.

David
http://AllinOneFilms.com


Re: Back to Premiere. sigh.
by Oliver Peters on May 3, 2020 at 5:52:17 pm

[David Cherniack] "The Mercury Playback Engine is what, 12-13 years old?...."

MPE is Adobe's architecture for dealing with the GPU to accelerate effects. I'm not sure it has anything to do with the playback issues that are of concern.

- Oliver

Oliver Peters - oliverpeters.com


Re: Back to Premiere. sigh.
by David Cherniack on May 3, 2020 at 7:45:43 pm

[Oliver Peters] "MPE is Adobe's architecture for dealing with the GPU to accelerate effects. I'm not sure it has anything to do with the playback issues that are of concern."

AFAIK it had all to do with playback...which was why it was called a playback engine. It worked in the first 64 bit build of PrPro as I recall. GPU acceleration worked with some effects, not with the actual decode of the codecs during playback.

David
http://AllinOneFilms.com


Re: Back to Premiere. sigh.
by Oliver Peters on May 3, 2020 at 8:00:45 pm

[David Cherniack] "AFAIK it had all to do with playback...which was why it was called a playback engine."

Nope. You can turn it off and go software-only and it makes no difference on standard media playback. It affects effects processing and transform functions, so if you add filters in software-only or several layers with PIP, then you are taxing the CPU. It also affects the output using an external i/o.

For example, on my mid-2014 MBP, if I put a 4K ProRes clip on a 1080 timeline as "set to frame size" so it scales, it will play just fine (1/2 resolution). When the project is set to Metal acceleration, there's no colored "stress" line over the timeline. Playback is smooth and instant. When I switch to software-only, I get a red line over that clip and it has to buffer for a split second before it starts to play.

- Oliver

Oliver Peters - oliverpeters.com


Re: Back to Premiere. sigh.
by David Cherniack on May 3, 2020 at 9:53:43 pm

[Oliver Peters] "Nope. You can turn it off and go software-only and it makes no difference on standard media playback. It affects effects processing and transform functions, so if you add filters in software-only or several layers with PIP, then you are taxing the CPU. It also affects the output using an external i/o."

You could, and can, certainly turn GPU acceleration of effects and today I'm pretty sure that some codecs are GPU accelerated in decode-and-playback, but back then it was all CPU for decode. Joe is right, back then it seemed pretty fast but today it may be showing its age. It doesn't yet look optimized for the new Mac Pro according to Puget Systems comparative tests.

David
http://AllinOneFilms.com


Re: Back to Premiere. sigh.
by Joe Marler on May 3, 2020 at 8:52:28 pm

[David Cherniack] "AFAIK it had all to do with playback...which was why it was called a playback engine. It worked in the first 64 bit build of PrPro as I recall. GPU acceleration worked with some effects, not with the actual decode of the codecs during playback..."

That was also my recollection. MPE was a catch-all term for numerous performance enhancements to the playback engine, including improved multi-threading, 64-bits, and GPU-accelerated effects. Initially only some effects were GPU-accelerated but the entire playback engine felt fast. Adobe obviously had done a lot of profiling work to optimize decode-oriented code paths.

The Premiere intro video still on Adobe's web site today describes it as allowing "editors to work with 4k and beyond, without time-consuming transcoding", and "never needing to render until your work is complete": https://helpx.adobe.com/premiere-pro/how-to/what-is-premiere-pro-cc.html?set=premiere-pro--get-started--overview

Back in the DV and 1080p H264 days, CS5/CS6 did seem very fast on period Windows machines. The ability to edit compressed native camera formats with good performance and without transcoding was impressive - it wasn't just an advertising slogan.

That raises the question, over time did the other NLEs get disproportionately faster on newer hardware generations or was Premiere not that fast back then but the other NLEs were even slower?

I recollect CS5 as seeming very fast. However when I recently inherited a cross-NLE project and had to concurrently run Resolve 16, Premiere 14 and FCPX 10.4.8 on my 10-core Vega 64 iMac Pro, FCPX felt super fast, Resolve felt nearly that fast, and Premiere seemed very laggy and sluggish.

I think some of it is just aesthetic - the FCPX skimmer is hyper-responsive and Resolve 16 is similar. But that doesn't necessarily make you edit faster. There's a difference between feeling fast vs producing more completed work fast.


Re: Back to Premiere. sigh.
by Eric Santiago on May 4, 2020 at 1:22:27 pm

[Joe Marler] "but in general interactive use FCPX is still a little more responsive."

I think this is what I cherish most with any app I work with.
Sure I expect apps such as Maya to be slow on most functions since the assumption is that its a graphics hog and data-set dependent but a vertical bar and already cached set of frames should not be lagging period.
This is where FCPX shines IMHO.
Now, of course, I can come up with a few functions that Premiere exceeds over FCPX but I just can't have that "lag" feeling when I'm doing basic edits.


Re: Back to Premiere. sigh.
by Jeremy Garchow on May 1, 2020 at 10:17:40 pm

[Tom Sefton] "how on earth do you cope with the media re-link tool in Premiere; it just doesn't work anywhere near as well as FCP. "

The "attach proxies" function in Premiere, though, is pretty killer.

All I want for quarantine is better format relinking in fcpx.


Re: Back to Premiere. sigh.
by Oliver Peters on May 2, 2020 at 12:27:51 am

Sigh ☺ You guys are sooooo funny. I regularly bounce between the apps and really don't see any clear advantage to X over PPro. Sure, it skims nicely and handles media well. But Premiere's media handling is pretty good these days. Maybe, as Apple would say, you are just holding it wrong ☺

- Oliver

Oliver Peters - oliverpeters.com


Re: Back to Premiere. sigh.
by Tom Sefton on May 2, 2020 at 6:57:15 am

Gahhhhhh you can’t be serious.

Premiere makes our new Mac Pro with an afterburner look like an old PC from years back making the jump to HDCAM footage from DV. If this was skimming over the actual 8K red rushes it might be acceptable, but this is 2K ProRes LT proxies - created in media encoder and stored in the root project folder called PROXIES. And somehow the search function still wants to go burrowing through my user library like some kind of hyperactive toddler with a short attention span.

Want to change your timeline resolution in premiere? Nope. Create a new one and copy all your media there. I might add that this was a timeline of the resolution 1280x720 with 2K footage in there. Is this normal? Really? Do people actually accept this level of performance in premiere just because they’ve been told that fcpx is hard to use and difficult to understand and you need to rethink your approach to editing and all that jazz?

Fcpx? Just change it. It’s that easy. As well as bouncing up to HDR or modifying your audio channels.

Skim your play head around the timeline in premiere - it sticks to random sections like (molasses) and when you hit space bar it thinks. Not for long, but long enough for you to believe that something is happening....it’s no longer part of your finger or your thought, it’s now an obvious machine that has to think to do something of your bidding. Fcpx is so fast and reactive that you forget a machine is there.

Just as a test I thought I’d sling the same footage at premiere that we are working on in fcpx. Multiple layers of 4/6K 60p ProRes 4444 footage with 2 colour adjustment layers on each, masks etc.. That....was hilarious.

However - I jumped back into tracks with audio mixing like it was 2008. That’s quite a nice trip down memory lane - like meeting up with an old friend for a chat about music you like, until you realise they’ve been taking crystal meth for 12 years and they now can’t talk for 30s without swatting away imaginary flies.

I know it’s another string to your bow as an editor, but how has premiere seemingly got worse than resolve?

Co-owner at Pollen Studio
www.pollenstudio.co.uk


Re: Back to Premiere. sigh.
by Oliver Peters on May 2, 2020 at 2:08:53 pm

[Tom Sefton] "Gahhhhhh you can’t be serious."

I'm absolutely serious. There are plenty of ways to make comparisons that skew one way or the other. There are certainly cases where I feel FCPX is a better fit. But it's not the universal solution for me.

I have two main issues with FCPX. The UI is "sticky" - meaning every action - to click on something - takes a split second longer that in Premiere, where it's largely instant. Relinking is the second. I've taken home media from archive drives to WFH. The FCPX Library linking is based on the shared storage locations at the office. I have had to move assets from multiple drives onto a single RAID, so paths are completely a mess. Relinking in FCPX is nearly impossible. Premiere - I can point to the new locations and I'm good to go.

I don't work with a new Mac Pro. I don't have enough media in any given project that would benefit from an Afterburner card. So that's a non-issue for me and will be for a while to come.

Audio mixing on complex jobs in FCPX? A complete mess with multiple compounds, because there is no track-based mixer or roles-based mixer. Can you do it? Sure. But not in a way that's conducive to any normal way of mixing. For example, change a filter on a clip, which is buried inside a compound with more effects on the role - all while still listening to the effect through a compressor on the master output? Easy in Premiere with track, submaster, and master tracks/buses. Not possible in FCPX.

[Tom Sefton] "I know it’s another string to your bow as an editor, but how has premiere seemingly got worse than resolve?"

I didn't say that it was. But in terms of the editor UI - I feel Premiere is a better editor. I'm also not fond of the database method for project files used by Resolve. Trimming is the biggest issue for me in Resolve and J-cut/L-cut trimming with embedded audio isn't possible yet in the cut page.

- Oliver

Oliver Peters - oliverpeters.com


Re: Back to Premiere. sigh.
by Joe Marler on May 3, 2020 at 11:57:13 am

[Oliver Peters] "The FCPX Library linking is based on the shared storage locations at the office. I have had to move assets from multiple drives onto a single RAID, so paths are completely a mess. Relinking in FCPX is nearly impossible. "

Oliver, could you clarify this? While there are some major FCPX re-link issues, in general the above case works for me - provided the filenames are unique. IOW I can combine multiple media trees from a NAS to a directly-attached RAID, change all the paths, and FCPX File>Relink Files will rapidly scan the entire volume and relink all the files.


Re: Back to Premiere. sigh.
by Oliver Peters on May 3, 2020 at 3:04:27 pm

[Joe Marler] "Oliver, could you clarify this? While there are some major FCPX re-link issues, in general the above case works for me "

The original edit was done from media on shared storage. Library on a local machine and media left in place. These files were archived onto different archive drives. That's because the media isn't associated with one single project. So the library and various media files are on several different drives. In order to make the necessary revisions at home, I have to copy all of these pieces (media and library) back onto single larger RAID. So obviously in that process, paths and volume names have all changed. Filenames are unique.

When I launch the FCPX library it starts to search for files, first going for the nonexistent volume in the path name. It just sits searching and searching. When it finally (minutes later) lets me point it to the new volume it goes back into a long searching mode again before I can actually point it to the correct file.

It would be a very simple fix (IMHO) to add a "manual searching" function that let you point to a place for it to start searching, like you can for individual files once you are in the library.

In the same situation in Premiere, when it can't initially find the media on launch, it quickly pops up the relink dialogue and you navigate to the new files and hit locate. Then all files in a relative path are immediately relinked and you are ready to go. The only slowdown is that waiting for caching to be completed, since no caches have yet been built. Fast for a project with a few assets. Longer for a project with hundreds of assets.

In my case for this project, I only needed to fix one timeline. So I canceled the search and let it load with media offline. Then relinked the few individual files in that sequence.

- Oliver

Oliver Peters - oliverpeters.com


Re: Back to Premiere. sigh.
by Jeremy Garchow on May 3, 2020 at 5:22:54 pm

[Oliver Peters] "It would be a very simple fix (IMHO) to add a "manual searching" function that let you point to a place for it to start searching, like you can for individual files once you are in the library."

Single click the library, hit file > relink files. Hit the locate all button, and point it at the top most folder or directory, (or even drive), and hit Choose. Fcpx verifies, then hit Relink Files.

You don’t have to wait, just keep clicking through the interface until you get to the verify stage.


Re: Back to Premiere. sigh.
by Oliver Peters on May 3, 2020 at 5:28:10 pm

[Jeremy Garchow] "Single click the library, hit file > relink files. Hit the locate all button, and point it at the top most folder or directory, (or even drive), "

It's at this stage where - if you have a large volume of files - that you get stuck on searching, same as with launch.

Just to clarify, sometimes that does go fast. But on this batch of revisions, when you try to follow this process, you can never stop the "looking for matching filenames." So at each step you get a spinning beach ball for a while until it to a point where it lets you go to the next folder. Basically the app is trying to be too smart for its own good.

- Oliver

Oliver Peters - oliverpeters.com


Re: Back to Premiere. sigh.
by Joe Marler on May 3, 2020 at 10:55:06 pm

[Oliver Peters] "ometimes that does go fast. But on this batch of revisions, when you try to follow this process, you can never stop the "looking for matching filenames." So at each step you get a spinning beach ball for a while until it to a point where it lets you go to the next folder."

I have definitely seen this behavior, just not in a while. It is abnormal and very slow. It sometimes yanks control from the user before you can even point the UI to a folder. There is no progress bar, but a spinning beach ball for a long time, which itself indicates poor programming or a malfunctioning system layer.

Was the media on shared storage? Was the media indexed for Spotlight searching? If it's using Spotlight lookups to expedite the searches, some aspects of this may not work properly on a NAS. In my testing, filename searches work but some metadata searches are unreliable on a NAS. FCPX would have to read metadata to determine relink compatibility.

If it's on local storage it would be interesting to rebuild Spotlight indexes on that and see if it makes a difference. https://support.apple.com/en-us/HT201716


Re: Back to Premiere. sigh.
by Oliver Peters on May 4, 2020 at 12:26:58 am

[Joe Marler] "Was the media on shared storage?"

From my earlier post:

The original edit was done from media on shared storage. Library on a local machine and media left in place. These files were archived onto different archive drives. That's because the media isn't associated with one single project. So the library and various media files are on several different drives. In order to make the necessary revisions at home, I have to copy all of these pieces (media and library) back onto single larger RAID. So obviously in that process, paths and volume names have all changed. Filenames are unique.

Not sure about Spotlight indexing. Certainly nothing on shared storage would be Spotlight indexed.

- Oliver

Oliver Peters - oliverpeters.com


Re: Back to Premiere. sigh.
by Jeremy Garchow on May 4, 2020 at 1:38:29 am

You can select the new drive and hit “choose”

You don’t have to wait for anything else.


Re: Back to Premiere. sigh.
by Joe Marler on May 4, 2020 at 12:15:11 pm

[Jeremy Garchow] "You can select the new drive and hit “choose”

You don’t have to wait for anything else."


Oliver was taking about an intermittent bug whereby you *can't* hit "choose". The relink UI yanks control from you and goes to a beach ball. It is apparently enumerating something in the background for several minutes. Then it finally finishes and you can select the folder and the rest of the relink process is normal. On very large datasets I've seen this phase take 10-15 min. This is on various local Thunderbolt 2 arrays, not just a NAS.

I used to see this frequently when relinking very large datasets, but not recently. Hypothetically it could be the difference between a brute-force sequential search for metadata in thousands of files vs an indexed Spotlight lookup.

Oliver is on a NAS and Spotlight indexes don't always work correctly there, but it's just speculation it's even using Spotlight. It could be something else. But it's a bug, not lack of a feature. It usually works OK but in some cases the relink performance falls off a cliff.


Re: Back to Premiere. sigh.
by Jeremy Garchow on May 4, 2020 at 12:35:51 pm

[Joe Marler] "Oliver was taking about an intermittent bug whereby you *can't* hit "choose". "

I see. I guess I’m lucky and I’ve never seen that.

I switch (or at least used to) switch between local and NAS a lot.

If I have the same master media files (and not transcodes) on each set of drives, relinking is usually only a few clicks away.


Re: Back to Premiere. sigh.
by Joe Marler on May 5, 2020 at 12:42:05 pm

[Oliver Peters] "...on this batch of revisions, when you try to follow this process, you can never stop the "looking for matching filenames." So at each step you get a spinning beach ball for a while until it to a point where it lets you go to the next folder."

I just noticed there was a fix in 10.4.1 which says: "Relink Files button highlights after selection, allowing you to press Enter to commit the command".

While that fix is vaguely worded, the problem I formerly saw might be described that way. IOW it would not wait to initiate the relink search until you pressed Enter - it would immediately start. This prevented isolating the relink search scope. However I think more was wrong than that, but fixes in release notes are not comprehensive.

I saw this problem frequently before 10.4, but I don't recollect seeing it since then, at least on locally-attached storage.


Re: Back to Premiere. sigh.
by Eric Santiago on May 5, 2020 at 12:49:20 pm

[Joe Marler] " I can combine multiple media trees from a NAS to a directly-attached RAID, change all the paths, and FCPX File>Relink Files will rapidly scan the entire volume and relink all the files."

This part I really love between the two.
I get a lot of odd drives from clients and when they tell me its a Premiere project, I have to add at least two days of lead time.
I have had mixed RED, Sony, EVA1, etc... footies in projects and FCPX always avoids the hassle when drives/media get moved.
For me, however, I use link and avoid proxies unless I have a lot of time in my hands and that's usually feature-length work.


Re: Back to Premiere. sigh.
by Tom Sefton on May 3, 2020 at 6:44:28 pm

I just don’t have the same issues at all with relinked media in fcp. Shared drive, unique raid, thunderbolt m2 drive - it’s just one click in relink and it finds the files immediately. If you want you can point it to one file and it auto finds all the others but it’s so reliable it’s one of my favourite features of fcp.

It’s even more impressive when working with postlab - one relink to a local drive when working from home and it’s done. Just can’t get on with premiere’s relink tool.

Co-owner at Pollen Studio
www.pollenstudio.co.uk


Re: Back to Premiere. sigh.
by Oliver Peters on May 3, 2020 at 7:04:24 pm

[Tom Sefton] "I just don’t have the same issues at all with relinked media in fcp. "

Obviously our experiences differ. I'm glad it works for you better than what I'm seeing. The experience you describe is how Premiere works for me ☺

Agreed on Postlab.

- Oliver

Oliver Peters - oliverpeters.com


Re: Back to Premiere. sigh.
by Oliver Peters on May 2, 2020 at 2:14:37 pm

[Tom Sefton] "Skim your play head around the timeline in premiere - it sticks to random sections like (molasses) and when you hit space bar it thinks. Not for long, but long enough for you to believe that something is happening...."

This is likely based on codec or maybe you haven't let it complete the building of cache files before starting. But I see these same issues with FCPX.

[Tom Sefton] "Just as a test I thought I’d sling the same footage at premiere that we are working on in fcpx. Multiple layers of 4/6K 60p ProRes 4444 footage with 2 colour adjustment layers on each, masks etc.. That....was hilarious."

A completely unfair comparison, because FCPX can take advantage of the Afterburner card and Premiere doesn't yet. Not the normal use case for someone with an older Mac Pro, iMac, or iMac Pro.

- Oliver

Oliver Peters - oliverpeters.com


Re: Back to Premiere. sigh.
by Tom Sefton on May 2, 2020 at 3:57:22 pm

Prores? That’s native for an apple machine and a supported mastering codec for premiere - it really shouldn’t be struggling with a single layer of footage at 2K resolution to playback. I’d be fine doing that on a MacBook Air with fcp.

The only ever time I see any non immediate response from fcp is with high resolution raw files when you have it set to best quality. I just can’t find any comparable level of performance between the two. Resolve is a close second to fcp at the moment, and it makes use of afterburner which is odd that premiere can’t?

Co-owner at Pollen Studio
www.pollenstudio.co.uk


Re: Back to Premiere. sigh.
by Oliver Peters on May 2, 2020 at 5:48:16 pm

[Tom Sefton] "it really shouldn’t be struggling with a single layer of footage at 2K resolution to playback."

No problem with Premiere either. I work with 4K ProRes on my mid-2014 MBP in Premiere without issue. Although 4K is a bit dependent on the drive in that case. 1080 or 2K, no problem at all.

I wonder if you are having a drive performance/optimization/cache issue? Is this on shared storage? If so, what sort of network? It could also be Catalina related. Just speculating, since I have thus far avoided Catalina.

- Oliver

Oliver Peters - oliverpeters.com


Re: Back to Premiere. sigh.
by Tom Sefton on May 2, 2020 at 6:38:33 pm

No just on a thunderbolt 2 attached Gspeed XL drive. Gets nearly 900MB/s and works fine in fcpx.

I can only think there must be something hellishly wrong with the install of premiere.

Quick workaround - xml to resolve.

Co-owner at Pollen Studio
www.pollenstudio.co.uk


Re: Back to Premiere. sigh.
by Oliver Peters on May 2, 2020 at 6:43:25 pm

[Tom Sefton] "I can only think there must be something hellishly wrong with the install of premiere."

Yes, there's something wrong that isn't typical.

- Oliver

Oliver Peters - oliverpeters.com


Re: Back to Premiere. sigh.
by greg janza on May 8, 2020 at 9:22:36 pm

[Tom Sefton] "If this was skimming over the actual 8K red rushes it might be acceptable, but this is 2K ProRes LT proxies - created in media encoder and stored in the root project folder called PROXIES."

If you're setup correctly, Premiere can be just as fast as fcpx. I've worked in fcpx enough to know what the real speed is and I can say that my workflow in Premiere is equally fast. Premiere is different than fcpx though in that you must have your system optimized.

All media cache needs to be on a separate drive from your main media and edit friendly proxies are essential.

What you're describing is not normal.

[Tom Sefton] "Skim your play head around the timeline in premiere - it sticks to random sections like (molasses) and when you hit space bar it thinks. "

Nope, it doesn't stick at all if your system is operating correctly. It's like butter with cineform, pro res or dnxhd media.

Perhaps it would be more helpful if you'd post your system specs. There's definitely a problem in your setup.

https://www.linkedin.com/in/tmprods
http://tallmanproductions.net


Re: Back to Premiere. sigh.
by Eric Santiago on May 11, 2020 at 11:57:35 am

[greg janza] "Nope, it doesn't stick at all if your system is operating correctly. It's like butter with cineform, pro res or dnxhd media.
"


I think its safe to say that we will all have different performance issues with whatever it is we are using.
My next big project will be Premiere on a new Mac Pro.
I should have some positive results from that.
On a different note, FCPX exporting RED 8K to ProRes444 on that VEGA II system is like butter ☺
No editing just export.


Re: Back to Premiere. sigh.
by Joe Marler on May 2, 2020 at 11:08:31 am

[Jeremy Garchow] "All I want for quarantine is better format relinking in fcpx."

Relinking in FCPX is both superb and terrible. Relink of regular media files on a single drive volume is superb - in fact it's fully automatic.

You could have 1,000 "in place" media files scattered across a huge RAID array, shut down FCPX, rename each file, move each file to a different location on that drive, then inside the library *delete* the symlinks to each of those files, then upon re-launch FCPX will automatically relink all the files and rebuild the symlinks. This is because the library not only stores the path but also the inode of each media file and uses that as a fall-back locator. Is there any other NLE that does this?

By contrast relink of proxies is terrible - in fact it does not exist.

In between those two extremes are other cases where FCPX relink doesn't work that well. E.g, if the media files are renamed after import *and* they are moved to another drive. Since inodes are only unique within a volume, it can't use that method. There are cases where relink requires doing one file at a time.

Obviously one answer is "just don't ever rename the files" after import, but there are reasons why this is done.

How does Premiere handle this? Say you commit a lot of work to a project, then transfer the data set to a NAS and as part of that move the media files are renamed. Can it batch relink the entire data set? When I formerly used Premiere it would not do that.


Re: Back to Premiere. sigh.
by Jeremy Garchow on May 2, 2020 at 12:02:01 pm

[Joe Marler] "Relinking in FCPX is both superb and terrible. Relink of regular media files on a single drive volume is superb - in fact it's fully automatic."

Depends on the format. R3d to mov? No prob.

Mov to mp4? Nope. Mxf to mov? Nope. Mxf to mp4? Nope. Mp4 to mxf? Nope. Mov to mxf? Nope.

Try it. Take an mxf file, make any file format you want with matching audio, and try to relink it, automatically. It won’t happen. But if you select the file one by one, fcpx will relink. So for a project with several thousand files, linking one by one is agony and far from automatic. Since fcpx will relink one by one and not automatically, this seems like a bug.

And as far as your sym link example, that works on some storage and not others.l, and yes it seems unique to fcpx.

Premiere allows you to search by other criteria, including media start and allows you to deselect criteria like file name and extension.

Fcpx is still much faster to work in though. I share all of Tom’s gripes with premiere, except format relinking. Premiere is better at this.


Re: Back to Premiere. sigh.
by Joe Marler on May 2, 2020 at 12:46:19 pm

[Jeremy Garchow] "Try it. Take an mxf file, make any file format you want with matching audio, and try to relink it, automatically. It won’t happen."

I just imported several MXF files using "leave files in place", shut down FCPX, renamed each file, moved each file to a new subfolder, then deleted the symlinks in the library which pointed to those files, and upon re-launching FCPX it automatically relinked them instantly and re-created the symlinks to the new locations and filenames.


Re: Back to Premiere. sigh.
by Jeremy Garchow on May 2, 2020 at 1:28:24 pm

[Joe Marler] "I just imported several MXF files using "leave files in place", shut down FCPX, renamed each file, moved each file to a new subfolder, then deleted the symlinks in the library which pointed to those files, and upon re-launching FCPX it automatically relinked them instantly and re-created the symlinks to the new locations and filenames."

Sure but that doesn’t help when you need to link to transcoded material.

It’s not about linking to the same files, it’s about linking to different files with the same characteristics (audio channels, tc, length) but different file extensions.

So if do you the same test, but transcode those files mov or mp4 first, you will not get fcpx to automatically link to anything but the original media (whether it's renamed or not).

Or, do an even easier test, Optimize the media and try to relink the MXF file to the folder of .movs created by FCPX automatically. It won't happen, you will only be able to relink one by one pointing fcpx at the exact file you are trying to link to. And doing that with the FCPX interface is extremely time consuming. So FCPX can't even link to the .mov media it creates from the master MXF files, which to me, makes exactly zero sense.

I cannot distribute the 50TBs of media on our server remotely and by staying at home (of which Chicago is on lockdown until at least the end of this month, and I would imagine it will get extended since the COVID infection numbers aren't going down), but I could do it if we could use proxy files. The ability to relink from other file formats to other file formats would be most welcome. So while, yes, inode linking can work, it only works in a very specific use case.


Re: Back to Premiere. sigh.
by Tom Sefton on May 2, 2020 at 1:52:46 pm

This works perfectly with r3d to .mov - I’m sure it did with mxf to .mov too the last time I did it.

Co-owner at Pollen Studio
www.pollenstudio.co.uk


Re: Back to Premiere. sigh.
by Jeremy Garchow on May 2, 2020 at 3:38:39 pm

[Tom Sefton] "This works perfectly with r3d to .mov"

Indeed it does. It’s the only one that works, and it might have to do with the red software “Apple workflow” component, but I’m not sure.


Re: Back to Premiere. sigh.
by Joe Marler on May 2, 2020 at 5:32:41 pm

[Jeremy Garchow] "Indeed it does. It’s the only one that works"

You are correct, the auto-relink based on inode is very slick but it only works within a single disk volume.

There are some cases where manual relink to externally-generated or transcoded files fails. It works with Sony XAVC-S .mp4 files, RED camera-generated proxies and others. It fails with MXF files and some old AVI DVC material I tested - even IF using proxies generated by FCPX itself and copied externally.

The reason seems to be a difference in audio metadata. Either the audio data in the original files is not written correctly or FCPX is simply mis-handling the audio in the transcoded file, or mis-handling the check itself. In some cases it inappropriately fails. Using Invisor's side-by-side comparison I can see some parameters of the audio are different between the original file and the proxy generated by FCPX - just blank in some fields.

In my MXF and AVI test files the audio plays OK in both original and transcoded files but during the relink FCPX complains "Incompatible file - the original file had audio, but the new file doesn't". The transcoded file has audio and it plays OK.

That's not a feature deficiency, it's just a bug. It should work.

I've also seen cases where media imported within an FCPX managed library will not allow relink to the original offloaded file, except one at a time. In this case it's not re-wrapped, the file was just copied to the library and renamed by FCPX during import.

Unfortunately the media file header is not composed of neat alphanumeric fields that you could easily tweak with a hex editor but includes complex, conditionally-encoded binary values: https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/QTFFChap3/qtff3.html#//apple_ref/doc/uid/TP40000939-CH205-75770

There is another half-implemented undocumented feature that indicates Apple has worked on this but not to completion: You can move media files to a new drive then create Finder aliases via OPT+CMD drag and copy those to the symlink folder within the library, and usually FCPX will re-read those and generate updated symlinks. But it doesn't always work.

Everybody complaining about this is correct -- this entire area needs a lot of work. Unfortunately both Apple and much of the FCPX community places a lot of emphasis on visible user-facing features, but there are poorly implemented system-facing issues that need major work.


Re: Back to Premiere. sigh.
by Tangier Clarke on May 14, 2020 at 5:30:43 pm

I feel your pain. Working in PPro coming from FCP X is agonizing except for a few features that I really like in PPro. I am on a project now having to use it.





© CreativeCOW.net