2009-05-17 7 views
5

私はターゲット設定された広告を放送できるストリーミングサーバーに取り組んでいます。基本的にリスナーは同じ音楽を聴いていますが、30分ごとに1ブロックの広告があり、すべてのリスナーは自分のブロックを持っています。このようなストリーミングサーバの実装にはさまざまな問題があり、この問題の1つは問題です。MP3ストリームをシームレスに連結するにはどうすればよいですか?

サーバ、すなわち、それは、いくつかのストリーム生成装置からネットワークを介してストリームを読み取り、すべてのリスナーにそれを中継する、Icecastのと同様に動作します。広告をブロードキャストする時に、サーバーはジェネレータからのストリームの取得を停止し、ファイルから広告を読み込み、それを各リスナーのバッファに挿入して送信し、ジェネレータからの中継ストリームで再開します。

すると、サーバスイッチの広告を放送するストリームを中継するから、それは(私たちはMP3で放送)2つのMP3ストリームを連結しています。私の関心事は、あるデータを別のデータに追加するだけで、可聴アーチファクトが発生する可能性があるということです。シームレスに行うことはできますか?

私はすでにこれを考え出した: - 私は、同期エラーを回避するために、サーバーはMP3フレームを認識することができます。 - 私は、ストリームからMP3フレームの後に広告ファイルからMP3フレームを追加することを考えています。 - 広告は正しくエンコードされたMP3ファイルからロードされるため、ファイルの最初のフレームでは使用できないため、バイトリザーバの問題を回避します。

しかし、私の心配はMDCTの仕組みです。リスナーは自分のサーバーが何をするのか分からないので、ダウンロードしたストリームに間違ったMDCTデータが次々に配置されるため、MP3デコーダでアーティファクトが生成される可能性があります。これを補償してファイルの先頭にゼロ埋めをしますか?

あなたはシームレスにそれらを解凍せずに2つのMP3ファイルを結合することができます任意のライブラリ/ツール(オープンソース可能な場合)を知っていますか?

MP3フォーマットの説明に役立つリソースを教えてください。私はインターネットをたくさん検索し、多くの情報を見つけましたが、私はまだ全体像を見逃しています。

たぶん、あなたは私がOGG/Vorbisの、AACのような別のコーデックを使用した場合、これは容易になるだろうことを知っていますか?

PS。この質問はWhat is the best way to merge mp3 files?の重複ではありません。 MP3ラップとツールは私にとってはオプションではありません。

答えて

0

は、Windowsを使っている場合は、マイクロソフトDirectShow APIを移動するための方法かもしれません。あなたは、オーディオとビデオの両方を静的にもストリーミングでも、さまざまな形式で処理できることがわかります(必要なコーデックのみが必要で、インターフェイスはほぼすべて同じです)。

このように、DirectShowは残念ながら複雑な方法で設計されており、学習曲線は急峻ですが、Windowsでオーディオ/ビデオ操作を行う場合は、並外れたパワーがあります。しかし、それを使用する方法に関するサンプルとチュートリアルが多数ありますので、最後にはあまり苦労しないかもしれません。また、.NET Frameworkを使用している場合は、DirectShow.NETの名前で管理されています。私が気づいていないもの以外に何かがない限り、あなたがしていることは何でも簡単な仕事にはならないでしょう。とにかくそれと幸運!

+0

このようなAPIはあまりにも計算コストがかかる可能性があります。私が働いているラジオ局はすでに5kユーザー/サーバーのピークトラフィックを持っています。各リスナーのために処理しなければならないのはわずか1秒の音楽であっても、それは時間のかかる圧縮解除/圧縮の1時間以上の音楽です... – Jasiu

+0

本当にそうするべきかどうかわかりませんDirectShowはWindows上のメディアのための*方法です。 – Noldorin

2

ファイルを連結するだけでMP3をマージすることができます。一部のクイックテスト(cat file1.mp3 file2.mp3 > merged.mp3; mplayer merged.mp3)では、期待どおりに動作するようです。 Webサーバーからのストリーミングはおそらく同様に機能します。

どのように現在の入力ファイルの切り替えを処理しますか?広告を短いトラックとして扱うだけで、再生することができます。

+0

はい、それは私が行きたいと思う方法ですが、それは動作していて、可聴グリッチが生成される状況はありませんか? – Jasiu

+1

これはうまくいかないでしょう...複数のmp3フォーマットがあります...一定のフレームサイズ(1サンプルあたりのビット数が多い)または変動する可変ビットレートのmp3で一定のビットレートmp3を設定できます。 ..彼らは互換性がありません。単純に連結すると、ヘッダーとid3タグをファイルの中央に置くので、メディアファイルにはファイルを再生する際の問題があります。 これを実行するソフトウェアを使用するか、両方の監査ファイルを単一の形式に変換して、オーディオストリームを連結して新しいファイルに保存する必要があります。 – uzbones

+0

私はID3タグを持っていないと私は定数ビットレートを使用してみましょう。 – Jasiu

0

私はそれが有効なフレームのヘッダに当たるまでどれ値するデコーダが「悪い」データをスキップします...

を非常に同様の問題にアプローチして、さまざまなソースで適切な質問をした後、次のを思い付きました。これは、ID3v2がmp3データに追加情報を注入するために頼るものです。サーバーでは、有効なMP3フレームのみを提供するために、ソースMP3ファイルの分析に行きます。いくつかのサイレントフレームを提供する場合(約7つ必要)、デコーダは、(エンコードされていない)MP3データの次の読み込みまでに時間を費やし、異なるエンコーディングからのフレームを連結する場合のアーチファクトを回避する必要がありますセッション。

さらに問題は、1つのフレームと次のフレームの間でMP3属性(1/2チャンネル、出力サンプルレートなど)を切り替えることです。このようなストリームに直面すると、一部のデコーダがかなり動揺し、1/2スピード再生などが発生します。したがって、すべてのソースマテリアルが同じ出力属性にエンコードされていることを確認する必要があります。そうしないと、元に戻すことができません。

あなたはすでにこれを見ているかもしれないが、そうでない場合:

http://www.devhood.com/tutorials/tutorial_details.aspx?tutorial_id=79&printer=t

0

あなたがファイルを連結する理由私は表示されません。あなたは何らかの種類のプレイリストシステムを使用して、送信するファイルを変更するだけです。私はこれが長い目で見ればより柔軟になり、大きなMP3ファイルで終わることはないと思います。

+0

私はあなたが言っていることを理解しているのかどうかは分かりませんが、あなたのアイデアがどのようにターゲット広告を可能にしているのかわかりません。私のラジオはSHOUTcast/Icyプロトコルを使用しています。さまざまなプレイヤーがいるので、クライアント側では何もできません。私はこの問題のために重要ではないので、ファイルについて話していますが、実際には、その場で生成されたMP3ストリームを使用します。 – Jasiu

+0

それはすべてサーバー側になります...基本的に、サーバーは曲と広告の間で交替する以外は、広告を曲として扱います。私はあなたがストリームにそれらを置くとき一緒にすべての曲を連結していないと仮定しています... – uzbones

2

CBR形式とVBR形式のmp3ファイルを連結することができます。 MP3ファイルにはメインヘッダがありません(ID3とXingは無視)。オーディオデータは、すべてのチャンクがそれ自身のヘッダを含むチャンクとして格納される。ヘッダには、そのチャンク内のオーディオデータのデコードに必要な情報(ビットレート、サンプル周波数、ステレオなど)が含まれています。

これは、mp3ファイルの再生時間を判断するのが難しい理由の1つです。

CBR MP3ファイルとVBRファイルを連結すると、最終結果はオーディオの最初のセクションが固定ビットレートである1つの長いVBRファイルと同じになります。

一部のMP3プレイヤーは厳格で、VBR MP3ファイルのXingヘッダーが必要な場合があります。これは決してMP3形式の仕様ではありませんでしたが、今は真とされています。

関連する問題