星期四左眼跳
之前写了几篇关于动感歌词的简单介绍，相信大家还有印象，这里就不多说了，这篇要说的是，关于翻译歌词和音译歌词，以及我在解析和显示这两种歌词的时候，遇到的一些难题、技术和。前面几篇可以点击文末左下角“
下面我简单说一下，关于翻译歌词和音译歌词保存在哪里的问题。因为我主要研究的是krc歌词，所以这里我会以krc解析为主。当然，我也根据自己的实际需求，自定义了一种歌词格式，方便自己使用，这里也会简单说一下，为了区分音译和翻译歌词，我把原来的歌词，称为：【原始歌词】，音译和翻译歌词统称【额外歌词】。
krc歌词，分析篇也说了，虽然是加密了，但是也难不到万能的网友。以下是根据网上提示的算法，得到解密后的歌词内容：
对的，你看到的不是乱码，这是我为了找到有翻译和音译的krc歌词，而找的一份歌词（茶太 - 志在千里~恋姫喚作百花王~.krc），里面的乱码其实是日语来的，好了废话不多说，其实我们只要细心看便会看到歌词里，有一行：
是的，就是这一行，krc歌词里面的翻译歌词和音译歌词，都在这一行里面，看到这些abcd是不是好眼熟？对的，这些字符串，就是base64加密后的字符串。我们解密来看看，是什么东东，解密内容如下：
从解密后的内容可以看到，type=0是音译歌词，type=1是翻译歌词，其中歌词中看不到与时间相关的标签，这是因为【原始歌词】中已经含有了时间的标签和精准到【字】的时间标签。翻译歌词相对简单，只需要与原始歌词的【行】对应即可。音译歌词，除了与原始歌词的【行】对应外，还与【行】歌词里的每个【字】相对应。
从歌词格式内容，我们可以看到，在解析歌词的时候，我们还要费时去解析歌词行的每个【字】（最可怜的还是要判断该【字】是中文、英文、韩文还是日文，最的还是泰文），然后对歌词进行分割，得到【字】然后，最后解析后面的时间标签再得到【字】对应的时间。是的，解析歌词行的每个【字】，这是在制作歌词的时候，才需要去做的事情啊，所以这里也是需要优化的地方，加上各种歌词间相互转换时，该格式存在出错的概率比较多，往往会因为得到的【字】个数与后面的【字】时间个数不对应，而报错。所以基于以上的种种原因，我重新改良了该歌词的格式：
从的内容可以看出，该歌词格式也是支持音译歌词和翻译歌词的（参考krc原理）。主要优化在歌词行：
在这里，我将每个【字】用来包住，这样子在解析时，除了简单，相对准确性会比较高。
在的歌词实体，新添加分割后的歌词行集合。当歌词内容过长，超出了显示的view时，歌词超出的部分会换行显示。在这里，我不是在显示的时候，才对歌词进行换行处理的，我的思如下：
关于多行歌词的显示方式，我在显示篇的时候，已经过，原理也是差不多的。这里以android为例子，在文章最后我会贴上我的源码，之前关于view的平滑移动是使用ValueAnimator的动画来实现的，我发觉它在实现fling的效果时，并不是好理想。所以我就转用了scroller来实现view的平滑移动，这里需要注意的是，scroller只做动画，不要使用它来移动view。我实现的思如下：
动感歌词行居中显示，公式：（view的中间值+（歌词高度 + 空行高度））*0.5 + 移动到当前行号所需的Y值- offsetY
offsetY是从当前歌词行切换到下一行时，需要的偏移值，公式：offsetY= 移动到【新】行号所需的Y值 - 移动到当前行号所需的Y值
歌词滑动快进时，在计算滑动所在的行号（需要注意行的高度），可通过offsetY值和每行歌词与view所绑定的关系，来计算当前对应的是第几行歌词。
在绘画歌词的过程中，顺序需要变一下，存在歌词过长换行的情况，所以每行歌词的Y值会有变化。先绘画当前歌词行，计算绘画分割后的当前行所需的Y值后，再使用该Y值来绘画当前歌词行下面的歌词。
翻译歌词：如果需要像音译歌词那样显示动感效果，则需要获取歌词的持续时间，计算每个【字】的平均时间，所以也是需要在原始歌词的基础上获取开始时间和结束时间，计算每个【字】的平均时间。
绘画歌词时，画完当前行分割的歌词后，需要向下画行对应的分割额外歌词。最后再向下画下一行歌词。在画当前行歌词的歌词时，先画额外歌词。
希望动感歌词的分析篇、生成篇、解析篇、显示篇和补充篇对一些想了解或者想实现动感歌词的读者有帮助。如有侵权，麻烦告知。阅读原文”查看。
本文由来源于325棋牌 325游戏中心唯一官方网站
网友评论 ()条 查看