パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

ニコニコ動画、ラウドネスノーマライゼーションを導入」記事へのコメント

  • ニコニコ動画のラウドネスノーマライゼーション(自動音量調整機能)について
    https://ch.nicovideo.jp/nicotalk/blomaga/ar1848078 [nicovideo.jp]

    に書かれていますが、ニコニコ動画が導入したのは、音質を一切低下させない完璧なラウドネスノーマライゼーションです。

    これなら、歌ってみたや音楽動画などを楽しんでいるユーザにとっても納得いく機能だと思います。しかもプレミアムアカウントでなくてもユーザがOFFにすることができます。

    一方、競合のYouTubeは、強制再エンコードでもラウドネスノーマライゼーション(強制)でも、音質が劣化する仕様です。

    同じ高音質動画を、YouTubeとニコニコ動画にアップして比較したことがありますが、数万円程度で構築できる試聴環境でも、はっきりと音質差が分かるレベルに違いました。
    (CDとハイレゾのような僅かな差ではなく、全く音質が違うと認識できるレベル)

    • >音質を一切低下させない完璧なラウドネスノーマライゼーション
      とは……

      ラウドネスノーマライゼーションは曲”全体”の音量をLUFS値で測り、それが任意の値(この場合は-15LUFS)になるよう音量を調整するだけなので、ラウドネスノーマライゼーションで音質が変わると言うのは音量を上下させただけで音質が変わると言っているのと同義でおかしい話

      音声のコーデックがyoutubeではopusの128~160kbpsであることが音質の差の理由

      親コメント
      • by Anonymous Coward

        ダイナミックレンジは劣化しないの?
        それとも、ノーマライゼーションと同時にビット拡張も行うんだろうか。

        • 現在主流のオーディオ演算が行われている32bit floatのダイナミックレンジは1530dBも有るので無用な心配かと 32bit floatに対するディザはあったとしても-200dBFS以下のものしか見た事が無い
          エンコードする際のゲインステージングの段階では、非可逆圧縮の場合PCMの様に単純にビット深度からダイナミックレンジを予測することが難しく、また入力される音量が0dBFSに近づくと誤差が増えたりする事があるが、これはフォーマット側の問題でありラウドネスノーマライゼーションによるものではない(ニコニコの場合はオプションで切れるので、おそらくメタデータを使って既にエンコードしたものに対してプレイヤー側で音量調節を行なっていると思われるのでその場合単純にフォーマットの性能の差ということになる)
          出力側ハードを考慮しても現行dacのノイズフロアの値はスマホ付属でも-100dBA程で、ノイズに埋もれることも殆どない

          親コメント
          • by Anonymous Coward

            演算のことを言ってるのではありません。
            それは好きな精度でやったらよろしい。

            そうではなく、元のオーディオデータが何bitで記録されているのかを気にしています。
            元のオーディオデータの平均レベルを増やしたとき、同じbitで出力したらダイナミックレンジが削られませんか。
            元が16bitで記録されていて、その平均レベルをコンプレッションかけずに6dB持ち上げると、同じ16bitで出力したらダイナミックレンジが6dB減りますよ。
            それとも、演算後のデータを32bit floatとかで出力して、それを受け取れるドライバやDACが存在するのですか?

            もしくは16bitで記録されたデータを、ノーマライゼーションの演算後に24bitに拡張して(いわゆるハイレゾ規格に拡張して)出力するような仕組みが、今回のニコニコ動画のシステムにはあるのか、そこが先のコメントの質問です。
            24bitに拡張して出力してくれるなら、それを再生できるシステムは存在するので。

            • あなたが最初にしたコメントの内容と随分話が逸れている様に思いますが…
              >元のオーディオデータの平均レベルを増やしたとき、同じbitで出力したらダイナミックレンジが削られませんか。
              >元が16bitで記録されていて、その平均レベルをコンプレッションかけずに6dB持ち上げると、同じ16bitで出力したらダイナミックレンジが6dB減りますよ。
              youtubeは細かい仕様を公表しなくなってしまった上にちょくちょく仕様を変更するのでもしかしたら違う可能性はありますが、現状音量を大きくする方向に正規化しているサービスはspotifyだけでそれもプレイヤー側にリミッターが付いて0dBFSを超えない様な仕組みかつ課金すれば正規化の目標値を-14から-24LUFSにまで落としてヘッドルームを十分確保できる様になっています
              なので続く2段落目も杞憂としか言いようがない内容ですが、あえて誤りを指摘するならソース固有のダイナミックレンジ(一度記録されたもの)とフォーマットが提供できるスペックとしてのダイナミックレンジ(16bitなら96dB)を混同しているのでしょう。ソースが16bitである時点でそのソースは96dB以上のダイナミックレンジを持つことが出来ませんし、また16bitであるからと言って96dBをフルに使ったソースであるという必要はありません。むしろフォーマットによるノイズフロアの制約でダイナミックレンジが下がると言えるのは音量を下げる方向に調整した時です
              >もしくは16bitで記録されたデータを、ノーマライゼーションの演算後に24bitに拡張して(いわゆるハイレゾ規格に拡張して)出力するような仕組みが、今回のニコニコ動画のシステムにはあるのか、そこが先のコメントの質問です。
              なのでこの部分も些か的を得ない質問という事になりますが、敢えて言うなら16bitで記録されたデータを24bitに再変換するのは非可逆圧縮されたファイルをwavに変換する様な無意味な行為です
              おそらく貴方は、ダイナミックレンジとノイズフロアとヘッドルーム辺りの語句を根本的に理解していないのだと思いますが

              親コメント
              • by Anonymous Coward

                ソースが16bitフルに使ってダイナミックレンジが96dBであった場合、その平均レベルを6dB上下するとしましょう。
                そのとき、出力が16bitのままでどうやって96dBのダイナミックレンジを維持できるのですか?
                その仕組みを説明して下さい。
                私は実現不可能だと思っているので、必ず劣化が起きると考えています。

                劣化が起きないのは、ソースのビット数より出力のビット数を増やした場合だけです。
                元が16bitで0dBFSから-96dBFSを使っている場合に6dB平均音量を下げるなら、1bit拡張して17bitにして、-6dBFSから-102dBFSで表現するしかありません。
                そうでなければ必ず失われる情報があります。

              • by Anonymous Coward

                もし誤解されると行けないので書いておきますが、上記の0dBFSは文字通りADC/DAC/デジタルデータのフルスケールとしての0dBです。

                >spotifyだけでそれもプレイヤー側にリミッターが付いて0dBFSを超えない様な仕組み
                フォーマット上からも、用語の定義からも0dBFSを超えることなんて無いはずですが、このようなことを書かれているので一応。

                >おそらく貴方は、ダイナミックレンジとノイズフロアとヘッドルーム辺りの語句を根本的に理解していない
                あなたは信じないかもしれませんが、私はオーディオIC開発にも関わっているので、この辺りの誤解はしていないつもりです。

              • 連投制限かかってしまったので遅くなって申し訳ない

                既に述べた通り、youtubeやニコニコが採用している非可逆圧縮で設定できるのはビットレートのみであり、PCMのようなサンプリングレートとビットデプスが常に一定(44.1kHz/16bitで1411.2kbps)のものと単純に比較することはできません(とはいえ、youtubeとニコニコで見てみましたが概ね100~120dB程のダイナミックレンジは確保できていると言えるでしょう)

                >元が16bitで0dBFSから-96dBFSを使っている場合に6dB平均音量を下げるなら、1bit拡張して17bitにして、-6dBFSから-102dBFSで表現するしかありませ

              • by Anonymous Coward

                私が議論しているのは正にここです。

                >dacに送られた時点の音量がdac側が対応できるダイナミックレンジ(多くの場合24dB int、つまり0dBFSから-144dBFS)を超えている場合は当然クリップするか再生されなくなるかします。

                DACに送る前にどう演算するかは、あなたがさんざん書かれているように好きな精度で演算できます。
                私も既に書きましたが、ここは好きな精度で劣化しないように演算すれば良いと思います。
                問題は、DAC(オーディオコーデックIC)に渡す段階で劣化が起きることです。

                DACにどのようなフォーマットでデータを渡すかは、DACのICのインターフェイスとドライバに依存

              • >音量を上下する場合は、ここで必ずダイナミックレンジの劣化が起こります。
                自分が引っかかっているところはここです。16bitの場合、それ以外(以降)のパスで16bit以上のbit depthが確保されていれば、それは単なる音量の上下とみなせるはずでそれをわざわざビット拡張だとかダイナミックレンジの劣化だとか言うのは違和感があります。アプリケーションからのドライバによる伝送がそれ以上の深度で行われているのならなおさらですし、そうでなければアプリ側のボリュームで音量を絞ってから後段で増幅しても量子化ノイズが多く乗った音になりますよね

    • by Anonymous Coward

      DACの手前で音量調整する以上、ビットパーフェクト云々で完璧なラウドネスノーマライゼーションとは言えないのでは?
      そもそも、OSのミキサーを通すならたいして変わらんのだろうけど

海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs

処理中...