SBV 转 LRC
或者粘贴字幕文本
这次转换会改变什么
有 2 项会被丢弃或需要你决定
- 时间
字幕条的结束时间（输出格式只记录字幕条何时开始）
- 精度
时间精度——输出的时间刻度更粗，因此每个时间戳都会四舍五入到最接近的 10 毫秒
这份清单来自这两种格式的能力矩阵，而不是你加载的这份具体文件。如果具体文件用到了格式允许、但矩阵没有建模的特性，可能会丢得更多。
SBV 转 LRC 是给歌词播放器准备时间戳：一行一条，方括号里是开始时间，后面跟文本。结束时间在这类播放器里没有意义。
LRC 的格式是 `[mm:ss.xx]` 加文本，没有 cue 序号，也没有文件头。SBV 里两行的字幕会变成两行、共用同一个时间戳——这是 LRC 表达“这两句属于同一条”的方式。
代价有两处。结束时间全部丢掉：播放器会让一行一直留到下一行开始，所以 SBV 的每个结束时刻都没有落点，开始时刻原样保留。精度也降了一档——LRC 写到百分秒，`0:00:04.126` 取整成 `[00:04.13]`，每条最多挪 5 毫秒；如果这些字幕还要和别的文件对齐，这就是唯一不精确的地方。SBV 本来就没有样式可丢，所以没有别的损失。
cue 会按开始时间排序，乱序文件会被排好。整季文件一次拖入，串行处理、可取消、打包成 ZIP；输出 UTF-8、Unix 换行、无 BOM；全过程在浏览器里，文件不上传。
示例
一份典型的 SBV 文件转成 LRC
输入
0:00:01.000,0:00:03.500
The quick brown fox.
0:00:04.000,0:00:06.250
Jumps over the lazy dog.
0:00:07.000,0:00:09.000
Two lines here.
And a second one.
输出
[00:01.00]The quick brown fox.
[00:04.00]Jumps over the lazy dog.
[00:07.00]Two lines here.
[00:07.00]And a second one.
这份产物丢掉了结束时间与精度；其余部分逐行一致。
同一转换遇到一份不规范但可读的输入
输入
0:00:02.000,0:00:04.000
Carriage-return line endings.
0:00:06.000,0:00:08.000
Indented timecode, no final newline.输出
[00:02.00]Carriage-return line endings.
[00:06.00]Indented timecode, no final newline.
真实文件里常见的损坏：混合换行、散落的空白、留空的字段。可以对照上面那份干净样例，看看解析器能容忍到什么程度。
常见问题
SBV 转 LRC 后，每条字幕的结束时间去哪了？
被丢弃了。LRC 只记录一行什么时候开始，播放器会让这一行一直留到下一行开始，所以结束时刻在 LRC 里是多余的；开始时间则原样保留。
SBV 转 LRC 时时间码为什么会变？
LRC 存到百分之一秒，SBV 存到千分之一秒，所以 `0:00:04.126` 会取整成 `[00:04.13]`，每条最多挪 5 毫秒。顺序不变、时长不拉伸，但这层取整躲不掉。
SBV 里两行的字幕转成 LRC 后是几行？
两行，而且共用同一个时间戳。这是 LRC 表达“这两句属于同一条字幕”的写法：同一时刻起两句歌词，播放器会一起显示。
SBV 转 LRC 会丢失样式吗？
不会额外丢什么——SBV 本身就不存样式，LRC 也不存。这一页的损失只有两类：每条 cue 的结束时间，以及时间码从毫秒取整到百分秒。
SBV 转 LRC 后 cue 的顺序会变吗？
会按开始时间排序，最早的在前。原始文件如果乱序，产物会替你排好；这改的是结构不是内容，是有意为之。
SBV 转 LRC 的产物用什么编码？
固定 UTF-8、Unix 换行、不带 BOM，与源文件原本的编码无关。整季文件可以批量转换，可中途取消，结果打成一个 ZIP，全程不上传。