SRT 轉 LRC
或者貼上字幕文字
這次轉換會改變什麼
有 2 項會被捨棄或需要你決定
- 時間
字幕的結束時間（輸出格式只記錄字幕何時開始）
- 精確度
時間精確度——輸出的時間刻度較粗，因此每個時間戳記都會四捨五入到最接近的 10 毫秒
這份清單來自這兩種格式的能力矩陣，而不是你載入的這份具體檔案。如果具體檔案用到了格式允許、但矩陣沒有建模的特性，可能會遺失更多。
這一頁把 SRT 轉成 LRC。目標不是影片播放器，而是歌詞播放器：它只需要知道每一列什麼時候開始。時間寫成 [mm:ss.xx]，精確到百分秒，SRT 的 00:00:04,126 會四捨五入成 [00:04.13]，每條字幕最多移動 5 毫秒，不拉伸也不重排。
結束時間會被丟棄——歌詞播放器會讓一列留到下一列開始，終點是多餘的。這也讓這個方向的損失清單有兩項：時間（結束時刻）與精度（毫秒降到 10 毫秒級）。一條兩行的字幕會輸出成兩列時間戳相同的歌詞，表示它們同屬一條；輸出依起始時間排序。
整季檔案可以一次拖入，佇列依序處理、可中途停止，結果打包成一個 ZIP。輸出固定為 UTF-8、Unix 換行、無 BOM；來源若是 UTF-16 或 Windows 單字元編碼，會在讀入時解碼並在結果面板說明。轉換全程在瀏覽器裡完成，檔案不上傳。
範例
一份典型的 SRT 檔案轉成 LRC
輸入
1
00:00:01,000 --> 00:00:03,500
Hello there.
2
00:00:03,500 --> 00:00:06,000
<i>Whispering</i> now.
And a second line.
3
00:00:06,000 --> 00:00:09,250
<b>Bold</b> statement.
輸出
[00:01.00]Hello there.
[00:03.50]Whispering now.
[00:03.50]And a second line.
[00:06.00]Bold statement.
這份產物遺失了結束時間與毫秒精度；起始時間依 10 毫秒取整，文字逐列保留。
同一轉換遇到一份格式不規則的輸入
輸入
1
0:00:01,00 --> 0:00:03,500
<B>Bold</B> and <I>italic</I>.
2
00:00:03,500 --> 00:00:06,000
3
00:00:08,000 --> 00:00:09,000
Last one.
輸出
[00:01.00]Bold and italic.
[00:03.50]
[00:08.00]Last one.
壞掉的時間碼與空條目不會被當成歌詞；讀得懂的條目照常寫出，讀不了的記進有損說明。
常見問題
SRT 轉 LRC 後每條字幕的結束時間去哪了？
LRC 只記錄一列何時開始。歌詞播放器會讓一列留到下一列開始，所以結束時間是多餘的；每個結束時刻都會被丟棄，每個 SRT 的開始時刻則原樣保留。
SRT 的 00:00:04,126 轉成 LRC 會變成什麼？
LRC 寫成 [00:04.13] 這種百分秒格式，而 SRT 寫成 00:00:04,126，所以每個時間碼會取整到最近的 10 毫秒，00:00:04,126 會變成 4.13 秒。沒有任何字幕移動超過 5 毫秒，但若要和另一份檔案逐格對齊，這裡就是唯一不再精確的地方。
SRT 轉 LRC 後產物長什麼樣子？
像 LRC：沒有字幕編號，每一列都帶著自己的方括號時間戳。每條 SRT 字幕會變成一條 LRC 歌詞，順序相同、文字相同。
SRT 轉 LRC 時一條兩行字幕會怎麼輸出？
變成兩列時間戳相同的歌詞，這是 LRC 表示「這兩句屬於同一條」的方式；兩行的配對關係保留，播放器會一起顯示。
SRT 轉 LRC 後字幕順序會保留嗎？
會，而且過程中會依開始時間排序，最早的在前。若你的 SRT 本來是亂序的，LRC 產物會把它排回順序；這改的是檔案結構而不是內容，而且是有意為之。
LRC 轉回 SRT 會有什麼代價？
反方向有自己的清單：LRC 轉 SRT 會遺失時間，因為 LRC 根本沒有結束時刻，寫回 SRT 時必須補一個預設時長。那份清單和上方不同，因為兩種格式各自保留的東西不一樣。
SRT 轉 LRC 後會保留來源檔案的編碼嗎？
不會，產物固定是 UTF-8、Unix 換行、無 BOM，無論 SRT 原本用什麼編碼。UTF-16 或 Windows 單字元編碼的檔案會在讀入時解碼（發生時結果面板會說明），輸出永遠是同一種 UTF-8 LRC。