カラオケ装置
【課題】カラオケ装置側で既存の楽曲データをそのまま使用して、ローマ字表記を行い、日本語の判読に不慣れな外国人ユーザーに対して、日本語曲の歌唱を楽しんでもらう。
【解決手段】カラオケ装置１は指定手段で指定された楽曲に対応する楽曲情報を読み出して、再生処理を実行する制御部１４を備え、再生処理は、読み出した楽曲情報に含まれる演奏情報を演奏手段に演奏させる演奏処理と、読み出した楽曲情報に含まれる歌詞情報に基づいて、歌詞文字情報に含まれる文字が漢字の場合、対応するルビ文字情報をローマ字に変換して表示手段に表示させ、歌詞文字情報に含まれる文字が平仮名もしくは片仮名の場合、当該平仮名もしくは片仮名をローマ字に変換して表示手段に表示させる歌詞表示処理を含む。
【解決手段】カラオケ装置１は指定手段で指定された楽曲に対応する楽曲情報を読み出して、再生処理を実行する制御部１４を備え、再生処理は、読み出した楽曲情報に含まれる演奏情報を演奏手段に演奏させる演奏処理と、読み出した楽曲情報に含まれる歌詞情報に基づいて、歌詞文字情報に含まれる文字が漢字の場合、対応するルビ文字情報をローマ字に変換して表示手段に表示させ、歌詞文字情報に含まれる文字が平仮名もしくは片仮名の場合、当該平仮名もしくは片仮名をローマ字に変換して表示手段に表示させる歌詞表示処理を含む。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、楽曲の演奏にあわせて歌唱を楽しむカラオケ装置に関するものであり、特に、演奏に同期して歌詞を表示することのできるカラオケ装置に関するものである。
【背景技術】
【０００２】
従来、カラオケ装置においては、歌唱補助を目的としてディスプレイなどの表示手段に、演奏に同期して歌詞や、日本語の歌詞であれば漢字の読み仮名（通称：ルビ）を表示することが行われている。このようなカラオケ装置では、ユーザは歌詞や漢字の読みを覚えておかなくても気軽に歌唱を楽しむことが可能となっている。
【０００３】
ところで、現在、カラオケは国内ユーザーのみならず、外国のユーザーにおいても好評を得ており、外国人ユーザーの中には、外国曲のみならず日本語の楽曲を歌唱したいというユーザーも増えつつある。
【０００４】
しかしながら、現在のカラオケ装置では日本語曲については、日本語の歌詞表示することが一般的であって、外国人ユーザーが気軽に歌唱を楽しむことは困難である。このような中、特許文献１には、日本語歌詞をローマ字表記することで歌詞の発音を容易にするカラオケ装置が開示されている。このカラオケ装置によれば、ローマ字を読み上げることで、日本語歌詞の発音が容易となる。しかしながら、特許文献１のカラオケ装置では、ローマ字表記を行うために別途データを作成する必要がある。そのため、同じ楽曲であっても、楽曲データをリニューアルすることや、ローマ字表記対応曲を追加する必要がある。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１０−６０６２８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
一方、カラオケ装置では、現状で日本語歌詞でホスト側で作成されて配信された曲数は数十万曲に上り、前述のようにホスト側で、既に配信されてしまった日本語歌詞の曲をローマ字表記対応曲に変更することや、新たに楽曲を作成して追加することは、非常に手間とコストがかかる作業であり、データ追加に伴う容量増加も懸念事項となる。
【０００７】
本発明は、カラオケ装置側で既存の楽曲データをそのまま使用して、ローマ字表記を行い、日本語の判読に不慣れな外国人ユーザーに対して、日本語曲の歌唱を楽しんでもらうことを目的としている。
【課題を解決するための手段】
【０００８】
そのため本発明は、演奏情報と歌詞情報を含む楽曲情報に基づいて再生を行うカラオケ装置において、
前記歌詞情報は、歌詞文字情報と、歌詞文字情報に対応づけられたルビ文字情報を含み、
指定手段で指定された楽曲に対応する前記楽曲情報を読み出して、再生処理を実行する制御部を備え、
前記再生処理は、演奏処理と歌詞表示処理を含み、
前記演奏処理は、読み出した前記楽曲情報に含まれる演奏情報を演奏手段に演奏させ、
前記歌詞表示処理は、読み出した前記楽曲情報に含まれる歌詞情報に基づいて、
前記歌詞文字情報に含まれる文字が漢字の場合、対応するルビ文字情報をローマ字に変換して表示手段に表示させ、
前記歌詞文字情報に含まれる文字が平仮名もしくは片仮名の場合、当該平仮名もしくは片仮名をローマ字に変換して表示手段に表示させることを特徴とする。
【０００９】
さらに本発明にかかるカラオケ装置は、
前記ルビ文字情報に基づいて変換されたローマ字は、変換元となったルビ文字情報のサイズ以内で表示することを特徴とする。
【００１０】
さらに本発明にかかるカラオケ装置において、
前記歌詞表示処理は、１文字先または１文字前の文字を参照してローマ字に変換することを特徴とする。
【００１１】
さらに本発明にかかるカラオケ装置において、
前記歌詞表示処理は、ローマ字への変換対象となる文字が、促音「っ」の場合は１文字先の文字を参照してローマ字に変換する、または、長音符「ー」の場合は１文字前の文字を参照してローマ字に変換することを特徴とする。
【００１２】
さらに本発明にかかるカラオケ装置は、
前記ルビ文字情報に基づいて変換されたローマ字と、平仮名または片仮名に基づいて変換されたローマ字とは、異なる段に表示させることを特徴とする。
【発明の効果】
【００１３】
本発明によれば、日本語曲をローマ字表記することで、日本語の判読に不慣れな外国人ユーザーなどに対して、日本語曲の歌唱を容易にさせることが可能となる。特に、既存の楽曲情報を用いて行うことで、楽曲情報の改変や追加などを必要とせず、機能追加に伴う手間とコストを削減することが可能となる。また、カラオケ装置において、楽曲が指定されてから後に、ローマ字への変換を行うこととなるため、楽曲情報のデータ量増加を伴うこともない。
【図面の簡単な説明】
【００１４】
【図１】本発明の実施形態に係るカラオケ装置の構成を示す図
【図２】本発明の実施形態に係る楽曲データのデータ構成を示す図
【図３】本発明の実施形態に係る歌詞データ（ブロックデータ）と描画結果の例を示す図
【図４】本発明の実施形態に係る楽曲データ再生処理を示すフロー図
【図５】本発明の実施形態に係る歌詞再生処理を示すフロー図
【図６】本発明の実施形態に係る通常ブロック描画処理を示すフロー図
【図７】本発明の実施形態に係るローマ字変換ブロック描画処理を示すフロー図（１）
【図８】本発明の実施形態に係るローマ字変換ブロック描画処理を示すフロー図（２）
【図９】本発明の実施形態に係る「全ルビ」の楽曲の歌詞表示例
【図１０】本発明の実施形態に係るルビのローマ字描画のプロセス
【図１１】本発明の実施形態に係る「全ルビ」ではない楽曲のテロップ表示例
【図１２】本発明の実施形態に係る歌詞のローマ字変換のプロセス
【図１３】本発明の実施形態に係るルビを二段にする実施例の場合の変換前・変換後
【発明を実施するための形態】
【００１５】
図１は、本発明の実施形態に係るカラオケ装置の構成を示す図である。本実施形態のカ
ラオケ装置１（「コマンダ」ともいう）は、ＣＰＵ１４、ＲＡＭ１５、ＲＯＭ１６などで構成される制御部を中心として、ＨＤＤ（ハードディスク）１３、音声処理部１８、映像処理部１１、操作パネル１０、通信インタフェイス１７などを備えて構成されている。
【００１６】
制御手段を構成するＣＰＵ１４、ＲＡＭ１５、ＲＯＭ１６は、コンピューターにおいて一般的に使用される構成であって、ＣＰＵ１４は、プログラムの実行などに基づく各種制御を、ＲＡＭ１５、ＲＯＭ１６、ハードディスク１３などに記憶する各種プログラム、各種データに基づいて行う。
【００１７】
カラオケ装置１における音声処理部１８は、主として演奏情報に基づく演奏処理を実行する手段である。演奏情報はＭＩＤＩ規格に基づいて作成されたデータの他、コーラスなどを担当する音声データなどを含んで構成されている。音声処理部１８では、ユーザーが指定した楽曲に対応する演奏情報に基づいて演奏処理を実行することで、所望の楽曲の演奏を行う。また、オーディオ入力端子に接続されたマイクから入力された音声情報と、演奏情報に基づく演奏音をミキシングしてアンプに出力し、アンプに接続されているスピーカーから放音する。なお、マイクから入力される音声情報に対しては、エコーなどの効果を付加することも可能としている。
【００１８】
映像処理部１１は、歌詞表示処理、並びに、背景映像表示処理など、ディスプレイ１２を介してユーザーに視覚的情報を提供する処理を実行する。歌詞表示処理は、楽曲情報に含まれる歌詞情報に基づいて歌詞をディスプレイ１２に表示させる処理であって、演奏処理に同期して実行される。ディスプレイ１２に表示された歌詞は、演奏に同期して歌唱すべき箇所が色替え表示され、歌唱者に歌唱箇所を教示する。また、背景映像表示処理は、演奏される楽曲の対応した各種映像を表示することで、歌唱の雰囲気を盛り上げる処理である。そのため、記憶手段としてのハードディスク１３には、ＭＰＥＧ形式などによる圧縮が施された背景映像情報が記憶されており、映像処理部１１では、この背景映像情報をデコードすることでディスプレイ１２に映像を表示する。
【００１９】
通信インタフェイス１７は、ネットワーク接続端子を介してインターネットに接続され、図示しないホスト装置から、新しくリリースされた楽曲情報や、背景映像情報、プログラムなどを受信するとともに、ホスト装置に対して利用履歴などを送信する。近年では、ユーザーの利用履歴、登録楽曲などを含んだユーザー情報をホスト装置で管理し、当該ユーザーの利用時に受信することで、各個ユーザーに即したサービスを提供することも可能である。
【００２０】
カラオケ装置１に対して行われる楽曲指定（予約）など、ユーザーからの各種指示は、操作パネル１０から行うことも可能であるが、通常、店舗内のネットワークに接続されたリモコン装置（図示せず）から行われる。リモコン装置は、タッチパネルなどのインタフェイスを備えており、ユーザーに各種情報を表示提供するとともに、タッチ指示による入力受付を行うことが可能となっている。
【００２１】
記憶手段として機能するハードディスク１３には、楽曲を演奏するための楽曲情報の他、ディスプレイに背景を表示するための背景映像情報、そして、カラオケ装置において各種処理を実行するためのプログラムを記憶している。また、前述したホスト装置から各種データを受信することで、記憶しているデータの追加、更新が実行される。本実施形態で説明する歌詞表示処理についても、プログラムとして受信させることで既存のカラオケ装置１に機能追加することが可能である。
【００２２】
では、本発明の特徴となる歌詞表示処理について説明する。図２は、本発明の実施形態に係る楽曲情報のデータ構成を示す図である。本実施形態の楽曲情報は、既存のものを利
用することが可能である。すなわち、楽曲情報に対して何ら加工、改変を行うことなくローマ字表示させることが可能となっている。このように、カラオケ装置１にて実行されるプログラムにてローマ字表示を行うこととしているため、楽曲情報の加工、改変に必要な手間、コストを抑えることが可能となっている。さらには、ローマ字表示のためのデータ量増加を伴うこともなく記憶容量を増加させることもない。
【００２３】
図２に示されるように楽曲情報は、楽曲情報の各種属性を示すメタデータ、演奏のために使用される演奏情報、歌詞表示のために使用される歌詞情報を含んで構成されている。本実施形態では、メタデータとして曲名、作曲者名、曲番号、ジャンル、個別素材画像の有無などを含んで構成されている。曲名、作曲者名、曲番号、ジャンルは、楽曲を検索、指定するための情報として用いられる。個別素材画像は、背景映像として当該楽曲に特化したものを有しているか否かを示す情報であって、有りの場合には、アーティストのライブ映像など当該楽曲に特化した映像が使用可能である。
【００２４】
本実施形態の演奏情報は、ＭＩＤＩ規格に即して作成されたＭＩＤＩデータとされているが、この他、バックコーラスなどの音声情報を含ませることとも考えられる。ＭＩＤＩデータの場合には、演奏手段としてのＭＩＤＩ音源に演奏させることで楽音が奏でられる。
【００２５】
歌詞情報（テロップデータ）は、演奏情報による演奏に同期してディスプレイ１２に歌詞を表示させるためのデータである。本実施形態では、１つのタイミングで１度に表示させるブロックデータを単位として構成されている。演奏情報の演奏に同期して出力されるステップ値をに基づいて、このブロックデータを読み出し、表示制御することで、演奏に同期した歌詞表示が実行されることとなる。
【００２６】
各ブロックデータは、表示データ、属性データ、ルビブロックデータを含んで構成されている。表示データは、表示させるべき歌詞の文字列（歌詞文字情報）、及び、当該文字列の位置決めのための座標を含んで構成されている。なお、１画面内に表示させるブロックデータは、複数設けることが可能であって、歌唱終了した箇所のブロックデータの歌詞を消去し、新たなブロックデータの歌詞を表示させることで、スムースな歌唱を行うことが可能である。
【００２７】
属性データは、表示データに含まれる文字列、並びに、ルビブロックデータに含まれる文字列の表示、消去、色替えタイミングを決めるための情報を含んだデータ群である。これらタイミングを決めるため、本実施形態では、演奏情報の進行に同期して出力されるステップ値（ＭＩＤＩステップ値）に対応づけられている。表示ステップ、消去ステップは、表示データ、ルビブロックデータの文字列の表示タイミング、消去タイミングを示すステップ値である。また、変化ステップは、表示データ、ルビブロックデータの文字列を色替えを開始するためのステップ値であって、本実施形態では文字列の色替え速度を示す変化速度を含んで構成されている。なお、属性データには、同ブロックデータ内に含まれるルビブロックデータの数（ルビブロック数）も含まれている。
【００２８】
ルビブロックデータは、表示データの文字列（主として漢字）に対しルビ（読み仮名：平仮名、片仮名）を表示するためのデータである。各ルビブロックデータは、文字列（ルビ文字情報）とそれを位置決めするための相対座標を含んで構成されている。
【００２９】
以上が本実施形態の楽曲情報のデータ構成であるが、データ構成については、本発明の趣旨を変更しない限り適宜形態を採用することができる。では、本実施形態の歌詞情報（ブロックデータ）とその描画結果の例について図３を用いて説明する。図３（ａ）は、本実施形態のブロックデータを示した例である。なお、この例では、表示ステップなどタイ
ミングを示す各種データは省略して記載している。「明日へ向かって飛べ」という表示データ内の文字列（以下、「本体文字列」という）について、各漢字「明日」、「向」、「飛」について平仮名のルビを振った形態となっている。
【００３０】
本実施形態において、本体文字を位置づけるための座標は、画面左上から本体文字列左上まで座標（ドット数）で表されている。本実施形態では、表示する文字列に所定の大きさのフォントを利用しており、このように１つのポイントを指定するのみで本体文字の位置決めが行われている。なお、位置決めについては、このように１つのポイントのみならず、例えば本体文字列の左上と右下を指定し、それらによって決められる枠内に合わせて表示するなど適宜形態を採用することができる。このような場合、大きさを自在に可変できるスケーラブルフォントを用いることが好ましい。
【００３１】
ルビについては、各漢字「明日」、「向」、「飛」について「あす」、「む」、「と」の平仮名を振ることになるが、その位置づけは、表示データで使用した座標からの相対座標で指定することとしている。本実施形態では、表示データ内の座標から右方向を正とし、文字列の左端までのドット数で定義づけている。ルビについても本体文字列と同様、文字列に所定の大きさのフォントを利用したものとなっているため、画面内上下方向の位置については、利用するフォントの大きさに基づいて自動で決定することが可能となっている。
【００３２】
このようなブロックデータによる描画結果の例が図３（ｂ）に示されている。図３（ａ）には記載されていないが、属性データ内の変化ステップに基づいて、本体文字列の左から右に向かって色替えすることで、歌唱者は歌唱箇所を認識することが可能となる。また、ルビについても本体文字列の色替え位置に合わせて色替えすることで、歌唱がさらに容易になる。
【００３３】
では、本実施形態において楽曲情報を再生させる処理について詳細に説明する。図４は、発明の実施形態に係る楽曲情報再生処理を示すフロー図である。カラオケ装置を操作するユーザーは、図１の操作パネル１０、あるいは、ネットワークに接続されたリモコン装置などの指定手段を利用して歌唱したい楽曲を指定する。楽曲の指定は通常、予約という形態で行うことが可能となっており、予約された楽曲は、その識別子（例えば、曲番号）をＲＡＭ１５内の予約テーブルに記録し、予約テーブルから識別子を順次、読み出して楽曲情報の再生が実行される。
【００３４】
操作パネル１０などから指定された楽曲について、楽曲情報の再生が開始されると、まず、Ｓ１０１にてハードディスク１３に格納されている楽曲情報が読み出される。Ｓ１０２では、読み出された楽曲情報に基づいて再生が開始されることとなるが、ここでは、演奏処理Ｓ２００と、歌詞再生処理Ｓ３００とが並列実行される。演奏処理は、読み出された楽曲情報内に含まれる演奏情報を、音声処理部１８に演奏されることで実行される。この演奏処理は、カラオケ装置ではよく知られる処理であるため、ここでの説明は省略する。演奏処理では、演奏情報の進行を示すステップ値が順次出力されており（Ｓ１０３）、歌詞再生処理Ｓ３００では、このステップ値に基づいて歌詞の表示、消去、色替えが実行される。楽曲情報の再生は、こらら演奏処理Ｓ２００、歌詞再生処理Ｓ３００が終了するまで（Ｓ１０４）実行されることとなる。
【００３５】
では、この歌詞再生処理Ｓ３００の詳細について説明する。図５は、本発明の実施形態に係る歌詞再生処理を示すフロー図である。歌詞再生処理は、図５の右上に示されるように楽曲データ内の歌詞情報、歌詞文字を表示するためのフォントデータ、演奏処理に伴って出力されるステップ値に基づいて実行される。
【００３６】
歌詞情報に含まれる各ブロックデータに対して、Ｓ３０１〜Ｓ３１２のブロックデータ処理ループが順次実行される。Ｓ３０２では、演奏処理で出力されるステップ値と読み出されているブロックデータ中、属性データに含まれる各ステップ（表示ステップ、消去ステップ、変化ステップ）との比較が行われる。Ｓ３０３、Ｓ３０６、Ｓ３０９ではこの比較に基づいて後続の各処理に進むこととなる。
【００３７】
表示ステップであることが判定された場合（Ｓ３０３：Ｙｅｓ）には、まず、ローマ字機能操作チェック、すなわち、現在、ローマ字変換を行う設定となっているか否かのチェックが実行される（Ｓ３０４）。ローマ字変換を行う設定については、操作パネル１０あるいはリモコン装置などの各種入力手段からユーザーの操作によって設定される。この設定は、楽曲再生中においても切り替えることが可能である。判定の結果、ローマ字変換機能を使用している場合（Ｓ３０５：Ｙｅｓ）には、ローマ字変換ブロック描画処理Ｓ５００にて歌詞の描画が実行される。一方、機能を使用していない場合（Ｓ３０５：Ｎｏ）には、通常ブロック描画処理が実行される。これら描画処理については後で詳しく説明する。
【００３８】
ステップ値との比較の結果、変化ステップであると判定された場合（Ｓ３０６：Ｙｅｓ）には、当該ブロックの文字列（本体文字、ルビ）に対して色替えが実行される。この色換えは、ローマ字変換ブロック処理Ｓ５００あるいは通常ブロック描画処理Ｓ４００にて、画面に表示された文字列について、左端から順に色替えを行い、歌唱者に対して歌唱位置を告知する処理である。この処理は、ブロックデータの属性データに含まれる変化ステップのタイミングで開始される。Ｓ３０７では、属性データ内に含まれる変化速度に基づいて、１回の描画にて変更される色替えの変更幅（ドット数）が算出される。Ｓ３０８では、算出された変更幅にて順次、表示されている文字列の色替え描画が実行される。本実施形態では、本体文字列に対する色替え位置と同じ横方向の位置について、ルビの文字列の色替えを実行することとしており、歌唱位置の把握をより正確なものとしている。なお、本実施形態では、１つのブロックデータについて１つの変化速度としているが、ブロックデータ内で変化速度を変更することも可能であり、その場合、変化タイミングと変更後の変化速度が必要となる。
【００３９】
ステップ値との比較の結果、消去ステップであることが判定された場合（Ｓ３０９：Ｙｅｓ）には、当該ブロックの文字列（主部、ルビ）の消去が実行される（Ｓ３１０）。以上の処理を演奏情報の演奏が終了するまで（Ｓ３１１：Ｙｅｓ）実行することで、演奏処理に同期した歌詞表示が実行されることとなる。
【００４０】
では、歌詞の文字列を表示するための通常ブロック描画処理と、ローマ字変換ブロック描画処理について詳しく説明する。
【００４１】
図６は、本発明の実施形態に係る通常ブロック描画処理を示すフロー図である。通常ブロック描画処理が開始されると、まず、Ｓ４０１にてブロックデータ中、表示データの座標が読み出され、本体文字列を配置していくための基準位置が設定される。続いて、Ｓ４０２からＳ４０７の処理にて、本体文字列の各本体文字についての描画が実行される。Ｓ４０３では、表示データの文字が読み出され、Ｓ４０４にて読み出された文字に対応するフォントデータによって描画が実行される。
【００４２】
Ｓ４０５では、次に表示すべき文字の位置決めのため、Ｓ４０４にて描画した文字の描画Ｘサイズ（画面横方向のサイズ）が取得される。Ｓ４０６では、次に描画する文字の位置決めのため、描画位置をＸサイズ分だけ進行させる。このようにＳ４０３〜Ｓ４０６の処理を繰り返すことで、表示データ中の文字列（本体文字列）の描画が実行される。
【００４３】
Ｓ４０８〜Ｓ４１６は、Ｓ４０１〜Ｓ４０７にて表示された本体文字列に対して、ルビを振るための処理である。この一連の処理は、各ルビブロックデータを順に読み出すことで実行される。Ｓ４０９では、ルビブロックデータの表示データ中に記述される相対座標と、表示データ中の座標に基づいて、描画すべきルビの描画開始座標が設定される。表示データ中の座標に対して相対座標を加算することで実行される。本実施形態では、相対座標として画面横方向のみの座標が設定されているため、画面縦方向の座標は表示データ中の座標が使用されることとなる。
【００４４】
Ｓ４１０〜Ｓ４１５は、各ルビブロックデータ毎に実行される処理であり、本体文字列の描画（Ｓ４０２〜Ｓ４０７）に類似した処理となっている。Ｓ４１１では、処理中のルビブロックデータの文字が読み出され、Ｓ４１２では、当該文字に対応するフォントデータに基づいて描画が実行される。Ｓ４１３、Ｓ４１４では、次のルビ文字の描画のための位置決定が実行される。このように各ルビブロックデータについて、Ｓ４１０〜Ｓ４１５の処理を繰り返すことで、表示する本体文字列のルビ表示が実行される。
【００４５】
以上、通常ブロック描画処理について説明したが、次にローマ字変換描画処理について、図７、図８を用いて説明する。図７、図８は、本発明の実施形態に係るローマ字変換ブロック描画処理を示すフロー図であり、特に図７は、本体文字列を表示するための処理であり、図８はルビ文字を表示するための処理となっている。なお、図７の丸Ｂは、図８に記載される丸Ｂ’に継続することを示している。
【００４６】
図７に示されるＳ５０２〜Ｓ５１６は、本体文字列を描画するための処理となっている。これらを繰り返すことで、表示データ中の文字列が画面に描画される。特に、本実施形態では、平仮名、片仮名のような一定の読みを有する表音文字について、アルファベットを使用したローマ字に変換することで、外国人など日本語の判読が困難なユーザーに対して歌唱を容易にすることとしている。特にローマ字への変換は、楽曲再生処理中に実行されるため、予め楽曲情報（特に、歌詞情報）を新たに用意する、あるいは、楽曲情報に変更を加えることを必要とせず、手間やコストを削減しつつも機能追加を図ることが可能となる。また、楽曲再生中に変換を行うため、変換されたローマ字のための記憶容量も必要とせず、楽曲情報のデータ量増加を伴うこともない。
【００４７】
Ｓ５０３では、表示データ中、文字列の１文字が読み出され、Ｓ５０４にて対応するフォントデータに基づいて画面に描画が行われる。Ｓ５０７は描画した文字が表音文字、すなわち、平仮名もしくは片仮名であるかが判定される。本実施形態では、このように本体文字が表音文字に対しては以下の処理（Ｓ５０８〜Ｓ５１５）にて、当該本体文字をローマ字に変換してルビを振ることとしている。Ｓ５０５にて平仮名もしくは片仮名でないと判定された場合には、Ｓ５１４、Ｓ５１５に進み、次に描画するための文字の基準位置を決定するための処理を実行し、次の本体文字の処理、あるいは、ルビブロックの処理に進む。
【００４８】
Ｓ５０５にて平仮名もしくは片仮名であると判定された場合には、まず、ルビ描画のため基準位置を移動させる（Ｓ５０６）。本実施形態では、本体文字描画の基準位置から画面縦方向（Ｙ方向）に所定量移動した位置を、ルビ描画のための基準位置としている。Ｓ５０７では、現在処理している文字が拗音、ぐたいてきには「ちゃ」、「きゅ」などにおける「ゃ」、「ゅ」であるか否かが判定される。拗音の場合には、Ｓ５０８で処理済みとなるため、描画を行うことなく、基準位置を本体文字の描画のための位置に戻し（Ｓ５１３）て処理を抜ける。
【００４９】
一方、拗音でないと判定された場合は、Ｓ５０８にて次の文字が拗音であるか否かが判定される。次の文字が拗音でない場合（Ｓ５０８：Ｎｏ）には、通常の文字表記であるた
め、Ｓ５０９にて処理中の文字１字分に対してローマ字変換処理を実行する。このローマ字変換処理は、平仮名もしくは片仮名をローマ字に変換するという単純な処理であって、簡単な変換テーブルを用いて実行することが可能である。例えば、「あ」、「キ」の場合には「Ａ」、「Ｋｉ」と１文字または２文字のアルファベットに変換される。Ｓ５１０では、Ｓ５０６にて移動させた基準位置にて変換されたローマ字を描画する。
【００５０】
Ｓ５０８にて次の文字が拗音であると判定された場合、次の文字（拗音）も含めたローマ字変換処理が実行される（Ｓ５１１）。例えば、「ぎゃ」、「ピョ」の場合には、「Ｇｙａ」、「Ｐｙｏ」と３文字のアルファベットに変換される。なお、変換規則によっては「じゃ」を「Ｊａ」と表記するなど２文字のアルファベットに変換してもよい。Ｓ５１２では、ローマ字に変換されたルビを画面に描画する。
【００５１】
図９には、本発明の実施形態に係る「全ルビ」の楽曲の歌詞表示例が示されている。ここで「全ルビ」の楽曲とは、本体文字列に使用する漢字全てについてルビが設けられている楽曲のことをいう。図９（ａ）は、通常ブロック処理による歌詞表示であり、図９（ｂ）は、ローマ字変換ブロック描画処理の表示例である。ユーザーは、操作パネル１０などの入力手段を使用して、これらの表示形態を切り替えることができる。また、図９の変換例から分かるように、本体文字「へ」、「け」、「て」、「べ」に対して、ローマ字によるルビ「Ｈｅ」、「Ｋｅ」、「Ｔｅ」、「Ｂｅ」が付されている。
【００５２】
図８に記載されるフロー図は、図７のフロー図の続きであって、主としてルビブロックに対する処理が示されている。Ｓ５１７〜Ｓ５３２の処理では、各ルビブロックに対して行われる処理が示されている。この処理を各ルビブロックに対して実行することで、元々漢字などに付されていたルビのローマ字変換が実行されることとなる。
【００５３】
Ｓ５１８は、読み出されたルビブロック中、描画するための基準位置となる相対座標が読み出され、表示データ中の座標とに基づいてルビ文字を描画するための基準位置（描画開始座標）が設定される。
【００５４】
Ｓ５１９〜Ｓ５２９の処理は、各ルビ文字に対して行われる処理である。Ｓ５２０では、ルビブロックデータ中の文字列中の１文字が読み出される。Ｓ５２１では、当該文字に対応するフォントを描画するために必要な画面横方向のサイズ（Ｘサイズ）が取得される。Ｓ５２２では、このＸサイズを加算し、１つのルビブロックデータ中のルビ文字列を描画するに必要な画面横方向の大きさが算出される。
【００５５】
Ｓ５２３〜Ｓ５２８の処理は、本体文字列を処理した場合と同様、拗音の有無に基づいてローマ字変換、並びに、描画処理となっている。本実施形態では、Ｓ５２６、Ｓ５２８で画面に描画することなく、バッファ領域に描画することとしている。これは後の処理で、ローマ字変換されたルビ文字列の大きさを考慮して描画を行うためである。
【００５６】
ルビブロックデータ中のルビ文字列の描画（この場合、バッファ領域への描画）が完了すると、Ｓ５２９にて処理を抜け、Ｓ５３０にてバッファ領域に描画した文字列の拡大・縮小が実行される。この処理は、Ｓ５２２で算出された元々（ローマ字変換処理前）のルビ文字列の大きさ（画面横方向について）に拡大または縮小する処理である。
【００５７】
図１０は、このＳ５３０で実行されるローマ字変換後のルビの縮小プロセスの例を示した図である。ルビ文字列「あす」について、ローマ字変換が実行された場合を考えてみる。ローマ字変換後のルビ文字列は「Ａｓｕ」と３文字表記となるため、元々の２文字表記よりも画面横方向の大きさが大きくなってしまう。そのため、本実施形態では、画面横方向の大きさについて、変換前の文字表記の大きさにサイズ変換（縮小）することで、文字
数が多くなった場合においても、隣り合うルビブロックの文字との重複を防ぎ、ルビ文字を見易くすることが可能となる。また、文字の色替えに関しても、変換前の文字表記とほぼ同タイミングで実行されることとなり、ローマ字変換後においても歌唱し易さを確保することが可能となる。
【００５８】
Ｓ５３１では、Ｓ５３０について拡大縮小されたバッファ領域内のルビ文字列を画面に描画する。以上の処理を各ルビブロック全てについて実行し、一連の処理を終了する。以上、本実施形態における歌詞表示処理について説明したが、本実施形態では、楽曲情報の再生中に演奏処理と同時進行で実行される歌詞表示処理において、ルビのローマ字変換が行われることしており、ローマ字表示のための歌詞情報の追加、変更を必要としない。
【００５９】
前述の実施形態では「全ルビ」について説明したが、楽曲情報には一部の漢字のみにルビが設けられた楽曲も存在する。図１１は、そのような場合の「全ルビ」ではない楽曲に対して、本実施形態の歌詞表示処理を適用した場合の表示例である。本実施形態では、表音文字を有さない文字（この場合「明日」、「向」）については、ローマ字変換を実行することができないため、図１１（ｂ）に示されるような表示形態となってしまう。しかしながら、歌唱できない文字が、数文字あったとしても歌唱全体からみれば影響は少なく、、また、楽曲情報に手を加えることなく歌詞表示処理のためのプログラムのみで対応できるという効果からみても、このような「全ルビ」では内楽曲に対しても適用する意義は大きい。
【００６０】
図１２は、本発明の実施形態に係る歌詞のローマ字変換のプロセス、並びに、変形例をまとめた例である。図中１、２、５で示されるルビを有さない漢字については、ローマ字によるルビが付されないこととなる。一方、図中３、６、８、９、１２、１４については、一律にローマ字変換することが可能な平仮名もしくは片仮名であるため、各本体文字上部にローマ字変換されたルビが表記されることとなる。
【００６１】
ここで、図の８に示されるように、本体文字あるいはルビ文字が促音「っ」を含む場合には、１つ先の文字を参照してローマ字に変換することが好ましい。この場合「って」となっているため、１つ先の文字である「て」の子音部分「ｔ」が促音「っ」のルビとして変換されることとなる。この他「っさ」の場合には、促音の１つ先のもじである「さ」の子音部分「ｓ」がルビとして変換される。
【００６２】
このような変換規則の例としては、他に「タワー」などに用いられる長音符「ー」についても考慮することが好ましい。「タワー」の場合には、１文字前の文字「ワ」を参照することとなり、具体的には１文字前の文字の母音部分「ａ」が「ー」のルビとして変換されることとなる。
【００６３】
また、本実施形態では、本体文字が片仮名の場合、平仮名の場合と区別できるような表示形態（この場合、斜体文字）でルビを表示している。本体文字が片仮名の場合、英語を基準とした外来文字であることが多く、このような文字については平仮名の場合と異なる形態にて表示することで、外国人などのユーザーはさらに歌唱が容易となる。
【００６４】
図１３は、さらなる応用例を示した場合を示す例であって、図１３（ａ）は、ローマ字変換前の表記例が、図１３（ｂ）は、ローマ字変換後の表示例が示されている。「曙」のように読み仮名が多数文字にわたる場合、ローマ字に変換すると文字数はさらに増加することが考えられる。本実施形態では平仮名や片仮名についてもルビ表示を行うこととしているため、ルビが重複して表示されることが懸念される（この場合、「ＡＫｅＢｏＮｏ」に隣接する「Ｈｅ」）。そのため、本実施形態では、元々付されていたルビをローマ字変換したルビと、本体文字における平仮名、片仮名をローマ字変換したルビを異なる段に表
示させることとしている。
【００６５】
このように異なる段に表示させることで、変換されたローマ字が重複して表示されることを避け、判読の容易性を向上させることが可能となる。なお、本実施形態では、異なる段に表示させる際、本体文字の平仮名、片仮名部分を縦方向に圧縮し、ルビ表記に必要なスペースを形成しているが、この形態を必須とするものではない。
【００６６】
なお、本発明はこれらの実施形態のみに限られるものではなく、それぞれの実施形態の構成を適宜組み合わせて構成した実施形態も本発明の範疇となるものである。
【符号の説明】
【００６７】
１…カラオケ装置、１０…操作パネル、１１…映像処理部、１２…ディスプレイ（表示部）、１３…ＨＤＤ（ハードディスク）、１４…ＣＰＵ（制御部）、１５…ＲＡＭ、１６…ＲＯＭ、１７…通信インタフェース、１８…音声処理部
【技術分野】
【０００１】
本発明は、楽曲の演奏にあわせて歌唱を楽しむカラオケ装置に関するものであり、特に、演奏に同期して歌詞を表示することのできるカラオケ装置に関するものである。
【背景技術】
【０００２】
従来、カラオケ装置においては、歌唱補助を目的としてディスプレイなどの表示手段に、演奏に同期して歌詞や、日本語の歌詞であれば漢字の読み仮名（通称：ルビ）を表示することが行われている。このようなカラオケ装置では、ユーザは歌詞や漢字の読みを覚えておかなくても気軽に歌唱を楽しむことが可能となっている。
【０００３】
ところで、現在、カラオケは国内ユーザーのみならず、外国のユーザーにおいても好評を得ており、外国人ユーザーの中には、外国曲のみならず日本語の楽曲を歌唱したいというユーザーも増えつつある。
【０００４】
しかしながら、現在のカラオケ装置では日本語曲については、日本語の歌詞表示することが一般的であって、外国人ユーザーが気軽に歌唱を楽しむことは困難である。このような中、特許文献１には、日本語歌詞をローマ字表記することで歌詞の発音を容易にするカラオケ装置が開示されている。このカラオケ装置によれば、ローマ字を読み上げることで、日本語歌詞の発音が容易となる。しかしながら、特許文献１のカラオケ装置では、ローマ字表記を行うために別途データを作成する必要がある。そのため、同じ楽曲であっても、楽曲データをリニューアルすることや、ローマ字表記対応曲を追加する必要がある。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１０−６０６２８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
一方、カラオケ装置では、現状で日本語歌詞でホスト側で作成されて配信された曲数は数十万曲に上り、前述のようにホスト側で、既に配信されてしまった日本語歌詞の曲をローマ字表記対応曲に変更することや、新たに楽曲を作成して追加することは、非常に手間とコストがかかる作業であり、データ追加に伴う容量増加も懸念事項となる。
【０００７】
本発明は、カラオケ装置側で既存の楽曲データをそのまま使用して、ローマ字表記を行い、日本語の判読に不慣れな外国人ユーザーに対して、日本語曲の歌唱を楽しんでもらうことを目的としている。
【課題を解決するための手段】
【０００８】
そのため本発明は、演奏情報と歌詞情報を含む楽曲情報に基づいて再生を行うカラオケ装置において、
前記歌詞情報は、歌詞文字情報と、歌詞文字情報に対応づけられたルビ文字情報を含み、
指定手段で指定された楽曲に対応する前記楽曲情報を読み出して、再生処理を実行する制御部を備え、
前記再生処理は、演奏処理と歌詞表示処理を含み、
前記演奏処理は、読み出した前記楽曲情報に含まれる演奏情報を演奏手段に演奏させ、
前記歌詞表示処理は、読み出した前記楽曲情報に含まれる歌詞情報に基づいて、
前記歌詞文字情報に含まれる文字が漢字の場合、対応するルビ文字情報をローマ字に変換して表示手段に表示させ、
前記歌詞文字情報に含まれる文字が平仮名もしくは片仮名の場合、当該平仮名もしくは片仮名をローマ字に変換して表示手段に表示させることを特徴とする。
【０００９】
さらに本発明にかかるカラオケ装置は、
前記ルビ文字情報に基づいて変換されたローマ字は、変換元となったルビ文字情報のサイズ以内で表示することを特徴とする。
【００１０】
さらに本発明にかかるカラオケ装置において、
前記歌詞表示処理は、１文字先または１文字前の文字を参照してローマ字に変換することを特徴とする。
【００１１】
さらに本発明にかかるカラオケ装置において、
前記歌詞表示処理は、ローマ字への変換対象となる文字が、促音「っ」の場合は１文字先の文字を参照してローマ字に変換する、または、長音符「ー」の場合は１文字前の文字を参照してローマ字に変換することを特徴とする。
【００１２】
さらに本発明にかかるカラオケ装置は、
前記ルビ文字情報に基づいて変換されたローマ字と、平仮名または片仮名に基づいて変換されたローマ字とは、異なる段に表示させることを特徴とする。
【発明の効果】
【００１３】
本発明によれば、日本語曲をローマ字表記することで、日本語の判読に不慣れな外国人ユーザーなどに対して、日本語曲の歌唱を容易にさせることが可能となる。特に、既存の楽曲情報を用いて行うことで、楽曲情報の改変や追加などを必要とせず、機能追加に伴う手間とコストを削減することが可能となる。また、カラオケ装置において、楽曲が指定されてから後に、ローマ字への変換を行うこととなるため、楽曲情報のデータ量増加を伴うこともない。
【図面の簡単な説明】
【００１４】
【図１】本発明の実施形態に係るカラオケ装置の構成を示す図
【図２】本発明の実施形態に係る楽曲データのデータ構成を示す図
【図３】本発明の実施形態に係る歌詞データ（ブロックデータ）と描画結果の例を示す図
【図４】本発明の実施形態に係る楽曲データ再生処理を示すフロー図
【図５】本発明の実施形態に係る歌詞再生処理を示すフロー図
【図６】本発明の実施形態に係る通常ブロック描画処理を示すフロー図
【図７】本発明の実施形態に係るローマ字変換ブロック描画処理を示すフロー図（１）
【図８】本発明の実施形態に係るローマ字変換ブロック描画処理を示すフロー図（２）
【図９】本発明の実施形態に係る「全ルビ」の楽曲の歌詞表示例
【図１０】本発明の実施形態に係るルビのローマ字描画のプロセス
【図１１】本発明の実施形態に係る「全ルビ」ではない楽曲のテロップ表示例
【図１２】本発明の実施形態に係る歌詞のローマ字変換のプロセス
【図１３】本発明の実施形態に係るルビを二段にする実施例の場合の変換前・変換後
【発明を実施するための形態】
【００１５】
図１は、本発明の実施形態に係るカラオケ装置の構成を示す図である。本実施形態のカ
ラオケ装置１（「コマンダ」ともいう）は、ＣＰＵ１４、ＲＡＭ１５、ＲＯＭ１６などで構成される制御部を中心として、ＨＤＤ（ハードディスク）１３、音声処理部１８、映像処理部１１、操作パネル１０、通信インタフェイス１７などを備えて構成されている。
【００１６】
制御手段を構成するＣＰＵ１４、ＲＡＭ１５、ＲＯＭ１６は、コンピューターにおいて一般的に使用される構成であって、ＣＰＵ１４は、プログラムの実行などに基づく各種制御を、ＲＡＭ１５、ＲＯＭ１６、ハードディスク１３などに記憶する各種プログラム、各種データに基づいて行う。
【００１７】
カラオケ装置１における音声処理部１８は、主として演奏情報に基づく演奏処理を実行する手段である。演奏情報はＭＩＤＩ規格に基づいて作成されたデータの他、コーラスなどを担当する音声データなどを含んで構成されている。音声処理部１８では、ユーザーが指定した楽曲に対応する演奏情報に基づいて演奏処理を実行することで、所望の楽曲の演奏を行う。また、オーディオ入力端子に接続されたマイクから入力された音声情報と、演奏情報に基づく演奏音をミキシングしてアンプに出力し、アンプに接続されているスピーカーから放音する。なお、マイクから入力される音声情報に対しては、エコーなどの効果を付加することも可能としている。
【００１８】
映像処理部１１は、歌詞表示処理、並びに、背景映像表示処理など、ディスプレイ１２を介してユーザーに視覚的情報を提供する処理を実行する。歌詞表示処理は、楽曲情報に含まれる歌詞情報に基づいて歌詞をディスプレイ１２に表示させる処理であって、演奏処理に同期して実行される。ディスプレイ１２に表示された歌詞は、演奏に同期して歌唱すべき箇所が色替え表示され、歌唱者に歌唱箇所を教示する。また、背景映像表示処理は、演奏される楽曲の対応した各種映像を表示することで、歌唱の雰囲気を盛り上げる処理である。そのため、記憶手段としてのハードディスク１３には、ＭＰＥＧ形式などによる圧縮が施された背景映像情報が記憶されており、映像処理部１１では、この背景映像情報をデコードすることでディスプレイ１２に映像を表示する。
【００１９】
通信インタフェイス１７は、ネットワーク接続端子を介してインターネットに接続され、図示しないホスト装置から、新しくリリースされた楽曲情報や、背景映像情報、プログラムなどを受信するとともに、ホスト装置に対して利用履歴などを送信する。近年では、ユーザーの利用履歴、登録楽曲などを含んだユーザー情報をホスト装置で管理し、当該ユーザーの利用時に受信することで、各個ユーザーに即したサービスを提供することも可能である。
【００２０】
カラオケ装置１に対して行われる楽曲指定（予約）など、ユーザーからの各種指示は、操作パネル１０から行うことも可能であるが、通常、店舗内のネットワークに接続されたリモコン装置（図示せず）から行われる。リモコン装置は、タッチパネルなどのインタフェイスを備えており、ユーザーに各種情報を表示提供するとともに、タッチ指示による入力受付を行うことが可能となっている。
【００２１】
記憶手段として機能するハードディスク１３には、楽曲を演奏するための楽曲情報の他、ディスプレイに背景を表示するための背景映像情報、そして、カラオケ装置において各種処理を実行するためのプログラムを記憶している。また、前述したホスト装置から各種データを受信することで、記憶しているデータの追加、更新が実行される。本実施形態で説明する歌詞表示処理についても、プログラムとして受信させることで既存のカラオケ装置１に機能追加することが可能である。
【００２２】
では、本発明の特徴となる歌詞表示処理について説明する。図２は、本発明の実施形態に係る楽曲情報のデータ構成を示す図である。本実施形態の楽曲情報は、既存のものを利
用することが可能である。すなわち、楽曲情報に対して何ら加工、改変を行うことなくローマ字表示させることが可能となっている。このように、カラオケ装置１にて実行されるプログラムにてローマ字表示を行うこととしているため、楽曲情報の加工、改変に必要な手間、コストを抑えることが可能となっている。さらには、ローマ字表示のためのデータ量増加を伴うこともなく記憶容量を増加させることもない。
【００２３】
図２に示されるように楽曲情報は、楽曲情報の各種属性を示すメタデータ、演奏のために使用される演奏情報、歌詞表示のために使用される歌詞情報を含んで構成されている。本実施形態では、メタデータとして曲名、作曲者名、曲番号、ジャンル、個別素材画像の有無などを含んで構成されている。曲名、作曲者名、曲番号、ジャンルは、楽曲を検索、指定するための情報として用いられる。個別素材画像は、背景映像として当該楽曲に特化したものを有しているか否かを示す情報であって、有りの場合には、アーティストのライブ映像など当該楽曲に特化した映像が使用可能である。
【００２４】
本実施形態の演奏情報は、ＭＩＤＩ規格に即して作成されたＭＩＤＩデータとされているが、この他、バックコーラスなどの音声情報を含ませることとも考えられる。ＭＩＤＩデータの場合には、演奏手段としてのＭＩＤＩ音源に演奏させることで楽音が奏でられる。
【００２５】
歌詞情報（テロップデータ）は、演奏情報による演奏に同期してディスプレイ１２に歌詞を表示させるためのデータである。本実施形態では、１つのタイミングで１度に表示させるブロックデータを単位として構成されている。演奏情報の演奏に同期して出力されるステップ値をに基づいて、このブロックデータを読み出し、表示制御することで、演奏に同期した歌詞表示が実行されることとなる。
【００２６】
各ブロックデータは、表示データ、属性データ、ルビブロックデータを含んで構成されている。表示データは、表示させるべき歌詞の文字列（歌詞文字情報）、及び、当該文字列の位置決めのための座標を含んで構成されている。なお、１画面内に表示させるブロックデータは、複数設けることが可能であって、歌唱終了した箇所のブロックデータの歌詞を消去し、新たなブロックデータの歌詞を表示させることで、スムースな歌唱を行うことが可能である。
【００２７】
属性データは、表示データに含まれる文字列、並びに、ルビブロックデータに含まれる文字列の表示、消去、色替えタイミングを決めるための情報を含んだデータ群である。これらタイミングを決めるため、本実施形態では、演奏情報の進行に同期して出力されるステップ値（ＭＩＤＩステップ値）に対応づけられている。表示ステップ、消去ステップは、表示データ、ルビブロックデータの文字列の表示タイミング、消去タイミングを示すステップ値である。また、変化ステップは、表示データ、ルビブロックデータの文字列を色替えを開始するためのステップ値であって、本実施形態では文字列の色替え速度を示す変化速度を含んで構成されている。なお、属性データには、同ブロックデータ内に含まれるルビブロックデータの数（ルビブロック数）も含まれている。
【００２８】
ルビブロックデータは、表示データの文字列（主として漢字）に対しルビ（読み仮名：平仮名、片仮名）を表示するためのデータである。各ルビブロックデータは、文字列（ルビ文字情報）とそれを位置決めするための相対座標を含んで構成されている。
【００２９】
以上が本実施形態の楽曲情報のデータ構成であるが、データ構成については、本発明の趣旨を変更しない限り適宜形態を採用することができる。では、本実施形態の歌詞情報（ブロックデータ）とその描画結果の例について図３を用いて説明する。図３（ａ）は、本実施形態のブロックデータを示した例である。なお、この例では、表示ステップなどタイ
ミングを示す各種データは省略して記載している。「明日へ向かって飛べ」という表示データ内の文字列（以下、「本体文字列」という）について、各漢字「明日」、「向」、「飛」について平仮名のルビを振った形態となっている。
【００３０】
本実施形態において、本体文字を位置づけるための座標は、画面左上から本体文字列左上まで座標（ドット数）で表されている。本実施形態では、表示する文字列に所定の大きさのフォントを利用しており、このように１つのポイントを指定するのみで本体文字の位置決めが行われている。なお、位置決めについては、このように１つのポイントのみならず、例えば本体文字列の左上と右下を指定し、それらによって決められる枠内に合わせて表示するなど適宜形態を採用することができる。このような場合、大きさを自在に可変できるスケーラブルフォントを用いることが好ましい。
【００３１】
ルビについては、各漢字「明日」、「向」、「飛」について「あす」、「む」、「と」の平仮名を振ることになるが、その位置づけは、表示データで使用した座標からの相対座標で指定することとしている。本実施形態では、表示データ内の座標から右方向を正とし、文字列の左端までのドット数で定義づけている。ルビについても本体文字列と同様、文字列に所定の大きさのフォントを利用したものとなっているため、画面内上下方向の位置については、利用するフォントの大きさに基づいて自動で決定することが可能となっている。
【００３２】
このようなブロックデータによる描画結果の例が図３（ｂ）に示されている。図３（ａ）には記載されていないが、属性データ内の変化ステップに基づいて、本体文字列の左から右に向かって色替えすることで、歌唱者は歌唱箇所を認識することが可能となる。また、ルビについても本体文字列の色替え位置に合わせて色替えすることで、歌唱がさらに容易になる。
【００３３】
では、本実施形態において楽曲情報を再生させる処理について詳細に説明する。図４は、発明の実施形態に係る楽曲情報再生処理を示すフロー図である。カラオケ装置を操作するユーザーは、図１の操作パネル１０、あるいは、ネットワークに接続されたリモコン装置などの指定手段を利用して歌唱したい楽曲を指定する。楽曲の指定は通常、予約という形態で行うことが可能となっており、予約された楽曲は、その識別子（例えば、曲番号）をＲＡＭ１５内の予約テーブルに記録し、予約テーブルから識別子を順次、読み出して楽曲情報の再生が実行される。
【００３４】
操作パネル１０などから指定された楽曲について、楽曲情報の再生が開始されると、まず、Ｓ１０１にてハードディスク１３に格納されている楽曲情報が読み出される。Ｓ１０２では、読み出された楽曲情報に基づいて再生が開始されることとなるが、ここでは、演奏処理Ｓ２００と、歌詞再生処理Ｓ３００とが並列実行される。演奏処理は、読み出された楽曲情報内に含まれる演奏情報を、音声処理部１８に演奏されることで実行される。この演奏処理は、カラオケ装置ではよく知られる処理であるため、ここでの説明は省略する。演奏処理では、演奏情報の進行を示すステップ値が順次出力されており（Ｓ１０３）、歌詞再生処理Ｓ３００では、このステップ値に基づいて歌詞の表示、消去、色替えが実行される。楽曲情報の再生は、こらら演奏処理Ｓ２００、歌詞再生処理Ｓ３００が終了するまで（Ｓ１０４）実行されることとなる。
【００３５】
では、この歌詞再生処理Ｓ３００の詳細について説明する。図５は、本発明の実施形態に係る歌詞再生処理を示すフロー図である。歌詞再生処理は、図５の右上に示されるように楽曲データ内の歌詞情報、歌詞文字を表示するためのフォントデータ、演奏処理に伴って出力されるステップ値に基づいて実行される。
【００３６】
歌詞情報に含まれる各ブロックデータに対して、Ｓ３０１〜Ｓ３１２のブロックデータ処理ループが順次実行される。Ｓ３０２では、演奏処理で出力されるステップ値と読み出されているブロックデータ中、属性データに含まれる各ステップ（表示ステップ、消去ステップ、変化ステップ）との比較が行われる。Ｓ３０３、Ｓ３０６、Ｓ３０９ではこの比較に基づいて後続の各処理に進むこととなる。
【００３７】
表示ステップであることが判定された場合（Ｓ３０３：Ｙｅｓ）には、まず、ローマ字機能操作チェック、すなわち、現在、ローマ字変換を行う設定となっているか否かのチェックが実行される（Ｓ３０４）。ローマ字変換を行う設定については、操作パネル１０あるいはリモコン装置などの各種入力手段からユーザーの操作によって設定される。この設定は、楽曲再生中においても切り替えることが可能である。判定の結果、ローマ字変換機能を使用している場合（Ｓ３０５：Ｙｅｓ）には、ローマ字変換ブロック描画処理Ｓ５００にて歌詞の描画が実行される。一方、機能を使用していない場合（Ｓ３０５：Ｎｏ）には、通常ブロック描画処理が実行される。これら描画処理については後で詳しく説明する。
【００３８】
ステップ値との比較の結果、変化ステップであると判定された場合（Ｓ３０６：Ｙｅｓ）には、当該ブロックの文字列（本体文字、ルビ）に対して色替えが実行される。この色換えは、ローマ字変換ブロック処理Ｓ５００あるいは通常ブロック描画処理Ｓ４００にて、画面に表示された文字列について、左端から順に色替えを行い、歌唱者に対して歌唱位置を告知する処理である。この処理は、ブロックデータの属性データに含まれる変化ステップのタイミングで開始される。Ｓ３０７では、属性データ内に含まれる変化速度に基づいて、１回の描画にて変更される色替えの変更幅（ドット数）が算出される。Ｓ３０８では、算出された変更幅にて順次、表示されている文字列の色替え描画が実行される。本実施形態では、本体文字列に対する色替え位置と同じ横方向の位置について、ルビの文字列の色替えを実行することとしており、歌唱位置の把握をより正確なものとしている。なお、本実施形態では、１つのブロックデータについて１つの変化速度としているが、ブロックデータ内で変化速度を変更することも可能であり、その場合、変化タイミングと変更後の変化速度が必要となる。
【００３９】
ステップ値との比較の結果、消去ステップであることが判定された場合（Ｓ３０９：Ｙｅｓ）には、当該ブロックの文字列（主部、ルビ）の消去が実行される（Ｓ３１０）。以上の処理を演奏情報の演奏が終了するまで（Ｓ３１１：Ｙｅｓ）実行することで、演奏処理に同期した歌詞表示が実行されることとなる。
【００４０】
では、歌詞の文字列を表示するための通常ブロック描画処理と、ローマ字変換ブロック描画処理について詳しく説明する。
【００４１】
図６は、本発明の実施形態に係る通常ブロック描画処理を示すフロー図である。通常ブロック描画処理が開始されると、まず、Ｓ４０１にてブロックデータ中、表示データの座標が読み出され、本体文字列を配置していくための基準位置が設定される。続いて、Ｓ４０２からＳ４０７の処理にて、本体文字列の各本体文字についての描画が実行される。Ｓ４０３では、表示データの文字が読み出され、Ｓ４０４にて読み出された文字に対応するフォントデータによって描画が実行される。
【００４２】
Ｓ４０５では、次に表示すべき文字の位置決めのため、Ｓ４０４にて描画した文字の描画Ｘサイズ（画面横方向のサイズ）が取得される。Ｓ４０６では、次に描画する文字の位置決めのため、描画位置をＸサイズ分だけ進行させる。このようにＳ４０３〜Ｓ４０６の処理を繰り返すことで、表示データ中の文字列（本体文字列）の描画が実行される。
【００４３】
Ｓ４０８〜Ｓ４１６は、Ｓ４０１〜Ｓ４０７にて表示された本体文字列に対して、ルビを振るための処理である。この一連の処理は、各ルビブロックデータを順に読み出すことで実行される。Ｓ４０９では、ルビブロックデータの表示データ中に記述される相対座標と、表示データ中の座標に基づいて、描画すべきルビの描画開始座標が設定される。表示データ中の座標に対して相対座標を加算することで実行される。本実施形態では、相対座標として画面横方向のみの座標が設定されているため、画面縦方向の座標は表示データ中の座標が使用されることとなる。
【００４４】
Ｓ４１０〜Ｓ４１５は、各ルビブロックデータ毎に実行される処理であり、本体文字列の描画（Ｓ４０２〜Ｓ４０７）に類似した処理となっている。Ｓ４１１では、処理中のルビブロックデータの文字が読み出され、Ｓ４１２では、当該文字に対応するフォントデータに基づいて描画が実行される。Ｓ４１３、Ｓ４１４では、次のルビ文字の描画のための位置決定が実行される。このように各ルビブロックデータについて、Ｓ４１０〜Ｓ４１５の処理を繰り返すことで、表示する本体文字列のルビ表示が実行される。
【００４５】
以上、通常ブロック描画処理について説明したが、次にローマ字変換描画処理について、図７、図８を用いて説明する。図７、図８は、本発明の実施形態に係るローマ字変換ブロック描画処理を示すフロー図であり、特に図７は、本体文字列を表示するための処理であり、図８はルビ文字を表示するための処理となっている。なお、図７の丸Ｂは、図８に記載される丸Ｂ’に継続することを示している。
【００４６】
図７に示されるＳ５０２〜Ｓ５１６は、本体文字列を描画するための処理となっている。これらを繰り返すことで、表示データ中の文字列が画面に描画される。特に、本実施形態では、平仮名、片仮名のような一定の読みを有する表音文字について、アルファベットを使用したローマ字に変換することで、外国人など日本語の判読が困難なユーザーに対して歌唱を容易にすることとしている。特にローマ字への変換は、楽曲再生処理中に実行されるため、予め楽曲情報（特に、歌詞情報）を新たに用意する、あるいは、楽曲情報に変更を加えることを必要とせず、手間やコストを削減しつつも機能追加を図ることが可能となる。また、楽曲再生中に変換を行うため、変換されたローマ字のための記憶容量も必要とせず、楽曲情報のデータ量増加を伴うこともない。
【００４７】
Ｓ５０３では、表示データ中、文字列の１文字が読み出され、Ｓ５０４にて対応するフォントデータに基づいて画面に描画が行われる。Ｓ５０７は描画した文字が表音文字、すなわち、平仮名もしくは片仮名であるかが判定される。本実施形態では、このように本体文字が表音文字に対しては以下の処理（Ｓ５０８〜Ｓ５１５）にて、当該本体文字をローマ字に変換してルビを振ることとしている。Ｓ５０５にて平仮名もしくは片仮名でないと判定された場合には、Ｓ５１４、Ｓ５１５に進み、次に描画するための文字の基準位置を決定するための処理を実行し、次の本体文字の処理、あるいは、ルビブロックの処理に進む。
【００４８】
Ｓ５０５にて平仮名もしくは片仮名であると判定された場合には、まず、ルビ描画のため基準位置を移動させる（Ｓ５０６）。本実施形態では、本体文字描画の基準位置から画面縦方向（Ｙ方向）に所定量移動した位置を、ルビ描画のための基準位置としている。Ｓ５０７では、現在処理している文字が拗音、ぐたいてきには「ちゃ」、「きゅ」などにおける「ゃ」、「ゅ」であるか否かが判定される。拗音の場合には、Ｓ５０８で処理済みとなるため、描画を行うことなく、基準位置を本体文字の描画のための位置に戻し（Ｓ５１３）て処理を抜ける。
【００４９】
一方、拗音でないと判定された場合は、Ｓ５０８にて次の文字が拗音であるか否かが判定される。次の文字が拗音でない場合（Ｓ５０８：Ｎｏ）には、通常の文字表記であるた
め、Ｓ５０９にて処理中の文字１字分に対してローマ字変換処理を実行する。このローマ字変換処理は、平仮名もしくは片仮名をローマ字に変換するという単純な処理であって、簡単な変換テーブルを用いて実行することが可能である。例えば、「あ」、「キ」の場合には「Ａ」、「Ｋｉ」と１文字または２文字のアルファベットに変換される。Ｓ５１０では、Ｓ５０６にて移動させた基準位置にて変換されたローマ字を描画する。
【００５０】
Ｓ５０８にて次の文字が拗音であると判定された場合、次の文字（拗音）も含めたローマ字変換処理が実行される（Ｓ５１１）。例えば、「ぎゃ」、「ピョ」の場合には、「Ｇｙａ」、「Ｐｙｏ」と３文字のアルファベットに変換される。なお、変換規則によっては「じゃ」を「Ｊａ」と表記するなど２文字のアルファベットに変換してもよい。Ｓ５１２では、ローマ字に変換されたルビを画面に描画する。
【００５１】
図９には、本発明の実施形態に係る「全ルビ」の楽曲の歌詞表示例が示されている。ここで「全ルビ」の楽曲とは、本体文字列に使用する漢字全てについてルビが設けられている楽曲のことをいう。図９（ａ）は、通常ブロック処理による歌詞表示であり、図９（ｂ）は、ローマ字変換ブロック描画処理の表示例である。ユーザーは、操作パネル１０などの入力手段を使用して、これらの表示形態を切り替えることができる。また、図９の変換例から分かるように、本体文字「へ」、「け」、「て」、「べ」に対して、ローマ字によるルビ「Ｈｅ」、「Ｋｅ」、「Ｔｅ」、「Ｂｅ」が付されている。
【００５２】
図８に記載されるフロー図は、図７のフロー図の続きであって、主としてルビブロックに対する処理が示されている。Ｓ５１７〜Ｓ５３２の処理では、各ルビブロックに対して行われる処理が示されている。この処理を各ルビブロックに対して実行することで、元々漢字などに付されていたルビのローマ字変換が実行されることとなる。
【００５３】
Ｓ５１８は、読み出されたルビブロック中、描画するための基準位置となる相対座標が読み出され、表示データ中の座標とに基づいてルビ文字を描画するための基準位置（描画開始座標）が設定される。
【００５４】
Ｓ５１９〜Ｓ５２９の処理は、各ルビ文字に対して行われる処理である。Ｓ５２０では、ルビブロックデータ中の文字列中の１文字が読み出される。Ｓ５２１では、当該文字に対応するフォントを描画するために必要な画面横方向のサイズ（Ｘサイズ）が取得される。Ｓ５２２では、このＸサイズを加算し、１つのルビブロックデータ中のルビ文字列を描画するに必要な画面横方向の大きさが算出される。
【００５５】
Ｓ５２３〜Ｓ５２８の処理は、本体文字列を処理した場合と同様、拗音の有無に基づいてローマ字変換、並びに、描画処理となっている。本実施形態では、Ｓ５２６、Ｓ５２８で画面に描画することなく、バッファ領域に描画することとしている。これは後の処理で、ローマ字変換されたルビ文字列の大きさを考慮して描画を行うためである。
【００５６】
ルビブロックデータ中のルビ文字列の描画（この場合、バッファ領域への描画）が完了すると、Ｓ５２９にて処理を抜け、Ｓ５３０にてバッファ領域に描画した文字列の拡大・縮小が実行される。この処理は、Ｓ５２２で算出された元々（ローマ字変換処理前）のルビ文字列の大きさ（画面横方向について）に拡大または縮小する処理である。
【００５７】
図１０は、このＳ５３０で実行されるローマ字変換後のルビの縮小プロセスの例を示した図である。ルビ文字列「あす」について、ローマ字変換が実行された場合を考えてみる。ローマ字変換後のルビ文字列は「Ａｓｕ」と３文字表記となるため、元々の２文字表記よりも画面横方向の大きさが大きくなってしまう。そのため、本実施形態では、画面横方向の大きさについて、変換前の文字表記の大きさにサイズ変換（縮小）することで、文字
数が多くなった場合においても、隣り合うルビブロックの文字との重複を防ぎ、ルビ文字を見易くすることが可能となる。また、文字の色替えに関しても、変換前の文字表記とほぼ同タイミングで実行されることとなり、ローマ字変換後においても歌唱し易さを確保することが可能となる。
【００５８】
Ｓ５３１では、Ｓ５３０について拡大縮小されたバッファ領域内のルビ文字列を画面に描画する。以上の処理を各ルビブロック全てについて実行し、一連の処理を終了する。以上、本実施形態における歌詞表示処理について説明したが、本実施形態では、楽曲情報の再生中に演奏処理と同時進行で実行される歌詞表示処理において、ルビのローマ字変換が行われることしており、ローマ字表示のための歌詞情報の追加、変更を必要としない。
【００５９】
前述の実施形態では「全ルビ」について説明したが、楽曲情報には一部の漢字のみにルビが設けられた楽曲も存在する。図１１は、そのような場合の「全ルビ」ではない楽曲に対して、本実施形態の歌詞表示処理を適用した場合の表示例である。本実施形態では、表音文字を有さない文字（この場合「明日」、「向」）については、ローマ字変換を実行することができないため、図１１（ｂ）に示されるような表示形態となってしまう。しかしながら、歌唱できない文字が、数文字あったとしても歌唱全体からみれば影響は少なく、、また、楽曲情報に手を加えることなく歌詞表示処理のためのプログラムのみで対応できるという効果からみても、このような「全ルビ」では内楽曲に対しても適用する意義は大きい。
【００６０】
図１２は、本発明の実施形態に係る歌詞のローマ字変換のプロセス、並びに、変形例をまとめた例である。図中１、２、５で示されるルビを有さない漢字については、ローマ字によるルビが付されないこととなる。一方、図中３、６、８、９、１２、１４については、一律にローマ字変換することが可能な平仮名もしくは片仮名であるため、各本体文字上部にローマ字変換されたルビが表記されることとなる。
【００６１】
ここで、図の８に示されるように、本体文字あるいはルビ文字が促音「っ」を含む場合には、１つ先の文字を参照してローマ字に変換することが好ましい。この場合「って」となっているため、１つ先の文字である「て」の子音部分「ｔ」が促音「っ」のルビとして変換されることとなる。この他「っさ」の場合には、促音の１つ先のもじである「さ」の子音部分「ｓ」がルビとして変換される。
【００６２】
このような変換規則の例としては、他に「タワー」などに用いられる長音符「ー」についても考慮することが好ましい。「タワー」の場合には、１文字前の文字「ワ」を参照することとなり、具体的には１文字前の文字の母音部分「ａ」が「ー」のルビとして変換されることとなる。
【００６３】
また、本実施形態では、本体文字が片仮名の場合、平仮名の場合と区別できるような表示形態（この場合、斜体文字）でルビを表示している。本体文字が片仮名の場合、英語を基準とした外来文字であることが多く、このような文字については平仮名の場合と異なる形態にて表示することで、外国人などのユーザーはさらに歌唱が容易となる。
【００６４】
図１３は、さらなる応用例を示した場合を示す例であって、図１３（ａ）は、ローマ字変換前の表記例が、図１３（ｂ）は、ローマ字変換後の表示例が示されている。「曙」のように読み仮名が多数文字にわたる場合、ローマ字に変換すると文字数はさらに増加することが考えられる。本実施形態では平仮名や片仮名についてもルビ表示を行うこととしているため、ルビが重複して表示されることが懸念される（この場合、「ＡＫｅＢｏＮｏ」に隣接する「Ｈｅ」）。そのため、本実施形態では、元々付されていたルビをローマ字変換したルビと、本体文字における平仮名、片仮名をローマ字変換したルビを異なる段に表
示させることとしている。
【００６５】
このように異なる段に表示させることで、変換されたローマ字が重複して表示されることを避け、判読の容易性を向上させることが可能となる。なお、本実施形態では、異なる段に表示させる際、本体文字の平仮名、片仮名部分を縦方向に圧縮し、ルビ表記に必要なスペースを形成しているが、この形態を必須とするものではない。
【００６６】
なお、本発明はこれらの実施形態のみに限られるものではなく、それぞれの実施形態の構成を適宜組み合わせて構成した実施形態も本発明の範疇となるものである。
【符号の説明】
【００６７】
１…カラオケ装置、１０…操作パネル、１１…映像処理部、１２…ディスプレイ（表示部）、１３…ＨＤＤ（ハードディスク）、１４…ＣＰＵ（制御部）、１５…ＲＡＭ、１６…ＲＯＭ、１７…通信インタフェース、１８…音声処理部
【特許請求の範囲】
【請求項１】
演奏情報と歌詞情報を含む楽曲情報に基づいて再生を行うカラオケ装置において、
前記歌詞情報は、歌詞文字情報と、歌詞文字情報に対応づけられたルビ文字情報を含み、
指定手段で指定された楽曲に対応する前記楽曲情報を読み出して、再生処理を実行する制御部を備え、
前記再生処理は、演奏処理と歌詞表示処理を含み、
前記演奏処理は、読み出した前記楽曲情報に含まれる演奏情報を演奏手段に演奏させ、
前記歌詞表示処理は、読み出した前記楽曲情報に含まれる歌詞情報に基づいて、
前記歌詞文字情報に含まれる文字が漢字の場合、対応するルビ文字情報をローマ字に変換して表示手段に表示させ、
前記歌詞文字情報に含まれる文字が平仮名もしくは片仮名の場合、当該平仮名もしくは片仮名をローマ字に変換して表示手段に表示させることを特徴とする
カラオケ装置。
【請求項２】
前記ルビ文字情報に基づいて変換されたローマ字は、変換元となったルビ文字情報のサイズ以内で表示することを特徴とする
請求項１に記載のカラオケ装置。
【請求項３】
前記歌詞表示処理は、１文字先または１文字前の文字を参照してローマ字に変換することを特徴とする
請求項１または請求項２に記載のカラオケ装置。
【請求項４】
前記歌詞表示処理は、ローマ字への変換対象となる文字が、促音「っ」の場合は１文字先の文字を参照してローマ字に変換する、または、長音符「ー」の場合は１文字前の文字を参照してローマ字に変換することを特徴とする
請求項３に記載のカラオケ装置。
【請求項５】
前記ルビ文字情報に基づいて変換されたローマ字と、平仮名または片仮名に基づいて変換されたローマ字とは、異なる段に表示させることを特徴とする
請求項１から請求項４の何れか１項に記載のカラオケ装置。
【請求項１】
演奏情報と歌詞情報を含む楽曲情報に基づいて再生を行うカラオケ装置において、
前記歌詞情報は、歌詞文字情報と、歌詞文字情報に対応づけられたルビ文字情報を含み、
指定手段で指定された楽曲に対応する前記楽曲情報を読み出して、再生処理を実行する制御部を備え、
前記再生処理は、演奏処理と歌詞表示処理を含み、
前記演奏処理は、読み出した前記楽曲情報に含まれる演奏情報を演奏手段に演奏させ、
前記歌詞表示処理は、読み出した前記楽曲情報に含まれる歌詞情報に基づいて、
前記歌詞文字情報に含まれる文字が漢字の場合、対応するルビ文字情報をローマ字に変換して表示手段に表示させ、
前記歌詞文字情報に含まれる文字が平仮名もしくは片仮名の場合、当該平仮名もしくは片仮名をローマ字に変換して表示手段に表示させることを特徴とする
カラオケ装置。
【請求項２】
前記ルビ文字情報に基づいて変換されたローマ字は、変換元となったルビ文字情報のサイズ以内で表示することを特徴とする
請求項１に記載のカラオケ装置。
【請求項３】
前記歌詞表示処理は、１文字先または１文字前の文字を参照してローマ字に変換することを特徴とする
請求項１または請求項２に記載のカラオケ装置。
【請求項４】
前記歌詞表示処理は、ローマ字への変換対象となる文字が、促音「っ」の場合は１文字先の文字を参照してローマ字に変換する、または、長音符「ー」の場合は１文字前の文字を参照してローマ字に変換することを特徴とする
請求項３に記載のカラオケ装置。
【請求項５】
前記ルビ文字情報に基づいて変換されたローマ字と、平仮名または片仮名に基づいて変換されたローマ字とは、異なる段に表示させることを特徴とする
請求項１から請求項４の何れか１項に記載のカラオケ装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公開番号】特開２０１３−１１８２９（Ｐ２０１３−１１８２９Ａ）
【公開日】平成２５年１月１７日（２０１３．１．１７）
【国際特許分類】
【出願番号】特願２０１１−１４６０４５（Ｐ２０１１−１４６０４５）
【出願日】平成２３年６月３０日（２０１１．６．３０）
【出願人】（０００００５２６７）ブラザー工業株式会社 (13,856)
【Ｆターム（参考）】
【公開日】平成２５年１月１７日（２０１３．１．１７）
【国際特許分類】
【出願日】平成２３年６月３０日（２０１１．６．３０）
【出願人】（０００００５２６７）ブラザー工業株式会社 (13,856)
【Ｆターム（参考）】
[ Back to top ]