定时歌词编辑器
歌词
空行会被丢弃。已经以 [mm:ss.xx] 开头的行会保留那个时间。
拖入音频文件、粘贴歌词，然后按播放，在每句开始时敲打点键。一切都不离开这个标签页。
整体平移所有已打点的行
导出的 .lrc
一行有了时间之后才会出现在这里。
没有时间的行不会出现在两种导出里：一行必须先打点，才能在时间轴上有位置。
键盘快捷键
- K 或空格 —— 播放 / 暂停
- 左 / 右方向键 —— 后退 / 前进 5 秒
- R —— 为这一行打点并移到下一行
- T —— 在这一行之后插入一行
- Delete —— 清除这一行的时间
- 上 / 下方向键 —— 移到上一行 / 下一行
这一页把一首歌和一份歌词变成带时间轴的 .lrc。载入音频，粘贴歌词——纯文本、一行一句都行，也可以是已有时间戳、只想调整的 .lrc——按下播放，在每句开始的那一刻敲一下键。时间点取自音频元素当前的播放位置，所以它跟随你正在听的文件，而不是页面里的某个时钟。最后一行打完后，把结果导出为 .lrc，或者在你需要喂给字幕编辑器时导出为 .srt。
歌词列表就是全部模型。一行有文字和一个可选开始时间；没有开始时间的行，就是你还没走到的那一行。未打点的行留在编辑器里，方便回头补，但它们不会出现在导出产物里：没有开始时间的行在时间轴上没有位置，替它编一个时间等于把一行放在没人选过的时刻。这就是为什么一首歌只打了一半时导出的文件比眼前的列表短——那不是错。
四个操作覆盖了给歌词对时真正会出问题的地方。打点把一行设为当前播放时间，并自动移到下一行，于是一串歌词每行只需一次按键。清除用来撤掉早敲了半拍的时间点。插入用来补上粘贴时漏掉的一行。整体平移把所有已打点的行移动同样的毫秒数，这正是发现整份文件比人声晚一秒之后要做的事——行与行之间的相对间隔保持不变；负向平移会在零处停住，而不会写出播放器读不了的时间码。
时间模型就是 LRC 自己的模型。一行持续到下一条开始；最后一行没有下一条，所以给它两秒，这与本站遇到任何格式本身没有结束时间时的做法相同。导出 .srt 时，结束时间就来自这里——与转换页从 .lrc 文件推导出的时间轴是同一套，所以两条路给出一致的结果。厘秒是 .lrc 能记录的精度；12.346 秒会写成 12.34，所以导出的文件读回来可能与编辑器相差几毫秒。
音频由浏览器自带的音频元素打开，这一页从不读取、解析或上传它。没有任何携带它的请求；唯一的网络流量就是页面本身。歌词列表的草稿保存在本浏览器的本地存储里，误刷新不会让你丢掉一次工作；清除站点数据会一并删掉。关掉标签页后，歌与歌词不存在于任何服务器上。
示例
把纯文本歌词一次打点完成
歌词
First line of the song
Second line of the song
Third line of the song导出的 .lrc
[00:12.00]First line of the song
[00:15.30]Second line of the song
[00:18.75]Third line of the song每条已打点的行就是一条 cue。.lrc 导出写厘秒，所以 18.75 秒正是按键那一刻记录的值；18.754 秒会被写成 18.75。
给已有的 .lrc 重新对时
歌词
[00:12.00]First line of the song
[00:14.00]Second line of the song
Third line of the song导出的 .lrc
[00:12.00]First line of the song
[00:14.00]Second line of the song
[00:17.75]Third line of the song粘贴 .lrc 会保留它已有的时间戳。第三行进来时没有时间戳，在播放到它之前一直是未打点状态，后来在 17.75 秒被打上点。
常见问题
还没打点的歌词行会进入导出的 .lrc 吗？
不会。未打点的行没有开始时间，而 .lrc 只靠时间戳定位一行，没有东西可写。它留在编辑器列表里、旁边没有时间；当你播放到它并按下打点键，它才加入导出。这是有意的设计，不是限制：另一种做法是给这一行编一个时间，把它放在你从未选择过的时刻——那正是本站尽量避免的静默发明。
定时歌词编辑器导出的 .srt 里，最后一行歌词显示多久？
从它的开始时间起两秒。.lrc 本身没有结束时间——一行持续到下一条开始——所以最后一行没有可继承的终点。两秒是本站对任何格式本身没有结束时间的统一宽度，因此这个编辑器的 .srt 导出与 .lrc 转 SRT 页面用同一批时间点会得到同一条时间轴。如果歌里最后一句真的拖了八秒，事后平移或改时长是诚实的做法，把猜测藏进导出器则不是。
把歌词时间轴整体往前移过头会怎样？
那些行会停在零，编辑器会说明有多少行被截到边界。负时间码在 .lrc 和 .srt 里都不存在——播放器拿到它，要么拒绝文件，要么把这一行当作从最开头开始。平移的用途是修正整份文件晚了一秒这类偏移；当请求的位移会把第一行推到音轨起点之前，物理上说得通的结果就是零，其余行保持相对间隔，除非它们也被截住。
能粘贴一份已有 .lrc，只改其中错的行吗？
能，这正是编辑器在粘贴时读取 LRC 时间戳的原因。已经带 [mm:ss.xx] 标签的行保留时间；标签之后的文字才是你编辑的内容；没有标签的行从未打点状态开始。导入时 [ti:]、[ar:]、[offset:] 这类元数据行会被忽略，而不会当成歌词，因为它们不是任何人会唱的行。一行有多个标签时取第一个，因为编辑器的模型是一行一个开始时间。
音频会被上传，让定时歌词编辑器读取时长或波形吗？
不会，而且这里也没有波形。音频由浏览器内置的音频元素从本地文件句柄播放；这一页从不读取它的字节、不解码、也不发送任何携带它的请求。时间点来自按下按键那一刻音频元素的当前播放位置，这与波形能给出的数字是同一个。为一整首歌解码波形只会花掉内存和时间，却不会让打点更准。
为什么导出的 .lrc 与编辑器里的时间差几毫秒？
因为 .lrc 记录厘秒，而编辑器保存整数毫秒。12.346 秒会写成 [00:12.34]——四舍五入到百分之一秒，不是截断。读回文件得到 12.340 秒，所以每行最多差五毫秒，远低于播放器能显示的程度。需要精确时间点时改导 .srt：它带毫秒，而且两份文件来自同一个 cue 模型。