JP2004171067A - データ管理方法およびデータ管理装置、データ管理プログラムならびにこれを記録した記録媒体 - Google Patents
データ管理方法およびデータ管理装置、データ管理プログラムならびにこれを記録した記録媒体 Download PDFInfo
- Publication number
- JP2004171067A JP2004171067A JP2002332837A JP2002332837A JP2004171067A JP 2004171067 A JP2004171067 A JP 2004171067A JP 2002332837 A JP2002332837 A JP 2002332837A JP 2002332837 A JP2002332837 A JP 2002332837A JP 2004171067 A JP2004171067 A JP 2004171067A
- Authority
- JP
- Japan
- Prior art keywords
- sample
- information
- atom
- entry
- time
- 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.)
- Withdrawn
Links
Images
Landscapes
- Television Signal Processing For Recording (AREA)
- Management Or Editing Of Information On Record Carriers (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
【課題】ＱｕｉｃｋＴｉｍｅファイルフォーマット等で記録された情報に対するランダムアクセス時における再生開始までの時間を短縮して、効率よく管理情報の読み出しを行うことができるデータ管理方法およびデータ管理装置、データ管理プログラムならびにこれを記録した記録媒体を提供する。
【解決手段】Ｔｒａｃｋ ａｔｏｍにおけるＵｓｅｒ ｄｅｆｉｎｅｄ ｄａｔａ ａｔｏｍの下位テーブルであるＡｃｃｅｓｓ Ｔａｂｌｅ ａｔｏｍの下位テーブルとして、複数の補助アクセステーブル（Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍ，Ｓａｍｐｌｅ ｔｏ Ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍ，Ｓｙｎｃ Ｓａｍｐｌｅ ａｃｃｅｓｓａｔｏｍ）を形成する。例えば、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍから、補助アクセステーブルであるＴｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍの情報に基づいて、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅにおける目的のエントリに含まれる情報を１回のロードで読み出す。
【選択図】 図１
【解決手段】Ｔｒａｃｋ ａｔｏｍにおけるＵｓｅｒ ｄｅｆｉｎｅｄ ｄａｔａ ａｔｏｍの下位テーブルであるＡｃｃｅｓｓ Ｔａｂｌｅ ａｔｏｍの下位テーブルとして、複数の補助アクセステーブル（Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍ，Ｓａｍｐｌｅ ｔｏ Ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍ，Ｓｙｎｃ Ｓａｍｐｌｅ ａｃｃｅｓｓａｔｏｍ）を形成する。例えば、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍから、補助アクセステーブルであるＴｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍの情報に基づいて、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅにおける目的のエントリに含まれる情報を１回のロードで読み出す。
【選択図】 図１
Description
【０００１】
【発明の属する技術分野】
本発明は、例えば、ＱｕｉｃｋＴｉｍｅ（登録商標）ファイルに記録された情報に対して、ランダムアクセスにより再生を行う場合でも、効率よく管理情報の読み出しを行うことができるデータ管理方法およびデータ管理装置、データ管理プログラムならびにこれを記録した記録媒体に関するものである。
【０００２】
【従来の技術】
オーディオやビデオ等の複数のマルチメディアデータを同期して再生するための管理方法として、ＰＣ（パーソナルコンピュータ）やデジカメなどにおいて、広くＱｕｉｃｋＴｉｍｅ（登録商標）ファイルフォーマットが利用されている（特許文献１・２を参照）。
【０００３】
ＱｕｉｃｋＴｉｍｅファイルフォーマットとは、Ａｐｐｌｅ社が開発したマルチメディアデータ管理用フォーマットであり、ＰＣの世界で広く用いられている。また、ＱｕｉｃｋＴｉｍｅファイルフォーマットをベースとして、ＭＰＥＧ４やＭｏｔｉｏｎ ＪＰＥＧ２０００などで採用されているファイルフォーマットであるＩＳＯ ｂａｓｅ ｍｅｄｉａ ｆｉｌｅ ｆｏｒｍａｔが規格化されている。
【０００４】
ＱｕｉｃｋＴｉｍｅファイルフォーマットは、ビデオデータやオーディオデータ等（これらを総称してメディアデータという）と管理情報とで構成される。ここでは、この両者を合わせて「ＱｕｉｃｋＴｉｍｅムービー」と称する。なお、このマルチメディアデータと管理情報とは、同じファイル中に存在しても、別々のファイルに存在してもよい。
【０００５】
例えば、管理情報とマルチメディアデータとを同じファイル中に格納した場合には、図２０に示すように、各種情報はａｔｏｍという共通の構造に格納される。具体的には、管理情報はＭｏｖｉｅ ａｔｏｍという構造に格納され、メディアデータはＭｏｖｉｅ ｄａｔａ ａｔｏｍという構造に格納される。
【０００６】
なお、Ｍｏｖｉｅ ａｔｏｍ中の管理情報には、メディアデータ中の任意の時間に対応するメディアデータのファイル中での相対位置を導くためのテーブルや、メディアデータの属性情報や、後述する外部参照情報等が含まれている。
【０００７】
一方、管理情報とメディアデータとを別々のファイルに格納した場合には、管理情報はＭｏｖｉｅ ａｔｏｍという構造に格納されるが、メディアデータはａｔｏｍに格納される必要はない。この場合、Ｍｏｖｉｅ ａｔｏｍはメディアデータを格納したファイルを「外部参照」している、という。
【０００８】
この外部参照は、複数のＡＶストリームファイルに対して行うことが可能であり、この仕組みにより、ＡＶストリーム自体を物理的に移動させることなく、見かけ上編集を行ったように見せる、いわゆる「ノンリニア編集」や「非破壊編集」が可能になる。
【０００９】
ここで、図２０〜図３５を用いて、ＱｕｉｃｋＴｉｍｅファイルにおける管理情報が格納されている構造について説明する。
【００１０】
まず、共通の情報格納構造であるａｔｏｍについて説明する。
【００１１】
ａｔｏｍの先頭には、そのａｔｏｍのサイズであるＡｔｏｍ ｓｉｚｅ、そのａｔｏｍの種別情報であるＴｙｐｅが必ず存在する。Ｔｙｐｅは４文字で区別され、例えば、Ｍｏｖｉｅ ａｔｏｍでは’ｍｏｏｖ’、Ｍｏｖｉｅ ｄａｔａ ａｔｏｍでは’ｍｄａｔ’となっている。
【００１２】
ここで、ａｔｏｍの先頭にあるＡｔｏｍ ｓｉｚｅとＴｙｐｅとの列を、ａｔｏｍ ｈｅａｄｅｒと呼ぶことにすると、ＱｕｉｃｋＴｉｍｅムービーは、必ずこの複数のａｔｏｍ構造によって構成される。そして、注目しているａｔｏｍ ｈｅａｄｅｒの先頭からａｔｏｍ ｈｅａｄｅｒで管理されるａｔｏｍ ｓｉｚｅ（バイト数）だけ先に次のａｔｏｍが存在することになる。そして、各ａｔｏｍは別のａｔｏｍを含むことができ、ａｔｏｍ間に階層構造を形成することが可能である。
【００１３】
Ｍｏｖｉｅ ａｔｏｍはコンテナａｔｏｍであって、Ｍｏｖｉｅ ｈｅａｄｅｒ ａｔｏｍ、任意の数のＴｒａｃｋ ａｔｏｍ、Ｕｓｅｒ ｄｅｆｉｎｅｄ ｄａｔａ ａｔｏｍを備えている。なお、コンテナａｔｏｍとは、任意の数のａｔｏｍを格納するための入れ物的な役割を果たすものであり、コンテナａｔｏｍ自体は情報を管理しない。
【００１４】
Ｍｏｖｉｅ ｈｅａｄｅｒ ａｔｏｍは、そのＭｏｖｉｅ ａｔｏｍが管理するムービーの全体的な属性を管理する。
【００１５】
Ｔｒａｃｋ ａｔｏｍは、そのムービーに含まれるビデオやオーディオ等のトラックに関する情報を格納する。
【００１６】
Ｕｓｅｒ ｄｅｆｉｎｅｄ ｄａｔａ ａｔｏｍの中には、独自に定義可能なａｔｏｍを配置することが可能であって、ＱｕｉｃｋＴｉｍｅフォーマットで定義されてない独自情報を任意個数格納することができる。１個の独自情報は１個のエントリで管理され、１個のエントリはＳｉｚｅとＴｙｐｅとＵｓｅｒ ｄａｔａとで構成される。Ｓｉｚｅはそのエントリ自体のサイズを表し、Ｔｙｐｅは独自情報をそれぞれ区別するための識別情報、Ｕｓｅｒ ｄａｔａは実際のデータを表す。
【００１７】
さらに、上記Ｔｒａｃｋ ａｔｏｍはコンテナａｔｏｍであり、Ｔｒａｃｋ Ｈｅａｄｅｒ ａｔｏｍ、Ｅｄｉｔ ａｔｏｍ、Ｍｅｄｉａ ａｔｏｍ、Ｕｓｅｒ ｄｅｆｉｎｅｄ ｄａｔａ ａｔｏｍを備えている。一般的に、ＱｕｉｃｋＴｉｍｅムービーにおいては、オーディオおよびビデオの２つのトラックが存在することが多いが、字幕を表示するテキストトラックや、複数のオーディオやビデオ等、任意の数のトラックを管理することが可能である。
【００１８】
Ｔｒａｃｋ ｈｅａｄｅｒ ａｔｏｍは、そのトラックの全体的な属性を管理する。
【００１９】
Ｅｄｉｔ ａｔｏｍは、メディアデータのどの区間を、ムービーのどのタイミングで再生するかを管理する。
【００２０】
Ｍｅｄｉａ ａｔｏｍは、実際のビデオやオーディオといったデータを管理する。さらに、このＭｅｄｉａ ａｔｏｍはコンテナａｔｏｍであり、Ｍｅｄｉａ ｈｅａｄｅｒ ａｔｏｍ、Ｈａｎｄｌｅｒ ｒｅｆｅｒｅｎｃｅ ａｔｏｍ、（Ｖｉｄｅｏ／Ａｕｄｉｏ） Ｍｅｄｉａ Ｉｎｆｏｒｍａｔｉｏｎ ａｔｏｍ、Ｕｓｅｒ Ｄｅｆｉｎｅｄ ｄａｔａ ａｔｏｍを備えている。
【００２１】
Ｍｅｄｉａ ｈｅａｄｅｒ ａｔｏｍは、そのＭｅｄｉａ ａｔｏｍが管理するメディアデータに関する全体的な属性等を管理する。
【００２２】
Ｈａｎｄｌｅｒ ｒｅｆｅｒｅｎｃｅ ａｔｏｍは、メディアデータをどのデコーダでデコードするかを示す情報を格納する。
【００２３】
Ｍｅｄｉａ ｉｎｆｏｒｍａｔｉｏｎ ａｔｏｍは、ビデオやオーディオ等のメディア固有の属性情報を管理する。さらに、このＭｅｄｉａ ｉｎｆｏｒｍａｔｉｏｎ ａｔｏｍはコンテナａｔｏｍであって、Ｍｅｄｉａ Ｉｎｆｏｒｍａｔｉｏｎ Ｈｅａｄｅｒ ａｔｏｍ、Ｈａｎｄｌｅｒ Ｒｅｆｅｒｅｎｃｅ ａｔｏｍ、Ｄａｔａ Ｒｅｆｅｒｅｎｃｅ ａｔｏｍ、Ｓａｍｐｌｅ ｔａｂｌｅ ａｔｏｍを備えている。
【００２４】
Ｍｅｄｉａ ｉｎｆｏｒｍａｔｉｏｎ ｈｅａｄｅｒ ａｔｏｍは、ビデオやオーディオ等メディア固有の属性情報を管理する。
【００２５】
Ｈａｎｄｌｅｒ ｒｅｆｅｒｅｎｃｅ ａｔｏｍは、Ｍｅｄｉａ ａｔｏｍの項で説明した通りである。
【００２６】
Ｄａｔａ ｉｎｆｏｒｍａｔｉｏｎ ａｔｏｍは、そのＱｕｉｃｋＴｉｍｅムービーが参照するメディアデータを含むファイルの名前を管理するａｔｏｍであるＤａｔａ ｒｅｆｅｒｅｎｃｅ ａｔｏｍを含んでいる。
【００２７】
Ｓａｍｐｌｅ ｔａｂｌｅ ａｔｏｍは、データのサイズや再生時間等を管理している。
【００２８】
次に、このＳａｍｐｌｅ ｔａｂｌｅ ａｔｏｍについて、図２１を用いて説明するが、その前に、ＱｕｉｃｋＴｉｍｅにおけるデータの管理方法について、図２２を用いて説明する。
【００２９】
ＱｕｉｃｋＴｉｍｅにおいて、データの最小単位（例えば、ビデオフレーム）はサンプルと呼ばれる。個々のトラック毎に、サンプルには再生時間順に１から始まる連続した番号（サンプル番号）が付されている。
【００３０】
また、同一トラックに属するサンプルが再生時間順にファイル中で連続的に配置された領域をチャンクと呼ぶ。チャンクにも再生時間順に、１から始まる連続した番号（チャンク番号）が付されている。
【００３１】
このように、ＱｕｉｃｋＴｉｍｅにおいては、サンプル番号とチャンク番号とを付して、データ管理を行っている。
【００３２】
Ｓａｍｐｌｅ ｔａｂｌｅ ａｔｏｍは、個々のサンプルの再生時間長およびデータサイズ、個々のチャンクのファイル先頭からのアドレスおよび個々のチャンクが含むサンプル数などを管理しており、これらの情報に基づいて、任意の時間に対応するサンプルの情報を求めることが可能となっている。
【００３３】
Ｓａｍｐｌｅ ｔａｂｌｅ ａｔｏｍは、図２１に示すように、Ｓａｍｐｌｅ ｄｅｓｃｒｉｐｔｉｏｎ ａｔｏｍ、Ｔｉｍｅｔｏ ｓａｍｐｌｅ ａｔｏｍ、Ｓｙｎｃ ｓａｍｐｌｅ ａｔｏｍ、Ｓａｍｐｌｅ−ｔｏ−ｃｈｕｎｋ ａｔｏｍ、Ｓａｍｐｌｅ ｓｉｚｅ ａｔｏｍおよびＣｈｕｎｋ ｏｆｆｓｅｔ ａｔｏｍを備えている。
【００３４】
Ｓａｍｐｌｅ ｄｅｓｃｒｉｐｔｉｏｎ ａｔｏｍは、個々のチャンクのデータフォーマット（Ｄａｔａ ｆｏｒｍａｔ）やサンプルが格納されているファイルのＩｎｄｅｘ番号等を管理する。
【００３５】
Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍは、図２３に示すように、個々のサンプルの再生時間長を管理する。なお、ここでは、各サンプルの再生時間長を全て管理するとデータ量が膨大になるため、再生時間長が同じＳａｍｐｌｅが続いた場合には、その繰り返し数を管理することによって情報量を圧縮している。
【００３６】
Ｓａｍｐｌｅ−ｃｏｕｎｔでは、同じ再生時間が繰り返されるサンプルの数が管理され、Ｓａｍｐｌｅ−ｄｅｌｔａでは、繰り返されるｓａｍｐｌｅの再生時間長が管理される。
【００３７】
図２２に示したサンプル構造の例に対応するＳａｍｐｌｅ−ｃｏｕｎｔとＳａｍｐｌｅ−ｄｅｌｔａのテーブル（Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅ）は、図２４に示すように、１つ目のエントリではｓａｍｐｌｅ−ｃｏｕｎｔが２、ｓａｍｐｌｅ−ｄｅｌｔａが１００となっており、再生時間長が１００のサンプルが２個並んでいることがわかる。２つ目のエントリでは、ｓａｍｐｌｅ−ｃｏｕｎｔが１、ｓａｍｐｌｅ−ｄｅｌｔａが９５になっており、再生時間長が９５のサンプルが１回だけ続いていることを表している。なお、図２２における数字は、各サンプルの再生時間長を示すものである。
【００３８】
Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｔｏｍは、図２５に示すように、個々のチャンクに含まれるサンプル数を管理する。なお、ここでも、各チャンクに含まれるサンプル数を全て管理していたのではデータ量が膨大になるため、チャンクに含まれる同じサンプル数が続いた場合に、その繰り返し数を管理することによって情報量を圧縮している。
【００３９】
Ｆｉｒｓｔ ｃｈｕｎｋにはチャンク内のサンプル数が繰り返される先頭のチャンク番号、ｓａｍｐｌｅｓ−ｐｅｒ−ｃｈｕｎｋにはチャンク中のサンプル数、Ｓａｍｐｌｅ−ｄｅｓｃｒｉｐｔｉｏｎ−ｉｎｄｅｘには注目しているチャンクが対応するＳａｍｐｌｅ ｄｅｓｃｒｉｐｔｉｏｎ情報のインデックス番号がそれぞれ示される。
【００４０】
図２２に示したチャンク構造の例に対応するＦｉｒｓｔ Ｃｈｕｎｋ、Ｓａｍｐｌｅ ｐｅｒ ｃｈｕｎｋ、Ｓａｍｐｌｅ−ｄｅｓｃｒｉｐｔｉｏｎ−ｉｎｄｅｘのテーブル（Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅ）は、図２６に示すように、例えば、３つ目のエントリにおいては、Ｆｉｒｓｔ ｃｈｕｎｋには３、Ｓａｍｐｌｅ−ｐｅｒ−ｃｈｕｎｋには２、Ｓａｍｐｌｅ−ｄｅｓｃｒｉｐｔｉｏｎ−ｉｎｄｅｘには１がセットされている。
【００４１】
また、次の４つ目のエントリにおいては、それぞれ、６，３，１がセットされている。これにより、チャンク番号３からチャンク番号５までのチャンクは、サンプル数２で構成されていることがわかる。
【００４２】
Ｓｙｎｃ ｓａｍｐｌｅ ａｔｏｍは、図２７に示すように、個々のサンプルのうち、単独でデコード可能なサンプルを管理する。そして、Ｓａｍｐｌｅ−ｎｕｍｂｅｒは、単独でデコード可能なサンプル番号を管理する。
【００４３】
図２２に示したサンプル構造の例に対応するＳａｍｐｌｅ ｎｕｍｂｅｒのテーブル（Ｓｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅ）は、図２８に示すように、サンプル１，３，４，６，８，・・・が単独でデコード可能なサンプルであることがわかる。なお、図２２に示す★印が付されたサンプルが単独でデコード可能なサンプルを示している。
【００４４】
Ｓａｍｐｌｅ ｓｉｚｅ ａｔｏｍは、図２９に示すように、個々のサンプルのサイズを管理する。なお、トラック中の全サンプルが同一のサイズの場合には、ｓａｍｐｌｅ−ｓｉｚｅフィールドにそのデータサイズを記録することによって、テーブルを作成する必要はない。よって、各サンプルのデータサイズを示すＳａｍｐｌｅ−ｓｉｚｅテーブル（Ｓａｍｐｌｅ ｓｉｚｅ ｔａｂｌｅ）は、例えば、図３０に示すように、このａｔｏｍでは、全てのサンプルのデータサイズが同一の場合を除いて、トラック中の全サンプルのデータサイズをそれぞれテーブルの１エントリとして管理している。
【００４５】
Ｃｈｕｎｋ ｏｆｆｓｅｔ ａｔｏｍは、図３１に示すように、個々のチャンクのファイル先頭からのアドレスを管理する。
【００４６】
各チャンクのファイルの先頭からのアドレスを示すＣｈｕｎｋ ｏｆｆｓｅｔテーブル（Ｃｈｕｎｋ ｏｆｆｓｅｔ ｔａｂｌｅ）は、例えば、図３２に示すように、このａｔｏｍでは、トラック中の全チャンクのアドレスをそれぞれテーブルの１エントリとして管理している。
【００４７】
ここで、図３３に示すようなサンプル、チャンク構成を有するＱｕｉｃｋＴｉｍｅムービーにおいて、ムービーの先頭を時刻０とした場合に、再生時刻１．Ｔｉｍｅを与えたときに再生するために読み出すべきサンプル情報の取得方法について説明する。なお、図３３においては、再生時刻１．Ｔｉｍｅに相当するサンプルは、２．Ｓａｍｐｌｅ ＃ｎであり、このサンプルは３．Ｃｈｕｎｋ ＃ｍに含まれているものとする。
サンプル情報は、上述したＳａｍｐｌｅ Ｔａｂｌｅ ａｔｏｍ内で定義される各ａｔｏｍの情報を組み合わせて取得される。ここで、各ａｔｏｍを利用したサンプル情報を取得する処理の流れについて、図３４を用いて説明する。
【００４８】
＜サンプルの再生時間長の取得＞
まず、サンプルの再生時間長を取得するために、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍ１００において、再生時刻からその時刻に再生すべきサンプルのサンプル番号（２．ｓａｍｐｌｅ ＃ｎ）と、そのサンプルの再生時間長（９．ｄｕｒａｔｉｏｎ）とを取得する。
＜サンプルのデータサイズの取得＞
次に、サンプルのデータサイズを取得するために、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍ１００によって取得したサンプル番号（２．ｓａｍｐｌｅ ＃ｎ）から、Ｓａｍｐｌｅ ｓｉｚｅ ａｔｏｍ１０２より目的のサンプルのデータサイズ（６．ｓａｍｐｌｅ ｓｉｚｅ ＃ｋ）を取得する。
＜サンプルが単独でデコード可能か否か＞
次に、サンプルが単独でデコード可能か否かを示す情報を取得するために、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍ１００によって取得したサンプル番号（２．ｓａｍｐｌｅ ＃ｎ）から、Ｓｙｎｃ ｓａｍｐｌｅ ａｔｏｍ１０３より指定したサンプルが単独でデコード可能かどうか（Ｓｙｎｃ Ｓａｍｐｌｅかどうか）（１０．Ｓｙｎｃ Ｓａｍｐｌｅ ｏｒ Ｎｏｔ）を取得する。
【００４９】
＜サンプルのアドレス取得＞
次に、サンプルのアドレスを取得するために、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍ１００によって取得したサンプル番号（２．ｓａｍｐｌｅ ＃ｎ）から、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｔｏｍ１０１よりサンプルを含むチャンクのチャンク番号（３．Ｃｈｕｎｋ ＃ｍ）とチャンクの先頭のサンプル番号（Ｓａｍｐｌｅ ＃ｎ−２）、チャンク中のサンプルがどのようなメディア種別なのかを管理するテーブルのインデックス番号を管理する１１．Ｓａｍｐｌｅ Ｄｅｓｃｒｉｐｔｉｏｎ ｉｎｄｅｘを取得する。
【００５０】
取得したチャンク番号（３．Ｃｈｕｎｋ ＃ｍ）より、Ｃｈｕｎｋ ｏｆｆｓｅｔ ａｔｏｍ１０４を用いて注目しているチャンクの先頭アドレス（７．Ｃｈｕｎｋ ｏｆｆｓｅｔ ＃ｊ）を取得する。そして、チャンクの先頭アドレスに、チャンクの先頭のサンプルから目的のサンプルまでのサイズを足し合わせて、目的のサンプルのアドレスを取得する。つまり、取得した７．Ｃｈｕｎｋ ｏｆｆｓｅｔ ＃ｊにｓａｍｐｌｅ ＃ｎ−２、Ｓａｍｐｌｅ ＃ｎ−１のサイズを足し合わせ、８．Ｓａｍｐｌｅ ａｄｄｒｅｓｓを取得する。なお、Ｓａｍｐｌｅ ＃ｎ−２およびＳａｍｐｌｅ ＃ｎ−１のサイズは、上述した＜サンプルのデータサイズの取得＞により取得したものを用いることができる。
【００５１】
このように、ＱｕｉｃｋＴｉｍｅにおいては、ＱｕｉｃｋＴｉｍｅムービーを再生するために必要なサンプル情報を、複数の管理テーブルの情報を組み合わせることで取得することができる。
【００５２】
【特許文献１】
特開２００１−１７６１９５号公報（２００１年６月２９日公開）
【００５３】
【特許文献２】
特開２００２−２４７４８８号公報（２００２年８月３０日公開）
【００５４】
【発明が解決しようとする課題】
しかしながら、上記従来のデータ管理方法では、以下に示すような問題点を有している。
【００５５】
すなわち、従来、マルチメディアデータは、メモリ資源やＣＰＵパワーの豊富なＰＣにおいて取り扱うことが一般的であった。しかし、近年では、メモリ資源やＣＰＵパワーに制限のある、ＰＤＡ（パーソナルデジタルアシスタント）、ディスクビデオレコーダ、カムコーダと言ったＡＶ機器、携帯電話などの民生用機器でもマルチメディアデータを取り扱うようになってきている。
【００５６】
また、ＱｕｉｃｋＴｉｍｅファイルフォーマットは、広く普及している管理方式であるため、様々なプラットフォームにおいて利用されている。
【００５７】
ＱｕｉｃｋＴｉｍｅムービーを記録する記録媒体に関しても記録容量が増大しており、長時間の記録が可能となっている。上述したように、ＱｕｉｃｋＴｉｍｅでは再生に必要なサンプル情報は、Ｓａｍｐｌｅ Ｔａｂｌｅ ａｔｏｍによって管理されているが、記録時間が長くなると、これに比例してＳａｍｐｌｅ Ｔａｂｌｅ ａｔｏｍのデータ量は増加する。
【００５８】
これに対して、メモリ資源等が限られている民生用機器においては、例えば、記録再生できるＱｕｉｃｋＴｉｍｅムービーの時間長の上限を設けるなどの運用規定を設けることが一般的である。このような場合でも、メモリを増やす、再生に必要な管理情報を逐次記録媒体からメモリに読み出す等して、想定している時間以上のＱｕｉｃｋＴｉｍｅムービーを再生可能とすることは可能である。
【００５９】
しかし、メモリの増設は、コストが増える上、記録時間によっては確実に対応できるものではない。一方、記録媒体からメモリへの読み出しについては、メモリには管理情報の一部分しか格納できないため、再生を継続するために再生途中で記録媒体からメモリに管理情報をロードする必要がある。
【００６０】
例えば、ムービーの先頭から順番に再生を開始する場合には、再生するのに必要な管理情報が無くなった段階で、続きの情報をメモリに読み込むことによって再生を継続することができる。しかし、ムービーの任意時間から再生開始を行うようなランダムアクセスを行う場合には、上述したＳａｍｐｌｅ Ｔａｂｌｅ ａｔｏｍ以下の各ａｔｏｍの内容を組み合わせて情報を取得する必要がある。
【００６１】
このとき、Ｓａｍｐｌｅ Ｓｉｚｅ ａｔｏｍに関しては、テーブルの１エントリ＝１サンプルサイズ、Ｃｈｕｎｋ Ｏｆｆｓｅｔ ａｔｏｍに関しては、テーブルの１エントリ＝１チャンクオフセットと１対１の関係になっているため、任意の情報を取得する場合に、どこを読み出せば良いか明確であり、問題は生じない。
【００６２】
しかし、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍ、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｔｏｍ、Ｓｙｎｃ Ｓａｍｐｌｅ ａｔｏｍに関しては、管理情報量を圧縮するために、サンプルの再生時間長の繰り返しやチャンク中のサンプル数の繰り返しを省略している。また、Ｓｙｎｃ Ｓａｍｐｌｅ ａｔｏｍに関しては、単独でデコード可能なサンプル番号のリストを管理している。
【００６３】
このため、このようなデータ管理装置における任意の情報にアクセスするためには、管理テーブルの先頭から順番に見ていかなければ目的の情報がどのエントリなのかを把握することができない。
【００６４】
例えば、図３５に示すように、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍ中の網掛け部分にある情報を取得する場合を例にあげて説明すれば、以下の通りである。なお、図３５のＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅ中の１つの四角は、１回のアクセスでメモリに読み込める量であることを示している。
【００６５】
ここでは、管理情報が全てメモリに存在する場合には、テーブルの先頭から順次情報を読み出しても、毎回計算を行わなければならないということ以外に、特に大きな問題はない。しかし、管理情報が全てメモリに存在しない場合には、図３５に示すように、テーブルの先頭から順番に目的の情報にたどり着くまでに何回も、記録媒体からメモリ上に管理情報を分割して読み出す必要がある。
【００６６】
図３５に示す例では、テーブルの先頭から５回の読み出しを経て、目的の情報をメモリに格納している。このように、任意時間から再生を開始する場合には、ランダムアクセスを行うための情報を取得するまでに、記録媒体に記録されたＱｕｉｃｋＴｉｍｅファイルから何回も管理情報を読み出してからでないと再生を開始できない。
【００６７】
実際に、このような処理を行う必要があるのは、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍ、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｔｏｍ、Ｓｙｎｃ Ｓａｍｐｌｅ ａｔｏｍの３つのａｔｏｍに対してであって、それぞれのａｔｏｍについて同様の処理を行わなければならない。
【００６８】
このため、任意の時間から再生を開始する、いわゆるランダムアクセスを行う際には、このような処理を行う必要があり、再生指示を出してから、実際に絵や音が表示画面等から出力されてムービーの再生が開始されるまでにかなりの時間を要するため、ユーザを待たせることになり、好ましくない。
【００６９】
また、光ディスク等のシーク時間（アクセス時間）やデータの読み出しレートの遅い記録媒体から再生を行う場合には、上記の問題はより顕著に現れる。
【００７０】
そして、上述した任意の時間からの再生についてのみならず、逆再生や早送り、逆早送りなどの特殊再生を行う場合についても、この問題は同様に発生する。
【００７１】
さらに、録画中の電源遮断等に対応するために導入された概念であるＦｒａｇｍｅｎｔｅｄ ｍｏｖｉｅは、ＱｕｉｃｋＴｉｍｅ フォーマットの１アプリケーションであるＭｏｔｉｏｎ ＪＰＥＧ２０００で導入された概念であり、上述のＳａｍｐｌｅ ｔａｂｌｅ ａｔｏｍに相当する情報を、部分的なＡＶストリーム毎に管理することが可能である。つまり、Ｆｒａｇｍｅｎｔｅｄ Ｍｏｖｉｅは、管理情報を分散して管理することを可能とする仕組みである。
【００７２】
このため、Ｆｒａｇｍｅｎｔｅｄ Ｍｏｖｉｅについては、１つのムービーを複数のＦｒａｇｍｅｎｔに分割し、それぞれのＦｒａｇｍｅｎｔ毎に管理情報を持つため、Ｆｒａｇｍｅｎｔ単位のメディアデータとそれを管理する管理情報とは、ペアでムービーファイルに複数記録されることになる。よって、任意の時間に相当するサンプルが含まれるＦｒａｇｍｅｎｔを取得するためには、各Ｆｒａｇｍｅｎｔの管理情報を順番に見ていく必要があり、上記と同様の問題を有する。
【００７３】
本発明は、上記の問題点に鑑みなされたものであり、その目的は、ＱｕｉｃｋＴｉｍｅファイルフォーマット等で記録された情報に対するランダムアクセス時における再生開始までの時間を短縮して、効率よく管理情報の読み出しを行うことができるデータ管理方法およびデータ管理装置、データ管理プログラムならびにこれを記録した記録媒体を提供することにある。
【００７４】
【課題を解決するための手段】
本発明のデータ管理装置は、上記の課題を解決するために、複数のデータ毎の情報を管理する主の管理テーブルを用いて、該主の管理テーブルに含まれるエントリを一定の規則に従うことなく記録した記録媒体から、必要な情報の読み出しを行うデータ管理方法において、上記記録媒体から必要な情報を読み出す際には、上記主の管理テーブルに含まれる複数のエントリ分の累積情報を個々のエントリで管理する補助管理テーブルを用いることを特徴としている。
【００７５】
上記のデータ管理方法によれば、記録媒体の主の管理テーブルに格納された情報を再生する場合には、補助管理テーブルを介して直接的に所望の情報へアクセスし、該所望の情報を効率よく読み出すことで、再生指示を受けてから実際に再生が開始されるまでの時間を短縮できる。
【００７６】
すなわち、上記補助管理テーブルにおいては、主の管理テーブルのエントリを複数個ごとに区切り、該複数個ごとに区切られたエントリの累積情報を１個ずつのエントリで管理している。また、主の管理テーブルは、格納する情報量をできる限り小さくするために、情報の圧縮、繰り返しの情報を省略する等して管理しているため、一定の規則に従って格納されていない。
【００７７】
このため、主の管理テーブルに格納された情報について再生指示があった場合には、主の管理テーブルの所望の情報にアクセスするために、まず、この補助管理テーブルにおける、所望の情報が含まれる累積情報を管理するエントリにアクセスする。そして、当該補助管理テーブルのエントリに対応する主の管理テーブルのエントリを、再生を行う装置等のメモリに対して読み出している。
【００７８】
例えば、主の管理テーブルが時間に関する情報を管理するテーブルである場合には、補助管理テーブルにおいて累積時間情報が管理されているため、任意の時間から処理を開始する、いわゆるランダムアクセスを行う場合でも、この任意の時間が含まれる累積時間情報を有する補助管理テーブルのエントリにアクセスし、このエントリを介して主の管理テーブルの情報を取得する。
【００７９】
これにより、従来のように、主の管理テーブルが有する各テーブルの先頭から順番にアクセスして所望の情報を探し出す必要はなく、補助管理テーブルを介して効率的に所望の情報を取得することで、ユーザから再生指示を受けてから実際に再生が開始されるまでに要する時間を短縮することができる。
【００８０】
なお、本発明のデータ管理方法は、再生指示を受けた所望の情報が記録されている記録媒体が、シーク時間（アクセス時間）やデータの読み出しレートが遅いという特性を有する光ディスク等の記録媒体である場合に特に有効である。
【００８１】
上記補助管理テーブルが備えている各エントリは、上記主の管理テーブルの分割読み出しを行う複数のエントリ分の累積情報を管理していることがより好ましい。
【００８２】
これにより、主の管理テーブルから分割読み出しする単位と、補助管理テーブルの１つのエントリに管理されている主の管理テーブルのエントリ数とを一致させることができるため、主の管理テーブルから再生を行う装置等のメモリに対して、さらに効率よく読み出しを行うことができる。
【００８３】
上記補助管理テーブルの各エントリは、上記累積情報が略等間隔で増加していくように、上記主の管理テーブルのエントリ数を区切って形成されていることがより好ましい。
【００８４】
これにより、補助管理テーブルにおける１エントリの間隔をできる限り等間隔になるように設定することで、おおよその見当をつけて所望の情報が含まれるエントリに対してアクセスすることができる。
【００８５】
よって、所望の情報が含まれるエントリにより効率よくアクセスすることができ、再生開始までに要する時間をより短縮できる。
【００８６】
上記主の管理テーブルが分割読み出しの対象となっており、かつ該分割読み出しを行うエントリに対応する補助管理テーブルが存在しない場合には、補助管理テーブルを生成することがより好ましい。
【００８７】
これにより、分割読み出しを行う主の管理テーブルのエントリに対応する補助管理テーブルが存在していない場合に補助管理テーブルを作成することで、補助管理テーブルの作成を必要最小限にでき、記録する情報量の増大を抑制できる。
【００８８】
上記主の管理テーブルは、ＱｕｉｃｋＴｉｍｅファイルフォーマットであることがより好ましい。
【００８９】
これにより、ビデオデータやオーディオデータ等のメディアデータと管理情報とを備えているＱｕｉｃｋＴｉｍｅファイルフォーマットのうち、管理情報について補助管理テーブルを形成し、該補助管理テーブルを介して所望の情報を含むエントリにアクセスすることで、効率よく所望の情報を取得できる。
【００９０】
上記補助管理テーブルは、時間に関する累積情報を管理していることがより好ましい。
【００９１】
これにより、任意の時間から再生を開始する、いわゆるランダムアクセスを行う場合でも、主の管理テーブルのエントリに１つずつアクセスして所望の情報を探し出す必要はなく、補助管理テーブルの各エントリに管理されている累積時間情報の中から上記任意の時間が含まれるエントリにアクセスすることで、直接的に所望の情報を取得できる。
【００９２】
上記補助管理テーブルは、サンプルおよびチャンクに関する累積情報を管理していることがより好ましい。
【００９３】
これにより、任意のサンプル番号に対応するチャンク情報を取得する場合において、補助管理テーブルの各エントリに管理されている累積サンプル情報の中から、所望のサンプルが含まれるエントリを選択してアクセスすることで、直接的に所望の情報を取得できる。
【００９４】
なお、チャンクとは、同一トラックに記録されたデータの最小単位であるサンプルが、再生時間順にファイル中で連続的に配置された領域をいう。
【００９５】
上記補助管理テーブルは、単独でデコード可能なサンプルに関する情報を管理していることがより好ましい。
【００９６】
これにより、任意のサンプルが単独でデコードできるか否かについて調べる場合において、補助管理テーブルの各エントリに管理されている累積情報の中から、所望のサンプルが含まれるエントリを選択してアクセスすることで、直接的に所望のデコード可能なサンプル情報を取得できる。
【００９７】
本発明のデータ管理装置は、上記の課題を解決するために、複数のデータ毎の情報を管理する主の管理テーブルを用いて、該主の管理テーブルに含まれるエントリを一定の規則に従うことなく記録された記録媒体から、必要な情報の読み出しを行うデータ管理装置において、上記記録媒体から必要な情報を読み出す際には、上記主の管理テーブルに含まれる複数のエントリ分の累積情報を個々のエントリで管理する補助管理テーブルを用いることを特徴としている。
【００９８】
上記の構成によれば、記録媒体の主の管理テーブルに格納された情報を再生する場合には、補助管理テーブルを介して直接的に所望の情報へアクセスし、該所望の情報を効率よく読み出すことで、再生指示を受けてから実際に再生が開始されるまでの時間を短縮できる。
【００９９】
すなわち、上記補助管理テーブルにおいては、主の管理テーブルのエントリを複数個ごとに区切り、該複数個ごとに区切られたエントリの累積情報を１個ずつのエントリでそれぞれ管理している。また、主の管理テーブルは、格納する情報量をできる限り小さくするために、情報の圧縮、繰り返しの情報を省略して管理しており、一定の規則に従って格納されていない。
【０１００】
このため、主の管理テーブルに格納された情報について再生指示があった場合には、主の管理テーブルの所望の情報にアクセスするために、まず、この補助管理テーブルにおける、所望の情報が含まれる累積情報を管理するエントリにアクセスする。そして、当該補助管理テーブルのエントリに対応する主の管理テーブルのエントリを、再生を行う装置等のメモリに対して読み出している。
【０１０１】
例えば、主の管理テーブルが時間に関する情報を管理するテーブルである場合には、補助管理テーブルにおいて累積時間情報が管理されているため、任意の時間から処理を開始する、いわゆるランダムアクセスを行う場合でも、この任意の時間が含まれる累積時間情報を有する補助管理テーブルのエントリにアクセスし、このエントリを介して主の管理テーブルの情報を取得する。
【０１０２】
これにより、従来のように、主の管理テーブルが有する各テーブルの先頭から順番にアクセスして所望の情報を探し出す必要はなく、補助管理テーブルを介して効率的に所望の情報を取得することで、ユーザから再生指示を受けてから実際に再生が開始されるまでに要する時間を短縮することができる。
【０１０３】
なお、本発明のデータ管理装置は、再生指示を受けた所望の情報が記録されている記録媒体が、シーク時間（アクセス時間）やデータの読み出しレートが遅いという特性を有する光ディスク等の記録媒体である場合に特に有効である。
【０１０４】
上記補助管理テーブルが備えている各エントリは、上記主の管理テーブルの分割読み出しを行う複数のエントリ分の累積情報を管理していることがより好ましい。
【０１０５】
これにより、主の管理テーブルから分割読み出しする単位と、補助管理テーブルの１つのエントリに管理されている主の管理テーブルのエントリ数とを一致させることができるため、主の管理テーブルから再生機器等のメモリに対して、さらに効率よく情報の読み出しを行うことができる。
【０１０６】
上記補助管理テーブルの各エントリは、上記累積情報が略等間隔で増加していくように、上記主の管理テーブルのエントリ数を区切って形成されていることがより好ましい。
【０１０７】
これにより、補助管理テーブルにおける１エントリの間隔をできる限り等間隔になるように設定することで、おおよその見当をつけて所望の情報が含まれるエントリに対してアクセスすることができる。
【０１０８】
よって、より効率よく、所望の情報が含まれるエントリにアクセスすることができ、再生開始までに要する時間を短縮できる。
【０１０９】
上記主の管理テーブルが分割読み出しの対象となっており、かつ該分割読み出しを行うエントリに対応する補助管理テーブルが存在しない場合には、補助管理テーブルを生成することがより好ましい。
【０１１０】
これにより、分割読み出しを行う主の管理テーブルのエントリに対応する補助管理テーブルが存在していない場合に補助管理テーブルを作成することで、補助管理テーブルの作成を必要最小限にでき、情報量の増大を抑制できる。
【０１１１】
上記主の管理テーブルは、ＱｕｉｃｋＴｉｍｅファイルフォーマットであることがより好ましい。
【０１１２】
これにより、ビデオデータやオーディオデータ等のメディアデータと管理情報とを備えているＱｕｉｃｋＴｉｍｅファイルフォーマットのうち、管理情報について補助管理テーブルを形成し、該補助管理テーブルを介して所望の情報を含むエントリにアクセスすることで、効率よく所望の情報を取得できる。
【０１１３】
本発明のデータ管理プログラムは、上記の課題を解決するために、上記データ管理方法を、コンピュータに実行させることを特徴としている。
【０１１４】
上記のプログラムによれば、本発明のデータ管理プログラムをコンピュータに実行させることにより、記録媒体の主の管理テーブルに格納された情報を再生する際に、補助管理テーブルを介して直接的に所望の情報へアクセスし、該所望の情報を効率よく読み出すことで、再生指示を受けてから実際に再生が開始されるまでの時間を短縮できる。
【０１１５】
本発明のデータ管理プログラムを記録した記録媒体は、上記の課題を解決するために、上記データ管理プログラムを記録したことを特徴としている。
【０１１６】
上記の構成によれば、本発明の記録媒体をコンピュータに読み取らせることにより、記録媒体の主の管理テーブルに格納された情報を再生する際に、補助管理テーブルを介して直接的に所望の情報へアクセスし、該所望の情報を効率よく読み出すことで、再生指示を受けてから実際に再生が開始されるまでの時間を短縮できる。
【０１１７】
【発明の実施の形態】
本発明のデータ管理方法およびデータ管理装置、データ管理プログラムおよびこれを記録した記録媒体に係る一実施形態について、図１〜図１９を用いて詳しく説明すれば以下の通りである。
【０１１８】
本実施形態のデータ管理方法は、メモリ資源やＣＰＵ資源に制限のある民生用機器により、ＱｕｉｃｋＴｉｍｅファイルに長時間に渡って記録されたデータを効率的に再生可能とするものである。
【０１１９】
本実施形態のデータ管理方法では、図１に示すように、Ｔｒａｃｋ ａｔｏｍにおけるＵｓｅｒ ｄｅｆｉｎｅｄ ｄａｔａ ａｔｏｍの下位テーブルであるＡｃｃｅｓｓ Ｔａｂｌｅ ａｔｏｍの下位テーブルとして、複数の補助アクセステーブル（補助管理テーブル）（Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍ，Ｓａｍｐｌｅ ｔｏ Ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍ，Ｓｙｎｃ Ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍ）を備えている。
【０１２０】
これにより、これらの補助アクセステーブルを用いて、容易に所望の情報を見つけることができるため、全ての管理情報が機器内のメモリに格納できない場合であっても、任意の時間から再生を開始する際に、毎回管理テーブルの先頭から順次所望の情報を見つけるまで、繰り返し読み出しを行う必要がなく、再生指示を受けてから再生開始までに要する時間を短縮できる。
【０１２１】
ここで、本実施形態のデータ管理方法において形成される上記各補助アクセステーブル（Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍ，Ｓａｍｐｌｅ ｔｏ Ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍ，Ｓｙｎｃ Ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍ）の構造について説明する。
【０１２２】
＜Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍの構造＞
Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍに対応する補助アクセステーブルＴｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓａｔｏｍは、図２に示すような構造を有しており、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍのＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅにおける複数のエントリの累積情報を１つ１つのエントリで管理するものである。
【０１２３】
本実施形態のデータ管理方法においては、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのうち、一回のアクセスでメモリに格納できるテーブルのエントリ数を基準として、補助アクセステーブルを構築する。
【０１２４】
Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍは、ｅｎｔｒｙ ｃｏｕｎｔ数分のエントリで構成されるテーブルＴｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅを持つ。各エントリは、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍにおける累積情報を管理する範囲における最後のエントリ＋１を管理するｅｎｔｒｙ ｎｕｍ（範囲の先頭は常にエントリ番号１）、その範囲における先頭のサンプルからのサンプル数の累積合計を示すｃｏｕｎｔ、その範囲における先頭からのサンプルの再生累積時間長を管理するｄｅｌｔａを備えている。
【０１２５】
図３に、図２２に示したサンプル、チャンク構造に対応するＴｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍとＴｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍとのテーブル部分の内容を示す。なお、この例では、説明を簡略化するため、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅにおいて一度にメモリに格納できるエントリ数を３エントリと想定している。実際には、このエントリ数はメモリの大きさに依存し、例えば、１０００エントリといった数になる。
【０１２６】
Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅの１エントリ目では、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのエントリ１〜３までの累積情報を管理している。つまり、エントリ１においては、累積５サンプル、累積再生時間長４８０、次のＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのエントリが４であることを示す。
【０１２７】
同様に、エントリ２では、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのエントリ１〜６までの累積情報を管理する。つまり、エントリ２においては、累積１２サンプル、累積再生時間長１１３５、次のＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのエントリが７であることを示す。
【０１２８】
本実施形態のデータ管理方法では、以上のような構成の補助アクセステーブルＴｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍを用いることによって、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅのｄｅｌｔａのフィールドから目的の時間が含まれるエントリを探し出し、そのテーブルのエントリの情報からダイレクトにＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅの任意のエントリからの一連の情報をメモリに格納することで、任意の時間に対応するサンプル情報を取得できる。
【０１２９】
これにより、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍのテーブルの先頭から順番に情報を読み出す必要がなくなり、処理時間を大幅に短縮することが可能となる。
【０１３０】
＜Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍの構造＞
Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｔｏｍに対応する補助アクセステーブルＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍは、図４に示すような構造を有しており、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｔｏｍにおけるテーブルの複数エントリの累積情報を１つのエントリで管理するものである。
【０１３１】
本実施形態では、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅを一回のアクセスでメモリに格納できるテーブルのエントリ数を基準として、補助アクセステーブルを構築する。
【０１３２】
Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍは、ｅｎｔｒｙ ｃｏｕｎｔ数分のエントリで構成されるテーブル（Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ｔａｂｌｅ）を持つ。各エントリは、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅにおける累積情報を管理する範囲における最後のエントリ＋１を管理するｅｎｔｒｙ ｎｕｍ（最初は常にエントリ番号１）、累積情報を求めた範囲の次のチャンク番号を管理するｃｈｕｎｋ、その範囲におけるサンプル１からの累積合計サンプル数を示すｃｏｕｎｔで構成される。
【０１３３】
図５に、図２２で示すサンプル、チャンク構造に対応するＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｔｏｍとＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍとのテーブル部分の内容を示す。なお、ここでも、説明を簡略化するために、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅにおいて一度にメモリに格納できるエントリ数を３エントリと想定している。実際には、このエントリ数はメモリの大きさに依存し、例えば、１０００エントリといった数になる。
【０１３４】
Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ｔａｂｌｅの１エントリ目では、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのエントリ１〜３までの累積情報を管理している。つまり、エントリ１においては、累積情報を管理している範囲の次のチャンク番号６、チャンク１からチャンク５までの累積サンプル数９、次のＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのエントリが４であることを示す。
【０１３５】
同様に、エントリ２では、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのエントリ１〜６までの累積情報を管理する。つまり、次のチャンクが９、累積１５サンプル、次のＳａｍｐｌｅ
ｔｏ ｃｈｕｎｋ ｔａｂｌｅのエントリは７であることを示す。
【０１３６】
本実施形態のデータ管理方法では、以上のような構成の補助アクセステーブルＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍを用いることによって、任意のサンプル番号に対応するチャンク情報を取得する際には、テーブルのｃｏｕｎｔのフィールドから目的のサンプルが含まれるエントリを探し出し、そのテーブルのエントリの情報に基づいて、ダイレクトにＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅの任意のエントリからの一連の情報をメモリに格納することができる。
【０１３７】
これにより、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｔｏｍのテーブルの先頭から順番に情報を読み出す必要が無くなり、処理時間を大幅に短縮することが可能となる。
【０１３８】
＜Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍの構造＞
Ｓｙｎｃ ｓａｍｐｌｅ ａｔｏｍに対応する補助アクセステーブルＳｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍは、図６に示すような構造を有しており、Ｓｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅにおいて一定間隔の情報を抜き出し管理するものである。
【０１３９】
本実施形態のデータ管理方法においては、Ｓｙｎｃ ｓａｍｐｌｅ ａｔｏｍを一回のアクセスでメモリに格納できるテーブルのエントリ数を基準として、補助アクセステーブルを構築する。
【０１４０】
Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍは、ｅｎｔｒｙ ｃｏｕｎｔ数分のエントリで構成されるテーブル（Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅ）を持つ。各エントリは、Ｓｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅのエントリ番号を管理するｅｎｔｒｙ ｎｕｍ、Ｓｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅにおけるｅｎｔｒｙ ｎｕｍ番目のｓｙｎｃ ｓａｍｐｌｅ ｎｕｍｂｅｒを管理するｓｙｎｃ ｎｕｍ、Ｓｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅにおけるｅｎｔｒｙ ｎｕｍ−１番目のｓｙｎｃ ｓａｍｐｌｅ ｎｕｍｂｅｒを管理するｐｒｅｖ ｓｙｎｃ ｎｕｍで構成される。
【０１４１】
図７に、図２２で示すサンプル、チャンク構造に対応するＳｙｎｃ ｓａｍｐｌｅ ａｔｏｍおよびＳｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍのテーブル部分の内容を示す。なお、ここでも、説明を簡略化するために、Ｓｙｎｃ ｓａｍｐｌｅ ａｔｏｍにおいて一度にメモリに格納できるエントリ数を３エントリと想定している。実際には、このエントリ数はメモリの大きさに依存し、例えば、１０００エントリといった値になる。
【０１４２】
Ｓｙｎｃ ｎｕｍには、Ｓｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅのエントリ１のＳａｍｐｌｅ ｎｕｍｂｅｒである１、ｐｒｅｖ ｓｙｎｃ ｎｕｍには、１つ前のエントリが存在しないためにｎｕｌｌ、ｅｎｔｒｙ ｎｕｍには、エントリ１に注目しているので１がそれぞれ格納されている。
【０１４３】
同様に、エントリ２では、Ｓｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅのエントリ４の情報を管理する。つまり、エントリ４においては、ｓｙｎｃ ｎｕｍには６、ｐｒｅｖ ｓｙｎｃ ｎｕｍには１つ前のエントリ（エントリ３）のＳａｍｐｌｅ ｎｕｍｂｅｒである４、ｅｎｔｒｙ ｎｕｍにはエントリ４に注目しているので４がそれぞれ格納される。
【０１４４】
本実施形態のデータ管理方法では、以上のような構成のＳｙｎｃ ｓａｍｐｌｅ ｔｏ ａｃｃｅｓｓ ａｔｏｍを用いることにより、テーブルのｓｙｎｃ ｎｕｍのフィールドから目的のサンプルが含まれるエントリを探し出し、そのテーブルのエントリの情報からダイレクトにＳｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅの任意のエントリからの一連の情報をメモリに格納するため、任意のサンプルが単独でデコードできるか否かについて調べることができる。
【０１４５】
これにより、Ｓｙｎｃ ｓａｍｐｌｅ ａｔｏｍのテーブルの先頭から順番に情報を読み出す必要が無くなり、処理時間を大幅に短縮することが可能となる。
【０１４６】
本実施形態のデータ管理方法では、以上のように、各種の補助アクセステーブルを用いることによって、例えば、図８に示すＴｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍから、補助アクセステーブルであるｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍの情報に基づいて、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅにおける目的のエントリが含まれる情報を１回のロードで読み出すことが可能となる。これにより、各テーブルの先頭から順番に情報を読み出して所望の情報を探す必要はなく、補助アクセステーブルを介して直接的に所望の情報を読み出して、再生指示を受けてから実際に再生が開始されるまでの時間を短縮できる。
【０１４７】
＜ＱｕｉｃｋＴｉｍｅファイルの管理情報の一般的な読み込み＞
ここで、以上のような構成の補助アクセステーブルを用いて、実際にメモリに対して管理情報を読み込む際の一般的な処理について、図９を用いて説明すれば以下の通りである。
【０１４８】
まず、ステップ（以下、Ｓと示す）１０００において、再生する情報を記録した目的のＱｕｉｃｋＴｉｍｅファイルをオープンする。
【０１４９】
まず、Ｓ１００１において、現在位置より８ｂｙｔｅのデータ（ａｔｏｍ ｈｅａｄｅｒ）を記録媒体から読み出す。
【０１５０】
Ｓ１００２においては、現在位置がファイルの終端であるか否かについて確認し、ファイルの終端である場合には、ステップＳ１００８において、ＱｕｉｃｋＴｉｍｅファイルにおける必須ａｔｏｍがメモリにロードできたか否かについて確認する。ここで、ＱｕｉｃｋＴｉｍｅファイルでないファイルをオープンしていた場合は、この段階で無効ファイルであることが判定される。Ｓ１００８において、必須ａｔｏｍが全て存在する場合には正常終了し、必須ａｔｏｍが全て存在していなかった場合には、Ｓ１００９においてエラー処理を行い、処理を終了する。
【０１５１】
一方、Ｓ１００２において、現在位置がファイルの終端でないと判断された場合には、Ｓ１００３において、読み出した８ｂｙｔｅ（ａｔｏｍ ｈｅａｄｅｒ）からａｔｏｍのサイズとａｔｏｍの種別を把握する。
【０１５２】
Ｓ１００４において、現在処理対象のａｔｏｍが、例えば、Ｍｏｖｉｅ ａｔｏｍ、Ｔｒａｃｋ ａｔｏｍ、Ｍｅｄｉａ ａｔｏｍ等のコンテナタイプのａｔｏｍと判定された場合には、Ｓ１００１に戻り、次の８ｂｙｔｅを記録媒体から読み出して、処理を継続する。
【０１５３】
一方、Ｓ１００４において、コンテナタイプのａｔｏｍと判定されなかった場合には、Ｓ１００５において、データを読み出す必要のあるａｔｏｍタイプであるか否かについての判定が行われる。
【０１５４】
ここで、読み出す必要のないａｔｏｍ（例えば、未知のａｔｏｍなど）と判定された場合には、Ｓ１００７において、現在位置を次ぎのａｔｏｍ ｈｅａｄｅｒの位置までシークし、Ｓ１００１に戻って次の８ｂｙｔｅを読み出し、処理を継続する。なお、次のａｔｏｍ ｈｅａｄｅｒの位置までのシークは、現在のａｔｏｍ ｈｅａｄｅｒの先頭から、ａｔｏｍのサイズ分シークすることによって実現できる。
【０１５５】
一方、Ｓ１００５において、読み出す必要のあるａｔｏｍタイプと判定された場合には、Ｓ１００６において、ａｔｏｍ情報を記録媒体から適切なメモリ空間に読み出す。読み出すデータ量は、現在のａｔｏｍ ｈｅａｄｅｒの先頭から、ａｔｏｍのサイズ分のデータを読み出すことになる。そして、Ｓ１００１に戻り、次の８ｂｙｔｅを読み出して、処理を継続する。
【０１５６】
上述した図９に示す処理は、ＱｕｉｃｋＴｉｍｅファイルの管理情報を読み出す際の一般的な処理の流れの概要であるが、本発明のＳａｍｐｌｅ Ｔａｂｌｅ情報を分割読み出しする場合には、図９に示すＳ１００６におけるａｔｏｍ情報を記録媒体から読み出し、メモリに格納する処理を行う際に特別な処理を行う必要がある。
【０１５７】
＜Ｓａｍｐｌｅ Ｔａｂｌｅの分割読み出し処理＞
そこで、この図９に示したＳ１００６に関し、本実施形態のデータ管理方法を適用した場合の処理について、図１０を用いて説明すれば以下の通りである。
【０１５８】
Ｓ１１００において、アクセスを行っているａｔｏｍが、分割読み出しの対象としてのａｔｏｍであるか否かについて判定を行う。ここで、分割読み出しの対象でない場合には、Ｓ１１０３においてａｔｏｍ情報を記録媒体から読み出し処理を終了する。つまり、図９におけるＳ１００６と同じ処理を行う。一方、Ｓ１１００において、分割読み出し対象のａｔｏｍと判定された場合、つまり、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍ、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｔｏｍ、Ｓｙｎｃ Ｓａｍｐｌｅ ａｔｏｍの何れかのａｔｏｍにアクセスしている場合には、Ｓ１１０１において、ａｔｏｍ ｈｅａｄｅｒで示されるサイズ情報より全てのテーブル情報がメモリにロードできるか否かについて判定を行う。
【０１５９】
ここで、全てのテーブルに対応する情報をメモリにロードできる場合には、Ｓ１１０２において、管理情報を全てメモリに読み出したことを示すために、メモリモードを一括モードにセットし、Ｓ１１０３において、ａｔｏｍに格納された情報を全てメモリに読み出し、処理を終了する。
【０１６０】
一方、Ｓ１１０１において、全てのテーブルの内容をメモリにロードできないと判定された場合、つまり、ａｔｏｍ ｈｅａｄｅｒのサイズ情報が、確保されているメモリ量よりも多い場合には、Ｓ１１０４において、補助アクセステーブルが存在するか否かについて調べる。ここで、補助アクセステーブルが存在しない場合には、Ｓ１１０８において、後段にて詳述する補助アクセステーブルの生成を行う。一方、補助アクセステーブルが存在している場合には、Ｓ１１０５へ進む。
【０１６１】
なお、Ｓ１１０４およびＳ１１０８における処理については、Ｓａｍｐｌｅ Ｔａｂｌｅ情報を読み出す際に、アクセステーブルの存在を把握していなければならない。例えば、この補助アクセステーブルがＳａｍｐｌｅ Ｔａｂｌｅよりもファイルの後に記録されているような場合には、判定を行うことができない。よって、このような場合には、全ての管理情報を読み終わった段階で、分割読み込みの対象となったａｔｏｍが存在する場合において対応する補助アクセステーブルが存在するか否かについて調べ、ここで存在しない場合に補助アクセステーブルを生成する処理を行えばよい。
【０１６２】
Ｓ１１０５においては、分割読み出しを行うテーブルの内、メモリに格納できる分だけをロードする。
【０１６３】
Ｓ１１０６においては、管理情報が全てメモリに読み出せなかったことを示すために、メモリモードを分割モードにセットする。
【０１６４】
Ｓ１１０７においては、次のａｔｏｍ ｈｅａｄｅｒの位置までシークして、処理を終了する。つまり、読み出せなかったテーブルのデータ量分だけシークすることによって、次のａｔｏｍ ｈｅａｄｅｒの位置にシークすることが可能である。
【０１６５】
本実施形態のデータ管理方法では、以上のような処理を行うことにより、Ｓａｍｐｌｅ Ｔａｂｌｅ情報を分割して読み出すことができる。
【０１６６】
＜Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍの生成＞
続いて、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍを生成する際の処理の流れについて、図１１を用いて説明すれば以下の通りである。
【０１６７】
Ｓ１２００においては、分割読み出しする単位ｎを決定する。ｎは一度にメモリにロードするテーブルのエントリ数を指す。例えば、一度に１００エントリをメモリに格納する場合にはｎ＝１００になる。Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅの１エントリに必要なメモリ量は８バイトであるから、テーブルをロードするのに必要なメモリ量は８バイト×ｎになる。
【０１６８】
Ｓ１２０１においては、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍの基本部分、具体的には、ａｔｏｍ ｈｅａｄｅｒの次に格納された情報からＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅまでの情報を読み出す。
【０１６９】
Ｓ１２０２においては、変数の初期化を行う。
【０１７０】
Ｓ１２０３においては、変数ｋがＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのエントリ数を超えたか否かについて判定を行う。ここで、変数ｋがＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのエントリ数を超えている場合には、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍの情報を全て生成したことを意味しているため、このまま処理を終了する。なお、生成したＴｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍは、Ｔｒａｃｋ ａｔｏｍ下のＵｓｅｒ ｄｅｆｉｎｅｄ ｄａｔａ ａｔｏｍ内にＡｃｃｅｓｓ ｔａｂｌｅ ａｔｏｍの一部として記録される。
【０１７１】
一方、Ｓ１２０３において、変数ｋがＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのエントリ数を超えていない場合、つまり、全てのＴｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅのエントリ生成が完了していない場合には、Ｓ１２０４において、次のｎエントリ分のＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅの情報を読み出す。
【０１７２】
Ｓ１２０５においては、Ｃｏｕｎｔｔｍｐおよびｄｅｌｔａｔｍｐ変数を初期化する。
【０１７３】
Ｓ１２０６においては、ロードしたＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅの全てのエントリに対して、繰り返しが完了したか否かについて判定を行い、繰り返しが完了していない場合には、Ｓ１２０７において、ｃｏｕｎｔｔｍｐの値に現在注目しているＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのＩ番目のエントリのｓａｍｐｌｅ ｃｏｕｎｔ値を加算する。Ｓ１２０８において、同様にｄｅｌｔａｔｍｐにｓａｍｐｌｅ ｄｅｌｔａの値を加算する。すなわち、Ｓ１２０７およびＳ１２０８においては、メモリにロードしたＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅの累積情報を生成している。
【０１７４】
一方、Ｓ１２０６において、繰り返しが完了したと判定された場合には、Ｓ１２０９において、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅのエントリのｃｏｕｎｔを生成する。具体的には、ひとつ前のエントリのｃｏｕｎｔ値（一つ前までの累積値）に、メモリにロードしたＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅ情報の累積合計値ｃｏｕｎｔｔｍｐを加算する。
【０１７５】
Ｓ１２１０においては、同様に、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅのエントリのｄｅｌｔａを生成する。具体的には、ひとつ前のエントリのｄｅｌｔａ値（一つ前までの累積値）に、メモリにロードしたＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅ情報の累積合計値ｄｅｌｔａｔｍｐを加算する。
【０１７６】
Ｓ１２１１においては、現在注目しているＴｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅのエントリ番号を表すｊに１を加算し、現在注目しているＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのエントリ番号を示すｋにメモリに読み出したエントリ数ｎを加算する。
【０１７７】
Ｓ１２１２においては、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅのｅｎｔｒｙ ｎｕｍにｔｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのエントリ番号ｋに１を加算した値を代入し、Ｓ１２０３に戻って処理を繰り返す。
【０１７８】
以上のように、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍの情報を全て生成したことが分かるまで繰り返し図１１に示す処理を行うことで、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍを生成できる。
【０１７９】
＜Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍの生成＞
続いて、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍを生成する際の処理の流れについて、図１２を用いて説明すれば、以下の通りである。
【０１８０】
Ｓ１３００においては、分割読み出しする単位ｎを決定する。なお、ｎは一度にメモリにロードするテーブルのエントリ数を指す。例えば、一度に１００エントリをメモリに格納する場合にはｎ＝１００となる。Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅの１エントリに必要なメモリ量は１２バイトなので、テーブルをロードするのに必要なメモリ量は１２バイト×ｎになる。
【０１８１】
Ｓ１３０１においては、Ｓａｍｐｌｅ ｔｏ Ｃｈｕｎｋ ａｔｏｍの基本部分、具体的には、ａｔｏｍｈｅａｄｅｒの次に格納された情報から、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅまでの情報を読み出す。
【０１８２】
Ｓ１３０２においては、変数の初期化を行う。
【０１８３】
Ｓ１３０３においては、変数ｋがＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのエントリ数を超えたか否かについて判定を行う。ここで、変数ｋがＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのエントリ数を超えている場合には、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍの情報を全て生成したことを意味するため、そのまま処理を終了する。なお、生成したＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍは、Ｔｒａｃｋ ａｔｏｍ下のＵｓｅｒ ｄｅｆｉｎｅｄ ｄａｔａ ａｔｏｍ内にＡｃｃｅｓｓ ｔａｂｌｅ ａｔｏｍの一部として記録する。
【０１８４】
一方、Ｓ１３０３において、変数ｋがＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのエントリ数を超えていない場合、つまり、全てのＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍのエントリ生成が完了していない場合には、Ｓ１３０４において、次のｎエントリ分のＳａｍｐｌｅ
ｔｏ ｃｈｕｎｋ ｔａｂｌｅの情報を読み出す。
【０１８５】
Ｓ１３０５においては、Ｃｏｕｎｔｔｍｐ変数を初期化する。
【０１８６】
Ｓ１３０６においては、ロードしたＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅの全てのエントリに対して繰り返しが完了したか否かについて判定を行う。ここで、繰り返しが完了していない場合には、Ｓ１３０７において、ｃｏｕｎｔｔｍｐの値に現在注目しているＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのエントリと次のエントリのｆｉｒｓｔ ｃｈｕｎｋの値の差、つまりチャンク数を求めたものに、チャンク中のサンプル数を管理しているｓａｍｐｌｅｓ ｐｅｒ ｃｈｕｎｋの値を掛け合わせたものを足し合わせる。すなわち、Ｓ１３０７においては、メモリにロードしたＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅの累積情報を生成している。
【０１８７】
一方、Ｓ１３０６において繰り返しが完了したと判定された場合には、Ｓ１３０８において、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ｔａｂｌｅのエントリのｃｏｕｎｔを生成する。具体的には、ひとつ前のエントリのｃｏｕｎｔ値（一つ前までの累積値）に、メモリにロードしたＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅ情報の累積合計値ｃｏｕｎｔｔｍｐを足し合わせる。
【０１８８】
Ｓ１３０９においては、現在注目しているＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ｔａｂｌｅのエントリ番号を表わすｊに１を加算し、該Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのエントリ番号を示すｋにメモリに読み出したエントリ数ｎを加算する。
【０１８９】
Ｓ１３１０においては、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ｔａｂｌｅのｅｎｔｒｙ ｎｕｍにＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのエントリ番号ｋに１を加算した値を代入する。
【０１９０】
Ｓ１３１１においては、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ｔａｂｌｅのｃｈｕｎｋにＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅにおけるｅｎｔｒｙ ｎｕｍ番目のエントリのｆｉｒｓｔ ｃｈｕｎｋの値を代入した後、Ｓ１３０３に戻って、処理を繰り返す。
【０１９１】
以上のように、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍの情報を全て生成したことが分かるまで、繰り返し図１２に示すような処理を行うことで、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍを生成できる。
【０１９２】
＜Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍの生成＞
続いて、Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍを生成する際の処理の流れについて、図１３を用いて説明すれば、以下の通りである。
【０１９３】
Ｓ１４００においては、分割読み出しする単位ｎを決定する。ｎは一度にメモリにロードするテーブルのエントリ数を指す。例えば、一度に１００エントリをメモリに格納する場合においては、ｎ＝１００となる。Ｓｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅの１エントリに必要なメモリ量は４バイトなので、テーブルをロードするのに必要なメモリ量は４バイト×ｎである。
【０１９４】
Ｓ１４０１においては、Ｓｙｎｃ ｓａｍｐｌｅ ａｔｏｍの基本部分、具体的には、ａｔｏｍ ｈｅａｄｅｒの次に格納された情報からＳｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅまでの情報を読み込む。
【０１９５】
Ｓ１４０２においては、変数の初期化を行う。
【０１９６】
Ｓ１４０３においては、変数ｋがＳｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅのエントリ数を超えたか否かについて判定を行う。ここで、変数ｋがＳｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅのエントリ数を超えている場合には、Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍの情報を全て生成したことを意味するため、このまま処理を終了する。なお、生成したＳｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍはＴｒａｃｋ ａｔｏｍ下のＵｓｅｒ ｄｅｆｉｎｅｄ ｄａｔａ ａｔｏｍ内にＡｃｃｅｓｓ Ｔａｂｌｅ ａｔｏｍの一部として記録する。
【０１９７】
一方、Ｓ１４０３において、変数ｋがＳｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅのエントリ数を超えていない場合、つまり、全てのＳｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍのエントリ生成が完了していないと判定された場合には、Ｓ１４０４に進む。
【０１９８】
Ｓ１４０４においては、ｋ−１が１以上であるか否かについて判定を行う。ここで、Ｋが１の場合には、一番先頭のテーブルを検出するための処理を行うため、Ｓ１４１１において、Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅのエントリｐｒｅｖ ｓｙｎｃ ｎｕｍに前のｓｙｎｃ ｓａｍｐｌｅ情報がないことを示すｎｕｌｌを代入して、Ｓ１４０７へ進む。
【０１９９】
一方、Ｓ１４０４において、Ｋが１以外である場合には、Ｓ１４０５において、（Ｋ−１）番目のＳｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅのエントリを読み出し、Ｓ１４０６において、ｐｒｅｖ ｓｙｎｃ ｎｕｍに読み出した（Ｋ−１）番目のエントリの情報を代入する。
【０２００】
Ｓ１４０７においては、Ｋ番目のＳｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅのエントリを読み出す。
【０２０１】
Ｓ１４０８においては、読み出したＫ番目のエントリをｓｙｎｃ ｎｕｍに代入する。
【０２０２】
Ｓ１４０９においては、Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅのエントリｅｎｔｒｙ ｎｕｍにＫを代入する。
【０２０３】
Ｓ１４１０においては、現在注目しているＳｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅのエントリ番号を表わすｊに１を加算し、現在注目しているＳｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅのエントリ番号を示すＫにｎを加算し、次にアクセスするエントリ番号を更新する。
【０２０４】
以上のように、Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍの情報を全て生成したことが分かるまで、繰り返し図１２に示すような処理を行うことで、Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍを生成できる。
【０２０５】
＜補助アクセス情報の記録＞
本実施形態のデータ管理方法では、図１１〜図１３に示すような補助アクセステーブルの生成方法に従って生成した各補助アクセステーブルについて、この補助アクセステーブルの生成処理はトラック単位で行われるため、図１に示す補助アクセステーブルは、トラック毎にＴｒａｃｋ ａｔｏｍの下層のＵｓｅｒ ｄｅｆｉｎｅｄ ｄａｔａ ａｔｏｍの中にそれぞれ記録される。
【０２０６】
Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍ、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍ、Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍにそれぞれ生成した補助アクセステーブルは、コンテナａｔｏｍであるＡｃｃｅｓｓ Ｔａｂｌｅ ａｔｏｍに格納され、Ｕｓｅｒ ｄｅｆｉｎｅｄ ｄａｔａ ａｔｏｍ内に記録される。
【０２０７】
次に、以上のように、補助アクセス情報が記録された補助アクセステーブルを備えたＱｕｉｃｋＴｉｍｅファイルに対して、任意の時間から再生を開始するランダムアクセスを行う際の処理について説明すれば、以下の通りである。
【０２０８】
＜Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍからの情報の取得方法＞
まず、本発明のデータ管理方法における、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍから必要な情報を取得する処理について、図１６を用いて説明する。Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍは、図３４を用いて説明したように、指定した再生時刻に対応したサンプル番号とそのサンプルの再生時間長を取得するための管理情報とを格納している。
【０２０９】
Ｓ１５００においては、変数ｓｍｐｎｕｍ、ｔｉｍｅ、ｊを初期化する。
【０２１０】
Ｓ１５０１においては、注目しているトラックのＵｓｅｒ ｄｅｆｉｎｅｄ ｄａｔａ ａｔｏｍ内のＡｃｃｅｓｓ ｔａｂｌｅ ａｔｏｍに、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍが存在するか否かについて調べる。
【０２１１】
これは、分割読み出しモードでは、必ずＴｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍが存在することを前提とした処理であり、存在するか否かについて調べているのは、Ｔｉｍｅｔｏ ｓａｍｐｌｅ ａｔｏｍのテーブル部分が小さい場合に、全ての情報をメモリにロードできているか否かについて調べるためである。なお、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍの情報が全てメモリにロードできない状況であって、かつＴｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍが存在しないような場合には、図１１に示すフローチャートに従って補助アクセステーブルを生成してもよい。
【０２１２】
上記Ｓ１５０１において、補助アクセステーブルが存在しない場合は、Ｓ１５０５へ進む。一方、補助アクセステーブルが存在する場合には、Ｓ１５０２において、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅのエントリ数に相当する分だけ繰り返し処理を行う。
【０２１３】
このとき、全エントリについて調査が終了した場合には、目的のエントリが探し出せなかったことを意味するため、Ｓ１５１２においてエラー処理を行い、処理を終了する。
【０２１４】
一方、全てのエントリについて調査が終わっていない場合には、Ｓ１５０３において、指定した再生時刻ｉｎｔｉｍｅとＴｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅのエントリのｄｅｌｔａとを比較する。ここで、ｄｅｌｔａの方がｉｎｔｉｍｅより小さい場合には、Ｓ１５０２に戻って処理を繰り返す。一方、ｄｅｌｔａがｉｎｔｉｍｅより大きい場合には、Ｓ１５０４へ進む。
【０２１５】
Ｓ１５０４においては、変数ｔｉｍｅにＴｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅにおける１つ前のエントリのｄｅｌｔａを、変数ｓｍｐｎｕｍにｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅにおける１つ前のエントリのｃｏｕｎｔを、ｊにｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅにおける１つ前のエントリのｅｎｔｒｙ ｎｕｍの値をそれぞれ代入する。
【０２１６】
Ｓ１５０５においては、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのｊ番目のエントリがメモリ上に存在するか否かについて調べる。ここで、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのｊ番目のエントリがメモリ上に存在する場合にはＳ１５０７へ進む。一方、存在しない場合には、Ｓ１５０６において、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅから、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅのｅｎｔｒｙ ｎｕｍ［ｉ−１］番目からｅｎｔｒｙ ｎｕｍ［ｉ］番目のエントリを記録媒体から読み出して、メモリにロードする。
【０２１７】
Ｓ１５０７においては、注目しているＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのｊ番目のエントリのｓａｍｐｌｅ ｃｏｕｎｔだけ処理を繰り返し、繰り返しが完了するとＳ１５１０へ進む。なお、繰り返しが完了していない場合には、Ｓ１５０８において、指定した再生時刻ｉｎｔｉｍｅが変数ｔｉｍｅにＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのｊ番目のエントリのｓａｍｐｌｅ ｄｅｌｔａを足した値より小さいか否かについて判定を行い、小さいと判定された場合には、目的のサンプルが見つかったことを意味するため、ここで処理を終了する。このとき、指定した再生時刻ｉｎｔｉｍｅに対応するサンプル番号は、変数ｓｍｐｎｕｍの値であり、サンプルの再生時間長は、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのｊ番目のエントリのｓａｍｐｌｅ ｄｅｌｔａ値である。
【０２１８】
一方、Ｓ１５０８において、指定した再生時刻ｉｎｔｉｍｅが変数ｔｉｍｅにＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのｊ番目のエントリのｓａｍｐｌｅ ｄｅｌｔａを足した値より大きいと判定された場合には、Ｓ１５０９において、変数ｔｉｍｅにｊ番目のエントリのｓａｍｐｌｅ ｄｅｌｔａの値を加算し、変数ｓｍｐｎｕｍに１を加算し、Ｓ１５０７に戻って処理を繰り返す。
【０２１９】
Ｓ１５１０においては、現在注目しているＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのエントリ番号であるｊに１を加算する。
【０２２０】
Ｓ１５１１においては、ｊがＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅの総エントリ数を超えているか否かについて判定を行い、総エントリ数を超えている場合には、指定した時間の情報が無かったことを意味するため、Ｓ１５１２においてエラー処理を行い、処理を終了する。一方、Ｓ１５１１において、総エントリ数を超えていない場合には、Ｓ１５０７に戻って処理を繰り返す。
【０２２１】
以上のように、本実施形態のデータ管理方法では、ＱｕｉｃｋＴｉｍｅファイルのＴｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍに格納された情報を効率よく取得することができる。
【０２２２】
＜Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｔｏｍからの情報の取得方法＞
続いて、本実施形態のデータ管理方法により、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｔｏｍから必要な情報を取得する処理の流れについて、図１５を用いて説明すれば以下の通りである。
【０２２３】
Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｔｏｍは、図３４を用いて説明したように、指定したサンプル番号に対応したチャンク番号とそのチャンク中のサンプル数などを取得するための管理情報である。
【０２２４】
Ｓ１６００においては、変数ｉ、ｃｈｋｔｍｐ、ｓｍｐｔｍｐを初期化する。
【０２２５】
Ｓ１６０１においては、注目しているトラックのＵｓｅｒ ｄｅｆｉｎｅｄ ｄａｔａ ａｔｏｍ内のＡｃｃｅｓｓ ｔａｂｌｅ ａｔｏｍにＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍが存在するか否かについて調べる。
【０２２６】
なお、これは、分割読み出しモードでは、必ずＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍが存在することを前提とした処理であって、存在するか否かについて調べているのは、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｔｏｍのテーブル部分が小さい場合に、全てメモリにロードできているか否かについて調べるためである。また、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｔｏｍの情報が全てメモリにロードできない状況であって、かつ、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍが存在しないような場合においては、図１２に示した方法により補助アクセステーブルを生成してもよい。
【０２２７】
上記Ｓ１６０１において、補助アクセステーブルが存在しない場合には、Ｓ１６０５へ進む。一方、補助アクセステーブルが存在する場合には、Ｓ１６０２において、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ｔａｂｌｅのエントリ数分繰り返し処理を行う。
【０２２８】
ここで、全エントリについて調査が終わってしまった場合には、目的のエントリが探せなかったことを意味するため、Ｓ１６１２においてエラー処理を行い、処理を終了する。一方、全てのエントリについて調査が終わっていない場合には、Ｓ１６０３において、指定したサンプル番号ｓｍｐｎｕｍと、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ｔａｂｌｅのエントリのｃｏｕｎｔとを比較する。ここで、ｃｏｕｎｔの方がｓｍｐｎｕｍより小さい場合には、Ｓ１６０２に戻って処理を繰り返す。一方、ｃｏｕｎｔがｓｍｐｎｕｍより大きい場合には、Ｓ１６０４へ進む。
【０２２９】
Ｓ１６０４においては、変数ｃｈｋｔｍｐにＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ｔａｂｌｅにおける１つ前のエントリのｃｈｕｎｋを、変数ｓｍｐｔｍｐにＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ｔａｂｌｅにおける１つ前のエントリのｃｏｕｎｔを、ｊにＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ｔａｂｌｅにおける１つ前のエントリｅｎｔｒｙ ｎｕｍの値をそれぞれ代入する。
【０２３０】
Ｓ１６０５においては、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのｊ番目のエントリがメモリ上に存在するか否かについて調べる。ここで、存在する場合にはＳ１６０７に進み、存在しない場合には、Ｓ１６０６において、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅから、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ｔａｂｌｅのｅｎｔｒｙ ｎｕｍ［ｉ−１］番目からｅｎｔｒｙ ｎｕｍ［ｉ］番目のエントリを記録媒体から読み出してメモリにロードする。
【０２３１】
Ｓ１６０７においては、注目しているＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのｊ番目のエントリのｆｉｒｓｔ ｃｈｕｎｋからｊ＋１番目のエントリのｆｉｒｓｔ ｃｈｕｎｋの値まで処理を繰り返し、繰り返しが完了した場合には、Ｓ１６１０へ進む。一方、繰り返しが完了していない場合には、Ｓ１６０８において、指定したサンプル番号が、変数ｓｍｐｔｍｐにＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのｊ番目のエントリのｓａｍｐｌｅ ｐｅｒ ｃｈｕｎｋの値を加算した値より小さいか否かについて判定を行う。
【０２３２】
ここで、指定したサンプル番号が、変数ｓｍｐｔｍｐにＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのｊ番目のエントリのｓａｍｐｌｅ ｐｅｒ ｃｈｕｎｋの値を加算した値より小さいと判定された場合には、目的のチャンク情報が見つかったことを意味するため、このまま処理を終了する。このとき、指定したサンプル番号に対応するチャンク番号は変数Ｋの値であり、チャンク中のサンプル数はＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのｊ番目のエントリのｓａｍｐｌｅｓ ｐｅｒ ｃｈｕｎｋの値である。一方、大きいと判定された場合には、Ｓ１６０９において変数ｓｍｐｔｍｐの値にｊ番目のエントリのｓａｍｐｌｅｓ ｐｅｒ ｃｈｕｎｋの値を足し合わせ、Ｓ１６０７に戻って処理を繰り返す。
【０２３３】
Ｓ１６１０においては、現在注目しているＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのエントリ番号であるｊに１を加算する。
【０２３４】
Ｓ１６１１においては、ｊがＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅの総エントリ数を超えているか否かについて判定を行う。ここで、ｊがＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅの総エントリ数を超えていると判定された場合には、指定したサンプルの情報が無かったことを意味するため、Ｓ１６１２においてエラー処理を行って処理を終了する。一方、Ｓ１６１１において、ｊがＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅの総エントリ数を超えていないと判定された場合には、Ｓ１６０７に戻って処理を繰り返す。
【０２３５】
本実施形態のデータ管理方法においては、以上のような処理を行うことにより、ＱｕｉｃｋＴｉｍｅファイルのＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｔｏｍに格納された情報を効率よく取得できる。
【０２３６】
＜Ｓｙｎｃ ｓａｍｐｌｅ ａｔｏｍからの情報の取得方法＞
本実施形態のデータ管理方法におけるＳｙｎｃ Ｓａｍｐｌｅ ａｔｏｍから必要な情報を取得する処理について、図１６を用いて説明すれば以下の通りである。
【０２３７】
なお、Ｓｙｎｃ ｓａｍｐｌｅ ａｔｏｍは、図３４を用いて説明したように、指定したサンプル番号のサンプルが単独でデコード可能か否かについて調べるための管理情報である。
【０２３８】
Ｓ１７００においては、変数ｉを初期化する。
【０２３９】
Ｓ１７０１においては、注目しているトラックのＵｓｅｒ ｄｅｆｉｎｅｄ ｄａｔａ ａｔｏｍ内のＡｃｃｅｓｓ ｔａｂｌｅ ａｔｏｍにＳｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍが存在するか否かについて調べる。ここでは、分割読み出しモードの場合には、必ずＳｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍが存在することを前提にしており、存在するか否かについて調べているのは、Ｓｙｎｃｓａｍｐｌｅ ａｔｏｍのテーブル部分が小さく全てメモリにロードできているかどうかを調べるためである。なお、処理によっては、Ｓｙｎｃ ｓａｍｐｌｅ ａｔｏｍの情報が全てメモリにロードできない状況であって、かつ、Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍが存在しない場合に、上述した図１３に示す方法により補助アクセステーブルを生成してもよい。
【０２４０】
ここで、注目しているトラックのＵｓｅｒ ｄｅｆｉｎｅｄ ｄａｔａ ａｔｏｍ内のＡｃｃｅｓｓ ｔａｂｌｅ ａｔｏｍにＳｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍが存在しない場合には、Ｓ１７０５へ進む。
【０２４１】
一方、注目しているトラックのＵｓｅｒ ｄｅｆｉｎｅｄ ｄａｔａ ａｔｏｍ内のＡｃｃｅｓｓ ｔａｂｌｅ ａｔｏｍにＳｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍが存在する場合には、Ｓ１７０２において、Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅのエントリ数分繰り返し処理を行う。
【０２４２】
このとき、全エントリについて調査が終わってしまった場合には、目的のエントリが探し出せなかったことを意味するため、Ｓ１７１１においてエラー処理を行って処理を終了する。一方、全てのエントリについて調査が終わっていない場合には、Ｓ１７０３において、指定したサンプル番号ｓｍｐｎｕｍとＳｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅのエントリのｓｙｎｃ ｎｕｍとを比較する。
【０２４３】
比較した結果、ｓｙｎｃ ｎｕｍの方がｓｍｐｎｕｍより小さい場合には、Ｓ１７０２に戻って処理を繰り返す。一方、ｓｙｎｃ ｎｕｍがｓｍｐｎｕｍより大きい場合には、Ｓ１７０４に進む。
【０２４４】
Ｓ１７０４においては、Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅにおける１つ前のエントリのｅｎｔｒｙ ｎｕｍの値をｊに代入する。
【０２４５】
Ｓ１７０５においては、Ｓｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅのｊ番目のエントリがメモリ上に存在するか否かについて調べ、存在する場合にはＳ１７０７に進む。一方、存在しない場合は、Ｓ１７０６において、Ｓｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅから、Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅのｅｎｔｒｙ ｎｕｍ［ｉ−１］からｅｎｔｒｙ ｎｕｍ［ｉ］番目のエントリを記録媒体より読み出し、メモリにロードする。
【０２４６】
Ｓ１７０７においては、指定したサンプル番号ｓｍｐｎｕｍがＳｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅのｊ番目のエントリのｓａｍｐｌｅ ｎｕｍｂｅｒと一致するか否かについて判定を行う。
【０２４７】
ここで、一致する場合には、指定したサンプルが単独でデコード可能であることを意味するため処理を終了する。一方、一致しない場合には、Ｓ１７０８において、指定したサンプルのサンプル番号ｓｍｐｎｕｍとＳｙｎｃ Ｓａｍｐｌｅ ｔａｂｌｅのｊ番目のエントリのｓａｍｐｌｅ ｎｕｍｂｅｒとを比較する。ここで、ｓｍｐｎｕｍの方が小さい場合には、指定したサンプルは単独でデコードできないことを意味するため、処理を終了する。一方、大きい場合には、Ｓ１７０９において、注目しているエントリ番号ｊに１を足し合わせる。
【０２４８】
Ｓ１７１０においては、ｊがＳｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅの総エントリ数を超えているか否かについて判定を行う。ここで、超えている場合には、指定したサンプルの情報が無かったことを意味するため、Ｓ１７１０においてエラー処理を行って処理を終了する。一方、超えていない場合には、Ｓ１７０７に戻って処理を繰り返す。
【０２４９】
本実施形態のデータ管理方法では、以上のような処理を行うことにより、ＱｕｉｃｋＴｉｍｅファイルのＳｙｎｃ ｓａｍｐｌｅ ａｔｏｍに格納された情報を効率よく取得できる。
【０２５０】
本実施形態のデータ管理方法は、以上のように、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍ、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍ、Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍのような補助アクセステーブルを設けることによって、任意の時間から再生を開始するランダムアクセスを行う際に、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅ、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅ、Ｓｙｎｃ ｓａｍｐｌｅｔａｂｌｅのそれぞれにおいて、テーブルの先頭から順番に目的の情報を探し出すまで、繰り返し読み出す必要がなくなる。よって、再生開始までの処理時間を大幅に短縮することが可能となる。また、読み出す管理情報が記録されている記録媒体が、光ディスクなどシーク時間（アクセス時間）やデータの読み出しレートの遅い媒体においては、さらに効果が大きくなる。
【０２５１】
また、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅ、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ｔａｂｌｅ、Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅの各エントリについて、それぞれ、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅ、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅ、Ｓｙｎｃ Ｓａｍｐｌｅ ｔａｂｌｅを、再生機器のメモリに分割ロードする単位で生成することによって、補助アクセステーブルの１つのエントリが格納している累積情報と、主のテーブルの分割読み出しする単位と一致するため、再生機器等メモリへ効率よく読み出しを行うことが可能となる。
【０２５２】
＜バリエーション＞
本実施形態のデータ管理方法では、上述したように、補助アクセステーブルにおけるｔａｂｌｅ情報のエントリは、主の管理テーブルを分割読み出しする単位を基準に生成されている。
【０２５３】
例えば、図３（図５，図７も同様）に示すように、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅを３エントリ単位で記録媒体から分割読み出しするような場合には、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅａｃｃｅｓｓ ｔａｂｌｅではＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅの３エントリ単位でテーブルの先頭からの累積情報を管理している。
【０２５４】
このような構成にすることによって、補助アクセステーブルに格納する情報の単位（エントリ数）が、分割読み出しする単位（エントリ数）と一致するため、効率よく情報の分割読み出しを行うことができる。
【０２５５】
ここで、補助アクセステーブルにおけるｔａｂｌｅ情報のエントリ生成方法として、主の管理テーブルにアクセスするためのインデックス情報ができるだけ等間隔に配置されるように設定する方法について説明する。
【０２５６】
＜Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍのバリエーション＞
まず、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍとＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅとの関係について、図１７を用いて説明すれば以下の通りである。
【０２５７】
ここでは、約５００ｔｉｍｅ ｕｎｉｔ毎に対応するＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのエントリにアクセスできるように、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅのエントリを生成している。
【０２５８】
Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅのｄｅｌｔａは、先頭からの累積再生時間長を表すフィールドであるため、約５００ｔｉｍｅ ｕｎｉｔ単位で数字が増えている。ただし、上記ｄｅｌｔａは５００ｔｉｍｅ ｕｎｉｔぴったりで区切れないため、５００ｔｉｍｅ ｕｎｉｔに一番近い時間情報が格納されている。Ｅｎｔｒｙ ｎｕｍには、対応するＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのエントリ番号、ｃｏｕｎｔには、先頭からの累積サンプル数が管理されている。
【０２５９】
例えば、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅの１エントリ目では、累積再生時間長ｄｅｌｔａ＝４８０に対応する、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのエントリ番号はｅｎｔｒｙ ｎｕｍ＝４、エントリ番号１〜３までに、累積５サンプル存在することを表している。また、２エントリ目では、累積再生時間長ｄｅｌｔａ＝８６５に対応する、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのエントリ番号はｅｎｔｒｙ ｎｕｍ＝６、エントリ番号１〜５までに累積９サンプル存在することを表している。
【０２６０】
なお、補助テーブルの作成方法やアクセス方法については、既に説明した方法と基本的な考えは同一であるため、説明を省略する。
【０２６１】
＜Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍのバリエーション＞
次に、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍとＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅとの関係について、図１８を用いて説明すれば以下の通りである。
【０２６２】
ここでは、約５サンプル毎に対応するＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのエントリにアクセスできるように、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ｔａｂｌｅのエントリを生成している。
【０２６３】
Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ｔａｂｌｅのｃｏｕｎｔは、先頭からの累積サンプル数を表すフィールドであるため、約５サンプル単位で数字が増えている。ただし、ｃｏｕｎｔは、５サンプルぴったりで区切れないため、５サンプルに一番近い情報が格納されている。Ｅｎｔｒｙ ｎｕｍには、対応するＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのエントリ番号、ｃｈｕｎｋには対応するＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのｆｉｒｓｔ ｃｈｕｎｋの値を管理している。
【０２６４】
例えば、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ｔａｂｌｅの１エントリ目では、累積サンプル数＝３に対応する、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのエントリ番号はｅｎｔｒｙ ｎｕｍ＝３、対応するｆｉｒｓｔ ｃｈｕｎｋの値であるｃｈｕｎｋには３を管理している。
【０２６５】
また、２エントリ目では、累積サンプル数＝１２に対応する、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのエントリ番号はｅｎｔｒｙ ｎｕｍ＝５、対応するｆｉｒｓｔ ｃｈｕｎｋの値であるｃｈｕｎｋには７を管理している。
【０２６６】
なお、補助テーブルの作成方法やアクセス方法については、既に説明した方法と基本的な考えは同一であるため、上記と同様に説明を省略する。
【０２６７】
＜Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍのバリエーション＞
さらに、Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍとＳｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅとの関係について、図１９を用いて説明すれば以下の通りである。
【０２６８】
ここでは、約５サンプル毎に対応するＳｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅのエントリにアクセスできるように、Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅのエントリを生成している。
【０２６９】
Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅのｓｙｎｃ ｎｕｍは、約５サンプル単位で数字が増えている。ただし、５サンプルぴったりで区切れないため、５サンプルに一番近い情報が格納されている。Ｅｎｔｒｙ ｎｕｍには、対応するＳｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅのエントリ番号、ｐｒｅｖ ｓｙｎｃ ｎｕｍには１つ前のｓｙｎｃサンプルの番号を管理している。
【０２７０】
例えば、Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅの１エントリ目では、ｓｙｎｃ ｎｕｍには１、Ｓｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅのエントリ番号はｅｎｔｒｙ ｎｕｍ＝１、ｐｒｅｖ ｓｙｎｃ ｎｕｍの値は存在しないことを表すｎｕｌｌを管理している。また、２エントリ目では、ｓｙｎｃ ｎｕｍには６、Ｓｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅのエントリ番号はｅｎｔｒｙ ｎｕｍ＝４、ｐｒｅｖ ｓｙｎｃ ｎｕｍの値は４であることを管理している。
【０２７１】
なお、補助テーブルの作成方法やアクセス方法については、既に説明した方法と基本的な考えは同一であるため、上記と同様に説明を省略する。
【０２７２】
本実施形態のデータ管理方法では、図１７〜図１９に示すように、主の管理テーブルにアクセスするための補助アクセステーブルによる各エントリを極力等間隔になるように設定しているため、補助アクセステーブルのテーブルにアクセスする際に、先頭から順番にエントリをアクセスしなくても、おおよその見当をつけて目的のエントリにアクセスすることが可能となる。よって、より効率よく所望の情報の読み出しが可能になる。
【０２７３】
すなわち、例えば、１エントリ１０秒単位で管理しているとすれば、１００秒に対応するエントリにアクセスしたければ、１０エントリ目にアクセスすればよい。
【０２７４】
これにより、再生しようとする所望の情報に対応する管理情報を早急に探し出すことができ、再生開始までの所要時間を短縮することができる。
【０２７５】
＜整合の検出＞
主の管理情報テーブルは解釈でき、本実施形態における補助アクセステーブルを解釈できない実装が、編集処理を行うと主の管理テーブルと補助アクセステーブルとの整合が保てなくなり問題がある。不整合を検出するために、補助アクセステーブルＴｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍ、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍ、Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍのそれぞれに、日時を管理するフィールドを追加してもよい。このフィールドには、補助アクセステーブルを作成した時点でのＭｅｄｉａ ｈｅａｄｅｒａｔｏｍで管理する変更日時情報を格納するようにする。メディア情報に変更が発生すると、Ｍｅｄｉａ Ｈｅａｄｅｒ ａｔｏｍの変更日時情報が書き換わるため、補助アクセステーブルで管理する日時と一致しないことで、不整合を検出することが可能になる。
【０２７６】
あるいは、各補助アクセステーブルに、対応する主の管理テーブルのエントリ数を管理させてもよい。主の管理テーブルに新たな情報が追加されたり、削除された場合には、主の管理テーブルのエントリ数が変更されるため、補助アクセステーブルで管理するエントリ数と一致しないことで、不整合を検出することが可能になる。
＜Ｆｒａｇｍｅｎｔｅｄ ｍｏｖｉｅへの応用＞
録画中の電源遮断等に対応するために導入された概念であるＦｒａｇｍｅｎｔｅｄ Ｍｏｖｉｅは、管理情報を分散して管理することを可能とする仕組みである。この機能を用いた場合、Ｆｒａｇｍｅｎｔごとに管理情報を分散記録するが、このときのＦｒａｇｍｅｎｔの再生時間長に決まりはなく、Ｆｒａｇｍｅｎｔごとに可変であってもよい。このとき、Ｆｒａｇｍｅｎｔｅｄ Ｍｏｖｉｅファイルの先頭に配置される基本管理情報に、補助アクセステーブルを置く。この補助アクセステーブルでは、各Ｆｒａｇｍｅｎｔと累積再生時間とＦｒａｇｍｅｎｔの記録位置との対応を管理する。このような補助アクセステーブルを用意することによって、任意の時刻に対応するＦｒａｇｍｅｎｔを特定し、そのＦｒａｇｍｅｎｔの記録位置を瞬時に特定することが可能となる。なお、補助テーブルの作成方法やアクセス方法については、既に説明した方法と基本的な考えは同一であるため、上記と同様に説明を省略する。
【０２７７】
なお、本実施形態では、ＱｕｉｃｋＴｉｍｅファイルフォーマットを用いた管理方法について説明したが、本発明はこれに限定されるものではない。例えば、メディアデータにアクセスするための管理情報テーブルにおいて、基準となる時刻等、テーブル中の任意のエントリが何に対応するかを計算などで一意に求められないような構造のファイル等に対しても適用可能である。
【０２７８】
また、本発明のデータ管理方法は、複数のデータ毎の情報を管理する主の管理テーブルの各エントリが、情報の省略などによって一定の規則に従って構成されないデータ管理方法において、上記主の管理テーブルの各エントリに効率よくアクセスする補助管理テーブルを用意することを特徴とするデータ管理方法と表現することもできる。
【０２７９】
【発明の効果】
本発明のデータ管理方法は、以上のように、記録媒体から必要な情報を読み出す際には、上記主の管理テーブルに含まれる複数のエントリ分の累積情報を個々のエントリで管理する補助管理テーブルを用いる管理方法である。
【０２８０】
それゆえ、記録媒体の主の管理テーブルに格納された情報を再生する場合には、補助管理テーブルを介して直接的に所望の情報へアクセスし、該所望の情報を効率よく読み出すことで、再生指示を受けてから実際に再生が開始されるまでの時間を短縮できるという効果を奏する。
【０２８１】
上記補助管理テーブルが備えている各エントリは、上記主の管理テーブルの分割読み出しを行う複数のエントリ分の累積情報を管理していることがより好ましい。
【０２８２】
それゆえ、主の管理テーブルから分割読み出しする単位と、補助管理テーブルの１つのエントリに管理されている主の管理テーブルのエントリ数とを一致させることができるため、主の管理テーブルから再生を行う装置等のメモリに対して、さらに効率よく読み出しを行うことができるという効果を奏する。
【０２８３】
上記補助管理テーブルの各エントリは、上記累積情報が略等間隔で増加していくように、上記主の管理テーブルのエントリ数を区切って形成されていることがより好ましい。
【０２８４】
それゆえ、補助管理テーブルにおける１エントリの間隔をできる限り等間隔になるように設定することで、おおよその見当をつけて所望の情報が含まれるエントリに対してアクセスすることができる。よって、所望の情報が含まれるエントリにより効率よくアクセスすることができ、再生開始までに要する時間をより短縮できるという効果を奏する。
【０２８５】
上記主の管理テーブルが分割読み出しの対象となっており、かつ該分割読み出しを行うエントリに対応する補助管理テーブルが存在しない場合には、補助管理テーブルを生成することがより好ましい。
【０２８６】
それゆえ、分割読み出しを行う主の管理テーブルのエントリに対応する補助管理テーブルが存在していない場合に補助管理テーブルを作成することで、補助管理テーブルの作成を必要最小限にでき、記録する情報量の増大を抑制できるという効果を奏する。
【０２８７】
上記主の管理テーブルは、ＱｕｉｃｋＴｉｍｅファイルフォーマットであることがより好ましい。
【０２８８】
それゆえ、ビデオデータやオーディオデータ等のメディアデータと管理情報とを備えているＱｕｉｃｋＴｉｍｅファイルフォーマットのうち、管理情報について補助管理テーブルを形成し、該補助管理テーブルを介して所望の情報を含むエントリにアクセスすることで、効率よく所望の情報を取得できるという効果を奏する。
【０２８９】
上記補助管理テーブルは、時間に関する累積情報を管理していることがより好ましい。
【０２９０】
それゆえ、任意の時間から再生を開始する、いわゆるランダムアクセスを行う場合でも、主の管理テーブルのエントリに１つずつアクセスして所望の情報を探し出す必要はなく、補助管理テーブルの各エントリに管理されている累積時間情報の中から上記任意の時間が含まれるエントリにアクセスすることで、直接的に所望の情報を取得できるという効果を奏する。
【０２９１】
上記補助管理テーブルは、サンプルおよびチャンクに関する累積情報を管理していることがより好ましい。
【０２９２】
それゆえ、任意のサンプル番号に対応するチャンク情報を取得する場合において、補助管理テーブルの各エントリに管理されている累積サンプル情報の中から、所望のサンプルが含まれるエントリを選択してアクセスすることで、直接的に所望の情報を取得できるという効果を奏する。
【０２９３】
上記補助管理テーブルは、単独でデコード可能なサンプルに関する情報を管理していることがより好ましい。
【０２９４】
それゆえ、任意のサンプルが単独でデコードできるか否かについて調べる場合において、補助管理テーブルの各エントリに管理されている累積情報の中から、所望のサンプルが含まれるエントリを選択してアクセスすることで、直接的に所望のデコード可能なサンプル情報を取得できるという効果を奏する。
【０２９５】
本発明のデータ管理装置は、以上のように、記録媒体から必要な情報を読み出す際には、上記主の管理テーブルに含まれる複数のエントリ分の累積情報を個々のエントリで管理する補助管理テーブルを用いる構成である。
【０２９６】
それゆえ、記録媒体の主の管理テーブルに格納された情報を再生する場合には、補助管理テーブルを介して直接的に所望の情報へアクセスし、該所望の情報を効率よく読み出すことで、再生指示を受けてから実際に再生が開始されるまでの時間を短縮できるという効果を奏する。
【０２９７】
上記補助管理テーブルが備えている各エントリは、上記主の管理テーブルの分割読み出しを行う複数のエントリ分の累積情報を管理していることがより好ましい。
【０２９８】
それゆえ、主の管理テーブルから分割読み出しする単位と、補助管理テーブルの１つのエントリに管理されている主の管理テーブルのエントリ数とを一致させることができるため、主の管理テーブルから再生機器等のメモリに対して、さらに効率よく情報の読み出しを行うことができるという効果を奏する。
【０２９９】
上記補助管理テーブルの各エントリは、上記累積情報が略等間隔で増加していくように、上記主の管理テーブルのエントリ数を区切って形成されていることがより好ましい。
【０３００】
それゆえ、補助管理テーブルにおける１エントリの間隔をできる限り等間隔になるように設定することで、おおよその見当をつけて所望の情報が含まれるエントリに対してアクセスすることができる。よって、より効率よく、所望の情報が含まれるエントリにアクセスすることができ、再生開始までに要する時間を短縮できるという効果を奏する。
【０３０１】
上記主の管理テーブルが分割読み出しの対象となっており、かつ該分割読み出しを行うエントリに対応する補助管理テーブルが存在しない場合には、補助管理テーブルを生成することがより好ましい。
【０３０２】
それゆえ、分割読み出しを行う主の管理テーブルのエントリに対応する補助管理テーブルが存在していない場合に補助管理テーブルを作成することで、補助管理テーブルの作成を必要最小限にでき、情報量の増大を抑制できるという効果を奏する。
【０３０３】
上記主の管理テーブルは、ＱｕｉｃｋＴｉｍｅファイルフォーマットであることがより好ましい。
【０３０４】
それゆえ、ビデオデータやオーディオデータ等のメディアデータと管理情報とを備えているＱｕｉｃｋＴｉｍｅファイルフォーマットのうち、管理情報について補助管理テーブルを形成し、該補助管理テーブルを介して所望の情報を含むエントリにアクセスすることで、効率よく所望の情報を取得できるという効果を奏する。
【０３０５】
本発明のデータ管理プログラムは、以上のように、上記データ管理方法を、コンピュータに実行させる構成である。
【０３０６】
それゆえ、本発明のデータ管理プログラムをコンピュータに実行させることにより、記録媒体の主の管理テーブルに格納された情報を再生する際に、補助管理テーブルを介して直接的に所望の情報へアクセスし、該所望の情報を効率よく読み出すことで、再生指示を受けてから実際に再生が開始されるまでの時間を短縮できるという効果を奏する。
【０３０７】
本発明のデータ管理プログラムを記録した記録媒体は、以上のように、上記データ管理プログラムを記録した構成である。
【０３０８】
それゆえ、本発明の記録媒体をコンピュータに読み取らせることにより、記録媒体の主の管理テーブルに格納された情報を再生する際に、補助管理テーブルを介して直接的に所望の情報へアクセスし、該所望の情報を効率よく読み出すことで、再生指示を受けてから実際に再生が開始されるまでの時間を短縮できるという効果を奏する。
【図面の簡単な説明】
【図１】ＱｕｉｃｋＴｉｍｅファイルにおける、Ａｃｃｅｓｓ ｔａｂｌｅ ａｔｏｍの配置位置を示す図である。
【図２】Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍの構造を示す図である。
【図３】３エントリずつテーブルを読み出す場合のＴｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅとＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅの関係を示す図である。
【図４】Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍの構造を示す図である。
【図５】３エントリずつテーブルを読み出す場合のＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ｔａｂｌｅとＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅとの関係を示す図である。
【図６】Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍの構造を示す図である。
【図７】３エントリずつテーブルを読み出す場合のＳｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅとＳｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅとの関係を示す図である。
【図８】補助アクセステーブルを利用した場合のデータの読み出す様子を示す図である。
【図９】ＱｕｉｃｋＴｉｍｅファイルの管理情報を読み込む処理の流れを示す図である。
【図１０】分割読み出し対象のａｔｏｍの管理情報を読み出す際の詳細な処理の流れを示す図である。
【図１１】Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍにおいて、管理情報の分割読み出しを行う処理の流れを示す図である。
【図１２】Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｔｏｍにおいて、管理情報を分割読み出しを行う処理の流れを示す図である。
【図１３】Ｓｙｎｃ ｓａｍｐｌｅ ａｔｏｍにおいて、管理情報を分割読み出しを行う処理の流れを示す図である。
【図１４】Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍにおいて、サンプル情報を取得する処理の流れを示す図である。
【図１５】Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｔｏｍにおいて、サンプル情報を取得する処理の流れを示す図である。
【図１６】Ｓｙｎｃ ｓａｍｐｌｅ ａｔｏｍにおいて、サンプル情報を取得する処理の流れを示す図である。
【図１７】５００ｔｉｍｅ ｕｎｉｔ単位で補助アクセステーブルを生成する場合のＴｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅとＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅとの関係を示す図である。
【図１８】５サンプル単位で補助アクセステーブルを生成する場合のＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ｔａｂｌｅとＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅの関係を示す図である。
【図１９】５サンプル単位で補助アクセステーブルを生成する場合のＳｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓｔａｂｌｅとＳｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅの関係を示す図である。
【図２０】従来のＱｕｉｃｋＴｉｍｅファイルの構造を示す図である。
【図２１】従来のＳａｍｐｌｅ ｔａｂｌｅ ａｔｏｍの構造を示す図である。
【図２２】従来のサンプルとチャンク構造の例を示す図である。
【図２３】従来のＴｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍの構造を示す図である。
【図２４】従来のＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅの例を示す図である。
【図２５】従来のＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｔｏｍの構造を示す図である。
【図２６】従来のＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅの例を示す図である。
【図２７】従来のＳｙｎｃ Ｓａｍｐｌｅ ａｔｏｍの構造を示す図である。
【図２８】従来のＳｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅの構造を示す図である。
【図２９】従来のＳａｍｐｌｅ ｓｉｚｅ ａｔｏｍの構造を示す図である。
【図３０】従来のＳａｍｐｌｅ ｓｉｚｅ ｔａｂｌｅの例を示す図である。
【図３１】従来のＣｈｕｎｋ ｏｆｆｓｅｔ ａｔｏｍの構造を示す図である。
【図３２】従来のＣｈｕｎｋ ｏｆｆｓｅｔ ｔａｂｌｅの例を示す図である。
【図３３】従来のサンプルとチャンク構造の例を示す図である。
【図３４】従来のサンプル情報を取得する際の処理の流れを示す図である。
【図３５】従来の管理情報の分割読み出し処理の様子を示す図である。
【符号の説明】
１００ Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍ
１０１ Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｔｏｍ
１０２ Ｓａｍｐｌｅ ｓｉｚｅ ａｔｏｍ
１０３ Ｓｙｎｃ ｓａｍｐｌｅ ａｔｏｍ
１０４ Ｃｈｕｎｋ ｏｆｆｓｅｔ ａｔｏｍ
【発明の属する技術分野】
本発明は、例えば、ＱｕｉｃｋＴｉｍｅ（登録商標）ファイルに記録された情報に対して、ランダムアクセスにより再生を行う場合でも、効率よく管理情報の読み出しを行うことができるデータ管理方法およびデータ管理装置、データ管理プログラムならびにこれを記録した記録媒体に関するものである。
【０００２】
【従来の技術】
オーディオやビデオ等の複数のマルチメディアデータを同期して再生するための管理方法として、ＰＣ（パーソナルコンピュータ）やデジカメなどにおいて、広くＱｕｉｃｋＴｉｍｅ（登録商標）ファイルフォーマットが利用されている（特許文献１・２を参照）。
【０００３】
ＱｕｉｃｋＴｉｍｅファイルフォーマットとは、Ａｐｐｌｅ社が開発したマルチメディアデータ管理用フォーマットであり、ＰＣの世界で広く用いられている。また、ＱｕｉｃｋＴｉｍｅファイルフォーマットをベースとして、ＭＰＥＧ４やＭｏｔｉｏｎ ＪＰＥＧ２０００などで採用されているファイルフォーマットであるＩＳＯ ｂａｓｅ ｍｅｄｉａ ｆｉｌｅ ｆｏｒｍａｔが規格化されている。
【０００４】
ＱｕｉｃｋＴｉｍｅファイルフォーマットは、ビデオデータやオーディオデータ等（これらを総称してメディアデータという）と管理情報とで構成される。ここでは、この両者を合わせて「ＱｕｉｃｋＴｉｍｅムービー」と称する。なお、このマルチメディアデータと管理情報とは、同じファイル中に存在しても、別々のファイルに存在してもよい。
【０００５】
例えば、管理情報とマルチメディアデータとを同じファイル中に格納した場合には、図２０に示すように、各種情報はａｔｏｍという共通の構造に格納される。具体的には、管理情報はＭｏｖｉｅ ａｔｏｍという構造に格納され、メディアデータはＭｏｖｉｅ ｄａｔａ ａｔｏｍという構造に格納される。
【０００６】
なお、Ｍｏｖｉｅ ａｔｏｍ中の管理情報には、メディアデータ中の任意の時間に対応するメディアデータのファイル中での相対位置を導くためのテーブルや、メディアデータの属性情報や、後述する外部参照情報等が含まれている。
【０００７】
一方、管理情報とメディアデータとを別々のファイルに格納した場合には、管理情報はＭｏｖｉｅ ａｔｏｍという構造に格納されるが、メディアデータはａｔｏｍに格納される必要はない。この場合、Ｍｏｖｉｅ ａｔｏｍはメディアデータを格納したファイルを「外部参照」している、という。
【０００８】
この外部参照は、複数のＡＶストリームファイルに対して行うことが可能であり、この仕組みにより、ＡＶストリーム自体を物理的に移動させることなく、見かけ上編集を行ったように見せる、いわゆる「ノンリニア編集」や「非破壊編集」が可能になる。
【０００９】
ここで、図２０〜図３５を用いて、ＱｕｉｃｋＴｉｍｅファイルにおける管理情報が格納されている構造について説明する。
【００１０】
まず、共通の情報格納構造であるａｔｏｍについて説明する。
【００１１】
ａｔｏｍの先頭には、そのａｔｏｍのサイズであるＡｔｏｍ ｓｉｚｅ、そのａｔｏｍの種別情報であるＴｙｐｅが必ず存在する。Ｔｙｐｅは４文字で区別され、例えば、Ｍｏｖｉｅ ａｔｏｍでは’ｍｏｏｖ’、Ｍｏｖｉｅ ｄａｔａ ａｔｏｍでは’ｍｄａｔ’となっている。
【００１２】
ここで、ａｔｏｍの先頭にあるＡｔｏｍ ｓｉｚｅとＴｙｐｅとの列を、ａｔｏｍ ｈｅａｄｅｒと呼ぶことにすると、ＱｕｉｃｋＴｉｍｅムービーは、必ずこの複数のａｔｏｍ構造によって構成される。そして、注目しているａｔｏｍ ｈｅａｄｅｒの先頭からａｔｏｍ ｈｅａｄｅｒで管理されるａｔｏｍ ｓｉｚｅ（バイト数）だけ先に次のａｔｏｍが存在することになる。そして、各ａｔｏｍは別のａｔｏｍを含むことができ、ａｔｏｍ間に階層構造を形成することが可能である。
【００１３】
Ｍｏｖｉｅ ａｔｏｍはコンテナａｔｏｍであって、Ｍｏｖｉｅ ｈｅａｄｅｒ ａｔｏｍ、任意の数のＴｒａｃｋ ａｔｏｍ、Ｕｓｅｒ ｄｅｆｉｎｅｄ ｄａｔａ ａｔｏｍを備えている。なお、コンテナａｔｏｍとは、任意の数のａｔｏｍを格納するための入れ物的な役割を果たすものであり、コンテナａｔｏｍ自体は情報を管理しない。
【００１４】
Ｍｏｖｉｅ ｈｅａｄｅｒ ａｔｏｍは、そのＭｏｖｉｅ ａｔｏｍが管理するムービーの全体的な属性を管理する。
【００１５】
Ｔｒａｃｋ ａｔｏｍは、そのムービーに含まれるビデオやオーディオ等のトラックに関する情報を格納する。
【００１６】
Ｕｓｅｒ ｄｅｆｉｎｅｄ ｄａｔａ ａｔｏｍの中には、独自に定義可能なａｔｏｍを配置することが可能であって、ＱｕｉｃｋＴｉｍｅフォーマットで定義されてない独自情報を任意個数格納することができる。１個の独自情報は１個のエントリで管理され、１個のエントリはＳｉｚｅとＴｙｐｅとＵｓｅｒ ｄａｔａとで構成される。Ｓｉｚｅはそのエントリ自体のサイズを表し、Ｔｙｐｅは独自情報をそれぞれ区別するための識別情報、Ｕｓｅｒ ｄａｔａは実際のデータを表す。
【００１７】
さらに、上記Ｔｒａｃｋ ａｔｏｍはコンテナａｔｏｍであり、Ｔｒａｃｋ Ｈｅａｄｅｒ ａｔｏｍ、Ｅｄｉｔ ａｔｏｍ、Ｍｅｄｉａ ａｔｏｍ、Ｕｓｅｒ ｄｅｆｉｎｅｄ ｄａｔａ ａｔｏｍを備えている。一般的に、ＱｕｉｃｋＴｉｍｅムービーにおいては、オーディオおよびビデオの２つのトラックが存在することが多いが、字幕を表示するテキストトラックや、複数のオーディオやビデオ等、任意の数のトラックを管理することが可能である。
【００１８】
Ｔｒａｃｋ ｈｅａｄｅｒ ａｔｏｍは、そのトラックの全体的な属性を管理する。
【００１９】
Ｅｄｉｔ ａｔｏｍは、メディアデータのどの区間を、ムービーのどのタイミングで再生するかを管理する。
【００２０】
Ｍｅｄｉａ ａｔｏｍは、実際のビデオやオーディオといったデータを管理する。さらに、このＭｅｄｉａ ａｔｏｍはコンテナａｔｏｍであり、Ｍｅｄｉａ ｈｅａｄｅｒ ａｔｏｍ、Ｈａｎｄｌｅｒ ｒｅｆｅｒｅｎｃｅ ａｔｏｍ、（Ｖｉｄｅｏ／Ａｕｄｉｏ） Ｍｅｄｉａ Ｉｎｆｏｒｍａｔｉｏｎ ａｔｏｍ、Ｕｓｅｒ Ｄｅｆｉｎｅｄ ｄａｔａ ａｔｏｍを備えている。
【００２１】
Ｍｅｄｉａ ｈｅａｄｅｒ ａｔｏｍは、そのＭｅｄｉａ ａｔｏｍが管理するメディアデータに関する全体的な属性等を管理する。
【００２２】
Ｈａｎｄｌｅｒ ｒｅｆｅｒｅｎｃｅ ａｔｏｍは、メディアデータをどのデコーダでデコードするかを示す情報を格納する。
【００２３】
Ｍｅｄｉａ ｉｎｆｏｒｍａｔｉｏｎ ａｔｏｍは、ビデオやオーディオ等のメディア固有の属性情報を管理する。さらに、このＭｅｄｉａ ｉｎｆｏｒｍａｔｉｏｎ ａｔｏｍはコンテナａｔｏｍであって、Ｍｅｄｉａ Ｉｎｆｏｒｍａｔｉｏｎ Ｈｅａｄｅｒ ａｔｏｍ、Ｈａｎｄｌｅｒ Ｒｅｆｅｒｅｎｃｅ ａｔｏｍ、Ｄａｔａ Ｒｅｆｅｒｅｎｃｅ ａｔｏｍ、Ｓａｍｐｌｅ ｔａｂｌｅ ａｔｏｍを備えている。
【００２４】
Ｍｅｄｉａ ｉｎｆｏｒｍａｔｉｏｎ ｈｅａｄｅｒ ａｔｏｍは、ビデオやオーディオ等メディア固有の属性情報を管理する。
【００２５】
Ｈａｎｄｌｅｒ ｒｅｆｅｒｅｎｃｅ ａｔｏｍは、Ｍｅｄｉａ ａｔｏｍの項で説明した通りである。
【００２６】
Ｄａｔａ ｉｎｆｏｒｍａｔｉｏｎ ａｔｏｍは、そのＱｕｉｃｋＴｉｍｅムービーが参照するメディアデータを含むファイルの名前を管理するａｔｏｍであるＤａｔａ ｒｅｆｅｒｅｎｃｅ ａｔｏｍを含んでいる。
【００２７】
Ｓａｍｐｌｅ ｔａｂｌｅ ａｔｏｍは、データのサイズや再生時間等を管理している。
【００２８】
次に、このＳａｍｐｌｅ ｔａｂｌｅ ａｔｏｍについて、図２１を用いて説明するが、その前に、ＱｕｉｃｋＴｉｍｅにおけるデータの管理方法について、図２２を用いて説明する。
【００２９】
ＱｕｉｃｋＴｉｍｅにおいて、データの最小単位（例えば、ビデオフレーム）はサンプルと呼ばれる。個々のトラック毎に、サンプルには再生時間順に１から始まる連続した番号（サンプル番号）が付されている。
【００３０】
また、同一トラックに属するサンプルが再生時間順にファイル中で連続的に配置された領域をチャンクと呼ぶ。チャンクにも再生時間順に、１から始まる連続した番号（チャンク番号）が付されている。
【００３１】
このように、ＱｕｉｃｋＴｉｍｅにおいては、サンプル番号とチャンク番号とを付して、データ管理を行っている。
【００３２】
Ｓａｍｐｌｅ ｔａｂｌｅ ａｔｏｍは、個々のサンプルの再生時間長およびデータサイズ、個々のチャンクのファイル先頭からのアドレスおよび個々のチャンクが含むサンプル数などを管理しており、これらの情報に基づいて、任意の時間に対応するサンプルの情報を求めることが可能となっている。
【００３３】
Ｓａｍｐｌｅ ｔａｂｌｅ ａｔｏｍは、図２１に示すように、Ｓａｍｐｌｅ ｄｅｓｃｒｉｐｔｉｏｎ ａｔｏｍ、Ｔｉｍｅｔｏ ｓａｍｐｌｅ ａｔｏｍ、Ｓｙｎｃ ｓａｍｐｌｅ ａｔｏｍ、Ｓａｍｐｌｅ−ｔｏ−ｃｈｕｎｋ ａｔｏｍ、Ｓａｍｐｌｅ ｓｉｚｅ ａｔｏｍおよびＣｈｕｎｋ ｏｆｆｓｅｔ ａｔｏｍを備えている。
【００３４】
Ｓａｍｐｌｅ ｄｅｓｃｒｉｐｔｉｏｎ ａｔｏｍは、個々のチャンクのデータフォーマット（Ｄａｔａ ｆｏｒｍａｔ）やサンプルが格納されているファイルのＩｎｄｅｘ番号等を管理する。
【００３５】
Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍは、図２３に示すように、個々のサンプルの再生時間長を管理する。なお、ここでは、各サンプルの再生時間長を全て管理するとデータ量が膨大になるため、再生時間長が同じＳａｍｐｌｅが続いた場合には、その繰り返し数を管理することによって情報量を圧縮している。
【００３６】
Ｓａｍｐｌｅ−ｃｏｕｎｔでは、同じ再生時間が繰り返されるサンプルの数が管理され、Ｓａｍｐｌｅ−ｄｅｌｔａでは、繰り返されるｓａｍｐｌｅの再生時間長が管理される。
【００３７】
図２２に示したサンプル構造の例に対応するＳａｍｐｌｅ−ｃｏｕｎｔとＳａｍｐｌｅ−ｄｅｌｔａのテーブル（Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅ）は、図２４に示すように、１つ目のエントリではｓａｍｐｌｅ−ｃｏｕｎｔが２、ｓａｍｐｌｅ−ｄｅｌｔａが１００となっており、再生時間長が１００のサンプルが２個並んでいることがわかる。２つ目のエントリでは、ｓａｍｐｌｅ−ｃｏｕｎｔが１、ｓａｍｐｌｅ−ｄｅｌｔａが９５になっており、再生時間長が９５のサンプルが１回だけ続いていることを表している。なお、図２２における数字は、各サンプルの再生時間長を示すものである。
【００３８】
Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｔｏｍは、図２５に示すように、個々のチャンクに含まれるサンプル数を管理する。なお、ここでも、各チャンクに含まれるサンプル数を全て管理していたのではデータ量が膨大になるため、チャンクに含まれる同じサンプル数が続いた場合に、その繰り返し数を管理することによって情報量を圧縮している。
【００３９】
Ｆｉｒｓｔ ｃｈｕｎｋにはチャンク内のサンプル数が繰り返される先頭のチャンク番号、ｓａｍｐｌｅｓ−ｐｅｒ−ｃｈｕｎｋにはチャンク中のサンプル数、Ｓａｍｐｌｅ−ｄｅｓｃｒｉｐｔｉｏｎ−ｉｎｄｅｘには注目しているチャンクが対応するＳａｍｐｌｅ ｄｅｓｃｒｉｐｔｉｏｎ情報のインデックス番号がそれぞれ示される。
【００４０】
図２２に示したチャンク構造の例に対応するＦｉｒｓｔ Ｃｈｕｎｋ、Ｓａｍｐｌｅ ｐｅｒ ｃｈｕｎｋ、Ｓａｍｐｌｅ−ｄｅｓｃｒｉｐｔｉｏｎ−ｉｎｄｅｘのテーブル（Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅ）は、図２６に示すように、例えば、３つ目のエントリにおいては、Ｆｉｒｓｔ ｃｈｕｎｋには３、Ｓａｍｐｌｅ−ｐｅｒ−ｃｈｕｎｋには２、Ｓａｍｐｌｅ−ｄｅｓｃｒｉｐｔｉｏｎ−ｉｎｄｅｘには１がセットされている。
【００４１】
また、次の４つ目のエントリにおいては、それぞれ、６，３，１がセットされている。これにより、チャンク番号３からチャンク番号５までのチャンクは、サンプル数２で構成されていることがわかる。
【００４２】
Ｓｙｎｃ ｓａｍｐｌｅ ａｔｏｍは、図２７に示すように、個々のサンプルのうち、単独でデコード可能なサンプルを管理する。そして、Ｓａｍｐｌｅ−ｎｕｍｂｅｒは、単独でデコード可能なサンプル番号を管理する。
【００４３】
図２２に示したサンプル構造の例に対応するＳａｍｐｌｅ ｎｕｍｂｅｒのテーブル（Ｓｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅ）は、図２８に示すように、サンプル１，３，４，６，８，・・・が単独でデコード可能なサンプルであることがわかる。なお、図２２に示す★印が付されたサンプルが単独でデコード可能なサンプルを示している。
【００４４】
Ｓａｍｐｌｅ ｓｉｚｅ ａｔｏｍは、図２９に示すように、個々のサンプルのサイズを管理する。なお、トラック中の全サンプルが同一のサイズの場合には、ｓａｍｐｌｅ−ｓｉｚｅフィールドにそのデータサイズを記録することによって、テーブルを作成する必要はない。よって、各サンプルのデータサイズを示すＳａｍｐｌｅ−ｓｉｚｅテーブル（Ｓａｍｐｌｅ ｓｉｚｅ ｔａｂｌｅ）は、例えば、図３０に示すように、このａｔｏｍでは、全てのサンプルのデータサイズが同一の場合を除いて、トラック中の全サンプルのデータサイズをそれぞれテーブルの１エントリとして管理している。
【００４５】
Ｃｈｕｎｋ ｏｆｆｓｅｔ ａｔｏｍは、図３１に示すように、個々のチャンクのファイル先頭からのアドレスを管理する。
【００４６】
各チャンクのファイルの先頭からのアドレスを示すＣｈｕｎｋ ｏｆｆｓｅｔテーブル（Ｃｈｕｎｋ ｏｆｆｓｅｔ ｔａｂｌｅ）は、例えば、図３２に示すように、このａｔｏｍでは、トラック中の全チャンクのアドレスをそれぞれテーブルの１エントリとして管理している。
【００４７】
ここで、図３３に示すようなサンプル、チャンク構成を有するＱｕｉｃｋＴｉｍｅムービーにおいて、ムービーの先頭を時刻０とした場合に、再生時刻１．Ｔｉｍｅを与えたときに再生するために読み出すべきサンプル情報の取得方法について説明する。なお、図３３においては、再生時刻１．Ｔｉｍｅに相当するサンプルは、２．Ｓａｍｐｌｅ ＃ｎであり、このサンプルは３．Ｃｈｕｎｋ ＃ｍに含まれているものとする。
サンプル情報は、上述したＳａｍｐｌｅ Ｔａｂｌｅ ａｔｏｍ内で定義される各ａｔｏｍの情報を組み合わせて取得される。ここで、各ａｔｏｍを利用したサンプル情報を取得する処理の流れについて、図３４を用いて説明する。
【００４８】
＜サンプルの再生時間長の取得＞
まず、サンプルの再生時間長を取得するために、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍ１００において、再生時刻からその時刻に再生すべきサンプルのサンプル番号（２．ｓａｍｐｌｅ ＃ｎ）と、そのサンプルの再生時間長（９．ｄｕｒａｔｉｏｎ）とを取得する。
＜サンプルのデータサイズの取得＞
次に、サンプルのデータサイズを取得するために、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍ１００によって取得したサンプル番号（２．ｓａｍｐｌｅ ＃ｎ）から、Ｓａｍｐｌｅ ｓｉｚｅ ａｔｏｍ１０２より目的のサンプルのデータサイズ（６．ｓａｍｐｌｅ ｓｉｚｅ ＃ｋ）を取得する。
＜サンプルが単独でデコード可能か否か＞
次に、サンプルが単独でデコード可能か否かを示す情報を取得するために、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍ１００によって取得したサンプル番号（２．ｓａｍｐｌｅ ＃ｎ）から、Ｓｙｎｃ ｓａｍｐｌｅ ａｔｏｍ１０３より指定したサンプルが単独でデコード可能かどうか（Ｓｙｎｃ Ｓａｍｐｌｅかどうか）（１０．Ｓｙｎｃ Ｓａｍｐｌｅ ｏｒ Ｎｏｔ）を取得する。
【００４９】
＜サンプルのアドレス取得＞
次に、サンプルのアドレスを取得するために、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍ１００によって取得したサンプル番号（２．ｓａｍｐｌｅ ＃ｎ）から、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｔｏｍ１０１よりサンプルを含むチャンクのチャンク番号（３．Ｃｈｕｎｋ ＃ｍ）とチャンクの先頭のサンプル番号（Ｓａｍｐｌｅ ＃ｎ−２）、チャンク中のサンプルがどのようなメディア種別なのかを管理するテーブルのインデックス番号を管理する１１．Ｓａｍｐｌｅ Ｄｅｓｃｒｉｐｔｉｏｎ ｉｎｄｅｘを取得する。
【００５０】
取得したチャンク番号（３．Ｃｈｕｎｋ ＃ｍ）より、Ｃｈｕｎｋ ｏｆｆｓｅｔ ａｔｏｍ１０４を用いて注目しているチャンクの先頭アドレス（７．Ｃｈｕｎｋ ｏｆｆｓｅｔ ＃ｊ）を取得する。そして、チャンクの先頭アドレスに、チャンクの先頭のサンプルから目的のサンプルまでのサイズを足し合わせて、目的のサンプルのアドレスを取得する。つまり、取得した７．Ｃｈｕｎｋ ｏｆｆｓｅｔ ＃ｊにｓａｍｐｌｅ ＃ｎ−２、Ｓａｍｐｌｅ ＃ｎ−１のサイズを足し合わせ、８．Ｓａｍｐｌｅ ａｄｄｒｅｓｓを取得する。なお、Ｓａｍｐｌｅ ＃ｎ−２およびＳａｍｐｌｅ ＃ｎ−１のサイズは、上述した＜サンプルのデータサイズの取得＞により取得したものを用いることができる。
【００５１】
このように、ＱｕｉｃｋＴｉｍｅにおいては、ＱｕｉｃｋＴｉｍｅムービーを再生するために必要なサンプル情報を、複数の管理テーブルの情報を組み合わせることで取得することができる。
【００５２】
【特許文献１】
特開２００１−１７６１９５号公報（２００１年６月２９日公開）
【００５３】
【特許文献２】
特開２００２−２４７４８８号公報（２００２年８月３０日公開）
【００５４】
【発明が解決しようとする課題】
しかしながら、上記従来のデータ管理方法では、以下に示すような問題点を有している。
【００５５】
すなわち、従来、マルチメディアデータは、メモリ資源やＣＰＵパワーの豊富なＰＣにおいて取り扱うことが一般的であった。しかし、近年では、メモリ資源やＣＰＵパワーに制限のある、ＰＤＡ（パーソナルデジタルアシスタント）、ディスクビデオレコーダ、カムコーダと言ったＡＶ機器、携帯電話などの民生用機器でもマルチメディアデータを取り扱うようになってきている。
【００５６】
また、ＱｕｉｃｋＴｉｍｅファイルフォーマットは、広く普及している管理方式であるため、様々なプラットフォームにおいて利用されている。
【００５７】
ＱｕｉｃｋＴｉｍｅムービーを記録する記録媒体に関しても記録容量が増大しており、長時間の記録が可能となっている。上述したように、ＱｕｉｃｋＴｉｍｅでは再生に必要なサンプル情報は、Ｓａｍｐｌｅ Ｔａｂｌｅ ａｔｏｍによって管理されているが、記録時間が長くなると、これに比例してＳａｍｐｌｅ Ｔａｂｌｅ ａｔｏｍのデータ量は増加する。
【００５８】
これに対して、メモリ資源等が限られている民生用機器においては、例えば、記録再生できるＱｕｉｃｋＴｉｍｅムービーの時間長の上限を設けるなどの運用規定を設けることが一般的である。このような場合でも、メモリを増やす、再生に必要な管理情報を逐次記録媒体からメモリに読み出す等して、想定している時間以上のＱｕｉｃｋＴｉｍｅムービーを再生可能とすることは可能である。
【００５９】
しかし、メモリの増設は、コストが増える上、記録時間によっては確実に対応できるものではない。一方、記録媒体からメモリへの読み出しについては、メモリには管理情報の一部分しか格納できないため、再生を継続するために再生途中で記録媒体からメモリに管理情報をロードする必要がある。
【００６０】
例えば、ムービーの先頭から順番に再生を開始する場合には、再生するのに必要な管理情報が無くなった段階で、続きの情報をメモリに読み込むことによって再生を継続することができる。しかし、ムービーの任意時間から再生開始を行うようなランダムアクセスを行う場合には、上述したＳａｍｐｌｅ Ｔａｂｌｅ ａｔｏｍ以下の各ａｔｏｍの内容を組み合わせて情報を取得する必要がある。
【００６１】
このとき、Ｓａｍｐｌｅ Ｓｉｚｅ ａｔｏｍに関しては、テーブルの１エントリ＝１サンプルサイズ、Ｃｈｕｎｋ Ｏｆｆｓｅｔ ａｔｏｍに関しては、テーブルの１エントリ＝１チャンクオフセットと１対１の関係になっているため、任意の情報を取得する場合に、どこを読み出せば良いか明確であり、問題は生じない。
【００６２】
しかし、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍ、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｔｏｍ、Ｓｙｎｃ Ｓａｍｐｌｅ ａｔｏｍに関しては、管理情報量を圧縮するために、サンプルの再生時間長の繰り返しやチャンク中のサンプル数の繰り返しを省略している。また、Ｓｙｎｃ Ｓａｍｐｌｅ ａｔｏｍに関しては、単独でデコード可能なサンプル番号のリストを管理している。
【００６３】
このため、このようなデータ管理装置における任意の情報にアクセスするためには、管理テーブルの先頭から順番に見ていかなければ目的の情報がどのエントリなのかを把握することができない。
【００６４】
例えば、図３５に示すように、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍ中の網掛け部分にある情報を取得する場合を例にあげて説明すれば、以下の通りである。なお、図３５のＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅ中の１つの四角は、１回のアクセスでメモリに読み込める量であることを示している。
【００６５】
ここでは、管理情報が全てメモリに存在する場合には、テーブルの先頭から順次情報を読み出しても、毎回計算を行わなければならないということ以外に、特に大きな問題はない。しかし、管理情報が全てメモリに存在しない場合には、図３５に示すように、テーブルの先頭から順番に目的の情報にたどり着くまでに何回も、記録媒体からメモリ上に管理情報を分割して読み出す必要がある。
【００６６】
図３５に示す例では、テーブルの先頭から５回の読み出しを経て、目的の情報をメモリに格納している。このように、任意時間から再生を開始する場合には、ランダムアクセスを行うための情報を取得するまでに、記録媒体に記録されたＱｕｉｃｋＴｉｍｅファイルから何回も管理情報を読み出してからでないと再生を開始できない。
【００６７】
実際に、このような処理を行う必要があるのは、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍ、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｔｏｍ、Ｓｙｎｃ Ｓａｍｐｌｅ ａｔｏｍの３つのａｔｏｍに対してであって、それぞれのａｔｏｍについて同様の処理を行わなければならない。
【００６８】
このため、任意の時間から再生を開始する、いわゆるランダムアクセスを行う際には、このような処理を行う必要があり、再生指示を出してから、実際に絵や音が表示画面等から出力されてムービーの再生が開始されるまでにかなりの時間を要するため、ユーザを待たせることになり、好ましくない。
【００６９】
また、光ディスク等のシーク時間（アクセス時間）やデータの読み出しレートの遅い記録媒体から再生を行う場合には、上記の問題はより顕著に現れる。
【００７０】
そして、上述した任意の時間からの再生についてのみならず、逆再生や早送り、逆早送りなどの特殊再生を行う場合についても、この問題は同様に発生する。
【００７１】
さらに、録画中の電源遮断等に対応するために導入された概念であるＦｒａｇｍｅｎｔｅｄ ｍｏｖｉｅは、ＱｕｉｃｋＴｉｍｅ フォーマットの１アプリケーションであるＭｏｔｉｏｎ ＪＰＥＧ２０００で導入された概念であり、上述のＳａｍｐｌｅ ｔａｂｌｅ ａｔｏｍに相当する情報を、部分的なＡＶストリーム毎に管理することが可能である。つまり、Ｆｒａｇｍｅｎｔｅｄ Ｍｏｖｉｅは、管理情報を分散して管理することを可能とする仕組みである。
【００７２】
このため、Ｆｒａｇｍｅｎｔｅｄ Ｍｏｖｉｅについては、１つのムービーを複数のＦｒａｇｍｅｎｔに分割し、それぞれのＦｒａｇｍｅｎｔ毎に管理情報を持つため、Ｆｒａｇｍｅｎｔ単位のメディアデータとそれを管理する管理情報とは、ペアでムービーファイルに複数記録されることになる。よって、任意の時間に相当するサンプルが含まれるＦｒａｇｍｅｎｔを取得するためには、各Ｆｒａｇｍｅｎｔの管理情報を順番に見ていく必要があり、上記と同様の問題を有する。
【００７３】
本発明は、上記の問題点に鑑みなされたものであり、その目的は、ＱｕｉｃｋＴｉｍｅファイルフォーマット等で記録された情報に対するランダムアクセス時における再生開始までの時間を短縮して、効率よく管理情報の読み出しを行うことができるデータ管理方法およびデータ管理装置、データ管理プログラムならびにこれを記録した記録媒体を提供することにある。
【００７４】
【課題を解決するための手段】
本発明のデータ管理装置は、上記の課題を解決するために、複数のデータ毎の情報を管理する主の管理テーブルを用いて、該主の管理テーブルに含まれるエントリを一定の規則に従うことなく記録した記録媒体から、必要な情報の読み出しを行うデータ管理方法において、上記記録媒体から必要な情報を読み出す際には、上記主の管理テーブルに含まれる複数のエントリ分の累積情報を個々のエントリで管理する補助管理テーブルを用いることを特徴としている。
【００７５】
上記のデータ管理方法によれば、記録媒体の主の管理テーブルに格納された情報を再生する場合には、補助管理テーブルを介して直接的に所望の情報へアクセスし、該所望の情報を効率よく読み出すことで、再生指示を受けてから実際に再生が開始されるまでの時間を短縮できる。
【００７６】
すなわち、上記補助管理テーブルにおいては、主の管理テーブルのエントリを複数個ごとに区切り、該複数個ごとに区切られたエントリの累積情報を１個ずつのエントリで管理している。また、主の管理テーブルは、格納する情報量をできる限り小さくするために、情報の圧縮、繰り返しの情報を省略する等して管理しているため、一定の規則に従って格納されていない。
【００７７】
このため、主の管理テーブルに格納された情報について再生指示があった場合には、主の管理テーブルの所望の情報にアクセスするために、まず、この補助管理テーブルにおける、所望の情報が含まれる累積情報を管理するエントリにアクセスする。そして、当該補助管理テーブルのエントリに対応する主の管理テーブルのエントリを、再生を行う装置等のメモリに対して読み出している。
【００７８】
例えば、主の管理テーブルが時間に関する情報を管理するテーブルである場合には、補助管理テーブルにおいて累積時間情報が管理されているため、任意の時間から処理を開始する、いわゆるランダムアクセスを行う場合でも、この任意の時間が含まれる累積時間情報を有する補助管理テーブルのエントリにアクセスし、このエントリを介して主の管理テーブルの情報を取得する。
【００７９】
これにより、従来のように、主の管理テーブルが有する各テーブルの先頭から順番にアクセスして所望の情報を探し出す必要はなく、補助管理テーブルを介して効率的に所望の情報を取得することで、ユーザから再生指示を受けてから実際に再生が開始されるまでに要する時間を短縮することができる。
【００８０】
なお、本発明のデータ管理方法は、再生指示を受けた所望の情報が記録されている記録媒体が、シーク時間（アクセス時間）やデータの読み出しレートが遅いという特性を有する光ディスク等の記録媒体である場合に特に有効である。
【００８１】
上記補助管理テーブルが備えている各エントリは、上記主の管理テーブルの分割読み出しを行う複数のエントリ分の累積情報を管理していることがより好ましい。
【００８２】
これにより、主の管理テーブルから分割読み出しする単位と、補助管理テーブルの１つのエントリに管理されている主の管理テーブルのエントリ数とを一致させることができるため、主の管理テーブルから再生を行う装置等のメモリに対して、さらに効率よく読み出しを行うことができる。
【００８３】
上記補助管理テーブルの各エントリは、上記累積情報が略等間隔で増加していくように、上記主の管理テーブルのエントリ数を区切って形成されていることがより好ましい。
【００８４】
これにより、補助管理テーブルにおける１エントリの間隔をできる限り等間隔になるように設定することで、おおよその見当をつけて所望の情報が含まれるエントリに対してアクセスすることができる。
【００８５】
よって、所望の情報が含まれるエントリにより効率よくアクセスすることができ、再生開始までに要する時間をより短縮できる。
【００８６】
上記主の管理テーブルが分割読み出しの対象となっており、かつ該分割読み出しを行うエントリに対応する補助管理テーブルが存在しない場合には、補助管理テーブルを生成することがより好ましい。
【００８７】
これにより、分割読み出しを行う主の管理テーブルのエントリに対応する補助管理テーブルが存在していない場合に補助管理テーブルを作成することで、補助管理テーブルの作成を必要最小限にでき、記録する情報量の増大を抑制できる。
【００８８】
上記主の管理テーブルは、ＱｕｉｃｋＴｉｍｅファイルフォーマットであることがより好ましい。
【００８９】
これにより、ビデオデータやオーディオデータ等のメディアデータと管理情報とを備えているＱｕｉｃｋＴｉｍｅファイルフォーマットのうち、管理情報について補助管理テーブルを形成し、該補助管理テーブルを介して所望の情報を含むエントリにアクセスすることで、効率よく所望の情報を取得できる。
【００９０】
上記補助管理テーブルは、時間に関する累積情報を管理していることがより好ましい。
【００９１】
これにより、任意の時間から再生を開始する、いわゆるランダムアクセスを行う場合でも、主の管理テーブルのエントリに１つずつアクセスして所望の情報を探し出す必要はなく、補助管理テーブルの各エントリに管理されている累積時間情報の中から上記任意の時間が含まれるエントリにアクセスすることで、直接的に所望の情報を取得できる。
【００９２】
上記補助管理テーブルは、サンプルおよびチャンクに関する累積情報を管理していることがより好ましい。
【００９３】
これにより、任意のサンプル番号に対応するチャンク情報を取得する場合において、補助管理テーブルの各エントリに管理されている累積サンプル情報の中から、所望のサンプルが含まれるエントリを選択してアクセスすることで、直接的に所望の情報を取得できる。
【００９４】
なお、チャンクとは、同一トラックに記録されたデータの最小単位であるサンプルが、再生時間順にファイル中で連続的に配置された領域をいう。
【００９５】
上記補助管理テーブルは、単独でデコード可能なサンプルに関する情報を管理していることがより好ましい。
【００９６】
これにより、任意のサンプルが単独でデコードできるか否かについて調べる場合において、補助管理テーブルの各エントリに管理されている累積情報の中から、所望のサンプルが含まれるエントリを選択してアクセスすることで、直接的に所望のデコード可能なサンプル情報を取得できる。
【００９７】
本発明のデータ管理装置は、上記の課題を解決するために、複数のデータ毎の情報を管理する主の管理テーブルを用いて、該主の管理テーブルに含まれるエントリを一定の規則に従うことなく記録された記録媒体から、必要な情報の読み出しを行うデータ管理装置において、上記記録媒体から必要な情報を読み出す際には、上記主の管理テーブルに含まれる複数のエントリ分の累積情報を個々のエントリで管理する補助管理テーブルを用いることを特徴としている。
【００９８】
上記の構成によれば、記録媒体の主の管理テーブルに格納された情報を再生する場合には、補助管理テーブルを介して直接的に所望の情報へアクセスし、該所望の情報を効率よく読み出すことで、再生指示を受けてから実際に再生が開始されるまでの時間を短縮できる。
【００９９】
すなわち、上記補助管理テーブルにおいては、主の管理テーブルのエントリを複数個ごとに区切り、該複数個ごとに区切られたエントリの累積情報を１個ずつのエントリでそれぞれ管理している。また、主の管理テーブルは、格納する情報量をできる限り小さくするために、情報の圧縮、繰り返しの情報を省略して管理しており、一定の規則に従って格納されていない。
【０１００】
このため、主の管理テーブルに格納された情報について再生指示があった場合には、主の管理テーブルの所望の情報にアクセスするために、まず、この補助管理テーブルにおける、所望の情報が含まれる累積情報を管理するエントリにアクセスする。そして、当該補助管理テーブルのエントリに対応する主の管理テーブルのエントリを、再生を行う装置等のメモリに対して読み出している。
【０１０１】
例えば、主の管理テーブルが時間に関する情報を管理するテーブルである場合には、補助管理テーブルにおいて累積時間情報が管理されているため、任意の時間から処理を開始する、いわゆるランダムアクセスを行う場合でも、この任意の時間が含まれる累積時間情報を有する補助管理テーブルのエントリにアクセスし、このエントリを介して主の管理テーブルの情報を取得する。
【０１０２】
これにより、従来のように、主の管理テーブルが有する各テーブルの先頭から順番にアクセスして所望の情報を探し出す必要はなく、補助管理テーブルを介して効率的に所望の情報を取得することで、ユーザから再生指示を受けてから実際に再生が開始されるまでに要する時間を短縮することができる。
【０１０３】
なお、本発明のデータ管理装置は、再生指示を受けた所望の情報が記録されている記録媒体が、シーク時間（アクセス時間）やデータの読み出しレートが遅いという特性を有する光ディスク等の記録媒体である場合に特に有効である。
【０１０４】
上記補助管理テーブルが備えている各エントリは、上記主の管理テーブルの分割読み出しを行う複数のエントリ分の累積情報を管理していることがより好ましい。
【０１０５】
これにより、主の管理テーブルから分割読み出しする単位と、補助管理テーブルの１つのエントリに管理されている主の管理テーブルのエントリ数とを一致させることができるため、主の管理テーブルから再生機器等のメモリに対して、さらに効率よく情報の読み出しを行うことができる。
【０１０６】
上記補助管理テーブルの各エントリは、上記累積情報が略等間隔で増加していくように、上記主の管理テーブルのエントリ数を区切って形成されていることがより好ましい。
【０１０７】
これにより、補助管理テーブルにおける１エントリの間隔をできる限り等間隔になるように設定することで、おおよその見当をつけて所望の情報が含まれるエントリに対してアクセスすることができる。
【０１０８】
よって、より効率よく、所望の情報が含まれるエントリにアクセスすることができ、再生開始までに要する時間を短縮できる。
【０１０９】
上記主の管理テーブルが分割読み出しの対象となっており、かつ該分割読み出しを行うエントリに対応する補助管理テーブルが存在しない場合には、補助管理テーブルを生成することがより好ましい。
【０１１０】
これにより、分割読み出しを行う主の管理テーブルのエントリに対応する補助管理テーブルが存在していない場合に補助管理テーブルを作成することで、補助管理テーブルの作成を必要最小限にでき、情報量の増大を抑制できる。
【０１１１】
上記主の管理テーブルは、ＱｕｉｃｋＴｉｍｅファイルフォーマットであることがより好ましい。
【０１１２】
これにより、ビデオデータやオーディオデータ等のメディアデータと管理情報とを備えているＱｕｉｃｋＴｉｍｅファイルフォーマットのうち、管理情報について補助管理テーブルを形成し、該補助管理テーブルを介して所望の情報を含むエントリにアクセスすることで、効率よく所望の情報を取得できる。
【０１１３】
本発明のデータ管理プログラムは、上記の課題を解決するために、上記データ管理方法を、コンピュータに実行させることを特徴としている。
【０１１４】
上記のプログラムによれば、本発明のデータ管理プログラムをコンピュータに実行させることにより、記録媒体の主の管理テーブルに格納された情報を再生する際に、補助管理テーブルを介して直接的に所望の情報へアクセスし、該所望の情報を効率よく読み出すことで、再生指示を受けてから実際に再生が開始されるまでの時間を短縮できる。
【０１１５】
本発明のデータ管理プログラムを記録した記録媒体は、上記の課題を解決するために、上記データ管理プログラムを記録したことを特徴としている。
【０１１６】
上記の構成によれば、本発明の記録媒体をコンピュータに読み取らせることにより、記録媒体の主の管理テーブルに格納された情報を再生する際に、補助管理テーブルを介して直接的に所望の情報へアクセスし、該所望の情報を効率よく読み出すことで、再生指示を受けてから実際に再生が開始されるまでの時間を短縮できる。
【０１１７】
【発明の実施の形態】
本発明のデータ管理方法およびデータ管理装置、データ管理プログラムおよびこれを記録した記録媒体に係る一実施形態について、図１〜図１９を用いて詳しく説明すれば以下の通りである。
【０１１８】
本実施形態のデータ管理方法は、メモリ資源やＣＰＵ資源に制限のある民生用機器により、ＱｕｉｃｋＴｉｍｅファイルに長時間に渡って記録されたデータを効率的に再生可能とするものである。
【０１１９】
本実施形態のデータ管理方法では、図１に示すように、Ｔｒａｃｋ ａｔｏｍにおけるＵｓｅｒ ｄｅｆｉｎｅｄ ｄａｔａ ａｔｏｍの下位テーブルであるＡｃｃｅｓｓ Ｔａｂｌｅ ａｔｏｍの下位テーブルとして、複数の補助アクセステーブル（補助管理テーブル）（Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍ，Ｓａｍｐｌｅ ｔｏ Ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍ，Ｓｙｎｃ Ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍ）を備えている。
【０１２０】
これにより、これらの補助アクセステーブルを用いて、容易に所望の情報を見つけることができるため、全ての管理情報が機器内のメモリに格納できない場合であっても、任意の時間から再生を開始する際に、毎回管理テーブルの先頭から順次所望の情報を見つけるまで、繰り返し読み出しを行う必要がなく、再生指示を受けてから再生開始までに要する時間を短縮できる。
【０１２１】
ここで、本実施形態のデータ管理方法において形成される上記各補助アクセステーブル（Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍ，Ｓａｍｐｌｅ ｔｏ Ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍ，Ｓｙｎｃ Ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍ）の構造について説明する。
【０１２２】
＜Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍの構造＞
Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍに対応する補助アクセステーブルＴｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓａｔｏｍは、図２に示すような構造を有しており、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍのＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅにおける複数のエントリの累積情報を１つ１つのエントリで管理するものである。
【０１２３】
本実施形態のデータ管理方法においては、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのうち、一回のアクセスでメモリに格納できるテーブルのエントリ数を基準として、補助アクセステーブルを構築する。
【０１２４】
Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍは、ｅｎｔｒｙ ｃｏｕｎｔ数分のエントリで構成されるテーブルＴｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅを持つ。各エントリは、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍにおける累積情報を管理する範囲における最後のエントリ＋１を管理するｅｎｔｒｙ ｎｕｍ（範囲の先頭は常にエントリ番号１）、その範囲における先頭のサンプルからのサンプル数の累積合計を示すｃｏｕｎｔ、その範囲における先頭からのサンプルの再生累積時間長を管理するｄｅｌｔａを備えている。
【０１２５】
図３に、図２２に示したサンプル、チャンク構造に対応するＴｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍとＴｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍとのテーブル部分の内容を示す。なお、この例では、説明を簡略化するため、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅにおいて一度にメモリに格納できるエントリ数を３エントリと想定している。実際には、このエントリ数はメモリの大きさに依存し、例えば、１０００エントリといった数になる。
【０１２６】
Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅの１エントリ目では、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのエントリ１〜３までの累積情報を管理している。つまり、エントリ１においては、累積５サンプル、累積再生時間長４８０、次のＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのエントリが４であることを示す。
【０１２７】
同様に、エントリ２では、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのエントリ１〜６までの累積情報を管理する。つまり、エントリ２においては、累積１２サンプル、累積再生時間長１１３５、次のＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのエントリが７であることを示す。
【０１２８】
本実施形態のデータ管理方法では、以上のような構成の補助アクセステーブルＴｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍを用いることによって、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅのｄｅｌｔａのフィールドから目的の時間が含まれるエントリを探し出し、そのテーブルのエントリの情報からダイレクトにＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅの任意のエントリからの一連の情報をメモリに格納することで、任意の時間に対応するサンプル情報を取得できる。
【０１２９】
これにより、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍのテーブルの先頭から順番に情報を読み出す必要がなくなり、処理時間を大幅に短縮することが可能となる。
【０１３０】
＜Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍの構造＞
Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｔｏｍに対応する補助アクセステーブルＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍは、図４に示すような構造を有しており、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｔｏｍにおけるテーブルの複数エントリの累積情報を１つのエントリで管理するものである。
【０１３１】
本実施形態では、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅを一回のアクセスでメモリに格納できるテーブルのエントリ数を基準として、補助アクセステーブルを構築する。
【０１３２】
Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍは、ｅｎｔｒｙ ｃｏｕｎｔ数分のエントリで構成されるテーブル（Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ｔａｂｌｅ）を持つ。各エントリは、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅにおける累積情報を管理する範囲における最後のエントリ＋１を管理するｅｎｔｒｙ ｎｕｍ（最初は常にエントリ番号１）、累積情報を求めた範囲の次のチャンク番号を管理するｃｈｕｎｋ、その範囲におけるサンプル１からの累積合計サンプル数を示すｃｏｕｎｔで構成される。
【０１３３】
図５に、図２２で示すサンプル、チャンク構造に対応するＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｔｏｍとＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍとのテーブル部分の内容を示す。なお、ここでも、説明を簡略化するために、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅにおいて一度にメモリに格納できるエントリ数を３エントリと想定している。実際には、このエントリ数はメモリの大きさに依存し、例えば、１０００エントリといった数になる。
【０１３４】
Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ｔａｂｌｅの１エントリ目では、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのエントリ１〜３までの累積情報を管理している。つまり、エントリ１においては、累積情報を管理している範囲の次のチャンク番号６、チャンク１からチャンク５までの累積サンプル数９、次のＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのエントリが４であることを示す。
【０１３５】
同様に、エントリ２では、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのエントリ１〜６までの累積情報を管理する。つまり、次のチャンクが９、累積１５サンプル、次のＳａｍｐｌｅ
ｔｏ ｃｈｕｎｋ ｔａｂｌｅのエントリは７であることを示す。
【０１３６】
本実施形態のデータ管理方法では、以上のような構成の補助アクセステーブルＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍを用いることによって、任意のサンプル番号に対応するチャンク情報を取得する際には、テーブルのｃｏｕｎｔのフィールドから目的のサンプルが含まれるエントリを探し出し、そのテーブルのエントリの情報に基づいて、ダイレクトにＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅの任意のエントリからの一連の情報をメモリに格納することができる。
【０１３７】
これにより、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｔｏｍのテーブルの先頭から順番に情報を読み出す必要が無くなり、処理時間を大幅に短縮することが可能となる。
【０１３８】
＜Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍの構造＞
Ｓｙｎｃ ｓａｍｐｌｅ ａｔｏｍに対応する補助アクセステーブルＳｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍは、図６に示すような構造を有しており、Ｓｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅにおいて一定間隔の情報を抜き出し管理するものである。
【０１３９】
本実施形態のデータ管理方法においては、Ｓｙｎｃ ｓａｍｐｌｅ ａｔｏｍを一回のアクセスでメモリに格納できるテーブルのエントリ数を基準として、補助アクセステーブルを構築する。
【０１４０】
Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍは、ｅｎｔｒｙ ｃｏｕｎｔ数分のエントリで構成されるテーブル（Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅ）を持つ。各エントリは、Ｓｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅのエントリ番号を管理するｅｎｔｒｙ ｎｕｍ、Ｓｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅにおけるｅｎｔｒｙ ｎｕｍ番目のｓｙｎｃ ｓａｍｐｌｅ ｎｕｍｂｅｒを管理するｓｙｎｃ ｎｕｍ、Ｓｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅにおけるｅｎｔｒｙ ｎｕｍ−１番目のｓｙｎｃ ｓａｍｐｌｅ ｎｕｍｂｅｒを管理するｐｒｅｖ ｓｙｎｃ ｎｕｍで構成される。
【０１４１】
図７に、図２２で示すサンプル、チャンク構造に対応するＳｙｎｃ ｓａｍｐｌｅ ａｔｏｍおよびＳｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍのテーブル部分の内容を示す。なお、ここでも、説明を簡略化するために、Ｓｙｎｃ ｓａｍｐｌｅ ａｔｏｍにおいて一度にメモリに格納できるエントリ数を３エントリと想定している。実際には、このエントリ数はメモリの大きさに依存し、例えば、１０００エントリといった値になる。
【０１４２】
Ｓｙｎｃ ｎｕｍには、Ｓｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅのエントリ１のＳａｍｐｌｅ ｎｕｍｂｅｒである１、ｐｒｅｖ ｓｙｎｃ ｎｕｍには、１つ前のエントリが存在しないためにｎｕｌｌ、ｅｎｔｒｙ ｎｕｍには、エントリ１に注目しているので１がそれぞれ格納されている。
【０１４３】
同様に、エントリ２では、Ｓｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅのエントリ４の情報を管理する。つまり、エントリ４においては、ｓｙｎｃ ｎｕｍには６、ｐｒｅｖ ｓｙｎｃ ｎｕｍには１つ前のエントリ（エントリ３）のＳａｍｐｌｅ ｎｕｍｂｅｒである４、ｅｎｔｒｙ ｎｕｍにはエントリ４に注目しているので４がそれぞれ格納される。
【０１４４】
本実施形態のデータ管理方法では、以上のような構成のＳｙｎｃ ｓａｍｐｌｅ ｔｏ ａｃｃｅｓｓ ａｔｏｍを用いることにより、テーブルのｓｙｎｃ ｎｕｍのフィールドから目的のサンプルが含まれるエントリを探し出し、そのテーブルのエントリの情報からダイレクトにＳｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅの任意のエントリからの一連の情報をメモリに格納するため、任意のサンプルが単独でデコードできるか否かについて調べることができる。
【０１４５】
これにより、Ｓｙｎｃ ｓａｍｐｌｅ ａｔｏｍのテーブルの先頭から順番に情報を読み出す必要が無くなり、処理時間を大幅に短縮することが可能となる。
【０１４６】
本実施形態のデータ管理方法では、以上のように、各種の補助アクセステーブルを用いることによって、例えば、図８に示すＴｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍから、補助アクセステーブルであるｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍの情報に基づいて、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅにおける目的のエントリが含まれる情報を１回のロードで読み出すことが可能となる。これにより、各テーブルの先頭から順番に情報を読み出して所望の情報を探す必要はなく、補助アクセステーブルを介して直接的に所望の情報を読み出して、再生指示を受けてから実際に再生が開始されるまでの時間を短縮できる。
【０１４７】
＜ＱｕｉｃｋＴｉｍｅファイルの管理情報の一般的な読み込み＞
ここで、以上のような構成の補助アクセステーブルを用いて、実際にメモリに対して管理情報を読み込む際の一般的な処理について、図９を用いて説明すれば以下の通りである。
【０１４８】
まず、ステップ（以下、Ｓと示す）１０００において、再生する情報を記録した目的のＱｕｉｃｋＴｉｍｅファイルをオープンする。
【０１４９】
まず、Ｓ１００１において、現在位置より８ｂｙｔｅのデータ（ａｔｏｍ ｈｅａｄｅｒ）を記録媒体から読み出す。
【０１５０】
Ｓ１００２においては、現在位置がファイルの終端であるか否かについて確認し、ファイルの終端である場合には、ステップＳ１００８において、ＱｕｉｃｋＴｉｍｅファイルにおける必須ａｔｏｍがメモリにロードできたか否かについて確認する。ここで、ＱｕｉｃｋＴｉｍｅファイルでないファイルをオープンしていた場合は、この段階で無効ファイルであることが判定される。Ｓ１００８において、必須ａｔｏｍが全て存在する場合には正常終了し、必須ａｔｏｍが全て存在していなかった場合には、Ｓ１００９においてエラー処理を行い、処理を終了する。
【０１５１】
一方、Ｓ１００２において、現在位置がファイルの終端でないと判断された場合には、Ｓ１００３において、読み出した８ｂｙｔｅ（ａｔｏｍ ｈｅａｄｅｒ）からａｔｏｍのサイズとａｔｏｍの種別を把握する。
【０１５２】
Ｓ１００４において、現在処理対象のａｔｏｍが、例えば、Ｍｏｖｉｅ ａｔｏｍ、Ｔｒａｃｋ ａｔｏｍ、Ｍｅｄｉａ ａｔｏｍ等のコンテナタイプのａｔｏｍと判定された場合には、Ｓ１００１に戻り、次の８ｂｙｔｅを記録媒体から読み出して、処理を継続する。
【０１５３】
一方、Ｓ１００４において、コンテナタイプのａｔｏｍと判定されなかった場合には、Ｓ１００５において、データを読み出す必要のあるａｔｏｍタイプであるか否かについての判定が行われる。
【０１５４】
ここで、読み出す必要のないａｔｏｍ（例えば、未知のａｔｏｍなど）と判定された場合には、Ｓ１００７において、現在位置を次ぎのａｔｏｍ ｈｅａｄｅｒの位置までシークし、Ｓ１００１に戻って次の８ｂｙｔｅを読み出し、処理を継続する。なお、次のａｔｏｍ ｈｅａｄｅｒの位置までのシークは、現在のａｔｏｍ ｈｅａｄｅｒの先頭から、ａｔｏｍのサイズ分シークすることによって実現できる。
【０１５５】
一方、Ｓ１００５において、読み出す必要のあるａｔｏｍタイプと判定された場合には、Ｓ１００６において、ａｔｏｍ情報を記録媒体から適切なメモリ空間に読み出す。読み出すデータ量は、現在のａｔｏｍ ｈｅａｄｅｒの先頭から、ａｔｏｍのサイズ分のデータを読み出すことになる。そして、Ｓ１００１に戻り、次の８ｂｙｔｅを読み出して、処理を継続する。
【０１５６】
上述した図９に示す処理は、ＱｕｉｃｋＴｉｍｅファイルの管理情報を読み出す際の一般的な処理の流れの概要であるが、本発明のＳａｍｐｌｅ Ｔａｂｌｅ情報を分割読み出しする場合には、図９に示すＳ１００６におけるａｔｏｍ情報を記録媒体から読み出し、メモリに格納する処理を行う際に特別な処理を行う必要がある。
【０１５７】
＜Ｓａｍｐｌｅ Ｔａｂｌｅの分割読み出し処理＞
そこで、この図９に示したＳ１００６に関し、本実施形態のデータ管理方法を適用した場合の処理について、図１０を用いて説明すれば以下の通りである。
【０１５８】
Ｓ１１００において、アクセスを行っているａｔｏｍが、分割読み出しの対象としてのａｔｏｍであるか否かについて判定を行う。ここで、分割読み出しの対象でない場合には、Ｓ１１０３においてａｔｏｍ情報を記録媒体から読み出し処理を終了する。つまり、図９におけるＳ１００６と同じ処理を行う。一方、Ｓ１１００において、分割読み出し対象のａｔｏｍと判定された場合、つまり、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍ、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｔｏｍ、Ｓｙｎｃ Ｓａｍｐｌｅ ａｔｏｍの何れかのａｔｏｍにアクセスしている場合には、Ｓ１１０１において、ａｔｏｍ ｈｅａｄｅｒで示されるサイズ情報より全てのテーブル情報がメモリにロードできるか否かについて判定を行う。
【０１５９】
ここで、全てのテーブルに対応する情報をメモリにロードできる場合には、Ｓ１１０２において、管理情報を全てメモリに読み出したことを示すために、メモリモードを一括モードにセットし、Ｓ１１０３において、ａｔｏｍに格納された情報を全てメモリに読み出し、処理を終了する。
【０１６０】
一方、Ｓ１１０１において、全てのテーブルの内容をメモリにロードできないと判定された場合、つまり、ａｔｏｍ ｈｅａｄｅｒのサイズ情報が、確保されているメモリ量よりも多い場合には、Ｓ１１０４において、補助アクセステーブルが存在するか否かについて調べる。ここで、補助アクセステーブルが存在しない場合には、Ｓ１１０８において、後段にて詳述する補助アクセステーブルの生成を行う。一方、補助アクセステーブルが存在している場合には、Ｓ１１０５へ進む。
【０１６１】
なお、Ｓ１１０４およびＳ１１０８における処理については、Ｓａｍｐｌｅ Ｔａｂｌｅ情報を読み出す際に、アクセステーブルの存在を把握していなければならない。例えば、この補助アクセステーブルがＳａｍｐｌｅ Ｔａｂｌｅよりもファイルの後に記録されているような場合には、判定を行うことができない。よって、このような場合には、全ての管理情報を読み終わった段階で、分割読み込みの対象となったａｔｏｍが存在する場合において対応する補助アクセステーブルが存在するか否かについて調べ、ここで存在しない場合に補助アクセステーブルを生成する処理を行えばよい。
【０１６２】
Ｓ１１０５においては、分割読み出しを行うテーブルの内、メモリに格納できる分だけをロードする。
【０１６３】
Ｓ１１０６においては、管理情報が全てメモリに読み出せなかったことを示すために、メモリモードを分割モードにセットする。
【０１６４】
Ｓ１１０７においては、次のａｔｏｍ ｈｅａｄｅｒの位置までシークして、処理を終了する。つまり、読み出せなかったテーブルのデータ量分だけシークすることによって、次のａｔｏｍ ｈｅａｄｅｒの位置にシークすることが可能である。
【０１６５】
本実施形態のデータ管理方法では、以上のような処理を行うことにより、Ｓａｍｐｌｅ Ｔａｂｌｅ情報を分割して読み出すことができる。
【０１６６】
＜Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍの生成＞
続いて、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍを生成する際の処理の流れについて、図１１を用いて説明すれば以下の通りである。
【０１６７】
Ｓ１２００においては、分割読み出しする単位ｎを決定する。ｎは一度にメモリにロードするテーブルのエントリ数を指す。例えば、一度に１００エントリをメモリに格納する場合にはｎ＝１００になる。Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅの１エントリに必要なメモリ量は８バイトであるから、テーブルをロードするのに必要なメモリ量は８バイト×ｎになる。
【０１６８】
Ｓ１２０１においては、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍの基本部分、具体的には、ａｔｏｍ ｈｅａｄｅｒの次に格納された情報からＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅまでの情報を読み出す。
【０１６９】
Ｓ１２０２においては、変数の初期化を行う。
【０１７０】
Ｓ１２０３においては、変数ｋがＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのエントリ数を超えたか否かについて判定を行う。ここで、変数ｋがＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのエントリ数を超えている場合には、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍの情報を全て生成したことを意味しているため、このまま処理を終了する。なお、生成したＴｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍは、Ｔｒａｃｋ ａｔｏｍ下のＵｓｅｒ ｄｅｆｉｎｅｄ ｄａｔａ ａｔｏｍ内にＡｃｃｅｓｓ ｔａｂｌｅ ａｔｏｍの一部として記録される。
【０１７１】
一方、Ｓ１２０３において、変数ｋがＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのエントリ数を超えていない場合、つまり、全てのＴｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅのエントリ生成が完了していない場合には、Ｓ１２０４において、次のｎエントリ分のＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅの情報を読み出す。
【０１７２】
Ｓ１２０５においては、Ｃｏｕｎｔｔｍｐおよびｄｅｌｔａｔｍｐ変数を初期化する。
【０１７３】
Ｓ１２０６においては、ロードしたＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅの全てのエントリに対して、繰り返しが完了したか否かについて判定を行い、繰り返しが完了していない場合には、Ｓ１２０７において、ｃｏｕｎｔｔｍｐの値に現在注目しているＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのＩ番目のエントリのｓａｍｐｌｅ ｃｏｕｎｔ値を加算する。Ｓ１２０８において、同様にｄｅｌｔａｔｍｐにｓａｍｐｌｅ ｄｅｌｔａの値を加算する。すなわち、Ｓ１２０７およびＳ１２０８においては、メモリにロードしたＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅの累積情報を生成している。
【０１７４】
一方、Ｓ１２０６において、繰り返しが完了したと判定された場合には、Ｓ１２０９において、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅのエントリのｃｏｕｎｔを生成する。具体的には、ひとつ前のエントリのｃｏｕｎｔ値（一つ前までの累積値）に、メモリにロードしたＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅ情報の累積合計値ｃｏｕｎｔｔｍｐを加算する。
【０１７５】
Ｓ１２１０においては、同様に、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅのエントリのｄｅｌｔａを生成する。具体的には、ひとつ前のエントリのｄｅｌｔａ値（一つ前までの累積値）に、メモリにロードしたＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅ情報の累積合計値ｄｅｌｔａｔｍｐを加算する。
【０１７６】
Ｓ１２１１においては、現在注目しているＴｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅのエントリ番号を表すｊに１を加算し、現在注目しているＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのエントリ番号を示すｋにメモリに読み出したエントリ数ｎを加算する。
【０１７７】
Ｓ１２１２においては、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅのｅｎｔｒｙ ｎｕｍにｔｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのエントリ番号ｋに１を加算した値を代入し、Ｓ１２０３に戻って処理を繰り返す。
【０１７８】
以上のように、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍの情報を全て生成したことが分かるまで繰り返し図１１に示す処理を行うことで、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍを生成できる。
【０１７９】
＜Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍの生成＞
続いて、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍを生成する際の処理の流れについて、図１２を用いて説明すれば、以下の通りである。
【０１８０】
Ｓ１３００においては、分割読み出しする単位ｎを決定する。なお、ｎは一度にメモリにロードするテーブルのエントリ数を指す。例えば、一度に１００エントリをメモリに格納する場合にはｎ＝１００となる。Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅの１エントリに必要なメモリ量は１２バイトなので、テーブルをロードするのに必要なメモリ量は１２バイト×ｎになる。
【０１８１】
Ｓ１３０１においては、Ｓａｍｐｌｅ ｔｏ Ｃｈｕｎｋ ａｔｏｍの基本部分、具体的には、ａｔｏｍｈｅａｄｅｒの次に格納された情報から、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅまでの情報を読み出す。
【０１８２】
Ｓ１３０２においては、変数の初期化を行う。
【０１８３】
Ｓ１３０３においては、変数ｋがＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのエントリ数を超えたか否かについて判定を行う。ここで、変数ｋがＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのエントリ数を超えている場合には、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍの情報を全て生成したことを意味するため、そのまま処理を終了する。なお、生成したＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍは、Ｔｒａｃｋ ａｔｏｍ下のＵｓｅｒ ｄｅｆｉｎｅｄ ｄａｔａ ａｔｏｍ内にＡｃｃｅｓｓ ｔａｂｌｅ ａｔｏｍの一部として記録する。
【０１８４】
一方、Ｓ１３０３において、変数ｋがＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのエントリ数を超えていない場合、つまり、全てのＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍのエントリ生成が完了していない場合には、Ｓ１３０４において、次のｎエントリ分のＳａｍｐｌｅ
ｔｏ ｃｈｕｎｋ ｔａｂｌｅの情報を読み出す。
【０１８５】
Ｓ１３０５においては、Ｃｏｕｎｔｔｍｐ変数を初期化する。
【０１８６】
Ｓ１３０６においては、ロードしたＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅの全てのエントリに対して繰り返しが完了したか否かについて判定を行う。ここで、繰り返しが完了していない場合には、Ｓ１３０７において、ｃｏｕｎｔｔｍｐの値に現在注目しているＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのエントリと次のエントリのｆｉｒｓｔ ｃｈｕｎｋの値の差、つまりチャンク数を求めたものに、チャンク中のサンプル数を管理しているｓａｍｐｌｅｓ ｐｅｒ ｃｈｕｎｋの値を掛け合わせたものを足し合わせる。すなわち、Ｓ１３０７においては、メモリにロードしたＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅの累積情報を生成している。
【０１８７】
一方、Ｓ１３０６において繰り返しが完了したと判定された場合には、Ｓ１３０８において、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ｔａｂｌｅのエントリのｃｏｕｎｔを生成する。具体的には、ひとつ前のエントリのｃｏｕｎｔ値（一つ前までの累積値）に、メモリにロードしたＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅ情報の累積合計値ｃｏｕｎｔｔｍｐを足し合わせる。
【０１８８】
Ｓ１３０９においては、現在注目しているＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ｔａｂｌｅのエントリ番号を表わすｊに１を加算し、該Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのエントリ番号を示すｋにメモリに読み出したエントリ数ｎを加算する。
【０１８９】
Ｓ１３１０においては、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ｔａｂｌｅのｅｎｔｒｙ ｎｕｍにＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのエントリ番号ｋに１を加算した値を代入する。
【０１９０】
Ｓ１３１１においては、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ｔａｂｌｅのｃｈｕｎｋにＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅにおけるｅｎｔｒｙ ｎｕｍ番目のエントリのｆｉｒｓｔ ｃｈｕｎｋの値を代入した後、Ｓ１３０３に戻って、処理を繰り返す。
【０１９１】
以上のように、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍの情報を全て生成したことが分かるまで、繰り返し図１２に示すような処理を行うことで、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍを生成できる。
【０１９２】
＜Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍの生成＞
続いて、Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍを生成する際の処理の流れについて、図１３を用いて説明すれば、以下の通りである。
【０１９３】
Ｓ１４００においては、分割読み出しする単位ｎを決定する。ｎは一度にメモリにロードするテーブルのエントリ数を指す。例えば、一度に１００エントリをメモリに格納する場合においては、ｎ＝１００となる。Ｓｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅの１エントリに必要なメモリ量は４バイトなので、テーブルをロードするのに必要なメモリ量は４バイト×ｎである。
【０１９４】
Ｓ１４０１においては、Ｓｙｎｃ ｓａｍｐｌｅ ａｔｏｍの基本部分、具体的には、ａｔｏｍ ｈｅａｄｅｒの次に格納された情報からＳｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅまでの情報を読み込む。
【０１９５】
Ｓ１４０２においては、変数の初期化を行う。
【０１９６】
Ｓ１４０３においては、変数ｋがＳｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅのエントリ数を超えたか否かについて判定を行う。ここで、変数ｋがＳｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅのエントリ数を超えている場合には、Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍの情報を全て生成したことを意味するため、このまま処理を終了する。なお、生成したＳｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍはＴｒａｃｋ ａｔｏｍ下のＵｓｅｒ ｄｅｆｉｎｅｄ ｄａｔａ ａｔｏｍ内にＡｃｃｅｓｓ Ｔａｂｌｅ ａｔｏｍの一部として記録する。
【０１９７】
一方、Ｓ１４０３において、変数ｋがＳｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅのエントリ数を超えていない場合、つまり、全てのＳｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍのエントリ生成が完了していないと判定された場合には、Ｓ１４０４に進む。
【０１９８】
Ｓ１４０４においては、ｋ−１が１以上であるか否かについて判定を行う。ここで、Ｋが１の場合には、一番先頭のテーブルを検出するための処理を行うため、Ｓ１４１１において、Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅのエントリｐｒｅｖ ｓｙｎｃ ｎｕｍに前のｓｙｎｃ ｓａｍｐｌｅ情報がないことを示すｎｕｌｌを代入して、Ｓ１４０７へ進む。
【０１９９】
一方、Ｓ１４０４において、Ｋが１以外である場合には、Ｓ１４０５において、（Ｋ−１）番目のＳｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅのエントリを読み出し、Ｓ１４０６において、ｐｒｅｖ ｓｙｎｃ ｎｕｍに読み出した（Ｋ−１）番目のエントリの情報を代入する。
【０２００】
Ｓ１４０７においては、Ｋ番目のＳｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅのエントリを読み出す。
【０２０１】
Ｓ１４０８においては、読み出したＫ番目のエントリをｓｙｎｃ ｎｕｍに代入する。
【０２０２】
Ｓ１４０９においては、Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅのエントリｅｎｔｒｙ ｎｕｍにＫを代入する。
【０２０３】
Ｓ１４１０においては、現在注目しているＳｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅのエントリ番号を表わすｊに１を加算し、現在注目しているＳｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅのエントリ番号を示すＫにｎを加算し、次にアクセスするエントリ番号を更新する。
【０２０４】
以上のように、Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍの情報を全て生成したことが分かるまで、繰り返し図１２に示すような処理を行うことで、Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍを生成できる。
【０２０５】
＜補助アクセス情報の記録＞
本実施形態のデータ管理方法では、図１１〜図１３に示すような補助アクセステーブルの生成方法に従って生成した各補助アクセステーブルについて、この補助アクセステーブルの生成処理はトラック単位で行われるため、図１に示す補助アクセステーブルは、トラック毎にＴｒａｃｋ ａｔｏｍの下層のＵｓｅｒ ｄｅｆｉｎｅｄ ｄａｔａ ａｔｏｍの中にそれぞれ記録される。
【０２０６】
Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍ、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍ、Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍにそれぞれ生成した補助アクセステーブルは、コンテナａｔｏｍであるＡｃｃｅｓｓ Ｔａｂｌｅ ａｔｏｍに格納され、Ｕｓｅｒ ｄｅｆｉｎｅｄ ｄａｔａ ａｔｏｍ内に記録される。
【０２０７】
次に、以上のように、補助アクセス情報が記録された補助アクセステーブルを備えたＱｕｉｃｋＴｉｍｅファイルに対して、任意の時間から再生を開始するランダムアクセスを行う際の処理について説明すれば、以下の通りである。
【０２０８】
＜Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍからの情報の取得方法＞
まず、本発明のデータ管理方法における、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍから必要な情報を取得する処理について、図１６を用いて説明する。Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍは、図３４を用いて説明したように、指定した再生時刻に対応したサンプル番号とそのサンプルの再生時間長を取得するための管理情報とを格納している。
【０２０９】
Ｓ１５００においては、変数ｓｍｐｎｕｍ、ｔｉｍｅ、ｊを初期化する。
【０２１０】
Ｓ１５０１においては、注目しているトラックのＵｓｅｒ ｄｅｆｉｎｅｄ ｄａｔａ ａｔｏｍ内のＡｃｃｅｓｓ ｔａｂｌｅ ａｔｏｍに、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍが存在するか否かについて調べる。
【０２１１】
これは、分割読み出しモードでは、必ずＴｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍが存在することを前提とした処理であり、存在するか否かについて調べているのは、Ｔｉｍｅｔｏ ｓａｍｐｌｅ ａｔｏｍのテーブル部分が小さい場合に、全ての情報をメモリにロードできているか否かについて調べるためである。なお、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍの情報が全てメモリにロードできない状況であって、かつＴｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍが存在しないような場合には、図１１に示すフローチャートに従って補助アクセステーブルを生成してもよい。
【０２１２】
上記Ｓ１５０１において、補助アクセステーブルが存在しない場合は、Ｓ１５０５へ進む。一方、補助アクセステーブルが存在する場合には、Ｓ１５０２において、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅのエントリ数に相当する分だけ繰り返し処理を行う。
【０２１３】
このとき、全エントリについて調査が終了した場合には、目的のエントリが探し出せなかったことを意味するため、Ｓ１５１２においてエラー処理を行い、処理を終了する。
【０２１４】
一方、全てのエントリについて調査が終わっていない場合には、Ｓ１５０３において、指定した再生時刻ｉｎｔｉｍｅとＴｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅのエントリのｄｅｌｔａとを比較する。ここで、ｄｅｌｔａの方がｉｎｔｉｍｅより小さい場合には、Ｓ１５０２に戻って処理を繰り返す。一方、ｄｅｌｔａがｉｎｔｉｍｅより大きい場合には、Ｓ１５０４へ進む。
【０２１５】
Ｓ１５０４においては、変数ｔｉｍｅにＴｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅにおける１つ前のエントリのｄｅｌｔａを、変数ｓｍｐｎｕｍにｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅにおける１つ前のエントリのｃｏｕｎｔを、ｊにｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅにおける１つ前のエントリのｅｎｔｒｙ ｎｕｍの値をそれぞれ代入する。
【０２１６】
Ｓ１５０５においては、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのｊ番目のエントリがメモリ上に存在するか否かについて調べる。ここで、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのｊ番目のエントリがメモリ上に存在する場合にはＳ１５０７へ進む。一方、存在しない場合には、Ｓ１５０６において、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅから、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅのｅｎｔｒｙ ｎｕｍ［ｉ−１］番目からｅｎｔｒｙ ｎｕｍ［ｉ］番目のエントリを記録媒体から読み出して、メモリにロードする。
【０２１７】
Ｓ１５０７においては、注目しているＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのｊ番目のエントリのｓａｍｐｌｅ ｃｏｕｎｔだけ処理を繰り返し、繰り返しが完了するとＳ１５１０へ進む。なお、繰り返しが完了していない場合には、Ｓ１５０８において、指定した再生時刻ｉｎｔｉｍｅが変数ｔｉｍｅにＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのｊ番目のエントリのｓａｍｐｌｅ ｄｅｌｔａを足した値より小さいか否かについて判定を行い、小さいと判定された場合には、目的のサンプルが見つかったことを意味するため、ここで処理を終了する。このとき、指定した再生時刻ｉｎｔｉｍｅに対応するサンプル番号は、変数ｓｍｐｎｕｍの値であり、サンプルの再生時間長は、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのｊ番目のエントリのｓａｍｐｌｅ ｄｅｌｔａ値である。
【０２１８】
一方、Ｓ１５０８において、指定した再生時刻ｉｎｔｉｍｅが変数ｔｉｍｅにＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのｊ番目のエントリのｓａｍｐｌｅ ｄｅｌｔａを足した値より大きいと判定された場合には、Ｓ１５０９において、変数ｔｉｍｅにｊ番目のエントリのｓａｍｐｌｅ ｄｅｌｔａの値を加算し、変数ｓｍｐｎｕｍに１を加算し、Ｓ１５０７に戻って処理を繰り返す。
【０２１９】
Ｓ１５１０においては、現在注目しているＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのエントリ番号であるｊに１を加算する。
【０２２０】
Ｓ１５１１においては、ｊがＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅの総エントリ数を超えているか否かについて判定を行い、総エントリ数を超えている場合には、指定した時間の情報が無かったことを意味するため、Ｓ１５１２においてエラー処理を行い、処理を終了する。一方、Ｓ１５１１において、総エントリ数を超えていない場合には、Ｓ１５０７に戻って処理を繰り返す。
【０２２１】
以上のように、本実施形態のデータ管理方法では、ＱｕｉｃｋＴｉｍｅファイルのＴｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍに格納された情報を効率よく取得することができる。
【０２２２】
＜Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｔｏｍからの情報の取得方法＞
続いて、本実施形態のデータ管理方法により、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｔｏｍから必要な情報を取得する処理の流れについて、図１５を用いて説明すれば以下の通りである。
【０２２３】
Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｔｏｍは、図３４を用いて説明したように、指定したサンプル番号に対応したチャンク番号とそのチャンク中のサンプル数などを取得するための管理情報である。
【０２２４】
Ｓ１６００においては、変数ｉ、ｃｈｋｔｍｐ、ｓｍｐｔｍｐを初期化する。
【０２２５】
Ｓ１６０１においては、注目しているトラックのＵｓｅｒ ｄｅｆｉｎｅｄ ｄａｔａ ａｔｏｍ内のＡｃｃｅｓｓ ｔａｂｌｅ ａｔｏｍにＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍが存在するか否かについて調べる。
【０２２６】
なお、これは、分割読み出しモードでは、必ずＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍが存在することを前提とした処理であって、存在するか否かについて調べているのは、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｔｏｍのテーブル部分が小さい場合に、全てメモリにロードできているか否かについて調べるためである。また、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｔｏｍの情報が全てメモリにロードできない状況であって、かつ、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍが存在しないような場合においては、図１２に示した方法により補助アクセステーブルを生成してもよい。
【０２２７】
上記Ｓ１６０１において、補助アクセステーブルが存在しない場合には、Ｓ１６０５へ進む。一方、補助アクセステーブルが存在する場合には、Ｓ１６０２において、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ｔａｂｌｅのエントリ数分繰り返し処理を行う。
【０２２８】
ここで、全エントリについて調査が終わってしまった場合には、目的のエントリが探せなかったことを意味するため、Ｓ１６１２においてエラー処理を行い、処理を終了する。一方、全てのエントリについて調査が終わっていない場合には、Ｓ１６０３において、指定したサンプル番号ｓｍｐｎｕｍと、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ｔａｂｌｅのエントリのｃｏｕｎｔとを比較する。ここで、ｃｏｕｎｔの方がｓｍｐｎｕｍより小さい場合には、Ｓ１６０２に戻って処理を繰り返す。一方、ｃｏｕｎｔがｓｍｐｎｕｍより大きい場合には、Ｓ１６０４へ進む。
【０２２９】
Ｓ１６０４においては、変数ｃｈｋｔｍｐにＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ｔａｂｌｅにおける１つ前のエントリのｃｈｕｎｋを、変数ｓｍｐｔｍｐにＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ｔａｂｌｅにおける１つ前のエントリのｃｏｕｎｔを、ｊにＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ｔａｂｌｅにおける１つ前のエントリｅｎｔｒｙ ｎｕｍの値をそれぞれ代入する。
【０２３０】
Ｓ１６０５においては、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのｊ番目のエントリがメモリ上に存在するか否かについて調べる。ここで、存在する場合にはＳ１６０７に進み、存在しない場合には、Ｓ１６０６において、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅから、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ｔａｂｌｅのｅｎｔｒｙ ｎｕｍ［ｉ−１］番目からｅｎｔｒｙ ｎｕｍ［ｉ］番目のエントリを記録媒体から読み出してメモリにロードする。
【０２３１】
Ｓ１６０７においては、注目しているＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのｊ番目のエントリのｆｉｒｓｔ ｃｈｕｎｋからｊ＋１番目のエントリのｆｉｒｓｔ ｃｈｕｎｋの値まで処理を繰り返し、繰り返しが完了した場合には、Ｓ１６１０へ進む。一方、繰り返しが完了していない場合には、Ｓ１６０８において、指定したサンプル番号が、変数ｓｍｐｔｍｐにＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのｊ番目のエントリのｓａｍｐｌｅ ｐｅｒ ｃｈｕｎｋの値を加算した値より小さいか否かについて判定を行う。
【０２３２】
ここで、指定したサンプル番号が、変数ｓｍｐｔｍｐにＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのｊ番目のエントリのｓａｍｐｌｅ ｐｅｒ ｃｈｕｎｋの値を加算した値より小さいと判定された場合には、目的のチャンク情報が見つかったことを意味するため、このまま処理を終了する。このとき、指定したサンプル番号に対応するチャンク番号は変数Ｋの値であり、チャンク中のサンプル数はＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのｊ番目のエントリのｓａｍｐｌｅｓ ｐｅｒ ｃｈｕｎｋの値である。一方、大きいと判定された場合には、Ｓ１６０９において変数ｓｍｐｔｍｐの値にｊ番目のエントリのｓａｍｐｌｅｓ ｐｅｒ ｃｈｕｎｋの値を足し合わせ、Ｓ１６０７に戻って処理を繰り返す。
【０２３３】
Ｓ１６１０においては、現在注目しているＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのエントリ番号であるｊに１を加算する。
【０２３４】
Ｓ１６１１においては、ｊがＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅの総エントリ数を超えているか否かについて判定を行う。ここで、ｊがＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅの総エントリ数を超えていると判定された場合には、指定したサンプルの情報が無かったことを意味するため、Ｓ１６１２においてエラー処理を行って処理を終了する。一方、Ｓ１６１１において、ｊがＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅの総エントリ数を超えていないと判定された場合には、Ｓ１６０７に戻って処理を繰り返す。
【０２３５】
本実施形態のデータ管理方法においては、以上のような処理を行うことにより、ＱｕｉｃｋＴｉｍｅファイルのＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｔｏｍに格納された情報を効率よく取得できる。
【０２３６】
＜Ｓｙｎｃ ｓａｍｐｌｅ ａｔｏｍからの情報の取得方法＞
本実施形態のデータ管理方法におけるＳｙｎｃ Ｓａｍｐｌｅ ａｔｏｍから必要な情報を取得する処理について、図１６を用いて説明すれば以下の通りである。
【０２３７】
なお、Ｓｙｎｃ ｓａｍｐｌｅ ａｔｏｍは、図３４を用いて説明したように、指定したサンプル番号のサンプルが単独でデコード可能か否かについて調べるための管理情報である。
【０２３８】
Ｓ１７００においては、変数ｉを初期化する。
【０２３９】
Ｓ１７０１においては、注目しているトラックのＵｓｅｒ ｄｅｆｉｎｅｄ ｄａｔａ ａｔｏｍ内のＡｃｃｅｓｓ ｔａｂｌｅ ａｔｏｍにＳｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍが存在するか否かについて調べる。ここでは、分割読み出しモードの場合には、必ずＳｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍが存在することを前提にしており、存在するか否かについて調べているのは、Ｓｙｎｃｓａｍｐｌｅ ａｔｏｍのテーブル部分が小さく全てメモリにロードできているかどうかを調べるためである。なお、処理によっては、Ｓｙｎｃ ｓａｍｐｌｅ ａｔｏｍの情報が全てメモリにロードできない状況であって、かつ、Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍが存在しない場合に、上述した図１３に示す方法により補助アクセステーブルを生成してもよい。
【０２４０】
ここで、注目しているトラックのＵｓｅｒ ｄｅｆｉｎｅｄ ｄａｔａ ａｔｏｍ内のＡｃｃｅｓｓ ｔａｂｌｅ ａｔｏｍにＳｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍが存在しない場合には、Ｓ１７０５へ進む。
【０２４１】
一方、注目しているトラックのＵｓｅｒ ｄｅｆｉｎｅｄ ｄａｔａ ａｔｏｍ内のＡｃｃｅｓｓ ｔａｂｌｅ ａｔｏｍにＳｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍが存在する場合には、Ｓ１７０２において、Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅのエントリ数分繰り返し処理を行う。
【０２４２】
このとき、全エントリについて調査が終わってしまった場合には、目的のエントリが探し出せなかったことを意味するため、Ｓ１７１１においてエラー処理を行って処理を終了する。一方、全てのエントリについて調査が終わっていない場合には、Ｓ１７０３において、指定したサンプル番号ｓｍｐｎｕｍとＳｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅのエントリのｓｙｎｃ ｎｕｍとを比較する。
【０２４３】
比較した結果、ｓｙｎｃ ｎｕｍの方がｓｍｐｎｕｍより小さい場合には、Ｓ１７０２に戻って処理を繰り返す。一方、ｓｙｎｃ ｎｕｍがｓｍｐｎｕｍより大きい場合には、Ｓ１７０４に進む。
【０２４４】
Ｓ１７０４においては、Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅにおける１つ前のエントリのｅｎｔｒｙ ｎｕｍの値をｊに代入する。
【０２４５】
Ｓ１７０５においては、Ｓｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅのｊ番目のエントリがメモリ上に存在するか否かについて調べ、存在する場合にはＳ１７０７に進む。一方、存在しない場合は、Ｓ１７０６において、Ｓｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅから、Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅのｅｎｔｒｙ ｎｕｍ［ｉ−１］からｅｎｔｒｙ ｎｕｍ［ｉ］番目のエントリを記録媒体より読み出し、メモリにロードする。
【０２４６】
Ｓ１７０７においては、指定したサンプル番号ｓｍｐｎｕｍがＳｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅのｊ番目のエントリのｓａｍｐｌｅ ｎｕｍｂｅｒと一致するか否かについて判定を行う。
【０２４７】
ここで、一致する場合には、指定したサンプルが単独でデコード可能であることを意味するため処理を終了する。一方、一致しない場合には、Ｓ１７０８において、指定したサンプルのサンプル番号ｓｍｐｎｕｍとＳｙｎｃ Ｓａｍｐｌｅ ｔａｂｌｅのｊ番目のエントリのｓａｍｐｌｅ ｎｕｍｂｅｒとを比較する。ここで、ｓｍｐｎｕｍの方が小さい場合には、指定したサンプルは単独でデコードできないことを意味するため、処理を終了する。一方、大きい場合には、Ｓ１７０９において、注目しているエントリ番号ｊに１を足し合わせる。
【０２４８】
Ｓ１７１０においては、ｊがＳｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅの総エントリ数を超えているか否かについて判定を行う。ここで、超えている場合には、指定したサンプルの情報が無かったことを意味するため、Ｓ１７１０においてエラー処理を行って処理を終了する。一方、超えていない場合には、Ｓ１７０７に戻って処理を繰り返す。
【０２４９】
本実施形態のデータ管理方法では、以上のような処理を行うことにより、ＱｕｉｃｋＴｉｍｅファイルのＳｙｎｃ ｓａｍｐｌｅ ａｔｏｍに格納された情報を効率よく取得できる。
【０２５０】
本実施形態のデータ管理方法は、以上のように、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍ、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍ、Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍのような補助アクセステーブルを設けることによって、任意の時間から再生を開始するランダムアクセスを行う際に、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅ、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅ、Ｓｙｎｃ ｓａｍｐｌｅｔａｂｌｅのそれぞれにおいて、テーブルの先頭から順番に目的の情報を探し出すまで、繰り返し読み出す必要がなくなる。よって、再生開始までの処理時間を大幅に短縮することが可能となる。また、読み出す管理情報が記録されている記録媒体が、光ディスクなどシーク時間（アクセス時間）やデータの読み出しレートの遅い媒体においては、さらに効果が大きくなる。
【０２５１】
また、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅ、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ｔａｂｌｅ、Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅの各エントリについて、それぞれ、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅ、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅ、Ｓｙｎｃ Ｓａｍｐｌｅ ｔａｂｌｅを、再生機器のメモリに分割ロードする単位で生成することによって、補助アクセステーブルの１つのエントリが格納している累積情報と、主のテーブルの分割読み出しする単位と一致するため、再生機器等メモリへ効率よく読み出しを行うことが可能となる。
【０２５２】
＜バリエーション＞
本実施形態のデータ管理方法では、上述したように、補助アクセステーブルにおけるｔａｂｌｅ情報のエントリは、主の管理テーブルを分割読み出しする単位を基準に生成されている。
【０２５３】
例えば、図３（図５，図７も同様）に示すように、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅを３エントリ単位で記録媒体から分割読み出しするような場合には、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅａｃｃｅｓｓ ｔａｂｌｅではＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅの３エントリ単位でテーブルの先頭からの累積情報を管理している。
【０２５４】
このような構成にすることによって、補助アクセステーブルに格納する情報の単位（エントリ数）が、分割読み出しする単位（エントリ数）と一致するため、効率よく情報の分割読み出しを行うことができる。
【０２５５】
ここで、補助アクセステーブルにおけるｔａｂｌｅ情報のエントリ生成方法として、主の管理テーブルにアクセスするためのインデックス情報ができるだけ等間隔に配置されるように設定する方法について説明する。
【０２５６】
＜Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍのバリエーション＞
まず、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍとＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅとの関係について、図１７を用いて説明すれば以下の通りである。
【０２５７】
ここでは、約５００ｔｉｍｅ ｕｎｉｔ毎に対応するＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのエントリにアクセスできるように、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅのエントリを生成している。
【０２５８】
Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅのｄｅｌｔａは、先頭からの累積再生時間長を表すフィールドであるため、約５００ｔｉｍｅ ｕｎｉｔ単位で数字が増えている。ただし、上記ｄｅｌｔａは５００ｔｉｍｅ ｕｎｉｔぴったりで区切れないため、５００ｔｉｍｅ ｕｎｉｔに一番近い時間情報が格納されている。Ｅｎｔｒｙ ｎｕｍには、対応するＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのエントリ番号、ｃｏｕｎｔには、先頭からの累積サンプル数が管理されている。
【０２５９】
例えば、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅの１エントリ目では、累積再生時間長ｄｅｌｔａ＝４８０に対応する、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのエントリ番号はｅｎｔｒｙ ｎｕｍ＝４、エントリ番号１〜３までに、累積５サンプル存在することを表している。また、２エントリ目では、累積再生時間長ｄｅｌｔａ＝８６５に対応する、Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅのエントリ番号はｅｎｔｒｙ ｎｕｍ＝６、エントリ番号１〜５までに累積９サンプル存在することを表している。
【０２６０】
なお、補助テーブルの作成方法やアクセス方法については、既に説明した方法と基本的な考えは同一であるため、説明を省略する。
【０２６１】
＜Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍのバリエーション＞
次に、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍとＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅとの関係について、図１８を用いて説明すれば以下の通りである。
【０２６２】
ここでは、約５サンプル毎に対応するＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのエントリにアクセスできるように、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ｔａｂｌｅのエントリを生成している。
【０２６３】
Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ｔａｂｌｅのｃｏｕｎｔは、先頭からの累積サンプル数を表すフィールドであるため、約５サンプル単位で数字が増えている。ただし、ｃｏｕｎｔは、５サンプルぴったりで区切れないため、５サンプルに一番近い情報が格納されている。Ｅｎｔｒｙ ｎｕｍには、対応するＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのエントリ番号、ｃｈｕｎｋには対応するＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのｆｉｒｓｔ ｃｈｕｎｋの値を管理している。
【０２６４】
例えば、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ｔａｂｌｅの１エントリ目では、累積サンプル数＝３に対応する、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのエントリ番号はｅｎｔｒｙ ｎｕｍ＝３、対応するｆｉｒｓｔ ｃｈｕｎｋの値であるｃｈｕｎｋには３を管理している。
【０２６５】
また、２エントリ目では、累積サンプル数＝１２に対応する、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅのエントリ番号はｅｎｔｒｙ ｎｕｍ＝５、対応するｆｉｒｓｔ ｃｈｕｎｋの値であるｃｈｕｎｋには７を管理している。
【０２６６】
なお、補助テーブルの作成方法やアクセス方法については、既に説明した方法と基本的な考えは同一であるため、上記と同様に説明を省略する。
【０２６７】
＜Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍのバリエーション＞
さらに、Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍとＳｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅとの関係について、図１９を用いて説明すれば以下の通りである。
【０２６８】
ここでは、約５サンプル毎に対応するＳｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅのエントリにアクセスできるように、Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅのエントリを生成している。
【０２６９】
Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅのｓｙｎｃ ｎｕｍは、約５サンプル単位で数字が増えている。ただし、５サンプルぴったりで区切れないため、５サンプルに一番近い情報が格納されている。Ｅｎｔｒｙ ｎｕｍには、対応するＳｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅのエントリ番号、ｐｒｅｖ ｓｙｎｃ ｎｕｍには１つ前のｓｙｎｃサンプルの番号を管理している。
【０２７０】
例えば、Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅの１エントリ目では、ｓｙｎｃ ｎｕｍには１、Ｓｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅのエントリ番号はｅｎｔｒｙ ｎｕｍ＝１、ｐｒｅｖ ｓｙｎｃ ｎｕｍの値は存在しないことを表すｎｕｌｌを管理している。また、２エントリ目では、ｓｙｎｃ ｎｕｍには６、Ｓｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅのエントリ番号はｅｎｔｒｙ ｎｕｍ＝４、ｐｒｅｖ ｓｙｎｃ ｎｕｍの値は４であることを管理している。
【０２７１】
なお、補助テーブルの作成方法やアクセス方法については、既に説明した方法と基本的な考えは同一であるため、上記と同様に説明を省略する。
【０２７２】
本実施形態のデータ管理方法では、図１７〜図１９に示すように、主の管理テーブルにアクセスするための補助アクセステーブルによる各エントリを極力等間隔になるように設定しているため、補助アクセステーブルのテーブルにアクセスする際に、先頭から順番にエントリをアクセスしなくても、おおよその見当をつけて目的のエントリにアクセスすることが可能となる。よって、より効率よく所望の情報の読み出しが可能になる。
【０２７３】
すなわち、例えば、１エントリ１０秒単位で管理しているとすれば、１００秒に対応するエントリにアクセスしたければ、１０エントリ目にアクセスすればよい。
【０２７４】
これにより、再生しようとする所望の情報に対応する管理情報を早急に探し出すことができ、再生開始までの所要時間を短縮することができる。
【０２７５】
＜整合の検出＞
主の管理情報テーブルは解釈でき、本実施形態における補助アクセステーブルを解釈できない実装が、編集処理を行うと主の管理テーブルと補助アクセステーブルとの整合が保てなくなり問題がある。不整合を検出するために、補助アクセステーブルＴｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍ、Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍ、Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍのそれぞれに、日時を管理するフィールドを追加してもよい。このフィールドには、補助アクセステーブルを作成した時点でのＭｅｄｉａ ｈｅａｄｅｒａｔｏｍで管理する変更日時情報を格納するようにする。メディア情報に変更が発生すると、Ｍｅｄｉａ Ｈｅａｄｅｒ ａｔｏｍの変更日時情報が書き換わるため、補助アクセステーブルで管理する日時と一致しないことで、不整合を検出することが可能になる。
【０２７６】
あるいは、各補助アクセステーブルに、対応する主の管理テーブルのエントリ数を管理させてもよい。主の管理テーブルに新たな情報が追加されたり、削除された場合には、主の管理テーブルのエントリ数が変更されるため、補助アクセステーブルで管理するエントリ数と一致しないことで、不整合を検出することが可能になる。
＜Ｆｒａｇｍｅｎｔｅｄ ｍｏｖｉｅへの応用＞
録画中の電源遮断等に対応するために導入された概念であるＦｒａｇｍｅｎｔｅｄ Ｍｏｖｉｅは、管理情報を分散して管理することを可能とする仕組みである。この機能を用いた場合、Ｆｒａｇｍｅｎｔごとに管理情報を分散記録するが、このときのＦｒａｇｍｅｎｔの再生時間長に決まりはなく、Ｆｒａｇｍｅｎｔごとに可変であってもよい。このとき、Ｆｒａｇｍｅｎｔｅｄ Ｍｏｖｉｅファイルの先頭に配置される基本管理情報に、補助アクセステーブルを置く。この補助アクセステーブルでは、各Ｆｒａｇｍｅｎｔと累積再生時間とＦｒａｇｍｅｎｔの記録位置との対応を管理する。このような補助アクセステーブルを用意することによって、任意の時刻に対応するＦｒａｇｍｅｎｔを特定し、そのＦｒａｇｍｅｎｔの記録位置を瞬時に特定することが可能となる。なお、補助テーブルの作成方法やアクセス方法については、既に説明した方法と基本的な考えは同一であるため、上記と同様に説明を省略する。
【０２７７】
なお、本実施形態では、ＱｕｉｃｋＴｉｍｅファイルフォーマットを用いた管理方法について説明したが、本発明はこれに限定されるものではない。例えば、メディアデータにアクセスするための管理情報テーブルにおいて、基準となる時刻等、テーブル中の任意のエントリが何に対応するかを計算などで一意に求められないような構造のファイル等に対しても適用可能である。
【０２７８】
また、本発明のデータ管理方法は、複数のデータ毎の情報を管理する主の管理テーブルの各エントリが、情報の省略などによって一定の規則に従って構成されないデータ管理方法において、上記主の管理テーブルの各エントリに効率よくアクセスする補助管理テーブルを用意することを特徴とするデータ管理方法と表現することもできる。
【０２７９】
【発明の効果】
本発明のデータ管理方法は、以上のように、記録媒体から必要な情報を読み出す際には、上記主の管理テーブルに含まれる複数のエントリ分の累積情報を個々のエントリで管理する補助管理テーブルを用いる管理方法である。
【０２８０】
それゆえ、記録媒体の主の管理テーブルに格納された情報を再生する場合には、補助管理テーブルを介して直接的に所望の情報へアクセスし、該所望の情報を効率よく読み出すことで、再生指示を受けてから実際に再生が開始されるまでの時間を短縮できるという効果を奏する。
【０２８１】
上記補助管理テーブルが備えている各エントリは、上記主の管理テーブルの分割読み出しを行う複数のエントリ分の累積情報を管理していることがより好ましい。
【０２８２】
それゆえ、主の管理テーブルから分割読み出しする単位と、補助管理テーブルの１つのエントリに管理されている主の管理テーブルのエントリ数とを一致させることができるため、主の管理テーブルから再生を行う装置等のメモリに対して、さらに効率よく読み出しを行うことができるという効果を奏する。
【０２８３】
上記補助管理テーブルの各エントリは、上記累積情報が略等間隔で増加していくように、上記主の管理テーブルのエントリ数を区切って形成されていることがより好ましい。
【０２８４】
それゆえ、補助管理テーブルにおける１エントリの間隔をできる限り等間隔になるように設定することで、おおよその見当をつけて所望の情報が含まれるエントリに対してアクセスすることができる。よって、所望の情報が含まれるエントリにより効率よくアクセスすることができ、再生開始までに要する時間をより短縮できるという効果を奏する。
【０２８５】
上記主の管理テーブルが分割読み出しの対象となっており、かつ該分割読み出しを行うエントリに対応する補助管理テーブルが存在しない場合には、補助管理テーブルを生成することがより好ましい。
【０２８６】
それゆえ、分割読み出しを行う主の管理テーブルのエントリに対応する補助管理テーブルが存在していない場合に補助管理テーブルを作成することで、補助管理テーブルの作成を必要最小限にでき、記録する情報量の増大を抑制できるという効果を奏する。
【０２８７】
上記主の管理テーブルは、ＱｕｉｃｋＴｉｍｅファイルフォーマットであることがより好ましい。
【０２８８】
それゆえ、ビデオデータやオーディオデータ等のメディアデータと管理情報とを備えているＱｕｉｃｋＴｉｍｅファイルフォーマットのうち、管理情報について補助管理テーブルを形成し、該補助管理テーブルを介して所望の情報を含むエントリにアクセスすることで、効率よく所望の情報を取得できるという効果を奏する。
【０２８９】
上記補助管理テーブルは、時間に関する累積情報を管理していることがより好ましい。
【０２９０】
それゆえ、任意の時間から再生を開始する、いわゆるランダムアクセスを行う場合でも、主の管理テーブルのエントリに１つずつアクセスして所望の情報を探し出す必要はなく、補助管理テーブルの各エントリに管理されている累積時間情報の中から上記任意の時間が含まれるエントリにアクセスすることで、直接的に所望の情報を取得できるという効果を奏する。
【０２９１】
上記補助管理テーブルは、サンプルおよびチャンクに関する累積情報を管理していることがより好ましい。
【０２９２】
それゆえ、任意のサンプル番号に対応するチャンク情報を取得する場合において、補助管理テーブルの各エントリに管理されている累積サンプル情報の中から、所望のサンプルが含まれるエントリを選択してアクセスすることで、直接的に所望の情報を取得できるという効果を奏する。
【０２９３】
上記補助管理テーブルは、単独でデコード可能なサンプルに関する情報を管理していることがより好ましい。
【０２９４】
それゆえ、任意のサンプルが単独でデコードできるか否かについて調べる場合において、補助管理テーブルの各エントリに管理されている累積情報の中から、所望のサンプルが含まれるエントリを選択してアクセスすることで、直接的に所望のデコード可能なサンプル情報を取得できるという効果を奏する。
【０２９５】
本発明のデータ管理装置は、以上のように、記録媒体から必要な情報を読み出す際には、上記主の管理テーブルに含まれる複数のエントリ分の累積情報を個々のエントリで管理する補助管理テーブルを用いる構成である。
【０２９６】
それゆえ、記録媒体の主の管理テーブルに格納された情報を再生する場合には、補助管理テーブルを介して直接的に所望の情報へアクセスし、該所望の情報を効率よく読み出すことで、再生指示を受けてから実際に再生が開始されるまでの時間を短縮できるという効果を奏する。
【０２９７】
上記補助管理テーブルが備えている各エントリは、上記主の管理テーブルの分割読み出しを行う複数のエントリ分の累積情報を管理していることがより好ましい。
【０２９８】
それゆえ、主の管理テーブルから分割読み出しする単位と、補助管理テーブルの１つのエントリに管理されている主の管理テーブルのエントリ数とを一致させることができるため、主の管理テーブルから再生機器等のメモリに対して、さらに効率よく情報の読み出しを行うことができるという効果を奏する。
【０２９９】
上記補助管理テーブルの各エントリは、上記累積情報が略等間隔で増加していくように、上記主の管理テーブルのエントリ数を区切って形成されていることがより好ましい。
【０３００】
それゆえ、補助管理テーブルにおける１エントリの間隔をできる限り等間隔になるように設定することで、おおよその見当をつけて所望の情報が含まれるエントリに対してアクセスすることができる。よって、より効率よく、所望の情報が含まれるエントリにアクセスすることができ、再生開始までに要する時間を短縮できるという効果を奏する。
【０３０１】
上記主の管理テーブルが分割読み出しの対象となっており、かつ該分割読み出しを行うエントリに対応する補助管理テーブルが存在しない場合には、補助管理テーブルを生成することがより好ましい。
【０３０２】
それゆえ、分割読み出しを行う主の管理テーブルのエントリに対応する補助管理テーブルが存在していない場合に補助管理テーブルを作成することで、補助管理テーブルの作成を必要最小限にでき、情報量の増大を抑制できるという効果を奏する。
【０３０３】
上記主の管理テーブルは、ＱｕｉｃｋＴｉｍｅファイルフォーマットであることがより好ましい。
【０３０４】
それゆえ、ビデオデータやオーディオデータ等のメディアデータと管理情報とを備えているＱｕｉｃｋＴｉｍｅファイルフォーマットのうち、管理情報について補助管理テーブルを形成し、該補助管理テーブルを介して所望の情報を含むエントリにアクセスすることで、効率よく所望の情報を取得できるという効果を奏する。
【０３０５】
本発明のデータ管理プログラムは、以上のように、上記データ管理方法を、コンピュータに実行させる構成である。
【０３０６】
それゆえ、本発明のデータ管理プログラムをコンピュータに実行させることにより、記録媒体の主の管理テーブルに格納された情報を再生する際に、補助管理テーブルを介して直接的に所望の情報へアクセスし、該所望の情報を効率よく読み出すことで、再生指示を受けてから実際に再生が開始されるまでの時間を短縮できるという効果を奏する。
【０３０７】
本発明のデータ管理プログラムを記録した記録媒体は、以上のように、上記データ管理プログラムを記録した構成である。
【０３０８】
それゆえ、本発明の記録媒体をコンピュータに読み取らせることにより、記録媒体の主の管理テーブルに格納された情報を再生する際に、補助管理テーブルを介して直接的に所望の情報へアクセスし、該所望の情報を効率よく読み出すことで、再生指示を受けてから実際に再生が開始されるまでの時間を短縮できるという効果を奏する。
【図面の簡単な説明】
【図１】ＱｕｉｃｋＴｉｍｅファイルにおける、Ａｃｃｅｓｓ ｔａｂｌｅ ａｔｏｍの配置位置を示す図である。
【図２】Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍの構造を示す図である。
【図３】３エントリずつテーブルを読み出す場合のＴｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅとＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅの関係を示す図である。
【図４】Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ａｔｏｍの構造を示す図である。
【図５】３エントリずつテーブルを読み出す場合のＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ｔａｂｌｅとＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅとの関係を示す図である。
【図６】Ｓｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ａｔｏｍの構造を示す図である。
【図７】３エントリずつテーブルを読み出す場合のＳｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅとＳｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅとの関係を示す図である。
【図８】補助アクセステーブルを利用した場合のデータの読み出す様子を示す図である。
【図９】ＱｕｉｃｋＴｉｍｅファイルの管理情報を読み込む処理の流れを示す図である。
【図１０】分割読み出し対象のａｔｏｍの管理情報を読み出す際の詳細な処理の流れを示す図である。
【図１１】Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍにおいて、管理情報の分割読み出しを行う処理の流れを示す図である。
【図１２】Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｔｏｍにおいて、管理情報を分割読み出しを行う処理の流れを示す図である。
【図１３】Ｓｙｎｃ ｓａｍｐｌｅ ａｔｏｍにおいて、管理情報を分割読み出しを行う処理の流れを示す図である。
【図１４】Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍにおいて、サンプル情報を取得する処理の流れを示す図である。
【図１５】Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｔｏｍにおいて、サンプル情報を取得する処理の流れを示す図である。
【図１６】Ｓｙｎｃ ｓａｍｐｌｅ ａｔｏｍにおいて、サンプル情報を取得する処理の流れを示す図である。
【図１７】５００ｔｉｍｅ ｕｎｉｔ単位で補助アクセステーブルを生成する場合のＴｉｍｅ ｔｏ ｓａｍｐｌｅ ａｃｃｅｓｓ ｔａｂｌｅとＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅとの関係を示す図である。
【図１８】５サンプル単位で補助アクセステーブルを生成する場合のＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｃｃｅｓｓ ｔａｂｌｅとＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅの関係を示す図である。
【図１９】５サンプル単位で補助アクセステーブルを生成する場合のＳｙｎｃ ｓａｍｐｌｅ ａｃｃｅｓｓｔａｂｌｅとＳｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅの関係を示す図である。
【図２０】従来のＱｕｉｃｋＴｉｍｅファイルの構造を示す図である。
【図２１】従来のＳａｍｐｌｅ ｔａｂｌｅ ａｔｏｍの構造を示す図である。
【図２２】従来のサンプルとチャンク構造の例を示す図である。
【図２３】従来のＴｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍの構造を示す図である。
【図２４】従来のＴｉｍｅ ｔｏ ｓａｍｐｌｅ ｔａｂｌｅの例を示す図である。
【図２５】従来のＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｔｏｍの構造を示す図である。
【図２６】従来のＳａｍｐｌｅ ｔｏ ｃｈｕｎｋ ｔａｂｌｅの例を示す図である。
【図２７】従来のＳｙｎｃ Ｓａｍｐｌｅ ａｔｏｍの構造を示す図である。
【図２８】従来のＳｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅの構造を示す図である。
【図２９】従来のＳａｍｐｌｅ ｓｉｚｅ ａｔｏｍの構造を示す図である。
【図３０】従来のＳａｍｐｌｅ ｓｉｚｅ ｔａｂｌｅの例を示す図である。
【図３１】従来のＣｈｕｎｋ ｏｆｆｓｅｔ ａｔｏｍの構造を示す図である。
【図３２】従来のＣｈｕｎｋ ｏｆｆｓｅｔ ｔａｂｌｅの例を示す図である。
【図３３】従来のサンプルとチャンク構造の例を示す図である。
【図３４】従来のサンプル情報を取得する際の処理の流れを示す図である。
【図３５】従来の管理情報の分割読み出し処理の様子を示す図である。
【符号の説明】
１００ Ｔｉｍｅ ｔｏ ｓａｍｐｌｅ ａｔｏｍ
１０１ Ｓａｍｐｌｅ ｔｏ ｃｈｕｎｋ ａｔｏｍ
１０２ Ｓａｍｐｌｅ ｓｉｚｅ ａｔｏｍ
１０３ Ｓｙｎｃ ｓａｍｐｌｅ ａｔｏｍ
１０４ Ｃｈｕｎｋ ｏｆｆｓｅｔ ａｔｏｍ
Claims (15)
- 複数のデータ毎の情報を管理する主の管理テーブルを用いて、該主の管理テーブルに含まれるエントリを一定の規則に従うことなく記録した記録媒体から、必要な情報の読み出しを行うデータ管理方法において、
上記記録媒体から必要な情報を読み出す際には、上記主の管理テーブルに含まれる複数のエントリ分の累積情報を個々のエントリで管理する補助管理テーブルを用いることを特徴とするデータ管理方法。 - 上記補助管理テーブルが備えている各エントリは、上記主の管理テーブルの分割読み出しを行う複数のエントリ分の累積情報を管理していることを特徴とする請求項１に記載のデータ管理方法。
- 上記補助管理テーブルの各エントリは、上記累積情報が略等間隔で増加していくように、上記主の管理テーブルのエントリ数を区切って形成されていることを特徴とする請求項１に記載のデータ管理方法。
- 上記主の管理テーブルが分割読み出しの対象となっており、かつ該分割読み出しを行うエントリに対応する補助管理テーブルが存在しない場合には、補助管理テーブルを生成することを特徴とする請求項１に記載のデータ管理方法。
- 上記主の管理テーブルは、ＱｕｉｃｋＴｉｍｅファイルフォーマットであることを特徴とする請求項１〜４の何れか１項に記載のデータ管理方法。
- 上記補助管理テーブルは、時間に関する累積情報を管理していることを特徴とする請求項１〜５の何れか１項に記載のデータ管理方法。
- 上記補助管理テーブルは、サンプルおよびチャンクに関する累積情報を管理していることを特徴とする請求項１〜６の何れか１項に記載のデータ管理方法。
- 上記補助管理テーブルは、単独でデコード可能なサンプルに関する情報を管理していることを特徴とする請求項１〜７の何れか１項に記載のデータ管理方法。
- 複数のデータ毎の情報を管理する主の管理テーブルを用いて、該主の管理テーブルに含まれるエントリを一定の規則に従うことなく記録された記録媒体から、必要な情報の読み出しを行うデータ管理装置において、
上記記録媒体から必要な情報を読み出す際には、上記主の管理テーブルに含まれる複数のエントリ分の累積情報を個々のエントリで管理する補助管理テーブルを用いることを特徴とするデータ管理装置。 - 上記補助管理テーブルが備えている各エントリは、上記主の管理テーブルの分割読み出しを行う複数のエントリ分の累積情報を管理していることを特徴とする請求項９に記載のデータ管理装置。
- 上記補助管理テーブルの各エントリは、上記累積情報が略等間隔で増加していくように、上記主の管理テーブルのエントリ数を区切って形成されていることを特徴とする請求項９に記載のデータ管理装置。
- 上記主の管理テーブルが分割読み出しの対象となっており、かつ該分割読み出しを行うエントリに対応する補助管理テーブルが存在しない場合には、補助管理テーブルを生成することを特徴とする請求項９に記載のデータ管理装置。
- 上記主の管理テーブルは、ＱｕｉｃｋＴｉｍｅファイルフォーマットであることを特徴とする請求項９〜１２の何れか１項に記載のデータ管理装置。
- 請求項１〜８の何れか１項に記載のデータ管理方法を、コンピュータに実行させることを特徴とするデータ管理プログラム。
- 請求項１４のデータ管理プログラムを記録したことを特徴とするコンピュータ読み取り可能な記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002332837A JP2004171067A (ja) | 2002-11-15 | 2002-11-15 | データ管理方法およびデータ管理装置、データ管理プログラムならびにこれを記録した記録媒体 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002332837A JP2004171067A (ja) | 2002-11-15 | 2002-11-15 | データ管理方法およびデータ管理装置、データ管理プログラムならびにこれを記録した記録媒体 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004171067A true JP2004171067A (ja) | 2004-06-17 |
Family
ID=32697743
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002332837A Withdrawn JP2004171067A (ja) | 2002-11-15 | 2002-11-15 | データ管理方法およびデータ管理装置、データ管理プログラムならびにこれを記録した記録媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2004171067A (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2013034226A (ja) * | 2012-09-26 | 2013-02-14 | Canon Inc | 情報送信装置、その制御方法及びプログラム |
| CN111209305A (zh) * | 2019-11-19 | 2020-05-29 | 华为技术有限公司 | 查询数据的方法、数据节点、分布式数据库、计算设备 |
-
2002
- 2002-11-15 JP JP2002332837A patent/JP2004171067A/ja not_active Withdrawn
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2013034226A (ja) * | 2012-09-26 | 2013-02-14 | Canon Inc | 情報送信装置、その制御方法及びプログラム |
| CN111209305A (zh) * | 2019-11-19 | 2020-05-29 | 华为技术有限公司 | 查询数据的方法、数据节点、分布式数据库、计算设备 |
| CN111209305B (zh) * | 2019-11-19 | 2023-07-18 | 华为云计算技术有限公司 | 查询数据的方法、数据节点、分布式数据库、计算设备 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| TWI310545B (en) | Storage medium storing search information and reproducing apparatus | |
| EP1204974B1 (en) | A digital video processing and interface system for video, audio and ancillary data | |
| TWI223801B (en) | Apparatus and method for recording data to an information recording medium, and apparatus and method for reproducing data from an information recording medium | |
| US6493504B1 (en) | Storage medium, recording apparatus, playback apparatus, recording method, and computer-readable storage medium | |
| US20020108112A1 (en) | System and method for thematically analyzing and annotating an audio-visual sequence | |
| WO2001015168A1 (en) | A user interface and processing system for digital video, audio and ancillary data | |
| US6925245B1 (en) | Method and medium for recording video information | |
| JP2003061041A (ja) | 異なるフォーマットで記憶されたコンテンツセグメントの選択を指定するための方法とシステム | |
| CN1998050A (zh) | 用于播放多媒体播放列表的方法和装置及其存储介质 | |
| JP2001028722A (ja) | 動画像管理装置及び動画像管理システム | |
| CN101132508A (zh) | 记录与再现设备及方法,影像捕获与记录设备及方法 | |
| US8224819B2 (en) | Apparatus, method, and program for processing information | |
| JP3152651B2 (ja) | 情報記録媒体、情報記録媒体に情報を記録、再生する装置および方法 | |
| CN101154427B (zh) | 记录和再现装置及记录和再现方法 | |
| JP3285029B2 (ja) | 記録媒体 | |
| KR20080019013A (ko) | 저속 검색 저장 장치로부터의 그래픽 검색 | |
| JP3164111B2 (ja) | 記録方法、記録装置およびコンピュータ読み取り可能な記録媒体 | |
| JP3164107B2 (ja) | 記録媒体 | |
| KR20050041856A (ko) | 검색을 위한 메타 정보가 포함된 저장 매체, 재생 장치 및그 재생 방법 | |
| JP2002281433A (ja) | 動画像検索閲覧編集装置および記録媒体 | |
| WO2004112030A1 (ja) | 情報処理装置および方法、記録媒体、並びにプログラム | |
| KR100878528B1 (ko) | 동영상편집방법 및 그 장치 | |
| JP2004171067A (ja) | データ管理方法およびデータ管理装置、データ管理プログラムならびにこれを記録した記録媒体 | |
| JP3139497B1 (ja) | 再生装置、再生方法、およびコンピュータ読み取り可能な記録媒体 | |
| JP3329338B1 (ja) | 記録方法、記録装置およびコンピュータ読み取り可能な記録媒体 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A300 | Application deemed to be withdrawn because no request for examination was validly filed |
Free format text: JAPANESE INTERMEDIATE CODE: A300 Effective date: 20060207 |