speex解码出错

Question

我使用speex对一些音频数据进行编码，然后通过UDP发送，然后在另一端进行解码。我用speex运行了几个测试，注意到如果我在编码后直接解码数据包，解码的数据与原始数据一点也不接近。缓冲区起始处的大多数字节都是0。因此，当我解码通过UDP发送的音频时，我得到的只是噪声。这是我对音频进行编码的方式：

bool AudioEncoder::encode( float *raw, char *encoded_bits )
{
    for ( size_t i = 0; i < 256; i++ )
        this->_rfdata[i] = raw[i];
    speex_bits_reset(&this->_bits);
    speex_encode(this->_state, this->_rfdata, &this->_bits);
    int bytesWritten = speex_bits_write(&this->_bits, encoded_bits, 512);
    if (bytesWritten)
        return true;
    return false;
}

这就是我解码音频的方式：

float *f = new float[256];
// recvbuf is the buffer I pass to my recv function on the socket
speex_bits_read_from(&this->_bits, recvbuf, 512);
speex_decode(this->state, &this->_bits, f);

我已经查看了文档，我的大部分代码都来自于speex网站上的示例编码/解码示例。我不确定我错过了什么。

Answer 1

我找到了编码数据如此不同的原因。正如Paulo所说，这是一个有损压缩的事实，而且speex只能处理160帧，所以当从portaudio获取数据到speex时，它需要160帧的“包”。

Answer 2

我在反向工程中发现，speaks实际上为音频数据引入了额外的延迟：

narrow band : delay = 200 - framesize + lookahead = 200 - 160 +  40 =  80 samples 

wide band   : delay = 400 - framesize + lookahead = 400 - 320 + 143 = 223 samples

uwide band  : delay = 800 - framesize + lookahead = 800 - 640 + 349 = 509 samples

由于lookahead是用零初始化的，因此您可以观察到前几个样本“接近零”。

为了获得正确的时序，您必须在获得馈送到编解码器的实际音频数据之前跳过这些样本。为什么会这样，我不知道。Probalby speex的作者从来没有关心过这一点，因为speex是用于流式传输的，而不是主要用于存储和恢复音频数据。另一个解决方法(不浪费空间)是，在输入实际音频数据之前，将(Frame Speex Delay)0输入编解码器，然后丢弃整个第一个speex帧。

我希望这能澄清一切。如果某个熟悉Speex的人读到了这篇文章，如果我错了，请随时纠正我。

编辑:实际上，解码器和编码器都有一个先行时间。延迟的实际公式为：

narrow band : delay = decoder_lh + encoder_lh =  40 +  40 =  80 samples 

wide band   : delay = decoder_lh + encoder_lh =  80 + 143 = 223 samples

uwide band  : delay = decoder_lh + encoder_lh = 160 + 349 = 509 samples

Answer 3

您可能希望在这里查看一些简单的编码/解码：http://www.speex.org/docs/manual/speex-manual/node13.html#SECTION001310000000000000000

由于您使用的是UDP，因此您还可以使用抖动缓冲区对数据包和内容进行重新排序。