PCMの「TruePeak」とは何か

15/04/11初稿

 「ハイレゾとDACについて考えていたらいろいろメンドクサイことに気がついちゃったかも知れない」シリーズ(笑)。


■TruePeakとは何か

・きっかけ
 とある邦楽CD音源のUDA-1アナログ出力をPCでADして、スペクトルを動的に眺めていた時のことです。
 頻度は多くありませんが、22kHz以上の帯域がヘンな表示に崩れることがあります。

フィルタリング・クリップ
(アナログキャプチャ)

 キャプチャレベルを下げても発生します。
 プレーヤソフトは≪foobar2000≫ですが、PCMそのまんま再生でもアップサンプリング再生でもDSD変換再生でも同じです。フルスイングのサイン波では発生しないようにボリューム調整したヘッドホン出力でも発生します。
 プレーヤソフトを変えて≪JRiver MediaCenter20≫にしてみても、PCM単純再生、DSD256変換再生共に発生します。
 しかし≪foobar2000≫のボリュームをちょっと下げると発生しなくなります。

 ずっと、たまたま何かFFT処理のツボみたいな時に発生するのかと思ってたけどなんだか違うみたいです。
 ということで、これをきっかけにいろいろ調べることになりました。

 なお、この“きっかけ”には何か勘違いあるかも知れませんが、以下考察には影響ないと思います。

・データがクリップしていなくても再生するとクリップする?
 「クリップして潰れている時の現象?」と思って“海苔系音源”で見てみると確かに多発します。
 しかし、当該ソースの最大音量を≪SoundEngineFree 5.02≫で調べてみると「-0.10dB」です。
 ≪Audacity 2.0.6≫の1of1条件で調べてもクリップしていません。

 これってもしかしてどこかで見た記憶がある「TruePeak」ってヤツでは? と、Resampler-V(SoX)で2倍アップサンプリングしたファイル(Convert機能で作成)化して同じく調べてみたところ、最大音量は「0dB」になり「1of1クリップ(*)」も大量発生しました。

*:1サンプルのみフルスケール(フルビット)であることを≪Audacity≫表示にならって「1of1クリップ」と呼ぶことにします。

 以下、発生箇所の例です(ただし、“きっかけ”になったスペクトル崩れ箇所ではありません)。
 上がオリジナル、下が2倍アップサンプリングです。

TruePeak:1644と1688:音楽:トリミング2

 オリジナル(上)は全くクリップしていません。が、2倍アップサンプリング(下)して“本来あるべきアナログ波形”に近づけたら「1of1クリップ」が発生しています。
 これはPCプレーヤソフトのアップサンプリングで発生した例(*)ですが、DACチップ内でも同様の処理である「オーバーサンプリングデジタルフィルタ」が行われていることはDAC動作を考えた記事などで詳述した通りです。

*:本実験は解りやすくするために2倍で実施しています。DACチップはもっと高倍率(PCM1795の場合は8倍)。

 つまり、PC側でアップサンプリングなどせず普通に再生していても、DACユニット内のデジタル→アナログ変換において

 OSDF(*)処理=リコンストラクションフィルタ処理によってピークは上昇する

のです。

*:Over Sampling Digital Filter

 「TruePeak」「インターサンプルピーク」などと呼ぶようです。ニホンゴなら「トゥルーピーク」(笑)。
http://pro.miroc.co.jp/2012/08/03/6782/

 DSDのMaxPeak考察時に参照したJPPA資料にもあります。
http://www.jppanet.or.jp/documents/audio_doc/jppa_chair_of_loudness_vol-1_2010.pdf

 ARIBの資料。P.33あたりが詳しいです。
http://www.arib.or.jp/english/html/overview/doc/4-TR-B32v1_0.pdf

 なお、1サンプルのみがフルスケール値になったとしてもピーク潰れとは限りません(本来あるべきレベルはもっと高いのに飽和した、のではなく丁度フルスケールなのかもしれない)。上記は単純に「アップサンプリングでピーク値が上昇する」例として使っています。

TruePeakのリクツを確かめる
 念のためですが、TruePeakは「音量上げすぎでピーク潰れ」とは根本的に違う現象です。
 いわゆる音圧戦争によって発生した現象ではありません。もちろんその方が発生しやすくなるでしょうけれど、意識的に音圧を上げたりせず、良心的に音量を0dB未満に抑えた場合でも発生するものです。
 それを確かめてみましょう。

 以下は、≪WaveGene 1.50≫で生成した16kHz:2448サイン波(左)と、それを≪foobar2000≫のResampler-V(SoX)でx4:24192にした波形(右)を並べたものです(≪Wavosaur≫にて)。
 ピーク関連の実験ですので、念のため-3dBで生成しています。

TruePeak:2448とそのx4サイン波 30°:トリミング

 16kHzを48kHzサンプリングなので1周期に3サンプルしかありませんから、それがサイン波のピークを捉えるとは限らず、むしろサンプルとサンプルの間にピークがあることの方が多くなります。
 それが「インターサンプルピーク」です。サイン波なら、一番厳しいのはサンプルリングのちょうど中間がアナログ信号のピークだった時です。周波数が高くなるほど(1周期のサンプルポイントが少なくなるほど)リアルサンプルピークとの差が大きくなるのが解ると思います(自分で作図してみればすぐ解ります。上記資料に図ありますし)。

 本例では、プラス側のピークを真ん中にもってくるため30度位相をズラして生成しています。ゼロクロスからではなく30/360=1/12進んだ状態からスタートしている状態です。16kHz-3dBのサイン波を48kHzキャプチャした時、たまたま波形とキャプチャ周期のタイミングが30度(1/12周期)ズレた場合のシミュレーションになっているハズです。

 生成したサンプル(左)では、プラス側振幅最大値は全く-3dBに届いていません。先の資料の通りおそらく6dB低いでしょう。しかし、サンプリング定理に基づいてリコンストラクションされるとキレイなサイン波が再現されるのです。右側の24192は、4倍アップサンプリングすればほぼサイン波が再現できることのシミュレーションです。
 なお、この例は解りやすさを優先してプラス側だけ極端に低くなるようにしているためマイナス側のピークは変化しませんが、位相ズレが30度でない場合を想像していただければマイナス側でもTruePeakが発生することは解ると思います。

・DACチップ動作の実際
 でも、感覚的には腑に落ちないところもありますよね。元のデジタルデータよりも約6dBも大きなアナログデータに再現されるのって本当に正しいのか? と。
 そこで、実際にこの2448ファイルを再生側では無加工=“ネイティブPCM再生”してアナログキャプチャしてみました。DACチップによる処理だけが現れるハズです。
 環境は「基音と倍音」記事と同じです。

TruePeak:2448サイン波16kHz-3dB 30°の再生波形
(アナログキャプチャ)

 データとしては3サンプル/周期しかなく、しかもプラス側ピークはデータ値としては-9dB程度しかないのに、ちゃんと16kHzサイン波が再生されています。
 DACチップ内でもSoXのアップサンプリングと同様の波形再現処理が行われていると見ていいでしょう。
 サンプリング定理(リコンストラクション=再構築処理)って凄いですね。

 人間が上記16kHzのサンプルポイントだけを提示され、「サンプル点を繋ぎなさい。ただし24kHzサイン波以上の急峻な変化はさせてはなりません」と言われたら、前後複数のサンプルポイントを考慮しながらなるべく滑らかになるよう線を引きますよね。結果は16kHzのサイン波になっちゃうハズです。
 「デジタルフィルタはそれと同じことを演算でやっている」ということです。

 なお、DACチップのアップ処理は4倍以上ですから、キャプチャしたサイン波は“もっと滑らかになってもいい”ハズです。
 なりきっていないのは、AD変換の方が192kHz止まりだからだと思います。48kHzを4倍した時と同じサンプリングポイントしかないので、192kHzのデジタル波形とアナログキャプチャ波形が結果的に似ているのだろう、と。

・TruePeakは制作側でどう扱われているか
 さて、とすると

「デジタルデータの値としてピークがサチっていなくても、アナログ化したらクリップする可能性がある」

と言うことです。

 制作サイドが、44.1kHz(や48kHz)のデータとしてサチらないようにピークレベルを確認しても、再生(DA変換)におけるリコンストラクションフィルタによってサチる(ピーク潰れが発生する)ことがあるワケです。
 そして、それは決してDAC(リコンストラクション)が余計なことをしているのではなく、正しい動作なのです。

 単純にAD→DAするだけであればアナログ波形が復元されるだけで元のアナログ波形よりピークが上昇することはないでしょう。
 が、一般の音楽制作ではそうはいきません。デジタルドメインで音量調節しますしミキシングしますしシンセなどの人工音声も入ってくるでしょうから。
 少なくとも非ハイサンプリングの音楽データにおいては、「リアルデータ値で注意していてもダメ」ってことです。

 これを避ける=事前に確認・修正する方法はあります。データをアップサンプリングしてDAC内におけるリコンストラクションをシミュレートすればよいのです。
 上記資料には、「4倍すればリアルサンプルピークとインターサンプルピークの誤差を0.3dBにまで抑えられる」とあります。上で見た24192(4倍)ファイルではほぼ16kHzサイン波が再現できていますので、確かにそのようです。
 「アップサンプリングでリコンストラクションをシミュレートし、クリップしないか確認し、修正する」ということですね。

 以上のことはデジタルオーディオのリクツを熟知している専門家にとっては意外でもなんでもないことだと思います。
 また、アップサンプリングによるクリップチェックは確認だけであってデータに手を加えるワケではありませんから弊害はありません。なので実施していて当然と思いますが、実際には発生しているところを見ると、どうもそうではないようですねぇ。
 「TruePeak問題」は制作現場には浸透していないのでしょうか。それとも、あまり気にしなくて良いという判断なのでしょうか。

 まあ、そもそもインターサンプルのピークどころか「“リアルサンプルのピーク”をガンガンクリップさせまくるマスタリング」が横行しているくらいですから、見えないピークなんて、知ってても無視なのかも知れません(苦笑)。

 昔のCDは2~3dBヘッドルームマージンがあるものが多いですが、“かつては”こういうことも配慮していたのかも知れません。

 ちなみに。
 web検索していたら、「Mastered for iTunes勉強会」の報告書(*)という情報を見つけました。
 この中の【クリッピングをチェックするツール】項に、「(インターサンプルピークが)すごい数出てくる」「いくつかなら問題ない(とAppleに言われている)」「compかけてガツガツ入れてる音源では1.5dBくらい下げないと出てきちゃう」などとあります。
 おそらくアップサンプリングしてチェックかけるツールなのだと思います(圧縮エンコードするとデコード時にピークが上がることがあるらしいので、もしかするとそのシミュレーションも入っているかも知れませんが)。
 いずれにしても、その結果について意外そうに言われると、TruePeakは制作者側にあんまり意識されてないような気がします。

*:http://jarec.com/report/2492

 どうも“そういうもの”ってことみたいですねぇ。意外ですけれど。


■TruePeakをどうすればよいか

 制作側では“そういうもの”らしいとなると、じゃあ、これエンドユーザはどうすればいいのでしょう?
 「発生数が多くなければ無視してよい」ってのは作る方の事情であって、聴く方にすれば発生数の多少…無視していいなどうかなんて音源データ解析しないと判らないですもんね。

・デジタルボリュームでデータ演算して回避
 PCMそのまま再生でもPCM→DSD変換再生でも、プレーヤ側で2dBくらい絞って送出すれば発生しなくなるっぽいですので、今後はそうしようかなぁ。
 でも、

「もともとピークが-3dB以下くらいのソースならそのままでもいい」
けれど、逆に
「もともとクリップしまくりのソースだとTruePeakを救っても焼け石に水」

ですよねぇ。だからってソースの素性をいちいちチェックしてから再生ってのも… リッピング時にチェックしてフォルダにマーキングでもしとく?(苦笑)

 また、やるなら排他WASAPIやASIOなどビットパーフェクトなAPIに対応してて、かつ、ボリューム機能があるプレーヤを使う必要があります。アップサンプリングする場合はその前にボリューム絞らねばなりません。プレーヤソフトに対する条件が増えちゃう=選択肢が狭まるということですね。TruePeakを気にするのなら、ですが。
 ちなみに≪foobar2000≫のボリュームプロセスはDSPより前だと思います。

・デジタルボリューム処理は音質劣化するのか
 ところで。
 デジタル演算でボリューム調整することには、「音質劣化する」と抵抗ある人も多いと思います。
 ですが、ちゃんとしたプレーヤソフトならそれはあまり気にする必要はないと思っています。
 例えば≪foobar2000≫の内部処理は32bitFloatのよう(*)ですから、(32bitネイティブ音源以外は)“音声情報劣化”を心配する必要はないでしょう。

*:BBSに「SoX Resamplerはプラグインとして32bitFloatでfoobarコアとIN/OUTしている」という記述があることから。なお、これはコアの基本動作の話であり、プラグインなどの内部は64bitかも知れません。

 どうして気にする必要ないのか、ちょっとたとえ話で説明してみます。

 PCさんが持ってる10円をDACさんに7/8にして渡さなければならなくなったとします。PCさんとDACさんが“円単位”でしか取引できない場合は四捨五入して9円にするしかないですが、“銭の単位”で取引できるならバッチリ「8円75銭」渡せますよね。
 もちろんいくら拡張しても割り切れるケースの方が少ないですが、例えば16bitを32bit拡張して演算した結果は、元の1bitを65,536段階で表現しているワケで、さらにそこで残る誤差(余り?)はもう無視していいでしょう。

 個人的には、ビット拡張してなお発生する誤差より、TruePeakによるクリップ発生の方がキモチワルイです。

・“ビット落ち”とは何か
 デジタル演算が嫌いな理由としてよく「“ビット落ち”が発生するから」と言われますが、この言葉、正しく用いる必要があると思っています。

 16bit深度データのプラス側フルスイング値は7FFFhです。例えばこれを256分の1の音量にする時、16bitのままだと8bitシフトですから007Fhになってしまいます。情報量が8bit分もなくなっています。明らかに“ビット落ち”ですね。
 しかし、24bit拡張して処理すれば7FFF00h→007FFFhです。元の情報量(16bit分)はそのまま残っています。
 これは、ざっくり言うと、「ボリューム演算する時、16bitを24bit拡張して実施するなら8x6=48dBゲインダウンするまでは情報の欠損はない」ということです。48dB以上絞る場合に初めて気にした方がよい、ということですね。
 逆に、EQなどで音量が上がる可能性がある場合は、07FFF0hなどにビット拡張してから演算すればよいワケです。

 以上、16bitデータをビット拡張演算して32bitや24bitで再生するような場合、情報量欠損はまず発生していないハズです。
 ので、“ビット落ち”という表現は不適切だと思っています。

 一方、24bitデータは拡張すると32bitになっちゃいますから、32bitで受けられるDACチップじゃないとDAC-I/Fの段階で情報量欠損となり、“ビット落ち”といってもいいでしょう。例えば24bit-I/Fで6dB以上音量絞ったら有効ビットが23bitに減りますので“1bit落ち”です。
 しかしそれって「ダイナミックレンジが144dB→138dBになる“だけ”」です。それを音質劣化と認識できる人はたぶんいない…ていうかそれ以前にその音質違いを表現できる再生装置がない(熱雑音以下?)でしょうから、実効的には無視していいと思っています。逆に、16bitが15bitになっちゃうビット落ちは無視できないと思います。

 以上、「ホントにビット落ち(情報量欠損)しているのか」「落ちてるとしても実効的な音質劣化なのか(それによって得られる効果を上回る劣化なのか)」をよく考えてシステム構築・運用した方がいいと思っています。

 なお、演算結果7FFFh(プラス側最大値。マイナス側なら8000h)を超えてしまうことは、単純に「オーバーフロー」、波形的には「ピーク潰れ」「クリッピング」と呼ぶべきでしょう。ビット落ちてないので。敢えて言うなら“ビット溢れ”?

・≪foobar2000≫の内部処理
 実際に32bit内部処理されているかカンタンに調べてみました。≪foobar2000 1.3.6≫にて。
 ボリュームが一番手軽なのですが、Convert機能によるファイル化ではボリューム効かないんですよね。といってウチの機材のS/PDIFデジタル録音方式だと24bitまでしか扱えません。そこで、16bitデータに≪-6dBLimiter≫というプラグインかけてConvert機能の32bit出力でファイル化。あんまりいい方法じゃないと思いますけどとりあえず。
 値を覗いてみたところ、おそらく32bit有意な値になってると思います。最大振幅値は7FFFhが3F6178D7hになってましたので。

1648.png
1648を3248で-6dB

 色付けしたサンプルはサイン波の1/4周期(ゼロクロス~プラスピーク)分です(ステレオ)。

 ボリューム演算がビットシフトに相当する比率じゃない場合はデータ値は変わってしまいます。ですので、私も気持ち的には「なるべく弄りたくない」派です(笑)。が、イマドキのDACユニット内ではOSDFで「デジタル演算」は必ずかかります。
 ので、「送り出し側でのデジタル演算の副作用をあまり気しても仕方ない(ビット落ちレベルにならないなら)」と、なんとか自分を納得させています。

 ≪foobar2000≫は上記の通り内部32bit処理、UDA-1(PCM1795)は32bit入力、そしてWASAPIもASIOも32bit出力可能、です。
 おお、「フル32bit処理」完成だ(笑)。
 “なんちゃって32bit”とか言われることもあるPCM1795ですが、スペック的にはキモチいいですね(爆)。

 なお、同じ32bitでも≪foobar2000≫の内部処理はFloat、DACチップの扱いはIntegerですが、FPとINTの相互変換において問題となる劣化はないと理解しています。

・FloatingPointの意味
 ところで、上記説明は敢えて「FixedPoint(ていうかINT:integer)」形式に限定しています。プレーヤソフトがFloatingPointで演算しても、DACチップで再生するまでのどこか(プレーヤソフトかDACユニット内のデータレシーバ部か)でFixedPointに変換されてしまうのが一般的だと思いますので。
 ていうか、浮動小数点形式は「計算」のためのものですから、普通はプレーヤソフトの出力時点でINTになってるハズです。

 もし、Floatで受けられるDACユニットがあったとしても、内部で何らかの演算処理をFloat形式で行う仕様(*)じゃないと意味ありません。それでも、DACチップにはINTで入れる必要があるでしょうから演算結果はINT変換されちゃうのですが。
 「Floatで受けられるけど特に内部演算はしないDACユニット」があるなら、受け取ってもただINT変換するだけですから、対応フォーマットを広げるって意味しかないです。
 「Floatで受けてOSDFやΔΣ変換演算をFloat形式で行うDACチップ」を搭載しているなら別ですが、そのようなチップは寡聞にして知らないです。ないですよねぇ?

*:Roland社の「S1LKi」エンジンはこれに相当します。32bitFloat形式で受け取り、DSPで1bit化やPCMx4処理まで行うようです。

    


 なお、念のためですが、本Blogで言う「ピットパーフェクト」とは「意図した加工するにせよしないにせよ、その前提として必要な“意図しない加工が発生しない転送・処理システム、状態”」という意味です。意図した加工を否定するものではありません。


■実事情

・ハイレゾとTruePeak
 ハイレゾ(ハイサンプリング)には、TruePeakが発生しにくいというメリットがあるかも知れませんね。インターサンプルピークとリアルサンプルピークと差が小さくなりますので。
 ただ、96kHzくらいだとまだ残っちゃうみたいです。上記資料の通り、やっぱり4倍(176.4kHz,192kHz)程度は必要ってことですね。

・ボリュームはデジタルですべてまかなえるか
 本項15/10/25追記。
 上述の通り、情報量が欠損することはないでしょう。ですが、だからとデジタルドメインであんまり絞ると、アナログドメインの“オイシイ領域”を使っていないことになるかも知れません。「DACチップ内のアナログ化ブロックは“データフルスケールで最適化”設計されているのではないか」と思えるためです。
 「プレーヤソフトをプリアンプ化する」のは熟慮が必要かと思います。

・電子ボリュームとは何か
 本項15/11/16追記。
 普通は、“絞り具合”を電子制御するボリュームコントロールチップのことを指します(例:JRC社製MUSES72320(*))。
 「デジタルボリューム」などと書かれることもありますが、デジタル値を演算で変更するものではありませんので念のため。

*:http://www.njr.co.jp/products/semicon/PDF/MUSES72320_J.pdf

・DACとTruePeak
 JPPA資料によると4kHzくらいならリアルサンプルとインターサンプルの誤差は0.3dB程度のようです。フルスケールになるような周波数は5kHz程度までと仮定すると、OSDFかける前に0.5dB程度絞ればかなりのTruePeakは防げるのではないかと思います。まあ、実際の楽曲では複数の波形(周波数)が重なるのでカンペキに防ぐことはできないでしょうけれど。

 ここで思い出されるのが、DSDにおける「MaxPeak」について調べてた時、同じファイルでもPCM→DSD変換再生よりPCM再生の方が0.4~0.6dBほどレベルが低かったことです。
 もしかすると、DACユニットはPCM再生モードではTruePeakを考慮し、「OSDF前段のAttenuation機能で0.5dB絞る」ようにDACチップを設定しているのかも知れません。
 定かではありませんが…


メインメニューへ

テーマ : オーディオ
ジャンル : 趣味・実用

最新記事
ERIへようこそ

Author:らかせ
「最新記事」または
「メインメニュー」からどうぞ

・ファイルへの直接リンク以外はリンクフリー(連絡不要)です

・一応、拍手にコメント(非公開)付けられるようにしてあります

・DB的に利用しており、過去記事もガシガシ書き換えています。特に「最新記事」は初稿から一週間くらいは直してることが多く、大幅に変わっちゃうことも。ご了承ください

・ということもありますし、記すまでもないですが無断転載(ファイル含む)はご遠慮ください

・引用の考え方については「007:諸事」をご参照ください

・アフィリエイトはAmazonのみです

・ハイパーリンクは当Blog記事のみです(054:節電記事のみ例外)

カテゴリ
検索フォーム
FC2カウンター