ZyXEL USB Omni56K Duoモデムを使用していて、音声ストリームを送受信したいのですが、適切な品質に到達するには、プレーンPCMのサンプリングレートが小さすぎて中品質の音声を送信できないため、「ZyXELADPCM」エンコーディングを実装する必要があります。また、USBでも機能しません（おそらく、このビットレートでさえUSB-Serialコンバーターには高すぎるためです）。
この不思議なコーデックは、Microsoft WAV関連のすべてのライブラリで、理論的にサポートされている多くのコーデックの1つと見なされていますが、実装は見つかりませんでした。
誰かが任意の言語または多分いくつかのドキュメントで実装を提供できますか？カスタムのmu-lawデコードアルゴリズムを作成することは、私にとって問題にはなりません。
ありがとう。
ZyXEL ADPCMが他の種類のADPCMとどのように異なるかはわかりませんが、いくつかのGoogle検索でさまざまなADPCM実装を見つけることができます。
しかし、私の投稿の本当の理由は、ADPCMを選択した理由です。ADPCMは、適応差分パルス符号変調です。これは、渡されるデータが現在の値ではなく、サンプルの差であることを意味します（これが、このような大きな圧縮が見られる理由でもあります）。ビット損失のないクリーンな環境（つまり、ディスクドライブ）では、これで問題ありません。ただし、ストリーミング環境では、ビットが定期的にマングルされる可能性があると一般的に想定されています。データに少しの損傷があると、静的またはその他のオーディオアーティファクトが非常に速く、通常はかなりひどく聞こえます。
ADPCMのリセットメカニズムはフレームベースではありません。つまり、エンコーダーによっては、オーディオの問題が長期間続く可能性があります。リセットコードは通常0のセットです（16が思い浮かびますが、私が自分のポートを作成してから何年も経っています）。
テレフォニー環境のADPCMは通常、12ビットのPCMサンプルを4ビットのADPCMサンプルに変換します（悪くはありません）。音質に関しては...電話での会話や話し言葉には悪くありませんが、ほとんどの人はブラインドテストで品質の低下を簡単に検出できます。
最後の文で、質問にカーブボールを投げます。あなたはmuLawについて言及し始めます。muLawは、12ビットのサンプルを取得し、対数スケールを使用して8ビットのサンプルに変換するPCM実装です。これは、北米でのTDM（電話）ネットワークの典型的な圧縮メカニズムです（世界の他の地域のほとんどは、ALawと呼ばれる同様のアルゴリズムを使用しています）。
だから、私はあなたが実際に見つけようとしているものを混乱させています。
また、MicrosftとWAVの実装についても言及しました。ご存知かもしれませんが、念のため、WAVは、フォーマット、サンプリング情報、チャンネル、サイズ、その他の有用な情報を提供するオーディオデータの単なるラッパーです。WAV、AU、またはその他のラッパーが含まれていない場合、muLawとADPCMは通常生データとして表示されます。
ADPCMを実装している場合のもう1つのヒント。私が示したように、それらは12ビットのサンプルを表すために4ビットを使用します。彼らは乗数テーブルを持っている両側でこれを回避します。テーブル内の位置は、4ビット値に基づいて変化します（つまり、値はステップサイズに対して倍数であり、新しいステップサイズを計算するために使用されます）。さまざまなアルゴリズムがわずかに異なるテーブルを使用しているのを見てきました（理由はわかりませんが、通常、送受信された信号がバイアスからゆっくりと外れているのがわかります）。古い人気のあるサウンドパッケージの1つは、テレフォニーハードウェアベンダーから通常見たものとは異なりました。
そして、もっと役に立たない雑学のために、ADPCMの複数のフレーバーがあります。差異には、テーブル、ソースサンプルサイズ、および宛先サンプルサイズが含まれますが、これらを操作する必要はありませんでした。テレフォニーで使用されるさまざまなオーディオ形式の仕様をインターネットで検索したときに見つけたフレーバーを文書化したところです。
あなたのpcmを配管するffmpeg -f u16le -i - -f wav -acodec adpcm_ms -ことはおそらくうまくいくでしょう。