我不确定 ZyXEL ADPCM 与其他 ADPCM 风格有何不同，但可以通过一些谷歌搜索找到各种 ADPCM 实现。
但是，我发帖的真正原因是为什么选择 ADPCM。ADPCM 是自适应差分脉冲编码调制。这意味着传递的数据是样本的差异，而不是当前值（这也是您看到如此巨大压缩的原因）。在没有比特丢失的干净环境中（即磁盘驱动器），这很好。但是，在流式传输环境中，通常假设比特可能会被周期性地损坏。对数据的任何一点损坏，您都会很快听到静态或其他音频伪影，而且通常非常糟糕。
ADPCM 的重置机制不是基于帧的，这意味着音频问题可能会持续很长时间，具体取决于编码器。重置代码通常是一组 0（我想到了 16，但自从我编写自己的端口以来已经有好几年了）。
电话环境中的 ADPCM 通常将 12 位 PCM 样本转换为 4 位 ADPCM 样本（还不错）。至于音频质量......对于电话交谈和口语来说还不错，但大多数人在盲测中可以很容易地检测到质量下降。
在你的最后一句话中，你把一个曲线球扔进了这个问题。你开始提到 muLaw。muLaw 是一个 PCM 实现，它采用 12 位样本并使用对数标度将其转换为 8 位样本。这是北美 TDM（电话）网络的典型压缩机制（世界其他大部分地区使用称为 ALaw 的类似算法）。
所以，我很困惑你实际上想要找到什么。
您还提到了 Microsft 和 WAV 实现。您可能知道，但以防万一，WAV 只是提供格式、采样信息、通道、大小和其他有用信息的音频数据的包装器。在不涉及 WAV、AU 或其他包装器的情况下，muLaw 和 ADPCM 通常以原始数据的形式呈现。
如果您正在实施 ADPCM，还有另一个提示。正如我所指出的，它们使用 4 位来表示 12 位样本。他们通过双方都有一个乘数表来解决这个问题。您在表格中的位置会根据 4 位值发生变化（换句话说，该值是步长的倍数，并用于计算新的步长）。我见过各种算法使用略有不同的表（不知道为什么，但您通常会看到发送和接收的信号慢慢偏离偏差）。一种较旧的流行声音包与我通常从电话硬件供应商那里看到的不同。
而且，对于更多无用的琐事，ADPCM 有多种口味。差异涉及表格、源样本大小和目标样本大小，但我从来不需要使用它们。刚刚记录了我在互联网上搜索电话中使用的各种音频格式的规范时发现的风格。
将您的 pcm 通过管道ffmpeg -f u16le -i - -f wav -acodec adpcm_ms -可能会起作用。