JP2008243155A - 歌詞検索装置及び歌詞検索プログラム - Google Patents

Abstract

【課題】元歌詞とルビ情報とが混在して構成されている歌詞データに対しても高い検索効率で検索し得る歌詞検索装置及び歌詞検索プログラムを提供すること。
【解決手段】本発明の歌詞検索装置及び歌詞検索プログラムによれば、第１の歌詞データ記憶手段に記憶されている第１の歌詞データから、第２の歌詞データが生成され、そのように生成された第２の歌詞データが、第２の歌詞データ記憶手段に記憶される。そして、入力された検索用の文字列は、第２の歌詞データ記憶手段に記憶されている第２の歌詞データを検索対象として検索される。よって、歌詞検索の際には、第２の歌詞データ、即ち、元歌詞データに含まれる文字のうち、付加的歌詞データが付される文字が対応する付加的歌詞データに置換されたデータを検索対象として使用するので、付加的歌詞データを含む文字列を用いて検索行う場合であっても、良好な検索効率で歌詞検索をすることができる。
【選択図】図７

Description

本発明は、歌詞検索装置及び歌詞検索プログラムに関し、特に、歌詞に基づいて検索を行う場合に、歌詞データの種類とは無関係に高い検索効率で検索し得る歌詞検索装置及び歌詞検索プログラムに関するものである。

従来、キーワードとして歌詞の一部分がキーワード入力器へ入力されると、第二のデータ記憶器に曲目ごとにテキストファイルとして記憶されている歌詞データの中から、入力された検索文字列（キーワード）の検索を行い、その検索文字列を含む曲目が抽出される電子音楽データ検索視聴装置が提案されている（特許文献１）。また、歌詞の出だしなどの入力データに基づいて、カセットやコンパクトディスクなどの記録媒体から楽曲を検索し、演奏させる検索システムが提案されている（特許文献２）。

これらの特許文献（特許文献１，２）などに記載される従来の歌詞検索では、演奏データ（電子音楽データ）に対応する歌詞データの中から、検索文字列の検索を行う。
特開２００１−１２５５８３号公報 特開平７−２７２４６２号公報

しかしながら、従来の歌詞検索では、ディスプレイなどの表示装置に文字によって記述される見かけの歌詞（元歌詞）のデータであれば対応可能であるが、元歌詞データと、元歌詞に含まれる一部の文字に対して付されたルビ（読み仮名）のデータとが混在して構成される歌詞データを検索対象とする場合には、検索の失敗が多く、検索効率が悪いという問題点があった。特に、文字によって記述される見かけの歌詞ではなく、ユーザが歌唱時に実際に発音する歌詞（発音上の歌詞）を検索文字列として使用した場合に、検索効率がより悪化する傾向があり、元歌詞とルビ情報との混在具合の複雑さの程度が高い場合には、検索不可能になるという問題点があった。

一般的に、見かけの歌詞より、実際に自身が歌う発音上の歌詞の方が、より強く印象に残るという理由によって、ユーザが歌詞検索を行う際には、発音上の歌詞を検索文字列として入力されるケースが多い。それにもかかわらず、上記のように、発音上の歌詞を検索文字列とする検索の成功率が非常に低いのでは、歌詞検索としての実用性が低い。

本発明は、上述した問題点を解決するためになされたものであり、元歌詞とルビ情報とが混在して構成されている歌詞データに対しても、高い検索効率で検索し得る歌詞検索装置、及び歌詞検索プログラムを提供することを目的としている。

この目的を達成するために、請求項１記載の歌詞検索装置は、文字によって記述される元歌詞データと、その元歌詞データに含まれる少なくとも１つの文字に対して付される付加的歌詞データとを、曲の進行順に、各々論理的に区別可能に混在して含む第１の歌詞データを記憶する第１の歌詞データ記憶手段と、前記元歌詞データに含まれる文字のうち、前記付加的歌詞データが付される文字を、対応する前記付加的歌詞データに置換したデータである第２の歌詞データを、前記第１の歌詞データ記憶手段に記憶されている前記第１の歌詞データから生成する第２の歌詞データ生成手段と、その第２の歌詞データ生成手段により生成された前記第２の歌詞データを記憶する第２の歌詞データ記憶手段と、検索用の文字列を入力する検索文字列入力手段と、前記第２の歌詞データ記憶手段に記憶されている前記第２の歌詞データを検索対象として、前記検索文字列入力手段から入力された文字列を検索する検索手段とを備えている。

請求項２記載の歌詞検索装置は、請求項１記載の歌詞検索装置において、前記第１の歌詞データ記憶手段に記憶されている前記第１の歌詞データから、前記付加的歌詞データを削除したデータである第３の歌詞データを生成する第３の歌詞データ生成手段と、その第３の歌詞データ生成手段により生成された第３の歌詞データを記憶する第３の歌詞データ記憶手段とを備え、前記検索手段は、前記第２の歌詞データ記憶手段に記憶されている前記第２の歌詞データ、又は前記第３の歌詞データ記憶手段に記憶されている前記第３の歌詞データの、少なくとも一方を検索対象として、前記検索文字列入力手段から入力された文字列を検索するものである。

請求項３記載の歌詞検索装置は、請求項２記載の歌詞検索装置において、前記検索手段は、前記第２の歌詞データ記憶手段に記憶されている前記第２の歌詞データ、又は前記第３の歌詞データ記憶手段に記憶されている前記第３の歌詞データの一方を検索対象として、前記検索文字列入力手段から入力された文字列を検索する第１の検索手段と、前記第２の歌詞データ記憶手段に記憶されている前記第２の歌詞データ、又は前記第３の歌詞データ記憶手段に記憶されている前記第３の歌詞データの他方を検索対象として、前記検索文字列入力手段から入力された文字列を検索する第２の検索手段と、前記第１の検索手段による検索の結果、前記検索文字列入力手段から入力された文字列に一致する文字列が見つかった場合には、前記第２の検索手段による検索の実行を禁止する検索終了手段とを備えている。

請求項４記載の歌詞検索装置は、請求項２記載の歌詞検索装置において、前記第２の歌詞データ生成手段により生成された第２の歌詞データ、又は前記第３の歌詞データ生成手段により生成された第３の歌詞データの一方を検索対象として、前記検索手段による検索を行う前に、前記第２の歌詞データ、又は前記第３の歌詞データの他方を、前記第２の歌詞データ生成手段、又は前記第３の歌詞データ生成手段によって生成することを待機する歌詞データ生成待機手段と、前記検索手段による検索の結果、前記検索文字列入力手段から入力された文字列に一致する文字列が見つかった場合に、前記歌詞データ生成待機手段により待機されている前記第２の歌詞データ生成手段又は前記第３の歌詞データ生成手段による歌詞データの生成を禁止する検索終了手段とを備えている。

請求項５記載の歌詞検索プログラムは、第１の歌詞データ記憶手段に記憶されている歌詞データであって、文字によって記述される元歌詞データと、前記元歌詞データに含まれる少なくとも１つの文字に対して付される付加的歌詞データとを、曲の進行順に、各々論理的に区別可能に混在して含む第１の歌詞データから、前記元歌詞データのうち、前記付加的歌詞データが付される文字を、対応する前記付加的歌詞データに置換した第２の歌詞データを生成し、第２の歌詞データ記憶手段に記憶させる第２の歌詞データ生成ステップと、その第２の歌詞データ生成ステップによって前記第２の歌詞データ記憶手段に記憶された第２の歌詞データを検索対象として、入力された検索用の文字列を検索させる検索ステップとを制御装置に実行させるものである。

請求項１記載の歌詞検索装置によれば、第１の歌詞データ記憶手段に記憶されている第１の歌詞データから、第２の歌詞データ生成手段によって第２の歌詞データが生成され、そのように生成された第２の歌詞データは、第２の歌詞データ記憶手段に記憶される。そして、検索文字列入力手段から入力された文字列は、検索手段により、第２の歌詞データ記憶手段に記憶されている第２の歌詞データを検索対象として検索される。

また、請求項５記載の歌詞検索プログラムによれば、第２の歌詞データ生成ステップの実行により、第１の歌詞データ記憶手段に記憶されている第１の歌詞データから、第２の歌詞データが生成され、そのように生成された第２の歌詞データが、第２の歌詞データ記憶手段に記憶される。そして、検索ステップの実行により、第２の歌詞データ記憶手段に記憶されている第２の歌詞データを検索対象として、入力された検索用の文字列が検索される。

ここで、「第１の歌詞データ」は、文字によって記述される元歌詞データと、その元歌詞データに含まれる少なくとも１つの文字に対して付される付加的歌詞データとを、曲の進行順に、各々論理的に区別可能に混在して含むデータであり、「第２の歌詞データ」は、第１の歌詞データにおける元歌詞データに含まれる文字のうち、付加的歌詞データが付される文字を、対応する付加的歌詞データに置換したデータである。

また、「付加的歌詞データ」とは、文字によって記述される見かけ上の歌詞（元歌詞）のうち、対応する文字を置き換えることのできる文字のデータであり、例えば、読み仮名として付された文字（例えば、ルビ）のデータや、読み方とは無関係に、文字を特徴づけたり説明したりする目的で付された仮名文字列や英数字文字列のデータなどが挙げられる。

よって、請求項１記載の歌詞検索装置、及び請求項５記載の歌詞検索プログラムによれば、歌詞検索の際には、第２の歌詞データ、即ち、元歌詞データに含まれる文字のうち、付加的歌詞データが付される文字が、対応する付加的歌詞データに置換されたデータを検索対象として使用するので、付加的歌詞データを含む文字列を用いて検索を行う場合であっても、良好な検索効率で歌詞検索をすることができるという効果がある。

例えば、付加的歌詞データが読み仮名（例えば、読み方として付されたルビ）であれば、第２の歌詞データは、元歌詞におけるルビの振られた文字（たとえば、漢字）を読み仮名で表したデータ、即ち、ユーザが歌唱時に実際に発音する歌詞（発音上の歌詞）のデータとなる。このように、発音上の歌詞のデータが検索対象として生成されるので、ユーザが発音上の歌詞を検索文字列として入力した場合であっても、良好な検索効率で歌詞検索をすることができる。一般的に、ユーザが歌詞検索を行う際には、見かけの歌詞に比べてより強く印象に残っている発音上の歌詞を検索文字列として入力されるケースが多いので、発音上の歌詞を検索文字列とした場合に、良好な検索効率で歌詞検索できる歌詞検索装置又は歌詞検索プログラムは非常に好適である。

請求項２記載の歌詞検索装置によれば、請求項１記載の歌詞検索装置の奏する効果に加えて、次の効果を奏する。第１の歌詞データ記憶手段に記憶されている第１の歌詞データから、第３の歌詞データ生成手段によって第３の歌詞データが生成され、そのように生成された第３の歌詞データは、第３の歌詞データ記憶手段に記憶される。

そして、検索文字列入力手段から入力された文字列は、検索手段により、第２の歌詞データ記憶手段に記憶されている第２の歌詞データ、又は第３の歌詞データ記憶手段に記憶されている第３の歌詞データの少なくとも一方を検索対象として検索される。

ここで、「第３の歌詞データ」は、第１の歌詞データから付加的歌詞データを削除したデータ、即ち、元歌詞データである。

よって、検索手段による歌詞検索の際には、第３の歌詞データ、即ち、元歌詞データを検索対象として使用することができるので、見かけ上の歌詞（元歌詞）を用いた検索にも適用可能であるという効果がある。

請求項３記載の歌詞検索装置によれば、請求項２記載の歌詞検索装置の奏する効果に加えて、次の効果を奏する。検索手段による検索では、まず、検索文字列入力手段から入力された検索用の文字列が、第１の検索手段により、第２の歌詞データ記憶手段に記憶されている第２の歌詞データ、又は第３の歌詞データ記憶手段に記憶されている第３の歌詞データの一方を検索対象として検索される。

ここで、第１の検索手段による検索の結果、入力された検索用の文字列に一致する文字列が見つからなかった場合には、該文字列が、第２の検索手段により、第２の歌詞データ記憶手段に記憶されている第２の歌詞データ、又は第３の歌詞データ記憶手段に記憶されている第３の歌詞データの他方を検索対象として検索される。

その一方で、第１の検索手段による検索の結果、入力された検索用の文字列に一致する文字列が見つかった場合には、検索終了手段により、第２の検索手段による検索の実行が禁止される、即ち、第２の検索手段による検索を行わない。

よって、第２の歌詞データ記憶手段に記憶されている第２の歌詞データ、又は第３の歌詞データ記憶手段に記憶されている第３の歌詞データのいずれか一方から、入力された検索用の文字列が先に見つかった場合には、第２の歌詞データ又は第３の歌詞データのうち、未だ検索されていない方の歌詞データに対する検索を行うことなく検索が終了するので、無駄な検索に時間を費やすことを防止することができ、速い検索速度で結果を得ることができるという効果がある。

請求項４記載の歌詞検索装置によれば、請求項２記載の歌詞検索装置の奏する効果に加えて、次の効果を奏する。第２の歌詞データ生成手段により生成された第２の歌詞データ又は第３の歌詞データ生成手段により生成された第３の歌詞データの一方を検索対象として検索手段による検索を行う前に、第２の歌詞データ又は第３の歌詞データの他方は、歌詞データ生成待機手段によって、第２の歌詞データ生成手段又は第３の歌詞データ生成手段による歌詞データの生成が待機される。

ここで、検索手段による検索の結果、検索文字列入力手段から入力された検索用の文字列に一致する文字列が見つかった場合には、検索終了手段によって、歌詞データ生成待機手段により待機されている第２の歌詞データ生成手段又は第３の歌詞データ生成手段による歌詞データの生成が禁止される、即ち、歌詞データ生成待機手段により待機されている第２の歌詞データ生成手段又は第３の歌詞データ生成手段によって、歌詞データ（第２の歌詞データ又は第３の歌詞データ）が生成されることはない。その結果、他方の歌詞データに対する検索を行うことなく、検索が終了する。

よって、第２の歌詞データ記憶手段に記憶されている第２の歌詞データ、又は第３の歌詞データ記憶手段に記憶されている第３の歌詞データのいずれか一方から、入力された検索用の文字列が先に見つかった場合には、第２の歌詞データ又は第３の歌詞データのうち、未だ検索されていない方の歌詞データは、生成されることなく検索が終了するので、無駄なデータ生成、及び検索に時間を費やすことを防止することができ、速い検索速度で結果を得ることができるという効果がある。

以下、本発明の好ましい実施例について、添付図面を参照して説明する。

図１は、本発明における一実施形態の歌詞検索装置５０を搭載する、自動演奏装置１の構成を示したブロック図である。

自動演奏装置１は、演奏データ（ＭＩＤＩ（Ｍｕｓｉｃａｌ Ｉｎｓｔｒｕｍｅｎｔ Ｄｉｇｉｔａｌ Ｉｎｔｅｒｆａｃｅ）メッセージ）に基づいて自動演奏を行うと共に、その自動演奏に伴う歌詞表示を歌詞データに基づいて表示する装置である。かかる自動演奏装置１は、図１に示すように、ＣＰＵ１０と、ＲＯＭ１１と、ＲＡＭ１２と、ハードディスク（ＨＤＤ）１３と、ユーザの操作により文字などを入力するキーボード１４と、各種情報を表示する液晶表示装置（ＬＣＤ）１５と、音源１６とを有しており、これらはバスライン１７により相互に接続して構成される。また、自動演奏装置１において、音源１６の出力は、Ｄ／Ａ変換器２１に接続され、Ｄ／Ａ変換器２１の出力は、アンプ２２に接続され、アンプ２２は、スピーカ２３に接続されている。

また、自動演奏装置１は、ユーザがキーボード１４から検索文字列（検索用の文字列）として入力した歌詞の一部分を含む曲をＨＤＤ１３から検索する装置である歌詞検索装置５０を搭載している、この歌詞検索装置５０は、ＣＰＵ１０と、ＲＯＭ１１と、ＲＡＭ１２と、ＨＤＤ１３と、キーボード１４と、ＬＣＤ１５と、これらを相互に接続するバスライン１７とから構成される。

ＣＰＵ１０は、自動演奏装置１（歌詞検索装置５０）の全体を制御する演算処理装置であり、ＲＯＭ１１には、このＣＰＵ１０により実行される各種の制御プログラムや、その実行の際に参照される固定値データが記憶される。

ＲＡＭ１２は、ＲＯＭ１１等に記憶されている制御プログラムの実行に当たって、各種のデータ等を一時的に記憶するためのメモリであり、書き換え可能に構成され、歌詞イベントバッファ１２ａと、ＯＲＬバッファ１２ｂと、ＲＢＬバッファ１２ｃと、ルビフラグ１２ｄと、消去文字数カウンタ１２ｅとを有している。

歌詞イベントバッファ１２ａは、後述する歌詞イベント抽出処理（図５参照）において、ＨＤＤ１３に記憶されているＮ曲分のスタンダードＭＩＤＩファイル（ＳＭＦ）の中の１ファイル、即ち、１曲分のＳＭＦに含まれている歌詞イベントのイベントデータ（以下、歌詞イベントのイベントデータを、単に「歌詞データ」と称する）を記憶するバッファメモリである。

ＯＲＬバッファ１２ｂは、後述する元歌詞データ生成処理（図６参照）において、歌詞イベントバッファ１２ａに記憶されている１曲分の歌詞データから生成された１曲分の元歌詞、即ち、文字によって記述される見かけ上の歌詞のデータ（元歌詞データ）を記憶するバッファメモリである。

ＲＢＬバッファ１２ｃは、後述するルビ歌詞データ生成処理（図７参照）において、歌詞イベントバッファ１２ａに記憶されている１曲分の歌詞データから生成された１曲分のルビ歌詞のデータ（ルビ歌詞データ）を記憶するバッファメモリである。

なお、本実施形態において「ルビ」は、元歌詞に含まれる文字（例えば、送り仮名を含む単語の漢字部分や、複数の漢字からなる熟語や、英単語）の読みを示す仮名（即ち、読み仮名）を意味する。また、「ルビ歌詞」は、ユーザが歌唱時に実際に発音する歌詞（発音上の歌詞）、即ち、元歌詞におけるルビが付されている文字を、対応するルビに置換した歌詞を意味する。

ルビフラグ１２ｄは、後述する元歌詞データ生成処理（図６参照）、及びルビ歌詞データ生成処理（図７参照）において、歌詞イベントバッファ１２ａに記憶されている歌詞データを１文字（本実施形態では、２バイト文字）ずつ読み出す際に、読み出した各文字がルビのデータ（ルビデータ）であるか否かを示すフラグである。具体的には、ルビフラグ１２ｄが「１」である場合に読み出されたデータは、ルビデータであることを示し、一方で、ルビフラグ１２ｄが「０」である場合に読み出されたデータは、ルビデータではない、即ち、元歌詞データであることを示す。

消去文字数カウンタ１２ｅは、後述するルビ歌詞データ生成処理（図７参照）において、ＲＢＬバッファ１２ｃに記憶させた元歌詞データの文字の数（データ量）をカウントするものである。

ＨＤＤ１３は、書き換え可能な不揮発性の大容量メモリであり、Ｎ曲分のＳＭＦ（第１ファイル１３ａ１〜第Ｎファイル１３ａＮ）を記憶している。なお、ＨＤＤ１３へ記憶させるＳＭＦは、例えば、対応するメディアドライブ（図示せず）に装着された記録媒体（例えば、ＤＶＤやＣＤなど）からのコピーや、通信インターフェイス（図示せず）を介して、外部からダウンロードなどの方法によって取得することができる。

音源１６は、ＳＭＦに含まれるＭＩＤＩイベントのイベントデータ（ＭＩＤＩデータ）に応じたデジタルの楽音信号を出力するものであり、Ｄ／Ａ変換器２１により、アナログの楽音信号に変換される。Ｄ／Ａ変換器２１によって変換されたアナログ楽音信号は、アンプ２２に供給され、スピーカ２３から楽音が放音される。

次に、図２（ａ）を参照して、ＳＭＦのデータ構成について説明する。図２（ａ）は、ＳＭＦのデータ構成を示す模式図である。なお、図２（ａ）では、ＨＤＤ１３に記憶されているＳＭＦの１つである、第１ファイル１３ａ１を代表として例示するが、他のＳＭＦ（第２ファイル１３ａ２〜第Ｎファイル１３ａＮ）も同様である。

図２（ａ）に示すように、自動演奏装置１において使用されるＳＭＦ（第１ファイル１３ａ１）は、ＳＭＦに対して定義されているフォーマット１の構造を有し、１つの曲の先頭に対して設けられる１つのヘッダチャンク５１と、その１つのヘッダチャンクに続く２つのトラックチャンク５２，５３とから構成されている。

ヘッダチャンク５１は、そのファイルの基本的な情報を格納するブロックである。このヘッダチャンク５１は、チャンクタイプを表す４バイトのデータ（「ＭＴｈｄ」を表すアスキーコード）を格納する先頭領域と、この先頭領域に続いてデータサイズ（本実施形態では「０００６ｈ」）を格納する領域と、この領域に続いてデータ本体を格納するデータ領域（本実施形態では、６バイトのデータ領域）とから構成されている。なお、ヘッダチャンク５１を構成する各領域の図示は省略する。

ヘッダチャンク５１に格納されるデータ本体は、ＳＭＦのフォーマットタイプ（本実施形態では「フォーマット１」）を指定する２バイトのデータと、１ファイル中に含まれるトラックチャンクの数（本実施形態では「２」）を指定する２バイトのデータと、トラックチャンク５２，５３で使用されるデルタタイム５５（図２（ｂ）参照）の意味（時間単位）を指定する２バイトのデータとから構成されている。

トラックチャンク５２，５３は、実際の演奏情報を格納するブロックである。なお、本実施形態では、ヘッダチャンク５１においてトラックチャンクの数を「２」と指定しているので、１つのＳＭＦ内部に２つのトラックチャンク５２，５３が設けられており、これら２つのトラックチャンク５２，５３に１曲分の演奏情報が格納されている。

図２（ａ）に示すように、これらのトラックチャンク５２，５３は、いずれも、チャンクタイプを表す４バイトのデータ（「ＭＴｒｋ」を表すアスキーコード）を格納する先頭領域５２ａ，５３ａと、この先頭領域５２ａ，５３ａに続いてデータサイズを格納する４バイトの領域５２ｂ，５３ｂと、この領域５２ｂ，５３ｂに続いてデータ本体を格納するデータ領域５２ｃ，５３ｃとから構成されている。

ここで、図２（ｂ）を参照して、トラックチャンク５２，５３の領域５２ｃ，５３ｃに格納されるデータ本体の内容について説明する。図２（ｂ）は、（ａ）に示したＳＭＦ（第１ファイル１３ａ１）における、トラックチャンク（１）５２の領域５２ｃに格納されるデータ本体のデータ構成を示す模式図である。なお、図２（ｂ）では、トラックチャンク（１）５２の領域５２ｃに格納されるデータ本体を例示するが、トラックチャンクに含まれる他のデータ本体についても同様である。

図２（ｂ）に示すように、トラックチャンク（１）５２の領域５２ｃに格納されるデータ本体は、デルタタイム５５とイベント５６とを一対とするデータのシーケンスにより形成されている。

ＳＭＦの規格では、イベント５６として格納されるイベントとして、ＭＩＤＩイベントと、システムエクスクルーシブイベントと、メタイベントとの３種類が定義されている。ここで、ＭＩＤＩイベントは、ＭＩＤＩチャネルメッセージ（ＭＩＤＩメッセージの１つ）を表すイベントであり、演奏データとしての実体をなすイベントである。また、システムエクスクルーシブイベントは、システムエクスクルーシブメッセージ（ＭＩＤＩメッセージの１つ）を表すイベントである。

また、メタイベントは、演奏データ（ＭＩＤＩメッセージ）以外のデータを表すイベントであり、例えば、演奏データによって演奏される自動演奏に伴う、歌詞のデータ（歌詞データ）を格納する歌詞イベントや、トラックチャンク（１）５２の終了位置を示すイベントであるエンド・オブ・トラックなどが含まれる。

デルタタイム５５は、ＳＭＦ内における各イベントの相対的な時間差を、ヘッダチャンク５１において指定された時間単位で表すデータである。なお、図２（ｂ）では、デルタタイムの値にかかわらず、デルタタイム５５を「Δｔ」で表している。イベント５６がデルタタイム５５と一対に構成されることにより、領域５２ｃ内の各イベント５６は、時系列（曲の進行順）に記述されることとなる。

次に、図３（ａ）を参照して、メタイベントのデータ構成について説明する。図３（ａ）は、メタイベントのデータ構成を示す模式図である。図３（ａ）に示すように、メタイベントは、メタイベントを表すステータスデータ「ＦＦｈ」を格納する領域６１と、イベントの種類を表すデータを格納する領域６２と、イベントのサイズを格納する領域６３と、イベントのデータ（イベントデータ）を格納する領域６４とから構成されている。

なお、図３（ａ）では、領域６２に「０５ｈ」が格納されている状態を例示しているが、このように、領域６２に「０５ｈ」が格納されているメタイベントは歌詞イベントであり、この場合には、領域６４には、領域６３に格納されたイベントサイズの歌詞データが格納されている。

ここで、図３（ｂ）及び図３（ｃ）を参照して、ＳＭＦにおけるメタイベントの１つである歌詞イベントについて説明する。図３（ｂ）は、領域５２ｃに格納される歌詞イベントを示す模式図である。なお、図３（ｂ）では、区間Ａに含まれるイベント５６のうち、８つが歌詞イベントＫ１〜Ｋ８である場合を例示している。また、図３（ｃ）は、図３（ｂ）における歌詞イベントＫ１，Ｋ２のイベントデータ（領域６４）を示す模式図である。

上述のように、歌詞イベントにおける領域６４には、イベントデータとして歌詞データが格納されており、各歌詞イベントには、デルタタイム５５で示されるタイミングに対応する歌詞データが格納されている。

この歌詞データは、２バイトの文字コード（ＳＪＩＳ漢字コード）を用いて歌詞を表したデータであり、後述するように、文字によって記述される、見かけ上の歌詞（元歌詞）のデータである元歌詞データＯＲ（図３（ｃ）参照）と、元歌詞に含まれる文字の読み仮名として付されるルビのデータであるルビデータＲＢ（図３（ｃ）参照）とが混在したデータである。なお、理解を容易にする目的で、図３（ｂ）及び図３（ｃ）において、領域６４に格納されている歌詞データを、文字コードに対応する文字として図示している。

元歌詞に含まれる文字に対してルビを付す場合には、ルビを付す対象とする元歌詞データＯＲを構成する全ての文字（例えば、「ハマ」というルビを付す対象である、「横浜」という元歌詞データＯＲ）を、同一の歌詞イベントにおける領域６４内に記述することを条件とし、ルビを付す対象である元歌詞データＯＲ’（ルビ対象データＯＲ’）の直後に、付すべきルビデータＲＢを、ルビ開始マークＲＳである「［」とルビ終了マークＲＥである「］」とで囲むことによって記述する。

このように、ＳＭＦデータにおける歌詞データは、ルビデータＲＢを、ルビ開始マークＲＳとルビ終了マークＲＥとで囲むことにより、元歌詞データＯＲとルビデータＲＢとを、各々論理的に区別することができる。

例えば、図３（ｃ）に示すように、歌詞イベントＫ１において、「横浜」を表す元歌詞データＯＲと、その元歌詞データＯＲの直後に記述されるルビ開始マークＲＳと、そのルビ開始マークＲＳの後に、「ハ」を表すルビデータＲＢとを含む歌詞データが記述され、歌詞イベントＫ１の次の歌詞イベントである歌詞イベントＫ２において、「マ」を表すルビデータＲＢと、そのルビデータＲＢの後に記述されるルビ終了マークＲＥとを含む歌詞データが記述されている場合、元歌詞に含まれる「横浜」という２文字の漢字に対して「ハマ」というルビが付される。

図３（ｂ）では、元歌詞である「横浜」に対して付される２文字のルビである「ハマ」が、別々の歌詞イベントの歌詞データとして記述されているので、自動演奏時に歌詞データに基づいて元歌詞及びルビをＬＣＤ１５に表示する場合には、「ハ」と「マ」とが異なるタイミングでルビが表示される。なお、ルビを構成する各文字は、必ずしも別々の歌詞イベントに記述する必要はなく、複数のルビを同じ歌詞イベントに記述し、同じタイミングで表示させるように構成してもよい。

このように、ＳＭＦの歌詞データは、元歌詞データとルビデータとが、曲の進行順に混在する複雑な構成であるために、従来の歌詞検索装置を用いて歌詞検索を行うと、歌詞データから、元歌詞のデータ（元歌詞データ）とルビ歌詞のデータ（ルビ歌詞データ）とを区別して検索することが難しく、検索の失敗が多く検索効率が悪かった。特に、ルビ歌詞で検索を行った場合に検索効率が悪化し、混在する元歌詞データ及びルビデータの複雑さの程度の大きさによっては、検索不可能になることもあった。

これに対し、自動演奏装置１に含まれる歌詞検索装置５０では、後述する図４〜図７に示す処理の実行により、元歌詞データとルビデータとが曲の進行順に混在する複雑な構成の歌詞データを検索対象とする場合であっても、高い検索効率で歌詞検索を行うことができる。

なお、説明の簡略化のため及び発明の理解を容易にするために、以下では、歌詞データ（元歌詞データ及びルビ歌詞データ）を構成する１文字を、全て２バイト文字であるものとして説明するが、１文字として、漢字やカタカナやひらがななどの２バイト文字と、英数半角文字や記号などの１バイト文字とが混在する場合であっても同様である。

ここで、図４〜図８を参照し、自動演奏装置１に含まれる歌詞検索装置５０によって歌詞検索を行う際に実行される処理について説明する。

図４は、歌詞検索装置５０で歌詞検索を行う場合のメイン処理を示すフローチャートである。また、図５は、図４のメイン処理の中で実行される歌詞イベント抽出処理（Ｓ５）を示すフローチャートであり、図６は、メイン処理の中で実行される元歌詞データ生成処理（Ｓ６）を示すフローチャートであり、図７は、メイン処理の中で実行されるルビ歌詞データ生成処理（Ｓ９）を示すフローチャートである。なお、図４〜図７に示す各フローチャートの実行プログラムは、ＲＯＭ１１に格納されている。

また、図８（ａ）は、図５の歌詞イベント抽出処理（Ｓ５）の実行結果を示す模式図であり、図８（ｂ）は、図６の元歌詞データ生成処理（Ｓ６）の実行結果を示す模式図であり、図８（ｃ）は、図７のルビ歌詞データ生成処理（Ｓ９）の実行結果を示す模式図である。

図４のメイン処理は、所定の操作により、歌詞検索装置５０による歌詞検索の実行が指示されると起動する処理であり、まず、歌詞イベントバッファ１２ａや、ＯＲＬバッファ１２ｂや、ＲＢＬバッファ１２ｃや、ルビフラグ１２ｄや、消去文字数カウンタ１２ｅなどの初期設定を実行する（Ｓ１）。

初期設定（Ｓ１）の実行後、ユーザ操作により、キーボード１４から検索文字列が入力されたかを確認し（Ｓ２）、検索文字列の入力がない場合には（Ｓ２：Ｎｏ）、Ｓ２へ戻り、再度確認を行う。

一方で、Ｓ２の処理により確認した結果、キーボード１４からの検索文字列の入力があった場合には（Ｓ２：Ｙｅｓ）、変数ｎの値を「１」に設定し（Ｓ３）、ＨＤＤ１３に記憶されている第１ファイル１３ａ１〜第Ｎファイル１３ａＮのうち、第ｎ番目のファイルである第ｎファイル１３ａｎ（ｎは、１〜Ｎのうち現在設定されている値）を、ＲＡＭ１２内の所定のエリアにロードする（Ｓ４）。

次いで、Ｓ４の処理によってＲＡＭ１２内の所定のエリアにロードされた第ｎファイル１３ａｎ（ｎ＝１〜Ｎ）の中から歌詞イベントを抽出し、そのイベントデータ、即ち、歌詞データを歌詞イベントバッファ１２ａに記憶する歌詞イベント抽出処理を実行する（Ｓ５）。なお、この歌詞イベント抽出処理（Ｓ５）で実行される具体的処理については、図５を参照しつつ後述する。

歌詞イベント抽出処理（Ｓ５）の実行後、歌詞イベントバッファ１２ａに記憶されている歌詞データに含まれる元歌詞データを抽出し、ＯＲＬバッファ１２ｂに記憶する元歌詞データ生成処理を実行する（Ｓ６）。なお、この元歌詞データ生成処理（Ｓ６）で実行される具体的処理については、図６を参照しつつ後述する。

元歌詞データ生成処理（Ｓ６）の実行後、ＯＲＬバッファ１２ｂに記憶されている元歌詞データの中から、Ｓ２の処理により入力が確認された検索文字列を検索し（Ｓ７）、検索文字列が見つかったかを確認する（Ｓ８）。

Ｓ８の処理により確認した結果、検索文字列が見つからなければ（Ｓ８：Ｎｏ）、歌詞イベントバッファ１２ａに記憶されている歌詞データからルビ歌詞データを抽出し、ＲＢＬバッファ１２ｃに記憶するルビ歌詞データ生成処理を実行する（Ｓ９）。なお、このルビ歌詞データ生成処理（Ｓ９）で実行される具体的処理については、図７を参照しつつ後述する。

ルビ歌詞データ生成処理（Ｓ９）の実行後、ＲＢＬバッファ１２ｃに記憶されているルビ歌詞データの中から、Ｓ２の処理により入力が確認された検索文字列を検索し（Ｓ１０）、検索文字列が見つかったかを確認する（Ｓ１１）。

Ｓ１１の処理により確認した結果、ＲＢＬバッファ１２ｃに記憶されているルビ歌詞データの中から検索文字列が見つかった場合には（Ｓ１１：Ｙｅｓ）、現在検索中のＳＭＦ、即ち、Ｓ４の処理によってＲＡＭ１２内の所定のエリアにロードされた第ｎファイル１３ａｎ（ｎは、１〜Ｎのうち現在設定されている値）のファイル名を、ＬＣＤ１５に表示又は追加表示する対象ファイル表示処理を実行し（Ｓ１４）、Ｓ１２の処理へ移行する。

一方で、Ｓ１１の処理により確認した結果、検索文字列が見つからなければ（Ｓ１１：Ｎｏ）、現在検索中のＳＭＦに含まれる歌詞データには、検索文字列に該当する歌詞が存在しなかったとし、この場合もまたＳ１２の処理へ移行する。

また、Ｓ８の処理により確認した結果、ＯＲＬバッファ１２ｂに記憶されている元歌詞データの中から検索文字列が見つかった場合には（Ｓ８：Ｙｅｓ）、対象ファイル表示処理を実行し（Ｓ１４）、Ｓ１２の処理へ移行する。つまり、ＯＲＬバッファ１２ｂに記憶されている元歌詞データの中から検索文字列が見つかり、Ｓ８におけるＹｅｓの分岐処理が実行された場合には、ルビ歌詞データ生成処理（Ｓ９）からＳ１１までの処理がスキップされ、その結果、ルビ歌詞データ生成処理（Ｓ９）によるルビ歌詞データの生成又はルビ歌詞データを検索対象とする検索のいずれも行われない。

なお、「特許請求の範囲」における、請求項５の「歌詞データの生成を禁止する」は、「歌詞データを生成する処理を実行しない（処理をスキップする）ことにより、歌詞データを生成しない」ことを意味し、例えば、本実施形態では、Ｓ８におけるＹｅｓの分岐処理の実行によってルビ歌詞データ生成処理（Ｓ９）がスキップされ、その結果として、ルビ歌詞データが生成されないことに相当する。同様に、「特許請求の範囲」における、請求項４の「検索の実行を禁止する」は、「検索処理を実行しない（処理をスキップする）ことによって検索を行わない」ことを意味し、例えば、本実施形態では、Ｓ８におけるＹｅｓの分岐処理の実行によってＳ１０の処理がスキップされ、その結果として、ルビ歌詞データを検索対象とする検索が実行されないことに相当する。

Ｓ１２では、現在検索中のＳＭＦがＨＤＤ１３に記憶されている最後のＳＭＦ（第Ｎファイル１３ａＮ）であるか、即ち、変数ｎが「Ｎ」であるかを確認する（Ｓ１２）。ここで、Ｓ１２の処理により確認した結果、変数ｎがＮであれば（Ｓ１２：Ｙｅｓ）、検索すべきＳＭＦはＨＤＤ１３内に残っていないので、このメイン処理を終了する。

一方で、Ｓ１２の処理により確認した結果、変数ｎがＮでなければ（Ｓ１２：Ｎｏ）、検索すべきＳＭＦがＨＤＤ１３内にまだ残っているので、変数ｎに１を加算し（Ｓ１３）、Ｓ４の処理へ移行し、次のＳＭＦに対し、Ｓ４〜Ｓ１１，Ｓ１４の処理を実行する。

よって、歌詞検索装置５０で実行される上述したメイン処理（図４）によれば、ＯＲＬバッファ１２ｂに記憶されている元歌詞データと、ＲＢＬバッファ１２ｃに記憶されているルビ歌詞データとの両方を検索対象として、歌詞検索を行うことができるので、元歌詞に含まれる文字列を検索文字列とするか、あるいは、ルビ歌詞に含まれる文字列を検索文字列とするかといったようなユーザによる個人差が生じる場合であっても、良好な検索効率で歌詞検索できる。

特に、従来の歌詞検索では、ルビ歌詞に含まれる文字列を検索文字列とした場合に、検索効率がより悪化する傾向が顕著であったが、元歌詞データとルビデータとを混在して含む歌詞データから、ルビ歌詞データを生成（再現）したことにより、ルビ歌詞に含まれる文字列を検索文字列とした場合の検索効率を向上させることができ、歌詞検索をする上で有用となる。

また、検索文字列が、ＯＲＬバッファ１２ｂに記憶されている元歌詞データの中から先に見つかった場合には、ルビ歌詞データについて検索を行わないので、無駄な検索に時間を費やすことを防止することができ、速い検索速度で結果を得ることができる。

ここで、図５を参照して、上述した歌詞イベント抽出処理（Ｓ５）について説明する。図５に示すように、歌詞イベント抽出処理（Ｓ５）では、まず、歌詞イベントバッファ１２ａをクリアすると共に、トラック番号を「１」に設定する（Ｓ５０１）。なお、「トラック番号」は、個々のトラックチャンクに付された番号である。例えば、図２（ａ）に示した第１ファイル１３ａ１には、２つのトラックチャンク５２，５３があるので、トラック番号「１」は、トラックチャンク（１）５２を示すトラック番号であり、トラック番号「２」は、トラックチャンク（２）５３を示すトラック番号である。

Ｓ５０１の処理後、１つのイベントを読み出し（Ｓ５０２）、読み出したイベントが歌詞イベントであるかを確認する（Ｓ５０３）。

Ｓ５０３の処理により確認した結果、歌詞イベントであれば（Ｓ５０３：Ｙｅｓ）、歌詞イベントにおける領域６４（図３参照）に格納されている歌詞データの先頭に、歌詞イベント開始マークＫＳ（図８（ａ）参照）として文字「Le」を付したものを歌詞イベントバッファ１２ａに記憶し（Ｓ５０４）、Ｓ５０５の処理へ移行する。

一方で、Ｓ５０３の処理により確認した結果、歌詞イベントでない、即ち、歌詞イベント以外のイベントであれば（Ｓ５０３：Ｎｏ）、Ｓ５０４の処理を実行することなく、Ｓ５０５の処理へ移行する。

Ｓ５０５では、現在処理中のトラックチャンク、即ち、現在設定されているトラック番号のトラックチャンクにおける最後のイベント（エンド・オブ・トラック）であるかを確認する（Ｓ５０５）。Ｓ５０５の処理により確認した結果、処理中のトラックチャンクにおける最後のイベントでなければ（Ｓ５０５：Ｎｏ）、Ｓ５０２の処理へ移行し、次のイベントに対し、Ｓ５０２〜Ｓ５０５の処理を実行する。

また、Ｓ５０５の処理により確認した結果、処理中のトラックチャンクにおける最後のイベントである場合には（Ｓ５０５：Ｙｅｓ）、未処理のトラックチャンクがあるかを確認し（Ｓ５０６）、未処理のトラックチャンクがなければ（Ｓ５０６：Ｎｏ）、この歌詞イベント抽出処理（Ｓ５）を終了する。

一方で、Ｓ５０６の処理により確認した結果、未処理のトラックチャンクがあれば（Ｓ５０６：Ｙｅｓ）、トラック番号に１加算し（Ｓ５０７）、Ｓ５０２の処理へ移行し、Ｓ５０２〜Ｓ５０５の処理を実行し、次のトラックチャンクに対し、そのトラックチャンクに含まれる歌詞イベントの歌詞データを、歌詞イベントバッファ１２ａに記憶する。

この歌詞イベント抽出処理（Ｓ５）によれば、歌詞イベントバッファ１２ａには、１つのＳＭＦに含まれる全ての歌詞イベントのイベントデータ、即ち、１曲分の歌詞データが、時系列（曲の進行順）に記憶されると共に、歌詞イベント開始マークＫＳの介在によって歌詞イベントの単位を区別可能に記憶されることになる。

例えば、図３（ｂ）における区間Ａに含まれる歌詞イベントＫ１〜Ｋ８のイベントデータ（歌詞データ）は、図８（ａ）に示すように歌詞イベントバッファ１２ａに記憶される。なお、理解を容易にする目的で、図８（ａ）では、歌詞イベントバッファ１２ａに記憶されているデータを、２バイトの文字コードに対応する文字（２バイトの文字）として図示している。

図８（ａ）に示すように、各歌詞イベントの歌詞データは、歌詞イベント抽出処理（Ｓ５）の結果として先頭に付された歌詞イベント開始マーク（Le）ＫＳにより、それぞれ論理的に区別することができる状態で、歌詞イベントバッファ１２ａに記憶されている。

なお、上述したように、元歌詞に含まれる文字に対してルビを付す場合には、ルビを付す対象とする元歌詞データＯＲを構成する全ての文字を、同一の歌詞イベントにおける領域６４内に記述することを条件とする。従って、１つの歌詞イベントの歌詞データにルビ開始マークＲＳが含まれている場合には、同一の歌詞イベント内の歌詞データにおいて、ルビ開始マークＲＳの前方に隣接する文字を少なくとも含み、１又は複数の文字から構成される元歌詞データＯＲが、ルビ対象データＯＲ’に相当する。

よって、歌詞イベント開始マークＫＳの付加により、各歌詞イベントの歌詞データが論理的に区別できるようになった結果として、１つの歌詞イベントに含まれるルビデータＲＢとルビ対象データＯＲ’とを論理的に区別することが可能となる。

次に、図６を参照して、上述した元歌詞データ生成処理（Ｓ６）について説明する。図６に示すように、元歌詞データ生成処理（Ｓ６）では、まず、ＯＲＬバッファ１２ｂをクリアすると共に、ルビフラグ１２ｄを「０」に設定する（Ｓ６０１）。

Ｓ６０１の処理後、歌詞イベントバッファ１２ａからの文字の読み出しが終了したか、即ち、後述するＳ６０３〜Ｓ６１０の処理が、歌詞イベントバッファ１２ａに記憶されている全ての文字に対して実行済みであるかを確認し（Ｓ６０２）、歌詞イベントバッファ１２ａからの文字の読み出しが終了していれば（Ｓ６０２：Ｙｅｓ）、この元歌詞データ生成処理（Ｓ６）を終了する。

一方で、Ｓ６０２の処理により確認した結果、歌詞イベントバッファ１２ａからの文字の読み出しが未だ終了していなければ（Ｓ６０２：Ｎｏ）、歌詞イベントバッファ１２ａから１文字を読み出す（Ｓ６０３）。

ここで、Ｓ６０２の処理、即ち、歌詞イベントバッファ１２ａからの文字の読み出しが終了したか否かの判定は、図示されないカウンタを用いて行うことができる。具体的には、上述した歌詞イベント抽出処理（図５）において、歌詞イベントを歌詞イベントバッファ１２ａに記憶する毎に、記憶したデータサイズ（文字数）をカウンタに加算しておき、その後、Ｓ６０３の処理により、歌詞イベントバッファ１２ａから文字を読み出す毎に、読み出したデータサイズ（文字数）を減算する。そして、該カウンタの値がゼロとなった場合に、歌詞イベントバッファ１２ａからの文字の読み出しが終了したと判定する。

Ｓ６０３の処理後、読み出した文字が歌詞イベント開始マークＫＳであるかを確認する（Ｓ６０４）。Ｓ６０４の処理により確認した結果、読み出した文字が歌詞イベント開始マークＫＳであれば（Ｓ６０４：Ｙｅｓ）、何も行うことなくＳ６０２の処理へ移行し、続いて実行されるＳ６０３の処理により次の１文字を読み出す。即ち、Ｓ６０２の処理によって読み出された文字が歌詞イベント開始マークＫＳである場合には、この歌詞イベント開始マークＫＳを読み飛ばし、次の１文字を読み出す。

一方で、Ｓ６０４の処理により確認した結果、歌詞イベント開始マークＫＳでなければ（Ｓ６０４：Ｎｏ）、ルビフラグ１２ｄが「１」であるかを確認する（Ｓ６０５）。ここで、ルビフラグ１２ｄが「１」でなければ（Ｓ６０５：Ｎｏ）、読み出した文字がルビ開始マークＲＳであるかを確認する（Ｓ６０６）。

Ｓ６０６の処理により確認した結果、読み出した文字がルビ開始マークＲＳでなければ（Ｓ６０６：Ｎｏ）、読み出した文字は、元歌詞データＯＲの文字であるので、読み出した文字をＯＲＬバッファ１２ｂに記憶し（Ｓ６０７）、Ｓ６０２の処理へ移行し、歌詞イベントバッファ１２ａからの文字の読み出しが未だ終了していなければ（Ｓ６０２：Ｎｏ）、次の１文字を読み出す（Ｓ６０３）。

一方、Ｓ６０６の処理により確認した結果、読み出した文字がルビ開始マークＲＳであれば（Ｓ６０６：Ｙｅｓ）、ルビフラグ１２ｄを「１」に設定し（Ｓ６０８）、Ｓ６０２の処理へ移行し、歌詞イベントバッファ１２ａからの文字の読み出しが未だ終了していなければ（Ｓ６０２：Ｎｏ）、次の１文字を読み出す（Ｓ６０３）。

よって、Ｓ６０８の処理の結果、読み出された文字がルビ開始マークＲＳである場合には、そのルビ開始マークＲＳを読み飛ばすと共に、ルビフラグ１２ｄを「１」に設定したことによって、次に読み出される文字を、ルビデータＲＢの文字として識別させることができる。

また、Ｓ６０５の処理により確認した結果、ルビフラグ１２ｄが「１」である場合には（Ｓ６０５：Ｙｅｓ）、読み出した文字がルビ終了マークＲＥであるかを確認し（Ｓ６０９）、ルビ終了マークＲＥでなければ（Ｓ６０９：Ｎｏ）、読み出した文字は、ルビデータＲＢの文字であるので、何も行うことなくＳ６０２の処理へ移行し、歌詞イベントバッファ１２ａからの文字の読み出しが未だ終了していなければ（Ｓ６０２：Ｎｏ）、次の１文字を読み出す（Ｓ６０３）。

一方、Ｓ６０９の処理により確認した結果、読み出した文字がルビ終了マークＲＥであれば（Ｓ６０９：Ｙｅｓ）、ルビフラグ１２ｄを「０」に設定し（Ｓ６１０）、Ｓ６０２の処理へ移行し、歌詞イベントバッファ１２ａからの文字の読み出しが未だ終了していなければ（Ｓ６０２：Ｎｏ）、次の１文字を読み出す（Ｓ６０３）。

よって、Ｓ６１０の処理の結果、読み出された文字がルビ終了マークＲＥである場合には、そのルビ開始マークＲＥを読み飛ばすと共に、ルビフラグ１２ｄを「０」に設定したことによって、次に読み出される文字を、元歌詞データＯＲの文字として識別させることができる。

この元歌詞データ生成処理（Ｓ６）によれば、１つのＳＭＦから時系列（曲の進行順）に抽出された元歌詞データＯＲがＯＲＬバッファ１２ｂに記憶される。従って、１つのＳＭＦから元歌詞データＯＲを時系列に並べたデータ、即ち、元歌詞（文字によって記述される見かけ上の歌詞）を再現するデータがＯＲＬバッファ１２ｂ内に生成されることとなる。

例えば、元歌詞データ生成処理（Ｓ６）の実行後、図３（ｂ）における区間Ａに含まれる歌詞イベントＫ１〜Ｋ８のイベントデータ（歌詞データ）は、元歌詞データＯＲのみが抽出されて、図８（ｂ）に示すようにＯＲＬバッファ１２ｂに記憶され、元歌詞である「横浜の人待つ」を再現する。なお、理解を容易にする目的で、図８（ｂ）では、ＯＲＬバッファ１２ｂに記憶されているデータを、２バイトの文字コードに対応する文字（２バイトの文字）として図示している。

次に、図７を参照して、上述したルビ歌詞データ生成処理（Ｓ９）について説明する。図７に示すように、ルビ歌詞データ生成処理（Ｓ９）では、まず、ＲＢＬバッファ１２ｃをクリアすると共に、ルビフラグ１２ｄを「０」に設定し、消去文字数カウンタ１２ｅを「０」に設定する（Ｓ７０１）。

Ｓ７０１の処理後、歌詞イベントバッファ１２ａからの文字の読み出しが終了したか否かを、Ｓ６０２（図６参照）と同様の処理によって確認する（Ｓ７０２）。Ｓ７０２の処理により確認した結果、歌詞イベントバッファ１２ａからの文字の読み出しが終了していれば（Ｓ７０２：Ｙｅｓ）、このルビ歌詞データ生成処理（Ｓ９）を終了する。

一方で、Ｓ７０２の処理により確認した結果、歌詞イベントバッファ１２ａからの文字の読み出しが未だ終了していなければ（Ｓ７０２：Ｎｏ）、歌詞イベントバッファ１２ａから１文字を読み出す（Ｓ７０３）。

Ｓ７０３の処理後、読み出した文字が歌詞イベント開始マークＫＳであるかを確認する（Ｓ７０４）。Ｓ７０４の処理により確認した結果、読み出した文字が歌詞イベント開始マークＫＳであれば（Ｓ７０４：Ｙｅｓ）、ルビフラグ１２ｄが「１」であるかを確認する（Ｓ７０５）。ここで、ルビフラグ１２ｄが「１」であれば（Ｓ７０５：Ｙｅｓ）、１の歌詞イベントのイベントデータ（歌詞データ）の最初がルビデータＲＢから始まっているので、何も行うことなくＳ７０２の処理へ移行し、続いて実行されるＳ６０３の処理により、次の１文字を読み出す。即ち、読み出された文字が、歌詞データの最初がルビデータＲＢである歌詞イベントに対して付された、歌詞イベント開始マークＫＳである場合には、この歌詞イベント開始マークＫＳを読み飛ばし、次の１文字を読み出す。

一方で、Ｓ７０５の処理により確認した結果、ルビフラグ１２ｄが「０」である場合には（Ｓ７０５：Ｎｏ）、１の歌詞イベントのイベントデータ（歌詞データ）の最初が元歌詞データＯＲから始まっているので、消去文字数カウンタ１２ｅを「０」に設定し（Ｓ７０６）、Ｓ７０２の処理へ移行し、歌詞イベントバッファ１２ａからの文字の読み出しが未だ終了していなければ（Ｓ７０２：Ｎｏ）、次の１文字を読み出す（Ｓ７０３）。

よって、Ｓ７０６の処理の結果、読み出された文字が、歌詞データの最初が元歌詞データＯＲである歌詞イベントに対して付された、歌詞イベント開始マークＫＳである場合には、その歌詞イベント開始マークＫＳを読み飛ばすと共に、消去文字数カウンタ１２ｅを「０」に設定したことによって、次に読み出される予定の文字（元歌詞データＯＲ）から、同じ歌詞イベント内にてルビ開始マークＲＳが読み出されるまで、ＲＢＬバッファ１２ｃに記憶させた元歌詞データＯＲの文字数を記憶させることができる。

また、Ｓ７０４の処理により確認した結果、歌詞イベント開始マークＫＳでなければ（Ｓ７０４：Ｎｏ）、ルビフラグ１２ｄが「１」であるかを確認する（Ｓ７０７）。ここで、ルビフラグ１２ｄが「１」でなければ（Ｓ７０７：Ｎｏ）、読み出した文字がルビ開始マークＲＳであるかを確認する（Ｓ７０８）。

Ｓ７０８の処理により確認した結果、読み出した文字がルビ開始マークＲＳでなければ（Ｓ７０８：Ｎｏ）、消去文字数カウンタ１２ｅに１加算し（Ｓ７１１）、読み出した文字をＲＢＬバッファ１２ｃに記憶する（Ｓ７１３）。即ち、消去文字数カウンタ１２ｅを「０」に設定した後、ＲＢＬバッファ１２ｃに元歌詞データＯＲが記憶される毎に、消去文字数カウンタ１２ｅの値がカウントアップされる。

Ｓ７１３の処理後、Ｓ７０２の処理へ移行し、、歌詞イベントバッファ１２ａからの文字の読み出しが未だ終了していなければ（Ｓ７０２：Ｎｏ）、次の１文字を読み出す（Ｓ７０３）。

一方、Ｓ７０８の処理により確認した結果、読み出した文字がルビ開始マークＲＳであれば（Ｓ７０８：Ｙｅｓ）、ＲＢＬバッファ１２ｃに記憶されている文字の末尾から、消去文字数カウンタ１２ｅの値が示す数の文字を消去する（Ｓ７０９）。このＳ７０９の処理の結果、消去文字数カウンタ１２ｅが「０」に設定されてから、ルビ開始マークＲＳが読み出されるまで、ＲＢＬバッファ１２ｃに記憶させた元歌詞データＯＲを、ルビ対象データＯＲ’として、ＲＢＬバッファ１２ｃから消去することができる。

Ｓ７０９の処理後、ルビフラグ１２ｄを「１」に設定すると共に、消去文字数カウンタ１２ｅを「０」に設定し（Ｓ７１０）、Ｓ７０２の処理へ移行し、歌詞イベントバッファ１２ａからの文字の読み出しが未だ終了していなければ（Ｓ７０２：Ｎｏ）、次の１文字を読み出す（Ｓ７０３）。

よって、Ｓ７１０の処理の結果、読み出された文字がルビ開始マークＲＳである場合には、そのルビ開始マークＲＳを読み飛ばすと共に、ルビフラグ１２ｄを「１」に設定したことによって、次に読み出される文字を、ルビデータＲＢの文字として識別させることができる。また、Ｓ７１０の結果、消去文字数カウンタ１２ｅが「０」に設定されるので、同一の歌詞イベント内であれば、ルビ終了マークＲＥの後に続く、元歌詞データＯＲの文字数をカウントすることができる。

また、Ｓ７０７の処理により確認した結果、ルビフラグ１２ｄが「１」である場合には（Ｓ７０７：Ｙｅｓ）、読み出した文字がルビ終了マークＲＥであるかを確認し（Ｓ７１２）、ルビ終了マークＲＥであれば（Ｓ７１２：Ｙｅｓ）、ルビフラグ１２ｄを「０」に設定し（Ｓ７１４）、Ｓ７０２の処理へ移行し、歌詞イベントバッファ１２ａからの文字の読み出しが未だ終了していなければ（Ｓ７０２：Ｎｏ）、次の１文字を読み出す（Ｓ７０３）。

よって、Ｓ７１４の処理の結果、読み出された文字がルビ終了マークＲＥである場合には、そのルビ開始マークＲＥを読み飛ばすと共に、ルビフラグ１２ｄを「０」に設定したことによって、次に読み出される文字を、元歌詞データＯＲの文字として識別させることができる。

一方で、Ｓ７１２の処理により確認した結果、読み出した文字がルビ終了マークＲＥでなければ（Ｓ７１２：Ｎｏ）、読み出した文字は、ルビデータＲＢの文字であるので、読み出した文字をＲＢＬバッファ１２ｃに記憶し（Ｓ７１３）、Ｓ７０２の処理へ移行し、歌詞イベントバッファ１２ａからの文字の読み出しが未だ終了していなければ（Ｓ７０２：Ｎｏ）、次の１文字を読み出す（Ｓ７０３）。

このルビ歌詞データ生成処理（Ｓ９）によれば、Ｓ７０９の処理の結果として、ＲＢＬバッファ１２ｃに記憶させた元歌詞データＯＲのうち、ルビ対象データＯＲ’に相当するデータがＲＢＬバッファ１２ｃから消去される一方で、Ｓ７１３の処理の結果として、ルビ開始マークＲＳとルビ終了マークＲＥとによって囲まれたルビデータＲＢが、ＲＢＬバッファ１２ｃに書き込まれる。即ち、ルビ対象データＯＲ’がルビデータＲＢに置換される。その結果として、ＲＢＬバッファ１２ｃには、ルビの付されていない元歌詞データＯＲ（元歌詞データＯＲからルビ対象データＯＲ’を除いたもの）とルビデータＲＢとが合成された歌詞データ、即ち、ルビ歌詞データが生成され、ＲＢＬバッファ１２ｃに記憶される。

つまり、このルビ歌詞データ生成処理（Ｓ９）によれば、ＲＢＬバッファ１２ｃには、１つのＳＭＦに含まれる全ての歌詞イベントのイベントデータ、即ち、１曲分の歌詞データが、時系列（曲の進行順）に一旦記憶されるが、ルビの付される元歌詞データＯＲ（ルビ対象データＯＲ’）は消去されるので、最終的にはルビ歌詞データが記憶されていることとなる。

例えば、ルビ歌詞データ生成処理（Ｓ９）の実行後、図３（ｂ）における区間Ａに含まれる歌詞イベントＫ１〜Ｋ８のイベントデータ（歌詞データ）は、図８（ｃ）に示すように、ルビ歌詞である「ハマのおんなまつ」に対応するルビ歌詞データとしてＲＢＬバッファ１２ｃに記憶されることになる。なお、理解を容易にする目的で、図８（ｃ）では、ＲＢＬバッファ１２ｃに記憶されているデータを、２バイトの文字コードに対応する文字（２バイトの文字）として図示している。

以上説明したように、本実施形態の歌詞検索装置５０によれば、ルビ歌詞データ生成処理（図７参照）により、元歌詞データとルビデータとが曲の進行順に混在して構成されている歌詞データから、ルビ歌詞データが生成されてＲＢＬバッファ１２ｃ内に記憶されるので、歌唱時に実際に発音する歌詞（発音上の歌詞、即ち、ルビ歌詞）に含まれる文字列を検索文字列とした場合であっても、良好な検索効率で歌詞検索をすることができる。

一般的に、ユーザが歌詞検索を行う際には、文字によって記述される見かけの歌詞（元歌詞）に比べてより強く印象に残っているルビ歌詞を検索文字列として入力されるケースが多いので、ルビ歌詞を検索文字列とした場合に、良好な検索効率で歌詞検索でき、非常に好適である。

また、本実施形態の歌詞検索装置５０によれば、元歌詞データ生成処理（図６参照）により、元歌詞データとルビデータとが曲の進行順に混在して構成されている歌詞データから、元歌詞データが生成されてＯＲＬバッファ１２ｂに記憶されるので、元歌詞を検索文字列として用いた検索にも適用可能である。よって、元歌詞に含まれる文字列を検索文字列とするか、あるいは、ルビ歌詞に含まれる文字列を検索文字列とするかといったようなユーザによる個人差が生じる場合であっても、良好な検索効率で歌詞検索できる。

以上、各実施形態に基づき本発明を説明したが、本発明は上述した実施形態に何ら限定されるものではなく、本発明の趣旨を逸脱しない範囲内で、種々の改良変更が可能であることは容易に推察できるものである。

例えば、上記実施形態では、ＳＭＦの歌詞データから、元歌詞データ及びルビ歌詞データをそれぞれ生成できる構成としたが、ＳＭＦの歌詞データに限定されるものではなく、元歌詞に含まれる文字とルビとが論理的に区別可能な形式の歌詞データであれば、適用可能である。

また、上記実施形態では、トラックチャンク（１）５２及びトラックチャンク（２）５３のそれぞれにＭＩＤＩイベントと歌詞イベントとが混在しているタイプのＳＭＦを用いる構成としたが、１曲分の演奏データ（ＭＩＤＩイベントなど）と１曲分の歌詞イベントとが、それぞれ別々にトラックチャンクに格納されているタイプのＳＭＦを用いる構成としてもよい。

また、上記実施形態では、フォーマット１のＳＭＦを例に説明したが、フォーマット１の場合に限定することを意図するものではなく、ＳＭＦにおけるその他のフォーマット、例えば、フォーマット０に対しても、上記実施形態を同様に適用することができる。

また、上記実施形態では、ＳＭＦを用いて例示したので、各歌詞イベントの歌詞データを論理的に区別させるために、歌詞イベント抽出処理（図５参照）におけるＳ５０４の処理によって、各歌詞イベントの歌詞データの先頭に歌詞イベント開始マークＫＳを付す構成とした。これに対し、各歌詞イベントの歌詞データの先頭に、所定の歌詞イベント開始マークが予め記述されたデータを使用してもよく、この場合には、上記実施形態のように、歌詞イベント抽出処理（図５参照）により歌詞イベント開始マークＫＳを付さずとも、各歌詞イベントの歌詞データを論理的に区別できる。

また、上記実施形態では、メイン処理（図４参照）において、ＯＲＬバッファ１２ｂに記憶されている元歌詞データの中から検索文字列が見つからなかった場合に、ルビ歌詞データを生成する構成としたが、予め、元歌詞データとルビ歌詞データを生成しておく構成であってもよい。なお、この構成において、元歌詞データ又はルビ歌詞データの一方に対して先に検索を行い、検索文字列が見つかった場合には、他方の歌詞データに対する検索を行わないようにすることにより、無駄な検索に時間を費やすことを防止することができる。

また、上記実施形態では、元歌詞データ及びルビ歌詞データの２種類を生成できる構成としたが、ルビ歌詞データのみを生成する構成としてもよい。

また、上記実施形態では、歌詞データから、元歌詞データと、元歌詞データにおける少なくとも一部の文字を対応するルビ（即ち、その文字の読みを示す仮名）に置換したルビ歌詞データとを生成する構成としたが、元歌詞データにおける少なくとも一部の文字に対して、読み方とは無関係に、文字を特徴づけたり説明したりする目的で付された仮名文字列や英数字文字列が対応付けられている場合に、元歌詞データにおける該当文字を、そのような仮名文字列や英数字文字列に置換して得られた歌詞データを生成して、検索対象として利用する構成としてもよい。

また、上記実施形態では、元歌詞データ生成処理（図６参照）及びルビ歌詞データ生成処理（図７参照）により、元歌詞データ及びルビ歌詞データは、いずれも１曲分全てが生成されるように構成したが、一部ずつ区切って生成して検索させるように構成してもよい。

また、１曲分全ての元歌詞データ及びルビ歌詞データを生成することに換えて、１曲における特定の部分、例えば、一番の歌詞やサビの歌詞のみに対し、元歌詞データ、及びルビ歌詞データを生成して検索させるように構成してもよい。なお、「１曲における特定の部分」は、予め規定されている特定の部分であっても、ユーザによって指定された特定の部分であってもよい。

また、１曲分全ての元歌詞データ、及びルビ歌詞データを生成することに換えて、ＳＭＦにおける表示に関する情報、例えば、キャリッジリターン（ＣＲ）やラインフィード（ＬＦ）などを区切りとして元歌詞データ及びルビ歌詞データを生成し、いずれか一方、又は、両方を交互に検索するように構成してもよい。

また、デルタタイム５５が示す値の時間差を考慮するなどして、文脈、文節、又は単語の切れなどを判別する判別手段を設け、これらの判別手段によって判別された単位（文脈、文節、又は単語の単位）で、検索文字列と比較する構成としてもよい。一般的に、検索文字列は、文脈、文節、又は単語などの決まった単位で入力されるので、予め文脈、文節、又は単語などの単位を明確にしておくことにより、検索効率をより向上させることができる。

また、ＯＲＬバッファ１２ｂに記憶されている元歌詞データ、及びＲＢＬバッファ１２ｃに記憶されているルビ歌詞データに含まれる各文字の時間的対応関係をつけた上で、検索文字列を所定の単位（文脈、文節、又は単語の単位）に分割する分割手段を設け、その分割手段によって分割された単位（文脈、文節、又は単語の単位）毎に、元歌詞データ、及びルビ歌詞データに対して検索するように構成してもよい。このとき、分割手段によって分割された単位（文脈、文節、又は単語の単位）が、一部は元歌詞データから見つかり、残りがルビ歌詞データから見つかった場合に、それらが、元歌詞データ、及びルビ歌詞データに含まれる各文字の時間的対応関係から、一連の歌詞をなすと推定される場合に、検索文字列がみつかったと判断するようにすればよい。元歌詞とルビ歌詞とを混同して記憶しているユーザがいることも考えられるので、このように検索文字列を所定の単位に分割し、その分割された単位毎に、元歌詞データ、及びルビ歌詞データに対して検索することは、検索効率の向上という点で有用である。

また、検索文字列と被検索文字列（上記実施形態では、ＯＲＬバッファ１２ｂに記憶されている元歌詞データ、及びＲＢＬバッファ１２ｃに記憶されているルビ歌詞データ）とに対し、予め定義されている規則（例えば、ひらがなを全てカタカナに変換する、スペースをすべて省く、句読点をすべて省く、など）に従う置換（プリプロセス）を実行する構成としてもよい。このように、検索文字列と被検索文字列とに対して同じ処理を経由させることにより、表記の違いを吸収させることができ、検索効率をより向上させることができる。

また、上記実施形態は、歌詞部分、即ち、ＳＭＦにおける歌詞データから元歌詞データとルビ歌詞データとを生成し、元歌詞（見かけの歌詞）、又はルビ歌詞のいずれに対しても歌詞検索を可能とするものであったが、検索対象は歌詞部分に限定されるものではない。例えば、ＭＩＤＩガイドラインにおいて、ルビを付すことが可能であるとされている曲情報部分（例えば、曲名や、作曲者名や、演奏者名など）に対しても、上記実施形態を同様に適用することができる。

なお、上記実施形態において、請求項１又は５に記載の第１の歌詞データ記憶手段としては、歌詞イベントバッファ１２ａが該当し、請求項１記載の第２の歌詞データ生成手段、又は請求項５記載の第２の歌詞データ生成ステップとしては、ルビ歌詞データ生成処理（Ｓ９）が該当し、請求項１又は５に記載の第２の歌詞データ記憶手段としては、ＲＢＬバッファ１２ｃが該当し、請求項１記載の検索文字列入力手段としては、キーボード１４が該当し、請求項１記載の検索手段、又は請求項５記載の検索ステップとしては、Ｓ１０の処理が該当する。

また、上記実施形態において、請求項２記載の第３の歌詞データ生成手段としては、元歌詞データ生成処理（Ｓ６）が該当し、請求項２記載の第３の歌詞データ記憶手段としては、ＯＲＬバッファ１２ｂが該当し、請求項２記載の検索手段としては、Ｓ７の処理又はＳ１０の処理が該当する。

また、上記実施形態において、請求項３記載の第１の検索手段としては、Ｓ７の処理が該当し、請求項３記載の第２の検索手段としては、Ｓ１０の処理が該当し、請求項３記載の検索終了手段としては、Ｓ８におけるＹｅｓの分岐処理が該当する。

また、上記実施形態において、請求項４記載の歌詞データ生成待機手段としては、Ｓ８の処理が該当し、請求項４記載の検索終了手段としては、Ｓ８におけるＹｅｓの分岐処理が該当する。

本発明における一実施形態の歌詞検索装置を搭載する、自動演奏装置の構成を示したブロック図である。 （ａ）は、ＳＭＦのデータ構成を示す模式図であり、（ｂ）は、（ａ）に示したＳＭＦにおける、トラックチャンクに格納されるデータ本体のデータ構成を示す模式図である。 （ａ）は、メタイベントのデータ構成を示す模式図であり、（ｂ）は、歌詞イベントを示す模式図であり、（ｃ）は、（ｂ）における歌詞イベントＫ１，Ｋ２のイベントデータ部分を示す模式図である。 歌詞検索装置で歌詞検索を行う場合のメイン処理を示すフローチャートである。 図４のメイン処理の中で実行される歌詞イベント抽出処理を示すフローチャートである。 図４のメイン処理の中で実行される元歌詞データ生成処理を示すフローチャートである。 図４のメイン処理の中で実行されるルビ歌詞データ生成処理を示すフローチャートである。 （ａ）は、歌詞イベント抽出処理の実行結果を示す模式図であり、（ｂ）は、元歌詞データ生成処理の実行結果を示す模式図であり、（ｃ）は、ルビ歌詞データ生成処理の実行結果を示す模式図である。

符号の説明

１ 自動演奏楽器
１２ａ 歌詞イベントバッファ（第１の歌詞データ記憶手段）
１２ｂ ＯＲＬバッファ（第３の歌詞データ記憶手段）
１２ｃ ＲＢＬバッファ（第２の歌詞データ記憶手段）
１２ｄ ルビフラグ
１２ｅ 消去文字数カウンタ
１３ａＮ 第Ｎファイル
５０ 歌詞検索装置
ＯＲ 元歌詞データ
ＯＲ’ ルビ対象データ（ルビによって置換される元歌詞）
ＲＢ ルビデータ（付加的歌詞データ）

Claims (5)

1. 文字によって記述される元歌詞データと、その元歌詞データに含まれる少なくとも１つの文字に対して付される付加的歌詞データとを、曲の進行順に、各々論理的に区別可能に混在して含む第１の歌詞データを記憶する第１の歌詞データ記憶手段と、
   前記元歌詞データに含まれる文字のうち、前記付加的歌詞データが付される文字を、対応する前記付加的歌詞データに置換したデータである第２の歌詞データを、前記第１の歌詞データ記憶手段に記憶されている前記第１の歌詞データから生成する第２の歌詞データ生成手段と、
   その第２の歌詞データ生成手段により生成された前記第２の歌詞データを記憶する第２の歌詞データ記憶手段と、
   検索用の文字列を入力する検索文字列入力手段と、
   前記第２の歌詞データ記憶手段に記憶されている前記第２の歌詞データを検索対象として、前記検索文字列入力手段から入力された文字列を検索する検索手段とを備えていることを特徴とする歌詞検索装置。
2. 前記第１の歌詞データ記憶手段に記憶されている前記第１の歌詞データから、前記付加的歌詞データを削除したデータである第３の歌詞データを生成する第３の歌詞データ生成手段と、
   その第３の歌詞データ生成手段により生成された第３の歌詞データを記憶する第３の歌詞データ記憶手段とを備え、
   前記検索手段は、前記第２の歌詞データ記憶手段に記憶されている前記第２の歌詞データ、又は前記第３の歌詞データ記憶手段に記憶されている前記第３の歌詞データの、少なくとも一方を検索対象として、前記検索文字列入力手段から入力された文字列を検索するものであることを特徴とする請求項１記載の歌詞検索装置。
3. 前記検索手段は、
   前記第２の歌詞データ記憶手段に記憶されている前記第２の歌詞データ、又は前記第３の歌詞データ記憶手段に記憶されている前記第３の歌詞データの一方を検索対象として、前記検索文字列入力手段から入力された文字列を検索する第１の検索手段と、
   前記第２の歌詞データ記憶手段に記憶されている前記第２の歌詞データ、又は前記第３の歌詞データ記憶手段に記憶されている前記第３の歌詞データの他方を検索対象として、前記検索文字列入力手段から入力された文字列を検索する第２の検索手段と、
   前記第１の検索手段による検索の結果、前記検索文字列入力手段から入力された文字列に一致する文字列が見つかった場合には、前記第２の検索手段による検索の実行を禁止する検索終了手段とを備えていることを特徴とする請求項２記載の歌詞検索装置。
4. 前記第２の歌詞データ生成手段により生成された第２の歌詞データ、又は前記第３の歌詞データ生成手段により生成された第３の歌詞データの一方を検索対象として、前記検索手段による検索を行う前に、前記第２の歌詞データ、又は前記第３の歌詞データの他方を、前記第２の歌詞データ生成手段、又は前記第３の歌詞データ生成手段によって生成することを待機する歌詞データ生成待機手段と、
   前記検索手段による検索の結果、前記検索文字列入力手段から入力された文字列に一致する文字列が見つかった場合に、前記歌詞データ生成待機手段により待機されている前記第２の歌詞データ生成手段又は前記第３の歌詞データ生成手段による歌詞データの生成を禁止する検索終了手段とを備えていることを特徴とする請求項２記載の歌詞検索装置。
5. 第１の歌詞データ記憶手段に記憶されている歌詞データであって、文字によって記述される元歌詞データと、前記元歌詞データに含まれる少なくとも１つの文字に対して付される付加的歌詞データとを、曲の進行順に、各々論理的に区別可能に混在して含む第１の歌詞データから、前記元歌詞データのうち、前記付加的歌詞データが付される文字を、対応する前記付加的歌詞データに置換した第２の歌詞データを生成し、第２の歌詞データ記憶手段に記憶させる第２の歌詞データ生成ステップと、
   その第２の歌詞データ生成ステップによって前記第２の歌詞データ記憶手段に記憶された第２の歌詞データを検索対象として、入力された検索用の文字列を検索させる検索ステップとを制御装置に実行させるものであることを特徴とする歌詞検索プログラム。
   
   
   
   
   
   

Images