ゲームオーディオのオーディオファイルは、当初より圧縮する必要がありました。私たちが夢見るような壮大なオーディオ環境を、そのまますべて非圧縮のオーディオサンプルとして保存するディスクスペースやメモリが充分でないことは、いまも変わっていません。このガイドはゲームに最適なオーディオエンコーダの選択を補助するためのものです。

どのコーデックにも長所と短所があります。各場面で使うべきコーデックは、必ずしも明確ではありません。すべてのプラットフォームにとって唯一の正しい選択肢があるわけではないことを、まず理解しておくことが重要です。実は1つのプラットフォームの全サウンドタイプに対応できる、1つの正しいコーデックさえありません。万能の解を求めない方がよいと思います。

Wwiseでサポートされるコーデックの詳細情報が不要な方は、最後のセクションに簡単な選択ガイドを掲載していますので、そこまで飛ばしてご覧ください。

圧縮とパフォーマンス 

WwiseがサポートするソフトウェアコーデックはPCM、ADPCM、Vorbis、Opusの4つです。これらのコーデックを利用する最大のメリットは、プラットフォーム間における一貫性です。全く同じ品質、相対的なパフォーマンス、そして動作をすべてのプラットフォームにおいて確保できます。ソフトウェアコーデックはWwiseのオーディオソースに対する機能セットをすべてサポートし、この点がハードウェアコーデックと異なります。

さらに各ゲームコンソールにはハードウェアオーディオプロセッサが付いています。それぞれ機能が異なり、プラットフォーム間で等しくありません（制限内容については後述します）。Wwiseは圧縮されたソースのハードウェアデコードに対応しており、それ以外のハードウェア処理が提供されているプラットフォームにおいては、Wwiseが対応している場合もあります。

「クオリティ」という用語について

はじめにオーディオの品質（クオリティ）に関して、残念な事実を述べたいと思います。オーディオの品質は主観的だということです。オーディオの良し悪しを教えてくれる公式や数値などは1つもありません。ただし、不完全ながらも代用品はあります。コーデックのパラメータを設定する際、最も重要となるのがQuality/Bitrateという設定です。この設定を選択する際、設定の具体的な意味に留意する必要があります。

Quality設定は「可変ビットレートのコーデック」で使用し、通常は単位がありません。Quality設定は複数の内部的なルールやパラメータを取りまとめた設定であり、この設定の結果、周波数スペクトルの各セクションに多めのビット数が配分されたり、少なめのビット数が配分されたりします（画像の解像度のように）。サウンドの周波数スペクトルは時間とともにが変化するため、サウンドは非常によく圧縮できる部分もあれば、あまりよく圧縮できない部分もあります。ほぼ無音状態の1秒間はかなり圧縮できる一方、ヘビメタ音楽の1秒間はそれほど圧縮できないことが容易に想像できます。

「固定ビットレートのコーデック」で使用されるBitrateは、文字通りオーディオ1秒を再構築するために1秒間に読み込むビット数です。サウンドを再構築するための情報が多い方が、オリジナルに近いサウンドを再現できます。時間の経過とともにオーディオ情報の量が変化するようなサウンドを、どうすれば毎秒同じビット数で圧縮できるのかと疑問に思うかもしれません。答えは簡単です。スペクトルの解像度を時間と共に変え、常に同じビット数を使用するのです。つまり無音に近い1秒間はこの部分に使用できるビット数が過剰にあるため、必要以上のビット数を使用してエンコードされます。逆にヘビメタ音楽の1秒間は再構築するデータ量が多いにもかかわらず、それを表現するために使用できるビット数が限られるため、解像度が低くなります。実はファイルサイズの観点で、ビットレートに制約のあるコーデックは無駄が多く生じます。ほかにもさまざまな技法が適用されますが、説明していると記事の目的から逸脱してしまうため、ここでは単純化した例を用いました。

つまり「variable rate/constant rate」プロパティを「constant quality/variable quality」と考えることもできます。最近のコーデックは一般的に非常に高度な心理的音響モデルが備わっており、低音質の設定においても多くのサウンドタイプの耳障りなアーティファクトを防止してくれます。耳障りというのはオーディオファンでなくとも「低品質のオーディオ」（丁寧な言い方をすると）と感じてしまう、はっきりとした邪魔なアーティファクトのことです。私たちは当然、何としてでもこのようなアーティファクトを回避したいわけです。

圧縮によるアーティファクトの中には「再現の忠実性の損失」とも言えるカテゴリに属する種類のものが多くあります。具体的には圧縮サウンドがオリジナル音とやや違い、聞いて分かるものですが、両者を比較してはじめて気づくような違いです。意識していない人にとって、どちらがオリジナルなのかは分からないかもしれません。このような圧縮アーティファクトはプレイヤーをゲームから引き離すことがないため、全体的なオーディオエクスペリエンスの観点において、さほど重要ではありません。

サウンドによって、オリジナルに忠実であることが重要である場合もあります。その1例が音楽ですが、特に音楽を聞く耳をもつ視聴者にとって、フィルタや周波数のゆがみは明確に分かります。正反対の例として、爆発音や足音などは再現性が忠実でないとしても、耳障りなエフェクトがない限り、オリジナルとの違いに気づく人はいないでしょう。サウンドが個別、あるいはフルボリュームで再生されることがほとんどないことも忘れてはいけません。結果的にスペースやCPUに余裕が必要な時に備え、忠実性の低さはヘビーなミックスで簡単にカバーすることができます。まずはじめに、サウンドカテゴリごとに品質またはビットレートの設定を選び、必要に応じて微調整してゆくというのが、取りかかり方法として容易かもしれません。ビットレートが一定であるコーデックを使用する場合は、サウンドのヘビーな部分に対応できるよう、ある程度の余裕（高ビットレート）を確保しておくようにしてください。

圧縮率

圧縮率とは単純に元のファイルサイズに対する最終的なファイルサイズの比率です。オーディオコーデックの場合、計算に含まれるのはWEMコンテナやマーカを除いたファイルのオーディオサンプル部分だけです。事前に行ったダウンサンプリングも除外されます。下表は各コーデックの圧縮効率を比較したものです。可変品質コーデックではオーディオの中身と設定が、結果に大きな影響を及ぼすことに疑問の余地はありません。

コーデック	圧縮率	可変ビットレート（VBR）/固定ビットレート（CBR）
PCM	1:1	Constant（固定）
ADPCM	4:1	Constant（固定）
Vorbis	2:1 - ~40:1*	Variable（可変）またはConstant（固定）
Opus	2:1 - ~60:1**	Constant（固定）
XMA	6:1 - 15:1	Constant（固定）
ATRAC9	8:1 - 13:1	Constant（固定）

(*) 選択した品質やオーディオの内容によります。上限に達することはほぼありません。
(**) Vorbisの注意書きと同じですが、ボイスコンテンツ（ナローバンド）や一部の調和のとれたコンテンツ（音楽）では、比率がはるかによくなります。

CPUパフォーマンス

下表はソフトウェアコーデックの性能をスループットという観点で示したものです。言い換えると、1つのコアでリアルタイムにデコードすることのできる最大ストリーム数です。この数値に含まれているのはデコーダ自体だけであり、リサンプリング、ボイスマネジメントのオーバーヘッド、割り込み、メモリバスのボトルネックなどは含まれません。つまりデコーダを隔離し、最良の条件下で見ていることになります。最高パフォーマンスの目安を示すための表ですが、実際のゲーム環境においてこの上限に到達する可能性は低いです。スループットをハードウェアコーデックが対応する最大ストリーム数（後述）と比較することができます。VorbisとOpusの場合、3つの数字は最低品質、デフォルト品質、最高品質の設定を表し、パフォーマンスの範囲全体を示します。

最大ストリーム数

プラットフォーム	ADPCM	Vorbis（低 - 中 - 高品質）	WEM Opus（低 - 中 - 高品質）
Mac1	10700	7500 - 5900 - 3100	1600 - 1200 - 700
モバイル2	8600	5200 - 4300 - 2100	1100 - 800 - 500
PC3	9500	5700 - 4600 - 2300	1300 - 1000 - 500
PS4	3200	1200 - 1000 - 500	300 - 200 - 100
PS5	7600	5900 - 4700 - 2500 (SW) 80 (HW)	80 (HW)
Switch	2000	600 - 500 - 300	200 - 150 - 100 (SW) 20 (HW)4
XboxOne	10000	1000 - 3400 - 1200	300 - 200 - 100
XboxSeriesX	9200	6900 - 5400 - 2800	300 (HW)

1. Mac M1
2. ARM64 Cortex A9
3. Core i7 （2018年頃）
4. ソフトウェアOpus（WEM）を使用。ハードウェアデコーダはわずかに異なるコーデックOpusNXを使用。次セクション参照。

ハードウェアの制約

コーデックのハードウェア実装に結び付いている特定のWwise機能がいくつかあります。ハードウェアが対応していない場合、それをWwiseがソフトウェアでエミュレートしようとしますが、コストが伴いまったく不可能であればエラーが報告されます。以下に機能の対応の可否をプラットフォーム別に示します：

• SA Loop（サンプルアキュレートループ）：ネイティブコーデックのブロックの長さにかかわらず、同じストリームの任意のサンプルでループを開始・停止できる機能。WwiseのLoopチェックボックスに相当します。
• SA Trans（サンプルアキュレートトランジション）：ネイティブコーデックのブロックの長さにかかわらず、サウンドを任意のサンプルで停止し、別のストリームの任意のポジションにジャンプする機能。Wwiseの« Sample accurate transition »モードのRandomコンテナやSequenceコンテナに使うと便利な機能です。
• 可変リサンプリング：サンプリングレートまたはピッチをサウンドの長さ全体において、ダイナミックに変化させることのできる機能。

下表にハードウェア機能の対応をまとめました。対応していない場合、追加のコストのもとソフトウェアで実現させます。

コーデック	PF	HW?	SA Loop	SA Trans	可変ピッチ	最大カウント
PCM	すべて	No	Yes	Yes	Yes
ADPCM	すべて	No	Yes	Yes	Yes
Vorbis	すべて1	No	Yes	Yes	Yes
	PS5	Yes	Yes	No	Yes	80
Opus	すべて1	No	Yes	Yes	Yes
	PS5	Yes	Yes	No	Yes	80
	XBX	Yes	Yes	Yes	Yes	300
	Switch	Yes	Yes	No	No	12 - 243
XMA	XB1	Yes	Yes2	No	No	128
	XBX	Yes	Yes2	No	No	128
ATRAC	PS4	Yes	Yes	No	No	60 - 5003
	PS5	Yes	Yes	No	No	120 - 10003

1. すべて、ただし下の指定プラットフォームを除きます
2. XMAのループが可能となるのは、128サンプルバウンダリのみです
3. 最大とはチャンネル数、ビットレート、すべてのアクティブサウンドのグラニュラリティによって変わります。合理的な最大は、ミッドレンジです。

ハードウェアのレイテンシ

ハードウェアアクセラレーションは通常、DSPコプロセッサを通して行います。このため、ほかのCPUと同様にデータを処理する必要があり、瞬時ではありません。実際のメリットは、メインCPUとの並列性にあります。残念ながらDSP自体はコンソールに搭載される最先端のCPUと比べ、動作がはるかに遅くなります。

この並列性を活かす方法は、同一フレーム内処理と遅延処理の2つがあります。モードを制御するのはbLowLatencyHwCodecフラグです。最初のモード（Trueの設定）は分かりやすく、ハードウェアとソフトウェアのソース間に遅延が発生しません。圧縮されたデータはデコーダに送られ、Wwiseはハードウェアが結果が出たとの信号を出すまで、その他のソフトウェアソースを処理し、ない場合はCPUをyieldします。次に結果を処理して同じオーディオフレーム内でミックスし、ほかのソフトウェアソースと同期させます。レイテンシは追加されません。Wwise Profilerに表示される処理時間は、yeild時間（CPUがほかのタスクに移行することのできる時間）が含まれる分、長くなります。ただしすべてが同期されます。

もう1つのモードはbLowLatencyHwCodec がFalseの時で、データは1つのフレーム内でデコンプレッサに送られますが、その結果をフェッチするのは次のフレームとなります。これにはDSPの処理時間を完全に隠せるという大きなメリットがあります。ただしすべてのサウンドが1フレーム分だけ遅れるため、ソフトウェアとハードウェアのサウンドのミックスを同期させる必要のある場合や、非常にタイトなレイテンシ要件のあるゲーム（リズムゲームなど）においては、問題が発生する可能性があります。全体的なシステムパフォーマンスの観点では、こちらの方が望ましいモードです。

結論としてハードウェアデコーディングはCPUをほかの作業のために解放できる方法ですが、絶対値的にCPUよりも多くの生オーディオを処理できるわけではありません。ただし並立性を最大化するために、ハードウェアソースとソフトウェアソースをミックスすることができます。

ハードウェアデコーディングはコストがない？

簡単に言うと答えは「ノー」です。最新世代のコンソールであっても「ノー」です。ハードウェアデコーディングのコストは、生のCPUサイクルとは違うかたちで現れます。ハードウェアデコーダの物理的な実装はプラットフォームによって大きく異なり、ドライバの実装、OSのインテグレーション、利用可能なAPIも違います。このためコーデックのコストの比較が難しくなります。ただし共通するコストもいくつかあります。

多くの場合、デコーダに命令を送るAPIはカーネルのバウンダリを越えるため、コストが発生することがよくあります。一部のプラットフォームではコマンドがスレッド同期で保護されているキューにポストされ、ここでしばらくストールすることがあります。場合によっては圧縮された入力ストリームを含むメモリを、ハードウェアデコーダから見えるメモリに転送する必要があり、これがメインメモリと異なることがあります。オーディオ出力に関しても同じことが必要かもしれません。出力形式がサウンドエンジンのほかの形式と一致しないこともよくあり、コンバージョン段階が必要となります。ハードウェアによってはバッチ単位で処理するため、バッチ全体が完了しなければ結果が出ないことがある一方、準備ができ次第結果を返すものもあります。

一般的にこのようなコストがあるため、非常に小さいサウンド（目安として100ms未満）にハードウェアコーデックを使うことは適していません。短いサウンドは使用頻度、長さ、プラットフォームなどによって、純粋なソフトウェアデコーディングよりコストが高くつく可能性があります。特に注意すべきサウンドはTrigger Rate方式で出される非常にドライな（短い）足音、衝撃音、繰り返しの銃器音などです。Random ContainerやSequence Containerでサンプルアキュレートなトランジションを通して作成されるグラニュラーシンセシスも、ハードウェアコーデックではリスクが高くなります。

各コーデックに関する補足説明

PCM

PCMは単純に非圧縮のメディアであるため、利点はスピードだけです。非圧縮のため、主な短所はディスクスペースとメモリスペースです。これが唯一推奨されるのは、性能の低いプラットフォームにおける、使用頻度の高いサウンドです。PCMがほかの選択肢よりも好ましいと考えられるプラットフォームは、いまどきありません。

ADPCM

ADPCMは昔のコンソールのはじめての手ごろなコーデック（CPU観点で）の1つとして、ゲーム業界で知られています。圧縮率は4:1の固定で、デコードが非常に速いです。最大の欠点は品質が不安定なところです。明らかなトランジェントや非常に高い周波数のサウンドでは、耳に聞こえるアーティファクトが発生します。ただしこれは例外的なケースであり、ADPCMはいまでもよく使われています。

Vorbis

音響心理を用いた汎用のコーデックであり、人間の耳や脳の特性を利用し、アーティファクトを最小限に抑えながらオーディオを圧縮します。このコーデックがゲームで使われるようになったのは、優れたオーディオ品質と高いファイル圧縮率のためです。圧縮率は非常に可変であり、オーディオ信号によって異なります。対応範囲は2:1（ワイドバンド信号で、最高の音質）から、40:1（ナローバンド信号で、最低の音質）までの広範囲です。このコーデックのWwiseの実装は何度も最適化されており、現在の平均CPUコストはADPCMコーデックの約1.5倍から3倍です。

Vorbisは可変ビットレートコーデックであり、圧縮率はファイルの中身に依存します。一般的にサウンドが大きいほど達成できる圧縮率が低くなります。さらにCPUコストは使用するQuality係数に直結しており、品質が高いほどデコードに必要なCPUが増大します。

このフォーマットでシーク操作、Virtual VoiceのFrom elapsed timeオプション、Interactive Music機能セットなどに対応するためには、シークテーブルが必要です。シークテーブルの使用は任意で、機能を使用しない場合はコストを回避できますが、一般的に有効にしておくべきです。シークテーブルのコストを下げるために大きいグラニュラリティを使用することは、ほとんどの場合に可能です。

このフォーマットは少量のメタデータのオーバーヘッドがあります。これは非常に小さいファイルに影響します。基本的に50msより小さいサウンドは、必要以上に大きくなる可能性があります。

Opus

品質とファイルサイズの比率はOpusがトップです。Vorbisの後継であり、圧縮率が大幅に改善されています。主観的なリスナーテストでは、知覚される品質がVorbisよりやや高いという結果が出ています（ https://opus-codec.org/comparison/ 参照）。このため品質を保ちつつVorbisよりも優れた圧縮率を達成できます。しかし高いCPUコストが伴い、速度はADPCMの5倍から10倍ほどかかります。

Opusは小さいファイルにとって、最適なフォーマットではありません。アルゴリズムを正しくセットアップするために数ミリ秒のデータが必要となり、約80msほどのオーディオがファイルに追加されます。同程度の長さの小さなオーディオ破片にOpusを使うと無駄になります。サウンドが200msより小さい場合は、基本的にVorbisやADPCMを使います。

XMA

このコーデックが提供されるのはXboxプラットフォームだけです。Xbox360以来、ゲームで使いこなされています。主な利点はハードウェアでデコードされることです。ただしハードウェア自体が特に高速ではなく、128ストリーム（チャンネル）という制限があります。また一部のオーディオコンテンツがこのアルゴリズムではよく圧縮されず、アーティファクトが聞こえることもあります。 幸いこれは例外的です。最後になりますが、このフォーマットはループポイントが128サンプルの倍数に制限されるため、CPUに戻らずループをサンプルアキュレートにつなぎ合わせることができません。

ATRAC9

このコーデックを利用できるのはPlayStationプラットフォームだけです。必ずハードウェアでデコードされます。エンコーディングの設定によっては、一部のサウンドにアーティファクトが発生することがありますが、設定を変更することで問題を解決できることがあります。幸いアーティファクトも一般的ではありません。

適切なコーデックを選ぶためのガイド

タスクに適したコーデックを見つけることは簡単ではありません。何を重視するのかによります：品質？速さ？ファイルサイズ？ほかのサウンドとの同期？当然プラットホームによっても選択肢が変わってきます。

品質vsファイルサイズが1番（同じ品質で最も小さいファイルサイズ）：Opus、続いてVorbis

品質vsスピードが1番：PCM（当然ながら）、それ以外ではVorbisがソフトウェアデコーディングで最高の品質を最速で提供します。Opusがハードウェアで提供されている場合は、これがベストです。

生のスピードで1番：PCM、続いてADPCM。もちろんハードウェアコーデックがサポートされ高レイテンシモードで使用する場合は、そちらの勝ちです。

デフォルトのコーデックとして私がおすすめするのはVorbis、またはハードウェアで利用できる場合は中程度の品質レベルのOpusです。

使いたいコーデックと設定をはじめにサウンドのサンプルで試し、アーティファクトの確認を注意深く行った上で、サウンドデザインの1つのセクション全体をそのコーデック設定に決めた方がよいでしょう。

基本的にはハードウェアコーデックとソフトウェアコーデックを混在させることが最良のスループット、すなわち最短時間で最大数のサンプル処理を達成するための秘策です。CPUがソフトウェアファイルをデコードしている間、ハードウェアが並行して作業を行うことができます。ソフトウェアソースがない場合、ハードウェアデコーダの速度に制限されてしまい、これは必ずしも速くありません。

ボイスオーバー

最近のゲームでは一般的に大量のVO（ボイスオーバー）ファイルがあります。従ってVOのサイズを最小限にすることが目標となります。この場合、Opusはソフトウェアでデコードされる場合においても最良のコーデックです。Opusには人間の声の圧縮に特化したサブコーデックがあります。通常は同時にアクティブになるVOが1つまたは2つ程度であり、デコードのコストは限定的です。もちろん、ハードウェアでOpusがサポートされている3つのプラットフォームにおいては問題ありません。

銃声、衝撃音、その他の短いグラニュラーサウンド

この種のサウンドはゲームで非常に頻繁に再生され、多くの場合、ファイルのサブセットを繋ぎ合わせてバリエーションを増やしています。このようなファイルは短いため、圧縮率が高く各種プラットフォームですばやくデコードできるVorbisが最良の選択と思われます。PS5やXboxSeriesXではOpusを検討することもできますが、ファイルサイズを優先して最適化する場合は無駄があります。ローエンドのモバイルでは、窮地に追い込まれて追加のCPUサイクルが必要な場合などで、ADPCMを検討してもよいでしょう。

一般的なSFX

長めのSFXを使用する場合は、ハードウェアコーデックが使用可能であれば推奨します。お使いのプラットフォームでサポートされていない場合は、Vorbisがよい選択肢であり、CPUに負荷がかかり過ぎる場合はADPCMを検討します。

アンビエンス

バックグランドのアンビエンスサウンドは、ループ音にさまざまな長さのディテールサウンドを追加してつくられることが多いです。デザインにもよりますが、かなりの数が再生されることがあります。ハードウェアコーデック対応のプラットフォームにおいては、それを使ってください。そうでない場合はVorbisが適しています。

音楽

Opusは音楽を念頭に設計されたコーデックであり、最良の選択です。音楽が非常に複雑で多くのレイヤーが同時に再生される場合、ソフトウェアでデコードした時にOpusはCPUに負担をかけるかもしれません。すべてのトラックがハードウェアでデコードされるのであれば、ハードウェアコーデックが適しています。ソフトウェアとハードウェアでデコードしたミュージックトラックをミックスすると同期が難しくなるかもしれません（前述のハードウェアレイテンシのセクションを参照）。Vorbisが2番目に適した選択です。

最後に

コーデックについて私からの最も簡単なアドバイスは、「あまり気にしないこと」です。少なくともプロジェクトの最初のうちはそうです。手はじめにすべてのソースで汎用的なコーデックの中程度の品質からはじめて問題ありません。幅広いカテゴリのサウンド用に、3つまたは4つのConversion Sharesetを定義しておく方法もあります。プロジェクトが順調に進行し、デザインのパフォーマンスの感覚がつかめてきてから、プロファイリングを開始して必要に応じてコーデックを変更することができます。Wwiseは階層のどのレベルにおいてもConversion Settingsをオーバーライドすることができるため、サウンドデザインの特定のセクションで特別なコーデックを使用することは簡単です。

聞こえがよくバジェット内に収まっているのであれば、コーデックをあまり気にしなくてもよいと思います。音がよくない場合、微調整のオプションが多数あることを忘れないようにしておきましょう。