压缩/解压缩音频数据
我正在 C# 应用程序中使用 win32 波形 api 来制作 voip 系统。 一切都很顺利，但是我需要某种方式来动态压缩音频数据。
因此基本上音频数据进入大小为 150 字节的“记录”缓冲区，然后通过 udp 发送该缓冲区，在远程端，接收 150 字节并将其放入“播放”缓冲区中。
所以我需要某种方法在 udp->send 之前和 udp->recv 之后压缩/解压缩数据。 普通压缩算法不适用于音频，包括 .NET GZip 类。
有谁知道我可以使用一个图书馆来帮助我做到这一点？
提前致谢...
i am using the win32 waveform api's in a C# app to make a voip system. all is going well, however i need some way of compressing the audio data on the fly.
so basically the audio data comes into a 'record' buffer of size 150 bytes, and then this buffer is sent over udp, and at the remote end, the 150 bytes are received and put into a 'play' buffer.
so i need some way of compressing/decompressing the data just before the udp->send and just after the udp->recv. normal compression algorithms dont work with audio, including the .NET GZip class.
does anyone know of a library that i can use that will help me do this ?
thanks in advance...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
150 字节对于音频数据来说是一个令人难以置信的小缓冲区——对于例如 16 KHz 单声道来说不到 5 毫秒。 我不是专家，但我认为无论您选择哪种压缩方案，您的压缩率都会因使用如此小的缓冲区而受到很大影响。 除此之外，您发送的每个数据包都会产生很大的开销。
也就是说，如果您要发送语音数据，请查看 Speex 进行有损压缩（我发现它在压缩语音方面非常有效，但对于音乐来说音质很糟糕。）
150 bytes is an unbelievably small buffer for audio data--less than 5 milliseconds for e.g. 16 KHz mono. I'm no expert but I think regardless of the compression scheme you choose, your compression ratio will suffer greatly for using such a small buffer. Besides that there is significant overhead for each packet you send.
That said, if you are sending speech data, take a look at Speex for lossy compression (I have found it very effective at compressing speech, but the sound quality is terrible for music.)
我认为您需要批量处理这些 150 字节的块以获得更好的压缩效果。
尽管如此，即使缓冲区大小如此之小，您仍然可以获得一些压缩。
如果内置的 GZipStream 不起作用，您可以尝试 DotNetZip 中包含的 GZipStream。 DotNetZip 中还有一个 ZlibCodec 类，它实现了 Codec 模式 - 这可能有助于以 150 字节块进行压缩。
I would think you'd want to batch up those 150-byte chunks to get better compression.
Although, even at small buffer sizes like that, you can still get some compression.
If the built-in GZipStream isn't working you could try the GZipStream that is included in DotNetZip. There is also a ZlibCodec class available in DotNetZip that implements the Codec pattern - this may facilitate compressing in 150-byte blocks.
您正在寻找的组件更广为人知的是编码器/解码器，或编解码器 ，并且在选择时有很多选择。
The component you're looking for is more well-known as a coder/decoder, or codec, and there are many options when it comes to picking one.
正如上面所建议的，我会研究 Speex。 它得到了很好的支持，现在已成为 Flash Player 的事实上的标准。
我认为根据您设置的缓冲区大小，延迟是一个问题（缓冲区越大，延迟越大），因此不要选择具有高解压缩帧大小的编解码器，因为它会引入高延迟。 这或多或少排除了 MP3...对于 5khz 输出采样率的语音（更高的采样率没有多大作用），最小解压缩帧大小为 576 个样本，或者在发送之前必须编码的约 100ms 数据。 这意味着在您考虑问题的网络部分之前，双向延迟就超过 200 毫秒。
As suggested above, I'd look into Speex. It's well supported, and now the defacto standard for Flash Player.
I assume that by the size you are setting your buffers that latency is an issue (the bigger the buffer, the bigger the latency), so don't go for a codec that has a high decompressed frame size, because it introduces high latency. This more or less rules out MP3... for voice at 5khz output sample rate (it wouldn't serve much purpose going higher), the minimum decompressed frame size is 576 samples, or ~100ms of data that must be encoded prior to send. This means a bothway latency of over 200ms before you've even considered the network part of the problem.