共计 6830 个字符，预计需要花费 18 分钟才能阅读完成。
在上一篇文章中，咱们实现了对音频前解决三剑客的学习。声音信号通过音频前解决模块，曾经“洗尽铅华、去除杂质”，当初，你是否已急不可待想要将它们分享到世界各地了呢？但稍安勿躁，想要更好地与世界分享咱们的声音，还有一个不得不思考的问题，而这个问题将由咱们明天的配角“音频编解码”来解决。
音频编码压缩的必要性
咱们都晓得，要想把音视频数据实时分享到世界的各个角落，有一个传输工具必不可少：网络。而要用好这个传输工具，有一个必须关注的点：网络带宽。
作为资深网民，大家必定都理解过带宽。它指的是网络链路 1 秒钟内能传输的最大数据量，其单位个别应用 bps（bit per second），对应到推流（上传）/ 拉流（下载），能够相应分为上行带宽和上行带宽。如果把网络比喻为高速路，那么带宽就相当于这条路的宽度，音视频数据相当于路上来往的车辆。公路越宽，则容许并行通过的车辆越多，其运输能力就越强，如果路线太窄、须要并行通过的车辆又太多，可能会呈现阻塞、甚至是车祸。对应的，网络带宽越大，单位工夫能传输的数据越多，如果带宽有余，势必导致传输异样，产生卡顿、甚至数据失落等影响用户体验的问题。
基于对带宽的理解，咱们进一步看看纯音频场景对带宽的需要状况。咱们曾经晓得，音频模拟信号经数字化解决会失去规范的数字⾳频数据裸流，其格局为 PCM。无妨先来计算一下，如果间接传输 PCM 数据须要多少带宽。
音频数据传输所需的带宽，能够通过音频码率来度量，在 音频必知必会之音频因素 一讲中，咱们曾经学习了音频码率的概念及计算形式。对于采样率 44.1K Hz，位深 16 bit 的双声道音频 PCM 数据，它的码率为：
采样率 /Hz * 位深 /bit * 声道数 * 时长(1s) = 44100 * 16 * 2 * 1 = 1411200 bps = 1.4112 Mbps（bps = bit per second）
也就是说，要求推流用户的上行带宽、拉流用户的上行带宽至多为：1.4112 Mbps。这是单条音频流的状况，如果将场景扩大到语聊房或在线会议，带宽要求还须要根据上麦人数翻 N 倍。而在一些非凡场景，比方曾风行一时的 ClubHouse 或 势头正旺的 MetaWorld，它们甚至号称“不限度上麦人数”，对于带宽的要求必然会更高。依据统计数据显示，2021 年我国宽带网络的上行速率中值约为 35Mbps，思考到理论场景中除了音频之外，还有其余数据须要传输（比方视频数据，所需带宽是音频的数十倍），综合考量下来，带宽也算是“寸土寸金”了，PCM 数据的码率着实让人“高攀不起”。
所以，如何高效利用带宽，如何在无限的带宽下传输更多的音频数据，是咱们的重要课题。而音频编解码，就是这个课题的一个无效解决方案。
在 RTC 音视频数据的解决链路上，音频编码模块位于音频前解决模块之后、网络传输模块之前，其次要作用就是对原始音频数据进行编码压缩，以减小数据量、升高带宽耗费（音频解码模块位于网络接管之后，能够认为是音频编码的反向流程，也即对压缩后的数据进行解压缩、还原）。常见的编码算法，比方 AAC，可能实现绝对于 PCM 数据 1 /15 以上的压缩率，也行将码率 1.4112 Mbps 升高至 0.094 Mbps，带宽占用将失去显著的优化。对于 RTC 场景来说，更低的带宽耗费意味着更好的场景适配性、更好的弱网适应性，这对于 RTC 利用的遍及、用户体验的保障都有裨益。除了带宽优化外，如果有保留音频为文件的需要，编码还能极大加重存储空间的压力。
综上，“升高带宽耗费”和 “升高存储空间占用” 形成了音频编解码存在的必要性。理解其必要性之后，咱们再进一步探索，为什么音频数据能够被编码压缩，编码压缩的“可行性”根底到底是什么呢？
音频编码压缩的可行性
咱们曾经晓得，音频编码过程是压缩、缩小数据量的过程，但“缩小”并不代表能够随便抛弃，而 要在缩小“数据量”时，同时尽可能防止“信息量”的失落，也即保真。如果被压缩的音频数据，其所有信息能够被残缺地解压、还原，咱们称相应的解决为无损压缩；否则，相应的解决即为有损压缩，有损压缩可能带来更好的压缩效益，是 RTC 场景下广泛应用的计划，咱们明天也着重理解有损压缩相干的技术点。
值得一提的是，有损和无损也是相对而言的，目前任何数字编码计划都无奈做到齐全无损，就像用数值表白圆周率 π = 3.1415926……，只能有限进步精度、有限靠近，但永远无奈相等。
注：PCM 就属于“无损”的音频编码，咱们已理解其原理是对模仿音频信号在时间轴、幅度轴上进行采样、量化解决，以使重构的语音波形尽可能与原始语音信号的统一，其保真度好，但编码码率很高，不适用于 RTC 场景。
那么，既然是“有损压缩”，实现可观的压缩率，又要最大限度防止“信息量”失落，这不是互相矛盾了吗？
其实，“信息量”再加上一个定语会更贴切，那就是防止“有用、重要的“的”信息量失落。压缩过程中抛弃的数据绝对于整体应该是“不必要”或“不重要”– 也即“冗余”的。在 RTC 场景中，人是音频信号的消费者，咱们能够充分利用人耳听觉的生理、心理个性来寻找这些“不必要”、“不重要”的冗余成分，总结下来次要包含两方面：
1 人耳听觉范围之外的音频信号
在系列第一讲 - 音频因素 中，咱们理解到：人耳的听力范畴仅限于频率 20Hz ~ 20kHz，低于或者高于该频率范畴的声音无奈被人耳感知，被称为次声波（<20Hz）和超声波（>20KHz）。这部分“无奈被人耳感知”的声音，就属于音频信号中“不必要”的“冗余”局部。同时，因为不同类型信号的频率特色不同，比方语音的频率集中在 300 ~ 3400Hz，如果只关注语音信号，300~3400Hz 频段之外的信号也能够视为“冗余”，能够在编码压缩过程中“抛弃”。
2被掩蔽掉的音频信号
除了对特定频率的声音不敏感外，人耳还会因为“掩蔽效应”而疏忽某些“弱音信号”。对于“掩蔽效应”，咱们以响度（声强级）作为参考（详见系列课程第四讲 - 音频 AGC），做如下了解：
人耳对于不同频率的声音，有相应的最小响度可闻阈，如果某个频率的声音响度小于该频率的最小可闻阈，该声音将无奈被人耳听到。并且，某一频率声音的最小可闻阈不是固定的，当存在能量较大的“强音信号”时，该“强音信号”左近频率的“弱音信号”的最小可闻阈值会进步，这就是掩蔽效应中的“频域掩蔽”，如下图【频域掩蔽】所示。
除了频域掩蔽外，当强音信号和弱音信号同时存在时，在不同机会，还会有“时域掩蔽”。如下图【时域掩蔽】所示，在强音信号呈现前的短时间内（约 20ms），曾经存在的弱音信号会被掩蔽；当二者同时存在，弱音信号会被掩蔽；当强音信号隐没后，还须要等上一段时间（约 150ms），弱音信号能力从新被人耳听到。以上三种类型的时域掩蔽别离称为 超前、同时和滞后掩蔽。
频域掩蔽【图源：网络】
时域掩蔽【图源：网络】
在频域掩蔽和时域掩蔽中，那些“被掩蔽的信号”无奈被人耳感知，所以能够视为冗余信号，能够在编码压缩过程中“抛弃”。
除了利用人耳听觉的生理、心理个性定义的“冗余”外，基于信息论原理，音频信号在时域和频域上的特色具备统计相关性，也即存在数据冗余，这些冗余也能够通过信息编码的形式进行压缩解决。
综上，咱们从声音信号中找到了“冗余”成分，它们是撑持音频编码压缩的“可行性”根底。
当初，咱们曾经理解了音频编码压缩的必要性和可行性，接下来该聊聊具体的音频编码格局了。
音频编解码技术的倒退历经了多个阶段，从针对语音信号的时域编解码、到针对音乐信号的频域编解码，最初也演变出同时兼顾两种类型信号的“全能编解码”，对于发展史大家灵便应用搜索引擎能够理解到很多干货，在此不做赘述。
目前，曾经有诸多成熟的计划供咱们抉择，除了后面提及的 AAC，常见的 音频编解码格局还有：OPUS、SILK、SPEEX、MP3、iLBC、AMR、Vorbis、G.7 系列等等，而在 RTC 利用中罕用的有 AAC 和 OPUS，咱们明天将重点理解这两种格局，并会围绕音视频业务开发者关注的：编码方案的优缺点、如何依据场景来灵便抉择等维度进行讲述。
如何抉择音频编解码格局
在具体介绍 AAC 和 OPUS 之前，先和大家聊聊：如何抉择一个适合的音频编解码格局？以及当咱们抉择音频编解码计划时，咱们到底在“选”什么？
从大方向上看，咱们抉择音频编解码计划时次要思考两点“可不可用”和“好不好用”，而每个大方向上，会有其细分维度。
首先是“可不可用”。具体的利用场景，可能因为某些“限度”导致某些编解码形式“不可用”或者“仅可用”，这些限度次要波及“兼容性”和“适用性”两方面。
对于兼容性，就音视频场景来说，次要指流媒体传输协定兼容性和平台兼容性。而平台可能绑定某种流媒体传输协定，二者个别是关联思考的。比方微信小程序平台反对 RTMP 传输协定，而 RTMP 协定反对 AAC 音频编码，就造成了肯定制约。另外须要留神的是，如果某两个平台反对的音频编解码格局不同，又有互通需要，可能就须要通过服务端转码的形式来搭建桥梁。
对于适用性，次要指的是“频宽反对是否合乎场景需要”。频宽指的是声音频率的反对范畴，人耳对声音频率的感知范畴（20Hz~20kHz）能够被划分成四个频宽区间：窄带、宽带（wideband）、超宽带（super-Wideband）和 全带（fullband），如下图所示：
联合已学习的声音频率、采样率、奈奎斯特采样定理等概念，大家应该很容易就能了解上述图表。举一个简略的例子，音频编解码格局 G.711 仅反对窄带信号，所以在编码一般语音（低频）时“可用“，实用于固话、电话场景，然而在编码全带信号时“不可用”，不适用于音乐直播等场景。
思考了“可不可用”这个根本规范后，咱们还须要有进一步的谋求，那就是 “好不好用”。
某种编解码格局“好不好用”，次要指的是：它在满足特定场景根本要求的根底上，是否将编码工作做到“尽如人意”。而在 RTC 场景下，对于“尽如人意”咱们次要思考音质和提早两方面。
对于音质。音质是大家广泛关注的指标，它的影响因素还比拟多，除了曾经提到的采样率，还有采样位深和声道数，反对的采样位深越大、声道数越多，天然能够更好的保障音质。比方 AAC 反对 96khz 采样和多达 48 个声道，这让它在谋求高音质的场景备受青眼。既然采样率、采样位深和声道数均影响音质，那么基于三者计算的综合指标 – 码率，天然也不例外。一般来说，反对的码率越高、越广，音质越能失去保障、灵活性也越大。那些仅反对固定码率的编码格局，比方仅反对 64kbps 码率的 G.711，其适用范围、音质下限就受到很大的限度了。
对于提早。提早在音视频传输中，指的是音视频数据从“主播端麦克风采集“、到从“观众端扬声器播放”的“端到端耗时”，这个耗时由音视频解决链路上的各个环节引入，包含采集、前解决、编解码、网络传输、渲染播放等等。显然，提早越低意味着实时性越高，也就越靠近于“面对面沟通”，在有连麦互动需要的场景中，“低提早”甚至是最重要的需要之一，关乎用户体验的外围。所以，依据场景需要，抉择一个提早适合的编解码格局相当重要。
综上，当咱们抉择编解码计划时，咱们其实是在 抉择“兼容性”和“适用性”，进一步的，还须要关注“音质”和“提早”，通过这四个细分维度，就根本能保障所选计划是”可用“且“好用”的。最初，咱们就 RTC 场景下罕用的编解码：AAC 和 OPUS，再来比照阐明下。
AAC 和 OPUS 的选取
AAC，是基于 MPEG- 2 标准，由 Fraunhofer IIS、Dolby Laboratories、AT&T、Sony 等公司于 1997 年合力研发推出，通过 25 年的倒退曾经被各个领域广泛应用。而 OPUS 由 Xiph.Org、Skype 等基金会研发推出，2012 年才被 IETF 批准进行标准化，绝对于 AAC，OPUS 更“年老”。对于 AAC 和 OPUS 以及其余常见音频编解码格局的个性比照，有两张图能够很直观的展现，咱们间接看图谈话。
上图展现了各编码算法的编解码耗时（Delay，纵轴）、反对码率范畴（Bitrate，横轴）、反对频宽。
上图展现了不同音频编码在不同码率（Bitrate）、不同频宽上的音质体现（Quaity）。
不难发现，在列举的编码算法中，OPUS 分外注目，它在“频宽反对”、“码率反对”、“提早”和“音质”方面，都有比拟显著的劣势，能够说是“学霸”一个。OPUS 的劣势，得益于它集成了两种编码器：语音编码器 SILK、超低提早的编码器 CELT，并做了很多针对性的优化。它能够无缝调节高低码率，具备极低并灵便可控的算法提早，并反对全频宽。在理论场景的测试中，OPUS 比 MP3、AAC 等编码有着更低的提早和更好的压缩率，音质也不甘拜下风。因而，OPUS 在 RTC 场景下备受青眼，某些对端到端提早极度敏感的场景，更是将其作为必选项，比方实时独唱 KTV，多个用户同时上麦 K 歌，须要依赖极低的端到端提早来保障同步性。
而 反观 AAC，其编解码耗时比 OPUS 高，相对来说不怎么实用于实时互动场景，但它在音质高保真方面，依然有着不俗的实力 ，尤其是在极高采样率、高码率、多声道配置下的编码成果尤佳（AAC 最高反对 96kHz 采样率，而 OPUS 为 48kHz，尽管都是全频宽，然而 AAC 在高频局部 能保留更多细节），非常适合音乐直播。另外，除了规范规格，AAC 系列还在算法提早、编码复杂度、编码效率等方面进行针对优化，推出了多种扩大规格，便于咱们灵便抉择。比方提早优化版的 AAC-LD（Low Delay），从图一中咱们看到其提早已靠近 OPUS；编码复杂度优化版的 AAC-LC（Low Complexity），在中高码率上进一步寻求音质和编码效率的平衡点，并提供更好的兼容性；编码效率优化的 AAC-HE（High Efficiency），进一步提高压缩效率，以谋求在更低码率下取得更高的音质。
其实，从下面的介绍来看，各方理论测试数据表明，OPUS 作为一种“年老”的编解码格局，确实有青出于蓝、长江后浪推前浪的实力，大部分场景下应该是更优于 AAC 的计划。但胜在“年老”也输在“年老”，年仅十岁的 OPUS 和曾经二十五岁的 AAC 比起来，还短少一点“人生经验”和“江湖位置”，别忘了，在“如何抉择音频编解码格局”的评估维度中，有一个重要的指标：“兼容性”。
作为前辈，并且背靠 Fraunhofer IIS、Dolby Laboratories、AT&T、Sony 等巨头，AAC 在各畛域已失去比拟充沛的遍及，领有宽泛的硬件设施、软件应用和传输协定兼容性，这些都是 OPUS 短时间内无奈超过的。比方，RTMP 是直播场景罕用的流媒体传输协定，它对于 AAC 编码具备良好的兼容性，却不反对 OPUS 编码，而大部分的 CDN 厂商均默认应用 RTMP 作为推流协定，某些平台比方微信小程序也仅反对 RTMP 传输，为了保障兼容开发、推广效率，咱们往往只能抉择或优先选择 AAC。
值得一提的是，Google 鼎鼎大名的开源我的项目 WebRTC 应用了同样开源、收费的 OPUS，作为其默认的音频编解码计划，但规范 WebRTC 不反对 AAC。这就导致，一些跨平台的音视频利用须要依赖服务端转码来实现与 WebRTC 的互通，转码操作肯定水平上减少了传输提早和开发运维老本。
最初，咱们通过表格再整顿一下 AAC 和 OPUS 的差异，并在细节上进行适当的补充。
总结
最初，简要总结一下明天的课程内容：首先，咱们理解了音频编码压缩的必要性（带宽和存储空间）和可行性（冗余），学习了音频编解码计划的抉择规范（“两大方向、四大维度”），并基于这些规范，对 RTC 场景下罕用的编解码格局 AAC 和 OPUS 进行了比拟，理解了它们优劣势和实用场景，今后你本人也能抉择一个适合的编解码计划了。
至此，大家已实现了必知必会根底 - 音频编解码局部的学习。咱们的声音走过了采集、前解决、编码的漫漫长路，终于蓄势待发，能够奔赴实时网络的各个角落，传递信息、传播价值，也心愿大家能在音视频利用开发的学习路线上，有所播种，再迈出虚浮的一步。
上面，咱们再通过一个思维导图，梳理一下整篇文章的内容：
问
本期思考题
作为采样率、位宽、声道数的综合指标，音频编码码率对音质会有显著的响应，那对于码率的抉择，是否越高就越好呢？
（🤫下期揭秘）
上期思考题 \ 揭秘 ⬇️
问:
谐波检测为什么能够用于辅助定位人声，进步 VAD 的准确度？
答:
在音频信号中，存在基波和谐波。基波的频率是音频信号的次要频率(基频)、最低频率，决定了声音的音调。谐波的频率比基波高，并且是基频的整数倍，如基频为 50MHz，则谐波呈现在 100MHz、150MHz ……，谐波赋予了音频音色。
语音的一个显著特色是蕴含了基频及其多个谐波频率，即便在强噪声环境下，这一特色也是存在的，能够用自相干的办法找到基频所在频点。所以，提取音频信号中的谐波特色量，能够辅助断定人声。（乐器的音频也有显著的谐波特色，并且和语音类似。
所以，基于谐波特色辅助 VAD 断定的 AGC 算法，个别对乐器音频也是失效的）
