2000年度森泰吉郎記念研究振興基金報告書

ネットワークにおける非言語コミュニケーションの探求

-作品「Wake」の製作を通じて-

政策・メディア研究科修士二年

サイバー・サウンド・プロジェクト

三谷哲一

1 はじめに

研究の動機

現在コミュニケーションのスタイルは既存のメディアを使ったものからインターネットの上でコンテクストを交換する方法へとシフトしつつある。
しかしながら未だ双方向、つまりインタラクティヴな情報交換の手法の多くは言語に依存したツールが中心となっている。このことが何を意味するのか、それは「非言語コミュニケーション」の欠落を意味するのではないかと考察した。
私はいちエンジニアとしての視点、いちアーティストとしての視点、両方の視点でこの問題、つまり「インターネット上のサウンド・インタラクションの可能性」を捉えアブストラクトとなる作品の制作を行いたいと考えた。以上が本研究を始めるにあたっての動機である。

研究の目的

以上を踏まえ研究の命題をインターネット・サウンド・インスタレーションと定めその課題として

Webブラウザを利用したインターフェイスの構築
言語からの脱却
参加者同士のインタラクションの実現

以上三点の課題を課した。

2 研究背景

この章ではインターネット上でサウンドを用いた表現を行う上でキーとなる技術の現状について考察する。

インターネットを利用した音声伝達技術

ここでは先に述べたようなコンテンツを形成する際に用いられるインターネットを利用した音声伝達技術をデータ伝送、サウンド生成の視点から以下の二種類に分類し記述する。

ストリーム型
イベントインタラクション型

ストリーム型

通常音声をインターネットを介して伝送する場合、他のファイルと同様の方法を取るならftp等の方法でサウンドファイルをダウンロードして聞く形になる。しかしながらこの方法ではデータのダウンロードにかかる時間が長くクライアントはダウンロードの終了まで待つ形になる。
またライヴのように長時間続くものの場合はその視聴は困難となる。
そこで考え出されたがストリームオーディオと呼ばれる方法である。この方法はデータの受信と再生を同時に行い、サーバーから送信され続けるデータを読み込みながら再生を行うという方法である。
具体的な手順としては、

対象となるオーディオソース(ライヴ、メディアからの再生等)に対してエンコーダーとなるコンピューターを設置する。
エンコーダーはサウンドカード等のオーディオデバイスから音声をデジタル化し、サーバーに対してデータを送信する。
サーバーはエンコーダーから受け取ったデータを視聴を希望するクライアントに送信する。

現時点で幾つかのプロダクト化された製品が発売、及びフリーで利用可能となっているが、おおよその手順は上記の手順と同一である。次に現時点で利用可能なソフトウェアのうち注目すべきものを下に記す。

RealPlayer
RealPlayerはこのなかでも最も古い歴史を持つプラットフォームである。開発はRealNetwork 社http://www.real.comによって行われている。
大きな特徴の一つは一つのストリームで複数のデータ転送速度に対応しうるSureStreamと呼ばれる転送制御システムを持つ事である。通常不特定多数のクライアントを対象とするインターネットを介した音声中継の場合、各ユーザーの利用可能帯域はまちまちであり、単一のデータ転送速度にターゲットを絞った場合、それに満たないクライアントには音飛び、中継の中断などの現象が発生する。しかしSureStreamによるデータ転送を行った場合にはクライアントの状況に合わせて自動的に転送速度の切り替えが行われる為、これまでの方式に比べてトラブルを減少させる事が可能となり、低帯域のクライアントから高帯域のクライアントまで一つのデータストリームでカバーする事を可能としている。
更にWorld Wide Web Consortium(以下W3Cと省略)の提唱するマルチメディア統合言語 Synchronized Multimedia Integration Language(以下SMILと省略) (http://ww.w3c.org/AudioVideo) に1998年にいち早く対応しており、音声、ビデオのみならず、テキスト、静止画、スライドショーなど複数のデータソースを単一のデータストリームとして配信するシステムを確立している。
mp3
正式にはMPEG-1 Audio Layer3と言い、ISO(International Standardization Organization)のワーキンググループであるMPEGの制定した音声情報圧縮の国際規格である。開発はFraunhofer IIS 研究所とエルランゲン大学によって行われた。またMPEG(Moving Pictures Experts Group）は、動画の圧縮形式として有名であるが、正確にはMPEG-1、MPEG-2、MPEG-3と言うように分類されている。
MP3はMPEGの中のAudioを規定したパートに含まれる音声圧縮のための規格である。原理的には可聴帯域にあるデータのみを抜き出し、不可聴帯域にあるデータを無視する事によりデータの削減に成功している。圧縮比の違いによってさらに分類されているが、そのうちの一つであるLayer3ではCDクオリティ (44.1khz　16bit stereo)を実現しても1/10から1/12の圧縮率を得ることが可能である。
現在、様々な再生用のアプリケーションが殆どのプラットフォームにおいて開発されその殆どが、ファイルからの再生と、ネットワーク経由のブロードキャストを受信可能である。ブロードキャスト向けのソフトウェアとしてはicecast (http://icecast.linuxpower.org) やshoutcast (http://www.shoutcast.com)、 LANE(http://www.mp3dev.org/mp3/)などが有名である。
Twin VQ
正式にはTransform-Domain Weighted Interleave Vector Quantization (http://www.twinvq.org) と言いNTTヒューマンインタフェース研究所が開発した音声圧縮技術である。現在MPEG-4の音声レイヤに採用されている。
TwinVQは楽音(音楽を時系列に沿って分割した個々の部分)の情報量を圧縮する際に、楽音に処理を加えてベクトル化する。そして、この元の楽音のベクトルと、前もって TwinVQ内のデータとして蓄えられている多数のベクトルの一つひとつとの類似度を計算し、最も近い符号の番号だけを伝送あるいは蓄積する。この事により情報量を大幅に減らすことを可能としている。
現在SoundVQ (http://www.yamaha.co.jp/xg/download/soundvq/) をはじめとして幾つかのソフトウェア、ハードウェアに採用されている。

イベントインタラクション型

これに対してネットワークにサウンドデータそのものを流すのではなく、コンテンツの構成情報のみをネットワークに流し、コンテンツの生成はに接続したユーザーの手にあるソフトウェアで行うのがイベントインタラクション型の特徴である。

JavaSound API
インターネット、特にWebブラウザをインターフェイスとしてインタラクティヴな環境を早くから実現していたのがCGI(Common Gatway Interface)とJava Applet であった。Javaの発表当時、Java自体には複雑な音響処理のエンジンは無く、音声の機能としては、アプレット上でサウンドファイルを再生できるのみであった。
これに対する拡張としてSun MicroSystemは1997年にJavaSound API (http://java.sun.com/products/java-media/sound/)を提唱し1998年末に「JavaSound 0.8EA」として公開した。当初は不安定で信頼性の低いものであったが、改良が続けられ現在Java2 1.3の実行環境に標準で組み込まれている。
また、当初ブラウザ上での複雑なアプレットの実行には機能、処理速度の面で大きな問題があったが、これはブラウザ上でアプレットを実行する場合、Netscape Navigatorなら Netscape社、Internet ExplorerならMicrosoft社のヴァーチャルマシンを使用するため起きていた問題である。Sun MicroSyustem社はJava2以降Plugin環境のサポートにより、多くのブラウザで同社の提供するヴァーチャルマシンを動作させる事を可能とし、実行速度の高速化と最新機能のサポートを可能とした。
JSyn
JSyn (http://http://www.softsynth.com/jsyn)はPhilip L Burk氏(SoftSynth社)によるJava用の音響処理 APIである。先のJavaSound APIとの違いは音響処理部をJavaに依存していない点にある。 JSynはC言語でコンパイルされておりユーザーはこれをNetScapeもしくはInternetExplorer用のプラグインとして使用する。プログラマはJava Appletからこのプラグインを呼び出し、音響処理をさせる。
このことにより理論上、クライアントに展開した音響処理のエンジンをネットワークから操作する事は可能になる。ネットワークを利用した例では2000年、ベルリンで開催されたICMC(International Computer Music Conference)でTransJamというシステムが発表されている。

考察

インターネット上での音声伝達技術に着目すると、大多数を対象としたブロードキャスト用のストリーム技術は整備が進んでいるが、一対一のコミュニケーションを対象としたイベントインタラクション型の単純なAPIはまだ開発の歴史も浅く、スタンダードといえるようなソフトウェアもまだ無い。
ストリーム型のソフトウェアを利用する場合はサウンドソースの生成に関してほぼ制約が無くなるが、ユーザーからのアクションをどのようにスムーズに伝達するという点において問題が起こるものと推測される。
インスタレーションのような構造に向いているソフトウェアを構築する場合 JavaSoundのような基本的なAPIの応用でソフトウェアシンセサイザーのような上位のコンポーネントを作る事が最もロスが少ないものと予想される。

3 作品「Wake」の製作に関して

本章では作品「Wake」の製作に関して論述する。本作品はインターネット上のサウンド・インタラクションという手法で非言語コミュニケーションに属するメッセージの再構築を目的としたものである。

コンセプトの絞込み

対象

まずプレイ環境を設定する必要がある。コンピュータを用いた表現を行う場合その環境の設定要素が即ユーザーの限定要素に繋がる。
インターネットを利用してサウンドとグラフィクスを用いた表現を行う場合、大きく分けて (a)専用のアプリケーションの配布(b)Webブラウザ等普及しているソフトウェアのプラグインとして実装、この二つのパターンが挙げられる。当然の事ながら(a)の場合はクライアントに対してダウンロード、インストールといった手順が発生し、また何らかのトラブルでアプリケーションが起動しない可能性が出てくる。言語の選択にもよるがプラットフォーム毎に異なるパッケージを準備する必要性が出てくる。(b)の場合でもネットワークの状況、その他のトラブルによって障害の出る可能性があったが、今回は(b)の方式を選択した。
そこで

簡単な操作
特別なデバイス、ネットワークを必要としない(Webブラウザとプラグイン程度で実行可能)

以上二点を作品製作に関して課す条件とした。

インタラクション･デザイン

次にインタラクションのデザインについて論述する。
クライアント-つまりインターネットを利用しているユーザーの一人一人が起こした行動がインターネット上のコンテンツに影響を及ぼす形態としては

メッセージボード型
リアルタイムインタラクション型

の二つに大きく分類される。今回の目的はユーザー個人のインタラクションを別のユーザーに送り戻すという性質上リアルタイムインタラクションの方が望ましい。よってリアルタイムインタラクションを選択した。
更にリアルタイム型の視覚表現の中でユーザー一人一人を識別する方法としては

アバタ型(個人の代理となるオブジェクトが存在する)
非アバタ型(個人の代理となるオブジェクトが存在しない)

の二つが挙げられる。それぞれの特徴に関しては前述した通りである。今回の作品の目標に互いに異なる文化的バックボーンを持つ人間のインタラクションがあるので明確なアバタを用いない事にした。
明確なアバタを持つという事はそれが何かの象徴-この場合はインターネット上のユーザー一人一人-になるという事であるが、シンボルの持つ意味は文化圏によって違いがある。よってより抽象的で分かりやすい表現形式を取る事が望ましいと判断した。

使用技術の絞込み

Java

ここで問題になるのがサウンド面でのインタラクションとオーディオ面でのインタラクションを分離することなく伝達する事であった。
抑揚をつけた表現をシームレスに進めるにはイベントインタラクション型の方が適切であったので作品のデザインはイベントインタラクション型に基づいて進める事にした。
この時点で先行するリサーチから視覚、聴覚のインタラクションをデザインできるアプリケーション、及び開発言語について幾つか候補があがったが最終的にはJavaを選択した。その理由を以下に示す。

プラットフォーム依存性
先ず、コンセプトの項で説明したように今回の作品をできるだけ多くのOSでサポートする事が大きな目的でもある。現時点でJDK1.3はMicrosoft Windows、Linux、Solarisでサポート(現時点においてMacintoshでは未サポートであるが、将来的に対応を表明)されており、多くの端末上で動作させる事が可能である。
ネットワークプログラミング
次にJavaを選択した理由のひとつにネットワークプログラミングの容易さが挙げられる。 Javaにはネットワークプログラミングの基本的な部分に関して標準のAPIが存在し、コーディングが容易である。
音響処理用のエンジンが設計可能
3章のDandeLion Flyerに関する説明でも述べたようにJavaSound API(JDK1.3より標準サポート) により前述したイベントインタラクション型の条件の一つ、サウンド処理のエンジンを組み込む事が可能になる。

ネットワーク

またこのような携帯をとる作品の場合、プロトコルの選択も重要になる。現時点で利用されているIP(Internet Protocol)v4を利用する事は固定された条件として、 IP上で動作するプロトコルのうちTCP(Trans Control Protocol)もしくは UDP(User Datagram Protocol)、どちらを利用するか選択条件となる。
両プロトコルの特徴を整理すると

TCP
IP上で動作し、データの転送制御を行う
何らかのアクシデントによりデータ欠損が起きた場合再度の転送要求を行う
転送スピードはUDPより劣る
UDP
IP上で動作し、データの転送制御は行わない
何らかのアクシデントによりデータ欠損が起きた場合、そのデータは失われたままとなる
転送スピードはTCPより優れている

今回の作品の場合、デザイン上小さなアクションを連続して送信する事が予想された。なおかつその一つ一つのアクションに関して、確実に動作することより、高速に連続して送信する事が望ましい条件であった。よって今回はUDPの方が適当と考え、クライアント-サーバー間のイベント通信はUDPを用いて行った。
そして考慮すべき事は遅延に対する処理であるが、現在の技術では環境にも左右されるがクライアント-サーバー間の通信では数ミリセカンド～数百ミリセカンドの遅延が発生する。クライアントで起こされたアクションと反応のタイミングが問題となるのだが、今回はクライアントで起こしたインタラクションをまず自分の描画エンジンと音声再生エンジンに投影され、それと同時進行でサーバーに対してその情報を送る。その後にサーバーから全クライアントに対してその情報が送信され、クライアントで再生される。丁度やまびこのような関係でクライアントで起きた信号ととサーバーから起きた信号を再生させる事にした。「Wake」イベントフロー

作品概要

以上の件を踏まえて決定したWakeの作品概要を下に示す。

ユーザーはインターネット経由でhttpサーバー(wake.sfc.keio.ac.jp)にアクセスしクライアントプログラム(java Applet)を受け取る。
クライアントは同じくhttpサーバーからサウンドファイル(100k未満)をダウンロードし、メモリ上に展開、簡易マルチトラック・サンプラーを構成する。
ユーザーに対しては400×400のキャンバスが展開される。
ユーザーはキャンバス上をクリックすることにより、グラフィック(波紋)とサウンドのフィードバックをクライアントから得る。
クライアントはその裏でユーザーから得たクリックの情報をUDPポート2001番を使用しサーバー (wake.sfc.keio.ac.jp)に送信する。
サーバーは受信したクリックの情報を全てのクライアントに対してUDPポート2000番を使用し送信する。
クライアントは受け取ったクリック情報に基づいて波紋とサウンドをユーザーにフィードバックする。この時自分の送信した情報もフィードバックとして返ってくる。
4～7の繰り返し

5 発表と評価

発表

「Wake」は現時点までに

「The Beidge between Artificial Langugae and Natural Language」(2000/10/31～11/5)
「インターカレッジコンピュータ音楽コンサート」(2000/12/16,17)

において公開した。12/16,17のインターカレッジコンピュータ音楽コンサートに関しては学生、及び音楽情報処理学会の先生方からも興味ある反応を得た。

評価

ここでもう一度「Wake」の作成を通じて行った実験についてまとめ、インターネットを使った表現行為としてのサウンドインタラクションに関して論ずる。

Javaによるクライアントサイドの音響処理

まず技術面での実験評価をまとめる。今回最も大きな問題となったのが Javaによりクライアントサイドに音響処理のエンジンを実装する事である。今回はマルチチャンネルのソフトウェアサンプラーを構成し、波紋のグラフィクス毎にチャンネルを割り当てクリックもしくはインターネットからのイベントを受信し再生周波数、左右位相を変化させ再生させた。
心配された負荷に関しても今回は問題なく、LinuxやMicrosoft Windowsの環境では PentiumⅡもしくはceleronクラスのCPUを積んだコンピュータであれば再生が途切れる事は起きなかった。

文化的バックボーンを越える

次にこの作品がインターネットというメディアを通じて、互いの文化的バックボーンを越える行為に値したかどうか検証する。
今回波紋、水滴といったどの文化圏にも存在しうるイヴェントをモチーフとして用いたが、その「水」に対する感覚も国によって違うという事を改めて認識するととなった。この作品自体に関しても何人かヨーロッパ、アメリカの人間にプレイしてもらったが返ってきた感想の中には「日本的」というものが幾つかあり、ビジュアル及びサウンドの面でのデザインにはまだ検討すべき余地が多いと判断される。
インターカレッジコンピュータ音楽コンサートの展示中は適当な説明を入れながら反応を伺っていったが、説明無しにそこで起こっているものがインターネットの向こう側のユーザーからの反応であると知る事が出来るケースとそうではないケースが存在した。インタラクションのデザインにおいて固体差を持たせないとそれが他者であると認識はできないのだが、余りにも固体差(アクションの間隔、アクションの距離)がつき過ぎるとそれが意味するものを認識できない可能性が大きくなる。事例を重ねてそのバランスの取り方についても推察すべき事が多々存在した。

展開として期待されるもの

Javaによる音響処理エンジンの改良

まず第一点目Javaを利用した音響処理エンジンの改良を挙げたい。今回は単純にマルチトラックサンプラーの実装に留まったが、その他の音響生成エンジンの実装も考えたい。Javaを利用する事によって今回のようなサウンドインスタレーションのみではなく、音楽製作の環境としてのネットワークを通じたセッションの可能性も存在する。
現在のところMIDI信号のインターネットを通じたキャスト等、幾つかの試みがなされているが、その多くが専用的アプリケーションで動作している。Javaを利用する事により機種依存性のないソフトウェアシンセサイザーとネットワークを組み合わせたアプリケーションの可能性があり、それを自由にユーザーの手によって組み合わせるエンジンの開発には大きな意味がある事を確信した。

楽曲への回帰

次に考えられるのが楽曲への回帰である。この研究と平行して行ったリサーチで 2000年2月に「Piece for Mukkuli」という楽曲を作曲している。「Piece for Mukkuli」では自然現象を楽曲構成に取り込むという試みを行い、これに成功している。この楽曲自体が自然現象の表現とダイレクトに結びついているかどうかはまだ疑問の余地が大きいところではある。しかしながら同様の試みを「Wake」から得たユーザーのインタラクションによって行う事に対する期待は極めて大きかった。
次のステップでは異なる文化的バックボーンを持つ人間同士のインタラクションにより生まれるルールや法則の上で新しい音楽製作のスタイルを模索したいと思う。