Premiere and Speed changes...
I posted the below in the Premiere forum a couple days ago and there has been no comment... Any chance anyone here has any idea of a workaround that is not a Preconform?
Hoping you swell Premiere folk can help me out. I received a Premiere CC RED project for a Resolve finish recently.
I first used the XML provided from Premiere and 90% of the timeline was totally off the mark.
I then tried running the XML through FCP7, tried an EDL and tried an AAF, all of which resulted in the same exact timelines.
So I switched form looking at what Resolve was doing wrong and started looking at Premiere. I am not a savvy Premiere user, but I found that every time a clip was retimed the TC appeared to change also. I don't mean in the standard "fit to fill" lose/gain a frame do to the math of retiming. I mean TC offset.
Normally this would be no big deal, since most timelines have few enough speed changes to be an issue. On this shoot though, they shot almost exclusively @ 120, so they always had the slow-mo. So almost every single shot was a speed effect.
Here is a screen grab showing the type of offset, which happens to not be consistent, I am observing.
Link for screen grab.
Has anyone seen this before? I would really like to give these guys a solution for future work, we had to work off of a high res export for this one...
eric b johnson
online editor | colorist | workflow
You're describing the story of my life over the last few months.
The XML that is created by PP is totally wonky if speed changes are involved. And even sometimes when no speed-changes are in there at all!
The only way I've been able to make things work without committing suicide was to end up creating a clean EDL by razor-blading every cut from the original edit onto a flattened render of the program.
You loose access to raw that way, unfortunately. But by doing your primaries pre the flattened render you should be good to go. Not ideal workflow at all. But at least it's fool proof.
IMHO PremierePro XMLs are useless for complex edits.
One thing I've yet to try is to take the XML into FCPX and exporting the XML from there with the hope that you'll get a healthy XML... You might want to give that a try...? Let me know what you find?
The issue, at least as I've observed it, is not the XML/EDL/AAF's produced by Premiere. In this case, they all generated an incorrect timeline. In exactly the exact same state of incorrectness. I also "rinsed" the XML through FCP7 and received the exact same results. I opened the XML, from CC (what the client was working in) in my CS6, and had exactly the same incorrect timeline.
The files also, accurately matched the INCORRECT TC's represented in the Source monitor as shown in the screen grab from the original post. So the issue must occur prior to the XML/EDL/AAF generation.
The issue, again as I've observed, appears to be how Premiere is applying the speed change. And if it is the case that inconsistencies are coming up in media without speed changes, then there is an issue with how Premiere is dealing with TC/Frame information.
I WAS able to use the EDL created from Premiere to create a preconformed timeline, but I had to then force conform every shot... pretty much the same amount of work as Blading each cut... but at least the "RECORD" TC's for the EDL were representative of reality, even if the "SOURCE" TC's were scattered to the wind...
eric b johnson
online editor | colorist | workflow
I had the same issue this summer. You're right that the speed changes don't come threw the XML. Yes, the best thing you can do is export a flattened file of the speed change and conform that clip inside Resolve. If you're not using your hi-res media in Premiere and are working proxy then you can send that clip to AE using Dynamic Linking and option + replace the proxy clip with your RAW file. While you're at it you can run optical flow before you render out your clip to Resolve. If you have a lot of shots it can take you a little time but at least you won't have a problem with your edit coming back from Color.
Jordan Mena | Editor | Colorist | Producer
Los Angeles, CA
Hi Jordon, i know this is a old(ish) thread any chance you could break the your work flow down step by step, im going to be worked with R3D files and the test i have done have the same problem that Eric has. The plan is to do the grade in Resolve and i would like them the have both the time remapping and be able to grade with he R3D files at the same time, this is the only message/web page that i have found with any sort of solution!
I'm having the same Premiere time-remapping XML to Resolve issues, so I'll be keeping an eye on this thread to see if anyone has any solutions.
Currently, my workaround to avoid creating a single flattened master export file to grade from, is to make a copy of the edit sequence in Premiere, remove all time remapping from clips (lengthening the overall sequence) and depending on the situation, adding handles to each edit. Then I export an XML from that edit, which has no speed gymnastics to sully the XML. That way, my colorist can still grade from the original media.
It's a messy and painful conforming process, about as far from efficient as it could be, but it seems to work. And I'm not cringing that I'm grading from media files that have been dumbed down before grading.
Billy Sheahan Photography/Curious Visuals