スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

PCMの「TruePeak」とは何か

15/04/11初稿

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


■TruePeakとは何か

・データがクリップしていなくても再生するとクリップする?
 とある邦楽CD音源のUDA-1出力をアナログサンプリングしてスペクトルを眺めていた時のことです。
 頻度は多くありませんが、22kHz以上の帯域がヘンな表示に崩れることがあります。録音レベルを下げても発生します。DSD変換でも、PCMのそのまんま再生でもアップサンプリング再生でも同じです。フルスイングのサイン波では発生しないようにボリューム調整したヘッドホン出力でも発生します。
 しかし、プレーヤの≪foobar2000≫のボリュームをちょっと下げると発生しなくなります。

 ≪JRiver MediaCenter20≫でも、PCM単純再生、DSD256変換再生共に発生します。

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

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

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


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

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

 以下、発生箇所の例です。
 上がオリジナル、下が2倍アップサンプリングです。

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

*:ただし、このポイントはきっかけになった「スペクトル崩れ」箇所ではありません。
 また、1サンプルのみがフルスケール値になったとしてもピーク潰れとは限りません(本来あるべきレベルはもっと高いのに飽和したのかリアルにフルスケールなのかは判らない)。上記は単純に「アップサンプリングでピーク値が上昇する」例として使っています。
 1サンプルのみフルスケール(フルビット)であることを≪Audacity≫表示にならって「1of1クリップ」と呼ぶことにします。

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

*:本実験は、解りやすくするために2倍で実施しています。

 つまり、PC内でアップサンプリングしなくとも、DACユニット内のデジタル→アナログ変換において

オーバーサンプリングデジタルフィルタ処理=リコンストラクションフィルタ処理によってピークは上昇する

のです。

 「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

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

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

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

 1周期にサンプルポイントが3カ所しかありませんからそれがサイン波のピークを捉えるとは限らず、むしろサンプルとサンプルの間にピークがあることの方が多くなります。
 これが「インターサンプルピーク」です。サイン波なら、一番厳しいのはサンプルリングのちょうど中間がアナログ信号のピークだった時です。本例の場合は位相が30度ズレた時そうなります。波形生成で言うと、周期をゼロクロスからではなく30/360=1/12進んだ状態からスタートしている状態です(自分で作図してみればすぐ解ります。上記資料に図ありますし)。周波数が高くなるほど(1周期のサンプルポイントが少なくなるほど)リアルサンプルピークとの差が大きくなるのが解ると思います。

 上記2448波形は30度ズラして生成したものです。16kHz-3dBのサイン波を48kHzキャプチャした時、たまたま波形とキャプチャ周期のタイミングが30度(1/12周期)ズレた場合のシミュレーションになっているハズです。
 左側の2448では、プラス側振幅は全く-3dBに届いていません。先の資料の通りおそらく-6dB程度低いでしょう。しかし、サンプリング定理に基づいてリコンストラクションされるとキレイなサイン波が再現されるのです。右側の24192は、4倍アップサンプリングすればほぼサイン波が再現できることをシミュレートしていることになります。

 (アップサンプリングなどしない)普通のPCM再生でもTruePeakは発生していると思われます。ので、DACユニット内のOSDF(*)でも上記と同じことが起きているようです(リクツ上その方が納得できます)。

*:Over Sampling Digital Filter

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

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などで音量が上がる可能性がある場合は24bit拡張した後一旦07FFF0hなどにしてから演算すればよいワケです。

 以上、16bitデータを32bit拡張演算して32bitや24bitで再生するような場合、情報量欠損はほぼ発生していないハズですので“ビット落ち”という表現は不適切だと思っています。
 一方、24bitデータの場合、32bitで受けられるDACチップじゃないとDAC-I/Fの段階でビット深度拡張できず情報量欠損となりますから、“ビット落ち”といってもいいでしょう。例えば6dB以上音量絞ったら有効ビットが23bitに減りますので“1bit落ち”です。
 しかしそれって「ダイナミックレンジが144dB→138dBになる“だけ”」です。それを音質劣化と認識できる人はたぶんいない…ていうかそれ以前にその音質違いを表現できる再生装置がない(熱雑音以下?)でしょうから、実効的には無視していいと思っています。逆に、16bitが15bitになっちゃうビット落ちは無視できないと思います。
 ので、「ホントにビット落ち(情報量欠損)しているのか」「落ちてるとしても実効的な音質劣化なのか(それによって得られる効果を上回る劣化なのか)」をよく考えてシステム構築・運用した方がいいと思っています。

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

・≪foobar2000≫の内部処理
 ≪foobar2000 1.3.6≫で実際に32bit内部処理されているかカンタンに調べてみました。ボリュームが一番手軽なのですが、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ですが、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カウンター
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。