Anatomy of an EDL
A CMX3600 EDL is plain text: a title, an optional frame-count mode, and a list of numbered events, each describing one edit. A minimal example:
| TITLE: NEON HARBOR EP101 CUT 04 FCM: NON-DROP FRAME 001 NH010 V C 01:00:10:00 01:00:14:12 01:00:00:00 01:00:04:12 * FROM CLIP NAME: NH_SH010_comp_v002 |
Reading an event line
- 001 - the event number.
- NH010 - the reel (historically a tape; today usually a clip/reel identifier).
- V - the track: V for video, A/A2/AA for audio channels. VFX shot lists come from V events.
- C - the transition: C is a cut; D means a dissolve (with a duration), W a wipe.
- Four timecodes - source in, source out, record in, record out. Source is where the media comes FROM; record is where it lands IN the timeline. Record out minus record in is the cut duration.
The comments are where the gold is
The base format predates long file names, so NLEs smuggle the useful data into comment lines starting with *:
- * FROM CLIP NAME: - the actual clip name, which in a VFX workflow usually encodes the shot ID and version (NH_SH010_comp_v002). This line, not the reel, is how cuts map to shots.
- * TO CLIP NAME: - the incoming clip of a dissolve.
- * LOC: - markers/locators with notes.
- * SOURCE FILE: - some NLEs write the media path here.
Timecode to frames
Timecode is HH:MM:SS:FF. To count frames: (hours x 3600 + minutes x 60 + seconds) x fps + frames. At 24 fps, 01:00:04:12 is 86,508 frames; subtract record-in 01:00:00:00 (86,400) and the event is 108 frames long. That arithmetic - plus handles - is the whole basis of a conform check.
Why it survives: every NLE exports it, every tool parses it, and it is human-readable in a crisis. OTIO is the richer modern interchange (JSON, nested tracks, metadata) - but when in doubt, everyone can still read the EDL.
Cutlist Tracker parses both: paste an EDL or an .otio and the shot list, durations and in-cut versions populate themselves, with a live preview of how each FROM CLIP NAME maps to a shot.