Every manifest this product ships used to say “not an NLE timeline”, and that was true: a pack of numbered files is a pile of clips, and the assembly, the order, the cuts, which audio sits under which picture, was rebuilt by hand at the other end every time.
The pack now carries timeline.xml: the lot as a sequence, in FCP7 XML. Premiere imports it through File → Import. Resolve and Final Cut read it too.
OTIO is the better-designed modern answer and Premiere still needs a plugin for it, so it is not the format that gets a lot onto an editor’s timeline today.
Hand it over beside the clips
The media paths are relative. On its own the XML relinks nothing.
Give an editor the file and the downloaded folder it came in, with the clips where the pack put them. An XML sent by itself is a sequence full of offline media and a conversation you did not need to have.
One frame rate for the whole sequence
A sequence declares a single rate, and every clip length is written in frames against it. So this one decision moves every cut in the lot.
Where the lot disagrees with itself, the majority wins, and the clips that disagree are named. Premiere conforms them on import either way; an editor who was not told is an editor who finds out by watching something drift. Ties break toward the rate that appears first in lot order, which is the shot an editor cuts to.
When nobody measured
A take whose frame rate was never recorded cannot contribute one. If nothing in the lot was ever measured, the sequence is built at 30, and the manifest says the rate was assumed rather than measured.
That distinction is the whole point of reporting it. An editor who knows the timebase was assumed checks it against the first clip and moves on. An editor who was told 30 as though it were a fact conforms the whole sequence to a number nobody established.
The NTSC rates
23.976, 29.97, 47.952 and 59.94 are written as their rounded timebase with the NTSC flag set, which is what those rates mean in this format.
A whole number is never NTSC, and that check has to come first: 24 is within 0.024 of 23.976, so a tolerance loose enough to catch a probe’s rounding of 23.976 also swallows real 24. Marking true 24 as NTSC makes every clip length 0.1% wrong, which on a 90-second explainer is a frame and a half of drift by the end.
What lands on the timeline
| Element | How it arrives |
|---|---|
| Video shots | In lot order, at their measured length |
| Stills | Held for four seconds, since a photograph has no length of its own |
| A clip’s own audio | Beside it, on the audio track |
| Narration | On a second audio track, under the picture it belongs to |
| A shot with no delivered take | A gap, not a broken link, the sequence keeps its shape and the hole is visible |
Captions are a sidecar this format cannot carry. They are in the pack and named in a comment inside the XML, so an editor finds them rather than discovering later that they existed.
Why the XML and the manifest cannot disagree
Both are built from the same list of clips, and both ask the same function for the frame rate. So the JSON’s description of the delivery and the sequence an editor opens are two renderings of one set of facts rather than two documents that have to be kept in step.
A still’s extension is taken from what the model actually returned: .png, .jpg or .webp, rather than guessed from the file stem, because a sequence pointing at a file the delivery does not contain is the one failure a well-formed XML will not save you from.
The rest of what an editor might ask (what made this shot, at what resolution, on whose key) is in the manifest beside it.