0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

MP3 を文字起こしに投げる前に ffprobe で確認している 4 つの値

0
Posted at

MP3 を文字起こしに投げる前に ffprobe で確認している 4 つの値

長時間の MP3 をまとめて文字起こしに投げると、数本だけ妙に精度が落ちることがあります。原因をモデル側に求めがちですが、実際には投げる前のファイル側で決まっていることが多い。

この記事はツール比較ではありません。文字起こしの前に MP3 がどういう音声なのかを確認する手順 と、値を見たあとに何を判断するかの整理です。

なお、ここで書くのは前段の切り分けまでです。文字にする手段として MP3文字起こし(Audio Converter AI)のようなオンラインツールを使う場合もあれば手元のモデルを使う場合もありますが、どちらでも前段の確認が不要になるわけではありません。

無料のMP3文字起こしツール

なぜ変換ではなく確認から始めるのか

前処理の定番は「16 kHz モノラルに変換する」ですが、元ファイルの状態を見ずに変換すると、すでに十分な音声を再エンコードで劣化させたり、片チャンネルが無音なのに気づかなかったりします。

変換は「対処」で、確認は「切り分け」です。順番を間違えると、原因が分からないまま再エンコードを繰り返すことになります。

無料のMP3文字起こしツール

確認している 4 つの値

ffprobe で次の 4 つを見ます。すべて単一ファイルに対する読み取り専用のコマンドなので、元ファイルは一切変化しません。

qiita.rb
ffprobe -v error \
  -show_entries stream=codec_name,sample_rate,channels,bit_rate \
  -of default=noprint_wrappers=1 \
  input.mp3

1. codec_name

MP3 であること自体の確認です。拡張子が .mp3 でも中身が AAC のファイルは珍しくありません。ここが mp3 でないなら、以降の想定が全部崩れます。

2. sample_rate

サンプリングレートです。8 kHz のファイルは、そもそも可聴域の情報を大きく落としています。この場合、認識モデルを変えても改善しません。録音設定を見直す側の問題です。

3. channels

いちばん見落とされがちな値です。ステレオ(2)であっても片方が無音というケースがあります。テーブル中央のレコーダーで片側のマイクが死んでいる、といった状況です。

左右の実効音量を比較します。

qiita.rb
ffmpeg -i input.mp3 -filter_complex \
  "[0:a]pan=mono|c0=c0[left];[0:a]pan=mono|c0=c1[right]" \
  -map "[left]" -f null - 2>&1 | tail -1

ffmpeg -i input.mp3 -af "volumedetect" -f null - 2>&1 | grep -E "mean_volume|max_volume"

片チャンネルの mean_volume が極端に低い場合は、モノラル化の前に「どちらを使うか」を決める必要があります。機械的に -ac 1 すると、無音側と有音側が混ざって音量が半分になります。

4. bit_rate

ビットレートは音質の代理指標であって、音質そのものではありません。同じ 128 kbps でも、元の録音環境が悪ければ認識結果は悪い。「ビットレートが高いから大丈夫」は成立しません。

音量そのものは別に見ます。

qiita.rb
ffmpeg -i input.mp3 -af "volumedetect" -f null - 2>&1 | grep -E "mean_volume|max_volume"

max_volume が 0.0 dB に近い場合はクリッピングの可能性があります。これは「音が割れているかもしれない」という警告であって、割れていることの証明ではありません。

やってはいけないこと

長いファイルを分割すれば精度が上がる、という話を聞きますが、分割自体が精度を上げるわけではありません。効果があるのは、無音区間で区切って話者の切り替わりをまたがないようにする場合です。境界をまたぐ発話が切れると、かえって文が壊れます。

また、ノイズ除去フィルタを無条件にかけるのも避けたいところです。声の高周波成分まで削ると、認識に必要な情報を自分で捨てることになります。

まとめて投げる前に

複数ファイルを扱うなら、確認もまとめて回したほうが速いです。

qiita.rb
for f in *.mp3; do
  echo "== $f"
  ffprobe -v error \
    -show_entries stream=codec_name,sample_rate,channels,bit_rate \
    -of default=noprint_wrappers=1 "$f"
done

値が揃っているファイルだけを一括処理し、外れ値は個別に扱う。この一手間で「なぜか数本だけ悪い」はかなり減らせます。

私は確認が済んだファイルを MP3文字起こし(Audio Converter AI)にまとめて投げています。登録なしで一括処理でき、結果に自動要約が付くためです。

ただし、要約は読み返すための索引であって、元の発言そのものではありません。引用するときは必ず全文を、数字や固有名詞は音声を確認する。前処理をどれだけ整えても、この最終確認は省略できません。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?