JP4214900B2 - コンテンツデータ再生装置及びプログラム - Google Patents

Description

本発明は、音楽や映像等のコンテンツデータを再生するコンテンツデータ再生装置に関し、特に、コンテンツデータの収容状況を出力（例えば表示等）することのできる装置に関する。

現在、通信カラオケシステムは、従来のモデムによる「ナローバンド接続」から、高速、大容量の「ブロードバンド接続」への移行期にある。ここで言う「通信カラオケシステムのブロードバンド化」とは、ホスト−カラオケ装置間の配信システムの通信経路が、モデムと電話網から、ＡＤＳＬやＦＴＴＨなどの高速インターネットの常時接続サービスに置き換わることを意味している。

ただし、コンテンツの保持形態は、依然としてカラオケ装置内のＨＤＤに蓄積する「配信＋蓄積型」であり、オンデマンドによるストリーム再生のような形式には簡単にはならないと思われる。それは、ＡＤＳＬやＦＴＴＨなどの高速インターネット接続サービスをもってしても、オンデマンド形式のサービスには帯域不足であり、運用の安定性に欠けるからである。

従って、近年の通信カラオケシステムのブロードバンド化とは、配信によって日々刻々追加される新曲に費やすことのできるデータ容量が、数十キロバイト単位から数百メガバイト単位にまで増やすことができることを意味する。近年のＨＤＤの記憶容量の増加によってこの程度の容量のデータを蓄積することも容易になっている。

さて、上述のように、ブロードバンド化によってコンテンツ（楽曲）１つに対して費やされる情報量は飛躍的に大きくなり、楽曲専用の映像と、サンプリングによる生音声（ＭＰＥＧビデオ）で制作することが可能になっている。その一方で、これまでの通信カラオケ装置の発展の中で蓄積されてきた、ナローバンドのコンテンツ、いわゆるＭＩＤＩと歌詞情報によるコンパクトな楽音演奏データの重要性が減じたわけではなく、膨大な曲数を擁するこれらナローバンドのコンテンツが、今後暫くは主流であると考えられる。それは、ＭＰＥＧビデオによる「高付加価値の」コンテンツは制作コストが高く、ブロードバンドによってこうした大容量コンテンツの配信が可能になっても、制作される楽曲数としては、比較的少なくならざるを得ないと考えられるからである。こうした高付加価値のブロードバンド向けのＭＰＥＧビデオ形式コンテンツは少数の人気曲やタイアップ曲に限られ、大多数の楽曲は、今後暫く、ＭＩＤＩ形式で作成されることになると考えられる。

また、高画質なＭＰＥＧビデオ形式での配信が可能になったことによって、通信カラオケ装置のサービスを差別化する動きも始まっている。アーティストの作成するプロモーションビデオのような、付加価値の高い短編映像作品を追加的な有償サービス契約を行ったカラオケ店舗のみに配信するといったケースである。

一方で、通信カラオケ装置には、収容されている楽曲の総数を知ることのできる、「総曲数表示機能」を持つことが当たり前になっている（例えば、特許文献１参照）。通信カラオケ装置を使ってカラオケ店舗を運営する事業者にとって、所有する装置内の総曲数に重要な関心を持つことは当然である。それは、カラオケサービスの質に直結する事項だからである。
特公平７−１０８０２５号公報

このように「総曲数表示機能」はいわば必須機能であったが、上述した通信カラオケのブロードバンド化によって別の観点で重視すべき事態が生じ、従前とは同様には捉えられないようになってきている。

まず、事業者が所有するカラオケ装置内の総曲数を知る場合、総曲数が十分に多いのかどうか、配信によって日々刻々と増加しているかどうかということに関心が向く。例えば、Ｊ社の通信カラオケサービスを導入している場合、Ｊ社の発表する総曲数と、自分の所有するカラオケ装置の総曲数が、ほぼ同じでなければならない。実際には、通信による遅延があるため、ある時点での総曲数には食い違いがありえるが、それでも、数百、数千といったレベルで異なれば事業者としては問題を感じてしまう。例えばＪ社が４月１日時点で５１０００曲だと発表していれば、４月２日の時点でカラオケ装置の総曲数表示は、例えば５０９９５曲といった程度の誤差レベルでなくてはおかしい。

ところが、これが、ブロードバンド化によって「１曲の価値」が大きく違う楽曲が含まれるようになると、問題が複雑になる。例えば従来のナローバンドのコンテンツばかりの状況においては、蓄積曲として５１０００曲であるか５０９９９曲であるかという状態の差は、カラオケサービスの質としてそれほどの違いはなく、配信システムが正常に稼動している限り、事業者が気に病む必要はなかった。しかし、不足するその１曲が、例えばブロードバンド向けにＭＰＥＧビデオで制作された話題性のある高画質で魅力的なプロモーション映像付きの楽曲であった場合には同様に考えるわけにはいかない。その１曲が存在するかしないかで提供できるサービスの全体的な質が大きく左右されかねないからである。つまり、ブロードバンド化によって「１曲の価値」が大きく違うサービスが始まると、通信カラオケ装置に収容された総曲数だけを気にしているわけにはいかなくなる。

なお、このような問題は、コンテンツデータがカラオケ曲の場合に限らず、他のコンテンツデータでも発生し得るものである。
そこで、本発明は、このように価値の異なるコンテンツデータが併存して蓄積されている場合であっても、その価値の違いに応じたコンテンツデータの蓄積実態を適切に把握可能なようにすることを目的とする。

上述した問題点を解決するためになされた本発明のコンテンツデータ再生装置は、コンテンツデータ記憶手段に記憶されているコンテンツデータに基づいてコンテンツ再生を行うものであるが、判断手段がコンテンツデータの価値分類を判断し、計測手段が、コンテンツデータ記憶手段に記憶されているコンテンツデータに関して、その価値分類毎にデータ総数を計測する。そして、出力手段が、判断手段によって判断された複数の価値分類毎に、計測手段によって計測されたデータ総数を出力する。なお、この出力に関しては、表示装置へ出力して表示させても良いし、あるいは印刷装置へ出力してプリントアウトさせても良い。

ここで判断手段は、コンテンツデータに付加された価値分類識別情報、コンテンツデータのデータ特性、価値分類毎に区分けされたコンテンツデータ記憶手段中の記憶領域のどこに記憶されているか、の少なくとも何れかに基づいてコンテンツデータの価値分類を判断する。価値分類に関しては、適用先に応じて適宜設定することができるが、例えば、いわゆる通信カラオケを例にとって説明すると、通常通常楽曲は、これまでの通信カラオケで主流であったＭＩＤＩ楽曲である。また、ブロードバンド楽曲は、例えばＭＰＥＧビデオデータを含み、従来のＭＩＤＩ楽曲の１００倍〜１０００倍といった大きなサイズのカラオケデータ（高付加価値コンテンツ）であり、通信時間の観点から一般的にブロードバンド通信でしか配信できないような大容量の楽曲である。また、契約楽曲は、カラオケサービスの毎月の情報通信料金に追加の料金を徴収する契約を結ぶことで配信されるようになる、付加価値の大きい楽曲である。これも、ブロードバンドでしか配信できない大容量のＭＰＥＧビデオデータを含むカラオケデータとして構成することが考えられる。楽曲・ブロードバンド楽曲・契約楽曲といった３分類が一例として考えられる。

これらはカラオケデータとしては同じであるが、上述の課題の項でも説明したように、「１曲の価値」が大きく違うものである。特に、通常楽曲とブロードバンド楽曲（あるいは契約楽曲）については、その差が大きい。したがって、このように価値の異なるコンテンツデータが併存して蓄積されている場合であっても、本発明装置によれば、その価値の違いに応じたコンテンツデータの蓄積実態を適切に把握可能である。

なお、コンテンツデータについては、例えば上述の通信カラオケ装置の場合であれば、配信用ホスト装置（センタ）からＩＳＤＮ回線やブロードバンド回線を介して配信されることとなるが、例えばＣＤ−ＲＯＭやＤＶＤ−ＲＯＭその他の可搬記憶媒体を介して供給される形式もあり得る。もちろん、それらの併用も考えられる。

なお、コンテンツデータのデータ特性としては、データの形式（例えばＭＰＥＧで収録されているか、ＭＩＤＩで収録されているかなど）やデータ容量などが考えられる。これらはファイル拡張子やデータサイズ等によって容易に判断できる。

次に、出力方法として表示装置への表示を行う場合の工夫について説明する。例えばカラオケシステムの場合、選曲番号等を表示するための７セグメントＬＥＤのような簡易表示装置と、歌詞テロップや背景映像を表示するためのディスプレイのような表示装置とを備えることが一般的である。

本発明のコンテンツデータ再生装置における出力手段は、コンテンツデータ再生装置の起動時に、前記複数の価値分類毎のデータ総数を、価値分類を示す識別記号と数字の組み合わせによって、前記複数の価値分類毎のデータ総数を一覧表示させることのできない表示装置へ所定時間毎に順番に表示させ、最後の順番のデータ総数の表示が終了したら、非表示にする。

さらに、各種指示を受け付ける指示受付手段を備え、その指示受付手段によって価値分類毎のデータ総数の表示指示を受け付けた場合、前記複数の価値分類毎のデータ総数を表示装置へ所定時間毎に順番に表示させ、最後の順番のデータ総数の表示が終了したら、非表示にするようにしてもよい。

このようにすれば、装置起動時だけでなく、コンテンツデータ再生装置の管理者が任意のタイミングで現在のコンテンツデータの蓄積状況を知りたい場合に有効な対処である。

さて、判断手段によるコンテンツデータの価値分類判断に関してさらに説明する。上述のように、判断手段は、コンテンツデータに付加された価値分類識別情報、コンテンツデータのデータ特性、価値分類毎に区分けされたコンテンツデータ記憶手段中の記憶領域のどこに記憶されているか、の少なくとも何れかに基づいて判断するのであるが、例えばコンテンツデータに付加された価値分類識別情報やコンテンツデータのデータ特性に基づいて判断する場合、コンテンツデータ記憶手段においては特に分類せずに記憶しておき、計測手段によるデータ総数の計測時に、判断手段によって逐次判断しながらデータ総数を計測していくこともできる。但し、価値分類識別情報やコンテンツデータのデータ特性に基づいて予め価値分類判断をしておき、その結果に応じた記憶領域に格納することも考えられる。例えば制御手段が、コンテンツデータに付加された価値分類識別情報に基づいて価値分類が判断されたコンテンツデータを、その価値分類に対応するコンテンツデータ記憶手段中の記憶領域に格納するように構成し、計測手段によるデータ総数の計測時には、コンテンツデータ記憶手段中の価値分類毎の記憶領域単位でデータ総数を計測するのである。このようにすれば、格納時には価値分類判断が必要となるが、データ総数計測時には判断が不要となり、計測結果の出力が早期に実現できる。

なお、上述したコンテンツデータ再生装置における判断手段、計測手段、出力手段、制御手段をコンピュータにて実現する場合、例えばコンピュータで実行するプログラムとして備えることができる。このようなプログラムは、例えばフレキシブルディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ハードディスク、ＲＯＭ、ＲＡＭ等のコンピュータ読み取り可能な記録媒体に記録し、必要に応じてコンピュータにロードして実行したり、ネットワークを介してロードして実行することにより、これら各手段としての機能を実現できる。

以下、本発明が適用された実施例について図面を用いて説明する。尚、本発明の実施の形態は、下記の実施例に何ら限定されることはなく、本発明の技術的範囲に属する限り種々の形態を採りうる。

［通信カラオケ装置及びその周辺機器の構成］
図１は、本実施例のコンテンツデータ再生装置としての通信カラオケ装置１の構成及び稼働時の周辺機器の構成を示すブロック図である。

本実施例の通信カラオケ装置１は、通信カラオケ装置１全体の制御を司るＣＰＵ１４、及びこのＣＰＵ１４に接続された以下の各部、すなわち曲の予約操作などを行うための操作パネル１０、画像情報等を映像化するための映像処理部１１、ＭＰＥＧ２映像データの再生手段となるＭＰＥＧデコーダ１２、カラオケ演奏用の楽曲データや映像データその他各種データを記憶しているハードディスク（ＨＤＤ）１３、システムプログラムや各種の設定に必要な設定データなどを記憶しておくメモリ１５、ＬＡＮインターフェース１６、ＭＩＤＩデータ（楽曲データ）に基づく演奏再生を行うＭＩＤＩ音源部１８、ＭＩＤＩ音源部１８による再生音及び利用者（歌唱者）の歌声をミキシングする等して適宜音声処理を施す音声処理部１９を備えている。

音声処理部１９はアンプ２０と接続されており、音声処理部１９から出力された音声情報に係る電気信号はアンプ２０によって増幅等されてスピーカ２２に出力され、このスピーカ２２から伴奏曲及び利用者（歌唱者）の歌声等が発せられる。また、利用者（歌唱者）の歌声等はマイクロフォン（以下、単にマイクと称す。）２３を介して音声処理部１９に入力される。また、映像処理部１１は背景画及び歌詞等を表示するモニタ２６と接続されている。また、ＬＡＮインターフェース１６はＬＡＮハブ装置２５に接続されている。このＬＡＮハブ装置２５にはＡＤＳＬモデム２７が接続されていると共に、カラオケ店舗内ＬＡＮ網を介して、別室（１，２）に設置された（別の）通信カラオケ装置１とも接続されている。ＡＤＳＬモデム２７はルータ機能を内蔵しており、通信カラオケ装置１は、このＡＤＳＬモデム２７、そしてインターネット３０を経由して配信センタ５０との通信を行うことができるよう構成されている。

ここで、操作パネル１０は、この通信カラオケ装置１の本体前面に設けられており、図２（ｂ）に示すように、利用者によって操作され、任意の曲の選択、演奏音の音程の調整、演奏と歌との音量バランスの調整、その他エコー、音量、トーンなど各種調整を行うためのスイッチ類１０ａと、現在演奏中の曲コードや予約曲数などを表示するための表示パネル１０ｂを備えている。本実施例の表示パネル１０ｂは、７セグメントＬＥＤで構成されており、６桁の数字や記号を表示可能なものである。

また、ＨＤＤ１３には、楽曲データや画像情報などのコンテンツデータなどが記憶されている。そして、操作パネル１０の操作部を介して曲が選択されると、ＣＰＵ１４は、楽曲データや画像情報をＨＤＤ１３から呼び出して、映像処理部１１およびＭＩＤＩ音源部１８に同期させて出力するようになっている。

ＣＰＵ１４から出力されるＭＩＤＩデータは、ＭＩＤＩ音源部１８においてアナログの演奏音信号に変換された後、音声処理部１９へ送られ、マイク２３を介して入力される利用者の歌唱音信号と適度な割合でミキシングされる。そして、このミキシングされた歌唱音信号と演奏音信号はアンプ２０へ送られて電気的に増幅される。さらに、アンプ２０からスピーカ２２に出力され音声及び演奏音となってスピーカ２２から外部へ出力される。

一方、映像処理部１１は、ＣＰＵ１４の制御の下、ＣＰＵ１４によってハードディスク１３から読み出された画像情報（歌詞データ）に基づいて歌詞映像の再生を行うものである。ＣＰＵ１４によりハードディスク１３から読み出された画像情報（背景画データ）は、ＭＰＥＧデコーダ１２によって背景映像として再生された後に映像処理部１１によって歌詞映像と合成され、モニタ２６へ出力される。これによって、モニタ２６の画面に背景映像とともに歌詞テロップが表示される。

なお、これらＣＰＵ１４が実行する処理のためのソフトウェアもハードディスク１３に格納されている。
このような構成のため、利用者は、モニタ２６に表示される歌詞テロップを参照しながら、スピーカ２２より流れるカラオケ演奏にあわせ、マイク２３を使って歌唱できるようになっている。

［通信カラオケ装置の動作等］
ところで、上述したように、ＨＤＤ１３にはコンテンツデータとしての楽曲データが記憶されているのであるが、本実施例では、その楽曲データを所定の価値分類識別情報に基づいて予め価値分類判断をした上で、その結果に応じた記憶領域に格納するようにしている。その点について説明する。

まず、図２を参照して、配信される楽曲データの構造を説明する。
楽曲データは、１曲につき２つのファイルで構成されている。１つは、楽曲ヘッダファイルであり、楽曲に関する管理情報が記されている。この管理情報の中に「価値分類識別情報」としてのコンテンツ区分の項がある。このヘッダファイルは、１キロバイトに満たないような相対的に小さなファイルであり、楽曲の実データはもう１つのファイルに収められている。その実データファイル名を示す項がヘッダファイルの中にあり、これによって２つ目のファイルとの連携を示すことができ、その効果として、ＭＩＤＩ形式やＭＰＥＧビデオ形式などの、複数のデータ再生様式に対応している。つまり、楽曲再生においては、まずヘッダファイルを参照し、そこから実データファイルを呼び出し、ファイルの形式に応じた再生様式のソフトウェアを作動させることとなる。なお、楽曲再生時の動作の詳細は省略する。

次に、ＨＤＤ１３内に多数の楽曲ファイルを収容される際の手法を、図３を参照して説明する。図３（ａ）はファイルシステムのディレクトリ構成を示しており、図３（ｂ）〜（ｄ）は各ディレクトリの格納ファイル事例を示している。

理論上、例えば１００万のコンテンツの収容を行うために、上位３桁をディレクトリで区分し、下位３桁については、曲番号をファイル名とする２つで１組の楽曲データファイルを格納している。収容するファイルの形式は図３に示す通りである。

また、本実施例の場合には、general / broadband / charge という最上位の階層がも
う一段あり、これによってコンテンツの区分毎の分類格納を行っている。つまり、generalディレクトリが通常楽曲用、broadbandディレクトリがブロードバンド楽曲用、chargeディレクトリが契約楽曲用のディレクトリである。ここで、通常楽曲とは、これまでの通信カラオケで主流であったＭＩＤＩ楽曲を意味する。また、ブロードバンド楽曲とは、ＭＰＥＧビデオデータを含み、従来のＭＩＤＩ楽曲の１００倍〜１０００倍といった大きなサイズのカラオケデータであり、通信時間の観点から一般的にブロードバンド通信でしか配信できないような大容量且つ付加価値の高い楽曲である。また、契約楽曲は、カラオケサービスの毎月の情報通信料金に追加の料金を徴収する契約を結ぶことで配信されるようになる、付加価値の大きい楽曲である。これも、ブロードバンドでしか配信できない大容量のＭＰＥＧビデオデータを含むカラオケデータとして構成することが考えられる。

コンテンツ区分に関して、例えばこうした分類を行わずに、通常のコンテンツもブロードバンドのコンテンツも１つのディレクトリ以下に収納した場合は、全てのファイルの中身をいちいち読み出して判別する処理をＣＰＵ１４が行わなければコンテンツの区分毎に楽曲数をカウントし直すことができない。それに対して、図３に示すように分別格納しておけば、分別格納してあるためヘッダファイルは必ず１曲につき１つとなり、各ディレクトリ以下のヘッダファイルの総数をカウントするだけで区分毎の楽曲数を容易に計測することができる。

このようにして計測した区分毎の楽曲数は、操作パネル１０の表示パネル１０ｂやモニタ２４に出力して表示させることができる。ここで、表示を行う場合の２つの具体例について説明する。

［表示例１］
この表示例１の場合は、通信カラオケ装置１を起動した際に上述したように区分毎の楽曲数を計測し、その結果を、図４（ｂ）に示すように操作パネル１０の表示パネル１０ｂに表示させるものである。なお、図４（ａ）は比較のため従来例を示した。

図４（ｂ）に示すように、まず通常楽曲の総数を表示する。この場合、単に総数を示す「５１０００」という数字のみを表示する。その表示を３秒間継続した後、次はブロードバンド楽曲の総数を表示する。この場合は記号と数字で表示する。具体的には、ブロードバンド楽曲であることを示す「ｂ」という英字とその総数である「２００」という数字を表示する。なお、６桁の７セグメントＬＥＤの最も左の桁に「ｂ」を表示し、数字は右詰で表示している。その表示をやはり３秒間継続した後、次は契約楽曲の総数を表示する。この場合も記号と数字で表示する。具体的には、契約楽曲であることを示す「ｃ」という英字とその総数である「３４」という数字を表示する。これらの表示は所定の起動処理中に実行するものであり、起動処理が終了すると、この表示パネル１０ｂには何も表示されなくなる。

このように、図４（ａ）に示す従来例では単に楽曲の総数である「５１２３４」が表示されるだけであったのに対し、図４（ｂ）に示す本実施例では通常楽曲→ブロードバンド楽曲→契約楽曲の順番でそれぞれのデータ総数が表示される。そのため、その順番で表示されること、あるいは記号無しが通常楽曲、記号ｂが頭に付くのがブロードバンド楽曲、記号ｃが頭に付くのが契約楽曲であることを知っていれば、管理者は各区分の楽曲数を容易に把握できる。

［表示例２］
この表示例２は、例えば任意のタイミングで操作パネル１０のスイッチ群１０ａ等によって所定の操作をした場合に、上述したように区分毎の楽曲数を計測し、その結果を、図５（ｂ）に示すようにモニタ２４に一覧表示させるものである。これは例えば環境設定と呼ばれる設定変更／保守用のオペレーション画面において所定の項目を選択操作するというように、通常のカラオケ利用者（カラオケを歌唱して楽しむ者）は知らない特殊な操作をして実行するよう構成することが好ましい。なお、図５（ａ）は比較のため従来例を示した。

図５（ｂ）に示すように、この場合は、「通常楽曲数：５１０００」、「ブロードバンド楽曲数：２００」、「契約楽曲数：３４」というように各区分を示す名称とその区分に属する楽曲数を一覧表示し、さらにそれらを合計した「収容総曲数：５１２３０曲」という内容も表示している。なお、最終配信日時も表示され、さらに「取り消しキーでカラオケに戻ります」というガイダンスも表示している。なお、最終配信日時を得る手法については後述する。

図５（ａ）に示す従来例では「収容総曲数：５１２３０曲」しか表示されていなかったのに対し、本実施例の場合は各区分のデータ総数まで一覧表示されるので、各区分の楽曲数を容易且つより明確に把握できる。また、表示例１の場合は通信カラオケ装置１の起動時に自動的に表示されるものであったが、この表示例２の場合は、所定の操作をすれば任意のタイミングで表示させることができる。したがって、通信カラオケ装置１の管理者が任意のタイミングで現在の楽曲の蓄積状況を知りたい場合に有効な対処である。また、最後に配信を受けた年月日なども表示されるため、配信システムの稼働が順調であることの確認にもなる。

なお、もちろん、装置起動時にモニタ２４に一覧表示させることも可能であるし、所定の操作を受け付けた場合に表示パネル１０ｂに表示させるようにしても構わないが、現実的には、上記表示例１、表示例２のような手法が適切である。

それでは、次に、配信によるコンテンツデータの受信時の動作に関し、図６のフローチャートを参照して説明する。
１日に１回の定常的なトリガ（所定の通信時間（時刻）が到来）によって本処理が開始され、まず、配信センタ５０との接続を行う（Ｓ１０１）。そして、未受領の配信データが尽きるまでのループ処理（Ｓ１０２〜Ｓ１０９）へ移行する。

ループ処理が開始すると、配信センタ５０からコンテンツデータを受信し、テンポラリ領域に一時保管する（Ｓ１０３）。そして、受信したコンテンツデータのアーカイブを解凍してデータファイルを取り出す（Ｓ１０４）。なお、ここでは幾つかのファイルを１つにまとめたアーカイブ形式としている。続くＳ１０５では、データファイルにおけるヘッダファイルのコンテンツ区分項を参照し（図２参照）、どのコンテンツ区分に属するか判定する。そして、コンテンツ区分が０であれば通常楽曲であるため、そのデータファイルを通常楽曲用ディレクトリ（図３のgeneralディレクトリ）に移動する（Ｓ１０６）。同
様に、コンテンツ区分が１であればブロードバンド楽曲であるため、そのデータファイルをブロードバンド楽曲用ディレクトリ（図３のbroadbandディレクトリ）に移動し（Ｓ１
０７）、また、コンテンツ区分が２であれば契約楽曲であるため、そのデータファイルを契約楽曲用ディレクトリ（図３のchargeディレクトリ）に移動する（Ｓ１０８）。

そして、未受領の配信データがなくなると、本ループ処理（Ｓ１０２〜Ｓ１０９）を終了し、コンテンツデータの最終配信日時を更新する（Ｓ１０９）。そして、配信センタ５０との接続を切断し（Ｓ１１０）、その日の通信処理が終了する。

なお、Ｓ１０９にて更新された最終配信日時が図５を参照して説明した表示例２において表示されることとなる。
次に、区分化されたコンテンツの計数処理について図７のフローチャートを参照して説明する。

上記表示例１（図４参照）の場合であれば操作パネル１０の表示パネル１０ｂにおける表示、表示例２（図５参照）の場合であればモニタ２４における表示（ＴＶ表示）による曲数表示のタイミングにおいて本処理が開始する。

まずは、通常楽曲数、ブロードバンド楽曲数、契約楽曲数の３種の値を初期化する（Ｓ２０１）。
そして、所定の階層ディレクトリ以下のファイル全てについて、再帰的な処理ループ（Ｓ２０２〜Ｓ２０６）へ移行する。

再帰的なループ処理が開始すると、ファイルリストを１つ読出し（Ｓ２０３）、それが、headファイルか否か判定する（Ｓ２０４）。なお、ファイル図３（ｂ）〜（ｄ）に示す格納ファイル事例からも分かるように、拡張子としてhead・midi・mpeg等があるため、その拡張しに基づいてheadファイルか否か判定する。そしてheadファイルであれば（Ｓ２０４：ＹＥＳ）、楽曲数を１増加させる（Ｓ２０５）。このような処理を、まず/general（通常楽曲用）ディレクトリに対して実行し、ディレクトリリストが尽きたら、次に/broadbandディレクトリについて上述したＳ２０２〜Ｓ２０６と同様の再帰的なループ処理を実行する（Ｓ２０７）。そして、/broadbandディレクトリについてディレクトリリストが尽きたら、次に/chargeディレクトリについて上述したＳ２０２〜Ｓ２０６と同様の再帰的
なループ処理を実行する（Ｓ２０８）。このようにして３個のディレクトリについての処理が終了すれば、通常楽曲数、ブロードバンド楽曲数、契約楽曲数のそれぞれが計測でき、計数処理が完了する。この処理で得られた結果（３種の値）が、上述した表示例１や表示例２に示すように表示されることとなる。

なお、本実施例においてはＨＤＤ１３が「コンテンツデータ記憶手段」に相当し、ＣＰＵ１４、ＭＩＤＩ音源部１８及びＭＰＥＧデコーダ１２が「再生手段」に相当する。また、ＣＰＵ１４は「判断手段」、「計測手段」、「出力手段」、「制御手段」にも相当する。さらに、操作パネル１０の表示パネル１０ｂやモニタ２４が「表示装置」に相当し、操作パネル１０のスイッチ類１０ａが「指示受付手段」に相当する。

［実施例の効果］
本実施例の通信カラオケ装置１によれば、図４（ｂ）に示す表示例１、あるいは図５（ｂ）に示す表示例２のように、通常楽曲・ブロードバンド楽曲・契約楽曲という区分毎に蓄積されている曲数が表示される。これら３つの区分のデータは、カラオケデータとしては同じであるが、「１曲の価値」が大きく違うものである。特に、通常楽曲とブロードバンド楽曲あるいは契約楽曲については、その差が大きく、後者の方が付加価値が高い。したがって、このように価値の異なるコンテンツデータが併存して蓄積されている場合であっても、本実施例によれば、その価値の違いに応じたコンテンツデータの蓄積実態を適切に把握できる。

また、表示例１の場合は、通信カラオケ装置１を起動した際に自動的に表示されるので、管理者としては特段の操作をしなくてもよく便利である。一方、表示例２の場合は、所定の操作をすれば任意のタイミングで表示させることができるため、管理者は自分が知りたい任意タイミングで現在の楽曲の蓄積状況を知ることができる。

そして、本実施例の場合は、配信センタ５０から配信された楽曲データを、楽曲ヘッダファイルに含まれるコンテンツ区分情報に基づいて予め価値分類判断をした上で、その結果に応じたディレクトリに格納し、表示の必要が生じた場合に、各ディレクトリ内に収容されている楽曲データの総数を計測するようにした。データ格納時には価値分類判断が必要となるが、データ総数計測時には判断が不要となり、計測結果の出力が早期に実現できる。

［別実施例］
（１）上記実施例では、区分毎の楽曲数を操作パネル１０の表示パネル１０ｂやモニタ２４に表示させるようにしたが、例えば印刷装置へ出力してプリンタアウトさせても良い。このようにしても、管理者は価値の違いに応じたコンテンツデータの蓄積実態を適切に把握できる。

（２）上記実施例では、配信センタ５０から配信された楽曲データを、楽曲ヘッダファイルに含まれるコンテンツ区分情報に基づいて予め価値分類判断をした上で、その結果に応じたディレクトリに格納し、表示の必要が生じた場合に、各ディレクトリ内に収容されている楽曲データの総数を計測するようにした。

しかしながら、価値分類判断に関しては、上記コンテンツ区分情報のように配信側でデータ中に含ませた特別な情報によらず、例えばデータの形式（例えばＭＰＥＧで収録されているか、ＭＩＤＩで収録されているかなど）やデータ容量などに基づいて判断することも可能である。つまり、ファイル拡張子やデータサイズ等によって判断する。また、例えば配信センタ５０から配信された楽曲データの受信時には特に区分毎のディレクトリに分けることなく区別せずに記憶しておき、表示の必要が生じた場合に初めて計数処理を実行するようにしてもよい。

データ容量に基づき、表示の必要が生じた場合に初めて計数処理を実行する場合の処理例を図８のフローチャートを参照して説明する。
通常楽曲数、ブロードバンド楽曲数、契約楽曲数の３種の値を初期化し（Ｓ３０１）、その後、contentsディレクトリのファイル全てについて、再帰的な処理ループ（Ｓ３０２〜Ｓ３０７）へ移行する。

再帰的なループ処理が開始すると、ファイルリストを１つ読出し（Ｓ３０３）、そのデータ容量が５メガバイト以上か否か判定する（Ｓ３０４）。そして、５メガバイト以上であれば（Ｓ３０４：ＹＥＳ）、ブロードバンド楽曲数を１増加させる（Ｓ３０５）。一方、５メガバイト未満であれば（Ｓ３０４：ＮＯ）、通常楽曲数を１増加させる（Ｓ３０６）。このような処理をディレクトリリストが尽きるまで再帰的に実行し、ディレクトリリストが尽きたら（Ｓ３０７）、本曲計数処理を終了する。

なお、この場合は、データ容量のみで判断しているため、容量の小さい通常楽曲数と、容量の大きいブロードバンド楽曲数の２種にしか区分分けはしていない。
（３）上記実施例では、通常楽曲、ブロードバンド楽曲、契約楽曲という３種類の区分をしたが、この区分の仕方は一例であり、実情に応じて適宜設定すればよい。例えば通常楽曲をさらに細分化したりすることも可能である。

（４）上記実施例では、いわゆる通信カラオケシステムとして、配信センタ５０から通信カラオケ装置１へ楽曲データを配信するようにしたが、例えばＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ等の記憶媒体を介して楽曲データの更新・追加を行う場合であっても同様に実現でき、同様の効果を得ることができる。さらには、通信による配信との併用も考えられる。

また、カラオケ装置以外であっても、価値の異なるコンテンツデータを蓄積し、その蓄積実態を適切に把握したいという要望がある装置であれば、同様に適用できる。例えばゲーム装置などでも適用可能である。また、価値に応じて区分の仕方もコンテンツに応じて適宜設定可能である。

実施例の通信カラオケ装置１の構成及び稼働時の周辺機器の構成を示すブロック図である。 ＨＤＤ１３内部に収録される楽曲データの説明図である。 （ａ）はファイルシステムのディレクトリ構成の説明図、（ｂ）〜（ｄ）は各ディレクトリの格納ファイル事例の説明図である。 区分毎の楽曲数の表示例１の説明図である。 区分毎の楽曲数の表示例２の説明図である。 配信によるコンテンツデータ受信時の動作を示すフローチャートである 区分化されたコンテンツの計数処理を示すフローチャートである。 データ容量に基づくコンテンツ計数処理を示すフローチャートである。

符号の説明

１…通信カラオケ装置、１０…操作パネル、１０ａ…スイッチ類、１０ｂ…表示パネル、１１…映像処理部、１２…ＭＰＥＧＥデコーダ、１３…ハードディスク、１４…ＣＰＵ、１５…メモリ、１６…ＬＡＮインターフェース、１８…ＭＩＤＩ音源部、１９…音声処理部、２０…アンプ、２２…スピーカ、２３…マイクロフォン、２５…ＬＡＮハブ装置、２６…モニタ、２７…ＡＤＳＬモデム、３０…インターネット、５０…配信センタ。

Claims (5)

1. コンテンツデータを記憶しておくコンテンツデータ記憶手段と、
   前記コンテンツデータ記憶手段に記憶されているコンテンツデータに基づいてコンテンツ再生を行う再生手段と、
   前記コンテンツデータに付加された価値分類識別情報、前記コンテンツデータのデータ特性、前記コンテンツデータ記憶手段中の区分された記憶領域のどこに記憶されているか、の少なくとも何れかに基づいて前記コンテンツデータの価値分類を判断する判断手段と、
   前記コンテンツデータ記憶手段に記憶されているコンテンツデータに関して、その価値分類毎にデータ総数を計測する計測手段と、
   前記判断手段によって判断された複数の価値分類毎に、前記計測手段によって計測されたデータ総数を出力する出力手段と、を備えるコンテンツデータ再生装置であって、
   前記出力手段は、
   当該再生装置の起動時に、前記複数の価値分類毎のデータ総数を、価値分類を示す識別記号と数字の組み合わせによって、前記複数の価値分類毎のデータ総数を一覧表示させることのできない表示装置へ所定時間毎に順番に表示させ、最後の順番のデータ総数の表示が終了したら、非表示にすること
   を特徴とするコンテンツデータ再生装置。
2. 請求項１に記載のコンテンツデータ再生装置において、
   さらに、各種指示を受け付ける指示受付手段を備え、
   前記出力手段は、
   前記指示受付手段によって前記価値分類毎のデータ総数の表示指示を受け付けた場合、前記複数の価値分類毎のデータ総数を、価値分類を示す識別記号と数字の組み合わせによって表示装置へ所定時間毎に順番に表示させ、最後の順番のデータ総数の表示が終了したら、非表示にすること
   を特徴とするコンテンツデータ再生装置。
3. 請求項１または２に記載のコンテンツデータ再生装置において、
   前記コンテンツデータに付加された価値分類識別情報に基づいて価値分類が判断されたコンテンツデータを、その価値分類に対応する前記コンテンツデータ記憶手段中の記憶領域に格納する制御手段を備えること、
   を特徴とするコンテンツデータ再生装置。
4. 請求項１または２に記載のコンテンツデータ再生装置における前記判断手段、計測手段及び出力手段としてコンピュータを機能させるためのプログラム。
5. 請求項３に記載のコンテンツデータ再生装置における前記判断手段、計測手段、出力手段及び制御手段としてコンピュータを機能させるためのプログラム。

Images