字幕依顯示時間拆分
或者貼上字幕文字
選項
一個時長 —— 3000、3s、1m30s 和 00:00:03,000 都可以。任何在畫面上停留超過這個時長的字幕都會被分成若干段，所以一條 8 秒的字幕在這裡填 3000 會變成三條，時間平均分配，與各段文字長短無關。當問題在於字幕停留太久時用這個；當問題在於文字太多時，用另一頁的字元數欄位。
時間以哪個影格率計算。在格式頁面上，這是 MicroDVD 需要的值，因為它把時間存成影格編號。在影格率頁面上，它是檔案當初對應的速率 —— 字幕是照這個版本製作的 —— 而頁面的第二個欄位填你要搭配的影片速率。常見的有 23.976、24、25、29.97、30、50、59.94 和 60。填錯會讓整條時間軸位移；在影格率頁面上，位移是按比例發生，而不是固定的量。
這一頁把在螢幕上停留超過上限的字幕條分成好幾段。上限預設 7000 毫秒——七秒，多數體例給的單條字幕天花板——如果你是按秒而不是按字元了解檔案，這就是你要的頁。一條八秒的字幕、上限三秒，會變成三段各約 2667 毫秒。
段數由時長算出，不用手動數，時間在各段之間平均分配。文字接著在離這些等分點最近的詞邊界處切開，所以各段字元數很少完全相同。這是刻意的：你要的是時長，工具保證的就是時長，文字只能在整詞的範圍內盡量跟上。
被拆字幕之外什麼都不會移動。正好等於上限的字幕保持原樣，沒有任何一條超長的檔案會逐位元組返回——這個工具只做拆分，所以上限設高了是對陌生檔案最安全的一次執行。把上限調低會得到更短的段、更多的段，但各段加起來仍然精確等於原本的區間。
與這裡每一頁一樣，檔案在瀏覽器分頁裡讀取、拆分、寫回，不上傳任何位元組。SRT、WebVTT、ASS、SSA、SBV、SAMI、MicroDVD、TTML、JSON 與 CSV 都接受，條數改變的檔案按時間軸順序從 1 編號寫出。
範例
八秒的字幕碰上三秒上限
輸入
1
00:00:00,000 --> 00:00:08,000
The rain kept falling all through the night and no one in the house could sleep.
輸出
1
00:00:00,000 --> 00:00:02,667
The rain kept falling all
2
00:00:02,667 --> 00:00:05,333
through the night and no one
3
00:00:05,333 --> 00:00:08,000
in the house could sleep.
切成 2667、2666、2667 毫秒——取整的零頭有去處，最後一段拿走剩下的，讓總長精確收在 8000 毫秒。切點落在 all 之後與 one 之後，這是三分之一與三分之二處最近的詞邊界，所以各段是 25、28、25 個字元，而不是各 26 個。
剛好等於上限的一條，和超過一毫秒的一條
輸入
1
00:00:01,000 --> 00:00:04,000
Exactly three seconds long.
2
00:00:05,000 --> 00:00:08,001
Just one millisecond too long.
輸出
1
00:00:01,000 --> 00:00:04,000
Exactly three seconds long.
2
00:00:05,000 --> 00:00:06,501
Just one millisecond
3
00:00:06,501 --> 00:00:08,001
too long.
第一條正好 3000 毫秒，完整留下；第二條 3001 毫秒，從中間切開。這就是「長於上限」的誠實讀法，也是上限少一毫秒會讓每條正好落在線上的字幕都被拆成兩段的原因。定數字之前先檢查檔案裡的時長。
什麼都碰不到的上限
輸入
1
00:00:01,000 --> 00:00:02,000
Short.
2
00:00:03,000 --> 00:00:03,900
Also short.
輸出
1
00:00:01,000 --> 00:00:02,000
Short.
2
00:00:03,000 --> 00:00:03,900
Also short.
三十秒比這裡任何一條都寬，所以檔案原樣返回。上限設得寬不會合併或拉伸任何東西：這一頁只拆字幕、不做別的，所以這也是查出檔案最長一條有多久的安全做法。
常見問題
按時長拆分的 7 秒上限來自哪裡？
七秒是單條字幕最常被引用的天花板，它其實是閱讀速度規則的化身：普通讀者每秒約讀 15 到 20 個字元，一條兩行 84 個字元的字幕需要接近五秒，讀得慢的人還要更多。廣播規範並不統一——若干歐洲體例定在六秒——所以把這個欄位當起點，並核對你交付對象的規定。工具只執行欄位裡的數字，自己不作判斷。
按時長拆分怎麼決定一條字幕要拆成幾段？
用時長除以上限並向上取整，所以 8000 毫秒對 3000 毫秒是三段，8000 對 4000 是兩段。各段隨後平均分配區間，因此邊界落在原字幕的三分之一、二分之一處，而不是落在其中的句子或行上。想讓切點跟著文字走，應使用按字元或按句拆分的那兩頁。
時長上限設到 1 毫秒，按時長拆分會拆出幾千段嗎？
每條字幕最多 200 段，而且還有一條在實務上更要緊的限制：一段不能短於一毫秒。所以九秒的字幕配上 1 毫秒上限會得到 200 段而不是 9000 段，報告會說上限未能達到。這是防止誤敲一個鍵就把一條字幕變出一份檔案的護欄，不是現實中會碰到的限制。
按時長拆分會影響整份檔案的時間軸嗎？
不會。被拆字幕的各段正好填滿原字幕占據的區間，其他每條字幕精確到毫秒保持原時間。唯一會變的是編號，因為條數改變的檔案會按時間軸順序從 1 寫出。如果被拆的字幕原本帶樣式，樣式留在第一段，報告會說明有多少新段沒有樣式。
字幕停留太久但只有一行字，該用按時長拆分嗎？
只能部分解決。這一頁能把這樣的字幕切成兩段，但兩段都只承載同一行短字的其中一部分，通常不算改善——讀者把同樣的話分兩次讀完。因為沒別的事情發生而賴著的字幕，更適合直接修時間本身，也就是平移與比例縮放兩頁，同時確認它是否本來就該覆蓋對白中的一個停頓。
檔案太大時，按時長拆分還能處理嗎？
最大讀取 64 MB，遠大於任何字幕軌：一小時影片約 100 KB。超過上限時頁面會明確說明而不是悄悄失敗，因為那種體積幾乎肯定不是字幕檔。特別大的真實檔案——比如整季——最好按集分批跑，每份下載都能檢查過再繼續。