字幕時間軸倒置偵測
或者貼上字幕文字
選項
時間以哪個影格率計算。在格式頁面上，這是 MicroDVD 需要的值，因為它把時間存成影格編號。在影格率頁面上，它是檔案當初對應的速率 —— 字幕是照這個版本製作的 —— 而頁面的第二個欄位填你要搭配的影片速率。常見的有 23.976、24、25、29.97、30、50、59.94 和 60。填錯會讓整條時間軸位移；在影格率頁面上，位移是按比例發生，而不是固定的量。
結束早於開始的字幕條，是一個不可能成立的時間碼：00:00:03,000 --> 00:00:03,000，或者更糟，結束時間比開始還早。這一頁回報的是檔案裡出現過這種字幕條——依據是讀取器不得不做的修復，因為這種形狀的時間碼根本留不住在記憶體裡，在任何事情發生之前就會被換成一個真正的時間。你拿回來的是一份報告，從來不是一份被改過的檔案。
這就是為什麼報告先講讀檔時丟失了什麼，然後才顯示發現。結束時間不在開始之後的字幕條會被給一毫秒，好讓檔案其餘的部分能被讀取、預覽與匯出；這些修復的次數列在報告開頭，底下那筆發現則寫著一筆錯誤、沒有字幕條編號，因為修復是讀檔當下累計的，不是存成清單的。兩行描述的是同一個壞掉的時間碼的兩面，所以它們屬於同一份報告，而不是分兩份。
這一頁必須繞開的陷阱是：一條貨真價實的一毫秒字幕條，看起來和被修好的那條一模一樣。所以這項檢查完全不看時長——它看的是修復紀錄——一條真的只停留一毫秒的字幕條不會被動到。負的時長與零長度是同一種缺陷，合併計算。有兩種格式完全不接受，而這一次兩邊的理由是同一個：LRC 的每個結束時間都從下一個時間戳推出來，所以那裡的一對時間不可能倒過來；純文字則根本沒有字幕條時間。檢查這兩者，等於對一個格式並不存在的欄位開出一份乾淨報告——那是唯一比沒有答案更糟的答案。
範例
沒有時長的字幕條
字幕
1
00:00:01,000 --> 00:00:02,000
Where were you?
2
00:00:03,000 --> 00:00:03,000
I was working late.
報告發現了什麼
Cues ending before they start — 1 found
Lost while reading: Timing × 1
Severity Cues Start End Measured
Error — — — 1 items
結束時間等於開始時間。讀取器給這條字幕一毫秒，檔案才留得住，並記下這次修復，報告則把兩半都印出來：開頭的丟失那一行，與底下一筆錯誤。修復才是證據；那一毫秒只是證據呈現出來的形狀。
真的只停留一毫秒的字幕條
字幕
1
00:00:01,000 --> 00:00:02,000
Where were you?
2
00:00:03,000 --> 00:00:03,001
I was working late.
報告發現了什麼
Cues ending before they start — Nothing found
Cues 2
Checks run 1
Lost while reading Nothing
手寫成停留一毫秒，沒有被回報。這個決定決定了整項檢查的形狀：被修好的零長度字幕條也會變成一毫秒，所以一條在這裡標記短時長的規則，會把每一份含壞時間碼的檔案都說成塞滿了短到不可能的字幕條。
結束時間在開始之前
字幕
1
00:00:01,000 --> 00:00:02,000
Where were you?
2
00:00:05,000 --> 00:00:02,000
I was working late.
報告發現了什麼
Cues ending before they start — 1 found
Lost while reading: Timing × 1
Severity Cues Start End Measured
Error — — — 1 items
五秒到兩秒：和零長度那個案例是同一種缺陷，用同一條規則計算，回報的樣子也一樣。檔案裡什麼都沒有被改寫——修好的時間只存在於讀取器的副本裡，好讓其餘部分能被處理，而那並不是這一頁提供的修復。
常見問題
什麼樣的情況算結束早於開始？
結束時間不晚於開始時間：可能是等於，例如 00:00:03,000 到 00:00:03,000；也可能是更早，例如 00:00:05,000 到 00:00:02,000。兩者是同一種缺陷，合併計算，而且都是從讀取器做的修復來計算，不是從字幕條本身，因為那種形狀的時間碼根本留不住在記憶體裡。
為什麼報告沒有點名字幕條？
因為這些修復是在讀檔過程中累計的，並沒有蒐集成一份清單。報告給的是次數——一筆錯誤、開頭丟失那一行的一項——兩半是同一件事，一邊從開頭看，一邊從發現區看。若你需要確切是哪一條，請在檔案裡搜尋它那兩個時間碼，而不是找字幕條編號。
停留一毫秒的字幕條算問題嗎？
在這裡不算，而且這是刻意的。手寫的一毫秒字幕條是合法的，不會被回報；被回報的是不得不修復的時間碼，而它修完之後剛好也以一毫秒的形式存著。改看時長而不是看修復，會把每一份含零長度字幕條的檔案都判成塞滿短到不可能的字幕條，那是錯了兩次的發現。
這一頁會修好它找到的時間碼嗎？
不會。修好的時間只存在於瀏覽器裡，好讓其餘的檔案能被讀取與回報。你下載或拖進來的檔案沒有改變，而且這一頁也沒有辦法把修好的版本存下來——替換一個壞掉的時間碼是操作，產物是一份字幕檔案，不是檢查。
哪些字幕格式可以檢查結束早於開始的字幕條？
十二種裡的十種：SRT、WebVTT、ASS、SSA、SBV、SMI、MicroDVD、TTML、JSON 與 CSV。少掉的兩種都不是疏忽。LRC 每行只存一個時間，讀取器用下一個時間戳推出每個結束時間，所以那裡的一對時間不可能倒過來——檢查它等於在評判一個格式並不存在的欄位。純文字則根本沒有字幕條時間。若你的檔案屬於這兩種，請先轉換。
這些壞掉的時間碼通常從哪裡來？
幾乎都是被產生的，不是被手打的。影格率換算時四捨五入的方向錯了、同一次平移被套用兩次、試算表匯出時結束欄留空而被讀成零，以及從定時文字檔抽出字幕時，某個本來就沒有時長的標記。
可以一次檢查好幾份檔案嗎？
可以。想拖幾個就拖幾個，它們會依序讀取，各自產生一份報告，最後一起以 zip 下載。佇列會逐檔顯示進度，執行到一半也能取消，而且整個過程沒有任何檔案被上傳。