Premiere’s FCP XML sequence timecode export is a mess

It is. A real mess for all of people who have to deal with drop frame vs. non-drop frame timecode.

Having lived in the PAL land, where we’re lucky to never have to bother with this issue I have not realized until recently how awful Premiere Pro is at exporting proper attributes to FCP XML.

In the FCP XML specification there are four main tags that should describe how sequence’s timecode should be handled. All of them are present in the <timecode> tag contained within the <sequence> tag.

First: <rate> tag contains <timebase> which should give you the base frames per second, and the optional <ntsc> tag which is an indicator, whether the 30 fps means really 30 fps or 29.97. This one seems to be encoded properly.

Second: <displayformat> should tell you, whether the timecode is drop frame (“DF”) or non-drop frame (“NDF”). It seems to be totally ignored, but in an inconsistent fashion. For 29.97 it always encodes “DF”, regardless of what type of timecode is used. For any 23.978 and true 24p, as well as for any 59,94 it always encodes “NDF”.

Third: <string> which should also be a way to obtain the information about drop and non-drop frame timecode, always gets encoded with semicolons in case of 29.97, but with colons otherwise, including 23.978 and 29,97 with 3:2 pulldown. Wow. If that wasn’t enough, the tag should also properly encode the sequence starting point, and it mostly does… unless you work in 29.97 non-drop frame, in which case the 1:00:00:00 mark gets mysteriously converted to 1;00;03;18, or in 59.94 drop frame, when it becomes 00:59:56:24.

Fourth: <frame> should give you the sequence starting points in frames, and it looks like at least this one works fine, and gets actually encoded with proper values reflecting drop frame or non-drop frame timecode base.

The only way to obtain proper information about drop and non-drop frame timecode is to use the non-standard attributes that Premiere adds to the <sequence> tag, namely “MZ.Sequence.VideoTimeDisplayFormat”. But even here the values seem to be case specific:

  • 100 is a true 24 fps
  • 101 is a true 25 fps
  • 102 is a drop frame 29,97
  • 103 is a non-drop frame for 29,97 or 3:2 pull-down for 23.978
  • 104 is a true 30 fps
  • 105 is a true 50 fps
  • 106 is a drop frame 59.97
  • 107 is a non-drop frame 59.97
  • 108 is a true 60 fps
  • 110 is 23.978

Also you need to be aware, that on importing FCP XML Premiere does seem to first intrepret the <rate> tree with <timebase> and <ntsc> tags, and only then resorts to the MZ.Sequence… atribute to get the proper drop or non-drop frame attribute. Bad, bad Premiere. Why don’t you play well with others?

And to add two insults to the injury: this is only the case for Premiere CS6. Out of curiosity, I imported all the various frame rate sequences into Premiere CS5.5 via FCP XML, and it did not recognize the non-standard attributes at all. Bad, bad Premiere. You don’t even play well with your older mates! The last straw? Exporting FCP XML from Premiere Pro CS5.5 does not give you ANY indication whether the timecode was drop or non-drop frame. The information is simply lost in translation.

Update: The worst news is yet to come: every single clip has the same problem, and there is no additional data to recover the information from. If your footage was recorded with non-drop frame, it gets exported to FCP XML as a drop frame.

It’s no wonder that other software has problems interpreting Premiere’s FCP XML export, when even such a basic thing as timecode base is bug-ridden. And by the way, Avid export and import do not seem to fare that great either.

Tagged , , , . Bookmark the permalink.

5 Responses to Premiere’s FCP XML sequence timecode export is a mess

  1. Jesse Zibble says:

    Hi Bart,

    Thank you for the information. We will look into this.

    -Jesse Zibble
    Adobe Premiere Pro Engineering

  2. Andrew says:

    Bart, found this link from your bug filed with Adobe. I too am experiencing this same thing with working with XMLs between FCP and CS6. It is a mess as you say. Another weird thing I’m seeing is that clips that are non-drop, when imported into Premiere Pro CS6 is that they don’t match what was imported into FCP. Is it fair to say that Premiere when importing clips that are non-drop is somehow treating it as drop frame, even though it keeps the colon (:) on all clips?

    • BartW says:

      Ah, interesting. I didn’t have an opportunity to test it the other way. I’d have to see the XML exported from FCP to say for sure, but possibly Premiere only looks for tag to determine both the frame rate and drop vs non-drop frame timecode, and to to determine the delimiter (colon). It would make no sense whatsoever.

      If you look at the timecode of the imported clips, do you see the dropped frames on the timecode with colon? If so, then it is a very strange bug, and it never should have happened. If not, then the clip is indeed reinterpreted as non-drop, and since all edits in XML are counted in frames, then every cut will most likely be misinterpreted. One way or another, it doesn’t hurt to report the issue.

      As you can see from the comment above, Jesse is already aware of the issue, and hopefully we shall see the correct interpretation and export in the next release.

  3. GZ says:

    At a client’s request I’m exporting 1080p25 NDF footage edited in Vegas as 1080i59.94 DF from DaVinci Resolve.
    I create the Resolve project as 59.94 interlaced WITH drop frame, input the progressive ndf 25fps footage, and then export it as 59.94i

    It seems to have worked fine but in MediaInfo I see three different time codes, two of which are DF (as required) and the third one is NDF.

    I haven’t been able to find MediaInfo documentation to see what those fields mean, so I don’t know if I have managed to do what I set out to do or not.

    Other #1
    ID : 901-Material
    Type : Time code
    Format : MXF TC
    Time code of first frame : 01:00:00;00
    Time code settings : Material Package
    Time code, striped : Yes

    Other #2
    ID : 901-Source
    Type : Time code
    Format : MXF TC
    Time code of first frame : 01:00:00;00
    Time code settings : Source Package
    Time code, striped : Yes

    Other #3
    Type : Time code
    Format : SMPTE TC
    Muxing mode : SDTI
    Time code of first frame : 00:59:56:24

    This third one starts at that weird place like your 59.94 case, and is NDF for some reason.

    I have no idea what’s going on.

    If someone can help me figure it out it would be great.

Leave a Reply to BartW Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.