互联网上，我们常见的歌词格式有 LRC、TRC（天天动听歌词）、KRC（KuGou ResourCe，酷狗资源文件）和 QRC（QQ音乐歌词）；在影视制作中，人们通常会用其他的卡拉 OK 字幕格式，例如 KSC（KBuilder 卡拉 OK 字幕描述脚本文件） 和 KAJ（Sayatoo 项目文件） 格式。在这篇文章中，我将初步分析比较这些歌词格式，大家也可以比较比较。
以下歌词文件示例之版权属原作者所有，歌词之版权在其撰写者或对应版权人/公司；若您感到版权被侵犯，请联系我们修改文章。特此声明。
LRC 格式
LRC 歌词格式是世界上最通用的歌词格式，没有之一。它是最基本的歌词格式，几乎没有支持其他歌词格式而不支持这个歌词格式的播放器。LRC 歌词格式的特性也是——简单。
[ti:最炫民族风]
[ar:凤凰传奇]
[by:百度网友][00:23.25]苍茫的天涯是我的爱
[00:27.16]绵绵的青山脚下花正开
[00:30.88]什么样的节奏是最呀最摇摆
[00:34.64]什么样的歌声才是最开怀
以上是一个示例 LRC 文件的开头部分。
可以看到，首先有一些记录歌曲及歌词信息的东东，我们将其称作“ID 标签”（ID Tags），它可以包含歌曲名（ti）、专集（al）、歌手（ar）、歌词创建者（by）、歌词延迟调整（offset）等信息。
然后让我们来分析歌词的主体部分——其实没什么好分析的，一眼就可看出，LRC 格式为每行歌词指定起始时刻，格式为[分钟:秒.百分秒]。然后？没啦。因为这个原因，所以我们并不好在行与行之间设立间隔，但是我们可以用空行（不写歌词正文，只写时间标签）的形式曲线救国，一般段与段之间确实这样用，但句子之间这样的话就容易在窗口歌词显示中扰乱美感。
以上说的是简单的 LRC 格式，即我们一般所说的 LRC 格式。事实上，还有一些人对其进行了扩展和完善，比如有一种扩展的简单格式和一种增强格式。
扩展的简单 LRC 格式在原来的基础上支持“男女合唱标记”。语法是，在歌词正文前添加“M: ”（男）、“F: ”（女）或“D: ”（合）。下面就是一个示例。但是，这种格式并没有被广泛使用，据说仅在 Walasoft 的 Walaoke 上可用。
[00:10.00]使用默认的颜色应该是蓝色
[00:12.35]F: 这行一般显示为红色
[00:15.10]M: 男声开始了
[00:20.05]继续男声
[00:25.45]D: 合唱部分就是我开启
[00:30.75]啊哈哈大合唱
增强 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 格式基础上，歌词正文中每个字的前面增加了时间标记<毫秒数>，每字连续解析，支持了逐字精准。或者，上文中“字”可理解为词，组合在一起当作一个“字”（以下称作“词看作字”），这在遇到英文时尤其有用。
但其实，天天动听论坛还发布了 TRC 歌词的制作规范《TRC制作注意事项说明》，强制了一些 ID 标签的存在，说明了服务器歌词匹配规则，规定了歌手命名规范。在另一帖子中，还强调了个人信息（如歌词制作者 QQ）要写道歌词的末尾。这一点若成强制规定，那真真是极好的。
目前这种格式的歌词无法在电脑上直接制作，只能通过手机端的“天天K歌”应用制作，或由其他格式转换而来。
KRC 格式
KRC 是酷狗公司推出的专利歌词格式，主要是支持了逐字精准，解决了所谓“歌词显示不准确”的问题。酷狗在很久之前在用 LRC 歌词做卡拉 OK 效果，但由于 LRC 的特性问题，在某一行中，每个字的持续时间只能是平均分配的（直到现在，还有不少播放器是这样做的），想必是后来实在看不下去了吧。让我们先浏览一下一个 .KRC 文件用记事本打开的前面一部分——
krc18F4飼\!怢鹬???H椡盻Y継?螂MKB山? 鱵z
7"_q鍽? 舝?煴渡貛韮枔to?龅?ㄩ乃8圛邬GG睙?垽eZ鸄1,倢诞?? -4孧Jx)?'*画姯汓袗塧9部潧恾蠒翰)彃湢炰X睱比柡犌栅],朢g |?塜蚳 衖〇猤潚壚鲨蔒?Q}害牨軖K悪w徊 w>7? 藲?媺?攢A瓾湟泀闆坊囝"Io?€=?畨枞 6乺滼脥％踯每宪 ?T憐 柩鳴-狞?x0O%€摨掋R?2胣＠?楸斕茺?7榥黖 v洰窩?爻顄腛u陭'樺?_迿昔幾6櫹w搷$幑^n@纄? 啅鸪 嶬?涣 樋话怾 ?l!?a秎婓sD?虥??澶?貮怿涧Jc? 鹣,贘F埡KQA雕淌邼魹?~k?娕芅T?︰ 闂眂匁1?擒{x駩癵{A莍燧
呃，等等。不是你电脑的问题——上面确实是一堆乱码！唉，酷狗歌词真不开放。除了在前面有“krc”供识别格式外，别的东西我们根本看不懂好吧！还好，根据《将酷狗krc歌词解析并转换为lrc歌词php源码》这篇高人写的文章，我们可以将后面的乱码解密解压后，得到正常的文本（仅提供前面一部分的浏览）——
[id:$00000000]
[ar:信乐团]
[ti:北京一夜]
[by:韩佯Τé]
[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>文可见，KRC 歌词对“词看作字”的支持也很好。行与行之间也能很好地设置时间间隔了呢。
KRC 文件可以在酷狗音乐上制作。
啊？你问我“,0>”的事？好吧，其实我也弄不明白。
QRC 格式
先前 QRC 格式是一种比较友好和开放的格式，但是现在……请看——
[offset:0]捬-偔!跖?J脚?唊?輣.3蟐陕:v黣?nRvX+霟>?O??冰垙1U筘摉F屘?y芊凋FU蠱k?诘鄑?賓{麵J搈rZ滿?s抆M?Z讼烚?鋷粒Q@?e艩(?k硟廪Je撤?徇 V=D葘"?嬝S?稌oX?潥YpA翯?舼tfy?v黝?d.?叶滹な&`??蜫籛^媣(躯闟愌?_?鵼;W[.癔锝眦6栭獔??瑆Sip+_wz€寕椨?騝痢碉鋭~?(蟒K????
嗯，它现在变成了一种，可以说比 KRC 还封闭的格式。现在我们既不能查看到其源码，也无法制作这种格式的歌词。腾讯客服网页火上浇油道，下载到的“QRC 类型”“不支持转换成 LRC 等其他类型”。我们现在只能粗略观察到 QRC 格式的一些特点，如支持逐字精准。
等待高手出现。
KSC 格式
据我所知，KSC 格式是由俗称“小灰熊字幕制作软件”的 KBuilder Tools 制作的，这款软件的作者是国人，出现的时间比 KRC 早多啦。软件一般自带英文、繁体中文和简体中文，是需要付费注册的。“小灰熊”主要用于专业视频制作领域的卡拉 OK 字幕制作与显示，与 Premiere 软件是好搭档，不过其格式也可视作是稍特殊的歌词格式。
一个 .KSC 文件的前面一部分如下所示：
karaoke := CreateKaraokeObject;
karaoke.rows := 2;
karaoke.clear;karaoke.songname := '新郎新娘';
karaoke.singer := '张启靓';karaoke.add('00:20.910', '00:26.758', '喜气洋洋歌声在飞扬' ,'294,3130,216,263,225,215,233,192,1080');
karaoke.add('00:27.844', '00:31.261', '花团锦簇鞭炮声声响', '321,280,272,313,272,288,303,288,1080');
karaoke.add('00:29.510', '00:36.062', '迎亲的队伍像游龙在飘荡', '263,305,271,254,201,241,200,256,288,193,1080');
karaoke.add('00:37.068', '00:40.613', '那是要迎娶美丽的新娘', '337,249,207,336,265,271,281,271,248,1080');
有时候也带上如下所示的更多有关歌词样式的代码：
karaoke.AnimateBorderColor := RGB(255, 255, 255);
karaoke.AnimateColor := RGB(0, 0, 255);
karaoke.NormalBorderColor := RGB(0, 0, 0);
karaoke.NormalColor := RGB(255, 255, 255);
karaoke.TransparentColor := RGB(0, 128, 0);
karaoke.AnimateBorderThickness := 1;
karaoke.NormalBorderThickness := 1;
karaoke.Font('黑体', 19, false);
karaoke.Charset := 1;
karaoke.Width := 353;
karaoke.Height := 94;
karaoke.AutoSize := true;
karaoke.linespace := 4;
karaoke.Rows := 2;
karaoke.FirstAlignment := 0;
karaoke.FirstIndent := 30;
karaoke.NextAlignment := 1;
karaoke.NextIndent := 30;
karaoke.TimeOffset := 0;
有点像编程代码吧，哈哈。其实 KSC 歌词制作起来是比较简单容易的，改代码的话也有语法检查帮助你。
自然，作为一种比较专业的格式，KSC 支持逐字精准、“词看作字”（使用英文方括号括起来）、男女合唱提示字、行与行间设置时间间隔，但不支持字与字之间设置间隔。有趣的是，你可以把行间的间隔设为负，就是说，会显示成一句还没结束，下一句就开始了。当然，因为解释器遵守的规范是怎样的，我们暂无从得知，所以还是玩玩就好。
对了，非编领域外，部分K歌软件也可能用得到 KSC 格式的歌词。
可以利用“小灰熊”软件将 KSC 导出为低级的 TXT 文本文档、SSA 或 SRT 字幕文件。
KAJ 格式
KAJ 格式其实是俗称“傻丫头”的 Sayatoo 的国外付费软件的项目文件，其制作和修改的过程均很方便。
KAJ 格式的文件用记事本打开也是乱码，像这样：
KARA 0 F ?稁8 朁嫗&5?G懔缂歌~玆諅X遯愅F?Y?B??蕴埾/?餌|?耍?}? ? ? ? x渃@餃A$#旝?量→I鸲i T亷??@l╔s ?@ ? ? O/TU 沟u曃d衟b`8?3??HM
X%2,@? 餫B鎯探v?0d╜@?蘥╮乣1p<18雀 &
蒪&駷t篑MⅤ?义V? 9 x渃€?N@? IJ? ? a x渃`?*捗澦濍擙!B#寽$?N4鷑$?&?'?0l囀1,?(?!| 攱g`囼Y佇4亖A蔳吕D9(?髞€?€p}2 +M?
F??@y ? ?K0@?FP辝`H?b身偸1A鍢仈赖7?€鬡 ?@ ?e鍎?v\r@汞@zs??;恾 ??膴@虄d?芯揁z1K馩?悰$W1 襍乆?A錊?€閸@,俤 H? (G搥 寕Q0d 左II # x淯冶/DA饙(T
?$岯?. A聨C(甡剤D蛮揌P(e譽襖?璣咛~嶁?哽{髒骬?劧刾 UO?<rC豨迺?o#_翓杉N沶N"獥葢s枒蟩??潷u>_?甹圌N?搠堸3皨軃萧
但是我们不必理解里面的含义了。我们需要知道的是，KAJ 格式也支持逐字精准、男女合唱提示字（前缀标识）、行与行间设置时间间隔，甚至字与字之间设置时间间隔；但不允许由于时间线的限制，并不能让行间时间间隔为负；制作的时候，默认会把英文单词合起来。有指示灯设置。除了基本的字体设置外，Sayatoo 软件还带有一些特效，此处不再讨论。
小结
LRC 最简单，没有逐字精准，TRC、KRC、QRC、KSC、KAJ 有，但是其中 KRC 和 QRC 格式不开放，而 KSC、KAJ 多用于专业领域。从这点上说，开发者如果要找一款特性适中的歌词格式，TRC 是不错的，KSC 也行。但是 KRC 歌词的资源更多（应仅次于 LRC 的资源），既然都已经出现了解析方法，利用下应该也是可以的（但好像 KRC 格式拥有专利）。LRC 总归来说，是只能满足简单需求的啦。
很久以前是 LRC 一统天下的世界，现在再也不是了，现在在“歌词格式界”没有真正的霸主。唔，不统一有时候会带来很多麻烦的说。
或者，不妨试着自己构想一种新的格式？哎呀，看起来会更加不统一的。
够详细呀~当年我还做过歌词呢，不过是最简单的LRC
想当年我也做过 - -
又没其他格式的呢。
你研究的越来越广泛了啊~
本来就有研究的呢，只是现在自觉地加以系统化了而已。
研究的透彻！
听说有最炫民族风我就来看了xdd
我之前分析过，不过分析的比较简单。QRC的话，估计还是只是把XML文档加密了一下，就算找到解密方法也无非就是还原回来罢了。
https://tffans.cn/post/909.html
不管是不是 XML，反正就是记录那么几个歌词的要素。
哈哈，还有人研究这个，trc格式制定者、开发者路过。。。
哇，欢迎欢迎。才不会告诉你当初写这篇文章是为了引出我自己的一个设计呢！
【Aegisub脚本】KRC/TRC等精准歌词格式转ASS卡拉OK
http://www.tcax.org/forum.php?mod=viewthread&tid=1239
这个超级赞！酷狗的krc歌词可以直接用来做卡拉OK
KRC QRC KSC 这3中格式
通过傻丫头卡拉OK扩展插件
已经能够直接导入傻丫头软件里面
大家自行测试吧~！
插件地址：
http://www.dvedit.cn/thread-202069-1-1.html
现在虾米歌词都是TRC了，不过github上连个解析器也没找到 - =
咦，那有可能是阿里巴巴作中作梗。: D
如果还是文章上说的 TRC，自己写解析器也不是很难吧。
请问LRCX格式如何解尖括号里的数字
[00:23.75]塞纳河畔 左岸的咖啡
[00:26.47]我手一杯 品尝你的美
[00:29.48]留下唇印的嘴
[00:34.40]花店玫瑰 名字写错谁
[00:36.87]告白气球 风吹到对街
[00:40.01]微笑在天上飞
尖括号被吃了 …… < 2821 , -2821 >
抱歉，上次有人给我看过 LRCX，不清楚那些数是代表的什么。
大佬。根据高人的文章写了个通过歌曲名搜索krc的api,我在想怎么把解析出来的krc转成ksc ，用php来实现。
http://50123.xyz/music/krc.php?keyword=讲真的
看起来应该是能做到的。比如可以把 KRC 相应歌词和时间标记读出来，再拼凑出 KSC。
晚上看了一下，太笨没有找到可以利用的规律，正则不知道怎么写
我不太清楚优化的字符串匹配怎么写，不过我稍微看了一下。KRC 歌词主体部分首先是一行一行的，于是可以把它们按每行拆开来，不过保留行尾的换行符供下一步使用。接着读行首的方括号信息，再用
<\d+,\d+,\d+>.*?(?=<|\n)之类的表达式就可以读到每个词的信息。解决了。实现了krc转ksc。代码冗余得自己都看不下去了。
测试地址
http://50123.xyz/music/krc.php?keyword=讲真的
解决就好
可以分享下嘛
上文对trc歌词的分析不完全正确。1trc歌词是在lrc歌词中需要以字同步行中详细在每个字前添（x∈正整数集，代表这个字的显示持续时间、单位：毫秒）、在需要停顿的字后详细添加（x∈正整数集，代表此个字的停顿时间、单位：毫秒），特别的：当需要停顿的字在最后一个字则不需要添加这个字的停顿时间，用行时间大于所有字的时间总和作停顿；trc歌词中不需要以同步行可以照搬lrc歌词格式，lrc歌词标签标栏中增加total（代表匹配歌词长，单位：毫秒）。如果在trc歌词中需要翻译行后面再增加[x-trans]……（……代表翻译内容）、不需要翻译行可以直接照搬lrc/trc歌词就是具有双行歌词显示的trc歌词——xtrc歌词。2qrc歌词还分为手机版和电脑版（16.5及以上版本起用新的加密方式）。3还有咪咕音乐mrc歌词没有提到。
感谢批评指正。
本文发表时间久远，可能已经过时。
请教一下，咪咕的mrc歌词怎么解码呢？
QRC格式的转换已经有人写出，代码地址https://gitee.com/ying32/MakeLyric#https://gitee.com/ying32/MakeLyric/releases
Is synchronous lyrics popular in China to the extent that formats are flooded?
In general, this is true. Music software is popular in China, and almost every software supports synchronous lyrics. However, because LRC is considered too basic, many Chinese apps have created their own format. Furthermore, some apps encrypt their format to not only improve user experience but also retain users by locking them into the app.
Thank you for your reply.
As a hobby, I make synchronized lyrics display software.
Information on China rarely hits in searches, and I don't actively search for information on China, so this page that happened to be linked was quite interesting. (Thanks to the automatic translation of the browser)
大佬很厉害！刚把我的软件做成支持网易云音乐的逐字歌词格式后就看见了这篇远古文章！直到现在还是很具有参考意义。
这里解释一下网易云音乐的
注：不是打开的本地文件，以下内容从github上的网易云音乐api中获取
{"t":-1000,"c":[{"tx":"作词: "},{"tx":"Nekock·LK","li":"http://p1.music.126.net/C2je7GOQiucGIXr9dq-FGw==/109951163054850367.jpg","or":"orpheus://nm/artist/home?id=12116049&type=artist"}]}
{"t":-500,"c":[{"tx":"作曲: "},{"tx":"Nekock·LK","li":"http://p1.music.126.net/C2je7GOQiucGIXr9dq-FGw==/109951163054850367.jpg","or":"orpheus://nm/artist/home?id=12116049&type=artist"}]}
0,3420编(570,570,0)曲 (1140,570,0): (1710,570,0)Nekock(2280,570,0)·(2850,570,0)LK
3420,3420调(3990,570,0)教 (4560,570,0): (5130,570,0)雪(5700,570,0)業(6270,570,0)業
6840,2850立(7410,570,0)绘 (7980,570,0): (8550,570,0)怜(9120,570,0)优
9690,3420视(10260,570,0)频 (10830,570,0): (11400,570,0)Nekock(11970,570,0)·(12540,570,0)LK
13110,4270我(13350,500,0)本(13850,260,0)计(14110,350,0)划(14460,600,0)在(15060,390,0)冬(15450,360,0)天(15810,400,0)死(16210,330,0)去(16540,840,0)的
......
前两行为json格式，包含了创作者的名称和链接
后面每行格式相同
本行开始时间,本行持续时间第一个字(本字开始时间,本字持续时间,0)第二个字......
单位为毫秒
看来时隔这么久，网易最近新出的逐字歌词格式也是大同小异（只是把相对时间换成了绝对时间）
博主感兴趣的话，可以看看我的软件吗？
由易语言编写，exui++作为界面支持库，bass进行音频解码
music.xwzkj.top