JP4766080B2 - 情報処理装置、情報配信システム、情報処理方法、及びプログラムを記録した記録媒体 - Google Patents
情報処理装置、情報配信システム、情報処理方法、及びプログラムを記録した記録媒体 Download PDFInfo
- Publication number
- JP4766080B2 JP4766080B2 JP2008163784A JP2008163784A JP4766080B2 JP 4766080 B2 JP4766080 B2 JP 4766080B2 JP 2008163784 A JP2008163784 A JP 2008163784A JP 2008163784 A JP2008163784 A JP 2008163784A JP 4766080 B2 JP4766080 B2 JP 4766080B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- information
- block
- area
- identification information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Management Or Editing Of Information On Record Carriers (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Signal Processing For Digital Recording And Reproducing (AREA)
Description
本発明は、マルチメディア情報としてのコンテンツを配信する情報配信システムと、この情報配信システムにおいて使用し得る情報処理装置、及びその方法、さらに、その方法を実行するプログラムを記録した記録媒体に関するものである。
近年、例えば楽曲としてのオーディオデータをサーバから配信して、最終的にはユーザが所有する記録媒体、もしくは記録媒体を内蔵するオーディオプレーヤに配信できるようにしたシステムが知られてきている。つまり音楽配信システムである。
このような音楽配信システムにあって送受信される情報としては、例えば楽曲としてのオーディオデータのほか、これに付随するジャケットなどの画像データや、歌詞などのテキストデータも含ませることが考えられている。つまり、送信すべきデータの種類としては、オーディオデータだけでなく、画像データやテキストデータ等のコンテンツも含まれる、いわゆるマルチメディア情報となる。
そして、このようなマルチメディア情報の作成にあたっては、ＨＴＭＬ(Hyper Text Markup Language)といわれる記述言語を用いることが広く行われている。 ＨＴＭＬでは、図１５に示すようにして、＜ ＞で囲まれるいわゆるタグといわれる識別子を用いて記述したファイルを作成することにより、情報の表現を行う。ＨＴＭＬの場合、タグの内容及びその意味は固定的なものとされている。ここで、画像を表示させるには、例えば図の場合であれば、＜IMG SRC="20silly.gif"width=100 HIGHT"=100＞などのようにしてタグによる記述を行うことで、外部参照ファイルである20silly.gifというファイル名の画像データファイルをリンクさせ、所要の位置に表示させることができる。
また、ここでのタグの記述は省略しているが、外部参照ファイルとしてオーディオ（音声）データファイルを用意し、所定のタグによって記述を行えば、このオーディオデータファイルもリンクさせて再生出力させることが可能とされている。
また、ここでのタグの記述は省略しているが、外部参照ファイルとしてオーディオ（音声）データファイルを用意し、所定のタグによって記述を行えば、このオーディオデータファイルもリンクさせて再生出力させることが可能とされている。
ここで、マルチメディア情報により先に述べたような音楽配信を行う場合について考えてみる。
この場合において、先ず優先されるべきなのは、楽曲データであるオーディオデータができるだけ高速で正確に送信されることであり、例えばこれに付随する他の種類の情報については、その後に送信されてくるようにすれば、充分に実用的となる。
この場合において、先ず優先されるべきなのは、楽曲データであるオーディオデータができるだけ高速で正確に送信されることであり、例えばこれに付随する他の種類の情報については、その後に送信されてくるようにすれば、充分に実用的となる。
しかし、このような音楽配信用のマルチメディア情報ファイルとしてＨＴＭＬ形式を採用したとすると、この場合には、ＨＴＭＬ記述ファイルと、このＨＴＭＬ記述ファイルの外部参照ファイルとしての配信用楽曲データを送信することになる。つまり、配信のためには、楽曲データだけではなく、必ずＨＴＭＬ記述ファイルを送信することが前提となるものである。
そして、このようなＨＴＭＬ形式とされる１つのマルチメディア情報ファイルにより複数の楽曲データをリンクさせて送信しようとさせた場合には、これらの楽曲データをそれぞれ個別にＨＴＭＬ記述ファイルにリンクさせねばならない。
現実的には、音楽配信サービスにあっては、１つのマルチメディア情報ファイルによって多数の楽曲データを配信することが要求されるために、１つのＨＴＭＬ記述ファイルにリンクさせるべき楽曲データ数としては、相当なものとならざるを得ない。
そして、このようなＨＴＭＬ形式とされる１つのマルチメディア情報ファイルにより複数の楽曲データをリンクさせて送信しようとさせた場合には、これらの楽曲データをそれぞれ個別にＨＴＭＬ記述ファイルにリンクさせねばならない。
現実的には、音楽配信サービスにあっては、１つのマルチメディア情報ファイルによって多数の楽曲データを配信することが要求されるために、１つのＨＴＭＬ記述ファイルにリンクさせるべき楽曲データ数としては、相当なものとならざるを得ない。
これは、例えば楽曲データを配信する側にとっては、音楽配信のためのマルチメディア情報の作成を難しく、また面倒にするものであり、バグなどの発生率も高くなって、それだけ配信側の作業効率を低下させることになる。また、これは作成時の処理速度や転送速度も低下させる要因となる。
また、マルチメディア情報を受信して処理する側においては、ＨＴＭＬの場合には、例えば目的の楽曲データを検索するためには、ＨＴＭＬ記述ファイルをその先頭から読み込んで順次タグの解釈を行っていく必要があるため、非常に時間がかかり、処理負担も重いものとなってしまう。例えば、記述言語としては、ＨＴＭＬのほかにＸＭＬ(Extensible Markup Language)などの、ＷｅｂページなどとしてＨＴＭＬと共に利用されているものも知られているが、上記した問題は、このようなＸＭＬについても同様に生じる。
つまり、多数の音楽データなどの大容量のデータを配信するなどのサービスを、上記したような記述ファイルと外部参照ファイルとにより形成されるような形式のマルチメディア情報ファイルにより行うのは、現実的には適当とはいえないものである。
また、マルチメディア情報を受信して処理する側においては、ＨＴＭＬの場合には、例えば目的の楽曲データを検索するためには、ＨＴＭＬ記述ファイルをその先頭から読み込んで順次タグの解釈を行っていく必要があるため、非常に時間がかかり、処理負担も重いものとなってしまう。例えば、記述言語としては、ＨＴＭＬのほかにＸＭＬ(Extensible Markup Language)などの、ＷｅｂページなどとしてＨＴＭＬと共に利用されているものも知られているが、上記した問題は、このようなＸＭＬについても同様に生じる。
つまり、多数の音楽データなどの大容量のデータを配信するなどのサービスを、上記したような記述ファイルと外部参照ファイルとにより形成されるような形式のマルチメディア情報ファイルにより行うのは、現実的には適当とはいえないものである。
そこで、本発明は上記した課題を考慮して、例えばデータ配信サービスにあたって、データを配信する側とこれを享受する側との双方において、マルチメディア情報の処理負担がより軽くなるようにして、データ配信サービスの充実が図られるようにすることを目的とする。
このため、１以上のブロックデータが格納されるデータエリアと、少なくともデータ内容を識別し得るブロック識別情報とデータエリア内に格納される子ブロックデータ数を示す子ブロックデータ数識別情報とデータ長を示すデータ長識別情報とが配置されるヘッダエリアと、が配置されて成るブロックデータを有するマルチメディア情報を取得する情報取得手段と、上記マルチメディア情報のヘッダエリアにおける上記ブロック識別情報と子ブロックデータ数識別情報及びデータ長識別情報に基づいて、上記情報取得手段により取得したマルチメディア情報から所要のデータを検索して抽出するデータ抽出手段と、上記データ抽出手段により抽出したデータを再生することのできる再生手段とを備えて情報処理装置を構成することとした。
また、情報配信システムとしては次のように構成する。
この情報配信システムは、情報配信装置と、情報受信装置とから成るものとされる。
上記情報配信装置は、１以上のブロックデータが格納されるデータエリアと、少なくともデータ内容を識別し得るブロック識別情報とデータエリア内に格納される子ブロックデータ数を示す子ブロックデータ数識別情報とデータ長を示すデータ長識別情報とが配置されるヘッダエリアと、が配置されて成るブロックデータを有するマルチメディア情報を１以上記憶可能な記憶手段と、上記記憶手段に記憶される１以上のマルチメディア情報のうちから選択したマルチメディア情報を送信出力可能な送信手段とを備えることとした。また、情報受信装置は、上記情報配信装置から送信されるマルチメディア情報を受信する受信手段と、上記マルチメディア情報のヘッダエリアにおける上記ブロック識別情報と子ブロックデータ数識別情報及びデータ長識別情報に基づいて、上記情報取得手段により取得したマルチメディア情報から所要のデータを検索して抽出するデータ抽出手段と、上記データ抽出手段により抽出したデータを再生することのできる再生手段とを備えることとした。
この情報配信システムは、情報配信装置と、情報受信装置とから成るものとされる。
上記情報配信装置は、１以上のブロックデータが格納されるデータエリアと、少なくともデータ内容を識別し得るブロック識別情報とデータエリア内に格納される子ブロックデータ数を示す子ブロックデータ数識別情報とデータ長を示すデータ長識別情報とが配置されるヘッダエリアと、が配置されて成るブロックデータを有するマルチメディア情報を１以上記憶可能な記憶手段と、上記記憶手段に記憶される１以上のマルチメディア情報のうちから選択したマルチメディア情報を送信出力可能な送信手段とを備えることとした。また、情報受信装置は、上記情報配信装置から送信されるマルチメディア情報を受信する受信手段と、上記マルチメディア情報のヘッダエリアにおける上記ブロック識別情報と子ブロックデータ数識別情報及びデータ長識別情報に基づいて、上記情報取得手段により取得したマルチメディア情報から所要のデータを検索して抽出するデータ抽出手段と、上記データ抽出手段により抽出したデータを再生することのできる再生手段とを備えることとした。
また、情報処理方法としては、１以上のブロックデータが格納されるデータエリアと、少なくともデータ内容を識別し得るブロック識別情報とデータエリア内に格納される子ブロックデータ数を示す子ブロックデータ数識別情報とデータ長を示すデータ長識別情報とが配置されるヘッダエリアと、が配置されて成るブロックデータを有するマルチメディア情報を取得する情報取得処理と、上記マルチメディア情報のヘッダエリアにおける上記ブロック識別情報と子ブロックデータ数識別情報及びデータ長識別情報に基づいて、上記情報取得処理により取得したマルチメディア情報から所要のデータを検索して抽出するデータ抽出処理と、上記データ抽出処理により抽出したデータを再生することのできる再生処理とを実行するように構成することとした。
また、プログラムとして、１以上のブロックデータが格納されるデータエリアと、少なくともデータ内容を識別し得るブロック識別情報とデータエリア内に格納される子ブロックデータ数を示す子ブロックデータ数識別情報とデータ長を示すデータ長識別情報とが配置されるヘッダエリアと、が配置されて成るブロックデータを有するマルチメディア情報を取得する情報取得処理と、上記マルチメディア情報のヘッダエリアにおける上記ブロック識別情報と子ブロックデータ数識別情報及びデータ長識別情報に基づいて、上記情報取得処理により取得したマルチメディア情報から所要のデータを検索して抽出するデータ抽出処理と、上記データ抽出処理により抽出したデータを再生することのできる再生処理とを情報処理装置に実行させる構成とした。
上記各構成によれば、本発明が対応するマルチメディア情報としては、データにヘッダが付加された形式とされた上で、ファイル自体としての構造内にデータを格納した構造を有していることになる。換言すれば、テキスト等による記述ファイルと、これにリンクさせた外部参照ファイルからなる構造とは異なるものとされる。そして、本発明では、上記した構造のマルチメディア情報のヘッダ情報の内容に基づいて、このマルチメディア情報から目的のデータを検索して最終的には再生を行うように構成される。この場合、データ再生のためのマルチメディア情報の処理としては、例えば、記述ファイルを参照してリンク先のデータを検索する場合よりも効率的で軽い処理とすることが可能になる。
以上説明したように本発明は、マルチメディア情報としては、ヘッダエリアと実データが格納されるデータエリアとから成るブロックデータを単位として形成される。つまり、実データをそのファイル構造内に埋め込むようにしたフォーマットを有する。そして、このマルチメディア情報を配信する情報配信システム、また、このマルチメディア情報についての処理を行う情報処理装置、及びマルチメディア情報を記録した記録媒体を提供する。
このような本発明の構成では、例えば従来から知られるＨＴＭＬなどのフォーマットをマルチメディア情報に採用する場合と比較して、情報ファイルのの作成、編集は容易となり、また、必要なデータの検索等の処理も軽いものとすることが可能となる。
このような本発明の構成では、例えば従来から知られるＨＴＭＬなどのフォーマットをマルチメディア情報に採用する場合と比較して、情報ファイルのの作成、編集は容易となり、また、必要なデータの検索等の処理も軽いものとすることが可能となる。
そして、例えば本発明が対応するマルチメディア情報のヘッダエリアの情報としては、少なくともファイル名識別情報(Block Name)及びデータ長識別情報(Data Length)の情報を有するようにされており、これによって、例えばマルチメディア情報再生のための検索を行う場合には、ヘッダに記述されたBlock Nameをチェックしながらマルチメディア情報のデータシーケンスを探索していけばよいことになる。また、この際には、Data Lengthを参照することで、容易に次のブロックデータにジャンプすることができ、その検索は高速なものとすることができる。
また本発明が対応するマルチメディア情報では、１つのブロックのデータエリアに対しては子ブロックを格納可能な構造を有するようにされる。そして、ヘッダエリアの情報としては、ブロック名称識別情報(Block Name)、子ブロックデータ数識別情報(Number of Child Blocks)、及びデータ長識別情報(Data Length)の情報を有するようにされる。つまり、本発明が対応する１つのマルチメディア情報としてのファイルをブロックの階層構造により記述することができる。そして、この階層構造を、ヘッダの記述内容によって管理するものである。
これにより、例えば或る関連した内容の複数のデータを、１つのブロック内に階層的に格納することなども可能となり、マルチメディアファイルにおけるデータの管理は容易となる。そしてこれに伴って、上記したファイルの作成・編集はさらに容易なると共に、例えば多数のデータを格納したマルチメディア情報であっても、高速なデータ検索を実現でき、その処理としても軽いものとなる。
また、マルチメディア情報の各エリア間に対して所定長の区切り情報を埋め込むことで、検索時におけるエリア単位の識別も容易で正確となるように配慮されているものである。
これにより、例えば或る関連した内容の複数のデータを、１つのブロック内に階層的に格納することなども可能となり、マルチメディアファイルにおけるデータの管理は容易となる。そしてこれに伴って、上記したファイルの作成・編集はさらに容易なると共に、例えば多数のデータを格納したマルチメディア情報であっても、高速なデータ検索を実現でき、その処理としても軽いものとなる。
また、マルチメディア情報の各エリア間に対して所定長の区切り情報を埋め込むことで、検索時におけるエリア単位の識別も容易で正確となるように配慮されているものである。
以下、本発明の実施の形態について説明を行っていくこととする。
なお、以降の説明は次の順序で行う。
１．情報配信システム
１−１．全体構成
１−２．サーバと配信端末装置の内部構成
１−３．記録再生装置
２．マルチメディアファイル
２−１．基本構造
２−２．具体的構造例
３．再生処理
なお、以降の説明は次の順序で行う。
１．情報配信システム
１−１．全体構成
１−２．サーバと配信端末装置の内部構成
１−３．記録再生装置
２．マルチメディアファイル
２−１．基本構造
２−２．具体的構造例
３．再生処理
１．情報配信システム
１−１．全体構成
本発明の実施の形態の情報配信システムとしては、楽曲としてのオーディオデータを配信するサービスを行うためのシステムを例に挙げるものとする。
図１は、この本実施の形態としての情報配信システムの全体構成を示している。
この図においてサーバ１００は、配信用データとしてのマルチメディアファイルを多数記憶している。このマルチメディアファイルは、詳しいことについては後述するが、主としては１以上の楽曲としてのオーディオデータ（楽曲データ）のほか、例えば楽曲データに付随したジャケットなどの画像データや、歌詞などのテキストデータも格納することができるようになっている。また、このようなマルチメディアファイルは、例えば、ここでは図示しないレコード制作会社などから供給される。
そして、このサーバ１００は、通信網２００を介して多数の配信端末装置３００と通信可能に構成されている。サーバ１００は上記通信網２００を介してマルチメディアファイルを送信する。
１−１．全体構成
本発明の実施の形態の情報配信システムとしては、楽曲としてのオーディオデータを配信するサービスを行うためのシステムを例に挙げるものとする。
図１は、この本実施の形態としての情報配信システムの全体構成を示している。
この図においてサーバ１００は、配信用データとしてのマルチメディアファイルを多数記憶している。このマルチメディアファイルは、詳しいことについては後述するが、主としては１以上の楽曲としてのオーディオデータ（楽曲データ）のほか、例えば楽曲データに付随したジャケットなどの画像データや、歌詞などのテキストデータも格納することができるようになっている。また、このようなマルチメディアファイルは、例えば、ここでは図示しないレコード制作会社などから供給される。
そして、このサーバ１００は、通信網２００を介して多数の配信端末装置３００と通信可能に構成されている。サーバ１００は上記通信網２００を介してマルチメディアファイルを送信する。
配信端末装置３００は、例えば各駅にある売店、コンビニエンスストア、公衆電話、各家庭等に設置されるもので、サーバ１００から送信されたマルチメディアファイルを受信し、受信によって得られたマルチメディアファイルを比較的多数記憶しておくことが可能とされている。
また、配信端末装置３００の本体に設けられるメディア挿脱部３０７ａに対しては、所定の記録媒体を装填可能とされている。ここでは、メディア挿脱部３０７ａに対して装填できるメディアとしては、所定方式の圧縮オーディオデータを記録再生することのできるＭＤ(Mini Disc)であるものとしている。また、本体に対しては、楽曲データのダウンロードを行うための各種操作子からなる操作部３０５と、このダウンロードに関する所要の各種表示が行われる表示部３０６が設けられている。
また、配信端末装置３００の本体に設けられるメディア挿脱部３０７ａに対しては、所定の記録媒体を装填可能とされている。ここでは、メディア挿脱部３０７ａに対して装填できるメディアとしては、所定方式の圧縮オーディオデータを記録再生することのできるＭＤ(Mini Disc)であるものとしている。また、本体に対しては、楽曲データのダウンロードを行うための各種操作子からなる操作部３０５と、このダウンロードに関する所要の各種表示が行われる表示部３０６が設けられている。
例えば記録再生装置１のユーザは、自分が所有するＭＤとしてのディスク９０をメディア挿脱部３０７ａに対して装填に対して装填しておき、操作部３０５に対する操作によって、ダウンロードしたいとする所望の楽曲データ指定して、例えば購買契約を結ぶ。
配信端末装置３００では、内部に記憶している複数のマルチメディアファイルのうちから、指定された楽曲データを検索して抽出し、この抽出した楽曲データを、メディア挿脱部３０７ａに装填されているディスク９０に書き込む。これにより、ユーザが購買したとされる楽曲データが、自分の所有するディスク９０にダウンロードされることになる。
配信端末装置３００では、内部に記憶している複数のマルチメディアファイルのうちから、指定された楽曲データを検索して抽出し、この抽出した楽曲データを、メディア挿脱部３０７ａに装填されているディスク９０に書き込む。これにより、ユーザが購買したとされる楽曲データが、自分の所有するディスク９０にダウンロードされることになる。
この図に示される記録再生装置１は、ユーザが所有するもので、ＭＤに対応してオーディオデータの記録再生が可能とされている。例えばユーザは、上記のようにして、ダウンロードした楽曲データが記録されたディスク９０を記録再生装置１に対して装填し、この楽曲データとしてのトラックの再生を行うことで、この購買した楽曲を聴くことができる。
なお、ＭＤフォーマットとして、例えばオーディオデータだけではなく、これに付随した静止画像データやテキストデータなどのいわゆるＡＵＸデータも記録再生可能なものが提案されているが、本実施の形態においても、マルチメディアファイルに対してこれらのＡＵＸデータとしての情報を格納し、配信端末装置３００により、装填されたディスク９０に対して、オーディオデータと共にＡＵＸデータを記録することが可能とされている。
また、この場合にユーザが所有するＭＤに対応する装置としては、再生専用機とされてもかまわないものである。
また、配信端末装置３００としては、例えば通信網２００を介してサーバ１００と双方向通信が可能な構成を採っているのであれば、配信端末装置３００側で必要とされるマルチメディアファイルをサーバ１００に要求して送信してもらうようにすることも可能である。
また、この場合にユーザが所有するＭＤに対応する装置としては、再生専用機とされてもかまわないものである。
また、配信端末装置３００としては、例えば通信網２００を介してサーバ１００と双方向通信が可能な構成を採っているのであれば、配信端末装置３００側で必要とされるマルチメディアファイルをサーバ１００に要求して送信してもらうようにすることも可能である。
このように、本実施の形態の情報配信システムでは、サーバ１００から送信されてくる情報を配信端末装置３００により格納しておき、この配信端末装置３００に格納された情報のうちから、ユーザがリクエストした情報を、記録再生装置１が対応可能な記録媒体にコピーすることができるものである。
なお、上記通信網２００としては特に限定されるものではなく、例えば通信衛星、ＩＳＤＮ(Integrated services digital network) 、ＣＡＴＶ(Cable Television,Community Antenna Television) 、アナログ電話回線、各種ワイヤレス通信等を利用することが考えられる。
１−２．サーバと配信端末装置の内部構成
図２は、サーバ１００及び配信端末装置３００の内部構成例を示している。
この図に示されるサーバ１は、例えば図示するように、制御部１０１、記憶部１０２、検索部１０３、インターフェイス部１０４を備えて構成されており、これら各機能回路部はバスラインを介して情報送受信が可能なように接続されている。
制御部１０１は、例えばコンピュータ装置等を備えて構成され、サーバ１００内における各部に対する制御及び各種処理を実行する。
図２は、サーバ１００及び配信端末装置３００の内部構成例を示している。
この図に示されるサーバ１は、例えば図示するように、制御部１０１、記憶部１０２、検索部１０３、インターフェイス部１０４を備えて構成されており、これら各機能回路部はバスラインを介して情報送受信が可能なように接続されている。
制御部１０１は、例えばコンピュータ装置等を備えて構成され、サーバ１００内における各部に対する制御及び各種処理を実行する。
インターフェイス部１０４は、通信網２００を介して、配信端末装置３００と通信を行うために設けられる。なお、送信時の伝送プロトコルについては独自のプロトコルであってもよいし、又はインターネットで汎用となっているＴＣＰ／ＩＰ(Transmission control protocol/internet protocol ）等でパケット化されてデータ送信されるものであってもよい。
検索部１０３は、制御部１０１の制御によって、記憶部１０２に記憶されているデータから所要のデータを検索する処理を実行するために設けられる。或るマルチメディアファイルを指定して配信端末装置３００に対して送信する必要のある場合には、この検索部１０３の処理によって、記憶部１０２に記憶されているデータのうちから、送信すべきマルチメディアファイルを検索するようにされる。
記憶部１０２は、例えば大容量の記録媒体と、この記録媒体を駆動するためのドライバ装置等を備えて構成され、配信用データである多数のマルチメディアファイル４０１が記憶されて格納されている。また、この他にも、課金設定情報などのユーザ関連データをはじめとする、配信サービスに関連する所要の情報を格納してもよいものとされる。
ここで、記憶部１０２としての媒体は、現在の放送用機器に用いられる磁気テープ等も考えられるが、ランダムアクセス可能なハードディスク、ＩＣメモリ、光ディスク、光磁気ディスク等を採用すればランダムアクセスが可能となるために、データの記憶及び呼び出しの効率が向上して好ましい。
ここで、記憶部１０２としての媒体は、現在の放送用機器に用いられる磁気テープ等も考えられるが、ランダムアクセス可能なハードディスク、ＩＣメモリ、光ディスク、光磁気ディスク等を採用すればランダムアクセスが可能となるために、データの記憶及び呼び出しの効率が向上して好ましい。
配信端末装置３００は、制御部３０１、メイン記憶部３０２、サブ記憶部３０３、ユーザインターフェイス部３０４、操作部３０５、表示部３０６、インターフェイス部３０８、メディアドライバ３０７の各機能回路部がデータバスにより接続されて構成されている。
このシステムにあっては、例えば電源が投入されると、例えばここでは図示しないサブ記憶部３０３としてのＲＯＭに記憶された基本入出力起動情報によって、内部の各機能回路部の基本的動作が可能になる。この後、制御部３０１は、例えばメイン記憶部３０２に格納されているシステム制御情報４０５を読み出すことで、配信端末装置３００としての基本的システム動作が可能となるように処理を実行する。
メイン記憶部３０２は、例えばハードディスクなどをはじめとする、比較的大容量のデータを記憶可能なストレージデバイスとされ、サーバ１００から送信されてきた多数のマルチメディアファイル４００が格納される。
また、この場合には、マルチメディアファイルについての処理を行うためのアプリケーションプログラムである、マルチメディアファイル用プログラム４０１も格納されているものとされ、制御部３０１は、このマルチメディアファイル用プログラム４０１を読み込んで起動させることによって、ユーザ操作に応じてのＭＤに対するデータのダウンロード動作を実行することが可能とされる。
また、上記したシステム制御情報４０５も、このメイン記憶部３０２に格納されているものとされる。
また、この場合には、マルチメディアファイルについての処理を行うためのアプリケーションプログラムである、マルチメディアファイル用プログラム４０１も格納されているものとされ、制御部３０１は、このマルチメディアファイル用プログラム４０１を読み込んで起動させることによって、ユーザ操作に応じてのＭＤに対するデータのダウンロード動作を実行することが可能とされる。
また、上記したシステム制御情報４０５も、このメイン記憶部３０２に格納されているものとされる。
ここで、上記マルチメディアファイル用プログラム４０１としては、図のように、検索プログラム４０２、データ識別プログラム４０３、及び再生プログラム４０４を備えて形成されている。
簡単に説明しておくと、検索プログラム４０２は、メイン記憶部３０２に記憶されているマルチメディアファイルのうちから、指定されたマルチメディアファイルを検索して特定するためのプログラムであり、データ識別プログラム４０３は、検索されたマルチメディアファイルにおいて、後述する構造により格納されているブロック（データ）を検索して特定するためのプログラムとされる。そして、再生プログラム４０４は、データ識別プログラム４０３により検索されたブロック内のデータを再生処理を実行するためのプログラムである。
なお、ここでいうところの、データの「再生処理」の意味としては、例えば、オーディオデータであればこれをオーディオ信号として再生出力するための処理のみに限定されるものではない。本実施の形態の場合であれば、例えばメディアに書き込むための転送処理など、例えばマルチメディアファイルからデータを抽出し、この抽出したデータについて何らかの処理を行うことも「再生処理」として含められるものである。
簡単に説明しておくと、検索プログラム４０２は、メイン記憶部３０２に記憶されているマルチメディアファイルのうちから、指定されたマルチメディアファイルを検索して特定するためのプログラムであり、データ識別プログラム４０３は、検索されたマルチメディアファイルにおいて、後述する構造により格納されているブロック（データ）を検索して特定するためのプログラムとされる。そして、再生プログラム４０４は、データ識別プログラム４０３により検索されたブロック内のデータを再生処理を実行するためのプログラムである。
なお、ここでいうところの、データの「再生処理」の意味としては、例えば、オーディオデータであればこれをオーディオ信号として再生出力するための処理のみに限定されるものではない。本実施の形態の場合であれば、例えばメディアに書き込むための転送処理など、例えばマルチメディアファイルからデータを抽出し、この抽出したデータについて何らかの処理を行うことも「再生処理」として含められるものである。
サブ記憶部３０３は、例えばＲＯＭ、ＲＡＭ等のメモリによって構成される。例えばＲＯＭには、上記した基本入出力起動情報等の情報が記憶される。また、ＲＡＭは、例えば制御部３０１が処理を実行する際に発生するデータや、各機能回路部が動作を実行する際の処理データなどが保持される。
ユーザインターフェイス部３０４は、操作部３０５及び表示部３０６などのユーザインターフェイスのために設けられている。例えば操作部３０５に対して行われた操作に応じて得られる操作情報を制御部３０１に対して転送し、また、制御部３０１の制御によって送信されてくる表示データを表示部３０６に対して転送することで、表示部３０６に対して所要の内容の表示を実行させる。
また、インターフェイス部３０８は、通信網２００を介してサーバ１００と通信するためのインターフェイスとされる。
メディアドライバ３０７は、前述したようにしてメディア挿脱部３０７ａから装填されたメディアに対応してデータの記録再生が可能とされる。本実施の形態の場合、メディアとしてはＭＤとされていることから、この場合のメディアドライバ３０７としてはＭＤに対応して記録再生が可能な構成を採ることになる。そして、本実施の形態としては、マルチメディアファイルに格納されているデータのうちで、ＭＤに記録可能なフォーマットのデータを、このメディアドライバ３０７によってＭＤに記録するようにされる。
１−３．記録再生装置
図３は本実施の形態のミニディスク記録再生装置１の内部構成を示す。
音声データが記録される光磁気ディスク（ミニディスク）９０は、スピンドルモータ２により回転駆動される。そして光磁気ディスク９０に対しては記録／再生時に光学ヘッド３によってレーザ光が照射される。
図３は本実施の形態のミニディスク記録再生装置１の内部構成を示す。
音声データが記録される光磁気ディスク（ミニディスク）９０は、スピンドルモータ２により回転駆動される。そして光磁気ディスク９０に対しては記録／再生時に光学ヘッド３によってレーザ光が照射される。
光学ヘッド３は、記録時には記録トラックをキュリー温度まで加熱するための高レベルのレーザ出力を行ない、また再生時には磁気カー効果により反射光からデータを検出するための比較的低レベルのレーザ出力を行なう。
このため、光学ヘッド３にはレーザ出力手段としてのレーザダイオード、偏光ビームスプリッタや対物レンズ等からなる光学系、及び反射光を検出するためのディテクタ等が搭載されている。対物レンズ３ａは２軸機構４によってディスク半径方向及びディスクに接離する方向に変位可能に保持されている。
このため、光学ヘッド３にはレーザ出力手段としてのレーザダイオード、偏光ビームスプリッタや対物レンズ等からなる光学系、及び反射光を検出するためのディテクタ等が搭載されている。対物レンズ３ａは２軸機構４によってディスク半径方向及びディスクに接離する方向に変位可能に保持されている。
また、ディスク９０を挟んで光学ヘッド３と対向する位置に磁気ヘッド６ａが配置されている。磁気ヘッド６ａは供給されたデータによって変調された磁界を光磁気ディスク９０に印加する動作を行なう。
光学ヘッド３全体及び磁気ヘッド６ａは、スレッド機構５によりディスク半径方向に移動可能とされている。
光学ヘッド３全体及び磁気ヘッド６ａは、スレッド機構５によりディスク半径方向に移動可能とされている。
再生動作によって、光学ヘッド３によりディスク９０から検出された情報はＲＦアンプ７に供給される。ＲＦアンプ７は供給された情報の演算処理により、再生ＲＦ信号、トラッキングエラー信号ＴＥ、フォーカスエラー信号ＦＥ、グルーブ情報（光磁気ディスク９０にプリグルーブ（ウォブリンググルーブ）として記録されている絶対位置情報）ＧＦＭ等を抽出する。
抽出された再生ＲＦ信号はエンコーダ／デコーダ部８に供給される。また、トラッキングエラー信号ＴＥ、フォーカスエラー信号ＦＥはサーボ回路９に供給され、グルーブ情報ＧＦＭはアドレスデコーダ１０に供給される。
抽出された再生ＲＦ信号はエンコーダ／デコーダ部８に供給される。また、トラッキングエラー信号ＴＥ、フォーカスエラー信号ＦＥはサーボ回路９に供給され、グルーブ情報ＧＦＭはアドレスデコーダ１０に供給される。
サーボ回路９は供給されたトラッキングエラー信号ＴＥ、フォーカスエラー信号ＦＥや、マイクロコンピュータにより構成されるシステムコントローラ１１からのトラックジャンプ指令、アクセス指令、スピンドルモータ２の回転速度検出情報等により各種サーボ駆動信号を発生させ、２軸機構４及びスレッド機構５を制御してフォーカス及びトラッキング制御を行ない、またスピンドルモータ２を一定線速度（ＣＬＶ）に制御する。
アドレスデコーダ１０は供給されたグルーブ情報ＧＦＭをデコードしてアドレス情報を抽出する。このアドレス情報はシステムコントローラ１１に供給され、各種の制御動作に用いられる。
また再生ＲＦ信号についてはエンコーダ／デコーダ部８においてＥＦＭ復調、ＣＩＲＣ等のデコード処理が行なわれるが、このときアドレス、サブコードデータなども抽出され、システムコントローラ１１に供給される。
また再生ＲＦ信号についてはエンコーダ／デコーダ部８においてＥＦＭ復調、ＣＩＲＣ等のデコード処理が行なわれるが、このときアドレス、サブコードデータなども抽出され、システムコントローラ１１に供給される。
エンコーダ／デコーダ部８でＥＦＭ復調、ＣＩＲＣ等のデコード処理された音声データ（セクターデータ）は、メモリコントローラ１２によって一旦バッファメモリ１３に書き込まれる。なお、光学ヘッド３によるディスク９０からのデータの読み取り及び光学ヘッド３からバッファメモリ１３までの系における再生データの転送は1.41Mbit/secで、しかも通常は間欠的に行なわれる。
バッファメモリ１３に書き込まれたデータは、再生データの転送が0.3Mbit/sec となるタイミングで読み出され、エンコーダ／デコーダ部１４に供給される。そして、音声圧縮処理に対するデコード処理等の再生信号処理を施され、４４．１ＫＨZ サンプリング、１６ビット量子化のデジタルオーディオ信号とされる。 このデジタルオーディオ信号はＤ／Ａ変換器１５によってアナログ信号とされ、出力処理部１６でレベル調整、インピーダンス調整等が行われてライン出力端子１７からアナログオーディオ信号Ａｏｕｔとして外部機器に対して出力される。またヘッドホン出力ＨＰｏｕｔとしてヘッドホン出力端子２７に供給され、接続されるヘッドホンに出力される。
また、エンコーダ／デコーダ部１４でデコードされた状態のデジタルオーディオ信号は、デジタルインターフェース部２２に供給されることで、デジタル出力端子２１からデジタルオーディオ信号Ｄｏｕｔとして外部機器に出力することもできる。例えば光ケーブルによる伝送形態で外部機器に出力される。
光磁気ディスク９０に対して記録動作が実行される際には、ライン入力端子１８に供給された記録信号（アナログオーディオ信号Ａｉｎ）は、Ａ／Ｄ変換器１９によってデジタルデータとされた後、エンコーダ／デコーダ部１４に供給され、音声圧縮エンコード処理を施される。
または外部機器からデジタル入力端子２０にデジタルオーディオ信号Ｄｉｎが供給された場合は、デジタルインターフェース部２２で制御コード等の抽出が行われるとともに、そのオーディオデータがエンコーダ／デコーダ部１４に供給され、音声圧縮エンコード処理を施される。
なお図示していないがマイクロホン入力端子を設け、マイクロホン入力を記録信号として用いることも当然可能である。
または外部機器からデジタル入力端子２０にデジタルオーディオ信号Ｄｉｎが供給された場合は、デジタルインターフェース部２２で制御コード等の抽出が行われるとともに、そのオーディオデータがエンコーダ／デコーダ部１４に供給され、音声圧縮エンコード処理を施される。
なお図示していないがマイクロホン入力端子を設け、マイクロホン入力を記録信号として用いることも当然可能である。
エンコーダ／デコーダ部１４によって圧縮された記録データはメモリコントローラ１２によって一旦バッファメモリ１３に書き込まれて蓄積されていった後、所定量のデータ単位毎に読み出されてエンコーダ／デコーダ部８に送られる。そしてエンコーダ／デコーダ部８でＣＩＲＣエンコード、ＥＦＭ変調等のエンコード処理された後、磁気ヘッド駆動回路６に供給される。
磁気ヘッド駆動回路６はエンコード処理された記録データに応じて、磁気ヘッド６ａに磁気ヘッド駆動信号を供給する。つまり、光磁気ディスク９０に対して磁気ヘッド６ａによるＮ又はＳの磁界印加を実行させる。また、このときシステムコントローラ１１は光学ヘッドに対して、記録レベルのレーザ光を出力するように制御信号を供給する。
操作部２３はユーザー操作に供される部位を示し、各種操作キーやダイヤルとしての操作子が設けられる。操作子としては例えば、再生、録音、一時停止、停止、ＦＦ（早送り）、ＲＥＷ（早戻し）、ＡＭＳ（頭出しサーチ）などの記録再生動作にかかる操作子や、通常再生、プログラム再生、シャッフル再生などのプレイモードにかかる操作子、さらには表示部２４における表示状態を切り換える表示モード操作のための操作子、トラック（プログラム）分割、トラック連結、トラック消去、トラックネーム入力、ディスクネーム入力などのプログラム編集操作のための操作子、さらには本実施の形態における後述するＡＵＸデータの記録、再生、動作モードなどの操作に必要な操作子が設けられている。
これらの操作キーやダイヤルによる操作情報はシステムコントローラ１１に供給され、システムコントローラ１１は操作情報に応じた動作制御を実行することになる。
これらの操作キーやダイヤルによる操作情報はシステムコントローラ１１に供給され、システムコントローラ１１は操作情報に応じた動作制御を実行することになる。
表示部２４の表示動作はシステムコントローラ１１によって制御される。
即ちシステムコントローラ１１は表示動作を実行させる際に表示すべきデータを表示部２４内の表示ドライバに送信する。表示ドライバは供給されたデータに基づいて液晶パネルなどによるディスプレイの表示動作を駆動し、所要の数字、文字、記号などの表示を実行させる。
表示部２４においては、記録／再生しているディスクの動作モード状態、トラックナンバ、記録時間／再生時間、編集動作状態等が示される。
またディスク９０には主データたるプログラムに付随して管理される文字情報（トラックネーム等）が記録できるが、その文字情報の入力の際の入力文字の表示や、ディスクから読み出した文字情報の表示などが実行される。
さらに本実施の形態の場合、ディスク９０には、プログラムとしての楽曲等のデータとは独立したデータファイルとなる副データ（ＡＵＸデータ）が記録されることができる。ＡＵＸデータとしてのデータファイルは、文字、静止画などの情報となるが、これらの文字や静止画を表示部２４で出力できるようにしてもよい。
即ちシステムコントローラ１１は表示動作を実行させる際に表示すべきデータを表示部２４内の表示ドライバに送信する。表示ドライバは供給されたデータに基づいて液晶パネルなどによるディスプレイの表示動作を駆動し、所要の数字、文字、記号などの表示を実行させる。
表示部２４においては、記録／再生しているディスクの動作モード状態、トラックナンバ、記録時間／再生時間、編集動作状態等が示される。
またディスク９０には主データたるプログラムに付随して管理される文字情報（トラックネーム等）が記録できるが、その文字情報の入力の際の入力文字の表示や、ディスクから読み出した文字情報の表示などが実行される。
さらに本実施の形態の場合、ディスク９０には、プログラムとしての楽曲等のデータとは独立したデータファイルとなる副データ（ＡＵＸデータ）が記録されることができる。ＡＵＸデータとしてのデータファイルは、文字、静止画などの情報となるが、これらの文字や静止画を表示部２４で出力できるようにしてもよい。
但し、ＡＵＸデータとしての文字情報や静止画情報を出力するには、比較的大画面となり、かつ画面上を或る程度自由に使用できるフルドットディスプレイやＣＲＴディスプレイが好適な場合も多く、このため、ＡＵＸデータの表示出力はインターフェース部２５を介して外部のモニタ装置などにおいて実行するようにすることが考えられる。
またＡＵＸデータファイルはユーザーがディスク９０に記録させることもできるが、その場合の入力としてイメージスキャナ、パーソナルコンピュータ、キーボード等を用いることが必要になる場合があり、そのような装置からＡＵＸデータファイルとしての情報をインターフェース部２５を介して入力することが考えられる。
またＡＵＸデータファイルはユーザーがディスク９０に記録させることもできるが、その場合の入力としてイメージスキャナ、パーソナルコンピュータ、キーボード等を用いることが必要になる場合があり、そのような装置からＡＵＸデータファイルとしての情報をインターフェース部２５を介して入力することが考えられる。
システムコントローラ１１は、ＣＰＵ、プログラムＲＯＭ、ワークＲＡＭ、インターフェース部等を備えたマイクロコンピュータとされ、上述してきた各種動作の制御を行う。
ところで、ディスク９０に対して記録／再生動作を行なう際には、ディスク９０に記録されている管理情報、即ちＰ−ＴＯＣ（プリマスタードＴＯＣ）、Ｕ−ＴＯＣ（ユーザーＴＯＣ）を読み出す必要がある。システムコントローラ１１はこれらの管理情報に応じてディスク９０上の記録すべきエリアのアドレスや、再生すべきエリアのアドレスを判別することとなる。
この管理情報はバッファメモリ１３に保持される。
そして、システムコントローラ１１はこれらの管理情報を、ディスク９０が装填された際に管理情報の記録されたディスクの最内周側の再生動作を実行させることによって読み出し、バッファメモリ１３に記憶しておき、以後そのディスク９０に対するプログラムの記録／再生／編集動作の際に参照できるようにしている。
この管理情報はバッファメモリ１３に保持される。
そして、システムコントローラ１１はこれらの管理情報を、ディスク９０が装填された際に管理情報の記録されたディスクの最内周側の再生動作を実行させることによって読み出し、バッファメモリ１３に記憶しておき、以後そのディスク９０に対するプログラムの記録／再生／編集動作の際に参照できるようにしている。
また、Ｕ−ＴＯＣはプログラムデータの記録や各種編集処理に応じて書き換えられるものであるが、システムコントローラ１１は記録／編集動作のたびに、Ｕ−ＴＯＣ更新処理をバッファメモリ１３に記憶されたＵ−ＴＯＣ情報に対して行ない、その書換動作に応じて所定のタイミングでディスク９０のＵ−ＴＯＣエリアについても書き換えるようにしている。
またディスク９０にはプログラムとは別にＡＵＸデータファイルが記録されるが、そのＡＵＸデータファイルの管理のためにディスク９０上にはＡＵＸ−ＴＯＣが形成される。
システムコントローラ１１はＵ−ＴＯＣの読出の際にＡＵＸ−ＴＯＣの読出も行い、バッファメモリ１３に格納して必要時にＡＵＸデータ管理状態を参照できるようにしている。
またシステムコントローラ１１は必要に応じて所定タイミングで（もしくはＡＵＸ−ＴＯＣの読出の際に同時に）ＡＵＸデータファイルを読み込み、バッファメモリ１３に格納する。そしてＡＵＸ−ＴＯＣで管理される出力タイミングに応じて表示部２４や、インターフェース部２５を介した外部機器における文字や画像の出力動作を実行させる。
システムコントローラ１１はＵ−ＴＯＣの読出の際にＡＵＸ−ＴＯＣの読出も行い、バッファメモリ１３に格納して必要時にＡＵＸデータ管理状態を参照できるようにしている。
またシステムコントローラ１１は必要に応じて所定タイミングで（もしくはＡＵＸ−ＴＯＣの読出の際に同時に）ＡＵＸデータファイルを読み込み、バッファメモリ１３に格納する。そしてＡＵＸ−ＴＯＣで管理される出力タイミングに応じて表示部２４や、インターフェース部２５を介した外部機器における文字や画像の出力動作を実行させる。
次に、図４により、ＭＤフォーマットにおいて規定されるデータ単位であるセクター、クラスタについて説明する。
ミニディスクシステムでの記録トラックとしては図４のようにクラスタＣＬが連続して形成されており、１クラスタが記録時の最小単位とされる。１クラスタは２〜３周回トラック分に相当する。
ミニディスクシステムでの記録トラックとしては図４のようにクラスタＣＬが連続して形成されており、１クラスタが記録時の最小単位とされる。１クラスタは２〜３周回トラック分に相当する。
そして１つのクラスタＣＬは、セクターＳFC〜ＳFFとされる４セクターのリンキング領域と、セクターＳ00〜Ｓ1Fとして示す３２セクターのメインデータ領域から形成されている。
１セクタは２３５２バイトで形成されるデータ単位である。
４セクターのサブデータ領域のうち、セクターＳFFはサブデータセクタとされ、サブデータとしての情報記録に使用できるが、セクターＳFC〜ＳFEの３セクターはデータ記録には用いられない。
一方、ＴＯＣデータ、オーディオデータ、ＡＵＸデータ等の記録は３２セクター分のメインデータ領域に行なわれる。
なお、アドレスは１セクター毎に記録される。
１セクタは２３５２バイトで形成されるデータ単位である。
４セクターのサブデータ領域のうち、セクターＳFFはサブデータセクタとされ、サブデータとしての情報記録に使用できるが、セクターＳFC〜ＳFEの３セクターはデータ記録には用いられない。
一方、ＴＯＣデータ、オーディオデータ、ＡＵＸデータ等の記録は３２セクター分のメインデータ領域に行なわれる。
なお、アドレスは１セクター毎に記録される。
また、セクターはさらにサウンドグループという単位に細分化され、２セクターが１１サウンドグループに分けられている。
つまり図示するように、セクターＳ00などの偶数セクターと、セクターＳ01などの奇数セクターの連続する２つのセクターに、サウンドグループＳＧ00〜ＳＧ0Aが含まれる状態となっている。１つのサウンドグループは４２４バイトで形成されており、11.61msec の時間に相当する音声データ量となる。
１つのサウンドグループＳＧ内にはデータがＬチャンネルとＲチャンネルに分けられて記録される。例えばサウンドグループＳＧ00はＬチャンネルデータＬ０とＲチャンネルデータＲ０で構成され、またサウンドグループＳＧ01はＬチャンネルデータＬ１とＲチャンネルデータＲ１で構成される。
なお、Ｌチャンネル又はＲチャンネルのデータ領域となる２１２バイトをサウンドフレームとよんでいる。
つまり図示するように、セクターＳ00などの偶数セクターと、セクターＳ01などの奇数セクターの連続する２つのセクターに、サウンドグループＳＧ00〜ＳＧ0Aが含まれる状態となっている。１つのサウンドグループは４２４バイトで形成されており、11.61msec の時間に相当する音声データ量となる。
１つのサウンドグループＳＧ内にはデータがＬチャンネルとＲチャンネルに分けられて記録される。例えばサウンドグループＳＧ00はＬチャンネルデータＬ０とＲチャンネルデータＲ０で構成され、またサウンドグループＳＧ01はＬチャンネルデータＬ１とＲチャンネルデータＲ１で構成される。
なお、Ｌチャンネル又はＲチャンネルのデータ領域となる２１２バイトをサウンドフレームとよんでいる。
次に図５により、ミニディスクフォーマットでのアドレス形式を説明する。
各セクターは、クラスタアドレスとセクターアドレスによってアドレスが表現される。そして図５上段に示すようにクラスタアドレスは１６ビット（＝２バイト）、セクターアドレスは８ビット（＝１バイト）の数値となる。
この３バイト分のアドレスが、各セクターの先頭位置に記録される。
各セクターは、クラスタアドレスとセクターアドレスによってアドレスが表現される。そして図５上段に示すようにクラスタアドレスは１６ビット（＝２バイト）、セクターアドレスは８ビット（＝１バイト）の数値となる。
この３バイト分のアドレスが、各セクターの先頭位置に記録される。
さらに４ビットのサウンドグループアドレスを追加することで、セクター内のサウンドグループの番地も表現することができる。例えばＵ−ＴＯＣなどの管理上において、サウンドグループアドレスまで表記することで、サウンドグループ単位での再生位置設定なども可能となる。
ところでＵ−ＴＯＣやＡＵＸ−ＴＯＣなどにおいては、クラスタアドレス、セクターアドレス、サウンドグループアドレスを３バイトで表現するために、図５下段に示すような短縮型のアドレスが用いられる。
まずセクターは１クラスタに３６セクターであるため６ビットで表現できる。従ってセクターアドレスの上位２ビットは省略できる。同様にクラスタもディスク最外周まで１４ビットで表現できるためクラスタアドレスの上位２ビットは省略できる。
このようにセクターアドレス、クラスタアドレスの上位各２ビットづつを省略することで、サウンドグループまで指定できるアドレスを３バイトで表現できる。
まずセクターは１クラスタに３６セクターであるため６ビットで表現できる。従ってセクターアドレスの上位２ビットは省略できる。同様にクラスタもディスク最外周まで１４ビットで表現できるためクラスタアドレスの上位２ビットは省略できる。
このようにセクターアドレス、クラスタアドレスの上位各２ビットづつを省略することで、サウンドグループまで指定できるアドレスを３バイトで表現できる。
また、後述するＵ−ＴＯＣ、ＡＵＸ−ＴＯＣでは、再生位置、再生タイミング等を管理するアドレスは、上記の短縮型のアドレスで表記するが、そのアドレスとしては、絶対アドレス形態で示す例以外に、オフセットアドレスで示す例も考えられる。オフセットアドレスとは、例えば楽曲等の各プログラムの先頭位置をアドレス０の位置としてそのプログラム内の位置を示す相対的なアドレスである。このオフセットアドレスの例を図６で説明する。
楽曲等のプログラムが記録されるのは、図７を用いて後述するが、ディスク上の第５０クラスタ（１６進表現でクラスタ３２ｈ：以下、本明細書において「ｈ」を付した数字は１６進表記での数値とする）からとなる。
例えば第１プログラムの先頭位置のアドレス（クラスタ３２ｈ、セクター００ｈ、サウンドグループ０ｈ）のアドレス値は図６（ａ）上段に示すのように、「００００００００００１１００１０００００００００００００」（つまり００３２ｈ、００ｈ、０ｈ）となる。これを短縮形で示すと、図６（ａ）下段のように、「００００００００１１００１０００００００００００」（つまり００ｈ、Ｃ８ｈ、００ｈ）となる。
例えば第１プログラムの先頭位置のアドレス（クラスタ３２ｈ、セクター００ｈ、サウンドグループ０ｈ）のアドレス値は図６（ａ）上段に示すのように、「００００００００００１１００１０００００００００００００」（つまり００３２ｈ、００ｈ、０ｈ）となる。これを短縮形で示すと、図６（ａ）下段のように、「００００００００１１００１０００００００００００」（つまり００ｈ、Ｃ８ｈ、００ｈ）となる。
この先頭アドレスを起点として、第１プログラム内のある位置として、例えばクラスタ００３２ｈ、セクター０４ｈ、サウンドグループ０ｈのアドレスは、図６（ｂ）のように短縮形の絶対アドレスでは「００ｈ、Ｃ８ｈ、４０ｈ」となり、一方オフセットアドレスは、先頭アドレスを起点とした差分でクラスタ００００ｈ、セクター０４ｈ、サウンドグループ０ｈを表現すればよいため、「００ｈ、００ｈ、４０ｈ」となる。
また図６（ａ）の先頭アドレスを起点として、第１プログラム内のある位置として、例えばクラスタ００３２ｈ、セクター１３ｈ、サウンドグループ９ｈのアドレスは、図６（ｃ）のように短縮形の絶対アドレスでは「００ｈ、Ｃ９ｈ、３９ｈ」となり、一方オフセットアドレスは「００ｈ、０１ｈ、３９ｈ」となる。
例えばこれらの例のように、絶対アドレス又はオフセットアドレスにより、プログラム内の位置などを指定できる。
例えばこれらの例のように、絶対アドレス又はオフセットアドレスにより、プログラム内の位置などを指定できる。
また、本実施の形態としてのディスク９０（ＭＤ）のエリア構造を図７で説明する。
図７（ａ）はディスク最内周側から最外周側までのエリアを示している。
光磁気ディスクとしてのディスク９０は、最内周側はエンボスピットにより再生専用のデータが形成されるピット領域とされており、ここにＰ−ＴＯＣが記録されている。
ピット領域より外周は、光磁気領域とされ、記録トラックの案内溝としてのグルーブが形成された記録再生可能領域となっている。
この光磁気領域の最内周側のクラスタ０〜クラスタ４９までの区間が管理エリアとされ、実際の楽曲等のプログラムが記録されるのは、クラスタ５０〜クラスタ２２５１までのプログラムエリアとなる。プログラムエリアより外周はリードアウトエリアとされている。
図７（ａ）はディスク最内周側から最外周側までのエリアを示している。
光磁気ディスクとしてのディスク９０は、最内周側はエンボスピットにより再生専用のデータが形成されるピット領域とされており、ここにＰ−ＴＯＣが記録されている。
ピット領域より外周は、光磁気領域とされ、記録トラックの案内溝としてのグルーブが形成された記録再生可能領域となっている。
この光磁気領域の最内周側のクラスタ０〜クラスタ４９までの区間が管理エリアとされ、実際の楽曲等のプログラムが記録されるのは、クラスタ５０〜クラスタ２２５１までのプログラムエリアとなる。プログラムエリアより外周はリードアウトエリアとされている。
管理エリア内を詳しく示したものが図７（ｂ）である。図７（ｂ）は横方向にセクター、縦方向にクラスタを示している。
管理エリアにおいてクラスタ０，１はピット領域との緩衝エリアとされている。クラスタ２はパワーキャリブレーションエリアＰＣＡとされ、レーザー光の出力パワー調整等のために用いられる。
クラスタ３，４，５はＵ−ＴＯＣが記録される。Ｕ−ＴＯＣの内容は後述するが、１つのクラスタ内の各セクターにおいてデータフォーマットが規定され、それぞれ所定の管理情報が記録されるが、このようなＵ−ＴＯＣデータとなるセクターを有するクラスタが、クラスタ３，４，５に３回繰り返し記録される。
管理エリアにおいてクラスタ０，１はピット領域との緩衝エリアとされている。クラスタ２はパワーキャリブレーションエリアＰＣＡとされ、レーザー光の出力パワー調整等のために用いられる。
クラスタ３，４，５はＵ−ＴＯＣが記録される。Ｕ−ＴＯＣの内容は後述するが、１つのクラスタ内の各セクターにおいてデータフォーマットが規定され、それぞれ所定の管理情報が記録されるが、このようなＵ−ＴＯＣデータとなるセクターを有するクラスタが、クラスタ３，４，５に３回繰り返し記録される。
クラスタ６，７，８はＡＵＸ−ＴＯＣが記録される。ＡＵＸ−ＴＯＣの内容についても後述するが、１つのクラスタ内の各セクターにおいてデータフォーマットが規定され、それぞれ所定の管理情報が記録される。このようなＡＵＸ−ＴＯＣデータとなるセクターを有するクラスタが、クラスタ６，７，８に３回繰り返して記録される。
クラスタ９からクラスタ４６までの領域は、ＡＵＸデータが記録される領域となる。ＡＵＸデータとしてのデータファイルはセクター単位で形成され、後述する静止画ファイルとしてのピクチャーファイルセクタ、文字情報ファイルとしてのテキストファイルセクター、プログラムに同期した文字情報ファイルとしてのカラオケテキストファイルセクター等が形成される。
そしてこのＡＵＸデータとしてのデータファイルや、ＡＵＸデータエリア内でＡＵＸデータファイルを記録可能な領域などは、ＡＵＸ−ＴＯＣによって管理されることになる。
そしてこのＡＵＸデータとしてのデータファイルや、ＡＵＸデータエリア内でＡＵＸデータファイルを記録可能な領域などは、ＡＵＸ−ＴＯＣによって管理されることになる。
なおＡＵＸデータエリアでのデータファイルの記録容量は、エラー訂正方式モード２として考えた場合に２．８Ｍバイトとなる。
また、例えばプログラムエリアの後半部分やプログラムエリアより外周側の領域（例えばリードアウト部分）に、第２のＡＵＸデータエリアを形成して、データファイルの記録容量を拡大することも考えられる。
また、例えばプログラムエリアの後半部分やプログラムエリアより外周側の領域（例えばリードアウト部分）に、第２のＡＵＸデータエリアを形成して、データファイルの記録容量を拡大することも考えられる。
クラスタ４７，４８，４９は、プログラムエリアとの緩衝エリアとされる。
クラスタ５０（＝３２ｈ）以降のプログラムエリアには、１又は複数の楽曲等の音声データがＡＴＲＡＣと呼ばれる圧縮形式で記録される。
記録される各プログラムや記録可能な領域は、Ｕ−ＴＯＣによって管理される。
なお、プログラム領域における各クラスタにおいて、セクターＦＦｈは、前述したようにサブデータとしての何らかの情報の記録に用いることができる。
クラスタ５０（＝３２ｈ）以降のプログラムエリアには、１又は複数の楽曲等の音声データがＡＴＲＡＣと呼ばれる圧縮形式で記録される。
記録される各プログラムや記録可能な領域は、Ｕ−ＴＯＣによって管理される。
なお、プログラム領域における各クラスタにおいて、セクターＦＦｈは、前述したようにサブデータとしての何らかの情報の記録に用いることができる。
なお、ミニディスクシステムではプログラム等が再生専用のデータとしてピット形態で記録されている再生専用ディスクも用いられるが、この再生専用ディスクでは、ディスク上はすべてピットエリアとなる。そして記録されているプログラムの管理はＰ−ＴＯＣによって後述するＵ−ＴＯＣとほぼ同様の形態で管理され、Ｕ−ＴＯＣは形成されない。
但し、ＡＵＸデータとして再生専用のデータファイルを記録する場合は、それを管理するためのＡＵＸ−ＴＯＣが記録されることになる。
但し、ＡＵＸデータとして再生専用のデータファイルを記録する場合は、それを管理するためのＡＵＸ−ＴＯＣが記録されることになる。
２．マルチメディアファイル
２−１．基本構造
続いて、上記した配信システムにおいて、サーバ１００と配信端末装置３００との間で送受信を行うマルチメディアファイルのデータ構造について説明しておく。
本実施の形態のマルチメディアファイルとしては、データを格納した「ブロック」といわれる単位により形成されると共に、１つのブロックは、複数のブロックを階層的に格納することができる構造を有する。
そこで先ず、図８を参照して１ブロックの構造について説明する。
この図に示すように、１つのブロックは、先ずヘッダエリアＡ０が配置され、これに続けてデータエリアＡ４が配置されてなる。
２−１．基本構造
続いて、上記した配信システムにおいて、サーバ１００と配信端末装置３００との間で送受信を行うマルチメディアファイルのデータ構造について説明しておく。
本実施の形態のマルチメディアファイルとしては、データを格納した「ブロック」といわれる単位により形成されると共に、１つのブロックは、複数のブロックを階層的に格納することができる構造を有する。
そこで先ず、図８を参照して１ブロックの構造について説明する。
この図に示すように、１つのブロックは、先ずヘッダエリアＡ０が配置され、これに続けてデータエリアＡ４が配置されてなる。
ヘッダエリアＡ０としては、先頭から順にブロック名エリアＡ１、子ブロック数エリアＡ２、データ長エリアＡ３が配置される。また、１ブロック内において、各エリア間の区切りとなる位置に対しては、所定長（例えば２バイト）の区切りコードＡ１０，Ａ１０・・・が挿入されるようにして配置される。また、区切りコードＡ１０は、図示するように、データエリアＡ４の最後にも配置するようにされる。
ブロック名エリアＡ１には、現ブロックにどのような内容のデータを格納しているのかを識別可能なように与えられたブロック名を示すBlock Nameが格納される。このBlock Nameとしては、２０ｈ〜７Ｅｈ（ｈは１６進法による表記であることを示す）までのＡＳＣＩＩコードを用いて表現される。
子ブロック数エリアＡ２はNumber of Child Blocksとされて、現ブロックのデータエリアＡ４内において、直下の階層下に格納される子ブロック数を示す値が１０進数のＡＳＣＩＩ文字列（３０ｈ〜３９ｈ）によって格納される。
本実施の形態のマルチメディアファイルの構造では、子ブロック内にさらにその子のブロックである孫ブロックを格納することを許可しているが、このNumber of Child Blocksにより示される数は、あくまでも子ブロック数を示すものとなる。例えば現ブロックのデータエリアに直接データが記述されていることで子ブロックが存在しないとされる場合には、このNumber of Child Blocksとしては「０」を格納し、子ブロック数が例えば１０個存在するとすれば、「１０」が格納される。
本実施の形態のマルチメディアファイルの構造では、子ブロック内にさらにその子のブロックである孫ブロックを格納することを許可しているが、このNumber of Child Blocksにより示される数は、あくまでも子ブロック数を示すものとなる。例えば現ブロックのデータエリアに直接データが記述されていることで子ブロックが存在しないとされる場合には、このNumber of Child Blocksとしては「０」を格納し、子ブロック数が例えば１０個存在するとすれば、「１０」が格納される。
データ長エリアＡ３はData Lengthとされて、現ブロックのデータエリアＡ４のデータサイズが示される。ここでは、データエリアＡ４のバイト数を１０進数のＡＳＣＩＩ文字列（３０ｈ〜３９ｈ）によって示すようにされる。なお、ここで示されるデータサイズとしては、データエリアＡ４の最後に配置される区切りコードＡ１０のサイズは含めないものとされる。
データエリアＡ４に対してはデータが格納される。また、ブロック単位自体を階層構造的に格納することも可能とされている。
データエリアＡ４に格納すべきデータとしては、上記Data Lengthにより指定されるバイト数の任意のバイト列を記述してよいものとされており、従って、バイナリデータをここに格納することも可能とされ、どのようなフォーマットのデータを格納するのかについては例えばアプリケーションごとに自由に決定することができるものとしている。つまり、本実施の形態のマルチメディアファイルとしては、そのファイルの記述内容の構造内に対して、直接、バイナリデータを埋め込むようにすることができるものであり、例えば、ＨＴＭＬやＸＭＬなどのように、記述ファイルの外部参照ファイルとしてバイナリデータを扱わないものとされる。そして、本実施の形態であれば、先の図３〜図７の説明において述べた、ＭＤフォーマットに対応する圧縮オーディオデータや、ＡＵＸデータとしての画像ファイル、テキストデータ等を、このデータエリアＡ４に対して格納することになるものである。
データエリアＡ４に格納すべきデータとしては、上記Data Lengthにより指定されるバイト数の任意のバイト列を記述してよいものとされており、従って、バイナリデータをここに格納することも可能とされ、どのようなフォーマットのデータを格納するのかについては例えばアプリケーションごとに自由に決定することができるものとしている。つまり、本実施の形態のマルチメディアファイルとしては、そのファイルの記述内容の構造内に対して、直接、バイナリデータを埋め込むようにすることができるものであり、例えば、ＨＴＭＬやＸＭＬなどのように、記述ファイルの外部参照ファイルとしてバイナリデータを扱わないものとされる。そして、本実施の形態であれば、先の図３〜図７の説明において述べた、ＭＤフォーマットに対応する圧縮オーディオデータや、ＡＵＸデータとしての画像ファイル、テキストデータ等を、このデータエリアＡ４に対して格納することになるものである。
そして、本実施の形態のマルチメディアファイルとしては、上記したブロックとしての構造を基本単位として、次に説明するようにして、１つの親となるブロック内に対して子ブロックを格納することが可能とされる。
図９には、例として１つのマルチメディアファイルが示されている。なお、この図においては、説明を簡単にするために、区切りコードＡ１０の図示は省略している。
このマルチメディアファイルは、全体としては、Block1より成るものとされており、このBlock1は、ヘッダエリアＡ０−１、データエリアＡ４−１から成るものとされる。そして、ヘッダエリアＡ０−１のブロック名エリアＡ１−１にはBlock Nameとして［Block1］が格納されている。また、子ブロック数エリアＡ２−１には、後述するようにしてデータエリアＡ４−１に格納される子ブロック数である［２］が格納され、データ長エリアＡ３−１には、データエリアＡ４−１の実際のデータサイズが示されることになる。
このマルチメディアファイルは、全体としては、Block1より成るものとされており、このBlock1は、ヘッダエリアＡ０−１、データエリアＡ４−１から成るものとされる。そして、ヘッダエリアＡ０−１のブロック名エリアＡ１−１にはBlock Nameとして［Block1］が格納されている。また、子ブロック数エリアＡ２−１には、後述するようにしてデータエリアＡ４−１に格納される子ブロック数である［２］が格納され、データ長エリアＡ３−１には、データエリアＡ４−１の実際のデータサイズが示されることになる。
そして、この場合には、図示するようにして、Block1のデータエリアＡ４−１に対しては、２つの子ブロックであるBlock2,Block3が格納されているものとする。
本実施の形態では、このようにして１つのブロックのデータエリアＡ４に対して、１以上の子ブロックを格納することが可能とされる。ただし、規則として、データエリアＡ４において子ブロックを有するブロックは、この子ブロックが格納されるデータエリアＡ４に対しては、自身のためのデータを直接記述することは禁止されている。換言すれば、子ブロックを有するデータエリアＡ４は、子ブロックのみで形成されるものと規定される。
本実施の形態では、このようにして１つのブロックのデータエリアＡ４に対して、１以上の子ブロックを格納することが可能とされる。ただし、規則として、データエリアＡ４において子ブロックを有するブロックは、この子ブロックが格納されるデータエリアＡ４に対しては、自身のためのデータを直接記述することは禁止されている。換言すれば、子ブロックを有するデータエリアＡ４は、子ブロックのみで形成されるものと規定される。
ここで、Block1のデータエリアＡ４−１内に格納される２つの子ブロックBlock2,Block3としては、先ずBlock2を記述し、これに続けてBlock3を記述しているものとする。つまり、データエリアＡ４−１内のデータシーケンスとしては、Block2→Block3の順に配置されるものとする。
Block2は、ヘッダエリアＡ０−２とこれに続くデータエリアＡ４−２とにより形成される。ヘッダエリアＡ０−２におけるブロック名エリアＡ１−２にはBlock Nameとして［Block2］が格納される。また、このBlock2のデータエリアＡ４−２には、Block2自身のデータが格納されて子ブロックは格納されていないことから、子ブロック数エリアＡ２−２には［０］が格納されることで子ブロックは無いことを示す。データ長エリアＡ３−２には、データエリアＡ４−２の実際のデータサイズが示される。そして、データエリアＡ４−２には、上記もしたようにBlock2自身のデータが格納される。
Block3は、ヘッダエリアＡ０−３とデータエリアＡ４−３とにより形成される。そしてヘッダエリアＡ０−３におけるブロック名エリアＡ１−３にはBlock Nameとして［Block3］が格納される。また、このBlock3のデータエリアＡ４−３には１つの子ブロックが格納されるので、子ブロック数エリアＡ２−３には［１］が記述される。データ長エリアＡ３−３には、データエリアＡ４−３の実際のデータサイズが示される。そして、データエリアＡ４−３には、１つのブロック単位のデータとして、Block4が格納される。
Block4は、ヘッダエリアＡ０−４とデータエリアＡ４−４とにより形成され、ヘッダエリアＡ０−４におけるブロック名エリアＡ１−４にはBlock Nameとして［Block4］を格納している。また、このBlock4のデータエリアＡ４−４には子ブロックが格納されずに自身のデータが格納されるので、子ブロック数エリアＡ２−４には［０］が記述される。データ長エリアＡ３−４には、データエリアＡ４−４の実際のデータサイズが示される。データエリアＡ４−４には、Block4自身のデータが格納される。
この図９に示されるマルチメディアファイルについてのブロック単位での構造をみた場合には、図１０のようにして示すことができる。
つまり、Block1をルートブロックとして、その階層下にBlock2，Block3が置かれる。そして、Block3の階層下にはBlock4が置かれるものである。
ここで、Block1からBlock4をみた場合には、Block4は孫ブロックとなる。そして、本実施の形態のマルチメディアファイルのフォーマットとしては、さらに孫の子→孫のようにしてブロックを階層下していくことが可能とされる。つまり、マルチメディアファイルを形成するブロックのすべては、その階層下に子ブロックを有することが可能とされているものである。ただし、階層構造のルートとなるブロックは、１つのみであると規定されている。
つまり、Block1をルートブロックとして、その階層下にBlock2，Block3が置かれる。そして、Block3の階層下にはBlock4が置かれるものである。
ここで、Block1からBlock4をみた場合には、Block4は孫ブロックとなる。そして、本実施の形態のマルチメディアファイルのフォーマットとしては、さらに孫の子→孫のようにしてブロックを階層下していくことが可能とされる。つまり、マルチメディアファイルを形成するブロックのすべては、その階層下に子ブロックを有することが可能とされているものである。ただし、階層構造のルートとなるブロックは、１つのみであると規定されている。
また、例えば別の例として、
<parent>
<child1>abc</child1>
<child2>def</child2>
</parent>
として記述される構造のマルチメディアファイルがあるとすると、そのダンプイメージは、図１１に示すものとなる。例えばこのようにして、本実施の形態のマルチメディアファイルは、データエリアに格納されるべきデータがテキストであるとすれば、すべてテキストデータとして表現することが可能とされる。
<parent>
<child1>abc</child1>
<child2>def</child2>
</parent>
として記述される構造のマルチメディアファイルがあるとすると、そのダンプイメージは、図１１に示すものとなる。例えばこのようにして、本実施の形態のマルチメディアファイルは、データエリアに格納されるべきデータがテキストであるとすれば、すべてテキストデータとして表現することが可能とされる。
このようなマルチメディアファイルの構造では、次のようなメリットを有する。
１つには、本実施の形態のマルチメディアファイルとしては、バイナリデータであっても、データの実体をそのファイル内に埋め込めるようにされていることから、例えば、ＨＴＭＬやＸＭＬなどのように、実体となるデータを外部参照ファイルとして扱うことはなくなる。これにより、例えば１つのマルチメディアファイルにより多数のオーディオデータなどを配信する側としては、マルチメディアファイルを作成、編集することが容易になり、また、作成したファイルの管理も楽なものとなるため、それだけ作業効率が向上する。
１つには、本実施の形態のマルチメディアファイルとしては、バイナリデータであっても、データの実体をそのファイル内に埋め込めるようにされていることから、例えば、ＨＴＭＬやＸＭＬなどのように、実体となるデータを外部参照ファイルとして扱うことはなくなる。これにより、例えば１つのマルチメディアファイルにより多数のオーディオデータなどを配信する側としては、マルチメディアファイルを作成、編集することが容易になり、また、作成したファイルの管理も楽なものとなるため、それだけ作業効率が向上する。
また、アップロードされたマルチメディアファイルを処理側にあっては、目的とするデータの検索は、ヘッダエリアに記述されるBlock Name、Number of Child Blocks、Data Lengthの情報を参照することになるのであるが、ここでBlock Name及びNumber of Child Blocksを把握しておいた上で、Data Lengthの情報を参照すれば、ここに記述されているデータ長に従って、データシーケンス上をジャンプするようにして検索を行っていくことが可能とされる。
ＨＴＭＬやＸＭＬでは、データを検索するのには、その記述ファイルとして記載されたタグを最初から読んでいくことが必要であり、これは、検索結果が得られるまでに時間がかかるものとなる。これに対して本実施の形態では、より高速に目的とするデータの検索結果を得ることが可能となるものである。
ＨＴＭＬやＸＭＬでは、データを検索するのには、その記述ファイルとして記載されたタグを最初から読んでいくことが必要であり、これは、検索結果が得られるまでに時間がかかるものとなる。これに対して本実施の形態では、より高速に目的とするデータの検索結果を得ることが可能となるものである。
２−２．具体的構造例
本実施の形態としてのマルチメディアファイルは上記した構造を有するものであるが、ここで、図１に示した本実施の形態の配信システムにおいて送受信されるマルチメディアファイルの具体的な構造例について、図１２及び図１３を参照して説明する。
本実施の形態としてのマルチメディアファイル構造としては、先ず図１２に示すようにしてルートブロックとして［Content］というファイル名のブロックが置かれる。そして、その階層下に[File Info]［Audio］[Image][text][video]の各ブロックが配置される。なお、データシーケンス上では、この図における上下の配置関係に従って、[File Info]→[Audio]→[Image]→[Text]→[Video]の順に、［Content］ブロックのデータエリア内に記述されているものとする。
本実施の形態としてのマルチメディアファイルは上記した構造を有するものであるが、ここで、図１に示した本実施の形態の配信システムにおいて送受信されるマルチメディアファイルの具体的な構造例について、図１２及び図１３を参照して説明する。
本実施の形態としてのマルチメディアファイル構造としては、先ず図１２に示すようにしてルートブロックとして［Content］というファイル名のブロックが置かれる。そして、その階層下に[File Info]［Audio］[Image][text][video]の各ブロックが配置される。なお、データシーケンス上では、この図における上下の配置関係に従って、[File Info]→[Audio]→[Image]→[Text]→[Video]の順に、［Content］ブロックのデータエリア内に記述されているものとする。
[File Info]ブロックは、このマルチメディアファイルとしてのコンテンツファイルに関する情報を格納するブロックとされ、例えば図のように、[Version][Charaset][Author]などの子ブロックを有する。
［Audio］ブロックには、このマルチメディアファイル内に格納されるオーディオデータに関する情報が格納され、[Data][Info]の子ブロックを有する。
[Data]ブロックは、例えば図のように[Location][Body]の子ブロックを有している。また、この[Location][Body]で１セットとなる子ブロックの組が、例えばこのマルチメディアファイルに格納すべきオーディオデータ数に応じた数配列されて設けられる。
[Location]ブロックは、オーディオデータの実体がどこに格納されているのかを示す情報が格納される。ここで、「internal」の記述があれば、オーディオデータは、このマルチメディアファイル内に埋め込まれていることを示すが、「external」の記述があれば、外部参照ファイルとして管理されていることを示すことになる。つまり、本実施の形態のマルチメディアファイルのフォーマットとしては、ファイル内に実データを埋め込むようにされるのであるが、このようにして、外部参照ファイルに対してリンクをはることも可能とされているものである。
[Body]ブロックには、Locationが「internal」として記述される場合には、オーディオデータの実体が格納され、「external」として記述される場合には、リンク先のＵＲＬが格納される。
[Data]ブロックは、例えば図のように[Location][Body]の子ブロックを有している。また、この[Location][Body]で１セットとなる子ブロックの組が、例えばこのマルチメディアファイルに格納すべきオーディオデータ数に応じた数配列されて設けられる。
[Location]ブロックは、オーディオデータの実体がどこに格納されているのかを示す情報が格納される。ここで、「internal」の記述があれば、オーディオデータは、このマルチメディアファイル内に埋め込まれていることを示すが、「external」の記述があれば、外部参照ファイルとして管理されていることを示すことになる。つまり、本実施の形態のマルチメディアファイルのフォーマットとしては、ファイル内に実データを埋め込むようにされるのであるが、このようにして、外部参照ファイルに対してリンクをはることも可能とされているものである。
[Body]ブロックには、Locationが「internal」として記述される場合には、オーディオデータの実体が格納され、「external」として記述される場合には、リンク先のＵＲＬが格納される。
また、［Audio］ブロックの階層下の[Info]ブロックは、図示するように、[Format][Bitrate][Channel]・・・・[SCMSStatus][PID]などの子ブロックを有している。
なお、以降のブロック[Image]、[Text]、[Video]の各階層下の構造については、図示するにとどめ、ここでの説明は省略する。
なお、以降のブロック[Image]、[Text]、[Video]の各階層下の構造については、図示するにとどめ、ここでの説明は省略する。
このような構成では、例えば［Content］ブロックのデータエリア内に格納される各ブロックのヘッダエリアのBlock Nameを参照することで、目的とするデータが格納されているブロックを見つけることができる。例えばオーディオデータを検索したいのであれば、[Audio]というBlock Nameがヘッダのブロック名エリアに記述されたブロックを見つければよいことになる。また、この検索時にはヘッダエリアのデータ長エリアに格納されるData Lengthの値に基づいて、ブロックのジャンプを行うようにすることで、高速に[Audio]ブロックを見つけることが可能である。そして、例えば[Audio]ブロックから、必要なデータを得る際にも同様の手順によって検索を行っていけばよいものである。
なお、図１２及び図１３に示したマルチメディアファイルの構造はあくまでも一例であり、適宜変更されて構わない。例えば、各ブロックに対して与えられるBlock Nameも、図示したものに限定されるものではなく、実際のアプリケーションの仕様等に応じて変更されて構わない。
なお、図１２及び図１３に示したマルチメディアファイルの構造はあくまでも一例であり、適宜変更されて構わない。例えば、各ブロックに対して与えられるBlock Nameも、図示したものに限定されるものではなく、実際のアプリケーションの仕様等に応じて変更されて構わない。
３．再生処理
続いて、本実施の形態の配信端末装置３００において行われる、マルチメディアファイルから指定されたデータを再生するための動作を実現するための処理について、図１４のフローチャートを参照して説明する。
なお、この図に示す処理は制御部３０１がマルチメディアファイル用プログラム４０１に従って実行するものとされる。
続いて、本実施の形態の配信端末装置３００において行われる、マルチメディアファイルから指定されたデータを再生するための動作を実現するための処理について、図１４のフローチャートを参照して説明する。
なお、この図に示す処理は制御部３０１がマルチメディアファイル用プログラム４０１に従って実行するものとされる。
この図に示す処理においては、先ずステップＳ１０１において、操作部３０５に対して行われた操作に応じて、再生すべきデータが格納されているとされるマルチメディアファイル及びブロックを指定することが行われる。ここでの指定は、例えばBlock Nameとして記述されたファイル名による指定が行われる。
そして、続くステップＳ１０２においては、マルチメディアファイル用プログラム４０１の検索プログラム４０２の実行プログラムに従って、メイン記憶部３０２に格納しているとされる多数のマルチメディアファイルのなかから、指定されたマルチメディアファイルを検索する。これは、メイン記憶部３０２に格納されるマルチメディアファイルのルートブロックのBlock Nameを参照するようにされる。
次のステップＳ１０３においては、上記ステップＳ１０２の検索結果としてＯＫが得られたか否かが判別される。ここで、検索対象となったマルチメディアファイルが検索されずに否定結果が得られた場合にはステップＳ１０８に進んで検索エラー処理を実行する。この検索エラー処理としては、例えば検索対象となるマルチメディアファイルは当該配信端末装置３００には格納されていないことなどをユーザに通知する内容の表示を表示部３０６に実行させる。
これに対して、検索対象となったマルチメディアファイルが検索されることでステップＳ１０３において肯定結果が得られた場合にはステップＳ１０４に進む。
ステップＳ１０４においては、データ識別プログラム４０３の実行プログラムに従って、先のステップＳ１０１により指定されたブロック（データ）を検索することが行われる。つまり、検索されたマルチメディアファイル内のブロックを探索していくことで、検索対象となるデータが格納されているブロックを検索するものである。このときには、前述したように、ヘッダエリアの記述内容を参照することで、高速に検索が行われるものである。
ステップＳ１０４においては、データ識別プログラム４０３の実行プログラムに従って、先のステップＳ１０１により指定されたブロック（データ）を検索することが行われる。つまり、検索されたマルチメディアファイル内のブロックを探索していくことで、検索対象となるデータが格納されているブロックを検索するものである。このときには、前述したように、ヘッダエリアの記述内容を参照することで、高速に検索が行われるものである。
そして、次のステップＳ１０５においては、上記ステップＳ１０４による検索結果がＯＫであるか否かが判別される。ここで、否定結果が得られた場合にはステップＳ１０８に進み、この場合には、例えば指定されたデータが存在しないことを示す表示を表示部３０６に実行させるなどの検索エラー処理を実行する。
これに対して、ステップＳ１０５において肯定結果が得られた場合には、ステップＳ１０６に進むようにされる。
これに対して、ステップＳ１０５において肯定結果が得られた場合には、ステップＳ１０６に進むようにされる。
ステップＳ１０６においては、再生プログラム４０４の実行プログラムに従って、検索されたブロックのデータを再生出力する。ここでの再生出力としては、例えばこの検索されたブロックのデータエリアに格納されているデータを抽出して取得することをいうものとされる。
そして、続くステップＳ１０７においては、例えば上記と同じ再生プログラム４０４の実行プログラムに従い、上記ステップＳ１０６により取得したデータをメディアドライバ３０７に転送し、メディアドライバ３０７に装填されているＭＤに対して書き込みを行うようにされる。なお、この際には、一旦サブ記憶部３０３のＲＡＭにデータを一時蓄積させ、メディアドライバ３０７に適合した転送レートでメディアドライバ３０７へのデータ転送を行うようにしてもよい。
そして、続くステップＳ１０７においては、例えば上記と同じ再生プログラム４０４の実行プログラムに従い、上記ステップＳ１０６により取得したデータをメディアドライバ３０７に転送し、メディアドライバ３０７に装填されているＭＤに対して書き込みを行うようにされる。なお、この際には、一旦サブ記憶部３０３のＲＡＭにデータを一時蓄積させ、メディアドライバ３０７に適合した転送レートでメディアドライバ３０７へのデータ転送を行うようにしてもよい。
なお、本発明としては上記した実施の形態に限定されるものではない。
例えば実施の形態では、マルチメディアファイルから抽出したデータが記録されるメディアをＭＤとしているが、これはあくまでも一例であって、例えば他のデータ記録が可能な各種ディスク、テープメディアや、さらにはメモリ素子により構成されるリムーバブルメディアであってもよいものである。また、例えば予めフラッシュメモリなどが内蔵された記録再生装置の本体を配信端末装置３００に対して装填することで、配信端末装置３００から記録再生装置内部のメモリにデータを書き込むようにするはい新形態とすることも考えられる。
また、ここでは、楽曲データ（及びこれに付随する画像、テキスト等のデータ）を配信するための配信システムを例に挙げたが、他の種類のデータを配信する配信システム、及び配信システムを構成する機器に対しても適用が可能である。また、本発明としては、配信システム以外にも、例えばＣＤ−ＲＯＭやＤＶＤなどのパッケージメディアに記録してマルチメディア情報を配布するような形態にも対応できるものである。更には、本発明が対応するマルチメディア情報の構造は、いわゆるマルチメディアコンテンツ以外のデータファイルの構造として採用することも可能とされる。
例えば実施の形態では、マルチメディアファイルから抽出したデータが記録されるメディアをＭＤとしているが、これはあくまでも一例であって、例えば他のデータ記録が可能な各種ディスク、テープメディアや、さらにはメモリ素子により構成されるリムーバブルメディアであってもよいものである。また、例えば予めフラッシュメモリなどが内蔵された記録再生装置の本体を配信端末装置３００に対して装填することで、配信端末装置３００から記録再生装置内部のメモリにデータを書き込むようにするはい新形態とすることも考えられる。
また、ここでは、楽曲データ（及びこれに付随する画像、テキスト等のデータ）を配信するための配信システムを例に挙げたが、他の種類のデータを配信する配信システム、及び配信システムを構成する機器に対しても適用が可能である。また、本発明としては、配信システム以外にも、例えばＣＤ−ＲＯＭやＤＶＤなどのパッケージメディアに記録してマルチメディア情報を配布するような形態にも対応できるものである。更には、本発明が対応するマルチメディア情報の構造は、いわゆるマルチメディアコンテンツ以外のデータファイルの構造として採用することも可能とされる。
１ 記録再生装置、９０ ディスク（ＭＤ）、１００ サーバ、１０１ 制御部、１０２ 記憶部、１０３ 検索部、１０４ インターフェイス部
２００ 通信網、３００ 配信端末装置、３０１ 制御部、３０２ メイン記憶部、３０３ サブ記憶部、３０４ ユーザインターフェイス部、３０５ 操作部、３０６ 表示部、３０７ メディアドライバ、３０８ インターフェイス部、４００ マルチメディアファイル、４０１マルチメディアファイル用プログラム、４０２ 検索プログラム、４０３ データ識別プログラム、４０４ 再生プログラム
２００ 通信網、３００ 配信端末装置、３０１ 制御部、３０２ メイン記憶部、３０３ サブ記憶部、３０４ ユーザインターフェイス部、３０５ 操作部、３０６ 表示部、３０７ メディアドライバ、３０８ インターフェイス部、４００ マルチメディアファイル、４０１マルチメディアファイル用プログラム、４０２ 検索プログラム、４０３ データ識別プログラム、４０４ 再生プログラム
Claims (11)
- １以上のブロックデータが格納されるデータエリアと、少なくともデータ内容を識別し得るブロック識別情報とデータエリア内に格納される子ブロックデータ数を示す子ブロックデータ数識別情報とデータ長を示すデータ長識別情報とが配置されるヘッダエリアと、が配置されて成るブロックデータを有するマルチメディア情報を取得する情報取得手段と、
上記マルチメディア情報のヘッダエリアにおける上記ブロック識別情報と子ブロックデータ数識別情報及びデータ長識別情報に基づいて、上記情報取得手段により取得したマルチメディア情報から所要のデータを検索して抽出するデータ抽出手段と、
上記データ抽出手段により抽出したデータを再生することのできる再生手段と、
を備える情報処理装置。 - 上記１つのブロックデータにおいては、
ヘッダエリアを形成する各情報エリアと、データエリアから成るデータシーケンス間において、エリア間の区切りであることを示す所定長の区切り識別情報が挿入される構造を有しており、
上記データ抽出手段は、抽出すべきデータの検索時において、上記区切り識別情報に基づいてエリアの区切り位置を識別することを特徴とする請求項１に記載の情報処理装置。 - 上記データエリアにはオーディオデータが格納されていることを特徴とする請求項１に記載の情報処理装置。
- 上記子ブロックには上記データエリアの関連情報が格納されていることを特徴とする請求項１に記載の情報処理装置。
- 上記子ブロックの上記データエリアには画像データが格納されていることを特徴とする請求項１に記載の情報処理装置。
- 上記画像データはジャケット画像であることを特徴とする請求項５に記載の情報処理装置。
- 上記子ブロックのデータエリアにはテキストデータが格納されていることを特徴とする請求項１に記載の情報処理装置。
- 上記テキストデータは歌詞データであることを特徴とする請求項７に記載の情報処理装置。
- 情報配信装置と、情報受信装置とから成り、
上記情報配信装置は、
１以上のブロックデータが格納されるデータエリアと、少なくともデータ内容を識別し得るブロック識別情報とデータエリア内に格納される子ブロックデータ数を示す子ブロックデータ数識別情報とデータ長を示すデータ長識別情報とが配置されるヘッダエリアと、が配置されて成るブロックデータを有するマルチメディア情報を１以上記憶可能な記憶手段と、
上記記憶手段に記憶される１以上のマルチメディア情報のうちから選択したマルチメディア情報を送信出力可能な送信手段と、を備え、
上記情報受信装置は、
上記情報配信装置から送信されるマルチメディア情報を受信する受信手段と、
上記マルチメディア情報のヘッダエリアにおける上記ブロック識別情報と子ブロックデータ数識別情報及びデータ長識別情報に基づいて、上記情報取得手段により取得したマルチメディア情報から所要のデータを検索して抽出するデータ抽出手段と、
上記データ抽出手段により抽出したデータを再生することのできる再生手段と、
を備える情報配信システム。 - １以上のブロックデータが格納されるデータエリアと、少なくともデータ内容を識別し得るブロック識別情報とデータエリア内に格納される子ブロックデータ数を示す子ブロックデータ数識別情報とデータ長を示すデータ長識別情報とが配置されるヘッダエリアと、が配置されて成るブロックデータを有するマルチメディア情報を取得する情報取得処理と、
上記マルチメディア情報のヘッダエリアにおける上記ブロック識別情報と子ブロックデータ数識別情報及びデータ長識別情報に基づいて、上記情報取得処理により取得したマルチメディア情報から所要のデータを検索して抽出するデータ抽出処理と、
上記データ抽出処理により抽出したデータを再生することのできる再生処理と、
を実行するようにされている情報処理方法。 - １以上のブロックデータが格納されるデータエリアと、少なくともデータ内容を識別し得るブロック識別情報とデータエリア内に格納される子ブロックデータ数を示す子ブロックデータ数識別情報とデータ長を示すデータ長識別情報とが配置されるヘッダエリアと、が配置されて成るブロックデータを有するマルチメディア情報を取得する情報取得処理と、
上記マルチメディア情報のヘッダエリアにおける上記ブロック識別情報と子ブロックデータ数識別情報及びデータ長識別情報に基づいて、上記情報取得処理により取得したマルチメディア情報から所要のデータを検索して抽出するデータ抽出処理と、
上記データ抽出処理により抽出したデータを再生することのできる再生処理と
を情報処理装置に実行させるプログラムが記録された記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2008163784A JP4766080B2 (ja) | 2008-06-23 | 2008-06-23 | 情報処理装置、情報配信システム、情報処理方法、及びプログラムを記録した記録媒体 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2008163784A JP4766080B2 (ja) | 2008-06-23 | 2008-06-23 | 情報処理装置、情報配信システム、情報処理方法、及びプログラムを記録した記録媒体 |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000088537A Division JP4244492B2 (ja) | 2000-03-24 | 2000-03-24 | 情報処理装置、情報配信システム、情報処理方法、及び記録媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2008226456A JP2008226456A (ja) | 2008-09-25 |
| JP4766080B2 true JP4766080B2 (ja) | 2011-09-07 |
Family
ID=39844851
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2008163784A Expired - Fee Related JP4766080B2 (ja) | 2008-06-23 | 2008-06-23 | 情報処理装置、情報配信システム、情報処理方法、及びプログラムを記録した記録媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4766080B2 (ja) |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0246584A (ja) * | 1988-08-08 | 1990-02-15 | Mitsubishi Electric Corp | 光ディスクファイル方法 |
| JPH05128736A (ja) * | 1991-11-05 | 1993-05-25 | Fujitsu Ltd | 磁気テープ装置制御方式 |
| JPH10276407A (ja) * | 1997-03-31 | 1998-10-13 | Nippon Telegr & Teleph Corp <Ntt> | ビデオ情報提供管理方法およびシステム |
| JP3019827B2 (ja) * | 1997-11-28 | 2000-03-13 | 三菱電機株式会社 | マルチメディア多重方式 |
| JPH11205358A (ja) * | 1998-01-16 | 1999-07-30 | Sony Corp | ディジタル信号伝送装置及びディジタル信号伝送システム |
| JPH11259525A (ja) * | 1998-03-06 | 1999-09-24 | Ntt Data Corp | 位置依存マルチメディア情報提供システム |
| JPH11327802A (ja) * | 1998-05-18 | 1999-11-30 | Hitachi Ltd | ディスクシステム |
| JP2000040300A (ja) * | 1998-07-21 | 2000-02-08 | Matsushita Electric Ind Co Ltd | データ伝送方法、データ記録方法及びデータ記録再生装置 |
-
2008
- 2008-06-23 JP JP2008163784A patent/JP4766080B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2008226456A (ja) | 2008-09-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4244492B2 (ja) | 情報処理装置、情報配信システム、情報処理方法、及び記録媒体 | |
| KR100906883B1 (ko) | 데이터 관리 장치 | |
| CN1967696B (zh) | 用于存储具有多级内容表(toc)机构和双toc区的音频居中的信息的方法和设备 | |
| US6567847B1 (en) | Data transmitting and receiving system | |
| KR100570741B1 (ko) | 분산시스템, 분산방법, 수신장치 및 수신방법 | |
| JP4078691B2 (ja) | 記録再生制御システム、記録再生制御方法および記録再生制御装置 | |
| US6388766B1 (en) | Dubbing apparatus | |
| JP2004021996A (ja) | 記録装置、サーバ装置、記録方法、プログラム、記憶媒体 | |
| JP2002216419A (ja) | ダビング装置 | |
| KR100583760B1 (ko) | 기록매체에압축오디오데이터를기록하는방법과장치및압축오디오데이터를송신하는방법 | |
| JP3826632B2 (ja) | 再生装置及び情報通信システム | |
| KR19990030266A (ko) | 디지털 신호 기록 장치 및 이의 기록 방법, 그와 함께 사용하기 위한 원격 제어 장치 및 이의 원격 제어 방법, 및 그와 함께 사용하기 위한 더빙 시스템 | |
| KR100474377B1 (ko) | 기록매체에압축음성데이터를기록하는방법과장치및압축음성데이터를전송하는방법 | |
| US7706229B2 (en) | Recording medium having different areas recorded with different modulation methods, recording apparatus, reproducing apparatus, recording method, and reproducing method | |
| US6061314A (en) | Optical disc device reproducing information according to reproduction speed information | |
| JP2002518774A (ja) | 高いレベルの音声ファイルと低いレベルの音声項目表示ファイルとを用いた音声中心情報を記憶する方法、上記情報を読み取り及び／又は記憶する装置及び記録担体 | |
| JP4766080B2 (ja) | 情報処理装置、情報配信システム、情報処理方法、及びプログラムを記録した記録媒体 | |
| US6345017B1 (en) | Reproducing apparatus capable of suppressing mechanical noise during access of sub data and main data | |
| JP3361186B2 (ja) | 光記録担体再生装置 | |
| JP4787670B2 (ja) | 記憶装置及び記憶方法 | |
| CA2464972A1 (en) | Information recording medium, information recording apparatus, information reproducing apparatus, and copying apparatus | |
| WO2004109685A1 (ja) | データ転送システム、データ転送方法およびデータ転送プログラム | |
| JP2004199792A (ja) | 記録再生システム、コントロール機器および管理方法 | |
| JP2008135162A (ja) | 記録再生制御システム、記録再生制御方法、および記録再生制御装置 | |
| JPH08102170A (ja) | ディスク担体記録再生装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20080623 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20100412 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20110222 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20110422 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20110517 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20110530 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140624 Year of fee payment: 3 |
|
| LAPS | Cancellation because of no payment of annual fees |