MicroDVD 转 LRC
或者粘贴字幕文本
选项
时间按哪个帧率计算。在格式页面里，这是 MicroDVD 需要的值，因为它把时间存成帧号。在帧率页面里，它是文件当初对应的速率 —— 字幕是按这个版本做的 —— 而页面的第二个框填你要拿它配套的视频速率。常见的有 23.976、24、25、29.97、30、50、59.94 和 60。填错会让整条时间轴偏移；在帧率页面里，偏移是按比例发生的，而不是一个固定的量。
这次转换会改变什么
有 3 项会被丢弃或需要你决定
- 时间
字幕条的结束时间（输出格式只记录字幕条何时开始）
- 帧率
源文件以帧号存储时间——每个时间戳都取决于你提供的帧率
- 精度
时间精度——输出的时间刻度更粗，因此每个时间戳都会四舍五入到最接近的 10 毫秒
这份清单来自这两种格式的能力矩阵，而不是你加载的这份具体文件。如果具体文件用到了格式允许、但矩阵没有建模的特性，可能会丢得更多。
这一页把 MicroDVD 写成 LRC：每行一个方括号时间戳，例如 `[00:04.00]正文`。LRC 是歌词格式，它只记一行什么时候开始，不记什么时候结束——歌词播放器会把这一行留到下一条开始为止。
因此每条 cue 的结束帧都被丢掉，开始帧则原样换算出时间。精度也随之降低：LRC 写厘秒，MicroDVD 换出来的毫秒要四舍五入到 10 ms，单条最多偏 5 ms。帧率这一维同样没有落点：LRC 里没有帧号，也没有记录“按多少 fps 读”的字段。
正文里的 `|` 会写成两行同时间戳的 LRC。这是 LRC 表达“这两行属于同一条字幕”的方式——它没有 cue 分组，只能靠相同的时间戳把它们绑在一起。
产物按开始时间升序，UTF-8、LF、无 BOM；源文件编码不同会先解码并在结果面板说明。批量时串行、可取消、ZIP 打包，不上传。
示例
一份典型的 MicroDVD 文件转成 LRC
输入
{1}{1}25
{100}{150}The quick brown fox jumps over the lazy dog.
{200}{260}Faster than|the last one.
输出
[00:04.00]The quick brown fox jumps over the lazy dog.
[00:08.00]Faster than
[00:08.00]the last one.
产物丢掉了结束时间、帧率与精度；其余逐行一致。
同一转换遇到一份脏文件
输入
{1}{1}23.976
{0100}{0150}Leading zeros in the frame numbers.
[INFORMATION]
{300}{340}An unrecognized line above was kept in place.
{400}{450}Trailing spaces are kept.
输出
[00:04.00]Leading zeros in the frame numbers.
[00:12.00]An unrecognized line above was kept in place.
[00:16.00]Trailing spaces are kept.
真实文件常见的损坏：混合换行、BOM、散布的空白、带前导零的帧号、认不出的行。可以对照上面那份干净样例，看解析器能容忍到什么程度。
常见问题
MicroDVD 转 LRC 后，每条 cue 的结束时间去哪了？
被丢掉了。LRC 只存开始时刻，播放器把一行保持到下一条开始；结束帧在这里没有对应的写法。
MicroDVD 转 LRC 时，竖线分隔的两行怎么写？
写成两行 LRC，时间戳相同。这是 LRC 唯一能表达“这两行一起出现”的手段，顺序保持原文。
MicroDVD 转 LRC 的时间码为什么只到百分秒？
LRC 的 `[00:04.12]` 只到厘秒，毫秒换算后四舍五入到最近的 10 ms。时间轴不会被拉伸，但单条可能移动最多 5 ms。
MicroDVD 转 LRC 时帧率填错会怎样？
每个时间戳都按比例偏。填 25 读一份本该 23.976 的文件，开头差得少，越往后差得越多；LRC 里没有任何字段能把这件事记下来。
MicroDVD 转 LRC 会保留“第 100 帧”这个信息吗？
不会。产物只有时钟时间戳，帧号与帧率都不保留。要保留帧号请留原始 `.sub`。
LRC 再转回 MicroDVD 会丢掉什么？
丢掉时间轴（结束时间）与帧率。回头写 MicroDVD 时要重新指定帧率，并重新给每条字幕补一个结束帧。