SPL 格式（Salt Player Lyrics）语法标准
标准版本：2026-11-02 版（日期标识）
制定时间：2024 年 12 月 16 日
修订时间：2026 年 11 月 2 日
制定作者：不要糖醋放椒盐
前言
Salt Player 歌词格式（简称“SPL”），基于且兼容（增强型）LRC，一种阅读友好的歌词格式。
为什么选择 SPL？
- LRC 格式拥有极多的使用用户，SPL 兼容 LRC，并在此基础上对多年来遇到的多种兼容性问题进行了适配，拥有优秀的兼容性。
- LRC/SPL 非常简单，对人类阅读友好，时间戳为分、秒、毫秒格式，加上歌词文本，没有过多标记字符，使得在极简文本编辑器/编辑框中也可以非常方便地编辑。
- LRC/SPL 极简的标记格式拥有强大的表现力，占用的字符空间也更少。
- SPL 在对适配各种兼容性问题的解决方案上将它们视为一种“语法糖”，并进行标准化，对编辑更加友好方便，同时也是本标准的意义。
修订记录
自 2026 年 11 月 2 日起，本标准以修订日期作为版本标识。此前的文本未标注版本编号，以下日期和内容依据已留存的文档及版本历史记录。
- 2024 年 12 月 16 日：制定本标准。
- 2024 年 12 月 26 日：版本库中最早留存的标准文本标注的修订日期；该次修订的具体内容未见于版本库。
- 2025 年 11 月 14 日：调整延迟逐字标记的说明，补充软件支持信息，见兼容性与延迟逐字标记。
- 2026 年 9 月 19 日：明确不带文本的时间戳行作为结束标记的处理方式，并补充示例，见显式行结尾。
- 2026 年 11 月 2 日：新增兼容性字段及
awlrc字段的忽略规则，明确忽略字段后的翻译相邻关系，并补充修订记录。
时间戳
时间戳名词在互联网不同的使用场景有多种解释。在本文中，时间戳代表记录时间的文本标记，由分、秒和毫秒组成，并使用 [ 和 ] 符号包裹，格式示例：
[05:20.22]你好椒盐音乐其中 [05:20.22] 便是一个时间戳，表示 5 分 20 秒 220 毫秒，分和秒之间由 :（半角冒号）分隔，秒和毫秒间由 .（半角句号）分隔，这和日常书写习惯一致。
分、秒和毫秒的数字规范
换算：1 分等于 60 秒，1 秒等于 1000 毫秒。
分限制 1 至 3 位数字，如 1、02、103 都是支持的写法。
秒限制 1 至 2 位数字，如 1、02、13 都是支持的写法。
毫秒限制 1 至 6 位数字，如 1、02、130、450000 都是支持的写法。不足 3 位的写法将视为在后位省略了 0，如 1 将视为 100、02 将视为 020，分别对应 100 毫秒和 20 毫秒，而非 1 毫秒和 2 毫秒。
综合示例，正确写法（// 后是注释）：
[103:3.405] // 表示 103 分 3 秒 405 毫秒
[3:12.5] // 表示 3 分 12 秒 500 毫秒错误写法：
(103:3.405) // 错误的时间戳包裹符号 `(`、`)`
[3:102.5] // 秒部分超出限制位数歌词行
一句歌词由时间戳和时间戳后接文本组成，如：
[05:20.22]你好椒盐音乐表示这是一句从 5 分 20 秒 220 毫秒开始的歌词，歌词内容是 你好椒盐音乐。
显式行结尾
在一句的歌词最后添加时间戳将视为歌词的结尾时间，如：
[05:20.22]你好椒盐音乐[05:21.22]表示此句歌词从 5 分 20 秒 220 毫秒开始到 5 分 21 秒 220 毫秒结束，共持续 1 秒。
也可换行标记，如：
[05:20.22]你好椒盐音乐
[05:21.22]和上一种写法一样，注意第二行时间戳后不接任何文本内容。
时间戳后不接任何文本内容的行是纯粹的结束标记：它不会产生一句新歌词，也不参与翻译识别，即无论它与哪句歌词时间戳相同，都不会被视为主歌词或翻译文本。
实际歌曲文件中，结束标记行常与下一句歌词使用相同的时间戳，如：
[05:20.22]你好椒盐音乐
[05:21.22]
[05:21.22]天天开心其中第二行 [05:21.22] 空行表示 你好椒盐音乐 在 5 分 21 秒 220 毫秒结束，与 天天开心 从 5 分 21 秒 220 毫秒开始并不冲突。
隐式行结尾
如果未在歌词行后标记歌词结束时间，这句歌词将一直持续直到下一句歌词开始，如：
[05:20.22]你好椒盐音乐
[05:22.22]天天开心第一句歌词将视为 5 分 20 秒 220 毫秒开始到 5 分 22 秒 220 毫秒结束，结束时间为下一行的开始时间。
重复行
如果一句歌词重复在歌曲中出现，可以使用多时间戳的方式简写，如：
[05:20.22]你好椒盐音乐
[05:30.22]你好椒盐音乐可简写为：
[05:20.22][05:30.22]你好椒盐音乐歌词翻译
翻译识别
翻译依靠同时间戳识别，在前的一句为主歌词文本，后的一句为翻译歌词文本，如：
[05:20.22]你好椒盐音乐
[05:20.22]Hello Salt Player其中 Hello Salt Player 是 你好椒盐音乐 的翻译文本，两句可以不紧挨着，但须保证翻译歌词在主歌词之后。
在 SPL 中也可省略翻译文本时间戳，如：
[05:20.22]你好椒盐音乐
Hello Salt Player但 Hello Salt Player 必须紧挨着主歌词句子；判断是否紧挨时，应先忽略兼容性字段。若：
[05:20.22]你好椒盐音乐
[05:21.22]不要糖醋放椒盐
Hello Salt PlayerHello Salt Player 将被视为 [05:21.22]不要糖醋放椒盐 的翻译文本。
多行翻译
SPL 标准支持多行翻译：
[05:20.22]你好椒盐音乐
Hello Salt Player
こんにちは Salt Player逐字歌词
逐字歌词是可以针对一行歌词内的文本进行更精确的时间控制，不局限于对每个字符都精确控制，也可以是词组或者其他一部分，如：
[05:20.22]你好椒盐音乐歌词中如果 你好 两个字持续 3 秒而 椒盐音乐 四个字持续 1 秒，这时候行歌词并不能精确的表现，便需要一种方法指定行内的更精确的时间标记。
逐字标记时间戳
逐字歌词和行歌词的时间戳逻辑差别不大，如上方提到的需求可以写成：
[05:20.22]你好[05:23.22]椒盐音乐[05:24.22][05:20.22] 到 [05:23.22] 的间隔为 3 秒，[05:23.22] 到 [05:24.22] 的间隔为 1 秒。
其中 [05:20.22] 依旧是行开始时间戳同时也是开始逐字标记时间戳，因为它位于句首，而 [05:23.22] 是中间的一个逐字标记时间戳，用以分隔 你好 和 椒盐音乐，最后的 [05:24.22] 是行结束时间戳同时也是结束逐字标记时间戳。
逐字标记时间戳需要递增，如果出现时间戳不在行开始时间和结束时间间或者小于之前的时间戳，那么此逐字标记时间戳会被忽略。
局限性
[05:20.22][05:30.22]你好[05:23.22]椒盐音乐[05:24.22]将被视为：
[05:20.22]你好[05:23.22]椒盐音乐[05:24.22]
[05:30.22]你好[05:23.22]椒盐音乐[05:24.22]其中第一行正常而第二行逐字标记时间戳存在顺序错误而被忽略，所以在使用逐字标记建议不使用重复行特性。
兼容性与延迟逐字标记
非开始逐字标记和结束逐字标记时间戳可以使用 < 和 > 符号包裹，如：
[05:20.22]你好[05:23.22]椒盐音乐[05:24.22]可写成：
[05:20.22]你好<05:23.22>椒盐音乐[05:24.22]这带来一种特性，可以实现歌词行到达而首字未开始，如：
[05:20.22]<05:21.22>你好<05:23.22>椒盐音乐[05:24.22]信息
歌词行到达而首字未开始特性将在 SPW 1.8 和 Salt Player 11.0.0 中得到支持
表示这句歌词从 5 分 20 秒 220 毫秒开始，但是到 5 分 21 秒 220 毫秒才到 你好 这部分，可以在 Salt Player 中实现歌词跳转到当前行但未真正开始播放的特性。
兼容性字段
SPL 的设计特点之一是歌词和时间标记可以直接阅读、编辑，用户使用普通文本编辑器即可修改歌词。因此，播放器应以用户能够直接编辑的歌词文本为显示依据，使修改后的内容能够反映在显示中。部分软件将另一份歌词或时间信息编码保存在字段中，这些数据不会随可见歌词的修改自动更新。为了避免播放器显示旧内容而使用户困惑，SPL 忽略本标准明确列出的兼容性字段。
即使尝试将字段中的逐字时间匹配到可见歌词，当用户修改文字、调整时间、拆合歌词行，或歌曲中存在重复歌词时，自动匹配也可能出错，导致逐字高亮错位。因此，SPL 以可见歌词为准，使编辑与显示的关系保持明确。
SPL 不将所有 [名称:内容] 形式的文本都视为兼容性字段。忽略仅发生在解析和显示过程中，不会删除或改写原始歌词文本或文件。
本章首次增订：2026 年 11 月 2 日（2026-11-02 版）。
忽略 awlrc 字段
LX Music（洛雪音乐）可能在歌词中写入 [awlrc:…] 字段，用于保存经过 Base64 编码的普通歌词、逐字歌词、翻译歌词或罗马音歌词。这些数据可能与文件中直接可见的歌词重复。
例如，用户将可见的 LRC 歌词 [00:12.00]Hello 改为 [00:12.00]Hi 时，awlrc 中编码的歌词仍可能是 Hello。如果播放器优先解析并显示 awlrc 中的歌词，用户修改后看到的仍是 Hello，容易误以为修改没有生效。由于字段内容经过编码，用户也难以直接发现并同步修改其中的旧数据。
因此，SPL 选择忽略 awlrc，而不是使用其中的歌词或时间信息：用户编辑可见歌词后，显示依据仍然是编辑后的歌词，保持 SPL 直接阅读和编辑的特点。
SPL 解析时应忽略能够识别为 LX Music awlrc 容器的独立行，不将它作为主歌词或翻译，也不使用其中的数据替代可见歌词或提供逐字时间。无时间戳的纯文本歌词展示也应忽略该字段。
这一选择的代价是：如果逐字时间、翻译或罗马音只保存在 awlrc 字段中，这些信息不会用于显示；如果主歌词也只保存在该字段中，则不会显示歌词。需要逐字效果时，可以将逐字时间写入可见歌词，使用本标准的逐字歌词格式。
识别规则如下：
- 字段必须单独占一行，行首和行尾允许空白字符；完整字段以
[awlrc:开始，以]结束。 - 字段内部由逗号分隔的
名称:值子字段组成，至少包含一个lrc、awlrc、tlrc或rlrc子字段，也允许包含其他名称的子字段。外层字段名和子字段名不区分大小写。 - 每个子字段的值为非空的 Base64 形式文本，使用英文字母、数字、
+、/，末尾可带一个或两个=填充。识别时允许省略填充，只检查字符形式，不校验编码能否解码，也不解析歌词内容。
例如：
[05:20.22]你好椒盐音乐
[awlrc:lrc:SGVsbG8=,awlrc:V29ybGQ=]
Hello Salt Player其中 awlrc 行被忽略，Hello Salt Player 仍被视为上一句的翻译。判断省略时间戳的翻译是否紧挨主歌词时，以忽略兼容性字段后的歌词行为准。
不满足上述识别规则的文本按原有歌词规则处理。例如，带时间戳的 [05:20.22][awlrc:lrc:SGVsbG8=] 是歌词行，不属于需要忽略的独立字段。