3 Replies Latest reply on Nov 2, 2013 6:14 PM by shooternz

    Premiere Pro edit with time remapping: XML to Resolve issue

    billyphoto Level 1

      I think I know the answer to this, but I thought I'd check here before trying a drastic work around.


      I've just finished a rough cut with lots of speed ramping in and out of cut points. Probably half of the clips in the two and a half minute sequence have some sort of time remapping on them.


      I'll be sending this edit to my colorist who is working on Resolve 9. Some early tests with XML exports from Premiere have been less than successful in terms of my timeline reproducing properly in Resolve.


      The clips all show up in the Resolve timeline, but the in and out points are wildly off. I did a test of the same XML that I exported from Premiere, back into Premiere and I see the same errors. Then I noticed that the XML sequence imported back into Premiere was missing all of the time remapping.


      My conclusion (and the conclusion out there on the internet) is that Premiere does not observe time remapping when exporting an XML. It simply uses the in point timecode of each clip in the edit and assumes it's running at 100% speed. The edit durations are all correct, but the clip within each edit is not playing back as it was time remapped in the original edit.


      It appears the only work around for this, unless I've missed something on the many Premiere and Resolve forums I've been visiting the past week, is to export a "flattened" master edit as a self contained single file, which would become the only media I would be delivering for color grading. Import that back into Premiere and slice the edit up with the Cut tool and export an XML of that as a courtesy to my colorist so she doesn't have to blade every edit in Resolve.


      By simplifying my edit and basically sending her a single master edit mov file or dpx sequence with all of the speed time remapping changes baked in and an XML that now has no time remapping or speed changes in it, but is sliced up by scene, it appears we can avoid the XML time remapping issues.


      The rather major downside however is, I'll have no handles on the individual clips (unless I go through the time consuming process of creating handles in a copy of the original master edit timeline), should I have to slide anything in the edit a frame or two here and there or finesse a speed change. We all know that a "locked" edit, is rarely so.


      Am I correct in my conclusion that any edit sequence with time remapping in it is not going to be able to be exported with an accurate XML, relinking to original media? I will have to disregard the original media and simply send her the final edit as a single exported QT or DPX file? That would be a shame, as it's always best to grade from original media files. It would also add a considerable amount of time to the conforming process.


      At this point I'm very tempted to create a copy of my rough cut edit, remove all of the time remapping, add handles to every edit and use that as the single media file she'll work from. When she finishes her grade, I'll reverse the process: Remove the handles and reapply time remapping, to every single clip that requires it. Not even close to an efficient workflow, but at least I'll have some flexibility, if needed, between the color grade and final conform in Premiere.


      EDIT: I just thought of another option. If I simply remove all time remapping from the original edit and export an XML from that now much longer edit, she can still work from the original media and give me handles on her output. It will simply be a much messier conform on my end during final assemble. That might be a better option than the "flattened master" idea.


      Any confirmation, thoughts or suggestions are welcome. Thanks for reading all of this.


      Billy Sheahan

      Chicago, IL


      p.s. Yes, I know the workflow might work better with the new Direct Link to SpeedGrade, but asking my colorist to learn new grading software simply to avoid this XML issue is... well... that's not going to happen!


      Message was edited by: Billy Sheahan


      Message was edited by: Billy Sheahan