The editor package: what your editor actually needs from a shoot day
An editor’s first hour on a project is spent discovering what they were given: which files exist, what is synced, what plays back, what is missing. A good handover package collapses that hour into minutes. This is a concrete spec for what to deliver — formats, multicam groups, proxies (including RAW), folder structure and the sync report — whether you assemble it by hand or generate it.
What “the package” means
A shoot-day handover has five layers, and weak handovers usually skip two of them:
- Media — camera originals and sound rolls, organised and complete.
- Proxies — edit-friendly versions of anything the edit machine cannot play natively.
- A project interchange file — FCPXML, Premiere XML or ALE that carries the sync relationships, so the editor imports a bin of synced clips instead of a pile of files.
- A sync report — the honest paper trail: what was matched, how, and what was not.
- Search material — transcripts, notes, anything that lets the editor find content instead of scrubbing for it.
Folder structure: boring on purpose
Editors do not want a clever structure; they want the same structure every time. A layout that has survived many productions:
2026-07-16_ShootName/01_CAMERA/A-CAM/,01_CAMERA/B-CAM/,01_CAMERA/DRONE/— originals, card structure preserved where the format demands it02_AUDIO/— sound rolls as recorded, plus the recorder’s own metadata/CSV if it writes one03_PROXY/— mirrors the camera folders, one proxy per original, same base filename04_PROJECT/— the FCPXML / Premiere XML / ALE files05_REPORTS/— sync report, transcripts99_JUNK/— false starts, lens caps, corrupt files — kept, but out of the way
Two rules matter more than the exact names. Nothing is deleted — the junk folder exists precisely so that sorting decisions are reversible. And proxies mirror originals one-to-one, because every relink strategy in every NLE ultimately leans on matching names and timecode.
FCPXML vs Premiere XML vs ALE
Three interchange formats cover the working NLE landscape. They are not equivalents; they carry different amounts of your work.
FCPXML — for Final Cut Pro (and more than you’d think)
FCPXML is Apple’s current interchange format: a versioned XML dialect (1.9, 1.10, 1.11…) describing events, clips, synchronized clips and multicam clips as first-class objects. It is the richest way to hand over sync: a synchronized clip lands in Final Cut as one object with picture and sound married at sample precision, roles assigned, ready to cut. DaVinci Resolve also imports FCPXML, which makes it a useful second door into Resolve-centric workflows. Version matters — ask which FCP version the editor runs, and export the newest dialect it accepts.
Premiere XML — the FCP7 lingua franca
What everyone calls “Premiere XML” is historically the FCP7 XML (xmeml) format — the interchange dialect of a discontinued application that outlived it, because Premiere Pro, Resolve and most conform tools still read it. It describes bins, clips and sequences; sync is expressed as sequences (one per synced clip, audio laid against picture) and multicam as nested sequence structures. It is less expressive than FCPXML — expect to reconstruct some organisation on import — but it is the most portable single file you can hand a Premiere editor today.
ALE — metadata for Avid workflows
Avid Log Exchange is not a project format at all: it is a tab-delimited text file of clip metadata — name, tape/reel, start and end timecode, frame rate, comments, custom columns. Media Composer workflows use it to enrich master clips during ingest: the ALE’s reel + timecode columns let Avid marry your metadata (and later, your conform) to the media. If an Avid editor or a finishing house is anywhere downstream, an ALE per shoot day costs almost nothing to include and quietly prevents a re-logging job.
| Format | Carries sync? | Best for |
|---|---|---|
| FCPXML | Yes — synchronized & multicam clips | Final Cut Pro, Resolve import |
| Premiere (FCP7) XML | Yes — as sequences | Premiere Pro, Resolve, conform tools |
| ALE | No — metadata only | Avid ingest, finishing, dailies logs |
When in doubt, deliver all three. They are small text files describing the same truth.
Multicam groups: deliver the grouping, not the ingredients
If two or more cameras rolled on the same moments, the editor needs multicam groups, not a note saying “A and B overlap.” A group is the set of angles plus the sound roll, aligned on a common timeline — a multicam clip in FCPXML, a nested multicam structure in Premiere XML. Two details decide whether groups are pleasant to cut with:
- Angle naming and order. Angles should be named by camera (A-CAM, B-CAM, DRONE) and appear in the same order in every group, so the editor’s fingers learn the layout once.
- One group per continuous event. If B-cam stopped and restarted mid-interview, the natural grouping is still one logical group per interview where the format allows gaps — not five fragments the editor must mentally reassemble. How the alignment itself is computed — timecode overlap or waveform — is covered in our guide to syncing without a clapper.
Proxy strategy — including the RAW problem
A proxy strategy answers three questions: what gets proxied, to what codec, and how do names and timecode survive?
- What: anything the edit machine cannot scrub smoothly. In practice: all RAW formats, high-bitrate intraframe UHD, and often 10-bit H.265 from mirrorless cameras, which decodes deceptively poorly on machines without the right hardware decoder.
- Codec: ProRes Proxy or ProRes LT at full or half resolution are the safe defaults on Mac-centric pipelines — interframe H.264 proxies are smaller but scrub worse, which defeats the purpose. Keep the frame rate and audio channel count identical to the original.
- Identity: the proxy must carry the same filename (different extension is fine), the same start timecode, and the same reel/tape name as its original. This triple is what lets the NLE toggle proxy/original and lets a finishing conform find its way back to camera originals. A proxy with stripped timecode is a future conform failure, quietly waiting.
RAW is the reason proxy generation cannot be a one-tool job: CinemaDNG, BRAW, R3D and their relatives need a renderer that actually understands the format. In practice that means driving DaVinci Resolve, Adobe Media Encoder or Compressor to do the debayer and encode — the workflow question is whether you queue that by hand for every card, or automate the round trip so proxies come back named and stamped correctly without anyone babysitting a render queue — the full recipe, format by format, is in the RAW proxy workflow guide.
The sync report: the part everyone skips
The sync report is one document — a page or a table — that states, per clip:
- How it was synced: file timecode, decoded LTC, or waveform match (the distinction matters; see how LTC works for why a decoded stamp can outrank camera metadata).
- The offset applied, and any drift correction on long takes.
- Confidence — a clean TC+waveform agreement, a weak waveform-only match, or a manual placement.
- What was not matched: sound rolls with no picture, clips with no usable audio, files whose timecode contradicted their content.
Its purpose is trust. An editor who finds one out-of-sync clip in a delivery without a report stops trusting all of it and starts re-checking everything — the report is what contains that damage to one line item. It also transfers accountability cleanly: if a clip is flagged “waveform match, low confidence, verify before use,” the handover was honest.
Search material: transcripts belong in the package
For interview-driven work, a transcript per synced clip changes how the edit starts: the editor searches for the sentence instead of scrubbing for it. On-device transcription has made this cheap enough to be a default deliverable rather than a luxury — the searchable footage guide covers the full workflow — so include per-clip text with timestamps in 05_REPORTS/, and the assistant who logs selects can work from words, not waveforms.
The checklist
- Originals complete, organised by camera, junk quarantined but kept
- Proxies one-to-one with originals — same names, same timecode, same reel
- FCPXML and/or Premiere XML carrying synced clips and multicam groups; ALE if Avid is downstream
- Sync report: method, offset, confidence, exceptions — per clip
- Transcripts with timestamps for anything spoken
- One top-level folder, dated and named, that opens the same way as the last delivery
Where Launchr Post fits
This package is what Launchr Post is built to produce. It syncs the day (timecode first, sample-accurate waveform refinement), sorts cameras, sound, drone and junk into the structure above, drives Resolve, Media Encoder or Compressor to generate correctly-stamped proxies from RAW, transcribes every word on-device, and exports the editor package — FCPXML, Premiere XML, ALE, multicam groups and the per-clip sync report — from one pass on your own Mac.
Hand over a shoot day properly
Run a real day through Launchr Post and open the resulting package in your NLE — synced clips, multicam groups, proxies and the sync report included.