ライブ オーディオ (ラジオ) ストリーム (MP3 や AAC など) の受信を開始すると、受信したデータは生のビットストリーム (生のエンコーダ出力) ではなく、常に何らかのコンテナー形式にラップされていると思います。この仮定が正しければ、ストリームの任意の場所からストリーミングを開始することはできないと思いますが、同期バイトまで待たなければなりません。そうですか？いくつかの同期バイトがあるのは普通ですか? 使用されているコーデック、チャンネル数、サンプルレートなどを推測できる同期バイトの後にヘッダーはありますか?
ライブ ストリームに接続すると、最も近い同期バイトからデータを受信しますか、それとも実際の位置から取得し、最初に同期バイトを確認する必要がありますか?
icecast のような一部のストリームは、ストリーム関連の情報が含まれる HTTP 応答でヘッダーを使用しますが、それらをスキップして直接 steam 形式を処理できると思います。
あれは正しいですか？
よろしく、
STeN
Doom9 には、mpeg と aac の両方のフレーム形式に関する優れた開始情報があります。Shoutcast は時々「メタデータ」を追加しますが、それは本当に些細なことです。あなたと共有したいのはこれです。私はあらゆる種類のストリームをキャプチャできるアプリケーションを持っており、aac と mp3 の両方がその中に含まれています。最初のバージョンでは、mp3/aac フレームに関係なく、たとえば 5 分ごとなど、時間に応じて任意の時点でファイルがカットされていました。mp3 (ファイルは再生可能) では何とか問題ありませんでしたが、aacplus では非常に悪かったです。
事は - aacplus デコーダーは間違ったデータを許すわけではなく、アクセス違反から謎のソフトウェアのシャットダウンまで、あらゆる種類のエラーなしですべてを経験しました。
とにかく、ストリームをキャプチャしたい場合は、サーバーへのソケットを開き、応答を読み取ります。そこにヘッダーがあり、その情報を使用して、時々挿入されるメタデータを削除します。aacplus と mp3 の両方のヘッダー情報を使用してフレーム境界を決定し、それらを尊重して適切な場所でファイルを分割します。
mp3 フレーム ヘッダー:
aacplus フレーム ヘッダー:
これも：
SHOUTcast/Icecast を見ると、出くわすデータは純粋な MPEG Layer III オーディオ データであり、それ以上のものではありません。(メタデータを要求していない場合)。
任意の場所でカットできるので、ストリームに同期する必要があります。これは通常、潜在的なヘッダーを見つけ、そのヘッダー内のデータを使用して順次ヘッダーを見つけることによって行われます。いくつかのフレーム ヘッダーが見つかったら、ストリームに同期したと見なして、再生用のデコードを開始できます。
繰り返しますが、これらには「コンテナ形式」はありません。それは単なる生データです。
メタデータが必要な場合は、サーバーからリクエストする必要があります。xその後、データはバイト数ごとにストリームに注入されます。http://www.smackfu.com/stuff/programming/shoutcast.htmlを参照してください。
私は自分自身に答えて議論を続けます（私たちはそれをすることを思いとどまりますが）：
また、ストリーミングされたデータを調べていたところ、シーケンスff f3 82 70が頻繁に繰り返されることがわかりました。これは、MPEG フレーム ヘッダーであると思われるので、それが何を意味するのかを調べてみました。
ff f3 82 70 (hex) = 11111111 11110011 10000010 01110000 (bin)
Analysis
11111111111 | SYNC
10 | MPEG version 2
01 | Layer III
1 | No CRC
1000 | 64 kbps
00 | 22050Hz
1 | Padding
0 | Private
01 | Joint stereo
11 | ...
それに対するコメントはありますか？
ストリーミング データの受信を開始するとき、DSP を処理するクラスにバッファを渡す前に、このヘッダーの前のすべてのデータを破棄する必要がありますか? これは実装固有のものである可能性があることは知っていますが、ここでの一般的な手続きについて知りたいです...
BR STEN