ショートストーリー：
自分のアプリケーションで処理された Shoutcast 互換のオーディオ ストリームを受信して送信する場合、mp3 (de/en) コーダー ライブラリを使用して適切に行うにはどうすればよいですか? 疑似コード、またはそれ以上 - 不十分な mp3 固有のコードは高く評価されます。
長い話：
私を悩ませているより具体的な質問は、 mp3 に関する記事によって引き起こされました。
通常、フレームは独立したアイテムです。各フレームには、独自のヘッダーとオーディオ情報があります。ファイルヘッダーはありません。したがって、MPEG ファイルの任意の部分を切り取って正しく再生できます (これはフレーム境界で行う必要がありますが、ほとんどのアプリケーションは不適切なヘッダーを処理します)。レイヤ III の場合、これは 100% 正しいわけではありません。MPEG バージョン 1 レイヤー III ファイルの内部データ編成により、フレームは相互に依存していることが多く、そのように切り離すことはできません。
これにより、Shoutcast サーバーとクライアントがフレーム ヘッダーとフレームの依存関係をどのように処理するのか疑問に思いました。
ほとんどの Shoutcast プレーヤーとの互換性を最大限に高めたい場合、固定ビットレート (CBR) にのみエンコードする必要がありますか?
mp3 フレーム ヘッダーがまったく使用されているのか、それともストリーム形式が Shoutcast プロトコル固有の HTTP ヘッダーから推測されているのか?
Shoutcast プロトコルは、フレーム境界で mp3 ストリームの提供を開始し、フレーム境界で切断されたチャンクで応答し続けることを保証しますか (または一般的な良い慣行ですか)? しかし、ライブ オーディオをストリーミングするための mp3 フレームの最小サイズまたは推奨サイズは?
Shoutcast はフレームの依存関係をどのように処理しますか? 提供されたストリームに前のフレームに依存するフレームがないことを保証するために、mp3 エンコーディングで何か特別なことを行いますか (これが可能であれば)? それとも、サーバー側/クライアント側でこれらの依存関係を無視しているため、音質が低下したり、アーティファクトが発生したりする可能性がありますか?