更新 | 小名开开

守望先锋 1.14 版本后更改了底层数据格式

2017.12.25

参考老文章： Overwatch Toolchain 解包方式考察，OW 音频小站一直以来使用原始文件 hash 的办法，便每次更新以后，都能区分旧数据和新增数据，使得每次更新的条目数量都在合理范围。但从版本 1.14 开始，暴雪更新了内部数据格式，这个是由蓝帖明确提到的，目的是减少之后的每次客户端更新时的下载。

但这对本小站来说不亚于一次冲击。这意味着，直到 1.13 版为止的条目，和从 1.17 版开始的所有条目，无法从数据角度建立『新』与『旧』的联系。

也就是说，明明从用户角度来说是同一句台词，音频波形也一致，但由于 OW 内部格式的变化，导致 hash 计算的结果变化，使得从数据角度来说，它们变成了两个不同的条目。

比如：【D.Va 】D.Va 一分，坏蛋零分。（1.17 版本）的 hash 计算结果是 5908654fbc3965232689836abb249c57，而
【D.Va 】D.Va 一分，坏蛋零分。（1.16 或更早版本）的 hash 计算结果是 1d99c1739f5b0844f57f3a1a5fbb4580。

我做了很多尝试，试图恢复一些信息，把这些本质相同的音频重新联系起来，有些成功了，有些失败了。最后我把匹配成功部分更新到原有条目上，匹配失败的部分按『新增音频』对待，添加到数据库里。

尝试使用音频分析软件批量比较，如果成功，理论上这是最好的办法。
- 这是本质的解决办法，如果两个音频文件的波形完全一致，则两个音频当然是一样的。
- 尝试了 Audacity 和 Similarity，前者缺乏批量功能，后者无法对这种只有一两秒的音频进行比较，均告失败。
尝试使用新版本拆解工具拆解旧客户端，失败，但得到了启发。
因为拆解所用的 Toolchain 工具链（简称 TC）本身有自己的文件名系统，而我亦保留了过去所有版本的原始拆解数据，理论上能通过新旧版本文件的相同路径名等信息恢复联系。
测试以上两条 D.VA 音频的 TC 路径分别为：
- 旧(1.13)：cn\heroes\D.Va\Sound Dump Full\_Base\000300000057\000000020231.wem
- 新(1.18)：cn\HeroVoice\D.Va\00000000059F.078\000000020231.wem
测试成功。
进入实操，发现由于旧版本拆解工具的不完全，数据存在错误，依然有许多坑要填：
- 一，多个不同的 TC 文件名对应同一个 hash，即多个 1.18 新文件条目对应同一个 1.13 旧条目 hash，错误在旧版拆解工具自带的文件名系统有 bug。
  - 解决办法是视为多个条目，并将旧条目的听写内容更新到各个新条目上。
  - 对于网站用户来说，同一个关键词可能会搜索出几条内容，但其中应该至少有一条是对得上的
- 二，同一个 TC 文件名对应多个一个 hash，即同一个 1.18 新文件条目对应多条旧的 1.13 旧条目，显然错误还是旧版折解工具的不完善
  - 解决办法只能是人工筛选按多条里面正确的那条。
  - 大约一共有 1200 条这种类型的错误，一条一条听完。网站用户肯定会得到正确的结果，因为这部分我都筛完了。

这次更新正常应当在 1.14 新版数据格式更新，1.17 新版拆解软件开发成熟以后更新，但这数据处理是真 TM 麻烦啊，烦死了。

ow.thnuclub.com 更新与计划更新

2017.09.29

小站因为忙停更了一段时间，结果被各种催更。值此国庆佳节加之周末免费，趁势也更新一下，再开些空头支票。

Done：更新末日铁拳、地平线月球基地及其它英雄新增语音。（1.13 版客户端拆解）

时间有限，只处理了增量更新部分。旧数据的疏漏错误更新后依然存在。他日有空再逐步更新旧数据。

Done：去掉了早期开发的赞与踩功能。

在去年小站刚出来时，曾指望让热心用户通过 vote / devote 功能，把『有内容的音频』也就是台词、音乐等条目上浮到前几页，让意义不大的嘈杂环境音下沉。但事实看来结果不好，一来是用户并没有很好地理解该功能。后台数据显示，被踩得最多的是源氏的龙神拔刀，其次是麦爹的午时已到。想必是冤魂太多，多少发泄一下吧╮(￣▽￣”)╭。二来呢，我看到这个数据以后也就懒病发作，没有继续考虑改进该功能了。后来还短暂地改成『倒放音频』，也就是猎奇一番，甚不实用。今日该功能彻底取消，就当是当年那几千投票，终于修正成果了吧。

Done：调整了下界面，加了圆角、阴影，js 代码的报错部分也处理了。

主要新增数据会用黄色标签显示在上方。条目按钮加了细微的圆角和渐变阴影，整体会更柔和一些。同时每页条目数从 200 条减少到 100 条，相应的显然页码数量也加了一倍。因为网页背景本身是守望的全屏截图，故整体风格不会有大的变化，没有前后对比，不仔细看的话应该看不出来。修正 JS 报错这事其实也可做可不做，只要不搞死页面，能正常执行功能，jQuery 也就这样了。

Done：加了打赏按钮。

这个没啥说的，目前平均也就每周一罐可乐，但听见叮咚声时的好心情很值钱。摊开算收益的话应该现在就把小站关掉，每年能省千儿块服务器钱。

Done：更新 36729 条音频的 MP3，音质略有提升。

音频文件的处理路径是游戏客户端→.wem格式→.ogg格式→.mp3格式，理论上每一步都会有损耗。为了能在网页上直接播放必须使用 MP3，但之前在把 OGG 转为 MP3 时我选的是 LameXP 里的质量等级 2（一共 10 级），现在我想通了，把质量等级改成了最高的 0。当然，质量越高，mp3 的体积也越大，从质量 2 到质量 0 体积平均会增大 50%，也就是大概每个文件 20KB 会增加到 30KB。

这对视频制作者会有所帮助，下载的音频在嵌入视频后的音效会有略微的提升。对 Lame 编码而言，质量 2 到质量 0，新增的数据主要集中在轻微的、高频的或者低频音域。这些音域的补足会让音频的回声、立体感和通透性更好一点点点点，就当是信则有吧。

缺点是，对于使用手机流量访问的用户流量的消耗会增加。目前统计的平均每条数据大概是 28KB，请量力而行。至于对网页响应速度则是几乎没影响的，你的主要延迟是来自于与 Github.io 这个网站（我拿来存音频源）之间的通讯延迟，至于下载的数据是 20KB 还是 30KB，差的不过是 0.0x 秒而已。

Done：当条目文字很长时改用换行式，取代当前的隐藏式。

这个功能和上一条类似，不难，但是会比较烦。换行以后会涉及到每行高度的变化，于是打开编辑面板时的对齐代码就需要调整。同时变化的高度也意味着右侧的齿轮按钮也要相应变化，现在它的高度是写死的。~~更麻烦的是 Input 框的高度自适应我没做过，可能要换用 contenteditable 的 div，要调整不少代码。~~好处当然也是显而易见的，长句子台词可以一次看完整了。

Input 框暂时先不修改了，太麻烦要查资料，一时搞不定。条目本身现在是换行式的了。