今日の話は、偶然の産物であり、言い換えれば、運よく何かを発見するといワザの成果です。意図していた場所に着地できず、私たちの研究プロジェクトの進展は支離滅裂に聞こえるかもしれませんが、お付き合いください。このような予想外の発見は、歴史研究をする上で一般的に珍しいものではありません。『 Conker’s Bad Fur Day 』研究プロジェクトが、その良い例です。（Conkerが誰だか知らない人は、 こちらをクリック 。）TwitterでNintendo 64のサウンドシステムについて書きながら生じたシンプルな疑問でしたが、次から次へと雪崩のように謎や手がかりが発生したものの、歴史的な大惨事を危うく回避することができました。「大惨事」とは大げさな表現ですが、この記事を最後まで読めば、納得してもらえるかもしれません。

技術的な「例外」に向かってクローリング

N64のサウンドシステムは、非常に複雑です。専用のサウンドカードも、チップも、プロセッサもないハードウェアが考案されました。各デベロッパは、RCPやRSPプロセッサを使って、音楽やサウンドエフェクトや、最終的には台詞も再生できるように、何とか工夫してゼロからつくり上げるしかありませんでした。当時、N64システムで、サウンド、グラフィック、AI、データ格納などを絶妙なバランスで維持するための技術的なソリューションが、色々ありました。この微妙なバランスから、N64の複雑かつ興味深いサウンド史が生まれたのです。それほど知られていなく、このハードウェアでリバースエンジニアリングをするのは、非常に難しいです。だからこそ、デベロッパのRare Limitedが、 MP3 lossyオーディオ圧縮フォーマットを、 Conker や Perfect Dark などのゲームに初めて採用したスタジオだと気付いたとき、思わず「どうやって？」と考えました。その頃、MP3はまだ新しいフォーマットで、90年代後半は2000年代ほど普及していませんでした。このファイルフォーマットをゲームに統合するとき、絶対にどこかで問題が発生しただろうし、ゲームのサウンド史というパズルのおもしろいピースが潜んでいるかもしれません。情報収集していくうちに、MP3を使っているのはボイスオーバーのみと知り、この圧縮率では音楽は聞きにくかったと思うので、理にかなっています。

私は、とある 技術好きの集まるフォーラム で、 Conker のMP3ファイルをすべて抽出した人がいる、というなんとも気になる昔の投稿を見つけました。オーディオクリップを聞くと、ゲーム中のボイスが、1つを除いてどれも予想通りに聞こえました。抽出したファイルは、Conkerの分を除けば、すべてゲーム中の音と同じでした。メインキャラクターのボイスはスピードアップされているようで、アーティファクトが多く入っていました。多くの例がアップロードされていたので、ファイルを何個か見て、どのファイルでも確かにそうだと、簡単に確認できました。ファイル抽出にどのツールを使ったのかは不明でしたが、あまりにも特徴的な「バグ」だったので、抽出方法が悪くて妙なアーティファクトが発生したのでは、という自分の仮説は、すぐに棄てました。ほかのキャラクターのボイスも一緒に入っているファイルでも、この意地悪な小リスConkerのオーディオだけに、この影響が見られました。テクニカルな能力のない私には、その理由が想像もつかず、友人の @Percight に助けを求めました。彼も私と同じくらい、この問題に引き込まれ、いくつかテストを行って協力してくれることになりました。

@Percight のテストでも、最初の謎は解けませんでしたが、おもしろい情報を収集できました。この不思議な音響現象を解明するうえで一番のネックは、ファイルを取得したときのデコンパイル、抽出、解凍の各種ツールの情報が欠けていたことでした。[注（文書を整理して保管していくアーキビストとして）: どのツールを使ったかという情報は、特に非公式のツールの場合、とても重要です。ファイル抽出ツールは推測できても、使ったバージョンを知る由はなく、問題がそのバージョンに起因するのかを確認することもできません。] 私たちは、MP3の読み込みに使うツールによって、Conkerのボイスが違ってくることに気付きました。MP3ファイルをWAVに変換し、ツールAcousmographeを使ってスペクトログラム分析を行いました。このMP3はバグや雑音だらけで、WindowsのデフォルトプレイヤーでConkerを聞き取るのは不可能でしたが、WAV版はスピードアップしているように聞こえました。ちょうどその時、フォーラムの元々の投稿で言及されていたクレイジーな考えが浮かんだのです。もし格納場所を節約するために、Conkerのボイスを意図的に速めていたとしたら？ゲームで一番おしゃべりなキャラクターなので、占領するデータスペースも大きいはず。N64のカートリッジスペース（当時64MBでつくられた最大のもの） をサウンドが占拠しないための、裏技だったとしたら？

となると、なぜ全キャラクターのボイスを加速化させてスペースを節約をしなかったのか、という疑問が残ります。仮説段階では、すべの仮定が重要です。

ここでConkerの声を聞いてみてください。CW: ランゲージ。

過去の手がかりから

技術的な分析の結果、クレイジーなことを考えました。一体誰が、ゲームでスペースを確保するためにサウンドをスピードアップさせるのか？自説を確認する方法もなかったので、私たちは過去をもう少し探ることにしました。ビデオゲームの歴史の有利なところは、制作者たちの多くがまだ健在であること。クリエイターたちに直接、仕事内容について聞き、彼らの知識と経験を記録することができます。ゲーミング業界では優れたコンファレンスが多く開催され、当然のように 思えるかもしれませんが、こういった具体的な記憶もすぐに薄れるので、手遅れになる前に聞く必要があります。私たちはTwitterで Conker のコンポーザーのRobin Beanlandからすぐに有益な情報を得られ、実にラッキーでした。ボイスオーバーにMP3だけを使うと、24～40kb/sの低ビットレート（高い品質は歌に使用）では、これ以上すると聞き取りづらくなります。彼は、私たちの仮説の「省スペース目的」など聞いたこともなく、納得しませんでした。また、Conker はRare Limitedが初めてMP3を使ったゲームだったということも教えてくれました。リリース前にコードを『Perfect Dark』の開発チームに渡し、彼らにも使えるようにしたそうです。これだけでも、当時の仕事の内部事情が分かり面白いです。

ほかにもサウンドの詳細として、例えば当時はMP3の解凍・実行をゲームプレイシーケンス中にADPCMと並行して行えなかったことを知りました。このため、ゲーム中に音楽が大事なとき、例えば「Great Mighty Poo」の歌などでは、フォーマットを変更しています。シネマティックシーンではChris Marlowの声（Great Mighty Pooの声優）にMP3を使っていますが、ゲームプレイのシーケンス中の声は、ADPCMです。彼の喉にトイレットペーパーを投げ込むには、いつ彼が歌っているのかを分かる必要があります！さて、妙にスピードアップしたボイスに話を戻すと、Beanland氏はメモリ節約のために検討したことはないと教えてくれただけで、それ以上は知りませんでした。この新しい情報を基に、@Percight はもう少し探りを入れることにしました。@PercightはFoobar2000と会話を始め、Checkmate MP3 Checkerで分析を進めましたが、いつもエラーレポートが出ました。少なくとも、常に表示される “unidentified bytes'' と “invalid header values'' からは、MP3がカスタマイズされたもので、Conkerが話すときのヘッダが独特だ、ということが分かりました。以上で私たちの研究アドベンチャーを終わらせても良かったのですが、数週間後にこのプロジェクトについて、月次で開催されるInteractive Audio Montreal（IAM）の会合で話し、 Plogue 創設者のDavid Viensと共に発表をしたところ、新たな炎に火がついたわけです。

この話は、歴史家やアーキビストがよく疑問に思うことの、典型的な例です。私がプロジェクトをIAMの場で紹介したのは、ゲームのサウンドを、背景状況と切り離して、サウンドチームの視点を取り入れずに理解しようとすると、大きな間違いを起こしかねないことを伝えたかったからです。発表を終えると、何人かのサウンドのプロから、実に興味深い話を聞いたのです。メモリスペースを確保するためにボイスオーバーをスピードアップさせることは、数年前に実際に行われていたようです。また、ミュージックコンポーザーは仕事を納品してしまえば、あとは自分の作品やサウンド全般に何が起きるのか、知らないとのこと。実装専門の担当者が、コンポーザーの知らないところでたくさんの技術的な処理を行うので、彼らもすべての謎に答えられないのです。偶然にあったこのフィードバックで、かえって疑問点が増えました。するとたまたま、それから間もなくして、フランスの技術雑誌『Canard PC Hardware』からN64サウンドシステムの記事を依頼されました。この話を完結させる絶好の機会でした。

技術的なお話 ー“MyButt.mp3” を理解するー

リスと敵が早口の汚い言葉で言い合う部分を抽出した『Great Mighty Poo』ダイアログの、とても下品な会話からとった名前のMP3ファイルを@Percightが分析した結果、台詞のスピードアップ問題がさらに明らかになったので、細かい技術的な話が好きな人のために紹介します。Conkerのボイスに対応する一部のフレームに、特定のヘッダがついています。いわゆる通常のボイスに使われるのは 0xFF 0xF3 0x50 0xC0 ですが、リスのボイスのヘッダの、最後のバイトだけは違い、 0xFF 0xF3 0x50 0xC8 なのです。“Copyright” 情報に割り当てるべきビットにおいて、0000を1000に変更していることを表します。ここまできて、このビットがCopyrightの目的にあるとは、考えにくいです。以下に示す通り、 “1” はフレームの終わりと次のヘッダの始まりの間にデータが追加されたことを表しますが、この情報に必ずしも著作権情報は入っていません。

不思議とスペクトグラムには何も表示されませんが、声優たちが違うマイクを使った可能性があります。

もう一つ、気になることがありました。Conkerのボイスに関連するすべてのフレームに、同じヘッダが使われているわけではありません。ほかのファイルでは違うので、さらに実験しました。@Percightはファイルを安定させようと、例外的なヘッダからくるフレームを、削除しようとしましたが、音がひどくなってしまいました。オーディオプレイヤーが読み込みを速くする代わりにデフォルトフレームを無視するときと似た結果でした。サウンドの一部をカットして、Conkerのおしゃべりを無意味な音に置き換えることで、一部のデータを削除していることに私たちは気付き始めました。次に@Percightは、すべての “0xC8” を “0xC0” ヘッダに変えて、ファイルが普通のコンスタントビットレートののMP3に見えるようにしたところ、予想通り、何も変わりませんでした。でも、試してみて良かったです。

最後に一つ、探ってみたい疑問点があり、それは例外的なフレームがファイルを重くしていることです。Conkerのファイルは、ほかのヘッダを使うファイルよりも、9バイトだけ長いのです。それぞれの中にある9バイトのグループを抑制しようとしたところ、魔法のように、そのファイルが完璧に読み込めました。省スペースの仮説は、これで完全に否定されました！

オーディオソフトウェアエンジニアのおかげで、解決

Conkerのボイスが変えられた原因を、ようやく @Percight が見つけたところで、あとは追加されたバイトの目的を探るだけでした。これらヘッダの非常に特徴的なパターン（ 0x4C 0x3A 0x01 0xXX 0x80 0x80/0x81 0xXX 0xXX 0x00 ）を見る限り、明らかに、意味もなく存在しているわけではありません。オーディオデコーダが正しく読み込めないので、サウンドに無関係の理由があるのかもしれない、と私たちは考え出しました。考えられる理由が多いので、実際にプロジェクトに関わった人でないと、この最後の疑問は答えられません。研究記事の締切りが近づく中、当時このプロジェクトのオーディオソフトウェアエンジニアであったMike Curringtonと、なんとか連絡がとれました。彼は私たちの質問にとても親切に答えてくれて、このパズルの最後のピースを提供してくれました。

Conkerというキャラクターは卑猥なおしゃべりをするリスというだけでなく、私たちがヘッダはオーディオに無関係だろうと推測したために見過ごすことができなかった、隠れた機能がありました。実際、オーディオに無関係だったのです。ほかのキャラクターはダイアログ中に適当に口をパクパク動かすだけですが、かわいいヒーローはアニメーション制作の過程で優遇されていたのです。数多くの顔表情や口表情のアニメーションで描かれ、顔がブレンドするときの形が沢山あり、それをアーティストたちはダイアログ中に同期させなければなりませんでした。MP3ファイルにあった余分なバイトは、シネマティックシーン中に口の動きを簡単に同期できるようにMichael Curringtonがつくったツールの名残だったのです。何か月も探し続け、ようやく答えが出ました。世界は救われ、私の記事も救われました。

この話は最初にフランス語で出され、ほかの Twitterスレッド 経由で、Rareのチームのおかげで、もう少し教えてもらえました。Conkerのマンガ風ボイスは半音2つ分ピッチを変えましたが、プロセス全体とレンダリングは、実装前に行われました。Robin Beanlandはボイスの長さをあえて同じに維持したので、この問題が保存スペースの節約目的ではないことが、100%明らかになりました。

Chris Seavorが最近、Twitterでスケッチやレベルデザインのスキャンを共有し始めました。開発中にゲームがどのように変わるのかが、よく分かります（出典: https://twitter.com/conkerhimself/status/1359160911769010183 ）（Chris Seavorのご好意でここに掲載）

私たちの冒険の賢明な結末

匿名の情熱的な人たちがツールを作成し、結果を惜しみなく公開してくれるからこそ、私たちは Conker のオーディオファイルの裏にある不思議なオーディオの話を掘り起こすことができました。@Percight の分析や、ゲームサウンドのオリジナルメンバーの回答がなければ、大きな誤解を持ったまま、私はConkerのボイスやサウンドについて誤った歴史をシェアしたかもしれません。大したことでないと思われるかもしれませんが、MP3の変則性をデータストレージの対策として共有していれば、歴史に対する二重の過ちとなってしまいます。まず、虚偽の情報という1つ目の過ち。そして、忘れてはならない、もっと格段に複雑で興味深い正解を、逃してしまうという過ち。正しい相手と、長々と話せたことで、1990年代のゲームの仕組みの面白い話を紹介することができました。

最終的に、一番簡単な答えが必ずしも正解ではなく、当たり前の情報が、必要なときには忘れられているかもしれないことを、私たちは学びました。また、サウンドファイルに音以外が入っていることもあることを知りました。アーキビストの立場から、リップシンク用のバイトをどうするべきかは、おもしろい疑問点です。音のアーカイブに影響します。これらのバイトをサウンドファイルから取り除けば、ゲームに忠実なサウンドを復元できるかもしれませんが、ボイスオーバーの歴史の一部分が切り取られてしまいます。MP3ファイルだけでは、この歴史を語ることができず、背景情報なしでは聞き取ることもできず、解決不可能な問題になってしまいます。

今でも、技術的なコツや作業方法は、プログラマーやサウンドエンジニアたちによって、充分に文書化や共有化されていません。働き方の倫理や、NDAの遵守など、業務内容を非公開とすべき、当然かつ重要な理由はあります。ゲームがリリースされ、次の世代のゲームや、ハードウェアや、技術に移行すると、新たな忘却の波が起き、一部のツールやコツが無意味になります。共有されないツールや習慣は、的確に記録しなければ、忘れられて失われる危険性があります。紹介したとおり、ゲームから抽出されたデータだけでは、それがどのように、どうして作用するのかを完全に理解できません。リバースエンジニアリングは厳密な科学ではなく、情報のギャップを埋めることで主に成り立っています。ゲームオーディオの歴史に未回答の技術的な疑問が残り、全体像を描くためのツールもありません。さらに、すべてのゲームがゲーム技術のアマチュア歴史家や音の冒険家を同じように惹きつけるわけではなく、私たちが適切な場所に目を向けなかったり、適切なタイミングで見ていなかったりすれば、素晴らしい情報が永遠に失われてしまいます。今回のように偶然が重なったことでおもしろい発見ができたことを考えると、時間の経過とともにどれだけの発見が見落とされるのか、想像してみてください。

今回の旅は、決して無駄ではありませんでした。省スペースという誤った仮説には、歴史的な真実も入っています。研究を通して、確かにストレージの最適化のためにスピードアップしたオーディオファイルを使ったゲームも、少数ながらあることが分かりました。PlayStation3の時代まで使われていたテクニックだという情報もあります。ただ、この方式の具体的な手がかりや事例はありません。 Rainbow Six 3 のボイスオーバーがスピードアップされたボイスのようだとするプレイヤーの指摘と、Ubisoftのゲームでよくやる（またはよくやっていた）手法だという回答が、過去に複数あります。古いN64のゲーム、例えば Super Mario や Mario Kart 64 などは、このテクニックを使ったかもしれません。今回のように、はっきりとした答えをもらえるまで、確実なことは分かりません。このようなテクニカルな慣習について、この記事を読んでいる人の中で実際に体験した方もいるかもしれません！ゲームオーディオの歴史を継続的に記録する作業に、貢献したいと考えた方は、技術が常に発展する中、あなたの作品とストーリーが忘れ去られないように、私にご連絡ください。