JP5272899B2 - 楽曲難易度算出装置および楽曲難易度算出プログラム - Google Patents

Description

本発明は、楽曲の難易度を評価する楽曲難易度算出装置および楽曲難易度算出プログラムに関する。

従来、楽曲の難易度を評価するときに、音楽教育の専門家や演奏家が、その楽曲における種々の要素、たとえば、音符の連なりなどに基づいて、主観的な評価を行なっていた。従来の主観的な評価では、たとえば、楽曲の構成要素についての客観的な難易度は存在せず、楽曲全体としての評価（たとえば、１０段階評価など）がなされているに過ぎない場合が多かった。

これに対して、楽曲を鍵盤楽器にて演奏する際の運指情報に基づいて、当該運指の難易度を算出する装置が提案されている。特許文献１には、ある音程の２音を２つの指にて押さえるような全ての場合を想定し、当該全ての場合のコストを定義し、運指情報が示す運指を行なう上での難易度を算出する難易度算出方法が提案されている。

特開２００６−７８６５６号公報

しかしながら、従来の難易度を算出する装置では、２音を２つの指にて押さえるような全ての場合の全てについてコスト値を定義するのが容易ではないという問題点があった。また、楽曲の難易度は運指のみではなく、他にも種々の要素が存在する。したがって、他の要素も考慮したうえで難易度を算出することが望ましい。

さらに、演奏者が感じる楽曲の難易度は演奏者の技量や楽曲の演奏経験によって相違する。たとえば、ある楽曲をすでに習得済みの演奏者は、当該楽曲の構成要素（たとえば、運指やリズム）を経験しているため、同様の演奏テクニックなど楽曲を構成する要素の具体的形態を含む楽曲についてはそれほど困難さを感じないことになる。したがって、演奏者の経験に基づいて楽曲の難易度を適切化することが望まれる。

本発明は、楽曲を構成する種々の要素を考慮して、適切に楽曲の難易度を算出する楽曲難易度算出装置および楽曲難易度算出プログラムを提供することを目的とする。また、本発明は、演奏者の経験に基づいて適切化された難易度を算出する楽曲難易度算出装置および楽曲難易度算出プログラムを提供することを目的とする。

本発明の目的は、楽曲を構成する音符ごとの音高情報、鍵盤位置情報、当該音符を押鍵する際の運指情報、および、当該音符についての時間情報を含む楽音データを格納した記憶手段と、
この記憶手段から楽音データを音符毎に順次読み出すとともに、当該読み出された音符に隣接する音符の楽音データを読み出す読み出し手段と、
この読み出し手段にて読み出された音符の楽音データ及び前記隣接する音符の楽音データ夫々に含まれる音高情報及び運指情報に基づき、隣接する音符間を押鍵する際になされる指使いの種別を判別する第１の判別手段と、
前記読み出された音符の楽音データ及び前記隣接する音符の楽音データ夫々に含まれる音高情報により決定された白鍵、黒鍵のいずれかであるかを示す情報と、運指情報とに基づき、隣接する音符間を押鍵する際の指のポジション種別を判別する第２の判別手段と、
前記読み出された音符の楽音データ及び前記隣接する音符の楽音データ夫々に含まれる音高情報及び運指情報に基づき、指くぐり或いは指返しの有無の種別を判別する第３の判別手段と、
前記読み出された音符の楽音データ及び前記隣接する音符の楽音データ夫々に含まれる鍵盤位置情報に基づき、隣接する音符を押鍵する指の開き具合の種別を判別する第４の判別手段と、
前記第１の判別手段乃至第４の判別手段夫々により判別された指使いの種別、指ポジションの種別、指くぐり或いは指返しの有無、及び指の開き具合の種別毎の数をカウントする種別カウント手段と、
前記指使いの種別、指ポジションの種別、指くぐり或いは指返しの有無、及び指の開き具合の種別の夫々において、演奏者による未習得・習得済みを示す習得度マップを生成する習得度マップ生成手段と、
前記指使いの種別、指ポジションの種別、指くぐり或いは指返しの有無の種別、及び指の開き具合の種別毎のコスト値のうち、前記習得度マップを参照して前記演奏者が未修得の種別のコスト値のみを取得し、前記種別カウント手段によりカウントされた種別毎の数に応じて、対応する当該取得されたコスト値を前記種別毎に累算するとともに、当該累算された種別毎のコスト値を加算することにより、楽曲難易度を算出する算出手段と、
を有する楽曲難易度算出装置により達成される。

また、好ましい実施態様においては、前記読み出し手段にて読み出された音符の楽音データ及び前記隣接する音符の楽音データ夫々に含まれる音高情報及び運指情報に基づき、音符の進行が上行かつ指が開く形態で運指が行われるか否かを判別する第５の判別手段を更に有し、
前記第５の判別手段により音符の進行が上行かつ指が開く形態で運指が行われると判別された場合に、前記第３の判別手段により判別される種別を特定の種別とし、判別されない場合は、前記第２の判別手段及び第４の判別手段により判別される種別を特定の種別とする。

また、本発明の目的は、楽曲を構成する音符ごとの音高情報、鍵盤位置情報、当該音符を押鍵する際の運指情報、および、当該音符についての時間情報を含む楽音データを格納した記憶手段を備えたコンピュータに、
この記憶手段から楽音データを音符毎に順次読み出すとともに、当該読み出された音符に隣接する音符の楽音データを読み出す読み出しステップと、
この読み出された音符の楽音データ及び前記隣接する音符の楽音データ夫々に含まれる音高情報及び運指情報に基づき、隣接する音符間を押鍵する際になされる指使いの種別を判別する第１の判別ステップと、
前記読み出された音符の楽音データ及び前記隣接する音符の楽音データ夫々に含まれる音高情報により決定された白鍵、黒鍵のいずれかであるかを示す情報と、運指情報とに基づき、隣接する音符間を押鍵する際の指のポジション種別を判別する第２の判別ステップと、
前記読み出された音符の楽音データ及び前記隣接する音符の楽音データ夫々に含まれる音高情報及び運指情報に基づき、指くぐり或いは指返しの有無の種別を判別する第３の判別ステップと、
前記読み出された音符の楽音データ及び前記隣接する音符の楽音データ夫々に含まれる鍵盤位置情報に基づき、隣接する音符を押鍵する指の開き具合の種別を判別する第４の判別ステップと、
前記第１の判別ステップ乃至第４の判別ステップ夫々により判別された指使いの種別、指ポジションの種別、指くぐり或いは指返しの有無、及び指の開き具合の種別毎の数をカウントする種別カウントステップと、
前記指使いの種別、指ポジションの種別、指くぐり或いは指返しの有無、及び指の開き具合の種別の夫々において、演奏者による未習得・習得済みを示す習得度マップを生成する習得度マップ生成ステップと、
前記指使いの種別、指ポジションの種別、指くぐり或いは指返しの有無の種別、及び指の開き具合の種別毎のコスト値のうち、前記習得度マップを参照して前記演奏者が未修得の種別のコスト値のみを取得し、前記カウントされた種別毎の数に応じて、対応する当該取得されたコスト値を前記種別毎に累算するとともに、当該累算された種別毎のコスト値を加算することにより、楽曲難易度を算出する算出ステップと、
を実行させる楽曲難易度算出プログラムにより達成される。

本発明によれば、楽曲を構成する種々の要素を考慮して、適切に楽曲の難易度を算出する楽曲難易度算出装置および楽曲難易度算出プログラムを提供することが可能となる。また、本発明によれば、演奏者の経験に基づいて適切化された難易度を算出する楽曲難易度算出装置および楽曲難易度算出プログラムを提供することが可能となる。

図１は、本発明の第１の実施の形態にかかる楽曲難易度算出装置の構成を示すブロックダイヤグラムである。 図２は、本実施の形態にかかる楽曲難易度算出装置１０において実行される処理の概略を示すフローチャートである。 図３は、本実施の形態にかかる楽曲データのデータ構成例を示す図である。 図４は、本実施の形態にかかる難易度評価処理の例を概略的に示すフローチャートである。 図５は、本実施の形態にかかる運指難易度評価処理の例を示すフローチャートである。 図６は、本実施の形態にかかる運指難易度評価処理の例を示すフローチャートである。 図７は、本実施の形態にかかるテクニック分類処理の例を示すフローチャートである。 図８は、本実施の形態にかかるテクニック分類処理の例を示すフローチャートである。 図９は、本実施の形態にかかる指開き特定処理の例を詳細に示すフローチャートである。 図１０は、本実施の形態にかかるリズム難易度評価処理の例を示すフローチャートである。 図１１は、本実施の形態にかかるリズム難易度評価処理の例を示すフローチャートである。 図１２は、本実施の形態にかかるリズムコスト算出処理の例を示すフローチャートである。 図１３は、本実施の形態にかかるリズムコスト算出処理の例を示すフローチャートである。 図１４は、本実施の形態にかかる調性難易度評価処理の例を示すフローチャートである。 図１５は、本実施の形態にかかる調性難易度評価処理の例を示すフローチャートである。 図１６は、本実施の形態において鍵位置情報を説明するための図である。 図１７（ａ）は、本実施の形態にかかるベーススケール配列ｉＢａｓｅＳｃａｌｅ［］の例を示す図、図１７（ｂ）は、本実施の形態にかかる非ベーススケール配列ｉＡＴｏｎａｌ［］の例を示す図である。 図１８は、本実施の形態にかかる長音階との一致度ｉＳｕｍの算出を説明するための図である。 図１９は、本実施の形態にかかる長音階との不一致度ｉＡＴｏｎａｌｉｔｙの算出を説明するための図である。 図２０は、本実施の形態にかかる難易度表示処理の例を示すフローチャートである。 図２１は、本実施の形態にかかる難易度表示処理により生成された楽譜の画像の例を示す図である。 図２２は、本実施の形態にかかる習得楽曲対応処理の例を示すフローチャートである。 図２３は、第２の実施の形態にかかる運指難易度評価処理の後半部分の例を示すフローチャートである。 図２４は、第２の実施の形態にかかる習得楽曲対応処理の例を示すフローチャートである。 図２５は、本発明の第３の実施の形態にかかるリズム難易度評価処理の例を示すフローチャートである。 図２６は、本発明の第３の実施の形態にかかるリズム難易度評価処理の例を示すフローチャートである。 図２７は、第３の実施の形態にかかる習得楽曲対応処理の例を示すフローチャートである。

以下、添付図面を参照して、本発明の実施の形態について説明する。図１は、本発明の第１の実施の形態にかかる楽曲難易度算出装置の構成を示すブロックダイヤグラムである。図１に示すように、本実施の形態にかかる楽曲難易度算出装置１０は、ＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、大規模記憶装置１４、入力装置１５、表示装置１６、サウンドシステム１７および鍵盤１８を有している。

ＣＰＵ１１は、後述する楽曲の難易度を評価するための種々の処理（運指難易度評価処理、リズム難易度評価処理、調性難易度評価処理、全体難易度の算出処理）や、操作者（演奏者）が習得した楽曲についての所定の情報を取得する処理（習得楽曲対応処理）を実行する。ＲＯＭ１２は、楽音難易度を評価するための種々の処理（運指難易度評価処理、リズム難易度評価処理、調性難易度評価処理、全体難易度の算出処理）、および、操作者（演奏者）が習得した楽曲についての所定の情報を取得する処理（習得楽曲対応処理）のプログラムや、処理に使用するパラメータなどを格納する。ＲＡＭ１３は、プログラムの実行の過程で生じたパラメータ、入力データ、出力データなどを一時的に記憶する。大規模記憶装置１４は、ハードディスク装置やメモリカードなどであり、楽曲データなどを格納する。なお、以下、本実施の形態においては、入力装置の操作者が演奏者でもあり、したがって、操作者は、自己の習得した楽曲を指定する情報を入力している。しかしながら、これに限定されるものではなく、操作者が、他の演奏者が習得した楽曲を指定する情報を入力し、楽曲難易度算出装置１０が、当該他の演奏者に対する楽曲難易度を算出できることは言うまでもない。

入力装置１５は、スイッチ類、キーボード、マウスなどを含み、操作者のスイッチ操作、キー操作、マウスの操作に基づく種々の指示などをＣＰＵ１１に与える。表示装置１２の画面上には、楽曲データに基づく楽譜、楽曲難易度の評価結果などを含む画像データが表示される。サウンドシステム４０は、楽音生成回路、増幅器、スピーカなどを含み、楽曲データにしたがって、或いは、操作者による鍵盤１８の押鍵操作にしたがって所定の楽音を生成して、楽音に基づく音響信号を出力する。なお、上記実施の形態において、鍵盤１８は必須ではない。

また、本実施の形態にかかる楽曲難易度算出装置１０は、鍵盤楽器の形態であっても良いし、或いは、パーソナルコンピュータのような形態であっても良い。鍵盤楽器の形態であれば、操作者は、表示装置１６の画面上に表示された楽譜を参照して、鍵盤１８の鍵を押鍵し、サウンドシステム１７が、操作者の押鍵に応答して、押鍵された鍵の音高に対応する楽音データを生成することで、サウンドシステム１７から楽音を出力することができる。

図２は、本実施の形態にかかる楽曲難易度算出装置１０において実行される処理の概略を示すフローチャートである。図２に示すように、本実施の形態にかかる楽曲難易度算出装置１０のＣＰＵ１１は、ＲＡＭ１３に格納されたパラメータ等のクリア、表示装置１６の画面上に表示された画像のクリアなどを含むイニシャライズを実行する（ステップ２０１）。次いで、ＣＰＵ１１は、楽曲難易度算出装置１０における動作モードを判断する（ステップ２０２）。本実施の形態において、楽曲難易度算出装置１０は、指定された楽曲についての難易度を評価する難易度評価モード、および、操作者（演奏者）が習得した楽曲を登録して当該楽曲について所定の情報を取得する習得楽曲登録モードを備え、動作モードを示す情報がＲＡＭ１３に格納される。したがって、ステップ２０２においては、楽曲難易度算出装置１０が、難易度評価モード或いは習得楽曲登録モードの、何れの動作モードの下にあるかが判断される。

ステップ２０２において、難易度評価モードであると判断された場合には、ＣＰＵ１１は、操作者が入力装置１５を操作することにより楽曲指定の入力があったかを判断する（ステップ２０３）。たとえば、楽曲指定の入力は、楽曲データの番号を入力することにより実現される。

ステップ２０３でＹｅｓと判断された場合には、ＣＰＵ１１は、大規模記憶装置１４に格納された楽曲データ群から、指定された楽曲の楽曲データを読み出して、ＲＡＭ１３に一時的に記憶する（ステップ２０４）。次いで、ＣＰＵ１１は、難易度評価処理を実行して、データを読み出された楽曲の難易度を示す値ｉＣｏｓｔを算出する（ステップ２０５）。ステップ２０３でＮｏと判断されると、ＣＰＵ１１は、難易度算出が行なわれた楽曲のそれぞれについて、算出された難易度と楽曲中の音符との関連を示す画像を生成して表示装置１６の画面上に表示する難易度表示処理を実行する（ステップ２０６）。難易度評価処理および難易度表示処理については、以下に詳述する。

ステップ２０２において、習得楽曲登録モードであると判断された場合には、ＣＰＵ１１は、操作者が入力装置１５を操作することにより楽曲指定の入力があったかを判断する（ステップ２０７）。ステップ２０３と同様に、楽曲指定の入力は、楽曲データの番号を入力することにより実現される。ステップ２０７においてＹｅｓと判断された場合には、ＣＰＵ１１は、習得楽曲対応処理を実行する（ステップ２０８）。ステップ２０７でＮｏと判断されると、ＣＰＵ１１は処理を終了する。習得楽曲対応処理についても後に詳述する。

図３は、本実施の形態にかかる楽曲データのデータ構成例を示す図である。図３に示すように、ある楽曲の楽曲データは、音符（ノート）ごとに、発音すべき楽音を示す楽音データのレコード（符号３０１、３０２参照）を有する。楽音データのレコード（たとえば、先頭のノートのレコードＮｏｔｅ［０］：符号３０１）は、音高情報「Ｐｉｔ」、鍵盤位置情報「Ｐｏｓ」、運指情報「Ｆｉｇ」、発音時刻「Ｔｉｍｅ」、発音時間「Ｇａｔｅ」、次のノートのレコードへのポインタ「＊Ｎｅｘｔ」および前のノートのレコードへのポインタ「＊ｐｒｅｖ」という項目を含む。

音高情報「Ｐｉｔ」は、たとえば、音名「Ｃ−１」を「０」として、音高が１つ高くなるごとに「１」を増分させた値である。鍵盤位置情報「Ｐｏｓ」は、当該音高に対応する鍵の横方向の中心位置を示す座標値である。たとえば、図１６に示すように、ある位置のＣ（たとえば、Ｃ４：Ｐｉｔ＝６０）の鍵盤位置情報Ｐｏｓ＝Ｘ_０とすると、Ｃ＃４〜Ｃ５までの鍵盤位置情報は、それぞれ、Ｘ_１〜Ｘ_１２で示すような値となる。図１６から理解できるように、隣接する白鍵と黒鍵、黒鍵と白鍵との間の座標値の差は「１」である。その一方、連続する白鍵（ＥとＦ、ＢとＣ）との間の座標値の差は「２」となる。

図４は、本実施の形態にかかる難易度評価処理の例を概略的に示すフローチャートである。図４に示すように、ＣＰＵ１１は、運指難易度評価処理（ステップ４０１）、リズム難易度評価処理（ステップ４０２）、調性難易度評価（ステップ４０３）、全体難易度の算出処理（ステップ４０４）を実行する。運指難易度評価処理において、ＣＰＵ１１は、楽音データ中の運指情報などに基づいて、運指難易度ｉＦＣｏｓｔを算出する。リズム難易度評価処理において、ＣＰＵ１１は、楽音データ中の発音時刻、発音時間などに基づいて、リズム難易度ＲＣｏｓｔを算出する。また、調性難易度評価処理において、ＣＰＵ１１は、楽音データの音高情報などに基づいて、調性難易度ｉＴＣｏｓｔを算出する。

ＣＰＵ１１は、算出した運指難易度ｉＦＣｏｓｔ、リズム難易度ｉＲＣｏｓｔ、調性難易度ｉＴＣｏｓｔおよび楽曲データ中のノート数（ｉＣｎｔ）に基づいて、それぞれに、重み係数ＲＦ、ＲＲ、ＲＴおよびＲＣを乗じて加算することで楽曲の難易度ｉＣｏｓｔを算出する（ステップ４０４）。すなわち、難易度ｉＣｏｓｔは以下の数式のようになる。

ｉＣｏｓｔ＝ｉＦＣｏｓｔ×ＲＦ＋ｉＲＣｏｓｔ×ＲＲ
＋ｉＴＣｏｓｔ×ＲＴ＋ｉＣｎｔ×ＲＣ
以下、運指難易度評価処理、リズム難易度評価処理および調性難易度評価処理について詳細に説明する。図５および図６は、本実施の形態にかかる運指難易度評価処理の例を示すフローチャートである。なお、本実施の形態においては、楽曲データは、右手で演奏する楽曲（メロディ）の音符についての楽音データから構成される。したがって、運指難易度においては、右手で演奏する場合の運指難易度が算出され。楽曲データ中、楽音データのレコードの運指情報は、右手のどの指で押鍵するかを示している。また、指番号「１」〜「５」は、それぞれ、親指〜小指で押鍵すべきことを示している。

図５に示すように、ＣＰＵ１１は、楽音データに示す楽曲のノート（音符）数を示すパラメータｉＣｎｔを「０」に初期化するとともに（ステップ５０１）、ＲＡＭ１３の楽曲データ中、最初の楽音データのレコードＮｏｔｅ［０］を、配列ｍｅ［］に格納する（ステップ５０２）。ＣＰＵ１１は、楽曲データにおいて全ての楽音データのレコードについて処理が終了するまで（ステップ５０３でＹｅｓ）、ステップ５０４〜５１５を繰り返す。

まず、ＣＰＵ１１は、配列ｍｅ［］に格納された楽音データのレコードの、一つ前の楽音でデータのレコードを特定し、それを配列ｐｒｅｖ［］に格納する（ステップ５０４）。次いで、ＣＰＵ１１は、配列ｍｅ［］および配列ｐｒｅｖ［］に格納された値に基づいて、テクニック分類処理を実行する（ステップ５０５）。テクニック分類処理においては、楽曲の隣接する音符間の運指について、ポジションタイプ（ＰｏｓＴｙｐｅ）、指開きタイプ（ｉＳｐｒｅａｄＴｙｐｅ）、リバースタイプ（ＲｅｖＴｙｐｅ）、および、指使いテクニック（Ｔｅｃｈ）という４つの分類項目のそれぞれの何れに該当するかを判断する。

ここで、ポジションタイプ（ＰｏｓＴｙｐｅ）という分類項目は、どのような指のポジションで運指が行なわれるかを示す。また、指開きタイプ（ｉＳｐｒｅａｄＴｙｐｅ）は、隣接する音符を押鍵する指の開き具合を示す。また、リバースタイプ（ＲｅｖＴｙｐｅ）は、後述する指くぐり、或いは、指返し（乗り越え）の存在を示す。さらに、指使いテクニック（Ｔｅｃｈ）は、隣接する音符を押鍵するときにどのような指使い（指換え）がなされているかを示す。

テクニック分類処理では、それぞれの分類項目について、当該分類項目における具体的提要を示す分類値が算出される。図７および図８は、本実施の形態にかかるテクニック分類処理の例を示すフローチャートである。ＣＰＵ１１は、配列ｍｅ［］中の運指情報「Ｆｉｇ」、音高情報「Ｐｉｔ」および鍵盤位置情報「Ｐｏｓ」について、ｆ１＝Ｆｉｇ、ｐ１＝Ｐｉｔ、ｐｓ１＝Ｐｏｓとする。また、音高情報「Ｐｉｔ」に基づき、鍵が白鍵か黒鍵かを判断し、白鍵、黒鍵の何れかを示す情報をｂ１とする。値ｂ１は、鍵が黒鍵であることを示す値「１」或いは鍵が白鍵であることを示す値「０」の何れかをとる。これら値ｆ１、ｐ１、ｐｓ１、ｂ１は、ＲＡＭ１３に格納される。

また、ＣＰＵ１１は、配列ｐｒｅｖ［］中の運指情報「Ｆｉｇ」、音高情報「Ｐｉｔ」および鍵盤位置情報「Ｐｏｓ」について、ｆ２＝Ｆｉｇ、ｐ２＝Ｐｉｔ、ｐｓ２＝Ｐｏｓとする。また、音高情報「Ｐｉｔ」に基づき、鍵が白鍵か黒鍵かを判断し、白鍵、黒鍵の何れかを示す情報をｂ２とする。これら値ｆ２、ｐ２、ｐｓ２、ｂ２は、ＲＡＭ１３に格納される。ＣＰＵ１１は、ｐ１、ｐ２、ｆ１およびｆ２に基づき、音高差を示す指標ｉＤｉｓｔを算出する（ステップ７０３）。

音高差を示す指標ｉＤｉｓｔは、楽曲において音符の進行が上行であったときに、指番号が増大あるいは減少しているか、また、進行が下行であったときに、指番号が減少或いは増大しているかを示す指標である。本実施の形態においては、ｉＤｉｓｔは以下のように求められる。

ｉＤｉｓｔ＝（ｐ１−ｐ２）＊（ｆ１−ｆ２）
したがって、ｉＤｉｓｔ＞０である場合には、音符の進行が上行かつ指番号が増大するような指使いである場合、或いは、音符の進行が下行かつ指番号が減少するような指使いである場合を意味している。すなわち、ｉＤｉｓｔ＞０である場合には、指が開く形態で運指が行なわれる（指くぐりや指返しが行なわれない）ことを示している。

ＣＰＵ１１は、ｆ２＝ｆ１かつｐ２＝ｐ１であるかを判断する（ステップ７０４）。ステップ７０４でＹｅｓとなる場合とは、隣接する音符間で、同じ音高の鍵が同じ指で押鍵されることを示す。ステップ７０４でＹｅｓと判断された場合には、ＣＰＵ１１は、指使いテクニック（Ｔｅｃｈ）という分類項目について、分類値Ｔｅｃｈとして、「Ｔｅｃｈ＝３」という値を与える（ステップ７０５）。与えられた値は、ＲＡＭ１３に格納される。次いで、ＣＰＵ１１は、ｆ２≠ｆ１かつｐ２＝ｐ１であるかを判断する（ステップ７０６）。ステップ７０６でＹｅｓとなる場合とは、隣接する音符間で、同じ音高の鍵が異なる指で押鍵されることを示す。ステップ７０６でＹｅｓと判断された場合には、ＣＰＵ１１は、指使いテクニック（Ｔｅｃｈ）という分類項目について、「Ｔｅｃｈ＝２」という値を与える（ステップ７０７）。

次いで、ＣＰＵ１１は、ｆ２＝ｆ１かつｐ２≠ｐ１であるかを判断する（ステップ７０８）。ステップ７０８でＹｅｓとなる場合とは、隣接する音符間で異なる音高の鍵が同じ指で押鍵されることを示す。ステップ７０８でＹｅｓと判断された場合には、ＣＰＵ１１は、指使いテクニック（Ｔｅｃｈ）という分類項目について、「Ｔｅｃｈ＝４」という値を与える（ステップ７０９）。ステップ７０８でＮｏと判断された場合には、ＣＰＵ１１は、指使いテクニック（Ｔｅｃｈ）という分類項目について、「Ｔｅｃｈ＝１」という値を与える（ステップ７１０）。

次に、ＣＰＵ１１は、ｉＤｉｓｔ＞０であるかを判断する（ステップ８０１）。上述したように、ｉＤｉｓｔ＞０であることは、指が開く形態で運指が行なわれる（指くぐりや指返しが行なわれない）ことを示している。ステップ８０１でＹｅｓと判断された場合には、ＣＰＵ１１は、ｂ２、ｂ１、ｆ２およびｆ１に基づいて、所定のテーブルｉＰＴｙｐｅ［］［］［］［］に基づいて、分類値ＰｏｓＴｙｐｅとして、ＰｏｓＴｙｐｅ＝ｉＰＴｙｐｅ［ｂ２］［ｂ１］［ｆ２］［ｆ１］を取得する（ステップ８０２）。テーブルｉＰＴｙｐｅ［］［］［］［］は、隣接する音符について、指番号および白鍵／黒鍵の種別に基づく値を含み、ＲＡＭ１３に格納される。

テーブルｉＰＴｙｐｅ［］［］［］［］における値について以下に簡単に説明する。テーブルｉＰｔｙｐｅ［］［］［］［］は、隣接する音符に配置すべき指の指番号およびその位置（白鍵或いは黒鍵）の関係に基づいて、その指のポジションタイプを格納したテーブルである。たとえば、現在の音符および一つ前の音符の双方が白鍵であれば、ｉＰＴｙｐｅ［０］［０］［ｆ２］［ｆ１］＝１となる。また、一つ前の音符が親指でかつ白鍵が押鍵されていれば、現在の音符が黒鍵であった場合に、ｉＰＴｙｐｅ［０］［１］［１］［ｆ１］＝２となる。また、一つ前の音符が親指でかつ黒鍵が押鍵されていれば、現在の音符が黒鍵であった場合に、ｉＰＴｙｐｅ［１］［１］［１］［ｆ１］＝３となる。

このように、テーブルｉＰｔｙｐｅにおいては、隣接する音符を押鍵するときの手のむきや指の位置の難易度が高まるのに応じて、値が大きくなるようになっている。

ステップ８０２が実行された後、ＣＰＵ１１は、指開き特定処理を実行する（ステップ８０３）。図９は、本実施の形態にかかる指開き特定処理の例を詳細に示すフローチャートである。

図９に示すように、ＣＰＵ１１は、指開きの度合いを示すパラメータであるｉＭｉｎ、ｉＬ１およびｉＬ２（ｉＭｉｎ＜ｉＬ１＜ｉＬ２）をＲＡＭ１３から取得する（ステップ９０１）。たとえば、ｉＭｉｎは、白鍵での長２度の幅に相当する「２」、ｉＬ１は、白鍵での長３度に相当する「４」、ｉＬ１は、白鍵での完全８度に相当する「１４」である。指開き特定処理においては、ｉＤｉｓｔと、ｉＭｉｎ、ｉＬ１およびｉＬ２とを比較して、指開きタイプ（ｉＳｐｒｅａｄＴｙｐｅ）の分類値を決定していく。

ＣＰＵ１１は、鍵盤位置に基づく距離ｉＫＤｉｓｔ＝｜ｐｓ２−ｐｓ１｜を算出する（ステップ９０２）。

ステップ７０３において算出されたｉＤｉｓｔ＜０である場合には（ステップ９０３でＹｅｓ）、ＣＰＵ１１は、指開きタイプ（ｉＳｐｒｅａｄＴｙｐｅ）という分類項目について、分類値ｉＳｐｒｅａｄＴｙｐｅとして、「ｉＳｐｒｅａｄＴｙｐｅ＝０」という値を与える（ステップ９０４）。なお、図９が実行されるときには、ｉＤｉｓｔ＞０であることが前提である（図８のステップ８０１参照）。したがって、これは実際には起こりえないことであるため、ステップ９０４はエラー処理となる。

ｉＫＤｉｓｔ＝ｉＭｉｎである場合（ステップ９０５でＹｅｓ）、ＣＰＵ１１は、指開きタイプ（ｉＳｐｒｅａｄＴｙｐｅ）という分類項目について、分類値ｉＳｐｒｅａｄＴｙｐｅとして、「ｉＳｐｒｅａｄＴｙｐｅ＝１」という値を与える（ステップ９０６）。ｉＭｉｎ＜ｉＫＤｉｓｔ≦ｉＬ１である場合（ステップ９０７でＹｅｓ）、ＣＰＵ１１は、指開きタイプ（ｉＳｐｒｅａｄＴｙｐｅ）という分類項目について、「ｉＳｐｒｅａｄＴｙｐｅ＝２」という値を与える（ステップ９０８）。ｉＫＤｉｓｔ＜ｉＭｉｎである場合（ステップ９０９でＹｅｓ）、ＣＰＵ１１は、指開きタイプ（ｉＳｐｒｅａｄＴｙｐｅ）という分類項目について、「ｉＳｐｒｅａｄＴｙｐｅ＝３」という値を与える（ステップ９１０）。

ｉＫＤｉｓｔ＜ｉＬ２である場合（ステップ９１１でＹｅｓ）、ＣＰＵ１１は、指開きタイプ（ｉＳｐｒｅａｄＴｙｐｅ）という分類項目について、「ｉＳｐｒｅａｄＴｙｐｅ＝４」という値を与える（ステップ９１２）。その一方、ｉＫＤｉｓｔ≧ｉＬ２である場合（ステップ９１１でＮｏ）、ＣＰＵ１１は、指開きタイプ（ｉＳｐｒｅａｄＴｙｐｅ）という分類項目について、「ｉＳｐｒｅａｄＴｙｐｅ＝５」という値を与える（ステップ９１３）。

指開き特定処理によって、ｉＫＤｉｓｔの値にしたがって、以下のようなｉＳｐｒｅａｄＴｙｐｅの値が付与される。

０≦ｉＫＤｉｓｔ＜Ｍｉｎ ｉＳｐｒｅａｄＴｙｐｅ＝３
ｉＫＤｉｓｔ＝ｉＭｉｎ ｉＳｐｒｅａｄＴｙｐｅ＝１
ｉＭｉｎ＜ｉＫＤｉｓｔ≦ｉＬ１ ｉＳｐｒｅａｄＴｙｐｅ＝２
ｉＬ１＜ｉＫＤｉｓｔ＜ｉＬ２ ｉＳｐｒｅａｄＴｙｐｅ＝４
ｉＬ２≦ｉＫＤｉｓｔ ｉＳｐｒｅａｄＴｙｐｅ＝５
指開き特定処理が終了すると、ＣＰＵ１１は、リバースタイプ（ＲｅｖＴｙｐｅ）という分類項目について、分類値ＲｅｖＴｙｐｅとして、「ＲｅｖＴｙｐｅ＝１」という分類値を与える（ステップ８０４）。その後、ＣＰＵ１１は、配列ｍｅ［］に格納された楽音データについて算出されたＰｏｓＴｙｐｅ、ｉＳｐｒｅａｄＴｙｐｅ、ＲｅｖＴｙｐｅおよびＴｅｃｈという分類値を、当該楽音データと関連付けて記憶装置（ＲＡＭ１３）に格納する（ステップ８０５）。

ステップ８０１でＮｏと判断された場合には、所定のテーブルｉＲＴｙｐｅ［］［］［］［］に基づいて、ＲｅｖＴｙｐｅ＝ｉＲＴｙｐｅ［ｐ２］［ｐ１］［ｆ２］［ｆ１］を取得する（ステップ８０６）。テーブルｉＲＴｙｐｅ［］［］［］［］は、隣接する音符について、指番号および音高に基づく値を含み、ＲＡＭ１３に格納される。

テーブルｉＲＴｙｐｅ［］［］［］［］における値について以下に簡単に説明する。テーブルｉＲｔｙｐｅ［］［］［］［］は、隣接する音符に配置すべき指の指番号および音高の関係に基づいて、運指における指くぐりや指返し（乗り越え）を示す情報を格納したテーブルである。本実施の形態において、ｉＤｉｓｔ≦０のときには、上行音形において、「１」より大きな指番号の指から指番号「１」の指に移行すること（いわゆる「指くぐり」）、或いは、下行音形において、指番号「１」の指から「１」より大きな指番号の指に移行すること（いわゆる「指返し」ないし「指の乗り越え」）が行なわれ得ることを意味している。

本実施の形態においては、指くぐりのとき、つまり、ｐ２＜ｐ１，ｆ２＞１、ｆ１＝１のときには、ｉＲＴｙｐｅ［ｐ２］［ｐ１］［ｆ２］［ｆ１］＝３となる。また、指返しのとき、つまり、ｐ２＞ｐ１、ｆ２＝１、ｆ１＞１のときには、ｉＲＴｙｐｅ［ｐ２］［ｐ１］［ｆ２］［ｆ１］＝２となる。一般的に、運指において、指返しより指くぐりの方が難しいといわれているため、指くぐりについて、ＲｅｖＴｙｐｅ＝３、指返しについてＲｅｖＴｙｐｅ＝２となるようにしている。

ステップ８０６の後、ＣＰＵ１１は、ポジションタイプ（ＰｏｓＴｙｐｅ）という分類項目について、「ＰｏｓＴｙｐｅ＝１」という分類値、指開きタイプ（ｉＳｐｒｅａｄＴｙｐｅ）という分類項目について、「ｉＳｐｒｅａｄＴｙｐｅ＝１」という分類値を与える（ステップ８０７）。その後、ＣＰＵ１１は、配列ｍｅ［］に格納された楽音データについて算出されたＰｏｓＴｙｐｅ、ｉＳｐｒｅａｄＴｙｐｅ、ＲｅｖＴｙｐｅおよびＴｅｃｈという分類値を、当該楽音データと関連付けて記憶装置（ＲＡＭ１３）に格納する（ステップ８０５）。

次に、２次元の運指難易度評価マップｉＦＭａｐ［ｉ］［ｊ］（ｉは分類項目、ｊは分類項目において付与された値）において、テクニック分類処理により得られた分類項目に対応する値をインクリメントする処理を実行する（図５のステップ５０６〜５１２）。本実施の形態においては、ポジションタイプ（ＰｏｓＴｙｐｅ）、指開きタイプ（ｉＳｐｒｅａｄＴｙｐｅ）、リバースタイプ（ＲｅｖＴｙｐｅ）、および、指使いテクニック（Ｔｅｃｈ）という４つの分類項目が存在する。したがって、２次元の運指難易度評価マップｉＦＭａｐ［ｉ］［ｊ］のそれぞれの要素は以下の分類項目に対応する。

ｉＦＭａｐ［０］［ｊ］：ｊが「ＰｏｓＴｙｐｅ」の値
ｉＦＭａｐ［１］［ｊ］：ｊが「ｉＳｐｒｅａｄＴｙｐｅ」の値
ｉＦＭａｐ［２］［ｊ］：ｊが「ＲｅｖＴｙｐｅ」の値
ｉＦＭａｐ［３］［ｊ］：ｊが「Ｔｅｃｈ」の値
なお、以下のステップ５０６、５０８、５１０、５１２から理解できるように、ｊ＝０、２のときの値は存在せず、ｊ＞１のみについて値を有する。

ＣＰＵ１１は、ＰｏｓＴｙｐｅ＞１である場合には（ステップ５０６でＹｅｓ）、対応する運指難易度評価マップの値であるｉＦＭａｐ［０］［ＰｏｓＴｙｐｅ］をインクリメントする（ステップ５０７）。また、ＣＰＵ１１は、ｉＳｐｒｅａｄＴｙｐｅ＞１である場合には（ステップ５０８でＹｅｓ）、対応する運指難易度評価マップの値であるｉＦＭａｐ［１］［ｉＳｐｒｅａｄＴｙｐｅ］をインクリメントする（ステップ５０９）。ＣＰＵ１１は、ＲｅｖＴｙｐｅ＞１である場合には（ステップ５１０でＹｅｓ）、対応する運指難易度評価マップの値であるｉＦＭａｐ［２］［ＲｅｖＴｙｐｅ］をインクリメントする（ステップ５１１）。さらに、ＣＰＵ１１は、Ｔｅｃｈ＞１である場合には（ステップ５１２でＹｅｓ）、対応する運指難易度評価マップの値であるｉＦＭａｐ［３］［Ｔｅｃｈ］をインクリメントする（ステップ５１３）。

次いで、ＣＰＵ１１は、ノート数（音符数）を示すパラメータｉＣｎｔをインクリメントして（ステップ５１４）、配列ｍｅ［］に、次の楽音データのレコードを格納し（ステップ５１５）、その後、ステップ５０３に戻る。

ステップ５０３でＹｅｓと判断された場合には、ＣＰＵ１１は、ステップ５０７、５０９、５１１および５１３でマップ値がインクリメントされた運指難易度評価マップｉＦＭａｐ［］［］を、楽曲を特定する情報と関連付けて、記憶装置（たとえばＲＡＭ１３）に格納する（ステップ５１６）。この楽曲を特定する情報と関連付けられた運指難易度評価マップｉＦＭａｐ［］［］は、後述する習得楽曲対応処理（図２のステップ２０８）において参照される。

次いで、ＣＰＵ１１は、パラメータｉおよびｉＦＣｏｓｔを「０」に初期化する（ステップ６０１）。ＣＰＵ１１は、パラメータｉが「４」以上であるかを判断する（ステップ６０２）。上記パラメータｉは、ｉＦＭａｐ［ｉ］［ｊ］の「ｉ」を特定するためのものである。ステップ６０２でＮｏと判断された場合には、ＣＰＵ１１は、パラメータｊを「０」に初期化して（ステップ６０３）、ｊが所定数より大きくなるまで（ステップ６０４）、ステップ６０５〜６０８の処理を繰り返す。

ＣＰＵ１１は、運指難易度評価マップの値ｉＦＭａｐ［ｉ］［ｊ］が「０」より大きいかを判断する（ステップ６０５）。ステップ６０５でＹｅｓと判断された場合には、ＣＰＵ１１は、操作者（演奏者）の楽曲習得度マップのマップ値ｉＦＭａｐＡｂｌ［ｉ］［ｊ］が「０」であるかを判断する（ステップ６０６）。この楽曲習得度マップｉＦＭａｐＡｂｌ［］［］は、分類項目の具体的態様ごとに、操作者（演奏者）が、当該分類項目の具体的態様にかかる技術の習得が行なわれているか否かを示すマップである。

楽曲習得度マップｉＭａｐＡｂｌ［］［］は、操作者（演奏者）ごとに設けられ、マップ値がＲＡＭ１３に格納される。楽曲習得度マップｉＦＭａｐＡｂｌ［］［］の生成については後に詳説する。

楽曲習得度マップｉＦＭａｐＡｂｌ［ｉ］［ｊ］＝１であることは、分類項目「ｉ」における分類値［ｊ］で特定される具体的態様については、操作者（演奏者）が習得済みであることを示す。たとえば、ｉＦＭａｐＡｂｌ［０］［２］＝１であれば、ポジションタイプ（ＰｏｓＴｙｐｅ）という分類項目について、分類値が「２」（ＰｏｓＴｙｐｅ＝２）であるような具体的態様については操作者（演奏者）が習得済みであることを示す。

後に詳述するが、本実施の形態においては、操作者（演奏者）が、ある分類項目の具体的態様について既に習得している場合には、当該分類項目の具体的態様についてのコスト値ｉＦＣｏｓｔ［ｉ］［ｊ］を加算しない。すなわち、操作者（演奏者）は、当該具体的態様について習得済みであるため、当該具体的態様は、その操作者（演奏者）にとっての楽曲難易度には影響を与えないからである。

ステップ６０６でＹｅｓと判断された場合には、ＣＰＵ１１は、運指難易度評価マップの値ｉＦＭａｐ［ｉ］［ｊ］に対応付けられたコスト値ｉＦＣｏｓｔ［ｉ］［ｊ］を、運指難易度の値ｉＦＣｏｓｔに加算する（ステップ６０７）。

以下、コスト値ｉＦＣｏｓｔ［ｉ］［ｊ］を格納したコストテーブル（ｉＦＣｏｓｔ［］［］［］）について説明する。コストテーブルは、コスト値ｉＦＣｏｓｔ［ｉ］［ｊ］のそれぞれに対応する、「ｉ×ｊ」個のコスト値ｉＦＣｏｓｔ［ｉ］［ｊ］を格納している。たとえば、ｉＦＣｏｓｔ［０］［ｊ］は、テクニック分類処理（図８）のステップ８０２で取得された「ＰｏｓＴｙｐｅ」の値のそれぞれに対応するコスト値であり、ポジションタイプのそれぞれの値に固有の値となっている。ｉ＝１以上の他のコスト値も同様である。

本実施の形態においては、ポジションタイプ「ＰｏｓＴｙｐｅ」、指開きタイプ「ｉＳｐｒｅａｄＴｙｐｅ」、リバースタイプ「ＲｅｖＴｙｐｅ」および指使いテクニック「Ｔｅｃｈ」のそれぞれにおいて、値が大きくなるのにしたがって、それぞれの分類項目において運指の困難度が高まるようになっている。したがって、コスト値ｉＦＣｏｓｔ［ｉ］［ｊ］も、ｊが増大するのにしたがって、コスト値が増大するようになっている。

また、本実施の形態においては，運指難易度評価マップの値ｉＦＭａｐ［ｉ］［ｊ］が幾つであるかは考慮せず、０より大きければ（すなわち１以上であれば）、コスト値ｉＦＣｏｓｔ［ｉ］［ｊ］を、運指難易度の値ｉＦＣｏｓｔに加算している。すなわち、運指難易度評価マップの値の多寡にかかわらず、加算される値はコスト値ｉＦＣｏｓｔ［ｉ］［ｊ］である。これは、分類項目「ｉ」（例えば、ポジションタイプや指開きタイプ）において、ｉＦＭａｐ［ｉ］［ｊ］において１より大きい値を有する音符が１つあれば、その場合には、当該ｉＦＭａｐ［ｉ］［ｊ］に対応する難易度を含むため、そのノートの数は、難易度を示すコスト値にそれほど大きく影響しないであろうという知見に基づく。

無論、運指難易度評価マップの値ｉＦＭａｐ［ｉ］［ｊ］に応じて、加算されるｉＦＣｏｓｔ［ｉ］［ｊ］に重みを与えても良い。つまりこの場合には、
ｉＣｏｓｔ＝ｉＣｏｓｔ＋
ｆ（ｉＦＣｏｓｔ［ｉ］［ｊ］）×ｉＦＣｏｓｔ［ｉ］［ｊ］
となる。ここで、ｆ（ｉＦＣｏｓｔ［ｉ］［ｊ］）は、変数ｉＦＣｏｓｔ［ｉ］［ｊ］が増大するのにしたがって増大するが、変数ｉＦＣｏｓｔ［ｉ］［ｊ］が増大するのにしたがって、関数値ｆの増分は小さくなっていく関数である。たとえば、ｆとして対数関数を使用しても良い。

ステップ６０５でＮｏと判断された場合、ステップ６０６でＮｏと判断された場合、或いは、ステップ６０７が実行された後、ＣＰＵ１１は、ｊをインクリメントして（ステップ６０８）、ステップ６０４に戻る。また、ステップ６０４でＹｅｓと判断された場合には、ＣＰＵ１１は、ｉをインクリメントして（ステップ６０９）、ステップ６０２に戻る。

このように本実施の形態においては、楽曲に含まれるあるノートが、運指に関する分類項目の具体的態様についてのマップ値ｉＦＭａｐ［ｉ］［ｊ］が「０」でない場合には、当該分類項目の具体的態様に対応するコスト値ｉＦＣｏｓｔ［ｉ］［ｊ］が、運指難易度ｉＦＣｏｓｔに加算される。

次に、リズム難易度評価処理について説明する。図１０および図１１は、本実施の形態にかかるリズム難易度評価処理の例を示すフローチャートである。図１０に示すように、ＣＰＵ１１は、ＲＡＭ１３の楽曲データ中、最初の楽音データのレコードＮｏｔｅ［０］を、配列ｍｅ［］に格納する（ステップ１００１）。ＣＰＵ１１は、楽曲データにおいて全ての楽音データのレコードについて処理が終了するまで（ステップ１００２でＹｅｓ）、ステップ１００３〜１００７を繰り返す。

ＣＰＵ１１は、ＲＡＭ１３に格納された、リズム評価処理用のパラメータ（リズムパラメータ）を取得する（ステップ１００３）。リズムパラメータには、１小節の長さを示すｉＭｅａｓＬｅｎ、リズムの分解能を示すＲｅｓｏｌｕｔｉｏｎなどが含まれ、これらは、次のリズムコスト算出処理において利用される。ＣＰＵ１１は、リズムコスト算出処理を実行する（ステップ１００４）。図１２および図１３は、本実施の形態にかかるリズムコスト算出処理の例を示すフローチャートである。リズムコスト算出処理においては、音符の音符長（次の音符までの間隔に基づく音符長）に相当する分類項目であるステップタイム（ｉＳｔｅｐＴｉｍｅ）についての分類値と、音符の小節中の位置に相当する分類項目であるポジション（ｉＰｏｓ）についての分類値とが得られる。

図１２に示すように、ＣＰＵ１１は、配列ｍｅ［］に示す楽音データのレコードの、次のレコードを参照して、その発音時刻Ｔｉｍｅを取得する（ステップ１２０１）。次いで、ＣＰＵ１１は、配列ｍｅ［］中の発音時刻Ｔｉｍｅと、ステップ１２０１で取得した次の発音データのレコードにおける発音時刻Ｔｉｍｅとに基づいて、次の音符までの間隔ｉＴを算出する（ステップ１２０２）。ＣＰＵ１１は、時間間隔ｉＴと、１小節の長さｉＭｅａｓＬｅｎとに基づいて、上記時間間隔の小節内での音符長ｉＳｔｅｐＴｉｍｅを算出する（ステップ１２０３）。得られたｉＳｔｅｐＴｉｍｅが、音符長という分類項目についての分類値となる。

本実施の形態において、音符長ｉＳｔｅｐＴｉｍｅは以下のように求められる。

ｉＳｔｅｐＴｉｍｅ＝３２×ｉＴ／ｉＭｅａｓＬｅｎ
本実施の形態においては、楽曲は４／４拍子としており、ｉＳｔｅｐＴｉｍｅは、ｉＴが３２分音符いくつ分に相当するかを示している。

次いで、ＣＰＵ１１は、配列ｍｅ［］中の発音時刻Ｔｉｍｅに基づき、小節内の音符位置ｉＴｉｃｋＩｎＭｅａｓ、拍内での音符位置ｉＴｉｃｋＩｎＢｅａｔおよび当該音符の属する拍ｉＢｅａｔを算出する（ステップ１３０４）。ｉＴｉｃｋＩｎＭｅａｓは、１小節を３２分割したときの音符の位置、つまり、小節の先頭から３２分音符でいくつ目に位置しているかを示す。また、ｉＴｉｃｋＩｎＢｅａｔは、拍の先頭から３２分音符でいくつ目に位置しているかを示す。

ＣＰＵ１１は、パラメータｉおよびｉＰｏｓを「０」に初期化して（ステップ１２０５）、ｉが８未満である限り（ステップ１２０６でＹｅｓ）、ステップ１２０７から１２１０の処理を実行する。ＣＰＵ１１は、ｉＴｉｃｋＩｎＢｅａｔの位置を特定するために、ａ＝ｉＴｉｃｋＩｎＢｅａｔ−ｉＲｅｓｏｌｕｔｉｏｎ×ｉ／８を算出する（ステップ１２０７）。ここで、ｉＴｉｃｋＩｎＢｅａｔは、「０」〜「７」の何れかの値をとる。したがって、いずれかのｉについて、ａ＝０となり、次のステップ１２０８でＹｅｓと判断される。ステップ１２０８でＮｏと判断された場合には、ＣＰＵ１１は、パラメータｉをインクリメントして（ステップ１２０９）、ステップ１２０６に戻る。ステップ１２０８でＹｅｓと判断された場合には、ＣＰＵ１１は、パラメータｉＰｏｓ＝ｉとする（ステップ１２１０）。

ステップ１２０６でＮｏと判断された場合、或いは、ステップ１２１０の処理が終了した後、図１３のステップ１３０１に進む。なお、本実施の形態においては、ステップ１２０４においてｉＴｉｃｋＩｎＢｅａｔの算出の際に、３２分音符の分解能にクォンタイズされる。したがって、ステップ１２１０においてＮｏと判断されることは本来ありえない。したがって、この場合は、演算において何らかのエラーが生じたことになる。

このようにして得られたｉＰｏｓは、音符が、拍の頭から３２分音符で何番目の位置にあるかを示すものである。これをそのまま使って良いが、本実施の形態においては、小節の先頭、小節の中央および拍の先頭として、ｉＰｏｓとして異なる値を与える。ｉＴｉｃｋＩｎＭｅａｓ＝０の場合、すなわち、音符が拍の先頭に位置している場合には（ステップ１３０１でＹｅｓ）、ＣＰＵ１１は、ｉＰｏｓ＝３２とする（ステップ１３０２）。また、ｉＴｉｃｋＩｎＢｅａｔ＝０かつｉＢｅａｔ＝２、つまり、音符が３拍目の先頭（小節の中央）に位置している場合には（ステップ１３０３でＹｅｓ）、ＣＰＵ１１は、ｉＰｏｓ＝１６とする（ステップ１３０４）。さらに、ｉＴｉｃｋＩｎＢｅａｔ＝０、つまり、音符が２拍目或いは４拍目の先頭に位置している場合には（ステップ１３０５でＹｅｓ）、ＣＰＵ１１は、ｉＰｏｓ＝８とする（ステップ１３０６）。

リズムコスト算出処理によって得られる分類項目の１つであるポジション（ｉＰｏｓ）の分類値は、音符の小節中の位置によって以下のような値をとる。

音符の位置が、小節の先頭：ｉＰｏｓ＝３２
音符の位置が、３拍目の先頭：ｉＰｏｓ＝１６
音符の位置が、他の拍（２拍目、４拍目）の先頭：ｉＰｏｓ＝８
音符の位置が他の場合：ｉＰｏｓ＝拍を８等分した場合の位置を示す値
上記ｉＰｏｓは、楽曲が４／４拍子の場合の例であり、他の拍子（たとえば、３／４）の場合には、ｉＰｏｓは異なる。楽曲が３／４拍子であれば、分類値「ｉＰｏｓ」は以下の値をとり得る。

音符の位置が、小節の先頭：ｉＰｏｓ＝３２
音符の位置が、他の拍（２拍目、３拍目）の先頭：ｉＰｏｓ＝８
音符の位置が他の場合：ｉＰｏｓ＝拍を８等分した場合の位置を示す値
リズムコスト算出処理が終了すると、ＣＰＵ１１は、２次元のリズム難易度評価マップの値であるｉＲＭａｐ［０］［ｉＳｔｅｐＴｉｍｅ］をインクリメントする（ステップ１００５）とともに、ｉＲＭａｐ［１］［ｉＰｏｓ］をインクリメントする（ステップ１００６）。その後、ＣＰＵ１１は、配列ｍｅ［］に、次の楽音データのレコードを格納し（ステップ１００７）、その後、ステップ１００２に戻る。

ステップ１００２でＹｅｓと判断された場合には、ＣＰＵ１１は、パラメータｉおよびｉＲＣｏｓｔを「０」に初期化する（ステップ１１０１）。ＣＰＵ１１は、パラメータｉが「２」以上であるかを判断する（ステップ１１０２）。上記パラメータｉは、ｉＲＭａｐ［ｉ］［ｊ］の「ｉ」を特定するためのものである。ステップ１１０２でＮｏと判断された場合には、パラメータｊを「０」に初期化して（ステップ１１０３）、ｊが所定数より大きくなるまで（ステップ１１０４）、ステップ１１０５〜１１０７の処理を繰り返す。

ＣＰＵ１１は、リズム難易度評価マップの値ｉＲＭａｐ［ｉ］［ｊ］が「０」より大きいかを判断する（ステップ１１０５）。ステップ１１０５でＹｅｓと判断された場合には、ＣＰＵ１１は、リズム難易度評価マップの値ｉＲＭａｐ［ｉ］［ｊ］に対応付けられたコスト値ｉＲＣｏｓｔ［ｉ］［ｊ］を、運指難易度の値ｉＲＣｏｓｔに加算する（ステップ１１０６）。

以下、コスト値ｉＲＣｏｓｔ［ｉ］［ｊ］を格納したコストテーブルｉＲＣｏｓｔ［］［］について説明する。運指難易度についてのコスト値ｉＲ［ｉ］［ｊ］を格納したコストテーブルと同様に、コストテーブルｉＲＣｏｓｔ［］［］は、コスト値ｉＲＣｏｓｔ［ｉ］［ｊ］のそれぞれに対応する、「ｉ×ｊ」個のコスト値ｉＲＣｏｓｔ［ｉ］［ｊ］を格納している。たとえば、ｉＲＣｏｓｔ［０］［ｊ］は、リズムコスト算出処理（図１２）のステップ１２０３で取得された音符長ｉＳｔｅｐＴｉｍｅのそれぞれに対応するコスト値であり、音符長のそれぞれに固有の値となっている。また、ｉＲＣｏｓｔ［１］［ｊ］は、ステップ１２１０、ステップ１３０２、１３０４、１３０６で得られた拍内の音符位置ｉＰｏｓのそれぞれに対応するコスト値であり、音符位置のそれぞれに固有の値となっている。

たとえば、ｉＲＣｏｓｔ［０］［ｉＳｔｅｐＴｉｍｅ］においては、ｉＳｔｅｐＴｉｍｅ＝３２、１６、８、４、および、それら以外の値、について、コスト値ｉＲＣｏｓｔ［０］［ｉＳｔｅｐＴｉｍｅ］が増大するようになっている。つまり、音符長が、全音符であるとき、そのコスト値ｉＲＣｏｓｔ［０］［３２］がもっとも小さく、２分音符、４分音符、８分音符、その他の音符となるのにしたがって、コスト値は大きくなる。

また、ｉＲＣｏｓｔ［１］［ｉＰｏｄ］においても、ｉＰｏｓ＝３２、１６、８、それら以外の値、について、コスト値ｉＲＣｏｓｔ［１］［ｉＰｏｓ］が増大するようになっている。つまり、音符が小節の先頭に位置するとき、そのコスト値ｉＲＣｏｓｔ［１］［３２］がもっとも小さく、３拍目の先頭、２拍目或いは４拍目の先頭、その他の位置となるのにしたがって、コスト値は大きくなる。

運指難易度コストの算出と同様に、リズム難易度評価マップの値ｉＲＭａｐ［ｉ］［ｊ］が幾つであるかは考慮せず、０より大きければ（すなわち１以上であれば）、コスト値ｉＲＣｏｓｔ［ｉ］［ｊ］を、リズム難易度の値ｉＲＣｏｓｔに加算している。すなわち、リズム難易度評価マップの値の多寡にかかわらず、加算される値はコスト値ｉＲＣｏｓｔ［ｉ］［ｊ］である。

ステップ１１０５でＮｏと判断された場合、或いは、ステップ１１０６が実行された後、ＣＰＵ１１は、ｊをインクリメントして（ステップ１１０７）、ステップ１１０４に戻る。また、ステップ１１０４でＹｅｓと判断された場合には、ＣＰＵ１１は、ｉをインクリメントして（ステップ１１０８）、ステップ１１０２に戻る。

このように本実施の形態においては、音符についてのリズム、特に、音符長および音符位置のそれぞれについて、対応するコスト値ｉＲＣｏｓｔ［ｉ］［ｊ］が、リズム難易度ｉＲＣｏｓｔに加算される。

次に、本実施の形態にかかる調性難易度評価処理について説明する。図１４および図１５は、本実施の形態にかかる調性難易度評価処理の例を示すフローチャートである。図１５に示すように、ＣＰＵ１１は、配列ｍｅ［］に先頭の楽音データのレコードを格納する（ステップ１４０１）。ＣＰＵ１１は、楽曲データにおいて全ての楽音データのレコードについて処理が終了するまで（ステップ１４０２でＹｅｓ）、ステップ１４０３、１４０４を繰り返す。

ＣＰＵ１１は、配列ｍｅ［］中の音高情報「Ｐｉｔ」に基づいて、カウント値ｉＰＣ［Ｐｉｔ ｍｏｄ １２］をインクリメントする（ステップ１４０３）。ステップ１４０３においては、音符の、ＣからＢまでの何れかの音名に対応するカウント値ｉＰＣがインクリメントされる。次いで、ＣＰＵ１１は、配列ｍｅ［］に次の楽音データのレコードを格納して（ステップ１４０４）、ステップ１４０２に戻る。ステップ１４０２〜１４０４の処理によって、楽曲に含まれるノート（音符）の音名のそれぞれについて、累算値を格納した配列ｉＰＣ［］が取得される。

ステップ１４０２でＹｅｓと判断された場合には、ＣＰＵ１１は、パラメータｉＴｏｎａｌｉｔｙ、ｉＭａｘ，ｉＡＴＭａｘおよびｉを「０」に初期化する（ステップ１４０５〜１４０７）。ＣＰＵ１１は、パラメータｉが１２以上になるまで（ステップ１４０８でＮｏ）、図１５のステップ１５０１〜１５１２を実行する。

図１５に示すように、ＣＰＵ１１は、パラメータｉＳｕｍおよびｉＡＴｏｎａｌｉｔｙを「０」に初期化する。ここに、ｉＳｕｍは、楽曲が含んでいたノート（音符）の音名の累算値と、各調の長音階との一致度を示すパラメータであり、ｉＡＴｏｎａｌｉｔｙは、上記音名の累算値と、各調の長音階との不一致度を示すパラメータである。なお、本実施の形態においては、長音階の楽曲について、各調の長音階との一致度、不一致度を見出しているが、これに限定されるものではない。短音階の楽曲については、各調の短音階との一致度や不一致度を見出せば良い。

ＣＰＵ１１は、パラメータｊを「０」に初期化して（ステップ１５０４）、ｉＳｕｍに、ｉＰＣ［（ｊ＋ｉ） ｍｏｄ １２］×ｉＢａｓｅＳｃａｌｅ［ｊ］を加算する。また、ＣＰＵ１１は、ｉＡＴｏｎａｌｉｔｙに、ｉＰＣ［（ｊ＋ｉ） ｍｏｄ １２］×ｉＡＴｏｎａｌ［ｊ］を加算する（ステップ１５０５）。その後、ＣＰＵ１１はｊをインクリメントしてステップ１５０３に戻る。

図１７（ａ）は、本実施の形態にかかるベーススケール配列ｉＢａｓｅＳｃａｌｅ［］の例を示す図である。図１７（ａ）に示すように、ｉＢａｓｅＳｃａｌｅ［］（符号１７０１）は、１１個の要素（ｊ＝０〜１１）を有し、長音階の音名に相当する要素（ｊ＝０、２、４、５、７、９、１１）が「１」となり、それ以外が「０」となっている。なお、図１７（ａ）において、配列の要素の上に配置された数字、♭（フラット）、＃（シャープ）は、最も左のｊ＝０の要素（根音）に対する間隔（度）を示している。また、図１７（ｂ）は、本実施の形態にかかる非ベーススケール配列ｉＡＴｏｎａｌ［］の例を示す図である。ｉＡＴｏｎａｌ［］（符号１７０２参照）は、ｉＢａｓｅＳｃａｌｅ［］１７０１と同様に、１１個の要素（ｊ＝０〜１１）を有し、その値は、ｉＢａｓｅＳｃａｌｅと逆となっている。すなわち、長音階の音名に該当しない要素（ｊ＝１、３、６、８、１０）が「１」となり、それ以外が「０」となっている。

以下、ステップ１５０４における、ｉＳｕｍに加算される値ｉＰＣ［（ｊ＋ｉ） ｍｏｄ １２］×ｉＢａｓｅＳｃａｌｅ［ｊ］について説明する。たとえば、図１８において、符号１８０１は、ステップ１４０２〜１４０４で得られた配列ｉＰＣ［］の例を示す図、符号１８０２は、ベーススケール配列ｉＢａｓｅＳｃａｌｅ［］の例を示す図である。

ｉＰＣ［ｊ＋ｉ ｍｏｄ １２］×ｉＢａｓｅＳｃａｌｅ［ｊ］において、ｉ＝０のときには、ｊ＝０、２、４、５、７、９において、０以外の値をとり、全てのｊについて処理が実行された場合のｉＳｕｍの最終値は、
ｉＳｕｍ＝Σ（ｉＰＣ［ｊ ｍｏｄ １２］×ｉＢａｓｅＳｃａｌｅ［ｊ］）
＝７＋２＋３＋１０＋４＋５＝３１となる。

ｉ＝１のときには、ｊ＝４、５、９、１１において、０以外の値をとり、全てのｊについて処理が実行された場合のｉＳｕｍの最終値は、
ｉＳｕｍ＝１＋３＋５＋８＝１７となる。

また、ｉ＝５のときには、ｊ＝０、２、４、５、７、９、２２において、０以外の値をとり、全てのｊについて処理が実行された場合のｉＳｕｍの最終値は、
ｉＳｕｍ＝１０＋４＋５＋８＋７＋２＋３＝３９となる。

さらに、ｉ＝７のときには、ｊ＝０、２、５、７、９において、０以外の値をとり、全てのｊについて処理が実行された場合のｉＳｕｍの最終値は、
ｉＳｕｍ＝４＋５＋７＋２＋３＝２２となる。

ｉＡＴｏｎａｌｉｔｙにｉＰＣ（ｊ＋ｉ ｍｏｄ １２）×ｉＡＴｏｎａｌ［ｊ］を加算する演算も、ｉＳｕｍの演算と同様に実行され得る。

図１９において、符号１９０１は、ステップ１４０２〜１４０４で得られた配列ｉＰＣ［］の例を示す図、符号１９０２は、非ベーススケール配列ｉＡＴｏｎｌｉｔｙ［］の例を示す図である。配列ｉＰＣ［］は、図１８の符号１８０１と同様である。

ｉ＝０のときには、ｉＡＴｏｎａｌｉｔｙの最終値
ｉＡＴｏｎａｌｉｔｙ＝Σ（ｉＰＣ［ｊ ｍｏｄ １２］×ｉＡＴｏｎａｌ［ｊ］
＝１＋５＋８＝１４となる。

また、ｉ＝１のときのｉＡＴｏｎａｌｉｔｙの最終値は、
ｉＡＴｏｎａｌｉｔｙ＝７＋２＋１０＋４＋５＝２８（符号１９０３参照）
ｉ＝５のときのｉＡＴｏｎａｌｉｔｙの最終値は、
ｉＡＴｏｎａｌｉｔｙ＝５＋１＝６（符号１９０４参照）
ｉ＝７のときのｉＡＴｏｎａｌｉｔｙの最終値は、
ｉＡＴｏｎａｌｉｔｙ＝５＋８＋１＋１０＝２４（符号１９０５参照）となる。

ステップ１５０３でＮｏと判断された場合、つまり、特定のｉについて、ｊ＝０〜１１のｉＳｕｍおよびｉＡＴｏｎａｌｉｔｙが算出された場合には、ＣＰＵ１１は、一致度ｉＳｕｍと不一致度ｉＡＴｏｎａｌｉｔｙの差分値ａ（＝ｉＳｕｍ−ｉＡＴｏｎａｌｉｔｙ）を算出する（ステップ１５０７）。

ＣＰＵ１１は、ステップ１５０７において得られた差分値ａが、ＲＡＭ１３に記憶された差分値ａの最大値ｉＭａｘより大きいかを判断する（ステップ１５０８）。ステップ１５０８でＹｅｓと判断された場合には、ＣＰＵ１１は、差分値ａを最大値ｉＭａｘとしてセットし（ステップ１５０９）、かつ、最大値ｉＭａｘを得たときの調性を示すパラメータｉＴｏｎａｌｉｔｙにｉをセットする（ステップ１５１０）。また、ＣＰＵ１１は、得られた不一致度ｉＡＴｏｎａｌｉｔｙを、ｉＳｕｍの最大値が得られたときの対応する不一致度ｉＡＴＭａｘとしてセットする（ステップ１５１１）。

ステップ１５０８でＮｏと判断された場合、または、ステップ１５１１が実行された後に、ＣＰＵ１１は、ｉをインクリメントして、ステップ１４０８に戻る。ステップ１４０８でＮｏと判断された場合には、ＣＰＵ１１は、調性難易度を示すｉＴＣｏｓｔを以下のように算出する（ステップ１４０９）。

ｉＴＣｏｓｔ＝（ｉＡＴＭａｘ×Ａ）／ｉＭａｘ
ここに、Ａは所定の定数である。したがって、ｉＴＣｏｓｔは、調性の一致度が最大となったときの、音符の音階との一致度ｉＳｕｍとそのときの不一致度ｉＡＴｏｎａｌｉｔｙとの差分値に対する、そのときの不一致度の比に、定数Ａを乗じたものとなる。

先に説明したように、運指難易度ｉＦＣｏｓｔ、リズム難易度ｉＲＣｏｓｔおよび調性難易度ｉＴＣｏｓｔが算出されると、これら難易度および楽曲のノート数ｉＣｎｔに基づいて、以下のように楽曲の難易度ｉＣｏｓｔが算出される。

ｉＣｏｓｔ＝ｉＦＣｏｓｔ×ＲＦ＋ｉＲＣｏｓｔ×ＲＲ
＋ｉＴＣｏｓｔ×ＲＴ＋ｉＣｎｔ×ＲＣ
次に、本実施の形態にかかる難易度表示処理について説明する。難易度評価処理（ステップ２０５）が終了し、新たな楽曲指定の入力が無かった場合（ステップ２０３でＮｏ）、ＣＰＵ１１は、難易度表示処理を実行する（ステップ２０６）。難易度表示処理では、難易度ｉＣｏｓｔが算出された楽曲について、音符ごとに対応する難易度を示す印を付した楽譜を生成して、表示装置１６の画面上に表示する。本実施の形態においては、音符ごとの運指難易度を楽譜上に示している。

図２０は、本実施の形態にかかる難易度表示処理の例を示すフローチャートである。図２０に示すように、ＣＰＵ１１は、配列ｍｅ［］に先頭の楽音データのレコードを格納する（ステップ２００１）。ＣＰＵ１１は、楽曲データにおいて全ての楽音データのレコードについて処理が終了するまで（ステップ２００２でＹｅｓ）、ステップ２００３〜２００９を繰り返す。

ＣＰＵ１１は、配列ｍｅ［］中の音高情報「Ｐｉｔ」、発音時刻「Ｔｉｍｅ」および発音時間「Ｇａｔｅ」に基づいて、画像において、五線譜中の所定の位置に所定の音長の音符を配置する（ステップ２００３）。また、ＣＰＵ１１は、配列ｍｅ［］中の運指情報「Ｆｉｇ」に基づいて、画像において、音符の上部に指番号を配置する（ステップ２００４）。次いで、ＣＰＵ１１は、ｍｅ［］で特定される楽音データに関連付けられて、ＲＡＭ１３に記憶されたポジションタイプ（ＰｏｓＴｙｐｅ）、指開きタイプ（ｉＳｐｒｅａｄＴｙｐｅ）、リバースタイプ（ＲｅｖＴｙｐｅ）、指使いテクニック（Ｔｅｃｈ）のそれぞれの分類項目についての分類値を取得する（ステップ２００５）。

次いで、ＣＰＵ１１は、それぞれの値の何れかが「１」より大きいかを判断する（ステップ２００６）。ステップ２００６でＹｅｓと判断された場合には、ＣＰＵ１１は、該当する分類項目を示す印を、音符の上部に配置する（ステップ２００７）。たとえば、ＰｏｓＴｙｐｅ＞１であれば「Ｐ」、ｉＳｐｒｅａｄＴｙｐｅ＞１であれば「Ｓ」、ＲｅｖＴｙｐｅ＞１であれば「Ｒ」、Ｔｅｃｈ＞１であれば「Ｔ」という印が、画像において音符の上部に配置される。

さらに、ＣＰＵ１１は、音符に印が付された分類項目に対応する色彩を付与する（ステップ２００８）。たとえば、ＰｏｓＴｙｐｅ＞１であれば赤、ｉＳｐｒｅａｄＴｙｐｅ＞１であれば水色、ＲｅｖＴｙｐｅ＞１であれば黄緑、Ｔｅｃｈ＞１であれば桃色という色彩が音符に付与される。なお、ＰｏｓＴｙｐｅおよびｉＳｐｒｅａＴｙｐｅの双方とも、１より大きい値を持っていた場合には、ＰｏｓＴｙｐｅについてのコスト値ｉＦＣｏｓｔ［０］［ＰｏｓＴｙｐｅ］と、ｉＳｐｒｅａｄＴｙｐｅについてのコスト値ｉＦｃｏｓｔ［１］［ｉＳｐｒｅａｄＴｙｐｅ］とを比較して、コスト値の大きい方の分類項目に対応する色彩が選択される。

その後、ＣＰＵ１１は、配列ｍｅ［］に次の楽音データのレコードを格納して（ステップ２００９）、ステップ２００２に戻る。

図２１は、本実施の形態にかかる難易度表示処理により生成された楽譜の画像の例を示す図である。図２１に示すように、楽曲を構成する音符の上部には、１〜５の指番号が表示されるとともに、特定の音符においては、分類項目に対応する印（「Ｐ」、「Ｓ」、「Ｒ」、「Ｔ」）が音符の上部に付加されている。また、図２１では表われていないが、印「Ｔ」が付された音符（たとえば、第２小節第３拍の「Ｇ４」）には、対応する色彩である桃色が付されている。同様に、印「Ｓ」が付された音符（たとえば、第３小節第１拍の「Ｅ５」）には、対応する色彩である水色が付され、印「Ｒ」が付された楽譜（たとえば、第７小節第１拍の「Ｆ＃４」、第２拍の「Ｇ４」）には、対応する色彩である黄緑色が付される。

さらに、印「Ｓ」および「Ｐ」の双方が付されている音符（たとえば、第３小節の第３．５拍の「Ｆ＃５」、第４小節の第１拍の「Ｇ５」）においては、コスト値の大きい方の分類項目（この場合には、ＰｏｓＴｙｐｅ）の色彩（この場合には、赤色）が付される。

次に、本実施の形態にかかる習得楽曲対応処理（図２のステップ２０８）についてより詳細に説明する。図２２は、本実施の形態にかかる習得楽曲対応処理の例を示すフローチャートである。図２２に示すように、ＣＰＵ１１は、ステップ２０７で指定された楽曲に関連付けられた運指難易度評価マップｉＦＭａｐ［］［］を、ＲＡＭ１３から読み出す（ステップ２２０１）。次いで、ＣＰＵ１１は、操作者（演奏者）固有の楽曲習得度マップｉＦＭａｐＡｂｌ［］［］が、ＲＡＭ１３に格納されているかを判断する（ステップ２２０２）。たとえば、操作者（演奏者）の情報は、上記ステップ２０７の楽曲指定において、楽曲を指定する情報と共に入力されれば良い。

ステップ２２０２でＹｅｓと判断された場合には、ＣＰＵ１１は、ＲＡＭ１３に格納された、当該操作者（演奏者）に固有の楽曲習得度マップｉＦＭａｐＡｂｌ［］［］を読み出す（ステップ２２０３）。ステップ２２０２でＮｏと判断された場合には、ＲＡＭ１３に新規の楽曲習得度マップｉＦＭａｐＡｂｌ［］［］を生成する。なお、新規の楽曲習得度マップのマップ値ｉＦＭａｐＡｂｌ［ｉ］［ｊ］は、全て「０」である。

次いで、ＣＰＵ１１は、パラメータｉを初期化して（ステップ２２０５）。パラメータｉが「４」以上であるかを判断する（ステップ２２０６）。ステップ２２０６でＹｅｓと判断された場合には処理を終了する。その一方、ステップ２２０６でＮｏと判断された場合には、ＣＰＵ１１は、パラメータｊを「０」に初期化して（ステップ２２０７）、ｊが所定数より大きくなるまで（ステップ２２０８）、ステップ２２０９〜２２１１を繰り返す。

ＣＰＵ１１は、楽曲に関連付けられた運指難易度評価マップｉＦＭａｐ［］［］のマップ値ｉＦＭａｐ［ｉ］［ｊ］が「０」より大きいかを判断する（ステップ２２０９）。ステップ２２０９でＹｅｓと判断された場合には、ＣＰＵ１１は、楽曲習得度マップｉＦＭａｐＡｂｌ［］［］において、パラメータｉ、ｊにて特定されるマップ値ｉＦＭａｐＡｂｌ［ｉ］［ｊ］に「１」をセットする（ステップ２２１０）。ステップ２２０９でＮｏと判断された場合、或いは、ステップ２２１０の後、ＣＰＵ１１は、パラメータｊをインクリメントして（ステップ２２１１）、ステップ２２０８に戻る。

このように、習得楽曲登録モードにおいて操作者により習得済みの楽曲が指定されると、運指難易度評価マップｉＦＭａｐ［］［］のマップ値ｉＦＭａｐ［ｉ］［ｊ］が「１」以上となっているような、当該楽曲について分類項目の具体的態様について、楽曲習得度マップｉＦＭａｐＡｂｌ［］［］のマップ値ｉＦＭａｐＡｂｌ［ｉ］［ｊ］も「１」となる。したがって、図６のステップ６０６で、マップ値ｉＦＭａｐＡｂｌ［ｉ］［ｊ］＝０であるかが判断され、上記マップ値が「０」ではない場合には、ｉＦＣｏｓｔ［ｉ］［ｊ］を、コストｉＦＣｏｓｔに反映させない。これにより、操作者（演奏者）が習得済みの事項（分類項目の具体的態様）を除外した楽曲の難易度の算出が可能となる。

本実施の形態においては、ＣＰＵ１１により、楽曲を構成する音符に関する楽音データの前記音高情報、運指情報および時間情報のいずれかに基づいて、前記楽曲の難易度を算出する難易度算出処理が実行される。難易度算出処理において、ＣＰＵ１１は、楽曲ごとに、楽曲の構成要素（たとえば、運指やリズム）に関する分類項目のそれぞれにおいて、その具体的態様の存在を示す難易度評価マップを生成して、ＲＡＭ１３などの記憶装置段に格納するとともに、難易度評価マップを参照して、分類項目の具体的態様のそれぞれに対するコスト値を格納した、ＲＡＭ１３など記憶手段に格納されたコストテーブルから、分類項目における具体的態様に対するコスト値を取得するとともに、当該コスト値を累算し、累算されたコスト値を前記運指に関する難易度として取得する。また、ＣＰＵ１１は、習得楽曲対応処理において、分類項目のそれぞれにおいて、その具体的態様の各々について、演奏者による習得の有無を示す習得度マップを生成して、ＲＡＭ１３など記憶装置に格納する。さらに、本実施の形態においては、ＣＰＵ１１はコスト累算の際に、習得度マップを参照して、分類項目の具体的態様における習得の有無を考慮して、コスト値を取得する。

したがって、本実施の形態によれば、演奏者が習得した楽曲において、分類項目の具体的態様が含まれる場合には、その分類項目の具体的態様が習得されたことを考慮したコスト値の算出を行なうことができる。したがって、演奏者の楽曲の習得にしたがった、当該演奏者の技量を考慮した楽曲の難易度を得ることが可能となる。

また、本実施の形態においては、ＣＰＵ１１は、習得度マップを参照して、分類項目の具体的態様において習得があった場合に、分類項目の具体的態様について対応するコスト値を、コスト値の累算から除外する。したがって、複雑な演算を経ることなく、演奏者の楽曲の習得にしたがった、当該演奏者の技量を考慮した楽曲の難易度を得ることが可能となる。

また、本実施の形態において、ＣＰＵ１１は、楽曲ごとに、難易度評価マップを参照して、分類項目の具体的態様が存在することを示している場合に、習得度マップにおいて、分類項目の具体的態様について所定値（たとえば「１」）をセットする。この場合には、習得度マップはフラグを格納するマップとなる。また、ある分類項目の具体的態様において、一度習得すれば、上記フラグが「１」とセットされ、当該分類項目の具体的態様については完全に習得したことを意味する。

本実施の形態においては、難易度算出処理には、音高情報および運指情報に基づいて、隣接する音符を押鍵する運指に関する運指難易度を算出する処理が含まれる。演奏者による運指の技量を考慮した楽曲の難易度を得ることが可能となる。

次に、本発明の第２の実施の形態について説明する。第１の実施の形態においては、楽曲習得度マップｉＦＭａｐＡｂｌ［］［］のマップ値ｉＦＭａｐＡｂｌ［ｉ］［ｊ］は、「０」または「１」の値をとり、コストｉＦＣｏｓｔ算出の際に、マップ値ｉＦＭａｐＡｂｌ［ｉ］［ｊ］＝０であるかが判断され、上記マップ値が「０」ではない場合には、ｉＦＣｏｓｔ［ｉ］［ｊ］を、コスト値ｉＦＣｏｓｔに反映させない。第２の実施の形態においては、マップ値ｉＦＭａｐＡｂｌ［ｉ］［ｊ］は、０〜Ｍａｘ（Ｍａｘ：所定の正の値）の何れかをとり、コスト値ｉＦＣｏｓｔ算出の際に、特定の分類項目の具体的態様についてのコスト値ｉＦＣｏｓｔ［ｉ］［ｊ］に、マップ値ｉＦＭａｐＡｂｌ［ｉ］［ｊ］を考慮した重みを与えて、コスト値ｉＦＣｏｓｔに加算している。

図２３は、第２の実施の形態にかかる運指難易度評価処理の後半部分の例を示すフローチャートである。図２３において、ステップ２３０１〜２３０５は、図６のステップ６０１〜６０５と同様である。また、ステップ２３０７、２３０８は、図６のステップ６０８、６０９と同様である。第２の実施の形態においては、ステップ２３０５でＹｅｓと判断された場合には、ＣＰＵ１１は、運指難易度評価マップの値ｉＦＭａｐ［ｉ］［ｊ］に対応付けられたコスト値ｉＦＣｏｓｔ［ｉ］［ｊ］に、重み（１−（ｉＦＭａｐＡｂｌ［ｉ］［ｊ］／Ｍａｘ））を乗じて、重みが乗じられたコスト値を、運指難易度の値ｉＦＣｏｓｔに加算する（ステップ２３０６）。

次に、第２の実施の形態にかかる習得楽曲対応処理についてより詳細に説明する。図２４は、第２の実施の形態にかかる習得楽曲対応処理の例を示すフローチャートである。図２４において、ステップ２４０１〜２４０９は、図２２のステップ２２０１〜２２０９と同様である。また、図２４のステップ２４１２、２４１３は、図２２のステップ２２１１、２２１２と同様である。第２の実施の形態においては、楽曲習得度マップｉＦＭａｐＡｂｌ［］［］のマップ値ｉＦＭａｐＡｂｌ［ｉ］［ｊ］は、０〜Ｍａｘの何れかの値をとり得る。

図２４において、ステップ２４０９でＹｅｓと判断された場合には、ＣＰＵ１１は、マップ値ｉＦＭａｐＡｂｌ［ｉ］［ｊ］が、取り得る値の最大値Ｍａｘより小さいかを判断する（ステップ２４１０）。ステップ２４１０でＹｅｓと判断された場合には、ＣＰＵ１１は、マップ値ｉＦＭａｐＡｂｌ［ｉ］［ｊ］をインクリメントする（ステップ２４１１）。ステップ２４０９または２４１０でＮｏと判断された場合、或いは、ステップ２４１１の後、ＣＰＵ１１は、パラメータｊをインクリメントして（ステップ２４１２）、ステップ２４０８に戻る。なお、Ｍａｘは、たとえば、大規模記憶装置１４に格納された楽曲データの楽曲総数としても良い。これによれば、全ての楽曲の習得が終了することで、ｉＦＭａｐＡｂｌ［ｉ］［ｊ］／Ｍａｘは「１」となり得る。したがって、ｉＦＣｏｓｔに加算すべきｉＦＣｏｓｔ［ｉ］［ｊ］×（１−（ｉＦＭａｐＡｂｌ［ｉ］［ｊ］／Ｍａｘ）の値が「０」となり得る。

第２の実施の形態においては、ＣＰＵ１１は、習得度マップの生成において、楽曲ごとに、難易度評価マップを参照して、分類項目の具体的態様が存在することを示している場合に、習得度マップにおいて、分類項目の具体的態様について、マップ値を累算する。また、ＣＰＵ１１は、コスト累算において、習得度マップを参照して、分類項目の具体的態様において累算された値が格納されている場合に、分類項目の具体的態様について対応するコスト値に、累算された値に基づく重みを付与する。したがって、第２の実施の形態によれば、分類項目の具体的態様における習得の度合いを、累算値として知ることができ、この習得の度合いを考慮した難易度算出が実現できる。

また、第２の実施の形態においては、重みが、累算された値の所定数に対する比に相当する。これにより、ある所定数の楽曲について分類項目の具体的態様における習得がなされたことをもって、当該分類項目の具体的態様を完全に習得したとすることができる。

本発明は、以上の実施の形態に限定されることなく、特許請求の範囲に記載された発明の範囲内で、種々の変更が可能であり、それらも本発明の範囲内に包含されるものであることは言うまでもない。

たとえば、前記第１の実施の形態および第２の実施の形態においては、運指難易度について、楽曲習得度マップを生成し、運指難易度にかかるコストｉＦＣｏｓｔの算出の際に、楽曲習得度マップを参照して、既に習得済みの、運指に関する分類項目の具体的態様について、コスト値ｉＦＣｏｓｔ［ｉ］［ｊ］の加算を行なわず、或いは、一定の重みを加えてコスト値ｉＦＣｏｓｔ［ｉ］［ｊ］の加算を行なっている。

しかしながら、運指難易度に限定されず、リズム難易度についても、同様に、楽曲習得度マップを生成して、楽曲習得度マップを参照して、コスト値の加算の是非を判断し、或いは、コスト値に重みを付与しても良い。

図２５および図２６は、本発明の第３の実施の形態にかかるリズム難易度評価処理の例を示すフローチャートである。図２５において、ステップ２５０１〜２５０７は、図１０のステップ１００１〜１００７と同様である。また、図２６において、ステップ２６０１〜２６０５、２６０７〜２６０９は、図１１のステップ１１０１〜１１０５、１１０６〜１１０８と同様である。

図２５において、ステップ２５０２でＹｅｓと判断された場合には、ＣＰＵ１１は、ステップ２５０５および２５０６でマップ値がインクリメントされたリズム難易度評価マップｉＲＭａｐ［］［］を、楽曲を特定する情報と関連付けて、記憶装置（たとえばＲＡＭ１３）に格納する（ステップ２５０８）。この楽曲を特定する情報と関連付けられたリズム難易度評価マップｉＲＭａｐ［］［］は、後述する第３の実施の形態にかかる習得楽曲対応処理において参照される。

また、図２６において、ステップ２６０５でＹｅｓと判断された場合には、ＣＰＵ１１は、操作者（演奏者）の楽曲習得度マップのマップ値ｉＲＭａｐＡｂｌ［ｉ］［ｊ］が「０」であるかを判断する（ステップ２６０６）。ステップ２０６でＹｅｓと判断された場合には、ＣＰＵ１１は、リズム難易度評価マップの値ｉＲＭａｐ［ｉ］［ｊ］に対応付けられたコスト値ｉＲＣｏｓｔ［ｉ］［ｊ］を、運指難易度の値ｉＲＣｏｓｔに加算する（ステップ１１０６）。

図２７は、第３の実施の形態にかかる習得楽曲対応処理の例を示すフローチャートである。図２７に示すように、ＣＰＵ１１は、楽曲に関連付けられたリズム難易度評価マップｉＲＭａｐ［］［］を、ＲＡＭ１３から読み出す（ステップ２７０１）。次いで、ＣＰＵ１１は、操作者（演奏者）固有の楽曲習得度マップが、ＲＡＭ１３に格納されているかを判断する（ステップ２７０２）。

ステップ２７０２でＹｅｓと判断された場合には、ＣＰＵ１１は、ＲＡＭ１３に格納された、当該操作者（演奏者）に固有の楽曲習得度マップｉＲＭａｐＡｂｌ［］［］を読み出す（ステップ２７０３）。ステップ２７０２でＮｏと判断された場合には、ＲＡＭ１３に新規の楽曲習得度マップｉＲＭａｐＡｂｌ［］［］を生成する。なお、新規の楽曲習得度マップのマップ値ｉＲＭａｐＡｂｌｅ［ｉ］［ｊ］は、全て「０」である。

次いで、ＣＰＵ１１は、パラメータｉを初期化して（ステップ２７０５）。パラメータｉが「２」以上であるかを判断する（ステップ２７０６）。ステップ２７０６でＹｅｓと判断された場合には処理を終了する。その一方、ステップ２７０６でＮｏと判断された場合には、ＣＰＵ１１は、パラメータｊを「０」に初期化して（ステップ２７０７）、ｊが所定数より大きくなるまで（ステップ２７０８）、ステップ２７０９〜２７１１を繰り返す。ステップ２７０８でＹｅｓと判断された場合には、ＣＰＵ１１は、パラメータｉをインクリメントして（ステップ２７１２）、ステップ２７０６に戻る。

ＣＰＵ１１は、楽曲に関連付けられたリズム難易度評価マップｉＲＭａｐ［］［］のマップ値ｉＲＭａｐ［ｉ］［ｊ］が「０」より大きいかを判断する（ステップ２７０９）。ステップ２７０９でＹｅｓと判断された場合には、ＣＰＵ１１は、楽曲習得度マップｉＲＭａｐＡｂｌ［］［］において、パラメータｉ、ｊにて特定されるマップ値ｉＲＭａｐＡｂｌ［ｉ］［ｊ］に「１」をセットする（ステップ２７１０）。ステップ２７０９でＮｏと判断された場合、或いは、ステップ２７１０の後、ＣＰＵ１１は、パラメータｊをインクリメントして（ステップ２７１１）、ステップ２７０８に戻る。

上述したように、第３の実施の形態においては、操作者により習得済みの楽曲が指定されると、リズム難易度評価マップｉＲＭａｐ［］［］のマップ値ｉＲＦＭａｐ［ｉ］［ｊ］が「１」以上となっているような、当該楽曲について分類項目の具体的態様について、楽曲習得度マップｉＲＭａｐＡｂｌ［］［］のマップ値ｉＲＭａｐＡｂｌ［ｉ］［ｊ］も「１」となる。したがって、図２６のステップ２６０６で、マップ値ｉＲＭａｐＡｂｌ［ｉ］［ｊ］＝０であるかが判断され、上記マップ値が「０」ではない場合には、ｉＲＣｏｓｔ［ｉ］［ｊ］を、コストｉＲＦＣｏｓｔに反映させない。これにより、操作者（演奏者）が習得済みの事項（分類項目の具体的態様）を除外した楽曲の難易度の算出が可能となる。すなわち、演奏者によるリズムに関する技量を考慮した楽曲の難易度を得ることが可能となる。

さらに、リズムコストｉＲＣｏｓｔの算出においても、第２の実施の形態と同様に、コスト値ｉＲＣｏｓｔ［ｉ］［ｊ］に、ｉＲＭａｐＡｂｌ［ｉ］［ｊ］に基づく重みを乗じて、重みが乗じられたコスト値を、ｉＲＣｏｓｔに加算しても良い。この場合に図２７に示す習得楽曲対応処理のステップ２７１０の代わりに、図２４のステップ２４１０，２４１１と同様に、ＣＰＵ１１は、リズム難易度評価マップの値ｉＲＭａｐ［ｉ］［ｊ］が最大値Ｍａｘより小さい限り、リズム難易度評価マップの値ｉＲＭａｐ［ｉ］［ｊ］をインクリメントする。

また、図２６において、習得度マップｉＲＭａｐＡｂｌ［ｉ］［ｊ］が「０」であるか否かの判断（ステップ２４０６）を行なうことなく、ＣＰＵ１１は、ステップ２６０７において、リズム難易度評価マップの値ｉＲＭａｐ［ｉ］［ｊ］に対応付けられたコスト値ＲＣｏｓｔ［ｉ］［ｊ］に、重み（１−（ｉＲＭａｐＡｂｌ［ｉ］［ｊ］／Ｍａｘ））を乗じて、重みが乗じられたコスト値を、運指難易度の値ｉＲＣｏｓｔに加算すれば良い。

１０ 楽曲難易度算出装置
１１ ＣＰＵ
１２ ＲＯＭ
１３ ＲＡＭ
１４ 大規模記憶装置
１５ 入力装置
１６ 表示装置
１７ サウンドシステム
１８ 鍵盤

Claims (3)

1. 楽曲を構成する音符ごとの音高情報、鍵盤位置情報、当該音符を押鍵する際の運指情報、および、当該音符についての時間情報を含む楽音データを格納した記憶手段と、
   この記憶手段から楽音データを音符毎に順次読み出すとともに、当該読み出された音符に隣接する音符の楽音データを読み出す読み出し手段と、
   この読み出し手段にて読み出された音符の楽音データ及び前記隣接する音符の楽音データ夫々に含まれる音高情報及び運指情報に基づき、隣接する音符間を押鍵する際になされる指使いの種別を判別する第１の判別手段と、
   前記読み出された音符の楽音データ及び前記隣接する音符の楽音データ夫々に含まれる音高情報により決定された白鍵、黒鍵のいずれかであるかを示す情報と、運指情報とに基づき、隣接する音符間を押鍵する際の指のポジション種別を判別する第２の判別手段と、
   前記読み出された音符の楽音データ及び前記隣接する音符の楽音データ夫々に含まれる音高情報及び運指情報に基づき、指くぐり或いは指返しの有無の種別を判別する第３の判別手段と、
   前記読み出された音符の楽音データ及び前記隣接する音符の楽音データ夫々に含まれる鍵盤位置情報に基づき、隣接する音符を押鍵する指の開き具合の種別を判別する第４の判別手段と、
   前記第１の判別手段乃至第４の判別手段夫々により判別された指使いの種別、指ポジションの種別、指くぐり或いは指返しの有無、及び指の開き具合の種別毎の数をカウントする種別カウント手段と、
   前記指使いの種別、指ポジションの種別、指くぐり或いは指返しの有無、及び指の開き具合の種別の夫々において、演奏者による未習得・習得済みを示す習得度マップを生成する習得度マップ生成手段と、
   前記指使いの種別、指ポジションの種別、指くぐり或いは指返しの有無の種別、及び指の開き具合の種別毎のコスト値のうち、前記習得度マップを参照して前記演奏者が未修得の種別のコスト値のみを取得し、前記種別カウント手段によりカウントされた種別毎の数に応じて、対応する当該取得されたコスト値を前記種別毎に累算するとともに、当該累算された種別毎のコスト値を加算することにより、楽曲難易度を算出する算出手段と、
   を有する楽曲難易度算出装置。
2. 前記読み出し手段にて読み出された音符の楽音データ及び前記隣接する音符の楽音データ夫々に含まれる音高情報及び運指情報に基づき、音符の進行が上行かつ指が開く形態で運指が行われるか否かを判別する第５の判別手段を更に有し、
   前記第５の判別手段により音符の進行が上行かつ指が開く形態で運指が行われると判別された場合に、前記第３の判別手段により判別される種別を特定の種別とし、判別されない場合は、前記第２の判別手段及び第４の判別手段により判別される種別を特定の種別とすることを特徴とする請求項１に記載の楽曲難易度算出装置。
3. 楽曲を構成する音符ごとの音高情報、鍵盤位置情報、当該音符を押鍵する際の運指情報、および、当該音符についての時間情報を含む楽音データを格納した記憶手段を備えたコンピュータに、
   この記憶手段から楽音データを音符毎に順次読み出すとともに、当該読み出された音符に隣接する音符の楽音データを読み出す読み出しステップと、
   この読み出された音符の楽音データ及び前記隣接する音符の楽音データ夫々に含まれる音高情報及び運指情報に基づき、隣接する音符間を押鍵する際になされる指使いの種別を判別する第１の判別ステップと、
   前記読み出された音符の楽音データ及び前記隣接する音符の楽音データ夫々に含まれる音高情報により決定された白鍵、黒鍵のいずれかであるかを示す情報と、運指情報とに基づき、隣接する音符間を押鍵する際の指のポジション種別を判別する第２の判別ステップと、
   前記読み出された音符の楽音データ及び前記隣接する音符の楽音データ夫々に含まれる音高情報及び運指情報に基づき、指くぐり或いは指返しの有無の種別を判別する第３の判別ステップと、
   前記読み出された音符の楽音データ及び前記隣接する音符の楽音データ夫々に含まれる鍵盤位置情報に基づき、隣接する音符を押鍵する指の開き具合の種別を判別する第４の判別ステップと、
   前記第１の判別ステップ乃至第４の判別ステップ夫々により判別された指使いの種別、指ポジションの種別、指くぐり或いは指返しの有無、及び指の開き具合の種別毎の数をカウントする種別カウントステップと、
   前記指使いの種別、指ポジションの種別、指くぐり或いは指返しの有無、及び指の開き具合の種別の夫々において、演奏者による未習得・習得済みを示す習得度マップを生成する習得度マップ生成ステップと、
   前記指使いの種別、指ポジションの種別、指くぐり或いは指返しの有無の種別、及び指の開き具合の種別毎のコスト値のうち、前記習得度マップを参照して前記演奏者が未修得の種別のコスト値のみを取得し、前記カウントされた種別毎の数に応じて、対応する当該取得されたコスト値を前記種別毎に累算するとともに、当該累算された種別毎のコスト値を加算することにより、楽曲難易度を算出する算出ステップと、
   を実行させる楽曲難易度算出プログラム。

Images