[Bug] LRC 歌词无法正确解析空时间标签和逐字时间标签，导致歌词结束时间异常 #120

检查清单

• 我已检索仓库中所有的 Issues，确保我没有重复提交问题；或有相似 Issue，但我觉得我的情况不包含在那个相似 Issue 之内
• 我已经找到了可以复现这个问题的方法，并且写在了下面的「具体信息」中
• 此问题可以在我的设备和当前环境中稳定复现
• 此问题可以在最新版本 (Latest Release) 中复现
• 此问题是在我更新到当前版本后才出现的

当前系统环境

Hyprland 0.55.4

当前 Node.js 及 npm 版本

v26.4.0/v12.0.1

当前版本

v1.0.0/ff176e85587eaceb48a52417065b480c39702fd9

具体信息

描述

使用 LRC 格式歌词时( TTML 格式没有同样问题)，SPlayer 的桌面歌词在某些歌曲中会出现时间轴错乱或卡顿的问题。经过测试对比，问题似乎与以下两种 LRC 时间标签的解析有关：

1. 空时间标签（只有时间戳，无歌词内容）
2. 逐字时间标签（mm:ss.cc 内嵌时间码）

复现步骤

案例一：空时间标签

以宋冬野《安河桥》的 LRC 为例（SPlayer 内置下载）：

[03:26.27]所以你好再见
[03:31.53]      ← 空行，仅有时间戳，无歌词内容

预期行为：[03:31.53] 这个空时间戳应被视为一个时间节点，表示前一句 [03:26.27]所以你好再见 的结束时间为 03:31.53，然后歌词进入空白/等待状态，直到 xx:xx.xx 显示下一句(如果有的话)。

实际行为：SPlayer 忽略或错误解析了 [03:31.53]，播放器没有识别空时间标签作为结束节点，因此上一句歌词一直保持显示，直到下一条非空歌词出现（若之后没有歌词，则持续到歌曲结束）

案例二：逐字时间标签

测试歌曲中出现的逐字歌词格式：

[03:26.27]<03:26.27>所<03:26.57>以<03:26.85>你<03:27.21>好<03:29.94>再<03:30.45>见<03:31.53>

预期行为：每个字或词在对应的时间点高亮/切换，最后一个字应在 03:31.53 结束。
实际行为：SPlayer 无法正确解析 <03:31.53> 为结束时间，导致最后一个字停留长时间。

额外测试结果

为排除播放器或歌词文件本身的问题，我在以下环境中进行了对比测试(均使用没有内嵌歌词的mp3文件，歌词为同目录下同名文件)：

上述测试表明，该 LRC 文件本身并无问题，其他播放器能正确识别空时间标签，且 Salt Player 对逐字时间标签也有良好支持。

最小复现测试文件

案例一：空时间标签

[00:00.00]A
[00:01.00]
[00:02.00]B

预期行为：

00:00 ~ 00:01  A
00:01 ~ 00:02  （空白）
00:02          B

实际行为：

00:00 ~ 00:02  A

案例二：逐字时间标签

[00:00.00]<00:00.00>A<00:01.00>B<00:02.00>

预期行为：

A：00:00 ~ 00:01
B：00:01 ~ 00:02

实际行为：

B 一直保持显示，未在 00:02.00 时结束

建议

建议 LRC 解析器：

• 将空时间标签视为上一句歌词的结束时间；
• 对逐字时间标签，至少正确识别最后一个时间标签作为结束时间，即使暂不支持逐字高亮。

补充说明

虽然 #661 - 修复带翻译 LRC 的结束时间问题 修复了带翻译 LRC 的结束时间问题，但本 Issue 涉及的是另外两种 LRC 时间标签的解析：

• 空时间标签（Empty timestamp line）
• 内嵌逐字时间标签（Inline per-word timestamps）

它们与翻译歌词的问题属于不同的解析逻辑，建议作为独立问题处理。