FCPXML vs Premiere XML: what each interchange format actually carries

Two files, one job — and one dead application

An interchange XML answers the question an ALE cannot: not just what the clips are, but how they relate — which recorder track is married to which camera clip, which angles form a multicam group, what order the timeline plays in. The XML never contains media. It contains references — names, paths, reels, timecodes — that the receiving NLE resolves against the actual files, which is why the identity triple of filename, start timecode and reel matters more than any other property in the file.

The two dialects come from the same family tree. Final Cut Pro 7 defined xmeml, and when Apple rebuilt Final Cut from scratch in 2011 it replaced the format wholesale with FCPXML. The industry, meanwhile, had standardised on the old dialect: Premiere Pro adopted FCP7 XML as its de facto interchange format — which is why everyone calls it “Premiere XML” today — and it froze in time. One format has evolved through a dozen versions since; the other has been stable for fifteen years precisely because its parent application stopped changing it.

How each file thinks

Open both files in a text editor — like an ALE, being readable is half their value — and the difference in worldview is immediate.

FCPXML is a database with references. The file opens with a <resources> block declaring every format, asset and effect once — a format resource pinning frame size and frame duration, an asset resource per media file with its URL, timecode and audio channel layout. The body — events, projects, timelines — then refers to those resources by ID. Nothing is repeated; a clip used forty times exists once as an asset and forty times as a reference.

xmeml is a document that repeats itself. There is no resource table: each <clipitem> carries its own copy of the clip’s name, path, rate and reel, nested inside tracks, inside sequences, inside bins. The same source file referenced in five places is described in full five times. That makes the format verbose and occasionally self-contradictory — two copies of the same clip can disagree — but also forgiving: a parser can read one clipitem in isolation without chasing references.

Time: rational numbers vs frame counts

The deepest difference is how the two formats count.

FCPXML writes time as a rational number of seconds. A frame at 23.976 fps lasts exactly 1001/24000s; a clip starting one hour in at 25 fps starts at 90000/25s. Every value is an exact fraction, so fractional rates are represented without rounding — there is no drift hiding in the arithmetic, and audio can be placed with sample precision using denominators like 1/48000s.

xmeml counts integer frames against a timebase. A clip’s <start>, <end>, <in> and <out> are whole frame numbers, and a <rate> block declares what a frame means: <timebase>24</timebase> plus an <ntsc> flag. ntsc TRUE means “divide by 1.001” — so 23.976 is written as timebase 24 with ntsc TRUE, and 29.97 as timebase 30 with ntsc TRUE. The flag is easy to write, easy to read and easy to mishandle: a tool that ignores it interprets a 23.976 timeline as true 24, which is the same 0.1 % error — one frame every 42 seconds — dissected in the frame-rate mismatch guide. And because positions are whole frames, sub-frame audio offsets — which sample-accurate dual-system sync produces constantly — must either ride in a vendor extension (Premiere’s exports add tick-based pproTicksIn/pproTicksOut elements alongside the frame numbers) or be rounded to the nearest frame: one reason a sample-accurate sync can arrive a hair off after a round-trip through the older dialect.

Sync and multicam: first-class objects vs nested sequences

For dual-system work the formats diverge exactly where it hurts.

FCPXML models a synced pair as a synchronized clip: one object containing the camera clip and the sound-roll audio at a fixed offset, with roles (dialogue, effects) attached. A multicam group is likewise a first-class multicam resource with named angles; the receiving application gets the grouping, the angle names and the sync relationship as data, ready to cut. Final Cut and Resolve both consume these objects directly.

xmeml has no synchronized-clip element. The convention — established back in FCP7 and still what Premiere expects — is a sequence per synced clip: picture on the video track, recorder audio laid against it at the right offset, the whole thing named like the take. Multicam becomes nested sequences inside sequences. It works, and every conform tool understands it, but the semantics are implied by structure rather than declared: a receiving tool sees “a sequence with audio at an offset”, not “a synced clip”, and organisation that FCPXML states outright has to be reconstructed — or re-explained in a naming convention.

Who reads what

The compatibility matrix is smaller than it looks:

Two practical consequences. First, there is no direct XML path between the two biggest NLEs: Final Cut does not read xmeml and Premiere does not read FCPXML — Resolve is the translator in the middle, reading and writing both. Second, “which XML should I send?” is really the question “what is downstream?” — and if the answer is unknown, the safe editor package contains both, which is exactly how a well-built handover is structured.

Version dialects

FCPXML is versioned aggressively: 1.9, 1.10, 1.11 and onward, with the version stamped in the root element. Apple documents each revision, and newer versions add real semantics — but Final Cut refuses versions newer than it understands, and third-party tools each support their own window of dialects. Since version 1.10 the XML can also travel as an .fcpxmld bundle — a package wrapping the same document. The operational rule: ask which application version is downstream and export the newest dialect it accepts, exactly as with FCPXML’s cousin problem, Resolve’s multicam import, where dialect determines what survives.

xmeml is frozen — the root element carries a version number, but the format stopped evolving with FCP7, and readers are correspondingly lenient. That stability is its virtue: an xmeml written today is structurally the file a conform tool from 2010 expects. The cost is that everything invented since 2011 — roles, captions, rich rate handling, sample-accurate placement — either travels in proprietary extensions that only one vendor reads, or does not travel at all.

How good XMLs die

Interchange XML fails in patterns, and nearly all of them are identity or arithmetic:

• The wrong dialect. An FCPXML one version too new is refused outright; an xmeml full of one vendor’s private extensions imports with holes. Export for the reader, not for the writer.
• The ignored ntsc flag. A 23.976 xmeml read as true 24 shifts every event by 0.1 % — sync that is perfect at the head of a clip and a frame out at the tail, the classic pulldown-class error.
• Broken media paths. xmeml stores absolute file:// URLs from the exporting machine; the importing machine has different volume names, and every clip arrives offline. Harmless if the relink identity is intact — fatal if it is not, because…
• …relinking keys on the identity triple. Filename, start timecode, reel. Proxies or transcodes that dropped the reel or re-stamped timecode relink to nothing — or worse, to the wrong clip. The contract is the same one proxy workflows live and die by.
• Rate mixing inside one file. A 25 fps sequence referencing 50 fps clips is legal and routinely mishandled; each tool rounds the conversion slightly differently. Keep sequence rates explicit and boring.
• Hand-editing with a helpful editor. Like an ALE through Excel, an XML through a “smart” editor that re-encodes entities or normalises whitespace inside values can corrupt names and paths invisibly. Edit copies, diff before use.

Which one to send

The decision collapses to the downstream seat. Final Cut downstream: FCPXML, newest dialect the editor’s version accepts. Premiere downstream: xmeml, with sync expressed as per-clip sequences. Resolve downstream: either works; FCPXML carries richer sync semantics. Avid downstream: neither — send an ALE for metadata and AAF for sequences. Unknown or mixed: send both XMLs next to the same media and let each seat take its native door — the two files describe the same sync from the same source of truth, so they cannot disagree unless the tool that wrote them did.

Where Launchr Post fits

Launchr Post exports both dialects from one pass, on your own Mac. After ingest and sync, the editor package contains an FCPXML with synchronized clips and multicam groups for Final Cut and Resolve, a Premiere XML with the per-clip synced sequences Premiere expects, and a merge-ready ALE for Avid — all referencing the same media by the same filename, timecode and reel, so whichever door the edit enters, the relink resolves.