Which metadata survives ALE, FCPXML, EDL, and XMP

An interchange format is a file you hand to another application so it can rebuild what you logged. Five of them matter for footage: ALE, FCPXML, EDL, XMP, and plain CSV. None of them carries everything you wrote. Each drops a different part of the record, and the part it drops is not printed on the export dialog.

This is the reference version of that problem. What each format carries, what it discards without telling you, and which one to send when a producer asks you to "get us the metadata."

Decide which file is the original before you export any of them

One file has to hold the complete record. The exports are projections of it, the way a JPEG is a projection of a raw file. If you treat an ALE as your archive because it is the last thing you sent, the first field Avid refuses to import is gone for good.

ClipLogger keeps the complete record in a .logger.json sidecar next to the media, for the reason set out in metadata should outlive the app. Any tool with a stable open file will do. Pick one, then read the rest of this as a list of what you lose on the way out.

EDL: timecode and nothing else

An EDL in CMX 3600 form is a text list of edit events. Each line gives a source reel name, a source in and out timecode, a record in and out, and a transition type. Editors have exchanged them since videotape, which is why every system on earth reads one.

The cost of that reach is the payload. An EDL has no place for a scene number, a subject, a rating, a lens, or a framing. Comment lines carry short free text and different systems truncate them at different lengths. The reel name is limited enough that long filenames get mangled into something you cannot match back.

Send an EDL when the receiving end needs the cut and does not need the log. Send it with something else attached when they need both.

ALE: your columns survive, your structure does not

Avid Log Exchange is a tab-delimited text file with three parts: a Heading block that declares the field delimiter and the video format, a Column block that names the fields, and a Data block with one row per clip. Avid Media Composer and DaVinci Resolve both import it, and both accept column names you invent.

That flexibility is the reason ALE remains the workhorse for logged footage. Name a column Framing and it arrives as a bin column called Framing.

What an ALE cannot express is shape. One row per clip means one value per field. A clip with three subjects in it becomes a comma-crammed string in a single cell, and the receiving application has no way to know it was ever a list. Ranges inside a clip have nowhere to live either, so a note attached to a moment thirty seconds in flattens to a note attached to the whole clip. Field names are case-sensitive on import in more systems than you expect, so a column called SHOOT DAY and one called Shoot Day are two columns.

FCPXML: structure survives, vocabulary does not

FCPXML describes a library, its events, its clips, and its ranges. It carries keywords with in and out points, markers, ratings on sub-ranges, roles, and the sequence itself. For anything time-based inside a clip, it is the only one of the five that can say what you mean.

The trade is vocabulary. FCPXML has keywords and notes and no concept of a field called Framing with a fixed set of allowed values. Your schema has to be flattened into keyword strings on the way out, which puts you back in tag territory with the failure modes described in a metadata schema for logging video. The receiving application also has to speak your version of the format. Resolve, Premiere, and Final Cut Pro each read a subset, and each ignores different elements without raising an error.

XMP: travels with the file, if the reader bothers to look

XMP is Adobe's metadata standard, written either into the media file itself or into a sidecar with the same base name. Premiere and Bridge read it. Resolve and Avid mostly do not.

The advantage is that XMP does not need a matching step. The metadata is at the same path as the footage, so a file that gets copied to a new drive carries its description with it. The limitation is that XMP is a namespace, not your namespace. Custom fields live in a private namespace that only a tool built to read that namespace will show, so the fields most useful to you are the ones least likely to appear on the other end.

CSV: whatever the destination's importer expects

Resolve imports a CSV of metadata and matches rows to clips on filename or reel name. The column headers have to match Resolve's own field names, character for character, or the column is skipped in silence. There is no error, and no report of which columns landed.

CSV is the right choice when you know the destination and can test one clip first. It is the worst choice when you are sending the file to someone you cannot ask.

The check that takes two minutes and saves a week

Export one clip, not four hundred. Import that one clip on the receiving system, open the bin, and read the fields back. Confirm the values arrived, the field names are the ones you meant, and the clip matched the right media. Then run the full export.

Every format on this list fails quietly. The two-minute round trip is the only thing that turns a silent failure into a visible one before the footage is someone else's problem.

Send the cut as an EDL, the log as an ALE, the ranges as FCPXML, and keep the original in a file none of them can damage.