游戏音频总是存在文件压缩方面的需求。这是因为磁盘空间或者说内存是有限的，不管自己有着怎样宏大的音频设计构想，也没办法都用原始未经压缩的音频样本。在此，我们就来说说如何为游戏选择最适合的音频编解码器。
每一种编解码器都有自己的优点和缺点。有时我们并不确定要选用哪种编解码器。首先要明白的是，没有哪种编码器能满足所有平台的要求。在特定平台上，甚至都无法完全满足各种声音类型的需求。因此，我们要摈弃“一种编解码器满足所有需求”的想法。
若不想了解 Wwise 都支持哪些编解码器，而只想知道自己应该选用哪种编解码器，请跳到最后一节看看怎么快速做出选择。
压缩和性能
Wwise 支持 4 种软件编解码器：PCM、ADPCM、Vorbis 和 Opus。选用这些编解码器有一个主要的优势，就是其在不同平台上的表现是一致的。我们可以在所有平台上获得完全相同的品质、相对性能和行为。它们都支持 Wwise 音频源的全部功能，硬件编解码器则不然。
除此之外，每台游戏主机还配备了硬件音频处理器。其各自有不同的功能，在各个平台上的表现也不相同（请继续阅读来了解相关限制）。Wwise 支持对经过压缩的源进行硬件解码，在平台允许的时候甚至支持更多硬件处理。
关于“品质”一词的说明
首先，关于音频品质有个不幸的事实：它是主观的。没有一定的公式或数字可以告诉我们音频好与不好。不过，我们还是有一些值得参考的衡量指标的。在设置编解码器的参数时，最重要的是 Quality/Bitrate。不过在选择所述设置时，要明白其到底意味着什么。
Quality 设置用在可变比特率编解码器中，通常是没有单位的。说白了，它不过是众多内部规则和参数的具体化指标，代表最终会为不同频段分配多少比特的数据（就像图像的分辨率）。鉴于声音的频谱会随着时间不断变化，不同声音部分的压缩效果也不尽相同。不难想象，一秒钟近乎无声的内容会被压缩得很厉害，一秒钟的重金属音乐则可能压缩不了多少。
Bitrate 设置用在恒定比特率编解码器中，它的含义非常直观。简单来说，就是要重建一秒钟的音频需在这一秒读取多少比特的数据。可以说，用来重建声音的信息越多就越接近原声。有人可能会问，如果声音的音频信息量随着时间变化，那怎么能用每秒相同的比特数压缩呢？很简单！就是随着时间改变频谱的分辨率，这样所用的比特数就总是相同的。拿上面的例子来说，编解码器会用较多的比特对近乎无声的内容进行编码，因为资源足以充分表示这部分数据。相较之下，重金属音乐的分辨率会更低一些，因为需要重建大量数据，而用于表示这些数据的比特数却很有限。所以，完全没必要为了控制文件大小而使用比特率受限的编解码器。这只是个简单的例子。当然其中还采用了很多其他的技术，不过这已经超出了本文的讨论范围。
所以，我们也可以把“可变比率/恒定比率”属性看作“恒定品质/可变品质”。总的来说，现代编解码器采用了非常先进的心理声学模型。即便设为较低的品质，其也能避免很多类型的声音出现刺耳的杂音。我说的“刺耳”是说听起来让人很不舒服，甚至非音响发烧友都会觉得“音质很差”。毫无疑问，我们都希望能设法避免产生这样的杂音。
除此之外，还有很多被归为“再现保真度损失”的压缩杂音。换句话说，压缩的声音跟原始声音会略有不同。这种差别其实是可以听出来的，但要做 A/B 比较才能明确分辨。不了解情况的听众可能根本分不出哪个才是原始声音。就整体音频体验而言，这些压缩杂音其实没那么重要，因为游戏玩家并不会因此走神。
对有些声音来说，忠于原声很重要。比方说，音乐。因为任何滤波或频率失真都很明显，尤其是对受过音乐训练的听众而言。相较之下，即便爆炸声或脚步声的保真度偏低一点，只要没有刺耳的杂音也不会有人注意到。此外，还要记住大多情况下声音并不是单独播放的，也不会以最大音量播放。最终，即使保真度稍微低一点，也很容易被混音掩盖掉。这样也方便节省内存空间或 CPU 处理资源。最简单的方法是先按声音类别选择 Quality/Bitrate 设置再根据需要进行微调。若使用恒定比特率编解码器，应确保为其留出一定的余量。这样可以设置更高的比特率，来掩盖音量较大的声音部分。
压缩比率
压缩比率就是最终文件大小与原始文件大小的比率。对于音频编解码器，在计算时只针对文件的音频样本部分，不包括 WEM 容器或标记。而且，也不包括之前的降采样。下表对各种编解码器的压缩效率做了对比。对于可变品质编解码器，音频内容和设置无疑会对结果产生很大影响。
|
编解码器 |
压缩比率 |
比特率 |
|
PCM |
1:1 |
恒定 |
|
ADPCM |
4:1 |
恒定 |
|
Vorbis |
2:1 - ~40:1* |
可变或恒定 |
|
Opus |
2:1 - ~60:1** |
恒定 |
|
XMA |
6:1 - 15:1 |
恒定 |
|
ATRAC9 |
8:1 - 13:1 |
恒定 |
(*) 因所选品质和音频内容而异，一般很难达到上限。
(**) 跟 Vorbis 一样，不过语音内容（窄带）和一些乐音内容（音乐）的比率要高很多。
CPU 性能
下表显示了几种软件编解码器的吞吐性能。所谓吞吐性能，就是单个内核最多可实时解码的音频流数。该数值只针对解码器本身，不包括重采样、声部管理开销、中断、内存总线瓶颈等。总之，解码器是在最佳条件下单独实施估算的。目的是让大家对最高性能有个大致的了解，不过在实际游戏环境中不太可能达到上限。另外，表中还与硬件编解码器支持的最大音频流数做了比较（如下所示）。对于 Vorbis 和 Opus，3 个数值分别代表相对于整个性能范围的最低、默认和最高品质设置。
最大音频流数
|
平台 |
ADPCM |
Vorbis（低中高品质） |
WEM Opus（低中高品质） |
|
Mac1 |
10700 |
7500 - 5900 - 3100 |
1600 - 1200 - 700 |
|
移动2 |
8600 |
5200 - 4300 - 2100 |
1100 - 800 - 500 |
|
PC3 |
9500 |
5700 - 4600 - 2300 |
1300 - 1000 - 500 |
|
PS4 |
3200 |
1200 - 1000 - 500 |
300 - 200 - 100 |
|
PS5 |
7600 |
5900 - 4700 - 2500（软件）80（硬件） |
80（硬件） |
|
Switch |
2000 |
600 - 500 - 300 |
200 - 150 - 100（软件）20（硬件）4 |
|
XboxOne |
10000 |
1000 - 3400 - 1200 |
300 - 200 - 100 |
|
XboxSeriesX |
9200 |
6900 - 5400 - 2800 |
300（硬件） |
1. Mac M1
2. ARM64 Cortex A9
3. Core i7 (circa 2018)
4. 使用软件 Opus (WEM)。硬件解码器使用稍有不同的编解码器 OpusNX（参见下节）。
硬件限制
Wwise 有一些特定的功能与编解码器的硬件实现有关。如果硬件不支持，Wwise 会尝试在软件中模拟同样的功能，但会有一定的成本，有时甚至根本无法实现并会报错。下面列出了可能支持的功能（具体取决于平台）：
- 精确到采样点的循环：能在同一音频流的任何采样点开始和停止循环，而不受原生编解码器数据块的时长影响。在 Wwise 中，该功能与 Loop 复选框对应。
- 精确到采样点的过渡：能在任何采样点停止声音并在任意位置跳转到另一音频流，而不受原生编解码器数据块的时长影响。在 Wwise 的 Sample accurate transition 模式下，这对 Random/Sequence Container 非常有用。
- 可变重采样：能在声音的整个持续期间动态调整采样率或音高。
下表简要列出了对硬件功能的支持情况。在不支持的情况下，将通过软件来实现，但会有额外的成本。
|
编解码器 |
平台 |
硬件 |
精确到采样点的循环 |
精确到采样点的过渡 |
可变音高 |
最大音频流数 |
|
PCM |
全部 |
否 |
是 |
是 |
是 |
|
|
ADPCM |
全部 |
否 |
是 |
是 |
是 |
|
|
Vorbis |
全部1 |
否 |
是 |
是 |
是 |
|
|
|
PS5 |
是 |
是 |
否 |
是 |
80 |
|
Opus |
全部1 |
否 |
是 |
是 |
是 |
|
|
|
PS5 |
是 |
是 |
否 |
是 |
80 |
|
|
XBX |
是 |
是 |
是 |
是 |
300 |
|
|
Switch |
是 |
是 |
否 |
否 |
12 - 243 |
|
XMA |
XB1 |
是 |
是2 |
否 |
否 |
128 |
|
|
XBX |
是 |
是2 |
否 |
否 |
128 |
|
ATRAC |
PS4 |
是 |
是 |
否 |
否 |
60 - 5003 |
|
|
PS5 |
是 |
是 |
否 |
否 |
120 - 10003 |
1. 全部（除以下指定平台外）
2. 只能在 128 个采样边界运行 XMA 循环
3. 最大值取决于诸多活跃声音的声道数、比特率和粒度。合理的最大值为中间值。
硬件延迟
硬件加速一般会通过 DSP 协处理器来完成。因此，其要像其他 CPU 一样处理数据，而且不是即时的。它的主要优点是能与主 CPU 并行运行。不过，DSP 本身比主机配备的高端 CPU 要慢很多。
并行运行有两种操作方式：同帧处理或延迟处理。具体由 bLowLatencyHwCodec 标记来控制。在第一种模式（设为 true 时）下，硬件源和软件源之间没有延迟。压缩后的数据会被发送给解码器，由 Wwise 对其他软件源进行处理。如果没有其他软件源，则由 CPU 进行处理，直到硬件发出结果就绪的信号。然后，会在同一音频帧对这些音频进行处理和混音，并确保与其他软件源同步。因此，不会增加任何延迟。这意味着 Wwise Profiler 所报告的处理时间会更长，因为其包含了让渡时间（CPU 可跳转到其他任务）。不过，所有操作都会同步执行。
在第二种模式（设为 false 时）下，会在一帧内向解码器发送数据，不过会在下一帧获取结果。这样做的主要好处是可以完全掩盖 DSP 的处理时间。但是，所有声音都会延迟一帧。如果必须同时同步软件和硬件声音，或游戏对延迟要求很严格（如节奏游戏），就可能会造成问题。不过，就整体系统性能来说，这种模式的效果最好。
总之，硬件解码可以释放 CPU 来做其他事情。不过从绝对意义上讲，这并不意味着其能比 CPU 处理更多的原始音频。当然，您也可以混合使用硬件源和软件源来最大限度地提高并行处理性能。
硬件解码没有代价吗？
简而言之，当然不是。即使在最新一代的主机上也非如此。硬件解码的成本跟原始 CPU 周期在形式上有所不同。硬件解码器在不同平台上的物理实现、驱动程序实现、操作系统集成以及可用 API 都存在很大差异。所有这些使得对编解码器的成本对比变得非常困难。不过，也有一些普遍存在的成本。
在很多情况下，对解码器发出命令的 API 会跨越内核的界限，而这通常会产生一定的成本。在有些平台上，会将命令发送到受某些线程同步保护的队列，并可能因而停滞一段时间。在有些情况下，需要将包含压缩输入流的内存转储到硬件解码器可辨识的内存，而这部分内存可能跟主内存是分开的。对于音频输出，可能也要这样做。另外，输出的格式与声音引擎其他部分不匹配的情况也是常有的。这时就需要实施转码。对此，有些硬件会分批运作，须完成整批操作才能获取结果；有些硬件则一就绪便会返回结果。
总的来说，考虑到所有这些成本，硬件编解码器一般不太适合很短的声音（短于 100 ms）。因此，鉴于短促声音的使用频率、持续时长和所用平台，其可能比纯软件解码的成本还要高。比如，对于很干/很短的脚步声、撞击声或通过 Trigger Rate 机制触发的重复枪支音效就要特别注意。另外，通过精确到采样点的过渡使用 Random Container 或 Sequence Container 实施的粒子合成对硬件编解码器来说也是有风险的。
有关各种编解码器的补充说明
PCM
PCM 是一种未压缩媒体，它的唯一优点是速度快。主要缺点是占用磁盘和内存空间，因为没有经过压缩。所以，只建议将其用于在低配平台上频繁使用的声音。目前而言，一般的平台都不会选用这种编解码器。
ADPCM
ADPCM 在游戏行业用得比较多。该编解码器在 CPU 方面的性价比较高，所以最初在老款主机中应用得很广泛。固定压缩比率 4:1，解码速度非常快。主要缺点是品质不稳定。对于具有明显瞬态或超高频率成分的声音，在实施处理的时候会出现清晰可辨的杂音。不过，这些情况一般很少会发生，所以 ADPCM 还是经常被拿来使用。
Vorbis
这是一种通用的心理声学编解码器。它会利用人耳和大脑的特性来帮助压缩音频并最大限度地减少杂音。这种编解码器最初因其良好的音频品质和出色的文件压缩效能而被应用于游戏领域。其压缩比率变化很大，具体取决于音频信号。具体来说，介于 2:1（最高品质，对于宽带信号）到 40:1（最低品质，对于窄带信号）之间。Wwise 采用的编解码器实现经过了反复优化，现在其平均 CPU 成本约为 ADPCM 编解码器的 1.5 ~ 3 倍。
Vorbis 是可变比特率编解码器，其压缩比率取决于文件的内容。一般来说，声音越嘈杂，压缩幅度越小。此外，其 CPU 成本与所用的 Quality 系数直接相关：品质越高，解码所用的 CPU 资源越多。
这种格式需要使用寻址表才能执行寻址操作。它支持 "From elapsed time" Virtual Voice 选项和 Interactive Music 功能。寻址表是可以选用的。若选择不使用此功能，则可避免相应的成本。不过，一般情况下最好启用。注意，大多情况下都可通过选用较大的粒度来降低寻址表产生的成本。
此外，这种格式的元数据开销较小。所以，很小的文件会因此受到影响。一般来说，对于短于 50 ms 的声音，可能会大于正常大小。
Opus
就品质之于文件大小而言，Opus 编解码器是最优选择。它是在 Vorbis 之后推出的，在压缩比率上有显著提升。根据对听众的主观测试，其感知品质略高于 Vorbis（参见 https://opus-codec.org/comparison/）。与 Vorbis 相比，它可以在保证品质的同时实现更高的压缩比率。不过，它的 CPU 成本相对较高，且一般会比 ADPCM 慢 5 ~ 10 倍。
Opus 格式不太适合很小的文件。其算法需要几毫秒的数据来正确设置，所以文件中会增加 80 ms 左右的音频。因此，用 Opus 处理长度与此相当的微粒化音频是一种浪费。一般来说，如果声音短于 200 ms，请选用 Vorbis 或 ADPCM。
XMA
这种编解码器仅适用于 Xbox 平台。自 Xbox360 以来，用的基本上都是这种编解码器。它的主要优点是通过硬件进行解码。不过，硬件的速度并不是特别快，最多只能处理 128 条音频流。而且，对有些音频内容的压缩效果不怎么好，有时甚至可能会出现清晰可辨的杂音。不过，这种情况一般很少会发生。最后，这种格式本身将循环点限制为了 128 个采样点的倍数。这样的话必须回到 CPU 处理才能对循环做精确到采样点的拼接。
ATRAC9
这种编解码器仅适用于 PlayStation 平台。它的特点是总是在硬件中实施解码。有些声音可能会产生一些可辨的杂音，不过只需更改所述设置就可解决问题。还好，这种杂音同样很少出现。
如何选择适合自己的编解码器
找到适合的编解码器不是个简单的问题。这取决于用户的关注点在哪里：品质、速度、文件大小还是与其他声音同步？显然，还跟所要使用的平台有关，因为其决定了可能的选择。
品质最佳 vs 文件最小（同等品质下文件最小）：首选 Opus，其次 Vorbis。
品质最佳 vs 速度最快：显然除 PCM 外，Vorbis 是软件解码速度最快、品质最好的。若硬件支持 Opus，则优先选择 Opus。
原始速度最快：首选 PCM，其次 ADPCM。显然，如果硬件支持并允许高延迟，所有硬件编解码器都没问题。
我推荐的默认编解码器是 Vorbis。对于中等品质要求的音频，在硬件支持的情况下，也可考虑使用 Opus。
建议先通过所选编解码器和设置运行声音样本并仔细监听杂音，然后再将整套声音设计素材交给特定的编解码器装置进行处理。
一般来说，最好结合使用硬件和软件编解码器来获得最佳吞吐性能（即在最短时间内处理最多的样本）。在 CPU 对软件文件进行解码时，硬件可以并行执行自己的任务。若没有软件源，则会受到硬件解码器速度的限制，而硬件解码器的速度有时并不快。
VO
现代游戏通常包含大量 VO 文件。所以，要尽量缩减这些文件的大小。就这一点而言，没有比 Opus 更好的编解码器，即使它是在软件中实施解码的。另外，Opus 有个专门用于人声压缩的子编解码器。通常，同一时间只会有一两句 VO 处于活跃状态，因此解码成本会保持在有限的范围内。显然，这在支持 Opus 硬件的 3 个平台上根本不是问题。
枪声、撞击声和其他短促的粒子化声音
这类声音在游戏中一般会反复播放，并通过文件的组合来实现多样变化。如果文件比较短，最好选用 Vorbis。因为它的压缩效果相对较好，且在所有平台上解码速度都很快。在 PS5 和 XboxSeriesX 上，也可以考虑选用 Opus。但若要针对文件大小实施优化，就没必要使用这种编解码器了。在低端移动设备上，如需释放 CPU 处理资源，则可考虑选用 ADPCM。
常用音效
对于较长的 SFX，应优先选用硬件编解码器（如支持）。若平台不支持，最好选用 Vorbis。若 CPU 负荷过重，则可选用 ADPCM。
环境声
背景环境声通常由循环和添加的不同长度的细节音效组成。在有些设计当中，可能会播放很多此类的声音。我的建议是，只要平台提供支持就使用硬件编解码器。如若不然，可考虑选用 Vorbis。
音乐
Opus 是不错的选择，因为它是专为音乐设计的编解码器。在软件中解码时，若音乐很复杂或要同时播放很多分层，Opus 可能会对 CPU 造成很大的负担。倘若所有乐曲都通过硬件解码，硬件编解码器会是不错的选择。对于结合使用软件和硬件解码的乐曲，同步起来会比较麻烦（参见前文“硬件延迟”章节）。在这种情况下，可考虑改用 Vorbis。
最后的建议
关于编解码器我能给出的最简单的建议就是：不用太过担心！至少在项目初期不必如此。在刚开始的时候，为所有源选择一种通用编解码器并设为中等品质即可。或者，也可以为声音大致定义三到四个 Conversion ShareSet。然后，项目步入正轨再考虑设计的性能、实施性能分析并在必要时更换编解码器。因为在 Wwise 中可覆盖任何层级的 Conversion Settings，所以可轻松针对特定的声音设计部分使用专门的编解码器。
只要音质不错并且在预算之内，就不用太担心编解码器的问题。如若不然，记住还有很多选项，可以根据需要进行调整！
评论