Exporting FCP XML from Premiere is a dead end

To give credit where one is due, the creators of Final Cut Pro did create one of the more popular standards of exchanging the project information, alongside the old EDL, and Avid’s AAF and OMF. Exporting XML from FCP was very versatile and allowed for various workflows to appear, passing data from FCP to Soundtrack Pro, and Color, but also to many other applications from vendors other than Apple.

For many years Adobe also tried to implement project sharing via exporting to AAF, and FCP XML. However, the exporting and reimporting still remains a pretty troublesome process, regardless of how much Adobe touts their horn. Many transitions can’t be converted, most of the effects do not translate, and there are problems with stills, time remapping, and Dynamic Link compositions. Not ideal under any circumstances.

People accustomed to XML interchange push Adobe to do a better job in this exporting – rightfully, especially in the short run. However, being so focused on their workflow, they seem to be unaware that there seems to be a better option, right around the corner, and that even Apple already considers FCP XML a legacy. The more time passes since the demise of FCP 7, the more constraining FCP XML will become, and with no support in development from Apple, the stagnant standard will at some point become problematic.

This is where the unrealized potential of Adobe Premiere comes in. Many people are not aware of the fact that Premiere’s project files are already XML! There is no need to export anything anywhere, the file is easily readable – and writeable! – by any application. Of course, it is not compatible with FCP’s implementation of XML, and its documentation is not publicly available in any way, but – as I wrote in a few of my earlier posts – the basis for the universal interchange container are already in place. The only thing that stops other vendors from accessing Premiere files is the lack of specification and – more likely – lack of demand from the users and lack of aggressive promotion of this de facto standard on the part of Adobe.

Therefore, instead of putting most resources into – mostly futile – attempts to translate Premiere sequences into FCP XML sequences to make them readable by other applications, why not promote Adobe XML standard that is already present?  This way we would get rid of numerous hurdles on the way, avoid all the problems and limitations of FCP XML, and in the end create the possibility for new, more flexible workflows.

Are you listening, Adobe?

Tagged , , , . Bookmark the permalink.

9 Responses to Exporting FCP XML from Premiere is a dead end

  1. David McGavran says:

    David McGavran here, Engineering Manager for Adobe Premiere Pro. While you theory is nice and could in a perfect would be quite useful, unfortunately it won’t work as you suggest. Our project file is xml but it is not designed as xml that can be shared or edited by others. It has a lot of fragile binary data and dependencies in it. Most efforts to change any of that data will lead to a corrupt project. FCP XML and AAF were designed to be shareable formats and we strive to support those in a robust way. If you have bugs please report them to us.

    Thanks

    Dave

    • Bart Walczak says:

      Hi David,

      Thanks for your feedback, this is much appreciated. I understand the problem of dependencies, and this is indeed unfortunate. That does not preclude other apps from reading the file though, if the specs were available. At least this side of the equation could have been solved, even if writing by third party is not possible (how about Audition or Speedgrade though?)

      I also understand that changing paths to media files in the project file can be done without much danger (I’ve done it myself in a text editor, when I got tired with clicking).

      I will still maintain my position that you should promote your own standard for exchange instead of relying on something that seems to be left out in the void by the main developer, and which seems to cause headaches when more complicated edits are concerned. You seem to be doing pretty well within the Suite.

      As far as bugs in FCP XML export go, there is nothing you are not already aware. It’s just the whole process of conforming that makes it cumbersome, especially if Premiere or After Effects specific features are used. Also, bringing XML back to an old project tends to be pretty messy.

      • David McGavran says:

        Hi Bart,

        You make valid points that having good full featured interchange formats are very important. Yes some people have had minor successes like changing paths but to add a formal spec to our project format unfortunately wouldn’t work. In fact changing paths can itself lead to problems if you change media types or something like that. (not simple from folder a to folder b) Thanks for your feedback and we will continue to stress open interchange formats.

        Cheers

        Dave

        • Bart Walczak says:

          Hi Dave,

          OK, I understand the limitations. Still not totally sold on the reading part, but I see where you’re coming from.

          I must have been lucky then. I changed media types from XDCAM EX in mp4 wrappers to transcoded uncompressed MOV files – something that requires at least a click for each file in Premiere due to a different file extension. Frankly I was sure it wouldn’t work, but it did, and saved me quite some time.

          At least I can hope scripting is going to be implemented at some point.

          Your feedback is much appreciated.

  2. Michael Nolting says:

    Bart you are a genius.
    I have been stressing on finding a way to get chapter information from FCP 6 into Premiere Pro since going to HD.
    FCP is very good at producing an XML export of the project information but , as you have said, Premiere is poor at implementing the information.
    I did not know that Premiere project file was XML!
    Now, all I need to do is write me a visual Basic application to read my FCP export and create the nodes in the Premiere project file.
    I am quite certain that this should be a safe thing to do, after all, its an XML file.
    Mike

    • BartW says:

      Thanks. Remember, that from CC upwards the project files are zipped. Also, always make a copy of your PPro project file, because it is prone to corruption if things go wrong. But I guess you already know that :)

    • Michael Nolting says:

      Bart,
      I may have spoke too soon about my elatement.
      I have an Encore chapter marker at 00;04;43;19 duration of 00;00;00;01
      In the xml file the node PremierData/Marker/Time is 72051646867200
      This is not anywhere near the number of frames (8509)
      Dave Please……
      Mike

      • Michael Nolting says:

        OK,
        Its frames time a constant value of 8475667200
        However, I need to figure out how many frames are dropped in a given set of time.
        At 30 min of video, my calculation was off by 4 seconds (too high)

        • BartW says:

          Premiere’s tick is both simpler, and a bit more complicated. The calculated value 8475667200 is valid for 29.97 fps, but with the original definition of this frame rate, being 30 000 / 1001, which does not precisely equal 29.97. So you should use the fractional definition to calculate your exact timecode.

          In general, the “tick” base equals 254016000000 and if you divide it by fps, you should get the number that is equivalent to how many ticks you get per frame. It should be an integral number for most calculations (it was chosen as the least common multiple of various audio and video frame rates).

Leave a Reply