私はwin32の波形apiをC＃アプリケーションで使用しています。すべてが順調に進んでいますが、私はその場でオーディオデータを圧縮する方法が必要です。オーディオデータの圧縮/伸長
したがって、基本的にオーディオデータは150バイトの 'レコード'バッファに入り、このバッファはudpで送信され、リモートエンドでは150バイトが受信されて '再生'バッファに格納されます。
私はudp-> sendの直前とudp-> recvの直前にデータを圧縮/解凍する何らかの方法が必要です。通常の圧縮アルゴリズムは、.NET GZipクラスを含むオーディオでは機能しません。
私はこれを行うのに役立つライブラリを誰もが知っていますか？事前に
おかげで...
あなたが探しているコンポーネントは、より多くのコーダ/デコーダ、またはcodecとしてよく知られており、それが1つを選ぶことになると多くのオプションがあります。
150バイトは、オーディオデータ用の信じられないほど小さなバッファです。たとえば、5ミリ秒未満です。モノラル16KHz。私はエキスパートではありませんが、あなたが選択した圧縮方式に関係なく、圧縮率はこのような小さなバッファを使用すると大きく損なわれると思います。それ以外にも、送信するパケットごとに大きなオーバーヘッドがあります。私が思うだろう
（16khz）で、どのバッファサイズをお勧めしますか？ 150に設定されていますが、Skypeのバッファは150より大きいですが、圧縮後は150になりますが、skypeが何をするか（udpスニファで見たもの）です。 –
+1 spex。これは、フラッシュが現在使用しているものです。 – spender
圧縮前に少なくとも20〜30ミリ秒、圧縮前に1 KBまでを推奨します（圧縮が素晴らしいなら、圧縮後に150バイトになるかもしれませんが、私は専門家ではありません）。ブロックが大きくなるとレイテンシは高くなりますが、レイテンシが20ms長くなることは大きな問題にはなりません。 – Qwertie
（私はスピーチを圧縮する時、それは非常に有効であることが分かっていますが、音質は音楽のためにひどいです。）あなたは、音声データを送信する場合、非可逆圧縮のためSpeexを見て、言った
より良い圧縮を得るために150バイトのチャンクをバッチアップする必要があります。
このような小さなバッファサイズでも、の一部をに圧縮することはできます。
組み込みのGZipStreamが機能しない場合は、DotNetZipに含まれるGZipStreamを試すことができます。 DotNetZipには、コーデックパターンを実装するZlibCodecクラスも用意されています。これは、150バイトのブロック単位での圧縮を容易にします。
上記のように、私はSpeexを調べます。これは十分サポートされており、現在はFlash Playerの標準規格となっています。
バッファサイズを設定すると、レイテンシが問題になります（バッファが大きいほどレイテンシが大きい）ので、高い圧縮解除フレームサイズのコーデックは使用しないでください。高い待ち時間をもたらす。これは、多かれ少なかれMP3の5khz出力サンプルレートでのボイス（それ以上の目的を果たすことはあまりありません）、最小の圧縮解除フレームサイズは576サンプル、または送信前にエンコードする必要があるデータの100msです。これは、問題のネットワーク部分を考慮する前でも、200ms以上の待機時間を意味します。
ベンチャーキャピタルに気を配りますか？ –