13

私は、decodeAudioData を使用して、より大きな mp3 ファイルの最初の部分を JavaScript でデコードして再生しようとしています。私の最初の粗雑なアプローチは、mp3 の先頭からいくつかのバイトを切り取り、decodeAudioData に供給することでした。驚くべきことではありませんが、これは失敗します。

掘り下げた後、decodeAudioData は、Fair Dinkum Thinkumによって文書化されているように、「有効な mp3 チャンク」でしか機能しないようです。

ただし、有効な mp3 チャンクの構造については明確化されていません (前述の著者はこれについて触れていません)。そこに存在するさまざまなmp3スプリッターを認識していますが、プログラムでこれに取り組みたいと思います。（サーバー側でnodejsを使用して、一種の「貧乏人のストリーミング」を実装しようとしています）。

では、mp3 フレーム ヘッダーの分割で十分でしょうか、それとももっと行う必要がありますか? (おそらく、最後にいくつかのデータを追加して、すべてのチャンクを「閉じる」?) 「バイトリザーバー」はどうですか? これは問題を引き起こしますか? 記録のために、私は現在 128kbps の cbr mp3 を使用しています。これにより、何らかの方法でプロセスが簡素化されますか?

decodeAudioData が有効なデータとして期待するものに関する情報をいただければ幸いです。

ありがとうございました。

PS: これはおそらく、Fair Dinkum Thinkum の投稿についての説明を求める要求であることは承知していますが、私の評判が低いため、コメントを投稿できません。そのため、他に方法がわかりませんが、新しい質問があります。再度、感謝します。

4

2 に答える 2

7

（Chromeで）decodeAudioDataをさらに実験した後、これが私が見つけたものです：

  • 最初のmp3チャンクは、mp3 フレーム境界で分割されている限り、正常にデコードされます。一定のビットレートの mp3 でさえ、常に一定サイズのフレームを含むとは限らないため、その境界を見つけることは常に簡単であるとは限りません (たとえば、mp3 ヘッダーの解析を含む)。たとえば、128kbps の mp3 ファイルには、417 バイトのフレームと 418 バイトのフレームが含まれています。(一部のフレームには、パディングとして余分なバイトが含まれています)。
  • 任意の mp3 チャンクは、「両側」の正確なフレーム境界で分割されたとしても、デコード可能であるとは限りません。この種のチャンクの中にはデコードできるものもありますが、decodeAudioData がエラーをスローする原因となるものもあります。これは、mp3 フレーム間の依存関係を作成するmp3 ビット リザーバーに関係していると推測しています。
于 2012-11-09T19:58:11.903 に答える
4

ファイルを有効な MP3 ヘッダー (バイト境界に位置合わせされた 12 ビットの「1」: FF Fx) で始まる複数の断片に分割すると、ほとんどの場合問題がなくなります。

于 2012-05-06T13:33:10.330 に答える