decodeAudioData（WebAudio API）の '有効なmp3チャンク'を定義します。

Question

私はdecodeAudioDataを使用して、より大きいmp3ファイルの最初の部分を、javascriptでデコードして再生しようとしています。私の最初の、粗い、アプローチは、mp3の始めから数バイトをスライスし、decodeAudioDataにそれらを与えることでした。驚くことではないが、これは失敗する。

掘り出した後、decodeAudioDataはFair Dinkum Thinkum、hereと記載されている「有効なmp3チャンク」でしか動作しないようです。

しかし、有効なmp3チャンクの構造についての説明はありません（上記の著者はこれに含まれません）。私はそこに存在する様々なMP3スプリッタを認識していますが、私はこれをプログラム的にアプローチしたいと思います。 （私は、サーバー側でnodejを使用して「貧乏人のストリーミング」を実装しようとしています）。

だから、mp3フレームヘッダーを分割するだけで十分ですか、それとももっと処理する必要がありますか？ （おそらく、最後にデータを追加することで、すべてのチャンクを「閉じる」のだろうか？）「バイトリザーバ」はどうですか？これは問題を引き起こすでしょうか？記録のために、私は現在128kbpsのcbr mp3で作業しています。これはどんな方法でもプロセスを簡素化しますか？

decodeAudioDataがvaildデータとして期待していることに関するすべての情報が評価されます。

ありがとうございます。

PS：これは恐らくFair Dinkum Thinkumのpostについての明確化の要求であることを認識していますが、私の評判が低いためコメントが投稿されません。だから私はそれを他の方法ではなく、新しい質問で見ることができません。再度、感謝します。

Answer 1

は（クローム上）decodeAudioDataと、より実験の後、これは私が見つけたものです：

• どれ初期 mp3チャンクが正常に限り、それはmp3のフレーム境界で分割されたとしてデコードされます。一定のビットレートのmp3には必ずしも一定のサイズのフレームが含まれているとは限らないため、その境界が必ずしも些細なものではない（例えば、mp3ヘッダを解析することを含む）場合もあります。たとえば、128kbpsのmp3ファイルには、417バイトのフレームと418バイトのフレームが含まれています。 （一部のフレームにはパディングとして余分なバイトが含まれています）。
• 任意のmp3チャンクはではありません。は、「両側」の正確なフレーム境界で分割してもデコード可能であることが保証されています。この種のチャンクの一部はデコードできますが、他のデコードではdecodeAudioDataにエラーが発生します。私はこれがmp3 bit reservoirと関係していると推測しています。これはmp3フレーム間の依存関係を作成します。

Answer 2

ファイルを有効なMP3ヘッダー（バイト境界に配置された '1'の12ビット：FF Fx）で始まる部分に分割すると、おそらく大丈夫でしょう。