TS3-Codec

论文：TS3-Codec: Transformer-Based Simple Streaming Single Codec

没开源代码。

Introduction

完全基于Transformer的Codec，简单、流式；相比基于CNN的STOA，12%的计算资源，77%的bitrate。

之前的Moshi Mimi和WavTokenizer是部分Transformer。

NAC的重要属性：

  • 流式：实时双工交互。
  • 单码本：架构简单。
  • 低资源消耗。
  • 低Token率。

架构

  • 滑动窗口（大小16或32）
  • Enc/Dec对称，8层16头，4096FFN dim
  • factorized VQ，codebook dim 8或16，codebook size 65536或131072

整体架构图如下：

Decoder实现基于：wetdog/wavenext_pytorch: Unofficial implementation of wavenext vocoder

设计原则：

  • 卷积层通常在参数效率和可复用性上表现较好，但在相同的参数规模下，卷积层的计算量通常比 Transformer 更大^①^。
  • 卷积操作具有固有的偏差。卷积层在不同时间戳的所有中间特征图上应用固定的加权和权重，而 Transformer 使用自注意力机制，根据每个特征图动态地确定权重。Transformer 还引入了位置Embedding，使得不同时间戳的不同特征图可以添加不同的Embedding。
  • Transformer 在模型设计上提供了简洁性。与卷积不同，卷积由于其固有的偏差（对超参数设置敏感），需要仔细选择卷积核以及上下采样机制，而 Transformer 可以避免这些复杂性。

训练目标

和BigCodec一样。不同的是将 VQ 损失与码本大小成正比：

  • 码本大小8192，4.0
  • 码本大小65536，32.0
  • 码本大小131072，64.0

实验配置

6w小时的Libri-light训练，test-clean Librispeech测试（和BigCodec一样）。

BigCodec-S一个样本2.5s对话长度，TS3-Codec是10s。

1000步Warmup，BigCodec-S的lr从1e-4到1e-5，TS3-Codec的从2e-4到2e-5，训练500k步。

评估指标

  • 复杂性和提取的 token 的属性
    • Paras：参数量。
    • 乘加运算（MACs）：MACs 指的是模型中的基本计算操作。本文基于 PyFlops 计算了 1 秒音频话语的 MACs6。对于 PyFlops 不支持的模块，如流式 Transformer，进行手动计算。
    • 每秒比特数（BPS）：衡量每秒传输的比特数。这个指标用来展示传输音频质量与压缩率之间的权衡。
    • 令牌率（Token rate）：表示每秒编码音频所需的令牌数的指标。它是语音语言建模中的一个重要衡量标准。
    • 帧率（Frame rate）：表示编码每秒音频所需帧数的指标。
  • 可理解性
    • 词错率（Word Error Rate，WER）
    • 短时目标可理解性（Short-Time Objective Intelligibility，STOI）
  • 失真度
    • 梅尔倒谱失真（MCD）：MCD 衡量两个梅尔频率倒谱系数（MFCCs）序列之间的差异。它通常用于语音合成和语音转换任务中，以评估生成语音的质量。
    • 语音质量感知评估（PESQ）：PESQ 通过将降级的语音信号与参考信号进行比较来评估语音信号的质量，提供一个预测人类语音质量感知的分数，较高的值表示更好的质量。本文使用了wide-band PESQ。
  • 说话人相似度：
  • 自然度

实验结果

如果看非流式，BigCodec不愧是SOTA，表现出相当不错的水准。流式，感觉MIMI更具潜力。TS3-Codec在Token Rate上有一定优势，但参数量相比MIMI高了不少。另外，MIMI是多码本的，虽然Token Rate高了不少，但Frame Rate只有12.5。不过单码本流式那确实只有TS3-Codec了。

可惜本文依然没有做Scale up的消融，不知道Transformer架构能否在Codec上Scale up。

另外WavTokenzier实际使用效果不太理想，普通音频重建效果不太好。

解释说明

①关于相同参数卷积比Transformer计算量大的解释：

  • 卷积层的计算过程涉及多个局部区域（卷积核）与输入数据（如图像、特征图）的逐一滑动匹配。如果卷积层的滤波器（卷积核）的尺寸较大，或输入特征图的分辨率较高，那么卷积操作需要处理大量的局部区域计算，从而增加计算量。Transformer 的自注意力计算是基于矩阵乘法的操作，通常是通过并行计算（如 GPU/TPU 上的大规模矩阵运算）来加速。尽管对于长序列，Transformer 的计算量也非常大，但它的计算过程本质上不依赖于滑动窗口和局部区域的计算，而是基于全局信息的整合。
  • Transformer 模型（特别是自注意力机制）可以利用高度并行化的计算来加速，尤其是在使用硬件加速（如 GPU 或 TPU）时。这使得 Transformer 可以在计算量上相对高效地处理长序列。相对而言，卷积操作更依赖于顺序计算，因为卷积层中的每一个局部区域的计算是必须依次进行的，尽管可以在某些情况下进行并行化，但相比于 Transformer 的全局计算，它的计算瓶颈更为明显。

总结

第一个全部用Transformer的Codec，遗憾的是本文没有Scale up的消融（不过也许可能是没效果）。实验结果图2可能是为了对比做的，但我们可以猜测，是否Token Rate比较低时，CNN没有Transformer抽取特征效果好？

另外，个人观点，CNN处理音频从架构上更加合理，因为音频和文本不一样。音频前后虽然也存在语义，但更多依赖的是局部特征。比如一个词的发音很可能和个人习惯有关，而和语义关系不太大。所以Transformer可能更适合语义、全局特征；但CNN对局部特征处理更佳，对前后特征变化更敏感。

对一个Codec来说，声学特征肯定是决定性优势的，语义在其后。这两者能否合二为一呢？GLM4Voice给了我们答案：可以，但需要预训练，而且合成还需要借助TTS模块。这也是个人比较看好MIMI架构的原因，它把语义和声学分开，不仅保证了语义，而且多码本还能保证音频质量，适合端到端建模。MIMI唯一的不足就是架构复杂了不少，但其实整体是很清晰的。本文评测结果中，MIMI的效果整体其实很有优势，尤其它还是流式，全双工的。另外，实际用下来也还可以。