各社オーディオミドルウェアSDK
CRIがADX2 LEを公開したので、メジャーどころのオーディオミドルウェアがほぼ全て無料DLのSDKを提供している状況になった。少なくとも、↓で挙げるライブラリは全て無料のWin32 SDKが有る。
ここで挙げないものとしてはRADのMilesがある。古参の(ヒストリは'94年から公開されている - http://www.radgametools.com/msshist.htm )オーディオエンジンでヒストリには.VOCとか懐かしい単語が並んでいるが、現代的なプラットフォームもサポートしている。
オーディオミドルウェア
近年のオーディオミドルウェアはサウンドデザイナとプログラマの分業にフォーカスして進化している。つまり、サウンドデザイナはGUIツールに.wavを並べ、シーケンスやタイミング、パラメタを調整して名前を付ける。プログラマは"サウンド『足音』を強さ100、座標(100,20,0)で鳴らす"と書くだけで良く、ミドルウェアのランタイムライブラリがサウンドデザイナの設計した通りのタイミングで足音サウンドを発生させてくれる。(たとえば、実際の足音サウンドは、足音.wavを複数回一定のペースで再生するだろう。)
この方面の機能に対して最も典型的な機能を提供しているのはWwiseで、fmodやADX2も同じ方向性で追従している。なので見るべきライブラリを一つ選ぶとしたらWwiseを勧める。
しかし従来は、圧縮/展開、ミキシング自体も重要な役割だった。fmodやADXはこの方面によい考察を提供していた。これは、ゲーム機が専用の音源を備えていた時代には大いに意味があったが、近年はCPUパワーがかなり潤沢になったという事情も有るため、重要性は失われつつある。また、BGMやCDの制御も役割だった時代がある。fmodはモジュールやMIDI音楽、CD-DAを再生するためのAPIが未だに存在する。
近年のオーディオミドルウェアは全て3Dパンニング機能を備えている。しかし、何故かHRTFエフェクトのような擬似サラウンドを含むライブラリは無い(例えばWwiseならAstundSoundを買ってこないといけない - http://www.inside-games.jp/article/2013/07/20/68725.html )。
(OS付属のライブラリ)
WindowsにはXaudio2、MacOSには標準としてのOpenALがある。またMacOSではCoreAudioのような強力なオーディオ機能も使うことができる。
どちらのライブラリも、既存のオーディオミドルウェアに相当する機能性は提供している。つまり、複数の圧縮されたストリームを同時に再生したり、3Dポジショニングを処理したりエフェクトを掛けることが出来る。
しかし、これらのライブラリには分業のための考察が存在しないため、発声タイミングの制御等をプログラマが記述する必要がある。つまり、サウンドデザイナを別立てにするならば、タイミングを制御するためのスクリプトやGUIツールを設計して提供しなければならない。このギャップが有るためオーディオミドルウェアに市場性がある。
さらに、Xaudioのようなライブラリには移植性が無い。オーディオミドルウェアの殆どは家庭用ゲーム機を含めたマルチプラットフォームとなっている。(Xaudioはxboxでも使用可能だが。。)
ちなみに、Sonyや任天堂やセガのハードのSDKも、PS/SS以降はそれなりのオーディオライブラリが付属していて、開発環境としても配慮が存在した。例えば開発機にMIDIポートを設けて内蔵音源の発声をサポートする等。音声の展開には未だにハードウェアCODEC(やDSP)が使用されることが有るので、オーディオミドルウェアも"ハードウェアネイティブ"な形式をサポートしていることが多い。
Wwise
- https://www.audiokinetic.com/jp/
- https://www.audiokinetic.com/downloads/ - ネットワークインストーラ経由でインストールする
今年に入って日本法人まで設立したWwiseは近代的なオーディオミドルウェアの典型と言える。Wwiseで特筆すべきなのは、Wwiseツールを接続可能なLIMBO体験版とそのデザインドキュメントがわざわざ付属してくる点だろう。しかも日本語版ドキュメントが提供される。
特徴的なのは、プログラミングの自由度よりもデザインツールのランタイムとしての機能性を充実させている点で:
- プログラムで出来ることが少ない！
「Wwise」の組み込み当初に一番困ったのが「プログラムから何も出来ない」ということです。プログラムから出来るのは「イベントを実行する」ことだけで、最初はとても窮屈に思いました。(「Wwise」にはパラメタ制御など他にも色々な機能がありますが、メインは「イベント」です)
何せ音量を変えるAPIすらありません。サウンドから「ポーズした時にＢＧＭの音量を下げて欲しい」と言われても「そういうイベントを作ってくれ」としか返せません。
対して、fmodやADXはより純粋な(プログラマのための)オーディオライブラリであった時期が有るので、それなりのコントロールがプログラムからも可能になっている。
fmod
- http://www.fmod.org/
- http://www.fmod.org/download/ - FMOD studioとAPIをダウンロードする
fmodはこのエントリがAncient 3dに属する最大の理由だろう。fmodは昔はいわゆるsceneで人気のあるMODプレイヤであって、introのためのmini-fmod等もあった。同じような位置のライブラリとしてBASS( http://www.un4seen.com/ )が有るが、BASSは(家庭用ゲーム機に進出していないのもあってか)fmod程商業的なdesign winは無い。
fmodは"従来型"のオーディオライブラリが順当に進化した形で、MOD再生のような従来のライブラリと近代的なサウンドデザイン環境が同居している。悪い言い方をすればゴチャゴチャでは有るが、歴史的興味のためには見るのも良いかもしれない。
(諸般の事情で個人的にはfmodが一番馴染みがある。)
ADX2
つい先日Win32版が公開されたADX2は、従来CRIが提供していたcodec製品(ADX、HCA)とサウンドデザイナ(CRI Sound Factory/CRI Audio)を統合したもので、他のライブラリに比べてゲーム組み込みへの考察がよく行き届いている。(逆に、Windows版はSound Factoryの登場当時には存在しなかった。)
ADX2 LEでは、ゲーム機向けの情報は丁寧に削られてしまっているのでPC版の状況しか見えない。PC版は音声出力に何故かXaudio2を使用しており、動作にはランタイムを必要とする。
しかし、(fmodにも共通する問題だが、)ビルド統合への考察が薄い。例えばコマンドラインでのバンク構築が無く、バンク情報の大量エディットはCSVでエクスポートしてそれを編集させる等実践的だがもうちょっと、こう、手心というか。。もっとも、WwiseもXMLを食わせる形でコマンドラインでのバンク構築をサポートしているがあまり熱心にドキュメントされていない。
独自CODECは他に例のない特徴で(MilesがBink Audioを載せている以外)、CRIの強みを活かしたシステムになっている。例えばHCA-MXは周波数領域でMIXしてから周波数変換するという非常に男らしいアプローチで圧縮音声の軽量なmixを実現している。
他にブリハマチで有名になってしまった楽曲変調( http://www.cri-mw.co.jp/product/interview/2010/ar-tonelico/page3.html )等の飛び道具も有る。
(内製のライブラリと、オーディオミドルウェアの将来)
サウンドライブラリの内製はそれなりに行われている。ナムコのNUsound( http://www.gamebusiness.jp/article.php?id=6682 )等。
個人的には、この内製傾向は大手スタジオでは今後も続く - つまり、制作フローやゲーム表現のためのカスタムサウンドライブラリはいつまでも必要にされるのではないかと考えている。マルチプラットフォーム対応を考えた場合でもサウンドライブラリは数人規模でメンテナンスでき(fmodだって十数人規模の企業でアレだけの採用がある)、ゲーム固有の表現は相応のカスタマイズが必要になると期待される。
純内製との中間解として、PAL(Physics Abstraction Layer)のような、オーディオミドルウェア向けの抽象化層を作ることが出来ないかと考えている。つまり、ワンショットサウンドの単純再生とエフェクト、3Dポジショニング程度に機能を絞れば個々のミドルウェアの機能差はほぼなくなるので、"とりあえず音が出る"段階での評価がより容易になるのではないかな。と。OpenALやOpenSL程度の機能性しか要求しない領域は確実に存在するので、そのような領域に対して、プラットフォーム独立でコンパクトなライブラリを提供することが求められているように思える。
ゲームエンジンはゲーム以外の応用も注目されているが、オーディオミドルウェアは今のところゲーム以外の応用で良い結果が無い。
オーディオミドルウェアの将来は混迷の中にある。つまり、通常の感覚ではゲームエンジンに吸収されそうなものだが、現実はそうなっていない。物理エンジンを始めとした専門性の高いミドルウェアは生き残る傾向にある(例えば、世間には"ポリゴンの重なりを計算する"ためだけの専用ライブラリ製品が存在する - http://www.umbrasoftware.com/ja/ )ので、同様に生き残る理由は十分にある。しかし、より高度な"オーディオシミュレーション"のためには(ゲームエンジンが内包する)ゲーム環境とのより緊密な連携は必要不可欠になるだろう。
特にfmodやADX2のドキュメントを読むと昔のサウンドライブラリ事情が透けて見える。fmodはハードウェアアクセラレーションのサポートが無くなったことを１段落割いて説明しているし("only 3DS, PS Vita, PSP, Wii and Wii U support FMOD_HARDWARE")、ADX2のドキュメントには『ADX2はゲーム機用でメモリ使用量をギリギリまで節約できるように、機能や再生するデータ内容／データ数に応じてかなり細かく初期化パラメータを指定できるようになっています。結果としてかなり初期化構造が複雑になっていますので、ひとまずは本サンプルの初期化コードをそのまま流用するぐらいの実装が簡単でしょう。』との記述がある。それでいて、fmodやAudioKineticはTrueAudio(AMDのGPU向けサウンドDSP)のサポート企業でもあり、現代のハードウェアでも(旧来の家庭用ゲーム機のような)努力が続けられている点は有る。
その昔、物理演算用にPPUのような専用プロセサが提供されたように、CreativeやnVidia( http://www.nvidia.co.jp/object/soundstorm_jp.html - アーキテクチャ説明のPDFとMP3(!)が有る)はエフェクトや3Dオーディオ等のアクセラレートが可能なDSPを提供していた。しかし、Creativeの最新サウンドカード( http://jp.creative.com/p/sound-blaster/sound-blaster-zx )は"最も先進的なクアッドコアオーディオ&ボイスプロセッサーSound Core3Dを搭載"していながら、エフェクト等のAPI(OpenALやEAX)について"※5 ハードウェアアクセラレーションには対応していません。"としている。では一体何のためにDSPを搭載しているのだろうか*1。。要するに、ハードウェアはオーディオのプログラマビリティをCPUに寄せる傾向にあり、オーディオミドルウェアもその影響を受けることになる。
そして、アーティストツールにより強く依存しつつあるオーディオミドルウェアは、オーディオのプログラマビリティをより制限する方向に行くのだろうか。それとも、(ゲームエンジンにおけるAIモデリングのように)アルゴリズミックな記述をアセットに盛り込み、プログラムもできるサウンドデザイナを要求するようになるのだろうか。
