問題タブ [lamemp3]

このアプリケーションでは、ffmpeg を使用してオーディオ ファイルを処理しています。具体的には、NodeJS ライブラリfluent-ffmpeg( npm リンク) を使用します。

当社の音声ファイルは、さまざまなテキスト読み上げプロバイダーから生成されます。最近、ssml を使用してオーディオを変換し、生成されたオーディオに一時停止を追加したときに、ファイルの長さが正しくないことに気付きました。さらに調査したところ、標準のオーディオも正しくないことがわかりました。データがより一貫しているため、全体的により正確でした。オーディオの最初に一時停止を入れると、推定値が最悪になり、非常に大きな差でオーバーシュートしました (たとえば、25 秒のオーディオ クリップは 3 分と読み取れますが、25 秒のマークを超えて再生すると最後までスキップされます)。 .

MP3 ファイルの構造について検索と調査を行ったところ、さまざまなオーディオ プレーヤーによって継続時間が推定されることが問題のように思えます。Windows Media Player がその例ですが、Firefox の Web Player もこれを行うようです。ffmpegコマンドを.audioQuality(0)、ffmpegにVBRを使用するように設定する using から、.audioBitrate(320)ffmpegに一定のビットレートを使用するように指示する に変更してみました。参考までに、libmp3lame を使用しており、VBR と CBR のそれぞれの場合に実行される完全なコマンドは次のとおりです。

VBR (壊れた持続時間) の場合: ffmpeg -i <URL> -acodec libmp3lame -aq 0 -f mp3 pipe:1 CBR (正しい持続時間) の場合:ffmpeg -i <URL> -acodec libmp3lame -b:a 320k -f mp3 pipe:1

注: 次に、適切なファイル ヘッダーを送信した後、要求元のクライアント アプリケーションに出力をパイプします。つまり、pipe:1 出力です。入力は、ソース ファイルが配置されているクラウド ストレージの URL です。

これにより、正しいデュレーションを持つという私たちの問題が修正されます。問題が、これらのプレーヤー/オーディオ消費者の一部によってデュレーションが推定されているためである場合、これが修正される理由は理にかなっています。しかし、これにはファイルサイズが大幅に大きくなるという犠牲が伴いました。これも私には理にかなっています. テスト中に、WAV の同じファイルと比較して、VBR mp3 は WAV ファイル サイズの約 10% であるのに対し、CBR mp3 は WAV ファイル サイズの 50% であることがわかりました。これは、私たちのユースケースで mp3 形式をサポートする目的を実質的に無効にします。mp3 形式は、サイズは小さいですが、大きな WAV ファイルに代わる、わずかに損失が大きくなります。

調査中に、mp3 ファイルの先頭のチャンクに ID3 タグが存在する可能性があることがわかりました。これは、オーディオの消費者がファイル全体を処理する前に継続時間を知るための情報を指定します。しかし、少なくとも期間については、標準がないように思われることもわかりました. 曲のタイトル、アルバム、アーティストなどのその他のもの。

私の質問は、VBR を使用しながら、できれば何らかの ffmpeg メカニズムを介して、mp3 ファイルに適切な期間を取得する方法はありますか? ありがとう！