民生レベルでデジタル音声の処理技術が進んでいる。例えばPHSだが、同じ回線 数で多くの情報を伝えるには、音声の圧縮化技術が重要である。データを1/2に圧 縮できれば回線数を倍にする効果があるのだ。究極の圧縮は、音声を文字データ に変換して転送するということになるだろうが、これは難しい。そこで、音声と しての情報を極力損なわずに、データ圧縮するというのが主流となっている。 とはいえ、音声伝達は、単に字面が伝わればよいというものではない。声でな ければ伝わらないこともある。音声を文字に変換すると、この細かいニュアンス が全て消滅してしまう。文字面が同じでも、ちょっとした言い方で意味が変わっ てしまうことは、よくあるのだ。電話は単に文字面を言葉で伝えているだけでは ない。その裏にある感情表現は捨ててはいけないのである。
*
1月号で“ときめきメモリアル”のアルバムに写真の枚数の話を書いて、壁が150
〜180枚じゃないかと書いたが、見積りが全然甘かった。手元のアルバムには228
枚の写真が入っているのである。
実は、200の大台に乗せた時、最初は230枚の写真を入れたつもりだったのに、 221枚しか入らなかったのである。これはどういうことだろうとNIFTY-Serveの FCGAMEMで書いたらコメントが付いて、プレイ終了までどの女の子のアルバムにな るか分からないのだから、全部の女の子の写真が記録されていて、そのサイズが 256じゃないのか、という予想だった。本当にそうなのか計算してみたら、確かに 256枚という数は当たっていそうである。
もしかするとコナミのプログラマーも私と同様な発想で、まあ180枚も撮れば限 界だろうと予想し、だったら256枚分のエリアを確保しておけばOKだろうと考えた のかもしれないが、問題はそれを検証しなかったということである。あるいは検 証したけどレアケースだから障害が発生しても構わないと判断したのかもしれな い。だったらどこかにそう書いておいて欲しいものである。音楽データのバグは ゲーム中のドキュメントに書かれているのだから。
どの程度が限界かを決めるのは難しい。個人的な経験則として、これはまず限 界だろうと予想した値を10倍すれば、まずOKなのだが…今回だと1,500枚? 日数 より多いからそりゃ無理だけど、例えば全部の日曜にデートに誘ってもらって(あ りえない)約300、イベントが30枚。400枚あれば十分かな、というあたりが妥当か。 実際にゲームをやってみれば、256枚というのが限界に極めて近い値で、もしかす ると超えてしまうことは分かるはずなのだが。
しかし、256枚というのはともかく、例えば512枚のデータを入れる余裕はなか ったか、ということが気になる。メモリカードの容量は1ブロックあたり8KBだそ うである。写真のデータというのは、たいして情報がない。日付と場所、どの女 の子かということと、親しさがどうか、程度で決まるのである。32ビットあれば 十分かな、と思ったのだが。昔ならビットストリームを作ってデータを極限まで 小さくしようと考えただろう。メモリが高かった時代である。
*
FCGAMEMでちょっと話題になったのだが、このゲームでは、写真の日付は9ビッ
トあれば表現できる。3年間を何も考えずに表現しようとすると、1061日あるそう
なので、単純に考えれば、10ビット=1024通りでも入らない。11ビット必要である。
ところが、これを10ビットで表現する方法がある。実はこのゲームには必ず撮る
ことになっている写真がある。例えば1996年4月4日がそうである。仮に、これを
0と表現し、前後の日付を10ビットの符号付き整数で表現する。例えば、1996年4
月3日なら-1、符号無しとみなせば1023に相当する数で表現する。こうしておけば、
後は最初に0が現れるまでは1995年4月4日〜1996年4月3日、0が現れた場合はそれ
以降として処理すればよい。
さらに、これを9ビットで表現することもできる。このゲームは、バレンタイン デーの写真は必ず伊集院が出てくるので、その写真を撮るはずである。従って、 前回撮った写真からの経過日数は最高でも一年の日数、すなわち366位内に収まる のである。従って、日付をゲームスタートからの経過日数ではなく、前回の写真 からの差分の日数で表現すれば、その値はたかだか366、すなわち9ビットで表現 できる511の範囲に入るのである。
ただ、私などは、かなりセコい性格なので、写真が入りきらない程メモリカー ドの容量が不足しているのなら、8ビットで入れてしまったらどうかと思ったりす るのだ。8ビット=1バイトというキリのよい数でもあるので、何となく8ビットに する魅力があるのだ。もちろん、8ビットだと前回の写真からの経過日数が範囲に 収まらない場合が出てくるので、処理は複雑になる。8ビットをフルに使えば直前 の写真の日付からの差分が255日以内である限り表現可能である。しかし、前回の 写真からの差分は255を超えるかもしれない。この時には、収まりきらない時を特 別扱いというのがセオリーである。
話を簡単にするため、一枚の写真に4バイトのデータを使うことにしよう。ビッ トストリームで情報を記録した方が多くのデータを保存できるが、考え方の本質 は同じである。通常は1バイト目に前回の写真からの経過日数を入れ、残りの3バ イトに他の情報を格納する。ただし、経過日数が255日以上になる場合には、1バ イト目には255という値を入れて、残りの3バイトは他の写真と同様に使う。これ だけでは経過日数の情報が欠落するので、次の写真データとして扱う予定の4バイ トを、経過日数を入れるために特別な使い方をする。例えば次の2バイトを本当の 経過日数として、余った2バイトは使わずに捨てればよい。
こうすれば、255日以上間のあいた写真は、4バイトではなく8バイト使って表現 することになるが、そもそも、これだけ間をおいて写真を撮れば、ゲーム期間中 に殆ど写真が撮れないのだから、この程度の無駄は何の差し支えもないというの がミソである。
2バイト使って日付を処理すれば、このような面倒は何もないのだから、当然コー ドも短くなるし、処理速度も有利である。従って、単純化すれば、処理を複雑に してまでデータサイズを小さくするか、あるいはデータサイズが大きくなっても 構わないから処理を簡単にするか、というトレードオフの問題になる。どちらを 選択すべきかは状況次第である。
/* sample list */
typedef struct {
char d_diff;
char info[3];
} PICTURE;
void read_picture(PICTURE *pict)
{
int i;
/* 実際はエラーチェックが必要 */
/* fp は他で定義されているとする */
pict->d_diff = (char) getc(fp);
pict->info[0] = (char) getc(fp);
pict->info[1] = (char) getc(fp);
pict->info[2] = (char) getc(fp);
}
void read_longday(int *past)
{
int i;
/* 実際はエラーチェックが必要 */
i = getc(fp) * 256;
i += getc(fp);
*past = i;
i = getc(fp); /* skip this */
i = getc(fp); /* skip this */
}
void check_picture(void)
{
PICTURE pict;
int pass_day;
read_picture(&pict);
pass_day = (int) pict.d_diff & 0xff;
if (pass_day == 0xff) {
read_longday(&pass_day);
}
/* pict.infoの処理 */
}
*
ある夜、回転寿司を食べに行った時の話である。ここで食べる時には、蟹の味
噌汁を頼むことにしている。見た所、味噌汁を注文する人はあまりいないのだが、
私はこれが好きなのだ。蛇足に決まっているが、蟹味噌が入っているのではなく、
蟹が入っている味噌汁である。しばらく落ち着いていると、隣にアベックが座っ
た。私の方をちらっと見て、「蟹の味噌汁があるぞ」というようなことを言った。
確かにある。男がそれを注文した。これが二つではなく一椀である。ただ、出て
きた味噌汁は女の方に置いた。この時の会話が、
と、こんな感じである。これほど変哲もない会話も珍しい。
但し、この時の「うわあ、蟹のにおいがするよ」が凄くよかった。たかが120円 の味噌汁なのに、この時ほど美味しそうな味噌汁は今まで見たことも聞いたこと もない。残念ながら、この貴重な声がどんな感じだったかをここに表現しようと しても、文字だけでは到底不可能であることは間違いないのである。