[功能优化] 处理歌词时间重叠时的失焦和定位问题（接 #1828）

[yufeng770]

在反馈此问题前请注意 Please note before reporting this issue

• 已经查看相关帮助内容 Read more about the Salt Player help content
• 已经在本仓库搜索相关内容（避免重复反馈）Already searched for related content in this repository (to avoid duplicate feedback)
• 确认仅将提交一个问题（多个问题或者备注提及另外的问题请重新提交新的，如建议 1、2、3 请分开提交。即便是针对某个功能的不太相关的点也应该分开提交，如歌词建议支持大小和颜色调节，应该分开提交大小、颜色的建议）Confirm to submit only one issue (if multiple issues or notes mention other issues, please submit a new one separately)

平台 Platform

• Android
• Windows
• HarmonyOS

描述 Describe

描述：

目前歌词失焦/换行逻辑主要依赖下一行的开始时间。当两行歌词存在时间重叠（哪怕只有几毫秒）时，（A行）在自身结束后不会立即变暗，而是要等（C行）开始才会失焦，导致高亮视觉上卡住。

按照 #1828 中的方案，可以利用 SPL 的“行到达但首字未开始”机制，通过提前（C行）的开始时间来触发失焦。

以这首歌为例：

原数据：

[01:21.80]<01:21.80>And<01:22.23> <01:22.23>I<01:22.84> <01:22.84>love<01:23.60> <01:23.78>you,<01:24.43> <01:24.70>it's<01:25.09> <01:25.38>ru<01:25.65><01:25.65>in<01:25.96><01:25.96>ing<01:26.25> <01:26.25>my<01:26.89> <01:26.89>life<01:27.78>[01:27.78]
[01:27.13]<01:27.13>I<01:27.82> <01:27.82>love<01:28.43> <01:28.76>you,<01:29.33> <01:29.69>it's<01:30.25> <01:30.37>ru<01:30.62><01:30.62>in<01:30.92><01:30.92>ing<01:31.24> <01:31.24>my<01:31.82> <01:31.82>life<01:32.71>[01:32.71]
[01:32.11]<01:32.11>I<01:32.84> <01:32.84>touched<01:33.49> <01:33.75>you<01:34.39> <01:34.65>for<01:35.14> <01:35.32>on<01:35.62><01:35.62>ly<01:35.94> <01:35.94>a<01:36.22> <01:36.22>fort<01:36.86><01:36.86>night<01:37.69>[01:37.69]

修改后（将第三行行时间强行提前到 01:27.79）：

[01:21.80]<01:21.80>And<01:22.23> <01:22.23>I<01:22.84> <01:22.84>love<01:23.60> <01:23.78>you,<01:24.43> <01:24.70>it's<01:25.09> <01:25.38>ru<01:25.65><01:25.65>in<01:25.96><01:25.96>ing<01:26.25> <01:26.25>my<01:26.89> <01:26.89>life<01:27.78>[01:27.78]
[01:27.13]<01:27.13>I<01:27.82> <01:27.82>love<01:28.43> <01:28.76>you,<01:29.33> <01:29.69>it's<01:30.25> <01:30.37>ru<01:30.62><01:30.62>in<01:30.92><01:30.92>ing<01:31.24> <01:31.24>my<01:31.82> <01:31.82>life<01:32.71>[01:32.71]
[01:27.79]<01:32.11>I<01:32.84> <01:32.84>touched<01:33.49> <01:33.75>you<01:34.39> <01:34.65>for<01:35.14> <01:35.32>on<01:35.62><01:35.62>ly<01:35.94> <01:35.94>a<01:36.22> <01:36.22>fort<01:36.86><01:36.86>night<01:37.69>[01:37.69]

虽然可以让A行正常显示，但有两个副作用：

1. 点击C行进行定位时，会跳到被提前后的 01:27.79，而不是C行的时间 01:32.11。
2. 主流平台获取的歌词中，单人演唱歌曲也经常存在上下行几毫秒的重叠。如果大量使用延迟逐字方案，需要改动很多时间戳，还可能引发后续歌词的连锁影响。

优化建议

SPL 本身已经支持显式结束时间戳（例如 [01:27.78]），可以考虑正常情况下，仍然使用“下一行开始”作为失焦条件。但当检测到时间重叠时，改为使用当前行自身的显式结束时间戳作为失焦触发条件。

这里附上相关音频供参考，这首歌存在大量重叠不到一秒的情况：