关于lrcx歌词格式疑惑

[zhangliangming]

[00:00.599]銀の龍の背に乗って - 中島みゆき
[00:00.599][tt]<0,0><200,1><349,2><500,3><650,4><849,5><999,6><1150,7><1299,8><1449,10><1599,12><1799,13><1999,14><2150,15><2300,16><2600,17>
[00:00.599][fu]<ぎん,0,1><りゅう,2,3><せ,4,5><の,6,7><なかじま,12,14>
[00:00.599][tr:zh-Hans]乘在银龙的背上 - 中岛美雪

[tt]<时间,字索引>这里的“字索引”是不是没什么用？只需要把每个字对应的时间列出来就可以了，解析时只要保证歌词字数和字时间标签数相等就好了。

[ddddxxx]

只是中文的话这样做没有问题，每个词都是单个字符。但是其它语言就要考虑分词了，否则一句英文就有几十上百条时间。

而且这是一个通用可扩展的格式，目的是为了把任意信息附加到歌词的某个位置或者某个范围。例如日文注音

[zhangliangming]

Let it go 对于其他语言，应该是解析的时候，判断字符是英文、日语、数字、韩语等等，像英文【Let】应该是当一个字来看。所以制作歌词和解析歌词按照同一套逻辑来设计，应该没问题。不过，lrcx和酷狗的krc歌词相互转换的话，lrcx歌词转酷狗krc歌词应该没问题，但是酷狗krc歌词转lrcx歌词，会有存在问题。

[ddddxxx]

这样的话歌词文件就依赖特定的分词算法，要能处理好各种边角问题太麻烦了，而且出了问题也不能改（文件已经写进用户磁盘里了）。至于酷狗的krc，目前的算法似乎没有太大问题。你有问题的例子吗？

[ddddxxx]

如果你想要解析 lrcx 的话，请注意这里的字索引是 unicode extended grapheme cluster 的索引，而非 unicode scala，utf code point 或者 code unit。我在解析其它歌词文件的时候发现过 unicode 处理方面的 bug。

[ddddxxx]

@zhangliangming 我看到你设计的 hrc 了，很想和你交流设计方面的细节。可以加我 Telegram 详细聊一下吗 https://t.me/ddddxxxx

[zhangliangming]

哈哈，其实我是搞java的。大家探讨一下。 [1679,1550]<0,399,0>作<399,200,0>词<599,250,0>：<849,301,0>李<1150,400,0>健 如上图，krc歌词文件，已经做好了分词的功能。你叫我找，我一下子也找不到对应的文件。其实对krc来说，它是可以实现 [1679,1550]<0,1550],0>作词：李健 这种歌词更多的是用手机来制作的。这种歌词在转lrcx，就会出现字对应不上的问题。 等等，我看怎样加你。

[ddddxxx]

嗯，我觉得这两种方案本质上是等价的。如果把标签信息插在文本里，就不用包含额外的位置信息了。我当初考虑到可读性，把标签单独拿出来了，所以需要附上位置信息。

[zhangliangming]

Telegram，我这边好像访问不了。你看看有没有微信或者QQ？我把我的联系方式发你邮件，你看看能不能收到。