What an ALE File Is Actually For
In SlateX, an ALE is a tab-delimited text list made of a header section, a column section, and a data section. Its job is to hand the receiver checkable information about what a row refers to, where that material sits in time, and which scene and take it belongs to. It does not decide which take is good, and it has no shot-parameter or channel-map column; the source file name and directory cells hold text from the sending machine, which links back to no media on the receiver’s disk. Whether it can be used in a particular receiving workflow still depends on the receiver checking the columns.
An ALE supplies identity and time information that can be checked; it does not certify that those values have already been verified.
What the file looks like
The current SlateX ALE starts with header information, then a fixed set of column names, and then data rows. Columns are separated by tabs, so the file behaves like a text table with explicit fields rather than a container for the media itself.
Rows are generated per camera. A take with several cameras can therefore occupy several rows. A take with no camera data still produces a fallback row. This means an ALE row is closer to a camera-level delivery record than to a rule that “one row equals one take.”
Ask where each value came from
It is useful to read ALE values in three source categories.
The first category comes from on-set records or user-entered information: scene and take identity, notes, director text, camera notes, and related recorded context. Their correctness depends on whether the source record matches what happened on set.
The second category is generated or derived by software. Duration, for example, is the frame-accurate span between the row’s two on-screen readings, tail frame excluded; if either reading is missing the cell ships empty. Names, formatted reel values, and some frame-rate representations are also produced by the software. A derived value is not an independent second observation; it still depends on its inputs.
The third category is the missing value itself. In this ALE a missing value has one shape: the cell is empty — no readable zero is written when a timecode was never recorded or a string fails the shape or range check. In a file from other software, 00:00:00:00 can be a genuine zero or a fallback, so the receiver needs to check them against the on-set record or the media.
Ask “where did this value come from?” before asking only “does this value look syntactically valid?”
What an ALE can hand to the receiver
The current columns can expose material name, start, end, duration, scene, take, reel, sound roll, frame rate, comments, camera identity, and related fields. That makes the file useful for passing identity and time-position clues into a receiving check.
There is an important identity boundary: Tape and Reel are currently populated from the same source value. They should not be treated as two independent identity signals simply because they appear in two columns.
The end position is not derived, and only partly automatic. End carries the reading taken at the moment of stop: the recording chain captures the camera’s screen value as it stops, while the out-point box on the take’s new and edit pages lets the supervisor copy it by hand. Neither happened, the cell stays empty, and we do not advance an in-point by a duration to fill it. A receiver should first check whether that reading exists on the row, then review Start, End and the span together — the column holds what the machine or the person saw at stop, not a conclusion matched against the media.
What the ALE does not contain
The current ALE carries two rating columns, Rating and Circled take, a Sound TC column for the sound’s start position, and the source file name and directory cells — those two hold a path on the sending machine — transcribed on set or recorded when media were imported — not a location on the receiver’s disk. For why a sound roll is not the same as a sound timecode, see “Why Sound Roll Does Not Mean Sound Timecode Is Present”. It still has no shot-number column, no lens, ISO, aperture, resolution or channel map, and it never carries the media itself. Read each column for its own source: one column’s presence does not carry another column’s fact, and a field recorded somewhere in the project does not mean this ALE shipped it.
That boundary only means the ALE does not decide which take to use. The on-set mark is readable in this same file: Rating carries the mark as text and Circled take carries TRUE or FALSE — a blank cell means no mark was left, and reading the literal is not a ruling.
How the ALE’s row count compares with the other two
The ALE, the CSV and the readable report all expand by camera now, so one batch of records sits at the same row granularity within a single export and a multicamera take takes extra rows in all three. The real differences are row order and column coverage: the ALE re-sorts by scene number, shot number and take, the CSV largely keeps the order records were created in, and the report sorts by scene, shot name and take.
This is not a difference that should be resolved by matching row numbers. Cross-file verification should return to scene, take, and camera identity rather than assuming that row N in one artifact represents row N in another.
What to do after receiving an ALE
This page stops at the purpose and boundaries of the format. The already published “What to Check Before Using an ALE for Matching” continues with the receiving procedure: identify what each row belongs to, then verify reel, material name, time position, frame rate, and the source of missing-looking values. For behavior in a specific receiving system, the receiver should check each column against its own import template.
FAQ
Does an ALE include the media files themselves?
No. SlateX’s current ALE is a text list: the source file name and directory cells hold a path from the sending machine (transcribed on set or recorded on import), and the media itself is not packaged.
Is End always an independently measured time position?
No. That column has three possible origins: the recording chain captures the screen reading at the moment of stop, the supervisor transcribes the camera’s out-point reading into its entry field, or neither happened and the cell is empty. The software will not invent a number from in-point plus duration. Even with a value it still needs checking against the media — verify it in your own import template.
Can Reel and Tape be treated as two independent identity checks?
No. The current output populates them from the same source value, so two columns do not represent two independent confirmations.
Why can one take appear on several ALE rows?
Because the current ALE generates data rows per camera. A multicamera take therefore expands into several rows, so total row count is not the same thing as total take count.
Axiom One LLC — SlateX