オーディオファイルのビットレートをすばやくテストする

このタグの私の経験ではそうではありません。近似する、彼ら間違った、特に古いVBRでエンコードされたMP3ファイルの場合、最大8倍の差があります。通常、MP4はあまり良くありません（ほぼ可変ビットレートを使用しますが、「MP4」では大きい家族同じ速度で品質が異なる非常に多様なオーディオコーデック！ )

これは、次の2つに関連しています。

1. 圧縮されて保存されたオーディオ（デジタルラジオ局、電話、またはオンラインビデオのオーディオトラックには送信されません）必要一定のビットレートで圧縮することは意味がありません。 「サイレント」を表現するには、マルチ楽器の曲で複雑な瞬間を表現するよりも少ないビットが必要です。したがって、オーディオ内のすべてのチャンクに対して1つのビットレートを選択し、それに従うと、平均ビットレートよりも多くのビットレートが必要な場合に多くのスペースを無駄にしたり、音が悪くなります。したがって、「合理的な」一定のビットレートを持つことは悪いようです。私たちは2000年頃に非常に高い固定ビットレートを使用していましたが、まだ音が悪くありませんでした。ただ多くのエンコーダがあまり良くなかったからです。誓いのために、2002年頃にはCDをリッピングするのに使用した様々なMP3エンコーダの音で160kbpsと知ることができました。良くありません。これらはオフロード獣です。
2. エンコーダが固定ビットレートではなく固定品質に設定されている場合、ヘッダにどのビットレートを入力しますか？最低？曲に1000分の1秒の沈黙がある場合、それは何の意味もありません。最大値？それは言葉ではありません。ただドラマーがシンバルを叩く瞬間かもしれません。平均？一部の曲は他の曲よりもエンコードするのが簡単なので少し理解できますが、曲の音量、ジャンル、テンポ、制作品質、スペースの分離が比較的一定であると仮定すると、つまりすべての音楽が同じに聞こえる場合、のような結果が得られます。ファイルサイズ（ビット単位）を曲の長さで割っても同じ結果になります。早くする必要があります！

これを除外してください。主な時間ffprobeは通常ロードと内部設定に費やされます。 @OleTangeのGNUを使って素敵に隠すことができますparallel。

# for bash, whose recursive globbing is off by default
# omit if on zsh
shopt -s globstar nullglob dotglob

# run all ffprobe in parallel.
# GNU parallel takes care of keeping output in correct order
parallel --eta \
  ffprobe \
    -loglevel fatal \
    -output_format json \
    -show_entries format=bit_rate:format=filename \
  ::: **/*.mp4 **/*.mp3 **/*.mpeg **/*.mpc **/*.wma **/*.opus **/*.ogg \
| jq  \
  '.[] | {(.filename): (.bit_rate|tonumber)} ' \
| jq --slurp \
  'reduce .[] as $i ({}; . * $i)' 
> allfiles.json

私はそれを試してみましたが、私には約400％の速度向上を意味しました。

（jq最後のチェーンは完全にオプションですが、ファイル名をビットレートにマッピングする効率的で使いやすいドキュメントを提供します）