DCオフセットの話

Acousticaのレビューやその他の記事にも何度か記してきたDCオフセット。
実は先日、授業でも取り上げてみた。

ここ数年ミックスの依頼が増えてビクつきつつ引き受けるのだけど、DCオフセット除去していないデータを受け取ることが多かった。
受け取った一群のオーディオファイルから1つ抜き出してDCオフセットのズレを測定(検出)して引っかかると、Oh…こちらで処理しなきゃダメか…と溜息が漏れる。
バッチ処理で行うからそんなに苦でもないのだけど、近年なまじっかハイレートでのレコーディングが流行ってるぶん処理待ち時間もそれなりに膨れる。

こうしたエラー対応はやれる人がやりゃいいじゃんというのももっともだけど、流通に乗せる製品は製造工程で多重にチェックを行ったほうがいいよね。
某社で働いてた頃は厳しかった*もんだが、殺伐とした現場から距離を置いて数年、こうしたチェックは標準でなくなったのか、それともデメリットが判明したのか。
なのでこの記事、もしかすると無意味かも。

*正確にいうと、上司はわかってなかったので同僚との間で取り決めた。

DCオフセットとは

DC offset

DC offset

通常、オーディオの波形データって、0の横軸の上半分と下半分とが等量じゃないとエネルギーとしてはおかしい。

だけど録音環境や電気的な影響、あるいは特定の奏法や編集結果(サイン波のちょうど半周期を意図的に切り出した場合とかね;以降’切り出し’を’トランケート’と記す)によっては上下が等量でなくなる場合がある。

経験則になるがズレを含む可能性の高い素材としては、

  • ボーカル
  • 打ち込みドラム(特に一流どこではないドラムのソフトウェア音源は鬼門)
  • サンプルパックの素材

元素材にズレがなくても、ズレを引き起こす可能性のあるエフェクト処理としては、

  • リバーブ
  • アンプシミュ
  • ビットクラッシャー

これらを使ったトラックがあれば要マーク。

一個のオーディオデータに混ざり込んでしまったズレは、最終的に色んなトラックと混ざってツーミックスで書き出されたって消えはしない。残ったまま。
ゴキブリが入ったまま調理されたラーメンからゴキブリを取り除くことはできない、みたいなもん。

生録じゃないならDCオフセットの問題は起きないかといったら全くそんなことはなくて、ソフトシンセにせよソフトPCM音源にせよ、元素材に問題があれば、その音を利用して僕らがダダ打ちした音にも問題が当然発生する
フリーのソフトウェア、新興のメーカーが多々あるけれども、こうした開発や配布にあたって元素材に対して常にトリートメントを施してくれていると考えないほうがいい。
この数年でメーカーが膨大に増えているぶん、問題のある素材も膨大に増えていると考えられる。

なぜ良くないか

DCオフセットがズレている場合の問題

DCオフセットがズレている場合の問題

波形の縦軸フルビット使うのがデータの持ちうる最大値のポテンシャル。
処理を行なう際、DCオフセットがズレているとポテンシャルを活かしきれない
典型例はノーマライズで、たとえば先ほどのスクショでDCオフセットがズレたオーディオデータをノーマライズするとピークが0dBを指しラウドネスは-11dBになったけれども、ズレを直すとピークは0dBでもラウドネスが-7dBまで上がる。
要するにノーマライズしきれないという点、それにピークインジケーターが違う値を指しかねないという点で、イリーガルなデータということになる。
「ポテンシャルを活かせてない」というのはこういう意味。

といっても、ここまでDCオフセットがズレることはまず滅多にない。
しかしいくつものトラックにこれが発生していたり、先ほど書いたように好ましくない範囲をトランケートしたオーディオリージョンが幾つもトラックに貼り付けられていたとしたら結構’あうあう’なことになる。

再度。ゴキブリが混ざったまま調理の仕上がったラーメンからゴキブリを取り除くことはできない。
いや、ピンポイントで逆相ぶつけて消すことはできるけど、地獄か!

どこまで処置すればよいか

原則、曲に使用していないものやNGテイクも含めて、そのプロジェクトで管理されるすべてのオーディオファイルを処理しておきたい。いつ差し替えが発生するかわからんので。
つまりPro Toolsのセッションフォルダをまるごと渡すケースであればそのフォルダに入っている全てのオーディオファイルにDCオフセット除去の処置を施すのが理想。逆に言うと、100%使わないもの(レファレンス音源とか)は入れるな。当たり前だけど。

あとは、処理結果でDCオフセットのズレが生じる場合もあるので、チェックだけはせめてその都度しておきたい。

除去/ブロック処理は各ソフトで同じか

静的に除去する処理と、動的にブロックする処理とは別々に考える必要があるが、ひとまず静的に除去する処理に限定しても、結論をいうとDCオフセットの処理は異なるようだ。ようだ…としか今のところは言えない。
少なくともWindowsのSound Forgeと、MacのLogic Pro Xでは結果が異なった。
どうやらビットの値が0の箇所を除外してズレを測定するケースがあるっぽい。
よって、実は自分の環境でDCオフセットを測定してズレが検出されたからといって、相手が除去処理を怠ったとも言い切れない点に注意しておきたい。

代わりの処理

除去処理も一筋縄にはいかないように思えてしまうが、簡単に防ぐ方法はある。
ローカット。
たぶん(僕が知らないだけという可能性があるのでこう書くが)上に記した動的にブロックする機能はこれじゃないかと思う。

DCオフセットのズレは、限りなく0Hzに近いスーパー低い音が混ざりこんでると考えることもできるので、ローカットすればズレは十中八九なくなる。
低域はなんでもかんでもカットするもんではないという理屈もあるにはあるし、両手を挙げて賛成なのだけど、トピックはそこじゃなくて、スーパー低い音を切ればオーディオデータのポテンシャルを活かせるようになる。

多くのEQは最小が20Hzくらいになってると思う。つまり可聴域の下限。
これより低いと音(Low Rumbleとかいう)としてはほとんど機能しないのでカットしてもおおむね支障はない。
ただ、ローカットすることで全体の波形の形状が変わり、場所によってはクリップが生じるので、リミッターなどの後処理もぬかりなく行っておきたい。

あともう1点だけ補足しておくと、音色次第で、波形データを超拡大表示した時にDCオフセットが一見ズレてみえることがあるけど、そう見えるだけ。
ソフトで検出させてペケにならなければそれでいい。

手順に与える手間、および逆利用

DCオフセットのズレを除去することで本来完全無音の箇所や微小音量の箇所がズルっと上なり下なりにシフトしてしまう。

エフェクトをかけたりトランケートする前にきちんとDCオフセット除去をしておかないと上のような状態になってしまう。
ましてマキシマイズ済みのオーディオデータだと、DCオフセット除去したとたんにクリップする可能性もある(処理するソフトにクリップガード機能くらいついてると信じたいが)。
だからこういうデータが送られてくると、やっぱ溜息が出る。どうやって劣化を最小限に抑えて問題を解決するかっていう。

🔔 トランケート時にDCオフセット除去してから範囲選択してやるか、範囲選択してトランケートしてからDCオフセット除去するかで結果が異なる点にも注意したい(面倒なので説明は省略)。

0じゃない位置に無音がシフトされてしまうことでノイズ・ゲートもかからなくなってしまう点も重要。

というように、手順に与える影響がないわけではないことを補っておく。

最後に、逆利用することができないのかという点で1例だけ。
いま書いたように無音がシフトされてしまうせいでノイズゲートがかからなくなるので、たとえば大量のセリフのオーディオデータにバッチ処理でノイズゲートかける際に、摩擦音での喋り出しや吐息がカットされないように意図的にDCオフセットを少しズラしたりスーパー低い音を加えたりしておいて、あとでDCオフセット除去またはローカットするという手がある。