关于lrcx歌词格式疑惑 about lyricskit HOT 8 OPEN

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

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

from lyricskit.

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

from lyricskit.

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

from lyricskit.

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

from lyricskit.

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

from lyricskit.

哈哈，其实我是搞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，就会出现字对应不上的问题。
等等，我看怎样加你。

from lyricskit.

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

from lyricskit.

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

from lyricskit.