拿到 ALE，先核对这些字段
拿到一份 ALE，先核对它指向哪条素材、时间位置从哪里来、缺值被写成了什么，再决定能不能继续用。SlateX 生成的 ALE 会按机位逐行写入，所以同一条 take 可能出现多行；其中有些缺值还会被补成看起来合法的内容。文件能打开，只说明语法层面可读，不能替代接收方对卷号、片段号、时码、帧率和实际有无数据的复核。
格式合法，不等于事实正确；先确认“这行是谁”，再确认“这个时间值从哪里来”。
先把“同一条为什么有多行”看明白
SlateX 的 ALE 按机位逐行生成。一个 take 如果挂了多台机位，接收方看到的不是“一条 take 等于一行”，而是同一条 take 按不同机位拆成多行。核对时应把 Scene、Take 与 Camera 放在一起看，再用 Reel、Name 等字段确认每一行的素材身份。只按行数数 take，会把多机位记录误当成多条拍摄。
当前列名与顺序固定为：Name、Tracks、Start、End、Duration、Scene、Take、Reel、Sound Roll、FPS、Description、Comments、Tape、Camera、Camera Notes、VFX_Count、VFX_Type、Shoot Day、Director。接收方应按文件里实际出现的字符串核对，不要先假定下游会把近义列名自动映射成同一个字段。
身份先看卷号、片段号和机位，不要只看一个名字
对片或入库前，先把 Reel、Name、Camera、Scene、Take 对到现场记录或素材本身。SlateX 的卷号与片段号来自当前机位记录并按固定规则自动编号；这能给接收方一个可检查的身份线索，但不能替代素材侧的实际名称核对。当前 Reel 与 Tape 写的是同一个来源值，也不应把这两列当成两条互相独立的身份信息。
如果一条记录没有可用机位信息，生成结果仍可能出现 A001、S001 这类默认值，Name 也可能带默认占位。它们的外观像正常数据，但它们表达的是生成器的兜底行为，不是接收方已经从素材上核实过的真值。看到这类值时，应回到现场记录或媒体文件确认。
时间位置要分开看 Start、End、Duration 和 FPS
Start、End、Duration 与 FPS 应一起核对。SlateX 当前在时码缺失或字符串长度不符合生成条件时，会静默写入 00:00:00:00。这个值在语法上是合法时码，因此单靠“格式检查通过”无法区分它是现场真实零点，还是缺值被补成了零。接收方需要回到现场记录或素材本身，把这两种情况分开。
End 也不是一个独立实测字段；当前生成方式是根据入点与时长回算出点。于是，入点、时长或帧率任一项有问题，出点也会跟着受影响。检查顺序应先确认 Start 是否可信，再确认 Duration 与 FPS，最后把 End 当作派生结果复核，而不是把四列都视为彼此独立的现场观测。
FPS 与丢帧写法要放在一起看：29.97 与 59.94 的时码在 ALE 里用末段分号表示丢帧。分号只说明这一行按丢帧写法生成，不证明这个值来自正确的时码链 —— 实时显示与交付文件之间的丢帧口径当前尚未统一。所以接收方应把时码当成待核值，而不是当成已验证的事实。
00:00:00:00 可能是合法字符串，也可能只是缺值的外衣；“看起来像时码”不是验收结论。
缺值不只有一种样子：空、短横线和默认值要分开
同一份 ALE 里，缺值并不只用一种方式表达。有的文本列可能留空，有的字段缺失时会写 -，有的身份与时间字段则可能得到默认值。接收时应把“明确为空”“明确占位”“生成器造出的合法默认值”分开标记。前两类比较容易看见，第三类更需要回源确认，因为它们最像已经记录过的内容。
这也是为什么“这一条到底有没有值”要和“这个值长得合不合法”分成两道检查。验收时不要只扫红字或空格；对 Reel、Name、Start、End、FPS 这类会参与匹配或定位的字段，应明确问一句：它来自现场记录、来自素材，还是来自生成器的兜底。
这份 ALE 还不包含什么
当前产物不写素材路径，也不提供可直接用于接收方工程的声道映射。Tracks 虽然存在，但当前生成值不能当作现场声音状态的完整描述。接收方如果要建立媒体位置、声道对应或其他工程侧关系，需要从自己的素材与交接信息补齐，不能只从这份 ALE 推出来。
这份 ALE 也没有状态或圈选列。接收方不能从 ALE 本身判断某条在现场被标成了什么状态。文件头的 COMMENTS 已经直接写明：Generated by SlateX. For reference only. Verify TC before conform. 这句话应按字面理解：先核时码，再决定下一步，不把生成文件当作未经复核的最终真值。
两项兼容性边界也应留在接收测试里
当前 ALE 使用 LF（\n）换行，而不是 CRLF；这是一项需要在具体接收环境里实测的兼容性条件，不应直接称为格式错误。生成路径里还有默认 25fps 未被显式传入的已知边界，因此涉及帧率的接收检查仍应以文件实际字段、现场记录与素材为准，不把默认行为当成已完成的兼容性验收。
更重要的边界是：我们目前没有与任何剪辑系统的导入验收记录。这份清单是一个执行示例，不是行业标准，也不证明某个接收系统会怎样解释每一列。它的目的只是把可检查的地方摆出来，让接收方知道哪里需要回源。
核对不通过时，三种处置不要混在一起
退回。 如果 Reel、Name、Start、FPS 等身份或时间字段与素材、现场记录冲突，而且原始记录仍可追溯，优先退回生成方修正源数据再重新生成。这样能避免在接收端留下一个已经被手工改过、却没有来源说明的版本。
手工补。 如果缺口很小、来源明确，而且接收方能把每一个修改指回具体素材或现场记录，可以在自己的接收副本里补齐，同时保留修改依据。不要用猜测去替换 00:00:00:00、默认卷号或其他占位。
只当参考。 如果无法确认身份、时码或帧率从哪里来，或者下游对列名、换行与字段解释还没有验证，就把这份 ALE 限定在参考用途，不让它承担需要精确匹配的决定。此时继续追查源记录，比把一个看起来整齐的表强行变成真值更重要。
FAQ
ALE 里看到 00:00:00:00，可以直接当成真实零点吗？
Start 或相关时码字段出现 00:00:00:00 时，应先回到现场记录或素材核对；SlateX 会在时码缺失或不符合生成条件时写入这个合法零值，所以它不能单独证明现场真的从零点开始。
为什么同一个 take 在 ALE 里会出现多行？
SlateX 的 ALE 按机位逐行生成；同一个 Scene 与 Take 如果有多台机位，会按不同 Camera 拆成多行，因此接收时应按机位分开核对，而不是按总行数计算 take 数量。
接收 ALE 时先核对哪些字段？
先核对 Reel、Name、Camera、Scene、Take 的身份关系，再核对 Start、Duration、FPS 与派生的 End，同时确认这些字段是真实记录、空值、占位还是默认值。
核对不过时应该退回、手工补，还是只当参考？
先看源记录能否追溯：身份或时间冲突且源数据可修正时退回；缺口小且每个修改都有明确来源时手工补；来源无法确认或接收行为未验证时，只把 ALE 当参考。
上海智独教育科技有限公司 — SlateX。以上数字截至 2026-09-24。