(57)【要約】【課題】適切なタイミングで適切な波形データの作成等を行う。【解決手段】配信時には標準ピッチのＭＰ３データのみ含まれた楽曲データが配信され、受信後に、配信ヘッダ中に含まれるＭＰ３キー変更データ付加パターンに基づいて標準ピッチ以外のＭＰ３データを作成して楽曲データに付加する。その後、実際の演奏頻度に応じても適切な対応をする。楽曲毎に、演奏頻度に応じて持つべきＭＰ３データを現在持っているか否かを判断し、ＭＰ３データが不足する場合には当該不足するＭＰ３データを作成して記憶し、一方、ＭＰ３データが過剰な場合には、当該過剰なＭＰ３データを削除する。これにより演奏回数が多い曲は多くの種類のＭＰ３データを、逆に、演奏回数が少ない曲は相対的に少ない種類のＭＰ３データを持るようになる。演奏時には、ピッチ変更量が最も少なくなるＭＰ３データをデコードし、必要ならばさらにピッチ変更する。【選択図】  図２
2004279690.tif 000002
【特許請求の範囲】
【請求項１】
デジタル符号化された少なくとも標準ピッチの波形データを記憶する波形データ記憶手段、
前記波形データ記憶手段に記憶された波形データを再生する波形データ再生手段、
前記標準ピッチからのピッチ変更量を指示するための操作入力を受け付けるピッチ変更入力受付手段、
前記波形データ再生手段によって再生された波形データに対し、前記ピッチ変更入力受付手段によって受け付けたピッチ変更量に基づいてピッチ変更処理を実行する第１のピッチ変更手段、
前記第１のピッチ変更手段によってピッチ変更された波形データに基づいて楽曲の演奏を行なう楽曲演奏手段と、
前記波形データ再生手段によって再生された波形データに対してピッチ変更処理を実行する第２のピッチ変更手段、
前記第２のピッチ変更手段によってピッチ変更のなされた波形データをデジタル符号化する符号化手段、
前記符号化手段によってデジタル符号化された波形データを前記波形データ記憶手段に記憶させる記憶制御手段、を備え、
前記第１のピッチ変更手段は、前記ピッチ変更入力受付手段によって受け付けたピッチ変更量に基づき、当該ピッチ変更量だけ変更した後のピッチに最も近いピッチの波形データを前記波形データ記憶手段から読み出し、その読み出した波形データを用いて前記ピッチ変更処理を実行する情報処理装置であって、
前記波形データ記憶手段に記憶される標準ピッチの波形データに対応して、その標準ピッチの波形データ以外に作成して記憶しておくべき波形データのピッチ変更量を記憶しておき、
前記第２のピッチ変更手段は、前記標準ピッチの波形データに対応するピッチ変更量に基づいてピッチ変更処理を実行し、
その第２のピッチ変更手段によってピッチ変更のなされた波形データを符号化手段によってデジタル符号化し、その符号化手段によってデジタル符号化された波形データを前記記憶制御手段によって前記波形データ記憶手段に記憶させる
情報処理装置。
【請求項２】
デジタル符号化された少なくとも標準ピッチの波形データを記憶する波形データ記憶手段、
前記波形データ記憶手段に記憶された波形データを再生する波形データ再生手段、
前記標準ピッチからのピッチ変更量を指示するための操作入力を受け付けるピッチ変更入力受付手段、
前記波形データ再生手段によって再生された波形データに対し、前記ピッチ変更入力受付手段によって受け付けたピッチ変更量に基づいてピッチ変更処理を実行する第１のピッチ変更手段、
前記第１のピッチ変更手段によってピッチ変更された波形データに基づいて楽曲の演奏を行なう楽曲演奏手段と、
前記波形データ再生手段によって再生された波形データに対してピッチ変更処理を実行する第２のピッチ変更手段、
前記第２のピッチ変更手段によってピッチ変更のなされた波形データをデジタル符号化する符号化手段、
前記符号化手段によってデジタル符号化された波形データを前記波形データ記憶手段に記憶させる記憶制御手段、を備え、
前記第１のピッチ変更手段は、前記ピッチ変更入力受付手段によって受け付けたピッチ変更量に基づき、当該ピッチ変更量だけ変更した後のピッチに最も近いピッチの波形データを前記波形データ記憶手段から読み出し、その読み出した波形データを用いて前記ピッチ変更処理を実行する情報処理装置であって、
さらに、
一定の集計期間中に前記楽曲演奏手段によって演奏された頻度を反映した演奏頻度反映情報を楽曲毎に集計する集計手段、
前記集計手段によって集計された演奏頻度反映情報を用いて、楽曲毎に、標準ピッチの波形データ以外に作成して記憶しておくべき波形データのピッチ変更量を決定するピッチ変更量決定手段、
楽曲に対応する波形データ毎に、前記ピッチ変更量決定手段によって決定されたピッチ変更量に対応する波形データとの過不足を判断し、不足する場合には、前記第２のピッチ変更手段によって当該不足する波形データに対応するピッチ変更量だけピッチ変更処理を実行し、その第２のピッチ変更手段によってピッチ変更のなされた波形データを符号化手段によってデジタル符号化し、その符号化手段によってデジタル符号化された波形データを前記記憶制御手段によって前記波形データ記憶手段に記憶させ、一方、過剰な場合には、当該過剰な波形データを前記記憶制御手段によって前記波形データ記憶手段から削除させる、波形データ作成削除制御手段、を備える
情報処理装置。
【請求項３】
請求項２に記載の情報処理装置において、
前記波形データ記憶手段に記憶される標準ピッチの波形データに対応して、その標準ピッチの波形データ以外に作成して記憶しておくべき波形データのピッチ変更量を記憶しておき、前記第２のピッチ変更手段は、前記標準ピッチの波形データに対応するピッチ変更量に基づいてピッチ変更処理を実行し、その第２のピッチ変更手段によってピッチ変更のなされた波形データを符号化手段によってデジタル符号化し、その符号化手段によってデジタル符号化された波形データを前記記憶制御手段によって前記波形データ記憶手段に記憶させる、初期化処理を実行し、
その初期波形データ作成記憶処理を実行した後は、前記集計手段によって集計された演奏頻度反映情報を用いて前記ピッチ変更量決定手段が決定したピッチ変更量に基づき、前記波形データ作成削除制御手段が過不足の波形データを削除又は作成追加する、使用状況反映処理を実行する
情報処理装置。
【請求項４】
請求項３に記載の情報処理装置において、
前記初期化処理が実行された時点から一定期間内は、前記使用状況反映処理は実行しない
情報処理装置。
【請求項５】
請求項３に記載の情報処理装置において、
前記初期化処理が実行された時点から一定期間内は、前記使用状況反映処理において波形データの作成追加のみ実行し、波形データの削除は実行しない
情報処理装置。
【請求項６】
請求項２〜５の何れかに記載の情報処理装置において、
前記集計手段が集計する演奏頻度反映情報は、演奏回数又は前記集計期間中の累積演奏時間の少なくとも何れかである
情報処理装置。
【請求項７】
請求項２〜６の何れかに記載の情報処理装置において、
前記集計手段は、前記波形データの不足を判断するための集計期間（以下、第１の集計期間と称す。）と、前記第１の集計期間とは異なる期間であって前記波形データの過剰を判断するための集計期間（以下、第２の集計期間と称す。）のそれぞれにおいて、前記演奏頻度反映情報を集計し、
前記波形データ作成削除制御手段は、前記第１の集計期間中に集計された演奏頻度反映情報を用いて前記ピッチ変更量決定手段が決定したピッチ変更量に対応する波形データに基づき、前記波形データの不足を判断し、一方、前記第２の集計期間中に集計された演奏頻度反映情報を用いて前記ピッチ変更量決定手段が決定したピッチ変更量に対応する波形データに基づき、前記波形データの過剰を判断する
情報処理装置。
【請求項８】
請求項７に記載の情報処理装置において、
前記第１の集計期間よりも前記第２の集計期間を長くした
情報処理装置。
【請求項９】
請求項７又は８に記載の情報処理装置において、
前記ピッチ変更量決定手段は、
前記演奏頻度反映情報を用いて前記ピッチ変更量を決定する際、当該ピッチ変更量の種類の増減を決定する境界を、集計期間ｘ、演奏頻度の反映量ｙとした場合にｙ＝ａｘ（ａは係数）となる一次関数によって決定し、且つ、増加時と減少時で前記一次関数の係数を同一とした
情報処理装置。
【請求項１０】
請求項１〜９の何れかに記載の情報処理装置において、
音符を元にした楽曲演奏情報を記憶する楽曲演奏情報記憶手段を備え、、
前記楽曲演奏手段は、前記第１のピッチ変更手段によって変更された波形データ及び前記楽曲演奏情報記憶手段に記憶された楽曲演奏情報に基づいてカラオケ演奏を行い、
前記波形データ記憶手段は、カラオケ演奏時に用いるバックコーラス用の波形データを記憶している
情報処理装置。
【請求項１１】
請求項１０に記載の情報処理装置において、
外部装置と通信するための通信手段を備え、
前記楽曲演奏情報及び波形データを含むカラオケ演奏用のデータは、外部装置から配信されたものである
情報処理装置。
【請求項１２】
請求項１〜１１の何れかに記載の情報処理装置において、
前記第１のピッチ変更手段は、クロスフェード方式によるピッチ変更処理を実行する
情報処理装置。
【請求項１３】
請求項１〜１２の何れかに記載の情報処理装置において、
前記第２のピッチ変更手段は、クロスフェード方式によるピッチ変更処理に対してピッチ変更後の音質劣化が少ない方式によるピッチ変更処理を実行する
情報処理装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、波形データに対してピッチ変更を行うピッチ変更手段を備えた情報処理装置に関する。
【０００２】
【従来の技術】
昨今、カラオケ市場においては、いわゆる通信カラオケというものが一般的になっている。この通信カラオケはＭＩＤＩ演奏が一般的だが、例えばバックコーラスなど肉声が欲しい時はデジタルオーディオデータを使う。デジタルオーディオデータはそのままではデータが巨大過ぎるため、通常はＡＤＰＣＭ（Ａｄａｐｔｉｖｅ  Ｄｉｆｆｅｒｅｎｔｉａｌ  Ｐｕｌｓｅ  Ｃｏｄｅ  Ｍｏｄｕｌａｔｉｏｎ）やＭＰ３等のコーデックでエンコード（圧縮）して保存しておき、使用時にはデコード（解凍）している。
【０００３】
また、例えばカラオケ装置においては、デフォルト状態での演奏ピッチがユーザの音域に合わないための対処として、ピッチを変更（増減）させることができるようになっている。具体的には、カラオケ曲の演奏が開始された後に、例えばピッチを増加させる場合には「＃」ボタンを押し、逆に、ピッチを減少させる場合には「♭」ボタンを押すことで、ピッチ変更を実現していた。
【０００４】
例えばバックコーラス付きのカラオケＭＩＤＩ楽曲をピッチコントロールしようとした場合、ＭＩＤＩ演奏についてはＭＩＤＩデータの構造上から容易にピッチコントロール可能であるが、バックコーラスについては特殊な方法を用いてピッチコントロール（一般にはピッチシフト等と称す。）を行なう必要があった。
【０００５】
ピッチシフトの方法には、クロスフェードを用いる方法（例えば、特許文献１参照）やＦＦＴ（＝高速フーリエ変換）等の周波数変換を用いる方法（例えば、特許文献２参照）等各種あるが、例えばカラオケ装置において実現する場合には、その目的からリアルタイムにピッチシフトを行なう必要がある。ここで、周波数変換方式は音質劣化が少ないが、その一方で計算量がクロスフェード方式と比べて多いため、処理負荷の観点からクロスフェードを用いる方法が一般的であった。
【０００６】
しかし、クロスフェード方式では周波数変換方式に比べて音質が劣化し易い欠点があった。例えばカラオケ装置においてピッチコントロールが必要とされる一般的範囲としては１オクターブ分が考えられるが、この範囲をカバーするための境界値は±６度にも及んでしまう。そして、このような±６度のピッチシフトをクロスフェード方式で行なうと、音質劣化が相当生じてしまうという問題があった。
【０００７】
このような問題に鑑み、本願出願人は、特願２００２−３２５５４１号（以下、先願とも称す。）において、ピッチ変更に際して周波数変換方式に比べて相対的に音質劣化が生じ易いが処理負荷の少ないクロスフェード方式を用いながらも、音質劣化が余り起こらないピッチ変更を実現する技術を提案した。この先願においては、例えばバックコーラス用のデータとして、標準ピッチの波形データに加え、その標準ピッチの波形データに対してピッチが変更された１以上の波形データを記憶しておき、ピッチ変更指示があった場合には、変更後のピッチに最も近いピッチの波形データを用いて再生し、必要ならばその再生した波形データに対してピッチ変更を行なう。
【０００８】
【特許文献１】
特許第第３１７５１７９号公報
【特許文献２】
特開２００１−３５６７９９号公報
【０００９】
【発明が解決しようとする課題】
ただし、このように１曲に対して多数の波形データを含めてしまうと、１曲の楽曲データのデータサイズが従来に比べて大きなものになってしまう。特に通信カラオケシステムにおいては新曲の楽曲データを頻繁に配信する必要があるが、配信データサイズが大きいことは通信費用・時間の増大を招来してしまうという問題があった。
【００１０】
本発明は、上述した問題点を解決するためになされたものであり、適切なタイミングで適切な波形データの作成等を行うことができる情報処理装置を提供することを目的とする。
【００１１】
【課題を解決するための手段及び発明の効果】
（１）上述した問題点を解決するためになされた請求項１に係る情報処理装置は、デジタル符号化された少なくとも標準ピッチの波形データを記憶する波形データ記憶手段、波形データ記憶手段に記憶された波形データを再生する波形データ再生手段、標準ピッチからのピッチ変更量を指示するための操作入力を受け付けるピッチ変更入力受付手段、波形データ再生手段によって再生された波形データに対し、ピッチ変更入力受付手段によって受け付けたピッチ変更量に基づいてピッチ変更処理を実行する第１のピッチ変更手段、第１のピッチ変更手段によってピッチ変更された波形データに基づいて楽曲の演奏を行なう楽曲演奏手段、波形データ再生手段によって再生された波形データに対してピッチ変更処理を実行する第２のピッチ変更手段、第２のピッチ変更手段によってピッチ変更のなされた波形データをデジタル符号化する符号化手段、符号化手段によってデジタル符号化された波形データを前記波形データ記憶手段に記憶させる記憶制御手段、を備え、第１のピッチ変更手段が、ピッチ変更入力受付手段によって受け付けたピッチ変更量に基づき、当該ピッチ変更量だけ変更した後のピッチに最も近いピッチの波形データを波形データ記憶手段から読み出し、その読み出した波形データを用いてピッチ変更処理を実行する情報処理装置である。
【００１２】
ここで、波形データ記憶手段に記憶される標準ピッチの波形データに対応して、その標準ピッチの波形データ以外に作成して記憶しておくべき波形データのピッチ変更量が記憶されている。このピッチ変更量は、例えば標準ピッチの波形データ自体に含めて記憶しておいてもよいし、あるいは別途対応関係を示すテーブル形式で記憶されていてもよい。そして、第２のピッチ変更手段は、標準ピッチの波形データに対応するピッチ変更量に基づいてピッチ変更処理を実行し、その第２のピッチ変更手段によってピッチ変更のなされた波形データを符号化手段によってデジタル符号化し、その符号化手段によってデジタル符号化された波形データを記憶制御手段によって波形データ記憶手段に記憶させる。
【００１３】
このように、本発明の情報処理装置によれば、標準ピッチの波形データ以外に作成して記憶しておくべき波形データのピッチ変更量が、標準ピッチの波形データに対応して記憶されているため、このピッチ変更量に応じた分だけ、標準ピッチからピッチ変更された波形データが作成・記憶されることとなる。したがって、例えば通信カラオケシステムを例にとって説明すれば、カラオケ装置へ新曲を配信する際、配信側で例えば経験則等によって演奏頻度の高低を推測し、演奏頻度が高そうであればピッチ変更した波形データを多く持たせるよう、また、演奏頻度が低そうであれば、ピッチ変更した波形データを少なく（零の場合、つまりピッチ変更した波形データを持たない場合も含む。）持たせるよう、標準ピッチの波形データに含めるピッチ変更量を設定すればよい。そして、この推測が妥当であれば、実際に波形データを用いた楽曲演奏時において、大きなピッチ変更を強いられる場面も少なくなり、且つ、ほとんど使用せずに無用の波形データを作成したり、そのような波形データが波形データ記憶手段内に居座るようなこともない。
【００１４】
（２）上述した問題点を解決するためになされた請求項２に係る情報処理装置は、デジタル符号化された少なくとも標準ピッチの波形データを記憶する波形データ記憶手段、波形データ記憶手段に記憶された波形データを再生する波形データ再生手段、標準ピッチからのピッチ変更量を指示するための操作入力を受け付けるピッチ変更入力受付手段、波形データ再生手段によって再生された波形データに対し、ピッチ変更入力受付手段によって受け付けたピッチ変更量に基づいてピッチ変更処理を実行する第１のピッチ変更手段、第１のピッチ変更手段によってピッチ変更された波形データに基づいて楽曲の演奏を行なう楽曲演奏手段、波形データ再生手段によって再生された波形データに対してピッチ変更処理を実行する第２のピッチ変更手段、第２のピッチ変更手段によってピッチ変更のなされた波形データをデジタル符号化する符号化手段、符号化手段によってデジタル符号化された波形データを前記波形データ記憶手段に記憶させる記憶制御手段、を備え、第１のピッチ変更手段が、ピッチ変更入力受付手段によって受け付けたピッチ変更量に基づき、当該ピッチ変更量だけ変更した後のピッチに最も近いピッチの波形データを波形データ記憶手段から読み出し、その読み出した波形データを用いてピッチ変更処理を実行する情報処理装置である。
【００１５】
そして、本情報処理装置は、さらに、一定期間中に楽曲演奏手段によって演奏された頻度を反映した演奏頻度反映情報を楽曲毎に集計する集計手段、集計手段によって集計された演奏頻度反映情報を用いて、楽曲毎に、標準ピッチの波形データ以外に作成して記憶しておくべき波形データのピッチ変更量を決定するピッチ変更量決定手段、波形データ作成削除制御手段を備えており、この波形データ作成削除制御手段は次のような制御を実行する。つまり、楽曲に対応する波形データ毎に、ピッチ変更量決定手段によって決定されたピッチ変更量に対応する波形データとの過不足を判断する。そして、波形データが不足する場合には、第２のピッチ変更手段によって当該不足する波形データに対応するピッチ変更量だけピッチ変更処理を実行し、その第２のピッチ変更手段によってピッチ変更のなされた波形データを符号化手段によってデジタル符号化し、その符号化手段によってデジタル符号化された波形データを記憶制御手段によって波形データ記憶手段に記憶させる。一方、波形データが過剰な場合には、当該過剰な波形データを記憶制御手段によって波形データ記憶手段から削除させる。
【００１６】
このように、本発明の情報処理装置によれば、標準ピッチの波形データ以外に作成して記憶しておく「ピッチ変更された」波形データについては、一定期間中に演奏された頻度を反映した情報に基づいている。なお、この演奏頻度反映情報としては、例えば請求項５に示すように、演奏回数又は集計期間中の累積演奏時間の少なくとも何れかとすることが考えられる。つまり、演奏頻度を知るための情報としては、演奏回数が適切であると考えられるが、例えば代替的に累積演奏時間であっても構わない。また、他の情報であっても構わない。例えばカラオケ装置に適用した場合を考えられると、リクエストに応じてカラオケ演奏がなされるため、リクエスト回数を演奏頻度反映情報としてもよい。
【００１７】
本発明は、実際の演奏状況を反映した適切な種類の「ピッチ変更された波形データ」を持たせようとする思想である。例えば演奏頻度が高い場合には相対的に多くの種類の「ピッチ変更された波形データ」を持たせ、逆に、演奏頻度が低い場合には相対的に少ない種類の「ピッチ変更された波形データ」を持たせるようにすることができる。
【００１８】
なお、具体的には、必要な波形データ数を決定し、その波形データ数に基づいてピッチ変更量を決定するような手法が考えられる。例えば−６度〜＋６度の範囲での波形データ数をまず決定する。最小は標準ピッチだけの場合の１個であり、最大は全てのピッチに対応した１３個である。ここで、必要な波形データの個数を決めた場合、それをどの程度のピッチ変更量だけピッチ変更した波形データに割り当てるかは、常識的に決まる。つまり、楽曲演奏時における第１のピッチ変更手段によるピッチ変更量が少ない方がよいということから考えれば、例えば３個の波形データを持たせる場合、上記目的を達成するためには、適宜分散させ、例えば標準ピッチに加えて−４度及び＋４度程度のピッチ変更量の波形データを持たせることとなる。他の個数の場合についても、適宜分散させるようにするのが一般的である。
【００１９】
（３）請求項３に係る発明は、上述した請求項１に係る発明と請求項２に係る発明の両方の機能を発揮可能なものである。但し、これらは同時期に行うものではなく、請求項１において説明したような処理、すなわち、波形データ記憶手段に記憶される標準ピッチの波形データに対応して、その標準ピッチの波形データ以外に作成して記憶しておくべき波形データのピッチ変更量を記憶しておき、第２のピッチ変更手段は、前記標準ピッチの波形データに対応するピッチ変更量に基づいてピッチ変更処理を実行し、その第２のピッチ変更手段によってピッチ変更のなされた波形データを符号化手段によってデジタル符号化し、その符号化手段によってデジタル符号化された波形データを記憶制御手段によって波形データ記憶手段に記憶させる、初期化処理をまず実行する。
【００２０】
そして、その初期波形データ作成記憶処理を実行した後に、請求項２において説明したような処理、すなわち、集計手段によって集計された演奏頻度反映情報を用いて前記ピッチ変更量決定手段が決定したピッチ変更量に基づき、波形データ作成削除制御手段が過不足の波形データを削除又は作成追加する、使用状況反映処理を実行する。
【００２１】
この初期化処理は、いわばデフォルト状態を決めるための工夫である。そして、このような初期化処理において適切な種類の波形データが準備されていれば、その後の使用状況反映処理において、ほとんど波形データの削除又は作成追加を実行しなくてもよくなる。つまり、例えばカラオケ装置などを考えてみると、どの程度流行するかを予測して波形データ種類を決めておけば、流行した時点では既に十分な準備が整っていることとなり、運用上、非常に好ましい。但し、流行時期が過ぎると演奏頻度も当然低下していくため、このような場合には使用状況反映処理によって、自然とピッチ変更された波形データが少なくなっていく。
【００２２】
また、請求項４に示すように、初期化処理が実行された時点から一定期間内は、使用状況反映処理は実行しないようにすることも考えられる。初期化処理は、その後の使用状況も想定して決定され適切（であると考えられる）種類の波形データがを予め準備しておくものである。例えばカラオケ装置へ適用した場合を考えると、新曲を追加し、その新曲の人気を想定して初期化処理を行った場合、結果的にみればその曲が予想通りの演奏頻度となったとしても、新曲追加当初は、演奏頻度が相対的に低くなるのが普通である。ある程度の期間を経て予想通りの演奏頻度となるにしても、初期段階では演奏頻度が低いことが考えられる。そのような場合に、上述の使用状況反映処理を適用すると、初期化処理においてせっかく準備した波形データを一旦削除し、その後再度作成することとなってしまう。そこで、初期化処理による状態はある程度適切なものと考え、所定期間は様子を見るということで、作成・削除を伴う使用状況反映処理は実行しないようにしたのである。
【００２３】
なお、使用状況反映処理の内、作成は行っても良いが、削除はしない、というようにしてもよい（請求項５）。
（４）また、請求項７に示すように、集計手段は、波形データの不足を判断するための集計期間（第１の集計期間）と、第１の集計期間とは異なる期間であって前記データの過剰を判断するための集計期間（第２の集計期間）のそれぞれにおいて、前記演奏頻度反映情報を集計し、波形データ作成削除制御手段は、第１の集計期間中に集計された演奏頻度反映情報を用いて前記ピッチ変更量決定手段が決定したピッチ変更量に対応する波形データに基づき、波形データの不足を判断し、一方、第２の集計期間中に集計された演奏頻度反映情報を用いて前記ピッチ変更量決定手段が決定したピッチ変更量に対応する波形データに基づき、波形データの過剰を判断するようにしてもよい。
【００２４】
このようにすれば、波形データの作成記憶や削除が頻繁に起こりすぎるのを防ぐことができる。ところで、波形データの作成に関しては、実際の演奏頻度に対してのレスポンスが低いと不適切であるため、短めが好ましいが、逆に削除時には余分に存在してもデータ量の増加という点以外のデメリットはないため、長めでよい。したがって、請求項８に示すように、第１の集計期間よりも第２の集計期間を長くすることが考えられる。なお、例えば、第２の集計期間を第１の集計期間の少なくとも２倍以上にすることが考えられる。
【００２５】
（５）また、請求項９に示すように、ピッチ変更量決定手段について、演奏頻度反映情報を用いてピッチ変更量を決定する際、当該ピッチ変更量の種類の増減を決定する境界を、集計期間ｘ、演奏頻度の反映量ｙとした場合にｙ＝ａｘ（ａは係数）となる一次関数によって決定し、且つ、増加時と減少時で一次関数の係数を同一としてもよい。
【００２６】
ピッチ変更量の種類の増減を決定するための判定式については種々考えられるが、簡易な判定のためにはこのような一次関数を用い、さらに増加時の境界を決めるための一次関数と減少時の境界を決めるための一次関数の係数を同一とすればよい。
【００２７】
（６）これまでの説明でも何度か例示しているが、この情報処理装置は例えばカラオケ装置に適用することができる。そして、カラオケ装置に適用する場合は、例えば請求項１０に示すように、音符を元にした楽曲演奏情報を記憶する楽曲演奏情報記憶手段を備え、楽曲演奏手段は、第１のピッチ変更手段によって変更された波形データ及び楽曲演奏情報記憶手段に記憶された楽曲演奏情報に基づいてカラオケ演奏を行い、波形データ記憶手段は、カラオケ演奏時に用いるバックコーラス用の波形データを記憶しているよう構成することが考えられる。
【００２８】
楽曲演奏情報及び波形データを含むカラオケ演奏用のデータについては、例えばＣＤ−ＲＯＭやＤＶＤ−ＲＯＭのようなパッケージメディアから読み込んでもよいが、請求項１１に示すように外部装置から配信してもらうこともできる。特に、いわゆる通信カラオケと称されるように、カラオケ演奏用データを外部装置（例えば配信センタ等のホストコンピュータ）から配信してもらうことが近年のカラオケ市場ではよく行われている。近年普及がめざましいブロードバンドの通信網を介して配信される場合には、通信コストが低下すると共に、カラオケ装置側で波形データを作成する手間が省けるメリットがある。
【００２９】
（７）なお、上述した第１のピッチ変更手段については、クロスフェード方式によるピッチ変更処理を実行することが考えられる。例えばカラオケ装置に適用した場合を想定すると、第１のピッチ変更手段はカラオケ曲の演奏時においてリアルタイムにピッチ変更処理を実行することとなるため、処理量が比較的少ないクロスフェード方式を採用することが好ましい。
【００３０】
一方、第２のピッチ変更手段については、クロスフェード方式によるピッチ変更処理に対してピッチ変更後の音質劣化が少ない方式によるピッチ変更処理を実行することが考えられる。第２のピッチ変更手段は楽曲演奏時にリアルタイムでピッチ変更処理を行う必要がなく、比較的時間に余裕がある状況で実行できる。そのため、クロスフェード方式よりも音質劣化が少ない方式によって処理した方がよいからである。この方式の例としては、高速フーリエ変換（ＦＦＴ）等の周波数変換方式によることが考えられる。
【００３１】
【発明の実施の形態】
以下、本発明が適用された実施例について図面を用いて説明する。なお、本発明の実施の形態は、下記の実施例に何ら限定されることなく、本発明の技術的範囲に属する限り種々の形態を採りうる。
【００３２】
図１（ａ）は、本発明の情報処理装置の一実施例としてのカラオケ装置１の構成を示すブロック図である。本実施例のカラオケ装置１は、いわゆる通信カラオケと称されるものであり、通信ネットワーク３を介してホストコンピュータ２に接続できるようになっている。そして、カラオケ装置１は、この通信ネットワーク３を介して接続したホストコンピュータ２からカラオケに関する音楽情報と画像情報とを取得することができる。
【００３３】
なお、ホストコンピュータ２は、通信ネットワーク３を介してカラオケ装置１とアクセス可能であって、カラオケ装置１に対して、最新の流行曲等の曲データを発信したり、どのような曲が何回演奏されたかといったログデータを含む関連情報をカラオケ装置１から受信したりして管理することができるようになっている。また、ホストコンピュータ２は、データベースを備えており、このデータベースに楽曲演奏に使用するコンテンツデータとしての音楽情報や背景画または歌詞等の画像情報等を記憶している。また、ホストコンピュータ２は、コンテンツデータ以外にバージョンアップされたシステムプログラム等をデータベースに記憶し、そのデータベースから随時読み出してカラオケ装置１に対して配信することができるようになっている。
【００３４】
次に、カラオケ装置１の構成について説明する。
このカラオケ装置１には、図１（ａ）に示されるように、ホストコンピュータ２に通信ネットワーク３を介して接続し各種の情報を送受信する通信装置１９、曲の予約操作などを行うための操作パネル１０、カラオケ装置１全体の制御を司る制御手段としてのＣＰＵ１４、各種情報を一時的に記憶するＲＡＭ１５、演奏の再生を行う音源再生装置１８、音楽情報にかかる電気信号を増幅等するアンプ２０、アンプ２０からの電気信号を入力して伴奏曲及び利用者（歌唱者）の歌声等を流すスピーカ２２、利用者（歌唱者）の歌声等をアンプ２０に入力するためのマイクロフォン（以下、単にマイクと称す。）２３、カラオケ用の音楽情報や画像情報その他各種データを記憶しているハードディスク１３、そのハードディスク１３に記憶された画像情報に基づいて歌詞や背景画を再生するための映像再生装置２４、画像情報である背景画及び歌詞等を表示する表示装置２６、現在の日付や日時を常にカウントしていて中央処理装置１１に通知するカレンダクロック２７を備えている。この内、操作パネル１０、ハードディスク１３、ＲＡＭ１５、音源再生装置１８、映像再生装置２４及びカレンダクロック２７は、ＣＰＵ１４に接続されている。
【００３５】
上述した通信装置１９は、信号の変調および復調を行う変復調装置であり、ＣＰＵ１４の制御の下、通信ネットワーク３を通じてホストコンピュータ２にアクセス可能に構成されている。それによって、通信装置１９は、通信ネットワーク３を介してホストコンピュータ２から送られてくる楽曲データ等を受信したり、上記関連情報をホストコンピュータ２に伝送することができる。
【００３６】
また、操作パネル１０は、利用者によって操作されるものであり、図１（ｂ）に示すように、任意の曲の選曲番号を入力するためのテンキーパネル１０ａ、演奏音のピッチ（演奏キーとも称される）の調整及び表示を行うためのピッチパネル１０ｂ、例えば選択された曲の選曲番号等を表示するための表示部１０ｃを備えている。
【００３７】
テンキーパネル１０ａは、「０」から「９」までの数字ボタンと、その数字ボタンを介して入力された選曲番号を確定させて演奏を実行させるための選曲ボタンを備える。
また、ピッチパネル１０ｂは、歌唱者の希望する音域に合わせた演奏をさせるための３種類のボタン、すなわちフラットボタン１０１、ナチュラルボタン１０２、シャープボタン１０３と、ピッチ表示用ＬＥＤ１０５を備える。フラット（♭）ボタン１０１はキーを下げるためのもの、シャープ（＃）ボタン１０３はキーを上げるためのものである。また、ナチュラルボタン１０２は、デフォルト状態である標準速度に戻すためのものである。この３種類のボタン１０１〜１０３がピッチ変更入力受付手段に相当する。
【００３８】
ピッチ表示用ＬＥＤ１０５は、演奏ピッチが標準ピッチ（デフォルトの状態）からどの程度変更されているかを示すためのものであり、中央には、標準ピッチを示すための他よりも少し大きな表示サイズのＬＥＤが配置され、その左右両側には、中央のＬＥＤよりも小さなＬＥＤがそれぞれ６つずつ配置されている。上述したフラットボタン１０１、シャープボタン１０３は、それぞれ１回押す毎にピッチが１度（半音：セミトーン）ずつ増減するようになっており、その操作に応じてピッチ表示用ＬＥＤ１０５の点灯部分が移動するように構成されている。具体的には、標準ピッチの場合は中央のＬＥＤが点灯しており、シャープボタン１０３を１回押せば１つ右側のＬＥＤが点灯し、さらに１回押せばさらに１つ右側のＬＥＤが点灯する。フラットボタン１０１の場合も同様に、押した回数分だけ左に位置するＬＥＤが点灯する。なお、このピッチ表示用ＬＥＤ１０５の配置からも分かるように、本実施例では、標準ピッチから最大６度の増減が可能となっている。
【００３９】
また、ハードディスク１３には、図２に示すように、アプリケーションプログラムや楽曲データなどが記憶されている。楽曲データは、ヘッダ、ＭＩＤＩデータ、歌詞データ、バックコーラスなどの肉声の波形データ等によって構成されている。波形データは、アナログのオーディオ信号をデジタル変換して作成したものであり、例えばＰＣＭ録音によって作成したＰＣＭデータやエンコードされたＡＤＰＣＭデータ、ＭＰ３データ等が該当する。ここでは「波形データ」がＭＰ３データであるとして以下の説明を進める。
【００４０】
また、ハードディスク１３には、映像データや各種の設定に必要な設定データ、さらには演奏記録などのログデータなども記憶されている。そして、操作パネル１０の操作部を介して選曲番号が入力されると、ＣＰＵ１４は、入力された選曲番号に対応する曲の楽曲データやその曲と関連する映像データをハードディスク１３から呼び出して、音源再生装置１８及び映像再生装置２４に同期させて出力するようになっている。
【００４１】
その後、ＣＰＵ１４から出力される楽曲データは、音源再生装置１８において、アナログの演奏音信号に変換された後、アンプ２０へ送られて電気的に増幅される。このアンプ２０は、マイク２３を介して入力される利用者の歌唱音信号と適度な割合でミキシングするもので、ミキシングされた歌唱音信号と演奏音信号は、アンプ２０からスピーカ２２に出力され、音声及び演奏音となってスピーカ２２から外部へ出力される。
【００４２】
ここで、音源再生装置１８について、図２を参照してさらに説明する。音源再生装置１８は、ＭＰ３用のデコーダ１８ａ、クロスフェード式ピッチ変更器１８ｂ、デジタルアナログコンバータ（ＤＡＣ）１８ｃ、ＭＰ３用のエンコーダ１８ｄ、ＦＦＴ（高速フーリエ変換）式ピッチ変更器１８ｅ、ＭＩＤＩ音源１８ｆを備えている。ＣＰＵ１４から出力される楽曲データ中のＭＩＤＩデータＤ２は、ＭＩＤＩ音源１８ｆにおいて演奏音信号に変換された後、ＤＡＣ１８ｃを介してアンプ２０へ出力される。一方、例えばバックコーラス用の波形データであるＭＰ３データは、デコーダ１８ａによってＰＣＭデータにデコードされた後、必要に応じてクロスフェード式ピッチ変更器１８ｂにてピッチ変更を行い、その後、ＤＡＣ１８ｃを介してアンプ２０へ出力される。
【００４３】
ＭＩＤＩデータを用いた楽曲演奏に際してピッチ変更（キー変更）をする場合には、標準ピッチからの変更量をＣＰＵ１４からＭＩＤＩ音源１８ｆに指示してやれば、ＭＩＤＩデータを用いてその指示されたピッチでの演奏音信号を容易に作成できる。一方、ＭＰ３データの場合は、デコーダ１８ａによってＰＣＭデータにデコードされた後、クロスフェード式ピッチ変更器１８ｂにてピッチ変更される。クロスフェード式のピッチ変更に関しては、従来技術としても示した特許文献１（特許第第３１７５１７９号公報参照）などに記載されている公知技術であるため、ここでは詳しい説明は省略する。
【００４４】
しかしクロスフェード方式のピッチ変更の場合は、周波数変換方式に比べて音質が劣化し易い。上述のように、本実施例では、標準ピッチから最大６度の増減が可能であるが、±６度のピッチ変更をクロスフェード方式で行なうと、音質劣化が相当生じてしまう。そこで、本実施例のカラオケ装置１では、次のような工夫をして音質劣化を極力防止している。
【００４５】
つまり、図３（ｃ），（ｄ）に示すように、ＭＰ３データとして、「標準ピッチ」のＭＰ３データ（図中のＭＰ３データ（±０）と表しているものが該当する。）だけでなく、標準ピッチより所定ピッチ高いＭＰ３データや標準ピッチより所定ピッチ低いＭＰ３データを含む楽曲データとして、ハードディスク１３に記憶しておくのである。そして、標準ピッチからのピッチ変更量が指定されると、そのピッチ変更量分だけ変更した後のピッチに最も近いピッチのＭＰ３データをハードディスク１３から読み出し、その読み出したＭＰ３データをデコーダ１８ａによってデコードし、クロスフェード式ピッチ変更器１８ｂによってピッチ変更するのである。
【００４６】
一例を挙げると、図３（ｃ）に示す楽曲データは、標準ピッチのＭＰ３データに加えて、標準ピッチより４度高いもの（図中のＭＰ３データ（＋４）と表しているものが該当する。）及び標準ピッチより４度低いもの（図中のＭＰ３データ（−４）と表しているものが該当する。）を含んでいる。また、図３（ｄ）に示す楽曲データは、標準ピッチのＭＰ３データに加えて、１〜６度高いもの及び１〜６度低いものの計１３個のＭＰ３データを含んでいる。例えばこの場合の曲ヘッダには、図３（ｅ）に示すように、曲番号に加え、各ＭＰ３データの先頭ビットまでのオフセット量及びデータサイズが格納されている。
【００４７】
但し、本実施例の場合は、通信ネットワーク３を介してホストコンピュータ２からカラオケ装置１に送られてくる時点での楽曲データ中には、図３（ｂ）に示すように、ＭＰ３データとしては標準ピッチのＭＰ３データしか存在しない。この標準ピッチのＭＰ３データを用いて他のピッチ変更されたＭＰ３データをカラオケ装置１内で作成するのである。もちろん、図３（ａ）に示すように、ＭＰ３データ自体が存在しない楽曲データも当然存在する。バックコーラス等のようにＭＩＤＩデータでは対応するのが難しい楽音データについてＭＰ３データとして持つため、元々バックコーラス等がない楽曲データであれば、このＭＰ３データ自体が存在しなくてもよいからである。
【００４８】
そして、標準ピッチのＭＰ３データを用いて他のピッチ変更されたＭＰ３データをカラオケ装置１内で作成する場合、次のようにする。
［楽曲データ受信時の処理］
ホストコンピュータ２から配信された楽曲データを受信した場合、バックコーラス付きの全ての楽曲は、図４（ａ）に示すように、配信ヘッダ・曲ヘッダ・ＭＩＤＩデータ・歌詞データに加え、標準ピッチのＭＰ３データ（±０）のみ持っている。この楽曲データを受信したカラオケ装置１は、図４（ｂ）に示す配信ヘッダ中にあるＭＰ３キー変更データ付加パターンを取得する。なお、配信ヘッダには、このＭＰ３キー変更データ付加パターンに加え、曲番号、ＭＰ３データ有無、その他配信に必要なヘッダデータが含まれている。
【００４９】
カラオケ装置１は、ハードディスク１４内に、図５に示すようなパターンテーブルを持っている。図５に示すパターンテーブルは、パターン１〜６に対応して、どのようなキー高さのＭＰ３データを持たせるかを決めるためのものであり、本実施例では、パターン１の場合には、標準ピッチ（±０）のみ、パターン２〜６は、それぞれ標準ピッチ（±０）以外に２個、４個、６個、８個、１２個のピッチ変更されたＭＰ３データを持つこととする。パターン２では標準ピッチから４度高いものと４度低いもの、パターン３では標準ピッチから３度及び６度高いものと３度及び６度低いもの、パターン４では標準ピッチから２度、４度及び６度高いものと２度、４度及び６度低いもの、パターン５では標準ピッチから１度、２度、４度及び５度高いものと１度、２度、４度及び５度低いもの、そしてパターン６は６度高いものから６度低いものまで全てのキー高さのものを持つ。
【００５０】
そして、カラオケ装置１では、配信ヘッダ（図４（ｂ）参照）から読み取ったパターンと突き合わせて付加すべきキー高さを決定する。そして、決定したキー高さに従って標準ピッチのＭＰ３データ（±０）をデコーダ１８ａによってデコードしてからＦＦＴ式ピッチ変更器１８ｅによってピッチ変更し、さらにエンコーダ１８ｄによって符号化（ＭＰ３データ化）した上で、楽曲データに付加する。その際、楽曲ヘッダ内容も修正を加える。このようにして作成されたのが、例えば図３（ｃ），（ｄ）に示すような標準ピッチ以外のＭＰ３データも含む楽曲データである。
【００５１】
なお、このように配信ヘッダ中にあるＭＰ３キー変更データ付加パターンに基づいて、いわばデフォルト状態のＭＰ３データの個数（種別）が決定されるのであるが、このパターンをどのように決めるかは、例えば楽曲データの配信事業者側において、例えば経験則等によって演奏頻度の高低を推測し、演奏頻度が高そうであればピッチ変更したＭＰ３データを多く持たせるよう、図５で言えばパターン４，５，６といったものを設定し、演奏頻度が低そうであれば、ピッチ変更した波形データを少なく（零の場合、つまりピッチ変更したＭＰ３データを持たない場合も含む。）持たせるよう、図５で言えばパターン１，２，３といったものを設定すればよい。
【００５２】
［受信後の処理］
上述のようにして、楽曲データの受信時にはパターンに応じてピッチ変更されたＭＰ３データが生成され、デフォルト状態が定まる。その後は、実際の演奏頻度に応じて、ＭＰ３データを削除したり、あるいはさらにピッチ変更したＭＰ３データを作成したりする。本実施例では、楽曲データをハードディスク１３に記憶してからの経過日数とその経過日数内における累積演奏回数の関係に基づいて、その楽曲に適したパターンを決定し、現在のパターンから変更していれば、その変更内容に応じてＭＰ３データを削除したり作成したりする。
【００５３】
このパターン変更を判定するための数式を、以下のように定めている。
パターン１：演奏回数≦日数×０．５
パターン２：演奏回数≦日数×１
パターン３：演奏回数≦日数×２
パターン４：演奏回数≦日数×４
パターン５：演奏回数≦日数×８
パターン６：演奏回数＞日数×８
これらを図式化して示したのが図６である。図６はｘ軸を（経過）日数、ｙ軸を（累積）演奏回数として、パターン間の境界を実線で示してある。この実線は、パターン１，２間の境界についてはｙ＝（１／２）ｘ、パターン２，３間の境界についてはｙ＝ｘ、パターン３，４間の境界についてはｙ＝２ｘ、パターン４，５間の境界についてはｙ＝４ｘ、パターン５，６間の境界についてはｙ＝８ｘという一次関数で規定してある。
【００５４】
このようなパターン変更の境界を規定するための判定式については種々考えられるが、本実施例では、上述のように一次関数を用い、さらに増加時の境界を決めるための一次関数と減少時の境界を決めるための一次関数の係数を同一としてあるため、簡易な判定が可能となる。
【００５５】
なお、このように増加時と減少時とで同じ判定式を用いてはいるが、本実施例では、その判定頻度を変えてある。具体的には、図７に示す演奏実績テーブルにおいて、各楽曲について、２日分の演奏回数と３０日分の演奏回数をそれぞれ記憶するようになっている。そして、データが増える方向のパターン変更は２日分の演奏回数を用い、つまり２日に１回行い、データが減る方向のパターン変更は３０日分の演奏回数を用い、つまり３０日に１回行うようにしている。
【００５６】
減少方向のパターン変更が３０日間隔（つまりおよそ１月に１回）なのは、例えばこの間隔を短くすると、１日毎のリクエストのバラツキによって図６の境界線上を行ったり来たりしてパターン変更が頻繁に行われると、ＭＰ３データの削除・作成が頻繁に発生し、処理負荷が増大すると共に、ハードディスク１３への過度の書き込みが発生するため、それを防止するためである。
【００５７】
一方、増加方向のパターン変更が２日１回なのは、何等かの理由で急にリクエストが増えた場合に対応するためである。このケースでは一過性の人気であることが多く、例えば３０日に１回程度では遅過ぎ、有効な対応ができない可能性がある。もちろん、リクエストのバラツキによって実勢より多目に増加方向へのパターン変更をしてしまう可能性もあるが、これについては、３０日に１回の削除方向のパターン変更の判断によって適性値に戻ることができる。
【００５８】
［具体的処理内容の説明］
以上、配信時の処理及び配信後の処理の概要を説明したが、次に、これらの処理の具体的内容について、図８〜図１２のフローチャート、図１３〜図１６の演奏実績テーブル（の変化）等を参照して説明する。
【００５９】
［楽曲データ受信時の動作］
図８は楽曲データ受信時の動作を示すフローチャートである。
まず、予め定められた受信時刻になったか否かを判断し（Ｓ１）、受信時刻になったら（Ｓ１：Ｙｅｓ）、通信装置１９（及び通信ネットワーク３）を介してホストコンピュータ２に接続する（Ｓ２）。そして、ホストコンピュータ２から通信ネットワーク３を介して配信されてくる楽曲データを通信装置１９を介して受信し、その受信した楽曲データをハードディスク１３上の一時保管場所に１曲分受信する（Ｓ３）。これを全曲受信するまで繰り返し、全曲受信したら（Ｓ４：Ｙｅｓ）、ピッチ変更ＭＰ３データの作成処理を実行する（Ｓ５）。これを、全曲作成するまで繰り返し、全曲作成したら（Ｓ６：Ｙｅｓ）、本処理を終了する。
【００６０】
それでは、図８のＳ５にて実行されるピッチ変更ＭＰ３データの作成処理について図９を参照して説明する。
最初のステップＳ５１では、配信ヘッダ中のＭＰ３データ有無のチェックをする。そして、ＭＰ３データが有る場合には、配信ヘッダよりＭＰ３キー変更データ付加パターンを取得する（Ｓ５２）。そして、それがパターン１か否かを判断する。パターン１でない場合には（Ｓ５３：Ｎｏ）、パターン番号を基にして、図５に示したパターンテーブルから、付加すべきキー高さを取得する（Ｓ５４）。そして、配信された楽曲データ中の、標準ピッチ（±０）のＭＰ３データをデコーダ１８ａによってデコードして、標準ピッチ（±０）のＰＣＭデータを作成する（Ｓ５５）。
【００６１】
そして、この標準ピッチ（±０）のＰＣＭデータを元にして、付加すべきキー高さのＰＣＭデータを、ＦＦＴ式ピッチ変更器１８ｅを用いて全て作成する（Ｓ５６）。その作成した標準ピッチ（±０）以外のＰＣＭデータをエンコーダ１８ｄによって符号化（ＭＰ３データ化）し（Ｓ５７）、その作成したＭＰ３データを楽曲データに付加する（Ｓ５８）。そして、作成したＭＰ３データの数に合わせて楽曲データの曲ヘッダ（図３参照）を修正する（Ｓ５９）。
【００６２】
その後、演奏実績テーブルの該当する曲番号テーブルを修正する（Ｓ６０）。具体的には、図１３に示すように、例えば曲番号１２３４６の楽曲データについて上述のようなＭＰ３データの作成等の処理を実行した場合には、図１３（ａ）から（ｂ）への変化からも分かるように、楽曲データの有無を「無」から「有」に変化させ、２日分演奏回数及び３０日分演奏回数を共に初期値−２とする。
【００６３】
そして、配信ヘッダを削除して楽曲データをハードディスク１３の正しい場所に配置し（Ｓ６１）、本処理を終了する。
一方、パターン１である場合には（Ｓ５３：Ｙｅｓ）、図５に示したパターンテーブルからも分かるように、標準ピッチのＭＰ３データのみ持てばよいため、ピッチ変更されたＭＰ３データを作成する必要がない。したがって、Ｓ５４〜Ｓ５９の処理を実行することなくＳ６０へ移行する。
【００６４】
［楽曲データ演奏時の動作］
図１０は楽曲データ演奏時の動作を示すフローチャートである。
まず、曲番号の予約受付が完了したか否か判断し（Ｓ１１０）、選曲ボタンが操作されて受付完了の場合は（Ｓ１１０：Ｙｅｓ）、その受け付けた曲番号に対応する楽曲データをハードディスク１３からＲＡＭ１５に転送する（Ｓ１２０）。そして、次のステップＳ１３０では、歌詞と演奏を同期再生する。具体的には、ＲＡＭ１５に転送した楽曲データ内のＭＩＤＩデータを音源再生装置１８（図１参照）内のＭＩＤＩ音源１８ｆ（図２参照）に送る。それと共に、ＭＰ３データを持つ楽曲データの場合には、標準ピッチのＭＰ３データを音源再生装置１８内のデコーダ１８ａ（図２参照）に送る。当然ながら、図３（ａ）に示すように波ＭＰ３データ自体を持たない楽曲データの場合は、デコーダ１８ａへ送ることはない。ＭＩＤＩデータはＭＩＤＩ音源１８ｆにおいて演奏音信号に変換された後、ＤＡＣ１８ｃを介してアンプ２０へ出力される。一方、デコーダ１８ａにてデコードされて生成された標準ピッチのＰＣＭデータはクロスフェード式ピッチ変更器１８ｂを介し、さらにＤＡＣ１８ｃを介してアンプ２０へ出力される。このような演奏処理を一曲終了するまで繰り返す。
【００６５】
なお、演奏途中でピッチ変更操作がされた場合には、その操作に応じたピッチ変更処理を実行する。つまり、フラットボタン１０１、ナチュラルボタン１０２、シャープボタン１０３のいずれかが操作された場合には、その操作に応じて「現在の演奏ピッチ値」を増減させる。この「現在の演奏ピッチ値」は、標準ピッチに対する差を度数（セミトーン数）で示すものであり、初期値は０である。そして、フラットボタン１０１が１回操作されれば１減り、シャープボタン１０３が１回操作されれば１増える。また、ナチュラルボタン１０２が操作された場合は、直前の操作がフラットボタン１０１によるものであればその反対の操作による動作としてピッチ値を１増やし、直前の操作がシャープボタン１０３によるものであればその反対の操作による動作としてピッチ値を１減らす。この「現在の演奏ピッチ値」は、ＲＡＭ１５にセット（記憶）される。そして、ＭＩＤＩ演奏を、そのセット（記憶）された現在の演奏ピッチ値に応じたものに変更する。ＭＩＤＩ音源１８ｆを用いたＭＩＤＩ演奏における演奏ピッチの変更は、ＭＩＤＩデータＤ２のパラメータの変更のみで簡単に対応できる。一方、ＭＰ３データの方は、現在の演奏ピッチ値に対応するＭＰ３データを選択し、そのＭＰ３データをデコードして生成したＰＣＭデータを必要に応じてさらにピッチ変更する。なお、現在の演奏ピッチ値に対応するＭＰ３データとは、その演奏ピッチに最も近いピッチのＭＰ３データである。具体的には、その楽曲データがどのパターンのＭＰ３データを有しているかによる。例えば図５のパターンテーブルに示すパターン６のように−６度から＋６度までの全てのピッチ（キー高さ）のＭＰ３データを有している楽曲データであれば、該当するピッチそのもののＭＰ３データを選択すればよく、その場合は、さらなるピッチ変更は不要である。また、例えばパターン２のように標準ピッチ以外には−４度及び＋４度のピッチのＭＰ３データしか有さない場合には、例えば−３度のピッチ変更が指示された場合には、−４度のピッチのＭＰ３データを用い、さらに１度上げるピッチ変更して演奏に用いることとなる。
【００６６】
そして、演奏処理が一曲終了すると（Ｓ１４０：Ｙｅｓ）、演奏実績テーブルの該当する曲番号の演奏実績が０以上か否かを判断し（Ｓ１５０）、演奏実績が０以上であれば（Ｓ１５０：Ｙｅｓ）、演奏実績テーブルの該当する曲番号の演奏実績を２日用・３０日用ともにインクリメント（＋１）してから（Ｓ１６０）、本処理を終了する。一方、演奏実績が０未満であれば（Ｓ１５０：Ｎｏ）、そのまま本処理を終了する。具体的には、図１４に示すように、例えば曲番号１２３４５の楽曲データについて上述のような演奏が終了した場合には、図１３（ａ）から（ｂ）への変化からも分かるように、２日分演奏回数及び３０日分演奏回数が共に０から１にインクリメント（＋１）されている。一方、例えば曲番号１２３４６の演奏回数は図１４（ａ）からも分かるように−２であったため、たとえこの曲について演奏が終了しても、図１０のＳ１５０にて否定判断されるため、演奏回数はインクリメントせず、−２のままとなる。
【００６７】
［ＭＰ３データ増加判定時の動作］
図１１は２日毎に行われるＭＰ３データの増加判定時の動作を示すフローチャートである。
まず、前回の判定時から２日経過したか否か判断し（Ｓ２１０）、２日経過していれば（Ｓ２１０：Ｙｅｓ）、判定対象を曲番号１に設定する（Ｓ２２０）。そして、演奏実績テーブルから該当曲の２日分演奏回数を取得し（Ｓ２３０）、その演奏回数の値が０以上か否かを判断する（Ｓ２４０）。そして、演奏回数が０以上であれば（Ｓ２４０：Ｙｅｓ）、パターン割り出し用の数式と演奏回数を照合してパターン番号を取得する（Ｓ２５０）。この数式に関しては既に説明したのでここでは繰り返さない。
【００６８】
その後、図１５に示すように、演奏実績テーブルの２日分欄を０にし（Ｓ２６０）、Ｓ２５０で取得したパターンより保持すべきキー高さを取得する（Ｓ２７０）。そして、ハードディスク１３上の該当楽曲データの曲ヘッダより該当楽曲データの持つＭＰ３データのキー高さを取得し（Ｓ２８０）、Ｓ２７０にて取得した保持すべきキー高さの数が実際に楽曲データが現在保持しているキー高さの数より多いか否かを判断する（Ｓ２９０）。
【００６９】
保持すべきキー高さの数が実際に楽曲データが現在保持しているキー高さの数よりも多い場合には（Ｓ２９０：Ｙｅｓ）、新たにＭＰ３データを作成する必要（及び場合によってはＭＰ３データを削除する必要）があるため、Ｓ３００〜Ｓ３５０の処理を実行する。
【００７０】
まず、Ｓ３００では、対象楽曲データ中の、標準ピッチ（±０）のＭＰ３データをデコーダ１８ａによってデコードし、標準ピッチ（±０）のＰＣＭデータを作成する。次に、標準ピッチのＰＣＭデータを元に保持すべきであり、且つ現時点で保持していないキー高さのＰＣＭデータを、ＦＦＴ式ピッチ変更器１８ｅを用いて全て作成する（Ｓ３１０）。その作成した標準ピッチ（±０）以外のＰＣＭデータをエンコーダ１８ｄによって符号化してＭＰ３データを作成し（Ｓ３２０）、その作成したＭＰ３データを楽曲データに付加する（Ｓ３３０）。次に、保持すべきでないキー高さのＭＰ３データを楽曲データから削除する（Ｓ３４０）。そして、作成したＭＰ３データの数に合わせて楽曲データの曲ヘッダ（図３参照）を修正する（Ｓ３５０）。例えば図５のパターンテーブルにおけるパターン３のＭＰ３データを保持している状態で、Ｓ２５０によってパターン４が取得されたとする。この場合、パターン４には存在しパターン３には存在しないものとして、標準ピッチから−２度、−４度、＋２度、＋４度ピッチ変更されたＭＰ３データがあるため、Ｓ３１０〜Ｓ３３０ではこれを作成し楽曲データに付加する。一方、パターン３では標準ピッチから−３度、＋３度ピッチ変更されたＭＰ３データが存在するが、パターン４ではこれらは存在しないので、Ｓ３４０ではこのキー高さのＭＰ３データを楽曲データから削除することとなる。
【００７１】
Ｓ３５０の処理後は、Ｓ３６０へ移行して全曲終了したか否か判断する。全曲終了していなければ（Ｓ３６０：Ｎｏ）、判定対象を次の曲番号に設定して（Ｓ３７０）Ｓ２３０へ移行し、全曲終了していれば（Ｓ３６０：Ｙｅｓ）、本処理を終了する。
【００７２】
一方、保持すべきキー高さの数が実際に楽曲データが現在保持しているキー高さの数以下の場合には（Ｓ２９０：Ｎｏ）、新たにＭＰ３データを作成する必要がないため、Ｓ３００〜Ｓ３５０の処理を実行せずにそのままＳ３６０へ移行する。
【００７３】
また、演奏回数が０未満の場合（Ｓ２４０：Ｎｏ）も、そのままＳ３６０へ移行する。つまり、実質的にＭＰ３データの増加の必要性自体を判断しない。したがって、図１５の演奏実績テーブルに示すように、曲番号１２３４６については、２日分欄の−２がそのまま維持されることとなる。
【００７４】
［ＭＰ３データ減少判定時の動作］
図１２は３０日毎に行われるＭＰ３データの減少判定時の動作を示すフローチャートである。
まず、前回の判定時から３０日経過したか否か判断し（Ｓ４１０）、３０日経過していれば（Ｓ４１０：Ｙｅｓ）、判定対象を曲番号１に設定する（Ｓ４２０）。そして、演奏実績テーブルから該当曲の３０日分演奏回数を取得し（Ｓ４３０）、その演奏回数の値が０以上か否かを判断する（Ｓ４４０）。そして、演奏回数が０以上であれば（Ｓ４４０：Ｙｅｓ）、パターン割り出し用の数式と演奏回数を照合してパターン番号を取得する（Ｓ４５０）。この数式に関しては既に説明したのでここでは繰り返さない。
【００７５】
その後、図１６に示すように、演奏実績テーブルの３０日分欄を０にし（Ｓ４６０）、Ｓ４５０で取得したパターンより保持すべきキー高さを取得する（Ｓ４７０）。そして、ハードディスク１３上の該当楽曲データの曲ヘッダより該当楽曲データの持つＭＰ３データのキー高さを取得し（Ｓ４８０）、Ｓ４７０にて取得した保持すべきキー高さの数が実際に楽曲データが現在保持しているキー高さの数より少ないか否かを判断する（Ｓ４９０）。
【００７６】
保持すべきキー高さの数が実際に楽曲データが現在保持しているキー高さの数よりも少ない場合には（Ｓ４９０：Ｙｅｓ）、ＭＰ３データデータを削除する必要（及び場合によっては新たにＭＰ３データを作成する必要）があるため、Ｓ５００〜Ｓ５５０の処理を実行する。
【００７７】
まず、Ｓ５００では、対象楽曲データ中の、標準ピッチ（±０）のＭＰ３データをデコーダ１８ａによってデコードし、標準ピッチ（±０）のＰＣＭデータを作成する。次に、標準ピッチのＰＣＭデータを元に保持すべきであり、且つ現時点で保持していないキー高さのＰＣＭデータを、ＦＦＴ式ピッチ変更器１８ｅを用いて全て作成する（Ｓ５１０）。その作成した標準ピッチ（±０）以外のＰＣＭデータをエンコーダ１８ｄによって符号化してＭＰ３データを作成し（Ｓ５２０）、その作成したＭＰ３データを楽曲データに付加する（Ｓ５３０）。次に、保持すべきでないキー高さのＭＰ３データを楽曲データから削除する（Ｓ５４０）。そして、作成したＭＰ３データの数に合わせて楽曲データの曲ヘッダ（図３参照）を修正する（Ｓ５５０）。例えば図５のパターンテーブルにおけるパターン３のＭＰ３データを保持している状態で、Ｓ４５０によってパターン２が取得されたとする。この場合、パターン２には存在しパターン３には存在しないものとして、標準ピッチから−２度、＋２度ピッチ変更されたＭＰ３データがあるため、Ｓ５１０〜Ｓ５３０ではこれを作成し楽曲データに付加する。一方、パターン３では標準ピッチから−６度、−３度、＋３度、＋６度ピッチ変更されたＭＰ３データが存在するが、パターン４ではこれらは存在しないので、Ｓ５４０ではこのキー高さのＭＰ３データを楽曲データから削除することとなる。
【００７８】
Ｓ５５０の処理後は、Ｓ５６０へ移行して全曲終了したか否か判断する。全曲終了していなければ（Ｓ５６０：Ｎｏ）、判定対象を次の曲番号に設定して（Ｓ５７０）Ｓ４３０へ移行し、全曲終了していれば（Ｓ５６０：Ｙｅｓ）、本処理を終了する。
【００７９】
一方、保持すべきキー高さの数が実際に楽曲データが現在保持しているキー高さの数以下の場合には（Ｓ４９０：Ｎｏ）、ＭＰ３データを削除する必要がないため、Ｓ５００〜Ｓ５５０の処理を実行せずにそのままＳ５６０へ移行する。
また、演奏回数が０未満の場合には（Ｓ４４０：Ｎｏ）、Ｓ５８０へ移行し、演奏実績テーブルの２日分演奏回数の値及び３０日分演奏回数の値を共にインクリメント（＋１）してから（Ｓ５８０）、Ｓ５６０へ移行する。つまり、実質的にＭＰ３データの削除のの必要性自体を判断しない。しかし、上述のようにＭＰ３データの増加判定時に、は図１５を参照して説明したように２日分演奏回数の値自体を全く変化させなかったが、ここでは２日分演奏回数及び３０日分演奏回数の値を共に＋１している。したがって、図１６の演奏実績テーブルに示すように、曲番号１２３４６については、２日分演奏回数欄及び３０日分演奏回数欄の値が（ａ）の場合の−２から（ｂ）の場合の−１にインクリメントされている。
【００８０】
なお、このようなＳ５８０の処理が２回実行されると２日分演奏回数欄及び３０日分演奏回数欄の値が共に０となるため、図１０のＳ１５０にて肯定判断となり、Ｓ１６０において２日分演奏回数欄及び３０日分演奏回数欄の値が共にインクリメントされる。そして、その場合は図１１のＳ２４０においても、図１２のＳ４４０においても共に肯定判断となり、実質的に増加判定、減少判定が実行されることとなる。
【００８１】
なお、本実施例においては、ハードディスク１３が「波形データ記憶手段」及び「楽曲演奏情報記憶手段」に相当し、ＣＰＵ１４及び音源再生装置１８が「波形データ再生手段」、「第１のピッチ変更手段」、「第２のピッチ変更手段」、「符号化手段」、「楽曲演奏手段」及び「記憶制御手段」に相当する。また、操作パネル１０が「ピッチ変更入力受付手段」に相当し、通信装置１９が「通信手段」に相当する。
【００８２】
［本実施例の効果］
（イ）図３（ｃ），（ｄ）に示すように、標準ピッチのＭＰ３データ以外にも、標準ピッチからピッチ変更されたＭＰ３データを楽曲データが持つことができるため、現在の演奏ピッチに対応して最も近い波形データが選択され、その選択された波形データを用いて、必要ならばさらにクロスフェード式ピッチ変更器１８ｂによってピッチ変更する。したがって、標準ピッチから±６度の範囲内でのピッチ変更に対して、いずれの場合も最大２度分のピッチ変更で対応できる。そのため、従来のように常に標準ピッチの波形データを用いてピッチ変更処理を実行する場合には３度以上のピッチ変更が必要であったケースであっても、２度以内のピッチ変更で済む。そのため、クロスフェード方式のピッチ変更処理を実行した場合の音質劣化を抑制でき、カラオケ演奏時に音質劣化の少ないバックコーラスを実現できる。
【００８３】
なお、ピッチ変更に際してクロスフェード方式ではなくＦＦＴ等の周波数変換方式を用いれば相対的に音質劣化は少ない。しかし、その一方で計算量がクロスフェード方式と比べて多いため、リアルタイム処理のためには処理負荷が相当大きくなる。したがって、処理負荷低減の観点からクロスフェード方式が有効であるが、従来のような最大６度のピッチ変更では音質劣化が問題となる。しかし、上述のように本実施例の場合は最大でも２度のピッチ変更で対応できるため、音質劣化の問題が小さくなり、その分クロスフェード式のピッチ変更を用いる場合の処理負荷の低減というメリットが生かされるのである。
【００８４】
（ロ）図８、図９等を参照して説明したように、本実施例の場合には、楽曲データがＭＰ３データを持つ場合であっても、ホストコンピュータ２からの配信時には、標準ピッチのＭＰ３データのみ含まれた楽曲データが配信される。そして、カラオケ装置１では、受信後に、配信ヘッダ中に含まれるＭＰ３キー変更データ付加パターン（図４（ｂ）参照）に基づいて、標準ピッチ以外のＭＰ３データを作成して楽曲データに付加する。
【００８５】
具体的には、通信カラオケシステムにおいて、カラオケ装置１へ新曲を配信する際、配信事業者側で例えば経験則等によって演奏頻度の高低を推測し、演奏頻度が高そうであればピッチ変更した波形データを多く持たせるよう、また、演奏頻度が低そうであれば、ピッチ変更したＭＰ３データを少なく（零の場合、つまりピッチ変更した波形データを持たない場合も含む。）持たせるよう、ＭＰ３キー変更データ付加パターンを設定すればよい。そして、この推測が妥当であれば、実際にＭＰ３データを用いた楽曲演奏時において、大きなピッチ変更を強いられる場面も少なくなり、且つ、ほとんど使用せずに無用のＭＰ３データを作成したり、そのようなＭＰ３データがハードディスク１３内に居座るようなこともない。
【００８６】
（ハ）図１０〜図１３を参照して説明したように、本実施例では、実際の演奏頻度に応じても適切な対応をしている。つまり、楽曲毎に、演奏頻度に応じて持つべきＭＰ３データを現在持っているか否かを判断し、ＭＰ３データが不足する場合には当該不足するＭＰ３データを作成してハードディスク１３に記憶し、一方、ＭＰ３データが過剰な場合には、当該過剰なＭＰ３データをハードディスク１３から削除させる。このようにすることで、演奏回数が多い場合には相対的に多くの種類のＭＰ３データを持たせ、逆に、演奏回数が少ない場合には相対的に少ない種類のＭＰ３データを持たせるようにすることができる。
【００８７】
なお、本実施例では、２日間毎の演奏回数に応じてＭＰ３データ数を増加させるか否かの判断を行い（図１１参照）、３０日間毎の演奏回数に応じてＭＰ３データ数を減少させるか否かの判断を行う（図１２参照）。このようにすればＭＰ３データの作成記憶や削除が頻繁に起こりすぎるのを防ぐことができる。そして、ＭＰ３データの作成に関しては、実際の演奏回数に対してのレスポンスが低いと不適切であるため、短めが好ましいが、逆に削除時には余分に存在してもデータ量の増加という点以外のデメリットはない。そこで、本実施例では３０日という相対的に長めの期間とした。
【００８８】
（ニ）また、本実施例の場合には、演奏実績テーブル（図７、図１３〜１６参照）の２日分演奏回数欄及び３０日分演奏回数欄のデフォルト値を−２とし、この値が０以上にならないと演奏回数のインクリメント（図１０のＳ１６０）を実行せず、また、図１１での増加判定や図１２の減少判定を実質的に実行しないようにした。そして、この２日分演奏回数欄及び３０日分演奏回数欄は、図１２に示すＳ５８０にてインクリメントされるため、Ｓ５８０の処理が２回実行、つまり３０日間×２＝６０日間経過すると、これら２日分演奏回数欄及び３０日分演奏回数欄の値が共に０となる。そのため、図１０のＳ１５０にて肯定判断となり、Ｓ１６０において２日分演奏回数欄及び３０日分演奏回数欄の値が共にインクリメントされ、その場合は図１１のＳ２４０においても、図１２のＳ４４０においても共に肯定判断となり、実質的に増加判定、減少判定が実行されることとなる。
【００８９】
つまり、楽曲データの配信を受けてから６０日間はＭＰ３データの増減自体を行わないということである。本実施例では、楽曲データの受信時処理として、当該楽曲データにふさわしいと思われる種類のＭＰ３データが作成されて記憶される。これは、上述したように、楽曲データの配信事業者側の経験則等を反映させて適切と思われるデフォルト状態を実現させたものである。新曲を追加し、その新曲の人気を想定してデフォルト状態にした場合、結果的にみればその曲が予想通りの演奏頻度となったとしても、新曲追加当初は、演奏回数が相対的に少なくなるのが普通である。ある程度の期間を経て予想通りの演奏回数となるにしても、初期段階では演奏回数が少ないことが考えられる。そのような場合に、図１１、図１２にて説明した演奏回数に応じたＭＰ３データの増加判定や減少判定を実質的に適用してしまうと、デフォルト状態のＭＰ３データを一旦削除し、その後再度作成することとなってしまう。そこで、デフォルト状態はある程度適切なものと考え、所定期間（ここでは６０日間）は様子を見るようにしたのである。
【００９０】
なお、本実施例で採用した増加判定のための２日間、減少判定のための３０日間はあくまで一例であり、そのような数値に何ら限定されることはない。例えばそれぞれ半分でもよいし、倍でもよい。また、２日と１０日、７日と３０日、７日と１５日、といった具合に種々考えられる。
【００９１】
また、デフォルト状態を維持するための６０日間についても、そのような数値に何ら限定されることはない。そして、この期間を楽曲データ個々に持つようにしてもいい。例えば配信ヘッダ中にパラメータデータとして別に持ち、配信時にホストコンピュータ２側で種々変えられるようにしてもいい。
【００９２】
また、例えばこの最初の６０日間において、ＭＰ３データの増加につながる処理は実行してもよいが、減少につながる処理は実行しないようにしてもよい。上述のように、実際にはあまり利用頻度のない楽曲データに対して余分と考えられるＭＰ３データが存在したとしても、データ量の増加という点以外のデメリットはないからである。
【００９３】
（ホ）楽曲データに関しては、例えばＣＤ−ＲＯＭやＤＶＤ−ＲＯＭのようなパッケージメディアから読み込んでもよい。但し、上記実施例のようにホストコンピュータ２から配信してもらう、いわゆる通信カラオケシステムの方が、当然ながらレスポンスがよくなる。そして、このようなホストコンピュータ２から各カラオケ装置１へ配信する形式の場合には、配信時の楽曲データには（ＭＰ３データが存在する場合であっても）標準ピッチのＭＰ３データしか存在しないため、データ量の増加を招来しない点で好ましい。
【００９４】
［その他］
（ａ）上記実施例ではＭＰ３データを例に挙げたが、波形データの形式としては、それ以外にも、ＡＤＰＣＭ、Ｍｐｅｇ２オーディオＡＡＣ、ＴｗｉｎＶＱ、ＡＴＲＡＣ３などであってもよい。
【００９５】
（ｂ）カラオケ装置１とホストコンピュータ２との間でデータを配信する伝送手段としての通信ネットワーク３は、公衆電話回線網が代表的なものとして考えられるが、それ以外にＩＳＤＮ回線網でもいいし、何等かの一般的な方法を用いて接続したインターネット網でもいい。
【００９６】
（ｃ）ＭＰ３データの増減判定のための数式の係数が、パターン１〜パターン６に行くにつれて、０．５→１→２→４→８というように倍々（つまり、２倍、４倍、８倍、１６倍）になっているが、例えば０．５→１→１．５→２→２．５というように等倍（つまり、２倍、３倍、４倍、５倍）でもいい。
【００９７】
（ｄ）上記実施例では、楽曲演奏の集な計を全曲一まとめにした演奏実績テーブルとして記憶するようにしたが、例えば楽曲データに直接演奏実績を持たせてもよい。また、演奏実績テーブルに関して言えば、上記実施例では未配信データのテーブルも最初から存在しているが、未受信時には存在しなくてもいい。
【００９８】
（ｅ）図７等に示す演奏実績データは、楽曲データの有無及び２日分・３０日分の演奏回数の集計データを兼用して記憶するようにしているが、別のデータとして保持してもいい。
（ｆ）上記実施例では、楽曲データの受信時にデフォルト状態のＭＰ３データを作成するようにしているが、これは受信直後以外でもいい。具体的には、時間をおいてＣＰＵ１４の動作に余裕があるタイミングで実行すればよい。
【００９９】
（ｇ）上記実施例では、ＭＰ３キー変更データ付加パターンを楽曲データに対応した配信ヘッダ中に含めておいたが、別途曲番号とＭＰ３キー変更データ付加パターンとの対応関係を示すテーブル形式のデータを配信してもらい、そのテーブルに基づいて同様の処理を実行してもよい。また、配信ヘッダ中に、ＭＰ３キー変更データ付加パターンに代えてＭＰ３データを作成すべきピッチ値を直接記憶させてもよい。
【０１００】
（ｈ）上記実施例ではカラオケ装置１の本体に設けられた操作パネル１０の操作部によってピッチ変更操作（や選曲番号）を入力するようにしたが、例えば赤外線信号やＢｌｕｅｔｏｏｔｈ規格に基づく無線通信によって接続されたリモコンなどに上記操作ボタンを準備し、その操作に基づくピッチ変更データ（や選曲データ）をカラオケ装置本体側へ送信するような構成であってもよい。
【０１０１】
（ｉ）上記実施例では、カラオケ装置１として実現した場合について説明したが、その他の情報処理装置であっても適用できる。
【図面の簡単な説明】
【図１】（ａ）は実施例のカラオケ装置の概略構成を示すブロック図、（ｂ）は操作パネルの外観図である。
【図２】実施例のカラオケ装置における音源再生装置等の詳細を示すブロック図である。
【図３】実施例のハードディスク内に格納される楽曲データの説明図である。
【図４】実施例の配信用楽曲データの説明図である。
【図５】ＭＰ３データのパターンテーブルの説明図である。
【図６】実施例のＭＰ３データ増減判定式を図式化した説明図である。
【図７】実施例の楽曲データの演奏実績テーブルの説明図である。
【図８】実施例のカラオケ装置が実行する楽曲データ受信時の動作を示すフローチャーである。
【図９】図８中のＳ５にて実行されるピッチ変更ＭＰ３データの作成処理を示すフローチャートである。
【図１０】実施例のカラオケ装置が実行する楽曲データ演奏時の動作を示すフローチャートである。
【図１１】実施例のカラオケ装置が実行するＭＰ３データの増加判定時の動作を示すフローチャートである。
【図１２】実施例のカラオケ装置が実行するＭＰ３データの減少判定時の動作を示すフローチャートである。
【図１３】楽曲データ配信時における演奏実績テーブルの変化を示した説明図である。
【図１４】楽曲演奏時における演奏実績テーブルの変化を示した説明図である。
【図１５】ＭＰ３データ増加判定時における演奏実績テーブルの変化を示した説明図である。
【図１６】ＭＰ３データ減少判定時における演奏実績テーブルの変化を示した説明図である。
【符号の説明】
１…カラオケ装置、２…ホストコンピュータ、３…通信ネットワーク、１０…操作パネル、１０ａ…テンキーパネル、１０ｂ…ピッチパネル、１０ｃ…表示部、１３…ハードディスク、１４…ＣＰＵ、１５…ＲＡＭ、１８…音源再生装置、１８ａ…デコーダ、１８ｂ…クロスフェード式ピッチ変更器、１８ｃ…デジタルアナログコンバータ（ＤＡＣ）、１８ｄ…エンコーダ、１８ｅ…ＦＦＴ式ピッチ変更器、１８ｆ…ＭＩＤＩ音源、２０…アンプ、２２…スピーカ、２３…マイクロフォン、２４…映像再生装置、２６…表示装置、２７…カレンダクロック、１０１…フラットボタン、１０２…ナチュラルボタン、１０３…シャープボタン、１０５…ピッチ表示用ＬＥＤ。
【図１】
2004279690.tif 000003
【図２】
2004279690.tif 000004
【図３】
2004279690.tif 000005
【図４】
2004279690.tif 000006
【図５】
2004279690.tif 000007
【図６】
2004279690.tif 000008
【図７】
2004279690.tif 000009
【図８】
2004279690.tif 000010
【図９】
2004279690.tif 000011
【図１０】
2004279690.tif 000012
【図１１】
2004279690.tif 000013
【図１２】
2004279690.tif 000014
【図１３】
2004279690.tif 000015
【図１４】
2004279690.tif 000016
【図１５】
2004279690.tif 000017
【図１６】
2004279690.tif 000018