JPH09138690A - 通信カラオケ装置の楽曲データの登録・削除・設定変更方法 - Google Patents

Abstract

(57)【要約】 【課題】 記憶容量の有効利用を行なうことができる通
信カラオケ装置の楽曲データの登録・削除・設定変更方
法を提供する。 【解決手段】 配信センタ１から送られる楽曲データを
記憶する記憶手段１３と、利用者のリクエスト曲を入力
する入力手段１４と、この入力手段から入力されたリク
エスト曲に対応する楽曲データを前記記憶手段１３に記
憶される楽曲データから選択する制御手段１５と、選択
された前記楽曲を楽音として出力する出力手段とを有す
る通信カラオケ装置の楽曲データの登録・削除・設定変
更方法において、前記楽曲データは、楽曲に関するイン
デックス情報と音楽情報とを含み、前記配信センタから
の指令に応じて前記記憶手段に記憶される楽曲データを
登録・削除・設定変更する。これにより、記憶手段の記
憶容量の有効利用を図る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、通信カラオケ装置
の楽曲データの登録・削除・設定変更方法に関する。

【０００２】

【従来の技術】一般に、楽音を発生させるための演奏情
報の伝達手段としてＭＩＤＩ（Ｍｕｓｉｃａｌ Ｉｎｓ
ｔｒｕｍｅｎｔ Ｄｉｇｉｔａｌ Ｉｎｔｅｒｆａｃ
ｅ）が広く用いられている。ＭＩＤＩとは、シンセサイ
ザや電子ピアノ等の楽器等の音源と連結して情報の交換
を可能とすべく定められたハードウエアとソフトウエア
の規格をいう。ＭＩＤＩを用いる場合、演奏者の鍵盤等
への入力は、ＭＩＤＩ情報に変換され、伝送路に出力さ
れる。一方、ＭＩＤＩの受信能力を持ち、実際に発音を
行なう音源が、伝送路に接続されており、ＭＩＤＩ情報
を解釈して発音する。

【０００３】このようなＭＩＤＩ情報は大別して以下の
ような情報からなる。 （１）打鍵（鍵盤を押し込む）等による発音開始、離鍵
（鍵盤の押し込みをやめる）等による発音停止を表す音
符的な情報（以下、音符情報といる）。この音符情報に
は鍵盤番号で表される音の高さの情報が含まれている。 （２）発音の強さを表すアクセント情報。ＭＩＤＩでは
音符情報に付随して送受信される。 （３）演奏者がペダルやレバー等を用いて行なった、ク
レッシェンド、音程の揺らぎ等の抑揚表現を音源に伝え
るための制御情報。具体的には、演奏者側のＭＩＤＩ変
換器がレバー位置の変化を検知した際に、位置の情報が
送信される。これらの各情報は、演奏の進行に従って、
即時的に送信されるため、情報の流れは上記各種情報が
混合した状態となっている。

【０００４】ＭＩＤＩ情報は全てデジタル化されている
ため、シンセサイザー等のコンピュータ機器と記録媒体
を用いて記録、編集、再生が行なわれている。すなわ
ち、ＭＩＤＩ情報はデータファイルとして媒体に記録さ
れる。ここで、通常、よく用いられるファイルフォーマ
ットとしてＳＭＦ（Ｓｔａｎｄａｒｄ Ｍｉｄｉ Ｆｉ
ｌｅ）があるが、ＭＩＤＩ情報は実時間の演奏情報なの
で発音開始、発音停止等の各情報要素（以下、ＭＩＤＩ
イベントと称す）は、ＳＭＦに記録される場合、時刻情
報を付加した状態で記録されている。また、ＭＩＤＩイ
ベントの発生順にしたがって記録を行なっているため、
音符情報と制御情報は混合された形で記録されている。

【０００５】ところで、ＳＭＦに限らず、データファイ
ルを保存する場合、記録媒体の容量が限られているため
に、データファイルはできるだけデータ圧縮されている
ことが望ましいが、ＭＩＤＩ情報をデータ圧縮するには
通常、ＬＨＡやＧＺＩＰ等のプログラムで使用されるＬ
Ｚ法と称されるパターンマッチングによる圧縮手法が用
いられる。このデータ圧縮の原理を簡単に説明する。元
ファイルからの圧縮ファイルの生成は、元ファイル中の
処理位置をファイル先頭から移動させつつ、圧縮ファイ
ルに処理位置から読み出したデータをコピーすることが
行なわれる。元ファイル内に２つの同一のデータ領域が
存在した場合には、処理位置が同一データ領域の内の２
つ目のデータ領域の先頭に来た時点で、単純にデータコ
ピーを行なう代わりに、一致している１つ目のデータ領
域の先頭位置から処理位置までの距離と、一致したデー
タ領域の長さを圧縮ファイルに記録し、元ファイル内の
処理位置を２つ目のデータ領域の終わりに移動させ、処
理を続ける。これにより、２つ目の同一データ領域につ
いては、データコピーする必要がなく、それに代えて、
僅かな長さの距離情報と長さ情報を付せばよく、データ
を圧縮することができる。

【０００６】以上の説明から明らかなように、この圧縮
データは、２つの同一のデータ領域が大きいほど、圧縮
率は高くなる。また、ある処理位置以降のデータパター
ンを処理位置以前のデータ領域から検索する際に、検索
対象となる領域の大きさには制限があるために、同一の
データ領域は近接している方が圧縮率が高くなるという
特性を有する。このようなＳＭＦ等の演奏情報ファイル
を用いている事例として通信カラオケ装置が挙げられ
る。通信カラオケ装置の内、非蓄積型は、配信センタか
ら公衆回線等を通じて配信されるＭＩＤＩ演奏情報ファ
イルを端末装置が受信し、これを端末装置が再生して歌
唱の伴奏として用いるものである。これは、利用者が選
曲を行なう毎に、選曲された楽曲に関する情報をセンタ
側から配信するようになっている。このような場合、配
信センタにある演奏情報ファイルを圧縮しておき、これ
を配信すれば、配信時間が短くて済むので、回線使用料
の低減になる。

【０００７】また、蓄積型と呼ばれる通信カラオケ装置
の端末装置は、大容量のハードディスク等の記録媒体を
内蔵し、これに過去に配信のあった演奏情報ファイルを
アップデート可能に保存している。この場合も演奏情報
ファイルを圧縮された状態で保存することによって、よ
り多くの曲を記録媒体に保持することができる。

【０００８】ここで従来の通信カラオケ装置を説明する
と、図６は従来の通信カラオケ装置を示す概略構成図で
あり、配信センタ１から通信回線２を介して通信カラオ
ケ装置３にＭＩＤＩ情報、歌詞文字、コーラス等を含む
音楽情報、インデックス情報、静止画情報等が配信され
るとこの情報はハードディスク等よりなる大容量の記憶
部５に記憶される。配信は、夜間等のように通信費用の
安い時間帯を選んで行なわれる。利用者が入力部６から
リクエスト楽曲をコードで入力すると、その楽曲に対応
した楽曲データが記憶部５から出力されると共に楽曲に
対応した背景画が記憶部５或いは多数のディスクを収容
したチェンジャ７から抽出され、ＭＩＤＩ情報等はＭＩ
ＤＩ音源部８によりスピーカ９から発音され、背景画は
表示駆動部１０を介してディスプレイ１１上に表示され
る。

【０００９】

【発明が解決しようとする課題】ここで、インデックス
情報や音楽情報などの楽曲データの登録手順及びその再
生手順について説明する。図７は楽曲データの登録手順
を示すフローチャートであり、まず、配信センタ１から
楽曲データの送信があるか否かを判断し（Ｓ１）、送信
がある場合には、記憶部５の容量に余裕があるか一杯で
あるかを判断する（Ｓ２）。ＮＯの場合、すなわち記憶
部５の容量に余裕がある場合には、送信された楽曲デー
タを全て登録するが（Ｓ３）、ＹＥＳの場合、すなわち
余裕がない場合には、楽曲データの登録を行なわない
（Ｓ４）。図８は楽曲データの再生手順を示すフローチ
ャートであり、まず、入力手段６から利用者によりリク
エスト曲が入力されたか否かを判断し（Ｓ１）、リクエ
スト曲が入力されるとそのリクエスト曲の楽曲データが
記憶部５にて記憶されているか否かを判断する（Ｓ
２）。ここで、ＹＥＳの場合、すなわち、リクエスト曲
の楽曲データを記憶している場合には、その楽曲を読み
出して再生を行なうが（Ｓ３）、ＮＯの場合には、リク
エスト曲の楽曲データを記憶していないので、曲無しと
して（Ｓ４）、終了する。

【００１０】このように、従来の通信カラオケ装置にお
いては、配信センタ１から送られる楽曲データを全て記
憶部５に貯め込み、そのまま記憶するようにしているの
で、記憶部５の容量が一杯になるとそれ以上の楽曲デー
タの配信を行なうことができなかった。また、最新の新
譜楽曲データを登録するには、マニュアルで既登録の楽
曲データを削除しなければならず、この時の削除曲の選
択も操作者が判断しなければならなかった。また、上述
のように登録された楽曲データは、マニュアルで削除さ
れない限り、記憶部に永続的に記憶された状態となるの
で、全くリクエストされない楽曲やリクエスト頻度の極
端に少ない楽曲も記憶されている状態となるので、不使
用楽曲データに記憶部がかなり占有されてしまう場合も
生じ、記憶部の有効利用ができなかった。本発明は、以
上のような問題点に着目し、これを有効に解決すべく創
案されたものであり、その目的は、記憶容量の有効利用
を行なうことができる通信カラオケ装置の楽曲データの
登録・削除・設定変更方法を提供することにある。

【００１１】

【課題を解決するための手段】本発明は、上記問題点を
解決するために、配信センタから送られる楽曲データを
記憶する記憶手段と、利用者のリクエスト曲を入力する
入力手段と、この入力手段から入力されたリクエスト曲
に対応する楽曲データを前記記憶手段に記憶される楽曲
データから選択する制御手段と、選択された前記楽曲を
楽音として出力する出力手段とを有する通信カラオケ装
置の楽曲データの登録・削除・設定変更方法において、
前記楽曲データは、楽曲に関するインデックス情報と音
楽情報とを含み、前記配信センタからの指令に応じて前
記記憶手段に記憶される楽曲データを登録・削除・設定
変更するように構成したものである。

【００１２】このように構成することにより、配信セン
タからの指令により記憶手段に楽曲データが記憶された
り、記憶手段に記憶されている楽曲データを削除した
り、設定変更したりする。配信センタからの指令には、
例えば楽曲データを登録するための登録指令、既登録の
データを削除する削除指令、データを変更する設定変更
指令の３種類がある。楽曲データを登録する場合には、
楽曲に関するインデックス情報のみを登録する場合と、
インデックス情報と音楽情報の両者を登録する場合があ
り、登録すべき指令が入力された時には、登録すべきデ
ータの容量と記憶手段の残容量とを比較し、この比較結
果に応じて、記憶手段に記憶されている楽曲データを削
除するか否かを決定し、残容量不足時には、既登録の楽
曲データを削除する。このように楽曲データを削除する
時には、全ての楽曲データを削除する場合もあるが、通
常はインデックス情報に対してデータ量が遥かに大きな
音楽情報（ＭＩＤＩや歌詞文字情報など）のみを削除
し、インデックス情報は次のリクエストに備えて残して
おく。

【００１３】また、このような削除指令に備えて、削除
優先リストを作成しており、このリストには楽曲データ
が記憶手段に登録された日付けが記録されて日付けの古
い順に削除されるが、この日付けは、楽曲がリクエスト
される毎に更新され、削除優先度を下げる。リクエスト
頻度の高い楽曲は、削除されることなく残ることにな
る。また、コーラス曲を含む楽曲データは、当初より削
除対象外とする。これは、コーラス自体のデータ量は、
ＭＩＤＩと比較しても膨大なのが一般的であり、配信セ
ンタから再配信するとなると通信コストが大幅に上昇し
てしまうためである。

【００１４】

【発明の実施の形態】以下に、本発明に係る通信カラオ
ケ装置の楽曲データの登録・削除・設定変更方法の一実
施例を添付図面に基づいて詳述する。図１は本発明方法
を実施するための通信カラオケ装置を示すブロック構成
図、図２は記憶手段に記憶されるデータの種類の一例を
示す図である。

【００１５】まず、この通信カラオケ装置について説明
する。この通信カラオケ装置１２は、配信センタ１から
電話回線などの通信回線２を介して配信される多数の楽
曲のデータや多数の静止画のデータを記憶する大容量
の、例えばハードディスクよりなる記憶手段１３と、利
用者がリクエスト曲を入力する入力手段１４と、この入
力手段１４からリクエストされた楽曲を上記記憶手段１
３から選択したり、これに対応する背景画を選択する、
例えばマイクロコンピュータ等よりなる制御手段１５
と、選択された楽曲や背景画を再生して出力する出力手
段１６とを有している。更に、このカラオケ装置１２
は、制御手段１５に付随する登録・削除・設定変更判断
部１７と、上記記憶手段１３の空いている残容量と登録
すべき楽曲のデータ量とを比較する残容量比較部１８
と、削除すべき楽曲を抽出する削除候補抽出部１９とを
有している。

【００１６】上記記憶手段１３は、配信センタ１から送
られる情報を記憶するものであり、ここにはインデック
ス情報を記憶するインデックス情報エリア１３Ａ、残容
量情報エリア１３Ｂ、削除優先リストエリア１３Ｃ、音
楽情報エリア１３Ｄ等が割り当てられて、記憶される。
尚、この記憶手段１３には、背景画として静止画情報等
も割り当てられて記憶される。

【００１７】ここで配信センタ１から配信される楽曲デ
ータの構成について図２も参照して説明すると、楽曲デ
ータは、インデックス情報と音楽情報とよりなり、イン
デックス情報はその曲の付随的な情報、例えばその曲の
楽曲番号、曲名、歌手名、コーラスの有無、音楽情報の
有無、その楽曲のデータ容量、再生の可不可等を示す情
報であり、楽曲毎にこのような情報を付している。例え
ばコーラスの有無は、この楽曲がコーラス付きなのか否
かを示し、音楽情報の有無は、この楽曲の後述する音楽
情報が記憶手段１３に記憶されているか否かを示し、再
生の可不可は、この楽曲を再生しても良いのか否かを示
し、例えば子供向けカラオケ装置においては、アダルト
ものの楽曲に関しては、再生不可としておく。インデッ
クス情報の上記した各項目毎に数ビット程度割り当てら
れることになる。このように、楽曲に付随するデータ量
は、非常に少ないのでインデックス情報エリア１３Ａの
大きさは非常に少なくて済み、また、インデックス情報
は、上述のように固定された項目に関する情報であるた
めに各楽曲のインデックス情報の大きさは固定長であ
る。このようなインデックス情報は、インデックス情報
エリア１３Ａに記憶される。

【００１８】これに対して音楽情報は、楽曲に対する実
体的なデータを構成し、楽曲番号の他に、シンセサイザ
等を駆動して演奏を行なうＭＩＤＩ情報、演奏と共に歌
うべき歌詞文字の情報、コーラスが付与されている場合
にはそのコーラス情報等が含まれており、この音楽情報
は音楽情報エリア１３Ｄに記憶され、個々の楽曲のデー
タ量は膨大なものとなる。残容量情報エリア１３Ｂに記
憶される残容量は、この記憶手段１３の空き容量に関す
る情報を示し、楽曲データの登録毎或いは削除毎に更新
される。削除優先リストエリア１３Ｃには、前述のよう
に各楽曲データの登録日が記憶され、この登録日は、そ
の曲がリクエストされる毎に更新されて、制御手段１５
から削除要求がなされると削除優先度が最も高い楽曲、
すなわち登録日或いはリクエスト日が最も古い楽曲が選
択される。

【００１９】配信センタ１からの指令の種類には、例え
ば楽曲データを登録するための登録指令、既登録のデー
タを削除する削除指令、データ、特にインデックス情報
の内容を変更する設定変更指令が存在し、前記登録・削
除・設定変更判断部１７が上記指令の内容を解析し、判
断する。残容量比較部１８は、楽曲データを登録すべき
指令がなされた時に、登録すべきデータの容量と記憶手
段１３の残容量とを比較する。削除候補抽出部は、記憶
手段１の容量が新たな楽曲データを登録するには容量が
不足している時に、削除候補楽曲を選択する部分であ
り、これには、コーラス付きの楽曲は除かれる。

【００２０】出力手段１６は、例えばＭＩＤＩ音源部２
０と表示駆動部２１よりなり、ＭＩＤＩ音源部２０は、
ＭＩＤＩ情報を再生してスピーカ２２から発音したり、
これとマイクロフォン２３から入力される肉声をミキシ
ングしてスピーカ２２から出力するようになっている。
表示駆動部２１は、最終的に選択された動画や静止画を
ディスプレイ２４に表示するようになっている。また、
動画を記憶するために多数の光ディスク等を収納するチ
ェンジャ２５が設けられており、各光ディスクは、自動
出し入れが可能なように棚内の所定の位置に配置され
る。

【００２１】入力手段１４は、利用者がリクエスト曲を
入力するキー群を有しており、例えば４ケタのコードを
入力することにより選曲を行なう。尚、この入力手段１
４には、特定の静止画を選択するために選画番号も入力
し得るようになっているが、これは本発明と直接的には
関係しないので、ここではこれ以上触れない。また、記
憶手段１３の前段には、一定量の容量を有するバッファ
メモリ２６が設けられており、配信センタ１から送られ
るデータを無条件で一定量は貯め得るようになってい
る。

【００２２】次に、以上のように構成されたカラオケ装
置にて行なわれる本発明方法を図３及び図４も参照しつ
つ説明する。まず、配信センタ１からはある程度の数の
楽曲データが通信回路２を介してすでに送られてきてお
り、これらの各楽曲毎のインデックス情報は記憶手段１
３のインデックス情報エリア１３Ａに、音楽情報は音楽
情報エリア１３Ｄにそれぞれ記憶されている。また、削
除優先リストエリア１３Ｃには、各楽曲の登録日或いは
リクエストがすでに行なわれた場合には、それに代えて
リクエスト日が記憶されている。更に、残容量情報エリ
ア１３Ｂには、記憶手段１３の現在の空き容量、すなわ
ち残容量に関する情報が記憶されている。

【００２３】このような状況下において、カラオケ装置
１２は、配信センタ１からの配信、すなわち送信データ
が存在するか否かを常時チェックしており（Ｓ１１）、
送信データが存在すると、登録・削除・設定変更判断部
１７においてそのデータの指令内容が登録、削除、設定
変更の内、どの指令に該当するか判断する（Ｓ１２）。
尚、この指令内容の種類は、予め定められている。

【００２４】ここで指令内容が新しい楽曲データを登録
するための［登録指令］の場合には、次に、楽曲データ
全体、すなわちインデックス情報と音楽情報を含む全体
を登録するのか否かを判断する（Ｓ１３）。ここでＮＯ
の場合には、インデックス情報のみを記憶手段１３のイ
ンデックス情報エリア１３Ａに記憶する（Ｓ１４）。こ
の場合には、この楽曲の音楽情報は記憶しないので、当
然のこととしてインデックス情報中の音楽情報の有無の
項目は、［無］を示す状態になされており、リクエスト
時に備える。また、このようなインデックス情報の容量
は非常に小さく、しかも記憶手段１３の残容量が零の状
態はほとんど生ずることがないので、この残容量のチェ
ックを行なうことなくインデックス情報を記憶する。

【００２５】Ｓ１３に戻って、ここでＹＥＳの場合、す
なわち楽曲データ全体を記憶して登録する指令の場合に
は、データ量が大きくなることから、まず、残容量比較
部１８は、この楽曲のデータ量と残容量情報エリア１３
Ｂから読み出した残容量とを比較して記憶手段１３の容
量は一杯になっているか否かを判断する（Ｓ１５）。こ
こでＮＯの場合、すなわち記憶手段１３の容量に余裕が
ある場合には、その楽曲のインデックス情報をインデッ
クス情報エリア１３Ａに、ＭＩＤＩや歌詞文字情報等を
音楽情報エリア１３Ｄにそれぞれ記憶して楽曲データ全
体を登録する（Ｓ１６）。尚、この場合、インデックス
情報の音楽情報の有無の項目は［有］を示す状態になさ
れており、リクエスト時に備える。そして、削除優先リ
スト１３Ｃには、その楽曲の登録日を記憶させる（Ｓ１
７）。尚、残容量情報エリア１３Ｂの内容も、更新され
て新たに登録された楽曲データの容量分だけ差し引かれ
た値となる。

【００２６】Ｓ１５に戻って、ここでＹＥＳの場合、す
なわち記憶手段１３の残容量が、新たな楽曲データを記
憶するためには少なすぎる場合には、削除候補抽出部１
９が記憶手段１３の削除優先リスト１３Ｃを参照するこ
とにより削除すべき楽曲を抽出し、選択する（Ｓ１
８）。尚、この抽出プロセスは後述するが、登録日かリ
クエスト日が最も古い楽曲が選択される。

【００２７】ここで、削除対象楽曲が求められると、こ
の楽曲のインデックス情報は残したままとして、インデ
ックス情報と比較して容量の大きな音楽情報を削除して
残容量を拡大する（Ｓ１９）。次に、この楽曲に関する
登録設定日或いはリクエスト日を削除優先リストエリア
１３Ｃから除き（Ｓ２０）、更に、残されたインデック
ス情報内の音楽情報の有無の項目を［有］から［無］に
変更してリクエストに備える（Ｓ２１）。そして、再
度、Ｓ１５に戻り、登録に十分な大きさの残容量を確保
できるまでＳ１５、Ｓ１８〜Ｓ２１を繰り返し行なう。
従って、新たな楽曲データ登録するために、使用頻度の
少ない楽曲を複数個削除する場合もあり、いずれにして
もここではインデックス情報は削除されることなく残さ
れる。

【００２８】ここで、図４を参照して先のＳ１８におけ
る削除候補の抽出操作について説明すると、まず、削除
優先リスト１３Ｃを参照することによって、削除優先リ
ストの中で登録日付けとリクエスト日の内、最も早い楽
曲を抽出する（Ｓ１８−１）。このような楽曲は使用頻
度が最も少ないことを意味する。次に、抽出した楽曲が
コーラス付きの楽曲か否かを判断し（Ｓ１８−２）、Ｙ
ＥＳの場合、すなわちコーラス付きの楽曲の場合には削
除候補から外す。この理由は、コーラス情報はＭＩＤＩ
情報と比較して例えば１００倍もの大きな容量を有して
いるのが一般的であり、もしこのコーラス付き楽曲デー
タを削除すると、次に、この楽曲がリクエストされた時
に送信コストが非常に高くなってしまうからである。そ
のために、コーラス付きの楽曲は削除することなく残す
こととする。上記Ｓ１８−２にてＮＯの場合、すなわち
コーラス付きでない楽曲の場合には、これを削除楽曲と
して選択する（Ｓ１８−３）。以降は、この楽曲のイン
デックス情報が残されて、音楽情報が削除されるのは前
述の通りである。

【００２９】次に、図３のＳ１２に戻って、ここで［削
除指令］の場合には、次に楽曲データ全体（インデック
ス情報と楽曲情報）を削除する指令なのか否かを判別し
（Ｓ２２）、ＮＯの場合、すなわち音楽情報のみの削除
指令の時にはインデックス情報を残して音楽情報のみを
削除し（Ｓ２３）、これと共にインデックス情報の音楽
情報の有無の項目を［有］から［無］に変更してリクエ
ストに備える（Ｓ２４）。更に、削除した楽曲に関する
情報を削除優先リストエリア１３Ｃから除く（Ｓ２
５）。Ｓ２２に戻って、ここでＹＥＳの場合、すなわ
ち、楽曲データ全体を削除する指令の場合には、この楽
曲のインデックス情報と楽曲情報も共に削除し（Ｓ２
６）、更に、Ｓ２５にてこの楽曲を削除優先リストから
外す。このような楽曲は、例えばほとんどリクエストさ
れない楽曲である。

【００３０】次に、Ｓ１２に戻って、ここで［設定変更
指令］の場合には、その楽曲のインデックス情報を変更
する（Ｓ２７）。このようにインデックス情報のみを変
更する場合には、例えばこのカラオケ装置を子供専用装
置として使用する場合には、再生の可不可の項目を［不
可］に設定してアダルトものの楽曲の再生を不許可にす
る場合に使用される。このように、配信センタから楽曲
データの登録指令があった時には、記憶手段１３の空き
スペースがある限り、楽曲データをそのまま記憶して登
録し、空きスペースがなかった場合には使用頻度の最も
少ない順から楽曲データを削除することになって登録に
必要なスペースを確保することができる。この削除操作
においては、楽曲のインデックス情報のみは残すように
してリクエストに備えることができる。

【００３１】また、配信センタからの削除指令によっ
て、楽曲データを全て削除することもできるし、リクエ
ストに備えてインデックス情報を残し、音楽情報のみを
削除することもできる。次に、このようなカラオケ装置
を用いて楽曲を再生する場合について図５を参照して説
明する。まず、このカラオケ装置では入力手段１４から
リクエスト曲が入力されたか否かを常時チェックしてお
り（Ｓ５１）、リクエスト曲が入力されると、制御手段
１５は記憶手段１３のインデックス情報エリア１３Ａを
参照して、リクエスト曲のインデックス情報が存在する
か否かを判断する（Ｓ５２）。ＹＥＳの場合、すなわち
リクエスト曲のインデックス情報が存在する場合には、
次にリクエスト曲の音楽情報を記憶しているか否かを判
断する（Ｓ５３）。この判断は、インデックス情報の音
楽情報の有無の項目の状態をチェックすることにより行
なう。

【００３２】この判断の結果、ＹＥＳの場合、すなわち
音楽情報が記憶されている場合には、この読み出しを行
なって音楽情報の再生を行なう（Ｓ５４）。尚、この場
合、再生の可不可もチェックされて再生許可状態となっ
ているのは勿論であり、また、コーラス付きの場合には
コーラスも再生され、同時に、適切な背景画もディスプ
レイに表示されるのは通常の動作と同じである。

【００３３】Ｓ５３に戻り、ここでＮＯの場合、すなわ
ち、リクエスト曲の音楽情報を記憶していない場合に
は、このリクエスト曲の音楽情報等の楽曲データを配信
センタ１に対して配信するように要求を出し（Ｓ５
５）、これにより配信センタ１はこのリクエスト曲の楽
曲データを通信回線２を介してこのカラオケ装置に配信
する（Ｓ５６）。そして、配信された楽曲データは前述
したと同様な手順で記憶されて登録される（Ｓ５７）。
これにより、Ｓ５４にて読み出しが可能となり、音楽情
報の再生を行なう。また、Ｓ５２に戻り、ここでＮＯの
場合、すなわちリクエスト曲のインデックス情報が記憶
されていない場合には、リクエスト曲無しとして（Ｓ５
８）、再生操作は行なわない。

【００３４】このように、リクエストがなされた場合、
そのリクエスト曲の楽曲データが全て記憶されていれ
ば、直ちに再生することができるし、また、インデック
ス情報のみが記憶されている場合には、それに対応する
音楽情報を直ちに配信センタからリアルタイムで配信さ
せ、その後、直ちに再生することができる。従って、リ
クエスト頻度の比較的多い曲に関する全ての楽曲データ
は記憶手段に常駐させ、リクエスト頻度の少ない曲に関
してはインデックス情報のみを記憶手段に常駐させてリ
クエスト時に音楽情報を配信させるようにしたので、不
必要な楽曲データは削除して記憶容量を有効利用するこ
とが可能となる。

【００３５】

【発明の効果】以上説明したように、本発明の通信カラ
オケ装置の楽曲データの登録・削除・設定変更方法によ
れば、次のように優れた作用効果を発揮することができ
る。配信センタからの指令に応じて記憶手段に記憶され
る楽曲データの登録・削除・設定変更を行なうようにし
たので、例えば楽曲データの登録指令があった場合にお
いて、記憶容量が不足している時には、例えばリクエス
ト頻度の少ない楽曲データを削除することにより必要な
記憶容量を確保することができる。また、この削除を行
なうにあたり、インデックス情報は残されているので、
この楽曲のリクエストが行なわれた場合には、配信セン
タから直ちに配信することができる。従って、全体とし
て記憶容量を有効に利用することができるので、必要最
小限の記憶容量でカラオケ装置を運用することができ
る。また、楽曲データの登録指令があった場合におい
て、記憶容量不足時にはコーラス付きの楽曲は削除対象
楽曲から外すことにより、この楽曲がリクエストされた
時に備えて通信コストが過大になることを防止すること
ができる。

【図面の簡単な説明】

【図１】本発明方法を実施するための通信カラオケ装置
を示すブロック構成図である。

【図２】記憶手段に記憶されるデータの種類の一例を示
す図である。

【図３】本発明方法を示すフローチャートである。

【図４】削除候補の抽出方法を示すフローチャートであ
る。

【図５】楽曲の再生時を示すフローチャートである。

【図６】一般的な通信カラオケ装置を示すブロック構成
図である。

【図７】通信カラオケ装置の楽曲データの従来の登録方
法を示すフローチャートである。

【図８】通信カラオケ装置の楽曲データの従来の再生方
法を示すフローチャートである。

【符号の説明】

１…配信センタ、２…通信回線、１２…通信カラオケ装
置、１３…記憶手段、１３Ａ…インデックス情報エリ
ア、１３Ｂ…残容量情報エリア、１３Ｃ…削除優先リス
トエリア、１３Ｄ…音楽情報エリア、１４…入力手段、
１５…制御手段、１６…出力手段、１７…登録・削除・
設定変更判断部、１８…残容量比較部、１９…削除候補
抽出部。

Claims (6)

【特許請求の範囲】
1. 【請求項１】 配信センタから送られる楽曲データを記
   憶する記憶手段と、利用者のリクエスト曲を入力する入
   力手段と、この入力手段から入力されたリクエスト曲に
   対応する楽曲データを前記記憶手段に記憶される楽曲デ
   ータから選択する制御手段と、選択された前記楽曲を楽
   音として出力する出力手段とを有する通信カラオケ装置
   の楽曲データの登録・削除・設定変更方法において、前
   記楽曲データは、楽曲に関するインデックス情報と音楽
   情報とを含み、前記配信センタからの指令に応じて前記
   記憶手段に記憶される楽曲データを登録・削除・設定変
   更することを特徴とする通信カラオケ装置の楽曲データ
   の登録・削除・設定変更方法。
2. 【請求項２】 前記指令は、前記楽曲データを登録する
   ための登録指令と、前記記憶手段に記憶されている楽曲
   データを部分的に或いは全部削除するための削除指令
   と、前記記憶手段に記憶されているインデックス情報の
   内容を変更するための設定変更指令の内、いずれか１つ
   であることを特徴とする請求項１記載の通信カラオケ装
   置の楽曲データの登録・削除・設定変更方法。
3. 【請求項３】 前記登録指令としては、楽曲に関するイ
   ンデックス情報のみを登録する指令と、インデックス情
   報と音楽情報の両者を登録する指令とが存在し、前記登
   録指令が入力された時には、登録すべきデータ容量と前
   記記憶手段の残容量とを比較し、この比較結果に応じて
   前記記憶手段に記憶されている楽曲データを削除するか
   否かを決定することを特徴とする請求項２記載の通信カ
   ラオケ装置の楽曲データの登録・削除・設定変更方法。
4. 【請求項４】 前記楽曲データを削除する場合には、前
   記インデックス情報を残して音楽情報を削除するように
   したことを特徴とする請求項３記載の通信カラオケ装置
   の楽曲データの登録・削除・設定変更方法。
5. 【請求項５】 前記記憶手段は、前記楽曲の登録日が記
   録されて当該楽曲がリクエストされる毎に前記登録日を
   更新するようにした削除優先リストが記憶されており、
   楽曲データを削除する時に前記削除優先リストを参照し
   て最も削除優先度が高い楽曲から削除するようにしたこ
   とを特徴とする請求項４記載の通信カラオケ装置の楽曲
   データの登録・削除・設定変更方法。
6. 【請求項６】 前記楽曲データがコーラスを含む場合に
   は、削除対象楽曲から外すことを特徴とする請求項５記
   載の通信カラオケ装置の楽曲データの登録・削除・設定
   変更方法。