演奏情報と歌詞情報を含む楽曲情報に基づいて再生を行うカラオケ装置において、前記歌詞情報は、歌詞文字情報と、歌詞文字情報に対応づけられたルビ文字情報を含み、指定手段で指定された楽曲に対応する前記楽曲情報を読み出して、再生処理を実行する制御部を備え、前記再生処理は、演奏処理と歌詞表示処理を含み、前記演奏処理は、読み出した前記楽曲情報に含まれる演奏情報を演奏手段に演奏させ、前記歌詞表示処理は、読み出した前記楽曲情報に含まれる歌詞情報に基づいて、前記歌詞文字情報に含まれる文字が漢字の場合、対応するルビ文字情報をローマ字に変換して表示手段に表示させ、前記歌詞文字情報に含まれる文字が平仮名もしくは片仮名の場合、当該平仮名もしくは片仮名をローマ字に変換して表示手段に表示させることを特徴とするカラオケ装置。前記ルビ文字情報に基づいて変換されたローマ字は、変換元となったルビ文字情報のサイズ以内で表示することを特徴とする請求項1に記載のカラオケ装置。前記歌詞表示処理は、1文字先または1文字前の文字を参照してローマ字に変換することを特徴とする請求項1または請求項2に記載のカラオケ装置。前記歌詞表示処理は、ローマ字への変換対象となる文字が、促音っの場合は1文字先の文字を参照してローマ字に変換する、または、長音符ーの場合は1文字前の文字を参照してローマ字に変換することを特徴とする請求項3に記載のカラオケ装置。前記ルビ文字情報に基づいて変換されたローマ字と、平仮名または片仮名に基づいて変換されたローマ字とは、異なる段に表示させることを特徴とする請求項1から請求項4の何れか1項に記載のカラオケ装置。一方、カラオケ装置では、現状で日本語歌詞でホスト側で作成されて配信された曲数は数十万曲に上り、前述のようにホスト側で、既に配信されてしまった日本語歌詞の曲をローマ字表記対応曲に変更することや、新たに楽曲を作成して追加することは、非常に手間とコストがかかる作業であり、データ追加に伴う容量増加も懸念事項となる。本発明は、カラオケ装置側で既存の楽曲データをそのまま使用して、ローマ字表記を行い、日本語の判読に不慣れな外国人ユーザーに対して、日本語曲の歌唱を楽しんでもらうことを目的としている。そのため本発明は、演奏情報と歌詞情報を含む楽曲情報に基づいて再生を行うカラオケ装置において、前記歌詞情報は、歌詞文字情報と、歌詞文字情報に対応づけられたルビ文字情報を含み、指定手段で指定された楽曲に対応する前記楽曲情報を読み出して、再生処理を実行する制御部を備え、前記再生処理は、演奏処理と歌詞表示処理を含み、前記演奏処理は、読み出した前記楽曲情報に含まれる演奏情報を演奏手段に演奏させ、前記歌詞表示処理は、読み出した前記楽曲情報に含まれる歌詞情報に基づいて、前記歌詞文字情報に含まれる文字が漢字の場合、対応するルビ文字情報をローマ字に変換して表示手段に表示させ、前記歌詞文字情報に含まれる文字が平仮名もしくは片仮名の場合、当該平仮名もしくは片仮名をローマ字に変換して表示手段に表示させることを特徴とする。さらに本発明にかかるカラオケ装置は、前記ルビ文字情報に基づいて変換されたローマ字は、変換元となったルビ文字情報のサイズ以内で表示することを特徴とする。さらに本発明にかかるカラオケ装置において、前記歌詞表示処理は、1文字先または1文字前の文字を参照してローマ字に変換することを特徴とする。さらに本発明にかかるカラオケ装置において、前記歌詞表示処理は、ローマ字への変換対象となる文字が、促音っの場合は1文字先の文字を参照してローマ字に変換する、または、長音符ーの場合は1文字前の文字を参照してローマ字に変換することを特徴とする。さらに本発明にかかるカラオケ装置は、前記ルビ文字情報に基づいて変換されたローマ字と、平仮名または片仮名に基づいて変換されたローマ字とは、異なる段に表示させることを特徴とする。本発明によれば、日本語曲をローマ字表記することで、日本語の判読に不慣れな外国人ユーザーなどに対して、日本語曲の歌唱を容易にさせることが可能となる。特に、既存の楽曲情報を用いて行うことで、楽曲情報の改変や追加などを必要とせず、機能追加に伴う手間とコストを削減することが可能となる。また、カラオケ装置において、楽曲が指定されてから後に、ローマ字への変換を行うこととなるため、楽曲情報のデータ量増加を伴うこともない。図1は、本発明の実施形態に係るカラオケ装置の構成を示す図である。本実施形態のカラオケ装置1コマンダともいうは、CPU14、RAM15、ROM16などで構成される制御部を中心として、HDDハードディスク13、音声処理部18、映像処理部11、操作パネル10、通信インタフェイス17などを備えて構成されている。制御手段を構成するCPU14、RAM15、ROM16は、コンピューターにおいて一般的に使用される構成であって、CPU14は、プログラムの実行などに基づく各種制御を、RAM15、ROM16、ハードディスク13などに記憶する各種プログラム、各種データに基づいて行う。カラオケ装置1における音声処理部18は、主として演奏情報に基づく演奏処理を実行する手段である。演奏情報はMIDI規格に基づいて作成されたデータの他、コーラスなどを担当する音声データなどを含んで構成されている。音声処理部18では、ユーザーが指定した楽曲に対応する演奏情報に基づいて演奏処理を実行することで、所望の楽曲の演奏を行う。また、オーディオ入力端子に接続されたマイクから入力された音声情報と、演奏情報に基づく演奏音をミキシングしてアンプに出力し、アンプに接続されているスピーカーから放音する。なお、マイクから入力される音声情報に対しては、エコーなどの効果を付加することも可能としている。映像処理部11は、歌詞表示処理、並びに、背景映像表示処理など、ディスプレイ12を介してユーザーに視覚的情報を提供する処理を実行する。歌詞表示処理は、楽曲情報に含まれる歌詞情報に基づいて歌詞をディスプレイ12に表示させる処理であって、演奏処理に同期して実行される。ディスプレイ12に表示された歌詞は、演奏に同期して歌唱すべき箇所が色替え表示され、歌唱者に歌唱箇所を教示する。また、背景映像表示処理は、演奏される楽曲の対応した各種映像を表示することで、歌唱の雰囲気を盛り上げる処理である。そのため、記憶手段としてのハードディスク13には、MPEG形式などによる圧縮が施された背景映像情報が記憶されており、映像処理部11では、この背景映像情報をデコードすることでディスプレイ12に映像を表示する。通信インタフェイス17は、ネットワーク接続端子を介してインターネットに接続され、図示しないホスト装置から、新しくリリースされた楽曲情報や、背景映像情報、プログラムなどを受信するとともに、ホスト装置に対して利用履歴などを送信する。近年では、ユーザーの利用履歴、登録楽曲などを含んだユーザー情報をホスト装置で管理し、当該ユーザーの利用時に受信することで、各個ユーザーに即したサービスを提供することも可能である。カラオケ装置1に対して行われる楽曲指定予約など、ユーザーからの各種指示は、操作パネル10から行うことも可能であるが、通常、店舗内のネットワークに接続されたリモコン装置図示せずから行われる。リモコン装置は、タッチパネルなどのインタフェイスを備えており、ユーザーに各種情報を表示提供するとともに、タッチ指示による入力受付を行うことが可能となっている。記憶手段として機能するハードディスク13には、楽曲を演奏するための楽曲情報の他、ディスプレイに背景を表示するための背景映像情報、そして、カラオケ装置において各種処理を実行するためのプログラムを記憶している。また、前述したホスト装置から各種データを受信することで、記憶しているデータの追加、更新が実行される。本実施形態で説明する歌詞表示処理についても、プログラムとして受信させることで既存のカラオケ装置1に機能追加することが可能である。では、本発明の特徴となる歌詞表示処理について説明する。図2は、本発明の実施形態に係る楽曲情報のデータ構成を示す図である。本実施形態の楽曲情報は、既存のものを利用することが可能である。すなわち、楽曲情報に対して何ら加工、改変を行うことなくローマ字表示させることが可能となっている。このように、カラオケ装置1にて実行されるプログラムにてローマ字表示を行うこととしているため、楽曲情報の加工、改変に必要な手間、コストを抑えることが可能となっている。さらには、ローマ字表示のためのデータ量増加を伴うこともなく記憶容量を増加させることもない。図2に示されるように楽曲情報は、楽曲情報の各種属性を示すメタデータ、演奏のために使用される演奏情報、歌詞表示のために使用される歌詞情報を含んで構成されている。本実施形態では、メタデータとして曲名、作曲者名、曲番号、ジャンル、個別素材画像の有無などを含んで構成されている。曲名、作曲者名、曲番号、ジャンルは、楽曲を検索、指定するための情報として用いられる。個別素材画像は、背景映像として当該楽曲に特化したものを有しているか否かを示す情報であって、有りの場合には、アーティストのライブ映像など当該楽曲に特化した映像が使用可能である。本実施形態の演奏情報は、MIDI規格に即して作成されたMIDIデータとされているが、この他、バックコーラスなどの音声情報を含ませることとも考えられる。MIDIデータの場合には、演奏手段としてのMIDI音源に演奏させることで楽音が奏でられる。歌詞情報テロップデータは、演奏情報による演奏に同期してディスプレイ12に歌詞を表示させるためのデータである。本実施形態では、1つのタイミングで1度に表示させるブロックデータを単位として構成されている。演奏情報の演奏に同期して出力されるステップ値をに基づいて、このブロックデータを読み出し、表示制御することで、演奏に同期した歌詞表示が実行されることとなる。各ブロックデータは、表示データ、属性データ、ルビブロックデータを含んで構成されている。表示データは、表示させるべき歌詞の文字列歌詞文字情報、及び、当該文字列の位置決めのための座標を含んで構成されている。なお、1画面内に表示させるブロックデータは、複数設けることが可能であって、歌唱終了した箇所のブロックデータの歌詞を消去し、新たなブロックデータの歌詞を表示させることで、スムースな歌唱を行うことが可能である。属性データは、表示データに含まれる文字列、並びに、ルビブロックデータに含まれる文字列の表示、消去、色替えタイミングを決めるための情報を含んだデータ群である。これらタイミングを決めるため、本実施形態では、演奏情報の進行に同期して出力されるステップ値MIDIステップ値に対応づけられている。表示ステップ、消去ステップは、表示データ、ルビブロックデータの文字列の表示タイミング、消去タイミングを示すステップ値である。また、変化ステップは、表示データ、ルビブロックデータの文字列を色替えを開始するためのステップ値であって、本実施形態では文字列の色替え速度を示す変化速度を含んで構成されている。なお、属性データには、同ブロックデータ内に含まれるルビブロックデータの数ルビブロック数も含まれている。ルビブロックデータは、表示データの文字列主として漢字に対しルビ読み仮名:平仮名、片仮名を表示するためのデータである。各ルビブロックデータは、文字列ルビ文字情報とそれを位置決めするための相対座標を含んで構成されている。以上が本実施形態の楽曲情報のデータ構成であるが、データ構成については、本発明の趣旨を変更しない限り適宜形態を採用することができる。では、本実施形態の歌詞情報ブロックデータとその描画結果の例について図3を用いて説明する。図3aは、本実施形態のブロックデータを示した例である。なお、この例では、表示ステップなどタイミングを示す各種データは省略して記載している。明日へ向かって飛べという表示データ内の文字列以下、本体文字列というについて、各漢字明日、向、飛について平仮名のルビを振った形態となっている。本実施形態において、本体文字を位置づけるための座標は、画面左上から本体文字列左上まで座標ドット数で表されている。本実施形態では、表示する文字列に所定の大きさのフォントを利用しており、このように1つのポイントを指定するのみで本体文字の位置決めが行われている。なお、位置決めについては、このように1つのポイントのみならず、例えば本体文字列の左上と右下を指定し、それらによって決められる枠内に合わせて表示するなど適宜形態を採用することができる。このような場合、大きさを自在に可変できるスケーラブルフォントを用いることが好ましい。ルビについては、各漢字明日、向、飛についてあす、む、との平仮名を振ることになるが、その位置づけは、表示データで使用した座標からの相対座標で指定することとしている。本実施形態では、表示データ内の座標から右方向を正とし、文字列の左端までのドット数で定義づけている。ルビについても本体文字列と同様、文字列に所定の大きさのフォントを利用したものとなっているため、画面内上下方向の位置については、利用するフォントの大きさに基づいて自動で決定することが可能となっている。このようなブロックデータによる描画結果の例が図3bに示されている。図3aには記載されていないが、属性データ内の変化ステップに基づいて、本体文字列の左から右に向かって色替えすることで、歌唱者は歌唱箇所を認識することが可能となる。また、ルビについても本体文字列の色替え位置に合わせて色替えすることで、歌唱がさらに容易になる。では、本実施形態において楽曲情報を再生させる処理について詳細に説明する。図4は、発明の実施形態に係る楽曲情報再生処理を示すフロー図である。カラオケ装置を操作するユーザーは、図1の操作パネル10、あるいは、ネットワークに接続されたリモコン装置などの指定手段を利用して歌唱したい楽曲を指定する。楽曲の指定は通常、予約という形態で行うことが可能となっており、予約された楽曲は、その識別子例えば、曲番号をRAM15内の予約テーブルに記録し、予約テーブルから識別子を順次、読み出して楽曲情報の再生が実行される。操作パネル10などから指定された楽曲について、楽曲情報の再生が開始されると、まず、S101にてハードディスク13に格納されている楽曲情報が読み出される。S102では、読み出された楽曲情報に基づいて再生が開始されることとなるが、ここでは、演奏処理S200と、歌詞再生処理S300とが並列実行される。演奏処理は、読み出された楽曲情報内に含まれる演奏情報を、音声処理部18に演奏されることで実行される。この演奏処理は、カラオケ装置ではよく知られる処理であるため、ここでの説明は省略する。演奏処理では、演奏情報の進行を示すステップ値が順次出力されておりS103、歌詞再生処理S300では、このステップ値に基づいて歌詞の表示、消去、色替えが実行される。楽曲情報の再生は、こらら演奏処理S200、歌詞再生処理S300が終了するまでS104実行されることとなる。では、この歌詞再生処理S300の詳細について説明する。図5は、本発明の実施形態に係る歌詞再生処理を示すフロー図である。歌詞再生処理は、図5の右上に示されるように楽曲データ内の歌詞情報、歌詞文字を表示するためのフォントデータ、演奏処理に伴って出力されるステップ値に基づいて実行される。歌詞情報に含まれる各ブロックデータに対して、S301~S312のブロックデータ処理ループが順次実行される。S302では、演奏処理で出力されるステップ値と読み出されているブロックデータ中、属性データに含まれる各ステップ表示ステップ、消去ステップ、変化ステップとの比較が行われる。S303、S306、S309ではこの比較に基づいて後続の各処理に進むこととなる。表示ステップであることが判定された場合S303:Yesには、まず、ローマ字機能操作チェック、すなわち、現在、ローマ字変換を行う設定となっているか否かのチェックが実行されるS304。ローマ字変換を行う設定については、操作パネル10あるいはリモコン装置などの各種入力手段からユーザーの操作によって設定される。この設定は、楽曲再生中においても切り替えることが可能である。判定の結果、ローマ字変換機能を使用している場合S305:Yesには、ローマ字変換ブロック描画処理S500にて歌詞の描画が実行される。一方、機能を使用していない場合S305:Noには、通常ブロック描画処理が実行される。これら描画処理については後で詳しく説明する。ステップ値との比較の結果、変化ステップであると判定された場合S306:Yesには、当該ブロックの文字列本体文字、ルビに対して色替えが実行される。この色換えは、ローマ字変換ブロック処理S500あるいは通常ブロック描画処理S400にて、画面に表示された文字列について、左端から順に色替えを行い、歌唱者に対して歌唱位置を告知する処理である。この処理は、ブロックデータの属性データに含まれる変化ステップのタイミングで開始される。S307では、属性データ内に含まれる変化速度に基づいて、1回の描画にて変更される色替えの変更幅ドット数が算出される。S308では、算出された変更幅にて順次、表示されている文字列の色替え描画が実行される。本実施形態では、本体文字列に対する色替え位置と同じ横方向の位置について、ルビの文字列の色替えを実行することとしており、歌唱位置の把握をより正確なものとしている。なお、本実施形態では、1つのブロックデータについて1つの変化速度としているが、ブロックデータ内で変化速度を変更することも可能であり、その場合、変化タイミングと変更後の変化速度が必要となる。ステップ値との比較の結果、消去ステップであることが判定された場合S309:Yesには、当該ブロックの文字列主部、ルビの消去が実行されるS310。以上の処理を演奏情報の演奏が終了するまでS311:Yes実行することで、演奏処理に同期した歌詞表示が実行されることとなる。では、歌詞の文字列を表示するための通常ブロック描画処理と、ローマ字変換ブロック描画処理について詳しく説明する。図6は、本発明の実施形態に係る通常ブロック描画処理を示すフロー図である。通常ブロック描画処理が開始されると、まず、S401にてブロックデータ中、表示データの座標が読み出され、本体文字列を配置していくための基準位置が設定される。続いて、S402からS407の処理にて、本体文字列の各本体文字についての描画が実行される。S403では、表示データの文字が読み出され、S404にて読み出された文字に対応するフォントデータによって描画が実行される。S405では、次に表示すべき文字の位置決めのため、S404にて描画した文字の描画Xサイズ画面横方向のサイズが取得される。S406では、次に描画する文字の位置決めのため、描画位置をXサイズ分だけ進行させる。このようにS403~S406の処理を繰り返すことで、表示データ中の文字列本体文字列の描画が実行される。S408~S416は、S401~S407にて表示された本体文字列に対して、ルビを振るための処理である。この一連の処理は、各ルビブロックデータを順に読み出すことで実行される。S409では、ルビブロックデータの表示データ中に記述される相対座標と、表示データ中の座標に基づいて、描画すべきルビの描画開始座標が設定される。表示データ中の座標に対して相対座標を加算することで実行される。本実施形態では、相対座標として画面横方向のみの座標が設定されているため、画面縦方向の座標は表示データ中の座標が使用されることとなる。S410~S415は、各ルビブロックデータ毎に実行される処理であり、本体文字列の描画S402~S407に類似した処理となっている。S411では、処理中のルビブロックデータの文字が読み出され、S412では、当該文字に対応するフォントデータに基づいて描画が実行される。S413、S414では、次のルビ文字の描画のための位置決定が実行される。このように各ルビブロックデータについて、S410~S415の処理を繰り返すことで、表示する本体文字列のルビ表示が実行される。以上、通常ブロック描画処理について説明したが、次にローマ字変換描画処理について、図7、図8を用いて説明する。図7、図8は、本発明の実施形態に係るローマ字変換ブロック描画処理を示すフロー図であり、特に図7は、本体文字列を表示するための処理であり、図8はルビ文字を表示するための処理となっている。なお、図7の丸Bは、図8に記載される丸B’に継続することを示している。図7に示されるS502~S516は、本体文字列を描画するための処理となっている。これらを繰り返すことで、表示データ中の文字列が画面に描画される。特に、本実施形態では、平仮名、片仮名のような一定の読みを有する表音文字について、アルファベットを使用したローマ字に変換することで、外国人など日本語の判読が困難なユーザーに対して歌唱を容易にすることとしている。特にローマ字への変換は、楽曲再生処理中に実行されるため、予め楽曲情報特に、歌詞情報を新たに用意する、あるいは、楽曲情報に変更を加えることを必要とせず、手間やコストを削減しつつも機能追加を図ることが可能となる。また、楽曲再生中に変換を行うため、変換されたローマ字のための記憶容量も必要とせず、楽曲情報のデータ量増加を伴うこともない。S503では、表示データ中、文字列の1文字が読み出され、S504にて対応するフォントデータに基づいて画面に描画が行われる。S507は描画した文字が表音文字、すなわち、平仮名もしくは片仮名であるかが判定される。本実施形態では、このように本体文字が表音文字に対しては以下の処理S508~S515にて、当該本体文字をローマ字に変換してルビを振ることとしている。S505にて平仮名もしくは片仮名でないと判定された場合には、S514、S515に進み、次に描画するための文字の基準位置を決定するための処理を実行し、次の本体文字の処理、あるいは、ルビブロックの処理に進む。S505にて平仮名もしくは片仮名であると判定された場合には、まず、ルビ描画のため基準位置を移動させるS506。本実施形態では、本体文字描画の基準位置から画面縦方向Y方向に所定量移動した位置を、ルビ描画のための基準位置としている。S507では、現在処理している文字が拗音、ぐたいてきにはちゃ、きゅなどにおけるゃ、ゅであるか否かが判定される。拗音の場合には、S508で処理済みとなるため、描画を行うことなく、基準位置を本体文字の描画のための位置に戻しS513て処理を抜ける。一方、拗音でないと判定された場合は、S508にて次の文字が拗音であるか否かが判定される。次の文字が拗音でない場合S508:Noには、通常の文字表記であるため、S509にて処理中の文字1字分に対してローマ字変換処理を実行する。このローマ字変換処理は、平仮名もしくは片仮名をローマ字に変換するという単純な処理であって、簡単な変換テーブルを用いて実行することが可能である。例えば、あ、キの場合にはA、Kiと1文字または2文字のアルファベットに変換される。S510では、S506にて移動させた基準位置にて変換されたローマ字を描画する。S508にて次の文字が拗音であると判定された場合、次の文字拗音も含めたローマ字変換処理が実行されるS511。例えば、ぎゃ、ピョの場合には、Gya、Pyoと3文字のアルファベットに変換される。なお、変換規則によってはじゃをJaと表記するなど2文字のアルファベットに変換してもよい。S512では、ローマ字に変換されたルビを画面に描画する。図9には、本発明の実施形態に係る全ルビの楽曲の歌詞表示例が示されている。ここで全ルビの楽曲とは、本体文字列に使用する漢字全てについてルビが設けられている楽曲のことをいう。図9aは、通常ブロック処理による歌詞表示であり、図9bは、ローマ字変換ブロック描画処理の表示例である。ユーザーは、操作パネル10などの入力手段を使用して、これらの表示形態を切り替えることができる。また、図9の変換例から分かるように、本体文字へ、け、て、べに対して、ローマ字によるルビHe、Ke、Te、Beが付されている。図8に記載されるフロー図は、図7のフロー図の続きであって、主としてルビブロックに対する処理が示されている。S517~S532の処理では、各ルビブロックに対して行われる処理が示されている。この処理を各ルビブロックに対して実行することで、元々漢字などに付されていたルビのローマ字変換が実行されることとなる。S518は、読み出されたルビブロック中、描画するための基準位置となる相対座標が読み出され、表示データ中の座標とに基づいてルビ文字を描画するための基準位置描画開始座標が設定される。S519~S529の処理は、各ルビ文字に対して行われる処理である。S520では、ルビブロックデータ中の文字列中の1文字が読み出される。S521では、当該文字に対応するフォントを描画するために必要な画面横方向のサイズXサイズが取得される。S522では、このXサイズを加算し、1つのルビブロックデータ中のルビ文字列を描画するに必要な画面横方向の大きさが算出される。S523~S528の処理は、本体文字列を処理した場合と同様、拗音の有無に基づいてローマ字変換、並びに、描画処理となっている。本実施形態では、S526、S528で画面に描画することなく、バッファ領域に描画することとしている。これは後の処理で、ローマ字変換されたルビ文字列の大きさを考慮して描画を行うためである。ルビブロックデータ中のルビ文字列の描画この場合、バッファ領域への描画が完了すると、S529にて処理を抜け、S530にてバッファ領域に描画した文字列の拡大縮小が実行される。この処理は、S522で算出された元々ローマ字変換処理前のルビ文字列の大きさ画面横方向についてに拡大または縮小する処理である。図10は、このS530で実行されるローマ字変換後のルビの縮小プロセスの例を示した図である。ルビ文字列あすについて、ローマ字変換が実行された場合を考えてみる。ローマ字変換後のルビ文字列はAsuと3文字表記となるため、元々の2文字表記よりも画面横方向の大きさが大きくなってしまう。そのため、本実施形態では、画面横方向の大きさについて、変換前の文字表記の大きさにサイズ変換縮小することで、文字数が多くなった場合においても、隣り合うルビブロックの文字との重複を防ぎ、ルビ文字を見易くすることが可能となる。また、文字の色替えに関しても、変換前の文字表記とほぼ同タイミングで実行されることとなり、ローマ字変換後においても歌唱し易さを確保することが可能となる。S531では、S530について拡大縮小されたバッファ領域内のルビ文字列を画面に描画する。以上の処理を各ルビブロック全てについて実行し、一連の処理を終了する。以上、本実施形態における歌詞表示処理について説明したが、本実施形態では、楽曲情報の再生中に演奏処理と同時進行で実行される歌詞表示処理において、ルビのローマ字変換が行われることしており、ローマ字表示のための歌詞情報の追加、変更を必要としない。前述の実施形態では全ルビについて説明したが、楽曲情報には一部の漢字のみにルビが設けられた楽曲も存在する。図11は、そのような場合の全ルビではない楽曲に対して、本実施形態の歌詞表示処理を適用した場合の表示例である。本実施形態では、表音文字を有さない文字この場合明日、向については、ローマ字変換を実行することができないため、図11bに示されるような表示形態となってしまう。しかしながら、歌唱できない文字が、数文字あったとしても歌唱全体からみれば影響は少なく、、また、楽曲情報に手を加えることなく歌詞表示処理のためのプログラムのみで対応できるという効果からみても、このような全ルビでは内楽曲に対しても適用する意義は大きい。図12は、本発明の実施形態に係る歌詞のローマ字変換のプロセス、並びに、変形例をまとめた例である。図中1、2、5で示されるルビを有さない漢字については、ローマ字によるルビが付されないこととなる。一方、図中3、6、8、9、12、14については、一律にローマ字変換することが可能な平仮名もしくは片仮名であるため、各本体文字上部にローマ字変換されたルビが表記されることとなる。ここで、図の8に示されるように、本体文字あるいはルビ文字が促音っを含む場合には、1つ先の文字を参照してローマ字に変換することが好ましい。この場合ってとなっているため、1つ先の文字であるての子音部分tが促音っのルビとして変換されることとなる。この他っさの場合には、促音の1つ先のもじであるさの子音部分sがルビとして変換される。このような変換規則の例としては、他にタワーなどに用いられる長音符ーについても考慮することが好ましい。タワーの場合には、1文字前の文字ワを参照することとなり、具体的には1文字前の文字の母音部分aがーのルビとして変換されることとなる。また、本実施形態では、本体文字が片仮名の場合、平仮名の場合と区別できるような表示形態この場合、斜体文字でルビを表示している。本体文字が片仮名の場合、英語を基準とした外来文字であることが多く、このような文字については平仮名の場合と異なる形態にて表示することで、外国人などのユーザーはさらに歌唱が容易となる。図13は、さらなる応用例を示した場合を示す例であって、図13aは、ローマ字変換前の表記例が、図13bは、ローマ字変換後の表示例が示されている。曙のように読み仮名が多数文字にわたる場合、ローマ字に変換すると文字数はさらに増加することが考えられる。本実施形態では平仮名や片仮名についてもルビ表示を行うこととしているため、ルビが重複して表示されることが懸念されるこの場合、AKeBoNoに隣接するHe。そのため、本実施形態では、元々付されていたルビをローマ字変換したルビと、本体文字における平仮名、片仮名をローマ字変換したルビを異なる段に表示させることとしている。このように異なる段に表示させることで、変換されたローマ字が重複して表示されることを避け、判読の容易性を向上させることが可能となる。なお、本実施形態では、異なる段に表示させる際、本体文字の平仮名、片仮名部分を縦方向に圧縮し、ルビ表記に必要なスペースを形成しているが、この形態を必須とするものではない。なお、本発明はこれらの実施形態のみに限られるものではなく、それぞれの実施形態の構成を適宜組み合わせて構成した実施形態も本発明の範疇となるものである。