压缩/解压缩音频数据答案

【问题标题】：Compressing/decompressing audio data压缩/解压缩音频数据
【发布时间】：2009-03-06 15:36:03
【问题描述】：

我在 C# 应用程序中使用 win32 波形 api 来制作 voip 系统。一切都很顺利，但是我需要一些即时压缩音频数据的方法。

所以基本上音频数据进入大小为 150 字节的“记录”缓冲区，然后通过 udp 发送此缓冲区，在远程端，接收 150 个字节并将其放入“播放”缓冲区。

所以我需要某种方式在 udp->send 之前和 udp->recv 之后压缩/解压缩数据。普通压缩算法不适用于音频，包括 .NET GZip 类。

有谁知道我可以使用的库可以帮助我做到这一点吗？

提前谢谢...

【问题讨论】：

标签： c# compression waveform

【解决方案1】：

150 字节对于音频数据来说是一个令人难以置信的小缓冲区——例如，不到 5 毫秒。 16 KHz 单声道。我不是专家，但我认为无论您选择哪种压缩方案，使用如此小的缓冲区，您的压缩率都会受到很大影响。除此之外，您发送的每个数据包都会产生大量开销。

也就是说，如果您要发送语音数据，请查看Speex 进行有损压缩（我发现它在压缩语音方面非常有效，但音质对于音乐来说很糟糕。）

【讨论】：

在 16khz 时，您建议的缓冲区大小是多少？它设置为 150，因为这就是 skype 所做的（用 udp 嗅探器观察），虽然我会想象 skype 的缓冲区大于 150，但压缩后最终为 150。
我建议在压缩前至少 20-30 毫秒或在压缩前最多 1 KB（如果您的压缩非常好，您可以在压缩后达到 150 字节，但我不是专家)。更大的块直接导致更高的延迟，但 20 毫秒的额外延迟并不是什么大问题。
总之，这是压缩和块大小（=延迟）之间的权衡。您可以有良好的压缩或小块，但很难同时获得两者。

【解决方案2】：

我认为您希望将这些 150 字节的块进行批量处理以获得更好的压缩效果。
虽然，即使在这样小的缓冲区大小下，您仍然可以获得一些压缩。

如果内置 GZipStream 不起作用，您可以尝试 DotNetZip 中包含的 GZipStream。 DotNetZip 中还有一个 ZlibCodec 类可用，它实现了 Codec 模式——这可能有助于压缩 150 字节块。

【讨论】：

【解决方案3】：

您正在寻找的组件更广为人知的是编码器/解码器或codec，在选择其中一个时有很多选择。

【讨论】：

你愿意冒险吗？

【解决方案4】：

如上所述，我会研究 Speex。它得到了很好的支持，现在是 Flash Player 的事实标准。

我假设根据您设置缓冲区的大小，延迟是一个问题（缓冲区越大，延迟越大），所以不要选择具有高解压缩帧大小的编解码器，因为它会引入高延迟。这或多或少地排除了 MP3 ......对于 5khz 输出采样率的语音（它不会起到更高的作用），最小解压缩帧大小为 576 个样本，或大约 100 毫秒必须在发送之前编码的数据.这意味着在您考虑问题的网络部分之前，双向延迟超过 200 毫秒。

【讨论】：