What to Check Before Using an ALE for Matching

The short answer: an ALE today ships 28 columns in a fixed order; check the column-name line row by row against it. The reconciliation after wrap is the real cost of the day: take numbers copied onto paper get retyped into a spreadsheet, and the last hour goes into tidying a record somebody else reads tomorrow. A skipped take number or one frame of timecode drift puts the re-conform on someone’s afternoon. SlateX hands this over as data rows — one row per camera, so four cameras make four rows and a take with no camera recorded still makes one. A value nobody read stays empty; we do not substitute a number that merely looks legitimate. This page is written to one standard: what you hand over should let the receiver find the mismatch themselves. The header’s COMMENTS line says whose conventions these are — read it as a boundary, not a certificate.

A file that opens only proves it can be read. Well-formed is not correct.

Column names and order: 28 columns, checked against the strings in the file

Column positions are a contract with the receiver: change a column and its data row in the same pass, or the file misaligns. The 28 columns, in order: Name, Tracks, Start, End, Duration, Scene, Take, Reel #, Soundroll, FPS, SlateX Description, SlateX Comments, Tape, Camera, Camera Notes, VFX_Count, VFX_Type, Director, Sound TC, Source File Name, Source File, Camroll, Shoot date, Unit, Rating, Circled take, TC Mode, SlateX Set Time. The last one is our own column, and it holds the “Scene duration” the supervisor types onto the take — a different ruler from Duration, whose span is the read-only “TC duration” on screen; the time section below keeps the two side by side. Check against these literals — a downstream system need not map a near-synonym onto the same field. The two columns SlateX Description and SlateX Comments carry the product name because they hold what we wrote, not someone else’s standard column.

Who a row is: card number, verbatim form, and counted number are three things

Tape carries the card you entered on set, and the whole name has to qualify: every character ASCII letter or digit, then upper-cased and truncated to 31. Anything else in it — non-Latin characters, a space, a hyphen — leaves the cell empty, because we will not pick characters out of a card name and hand over a number you never wrote. The casing rule exists because one card split across capitalisations becomes three downstream, and batch pulls, re-pulls and edit sheets fall out of line. Camroll carries that same card and needs it to be pure ASCII: a card name with non-Latin characters leaves that cell empty, and the wording as typed survives in the CSV and the PDF. Reel # is contracted as numeric, so a card name containing any letter empties the cell; we do not strip a prefix to manufacture a number.

A third thing looks like an identifier: the display number the software counts, a camera letter plus a three-digit increment. It sits beside the card you typed: the CSV splits them into Reel and Camera Card, so you can see which was transcribed and which was assigned. It corresponds to no physical card, so it cannot find original media.

Name is held to the same two rulers, 31 characters and ASCII; it takes the roll-plus-clip name of the camera on that row, and only when the take has no camera row at all does it use a name the take already has — the shot name if one was recorded, otherwise the scene number, and failing that the shot number, with the take number appended — the same string on every export, with no promise that two rows will differ: take numbers are typed in, so check identity field by field — scene, shot, take, and on a multicamera row the camera as well. It is a generated identifier, not the name you wrote on paper on set.

Time position: in-point and out-point only carry what the set actually read

Start takes the one in-point timecode this row holds; there is no second column to fall back to. End takes the out-point stored on the record, and it reaches the record by two paths: the recording chain captures the reading on the screen at the moment the supervisor calls stop, while the take’s new and edit pages hold an out-point box to be filled by hand from the camera. Nothing was read means nothing is delivered, and we do not advance an in-point by a duration to manufacture one — that would pass off a calculated number as the camera’s own reading. The CSV out-point cell follows the same ruler and the same source. An empty one surfaces on the reconcile sheet as TC_OUT_MISSING, whose judgement is: in-point present, out-point absent. Somebody has to go back to the camera report or the camera itself.

Duration is no longer the number the supervisor’s stopwatch reported. The column is the frame-accurate span between the two on-screen readings, tail frame excluded, so it equals End − Start; if either reading is missing, the cell is empty. What the supervisor types into “Scene duration” — how long the action actually ran, preroll, slate and a director who rolls early all inside it — travels in its own column, SlateX Set Time, side by side with Duration. The two disagreeing is normal on a set rather than an error: they were never measuring the same stretch. The reconcile sheet marks that case as DURATION_MISMATCH to get a human to look, and changes no value. FPS has a value only when that row declares a frame rate; no declaration, no number. The column never shows a rate this camera did not report.

Semicolons follow declarations only. TC Mode holds one token, DF; a blank means no drop-frame declaration exists, which is not non-drop-frame. Only rows declaring DF write Start, End and Duration with semicolons — a SlateX display convention, stated verbatim in the header, not a requirement of any standard. Sound timecode goes over verbatim: shape judged, frame positions never trimmed.

In this ALE, a missing value has one appearance: empty

Cells with no recorded timecode, or failing a shape or range check, come over empty. You will not see 00:00:00:00: its fault was looking legal — a receiver could not tell a genuine on-set zero from a padded one — so that route is gone. A blank now asks two questions: was nothing recorded, or was what got recorded not ASCII? The free-text columns are where the second one shows up.

Source File Name and Source File exist as columns; their value comes either from what you transcribed on set or from the pass that brings media in from a file, which fills those same cells and never overwrites what you typed. We do not guess at paths. VFX_Count has no manual field; only the bundled demo projects bring a value, so a take created on set comes back empty. Soundroll carries the roll number from the sound ledger through that same Tape gate: the whole value ships only if it is ASCII letters and digits, and it stays empty rather than taking a number the software counted. The whole file is ASCII-only, but that is two different rules, not one ruler. Human-readable free text — description, take notes, camera notes, director, unit — is folded to ASCII first wherever only the glyph changed: accents, typographic quotes and dashes, full-width punctuation, with line breaks and tabs flattened. Only what stays non-Latin after that folding empties the cell. Source-index cells — card number, scene number, file name, path — are never folded, because that cell has to carry the thing you transcribed, so a non-ASCII value ships empty there. A Chinese note is therefore a blank cell while an accented German note ships folded, and both keep their verbatim text in the CSV and the PDF.

What state a row was left in is in the file

Rating carries the on-set mark — Circle, Keep, Hold, N/G — and is empty when a take was never marked; Circled take carries TRUE or FALSE. A receiver therefore reads which mark a take carried, and whether it was circled, without asking the script supervisor.

Tracks has four forms rather than a “not MOS therefore sync” default: V MOS, A1A2 wild, VA1A2 sync sound; a row with no sound fact stays empty. The literals are written run together; no spaced V A1 A2 form exists.

What the wrap reconcile sheet is, and what it is not

A single-day export can carry a Reconcile_*.csv, judging one page — ours: what is missing, what contradicts itself. Fourteen codes, each one thing — CARD_MISSING, SOURCE_MISSING, SOURCE_DUP, SOUND_ROLL_MISSING, SOUND_TC_MISSING, MOS_VS_SOUND, MOS_VS_WILD, TC_MODE_UNDECLARED, TC_SOURCE_UNDECLARED, TC_EPOCH_MIXED, DURATION_MISMATCH, TC_IN_MISSING, TC_OUT_MISSING, DAY_MISSING. Five of them (SOURCE_DUP, MOS_VS_SOUND, MOS_VS_WILD, DURATION_MISMATCH, TC_EPOCH_MIXED) lift a row to Conflict, the rest land it in Missing, and a row reads Consistent only when none applies. DURATION_MISMATCH compares the two rulers, “Scene duration” against “TC duration”; it does not decide who misremembered. It marks and nothing more: no value changes, none overwrites another.

“Consistent” has one reading: our own checks found nothing. It does not mean two departments confirmed each other.

It reads neither the camera report nor the sound report: the header holds a column for the card number from the camera report and a column for the sound roll number, and both values come from your record in our software. DAY_MISSING marks a row attached to no shooting day — the take is not lost and still ships in the full package, but day number, date, unit and director carry nothing, and the reconcile sheet exposes that. What is lost is the day’s wrap paperwork, not the records. One absence it will not name: a cell emptied because the text is not ASCII — the record holds the value, so no flag fires, and those columns you check against what you typed.

Check it against your own import template

This is a checking list, not an industry standard, and it does not predict how any receiving system reads each column. Its purpose is to show what is worth checking, and where to go back to source. Before handing anything over, the receiver should check the record line by line against their own import template: the check stays in the reader’s hands.

When a check fails, keep the three responses apart

Send it back. Where an identity or time field contradicts the media or the on-set record and the source is traceable, return it to the generating side to fix and re-export, so the receiver holds no hand-edited version of unclear origin.

Patch it by hand where the gap is small, the source is clear and every change points back at specific media or a record; keep the reasoning beside it. Never fill a blank with a guess, and never manufacture a number for the empty End.

Keep it as reference. Where provenance cannot be confirmed, or you have not verified how the downstream system treats this file, the ALE stays a reference and carries no decision that needs exact matching.

FAQ

Can 00:00:00:00 be taken as a real zero point?

You will not meet that string again. A blank reads as not recorded — except on the free-text columns, where a value can exist and still ship blank because it is not ASCII; the CSV holds it verbatim.

Why does one take appear as several rows?

One row per camera: a Scene and Take with four cameras is four rows, so check by Camera rather than counting rows as takes. No camera recorded, still one row.

Can End be used for matching?

First check whether it has a value. The out-point exists only if somebody typed the reading off the camera; nothing typed, nothing shipped, and we infer nothing from in-point plus duration. Even with a value it stays a reading to verify against the media in your own import template, so this page does not promise that importing it lines anything up.

Is a semicolon timecode the general sign of drop-frame?

No. Only rows whose TC Mode reads DF use semicolons, a SlateX display convention. A blank means no declaration, not non-drop-frame.

The sheet says “Consistent” — did both departments agree?

No. It reads only our own page, and “Consistent” means our checks found nothing. The camera and sound reports are outside it.

Axiom One LLC — SlateX