JP2006171678A - セッション端末 - Google Patents

Abstract

【課題】音楽セッションに参加する演奏者に対し、その音楽セッションの演奏内容を示す良好な品質の楽音情報を保存用として提供すること。
【解決手段】セッション端末１０は、楽器４０から楽音信号が入力されると、低ビットレートのリアルタイム伝送用楽音情報と高ビットレートのバッチ伝送用楽音情報とを生成する。そして、音楽セッションが行われている間は、リアルタイム伝送用楽音情報をセッション管理サーバ装置２０へ送信し、音楽セッションが終わると、バッチ伝送用楽音情報を送信する。
【選択図】 図１

Description

本発明は、ネットワークを利用した音楽セッションを支援する技術に関する。

ネットワークを利用することによって遠隔にある演奏者同士による音楽セッションを行わせる、「ネットセッション」と呼ばれるサービスが普及してきている。このサービスは、ネットセッションに特化された専用のデバイスである「セッション端末」から、それらセッション端末間での楽音情報のやり取りを仲介するサーバ装置へアクセスすることによって提供される。
このセッション端末は、通信機能に加えて、楽音信号をデコードし及びエンコードする機能を搭載する。そして、ある演奏者が自らのセッション端末に接続した楽器を演奏すると、その楽音信号が自らのセッション端末からサーバ装置を経由して他の演奏者のセッション端末へほぼリアルタイムに伝送され、伝送先の端末から楽音として放音される。このような処理が相互に行われることにより、音楽セッションが実現する。

ネットセッションサービスをより魅力あるものとするためには、同サービスを通じて提供される演奏音の音質を、生で行われる音楽セッションのそれに可能な限り近づけることが望ましい。そして、そのためには、各演奏者の楽器からライン入力等でセッション端末に入力される楽音信号を、可能な限り高いビットレートで符号化して送出することが必要となる。
しかしながら、各セッション端末間のデータ伝送路のデータ通信速度には一定の限界があるため、あまりに高いビットレートで符号化して送出してしまうと、今度は、ネットセッションサービスを提供する上で最も重要な条件の一つであるリアルタイム性が確保し難くなってくるという問題があった。特許文献１には、この種の問題の解決の端緒となり得る記載が認められる。同文献に開示された送受信制御装置は、自身とデータの引渡先の装置との間に介在するデータ伝送路のデータ通信速度を随時検出し、検出した速度に応じてデータの品質を適宜劣化させてから送信するといった処理を行う。
特開２００４−１５３７７７

ところで、特許文献１に記された類の技術をネットセッションサービスに取り入れた場合、各セッション端末で符号化された楽音信号を遣り取りする際のビットレートはそれら端末間のデータ伝送速度に依存して流動的なものとなる。一方で、ネットセッションサービスを利用する演奏者の多くは、自らが参加した音楽セッションの演奏内容を自ら保存して後から聴き返したり、あるいは自身の知り合いに聴かせてみたいといった希望を持っている。このような希望を持つ演奏者にしてみると、ビットレートを流動化させた結果として、音質が一定しない演奏音の保存を強いられることはかえって不都合が大きい。
本発明は、このような事情を鑑み案出されたものであり、音楽セッションに参加する演奏者に対し、その音楽セッションの演奏内容を示す良好な品質の楽音情報を保存用として提供することを目的とする。

本発明の好適な態様であるセッション端末は、情報の記憶手段と、楽音信号を入力する入力手段と、前記入力手段から楽音信号が入力されると、入力された楽音信号に第１のビットレートでの符号化処理を施してリアルタイム伝送用の楽音情報を生成すると共に、当該入力された楽音信号に前記第１のビットレートよりも高い第２のビットレートでの符号化処理を施してバッチ伝送用の楽音情報を生成する符号化手段と、前記符号化手段が生成したバッチ伝送用の楽音情報を前記記憶手段に記憶する記憶制御手段と、他のセッション端末からリアルタイム伝送用の楽音情報を受信する受信手段と、前記受信手段が受信した楽音情報に所定の復号化処理を施して得た楽音信号を出力する出力手段と、前記符号化手段によって生成されるリアルタイム伝送用の楽音情報を前記他のセッション端末へ送信すると共に、所定のタイミングで、前記記憶制御手段によって前記記憶手段に記憶されていたバッチ伝送用の楽音情報を外部の特定の装置へ送信する送信手段とを備える。

この態様において、前記送信手段は、リアルタイム伝送が行われていない間に前記記憶手段に記憶されていたバッチ伝送用の楽音情報を前記特定の装置へ送信するようにしてもよい。

また、前記記憶制御手段は、前記符号化手段が生成した時刻の情報と共にバッチ伝送用の楽音情報を前記記憶手段に記憶し、前記受信手段は、前記送信手段が前記特定の装置へバッチ伝送用の楽音情報を送信した後、自端末と他のセッション端末から送信されていた各バッチ伝送用の楽音情報を前記時刻情報を基にミキシングして得られた多重楽音情報を前記特定の装置から受信し、前記出力手段は、前記受信手段が受信した多重楽音情報に所定の復号化処理を施して得た楽音信号を出力するようにしてもよい。

さらに前記リアルタイム伝送用の楽音情報は前記特定の装置へ送信されるものであり、前記特定の装置より、送信したリアルタイム伝送用の楽音情報と前記特定の装置内で保持する模範楽音情報を比較することによって求められる差異情報を前記受信手段が受信すると、その差異情報に応じて前記バッチ伝送用の楽音情報を前記特定の装置へ送信するようにしてもよい。

更に、前記受信手段は、前記送信したバッチ伝送用の楽音情報に対して模範楽音情報との差異点を強調するような加工を施して得られた練習用楽音情報を受信するようにしてもよい。

本発明によると、音楽セッションに参加する演奏者に対し、その音楽セッションの演奏内容を示す良好な品質の楽音情報を保存用として提供することができる。

（第１実施形態）
本願発明の第１実施形態について説明する。
まず、以降の説明で用いる主要な用語を定義しておく。「運営者」とは、ネットワークを利用した各種サービスを提供している事業者を意味する。「演奏者」とは、運営者による支援の下、セッション端末の持ち主としてサービスを利用する個人を意味する。「楽音情報」とは、楽音信号に所定のビットレートで符号化処理を施して得た符号列を表す情報を意味する。

図１は、本実施形態にかかるセッションシステムの全体構成図である。図に示すように、本システムは、複数のセッション端末１０と、セッション管理サーバ装置２０とから構成される。これら各ノードは、図に示すＮＴＰ（network time protocol）サーバ３０による支援の下、時刻の同期が図られるようになっている。
図２は、セッション端末１０のハードウェア構成を示すブロック図である。図に示すように、この端末１０は、楽音信号入力部１１、楽音信号出力部１２、通信部１３、記憶部１４、エンコード／デコード部１５、通信速度検出部１６、表示部１７、操作部１８、及び制御部１９を備える。

楽音信号入力部１１は、楽器４０から自端末１０へ楽音信号を入力する。一方、楽音信号出力部１２は、自端末１０からスピーカ５０へ楽音信号を出力する。通信部１３は、予め登録されたセッション管理サーバ装置２０のネットワークアドレスを基に同装置２０とコネクションを確立し、各種情報の送受信を行うようになっている。
記憶部１４は、自端末１０を識別する固有の識別情報である端末ＩＤを予め記憶している。また、この記憶部１４は、制御部１９による指示の下、特定の楽音情報を記憶する。

エンコード／デコード部１５は、楽音信号入力部１１から楽音信号が供給されると、その楽音信号に対して第１ビットレートでの符号化処理とそれよりも高く設定された第２ビットレートでの符号化処理とを個別に施すことによって、データ量の異なる２つの楽音情報を夫々取得する。そして、第１ビットレートでの符号化処理を施して得た楽音情報（以下、この楽音情報を「リアルタイム伝送用楽音情報」と呼ぶ。）を通信部１３へ直ちに供給すると共に、第２ビットレートでの符号化処理を施して得た楽音情報（以下、この楽音情報を「バッチ伝送用楽音情報」と呼ぶ。）を記憶部１４へ供給し、同部１４に記憶させる。一方で、このエンコード／デコード部１５は、通信部１３あるいは記憶部１４から楽音情報が供給されると、その楽音情報に復号化処理を施して得た楽音信号を楽音信号出力部１２へ供給する。

通信速度検出部１６は、通信部１３がセッション管理サーバ装置２０とコネクションを確立すると、同装置２０との間のデータ伝送路におけるデータ通信速度を所定の時間長毎に検出し、検出した通信速度に応じて第１ビットレートの設定値を最適化する。後の動作説明の項でも詳述するように、エンコード／デコード部１５が第１ビットレートで符号化処理を施して得たリアルタイム伝送用楽音情報は、セッション管理サーバ装置２０を経由して他のセッション端末１０へ直ちに送信されることになっている。このため、音楽セッションを行う際におけるリアルタイム性の破綻を回避しつつも可能な限り高音質の楽音情報を送信すべく、データ通信速度と第１ビットレートとを連動させる制御を通信速度検出部１６に実行させるものである。一方で、データ通信速度と第２ビットレートとを連動させる制御は実行されない。この第２ビットレートの設定値は、十分に高品質の楽音情報の生成を確保する値として固定されるためである。

表示部１７は、各種情報を表示するディスプレイである。操作部１８は、各種情報を入力するタッチパネル等の操作子である。
制御部１９は、上記各部を制御する。この制御部１９が行う特徴的な動作については、後にフローチャートを参照しつつ詳述する。

図３は、セッション管理サーバ装置２０のハードウェア構成を示すブロック図である。このサーバ装置２０は、運営者による管理の下に稼動しており、図に示すように、各種制御を行うＣＰＵ２１、ＣＰＵ２１にワークエリアを提供するＲＡＭ２２、ＩＰＬ（initial program loader）を記憶したＲＯＭ２３の他、ネットワークインターフェース２４、コンピュータディスプレイ２５、キーボード２６、ハードディスク２７などを備える。そして、ハードディスク２７は、音楽セッション支援プログラム２７ａを記憶する。

音楽セッション支援プログラム２７ａは、本実施形態に特有の機能をＣＰＵ２１に実現させるためのプログラムである。ＣＰＵ２１によってこのプログラムが実行されると、ＲＡＭ２２にはセッション管理テーブルが形成される。
図４は、セッション管理テーブルのデータ構造図である。このテーブルは、各々が１つの音楽セッションと対応する複数のレコードの集合体である。図４の例では４つのレコードが設けられている。これは、セッション管理サーバ装置２０が４つの音楽セッションを個別に取り仕切ることができることを意味している。このテーブルを構成する１つのレコードは、「セッション」、「参加メンバー」、及び「セッション中フラグ」の３つのフィールドを有している。

「セッション」のフィールドには、各音楽セッションに予め割り振られた固有の番号であるセッション識別情報が記憶される。「参加メンバー」のフィールドには、セッション端末１０から自装置２０に送信されてくる端末ＩＤが記憶される。「セッション中フラグ」のフィールドには、音楽セッションが既に開始されていることを示す「１」、又は音楽セッションが未だ開始されていないことを示す「０」の何れかの情報が記憶される。

次に、本実施形態の動作について説明する。
本実施形態の動作は、セッション開始処理と、セッション離脱処理とに分けることができる。図５は、セッション開始処理を示すフローチャートである。
図に示す処理は、何れかの演奏者が自らのセッション端末１０からセッション管理サーバ装置２０にアクセスすると開始される。
セッション端末１０からのアクセスを受けたセッション管理サーバ装置２０のＣＰＵ２１は、ＲＡＭ２２のセッション管理テーブルの記憶内容を基に生成したセッションルーム案内画面の表示データを、アクセスしてきたセッション端末１０に宛てて送信する（Ｓ１００）。

表示データを受信したセッション端末１０の制御部１９は、セッションルーム案内画面を表示部１７に表示させる（Ｓ１１０）。
図６は、セッションルーム案内画面である。この画面は、セッション管理テーブルにおける各レコードの記憶内容を、「セッションルーム」と呼ばれる仮想的な部屋への入室の有無として夫々表す。同画面の上段には、「入室するセッションルームを選択して下さい。但し、セッションが既に開始されているセッションルームには入室できません。」という内容を示す文字列が表示される。もちろん、これに限らず、既に開始されているセッションに途中参加できるようにしてもよい。また、同画面の下段には、セッション管理テーブルの記憶内容が、「セッションルーム」、「入室者」、及び「状態」の３つの項目を対応付けた表として表示される。この表では、セッション管理テーブルの「セッション」のフィールドに記憶されていたセッション識別情報が「セッションルーム」の項目として表示され、「参加メンバー」のフィールドに記憶されていた一又は複数の端末ＩＤが「入室者」の項目として表示される。更に、セッション管理テーブルの「セッション中フラグ」のフィールドの記憶内容が「１」である音楽セッションについては、対応するセッションルームの「状態」の項目が「セッション中」と表示される一方で、「０」である音楽セッションについては「入室者募集中」と表示される。

セッションルーム案内画面を参照した演奏者は、自らが入室するセッションルームを操作部１８により選択する。
操作部１８によってセッションルームが選択されると、セッション端末１０のＣＰＵ２１は、選択されたセッションルームのセッション識別情報と、記憶部１４から読み出した自身の端末ＩＤとをセッション管理サーバ装置２０へセットとして送信する（Ｓ１２０）。

セッション識別情報と端末ＩＤのセットを受信したセッション管理サーバ装置２０のＣＰＵ２１は、受信したセッション識別情報と対応するレコードをセッション管理テーブルから特定する（Ｓ１３０）。
続いて、ＣＰＵ２１は、ステップ１３０で特定したレコードの「参加メンバー」のフィールドへ端末ＩＤを記憶する（Ｓ１４０）。このステップ１４０にて、自らが送信した端末ＩＤが「参加メンバー」のフィールドに記憶されたセッション端末１０は、同じフィールドに既に記憶されていた、又は後から記憶される端末ＩＤの発信元のセッション端末１０と共に音楽セッションを行うことが可能な状態になる。

続いて、ＣＰＵ２１は、ステップ１３０で特定したレコードの「参加メンバー」のフィールドに記憶されている全ての端末ＩＤをＲＡＭ２２へ読み出す（Ｓ１５０）。
ＣＰＵ２１は、ステップ１５０で読み出した端末ＩＤを所定の雛形に埋め込むことによって得た参加状況通知画面の表示データを、それら各端末ＩＤの発信元であったセッション端末１０に宛てて送信する（Ｓ１６０）。

表示データを受信したセッション端末１０の制御部１９は、参加状況通知画面を表示部１７に表示させる（Ｓ１７０）。
図７は、参加状況通知画面である。この画面の上段には、「セッションルームに入室している方のＩＤは以下の通りです。準備ができたら、「セッション開始」を選択してください。」という内容の文字列が表示され、その下には、ステップ１５０で読み出された全ての端末ＩＤが入室者として表示される。更に画面の下段には、「セッション開始」と記したボタンが表示される。

この画面を参照した演奏者は、セッションを開始してもよいか否かを判断する。セッションを開始してもよいと判断したときは、画面下のボタンを操作部１８によって選択する。
「セッション開始」のボタンが選択されると、制御部１９は、セッションの開始を求めるメッセージをセッション管理サーバ装置２０へ送信する（Ｓ１８０）。

セッション管理サーバ装置２０のＣＰＵ２１は、参加状況通知画面の表示データの宛先であった全てのセッション端末１０からセッションの開始を求めるメッセージを受信すると、ステップ１３０で特定したレコードの「セッション中フラグ」のフィールドの記憶内容を「０」から「１」へ書き換える（Ｓ１９０）。
続いて、ＣＰＵ２１は、音楽セッションの開始タイミングまでの残り時間長を表すカウントダウン信号を、各セッション端末１０へ送信する（Ｓ２００）。

カウントダウン信号を受信したセッション端末１０の制御部１９は、他のセッション端末１０と同期を取りつつ、音楽セッションの開始タイミングまでの残り時間長を表示部１７に表示させる（Ｓ２１０）。具体的には、「スタート３秒前」→「スタート２秒前」→「スタート１秒前」の各内容を示す文字列をこの順番で一秒おきに表示させ、更に「スタート１秒前」の文字列を表示してから１秒経過したタイミングで、「スタート！」の文字列を表示させる。

各演奏者は、自らのセッション端末１０の表示部１７に表示されるカウントダウン表示を参照し、「スタート！」の文字列が表示されたタイミングに合わせて一斉に楽器４０の演奏を開始する。
演奏が開始された後、各セッション端末１０は、楽器４０から自端末１０に入力される楽音信号に対して第１ビットレートでの符号化処理を施して得たリアルタイム伝送用楽音情報をセッション管理サーバ装置２０へ送信する処理と、第２ビットレートでの符号化処理を施して得たバッチ伝送用楽音情報を記憶部１４に記憶させる処理と、セッション管理サーバ装置２０を経由して他のセッション端末１０から送信されてくるリアルタイム伝送用楽音情報を楽音信号としてスピーカ５０へ出力する処理とを並行して行う。
なお、これらの処理を行う際、セッション端末１０の制御部１９は、楽音信号から生成したバッチ伝送用楽音情報に、現在時刻を示すタイムスタンプを内包させてから記憶部１４へ順次記憶させる。

また、セッション管理サーバ装置２０のＣＰＵ２１は、一方のセッション端末１０から受信したリアルタイム伝送用楽音情報を他方のセッション端末１０へ直ちに転送する処理を行う。
このようなセッション管理サーバ装置２０を介したリアルタイム伝送用楽音情報の遣り取りが実行されることで、各セッション端末１０は、遠隔にある他のセッション端末１０に入力された楽音信号をも自らのスピーカ４０から楽音として放音することが可能になり、その結果、遠隔にある演奏者同士によるリアルタイムの音楽セッションが実現する。

各演奏者は、自らのセッション端末１０の操作部１８に所定の操作を行うことによって、音楽セッションからの離脱を指示することができる。そして、この離脱を指示する操作がセッション端末１０の操作部１８に行われると、セッション離脱処理が開始される。
図８は、セッション離脱処理を示すフローチャートである。
あるセッション端末１０の操作部１８から離脱を指示する操作が行われると、そのセッション端末１０の制御部１９は、音楽セッションからの離脱を求めるメッセージをセッション管理サーバ装置２０へ送信する（Ｓ２００）。
メッセージを受信したセッション管理サーバ装置２０のＣＰＵ２１は、そのメッセージの発信元のセッション端末１０に宛てて、バッチ伝送用楽音情報の送信を求めるメッセージを送信する（Ｓ２１０）。

メッセージを受信したセッション端末１０の制御部１９は、記憶部１４に記憶しておいたバッチ伝送用楽音情報を読出し、読み出したバッチ伝送用楽音情報をセッション管理サーバ装置２０へ送信する（Ｓ２２０）。
バッチ伝送用楽音情報を受信したセッション管理サーバ装置２０のＣＰＵ２１は、受信したバッチ伝送用楽音情報をＲＡＭ２２に記憶する（Ｓ２３０）。

続いて、ＣＰＵ２１は、カウントダウン信号の宛先であった全てのセッション端末１０から、バッチ伝送用楽音情報を受信したか否か判断する（Ｓ２４０）。
ステップ２４０にて、全てのセッション端末１０からバッチ伝送用楽音情報を受信したと判断したＣＰＵ２１は、ステップ１３０で特定したレコードの「セッション中フラグ」のフィールドの記憶内容を「１」から「０」へ書き換えると共に、同レコードの「参加メンバー」のフィールドに記憶されている端末ＩＤを消去する（Ｓ２５０）。

続いて、ＣＰＵ２１は、ＲＡＭ２２に記憶されている全てのバッチ伝送用楽音情報をミキシングして多重楽音情報を生成する（Ｓ２６０）。上述したように、各セッション端末１０は、バッチ伝送用楽音情報にタイムスタンプを内包させることになっている。従って、ＣＰＵ２１は、各バッチ伝送用楽音情報に内包されているタイムスタンプを参照し、それら各バッチ伝送用楽音情報の時間軸を一致させつつミキシングを行なう。

ＣＰＵ２１は、ステップ２６０で生成した多重楽音情報を、バッチ伝送用楽音情報の発信元であった各セッション端末１０に宛てて送信する（Ｓ２７０）。
多重楽音情報を受信した各セッション端末１０は、その多重楽音情報を記憶部１４に記憶させた後、セッション管理サーバ装置２０とのコネクションを解除する（Ｓ２８０）。

各演奏者は、自らのセッション端末１０とセッション管理サーバ装置２０とのコネクションを解除し、オフライン状態となったセッション端末１０の操作部１８に所定の操作を行うことによって、多重楽音情報の再生を指示する。多重楽音情報の再生を指示する操作が行われると、セッション端末１０の制御部１９は、記憶部１４に記憶された多重楽音情報をエンコード／デコード部１５へ順次供給する。すると、エンコード／デコード部１５にて復号化処理を施して得られた楽音信号が楽音信号出力部１２を介してスピーカ５０へ出力され、スピーカ５０からは、先に行われた音楽セッションの模様が高音質の多重楽音として放音されることになる。

以上説明した実施形態によると、各セッション端末１０は、楽器４０から入力された楽音信号に第１ビットレートでの符号化処理とそれよりも高い第２ビットレートでの符号化処理とを個別に施すようになっている。そして、他のセッション端末１０と共に現に音楽セッションを行っている間は第１ビットレートでの符号化処理を施して得たリアルタイム伝送用楽音情報をセッション管理サーバ装置２０へ送信する一方、その音楽セッションから離脱すると、今度は第２ビットレートでの符号化処理を施して得ておいたバッチ伝送用楽音情報を送信する。また、セッション管理サーバ装置２０は、全てのセッション端末１０が離脱して音楽セッションが終了した後、それら各セッション端末１０から受信したバッチ伝送用楽音情報をミキシングして得た多重楽音情報を夫々に提供するようになっている。
従って、データ伝送路に過度の負担をかけない程度の音質で楽音情報を遣り取りさせることによるリアルタイムの音楽セッションを保証する一方で、音楽セッションが終了した後は、その演奏の模様をより高い音質で記録した楽音情報を提供することができる。

（第２実施形態）
本願発明の第２実施形態について説明する。本実施形態の特徴は、音楽セッションにおいて所定の課題曲を演奏者に演奏させ、その演奏により得られたリアルタイム伝送用楽音情報をセッション管理サーバ装置が評価するようにした点にある。

本実施形態にかかるセッションシステムの全体構成は図１に示したところと同様である。但し、図に示す各ノードのうちセッション管理サーバ装置２０のハードウェア構成は第１実施形態と異なる。
図９は、セッション管理サーバ装置２０のハードウェア構成を示すブロック図である。図に示すように、このサーバ装置は、ＣＰＵ２１、ＲＡＭ２２、ＲＯＭ２３、ネットワークインターフェース２４、コンピュータディスプレイ２５、キーボード２６、ハードディスク２７のほか、楽音処理用ＤＳＰ２８を備える。楽音処理用ＤＳＰ２８には、各セッション端末１０から送信されてくる楽音情報がＣＰＵ２１を介して供給されるようになっている。そして、この楽音処理用ＤＳＰ２８は、ＣＰＵ２１から供給される楽音情報に復号化処理を施して得た楽音信号を解析することによりそのピッチと音量を抽出し、演奏ピッチデータ及び演奏音量データとして夫々出力するようになっている。
また、ハードディスク２７は、音楽セッション支援プログラム２７ａに加えて課題曲模範楽音情報２７ｂを記憶する。課題曲模範楽音情報２７ｂは、課題楽曲のお手本となる楽音信号に符号化処理を施して得た楽音情報である。

次に、本実施形態の動作を説明する。
本実施形態の動作は、第１実施形態と同様にセッション開始処理とセッション離脱処理に分けることができ、これら両処理のうちセッション離脱処理の一部が第１実施形態と異なる。また、セッション開始処理のサブルーチンとしてセッション評価処理が実行される。

図１０は、セッション評価処理を示すフローチャートである。
図に示す処理は、図５に示すステップ２００においてセッション管理サーバ装置２０が各セッション端末１０へカウントダウン信号を送信し終えたことをトリガーとして開始される。第１実施形態において、カウントダウン信号を送信し終えたセッション管理サーバ装置２０は、一方のセッション端末１０から自装置２０へ送信されてくるリアルタイム伝送用楽音情報を他方のセッション端末１０へ転送する処理を実行するだけであったが、本実施形態においては、この転送処理と併せて図に示す処理をも実行する。
カウントダウン信号を送信し終えたセッション管理サーバ装置２０のＣＰＵ２１は、図５のステップ１４０にて「参加メンバー」のフィールドに記憶した各端末ＩＤを読み出す（Ｓ４００）。

続いて、ＣＰＵ２１は、演奏評価管理テーブルをＲＡＭ２２に形成する（Ｓ４１０）。
図１１は、演奏評価管理テーブルのデータ構造図である。このテーブルは、各々が、１つの音楽セッションに参加することとなった各演奏者と対応する複数のレコードの集合体である。そして、このテーブルを構成する１つのレコードは、「演奏者」、「評価ポイント」、及び「良好演奏フラグ」の３つのフィールドを有する。
「演奏者」のフィールドには、ステップ４００で読み出された端末ＩＤの各々が記憶される。「評価ポイント」のフィールドには、評価ポイントが記憶される。評価ポイントとは、各演奏者の演奏の巧拙の程度を客観的に示す数値を意味し、演奏評価管理テーブルが形成された直後は、満点である「１００」が記憶される。後に詳述するように、各演奏者のセッション端末１０からリアルタイム伝送用楽音情報が送信されてくると、その楽音情報と課題曲模範楽音情報２７ｂとから夫々抽出したピッチ及び音量のずれ量が所定値を上回る度にこのフィールドの数値を減じて行き、演奏者が音楽セッションから離脱した時点の数値が閾値である「８０」を上回っていたときのみ、「良好演奏フラグ」のフィールドに「１」が記憶されるようになっている。

図１０において、演奏評価管理テーブルをＲＡＭ２２を形成したＣＰＵ２１は、ハードディスク２７に記憶された課題曲模範楽音情報２７ｂをＲＡＭ２２に読み出す（Ｓ４２０）。
課題曲模範楽音情報２７ｂを読み出したＣＰＵ２１は、セッション端末１０からのリアルタイム伝送用楽音情報の送信を待つ。音楽セッションが開始され、セッション端末１０からリアルタイム伝送用楽音情報が送信され始めると、ＣＰＵ２１は、以降の一連の処理をそれら各セッション端末１０から受信するリアルタイム伝送用楽音情報毎に並列に実行する。

リアルタイム伝送用楽音情報を受信したＣＰＵ２１は、その発信元のセッション端末１０の端末ＩＤを「演奏者」のフィールドに記憶したレコードを演奏評価管理テーブルから特定する（Ｓ４３０）。
ＣＰＵ２１は、リアルタイム伝送用楽音情報を楽音処理用ＤＳＰ２８に供給し、演奏ピッチデータ及び演奏音量データを取得する（Ｓ４４０）。

また、ＣＰＵ２１は、ＲＡＭ２２の課題楽曲模範情報に復号化処理を施して得た楽音信号から現在の演奏区間の模範ピッチデータ及び模範音量データを取得し、その模範ピッチデータ及び模範音量データとステップ４４０で取得した演奏ピッチデータ及び演奏音量データのずれ量を検出する（Ｓ４５０）。
更に、ＣＰＵ２１は、ステップ４５０で検出したずれ量が所定値よりも大きいか否か判断する（Ｓ４６０）。

ステップ４６０において、ずれ量が所定値よりも大きいと判断したＣＰＵ２１は、ステップ４３０で特定したレコードの「評価ポイント」に記憶された数値から所定値（例えば、１ポイント）を減じる（Ｓ４７０）。
このステップ４３０乃至ステップ４７０の一連の処理は、音楽セッションからの離脱を求めるメッセージを受信するまで所定時間長毎に繰り返される。

図１２及び１３は、セッション離脱処理を示すフローチャートである。本実施形態においては、ステップ２００よりも後の内容が第１実施形態と異なる。
ステップ２００にて、音楽セッションからの離脱を求めるメッセージをセッション端末１０から受信したセッション管理サーバ装置２０のＣＰＵ２１は、そのメッセージの発信元のセッション端末１０の端末ＩＤを「演奏者」のフィールドに記憶しているレコードを、演奏評価管理テーブルから特定する（Ｓ５００）。

続いて、ＣＰＵ２１は、ステップ５００で特定したレコードの「評価ポイント」のフィールドに記憶された数値が閾値である「８０」を上回っているか判断する（Ｓ５１０）。
ステップ５１０において、評価ポイントが閾値を上回っていると判断したＣＰＵ２１は、ステップ５００で特定したレコードの「良好演奏フラグ」のフィールドに「１」を記憶する（Ｓ５２０）。

続いて、ＣＰＵ２１は、図５のステップ２００で送信したカウントダウン信号の宛先であった全てのセッション端末１０から離脱を求めるメッセージを受信したか判断する（Ｓ５３０）。
ステップ５３０にて、全てのセッション端末１０からメッセージを受信したと判断したＣＰＵ２１は、図５のステップ１３０で特定したレコードの「セッション中フラグ」のフィールドの記憶内容を「１」から「０」へ書き換えると共に、同レコードの「参加メンバー」のフィールドに記憶されている端末ＩＤを消去する（Ｓ５４０）。

ＣＰＵ２１は、「良好演奏フラグ」のフィールドに「１」が記憶されている一又は複数のレコードを演奏評価管理テーブルから特定する（Ｓ５５０）。
ＣＰＵ２１は、ステップ５５０で特定したレコードの「演奏者」のフィールドに記憶された端末ＩＤと対応するセッション端末１０に宛てて、バッチ伝送用楽音情報の送信を求めるメッセージを送信する（Ｓ５６０）。

メッセージを受信したセッション端末１０の制御部１９は、記憶部１４に記憶しておいたバッチ伝送用楽音情報を読出し、読み出したバッチ伝送用楽音情報をセッション管理サーバ装置２０へ送信する（Ｓ５７０）。
バッチ伝送用楽音情報を受信したセッション管理サーバ装置２０のＣＰＵ２１は、受信したバッチ伝送用楽音情報をＲＡＭ２２に記憶する（Ｓ５８０）。

続いて、ＣＰＵ２１は、メッセージの宛先であった全てのセッション端末１０から、バッチ伝送用楽音情報を受信したか否か判断する（Ｓ５９０）。
ステップ５９０にて、全てのセッション端末１０からバッチ伝送用楽音情報を受信したと判断したＣＰＵ２１は、ＲＡＭ２２に記憶されている全てのバッチ伝送用楽音情報をミキシングして多重楽音情報を生成する（Ｓ６００）。

ＣＰＵ２１は、ステップ６００で生成した多重楽音情報を、バッチ伝送用楽音情報の発信元であった各セッション端末１０に宛てて送信する（Ｓ６１０）。
多重楽音情報を受信した各セッション端末１０の制御部１９は、その多重楽音情報を記憶部１４に記憶させる（Ｓ６２０）。多重楽音情報を記憶したセッション端末１０に対してその再生を指示する操作が行われると、音楽セッションの模様が高音質の多重楽音として放音される点は、第１実施形態と同様である。

多重楽音情報を記憶させた制御部１９は、多重楽音情報を取得した旨のメッセージをセッション管理サーバ装置２０へ送信する（Ｓ６３０）。
このメッセージを受信したセッション管理サーバ装置２０のＣＰＵ２１は、楽音情報加工サービス提案画面の表示データを各セッション端末１０へ送信する（Ｓ６４０）。

表示データを受信したセッション端末１０の制御部１９は、楽音情報加工サービス提案画面を表示部１７に表示させる（Ｓ６５０）。
この画面の上段には「うまく演奏できなかった箇所が強調された楽音情報の提供を受けることができます。本サービスを利用しますか？」という内容の文字列が表示され、その下には、「利用する」及び「利用しない」と夫々記されたボタンが表示される。この画面を参照した演奏者は、何れかのボタンを選択する。
「利用する」と記したボタンが選択されると、セッション端末１０の制御部１９は、記憶部１４に記憶しておいたバッチ伝送用楽音情報を読出し、読み出したバッチ伝送用楽音情報をセッション管理サーバ装置２０へ送信する（Ｓ６６０）。

バッチ伝送用楽音情報を受信したセッション管理サーバ装置２０のＣＰＵ２１は、そのバッチ伝送用楽音情報の一部を加工して練習用楽音情報を生成する（Ｓ６７０）。練習用楽音情報の生成は、以下の手順に従って行われる。まず、受信したバッチ伝送用楽音情報とハードディスク２７から読み出した課題曲模範楽音情報２７ｂの各々に復号化処理を施して楽音信号を復元する。次に、バッチ伝送用楽音情報から得た楽音信号の波形を課題曲模範楽音情報２７ｂから得た楽音信号の波形と順次比較し、課題曲模範楽音情報２７ｂから得た楽音信号との差異が所定値より大きい区間の楽音信号に、所定の効果音を表す楽音信号を重畳して行く。これにより、お手本と同じように演奏できていない演奏区間が所定の効果音により強調された練習用楽音情報が生成される。

ＣＰＵ２１は、生成した練習用楽音情報をバッチ伝送用楽音情報の発信元であったセッション端末１０へ送信する（Ｓ６８０）。
練習用楽音情報を受信した各セッション端末１０の制御部１９は、その練習用楽音情報を記憶部１４に記憶させる（Ｓ６９０）。
そして、演奏者が、自らのセッション端末１０の操作部１８に所定の操作を行うことによって、練習用楽音情報の再生を指示すると、今度は、お手本どおりに演奏されていない箇所が所定の効果音によって強調された自らの演奏が放音されることになる。

以上説明した本実施形態では、セッション管理サーバ装置２０が、各演奏者のセッション端末１０から送信されてくるリアルタイム伝送用楽音情報を基にそれら各演奏者の演奏の巧拙を評価し、評価結果が良好であった演奏者のセッション端末１０からのみバッチ伝送用楽音情報を収集して多重楽音情報を生成するようになっている。従って、演奏内容が良好な演奏者の演奏だけを記録した多重楽音情報を容易に取得することができる。更に、本実施形態では、音楽セッションを終えた各演奏者が、自身の演奏の巧拙の良否にかかわらず、音楽情報加工サービスを利用できるようになっている。このサービスにおいては、セッション管理サーバ装置２０が、セッション端末１０から受信したバッチ伝送用楽音情報から、お手本どおりに演奏できていない箇所を強調した練習用楽音情報を生成して提供するようになっている。従って、このサービスを利用する演奏者は、正しく演奏できていない演奏箇所を容易に把握することができる。

（他の実施形態）
本願発明は、種々の変形実施が可能である。
上記実施形態では、あるセッションルームの音楽セッションが一旦始まってしまうと、その音楽セッションへ他の演奏者が後から参加することはできなかった。これに対し、そのような制限を設けずに音楽セッションへの途中参加が許容されるようにしてもよい。その場合、新たに参加してきた演奏者のセッション端末１０に対しては、音楽セッションの当初からの演奏内容を記録した多重楽音情報を提供するようにしてもよいし、新たな参加があった後の演奏内容のみを記録した多重楽音情報を提供するようにしてもよい。

セッション管理サーバ装置２０は、多重楽音情報だけでなくこれに各演奏者の動画像情報を対応付けることによってプロモーションビデオを生成するサービスを行なってもよい。この変形例は、各セッション端末１０に、演奏者の演奏している様子を撮像するための撮像手段を搭載させることによって実現可能である。この変形例において、セッション管理サーバ装置２０は、音楽セッションの終了後に各セッション端末１０から送信されてくるバッチ伝送用楽音情報と動画像情報とを適宜編集することによって、プロモーションビデオを生成することになる。

上記実施形態では、音楽セッションからの離脱を求めるメッセージを受信したセッション管理サーバ装置２０が、その発信元であるセッション端末１０にバッチ伝送用楽音情報の送信を求め、求めに応じたセッション端末１０がバッチ伝送用楽音情報を送信するようになっていた。これに対し、各セッション端末１０は他のタイミングでバッチ伝送用楽音情報を送信するようにしてもよい。要するに、セッション管理サーバ装置２０を介したリアルタイム伝送用楽音情報の遣り取りが行われていない間であれば、バッチ伝送用楽音情報の送信をいつ行なってもよい。

上記実施形態においては、音楽セッションを行っているセッション端末１０が、リアルタイム伝送用楽音情報とバッチ伝送用楽音情報とを個別に生成し、リアルタイム伝送用楽音情報はその生成後直ちにセッション管理サーバ装置２０へ送信する一方、バッチ伝送用楽音情報は音楽セッションの終了後に改めて送信するようになっていた。これに対し、リアルタイム伝送用楽音情報の送信の妨げとならない限りにおいて、音楽セッションの終了前にバッチ伝送用楽音情報の送信を行なってもよい。例えば、リアルタイム伝送用楽音情報の送信に用いられる帯域の隙間を用いてバッチ伝送用楽音情報の送信を行うようにすれば、リアルタイム伝送用楽音情報の送信との両立も可能である。この変形例によると、音楽セッションの終了後、バッチ伝送用楽音情報の送信の完了までに要する待ち時間を減らすことができる。
また、上記実施形態においては、リアルタイム伝送用楽音情報とバッチ伝送用楽音情報のビットレートはセッション管理サーバ装置２０が設定するものであったが、演奏者自身がこれを設定できるようにしてもよい。更に、ビットレートだけでなく、各々の楽音情報を生成する際の圧縮方式（例えば、可逆圧縮か付加逆圧縮か）をも演奏者が設定できるようにしてもよい。

第２実施形態では、ある演奏者のセッション端末１０から受信したリアルタイム伝送用楽音情報の評価ポイントが閾値を超えると、そのセッション端末１０に対してバッチ伝送用楽音情報の送信が直ちに求められるようになっていた。これに対し、評価ポイントをセッション端末１０に送信した上で、バッチ伝送用楽音情報の送信の有無を演奏者に委ねるようにしてもよい。また、第２実施形態の音楽情報加工サービスでは、バッチ伝送用楽音情報から復元された楽音信号のうちお手本とのずれが大きかった演奏区間に効果音の楽音信号を重畳することによって練習用楽音情報を生成していた。これに対し、お手本とのずれが大きかった演奏区間の楽音信号を課題曲模範楽音情報のそれと差し替えることによって練習用楽音情報を生成するようにしてもよい。

セッションシステムの全体構成図である。 セッション端末のハードウェア構成図である。 セッション管理サーバ装置のハードウェア構成図である。 セッション管理テーブルのデータ構造図である。 セッション開始処理を示すフローチャートである。 セッションルーム案内画面である。 参加状況通知画面である。 セッション離脱処理を示すフローチャートである。 セッション管理サーバ装置のハードウェア構成図である。 セッション評価処理を示すフローチャートである。 演奏評価管理テーブルのデータ構造図である。 セッション離脱処理を示すフローチャートである（前半部分）。 セッション離脱処理を示すフローチャートである（後半部分）。

符号の説明

１０…セッション端末、１１…楽音信号入力部、１２…楽音信号出力部、１３…通信部、１４…記憶部、１５…エンコード／デコード部、１６…通信速度検出部、１７…表示部、１８…操作部、１９…制御部、２０…セッション管理サーバ装置、２０…同装置、２０…サーバ装置、２１…ＣＰＵ、２２…ＲＡＭ、２３…ＲＯＭ、２４…ネットワークインターフェース、２５…コンピュータディスプレイ、２６…キーボード、２７…ハードディスク

Claims (5)

1. 情報の記憶手段と、
   楽音信号を入力する入力手段と、
   前記入力手段から楽音信号が入力されると、入力された楽音信号に第１のビットレートでの符号化処理を施してリアルタイム伝送用の楽音情報を生成すると共に、当該入力された楽音信号に前記第１のビットレートよりも高い第２のビットレートでの符号化処理を施してバッチ伝送用の楽音情報を生成する符号化手段と、
   前記符号化手段が生成したバッチ伝送用の楽音情報を前記記憶手段に記憶する記憶制御手段と、
   他のセッション端末からリアルタイム伝送用の楽音情報を受信する受信手段と、
   前記受信手段が受信した楽音情報に所定の復号化処理を施して得た楽音信号を出力する出力手段と、
   前記符号化手段によって生成されるリアルタイム伝送用の楽音情報を前記他のセッション端末へ送信すると共に、所定のタイミングで、前記記憶制御手段によって前記記憶手段に記憶されていたバッチ伝送用の楽音情報を外部の特定の装置へ送信する送信手段と
   を備えるセッション端末。
2. 請求項１に記載のセッション端末において、
   前記送信手段は、
   リアルタイム伝送が行われていない間に前記記憶手段に記憶されていたバッチ伝送用の楽音情報を前記特定の装置へ送信する
   セッション端末。
3. 請求項１又は２に記載のセッション端末において、
   前記記憶制御手段は、
   前記符号化手段が生成した時刻の情報と共にバッチ伝送用の楽音情報を前記記憶手段に記憶し、
   前記受信手段は、
   前記送信手段が前記特定の装置へバッチ伝送用の楽音情報を送信した後、自端末と他のセッション端末から送信されていた各バッチ伝送用の楽音情報を前記時刻情報を基にミキシングして得られた多重楽音情報を前記特定の装置から受信し、
   前記出力手段は、
   前記受信手段が受信した多重楽音情報に所定の復号化処理を施して得た楽音信号を出力する
   セッション端末。
4. 請求項１に記載のセッション端末において、
   さらに前記リアルタイム伝送用の楽音情報は前記特定の装置へ送信されるものであり、
   前記特定の装置より、送信したリアルタイム伝送用の楽音情報と前記特定の装置内で保持する模範楽音情報を比較することによって求められる差異情報を前記受信手段が受信すると、その差異情報に応じて前記バッチ伝送用の楽音情報を前記特定の装置へ送信する
   ことを特徴とするセッション端末。
5. 請求項１に記載のセッション端末において、
   前記受信手段は、
   前記送信したバッチ伝送用の楽音情報に対して模範楽音情報との差異点を強調するような加工を施して得られた練習用楽音情報を受信する
   ことを特徴とするセッション端末。

Images