29.97轉23.976影格修正
或者貼上字幕文字
選項
時間以哪個影格率計算。在格式頁面上，這是 MicroDVD 需要的值，因為它把時間存成影格編號。在影格率頁面上，它是檔案當初對應的速率 —— 字幕是照這個版本製作的 —— 而頁面的第二個欄位填你要搭配的影片速率。常見的有 23.976、24、25、29.97、30、50、59.94 和 60。填錯會讓整條時間軸位移；在影格率頁面上，位移是按比例發生，而不是固定的量。
你要拿字幕搭配的那個版本的影格率 —— 也就是你實際要播放的影片。套用的係數是第一個欄位除以這一個，所以 24 轉 25 得到 0.96：影片在 PAL 上快 4%，100 分鐘的片子正好裝進 96 分鐘的帶子。兩個欄位填反了，整條時間軸會朝錯誤的方向位移同樣的量。
這一頁把時間軸按 29.97 fps 計數的字幕檔，放上 23.976 的時間軸。每個時間戳乘上 1.25——正好四分之五——所以檔案長了四分之一：四十八秒處的字幕變成一分鐘，一集三十分鐘、字幕卻說二十四分鐘的節目，會回到三十分鐘。兩個欄位已填好；如果你的檔案是按別的速率計數，再改。
錯誤與鏡像那一頁是同一道算術，只是從另一端看。影格編號屬於 23.976 時間軸，卻被 29.97 除，結果小了四分之一，因為 23.976 除以 29.97 是 0.8——整條時間軸被壓成五分之四，每條字幕提前 20%，影片愈到後面超前愈多。乘上 1.25 就是把這個錯誤除回去。
認出自己是哪一個方向，就是全部的工作，而症狀會告訴你。字幕愈來愈晚、一集二十四分鐘的節目最後一條卻宣稱三十分鐘，需要 0.8；字幕愈來愈早、一集三十分鐘的節目最後一條只宣稱二十四分鐘，需要這一頁。兩份檔案都來自同一批除錯的影格編號，差的只是錯誤的方向。
1.25 是精確值，理由與它的鏡像相同：29.97 是 30000/1001、23.976 是 24000/1001，共同的除以 1001 相消，29.97 除以 23.976 就是 30000 除以 24000——四分之五，沒有四捨五入、沒有餘數。每條字幕在螢幕上多拿到四分之一的時間，每行的閱讀速度因此下降 20%，這是這一組裡少數讓檔案壓力減輕的方向。檔案不會上傳，整季可以一次排隊跑完——SRT、WebVTT、ASS、SSA、SBV、SAMI、MicroDVD、TTML、JSON 與 CSV 都按真實格式讀取。
範例
把 1.25 套用在二十四分鐘的劇集上
輸入
1
00:00:01,000 --> 00:00:03,000
Hello there.
2
00:01:00,000 --> 00:01:02,000
One minute in.
輸出
1
00:00:01,250 --> 00:00:03,750
Hello there.
2
00:01:15,000 --> 00:01:17,500
One minute in.
最後一個時間戳從 00:24:00,000 移到 00:30:00,000。每個字都到了，只是整個節目變長，因為時間軸被拉長。
同一個比例，被一對參考點量出來
輸入
1
00:08:00,000 --> 00:08:02,000
Eight minutes in.
2
00:24:00,000 --> 00:24:02,000
Twenty-four minutes in.
輸出
1
00:10:00,000 --> 00:10:02,500
Eight minutes in.
2
00:30:00,000 --> 00:30:02,500
Twenty-four minutes in.
兩個時間戳都以同一個比例向零點拉開，零點因此不動。線性縮放全都如此，和從哪個時刻量參考點無關。
較長的檔案：十分鐘處
輸入
{1}{1}29.97
{300}{360}Hello
輸出
{1}{1}23.976
{300}{360}Hello
十分鐘變成十二分半。1.25 這個比例讓整份檔案在最後長了四分之一，和一開始就加多久無關。
常見問題
29.97 轉 23.976 的比例為什麼正好是 1.25？
因為兩個速率都是某個整數除以 1001——29.97 是 30000/1001、23.976 是 24000/1001——兩者相除，1001 相消，剩下 30000 除以 24000，也就是四分之五。沒有任何取整或近似，所以四十八秒處的字幕精確落在一分鐘。
字幕出現得太早而且愈來愈早，是 29.97 轉 23.976 嗎？
檢查早的量是不是已過時間的四分之一。八分鐘處早兩分鐘、二十四分鐘處早六分鐘、兩小時的影片早二十四分鐘，就是這一對。鏡像那一頁處理相反的症狀：字幕愈來愈晚的檔案需要 0.8 而不是 1.25。
可以用 29.97 轉 23.976 直接從 NTSC 影片轉到 PAL 嗎？
不能，繞這一頁是刻意的遠路。29.97 轉 25 是 1.19880，而且沒有這一頁，因為 29.97 是訊號的速率，不是畫面播放的速度——訊號裡的影片是用重複影格撐出來的，播放長度不變。從 NTSC 時間軸走到 PAL 的誠實路徑是先回到影片速率（就是這個轉換），再走 23.976 轉 25。
影片是 29.97、字幕看起來正確，29.97 轉 23.976 會毀了它們嗎？
會，而這是另一頁陷阱的鏡像。裝在 NTSC 訊號裡的影片套了 pulldown，用重複影格補滿、不改變播放長度，所以按那支影片對時的字幕本來就正確。只有影格編號被用錯速率除過的檔案需要轉換；把正確的檔案乘上 1.25，會讓每條字幕晚了四分之一。
29.97 轉 23.976 後時間軸長了四分之一，字幕長度與閱讀速度會怎樣？
每條字幕除了往後移動，時長也增加 25%，所以兩秒的一行拿到 2.5 秒，字完全沒變。這會讓每行的閱讀速度下降 20%，是這一組裡少數替檔案減壓的方向之一——另一個是 50 轉 25 的減半。
什麼樣的工作流程會留下偏早的檔案，該用 29.97 轉 23.976 嗎？
把容器的速率當成畫面的速率。NTSC 承載 29.97，工具若從影片讀到這個數字並拿它去除影格編號，就會把訊號裡的影片計得太短，因為影片本身跑的是 23.976，pulldown 只是填充。解法是宣告畫面真正跑的速率，也就是這一頁做的事：前面填 29.97，後面填 23.976。