字幕顺序错乱检测
或者粘贴字幕文本
选项
时间按哪个帧率计算。在格式页面里，这是 MicroDVD 需要的值，因为它把时间存成帧号。在帧率页面里，它是文件当初对应的速率 —— 字幕是按这个版本做的 —— 而页面的第二个框填你要拿它配套的视频速率。常见的有 23.976、24、25、29.97、30、50、59.94 和 60。填错会让整条时间轴偏移；在帧率页面里，偏移是按比例发生的，而不是一个固定的量。
字幕文件本应一路向前：每一条的开始时间不早于前一条。这一页报告不满足这一点的文件，而它依据的不是字幕条本身，而是读取器为把文件读进来所做的那次重排——等到可以检查的时候，顺序已经被摆正了。产物是一份报告，不是转换后的文件。
先理解这个机制再看报告。文件一读入就按开始时间排序，因为后续每一次操作、每一个预览和每一次导出都假定顺序是升序的。所以一份乱序文件在字幕条上留不下痕迹，唯一存活的证据是有多少条被搬动过：报告只给一条文档级发现和涉及的条数，不给时间码，因为排序之后已经没有诚实的出错位置可指。
判定是一次开始时间的下降，仅此而已。两条在同一毫秒开始的字幕不算乱序：排序是稳定的，没有条目移动，这一页放行——那一对更可能出现在重叠检测页上。按顺序读入的文件会得到一份没有发现的报告，读取时丢失一栏写着无，这是真正的免责而不是缺答案：证据就是移动的条数，而零也是一个数。
除纯文本外的十一种格式都可以检查：没有开始时间的格式谈不上顺序。报告以 PDF 为主产物、CSV 为第二份，支持批量处理，文件不上传。
示例
文件是倒着走的
字幕
1
00:00:10,000 --> 00:00:11,000
I was working late.
2
00:00:01,000 --> 00:00:02,000
Where were you?
报告发现了什么
Cues out of sequence — 1 found
Severity Cues Start End Measured
Warning — — — 2 items
第二条字幕比第一条早九秒。报告只给出一条发现、不给时间码：字幕条在读取时已经被排序，文件里不再有一个位置可以被称为错的。头部那行字幕条顺序错乱 × 2 就是同一件事在读取时的计数。
同时开始的两条字幕不算乱序
字幕
1
00:00:01,000 --> 00:00:02,000
Where were you?
2
00:00:01,000 --> 00:00:03,000
I was working late.
报告发现了什么
Cues out of sequence — Nothing found
Cues 2
Checks run 1
Lost while reading Nothing
开始时间相等不是下降，排序稳定，没有任何条目移动。这样的文件带着另一种缺陷——两条字幕共享屏幕——那是重叠检测页的事。把它们送到这里，等于报告一次从未发生的重排。
常见问题
字幕顺序错乱检测依据什么判断一份文件乱序？
一条字幕的开始时间早于它上面那条的开始时间，也就是一次下降，仅此而已。开始时间相等不算下降；结束时间与排序无关，因为排序按开始时间。一条坏字幕就足以让整份文件被报告。
两条字幕开始时间相同，字幕顺序错乱检测会报告吗？
不会。开始时间相同不会让任何条目移动，稳定排序原样通过。这一对字幕值得从另一个角度检查：两条同时出现在屏幕上就是重叠，应该交给字幕重叠检测那一页。
为什么顺序错乱检测的发现不给出时间码？
因为字幕条在读取时已经被排序，报告是之后生成的。那时内存里的顺序已经正确，文件里不再剩下一个可以诚实称为错位的位置；证据是搬动的条数，它印在实测列和报告头的丢失行里。
字幕顺序错乱检测会把我的文件重新排序吗？
不会。它只读文件、出报告，原件不动。发现所指的那次排序发生在浏览器读取时，不会写到任何地方；如果你要的是排好序的文件本身，那是另一项以字幕文件为产物的操作。
字幕顺序错乱检测支持哪些字幕格式？
除纯文本外的十一种：SRT、WebVTT、ASS、SSA、SBV、SMI、LRC、MicroDVD、TTML、JSON 与 CSV。纯文本没有开始时间，也就没有顺序可错——在那里报干净只是虚假的免责。
读取时丢失为无和未发现问题的区别在顺序错乱检测里是什么？
两者都是真结果，但说的是两件事：前者表示读取时没有字幕条需要搬动，后者表示这项检查跑了并且没有发现乱序。证据都是移动的条数，零也是一个可以相信的数。
交付的字幕文件为什么会出现顺序错乱？
通常原因很无聊：两个文件手工合并、机器翻译按不同顺序返回片段、或者时间轴工具只作用于选中的一段。播放器自己也会排序，所以它很少活到观众面前，却会活进那些假定文件有序的工具里。