大家好 , 我是LEE. 一名有信仰的果粉Coder.
非常感谢大家利用自己宝贵的时间来阅读我的文章 , 我并非大神 , 只是一枚努力成为大神的猿. 这篇文章主要写一个iOS系统下的音乐播放器 , 我会一步一步的去完成这个播放器的开发 , 并且会分析一些主要的技术点以及注意事项等 . 如果你是一个小白初学者 , 希望你看完后能够对你的提升有所帮助 , 如果你是一个老司机 , 希望可以得到你的指点 , 有任何不妥的地方 欢迎指正 , 我会认真改正 . 那么.. 开车了~
前言
在开发音乐播放器时 , 针对歌词的处理是必不可少的 , 而要想解析歌词得到我们需要的数据 , 首先就要了解歌词数据的构成格式 , 下面为大家简单介绍几种常见的歌词格式.
格式分析
当今互联网上 , 我们常见的歌词格式有 LRC、TRC（天天动听歌词）、KRC（KuGou ResourCe , 酷狗资源文件）和 QRC（QQ音乐歌词) . 下面我为大家分析比较这些歌词格式.
LRC 格式
LRC 歌词格式是世界上最通用的歌词格式 , 没有之一 . 它是最基本的歌词格式 , 几乎没有支持其他歌词格式而不支持这个歌词格式的播放器 . LRC 歌词格式的特性就是——简单.
[ti:青花瓷]
[ar:周杰伦]
[al:我很忙]
[00:00.00]青花瓷 - 周杰伦
[00:20.89]素胚勾勒出青花笔锋浓转淡
[00:25.58]瓶身描绘的牡丹一如你初妆
[00:29.96]冉冉檀香透过窗心事我了然
[00:34.43]宣纸上 走笔至此搁一半
[00:38.99]釉色渲染仕女图韵味被私藏
[00:43.33]而你嫣然的一笑如含苞待放
[00:47.80]你的美一缕飘散
[00:50.27]去到我去不了的地方
[00:56.40]天青色等烟雨 而我在等你
[01:00.43]炊烟袅袅升起 隔江千万里
[01:05.34]在瓶底书汉隶仿前朝的飘逸
[01:09.37]就当我为遇见你伏笔
简单分析一下
首先有一些记录歌曲及歌词信息的东东 , 我们将其称作"ID 标签" (ID Tags) , 它可以包含歌曲名 (ti) , 专集 (al) , 歌手 (ar) , 歌词创建者 (by) , 歌词延迟调整 (offset) 等信息.
下面是主体部分 , LRC 格式为每行歌词指定起始时刻 , 格式为
[分钟:秒.百分秒].
以上说的是简单的 LRC 格式 也是我们最常见的格式 . 事实上 , 还有一些对其进行了扩展和完善 , 比如有一种扩展的简单格式和一种增强格式.
扩展的 LRC 格式在原来的基础上支持 "男女合唱标记" . 语法是: 在歌词正文前添加 "M:" (男) 、"F:" (女) 或 "D:" (合) . 下面就是一个示例 . 但是 , 这种格式并没有被广泛使用.
[00:10.00]使用默认的颜色应该是蓝色
[00:12.35]F: 这行一般显示为红色
[00:15.10]M: 男声开始了
[00:20.05]继续男声
[00:25.45]D: 合唱部分开启,一般为绿色
增强 LRC 格式支持在原格式基础上加入了逐字精准支持 . 通过在每个字 (也可以是词) 外添加额外的时刻标签<分钟:秒.百分秒> . 这种格式的设计者的主页已经挂掉了 , 恕我不能提供更多信息和具体的示例 . 维基百科给的示例如下：
[mm:ss.xx] <mm:ss.xx> 第一行第一个词 <mm:ss.xx> 第一行第二个词 <mm:ss.xx> ... 第一行最后一个词 <mm:ss.xx>
[mm:ss.xx] <mm:ss.xx> 第二行第一个词 <mm:ss.xx> 第二行第二个词 <mm:ss.xx> ... 第二行最后一个词 <mm:ss.xx>...
[mm:ss.xx] <mm:ss.xx> 最后一行第一个词 <mm:ss.xx> 最后一行第二个词 <mm:ss.xx> ... 最后一行最后一个词 <mm:ss.xx>
TRC 格式
TRC 格式是由天天动听制定的一种歌词格式 , 可以看作是对 LRC 格式的扩展-----为什么我这样说呢 ? 请看下面我从一 TRC 文件中从头摘取的文本.
[ar:胡彦斌]
[ti:当你要离开的时候]
[al:]
[total:243000]
[offset:0]
[by:ttpod]
[00:16.54]<250>当<300>你<1852>要<249>离<452>开<201>的<451>时<3801>候
[00:24.32]<200>我<200>们<1201>走<250>过<250>了<251>无<350>数<350>个<600>路<3851>口
因此 , 我们可以下结论 , TRC 格式在 LRC 格式基础上 , 歌词正文中每个字的前面增加了时间标记<毫秒数> , 每个字连续解析 , 支持了逐字精准 . (上文中"字"可理解为词) , 这在遇到英文时尤其有用.
KRC 格式
KRC 是酷狗公司推出的专利歌词格式 , 主要是支持了逐字精准 , 解决了所谓“歌词显示不准确”的问题 . 酷狗在很久之前在用 LRC 歌词做卡拉 OK 效果 , 但由于 LRC 的特性问题 , 在某一行中 , 每个字的持续时间只能是平均分配的 (直到现在，还有不少播放器是这样做的) , 想必是后来实在看不下去了吧 . 这里值得说一点 , 酷狗的歌词是经过加密处理的 , 直接打开会看到全部都是乱码 , 不过这种事还是难不倒万能的天朝攻城狮 , 下面是解密后的歌词片段:
[id:$00000000]
[ar:信乐团]
[ti:北京一夜]
[by:帅比LEE]
[hash:766fe295bf2722a9ede2abdd61d580c1]
[total:278438]
[sign:大家去北京玩一夜吧!!!!]
[53883,3092]<0,632,0>One <632,784,0>Night <1416,372,0>in <1788,548,0>北<2336,755,0>京
[56675,3539]<0,560,0>我<560,416,0>留<976,392,0>下<1368,412,0>许<1780,392,0>多<2172,1366,0>情
[59914,2577]<0,549,0>不<549,276,0>管<825,252,0>你<1077,214,0>爱<1291,182,0>与<1473,212,0>不 <1685,887,0>爱
[62191,3344]<0,560,0>都<560,210,0>是<770,210,0>历<980,204,0>史<1184,202,0>的<1386,564,0>尘<1950,1387,0>埃
通过观察我们可以看出 , KRC 格式记录了歌词的制作者名称、ID、个性签名 , 歌曲的基本信息也有在列 , 还包括歌曲长度和歌曲 hash 值 . 歌曲的 hash 值是实现打开歌词文件就抓取对应歌曲要求的重要信息 . 而在正文中 , 语法为:
[此行开始时刻距0时刻的毫秒数,此行持续的毫秒数]<0,此字持续的毫秒数,0>歌<此字开始的时刻距此行开始时刻的毫秒数,此字持续的毫秒数,0>词<此字开始的时刻距此行开始时刻的毫秒数,此字持续的毫秒数,0>正<此字开始的时刻距此行开始时刻的毫秒数,此字持续的毫秒数,0>文
由此可见 , 酷狗的歌词格式也是支持逐字同步的 , 只不过语法中最后那个 0 我是真不懂啥意思 - - , 可能是延迟偏移毫秒数或者是巴拉巴拉什么的.
QRC 格式
QRC 是QQ音乐推出的专用歌词格式 , 同样支持逐字精准 , 先前 QRC 格式是一种比较友好和开放的格式 , 但是现在.....万恶的加密 , 它现在变成了一种可以说比 KRC 还封闭的格式 . 现在我们既不能查看到其源码 , 也无法制作这种格式的歌词 . 下面是早年间存在于世的 QRC歌词片段:
[1790,2062]那(1790,375)一(2165,309)年 (2474,315)汪(2789,311)苏(3100,314)泷(3414,438)
[5052,3516]作(5052,252)曲(5304,248)：(5552,252)汪(5804,253)苏(6057,247)泷
解析语法为 (方括号内表示一行的 , 小括号表示每个字的) :
[开始时间ms,持续时间ms]歌词 (开始时间ms , 持续时间ms)
感觉和 KRC 很像有木有 ? 现在具体是什么样 只有QQ音乐项目组知道了.
总结
LRC 最简单 , 最广泛 , 但是没有逐字精准 . TRC、KRC、QRC 支持逐字精准 , 但是其中 KRC 和 QRC 格式不开放 . 从这点上看 , TRC 是不错的选择 . 但是 KRC 歌词的资源更多 (应仅次于 LRC 的资源 ) , 既然都已经出现了解析方法 , 利用下应该也是可以的 (但 KRC 格式拥有专利 , 谨慎哟) , LRC 总归来说，是只能满足简单需求的啦 , 如果你只是用于研究写写demo , TRC 和 LRC 就够了.
最后提醒大家一下 , 如果你正在做一个音乐播放器类的APP , 那么你一定要注意解析歌词时的容错处理 , 千万别因为歌词数据有一点小错误而导致你整个APP蹦掉 , 血淋淋的教训.
