(57)【要約】【課題】音楽コンテンツの著作権を保護しつつも、音楽コンテンツの編集を行うことができる半導体メモリカードを提供する。【解決手段】ＳＤメモリカードには、暗号化された複数のオーディオオブジェクト（ＡＯＢ）と、トラック情報（ＴＫＩ）とが記録されている。ＴＫＩにおける属性情報（ＴＫＩ＿ＢＬＫ＿ＡＴＲ）は、各ＡＯＢが、トラックの先頭部分、中間部分、終端部分、全体部分のいずれであるかを示し、ＴＫＩにおけるブロック情報（ＢＩＴ）は、各ＡＯＢの有効部分の開始位置を示すオフセットと、当該オフセットからの有効部分のデータ長とを示す。【選択図】　図１７
2004030586.tif 000002
【特許請求の範囲】
【請求項１】
プロテクト領域と非プロテクト領域とを備える半導体メモリカードであって、
プロテクト領域には、接続される機器と半導体メモリカードの間で互いの正当性が認証された場合のみ、当該機器によりアクセスできる領域であるとともに、複数の暗号鍵を所定の順序に配列してなる暗号鍵列が格納され、
非プロテクト領域には、複数の暗号化されたオーディオオブジェクトと、管理情報が格納され、
各オーディオオブジェクトは、固有識別情報を有し、再生すべき有効部分のみからなるものと、有効部分と共に、再生不要な無効部分をその先端及び／又は終端に含むものがあり、
各暗号鍵は、固有識別情報によって各オーディオオブジェクトと対応付けられるとともに、対応するオーディオオブジェクトを復号化し、
管理情報は、属性情報と、ブロック情報と、リンク情報と、プレイリストを含み、
属性情報は、各オーディオオブジェクトが、オーディオトラックの先頭部分、中間部分、終端部分、全体部分のいずれであるかを示し、
ブロック情報は、各オーディオオブジェクトの有効部分の開始位置を示すオフセットと、当該オフセットからの有効部分のデータ長とを示し、
リンク情報は、オーディオトラックの先頭部分又は中間部分を構成するオーディオオブジェクトについて、それらに後続される中間部分又は終端部分との接続関係を有するオーディオオブジェクトを示し、
プレイリストは、オーディオトラックの再生順序を示すとともに、各オーディオトラックにおけるオーディオオブジェクトの再生順序を示す、半導体メモリカード。
【請求項２】
前記オーディオトラックの再生には、オーディオオブジェクトの有効部分の再生をスキップすることなく行う通常再生と、オーディオオブジェクトの有効部分を所定の第１時間ずつスキップし、スキップの度に同有効部分の再生を所定の第２時間だけ行うオーディオトラックの間欠再生とがあり、
前記オーディオトラックは更に、複数のオーディオオブジェクトのそれぞれに１対１の比率で割り当てられた複数のエントリー位置情報を含み、
複数のエントリー位置情報は、オーディオオブジェクト内部の、第１時間おきの位置を示し、
前記ブロック情報は、
管理情報に示された格納位置と、前記複数のエントリー位置情報のうち最前のものとのオフセットと、当該オフセットからの有効部分のデータ長とを示す、請求項１記載の半導体メモリカード。
【請求項３】
請求項１記載の半導体メモリカードについての再生装置であって、
プレイリストに基づいて、再生すべきオーディオトラック内のオーディオオブジェクトを特定し、特定したオーディオオブジェクトを半導体メモリカードの非プロテクト領域から読み出す第１読み出し手段と、
接続される半導体メモリカードと再生装置の間で互いの正当性が認証された場合のみ、当該半導体メモリカードのプロテクト領域へのアクセスを許可する認証手段と、
認証手段で認証に成功した場合に、再生すべきオーディオオブジェクトに対応する暗号鍵をプロテクト領域から読み出す第２読み出し手段と、
読み出されたオーディオオブジェクトを、読み出された暗号鍵を用いて復号する復号手段と、
復号されたオーディオオブジェクトを前記オフセット位置から再生する再生手段とを備える、再生装置。
【請求項４】
複数のコンテンツより構成されるタイトルを請求項１記載の半導体メモリカードに記録する記録装置であって、
タイトルに含まれる複数のコンテンツのそれぞれに、複数の暗号鍵のそれぞれを割り当てて、割り当てられたそれぞれの暗号鍵を用いて各コンテンツを暗号化することにより、複数のオーディオオブジェクトを得る暗号化手段と、
複数の暗号鍵を暗号鍵列として半導体メモリカードのプロテクト領域に記録するとともに、暗号化された複数のオーディオオブジェクトを含む１つ以上のオーディオトラックと、管理情報とを半導体メモリカードの非プロテクト領域に記録する記録手段を備え、
前記管理情報は、属性情報と、ブロック情報と、リンク情報と、プレイリストを含み、
属性情報は、各オーディオオブジェクトが、オーディオトラックの先頭部分、中間部分、終端部分、全体部分のいずれであるかを示し、
ブロック情報は、各オーディオオブジェクトの有効部分の開始位置を示すオフセットと、当該オフセットからの有効部分のデータ長とを示し、
リンク情報は、オーディオトラックの先頭部分又は中間部分を構成するオーディオオブジェクトについて、それらに後続される中間部分又は終端部分との接続関係を有するオーディオオブジェクトを示し、
プレイリストは、オーディオトラックの再生順序を示すとともに、各オーディオトラックにおけるオーディオオブジェクトの再生順序を示す、記録装置。
【請求項５】
請求項１記載の半導体メモリカードについての再生手順をコンピュータに行わせるプログラムをコンピュータ読取可能な形式で記録している記録媒体であって、
プレイリストに基づいて、再生すべきオーディオトラック内のオーディオオブジェクトを特定し、特定したオーディオオブジェクトを半導体メモリカードの非プロテクト領域から読み出す第１読み出しステップと、
接続される半導体メモリカードとコンピュータの間で互いの正当性が認証された場合のみ、当該半導体メモリカードのプロテクト領域へのアクセスを許可する認証ステップと、
認証ステップで認証に成功した場合に、再生すべきオーディオオブジェクトに対応する暗号鍵をプロテクト領域から読み出す第２読み出しステップと、
読み出されたオーディオオブジェクトを、読み出された暗号鍵を用いて復号する復号ステップと、
復号されたオーディオオブジェクトを前記オフセット位置から再生する再生ステップと、
を含む手順をコンピュータに行わせるプログラムが記録されているコンピュータ読取可能な記録媒体。
【請求項６】
複数のコンテンツより構成されるタイトルを請求項１記載の半導体メモリカードに記録する手順をコンピュータに行わせるプログラムをコンピュータ読取可能な形式で記録している記録媒体であって、
装置外部からのタイトルの入力が開始されれば、タイトルに含まれる複数のコンテンツのそれぞれに、複数の暗号鍵のそれぞれを割り当てて、割り当てられたそれぞれの暗号鍵を用いて各コンテンツを暗号化することにより、複数のオーディオオブジェクトを得る暗号化ステップと、
複数の暗号鍵を暗号鍵列として半導体メモリカードのプロテクト領域に記録するとともに、暗号化された複数のオーディオオブジェクトを含む１つ以上のオーディオトラックと、管理情報を半導体メモリカードの非プロテクト領域に記録する記録ステップと
からなる手順をコンピュータに行わせるプログラムが記録されており、
前記管理情報は、属性情報と、ブロック情報と、リンク情報と、プレイリストを含み、
属性情報は、各オーディオオブジェクトが、オーディオトラックの先頭部分、中間部分、終端部分、全体部分のいずれであるかを示し、
ブロック情報は、各オーディオオブジェクトの有効部分の開始位置を示すオフセットと、当該オフセットからの有効部分のデータ長とを示し、
リンク情報は、オーディオトラックの先頭部分又は中間部分を構成するオーディオオブジェクトについて、それらに後続される中間部分又は終端部分との接続関係を有するオーディオオブジェクトを示し、
プレイリストは、オーディオトラックの再生順序を示すとともに、各オーディオトラックにおけるオーディオオブジェクトの再生順序を示す、コンピュータ読取可能な記録媒体。
【請求項７】
請求項１記載の半導体メモリカードを再生するコンピュータにおいて適用される再生方法であって、
プレイリストに基づいて、再生すべきオーディオトラック内のオーディオオブジェクトを特定し、特定したオーディオオブジェクトを半導体メモリカードの非プロテクト領域から読み出す第１読み出しステップと、
接続される半導体メモリカードとコンピュータの間で互いの正当性が認証された場合のみ、当該半導体メモリカードのプロテクト領域へのアクセスを許可する認証ステップと、
認証ステップで認証に成功した場合に、再生すべきオーディオオブジェクトに対応する暗号鍵をプロテクト領域から読み出す第２読み出しステップと、
読み出されたオーディオオブジェクトを、読み出された暗号鍵を用いて復号する復号ステップと、
復号されたオーディオオブジェクトを再生する再生ステップと
を含む、再生方法。
【請求項８】
複数のコンテンツより構成されるタイトルを請求項１記載の半導体メモリカードに記録する記録方法であって、
装置外部からのタイトルの入力が開始されれば、タイトルに含まれる複数のコンテンツのそれぞれに、複数の暗号鍵のそれぞれを割り当てて、割り当てられたそれぞれの暗号鍵を用いて各コンテンツを暗号化することにより、複数のオーディオオブジェクトを得る暗号化ステップと、
複数の暗号鍵を暗号鍵列として半導体メモリカードのプロテクト領域に記録するとともに、暗号化された複数のオーディオオブジェクトを含む１つ以上のオーディオトラックと、管理情報を半導体メモリカードの非プロテクト領域に記録する記録ステップと、を含み、
前記管理情報は、属性情報と、ブロック情報と、リンク情報と、プレイリストを含み、
属性情報は、各オーディオオブジェクトが、オーディオトラックの先頭部分、中間部分、終端部分、全体部分のいずれであるかを示し、
ブロック情報は、各オーディオオブジェクトの有効部分の開始位置を示すオフセットと、当該オフセットからの有効部分のデータ長とを示し、
リンク情報は、オーディオトラックの先頭部分又は中間部分を構成するオーディオオブジェクトについて、それらに後続される中間部分又は終端部分との接続関係を有するオーディオオブジェクトを示し、
プレイリストは、オーディオトラックの再生順序を示すとともに、各オーディオトラックにおけるオーディオオブジェクトの再生順序を示す、記録方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、オーディオデータ、制御データを格納する半導体メモリカードと、当該半導体メモリカードについての再生装置、記録装置、再生方法、記録方法、コンピュータ読み取り可能な記録媒体に関し、特に、電子音楽配信等のコンテンツ配信サービスにおいて、コンテンツとして配信されたオーディオデータ、管理情報を格納する場合の改良に関する。
【０００２】
【従来の技術】近年、電子音楽配信を実現するためのインフラストラクチャが整備されつつあり、ＣＤ，カセットテープ等のパッケージソフトの流通を主体としていた音楽業界は、壮大な変革期を迎えようとしている。
かかる電子音楽配信音楽コンテンツの引き渡しは、消費者が所有するコンピュータが、音楽会社のサーバコンピュータから音楽コンテンツをダウンロードすることにより実現される。電子音楽配信の利用者は、こうしてダウンロードにより入手した音楽コンテンツを持ち運ぼうとする場合、音楽コンテンツを可搬式の記録媒体に格納させねばならない。電子音楽配信により入手した音楽コンテンツの格納に最も適しているといわれているものが上述した半導体メモリカードである。
【０００３】
半導体メモリカードは、フラッシュＡＴＡカードやコンパクトフラッシュ（登録商標）カードと呼ばれるものが知られている。これら半導体メモリカードは、フラッシュメモリ（ＥＥＰＲＯＭ）と呼ばれる半導体デバイスを内蔵しており、ＭＤ，ＣＤ−Ｒ等と比較して、データの高速書き込みが可能であり、膨大なデータ長を有する音楽コンテンツの格納を短期間で完遂することができる。
【０００４】
その反面、電子音楽配信にて配信された音楽コンテンツが半導体メモリカードに格納されれば、半導体メモリカードに格納された音楽コンテンツを更にコピーすることにより、音楽著作物の不正な複製品が氾濫する恐れがある。特に半導体メモリカードは、ＣＤ−Ｒ，ＭＤと比較して、高速なデータ書き込みが可能であるので、複製品の氾濫は、より深刻化すると考えられる。そのような著作権者の不安を払拭するためには、電子音楽配信にて配信された音楽コンテンツを半導体メモリカードに格納する場合に、著作権者側の不安を払拭するような高度な暗号化方式で、音楽コンテンツを暗号化せねばならない。不正コピーを防止することを念頭においたコンテンツの格納方式の１つに、ＤＶＤ−Ａｕｄｉｏ規格のタイトル格納方式がある。音楽アプリケ−ションプログラムを一例にとるなら、タイトルとは、音楽アルバムに相当し、曲に該当するコンテンツを複数含む。タイトルを構成する複数コンテンツは、コンテンツはその製作者が定めた暗号鍵（一般にタイトル鍵と呼ばれる。）により暗号化された状態で、ＤＶＤ−Ａｕｄｉｏに記録される。タイトル鍵は、コンテンツが記録されたＤＶＤ−Ａｕｄｉｏについて固有な暗号鍵（一般にディスク鍵と呼ばれる。）を用いた暗号化を経てＤＶＤ−Ａｕｄｉｏにおけるセクタヘッダ領域に記録される。そのディスク鍵自身も、コンテンツのデコード装置を製作した製作会社が定めた暗号鍵（一般にマスタ鍵と呼ばれる。）を用いて、暗号化されてＤＶＤ−Ａｕｄｉｏのリードイン領域に記録される。これらセクタヘッダ領域と、リードイン領域は、一般ユーザがアクセスできない領域なので、ＤＶＤ−Ａｕｄｉｏに記録されたタイトル鍵を不正に取得することは、極めて困難になる。
【０００５】
また磁気式、光学式の記録媒体と比較して、半導体メモリカードはその容量が制限されていることが多いので、音楽コンテンツを半導体メモリカードに格納する際には、音楽コンテンツをより高度に圧縮しておく必要がある。そのような高圧縮率を得ることができる符号化方式の１つにＭＰＥＧ２−ＡＡＣ方式がある。ＭＰＥＧ２−ＡＡＣ方式の特徴は、人間の聴覚特性を考慮して、各オーディオフレーム（オーディオフレームとは、符号化、再生の最小単位となる時間帯であり、大体２０ｍｓｅｃの時間長に相当する）に割り当てるべきビット長を変化させる点にある。即ち、可聴帯域（人間が聞くことができる帯域）を多く有するオーディオフレームに多くのビット長を割り当て、不可聴帯域（人間が聞く事ができない帯域）を多く有するオーディオフレームには、割り当てるべきビット長を削減するのである。
【０００６】
このようにＭＰＥＧ２−ＡＡＣ方式は可聴帯域の含有量に応じてオーディオフレームに割り当てるべきビット長を変化させるので、言い換えれば可変長符号化方式であるので、高圧縮率且つ高音質な音楽コンテンツを得ることができる。高圧縮率且つ高音質な音楽コンテンツは、公衆ネットワークでの伝送に好適であり、容量が制限された半導体メモリカードに蓄積する場合に好適である。
【０００７】
尚、半導体メモリカードに関する先行技術文献には、以下の特許文献に記載されたものがある。
【０００８】
【特許文献１】
特開平０９−１０７５３６号公報
【特許文献２】
特開平０７−３１９６３５号公報
【特許文献３】
特開平１０−２６９２９０号公報
【特許文献４】
特開平１１−０４５５０７号公報
【０００９】
【発明が解決しようとする課題】
ところで、従来のコンテンツの格納方式では、その音楽コンテンツの暗号化に用いたタイトル鍵が解読されれば、その記録媒体に記録されている全ての音楽コンテンツの復号が可能になるので、いったんタイトル鍵が暴露されると、その半導体メモリカードに格納されている全ての曲が容易に復号化されてしまうという第１の問題点がある。そのような事態は頻繁に起こるとは言い難いが、希にでも発生すれば、それに起因して生じる著作権者の損害は、はかりしえないものとなる。特に、近年におけるコンピュータの処理能力の向上には目覚ましいものがあり、音楽コンテンツの暗号化に用いたタイトル鍵が解読されることは、完全に有り得ないとは断言し難い。万が一にでもタイトル鍵が暴露された場合に、著作権者の損害を最小限に留めるようなデータ構造は、従来技術には存在しないという問題点がある。
【００１０】
また、電子音楽配信において配信されるべき音楽コンテンツは、著作権を保護せねばならないので、暗号化された状態のまま音楽コンテンツを配信し、半導体メモリカードも、暗号化がなされたまま、音楽コンテンツを格納しておく必要がある。しかし暗号化された状態のまま音楽コンテンツを半導体メモリカードに格納した場合、正当な対価を支払って音楽コンテンツを入手した操作者から、音楽コンテンツを自由に編集する機会を奪ってしまうという第２の問題点がある
即ち、音楽コンテンツが暗号化されれば、曲の再生順序を入れ替えたり、また一部の曲を削除するという編集が困難となる。これは、電子音楽配信において正当な対価を支払って音楽コンテンツを入手した操作者からも音楽コンテンツを自由に編集する機会を奪う結果になる。
【００１１】
一方、半導体メモリカードと同じ音楽の録音用途に用いられるミニディスク（ＭＤ）の記録装置は、ＴＯＣ（Ｔａｂｌｅ　Ｏｆ　Ｃｏｎｔｅｎｓ）を用いて各曲にトラックという再生単位を割り当てることにより、各トラックの再生順序を入れ替えたり、トラックを分割したり、複数トラックを１つに統合するといった編集操作、いわゆるトラック編集を実現している。半導体メモリカードにおいてトラック編集が実現できないのでは、既存のミニディスクと比較して、機能的に見劣りすることになってしまい、現状のミニディスクのユーザに、半導体メモリカードの機能価値を強くアピールできないという問題点がある。
【００１２】
本発明の目的は、音楽コンテンツの著作権を保護しつつも、音楽コンテンツの編集を行うことができる半導体メモリカードを提供することである。
【００１３】
【課題を解決するための手段】
上記目的を達成するため、本発明に係る半導体メモリカードは、　　　プロテクト領域と非プロテクト領域とを備える半導体メモリカードであって、プロテクト領域には、接続される機器と半導体メモリカードの間で互いの正当性が認証された場合のみ、当該機器によりアクセスできる領域であるとともに、複数の暗号鍵を所定の順序に配列してなる暗号鍵列が格納され、非プロテクト領域には、複数の暗号化されたオーディオオブジェクトと、管理情報が格納され、各オーディオオブジェクトは、固有識別情報を有し、再生すべき有効部分のみからなるものと、有効部分と共に、再生不要な無効部分をその先端及び／又は終端に含むものがあり、各暗号鍵は、固有識別情報によって各オーディオオブジェクトと対応付けられるとともに、対応するオーディオオブジェクトを復号化し、　　　管理情報は、属性情報と、ブロック情報と、リンク情報と、プレイリストを含み、属性情報は、各オーディオオブジェクトが、オーディオトラックの先頭部分、中間部分、終端部分、全体部分のいずれであるかを示し、ブロック情報は、各オーディオオブジェクトの有効部分の開始位置を示すオフセットと、当該オフセットからの有効部分のデータ長とを示し、リンク情報は、オーディオトラックの先頭部分又は中間部分を構成するオーディオオブジェクトについて、それらに後続される中間部分又は終端部分との接続関係を有するオーディオオブジェクトを示し、プレイリストは、オーディオトラックの再生順序を示すとともに、各オーディオトラックにおけるオーディオオブジェクトの再生順序を示すことを特徴としている。
【００１４】
【発明の実施の形態】
以降、図面を参照しながら半導体メモリカード（フラッシュメモリカード）の実施形態について説明を行う。
尚、以降の各文には、その文頭に以下のような体系を有する分類番号を付している。
【００１５】
［ｘ１−ｘ２＿ｘ３−ｘ４］
分類番号の桁数は、その項目の階層的な深さを意味している。具体的にいうと、ｘ１は、説明に引用している図番である。本明細書に添付している図には、明細書において引用する順番に沿った番号を付しているので、この図番の順序が、説明の順序とほぼ同一となる。ｘ２は、ｘ１に示される図を引用して説明する場合の説明の順序を示す。ｘ３は、ｘ２の構成要素をより詳細に説明するために説明図を引用する場合、その説明図の図番を示し、ｘ４は、ｘ３に示される図を引用して説明する場合の説明の順序を示す。
【００１６】
（第１実施形態）
［１−１＿２］　　フラッシュメモリカード３１の外観形状
初めに、フラッシュメモリカード３１の外観形状について説明する。図１は、フラッシュメモリカード３１を上面から見た場合の形状示す図であり、図２は、フラッシュメモリカード３１をその下面から見た場合の構造を示す図である。図１、図２に示すように、フラッシュメモリカード３１の大きさは、長さが約３２．０ｍｍ、幅は約２４．０　ｍｍ、厚さ約２．０　ｍｍであり、指先で把持できる程度の大きさ（切手サイズの大きさ）である。下面には、機器との接続のための９本のコネクタが設けられており、側面には、記憶内容の上書きを許可するか禁止するかを操作者が設定することができるプロテクトスイッチ３２が設けられている。
【００１７】
［３−１］　　フラッシュメモリカード３１の物理構造
図３は、本実施形態に係る半導体メモリカード（以下、フラッシュメモリカード３１と称する）の階層構造を示す図である。本図に示すように、フラッシュメモリカード３１の階層構造は、物理層、ファイルシステム層、応用層からなる点で、ＤＶＤ（Ｄｉｇｉｔａｌ　Ｖｉｄｅｏ　Ｄｉｓｃ）の階層構造と同一であるが、各層における論理構造、物理構造は大きく相違する。
【００１８】
［３−２］　　フラッシュメモリカード３１の物理構造
先ずフラッシュメモリカード３１の物理層について説明する。フラッシュメモリは、複数のセクタからなり、各セクタは５１２バイトのディジタルデータを格納する。例えば６４ＭＢｙｔｅタイプのフラッシュメモリカード３１の場合、そのメモリー容量は、６７１０８８６４（＝６４×１０２４×１０２４）バイトであり、このときの有効セクタ数は１３１０７２（＝６７１０８８６４／５１２）となる。更に、この有効セクタからエラー用の代替セクタ数を差し引けば、残りの有効セクタ数は、１２８，０００となり、ここに各種データが記録されることなる。
【００１９】
［３−２＿４Ａ−１］　物理層における３つの領域
これら有効セクタからなる領域には、図４（ａ）に示す３つの領域が設けられる。図４（ａ）は、フラッシュメモリカード３１の物理層に設けられた『システム領域』、『プロテクト領域』、『ユーザデータ領域』を示す図である。以降、これら３つの領域について説明する。
【００２０】
『ユーザデータ領域』は、フラッシュメモリカード３１と接続された機器が様々なデータを自由に書き込むことができ、データを自由に読み出すことができる領域であり、その内部領域がファイルシステムにより管理されている。
『システム領域』は、フラッシュメモリカード３１のそれぞれについてユニークな値を持つメディアＩＤが格納される領域である。ユーザデータ領域が書込可能であるのに対して、システム領域は、読出専用であり、ここに格納されたメディアＩＤを書き換えることはできない。
【００２１】
『プロテクト領域』は、ユーザデータ領域同様、データ書き込みが可能な領域である。ユーザデータ領域との差違は、ユーザデータ領域では、データの読み書きが自由に行なえるのに対して、プロテクト領域では、フラッシュメモリカード３１と接続された機器と、フラッシュメモリカード３１とが互いの正当性を確認した場合のみ読み書きすることができる点、即ち、フラッシュメモリカード３１と接続された機器と、フラッシュメモリカード３１との相互認証が成功した場合のみ、読み書き可能となる点である。
【００２２】
［３−２＿４Ａ−２］　物理層における３つの領域の用途
フラッシュメモリカード３１に接続された機器がフラッシュメモリカード３１にデータを書き込む際、そのデータの著作権保護の要否に応じて、これら３つの領域は利用される。ここで、著作権の保護が必要なデータをフラッシュメモリカード３１に書き込む場合、当該データは、所定の暗号鍵（ＦｉｌｅＫｅｙと呼ばれる。）を用いて暗号化された後にユーザデータ領域に格納される。このＦｉｌｅＫｅｙは著作権者が自由に設定できるものであり、これだけでも、当該データの著作権は保護されるが、更に万全を期すため、この暗号化に用いたＦｉｌｅＫｅｙ自身も暗号化する。ＦｉｌｅＫｅｙ自身を暗号化する際、鍵として用いられるのは、システム領域に格納されているメディアＩＤを所定の演算式に適用することにより得られる任意の値であり、プロテクト領域は、当該任意の値を用いて暗号化されたＦｉｌｅＫｅｙを格納する。著作権保護が必要なデータは、所定のＦｉｌｅＫｅｙを用いて暗号化し、このＦｉｌｅＫｅｙ自身もメディアＩＤに基づいた値を用いて暗号化するという二段階の暗号化がなされるので、不正コピーなどの著作権侵害行為は、極めて困難になる。
【００２３】
［３−２＿４Ｂ−１］　ファイルシステムの概要
フラッシュメモリカード３１の物理層の構成は以上説明した通りであり、著作権保護の改良がなされていることがわかる。続いてこの物理層上に存在するファイルシステム層の構成について説明する。
ＤＶＤのファイルシステム層は、ＵＤＦ（ｕｎｉｖｅｒｓａｌ　ｄｉｓｋ　ｆｏｒｍａｔ）型のファイルシステムであるの対して、フラッシュメモリカード３１のファイルシステム層は、ＦＡＴ型のファイルシステム（ＦＡＴ：Ｆｉｌｅ　Ａｌｌｏｃａｔｉｏｎ　Ｔａｂｌｅ，ＩＳＯ／ＩＥＣ　９２９３）であり、この点がＤＶＤと異なる。
【００２４】
図４（ｂ）は、ファイルシステム層におけるプロテクト領域及びユーザデータ領域の構成を示す図である。図４（ｂ）においてファイルシステムにおけるプロテクト領域及びユーザデータ領域は、『パーティションブートセクタ』と、『ファイルアロケーションテーブル（ＦＡＴ）』と、『ルートディレクトリエントリ』と、『データ領域』とを含んでおり、プロテクト領域とユーザデータ領域は共に同じ構成となっていることがこの図からも明らかである。図５は、これらファイルシステム構成の詳細を示す図である。以降、ユーザデータ領域についての構成を図４、図５を参照しながら説明する。
【００２５】
［３−２＿４Ｂ−２］　パーティションブートセクタ
『パーティションブートセクタ』は、フラッシュメモリカード３１が汎用パーソナルコンピュータに装填され、当該汎用パーソナルコンピュータのオペレーティングシステムの起動ディスクにフラッシュメモリカード３１を割り当てられた場合、汎用パーソナルコンピュータがブート時に参照すべき内容が記載されているセクタである。
【００２６】
［３−２＿４Ｂ−３＿５］　データ領域
『データ領域』は、クラスタを最小単位にして、フラッシュメモリカード３１に接続された機器によりアクセスされる領域である。フラッシュメモリカード３１のセクタサイズが５１２バイトであるのに対して、クラスタサイズは、１６Ｋバイトであるので、ファイルシステム層では３２個のセクタを一単位として、データの読み書きが行われる。クラスタサイズを１６Ｋバイトとした理由は、以下の通りである。即ち、フラッシュメモリカード３１にデータを書き込む場合、当該フラッシュメモリカード３１に格納されているデータを一旦イレーズ（消去）してから、データ書き込みを行わねばならない。フラッシュメモリカード３１において、そのようにデータをイレーズできるサイズは、１６Ｋバイトであるので、このイレーズ可能なサイズにクラスタサイズを設定することにより、データ書き込みが好適に行われるようにしている。図５における破線の引き出し線ｆｆ２は、データ領域に含まれる複数のクラスタ００２，００３，００４，００５・・・・・を示す。図中の番号００２，００３，００４，００５，００６，００７，００８・・・・・・・は、各クラスタを識別するために付与された３桁の１６進数表記のクラスタ番号を示す。データ領域に対するアクセスは、クラスタを最小単位として行われるので、データ領域の内部位置は、これらのクラスタ番号を用いて、指示される。
【００２７】
［３−２＿４Ｂ−４＿５］　ファイルアロケーションテーブル
『ファイルアロケーションテーブル』は、ＩＳＯ／ＩＥＣ　９２９３に準拠したファイルシステム構造を有しており、複数のＦＡＴ値からなる。各ＦＡＴ値は各クラスタに対応づけられており、対応するクラスタが読み出された場合、次にどのクラスタを読み出せばよいかを示す。図５の破線の引き出し線ｆｆ１は、ファイルアロケーションテーブルに含まれる複数のＦＡＴ値００２，００３，００４，００５・・を示す。このＦＡＴ値に付与された数値『００２，００３，００４，００５・・』は、各ＦＡＴ値がどのクラスタに対応づけられているか、つまり、各ＦＡＴ値が対応づけられているクラスタのクラスタ番号を示す。
【００２８】
［３−２＿４Ｂ−５＿５−１］　ルートディレクトリエントリ
『ルートディレクトリエントリ』は、ルートディレクトリにどのようなファイルが存在するかを示す情報である。具体的にいうと、ルートディレクトリエントリーには、存在するファイルの『ファイル名』と、そのファイルの『拡張子』と、『ファイル属性』と、ファイルの『更新時刻及び年月日』と、ファイルの先頭部が格納されている『ファイル最初のクラスタ番号』とが記載されている。
【００２９】
［３−２＿４Ｂ−５＿５−２］　サブディレクトリのディレクトリエントリ
ルートディレクトリにあるファイルについての情報は、このルートディレクトリエントリーに記載されるが、サブディレクトリについての情報は、このルートディレクトリエントリーには記載されない。サブディレクトリについてのディレクトリエントリーは、データ領域内に作成される。図５のデータ領域内に記載されたＳＤ＿Ａｕｄｉｏディレクトリエントリーは、サブディレクトリについてのディレクトリエントリーの一例であり、本ＳＤ＿Ａｕｄｉｏディレクトリエントリーは、ルートディレクトリエントリー同様、そのサブディレクトリに存在するファイルの『ファイル名』と、そのファイルの『拡張子』と、『ファイル属性』と、ファイルの『更新時刻及び年月日』と、ファイルの先頭部が格納されている『ファイル最初のクラスタ番号』とが記述される。
【００３０】
［３−２＿４Ｂ−５＿６−１］　ＡＯＢファイルの格納方式
ここで、ＳＤ＿ＡｕｄｉｏディレクトリにＡＯＢ００１．ＳＡ１というファイルを格納する場合、ＡＯＢ００１．ＳＡ１がどのように格納されるか、即ち、ファイル格納方式の一例を図６を参照しながら説明する。上述したようにデータ領域の最小アクセス単位はクラスタであるので、ＡＯＢ００１．ＳＡ１は、クラスタサイズを最小単位にしてデータ領域に格納せねばならない。ＡＯＢ００１．ＳＡ１は、先ずクラスタサイズに分割されて、各クラスタに書き込まれる。図６は、ＡＯＢ００１．ＳＡ１をクラスタサイズに合わせて５つに分割し、各分割部分を、クラスタ００３，００４，００５，００Ａ，００Ｃに格納する状態を想定した図である。
【００３１】
［３−２＿４Ｂ−５＿７−１］　ＡＯＢファイルの格納方式
ＡＯＢ００１．ＳＡ１が分割格納されると、ディレクトリエントリー及びファイルアロケーションテーブルは、図７のように設定されねばならない。
図７は、ＡＯＢ００１．ＳＡ１が複数のクラスタに記録されている場合のディレクトリエントリー及びファイルアロケーションテーブルについての設定例を示す図である。本図においてＡＯＢ００１．ＳＡ１の先頭部分がクラスタ００３に記録されている場合、ＳＤ＿Ａｕｄｉｏディレクトリエントリーにおける『最初のクラスタ番号』には、その先頭部分が格納されているクラスタについてのクラスタ番号００３が記載される。以降、ＡＯＢ００１．ＳＡ１の後続する部分は、クラスタ００４、クラスタ００５に格納されていることがわかる。ＡＯＢ００１．ＳＡ１の先頭部分を格納しているクラスタ００３には、ＦＡＴ値００３（００４）が対応しているが、このＦＡＴ値は、ＡＯＢファイルの後続する部分を格納しているクラスタ００４を示すものである。またこれに後続している部分を格納しているクラスタ００４，００５には、ＦＡＴ値００４（００５），ＦＡＴ値００５（００Ａ）が対応しているが、これのＦＡＴ値は、ＡＯＢファイルの次の後続する部分を格納しているクラスタ００５，００Ａを示すものである。
【００３２】
これらＦＡＴ値に記載されたクラスタ番号を矢印ｆｋ１，ｆｋ２，ｆｋ３，ｆｋ４，ｆｋ５・・・・・に示すように順次読みとってゆけば、ＡＯＢ００１．ＳＡ１の分割部分を全て読み取ることができる。以上の説明により、フラッシュメモリカード３１のデータ領域は、クラスタを最小単位としてアクセスされ、また各クラスタにはそれぞれＦＡＴ値が対応づけられていることがわかる。尚、ＡＯＢファイルの末尾の部分を格納したクラスタ（図７の一例では、クラスタ００Ｃ）に対応づけられているＦＡＴ値には、そのクラスタがファイルの最終部分を格納していることを示すクラスタ番号『ＦＦＦ』が記述される。
【００３３】
以上で、本発明のフラッシュメモリカード３１のファイルシステムに関する説明を終え、続いて、上述したファイルシステム上に存在する応用層の構成について説明する。
［３−３］　　フラッシュメモリカード３１における応用層の概要
フラッシュメモリカード３１における応用層の概要は、図３に記載された通りである。図３における破線の引き出し線ＰＮ１に示すようにフラッシュメモリカード３１における応用層は、プレゼンテーションデータと、プレゼンテーションデータの再生を制御するためのナビゲーションデータとからなる。
【００３４】
本図の破線の引き出し線ＰＮ２に示すように、プレゼンテーションデータは、音楽等の音声データをエンコードすることにより得られたオーディオオブジェクト群（ＡＯＢ群）を含み、ナビゲーションデータは、プレイリストマネージャー（ＰｌａｙｌｉｓｔＭａｎａｇｅｒ（ＰＬＭＧ））と、トラックマネージャー（Ｔｒａｃｋ　Ｍａｎａｇｅｒ（ＴＫＭＧ））とを含む。
［３−３＿８Ａ，Ｂ−１］　ディレクトリ構成
図８（ａ）、（ｂ）は、応用層におけるこれら２つのデータを格納する場合、ファイルシステム層においてユーザデータ領域及びプロテクト領域には、どのようなディレクトリが構成され、どのようなファイルが当該ディレクトリの配下に作成されるかを示す図である。本図における『ＳＤ＿ＡＵＤＩＯ．ＰＬＭ』、『ＳＤ＿ＡＵＤＩＯ．ＴＫＭ』は、プレイリストマネージャー（ＰｌａｙｌｉｓｔＭａｎａｇｅｒ（ＰＬＭＧ））、トラックマネージャー（Ｔｒａｃｋ　Ｍａｎａｇｅｒ（ＴＫＭＧ））といったナビゲーションデータを収録したファイルであり、『ＡＯＢ００１．ＳＡ１』『ＡＯＢ００２．ＳＡ１』『ＡＯＢ００３．ＳＡ１』『ＡＯＢ００４．ＳＡ１』・・・・・は、プレゼンテーションデータであるオーディオオブジェクトを格納したファイル（以下、ＡＯＢファイルという）である。
【００３５】
『ＡＯＢ０ｘｘ．ＳＡ１』における拡張子『ＳＡ』は、『Ｓｅｃｕｒｅ　Ａｕｄｉｏ』の略であり、これらの格納内容は、著作権保護の必要性があることを示す（尚、図８（ａ）にはＡＯＢファイルが８個だけ記述されているが、これは単なる一例であり、ＳＤ＿ＡｕｄｉｏディレクトリはＡＯＢファイルを最大９９９個まで格納することができる。）。このようにプレゼンテーションデータに著作権保護の必要性がある場合、プロテクト領域には、ＳＤ＿Ａｕｄｉｏディレクトリという名称のサブディレクトリが設けられ、そのＳＤ＿Ａｕｄｉｏディレクトリの配下に暗号鍵格納ファイルＡＯＢＳＡ１．ＫＥＹが作成される。図８（ｂ）は、ＳＤ＿Ａｕｄｉｏの下に格納された暗号鍵格納ファイルＡＯＢＳＡ１．ＫＥＹを示す図である。暗号鍵格納ファイルＡＯＢＳＡ１．ＫＥＹには、複数の暗号鍵ＦｉｌｅＫｅｙを所定の順序に配列してなる暗号鍵列であるＦｉｌｅＫｅｙ＃１〜＃８が格納されている。
【００３６】
電子音楽配信において音楽会社のサーバコンピュータは、この図８（ａ）、（ｂ）に示すＳＤ＿Ａｕｄｉｏディレクトリを保持しており、当該音楽コンテンツの購入要求が消費者から発せられれば、このＳＤ＿Ａｕｄｉｏディレクトリを圧縮し、暗号化した後、購入要求を発した消費者が所有するＳＤ＿Ａｕｄｉｏディレクトリを公衆ネットワークを介して送信する。消費者が所有するコンピュータがこのＳＤ＿Ａｕｄｉｏディレクトリを受信すると、このディレクトリの暗号化を解除すると共に、伸長を行い、ＳＤ＿Ａｕｄｉｏディレクトリを得る（尚、ここでいう公衆ネットワークは、ＩＳＤＮ回線等の有線通信網、携帯電話に代表される無線通信網等、公衆に利用が解放されている全てのネットワークを含む）。尚、ＡＯＢファイルを音楽会社のサーバコンピュータからダウンロードし、消費者が所有するコンピュータが、フラッシュメモリカード３１においてこの図８（ａ）、（ｂ）に示すＳＤ＿Ａｕｄｉｏディレクトリを作成しても良い。
【００３７】
［３−３＿９−１］　　ＡＯＢＳＡ１．ＫＥＹと、ＡＯＢファイルとの対応
図９は、ＳＤ＿Ａｕｄｉｏの下にあるＡＯＢＳＡ１．ＫＥＹと、ＡＯＢファイルとの対応を示す図である。本図においてユーザデータ領域における暗号化ファイルを暗号化する際に用いたＦｉｌｅＫｅｙは、プロテクト領域に対応する暗号鍵格納ファイルに格納される。
【００３８】
暗号化されたＡＯＢファイルと、暗号鍵格納ファイルとは、以下の一定の規則（１）（２）（３）に基づく対応関係を有する。
（１）暗号鍵格納ファイルは、暗号化されたファイルが格納されているディレクトリと同じディレクトリ名に配置される。図９のユーザデータ領域においてＳＤ＿ＡｕｄｉｏディレクトリにＡＯＢファイルが配されており、暗号鍵格納ファイルもＳＤ＿Ａｕｄｉｏディレクトリに配されていることからも、この規則に従った、ファイル配置が行われていることがわかる。
【００３９】
（２）暗号鍵格納ファイルには、データ領域におけるＡＯＢファイルのファイル名の先頭３文字と、所定の拡張子「．ｋｅｙ」とを組み合わせたファイル名が付与される。ＡＯＢファイルのファイル名が『ＡＯＢ００１．ＳＡ１』である場合、暗号鍵格納ファイルには、矢印ｎｋ１，ｎｋ２に示すように、この先頭３文字『ＡＯＢ』と、『ＳＡ１』と、拡張子『．ｋｅｙ』とからなる『ＡＯＢＳＡ１．ＫＥＹ』というファイル名が付与されることがわかる。
【００４０】
（３）　ＡＯＢファイルのファイル名には、暗号鍵格納ファイル内の暗号鍵列において、そのオーディオオブジェクトに対応するＦｉｌｅｋｅｙが何番目に位置するか、即ち、対応するＦｉｌｅＫｅｙの順位を示すシリアル番号が付与される。
図９における暗号鍵格納ファイル内の『Ｆｉｌｅ　Ｋｅｙ　Ｅｎｔｒｙ＃１，＃２，＃３・・・・・＃８』は、暗号鍵格納ファイル内の各ＦｉｌｅＫｅｙが格納されている領域の先頭位置を示す。一方ＡＯＢファイルのファイル名には、”００１”，”００２”，”００３”，”００４”といったシリアル番号が付与されている。これらのＡＯＢファイル内のシリアル番号は、対応するＦｉｌｅＫｅｙが暗号鍵列において何番目に位置するかを意味するので、各ＡＯＢファイルを暗号化する際に用いたＦｉｌｅＫｅｙは、同一のシリアル番号を有する『Ｆｉｌｅ　Ｋｅｙ　Ｅｎｔｒｙ』に存在することなる。図９における矢印ＡＫ１，ＡＫ２，ＡＫ３は、ＡＯＢファイルとＦｉｌｅＫｅｙとの対応関係を示す。即ち、ユーザデータ領域におけるＡＯＢ００１．ＳＡ１は『Ｆｉｌｅ　Ｋｅｙ　Ｅｎｔｒｙ＃１』に格納されているＦｉｌｅＫｅｙと対応しており、ＡＯＢ００２．ＳＡ１は、『Ｆｉｌｅ　Ｋｅｙ　Ｅｎｔｒｙ＃２』以降に格納されたＦｉｌｅＫｅｙ、ＡＯＢ００３．ＳＡ１は『Ｆｉｌｅ　Ｋｅｙ　Ｅｎｔｒｙ＃３』以降に格納されたＦｉｌｅＫｅｙに対応していることを示す。以上の（３）からもわかるように、ＡＯＢファイルの暗号化に用いたＦｉｌｅＫｅｙは、各ファイル毎に異なるものであり、それらは、ファイル名に組み込まれている”００１”，”００２”，”００３”，”００４”といったシリアル番号と、同一のシリアル番号を有する『Ｆｉｌｅ　Ｋｅｙ　Ｅｎｔｒｙ』に格納されている。各ＡＯＢファイルは異なるＦｉｌｅＫｅｙを用いて暗号化されるので、仮に、特定のＡＯＢファイルの暗号化キーが暴露された場合でも、他のＡＯＢファイルは、暴露されたＦｉｌｅＫｅｙを用いても暗号化を解除することはできない。これにより、ＡＯＢファイルを暗号化した際のＦｉｌｅＫｅｙが暴露された場合の損害を最小限に留めることができる。
【００４１】
［３−３＿１０−１］　ＡＯＢファイルの内部構成
続いてＡＯＢファイルの内部構成について説明する。図１０は、ＡＯＢファイルのデータ構成を階層的に示す図である。本図の第１段目は、ＡＯＢファイルを示し、第２段目は、ＡＯＢを示す。第３段目は、ＡＯＢ＿ＢＬＯＣＫを示し、第４段目はＡＯＢ＿ＥＬＥＭＥＮＴ、第５段目は、ＡＯＢ＿ＦＲＡＭＥを示す。
【００４２】
図１０の第５段目における『ＡＯＢ＿ＦＲＡＭＥ』は、ＡＯＢを構成する最小単位であり、ＡＤＴＳヘッダと、ＡＤＴＳ（Ａｕｄｉｏ　Ｄａｔａ　Ｔｒａｎｓｐｏｒｔ　Ｓｔｒｅａｍ）形式のオーディオデータとからなる。ＡＤＴＳ形式のオーディオデータは、ＭＰＥＧ２−ＡＡＣ　［　Ｌｏｗ　Ｃｏｍｐｌｅｘｉｔｙ　Ｐｒｏｆｉｌｅ］にて符号化され、１６Ｋｂｐｓ〜１４４Ｋｂｐｓの伝送速度で再生されるストリームデータである（尚、既存のコンパクトディスクに記録されるＰＣＭデータの伝送速度は１．５Ｍｂｐｓであるので、ＰＣＭデータと比較して、一段と低いことがわかる。）。これらのＡＯＢ＿ＦＲＡＭＥ列のデータ構造は、電子音楽配信にて配信されるオーディオデータトランスポートに含まれるオーディオフレーム列と同一である。即ち、ＡＯＢ＿ＦＲＡＭＥ列として格納されるべきオーディオデータトランスポートストリームは、ＭＰＥＧ２−ＡＣＣにてエンコードされ、更に暗号化された状態で、公衆ネットワークを伝送し、消費者宛に伝送される。ＡＯＢファイルは、そのように伝送されたオーディオデータトランスポートストリームを、ＡＯＢ＿ＦＲＡＭＥ列として分割して格納しているのである。
【００４３】
｛３−３＿１０−１＿１１｝ＭＰＥＧ２−ＡＡＣについて
ＭＰＥＧ２−ＡＡＣの詳細に関しては、ＩＳＯ／ＩＥＣ　１３８１８−７：１９９７（Ｅ）　Ｉｎｆｏｒｍａｔｉｏｎ　ｔｅｃｈｎｏｌｏｇｙ　−　Ｇｅｎｅｒｉｃ　ｃｏｄｉｎｇ　ｏｆ　ｍｏｖｉｎｇ　ｐｉｃｔｕｒｅｓ　ａｎｄ　ａｓｓｏｃｉａｔｅｄ　ａｕｄｉｏ　ｉｎｆｏｒｍａｔｉｏｎ−　Ｐａｒｔ７　Ａｄｖａｎｃｅｄ　Ａｕｄｉｏ　Ｃｏｄｉｎｇ　（ＡＡＣ）を参照されたい。ここで注意すべきは、ＡＯＢは、ＩＳＯ／ＩＥＣ１３８１８−７に記述されているパラメータ表を図１１（ａ）のように制限して適用されたＭＰＥＧ２−ＡＡＣ方式にて圧縮されている点である。図１１（ａ）は、ＩＳＯ／ＩＥＣ１３８１８−７に記述されているパラメータ表を示す図であり、Ｐａｒａｍｅｔｅｒ欄と、Ｖａｌｕｅ欄と、Ｃｏｍｍｅｎｔ欄の内容を示すコメント欄とからなる。
【００４４】
パラメータ欄『ｐｒｏｆｉｌｅ』は、ＩＳＯ／ＩＥＣ　１３８３８−７で規定されているＬＣ−ｐｒｏｆｉｌｅの制限が適用されていることを示す。
パラメータ欄『ｓａｍｐｌｉｎｇ＿ｆｒｅｑｕｅｎｃｙ＿ｉｎｄｅｘ』は、『４８ｋＨｚ，４４．１ｋＨｚ，３２ｋＨｚ，２４ｋＨｚ，２２．０５ｋＨＺ，１６ｋＨｚ』といったサンプリング周波数が適用されていることを示す。パラメータ欄『ｎｕｍｂｅｒ＿ｏｆ＿ｄａｔａ＿ｂｌｏｃｋ＿ｉｎ＿ｆｒａｍｅ』は、１ｈｅａｄｅｒ／１ｒａｗ＿ｄａｔａ＿ｂｌｏｃｋに設定されていることを示す。
【００４５】
尚、ＡＯＢ＿ＦＲＡＭＥは、ＭＰＥＧ−ＡＡＣ方式にて符号化されているものとして説明したが、ＡＯＢ＿ＦＲＡＭＥは、ＭＰＥＧ−Ｌａｙｅｒ３（ＭＰ３）方式、Ｗｉｎｄｏｗｓ（登録商標）　Ｍｅｄｉａ　Ａｕｄｉｏ（ＷＭＡ方式等他の符号化方式にて符号化されてもよい。この際、図１１（ａ）に示したパラメータの代わりに、図１１（ｂ）、図１１（ｃ）に示すパラメータ表を用いねばならない。
【００４６】
［３−３＿１０−２＿１２］　　ＡＯＢ＿ＦＲＡＭＥの構成
『ＡＯＢ＿ＦＲＡＭＥ』は、以上の制限下で符号化されたオーディオデータを含むが、ＡＯＢ＿ＦＲＡＭＥに含まれるオーディオデータのデータ長は、その再生時間が２０ミリ秒となるデータに過ぎない。しかし、ＭＰＥＧ２−ＡＡＣ方式は可変長符号化方式であるので、各ＡＯＢ＿ＦＲＡＭＥに含まれるオーディオデータのデータ長は、それぞれのＡＯＢ＿ＦＲＡＭＥ毎に異なる。以下、図１２を参照しながら、ＡＯＢ＿ＦＲＡＭＥの構成の詳細について説明する。本図の第１段目は、ＡＯＢ＿ＦＲＡＭＥの全体構成を示し、第２段目は、ＡＯＢ＿ＦＲＡＭＥのそれぞれの部位がどのように暗号化されているかを示す。この第２段目を参照すれば、ＡＤＴＳヘッダは、非暗号化部、即ち、暗号化がなされていないことがわかる。また、オーディオデータは、暗号化された部分と、非暗号化部分との双方を含む。暗号化部分は、８バイトの暗号化データを複数配したものである。８バイトの暗号化データは、６４ビットの元データを５６ビットのＦｉｌｅＫｅｙを用いて暗号化することにより生成されている。非暗号化部分は、そのように６４ビット単位に暗号化が行われた際、６４ビットに満たないために暗号化されずに残したものである。
【００４７】
第３段目は、非暗号化部分であるＡＤＴＳヘッダの内容を示す図である。ＡＤＴＳヘッダは７バイトであり、１２ビットの同期ワード（ＦＦＦと設定されている）と、同じＡＯＢ＿ＦＲＡＭＥに含まれるオーディオデータのデータ長と、そのオーディオデータをエンコードする際のサンプリング周波数とが記載されている。
［３−３＿１０−３＿１３］　　ＡＯＢ＿ＦＲＡＭＥのバイト長設定
図１３は、３つのＡＯＢ＿ＦＲＡＭＥにおいて、それぞれのＡＯＢ＿ＦＲＡＭＥにおけるオーディオデータのバイト長がどのように設定されるかを示す図である。本図において、ＡＯＢ＿ＦＲＡＭＥ＃１に含まれるオーディオデータ＃１のデータ長はｘ１、ＡＯＢ＿ＦＲＡＭＥ＃２に含まれるオーディオデータ＃２のデータ長はｘ２、ＡＯＢ＿ＦＲＡＭＥ＃３に含まれるオーディオデータ＃３のデータ長はｘ３であり、ｘ１，ｘ２，ｘ３というようにそれぞれのデータ長が互いに異なる場合、ＡＯＢ＿ＦＲＡＭＥ＃１に含まれるＡＤＴＳヘッダには、データ長ｘ１が記載され、ＡＯＢ＿ＦＲＡＭＥ＃２に含まれるＡＤＴＳヘッダには、データ長ｘ２、ＡＯＢ＿ＦＲＡＭＥ＃３に含まれるＡＤＴＳヘッダには、データ長ｘ３が記載される。オーディオデータそのものは、暗号化されているが、ＡＤＴＳヘッダ自体は暗号化されていないので、各ＡＯＢ＿ＦＲＡＭＥにおけるＡＤＴＳヘッダから、オーディオデータのデータ長を読み取ってゆけば、後続するＡＯＢ＿ＦＲＡＭＥがどこから存在するかを知得することができる。以上でＡＯＢ＿ＦＲＡＭＥについての説明を終える。
【００４８】
［３−３＿１０−４］　ＡＯＢ＿ＥＬＥＭＥＮＴについて
続いて図１０において第４段目に位置するＡＯＢ＿ＥＬＥＭＥＮＴについて説明する。
『ＡＯＢ＿ＥＬＥＭＥＮＴ』は、連続する複数のＡＯＢ＿ＦＲＡＭＥの集合である。ここで、どれだけの数のＡＯＢ＿ＦＲＡＭＥがＡＯＢ＿ＥＬＥＭＥＮＴに含まれるかは、図１１（ａ）に示したｓａｍｐｌｉｎｇ＿ｆｒｅｑｕｅｎｃｙ＿ｉｎｄｅｘの設定と、符号化方式とに従って変化する。即ち、ＡＯＢ＿ＥＬＥＭＥＮＴに含まれるＡＯＢ＿ＦＲＡＭＥの個数は、そのＡＯＢ＿ＥＬＥＭＥＮＴに含まれるＡＯＢ＿ＦＲＡＭＥの再生時間が大体２秒になるように定められており、サンプリング周波数と、符号化方式に応じて、異なる個数となる。
【００４９】
［３−３＿１０−５＿１４］　　ＡＯＢ＿ＥＬＥＭＥＮＴに含まれるＡＯＢ＿ＦＲＡＭＥ数
図１４は、ｓａｍｐｌｉｎｇ＿ｆｒｅｑｕｅｎｃｙと、ＡＯＢ＿ＥＬＥＭＥＮＴに含まれるＡＯＢ＿ＦＲＡＭＥ数との対応を示す図である。本図においてＮはＡＯＢ＿ＥＬＥＭＥＮＴの再生期間を秒単位に示したものであり、符号化方式がＭＰＥＧ−ＡＡＣ方式であれば”２”となる。またｓａｍｐｌｉｎｇ＿ｆｒｅｑｕｅｎｃｙが４８ｋＨｚである場合、ＡＯＢ＿ＥＬＥＭＥＮＴに含まれるフレーム数は、９４（＝４７×２）個となり、ｓａｍｐｌｉｎｇ＿ｆｒｅｑｕｅｎｃｙが４４．１ｋＨｚである場合、ＡＯＢ＿ＥＬＥＭＥＮＴに含まれるフレーム数は８６（＝４３×２）個、ｓａｍｐｌｉｎｇ＿ｆｒｅｑｕｅｎｃｙが３２ｋＨｚである場合、ＡＯＢ＿ＥＬＥＭＥＮＴに含まれるフレーム数は６４（＝３２×２）個、ｓａｍｐｌｉｎｇ＿ｆｒｅｑｕｅｎｃｙが２４ｋＨｚである場合、フレーム数は４８（＝２４×２）個、ｓａｍｐｌｉｎｇ＿ｆｒｅｑｕｅｎｃｙが２２．０５ｋＨｚである場合、ＡＯＢ＿ＥＬＥＭＥＮＴに含まれるフレーム数は４４（＝２２×２）個、ｓａｍｐｌｉｎｇ＿ｆｒｅｑｕｅｎｃｙが１６ｋＨｚである場合、ＡＯＢ＿ＥＬＥＭＥＮＴに含まれるフレーム数は３２（＝１６×２）個となる。但し、ＡＯＢを分割などの編集を行った場合、ＡＯＢの先頭と最後のＡＯＢ＿ＥＬＥＭＥＮＴのＡＯＢ＿ＦＲＡＭＥ数は、図１４の個数より少なくなる場合がある。
【００５０】
ＡＯＢ＿ＥＬＥＭＥＮＴには、ヘッダ等の特別な情報は付与されていないが、その代わりにそのデータ長がタイムサーチテーブルに示されている。
［３−３＿１０−６＿１５］　　ＡＯＢ＿ＥＬＥＭＥＮＴ及びＡＯＢ＿ＦＲＡＭＥの時間長の一例
図１５は、ＡＯＢ＿ＥＬＥＭＥＮＴの時間長及びＡＯＢ＿ＦＲＡＭＥの時間長の一例を示す図である。本図の第１段目は、複数ＡＯＢ＿ＢＬＯＣＫの並びであり、第２段目は、複数ＡＯＢ＿ＥＬＥＭＥＮＴの並びを示す。第３段目は、複数ＡＯＢ＿ＦＲＡＭＥの並びを示す。
【００５１】
本図を参照すると、ＡＯＢ＿ＥＬＥＭＥＮＴは、約２．０秒という再生時間長に相当し、本図におけるＡＯＢ＿ＦＲＡＭＥは、２０ｍｓｅｃという再生時間長に対応することが判る。ＡＯＢ＿ＥＬＥＭＥＮＴのそれぞれに付されている『ＴＭＳＲＴ＿ｅｎｔｒｙ』という文字列は、各ＡＯＢ＿ＥＬＥＭＥＮＴのデータ長がタイムサーチテーブルに記載されていることを示す。このようなＴＭＳＲＴ＿ｅｎｔｒｙを参照して、順方向サーチ再生、逆方向サーチ再生を行うことにより、例えば２．０秒をスキップして、２４０ミリ秒分だけ再生するという間欠な再生を実現することができるのである。
【００５２】
［３−３＿１０−７］　ＡＯＢ＿ＢＬＯＣＫについて
以上でＡＯＢ＿ＥＬＥＭＥＮＴについての説明を終え、続いてＡＯＢ＿ＥＬＥＭＥＮＴの上位、即ち、図１０のＡＯＢファイルのデータ構成を示す図における第３段目に位置するのＡＯＢ＿ＢＬＯＣＫについて説明する。
『ＡＯＢ＿ＢＬＯＣＫ』は、有効なＡＯＢ＿ＥＬＥＭＥＮＴからなる領域であり、ＡＯＢファイル中に一つ存在する。ＡＯＢ＿ＥＬＥＭＥＮＴが２秒という再生時間に相当するのに対して、ＡＯＢ＿ＢＬＯＣＫは８．４分の再生時間を上限とした再生時間に相当する。各ＡＯＢを８．４分の再生時間に限定した理由は、ＡＯＢ＿ＢＬＯＣＫに含まれるＡＯＢ＿ＥＬＥＭＥＮＴの個数を制限することにより、タイムサーチテーブルのサイズを５０４バイト以下に抑制するためである。
【００５３】
［３−３＿１０−８］　タイムサーチテーブルの抑制
以下、再生時間の限定により、タイムサーチテーブルの抑制が可能となった理由を詳細に説明する。
順方向サーチ再生、逆方向サーチ再生の再生を行う際、２秒分読み出しをスキップして２４０ミリ秒だけ再生するという『２秒スキップ２４０ミリ秒再生』が行われる。このように２秒という時間長をスキップする場合、原則として、ＡＯＢ＿ＦＲＡＭＥのＡＤＴＳヘッダに示されているデータ長を順次参照してゆけばよいのだが、その場合、２秒という時間間隔をスキップするために１００個（＝２秒／２０ミリ秒）ものＡＯＢ＿ＦＲＡＭＥを順次検出せねばならず、再生装置に余分な処理負荷を与えてしまう。そのような処理負荷を軽減するには、その２秒間隔の読出先アドレスをタイムサーチテーブルに記述して、順方向サーチ再生及び逆方向サーチ再生が命じられた際、再生装置がこれを参照すればよい。即ち、タイムサーチテーブルには、２秒先、４秒先の読出先アドレスを算出するための情報、具体的には、各ＡＯＢ＿ＥＬＥＭＥＮＴについてのデータ長を記述しておき、再生装置は、これを参照して、順方向サーチ再生−逆方向サーチ再生を行えばよいのである。２秒に相当するデータ長がどの程度になるかについて考察する。オーディオデータの再生時のビットレートは、上述したように１６Ｋｂｐｓ〜１４４Ｋｂｐｓの範囲であるので、２秒当たりに再生されるデータ長は４Ｋｂｙｔｅ（＝１６Ｋｂｐｓ×２／８）〜３６Ｋｂｙｔｅ（＝１４４Ｋｂｐｓ×２／８）となる。
【００５４】
２秒当たりのデータ長が４Ｋｂｙｔｅ〜３６Ｋｂｙｔｅであるなら、オーディオデータのデータ長が記述されるためのタイムサーチテーブル内のエントリーのデータ長は、２バイト（１６ビット）必要となる。何故なら、エントリーに１６ビット長を割り当てたならば、０〜６４ＫＢｙｔｅの数値が記述されることができるからである。一方、タイムサーチテーブルの総データサイズを例えば５０４バイト（これは後述するＴＫＴＭＳＲＴのデータサイズである）内に制限する場合を考えると、このタイムサーチテーブル内に設けるべきエントリーは、２５２（＝５０４／２）個に制限せねばならない。上述したように、エントリーは、２秒毎に設けられるものであるので２５２エントリーに対応する再生時間は、５０４秒（＝２秒×２５２）となり、８分２４秒（＝８．４分）となる。このようにＡＯＢ＿ＢＬＯＣＫにおける再生時間を８．４分以下に制限したことにより、タイムサーチテーブルのデータサイズを５０４バイト以下とすることができる。
【００５５】
［３−３＿１０−９］　ＡＯＢについて
以上でＡＯＢ＿ＢＬＯＣＫについての説明を終え、続いてＡＯＢについて説明する。
図１０の第２段目に位置するＡＯＢは、ＡＯＢ＿ＢＬＯＣＫの前後に無効領域が付与された領域であり、ＡＯＢファイル中に一つ存在する。
この無効領域は、当該、ＡＯＢ＿ＢＬＯＣＫと同じクラスタに格納され、当該ＡＯＢ＿ＢＬＯＣＫと供に読み書きされる領域である。ＡＯＢにおいて、何処から何処までがＡＯＢ＿ＢＬＯＣＫに該当するのかは、ナビゲーションデータに含まれるＢＩＴ（その詳細についての説明は、後段で行う。）にて指定される。
【００５６】
以上で、各ＡＯＢファイルにどのようなデータが格納されているかが明らかとなった。続いて、図９に示した８つのＡＯＢファイルに含まれるＡＯＢ、ＡＯＢ＿ＢＬＯＣＫが連続して読み出されることにより、どのような内容が再生されるかを説明する。
［３−３＿１０−１０＿１６］
図１６は、ＡＯＢファイルに収録されている各ＡＯＢ、ＡＯＢ＿ＢＬＯＣＫが連続して再生されることにより、どのような再生内容が再生されるかを示す。第１段目は、ユーザデータ領域における８つのＡＯＢファイルを示し、第２段目は、各ＡＯＢファイルに収録されている８つのＡＯＢを示す。第３段目は、それぞれのＡＯＢに含まれる８つのＡＯＢ＿ＢＬＯＣＫを示す。
【００５７】
第５段目は、５つのコンテンツ部からなるタイトルを示す。５つのコンテンツ部は、ＳｏｎｇＡ、ＳｏｎｇＢ、ＳｏｎｇＣ、ＳｏｎｇＤ、ＳｏｎｇＥという５つの曲のそれぞれを示し、タイトルは、これら５つの曲（コンテンツ）からなる音楽アルバムを示す。破線ＡＳ１，ＡＳ２，ＡＳ３・・・・ＡＳ７，ＡＳ８は、音楽アルバムの分割部分と、ＡＯＢ＿ＢＬＯＣＫとの対応関係を示し、第４段目は、第５段目の音楽アルバムがどのような単位で分割されるかを示す。
【００５８】
これらの破線を参照すると、各ＡＯＢ＿１に含まれるＡＯＢ＿Ｂｌｏｃｋは、６．１分という時間にて再生される曲（ＳｏｎｇＡ）であり、各ＡＯＢ＿２に含まれるＡＯＢ＿Ｂｌｏｃｋは、３．３分という時間にて再生される曲（ＳｏｎｇＢ）、各ＡＯＢ＿３に含まれるＡＯＢ＿Ｂｌｏｃｋは、５．５分という時間にて再生される曲（ＳｏｎｇＣ）である。以上のようにＡＯＢ００１．ＳＡ１〜ＡＯＢ００３．ＳＡ１は、それぞれが独立した曲に対応するものであることがわかる。第６段目は、ＴｒａｃｋＡ〜Ｅからなるトラックシーケンスを示す。これらＴｒａｃｋＡ〜Ｅは、ＳｏｎｇＡ、ＳｏｎｇＢ、ＳｏｎｇＣ、ＳｏｎｇＤ、ＳｏｎｇＥという５つの曲のそれぞれと１対１に対応しており、一個の独立した再生単位として扱われる。
【００５９】
一方、ＡＯＢ＿４は、３０．６分という時間にて再生される曲（ＳｏｎｇＤ）の先頭部分であり、８．４分という再生時間にて再生される。ＡＯＢ＿５、ＡＯＢ＿６に含まれるＡＯＢ＿ＢＬＯＣＫはＳｏｎｇＤの中間部分であり、８．４分という再生時間、ＡＯＢ＿７に含まれるＡＯＢ＿ＢＬＯＣＫは、ＳｏｎｇＤの終端部分であり、５．４分という再生時間にて再生される。このように３０．６分という再生時間を有する曲は、（８．４分＋８．４分＋８．４分＋５．４分）という単位で分割され、各ＡＯＢに含まれていることがわかる。この図からも理解できるように、ＡＯＢファイルに含まれる全ての曲は、再生時間長が８．４分という時間長以内に収められていることがわかる。
【００６０】
以上の説明によりＡＯＢの再生時間長を制限することにより、各ＡＯＢに対応づけられているタイムサーチテーブルのデータサイズも制限されていることが明らかとなった。続いて、このタイムサーチテーブルを含むナビゲーションデータについて説明する。
［３−３＿８Ａ，Ｂ−２］
ナビゲーションデータは、『ＳＤ＿Ａｕｄｉｏ．ＰＬＭ』『ＳＤ＿Ａｕｄｉｏ．ＴＫＭ』という２つのファイルからなることは既に述べた通りである。ファイル『ＳＤ＿Ａｕｄｉｏ．ＰＬＭ』は、プレイリストマネージャ（Ｐｌａｙｌｉｓｔｍａｎａｇｅｒ）を含み、ファイル『ＳＤ＿Ａｕｄｉｏ．ＴＫＭ』は、トラックマネージャ（ＴｒａｃｋＭａｎａｇｅｒ）を含む。
【００６１】
プレゼンテーションデータの説明で述べたように、複数のＡＯＢファイルは、符号化されたＡＯＢを収録しているが、これらのＡＯＢの再生時間がどれだけであるか、また、それぞれのＡＯＢがどのような曲名であり、作曲者は誰であるか等は何等記載されていない。一方、複数のＡＯＢは、複数のＡＯＢファイルに収録されているのみなので、それらをどのような順序で再生させるかは一切記載されていない。トラックマネージャ、プレイリストマネージャーは、こういった情報を再生装置に通知するために設けられている。
【００６２】
ここでトラックマネージャーは、ＡＯＢファイルに収録されているＡＯＢと、トラックとの対応関係を示し、これらのＡＯＢの再生時間がどれだけであるか、また、それぞれのＡＯＢがどのような曲名であり、作曲者は誰であるか等の諸情報を示す複数のトラック管理情報を含む。トラックとは、ユーザにとって意味のある再生単位であり、フラッシュメモリカード３１に音楽著作物を格納しようとする場合、トラックは曲に対応し、フラッシュメモリカード３１にリーディングブックを格納しようとする場合（リーディングブックとは、書籍ではなく、読み上げ音声により表現された文書著作物をいう）、ブックジャンルであるなら、トラックは、文の章／節に対応する。トラックマネージャーは、複数ＡＯＢファイルに収録されている複数のＡＯＢをトラックの集合として管理するために設けられている。
【００６３】
プレイリストとは、トラックの複数の再生順序を規定するものであり、プレイリストマネージャーは、このようなプレイリストを複数含んでいる。
以降、トラックマネージャーについて図面を参照しながら説明する。
［１７−１＿１８］　　Ｐｌａｙｌｉｓｔｍａｎａｇｅｒ及びＴｒａｃｋＭａｎａｇｅｒの詳細構成
図１７は、実施形態におけるＰｌａｙｌｉｓｔｍａｎａｇｅｒ及びＴｒａｃｋＭａｎａｇｅｒの構成を段階的に詳細化した図であり、図１８は、ＰｌａｙＬｉｓｔＭａｎａｇｅｒ及びＴｒａｃｋＭａｎａｇｅｒのサイズを示す図である。即ち、本図において右段に位置する論理フォーマットは、その左段に位置する論理フォーマットを詳細化したものであり、破線に示す引き出し線は、右段の論理フォーマットがその左段の論理フォーマット内のどの部分を詳細化したかを明確にしている。
【００６４】
このような表記に従って図１７におけるＴｒａｃｋＭａｎａｇｅｒの構成を参照すると、ＴｒａｃｋＭａｎａｇｅｒは、破線の引き出し線ｈ１に示すように、Ｔｒａｃｋ　Ｉｎｆｏｒｍａｔｉｏｎ（ＴＫＩと略す）＃１，＃２，＃３，＃４・・・・・＃ｎからなる。これらのＴＫＩはＡＯＢファイルに収録されているＡＯＢを、トラックとして管理するための情報であり、各ＡＯＢファイルに対応している。
【００６５】
図１７を参照すると各ＴＫＩは、破線の引き出し線ｈ２に示すように、Ｔｒａｃｋ＿Ｇｅｎｅｒａｌ＿Ｉｎｆｏｒｍａｔｉｏｎ（ＴＫＧＩ）　、ＴＫＩに固有なテキスト情報が記述されるＴｒａｃｋ＿Ｔｅｘｔ＿Ｉｎｆｏｒｍａｔｉｏｎ＿Ｄａｔａ＿Ａｒｅａ（ＴＫＴＸＴＩ＿ＤＡ）、タイムサーチテーブルの役割を有するＴｒａｃｋ＿Ｔｉｍｅ＿Ｓｅｒｃｈ＿Ｔａｂｌｅ（ＴＫＴＭＳＲＴ）からなることがわかる。図１８を参照すると、ＴＫＩ自体は固定サイズ（１０２４バイト）であり、ＴＫＧＩとＴＫＴＸＴＩ＿ＤＡとは合計で５１２バイト固定長であることがわかる。ＴＫＴＭＳＲＴも５１２バイト固定長である。またＴｒａｃｋＭａｎａｇｅｒにおいて、ＴＫＩは、最大９９９個まで設定することができる。
【００６６】
このＴＫＴＭＳＲＴは、破線の引き出し線ｈ３に示すように、ＴＭＳＲＴ＿Ｈｅａｄｅｒと、ＴＭＳＲＴ＿ｅｔｒｙ＃１，＃２，＃３・・・・・＃ｎとからなることがわかる。
［１７−２＿１９］　　ＴＫＩと、ＡＯＢファイル及びＡＯＢとの相互関係
図１９は、図１７に示したＴＫＩと、図１６に示したＡＯＢファイル及びＡＯＢとの相互関係を示す図である。図１９の第１段目における四角枠はＴｒａｃｋＡ〜Ｅとからなるトラックシーケンス、図１９の第２段目における四角枠はＴｒａｃｋＭａｎａｇｅｒを示し、第３、第４段目は図１６に示した８つのＡＯＢファイルを示す。第５段目における８つの枠は、８つのＡＯＢを示す。この８つのＡＯＢファイルは、図１６に示した８つのＡＯＢを収録していたものであり、ＴｒａｃｋＡ、ＴｒａｃｋＢ、ＴｒａｃｋＣ、ＴｒａｃｋＤ、ＴｒａｃｋＥを含む音楽アルバムを形成している。第２段目は、８つのＴＫＩを示す。これらＴＫＩに付与された数値”１”，”２”，”３”，”４”は、各ＴＫＩを識別するためのシリアル番号であり、各ＴＫＩは、同じシリアル番号００１，００２，００３，００４，００５・・・・・が付与されたＡＯＢファイルと対応づけられている。この点に注意して、図１９を参照すれば、ＴＫＩ＃１がＡＯＢ００１．ＳＡ１に対応していて、ＴＫＩ＃２がＡＯＢ００２．ＳＡ１、ＴＫＩ＃３がＡＯＢ００３．ＳＡ１、ＴＫＩ＃４がＡＯＢ００４．ＳＡ１に対応していることがわかる（本図における矢印ＴＡ１，ＴＡ２，ＴＡ３，ＴＡ４・・・・・・は、各ＴＫＩがどのＡＯＢファイルと対応しているかを示す。）。このように各ＴＫＩは、各ＡＯＢファイルに収録されているＡＯＢと、１対１の対応関係を有するので、各ＴＫＩには、ＡＯＢに固有な情報を詳細に記載しておくことができる。
【００６７】
［１７−３＿２０］　　ＴＫＴＭＳＲＴのデータ構造について
ＡＯＢファイルに収録されているＡＯＢに固有な情報として、先ず初めにＴＫＴＭＳＲＴについて説明する。図２０は、図１７に示したＴＫＴＭＳＲＴの詳細なデータ構造を示す図である。本図の右側には、タイムサーチテーブルヘッダ（ＴＭＳＲＴ＿Ｈｅａｄｅｒ）の詳細なデータ構造が示されている。図２０において、タイムサーチテーブルヘッダのデータサイズは８バイトであり、ＴＭＳＲＴ＿ＩＤ（０バイト目から１バイト目まで）、ｒｅｓｅｒｖｅｄ（２バイト目から３バイト目まで）、Ｔｏｔａｌ　ＴＭＳＲＴ＿ｅｎｔｒｙ＿Ｎｕｍｂｅｒ（４バイト目から７バイト目まで）という３つのフィールドを有する。『ＴＭＳＲＴ＿ＩＤ』には、ＴＭＳＲＴを一意に識別できるＩＤが記述される。『Ｔｏｔａｌ　ＴＭＳＲＴ＿ｅｎｔｒｙ　Ｎｕｍｂｅｒ』には、当該ＴＭＳＲＴ内にあるＴＭＳＲＴ＿ｅｎｔｒｙの総数が記述される。
【００６８】
［１７−３＿２１−１］　　ＴＫＴＭＳＲＴの具体例について
続いてＴＫＴＭＳＲＴについてより詳細に説明する。図２１は、ＴＫＴＭＳＲＴについての一例を示す図である。本図の左側に、ＡＯＢを示し、右側にＴＫＴＭＳＲＴを示す。本図左側のＡＯＢは、複数のＡＯＢ＿ＥＬＥＭＥＮＴ＃１，＃２，＃３・・・・・・＃ｎからなり、その右側における複数の領域ＡＲ１，ＡＲ２，ＡＲ３・・・・・・ＡＲｎを占有している。また図中の『０』『３２０００』『６４２００』『９７０００』『１２０３４００』『１２４００００』といった数値は、ＡＯＢに含まれるＡＯＢ＿ＢＬＯＣＫ先頭からの各ＡＯＢ＿ＥＬＥＭＥＮＴの占有領域ＡＲ１，ＡＲ２，ＡＲ３，ＡＲｎ−１，ＡＲｎまでの相対アドレスを示す。ＡＯＢ＿ＥＬＥＭＥＮＴ＃２は、ＡＯＢ＿ＢＬＯＣＫ先頭から『３２０００』だけ隔てられた位置に記録されていることを示す。ＡＯＢ＿ＥＬＥＭＥＮＴ＃３は、ＡＯＢ＿ＢＬＯＣＫ先頭から『６４２００』だけ隔てられた位置に、ＡＯＢ＿ＥＬＥＭＥＮＴ＃ｎ−１は、ＡＯＢ＿ＢＬＯＣＫ先頭から『１２０３４００』だけ隔てられた位置に記録されていることを示す。
【００６９】
注意すべきは、各占有領域の先頭アドレスの間隔が一定値ではないこと、即ち、各ＡＯＢ＿ＥＬＥＭＥＮＴの占有領域が、それぞれ異なるサイズだけ複数クラスタを占有していることである。各占有領域のサイズがそれぞれ異なるのは、各ＡＯＢ＿ＦＲＡＭＥにおける符号割り当てが可変長だからである。
各ＡＯＢ＿ＥＬＥＭＥＮＴの占有サイズが異なるので、各ＡＯＢ＿ＥＬＥＭＥＮＴの先頭にジャンプする場合、各ＡＯＢ＿ＥＬＥＭＥＮＴがＡＯＢ内の何処に存在するかを予め再生装置に指示しておく必要がある。このような目的をもって、複数のＴＭＳＲＴ＿ｅｎｔｒｙは記載されている。矢印ＲＴ１，ＲＴ２，ＲＴ３・・・・・・ＲＴｎ−１，ＲＴｎは、これら各ＡＯＢ＿ＥＬＥＭＥＮＴの占有領域ＡＲ１，ＡＲ２，ＡＲ３・・・・・・ＡＲｎ−１，ＡＲｎと、ＴＭＳＲＴ＿ｅｎｔｒｙ＃１、ＴＭＳＲＴ＿ｅｎｔｒｙ＃２、ＴＭＳＲＴ＿ｅｎｔｒｙ＃３・・・・・・ＴＭＳＲＴ＿ｅｎｔｒｙ＃ｎ−１，ＴＭＳＲＴ＿ｅｎｔｒｙ＃ｎとの対応関係を示す。即ち、ＡＯＢ＿ＥＬＥＭＥＮＴ＃１の占有領域ＡＲ１がどれだけのサイズを占有しているかがＴＭＳＲＴ＿ｅｎｔｒｙ＃１に記載され、ＡＯＢ＿ＥＬＥＭＥＮＴ＃２、ＡＯＢ＿ＥＬＥＭＥＮＴ＃３の占有領域ＡＲ２，ＡＲ３がどれだけのサイズを占有しているかがＴＭＳＲＴ＿ｅｎｔｒｙ＃２、ＴＭＳＲＴ＿ｅｎｔｒｙ＃３に記載される。
【００７０】
ここで、占有領域ＡＲ１は、ＡＯＢの先頭から、ＡＯＢ＿ＥＬＥＭＥＮＴ＃２の先頭『３２０００』迄を占有しているので、ＴＭＳＲＴ＿ｅｎｔｒｙ＃１は３２０００（＝３２０００−０）と記述され、占有領域ＡＲ２は、ＡＯＢ＿ＥＬＥＭＥＮＴ＃１の先頭『３２０００』から、ＡＯＢ＿ＥＬＥＭＥＮＴ＃２の先頭『６４２００』迄を占有しているので、ＴＭＳＲＴ＿ｅｎｔｒｙ＃２は『３２２００（＝６４２００−３２０００）』と記述、占有領域ＡＲ３は、ＡＯＢ＿ＥＬＥＭＥＮＴ＃３の先頭『６４２００』から、ＡＯＢ＿ＥＬＥＭＥＮＴ＃４の先頭『９７０００』迄を占有しているので、ＴＭＳＲＴ＿ｅｎｔｒｙ＃３は『３２８００（＝９７０００−６４２００）』、占有領域ＡＲｎ−１は、ＡＯＢ＿ＥＬＥＭＥＮＴ＃ｎ−１の先頭『１２０３４００』から、ＡＯＢ＿ＥＬＥＭＥＮＴ＃ｎの先頭『１２４００００』迄を占有しているので、ＴＭＳＲＴ＿ｅｎｔｒｙ＃ｎ−１は『３６６００（＝１２４００００−１２０３４００）』と記述されている。
【００７１】
［１７−３＿２１−２］　　ＴＫＴＭＳＲＴの読み出し方式
このようにタイムサーチテーブルには、ＡＯＢ＿ＥＬＥＭＥＮＴのデータサイズが記載されていることがわかる。一方、ＡＯＢ＿ＥＬＥＭＥＮＴの説明で述べたように、各ＡＯＢ＿ＢＬＯＣＫのデータ長は、再生時間が８．４分内になるように定めらているので、１つのＡＯＢに含まれるＡＯＢ＿ＥＬＥＭＥＮＴの総数は、所定数（図２０に示す２５２個）以下に抑えられている。ＡＯＢ＿ＥＬＥＭＥＮＴ数が所定数以下に抑えられるので、ＡＯＢ＿ＥＬＥＭＥＮＴに対応するＴＭＳＲＴ＿ｅｎｔｒｙの総数も所定数以下となり、これらを含むＴＫＴＭＳＲＴのデータサイズも所定サイズ以下となる。ＴＫＴＭＳＲＴのサイズを抑制したため、再生装置は、以下のようにＴＫＩを読み出して、利用することができる。
【００７２】
あるＡＯＢが読み出されて、その再生が開始されると、それに対応するＴＫＩを読み出して、メモリに格納する。以降、当該ＡＯＢの再生が継続している期間において、このＴＫＩをメモリに格納しておく。当該ＡＯＢの再生が終われば、これに後続するＡＯＢが読み出されて、その再生が開始されると、それに対応するＴＫＩを読み出して、それまでメモリ上に格納されていたＴＫＩを、新たに読み出されたＴＫＩを用いて上書きする。以降、当該ＡＯＢの再生が継続している期間において、このＴＫＩをメモリに格納しておく。
【００７３】
ＴＫＩの読み出しと、メモリへの格納とをこのように行えば、再生装置におけるメモリの実装量が小規模であっても、必要なＴＫＩを読み出すだけで順方向サーチ再生、逆方向サーチ再生といった特殊再生を行うことができる。尚、本実施形態では、あるＡＯＢ＿ＥＬＥＭＥＮＴの先頭アドレスから次のＡＯＢ＿ＥＬＥＭＥＮＴの先頭アドレスまでのデータ長をＴＭＳＲＴ＿ｅｎｔｒｙとして記載したが、ＡＯＢ＿ＢＬＯＣＫの先頭から、各ＡＯＢ＿ＥＬＥＭＥＮＴの先頭までの相対アドレスを記載してもよい。
【００７４】
［１７−３＿２１−３］　　ＡＯＢ＿ＥＬＥＭＥＮＴを含むクラスタの特定
最後にＴＫＴＭＳＲＴを参照して、任意のＡＯＢ＿ＥＬＥＭＥＮＴをどうやって読み出せばよいかについて説明する。各ＡＯＢ＿ＥＬＥＭＥＮＴのサイズが記載されたＴＫＴＭＳＲＴを参照して、ＡＯＢにおいて先頭からｙ番目に位置するＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙを読み出す場合、以下の｛数式１｝を満たすクラスタｕを求めて、そのクラスタｕの先頭からオフセットｖ以降を読み出せばよい。
｛数式１｝
クラスタｕ　＝　（ＡＯＢ＿ＥＬＥＭＥＮＴ＃１からＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙ−１までのＴＭＳＲＴ＿ｅｎｔｒｙの総和＋ＤＡＴＡ＿Ｏｆｆｓｅｔ）／クラスタサイズ
オフセットｖ　＝（ＡＯＢ＿ＥＬＥＭＥＮＴ＃１からＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙ−１までのＴＭＳＲＴ＿ｅｎｔｒｙの総和＋ＤＡＴＡ＿Ｏｆｆｓｅｔ）　ｍｏｄ　クラスタサイズ
ｃ　＝ａ　ｍｏｄ　ｂとある場合、ｃは、ａをｂで割った場合の余りを示し、ＤＡＴＡ＿Ｏｆｆｓｅｔは、ＢＩＴに記載されている情報であり、後述する。
【００７５】
［１７−４］　ＴＫＴＸＴＩ＿ＤＡについて
以上で、タイムサーチマップ（ＴＫＴＭＳＲＴ）の説明を終わる。次に、図１７においてＴＫＴＭＳＲＴの上段に記載されているＴｒａｃｋ　Ｔｅｘｔ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｄａｔａ　Ａｒｅａ（ＴＫＴＸＴＩ＿ＤＡ）について説明する。
Ｔｒａｃｋ　Ｔｅｘｔ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｄａｔａ　Ａｒｅａ（ＴＫＴＸＴＩ＿ＤＡ）には、アーティスト名、アルバム名、編曲者名、プロデューサ名等を示すテキスト情報が記述される。テキストデータが存在しない場合でも、この領域は確保される。
【００７６】
［１７−５］　ＴＫＧＩについて
続いてＴＫＴＸＴＩ＿ＤＡの上段にあるＴＫＧＩについて説明する。図１７においてＴＫＩのＴＫＧＩは、破線の引き出し線ｈ４に示すように、ＴＫＩの識別子『ＴＫＩ＿ＩＤ』、ＴＫＩ番号『ＴＫＩＮ』、ＴＫＩのサイズ『ＴＫＩ＿ＳＺ』、次のＴＫＩへのリンクポインタ『ＴＫＩ＿ＬＮＫ＿ＰＴＲ』、ブロック属性『ＴＫＩ＿ＢＬＫ＿ＡＴＲ』、再生時間『ＴＫＩ＿ＰＢ＿ＴＭ』、ＴＫＩのオーディオ属性『ＴＫＩ＿ＡＯＢ＿ＡＴＲ』、『ＩＳＲＣ』、ブロック情報『ＢＩＴ』という一連の情報が記録されていることがわかる（尚、本図は、説明の簡略化のため、一部のフィールドについては省略して表記している。）。
【００７７】
［１７−５＿２２−１］　　ＴＫＧＩについて
以下、図２２を参照しながらＴＫＧＩの詳細構成について説明する。本図と、図１７との違いは、図１７に示したＴＫＧＩのデータ構成が図中左側に配置されており、図１７では明らかにされてなかった『ＴＫＩ＿ＢＬＫ＿ＡＴＲ』，『ＴＫＩ＿ＡＯＢ＿ＡＴＲ』，『ＩＳＲＣ』のビット構成が、図中の右側に配置されている点である。
【００７８】
［１７−５＿２２−２］　　ＴＫＩ＿ＩＤについて
『ＴＫＩ＿ＩＤ』には、ＴＫＩを一意に識別できるＩＤ（本実施形態では２バイトの”Ａ４”というコード）が記述される。
［１７−５＿２２−３］　　ＴＫＩＮについて
『ＴＫＩＮ』には、１から９９９までの範囲のＴＫＩ番号が記述される。なお、このＴＫＩ番号は他のＴＫＩのＴＫＩＮに記述されるＴＫＩ番号と重複してはならない。このようなＴＫＩＮとして、ＴｒａｃｋＭａｎａｇｅｒにおけるＴＫＩの順位、即ち、ＴｒａｃｋＭａｎａｇｅｒにおいてＴＫＩが何番目に位置するかを記述するものとする。本図におけるＴＫＩ＃１なら、ＴＫＩ番号は、”１”と記載され、ＴＫＩ＃２ならＴＫＩ番号は、”２”と、ＴＫＩ＃３ならＴＫＩ番号は、”３”と記載される。
【００７９】
［１７−５＿２２−４］　　ＴＫＩ＿ＳＺについて
『ＴＫＩ＿ＳＺ』には、ＴＫＩのデータサイズがバイト数単位で記述される。図２２では、ＴＫＩのデータサイズが１０２４バイトと規定されているので、本実施形態において１０２４バイトと記述される。
［１７−５＿２２−５］　　ＴＫＩ＿ＬＮＫ＿ＰＴＲについて
『ＴＫＩ＿ＬＮＫ＿ＰＴＲ』には、当該ＴＫＩのリンク先のＴＫＩについてのＴＫＩＮが記述される。ここで、ＴＫＩ間の対応関係について説明する。
【００８０】
トラックが複数のＡＯＢから構成され、それらが複数のＡＯＢファイルに収録されている場合、それら複数のＡＯＢファイルに対応づけられている複数のＴＫＩは一体となって、当該トラックを管理することになる。このように複数のＴＫＩが一体となっている場合、これらＴＫＩに対応するＡＯＢファイルに、どのＴＫＩに対応するＡＯＢファイルが後続するかを示す必要がある。ＴＫＩ＿ＬＮＫ＿ＰＴＲは、各ＴＫＩに後続するＴＫＩについてのＴＫＩＮを記述するという用途に用いられる。
【００８１】
［１７−５＿２２−６＿１９］　ＴＫＩ＿ＬＮＫ＿ＰＴＲについて
以降、図１９に示した８つのＴＫＩにおいて、ＴＫＩ＿ＬＮＫ＿ＰＴＲがどのように設定されているかについて説明する。１トラックを構成するＴＫＩ＃１〜ＴＫＩ＃３、ＴＫＩ＃８において、そのＴＫＩ＿ＬＮＫ＿ＰＴＲは設定されないが、ＴｒａｃｋＤを構成する４つのＡＯＢファイルに対応するＴＫＩ＃４、ＴＫＩ＃５、ＴＫＩ＃６、ＴＫＩ＃７は、各ＴＫＩ＿ＬＮＫ＿ＰＴＲが次のＴＫＩ＿ＬＮＫ＿ＰＴＲを指示するよう設定されている。即ち、矢印ＴＬ４，ＴＬ５，ＴＬ６に示すように、ＴＫＩ＃４のＴＫＩ＿ＬＮＫ＿ＰＴＲはＴＫＩ＃５を指示しており、ＴＫＩ＃５のＴＫＩ＿ＬＮＫ＿ＰＴＲはＴＫＩ＃６を、ＴＫＩ＃６のＴＫＩ＿ＬＮＫ＿ＰＴＲはＴＫＩ＃７を指示している。これらは、何れもＴｒａｃｋＤを構成する。４つのＡＯＢファイルに対応づけられているＴＫＩにおけるこれらＴＫＩ＿ＬＮＫ＿ＰＴＲを参照することにより、ＴＫＩ＃４〜ＴＫＩ＃７という４つのＴＫＩ、及びＡＯＢ００４．ＳＡ１〜ＡＯＢ００７．ＳＡ１という４つのＡＯＢファイルが、一体となってＴｒａｃｋＤを構成しているということがわかる。
【００８２】
［１７−５＿２２−７］　　ＴＫＩ＿ＢＬＫ＿ＡＴＲについて
『ＴＫＩ＿ＢＬＫ＿ＡＴＲ』には、ＴＫＩについての属性が記述される。図２２においてＴＫＩ＿ＢＬＫ＿ＡＴＲから破線にて引き出された枠に、ＴＫＩ＿ＢＬＫ＿ＡＴＲのビット構成を示す。本図においてＴＫＩ＿ＢＬＫ＿ＡＴＲは１６ビットであり、ｂ３ビットからｂ１５ビットまでが将来の拡張のために確保されている。ビット番号ｂ２からｂ０までの３ビットを用いて、ＴＫＩについての属性が記述される。
【００８３】
ＴＫＩが使用されており、１個のＴＫＩが１個のトラックに含まれる場合、ＴＫＩ＿ＢＬＫ＿ＡＴＲには”０００ｂ”の値が記述される（以降、この設定を『Ｔｒａｃｋ』という。）。ＴＫＩが使用されており、１トラックが複数のＴＫＩを含み、当該ＴＫＩがその先頭である場合は、ＴＫＩ＿ＢＬＫ＿ＡＴＲには”００１ｂ”の値が記述される（以降、この設定を『Ｈｅａｄ＿ｏｆ＿Ｔｒａｃｋ』という。）。ＴＫＩが使用されており、１トラックが複数のＴＫＩから構成され、当該ＴＫＩがその中間である場合は、ＴＫＩ＿ＢＬＫ＿ＡＴＲには”０１０ｂ”の値が記述される（以降、この設定を『Ｍｉｄｐｏｉｎｔ＿ｏｆ＿Ｔｒａｃｋ』という）。ＴＫＩが使用されており、１トラックが複数のＴＫＩから構成され、当該ＴＫＩがその終端である場合、ＴＫＩ＿ＢＬＫ＿ＡＴＲには”０１１ｂ”の値が記述される（以降、この設定を『Ｅｎｄ＿ｏｆ＿Ｔｒａｃｋ』という。）。ＴＫＩが未使用であり、ＴＫＩの領域がある場合、すなわち削除されたＴＫＩである場合は、”１００ｂ”の値が記述される（以降、この設定を『Ｕｎｕｓｅｄ』という）。ＴＫＩが未使用であり、ＴＫＩの領域がない場合、すなわち初期状態のＴＫＩである場合は、”１０１ｂ”の値が記述される。
【００８４】
［１７−５＿２２−８＿１９］　ＴＫＩ＿ＢＬＫ＿ＡＴＲの設定例
図１９の一例では、それぞれのＴＫＩについてのＴＫＩ＿ＢＬＫ＿ＡＴＲがどのように設定されているかについて説明する。
各ＴＫＩにおけるＴＫＩ＿ＢＬＫ＿ＡＴＲを参照すれば、ＴＫＩ＃１（ＡＯＢ００１．ＳＡ１）、ＴＫＩ＃２（ＡＯＢ００２．ＳＡ１）、ＴＫＩ＃３（ＡＯＢ００３．ＳＡ１）、ＴＫＩ＃８（ＡＯＢ００８．ＳＡ１）という４つの組みは、それぞれが独立したトラックに対応しているので、ＴＫＩ＃１、ＴＫＩ＃２、ＴＫＩ＃３、ＴＫＩ＃８のＴＫＩ＿ＢＬＫ＿ＡＴＲは、『Ｔｒａｃｋ』と設定されている。
【００８５】
ＴＫＩ＃４におけるＴＫＩ＿ＢＬＫ＿ＡＴＲは『Ｈｅａｄ＿ｏｆ＿Ｔｒａｃｋ』と設定され、ＴＫＩ＃７におけるＴＫＩ＿ＢＬＫ＿ＡＴＲは『Ｅｎｄ＿ｏｆ＿Ｔｒａｃｋ』と、ＴＫＩ＃５、ＴＫＩ＃６は『Ｍｉｄｐｏｉｎｔ＿ｏｆ＿Ｔｒａｃｋ』と設定されていることがわかる。このことは、ＴＫＩ＃４と対応関係を有するＴＫＩ＃４（ＡＯＢ００４．ＳＡ１）はトラックの先頭部と、ＴＫＩ＃５、ＴＫＩ＃６と対応関係を有するＴＫＩ＃５（ＡＯＢ００５．ＳＡ１）及びＴＫＩ＃６（ＡＯＢ００６．ＳＡ１）はトラックの中間部と、ＴＫＩ＃７と対応関係を有するＴＫＩ＃７（ＡＯＢ００７．ＳＡ１）はトラックの終端部であることを意味する。
【００８６】
このように各ＴＫＩにおけるＴＫＩ＿ＢＬＫ＿ＡＴＲの記載に従って、ＴＫＩ（ＡＯＢファイル）の組みを分類すれば、ＴＫＩ＃１（ＡＯＢ００１．ＳＡ１）が１つ目のトラック（ＴｒａｃｋＡ）を構成していることがわかる。ＴＫＩ＃２（ＡＯＢ００２．ＳＡ１）が２つ目のトラック（ＴｒａｃｋＢ）、ＴＫＩ＃３（ＡＯＢ００３．ＳＡ１）が３つ目のトラック（ＴｒａｃｋＣ）を構成していることがわかる。ＴＫＩ＃４（ＡＯＢ００４．ＳＡ１）が４つ目のトラック（ＴｒａｃｋＤ）の先頭部分を構成しており、ＴＫＩ＃５（ＡＯＢ００５．ＳＡ１）、ＴＫＩ＃６（ＡＯＢ００６．ＳＡ１）がＴｒａｃｋＤの中間部分を構成しており、ＴＫＩ＃７（ＡＯＢ００７．ＳＡ１）がＴｒａｃｋＤの終端部分を構成していることがわかる。ＴＫＩ＃８（ＡＯＢ００８．ＳＡ１）は独立して５つ目のＴｒａｃｋＥの終端部分を構成していることがわかる。
【００８７】
［１７−５＿２２−９］　　ＴＫＩ＿ＰＢ＿ＴＭについて
『ＴＫＩ＿ＰＢ＿ＴＭ』には、ＴＫＩに対応するＡＯＢファイルに収録されているＡＯＢにより構成されるトラック（曲）の再生時間が記述される。
トラックが複数のＴＫＩから構成される場合、先頭のＴＫＩについてのＴＫＩ＿ＰＢ＿ＴＭには、トラック全体の再生時間が記述される。また２番目以降のＴＫＩには、それぞれのＴＫＩに対応するＡＯＢの再生時間が記述される。
【００８８】
［１７−５＿２２−１０］　ＴＫＩ＿ＡＯＢ＿ＡＴＲについて
『ＴＫＩ＿ＡＯＢ＿ＡＴＲ』には、ＴＫＩに対応するＡＯＢファイルに収録されているＡＯＢがどのようなサンプリング周波数でサンプリングされているか、どのようなビットレートで転送されるか、チャネル数がどれだけであるか等、ＡＯＢを生成する際のエンコード条件が記述される。『ＴＫＩ＿ＡＯＢ＿ＡＴＲ』から破線にて引き出された枠は、ＴＫＩ＿ＡＯＢ＿ＡＴＲのビット構成を示す。本図においてＴＫＩ＿ＡＯＢ＿ＡＴＲは、２０ビットであり、ビット番号ｂ１６からビット番号ｂ１９までのフィールドには、コーディングモードが記述される。ＭＰＥＧ−２　ＡＡＣ（ｗｉｔｈ　ＡＤＴＳ　ｈｅａｄｅｒ）でエンコードされている場合には、”００００ｂ”の値が、ＭＰＥＧ−ｌａｙｅｒ３（ＭＰ３）でエンコードされている場合には、”０００１ｂ”の値が、Ｗｉｎｄｏｗｓ（登録商標）　Ｍｅｄｉａ　Ａｕｄｉｏ（ＷＭＡ）でエンコードされている場合、”００１０ｂ”がそれぞれ記述される。
【００８９】
ビット番号ｂ１５からビット番号ｂ８までのフィールドには、ビットレートが記述される。ＭＰＥＧ−２　ＡＡＣ（ｗｉｔｈ　ＡＤＴＳ　ｈｅａｄｅｒ）でエンコードされている場合には、”１６”〜”７２”の値が、ＭＰＥＧ１−ｌａｙｅｒ３（ＭＰ３）でエンコードされている場合には”１６”〜”９６”の値が、ＭＰＥＧ２−ｌａｙｅｒ３（ＭＰ３）　ＬＳＦでエンコードされている場合には”１６”〜”８０”の値が、Ｗｉｎｄｏｗｓ（登録商標）　Ｍｅｄｉａ　Ａｕｄｉｏ（ＷＭＡ）でエンコードされている場合、”８”〜”１６”の値がそれぞれ記述される。
【００９０】
ビット番号ｂ７からビット番号ｂ４には、サンプリング周波数が記述される。４８ｋＨｚの場合は”００００ｂ”、４４．１ｋＨｚの場合は”０００１ｂ”、３２ｋＨｚの場合は”００１０ｂ”、２４ｋＨｚの場合は”００１１ｂ”、２２．０５ｋＨｚの場合は”０１００ｂ”、１６ｋＨｚの場合は”０１０１ｂ”の値が記述される。
ビット番号ｂ３からビット番号ｂ１までのフィールドには、チャネル数が記述される。１ｃｈ（ｍｏｎｏ）の場合は、”０００ｂ”が記述される。２ｃｈ（ｓｔｅｒｅｏ）の場合は、”００１ｂ”が記述される。
【００９１】
ビット番号ｂ３１からビット番号ｂ２０、およびビット番号ｂ０の領域は、将来の拡張用に予約されている。
［１７−５＿２２−１１］　ＩＳＲＣについて
『ＩＳＲＣ』には、ＴＫＧＩにおけるＩＳＲＣ（Ｉｎｔｅｒｎａｔｉｏｎａｌ　Ｓｔａｎｄａｒｄ　Ｒｅｃｏｒｄｉｎｇ　Ｃｏｄｅ）が記述される。図２２における『ＩＳＲＣ』から破線にて引き出された枠はＩＳＲＣの内容を示す。この枠に示されているように、ＩＳＲＣは、１０バイトからなり、ビット番号ｂ４からビット番号ｂ７までのフィールドにＲｅｃｏｒｄｉｎｇ−ｉｔｅｍ　ｃｏｄｅ（＃１２）が記述され、ビット番号ｂ８からビット番号ｂ１１までのフィールドにＲｅｃｏｒｄｉｎｇ　ｃｏｄｅ／Ｒｅｃｏｒｄｉｎｇ−ｉｔｅｍ　ｃｏｄｅ（＃１１）が記述される。
【００９２】
ビット番号ｂ１２からビット番号ｂ２３までのフィールドにＲｅｃｏｒｄｉｎｇ　ｃｏｄｅ（ＩＳＲＣ＃１０，＃９，＃８）が記述される。ビット番号ｂ２４からビット番号ｂ３１までのフィールドにＹｅａｒ−ｏｆ−Ｒｅｃｏｒｄｉｎｇ　ｃｏｄｅ（ＩＳＲＣ＃６，＃７）が記述される。以降、ビット番号ｂ３２からビット番号ｂ３７までのフィールド、ビット番号ｂ４０からビット番号ｂ４５までのフィールド、ビット番号ｂ４８からビット番号ｂ５３までのフィールドには、Ｆｉｒｓｔ　Ｏｗｎｅｒ　Ｃｏｄｅ（ＩＳＲＣ＃３，＃４，＃５）が記述される。ビット番号ｂ５６からビット番号ｂ６１までのフィールド、ビット番号ｂ６４からビット番号ｂ６９までのフィールドには、Ｃｏｕｎｔｒｙ　ｃｏｄｅ（ＩＳＲＣ＃１，＃２，＃３）が記述される。ビット番号ｂ７９のフィールドには、１ビットのＶａｌｉｄｉｔｙ　ｆｌａｇが記述される。尚、ＩＳＲＣの詳細については、ＩＳＯ３９０１　：　１９８６　’’Ｄｏｃｕｍｅｎｔａｔｉｏｎ−Ｉｎｔｅｒｎａｔｉｏｎａｌ　Ｓｔａｎｄａｒｄ　Ｒｅｃｏｒｄｉｎｇ　Ｃｏｄｅ　（ＩＳＲＣ）　’’を参照されたい。
【００９３】
［１７−５＿２２−１２＿２３Ａ−１］　ＢＩＴについて
『ブロック情報テーブル（ＢＩＴ）』は、ＡＯＢ＿ＢＬＯＣＫを管理するテーブルである。図２３（ａ）、（ｂ）は、ＢＩＴの詳細構成を示す図である。図２３（ａ）に示すように、ＢＩＴは、６０バイト目から６３バイト目までを占めるＤＡＴＡ＿ＯＦＦＳＥＴフィールドと、６４バイト目から６７バイト目までを占めるＳＺ＿ＤＡＴＡフィールドと、６８バイト目から７１バイト目までを占めるＴＭＳＲＴＥ＿Ｎｓフィールドと、７２バイト目から７３バイト目までを占めるＦＮｓ＿１ｓｔ＿ＴＭＳＲＴＥフィールドと、７４バイト目から７５バイト目までを占めるＦＮｓ＿Ｌａｓｔ＿ＴＭＳＲＴＥフィールドと、７６バイト目から７７バイト目までを占めるＦＮｓ＿Ｍｉｄｄｌｅ＿ＴＭＳＲＴＥフィールドと、７８バイト目から７９バイト目までを占めるＴＩＭＥ＿ＬＥＮＧＴＨフィールドとからなる。以下、各構成要素の説明を行う。
【００９４】
［１７−５＿２２−１２＿２３Ａ−２］　ＤＡＴＡ＿Ｏｆｆｓｅｔについて
『ＤＡＴＡ＿ＯＦＦＳＥＴ』には、クラスタ境界から各ＡＯＢ＿ＢＬＯＣＫの先頭までの相対アドレスがバイト単位で記述される。これにより、ＡＯＢからＡＯＢ＿ＢＬＯＣＫまでの間に無効領域がどれだけ存在するかが表現される。ＡＯＢとしてフラッシュメモリカード３１に格納されている音楽が、エアチェックして録音された音楽であり、その音楽のイントロの部分にディスクジョッキーの音声が混じっている場合、ＢＩＴにおけるＤＡＴＡ＿Ｏｆｆｓｅｔを設定することにより、この不要音声をＡＯＢ＿ＢＬＯＣＫから除外して再生させないようにすることができる。
【００９５】
［１７−５＿２２−１２＿２３Ａ−３］　ＳＺ＿ＤＡＴＡについて
『ＳＺ＿ＤＡＴＡ』には、各ＡＯＢ＿ＢＬＯＣＫのデータ長がバイト単位で記述される。ＳＺ＿ＤＡＴＡとＤＡＴＡ＿Ｏｆｆｓｅｔとを加算した値をＡＯＢを収録しているファイルサイズ（クラスタサイズの整数倍）から差し引けば、ＡＯＢ＿ＢＬＯＣＫに後続する無効領域がどれだけのサイズであるかを求めることができる。
【００９６】
［１７−５＿２２−１２＿２３Ａ−４］　ＴＭＳＲＴＥ＿Ｎｓについて
『ＴＭＳＲＴＥ＿Ｎｓ』には、各ＡＯＢ＿ＢＬＯＣＫに含まれるＴＭＳＲＴ＿ｅｎｔｒｙの総数が記述される。
［１７−５＿２２−１２＿２３Ａ−５］　『ＦＮｓ＿１ｓｔ＿ＴＭＳＲＴＥ』、『ＦＮｓ＿Ｌａｓｔ＿ＴＭＳＲＴＥ』、『ＦＮｓ＿Ｍｉｄｄｌｅ＿ＴＭＳＲＴＥ』について
『ＦＮｓ＿１ｓｔ＿ＴＭＳＲＴＥ』には、当該ＡＯＢ＿ＢＬＯＣＫ中の先頭に位置するＡＯＢ＿ＥＬＥＭＥＮＴに含まれるＡＯＢ＿ＦＲＡＭＥ数が記述される。
【００９７】
『ＦＮｓ＿Ｌａｓｔ＿ＴＭＳＲＴＥ』には、ＡＯＢ＿ＢＬＯＣＫの最後尾のＡＯＢ＿ＥＬＥＭＥＮＴに含まれるＡＯＢ＿ＦＲＡＭＥの個数が記述される。
『ＦＮｓ＿Ｍｉｄｄｌｅ＿ＴＭＳＲＴＥ』には、先頭と最後尾のＡＯＢ＿ＥＬＥＭＥＮＴを除くＡＯＢ＿ＥＬＥＭＥＮＴ、即ち、ＡＯＢ＿ＢＬＯＣＫの中間部に位置するＡＯＢ＿ＥＬＥＭＥＮＴに含まれるＡＯＢ＿ＦＲＡＭＥの個数が記述される。
【００９８】
『ＴＩＭＥ＿ＬＥＮＧＴＨ』は、図２３（ｃ）に示すフォーマットにてＡＯＢ＿ＥＬＥＭＥＮＴの再生期間をミリ秒オーダーの時間精度で記述するフィールドである。図２３（ｃ）に示すように、ＴＩＭＥ＿ＬＥＮＧＴＨフィールドは、１６ビット長であり、符号化方式がＭＰＥＧ−ＡＡＣ方式やＭＰＥＧ−Ｌａｙｅｒ３方式であれば、ＡＯＢ＿ＥＬＥＭＥＮＴの再生期間は２秒となるので、ＴＩＭＥ＿ＬＥＮＧＴＨには、２０００の値が記述される。
【００９９】
［１７−５＿２２−１３＿２３Ｂ］
図２３（ｂ）は、ＦＮｓ＿Ｍｉｄｄｌｅ＿ＴＭＳＲＴＥにＡＯＢ＿ＦＲＡＭＥが幾つ格納されているかを示す図である。本図は図１４同様、ｓａｍｐｌｉｎｇ＿ｆｒｅｑｕｅｎｃｙと、中間部のＡＯＢ＿ＥＬＥＭＥＮＴに含まれるＡＯＢ＿ＦＲＡＭＥ数との対応関係を示している。本図におけるｓａｍｐｌｉｎｇ＿ｆｒｅｑｕｅｎｃｙと、ＡＯＢ＿ＥＬＥＭＥＮＴに含まれるフレーム個数との対応関係は図１４と全く同一であり、サンプリング周波数に応じて異なる個数になっていることがわかる。『ＦＮｓ＿１ｓｔ＿ＴＭＳＲＴＥ』及び『ＦＮｓ＿Ｌａｓｔ＿ＴＭＳＲＴＥ』におけるフレーム数は、『ＦＮｓ＿Ｍｉｄｄｌｅ＿ＴＭＳＲＴＥ』におけるフレーム数と原則同一のフレーム数に設定されるが、ＡＯＢ＿ＢＬＯＣＫの先頭又は末尾に位置するＡＯＢ＿ＥＬＥＭＥＮＴに無効領域を設定する場合、『ＦＮｓ＿１ｓｔ＿ＴＭＳＲＴＥ』及び『ＦＮｓ＿Ｌａｓｔ＿ＴＭＳＲＴＥ』は、『ＦＮｓ＿Ｍｉｄｄｌｅ＿ＴＭＳＲＴＥ』と異なる値となる。
【０１００】
［１７−５＿２２−１４＿２４］　　ＡＯＢ＿ＥＬＥＭＥＮＴの格納例
図２４は、ＡＯＢ＿ＥＬＥＭＥＮＴ＃１〜＃４からなるＡＯＢが格納されているクラスタ００７〜クラスタ００Ｅを示す図である。ＡＯＢが図２４に示すように格納されている場合に、ＢＩＴがどのように設定されるかについて説明する。これらクラスタ００７〜クラスタ００Ｅに格納されているＡＯＢ＿ＥＬＥＭＥＮＴ＃１〜ＡＯＢ＿ＥＬＥＭＥＮＴ＃４のそれぞれには、三角旗状の記号が付与されているが、これらは、ＡＯＢ＿ＥＬＥＭＥＮＴ＃１〜ＡＯＢ＿ＥＬＥＭＥＮＴ＃４のそれぞれに、ＴＫＩに含まれるＴＭＳＲＴ＿ｅｎｔｒｙが設定されていることを示す。
【０１０１】
この際、ＡＯＢ先端におけるＡＯＢ＿ＥＬＥＭＥＮＴ＃１の先端部分は、クラスタ００７に格納されており、ＡＯＢ末尾におけるＡＯＢ＿ＥＬＥＭＥＮＴ＃４の終端部分は、クラスタ００Ｅに格納されている。ＡＯＢ＿ＥＬＥＭＥＮＴ＃１〜＃４は、クラスタ００７の途中ｍｄ０からクラスタ００Ｅの途中ｍｄ４迄を占有している。ＢＩＴ内のＳＺ＿ＤＡＴＡは、矢印ｓｄ１に示すようにＡＯＢ＿ＥＬＥＭＥＮＴ＃１からＡＯＢ＿ＥＬＥＭＥＮＴ＃４の最後までを指示しており、クラスタ００７，００Ｅ内の領域であって、ＡＯＢ＿ＥＬＥＭＥＮＴにより占有されていない部分ｕｄ０，ｕｄ１を指示していない。
【０１０２】
これに対して、ＡＯＢは、クラスタ００７、クラスタ００Ｅ内の領域であって、ＡＯＢ＿ＥＬＥＭＥＮＴ＃１、ＡＯＢ＿ＥＬＥＭＥＮＴ＃４により占有されていない部分ｕｄ０，ｕｄ１までも含んでいる。ＢＩＴ内のＤＡＴＡ＿Ｏｆｆｓｅｔは、非占有部分ｕｄ０のデータ長、即ち、クラスタ００７の先頭から、ＡＯＢ＿ＥＬＥＭＥＮＴ＃１の先頭までの相対値を指示している。
本図においてＡＯＢ＿ＥＬＥＭＥＮＴ＃１は、クラスタ００７の途中ｍｄ０からクラスタ００８の途中ｍｄ１までを占有している。このＡＯＢ＿ＥＬＥＭＥＮＴ＃１は、クラスタ００８全体を占有しているのではなく、その終端部分以降は、ＡＯＢ＿ＥＬＥＭＥＮＴ＃２に占有されている。ＡＯＢ＿ＥＬＥＭＥＮＴ＃４は、クラスタ００Ｃの途中部分ｍｄ３から、クラスタ００Ｅの途中部分ｍｄ４までを占有している。このようにＡＯＢ＿ＥＬＥＭＥＮＴには、クラスタの境界を跨ぐように、記録されているものが存在することがわかる。つまり、ＡＯＢ＿ＥＬＥＭＥＮＴは、クラスタの境界とは全く関係無く、記録されているのである。ＢＩＴ内の『ＦＮｓ＿１ｓｔ＿ＴＭＳＲＴＥ』は、クラスタ００７〜クラスタ００８におけるＡＯＢ＿ＥＬＥＭＥＮＴ＃１のフレーム数を示しており、ＢＩＴ内の『ＦＮｓ＿Ｌａｓｔ＿ＴＭＳＲＴＥ』は、クラスタ００Ｃ〜クラスタ００ＥにおけるＡＯＢ＿ＥＬＥＭＥＮＴ＃４のフレーム数を示している。
【０１０３】
このように、各ＡＯＢ＿ＥＬＥＭＥＮＴは、クラスタの境界に関係なく、自由に配置されており、ＢＩＴにより、クラスタ境界からＡＯＢ＿ＥＬＥＭＥＮＴまでのオフセットや各ＡＯＢ＿ＥＬＥＭＥＮＴ毎のフレーム数が管理されていることがわかる。
［１７−５＿２２−１４＿２５］　　各ＡＯＢ＿ＥＬＥＭＥＮＴ毎のフレーム数の利用法１
ＢＩＴに記載されている各ＡＯＢ＿ＥＬＥＭＥＮＴ毎のフレーム数がどのように利用されるかを以下に説明する。ＢＩＴに記載されているフレーム数は、先ず第１に、再生経過時刻を２秒スキップして、２４０ミリ秒だけ再生するという順方向サーチ再生、逆方向サーチ再生を行う場合に用いられる。
【０１０４】
図２５は、ＡＯＢ内の任意のＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙにおけるＡＯＢ＿ＦＲＡＭＥ＃ｘから順方向サーチ再生を行う場合、次に再生すべきＡＯＢ＿ＦＲＡＭＥ＃ｘ＋１をどのように設定するかを示す図である。
本図は、ＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙに含まれるＡＯＢ＿ＦＲＡＭＥ＃ｘが再生されている時点において、順方向サーチ再生が指示された場合を想定して作図した図である。本図において、ｔは、所定の間欠再生時間（＝２４０ミリ秒）、ｆ（ｔ）は、間欠再生時間に相当するフレーム数、間欠スキップ時間ｓｋｉｐ＿ｔｉｍｅは、間欠再生を行う際にスキップすべき時間長（この場合は２秒）、この間欠スキップ時間ｓｋｉｐ＿ｔｉｍｅに対応するフレーム数をｆ（ｓｋｉｐ＿ｔｉｍｅ）とする。ここで間欠再生は、以下の▲１▼▲２▼▲３▼の手順を繰り返すことにより行われる。
【０１０５】
▲１▼ＴＫＴＭＳＲＴに記載されているＴＭＳＲＴ＿ｅｎｔｒｙを参照して、旗（ＡＯＢ＿ＥＬＥＭＥＮＴ）の先頭へとジャンプする。
▲２▼２４０ミリ秒だけ再生を行う
▲３▼次の旗（ＡＯＢ＿ＥＬＥＭＥＮＴ）の先頭へとジャンプする。
尚、本実施形態では、２４０ミリ秒再生し、２秒後の箇所にジャンプし、２４０ミリ秒再生するという、より正確な間欠再生を実現する方法について説明する。
【０１０６】
ＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙに含まれるＡＯＢ＿ＦＲＡＭＥ＃ｘから、２秒＋２４０ミリ秒後のＡＯＢ＿ＦＲＡＭＥ＃ｘ＋１は、ＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙ＋１内に存在する筈である。２秒＋２４０ミリ秒後のＡＯＢ＿ＦＲＡＭＥ＃ｘ＋１を特定する場合、次のＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙ＋１についての先頭アドレスは、ＴＫＴＭＳＲＴにおけるＴＭＳＲＴ＿ｅｎｔｒｙを読み出すことにより即座に算出することができるが、そのＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙ＋１の先頭アドレスからＡＯＢ＿ＦＲＡＭＥ＃ｘ＋１までに介在するＡＯＢ＿ＦＲＡＭＥ数は、ＴＭＳＲＴ＿ｅｎｔｒｙのみでは知り得ない。そのようなＡＯＢ＿ＦＲＡＭＥ数を算出するためには、ＡＯＢ＿ＦＲＡＭＥ＃ｘがＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙの先頭から何番目に位置するかを示す＃ｘと、ｆ（ｔ）と、ｆ（ｓｋｉｐ＿ｔｉｍｅ）との和から、ＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙに含まれる全フレーム数を差し引くことにより求める必要がある。そのように、次のＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙ＋１におけるＡＯＢ＿ＦＲＡＭＥ＃ｘ＋１の相対フレーム位置を簡易に算出するため、ＢＩＴに各ＡＯＢ＿ＥＬＥＭＥＮＴについての『ＦＮｓ＿１ｓｔ＿ＴＭＳＲＴＥ』、『ＦＮｓ＿Ｍｉｄｄｌｅ＿ＴＭＳＲＴＥ』、『ＦＮｓ＿Ｌａｓｔ＿ＴＭＳＲＴＥ』を記載しているのである。
【０１０７】
［１７−５＿２２−１５＿２６Ａ］　各ＡＯＢ＿ＥＬＥＭＥＮＴ毎のフレーム数の利用法２
ＢＩＴに記載されているフレーム数は、第２に、任意の再生時刻から再生を開始するという機能（タイムサーチ機能）を実行する際に利用される。図２６（ａ）は、任意の再生開始時刻が指定された場合、その指定時刻に対応するＡＯＢ＿ＥＬＥＭＥＮＴ、ＡＯＢ＿ＦＲＡＭＥをどのように特定するかを示す図である。
【０１０８】
任意の時刻が指定されて再生が指示された場合、再生指定時刻をＪｍｐ＿Ｅｎｔｒｙ（秒）とすると、以下の式を満たすＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙと、ＡＯＢ＿ＦＲＡＭＥ位置ｘとから、再生を開始すればよい。
｛数式２｝
Ｊｍｐ＿Ｅｎｔｒｙ（秒）＝（ＦＮｓ＿１ｓｔ＿ＴＭＳＲＴＥ＋ＦＮｓ＿ｍｉｄｄｌｅ＿ＴＭＳＲＴＥ×ｙ＋ｘ）×２０ｍｓｅｃ
これら『ＦＮｓ＿１ｓｔ＿ＴＭＳＲＴＥ』及び『ＦＮｓ＿Ｍｉｄｄｌｅ＿ＴＭＳＲＴＥ』はＢＩＴに記載されているので、これらを｛数式２｝に適用することによりＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙ、ＡＯＢ＿ＦＲＡＭＥ＃ｘが算出されれば、このＡＯＢに対応するＴＫＴＭＳＲＴを参照して、ＡＯＢにおいてｙ＋２番目に位置するＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙ＋２の先頭アドレスを求めて、この先頭アドレスから、ＡＯＢ＿ＦＲＡＭＥ＃ｘの探索を始め、ｘ番目のＡＯＢ＿ＦＲＡＭＥが探索されれば、このｘ番目のＡＯＢ＿ＦＲＡＭＥから再生を開始する。これにより、Ｊｍｐ＿Ｅｎｔｒｙ（秒）にて指定された時刻から、再生を開始することができる。
【０１０９】
この際、ＡＯＢファイルのＡＤＴＳヘッダ部分を検索せず、ＴＫＴＭＳＲＴにＴＭＳＲＴ＿ｅｎｔｒｙが記述されているＡＯＢ＿ＥＬＥＭＥＮＴ単位で検索を行えばよいので、再生指定時刻に対応する再生位置を高速に探し出すことができる。
同様に、複数のＡＯＢからなるトラックに対して、タイムサーチ機能が実行され、Ｊｍｐ＿Ｅｎｔｒｙ（秒）が指定された場合、以下の｛数式３｝を満たすＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙと、ＡＯＢ＿ＦＲＡＭＥ＃ｘとを算出すればよい。
｛数式３｝
Ｊｍｐ＿Ｅｎｔｒｙ（秒）　＝　ＡＯＢ＿１からＡＯＢ＿ｎまでの再生時間の総和
＋（ＦＮｓ＿１ｓｔ＿ＴＭＳＲＴＥ（＃ｎ＋１）＋ＦＮｓ＿ｍｉｄｄｌｅ＿ＴＭＳＲＴＥ（＃ｎ＋１）・ｙ＋ｘ）・２０ｍｓｅｃここでＡＯＢ＿１からＡＯＢ＿ｎまでのＡＯＢの再生時間の総和は、以下の通りである。
ＡＯＢ＿１からＡＯＢ＿ｎまでの再生時間の総和＝
（『ＦＮｓ＿１ｓｔ＿ＴＭＳＲＴＥ』（＃１）＋『ＦＮｓ＿Ｍｉｄｄｌｅ＿ＴＭＳＲＴＥ』（＃１）・（ＴＭＳＲＴ＿ｅｎｔｒｙ数＃１−２）＋『ＦＮｓ＿Ｌａｓｔ＿ＴＭＳＲＴＥ』（＃１）
＋　『ＦＮｓ＿１ｓｔ＿ＴＭＳＲＴＥ』（＃２）＋『ＦＮｓ＿Ｍｉｄｄｌｅ＿ＴＭＳＲＴＥ』（＃２）・ＴＭＳＲＴ＿ｅｎｔｒｙ数＃２−２）＋『ＦＮｓ＿Ｌａｓｔ＿ＴＭＳＲＴＥ』（＃２）
＋　『ＦＮｓ＿１ｓｔ＿ＴＭＳＲＴＥ』（＃３）＋『ＦＮｓ＿Ｍｉｄｄｌｅ＿ＴＭＳＲＴＥ』（＃３）・ＴＭＳＲＴ＿ｅｎｔｒｙ数＃３−２）＋『ＦＮｓ＿Ｌａｓｔ＿ＴＭＳＲＴＥ』（＃３）
・・・・・・・・・
＋　『ＦＮｓ＿１ｓｔ＿ＴＭＳＲＴＥ』（＃ｎ）＋『ＦＮｓ＿Ｍｉｄｄｌｅ＿ＴＭＳＲＴＥ』（＃ｎ）・ＴＭＳＲＴ＿ｅｎｔｒｙ数＃ｎ−２）＋『ＦＮｓ＿Ｌａｓｔ＿ＴＭＳＲＴＥ』（＃ｎ））・２０ｍｓｅｃ
｛数式３｝を満たすＡＯＢ＿ｎ、ＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙ、ＡＯＢ＿ＦＲＡＭＥ＃ｘが算出されれば、このＡＯＢ＿ｎ＋１に対応するＴＫＴＭＳＲＴを参照して、ｙ＋２番目のＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙ＋２に位置するアドレスから、ＡＯＢ＿ＦＲＡＭＥ＃ｘの探索を始め、ｘ番目のＡＯＢ＿ＦＲＡＭＥが探索されれば、このｘ番目のＡＯＢ＿ＦＲＡＭＥから再生を開始する。
【０１１０】
［１７−５＿２２−１６＿２７Ａ，Ｂ］　ＡＯＢファイル及びＴＫＩの削除
ＴＫＩに含まれる情報を全て説明したところで、一部のトラックが削除された場合（ｃａｓｅ１）、一部のトラックが削除された後、新たなトラックを記録する場合（ｃａｓｅ２）、複数のトラックのうち、任意の２つを１つのトラックに統合する場合（ｃａｓｅ３）、１つのトラックを分割して、２つのトラックを得る場合（ｃａｓｅ４）において、ＴＫＩがどのように更新されるかについて説明する。
【０１１１】
先ず初めに、一部のトラックが削除された場合（ｃａｓｅ１）について説明する。
図２７（ａ）、（ｂ）は、トラックを削除する場合を想定した図である。本図は、図１９に示したＴｒａｃｋＭａｎａｇｅｒを示すものであり、本図においてＴｒａｃｋＢを削除することを操作者が希望しているものとする。このＴｒａｃｋＢに対応するＡＯＢは、ＡＯＢ００２．ＳＡ１に収録されており、それがＴＫＩ＃２に対応づけられているので、ＡＯＢ００２．ＳＡ１が削除されると共に、ＴＫＩ＃２のＴＫＩ＿ＢＬＫ＿ＡＴＲが『Ｕｎｕｓｅｄ』に設定される。ＡＯＢ００２．ＳＡ１が削除され、ＴＫＩ＃２のＴＫＩ＿ＢＬＫ＿ＡＴＲが『Ｕｎｕｓｅｄ』に設定された状態を図２７（ｂ）に示す。ＡＯＢ００２．ＳＡ１が削除されたので、データ領域においてＡＯＢ００２．ＳＡ１が占有していた領域は空き領域に解放される。それと共に、ＴｒａｃｋＭａｎａｇｅｒにおいては、ＴＫＩ＃２のＴＫＩ＿ＢＬＫ＿ＡＴＲが『Ｕｎｕｓｅｄ』に設定されていることがわかる。
【０１１２】
［１７−５＿２２−１７＿２８Ａ，Ｂ］　新たにＡＯＢファイルを記録する場合のＴＫＩの割り当て
続いて一部のトラックが削除された後、新たなトラックを記録する場合（ｃａｓｅ２）について説明する。
図２８（ａ）は、トラックの削除が複数回行われた後のＴｒａｃｋＭａｎａｇｅｒを示す図である。本図において、複数のトラックが削除され、これらがＴＫＩ＃２、ＴＫＩ＃４、ＴＫＩ＃５、ＴＫＩ＃７、ＴＫＩ＃８に対応づけられているとすれば、これらのＴＫＩのＴＫＩ＿ＢＬＫ＿ＡＴＲが『Ｕｎｕｓｅｄ』に設定される。ＡＯＢファイルの削除は、通常のファイルと同様に行われるが、ＴｒａｃｋＭａｎａｇｅｒは、該当するＴＫＩのＴＫＩ＿ＢＬＫ＿ＡＴＲが『Ｕｎｕｓｅｄ』に設定されるのみで削除処理は完了する。そうすると、本図に示すように『Ｕｎｕｓｅｄ』のＴＫＩが虫食い状にＴｒａｃｋＭａｎａｇｅｒ上に現れることになる。
【０１１３】
図２８（ｂ）は、『Ｕｎｕｓｅｄ』のＴＫＩが存在しており、ここに新たなＴＫＩ、ＡＯＢファイルを書き込む場合、その書き込みがどのように行われるかを示す図である。ここで４つのＡＯＢからなるトラックを書き込もうとする場合を想定する。ここでＡＯＢの記録にどの空きＴＫＩを割り当てるかは、後述するＤＰＬ＿ＴＫ＿ＳＲＰにより決定されるか、又は、任意のＴＫＩが割り当てられる。その４つのＡＯＢには、ＴｒａｃｋＭａｎａｇｅｒにおいて、『Ｕｎｕｓｅｄ』に設定されているＴＫＩ＃２、ＴＫＩ＃４、ＴＫＩ＃７、ＴＫＩ＃８が割り当てられる。
【０１１４】
これら４つのＡＯＢは１つのトラックを構成するものなので、ＴＫＩ＃２についてのＴＫＩ＿ＢＬＫ＿ＡＴＲを『Ｈｅａｄ＿ｏｆ＿Ｔｒａｃｋ』と、ＴＫＩ＃４、ＴＫＩ＃７についてのＴＫＩ＿ＢＬＫ＿ＡＴＲを『Ｍｉｄｐｏｉｎｔ＿ｏｆ＿Ｔｒａｃｋ』と、ＴＫＩ＃８についてのＴＫＩ＿ＢＬＫ＿ＡＴＲは、『Ｅｎｄ＿ｏｆ＿Ｔｒａｃｋ』と設定される。トラックＴｒａｃｋＤを構成する４つのＴＫＩ＃２、ＴＫＩ＃４、ＴＫＩ＃７、ＴＫＩ＃８は、各ＴＫＩ＿ＬＮＫ＿ＰＴＲが、トラックＴｒａｃｋＤを構成する次のＴＫＩ＿ＬＮＫ＿ＰＴＲを指示するよう設定されている。即ち、矢印ＴＬ２，ＴＬ４，ＴＬ７に示すように、ＴＫＩ＃２のＴＫＩ＿ＬＮＫ＿ＰＴＲはＴＫＩ＃４を指示しており、ＴＫＩ＃４のＴＫＩ＿ＬＮＫ＿ＰＴＲはＴＫＩ＃７を、ＴＫＩ＃７のＴＫＩ＿ＬＮＫ＿ＰＴＲはＴＫＩ＃８を指示している。
【０１１５】
その後、ＴＫＩ＃２、ＴＫＩ＃４、ＴＫＩ＃７、ＴＫＩ＃８のそれぞれと同じ番号を有する４つのファイルＡＯＢ００２．ＳＡ１、ＡＯＢ００４．ＳＡ１、ＡＯＢ００７．ＳＡ１、ＡＯＢ００８．ＳＡ１が作成されて、これら４つのファイルにＴｒａｃｋＤを構成する４つのＡＯＢが収録される。
かかるＴＫＩ＿ＢＬＫ＿ＡＴＲ、ＴＫＩ＿ＬＮＫ＿ＰＴＲの設定により、４つ目のトラックＴｒａｃｋＤは、ＴＫＩ＃２、ＴＫＩ＃４、ＴＫＩ＃７、ＴＫＩ＃８を用いて管理されることなる。
【０１１６】
以上のように、フラッシュメモリカード３１に新たにトラックを書き込む場合、それまでＴｒａｃｋＭａｎａｇｅｒに『Ｕｎｕｓｅｄ』に設定されているＴＫＩを、その新規に記録すべきトラックについてのＴＫＩに割り当てていることがわかる。
［１７−５＿２２−１８＿２９Ａ，Ｂ］　２つのトラックを統合する場合のＴＫＩ設定
続いてトラックの統合（ｃａｓｅ３）を行う際の、ＴＫＩの更新について説明する。
【０１１７】
図２９（ａ）、（ｂ）は、２つのトラックを１つに統合する場合にＴＫＩがどのように設定されるかを示す図である。図２９（ａ）は、図１９に示したＴｒａｃｋＭａｎａｇｅｒと同一であり、図２９（ａ）において、ＴｒａｃｋＣとＴｒａｃｋＥとを１つのトラックに統合するという編集操作を操作者が希望しているものとする。これらＴｒａｃｋＣ、ＴｒａｃｋＥに対応するＡＯＢがＡＯＢ００３．ＳＡ１、ＡＯＢ００８．ＳＡ１に収録されており、それらがＴＫＩ＃３、ＴＫＩ＃８に対応づけられているので、これらＴＫＩ＃３及びＴＫＩ＃８のＴＫＩ＿ＢＬＫ＿ＡＴＲの書き換えが行われる。図２９（ｂ）は、ＴＫＩのＴＫＩ＿ＢＬＫ＿ＡＴＲの書き換え後を示す図である。本図においてＴＫＩ＃３、ＴＫＩ＃８のＴＫＩ＿ＢＬＫ＿ＡＴＲはＴｒａｃｋと記載されているが、図２９（ｂ）では、ＴＫＩ＃３のＴＫＩ＿ＢＬＫ＿ＡＴＲは『Ｈｅａｄ＿ｏｆ＿Ｔｒａｃｋ』に書き換えられ、ＴＫＩ＃８のＴＫＩ＿ＢＬＫ＿ＡＴＲは『Ｅｎｄ＿ｏｆ＿Ｔｒａｃｋ』に書き換えられている。このように、ＴＫＩ＿ＢＬＫ＿ＡＴＲが書き換えられることにより、ＴＫＩ＃３、ＴＫＩ＃８、これらに対応するＡＯＢ００３．ＳＡ１、ＡＯＢ００８．ＳＡ１は、ＴｒａｃｋＣという１つのトラックとして扱われる。これに加えて、ＴＫＩ＃３のＴＫＩ＿ＬＮＫ＿ＰＴＲがリンク先としてＴＫＩ＃８を指示するように書き換えられる。
【０１１８】
ここで留意すべきは、ＴＫＩのＴＫＩ＿ＢＬＫ＿ＡＴＲは書き換えられたが、ＡＯＢ００３．ＳＡ１とＡＯＢ００８．ＳＡ１とを統合するという処理は行われなかった点である。何故なら、これらのＡＯＢファイルは、互いに異なるＦｉｌｅＫｅｙにて暗号化されているので、これらを１つに統合するとなると、暗号化されたＡＯＢファイルを復号して再度暗号化するという復号化−暗号化という２つの処理が各ＡＯＢファイルについて行う必要があり、多大な処理負荷が要求されるからである。また、統合後のＡＯＢファイルは、１つのＦｉｌｅＫｅｙにて暗号化されるので、統合前と比較して、著作権保護の弱体化を招くからである。
【０１１９】
加えてＴＫＩは、元々ＴＫＴＭＳＲＴのサイズが大きくならないように定められているのに、編集操作においてこれを１つに統合するとなると、統合後のＴＫＩのサイズが、大きくなり過ぎる恐れがあるからである。
以上のように、本実施形態におけるトラックの統合化編集は、ＡＯＢファイルの暗号化を維持したまま、ＴＫＩ＿ＢＬＫ＿ＡＴＲの属性変更のみで実現されることがわかる。
【０１２０】
［１７−５＿２２−１８＿２９Ａ，Ｂ−１＿３０，３１］　トラックを統合する場合に満たすべき条件
トラックの統合は、ＴＫＩ＿ＢＬＫ＿ＡＴＲの属性変更にて実現されることは上述した通りであるが、トラックの統合にあたっては、統合されるトラックに含まれるＡＯＢが以下の条件を満たしていることが要求される。
１つ目の条件とは、後続するトラックに含まれるＡＯＢと、先行するトラックに含まれるＡＯＢとのオーディオ属性（オーディオコーディングモード、ビットレート、サンプリング周波数、チャネル数）が一致していることである。これは、ＡＯＢのオーディオ属性が前後のＡＯＢで異なると、再生装置は、デコーダの動作を一旦リセットする必要があり、連続する２つのＡＯＢをシームレスに（途切れることなく）再生することが困難になるという理由による。
【０１２１】
２つ目の条件とは、統合後により得られるトラックにおいて、ＡＯＢ＿ＦＲＡＭＥ数が『ＦＮｓ＿Ｍｉｄｄｌｅ＿ＴＭＳＲＴＥ』に満たないＡＯＢ＿ＥＬＥＭＥＮＴのみからなるＡＯＢが３つ以上連続しないことである。
ＡＯＢ＿ＥＬＥＭＥＮＴのうち少なくとも１つが、『ＦＮｓ＿Ｍｉｄｄｌｅ＿ＴＭＳＲＴＥ』にて指示されたフレーム数と同数のＡＯＢ＿ＦＲＡＭＥを有しているか否かにより、ＡＯＢは２つのタイプに分類される。１つ目のタイプのＡＯＢは、『ＦＮｓ＿Ｍｉｄｄｌｅ＿ＴＭＳＲＴＥ』にて指示されたフレーム数と同数のＡＯＢ＿ＦＲＡＭＥを有するＡＯＢ＿ＥＬＥＭＥＮＴを少なくとも１つ有しているＡＯＢであり、２つ目のタイプのＡＯＢは、『ＦＮｓ＿Ｍｉｄｄｌｅ＿ＴＭＳＲＴＥ』にて指示されたフレーム数と同数のＡＯＢ＿ＦＲＡＭＥを有しているＡＯＢ＿ＥＬＥＭＥＮＴを一切有していないＡＯＢである。即ち、２つ目のタイプのＡＯＢにおけるＡＯＢ＿ＥＬＥＭＥＮＴは、何れも『ＦＮｓ＿Ｍｉｄｄｌｅ＿ＴＭＳＲＴＥ』にて指示されたフレーム数を下回っており、上述した２つ目の条件は、Ｔｙｐｅ２のＡＯＢが３つ以上連続することを禁じているのである。その禁止理由は以下の通りである。即ちＡＯＢを順次読み出してゆく際、再生装置内のバッファは、充分な数のＡＯＢ＿ＦＲＡＭＥにて満たされていることが望ましいが、Ｔｙｐｅ２のＡＯＢが連続していると、再生装置内のバッファを、ＡＯＢ＿ＦＲＡＭＥで満たすことができなくなる。そうすると、再生装置内のバッファがアンダーフローを起こし、ＡＯＢの再生の連続性が保てなくなる。そうしたアンダフローの発生を避けるため、Ｔｙｐｅ２のＡＯＢが３つ以上連続することを２つ目の条件は禁じているのである。
【０１２２】
図３０（ａ）は、Ｔｙｐｅ１のＡＯＢを示し、図３０（ｂ）は、Ｔｙｐｅ２のＡＯＢを示す図である。図３０（ｂ）におけるＡＯＢは２つ以下のＡＯＢ＿ＥＬＥＭＥＮＴのみからなり、それら２つ以下のＡＯＢ＿ＥＬＥＭＥＮＴは、『ＦＮｓ＿Ｍｉｄｄｌｅ＿ＴＭＳＲＴＥ』に示されるＡＯＢ＿ＦＲＡＭＥを有していない（尚、この場合ＢＩＴには、ＦＮｓ＿１ｓｔ＿ＴＭＳＲＴＥのみが記述される。）。
『ＦＮｓ＿Ｍｉｄｄｌｅ＿ＴＭＳＲＴＥ』に示されるＡＯＢ＿ＦＲＡＭＥを有していないことがＴｙｐｅ２ＡＯＢの要件なので、たった１つのＡＯＢ＿ＦＲＡＭＥにより構成されるＡＯＢであっても、このＴｙｐｅ２のＡＯＢに分類されることなる。
【０１２３】
図３１（ａ）は、Ｔｙｐｅ１＋Ｔｙｐｅ２＋Ｔｙｐｅ２＋Ｔｙｐｅ１の組み合わせで、複数トラックを１つに統合する場合を示す図である。この場合、Ｔｙｐｅ２のＡＯＢが３つ連続することは避けられているので、これらは１つのトラックに統合される。
図３１（ｂ）は、Ｔｙｐｅ１＋Ｔｙｐｅ２＋Ｔｙｐｅ２＋Ｔｙｐｅ２＋Ｔｙｐｅ１の組み合わせで、複数トラックを１つに統合する場合を示す図である。この場合、Ｔｙｐｅ２のＡＯＢが３つ連続しているので、これらを１つのトラックに統合することは禁じられる。
【０１２４】
［１７−５＿２２−１８＿２９Ａ，Ｂ−１＿３２］　　Ｔｙｐｅ１、Ｔｙｐｅ２の組合せを考慮したトラック統合
図３１（ａ）に示したトラックの統合によれば、先行するトラックの終端がＴｙｐｅ１である場合、このトラックは、先頭にＴｙｐｅ２のＡＯＢを配したトラック、又は、先頭にＴｙｐｅ１のＡＯＢを配したトラックと統合することができる。図３２（ａ）は、先行するトラックの終端にＴｙｐｅ１のＡＯＢが配され、後続するトラックの先頭にＴｙｐｅ１のＡＯＢが配されている配置パターンを示す図である。また図３２（ｂ）は、先行するトラックの終端にＴｙｐｅ１のＡＯＢが配され、後続するトラックの先頭にＴｙｐｅ２のＡＯＢが配されている配置パターンを示す図である。これらは何れも、条件２を満たすので、１つのトラックに統合することができる。
【０１２５】
先行するトラックの終端がＴｙｐｅ２であり、そのＴｙｐｅ２の直前にＴｙｐｅ１のＡＯＢが配置されている場合、このトラックは、先頭がＴｙｐｅ１のトラック、又は、先頭にＴｙｐｅ２のＡＯＢが配され、その直後にＴｙｐｅ１のＡＯＢが配置されたトラックと統合することができる。
図３２（ｃ）は、先行するトラックの終端にＴｙｐｅ１、Ｔｙｐｅ２順でＡＯＢが配され、後続するトラックの先頭にＴｙｐｅ１のＡＯＢが配されている配置パターンを示す図である。図３２（ｄ）は、先行するトラックの終端にＴｙｐｅ１、Ｔｙｐｅ２順でＡＯＢが配され、後続するトラックの先頭に、Ｔｙｐｅ２、Ｔｙｐｅ１のＡＯＢが配されている配置パターンを示す図である。これらも、条件２を満たすので、１つのトラックに統合することができる。
【０１２６】
先行するトラックの終端がＴｙｐｅ２であり、そのＴｙｐｅ２の直前にＴｙｐｅ２のＡＯＢが配置されている場合、このトラックは、先頭にＴｙｐｅ１のＡＯＢが配されたトラックと統合することができる。図３２（ｅ）は、先行するトラックの終端にＴｙｐｅ２、Ｔｙｐｅ２のＡＯＢが配され、後続するトラックの先頭にＴｙｐｅ１のＡＯＢが配されている配置パターンを示す図である。これも、条件２を満たすので、１つのトラックに統合することができる。以上のように、トラックの統合にあたっては、統合されるべき２つのトラックが上述した２つの条件を満たすかを前もって判定し、これらの２つの条件を満たすと判定された場合のみ、２つのトラックを１つに統合する。
【０１２７】
続いてトラックの分割（ｃａｓｅ４）を行う際の、ＴＫＩの更新について説明する。
［１７−５＿２２−１９＿３３Ａ，Ｂ］　トラックを分割する場合のＴＫＩ設定
図３３（ａ）、（ｂ）は、１つのトラックを２つのトラックに分割する場合を想定した図である。本図におけるＴｒａｃｋＭａｎａｇｅｒは、図２７に示すＴｒａｃｋＭａｎａｇｅｒと同一であり、本図において、ＴｒａｃｋＣをＴｒａｃｋＣ−ＴｒａｃｋＦという２つのトラックに分割するという編集を操作者が希望しているものとする。ＴｒａｃｋＣをＴｒａｃｋＣ−ＴｒａｃｋＦに分割しようとすると、ＴｒａｃｋＦに対応するＡＯＢ００２．ＳＡ１が生成される。図３３（ａ）では、ＴＫＩ＃２が『Ｕｎｕｓｅｄ』に設定されており、分割の結果、図３３（ｂ）に示すように『Ｕｎｕｓｅｄ』に設定されているＴＫＩ＃２は、新たに生成されたＡＯＢ００２．ＳＡ１に割り当てられる。
【０１２８】
［１７−５＿２２−１９＿３３Ａ，Ｂ−１＿３４Ａ，Ｂ］
ディレクトリエントリー及びＦＡＴ値の更新
ここでＡＯＢ００３．ＳＡ１を分割して、ＡＯＢ００２．ＳＡ１を生成する際、ディレクトリエントリー及びＦＡＴ値を更新せねばならない。これらディレクトリエントリー及びＦＡＴ値をどのように更新するかを以下に説明する。図３４（ａ）は、分割前において、ＡＯＢ００３．ＳＡ１が属するＳＤ＿ＡｕｄｉｏディレクトリについてのＳＤ＿Ａｕｄｉｏディレクトリエントリーがどのように記述されているかを示す図である。ＡＯＢ００３．ＳＡ１は、複数に分割されて、クラスタ００７，００８，００９，００Ａ・・・・００Ｄ，００Ｅに格納されているものとする。この場合、ディレクトリエントリーにおけるＡＯＢ００３．ＳＡ１について『ファイル最初のクラスタ番号』は、『００７』と記述され、クラスタ００７，００８，００９，００Ａ・・・・００Ｄに対応するＦＡＴ値００７，００８，００９，００Ａ・・・・００Ｄは、それぞれ（００８），（００９），（００Ａ）・・・・（００Ｄ），（００Ｅ）と記述されている。
【０１２９】
この状態でＡＯＢ００３．ＳＡ１の後半部を分割してＡＯＢ００２．ＳＡ１を得る場合、ＳＤ＿Ａｕｄｉｏディレクトリエントリーには、ＡＯＢ００２．ＳＡ１についての『ファイル名』、『ファイル拡張子』、『ファイル最初のクラスタ番号』が追加される。図３４（ｂ）は、分割後において、ＡＯＢ００３．ＳＡ１が属するＳＤ＿ＡｕｄｉｏディレクトリについてのＳＤ＿Ａｕｄｉｏディレクトリエントリーがどのように記述されているかを示す図である。
【０１３０】
本図におけるクラスタ００Ｆは、操作者により指定された分割境界を含むクラスタ００Ｂの内容のコピーを格納したものである。クラスタ００Ｂに格納されているＡＯＢ００２．ＳＡ１の分割部分に後続する分割部分は、クラスタ００Ｃ，００Ｄ，００Ｅ以降に格納されている。ＡＯＢ００２．ＳＡ１の先頭部分はクラスタ００Ｆに格納され、残りの部分は、クラスタ００Ｃ，００Ｄ，００Ｅ以降に格納されているので、ＡＯＢ００２．ＳＡ１についての『ファイル最初のクラスタ番号』には、クラスタ００Ｆを示すクラスタ番号００Ｆが記述され、クラスタ００Ｆ，００Ｃ，００Ｄ，００Ｅに対応づけられているＦＡＴ値００Ｆ，００Ｃ，００Ｄ，００Ｅには、（００Ｃ），（００Ｄ），（００Ｅ）が記述される。
【０１３１】
［１７−５＿２２−１９＿３３Ａ，Ｂ−２＿３５Ａ，Ｂ］　ＴＫＩ内の情報要素の設定
以上のディレクトリエントリー及びＦＡＴ値の更新によりＡＯＢ００２．ＳＡ１を得た後、ＡＯＢ００２．ＳＡ１についてのＴＫＩ内の情報要素をどのように設定するかについて説明する。分割されたトラックについてのＴＫＩを生成する場合、ＴＫＩの情報要素には、元のＴＫＩに記載されているものをコピーして継承すればよいもの（１）、元のＴＫＩに基づいて更新せねばならないもの（２）の二種類が存在する。前者に該当するのは、ＴＫＴＸＴＩ＿ＤＡ，ＩＳＲＣであり、後者に該当するのは、ＢＩＴ、ＴＫＴＭＳＲＴを初めとする残りの構成要素である。これら両者が存在するので、本実施形態では、分割されたトラックについてのＴＫＩを生成する際、分割元のＴＫＩをコピ−して新たなＴＫＩの雛型を作成すると共に、それに含まれるＴＫＴＭＳＲＴ、ＢＩＴを分割・更新を行い、残りの情報要素を更新するという手順がなされる。
【０１３２】
図３５（ａ）は、ＡＯＢを任意のＡＯＢ＿ＦＲＡＭＥで分割する場合を想定した図である。本図において第１段目は、４つのＡＯＢ＿ＥＬＥＭＥＮＴであるＡＯＢ＿ＥＬＥＭＥＮＴ＃１、ＡＯＢ＿ＥＬＥＭＥＮＴ＃２、ＡＯＢ＿ＥＬＥＭＥＮＴ＃３、ＡＯＢ＿ＥＬＥＭＥＮＴ＃４を示す。これら４つのＡＯＢ＿ＥＬＥＭＥＮＴのそれぞれのデータ長は、４つのＴＭＳＲＴ＿ｅｎｔｒｙ＃ｋ−１，＃ｋ，＃ｋ＋１，＃ｋ＋２（ここでｋ＝２とする）としてＴＫＴＭＳＲＴに設定されている。本図において、ＡＯＢ＿ＥＬＥＭＥＮＴ＃２において分割境界ｂｄ１が設定されたとすると、ＡＯＢ＿ＥＬＥＭＥＮＴ＃２は、分割境界ｂｄ１より前方のフレームからなる領域▲１▼と、分割境界ｂｄ１より後方のフレームからなる領域▲２▼とに分割される。図３５（ｂ）は、ＡＯＢ＿ＥＬＥＭＥＮＴ＃２の途中部分でＡＯＢが分割されて、ＡＯＢ＿１、ＡＯＢ＿２という２つのＡＯＢが得られた状態を示す図である。
【０１３３】
［１７−５＿２２−１９＿３３Ａ，Ｂ−３＿３６］　　ＢＩＴの設定
図３６は、図３５に示したようにＡＯＢが分割された場合に、ＢＩＴがどのように設定されるかを示す図である。図３５に示したＡＯＢは、分割境界ｂｄ１にて分割されており、その分割により得られたＡＯＢ＿１は、ＡＯＢ＿ＥＬＥＭＥＮＴ＃１と、ＡＯＢ＿ＥＬＥＭＥＮＴ＃２という２つのＡＯＢ＿ＥＬＥＭＥＮＴを含み、ＡＯＢ＿２は、ＡＯＢ＿ＥＬＥＭＥＮＴ＃１、ＡＯＢ＿ＥＬＥＭＥＮＴ＃２、ＡＯＢ＿ＥＬＥＭＥＮＴ＃３という３つのＡＯＢ＿ＥＬＥＭＥＮＴを含んでいることがわかる。
【０１３４】
これらのＡＯＢ＿ＥＬＥＭＥＮＴのそれぞれにも、三角旗状の記号が付与されているが、これらは、それぞれＡＯＢに対応するＴＫＩに含まれるＴＭＳＲＴ＿ｅｎｔｒｙが設定されていることを示す。先ず最初に分割により得られたＡＯＢ＿１について説明する。ＡＯＢ＿１に含まれるＡＯＢ＿ＥＬＥＭＥＮＴ＃１、ＡＯＢ＿ＥＬＥＭＥＮＴ＃２は、クラスタ００７〜クラスタ００Ａを占有しているので、ＡＯＢ＿１は、クラスタ００７〜クラスタ００Ａを一単位として扱われる。ここでＡＯＢ＿１におけるＡＯＢ＿ＥＬＥＭＥＮＴ＃２は、クラスタ００Ａの終端迄を占有しているのではなく、クラスタ００Ａの存在する分割境界ｂｄ１迄を占有しているのでＡＯＢ＿１についてのＳＺ＿ＤＡＴＡは、領域ｍｄ０から、クラスタ００Ａにおける分割境界ｂｄ１までのデータ長を指示することになる。ＡＯＢ＿１の『ＦＮｓ＿１ｓｔ＿ＴＭＳＲＴＥ』は分割前と変わらないが、ＡＯＢ＿１の『ＦＮｓ＿Ｌａｓｔ＿ＴＭＳＲＴＥ』は、ＡＯＢ＿ＥＬＥＭＥＮＴ＃２の分割前の先頭から、分割境界ｂｄ１までのフレーム数を指示している点が分割前と異なる。
【０１３５】
続いて分割により得られたＡＯＢ＿２について説明する。ＡＯＢ＿２に含まれるＡＯＢ＿ＥＬＥＭＥＮＴ＃１、ＡＯＢ＿ＥＬＥＭＥＮＴ＃２、ＡＯＢ＿ＥＬＥＭＥＮＴ＃３は、クラスタ００Ｂ〜クラスタ００Ｆを占有している。クラスタ００Ｆとは、クラスタ００Ａの内容のコピーを格納しているクラスタである（クラスタ００Ｆにクラスタ００Ａのコピーを格納している理由は、クラスタ００Ａは、ＡＯＢ＿１のＡＯＢ＿ＥＬＥＭＥＮＴ＃２により占有されているので、このクラスタと異なるクラスタをＡＯＢ＿２に含まれるＡＯＢ＿ＥＬＥＭＥＮＴ＃１に割り当てる必要があるからである。）。
【０１３６】
ＡＯＢ＿２におけるＡＯＢ＿ＥＬＥＭＥＮＴ＃１は、クラスタ００Ｆの先端から占有しているのではなく、クラスタ００Ｆの存在する分割境界ｂｄ１以降を占有しているのでＡＯＢ＿２についてのＳＺ＿ＤＡＴＡは、クラスタ００Ｂの先頭から、クラスタ００Ｅにおける途中部分までのデータ長と、クラスタ００ＦにおいてＡＯＢ＿ＥＬＥＭＥＮＴ＃１が占有しているデータ長との和を指示することになる。
【０１３７】
クラスタ００Ｆに格納されているクラスタ００Ａのコピーには、ＡＯＢ＿１のＡＯＢ＿ＥＬＥＭＥＮＴ＃２が記録されており、ＡＯＢ＿１のＡＯＢ＿ＥＬＥＭＥＮＴ＃２により占有されている部分を、ＡＯＢ＿２から除外されねばならないので、ＡＯＢ＿２のＢＩＴについてのＤＡＴＡ＿Ｏｆｆｓｅｔは、クラスタ００ＦにおいてＡＯＢ＿１のＡＯＢ＿ＥＬＥＭＥＮＴ＃２により占有されているサイズが設定されている。
【０１３８】
この図からもわかるように、ＡＯＢの分割においては、分割境界を含むＡＯＢ＿ＥＬＥＭＥＮＴのみが２つに分割され、その分割境界の前後のＡＯＢ＿ＥＬＥＭＥＮＴは、分割前のものから変化していないことがわかる。そのため、ＡＯＢ＿２の『ＦＮｓ＿Ｌａｓｔ＿ＴＭＳＲＴＥ』は、分割前のＡＯＢ＿ＥＬＥＭＥＮＴ＃４の『ＦＮｓ＿Ｌａｓｔ＿ＴＭＳＲＴＥ』と同じ値に設定され、ＡＯＢ＿２の『ＦＮｓ＿１ｓｔ＿ＴＭＳＲＴＥ』は、ＡＯＢ＿２のＡＯＢ＿ＥＬＥＭＥＮＴ＃１、即ち、分割前のＡＯＢ＿ＥＬＥＭＥＮＴ＃２における分割境界以降の終端部分に含まれるフレーム数が設定される。
【０１３９】
［１７−５＿２２−１９＿３３Ａ，Ｂ−４＿３７］　　ＢＩＴの設定
図３７は、分割の前後でＢＩＴがどのように変化するかを更に具体的に示す図である。図３７の左側のＢＩＴは、分割前のＢＩＴの設定例を示す。トラックを分割する前のＢＩＴは、Ｄａｔａ＿ＯｆｆｓｅｔがＸに設定され、ＳＺ＿ＤＡＴＡが『５２４２８』、ＴＭＳＲＴＥ＿Ｎｓが『ｎ』個と設定される。ＦＮｓ＿１ｓｔ＿ＴＭＳＲＴＥは『８０フレーム』、ＦＮｓ＿Ｍｉｄｄｌｅ＿ＴＭＳＲＴＥについては『９４フレーム』に設定され、ＦＮｓ＿Ｌａｓｔ＿ＴＭＳＲＴＥは『５０フレーム』に設定されることがわかる。
【０１４０】
図３７の右側に、分割後の２つのトラックについてのＢＩＴの設定を示す。本ＢＩＴに対応するＡＯＢが図３５（ａ）に示すように分割された場合、１トラック目のＢＩＴにおいて、Ｄａｔａ＿Ｏｆｆｓｅｔは分割前と同一値『ｘ』に設定されるが、ＳＺ＿ＤＡＴＡに分割点ｂｄ１までのデータ長『Ｑ』に更新され、ＴＭＳＲＴＥ＿Ｎｓには、１番目のＴＭＳＲＴ＿ｅｎｔｒｙからｋ番目のＴＭＳＲＴ＿ｅｎｔｒｙまでのＴＭＳＲＴ＿ｅｎｔｒｙの個数である『ｋ個』に更新される。ＦＮｓ＿１ｓｔ＿ＴＭＳＲＴＥ及びＦＮｓ＿Ｍｉｄｄｌｅ＿ＴＭＳＲＴＥについては分割前同様、８０，９４フレームに設定されるが、分割後の１トラック目のＡＯＢの最後のＡＯＢ＿ＥＬＥＭＥＮＴには、図３５（ａ）においてｐ個のＡＯＢ＿ＦＲＡＭＥが含まれているので、ＦＮｓ＿Ｌａｓｔ＿ＴＭＳＲＴＥは『ｐフレーム』に設定される。
【０１４１】
２トラック目のＢＩＴは、Ｄａｔａ＿ＯｆｆｓｅｔがＲに設定され、ＳＺ＿ＤＡＴＡがオリジナルのＳＺ＿ＤＡＴＡ５２４２８−分割点ｂｄ１までのデータ長『Ｑ』、ＴＭＳＲＴＥ＿Ｎｓがｎ−ｋ＋１個と設定される（ｋ番目のＴＭＳＲＴ＿ｅｎｔｒｙからｎ番目のＴＭＳＲＴ＿ｅｎｔｒｙまでのＴＭＳＲＴ＿ｅｎｔｒｙ個数であるｎ−ｋ個と、分割のために新たに追加されたｋ番目のＴＭＳＲＴ＿ｅｎｔｒｙの個数である１個とを加算した数である。）。ＦＮｓ＿Ｍｉｄｄｌｅ＿ＴＭＳＲＴＥ及びＦＮｓ＿Ｌａｓｔ＿ＴＭＳＲＴＥについては分割前同様、９４，５０フレームに設定されるが、分割後の２トラック目のＡＯＢの最初のＡＯＢ＿ＥＬＥＭＥＮＴには、９４−ｐ個のＡＯＢ＿ＦＲＡＭＥが含まれているので、ＦＮｓ＿１ｓｔ＿ＴＭＳＲＴＥは『９４−ｐフレーム』に設定される。
【０１４２】
［１７−５＿２２−１９＿３３Ａ，Ｂ−５＿３８］　　ＢＩＴの設定
図３８は、分割後のＴＫＴＭＳＲＴを示す図である。まずＴＭＳＲＴについては以下のようになる。１トラック目のＴＭＳＲＴは分割前のＡＯＢのＴＭＳＲＴのはじめからｋ番目のエントリまで（ＴＭＳＲＴ＿ｅｎｔｒｙ＃１〜ＴＭＳＲＴ＿ｅｎｔｒｙ＃ｋ）を含む。ここで注意すべきは、分割境界を含むＡＯＢ＿ＥＬＥＭＥＮＴ＃ｋは、領域▲１▼を含むのみなので、このｋ番目のエントリーは、この領域▲１▼に相当する部分のデータサイズのみが含まれている。２トラック目のＴＭＳＲＴは、分割前のｋ番目のエントリからｎ番目のエントリまで（ＴＭＳＲＴ＿ｅｎｔｒｙ＃ｋ〜ＴＭＳＲＴ＿ｅｎｔｒｙ＃ｎ）を含む。ここで注意すべきは、分割境界を含むＡＯＢ＿ＥＬＥＭＥＮＴ＃ｋは、２トラック目において領域▲２▼を含むのみなので、分割前のｋ番目のエントリーは、この領域▲２▼に相当する部分のデータサイズのみが含まれている。
【０１４３】
ＴＫＩをコピ−すると共に、ＴＫＴＭＳＲＴ、ＢＩＴを分割・更新を行い、残りの情報要素を更新すれば、分割により得られた新たなトラックについてのＴＫＩが得られることになる。統合の場合と同様、暗号化されたＡＯＢファイルを復号化することなく、暗号化された状態のままＡＯＢファイルに対応するトラックを２つに分割することができる。ＡＯＢファイル分割の際に復号・再暗号化が伴わないので、トラックを分割する際の処理負荷が軽減されていることがわかる。これにより、再生装置の処理性能が低い場合でも、トラックの編集を行うことができる。
【０１４４】
以上長文となったが、ＴＫＩについての説明を終了する。続いてプレイリストについて説明する。
［１７−６］　Ｐｌａｙｌｉｓｔｍａｎａｇｅｒ
図１７に示すＰｌａｙｌｉｓｔｍａｎａｇｅｒは、破線の引き出し線ｈ５に示すように、フラッシュメモリカード３１内に格納されているプレイリストを管理するＰｌａｙｌｉｓｔＭａｎａｇｅｒ＿Ｉｎｆｏｒｍａｔｉｏｎ（ＰＬＭＧＩ）と、フラッシュメモリカード３１に格納される全トラックを管理するＤｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ＿Ｉｎｆｏｒｍａｔｉｏｎ（ＤＰＬＩ）と、ＰｌａｙｌｉｓｔＩｎｆｏｒｍａｔｉｏｎ（ＰＬＩ）＃１，＃２，＃３，＃４，＃５・・・・・＃ｎとからなり、Ｄｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報は、破線の引き出し線ｈ６に示すように、Ｄｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ＿Ｇｅｎｅｒａｌ＿Ｉｎｆｏｒｍａｔｉｏｎ（ＤＰＬＧＩ），Ｄｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ＿Ｔｒａｃｋ＿Ｓｅｒｃｈ＿Ｐｏｉｎｔｅｒ（ＤＰＬ＿ＴＫ＿ＳＲＰ）＃１，＃２，＃３，＃４・・・・＃ｍからなることがわかる。また各ＰＬＩは、破線の引き出し線ｈ７に示すように、Ｐｌａｙｌｉｓｔ＿Ｇｅｎｅｒａｌ＿Ｉｎｆｏｒｍａｔｉｏｎ（ＰＬＧＩ），Ｐｌａｙｌｉｓｔ＿Ｔｒａｃｋ＿Ｓｅｒｃｈ＿Ｐｏｉｎｔｅｒ（ＰＬ＿ＴＫ＿ＳＲＰ）＃１，＃２，＃３，＃４・・・・＃ｍからなることがわかる。
【０１４５】
ここでＤｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報と、ＰｌａｙＬｉｓｔ情報との差違について説明しておく。Ｄｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報は、全てのトラックを指定することが義務付けられているのに対して、ＰｌａｙＬｉｓｔ情報は、そのような義務は存在せず、任意のトラックを指定すれば良い。そのため、ユーザが、自分の好みのトラックのみを指定しているようなＰｌａｙＬｉｓｔ情報を生成してフラッシュメモリカード３１に記憶させたり、またフラッシュメモリカード３１に記憶される複数のトラックのうち、所定のジャンルのトラックのみを指定しているようなＰｌａｙＬｉｓｔ情報を再生装置が自動的に生成してフラッシュメモリカード３１に記憶させるという用途に適している。
【０１４６】
［１７−７＿１８］　　プレイリストの個数、データサイズ
図１８を参照すると、プレイリストの最大数は９９個である。また、Ｐｌａｙｌｉｓｔ　Ｍａｎａｇｅｒ　Ｉｎｆｏｒｍａｔｉｏｎ（ＰＬＭＧＩ）とＤｅｆａｕｌｔ　Ｐｌａｙｌｉｓｔ　Ｉｎｆｏｒｍａｔｉｏｎ（ＤＰＬＩ）は、合計で２５６０バイトの固定長である。Ｐｌａｙｌｉｓｔ　Ｉｎｆｏｒｍａｔｉｏｎ（ＰＬＩ）もまた、５１２バイトの固定長である。Ｄｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報に含まれるＤＰＬ＿ＴＫ＿ＳＲＰは、ＤＰＬ＿ＴＫ＿ＡＴＲ，ＤＰＬ＿ＴＫＩＮを含んでいる。一方、ＰｌａｙＬｉｓｔ情報に含まれるＰＬ＿ＴＫ＿ＳＲＰは、ＰＬ＿ＴＫＩＮのみを含んでいる。これらのＤＰＬ＿ＴＫ＿ＡＴＲ，ＤＰＬ＿ＴＫＩＮ，ＰＬ＿ＴＫＩＮは、図３９に示すフォーマットを有する。
【０１４７】
［１７−８＿３９−１］　　ＤＰＬ＿ＴＫ＿ＳＲＰのフォーマット
図３９（ａ）は、ＤＰＬ＿ＴＫ＿ＳＲＰのフォーマットを示す図である。図３９（ａ）においてＤＰＬ＿ＴＫ＿ＳＲＰは、０ビット目から９ビット目までに、ＤＰＬ＿ＴＫＩＮが記述され、１３ビット目から１５ビットまでには、ＤＰＬ＿ＴＫ＿ＡＴＲが記述され、１０ビット目から１２ビットまでは予約用に確保（ｒｅｓｅｒｖｅｄ）されている。
【０１４８】
次に、０ビット目から９ビット目までのフィールドを占めるＤＰＬ＿ＴＫＩＮには、ＴＫＩ番号が記述される。ここにＴＫＩ番号を記述することにより、ＴＫＩを特定することが可能となる。
［１７−９＿３９Ｂ］　ＰＬ＿ＴＫ＿ＳＲＰのフォーマット
図３９（ｂ）は、ＰＬ＿ＴＫ＿ＳＲＰのフォーマットを示す図である。ＰＬ＿ＴＫ＿ＳＲＰは、０ビット目から９ビット目までのフィールドを有しており、ここにＰＬ＿ＴＫＩＮ、即ち、ＴＫＩ番号が記述される。
【０１４９】
［１７−８＿３９Ａ−２］　ＤＰＬ＿ＴＫ＿ＡＴＲの構成
図３９（ａ）の『ＤＰＬ＿ＴＫ＿ＡＴＲ』から破線の矢印ｈ５１，ｈ５２にて引き出された枠内に、ＤＰＬ＿ＴＫ＿ＡＴＲの設定例を示す。この枠内の記載からも理解できるように、ＤＰＬ＿ＴＫ＿ＳＲＰについてのＤＰＬ＿ＴＫ＿ＡＴＲの設定は、ＴＫＩについてのＴＫＩ＿ＢＬＫ＿ＡＴＲの設定と同一であり、『Ｔｒａｃｋ』、『Ｈｅａｄ＿ｏｆ＿Ｔｒａｃｋ』、『Ｍｉｄｐｏｉｎｔ＿ｏｆ＿Ｔｒａｃｋ』、『Ｅｎｄ＿ｏｆ＿Ｔｒａｃｋ』の何れかが設定される。
【０１５０】
具体的には、ＴＫＩＮにて指定されたＴＫＩが使用中であり、当該ＴＫＩに対応するＡＯＢファイルに１個のトラックに対応するオーディオオブジェクトが収録されている場合（ＴＫＩのＴＫＩ＿ＢＬＫ＿ＡＴＲにおける『Ｔｒａｃｋ』）、ＤＰＬ＿ＴＫ＿ＡＴＲは”０００ｂ”の値が設定される。
ＴＫＩＮにて指定されたＴＫＩが使用中であり、当該ＴＫＩに対応するＡＯＢファイルにトラックの先頭部のみに対応するオーディオオブジェクトが収録されている場合（ＴＫＩのＴＫＩ＿ＢＬＫ＿ＡＴＲにおける『Ｈｅａｄ＿ｏｆ＿Ｔｒａｃｋ』）、ＤＰＬ＿ＴＫ＿ＡＴＲは”００１ｂ”の値が設定される。
【０１５１】
ＴＫＩＮにて指定されたＴＫＩが使用中であり、当該ＴＫＩに対応するＡＯＢファイルにトラックの中間部のみに対応するオーディオオブジェクトが収録されている場合（ＴＫＩのＴＫＩ＿ＢＬＫ＿ＡＴＲにおける『Ｍｉｄｐｏｉｎｔ＿ｏｆ＿Ｔｒａｃｋ』）、ＤＰＬ＿ＴＫ＿ＡＴＲには”０１０ｂ”の値が設定される。
ＴＫＩＮにて指定されたＴＫＩが使用中であり、当該ＴＫＩに対応するＡＯＢファイルにトラックの終端部のみに対応するオーディオオブジェクトが収録されている場合（ＴＫＩのＴＫＩ＿ＢＬＫ＿ＡＴＲにおける『Ｅｎｄ＿ｏｆ＿Ｔｒａｃｋ』）、ＤＰＬ＿ＴＫ＿ＡＴＲには、”０１１ｂ”の値が設定される。
【０１５２】
ＴＫＩＮにて指定されたＴＫＩが未使用であり、ＴＫＩの領域のみが確保されている場合、すなわち削除されたＴＫＩである場合（ＴＫＩのＴＫＩ＿ＢＬＫ＿ＡＴＲにおける『Ｕｎｕｓｅｄ』）、”１００ｂ”の値が設定される。
ＴＫＩＮにて指定されたＴＫＩが未使用であり、ＴＫＩの領域が確保されていない場合、すなわち初期状態のＴＫＩである場合は、”１０１ｂ”の値が設定される。
【０１５３】
『ＤＰＬ＿ＴＫ＿ＳＲＰ』は、ＤＰＬ＿ＴＫＩＮにＴＫＩの番号を記述することにより、複数のＴＫＩのうち、何れかのものとの対応関係を有する。また、Ｄｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報におけるＤＰＬ＿ＴＫ＿ＳＲＰの順位は、ＤＰＬ＿ＴＫ＿ＳＲＰと対応関係を有するＴＫＩに対応するＡＯＢ（ＡＯＢファイル）が何番目に再生されるかを示す。これらのことにより、Ｄｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報におけるＤＰＬ＿ＴＫ＿ＳＲＰの順序は、複数のトラックをどのような順序で再生させるか、即ち、トラックの再生順序を定義することなる。
【０１５４】
［１７−９＿４０−１］　　Ｄｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報、ＴＫＩ、ＡＯＢファイルの相互関係
図４０は、Ｄｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報、ＴＫＩ、ＡＯＢファイルの相互関係を示す図である。本図における第２、第３、第４段目は、図１９の第１段目、第２段目、第３段目と同一であり、８つのＴＫＩを含むＴｒａｃｋＭａｎａｇｅｒ、８つのＡＯＢファイルを示す。図１９と異なるのは、第１段目にＤｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報を示す四角枠が記述されている点である。第１段目の枠に含まれる８つの小枠は、Ｄｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報に含まれる８つのＤＰＬ＿ＴＫ＿ＳＲＰを示す。これらの小枠の上段はＤＰＬ＿ＴＫ＿ＡＴＲを示し、下段はＤＰＬ＿ＴＫＩＮを示す。
【０１５５】
本図における矢印ＤＴ１，ＤＴ２，ＤＴ３，ＤＴ４・・・・・を参照すれば、ＤＰＬ＿ＴＫ＿ＳＲＰ＃１と、ＴＫＩ＃１との間に対応関係が成立しており、ＤＰＬ＿ＴＫ＿ＳＲＰ＃２と、ＴＫＩ＃２との間、ＤＰＬ＿ＴＫ＿ＳＲＰ＃３と、ＴＫＩ＃３との間、ＤＰＬ＿ＴＫ＿ＳＲＰ＃４と、ＴＫＩ＃４との間にも対応関係が成立していることがわかる。
更に、各ＤＰＬ＿ＴＫ＿ＳＲＰにおけるＤＰＬ＿ＴＫ＿ＡＴＲを参照すれば、ＤＰＬ＿ＴＫ＿ＳＲＰ＃１、ＤＰＬ＿ＴＫ＿ＳＲＰ＃２、ＤＰＬ＿ＴＫ＿ＳＲＰ＃３、ＤＰＬ＿ＴＫ＿ＳＲＰ＃８は何れも、Ｔｒａｃｋと設定されている。即ち、ＤＰＬ＿ＴＫ＿ＳＲＰ＃１→ＴＫＩ＃１（ＡＯＢ００１．ＳＡ１）、ＤＰＬ＿ＴＫ＿ＳＲＰ＃２→ＴＫＩ＃２（ＡＯＢ００２．ＳＡ１）、ＤＰＬ＿ＴＫ＿ＳＲＰ＃３→ＴＫＩ＃３（ＡＯＢ００３．ＳＡ１）、ＤＰＬ＿ＴＫ＿ＳＲＰ＃８→ＴＫＩ＃８（ＡＯＢ００８．ＳＡ１）という４つの組みは、それぞれが独立したトラックに対応しているのである。
【０１５６】
ＤＰＬ＿ＴＫ＿ＳＲＰ＃４、ＤＰＬ＿ＴＫ＿ＳＲＰ＃５、ＤＰＬ＿ＴＫ＿ＳＲＰ＃６、ＤＰＬ＿ＴＫ＿ＳＲＰ＃７のＤＰＬ＿ＴＫ＿ＡＴＲは何れもＴｒａｃｋと設定されず、ＤＰＬ＿ＴＫ＿ＳＲＰ＃４におけるＤＰＬ＿ＴＫ＿ＡＴＲは『Ｈｅａｄ＿ｏｆ＿Ｔｒａｃｋ』と設定され、ＤＰＬ＿ＴＫ＿ＳＲＰ＃７におけるＤＰＬ＿ＴＫ＿ＡＴＲは『Ｅｎｄ＿ｏｆ＿Ｔｒａｃｋ』と、ＤＰＬ＿ＴＫ＿ＳＲＰ＃５、ＤＰＬ＿ＴＫ＿ＳＲＰ＃６は『Ｍｉｄｐｏｉｎｔ＿ｏｆ＿Ｔｒａｃｋ』と設定されていることがわかる。このことは、ＤＰＬ＿ＴＫ＿ＳＲＰ＃４と対応関係を有するＴＫＩ＃４（ＡＯＢ００４．ＳＡ１）が、トラックの先頭部であり、ＤＰＬ＿ＴＫ＿ＳＲＰ＃５，＃６と対応関係を有するＴＫＩ＃５（ＡＯＢ００５．ＳＡ１）及びＴＫＩ＃６（ＡＯＢ００６．ＳＡ１）が、トラックの中間部と、ＤＰＬ＿ＴＫ＿ＳＲＰ＃７と対応関係を有するＴＫＩ＃７（ＡＯＢ００７．ＳＡ１）が、トラックの終端部であることを意味する。
【０１５７】
ＤｅｆａｕｌｔＰｌａｙｌｉｓｔにおけるＤＰＬ＿ＴＫ＿ＳＲＰの順序は、各ＴＫＩに対応づけられているＡＯＢをどのような順序で再生させるかを示す。本図のＤｅｆａｕｌｔＰｌａｙｌｉｓｔ内のＤＰＬ＿ＴＫ＿ＳＲＰ＃１，＃２，＃３，＃４・・・・・・＃８のＤＰＬ＿ＴＫＩＮは、ＴＫＩ＃１，＃２，＃３，＃４・・・・・・＃８を示しているので、矢印（１）（２）（３）（４）・・・・・（８）に示すようにＴＫＩ＃１に対応するＡＯＢ００１．ＳＡ１が１番目に再生され、ＴＫＩ＃２に対応するＡＯＢ００２．ＳＡ１が２番目、ＴＫＩ＃３に対応するＡＯＢ００３．ＳＡ１が３番目、ＴＫＩ＃４に対応するＡＯＢ００４．ＳＡ１が４番目に再生されることになる。
【０１５８】
［１７−１０＿４１］　　ＤｅｆａｕｌｔＰｌａｙｌｉｓｔ、ＰｌａｙＬｉｓｔ情報の設定例
図４１は、ＤｅｆａｕｌｔＰｌａｙｌｉｓｔ、ＰｌａｙＬｉｓｔ情報の設定例を、図４０と同様の表記で示した図である。本図における第１段目における四角枠はＤｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報を示し、第２段目における３つの四角枠はＰｌａｙＬｉｓｔ情報を示す。ＤｅｆａｕｌｔＰｌａｙｌｉｓｔに含まれる小枠は、ＤｅｆａｕｌｔＰｌａｙｌｉｓｔに含まれる８つのＤＰＬ＿ＴＫ＿ＳＲＰを示し、ＰｌａｙＬｉｓｔ情報に含まれる小枠は、３つ又は４つのＰＬ＿ＴＫ＿ＳＲＰを示す。本図のＤｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報に含まれる各ＤＰＬ＿ＴＫ＿ＳＲＰのＴＫＩＮの設定は、図４０と同一である。しかし、ＰｌａｙＬｉｓｔ情報に含まれるＰＬ＿ＴＫ＿ＳＲＰのＴＫＩＮの設定は、ＤＰＬ＿ＴＫ＿ＳＲＰのそれと全く異なることがわかる。
【０１５９】
［１７−１０＿４２］　ＤＰＬ＿ＴＫ＿ＳＲＰとＴＫＩとの対応
図４２は、図４０と同じ表記法を用いてＤＰＬ＿ＴＫ＿ＳＲＰとＴＫＩとの対応を示す図である。図４２においてＰｌａｙｌｉｓｔ＃１は、ＰＬ＿ＴＫ＿ＳＲＰ＃１，＃２，＃３からなる。このうちＰＬ＿ＴＫ＿ＳＲＰ＃１のＰＬ＿ＴＫＩＮは＃３と記載されており、ＰＬ＿ＴＫ＿ＳＲＰ＃２のＰＬ＿ＴＫＩＮは＃１と、ＰＬ＿ＴＫ＿ＳＲＰ＃３のＰＬ＿ＴＫＩＮは＃２と記載されているので、ＰｌａｙＬｉｓｔ情報＃１を用いてトラックを再生する場合、矢印（１１）（１２）（１３）に示すように複数のＡＯＢはＡＯＢ＿３，＃１，＃２の順序で再生される。
【０１６０】
Ｐｌａｙｌｉｓｔ＃２は、ＰＬ＿ＴＫ＿ＳＲＰ＃１，＃２，＃３からなる。このうちＰＬ＿ＴＫ＿ＳＲＰ＃１のＰＬ＿ＴＫＩＮは＃８と記載されており、ＰＬ＿ＴＫ＿ＳＲＰ＃２，＃３のＰＬ＿ＴＫＩＮは＃３、＃１と記載されているので、ＰｌａｙＬｉｓｔ情報＃２を用いてトラックを再生する場合、矢印（２１）（２２）（２３）に示すように複数のＡＯＢはＡＯＢ＃８，＃３，＃１という順序、即ちＰｌａｙｌｉｓｔ＃１と全く異なる順序で再生される。
【０１６１】
Ｐｌａｙｌｉｓｔ＃３は、ＰＬ＿ＴＫ＿ＳＲＰ＃１，＃２，＃３，＃４からなる。このうちＰＬ＿ＴＫ＿ＳＲＰ＃１，＃２，＃３，＃４のＰＬ＿ＴＫＩＮは＃８，＃４，＃３，＃１と記載されているので、ＰｌａｙＬｉｓｔ情報＃３を用いてトラックを再生する場合以下に示す再生順序でＡＯＢが再生される。先ず矢印（３１）に示すようにＴｒａｃｋＥを構成するＡＯＢ＿８が再生され、矢印（３２）に示すようにＴｒａｃｋＤを構成するＡＯＢ＿４，ＡＯＢ＿５，ＡＯＢ＿６，ＡＯＢ＿７がこれに続いて再生される。続いて、矢印（３３）（３４）に示すようにＴｒａｃｋＣ、ＴｒａｃｋＡを構成するＡＯＢ＿３，ＡＯＢ＿１という順序で再生される。ここで注意すべきは、トラックが複数のＴＫＩから構成される場合、ＰＬ＿ＴＫ＿ＳＲＰのエントリーには、複数ＴＫＩのうち、先頭のＴＫＩ番号のみが記述されている点である。具体的にいうと、Ｄｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報におけるＤＰＬ＿ＴＫ＿ＳＲＰは、ＴｒａｃｋＤについての４つのＴＫＩであるＴＫＩ＃４、ＴＫＩ＃５、ＴＫＩ＃６、ＴＫＩ＃７を指定していたが、ＰｌａｙＬｉｓｔ情報におけるＰＬ＿ＴＫ＿ＳＲＰは、それら４つのＴＫＩを指定する必要はない。Ｐｌａｙｌｉｓｔ＃３のＰＬ＿ＴＫ＿ＳＲＰ＃２がＴＫＩ＃４〜ＴＫＩ＃７のうち、ＴＫＩ＃４のみを指定していることは、このことを意味している。
【０１６２】
一方、複数のＤＰＬ＿ＴＫ＿ＳＲＰを含むＤＰＬＩは、１セクタに収まるようなデータサイズを有しており、ＲＡＭ上に常駐されている。そのため、Ｐｌａｙｌｉｓｔに基づいて各トラックを再生する場合、ＲＡＭ上に常駐されているＤＰＬ＿ＴＫ＿ＳＲＰを参照することにより、各ＴＫＩを高速に検索することが可能となる。即ち、複数ＴＫＩのうち、先頭のＴＫＩ番号のみが記述されているＰＬ＿ＴＫ＿ＳＲＰを用いてＴＫＩ（ＡＯＢ）を再生するには、ＰＬ＿ＴＫ＿ＳＲＰに記述されているＴＫＩを元にＲＡＭ上に常駐されているＤＰＬ＿ＴＫ＿ＳＲＰを検索し、トラックが複数のＴＫＩから構成されているか否かを判定する。複数のＴＫＩから構成されている場合には、対応するＴＫＩ（ＡＯＢ）を全て再生するという手順を経るのである。
【０１６３】
以上のように、ＰｌａｙＬｉｓｔＭａｎａｇｅｒにはＤｅｆａｕｌｔＰｌａｙｌｉｓｔ、複数のＰｌａｙＬｉｓｔ情報が記述され、これらを構成するＤＰＬ＿ＴＫ＿ＳＲＰ、ＰＬ＿ＴＫ＿ＳＲＰのＤＰＬ＿ＴＫＩＮ、ＰＬ＿ＴＫＩＮにそれぞれ相異なる再生順序が記載されていれば、複数ＡＯＢは、それぞれ相異なる再生順序で再生されることになる。全く異なる再生順序で再生されれば、操作者は、複数の音楽アルバムが格納されているような感覚でフラッシュメモリカード３１を利用することができる。
【０１６４】
また、注意すべきは、何れもＡＯＢファイルに対応づけられているＤＰＬ＿ＴＫ＿ＳＲＰ、ＴＫＩのうち、ＤＰＬ＿ＴＫ＿ＳＲＰのデータサイズは小さく（２バイトに過ぎない）、ＴＫＩのデータサイズは大きい（１０２４バイトもある。）点である。ＴｒａｃｋＭａｎａｇｅｒにおけるＴＫＩの順序を入れ替えることは、フラッシュメモリカード３１に対するアクセスが多く発生するが、Ｄｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報、ＰｌａｙＬｉｓｔ情報におけるＤＰＬ＿ＴＫ＿ＳＲＰの順序を入れ替えても、フラッシュメモリカード３１に対するアクセスはそれほど多くなならない。この点に鑑み、ナビゲーションデータは、その編集時において、編集操作に応じてＤｅｆａｕｌｔＰｌａｙｌｉｓｔにおけるＤＰＬ＿ＴＫ＿ＳＲＰの順序を積極的に変化させる一方、ＴｒａｃｋＭａｎａｇｅｒにおけるＴＫＩの順序は、編集操作にかかわらず、一定に維持するようにしている。
【０１６５】
［１７−９＿４０−２＿４３Ａ，Ｂ］　　ＤＰＬ＿ＴＫ＿ＳＲＰの順序を入れ替え
次に、Ｄｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報におけるＤＰＬ＿ＴＫ＿ＳＲＰの順序を入れ替えることにより、トラックの再生順序を変更するという編集操作がどう行われるかについて説明する。図４３（ａ）、（ｂ）は、トラックの順序を入れ替える場合を想定した図である。図４３（ａ）におけるＤＰＬ＿ＴＫ＿ＳＲＰ、ＴＫＩの設定は、図４０と同じである。図４０（ａ）においてＤＰＬ＿ＴＫ＿ＳＲＰ＃３におけるＤＰＬ＿ＴＫＩＮはＴＫＩ＃３、ＤＰＬ＿ＴＫ＿ＳＲＰ＃８におけるＤＰＬ＿ＴＫＩＮはＴＫＩ＃８と設定されていたが、この状態において、太枠で囲ったＤＰＬ＿ＴＫ＿ＳＲＰ＃３と、ＤＰＬ＿ＴＫ＿ＳＲＰ＃８との順番を入れ替える。図４３（ｂ）における（１）（２）（３）（４）（５）（６）（７）（８）は、順番入れ替え後のトラックの再生順序を示す。このことに留意すると、図４３（ａ）における再生順序は、ＴｒａｃｋＡ、ＴｒａｃｋＢ、ＴｒａｃｋＣ、ＴｒａｃｋＤ、ＴｒａｃｋＥであるが、図４３（ｂ）におけるＤｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報では、ＤＰＬ＿ＴＫ＿ＳＲＰ＃３、ＤＰＬ＿ＴＫ＿ＳＲＰ＃８についてのＤＰＬ＿ＴＫＩＮの順序が入れ替えられたので、ＴｒａｃｋＡ、ＴｒａｃｋＢ、ＴｒａｃｋＥ、ＴｒａｃｋＤ、ＴｒａｃｋＣの順序で再生されることになる。このように、Ｄｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報における、ＤＰＬ＿ＴＫ＿ＳＲＰの順序を入れ替えることにより、簡易にトラックの再生順序を変更することができる。
【０１６６】
トラックの変更操作という編集操作について説明したところで、ＴＫＩの場合と同様、一部のトラックが削除された場合（ｃａｓｅ１）、一部のトラックが削除された後、新たなトラックを記録する場合（ｃａｓｅ２）、複数のトラックのうち、任意の２つを１つのトラックに統合する場合（ｃａｓｅ３）、１つのトラックを分割して、２つのトラックを得る場合（ｃａｓｅ４）において、ＤＰＬ＿ＴＫ＿ＳＲＰ及びＴＫＩがどのように更新されるかについて説明する。
【０１６７】
［１７−９＿４０−３＿４４Ａ，Ｂ］　　トラックを削除する場合
先ず初めに、一部のトラックが削除された場合（ｃａｓｅ１）について説明する。
図４４（ａ）、（ｂ）は、図４０に示したＤｅｆａｕｌｔＰｌａｙｌｉｓｔのうち、ＤＰＬ＿ＴＫ＿ＳＲＰ＃２及びＴＫＩ＃２を削除する場合にＤｅｆａｕｌｔＰｌａｙｌｉｓｔ、ＴｒａｃｋＭａｎａｇｅｒ、ＡＯＢファイルがどのように更新されるかを示す図である。図４４は、ＴＫＩの削除の説明で引用した図２７と同一部分を有する。即ち、図４４における第２、第３、第４段目は図２７と同一である。異なるのは図４０同様、第１段目に複数のＤＰＬ＿ＴＫ＿ＳＲＰを含むＤｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報が記載されている点である。図４４（ａ）において太枠で囲ったＤＰＬ＿ＴＫ＿ＳＲＰ＃２→ＴＫＩ＃２（ＡＯＢ００２．ＳＡ１）からなるＴｒａｃｋＢをユーザが削除したものとする。この場合、Ｄｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報においてはＤＰＬ＿ＴＫ＿ＳＲＰ＃２が削除されて、ＤＰＬ＿ＴＫ＿ＳＲＰ＃３〜ＤＰＬ＿ＴＫ＿ＳＲＰ＃８は、ＤＰＬ＿ＴＫ＿ＳＲＰ＃２が占有していたフィールドを詰めるように、順番が１つずつ繰り上がる。このように各ＤＰＬ＿ＴＫ＿ＳＲＰの順番を繰り上がり、一番最後のＤＰＬ＿ＴＫ＿ＳＲＰ＃８が『Ｕｎｕｓｅｄ』に設定される。これに対してＴＫＩは、図２７（ａ）、（ｂ）を用いて説明したように『Ｕｎｕｓｅｄ』に設定されているのみで、ＴＫＩ＃２を詰めるような移動は行われていない。またＡＯＢ００２．ＳＡ１は、削除されていることがわかる。ＤＰＬ＿ＴＫ＿ＳＲＰについては順番の繰り上げが行われたが、ＴＫＩについては順番の繰り上げが行われていないので、図４４（ｂ）では、ＤＰＬ＿ＴＫ＿ＳＲＰにおけるＤＰＬ＿ＴＫＩＮが更新されている。即ち、新たなＤＰＬ＿ＴＫ＿ＳＲＰ＃２のＤＰＬ＿ＴＫＩＮは、矢印ＤＴ１１に示すようにＴＫＩ＃３を指示しており、ＤＰＬ＿ＴＫ＿ＳＲＰ＃３のＤＰＬ＿ＴＫＩＮは矢印ＤＴ１２に示すようにＴＫＩ＃４を、ＤＰＬ＿ＴＫ＿ＳＲＰ＃４のＤＰＬ＿ＴＫＩＮはＴＫＩ＃５、ＤＰＬ＿ＴＫ＿ＳＲＰ＃５のＤＰＬ＿ＴＫＩＮはＴＫＩ＃６をそれぞれ指示している。更に、『Ｕｎｕｓｅｄ』に設定されたＤＰＬ＿ＴＫ＿ＳＲＰ＃８のＤＰＬ＿ＴＫＩＮは、矢印ＤＴ１３に示すように、『Ｕｎｕｓｅｄ』に設定されたＴＫＩ＃２を設定していることがわかる。
【０１６８】
トラックの削除が行われた場合、使用中であるＤＰＬ＿ＴＫ＿ＳＲＰが先頭に繰り上げられるが、それに対応するＴＫＩは、もとの配置を保ったまま、未使用に設定されることがわかる。このように、ＴＫＩの配置を編集前後において、不動とするので、編集処理に伴う処理負荷を軽減することができる。
［１７−９＿４０−４＿４５Ａ，Ｂ］　　トラックを記録する場合のＴＫＩの割り当て
続いて一部のトラックが削除された後、新たなトラックを記録する場合（ｃａｓｅ２）について説明する。図４５（ａ）、（ｂ）は、『Ｕｎｕｓｅｄ』のＴＫＩと、ＤＰＬ＿ＴＫ＿ＳＲＰとが存在しており、ここに新たなＴＫＩ、ＤＰＬ＿ＴＫ＿ＳＲＰを書き込む場合、その書き込みがどのように行われるかを示す図である。図４５（ａ）、（ｂ）において、『Ｕｎｕｓｅｄ』のＴＫＩに新たなＴＫＩを割り当てるケースを説明した際、引用した図２８（ａ）〜（ｂ）と同一部分を有する。即ち、図４５（ａ）、（ｂ）における第２、第３、第４段目は、図２８（ａ）、（ｂ）の第１、第２、第３段目と同一である。異なるのは、図４５の第１段目に複数のＤＰＬ＿ＴＫ＿ＳＲＰからなるＤｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報が記述されている点である。図４５（ａ）において、ＤＰＬ＿ＴＫ＿ＳＲＰ＃４〜ＤＰＬ＿ＴＫ＿ＳＲＰ＃８が『Ｕｎｕｓｅｄ』であり、一方、図２８（ａ）に示したようにＴＫＩ＃２、ＴＫＩ＃４、ＴＫＩ＃５、ＴＫＩ＃７、ＴＫＩ＃８が『Ｕｎｕｓｅｄ』であることがわかる。ＴｒａｃｋＭａｎａｇｅｒにおいて『Ｕｎｕｓｅｄ』のＴＫＩが虫食い状に存在しているのに対して、Ｄｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報において『Ｕｎｕｓｅｄ』のＤＰＬ＿ＴＫ＿ＳＲＰがまとめられているのは、上述したように、ＤＰＬ＿ＴＫ＿ＳＲＰは、『Ｕｎｕｓｅｄ』以外のＤＰＬ＿ＴＫ＿ＳＲＰの繰り上げが行われるのに対して、ＴＫＩは、そのような繰り上げが行われないからである。
【０１６９】
ここで４つのＡＯＢからなるＴｒａｃｋＤを書き込もうとする場合を想定する。その４つのＡＯＢのそれぞれについてのＴＫＩは、ＴｒａｃｋＭａｎａｇｅｒにおいて、『Ｕｎｕｓｅｄ』に設定されているＴＫＩ＃２、ＴＫＩ＃４、ＴＫＩ＃７、ＴＫＩ＃８のそれぞれに書き込まれる。
一方、これら４つのＡＯＢについてのＤＰＬ＿ＴＫ＿ＳＲＰは、Ｄｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報におけるＤＰＬ＿ＴＫ＿ＳＲＰ＃４〜ＤＰＬ＿ＴＫ＿ＳＲＰ＃７に書き込まれる。これら４つのＡＯＢは１つのトラックを構成するものなので、ＤＰＬ＿ＴＫ＿ＳＲＰ＃４についてのＤＰＬ＿ＴＫ＿ＡＴＲは『Ｈｅａｄ＿ｏｆ＿Ｔｒａｃｋ』と、ＤＰＬ＿ＴＫ＿ＳＲＰ＃５、ＤＰＬ＿ＴＫ＿ＳＲＰ＃６についてのＤＰＬ＿ＴＫ＿ＡＴＲは『Ｍｉｄｐｏｉｎｔ＿ｏｆ＿Ｔｒａｃｋ』と、ＤＰＬ＿ＴＫ＿ＳＲＰ＃７についてのＤＰＬ＿ＴＫ＿ＡＴＲは『Ｅｎｄ＿ｏｆ＿Ｔｒａｃｋ』と設定されている。
【０１７０】
また、ＤＰＬ＿ＴＫ＿ＳＲＰ＃４についてのＤＰＬ＿ＴＫＩＮはＴＫＩ＃２と設定され、ＤＰＬ＿ＴＫ＿ＳＲＰ＃５についてのＤＰＬ＿ＴＫＩＮはＴＫＩ＃４、ＤＰＬ＿ＴＫ＿ＳＲＰ＃６についてのＤＰＬ＿ＴＫＩＮはＴＫＩ＃７、ＤＰＬ＿ＴＫ＿ＳＲＰ＃７についてのＤＰＬ＿ＴＫＩＮはＴＫＩ＃８と設定されている。
以上のようなＤＰＬ＿ＴＫＩＮ、ＤＰＬ＿ＴＫ＿ＡＴＲの設定により、ＴＫＩ＃２，ＴＫＩ＃４，ＴＫＩ＃７，ＴＫＩ＃８は、４つ目のトラックＴｒａｃｋＤとして管理されることなる。
【０１７１】
以上の処理において、『Ｕｎｕｓｅｄ』のＴＫＩに対する書き込みが行われたが、ＴＫＩ＃１、ＴＫＩ＃２、ＴＫＩ＃３、ＴＫＩ＃４に関しては、何の変動もなされていない点は図２８の場合と同様である。
［１７−９＿４０−５＿４６Ａ，Ｂ］　　トラックの統合（ｃａｓｅ３）を行う場合について
続いてトラックの統合（ｃａｓｅ３）を行う際の、Ｄｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報の更新について説明する。図４６（ａ）、（ｂ）は、トラックの統合を行う場合を想定した図である。本図は、ＴＫＩの統合処理を説明した際に引用した図２９（ａ）、（ｂ）と同一部分を有する。即ち、図４６（ａ）、（ｂ）における第２、第３、第４段目は、図２９（ａ）、（ｂ）における第１段目、第２段目と同一である。差違点は、図４６（ａ）、（ｂ）では、Ｄｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報が記載されており、それに含まれるＤＰＬ＿ＴＫ＿ＳＲＰ＃８が『Ｕｎｕｓｅｄ』に設定されていて、同じく『Ｕｎｕｓｅｄ』に設定されているＴＫＩ＃２と対応関係を有している点である。本図において、図２９に示したようなトラックの統合処理が、ＡＯＢファイル及びＴＫＩに対してなされると、ＤＰＬ＿ＴＫ＿ＳＲＰ＃３〜ＤＰＬ＿ＴＫ＿ＳＲＰ＃６の内容を１つずつずらして、太枠で囲ったＤＰＬ＿ＴＫ＿ＳＲＰ＃７の記述内容をＤＰＬ＿ＴＫ＿ＳＲＰ＃３にコピーする。ＴＫＩについては、図２９に示した場合と同様の更新処理がなされる。
【０１７２】
［１７−９＿４０−６＿４７Ａ，Ｂ］　　トラックの分割（ｃａｓｅ４）を行う場合について
続いてトラックの分割（ｃａｓｅ４）を行う際の、Ｄｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報の更新について説明する。
図４７（ａ）、（ｂ）は、トラックの分割を行う場合を想定した図である。本図は、ＴＫＩについての分割処理を説明した際に引用した図３３（ａ）、（ｂ）と同一部分を有する。即ち、本図における第２段目、第３段目は、図３３（ａ）、（ｂ）における第１段目、第２段目と同一である。差違点は、図４７（ａ）、（ｂ）では、Ｄｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報が記載されており、それに含まれるＤＰＬ＿ＴＫ＿ＳＲＰ＃８が『Ｕｎｕｓｅｄ』に設定されていて、同じく『Ｕｎｕｓｅｄ』に設定されているＴＫＩ＃２と対応関係を有している点である。この状態において、図３３の場合と同様に、太枠で囲ったＴＫＩ＃３、ＡＯＢ００３．ＳＡ１を２つに分割しようとすると、ＤＰＬ＿ＴＫ＿ＳＲＰ＃３〜ＤＰＬ＿ＴＫ＿ＳＲＰ＃７の順序を一つずつ繰り下げて、Ｄｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報における『Ｕｎｕｓｅｄ』のＤＰＬ＿ＴＫ＿ＳＲＰをＤＰＬ＿ＴＫ＿ＳＲＰ＃３まで移動する。移動後のＤＰＬ＿ＴＫ＿ＳＲＰ＃３には、分割により得られたＴＫＩ＃２が対応づけられる。ＴＫＩ＃２に対応づけられているＡＯＢ００２．ＳＡ１は、元々ＡＯＢ００３．ＳＡ１の後半部を格納したものであるが、ＴＫＩ＃２に対応づけられているＤＰＬ＿ＴＫ＿ＳＲＰ＃３の前に、ＤＰＬ＿ＴＫ＿ＳＲＰ＃２が存在し、このＤＰＬ＿ＴＫ＿ＳＲＰ＃２は、ＴＫＩ＃２−ＡＯＢ００２．ＳＡ１が対応づけられている。即ち、ＡＯＢ００２．ＳＡ１及びＡＯＢ００３．ＳＡ１は、元のＡＯＢ００３．ＳＡ１の後半部分、前半部分を格納しているが、これらを指定しているＤＰＬ＿ＴＫ＿ＳＲＰ＃２、ＤＰＬ＿ＴＫ＿ＳＲＰ＃３は、ＡＯＢ００３．ＳＡ１、ＡＯＢ００２．ＳＡ１の順序で、これらのＡＯＢファイルを再生するよう再生順序を指定しているので、元のＡＯＢ００３．ＳＡ１の後半部分、前半部分は、ＤＰＬ＿ＴＫ＿ＳＲＰの再生順序指定により、前半部分、後半部分の順に、再生されることなる。
【０１７３】
［１７−９＿４０−８］　　　　編集処理の応用
以上の４つの編集操作を組み合わせることにより、操作者は、様々な編集操作を行うことができる。即ち、あるトラックの先頭部分にディスクジョッキーのアナウンスが入っており、これを削除したい場合、上記のトラックの分割処理にて、そのアナウンス部分を一個のトラックとして分割し、その後、そのトラックを削除すれば、ディスクジョッキーのアナウンスのみを部分的に削除することができる。
【０１７４】
以上でナビゲーションデータについての説明を終え、続いて、このようなナビゲーションデータ、プレゼンテーションデータを再生するために構成された再生装置について説明する。
［４８−１］　再生装置の外観
図４８は、本実施形態に係るフラッシュメモリカード３１についての携帯型の再生装置を示す図である。本図において再生装置は、フラッシュメモリカード３１が挿入される挿入口、再生、順方向サーチ再生、逆方向サーチ再生、早送り、巻き戻し、停止等のキー操作を操作者から受け付けるためのキーパネルと、液晶ディスプレィとを有しており、通常の携帯型音響機器同様の外観を有する。キーパネルには、プレイリスト／トラックの選択を受け付けるＰｌａｙｌｉｓｔキー、トラックの先頭へのスキップを受け付ける『｜＜＜キー』、次トラックの先頭へのスキップを受け付ける『＞＞｜キー』、早送り、巻き戻し、順方向サーチ再生、逆方向サーチ再生を受け付ける『＞＞キー』，『＜＜キー』、フラッシュメモリカード３１に静止画が格納されている場合に、静止画を表示させる操作を受け付けるＤｉｓｐｌａｙキー、録音操作を操作者から受け付けるＲｅｃキー、Ｓｔｅｒｅｏ／Ｍｏｎｏｒａｌ選択、サンプリング周波数選択を操作者から受け付けるＡｕｄｉｏキー、ブックマークの指定を受け付けるＭａｒｋキー、トラックの編集、タイトル入力を受け付けるＥｄｉｔキーが備えられている。
【０１７５】
［４８−２］　フラッシュメモリカード３１の携帯型再生装置における改良点
このフラッシュメモリカード３１の携帯型再生装置が通常の携帯型音響機器と異なるのは、以下の改良点（１）〜（４）である。即ち、操作者からＤｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報、ＰｌａｙＬｉｓｔ情報、トラックの指定を受け付けるために、液晶ディスプレィには、プレイリスト、トラックの一覧表示がなされること（１）、また、そのように一覧表示されたプレイリスト又はトラックのうち、任意のものを再生対象又は編集対象として指定させるためのキー割り当てがなされていること（２）、トラックの再生進行と共に、液晶ディスプレィには、トラックの再生経過時刻が表示されること（３）、タイムサーチ機能や分割編集を行う際に、再生開始時間を設定するために用いられるジョグダイアルが設けられていること（４）である。
【０１７６】
［４８−２＿４９＿５０］　改良点（２）の詳細
改良点（２）の詳細は以下の通りである。図４９は、プレイリストの選択が行われる際の液晶ディスプレィの表示内容の一例を示す図であり、図５０は、トラックの選択が行われる際の液晶ディスプレィの表示内容の一例を示す図である。
図４９における『ＤＥＦＡＵＬＴＰＬＡＹＬＩＳＴ』『ＰＬＡＹＬＩＳＴ＃１』『ＰＬＡＹＬＩＳＴ＃２』『ＰＬＡＹＬＩＳＴ＃３』『ＰＬＡＹＬＩＳＴ＃４』は、フラッシュメモリカード３１に格納されているデフォルトプレイリストと、４つのプレイリストを示すＡＳＣＩＩ文字列である。また、図５０（ａ）における『ＴＲＡＣＫ＃１』『ＴＲＡＣＫ＃２』『ＴＲＡＣＫ＃３』『ＴＲＡＣＫ＃４』『ＴＲＡＣＫ＃５』は、フラッシュメモリカード３１に格納されているデフォルトプレイリストにて、再生順序が指定される５つのトラックを示すＡＳＣＩＩ文字列である。図４９及び図５０（ａ）にて、ハッチングを付したこれらのプレイリスト及びトラックは、再生対象又は編集対象として指定されていることを示す。このように液晶ディスプレィにプレイリストにて再生順序が規定されるトラックが一覧表示され、ＴＲＡＣＫ＃１が再生対象に指定された状態で＞＞｜キーの押下がなされると、図５０（ｂ）に示すように一覧表示された複数トラックのうち、その下のＴＲＡＣＫ＃２が再生対象に指定される。ＴＲＡＣＫ＃２が、再生対象に指定された状態で＞＞｜キーの押下がなされると、図５０（ｃ）に示すように一覧表示された複数トラックのうち、更に下段のＴＲＡＣＫ＃３が再生対象に指定される。ＴＲＡＣＫ＃３が再生対象に指定された状態で｜＜＜キーの押下がなされると、一覧表示された複数トラックのうち、図５０（ｄ）に示すように一段上のＴＲＡＣＫ＃２が再生対象に指定される。このように＞＞｜キー、｜＜＜キーの押下に応じて、何れかのトラックが再生対象として選択されるので、何れかのトラックが再生対象として選択された際に、図５０（ｅ）に示すように再生キーが押下されれば、そのトラックの再生が開始され、Ｅｄｉｔキーが押下されれば、そのトラックが編集対象として指定される。
【０１７７】
［４８−３＿５１］　　改良点（４）の詳細
続いて改良点（４）の詳細について説明する。図５１は、ジョグダイアルの操作例を示す図である。ジョグダイアルにより、操作者による回転操作を受け付けて、その回転量に応じて、液晶ディスプレィに表示されている再生経過時刻を増減させる。例えば図５１（ａ）に示すように、液晶ディスプレィに再生開始時刻が『００：００：２０』と表示されているものとする。この場合、図５１（ｂ）に示すように、ジョグダイアルが反時計回りに回転されたとすると、再生開始時刻は、その回転量に応じて減少して『００：００：１０』となる。また図５１（ｃ）に示すように、ジョグダイアルが時計回りに回転されたとすると、再生開始時刻は、その回転量に応じて増加して『００：００：３０』となる。
【０１７８】
このように再生時間時間を増減させるのは、トラックにおける任意の再生時刻を指定するためであり、ジョグダイアルの回転により、任意の再生時刻が指定され、再生キーが押下されれば、上記｛数式２｝｛数式３｝に従って指定された位置からＡＯＢを再生する。
また、分割編集においてジョグダイアルは、任意の再生開始時間を分割境界として特定する際、分割境界を微調整するために用いられる。
【０１７９】
［５２−１］　再生装置の内部構成について
続いて再生装置の内部構成について説明する。図５２は、再生装置の内部構成を示す図である。本図において再生装置は、フラッシュメモリカード３１を接続するためのカードコネクタ１と、キーパネル、ジョグダイアルと接続されるユーザインターフェイス部２と、ＲＡＭ３と、ＲＯＭ４と、プレイリスト、トラックを一覧表示する一覧表示枠、再生経過時刻が表示される再生経過時刻枠を有する液晶ディスプレィ５と、液晶ディスプレィを駆動するためのＬＣＤドライバ６と、ＡＯＢファイル毎に異なるＦｉｌｅＫｅｙを用いて、ＡＯＢ＿ＦＲＡＭＥの暗号化を解除するデ・スクランブラ７と、デ・スクランブラ７によりＡＯＢ＿ＦＲＡＭＥのデスクランブルが行われれば、当該ＡＯＢ＿ＦＲＡＭＥのＡＤＴＳヘッダを参照して、当該ＡＯＢ＿ＦＲＡＭＥを復号することにより、ＰＣＭデータを得るＡＡＣデコーダ８と、ＡＡＣデコーダ８の復号により得られたＰＣＭデータをＤ／Ａ変換して、ヘッドホン端子を介してスピーカーに出力するＤ／Ａコンバータ９と、再生装置内の統合処理を行うＣＰＵ１０とを備える。このハードウェア構成からも判るように、本再生装置には、ＴｒａｃｋＭａｎａｇｅｒ、Ｄｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報を処理するための新規の構成は見られない。ＴｒａｃｋＭａｎａｇｅｒ、Ｄｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報の処理のために設けられているのは、ＲＡＭ３内に確保されているＤＰＬＩ常駐領域１１、ＰＬＩ格納領域１２、ＴＫＩ格納領域１３、ＦｉｌｅＫｅｙ格納領域１４、ダブルバッファ１５と、ＲＯＭ４に格納されている再生制御プログラム及び編集制御プログラムである。
【０１８０】
［５２−２］　ＤＰＬＩ常駐領域１１
ＤＰＬＩ常駐領域１１は、カードコネクタ１に接続されフラッシュメモリカード３１から読み出されたＤｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報を常駐させるために確保されている領域である。
［５２＿１２］　　ＰＬＩ格納領域１２
ＰＬＩ格納領域１２は、操作者により選択され、再生対象になっているＰｌａｙＬｉｓｔ情報を格納しておくために確保されている領域である。
【０１８１】
［５２−３］　ＴＫＩ格納領域１３
ＴＫＩ格納領域１３は、ＴｒａｃｋＭａｎａｇｅｒに含まれる複数のＴＫＩのうち、再生対象になっているＡＯＢファイルに対応するＴＫＩのみを格納しておくために確保されている領域であり、ＴＫＩ１個分のデータサイズを有する。
［５２−４］　ＦｉｌｅＫｅｙ格納領域１４
ＦｉｌｅＫｅｙ格納領域１４は、プロテクト領域内のＡＯＢＳＡ１．ＫＥＹに含まれる複数のＦｉｌｅＫｅｙのうち、再生対象になっているＡＯＢファイルに対応するＦｉｌｅＫｅｙのみを格納しておくために確保されている領域である。
【０１８２】
［５２−５］　ダブルバッファ１５
ダブルバッファ１５は、フラッシュメモリカード３１から読み出されたクラスタデータ（クラスタ一個当たりに格納されるデータ）を順次入力して格納するという入力処理と、格納されたクラスタデータから暗号化ＡＯＢ＿ＦＲＡＭＥを読み出して、順次デ・スクランブラ７に出力するという出力処理とを並列に行う場合に用いられる入出力バッファである。ダブルバッファ１５は、ＡＯＢ＿ＦＲＡＭＥとしての出力が済んだクラスタが占有していた領域を順次空き領域に解放し、この空き領域を、新たに読み出されたクラスタの格納に用いるという領域確保、即ち、リングポインタを用いた巡回式の領域確保を行う。
【０１８３】
［５２−５＿５３＿５４Ａ，Ｂ］　　　ダブルバッファ１５における入出力
図５３は、ダブルバッファ１５におけるデータ入出力がどのように行われるかを示す図である。図５４（ａ）、（ｂ）は、リングポインタを用いた巡回式の領域確保がどのように行われるかを示す図である。
これらの図において左下向きの矢印は、クラスタデータの書込先アドレスについてポインタ、即ち、書込先ポインタを示す。左上向きの矢印は、クラスタデータの読出先アドレスについてのポインタ、即ち、読出先ポインタを示す。これらのポインタは、リングポインタとして用いられる。
【０１８４】
［５４−６＿５３］　　フラッシュメモリカード３１がカードコネクタ１に接続されると、このフラッシュメモリカード３１のユーザデータ領域におけるクラスタデータは、矢印ｗ１，ｗ２に示すようにフラッシュメモリカード３１から読み出される。読み出されたクラスタデータは、ダブルバッファ１５において、書込先ポインタＷＰ１，ＷＰ２に示される位置に順次格納されてゆく。
【０１８５】
［５２−７＿５４Ａ］　このように格納されたクラスタデータに含まれるＡＯＢ＿ＦＲＡＭＥのうち、読出先ポインタ▲１▼▲２▼▲３▼▲４▼▲５▼▲６▼▲７▼▲８▼▲９▼に指示される位置に存在するＡＯＢ＿ＦＲＡＭＥは、矢印ｒ１，ｒ２，ｒ３，ｒ４，ｒ５・・・・・・に示すように順次デ・スクランブラ７へと出力されてゆく。ここでダブルバッファ１５にクラスタデータ００２，００３が格納されており、読出先ポインタにてに示さる読出先が図５３の▲１▼▲２▼▲３▼▲４▼に示すように移動して、▲５▼に達した場合、クラスタ００２に含まれるＡＯＢ＿ＦＲＡＭＥは全て読み出されたことになるので、新たにクラスタ００４を読み出して、図５４（ａ）の矢印ｗ６に示すように、クラスタ００２が占有していた領域に上書きする。
【０１８６】
［５２−８＿５４Ｂ］　また読出先ポインタにてに示さる読出先が▲６▼▲７▼に示すように移動して、▲９▼に達すれば、クラスタ００３に含まれるＡＯＢ＿ＦＲＡＭＥは全て読み出されたことになるので、新たにクラスタ００５を読み出して、図５４（ｂ）の矢印ｗ７に示すように、クラスタ００３が占有していた領域に上書きする。以上のような、ＡＯＢ＿ＦＲＡＭＥの出力と、クラスタデータの上書きとが何度も繰り返されて、ＡＯＢファイルに含まれるＡＯＢ＿ＦＲＡＭＥが順次デ・スクランブラ７、ＡＡＣデコーダ８に出力されてゆく。
【０１８７】
［５２−９＿５５〜５８］　　ＲＯＭ４に格納されている再生制御プログラム
続いてＲＯＭ４に格納されている再生制御プログラムについて説明する。
図５５は、ＡＯＢファイル読み出し処理の処理手順を示すフローチャートであり、図５６、図５７、図５８は、ＡＯＢ＿ＦＲＡＭＥ出力処理の処理手順を示すフローチャートである。
【０１８８】
［５２−９＿５５−１］　　これらのフローチャートにおいて、変数ｗとは、複数ＤＰＬ＿ＴＫ＿ＳＲＰのそれぞれを指示する変数であり、変数ｚとは、それぞれのＡＯＢファイルと、それに対応するＴＫＩと、それに含まれるＡＯＢとを一意に指示するための変数である。変数ｙとは、変数ｚにて指示されるＡＯＢ＿ｚに含まれる個々のＡＯＢ＿ＥＬＥＭＥＮＴを指示するための変数であり、変数ｘとは、変数ｙにて指示されるＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙに含まれるそれぞれのＡＯＢ＿ＦＲＡＭＥを指示する変数である。先ず図５５を参照しながらＡＯＢファイル読出処理の処理手順について説明する。
【０１８９】
［５２−９＿５５−２］　　ステップＳ１においてＣＰＵ１０はＰｌａｙＬｉｓｔＭａｎａｇｅｒを読み出して、Ｄｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報及びＰｌａｙＬｉｓｔ情報を一覧表示する。ステップＳ２においてＣＰＵ１０は、Ｄｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報、ＰｌａｙＬｉｓｔ情報の何れに従ってＡＯＢを再生させるかの指定を待つ。ここで、Ｄｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報が指定された場合、ステップＳ２からステップＳ３に移行して、変数ｗを初期化し（＃ｗ←１）、ステップＳ４では、Ｄｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報におけるＤＰＬ＿ＴＫ＿ＳＲＰ＃ｗに対応づけられたＤＰＬ＿ＴＫＩＮにより指定されているＴＫＩ＃ｚを特定して、そのＴＫＩ＃ｚのみをＴＫＩ格納領域１３に読み出す。そして、ステップＳ５においてＴＫＩ＃ｚと同じ番号を有するＡＯＢファイル＃ｚを特定する。ここまでの手順で、ようやく、再生すべきＡＯＢファイルが特定されたことになる。特定されたＡＯＢファイルは、暗号化されているので、このＡＯＢファイルの暗号化を解除すべく、以降ステップＳ６、ステップＳ７の処理を行う。即ち、ステップＳ６では、プロテクト領域をアクセスして、暗号鍵格納ファイルにおいて当該ＡＯＢファイル＃ｚと同じ番号を有するＦｉｌｅ　Ｋｅｙ　Ｅｎｔｒｙ＃ｚに格納されているＦｉｌｅＫｅｙ＃ｚを読み出す。ステップＳ７においてＣＰＵ１０は、ＦｉｌｅＫｅｙ＃ｚをデ・スクランブラ７に設定する。かかる設定により、ＦｉｌｅＫｅｙはデ・スクランブラ７に設定されたので、以降、ＡＯＢファイルに含まれるＡＯＢ＿ＦＲＡＭＥが順次デ・スクランブラ７に投入されれば、ＡＯＢ＿ＦＲＡＭＥは順次再生されることになる。
【０１９０】
［５２−９＿５５−３］　　以降、ＡＯＢファイルを格納している各クラスタを順次読み出してゆく。ステップＳ８では、ディレクトリエントリーにおけるそのＡＯＢファイル＃ｚについての『ファイル最初のクラスタ番号』を特定し、ステップＳ９においてＣＰＵ１０は、そのクラスタに格納されているデータをフラッシュメモリカード３１から読み出す。ステップＳ１０では、ＦＡＴ値にクラスタ番号がＦＦＦと記述されているか否かを判定し、もしＦＡＴ値がＦＦＦ以外の値なら、ステップＳ１１においてそのＦＡＴ値にて指示されているクラスタに格納されているデータを読み出す。かかる読み出し後、ステップＳ１０に移行する。ここで、何れかのクラスタに格納されているデータを読み出し、そのクラスタに対応づけられているＦＡＴ値を参照した際、そのＦＡＴ値にＦＦＦ以外の何れかのクラスタ番号が記述されている限り、ステップＳ１０−ステップＳ１１の処理は繰り返し行われる。これにより、そのＦＡＴ値により指示されているクラスタが順次読み出されてゆく。そのＦＡＴ値にクラスタ番号がＦＦＦと記述されている場合、ＡＯＢファイル＃ｚを構成するクラスタは全て読み出されたことになるので、ステップＳ１０からステップＳ１２に移行する。
【０１９１】
［５２−９＿５５−４］　　ステップＳ１２においてＣＰＵ１０は、変数＃ｗがＤＰＬ＿ＴＫ＿ＳＲＰの総数と一致したか否かを判定する。一致しないなら、ステップＳ１３に移行して、変数＃ｗをインクリメントした後（＃ｗ←＃ｗ＋１）、ステップＳ４に移行する。ステップＳ４においてＤｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報におけるＤＰＬ＿ＴＫ＿ＳＲＰ＃ｗのＤＰＬ＿ＴＫＩＮ＃ｗにより指定されているＴＫＩ＃ｚを特定して、そのＴＫＩ＃ｚのみをＴＫＩ格納領域１３に読み出す。この際、ＴＫＩ格納領域１３にはそれまで使用されていたＴＫＩが格納されているが、ＣＰＵ１０は、ＴＫＩ格納領域１３に既に格納されているＴＫＩを新たに読み出したＴＫＩを用いて上書きする。このような上書きによりＴＫＩ格納領域１３には、最新のＴＫＩのみが格納されることになる。このようにＴＫＩが上書きされれば、ステップＳ５〜ステップＳ１２の処理をＡＯＢファイル＃ｚについて繰り返す。ステップＳ５〜ステップＳ１２の処理が繰り返され、Ｄｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報に含まれる全てのＤＰＬ＿ＴＫ＿ＳＲＰに対応するＴＫＩ、ＡＯＢファイルが読み出されれば、変数＃ｗとＤＰＬ＿ＴＫ＿ＳＲＰの総数とが一致して、ステップＳ１２がＹｅｓとなり、本フローチャートを終了する。
【０１９２】
［５２−９＿５６＿５７＿５８］　　ＡＯＢ＿ＦＲＡＭＥ出力処理
かかるＡＯＢファイル読出処理と並行して、ＣＰＵ１０は、図５６、図５７、図５８のフローチャートに従い、ＡＯＢ＿ＦＲＡＭＥ出力処理を行う。本フローチャートにおいてｐｌａｙ＿ｔｉｍｅとは、これまで再生が経過した時間、即ち、再生経過時刻を示す変数であり、液晶ディスプレィ５の時刻表示枠内の時刻は、このｐｌａｙ＿ｔｉｍｅの更新に応じて、表示内容が書き換えられる。また、ｐｌａｙ＿ｄａｔａとは、これまで再生されたデータ長である。
【０１９３】
［５２−９＿５６−１］　　ステップＳ２１において、ＣＰＵ１０は、ＡＯＢファイル＃ｚについてのクラスタデータがダブルバッファ１５に蓄積されたかを監視している。クラスタデータが蓄積されない限り、このステップＳ２１を繰り返し行うが、クラスタデータが蓄積されれば、ステップＳ２２において、＃ｘ、＃ｙの初期化を行い（＃ｘ←１，＃ｙ←１）、その後、ステップＳ２３において、ＡＯＢファイル＃ｚについてのクラスタにおいて、ＴＫＩ＃ｚに含まれるＢＩＴ＃ｚのＤａｔａ＿Ｏｆｆｓｅｔ以降からＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙにおけるＡＯＢ＿ＦＲＡＭＥ＃ｘを検出する。ここでＳＺ＿ＤＡＴＡから７バイトは、ＡＤＴＳヘッダが占有しているものとして、当該ＡＤＴＳヘッダを参照し、ＡＤＴＳヘッダに示されているデータ長が本体部のオーディオデータであると解析して、当該ＡＤＴＳヘッダと、本体部のオーディオデータとを読み出し、デ・スクランブラ７に出力する。デ・スクランブラ７によりＡＯＢ＿ＦＲＡＭＥの暗号化が解除され、ＡＡＣデコーダ８により復号が行われれば、音声として再生されることになる。
【０１９４】
［５２−９＿５６−２］　　検出後、ステップＳ２４において、ＡＯＢ＿ＦＲＡＭＥ＃ｘをデ・スクランブラ７に出力し、ステップＳ２５において、再生経過時刻ｐｌａｙ＿ｔｉｍｅをＡＯＢ＿ＦＲＡＭＥ＃ｘに相当する再生時間だけインクリメントし、再生済みデータ数ｐｌａｙ＿ｄａｔａをＡＯＢ＿ＦＲＡＭＥ＃ｘに相当するデータ数だけインクリメントする。ここでＡＯＢ＿ＦＲＡＭＥの再生時間長は、２０ｍｓｅｃであるので、再生経過時刻ｐｌａｙ＿ｔｉｍｅには、２０ｍｓｅｃが加算されることになる。
【０１９５】
１番目のＡＯＢ＿ＦＲＡＭＥがデ・スクランブラ７に出力されれば、ステップＳ２６においてＡＯＢ＿ＦＲＡＭＥ＃ｘのＡＤＴＳヘッダを参照して、次のＡＯＢ＿ＦＲＡＭＥが何処に存在するかを特定する。ステップＳ２７では、変数＃ｘのインクリメントを行い（＃ｘ←＃ｘ＋１）、次のＡＯＢ＿ＦＲＡＭＥをＡＯＢ＿ＦＲＡＭＥ＃ｘとする。ステップＳ２８においてＡＯＢ＿ＦＲＡＭＥ＃ｘをデ・スクランブラ７に投入する。その後、ステップＳ２９では、ｐｌａｙ＿ｔｉｍｅを、ＡＯＢ＿ＦＲＡＭＥ＃ｘに相当する再生時間だけインクリメントすると供に、ｐｌａｙ＿ｄａｔａをＡＯＢ＿ＦＲＡＭＥ＃ｘに相当するデータ数だけインクリメントする。ＡＯＢ＿ＦＲＡＭＥ＃ｘをインクリメントした後、ステップＳ３０においてＣＰＵ１０は、＃ｘが『ＦＮｓ＿１ｓｔ＿ＴＭＳＲＴＥ』に達したかを判定する。＃ｘが『ＦＮｓ＿１ｓｔ＿ＴＭＳＲＴＥ』に達しないのなら、ステップＳ３１において、Ｐｌａｙキー以外のキーが押下されたかどうかを確認した後、ステップＳ２６に移行する。以降、＃ｘが『ＦＮｓ＿１ｓｔ＿ＴＭＳＲＴＥ』に達するまで、または、Ｐｌａｙキー以外のキーが押下されるまで、ステップＳ２６〜ステップＳ３１の処理は繰り返し行われる。ここでＰｌａｙキー以外のキーが押下された場合、本フローチャートを終了して、押下されたキーに該当する処理を行う。押下されたキーが停止キーなら再生処理を停止し、押下されたキーが一時停止キーなら一時停止を行う。
【０１９６】
［５２−９＿５７−１］　　一方、＃ｘが『ＦＮｓ＿１ｓｔ＿ＴＭＳＲＴＥ』に達したなら、ステップＳ３０がＹｅｓとなり、図５７のステップＳ３２に移行する。ステップＳ２６からステップＳ３０までの処理にて、ＡＯＢ＿ＥＬＥＭＥＮＴに含まれる全てのＡＯＢ＿ＦＲＡＭＥがデ・スクランブラ７に投入されたので、次のＡＯＢ＿ＥＬＥＭＥＮＴに処理対象を移行すべく、ステップＳ３２において＃ｙをインクリメントすると共に、＃ｘを初期化する（＃ｙ←＃ｙ＋１，＃ｘ←１）。
【０１９７】
その後、ステップＳ３３においてＴＫＴＭＳＲＴを参照してＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙについての先頭アドレスを算出する。以降、ステップＳ３４〜ステップＳ４２からなる処理を行う。ステップＳ３４〜ステップＳ４２の処理は、ＡＯＢ＿ＥＬＥＭＥＮＴに含まれるＡＯＢ＿ＦＲＡＭＥを次々と読み出す処理である点で、ステップＳ２４〜ステップＳ３１からなる処理と同一であるといえる。ステップＳ２４〜ステップＳ３１の処理と異なるのは、後者におけるループ処理の終了条件は、＃ｘが『ＦＮｓ＿１ｓｔ＿ＴＭＳＲＴＥ』に達することであるのに対し、前者におけるループ処理の終了条件は、＃ｘが『ＦＮｓ＿Ｍｉｄｄｌｅ＿ＴＭＳＲＴＥ』に達することである。＃ｘが『ＦＮｓ＿Ｍｉｄｄｌｅ＿ＴＭＳＲＴＥ』に達して、ステップＳ３４〜ステップＳ４２からなるループ処理が終了すると、ステップＳ４１がＹｅｓとなってステップＳ４３に移行する。ステップＳ４３においてＣＰＵ１０は＃ｙをインクリメントすると共に、＃ｘを初期化する（＃ｙ←＃ｙ＋１，＃ｘ←１）。その後、ステップＳ４４において、変数ｙが、ＴＫＩ＃ｚのＴＭＳＲＴ＿Ｈｅａｄｅｒにおける（ＴｏｔａｌＴＭＳＲＴ＿ｅｎｔｒｙ＿Ｎｕｍｂｅｒ−１）と等しい値に達したかを判定する。＃ｙが（ＴｏｔａｌＴＭＳＲＴ＿ｅｎｔｒｙ＿Ｎｕｍｂｅｒ−１）より小さい場合、ＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙは未だ、最後のＡＯＢ＿ＥＬＥＭＥＮＴに達してしていないので、ステップＳ４４からステップＳ３２に移行することにより、ステップＳ３２〜ステップＳ４２の処理を継続して行う。＃ｙが（ＴｏｔａｌＴＭＳＲＴ＿ｅｎｔｒｙ＿Ｎｕｍｂｅｒ−１）に達した場合、最後のＡＯＢ＿ＥＬＥＭＥＮＴの１つ前のＡＯＢ＿ＥＬＥＭＥＮＴまで、ＡＯＢ＿ＦＲＡＭＥの読み出し処理は完遂したと考えられるので、ステップＳ４４がＹｅｓとなり、図５８のステップＳ４５に移行する。
【０１９８】
［５２−９＿５７−２］　　ステップＳ４５〜ステップＳ５４の処理は、最後のＡＯＢ＿ＥＬＥＭＥＮＴに含まれる複数のＡＯＢ＿ＦＲＡＭＥをそれぞれ読み出す処理であるという点において、上述したステップＳ３３〜ステップＳ４２の処理と同一といえる。異なるのは、ステップＳ３３〜ステップＳ４２におけるループ処理は、ステップＳ４１において＃ｘが『ＦＮｓ＿Ｍｉｄｄｌｅ＿ＴＭＳＲＴＥ』に達することがループ処理の終了条件であったのに対して、ステップＳ５３では、＃ｘが『ＦＮｓ＿Ｌａｓｔ＿ＴＭＳＲＴＥ』であり、かつ、これまで読み出されたデータサイズを示すＰｌａｙ＿ｄａｔａがＳＺ＿ＤＡＴＡに達することが、ループ処理の終了条件になっている点である。
【０１９９】
このステップＳ５３の条件が満たされるまで、ステップＳ４９〜ステップＳ５４の処理は繰り返し行われ、この条件が満たされれば、ステップＳ５３がＹｅｓとなって、ステップＳ５５に移行する。ステップＳ５５においてＣＰＵ１０は、＃ｚをインクリメントしてからステップＳ２１に移行して（＃ｚ←＃ｚ＋１）、次のＡＯＢファイルがダブルバッファ１５に蓄積されるのを待つ。蓄積されれば、ステップＳ２１からステップＳ２２に移行し、次のＡＯＢファイルについて、ステップＳ２２〜ステップＳ５４の処理を繰り返し行う。即ち、次のＤＰＬ＿ＴＫ＿ＳＲＰのＤＰＬ＿ＴＫＩＮにより指定されているＴＫＩを特定し、そのＴＫＩに対応するＡＯＢファイル、即ち、ＴＫＩと同じ番号を有するＡＯＢファイルを特定する。その後、プロテクト領域をアクセスして、暗号鍵格納ファイルにおいて当該ＴＫＩと同じ番号を有するＦｉｌｅＫｅｙを特定し、当該ＦｉｌｅＫｅｙを読み出して、当該ＦｉｌｅＫｅｙをデ・スクランブラに設定してから、そのＴＫＩと同じ番号を有するＡＯＢファイルに含まれるＡＯＢ＿ＦＲＡＭＥを順次読み出して再生してゆくのである。
【０２００】
［５２−９＿５７−３＿５９］　再生経過時刻の更新
図５９は、液晶ディスプレィ５の時刻表示枠に表示される再生経過時刻が、変数Ｐｌａｙ＿Ｔｉｍｅの更新したがい、増加してゆく様子を示す図である。本図（ａ）では、再生経過時刻は００：００：００．０００であるが、ＡＯＢ＿ＦＲＡＭＥ＃１の再生が終了した時点で、再生経過時刻にＡＯＢ＿ＦＲＡＭＥの時間長２０ｍｓｅｃが加算されて００：００：００．０２０に更新されている。ＡＯＢ＿ＦＲＡＭＥ＃２の再生が終了した時点で、再生経過時刻にＡＯＢ＿ＦＲＡＭＥの時間長２０ｍｓｅｃが加算されて００：００：００．０４０に、ＡＯＢ＿ＦＲＡＭＥ＃６の再生が終了した時点で、再生経過時刻は００：００：００．１２０となっていることがわかる。
【０２０１】
以上がＡＯＢ＿ＦＲＡＭＥ出力処理の全貌である。本フローチャートのステップＳ３１において、Ｐｌａｙキー以外のキーの押下時に、本フローチャートの処理を中断することは既に述べた通りであり、そのようなＰｌａｙキー以外のキーとして一時停止キーや停止キーがあることも説明済みであるが、一時停止キーや停止キー以外にも、特殊再生を再生装置に行わせるためのキーが押下された場合も、図５６、図５７、図５８のフローチャートの処理は中断し、その押下されたキーに応じた処理が実行される。以降、＞＞キーが押下され、順方向サーチ再生を実行する場合のＣＰＵ１０の処理手順と、一時停止キーや停止キーが押下された後に、ジョグダイアルが操作されることにより、タイムサーチ機能が実行される場合のＣＰＵ１０の処理手順とについて説明する。
【０２０２】
［５２−１０＿６０］　順方向サーチ再生
図６０は、順方向サーチ再生を行う場合のＣＰＵ１０の処理手順を示すフローチャートである。＞＞キーが操作者により押下されて図５６、図５７、図５８のステップＳ３１、ステップＳ４２、ステップＳ５４がＹｅｓになった際、ＣＰＵ１０により実行されるのが本フローチャートである。
【０２０３】
ステップＳ６１において、ＣＰＵ１０はＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙのＡＯＢ＿ＦＲＡＭＥ＃ｘからｘ＋ｆ（ｔ）−１までをデ・スクランブラ７に投入する。ここで、『ｔ』とは、間欠再生時間であり、ｆ（ｔ）を、間欠再生時間に相当するフレーム数、ｄ（ｔ）を間欠再生時間に相当するデータ数とすると、ステップＳ６２では、再生経過時刻を示すｐｌａｙ＿ｔｉｍｅ、再生済みデータ数を示すｐｌａｙ＿ｄａｔａを、ｔ：間欠再生時間、ｆ（ｔ）：間欠再生時間に相当するフレーム数、ｄ（ｔ）：間欠再生時間に相当するデータ数に基づいて更新する（ｘ←ｘ＋ｆ（ｔ）、ｐｌａｙ＿ｔｉｍｅ←ｐｌａｙ＿ｔｉｍｅ＋ｔ、ｐｌａｙ＿ｄａｔａ←ｐｌａｙ＿ｄａｔａ＋ｄ（ｔ）　尚、一般に間欠再生時間は２４０ミリ秒（１２個のＡＯＢ＿ＦＲＡＭＥの再生時間長）に相当する。）。
【０２０４】
［５２−１０＿６０−１＿６１Ａ，Ｂ］　図６１（ａ）、（ｂ）は、順方向サーチ再生時において、再生経過時刻がインクリメントされてゆく様子を示す図である。図６１（ａ）は、再生経過時刻の初期状態を示し、再生時点は、ＡＯＢ＿ＥＬＥＭＥＮＴ＃５１のＡＯＢ＿ＦＲＡＭＥ＃１であることを示す。この場合の再生経過時刻は、００：００：０１．０００であることがわかる。ここで、間欠再生時間として、１番目から１２番目までのＡＯＢ＿ＦＲＡＭＥがデ・スクランブラ７に投入されて、再生経過時刻に１ＡＯＢ＿ＦＲＡＭＥの時間長である２４０ミリ秒が加算されると、図６１（ｂ）に示すように、再生経過時刻は、００：００：０１．２４０となる。
【０２０５】
［５２−１０＿６０−２］　これらを更新した後、ステップＳ６３においてＣＰＵ１０は、インクリメント後のＡＯＢ＿ＦＲＡＭＥ＃ｘと、ＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙの総フレーム数との大小比較して、インクリメント後のＡＯＢ＿ＦＲＡＭＥ＃ｘがＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙ内に存在するかを判定する。具体的には、ＡＯＢの先頭に位置するＡＯＢ＿ＥＬＥＭＥＮＴのフレーム数は『ＦＮｓ＿１ｓｔ＿ＴＭＳＲＴＥ』であり、中間のもののフレーム数は『ＦＮｓ＿Ｍｉｄｄｌｅ＿ＴＭＳＲＴＥ』、最後のもののフレーム数は『ＦＮｓ＿Ｌａｓｔ＿ＴＭＳＲＴＥ』に示されるので、これらと、ＡＯＢ＿ＦＲＡＭＥ＃ｘとを比較することにより、判定を行う。もし更新後のＡＯＢ＿ＦＲＡＭＥ＃ｘがＡＯＢ＿ＥＬＥＭＥＮＴ内に存在しないのなら、ステップＳ６４においてＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙに後続するＡＯＢ＿ＥＬＥＭＥＮＴが存在するかを判定する。ここでＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙが最後のＡＯＢ＿ＥＬＥＭＥＮＴであり、後続するＡＯＢ＿ＥＬＥＭＥＮＴが存在しない場合、ステップＳ６４がＮｏとなり、本フローチャートの処理を終了するが、後続するＡＯＢ＿ＥＬＥＭＥＮＴが存在する場合、ステップＳ６５において、ＡＯＢ＿ＦＲＡＭＥ＃ｘからＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙにおけるフレーム数を減じ、ステップＳ６６において＃ｙを更新することにより（ｙ←ｙ＋１）、ＡＯＢ＿ＦＲＡＭＥ＃ｘを後続するＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙにおけるＡＯＢ＿ＦＲＡＭＥのフレーム位置に変換する。もし更新後のＡＯＢ＿ＦＲＡＭＥ＃ｘがＡＯＢ＿ＥＬＥＭＥＮＴ内に存在するのなら、これらステップＳ６５〜ステップＳ６６をスキップして、ステップＳ６７に移行する。
【０２０６】
［５２−１０＿６０−３］　続いて、間欠スキップ間隔に応じて、ＡＯＢ＿ＦＲＡＭＥ＃ｘ、再生経過時刻ｐｌａｙ＿ｔｉｍｅ、再生済みデータ数ｐｌａｙ＿ｄａｔａの更新を行う。ここで、間欠スキップ間隔に相当する時間をｓｋｉｐ＿ｔｉｍｅ（２秒）とし、間欠スキップ間隔ｓｋｉｐ＿ｔｉｍｅに相当するフレーム数をｆ（ｓｋｉｐ＿ｔｉｍｅ）、間欠スキップ間隔ｓｋｉｐ＿ｔｉｍｅに相当するデータ数ｄ（ｓｋｉｐ＿ｔｉｍｅ）とすると、ステップＳ６７において、これらを用いてＡＯＢ＿ＦＲＡＭＥ＃ｘ、再生経過時刻ｐｌａｙ＿ｔｉｍｅ、再生済みデータ数ｐｌａｙ＿ｄａｔａを更新する（ｘ←ｘ＋ｆ（ｓｋｉｐ＿ｔｉｍｅ），ｐｌａｙ＿ｔｉｍｅ←ｐｌａｙ＿ｔｉｍｅ＋ｓｋｉｐ＿ｔｉｍｅ，ｐｌａｙ＿ｄａｔａ←ｐｌａｙ＿ｄａｔａ＋ｄ（ｓｋｉｐ＿ｔｉｍｅ））。
【０２０７】
［５２−１０＿６０−４＿６１Ｃ］　図６１（ｃ）に示すように、ＡＯＢ＿ＥＬＥＭＥＮＴ＃５１内のフレーム位置を示すＡＯＢ＿ＦＲＡＭＥ＃ｘに間欠スキップ間隔を加算したものとする。この加算後の＃ｘがＡＯＢ＿ＥＬＥＭＥＮＴ＃５１のフレーム数を上回れば、ＡＯＢ＿ＥＬＥＭＥＮＴを次のＡＯＢ＿ＥＬＥＭＥＮＴに更新すると共に、加算後の＃ｘから、ＡＯＢ＿ＥＬＥＭＥＮＴ＃５１のフレーム数を減じることにより、ＡＯＢ＿ＦＲＡＭＥ＃ｘを、ＡＯＢ＿ＥＬＥＭＥＮＴ＃５２におけるフレーム位置に変換する。この場合、ＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙがＡＯＢ＿ＥＬＥＭＥＮＴ＃５２となり、再生経過時刻は、００：００：０１．２４０に２．０００を加算することにより、００：００：０３．２４０となる。ＡＯＢ＿ＦＲＡＭＥ＃ｘは、ＡＯＢ＿ＥＬＥＭＥＮＴ＃５２におけるＡＯＢ＿ＦＲＡＭＥ＃６２（＝（３２４０ｍｓｅｃ−２０００ｍｓｅｃ）／２０ｍｓｅｃ）となる。
【０２０８】
［５２−１０＿６０−５＿６１（ｄ）］　その後、ＡＯＢ＿ＥＬＥＭＥＮＴ＃５２におけるＡＯＢ＿ＦＲＡＭＥ＃６２がデ・スクランブラ７に投入されれば、図６１（ｄ）に示すように再生経過時刻は、００：００：０３．２４０に０．２４０を加算することにより、００：００：０３．４８０となる。
ステップＳ６７において間欠的スキップ時間に応じた更新を行えば、ステップＳ６８〜ステップＳ７１の処理を行う。このステップＳ６８〜ステップＳ７１の処理は、ステップＳ６３〜ステップＳ６６の処理と同一であり、間欠スキップ間隔ｓｋｉｐ＿ｔｉｍｅに相当するフレーム数が加算された後のＡＯＢ＿ＦＲＡＭＥがＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙ内に存在するかどうかの判定がなされて、存在するのなら、その次のＡＯＢ＿ＥＬＥＭＥＮＴをＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙとし、ＡＯＢ＿ＦＲＡＭＥ＃ｘを、新たなＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙにおけるフレーム位置に変換する。
【０２０９】
間欠再生時間及び間欠的スキップ時間に応じて、ＡＯＢ＿ＦＲＡＭＥ＃ｘ、ＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙがインクリメントされれば、ステップＳ７２において、ＣＰＵ１０は、ＴＫＴＭＳＲＴを参照してＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙについての先頭アドレスを算出し、ステップＳ７３においてＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙにおける先頭アドレスからＡＤＴＳヘッダの探索を開始することにより、ＡＯＢ＿ＦＲＡＭＥ＃ｘを検出する。そして、ステップＳ７４において、順方向スキップキー以外のキーが押下されたか否かを判定した後、ステップＳ６１においてＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙのＡＯＢ＿ＦＲＡＭＥ＃ｘからｘ＋ｆ（ｔ）−１までをデ・スクランブラ７に投入し、再度ステップＳ６２〜ステップＳ７３の処理を繰り返し行う。
【０２１０】
以上の処理にて、ＡＯＢ＿ＦＲＡＭＥ＃ｘ、ＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙがインクリメントされ、再生位置が進行してゆく。その後、操作者により再生キーが押下されれば、ステップＳ７４がＮｏとなり、本フローチャートの処理を終了する。
［５２−１１］　　タイムサーチ機能の実行
タイムサーチ機能が行われた場合の処理について説明する。Ｄｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報におけるトラックを一覧表示し、任意のトラックの指定を受け付ける。トラックが指定され、ジョグダイアルが操作されると、再生開始時刻を更新する。再生開始時刻が増減した後、再生キーが押下されると、その再生が指定された時刻をＪｍｐ＿Ｅｎｔｒｙ（秒）と特定する。一方、指定されたトラックが複数のＡＯＢからなるか、単一のＡＯＢからなるかを判定する。単一のＡＯＢからなる場合、｛数式２｝を満たすＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙと、ＡＯＢ＿ＦＲＡＭＥ＃ｘとを算出する。｛数式２｝を満たすＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙ、ＡＯＢ＿ＦＲＡＭＥ＃ｘが算出されれば、このＡＯＢに対応するＴＫＴＭＳＲＴにおいて、ｙ＋２番目に位置するアドレスから、ＡＯＢ＿ＦＲＡＭＥ＃ｘの探索を始め、ｘ番目のＡＯＢ＿ＦＲＡＭＥが探索されれば、このｘ番目のＡＯＢ＿ＦＲＡＭＥから再生を開始する。
【０２１１】
［５２−１２］
複数のＡＯＢからなる場合、｛数式３｝を満たすＡＯＢ＿ｎ、ＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙと、ＡＯＢ＿ＦＲＡＭＥ＃ｘとを算出する。｛数式３｝を満たすＡＯＢ＿ｎ、ＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙ、ＡＯＢ＿ＦＲＡＭＥ＃ｘが算出されれば、このＡＯＢ＿ｎに対応するＴＫＴＭＳＲＴにおいて、ｙ＋２番目に位置するアドレスから、ＡＯＢ＿ＦＲＡＭＥ＃ｘの探索を始め、ｘ番目のＡＯＢ＿ＦＲＡＭＥが探索されれば、このｘ番目のＡＯＢ＿ＦＲＡＭＥから再生を開始する。
【０２１２】
続いてＢＩＴにおけるＦＮｓ＿１ｓｔ＿ＴＭＳＲＴＥは８０フレームであり、ＦＮｓ＿Ｌａｓｔ＿ＴＭＳＲＴＥは５０フレーム、ＦＮｓ＿Ｍｉｄｄｌｅ＿ＴＭＳＲＴＥが９４フレームであるＡＯＢにおいて、任意の再生時刻から再生を開始する場合について説明する。
［５２−１３＿６２Ａ，Ｂ］
ここで、タイムサーチ機能が行われる場合の具体例として、ジョグダイアルにより、再生開始時刻が指定された場合に再生を開始すべきＡＯＢ＿ＥＬＥＭＥＮＴ、再生を開始すべきフレーム位置をどのように特定するかについて説明する。図６２は、タイムサーチ機能が行われる場合の具体例を示す図である。ここで図６２（ａ）に示すように、再生装置が把持されて、あるＡＯＢが再生対象として指定された状態で、その右手の親指により、ジョグダイアルの回転操作がなされ、　再生開始時刻＝００：０４：４０．０００（＝２８０．００ｓｅｃ）が指定されたものとする。このＡＯＢについてＴＫＩ内のＢＩＴが、図６２（ｂ）に示す内容である場合、再生開始時刻＝００：０４：４０．０００（＝２８０．００ｓｅｃ）を｛数式２｝に適用すると、
２８０ｓｅｃ　＝（ＦＮｓ＿１ｓｔ＿ＴＭＳＲＴＥ＋ＦＮｓ＿ｍｉｄｄｌｅ＿ＴＭＳＲＴＥ・ｙ＋ｘ）×２０ｍｓｅｃ
＝（　８０　＋　９４・１４８　＋　８）×２０ｍｓｅｃ
となるので、｛数式２｝を満たすＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙ、ＡＯＢ＿ＦＲＡＭＥ＃ｘとして、ｙ＝１４８，ｘ＝８のＡＯＢ＿ＦＲＡＭＥが得られる。
【０２１３】
このようにｙ＝１４８と特定されたので、ｙ＋２番目のＡＯＢ＿ＥＬＥＭＥＮＴ＃１５０（＝１４８＋２）のエントリーアドレスをＴＫＴＭＳＲＴから取得して、ここから８番目のＡＯＢ＿ＦＲＡＭＥから、再生を開始すれば、　再生経過時刻＝００：０４：４０．０００（＝２８０．００ｓｅｃ）から、再生を開始することができる。
［５２−１４＿６３＿６４＿６５］
以上でＰｌａｙキーが押下された場合の、ＣＰＵ１０の処理内容の説明を終える。続いてＲＯＭに格納されている編集制御プログラムについて説明する。本編集制御プログラムは、Ｅｄｉｔキーが押下された場合に実行されるものであり、図６３、図６４、図６５にその処理手順を示す。以降、これらのフローチャートを参照しながら、編集制御プログラムの処理内容について説明する。
【０２１４】
［５２−１４＿６３−１］　編集制御プログラム
Ｅｄｉｔキーが押下されれば、図６３のステップＳ１０１において削除、分割、統合といった典型的な編集操作の何れを行うかを操作者に提示する対話画面を表示し、その後、ステップＳ１０２において、対話画面に対する処理が指定されたかを判定する。ここで対話画面の操作において、＞＞｜キー、｜＜＜キーをそれぞれ上下カーソル操作を受け付けるためのキー、即ち、上下カーソルキーとして用いるものとする。削除処理が指定されると、ステップＳ１０３、ステップＳ１０４からなるループ処理に移行する。ステップＳ１０３では、＞＞｜キー、｜＜＜キーが押下されたか否かを判定し、ステップＳ１０４では、編集キーが押下されたか否かを判定する。＞＞｜、｜＜＜キーが押下されれば、ステップＳ１０３からステップＳ１０５に移行して、指示されたトラックを編集対象として指定する。一方、編集キーが押下されれば、削除すべきトラックが特定されたとして、図４４に示した処理を行い、指定されたトラックについてのＴＫＩのＴＫＩ＿ＢＬＫ＿ＡＴＲを『Ｕｎｕｓｅｄ』に設定することにより、特定されたトラックを削除する。
【０２１５】
［５２−１４＿６３−２］　統合編集処理
統合編集が指定されると、ステップＳ１０２からステップＳ１０７〜ステップＳ１０９からなるループ処理に移行する。ステップＳ１０７〜ステップＳ１０９からなるループ処理では、＞＞｜キー、｜＜＜キーの押下と、編集キーの押下とを受け付ける。＞＞｜｜、｜＜＜キーが押下されれば、ステップＳ１０７からステップＳ１１０に移行して、指示されたトラックに対するハイライト表示を行う。編集キーが押下されれば、ステップＳ１０８がＹｅｓとなり、ステップＳ１１１に移行する。ステップＳ１１１では、カーソルキーにて指示されたトラックを、編集対象として指定し、再度、ステップＳ１０７〜ステップＳ１０９からなるループ処理に移行する。
【０２１６】
２トラック目の編集対象が特定されれば、ステップＳ１０９がＹｅｓとなって、ステップＳ１１２に移行する。ステップＳ１１２では、先行するトラック、後続するトラックについてのＴＫＩのＢＩＴを参照することにより、両トラックの末尾及び先頭に配置されているＡＯＢ（その前後にもＡＯＢが配されている場合は、その前後のＡＯＢ）のタイプがＴｙｐｅ１、Ｔｙｐｅ２の何れであるかを判定する。
【０２１７】
各ＡＯＢのタイプが判明したのなら、ステップＳ１１３においてそれら各タイプのＡＯＢの配置画像に示した何れの配置パターンに該当するかを判定する。図３２（ａ）〜（ｄ）の何れかの配置パターンに該当し、統合後においても、Ｔｙｐｅ２ＡＯＢが３つ連続しないことが明らかならば、ステップＳ１１５において先行するトラック、後続するトラックを１つのトラックに統合する。即ち、これらに対応づけられたＴＫＩ、ＤＰＬ＿ＴＫ＿ＳＲＰに対して、図４６に示した操作を行い、ＴＫＩのＴＫＩ＿ＢＬＫ＿ＡＴＲを書き換えることにより、それら操作対象として選択された複数のトラックを１つのトラックに統合する。図３２（ａ）〜（ｄ）の何れの配置パターンにも該当せず、統合後にＴｙｐｅ２のＡＯＢが３つ連続してしまう場合は、ステップＳ１１４において統合後のトラックにアンダーフローの発生の恐れがある旨を表示し、統合処理を中断する。
【０２１８】
［５２−１４＿６４−１］　トラックの分割処理
トラックの分割が指定されると、ステップＳ１０２からステップＳ１１６〜ステップＳ１１７からなるループ処理に移行する。ステップＳ１１６〜ステップＳ１１７からなるループ処理では、＞＞｜キー、｜＜＜キーの押下と、編集キーの押下とを受け付ける。＞＞｜｜、｜＜＜キーが押下されれば、ステップＳ１１６からステップＳ１１８に移行して、指示されたトラックを編集対象として指定する。編集キーが押下されれば、ステップＳ１１７がＹｅｓとなり、ステップＳ１１９に移行する。ステップＳ１１９では、カーソルキーにて指示されたトラックを、編集対象として指定する。その後、ステップＳ１２０では、分割が指定されたトラックの再生を開始して、ステップＳ１２１においてＭａｒｋキーの押下を受け付ける。Ｍａｒｋキーの押下が行われると、トラックの再生を一時停止し、ステップＳ１２２〜ステップＳ１２３からなるループ処理に移行する。ステップＳ１２２では、ジョグダイアルに対する回転操作を受け付け、ジョグダイアルに対して回転操作がなされると、ステップＳ１２４においてその回転操作に伴い、再生開始時間を増減させる。その後、ステップＳ１２２〜ステップＳ１２３からなるループ処理に再度移行する。回転操作により再生開始時刻が増減された状態で、編集キーが押下されれば、ステップＳ１２３からステップＳ１２５に移行し、ステップＳ１２５において、編集キーが押下された再生時間を分割境界として指定する（尚、分割境界の指定にあたっては、アンドゥ機能（編集の取り消し）が可能である。）。その後、ステップＳ１２６において図４７で説した処理を行い、ＤＰＬＩ、ＴＫＩを更新することにより、トラックの分割を行う。
【０２１９】
［５２−１４＿６５−１］　プレイリストの設定編集処理
プレイリストの設定編集が指定されると、図６５のフローチャートに移行する。本フローチャートにおいて変数ｋとは、これから設定されるプレイリストにより、再生順序が規定される個々のトラックを指示するための変数であり、図６５のフローチャートでは、先ずステップＳ１３１においてこの変数ｋに１を設定した後、ステップＳ１３２〜ステップＳ１３４からなるループ処理に移行する。ステップＳ１３２〜ステップＳ１３４からなるループ処理では、＞＞｜キー、｜＜＜キーの押下と、編集キーの押下と、停止キーの押下とを受け付ける。＞＞｜キー、｜＜＜キーが押下されれば、ステップＳ１３２からステップＳ１３５に移行して、＞＞｜キー、｜＜＜キーにより指示されたトラックを指定する。編集キーが押下されれば、ステップＳ１３３がＹｅｓとなり、ステップＳ１３６に移行する。ステップＳ１３６では、編集キーにて指示されたトラックを、ｋ番目に再生されるべきトラックとして特定する。その後、ステップＳ１３７において、変数ｋをインクリメントして、ステップＳ１３２〜ステップＳ１３４のループ処理に移行する。このような処理を繰り返すことにより、２トラック目、３トラック目、４トラック目のトラックが順次特定される。このようにして、新たに作成されたプレイリストにて再生されるべき複数のトラックが特定された状態で停止キーが押下されると、ステップＳ１３４からステップＳ１３８に移行して、これらに対応づけられたＴＫＩを特定するＰＬ＿ＴＫ＿ＳＲＰからなるＰｌａｙＬｉｓｔ情報を生成する。
【０２２０】
（記録装置）
［６６−１］　記録装置
続いて、フラッシュメモリカード３１の記録装置についての一例を説明する。図６６は、フラッシュメモリカード３１の記録装置の一例を示す図である。本図における記録装置は、インターネットを介した通信が可能であり、電子音楽配信によりＳＤ＿Ａｕｄｉｏディレクトリィが暗号化された状態で通信回線を介して伝送されてくる場合、又は、電子音楽配信によりオーディオデータトランスポートストリームが配信されてくる場合にこれらを受信することができる汎用パーソナルコンピュータである。
【０２２１】
［６７−１］　記録装置のハードウェア構成
図６７は、記録装置のハードウェア構成を示す図である。本図において記録装置は、フラッシュメモリカード３１を接続するためのカードコネクタ２１と、ＲＡＭ２２と、記録装置の統合制御を行うための記録制御プログラムを格納した固定ディスク装置２３と、マイクから入力された音声をＡ／Ｄ変換して、ＰＣＭデータを得るＡ／Ｄコンバータ２４と、単位時間当たりのＰＣＭデータをエンコードして、ＡＤＴＳヘッダを付与することにより、ＡＯＢ＿ＦＲＡＭＥを得るＡＣＣエンコーダ２５と、各ＡＯＢファイル毎のＦｉｌｅＫｅｙを用いて、ＡＯＢ＿ＦＲＡＭＥを暗号化するスクランブル部２６と、電子音楽配信によりＳＤ＿Ａｕｄｉｏディレクトリィが暗号化された状態で通信回線を介して伝送されてくる場合、又は、電子音楽配信によりオーディオデータトランスポートストリームが通信回線を介して伝送されてくる場合に、オーディオデータトランスポートストリームを受信するモデム装置２７と、記録装置内の統合制御を行うＣＰＵ２８と、操作者からの操作を受け付けるキーボード２９と、ディスプレィ３０とを有する。
【０２２２】
［６７−２］　入力経路ＲＴ１〜ＲＴ４
電子音楽配信によりデータ領域及びプロテクト領域に書き込むべきＳＤ＿Ａｕｄｉｏディレクトリィが暗号化された状態で通信回線を介して伝送されてくる場合、記録装置はこれらを正当に受信した時点で、フラッシュメモリカード３１のデータ領域及びプロテクト領域に書き込めばよい。しかし、ＳＤ＿Ａｕｄｉｏディレクトリィでは無く、電子音楽配信によりオーディオデータトランスポートストリームそのものが伝送されてくる場合、またＰＣＭデータの状態で記録装置に入力されてくる場合、原音の状態で記録装置に入力されてくる場合、記録装置は、以下に示す４つの入力経路を経て、フラッシュメモリカード３１にオーディオデータトランスポートストリームを書き込むことなる。
【０２２３】
本図における記録装置がフラッシュメモリカード３１に、オーディオデータトランスポートストリームを格納する際、オーディオデータトランスポートストリームの入力経路には、図６７に示す入力経路ＲＴ１、入力経路ＲＴ２、入力経路ＲＴ３、入力経路ＲＴ４がある。
［６７−３］　入力経路ＲＴ１
入力経路ＲＴ１は、電子音楽配信によりＳＤ＿Ａｕｄｉｏディレクトリィが暗号化された状態で通信回線を介して伝送されてくる場合、又は、オーディオデータトランスポートストリームが通信回線を介して伝送されてくる場合の入力経路であり、この場合、トランスポートストリームに含まれるＡＯＢ＿ＦＲＡＭＥは、一個のＡＯＢに属するもの毎に異なるＦｉｌｅＫｅｙを用いて暗号化されている。暗号化済みのトランスポートストリームに対しては、再度の暗号化、符号化の必要は存在しないので、ＳＤ＿Ａｕｄｉｏディレクトリィ又はオーディオデータトランスポートストリームは、暗号化された状態で、ＲＡＭ２２に格納される。
【０２２４】
［６７−４］　入力経路ＲＴ２
入力経路ＲＴ２は、マイクから音声が入力されてくる場合の入力経路である。この場合、Ａ／Ｄコンバータ２４にマイクから入力された音声をＡ／Ｄ変換を行わせて、ＰＣＭデータを得る。そしてＰＣＭデータのエンコードをＡＡＣエンコーダ２５に行わせて、ＡＤＴＳヘッダを付与することにより、ＡＯＢ＿ＦＲＡＭＥを得る。その後、スクランブル部２６に各ＡＯＢファイル毎のＦｉｌｅＫｅｙを用いて、ＡＯＢ＿ＦＲＡＭＥを暗号化を行わせることにより、暗号化がなされたオーディオデータを得る。その後、オーディオデータをＲＡＭ２２に格納する。
【０２２５】
［６７−５］　入力経路ＲＴ３
入力経路ＲＴ３は、ＣＤから読み出されたＰＣＭデータが装置に入力されてくる場合の入力経路である。ＰＣＭデータの状態で入力されてくるので、当該ＰＣＭデータは、そのままＡＡＣエンコーダ２５に入力される。そのように入力されたＰＣＭデータのエンコードをＡＡＣエンコーダ２５に行わせて、ＡＤＴＳヘッダを付与することにより、ＡＯＢ＿ＦＲＡＭＥを得る。その後、スクランブル部２６に各ＡＯＢ＿ＦＲＡＭＥ毎のＦｉｌｅＫｅｙを用いて、ＡＯＢ＿ＦＲＡＭＥを暗号化を行わせることにより、暗号化がなされたオーディオデータを得る。その後、オーディオデータはＲＡＭ２２に格納される。
【０２２６】
［６７−６］　入力経路ＲＴ４
入力経路ＲＴ４は、３つの入力経路ＲＴ１，ＲＴ２，ＲＴ３において入力されたトランスポートストリームを、フラッシュメモリカード３１に書き込む際の入力経路である。かかるオーディオデータの格納に伴い、ＴＫＩ、Ｄｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報は生成される。再生装置の場合と同様、かかる記録装置の機能主体も、ＲＯＭに記録されている記録プログラムである。即ち、ＡＯＢの記録やＴｒａｃｋＭａｎａｇｅｒ、ＰｌａｙＬｉｓｔＭａｎａｇｅｒの記録といった本実施形態特有の処理は、固定ディスク装置に記録されている記録プログラムにより実現される。
【０２２７】
［６７−７＿６８］　　記録処理の処理手順
以降、フローチャートを参照しながら、上記入力経路ＲＴ１，ＲＴ２，ＲＴ３，ＲＴ４において、トランスポートストリームをフラッシュメモリカード３１に書き込む場合の記録処理の処理手順について説明する。図６８は、記録処理の処理手順を示すフローチャートである。本フローチャートにおいて引用する変数としては、Ｆｒａｍｅ＿Ｎｕｍｂｅｒ、Ｄａｔａ＿Ｓｉｚｅといったものがある。Ｆｒａｍｅ＿Ｎｕｍｂｅｒとは、これまでＡＯＢファイルに記録されたＡＯＢ＿ＦＲＡＭＥの総数を管理するための変数であり、Ｄａｔａ＿Ｓｉｚｅとは、これまでＡＯＢファイルに記録されたＡＯＢ＿ＦＲＡＭＥのデータサイズを管理するための変数である。
【０２２８】
本フローチャートが実行されると、ステップＳ２００においてＣＰＵ２８は、ＤｅｆａｕｌｔＰｌａｙｌｉｓｔ，ＴｒａｃｋＭａｎａｇｅｒを作成し、ステップＳ２０１において、変数＃ｚ，＃ｗを初期化する（ｚ←１，ｗ←１）。ステップＳ２０２では、ＡＯＢファイル＃ｚを作成してフラッシュメモリカード３１におけるデータ領域に格納する。この状態で、データ領域におけるＳＤ＿Ａｕｄｉｏディレクトリのディレクトリエントリーには、ＡＯＢファイル＃ｚのファイル名、ファイル拡張子、最初のクラスタ番号が設定されることになる。続くステップＳ２０３において、ＣＰＵ２８は、ＴＫＩ＃ｚを作成してＴｒａｃｋＭａｎａｇｅｒに格納し、ステップＳ２０４においてＣＰＵ２８は、ＤＰＬ＿ＴＫ＿ＳＲＰ＃ｗを作成してＤｅｆａｕｌｔＰｌａｙｌｉｓｔ情報に格納する。以降ステップＳ２０５において変数＃ｙを初期化し（ｙ←１）、ステップＳ２０６において、Ｆｒａｍｅ＿Ｎｕｍｂｅｒ、Ｄａｔａ＿Ｓｉｚｅのそれぞれを初期化する（Ｆｒａｍｅ＿Ｎｕｍｂｅｒ←０、Ｄａｔａ＿Ｓｉｚｅ←０）。
【０２２９】
ステップＳ２０７においてＣＰＵ２８は、ＡＯＢファイル＃ｚに書き込むべき、オーディオデータトランスポートストリームの入力が終了したかを判定する。ＡＡＣエンコーダ２５により符号化され、スクランブル部２６により暗号化されたオーディオデータトランスポートストリームが続々とＲＡＭ２２に格納されており、クラスタデータの書き込みを継続する必要がある場合、ステップＳ２０７がＮｏとなりステップＳ２０９に移行する。ステップＳ２０９においてＣＰＵ２８は、クラスタサイズ分のＡＡＣオーディオデータがＲＡＭ２２に蓄積したかを判定する。ＲＡＭ２２にクラスタデータが蓄積した場合、ステップＳ２０９がＹｅｓとなり、ステップＳ２１０に移行して、ＲＡＭ２２に蓄積されたクラスタサイズのＡＡＣオーディオデータをフラッシュメモリカード３１に書き込んだ後ステップＳ２１１に移行する。クラスタデータの蓄積が完了していない場合、ステップＳ２１０をスキップしてステップＳ２１１に移行する。ステップＳ２１１においてＣＰＵ２８は、Ｆｒａｍｅ＿Ｎｕｍｂｅｒをインクリメントし（Ｆｒａｍｅ＿Ｎｕｍｂｅｒ←Ｆｒａｍｅ＿Ｎｕｍｂｅｒ＋１）、Ｄａｔａ＿ＳｉｚｅをそのＡＯＢ＿ＦＲＡＭＥのデータサイズだけインクリメントする。かかる更新を行った後、ステップＳ２１２においてＦｒａｍｅ＿Ｎｕｍｂｅｒが、『ＦＮｓ＿Ｍｉｄｄｌｅ＿ＴＭＳＲＴＥ』として定めているフレーム数に達したか否かを判定する。ここで『ＦＮｓ＿Ｍｉｄｄｌｅ＿ＴＭＳＲＴＥ』は、オーディオデータトランスポートストリームが符号化された際のサンプリング周波数に応じた値となるので、Ｆｒａｍｅ＿Ｎｕｍｂｅｒが、『ＦＮｓ＿Ｍｉｄｄｌｅ＿ＴＭＳＲＴＥ』に達した場合は、ステップＳ２１２はＹｅｓとなるが、そうでない場合、ステップＳ２１２はＮｏになり、ステップＳ２０７に移行する。以降、ステップＳ２０７、ステップＳ２１２がＹｅｓとなるまで、ステップＳ２０７〜ステップＳ２１２は繰り返し行われる。
【０２３０】
Ｆｒａｍｅ＿Ｎｕｍｂｅｒが『ＦＮｓ＿Ｍｉｄｄｌｅ＿ＴＭＳＲＴＥ』に達してステップＳ２１２がＹｅｓとなった場合、ステップＳ２１２からステップＳ２１３に移行し、Ｄａｔａ＿ＳｉｚｅをＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙについてのＴＭＳＲＴ＿ｅｎｔｒｙ＃ｙとしてＴＫＩ＃ｚのＴＫＴＭＳＲＴに格納してステップＳ２１４において＃ｙをインクリメントした後（ｙ←ｙ＋１）、ステップＳ２１５において変数ｙが２５２に達したか否かを判定する。ここで２５２という値は、一個のＡＯＢに格納できるＡＯＢ＿ＥＬＥＭＥＮＴの総数を示す値であり、変数ｙが２５２に達しない場合、ステップＳ２１６に移行する。ステップＳ２１６では、無音状態が所定時間以上継続しており、オーディオデータがトラック間の境界に達したか否かを判定する。無音状態が存在しない場合、ステップＳ２０６〜ステップＳ２１５の処理を繰り返し行う。変数ｙが２５２に達した場合、又は、無音状態が所定時間以上継続した場合、ステップＳ２１５、ステップＳ２１６の何れか一方がＹｅｓとなり、ステップＳ２１７に移行して、変数＃ｚ，＃ｗをインクリメントする（ｚ←ｚ＋１，ｗ←ｗ＋１）。その後、インクリメントされた＃ｚについて、ステップＳ２０２〜ステップＳ２１６の処理を繰り返し行う。かかる繰り返しにより、複数のＡＯＢ＿ＥＬＥＭＥＮＴを含むＡＯＢが次々とフラッシュメモリカード３１に書き込まれてゆく。
【０２３１】
ここで、ＡＡＣエンコーダ２５、スクランブル部２６、モデム装置２７からのオーディオデータトランスポートストリームの伝送が終了した場合、ＡＯＢファイル＃ｚに書き込むべき、オーディオデータトランスポートストリームの入力が終了したことになるので、ステップＳ２０７がＹｅｓとなり、ステップＳ２０８に移行する。ステップＳ２０８においてＣＰＵ２８は、Ｄａｔａ＿ＳｉｚｅをＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙについてのＴＭＳＲＴ＿ｅｎｔｒｙ＃ｙとしてＴＫＩ＃ｚのＴＫＴＭＳＲＴに格納し、ＲＡＭ２２に蓄積されたオーディオデータをＡＯＢ＿ｚに対応するＡＯＢファイルに格納した後、本フローチャートの処理を終了する。
【０２３２】
以上の処理により、暗号化されたオーディオデータトランスポートストリームは、フラッシュメモリカード３１に格納されたことになるが、この暗号化を解除するためのＦｉｌｅＫｅｙは、以下の処理により、プロテクト領域に格納される。
入力経路ＲＴ２，ＲＴ３の場合は、一個のＡＯＢの符号化が開始される度に、ＣＰＵ２８は異なるＦｉｌｅＫｅｙを生成して、スクランブル部２６に設定し、そのＦｉｌｅＫｅｙでスクランブル部２６に暗号化を行わせると共に、それらのＦｉｌｅＫｅｙをプロテクト領域に存在する暗号鍵格納ファイルのＦｉｌｅＫｅｙ　Ｅｎｔｒｙ以降に格納する。
【０２３３】
一方入力経路ＲＴ１の場合は、ＡＯＢファイル、ＴＫＭＧを格納したファイル、ＰＬＭＧを格納したファイル、ＡＯＢ毎の異なるＦｉｌｅＫｅｙを格納した暗号鍵格納ファイルは、電子音楽配信のプロバイダより、送信される。ＣＰＵ２８は、それらを受信して、ＡＯＢファイル、ＴＫＭＧを格納したファイル、ＰＬＭＧを格納したファイルをユーザデータ領域に書き込み、ＡＯＢ毎の異なるＦｉｌｅＫｅｙを格納した暗号鍵格納ファイルをプロテクト領域に書き込む。
【０２３４】
以上のように本実施形態によれば、ＡＯＢを格納したファイルは、それぞれ異なる暗号鍵にて暗号化されているので、１つのファイルを暗号化に用いられた暗号鍵が解読され、暴露されたとしても、その解読によって復号できるＡＯＢは、１つのファイルに格納されているＡＯＢだけであり、他のファイルに格納されたＡＯＢには何の影響も及ぼさない。暗号鍵が暴露された場合の損失を最小限に抑える事ができる。
【０２３５】
なお、上記実施形態は現状において最善の効果が期待できるシステム例として説明したに過ぎない。本発明は、その要旨を逸脱しない範囲で実施変更することができる。具体的には、以下の（ａ）〜（ｆ）に示すような変更実施が可能である。
（ａ）本実施の形態では、記録媒体を半導体メモリ（フラッシュメモリカード）として説明を行ったが、これに限られるものではなく、ＤＶＤ−ＲＡＭなどの光ディスクやハードディスクなどに置き換えることができる。
【０２３６】
（ｂ）本実施の形態では、音楽データとしてＡＡＣを使用したが、これに限られるものではなく、ＭＰ３（ＭＰＥＧ　１　Ａｕｄｉｏ　Ｌａｙｅｒ　３）、Ｄｏｌｂｙ−ＡＣ３、ＤＴＳ（Ｄｉｇｉｔａｌ　Ｔｈｅａｔｅｒ　Ｓｙｓｔｅｍ）などであってもよい。
（ｃ）ＴＫＭＧを格納したファイル、ＰＬＭＧを格納したファイルのそのものを電子音楽配信にて配信するのではなく、ＴＫＭＧ，ＰＬＭＧの元となる情報を、ＡＯＢファイル、ＡＯＢ毎の異なる暗号鍵を格納した暗号鍵格納ファイルと共に配信し、記録装置において、このＴＫＭＧ，ＰＬＭＧの元となる情報を加工することによりＴＫＭＧ，ＰＬＭＧを得て、フラッシュメモリカードに記録しても良い。
【０２３７】
（ｄ）説明の便宜上、記録装置、再生装置をそれぞれ別装置としたが、携帯型再生装置に記録装置の機能を具備してもよいし、パソコン型の記録装置に再生装置の機能を具備させてもよい。また、これら携帯型再生装置、パソコン型記録装置以外にも、ネットワークからコンテンツをダウンロードすることができる通信機器に、これら再生装置、記録装置の機能を具備させてもよい。例えば、インタネットのアクセスが可能な携帯型電話機に、第１実施形態に示した再生装置、記録装置の機能を具備させ、携帯型電話機が無線ネットワークを介してダウンロードしたコンテンツを、第１実施形態に示したように、フラッシュメモリカード３１に格納しても良い。更に、本実施形態ではインターネットとの接続のために記録装置は、モデム装置２７を有していたが、これに替えて、ＩＳＤＮ回線との接続を行うためのターミナルアダプタ等を具備していてもよい。
【０２３８】
（ｅ）図５５〜図５８、図６０、図６３〜図６５、図６８のフローチャートを参照して説明した手順等を実行形式プログラムにより実現し、これを記録媒体に記録して流通・販売の対象にしても良い。このような記録媒体には、ＩＣカードや光ディスク、フロッピー（登録商標）ディスク等があるが、これらに記録された機械語プログラムは汎用コンピュータにインストールされることにより利用に供される。この汎用コンピュータは、インストールした実行形式プログラムを逐次実行して、本実施形態に示した再生装置、記録装置の機能を実現するのである。
【０２３９】
（ｆ）本実施形態においてフラッシュメモリカード３１に複数のＡＯＢと、複数のＦｉｌｅＫｅｙとを格納させたが、フラッシュメモリカード３１に１つのＡＯＢと、１つのＦｉｌｅＫｅｙとを格納させてよい。また、ＡＯＢの暗号化を行わず、ＡＡＣ方式のＡＯＢをフラッシュメモリカード３１に格納させてもよい。
（第２実施形態）
第１実施形態では、フラッシュメモリカード３１における記憶領域を示したのみで、その内部にどのようなハードウェア構成が実装されているかの説明は行わなかったが、第２実施形態は、かかるハードウェア構成を詳細に示す実施形態である。
【０２４０】
［６９−１］　フラッシュメモリカード３１のハードウェア構成
図６９は、フラッシュメモリカード３１のハードウェア構成を示す図である。このフラッシュメモリカード３１は、３つのＩＣチップ（コントロールＩＣ３０２、フラッシュメモリ３０３、ＲＯＭ３０４）を内蔵している。
ＲＯＭ３０４は、その内部に第１実施形態に示したシステム領域を有し、第１実施形態に示したメディアＩＤの他に、そのメディアＩＤを暗号化して得られるセキュアメディアＩＤ３４３も格納されている。
【０２４１】
コントロールＩＣ３０２は、アクティブ素子（論理ゲート等）からなる制御回路であり、認証部３２１、コマンド解読部３２２、マスター鍵記憶部３２３、システム領域アクセス制御部３２４、プロテクト領域アクセス制御部３２５、非プロテクト領域アクセス制御部３２６及び暗号・復号化回路３２７等を有する。
認証部３２１は、ＣＯＭＭＡＮＤピンを介して、このフラッシュメモリカード３１にアクセスしようとする機器とチャレンジ・レスポンス型の相互認証を行う回路であり、乱数発生器や暗号器等を有し、その暗号器と同一の暗号器を相手側機器が有しているか否かを検出することによって、相手側機器の正当性を認証する。ここでチャレンジ・レスポンス型の相互認証とは、相手側機器の正当性を検証するためにチャレンジデータを相手側機器に送り、それに対して相手側機器において自己の正当性を証明する処理が施こされて生成されたレスポンスデータを相手側機器から受け取り、それらチャレンジデータとレスポンスデータとを比較することで相手側機器を認証することができるか否かを判断するという認証ステップを、双方の機器が相互に行うことである。
【０２４２】
コマンド解読部３２２は、ＣＯＭＭＡＮＤピンを介して入力されたコマンド（このフラッシュメモリカード３１への命令）の種類を判定し実行するデコード回路や制御回路からなるコントローラであり、入力されたコマンドの種類に応じて、各種構成要素３２１〜３２７を制御する。
コマンドには、フラッシュメモリ３０３のデータを読み・書き・消去するコマンド等がある。例えば、データの読み書きに関しては、プロテクト領域にアクセスするためのコマンド「ＳｅｃｕｒｅＲｅａｄ　ａｄｄｒｅｓｓ　ｃｏｕｎｔ」、「ＳｅｃｕｒｅＷｒｉｔｅ　ａｄｄｒｅｓｓ　ｃｏｕｎｔ」や、非プロテクト領域にアクセスするためのコマンド「Ｒｅａｄ　ａｄｄｒｅｓｓ　ｃｏｕｎｔ」、「Ｗｒｉｔｅ　ａｄｄｒｅｓｓ　ｃｏｕｎｔ」等が定義されている。ここで、「ａｄｄｒｅｓｓ」は、読み書きの対象となる一連のセクタ群の最初のセクタの番号であり、「ｃｏｕｎｔ」は、読み書きする合計セクタ数を示す。また、セクタは、フラッシュメモリカード３１に対してデータを読み書きする際の単位であり、ここでは、５１２バイトである。
【０２４３】
マスター鍵記憶部３２３は、暗号化されたマスター鍵３２３ａを予め記憶している。マスタ鍵とは、メディアＩＤの暗号化に用いられる暗号鍵であり、フラッシュメモリカード３１が機器に接続された際、暗号化がなされたまま、その機器に引き渡される。このマスタ鍵の暗号化は、このマスタ鍵を受け取った機器に固有な鍵情報（一般にデバイス鍵と呼ばれる。）を用いた場合のみ復号される。
【０２４４】
システム領域アクセス制御部３２４は、システム領域であるＲＯＭ３０４に格納されたメディアＩＤ等を読み出す回路である。システム領域アクセス制御部３２４により読み出されたメディアＩＤは、この区間に接続された機器に引き渡され、その機器において、デバイス鍵により復号されたマスタ鍵を用いて暗号化される。プロテクト領域アクセス制御部３２５及び非プロテクト領域アクセス制御部３２６は、それぞれ、フラッシュメモリ３０３のプロテクト領域及び非プロテクト領域へのデータ書き込み及びデータ読み出しを実行する回路であり、４本のデータピンを介して外部機器（第１実施形態に示した記録装置、再生装置等）との間でデータを送受信する。
【０２４５】
なお、これらアクセス制御部３２５、３２６は、内部に１ブロック分のバッファメモリを有し、ＤＡＴＡ１〜４ピンを介した入出力を行う。この入出力は、論理的にはセクタを単位として行われるが、フラッシュメモリ３０３の内容を書き換えるときには、ブロック（３２個のセクタ、１６Ｋバイト）を単位として入出力する。具体的には、ある１個のセクタデータを書き換える場合には、フラッシュメモリ３０３から該当するブロックをバッファメモリに読み出し、そのブロックを一括消去するともに、バッファメモリ中の該当セクタを書き換えた後に、そのブロックをバッファメモリからフラッシュメモリ３０３に書き戻す。
【０２４６】
暗号・復号化回路３２７は、プロテクト領域アクセス制御部３２５及び非プロテクト領域アクセス制御部３２６による制御の下で、マスター鍵記憶部３２３に格納されたマスター鍵３２３ａを用いて暗号化及び復号化を行う回路であり、フラッシュメモリ３０３にデータを書き込む際にそのデータを暗号化して書き込み、フラッシュメモリ３０３からデータを読み出した際にそのデータを復号化する。これは、不正なユーザがこのフラッシュメモリカード３１を分解してフラッシュメモリ３０３の内容を直接解析し、プロテクト領域に格納されたパスワードを盗む等の不正行為を防止するためである。
【０２４７】
［６９＿７０］　ＡＯＢを再生する場合の通信シーケンス
図７０は、フラッシュメモリカード３１に接続された再生装置が、暗号鍵ＦｉｌｅＫｅｙを読み出して、ＡＯＢを再生する場合の通信シーケンスを示す図である。
再生装置は、フラッシュメモリカード３１にマスタ鍵を読み出す旨のコマンドを発行する（ｓｃ１）。コマンドが発行されると、コマンド解読部３２２は、マスター鍵記憶部３２３に記憶されている暗号化マスター鍵３２３ｂを取り出し、再生装置に引き渡す（ｓｃ２）。
【０２４８】
暗号化マスター鍵３２３ｂを受け取った再生装置は、自身が保持しているデバイス鍵２１１ａを用いて暗号化マスター鍵３２３ｂを復号する（ｓｃ３）。この復号処理に用いられる復号アルゴリズムは、フラッシュメモリカード３１に格納されている暗号化マスター鍵３２３ｂが生成された際に用いられた暗号アルゴリズムに対応したものなので、この再生装置が有するデバイス鍵２１１ａが予定されたもの（正規のもの）であれば、この復号によってマスター鍵は正常に復元されることなる。
【０２４９】
マスタ鍵を得た再生装置は、フラッシュメモリカード３１にメディアＩＤを読み出す旨の専用コマンドをフラッシュメモリカード３１に発行する（ｓｃ４）。システム領域アクセス制御部３２４は、フラッシュメモリカード３１のＲＯＭ３０４に記憶されているメディアＩＤを取り出し、再生装置に引き渡す（ｓｃ５）。暗号・復号化回路３２７は、復元により得られた上記マスター鍵を用いて、取り出されたメディアＩＤを暗号化する（ｓｃ６）。ここでの暗号アルゴリズムは、フラッシュメモリカード３１に格納されているセキュアメディアＩＤ３４３が生成された際に用いられた暗号アルゴリズムと同一である。従って、この暗号化によって、フラッシュメモリカード３１が有するセキュアメディアＩＤ３４３と同一のセキュアメディアＩＤが得られる。
【０２５０】
同一セキュアメディアＩＤを得ることに成功した再生装置は、フラッシュメモリカード３１における認証部３２１との相互認証を行なう（ｓｃ７）。その結果、いずれの機器においても、相手側機器の認証に成功したか否かを示す（ＯＫ／ＮＧ）情報と、その認証結果に依存して定まる時変の鍵であるセキュア鍵とを両者は享有することなる。
【０２５１】
相互認証に成功した再生装置は、フラッシュメモリカード３１のプロテクト領域にアクセスするためのコマンドを生成する。例えばプロテクト領域からデータを読み出す場合であれば、そのコマンド「ＳｅｃｕｒｅＲｅａｄ　ａｄｄｒｅｓｓ　ｃｏｕｎｔ」のパラメータ（２４ビット長のアドレス「ａｄｄｒｅｓｓ」と８ビット長のカウント「ｃｏｕｎｔ」）をセキュア鍵で暗号化し（ｓｃ８）、得られた暗号化パラメータと、そのコマンドのタグ（コマンドの種類「ＳｅｃｕｒｅＲｅａｄ」を示す６ビット長のコード）とを連結することにより暗号化コマンドを生成して（ｓｃ９）、フラッシュメモリカード３１に送る（ｓｃ１０）。
【０２５２】
暗号化コマンドを受け取ったフラッシュメモリカード３１は、そのタグからコマンドの種類を判定する（ｓｃ１１）。ここでは、プロテクト領域からの読出コマンド「ＳｅｃｕｒｅＲｅａｄ」であると判定する。
読出コマンドであると判定した場合、暗号・復号化回路３２７は、そのコマンドに含まれていたパラメータを、相互認証で得られたセキュア鍵を用いて（ｓｃ１２）復号する（ｓｃ１３）。ここでの復号に用いられるアルゴリズムは、再生装置において暗号化コマンドを生成する際に用いられた暗号アルゴリズムに対応するので、相互認証が成功していれば、即ち、双方の機器で用いられるセキュア鍵が一致していれば、この復号によって得られるパラメータは、再生装置で用いられた元のパラメータに等しくなる。
【０２５３】
正当なパラメータを含むコマンドを得たプロテクト領域アクセス制御部３２５は、その正当なパラメータによって特定されるセクタをアクセスして、そこに格納された暗号鍵ＦｉｌｅＫｅｙをプロテクト領域から読み出す。暗号・復号化回路３２７は、相互認証により得られたセキュア鍵を用いて（ｓｃ１４）、プロテクト領域のＡＯＢＳＡ１．ＫＥＹに格納されている暗号鍵ＦｉｌｅＫｅｙを暗号化する（ｓｃ１５）。暗号・復号化回路３２７による暗号化が行われると、プロテクト領域アクセス制御部３２５は、プロテクト領域のＡＯＢＳＡ１．ＫＥＹに格納されている暗号鍵ＦｉｌｅＫｅｙを再生装置に送信して引き渡す（ｓｃ１６）。
【０２５４】
再生装置は、送られてきた暗号鍵ＦｉｌｅＫｅｙを、相互認証で得られたセキュア鍵を用いて（ｓｃ１７）、復号する（ｓｃ１８）。ここでの復号アルゴリズムは、フラッシュメモリカード３１において暗号鍵ＦｉｌｅＫｅｙの暗号化に用いられたアルゴリズムに対応するので、相互認証が成功していれば、即ち、双方の機器で用いられるセキュア鍵が一致していれば、この復号により、元の暗号鍵ＦｉｌｅＫｅｙを得ることができる（ｓｃ１９）。その後、得られた暗号鍵ＦｉｌｅＫｅｙをマスター鍵３２３ａとメディアＩＤで復号化し、暗号鍵ＦｉｌｅＫｅｙを抽出する（ｓｃ２０）。
【０２５５】
暗号鍵ＦｉｌｅＫｅｙが得られ、非プロテクト領域からこの暗号鍵ＦｉｌｅＫｅｙに対応するＡＯＢが読み出されると（ｓｃ２１）、ＡＯＢをこの暗号鍵ＦｉｌｅＫｅｙを用いて復号しながら音楽を再生していく。
［６９＿７０＿７１］　相互認証における詳細な通信シーケンス
図７１は、図７０に示された相互認証における詳細な手順を示す通信シーケンス図である。ここでは、フラッシュメモリカード３１と再生装置は、チャレンジ・レスポンス型の相互認証を行う。
【０２５６】
フラッシュメモリカード３１における認証部３２１は、再生装置の正当性を検証するために、乱数を生成し（ｓｃ３０）、それをチャレンジデータとして再生装置に送る（ｓｃ５０）。再生装置は、自己の正当性を証明するために、そのチャレンジデータを暗号化し（ｓｃ３１）、レスポンスデータとしてフラッシュメモリカード３１における認証部３２１に返す（ｓｃ３２）。フラッシュメモリカード３１における認証部３２１は、チャレンジデータとして送った乱数を暗号化し（ｓｃ３３）、そのレスポンスデータと、暗号化チャレンジデータとを比較する（ｓｃ３４）。一致している場合には、再生装置の認証に成功した（ＯＫ）と認識し、その再生装置から送られてくるプロテクト領域へのアクセスコマンドを受け付ける。一方、比較の結果、一致しなかった場合には、認証に成功しなかった（ＮＧ）と認識し、もし、その後に再生装置からプロテクト領域へのアクセスコマンドが送られてきたとしても、その実行を拒絶する。
【０２５７】
同様にして、再生装置は、フラッシュメモリカード３１の正当性を検証するために、上記認証と同様のやりとりを行う。つまり、乱数を生成し（ｓｃ４０）、それをチャレンジデータとしてフラッシュメモリカード３１における認証部３２１に送る（ｓｃ５１）。認証部３２１は、自己の正当性を証明するために、そのチャレンジデータを暗号化し（ｓｃ４１）、レスポンスデータとして再生装置に返す。再生装置は、チャレンジデータとして送った乱数を暗号化し（ｓｃ４３）、その結果得られる暗号化チャレンジデータと、そのレスポンスデータとを比較し（ｓｃ４４）、一致している場合には、フラッシュメモリカード３１の認証に成功した（ＯＫ）と認識し、そのフラッシュメモリカード３１のプロテクト領域へのアクセスを行う。一方、比較の結果、一致しなかった場合には、認証に成功しなかった（ＮＧ）と認識し、そのフラッシュメモリカード３１のプロテクト領域へのアクセスは断念する。
【０２５８】
なお、これら相互認証における暗号化アルゴリズムは、フラッシュメモリカード３１及び再生装置が正当な機器である限り、全て同一である。また、フラッシュメモリカード３１及び再生装置は、それぞれの認証及び証明において生成した暗号化チャレンジデータとレスポンスデータとを排他的論理和演算を行い（ｓｃ４５，４６）、得られた結果をセキュア鍵として、フラッシュメモリカード３１のプロテクト領域へのアクセスのために用いる。そうすることで、フラッシュメモリカード３１と、これに接続された機器との相互認証に成功した場合にのみ共通となり、かつ、時変のセキュア鍵を共有し合うことが可能となり、これによって、プロテクト領域にアクセスする条件として相互認証に成功していることが条件とされることになる。
【０２５９】
また、セキュア鍵の生成方法として、暗号化チャレンジデータとレスポンスデータとセキュアメディアＩＤとの排他的論理和をとることしてもよい。
以上のように本実施形態によれば、これにより、著作権保護に関わるデータをプロテクト領域に格納し、そうでないデータを非プロテクト領域に格納することで、デジタル著作物と非著作物とを混在させて使用することができ、両方の用途を兼ね備えた半導体メモリカードが実現される。
【０２６０】
【発明の効果】
本発明に係る半導体メモリカードは、プロテクト領域と非プロテクト領域とを備える半導体メモリカードであって、プロテクト領域には、接続される機器と半導体メモリカードの間で互いの正当性が認証された場合のみ、当該機器によりアクセスできる領域であるとともに、複数の暗号鍵を所定の順序に配列してなる暗号鍵列が格納され、非プロテクト領域には、複数の暗号化されたオーディオオブジェクトと、管理情報が格納され、各オーディオオブジェクトは、固有識別情報を有し、再生すべき有効部分のみからなるものと、有効部分と共に、再生不要な無効部分をその先端及び／又は終端に含むものがあり、各暗号鍵は、固有識別情報によって各オーディオオブジェクトと対応付けられるとともに、対応するオーディオオブジェクトを復号化し、管理情報は、属性情報と、ブロック情報と、リンク情報と、プレイリストを含み、属性情報は、各オーディオオブジェクトが、オーディオトラックの先頭部分、中間部分、終端部分、全体部分のいずれであるかを示し、ブロック情報は、各オーディオオブジェクトの有効部分の開始位置を示すオフセットと、当該オフセットからの有効部分のデータ長とを示し、リンク情報は、オーディオトラックの先頭部分又は中間部分を構成するオーディオオブジェクトについて、それらに後続される中間部分又は終端部分との接続関係を有するオーディオオブジェクトを示し、プレイリストは、オーディオトラックの再生順序を示すとともに、各オーディオトラックにおけるオーディオオブジェクトの再生順序を示している。
【０２６１】
複数のオーディオオブジェクトは、複数の暗号鍵にて暗号化することが可能であるので、１つのオーディオオブジェクトを暗号化に用いられた暗号鍵が解読され、暴露されたとしても、その解読によって復号できるそのオーディオオブジェクト唯１つだけであり、他のオーディオオブジェクトには何の影響も及ばないので、暗号鍵が暴露された場合の損失を最小限に抑える事ができる。
【０２６２】
暗号化された複数のオーディオオブジェクトをどのようなオーディオトラックとして管理するかは、属性情報に示されているので、例えば２つのオーディオオブジェクトが、２つの独立したオーディオトラックとして管理されている場合、これら２つのオーディオオブジェクトにおける属性情報を、オーディオトラックの先頭部分と、オーディオトラックの終端部分とに変更することにより、２つのオーディオオブジェクトを１つのオーディオトラックに統合することができる。属性情報変更によりオーディオトラックの統合編集が行なえるので、オーディオオブジェクトの暗号化をむやみに解除することなく、統合編集を高速に行うことができる。
【０２６３】
オーディオフレームの前方に無効部分が存在する場合に、その無効部分のデータ長がどれだけであるか、有効部分のデータ長がどれだけであるかは、ブロック情報により設定されるので、格納されている音楽が、エアチェックして録音された音楽であり、その音楽のイントロの部分にディスクジョッキーの音声が混じっている場合、ブロック情報におけるデータオフセットを設定することにより、この不要音声をオーディオオブジェクトから除外して再生させないようにすることができる。ブロック情報の設定により、不要音声を再生させないように設定することが可能なので、オーディオオブジェクトの一部を削除するという編集がオーディオオブジェクトの暗号化を解除することなく、高速に行うことができる。
【図面の簡単な説明】
【図１】フラッシュメモリカード３１を上面から見た場合の形状を示す図である。
【図２】フラッシュメモリカード３１をその下面から見た場合の形状を示す図である。
【図３】本実施形態に係るフラッシュメモリカード３１の階層構造を示す図である。
【図４】（ａ）フラッシュメモリカード３１の物理層に設けられたシステム領域と、プロテクト領域と、ユーザデータ領域の構成を示す図である。
（ｂ）ファイルシステム層におけるプロテクト領域及びユーザデータ領域の構成を示す図である。
【図５】ファイルシステム層における構成の詳細を示す図である。
【図６】ＡＯＢ００１．ＳＡ１をクラスタサイズに合わせて５つに分割し、各分割部分を、クラスタ００３，００４，００５，００Ａ，００Ｃに格納する状態を想定した図である。
【図７】ＡＯＢ００１．ＳＡ１が複数のクラスタに記録されている場合のディレクトリエントリー及びファイルアロケーションテーブルについての設定例を示す図である。
【図８】（ａ）（ｂ）応用層におけるこれら２つのデータを格納する場合、ファイルシステム層においてユーザデータ領域及びプロテクト領域には、どのようなディレクトリが構成され、どのようなファイルが当該ディレクトリの配下に作成されるかを示す図である。
【図９】ＳＤ＿Ａｕｄｉｏディレクトリの下にあるＡＯＢＳＡ１．ＫＥＹと、ＡＯＢファイルとの対応を示す図である。
【図１０】ＡＯＢファイルのデータ構成を階層的に示す図である。
【図１１】（ａ）ＩＳＯ／ＩＥＣ１３８１８−７に記述されているパラメータを表形式に示す図である。
（ｂ）ＭＰＥＧ−Ｌａｙｅｒ３（ＭＰ３）方式にて符号化する際に使用すべきパラメータを表形式に示す図である。
（ｃ）Ｗｉｎｄｏｗｓ（登録商標）　Ｍｅｄｉａ　Ａｕｄｉｏ（ＷＭＡ）方式にて符号化する際に使用すべきパラメータを表形式に示す図である。
【図１２】ＡＯＢ＿ＦＲＡＭＥの構成の詳細を示す図である。
【図１３】３つのＡＯＢ＿ＦＲＡＭＥにおいて、それぞれのＡＯＢ＿ＦＲＡＭＥにおけるオーディオデータのバイト長がどのように設定されるかを示す図である。
【図１４】ｓａｍｐｌｉｎｇ＿ｆｒｅｑｕｅｎｃｙと、ＡＯＢ＿ＥＬＥＭＥＮＴに含まれるＡＯＢ＿ＦＲＡＭＥ数との対応を示す図である。
【図１５】ＡＯＢ＿ＥＬＥＭＥＮＴの時間長及びＡＯＢ＿ＦＲＡＭＥの時間長の一例を示す図である。
【図１６】ＡＯＢファイルに収録されている各ＡＯＢ、ＡＯＢ＿ＢＬＯＣＫが連続して再生されることにより、どのような再生内容が再生されるかを示す図である。
【図１７】第１実施形態におけるＰｌａｙｌｉｓｔｍａｎａｇｅｒ及びＴｒａｃｋＭａｎａｇｅｒの構成を段階的に詳細化した図である。
【図１８】ＰｌａｙＬｉｓｔＭａｎａｇｅｒ及びＴｒａｃｋＭａｎａｇｅｒのサイズを示す図である。
【図１９】図１７に示したＴＫＩと、図１６に示したＡＯＢファイル及びＡＯＢとの相互関係を示す図である。
【図２０】図１７に示したＴＫＴＭＳＲＴの詳細なデータ構造を示す図である。
【図２１】ＴＫＴＭＳＲＴについての一例を示す図である。
【図２２】ＴＫＧＩの詳細構成を示す図である。
【図２３】（ａ）（ｂ）ＢＩＴの詳細構成を示す図である。
（ｃ）ＴＩＭＥ＿ＬＥＮＧＴＨフィールドのデータフォーマットを示す図である。
【図２４】ＡＯＢ＿ＥＬＥＭＥＮＴ＃１〜＃４からなるＡＯＢが格納されているクラスタ００７〜クラスタ００Ｅを示す図である。
【図２５】ＡＯＢ内の任意のＡＯＢ＿ＥＬＥＭＥＮＴ＃ｙにおけるＡＯＢ＿ＦＲＡＭＥ＃ｘから順方向サーチ再生を行う場合、次に再生すべきＡＯＢ＿ＦＲＡＭＥ＃ｘ＋１をどのように設定するかを示す図である。
【図２６】（ａ）（ｂ）任意の再生開始時刻が指定された場合、その指定時刻に対応するＡＯＢ、ＡＯＢ＿ＥＬＥＭＥＮＴ、ＡＯＢ＿ＦＲＡＭＥをどのように特定するかを示す図である。
【図２７】（ａ）（ｂ）トラックを削除する場合を想定した図である。
【図２８】（ａ）トラックの削除が複数回行われた後のＴｒａｃｋＭａｎａｇｅｒを示す図である。
（ｂ）『Ｕｎｕｓｅｄ』のＴＫＩが存在しており、ここに新たなＴＫＩ、ＡＯＢファイルを書き込む場合、その書き込みがどのように行われるかを示す図である。
【図２９】（ａ）（ｂ）２つのトラックを統合する場合にＴＫＩがどのように設定されるかを示す図である。
【図３０】（ａ）　Ｔｙｐｅ１のＡＯＢを示す図である。
（ｂ）Ｔｙｐｅ２のＡＯＢを示す図である。
【図３１】（ａ）Ｔｙｐｅ１＋Ｔｙｐｅ２＋Ｔｙｐｅ２＋Ｔｙｐｅ１の組み合わせで、複数トラックを１つに統合する場合を示す図である。
（ｂ）Ｔｙｐｅ１＋Ｔｙｐｅ２＋Ｔｙｐｅ２＋Ｔｙｐｅ２＋Ｔｙｐｅ１の組み合わせで、複数トラックを１つに統合する場合を示す図である。
【図３２】（ａ）先行するトラックの終端にＴｙｐｅ１のＡＯＢが配され、後続するトラックの先頭にＴｙｐｅ１のＡＯＢが配されている配置パターンを示す図である。
（ｂ）先行するトラックの終端にＴｙｐｅ１のＡＯＢが配され、後続するトラックの先頭にＴｙｐｅ２のＡＯＢが配されている配置パターンを示す図である。
（ｃ）　先行するトラックの終端にＴｙｐｅ１、Ｔｙｐｅ２順でＡＯＢが配され、後続するトラックの先頭にＴｙｐｅ１のＡＯＢが配されている配置パターンを示す図である。
（ｄ）　先行するトラックの終端にＴｙｐｅ１、Ｔｙｐｅ２順でＡＯＢが配され、後続するトラックの先頭に、Ｔｙｐｅ２、Ｔｙｐｅ１のＡＯＢが配されている配置パターンを示す図である。
（ｅ）　先行するトラックの終端にＴｙｐｅ２、Ｔｙｐｅ２のＡＯＢが配され、後続するトラックの先頭にＴｙｐｅ１のＡＯＢが配されている配置パターンを示す図である。
【図３３】（ａ）（ｂ）１つのトラックを２つのトラックに分割する場合を想定した図である。
【図３４】（ａ）（ｂ）分割前後において、ＡＯＢ００３．ＳＡ１が属するＳＤ＿ＡｕｄｉｏディレクトリについてのＳＤ＿Ａｕｄｉｏディレクトリエントリーがどのように記述されているかかを示す図である。
【図３５】（ａ）ＡＯＢをＡＯＢ＿ＥＬＥＭＥＮＴ＃２の途中部分で分割する場合を想定した図である。
（ｂ）ＡＯＢ＿ＥＬＥＭＥＮＴ＃２の途中部分でＡＯＢが分割されて、ＡＯＢ＿１、ＡＯＢ＿２という２つのＡＯＢが得られた状態を示す図である。
【図３６】図３５に示したようにＡＯＢが分割された場合に、ＢＩＴがどのように設定されるかを示す図である。
【図３７】分割の前後でＢＩＴがどのように変化するかを具体的に示す図である。
【図３８】分割の前後でＴＫＴＭＳＲＴがどのように変化するかを具体的に示す図である。
【図３９】（ａ）ＤＰＬ＿ＴＫ＿ＳＲＰのフォーマットを示す図である。
（ｂ）ＰＬ＿ＴＫ＿ＳＲＰのフォーマットを示す図である。
【図４０】Ｄｅｆａｕｌｔ＿Ｐｌａｙｌｉｓｔ情報、ＴＫＩ、ＡＯＢファイルの相互関係を示す図である。
【図４１】ＤｅｆａｕｌｔＰｌａｙｌｉｓｔ、ＰｌａｙＬｉｓｔ情報の設定例を、図４０と同様の表記で示した図である。
【図４２】図４０と同じ表記法を用いてＤＰＬ＿ＴＫ＿ＳＲＰとＴＫＩとの対応を示す図である。
【図４３】（ａ）（ｂ）トラックの順序を入れ替える場合を想定した図である。
【図４４】（ａ）（ｂ）図４０に示したＤｅｆａｕｌｔＰｌａｙｌｉｓｔのうち、ＤＰＬ＿ＴＫ＿ＳＲＰ＃２及びＴＫＩ＃２を削除する場合にＤｅｆａｕｌｔＰｌａｙｌｉｓｔ、ＴｒａｃｋＭａｎａｇｅｒ、ＡＯＢファイルがどのように更新されるかを示す図である。
【図４５】（ａ）（ｂ）『Ｕｎｕｓｅｄ』のＴＫＩと、ＤＰＬ＿ＴＫ＿ＳＲＰとが存在しており、ここに新たなＴＫＩ、ＤＰＬ＿ＴＫ＿ＳＲＰを書き込む場合、その書き込みがどのように行われるかを示す図である。
【図４６】（ａ）（ｂ）トラックの統合を行う場合を想定した図である。
【図４７】（ａ）（ｂ）トラックの分割を行う場合を想定した図である。
【図４８】本実施形態に係るフラッシュメモリカード３１についての携帯型の再生装置を示す図である。
【図４９】プレイリストの選択が行われる際の液晶ディスプレィの表示内容の一例を示す図である。
【図５０】（ａ）〜（ｅ）トラックの選択が行われる際の液晶ディスプレィの表示内容の一例を示す図である。
【図５１】（ａ）〜（ｃ）ジョグダイアルの操作例を示す図である。
【図５２】再生装置の内部構成を示す図である。
【図５３】ダブルバッファ１５におけるデータ入出力がどのように行われるかを示す図である。
【図５４】（ａ）（ｂ）リングポインタを用いた巡回式の領域確保がどのように行われるかを示す図である。
【図５５】ＡＯＢファイル読み出し処理の処理手順を示すフローチャートである。
【図５６】ＡＯＢ＿ＦＲＡＭＥ出力処理の処理手順を示すフローチャートである。
【図５７】ＡＯＢ＿ＦＲＡＭＥ出力処理の処理手順を示すフローチャートである。
【図５８】ＡＯＢ＿ＦＲＡＭＥ出力処理の処理手順を示すフローチャートである。
【図５９】（ａ）〜（ｄ）液晶ディスプレィ５の時刻表示枠に表示される再生経過時刻が、変数Ｐｌａｙ＿Ｔｉｍｅの更新したがい、増加してゆく様子を示す図である。
【図６０】順方向サーチ再生処理時におけるＣＰＵ１０の処理手順を示すフローチャートである。
【図６１】（ａ）〜（ｄ）順方向サーチ再生時において、再生経過時刻がインクリメントされてゆく様子を示す図である。
【図６２】（ａ）〜（ｂ）タイムサーチ機能が行われる場合の具体例を示す図である。
【図６３】編集制御プログラムの処理手順を示すフローチャートである。
【図６４】編集制御プログラムの処理手順を示すフローチャートである。
【図６５】編集制御プログラムの処理手順を示すフローチャートである。
【図６６】フラッシュメモリカード３１の記録装置の一例を示す図である。
【図６７】記録装置のハードウェア構成を示す図である。
【図６８】記録処理の処理手順を示すフローチャートである。
【図６９】フラッシュメモリカード３１のハードウェア構成を示す図である。
【図７０】フラッシュメモリカード３１に接続された再生装置が、暗号鍵ＦｉｌｅＫｅｙを読み出して、ＡＯＢを再生する場合の通信シーケンスを示す図である。
【図７１】図７０に示された相互認証における詳細な手順を示す通信シーケンス図である。
【符号の説明】
１　　カードコネクタ
２　　ユーザインターフェイス部
３　　ＲＡＭ
４　　ＲＯＭ
５　　液晶ディスプレィ
６　　ＬＣＤドライバ
７　　デ・スクランブラ
８　　ＡＡＣデコーダ
９　　Ａ／Ｄコンバータ
１１　　ＤＰＬＩ常駐領域
１２　　ＰＬＩ格納領域
１３　　ＴＫＩ格納領域
１４　　ＦｉｌｅＫｅｙ格納領域
１５　　ダブルバッファ
２１　　カードコネクタ
２２　　ＲＡＭ
２３　　固定ディスク装置
２４　　コンバータ
２４　　Ａ／ＤステップＳ
２５　　ＡＡＣエンコーダ
２６　　スクランブル部
２７　　モデム装置
２８　　ＣＰＵ
２９　　キーボード
３０　　ディスプレィ
３１　　フラッシュメモリカード
３２　　プロテクトスイッチ
２１１　　デバイス鍵
３０３　　フラッシュメモリ
３２１　　認証部
３２２　　コマンド解読部
３２３　　マスター鍵
３２４　　システム領域アクセス制御部
３２５　　プロテクト領域アクセス制御部
３２６　　非プロテクト領域アクセス制御部
３２７　　復号化回路
【図１】
2004030586.tif 000003
【図２】
2004030586.tif 000004
【図３】
2004030586.tif 000005
【図４】
2004030586.tif 000006
【図５】
2004030586.tif 000007
【図６】
2004030586.tif 000008
【図７】
2004030586.tif 000009
【図８】
2004030586.tif 000010
【図９】
2004030586.tif 000011
【図１０】
2004030586.tif 000012
【図１１】
2004030586.tif 000013
【図１２】
2004030586.tif 000014
【図１３】
2004030586.tif 000015
【図１４】
2004030586.tif 000016
【図１５】
2004030586.tif 000017
【図１６】
2004030586.tif 000018
【図１７】
2004030586.tif 000019
【図１８】
2004030586.tif 000020
【図１９】
2004030586.tif 000021
【図２０】
2004030586.tif 000022
【図２１】
2004030586.tif 000023
【図２２】
2004030586.tif 000024
【図２３】
2004030586.tif 000025
【図２４】
2004030586.tif 000026
【図２５】
2004030586.tif 000027
【図２６】
2004030586.tif 000028
【図２７】
2004030586.tif 000029
【図２８】
2004030586.tif 000030
【図２９】
2004030586.tif 000031
【図３０】
2004030586.tif 000032
【図３１】
2004030586.tif 000033
【図３２】
2004030586.tif 000034
【図３３】
2004030586.tif 000035
【図３４】
2004030586.tif 000036
【図３５】
2004030586.tif 000037
【図３６】
2004030586.tif 000038
【図３７】
2004030586.tif 000039
【図３８】
2004030586.tif 000040
【図３９】
2004030586.tif 000041
【図４０】
2004030586.tif 000042
【図４１】
2004030586.tif 000043
【図４２】
2004030586.tif 000044
【図４３】
2004030586.tif 000045
【図４４】
2004030586.tif 000046
【図４５】
2004030586.tif 000047
【図４６】
2004030586.tif 000048
【図４７】
2004030586.tif 000049
【図４８】
2004030586.tif 000050
【図４９】
2004030586.tif 000051
【図５０】
2004030586.tif 000052
【図５１】
2004030586.tif 000053
【図５２】
2004030586.tif 000054
【図５３】
2004030586.tif 000055
【図５４】
2004030586.tif 000056
【図５５】
2004030586.tif 000057
【図５６】
2004030586.tif 000058
【図５７】
2004030586.tif 000059
【図５８】
2004030586.tif 000060
【図５９】
2004030586.tif 000061
【図６０】
2004030586.tif 000062
【図６１】
2004030586.tif 000063
【図６２】
2004030586.tif 000064
【図６３】
2004030586.tif 000065
【図６４】
2004030586.tif 000066
【図６５】
2004030586.tif 000067
【図６６】
2004030586.tif 000068
【図６７】
2004030586.tif 000069
【図６８】
2004030586.tif 000070
【図６９】
2004030586.tif 000071
【図７０】
2004030586.tif 000072
【図７１】
2004030586.tif 000073