カラオケ端末
【課題】カラオケに用いられる楽曲データのダウンロードが中断された場合であっても、当該楽曲データのダウンロードを効率的におこなうこと。
【解決手段】ダウンロード部１０２は、カラオケに用いられる楽曲データを配信するサーバ装置１４０との通信をおこなうことにより、当該サーバ装置１４０から楽曲データをダウンロードして楽曲データ格納部１０４へ格納させておく。ダウンロード部１０２は、一の楽曲データのダウンロードが中断された場合、当該一の楽曲データのうちの既に受信した部分を楽曲データ格納部１０４へ格納させておき、中断された当該ダウンロードが再開された場合、当該一の楽曲データのうちの、受信した部分に続く残りの部分を受信し、当該残りの部分を、既に格納されている受信した部分に関連づけて楽曲データ格納部１０４に格納させる。
【解決手段】ダウンロード部１０２は、カラオケに用いられる楽曲データを配信するサーバ装置１４０との通信をおこなうことにより、当該サーバ装置１４０から楽曲データをダウンロードして楽曲データ格納部１０４へ格納させておく。ダウンロード部１０２は、一の楽曲データのダウンロードが中断された場合、当該一の楽曲データのうちの既に受信した部分を楽曲データ格納部１０４へ格納させておき、中断された当該ダウンロードが再開された場合、当該一の楽曲データのうちの、受信した部分に続く残りの部分を受信し、当該残りの部分を、既に格納されている受信した部分に関連づけて楽曲データ格納部１０４に格納させる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、カラオケ端末に関する。
【背景技術】
【０００２】
特許文献１には、カラオケ用の楽曲データをサーバ装置から各カラオケ端末に配信する通信カラオケシステムが開示されている。このような通信カラオケシステムで扱われる楽曲データの平均的なファイルサイズは、たとえばＭＩＤＩ（Musical Instrument Digital Interface）データであれば、１５０Ｋｂｙｔｅ程度である。各カラオケ端末は、この程度のファイルサイズの楽曲データであれば、比較的短い時間で当該楽曲データをサーバ装置からダウンロードすることができる。従って、ＭＩＤＩデータを用いた従来の通信カラオケシステムでは、ファイルの受信途中で通信が途切れるようなことがあった場合には、カラオケ装置は、途中まで受信したファイルを一度削除して、通信再開後にファイルを受信し直していた。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開平８−２６３０７８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
一方、近年では通信回線のブロードバンド化に伴い、楽曲データが高品質なものとなることで、楽曲データのデータサイズの巨大化を招いており、中にはデータサイズが１３０Ｍｂｙｔｅを超える楽曲データもある。このようにデータサイズの大きな楽曲データの場合、通信再開後にファイルを受信し直すのは効率が悪い。そこで、本発明は、カラオケに用いられる楽曲データのダウンロードが中断された場合であっても、当該楽曲データのダウンロードを効率的におこなうことを目的とする。
【課題を解決するための手段】
【０００５】
上記課題を解決するため、本発明は、データを格納する格納部と、カラオケに用いられる楽曲データを配信する情報処理装置との通信をおこなうことにより、当該情報処理装置から楽曲データをダウンロードして前記格納部に格納させるダウンロード部とを備え、前記ダウンロード部は、一の前記楽曲データのダウンロードが中断された場合、当該一の楽曲データのうちの既に受信した部分を前記格納部へ格納させておき、中断された当該ダウンロードが再開された場合、当該一の楽曲データのうちの、前記受信した部分に続く残りの部分を受信し、当該残りの部分を、既に格納されている前記受信した部分に関連づけて前記格納部に格納させることを特徴とするカラオケ端末を提供する。
【発明の効果】
【０００６】
本発明のカラオケ端末によれば、一の楽曲データのダウンロードが中断され、当該ダウンロードが再開されると、当該一の楽曲データの楽曲データの先頭から受信しなおすのではなく、当該一の楽曲データの受信済みの部分に続く残りの部分を受信するので、ダウンロード再開後におけるデータ受信量を抑えることができ、当該一の楽曲データのダウンロードを効率的におこなうことができる。
【図面の簡単な説明】
【０００７】
【図１】本実施形態に係る通信カラオケシステム１０の全体構成を示す。
【図２】カラオケ端末１００の機能構成を示す。
【図３】カラオケ端末１００による処理の手順を示す。
【図４】楽曲データ格納部１０４に格納されている楽曲データの一例を示す。
【図５】楽曲データ格納部１０４に格納されている楽曲データの一例を示す。
【図６】カラオケ端末１００のハードウェア構成の一例を示す。
【発明を実施するための形態】
【０００８】
図１は、本実施形態に係る通信カラオケシステム１０の全体構成を示す。通信カラオケシステム１０は、カラオケ端末１００と、サーバ装置１４０とを備える。カラオケ端末１００は、ユーザからの要求に従ってカラオケ用の楽曲データ（以下、単に「楽曲データ」という。）を再生する装置である。カラオケ端末１００およびサーバ装置１４０のそれぞれは、ネットワーク１２０に接続されている。ネットワーク１２０はＬＡＮ（Local Area Network）やインターネットであり、カラオケ端末１００とサーバ装置１４０との間におけるデータ通信が行われる通信網である。サーバ装置１４０は、楽曲データを配信する情報処理装置である。サーバ装置１４０は、その内部あるいは外部に備えたＨＤＤ（Hard Disk Drive）等の記憶手段に楽曲データを格納しており、カラオケ端末１００からの要求に従って、あるいは定期的に、ネットワーク１２０経由でこの楽曲データをカラオケ端末１００に配信する。ここで、楽曲データとは、カラオケに用いられる楽曲に関する楽音データと映像データとが組み合わされたものを示す。すなわち、楽曲データは、主旋律の歌声が存在せず伴奏やコーラスで構成されたいわゆるカラオケバージョンの楽曲に関する音声データと、この楽曲の歌詞や歌詞の背景に表示する映像からなる映像データとから成り立っている。通信カラオケシステム１０には、複数のカラオケ端末１００が存在してもよく、複数のサーバ装置１４０が存在してもよい。
【０００９】
図２は、カラオケ端末１００の機能構成を示す。ここでは、カラオケ端末１００が備える機能のうち、本実施形態の説明に必要となる、楽曲データをダウンロードして格納することに関する機能と、格納された楽曲データを再生することに関する機能について説明する。カラオケ端末１００は、ダウンロード部１０２、楽曲データ格納部１０４、指示入力部１０５、楽曲データ再生部１０６、表示部１０８、発音部１１０、収音部１１２、および音声合成部１１４を備える。
【００１０】
ダウンロード部１０２は、サーバ装置１４０との通信をおこなうことにより、サーバ装置１４０から楽曲データをダウンロードする。楽曲データ格納部１０４は、ダウンロード部１０２によってサーバ装置１４０からダウンロードされた楽曲データを格納する。楽曲データ再生部１０６は、楽曲データ格納部１０４に格納されている楽曲データを再生する。
【００１１】
このカラオケ端末１００の利用時には、ユーザに対し、再生可能な楽曲データの曲目リストが提供される。この曲目リストには、複数の楽曲データのそれぞれについて、曲名、歌手名、楽曲データＩＤなどが示されている。そして、カラオケ端末１００のユーザが、この曲目リストの中から所望の楽曲データを選択し、選択した楽曲データに対応付けられている楽曲データＩＤを、指示入力部１０５で入力すると、楽曲データ再生部１０６は、この楽曲データＩＤに対応付けられている楽曲データを楽曲データ格納部１０４から検索する。この楽曲データが楽曲データ格納部１０４に格納されていれば、楽曲データ再生部１０６が、この楽曲データを楽曲データ格納部１０４から取得し、これを再生する。一方、この楽曲データが楽曲データ格納部１０４に格納されていなければ、ダウンロード部１０２が、この楽曲データＩＤに対応付けられている楽曲データをサーバ装置１４０からダウンロードする。楽曲データ格納部１０４には、ダウンロードされた楽曲データが、当該楽曲データの楽曲データＩＤと対応づけて格納される。このようにして、楽曲データのダウンロードが完了すると、楽曲データ再生部１０６が、ダウンロードされた楽曲データを楽曲データ格納部１０４から取得し、これを再生する。
【００１２】
このようにして楽曲データが再生されると、表示部１０８が、この楽曲データに含まれる映像データに応じた映像を表示する。これと同時に、発音部１１０が、この楽曲データに含まれる楽音データに応じた音を発する。さらに、楽曲データの再生中に、カラオケ端末１００のユーザが発した音声を収音部１１２が収集すると、音声合成部１１４が、収集部１１２によって収集された音声を示す音声データと、再生部１０６によって再生された楽曲データに含まれる楽音データとを合成して、これを発音部１１０へ供給する。これにより、発音部１１０からは、カラオケ端末１００のユーザが発した音声と、楽曲データに含まれる楽音とが重ねられて、発せられる。
【００１３】
図３は、カラオケ端末１００による処理の手順を示す。まず、カラオケ端末１００のユーザが、曲目リストの中から所望の楽曲データ（以下、「当該楽曲データ」という。）を選択し、当該楽曲データに対応付けられている楽曲データＩＤを、指示入力部１０５で入力する（ステップＳ３０２）。これに応じて、楽曲データ再生部１０６が、当該楽曲データが楽曲データ格納部１０４に格納されているか否かを判断する（ステップＳ３０４）。
【００１４】
ステップＳ３０４において、「当該楽曲データが楽曲データ格納部１０４に格納されている」と判断された場合（ステップＳ３０４：ＹＥＳ）、楽曲データ再生部１０６が、当該楽曲データを楽曲データ格納部１０４から取得し、これを再生する（ステップＳ３２０）。
【００１５】
一方、ステップＳ３０４において、「当該楽曲データが楽曲データ格納部１０４に格納されてない」と判断された場合（ステップＳ３０４：ＮＯ）、ダウンロード部１０２が、サーバ装置１４０との通信をおこなうことにより、サーバ装置１４０からの当該楽曲データのダウンロードを開始する（ステップＳ３０６）。具体的には、ダウンロード部１０２が、当該楽曲データの楽曲データＩＤをサーバ装置１４０に通知し、この通知に応じて、サーバ装置１４０が当該楽曲データＩＤに対応する楽曲データを記憶手段から読み出してカラオケ端末１００に送信する。ダウンロード部１０２はこれを受信する。
【００１６】
その後、ダウンロード部１０２は、当該楽曲データのダウンロードの最中に、当該ダウンロードが中断されなければ（ステップＳ３０８：ＮＯ）、当該楽曲データを受信し（ステップＳ３１２）、受信した当該楽曲データを、再生不可能な一時ファイルとして楽曲データ格納部１０４に格納させる（ステップＳ３１４）。そして、ダウンロード部１０２は、当該楽曲データの全部を受信していなければ（ステップＳ３１６：ＮＯ）、当該楽曲データの全部を受信するまで、ステップＳ３１２およびステップＳ３１４を繰り返し、その都度、受信した当該楽曲データを楽曲データ格納部１０４に格納されている一時ファイルに加えていく。
【００１７】
ダウンロード部１０２が、当該楽曲データの全部を受信して楽曲データ格納部１０４に格納させると（ステップＳ３１６：ＹＥＳ）、ダウンロード部１０２は、楽曲データ格納部１０４に格納されている一時ファイルを、再生可能な完全ファイルとして有効化する（ステップＳ３１８）。そして、楽曲データ再生部１０６が、当該楽曲データを楽曲データ格納部１０４から取得し、これを再生する（ステップＳ３２０）。
【００１８】
上記において、当該楽曲データのダウンロードの最中に、当該ダウンロードが中断される場合がある（ステップＳ３０８：ＹＥＳ）。例えば、サーバ装置１４０とカラオケ端末１００との間の通信環境が悪化した場合とか、サーバ装置１４０またはカラオケ端末１００に処理の異常が発生したような場合である。この場合、ダウンロード部１０２は、当該楽曲データのうちの、当該ダウンロードが中断されるまでに受信した部分を、破棄してしまうのではなく、再生不可能な一時ファイルとして楽曲データ格納部１０４に格納させたままにしておく。そして、ダウンロード部１０２は、サーバ装置１４０に対して要求を送信するなどして、当該ダウンロードの再開を試みる（ステップＳ３１０）、この試みは、タイムアウトになるまで繰り返される（ステップＳ３１０：ＮＯ）。当該ダウンロードが再開できた場合には（ステップＳ３１０：ＹＥＳ）、ダウンロード部１０２は、当該楽曲データのうちの、既に受信した部分、すなわち、楽曲データ格納部１０４に格納しておいた部分に続く、残りの部分のダウンロードを開始し（ステップＳ３１１）、当該残りの部分の全部を受信するまで、ステップＳ３１２およびステップＳ３１４を繰り返し、その都度、受信した当該残りの部分を楽曲データ格納部１０４に格納されている一時ファイルに加えていく。このように同一の一時ファイルに残りの部分が追加されるので、この残りの部分が、既に格納されている部分に関連づけて楽曲データ格納部１０４に格納されることになる。
【００１９】
ここで、サーバ装置１４０においては、ダウンロードの再開要求をカラオケ端末１００から受け取ったとしても、どの楽曲データのどの位置からの配信を再開すればよいか判断できない場合がある。そこで、本実施形態のカラオケ端末１００は、ダウンロードの再開をサーバ装置１４０へ要求するとともに、当該楽曲データの楽曲データＩＤ、および当該楽曲データのうちの楽曲データ格納部１０４に格納された受信済みの部分のデータサイズ（Ｂｙｔｅ数）、すなわち一時ファイルのデータサイズをサーバ装置１４０へ通知する。たとえば、ダウンロード済みの部分のデータサイズが、「１５４３００ＫＢｙｔｅ」の場合、カラオケ端末１００は、当該楽曲データの楽曲データＩＤと、受信済みの部分のデータサイズ「１５４３００ＫＢｙｔｅ」とを、サーバ装置１４０へ通知する。これにより、サーバ装置１４０は、通知された楽曲データＩＤに基づいて、配信を再開する楽曲データを特定し、さらに、その楽曲データにおいて当該データの先頭からデータサイズ「１５４３００ＫＢｙｔｅ」に相当する位置が配信を再開する位置であることを特定することができる。
【００２０】
図４および図５は、楽曲データ格納部１０４に格納されている楽曲データの管理テーブル４００の一例を示す。図４および図５に示す管理テーブル４００は、楽曲データ格納部１０４に格納されているデータベース・テーブルである。この管理テーブル４００には、各々の楽曲データに関する情報、例えば各楽曲データの楽曲データＩＤ、ファイル名、保存日時、および再生回数が記述されている。ここで、各々の楽曲データのファイル名には、拡張子が付与されている。複数の楽曲データのファイルのうち、ファイル名に拡張子「．ｓｏｎｇ」が付与されているものは、再生可能な完全ファイルであることを示す。一方、ファイル名に拡張子「．ｔｍｐ」が付与されているものは、ダウンロードの途中であり、再生不可能な一時ファイルであることを示す。たとえば、図４に示すテーブル４００において、楽曲データＩＤが「１０２５−３１」の楽曲データのファイル名は、「１０２５−３１．ｔｍｐ」となっている。これは、この楽曲データのダウンロードが途中であり、このファイルが再生不可能な一時ファイルであることを示している。この楽曲データのダウンロードが完了すると、再生不可能な一時ファイルが再生可能な完全ファイルに有効化され、これにより、図５に示すように、この楽曲データのファイル名は、「１０２５−３１．ｔｍｐ」から「１０２５−３１．ｓｏｎｇ」となる。
【００２１】
図６は、カラオケ端末１００のハードウェア構成の一例を示す。カラオケ端末１００は、ＣＰＵ１５０５、ＲＯＭ１５１０、ＲＡＭ１５２０、ＨＤ（ハードディスク）ドライブ１５２５、通信インターフェース１５３０、外部メモリドライブ１５４０、外部メモリ１５４２、操作パネル１５５０、ディスプレイ１５６０、スピーカ１５７０、およびマイク１５８０を備える。
【００２２】
ＲＯＭ１５１０、ＲＡＭ１５２０、およびＨＤドライブ１５２５は、各種データおよび各種プログラムを格納する。ＣＰＵ１５０５は、ＲＯＭ１５１０、ＲＡＭ１５２０、ＨＤドライブ１５２５、または外部メモリ１５４２に格納されたプログラムを実行することで、各種データ処理および各種ハードウェア制御をおこなう。
【００２３】
通信インターフェース１５３０は、ネットワーク１２０に接続し、ネットワーク１２０を介して外部との通信をおこなう。外部メモリドライブ１５４０は、外部メモリ１５４２に接続し、外部メモリ１５４２に対するデータの送受信をおこなう。外部メモリ１５４２としては、たとえば、メモリカードが挙げられる。
【００２４】
操作パネル１５５０には、キーボード、ボタン、タッチパネルなどの入力デバイスが設けられており、これらの入力デバイスがユーザによって操作されることにより、当該カラオケ端末１００に対し、各種情報を入力する。ディスプレイ１５６０は、映像データに応じた映像を表示する。スピーカ１５７０は、音声データに応じた音を発する。マイク１５８０は、音を収集し、収集した音に応じた音声データを生成する。
【００２５】
ＣＰＵ１５０５が実行するプログラムは、たとえば、コンピュータ読み取り可能な記録媒体に格納されてカラオケ端末１００に提供され、カラオケ端末１００に格納される。ＣＰＵ１５０５が実行するプログラムは、カラオケ端末１００に予め格納されていてもよい。また、ＣＰＵ１５０５が実行するプログラムは、外部装置から通信ネットワークを介してカラオケ端末１００に提供され、カラオケ端末１００に格納されてもよい。
【００２６】
たとえば、コンピュータであるカラオケ端末１００は、ＣＰＵ１５０５が、上記プログラムを実行し、通信インターフェース１５３０を制御することにより、図２に示したダウンロード部１０２として機能する。また、カラオケ端末１００は、ＲＯＭ１５１０、ＲＡＭ１５２０、ＨＤドライブ１５２５、または外部メモリ１５４２が、図２に示した楽曲データ格納部１０４として機能する。また、カラオケ端末１００は、ＣＰＵ１５０５が、上記プログラムを実行することにより、図２に示した楽曲データ再生部１０６および音声合成部１１４として機能する。また、カラオケ端末１００は、操作パネル１５５０が、図２に示した指示入力部１０５として機能する。また、カラオケ端末１００は、ディスプレイ１５６０が、図２に示した表示部１０８として機能する。また、カラオケ端末１００は、スピーカ１５７０が、図２に示した発音部１１０として機能する。また、カラオケ端末１００は、マイク１５８０が、図２に示した収音部１１２として機能する。
【００２７】
以上説明したように、本実施形態に係るカラオケ端末１００によれば、一の楽曲データのダウンロードが中断され、当該ダウンロードが再開されると、当該一の楽曲データの楽曲データの先頭から受信しなおすのではなく、当該一の楽曲データの受信済みの部分に続く残りの部分を受信するので、最初からダウンロードをやり直す場合と比較して、ダウンロード再開後におけるデータ受信量やダウンロード時間を抑えることができる。よって、当該一の楽曲データのダウンロードを効率的におこなうことができる。
【００２８】
＜変形例＞
上述の実施形態を以下のように変形してもよい。また、以下の各変形例を適宜組み合わせてもよい。
【００２９】
＜変形例１＞
実施形態において、ダウンロード部１０２は、ダウンロードが中断されるまでに受信した部分を、楽曲データ格納部１０４へ一時ファイルとして格納しておき、当該ダウンロードが再開すると、これに続く残りの部分をサーバ装置１４０から受信することとした。ここで、一時ファイルのデータが壊れていると、ダウンロードを再開して、全てのデータを受信し、当該一時ファイルを有効化したとしても、当該楽曲データを正常に再生することができない。そこで、ダウンロード部１０２は、受信済みの部分のデータのうちのデータが壊れていない部分以降の、残りの部分のデータを、サーバ装置１４０から受信することが望ましい。具体的には次のような仕組みとなる。
【００３０】
たとえば、ダウンロード部１０２は、受信済みの部分のデータのハッシュ値をサーバ装置１４０へ送信し、受信済みの部分のデータが壊れているか否かをサーバ装置１４０に判断させ、その判断結果をサーバ装置１４０から受け取る。そして、ダウンロード部１０２は、受信済みの部分のデータが壊れていないとの判断結果をサーバ装置１４０から受け取った場合は、受信済みの部分に続く残りの部分をサーバ装置１４０から受信する。
【００３１】
一方、ダウンロード部１０２は、受信済みの部分のデータが壊れているとの判断結果をサーバ装置１４０から受け取った場合は、判断の対象とする受信済みの部分のデータの先頭からのサイズを所定量減らしてから（つまり、受信済みの部分のデータの後ろから所定量のデータを除いてから）、上記と同様に、このサイズが減らされた後のデータのハッシュ値をサーバ装置１４０へ送信し、サイズが減らされた後のデータが壊れているか否かをサーバ装置１４０に判断させ、その判断結果をサーバ装置１４０から受け取る。そして、ダウンロード部１０２は、サイズが減らされた後のデータが壊れていないとの判断結果をサーバ装置１４０から受け取った場合は、このサイズが減らされた後のデータに続く残りの部分をサーバ装置１４０から受信する。
【００３２】
なおも、ダウンロード部１０２は、サイズが減らされた後のデータが壊れているとの判断結果をサーバ装置１４０から受け取った場合は、判断の対象とする受信済みの部分のデータの先頭からのサイズをさらに所定量減らし、上記と同様に、このサイズがさらに減らされた後のデータのハッシュ値をサーバ装置１４０へ送信し、サイズがさらに減らされた後のデータが壊れているか否かをサーバ装置１４０に判断させ、その判断結果をサーバ装置１４０から受け取る。
【００３３】
具体例を挙げると、受信済みの部分のデータのサイズが「１５０ＭＢｙｔｅ」である場合、たとえば、ダウンロード部１０２は、受信済みの部分のデータのうちの、先頭から「１５０ＭＢｙｔｅ」分のデータのハッシュ値をサーバ装置１４０へ送信し、この「１５０ＭＢｙｔｅ」分のデータが壊れているか否かをサーバ装置１４０に判断させ、その判断結果をサーバ装置１４０から受け取る。そして、ダウンロード部１０２は、この「１５０ＭＢｙｔｅ」分のデータが壊れていないとの判断結果をサーバ装置１４０から受け取った場合は、この「１５０ＭＢｙｔｅ」分のデータに続く残りの部分をサーバ装置１４０から受信する。
【００３４】
一方、ダウンロード部１０２は、「１５０ＭＢｙｔｅ」分のデータが壊れているとの判断結果をサーバ装置１４０から受け取った場合は、判断の対象とする受信済みの部分のデータのサイズを先頭から「１４０ＭＢｙｔｅ」分に減らし、上記と同様に、この「１４０ＭＢｙｔｅ」分のデータのハッシュ値をサーバ装置１４０へ送信し、この「１４０ＭＢｙｔｅ」分のデータが壊れているか否かをサーバ装置１４０に判断させ、その判断結果をサーバ装置１４０から受け取る。そして、ダウンロード部１０２は、この「１４０ＭＢｙｔｅ」分のデータが壊れていないとの判断結果をサーバ装置１４０から受け取った場合は、この「１４０ＭＢｙｔｅ」分のデータに続く残りの部分をサーバ装置１４０から受信する。
【００３５】
なおも、ダウンロード部１０２は、この「１４０ＭＢｙｔｅ」分のデータが壊れているとの判断結果をサーバ装置１４０から受け取った場合は、判断の対象とする受信済みの部分のデータのサイズを先頭から「１３０ＭＢｙｔｅ」分に減らし、上記と同様に、この「１３０ＭＢｙｔｅ」分のデータのハッシュ値をサーバ装置１４０へ送信し、この「１３０ＭＢｙｔｅ」分のデータが壊れているか否かをサーバ装置１４０に判断させ、その判断結果をサーバ装置１４０から受け取る。
【００３６】
このようにして、ダウンロード部１０２は、徐々に判断対象のデータの先頭からのサイズを減らして、このデータが壊れているか否かをサーバ装置１４０に判断させることにより、受信済みの部分のデータにおける、データが壊れていない部分に続く残りの部分からのダウンロードを再開する。これにより、ダウンロード再開後に受信するデータ量を、データが壊れている箇所を修復できる最小限のデータ量に抑えることができるため、楽曲データのダウンロードを効率的におこなうことができる。
【００３７】
＜変形例２＞
変形例１において、サーバ装置１４０は、楽曲データのヘッダー等に対して、部分的にハッシュ値を埋め込んで当該楽曲データを配信し、ダウンロード部１０２は、このハッシュ値により、データが壊れていない部分を自ら特定し、ダウンロードの再開後は、データが壊れていないと特定した部分以降の部分をサーバ装置１４０から受信するようにしてもよい。たとえば、サーバ装置１４０は、楽曲データを複数のブロックに区切って、カラオケ端末１００へ配信する。このとき、サーバ装置１４０は、各々のブロックに対して、当該ブロックに割り当てられたブロック識別情報と、当該ブロックに含まれる前記楽曲データのハッシュ値を含めて、当該楽曲データをカラオケ端末１００へ配信する。ダウンロード部１０２は、当該楽曲データをブロック単位で受信し、受信した当該楽曲データをブロック単位で、順次、楽曲データ格納部１０４へ格納する。楽曲データのダウンロードが中断された場合、楽曲データ格納部１０４へ格納されている（すなわち、受信済みの）各々のブロックに含まれる楽曲データのハッシュ値を算出して、当該ブロックについて算出した当該ハッシュ値と、当該ブロックに含まれていた前記ハッシュ値とを照合する。そして、ダウンロード部１０２は、双方のハッシュ値が一致していないブロックに含まれているブロック識別情報をサーバ装置１４０に通知し、当該ブロック以降のブロックに含まれている楽曲データを、データが壊れていない部分に続く残りの部分として、サーバ装置１４０に要求する。以上のように、変形例２では、データが壊れているブロックについては、当該ブロックを含む、当該ブロック以降のデータを新たに受信することによって、データが壊れている部分を復旧することとした。このように、データが壊れている部分の判断や、再送をブロック単位としたのは、データが壊れている部分の判断や、再送をデータサイズ単位（たとえば、Ｂｙｔｅ単位）とするよりも、既に受信済みの楽曲データと再送された楽曲データとを結合する処理などを、容易におこなうことができるからである。
【００３８】
＜変形例３＞
変形例１において、ダウンロード部１０２は、徐々に判断対象のデータの先頭からのサイズを所定量減らして、このデータが壊れているか否かをサーバ装置１４０に判断させることとしたが、判断対象のデータ量が、データが壊れている箇所を含む部分のデータ量に近づくにつれ、判断対象のデータの先頭からのサイズを減らす量を、少なくするようにしてもよい。これにより、データが壊れていない部分を特定する際の精度を高めることができるので、ダウンロード再開後に受信するデータ量を、データが壊れている箇所を修復できるより最小限のデータ量に抑えることができるため、楽曲データのダウンロードを効率的におこなうことができる。
【００３９】
たとえば、データが壊れている箇所が先頭から「１３８ＭＢｂｙｔｅ」目の箇所であり、この大体の位置をダウンロード部１０２が把握しているとする。ここで、ダウンロード部１０２が把握している箇所と、実際にデータが壊れている箇所との間に誤差があることが考えられるので、まず、ダウンロード部１０２は、先頭から「１５０Ｍｂｙｔｅ」分のデータについてデータが壊れているか否かをサーバ装置１４０に判断させる。ここで、データが壊れていると判断されれば、ダウンロード部１０２は、先頭からのデータサイズを「１０Ｍｂｙｔｅ」減らして、「１４０Ｍｂｙｔｅ」分のデータについてデータが壊れているか否かをさらに判断させる。
【００４０】
ここでも、データ壊れていると判断された場合、ダウンロード部１０２が把握しているデータが壊れている箇所の先頭からのデータサイズ「１３８Ｍｂｙｔｅ」と、データが壊れているか否かを判断したデータサイズ「１４０Ｍｂｙｔｅ」との差が１０Ｍｂｙｔｅ未満となったので、ダウンロード部１０２は、先頭からのデータサイズを「１０Ｍｂｙｔｅ」減らすのではなく、「５Ｍｂｙｔｅ」減らして、「１３５ＭＢｂｙｔｅ」分のデータについてデータが壊れているか否かをサーバ装置１４０に判断させる。ここで、壊れていないと判断されれば、ダウンロード部１０２は、先頭から「１３５ＭＢｂｙｔｅ」分のデータに続くデータの受信を再開することになる。
【００４１】
変形例１のように、常に「１０Ｍｂｙｔｅ」づつ減らして判断する方式では、先頭から「１３０ＭＢｂｙｔｅ」分のデータに続くデータの受信を再開することになり、変形例３では、上記したとおり、先頭から「１３５ＭＢｂｙｔｅ」分のデータに続くデータの受信を再開することとなり、変形例３では、変形例１よりも、ダウンロード再開後のデータ受信量が「５Ｍｂｙｔｅ」少なくなる。このように、変形例３では、ダウンロード再開後に受信するデータ量を、データが壊れている箇所を修復できるより最小限のデータ量に抑えることができるため、楽曲データのダウンロードを効率的におこなうことができる。
【００４２】
＜変形例４＞
実施形態において、ダウンロード部１０２は、ダウンロードが中断されるまでに受信した部分を、楽曲データ格納部１０４へ一時ファイルとして格納しておき、当該ダウンロードが再開すると、これに続く残りの部分をサーバ装置１４０から受信することとしたが、当該ダウンロードが再開すると、当該楽曲データを先頭から再送してもらい、再送された楽曲データのうちの、既に受信済みの部分については、これを破棄するようにしてもよい。変形例１において、当該ダウンロードが再開すると、受信済みの楽曲データにおけるデータが壊れていない部分に続く残りの部分をサーバ装置１４０から受信することとしたが、同様に、当該ダウンロードが再開すると、当該楽曲データを先頭から再送してもらい、再送された楽曲データのうちの、既に受信済みであり、かつデータが壊れていない部分については、これを破棄するようにしてもよい。
【００４３】
＜変形例５＞
既に楽曲データ格納部１０４に格納されている古いバージョンの楽曲データ（以下、「旧楽曲データ」と示す）に対して、新しいバージョンの楽曲データ（以下、「新楽曲データ」と示す）がサーバ装置１４０から配信される場合がある。この場合、ダウンロード部１０２は、新楽曲データをダウンロード中の間は、この新楽曲データで旧楽曲データを上書きせず、旧楽曲データと新楽曲データとを別々に楽曲データ格納部１０４に格納し、新楽曲データのダウンロードが完了した後、旧楽曲データを新楽曲データで上書きするようにしてもよい。これにより、旧楽曲データの再生中に、当該旧楽曲データが新楽曲データで上書きされてしまうことを防止できるうえ、旧楽曲データの再生と新楽曲データのダウンロードとを並行しておこなうことができる。なお、新楽曲データのダウンロードが完了した時点で、旧楽曲データが再生中の場合は、旧楽曲データの再生が終了した後に、旧楽曲データを新楽曲データで上書きするとよい。これらの場合も、実施形態で説明したように、新楽曲データのダウンロードが中断され、中断された当該ダウンロードが再開された場合、当該新楽曲データのうちの、受信した部分に続く残りの部分を受信し、当該残りの部分を、既に格納されている受信した部分に関連づけて楽曲データ格納部１０４に格納させるとよい。要するに、実施形態の「一の楽曲データ」を「新楽曲データ」に読み替えるとよい。なお、ここでいう「新楽曲データをダウンロード中の間」とは、新楽曲データの全てのデータのダウンロードが完了するまでを意味している。したがって、ここでいう「新楽曲データをダウンロード中の間」には、新楽曲データのダウンロードが中断されている間や、中断されたダウンロードが再開した後のダウンロードがおこなわれている間も含む。
【符号の説明】
【００４４】
１０…通信カラオケシステム、１００…カラオケ端末、１４０…サーバ装置、１２０…ネットワーク、１０２…ダウンロード部、１０４…楽曲データ格納部、１０５…指示入力部、１０６…楽曲データ再生部、１０８…表示部、１１０…発音部、１１２…収音部、１１４…音声合成部
【技術分野】
【０００１】
本発明は、カラオケ端末に関する。
【背景技術】
【０００２】
特許文献１には、カラオケ用の楽曲データをサーバ装置から各カラオケ端末に配信する通信カラオケシステムが開示されている。このような通信カラオケシステムで扱われる楽曲データの平均的なファイルサイズは、たとえばＭＩＤＩ（Musical Instrument Digital Interface）データであれば、１５０Ｋｂｙｔｅ程度である。各カラオケ端末は、この程度のファイルサイズの楽曲データであれば、比較的短い時間で当該楽曲データをサーバ装置からダウンロードすることができる。従って、ＭＩＤＩデータを用いた従来の通信カラオケシステムでは、ファイルの受信途中で通信が途切れるようなことがあった場合には、カラオケ装置は、途中まで受信したファイルを一度削除して、通信再開後にファイルを受信し直していた。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開平８−２６３０７８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
一方、近年では通信回線のブロードバンド化に伴い、楽曲データが高品質なものとなることで、楽曲データのデータサイズの巨大化を招いており、中にはデータサイズが１３０Ｍｂｙｔｅを超える楽曲データもある。このようにデータサイズの大きな楽曲データの場合、通信再開後にファイルを受信し直すのは効率が悪い。そこで、本発明は、カラオケに用いられる楽曲データのダウンロードが中断された場合であっても、当該楽曲データのダウンロードを効率的におこなうことを目的とする。
【課題を解決するための手段】
【０００５】
上記課題を解決するため、本発明は、データを格納する格納部と、カラオケに用いられる楽曲データを配信する情報処理装置との通信をおこなうことにより、当該情報処理装置から楽曲データをダウンロードして前記格納部に格納させるダウンロード部とを備え、前記ダウンロード部は、一の前記楽曲データのダウンロードが中断された場合、当該一の楽曲データのうちの既に受信した部分を前記格納部へ格納させておき、中断された当該ダウンロードが再開された場合、当該一の楽曲データのうちの、前記受信した部分に続く残りの部分を受信し、当該残りの部分を、既に格納されている前記受信した部分に関連づけて前記格納部に格納させることを特徴とするカラオケ端末を提供する。
【発明の効果】
【０００６】
本発明のカラオケ端末によれば、一の楽曲データのダウンロードが中断され、当該ダウンロードが再開されると、当該一の楽曲データの楽曲データの先頭から受信しなおすのではなく、当該一の楽曲データの受信済みの部分に続く残りの部分を受信するので、ダウンロード再開後におけるデータ受信量を抑えることができ、当該一の楽曲データのダウンロードを効率的におこなうことができる。
【図面の簡単な説明】
【０００７】
【図１】本実施形態に係る通信カラオケシステム１０の全体構成を示す。
【図２】カラオケ端末１００の機能構成を示す。
【図３】カラオケ端末１００による処理の手順を示す。
【図４】楽曲データ格納部１０４に格納されている楽曲データの一例を示す。
【図５】楽曲データ格納部１０４に格納されている楽曲データの一例を示す。
【図６】カラオケ端末１００のハードウェア構成の一例を示す。
【発明を実施するための形態】
【０００８】
図１は、本実施形態に係る通信カラオケシステム１０の全体構成を示す。通信カラオケシステム１０は、カラオケ端末１００と、サーバ装置１４０とを備える。カラオケ端末１００は、ユーザからの要求に従ってカラオケ用の楽曲データ（以下、単に「楽曲データ」という。）を再生する装置である。カラオケ端末１００およびサーバ装置１４０のそれぞれは、ネットワーク１２０に接続されている。ネットワーク１２０はＬＡＮ（Local Area Network）やインターネットであり、カラオケ端末１００とサーバ装置１４０との間におけるデータ通信が行われる通信網である。サーバ装置１４０は、楽曲データを配信する情報処理装置である。サーバ装置１４０は、その内部あるいは外部に備えたＨＤＤ（Hard Disk Drive）等の記憶手段に楽曲データを格納しており、カラオケ端末１００からの要求に従って、あるいは定期的に、ネットワーク１２０経由でこの楽曲データをカラオケ端末１００に配信する。ここで、楽曲データとは、カラオケに用いられる楽曲に関する楽音データと映像データとが組み合わされたものを示す。すなわち、楽曲データは、主旋律の歌声が存在せず伴奏やコーラスで構成されたいわゆるカラオケバージョンの楽曲に関する音声データと、この楽曲の歌詞や歌詞の背景に表示する映像からなる映像データとから成り立っている。通信カラオケシステム１０には、複数のカラオケ端末１００が存在してもよく、複数のサーバ装置１４０が存在してもよい。
【０００９】
図２は、カラオケ端末１００の機能構成を示す。ここでは、カラオケ端末１００が備える機能のうち、本実施形態の説明に必要となる、楽曲データをダウンロードして格納することに関する機能と、格納された楽曲データを再生することに関する機能について説明する。カラオケ端末１００は、ダウンロード部１０２、楽曲データ格納部１０４、指示入力部１０５、楽曲データ再生部１０６、表示部１０８、発音部１１０、収音部１１２、および音声合成部１１４を備える。
【００１０】
ダウンロード部１０２は、サーバ装置１４０との通信をおこなうことにより、サーバ装置１４０から楽曲データをダウンロードする。楽曲データ格納部１０４は、ダウンロード部１０２によってサーバ装置１４０からダウンロードされた楽曲データを格納する。楽曲データ再生部１０６は、楽曲データ格納部１０４に格納されている楽曲データを再生する。
【００１１】
このカラオケ端末１００の利用時には、ユーザに対し、再生可能な楽曲データの曲目リストが提供される。この曲目リストには、複数の楽曲データのそれぞれについて、曲名、歌手名、楽曲データＩＤなどが示されている。そして、カラオケ端末１００のユーザが、この曲目リストの中から所望の楽曲データを選択し、選択した楽曲データに対応付けられている楽曲データＩＤを、指示入力部１０５で入力すると、楽曲データ再生部１０６は、この楽曲データＩＤに対応付けられている楽曲データを楽曲データ格納部１０４から検索する。この楽曲データが楽曲データ格納部１０４に格納されていれば、楽曲データ再生部１０６が、この楽曲データを楽曲データ格納部１０４から取得し、これを再生する。一方、この楽曲データが楽曲データ格納部１０４に格納されていなければ、ダウンロード部１０２が、この楽曲データＩＤに対応付けられている楽曲データをサーバ装置１４０からダウンロードする。楽曲データ格納部１０４には、ダウンロードされた楽曲データが、当該楽曲データの楽曲データＩＤと対応づけて格納される。このようにして、楽曲データのダウンロードが完了すると、楽曲データ再生部１０６が、ダウンロードされた楽曲データを楽曲データ格納部１０４から取得し、これを再生する。
【００１２】
このようにして楽曲データが再生されると、表示部１０８が、この楽曲データに含まれる映像データに応じた映像を表示する。これと同時に、発音部１１０が、この楽曲データに含まれる楽音データに応じた音を発する。さらに、楽曲データの再生中に、カラオケ端末１００のユーザが発した音声を収音部１１２が収集すると、音声合成部１１４が、収集部１１２によって収集された音声を示す音声データと、再生部１０６によって再生された楽曲データに含まれる楽音データとを合成して、これを発音部１１０へ供給する。これにより、発音部１１０からは、カラオケ端末１００のユーザが発した音声と、楽曲データに含まれる楽音とが重ねられて、発せられる。
【００１３】
図３は、カラオケ端末１００による処理の手順を示す。まず、カラオケ端末１００のユーザが、曲目リストの中から所望の楽曲データ（以下、「当該楽曲データ」という。）を選択し、当該楽曲データに対応付けられている楽曲データＩＤを、指示入力部１０５で入力する（ステップＳ３０２）。これに応じて、楽曲データ再生部１０６が、当該楽曲データが楽曲データ格納部１０４に格納されているか否かを判断する（ステップＳ３０４）。
【００１４】
ステップＳ３０４において、「当該楽曲データが楽曲データ格納部１０４に格納されている」と判断された場合（ステップＳ３０４：ＹＥＳ）、楽曲データ再生部１０６が、当該楽曲データを楽曲データ格納部１０４から取得し、これを再生する（ステップＳ３２０）。
【００１５】
一方、ステップＳ３０４において、「当該楽曲データが楽曲データ格納部１０４に格納されてない」と判断された場合（ステップＳ３０４：ＮＯ）、ダウンロード部１０２が、サーバ装置１４０との通信をおこなうことにより、サーバ装置１４０からの当該楽曲データのダウンロードを開始する（ステップＳ３０６）。具体的には、ダウンロード部１０２が、当該楽曲データの楽曲データＩＤをサーバ装置１４０に通知し、この通知に応じて、サーバ装置１４０が当該楽曲データＩＤに対応する楽曲データを記憶手段から読み出してカラオケ端末１００に送信する。ダウンロード部１０２はこれを受信する。
【００１６】
その後、ダウンロード部１０２は、当該楽曲データのダウンロードの最中に、当該ダウンロードが中断されなければ（ステップＳ３０８：ＮＯ）、当該楽曲データを受信し（ステップＳ３１２）、受信した当該楽曲データを、再生不可能な一時ファイルとして楽曲データ格納部１０４に格納させる（ステップＳ３１４）。そして、ダウンロード部１０２は、当該楽曲データの全部を受信していなければ（ステップＳ３１６：ＮＯ）、当該楽曲データの全部を受信するまで、ステップＳ３１２およびステップＳ３１４を繰り返し、その都度、受信した当該楽曲データを楽曲データ格納部１０４に格納されている一時ファイルに加えていく。
【００１７】
ダウンロード部１０２が、当該楽曲データの全部を受信して楽曲データ格納部１０４に格納させると（ステップＳ３１６：ＹＥＳ）、ダウンロード部１０２は、楽曲データ格納部１０４に格納されている一時ファイルを、再生可能な完全ファイルとして有効化する（ステップＳ３１８）。そして、楽曲データ再生部１０６が、当該楽曲データを楽曲データ格納部１０４から取得し、これを再生する（ステップＳ３２０）。
【００１８】
上記において、当該楽曲データのダウンロードの最中に、当該ダウンロードが中断される場合がある（ステップＳ３０８：ＹＥＳ）。例えば、サーバ装置１４０とカラオケ端末１００との間の通信環境が悪化した場合とか、サーバ装置１４０またはカラオケ端末１００に処理の異常が発生したような場合である。この場合、ダウンロード部１０２は、当該楽曲データのうちの、当該ダウンロードが中断されるまでに受信した部分を、破棄してしまうのではなく、再生不可能な一時ファイルとして楽曲データ格納部１０４に格納させたままにしておく。そして、ダウンロード部１０２は、サーバ装置１４０に対して要求を送信するなどして、当該ダウンロードの再開を試みる（ステップＳ３１０）、この試みは、タイムアウトになるまで繰り返される（ステップＳ３１０：ＮＯ）。当該ダウンロードが再開できた場合には（ステップＳ３１０：ＹＥＳ）、ダウンロード部１０２は、当該楽曲データのうちの、既に受信した部分、すなわち、楽曲データ格納部１０４に格納しておいた部分に続く、残りの部分のダウンロードを開始し（ステップＳ３１１）、当該残りの部分の全部を受信するまで、ステップＳ３１２およびステップＳ３１４を繰り返し、その都度、受信した当該残りの部分を楽曲データ格納部１０４に格納されている一時ファイルに加えていく。このように同一の一時ファイルに残りの部分が追加されるので、この残りの部分が、既に格納されている部分に関連づけて楽曲データ格納部１０４に格納されることになる。
【００１９】
ここで、サーバ装置１４０においては、ダウンロードの再開要求をカラオケ端末１００から受け取ったとしても、どの楽曲データのどの位置からの配信を再開すればよいか判断できない場合がある。そこで、本実施形態のカラオケ端末１００は、ダウンロードの再開をサーバ装置１４０へ要求するとともに、当該楽曲データの楽曲データＩＤ、および当該楽曲データのうちの楽曲データ格納部１０４に格納された受信済みの部分のデータサイズ（Ｂｙｔｅ数）、すなわち一時ファイルのデータサイズをサーバ装置１４０へ通知する。たとえば、ダウンロード済みの部分のデータサイズが、「１５４３００ＫＢｙｔｅ」の場合、カラオケ端末１００は、当該楽曲データの楽曲データＩＤと、受信済みの部分のデータサイズ「１５４３００ＫＢｙｔｅ」とを、サーバ装置１４０へ通知する。これにより、サーバ装置１４０は、通知された楽曲データＩＤに基づいて、配信を再開する楽曲データを特定し、さらに、その楽曲データにおいて当該データの先頭からデータサイズ「１５４３００ＫＢｙｔｅ」に相当する位置が配信を再開する位置であることを特定することができる。
【００２０】
図４および図５は、楽曲データ格納部１０４に格納されている楽曲データの管理テーブル４００の一例を示す。図４および図５に示す管理テーブル４００は、楽曲データ格納部１０４に格納されているデータベース・テーブルである。この管理テーブル４００には、各々の楽曲データに関する情報、例えば各楽曲データの楽曲データＩＤ、ファイル名、保存日時、および再生回数が記述されている。ここで、各々の楽曲データのファイル名には、拡張子が付与されている。複数の楽曲データのファイルのうち、ファイル名に拡張子「．ｓｏｎｇ」が付与されているものは、再生可能な完全ファイルであることを示す。一方、ファイル名に拡張子「．ｔｍｐ」が付与されているものは、ダウンロードの途中であり、再生不可能な一時ファイルであることを示す。たとえば、図４に示すテーブル４００において、楽曲データＩＤが「１０２５−３１」の楽曲データのファイル名は、「１０２５−３１．ｔｍｐ」となっている。これは、この楽曲データのダウンロードが途中であり、このファイルが再生不可能な一時ファイルであることを示している。この楽曲データのダウンロードが完了すると、再生不可能な一時ファイルが再生可能な完全ファイルに有効化され、これにより、図５に示すように、この楽曲データのファイル名は、「１０２５−３１．ｔｍｐ」から「１０２５−３１．ｓｏｎｇ」となる。
【００２１】
図６は、カラオケ端末１００のハードウェア構成の一例を示す。カラオケ端末１００は、ＣＰＵ１５０５、ＲＯＭ１５１０、ＲＡＭ１５２０、ＨＤ（ハードディスク）ドライブ１５２５、通信インターフェース１５３０、外部メモリドライブ１５４０、外部メモリ１５４２、操作パネル１５５０、ディスプレイ１５６０、スピーカ１５７０、およびマイク１５８０を備える。
【００２２】
ＲＯＭ１５１０、ＲＡＭ１５２０、およびＨＤドライブ１５２５は、各種データおよび各種プログラムを格納する。ＣＰＵ１５０５は、ＲＯＭ１５１０、ＲＡＭ１５２０、ＨＤドライブ１５２５、または外部メモリ１５４２に格納されたプログラムを実行することで、各種データ処理および各種ハードウェア制御をおこなう。
【００２３】
通信インターフェース１５３０は、ネットワーク１２０に接続し、ネットワーク１２０を介して外部との通信をおこなう。外部メモリドライブ１５４０は、外部メモリ１５４２に接続し、外部メモリ１５４２に対するデータの送受信をおこなう。外部メモリ１５４２としては、たとえば、メモリカードが挙げられる。
【００２４】
操作パネル１５５０には、キーボード、ボタン、タッチパネルなどの入力デバイスが設けられており、これらの入力デバイスがユーザによって操作されることにより、当該カラオケ端末１００に対し、各種情報を入力する。ディスプレイ１５６０は、映像データに応じた映像を表示する。スピーカ１５７０は、音声データに応じた音を発する。マイク１５８０は、音を収集し、収集した音に応じた音声データを生成する。
【００２５】
ＣＰＵ１５０５が実行するプログラムは、たとえば、コンピュータ読み取り可能な記録媒体に格納されてカラオケ端末１００に提供され、カラオケ端末１００に格納される。ＣＰＵ１５０５が実行するプログラムは、カラオケ端末１００に予め格納されていてもよい。また、ＣＰＵ１５０５が実行するプログラムは、外部装置から通信ネットワークを介してカラオケ端末１００に提供され、カラオケ端末１００に格納されてもよい。
【００２６】
たとえば、コンピュータであるカラオケ端末１００は、ＣＰＵ１５０５が、上記プログラムを実行し、通信インターフェース１５３０を制御することにより、図２に示したダウンロード部１０２として機能する。また、カラオケ端末１００は、ＲＯＭ１５１０、ＲＡＭ１５２０、ＨＤドライブ１５２５、または外部メモリ１５４２が、図２に示した楽曲データ格納部１０４として機能する。また、カラオケ端末１００は、ＣＰＵ１５０５が、上記プログラムを実行することにより、図２に示した楽曲データ再生部１０６および音声合成部１１４として機能する。また、カラオケ端末１００は、操作パネル１５５０が、図２に示した指示入力部１０５として機能する。また、カラオケ端末１００は、ディスプレイ１５６０が、図２に示した表示部１０８として機能する。また、カラオケ端末１００は、スピーカ１５７０が、図２に示した発音部１１０として機能する。また、カラオケ端末１００は、マイク１５８０が、図２に示した収音部１１２として機能する。
【００２７】
以上説明したように、本実施形態に係るカラオケ端末１００によれば、一の楽曲データのダウンロードが中断され、当該ダウンロードが再開されると、当該一の楽曲データの楽曲データの先頭から受信しなおすのではなく、当該一の楽曲データの受信済みの部分に続く残りの部分を受信するので、最初からダウンロードをやり直す場合と比較して、ダウンロード再開後におけるデータ受信量やダウンロード時間を抑えることができる。よって、当該一の楽曲データのダウンロードを効率的におこなうことができる。
【００２８】
＜変形例＞
上述の実施形態を以下のように変形してもよい。また、以下の各変形例を適宜組み合わせてもよい。
【００２９】
＜変形例１＞
実施形態において、ダウンロード部１０２は、ダウンロードが中断されるまでに受信した部分を、楽曲データ格納部１０４へ一時ファイルとして格納しておき、当該ダウンロードが再開すると、これに続く残りの部分をサーバ装置１４０から受信することとした。ここで、一時ファイルのデータが壊れていると、ダウンロードを再開して、全てのデータを受信し、当該一時ファイルを有効化したとしても、当該楽曲データを正常に再生することができない。そこで、ダウンロード部１０２は、受信済みの部分のデータのうちのデータが壊れていない部分以降の、残りの部分のデータを、サーバ装置１４０から受信することが望ましい。具体的には次のような仕組みとなる。
【００３０】
たとえば、ダウンロード部１０２は、受信済みの部分のデータのハッシュ値をサーバ装置１４０へ送信し、受信済みの部分のデータが壊れているか否かをサーバ装置１４０に判断させ、その判断結果をサーバ装置１４０から受け取る。そして、ダウンロード部１０２は、受信済みの部分のデータが壊れていないとの判断結果をサーバ装置１４０から受け取った場合は、受信済みの部分に続く残りの部分をサーバ装置１４０から受信する。
【００３１】
一方、ダウンロード部１０２は、受信済みの部分のデータが壊れているとの判断結果をサーバ装置１４０から受け取った場合は、判断の対象とする受信済みの部分のデータの先頭からのサイズを所定量減らしてから（つまり、受信済みの部分のデータの後ろから所定量のデータを除いてから）、上記と同様に、このサイズが減らされた後のデータのハッシュ値をサーバ装置１４０へ送信し、サイズが減らされた後のデータが壊れているか否かをサーバ装置１４０に判断させ、その判断結果をサーバ装置１４０から受け取る。そして、ダウンロード部１０２は、サイズが減らされた後のデータが壊れていないとの判断結果をサーバ装置１４０から受け取った場合は、このサイズが減らされた後のデータに続く残りの部分をサーバ装置１４０から受信する。
【００３２】
なおも、ダウンロード部１０２は、サイズが減らされた後のデータが壊れているとの判断結果をサーバ装置１４０から受け取った場合は、判断の対象とする受信済みの部分のデータの先頭からのサイズをさらに所定量減らし、上記と同様に、このサイズがさらに減らされた後のデータのハッシュ値をサーバ装置１４０へ送信し、サイズがさらに減らされた後のデータが壊れているか否かをサーバ装置１４０に判断させ、その判断結果をサーバ装置１４０から受け取る。
【００３３】
具体例を挙げると、受信済みの部分のデータのサイズが「１５０ＭＢｙｔｅ」である場合、たとえば、ダウンロード部１０２は、受信済みの部分のデータのうちの、先頭から「１５０ＭＢｙｔｅ」分のデータのハッシュ値をサーバ装置１４０へ送信し、この「１５０ＭＢｙｔｅ」分のデータが壊れているか否かをサーバ装置１４０に判断させ、その判断結果をサーバ装置１４０から受け取る。そして、ダウンロード部１０２は、この「１５０ＭＢｙｔｅ」分のデータが壊れていないとの判断結果をサーバ装置１４０から受け取った場合は、この「１５０ＭＢｙｔｅ」分のデータに続く残りの部分をサーバ装置１４０から受信する。
【００３４】
一方、ダウンロード部１０２は、「１５０ＭＢｙｔｅ」分のデータが壊れているとの判断結果をサーバ装置１４０から受け取った場合は、判断の対象とする受信済みの部分のデータのサイズを先頭から「１４０ＭＢｙｔｅ」分に減らし、上記と同様に、この「１４０ＭＢｙｔｅ」分のデータのハッシュ値をサーバ装置１４０へ送信し、この「１４０ＭＢｙｔｅ」分のデータが壊れているか否かをサーバ装置１４０に判断させ、その判断結果をサーバ装置１４０から受け取る。そして、ダウンロード部１０２は、この「１４０ＭＢｙｔｅ」分のデータが壊れていないとの判断結果をサーバ装置１４０から受け取った場合は、この「１４０ＭＢｙｔｅ」分のデータに続く残りの部分をサーバ装置１４０から受信する。
【００３５】
なおも、ダウンロード部１０２は、この「１４０ＭＢｙｔｅ」分のデータが壊れているとの判断結果をサーバ装置１４０から受け取った場合は、判断の対象とする受信済みの部分のデータのサイズを先頭から「１３０ＭＢｙｔｅ」分に減らし、上記と同様に、この「１３０ＭＢｙｔｅ」分のデータのハッシュ値をサーバ装置１４０へ送信し、この「１３０ＭＢｙｔｅ」分のデータが壊れているか否かをサーバ装置１４０に判断させ、その判断結果をサーバ装置１４０から受け取る。
【００３６】
このようにして、ダウンロード部１０２は、徐々に判断対象のデータの先頭からのサイズを減らして、このデータが壊れているか否かをサーバ装置１４０に判断させることにより、受信済みの部分のデータにおける、データが壊れていない部分に続く残りの部分からのダウンロードを再開する。これにより、ダウンロード再開後に受信するデータ量を、データが壊れている箇所を修復できる最小限のデータ量に抑えることができるため、楽曲データのダウンロードを効率的におこなうことができる。
【００３７】
＜変形例２＞
変形例１において、サーバ装置１４０は、楽曲データのヘッダー等に対して、部分的にハッシュ値を埋め込んで当該楽曲データを配信し、ダウンロード部１０２は、このハッシュ値により、データが壊れていない部分を自ら特定し、ダウンロードの再開後は、データが壊れていないと特定した部分以降の部分をサーバ装置１４０から受信するようにしてもよい。たとえば、サーバ装置１４０は、楽曲データを複数のブロックに区切って、カラオケ端末１００へ配信する。このとき、サーバ装置１４０は、各々のブロックに対して、当該ブロックに割り当てられたブロック識別情報と、当該ブロックに含まれる前記楽曲データのハッシュ値を含めて、当該楽曲データをカラオケ端末１００へ配信する。ダウンロード部１０２は、当該楽曲データをブロック単位で受信し、受信した当該楽曲データをブロック単位で、順次、楽曲データ格納部１０４へ格納する。楽曲データのダウンロードが中断された場合、楽曲データ格納部１０４へ格納されている（すなわち、受信済みの）各々のブロックに含まれる楽曲データのハッシュ値を算出して、当該ブロックについて算出した当該ハッシュ値と、当該ブロックに含まれていた前記ハッシュ値とを照合する。そして、ダウンロード部１０２は、双方のハッシュ値が一致していないブロックに含まれているブロック識別情報をサーバ装置１４０に通知し、当該ブロック以降のブロックに含まれている楽曲データを、データが壊れていない部分に続く残りの部分として、サーバ装置１４０に要求する。以上のように、変形例２では、データが壊れているブロックについては、当該ブロックを含む、当該ブロック以降のデータを新たに受信することによって、データが壊れている部分を復旧することとした。このように、データが壊れている部分の判断や、再送をブロック単位としたのは、データが壊れている部分の判断や、再送をデータサイズ単位（たとえば、Ｂｙｔｅ単位）とするよりも、既に受信済みの楽曲データと再送された楽曲データとを結合する処理などを、容易におこなうことができるからである。
【００３８】
＜変形例３＞
変形例１において、ダウンロード部１０２は、徐々に判断対象のデータの先頭からのサイズを所定量減らして、このデータが壊れているか否かをサーバ装置１４０に判断させることとしたが、判断対象のデータ量が、データが壊れている箇所を含む部分のデータ量に近づくにつれ、判断対象のデータの先頭からのサイズを減らす量を、少なくするようにしてもよい。これにより、データが壊れていない部分を特定する際の精度を高めることができるので、ダウンロード再開後に受信するデータ量を、データが壊れている箇所を修復できるより最小限のデータ量に抑えることができるため、楽曲データのダウンロードを効率的におこなうことができる。
【００３９】
たとえば、データが壊れている箇所が先頭から「１３８ＭＢｂｙｔｅ」目の箇所であり、この大体の位置をダウンロード部１０２が把握しているとする。ここで、ダウンロード部１０２が把握している箇所と、実際にデータが壊れている箇所との間に誤差があることが考えられるので、まず、ダウンロード部１０２は、先頭から「１５０Ｍｂｙｔｅ」分のデータについてデータが壊れているか否かをサーバ装置１４０に判断させる。ここで、データが壊れていると判断されれば、ダウンロード部１０２は、先頭からのデータサイズを「１０Ｍｂｙｔｅ」減らして、「１４０Ｍｂｙｔｅ」分のデータについてデータが壊れているか否かをさらに判断させる。
【００４０】
ここでも、データ壊れていると判断された場合、ダウンロード部１０２が把握しているデータが壊れている箇所の先頭からのデータサイズ「１３８Ｍｂｙｔｅ」と、データが壊れているか否かを判断したデータサイズ「１４０Ｍｂｙｔｅ」との差が１０Ｍｂｙｔｅ未満となったので、ダウンロード部１０２は、先頭からのデータサイズを「１０Ｍｂｙｔｅ」減らすのではなく、「５Ｍｂｙｔｅ」減らして、「１３５ＭＢｂｙｔｅ」分のデータについてデータが壊れているか否かをサーバ装置１４０に判断させる。ここで、壊れていないと判断されれば、ダウンロード部１０２は、先頭から「１３５ＭＢｂｙｔｅ」分のデータに続くデータの受信を再開することになる。
【００４１】
変形例１のように、常に「１０Ｍｂｙｔｅ」づつ減らして判断する方式では、先頭から「１３０ＭＢｂｙｔｅ」分のデータに続くデータの受信を再開することになり、変形例３では、上記したとおり、先頭から「１３５ＭＢｂｙｔｅ」分のデータに続くデータの受信を再開することとなり、変形例３では、変形例１よりも、ダウンロード再開後のデータ受信量が「５Ｍｂｙｔｅ」少なくなる。このように、変形例３では、ダウンロード再開後に受信するデータ量を、データが壊れている箇所を修復できるより最小限のデータ量に抑えることができるため、楽曲データのダウンロードを効率的におこなうことができる。
【００４２】
＜変形例４＞
実施形態において、ダウンロード部１０２は、ダウンロードが中断されるまでに受信した部分を、楽曲データ格納部１０４へ一時ファイルとして格納しておき、当該ダウンロードが再開すると、これに続く残りの部分をサーバ装置１４０から受信することとしたが、当該ダウンロードが再開すると、当該楽曲データを先頭から再送してもらい、再送された楽曲データのうちの、既に受信済みの部分については、これを破棄するようにしてもよい。変形例１において、当該ダウンロードが再開すると、受信済みの楽曲データにおけるデータが壊れていない部分に続く残りの部分をサーバ装置１４０から受信することとしたが、同様に、当該ダウンロードが再開すると、当該楽曲データを先頭から再送してもらい、再送された楽曲データのうちの、既に受信済みであり、かつデータが壊れていない部分については、これを破棄するようにしてもよい。
【００４３】
＜変形例５＞
既に楽曲データ格納部１０４に格納されている古いバージョンの楽曲データ（以下、「旧楽曲データ」と示す）に対して、新しいバージョンの楽曲データ（以下、「新楽曲データ」と示す）がサーバ装置１４０から配信される場合がある。この場合、ダウンロード部１０２は、新楽曲データをダウンロード中の間は、この新楽曲データで旧楽曲データを上書きせず、旧楽曲データと新楽曲データとを別々に楽曲データ格納部１０４に格納し、新楽曲データのダウンロードが完了した後、旧楽曲データを新楽曲データで上書きするようにしてもよい。これにより、旧楽曲データの再生中に、当該旧楽曲データが新楽曲データで上書きされてしまうことを防止できるうえ、旧楽曲データの再生と新楽曲データのダウンロードとを並行しておこなうことができる。なお、新楽曲データのダウンロードが完了した時点で、旧楽曲データが再生中の場合は、旧楽曲データの再生が終了した後に、旧楽曲データを新楽曲データで上書きするとよい。これらの場合も、実施形態で説明したように、新楽曲データのダウンロードが中断され、中断された当該ダウンロードが再開された場合、当該新楽曲データのうちの、受信した部分に続く残りの部分を受信し、当該残りの部分を、既に格納されている受信した部分に関連づけて楽曲データ格納部１０４に格納させるとよい。要するに、実施形態の「一の楽曲データ」を「新楽曲データ」に読み替えるとよい。なお、ここでいう「新楽曲データをダウンロード中の間」とは、新楽曲データの全てのデータのダウンロードが完了するまでを意味している。したがって、ここでいう「新楽曲データをダウンロード中の間」には、新楽曲データのダウンロードが中断されている間や、中断されたダウンロードが再開した後のダウンロードがおこなわれている間も含む。
【符号の説明】
【００４４】
１０…通信カラオケシステム、１００…カラオケ端末、１４０…サーバ装置、１２０…ネットワーク、１０２…ダウンロード部、１０４…楽曲データ格納部、１０５…指示入力部、１０６…楽曲データ再生部、１０８…表示部、１１０…発音部、１１２…収音部、１１４…音声合成部
【特許請求の範囲】
【請求項１】
データを格納する格納部と、
カラオケに用いられる楽曲データを配信する情報処理装置との通信をおこなうことにより、当該情報処理装置から楽曲データをダウンロードして前記格納部に格納させるダウンロード部と
を備え、
前記ダウンロード部は、
一の前記楽曲データのダウンロードが中断された場合、当該一の楽曲データのうちの既に受信した部分を前記格納部へ格納させておき、
中断された当該ダウンロードが再開された場合、当該一の楽曲データのうちの、前記受信した部分に続く残りの部分を受信し、当該残りの部分を、既に格納されている前記受信した部分に関連づけて前記格納部に格納させる
ことを特徴とするカラオケ端末。
【請求項２】
前記一の楽曲データが、既に前記格納部に格納されている古いバージョンの旧楽曲データに対する、新しいバージョンの新楽曲データである場合、
前記ダウンロード部は、
前記新楽曲データをダウンロード中の間は、当該新楽曲データで前記旧楽曲データを上書きせず、前記旧楽曲データと当該新楽曲データとを別々に前記格納部に格納させておき、当該新楽曲データのダウンロードが完了した後、前記旧楽曲データを当該新楽曲データで上書きする
ことを特徴とする請求項１に記載のカラオケ端末。
【請求項３】
前記ダウンロード部は、
前記一の楽曲データのダウンロードが中断された場合、前記受信した部分における、データが壊れていない部分を特定し、当該ダウンロードが再開された場合、特定された前記データが壊れていない部分に続く残りの部分を前記情報配信装置に要求して受信する
ことを特徴とする請求項１または２に記載のカラオケ端末。
【請求項４】
前記楽曲データは複数のブロックに区切られて前記情報配信装置から配信され、
各々の前記ブロックには、当該ブロックに割り当てられたブロック識別情報と、当該ブロックに含まれる前記楽曲データのハッシュ値が含まれており、
前記ダウンロード部は、前記一の楽曲データのダウンロードが中断された場合、前記格納部へ格納されている各々の前記ブロックに含まれる楽曲データのハッシュ値を算出して、当該ブロックについて算出した当該ハッシュ値と、当該ブロックに含まれていた前記ハッシュ値とを照合し、
双方の前記ハッシュ値が一致していないブロックに含まれている前記ブロック識別情報を前記情報配信装置に通知し、当該ブロック以降のブロックに含まれている楽曲データを、前記データが壊れていない部分に続く残りの部分として、前記情報配信装置に要求する
ことを特徴とする請求項３に記載のカラオケ端末。
【請求項５】
前記ダウンロード部は、
一の前記楽曲データのダウンロードが中断された場合、当該一の楽曲データのうちの既に受信した部分のデータサイズを前記情報処理装置に通知することにより、当該ダウンロードが再開される場合に、当該一の楽曲データのうちの前記データサイズ以降に相当する前記残りの部分を配信するよう前記情報処理装置に要求する
ことを特徴とする請求項１または２に記載のカラオケ端末。
【請求項６】
前記ダウンロード部は、
前記一の楽曲データのダウンロードが中断された場合、前記受信した部分のデータについてハッシュ値を生成して前記情報配信装置に送信し、
当該受信した部分におけるデータが壊れているか否かについての前記情報配信装置による判断結果を受信し、
前記判断結果が前記受信した部分におけるデータが壊れていない旨である場合には、前記情報配信装置から、前記受信した部分に続く残りの部分を受信し、
前記判断結果が前記受信した部分におけるデータが壊れている旨である場合には、前記受信した部分の後ろから所定量のデータを除いてから、当該受信した部分のデータについてハッシュ値を生成して前記情報配信装置に送信する処理を、前記受信した部分におけるデータが壊れていない旨の前記判断結果を受信するまで繰り返す
ことを特徴とする請求項１または２に記載のカラオケ端末。
【請求項１】
データを格納する格納部と、
カラオケに用いられる楽曲データを配信する情報処理装置との通信をおこなうことにより、当該情報処理装置から楽曲データをダウンロードして前記格納部に格納させるダウンロード部と
を備え、
前記ダウンロード部は、
一の前記楽曲データのダウンロードが中断された場合、当該一の楽曲データのうちの既に受信した部分を前記格納部へ格納させておき、
中断された当該ダウンロードが再開された場合、当該一の楽曲データのうちの、前記受信した部分に続く残りの部分を受信し、当該残りの部分を、既に格納されている前記受信した部分に関連づけて前記格納部に格納させる
ことを特徴とするカラオケ端末。
【請求項２】
前記一の楽曲データが、既に前記格納部に格納されている古いバージョンの旧楽曲データに対する、新しいバージョンの新楽曲データである場合、
前記ダウンロード部は、
前記新楽曲データをダウンロード中の間は、当該新楽曲データで前記旧楽曲データを上書きせず、前記旧楽曲データと当該新楽曲データとを別々に前記格納部に格納させておき、当該新楽曲データのダウンロードが完了した後、前記旧楽曲データを当該新楽曲データで上書きする
ことを特徴とする請求項１に記載のカラオケ端末。
【請求項３】
前記ダウンロード部は、
前記一の楽曲データのダウンロードが中断された場合、前記受信した部分における、データが壊れていない部分を特定し、当該ダウンロードが再開された場合、特定された前記データが壊れていない部分に続く残りの部分を前記情報配信装置に要求して受信する
ことを特徴とする請求項１または２に記載のカラオケ端末。
【請求項４】
前記楽曲データは複数のブロックに区切られて前記情報配信装置から配信され、
各々の前記ブロックには、当該ブロックに割り当てられたブロック識別情報と、当該ブロックに含まれる前記楽曲データのハッシュ値が含まれており、
前記ダウンロード部は、前記一の楽曲データのダウンロードが中断された場合、前記格納部へ格納されている各々の前記ブロックに含まれる楽曲データのハッシュ値を算出して、当該ブロックについて算出した当該ハッシュ値と、当該ブロックに含まれていた前記ハッシュ値とを照合し、
双方の前記ハッシュ値が一致していないブロックに含まれている前記ブロック識別情報を前記情報配信装置に通知し、当該ブロック以降のブロックに含まれている楽曲データを、前記データが壊れていない部分に続く残りの部分として、前記情報配信装置に要求する
ことを特徴とする請求項３に記載のカラオケ端末。
【請求項５】
前記ダウンロード部は、
一の前記楽曲データのダウンロードが中断された場合、当該一の楽曲データのうちの既に受信した部分のデータサイズを前記情報処理装置に通知することにより、当該ダウンロードが再開される場合に、当該一の楽曲データのうちの前記データサイズ以降に相当する前記残りの部分を配信するよう前記情報処理装置に要求する
ことを特徴とする請求項１または２に記載のカラオケ端末。
【請求項６】
前記ダウンロード部は、
前記一の楽曲データのダウンロードが中断された場合、前記受信した部分のデータについてハッシュ値を生成して前記情報配信装置に送信し、
当該受信した部分におけるデータが壊れているか否かについての前記情報配信装置による判断結果を受信し、
前記判断結果が前記受信した部分におけるデータが壊れていない旨である場合には、前記情報配信装置から、前記受信した部分に続く残りの部分を受信し、
前記判断結果が前記受信した部分におけるデータが壊れている旨である場合には、前記受信した部分の後ろから所定量のデータを除いてから、当該受信した部分のデータについてハッシュ値を生成して前記情報配信装置に送信する処理を、前記受信した部分におけるデータが壊れていない旨の前記判断結果を受信するまで繰り返す
ことを特徴とする請求項１または２に記載のカラオケ端末。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２０１１−２０９５０６（Ｐ２０１１−２０９５０６Ａ）
【公開日】平成２３年１０月２０日（２０１１．１０．２０）
【国際特許分類】
【出願番号】特願２０１０−７７２７３（Ｐ２０１０−７７２７３）
【出願日】平成２２年３月３０日（２０１０．３．３０）
【出願人】（０００００４０７５）ヤマハ株式会社 (5,930)
【Ｆターム（参考）】
【公開日】平成２３年１０月２０日（２０１１．１０．２０）
【国際特許分類】
【出願日】平成２２年３月３０日（２０１０．３．３０）
【出願人】（０００００４０７５）ヤマハ株式会社 (5,930)
【Ｆターム（参考）】
[ Back to top ]