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

从他处下载的歌曲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 匹配阶段就拿到有效的匹配结果。