Moriafly
对SPL格式的一个小疑惑
在反馈此问题前请注意 Please note before reporting this issue
- [x] 已经查看相关帮助内容 Read more about the Salt Player help content
- [x] 已经在本仓库搜索相关内容（避免重复反馈）Already searched for related content in this repository (to avoid duplicate feedback)
- [x] 确认仅将提交一个问题（多个问题或者备注提及另外的问题请重新提交新的）Confirm to submit only one issue (if multiple issues or notes mention other issues, please submit a new one separately)
描述 Describe
看到作者在 #764 中的 10.7.0-alpha02 中为增强型 LRC 提供了支持，而在 SPL 格式的规范文档中发现，作者针对增强 LRC 的支持出现了一些变化。
在SPL中，对增强 LRC 的支持如下文所述 https://moriafly.com/standards/spl.html#%E5%85%BC%E5%AE%B9%E6%80%A7%E4%B8%8E%E5%BB%B6%E8%BF%9F%E9%80%90%E5%AD%97%E6%A0%87%E8%AE%B0
这与增强型 LRC 的格式是不同的，根据维基百科对增强型 LRC 格式的定义，也是和目前foobar 2000的知名插件ESLyric的自动匹配的逐字歌词相匹配的格式如下
https://zh.wikipedia.org/wiki/LRC%E6%A0%BC%E5%BC%8F
因为 SPL 格式要求歌词行末尾以 “[mm:ss.xx]” 结尾，因此增强型 LRC 在现在 SPL 格式的标准下是无法兼容的。
其实我对于目前 SPL 所支持的歌词略有疑惑，对于增强 LRC 来说，用"[]"来表示歌词行，用"<>"表示行内逐字的时间戳是非常高效且直观的，而且也方便歌词解析软件用正则去掉带"<>"的部分从而显示成正常的逐行歌词。
而用"[]"既作歌词行的开头，又作歌词行内的时间戳标记，在我个人看来有些蛮烦的，至少无法处理一下这种情况： [00:40.79]只[00:41.05]是[00:41.30]一[00:41.56]场[00:43.86]游[00:44.15]戏[00:45.23][00:47.22]按[00:47.61]下[00:48.15]重[00:48.64]启[00:49.70][00:52.38]归[00:52.96]为[00:53.36]沉[00:53.94]寂[00:55.23] 其实作者也看出来了，没有分行，正常分行的情况下是这样的： [00:40.79]只[00:41.05]是[00:41.30]一[00:41.56]场[00:43.86]游[00:44.15]戏[00:45.23] [00:47.22]按[00:47.61]下[00:48.15]重[00:48.64]启[00:49.70] [00:52.38]归[00:52.96]为[00:53.36]沉[00:53.94]寂[00:55.23]
那可能会有反对的意见，说可以依靠连续的两个时间戳来识别，这能体现出增强 LRC 与这种格式的区别了，因为增强 LRC 是支持歌词行内停顿的，例如下文表示：
中间的两个时间戳就代表行内停顿，这个行内停顿还挺长的，持续了1分半。
对了，对于这种 SPL 全用 "[]" 可能带来的潜在问题就是比例问题了，从下图可以看出来，在小的显示框的情况下，无法准确的判断每一个歌词行的开头，这需要软件做出应对，毕竟 SPW 是 PC 端软件了，肯定会有编辑歌词的功能，Salt Player 可能以后也会支持。
不过其实我还是有个问题，难道全用 "[]" 对歌词解析器来说是会更易读吗？据我所知，大规模用这种格式的貌似是网易云音乐。
这儿有几个问题，分别说明/讨论，第一个“因为 SPL 格式要求歌词行末尾以 “[mm:ss.xx]” 结尾，因此增强型 LRC 在现在 SPL **格式的标准下是无法兼容的。”
SPL 会自动添加隐式行结尾，即如
[00:52.38]归<00:52.96>为<00:53.36>沉<00:53.94>寂<00:55.23>
会在解析的时候视为：
[00:52.38]归<00:52.96>为<00:53.36>沉<00:53.94>寂<00:55.23>[00:55.23]
做为一种兼容性，已经过测试
关于“歌词行内停顿”需要进行重新支持，我想这个地方无论使用<>或者[]都是一样的，不会有区别 目前歌词解析器还不支持行内停顿，连续时间戳将只保留最后一个，我想应该在后续版本测试完成后添加
其实我最好奇的还是我最后的这句话， “ 难道全用 "[]" 对歌词解析器来说是会更易读吗？据我所知，大规模用这种格式的貌似是网易云音乐 " 因为我看到大部分支持的卡拉OK的歌曲软件基本上都是将 ”[00:47.22]按[00:47.61]下[00:48.15]重[00:48.64]启[00:49.70]“ 这种格式作为逐字歌词的格式的。