シャウトキャストサーバーとクライアントは、どのようにmp3フレームヘッダーとフレームの依存関係を処理しますか？

Question

短編小説：

私自身は自分のアプリケーションで処理Shoutcastは互換性のあるオーディオストリームを受信して​​から送信する場合は、その後、どのようにそれが適切にmp3を使用して行うには（デ/ EN）ライブラリをコーダ？擬似コード、またはより良いlame mp3固有のコードは高く評価されるでしょう。

長い物語：

言う article about mp3によって引き起こされた私を気に

より具体的な質問、：

を一般的に、フレームは、独立した項目です。各フレームには独自のヘッダー と音声情報があります。ファイルヘッダーはありません。したがって、 はMPEGファイルの一部を切り取り、正しく再生することができます（フレーム境界で を実行する必要がありますが、ほとんどのアプリケーションは正しくない ヘッダーを処理します）。レイヤーIIIの場合、これは100％正確ではありません。 MPEGバージョン1のレイヤIIIファイルの内部の データ編成のため、フレームは多くの場合、 に依存しており、そのようにカットすることはできません。

これは、Shoutcastサーバーとクライアントがフレームヘッダーとフレームの依存関係をどのように処理するのかと思いました。

Shoutcastプレーヤーのほとんどと最大の互換性を実現するには、固定ビットレート（CBR）のみにエンコードする必要がありますか？

mp3フレームヘッダーがまったく使用されているか、Shoutcastプロトコル固有のHTTPヘッダーからストリーム形式が推測されていますか？

Shoutcastプロトコルは、フレーム境界でmp3ストリームの配信を開始し、フレーム境界で切り取られたチャンクで応答を続けますか？しかし、ライブオーディオをストリーミングするためのmp3フレームの最小または推奨サイズはどれくらいですか？

Shoutcastはフレーム依存関係をどのように扱うのですか？サーブされたストリームに前のフレームに依存するフレームがないことを保証するためにmp3エンコーディングでは何か特別な処理を行いますか？あるいは、サーバー側/クライアント側のこれらの依存関係を無視して、オーディオの品質を低下させたり、アーティファクトを取得したりすることはできますか？

Answer 1

SHOUTcastサーバーは、通過するデータを認識しないか、気にしません。彼らはそれをそのまま送る。実際には、SHOUTcastサーバーから任意のデータを送信して受信することができます。 SHOUTcastは、バッファサイズが低下しているところでメディアデータを分割します。

データに再同期するのはクライアントの責任です。これは、フレームヘッダーの位置を特定し、デコードします。オーディオを確実に再生するのに十分なフレームがコーデックに入ると、生のPCMの出力が開始されます。再生を開始するのが安全かどうかは、コーデックによって異なります。コーデックはメディアのデコードに関して何をしているのかを知っているので、アーティファクトなしで開始するのに十分なデータ（ビットリザーバを含む）がいつあるのかを知っています。ビットリザーバはあまりにも遠くまで持ち運ぶことができないので、それを処理するには最悪の場合は数フレームしかかかりません。

これは、接続時にできるだけ早くクライアントにフラッシュするために、サーバー側にかなりのバッファを持つことが重要な理由の1つです。再生をすばやく開始する場合、コーデックは現在のフレームより多くのデータを必要とします。