Why your Premiere conform is broken (and where the frames go)

You send the XML. The colourist imports it into Resolve. They call you twenty minutes later. “Your timeline is 50fps.” You check the sequence settings. 1080p25, progressive, no fields. You exported correctly. You did everything right. And the conform is still broken.

This is one of the most persistent problems in professional post-production. Premiere Pro’s FCP7 XML export contains bugs that have been documented by colourists, conform artists, and finishing editors for over a decade. Some are fixed. Most are not. All of them cost hours.

This post maps the specific failures, explains the mechanics behind each one, and describes the workarounds that working professionals actually use. If you have ever had a conform fall apart after leaving Premiere, you will recognise some of these.

The landscape of a Premiere conform

The conform is the moment where editorial decisions meet original camera media. The editor works with proxies or transcoded dailies. When the cut is locked, the timeline description travels to the colourist or finishing house, where it is matched against the high-resolution source files. The format that carries this description is usually one of three things: an EDL, an AAF, or an XML.

From Premiere Pro, the standard export for grading handoff is FCP7 XML. This is Apple’s XMEML format, originally designed for Final Cut Pro 7. Premiere adopted it as its primary interchange format because the ecosystem already supported it. Resolve, Baselight, Flame, Hiero, and Scratch all read it. The format handles multi-track timelines, nested sequences, speed changes, and transitions. On paper, it is the right tool for the job.

In practice, Premiere’s implementation of the FCP7 XML export has a cluster of bugs that affect timing, frame rates, and metadata accuracy. The bugs are not theoretical. They show up in real conforms, on real schedules, with real budgets attached.

The seven bugs

The interactive table below summarises the known issues. Click any row for a longer explanation of the mechanism.

Three of these are critical. They do not produce subtle errors. They produce conforms that are visibly, obviously wrong in ways that halt the grading session.

Bug 1: Your 25fps timeline becomes 50fps

This is the one that generates the most support tickets. In Premiere Pro 25.0 and 25.1, exporting a progressive 25fps sequence via FCP7 XML writes the field dominance metadata incorrectly. Instead of fielddominance=none (progressive), it writes fielddominance=lower (interlaced, lower field first).

Every downstream tool that reads this XML does the correct thing with the incorrect data. When Resolve sees fielddominance=lower at 25fps, it interprets the content as 25fps interlaced, which is 50 fields per second. It creates a 50fps timeline. Baselight does the same. Flame does the same. The tools are not wrong. The XML is.

The bug only affects sequences created from scratch in Premiere 25.x. If you opened a project originally created in version 24.x, the export was correct. Adobe fixed it in version 25.2 (build 10), but the fix only applies if you update and re-export. Every XML that left a 25.0 or 25.1 installation carries this error.

The same bug also affects 29.97fps progressive sequences. The field dominance is written as lower even when the sequence is explicitly set to “Fields: No Fields (Progressive Scan).”

The fix is a single find-and-replace in a text editor: change <fielddominance>lower</fielddominance> to <fielddominance>none</fielddominance>. But you need to know the bug exists before you think to look for it.

Bug 2: The silent drift at 23.976

This one is worse in some ways because it does not announce itself. It starts quiet and gets louder.

In the FCP7 XML format, the difference between true 24fps and 23.976fps is encoded by a single boolean flag called ntsc. When ntsc is TRUE, the frame rate is reduced by the familiar 0.1% NTSC factor: 24 becomes 23.976, 30 becomes 29.97, 60 becomes 59.94. When Premiere exports a 23.976fps sequence with ntsc=FALSE, every downstream tool reads it as true 24fps.

The rate error is 24 / 23.976 = 1.001001. That is a drift of approximately one frame every 42 seconds. On a 30-second spot, you will never notice. On a feature film, the numbers look like this:

Try selecting the 90-minute preset. By the end of a standard feature, the conform has drifted by roughly 128 frames. That is 5.3 seconds. Dialogue is completely out of sync with picture. Cuts land in the wrong place. And because the drift is gradual (linear over the programme length), the first reel might look fine during a spot check. The problem only becomes obvious in the back half, by which point the colourist may have graded 40 minutes of material against a timeline that was never correct.

Bug 5: The speed change trap

This is the hardest bug to diagnose because it only affects some clips on the timeline.

When Premiere exports an XML containing clips that have been retimed (speed changed), it bakes the frame rate conform into the speed value for those clips. If a 50fps clip is conformed to 25fps (a 50% speed interpretation) and then the editor applies an 80% creative speed change, Premiere writes a speed of 40% into the XML. It multiplied 80% by the 50% conform factor.

The problem: Premiere does not do this for clips that have not been retimed. Non-retimed clips export with their raw durations, and the downstream tool is expected to apply its own frame rate conform. This creates an inconsistency within a single timeline. The grading tool re-applies the conform to everything, which is correct for the non-retimed clips and wrong for the retimed ones. The retimed clips end up playing at half their intended speed.

This compounds with nesting. If the retimed clip is inside a nested sequence, each nesting level can introduce its own conform factor. The result is clips playing at speeds that bear no obvious relationship to the editor’s intent.

The workarounds people actually use

The community has developed a set of survival strategies, none of them elegant.

Manual XML editing. Open the XML in a text editor, find-and-replace the broken values. This works for the field dominance bug and the ntsc flag. It does not help with speed change interactions or frame rounding errors, because those require understanding the relationship between specific clips and their source media.

Export as EDL instead. Many colourists now request EDLs from Premiere editors specifically because the EDL format is too simple to carry the bugs. An EDL is just a flat list of timecodes and reel names. No field dominance metadata. No ntsc flags. No speed effect encoding. The limitation is real: EDLs support a single video track, no speed ramps, and the CMX3600 format truncates filenames to eight characters. But for a single-track cutlist, the EDL arrives intact when the XML does not.

Export as AAF. The Advanced Authoring Format uses a completely different encoding and avoids most of the FCP7 XML bugs. Several professionals report that AAF exports from Premiere handle 25fps progressive content correctly where XML fails. The tradeoff is that AAF files are binary, harder to debug, larger, and not universally supported (Flame, for example, prefers XML or EDL).

Flatten retimes before export. For the speed/conform interaction bug, the workaround is to duplicate the sequence, render all retimed clips in place, replace them with the rendered versions, and then export. This removes all speed effects from the XML, avoiding the double-conform problem. It also destroys the editor’s ability to adjust retimes after handoff, which is sometimes acceptable and sometimes not.

Always send a reference render. This does not fix any bugs. It lets the colourist detect them. Export a low-bitrate H.264 alongside the XML. The colourist plays it against the conformed timeline and spot-checks every cut point, speed change, and in/out transition. If something does not match, they know before they start grading.

Launder through Resolve. A surprisingly common workflow: import the broken Premiere XML into Resolve, let Resolve partially correct the errors during import, then re-export a new XML from Resolve. Resolve’s XML writer is more spec-compliant than Premiere’s. This adds a step and can introduce its own rounding errors, but it often produces a usable result.

Why the standard format is not standard

The root of the problem is that FCP7 XML is not Premiere’s native format. It is a translation layer. Premiere converts its internal timeline model (which uses a tick-based time system with 254016000000 ticks per second) into Apple’s frame-count-based XMEML schema. Every translation is lossy. The bugs documented above are places where the translation goes wrong.

Adobe knows about these issues. The field dominance bug was fixed relatively quickly once it was reported. But bugs 3, 4, 5, and 6 have been present since at least CS6 (2012) and remain unfixed in the current stable release. The timecode string mismatch and the displayformat error are so long-standing that the community treats them as known constants rather than bugs.

Adobe has introduced OTIO (OpenTimelineIO) export in the Premiere Pro beta channel. This is a promising direction, but as of early 2026 it is not in the stable release, and the beta implementation has its own metadata fidelity issues: clip names revert to original filenames on roundtrip, and tape names are lost entirely. For now, FCP7 XML with manual corrections remains the standard path.

What a proper correction layer looks like

The right solution is not to fix XMLs by hand. It is to build a parser that knows about Premiere’s specific failure modes and corrects them programmatically during import.

A Premiere-aware conform tool needs to do five things:

1. Detect Premiere origin. Premiere embeds proprietary attributes like MZ.Sequence.VideoTimeDisplayFormat in its XMLs. If these are present, the tool activates correction mode.

2. Fix field dominance. If fielddominance is lower or upper but the timebase is 25 and the source media is progressive, force it to none.

3. Fix the ntsc flag. Cross-reference the declared frame rate against the source media (via probe data). If source files are 23.976 and the XML says true 24, correct the flag.

4. Ignore displayformat. Never trust the DF/NDF indicator from Premiere. Derive it from the rate and the proprietary MZ.Sequence.VideoTimeDisplayFormat code if available.

5. Use frame counts, not strings. Always compute timecodes from the <frame> element and the rate. Never trust the <string> element.

This is the approach we are building into Muster’s conform engine. The goal is that a colourist who does not own Premiere, and should not need to, can import a Premiere-originated XML and get a correct timeline without manual intervention.

The broader lesson

Premiere Pro is the most widely used NLE in the world. Its XML export is the primary interchange format for tens of thousands of conform workflows every year. And it has had documented, reproducible timing bugs in that export for over a decade.

This is not a Premiere-specific failing. It is a structural problem with interchange formats that are translations rather than native representations. Every NLE-to-grading-tool handoff involves a lossy conversion, and the bugs live in the gap between what the source application means and what the target application reads. The only reliable defense is a correction layer that understands both sides of the conversation.

If you are an editor sending XMLs to a colourist: always include a reference render. If you are a colourist receiving XMLs from Premiere: check the field dominance, check the frame rate, and never trust the timecode strings. If you are building tools that parse these files: trust the frame counts, probe the source media, and assume the metadata is guilty until proven innocent.