AWS Elemental MediaConvertで音量正規化をやってみた！
2025.06.26はじめに
清水です。ブロードキャストグレードの機能を備えたファイルベースの動画変換サービスであるAWS Elemental MediaConverの機能の一つに音量正規化（Audio Normalization）というものがあります。MediaConvertの料金ページに追加料金の発生するアドオン機能の一つとして列挙されている機能で、名称だけは知っている、というケースは多いのではないでしょうか。
この音量正規化（Audio Normalization）機能、私の記憶が定かであればAWS Elemental MediaConvertリリースの2017年11月の段階ですでに実装されていたかと思います。しかし私もご多分に漏れず、料金ページでは何度も目にしたことがあるけど使ったことはない、という状態でした。
今回はこのMediaConvertの音量正規化機能を使ってみたのでまとめてみたいと思います。目標とするラウドネス値（Target LKFS）を変化させることで、変換前の動画ファイルの音量を全体的に小さくしたり、反対に大きくしたりといったことができることを確認しました。
MediaConvertで音量の正規化をしてみた
では実際にMediaConvertで音量正規化をともなった動画変換をやってみます。
以下の動画（井の頭線の電車を撮影した映像）を入力として使用しました。（以前、ブログエントリ「AWS Elemental MediaConvertでVideo overlays（ビデオソースの置き換え）ができるようになっていました！ | DevelopersIO」で使用した動画ファイルです。）
MediaConvertのマネジメントコンソール、(Create job) ボタンでJobの作成ページに進みます。あらかじめJob settingsのAWS integrationでService access（Service role）の設定を行い、また入力ファイル（Input file URL）を指定しておきます。
今回、変換後のファイルはMP4ファイル形式としました。Output groupsを(Add)し、File groupを(Select)します。出力先となるS3バケットとパス情報をFile group settingsのDestinationで指定します。今回はs3://[bucket-name]/path/to/$fn$-targetlkfs-24という形式で指定しました。suffixとしているtargetlkfs-24は後述するTarget LKFSの値を示すようにしています。
出力のFile groupの設定では、デフォルトで選ばれているVideo codec MPEG-4 AVC (H.264)を使用します。Widthを1280、Heightを720、Max bitrate (bits/s)を5000000としました。（1280x720、5MbpsのMP4動画に変換します。）
上記以外のVideoの設定はデフォルト値を使用します。続いて Audio 1 をクリックしてAudioの設定項目に進みます。
Audioの設定についても基本的にはデフォルト値を使用しました。Bitrate (kbit/s)のみ、160.0に変更しています。（Videoのビットレートと合わせて、System preset System-Generic_Hd_Mp4_Avc_Aac_16x9_Sdr_1280x720p_30Hz_5Mbps_Qvbr_Vq9を参考にしています。）
さて、ここから本題のAudio Normalizationの設定です。設定箇所はAdvancedの項目の中にあります。「▶Advanced」の箇所をクリックして展開しましょう。
最下部に Audio normalization の項目がありますね！クリックしてチェックボックスをonにします。
Audio normalizationの設定項目が表れます。以下のように設定しました。
AlgorithmはITU-R BS.1770-1、Algorithm controlはCorrect audioとします。目標とするラウドネス値であるTarge LKFSは -24 としました。これはアルゴリズムとしてITU-R BS.1770-1を選択した際にデフォルトで使用される値であり、また後述しますが日本での一般的な基準値でもあります。修正の際のしきい値となるLKFS gateは-70を指定しました。これは設定できる最小値であり、またマネジメントコンソールでデフォルトで表示されている値でもありますね。すべてのレベルのコンテンツを修正するイメージです。
Loudness loggingの項目ではLogを選択し、ラウドネス値をCSVファイルにログ出力するように設定しました。Peack calculationはNoneにし、またTrue-peak limiter thresholdについても今回は無指定としました。
以上でJobを作成します。JogがCompleteとなったら、まずはLoudness loggingで出力したログファイルについて確認してみましょう。出力先として指定したS3バケット内にIMG_0866-targetlkfs-24.mp4という変化後の動画ファイルと、もうひとつIMG_0866-targetlkfs-24_loudness.csvというファイルが作成されています。このCSVファイルがLoudness loggingのログファイルですね。
ログファイルの中身は以下のようになっていました。
Seconds,Dialnorm,InputIntegratedLoudness,OutputIntegratedLoudness
1,0,-18.839191,-23.989708
変換前ラウドネス（InputIntegratedLoudness）が-18.839191 LKFS、変換後のラウドネス （OutputIntegratedLoudness）が-23.989708 LKFSというふうに読み取っています。
続いて変換後の動画ファイルの音量についても確認してみましょう。今回はDaVinci Resolveを使って音量波形として視覚的に確認してみました。
以下が実際の波形です。左側（タイムラインの前半）を変換前の動画（IMG_0866.MOV）、右側（タイムラインの後半）を変換後の動画（IMG_0866-targetlkfs-24.mp4）としています。変換後の動画では波形が全体的に小さくなっていることが確認できますね。つまり、音量としても全体的に小さくなっています。これは、変換前後のラウドネス値（およそ-19 LKFSからおよそ-24 LKFSへ変わったこと）とも一致しますね。
Target LKFSを変えて正規化された音量が変わることを確認してみる
MediaConvertで変換時にに音量正規化を行うことで、変換後の動画ファイルの音量が変わっていること（具体的には音量が小さくなっていること）が確認できました。このケースでは、変換時の音量正規化のパラメータの1つであり、目標とするラウドネス値であるTarget LKFSを-24としました。
続いてはこのTarget LKFSを-13として音量正規化をしてみます。以下のAudio normalizationの設定でJobを作成しました。また出力される変換後のファイルを区別するため、出力先Destinationをs3://[bucket-name]/path/to/$fn$-targetlkfs-13というように変更しています。そのほか項目は先ほどの（Target LKFS -24とした）Jobと同じです。
JobがCompleteしたら、先ほどと同様に、まずはログファイルを確認してみます。
Seconds,Dialnorm,InputIntegratedLoudness,OutputIntegratedLoudness
1,0,-18.839191,-14.020654
変換前ラウドネス（InputIntegratedLoudness）は当然ながら先ほどのJobと同様-18.839191 LKFSでした。変換後のラウドネス（OutputIntegratedLoudness）は-14.020654 LKFSです。先ほどのおよそ-24と比べると値が大きくなっていますね。音量も大きくなっているはずです。
実際の音量をDaVinci Resolveの音量波形で確認してみました。タイムラインの先頭（つまり左）から順に、変換前の動画（IMG_0866.MOV）、Target LKFS -24で変換した動画（IMG_0866-targetlkfs-24.mp4）、Target LKFS -13で変換した動画（IMG_0866-targetlkfs-13.mp4）と並べています。
Target LKFS -13で変換した動画の音声は、変換前よりも大きくなっていることが確認できますね。MediaConvertで音量正規化を行う際にTarget LKFSの値を変えることで、音量を全体的に小さくするほか、大きくすることもできることが確認できました。
Audio normalizationの各設定やラウドネスについて
MediaConvertで音量正規化を行うことで、全体の音量を変換前から大きくしたり小さくしたりできることを確認してきました。
ところで、筆者は今回はじめてMediaConvertのAudio normalization機能を使ってみたのですが、実は設定項目を確認した段階では、「あれ？どう設定したら実際に音量を変えられるんだ？」という状態でした。
Audio normalization機能についは、私が確認する限り、MediaConvert User Guideに記載はありません。（Audio normalization機能がMediaConvertリリース当時からある機能ということもあり、そういえばリリース当時のAWS Media ServicesはいまほどUser Guideが充実していなかったな、ということを思い出しました。）
公式ドキュメント類で参考になったのはAWS Elemental MediaConvert API ReferenceのJobsリソースのページのAudioNormalizationSettingsの項目です。マネジメントコンソールの設定項目のヘルプ（青文字のInfoクリックで右側に表示される情報）についても、基本的にこのAPI Referenceの情報と同様のようでした。
ただ、このAPI Referenceを読んでも、例えばITU-R BS.1770-1などアルゴリズムの名称だったり、Target LKFSでいきなり-24 LKFSなどの値がでてきたり、いまいちピンとこない項目が多くありました。
その過程で、例えば以下のサイトなどでラウドネスについて改めて基本的なことを確認しました。そもそもラウドネスが何をするものなのかといったことや、日本では-24 LUFS（LKFS）が基準であること、DaVinci Resolveを使った測定方法などなど、ですね。
本エントリでTarget LKFSを-24のほか、-13にして変換したのも上記サイトの情報からきています。こちらによると、YouTubeの標準ラウドネスは-13 LUFSとのことです。（ただし、情報によっては-14 LUFSという記載もあります。）
さらに確認してみると、ストリーミングサービスでそれぞれラウドネス基準値は異なっているようです。
放送局などの一般的な基準では-24 LUFSなどが用いられるのに対して、ストリーミングサービスでは-20より大きい、-18〜-14 LUFSあたりが基準値として使われている、ということでした。
またそもそも、MediaConvertの設定項目で出てきたBS.1770といったアルゴリズム、ラウドネスの計測方法についても様々な種類があるようです。今回は扱いませんでしたが、MediaConvertの設定項目にあるゲート（KFS gate）やTrue peak（Peak calculation）などの項目でも、音量正規化後の結果は変わりそうです。
実際にMediaConvertで音量正規化を行うとして、Target LKFSなどをどうするか、といったことを件t脳する場合は、このような「ラウドネス」に関して調査するとよさそうかな、と思いました。
まとめ
AWS Elemental MediaConvertで音量の正規化をやってみました。変換前の動画ファイルに対してパラメータ（Target LKFS）の違いで、音量が全体的に小さく、または大きくなることが確認できました。
個人的には音量・ラウドネスまわりに疎く（カラーバーと1kHzトーンは-20dBにあわせておく、ぐらいの漠然とした知識しかありませんでした）、設定項目をみたときは少々とっつきにくい感じを受けました、ラウドネスまわりについて基本的な項目を確認しつつ、MediaConvertのAudio normalization機能の確認ができました。
単体の動画ファイルのみを配信する場合などではあまり活用する機会はないかと思いますが、音量レベル（ラウドネス）が異なる可能性のある複数のコンテンツを連続して再生・視聴できるようにする場合などでは、ラウドネス・音量をあわせておくことは重要ですよね。わかりやすい例でいえば、動画コンテンツが本編と広告などで切り替わるたびに、音量が変わって視聴者がスマホなどの視聴デバイス側で音量を操作していた、なんてのはあまり良い体験ではありません。そんなことを避けるためにも、MediaConvertのAudio normalizationを上手に活用していきましょう。
