What the Tracks Column Does Not Tell You
The ALE Tracks field is written by a silent-recording branch: that branch would write V, the other V A1 A2. There is currently no place on the take to mark that state, so what a receiver actually sees in this column is V A1 A2. What the field tells a receiver is the track notation that was written. It does not identify what each audio track contains, and it is not a channel map.
Tracks is a notation, not a description of the sound-routing relationship.One text shape comes from a binary condition
The generator checks a silent-state condition. One branch writes V; the other writes V A1 A2. The take record offers no way to set that state, so today the branch that fires is the V A1 A2 one. It does not continue by reading a record that says which microphone belongs to A1 or which source belongs to A2.
So V A1 A2 tells you that the file contains a video-plus-two-audio-track notation. It does not prove what was actually recorded into those channels or how a receiving project should route them.
Keep a product boundary in view as well: a sound-related export column does not prove that the current take-record UI has a complete entry path for that sound state. Column presence must not be turned into an on-set capability claim.
The same Tracks string can describe different sound situations
From the Tracks field alone, normal sync-sound material and a separately recorded wild-track situation can look the same: V A1 A2. The field carries no extra label explaining the recording context behind those tracks.
A receiver therefore cannot use Tracks alone to distinguish sync dialogue, a wild track, or another sound relationship. When that meaning matters, go back to the sound record, on-set notes, and actual media.
Two rows that both say V A1 A2 share the same notation; they do not necessarily share the same sound relationship.
It does not carry sample rate, channel sources, or sound timecode
The current ALE has no channel map describing what A1 or A2 is connected to. The header carries one audio-format constant printed as 48khz, which does not come from any user record; apart from that there is no sample-rate field, no channel source, and no sound-timecode field.
Sound Roll is present, but it identifies the sound roll rather than the sound’s time position. A roll identifier cannot replace sound timecode, just as Tracks cannot replace channel mapping.
If a receiving workflow needs to synchronize sound, it must return to the sound media, sound record, and handoff information to establish roll identity, time position, and channel relationships.
Downstream interpretation needs receiving tests
The current source material contains no import-acceptance record proving how a particular receiving system will interpret V A1 A2. The safe statement is therefore limited to the literal value SlateX writes and the information it does not carry.
Receivers should test the field against their own import template: whether Tracks is read, how it is read, and what additional channel information the workflow requires. Only that receiving test can establish what role the field should play in a specific environment.
FAQ
Does V A1 A2 provide a complete two-channel map?
No. It is the generator’s track notation and does not say what sound source or input belongs to A1 or A2.
Can Tracks distinguish sync sound from a wild track?
Not by itself. Different sound situations can produce the same V A1 A2 text, so the receiver needs the sound record and the actual media.
Why is sound timecode still needed if Sound Roll exists?
They answer different questions. Sound roll identifies the sound asset group; sound timecode identifies a time position. The current ALE has a sound-roll field but no sound-timecode field.
Can a receiver assume its system will interpret Tracks as intended?
No. The supplied evidence does not include downstream import-acceptance records for that behavior. Test the field with the actual receiving template and media workflow.
Axiom One LLC — SlateX. Figures current as of 24 September 2026.