アカウント名:
パスワード:
ニコニコ動画のラウドネスノーマライゼーション(自動音量調整機能)についてhttps://ch.nicovideo.jp/nicotalk/blomaga/ar1848078 [nicovideo.jp]
に書かれていますが、ニコニコ動画が導入したのは、音質を一切低下させない完璧なラウドネスノーマライゼーションです。
これなら、歌ってみたや音楽動画などを楽しんでいるユーザにとっても納得いく機能だと思います。しかもプレミアムアカウントでなくてもユーザがOFFにすることができます。
一方、競合のYouTubeは、強制再エンコードでもラウドネスノーマライゼーション(強制)でも、音質が劣化する仕様です。
同じ高音質動画を、YouTubeとニコニコ動画にアップして比較したことがありますが、数万円程度で構築できる試聴環境でも、はっきりと音質差が分かるレベルに違いました。(CDとハイレゾのような僅かな差ではなく、全く音質が違うと認識できるレベル)
>音質を一切低下させない完璧なラウドネスノーマライゼーションとは……
ラウドネスノーマライゼーションは曲”全体”の音量をLUFS値で測り、それが任意の値(この場合は-15LUFS)になるよう音量を調整するだけなので、ラウドネスノーマライゼーションで音質が変わると言うのは音量を上下させただけで音質が変わると言っているのと同義でおかしい話
音声のコーデックがyoutubeではopusの128~160kbpsであることが音質の差の理由
ダイナミックレンジは劣化しないの?それとも、ノーマライゼーションと同時にビット拡張も行うんだろうか。
現在主流のオーディオ演算が行われている32bit floatのダイナミックレンジは1530dBも有るので無用な心配かと 32bit floatに対するディザはあったとしても-200dBFS以下のものしか見た事が無いエンコードする際のゲインステージングの段階では、非可逆圧縮の場合PCMの様に単純にビット深度からダイナミックレンジを予測することが難しく、また入力される音量が0dBFSに近づくと誤差が増えたりする事があるが、これはフォーマット側の問題でありラウドネスノーマライゼーションによるものではない(ニコニコの場合はオプションで切れるので、おそらくメタデータを使って既にエンコードしたものに対してプレイヤー側で音量調節を行なっていると思われるのでその場合単純にフォーマットの性能の差ということになる)出力側ハードを考慮しても現行dacのノイズフロアの値はスマホ付属でも-100dBA程で、ノイズに埋もれることも殆どない
演算のことを言ってるのではありません。それは好きな精度でやったらよろしい。
そうではなく、元のオーディオデータが何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に変換する様な無意味な行為ですおそらく貴方は、ダイナミックレンジとノイズフロアとヘッドルーム辺りの語句を根本的に理解していないのだと思いますが
ソースが16bitフルに使ってダイナミックレンジが96dBであった場合、その平均レベルを6dB上下するとしましょう。そのとき、出力が16bitのままでどうやって96dBのダイナミックレンジを維持できるのですか?その仕組みを説明して下さい。私は実現不可能だと思っているので、必ず劣化が起きると考えています。
劣化が起きないのは、ソースのビット数より出力のビット数を増やした場合だけです。元が16bitで0dBFSから-96dBFSを使っている場合に6dB平均音量を下げるなら、1bit拡張して17bitにして、-6dBFSから-102dBFSで表現するしかありません。そうでなければ必ず失われる情報があります。
もし誤解されると行けないので書いておきますが、上記の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で表現するしかありませ
私が議論しているのは正にここです。
>dacに送られた時点の音量がdac側が対応できるダイナミックレンジ(多くの場合24dB int、つまり0dBFSから-144dBFS)を超えている場合は当然クリップするか再生されなくなるかします。
DACに送る前にどう演算するかは、あなたがさんざん書かれているように好きな精度で演算できます。私も既に書きましたが、ここは好きな精度で劣化しないように演算すれば良いと思います。問題は、DAC(オーディオコーデックIC)に渡す段階で劣化が起きることです。
DACにどのようなフォーマットでデータを渡すかは、DACのICのインターフェイスとドライバに依存
>音量を上下する場合は、ここで必ずダイナミックレンジの劣化が起こります。自分が引っかかっているところはここです。16bitの場合、それ以外(以降)のパスで16bit以上のbit depthが確保されていれば、それは単なる音量の上下とみなせるはずでそれをわざわざビット拡張だとかダイナミックレンジの劣化だとか言うのは違和感があります。アプリケーションからのドライバによる伝送がそれ以上の深度で行われているのならなおさらですし、そうでなければアプリ側のボリュームで音量を絞ってから後段で増幅しても量子化ノイズが多く乗った音になりますよね
DACの手前で音量調整する以上、ビットパーフェクト云々で完璧なラウドネスノーマライゼーションとは言えないのでは?そもそも、OSのミキサーを通すならたいして変わらんのだろうけど
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
音質を一切低下させない完璧なラウドネスノーマライゼーション (スコア:1)
ニコニコ動画のラウドネスノーマライゼーション(自動音量調整機能)について
https://ch.nicovideo.jp/nicotalk/blomaga/ar1848078 [nicovideo.jp]
に書かれていますが、ニコニコ動画が導入したのは、音質を一切低下させない完璧なラウドネスノーマライゼーションです。
これなら、歌ってみたや音楽動画などを楽しんでいるユーザにとっても納得いく機能だと思います。しかもプレミアムアカウントでなくてもユーザがOFFにすることができます。
一方、競合のYouTubeは、強制再エンコードでもラウドネスノーマライゼーション(強制)でも、音質が劣化する仕様です。
同じ高音質動画を、YouTubeとニコニコ動画にアップして比較したことがありますが、数万円程度で構築できる試聴環境でも、はっきりと音質差が分かるレベルに違いました。
(CDとハイレゾのような僅かな差ではなく、全く音質が違うと認識できるレベル)
Re:音質を一切低下させない完璧なラウドネスノーマライゼーション (スコア:1)
>音質を一切低下させない完璧なラウドネスノーマライゼーション
とは……
ラウドネスノーマライゼーションは曲”全体”の音量をLUFS値で測り、それが任意の値(この場合は-15LUFS)になるよう音量を調整するだけなので、ラウドネスノーマライゼーションで音質が変わると言うのは音量を上下させただけで音質が変わると言っているのと同義でおかしい話
音声のコーデックがyoutubeではopusの128~160kbpsであることが音質の差の理由
Re: (スコア:0)
ダイナミックレンジは劣化しないの?
それとも、ノーマライゼーションと同時にビット拡張も行うんだろうか。
Re:音質を一切低下させない完璧なラウドネスノーマライゼーション (スコア:1)
現在主流のオーディオ演算が行われている32bit floatのダイナミックレンジは1530dBも有るので無用な心配かと 32bit floatに対するディザはあったとしても-200dBFS以下のものしか見た事が無い
エンコードする際のゲインステージングの段階では、非可逆圧縮の場合PCMの様に単純にビット深度からダイナミックレンジを予測することが難しく、また入力される音量が0dBFSに近づくと誤差が増えたりする事があるが、これはフォーマット側の問題でありラウドネスノーマライゼーションによるものではない(ニコニコの場合はオプションで切れるので、おそらくメタデータを使って既にエンコードしたものに対してプレイヤー側で音量調節を行なっていると思われるのでその場合単純にフォーマットの性能の差ということになる)
出力側ハードを考慮しても現行dacのノイズフロアの値はスマホ付属でも-100dBA程で、ノイズに埋もれることも殆どない
Re: (スコア:0)
演算のことを言ってるのではありません。
それは好きな精度でやったらよろしい。
そうではなく、元のオーディオデータが何bitで記録されているのかを気にしています。
元のオーディオデータの平均レベルを増やしたとき、同じbitで出力したらダイナミックレンジが削られませんか。
元が16bitで記録されていて、その平均レベルをコンプレッションかけずに6dB持ち上げると、同じ16bitで出力したらダイナミックレンジが6dB減りますよ。
それとも、演算後のデータを32bit floatとかで出力して、それを受け取れるドライバやDACが存在するのですか?
もしくは16bitで記録されたデータを、ノーマライゼーションの演算後に24bitに拡張して(いわゆるハイレゾ規格に拡張して)出力するような仕組みが、今回のニコニコ動画のシステムにはあるのか、そこが先のコメントの質問です。
24bitに拡張して出力してくれるなら、それを再生できるシステムは存在するので。
Re:音質を一切低下させない完璧なラウドネスノーマライゼーション (スコア:1)
あなたが最初にしたコメントの内容と随分話が逸れている様に思いますが…
>元のオーディオデータの平均レベルを増やしたとき、同じbitで出力したらダイナミックレンジが削られませんか。
>元が16bitで記録されていて、その平均レベルをコンプレッションかけずに6dB持ち上げると、同じ16bitで出力したらダイナミックレンジが6dB減りますよ。
youtubeは細かい仕様を公表しなくなってしまった上にちょくちょく仕様を変更するのでもしかしたら違う可能性はありますが、現状音量を大きくする方向に正規化しているサービスはspotifyだけでそれもプレイヤー側にリミッターが付いて0dBFSを超えない様な仕組みかつ課金すれば正規化の目標値を-14から-24LUFSにまで落としてヘッドルームを十分確保できる様になっています
なので続く2段落目も杞憂としか言いようがない内容ですが、あえて誤りを指摘するならソース固有のダイナミックレンジ(一度記録されたもの)とフォーマットが提供できるスペックとしてのダイナミックレンジ(16bitなら96dB)を混同しているのでしょう。ソースが16bitである時点でそのソースは96dB以上のダイナミックレンジを持つことが出来ませんし、また16bitであるからと言って96dBをフルに使ったソースであるという必要はありません。むしろフォーマットによるノイズフロアの制約でダイナミックレンジが下がると言えるのは音量を下げる方向に調整した時です
>もしくは16bitで記録されたデータを、ノーマライゼーションの演算後に24bitに拡張して(いわゆるハイレゾ規格に拡張して)出力するような仕組みが、今回のニコニコ動画のシステムにはあるのか、そこが先のコメントの質問です。
なのでこの部分も些か的を得ない質問という事になりますが、敢えて言うなら16bitで記録されたデータを24bitに再変換するのは非可逆圧縮されたファイルをwavに変換する様な無意味な行為です
おそらく貴方は、ダイナミックレンジとノイズフロアとヘッドルーム辺りの語句を根本的に理解していないのだと思いますが
Re: (スコア:0)
ソースが16bitフルに使ってダイナミックレンジが96dBであった場合、その平均レベルを6dB上下するとしましょう。
そのとき、出力が16bitのままでどうやって96dBのダイナミックレンジを維持できるのですか?
その仕組みを説明して下さい。
私は実現不可能だと思っているので、必ず劣化が起きると考えています。
劣化が起きないのは、ソースのビット数より出力のビット数を増やした場合だけです。
元が16bitで0dBFSから-96dBFSを使っている場合に6dB平均音量を下げるなら、1bit拡張して17bitにして、-6dBFSから-102dBFSで表現するしかありません。
そうでなければ必ず失われる情報があります。
Re: (スコア:0)
もし誤解されると行けないので書いておきますが、上記の0dBFSは文字通りADC/DAC/デジタルデータのフルスケールとしての0dBです。
>spotifyだけでそれもプレイヤー側にリミッターが付いて0dBFSを超えない様な仕組み
フォーマット上からも、用語の定義からも0dBFSを超えることなんて無いはずですが、このようなことを書かれているので一応。
>おそらく貴方は、ダイナミックレンジとノイズフロアとヘッドルーム辺りの語句を根本的に理解していない
あなたは信じないかもしれませんが、私はオーディオIC開発にも関わっているので、この辺りの誤解はしていないつもりです。
Re: (スコア:0)
連投制限かかってしまったので遅くなって申し訳ない
既に述べた通り、youtubeやニコニコが採用している非可逆圧縮で設定できるのはビットレートのみであり、PCMのようなサンプリングレートとビットデプスが常に一定(44.1kHz/16bitで1411.2kbps)のものと単純に比較することはできません(とはいえ、youtubeとニコニコで見てみましたが概ね100~120dB程のダイナミックレンジは確保できていると言えるでしょう)
>元が16bitで0dBFSから-96dBFSを使っている場合に6dB平均音量を下げるなら、1bit拡張して17bitにして、-6dBFSから-102dBFSで表現するしかありませ
Re: (スコア:0)
私が議論しているのは正にここです。
>dacに送られた時点の音量がdac側が対応できるダイナミックレンジ(多くの場合24dB int、つまり0dBFSから-144dBFS)を超えている場合は当然クリップするか再生されなくなるかします。
DACに送る前にどう演算するかは、あなたがさんざん書かれているように好きな精度で演算できます。
私も既に書きましたが、ここは好きな精度で劣化しないように演算すれば良いと思います。
問題は、DAC(オーディオコーデックIC)に渡す段階で劣化が起きることです。
DACにどのようなフォーマットでデータを渡すかは、DACのICのインターフェイスとドライバに依存
Re: (スコア:0)
>音量を上下する場合は、ここで必ずダイナミックレンジの劣化が起こります。
自分が引っかかっているところはここです。16bitの場合、それ以外(以降)のパスで16bit以上のbit depthが確保されていれば、それは単なる音量の上下とみなせるはずでそれをわざわざビット拡張だとかダイナミックレンジの劣化だとか言うのは違和感があります。アプリケーションからのドライバによる伝送がそれ以上の深度で行われているのならなおさらですし、そうでなければアプリ側のボリュームで音量を絞ってから後段で増幅しても量子化ノイズが多く乗った音になりますよね
Re: (スコア:0)
DACの手前で音量調整する以上、ビットパーフェクト云々で完璧なラウドネスノーマライゼーションとは言えないのでは?
そもそも、OSのミキサーを通すならたいして変わらんのだろうけど