Where Each ALE Column Comes From

SlateX writes its ALE as tab-delimited text with a file-level heading, a column-name section, and data rows. The fields do not share one source model. Some come from on-set entry, some are derived from existing records, and some are fallback strings written when data is missing. A receiver should first ask where a value came from, then decide what it can safely be used to verify.

One row can mix entered data, derived results, and fallbacks. A tidy table does not label those categories for you.

Read the file-level heading separately from row data

The heading includes video format, audio format, and frame rate. The heading FPS is a file-level value derived by summarizing camera-row frame-rate labels across the snapshot; it is not simply the FPS of each individual row. Video format is also a file-level result derived from camera resolution strings.

Audio format has a different source. The current value is a fixed literal rather than a sample-rate or channel value entered by the user. These three heading entries therefore look parallel while being produced in different ways.

Identity fields: Name, Scene, Take, Reel, Tape, Camera

Name first uses the generated filename for the current camera record and falls back to a generated placeholder shape when that context is unavailable. Scene comes from the scene identity attached to the shot. Take comes from the take number and is not zero-padded. Camera comes from the camera identifier.

Reel comes from the camera reel display value and can fall back to a value such as A001 when camera context is missing. Tape deserves special attention: it is populated from the same reel value as Reel. Two columns do not create two independent identity signals.

Sound Roll comes from the camera record’s sound-roll value and can also receive a fallback shape. Compare these identity fields with the on-set record and the media naming rather than accepting a string merely because it resembles a normal reel or clip identifier.

Time fields: Start, End, Duration, FPS

Start first uses timecode-in and then the take timecode. The only test applied is whether the string is 11 characters long, not whether it is a valid timecode: an 11-character malformed string is written as-is, while anything else becomes 00:00:00:00. Duration comes from the take duration and can also use an all-zero timecode-shaped fallback.

End has a different status. If an out point exists, it is used. If it is missing, SlateX calculates an end value from the start, duration, and frame rate. End is therefore not an independently observed value on every row. A problem in start, duration, or frame rate can affect the derived result.

FPS is the camera-row frame-rate label with fallback behavior when that camera value is unavailable. There is also a receiving boundary here: frame-rate fallbacks are not identical across every delivery format, so a default seen in one file should not be generalized into a cross-format truth.

When an end position is calculated, verify it as a derived result rather than treating it as another independent observation.

Text fields: Description, Comments, Camera Notes, Director

Description combines non-empty scene summary, shot description, and shot notes. Comments comes from take notes. Camera Notes comes from the camera record. Those three fields pass through the ALE generator’s current text-cleaning path.

Director carries the director text of the shoot day the take belongs to, written per take through the export snapshot, and uses a placeholder when absent. It does not share exactly the same cleaning path as the three fields above. It would therefore be inaccurate to claim that every ALE field receives one uniform sanitization pass.

The source distinction matters even when every value looks like text. One field can be direct entry, another can be a composition of several records, and another can contain a placeholder.

Tracks, VFX, and Shoot Day have narrower meanings

Tracks is generated from the take’s sound-state branch and produces a fixed track notation. It is not a channel map and does not describe which microphone belongs to which track, sample rate, or receiving-project routing.

VFX_Count reads a take-level count field that currently has no usable entry path, so it should not be presented as an available recording capability. VFX_Type is different: it is assembled from camera-level VFX, plate, clean, and reference states.

Shoot Day comes from the shooting-day number and uses - when that value is missing. Many other missing values are left empty instead. The dash is therefore a placeholder in this field, not a business value.

Know what the ALE does not contain

The current ALE has no rating or circled-take column. It also does not contain shot number, lens, ISO, aperture, shutter, resolution, media path, channel map, or sound timecode. The existence of that information elsewhere in the app does not mean it is present in the ALE.

Likewise, Reel and Tape cannot be treated as independent confirmation, Tracks cannot be read as a channel map, and End cannot always be treated as an observed out point. Receivers should check the literal columns, value shapes, and sources against their own import template rather than assuming how a particular downstream system will interpret them.

Column names should also be checked as literal strings. A similar-looking field name in a receiving template should not be assumed to map to the same meaning until that mapping has been tested in the actual receiving environment.

FAQ

Can Reel and Tape be used to confirm each other?

Not as independent sources. The current generator fills both from the same reel value, so matching values only show that the same source was written twice.

Is End always recorded directly on set?

No. An existing out point can be used, but when it is absent SlateX calculates an end value from start, duration, and frame rate. Verify which source applies to the row you received.

Is Tracks a channel map?

No. It is a generated track notation. It does not carry microphone-to-channel relationships, sample rate, or receiving-project routing.

Why does the receiver still need to check every field?

Because one ALE can contain direct entry, derived values, and fallbacks at the same time, and fields also differ in cleaning and placeholder behavior. A readable file does not prove that every field source has been verified.

Axiom One LLC — SlateX. Figures current as of 24 September 2026.