对网易云音乐将云盘上传/本地播放的音乐关联匹配到曲库相应条目行为的观察

作者:一年又一年 分类: 技术 发布于:2019-3-10 20:07 ė220次浏览 61条评论
从他处下载的歌曲A,上传云盘后,匹配成曲库中对应的歌曲A条目。

将歌曲A中间几秒静音,上传云盘后,依旧能匹配成歌曲A。
查看曲库的歌曲A条目,出现云盘标记,播放听到的是做过静音处理的版本。

歌曲A,meta 信息全部被故意修改成歌曲C的,但是依旧能匹配成歌曲A,但仍可确定匹配受到了 meta 的影响,测试中发现带有错误 meta 的歌曲A的日文版,被匹配成歌曲A的英文版拉取了歌词。(错误的 meta 是英文的,但并不是歌曲A英文版的 meta)

首先播放歌曲A,匹配到了歌词。之后将歌曲A文件换成与歌曲A完全不同的歌曲B,保持路径相同文件名相同。再次播放,呈现的依旧是上次匹配到的歌曲A的歌词。

首次频谱分析拉到结果后会将匹配结果按文件路径缓存。重启可使缓存失效,重新进行频谱分析匹配。

meta 会影响频谱分析(听歌识曲)匹配结果,但 meta 对匹配结果的影响仅作用于由频谱匹配相似决定的歌曲范围之内。

换言之,在 meta 中把曲名设置成 Hop 并不能使得一首不是 Hop 的曲子匹配结果为 Hop,
而当这首曲子在匹配到一堆频谱相似的不同版本时,曲名为 Hop 会影响最终选择哪个版本作为结果。

之后从网络请求层面来观察。

本地播放时会发送两个与匹配曲库有关的 API 请求,API 的请求参数被加密,但返回内容是明文的(相关技术特性广为人知,可参考许多网易云音乐加密/非公开接口的开源项目)。

未尝试溯源明文,故 API 提交内容和用途纯粹猜测。
/eapi/search/match/new 疑似 hash 匹配
/eapi/music/matcher 疑似频谱匹配

当播放歌曲A的网络下载的版本时,先请求疑似为 hash 匹配的 /eapi/search/match/new,这一步的 API 返回匹配到曲库中的歌曲A条目,拉取歌词。

当播放歌曲A的中间几秒静音的修改版时,也先请求疑似 hash 匹配的 API,但返回匹配结果为空,进一步请求 /eapi/music/matcher,提交的字节数大于前一 API,疑似频谱特征匹配,成功匹配到曲库里的歌曲A条目后拉取歌词。

对于已经成功匹配过歌词的本地歌曲,下次播放时不会再发出任何匹配相关的 API 请求,即前文已经介绍的缓存机制,重启可使缓存失效。

/eapi/search/match/new (疑似 hash 匹配的 API)的 hash 收录机制不明,可能其仅对被广泛持有的歌曲文件的 hash 进行收录。

歌曲A的中间几秒静音的修改版在曾经历过 hash 匹配为空->频谱匹配得到结果后,(待本地缓存失效后)再次播放时,依旧会经历 hash 匹配为空->频谱匹配得到结果 这一过程,而不是在 hash 匹配阶段就拿到有效的匹配结果。
0

♥ 若您欲转载敝站的原创内容,还请您附注出处及相应链接

评论

  1. Eric_Lian 2019-05-01 09:36 回复

    有点意思。

发表评论

电子邮件地址不会被公开。必填项已用*标注

Ɣ回顶部