JP3994993B2 - データ処理方法 - Google Patents

Description

本発明は、クライアント・サーバ方式における波形データ等の処理に用いて好適なデータ処理方法、データ処理装置および記録媒体に関する。

電子楽器のメモリ音源等に使用される波形データは、自然楽器音を録音した波形あるいは人工的に合成した波形に対して種々の演算処理を施して生成される。これら波形データの処理の中には多大な演算時間を要するものもあるため、各ユーザ（波形データの開発者）が各１台のコンピュータを用いて全ての作業を行おうとすると、待ち時間が多くなり作業効率が悪化する。このため、従来よりネットワーク上に演算速度の高い共用のサーバが設けられ、各ユーザの使用するコンピュータ（クライアント機）からの処理要求に応じて必要な演算処理が行われていた。

具体的には、サーバはＷＷＷサーバとして構築され、ネットワーク上のクライアント機に対してホームページが提供される。そして、各ユーザが、各クライアント機上でブラウザ等を使用して該ホームページを開くと、サーバにて提供可能な処理サービスがリストアップされる。各ユーザは、そのリスト上で所望の処理サービスを選択し、必要に応じて所定のデータや所定のパラメータ等を入力する。サーバ側においては、指定された処理サービス、データ、パラメータ等に応じて演算処理が行われ、演算処理が完了すると対応するクライアント機に対して処理が終了した旨が通知される。そして、ユーザは、この通知を見て、サーバから演算処理結果を受信していた。

しかし、上述した技術によれば、処理サービスの依頼手順は、以下のようにきわめて煩雑であった。
すなわち、ユーザは、ホームページを開き、そのホームページ上で所望の項目（処理サービス）を選択し、依頼内容を入力するという一連の操作を行わなければならない。また、ブラウザの１枚のページ（ウィンドウ）では１種類の処理サービスについてのみ入力が可能であったため、複数の処理サービスを依頼する場合には、複数のページを開いて入力を行う必要があった。また、各処理サービスに対応するページは、ページ毎にユーザインターフェースが異なる場合もある。さらに、これらページ毎に、ユーザは所定のデータや所定のパラメータ等を入力しなければならない。

この発明は上述した事情に鑑みてなされたものであり、様々な処理サービスを簡易な方法で提供するデータ処理方法、データ処理装置および記録媒体を提供することを目的としている。

上記課題を解決するため本発明にあっては、下記構成を具備することを特徴とする。なお、括弧内は例示である。
請求項１記載のデータ処理方法にあっては、ネットワークに接続されたサーバを構成するデータ処理装置で実行されるデータ処理方法であって、前記データ処理装置は、該ネットワークに接続されたクライアントから処理対象ファイルまたはパラメータファイルを読み書き可能な複数の処理ディレクトリを備えているとともに、所定時間毎に、該複数の処理ディレクトリを順次確認する処理ディレクトリ確認プロセスを起動し、該プロセスは、確認対象の処理ディレクトリ内に処理対象ファイル（波形データ切り分けディレクトリ内のAIFFファイル）が存在するか否かを判定する第１判定過程（ＳＰ６８）と、該処理ディレクトリ内に所定のパラメータをテキストで記述したテキストファイルである前記パラメータファイル（波形データ切り分けディレクトリ内のcut.txt）が存在するか否かを判定する第２判定過程（ＳＰ７６）と、前記処理対象ファイルが存在しかつ前記パラメータファイルが存在しない旨が判定されると、該処理対象ファイルに対して当該処理ディレクトリに対応する第１処理（波形データ切り分けの「自動モード」処理）を施す一方、前記処理対象ファイルが存在しかつ前記パラメータファイルが存在する旨が判定されると、該処理対象ファイルに対して、該パラメータファイルにテキストで記述されたパラメータを用いて当該処理ディレクトリに対応する第２処理（波形データ切り分けの「手動モード」または「半自動モード」処理）を施す処理過程（ＳＰ７６）とを含むことを特徴とする。
さらに、請求項２記載の構成にあっては、請求項１記載のデータ処理方法において、前記処理過程において前記処理対象ファイルに対して前記第２処理を行う場合、その処理結果として複数の処理結果ファイルが出力され、前記パラメータファイルには、これら出力される複数の処理結果ファイルに各々対応する複数のパラメータが記憶されていることを特徴とする。
さらに、請求項３記載の構成にあっては、請求項１記載のデータ処理方法において、さらに、前記パラメータファイルではモード指定（波形データ切り分けの「手動モード」または「半自動モード」）を行うことが可能であり、前記処理過程において前記処理対象ファイルに対して前記第２処理を行うとき、該パラメータファイルで前記モード指定が行われているか否かに応じて異なる処理を施すことを特徴とする。
さらに、請求項４記載の構成にあっては、請求項３記載のデータ処理方法において、前記処理過程における前記第２処理において、前記パラメータファイルに記述されたテキスト中に前記モードを指定する特定の文字列（[NoAuto]）を検出した場合は、第１の態様（手動モード）にて前記第２処理を施し、他の場合には第２の態様（半自動モード）にて前記第２処理を施すことを特徴とする。
さらに、請求項５記載の構成にあっては、請求項１ないし４の何れかに記載のデータ処理方法において、前記パラメータファイルには、前記処理過程にて一の処理対象ファイルに対して前記第２処理を施すための複数のパラメータがテキストで記述されていることを特徴とする。

このように、本発明によれば、複数のディレクトリが自動的に検索され、処理対象ファイルが存在する場合には、その属するディレクトリに対応する処理が自動的に実行されるから、ユーザに対して様々な処理サービスを簡易な方法で提供することができる。

1．実施例の構成
次に、本発明の一実施例のネットワークシステムの構成を図１を参照し説明する。
図において１００はネットワーク（インターネットまたはイントラネット）であり、サーバ１１０と、クライアント機１２０，１３０，…，１９０とが接続されている。サーバ１１０の内部において２はハードディスクであり、オペレーティングシステムと、該オペレーティングシステムの上で動作する種々の処理サービスのアプリケーションプログラム、その他各種のデータを格納する。４は、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ等のリムーバルディスクであり、ハードディスク２と同様の情報を格納する。６は表示器であり、ユーザ（システム管理者）に対して各種情報を表示する。

８は入力装置であり、キーボード、マウス等から構成され、ユーザによって各種の情報が入力される。１８はネットワークインターフェースであり、ネットワーク１００を通して各クライアント機１２０，１３０，……，１９０との間で情報のやりとりを行う。２０はＣＰＵであり、後述する制御プログラムに基づいて、バス１４を介してサーバ１１０内の各部を制御する。２２はＲＯＭであり、イニシャルプログラムローダ等が格納されている。２４はＲＡＭであり、ＣＰＵ２０のワークメモリとして使用される。

次に、クライアント機１２０の内部において、構成要素３２，３４，３６，３８，４８，５０，５２，５４は、上記サーバ１１０の構成要素２，４，６，８，１８，２０，２２，２４と同様に構成されている。４０はサウンドボードであり、供給された演奏情報（ＭＩＤＩ信号）に基づいて波形メモリから波形データを読み出して楽音信号を生成する波形メモリ音源と、外部から入力されたアナログ信号をデジタルの波形データに変換してＲＡＭ５４に記憶させるＡＤコンバータとから構成されている。なお、上記波形メモリは、サウンドボード４０の内部にあってもよく、ＲＡＭ５４またはハードディスク３２上にあってもよい。サウンドボード４０内の音源によって生成された楽音信号は、サウンドシステム４２を介して発音される。４６はＭＩＤＩインタフェースであり、外部のＭＩＤＩ機器との間でＭＩＤＩ信号をやりとりする。クライアント機１３０，……，１９０もクライアント機１２０と同様に構成されている。

ここで、サーバ１１０のハードディスク２等におけるディレクトリ構造を図２を参照し説明する。サーバ１１０のルートディレクトリ２００には、システムディレクトリ２１０、ホームディレクトリ２２０およびその他のディレクトリ２３０が設けられている。また、ホームディレクトリ２２０には、ネットワーク１００に対してログオン可能なユーザの各々に対して、ユーザディレクトリ２２１，２２２，……，２２ｎが設けられている。各ユーザディレクトリ２２１，２２２，……，２２ｎには、ユーザ名、パスワード等によるアクセス制限がかけられている。すなわち、各ユーザディレクトリには、対応するユーザ、システム管理者および各処理サービスプログラムのみがアクセス可能になっている。

2．実施例の動作
2．1．クライアント機における動作
2．1．1．ログイン（認証）処理
次に、本実施例の動作を説明する。
まず、ユーザは、何れかのクライアント機１２０，１３０，……，１９０において所定のアプリケーションプログラム（主としてターミナルエミュレータ）を立ち上げると、このアプリケーションプログラムのウィンドウにプロンプトが表示される。ここで、図３(a)に示す操作がユーザにより行われる。まず、ユーザが「login」とタイプし、続いてユーザ名を入力すると、このユーザ名が正しいか否かがサーバ１１０によって判定される（以上ステップＳＰ２）。正しいユーザ名であれば、パスワードの入力要求がクライアント機のウィンドウに表示される。ユーザが正しいパスワードを入力すると（ステップＳＰ４）、サーバ１１０内の該ユーザに対応するユーザディレクトリにアクセス可能になる。

2．1．2．処理サービス依頼
次に、ユーザがサーバ１１０に対して処理サービス依頼を行う際の動作を同図(c)を参照し説明する。まず、ステップＳＰ１２において、ユーザは、処理対象となるデータファイルと、（必要に応じて）パラメータファイルとを準備する。具体的には、クライアント機のファイル操作アプリケーションによってアクセス可能な場所にこれらデータ等が準備される。

ここで本明細書における「データファイル」および「パラメータファイル」の意義について説明しておく。「データファイル」には、処理対象となる「主データ」と、（必要な場合には）「補助データ」とが含まれる。例えば、データファイルが波形データファイルである場合、「主データ」とは波形のサンプリングデータを指す。また、「補助データ」としては、サンプリング周波数、オリジナルピッチ、スタートアドレス、エンドアドレス、ループアドレス等のパラメータが該当する。また、「パラメータファイル」は、補助データに含まれていないパラメータを指定する必要がある場合に作成される。

図３(c)に戻り、ユーザは、次にステップＳＰ１４において、サーバ１１０上の対応するユーザディレクトリのウィンドウをオープンする。ここで、ユーザディレクトリのウィンドウをオープンした状態においてクライアント機の表示器３６の表示状態の例を図４に示す。図４において３００はデスクトップウィンドウであり、ここに処理対象となるデータファイルのアイコン３０１，３０２が表示されている。また、ウィンドウ３１０は、対応するユーザディレクトリの内容を表示している。ユーザディレクトリには、処理サービスの内容毎に異なる処理ディレクトリが設けられている（但し、詳細は後述するが、複数の処理サービスが同一処理ディレクトリを共用することもある）。そして、ウィンドウ３１０内においては、各処理ディレクトリに各々対応するアイコン３１１〜３１８が表示されている。

図３(c)に戻り、ユーザは、データファイルおよび（必要に応じて）パラメータファイルを所望の処理サービスに対応する処理ディレクトリにコピーする。かかる操作は、クライアント機のオペレーティングシステムが対応している場合には、ドラッグアンドドロップ操作により為すことができる。例えばアイコン３０１に対応する波形データファイルに対して「波形データループ作成処理」を施し、アイコン３０２に対応する曲データに対して「メロディ表情付与処理」を施すのであれば、アイコン３０１をアイコン３１２上に、アイコン３０２をアイコン３１８上に、各々ドラッグアンドドロップするとよい。なお、パラメータファイルが必要な場合は、該パラメータファイルのアイコンを、対応するデータファイルのアイコンと同一の処理ディレクトリにドラッグアンドドロップするとよい。

2．1．3．処理サービス結果受領およびログアウト処理
さて、サーバ１１０においては、各処理ディレクトリ上のファイルに対して各ディレクトリに応じた処理サービスが行なわれ、その結果が各処理ディレクトリ内に処理結果ファイルとして書込まれる（詳細は後述する）。なお、処理結果ファイルのファイル名は、元のデータファイルのファイル名に対して所定の対応関係を有しつつ異なるファイル名に設定される。ユーザは処理依頼に係るディレクトリのウィンドウを開き（図３(d)のステップＳＰ２２）、処理結果ファイルの内容を確認する（ステップＳＰ２４）。そして、ユーザは、所望の処理サービス結果を受領した場合には、ターミナルエミュレータ等のプロンプトにおいて「logout」とタイプする（図３(b)ステップＳＰ６）。これにより、サーバ１１０と当該クライアント機との接続が終了する。

2．2．サーバ１１０における動作
2．2．1．ユーザディレクトリ確認処理
サーバ１１０においては、所定時間（例えば１０分）毎に図５に示すユーザディレクトリ確認処理ルーチンが起動される。すなわち、当ルーチンは、マルチタスク処理により、並列して起動された複数のプロセスにおいて個別に実行される。
図において処理がステップＳＰ３０に進むと、既に起動されているユーザディレクトリ確認処理ルーチンのプロセスが検出される。次に処理がステップＳＰ３２に進むと、既に起動されているユーザディレクトリ確認処理ルーチンのプロセスが３以上であるか否かが判定される。ここで「ＹＥＳ」と判定されると、本ルーチンの処理は終了する。これは、ユーザディレクトリ確認処理ルーチンを過度に立ち上げるとリソースが無駄になるため、該ルーチンのプロセス数を「３」に限定したものである。

一方、ステップＳＰ３２において「ＮＯ」と判定されると、処理はステップＳＰ３４に進み、ユーザリスト（全ユーザを羅列したリスト）の中から一人目のユーザが処理対象として指定される。次に処理がステップＳＰ３６に進むと、「該指定されたユーザのユーザディレクトリが存在し、かつ、該ユーザディレクトリがロックされていない」か否かが判定される。ここで、「ロックされている」とは、該ユーザディレクトリ中に「ロック中」であることを示す所定の「ロックファイル」が存在することを意味し、具体的には他のプロセスのユーザディレクトリ確認処理ルーチンによって当該ユーザディレクトリが処理中である、という意味である。

ユーザディレクトリが存在しない場合あるいは当該ユーザディレクトリがロック中である場合は「ＮＯ」と判定され、処理はステップＳＰ５０に進む。ここでは、全ユーザに対して処理対象としての指定が行われたか否かが判定される。ここで、「ＮＯ」と判定されると、処理はステップＳＰ５２に進み、次のユーザが処理対象として指定される。そして、対応するユーザディレクトリが存在し、かつ、該ユーザディレクトリがロック中でなければステップＳＰ３６において「ＹＥＳ」と判定され処理はステップＳＰ３８に進む。

ステップＳＰ３８においては、該ユーザディレクトリに対してロックファイルが書き込まれ、これによって他のプロセスのユーザディレクトリ確認処理ルーチンによる当該ユーザディレクトリの操作等が禁止される。そして、カウンタ変数ｉに「１」が代入される。なお、このカウンタ変数ｉは、ユーザディレクトリ内の各処理ディレクトリに昇順に付与された番号に対応する。次に、処理がステップＳＰ４０に進むと、ｉ番目の処理ディレクトリが存在するか否かが判定される。ここで「ＮＯ」と判定されると、全処理ディレクトリについて検索が終了したか否かが判定される。まだ検索されていない処理ディレクトリが存在すればここで「ＮＯ」と判定され、処理はステップＳＰ４６に進む。ここではカウンタ変数ｉが「１」だけインクリメントされ、処理はステップＳＰ４０に戻る。

ここで、ｉ番目の処理ディレクトリが存在すればステップＳＰ４０において「ＹＥＳ」と判定され、処理はステップＳＰ４２に進む。ここではｉ番目のディレクトリに対するＤｉ確認処理ルーチン（詳細は後述する）が呼び出され、処理はステップＳＰ４４に進む。以下、全処理ディレクトリに対して上記検索処理が終了すると、ステップＳＰ４４において「ＹＥＳ」と判定され処理はステップＳＰ４８に進む。ここでは、当該ユーザに対するアンロック処理が行われる。すなわち、ユーザディレクトリ内のロックファイルが削除され、処理はステップＳＰ５０に進む。そして、全ユーザに対して処理対象としての指定が行われ、上述した処理が完了すると、ステップＳＰ５０において「ＹＥＳ」と判定され、当該ユーザディレクトリ確認処理ルーチンのプロセスが終了する。

このように、本実施例においては、複数のプロセスにおいてユーザディレクトリ確認処理ルーチンが実行され、各プロセスにおいて処理中のユーザディレクトリがロックされるから、プロセス間の干渉を防止することができる。さらに、あるプロセスにおいて処理時間の長い処理サービスを実行している時、他のプロセスはこのプロセスを追い越して次のユーザに対する処理サービスを開始することができる。このため、あるユーザが処理時間の長い処理サービスを依頼したとしても、他のユーザの処理サービスをあまり遅らせることなく実行することができる。

2．2．2．Ｄｉ確認処理
次に、ステップＳＰ４２において呼び出されるＤｉ確認処理ルーチンの詳細を図６を参照し説明する。
図において処理がステップＳＰ６０に進むと、処理開始時刻がファイルSTIMEに記憶される。なお、ファイルSTIMEは、各処理ディレクトリ毎に設けられるファイルである。次に、処理がステップＳＰ６２に進むと、当該処理ディレクトリにファイルPTIMEが存在するか否かが判定される。なお、ファイルPTIMEとは、この処理ディレクトリに対して、Ｄｉ確認処理ルーチン（図６）が前回開始された時刻を記憶するファイルである。ここで「ＮＯ」と判定されると処理はステップＳＰ６４に進み、カウンタ変数ｉに係る処理サービスの対象となるデータファイルがサーチされる。

一方、ステップＳＰ６２において「ＹＥＳ」と判定されると、処理はステップＳＰ６６に進み、ｉ番目の処理サービスの対象となるデータファイルのうち、ファイルPTIMEに示される前回の処理開始時刻よりも新しいデータファイルが検索される。ここでは、Ｄｉ確認処理の開始時にＤｉ確認処理の処理開始時刻（ファイルSTIME）と、前回の開始時刻（ファイルPTIME）とに基づいて処理すべきデータファイルが確定される。従って、たとえＤｉ確認処理の実行中に新たなデータファイルが当該ディレクトリに書き込まれたとしても、次回のＤｉ確認処理において、該新たなデータファイルが処理対象のデータファイルとして適切に検出される。但し、Ｄｉ確認処理において処理中のデータファイル（確定されたデータファイル）については、ステップＳＰ６４ないしＳＰ６６においてファイルロックされ、Ｄｉ確認処理（ないし後述するステップＳＰ７６の処理）が終了するまで書き換えができないようになっている。

ステップＳＰ６４，ＳＰ６６の処理が終了すると、処理はステップＳＰ６８に進む。ここでは、先のステップＳＰ６４，ＳＰ６６の検索結果により処理対象のデータファイルが存在したか否かが判定される。データファイルが存在すれば「ＹＥＳ」と判定され処理はステップＳＰ７０に進む。ステップＳＰ７０においては、処理ディレクトリ内のログファイルに、「処理サービスが開始された」旨が記録される。なお、処理ディレクトリ内にログファイルが存在しない場合には、新たにログファイルが生成され、同旨が記録される。次に、処理がステップＳＰ７２に進むと、処理対象となるデータファイルのうち一つめのデータファイルが指定される。次に、処理がステップＳＰ７４に進むと、ログファイルに上記指定されたデータファイル名が記録される。次に、処理がステップＳＰ７６に進むと、この指定されたデータファイルに対して、該ｉ番目の処理ディレクトリに対応する処理サービスｉが実行される。

次に、処理がステップＳＰ７８に進むと、該処理ディレクトリにおいて、処理すべき他のデータファイルが残っているか否かが判定される。ここで「ＹＥＳ」と判定されると、処理はステップＳＰ８０に進み、次のデータファイルが処理対象として指定され、上記ステップＳＰ７４，ＳＰ７６の処理が実行される。このようにして全ての処理対象のデータファイルに対して処理サービスｉが実行されると、ステップＳＰ７８において「ＮＯ」と判定され、処理はステップＳＰ８２に進む。

ここでは、ログファイルにおいて「処理サービスが完了した」旨が記録される。次に、処理がステップＳＰ８４に進むと、ファイルSTIMEに記録された処理開始時刻がファイルPTIME内に記録され、本ルーチンの処理が完了する。なお、ステップＳＰ６４，ＳＰ６６において処理対象となるデータファイルが存在しなかった場合はステップＳＰ６８において「ＮＯ」と判定され、直ちにステップＳＰ８４において処理開始時刻がファイルPTIME内に記録され、本ルーチンの処理が完了する。

本ルーチンの処理によれば、処理状況がログファイルに逐次記録されるから、ユーザはこのログファイルを参照して処理の進捗状況を確認することができる。また、ファイルPTIMEが存在する場合には、ここに記録された前回の処理開始時刻に応じて処理対象となるデータファイルを決定するから（ステップＳＰ６６）、同一のデータファイルに対する同一の処理サービスを繰り返すような無駄を排除することができる。

2．3．各処理サービスの具体的例
次に、上記ステップＳＰ７６において実行される様々な処理の具体例を説明する。
2．3．1．波形データ分析
本処理サービスは、「波形データ分析」という名前の処理ディレクトリが存在し、かつ該ディレクトリに波形データファイル（AIFFファイル）が存在する場合に実行される。なお、波形データファイルは、16bitリニアのモノラルのAIFFファイルで、正しいサンプリング周波数と、MIDI Key番号(音高情報のこと)が設定されている。

本処理サービスにおいては、この原波形データ(名前.aif)がＦＦＴ分析され、時間軸上で連続している成分である決定論的成分(名前_S.stf, 名前_SD.aif)と、それ以外の切れ切れの成分である残留成分(名前_SX.aif)とに分離され出力される。ここでは、まず原波形データに対して、所定長さの窓関数が施され、該窓関数の範囲内における周波数成分が解析される。窓関数の長さは、原波形データのサンプリング周波数と音高情報とに基づいて、例えばそのピッチ周期の例えば８倍の長さに設定される。なお、ファイル名内における「名前」の部分は、ファイル命名規則に従った任意の文字列が指定される。これは後述する他の処理サービスについても同様である。

次に、窓関数の位置が時間軸上で該ピッチ周期の１／８だけ後ろにシフトされ、同様に周波数成分が解析される。この処理が原波形データ全体に対して繰り返えされると、時間軸上における周波数成分の変化が得られる。この一連の周波数成分のうち時間軸上で連続している成分が決定論的成分になる。次に決定論的成分に基づいて決定論的波形データを合成し、原波形データから決定論的波形データを減算すると、残留成分が得られる。従って、決定論的成分には、楽音のピッチ成分が含まれており、残留成分には楽音の各種ノイズ成分が含まれている。

以上の処理が終了すると、原波形データファイル(名前.aif)に対して、次の３つのファイルが作成される。
(１)名前_S.stf ：決定論的成分を記述したファイル。
(２)名前_SD.aif ：該STFファイルから合成したAIFFファイル。
(３)名前_SX.aif ：原波形データファイル(名前.aif)から波形データ（名前_SD.aif）を減算した残留成分のAIFFファイル。

2．3．2．波形データループ作成
本処理サービスは、「波形データループ作成」という名前の処理ディレクトリが存在し、かつ該ディレクトリに波形データファイル（AIFFファイル）が存在する場合に実行される。なお、波形データファイルは、16bitリニアのモノラルまたはステレオのAIFFファイルで、正しいサンプリング周波数と、MIDI Key番号と、適切なループスタート・エンドマーカーとが設定されている。

また、同処理ディレクトリにloop.txtという名前のテキストファイルがある場合は、その記載内容に基づいて、波形データファイルのセンターキー、ループスタート、ループエンドを設定するとともに、ループ作成態様の制御も行なうことが可能である。ここで、loop.txtの記載例を以下に示しておく。
-------------------------------------
[Loop Set]
名前1.aif 63 2373 2475 off on
#名前2L.aif 63 2373 2475 off off
名前2.aif 61 2370 2470 50 on
-------------------------------------
上記例において先頭文字が「#」である行はコメント行である。「名前1.aif」等は波形名であり、その後のパラメータは、順に、センターキー、ループスタート、ループエンド、ピッチ調整のオンオフ(上記例の「50」はループの50％前からピッチ調整を行うことを示す)、サンプリング周波数変換のオンオフを各々指標する。

本処理サービスにおいては、原波形データの波形データ分析が行なわれ、各周波数成分についてループ終端と先端においてレベル、位相が合うように再合成される。ここで、倍音以外の成分は周波数帯ごとに細かく分類され、なるべくフラットになるようにクロスフェードループが施され、上記再合成したデータに足し込まれる。また、loop.txtにおいて「ピッチ調整」がオンに指定されている場合は、アタックのピッチとループのピッチを合わせるためのピッチ調整も行なわれる。さらに、loop.txtにおいて「サンプリング周波数変換」がオンに指定されている場合は、ループのピッチが波形データファイルの MIDI Key番号に適合するように波形データのサンプリング周波数が変換される。

以上の処理により、本処理サービスにおいては、下記４つのファイルが作成される。
(１)名前_L0.aif ：ループ内のピークの変動をゼロにした波形データファイル。
(２)名前_L1.aif ：基音の位相がピッチの整数倍になる様調整された波形データファイル。
(３)名前_L2.aif ：基音と２倍音の位相がピッチの整数倍になる様調整された波形データファイル。
(４)名前_L3.aif ：全ての倍音の位相がピッチの整数倍になる様調整された波形データファイル。

ここで、得られたパラメータや波形データの使用方法について概要を説明しておく。上述した処理によって切り分けられた各波形データファイルの波形データは、選択的に波形メモリに記憶させることができる。前述したように、波形メモリ音源においては、波形メモリから波形データが読み出され、読み出された波形データに基づいて楽音が生成される。波形メモリ音源において、上記センターキーは、演奏情報で指定された音高の楽音を生成するために波形データをピッチシフトする際のピッチシフト量を決定するために使用される。また、波形メモリ音源においては、上記ループスタートおよびループエンドに基づいて波形データの一部をループ読出しすることが可能である。すなわち、波形データの先頭からループエンドまで一通り波形データを読み出した後、読出し制御位置をループスタートに戻し、ループスタートからループエンドの間を繰り返し読み出すように制御される。

2．3．3．波形データノイズ除去
本処理サービスは、「波形データノイズ除去」という名前の処理ディレクトリにが存在し、かつ該ディレクトリに波形データファイル（AIFFファイル）が存在する場合に実行される。なお、波形データファイルは、16bitリニアのモノラルのAIFFファイルで、正しいサンプリング周波数と、MIDI Key番号が設定されている。本処理サービスにおいては、原波形データ(名前.aif)に設定された音高情報に対応する基音の２／３オクターブ以下の周波数成分がカットされ出力される。この低い周波数成分がカットされた波形データは、「名前_C.aif」なるファイル名で出力される。

2．3．4．波形データ切り分け
本処理サービスは、「波形データ切り分け」という名前の処理ディレクトリが存在し、かつ該ディレクトリに波形データファイルが存在する場合に実行される。ここで、波形データファイル(名前.aif)は、16bitリニアのモノラルorステレオのAIFFファイルである。また、同ディレクトリにcut.txtという名前のテキストファイルがある場合は、その記載内容に応じた動作が実行される。ここで、cut.txtの記載例を以下に示す。

＜cut.txtの記載内容例１（半自動モード）＞
-------------------------------------
[名前] 出力名 4 1
021 64 92610 127890 135000
022 64 92610 127890 135000
023 64 92610 127890 135000
024 64 92610 127890 135000
[名前(次の波形の名前)] 3 0
：
-------------------------------------

上記例１において、１行目の[名前]の部分は、処理対象となる波形データファイル名を示す。また、「出力名」は、出力結果のファイル名の先頭文字列を表す任意の（ファイル命名規則に従った）文字列が指定される。これに続く数字（上記例１では「4」）は、切り出し数を示し、最後の数字はノーマライズのオンオフを示す。例１の２行〜４行の各行においては、切り出し数に応じた各切り出し波形（１つ目〜４つ目）のパラメータが記述される。すなわち、各行において、左からkey番号、タッチ、ループスタート、ループエンドおよび切り出しサイズが各々指定される。そして、５行目以降は、他の波形データファイルについて、同様の内容が繰り返される。

次に、cut.txtの他の記載例を以下に示す。
＜cut.txtの記載内容例２（手動モード）＞
-------------------------------------
[No Auto]
[名前] 出力名 4 0
021 64 92610 127890 135000 124616
021 64 92610 127890 135000 520800
021 64 92610 127890 135000 916181
021 64 92610 127890 135000 131259
[名前(次の波形の名前)] 3 1
：
-------------------------------------

上記例２において、１行目の[No Auto]の部分は、「手動モード」（波形の切り出しスタート位置をユーザが手動で設定するモード）の選択指定を示す。２行目および３〜６行目においては、上記例１の１行目および２〜５行目と同様のパラメータを指定を指定するが、３〜６行目においては、最後に「切り出しスタート位置」のパラメータが追加される。

本処理サービスにおいては、原波形データの波形のレベルと長さに基づいて、１つの原波形データファイルが複数の波形データファイルに切り分けられる。
まず、処理ディレクトリ内にcut.txtが存在しない場合、動作モードは「自動モード」に設定される。この動作モードでは、波形のレベルが所定の＃１閾値を超える位置から立上がりが検出され、その後に所定の＃２閾値を下回る位置から立下がりが検出され、その立上がりから立下がりまでの区間が個々の波形データファイルとして出力される。

また、処理ディレクトリ内にcut.txtが存在し、cut.txt内に「手動モード」の指定が無い場合（上記例１）、動作モードは「半自動モード」に設定される。この動作モードでは、立上がりは自動検出されるが、立下がりの自動検出は行われず、該立上がりから指定されたサイズの範囲が切り出され、個々の波形データファイルとして出力される。また、手動モード（上記例２）においては、立上がり、立下がりとも検出されず、指定されたスタート位置から指定されたサイズの波形が切り出され、その部分が個々の波形データファイルとして出力される。

自動モードにおいて出力される波形データのファイル名は、原波形データファイルのファイル名に対応して、「名前_mm-ss_num_key[ _L or _R].aif」の形式に設定される。ここに、「mm-ss」の部分は波形の長さを示し、「num」は切り出し順、「key」は検出されたkey番号を示す。また、「[ _L or _R]」の部分は、原波形データファイルがステレオファイルである場合にのみ、「_L」または「_R」に設定される。

また、半自動モードおよび手動モードにおいては、出力される波形データのファイル名は「出力名_vel_key[ _L or _R].aif」の形式に設定される。ここに「vel」は指定されたタッチ、「key」は指定されたkey番号を示し、「[ _L or _R]」の部分は自動モードの場合と同様である。また、cut.txtにおいて「ノーマライズのオン」が指定された原波形データファイルが少なくとも一つ存在すれば、処理ディレクトリ内に「nlevel.txt」なるファイルが作成される。このファイルの記載内容例を以下に示す。

-------------------------------------
出力名_vel_key_L.aif, 68
出力名_vel_key_R.aif, 70
-------------------------------------
上記例において、「出力名_vel_key_L.aif」、「出力名_vel_key_R.aif」の部分は、上述した命名規則に従った出力ファイル名であり、その後に続く数字「68」，「70」がノーマライズレベルを示す。

2．3．5．メロディ分析
本処理サービスは、「メロディ分析」という名前の処理ディレクトリが存在し、かつ該ディレクトリに第１形式（例えばスタンダードMIDIファイル：名前.MID）の曲データファイルが存在する場合に実行される。この第１形式のデータファイルには、複数パート分の演奏情報シーケンスを記憶させることが可能である。本処理サービスにおいては、単一演奏パートの曲データが分析され、曲の調が検出されるとともに、該曲データが複数区間に分割され各区間のコードが決定される。なお、曲データファイルが複数パートを含む場合は、パート番号が最小であるパートのデータだけが分析される。
そして、曲の調について、複数の候補が検出された場合は、それぞれの調について分析が行なわれ対応する複数のファイルが出力される。

この結果、「名前_key.XWS」なる第２形式の複数の曲データファイルが処理ディレクトリ内に生成される。なお、第２形式の曲データファイルには、複数パート分の演奏情報シーケンスに加え、そのマスタートラックに伴奏用のコードシーケンス、スタイルシーケンスおよびウエーブトラックを記憶させることが可能である。生成された曲データファイルのマスタートラックには、決定されたコードが記憶されている。また、コードの候補が複数発見された場合、採用されなかったコードも候補として記憶される。ファイル名中の「key」の部分は、そのファイルの決定された調を示す。なお、「マスタートラック」とは、特定の演奏パートには属さず、複数演奏パート全体を制御するトラックをいう。ここで曲の名前、SMPTEオフセット、マーカー、テンポ、拍子、コード、調、マスタボリューム、システムエフェクト等が指定される。

クライアント機１２０のＣＰＵ５０は、ＲＡＭ５４に記憶された自動演奏プログラムを実行することにより、第１形式ないし第２形式の曲データファイルに基づく自動演奏を行うことができる。該自動演奏において発生した演奏情報は波形メモリ音源に供給され、波形メモリ音源にて該演奏情報に対応した楽音が生成される。

2．3．6．メロディ生成
本処理サービスは、「メロディ分析」という名前の処理ディレクトリが存在し、かつ該ディレクトリに上記第１形式とは異なる形式（例えば上記第２形式の独自フォーマットの曲ファイル：名前.XWS）の曲データファイルが存在し、さらに「arrange.txt」なるファイル名のテキストファイルが存在しない場合に実行される。

本処理サービスにおいては、該曲データファイルの内容がサーチされ、ここにコード進行データが記憶されていなかった場合には実質的な処理は行われない。また、曲データファイルに演奏パートのデータが記憶されていたとしても、そのデータは使用されない。本処理サービスにおいては、上記コード進行データと乱数とに基づいて３つのメロディが生成され、これらメロディを記述した３つの曲データファイルが出力される。なお、メロディ生成の際に乱数が使用されるため、これら３つのメロディは相互に異なる。

これら３つの曲データファイルには、「名前_01.XWS」，「名前_02.XWS」および「名前_03.XWS」のファイル名が各々付与され、生成されたメロディと、原曲データファイルと同一のコード進行とが記録される。

2．3．7．アレンジ
本処理サービスは、「メロディ分析」という名前の処理ディレクトリが存在し、かつ該ディレクトリに上記第２形式の曲データファイルと、「arrange.txt」なるテキストファイルとが存在する場合に実行される。ここで、arrange.txtの記載内容例を以下に示す。
-------------------------------------
[LoveCheck.XWS]
SlowRock1 60 8 SRock_LCheck.XWS
PopBallad4 75 10 PBallad_LCheck.XWS
-------------------------------------

上記例において、１行目は処理対象となる曲データファイル名を示す。また、２行目以降は、各行が出力される（アレンジされた）曲データファイルに一対一に対応する。２行目以降において、行頭のパラメータは、アレンジ後の楽曲のスタイルを示す。次のパラメータは初期テンポを示し、３番目のパラメータはパート数を示す。また、最後のパラメータは、出力される曲データファイル名を示す。

本処理サービスによれば、原曲データファイルに記憶されている単一パートの演奏とコード進行に基づいて、複数パートの演奏データが生成される。その際、arrange.txtの内容に基づいて、スタイル、初期テンポ、パート数等が指定される。そして、生成された演奏データは、各々指定されたファイル名で出力される。

2．3．8．メロディ表情付与
本処理サービスは、「メロディ表情付与」という名前の処理ディレクトリが存在し、かつ該ディレクトリに第２形式の曲データファイルと、テキストファイル「rendering.txt」とが存在する場合に実行される。ここで、テキストファイル「rendering.txt」の記載内容例を以下に示す。
-------------------------------------
[Relax.XWS]
W.Collins 3 5 Relax_WC.XWS
M.Andreev 7 3 Relax_MA.XWS
-------------------------------------

上記例において、１行目は処理対象となる曲データファイル名を示す。また、２行目以降は、各行が出力される（表情付与された）曲データファイルに一対一に対応する。２行目以降において、行頭のパラメータは、表情付与のスタイルに対応する仮想作曲家名を示す。次のパラメータはテンションを示し、３番目のパラメータは明るさを示す。また、最後のパラメータは、出力される曲データファイル名を示す。

本処理サービスによれば、原曲データファイルに記憶されている１ないし複数パートの演奏データが、仮想演奏家に対応したエキスパートシステムによって分析され、分析結果に基づいて表情付けが行なわれる。ここに表情付けとは、テンポ変化の付与、フレーズや各音符に対する強弱の付与、スラーやスタッカート等の付与等である。そして、生成された演奏データは、各々指定されたファイル名で出力される。

以上のように本実施例によれば、所望の処理サービスに対応した処理ディレクトリにデータファイルあるいはパラメータファイルを転送するという簡単な操作によって、サーバ１１０に対して処理サービスの依頼を行うことができる。

3．変形例
本発明は上述した実施例に限定されるものではなく、例えば以下のように種々の変形が可能である。
(1)上記各実施例は複数のコンピュータ上で動作するソフトウエアによって本発明を実施した例を示したが、上記実施例に用いられるソフトウエアのみをＣＤ−ＲＯＭ、フレキシブルディスク等の記録媒体に格納して頒布し、あるいは伝送路を通じて頒布することもできる。

(2)上記実施例においては、ユーザがステップＳＰ１４を実行することによってユーザディレクトリのウィンドウ３１０をオープンさせたが、ログイン操作（図３(a)）が終了した時に自動的に該ウィンドウ３１０をオープンさせるようにしてもよい。

(3)上記実施例においては、ユーザがログファイルを参照することによって処理サービスの進捗状況を確認したが、例えば各ユーザに対するアンロック処理が行われた時（ステップＳＰ４８）に、ユーザに対して処理サービスの完了を報告するメールを送信するようにしてもよい。さらに、処理サービスの進捗状況を所定のＷＷＷ（World Wide Web）ページに掲載することにより、他のユーザの処理状況も含めて確認できるようにしてもよい。

(4)上記実施例において、処理サービスの提供に要したサーバ１１０の処理量に応じて、該処理サービスを要求したユーザに対して課金処理を行なってもよい。

(5)上記実施例においては、各ユーザディレクトリ内に共通の処理ディレクトリを設けたが、処理ディレクトリは各ユーザ毎に異なってもよい。すなわち、各ユーザに対して提供する処理サービスを異ならせる場合、システム管理者は、各提供しようとする処理サービスに対応した処理ディレクトリのみを、各ユーザディレクトリに作成するとよい。

(6)上記実施例においては、サーバ１１０全体でユーザディレクトリ確認処理のプロセス数が最大「３」までに制限されていたが、この数は「３」に限られるものではなく、システム管理者が任意に設定できるようにしてもよい。

(7)上記実施例においては、何れかのユーザディレクトリに対して何らかの処理サービスが実行されている際、該ユーザディレクトリはロックされたから、一つのユーザディレクトリの処理に供される処理サービスのプロセス数は「１」に限定されていた。従って、一つの処理ディレクトリの処理に供されるプロセス数も当然「１」に限定されていた。しかし、一つのユーザディレクトリまたは一つの処理ディレクトリの処理に対して、所定の最大値ｍ個（例えばｍ＝２）までのプロセスを同時に実行可能にしてもよい。その場合、各ユーザの各処理ディレクトリ毎にロックをかけるようにすることが考えられる。

(8)上記実施例において、サーバ１１０をマルチプロセッサ構成のコンピュータによって構成してもよい。あるいは、サーバ１１０の機能を、ネットワークを介して接続された複数のコンピュータによる分散処理によって実現してもよい。

(9)上記実施例において「メロディ分析」および「メロディ生成」処理は、何れも共通の処理ディレクトリ（メロディ分析）中になんらかのファイルが存在する際に実行される点で共通するが、ファイルの種類（第１／第２形式）に応じて何れの処理が実行されるかが決定されていた。
これと同様に、ある処理ディレクトリ内のファイルに対する処理サービスを、当該ファイルの種類に応じて設定してもよい。同様に、処理ディレクトリ内に所定のパラメータファイルが存在するか否か、あるいは、パラメータファイルの種類に応じて処理サービスの内容を設定してもよい。

本発明の一実施例のネットワークシステムのブロック図である。 サーバ１１０のディレクトリ構造を示す図である。 クライアント機１２０において実行される処理のフローチャートである。 クライアント機１２０の表示器３６の表示例を示す図である。 サーバ１１０におけるユーザディレクトリ確認処理ルーチンのフローチャートである。 サーバ１１０におけるＤｉ確認処理ルーチンのフローチャートである。

符号の説明

２……ハードディスク、４……リムーバルディスク、６……表示器、８……入力装置、１４……バス、１８……ネットワークインターフェース、２０……ＣＰＵ、２２……ＲＯＭ、２４……ＲＡＭ、３２……ハードディスク、３４……リムーバルディスク、３６……表示器、３８……入力装置、４０……サウンドボード、４２……サウンドシステム、４６……ＭＩＤＩインタフェース、４８……ネットワークインターフェース、５０……ＣＰＵ、５２……ＲＯＭ、５４……ＲＡＭ、１００……ネットワーク、１１０……サーバ、１２０，１３０，……，１９０……クライアント機、２００……ルートディレクトリ、２１０……システムディレクトリ、２２０……ホームディレクトリ、２２１，２２２，……，２２ｎ……ユーザディレクトリ、２３０……その他のディレクトリ、３００……デスクトップウィンドウ、３０１，３０２，３１１〜３１８……アイコン、３１０……ウィンドウ。

Claims (5)

1. ネットワークに接続されたサーバを構成するデータ処理装置で実行されるデータ処理方法であって、前記データ処理装置は、該ネットワークに接続されたクライアントから処理対象ファイルまたはパラメータファイルを読み書き可能な複数の処理ディレクトリを備えているとともに、所定時間毎に、該複数の処理ディレクトリを順次確認する処理ディレクトリ確認プロセスを起動し、該プロセスは、
   確認対象の処理ディレクトリ内に処理対象ファイルが存在するか否かを判定する第１判定過程と、
   該処理ディレクトリ内に所定のパラメータをテキストで記述したテキストファイルである前記パラメータファイルが存在するか否かを判定する第２判定過程と、
   前記処理対象ファイルが存在しかつ前記パラメータファイルが存在しない旨が判定されると、該処理対象ファイルに対して当該処理ディレクトリに対応する第１処理を施す一方、前記処理対象ファイルが存在しかつ前記パラメータファイルが存在する旨が判定されると、該処理対象ファイルに対して、該パラメータファイルにテキストで記述されたパラメータを用いて当該処理ディレクトリに対応する第２処理を施す処理過程と
   を含むことを特徴とするデータ処理方法。
2. 前記処理過程において前記処理対象ファイルに対して前記第２処理を行う場合、その処理結果として複数の処理結果ファイルが出力され、前記パラメータファイルには、これら出力される複数の処理結果ファイルに各々対応する複数のパラメータが記憶されていることを特徴とする請求項１記載のデータ処理方法。
3. さらに、前記パラメータファイルではモード指定を行うことが可能であり、前記処理過程において前記処理対象ファイルに対して前記第２処理を行うとき、該パラメータファイルで前記モード指定が行われているか否かに応じて異なる処理を施すことを特徴とする請求項１記載のデータ処理方法。
4. 前記処理過程における前記第２処理において、前記パラメータファイルに記述されたテキスト中に前記モードを指定する特定の文字列を検出した場合は、第１の態様にて前記第２処理を施し、他の場合には第２の態様にて前記第２処理を施すことを特徴とする請求項３記載のデータ処理方法。
5. 前記パラメータファイルには、前記処理過程にて一の処理対象ファイルに対して前記第２処理を施すための複数のパラメータがテキストで記述されていることを特徴とする請求項１ないし４の何れかに記載のデータ処理方法。

Images