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.