画面写真をクリックするとWebGLビルドに飛びます。
こんにちは。技術部平山です。
今日は、デシベル(db)のお話です。どうでしょう?使い慣れてますか?
使い慣れている方は読む必要がないお話です。
Unity屋にとっての音量
Unity上で音量を調整しようとすれば、 AudioSource.volumeに0から1の値を入れます。
0だと無音で、1だと元のデータそのまま、あとは小さいほど音が小さい、というだけの話です。 何もわかりにくさはありません。
また、もう少し詳しいプログラマであれば、 サウンドデータが波を表す値の配列であることを知っているかもしれません。 例えば16bit値で波を表していれば、 -32768から32767までの値がズラッと並んだものがサウンドデータです。 それにAudioSource.volumeの0から1の値が掛け算されて、 スピーカーから出てきます。0.5なら半分にされますし、0.1なら1/10です。
わかりやすいですね。何か問題なんですか?
サウンド屋さんにとっての音量
実は、サウンドのプロの方々は、音量を表すのに 「デシベル(db)」という単位を使っています。 10倍大きいと20増える、というもので、 例えばデシベルが-6だと、音量が半分になります。
| 元の値 | デシベル |
|---|---|
| 1 | 0 |
| 0.5 | -6 |
| 0.1 | -20 |
| 0.01 | -40 |
| 0.001 | -60 |
「何それわかりにくい」
と思いますよね?0.5で何が悪いの?
でも、音のプロにとっては、デシベルの方がずっと使いやすいのです。何故か?
理由は、人間の聴覚特性にあります。
人間の聴覚特性
人間の感覚は多くの場合対数的です。
1000円のランチが500円引きなのと、 100万円の車が500円引きなのと、 違いは同じ500円です。
でも、100万円が99万9500円になっても、 全然うれしくないですよね? 1000円なら半額で50%ですが、 100万円なら99.95%ですから、 比率で見れば全然ありがたみがありません。
このように、人は多くの場合差ではなく比率で見ます。 これは聴覚に関しても同じです。
音のデータの大きさが1から0.1になるのと、 0.1から0.01になるのは、同じような変化と感じます。 両方とも1/10ですからね。 前者は0.9も減っていて、後者は0.09しか減ってないのにです。
スライダー問題
音量の調節をスライダーである場合には、特にこれが問題になります。 0から1のスライダーがあると考えてください。
左端が0で右端が1だとします。 1から0.1に落とした所で、「今下げた分くらいもう一回下げたい」 と思ったとします。もう一回1/10にすればいいので、 0.01にすれば良さそうです。 しかし、調整に使える幅はさっきの1/10しかありません。 さらにもう一回1/10にしようと思うと、 もう1/100しか幅がないので、微調整はほとんど無理です。
このように、 「右の方はかなりいじってもあまり変わらないのに、 左の方はわずかに動かしただけで派手に変わってしまう」 ということが起きます。
しかし、スライダーで調整する時には、 「どこであれ1cm動かした時の変化は同じであってほしい」 のです。デシベルにすれば、かなりそれに近づきます。
第二のスライダーはデシベルで設定するためのものです。 まず0から-12に下げ、次に-24まで下げたとします。 どちらも差は12ですが、 それに対応する元の音量は、「1から0.25」と「0.25から0.625」 です。差は0.75と0.1875で、全然違いますが、 デシベルにすれば同じ幅になるのです。 是非サンプル でいじってみてください。
これが、デシベルが広く使われている理由です。 ほぼほぼ「整数2桁」で調整ができます。
一般的に、調整幅が広い場合には、 デシベルのように対数化した値で調整できるようにします。 そうでないと、0.0001から1、というように調整幅の桁数が 多くなって調整が難しくなります。
例えばグラフィックスでも同じことが起こり、 光の明るさなんかは対数で設定できた方が良いでしょう。 星の明るさと昼の太陽の明るさでは100億倍違ったりします (wikipediaの「等級」のページ参考) 。
「整数2桁」の使いやすさ
音量に限らず、大抵の調整は「整数2桁」でできるようにしておくと便利です。 人間が違いを認識できる段階はそれくらいでしょう。
例えば、敵の攻撃力なんかは、 序盤は5とか10で、終盤は1万、みたいなことになりますよね? 序盤は1の価値が凄まじく大きいですが、終盤は1どころか100 変えても大差ありません。
もしこれをスライダーにして調整させれば、 音量と同じく使いにくい状態になるでしょう。 こういう場合も対数にすればスライダーで調整しやすくなるのかもしれませんね。
実装
相互変換
まず0から1の値とデシベルの相互変換が必要です。 0から1の値にも名前が欲しいので、仮に「リニア値」 と呼んでおきましょうか。
public static float ToDecibel(float linear, float dbMin) { var decibel = dbMin; if (linear > 0f) { decibel = 20f * Mathf.Log10(linear); decibel = Mathf.Max(decibel, dbMin); } return decibel; } public static float FromDecibel(float decibel) { return Mathf.Pow(10f, decibel / 20f); }
リニア値は、10を底とする対数(Log10)を取り、 20を掛ければデシベルになります。 例えば0.1であれば、対数を取ると-1です。 これに20を掛けて-20となります。
この際、Log10(0)はマイナス無限になるため、 一定以上小さい値は最低値に固定してしまいます。 「どれくらいで無音とみなすか」がコード中のdbMinで、 -80あたりが良いのではないでしょうか。
サウンドデータが16bitであれば、-32768から32767で、 -80dbは1万分の1ですから、-3から3までの幅に落ちます。 ほぼ無音と言えるでしょう。 もし完全に0に落としたいのであれば、-90とか-100とかにしても 良いのかもしれません。
幅が狭い方がスライダーの調整はしやすいのですが、 -60くらいだと、スピーカーの音量が大きい時に微妙に聴こえてしまいます。 私が試した限りではありますが、-80で良い気がします。
見える所を全部デシベルにする
あとは、データの運用の話です。 データのパイプラインのどこをデシベル、どこをリニア値にするか、 という話なのですが、私の現状の結論は可能な限りデシベルです。
すなわち、AudioSource.volumeに値を渡す寸前に FromDecibel()を使ってリニア値に変換し、 逆にAudioSource.volumeを外に出す時には、 すぐにToDecibel()を使ってデシベルにしてしまいます。
例えばBGMの音量を設定する関数、 みたいなのを作った場合はデシベルを受け取るようにし、 お客さんが音量調節できるスライダーを作った場合は、それもデシベルにします。 それを端末に保存する時もデシベルで、 効果音の音量をエクセルやスプレッドシートで設定する時もデシベルです。 AudioSourceを直接いじるプログラマ以外にはデシベルしか見えない という状態にします。
複数の設定値の合成
設定値が複数重なった場合は、デシベルを加算します。
例えばある音素材のデフォルトの音量が-6dbで、 あるシーンでそれを-12dbして鳴らす設定で、 さらにお客さんが全体の音量を-6dbと設定しているのであれば、 全部足して-24dbとなります。
これは、リニア値であれば掛け算です。元データが0.5(=-6db)、 シーンの設定が0.25(=-12db)、お客さんが0.5(=-6db)を設定していれば、 全部掛けて0.0625とします。これはデシベルで言えば-24dbでして、 計算結果は同じになります。デシベルの方が足し算で済んで簡単だと思いませんか?
スライダーを作る時に一工夫
デシベルのスライダーを作るのは簡単で、 左端で-80、右端で0、となるようなスライダーを用意すれば済みます。
ただ、-40、つまり1/100以下の領域を微妙に調整したいことは あんまりありません。すごく小さい音から無音の間って、 そんなに調整細かくやらなくてもいいですよね?
「細かく調整したい場所にスライダーの長さを割く」 ことが使いやすさにつながるわけで、 -80から0まで均等に使ってしまうと、-80から-40までという あんまり必要ない場所にかなりの長さが割かれてしまいます。
そこで、もう一工夫してはいかがでしょうか。
とりあえず二乗
-80から-40までの幅よりも、 -40から0までの幅の方が大きくなるように、 さらに変換関数を挟みます。 いろんな方法がありますが、「二乗する」は一番簡単でしょう。
今、-80dbで0、0dbで1である、としましょう。 例えば、-40dbであれば真ん中ですから0.5ですね。 これをこのまま使わず、二乗して0.25にしてからスライダーの位置とします。
どうでしょう?
-40dbで0.25ということは、-80dbから-40dbまでがスライダーの1/4の長さしか 使っていないということです。残りの3/4は -40dbから0dbに使われます。 細かく調整したい上の方により長い距離を使えるので、調整がしやすくなるのです。
コードはこんな感じでしょう。
static float DbToSliderPos(float db) { float pos = (db + 80f) / 80f; //[-80,0]→[0,1] return pos * pos; // 二乗 }
逆に、スライダーからデシベルにする時には、 2乗の逆関数、つまり平方根を取ります。 コードにすれば、こんな感じです。
static float SliderPosToDb(float pos) { pos = Mathf.Sqrt(pos); float db = (pos * 80f) - 80f; //[0,1]→[-80,0] return db; }
お客さんに調整してもらうUIであれば、 これくらいが丁度いいんじゃないかなと思います。
実際、サウンドのプロの方が使うCUBASE 等のサウンド編集ソフトでも、 音量調節のスライダーは下の方が狭くなっています。 こういう工夫はあってもいいのではないでしょうか。
終わりに
このへんの整備は、 データの量産が始まる前にやっておいた方がいいと思います。
開発序盤は音量のことなんか気にせずにダミーデータをテキトーに 鳴らしていて、開発中盤になってからサウンドが合流、 ということは結構ありますよね。
そうなると、サウンド素人なプログラマが サウンド絡みの処理を作り終わってデータ入力パイプラインの 設計まで終わった後に、サウンドの専門家が参加することになります。 効果音のパラメータのスプレッドシートやjson等々も 全部リニア値で指定、みたいなことになっていると、 サウンドの人がまともな調整をするのはかなり大変になります。 「セリフしゃべってる間はBGMを-8dbで」 とかサウンドさんが言っても、それをいちいちリニア値に変換しないと いけなくなってしまうのです。
実は東京プリズンの開発がそうでした。 かなり後になって慌ててサウンドさん向けに デシベルでデバグ用の音量グラフをつけたり、 お客さん用のオプション画面のスライダーを デシベルベースに直したりしたのです(しかも2乗の工夫はしてなかった)。 そして、入力データはもはやデシベルにはできませんでした。
もし、同じように入力データ側をいじれない状況になってしまっていても、 できることはあります。 お客さん用の音量調節UIや、サウンドさん向けの音量デシベル表示くらいは、 後からでもできるはずです。 やっておいて損はないと思いますよ。