从他处下载的歌曲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 会影响最终选择哪个版本作...

阅读全文>>

※本文旨在描述笔者自己遇到的情况和一些新发现，供您作为预案参考，而非任何面向大众的方案。

现在网络上介绍安卓 QQ （手机QQ）聊天记录数据库基本情况（比如异或加密和表结构）的文章和资源已经相对很丰富了，本文就不再赘述。相关技术此前笔者也略有些了解，但没有实际复现研究细节。

直到近日，笔者因一些原因，不慎搞炸了手Q的聊天记录（历史聊天信息乱码），于是终于有机会（被迫）将这方面的技术拿出来检验是否依旧可行，并尝试用其挽回。

※ 切勿模拟复现以下描述所对应的情况，除非您知晓这其中的高风险度。数据无价，意外丢失追悔莫及。

在过程中，笔者参考历史文章公开的技术情况，基本确认了既往的技术到目前（手机 QQ 7.8）为止，依旧适用和有效，进而复现了相关操作。

由于笔者的个人情况的特殊性，在此过程中走了些苦路，不过也观察和发现了一些似乎还没有人公开发表的新技术，主要是关于安卓手机 QQ 对待聊天数据库加密密钥选取、保存和异常重建的一些基本逻辑和现象。大纲如下：

聊天数据库异或加密存在密钥文件 —— 一般情况下密钥为 IMEI 已经不是什么新闻，但因为密钥文件（手机QQ应用数据目录/f...

阅读全文>>