How To Fix Hiero XML Export For Premiere… Sort Of


Some time ago, if you ever tried to export XML from Hiero to Premiere, you got a generic importer error message and that was it. This issue – audio related – was thankfully fixed in later versions of Hiero. However, another hydra reared its ugly head, and this time attempted XML interchange resulted in something along these lines: see more

Adobe Media Encoder Grows Up


Adobe revealed today, that Adobe Media Encoder will receive a few very worthwhile updates, including long awaited GPU acceleration, direct implementation of Premiere Pro engine, and a number of new features. There are two, which are of special interest to me: the so-called mini-pipe – adding new effects such as image overlay, timecode burn-in, or a given SpeedGrade look – and the ability to import FCP XML sequences without the need to pass them through Adobe Premiere. Both have potentially important workflow considerations in the long run.
see more

Continuing Premiere’s FCP XML export woes…

If you are familiar with my recent complaint about the issues with FCP XML export, let me throw two more problems into the mix. They might not be as important as the drop and non-drop frame issue, because no data is lost in the process, and they are fixable, although they might be quite an annoyance.

After fixing the problem with exporting zero-marker duration, we shall find out two things:

  1. Although subclips are correctly exported to FCP XML, for some reason Premiere creates additional markers in the main clip which span through the whole duration of each subclip…
  2. …but in each subclip, each marker’s in point is wrongly calculated, and their positions change, often beyond the subclip’s borders.


There’s a clip that has 1 marker in it, and 1 subclip. The subclip starts at a frame 228, and ends at the frame 645 of the main clip. The marker starts at frame 355 and ends at 528. After export, you will get:

  • 2 markers on the main clip:
    • 355-528
    • 228-645
  • 2 markers on the subclip:
    • 355-300 (sic!)
    • 228-417

And what you should get:

  • 1 marker on the main clip: 355-528
  • 1 marker on the subclip: 127-300

I think you have already figured out, what’s going on – the subclip’s offset is not removed from marker’s in point. As I said – hardly a big problem. Merely an annoyance. But it requires a tool to fix it if you are using certain kind of workflow: the subclip-spanned markers should be removed, the real markers’ in points in subclips recalculated.

Depending how you look at it, the fact that the very same errors are present in FCP XML exports from Prelude, can be either disheartening – because you’d think it’s such a basic functionality that somebody should have had noticed in in the production stage – or encouraging – because if they fix it in Premiere, they will also fix it in Prelude.

On a positive note – I’ve been in contact with Jesse Zibble from Adobe about XML export in general, and I know they have been working on these issues. But judging from the release cycle of previous bug fixes, I don’t think this is going to be amended in the current release.

All of us not using Creative Cloud yet, feel free to express your disappointment now. And if any of you needs a tool to fix these markers, drop me an email.

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.

Premiere Pro doesn’t export markers of 0 duration to FCP XML

While doing research for a commission that I recently received, I found out that Premiere Pro CS6 does not export markers of 0 duration to FCP XML. This proved to be a bit of a surprise, and also turned out to be a major flaw for the software that I am supposed to develop.

I had to find out the way to automatically convert all the markers into the ones with specified duration. Fortunately, as I wrote many times, Premiere Pro’s project file itself is an XML. Of course, as it was kindly pointed out to me, it’s pretty complicated in comparison to the exchange standard promoted by Apple, however it is still possible to dabble in it, and if one knows what one is doing, to fix a thing or two.

Marker duration proved to be a relatively uncomplicated fix.

In the project file, markers are wrapped into the <DVAMarker> tag. What is present inside, is an object written down in JavaScript Object Notation. I’m not going to elaborate on this here, either you know what it is, or you most likely wouldn’t care. Suffice to say, that the typical 0 duration marker looks like this:

<DVAMarker>{“DVAMarker”: {“mMarkerID”: “3cd853f0-c855-46de-925c-f89998aade87″, “mStartTime”: {“ticks”: 6238632960000}, “mType”: “Comment”}}</DVAMarker>

and the typical 1 duration marker looks like this:

<DVAMarker>{“DVAMarker”: {“mComment”: “kjhkjhkjhj”, “mCuePointType”: “Event”, “mDuration”: {“ticks”: 10160640000}, “mMarkerID”: “7583ba75-81f5-4ef2-a810-399786f3a75d”, “mStartTime”: {“ticks”: 4049893512000}, “mType”: “Comment”}}</DVAMarker>

As you can see, the mDuration property is missing in the 0 duration marker, and the duration 1 marker is also labeled as “Event” in the “mCuePointType” property. It turns out, that it is enough to insert the following string:

“mDuration”: {“ticks”: 10160640000},

right after the second curly brace to create the proper 1 frame marker that gets exported. You can do it in your favourite text editor yourself, and then the corrected marker would look like this:

<DVAMarker>{“DVAMarker”: {“mDuration”: {“ticks”: 10160640000}, “mMarkerID”: “3cd853f0-c855-46de-925c-f89998aade87″, “mStartTime”: {“ticks”: 6238632960000}, “mType”: “Comment”}}</DVAMarker>

Granted, it’s a bit tedious to do it by hand for hundreds of markers (as was my client’s request), and unless Adobe decides to fix it in the near future (I already filed a bug report), or Josh from releases it first on his own, some time at the beginning of the next year I might have a piece of software that will automatically convert the 0 duration markers to 1 frame ones, so that they get easily exported to FCP XML. I understand that this is a pretty rare problem, but perhaps there are a few of you who could benefit from this solution.

The main bugger? Most likely it will be Windows only, unless there is specific interest for the Mac platform for something like this.