JP2010521021A - 楽曲ベースの検索エンジン - Google Patents

Abstract

楽曲ベースの検索の方法、システムおよびデバイスについて記載する。本発明の実施形態は、楽曲構成要素を指定する楽曲クエリを受信する。このクエリは、文字、オーディオおよび／または楽譜データを使用する。楽曲クエリは、指定された楽曲構成要素に基づいて検索パラメータを生成するために使用されるとよく、これは、場合によっては重み付けされてもよい。次に、検索パラメータは、データ記録を含むデータベースに対して送るとよく、各データ記録は、楽曲作品と、この楽曲作品に関する楽曲構成要素の組とに関連する。続いて、検索パラメータと、関連の楽曲作品との間の共通の楽曲構成要素に基づいて、データベース内の一致するデータ記録が同定されてもよい。次に、検索出力が様々な方法で順位付け、表示、および出力されてもよい。

Description

（相互参照）
本願は、同時係属中の米国仮特許出願第６０／８８９，８１６号（名称「ＣＯＬＬＡＢＯＲＡＴＩＶＥ ＭＵＳＩＣ ＳＨＡＲＩＮＧ」、２００７年２月１４日出願、代理人整理番号０２６２８７−０００３００ＵＳ）および同時係属中の米国仮特許出願第６０／８８９，８２１号（名称「ＭＵＳＩＣ−ＢＡＳＥＤ ＳＥＡＲＣＨ ＥＮＧＩＮＥ」、２００７年２月１４日出願、代理人整理番号０２６２８７−０００４００ＵＳ）の優先権の利益を主張し、これらの出願は、全ての目的のために、その全体が本明細書に記載されているように参考として援用される。本願は、Ｒｏｂｅｒｔ Ｄ．Ｔａｕｂらに対する米国仮特許出願第６１／０２８，４９０号（名称「ＭＵＳＩＣ ＳＣＯＲＥ ＤＥＣＯＮＳＴＲＵＣＴＩＯＮ」、２００８年２月１３日出願、代理人整理番号０２６２８７−０００５００ＵＳ）の優先権の利益を主張する。仮出願日の優先権が主張され、仮出願の開示は、全ての目的のために本明細書に参考として援用される。

本願は、さらに同時係属中の米国特許出願第＿＿＿＿＿＿＿号（名称「ＣＯＬＬＡＢＯＲＡＴＩＶＥ ＭＵＳＩＣ ＣＲＥＡＴＩＯＮ」、２００８年２月１４日出願、代理人整理番号０２６２８７−０００３１０ＵＳ）と関連し、この出願は本願とともに出願され、全ての目的のために、その全体が、本明細書に記載されているように参考として援用される。

本発明は、全般的にオーディオアプリケーションに関し、特に楽曲ベースの検索に関する。

オーディオについての文字情報（例えばアーティスト、タイトルなど）が不明のときに、オーディオサンプル、アルバムトラック、またはその他のオーディオ情報を見つけることが望まれることがしばしばある。例えば、ある人が、ラジオで曲を聴いた後、その曲をインターネットで見つけたいこともある。その人が、メロディは思いだすものの、曲の名前、曲の歌詞、またはアーティストさえも分からなければ、従来の（例えばテキストベースの）検索エンジンを使用してその曲を見つけるのは非常に困難であると考えられる。

既存のいくつかの検索エンジンは、オーディオ作品を、そのオーディオ作品についてデータベースに手動で供給されたメタデータに基づき整理する能力を提供することができる。例えば、データベースに、曲のジャンル、テンポ、ピッチの並び、ピッチ間隔の並び、発売日、アーティストなどに関する情報を提供することが可能なこともある。その場合、この情報は、従来の検索エンジンによって、特定の曲を探し出す助けとなるよう使用されてもよい。しかし、この能力を提供するには、オーディオ作品についての情報を手動で（さらに多くの場合主観的に）決定して、その情報をデータベースに格納する必要がある。これは、効率の悪さ、誤り、および利用可能な情報の種類に関する制限をもたらす傾向にあると考えられる。

既存のいくつかの検索エンジンはさらに、特定の種類のオーディオファイルからメタデータを抽出する能力を提供することもある。例えば、ＭＰＥＧ−７ファイル形式および他のファイル形式は、オーディオコンテンツについて特定の種類の情報を格納するよう構成されていることもある。その結果、検索エンジンは、例えばファイルのヘッダ情報から、その情報を抽出することができると考えられる。

さらに他の既存の検索エンジンは、１つの特定の上位パターンによって曲をグループ化する能力を提供することもある。例えば、上位のリズム記号が、オーディオ信号の包絡線から抽出されるとよく、その上位記号が曲のグループ化に使用されてもよい。これは、特定の種類の情報を手動で入力する必要をなくすが、依然として検索には制限があると考えられる。１つの制限は、検索が、文字でない単一の次元に制限される可能性があるということである。例えば、ユーザは、リズム記号についてのみ検索することができると考えられるが、無数の曲が同じようなリズム記号を共有している可能性がある。もう１つの制限は、その単一の次元が、有用な結果を提供するのに十分に基本的なものでない可能性もあるということである。例えば、ユーザは、コーラスのメロディをハミングしたいことも、またはリズムの一部をドラムで演奏したいこともあるが、これらはどちらも、上位パターンに対して検索可能ではない。

少なくともこのような理由から、改善された機能を楽曲検索に提供することが望ましいと考えられる。

特に、楽曲ベースの検索の方法、システムおよびデバイスについて記載する。

本発明の実施形態は、様々な特徴および機能を提供する。いくつかの実施形態は、様々な種類の検索入力（例えば、テキスト、オーディオ、楽譜画像など）を受け取り、様々な種類の検索出力（例えば、文字のリスト、オーディオ出力、楽譜出力など）を生成する。本発明の他の実施形態は、文字情報のインテリジェント構文解析、楽曲構成要素を生成するためのオーディオおよび楽譜画像データの分解、直交および重み付き検索能力、ならびにその他多数の機能をサポートする。他の実施形態は、ローカルで（例えば、パーソナルコンピュータまたはローカルエリアネットワーク）動作するよう構成され、その他の実施形態では、本発明はリモートで（例えば、インターネット経由で、またはリモートサーバを使用して）動作するよう構成される。他の実施形態は、検索結果のテキスト、楽譜、オーディオ出力の生成を含む出力機能をサポートする。

一実施形態では、楽曲検索を実行するコンピュータ方法が提供される。本方法は、楽曲構成要素を指定する楽曲クエリを受信することと、受信された楽曲クエリによって指定された楽曲構成要素に基づいて検索パラメータの組を生成することと、いくつかのデータ記録を含むデータベースに対して検索パラメータの組を送る（ｄｉｒｅｃｔ）ことであって、各データ記録は、楽曲作品と、この楽曲作品に関係する楽曲構成要素の組とにそれぞれ関連しており、少なくとも１つのデータ記録と関連する楽曲構成要素のこの組は、少なくとも１つの楽曲作品から分解されたデータを含む、送ることと、検索パラメータの組に一致するデータ記録を含む、一致するデータ記録の組をデータベースにおいて同定することと、一致するデータ記録の組に関連する楽曲作品を含む、一致した楽曲作品の組をデータベース内で同定することと、順位付けリストに並べられている、一致した楽曲作品を含む検索出力を生成することとを含む。

本発明のその他の特徴および利点が、以下の、本発明の原理を一例として示す好適な実施形態の説明から明らかとなるはずである。

以下の図面を参照することによって、本発明の性質および利点のさらなる理解が実現されると考えられる。添付の図面では、同様のコンポーネントまたは特徴が、同じ参照ラベルを有することもある。さらに、類似したコンポーネント間を区別するダッシュと第２のラベルとが参照ラベルに続くことによって、同じ種類の様々なコンポーネントが区別されることもある。本明細書内で、第１の参照ラベルのみが使用されていれば、その説明は、第２の参照ラベルに関係なく、同じ第１参照ラベルを有する類似コンポーネントのうち任意のものに適用できる。

図１は、本発明に従い構成された、楽曲ベースの検索用のシステムの簡略化した上位ブロック図である。 図２は、本発明による楽曲ベースの検索の例示的方法のフロー図である。 図３は、本発明による、オーディオ検索文字列を生成する、実例となる様々な種類の楽曲入力である。 図４Ａは、本発明による、楽曲入力データを分解する方法のフロー図である。 図４Ｂは、本発明による、楽曲の小さな構成要素を分解する方法の実施形態である。 図４Ｃは、本発明による、楽曲の大きな構成要素を分解する方法の実施形態である。 図５Ａは、本発明による、楽曲構成要素の生成のためにオーディオ信号入力を分解する例示的システムの簡略化したブロック図である。 図５Ｂは、本発明によるオーディオ分解ユニットの一実施形態の下位ブロック図である。 図６Ａは、光学式文字認識（ＯＣＲ）機能を提供するために、本発明に従って楽曲画像データを処理する例示的システムである。 図６Ｂは、ＯＣＲプロセッサへの入力として提供される、図６Ａに示されているキャプチャデバイスからつくり出された例示的画像データである。 図７は、本発明による楽曲ベースの検索エンジンのＧＵＩの実施形態である。 図８は、本発明の特定の実施形態を実装する計算システムのブロック図である。 図９は、本発明による製品の実例となる実施形態を、ハンドヘルドコンシューマ電子デバイスとして示す。 図１０は、図９に示されているものに類似したデバイスの実施形態の動作を示す簡略化したプロセスフロー図である。

この説明は、実施例としての実施形態のみを提供するものであり、本発明の範囲、適用性、または構成を限定しようとするものではない。それどころか、続く実施形態の説明は、本発明の実施形態を実装できるようにする説明を当業者に提供する。本発明の意図および範囲から逸脱することなく、構成要素の機能および配置に様々な変更が加えられてよい。

したがって、様々な実施形態が、必要に応じて、様々な手順またはコンポーネントを省略、置換、または追加してもよい。例えば、当然のことながら、代替の実施形態では、記載されたものとは異なる順序で方法が実行されてもよく、様々なステップが追加、省略されても、または組み合わされてもよい。さらに、特定の実施形態に関して記載される特徴が、他の様々な実施形態に組み合わされてもよい。実施形態の種々の側面および構成要素が、同様の形で組み合わされてもよい。

さらに、当然のことながら、以下のシステム、方法およびソフトウェアは、個別に、または集合的に、より大きなシステムのコンポーネントであってもよく、その利用により他の手順が優先しても、またはそうでなければ他の手順がその利用に変更を加えてもよい。さらに、いくつかのステップが、以下の実施形態の前、後、またはそれと同時に必要な場合もある。

（概説）
本発明の実施形態は、楽曲ベースの検索に関する新規な機能を提供する。一側面において、本発明の技術は、ウェブポータルまたはイントラネット（ＬＡＮ）サイトなどのネットワークサイトとして実装可能である。他の側面では、本発明は、クライアント側のソフトウェアとして、既存の検索環境に対するアドオン機能として、または専用デバイスおよびシステムとして提供されてもよい。

本発明の実施形態は、様々な特徴および機能を提供する。いくつかの実施形態は、様々な種類の検索入力（例えば、テキスト、オーディオ、楽譜画像など）を受け取り、様々な種類の検索出力（例えば、文字のリスト、オーディオ出力、楽譜出力など）を生成する。特定の実施形態では、本発明は、文字情報のインテリジェント構文解析、楽曲構成要素を生成するためのオーディオおよび楽譜画像データの分解、直交および重み付き検索能力、ならびにその他多数の機能をサポートする。本発明のいくつかの実施形態は、ローカルで（例えば、パーソナルコンピュータまたはローカルエリアネットワーク）動作するよう構成され、他の実施形態は、リモートで（例えば、インターネット経由で、またはリモートサーバを使用して）動作するよう構成される。さらに他の実施形態は、検索結果のテキスト、楽譜、オーディオ出力の生成を含む出力機能をサポートする。

図１は、本発明に従い構成された、楽曲ベースの検索用のシステム１００の簡略化した上位ブロック図を示す。システム１００は、ネットワーク１１０を介していくつかのワークステーション１０４に接続された検索エンジン１６０を含む。ワークステーション１０４は、ユーザインターフェースを介して検索エンジンにアクセスしてもよい。ネットワーク１１０は、このいくつかのワークステーション１０４間の通信を促す任意のものであってもよい。例えば、ネットワーク１１０は、インターネットまたはローカルエリアネットワーク（ＬＡＮ）としてもよい。特定の実施形態では、検索エンジン１６０は、ワークステーション１０４上にあってもよく［（図示せず）］、ワークステーション１０４にあるかまたはワークステーション１０４に対してリモートのデータを検索するよう構成されていてもよい。

ワークステーション１０４は、ネットワーク１１０との通信と、検索入力１０２の受信とを行うよう構成されている任意のデバイスまたはシステムであってもよい。いくつかの実施形態では、ワークステーション１０４は多目的デバイスである。例えば、ワークステーション１０４は、コンピュータ（例えばラップトップ、デスクトップなど）またはハンドヘルドデバイス（例えば携帯情報端末、セルラー電話など）であってもよい。他の実施形態では、ワークステーション１０４は専用デバイスである。例えば、ワークステーション１０４は、検索入力１０２の受信、ネットワーク１１０との通信、および検索出力１０６の生成を含む、楽曲ベースの検索エンジンの提供専用に開発された専用の携帯用デバイスであってもよい。特定の実施形態では、ワークステーション１０４は、オーディオ、楽譜情報、テキスト、またはその他の情報を検索入力として入力するためのインターフェースであるか、またはそれを提供する。例えば、ワークステーション１０４は、エレキギター、デジタルオーディオコンポーネント、または楽曲楽譜の画像を記録するためのウェブカメラの直接ネットワークインターフェースであってもよい。

当然のことながら、本発明によれば、ワークステーション１０４が検索入力１０２を受信する方法は数多くある。例えば、検索入力１０２は、内蔵マイクロホンまたは外付けマイクロホン、ラインレベルオーディオポート、ファイル転送（例えば固定または取り外し可能データストアから、またはネットワーク経由で）、楽譜画像キャプチャデバイス、テキストフィールドなどによって受信されてもよい。楽曲入力の実施形態については、下記により詳しく記載する。検索入力は、検索エンジン出力を含む一致を探し出すために、データベースに対して送られるクエリを含んでもよい。

いくつかの実施形態では、ワークステーション１０４は、検索出力１０６を生成するよう構成されている。一実施形態では、検索出力１０６は、スピーカを通じてプレイされるよう構成されたオーディオ出力を含む。別の実施形態では、検索出力１０６は、ネットワーク経由で格納、プレイおよび／または共有されるよう構成されたオーディオファイルを含む。さらに別の実施形態では、検索出力１０６は、互換性のある他のシステムが使用するための楽曲構成要素データ（例えばピッチ、音程、テンポ、調、振幅など）を含む。さらに別の実施形態では、検索出力１０６は、楽譜表現データを含み、これは、楽譜編集ソフトウェアにより使用されるよう、文書編集もしくは公開システムに送信されるよう、または印刷されるよう構成されている。さらに別の実施形態では、検索出力１０６は、検索結果の一次元または多次元のリストを含む。

検索入力１０２の種類によっては、検索入力１０２から楽曲構成要素を分解することが望ましいこともある。一例では、検索入力１０２はオーディオ信号として受信される（例えば、検索者がギターを使用してマイクロホンに向けてメロディラインをプレイする）。別の例では、検索入力１０２は、楽曲楽譜の走査画像として受信される。どちらの例でも、検索入力１０２から楽曲構成要素を分解して、検索パラメータの生成に使用することが望ましいと考えられる。楽曲（例えば、オーディオおよび楽譜）分解については、下記により詳しく記載する。

いくつかの実施形態では、システム１００は、楽曲分解機能を提供する１つ以上の楽曲分解ユニット１２０を含む。特定の実施形態では、楽曲分解ユニット１２０はワークステーション１０４上にある。例えば、楽曲分解ユニット１２０は、クライアントレベルのソフトウェアとして実装されてもよい。こうした実施形態では、検索入力１０２は、ネットワーク１１０経由で検索エンジン１６０へ送信される前に楽曲構成要素に分解されてもよい。他の実施形態では、楽曲分解ユニット１２０は、検索エンジン１６０の一部として提供されてもよい（例えば構成要素１２０−２）。検索入力１０２が、ワークステーション１０４にて受信され、ネットワーク１１０経由で検索エンジン１６０へ送信され、次に検索エンジン１６０にて楽曲構成要素へ分解されてもよい。

特定の実施形態では、検索エンジン１６０は、１つ以上のデータストア１１５と動作的に通信（ｏｐｅｒａｔｉｖｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ）していてもよい。いくつかの実施形態では、検索エンジン１６０は、データストア１１５とネットワーク１１０経由で通信する。他の実施形態では、検索エンジン１６０はデータストア１１５と直接通信する。データストア１１５は、検索入力１０２または検索出力１０６に関する１種類以上の情報を格納するよう構成されてもよい。例えば、データストア１１５は、生のオーディオファイル（例えば、デジタル化オーディオ信号データを含んだファイル）、符号化オーディオファイル（例えば、ファイルコンテンツデータまたはオーディオ信号データに関するメタデータを含んだファイル）、楽曲構成要素情報（例えば、楽曲構成要素の各楽曲投稿に関連付けされて、多次元リレーショナルデータベースに格納される、分解済みの楽曲構成要素）などを格納するよう構成されてもよい。

当然のことながら、特定の種類のデータ保護が、本発明の実施形態において望まれる場合もある。いくつかの実施形態では、データストア１１５は、特定の種類のデータ保護（例えば、暗号化、パスワード保護など）を使用してデータを格納するよう構成されている。他の実施形態では、システム１００の様々なコンポーネント間の物理および仮想通信リンクが安全である（例えば、セキュアソケットレイヤ暗号化による）。例えば、検索エンジン１６０とワークステーション１０４との間、または検索エンジン１６０とデータストア１１５との間のネットワーク通信が安全であってもよい。さらに他の実施形態では、検索出力１０６が保護され、コピー、削除などが防止されてもよい。例えば、特定のデジタル著作権管理（ＤＲＭ：ｄｉｇｉｔａｌ ｒｉｇｈｔｓ ｍａｎａｇｅｍｅｎｔ）技術が用いられて、検索出力１０６ファイルの不正コピーまたは共有が制限されてもよい。

いくつかの実施形態では、検索エンジン１６０は、ネットワークインターフェースユニット１５０を通じてネットワーク１１０と通信する。ネットワークインターフェースユニット１５０の特定の実施形態は、特定の種類のネットワーク機能を提供することによって、検索エンジン１６０とネットワーク１１０との間の通信を促す。例えば、ネットワークインターフェースユニット１５０は、効果的な共同制作、ファイル転送および検索エンジン１６０のその他の能力を可能にするために、ネットワークトラフィックのルーティングおよび／または解釈を行う。

ネットワークインターフェースユニット１５０の様々な実施形態が、強化された能力を提供する。いくつかの実施形態では、ネットワークインターフェースユニット１５０は、ネットワーク１１０を介してワークステーション１０４からログイン情報を受信して処理するよう構成されている。一実施形態では、ログイン情報は、ワークステーション１０４のユーザを検証して、検索エンジン１６０に対するユーザのアクセス権を判断するために使用される。アクセス権は、例えば、そのユーザが検索エンジン１６０に入ることができるかどうか、どのファイルにそのユーザがアクセスしてよいか、検索エンジン１６０のどの機能をユーザが使用してよいかなどを決定してもよい。

当然のことながら、本発明によれば、検索エンジン１６０の多数の実施形態が可能である。いくつかの実施形態では、検索エンジン１６０は、ウェブブラウザを通じて使用されるよう構成されており、ネットワークアドレスに配置可能である。こうした実施形態のうちのいくつかでは、検索エンジン１６０は、異なる多数のブラウジング環境に拡張できるよう構成されている（例えば、ＸＭＬ、ＨＴＭＬ、または別の拡張可能マークアップ言語で書かれることによる）。他の実施形態では、検索エンジン１６０は、ワークステーション１０４上にあるクライアント側アプリケーションとして実装される。こうした実施形態では、特定の機能がサーバ上に実装され（例えばファイル管理）、その一方で、検索処理の大部分がクライアントワークステーション１０４上で行われてもよい。さらに他の実施形態では、検索エンジン１６０は、ローカルエリアネットワーク用の別個のネットワークサーバ上にあってもよく、または、ワークステーション１０４が、ネットワークにアプリケーションを供給するために使用されてもよい。

検索エンジン１６０の実施形態は、検索インターフェースユニット１３０を含む。様々な実施形態において、検索インターフェースユニット１３０は、入力およびクエリの操作、検索のパラメータ化、結果の読み出しおよび順位付け、結果の表示などを含む、検索エンジン１６０の中心的機能を実行するよう構成されている。検索インターフェースユニット１３０の実施形態および機能については、下記により詳しく記載する。

検索エンジン１６０の実施形態は、出力生成ユニット１４０をさらに含む。いくつかの実施形態では、出力生成ユニット１４０は、検索インターフェースユニット１３０から出力を受信して出力データを生成するよう構成されてもよい。出力生成ユニット１４０によって生成されたデータは、データストア１１５（例えば、直接もしくはネットワーク１１０経由で）、またはワークステーション１０４に伝達されてもよい。いくつかの実施形態では、出力生成ユニット１４０によって生成される出力データは、検索出力１０６であってもよい。他の実施形態では、出力生成ユニット１４０によって生成される出力データは、検索出力１０６を生成するためにワークステーション１０４によって使用可能であってもよい。

図２は、本発明による、楽曲ベースの検索の例示的方法２００のフロー図を示す。方法２００のいくつかの実施形態は、図１に示されているシステム１００のようなシステムを使用して実行されてもよい。方法２００は、ブロック２０２で楽曲クエリ入力を受信することによって開始する。様々な実施形態において、ブロック２０２にて受信される楽曲クエリ入力は、テキスト入力１０２−１、オーディオ入力１０２−２（例えば、オ−ディオ信号またはオーディオファイル）および／または楽譜入力１０２−１（例えば、楽曲構成要素データの楽譜画像または楽譜エントリ）を含んでもよい。

ブロック２０４で、方法２００は、クエリ入力を処理し、楽曲ベースの検索用のデータを生成する。いくつかの実施形態では、同定可能な楽曲構成要素の組を生成するために、オーディオ入力１０２−２または楽譜入力１０２−３が分解される。他の実施形態では、クエリを同定可能な楽曲構成要素に変換するために、テキスト入力１０２−１が構文解析され、さらに別の方法で処理されてもよい。その他多数の種類の処理が、ブロック２０４において可能である。それには、例えば、オーディオ信号の正規化または雑音除去を行って分解を助けること、提供された情報に、他の提供情報と矛盾したものまたは一貫性がないものがないかを評価することなどが含まれる。

いくつかの実施形態では、方法２００はさらに、ブロック２０６で、クエリプリファレンスの組を受信する。特定の実施形態では、クエリプリファレンスは、様々な検索構成要素の重み付けのプリファレンスの組を含む。例えば、検索者は、約１００ビート毎分（ｂｐｍ：ｂｅａｔｓ ｐｅｒ ｍｉｎｕｔｅ）のテンポであって好適にはトランペットラインを備えた、ジャズソングすべてを要求してもよい。この検索者は、そうした構成要素すべてを検索し、ただしトランペット構成要素にはより低い重み付けを与えてもよい。よって、テンポが好ましい範囲の外にあるジャズトランペットパフォーマンスは、トランペットラインのない１００ｂｐｍのジャズパフォーマンスよりも低く順位付けされてもよい。

当然のことながら、本発明によれば、多数の種類の重み付けおよびプリファレンスが可能である。例えば、検索者は、パフォーマンスの最初の１分間のうちに生じる情報を検索してもよい。別の例として、検索者は、オーディオ入力およびテキスト入力の両方を提供して（例えば、検索者が、キーボードを使用して検索エンジンへメロディラインをプレイし、テキストエントリフィールドを使用してクラシック楽曲のみを探すよう検索エンジンに命じる）、テキスト入力をオーディオ入力よりも大きく重み付けしてもよい。

ブロック２０８において、方法２００は、ブロック２０２で受信された入力と、ブロック２０６で受信されたプリファレンスとを使用して、検索パラメータの組を生成してもよい。いくつかの実施形態では、ブロック２０８での検索パラメータの生成は、単にブロック２０２および２０６から受信されたデータを変換することを含む。例えば、分解された楽曲構成要素、構文解析されたテキストデータ、およびその他の情報が、データベースに対して実行されるクエリ言語に変換されてもよい。他の実施形態では、ブロック２０８での検索パラメータの生成は、ブロック２０２および２０６から受信されたデータを解釈することを含む。例えば、検索者が検索エンジンへメロディを笛で吹くと、検索エンジンは、検索者がメロディを伝えようとしたのか、テンポもしくはリズムを伝えようとしたのか、その曲が笛を吹いて演奏されたことを伝えようとしたのか、またはその他何らかの情報もしくは情報の組み合わせを伝えようとしたのかを判断してもよい。さらに他の実施形態では、ブロック２０８での検索パラメータの生成は、例えば、ブール演算を評価すること、通常語（ｐｌａｉｎ ｌａｎｇｕａｇｅ）入力をクエリに対応した入力に変換することなどを含んでもよい。

ブロック２０８において検索パラメータが生成されると、方法２００は、ブロック２１０において検索を実行して、検索結果を読み出す。ブロック２１０の実施形態は、検索を、１つ以上の所定のデータベースに対して実行しても、データ（例えば、インターネットを介してアクセス可能なデータ）のネットワークに対して実行しても、ローカルのデータストアに対して実行しても、またはその他任意の、検索可能な楽曲データ用のコンピュータアクセス可能な場所に対して実行してもよい。特定の実施形態は、実際のオーディオファイルを返すことによって結果を返し、他の実施形態は、オーディオファイルへのポインタ、オーディオファイルに関する文字もしくは楽譜表現情報、またはその他任意の有用な情報を返す。

ブロック２１２において、方法２００は、結果を順位付けして表示する。当然のことながら、本発明によれば、結果の順位付けは、いくつかの方法で実行されてもよい。例えば、結果の順位付けは、楽曲構成要素（例えば格納データまたは検索入力データ内の）の判断における信頼値、一致したパラメータの数および一致した程度、ユーザによって供給されたかまたは検索エンジンによって推測された重み付けおよび他のプリファレンスなどに関係してもよい。

場合によっては、ブロック２１２は、検索者にとって望ましくない、または必要条件の何らかの組に適合しない結果リストを生成することもある。例えば、ユーザの観点から、リストが興味をそそらない、数が多すぎる、短すぎる、不適切な順序であるなどの可能性がある。よって、ブロック２１４において、方法２００は、検索を修正するかどうかを決定する。いくつかの実施形態では、検索者は、検索の修正（例えば、追加すること、または既存の検索パラメータを変更することによる）を決定し、他の実施形態では、検索エンジンが結果パラメータに基づいて自動的に検索を修正する。例えば、検索者が検索エンジンに、ギターでプレイされた特定の種類の曲に関してクエリを行うが、検索結果が返されないと仮定する。検索エンジンは、バンジョー、ベースまたはシタールなどの他の楽器でプレイされた曲を含めるよう自動的に検索を修正してもよい。修正後の検索で結果を見つけた後、検索エンジンは、「「ギター」の検索で０件の結果が返りました。「バンジョー」を含めるよう検索を広げると、１２件の結果が生じました。「バンジョー」の結果を表示するには［ここ］をクリックしてください。」というようなことを示す通知を検索者に返してもよい。他の自動検索修正が、検索エンジンによってもたらされてもよい。

方法２００が、ブロック２１４において、検索の修正が必要であると判断すると、新たな入力または変更された入力がブロック２１６で受信されてもよい。こうした新たな入力または変更された入力は、ブロック２０８から２１２まで、新たな結果を伴う修正された検索を生成するために使用されてもよい。したがって、ユーザは、新たな入力または変更された入力を含む追加のクエリを出すことを求めてもよい。その結果、検索が反復する形で実施されてもよい。

方法２００が、ブロック２１４にて、検索が修正されるべきではないと判断すると（例えば、検索者が受信された結果で次に進む、または結果が結果パラメータを満たす）、ブロック２１８にて、検索結果が出力または分解されてもよい。いくつかの実施形態では、受信される結果は、オーディオファイル、楽譜画像、またはその他の情報を含む。こうした実施形態のいつくかでは、結果を分解して、特定の出力（例えば、特定の楽曲構成要素に関する文字出力１０６−１、特定のパラメータを備えたオーディオ出力１０６−２、楽譜表現出力１０６−３など）を生成することが望ましい場合もある。

当然のことながら、図１および２に関して記載された実施形態は、本発明の例示的構造および例示的機能の概要を提供することを目的としている。よって、上記で与えられた説明は、本発明の範囲を制限するものと解釈されるべきではない。さらに明瞭にするために、特定の機能のさらなる説明が、以下でさらに論じられる。

（検索入力）
楽曲寄与を生成するために、多数の異なる種類の検索入力が考えられる。図３は、本発明による、検索寄与を生成するための、実例となる様々な種類の検索入力を示す。当然のことながら、図３に示されている検索入力装置は、考えられる多数の検索入力装置のうちのいくつかのみを提供するものであり、本発明の可能性を制限するものと解釈されるべきではない。

検索入力の一実施形態には、生のオーディオファイル３０２が含まれる。生のオーディオファイル３０２は、デジタル信号表現へとデジタル化されたオーディオ信号データを含んでもよい。例えば、デジタル信号情報は、タイムスタンプおよび電圧レベルをそれぞれ有する複数のサンプルを含んでもよく、このサンプルは、オーディオ信号のアナログバージョンを表すものである。他の例では、デジタル信号情報が、オーディオ信号を計算手順で表すために符号化されてもよい（例えば、誤り訂正情報、コーデック情報などを含む）。

検索入力の別の実施形態には、強化されたオーディオファイル３０４が含まれる。強化されたオーディオファイル３０４は、生のオーディオファイル３０２に存在するデータを補完する、またはそれに取って代わる情報を含んでもよい。特定の実施形態では、強化されたオーディオファイル３０４は、ファイルのコンテンツについてのメタデータ、その形式、またはその他有用な情報を含んでもよい。例えば、メタデータは、トラック名、アルバム名、アーティスト名、ジャンルなどを含めて、オーディオファイルについて手動で入力された情報を含んでもよい。別の例では、メタデータは、他のシステムに対応してもよい（例えば、曲のアルバム製造番号およびトラック番号がメタデータ内に提供され、特定のデータベース検索が、曲のタイトルのような、その曲についての他の情報を返せるようにしてもよい）。

強化されたオーディオファイル３０４のいくつかの実施形態は、生のオーディオファイル３０２を、エンコーダ３３０に通すことによってつくられる。例えば、強化されたオーディオファイル３０４は、ＭＰＥＧ−７エンコーダによって生成されてもよい。ＭＰＥＧ−７エンコーダは、メタデータを格納し、メタデータを、強化されたオーディオファイル３０４内の特定のタイムスタンプに結びつけるために、ＸＭＬを使用することができる。他の実施形態では、強化されたオーディオファイル３０４は、生のオーディオファイル３０２を、オーディオ分解器３２０に通すことによって生成されてもよい。オーディオ分解器３２０は、生のオーディオファイル３０２から検索構成要素を分解し（下記により詳しく記載するように）、それを強化されたオーディオファイル３０４に格納してもよい。

検索入力のさらに別の実施形態には、互換性のある楽器３０６からのデジタル化された出力を含む。一実施形態では、楽器デジタル・インターフェース（ＭＩＤＩ：Ｍｕｓｉｃａｌ Ｉｎｓｔｒｕｍｅｎｔａｌ Ｄｉｇｉｔａｌ Ｉｎｔｅｒｆａｃｅ）楽器（例えばキーボード）が、ＭＩＤＩデータ生成に使用される。ＭＩＤＩデータは、楽曲構成要素を含んでもよい。場合によっては、含まれる楽曲構成要素が、他の楽曲構成要素の生成に使用されてもよい。例えば、ＭＩＤＩデータは、音符のピッチを複数含むと考えられ、これを分析して調を判断することができる。他の実施形態では、互換性のある楽器３０６は、使用可能な形式でデータを出力するよう動作可能であってもよい。例えば、キーボードは、デジタル同軸、光学または他の種類の出力を有してもよく、この出力は、他のコンポーネントに対応してもよい。

検索入力のさらに別の実施形態には、センサ３０８からのアナログ出力が含まれる。一実施形態では、１つ以上の楽器により生成される圧力波を検出して、それをアナログオーディオ信号に変換するために、１つ以上のマイクロホンが使用される。別の実施形態では、エレキギターのスチール弦の動きをアナログオーディオ信号に変換するために電磁ピックアップが使用される。

検索入力のさらに別の実施形態には、編集可能楽譜ファイル３１０が含まれる。編集可能楽譜ファイル３１０は、編集可能な楽譜データを含む任意の種類のファイルであってもよい。例えば、編集可能楽譜ファイル３１０は、楽譜編集ソフトウェア３４０を使用して生成されたものでもよい。検索入力のいくつかの実施形態には、楽譜画像３１２が含まれる。楽譜画像３１２の実施形態は、任意の種類の使用可能なデジタル画像を含んでもよい。一実施形態では、楽譜画像３１２は、印刷されている楽譜を画像キャプチャ装置（例えばスキャナ、デジタルスチルまたはビデオカメラなど）によってデジタル画像に変換してつくられる、楽譜の物理的なプリントアウト（例えばシートミュージック）のデジタル化表現である。他の実施形態では、楽譜画像３１２は、楽譜画像３１２を楽譜分解器３５０に通すことによって編集可能楽譜ファイル３１０へと変換される。下記により詳しく記載するように、楽譜分解器３５０は、楽譜画像３１２から楽曲構成要素を分解するよう動作可能であってもよい。

検索入力の他の実施形態は、１つ以上のテキストクエリ３１４を含む。テキストクエリ３１４は、楽曲ベースの検索の検索クエリとして解釈可能な任意の種類のテキストデータを含んでもよい。一実施形態では、テキストクエリ３１４は、検索パラメータへと復号されるよう構成された、クエリ言語に形式を合わせたテキストを含む。別の実施形態では、テキストクエリ３１４は通常語データを含む。さらに別の実施形態では、テキストクエリ３１４は、ブール演算子、フィールド名、特殊文字などの他のパラメータを含む。特定の実施形態では、テキストクエリ３１４は、検索入力を生成するよう、テキストパーサ３６０またはその他のテキスト処理ユニットを通る。

特定の実施形態では、エンコーダ３３０、オーディオ分解器３２０、楽譜分解器３５０、楽譜エディタ３４０、テキストパーサ３６０、またはその他のアプリケーションは、ワークステーション１０４、サーバコンピュータ、またはネットワーク１１０上にあっても良い。他の実施形態では、検索入力１０２は、楽曲ベースの検索用の検索可能な構成要素であってもよく、または、それを生成するために使用されてもよい。特定の実施形態では、検索可能な構成要素は、楽曲ベースの検索のためのデータとして検索データベース１１５内に格納されてもよい。他の実施形態では、検索可能な構成要素は、楽曲ベースの検索用に、ネットワーク１１０に渡されてもよい。

（オーディオ分離）
本発明のいくつかの実施形態では、オーディオ信号データおよび楽譜画像データのような楽曲入力データからの楽曲構成要素の分解を実現することが望ましいと考えられる。当然のことながら、様々な種類の楽曲入力データから楽曲構成要素を分解する方法が多数ある。場合によっては、データが、分解しやすい形でオーディオファイルに格納されることもある。例えば、楽曲構成要素データは、強化されたオーディオファイルにヘッダ情報として格納されることもある。しかし、他の場合には、特定の種類の楽曲構成要素を楽曲入力データから抽出するのが簡単でないこともある。

図４Ａは、本発明による、楽曲入力データを分解する方法４００のフロー図を示す。方法４００は、ブロック４０２において楽曲入力データを受信することによって開始する。いくつかの実施形態では、ブロック４０２において受信された楽曲入力は、
検索入力、検索データベースに格納された楽曲若しくは楽曲構成要素、または楽曲ベースの検索と置換可能な別の楽曲データを含んでもよい。

ブロック４１０において、楽曲の小さな構成要素が楽曲入力から分解される。一例として、楽曲の小さな構成要素は、音符のピッチおよび音価（ｎｏｔｅ ｖａｌｕｅ）、タイムスタンプ、音符の包絡線および音色、調、テンポ、ならびにその他同様の構成要素を含み得る。特定の実施形態では、楽曲の小さな構成要素は、楽曲の他の小さな構成要素のグループを複数含んでもよい（例えば、タイで連結された音符、３連符、トラックまたは楽器によってグループ分けされた音符、小節によってグループ分けされた音符、寄与者によってグループ分けされた音符など）。他の実施形態では、楽曲の小さな構成要素は、楽曲の他の小さな構成要素のコンポーネントを含んでもよい（例えば符幹（ｓｔｅｍ）、符尾（ｆｌａｇ）、付点など）。

ブロック４５０において、楽曲の大きな構成要素が分解される。一例として、楽曲の大きな構成要素は、楽曲の小さな構成要素のグループおよびパターンの分析から生成される情報を含んでもよい。いくつかの実施形態では、楽曲の大きな構成要素は、楽曲の小さな構成要素の複数のグループに関する部分的または全体的なパターン情報を含む（例えば、
リズム記号、反復モチーフ、コード／調の変更、形式（例えばＡ−Ｂ−Ａ、またはコーラス−ヴァース−ヴァース−コーラス）など）。その他の実施形態では、楽曲の大きな構成要素は、楽曲の小さな構成要素の複数組から算出される統計情報を含む（例えば音符またはリズムパータンのヒストグラムなど）。続いて、楽曲の小さな構成要素および大きな構成要素が、ブロック４９０において出力されてもよい。

図４Ｂは、本発明による、楽曲の小さな構成要素を分解する方法４１０の実施形態を示す。方法４１０は、ブロック４０２において楽曲入力信号を受信することによって開始する。いくつかの実施形態では、楽曲入力信号の前処理が行われてもよい。例えば、オーディオ信号のアナログからデジタルへの変換、より低いサンプルレートへのダウンコンバート、特定のエンコーダまたはデコーダとの互換性のためのトランスコード、モノフォニックオーディオトラックへの解析、またはその他任意の有用な前処理が行われてもよい。

いくつかの実施形態では、ブロック４１２においてピッチ情報が抽出され、音符開始（ｎｏｔｅ ｏｎｓｅｔ）イベントがブロック４１４において抽出される。方法４１０のいくつかの実施形態では、ブロック４１２において抽出されたピッチ情報およびブロック４１４において抽出された音符開始イベントが、ブロック４０２において受信されたオーディオ信号から他の情報を抽出して処理するために使用される。

特定の実施形態では、この情報は、ブロック４１６において音符の持続時間を判断するため、ブロック４１８において休符を判断するため、ブロック４２０において複数の時間ウィンドウ（ｔｉｍｅ ｗｉｎｄｏｗ）にわたるテンポを判断するため、ブロック４２４において複数のウィンドウにわたる調を判断するため、さらにブロック４２８において楽器編成を判断するために使用される。他の実施形態では、ブロック４１６において判断された音符の持続時間、ブロック４１８において判断された休符、ブロック４２０において判断されたテンポが、ブロック４２２において、音価を判断するために使用される。ブロック４２４において判断された調は、ブロック４２６において調のピッチ指示（ｐｉｔｃｈ ｄｅｓｉｇｎａｔｉｏｎ）を判断するために使用される。ブロック４２８において判断された楽器編成は、ブロック４３０においてトラックを判断するために使用される。様々な実施形態において、ブロック４１２〜４３０の出力は、ブロック４９０−１において、楽曲の小さな構成要素としての出力を生成するために使用されるよう構成されている。

図４Ｃは、本発明による、楽曲の大きな構成要素を分解する方法４５０の実施形態を示す。方法４５０は、ブロック４５２において楽曲の小さな構成要素を受信することによって開始する（例えば、図４Ｂの方法４１０から）。楽曲の小さな構成要素は、いくつかの種類の、楽曲の大きな構成要素を生成するために使用されてもよい。

いくつかの実施形態では、楽曲の小さな構成要素は、ブロック４５４において曲の形式を判断し（例えば、イントロ−ヴァース−コーラス−ヴァース−ブリッジ−コーラス−コーラス−アウトロ）、ブロック４５６においてジャンルを判断し（例えば、ロック、クラシック、ジャズ、インドの古典楽曲など）、ブロック４５８においてリズム記号を判断し（例えば、第１楽章は４／４拍子で９０ビート毎秒（ｂｐｍ：ｂｅａｔｓ ｐｅｒ ｍｉｎｕｔｅ）のテンポ、第２楽章は３／４拍子で１２０ｂｐｍのテンポ、さらに第３楽章は４／４拍子に戻るが１２０ｂｐｍのテンポのまま）、ブロック４６０において音調曲線を判断し（例えば、曲が比較的低音量かつ速いテンポでドラムおよびベースのみで開始し、１分後、その曲が、中音量かつより遅いテンポでクリーンなギターラインを追加する）、ブロック４６２において、調の変更を判断し（例えば、その曲がハ長調という調で始まり、ヘ長調に転調してすぐにニ短調、ト長調と転調し、ハ長調に戻る）、ブロック４６４においてコード変更を判断するため（例えば、その曲の一部がＡｍ^７からＤｍ^７へ、Ｇｍ^７へ、Ｃ^７へ、Ｆ^６へと変化する、またはその曲がｉｉｉ^７からｖｉ^７へ、ｉｉ^７へ、Ｖ^７へ、Ｉ^６へと変化する）に使用される。様々な実施形態において、ブロック４５４〜４６４の出力は、ブロック４９０−２において、楽曲の大きな構成要素として出力を生成するために使用されるよう構成されている。

当然のことながら、本発明によれば、その他多数の種類の、楽曲の小さな構成要素および楽曲の大きな構成要素が可能である。さらに、検索に必要な楽曲構成要素の種類に応じて、楽曲入力信号は、多数の異なるレベルで分解されてもよい。例えば、仮のドラムトラックが、リズム情報を提供するためだけに使用されてもよい。その場合、ピッチ、音色、調などに関係する楽曲構成要素を分解または保存しても、リソースの無駄であると考えられる。別の例では、ボーカルラインが、曲のセクション全体にわたるピッチ変化の音調曲線の大まかな方向付けを提供するために使用されてもよい。その場合、正確なピッチ、音符の持続時間などを分解することは重要でないと考えられる。むしろ、ピッチ変動の大まかな指示のみを、近似のピッチ値および持続時間を用いて抽出するほうがより効率的であると考えられる。

さらに、当然のことながら、利用可能な楽曲データの種類および様々な用途のニーズに応じて、楽曲入力から楽曲構成要素を分解する多数の方法があると考えられる。図５Ａは、本発明の実施形態による楽曲構成要素を生成するためにオーディオ信号入力を分解する例示的システムの簡略化したブロック図を示す。図のように、入力１０２が、楽曲分解ユニット１２０によって受信され、楽曲分解ユニット１２０は、入力１０２を分解して分解済み出力５７０を生成する。

いくつかの実施形態では、入力１０２は、オーディオ受信器ユニット５０６にある楽曲分解ユニット１２０により受信される。一実施形態では、作品が、マイクロホンまたはマイクロホン配列によってリアルタイムで受信され、さらに、オーディオ受信器ユニット５０６によって受信されるよう、アナログ電気入力１０２に変換される。他の実施形態では、入力１０２は、再生に適した記録済み楽曲ファイルなどのデジタルデータを含んでもよい。入力１０２がアナログ信号であれば、信号処理装置ユニット５１０、音符処理装置ユニット５３０、および楽譜処理装置ユニット５５０によるデジタル信号処理に備えて、オーディオ受信器ユニット５０６によってデジタル表現に変換されてもよい。入力１０２がリアルタイムで受信される場合、入力１０２の全長をあらかじめ判断する方法はないと考えられる。よって、入力１０２は、所定間隔（例えば、経過時間、デジタルサンプルの数、メモリ使用量など）で受信および格納され、それに合わせて処理されてもよい。別の実施形態では、記録済みのサウンドクリップが、オーディオ受信器５０６により受信されてデジタル化され、それによって固定の時間間隔を有するものになる。

楽曲分解ユニット１２０の一実施形態の下位ブロック図が、図５Ｂに示されている。１つ以上のオーディオソース５０２が、楽曲入力信号１０２を生成するために使用されてもよい。オーディオソース５０２は、楽曲入力信号１０２をオーディオ受信器５０６に提供することができる任意のものであってもよい。いくつかの実施形態では、１つ以上のマイクロホン、トランスデューサ、および／またはその他のセンサが、オーディオソース５０２として使用される。マイクロホンが、生のパフォーマンス（または記録されたパフォーマンスの再生）からの圧力波または電磁波を、楽曲入力信号１０２として使用される電気信号へと変換してもよい。例えば、生のオーディオパフォーマンスでは、歌い手からのオーディオの検知および変換を行うためにマイクロホンが使用されてもよく、その一方で、ギターおよびベースからのオーディオの検知および変換を行うために電磁「ピックアップ」が使用されてもよい。他の実施形態では、オーディオソース５０２は、楽曲入力信号１０２、または楽曲入力信号１０２を読み取ることができるオーディオファイルを提供するよう構成されたアナログまたはデジタル装置を含んでもよい。例えば、デジタル化オーディオファイルは、オーディオ形式でストレージ媒体上に格納され、そのストレージ媒体によって、楽曲入力信号１０２としてオーディオ受信器５０６に提供されてもよい。

当然のことながら、オーディオソース５０２次第で、楽曲入力信号１０２は異なる特性を有してもよい。楽曲入力信号１０２は、モノフォニックであってもポリフォニックであってもよく、複数のトラックのオーディオデータを含んでもよく、多数の種類の楽器からのオーディを含んでもよく、特定のファイルフォーマットなどを含んでもよい。同じく、当然のことながら、オーディオ受信器５０６は楽曲入力信号１０２を受信することができる任意のものであってもよい。さらに、オーディオ受信器５０６は、オーディオソース５０２と接続し、音楽入力信号１０２を受信または解釈するために必要な１つ以上のポート、デコーダ、またはその他のコンポーネントを含んでもよい。

オーディオ受信器５０６は、さらなる機能を提供してもよい。一実施形態では、オーディオ受信器５０６は、アナログ楽曲入力信号１０２をデジタル楽曲入力信号１０２に変換する。別の実施形態では、オーディオ受信器５０６は、楽曲入力信号１０２を、より低いサンプルレートにダウンコンバートして、システム５００に対する計算負荷を軽減するよう構成されている。一実施形態では、楽曲入力信号１０２は約８〜９ｋＨｚにダウンサンプリングされる。これは、楽曲入力信号１０２のより高い周波数分解能を提供することができ、システム５００の設計に対するいくらかの制約（例えばフィルタの規格）を軽減することができる。

さらに別の実施形態では、オーディオ受信器５０６は、オーディオレベルが一定の閾値を超えたことの検出に基づき、楽曲入力信号１０２の受信を開始する（例えば記録を開始する）よう設定された、閾値検出コンポーネントを含む。例えば、閾値検出コンポーネントは、特定の期間にわたってオーディオを分析して、楽曲入力信号１０２の振幅が或る一定時間、所定の閾値より上にとどまるかどうかを検出してもよい。閾値検出コンポーネントは、楽曲入力信号１０２の振幅が一定時間、所定の閾値未満に下がると、楽曲入力信号１０２の受信を中断する（例えば記録を中断する）ようさらに設定されてもよい。さらに別の実施形態では、閾値検出コンポーネントは、楽曲入力信号１０２の受信を実際に開始または終了するのではなく、楽曲入力信号１０２の振幅が、或る時間の間、閾値を超えた状態かまたは閾値未満に下がった状態を表す、システム５００のフラグを生成するために使用されてもよい。

図５Ｂによれば、オーディオ受信器５０６は、楽曲入力信号１０２を信号処理装置ユニット５１０に渡す。信号処理装置ユニット５１０は、振幅抽出ユニット５１２および周波数抽出ユニット５１４を含む。振幅抽出ユニット５１２は、楽曲入力信号１０２から振幅関連情報を抽出するよう構成されている。周波数抽出ユニット５１４は、楽曲入力信号１０２から周波数関連情報を抽出するよう構成されている。

一実施形態では、周波数抽出ユニット５１４は、変換アルゴリズムを使用して時間領域からの信号を周波数領域に変換する。例えば、時間領域では、楽曲入力信号１０２は経時的な振幅の変化として表されてもよい。一方、高速フーリエ変換（ＦＦＴ）アルゴリズムを適用した後、同じ楽曲入力信号１０２は、その周波数成分それぞれの振幅のグラフとして表されてもよい（例えば、倍音系列のような、信号が処理される周波数範囲内の各周波数帯の相対的強度または相対的寄与率）。処理を効率化するには、このアルゴリズムを一定の周波数範囲に限定することが望ましいこともある。例えば、周波数範囲は可聴スペクトル（例えば約２０Ｈｚ〜２０ｋＨｚ）のみにわたってもよい。

様々な実施形態において、信号処理装置ユニット５１０は、周波数関連情報を他の方法で抽出してもよい。例えば、多数の変換アルゴリズムは、固定幅の線形周波数「バケット（ｂｕｃｋｅｔｓ）」において信号を出力する。これは、特にオーディオ信号が事実上本質的に（線形ではなく）対数的かもしれないということを考えると、可能な周波数分解能または変換の効果を制限する可能性がある。当該技術分野では、楽曲入力信号１０２から周波数関連情報を抽出するための多数のアルゴリズムが既知となっている。

続いて、振幅抽出ユニット５１２により抽出された振幅関連情報と、周波数抽出ユニット５１４により抽出された周波数関連情報とが、音符処理ユニット５３０の様々なコンポーネントによって使用されてもよい。いくつかの実施形態では、音符処理ユニット５３０は、音符開始検出器ユニット５３２、音符持続時間検出器ユニット５３４、ピッチ検出器ユニット５３６、休符検出器ユニット５４４、包絡線検出器ユニット５３８、音色検出器ユニット５４０、および音符強弱検出器ユニット５４２のうちの全部または一部を含む。

音符開始検出器ユニット５３２は、音符開始を検出するよう構成されている。音符の開始（すなわち始まり）は、典型的には、楽曲の中でピッチの変化として（例えばスラー）、振幅の変化として（例えば包絡線の、アタッチ部（ａｔｔａｃｈ ｐｏｒｔｉｏｎ））、またはピッチおよび振幅の変化の何らかの組み合わせとして現れる。よって、音符開始検出器ユニット５３２は、周波数（すなわちピッチ）および／または振幅に特定の種類の変化があるときは常に音符開始イベントを生成するよう設定されてもよい。

音符は、その持続時間（例えば、秒またはサンプル数での、音符が続く時間）によって特徴づけられてもよい。いくつかの実施形態では、音符処理ユニット５３０は、音符開始イベントによりマークされた音符の持続時間を検出するよう構成されている音符持続時間検出器ユニット５３４を含む。

なお、楽曲の一部の特性は、単に信号の物理的特質ではなく、心理音響的なものである。例えば、周波数は信号の物理的特性である（例えば、正弦波が伝わるサイクル数／秒を表す）が、ピッチはより複雑な心理音響的現象である。１つの理由は、楽器から出る単一のピッチの音符は、通常、振幅のそれぞれ異なるいくつかの周波数で構成されているということであり、これは音色として知られる。脳は、それらの周波数のうち１つ（例えば、典型的には基本周波数）を「ピッチ」として感知し、他の周波数は、単にその音符に対して「調和した音色」を加えるものとして感知すると考えられる。場合によっては、聴き手が体験する音符のピッチは、ほとんどまたは完全に、信号にない周波数であることもある。

いくつかの実施形態では、音符処理ユニット５３０は、音符開始イベントによりマークされた音符のピッチを検出するよう構成されているピッチ検出器ユニット５３６を含む。他の実施形態では、ピッチ検出器ユニット５３６は、個々の音符のピッチを追跡する代わりに（またはそれに加えて）、楽曲入力信号１０２のピッチを追跡するよう設定されている。当然のことながら、場合によって、ピッチ検出器ユニット５３６は、閾値を超える楽曲入力信号１０２のピッチの変化を判断するために音符開始検出器ユニット５３２により使用されてもよい。

音符処理ユニット５３０のいくつかの実施形態は、楽曲入力信号１０２中の休符の存在を検出するよう構成されている休符検出器ユニット５４４を含む。休符検出器ユニット５４４の一実施形態は、振幅抽出ユニット５１２によって抽出された振幅関連情報と、ピッチ検出器ユニット５３６によって生成された信頼情報とを使用する。例えば、振幅関連情報は、楽曲入力信号１０２の振幅が、或る時間ウィンドウにわたって相対的に低い（例えば、ノイズフロアにあるか、またはそれに近い）ことを明らかにしてもよい。ピッチ検出器ユニット５３６は、同じ時間ウィンドウにわたって、特定ピッチの存在の信頼度が非常に低いと判断してもよい。この情報および他の情報を使用して、休符検出器ユニット５４４は、休符の存在と、休符が開始したと思われる時間位置とを検出する。

いくつかの実施形態では、音符処理ユニット５３０は、音色検出器ユニット５４０を含む。振幅抽出ユニット５１２によって抽出された振幅関連情報と、周波数抽出ユニット５１４によって抽出された周波数関連情報とが、音色検出器ユニット５４０によって、楽曲入力信号１０２の一部の音色情報を検出するために使用されてもよい。オーディオ信号１０２のこの部分の倍音構成（ｈａｒｍｏｎｉｃ ｃｏｍｐｏｓｉｔｉｏｎ）を、音色情報が明らかにしてもよい。いくつかの実施形態では、音色検出器ユニット５４０は、音符開始イベントから開始する特定の音符に関する音色情報を検出してもよい。

音色検出器ユニット５４０の一実施形態では、ガウシアンフィルタを用いて振幅関連情報および周波数関連情報の畳み込みが行われ、フィルタ処理されたスペクトルが生成される。続いて、フィルタ処理されたスペクトルは、ピッチ検出器ユニット５３６によって検出されたピッチの周りに包絡線を生成するために使用されてもよい。この包絡線は、当該ピッチの音符の音色に対応してもよい。

いくつかの実施形態では、音符処理ユニット５３０は、包絡線検出器ユニット５３８を含む。振幅抽出ユニット５１２によって抽出された振幅関連情報が、包絡線検出器ユニット５３８によって、楽曲入力信号１０２の一部の包絡線情報を検出するために使用されてもよい。例えば、ピアノを打鍵すると、ハンマーに弦の組をたたかせることができ、アタック振幅の大きなオーディオ信号をもたらす。この振幅は、急速なディケイを経て、弦が共振する若干の定常状態振幅でのサステイン状態に至る（当然、弦のエネルギーが消耗されるにつれ、包絡線のこの部分にわたって振幅は徐々に小さくなると考えられる）。最後に、ピアノの鍵がリリースされると、ダンパーが弦の上に降り振幅が急速にゼロに落ちる。この種類の包絡線は、典型的には、ＡＤＳＲ（ａｔｔａｃｋ，ｄｅｃａｙ，ｓｕｓｔａｉｎ，ｒｅｌｅａｓｅ：アタック、ディケイ、サステイン、リリース）包絡線と呼ばれる。包絡線検出器ユニット５３８は、ＡＤＳＲ包絡線の各部分の一部もしくは全部、またはその他任意の種類の有用な包絡線情報を検出するよう設定されてもよい。

様々な実施形態において、音符処理ユニット５３０は、音符強弱検出器ユニット５４２も含む。特定の実施形態では、音符強弱検出器ユニット５４２は、特定の音符開始イベントから開始する特定の音符に対して、包絡線検出器ユニット５３８に似た機能を提供する。他の実施形態では、音符強弱検出器ユニット５４２は、包絡線検出器ユニット５３８によって検出されている包絡線のパターンに関して、基準からはずれているか、または或る所定のパターンに適合する音符包絡線を検出するよう構成されている。例えば、スタッカートの音符は、そのＡＤＳＲ包絡線の鋭いアタック部分と、短いサステイン部分とを特徴とすると考えられる。別の例では、アクセントのある音符は、周囲の音符のアタック振幅よりも著しく大きいアタック振幅を特徴とすると考えられる。

当然のことながら、音符強弱検出器ユニット５４２および他の音符処理ユニットは、分解済み出力５７０の一部として望ましいと思われる、音符の他の特質を複数特定するために使用されてもよい。例えば、音符は、スラー、アクセント、スタッカート、装飾音符などとして記号を付けられることもある。その他多数の音符の特性が、本発明により抽出されてもよい。

複数の音符または音符開始イベント（休符を含む）に関する情報が、他の情報の生成に使用されてもよい。図５Ｂの実施形態によれば、音符処理ユニット５３０の様々なコンポーネントが、楽譜処理ユニット５５０の様々なコンポーネントと動作的に通信してもよい。楽譜処理ユニット５５０は、テンポ検出ユニット５５２、拍子検出ユニット５５４、調検出ユニット５５６、楽器同定ユニット５５８、トラック検出ユニット５６２、および全体的強弱検出ユニット５６４のうちの全部または一部を含んでもよい。

いくつかの実施形態では、楽譜処理ユニット５５０は、時間ウィンドウにわたる楽曲入力信号１０２のテンポを検出するよう構成されているテンポ検出ユニット５５２を含む。典型的には、楽曲の一部分のテンポ（例えば、音響心理学的に楽曲が進むように思われる速度）は、ある程度、音符および休符の存在および持続時間による影響を受けると思われる。よって、テンポ検出ユニット５５２の特定の実施形態は、音符開始検出器ユニット５３２、音符持続時間検出器ユニット５３４、および休符検出器ユニット５４４からの情報を使用して、テンポを判断する。テンポ検出ユニット５５２の他の実施形態は、判断されたテンポをさらに使用して、音価（例えば、４分音符、８分音符など）を音符および休符に割り当てる。

拍子は、楽曲の各小節にいくつの拍があり、どの音価を１拍と見なすかを規定する。例えば、４／４という拍子は、各小節が４拍（分子）を有し、１拍が４分音符（分母）で表されるということを表す。このため、拍子は、音符および縦線の場所、さらに有用な分解済み出力５７０を提供するために必要となり得る他の情報を判断する助けとなると考えられる。いくつかの実施形態では、楽譜処理ユニット５５０は、楽曲入力信号１０２の拍子を検出するよう構成されている拍子検出ユニット５５４を含む。

いくつかの実施形態では、単純拍子は、テンポ情報、およびテンポ検出ユニット５５２により抽出された音価、ならびにその他の情報（例えば、音符強弱検出器ユニット５４２により抽出された音符強弱情報）から推測される。しかし通常、拍子の判断は、複雑なパターン認識を伴う複雑なタスクである。

例えば、楽曲入力信号１０２から、４分音符、４分音符、８分音符、８分音符、８分音符、８分音符という音価の並びが抽出されると仮定する。この単純な並びは、４／４の１小節、２／４の２小節、１／４の４小節、８／８の１小節、またはその他多数の拍子として表すことができるであろう。最初の４分音符および最初の８分音符にアクセント（例えば増大したアタック振幅）があったと仮定すれば、これによって、この並びは、２／４の２小節、４／８の２小節、または４／４の１小節である可能性がより高くなる。さらに、４／８が非常にまれな拍子であるということを前提とすると、推測として４／８を除外するのに十分であると思われる。さらに、楽曲入力信号１０２のジャンルがフォークソングであるという認識によって、４／４が最も適当な拍子候補である可能性がより高くなることもある。

上記の例は、非常に単純な音価の並びによってさえ含まれる複雑性を明らかにするものである。多くの音符の並びはより一層複雑であり、音価の異なる多数の音符、複数の小節にわたる複数の音符、付点音符および装飾音符、シンコペーション、ならびに拍子の解釈における他の難点を伴う。このため、従来の計算アルゴリズムでは、正確に拍子を判断するのが困難なこともある。よって、拍子検出ユニット５５４の様々な実施形態は、そうした複雑なパターンを検出するよう訓練された人工ニューラルネットワーク（ＡＮＮ）５６０を使用する。ＡＮＮ５６０は、異なる拍子の多数のサンプルと、サンプル毎に精緻化されるコスト関数とを、ＡＮＮ５６０に提供することによって訓練されてもよい。いくつかの実施形態では、ＡＮＮ５６０は、学習パラダイムを使用して訓練される。この学習パラダイムは、例えば、教師あり学習、教師なし学習、または強化学習アルゴリズムを含んでもよい。

当然のことながら、テンポと拍子情報とのいずれかまたは両方を使用することによって、楽曲構成要素または分解済み出力５７０として使用される多数の有用な種類の情報が生成されてもよい。例えば、その情報は、符尾で音符を個々に指定するのではなく複数の音符を棒でまとめるべきところ（例えば、８分音符の組として）の判断、音符を２小節にわたって分割するべきときと、タイで連結するべきときとの判断、または複数音符の組を３連符（またはさらに高次の組）、装飾音符、トリルもしくはモルデント、グリッサンドとして指定するべきときの判断などを可能にしてもよい。

楽曲構成要素または分解済み出力５７０を生成するのに有用となり得る情報のもう１つの組は、楽曲入力信号１０２の或るセクションの調に関係する。調情報は、例えば、特定された根音のピッチおよび関連するモダリティを含んでもよい。例えば、「イ短調」は、調の根音のピッチが「Ａ音」であり、モダリティが短調であることを表す。それぞれの調は、調号によって特徴づけられる。調号は、「調内の」音符（例えば調に関連する全音階の一部）および「調外の」音符（例えば調の枠組みにおける変化音）を特定する。例えば、「イ短調」は、シャープもフラットも含まないが、「ニ長調」は、２つのシャープを含み、フラットは含まない。

いくつかの実施形態では、楽譜処理ユニット５５０は、楽曲入力信号１０２の調を検出するよう構成されている調検出ユニット５５６を含む。調検出ユニット５５６のいくつかの実施形態は、ピッチの並びとコスト関数の組との比較に基づいて調を判断する。例えば、コスト関数は、規定の時間ウィンドウにわたる楽曲の一部分において、変化音の数を最小限にしようとしてもよい。他の実施形態では、調検出ユニット５５６は、複雑な調判断を行うため、または精緻化するために、人工ニューラルネットワークを使用してもよい。さらに他の実施形態では、調判断を精緻化するために、一連の調変更がコスト関数に対して評価されてもよい。さらに他の実施形態では、調検出ユニット５５６によって得られた調情報が、特定の調のピッチ指示により音符（または音符開始イベント）に属性を与えるために使用されてもよい。例えば、ヘ長調の「Ｂ音」は、「Ｂナチュラル」と表されてもよい。当然、調情報は、調号または楽曲楽譜表現についての他の情報を生成するために使用されてもよい。いくつかの実施形態では、調情報はさらに、コードまたはその他の倍音情報を生成するために使用されてもよい。例えば、ギターのコードがタブラチュア形式で生成されてもよく、またはジャズコードが提供されてもよい。

他の実施形態では、楽譜処理ユニット５５０は、楽曲入力信号１０２でプレイされている楽器を特定するよう構成された、楽器同定ユニット５５８も含む。楽器は、特定の音色を有するといわれることが多い。しかし、プレイされている音符または音符のプレイの仕方次第で、単一の楽器に関しても音色の違いがあると考えられる。例として、例えばバイオリンを構成するのに使用されている素材、演奏者の弾き方、プレイされている音符（例えば、開放弦でプレイされる音符は、指で押さえた弦でプレイされる同じ音符とは音色が異なり、バイオリンの音域において低い音符は、高音域の音符とは音色が異なる）、音符が弓で弾かれるかはじかれるかなどに基づき、あらゆるバイオリンの音色が異なる。しかしそれでも、バイオリンの音符間には、ほかの楽器とは別ものとしてそれをバイオリンであると特定するのに十分な類似点があると考えられる。

楽器同定ユニット５５８の実施形態は、単一または複数の音符の特性を比較して、楽曲入力信号１０２の、或る楽器でプレイされているように考えられるピッチの範囲、そうしたピッチそれぞれにおいてその楽器からつくり出される音色、および／またはその楽器でプレイされている音符の振幅包絡線を判断するよう構成されている。一実施形態では、音色の違いを使用し、複数の楽器サンプルの典型的な音色の特徴と、楽曲入力信号１０２から検出された音色とを比較することによって種々の楽器を検出する。例えば、同じ音符を同じ音量で同じ持続時間プレイしても、サックスとピアノとは、それらの異なる音色が理由で、全く異なって聞こえると考えられる。当然、上記のように、音色のみに基づく同定は、正確さが限られる可能性がある。

別の実施形態では、種々の楽器を検出するためにピッチ範囲が使用される。例えば、チェロは、典型的には、中央Ｃより約２オクターブ下から、中央Ｃの約１オクターブ上の範囲の音符が出ると考えられる。一方、バイオリンは、中央Ｃのすぐ下から、中央Ｃの約４オクターブ上の範囲の音符が出ると考えられる。したがって、バイオリンとチェロとは似た音色を持つとはいえ（どちらも擦弦楽器である）、それらのピッチ範囲は、同定に使用するには十分異なる。当然、ある程度は範囲が重複することから、誤りは起こり得ると考えられる。さらに、他の楽器（例えば、ピアノ）はより広い範囲を有し、その範囲は多数の楽器と重複し得る。

さらに別の実施形態では、包絡線検出が、種々の楽器を特定するために使用される。例えば、打楽器（例えば、ピアノ）でプレイされる音符は、木管（例えば、フルート）、リード（例えば、オーボエ）、金管（例えば、トランペット）、または弦（例えば、バイオリン）楽器でプレイされる同じ音符とは異なって聞こえると考えられる。しかし、各楽器は、どのように音符がプレイされるかによって、多数の異なる種類の包絡線を作り出せることもある。例えば、バイオリンは、はじかれること、もしくは弓で弾かれることもあり、または、音符がレガートでプレイされることも、スタッカートでプレイされることもある。

少なくとも上記の問題が理由で、正確な楽器同定には、場合によっては複数の音符にわたる楽曲入力信号１０２の複数の特性を含む、複雑なパターンの検出が必要なこともある。よって、楽器同定ユニット５５８のいくつかの実施形態は、こういった複雑なパターンの組み合わせを検出するよう訓練された人工ニューラルネットワーク５６０を利用する。

楽譜処理ユニット５５０のいくつかの実施形態は、楽曲入力信号１０２の中からオーディオトラックを特定するよう構成されているトラック検出ユニット５６２を含む。場合によっては、楽曲入力信号１０２は、既にトラックを単位として分かれた形式となっていることもある。例えば、いくつかのデジタルオーディオテープ（ＤＡＴ：Ｄｉｇｉｔａｌ Ａｕｄｉｏ Ｔａｐｅ）上のオーディオは、８つの別々のデジタルオーディオトラックとして格納されることもある。こうした場合には、トラック検出ユニット５６２は、単に個々のオーディオトラックを同定するように構成されていればよい。

一方、他の場合には、複数のトラックが、単一の楽曲入力信号１０２に格納されており、その楽曲入力信号から特定のデータを抽出することによって特定する必要があることもある。よって、トラック検出ユニット５６２のいくつかの実施形態は、楽曲入力ファイル１０２から抽出された情報を使用して、別々のオーディオトラックを同定するよう構成されている。例えば、パフォーマンスが、同時に鳴っている５つの楽器を含むもある（例えばジャズ五重奏）。その別々の楽器を、別々のトラックとして同定することが望ましいこともある。

トラック検出は、いくつかの異なる方法で実現することができる。一実施形態では、トラック検出ユニット５６２は、ピッチ検出を使用して、種々の音符の並びが特定のピッチ範囲に限定されているようであるかどうかを判断する。別の実施形態では、トラック検出ユニット５６２は、楽器同定ユニット５５８からの楽器同定情報を使用して、異なるトラックを判断する。

多くの楽譜は、作品またはパフォーマンスの全体的な強弱に関する情報も含む。全体的な強弱は、上述の音符強弱とは対照的に、２つ以上の音符にわたる強弱を指す。例えば、作品全体または作品の中のセクションに、フォルテ（強音で）またはピアノ（弱音で）として記号を付けられていることもある。別の例では、音符の並びが、クレッシェンドで徐々に大きくなることもある。この種類の情報を生成するために、楽譜処理ユニット５５０のいくつかの実施形態は、全体的強弱検出ユニット５６４を含む。全体的強弱検出ユニット５６４の実施形態は、場合によっては音符強弱情報および／または包絡線情報を含む振幅情報を使用して、全体的な強弱を検出する。

特定の実施形態では、強弱の判断を助けるために、閾値があらかじめ定められるか、または楽曲入力信号１０２から適応的に生成される。例えば、ロックのパフォーマンスの平均音量はフォルテと見なされてもよい。その平均をいくらかの量上回る（例えば、閾値、標準偏差などに基づいて）振幅は、フォルティシモと見なされてもよく、その一方で、その平均未満にいくらかの量下がる振幅は、ピアノと見なされてもよい。

特定の実施形態はさらに、強弱の変化が生じる期間を考慮してもよい。例えば、２分間の静かな音符で開始し、突然２分間の、より大きい音符のセクションに切り替わる作品は、ピアノのセクションに続いてフォルテのセクションを有すると見なされてもよい。一方、数個の音符にわたって大きくなっていき、さらに数個の音符の間、その大きい音量のままであり、続いて元の振幅に戻る静かな作品は、クレッシェンドに続いてデクレッシェンドがあると見なされてもよい。

上述の様々な種類の情報すべて、およびその他任意の有用な情報が、楽曲構成要素または分解済み出力５７０として使用されるよう生成されてもよい。システムの様々なコンポーネントに関連して記載された楽曲構成要素または分解済み出力５７０に加えて、任意の数の他の楽曲構成要素または分解済み出力５７０が、同じ情報または他の情報から生成されてもよい。一例において、音符がスタッカートの点の付いた８分音符であると判断されると仮定する。他の楽曲５７０構成要素は、音符の符頭、符幹、符尾、付点、スタッカートの点、およびその他の音符の特性を含んでもよい。さらに他の楽曲構成要素５７０は、ディスプレイまたはプリントアウト上での音符表現のスタイルまたは色、符幹の方向（例えば、方向は、デフォルトにされても、または譜表上の音符の位置に基づいて決定されてもよく、または音符が特定の音符の並びの一部であることを示すよう変更されてもよい）、音符の符頭のサイズ（例えば、他の音符と区別するために、または他の何らかの理由で、読みやすいようにサイズ調整されてもよい）、符頭の形（例えば、衝撃音に関しては違う形であってもよい）、またはその他任意の有用な情報を含んでもよい。他の例では、楽曲構成要素または分解済み出力５７０は、五線、音部記号、小節番号、歌詞、歌詞の位置合わせ、ページタイトル、譜表のタイトル、余白、楽器編成データ、再生データなどを含んでもよい。さらに他の例では、楽曲構成要素または分解済み出力５７０は、楽曲ベースの検索の有効性を向上させることに役立つ別の情報を含んでもよい。楽曲構成要素または分解済み出力５７０は、保存または出力されてもよい。

当然のことながら、上述の様々なユニットおよびコンポーネントが、本発明から逸脱せずに様々な方法で実装されてもよい。例えば、特定のユニットが、他のユニットのコンポーネントであってもよく、または別のユニットの追加機能として実装されてもよい。さらに、本発明によれば、ユニットは多数の方法で接続可能であり、データはそれらの間を多数の方法で流れることができる。さらに、オーディオ分解に関する様々な実施形態が、２００８年２月１日に出願された、Ｒｏｂｅｒｔ Ｄ． Ｔａｕｂらの、「ＭＵＳＩＣ ＴＲＡＮＳＣＲＩＰＴＩＯＮ」という題の米国特許出願第１２／０２４９８１号明細書にさらに深く記載されており、これは、あらゆる目的において、参照によって本願明細書に引用したものとする。

（楽譜分解）
場合によっては、オーディオ信号から楽曲構成要素を分解するのに加えて、またはその代わりに、楽譜画像から楽曲構成要素を分解することが望ましいこともある。本発明の各実施形態は、楽譜画像を入力として受け取るよう構成される。当然のことながら、楽譜画像から楽曲構成要素を分解するため、すなわち楽譜分解を実行するための、多数の方法が考えられる。

図６Ａは、本発明に従って楽曲画像データを処理し、光学式文字認識（ＯＣＲ）機能を提供するシステムを示す。ＯＣＲ処理装置６０２は、カメラまたはスキャナなどの楽譜キャプチャ装置６０６を用いて取り込まれる楽曲楽譜６０４の画像データを受信する。ＯＣＲ処理装置６０２は、楽曲楽譜入力に対応するデータを含む楽曲楽譜出力を作り出すが、この出力は様々な用途に用いることができるデジタル形式である。楽曲楽譜のデジタル表現は、次に限定されるものではないが、プリント出力、検索メカニズムによる使用のため、配布および複数ユーザとの共同制作のため、ならびにＭＩＤＩコンポーネントなどを用いたオーディオ出力の生成のためを含め、他のシステムによって容易に処理することができる。例えば、図６Ａは、楽曲楽譜出力が、印刷機能６０８、検索機能６１０、配布機能６１２、およびオーディオ／ＭＩＤＩ出力６１４に提供可能であることを示す。

この取り込まれた楽曲楽譜画像は、ウェブカメラ、電話のカメラ、簡単処理のカメラ、ならびにその他より高性能なカメラを含む、任意の画像キャプチャ装置を用いて作り出すことが可能である。楽曲楽譜の画像は、取り込まれると、調節およびさらなる処理のためにＯＣＲ処理装置に渡される。

図６Ｂは、ＯＣＲ処理装置６０２への入力として提供される、キャプチャ装置６０６（図６Ａ）からつくり出された画像データ６５２を示す。図６Ｂは、ＯＣＲ処理装置６０２が、画像データを受信する画像前処理コンポーネント６５４を含むことを示す。画像データは、例えば、ビットマップ画像（．ｂｍｐ）、ＪＰＥＧデータ、ＴＩＦＦデータの形式、およびデジタルカメラによって一般に使用される他のファイル形式などとしてもよい。画像前処理コンポーネントは、２値化、画像のスキュー補正、および不適切なバックグラウンド成分の除去を実行する。２値化の動作は、取り込み画像内の明るさおよびコントラストの調節に関係する。スキュー補正の動作は、楽譜の五線が画像の下側の縁に平行にそろう方向から回転している画像を補正することに関係する。不適切なバックグラウンド成分の除去は、ノイズアーチファクトおよびその他不要なバックグラウンド成分を除去することによって、画像をクリーンにする。必要に応じて、前処理動作は、外部の画像処理ルーチンまたはモジュールによって実行することができる。

前処理コンポーネント６５４は、結果として生じるデータを、ニューラルネットワーク（ＮＮ）処理コンポーネント６５６に提供する。ＮＮ処理コンポーネント６５６は、取り込み画像内の音楽記号体系を特定し、光学画像の認知処理を実行する。すなわち、ニューラルネットワークは、取り込み楽曲画像内の楽曲記号を認識するコンピュータプロセスを実行し、必要に応じて、特定されたシンボルの認知的解釈を入力データから行って推定を行い、取り込み画像内のアーチファクトまたは記号体系に対する適切なラベルを判断する。

ＮＮ処理コンポーネント６５６は、調節された楽曲楽譜画像を受信する訓練されたニューラルネットワークを含む。必要に応じて、訓練されたニューラルネットワークは、その出力をフィードバックの提供に利用して、その動作を調節することができる。そのようなフィードバックは、バックプロパゲーション技術を利用するために、または既に訓練されているニューラルネットワークのネットワークノードの重みを調節するために、因子グラフ演算を伴うこともある。出力をフィードバックとして使用するための他の技術は、当業者には既知である。

ＮＮ処理コンポーネント６５６の出力は、後処理コンポーネント６５８に提供され、後処理コンポーネント６５８は、ＮＮの出力を作り出す。次に、後処理コンポーネントの出力は、図６Ａに示されている印刷、検索、配布、およびオーディオ機能など、様々な機能に提供することができる。後処理コンポーネントは、ＮＮ出力に対して解釈機能を実行して、ＮＮによって特定されたどのアーチファクトの種類が正確である可能性があるか否かを判断する。後処理コンポーネント６５８による解釈は、ＮＮによりつくり出される信頼値に基づく。当業者であれば、ＮＮ信頼値出力データの解釈技術を熟知しているであろう。次に、後処理は、音符情報または特定された楽譜のアーチファクトに対応する他の情報などのＯＣＲ処理装置出力を適切な形式で作り出す。例えば、楽曲情報は、ＭＩＤＩ形式などの電子楽器表現の形式、またはその他のデータ形式、またはその他の情報の組み合わせという形式をとってもよい。

当然のことながら、上述の様々なユニットおよびコンポーネントが、本発明から逸脱せずに様々な方法で実装されてもよい。例えば、特定のユニットは、他のユニットのコンポーネントであってもよく、または、別のユニットの追加機能として実装されてもよい。さらに、本発明によれば、ユニットは多数の方法で接続されてよく、データはそれらの間を多数の方法で流れてもよい。さらに、楽譜分解に関する様々な実施形態が、２００８年２月１３日に出願されたＲｏｂｅｒｔ Ｄ． Ｔａｕｂらの、「ＭＵＳＩＣ ＳＣＯＲＥ ＤＥＣＯＮＳＴＲＵＣＴＩＯＮ」という題の米国特許仮出願第６１／０２８，４９０号明細書にさらに深く記載されており、これは、あらゆる目的において、参照によって本願明細書に引用したものとする。楽曲楽譜キャプチャ技術の他の側面は、２００５年１２月１５日に出願されたＲｏｂｅｒｔ Ｄ．Ｔａｕｂらの、「ＳＹＳＴＥＭ ＡＮＤ ＭＥＴＨＯＤ ＦＯＲ ＭＵＳＩＣ ＳＣＯＲＥ ＣＡＰＴＵＲＥ ＡＮＤ ＳＹＮＣＨＲＯＮＩＺＥＤ ＡＵＤＩＯ ＰＥＲＦＯＲＭＡＮＣＥ ＷＩＴＨ ＳＹＮＣＨＲＯＮＩＺＥＤ ＰＲＥＳＥＮＴＡＴＩＯＮ」という題の米国特許出願第１１／３０３，８１２号明細書から入手でき、これは、あらゆる目的において、参照によって本願明細書に引用したものとする。

（検索エンジン）
本発明の多数の側面は、検索エンジンの機能および／または構造に関連する。いくつかの実施形態では、検索エンジンは、図１の検索エンジン１６０として実装されてもよい。共同制作ポータルの様々な実施形態は、検索入力および出力の操作、検索実行、および結果の処理、ならびにファイル管理、楽曲ビューイング、楽曲およびテキスト編集、および楽曲ベースの検索の、他の側面に関する機能を提供してもよい。当然のことながら、グラフィカルユーザインターフェース（「ＧＵＩ」）の設計および実装、共同制作ポータルが可能にするユーザインタラクションのレベル、ＧＵＩコントロールの種類、モジュールとコンポーネントとの間の機能上の重複部分および依存関係、ネットワーク設計およびインターフェース、ならびに検索エンジンの他の側面に関して、多数の可能性がある。よって、以下の説明は、本発明のいくつかの例示的実施形態のみの記載を目的としており、当業者には当然のことながら、本発明の範囲は、開示される具体的な実施形態によって制限されることはない。

図７は、本発明による楽曲ベースの検索エンジンの実施形態で使用されるグラフィカルユーザインターフェース（ＧＵＩ）の例示的な一構成を示す。ＧＵＩ７００は、検索入力セクション７０２および検索結果セクション７５０という、少なくとも２つの主要セクション（図７ではフレームとして示されている）を含む。検索入力セクション７０２は、特に、様々な種類の検索入力の受信および処理、ならびにそれらを使用しての検索パラメータの生成を取り扱う。検索結果セクション７５０は、特に、検索結果の受信、検索結果の表示、および検索出力の生成を取り扱う。

検索入力セクション７０２は、入力の受信、入力の表示、および入力セクションの制御に関係するいくつかのＧＵＩ構成要素を含む。本発明によれば、キーワード入力７０４、オーディオ入力７０６、および楽譜入力７０８を含む、いくつかの種類の入力受信が可能である（図７に示されているように）。キーワード入力、オーディオ入力、および楽譜入力は、同じクエリの一部として受信されてもよく、または、反復する形で連続的に、もしくは任意の順序で受信されてもよい。キーワード入力７０４は、任意の種類の英数字、文字またはテキスト関連の入力の受信を含む。一実施形態では、キーワード入力７０４は、通常語テキストを含み、これは、キーワードの組を生成するために解釈される。別の実施形態では、キーワード入力７０４は、キーワードに変換されるよう機能可能な特殊テキストを含む。例えば、特殊テキストは、フィールドエントリ、ブール演算子などを含んでもよい。次に、テキストは、任意の有用な方法で処理されてもよい（例えば、ＸＭＬのようなマークアップ言語における文書型定義を使用して）。

さらに別の実施形態では、キーワード入力７０４は、オーディオ信号処理を使用して受信される。例えば、ユーザは、記録ボタン７１０をクリックするとよく、これによって音声記録が開始する。次に、音声記録は、スピーチトゥテキストプロセッサによって処理されてもよい。続いて、処理されたテキストは、上記で説明された方法を含む任意の有用な方法で、クエリ入力用のキーワードへとさらに処理されてもよい。

一実施形態では、受信されたキーワード入力７０４は、「ＴＥＭＰＯ（‘９０−１００’）＆ ＧＥＮＲＥ（‘ｊａｚｚ ｏｒ ｂｌｕｅｓ’）＆ ＳＴＡＲＴＫＥＹ（‘Ｄ−ｍｉｎｏｒ’）＆ ＡＵＤＩＯ＿ＩＮＰＵＴ（ＤＥＣＯＮＳＴＲＵＣＴ（‘ｒｈｙｔｈｍ’））」である。当然のことながら、この受信されたキーワード入力７０４は、実例を示すことのみを目的としており、入力は、他の多数の内容および種類のキーワード入力を含むことができるであろう。この例示的なキーワード入力７０４は、検索者が、９０から１００ｂｐｍのテンポで、ジャズまたはブルースのジャンルで、ニ短調という開始調で、受信されるオーディオ入力から分解されるリズムに似たリズムである曲を見つけたいということを表すと考えられる。なお、「＆」はブールの「ａｎｄ」演算を示す。なお、さらに、キーワード入力の受信および処理のための多数の方法が当技術分野で既知であり、その多くは、ユーザが、特殊な記号論を学ばずにキーワードを入力できるようにする。

オーディオ入力７０６は、異なるいくつかの方法で受信および処理可能である。考えられる様々な受信および処理の機能を盛り込むために、ＧＵＩコントロールの組が提供されてもよい。例えば、図のように、オーディオ入力信号を受信（例えば、マイクロホンまたは他のオーディオ入力ソースから）するため、オーディオ入力ファイルをロードするため、または受信したオーディオ信号またはファイルを楽曲構成要素へ分解するためのボタンが提供されてもよい。オーディオ入力は、２種類以上の入力を含んでもよい。例えば、旋律の部分は、ハミングされた、または歌われた曲を含んでもよいと考えられ、話し言葉の部分は話し言葉を含んでもよい。各部分を自動検出するよう、オーディオ入力には、各種類の間に部分セパレータが提供されるとよく、これは、例えば所定の言葉を含んでもよい。

楽譜入力７０８も同じく、異なるいくつかの方法で受信および処理可能である。考えられる様々な受信および処理の機能を盛り込むために、ＧＵＩコントロールの組が提供されてもよい。例えば、図のように、楽譜画像を受信するため（例えば、カメラ、スキャナ、またはその他のデジタル撮像デバイスから）、楽譜画像ファイルをロードするため、または受信した楽譜画像を楽曲構成要素へ分解するためのボタンが提供されてもよい。

いくつかの実施形態では、入力表示フレーム７２０が、受信および／または処理された入力に関する情報の表示用に提供される。入力表示フレーム７２０の特定の実施形態は、オーディオおよび／または楽譜の分解結果情報７２２、生および／または分解済みの楽曲構成要素表現ディスプレイ７２４、ならびに再生／視覚化／記録コントロール７２６を含む。

一実施形態では、オーディオ入力７０６が、検索者によってマイクロホンに向けて手で叩かれた、またはハミングされたリズムを記録することによって受信される。次に、オーディオ入力７０６は、リズムに関係する楽曲構成要素（例えば、音符開始（ｎｏｔｅ ｏｎｓｅｔ）および持続時間、休符、テンポなど）を抽出するために分解される。オーディオおよび／または楽譜の分解結果情報７２２領域に情報が提供され、オーディオ入力信号からのリズムの分解が成功したことを示す。生および／または分解済みの楽曲構成要素表現表示７２４領域において、分解された楽曲構成要素の説明図が、検索者に表示される。オーディオおよび／または楽譜の分解によってつくり出される楽曲構成要素の種類は、上に記載した。検索者は、オーディオおよび／または楽譜の分解結果情報７２２領域ならびに生および／または分解済みの楽曲構成要素表現表示７２４領域内の情報を使用して、検索エンジン７００が、ユーザの要望通りに記録および分解を行ったたかどうかを判断してもよい。

再生／視覚化／記録コントロール７２６は、再生、視覚化、記録、または、入力表示フレーム７２０に影響を与え得る他の側面を操作するための任意の有用なコントロールを含んでもよい。例えば、再生／視覚化／記録コントロール７２６は、再生／記録ボタン（例えば、記録、プレイ、一時停止、停止、早送り、挿入、重ね記録、トリミングなど）、再生／記録ボタンプログレスインジケータ（例えば、メモリインジケータ、経過時間インジケータ、位置インジケータなど）、視覚化コントロール（例えば、拡大表示およびパンニングコントロール、モード切り替えコントロール（例えば、楽譜表現モード、オーディオ信号／包絡線表現モード、ピアノロール表現モードなど）など）、および／またはその他任意の有用なコントロールを含んでもよい。

検索入力セクション７０２の実施形態は、入力セクションコントロールを含む。当然のことながら、多数の種類のコントロール（例えばスライダー、ノブ、スイッチ、ボタンなど）が、検索入力セクション７０２の多数の機能を制御するために提供されてもよい。いくつかの実施形態では、入力セクションコントロールは、設定ボタン７３０−１、リセットボタン７３０−２、修正ボタン７３０−３、および検索ボタン７３０−４などの入力コントロールボタン７３０の組を含む。

設定ボタン７３０−１は、検索入力セクション７０２の任意の数の設定を制御してもよい。いくつかの実施形態では、設定ボタンをクリックすると、設定メニューが現れて任意の数の設定へのアクセスを提供する。いくつかの設定は、ファイル管理（例えば、特定のファイルの種類を受け入れるよう、または特定のポートまたはコンポーネントからオーディオまたはビデオを受信するよう、検索エンジン７００を設定すること）、言語（例えば、特定のセマンティック形式（ｓｅｍａｎｔｉｃ ｆｏｒｍａｔ）のテキストを受け入れるよう検索エンジン７００を設定すること）などを含め、検索入力の受信に関係してもよい。その他の設定は、重み付けを設定すること（例えば、異なる検索入力を異なる形で重み付けするよう検索エンジン７００を設定することなど）、オーディオおよび楽譜分解を設定すること（例えば、最小クオンタイズ値を設定すること（例えば、音符の持続時間、ピッチの変動など）、特定の種類または組の楽曲構成要素のみを検出するよう検索エンジン７００を設定することなど）などを含め、受信した入力の処理に関係してもよい。

例えば、図７に示されている実例となる実施形態では、この設定は、検索エンジン７００をいくつかの形で設定してもよい。検索エンジン７００は、ワークステーションにおいてサウンドカードを介してオーディオ入力を受け取るよう設定されても、リズム楽曲構成要素のみを探すよう設定されても、特定の閾値音量（またはアタックレベル）を超えるオーディオのみを探すよう設定されても、さらにすべての音符および休符の音価すべてを最も近い８分音符にクオンタイズするよう設定されてもよい。検索エンジン７００はさらに、分解されたリズムをテキスト入力よりも大きく重み付けするよう設定されても（例えば、分解されたリズムがより重要な検索語として扱われるように）、さらにテンポキーワード入力を２番目に重要な検索語として重み付けするよう設定されてもよい。

リセットボタン７３０−２は、検索パラメータをリセットするよう構成されてもよい（例えば、デフォルト設定に戻るように、キーワードフィールドをクリアするように、重み付けをクリアするようになど）。修正ボタン７３０−３は、結果が返された後に検索を修正するよう設定されてもよい。例えば、より限定された結果を求めて結果の中を検索すること、他の検索入力に基づいて結果をフィルタにかけること、検索入力の全部または一部を変更すること、重み付けを修正することなどが望まれることもある。このように、検索結果のフィールドを次第に具体的に、または狭くしながら、ユーザは検索基準を連続または反復して入力することができる。検索ボタン７３０−４は、検索入力に基づいて検索パラメータを生成し、その検索パラメータを使用して、１つ以上のデータベースに対する検索を実行するよう設定されてもよい。

検索入力が受信され、キーワード、重みなどへと処理されると、それらは、検索パラメータの組を生成するために使用されてもよい。例えば、フラットファイルデータベースを検索するためのＳＱＬクエリに変換されてもよい。検索パラメータの組は、場合によっては検索されるデータベースの種類および／またはデータベースに格納されているデータの種類に応じて、有用な任意の方法で形式を合わせ、または生成されてもよい。

いくつかの実施形態では、データベースは、生のオーディオおよび／または楽譜ファイル（または生のオーディオファイルへのポインタ）を格納し、そのファイルは「オンザフライ」で分解されてもよい（例えば、検索のとき、またはその前後に）。他の実施形態では、データベースはオーディオファイルに関するメタデータ（例えば、オーディオファイルから分解されたもの、オーディオファイル内のメタデータから抽出されたもの、手動で入力されたもの、他の何らかのシステムにより生成されたものなど）を格納する。さらに他の実施形態では、データベースは、楽曲ベースの検索のために複数の方法で使用され得る複数の種類のファイルを格納する。

様々な実施形態において、データは、その、データベース上での格納されている状態において、事前フィルタ処理にかけられているか、または他の方法で前処理されている。一実施形態では、ある所定種類の楽曲構成要素が、可能性の高い検索候補であると判断されて事前分解されてもよい。例えば、検索者が、特定のテンポの曲を検索する傾向にあると仮定する。テンポは、一種の事前分類または事前フィルタリングプロセスとして、ファイルから事前分解されてもよい。特定の実施形態では、事前分解は、最終的な分解とは異なるレベル（例えば分解能）で実行されてもよい。例えば、特定のメロディラインを有する曲を検索するには、まず、曲のピッチ輪郭の粗い分解を行い、考えられる一致候補リストの範囲を狭めることが可能なこともある。その結果、さらに徹底的な分解は、その限られた候補リストのみに対して、より正確に一致を判断するために実行されてもよい。他の実施形態では、ファイルに関するメタデータまたは他の情報（例えば、ジャンル、作者、楽器のリストなど）が、データを事前フィルタ処理にかけるため、または事前分類するために使用されてもよい。例えば、特定のジャンルの曲すべてが事前分類されてもよい。すなわち、曲は「速い」または「遅い」と事前分類されてもよい。こうした方法、またはこの他の方法では、システムリソースの保護、検索時間の短縮、結果の改善のため、および他の理由で、多層の前処理が使用されてもよい。

検索結果は、読み出されると、本発明によるいくつかの異なる形で扱うことができる。いくつかの実施形態では、検索結果が順位付けされる。当然のことながら、多様な結果の順位付けがあり、そのための処理も多数あり得る。いくつかの順位付けは、特定の候補が、検索入力にどの程度厳密に一致するかに関係する。他の順位付けはさらに、検索者によって提供される様々な重み付けおよびその他のプリファレンスを考慮に入れる。さらに他の順位付けは、１つ以上の信頼値（例えば、様々なコスト関数によって生じるエラー値）を考慮に入れる。信頼値の１つの種類は、楽曲構成要素の分解に関係して、分解が正しい結果をもたらした可能性を表してもよい（例えば、外れ値またはわずかな表現の変動を含む様々な理由によって、テンポは９６％の信頼度で９０ｂｐｍと判断されることもある）。当然、分解は、検索入力の分解および／または読み出されたデータ（例えば、データベースに格納されているデータ）の分解に関係すればよい。別の種類の信頼値は、検索の信頼度に関係してもよい。例えば、検索入力として使用されるメロディラインは、データベースから読み出されたメロディラインに、９９％の信頼度で一致することもある（例えば、読み出されたメロディの少数の音符が、入力されたメロディと正確に一致しない）。

次に、結果（例えば順位付けされた結果）が、ＧＵＩ７００の検索結果セクション７５０に表示されてもよい。検索結果セクション７５０は、結果表示および結果セクションの制御に関するいくつかのＧＵＩ構成要素を含む。多数の種類の結果表示が考えられるが、図７は、結果リスト表示領域７６０および結果詳細表示領域７７０を示す。

結果リスト表示領域７６０は、１つ以上のデータベースから読み出された結果のリストを表示するよう構成されている。いくつかの実施形態では、結果リスト表示領域は、ウィンドウコントロールを含む。例えば、結果リスト表示領域は、検索者がより簡単に結果をスクロールできるようにするスクロールバー７６２を、下部および側方に含んでもよい。

図に示すように、結果リスト表示領域は、「‘ＴＥＭＰＯ（９０−１００）＆ ＧＥＮＲＥ（ｊａｚｚ ｏｒ ｂｌｕｅｓ）＆ ＳＴＡＲＴＫＥＹ（Ｄ−ｍｉｎｏｒ）＆ ＡＵＤＩＯ＿ＩＮＰＵＴ（ＤＥＣＯＮＳＴＲＵＣＴ（ｒｈｙｔｈｍ））’の検索結果（２３８中）１〜２０を表示」のように、検索結果全体に関する情報を含んでもよい。この種類の情報は、現在のリストが、検索入力セクション７０２に提供された実例となる検索入力に応答して、データベースから読み出された合計２３８の結果の中から最初の２０の結果を表示していることを検索者に示してもよい。結果リスト領域はさらに、順位付けリストの表示を含んでもよい（例えば、チャートとして）。そのチャートは、例えば、曲のタイトル、アーティスト、信頼値などを含む、結果についての上位情報（ｈｉｇｈ−ｌｅｖｅｌ ｉｎｆｏｒｍａｔｉｏｎ）を含んでもよい。

示されている例では、読み出された第２の結果７６４は、Ｅｄ Ｗａｓｈｉｎｇｔｏｎによる「Ｗａｌｋｉｎｇ ｉｎ Ｄａｒｋｎｅｓｓ」という題の曲である。なお、示されている結果は、つくりもののデータで構成されており、決して実在する楽曲作品を指すことも、アーティストを指すことも目的としてはいない。信頼値は、「９７％（９９％／９９％／９７％／９２％）」と表示されている。これは、重み付けされた９７％という総信頼値に対して、オーディオ検索入力から分解されたテンポに関しては９９％の信頼度、ジャンルに関しては９９％の信頼度、開始調に関しては９７％の信頼度、およびリズムに関しては９２％の信頼度が検索により返されたということを表すと考えられる。場合によっては、様々な理由から、検索者に、検索に含まれている一部または全部の信頼値を提示することが望ましいと考えられる。例えば、検索者は、１つの結果が全体では比較的高い信頼値を有するかもしれないが、１つのパラメータが検索入力から大幅に逸脱したということを知りたいこともある。これによって、検索者は、さらに調整された結果が読み出されるよう、後からの検索をより効果的に修正することができると考えられる。

結果詳細表示領域７７０は、特定の結果の詳細に関係する、任意の数の異なる種類のデータを決定するよう構成されてもよい。一実施形態では、選択された結果に関連するオーディオの様々な表現が表示される。例えば、楽譜表現、オーディオ信号表現、ピアノロール表現、またはその他任意の有用な表現が表示されてもよい。別の実施形態では、結果リスト表示領域７６０に提供されるものと同じテキスト情報または他のテキスト情報が提供されてもよい（例えば、より大きなフォントを使用する、さらなる詳細を提供する、その曲のアルバムカバーからのカバーアートの画像を提供する、その曲を購入するための、またはそのバンドのウェブサイトを訪問するためのハイパーリンクを提供するなど）。いくつかの実施形態では、結果詳細表示領域７７０は、再生／視覚化／記録コントロール７７４（例えば、入力表示フレーム７２０の実施形態で提供される再生／視覚化／記録コントロール７２６に類似している）を含む。

検索結果セクション７５０の実施形態は、結果セクションコントロールを含む。当然のことながら、多数の種類のコントロール（例えば、スライダー、ノブ、スイッチ、ボタンなど）が、検索結果セクション７５０の多数の機能を制御するために提供されてもよい。いくつかの実施形態では、結果セクションコントロールは、設定ボタン７８０−１、前ボタン７８０−２、次ボタン７８０−３、および出力ボタン７８０−４などの結果コントロールボタン７８０の組を含む。

設定ボタン７８０−１は、検索結果セクション７０２の任意の数の設定を制御してもよい。いくつかの実施形態では、設定ボタンをクリックすると、設定メニューが現れて任意の数の設定へのアクセスを提供する。いくつかの設定は、結果の受け取り方（例えば、結果の最大数、順位付けの種類など）、結果の表示法（例えば、結果リスト表示領域７６０に何の欄が表示されるか、結果詳細表示領域７７０にどの表現またはテキストが示されるかなど）に関係してもよい。

前ボタン７８０−２および次ボタン７８０−３は、それぞれ、結果リスト内の前の結果または次の結果へジャンプするよう設定されてもよい。当然、他のナビゲーションコントロールも可能であると考えられる（例えば、次のページ、分類、フィルタなど）。出力ボタン７８０−４は、１つ以上の方法で検索結果データを出力するよう構成されてもよい。いくつかの実施形態では、出力は、図１の出力生成ユニット１４０によって生成されてもよい。当然のことながら、異なる多数の種類のデータの、多数の種類の出力が考えられる。例えば、結果データは、生のオーディオデータ（例えば、スピーカ、メディア再生デバイス、サウンドカードなどを介してプレイされるよう構成された信号）、符号化オーディオデータ（例えば、ストレージ媒体（例えば、コンパクトディスク）上での格納用、メディア再生ソフトウェアによる再生用、ネットワーク経由での共有用など）、楽譜表現データ（例えば、楽譜画像、楽譜作成および／または編集ソフトウェアに対応した楽曲構成要素など）、テキストデータ（例えば、ファイル、プリントアウトなどとして格納される、結果リストもしくは結果詳細に関係するテキスト）、またはその他任意の有用な情報として出力されてもよい。さらに、出力は、検索入力、検索履歴、検索統計、データベース統計、設定などのログまたは記録を含んでもよい。

いくつかの実施形態では、検索エンジン７００は共同環境へ統合される（例えば、インターネット経由で）。その結果、この検索エンジンは、共同環境を生かす多数の方法で使用されればよく、または逆も同様である。例えば、検索入力および／または結果は、ネットワーク上で他者と共有されてもよい。一実施形態では、ユーザは、検索パターンが似ている他のユーザを検索してもよく、またはユーザは、自らの経験に基づいて特定の検索結果を勧めてもよい。例えば、「Ｘ」の検索を実行した後に、検索エンジン７００は、「‘Ｘ’を検索したユーザは‘Ｙ’にも関心があるかもしれない」と通知してもよい。この種類および同様の種類の結果は、他のユーザ、検索傾向およびパターンを判断するインテリジェントアルゴリズム、広告主、またはその他任意のデバイス、個人もしくは団体によって生成されてもよい。

（例示的実装）
上述のシステムおよび方法は、いくつかの形で実装することができる。そのような実装の１つは、様々な電子コンポーネントを含む。例えば、様々なシステムのユニットが、個別または集合的に、ハードウェアに適用可能な機能の一部または全部を実行するようになっている１つ以上の特定用途向け集積回路（ＡＳＩＣ：Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）を用いて実装されてもよい。あるいは、各機能は、１つ以上の集積回路上の、他の１つ以上の処理ユニット（またはコア）によって実行されてもよい。他の実施形態では、他の種類の集積回路が使用されてもよく（例えば、構造化／プラットフォームＡＳＩＣ、フィールドプログラマブルゲートアレイ（ＦＰＧＡ：Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）、およびその他のセミカスタムＩＣ）、これは、当技術分野で既知の任意の方法でプログラムされてもよい。各ユニットの機能はさらに、全体的または部分的に、１つ以上の汎用または特定用途向け処理装置によって実行されるよう形式を合わせた、メモリに記録された命令を用いて実装されてもよい。

図８は、本発明の特定の実施形態を実装する計算システム８００のブロック図を示す。一実施形態では、計算システム８００は、図１に示されているポータル１６０としての機能を果たしてもよい。なお、図８は、様々なコンポーネントの一般化した説明を提供することのみを意図しており、このコンポーネントのいずれかまたはすべてが、必要に応じて利用されてもよい。したがって、図８は、個々のシステム構成要素が、相対的に別々となった形、または相対的により統合された形で、どのように実装され得るかを、広く示す。

バス８２６を介して電気的に結合可能な（または、必要に応じて別の方法で通信してもよい）複数のハードウェア構成要素を含む計算システム８００が示されている。ハードウェア構成要素は、１つ以上の汎用処理装置および／または１つ以上の専用処理装置（デジタル信号処理チップ、グラフィックス加速チップ、および／または同様のものなど）を含むがこれに限定されるものではない、１つ以上の処理装置８０２と、マウス、キーボードおよび／または同様のものを含むことができるがこれに限定されるものではない、１つ以上の入力装置８０４と、ディスプレイ装置、プリンタおよび／または同様のものを含むことができるがこれに限定されるものではない、１つ以上の出力装置８０６とを含むことができる。

計算システム８００はさらに、１つ以上のストレージ装置８０８を含む（および／またはそれと通信している）とよく、これは、ローカルのおよび／またはネットワークアクセス可能なストレージを含むことができるがこれに限定はされず、および／または、ディスクドライブ、ドライブアレイ、光学式ストレージ装置、ランダムアクセスメモリ（「ＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）」）などのソリッドステートストレージ装置、および／または読み取り専用メモリ（「ＲＯＭ（ｒｅａｄ−ｏｎｌｙ ｍｅｍｏｒｙ）」）を含むことができるがこれに限定されず、これは、プログラマブル、フラッシュアップデート可能、および／または同様のものとすることができる。計算システム８００はさらに、通信サブシステム８１４を含んでもよく、通信サブシステム１０１４は、モデム、ネットワークカード（無線または有線）、赤外線通信装置、無線通信装置および／またはチップ組（Ｂｌｕｅｔｏｏｔｈ装置、８０２．１１装置、ＷｉＦｉ装置、ＷｉＭａｘ装置、セルラー通信機器など）および／または同様のものを含むことができるが、限定されるものではない。通信サブシステム８１４は、ネットワーク（一例を挙げると、以下に記載されているネットワークなど）および／または本願明細書に記載される他の任意の装置とのデータ交換を可能にしてもよい。多数の実施形態において、計算システム８００はさらに、ワーキングメモリ８１８を含み、これは、上記のようにＲＡＭまたはＲＯＭ装置を含むことができる。

計算システム８００は、さらに、オペレーティングシステム８２４および／または１つ以上のアプリケーションプログラム８２２などの他のコードを含めて、現在ワーキングメモリ８１８内にあるものとして示されているソフトウェア構成要素を含んでもよく、これは、本発明のコンピュータプログラムを含んでもよく、および／または本願明細書に記載されているように本発明の方法の実装、および／または本発明のシステムの構成を行うよう設計されてもよい。単なる一例として、上記で説明された方法（単数または複数）に関して記載された１つ以上の手順は、コンピュータ（および／またはコンピュータ内の処理装置）によって実行可能なコードおよび／または命令として実装することもできるであろう。一実施形態では、図１のオーディオおよび／または楽譜分解ユニット１２０、ならびにその他の様々なクライアント側の方法は、計算システム８００によって読み取り可能なアプリケーションプログラム８２２として実装される。

こうした命令および／またはコードの組は、コンピュータ読み取り可能ストレージ媒体８１０ｂ上に格納されてもよいであろう。いくつかの実施形態では、コンピュータ読み取り可能ストレージ媒体８１０ｂは、上述のストレージ装置（単数または複数）８０８である。他の実施形態では、コンピュータ読み取り可能ストレージ媒体８１０ｂは、コンピュータシステム内に組み込まれていてもよいであろう。さらに他の実施形態では、コンピュータ読み取り可能ストレージ媒体８１０ｂは、コンピュータシステムから分離していても（すなわち、コンパクトディスクなどの取り外し可能媒体など）、およびまたは、ストレージ媒体に格納されている命令／コードを用いて汎用コンピュータをプログラムするためにストレージ媒体を使用できるよう、インストールパッケージにおいて提供されてもよいであろう。こうした命令は、計算システム８００によって実行可能な実行コードという形をとっても、および／または、ソースおよび／またはインストール可能コードという形をとてもよいであろう。ソースおよび／またはインストール可能コードは、計算システム８００上でコンパイルおよび／またはインストールされると（例えば、一般に利用可能な様々なコンパイラ、インストールプログラム、圧縮／解凍ユーティリティなどのうちのいずれかを使用して）、その結果実行コードという形をとる。こうした実施形態では、コンピュータ読み取り可能ストレージ媒体８１０ｂは、コンピュータ読み取り可能ストレージ媒体読み取り機８１０ａによって読み取られてもよい。

当業者には当然のことながら、特有の要件に従って、多くの変形物がつくられてもよい。例えば、カスタマイズされたハードウェアがさらに使用されること、および／または特定の構成要素がハードウェア、ソフトウェア（アプレイットなどの高移植性ソフトウェアなどを含む）もしくは両方に実装されることが可能であろう。さらに、ネットワーク入力／出力装置などの他のコンピューティング・デイバスへの接続が用いられてもよい。

いくつかの実施形態では、入力装置８０４のうちの１つ以上は、オーディオインターフェース８３０−１と結合してもよい。オーディオインターフェース８３０−１は、マイクロホン、楽器、デジタルオーディオ装置、または他のオーディオ信号もしくはファイルのソースと、例えば物理的、光学的、電磁的などの形で、インターフェースで接続することによって、楽曲寄与１０２−１を受信するよう構成されてもよい。他の実施形態では、入力装置８０４のうちの１つ以上は、楽譜インターフェース８３０−２と結合してもよい。楽譜インターフェース８３０−２は、カメラ、スキャナ、デジタル撮像装置、またはその他のデジタル画像ソースとインターフェースで接続することによって、楽譜寄与１０２−２を受信するよう構成されてもよい。

さらに、いくつかの実施形態では、出力装置８０６のうちの１つ以上は、オーディオ出力装置１０６−１と結合してもよい。オーディオ出力装置１０６−１は、本発明の実施形態によって生成されたオーディオ信号データを、例えばスピーカ、オーディオコンポーネント、デジタル−アナログ変換器、コンパクトディスクライターなど、そのデータを処理する能力がある１つ以上のシステムまたは装置に出力するよう構成されてもよい。他の実施形態では、出力装置８０６のうちの１つ以上は、楽譜出力装置１０６−２と結合してもよい。楽譜出力装置１０６−２は、本発明の実施形態によって生成された楽譜表現データを、例えば楽譜書き起こしソフトウェア、楽譜公開システム、ファイルストレージ装置など、そのデータを処理する能力がある１つ以上のシステムまたは装置に出力するよう構成されてもよい。

一実施形態では、本発明は、本発明の方法を実行するためにコンピュータシステム（計算システム８００など）を用いる。実施形態の組によれば、処理装置８０２が、ワーキングメモリ８１８に含まれている１つ以上の命令の１つ以上のシーケンス（オペレーティングシステム８２４および／またはアプリケーションプログラム８２２などのその他のコードに組み込まれることも可能と考えられる）を実行するのに応答して、当該方法の手順の一部または全部が計算システム８００によって実行される。当該の命令は、ストレージ装置（単数または複数）８０８（または８１０）のうちの１つ以上など、別の機械読み取り可能媒体からワーキングメモリ８１８に読み込まれてもよい。単なる一例として、ワーキングメモリ８１８に含まれている命令のシーケンスの実行は、処理装置（単数または複数）８０２に、本願明細書に記載されている方法の１つ以上の手順を実行させてもよいであろう。

本願明細書で使用される「機械読み取り可能媒体」および「コンピュータ読み取り可能媒体」という用語は、機械を特定の形で動作させるデータの提供に関与する任意の媒体を指す。計算システム８００を使用して実装される実施形態では、様々な機械読み取り可能媒体が、命令／コードを実行用に処理装置（単数または複数）８０２に提供するのに関与すること、および／またはそのような命令／コードを（例えば信号として）格納および／または搬送するために使用されることが可能であろう。多数の実装において、コンピュータ読み取り可能媒体は、物理的および／または有形のストレージ媒体である。そのような媒体は、次に限定されるものではないが、不揮発性媒体、揮発性媒体および伝送媒体を含む多数の形態をとり得る。不揮発性媒体は、例えば、ストレージ装置（単数または複数）（１６０８または８１０）などの光ディスクまたは磁気ディスクを含む。揮発性媒体は、ワーキングメモリ８１８などのダイナミックメモリを含むがこれに限定されるものではない。伝送媒体は、バス８２６を構成するワイヤーを含めて、同軸ケーブル、銅線、光ファイバ、ならびに、通信サブシステム８１４の様々なコンポーネント（および／または通信サブシステム８１４が他の装置との通信を提供するのに用いる媒体）を含む。したがって、伝送媒体はさらに、波（電波通信および赤外線データ通信中に生成されるものなど、電波、音波、および／または光波を含むがこれに限定されるものではない）という形態をとることができる。

物理的および／または有形のコンピュータ読み取り可能媒体の一般的形態には、例えば、ｆｌｏｐｐｙ ｄｉｓｋ（登録商標）、フレキシブルディスク、ハードディスク、磁気テープもしくはその他任意の磁気媒体、ＣＤ−ＲＯＭ、その他任意の光学媒体、パンチカード、紙テープ、穴のパターンを有するその他任意の物理的媒体、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、その他任意のメモリチップもしくはメモリカートリッジ、以下に記載される搬送波、またはコンピュータが命令および／またはコードを読み取ることができるその他任意の媒体が含まれる。

様々な形式の機械読み取り可能媒体が、１つ以上の命令の１つ以上のシーケンスを、実行用に処理装置（単数または複数）８０２へ搬送するのに関与してよい。単なる一例として、この命令は、最初にリモートコンピュータの磁気ディスクおよび／または光ディスク上で搬送されてもよい。リモートコンピュータは、命令をダイナミックメモリにロードして、その命令を信号として、計算システム８００によって受信および／または実行される伝送媒体上で送信することもできるであろう。こうした信号は、電磁信号、音響信号、光信号および／または同様のものという形態であってもよいと考えられ、すべて、本発明の様々な実施形態に従って、命令が符号化されることが可能な搬送波の例である。

通信サブシステム８１４（および／またはそのコンポーネント）は、通常、この信号を受信することになり、続いてバス８２６がこの信号（および／またはこの信号により搬送されるデータ、命令など）を、ワーキングメモリ８１８へ搬送してもよいであろう。処理装置（単数または複数）８０２は、このワーキングメモリ８１８から命令を読み出して実行する。ワーキングメモリ８１８によって受信された命令は、任意選択で、処理装置（単数または複数）８０２による実行の前または後に、ストレージ装置８０８上に格納されてもよい。

当然のことながら、本発明によれば、システムの多数の実装が可能であり、それは、図８に関して記載されるコンポーネントまたは機能を組み込んでも組み込まなくてもよい。いくつかの実施形態では、システムは専用装置として実装される。この装置は、音圧を検知してそれをシステムが使用する検索入力へ変換するよう構成された、１つ以上の内蔵マイクロホンを含んでもよい。代わりに、この装置は、外付けマイクロホン、媒体装置、データ記憶装置、またはその他のオーディオソースとインターフェースで接続するための１つ以上の楽曲入力ポートを含んでもよい。こうした実施形態のうちのいくつかでは、装置は、ハンドヘルドまたは携帯用装置であってもよい。他の実施形態では、このシステムは、多目的または汎用の装置において実装されてもよい（例えば、コンピュータによって実行されるようコンピュータ読み取り可能媒体上に格納されたソフトウェアモジュールとして）。こうした実施形態のいくつかでは、オーディオソースは、サウンドカード、外付けマイクロホン、または格納済みのオーディオファイルであってもよい。その結果、入力が生成されシステムに提供される。

このシステムの他の実施形態は、聴音装置として動作する簡略化バージョンまたはモノラルバージョンとして実装されてもよく、これは、１つのマイクロホンに向かって楽器をプレイするユーザ、または特定の曲またはメロディまたはその一部を歌うユーザから、オーディオを受信する。単一マイクロホンの構成では、このシステムは続いて、１つのマイクロホンから記録された楽曲を対応する楽曲楽譜に変換する。これは、話し言葉および文章をコンピュータ読み取り可能テキストに変換するテキストトゥスピーチソフトウェアの音楽的な等価物を提供してもよい。サウンド−音符変換として、曲またはメロディが、１つの楽器がプレイしているかのように登録されることになる。

当然のことながら、このシステムの他の実装はさらに、ユーザおよび他のシステムとの相性に関係して、他の種類のインターフェースおよび機能を含んでよい。例えば、入力ポートが、回線レベル入力（例えば、ステレオシステムまたはギターアンプから）、マイクロホン入力、ネットワーク入力（例えばインターネットから）、またはその他のデジタルオーディオコンポーネント用に提供されてもよい。同じく、出力ポートも、スピーカ、オーディオコンポーネント、コンピュータおよびネットワークなどへの出力のために提供されてもよい。さらに、いくつかの実装では、システムは、ユーザ入力（例えば、物理的または仮想のキーパッド、スライダー、ノブ、スイッチなど）および／またはユーザ出力（例えば、ディスプレイ、スピーカなど）を提供してもよい。例えば、インターフェース能力が提供されて、記録、またはシステムによってその記録から抽出されたデータを、ユーザが聴くことができるようにしてもよい。

一実施形態では、本発明の機能は、デジタルコンピュータにインストール可能なアプリケーションを含むソフトウェアにおいて実装される。このソフトウェア実装は、演奏者に入力および出力インターフェースを提供することが好ましい。すなわち、このソフトウェアがインストールされているホストコンピュータは、典型的には、演奏者が、歌うため、または演奏者の楽器をプレイするために読むことができる楽曲楽譜の視覚的表現をもたらすディスプレイを含む。このコンピュータはさらに、典型的には、演奏者のセッションを記録するためのマイクロホンなどの入力インターフェースを含み、記録済みのパフォーマンスを演奏者が聴けるように、スピーカなどの出力インターフェースを含む。このコンピュータ実装は、画像キャプチャを含むことができ、譜表上の音符を含む楽曲楽譜が、光学入力手段によってデジタル化され、続いてこのコンピュータに入力されることが可能である。デジタル化された楽曲楽譜は、ＯＣＲ技術によって解釈することができ、結果として生じる解釈後のデータは、楽譜の合成オーディオ演奏をもたらすよう処理される。これには、適切な場合は、言葉と適切なピッチとを一致させる合成ボーカル演奏が含まれ、その結果オーディオ演奏は、楽譜の視覚的表現と同期される。以下に提供されるさらなる詳細な説明では、コンピュータソフトウェア実装は、「レベルＸ」実装と呼ばれるか、または「ｅＭｕｓｅ Ｘ」製品と呼ばれる（「ｅＭｕｓｅ」という名前は、本発明のあらゆる権利の譲受人、Ｐｒｉｎｃｅｔｏｎ，Ｎｅｗ Ｊｅｒｓｅｙ，ＵＳＡのＭｕｓｅＡｍｉ，Ｉｎｃ．の製品実施形態を指す）。

別の実施形態では、本発明の機能は、ディスプレイ、入力インターフェース、オーディオおよび視覚出力インターフェース、ならびにＯＣＲ画像解釈インターフェースを含むことができるハンドヘルド装置において記録される。このハンドヘルド装置実装は、各種の便利なユーザコントロールノブと、装置機能の便利なナビゲーションのための機構とを含む。ディスプレイは、ユーザによる機能選択のためのメニューオプションの視覚的表現をサポートする。

以下でさらに記載されるように、コンピューティング装置は、外部ソースから楽曲楽譜データを受信し、続いてその楽曲楽譜データの合成オーディオ演奏と、楽曲楽譜の同期された視覚的表現とをもたらすことによって、楽曲楽譜データを解釈および処理する。

外部ソースは、楽曲楽譜データをネットワーク接続経由でコンピューティング装置に提供する、ネットワークデータソースで構成されることが可能である。ネットワーク接続は、コンピューティング装置と、ネットワークとの間の、無線接続による通信で構成されることが可能である。

楽曲楽譜データは、記録済み媒体を取り込んでその記録済み媒体から楽曲楽譜データを取得するコンピューティング装置の読み取り機に、記録済み媒体を取り込むことによって、記録済み媒体から読み取られることが可能である。記録済み媒体は、合成楽曲制作のＭＩＤＩ規格に従った合成オーディオ演奏向けの、十分なデータを含む。すなわち、コンピューティング装置は、楽曲楽譜を特定するデータを受信することができ、選択されたテンポ、音色、音部記号、調号、拍子記号および同様のもので、対応する楽音を生成または合成することができる。記録済み媒体は、フラッシュメモリ装置を含むことができる。

コンピューティング装置には、楽曲楽譜のユーザパフォーマンスを記録して、その記録されたユーザパフォーマンスの再生を提供する能力を提供することができる。ユーザパフォーマンスの再生は、合成楽曲楽譜演奏とは独立して生じること、または同時に生じることが可能である。さらに、ユーザパフォーマンスの再生は、記録済みのユーザパフォーマンスに対応する音符の視覚表現と共に提供されることが可能である。このようにして、「聴音」機能が提供される。

１つの代案では、合成オーディオ演奏と、楽曲楽譜の同期された視覚的表現との両方を生成するために装置によって使用される楽曲楽譜データは、楽曲楽譜のデジタル画像を光学的に取り込み、続いてそのデジタル情報を解釈および処理して、適切な音符を表すデータの集合をつくり出し、そうして楽曲楽譜に対応するデータを生成する装置によって取得されてもよい。

さらに、楽曲楽譜データの合成オーディオ演奏の特性を決定する楽曲文脈情報が提供されることが可能であり、そのすべてがユーザによって調節されてもよい。当該の楽曲文脈情報は、複数の調号、拍子記号音色、テンポ、および、レガート、クレッシェンド、リタルダンドなどの表現用語を含むことができる。

別の代案では、楽曲楽譜データのオーディオ再生と、音符の視覚的表現とを作り出すことは、ネットワークデータソースと通信することで達成される。必要に応じて、ネットワークデータソースは、楽曲楽譜データをコンピューティング装置に提供する。さらに別の代案では、ネットワークデータソースは、コンピューティング装置に、楽曲楽譜データの合成オーディオ演奏の楽曲特性を決定する楽曲文脈情報を提供することができる。さらに、ネットワークデータソースは、楽曲文脈情報を無線接続によって提供することができる。

１つの代案では、楽曲楽譜データの合成オーディオ演奏と、楽曲楽譜の同期された視覚的表現とを作り出すことは、コンピューティング装置の読み取り機に記録済み媒体を挿入することによって達成される。必要に応じて、コンピューティング装置は、記録済み媒体から楽曲楽譜データを取得する。さらに、記録済み媒体は、楽曲楽譜データの合成オーディオ演奏の楽曲特性を決定する楽曲文脈情報も、コンピューティング装置に提供することができる。

１つのオプション機能は、楽曲楽譜の、ユーザの楽器および／またはボーカルパフォーマンスの記録を提供することである。別の代案は、ＭＩＤＩ規格に従って合成オーディオ演奏を作り出すことである。さらに、視覚的表現を作り出すことは、対応する合成オーディオ演奏と同期された楽曲楽譜を表示することから成ってもよい。別のオプションは、楽曲楽譜データの視覚的表現と、オーディオ演奏との両方、および、記録済みユーザパフォーマンスのオーディオコンポーネントと、ユーザパフォーマンスによって生成された楽曲楽譜の同期された対応する視覚表示との両方の再生という、同期化された同時再生を提供することである。

本発明に従って、コンピューティング装置は、楽曲楽譜を光学的にデジタル方式で取り込み、デジタル画像を解釈して、このデジタル方式で取り込まれた楽曲楽譜に対応する楽曲楽譜データをコンピューティング装置用に生成し、楽曲楽譜データの合成オーディオ演奏と、楽曲楽譜の同期された視覚的表現とを作り出すことができる。コンピューティング装置は、楽曲楽譜データの合成オーディオ演奏の楽曲特性を決定するためにこのコンピューティング装置によって使用される、楽曲文脈情報を受信することができる。上述の代わりの実施形態と同様に、楽曲文脈情報は、複数の調号、拍子記号音色、テンポ、および、レガート、クレッシェンド、リタルダンドなどの表現用語などを含むことができる。これらは、ユーザによって、楽曲楽譜データの合成オーディオ演奏の楽曲特性を決定するために選択されることが可能である。オプションとして、コンピューティング装置は、光学的にデジタル方式で取り込まれた楽曲楽譜から楽曲文脈情報を特定し、さらに任意選択で、ネットワークデータソースから楽曲文脈情報を取得することができる。必要に応じて、ネットワークデータソースは、このコンピューティング装置との無線接続によって楽曲文脈情報を提供する。

コンピューティング装置には、合成演奏および／またはユーザによって記録されたパフォーマンスのオーディオ再生用に、この装置所有のラウドスピーカが提供されることが可能である。さらに、この装置は、ヘッドホンまたは外付けラウドスピーカまたは同様のものに接続するための出力ジャックを含むことができ、さらに、装置がオーディオパフォーマンスを無線サウンド再生システム（無線コンポーネント対応となっているホームステレオシステムなど）に伝送できるようにする無線伝送能力が提供されることも可能である。装置は、所定の長さの楽曲楽節を格納可能にするのに十分なコンピューティングメモリを有する。

以下のさらなる詳細な説明は、ハンドヘルド装置実装における機能の様々な実装を参照するが、それぞれ、「レベル１」および「レベル２」または「ｅＭｕｓｅ１」および「ｅＭｕｓｅ２」と呼ばれる。

以下の説明では、一連のデジタルコンピューティング装置にインストール可能な楽曲再生ソフトウェアについて記載し、さらに、ハンドヘルドシートミュージック読み取り装置の実施形態についても記載する。本願明細書において、これらは集合的にｅＭｕｓｅ製品と呼ばれる。

図９は、ハンドヘルドの電池式「簡単処理」コンシューマ電子装置９００として、製品の実例となる実施形態を示す。この装置は、シートミュージックから、選択された楽曲楽節の画像を、数小節またはページ全体でさえも取り込み、その楽節をデジタル方式で形式設定して符号化し、続いてその選択された楽節をプレイするが、これはすべてリアルタイムで事実上瞬時に行われる。再生サウンドは楽器特有であり、ユーザによって選択された音色（例えば、ピアノ、バイオリン、フルートなどのサウンド）でプレイする。複数の音色を同時にプレイ可能である。装置９００は、調号、拍子、音量およびテンポなどの楽曲の変化を認識し、フォルテ、ピアノ、クレス（ｃｒｅｓｓ．）、レガートおよび同様のものなど、音楽の平凡な用語を考慮するよう設計されている。ＬＣＤ画面９０２は、楽曲楽節９０４を、それを装置が再生しているときに表示し、プレイされる音符はそれぞれ、残りの楽曲楽譜のからその音符を区別するよう、他と異なる色で強調表示される。

図９の装置９００は、デジタル「音楽カード」機能を組み入れており、これは、１つ以上の記録済みまたはダウンロード済みの楽曲作品を用いて符号化されたデータカード（図示せず）の挿入をサポートし、特定の小節を迅速に参照できるようにする。データカードは、典型的にセルラー電話およびデジタルカメラによって使用されるものなどの記録可能媒体を含むことができる。データカードは、装置９００のカードスロット９０６に収容される。装置９００はさらに、符号化された楽曲作品を表すデジタルデータを処理する。ダウンロード済みのファイルは、装置のメモリ内に保存することもできる。符号化された楽曲作品は、豊かなリスニング体験を提供し、楽曲楽譜の特定の小節を迅速に参照できるようにする。

装置９００の記録／再生機能は、ユーザが、記録されたパフォーマンスを、楽曲楽譜を基準として直ちに評価できるようにする。すなわち、装置９００は、楽曲作品のユーザのパフォーマンスを記録して、そのユーザのパフォーマンスを、受信済みの楽曲作品の再生と共に（すなわち同時に）再生することができる。ユーザパフォーマンスの再生は、「聴音」機能を提供する、対応する視覚的表現と共に提供されことが可能である。メトロノームおよび楽曲の音程チューナーの両方の能力も、この装置に組み込まれ、さらに装置は、「ミュージックマイナスワン」機能向けに調節されることが可能である。「ミュージックマイナスワン」機能は、複数譜表または複数パートの楽曲作品で、ユーザが、その作品のどのパート（単数または複数）をＭＩＤＩインターフェースによって再生するかを決定できるようにする。これによって、ユーザは、装置に合わせて特定のパートをプレイすること／歌うことができるようになる。

図９は、蓋または上部９０８の下面に組み込まれたＬＣＤ画面９０２を有する押し上げ式の蓋９０８を備えた、ハンドヘルド装置としての装置９００を示す。装置はさらに、楽曲再生用のスピーカ９１０（図９にはステレオペアが示されている）と、ユーザパフォーマンスを記録するためのマイクロホン９１２とを内蔵している。画像キャプチャ能力は、図９に示されているように実装可能である。押し上げ式の蓋９０８がカメラシステムを含み、カメラシステムは、押し上げ式の蓋９０８の外側表面に取り付けられた光学レンズを含み、画像キャプチャを目的としてレンズシャッターボタン９１４によってトリガされる。音量９１６、再生テンポ９１８、メニューナビゲーション９２０、および位置９２２の調節用サムホイールとして示されている、様々なユーザインターフェースコントロールが提供される。装置９００には、ネットワークまたは他の装置とより容易に接続できるよう、ＵＳＢポート９２４が提供されることが可能である。オン／オフスイッチ９２５は、装置９００をオン・オフする。

図９に示されているように、楽曲楽譜の演奏（合成パフォーマンス）およびユーザのパフォーマンスの再生を含む機能の制御用に複数のコントロールボタンも提供されている。図９は、プレイ／一時停止９２６、停止９２８、次／リセット９３０、および記録９３２という機能用の例示的コントロールボタンを示す。図９は、タイミングインジケータを示し再生テンポ９１８と関連があるメトロノーム表示ディスプレイ９３４も示す。メトロノーム機能、および装置９００のその他の機能の選択は、メニューサムホイール９２０および／または位置サムホイール９２２の処理と併せて、ＬＣＤ画面９０２のメニューナビゲーションを用いて遂行される。選択は、次／リセットコントロールボタン９３０の処理によって実現される。キーボードまたはキーパッド９３５は、キーパッド９３５の専用ファンクションキーを介した入力、またはキーパッド９３５からの英数字入力に使用することができる。ＬＣＤ画面９０２には、楽曲楽節９０４からの音符のグラフィック画像が提供され、これは画面中を横断し、各音符がプレイされるときにディスプレイ内に個々の音符が画面上に現れるか、または強調表示される。ディスプレイは、楽曲楽節９０４がプレイされるときに、楽曲の所定数の音符または小節が表示されるよう、再生中、引き延ばされた楽曲譜表画像を提供することが好ましい。

装置９００の一実施形態では、デジタルカメラシステム９１４が、楽曲楽譜内の楽節の画像（単一の音符、いくつかの小節、またはページ全体さえも）を取り込む。デジタルカメラは、装置９００に内蔵可能であり、当業者には周知であろうレンズと像変換器との組み合わせを含んでもよい。ＬＣＤ画面９０２は、取り込まれる小節をユーザが正確に決定できるようにする。装置は、単一譜表の楽曲ライン、二重奏、三重奏、四重層、または指揮者の総譜でさえ読み取ることができる。装置９００は、同時に数の音色を提供する。

ＯＣＲモジュールは、デジタル化画像データを含む、楽曲の抜粋の「写真」を受信してもよい。調号および拍子などの追加の重要な楽曲文脈情報も、楽曲楽譜のデジタル画像を介して、または有効な調号および拍子記号すべてを一覧にした「チートシート」（例えば、ウェブサイトからダウンロードされ、次に無線で、またはＵＳＢポートを介して装置に伝送される――下記参照）を介して、ＯＣＲモジュールへ送信される。この「チートシート」はさらに、ユーザがセクションから所望の音色（単数または複数）を選択することができる、またはユーザが所望の音色（単数または複数）を手動で指定（入力）することができるセクションを含んでもよい。

別の実施形態では、装置９００は、ＭＩＤＩシンセサイザーの機能を提供してもよい。ＯＣＲモジュールは、合成サウンドを作り出すＭＩＤＩモジュールにサウンド情報を送信してもよい。これは、調節可能な音色を提供する。ユーザは、楽曲の特定の楽節または一部分の、楽器の種類（ピアノ、バイオリン、フルートなど）を指定する。このモジュールはさらに、ユーザが、ピッチの変化なしで、楽譜に示されているメトロノーム（あれば）よりもゆっくりと（または速く）その楽節を聴くことができるように、調節可能なテンポを提供する。装置は、それ自体の小型ラウドスピーカを介して再生するが、さらにヘッドホンおよび／または外付けスピーカ用のヘッドホンジャック９３４および無線能力も有する。

様々な実施形態において、装置９００は、特定の視覚表示能力を提供してもよい。例えば、ＬＣＤ画面９０２は、取り込まれている（撮影されている）小節が、聴こうとしている小節であることをユーザが確認する助けになってもよい。カーソル９３６を備えたＬＣＤ画面９０２は、楽節が再生されるとき、ユーザによって撮影された楽節から、または格納済みデータを備える音楽カードから、楽曲楽節９０４を表示する。カーソルは、リアルタイムで楽曲楽節９０４がプレイされているときに、指定されているテンポには関係なく、プレイされている現在の音符（単数または複数）の楽譜内での正確な楽曲位置を示す。従来の種類の移動するカーソルではなく、代わりに、カーソル９３６はプレイされている音符を、その音符を強調表示すること（例えば、その音符をより明るくすること）、またはその音符がプレイされるときに他の音符とは異なる表示色を与えることによって示すことができる。別のオプションは、特に単一ラインの楽曲楽節９０４に関して、ＬＣＤ画面９０２が音符９３８の名前を示すことである（英語とソルフェージュとの両方で）。楽曲楽節９０４が、同時に存在する複数の楽曲ラインから成る場合、ユーザは、音符９３８の名前が表示されるラインを指定することができる。

ＬＣＤ画面９０２はさらに、プレイされるよう選択された楽曲楽節９０４のインジケータを示してもよい。このインジケータは、楽節マーカー９３９と呼ばれる。図９では、楽節マーカー９３９が、丸で囲まれた数字「１」として示されている。この数字「１」は、楽曲楽節９０４の第１小節が現在表示されていることを示し、丸は、再生が第１小節で開始されたことを示す。再生が次の小節に続くと、「２」が「１」の代わりに表示されるが、この「２」には丸が付かないことになる。

別の実施形態では、装置９００は、記録センサ機能を提供してもよい。例えば、マイクロホン９１２は、問題になっている楽曲楽節９０４をユーザ自身がプレイする（および／または歌う）のをユーザが記録して、直ちにその記録を再生し、ユーザのパフォーマンスと、装置９００の（すなわち、前もって記録されたか、または合成された演奏の）パフォーマンスとを比較できるように構成されてもよい。この機能は、生徒が音符、調律、リズムおよび強弱を調節する助けとなると考えられる。上述の通り、ユーザのパフォーマンスがマイクロホン９１２を介して記録され、「聴音」機能を提供することが可能である。

装置９００のいくつかの実施形態は、無線能力を提供する。例えば、装置９００は、ネットワークおよび他の無線対応装置との無線通信を可能にし、文脈情報を備えた符号化楽曲ファイルのダウンロードを可能にするよう動作可能であってもよい。本願明細書に記載される機能は、例えば、携帯用の音楽インタラクションのために、ＰＤＡまたはスマートフォンなどの無線プラットフォームにインストールされたｅＭｕｓｅソフトウェアによって提供されることが可能である。さらに、装置９００は、ホームＰＣおよび／またはステレオシステム、または別のコンポーネントの計算およびメモリ（およびオーディオ再生）を使用してもよい。

別の実施形態では、ユーザのパフォーマンスが装置９００によって記録され、そのユーザのパフォーマンスが音符解釈処理を受け、ユーザの記録済みパフォーマンスに対応する音符の表示を作り出すもとのデータが生成されてもよい。このようにして、装置は、「聴音」を行うことができ、ユーザによる生のオーディオパフォーマンスを、そのパフォーマンスに対応する楽曲楽譜の視覚表示に変換することができる。したがって、装置の楽曲解釈機能は、光または電子ネットワーク通信によって受信される両方の楽曲楽譜データを処理することができ、マイクロホンによって取り込まれたユーザの生のパフォーマンスによってつくり出される楽曲楽譜データを処理することができる。

本願明細書に記載されているソフトウェアは、様々なプラットフォームで使用可能である。一実施形態では、ｅＭｕｓｅの複数の側面が、ハイエンドの携帯電話に組み込まれ、携帯電話のカメラが楽曲楽譜内の特定の楽節を撮影する。次に、取り込み画像は、圧縮されてリモートサーバへ送信され、リモートサーバは、その画像データに対してＯＣＲ動作を実行して、画像を対応する音符情報へと解釈する。次に、サーバは、ｍｉｄｉファイルおよびグラフィックファイルの両方を送り返し、このバージョンのｅＭｕｓｅが、撮影された楽曲をプレイして、音符がプレイされるときに音符をＬＣＤに表示することができるようにする。

図１０は、図９の装置９００の実施形態の動作を示すプロセスフロー図の簡略化した例を提供する。最初の動作で、楽曲楽譜のデジタル表現が装置に提供される。デジタル表現は、装置と共に動作するデジタルカメラなどのデジタル画像キャプチャ装置１００４を使用してデジタル方式で取り込まれる印刷されたページなど、装置への視覚的表現１００２によって受信されることが可能である。次に、光学入力１００６から生じるデジタルデータが、音符データ解釈プロセス１００８に提供される。あるいは、楽曲楽譜のデジタル表現は、楽曲楽譜に対応するデジタルデータの無線伝送もしくはネットワーク上でのデータの有線伝送、またはメモリカードもしくは他の媒体などのストレージ媒体を介した入力などによって、電子的に１０１０提供されることが可能である。次に、楽曲楽譜１０１０の電子的に受信されたバージョンが、音符データ解釈プロセス１００８に提供される。

音符データ解釈プロセス１００８は、楽曲楽譜に対応するデジタルデータを受信し、それを処理して、楽曲楽譜を特定して適切なハードウェアによる楽譜の再現を可能にするのに十分な、音符と、付随する情報との組を作り出す。プロセス１００８は、楽曲楽譜デジタルデータ１００６、１０１０を認識して適切な変換データを作り出すよう機械学習技術で訓練された処理装置を含む。プロセス１００８は、例えば、解釈プロセスの精度を実質的に１００％の精度まで上げるために、ニューラルネットワークソフトウェア工学技術を使用して訓練可能である。本発明に従って、入力楽曲楽譜データは、ユーザに対するリアルタイムのオーディオおよび視覚的表現用に作り出す必要がある。したがって、入力楽曲楽譜データの解釈は、リアルタイムでなければならず、１００％の精度の解釈（変換）に近づかなくてはならない。プロセス１００８は、光学式文字認識（ＯＣＲ）技術を利用するが、音符の認識およびデジタルデータ（電子または光学スキャンから得られる）を適切な表現に解釈するよう適応している。

解釈プロセス出力１０１２は、装置のディスプレイ画面１０１４に提供される楽曲楽譜の視覚的表現、およびさらに、装置のスピーカまたは同様のものを介したオーディオ表現のために適切な装置システムおよびハードウェア１０１６に提供される楽曲楽譜の合成オーディオ演奏を含む。

（他の能力）
当然のことながら、上述の能力に加えて、他に多数の能力が考えられる。さらなる処理能力の１つの組は、ユーザに提供されるカスタマイズ性を高めることを含む。例えば、実施形態は、本発明の様々なコンポーネントおよび方法の、強化されたカスタマイズ性を可能にしてもよい。

いくつかの実施形態では、様々な理由から、様々な閾値、ウィンドウ、ならびにコンポーネントおよび方法に対するその他の入力はそれぞれ、調節可能とされてもよい。例えば、ユーザは、調判断が頻繁に行われすぎているように思われる場合に、調抽出ウィンドウを調整できてもよい（例えばユーザは、調からの短時間の離脱には、調の変更として楽譜上に現れてほしくないこともある）。別の例として、記録は、記録時のパフォーマンス中に使用される６０Ｈｚの電力から生じる背景雑音を含むこともある。ユーザは、この６０Ｈｚピッチを楽譜上に低音として表さないよう、様々なフィルタアルゴリズムを調節して、この６０Ｈｚピッチを無視することを希望するかもしれない。さらに別の例では、ユーザは、音符のピッチ分解能を調節するために、ピッチが量子化されるミュージックビン（ｍｕｓｉｃ ｂｉｎｓ）の分解能を調節してもよい。

他の実施形態では、より低いカスタマイズ性がユーザに提供されてもよい。一実施形態では、ユーザは、表現精度レベルを調節することができてもよい。ユーザは、テンポおよびピッチの様な個々の楽譜表現構成要素の精度の選択を含む１つ以上のパラメータに基づき、システムが精度のより高い楽譜表現を生成するべきか、またはより低い楽譜表現を生成するべきかを入力してもよい（例えば、物理的または仮想スライダー、ノブ、スイッチなどを介して）。

例えば、最小の音価が１６分音符となるように、いくつかの内部設定が連携してもよい。表現精度を調節することによって、より長いまたはより短い持続時間が検出され、最小値として表されてもよい。これは、演奏者が厳密に一定の拍で演奏していない場合（例えば、打楽器のセクションがない、メトロノームがないなど）に有用となり得、システムの精度が高すぎると、望ましくない表現（例えば複々付点音符）を生じることもある。別の例として、最小のピッチ変化が半音となる（すなわち、半音階での音符）よう、いくつかの内部設定が連携してもよい。

さらに他の実施形態では、さらに低いカスタマイズ性がユーザに提供されてもよい。一実施形態では、ユーザは、自らが初心者ユーザであるかまたは上級ユーザであるかを入力してもよい。別の実施形態では、ユーザは、システムの感度が高くあるべきかまたは低くあるべきかを入力してもよい。どちらの実施形態でも、多数のコンポーネントまたは方法において、多数の異なるパラメータが、所望のレベルに合うよう共に調節されてもよい。例えば、或る場合には、歌い手が、ピッチと持続時間のあらゆる揺れを正確に書き起こしたいこともある（例えば、間違いを発見するため、または特定のパフォーマンスを、そのすべての、感覚の微妙な違いとともに、忠実に再現するための練習の助けとして）。その一方で、別の場合には、歌い手は、システムに小さなずれを無視させることで、公開用の読みやすい楽譜を生成したいこともある。

特定の実施形態では、カスタマイズ性のレベル、機能の種類、およびシステムまたは方法のその他の側面は、種々の方法で決定されてよい。一実施形態では、ユーザは、そうした側面を決定するために、特定のプリファレンスを選択しても、特定の物理的または仮想コントロールを処理しても、または別の方法でシステムと能動的に対話してもよい。別の実施形態では、システムが、様々な側面を自動的に選択してもよい（例えば、ユーザに関するログインおよび／またはプロフィール情報から、またはユーザのシステムの使用パターンからなど）。

さらなる能力のもう１つの組は、様々な種類の入力を使用して、入力オーディオ信号の処理を精緻化するか、または別の形でこの処理に影響を及ぼすことを含む。一実施形態は、訓練された１つ以上の人工ニューラルネットワーク（ＡＮＮ）を使用して、特定の判断を精緻化する。例えば、心理音響学的判断（例えば、拍子、調、楽器編成など）は、訓練されたＡＮＮを使用するのに適している。

別の実施形態は、ユーザに、複数トラックをレイヤ状にする能力を提供する（例えば、ワンマンバンド）。ユーザが、ドラムトラックを演奏することによって開始してもよく、このトラックは、本発明のシステムを使用してリアルタイムで処理される。次に、ユーザは連続してギタートラック、キーボードトラック、およびボーカルトラックを演奏し、このそれぞれが処理される。場合によっては、ユーザは一緒に処理する複数のトラックを選択してもよく、他の場合には、ユーザは各トラックが別々に処理されるよう選んでもよい。続いて、いくつかのトラックからの情報が、他のトラックの処理を精緻化または指示するために使用されてもよい。例えば、ドラムトラックが独立して処理され、高信頼度のテンポおよび拍子情報が生成されてもよい。次に、テンポおよび拍子情報が、音符の持続時間および音価をより正確に判断するために他のトラックと共に使用されることも可能である。別の例として、ギタートラックは、小さな時間ウィンドウの間に多数のピッチを提供することもあり、これによって、調の判断が容易になることもある。次に、調の判断は、調のピッチの決定をキーボードトラックの各音符に割り当てるために使用されてもよい。さらに別の例として、複数トラックが、１つ以上の次元において位置合わせ、量子化、または正規化されてもよい（例えば、複数トラックが、同じテンポ、平均音量、ピッチの範囲、ピッチ分解能、最小音符持続時間などを有するように正規化されてもよい）。さらに、「ワンマンバンド」のいくつかの実施形態では、ユーザが、１つの楽器を使用してオーディオ信号を生成し、次に、システムまたは方法を使用して、単数または複数の異なる楽器に変換する（例えば、四重奏曲の４つのトラックすべてを、キーボードを使用してプレイして、そのキーボード入力を、システムを使用して弦楽四重奏に変換する）。場合によっては、これには、音色の調節、楽曲ラインの移調、および他の処理が必要となり得る。

さらに別の実施形態は、楽曲入力信号に付帯的な入力を使用して、処理を精緻化または指示する。一実施形態では、ジャンル情報がユーザ、別のシステム（例えばコンピュータシステムもしくはインターネット）、またはデジタルオーディオファイル内のヘッダ情報から受信され、様々なコスト関数を精緻化する。例えば、調のコスト関数は、ブルース、インドの古典音楽、フォークなどによって異なってもよい。または、異なる楽器編成の可能性は異なるジャンルで高くなると考えられる（例えば、「オルガンの様な」サウンドは、讃美歌音楽ではオルガンである可能性が高く、ポルカ音楽ではアコーディオンである可能性がより高いと考えられる）。

さらなる能力のもう１つの組は、複数のコンポーネントまたは方法にわたって情報を使用して、複雑な判断を精緻化することを含む。一実施形態では、楽器同定方法の出力が、特定されている楽器の既知の能力または限界に基づいて判断を精緻化するよう使用される。例えば、楽器同定方法が、楽曲ラインはピアノでプレイされている可能性が高いと判断すると仮定する。一方、ピッチ同定方法は、その楽曲ラインが、速くて浅いビブラート（例えば、検出された調のピッチ指示の１または２半音のみの範囲内でのピッチの震え）を含むと判断する。これは典型的にはピアノで作り出すことができる効果ではないため、システムは、このラインが別の楽器によりプレイされていると判断してもよい（例えば、電子キーボードまたはオルガン）。

さらなる能力のさらにもう１つの組は、システムおよび方法の様々な機能を使用して、着信音（例えば、携帯電話、ボイスオーバーインターネットプロトコル電話、およびその他の装置の）を処理することを含む。一実施形態では、分解された楽曲構成要素が着信音の規格に適合するように処理される。例えば、いくつかの装置は、着信音の帯域幅、ポリフォニーの深さ、および長さに制限があるかもしれない。したがって、場合によっては、システムが、着信音の規格に適合するよう検索入力または格納された検索データを自動的に調節してもよく、または、そうした規格に従ってユーザを導くのに望ましい情報または必要な情報を用いて、ユーザにプロンプトで指示を求めてもよい。その結果、ユーザは、例えば着信音を聴くこと、着信音を携帯電話または他の装置（またはストレージ場所）にダウンロードすること、ネットワーク経由で他者と着信音を共有すること、着信音をオークションにかけることまたは販売することなどができると考えられる。

さらなる能力のさらにもう１つの組は、オーディオまたは楽譜出力を、販売またはオークション用の製品として構成することを含む。例えば、検索ポータルは、楽曲オークション機能または楽曲ストア機能を含んでもよい。買い物機能は、著作権使用料および価格設定、投票（例えば、所定の期間中で最も人気の高いものを特集する、または勝者がポータル上で特別な特集を得る）、装置または規格での検索、異なる支払い処理、安全な電子商取引、著作権保護およびデジタル著作権管理などに関する能力を含んでもよい。

さらに、さらなる能力のもう１つの組は、分解または受信された楽曲構成要素を使用して、類似の作品を検索し、著作権侵害を回避（または検出）することを含む。この能力は、この特定の結果を求めて検索を調整するために、システムに追加モジュールが組み込まれること、または方法に追加ステップが組み込まれることを必要とすることもある。例えば、いくつかの実施形態では、著作権法およびポリシーに関する情報が提供され、システムおよび方法が、潜在的な侵害があるかどうかを判断する助けになってもよい。

当然のことながら、本発明によれば、このようなさらなる処理能力が多数考えられる。なお、さらに、上記で説明された方法、システムおよび装置は、単に例であるものとする。様々な実施形態は、必要に応じて様々な手順またはコンポーネントを省略、置換、または追加してよいということを強調しなければならない。例えば、当然のことながら、代わりの実施形態では、本方法が説明とは異なる順序で実行されてもよく、様々なステップが追加、省略されても、または組み合わされてもよい。さらに、特定の実施形態に関して説明された特徴が、他の様々な実施形態に組み合わされてもよい。実施形態の種々の側面および構成要素が、同様の形で組み合わされてもよい。さらに、技術は進化するものであり、したがって、構成要素の多くは例であり、本発明の範囲を制限すると解釈されてはならないということを強調しなくてはならない。

説明の中では、実施形態が完全に理解されるよう具体的な詳細事項が与えられた。しかし、当業者には当然のことながら、実施形態はこれらの具体的な詳細事項を用いずに実践されてもよい。例えば、実施形態を分かりにくくすることを避けるために、周知の回路、プロセス、アルゴリズム、構造および技術を、不必要な詳細事項なしで示してきた。さらに、本願明細書で与えられた見出しは、単に様々な実施形態の説明を明快にするのを助けることを目的としており、本発明の範囲または本発明のいかなる部分の機能も制限するものと解釈されてはならない。例えば、特定の方法またはコンポーネントは、たとえそれらが異なる見出しの下で説明されていても、他の方法またはコンポーネントの一部として実装されてもよい。

なお、さらに、実施形態は、フロー図またはブロック図として示されるプロセスとして記載されていることもある。それぞれ、動作を逐次プロセスとして記載しているかもしれないが、動作の多くは、並行して、または同時に実行可能である。さらに、各動作の順序は配列し直されてもよい。プロセスは、図に含まれていない追加のステップを有してもよい。

Claims (41)

1. 楽曲検索を実行するコンピュータ方法であって、
   楽曲構成要素を指定する楽曲クエリを受信することと、
   該受信された楽曲クエリによって指定された該楽曲構成要素に基づいて検索パラメータの組を生成することと、
   複数のデータ記録を含むデータベースに対して該検索パラメータの組を送ることであって、各データ記録は、楽曲作品と、該楽曲作品に関係する楽曲構成要素の組とに関連し、
   少なくとも１つのデータ記録に関連する該楽曲構成要素の組は、少なくとも１つの該楽曲作品から分解されたデータを含む、ことと、
   該データベースにおいて一致するデータ記録の組を同定することであって、該一致するデータ記録の組は、該検索パラメータの組と一致するデータ記録を含む、ことと、
   該データベースにおいて一致した楽曲作品の組を同定することであって、該一致した楽曲作品の組は該一致するデータ記録の組に関連する楽曲作品を含む、ことと、
   順位付けリストに並べられている該一致した楽曲作品を含む検索出力を生成することと
   を含む、方法。
2. 少なくとも１つの追加の楽曲クエリを受信することと、
   分解された追加の楽曲クエリを生成することと、
   分解された楽曲作品を含む選択されたデータベースに対して、該分解された追加の楽曲クエリを送ることと、
   該分解された追加の楽曲クエリに一致する、分解された楽曲作品を同定することと、
   順位付けリストに並べられている該同定された楽曲作品を含む検索出力を生成することと
   をさらに含む、請求項１に記載の方法。
3. 送ることは、前記分解された追加の楽曲クエリを、前の楽曲クエリの出力として同定された楽曲作品の組に対して送ることを含む、請求項２に記載の方法。
4. 前記順位付けリストは、重み付けされた値に従って並べられている、請求項２に記載の方法。
5. クエリを受信することは、オーディオ入力を受信することを含む、請求項１に記載の方法。
6. 前記オーディオ入力は、話し言葉の部分および旋律の部分を含む、請求項５に記載の方法。
7. 前記オーディオ入力において、前記話し言葉の部分と、前記旋律の部分との間に部分セパレータが存在する、請求項６に記載の方法。
8. 前記部分セパレータは、所定の話し言葉を含む、請求項７に記載の方法。
9. 前記オーディオ入力は、コンピュータ入力ポートを介して受信されたオーディオセグメントを含む、請求項５に記載の方法。
10. 前記オーディオ入力は、ＭＩＤＩシーケンスを含む、請求項５に記載の方法。
11. クエリを受信するステップは、楽曲楽譜画像を受信することを含む、請求項１に記載の方法。
12. 前記楽曲楽譜画像は、楽曲構成要素を有するＯＣＲ出力を含む、請求項１１に記載の方法。
13. クエリを受信することは、前記楽曲構成要素に対するユーザ指定の入力パラメータを受信することを含む、請求項１に記載の方法。
14. 前記ユーザ指定の入力パラメータは、話し言葉として受信される、請求項１３に記載の方法。
15. 前記ユーザ指定の入力パラメータは、英数字入力として受信される、請求項１３に記載の方法。
16. クエリを受信することは、楽曲作品のメタデータに対して送るユーザ指定の入力パラメータを受信することを含む、請求項１に記載の方法。
17. 前記ユーザ指定の入力パラメータは、話し言葉として受信される、請求項１６に記載の方法。
18. 前記ユーザ指定の入力パラメータは、英数字入力として受信される、請求項１６に記載の方法。
19. 前記分解された楽曲クエリを送ることは、前記検索が送られるユーザ指定のデータベースを受信することを含む、請求項１に記載の方法。
20. 前記ユーザ指定のデータベースは、前記コンピュータのデータベースを含む、請求項１９に記載の方法。
21. 楽曲検索を実行するコンピュータシステムであって、
    楽曲セグメントを指定する楽曲クエリを受信するよう適合される入力インターフェースと、
    該受信された楽曲クエリの楽曲構成要素を含む分解された楽曲クエリを生成するよう適合されるクエリ入力プロセッサと、
    分解された楽曲作品を含む選択されたデータベースに対して、該分解された楽曲クエリを送り、該分解された楽曲クエリに一致する該データベースの分解された楽曲作品を同定し、順位付けリストに並べられている該同定された楽曲作品を含む検索出力を同定して生成するよう適合されるクエリエンジンと
    を含む、システム。
22. 前記入力インターフェースは、少なくとも１つの追加の楽曲クエリを受信し、
    前記クエリ入力プロセッサは、分解された追加の楽曲クエリを生成し、
    前記クエリエンジンは、該分解された追加の楽曲クエリを分解された楽曲作品を含む選択されたデータベースに対して送り、該分解された追加の楽曲クエリに一致する分解された楽曲作品を同定し、順位付けリストに並べられている該同定された楽曲作品を含む検索出力を生成する、請求項２１に記載のシステム。
23. 前記システムは、前記追加の楽曲クエリを、前の楽曲クエリの出力として同定された楽曲作品の組に対して送る、請求項２２に記載のシステム。
24. 前記順位付けリストは、重み付けされた値に従って並べられている、請求項２２に記載のシステム。
25. クエリを受信することは、オーディオ入力を受信することを含む、請求項２１に記載のシステム。
26. 前記オーディオ入力は、話し言葉の部分および旋律の部分を含む、請求項２５に記載のシステム。
27. 前記オーディオ入力において、前記話し言葉の部分と、前記旋律の部分との間に部分セパレータが存在する、請求項２６に記載のシステム。
28. 前記部分セパレータは、所定の話し言葉を含む、請求項２７に記載のシステム。
29. 前記オーディオ入力は、コンピュータ入力ポートを介して受信されたオーディオセグメントを含む、請求項２５に記載のシステム。
30. 前記オーディオ入力は、ＭＩＤＩシーケンスを含む、請求項２５に記載のシステム。
31. クエリを受信することは、楽曲楽譜画像を受信することを含む、請求項２１に記載のシステム。
32. 前記楽曲楽譜画像は、楽曲構成要素を有するＯＣＲ出力を含む、請求項３１に記載のシステム。
33. 前記受信されたクエリは、前記楽曲構成要素に対して送られるユーザ指定の入力パラメータを含む、請求項２１に記載のシステム。
34. 前記ユーザ指定の入力パラメータは、話し言葉として受信される、請求項３３に記載のシステム。
35. 前記ユーザ指定の入力パラメータは、英数字入力として受信される、請求項３３に記載のシステム。
36. 前記受信されたクエリは、楽曲作品のメタデータに対して送られるユーザ指定の入力パラメータを含む、請求項２１に記載のシステム。
37. 前記ユーザ指定の入力パラメータは、話し言葉として受信される、請求項３６に記載のシステム。
38. 前記ユーザ指定の入力パラメータは、英数字入力として受信される、請求項３６に記載のシステム。
39. 前記分解された楽曲クエリは、前記検索が送られるユーザ指定のデータベースを含む、請求項２１に記載のシステム。
40. 前記ユーザ指定のデータベースは、前記コンピュータのデータベースを含む、請求項３９に記載のシステム。
41. 楽曲ベースの検索エンジンの動作を指示するコンピュータ読み取り可能プログラムが具現化されているコンピュータ読み取り可能ストレージ媒体であって、該コンピュータ読み取り可能プログラムは、以下の：
    楽曲構成要素を指定する楽曲クエリを受信することと、
    該受信された楽曲クエリによって指定された該楽曲構成要素に基づいて検索パラメータの組を生成することと、
    複数のデータ記録を含むデータベースに対して該検索パラメータの組を送ることであって、各データ記録は、楽曲作品と、該楽曲作品に関係する楽曲構成要素の組とに関連し、
    少なくとも１つのデータ記録に関連する該楽曲構成要素の組は、少なくとも１つの該楽曲作品から分解されたデータを含む、ことと、
    該データベースにおいて一致するデータ記録の組を同定することであって、該一致するデータ記録は該検索パラメータの組に一致するデータ記録を含む、ことと、
    該データベースにおいて一致した楽曲作品の組を同定することであって、該一致した楽曲作品は該一致するデータ記録の組と関連する楽曲作品を含む、ことと、
    順位付けリストに並べられている該一致した楽曲作品を含む検索出力を生成することと
    に従う、楽曲ベースの検索に関する命令を含む、コンピュータ読み取り可能ストレージ媒体。

Images