LRC 檔案是一個純 UTF-8 文字檔，每一行歌詞前面都有一個方括號包裝的時間戳，格式為 [mm:ss.xx]，其中 mm 代表分鐘(兩位數或三位數),ss 代表秒數(從 00 到 59),xx 代表百分秒(從 00 到 99)。如果你想從已有的文字建立 LRC 檔案，只要把歌詞貼進簡單的 LRC 產生器，設定起始時間戳和固定間隔，工具就會自動為每一行加上時間戳，採用大多數播放器都能解析的實際通用格式。下載的檔案副檔名為 .lrc，在每一行保留下來的歌詞前面都有一個對齊到百分秒的時間戳，並可能包含最多三個可選的詮釋資料標籤 —— [ti:] 代表標題、[ar:] 代表演出者、[al:] 代表專輯。由於格式只是文字加上方括號，任何 UTF-8 編輯器都能開啟它，但大多數音樂播放器只有在時間戳準確對上節拍時才會捲動歌詞，這就是為什麼固定間隔的起始檔案在後續必須用專門的編輯器逐行重新對齊時間。
純文字中的 LRC 檔案長什麼樣子
一個簡單的 LRC 檔案由三個組成部分構成:頂部的可選詮釋資料標籤、一行空白分隔行，以及底下一系列有計時的歌詞列。每一個有計時的列都將一個 [mm:ss.xx] 時間戳與播放器到達該時間點時應顯示的歌詞文字配對在一起。分鐘欄位使用兩位數或三位數，秒數欄位永遠是 00 到 59 之間的兩位數，兩者之間以一個小數點分隔，小數點後面剛好兩位數代表百分秒。這個實際通用的格式被廣泛描述，包括在 QuickLRC 的 LRC 字幕格式參考資料 中，而獨立的 Subforge LRC 時間模組也確認了相同的算術 —— 分鐘貢獻 60,000 毫秒，秒數貢獻 1,000，後面兩位數代表百分秒。
一個有效的檔頭區段可能長這樣:
[ti:歌曲標題][ar:演出者名稱][al:專輯名稱]
接著有計時的歌詞區塊會繼續以下列形式排列:
[00:12.34]歌曲的第一行[00:15.84]歌曲的第二行[00:19.34]歌曲的第三行
這個結構就是完整的合約。任何更複雜的內容 —— 以尖括號包裝的增強型逐字時間戳、卡拉 OK 對唱標記、三位數的毫秒、或小時欄位 —— 都屬於擴充版 LRC 變體，並非每個播放器都支援，而一個保守的簡單 LRC 產生器會刻意省略這些內容，讓你產生的檔案能在最多元的播放器上以相同方式解析。
將純文字轉為 LRC 檔案:逐步教學
依照下列步驟，使用 LRC 檔案產生器 把你的純歌詞文字轉成可用的 .lrc 檔案。
- 在瀏覽器中開啟產生器。整個工作流程都在本機執行，不需要註冊、帳號或上傳，也不會有任何資料離開目前的分頁。
- 把歌詞文字貼進歌詞輸入框，每一列剛好放一個顯示事件。工具接受 1–500 行非空白的內容，會自動移除空白的列，並拒絕控制字元，避免它們悄悄溜進播放器可能無法一致解析的檔案。
- 以 MM:SS.xx 格式輸入第一個時間戳。有效的範例包括 00:00.00、09:59.99、10:00.00，以及 123:45.67 —— 頁面會在產生之前強制執行秒數兩位數從 00 到 59 的規則以及百分秒兩位數的規則。
- 設定連續行之間的間隔。任何從 0.01 到 600.00 秒之間的值都可以接受，且小數位數不超過兩位。這個小數值會在產生任何列之前先轉換為整數的百分秒數，因此累加過程不會像二進位浮點運算那樣產生漂移。
- 選擇性填寫標題、演出者和專輯欄位。這些會成為檔案頂部的 [ti:value]、[ar:value] 和 [al:value] 標籤，每個欄位最多截為 120 個字元，並移除方括號和控制字元，因此單一欄位無法注入額外的 LRC 標籤。
- 點擊 Generate 並檢查預覽。預覽就是完整、未截斷的檔案 —— 第一個和最後一個時間戳都會顯示在裡面，而任何對輸入的修改都會清除先前的預覽，讓你絕不會讀到過時的結果。
- 點擊 Download 以 UTF-8 編碼(不含位元組順序記號)儲存副檔名為 .lrc 的檔案。檔名來自你提供的標題;不安全的標點符號會被替換為連字號，而空白的標題則會產生 synced-lyrics.lrc。
下載完成後，這個檔案就可以自行重新命名、重新對齊時間，或載入專門的編輯器中。
百分秒運算內部原理:間隔如何累加
這個產生器不會聆聽你的音訊，也不會對齊歌詞與人聲 —— 它只是把你選擇的間隔(以百分秒為單位)逐行加到起始時間戳上。理解這個運算能幫助你在下載之前預測預覽中的確切時間戳。
假設起始時間戳為 00:12.34，間隔為 2.50 秒。間隔會先轉換為整數的百分秒數(2.50 × 100 = 250)，然後這個整數會在不經過額外進位的情況下累加:
- 第 1 行:00:12.34
- 第 2 行:00:12.34 + 2.50 = 00:14.84
- 第 3 行:00:14.84 + 2.50 = 00:17.34
- 第 4 行:00:17.34 + 2.50 = 00:19.84
由於整個累加過程都使用整數百分秒，因此重複的加法不會累積二進位浮點運算通常會產生的小漂移。如果最終計算出來的時間戳會超過格式允許的最大值 999:59.99，產生動作會失敗，並且不會悄悄截斷任何內容，讓你能從原始輸入繼續作業，而不是從一個寫到一半的檔案繼續。無論你產生 10 行還是達到 500 行的上限，這個運算規則都一樣;只有起始時間和間隔會改變。
產生器強制執行的限制與驗證規則
由於簡單版 LRC 格式在設計上就很保守，產生器在產出任何結果之前會套用一組小範圍的硬性限制。預先了解這些限制能幫助你調整貼上的歌詞內容，讓檔案在第一次點擊時就能準備就緒。
| 輸入 | 限制 | 為何重要 |
|---|---|---|
| 歌詞列數 | 1–500 行非空白列，總字元數最多 50,000，每列最多 500 個字元 | 空白的列會被移除;過大的輸入會在預覽前被拒絕。 |
| 第一個時間戳 | MM:SS.xx，分鐘位數 2–3 位，秒數 00–59，百分秒剛好兩位 | 範例:00:00.00、09:59.99、10:00.00、123:45.67。 |
| 最大時間戳 | 999:59.99 | 若最終計算時間超過此值，產生動作會中止。 |
| 間隔 | 0.01–600.00 秒，小數位數不超過 2 位 | 會轉換為整數百分秒以避免浮點漂移。 |
| 標題 / 演出者 / 專輯 | 每個最多 120 個字元，不得包含方括號或控制字元 | 空白欄位會完全省略。 |
| 行尾符號 | CRLF、CR 和 LF 都可接受 | Windows、傳統 Mac 和 Unix 輸入都會在產生前統一標準化。 |
任何超出這些範圍的內容都會停止產生，而不是產出格式錯誤的檔案。這個工具絕不會編造歌詞，絕不會從第三方服務取得時間戳，也不會在你關閉分頁後儲存你的文字。
從草稿到定稿:依錄音重新對齊時間
你下載的檔案是起始草稿，而不是成品。實際的人聲很少以完全等距的間隔開始 —— 副歌會拉長、主歌會壓縮、間奏會留下空隙、口白開頭會提早出現。固定間隔的檔案能幫你從「沒有檔案」走到「每行都有時間戳的檔案」，這已經是困難的部分;更細緻的對齊則交給專門的歌詞編輯器，它會播放你的音訊並讓你用耳朵微調每個時間戳。
一個合理的重新對齊流程看起來像這樣:
- 把 .lrc 檔案和對應的音訊並排載入你的編輯器。
- 從頭開始播放，並針對每一行，把播放位置拖到歌手開始唱出該句的精確瞬間。
- 更新方括號中的時間戳，讓它以你的播放器常用的小幅偏移(通常是幾百毫秒，視播放器而定)領先歌詞列。
- 重新檢查副歌、橋段和任何重複的段落，因為同一段旋律在不同次演唱之間常會被拉長或縮短。
- 把重新對齊時間的檔案以對應的基底檔名儲存在音訊旁邊，讓播放器自動配對。
在整個流程中，歌詞文字、大小寫、標點符號，以及任何嵌入的版權聲明都會保持你原本輸入的樣子 —— 產生器不會改寫語言，只會放置時間戳。
為何播放器相容性仍然重要
不同的音樂播放器對 LRC 的實作方式不同。有些播放器會毫無異議地接受保守的 [mm:ss.xx] 簡單子集;其他則會尋找小時欄位、三位數的毫秒、增強型逐字時間戳，或產生器刻意不輸出的專屬標籤。編碼方式也有所不同 —— 你下載的檔案是沒有位元組順序記號的 UTF-8，這適用於絕大多數桌面和行動裝置播放器，但少數較舊的工具可能會在你以不同編碼重新儲存後，誤判非 ASCII 字元。
因此，最後一個步驟永遠相同:在你實際要使用的播放器中開啟檔案，從頭開始播歌，觀察每一行是否準時捲動。如果歌詞出現但整體偏早或偏晚，在你的編輯器中為每個時間戳加上或減去一個小幅偏移。如果某個播放器完全忽略 [ar:] 或 [al:]，簡單的詮釋資料子集仍然是最安全的基準 —— 它是幾乎每個播放器都同意的部分格式。
如果你的工作流程還需要為影片或卡拉 OK 曲目做字幕式計時，實用的後續做法是對應的 SRT 格式;歌詞 SRT 完整教學 詳細介紹了該轉換。