JP4469125B2 - 半導体メモリカード、編集装置、編集方法、コンピュータ読み取り可能な記録媒体 - Google Patents
半導体メモリカード、編集装置、編集方法、コンピュータ読み取り可能な記録媒体 Download PDFInfo
- Publication number
- JP4469125B2 JP4469125B2 JP2002156443A JP2002156443A JP4469125B2 JP 4469125 B2 JP4469125 B2 JP 4469125B2 JP 2002156443 A JP2002156443 A JP 2002156443A JP 2002156443 A JP2002156443 A JP 2002156443A JP 4469125 B2 JP4469125 B2 JP 4469125B2
- Authority
- JP
- Japan
- Prior art keywords
- aob
- tki
- pob
- srp
- playback
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Storage Device Security (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、オーディオデータ、静止画データ、制御データを格納する半導体メモリカード、編集装置、再生方法、編集方法、コンピュータ読み取り可能な記録媒体に関し、特に、電子音楽配信等のコンテンツ配信サービスにおいて、コンテンツとして配信されたオーディオデータ、画像データ、制御データを格納する場合の改良に関する。
【０００２】
【従来の技術】
インターネットにおいて音楽コンテンツの購入が可能となる電子音楽配信は、音楽市場の活性化の起爆材になり得るものであり、その実現のためのインフラストラクチャは、着々と整備されつつある。上述した半導体メモリカードは、電子音楽配信から購入した音楽コンテンツを格納し、これを持ち運ぶのに好適な可搬型の記録媒体であり、今後その需要が飛躍的に増大すると期待される。
【０００３】
音楽コンテンツには、単に音楽再生が可能だけでは無く、音楽再生と共に、その音楽に関連する画像表示を行うことができる"メディアミックス"型の音楽コンテンツがある。歌詞を示す画像やその背景画となる画像を、カラオケ音楽ともに記録媒体に記録しておき、カラオケ音楽の再生時に、歌詞表示を行うという『カラオケソフト』は、"メディアミックス"型の典型的な音楽コンテンツであり、今後、電子音楽配信の更なる発展を考えるには、メディアミックス型の音楽コンテンツの流通・販売の実現をも視野に入れねばならない。それに伴い、"メディアミックス"型の音楽コンテンツを半導体メモリカードに格納する際の格納方式も、より具体的な検討が迫られることなる。
【０００４】
それでは、CD等の記録媒体において、"メディアミックス"型の音楽コンテンツは、どのように格納されていたか、即ち、記録媒体における従来のオーディオデータ−画像データの格納方式について説明する。
音楽再生と画像表示とを行うため、従来の"メディアミックス"型の音楽コンテンツは、音楽についてのオーディオデータと、歌詞・背景画を示す画像データとを多重化して得た多重化データを記録媒体に記録させることにより、オーディオデータの再生と、画像データの表示とを共に行っていた。多重化により、オーディオデータ再生ともに画像表示を実現していた記録媒体には、CD-Graphics(サブコードGraphics)と呼ばれるものがある。このCD-Graphicsにおける多重化の一単位は、16ビットのメインコードと、サブコードとからなり、16ビットのメインコードにオーディオデータを割り当て、サブコードに、歌詞や背景画像等の画像データを割り当てている。そしてCD-Graphicsに記録された音楽コンテンツの何れかの再生が開始されれば、16ビットのメインコードに割り当てられたオーディオデータが順次再生され、サブコードに割り当てられた画像データが順次表示される。
【０００５】
【発明が解決しようとする課題】
ところで上述したオーディオデータ−画像データの多重化方式に従って、複数の音楽コンテンツからなる音楽アルバムを製作しようとすると、各音楽コンテンツ毎に一律に画像を設けることなる。即ち、従来のオーディオデータ−画像データの多重化方式は、各音楽コンテンツに少なくとも1つの画像を割り当てることが要求されるので、製作者は、かかる画像の製作の手間に煩わされるという問題点がある。
【０００６】
もっとも、知名度が高いアーティストの音楽アルバムについては、音楽コンテンツ毎に異なる画像が設けられている方が消費者からも歓迎されるだろうし、音楽アルバムの売り上げが多大となると予想されるので、かかる手間と費用が報われる可能性が高い。逆に人気が低いアーティストの音楽アルバムについては、音楽コンテンツ毎に異なる画像が設けたとしても、消費者の反応は鈍いだろうし、音楽アルバムの売り上げが多大になることは期待できないので、かかる手間や費用が報われない可能性が高い。
【０００７】
画像製作に要した労力や経費が報われるか否かは、知名度の高い音楽アルバムと低い音楽アルバムとの間の落差が激しいことは明らかであるが、従来のオーディオデータ−画像データの多重化方式は、アーティストの知名度や、売り上げの見込数に拘らず、各音楽コンテンツに少なくとも1つの画像を割り当てることが要求されるので、この点において製作者にとって不満が残るものであった。
【０００８】
本発明の目的は、複数の音楽コンテンツからなる音楽アルバムを製作する場合において、各音楽コンテンツに割り当てるべき画像を製作する手間を削減することができる半導体メモリカードを提供することである。
【０００９】
【課題を解決するための手段】
ここで音楽コンテンツと表示すべき画像について考えてみると、音楽コンテンツの歌詞については、音楽コンテンツ毎に異なるものを設けることは必要不可欠となるが、背景画については、複数の音楽コンテンツの再生時に表示させるべき背景画を共通化して良い場合がある。例えば、複数の音楽コンテンツが同一人物により作詞・作曲・歌唱されている場合、それら複数の音楽コンテンツの再生時において、その人物の共通の写真を背景画として表示させることにより、製作者の手間を省くというオーディオデータ（オーディオオブジェクト）及び画像データ（静止画オブジェクト）の格納方式が考えられる。
【００１０】
複数音楽コンテンツ間の画像データ（静止画オブジェクト）の共通化を図って上記目的を達成するため、本発明に係る半導体メモリカードは、複数のオーディオオブジェクト、静止画オブジェクト、再生経路情報、第１ポインタ情報、第２ポインタ情報、シンボリックカウンタを格納する半導体メモリカードであって、再生経路情報は、オーディオオブジェクトの再生順序を示し、第１ポインタ情報は、再生経路情報に対応するものであって、該再生経路情報に従ったオーディオオブジェクトの全再生時間中における静止画オブジェクトの再生順序を示し、第２ポインタ情報は、特定のオーディオオブジェクトに対応するものであって、該オーディオオブジェクトの全再生時間中における静止画オブジェクトの再生順序を示し、シンボリックカウンタは、各静止画オブジェクトに対応づけられており、対応する静止画オブジェクトが第１ポインタ情報又は第２ポインタ情報により指定されているか否かを示し、指定されている静止画オブジェクトについては、幾つの第１ポインタ情報、第２ポインタ情報により指定されているかの指定数を示す、ことを特徴としている。
【００１１】
【発明の実施の形態】
以降、図面を参照しながら半導体メモリカード（フラッシュメモリカード）の実施形態について説明を行う。
尚、以降の各文には、その文頭に以下のような体系を有する分類番号を付している。
【００１２】
{x1-x2_x3-x4}
分類番号の桁数は、その項目の階層的な深さを意味している。具体的にいうと、x1は、説明に引用している図番である。本明細書に添付している図には、明細書において引用する順番に沿った番号を付しているので、この図番の順序が、説明の順序とほぼ同一となる。x2は、x1に示される図を引用して説明する場合の説明の順序を示す。x3は、x2の構成要素をより詳細に説明するために説明図を引用する場合、その説明図の図番を示し、x4は、x3に示される図を引用して説明する場合の説明の順序を示す。
【００１３】
（第１実施形態）
{1-1_2} フラッシュメモリカード３１の外観形状
初めに、フラッシュメモリカード３１の外観形状について説明する。図１は、フラッシュメモリカード３１を上面から見た場合の形状示す図であり、図２は、フラッシュメモリカード３１をその下面から見た場合の構造を示す図である。図１、図２に示すように、フラッシュメモリカード３１の大きさは、長さが約32.0 mm、幅は約24.0 mm、厚さ約2.0 mmであり、指先で把持できる程度の大きさ（切手サイズの大きさ）である。下面には、機器との接続のための9本のコネクタが設けられており、側面には、記憶内容の上書きを許可するか禁止するかを操作者が設定することができるプロテクトスイッチ３２が設けられている。
【００１４】
{3-1} フラッシュメモリカード３１の物理構造
図３は、本実施形態に係る半導体メモリカード（以下、フラッシュメモリカード３１と称する）の階層構造を示す図である。本図に示すように、フラッシュメモリカード３１の階層構造は、物理層、ファイルシステム層、応用層からなる点で、DVD（Digital Video Disc）の階層構造と同一であるが、各層における論理構造、物理構造は大きく相違する。
【００１５】
{3-2} フラッシュメモリカード３１の物理構造
先ずフラッシュメモリカード３１の物理層について説明する。フラッシュメモリは、複数のセクタからなり、各セクタは512バイトのディジタルデータを格納する。例えば64MByteタイプのフラッシュメモリカード３１の場合、そのメモリー容量は、67108864(=64×1024×1024)バイトであり、このときの有効セクタ数は131072(=67108864/512)となる。更に、この有効セクタからエラー用の代替セクタ数を差し引けば、残りの有効セクタ数は、128,000となり、ここに各種データが記録されることなる。
【００１６】
{3-2_4A-1} 物理層における3つの領域
これら有効セクタからなる領域には、図４（ａ）に示す3つの領域が設けられる。図４（ａ）は、フラッシュメモリカード３１の物理層に設けられた『システム領域』、『プロテクト領域』、『ユーザデータ領域』を示す図である。以降、これら3つの領域について説明する。
【００１７】
『ユーザデータ領域』は、フラッシュメモリカード３１と接続された機器が様々なデータを自由に書き込むことができ、データを自由に読み出すことができる領域であり、その内部領域がファイルシステムにより管理されている。
『システム領域』は、フラッシュメモリカード３１のそれぞれについてユニークな値を持つメディアIDが格納される領域である。ユーザデータ領域が書込可能であるのに対して、システム領域は、読出専用であり、ここに格納されたメディアIDを書き換えることはできない。
【００１８】
『プロテクト領域』は、ユーザデータ領域同様、データ書き込みが可能な領域である。ユーザデータ領域との差違は、ユーザデータ領域では、データの読み書きが自由に行なえるのに対して、プロテクト領域では、フラッシュメモリカード３１と接続された機器と、フラッシュメモリカード３１とが互いの正当性を確認した場合のみ読み書きすることができる点、即ち、フラッシュメモリカード３１と接続された機器と、フラッシュメモリカード３１との相互認証が成功した場合のみ、読み書き可能となる点である。
【００１９】
{3-2_4A-2} 物理層における3つの領域の用途
フラッシュメモリカード３１に接続された機器がフラッシュメモリカード３１にデータを書き込む際、そのデータの著作権保護の要否に応じて、これら3つの領域は利用される。ここで、著作権の保護が必要なデータをフラッシュメモリカード３１に書き込む場合、当該データは、所定の暗号鍵(FileKeyと呼ばれる。)を用いて暗号化された後にユーザデータ領域に格納される。このFileKeyは著作権者が自由に設定できるものであり、これだけでも、当該データの著作権は保護されるが、更に万全を期すため、この暗号化に用いたFileKey自身も暗号化する。FileKey自身を暗号化する際、鍵として用いられるのは、システム領域に格納されているメディアIDを所定の演算式に適用することにより得られる任意の値であり、プロテクト領域は、当該任意の値を用いて暗号化されたFileKeyを格納する。著作権保護が必要なデータは、所定のFileKeyを用いて暗号化し、このFileKey自身もメディアIDに基づいた値を用いて暗号化するという二段階の暗号化がなされるので、不正コピーなどの著作権侵害行為は、極めて困難になる。
【００２０】
{3-2_4B-1} ファイルシステムの概要
フラッシュメモリカード３１の物理層の構成は以上説明した通りであり、著作権保護の改良がなされていることがわかる。続いてこの物理層上に存在するファイルシステム層の構成について説明する。
DVDのファイルシステム層は、UDF(universal disk format)型のファイルシステムであるの対して、フラッシュメモリカード３１のファイルシステム層は、FAT型のファイルシステム（FAT:File Allocation Table,ISO/IEC 9293）であり、この点がDVDと異なる。
【００２１】
図４（ｂ）は、ファイルシステム層におけるプロテクト領域及びユーザデータ領域の構成を示す図である。図４（ｂ）においてファイルシステムにおけるプロテクト領域及びユーザデータ領域は、『パーティションブートセクタ』と、『ファイルアロケーションテーブル(FAT)』と、『ルートディレクトリエントリ』と、『データ領域』とを含んでおり、プロテクト領域とユーザデータ領域は共に同じ構成となっていることがこの図からも明らかである。図５は、これらファイルシステム構成の詳細を示す図である。以降、ユーザデータ領域についての構成を図４、図５を参照しながら説明する。
【００２２】
{3-2_4B-2} パーティションブートセクタ
『パーティションブートセクタ』は、フラッシュメモリカード３１が汎用パーソナルコンピュータに装填され、当該汎用パーソナルコンピュータのオペレーティングシステムの起動ディスクにフラッシュメモリカード３１を割り当てられた場合、汎用パーソナルコンピュータがブート時に参照すべき内容が記載されているセクタである。
【００２３】
{3-2_4B-3_5} データ領域
『データ領域』は、クラスタを最小単位にして、フラッシュメモリカード３１に接続された機器によりアクセスされる領域である。フラッシュメモリカード３１のセクタサイズが512バイトであるのに対して、クラスタサイズは、16Kバイトであるので、ファイルシステム層では32個のセクタを一単位として、データの読み書きが行われる。クラスタサイズを16Kバイトとした理由は、以下の通りである。即ち、フラッシュメモリカード３１にデータを書き込む場合、当該フラッシュメモリカード３１に格納されているデータを一旦イレーズ(消去)してから、データ書き込みを行わねばならない。フラッシュメモリカード３１において、そのようにデータをイレーズできるサイズは、16Kバイトであるので、このイレーズ可能なサイズにクラスタサイズを設定することにより、データ書き込みが好適に行われるようにしている。図５における破線の引き出し線ff2は、データ領域に含まれる複数のクラスタ002,003,004,005・・・・・を示す。図中の番号002,003,004,005,006,007,008・・・・・・・は、各クラスタを識別するために付与された3桁の16進数表記のクラスタ番号を示す。データ領域に対するアクセスは、クラスタを最小単位として行われるので、データ領域の内部位置は、これらのクラスタ番号を用いて、指示される。
【００２４】
{3-2_4B-4_5} ファイルアロケーションテーブル
『ファイルアロケーションテーブル』は、ISO/IEC 9293に準拠したファイルシステム構造を有しており、複数のFAT値からなる。各FAT値は各クラスタに対応づけられており、対応するクラスタが読み出された場合、次にどのクラスタを読み出せばよいかを示す。図５の破線の引き出し線ff1は、ファイルアロケーションテーブルに含まれる複数のFAT値002,003,004,005・・を示す。このFAT値に付与された数値『002,003,004,005・・』は、各FAT値がどのクラスタに対応づけられているか、つまり、各FAT値が対応づけられているクラスタのクラスタ番号を示す。
【００２５】
{3-2_4B-5_5-1} ルートディレクトリエントリ
『ルートディレクトリエントリ』は、ルートディレクトリにどのようなファイルが存在するかを示す情報である。具体的にいうと、ルートディレクトリエントリーには、存在するファイルの『ファイル名』と、そのファイルの『拡張子』と、『ファイル属性』と、ファイルの『更新時刻及び年月日』と、ファイルの先頭部が格納されている『ファイル最初のクラスタ番号』とが記載されている。
【００２６】
{3-2_4B-5_5-2} サブディレクトリのディレクトリエントリ
ルートディレクトリにあるファイルについての情報は、このルートディレクトリエントリーに記載されるが、サブディレクトリについての情報は、このルートディレクトリエントリーには記載されない。サブディレクトリについてのディレクトリエントリーは、データ領域内に作成される。図５のデータ領域内に記載されたSD_Audioディレクトリエントリーは、サブディレクトリについてのディレクトリエントリーの一例であり、本SD_Audioディレクトリエントリーは、ルートディレクトリエントリー同様、そのサブディレクトリに存在するファイルの『ファイル名』と、そのファイルの『拡張子』と、『ファイル属性』と、ファイルの『更新時刻及び年月日』と、ファイルの先頭部が格納されている『ファイル最初のクラスタ番号』とが記述される。
【００２７】
{3-2_4B-5_6-1} AOBファイルの格納方式
ここで、SD_AudioディレクトリにAOB001.SA1というファイルを格納する場合、AOB001.SA1がどのように格納されるか、即ち、ファイル格納方式の一例を図６を参照しながら説明する。上述したようにデータ領域の最小アクセス単位はクラスタであるので、AOB001.SA1は、クラスタサイズを最小単位にしてデータ領域に格納せねばならない。AOB001.SA1は、先ずクラスタサイズに分割されて、各クラスタに書き込まれる。図６は、AOB001.SA1をクラスタサイズに合わせて5つに分割し、各分割部分を、クラスタ003,004,005,00A,00Cに格納する状態を想定した図である。
【００２８】
{3-2_4B-5_7-1} AOBファイルの格納方式
AOB001.SA1が分割格納されると、ディレクトリエントリー及びファイルアロケーションテーブルは、図７のように設定されねばならない。
図７は、AOB001.SA1が複数のクラスタに記録されている場合のディレクトリエントリー及びファイルアロケーションテーブルについての設定例を示す図である。本図においてAOB001.SA1の先頭部分がクラスタ003に記録されている場合、SD_Audioディレクトリエントリーにおける『最初のクラスタ番号』には、その先頭部分が格納されているクラスタについてのクラスタ番号003が記載される。以降、AOB001.SA1の後続する部分は、クラスタ004、クラスタ005に格納されていることがわかる。AOB001.SA1の先頭部分を格納しているクラスタ003には、FAT値003(004)が対応しているが、このFAT値は、AOBファイルの後続する部分を格納しているクラスタ004を示すものである。またこれに後続している部分を格納しているクラスタ004,005には、FAT値004(005),FAT値005(00A)が対応しているが、これのFAT値は、AOBファイルの次の後続する部分を格納しているクラスタ005,00Aを示すものである。
【００２９】
これらFAT値に記載されたクラスタ番号を矢印fk1,fk2,fk3,fk4,fk5・・・・・に示すように順次読みとってゆけば、AOB001.SA1の分割部分を全て読み取ることができる。以上の説明により、フラッシュメモリカード３１のデータ領域は、クラスタを最小単位としてアクセスされ、また各クラスタにはそれぞれFAT値が対応づけられていることがわかる。尚、AOBファイルの末尾の部分を格納したクラスタ(図７の一例では、クラスタ00C)に対応づけられているFAT値には、そのクラスタがファイルの最終部分を格納していることを示すクラスタ番号『FFF』が記述される。
【００３０】
以上で、本発明のフラッシュメモリカード３１のファイルシステムに関する説明を終え、続いて、上述したファイルシステム上に存在する応用層の構成について説明する。
{3-3} フラッシュメモリカード３１における応用層の概要
フラッシュメモリカード３１における応用層の概要は、図３に記載された通りである。図３における破線の引き出し線PN1に示すようにフラッシュメモリカード３１における応用層は、プレゼンテーションデータと、プレゼンテーションデータの再生を制御するためのナビゲーションデータとからなる。
【００３１】
本図の破線の引き出し線PN2に示すように、プレゼンテーションデータは、音楽等の音声データをエンコードすることにより得られたオーディオオブジェクト群(AOB群)を含み、ナビゲーションデータは、プレイリストマネージャー(PlaylistManager(PLMG))と、トラックマネージャー(Track Manager(TKMG))とを含む。
{3-3_8A,B-1} ディレクトリ構成
図８（ａ）、（ｂ）は、応用層におけるこれら2つのデータを格納する場合、ファイルシステム層においてユーザデータ領域及びプロテクト領域には、どのようなディレクトリが構成され、どのようなファイルが当該ディレクトリの配下に作成されるかを示す図である。本図における『SD_AUDIO.PLM』、『SD_AUDIO.TKM』は、プレイリストマネージャー(PlaylistManager(PLMG))、トラックマネージャー(Track Manager(TKMG))といったナビゲーションデータを収録したファイルであり、『AOB001.SA1』『AOB002.SA1』『AOB003.SA1』『AOB004.SA1』・・・・・は、プレゼンテーションデータであるオーディオオブジェクトを格納したファイル（以下、AOBファイルという）である。
【００３２】
『AOB0xx.SA1』における拡張子『SA』は、『Secure Audio』の略であり、これらの格納内容は、著作権保護の必要性があることを示す（尚、図８（ａ）にはAOBファイルが8個だけ記述されているが、これは単なる一例であり、SD_AudioディレクトリはAOBファイルを最大999個まで格納することができる。）。このようにプレゼンテーションデータに著作権保護の必要性がある場合、プロテクト領域には、SD_Audioディレクトリという名称のサブディレクトリが設けられ、そのSD_Audioディレクトリの配下に暗号鍵格納ファイルAOBSA1.KEYが作成される。図８（ｂ）は、SD_Audioの下に格納された暗号鍵格納ファイルAOBSA1.KEYを示す図である。暗号鍵格納ファイルAOBSA1.KEYには、複数の暗号鍵FileKeyを所定の順序に配列してなる暗号鍵列であるFileKey#1〜#8が格納されている。
【００３３】
電子音楽配信において音楽会社のサーバコンピュータは、この図８（ａ）、（ｂ）に示すSD_Audioディレクトリを保持しており、当該音楽コンテンツの購入要求が消費者から発せられれば、このSD_Audioディレクトリを圧縮し、暗号化した後、購入要求を発した消費者が所有するSD_Audioディレクトリを公衆ネットワークを介して送信する。消費者が所有するコンピュータがこのSD_Audioディレクトリを受信すると、このディレクトリの暗号化を解除すると共に、伸長を行い、SD_Audioディレクトリを得る（尚、ここでいう公衆ネットワークは、ISDN回線等の有線通信網、携帯電話に代表される無線通信網等、公衆に利用が解放されている全てのネットワークを含む）。尚、AOBファイルを音楽会社のサーバコンピュータからダウンロードし、消費者が所有するコンピュータが、フラッシュメモリカード３１においてこの図８（ａ）、（ｂ）に示すSD_Audioディレクトリを作成しても良い。
【００３４】
{3-3_9-1} AOBSA1.KEYと、AOBファイルとの対応
図９は、SD_Audioの下にあるAOBSA1.KEYと、AOBファイルとの対応を示す図である。本図においてユーザデータ領域における暗号化ファイルを暗号化する際に用いたFileKeyは、プロテクト領域に対応する暗号鍵格納ファイルに格納される。
【００３５】
暗号化されたAOBファイルと、暗号鍵格納ファイルとは、以下の一定の規則(1)(2)(3)に基づく対応関係を有する。
(1)暗号鍵格納ファイルは、暗号化されたファイルが格納されているディレクトリと同じディレクトリ名に配置される。図９のユーザデータ領域においてSD_AudioディレクトリにAOBファイルが配されており、暗号鍵格納ファイルもSD_Audioディレクトリに配されていることからも、この規則に従った、ファイル配置が行われていることがわかる。
【００３６】
(2)暗号鍵格納ファイルには、データ領域におけるAOBファイルのファイル名の先頭3文字と、所定の拡張子「.key」とを組み合わせたファイル名が付与される。AOBファイルのファイル名が『AOB001.SA1』である場合、暗号鍵格納ファイルには、矢印nk1,nk2に示すように、この先頭３文字『AOB』と、『SA1』と、拡張子『.key』とからなる『AOBSA1.KEY』というファイル名が付与されることがわかる。
【００３７】
(3) AOBファイルのファイル名には、暗号鍵格納ファイル内の暗号鍵列において、そのオーディオオブジェクトに対応するFilekeyが何番目に位置するか、即ち、対応するFileKeyの順位を示すシリアル番号が付与される。
図９における暗号鍵格納ファイル内の『File Key Entry#1,#2,#3・・・・・#8』は、暗号鍵格納ファイル内の各FileKeyが格納されている領域の先頭位置を示す。一方AOBファイルのファイル名には、"001","002","003","004"といったシリアル番号が付与されている。これらのAOBファイル内のシリアル番号は、対応するFileKeyが暗号鍵列において何番目に位置するかを意味するので、各AOBファイルを暗号化する際に用いたFileKeyは、同一のシリアル番号を有する『File Key Entry』に存在することなる。図９における矢印AK1,AK2,AK3は、AOBファイルとFileKeyとの対応関係を示す。即ち、ユーザデータ領域におけるAOB001.SA1は『File Key Entry#1』に格納されているFileKeyと対応しており、AOB002.SA1は、『File Key Entry#2』以降に格納されたFileKey、AOB003.SA1は『File Key Entry#3』以降に格納されたFileKeyに対応していることを示す。以上の(3)からもわかるように、AOBファイルの暗号化に用いたFileKeyは、各ファイル毎に異なるものであり、それらは、ファイル名に組み込まれている"001","002","003","004"といったシリアル番号と、同一のシリアル番号を有する『File Key Entry』に格納されている。各AOBファイルは異なるFileKeyを用いて暗号化されるので、仮に、特定のAOBファイルの暗号化キーが暴露された場合でも、他のAOBファイルは、暴露されたFileKeyを用いても暗号化を解除することはできない。これにより、AOBファイルを暗号化した際のFileKeyが暴露された場合の損害を最小限に留めることができる。
【００３８】
{3-3_10-1} AOBファイルの内部構成
続いてAOBファイルの内部構成について説明する。図１０は、AOBファイルのデータ構成を階層的に示す図である。本図の第１段目は、AOBファイルを示し、第２段目は、AOBを示す。第３段目は、AOB_BLOCKを示し、第４段目はAOB_ELEMENT、第５段目は、AOB_FRAMEを示す。
【００３９】
図１０の第５段目における『AOB_FRAME』は、AOBを構成する最小単位であり、ADTSヘッダと、ADTS（Audio Data Transport Stream）形式のオーディオデータとからなる。ADTS形式のオーディオデータは、MPEG2-AAC [ Low Complexity Profile]にて符号化され、16Kbps〜144Kbpsの伝送速度で再生されるストリームデータである（尚、既存のコンパクトディスクに記録されるPCMデータの伝送速度は1.5Mbpsであるので、PCMデータと比較して、一段と低いことがわかる。）。これらのAOB_FRAME列のデータ構造は、電子音楽配信にて配信されるオーディオデータトランスポートに含まれるオーディオフレーム列と同一である。即ち、AOB_FRAME列として格納されるべきオーディオデータトランスポートストリームは、MPEG2-ACCにてエンコードされ、更に暗号化された状態で、公衆ネットワークを伝送し、消費者宛に伝送される。AOBファイルは、そのように伝送されたオーディオデータトランスポートストリームを、AOB_FRAME列として分割して格納しているのである。
【００４０】
｛3-3_10-1_11｝MPEG2-AACについて
MPEG2-AACの詳細に関しては、ISO/IEC 13818-7:1997(E) Information technology - Generic coding of moving pictures and associated audio information - Part7 Advanced Audio Coding (AAC)を参照されたい。ここで注意すべきは、AOBは、ISO/IEC13818-7に記述されているパラメータ表を図１１（ａ）のように制限して適用されたMPEG2-AAC方式にて圧縮されている点である。図１１（ａ）は、ISO/IEC13818-7に記述されているパラメータ表を示す図であり、Parameter欄と、Value欄と、Comment欄の内容を示すコメント欄とからなる。
【００４１】
パラメータ欄『profile』は、ISO/IEC 13838-7で規定されているLC-profileの制限が適用されていることを示す。
パラメータ欄『sampling_frequency#index』は、『48kHz,44.1kHz,32kHz,24kHz,22.05kHZ,16kHz』といったサンプリング周波数が適用されていることを示す。パラメータ欄『number_of_data_block_in_frame』は、1header/1raw_data_blockに設定されていることを示す。
【００４２】
尚、AOB_FRAMEは、MPEG-AAC方式にて符号化されているものとして説明したが、AOB_FRAMEは、MPEG-Layer3(MP3)方式、Windows（登録商標） Media Audio(WMA方式等他の符号化方式にて符号化されてもよい。この際、図１１（ａ）に示したパラメータの代わりに、図１１（ｂ）、図１１（ｃ）に示すパラメータ表を用いねばならない。
【００４３】
{3-3_10-2_12} AOB_FRAMEの構成
『AOB_FRAME』は、以上の制限下で符号化されたオーディオデータを含むが、AOB_FRAMEに含まれるオーディオデータのデータ長は、その再生時間が20ミリ秒となるデータに過ぎない。しかし、MPEG2-AAC方式は可変長符号化方式であるので、各AOB_FRAMEに含まれるオーディオデータのデータ長は、それぞれのAOB_FRAME毎に異なる。以下、図１２を参照しながら、AOB_FRAMEの構成の詳細について説明する。本図の第１段目は、AOB_FRAMEの全体構成を示し、第２段目は、AOB_FRAMEのそれぞれの部位がどのように暗号化されているかを示す。この第２段目を参照すれば、ADTSヘッダは、非暗号化部、即ち、暗号化がなされていないことがわかる。また、オーディオデータは、暗号化された部分と、非暗号化部分との双方を含む。暗号化部分は、8バイトの暗号化データを複数配したものである。8バイトの暗号化データは、64ビットの元データを56ビットのFileKeyを用いて暗号化することにより生成されている。非暗号化部分は、そのように64ビット単位に暗号化が行われた際、64ビットに満たないために暗号化されずに残したものである。
【００４４】
第３段目は、非暗号化部分であるADTSヘッダの内容を示す図である。ADTSヘッダは7バイトであり、12ビットの同期ワード(FFFと設定されている)と、同じAOB_FRAMEに含まれるオーディオデータのデータ長と、そのオーディオデータをエンコードする際のサンプリング周波数とが記載されている。
{3-3_10-3_13} AOB_FRAMEのバイト長設定
図１３は、3つのAOB_FRAMEにおいて、それぞれのAOB_FRAMEにおけるオーディオデータのバイト長がどのように設定されるかを示す図である。本図において、AOB_FRAME#1に含まれるオーディオデータ#1のデータ長はx1、AOB_FRAME#2に含まれるオーディオデータ#2のデータ長はx2、AOB_FRAME#3に含まれるオーディオデータ#3のデータ長はx3であり、x1,x2,x3というようにそれぞれのデータ長が互いに異なる場合、AOB_FRAME#1に含まれるADTSヘッダには、データ長x1が記載され、AOB_FRAME#2に含まれるADTSヘッダには、データ長x2、AOB_FRAME#3に含まれるADTSヘッダには、データ長x3が記載される。オーディオデータそのものは、暗号化されているが、ADTSヘッダ自体は暗号化されていないので、各AOB_FRAMEにおけるADTSヘッダから、オーディオデータのデータ長を読み取ってゆけば、後続するAOB_FRAMEがどこから存在するかを知得することができる。以上でAOB_FRAMEについての説明を終える。
【００４５】
{3-3_10-4} AOB_ELEMENTについて
続いて図１０において第４段目に位置するAOB_ELEMENTについて説明する。
『AOB_ELEMENT』は、連続する複数のAOB_FRAMEの集合である。ここで、どれだけの数のAOB_FRAMEがAOB_ELEMENTに含まれるかは、図１１（ａ）に示したsampling_frequency_indexの設定と、符号化方式とに従って変化する。即ち、AOB_ELEMENTに含まれるAOB_FRAMEの個数は、そのAOB_ELEMENTに含まれるAOB_FRAMEの再生時間が大体2秒になるように定められており、サンプリング周波数と、符号化方式に応じて、異なる個数となる。
【００４６】
{3-3_10-5_14} AOB_ELEMENTに含まれるAOB_FRAME数
図１４は、sampling_frequencyと、AOB_ELEMENTに含まれるAOB_FRAME数との対応を示す図である。本図においてNはAOB_ELEMENTの再生期間を秒単位に示したものであり、符号化方式がMPEG-AAC方式であれば"2"となる。またsampling_frequencyが48kHzである場合、AOB_ELEMENTに含まれるフレーム数は、94(=47×2)個となり、sampling_frequencyが44.1kHzである場合、AOB_ELEMENTに含まれるフレーム数は86(=43×2)個、sampling_frequencyが32kHzである場合、AOB_ELEMENTに含まれるフレーム数は64(=32×2)個、sampling_frequencyが24kHzである場合、フレーム数は48(=24×2)個、sampling_frequencyが22.05kHzである場合、AOB_ELEMENTに含まれるフレーム数は44(=22×2)個、sampling_frequencyが16kHzである場合、AOB_ELEMENTに含まれるフレーム数は32(=16×2)個となる。但し、AOBを分割などの編集を行った場合、AOBの先頭と最後のAOB_ELEMENTのAOB_FRAME数は、図１４の個数より少なくなる場合がある。
【００４７】
AOB_ELEMENTには、ヘッダ等の特別な情報は付与されていないが、その代わりにそのデータ長がタイムサーチテーブルに示されている。
{3-3_10-6_15} AOB_ELEMENT及びAOB_FRAMEの時間長の一例
図１５は、AOB_ELEMENTの時間長及びAOB_FRAMEの時間長の一例を示す図である。本図の第１段目は、複数AOB_BLOCKの並びであり、第２段目は、複数AOB_ELEMENTの並びを示す。第３段目は、複数AOB_FRAMEの並びを示す。
【００４８】
本図を参照すると、AOB_ELEMENTは、約2.0秒という再生時間長に相当し、本図におけるAOB_FRAMEは、20msecという再生時間長に対応することが判る。AOB_ELEMENTのそれぞれに付されている『TMSRT_entry』という文字列は、各AOB_ELEMENTのデータ長がタイムサーチテーブルに記載されていることを示す。このようなTMSRT_entryを参照して、順方向サーチ再生、逆方向サーチ再生を行うことにより、例えば2.0秒をスキップして、240ミリ秒分だけ再生するという間欠な再生を実現することができるのである。
【００４９】
{3-3_10-7} AOB_BLOCKについて
以上でAOB_ELEMENTについての説明を終え、続いてAOB_ELEMENTの上位、即ち、図１０のAOBファイルのデータ構成を示す図における第３段目に位置するのAOB_BLOCKについて説明する。
『AOB_BLOCK』は、有効なAOB_ELEMENTからなる領域であり、AOBファイル中に一つ存在する。AOB_ELEMENTが2秒という再生時間に相当するのに対して、AOB_BLOCKは8.4分の再生時間を上限とした再生時間に相当する。各AOBを8.4分の再生時間に限定した理由は、AOB_BLOCKに含まれるAOB_ELEMENTの個数を制限することにより、タイムサーチテーブルのサイズを504バイト以下に抑制するためである。
【００５０】
{3-3_10-8} タイムサーチテーブルの抑制
以下、再生時間の限定により、タイムサーチテーブルの抑制が可能となった理由を詳細に説明する。
順方向サーチ再生、逆方向サーチ再生の再生を行う際、2秒分読み出しをスキップして240ミリ秒だけ再生するという『2秒スキップ240ミリ秒再生』が行われる。このように2秒という時間長をスキップする場合、原則として、AOB_FRAMEのADTSヘッダに示されているデータ長を順次参照してゆけばよいのだが、その場合、2秒という時間間隔をスキップするために100個(=2秒／20ミリ秒)ものAOB_FRAMEを順次検出せねばならず、再生装置に余分な処理負荷を与えてしまう。そのような処理負荷を軽減するには、その2秒間隔の読出先アドレスをタイムサーチテーブルに記述して、順方向サーチ再生及び逆方向サーチ再生が命じられた際、再生装置がこれを参照すればよい。即ち、タイムサーチテーブルには、2秒先、4秒先の読出先アドレスを算出するための情報、具体的には、各AOB_ELEMENTについてのデータ長を記述しておき、再生装置は、これを参照して、順方向サーチ再生-逆方向サーチ再生を行えばよいのである。2秒に相当するデータ長がどの程度になるかについて考察する。オーディオデータの再生時のビットレートは、上述したように16Kbps〜144Kbpsの範囲であるので、2秒当たりに再生されるデータ長は4Kbyte(=16Kbps×2／8)〜36Kbyte(=144Kbps×2/8)となる。
【００５１】
2秒当たりのデータ長が4Kbyte〜36Kbyteであるなら、オーディオデータのデータ長が記述されるためのタイムサーチテーブル内のエントリーのデータ長は、2バイト(16ビット)必要となる。何故なら、エントリーに16ビット長を割り当てたならば、0〜64KByteの数値が記述されることができるからである。一方、タイムサーチテーブルの総データサイズを例えば504バイト(これは後述するTKTMSRTのデータサイズである)内に制限する場合を考えると、このタイムサーチテーブル内に設けるべきエントリーは、252(=504/2)個に制限せねばならない。上述したように、エントリーは、2秒毎に設けられるものであるので252エントリーに対応する再生時間は、504秒(=2秒×252)となり、8分24秒(=8.4分)となる。このようにAOB_BLOCKにおける再生時間を8.4分以下に制限したことにより、タイムサーチテーブルのデータサイズを504バイト以下とすることができる。
【００５２】
{3-3_10-9} AOBについて
以上でAOB_BLOCKについての説明を終え、続いてAOBについて説明する。
図１０の第２段目に位置するAOBは、AOB_BLOCKの前後に無効領域が付与された領域であり、AOBファイル中に一つ存在する。
この無効領域は、当該、AOB_BLOCKと同じクラスタに格納され、当該AOB_BLOCKと供に読み書きされる領域である。AOBにおいて、何処から何処までがAOB_BLOCKに該当するのかは、ナビゲーションデータに含まれるBIT(その詳細についての説明は、後段で行う。)にて指定される。
【００５３】
以上で、各AOBファイルにどのようなデータが格納されているかが明らかとなった。続いて、図９に示した8つのAOBファイルに含まれるAOB、AOB_BLOCKが連続して読み出されることにより、どのような内容が再生されるかを説明する。
{3-3_10-10_16}
図１６は、AOBファイルに収録されている各AOB、AOB_BLOCKが連続して再生されることにより、どのような再生内容が再生されるかを示す。第１段目は、ユーザデータ領域における8つのAOBファイルを示し、第２段目は、各AOBファイルに収録されている8つのAOBを示す。第３段目は、それぞれのAOBに含まれる8つのAOB_BLOCKを示す。
【００５４】
第５段目は、5つのコンテンツ部からなるタイトルを示す。5つのコンテンツ部は、SongA、SongB、SongC、SongD、SongEという5つの曲のそれぞれを示し、タイトルは、これら5つの曲（コンテンツ）からなる音楽アルバムを示す。破線AS1,AS2,AS3・・・・AS7,AS8は、音楽アルバムの分割部分と、AOB_BLOCKとの対応関係を示し、第４段目は、第５段目の音楽アルバムがどのような単位で分割されるかを示す。
【００５５】
これらの破線を参照すると、各AOB#1に含まれるAOB_Blockは、6.1分という時間にて再生される曲(SongA)であり、各AOB#2に含まれるAOB_Blockは、3.3分という時間にて再生される曲(SongB)、各AOB#3に含まれるAOB_Blockは、5.5分という時間にて再生される曲(SongC)である。以上のようにAOB001.SA1〜AOB003.SA1は、それぞれが独立した曲に対応するものであることがわかる。第６段目は、TrackA〜Eからなるトラックシーケンスを示す。これらTrackA〜Eは、SongA、SongB、SongC、SongD、SongEという5つの曲のそれぞれと1対1に対応しており、一個の独立した再生単位として扱われる。
【００５６】
一方、AOB#4は、30.6分という時間にて再生される曲(SongD)の先頭部分であり、8.4分という再生時間にて再生される。AOB#5、AOB#6に含まれるAOB_BLOCKはSongDの中間部分であり、8.4分という再生時間、AOB#7に含まれるAOB_BLOCKは、SongDの終端部分であり、5.4分という再生時間にて再生される。このように30.6分という再生時間を有する曲は、(8.4分+8.4分+8.4分+5.4分)という単位で分割され、各AOBに含まれていることがわかる。この図からも理解できるように、AOBファイルに含まれる全ての曲は、再生時間長が8.4分という時間長以内に収められていることがわかる。
【００５７】
以上の説明によりAOBの再生時間長を制限することにより、各AOBに対応づけられているタイムサーチテーブルのデータサイズも制限されていることが明らかとなった。続いて、このタイムサーチテーブルを含むナビゲーションデータについて説明する。
{3-3_8A,B-2}
ナビゲーションデータは、『SD_Audio.PLM』『SD_Audio.TKM』という2つのファイルからなることは既に述べた通りである。ファイル『SD_Audio.PLM』は、プレイリストマネージャ(Playlistmanager)を含み、ファイル『SD_Audio.TKM』は、トラックマネージャ(TrackManager)を含む。
【００５８】
プレゼンテーションデータの説明で述べたように、複数のAOBファイルは、符号化されたAOBを収録しているが、これらのAOBの再生時間がどれだけであるか、また、それぞれのAOBがどのような曲名であり、作曲者は誰であるか等は何等記載されていない。一方、複数のAOBは、複数のAOBファイルに収録されているのみなので、それらをどのような順序で再生させるかは一切記載されていない。トラックマネージャ、プレイリストマネージャーは、こういった情報を再生装置に通知するために設けられている。
【００５９】
ここでトラックマネージャーは、AOBファイルに収録されているAOBと、トラックとの対応関係を示し、これらのAOBの再生時間がどれだけであるか、また、それぞれのAOBがどのような曲名であり、作曲者は誰であるか等の諸情報を示す複数のトラック管理情報を含む。トラックとは、ユーザにとって意味のある再生単位であり、フラッシュメモリカード３１に音楽著作物を格納しようとする場合、トラックは曲に対応し、フラッシュメモリカード３１にリーディングブックを格納しようとする場合（リーディングブックとは、書籍ではなく、読み上げ音声により表現された文書著作物をいう）、ブックジャンルであるなら、トラックは、文の章／節に対応する。トラックマネージャーは、複数AOBファイルに収録されている複数のAOBをトラックの集合として管理するために設けられている。
【００６０】
プレイリストとは、トラックの複数の再生順序を規定するものであり、プレイリストマネージャーは、このようなプレイリストを複数含んでいる。
以降、トラックマネージャーについて図面を参照しながら説明する。
{17-1_18} Playlistmanager及びTrackManagerの詳細構成
図１７は、実施形態におけるPlaylistmanager及びTrackManagerの構成を段階的に詳細化した図であり、図１８は、PlayListManager及びTrackManagerのサイズを示す図である。即ち、本図において右段に位置する論理フォーマットは、その左段に位置する論理フォーマットを詳細化したものであり、破線に示す引き出し線は、右段の論理フォーマットがその左段の論理フォーマット内のどの部分を詳細化したかを明確にしている。
【００６１】
このような表記に従って図１７におけるTrackManagerの構成を参照すると、TrackManagerは、破線の引き出し線h1に示すように、Track Information(TKIと略す)#1,#2,#3,#4・・・・・#nからなる。これらのTKIはAOBファイルに収録されているAOBを、トラックとして管理するための情報であり、各AOBファイルに対応している。
【００６２】
図１７を参照すると各TKIは、破線の引き出し線h2に示すように、Track_General_Informatin(TKGI) 、TKIに固有なテキスト情報が記述されるTrack_Text_Infomation_Data_Area(TKTXTI_DA)、タイムサーチテーブルの役割を有するTrack_Time_Serch_Table(TKTMSRT)からなることがわかる。図１８を参照すると、TKI自体は固定サイズ（1024バイト）であり、TKGIとTKTXTI_DAとは合計で512バイト固定長であることがわかる。TKTMSRTも512バイト固定長である。またTrackManagerにおいて、TKIは、最大999個まで設定することができる。
【００６３】
このTKTMSRTは、破線の引き出し線h3に示すように、TMSRT_Headerと、TMSRT_etry#1,#2,#3・・・・・#nとからなることがわかる。
{17-2_19} TKIと、AOBファイル及びAOBとの相互関係
図１９は、図１７に示したTKIと、図１６に示したAOBファイル及びAOBとの相互関係を示す図である。図１９の第１段目における四角枠はTrackA〜Eとからなるトラックシーケンス、図１９の第２段目における四角枠はTrackManagerを示し、第３、第４段目は図１６に示した8つのAOBファイルを示す。第５段目における8つの枠は、8つのAOBを示す。この8つのAOBファイルは、図１６に示した8つのAOBを収録していたものであり、TrackA、TrackB、TrackC、TrackD、TrackEを含む音楽アルバムを形成している。第２段目は、8つのTKIを示す。これらTKIに付与された数値"1","2","3","4"は、各TKIを識別するためのシリアル番号であり、各TKIは、同じシリアル番号001,002,003,004,005・・・・・が付与されたAOBファイルと対応づけられている。この点に注意して、図１９を参照すれば、TKI#1がAOB001.SA1に対応していて、TKI#2がAOB002.SA1、TKI#3がAOB003.SA1、TKI#4がAOB004.SA1に対応していることがわかる（本図における矢印TA1,TA2,TA3,TA4・・・・・・は、各TKIがどのAOBファイルと対応しているかを示す。）。このように各TKIは、各AOBファイルに収録されているAOBと、1対1の対応関係を有するので、各TKIには、AOBに固有な情報を詳細に記載しておくことができる。
【００６４】
{17-3_20} TKTMSRTのデータ構造について
AOBファイルに収録されているAOBに固有な情報として、先ず初めにTKTMSRTについて説明する。図２０は、図１７に示したTKTMSRTの詳細なデータ構造を示す図である。本図の右側には、タイムサーチテーブルヘッダ(TMSRT_Header)の詳細なデータ構造が示されている。図２０において、タイムサーチテーブルヘッダのデータサイズは8バイトであり、TMSRT_ID(0バイト目から1バイト目まで)、reserved(2バイト目から3バイト目まで)、Total TMSRT_entry_Number(4バイト目から7バイト目まで)という3つのフィールドを有する。『TMSRT_ID』には、TMSRTを一意に識別できるIDが記述される。『Total TMSRT_entry Number』には、当該TMSRT内にあるTMSRT_entryの総数が記述される。
【００６５】
{17-3_21-1} TKTMSRTの具体例について
続いてTKTMSRTについてより詳細に説明する。図２１は、TKTMSRTについての一例を示す図である。本図の左側に、AOBを示し、右側にTKTMSRTを示す。本図左側のAOBは、複数のAOB_ELEMENT#1,#2,#3・・・・・・#nからなり、その右側における複数の領域AR1,AR2,AR3・・・・・・ARnを占有している。また図中の『0』『32000』『64200』『97000』『1203400』『1240000』といった数値は、AOBに含まれるAOB_BLOCK先頭からの各AOB_ELEMENTの占有領域AR1,AR2,AR3,ARn-1,ARnまでの相対アドレスを示す。AOB_ELEMENT#2は、AOB_BLOCK先頭から『32000』だけ隔てられた位置に記録されていることを示す。AOB_ELEMENT#3は、AOB_BLOCK先頭から『64200』だけ隔てられた位置に、AOB_ELEMENT#n-1は、AOB_BLOCK先頭から『1203400』だけ隔てられた位置に記録されていることを示す。
【００６６】
注意すべきは、各占有領域の先頭アドレスの間隔が一定値ではないこと、即ち、各AOB_ELEMENTの占有領域が、それぞれ異なるサイズだけ複数クラスタを占有していることである。各占有領域のサイズがそれぞれ異なるのは、各AOB_FRAMEにおける符号割り当てが可変長だからである。
各AOB_ELEMENTの占有サイズが異なるので、各AOB_ELEMENTの先頭にジャンプする場合、各AOB_ELEMENTがAOB内の何処に存在するかを予め再生装置に指示しておく必要がある。このような目的をもって、複数のTMSRT_entryは記載されている。矢印RT1,RT2,RT3・・・・・・RTn-1,RTnは、これら各AOB_ELEMENTの占有領域AR1,AR2,AR3・・・・・・ARn-1,ARnと、TMSRT_entry#1、TMSRT_entry#2、TMSRT_entry#3・・・・・・TMSRT_entry#n-1,TMSRT_entry#nとの対応関係を示す。即ち、AOB_ELEMENT#1の占有領域AR1がどれだけのサイズを占有しているかがTMSRT_entry#1に記載され、AOB_ELEMENT#2、AOB_ELEMENT#3の占有領域AR2,AR3がどれだけのサイズを占有しているかがTMSRT_entry#2、TMSRT_entry#3に記載される。
【００６７】
ここで、占有領域AR1は、AOBの先頭から、AOB_ELEMENT#2の先頭『32000』迄を占有しているので、TMSRT_entry#1は32000(=32000-0)と記述され、占有領域AR2は、AOB_ELEMENT#1の先頭『32000』から、AOB_ELEMENT#2の先頭『64200』迄を占有しているので、TMSRT_entry#2は『32200(=64200-32000)』と記述、占有領域AR3は、AOB_ELEMENT#3の先頭『64200』から、AOB_ELEMENT#4の先頭『97000』迄を占有しているので、TMSRT_entry#3は『32800(=97000-64200)』、占有領域ARn-1は、AOB_ELEMENT#n-1の先頭『1203400』から、AOB_ELEMENT#nの先頭『1240000』迄を占有しているので、TMSRT_entry#n-1は『36600(=1240000-1203400)』と記述されている。
【００６８】
{17-3_21-2} TKTMSRTの読み出し方式
このようにタイムサーチテーブルには、AOB_ELEMENTのデータサイズが記載されていることがわかる。一方、AOB_ELEMENTの説明で述べたように、各AOB_BLOCKのデータ長は、再生時間が8.4分内になるように定めらているので、1つのAOBに含まれるAOB_ELEMENTの総数は、所定数(図２０に示す252個)以下に抑えられている。AOB_ELEMENT数が所定数以下に抑えられるので、AOB_ELEMENTに対応するTMSRT_entryの総数も所定数以下となり、これらを含むTKTMSRTのデータサイズも所定サイズ以下となる。TKTMSRTのサイズを抑制したため、再生装置は、以下のようにTKIを読み出して、利用することができる。
【００６９】
あるAOBが読み出されて、その再生が開始されると、それに対応するTKIを読み出して、メモリに格納する。以降、当該AOBの再生が継続している期間において、このTKIをメモリに格納しておく。当該AOBの再生が終われば、これに後続するAOBが読み出されて、その再生が開始されると、それに対応するTKIを読み出して、それまでメモリ上に格納されていたTKIを、新たに読み出されたTKIを用いて上書きする。以降、当該AOBの再生が継続している期間において、このTKIをメモリに格納しておく。
【００７０】
TKIの読み出しと、メモリへの格納とをこのように行えば、再生装置におけるメモリの実装量が小規模であっても、必要なTKIを読み出すだけで順方向サーチ再生、逆方向サーチ再生といった特殊再生を行うことができる。尚、本実施形態では、あるAOB_ELEMENTの先頭アドレスから次のAOB_ELEMENTの先頭アドレスまでのデータ長をTMSRT_entryとして記載したが、AOB_BLOCKの先頭から、各AOB_ELEMENTの先頭までの相対アドレスを記載してもよい。
【００７１】
{17-3_21-3} AOB_ELEMENTを含むクラスタの特定
最後にTKTMSRTを参照して、任意のAOB_ELEMENTをどうやって読み出せばよいかについて説明する。各AOB_ELEMENTのサイズが記載されたTKTMSRTを参照して、AOBにおいて先頭からy番目に位置するAOB_ELEMENT#yを読み出す場合、以下の｛数式１｝を満たすクラスタuを求めて、そのクラスタuの先頭からオフセットv以降を読み出せばよい。
｛数式１｝
クラスタu = (AOB_ELEMENT#1からAOB_ELEMENT#y-1までのTMSRT_entryの総和+DATA_Offset)／クラスタサイズ
オフセットv =(AOB_ELEMENT#1からAOB_ELEMENT#y-1までのTMSRT_entryの総和+DATA_Offset) mod クラスタサイズ
c =a mod bとある場合、cは、aをbで割った場合の余りを示し、DATA_Offsetは、BITに記載されている情報であり、後述する。
【００７２】
{17-4} TKTXTI_DAについて
以上で、タイムサーチマップ(TKTMSRT)の説明を終わる。次に、図１７においてTKTMSRTの上段に記載されているTrack Text Information Data Area(TKTXTI_DA)について説明する。
Track Text Information Data Area(TKTXTI_DA)には、アーティスト名、アルバム名、編曲者名、プロデューサ名等を示すテキスト情報が記述される。テキストデータが存在しない場合でも、この領域は確保される。
【００７３】
{17-5} TKGIについて
続いてTKTXTI_DAの上段にあるTKGIについて説明する。図１７においてTKIのTKGIは、破線の引き出し線h4に示すように、TKIの識別子『TKI_ID』、TKI番号『TKIN』、TKIのサイズ『TKI_SZ』、次のTKIへのリンクポインタ『TKI_LNK_PTR』、ブロック属性『TKI_BLK_ATR』、再生時間『TKI_PB_TM』、TKIのオーディオ属性『TKI_AOB_ATR』、『ISRC』、ブロック情報『BIT』という一連の情報が記録されていることがわかる（尚、本図は、説明の簡略化のため、一部のフィールドについては省略して表記している。）。
【００７４】
{17-5_22-1} TKGIについて
以下、図２２を参照しながらTKGIの詳細構成について説明する。本図と、図１７との違いは、図１７に示したTKGIのデータ構成が図中左側に配置されており、図１７では明らかにされてなかった『TKI_BLK_ATR』,『TKI_AOB_ATR』,『ISRC』のビット構成が、図中の右側に配置されている点である。
【００７５】
{17-5_22-2} TKI_IDについて
『TKI_ID』には、TKIを一意に識別できるID(本実施形態では2バイトの"A4"というコード)が記述される。
{17-5_22-3} TKINについて
『TKIN』には、1から999までの範囲のTKI番号が記述される。なお、このTKI番号は他のTKIのTKINに記述されるTKI番号と重複してはならない。このようなTKINとして、TrackManagerにおけるTKIの順位、即ち、TrackManagerにおいてTKIが何番目に位置するかを記述するものとする。本図におけるTKI#1なら、TKI番号は、"1"と記載され、TKI#2ならTKI番号は、"2"と、TKI#3ならTKI番号は、"3"と記載される。
【００７６】
{17-5_22-4} TKI_SZについて
『TKI_SZ』には、TKIのデータサイズがバイト数単位で記述される。図２２では、TKIのデータサイズが1024バイトと規定されているので、本実施形態において1024バイトと記述される。
{17-5_22-5} TKI_LNK_PTRについて
『TKI_LNK_PTR』には、当該TKIのリンク先のTKIについてのTKINが記述される。ここで、TKI間の対応関係について説明する。
【００７７】
トラックが複数のAOBから構成され、それらが複数のAOBファイルに収録されている場合、それら複数のAOBファイルに対応づけられている複数のTKIは一体となって、当該トラックを管理することになる。このように複数のTKIが一体となっている場合、これらTKIに対応するAOBファイルに、どのTKIに対応するAOBファイルが後続するかを示す必要がある。TKI_LNK_PTRは、各TKIに後続するTKIについてのTKINを記述するという用途に用いられる。
【００７８】
{17-5_22-6_19} TKI_LNK_PTRについて
以降、図１９に示した8つのTKIにおいて、TKI_LNK_PTRがどのように設定されているかについて説明する。１トラックを構成するTKI#1〜TKI#3、TKI#8において、そのTKI_LNK_PTRは設定されないが、TrackDを構成する4つのAOBファイルに対応するTKI#4、TKI#5、TKI#6、TKI#7は、各TKI_LNK_PTRが次のTKI_LNK_PTRを指示するよう設定されている。即ち、矢印TL4,TL5,TL6に示すように、TKI#4のTKI_LNK_PTRはTKI#5を指示しており、TKI#5のTKI_LNK_PTRはTKI#6を、TKI#6のTKI_LNK_PTRはTKI#7を指示している。これらは、何れもTrackDを構成する。4つのAOBファイルに対応づけられているTKIにおけるこれらTKI_LNK_PTRを参照することにより、TKI#4〜TKI#7という4つのTKI、及びAOB004.SA1〜AOB007.SA1という4つのAOBファイルが、一体となってTrackDを構成しているということがわかる。
【００７９】
{17-5_22-7} TKI_BLK_ATRについて
『TKI_BLK_ATR』には、TKIについての属性が記述される。図２２においてTKI_BLK_ATRから破線にて引き出された枠に、TKI_BLK_ATRのビット構成を示す。本図においてTKI_BLK_ATRは16ビットであり、b3ビットからb15ビットまでが将来の拡張のために確保されている。ビット番号b2からb0までの3ビットを用いて、TKIについての属性が記述される。
【００８０】
TKIが使用されており、１個のTKIが１個のトラックに含まれる場合、TKI_BLK_ATRには"000b"の値が記述される(以降、この設定を『Track』という。)。TKIが使用されており、１トラックが複数のTKIを含み、当該TKIがその先頭である場合は、TKI_BLK_ATRには"001b"の値が記述される（以降、この設定を『Head_of_Track』という。）。TKIが使用されており、１トラックが複数のTKIから構成され、当該TKIがその中間である場合は、TKI_BLK_ATRには"010b"の値が記述される（以降、この設定を『Midpoint_of_Track』という）。TKIが使用されており、１トラックが複数のTKIから構成され、当該TKIがその終端である場合、TKI_BLK_ATRには"011b"の値が記述される（以降、この設定を『End_of_Track』という。）。TKIが未使用であり、TKIの領域がある場合、すなわち削除されたTKIである場合は、"100b"の値が記述される（以降、この設定を『Unused』という）。TKIが未使用であり、TKIの領域がない場合、すなわち初期状態のTKIである場合は、"101b"の値が記述される。
【００８１】
{17-5_22-8_19} TKI_BLK_ATRの設定例
図１９の一例では、それぞれのTKIについてのTKI_BLK_ATRがどのように設定されているかについて説明する。
各TKIにおけるTKI_BLK_ATRを参照すれば、TKI#1（AOB001.SA1）、TKI#2（AOB002.SA1）、TKI#3（AOB003.SA1）、TKI#8（AOB008.SA1）という4つの組みは、それぞれが独立したトラックに対応しているので、TKI#1、TKI#2、TKI#3、TKI#8のTKI_BLK_ATRは、『Track』と設定されている。
【００８２】
TKI#4におけるTKI_BLK_ATRは『Head_of_Track』と設定され、TKI#7におけるTKI_BLK_ATRは『End_of_Track』と、TKI#5、TKI#6は『Midpoint_of_Track』と設定されていることがわかる。このことは、TKI#4と対応関係を有するTKI#4（AOB004.SA1）はトラックの先頭部と、TKI#5、TKI#6と対応関係を有するTKI#5（AOB005.SA1）及びTKI#6（AOB006.SA1）はトラックの中間部と、TKI#7と対応関係を有するTKI#7（AOB007.SA1）はトラックの終端部であることを意味する。
【００８３】
このように各TKIにおけるTKI_BLK_ATRの記載に従って、TKI（AOBファイル）の組みを分類すれば、TKI#1（AOB001.SA1）が1つ目のトラック(TrackA)を構成していることがわかる。TKI#2（AOB002.SA1）が2つ目のトラック(TrackB)、TKI#3（AOB003.SA1）が3つ目のトラック(TrackC)を構成していることがわかる。
TKI#4（AOB004.SA1）が4つ目のトラック(TrackD)の先頭部分を構成しており、TKI#5（AOB005.SA1）、TKI#6（AOB006.SA1）がTrackDの中間部分を構成しており、TKI#7（AOB007.SA1）がTrackDの終端部分を構成していることがわかる。TKI#8（AOB008.SA1）は独立して5つ目のTrackEの終端部分を構成していることがわかる。
【００８４】
{17-5_22-9} TKI_PB_TMについて
『TKI_PB_TM』には、TKIに対応するAOBファイルに収録されているAOBにより構成されるトラック(曲)の再生時間が記述される。
トラックが複数のTKIから構成される場合、先頭のTKIについてのTKI_PB_TMには、トラック全体の再生時間が記述される。また2番目以降のTKIには、それぞれのTKIに対応するAOBの再生時間が記述される。
【００８５】
{17-5_22-10} TKI_AOB_ATRについて
『TKI_AOB_ATR』には、TKIに対応するAOBファイルに収録されているAOBがどのようなサンプリング周波数でサンプリングされているか、どのようなビットレートで転送されるか、チャネル数がどれだけであるか等、AOBを生成する際のエンコード条件が記述される。『TKI_AOB_ATR』から破線にて引き出された枠は、TKI_AOB_ATRのビット構成を示す。本図においてTKI_AOB_ATRは、20ビットであり、ビット番号b16からビット番号b19までのフィールドには、コーディングモードが記述される。MPEG-2 AAC(with ADTS header)でエンコードされている場合には、"0000b"の値が、MPEG-layer3(MP3)でエンコードされている場合には、"0001b"の値が、Windows（登録商標） Media Audio(WMA)でエンコードされている場合、"0010b"がそれぞれ記述される。
【００８６】
ビット番号b15からビット番号b8までのフィールドには、ビットレートが記述される。MPEG-2 AAC(with ADTS header)でエンコードされている場合には、"16"〜"72"の値が、MPEG1-layer3(MP3)でエンコードされている場合には"16"〜"96"の値が、MPEG2-layer3(MP3) LSFでエンコードされている場合には"16"〜"80"の値が、Windows（登録商標） Media Audio(WMA)でエンコードされている場合、"8"〜"16"の値がそれぞれ記述される。
【００８７】
ビット番号b7からビット番号b4には、サンプリング周波数が記述される。48kHzの場合は"0000b"、44.1kHzの場合は"0001b"、32kHzの場合は"0010b"、24kHzの場合は"0011b"、22.05kHzの場合は"0100b"、16kHzの場合は"0101b"の値が記述される。
ビット番号b3からビット番号b1までのフィールドには、チャネル数が記述される。1ch(mono)の場合は、"000b"が記述される。2ch(stereo)の場合は、"001b"が記述される。
【００８８】
ビット番号b31からビット番号b20、およびビット番号b0の領域は、将来の拡張用に予約されている。
{17-5_22-11} ISRCについて
『ISRC』には、TKGIにおけるISRC（International Standard Recording Code）が記述される。図２２における『ISRC』から破線にて引き出された枠はISRCの内容を示す。この枠に示されているように、ISRCは、10バイトからなり、ビット番号b4からビット番号b7までのフィールドにRecording-item code(#12)が記述され、ビット番号b8からビット番号b11までのフィールドにRecording code/Recording-item code(#11)が記述される。
【００８９】
ビット番号b12からビット番号b23までのフィールドにRecording code(ISRC#10,#9,#8)が記述される。ビット番号b24からビット番号b31までのフィールドにYear-of-Recording code(ISRC#6,#7)が記述される。
以降、ビット番号b32からビット番号b37までのフィールド、ビット番号b40からビット番号b45までのフィールド、ビット番号b48からビット番号b53までのフィールドには、First Owner Code(ISRC#3,#4,#5)が記述される。ビット番号b56からビット番号b61までのフィールド、ビット番号b64からビット番号b69までのフィールドには、Country code(ISRC#1,#2,#3)が記述される。ビット番号b79のフィールドには、1ビットのValidity flagが記述される。尚、ISRCの詳細については、ISO3901 : 1986 ''Documentation-International Standard Recording Code (ISRC) ''を参照されたい。
【００９０】
{17-5_22-12_23A-1} BITについて
『ブロック情報テーブル(BIT)』は、AOB_BLOCKを管理するテーブルである。図２３（ａ）、（ｂ）は、BITの詳細構成を示す図である。図２３（ａ）に示すように、BITは、60バイト目から63バイト目までを占めるDATA_OFFSETフィールドと、64バイト目から67バイト目までを占めるSZ_DATAフィールドと、68バイト目から71バイト目までを占めるTMSRTE_Nsフィールドと、72バイト目から73バイト目までを占めるFNs_1st_TMSRTEフィールドと、74バイト目から75バイト目までを占めるFNs_Last_TMSRTEフィールドと、76バイト目から77バイト目までを占めるFNs_Middle_TMSRTEフィールドと、78バイト目から79バイト目までを占めるTIME_LENGTHフィールドとからなる。以下、各構成要素の説明を行う。
【００９１】
{17-5_22-12_23A-2} DATA_Offsetについて
『DATA_OFFSET』には、クラスタ境界から各AOB_BLOCKの先頭までの相対アドレスがバイト単位で記述される。これにより、AOBからAOB_BLOCKまでの間に無効領域がどれだけ存在するかが表現される。AOBとしてフラッシュメモリカード３１に格納されている音楽が、エアチェックして録音された音楽であり、その音楽のイントロの部分にディスクジョッキーの音声が混じっている場合、BITにおけるDATA_Offsetを設定することにより、この不要音声をAOB_BLOCKから除外して再生させないようにすることができる。
【００９２】
{17-5_22-12_23A-3} SZ_DATAについて
『SZ_DATA』には、各AOB_BLOCKのデータ長がバイト単位で記述される。SZ_DATAとDATA_Offsetとを加算した値をAOBを収録しているファイルサイズ(クラスタサイズの整数倍)から差し引けば、AOB_BLOCKに後続する無効領域がどれだけのサイズであるかを求めることができる。
【００９３】
{17-5_22-12_23A-4} TMSRTE_Nsについて
『TMSRTE_Ns』には、各AOB_BLOCKに含まれるTMSRT_entryの総数が記述される。
{17-5_22-12_23A-5} 『FNs_1st_TMSRTE』、『FNs_Last_TMSRTE』、『FNs_Middle_TMSRTE』について
『FNs_1st_TMSRTE』には、当該AOB_BLOCK中の先頭に位置するAOB_ELEMENTに含まれるAOB_FRAME数が記述される。
【００９４】
『FNs_Last_TMSRTE』には、AOB_BLOCKの最後尾のAOB_ELEMENTに含まれるAOB_FRAMEの個数が記述される。
『FNs_Middle_TMSRTE』には、先頭と最後尾のAOB_ELEMENTを除くAOB_ELEMENT、即ち、AOB_BLOCKの中間部に位置するAOB_ELEMENTに含まれるAOB_FRAMEの個数が記述される。
【００９５】
『TIME_LENGTH』は、図２３（ｃ）に示すフォーマットにてAOB_ELEMENTの再生期間をミリ秒オーダーの時間精度で記述するフィールドである。図２３（ｃ）に示すように、TIME_LENGTHフィールドは、16ビット長であり、符号化方式がMPEG-AAC方式やMPEG-Layer3方式であれば、AOB_ELEMENTの再生期間は2秒となるので、TIME_LENGTHには、2000の値が記述される。
【００９６】
{17-5_22-13_23B}
図２３（ｂ）は、FNs_Middle_TMSRTEにAOB_FRAMEが幾つ格納されているかを示す図である。本図は図１４同様、sampling_frequencyと、中間部のAOB_ELEMENTに含まれるAOB_FRAME数との対応関係を示している。本図におけるsampling_frequencyと、AOB_ELEMENTに含まれるフレーム個数との対応関係は図１４と全く同一であり、サンプリング周波数に応じて異なる個数になっていることがわかる。『FNs_1st_TMSRTE』及び『FNs_Last_TMSRTE』におけるフレーム数は、『FNs_Middle_TMSRTE』におけるフレーム数と原則同一のフレーム数に設定されるが、AOB_BLOCKの先頭又は末尾に位置するAOB_ELEMENTに無効領域を設定する場合、『FNs_1st_TMSRTE』及び『FNs_Last_TMSRTE』は、『FNs_Middle_TMSRTE』と異なる値となる。
【００９７】
{17-5_22-14_24} AOB_ELEMENTの格納例
図２４は、AOB_ELEMENT#1〜#4からなるAOBが格納されているクラスタ007〜クラスタ00Eを示す図である。AOBが図２４に示すように格納されている場合に、BITがどのように設定されるかについて説明する。これらクラスタ007〜クラスタ00Eに格納されているAOB_ELEMENT#1〜AOB_ELEMENT#4のそれぞれには、三角旗状の記号が付与されているが、これらは、AOB_ELEMENT#1〜AOB_ELEMENT#4のそれぞれに、TKIに含まれるTMSRT_entryが設定されていることを示す。
【００９８】
この際、AOB先端におけるAOB_ELEMENT#1の先端部分は、クラスタ007に格納されており、AOB末尾におけるAOB_ELEMENT#4の終端部分は、クラスタ00Eに格納されている。AOB_ELEMENT#1〜#4は、クラスタ007の途中md0からクラスタ00Eの途中md4迄を占有している。BIT内のSZ_DATAは、矢印sd1に示すようにAOB_ELEMENT#1からAOB_ELEMENT#4の最後までを指示しており、クラスタ007,00E内の領域であって、AOB_ELEMENTにより占有されていない部分ud0,ud1を指示していない。
【００９９】
これに対して、AOBは、クラスタ007、クラスタ00E内の領域であって、AOB_ELEMENT#1、AOB_ELEMENT#4により占有されていない部分ud0,ud1までも含んでいる。BIT内のDATA_Offsetは、非占有部分ud0のデータ長、即ち、クラスタ007の先頭から、AOB_ELEMENT#1の先頭までの相対値を指示している。
本図においてAOB_ELEMENT#1は、クラスタ007の途中md0からクラスタ008の途中md1までを占有している。このAOB_ELEMENT#1は、クラスタ008全体を占有しているのではなく、その終端部分以降は、AOB_ELEMENT#2に占有されている。AOB_ELEMENT#4は、クラスタ00Cの途中部分md3から、クラスタ00Eの途中部分md4までを占有している。このようにAOB_ELEMENTには、クラスタの境界を跨ぐように、記録されているものが存在することがわかる。つまり、AOB_ELEMENTは、クラスタの境界とは全く関係無く、記録されているのである。BIT内の『FNs_1st_TMSRTE』は、クラスタ007〜クラスタ008におけるAOB_ELEMENT#1のフレーム数を示しており、BIT内の『FNs_Last_TMSRTE』は、クラスタ00C〜クラスタ00EにおけるAOB_ELEMENT#4のフレーム数を示している。
【０１００】
このように、各AOB_ELEMENTは、クラスタの境界に関係なく、自由に配置されており、BITにより、クラスタ境界からAOB_ELEMENTまでのオフセットや各AOB_ELEMENT毎のフレーム数が管理されていることがわかる。
{17-5_22-14_25} 各AOB_ELEMENT毎のフレーム数の利用法１
BITに記載されている各AOB_ELEMENT毎のフレーム数がどのように利用されるかを以下に説明する。BITに記載されているフレーム数は、先ず第１に、再生経過時刻を2秒スキップして、240ミリ秒だけ再生するという順方向サーチ再生、逆方向サーチ再生を行う場合に用いられる。
【０１０１】
図２５は、AOB内の任意のAOB_ELEMENT#yにおけるAOB_FRAME#xから順方向サーチ再生を行う場合、次に再生すべきAOB_FRAME#x+1をどのように設定するかを示す図である。
本図は、AOB_ELEMENT#yに含まれるAOB_FRAME#xが再生されている時点において、順方向サーチ再生が指示された場合を想定して作図した図である。本図において、tは、所定の間欠再生時間(=240ミリ秒)、f(t)は、間欠再生時間に相当するフレーム数、間欠スキップ時間skip_timeは、間欠再生を行う際にスキップすべき時間長（この場合は2秒)、この間欠スキップ時間skip_timeに対応するフレーム数をf(skip_time)とする。ここで間欠再生は、以下の▲１▼▲２▼▲３▼の手順を繰り返すことにより行われる。
【０１０２】
▲１▼TKTMSRTに記載されているTMSRT_entryを参照して、旗(AOB_ELEMENT)の先頭へとジャンプする。
▲２▼240ミリ秒だけ再生を行う
▲３▼次の旗(AOB_ELEMENT)の先頭へとジャンプする。
尚、本実施形態では、240ミリ秒再生し、2秒後の箇所にジャンプし、240ミリ秒再生するという、より正確な間欠再生を実現する方法について説明する。
【０１０３】
AOB_ELEMENT#yに含まれるAOB_FRAME#xから、2秒+240ミリ秒後のAOB_FRAME#x+1は、AOB_ELEMENT#y+1内に存在する筈である。2秒+240ミリ秒後のAOB_FRAME#x+1を特定する場合、次のAOB_ELEMENT#y+1についての先頭アドレスは、TKTMSRTにおけるTMSRT_entryを読み出すことにより即座に算出することができるが、そのAOB_ELEMENT#y+1の先頭アドレスからAOB_FRAME#x+1までに介在するAOB_FRAME数は、TMSRT_entryのみでは知り得ない。そのようなAOB_FRAME数を算出するためには、AOB_FRAME#xがAOB_ELEMENT#yの先頭から何番目に位置するかを示す#xと、f(t)と、f(skip_time)との和から、AOB_ELEMENT#yに含まれる全フレーム数を差し引くことにより求める必要がある。そのように、次のAOB_ELEMENT#y+1におけるAOB_FRAME#x+1の相対フレーム位置を簡易に算出するため、BITに各AOB_ELEMENTについての『FNs_1st_TMSRTE』、『FNs_Middle_TMSRTE』、『FNs_Last_TMSRTE』を記載しているのである。
【０１０４】
{17-5_22-15_26A} 各AOB_ELEMENT毎のフレーム数の利用法２
BITに記載されているフレーム数は、第２に、任意の再生時刻から再生を開始するという機能（タイムサーチ機能）を実行する際に利用される。図２６（ａ）は、任意の再生開始時刻が指定された場合、その指定時刻に対応するAOB_ELEMENT、AOB_FRAMEをどのように特定するかを示す図である。
【０１０５】
任意の時刻が指定されて再生が指示された場合、再生指定時刻をJmp_Entry(秒)とすると、以下の式を満たすAOB_ELEMENT#yと、AOB_FRAME位置xとから、再生を開始すればよい。
｛数式２｝
Jmp_Entry(秒)＝(FNs_1st_TMSRTE＋FNs_middle_TMSRTE×y＋x)×20msec
これら『FNs_1st_TMSRTE』及び『FNs_Middle_TMSRTE』はBITに記載されているので、これらを｛数式２｝に適用することによりAOB_ELEMENT#y、AOB_FRAME#xが算出されれば、このAOBに対応するTKTMSRTを参照して、AOBにおいてy+2番目に位置するAOB_ELEMENT#y+2の先頭アドレスを求めて、この先頭アドレスから、AOB_FRAME#xの探索を始め、x番目のAOB_FRAMEが探索されれば、このx番目のAOB_FRAMEから再生を開始する。これにより、Jmp_Entry(秒)にて指定された時刻から、再生を開始することができる。
【０１０６】
この際、AOBファイルのADTSヘッダ部分を検索せず、TKTMSRTにTMSRT_entryが記述されているAOB_ELEMENT単位で検索を行えばよいので、再生指定時刻に対応する再生位置を高速に探し出すことができる。
同様に、複数のAOBからなるトラックに対して、タイムサーチ機能が実行され、Jmp_Entry(秒)が指定された場合、以下の｛数式３｝を満たすAOB_ELEMENT#yと、AOB_FRAME#xとを算出すればよい。
｛数式３｝
Jmp_Entry(秒) = AOB#1からAOB#nまでの再生時間の総和
+（FNs_1st_TMSRTE(#n+1)+FNs_middle_TMSRTE(#n+1)・y+x）・20msec
ここでAOB#1からAOB#nまでのAOBの再生時間の総和は、以下の通りである。
AOB#1からAOB#nまでの再生時間の総和＝
(『FNs_1st_TMSRTE』(#1)+『FNs_Middle_TMSRTE』(#1)・(TMSRT_entry数#1-2)+『FNs_Last_TMSRTE』(#1)
+ 『FNs_1st_TMSRTE』(#2)+『FNs_Middle_TMSRTE』(#2)・TMSRT_entry数#2-2)+『FNs_Last_TMSRTE』(#2)
+ 『FNs_1st_TMSRTE』(#3)+『FNs_Middle_TMSRTE』(#3)・TMSRT_entry数#3-2)+『FNs_Last_TMSRTE』(#3)
・・・・・・・・・
+ 『FNs_1st_TMSRTE』(#n)+『FNs_Middle_TMSRTE』(#n)・TMSRT_entry数#n-2)+『FNs_Last_TMSRTE』(#n))・20msec
｛数式３｝を満たすAOB#n、AOB_ELEMENT#y、AOB_FRAME#xが算出されれば、このAOB#n+1に対応するTKTMSRTを参照して、y+2番目のAOB_ELEMENT#y+2に位置するアドレスから、AOB_FRAME#xの探索を始め、x番目のAOB_FRAMEが探索されれば、このx番目のAOB_FRAMEから再生を開始する。
【０１０７】
{17-5_22-16_27A,B} AOBファイル及びTKIの削除
TKIに含まれる情報を全て説明したところで、一部のトラックが削除された場合(case1)、一部のトラックが削除された後、新たなトラックを記録する場合(case2)、複数のトラックのうち、任意の2つを1つのトラックに統合する場合(case3)、1つのトラックを分割して、2つのトラックを得る場合(case4)において、TKIがどのように更新されるかについて説明する。
【０１０８】
先ず初めに、一部のトラックが削除された場合(case1)について説明する。
図２７（ａ）、（ｂ）は、トラックを削除する場合を想定した図である。本図は、図１９に示したTrackManagerを示すものであり、本図においてTrackBを削除することを操作者が希望しているものとする。このTrackBに対応するAOBは、AOB002.SA1に収録されており、それがTKI#2に対応づけられているので、AOB002.SA1が削除されると共に、TKI#2のTKI_BLK_ATRが『Unused』に設定される。AOB002.SA1が削除され、TKI#2のTKI_BLK_ATRが『Unused』に設定された状態を図２７（ｂ）に示す。AOB002.SA1が削除されたので、データ領域においてAOB002.SA1が占有していた領域は空き領域に解放される。それと共に、TrackManagerにおいては、TKI#2のTKI_BLK_ATRが『Unused』に設定されていることがわかる。
【０１０９】
{17-5_22-17_28A,B} 新たにAOBファイルを記録する場合のTKIの割り当て
続いて一部のトラックが削除された後、新たなトラックを記録する場合(case2)について説明する。
図２８（ａ）は、トラックの削除が複数回行われた後のTrackManagerを示す図である。本図において、複数のトラックが削除され、これらがTKI#2、TKI#4、TKI#5、TKI#7、TKI#8に対応づけられているとすれば、これらのTKIのTKI_BLK_ATRが『Unused』に設定される。AOBファイルの削除は、通常のファイルと同様に行われるが、TrackManagerは、該当するTKIのTKI_BLK_ATRが『Unused』に設定されるのみで削除処理は完了する。そうすると、本図に示すように『Unused』のTKIが虫食い状にTrackManager上に現れることになる。
【０１１０】
図２８（ｂ）は、『Unused』のTKIが存在しており、ここに新たなTKI、AOBファイルを書き込む場合、その書き込みがどのように行われるかを示す図である。
ここで4つのAOBからなるトラックを書き込もうとする場合を想定する。ここでAOBの記録にどの空きTKIを割り当てるかは、後述するDPL_TK_SRPにより決定されるか、又は、任意のTKIが割り当てられる。その4つのAOBには、TrackManagerにおいて、『Unused』に設定されているTKI#2、TKI#4、TKI#7、TKI#8が割り当てられる。
【０１１１】
これら4つのAOBは1つのトラックを構成するものなので、TKI#2についてのTKI_BLK_ATRを『Head_of_Track』と、TKI#4、TKI#7についてのTKI_BLK_ATRを『Midpoint_of_Track』と、TKI#8についてのTKI_BLK_ATRは、『End_of_Track』と設定される。トラックTrackDを構成する4つのTKI#2、TKI#4、TKI#7、TKI#8は、各TKI_LNK_PTRが、トラックTrackDを構成する次のTKI_LNK_PTRを指示するよう設定されている。即ち、矢印TL2,TL4,TL7に示すように、TKI#2のTKI_LNK_PTRはTKI#4を指示しており、TKI#4のTKI_LNK_PTRはTKI#7を、TKI#7のTKI_LNK_PTRはTKI#8を指示している。
【０１１２】
その後、TKI#2、TKI#4、TKI#7、TKI#8のそれぞれと同じ番号を有する4つのファイルAOB002.SA1、AOB004.SA1、AOB007.SA1、AOB008.SA1が作成されて、これら4つのファイルにTrackDを構成する4つのAOBが収録される。
かかるTKI_BLK_ATR、TKI_LNK_PTRの設定により、4つ目のトラックTrackDは、TKI#2、TKI#4、TKI#7、TKI#8を用いて管理されることなる。
【０１１３】
以上のように、フラッシュメモリカード３１に新たにトラックを書き込む場合、それまでTrackManagerに『Unused』に設定されているTKIを、その新規に記録すべきトラックについてのTKIに割り当てていることがわかる。
{17-5_22-18_29A,B} 2つのトラックを統合する場合のTKI設定
続いてトラックの統合(case3)を行う際の、TKIの更新について説明する。
【０１１４】
図２９（ａ）、（ｂ）は、2つのトラックを1つに統合する場合にTKIがどのように設定されるかを示す図である。図２９（ａ）は、図１９に示したTrackManagerと同一であり、図２９（ａ）において、TrackCとTrackEとを1つのトラックに統合するという編集操作を操作者が希望しているものとする。これらTrackC、TrackEに対応するAOBがAOB003.SA1、AOB008.SA1に収録されており、それらがTKI#3、TKI#8に対応づけられているので、これらTKI#3及びTKI#8のTKI_BLK_ATRの書き換えが行われる。図２９（ｂ）は、TKIのTKI_BLK_ATRの書き換え後を示す図である。本図においてTKI#3、TKI#8のTKI_BLK_ATRはTrackと記載されているが、図２９（ｂ）では、TKI#3のTKI_BLK_ATRは『Head_of_Track』に書き換えられ、TKI#8のTKI_BLK_ATRは『End_of_Track』に書き換えられている。このように、TKI_BLK_ATRが書き換えられることにより、TKI#3、TKI#8、これらに対応するAOB003.SA1、AOB008.SA1は、TrackCという1つのトラックとして扱われる。これに加えて、TKI#3のTKI_LNK_PTRがリンク先としてTKI#8を指示するように書き換えられる。
【０１１５】
ここで留意すべきは、TKIのTKI_BLK_ATRは書き換えられたが、AOB003.SA1とAOB008.SA1とを統合するという処理は行われなかった点である。何故なら、これらのAOBファイルは、互いに異なるFileKeyにて暗号化されているので、これらを1つに統合するとなると、暗号化されたAOBファイルを復号して再度暗号化するという復号化−暗号化という2つの処理が各AOBファイルについて行う必要があり、多大な処理負荷が要求されるからである。また、統合後のAOBファイルは、1つのFileKeyにて暗号化されるので、統合前と比較して、著作権保護の弱体化を招くからである。
【０１１６】
加えてTKIは、元々TKTMSRTのサイズが大きくならないように定められているのに、編集操作においてこれを1つに統合するとなると、統合後のTKIのサイズが、大きくなり過ぎる恐れがあるからである。
以上のように、本実施形態におけるトラックの統合化編集は、AOBファイルの暗号化を維持したまま、TKI_BLK_ATRの属性変更のみで実現されることがわかる。
【０１１７】
{17-5_22-18_29A,B-1_30,31} トラックを統合する場合に満たすべき条件
トラックの統合は、TKI_BLK_ATRの属性変更にて実現されることは上述した通りであるが、トラックの統合にあたっては、統合されるトラックに含まれるAOBが以下の条件を満たしていることが要求される。
1つ目の条件とは、後続するトラックに含まれるAOBと、先行するトラックに含まれるAOBとのオーディオ属性（オーディオコーディングモード、ビットレート、サンプリング周波数、チャネル数）が一致していることである。これは、AOBのオーディオ属性が前後のAOBで異なると、再生装置は、デコーダの動作を一旦リセットする必要があり、連続する2つのAOBをシームレスに（途切れることなく）再生することが困難になるという理由による。
【０１１８】
2つ目の条件とは、統合後により得られるトラックにおいて、AOB_FRAME数が『FNs_Middle_TMSRTE』に満たないAOB_ELEMENTのみからなるAOBが3つ以上連続しないことである。
AOB_ELEMENTのうち少なくとも1つが、『FNs_Middle_TMSRTE』にて指示されたフレーム数と同数のAOB_FRAMEを有しているか否かにより、AOBは2つのタイプに分類される。1つ目のタイプのAOBは、『FNs_Middle_TMSRTE』にて指示されたフレーム数と同数のAOB_FRAMEを有するAOB_ELEMENTを少なくとも1つ有しているAOBであり、2つ目のタイプのAOBは、『FNs_Middle_TMSRTE』にて指示されたフレーム数と同数のAOB_FRAMEを有しているAOB_ELEMENTを一切有していないAOBである。即ち、2つ目のタイプのAOBにおけるAOB_ELEMENTは、何れも『FNs_Middle_TMSRTE』にて指示されたフレーム数を下回っており、上述した2つ目の条件は、Type2のAOBが3つ以上連続することを禁じているのである。その禁止理由は以下の通りである。即ちAOBを順次読み出してゆく際、再生装置内のバッファは、充分な数のAOB_FRAMEにて満たされていることが望ましいが、Type2のAOBが連続していると、再生装置内のバッファを、AOB_FRAMEで満たすことができなくなる。そうすると、再生装置内のバッファがアンダーフローを起こし、AOBの再生の連続性が保てなくなる。そうしたアンダフローの発生を避けるため、Type2のAOBが3つ以上連続することを2つ目の条件は禁じているのである。
【０１１９】
図３０（ａ）は、Type1のAOBを示し、図３０（ｂ）は、Type2のAOBを示す図である。図３０（ｂ）におけるAOBは2つ以下のAOB_ELEMENTのみからなり、それら2つ以下のAOB_ELEMENTは、『FNs_Middle_TMSRTE』に示されるAOB_FRAMEを有していない（尚、この場合BITには、FNs_1st_TMSRTEのみが記述される。）。
『FNs_Middle_TMSRTE』に示されるAOB_FRAMEを有していないことがType2AOBの要件なので、たった1つのAOB_FRAMEにより構成されるAOBであっても、このType2のAOBに分類されることなる。
【０１２０】
図３１（ａ）は、Type1＋Type2＋Type2＋Type1の組み合わせで、複数トラックを1つに統合する場合を示す図である。この場合、Type2のAOBが3つ連続することは避けられているので、これらは1つのトラックに統合される。
図３１（ｂ）は、Type1＋Type2＋Type2＋Type2＋Type1の組み合わせで、複数トラックを1つに統合する場合を示す図である。この場合、Type2のAOBが3つ連続しているので、これらを1つのトラックに統合することは禁じられる。
【０１２１】
{17-5_22-18_29A,B-1_32} Type1、Type2の組合せを考慮したトラック統合 図３１（ａ）に示したトラックの統合によれば、先行するトラックの終端がType1である場合、このトラックは、先頭にType2のAOBを配したトラック、又は、先頭にType1のAOBを配したトラックと統合することができる。図３２（ａ）は、先行するトラックの終端にType1のAOBが配され、後続するトラックの先頭にType1のAOBが配されている配置パターンを示す図である。また図３２（ｂ）は、先行するトラックの終端にType1のAOBが配され、後続するトラックの先頭にType2のAOBが配されている配置パターンを示す図である。これらは何れも、条件2を満たすので、1つのトラックに統合することができる。
【０１２２】
先行するトラックの終端がType2であり、そのType2の直前にType1のAOBが配置されている場合、このトラックは、先頭がType1のトラック、又は、先頭にType2のAOBが配され、その直後にType1のAOBが配置されたトラックと統合することができる。
図３２（ｃ）は、先行するトラックの終端にType1、Type2順でAOBが配され、後続するトラックの先頭にType1のAOBが配されている配置パターンを示す図である。図３２（ｄ）は、先行するトラックの終端にType1、Type2順でAOBが配され、後続するトラックの先頭に、Type2、Type1のAOBが配されている配置パターンを示す図である。これらも、条件2を満たすので、1つのトラックに統合することができる。
【０１２３】
先行するトラックの終端がType2であり、そのType2の直前にType2のAOBが配置されている場合、このトラックは、先頭にType1のAOBが配されたトラックと統合することができる。図３２（ｅ）は、先行するトラックの終端にType2、Type2のAOBが配され、後続するトラックの先頭にType1のAOBが配されている配置パターンを示す図である。これも、条件2を満たすので、1つのトラックに統合することができる。以上のように、トラックの統合にあたっては、統合されるべき2つのトラックが上述した2つの条件を満たすかを前もって判定し、これらの2つの条件を満たすと判定された場合のみ、2つのトラックを1つに統合する。
【０１２４】
続いてトラックの分割(case4)を行う際の、TKIの更新について説明する。
{17-5_22-19_33A,B} トラックを分割する場合のTKI設定
図３３（ａ）、（ｂ）は、1つのトラックを2つのトラックに分割する場合を想定した図である。本図におけるTrackManagerは、図２７に示すTrackManagerと同一であり、本図において、TrackCをTrackC−TrackFという2つのトラックに分割するという編集を操作者が希望しているものとする。TrackCをTrackC−TrackFに分割しようとすると、TrackFに対応するAOB002.SA1が生成される。図３３（ａ）では、TKI#2が『Unused』に設定されており、分割の結果、図３３（ｂ）に示すように『Unused』に設定されているTKI#2は、新たに生成されたAOB002.SA1に割り当てられる。
【０１２５】
{17-5_22-19_33A,B-1_34A,B}
ディレクトリエントリー及びFAT値の更新
ここでAOB003.SA1を分割して、AOB002.SA1を生成する際、ディレクトリエントリー及びFAT値を更新せねばならない。これらディレクトリエントリー及びFAT値をどのように更新するかを以下に説明する。図３４（ａ）は、分割前において、AOB003.SA1が属するSD_AudioディレクトリについてのSD_Audioディレクトリエントリーがどのように記述されているかを示す図である。AOB003.SA1は、複数に分割されて、クラスタ007,008,009,00A・・・・00D,00Eに格納されているものとする。この場合、ディレクトリエントリーにおけるAOB003.SA1について『ファイル最初のクラスタ番号』は、『007』と記述され、クラスタ007,008,009,00A・・・・00Dに対応するFAT値007,008,009,00A・・・・00Dは、それぞれ(008),(009),(00A)・・・・(00D),(00E)と記述されている。
【０１２６】
この状態でAOB003.SA1の後半部を分割してAOB002.SA1を得る場合、SD_Audioディレクトリエントリーには、AOB002.SA1についての『ファイル名』、『ファイル拡張子』、『ファイル最初のクラスタ番号』が追加される。図３４（ｂ）は、分割後において、AOB003.SA1が属するSD_AudioディレクトリについてのSD_Audioディレクトリエントリーがどのように記述されているかを示す図である。
【０１２７】
本図におけるクラスタ00Fは、操作者により指定された分割境界を含むクラスタ00Bの内容のコピーを格納したものである。クラスタ00Bに格納されているAOB002.SA1の分割部分に後続する分割部分は、クラスタ00C,00D,00E以降に格納されている。AOB002.SA1の先頭部分はクラスタ00Fに格納され、残りの部分は、クラスタ00C,00D,00E以降に格納されているので、AOB002.SA1についての『ファイル最初のクラスタ番号』には、クラスタ00Fを示すクラスタ番号00Fが記述され、クラスタ00F,00C,00D,00Eに対応づけられているFAT値00F,00C,00D,00Eには、(00C),(00D),(00E)が記述される。
【０１２８】
{17-5_22-19_33A,B-2_35A,B} TKI内の情報要素の設定
以上のディレクトリエントリー及びFAT値の更新によりAOB002.SA1を得た後、AOB002.SA1についてのTKI内の情報要素をどのように設定するかについて説明する。分割されたトラックについてのTKIを生成する場合、TKIの情報要素には、元のTKIに記載されているものをコピーして継承すればよいもの(1)、元のTKIに基づいて更新せねばならないもの(2)の二種類が存在する。前者に該当するのは、TKTXTI_DA,ISRCであり、後者に該当するのは、BIT、TKTMSRTを初めとする残りの構成要素である。これら両者が存在するので、本実施形態では、分割されたトラックについてのTKIを生成する際、分割元のTKIをコピ−して新たなTKIの雛型を作成すると共に、それに含まれるTKTMSRT、BITを分割・更新を行い、残りの情報要素を更新するという手順がなされる。
【０１２９】
図３５（ａ）は、AOBを任意のAOB_FRAMEで分割する場合を想定した図である。本図において第１段目は、4つのAOB_ELEMENTであるAOB_ELEMENT#1、AOB_ELEMENT#2、AOB_ELEMENT#3、AOB_ELEMENT#4を示す。これら4つのAOB_ELEMENTのそれぞれのデータ長は、4つのTMSRT_entry#k-1,#k,#k+1,#k+2(ここでk=2とする)としてTKTMSRTに設定されている。本図において、AOB_ELEMENT#2において分割境界bd1が設定されたとすると、AOB_ELEMENT#2は、分割境界bd1より前方のフレームからなる領域▲１▼と、分割境界bd1より後方のフレームからなる領域▲２▼とに分割される。図３５（ｂ）は、AOB_ELEMENT#2の途中部分でAOBが分割されて、AOB#1、AOB#2という2つのAOBが得られた状態を示す図である。
【０１３０】
{17-5_22-19_33A,B-3_36} BITの設定
図３６は、図３５に示したようにAOBが分割された場合に、BITがどのように設定されるかを示す図である。図３５に示したAOBは、分割境界bd1にて分割されており、その分割により得られたAOB#1は、AOB_ELEMENT#1と、AOB_ELEMENT#2という2つのAOB_ELEMENTを含み、AOB#2は、AOB_ELEMENT#1、AOB_ELEMENT#2、AOB_ELEMENT#3という3つのAOB_ELEMENTを含んでいることがわかる。
【０１３１】
これらのAOB_ELEMENTのそれぞれにも、三角旗状の記号が付与されているが、これらは、それぞれAOBに対応するTKIに含まれるTMSRT_entryが設定されていることを示す。先ず最初に分割により得られたAOB#1について説明する。AOB#1に含まれるAOB_ELEMENT#1、AOB_ELEMENT#2は、クラスタ007〜クラスタ00Aを占有しているので、AOB#1は、クラスタ007〜クラスタ00Aを一単位として扱われる。ここでAOB#1におけるAOB_ELEMENT#2は、クラスタ00Aの終端迄を占有しているのではなく、クラスタ00Aの存在する分割境界bd1迄を占有しているのでAOB#1についてのSZ_DATAは、領域md0から、クラスタ00Aにおける分割境界bd1までのデータ長を指示することになる。AOB#1の『FNs_1st_TMSRTE』は分割前と変わらないが、AOB#1の『FNs_Last_TMSRTE』は、AOB_ELEMENT#2の分割前の先頭から、分割境界bd1までのフレーム数を指示している点が分割前と異なる。
【０１３２】
続いて分割により得られたAOB#2について説明する。AOB#2に含まれるAOB_ELEMENT#1、AOB_ELEMENT#2、AOB_ELEMENT#3は、クラスタ00B〜クラスタ00Fを占有している。クラスタ00Fとは、クラスタ00Aの内容のコピーを格納しているクラスタである（クラスタ00Fにクラスタ00Aのコピーを格納している理由は、クラスタ00Aは、AOB#1のAOB_ELEMENT#2により占有されているので、このクラスタと異なるクラスタをAOB#2に含まれるAOB_ELEMENT#1に割り当てる必要があるからである。）。
【０１３３】
AOB#2におけるAOB_ELEMENT#1は、クラスタ00Fの先端から占有しているのではなく、クラスタ00Fの存在する分割境界bd1以降を占有しているのでAOB#2についてのSZ_DATAは、クラスタ00Bの先頭から、クラスタ00Eにおける途中部分までのデータ長と、クラスタ00FにおいてAOB_ELEMENT#1が占有しているデータ長との和を指示することになる。
【０１３４】
クラスタ00Fに格納されているクラスタ00Aのコピーには、AOB#1のAOB_ELEMENT#2が記録されており、AOB#1のAOB_ELEMENT#2により占有されている部分を、AOB#2から除外されねばならないので、AOB#2のBITについてのDATA_Offsetは、クラスタ00FにおいてAOB#1のAOB_ELEMENT#2により占有されているサイズが設定されている。
【０１３５】
この図からもわかるように、AOBの分割においては、分割境界を含むAOB_ELEMENTのみが2つに分割され、その分割境界の前後のAOB_ELEMENTは、分割前のものから変化していないことがわかる。そのため、AOB#2の『FNs_Last_TMSRTE』は、分割前のAOB_ELEMENT#4の『FNs_Last_TMSRTE』と同じ値に設定され、AOB#2の『FNs_1st_TMSRTE』は、AOB#2のAOB_ELEMENT#1、即ち、分割前のAOB_ELEMENT#2における分割境界以降の終端部分に含まれるフレーム数が設定される。
【０１３６】
{17-5_22-19_33A,B-4_37} BITの設定
図３７は、分割の前後でBITがどのように変化するかを更に具体的に示す図である。図３７の左側のBITは、分割前のBITの設定例を示す。トラックを分割する前のBITは、Data_OffsetがXに設定され、SZ_DATAが『52428』、TMSRTE_Nsが『n』個と設定される。FNs_1st_TMSRTEは『80フレーム』、FNs_Middle_TMSRTEについては『94フレーム』に設定され、FNs_Last_TMSRTEは『50フレーム』に設定されることがわかる。
【０１３７】
図３７の右側に、分割後の2つのトラックについてのBITの設定を示す。本BITに対応するAOBが図３５（ａ）に示すように分割された場合、１トラック目のBITにおいて、Data_Offsetは分割前と同一値『x』に設定されるが、SZ_DATAに分割点bd1までのデータ長『Q』に更新され、TMSRTE_Nｓには、1番目のTMSRT_entryからk番目のTMSRT_entryまでのTMSRT_entryの個数である『k個』に更新される。FNs_1st_TMSRTE及びFNs_Middle_TMSRTEについては分割前同様、80,94フレームに設定されるが、分割後の1トラック目のAOBの最後のAOB_ELEMENTには、図３５（ａ）においてp個のAOB_FRAMEが含まれているので、FNs_Last_TMSRTEは『pフレーム』に設定される。
【０１３８】
２トラック目のBITは、Data_OffsetがRに設定され、SZ_DATAがオリジナルのSZ#DATA52428−分割点bd1までのデータ長『Q』、TMSRTE_Nsがn-k+1個と設定される（k番目のTMSRT_entryからn番目のTMSRT_entryまでのTMSRT_entry個数であるn-k個と、分割のために新たに追加されたk番目のTMSRT_entryの個数である1個とを加算した数である。）。FNs_Middle_TMSRTE及びFNs_Last_TMSRTEについては分割前同様、94,50フレームに設定されるが、分割後の2トラック目のAOBの最初のAOB_ELEMENTには、94-p個のAOB_FRAMEが含まれているので、FNs_1st_TMSRTEは『94-pフレーム』に設定される。
【０１３９】
{17-5_22-19_33A,B-5_38} BITの設定
図３８は、分割後のTKTMSRTを示す図である。まずTMSRTについては以下のようになる。１トラック目のTMSRTは分割前のAOBのTMSRTのはじめからk番目のエントリまで(TMSRT_entry#1〜TMSRT_entry#k)を含む。ここで注意すべきは、分割境界を含むAOB_ELEMENT#kは、領域▲１▼を含むのみなので、このk番目のエントリーは、この領域▲１▼に相当する部分のデータサイズのみが含まれている。２トラック目のTMSRTは、分割前のk番目のエントリからn番目のエントリまで(TMSRT_entry#k〜TMSRT_entry#n)を含む。ここで注意すべきは、分割境界を含むAOB_ELEMENT#kは、2トラック目において領域▲２▼を含むのみなので、分割前のk番目のエントリーは、この領域▲２▼に相当する部分のデータサイズのみが含まれている。
【０１４０】
TKIをコピ−すると共に、TKTMSRT、BITを分割・更新を行い、残りの情報要素を更新すれば、分割により得られた新たなトラックについてのTKIが得られることになる。統合の場合と同様、暗号化されたAOBファイルを復号化することなく、暗号化された状態のままAOBファイルに対応するトラックを2つに分割することができる。AOBファイル分割の際に復号・再暗号化が伴わないので、トラックを分割する際の処理負荷が軽減されていることがわかる。これにより、再生装置の処理性能が低い場合でも、トラックの編集を行うことができる。
【０１４１】
以上長文となったが、TKIについての説明を終了する。続いてプレイリストについて説明する。
{17-6} Playlistmanager
図１７に示すPlaylistmanagerは、破線の引き出し線h5に示すように、フラッシュメモリカード３１内に格納されているプレイリストを管理するPlaylistManager_Information(PLMGI)と、フラッシュメモリカード３１に格納される全トラックを管理するDefault_Playlist_Information(DPLI)と、PlaylistInformation(PLI)#1,#2,#3,#4,#5・・・・・#nとからなり、Default_Playlist情報は、破線の引き出し線h6に示すように、Default_Playlist_General_Information(DPLGI),Default_Playlist_Track_Serch_Pointer(DPL_TK_SRP)#1,#2,#3,#4・・・・#mからなることがわかる。また各PLIは、破線の引き出し線h7に示すように、Playlist_General_Information(PLGI),Playlist_Track_Serch_Pointer(PL_TK_SRP)#1,#2,#3,#4・・・・#mからなることがわかる。
【０１４２】
ここでDefault_Playlist情報と、PlayList情報との差違について説明しておく。Default_Playlist情報は、全てのトラックを指定することが義務付けられているのに対して、PlayList情報は、そのような義務は存在せず、任意のトラックを指定すれば良い。そのため、ユーザが、自分の好みのトラックのみを指定しているようなPlayList情報を生成してフラッシュメモリカード３１に記憶させたり、またフラッシュメモリカード３１に記憶される複数のトラックのうち、所定のジャンルのトラックのみを指定しているようなPlayList情報を再生装置が自動的に生成してフラッシュメモリカード３１に記憶させるという用途に適している。
【０１４３】
{17-7_18} プレイリストの個数、データサイズ
図１８を参照すると、プレイリストの最大数は99個である。また、Playlist Manager Information(PLMGI)とDefault Playlist Information(DPLI)は、合計で2560バイトの固定長である。Playlist Information(PLI)もまた、512バイトの固定長である。Default_Playlist情報に含まれるDPL_TK_SRPは、DPL_TK_ATR,DPL_TKINを含んでいる。一方、PlayList情報に含まれるPL_TK_SRPは、PL_TKINのみを含んでいる。これらのDPL_TK_ATR,DPL_TKIN,PL_TKINは、図３９に示すフォーマットを有する。
【０１４４】
{17-8_39-1} DPL_TK_SRPのフォーマット
図３９（ａ）は、DPL_TK_SRPのフォーマットを示す図である。図３９（ａ）においてDPL_TK_SRPは、0ビット目から9ビット目までに、DPL_TKINが記述され、13ビット目から15ビットまでには、DPL_TK_ATRが記述され、10ビット目から12ビットまでは予約用に確保(reserved)されている。
【０１４５】
次に、0ビット目から9ビット目までのフィールドを占めるDPL_TKINには、TKI番号が記述される。ここにTKI番号を記述することにより、TKIを特定することが可能となる。
{17-9_39B} PL_TK_SRPのフォーマット
図３９（ｂ）は、PL_TK_SRPのフォーマットを示す図である。PL_TK_SRPは、0ビット目から9ビット目までのフィールドを有しており、ここにPL_TKIN、即ち、TKI番号が記述される。
【０１４６】
{17-8_39A-2} DPL_TK_ATRの構成
図３９（ａ）の『DPL_TK_ATR』から破線の矢印h51,h52にて引き出された枠内に、DPL_TK_ATRの設定例を示す。この枠内の記載からも理解できるように、DPL_TK_SRPについてのDPL_TK_ATRの設定は、TKIについてのTKI_BLK_ATRの設定と同一であり、『Track』、『Head_of_Track』、『Midpoint_of_Track』、『End_of_Track』の何れかが設定される。
【０１４７】
具体的には、TKINにて指定されたTKIが使用中であり、当該TKIに対応するAOBファイルに１個のトラックに対応するオーディオオブジェクトが収録されている場合（TKIのTKI_BLK_ATRにおける『Track』）、DPL_TK_ATRは"000b"の値が設定される。
TKINにて指定されたTKIが使用中であり、当該TKIに対応するAOBファイルにトラックの先頭部のみに対応するオーディオオブジェクトが収録されている場合（TKIのTKI_BLK_ATRにおける『Head_of_Track』）、DPL_TK_ATRは"001b"の値が設定される。
【０１４８】
TKINにて指定されたTKIが使用中であり、当該TKIに対応するAOBファイルにトラックの中間部のみに対応するオーディオオブジェクトが収録されている場合（TKIのTKI_BLK_ATRにおける『Midpoint_of_Track』）、DPL_TK_ATRには"010b"の値が設定される。
TKINにて指定されたTKIが使用中であり、当該TKIに対応するAOBファイルにトラックの終端部のみに対応するオーディオオブジェクトが収録されている場合（TKIのTKI_BLK_ATRにおける『End_of_Track』）、DPL_TK_ATRには、"011b"の値が設定される。
【０１４９】
TKINにて指定されたTKIが未使用であり、TKIの領域のみが確保されている場合、すなわち削除されたTKIである場合（TKIのTKI_BLK_ATRにおける『Unused』）、"100b"の値が設定される。
TKINにて指定されたTKIが未使用であり、TKIの領域が確保されていない場合、すなわち初期状態のTKIである場合は、"101b"の値が設定される。
【０１５０】
『DPL_TK_SRP』は、DPL_TKINにTKIの番号を記述することにより、複数のTKIのうち、何れかのものとの対応関係を有する。また、Default_Playlist情報におけるDPL_TK_SRPの順位は、DPL_TK_SRPと対応関係を有するTKIに対応するAOB（AOBファイル）が何番目に再生されるかを示す。これらのことにより、Default_Playlist情報におけるDPL_TK_SRPの順序は、複数のトラックをどのような順序で再生させるか、即ち、トラックの再生順序を定義することなる。
【０１５１】
{17-9_40-1} Default_Playlist情報、TKI、AOBファイルの相互関係
図４０は、Default_Playlist情報、TKI、AOBファイルの相互関係を示す図である。本図における第２、第３、第４段目は、図１９の第１段目、第２段目、第３段目と同一であり、8つのTKIを含むTrackManager、8つのAOBファイルを示す。図１９と異なるのは、第１段目にDefault_Playlist情報を示す四角枠が記述されている点である。第１段目の枠に含まれる8つの小枠は、Default_Playlist情報に含まれる8つのDPL_TK_SRPを示す。これらの小枠の上段はDPL_TK_ATRを示し、下段はDPL_TKINを示す。
【０１５２】
本図における矢印DT1,DT2,DT3,DT4・・・・・を参照すれば、DPL_TK_SRP#1と、TKI#1との間に対応関係が成立しており、DPL_TK_SRP#2と、TKI#2との間、DPL_TK_SRP#3と、TKI#3との間、DPL_TK_SRP#4と、TKI#4との間にも対応関係が成立していることがわかる。
更に、各DPL_TK_SRPにおけるDPL_TK_ATRを参照すれば、DPL_TK_SRP#1、DPL_TK_SRP#2、DPL_TK_SRP#3、DPL_TK_SRP#8は何れも、Trackと設定されている。即ち、DPL_TK_SRP#1→TKI#1（AOB001.SA1）、DPL_TK_SRP#2→TKI#2（AOB002.SA1）、DPL_TK_SRP#3→TKI#3（AOB003.SA1）、DPL_TK_SRP#8→TKI#8（AOB008.SA1）という4つの組みは、それぞれが独立したトラックに対応しているのである。
【０１５３】
DPL_TK_SRP#4、DPL_TK_SRP#5、DPL_TK_SRP#6、DPL_TK_SRP#7のDPL_TK_ATRは何れもTrackと設定されず、DPL_TK_SRP#4におけるDPL_TK_ATRは『Head_of_Track』と設定され、DPL_TK_SRP#7におけるDPL_TK_ATRは『End_of_Track』と、DPL_TK_SRP#5、DPL_TK_SRP#6は『Midpoint_of_Track』と設定されていることがわかる。このことは、DPL_TK_SRP#4と対応関係を有するTKI#4（AOB004.SA1）が、トラックの先頭部であり、DPL_TK_SRP#5,#6と対応関係を有するTKI#5（AOB005.SA1）及びTKI#6（AOB006.SA1）が、トラックの中間部と、DPL_TK_SRP#7と対応関係を有するTKI#7（AOB007.SA1）が、トラックの終端部であることを意味する。
【０１５４】
DefaultPlaylistにおけるDPL_TK_SRPの順序は、各TKIに対応づけられているAOBをどのような順序で再生させるかを示す。本図のDefaultPlaylist内のDPL_TK_SRP#1,#2,#3,#4・・・・・・#8のDPL_TKINは、TKI#1,#2,#3,#4・・・・・・#8を示しているので、矢印(1)(2)(3)(4)・・・・・(8)に示すようにTKI#1に対応するAOB001.SA1が1番目に再生され、TKI#2に対応するAOB002.SA1が2番目、TKI#3に対応するAOB003.SA1が3番目、TKI#4に対応するAOB004.SA1が4番目に再生されることになる。
【０１５５】
{17-10_41} DefaultPlaylist、PlayList情報の設定例
図４１は、DefaultPlaylist、PlayList情報の設定例を、図４０と同様の表記で示した図である。本図における第１段目における四角枠はDefault_Playlist情報を示し、第２段目における3つの四角枠はPlayList情報を示す。DefaultPlaylistに含まれる小枠は、DefaultPlaylistに含まれる8つのDPL_TK_SRPを示し、PlayList情報に含まれる小枠は、3つ又は4つのPL_TK_SRPを示す。本図のDefault_Playlist情報に含まれる各DPL_TK_SRPのTKINの設定は、図４０と同一である。しかし、PlayList情報に含まれるPL_TK_SRPのTKINの設定は、DPL_TK_SRPのそれと全く異なることがわかる。
【０１５６】
{17-10_42} DPL_TK_SRPとTKIとの対応
図４２は、図４０と同じ表記法を用いてDPL_TK_SRPとTKIとの対応を示す図である。図４２においてPlaylist#1は、PL_TK_SRP#1,#2,#3からなる。このうちPL_TK_SRP#1のPL_TKINは#3と記載されており、PL_TK_SRP#2のPL_TKINは#1と、PL_TK_SRP#3のPL_TKINは#2と記載されているので、PlayList情報#1を用いてトラックを再生する場合、矢印(11)(12)(13)に示すように複数のAOBはAOB#3,#1,#2の順序で再生される。
【０１５７】
Playlist#2は、PL_TK_SRP#1,#2,#3からなる。このうちPL_TK_SRP#1のPL_TKINは#8と記載されており、PL_TK_SRP#2,#3のPL_TKINは#3、#1と記載されているので、PlayList情報#2を用いてトラックを再生する場合、矢印(21)(22)(23)に示すように複数のAOBはAOB#8,#3,#1という順序、即ちPlaylist#1と全く異なる順序で再生される。
【０１５８】
Playlist#3は、PL_TK_SRP#1,#2,#3,#4からなる。このうちPL_TK_SRP#1,#2,#3,#4のPL_TKINは#8,#4,#3,#1と記載されているので、PlayList情報#3を用いてトラックを再生する場合以下に示す再生順序でAOBが再生される。先ず矢印(31)に示すようにTrackEを構成するAOB#8が再生され、矢印(32)に示すようにTrackDを構成するAOB#4,AOB#5,AOB#6,AOB#7がこれに続いて再生される。続いて、矢印(33)(34)に示すようにTrackC、TrackAを構成するAOB#3,AOB#1という順序で再生される。ここで注意すべきは、トラックが複数のTKIから構成される場合、PL_TK_SRPのエントリーには、複数TKIのうち、先頭のTKI番号のみが記述されている点である。具体的にいうと、Default_Playlist情報におけるDPL_TK_SRPは、TrackDについての4つのTKIであるTKI#4、TKI#5、TKI#6、TKI#7を指定していたが、PlayList情報におけるPL_TK_SRPは、それら4つのTKIを指定する必要はない。Playlist#3のPL_TK_SRP#2がTKI#4〜TKI#7のうち、TKI#4のみを指定していることは、このことを意味している。
【０１５９】
一方、複数のDPL_TK_SRPを含むDPLIは、1セクタに収まるようなデータサイズを有しており、RAM上に常駐されている。そのため、Playlistに基づいて各トラックを再生する場合、RAM上に常駐されているDPL_TK_SRPを参照することにより、各TKIを高速に検索することが可能となる。即ち、複数TKIのうち、先頭のTKI番号のみが記述されているPL_TK_SRPを用いてTKI(AOB)を再生するには、PL_TK_SRPに記述されているTKIを元にRAM上に常駐されているDPL_TK_SRPを検索し、トラックが複数のTKIから構成されているか否かを判定する。複数のTKIから構成されている場合には、対応するTKI(AOB)を全て再生するという手順を経るのである。
【０１６０】
以上のように、PlayListManagerにはDefaultPlaylist、複数のPlayList情報が記述され、これらを構成するDPL_TK_SRP、PL_TK_SRPのDPL_TKIN、PL_TKINにそれぞれ相異なる再生順序が記載されていれば、複数AOBは、それぞれ相異なる再生順序で再生されることになる。全く異なる再生順序で再生されれば、操作者は、複数の音楽アルバムが格納されているような感覚でフラッシュメモリカード３１を利用することができる。
【０１６１】
また、注意すべきは、何れもAOBファイルに対応づけられているDPL_TK_SRP、TKIのうち、DPL_TK_SRPのデータサイズは小さく(2バイトに過ぎない)、TKIのデータサイズは大きい(1024バイトもある。)点である。TrackManagerにおけるTKIの順序を入れ替えることは、フラッシュメモリカード３１に対するアクセスが多く発生するが、Default_Playlist情報、PlayList情報におけるDPL_TK_SRPの順序を入れ替えても、フラッシュメモリカード３１に対するアクセスはそれほど多くなならない。この点に鑑み、ナビゲーションデータは、その編集時において、編集操作に応じてDefaultPlaylistにおけるDPL_TK_SRPの順序を積極的に変化させる一方、TrackManagerにおけるTKIの順序は、編集操作にかかわらず、一定に維持するようにしている。
【０１６２】
{17-9_40-2_43A,B} DPL_TK_SRPの順序を入れ替え
次に、Default_Playlist情報におけるDPL_TK_SRPの順序を入れ替えることにより、トラックの再生順序を変更するという編集操作がどう行われるかについて説明する。図４３（ａ）、（ｂ）は、トラックの順序を入れ替える場合を想定した図である。図４３（ａ）におけるDPL_TK_SRP、TKIの設定は、図４０と同じである。図４０（ａ）においてDPL_TK_SRP#3におけるDPL_TKINはTKI#3、DPL_TK_SRP#8におけるDPL_TKINはTKI#8と設定されていたが、この状態において、太枠で囲ったDPL_TK_SRP#3と、DPL_TK_SRP#8との順番を入れ替える。図４３（ｂ）における(1)(2)(3)(4)(5)(6)(7)(8)は、順番入れ替え後のトラックの再生順序を示す。このことに留意すると、図４３（ａ）における再生順序は、TrackA、TrackB、TrackC、TrackD、TrackEであるが、図４３（ｂ）におけるDefault_Playlist情報では、DPL_TK_SRP#3、DPL_TK_SRP#8についてのDPL_TKINの順序が入れ替えられたので、TrackA、TrackB、TrackE、TrackD、TrackCの順序で再生されることになる。このように、Default_Playlist情報における、DPL_TK_SRPの順序を入れ替えることにより、簡易にトラックの再生順序を変更することができる。
【０１６３】
トラックの変更操作という編集操作について説明したところで、TKIの場合と同様、一部のトラックが削除された場合(case1)、一部のトラックが削除された後、新たなトラックを記録する場合(case2)、複数のトラックのうち、任意の2つを1つのトラックに統合する場合(case3)、1つのトラックを分割して、2つのトラックを得る場合(case4)において、DPL_TK_SRP及びTKIがどのように更新されるかについて説明する。
【０１６４】
{17-9_40-3_44A,B} トラックを削除する場合
先ず初めに、一部のトラックが削除された場合(case1)について説明する。
図４４（ａ）、（ｂ）は、図４０に示したDefaultPlaylistのうち、DPL_TK_SRP#2及びTKI#2を削除する場合にDefaultPlaylist、TrackManager、AOBファイルがどのように更新されるかを示す図である。図４４は、TKIの削除の説明で引用した図２７と同一部分を有する。即ち、図４４における第２、第３、第４段目は図２７と同一である。異なるのは図４０同様、第１段目に複数のDPL_TK_SRPを含むDefault_Playlist情報が記載されている点である。図４４（ａ）において太枠で囲ったDPL_TK_SRP#2→TKI#2（AOB002.SA1）からなるTrackBをユーザが削除したものとする。この場合、Default_Playlist情報においてはDPL_TK_SRP#2が削除されて、DPL_TK_SRP#3〜DPL_TK_SRP#8は、DPL_TK_SRP#2が占有していたフィールドを詰めるように、順番が1つずつ繰り上がる。このように各DPL_TK_SRPの順番を繰り上がり、一番最後のDPL_TK_SRP#8が『Unused』に設定される。これに対してTKIは、図２７（ａ）、（ｂ）を用いて説明したように『Unused』に設定されているのみで、TKI#2を詰めるような移動は行われていない。またAOB002.SA1は、削除されていることがわかる。DPL_TK_SRPについては順番の繰り上げが行われたが、TKIについては順番の繰り上げが行われていないので、図４４（ｂ）では、DPL_TK_SRPにおけるDPL_TKINが更新されている。即ち、新たなDPL_TK_SRP#2のDPL_TKINは、矢印DT11に示すようにTKI#3を指示しており、DPL_TK_SRP#3のDPL_TKINは矢印DT12に示すようにTKI#4を、DPL_TK_SRP#4のDPL_TKINはTKI#5、DPL_TK_SRP#5のDPL_TKINはTKI#6をそれぞれ指示している。更に、『Unused』に設定されたDPL_TK_SRP#8のDPL_TKINは、矢印DT13に示すように、『Unused』に設定されたTKI#2を設定していることがわかる。
【０１６５】
トラックの削除が行われた場合、使用中であるDPL_TK_SRPが先頭に繰り上げられるが、それに対応するTKIは、もとの配置を保ったまま、未使用に設定されることがわかる。このように、TKIの配置を編集前後において、不動とするので、編集処理に伴う処理負荷を軽減することができる。
{17-9_40-4_45A,B} トラックを記録する場合のTKIの割り当て
続いて一部のトラックが削除された後、新たなトラックを記録する場合(case2)について説明する。図４５（ａ）、（ｂ）は、『Unused』のTKIと、DPL_TK_SRPとが存在しており、ここに新たなTKI、DPL_TK_SRPを書き込む場合、その書き込みがどのように行われるかを示す図である。図４５（ａ）、（ｂ）において、『Unused』のTKIに新たなTKIを割り当てるケースを説明した際、引用した図２８（ａ）〜（ｂ）と同一部分を有する。即ち、図４５（ａ）、（ｂ）における第２、第３、第４段目は、図２８（ａ）、（ｂ）の第１、第２、第３段目と同一である。異なるのは、図４５の第１段目に複数のDPL_TK_SRPからなるDefault_Playlist情報が記述されている点である。図４５（ａ）において、DPL_TK_SRP#4〜DPL_TK_SRP#8が『Unused』であり、一方、図２８（ａ）に示したようにTKI#2、TKI#4、TKI#5、TKI#7、TKI#8が『Unused』であることがわかる。TrackManagerにおいて『Unused』のTKIが虫食い状に存在しているのに対して、Default_Playlist情報において『Unused』のDPL_TK_SRPがまとめられているのは、上述したように、DPL_TK_SRPは、『Unused』以外のDPL_TK_SRPの繰り上げが行われるのに対して、TKIは、そのような繰り上げが行われないからである。
【０１６６】
ここで4つのAOBからなるTrackDを書き込もうとする場合を想定する。その4つのAOBのそれぞれについてのTKIは、TrackManagerにおいて、『Unused』に設定されているTKI#2、TKI#4、TKI#7、TKI#8のそれぞれに書き込まれる。
一方、これら4つのAOBについてのDPL_TK_SRPは、Default_Playlist情報におけるDPL_TK_SRP#4〜DPL_TK_SRP#7に書き込まれる。これら4つのAOBは1つのトラックを構成するものなので、DPL_TK_SRP#4についてのDPL_TK_ATRは『Head_of_Track』と、DPL_TK_SRP#5、DPL_TK_SRP#6についてのDPL_TK_ATRは『Midpoint_of_Track』と、DPL_TK_SRP#7についてのDPL_TK_ATRは『End_of_Track』と設定されている。
【０１６７】
また、DPL_TK_SRP#4についてのDPL_TKINはTKI#2と設定され、DPL_TK_SRP#5についてのDPL_TKINはTKI#4、DPL_TK_SRP#6についてのDPL_TKINはTKI#7、DPL_TK_SRP#7についてのDPL_TKINはTKI#8と設定されている。
以上のようなDPL_TKIN、DPL_TK_ATRの設定により、TKI#2,TKI#4,TKI#7,TKI#8は、4つ目のトラックTrackDとして管理されることなる。
【０１６８】
以上の処理において、『Unused』のTKIに対する書き込みが行われたが、TKI#1、TKI#2、TKI#3、TKI#4に関しては、何の変動もなされていない点は図２８の場合と同様である。
{17-9_40-5_46A,B} トラックの統合(case3)を行う場合について
続いてトラックの統合(case3)を行う際の、Default_Playlist情報の更新について説明する。図４６（ａ）、（ｂ）は、トラックの統合を行う場合を想定した図である。本図は、TKIの統合処理を説明した際に引用した図２９（ａ）、（ｂ）と同一部分を有する。即ち、図４６（ａ）、（ｂ）における第２、第３、第４段目は、図２９（ａ）、（ｂ）における第１段目、第２段目と同一である。差違点は、図４６（ａ）、（ｂ）では、Default_Playlist情報が記載されており、それに含まれるDPL_TK_SRP#8が『Unused』に設定されていて、同じく『Unused』に設定されているTKI#2と対応関係を有している点である。本図において、図２９に示したようなトラックの統合処理が、AOBファイル及びTKIに対してなされると、DPL_TK_SRP#3〜DPL_TK_SRP#6の内容を1つずつずらして、太枠で囲ったDPL_TK_SRP#7の記述内容をDPL_TK_SRP#3にコピーする。TKIについては、図２９に示した場合と同様の更新処理がなされる。
【０１６９】
{17-9_40-6_47A,B} トラックの分割(case4)を行う場合について
続いてトラックの分割(case4)を行う際の、Default_Playlist情報の更新について説明する。
図４７（ａ）、（ｂ）は、トラックの分割を行う場合を想定した図である。本図は、TKIについての分割処理を説明した際に引用した図３３（ａ）、（ｂ）と同一部分を有する。即ち、本図における第２段目、第３段目は、図３３（ａ）、（ｂ）における第１段目、第２段目と同一である。差違点は、図４７（ａ）、（ｂ）では、Default_Playlist情報が記載されており、それに含まれるDPL_TK_SRP#8が『Unused』に設定されていて、同じく『Unused』に設定されているTKI#2と対応関係を有している点である。この状態において、図３３の場合と同様に、太枠で囲ったTKI#3、AOB003.SA1を2つに分割しようとすると、DPL_TK_SRP#3〜DPL_TK_SRP#7の順序を一つずつ繰り下げて、Default_Playlist情報における『Unused』のDPL_TK_SRPをDPL_TK_SRP#3まで移動する。移動後のDPL_TK_SRP#3には、分割により得られたTKI#2が対応づけられる。TKI#2に対応づけられているAOB002.SA1は、元々AOB003.SA1の後半部を格納したものであるが、TKI#2に対応づけられているDPL_TK_SRP#3の前に、DPL_TK_SRP#2が存在し、このDPL_TK_SRP#2は、TKI#2−AOB002.SA1が対応づけられている。即ち、AOB002.SA1及びAOB003.SA1は、元のAOB003.SA1の後半部分、前半部分を格納しているが、これらを指定しているDPL_TK_SRP#2、DPL_TK_SRP#3は、AOB003.SA1、AOB002.SA1の順序で、これらのAOBファイルを再生するよう再生順序を指定しているので、元のAOB003.SA1の後半部分、前半部分は、DPL_TK_SRPの再生順序指定により、前半部分、後半部分の順に、再生されることなる。
【０１７０】
{17-9_40-8} 編集処理の応用
以上の4つの編集操作を組み合わせることにより、操作者は、様々な編集操作を行うことができる。即ち、あるトラックの先頭部分にディスクジョッキーのアナウンスが入っており、これを削除したい場合、上記のトラックの分割処理にて、そのアナウンス部分を一個のトラックとして分割し、その後、そのトラックを削除すれば、ディスクジョッキーのアナウンスのみを部分的に削除することができる。
【０１７１】
以上でナビゲーションデータについての説明を終え、続いて、このようなナビゲーションデータ、プレゼンテーションデータを再生するために構成された再生装置について説明する。
{48-1} 再生装置の外観
図４８は、本実施形態に係るフラッシュメモリカード３１についての携帯型の再生装置を示す図である。本図において再生装置は、フラッシュメモリカード３１が挿入される挿入口、再生、順方向サーチ再生、逆方向サーチ再生、早送り、巻き戻し、停止等のキー操作を操作者から受け付けるためのキーパネルと、液晶ディスプレィとを有しており、通常の携帯型音響機器同様の外観を有する。キーパネルには、プレイリスト／トラックの選択を受け付けるPlaylistキー、トラックの先頭へのスキップを受け付ける『|<<キー』、次トラックの先頭へのスキップを受け付ける『>>|キー』、早送り、巻き戻し、順方向サーチ再生、逆方向サーチ再生を受け付ける『>>キー』,『<<キー』、フラッシュメモリカード３１に静止画が格納されている場合に、静止画を表示させる操作を受け付けるDisplayキー、録音操作を操作者から受け付けるRecキー、Stereo/Monoral選択、サンプリング周波数選択を操作者から受け付けるAudioキー、ブックマークの指定を受け付けるMarkキー、トラックの編集、タイトル入力を受け付けるEditキーが備えられている。
【０１７２】
{48-2} フラッシュメモリカード３１の携帯型再生装置における改良点
このフラッシュメモリカード３１の携帯型再生装置が通常の携帯型音響機器と異なるのは、以下の改良点(1)〜(4)である。即ち、操作者からDefault_Playlist情報、PlayList情報、トラックの指定を受け付けるために、液晶ディスプレィには、プレイリスト、トラックの一覧表示がなされること(1)、また、そのように一覧表示されたプレイリスト又はトラックのうち、任意のものを再生対象又は編集対象として指定させるためのキー割り当てがなされていること(2)、トラックの再生進行と共に、液晶ディスプレィには、トラックの再生経過時刻が表示されること(3)、タイムサーチ機能や分割編集を行う際に、再生開始時間を設定するために用いられるジョグダイアルが設けられていること(4)である。
【０１７３】
{48-2_49_50} 改良点(2)の詳細
改良点(2)の詳細は以下の通りである。図４９は、プレイリストの選択が行われる際の液晶ディスプレィの表示内容の一例を示す図であり、図５０は、トラックの選択が行われる際の液晶ディスプレィの表示内容の一例を示す図である。
図４９における『DEFAULTPLAYLIST』『PLAYLIST#1』『PLAYLIST#2』『PLAYLIST#3』『PLAYLIST#4』は、フラッシュメモリカード３１に格納されているデフォルトプレイリストと、4つのプレイリストを示すASCII文字列である。また、図５０（ａ）における『TRACK#1』『TRACK#2』『TRACK#3』『TRACK#4』『TRACK#5』は、フラッシュメモリカード３１に格納されているデフォルトプレイリストにて、再生順序が指定される5つのトラックを示すASCII文字列である。図４９及び図５０（ａ）にて、ハッチングを付したこれらのプレイリスト及びトラックは、再生対象又は編集対象として指定されていることを示す。このように液晶ディスプレィにプレイリストにて再生順序が規定されるトラックが一覧表示され、TRACK#1が再生対象に指定された状態で>>|キーの押下がなされると、図５０（ｂ）に示すように一覧表示された複数トラックのうち、その下のTRACK#2が再生対象に指定される。TRACK#2が、再生対象に指定された状態で>>|キーの押下がなされると、図５０（ｃ）に示すように一覧表示された複数トラックのうち、更に下段のTRACK#3が再生対象に指定される。TRACK#3が再生対象に指定された状態で|<<キーの押下がなされると、一覧表示された複数トラックのうち、図５０（ｄ）に示すように一段上のTRACK#2が再生対象に指定される。このように>>|キー、|<<キーの押下に応じて、何れかのトラックが再生対象として選択されるので、何れかのトラックが再生対象として選択された際に、図５０（ｅ）に示すように再生キーが押下されれば、そのトラックの再生が開始され、Editキーが押下されれば、そのトラックが編集対象として指定される。
【０１７４】
{48-3_51} 改良点(4)の詳細
続いて改良点(4)の詳細について説明する。図５１は、ジョグダイアルの操作例を示す図である。ジョグダイアルにより、操作者による回転操作を受け付けて、その回転量に応じて、液晶ディスプレィに表示されている再生経過時刻を増減させる。例えば図５１（ａ）に示すように、液晶ディスプレィに再生開始時刻が『00:00:20』と表示されているものとする。この場合、図５１（ｂ）に示すように、ジョグダイアルが反時計回りに回転されたとすると、再生開始時刻は、その回転量に応じて減少して『00:00:10』となる。また図５１（ｃ）に示すように、ジョグダイアルが時計回りに回転されたとすると、再生開始時刻は、その回転量に応じて増加して『00:00:30』となる。
【０１７５】
このように再生時間時間を増減させるのは、トラックにおける任意の再生時刻を指定するためであり、ジョグダイアルの回転により、任意の再生時刻が指定され、再生キーが押下されれば、上記｛数式２｝｛数式３｝に従って指定された位置からAOBを再生する。
また、分割編集においてジョグダイアルは、任意の再生開始時間を分割境界として特定する際、分割境界を微調整するために用いられる。
【０１７６】
{52-1} 再生装置の内部構成について
続いて再生装置の内部構成について説明する。図５２は、再生装置の内部構成を示す図である。本図において再生装置は、フラッシュメモリカード３１を接続するためのカードコネクタ１と、キーパネル、ジョグダイアルと接続されるユーザインターフェイス部２と、RAM３と、ROM４と、プレイリスト、トラックを一覧表示する一覧表示枠、再生経過時刻が表示される再生経過時刻枠を有する液晶ディスプレィ５と、液晶ディスプレィを駆動するためのLCDドライバ６と、AOBファイル毎に異なるFileKeyを用いて、AOB_FRAMEの暗号化を解除するデ・スクランブラ７と、デ・スクランブラ７によりAOB_FRAMEのデスクランブルが行われれば、当該AOB_FRAMEのADTSヘッダを参照して、当該AOB_FRAMEを復号することにより、PCMデータを得るAACデコーダ８と、AACデコーダ８の復号により得られたPCMデータをD/A変換して、ヘッドホン端子を介してスピーカーに出力するD/Aコンバータ９と、再生装置内の統合処理を行うCPU１０とを備える。このハードウェア構成からも判るように、本再生装置には、TrackManager、Default_Playlist情報を処理するための新規の構成は見られない。TrackManager、Default_Playlist情報の処理のために設けられているのは、RAM３内に確保されているDPLI常駐領域１１、PLI格納領域１２、TKI格納領域１３、FileKey格納領域１４、ダブルバッファ１５と、ROM４に格納されている再生制御プログラム及び編集制御プログラムである。
【０１７７】
{52-2} DPLI常駐領域１１
DPLI常駐領域１１は、カードコネクタ１に接続されフラッシュメモリカード３１から読み出されたDefault_Playlist情報を常駐させるために確保されている領域である。
{52_12} PLI格納領域１２
PLI格納領域１２は、操作者により選択され、再生対象になっているPlayList情報を格納しておくために確保されている領域である。
【０１７８】
{52-3} TKI格納領域１３
TKI格納領域１３は、TrackManagerに含まれる複数のTKIのうち、再生対象になっているAOBファイルに対応するTKIのみを格納しておくために確保されている領域であり、TKI1個分のデータサイズを有する。
{52-4} FileKey格納領域１４
FileKey格納領域１４は、プロテクト領域内のAOBSA1.KEYに含まれる複数のFileKeyのうち、再生対象になっているAOBファイルに対応するFileKeyのみを格納しておくために確保されている領域である。
【０１７９】
{52-5} ダブルバッファ１５
ダブルバッファ１５は、フラッシュメモリカード３１から読み出されたクラスタデータ（クラスタ一個当たりに格納されるデータ）を順次入力して格納するという入力処理と、格納されたクラスタデータから暗号化AOB_FRAMEを読み出して、順次デ・スクランブラ７に出力するという出力処理とを並列に行う場合に用いられる入出力バッファである。ダブルバッファ１５は、AOB_FRAMEとしての出力が済んだクラスタが占有していた領域を順次空き領域に解放し、この空き領域を、新たに読み出されたクラスタの格納に用いるという領域確保、即ち、リングポインタを用いた巡回式の領域確保を行う。
【０１８０】
{52-5_53_54A,B} ダブルバッファ１５における入出力
図５３は、ダブルバッファ１５におけるデータ入出力がどのように行われるかを示す図である。図５４（ａ）、（ｂ）は、リングポインタを用いた巡回式の領域確保がどのように行われるかを示す図である。
これらの図において左下向きの矢印は、クラスタデータの書込先アドレスについてポインタ、即ち、書込先ポインタを示す。左上向きの矢印は、クラスタデータの読出先アドレスについてのポインタ、即ち、読出先ポインタを示す。これらのポインタは、リングポインタとして用いられる。
【０１８１】
{54-6_53} フラッシュメモリカード３１がカードコネクタ１に接続されると、このフラッシュメモリカード３１のユーザデータ領域におけるクラスタデータは、矢印w1,w2に示すようにフラッシュメモリカード３１から読み出される。読み出されたクラスタデータは、ダブルバッファ１５において、書込先ポインタWP1,WP2に示される位置に順次格納されてゆく。
【０１８２】
{52-7_54A} このように格納されたクラスタデータに含まれるAOB_FRAMEのうち、読出先ポインタ▲１▼▲２▼▲３▼▲４▼▲５▼▲６▼▲７▼▲８▼▲９▼に指示される位置に存在するAOB_FRAMEは、矢印r1,r2,r3,r4,r5・・・・・・に示すように順次デ・スクランブラ７へと出力されてゆく。ここでダブルバッファ１５にクラスタデータ002,003が格納されており、読出先ポインタにてに示さる読出先が図５３の▲１▼▲２▼▲３▼▲４▼に示すように移動して、▲５▼に達した場合、クラスタ002に含まれるAOB_FRAMEは全て読み出されたことになるので、新たにクラスタ004を読み出して、図５４（ａ）の矢印w6に示すように、クラスタ002が占有していた領域に上書きする。
【０１８３】
{52-8_54B} また読出先ポインタにてに示さる読出先が▲６▼▲７▼に示すように移動して、▲９▼に達すれば、クラスタ003に含まれるAOB_FRAMEは全て読み出されたことになるので、新たにクラスタ005を読み出して、図５４（ｂ）の矢印w7に示すように、クラスタ003が占有していた領域に上書きする。以上のような、AOB_FRAMEの出力と、クラスタデータの上書きとが何度も繰り返されて、AOBファイルに含まれるAOB_FRAMEが順次デ・スクランブラ７、AACデコーダ８に出力されてゆく。
【０１８４】
{52-9_55〜58} ROM４に格納されている再生制御プログラム
続いてROM４に格納されている再生制御プログラムについて説明する。
図５５は、AOBファイル読み出し処理の処理手順を示すフローチャートであり、図５６、図５７、図５８は、AOB_FRAME出力処理の処理手順を示すフローチャートである。
【０１８５】
{52-9_55-1} これらのフローチャートにおいて、変数wとは、複数DPL_TK_SRPのそれぞれを指示する変数であり、変数zとは、それぞれのAOBファイルと、それに対応するTKIと、それに含まれるAOBとを一意に指示するための変数である。変数yとは、変数zにて指示されるAOB#zに含まれる個々のAOB_ELEMENTを指示するための変数であり、変数xとは、変数yにて指示されるAOB_ELEMENT#yに含まれるそれぞれのAOB_FRAMEを指示する変数である。先ず図５５を参照しながらAOBファイル読出処理の処理手順について説明する。
【０１８６】
{52-9_55-2} ステップＳ１においてCPU１０はPlayListManagerを読み出して、Default_Playlist情報及びPlayList情報を一覧表示する。ステップＳ２においてCPU１０は、Default_Playlist情報、PlayList情報の何れに従ってAOBを再生させるかの指定を待つ。ここで、Default_Playlist情報が指定された場合、ステップＳ２からステップＳ３に移行して、変数wを初期化し（#w←1）、ステップＳ４では、Default_Playlist情報におけるDPL_TK_SRP#wに対応づけられたDPL_TKINにより指定されているTKI#zを特定して、そのTKI#zのみをTKI格納領域１３に読み出す。そして、ステップＳ５においてTKI#zと同じ番号を有するAOBファイル#zを特定する。ここまでの手順で、ようやく、再生すべきAOBファイルが特定されたことになる。特定されたAOBファイルは、暗号化されているので、このAOBファイルの暗号化を解除すべく、以降ステップＳ６、ステップＳ７の処理を行う。即ち、ステップＳ６では、プロテクト領域をアクセスして、暗号鍵格納ファイルにおいて当該AOBファイル#zと同じ番号を有するFile Key Entry#zに格納されているFileKey#zを読み出す。ステップＳ７においてCPU１０は、FileKey#zをデ・スクランブラ７に設定する。かかる設定により、FileKeyはデ・スクランブラ７に設定されたので、以降、AOBファイルに含まれるAOB_FRAMEが順次デ・スクランブラ７に投入されれば、AOB_FRAMEは順次再生されることになる。
【０１８７】
{52-9_55-3} 以降、AOBファイルを格納している各クラスタを順次読み出してゆく。ステップＳ８では、ディレクトリエントリーにおけるそのAOBファイル#zについての『ファイル最初のクラスタ番号』を特定し、ステップＳ９においてCPU１０は、そのクラスタに格納されているデータをフラッシュメモリカード３１から読み出す。ステップＳ１０では、FAT値にクラスタ番号がFFFと記述されているか否かを判定し、もしFAT値がFFF以外の値なら、ステップＳ１１においてそのFAT値にて指示されているクラスタに格納されているデータを読み出す。かかる読み出し後、ステップＳ１０に移行する。ここで、何れかのクラスタに格納されているデータを読み出し、そのクラスタに対応づけられているFAT値を参照した際、そのFAT値にFFF以外の何れかのクラスタ番号が記述されている限り、ステップＳ１０−ステップＳ１１の処理は繰り返し行われる。これにより、そのFAT値により指示されているクラスタが順次読み出されてゆく。そのFAT値にクラスタ番号がFFFと記述されている場合、AOBファイル#zを構成するクラスタは全て読み出されたことになるので、ステップＳ１０からステップＳ１２に移行する。
【０１８８】
{52-9_55-4} ステップＳ１２においてCPU１０は、変数#wがDPL_TK_SRPの総数と一致したか否かを判定する。一致しないなら、ステップＳ１３に移行して、変数#wをインクリメントした後（#w←#w+1）、ステップＳ４に移行する。ステップＳ４においてDefault_Playlist情報におけるDPL_TK_SRP#wのDPL_TKIN#wにより指定されているTKI#zを特定して、そのTKI#zのみをTKI格納領域１３に読み出す。この際、TKI格納領域１３にはそれまで使用されていたTKIが格納されているが、CPU１０は、TKI格納領域１３に既に格納されているTKIを新たに読み出したTKIを用いて上書きする。このような上書きによりTKI格納領域１３には、最新のTKIのみが格納されることになる。このようにTKIが上書きされれば、ステップＳ５〜ステップＳ１２の処理をAOBファイル#zについて繰り返す。ステップＳ５〜ステップＳ１２の処理が繰り返され、Default_Playlist情報に含まれる全てのDPL_TK_SRPに対応するTKI、AOBファイルが読み出されれば、変数#wとDPL_TK_SRPの総数とが一致して、ステップＳ１２がYesとなり、本フローチャートを終了する。
【０１８９】
{52-9_56_57_58} AOB_FRAME出力処理
かかるAOBファイル読出処理と並行して、CPU１０は、図５６、図５７、図５８のフローチャートに従い、AOB_FRAME出力処理を行う。本フローチャートにおいてplay_timeとは、これまで再生が経過した時間、即ち、再生経過時刻を示す変数であり、液晶ディスプレィ５の時刻表示枠内の時刻は、このplay_timeの更新に応じて、表示内容が書き換えられる。また、play_dataとは、これまで再生されたデータ長である。
【０１９０】
{52-9_56-1} ステップＳ２１において、CPU１０は、AOBファイル#zについてのクラスタデータがダブルバッファ15に蓄積されたかを監視している。クラスタデータが蓄積されない限り、このステップＳ２１を繰り返し行うが、クラスタデータが蓄積されれば、ステップＳ２２において、#x、#yの初期化を行い（#x←1,#y←1）、その後、ステップＳ２３において、AOBファイル#zについてのクラスタにおいて、TKI#zに含まれるBIT#zのData_Offset以降からAOB_ELEMENT#yにおけるAOB_FRAME#xを検出する。ここでSZ_DATAから7バイトは、ADTSヘッダが占有しているものとして、当該ADTSヘッダを参照し、ADTSヘッダに示されているデータ長が本体部のオーディオデータであると解析して、当該ADTSヘッダと、本体部のオーディオデータとを読み出し、デ・スクランブラ７に出力する。デ・スクランブラ７によりAOB_FRAMEの暗号化が解除され、AACデコーダ８により復号が行われれば、音声として再生されることになる。
【０１９１】
{52-9_56-2} 検出後、ステップＳ２４において、AOB_FRAME#xをデ・スクランブラ7に出力し、ステップＳ２５において、再生経過時刻play_timeをAOB_FRAME#xに相当する再生時間だけインクリメントし、再生済みデータ数play_dataをAOB_FRAME#xに相当するデータ数だけインクリメントする。ここでAOB_FRAMEの再生時間長は、20msecであるので、再生経過時刻play_timeには、20msecが加算されることになる。
【０１９２】
1番目のAOB_FRAMEがデ・スクランブラ７に出力されれば、ステップＳ２６においてAOB_FRAME#xのADTSヘッダを参照して、次のAOB_FRAMEが何処に存在するかを特定する。ステップＳ２７では、変数#xのインクリメントを行い（#x←#x+1）、次のAOB_FRAMEをAOB_FRAME#xとする。ステップＳ２８においてAOB_FRAME#xをデ・スクランブラ7に投入する。その後、ステップＳ２９では、play_timeを、AOB_FRAME#xに相当する再生時間だけインクリメントすると供に、play_dataをAOB_FRAME#xに相当するデータ数だけインクリメントする。AOB_FRAME#xをインクリメントした後、ステップＳ３０においてCPU１０は、#xが『FNs_1st_TMSRTE』に達したかを判定する。#xが『FNs_1st_TMSRTE』に達しないのなら、ステップＳ３１において、Playキー以外のキーが押下されたかどうかを確認した後、ステップＳ２６に移行する。以降、#xが『FNs_1st_TMSRTE』に達するまで、または、Playキー以外のキーが押下されるまで、ステップＳ２６〜ステップＳ３１の処理は繰り返し行われる。ここでPlayキー以外のキーが押下された場合、本フローチャートを終了して、押下されたキーに該当する処理を行う。押下されたキーが停止キーなら再生処理を停止し、押下されたキーが一時停止キーなら一時停止を行う。
【０１９３】
{52-9_57-1} 一方、#xが『FNs_1st_TMSRTE』に達したなら、ステップＳ３０がYesとなり、図５７のステップＳ３２に移行する。ステップＳ２６からステップＳ３０までの処理にて、AOB_ELEMENTに含まれる全てのAOB_FRAMEがデ・スクランブラ７に投入されたので、次のAOB_ELEMENTに処理対象を移行すべく、ステップＳ３２において#yをインクリメントすると共に、#xを初期化する（#y←#y+1,#x←1）。
【０１９４】
その後、ステップＳ３３においてTKTMSRTを参照してAOB_ELEMENT#yについての先頭アドレスを算出する。以降、ステップＳ３４〜ステップＳ４２からなる処理を行う。ステップＳ３４〜ステップＳ４２の処理は、AOB_ELEMENTに含まれるAOB_FRAMEを次々と読み出す処理である点で、ステップＳ２４〜ステップＳ３１からなる処理と同一であるといえる。ステップＳ２４〜ステップＳ３１の処理と異なるのは、後者におけるループ処理の終了条件は、#xが『FNs_1st_TMSRTE』に達することであるのに対し、前者におけるループ処理の終了条件は、#xが『FNs_Middle_TMSRTE』に達することである。#xが『FNs_Middle_TMSRTE』に達して、ステップＳ３４〜ステップＳ４２からなるループ処理が終了すると、ステップＳ４１がYesとなってステップＳ４３に移行する。ステップＳ４３においてCPU１０は#yをインクリメントすると共に、#xを初期化する（#y←#y+1,#x←1）。その後、ステップＳ４４において、変数yが、TKI#zのTMSRT_Headerにおける(TotalTMSRT_entry_Number-1)と等しい値に達したかを判定する。#yが(TotalTMSRT_entry_Number-1)より小さい場合、AOB_ELEMENT#yは未だ、最後のAOB_ELEMENTに達してしていないので、ステップＳ４４からステップＳ３２に移行することにより、ステップＳ３２〜ステップＳ４２の処理を継続して行う。#yが(TotalTMSRT_entry_Number-1)に達した場合、最後のAOB_ELEMENTの1つ前のAOB_ELEMENTまで、AOB_FRAMEの読み出し処理は完遂したと考えられるので、ステップＳ４４がYesとなり、図５８のステップＳ４５に移行する。
【０１９５】
{52-9_57-2} ステップＳ４５〜ステップＳ５４の処理は、最後のAOB_ELEMENTに含まれる複数のAOB_FRAMEをそれぞれ読み出す処理であるという点において、上述したステップＳ３３〜ステップＳ４２の処理と同一といえる。異なるのは、ステップＳ３３〜ステップＳ４２におけるループ処理は、ステップＳ４１において#xが『FNs_Middle_TMSRTE』に達することがループ処理の終了条件であったのに対して、ステップＳ５３では、#xが『FNs_Last_TMSRTE』であり、かつ、これまで読み出されたデータサイズを示すPlay_dataがSZ_DATAに達することが、ループ処理の終了条件になっている点である。
【０１９６】
このステップＳ５３の条件が満たされるまで、ステップＳ４９〜ステップＳ５４の処理は繰り返し行われ、この条件が満たされれば、ステップＳ５３がYesとなって、ステップＳ５５に移行する。ステップＳ５５においてCPU１０は、#zをインクリメントしてからステップＳ２１に移行して（#z←#z+1）、次のAOBファイルがダブルバッファ１５に蓄積されるのを待つ。蓄積されれば、ステップＳ２１からステップＳ２２に移行し、次のAOBファイルについて、ステップＳ２２〜ステップＳ５４の処理を繰り返し行う。即ち、次のDPL_TK_SRPのDPL_TKINにより指定されているTKIを特定し、そのTKIに対応するAOBファイル、即ち、TKIと同じ番号を有するAOBファイルを特定する。その後、プロテクト領域をアクセスして、暗号鍵格納ファイルにおいて当該TKIと同じ番号を有するFileKeyを特定し、当該FileKeyを読み出して、当該FileKeyをデ・スクランブラに設定してから、そのTKIと同じ番号を有するAOBファイルに含まれるAOB_FRAMEを順次読み出して再生してゆくのである。
【０１９７】
{52-9_57-3_59} 再生経過時刻の更新
図５９は、液晶ディスプレィ５の時刻表示枠に表示される再生経過時刻が、変数Play_Timeの更新したがい、増加してゆく様子を示す図である。本図（ａ）では、再生経過時刻は00:00:00.000であるが、AOB_FRAME#1の再生が終了した時点で、再生経過時刻にAOB_FRAMEの時間長20msecが加算されて00:00:00.020に更新されている。AOB_FRAME#2の再生が終了した時点で、再生経過時刻にAOB_FRAMEの時間長20msecが加算されて00:00:00.040に、AOB_FRAME#6の再生が終了した時点で、再生経過時刻は00:00:00.120となっていることがわかる。
【０１９８】
以上がAOB_FRAME出力処理の全貌である。本フローチャートのステップＳ３１において、Playキー以外のキーの押下時に、本フローチャートの処理を中断することは既に述べた通りであり、そのようなPlayキー以外のキーとして一時停止キーや停止キーがあることも説明済みであるが、一時停止キーや停止キー以外にも、特殊再生を再生装置に行わせるためのキーが押下された場合も、図５６、図５７、図５８のフローチャートの処理は中断し、その押下されたキーに応じた処理が実行される。以降、>>キーが押下され、順方向サーチ再生を実行する場合のCPU１０の処理手順と、一時停止キーや停止キーが押下された後に、ジョグダイアルが操作されることにより、タイムサーチ機能が実行される場合のCPU１０の処理手順とについて説明する。
【０１９９】
{52-10_60} 順方向サーチ再生
図６０は、順方向サーチ再生を行う場合のCPU１０の処理手順を示すフローチャートである。>>キーが操作者により押下されて図５６、図５７、図５８のステップＳ３１、ステップＳ４２、ステップＳ５４がYesになった際、CPU１０により実行されるのが本フローチャートである。
【０２００】
ステップＳ６１において、CPU１０はAOB_ELEMENT#yのAOB_FRAME#xからx+f(t)-1までをデ・スクランブラ7に投入する。ここで、『t』とは、間欠再生時間であり、f(t)を、間欠再生時間に相当するフレーム数、d(t)を間欠再生時間に相当するデータ数とすると、ステップＳ６２では、再生経過時刻を示すplay_time、再生済みデータ数を示すplay_dataを、t:間欠再生時間、f(t):間欠再生時間に相当するフレーム数、d(t):間欠再生時間に相当するデータ数に基づいて更新する（x←x+f(t)、play_time←play_time+t、play_data←play_data+d(t) 尚、一般に間欠再生時間は240ミリ秒(12個のAOB_FRAMEの再生時間長)に相当する。）。
【０２０１】
{52-10_60-1_61A,B} 図６１（ａ）、（ｂ）は、順方向サーチ再生時において、再生経過時刻がインクリメントされてゆく様子を示す図である。図６１（ａ）は、再生経過時刻の初期状態を示し、再生時点は、AOB_ELEMENT#51のAOB_FRAME#1であることを示す。この場合の再生経過時刻は、00:00:01.000であることがわかる。ここで、間欠再生時間として、1番目から12番目までのAOB_FRAMEがデ・スクランブラ７に投入されて、再生経過時刻に1AOB_FRAMEの時間長である240ミリ秒が加算されると、図６１（ｂ）に示すように、再生経過時刻は、00:00:01.240となる。
【０２０２】
{52-10_60-2} これらを更新した後、ステップＳ６３においてCPU１０は、インクリメント後のAOB_FRAME#xと、AOB_ELEMENT#yの総フレーム数との大小比較して、インクリメント後のAOB_FRAME#xがAOB_ELEMENT#y内に存在するかを判定する。具体的には、AOBの先頭に位置するAOB_ELEMENTのフレーム数は『FNs_1st_TMSRTE』であり、中間のもののフレーム数は『FNs_Middle_TMSRTE』、最後のもののフレーム数は『FNs_Last_TMSRTE』に示されるので、これらと、AOB_FRAME#xとを比較することにより、判定を行う。もし更新後のAOB_FRAME#xがAOB_ELEMENT内に存在しないのなら、ステップＳ６４においてAOB_ELEMENT#yに後続するAOB_ELEMENTが存在するかを判定する。ここでAOB_ELEMENT#yが最後のAOB_ELEMENTであり、後続するAOB_ELEMENTが存在しない場合、ステップＳ６４がNoとなり、本フローチャートの処理を終了するが、後続するAOB_ELEMENTが存在する場合、ステップＳ６５において、AOB_FRAME#xからAOB_ELEMENT#yにおけるフレーム数を減じ、ステップＳ６６において#yを更新することにより（y←y+1）、AOB_FRAME#xを後続するAOB_ELEMENT#yにおけるAOB_FRAMEのフレーム位置に変換する。もし更新後のAOB_FRAME#xがAOB_ELEMENT内に存在するのなら、これらステップＳ６５〜ステップＳ６６をスキップして、ステップＳ６７に移行する。
【０２０３】
{52-10_60-3} 続いて、間欠スキップ間隔に応じて、AOB_FRAME#x、再生経過時刻play_time、再生済みデータ数play_dataの更新を行う。ここで、間欠スキップ間隔に相当する時間をskip_time(2秒)とし、間欠スキップ間隔skip_timeに相当するフレーム数をf(skip_time)、間欠スキップ間隔skip_timeに相当するデータ数d(skip_time)とすると、ステップＳ６７において、これらを用いてAOB_FRAME#x、再生経過時刻play_time、再生済みデータ数play_dataを更新する（x←x+f(skip_time),play_time←play_time+skip_time,play_data←play_data+d(skip_time)）。
【０２０４】
{52-10_60-4_61C} 図６１（ｃ）に示すように、AOB_ELEMENT#51内のフレーム位置を示すAOB_FRAME#xに間欠スキップ間隔を加算したものとする。この加算後の#xがAOB_ELEMENT#51のフレーム数を上回れば、AOB_ELEMENTを次のAOB_ELEMENTに更新すると共に、加算後の#xから、AOB_ELEMENT#51のフレーム数を減じることにより、AOB_FRAME#xを、AOB_ELEMENT#52におけるフレーム位置に変換する。この場合、AOB_ELEMENT#yがAOB_ELEMENT#52となり、再生経過時刻は、00:00:01.240に2.000を加算することにより、00:00:03.240となる。AOB_FRAME#xは、AOB_ELEMENT#52におけるAOB_FRAME#62(=(3240msec-2000msec)/20msec)となる。
【０２０５】
{52-10_60-5_61(d)} その後、AOB_ELEMENT#52におけるAOB_FRAME#62がデ・スクランブラ７に投入されれば、図６１（ｄ）に示すように再生経過時刻は、00:00:03.240に0.240を加算することにより、00:00:03.480となる。
ステップＳ６７において間欠的スキップ時間に応じた更新を行えば、ステップＳ６８〜ステップＳ７１の処理を行う。このステップＳ６８〜ステップＳ７１の処理は、ステップＳ６３〜ステップＳ６６の処理と同一であり、間欠スキップ間隔skip_timeに相当するフレーム数が加算された後のAOB_FRAMEがAOB_ELEMENT#y内に存在するかどうかの判定がなされて、存在するのなら、その次のAOB_ELEMENTをAOB_ELEMENT#yとし、AOB_FRAME#xを、新たなAOB_ELEMENT#yにおけるフレーム位置に変換する。
【０２０６】
間欠再生時間及び間欠的スキップ時間に応じて、AOB_FRAME#x、AOB_ELEMENT#yがインクリメントされれば、ステップＳ７２において、CPU１０は、TKTMSRTを参照してAOB_ELEMENT#yについての先頭アドレスを算出し、ステップＳ７３においてAOB_ELEMENT#yにおける先頭アドレスからADTSヘッダの探索を開始することにより、AOB_FRAME#xを検出する。そして、ステップＳ７４において、順方向スキップキー以外のキーが押下されたか否かを判定した後、ステップＳ６１においてAOB_ELEMENT#yのAOB_FRAME#xからx+f(t)-1までをデ・スクランブラ7に投入し、再度ステップＳ６２〜ステップＳ７３の処理を繰り返し行う。
【０２０７】
以上の処理にて、AOB_FRAME#x、AOB_ELEMENT#yがインクリメントされ、再生位置が進行してゆく。その後、操作者により再生キーが押下されれば、ステップＳ７４がNoとなり、本フローチャートの処理を終了する。
{52-11} タイムサーチ機能の実行
タイムサーチ機能が行われた場合の処理について説明する。Default_Playlist情報におけるトラックを一覧表示し、任意のトラックの指定を受け付ける。トラックが指定され、ジョグダイアルが操作されると、再生開始時刻を更新する。再生開始時刻が増減した後、再生キーが押下されると、その再生が指定された時刻をJmp_Entry(秒)と特定する。一方、指定されたトラックが複数のAOBからなるか、単一のAOBからなるかを判定する。単一のAOBからなる場合、｛数式２｝を満たすAOB_ELEMENT#yと、AOB_FRAME#xとを算出する。｛数式２｝を満たすAOB_ELEMENT#y、AOB_FRAME#xが算出されれば、このAOBに対応するTKTMSRTにおいて、y+2番目に位置するアドレスから、AOB_FRAME#xの探索を始め、x番目のAOB_FRAMEが探索されれば、このx番目のAOB_FRAMEから再生を開始する。
【０２０８】
{52-12}
複数のAOBからなる場合、｛数式３｝を満たすAOB#n、AOB_ELEMENT#yと、AOB_FRAME#xとを算出する。｛数式３｝を満たすAOB#n、AOB_ELEMENT#y、AOB_FRAME#xが算出されれば、このAOB#nに対応するTKTMSRTにおいて、y+2番目に位置するアドレスから、AOB_FRAME#xの探索を始め、x番目のAOB_FRAMEが探索されれば、このx番目のAOB_FRAMEから再生を開始する。
【０２０９】
続いてBITにおけるFNs_1st_TMSRTEは80フレームであり、FNs_Last_TMSRTEは50フレーム、FNs_Middle_TMSRTEが94フレームであるAOBにおいて、任意の再生時刻から再生を開始する場合について説明する。
{52-13_62A,B}
ここで、タイムサーチ機能が行われる場合の具体例として、ジョグダイアルにより、再生開始時刻が指定された場合に再生を開始すべきAOB_ELEMENT、再生を開始すべきフレーム位置をどのように特定するかについて説明する。図６２は、タイムサーチ機能が行われる場合の具体例を示す図である。ここで図６２（ａ）に示すように、再生装置が把持されて、あるAOBが再生対象として指定された状態で、その右手の親指により、ジョグダイアルの回転操作がなされ、 再生開始時刻=00:04:40.000(=280.00sec)が指定されたものとする。このAOBについてTKI内のBITが、図６２（ｂ）に示す内容である場合、再生開始時刻=00:04:40.000(=280.00sec)を｛数式２｝に適用すると、
280sec ＝(FNs_1st_TMSRTE＋FNs_middle_TMSRTE・y＋x)×20msec
＝( 80 + 94・148 + 8)×20msec
となるので、｛数式２｝を満たすAOB_ELEMENT#y、AOB_FRAME#xとして、y=148,x=8のAOB_FRAMEが得られる。
【０２１０】
このようにy=148と特定されたので、y+2番目のAOB_ELEMENT#150(=148+2)のエントリーアドレスをTKTMSRTから取得して、ここから8番目のAOB_FRAMEから、再生を開始すれば、 再生経過時刻=00:04:40.000(=280.00sec)から、再生を開始することができる。
{52-14_63_64_65}
以上でPlayキーが押下された場合の、CPU１０の処理内容の説明を終える。続いてROMに格納されている編集制御プログラムについて説明する。本編集制御プログラムは、Editキーが押下された場合に実行されるものであり、図６３、図６４、図６５にその処理手順を示す。以降、これらのフローチャートを参照しながら、編集制御プログラムの処理内容について説明する。
【０２１１】
{52-14_63-1} 編集制御プログラム
Editキーが押下されれば、図６３のステップＳ１０１において削除、分割、統合といった典型的な編集操作の何れを行うかを操作者に提示する対話画面を表示し、その後、ステップＳ１０２において、対話画面に対する処理が指定されたかを判定する。ここで対話画面の操作において、>>|キー、|<<キーをそれぞれ上下カーソル操作を受け付けるためのキー、即ち、上下カーソルキーとして用いるものとする。削除処理が指定されると、ステップＳ１０３、ステップＳ１０４からなるループ処理に移行する。ステップＳ１０３では、>>|キー、|<<キーが押下されたか否かを判定し、ステップＳ１０４では、編集キーが押下されたか否かを判定する。>>|、|<<キーが押下されれば、ステップＳ１０３からステップＳ１０５に移行して、指示されたトラックを編集対象として指定する。一方、編集キーが押下されれば、削除すべきトラックが特定されたとして、図４４に示した処理を行い、指定されたトラックについてのTKIのTKI_BLK_ATRを『Unused』に設定することにより、特定されたトラックを削除する。
【０２１２】
{52-14_63-2} 統合編集処理
統合編集が指定されると、ステップＳ１０２からステップＳ１０７〜ステップＳ１０９からなるループ処理に移行する。ステップＳ１０７〜ステップＳ１０９からなるループ処理では、>>|キー、|<<キーの押下と、編集キーの押下とを受け付ける。>>|｜、|<<キーが押下されれば、ステップＳ１０７からステップＳ１１０に移行して、指示されたトラックに対するハイライト表示を行う。編集キーが押下されれば、ステップＳ１０８がYesとなり、ステップＳ１１１に移行する。ステップＳ１１１では、カーソルキーにて指示されたトラックを、編集対象として指定し、再度、ステップＳ１０７〜ステップＳ１０９からなるループ処理に移行する。
【０２１３】
2トラック目の編集対象が特定されれば、ステップＳ１０９がYesとなって、ステップＳ１１２に移行する。ステップＳ１１２では、先行するトラック、後続するトラックについてのTKIのBITを参照することにより、両トラックの末尾及び先頭に配置されているAOB（その前後にもAOBが配されている場合は、その前後のAOB）のタイプがType1、Type2の何れであるかを判定する。
【０２１４】
各AOBのタイプが判明したのなら、ステップＳ１１３においてそれら各タイプのAOBの配置画像に示した何れの配置パターンに該当するかを判定する。図３２（ａ）〜（ｄ）の何れかの配置パターンに該当し、統合後においても、Type2AOBが3つ連続しないことが明らかならば、ステップＳ１１５において先行するトラック、後続するトラックを1つのトラックに統合する。即ち、これらに対応づけられたTKI、DPL_TK_SRPに対して、図４６に示した操作を行い、TKIのTKI_BLK_ATRを書き換えることにより、それら操作対象として選択された複数のトラックを1つのトラックに統合する。図３２（ａ）〜（ｄ）の何れの配置パターンにも該当せず、統合後にType2のAOBが3つ連続してしまう場合は、ステップＳ１１４において統合後のトラックにアンダーフローの発生の恐れがある旨を表示し、統合処理を中断する。
【０２１５】
{52-14_64-1} トラックの分割処理
トラックの分割が指定されると、ステップＳ１０２からステップＳ１１６〜ステップＳ１１７からなるループ処理に移行する。ステップＳ１１６〜ステップＳ１１７からなるループ処理では、>>|キー、|<<キーの押下と、編集キーの押下とを受け付ける。>>|｜、|<<キーが押下されれば、ステップＳ１１６からステップＳ１１８に移行して、指示されたトラックを編集対象として指定する。編集キーが押下されれば、ステップＳ１１７がYesとなり、ステップＳ１１９に移行する。ステップＳ１１９では、カーソルキーにて指示されたトラックを、編集対象として指定する。その後、ステップＳ１２０では、分割が指定されたトラックの再生を開始して、ステップＳ１２１においてMarkキーの押下を受け付ける。Markキーの押下が行われると、トラックの再生を一時停止し、ステップＳ１２２〜ステップＳ１２３からなるループ処理に移行する。ステップＳ１２２では、ジョグダイアルに対する回転操作を受け付け、ジョグダイアルに対して回転操作がなされると、ステップＳ１２４においてその回転操作に伴い、再生開始時間を増減させる。その後、ステップＳ１２２〜ステップＳ１２３からなるループ処理に再度移行する。回転操作により再生開始時刻が増減された状態で、編集キーが押下されれば、ステップＳ１２３からステップＳ１２５に移行し、ステップＳ１２５において、編集キーが押下された再生時間を分割境界として指定する（尚、分割境界の指定にあたっては、アンドゥ機能（編集の取り消し）が可能である。）。その後、ステップＳ１２６において図４７で説した処理を行い、DPLI、TKIを更新することにより、トラックの分割を行う。
【０２１６】
{52-14_65-1} プレイリストの設定編集処理
プレイリストの設定編集が指定されると、図６５のフローチャートに移行する。本フローチャートにおいて変数kとは、これから設定されるプレイリストにより、再生順序が規定される個々のトラックを指示するための変数であり、図６５のフローチャートでは、先ずステップＳ１３１においてこの変数kに1を設定した後、ステップＳ１３２〜ステップＳ１３４からなるループ処理に移行する。ステップＳ１３２〜ステップＳ１３４からなるループ処理では、>>|キー、|<<キーの押下と、編集キーの押下と、停止キーの押下とを受け付ける。>>|キー、|<<キーが押下されれば、ステップＳ１３２からステップＳ１３５に移行して、>>|キー、|<<キーにより指示されたトラックを指定する。編集キーが押下されれば、ステップＳ１３３がYesとなり、ステップＳ１３６に移行する。ステップＳ１３６では、編集キーにて指示されたトラックを、k番目に再生されるべきトラックとして特定する。その後、ステップＳ１３７において、変数kをインクリメントして、ステップＳ１３２〜ステップＳ１３４のループ処理に移行する。このような処理を繰り返すことにより、2トラック目、3トラック目、4トラック目のトラックが順次特定される。このようにして、新たに作成されたプレイリストにて再生されるべき複数のトラックが特定された状態で停止キーが押下されると、ステップＳ１３４からステップＳ１３８に移行して、これらに対応づけられたTKIを特定するPL_TK_SRPからなるPlayList情報を生成する。
【０２１７】
（記録装置）
{66-1} 記録装置
続いて、フラッシュメモリカード３１の記録装置についての一例を説明する。図６６は、フラッシュメモリカード３１の記録装置の一例を示す図である。本図における記録装置は、インターネットを介した通信が可能であり、電子音楽配信によりSD_Audioディレクトリィが暗号化された状態で通信回線を介して伝送されてくる場合、又は、電子音楽配信によりオーディオデータトランスポートストリームが配信されてくる場合にこれらを受信することができる汎用パーソナルコンピュータである。
【０２１８】
{67-1} 記録装置のハードウェア構成
図６７は、記録装置のハードウェア構成を示す図である。本図において記録装置は、フラッシュメモリカード３１を接続するためのカードコネクタ２１と、RAM２２と、記録装置の統合制御を行うための記録制御プログラムを格納した固定ディスク装置２３と、マイクから入力された音声をA/D変換して、PCMデータを得るA/Dコンバータ２４と、単位時間当たりのPCMデータをエンコードして、ADTSヘッダを付与することにより、AOB_FRAMEを得るACCエンコーダ２５と、各AOBファイル毎のFileKeyを用いて、AOB_FRAMEを暗号化するスクランブル部２６と、電子音楽配信によりSD_Audioディレクトリィが暗号化された状態で通信回線を介して伝送されてくる場合、又は、電子音楽配信によりオーディオデータトランスポートストリームが通信回線を介して伝送されてくる場合に、オーディオデータトランスポートストリームを受信するモデム装置２７と、記録装置内の統合制御を行うCPU２８と、操作者からの操作を受け付けるキーボード２９と、ディスプレィ３０とを有する。
【０２１９】
{67-2} 入力経路RT1〜RT4
電子音楽配信によりデータ領域及びプロテクト領域に書き込むべきSD_Audioディレクトリィが暗号化された状態で通信回線を介して伝送されてくる場合、記録装置はこれらを正当に受信した時点で、フラッシュメモリカード３１のデータ領域及びプロテクト領域に書き込めばよい。しかし、SD_Audioディレクトリィでは無く、電子音楽配信によりオーディオデータトランスポートストリームそのものが伝送されてくる場合、またPCMデータの状態で記録装置に入力されてくる場合、原音の状態で記録装置に入力されてくる場合、記録装置は、以下に示す4つの入力経路を経て、フラッシュメモリカード３１にオーディオデータトランスポートストリームを書き込むことなる。
【０２２０】
本図における記録装置がフラッシュメモリカード３１に、オーディオデータトランスポートストリームを格納する際、オーディオデータトランスポートストリームの入力経路には、図６７に示す入力経路RT1、入力経路RT2、入力経路RT3、入力経路RT4がある。
{67-3} 入力経路RT1
入力経路RT1は、電子音楽配信によりSD_Audioディレクトリィが暗号化された状態で通信回線を介して伝送されてくる場合、又は、オーディオデータトランスポートストリームが通信回線を介して伝送されてくる場合の入力経路であり、この場合、トランスポートストリームに含まれるAOB_FRAMEは、一個のAOBに属するもの毎に異なるFileKeyを用いて暗号化されている。暗号化済みのトランスポートストリームに対しては、再度の暗号化、符号化の必要は存在しないので、SD_Audioディレクトリィ又はオーディオデータトランスポートストリームは、暗号化された状態で、RAM２２に格納される。
【０２２１】
{67-4} 入力経路RT2
入力経路RT2は、マイクから音声が入力されてくる場合の入力経路である。この場合、A/Dコンバータ２４にマイクから入力された音声をA/D変換を行わせて、PCMデータを得る。そしてPCMデータのエンコードをAACエンコーダ２５に行わせて、ADTSヘッダを付与することにより、AOB_FRAMEを得る。その後、スクランブル部２６に各AOBファイル毎のFileKeyを用いて、AOB_FRAMEを暗号化を行わせることにより、暗号化がなされたオーディオデータを得る。その後、オーディオデータをRAM２２に格納する。
【０２２２】
{67-5} 入力経路RT3
入力経路RT3は、CDから読み出されたPCMデータが装置に入力されてくる場合の入力経路である。PCMデータの状態で入力されてくるので、当該PCMデータは、そのままAACエンコーダ２５に入力される。そのように入力されたPCMデータのエンコードをAACエンコーダ２５に行わせて、ADTSヘッダを付与することにより、AOB_FRAMEを得る。その後、スクランブル部２６に各AOB_FRAME毎のFileKeyを用いて、AOB_FRAMEを暗号化を行わせることにより、暗号化がなされたオーディオデータを得る。その後、オーディオデータはRAM２２に格納される。
【０２２３】
{67-6} 入力経路RT4
入力経路RT4は、3つの入力経路RT1,RT2,RT3において入力されたトランスポートストリームを、フラッシュメモリカード３１に書き込む際の入力経路である。
かかるオーディオデータの格納に伴い、TKI、Default_Playlist情報は生成される。再生装置の場合と同様、かかる記録装置の機能主体も、ROMに記録されている記録プログラムである。即ち、AOBの記録やTrackManager、PlayListManagerの記録といった本実施形態特有の処理は、固定ディスク装置に記録されている記録プログラムにより実現される。
【０２２４】
{67-7_68} 記録処理の処理手順
以降、フローチャートを参照しながら、上記入力経路RT1,RT2,RT3,RT4において、トランスポートストリームをフラッシュメモリカード３１に書き込む場合の記録処理の処理手順について説明する。図６８は、記録処理の処理手順を示すフローチャートである。本フローチャートにおいて引用する変数としては、Frame_Number、Data_Sizeといったものがある。Frame_Numberとは、これまでAOBファイルに記録されたAOB_FRAMEの総数を管理するための変数であり、Data_Sizeとは、これまでAOBファイルに記録されたAOB_FRAMEのデータサイズを管理するための変数である。
【０２２５】
本フローチャートが実行されると、ステップＳ２００においてCPU２８は、DefaultPlaylist,TrackManagerを作成し、ステップＳ２０１において、変数#z,#wを初期化する（z←1,w←1）。ステップＳ２０２では、AOBファイル#zを作成してフラッシュメモリカード３１におけるデータ領域に格納する。この状態で、データ領域におけるSD_Audioディレクトリのディレクトリエントリーには、AOBファイル#zのファイル名、ファイル拡張子、最初のクラスタ番号が設定されることになる。続くステップＳ２０３において、CPU２８は、TKI#zを作成してTrackManagerに格納し、ステップＳ２０４においてCPU２８は、DPL_TK_SRP#wを作成してDefaultPlaylist情報に格納する。以降ステップＳ２０５において変数#yを初期化し（y←1）、ステップＳ２０６において、Frame_Number、Data_Sizeのそれぞれを初期化する（Frame_Number←0、Data_Size←0）。
【０２２６】
ステップＳ２０７においてCPU２８は、AOBファイル#zに書き込むべき、オーディオデータトランスポートストリームの入力が終了したかを判定する。AACエンコーダ２５により符号化され、スクランブル部２６により暗号化されたオーディオデータトランスポートストリームが続々とRAM２２に格納されており、クラスタデータの書き込みを継続する必要がある場合、ステップＳ２０７がNoとなりステップＳ２０９に移行する。ステップＳ２０９においてCPU２８は、クラスタサイズ分のAACオーディオデータがRAM２２に蓄積したかを判定する。RAM２２にクラスタデータが蓄積した場合、ステップＳ２０９がYesとなり、ステップＳ２１０に移行して、RAM２２に蓄積されたクラスタサイズのAACオーディオデータをフラッシュメモリカード３１に書き込んだ後ステップＳ２１１に移行する。クラスタデータの蓄積が完了していない場合、ステップＳ２１０をスキップしてステップＳ２１１に移行する。ステップＳ２１１においてCPU２８は、Frame_Numberをインクリメントし(Frame_Number←Frame_Number+1)、Data_SizeをそのAOB_FRAMEのデータサイズだけインクリメントする。かかる更新を行った後、ステップＳ２１２においてFrame_Numberが、『FNs_Middle_TMSRTE』として定めているフレーム数に達したか否かを判定する。ここで『FNs_Middle_TMSRTE』は、オーディオデータトランスポートストリームが符号化された際のサンプリング周波数に応じた値となるので、Frame_Numberが、『FNs_Middle_TMSRTE』に達した場合は、ステップＳ２１２はYesとなるが、そうでない場合、ステップＳ２１２はNoになり、ステップＳ２０７に移行する。以降、ステップＳ２０７、ステップＳ２１２がYesとなるまで、ステップＳ２０７〜ステップＳ２１２は繰り返し行われる。
【０２２７】
Frame_Numberが『FNs_Middle_TMSRTE』に達してステップＳ２１２がYesとなった場合、ステップＳ２１２からステップＳ２１３に移行し、Data_SizeをAOB_ELEMENT#yについてのTMSRT_entry#yとしてTKI#zのTKTMSRTに格納してステップＳ２１４において#yをインクリメントした後（y←y+1）、ステップＳ２１５において変数yが252に達したか否かを判定する。ここで252という値は、一個のAOBに格納できるAOB_ELEMENTの総数を示す値であり、変数yが252に達しない場合、ステップＳ２１６に移行する。ステップＳ２１６では、無音状態が所定時間以上継続しており、オーディオデータがトラック間の境界に達したか否かを判定する。無音状態が存在しない場合、ステップＳ２０６〜ステップＳ２１５の処理を繰り返し行う。変数yが252に達した場合、又は、無音状態が所定時間以上継続した場合、ステップＳ２１５、ステップＳ２１６の何れか一方がYesとなり、ステップＳ２１７に移行して、変数#z,#wをインクリメントする（z←z+1,w←w+1）。その後、インクリメントされた#zについて、ステップＳ２０２〜ステップＳ２１６の処理を繰り返し行う。かかる繰り返しにより、複数のAOB_ELEMENTを含むAOBが次々とフラッシュメモリカード３１に書き込まれてゆく。
【０２２８】
ここで、AACエンコーダ２５、スクランブル部２６、モデム装置２７からのオーディオデータトランスポートストリームの伝送が終了した場合、AOBファイル#zに書き込むべき、オーディオデータトランスポートストリームの入力が終了したことになるので、ステップＳ２０７がYesとなり、ステップＳ２０８に移行する。ステップＳ２０８においてCPU２８は、Data_SizeをAOB_ELEMENT#yについてのTMSRT_entry#yとしてTKI#zのTKTMSRTに格納し、RAM22に蓄積されたオーディオデータをAOB#zに対応するAOBファイルに格納した後、本フローチャートの処理を終了する。
【０２２９】
以上の処理により、暗号化されたオーディオデータトランスポートストリームは、フラッシュメモリカード３１に格納されたことになるが、この暗号化を解除するためのFileKeyは、以下の処理により、プロテクト領域に格納される。
入力経路RT2,RT3の場合は、一個のAOBの符号化が開始される度に、CPU２８は異なるFileKeyを生成して、スクランブル部２６に設定し、そのFileKeyでスクランブル部２６に暗号化を行わせると共に、それらのFileKeyをプロテクト領域に存在する暗号鍵格納ファイルのFileKey Entry以降に格納する。
【０２３０】
一方入力経路RT1の場合は、AOBファイル、TKMGを格納したファイル、PLMGを格納したファイル、AOB毎の異なるFileKeyを格納した暗号鍵格納ファイルは、電子音楽配信のプロバイダより、送信される。CPU２８は、それらを受信して、AOBファイル、TKMGを格納したファイル、PLMGを格納したファイルをユーザデータ領域に書き込み、AOB毎の異なるFileKeyを格納した暗号鍵格納ファイルをプロテクト領域に書き込む。
【０２３１】
以上のように本実施形態によれば、AOBを格納したファイルは、それぞれ異なる暗号鍵にて暗号化されているので、1つのファイルを暗号化に用いられた暗号鍵が解読され、暴露されたとしても、その解読によって復号できるAOBは、1つのファイルに格納されているAOBだけであり、他のファイルに格納されたAOBには何の影響も及ぼさない。暗号鍵が暴露された場合の損失を最小限に抑える事ができる。
【０２３２】
なお、上記実施形態は現状において最善の効果が期待できるシステム例として説明したに過ぎない。本発明は、その要旨を逸脱しない範囲で実施変更することができる。具体的には、以下の（ａ）〜（ｆ）に示すような変更実施が可能である。
（ａ）本実施の形態では、記録媒体を半導体メモリ（フラッシュメモリカード）として説明を行ったが、これに限られるものではなく、DVD-RAMなどの光ディスクやハードディスクなどに置き換えることができる。
【０２３３】
（ｂ）本実施の形態では、音楽データとしてAACを使用したが、これに限られるものではなく、MP3（MPEG 1 Audio Layer 3）、Dolby-AC3、DTS（Digital Theater System）などであってもよい。
（ｃ）TKMGを格納したファイル、PLMGを格納したファイルのそのものを電子音楽配信にて配信するのではなく、TKMG,PLMGの元となる情報を、AOBファイル、AOB毎の異なる暗号鍵を格納した暗号鍵格納ファイルと共に配信し、記録装置において、このTKMG,PLMGの元となる情報を加工することによりTKMG,PLMGを得て、フラッシュメモリカードに記録しても良い。
【０２３４】
（ｄ）説明の便宜上、記録装置、再生装置をそれぞれ別装置としたが、携帯型再生装置に記録装置の機能を具備してもよいし、パソコン型の記録装置に再生装置の機能を具備させてもよい。また、これら携帯型再生装置、パソコン型記録装置以外にも、ネットワークからコンテンツをダウンロードすることができる通信機器に、これら再生装置、記録装置の機能を具備させてもよい。例えば、インタネットのアクセスが可能な携帯型電話機に、第１実施形態に示した再生装置、記録装置の機能を具備させ、携帯型電話機が無線ネットワークを介してダウンロードしたコンテンツを、第１実施形態に示したように、フラッシュメモリカード３１に格納しても良い。更に、本実施形態ではインターネットとの接続のために記録装置は、モデム装置２７を有していたが、これに替えて、ISDN回線との接続を行うためのターミナルアダプタ等を具備していてもよい。
【０２３５】
（ｅ）図５５〜図５８、図６０、図６３〜図６５、図６８のフローチャートを参照して説明した手順等を実行形式プログラムにより実現し、これを記録媒体に記録して流通・販売の対象にしても良い。このような記録媒体には、ICカードや光ディスク、フレキシブルディスク等があるが、これらに記録された機械語プログラムは汎用コンピュータにインストールされることにより利用に供される。この汎用コンピュータは、インストールした実行形式プログラムを逐次実行して、本実施形態に示した再生装置、記録装置の機能を実現するのである。
【０２３６】
（ｆ）本実施形態においてフラッシュメモリカード３１に複数のAOBと、複数のFileKeyとを格納させたが、フラッシュメモリカード３１に1つのAOBと、1つのFileKeyとを格納させてよい。また、AOBの暗号化を行わず、AAC方式のAOBをフラッシュメモリカード３１に格納させてもよい。
（第２実施形態）
第２実施形態は、第１実施形態に示したAOBファイルと共に、これらと共に表示すべき静止画をどのように格納するかという改良に関する。
【０２３７】
{69-1} 第２実施形態におけるフラッシュメモリカードの階層構造
図６９は、本実施形態に係るフラッシュメモリカード３１の階層構造を示す図である。第１実施形態の階層構造と異なるのは、第２実施形態では、プレゼンテーションデータにPOB群が新たに追加されており、ナビゲーションデータにPOBManagerが新たに追加されている点である。これらPOB群が、JPEG（Joint Photographic Experts Group）形式の静止画データであり、PlayListManager及びTrackManagerにより参照される。POBManagerは、これらPOBがPlayListManager及びTrackManagerによりどのように参照されるかが記述されている管理情報である。
【０２３８】
{69-1_70A-1}ファイルシステム層におけるユーザデータ領域の構成
新規な情報要素がプレゼンテーションデータ及びナビゲーションデータに追加されたので、ファイルシステム層におけるユーザデータ領域及びプロテクト領域の内部構成は、図７０（ａ）、（ｂ）のように改変されている。本図と、図８（ａ）に示した第１実施形態のユーザデータ領域とが異なるのは、POBXXX.JPG、POBXXX.SP1といったファイルが追加されており、POB000.POMというファイルが追加されている点である。
【０２３９】
POBXXX.JPG、POBXXX.SP1は、図６９に示したPOB群に対応するものであり、POB000.POMは、POBManagerに対応するものである。POBXXX.JPGと、POBXXX.SP1の違いは、著作権の有無の相違である。前者は、単にJPEG方式の静止画データを収録したファイルであるのに対して、後者は、静止画の著作権を保護するため、暗号化されている点である(その拡張子のSP1は"Secure Picture"の略であり、著作権保護の必要性があることはこれからも明らかである。)。ユーザが個人的に撮影した家族写真や記念写真等の静止画データは、専ら個人的な楽しみのもとでフラッシュメモリカードに記録するものであり、著作権の保護に神経を尖らせる必要はないので前者の形態でフラッシュメモリカードに格納しておけばよいが、電子音楽配信により配信されたアーティストの写真やイラストは、音楽コンテンツ同様、アーティストにより創作された創作物であり、ユーザがコピーすることにより、その著作権が侵害される恐れがあるので、後者の形態でフラッシュメモリカードに格納される。図中のPOBXXX.SP1及びPOBXXX.JPGに付されている001,002,003といった数値は、POBのそれぞれに割り当てられたPOB番号であり、複数のPOBはこれらPOB番号により一意に特定される。
【０２４０】
{69-2_70B-1}ファイルシステム層におけるユーザデータ領域の構成
図７０（ｂ）は、第２実施形態におけるプロテクト領域の構成を示す図である。プロテクト領域には、図８（ｂ）に示したプロテクト領域の構成と比較して、POBSP1.keyという暗号鍵格納ファイルが新規に追加されている。これは、図７０（ａ）におけるPOBXXX.SP1の暗号化を解除するためのFilekeyを格納したファイルであり、POBXXX.SP1を読み出す場合、このファイルからFilekeyを取り出さねばならない。
【０２４１】
電子音楽配信において音楽会社のサーバコンピュータは、この図７０（ａ）、（ｂ）に示すSD_Audioディレクトリを保持しており、当該音楽コンテンツの購入要求が消費者から発せられれば、このSD_Audioディレクトリを圧縮し、暗号化した後、購入要求を発した消費者にSD_Audioディレクトリを送信する。消費者が所有するコンピュータがこのSD_Audioディレクトリを受信すると、このディレクトリの暗号化を解除すると共に、伸長を行い、SD_Audioディレクトリを得る。尚、トラック(AOB)と、このトラックに対応する静止画(POB)とを音楽会社のサーバコンピュータからダウンロードし、消費者が所有するコンピュータが、フラッシュメモリカード３１においてこの図７０（ａ）、（ｂ）に示すSD_Audioディレクトリを作成しても良い。
【０２４２】
{69-3_71A,B,C-1} POBXXX.JPG、POBXXX.SP1の内部構成
続いて、POBXXX.JPG、POBXXX.SP1の内部構成について説明する。図７１（ａ）は、POBXXX.JPGの内部構成を示す図である。本図においてPOBXXX.JPGは、暗号化されていない静止画データを含んでおり、通常のJPEGファイルと同じファイル構成を有する。
【０２４３】
図７１（ｂ）は、POBXXX.SP1の内部構成を示す図である。本図に示すように、POBXXX.SP1はPOB_Header(POB_H)と、暗号化されたJPEG方式の静止画データとからなることがわかる。
破線の引き出し線hp1に、POB_Hの内部構成を示す。本図に示すように、POB_Hは、POBファイルの識別番号を示し、２バイト長の値"FFE0"に設定されるPOB_IDと、1バイト長の予約領域と、POBXXX.SP1に暗号化された実体部が存在するか、存在しないかを示す1バイト長のPOB_ATRと、POBのデータ長を示す4バイト長のPOB_SZとからなる。
【０２４４】
このPOBXXX.SP1には暗号化された実体部が存在するので、POB_ATRは『実体有り』を示す"0"に設定されているが、POBXXX.SP1に暗号化された実体部が存在せず、代わりに静止画データを格納しているファイルについてのファイルパスを格納しているものがある。図７１（ｃ）は、暗号化された実体部の代わりにファイルパスを格納したPOBファイルの一例を示す図である。『\DCIM\Ctg_001\photo001.JPG』の『photo001.JPG』は、デジタルスチルカメラにより撮影された静止画データを収録したファイルであり、そのファイルについてのファイルパスを示す。POBファイル内にこのようなディレクトリパス、ファイル名が指定されている場合、POBファイルにおけるこのような記載内容により、『\DCIM\Ctg_001\photo001.JPG』の『photo001.JPG』に収録されている静止画データは間接的に参照されることになる。このPOBXXX.SP1において、POBManagerにおけるPOB_ATRは『実体無し』を示す"1"に設定される。
【０２４５】
例えばデジタルスチルカメラにより撮影された静止画データを、特有のファイルに収録すること、当該ファイルを特有のディレクトリに格納することを、デジタルスチルカメラ専用のデバイスドライバがフラッシュメモリカードに要求している場合であっても(図７１（ｃ）の一例では、デジタルスチルカメラ専用のデバイスドライバは、\DCIM\Ctg_001\photo001.JPGに格納することを要求している)、図７１（ｃ）におけるPOBファイルは、当該参照先ファイルパスを介して、静止画データを収録したJPGファイルを指定するので、デジタルスチルカメラにより撮影された静止画データを、特有ファイル、特有ディレクトリに格納しつつも、そのような静止画を音楽コンテンツの再生と共に表示させることができる。
【０２４６】
以上で第２実施形態におけるプレゼンテーションデータについての説明を終える。
{72-1} PlayListManager及びTrackManagerについて
プレゼンテーションデータにおけるPOBXXX.JPG及びPOBXXX.SP1は、第１実施形態に示したトラックの再生と同期して表示される。トラックとの同期表示を実現するため第２実施形態におけるPlayListManager及びTrackManagerは、図７２に示す構成を有する。図７２は、第２実施形態におけるPlayListManager、TrackManagerの詳細構成を示す図である。本図と図１７に示した第１実施形態のPlayListManager、TrackManagerの構成とが異なるのは、図１７において明らかにされていなかったDefault Playlist General Infomation(DPLGI)、Playlist General Infomation(PLGI)の内部構成が明らかにされており、TKGIの内部構成に、TKI_POB_ATRと、20個のTKI_POB_SRPとが新規に設けられている点である。
【０２４７】
{72-2} DPLGIについて
デフォルトプレイリスト全体情報(DPLGI)は、破線の引き出し線h61に示すように、DPLIを一意に識別できるIDが記述されるDPLI_IDフィールドと、DPLIから参照されるトラック数が記述されるDPLI_TK_Nsフィールドと、デフォルトプレイリストから参照されるすべてのトラックの再生時間の総和がミリ秒の単位で記述されるDPLI_PB_TMフィールドと、DPLI_POB_ATRフィールドと、60個のDPLI_POB_SRPフィールドとからなる。
【０２４８】
{72-3} PLGIについて
プレイリスト全体情報(PLGI)は、破線の引き出し線h62に示すように、PLIを一意に識別できるIDが記述されるPLI_IDフィールドと、PLIから参照されるトラック数が記述でき、最大９９個のトラックを参照することができるPLI_TK_Nsフィールドと、ミリ秒の単位でプレイリストから参照されるすべてのトラックの再生時間の総和が記述されるPLI_PB_TMフィールドと、PLI_POB_ATRフィールドと、20個のPLI_POB_SRPフィールドとからなる。
【０２４９】
{72-4_73} 第２実施形態における追加改良点のまとめ
以上の説明からもわかるように、本実施形態においてTKGIには、TKI_POB_ATR、TKI_POB_SRPという2つの情報が追加されており、DPLGIにも、DPLI_POB_ATR−DPLI_POB_SRPという2つの情報、PLGIにも、PLI_POB_ATR−PLI_POB_SRPという2つの情報が追加されていることがわかる。TKI_POB_SRP、PLI_POB_SRP、DPLI_POB_SRPは何れも、共通の構成を有しておりPOBを指定することができる。図７３は、TKI_POB_SRP、PLI_POB_SRP、DPLI_POB_SRPにより、図７０に示したPOBファイルが指定されている状態を示す図である。以降、TKI_POB_ATR（DPLI_POB_ATR、PLI_POB_ATR）、TKI_POB_SRP（DPLI_POB_SRP、PLI_POB_SRP）のデータ構造について説明する。
【０２５０】
{74-1} TKI_POB_SRP
TKI_POB_SRPは、Default_Playlist情報、PlayList情報により指定された再生順序により再生が行われている時間帯のうち、特定のAOBが再生される再生期間に表示すべきPOBを指定するフィールドである。言い換えれば、TrackManagerはTKI_POB_SRPを設定することにより、トラック毎に表示すべきPOBを指定することができる。
【０２５１】
図７４は、TKI_POB_SRP、TKI_POB_ATRのデータ構造を示す図である。
本図においてTKI_POB_SRPは、ビット番号b25からビット番号b16までの『POB指定フィールド』と、ビット番号b11からビット番号b8までの『number of Pixel』フィールドと、ビット番号b7からビット番号b6までの『Huffman table』フィールドと、ビット番号b5からビット番号b4までの『Chominance sampling』フィールドと、ビット番号b3からビット番号b0迄を占める『Picture Coding Mode』フィールドと、ビット番号b12からビット番号b15、ビット番号b26からビット番号b31までの予約領域とからなる。
【０２５２】
『POB指定フィールド』は、このTKIに対応するAOBファイルが再生されている期間において、表示すべきPOBの番号（参照すべきPOBの番号）が1から999の範囲で記述されるフィールドである。このTKIに対応するAOBファイルが再生されている期間において、静止画を表示しない場合“0”が記述される。
『Picture Coding Mode』フィールドは、POB指定フィールドにて指定される静止画を表示する際、その静止画がどのような方式で符号化されているかを再生装置に通知するためのフィールドである。JPEG（Joint Photograph Expert Group）の場合、“0000b”の値が記述される。
【０２５３】
『Chominance sampling』フィールドは、POB指定フィールドで指定されている静止画を符号化した際、輝度成分、2つの色差成分のサンプリングがどのような比率で行われたかを示すフィールドである。輝度成分と、2つの色差成分との比率が4:2:2の比率である場合、00bitに設定され、4:2:0の比率である場合、01bitに設定される。
【０２５４】
『Huffman table』フィールドは、POB指定フィールドで指定されている静止画を表示する際、典型的なハフマンテーブルを用いるか否かを示すフィールドである。ハフマンテーブルを用いる場合、00bitに設定される。
『number of Pixel』フィールドは、POB指定フィールドにて指定された静止画データのイメージサイズが記述されるフィールドである。当該静止画データのイメージサイズが96×96の場合“0000b”の値が記述される。640×480の場合は、“0001b”、160×120〜1800×1200のイメージサイズであって、640×480以外のイメージサイズであれば“0010b”の値が記述される。
【０２５５】
TKGIは、以上のような構成を有するTKI_POB_SRPを20個有しているので、トラックの再生時に最大20枚の静止画を再生させることができる。尚、1つのトラックが複数のTKIから構成される場合、TKI_POB_SRPは先頭のTKIのみ有効となる。
{74-2} TKI_POB_ATR
『TKI_POB_ATR』は、TKGIにおける20個のTKI_POB_SRPにて指定されたPOBを、どのような態様で表示させるかを指定するために設けられている。TKI_POB_ATRは、ビット番号b0からビット番号b1迄を占めるDisplay order modeフィールドと、ビット番号b2からビット番号b3迄を占めるDisplay Timing modeフィールドとからなる。
【０２５６】
『Display order mode』フィールドは、TKGI内の20個のTKI_POB_SRPにて指定されているPOBをどのような順序で表示させるかが設定される。AOBの再生時間において、POBをどのように再生させるかには、3つの態様がある。1つ目の態様は、TKGI内の最大20個のTKI_POB_SRPにて指定されているPOBをTKGI内のTKI_POB_SRPの順序に従って表示する場合であり、これをシーケンシャルモードという。2つ目の態様は、TKGI内の20個のTKI_POB_SRPにて指定されているPOBを無作為に選んで再生するモードであり、これをランダムモードという。3つ目の態様は、重複を避けるようにTKGI内の20個のTKI_POB_SRPにて指定されているPOBを無作為に選んで再生するモードであり、シャッフルモードという。Display order modeフィールドは、シーケンシャルモードに設定される場合“00b”の値が設定される。一方ランダムモードに設定される場合“01b”、シャフルモードに設定される場合“10b”の値に記述される。
【０２５７】
『Display Timing mode』フィールドは、TKGI内の最大20個のTKI_POB_SRPにて指定されているPOBの表示と、TKIに対応づけられているAOBファイルの再生とを同期させるか否かが設定されるフィールドである。映像と音声とが同期しているモードをスライドショーモードといい、映像表示のみをスキップさせることはできない。一方、映像と音声とが同期していないモードをブラウザブルモードといい、映像表示のみをスキップさせることができる。
【０２５８】
以上のようにTKGIは、自身に対応するAOBファイルが再生されている期間において、どのPOBを表示させるか、それらPOBの表示をどのような順序で行うか、POBの表示と、TKIに対応づけられているAOBファイルの再生とを同期させるか否かが設定される。
{74-3_75} TKI#1〜TKI#3に含まれるTKI_POB_SRPの設定例
図７５は、TrackManagerに含まれるTKI#1〜TKI#3についてのTKI_POB_SRPの設定例を示す図である。第１段目は、TrackManagerを示し、第２段目は、9つのPOBファイルを示す。第１段目におけるTrackManagerは、8つのTKIを含み、矢印は、それらTKI内のTKI_POB_SRPがどのPOBファイルを参照しているかを示す。矢印に示される参照関係によると、TKI#1は3つのTKI_POB_SRPを含み、それら3つのTKI_POB_SRPはPOB001〜POB003を指定している。またTKI#2は3つのTKI_POB_SRPを含み、それら3つのTKI_POB_SRPはPOB004〜POB006を、TKI#3は3つのTKI_POB_SRPを含み、それら3つのTKI_POB_SRPはPOB007〜POB009を指定していることがわかる。
【０２５９】
本実施形態においてPOB001〜009には、無地の背景に、歌詞を示す文字列を配したJPEG画像データを用いるものとする。ここで歌詞の記述に用いられている文字列は、より歌詞のイメージに合うようなフォントにて描かれており、輪郭強調や装飾等が施されている。
図７５における最下段に、各POBの内容を示す。POB001〜POB003の内容は、TrackAの歌詞カード であり、POB004〜POB006の内容はTrackBの歌詞カード、POB007〜POB009の内容は、TrackCの歌詞カードである。これらは何れも各トラックが再生されている期間に再生しないと意味がないので、TKIに含まれるTKI_POB_SRPにより、各トラックが再生されている期間において再生されるよう設定されている。
【０２６０】
各トラックが再生されている期間は、第１実施形態において図１６に示した通りである。即ち、TKI#1に対応するAOB001.SA1の再生時間は6.1分、TKI#2に対応するAOB002.SA1の再生時間は3.3分、TKI#3に対応するAOB003.SA1の再生時間は5.5分なので、これらの期間において、TKIに設定されているTKI_POB_SRPの設定は有効となり、再生装置は、その有効なTKI_POB_SRPに従って、POBを表示することができる。
【０２６１】
TKI#1に対応するAOB001.SA1の再生時間は6.1分であり、この期間にPOB001〜POB003を均等に表示させるとすれば、一枚当りの表示時間は2.03分 ＝(6.1分/3)となる。TKI#2に対応するAOB002.SA1の再生時間は3.3分であり、再生装置はPOB004〜POB006の一枚当りの表示時間は1.1分 ＝(3.3分/3)、TKI#3に対応するAOB003.SA1の再生時間は5.5分でありPOB007〜POB009の一枚当りの表示時間は1.83分 ＝(5.5分/3)となる。
【０２６２】
{74-4_76} TKI#4〜TKI#8に含まれるTKI_POB_SRPの設定例
図７６は、TrackManagerに含まれるTKI#4〜TKI#8に含まれるTKI_POB_SRPの設定例を示す図である。第１段目は、TrackManagerを示し、第２段目は、10個のPOBファイルを示す。矢印に示される参照関係によると、TKI#4は図７６における7本の矢印に示される7つのTKI_POB_SRPを含み、それら7つのTKI_POB_SRPはそれぞれPOB010〜POB016を指定している。またTKI#8は3つのTKI_POB_SRPを含み、それらTKI_POB_SRPはPOB017〜POB019を指定していることがわかる。本実施形態においてPOB010〜019も、POB001〜009同様、無地の背景に、歌詞を示す文字列を配したJPEG画像データを用いるものとする。尚、TKI#4のみにTKI_POB_SRPが設定され、TKI#5〜#7にTKI_POB_SRPが設定されていないのは、上述したように1つのトラックが複数のTKIから構成される場合、TKI_POB_SRPは先頭のTKIのみ有効となるからである。
【０２６３】
POB010〜POB016の内容は、第１実施形態の図１６に示したTrackDの歌詞カード、POB017〜POB019の内容はTrackEの歌詞カードである。TKI#4〜TKI#7に対応するAOB004.SA1〜AOB007.SA1の再生時間は30.6分であり、POB010〜POB016の一枚当りの表示時間は4.37分 (＝30.6分/7)となり、これらの期間において、各POBを均等に表示させることができる。TKI#8に対応するAOB008.SA1の再生時間は7.0分であり、POB017〜POB019の一枚当りの表示時間は2.33分 (＝7.0分/3)となる。
【０２６４】
{77-1} DPLGIに含まれるDPLI_POB_SRP及びDPLI_POB_ATR
TKI_POB_SRPがトラック毎に、表示すべきPOBを指定することができるのに対して、DPLGIにおけるDPLI_POB_SRPは、Default_Playlist情報により指定された順序に従って、複数AOBが再生される時間帯において表示すべきPOBを指定するものである。図７７はDPLGIに含まれているDPLI_POB_SRP及びDPLI_POB_ATRを示す図である。DPLGIに含まれるDPLI_POB_SRP及びDPLI_POB_ATRもTKI_POB_SRP及びTKI_POB_ATRと同一のデータ構造を有していることは、この図７７からも明らかである。Default_Playlist情報は、複数AOBファイルの再生順序を規定するものなので、図７７におけるDPLI_POB_SRP及びDPLI_POB_ATRは、Default_Playlist情報により再生順序が規定されている複数のAOBファイルが再生されている期間において、どのPOBを表示させるか、それらPOBの表示をどのような順序で行うか、POBの表示と、TKIに対応づけられているAOBファイルの再生とを同期させるか否かを設定することができる。
【０２６５】
{77-2_78} 20個のDPLI_POB_SRPの設定例
図７８は、Default_Playlist情報に含まれる20個のDPLI_POB_SRPの設定例を示す図である。第１段目は、Default_Playlist情報を示し、それに含まれる枠はDPLGIと、20個のDPLI_POB_SRPとを示す。第２段目は、POB020〜POB039からなる20個のPOBファイルを示す。矢印に示される参照関係によると、20個のDPLI_POB_SRPはそれぞれPOB020〜POB039を指定している。
【０２６６】
POB020は、TrackA〜TrackEからなる音楽アルバムを記録したパッケージソフトのジャケットに使用されているイラストであり、POB021は、当該音楽アルバムをプロデュースした製作会社のロゴマーク、POB022〜POB025は、アーティストの肖像、POB026〜POB031は、プロモーションビデオのワンシーンであり、POB032〜POB039は、TrackA〜TrackEがコンサートで演奏された際に撮影された写真である。Default_Playlist情報におけるDPLI_POB_SRPは、音楽コンテンツを創作したものにより定義されるものなので、音楽コンテンツのトラックのイメージや、アーティストのタレントイメージにあったPOBを表示するよう指定されている。
【０２６７】
Default_Playlist情報にて再生順序が指定されているAOBファイルが再生されている期間において、このDPLGIに含まれるDPLI_POB_SRPにて指定されるPOBファイルが表示されることになる。例えば、図４０の一例では、Default_Playlist情報により8つのTKIを介して、TrackA〜TrackEという5つのトラックの再生順序が指定されていた。一方、図７８の一例においてDefault_Playlist情報に含まれるDPLI_POB_SRPにより、20個のPOBファイルが指定されているとすると、52.5分という再生時間においてこのDefault_Playlist情報によるDPLI_POB_SRPの指定は有効となる。更に、この52.5分という再生時間を、POB020〜POB039に均等に割り当てるとすると、一枚当りの表示時間は2.625分 ＝(52.5分/20)となる。
【０２６８】
{77-3_79} 再生時間の経過に伴う前景画−背景画の遷移
図７９は、Default_Playlist情報に含まれるDPLI_POB_SRPにて指定されたPOBを背景画とし、TrackManagerに含まれるTKI_POB_SRPにて指定されるPOBを前景画とした場合、これらがどのように合成されるかを示すタイミングチャートである。図７９の第１段目は、図７８の第２段目と同一のPOBを示すものであり、図７９の第２段目は、図７５、図７６の第２段目と同一のPOBを示すものである。本図の横方向は、1分を単位時間とした時間軸である。また本図のPOBの横幅は、各POBの再生がどれだけの間継続しているかを分単位で示す。
【０２６９】
本図の時間軸を参照すると、再生開始から6.1分までの期間において、POB001〜POB003(TrackAの歌詞カード)が前景画として、POB020、POB021(ジャケットイラストと製作会社のロゴマーク)、POB022(アーティストの肖像)が背景画として表示されることになる。
再生開始6.1分経過後から14.9(=6.1+3.3+5.5)分が経過するまでの期間において、POB004〜POB009(TrackB、TrackCの歌詞カード)が前景画として、POB022〜POB025(アーティストの肖像)が背景画として表示されることになる。
【０２７０】
再生開始14.9分経過後においてPOB010〜POB011(TrackDの歌詞カード)が前景画として、POB025(アーティストの肖像)、POB026〜POB028(プロモーションビデオのワンシーン)が背景画として表示される。
{77-4_80} 本タイミングチャートによれば、Default_Playlist情報の再生開始から6.1分経過後に、POB004を前景画(TrackBの歌詞)とし、POB022(アーティストの写真)を背景画とした合成映像が表示されることになる。図８０は、Default_Playlist情報の再生開始から6分経過後に、前景画、背景画がどのように合成されるかを示す図である。
【０２７１】
{77-5_81}またDefault_Playlist情報の再生開始から16分経過後には、POB010(TrackDの歌詞)を前景画とし、POB026(プロモーションビデオのワンシーン)を背景画とした合成映像が表示されることになる。図８１は、Default_Playlist情報の再生開始から16分経過後に、前景画、背景画がどのように合成されるかを示す図である。
【０２７２】
上記のように、Default_Playlist情報内のDPLI_POB_SRPにて指定されたPOBファイルと、TrackManagerにおけるTKI_POB_SRPにて指定されたPOBファイルとをそれぞれ前景画、背景画として合成して表示させれば、そのトラックについての歌詞ともに、そのトラックを作詞・作曲したアーティストの肖像や、プロモーションビデオ、コンサートシーン等を背景画として表示させることができる。また、どの時間帯にどのPOBファイルを表示させるかは、TrackManager、Default_Playlist情報におけるTKI_POB_SRP、DPLI_POB_SRPを書き換えることにより、容易に変更することができる
{82-1} PLGIに含まれるPLI_POB_SRP及びPLI_POB_ATR
PLGIに含まれているPLI_POB_SRP及びPLI_POB_ATRも、DPLGIに含まれるDPLI_POB_SRP及びDPLI_POB_ATR、TKIに含まれるTKI_POB_SRP及びTKI_POB_ATRと同一のデータ構造を有している。図８２はPLGIに含まれているPLI_POB_SRP及びPLI_POB_ATRを示す図である。PlayList情報は、Default_Playlist情報と異なり、ユーザが独自に定めた再生順序を規定するものなので、PLI_POB_SRP及びPLI_POB_ATRは、PlayList情報により再生順序が規定されている複数のAOBファイルが再生されている期間において、どのPOBを表示させるか、それらPOBの表示をどのような順序で行うか、POBの表示と、TKIに対応づけられているAOBファイルの再生とを同期させるか否かをユーザが自分の考えで設定することができる（尚、Default_Playlist情報のDPLI_POB_SRPを音楽会社が設定したというのは一例に過ぎず、Default_Playlist情報におけるDPLI_POB_SRPの設定もユーザが自由に設定しても良い。）。
【０２７３】
{82-2_83} PlayList情報に含まれるPLI_POB_SRPの設定例
続いて、PlayList情報に含まれるPLI_POB_SRPの設定例について説明する。
図８３は、PlayList情報に含まれる20個のPLI_POB_SRPの設定例を示す図である。第１段目は、PlayList情報を示し、それに含まれる枠はPLGIと、20個のPLI_POB_SRPとを示す。第２段目は、POB040〜POB059からなる20個のPOBファイルを示す。矢印に示される参照関係によると、20個のPLI_POB_SRPはそれぞPOB040〜POB059を指定している。
【０２７４】
POB020〜POB039が何れも音楽コンテンツの製作者が作成した静止画データであるのに対して、POB040〜POB059は何れもユーザの個人的な写真である。即ち、POB040は、ユーザの家族の写真であり、POB041は、ユーザの卒業写真、POB042〜POB045は、ユーザのペットの写真、POB046〜POB051は、ヨーロッパ旅行時の記念写真であり、POB052〜POB059は、アメリカ旅行時における記念写真である。尚、説明の簡略化を図るため、このPlayList情報にて再生順序が指定されるAOBファイルの総再生時間と、このPlayList情報により表示するよう指定されるPOBの数とは、Default_Playlist情報と同一とする。そうすると、このPlayList情報により指定されるTrackA〜TrackEの総再生時間は52.5分となり、POB040〜POB059をこの再生時間において、均等に表示させる場合は、一枚当りの表示時間は2.625分 ＝(52.5分/20)となる。
【０２７５】
{82-3_84} 再生時間の経過に伴う前景画−背景画の遷移
図８４は、Playlist情報に含まれるPLI_POB_SRPにて指定されたPOBを背景画とし、TrackManagerに含まれるTKI_POB_SRPにて指定されるPOBを前景画とした場合、これらがどのように合成されるかを示すタイミングチャートである。図８４の第１段目は、図８３の第２段目と同一のPOBを示すものであり、図８４の第２段目は、図７５、図７６の第２段目と同一のPOBを示すものである。本図の横方向は、1分を単位時間とした時間軸である。また本図のPOBの横幅は、各POBの再生がどれだけの間継続しているかを分単位で示す。
【０２７６】
本図において再生開始直後から6.1分が経過するまでの期間において、POB001〜POB003(TrackAの歌詞カード)が前景画として、POB040、POB041(家族写真と卒業写真)、POB042が背景画として表示されることになる。
6.1分経過後から14.9分が経過するまでの期間において、POB004〜POB009(TrackB、TrackCの歌詞カード)が前景画として、POB042〜POB045(ペットの写真)が背景画として表示されることなる。14.9分以降には、POB010〜POB011(TrackDの歌詞カード)が前景画として、POB045,POB046〜POB048(ヨーロッパ旅行時における記念写真)が背景画として表示されることになる。
【０２７７】
Default_Playlist情報に指定されていたPOBは、音楽コンテンツの製作会社が考えたものであり、音楽コンテンツのトラックのイメージや、アーティストのタレントイメージにあったPOBが指定されているのに対して、PlayList情報に指定されていたPOBは、ユーザが個人的に選んだものであり、ユーザ個人の思い入れが強いものとなっている。
【０２７８】
{82-4_85} 図８４によると、Playlist情報の再生開始から6.1分経過後に、POB004を前景画(TrackBの歌詞)とし、POB042(ペットの写真)を背景画とした合成映像が表示されることになる。図８５は、Playlist情報の再生開始から6.1分経過後に、前景画、背景画がどのように合成されるかを示す図である。
{82-5_86} Playlist情報の再生開始から16分経過後には、POB010(TrackDの歌詞)を前景画とし、POB046(ヨーロッパ旅行の写真)を背景画とした合成映像が表示されることになる。図８６は、Playlist情報の再生開始から16分経過後に、前景画、背景画がどのように合成されるかを示す図である。これらの合成画像における歌詞内容は、図８０、図８１と同一であるが、背景画が異なるため、見た印象は、図８０、図８１に示した合成画像と大きく異なっていることがわかる。
【０２７９】
上記のように、ユーザが独自に定義したPlayList情報内のPLI_POB_SRPに、Default_Playlist情報にて指定されたPOBファイルとは異なるPOBファイルを指定させることにより、ユーザは、自分の思い出のトラックの再生時に、その思い出にまつわる写真等を表示させることができる。
{82-6_87} Default_Playlist情報のDPLI_POB_SRPにおいて、共通のPOBを指定させた設定例
図７８、図７９、図８２、図８３の一例では、Default_Playlist情報に含まれる全てのDPLI_POB_SRPにそれぞれ異なるPOBファイルを指定させたが、Default_Playlist情報に含まれるDPLI_POB_SRPのうち、何れかのものに重複したPOBファイルを指定させれば、複数のトラックが再生されている期間において、共通のPOBファイルを表示させることにより、POBファイルの個数を少なくし、タイトル製作者の手間を削減することができる。図８７は、Default_Playlist情報における複数のDPLI_POB_SRPのうち、DPLI_POB_SRPに共通のPOBファイルを指定させることにより、POBファイルの数の削減を図った例である。本図において、DPLI_POB_SRP#1と、DPLI_POB_SRP#4とはPOB020を指定しており、DPLI_POB_SRP#2と、DPLI_POB_SRP#5とはPOB021を指定していることがわかる。
【０２８０】
{82-7_88} 再生時間の経過に伴う前景画−背景画の遷移
図８８は、Default_Playlist情報に含まれるDPLI_POB_SRPにて指定されたPOBを背景画とし、TrackManagerに含まれるTKI_POB_SRPにて指定されるPOBを前景画とした場合、これらがどのように合成されるかを示すタイミングチャートである。本タイミングチャートにおいて再生開始直後、7.875分経過後、15.75分経過後とにおいて、パッケージソフトのジャケットイラストを示すPOB020は繰り返し三回表示されていることがわかる。また再生開始から2.625分経過後、10.5分経過後、18.375分経過後において、製作会社のロゴを示すPOB021は繰り返し三回表示されていることがわかる。図８７のようにDPLI_POB_SRPを指定した場合、同一のPOBが繰り返し表示されるので、ジャケットイラストやロゴマーク等、POBの中に繰り返し表示すべきものが存在する場合に好適となる。
【０２８１】
以上長文となったが、TKGI、DPLGI、PLGIについての説明を終える。
{69-4_89} POBMGについて
第２実施形態において、ナビゲーションデータに追加された新規の情報要素であるPOBManagerについて説明する。図８９は、POBMGの内部構成を示す図である。本図に示すようにPOBMGは、POB管理情報(POBMGI)と、POB Count Information(POBCI)#1・・・・・・#nとからなる。
【０２８２】
{69-4_89-1} POBMGIについて
POB管理情報(POBMGI)は、破線の引き出し線に示すように、0バイト目から1バイト目迄を占めるPOBMGI識別情報と、2バイト目から3バイト目迄を占める予約フィールド(reserved)と、4バイト目から5バイト目迄を占めるPOB_Nsフィールドと、6バイト目から7バイト目までを占める予約フィールド(reserved)とからなる。
【０２８３】
POBMGI識別情報フィールドには、POBMGIを一意に識別できるIDが記述され（ISO646のキャラクタセットコード"A6"である。）、POB_Nsフィールドには、"0"から"999"までのPOBの数が記述される。以上で、POB管理情報(POBMGI)の説明を終わる。
{69-4_89-2} POBCIについて
次に、POB Count Information (POBCI)の説明を行う。POB Count Information (POBCI)は、POBのそれぞれに対応づけて設けられている管理情報である。そのビット構成は、破線の引き出し線に示す通りである。即ち、ビット番号b0からビット番号b9までを占めているPOB_RCNフィールドと、ビット番号b10からビット番号b13までを占めている予約領域フィールドと、ビット番号b14からビット番号b15迄を占めているdata existenceフィールドとからなる。
【０２８４】
{69-4_89-3} POB_RCNについて
『POB_RCN』フィールドは、POBCIにより対応づけられているPOBの表示がDPLGI、PLGI、TKGIにより指定されているか否かを示し、指定されている場合、その指定回数、即ち、表示が指定されている回数が1から999の範囲で記述される。第１実施形態で述べたように、TKIは削除可能であり、Default_Playlist情報、PlayList情報における再生順序の指定も自由に削除することができる。POB_refernce_countにおけるPOB指定数は、それに対応するPOBを指定していたTKIが削除された場合、削除されたTKI数だけデクリメントされる。またDefault_Playlist情報、PlayList情報が削除された場合も、削除されたTKI数だけデクリメントされる。DPLGI、PLGI、TKGIにより表示が指定されていない場合POB_refernce_countは0となる。POB_refernce_countが0となったPOBは何れのTKI、PlayList情報からも参照されないPOBであるので、再生装置は、TKI、PlayList情報の削除が行われる度に、このrefernce_count_numberが0となったPOBを検出し、refernce_count_numberが0となったPOBを収録しているPOBファイルを削除することにより、フラッシュメモリカードにおいて格納される静止画データ数を削減することができる。複数のPOBのうち、特定のPOBが特定のトラックのみと密接な関係を有しているものであり、そのトラックと同期して再生されないのではそのPOBをフラッシュメモリカードに格納しておく意味が存在しない場合（例えば、フラッシュメモリカードに格納されているトラックの歌詞を示す静止画が静止画データとして格納されているようなケースがこれに該当する）、refernce_count_numberに基づいて、削除を行うことにより、フラッシュメモリカードに余分なPOBを格納しておくという無駄がなくなる。尚、TKIが削除されるケース以外にも、DPLI_POB_SRP,PLI_POB_SRP,TKI_POB_SRPにて指定されているPOBが編集作業により削除された場合にも、同様のrefernce_count_numberのデクリメントを行っても良い。
【０２８５】
{69-4_89-4} data existenceについて
ビット番号b14からビット番号b15迄を占めているdata existenceフィールドには、このPOB番号に対応するPOBが存在するか否かが指定される。POB番号に対応するPOBが存在する場合、01bに設定され、POBが存在しない場合、00bが設定される。POBが存在すると指定されている場合、TKI、PlayList情報の削除が行われてたとえPOB_refernce_countが0になったとしても、当該POB_refernce_countに対応するPOBはフラッシュメモリカードに格納しておく価値があるとみなしてPOBの削除はなされない。TKI、PlayList情報により参照されているか否かに拘らず、POB単独でも保存価値がある場合、そのPOBに対応するdata existanceを1に設定し、TKI、PlayList情報により参照されていなければ、保存価値が無いようなPOBは、そのPOBに対応するdata existanceを0に設定することにより、保存価値のあるPOBは、フラッシュメモリカードに残しておくことができる。その一方、トラックと一体となって初めて保存価値があるようなPOBは、トラックの削除と共に削除することにより、フラッシュメモリカードの格納容量を有効利用することができる。
【０２８６】
以上で、POBManager(POBMG)の説明を終わる。
{69-5} TKIの編集時における更新
第１実施形態において述べた4つの編集ケース、一部のトラックが削除された場合(case1)、複数のトラックのうち、任意の2つを1つのトラックに統合する場合(case3)、1つのトラックを分割して、2つのトラックを得る場合(case4)、トラックの順番を入れ替えた場合(case5)において、TKI_POB_SRP及びDPLI_POB_SRPがどのように更新されるかについて説明する。
【０２８７】
トラックが削除された場合(case1)、第１実施形態に示したよう、そのTKIについてのTKI_BLK_ATRを『Unused』に設定すると共に、そのTKIにおけるTKI_POB_SRPを削除する。それと共に、そのTKI_POB_SRPにより指定されていたPOBに対応するPOBManagerにおけるPOB_refernce_countをデクリメントする。DPLGI、PLGIにおけるPLI_POB_SRP、DPLI_POB_SRPにて指定されていたPOBについては、その削除によっても、変化はない。
【０２８８】
DPL_TK_SRPにて指定されたトラックの順序が入れ代わった場合(case5)、トラックの順序が入れ代わるので、TKI_POB_SRPにて指定されたPOBの表示順序は入れ替え後の順位となる。
トラックの統合(case3)については、TKIにおけるTKI_POB_SRPも統合させるのが望ましい。何故なら、上述したように1つのトラックが複数のTKIから構成される場合、TKI_POB_SRPは先頭のTKIのみ有効となるので、トラックの統合操作により後半のTKIのTKI_POB_SRPにて指定されているPOBを、前半のTKIのTKI_POB_SRPに指定させる必要があるからである。
【０２８９】
また、トラックの分割時(case4)においては、TKIのTKI_BLK_ATRを変更し、TKTMSRT、BITを2つに分割する必要があるのは、第１実施形態に説明した通りであるが、それと同様に、TKGIにて指定されている複数のTKI_POB_SRPを2つに分割して、元のTKIと、分割により得られたTKIとに分配させてもよい。
{69-6}TKI_POB_SRP、DPLI_POB_SRP設定の応用例
以上の説明したTrackManager、PlayListManagerのデータ構造では、AOBファイルとPOBとの対応づけを、TKI_POB_SRP、DPLI_POB_SRP、PLI_POB_SRPの設定により自由に変化させることができるので、音楽コンテンツの提供者は、歌詞がないタイプ、歌詞があるタイプ、歌詞と背景画とがあるタイプ等、付随している静止画データの多少に応じて、価格が異なる複数の音楽コンテンツを消費者に販売することができる。
【０２９０】
歌詞がないタイプの購入を消費者が希望した場合、第１実施形態に示した8つのAOBファイルと、図７８に示したPOB020〜POB039をTKI#1〜TKI#8におけるTKI_POB_SRPに指定させたTrackManagerとを含むSD_Audioディレクトリを作成して、これを圧縮した後、消費者が所有する汎用パーソナルコンピュータに送信する。尚、トラック(AOB)と、このトラックに対応する静止画(POB)とを音楽会社のサーバコンピュータからダウンロードし、消費者が所有するコンピュータが、フラッシュメモリカード３１においてこの図７０（ａ）、（ｂ）に示すSD_Audioディレクトリを作成しても良い。
【０２９１】
歌詞があるタイプの購入を消費者が希望した場合、第１実施形態に示した8つのAOBファイルと、図７５、図７６に示した歌詞に対応するPOB001〜POB019をTKI#1〜TKI#8におけるTKI_POB_SRPに指定させたTrackManagerとを含むSD_Audioディレクトリを作成して、これを圧縮した後、消費者が所有する汎用パーソナルコンピュータに送信する。
【０２９２】
歌詞と背景画とがあるタイプの購入を消費者が希望した場合、第１実施形態に示した8つのAOBファイルと、歌詞に対応するPOB001〜POB019をTKI#1〜TKI#8におけるTKI_POB_SRPに指定させたTrackManagerと、図７８に示したPOB020〜POB039をDPLI_POB_SRPに指定させたPlayListManagerとを含むSD_Audioディレクトリを作成して、これを圧縮した後、消費者が所有する汎用パーソナルコンピュータに送信すればよい。
【０２９３】
本実施形態では、TKI_POB_SRP、DPLI_POB_SRP、PLI_POB_SRPの設定によりオーディオデータに任意の静止画データを付随させることができるので、付随する静止画データの多少に応じて、価格帯の異なる音楽コンテンツを簡易に作成することができる。
{90-1_91} 第２実施形態に係る再生装置について
続いて、第２実施形態に係る再生装置について説明する。第２実施形態に係る再生装置が第１実施形態のものと異なる点は、大きく3つある。そのうち第１の差違点は、第１実施形態における再生装置が携帯型であるのに対して、第２実施形態における再生装置が車載型である点である。図９０は、第２実施形態に係る再生装置がどのように用いられるかを示す図であり、図９１は、第２実施形態に係る再生装置本体のみの外観を示す図である。本図において、第２実施形態に係る再生装置が第１実施形態の再生装置と異なるのは、第２実施形態に係る再生装置は、図９０に示すように自動車の車内に設置されており、大型の液晶ディスプレィ５と、車載スピーカーとに接続されている点である。再生装置に接続されている液晶ディスプレィ５が大型なので、第２実施形態における再生装置は、上述した各種静止画データを好適に表示することができる。
【０２９４】
第２の差違点は、第２実施形態におけるデ・スクランブラ７は、オーディオデータの暗号化を解除する以外にもPOBの暗号化を解除する点である。即ち、POBファイルがPOBXXX.SP1であり、収録されているPOBが暗号化されている場合、デ・スクランブラ７には、プロテクト領域における暗号鍵格納ファイルPOBSP1.KEYのKey Entryに格納されているFilekeyが設定され、POBXXX.SP1における暗号化を解除する。 最後に、第３に異なるのは、第２実施形態におけるROM４に、POBを前景画又は背景画として表示する処理内容を記載したプログラムが格納されており、これに基づいて、CPU１０が画面表示を行う点である。
【０２９５】
{90-2_92_93_94}
続いて、第２実施形態に係る再生装置の内部構成について説明する。図９２に示した再生装置の内部構成が、第１実施形態と異なるのは、複数のVRAM６１が設けられている点である。
複数のVRAM６１は、それぞれが一枚のグラフィックスプレーン0に対応しているVRAMからなる。各グラフィックスプレーンのVRAMは、各画素毎に0%〜100%の透過率αが設定され、液晶ディスプレィ５に表示されるべき画像の画素値は以下の式により算出される。図９３（ａ）は、複数のVRAM６１に格納された静止画がどのように重ね合わせられるかを示す図である。
各画素の画素値 = グラフィックスプレーン0の画素値×(1-α) ＋ グラフィックスプレーン1の画素値×α
前景画側において歌詞を表す文字の部分は、透過率が0%に設定される。従って、グラフィックスプレーン1に記憶されている背景画は、一切画面上に現れない。前景画において無地の背景部分は、透過率が100%に設定される。従ってグラフィックスプレーン0における静止画の無地の部分にグラフィックスプレーン１に記憶されている背景画がはめ込まれることなる。このように透過率αを設定すれば、歌詞が記載された透明シートを背景画に被せたような、合成画像、即ち、図８０、図８１に示したような合成画像を得ることができる。
【０２９６】
尚、図９３（ａ）に示したような合成画像以外にも、例えば図９３（ｂ）に示すように、歌詞を下半分に配し、背景画に上半分に配した合成画像を表示しても良い。
{94-1} 前景画表示処理についてのフローチャート
図９４は、前景画表示処理についての処理手順を示すフローチャートである。Default_Playlist情報が指定されTKI#zに基づいた再生が開始されると、ステップＳ４０２において、CPU１０は当該TKIに含まれるTKGIに含まれるTKI_POB_SRPがPOBファイルを指定しているか否かを判定する。TKI_POB_SRPがPOBファイルを指定している場合、ステップＳ４０３においてCPU１０は、TKGIに含まれるTKI_POB_SRPが何枚のPOBファイルを指定しているかを計数する。ステップＳ４０４においてPOBファイルの枚数に基づいて、POBファイル一枚当たりの表示時間POB_timeを決定する。続いて、ステップＳ４０５においてCPU１０は、TKGIにおけるTKI_POB_ATRを参照して、各POBファイルをどのような表示モードで表示させるかを決定する。TKI_POB_ATRがシーケンシャルモードと記載されているなら、ステップＳ４０５からステップＳ４０６に移行して変数iを初期化し、ステップＳ４０７において、i番目のTKI_POB_SRPにて指定されているPOBファイルを表示時間POB_timeだけ表示する。この際、TKI_POB_SRPで指定されているPOBファイルの拡張子がJPGであるなら、当該POBをそのまま表示する。TKI_POB_SRPで指定されているPOBの拡張子がSP1であり、暗号化されているのなら、これに対応するFilekeyをプロテクト領域から読み出して、当該POBの暗号化を復号した上で、当該POBを表示する。その後、ステップＳ４０８では、変数iがPOB_Nsに達したかを判定し、達していないならステップＳ４０９において変数iをインクリメントして、ステップＳ４０７に移行する。以降、変数iがPOB_Nsに達するまで、ステップＳ４０６〜ステップＳ４０９を繰り返し行う。これにより、TKGIのTKI_POB_SRPにて指定されるPOBが順次表示されてゆく。変数iがPOB_Nsに達した場合、本フローチャートの処理を終了する。
【０２９７】
TKI_POB_ATRがランダムモードと記載されているなら、ステップＳ４１０において変数iを初期化した後、ステップＳ４１１において1からPOB_Nsまでの範囲の乱数rを発生して、ステップＳ４１２において乱数rに相当するr番目のTKI_POB_SRPにて指定されているPOBファイルをステップＳ４０４において決定された表示時間POB_timeだけ表示する。その後、ステップＳ４１３において変数iがPOB_Nsに達したかを判定し、達していないならステップＳ４１４において変数iをインクリメントして、ステップＳ４１１に移行する。当該表示を終えると、ステップＳ４１１において1からPOB_Nsまでの範囲の乱数rを再度発生して、ステップＳ４１２において乱数rに相当するr番目のTKI_POB_SRPにて指定されているPOBファイルを読み出して、ステップＳ４０４において決定された表示時間POB_timeだけ表示する。この際、シーケンシャルモードの場合と同様に、TKI_POB_SRPで指定されているPOBファイルの拡張子がJPGであるなら、当該POBをそのまま表示する。TKI_POB_SRPで指定されているPOBの拡張子がSP1であり、暗号化されているのなら、これに対応するFilekeyをプロテクト領域から読み出して、当該POBの暗号化を復号した上で、当該POBを表示する。
【０２９８】
以降、変数iがPOB_Nsに達するまで、ステップＳ４１１〜ステップＳ４１４を繰り返し行う。これにより、TKGIのTKI_POB_SRPにて指定されるPOBがランダムな順序で表示されてゆく。変数iがPOB_Nsに達した場合、本フローチャートの処理を終了する。
TKI_POB_ATRがシャッフルモードと記載されているなら、ステップＳ４０５からステップＳ４１５に移行して、ステップＳ４１５において変数iを初期化した後、ステップＳ４１６において1からPOB_Nsまでの範囲の乱数rを発生し、その後、ステップＳ４１８では、発生した乱数rと、表示済みPOB番号とが一致するか否かを判定する。一致するなら、ステップＳ４１６に移行して、再度乱数を発生する。一致しないのなら、ステップＳ４１８からステップＳ４１９に移行して、乱数rに相当するr番目のTKI_POB_SRPにて指定されているPOBファイルをステップＳ４０４において決定された表示時間POB_timeだけ表示する。この際、シーケンシャルモード、ランダムモードの場合と同様に、TKI_POB_SRPで指定されているPOBファイルの拡張子がJPGであるなら、当該POBをそのまま表示する。TKI_POB_SRPで指定されているPOBの拡張子がSP1であり、暗号化されているのなら、これに対応するFilekeyをプロテクト領域から読み出して、当該POBの暗号化を復号した上で、当該POBを表示する。当該表示を終えると、ステップＳ４１７において変数rを表示済みPOB番号として格納する。その後、ステップＳ４２０において変数iがPOB_Nsに達したかを判定し、達していないならステップＳ４２１において変数iをインクリメントして、ステップＳ４１６に移行する。以降、変数iがPOB_Nsに達するまで、ステップＳ４１６〜ステップＳ４２１を繰り返し行う。これにより、TKGIのTKI_POB_SRPにて指定されるPOBが順次表示されてゆく。変数iがPOB_Nsに達した場合、本フローチャートの処理を終了する。
【０２９９】
{95-1} 背景画表示処理についてのフローチャート
前景画表示処理についての説明を以上で終え、続いて背景画表示処理の処理手順について説明する。図９５は、背景画表示処理の処理手順を示すフローチャートである。本フローチャートは、図９４において『TKGIのTKI_POB_SRP、TKI_POB_ATR』に基づいて行われていた処理を『DPLGIのDPLI_POB_SRP、DPLI_POB_ATR』に置き換えたものであり、基本的な処理手順は、図９４のフローチャートと同一である。
【０３００】
Default_Playlist情報が選択されると、ステップＳ４０２〜Ｓ４０５の場合と同様、ステップＳ５０２〜Ｓ５０５においてCPU１０は、当該DPLGIに含まれるDPLI_POB_SRPがPOBファイルを指定しているか否かを判定し、指定している場合、何枚のPOBファイルを指定しているかを計数して、POBファイル一枚当たりの表示時間POB_timeを決定し、またDPLI_POB_ATRに従って、どの表示モードで表示させるかを決定する。DPLI_POB_ATRがシーケンシャルモードと記載されているなら、ステップＳ４０６〜ステップＳ４０９の場合と同様、ステップＳ５０６〜ステップＳ５０９において、変数iに従って、DPLGIに含まれるDPLI_POB_SRPに従い、POBファイルを順次表示してゆく。
【０３０１】
DPLI_POB_ATRがランダムモードと記載されているなら、ステップＳ４１０〜ステップＳ４１４の場合と同様、ステップＳ５１０〜ステップＳ５１４において、変数rに従って、DPLGIに含まれるDPLI_POB_SRPに従い、POBファイルを順次表示してゆく。
DPLI_POB_ATRがシャッフルモードと記載されているなら、ステップＳ４１５〜ステップＳ４２１の場合と同様、ステップＳ５１５〜ステップＳ５２１において、変数rに従って、DPLGIに含まれるDPLI_POB_SRPに従い、POBファイルを順次表示してゆく。
【０３０２】
{96-1}背景画表示処理についてのフローチャート
DPLGIのDPLI_POB_SRPを参照した場合の前景画表示処理についての説明を以上で終え、続いてPLGIのPLI_POB_SRPを参照する場合の背景画表示処理の処理手順について説明する。図９６は、背景画表示処理の処理手順を示すフローチャートである。本フローチャートは、図９５において『DPLGIのDPLI_POB_SRP、DPLI_POB_ATR』に基づいて行われていた処理を『PLGIのPLI_POB_SRP、DPLI_POB_ATR』に置き換えたものであり、前景画と基本的な処理手順は、図９５のフローチャートと同一なので、同一の参照符号を付して、詳細な説明は省略する。
【０３０３】
{94-2_95-2_97A,B,C} 液晶ディスプレィ５における表示例
図９４、図９５のフローチャートに示す処理手順により、TKI_POB_SRPにて指定された前景画、DPLGIにより指定された背景画が合成された場合に、どのような合成画像が液晶ディスプレィ５に表示されるかを図９７（ａ）〜（ｃ）に示す。
【０３０４】
図９７（ａ）に示すように、Default_Playlist情報が指定され、これに記載された再生順序に従い、POBの表示が開始されたとする。この場合、図９４のフローチャートに示す前景画表示処理と、図９５のフローチャートに示す背景画表示処理とが行われて、TKGIに含まれる複数のTKI_POB_SRPより表示が指定されたPOB、DPLGIに含まれる複数のDPLI_POB_SRPより表示が指定されたPOBが順次表示されてゆく。そのため再生開始から6分経過後に図８０に示した画像合成が行われ、液晶ディスプレィ５には、図９７（ｂ）に示す合成画像が表示される。
【０３０５】
また再生開始から16分経過後に図８１に示した画像合成が行われ、液晶ディスプレィ５には、図９７（ｃ）に示す合成画像が表示される。
{94-2_96-1_98A,B,C} 液晶ディスプレィ５における表示例
図９４、図９６のフローチャートに示す処理手順により、TKI_POB_SRPにて指定された前景画、PLI_POB_SRPにて指定された背景画が合成された場合に、どのような合成画像が液晶ディスプレィ５に表示されるかを図９８（ａ）〜（ｃ）に示す。
【０３０６】
図９８（ａ）に示すように、PlayList情報が指定され、これに記載された再生順序に従い、POBの表示が開始されたとする。この場合、図９４のフローチャートに示す前景画表示処理と、図９６のフローチャートに示す背景画表示処理とが行われて、TKGIに含まれる複数のTKI_POB_SRPより表示が指定されたPOB、PLGIに含まれる複数のPLI_POB_SRPより表示が指定されたPOBが順次表示されてゆく。そのため再生開始から6分経過後に図８５に示した画像合成が行われ、液晶ディスプレィ５には、図９８（ｂ）に示す合成画像が表示される。また再生開始から16分経過後に図８６に示した画像合成が行われ、液晶ディスプレィ５には、図９８（ｃ）に示す合成画像が表示される。
【０３０７】
{99_1}第２実施形態に係る記録装置
続いて、第２実施形態に係る記録装置について説明する。第２実施形態に係る記録装置が新規なのは、複数のPOBをフラッシュメモリカード３１に記録すると共に、TKI_POB_SRP、DPLI_POB_SRP、PLI_POB_SRPを設定する点、また、TKI_POB_ATR、DPLI_POB_ATR、PLI_POB_ATRを設定する点である。こうした一連の処理は、第２実施形態に係るCPU１０が図９９のフローチャートに記載された手順を経ることによりなされる。以降、図９９のフローチャートを参照しながら、第２実施形態に係る記録装置の記録処理について説明する。
【０３０８】
ステップＳ６０１において、CPU１０は本フローチャートで用いられる各変数の初期化を行う。本フローチャートで用いられる変数には、変数#x、#y、#z、#u、#vy、#wがある。#xは、複数のPOBのうち処理対象となるPOBを特定する変数であり、#yは、複数トラックシーケンスのうち処理対象となるトラックシーケンス(PLI)を特定する変数、#zは、複数トラックのうち処理対象となるトラック(TKI)を特定する変数である。
【０３０９】
#uは、複数のDPLI_POB_SRPのうち、処理対象となるDPLI_POB_SRPを特定する変数であり、#vyは、#yにて指示されるPLI（PLI#y）に含まれる複数PLI_POB_SRPのうち、処理対象となるPLI_POB_SRPを特定する変数である。#wは、#zにて指示されるTKI#y）に含まれる複数TKI_POB_SRPのうち処理対象となるTKI_POB_SRPを特定する変数である。
【０３１０】
これらの変数が初期化されると、ステップＳ６０２においてPOB#xを表示する。これにより、操作者は、POBがどのような写真、イラスト、歌詞であるかを視覚的に確認することができる。ステップＳ６０３においてPOB#xは、トラックシーケンスが再生される全時間帯を通じて表示させるべき静止画データであるか、特定のトラックが再生される時間帯にのみ表示させるべき静止画データであるかという選択を操作者から仰ぎ、何れかの選択を受け付ける。
【０３１１】
『POB#xをトラックシーケンスに割り当てるべき』と操作者が判断した場合、ステップＳ６０４においてPOB#xを表示させるべきトラックシーケンスの選択待ちを行い、もし選択がなされれば、ステップＳ６０５においてそのトラックシーケンス#yを指定しているプレイリストはDPLIであるか、PLIであるかを判定する。そのプレイリストがDPLIならばステップＳ６０６においてDPLIにおけるDPLI_POB_SRP#uにPOB#xを設定し、ステップＳ６０７においてDPLIにおけるDPLI_POB_ATR#uをPOB#xに基づいて設定する。こうしてDPLI_POB_SRP、DPLI_POB_ATRの双方を設定したのなら、ステップＳ６０８において#uのインクリメントを行い（#u←#u+1）、その後、ステップＳ６０９において#xのインクリメントを行う（#x←#x+1）。
【０３１２】
ステップＳ６０５においてPLIが選択された場合、ステップＳ６１０においてPLI#yにおけるPLI_POB_SRP#vyにPOB#xを設定し、ステップＳ６１１においてPLIにおけるPLI_POB_ATR#vyをPOB#xに基づいて設定する。そして、ステップＳ６１２において#vyをインクリメントした後（#vy←#vy+1）、#xをインクリメントするようステップＳ６０９に移行する。
【０３１３】
ステップＳ６０３においてPOB#xをトラックに割り当てるべきと判断した場合、ステップＳ６１３においてトラックの指定を受け付け、ステップＳ６１４において指定されたトラック#zについてのTKI#zに設定されているTKI_POB_SRP#wにPOB#xを設定する。その後、ステップＳ６１５においてTKI#zにおけるTKI_POB_ATR#wをPOB#xに基づいて設定し、ステップＳ６１６において#wをインクリメントした後（#w←#w+1）、ステップＳ６１７において#xがPOBのラストナンバー#nに達したか否かを判定する。達しないならば、ステップＳ６０９に移行して#xのインクリメントを行い、#xがPOBのラストナンバー#nに達したならば、ステップＳ６１８においてPOB#1〜#n,DPLI及びPLIを含むPLMGTKIを含むTKMGをフラッシュメモリカードに記録して、処理を終了する。
【０３１４】
以上のように本実施形態によれば、アーティストの写真や会社のロゴマーク等、複数のトラックが再生されている時間帯において、背景画として共通に表示させたい静止画データが存在する場合、Default_Playlist情報、PlayList情報におけるDPLGI、PLGI内のDPLI_POB_SRP、PLI_POB_SRPにて、その静止画データを指定することにより、それらのプレイリスト情報により再生順序が指定される複数のトラックが再生されている時間帯において、共通の静止画データを表示させておくことができる。また、歌詞等のように、背景画とは別に特定のトラックが再生されている期間にのみ表示させたい静止画データが存在する場合、そのような静止画データをTKIにおけるTKI_POB_SRPにて指定することができる。
【０３１５】
尚、上記実施形態は現状において最善の効果が期待できるシステム例として説明したに過ぎない。本発明は、その要旨を逸脱しない範囲で実施変更することができる。具体的には、以下の（ａ）（ｂ）（ｃ）に示すような変更実施が可能である。
（ａ）図９４、図９５、図９６、図９９のフローチャートを参照して説明した手順等を実行形式プログラムにより実現し、これを記録媒体に記録して流通・販売の対象にしても良い。
【０３１６】
（ｂ）本実施形態に係るプレゼンテーションデータ、ナビゲーションデータを音楽コンテンツに適用する場合を一例として説明を行ったが、本実施形態に係るプレゼンテーションデータ、ナビゲーションデータをアナウンサーや声優が書物を読み上げる音声により構成されるリーディングブックに適用してよいことはいうまでもない。この場合、その書物に含まれる文章の文字列を含む静止画を前景画としてTKI_POB_SRPにて指定させ、一方、その文書の挿絵を背景画としてDPLI_POB_SRP、PLI_POB_SRPに指定させるのが望ましい。
【０３１７】
（ｃ）本実施形態では、DPLI_POB_SRP−PLI_POB_SRPにより指定されていたPOBを背景画とし、TKI_POB_SRPにより指定されていたPOBを前景画としていたが、両者の関係を入れ替えても良い。更に、DPLI_POB_SRP−PLI_POB_SRPで指定されていたPOB、及び、TKI_POB_SRPにより指定されていたPOBの何れか一方のみを表示させてもよい。加えて、POBを前景画、背景画と区別することなく表示させてもよい。例えば、DPLI_POB_SRP(PLI_POB_SRP)にて指定されたPOBを表示し、次にTKI_POB_SRPにて指定されたPOBを表示させてよいことはいうまでもない。
【０３１８】
（第３実施形態）
第２実施形態では、PlayList情報及びTKIが有効な期間に各POBを均等な割合で表示させるとしたが、第３実施形態は、フレーズ期間テーブルと、ハイライト座標テーブルとをフラッシュメモリカード３１に格納させて、音声再生と、歌詞表示とを緻密に同期させる実施形態である。
【０３１９】
前者のフレーズ期間テーブルとは、各歌詞を示すPOBを指定するTKI_POB_SRPと、フレーズ期間の始期・終期を示す情報とを対応づけたテーブルである。図１００（ａ）は、フレーズ期間テーブルの一例を示す図である。ここでフレーズ期間は、AOBの再生時において、歌詞に記述されているフレーズが現れる期間を、ミリ秒単位の時間精度で表しており、再生装置は、第１実施形態に示したような再生経過時刻の更新に伴い、更新された再生経過期間が、テーブルに記載されているフレーズ期間のどれに相当するかの監視を行う。かかる監視により、現在再生されているAOB、AOB_ELEMENT、AOB_FRAMEの歌詞を記載したPOBがどれであるかを知ることができる。POBのフレーズ期間が何時であるかをミリ秒単位の時間精度で記載したテーブルを用いれば、上述したミリ秒単位の時間精度で、AOB再生と、歌詞表示とを同期させることができる。
【０３２０】
また、第１実施形態に示したようなジョグダイアルを用いた再生開始時刻の指定がなされ、頭出しを行う場合、AOB、AOB_ELEMENTについては、第１実施形態に示した数式１〜数式３を用いることにより、指定された再生開始時刻がどのAOBのどのAOB_ELEMENTのAOB_FRAMEに該当するかを判定する。一方静止画については、指定された再生開始時刻がどのフレーズ期間に対応するかを判定する。そして、指定されたフレーズ期間に対応するPOBを表示させる。こうして、ジョグダイアルを用いて頭出しを行う場合にも、その該当するPOBを適宜表示することができる。尚、本実施形態では、フレーズ期間テーブルに時刻を記載したが、その歌詞と同期すべきAOB、AOB_ELEMENT、AOB_FRAMEを示すAOB番号、AOB_ELEMENT番号、AOB_FRAME番号をフレーズ期間テーブルに記載しても良い。
【０３２１】
一方、後者のハイライト座標テーブルとは、歌詞に含まれる文字についての表示座標と、AOBにおいて、その文字に対応するAOB_ELEMENT及びAOB_FRAMEが再生される期間とを対応づけたテーブルである。図１００（ｂ）は、ハイライト座標テーブルの一例を示す図である。こうしたハイライト座標テーブルを設けておき、フレーズ期間に対応して表示されている歌詞のうち、今再生されているAOB_ELEMENT及びAOB_FRAMEに対応する文字のみを、異なる色にて表示するという動作を再生装置に行わせる。
【０３２２】
例えば歌詞に『小さなウィンドゥからあなたにアクセス』というフレーズが含まれている場合、ハイライト座標テーブルには、『小』『さ』『な』『ウ』『ィ』『ン』『ド』『ゥ』という文字の表示座標と、その文字に対応するAOB_ELEMENT及びAOB_FRAMEが再生される期間とを対応づけておく。そして再生装置は、第１実施形態に示したようなAOBの再生進行に伴い、ハイライト座標テーブルにおける文字の表示座標にて指示された箇所の色を変更する。
【０３２３】
これにより再生装置は、歌詞のうち、AOBにて再生されている箇所がどこであるかが、一目で判るような映像表示を行うことができ、現行のカラオケソフトのような再生を実現することが可能となる。
以上のように本実施形態によれば、フレーズ期間テーブルと、ハイライト座標テーブルという2つのテーブルを用いることにより、現行のカラオケソフトのような、音声再生と、歌詞表示とを緻密に同期させることが可能となる。
【０３２４】
【発明の効果】
本発明に係る半導体メモリカードは、複数のオーディオオブジェクト、静止画オブジェクト、再生経路情報、第１ポインタ情報、第２ポインタ情報、シンボリックカウンタを格納する半導体メモリカードであって、再生経路情報は、オーディオオブジェクトの再生順序を示し、第１ポインタ情報は、再生経路情報に対応するものであって、該再生経路情報に従ったオーディオオブジェクトの全再生時間中における静止画オブジェクトの再生順序を示し、第２ポインタ情報は、特定のオーディオオブジェクトに対応するものであって、該オーディオオブジェクトの全再生時間中における静止画オブジェクトの再生順序を示し、シンボリックカウンタは、各静止画オブジェクトに対応づけられており、対応する静止画オブジェクトが第１ポインタ情報又は第２ポインタ情報により指定されているか否かを示し、指定されている静止画オブジェクトについては、幾つの第１ポインタ情報、第２ポインタ情報により指定されているかの指定数を示しているので、オーディオシーケンスに含まれる複数のオーディオオブジェクトが、再生経路情報に示される再生順序に準じて再生されている時間帯において、背景画として共通に表示させたい静止画オブジェクトが存在する場合、第１ポインタ情報において、再生経路情報と対応づけてその静止画オブジェクトを指定させる。これによりオーディオシーケンスに含まれる複数のオーディオオブジェクトが再生されている時間帯において、共通の静止画オブジェクトを表示させておくことができる。
【０３２５】
複数のオーディオオブジェクトに対して共通の静止画を割り当てることができるので、知名度が低い音楽アルバムに相当するオーディオシーケンスについては、複数のオーディオオブジェクトが再生されている期間において、静止画オブジェクト等を共通に表示させることにより、画像製作に要する手間や費用を倹約することができる。
【０３２６】
逆に知名度が高い音楽アルバムに相当するオーディオシーケンスについては、各オーディオオブジェクトが再生されている期間において、各オーディオオブジェクトに対して複数の静止画を割り当てて、一つのオーディオオブジェクトに対して複数の静止画オブジェクトを表示させることにより、各オーディオオブジェクトの再生を豪華に演出することができる。そうした静止画表示にてアーティストのファンの心理を掴むことにより、オーディオシーケンス（音楽アルバム）の売り上げを高めることができる。
【０３２７】
また、歌詞等のように、背景画とは別に特定のオーディオオブジェクトが再生されている期間にのみ表示させたい静止画オブジェクトが存在する場合、そのような静止画オブジェクトを第２ポインタ情報にて指定して、特定のオーディオオブジェクトに割り当てることができる。
更に、対応する静止画オブジェクトが第１ポインタ情報又は第２ポインタ情報により指定されているか否かがシンボリックカウンタに示されている。このシンボリックカウンタには、幾つの第１ポインタ情報、第２ポインタ情報により指定されているかの指定数さえも表現されているので、半導体メモリカードの記録装置がオーディオオブジェクトやオーディオシーケンスの削除を行った際、削除されたオーディオオブジェクトについての第２ポインタ情報や削除されたオーディオシーケンスについての第１ポインタ情報を特定し、これら第１ポインタ情報、第２ポインタ情報により表示が指定される静止画オブジェクトについての割当数をデクリメントしてゆく。何れかの静止画オブジェクトについての割当数が0に達したなら、当該静止画オブジェクトはどの第１ポインタ情報や第２ポインタ情報からも参照されない静止画オブジェクトであるとして、当該静止画オブジェクトを削除してしまうことができる。このようにオーディオオブジェクトの削除と連動して、静止画オブジェクトの削除を行うことにより、半導体メモリカードにおける記憶効率を向上させることができる。
【図面の簡単な説明】
【図１】フラッシュメモリカード３１を上面から見た場合の形状を示す図である。
【図２】フラッシュメモリカード３１をその下面から見た場合の形状を示す図である。
【図３】本実施形態に係るフラッシュメモリカード３１の階層構造を示す図である。
【図４】（ａ）フラッシュメモリカード３１の物理層に設けられたシステム領域と、プロテクト領域と、ユーザデータ領域の構成を示す図である。
（ｂ）ファイルシステム層におけるプロテクト領域及びユーザデータ領域の構成を示す図である。
【図５】ファイルシステム層における構成の詳細を示す図である。
【図６】 AOB001.SA1をクラスタサイズに合わせて5つに分割し、各分割部分を、クラスタ003,004,005,00A,00Cに格納する状態を想定した図である。
【図７】 AOB001.SA1が複数のクラスタに記録されている場合のディレクトリエントリー及びファイルアロケーションテーブルについての設定例を示す図である。
【図８】（ａ）（ｂ）応用層におけるこれら2つのデータを格納する場合、ファイルシステム層においてユーザデータ領域及びプロテクト領域には、どのようなディレクトリが構成され、どのようなファイルが当該ディレクトリの配下に作成されるかを示す図である。
【図９】 SD_Audioディレクトリの下にあるAOBSA1.KEYと、AOBファイルとの対応を示す図である。
【図１０】 AOBファイルのデータ構成を階層的に示す図である。
【図１１】（ａ）ISO/IEC13818-7に記述されているパラメータを表形式に示す図である。
（ｂ）MPEG-Layer3(MP3)方式にて符号化する際に使用すべきパラメータを表形式に示す図である。
（ｃ）Windows（登録商標） Media Audio(WMA)方式にて符号化する際に使用すべきパラメータを表形式に示す図である。
【図１２】 AOB_FRAMEの構成の詳細を示す図である。
【図１３】 3つのAOB_FRAMEにおいて、それぞれのAOB_FRAMEにおけるオーディオデータのバイト長がどのように設定されるかを示す図である。
【図１４】 sampling_frequencyと、AOB_ELEMENTに含まれるAOB_FRAME数との対応を示す図である。
【図１５】 AOB_ELEMENTの時間長及びAOB_FRAMEの時間長の一例を示す図である。
【図１６】 AOBファイルに収録されている各AOB、AOB_BLOCKが連続して再生されることにより、どのような再生内容が再生されるかを示す図である。
【図１７】第１実施形態におけるPlaylistmanager及びTrackManagerの構成を段階的に詳細化した図である。
【図１８】 PlayListManager及びTrackManagerのサイズを示す図である。
【図１９】図１７に示したTKIと、図１６に示したAOBファイル及びAOBとの相互関係を示す図である。
【図２０】図１７に示したTKTMSRTの詳細なデータ構造を示す図である。
【図２１】 TKTMSRTについての一例を示す図である。
【図２２】 TKGIの詳細構成を示す図である。
【図２３】（ａ）（ｂ）BITの詳細構成を示す図である。
（ｃ）TIME_LENGTHフィールドのデータフォーマットを示す図である。
【図２４】 AOB_ELEMENT#1〜#4からなるAOBが格納されているクラスタ007〜クラスタ00Eを示す図である。
【図２５】 AOB内の任意のAOB_ELEMENT#yにおけるAOB_FRAME#xから順方向サーチ再生を行う場合、次に再生すべきAOB_FRAME#x+1をどのように設定するかを示す図である。
【図２６】（ａ）（ｂ）任意の再生開始時刻が指定された場合、その指定時刻に対応するAOB、AOB_ELEMENT、AOB_FRAMEをどのように特定するかを示す図である。
【図２７】（ａ）（ｂ）トラックを削除する場合を想定した図である。
【図２８】（ａ）トラックの削除が複数回行われた後のTrackManagerを示す図である。
（ｂ）『Unused』のTKIが存在しており、ここに新たなTKI、AOBファイルを書き込む場合、その書き込みがどのように行われるかを示す図である。
【図２９】（ａ）（ｂ）2つのトラックを統合する場合にTKIがどのように設定されるかを示す図である。
【図３０】（ａ） Type1のAOBを示す図である。
（ｂ）Type2のAOBを示す図である。
【図３１】（ａ）Type1＋Type2＋Type2＋Type1の組み合わせで、複数トラックを1つに統合する場合を示す図である。
（ｂ）Type1＋Type2＋Type2＋Type2＋Type1の組み合わせで、複数トラックを1つに統合する場合を示す図である。
【図３２】（ａ）先行するトラックの終端にType1のAOBが配され、後続するトラックの先頭にType1のAOBが配されている配置パターンを示す図である。
（ｂ）先行するトラックの終端にType1のAOBが配され、後続するトラックの先頭にType2のAOBが配されている配置パターンを示す図である。
（ｃ） 先行するトラックの終端にType1、Type2順でAOBが配され、後続するトラックの先頭にType1のAOBが配されている配置パターンを示す図である。
（ｄ） 先行するトラックの終端にType1、Type2順でAOBが配され、後続するトラックの先頭に、Type2、Type1のAOBが配されている配置パターンを示す図である。
（ｅ） 先行するトラックの終端にType2、Type2のAOBが配され、後続するトラックの先頭にType1のAOBが配されている配置パターンを示す図である。
【図３３】（ａ）（ｂ）1つのトラックを2つのトラックに分割する場合を想定した図である。
【図３４】（ａ）（ｂ）分割前後において、AOB003.SA1が属するSD_AudioディレクトリについてのSD_Audioディレクトリエントリーがどのように記述されているかかを示す図である。
【図３５】（ａ）AOBをAOB_ELEMENT#2の途中部分で分割する場合を想定した図である。
（ｂ）AOB_ELEMENT#2の途中部分でAOBが分割されて、AOB#1、AOB#2という2つのAOBが得られた状態を示す図である。
【図３６】図３５に示したようにAOBが分割された場合に、BITがどのように設定されるかを示す図である。
【図３７】分割の前後でBITがどのように変化するかを具体的に示す図である。
【図３８】分割の前後でTKTMSRTがどのように変化するかを具体的に示す図である。
【図３９】（ａ）DPL_TK_SRPのフォーマットを示す図である。
（ｂ）PL_TK_SRPのフォーマットを示す図である。
【図４０】 Default_Playlist情報、TKI、AOBファイルの相互関係を示す図である。
【図４１】 DefaultPlaylist、PlayList情報の設定例を、図４０と同様の表記で示した図である。
【図４２】図４０と同じ表記法を用いてDPL_TK_SRPとTKIとの対応を示す図である。
【図４３】（ａ）（ｂ）トラックの順序を入れ替える場合を想定した図である。
【図４４】（ａ）（ｂ）図４０に示したDefaultPlaylistのうち、DPL_TK_SRP#2及びTKI#2を削除する場合にDefaultPlaylist、TrackManager、AOBファイルがどのように更新されるかを示す図である。
【図４５】（ａ）（ｂ）『Unused』のTKIと、DPL_TK_SRPとが存在しており、ここに新たなTKI、DPL_TK_SRPを書き込む場合、その書き込みがどのように行われるかを示す図である。
【図４６】（ａ）（ｂ）トラックの統合を行う場合を想定した図である。
【図４７】（ａ）（ｂ）トラックの分割を行う場合を想定した図である。
【図４８】本実施形態に係るフラッシュメモリカード３１についての携帯型の再生装置を示す図である。
【図４９】プレイリストの選択が行われる際の液晶ディスプレィの表示内容の一例を示す図である。
【図５０】（ａ）〜（ｅ）トラックの選択が行われる際の液晶ディスプレィの表示内容の一例を示す図である。
【図５１】（ａ）〜（ｃ）ジョグダイアルの操作例を示す図である。
【図５２】再生装置の内部構成を示す図である。
【図５３】ダブルバッファ１５におけるデータ入出力がどのように行われるかを示す図である。
【図５４】（ａ）（ｂ）リングポインタを用いた巡回式の領域確保がどのように行われるかを示す図である。
【図５５】 AOBファイル読み出し処理の処理手順を示すフローチャートである。
【図５６】 AOB_FRAME出力処理の処理手順を示すフローチャートである。
【図５７】 AOB_FRAME出力処理の処理手順を示すフローチャートである。
【図５８】 AOB_FRAME出力処理の処理手順を示すフローチャートである。
【図５９】（ａ）〜（ｄ）液晶ディスプレィ５の時刻表示枠に表示される再生経過時刻が、変数Play_Timeの更新したがい、増加してゆく様子を示す図である。
【図６０】順方向サーチ再生処理時におけるCPU１０の処理手順を示すフローチャートである。
【図６１】（ａ）〜（ｄ）順方向サーチ再生時において、再生経過時刻がインクリメントされてゆく様子を示す図である。
【図６２】（ａ）〜（ｂ）タイムサーチ機能が行われる場合の具体例を示す図である。
【図６３】編集制御プログラムの処理手順を示すフローチャートである。
【図６４】編集制御プログラムの処理手順を示すフローチャートである。
【図６５】編集制御プログラムの処理手順を示すフローチャートである。
【図６６】フラッシュメモリカード３１の記録装置の一例を示す図である。
【図６７】記録装置のハードウェア構成を示す図である。
【図６８】記録処理の処理手順を示すフローチャートである。
【図６９】第２実施形態におけるフラッシュメモリカードの階層構造を示す図である。
【図７０】（ａ）（ｂ）ファイルシステム層におけるユーザデータ領域及びプロテクト領域の内部構成を示す図である。
【図７１】（ａ）POBXXX.JPGの内部構成を示す図である。
（ｂ）暗号化された静止画データを含むPOBファイルの内部構成を示す図である。
（ｃ）暗号化された実体部の代わりにファイルパスを格納したPOBファイルの一例を示す図である。
【図７２】第２実施形態におけるPlayListManager、TrackManagerの詳細構成を示す図である。
【図７３】 TKI_POB_SRP、PLI_POB_SRP、DPLI_POB_SRPにより、図７０に示したPOBファイルが指定されている状態を示す図である。
【図７４】 TKI_POB_SRP、TKI_POB_ATRのデータ構造を示す図である。
【図７５】 TrackManagerに含まれるTKI#1〜TKI#3についてのTKI_POB_SRPの設定例を示す図である。
【図７６】 TrackManagerに含まれるTKI#4〜TKI#8に含まれるTKI_POB_SRPの設定例を示す図である。
【図７７】 DPLGIに含まれているDPLI_POB_SRP及びDPLI_POB_ATRを示す図である。
【図７８】 Default_Playlist情報に含まれる20個のDPLI_POB_SRPの設定例を示す図である。
【図７９】 Default_Playlist情報に含まれるDPLI_POB_SRPにて指定されたPOBを背景画とし、TrackManagerに含まれるTKI_POB_SRPにて指定されるPOBを前景画とした場合、これらがどのように合成されるかを示すタイミングチャートである。
【図８０】 Default_Playlist情報の再生開始から6分経過後に、前景画、背景画がどのように合成されるかを示す図である。
【図８１】 Default_Playlist情報の再生開始から16分経過後に、前景画、背景画がどのように合成されるかを示す図である。
【図８２】 PLGIに含まれているPLI_POB_SRP及びPLI_POB_ATRを示す図である。
【図８３】 PlayList情報に含まれる20個のPLI_POB_SRPの設定例を示す図である。
【図８４】 Playlist情報に含まれるPLI_POB_SRPにて指定されたPOBを背景画とし、TrackManagerに含まれるTKI_POB_SRPにて指定されるPOBを前景画とした場合、これらがどのように合成されるかを示すタイミングチャートである。
【図８５】 Playlist情報の再生開始から6分経過後に、前景画、背景画がどのように合成されるかを示す図である。
【図８６】 Default_Playlist情報の再生開始から16分経過後に、前景画、背景画がどのように合成されるかを示す図である。
【図８７】 Default_Playlist情報における複数のDPLI_POB_SRPのうち、DPLI_POB_SRPに共通のPOBファイルを指定させることにより、POBファイルの数の削減を図った例である。
【図８８】 Default_Playlist情報に含まれるDPLI_POB_SRPにて指定されたPOBを背景画とし、TrackManagerに含まれるTKI_POB_SRPにて指定されるPOBを前景画とした場合、これらがどのように合成されるかを示すタイミングチャートである。
【図８９】 POBMGの内部構成を示す図である。
【図９０】第２実施形態に係る再生装置がどのように用いられるかを示す図である。
【図９１】第２実施形態に係る再生装置本体のみの外観を示す図である。
【図９２】第２実施形態に係る再生装置の内部構成を示す図である。
【図９３】（ａ）複数のVRAM６１に格納された静止画がどのように重ね合わせられるかを示す図である。
（ｂ）複数のVRAM６１に格納された静止画がどのように重ね合わせられるかを示す図である。
【図９４】前景画表示処理についての処理手順を示すフローチャートである。
【図９５】背景画表示処理の処理手順を示すフローチャートである。
【図９６】背景画表示処理の処理手順を示すフローチャートである。
【図９７】（ａ）〜（ｃ）図９４、図９５のフローチャートに示す処理手順により、TKI_POB_SRPにて指定された前景画、DPLGIにより指定された背景画が合成された場合に、どのような合成画像が液晶ディスプレィ５に表示されるかを示す図である。
【図９８】（ａ）〜（ｃ）図９４、図９６のフローチャートに示す処理手順により、TKI_POB_SRPにて指定された前景画、PLI_POB_SRPにて指定された背景画が合成された場合に、どのような合成画像が液晶ディスプレィ５に表示されるかを示す図である。
【図９９】第２実施形態に係る記録装置の処理手順を示すフローチャートである。
【図１００】（ａ）フレーズ期間テーブルの一例を示す図である。
（ｂ）ハイライト座標テーブルの一例を示す図である。
【符号の説明】
１ カードコネクタ
２ ユーザインターフェイス部
３ RAM
４ ROM
５ 液晶ディスプレィ
６ LCDドライバ
７ デ・スクランブラ
８ AACデコーダ
９ A/Dコンバータ
１１ DPLI常駐領域
１２ PLI格納領域
１３ TKI格納領域
１４ FileKey格納領域
１５ ダブルバッファ
２１ カードコネクタ
２２ RAM
２３ 固定ディスク装置
２４ コンバータ
２４ A/DステップＳ
２５ AACエンコーダ
２６ スクランブル部
２７ モデム装置
２８ CPU
２９ キーボード
３０ ディスプレィ
３１ フラッシュメモリカード
３２ プロテクトスイッチ
６１ VRAM
【発明の属する技術分野】
本発明は、オーディオデータ、静止画データ、制御データを格納する半導体メモリカード、編集装置、再生方法、編集方法、コンピュータ読み取り可能な記録媒体に関し、特に、電子音楽配信等のコンテンツ配信サービスにおいて、コンテンツとして配信されたオーディオデータ、画像データ、制御データを格納する場合の改良に関する。
【０００２】
【従来の技術】
インターネットにおいて音楽コンテンツの購入が可能となる電子音楽配信は、音楽市場の活性化の起爆材になり得るものであり、その実現のためのインフラストラクチャは、着々と整備されつつある。上述した半導体メモリカードは、電子音楽配信から購入した音楽コンテンツを格納し、これを持ち運ぶのに好適な可搬型の記録媒体であり、今後その需要が飛躍的に増大すると期待される。
【０００３】
音楽コンテンツには、単に音楽再生が可能だけでは無く、音楽再生と共に、その音楽に関連する画像表示を行うことができる"メディアミックス"型の音楽コンテンツがある。歌詞を示す画像やその背景画となる画像を、カラオケ音楽ともに記録媒体に記録しておき、カラオケ音楽の再生時に、歌詞表示を行うという『カラオケソフト』は、"メディアミックス"型の典型的な音楽コンテンツであり、今後、電子音楽配信の更なる発展を考えるには、メディアミックス型の音楽コンテンツの流通・販売の実現をも視野に入れねばならない。それに伴い、"メディアミックス"型の音楽コンテンツを半導体メモリカードに格納する際の格納方式も、より具体的な検討が迫られることなる。
【０００４】
それでは、CD等の記録媒体において、"メディアミックス"型の音楽コンテンツは、どのように格納されていたか、即ち、記録媒体における従来のオーディオデータ−画像データの格納方式について説明する。
音楽再生と画像表示とを行うため、従来の"メディアミックス"型の音楽コンテンツは、音楽についてのオーディオデータと、歌詞・背景画を示す画像データとを多重化して得た多重化データを記録媒体に記録させることにより、オーディオデータの再生と、画像データの表示とを共に行っていた。多重化により、オーディオデータ再生ともに画像表示を実現していた記録媒体には、CD-Graphics(サブコードGraphics)と呼ばれるものがある。このCD-Graphicsにおける多重化の一単位は、16ビットのメインコードと、サブコードとからなり、16ビットのメインコードにオーディオデータを割り当て、サブコードに、歌詞や背景画像等の画像データを割り当てている。そしてCD-Graphicsに記録された音楽コンテンツの何れかの再生が開始されれば、16ビットのメインコードに割り当てられたオーディオデータが順次再生され、サブコードに割り当てられた画像データが順次表示される。
【０００５】
【発明が解決しようとする課題】
ところで上述したオーディオデータ−画像データの多重化方式に従って、複数の音楽コンテンツからなる音楽アルバムを製作しようとすると、各音楽コンテンツ毎に一律に画像を設けることなる。即ち、従来のオーディオデータ−画像データの多重化方式は、各音楽コンテンツに少なくとも1つの画像を割り当てることが要求されるので、製作者は、かかる画像の製作の手間に煩わされるという問題点がある。
【０００６】
もっとも、知名度が高いアーティストの音楽アルバムについては、音楽コンテンツ毎に異なる画像が設けられている方が消費者からも歓迎されるだろうし、音楽アルバムの売り上げが多大となると予想されるので、かかる手間と費用が報われる可能性が高い。逆に人気が低いアーティストの音楽アルバムについては、音楽コンテンツ毎に異なる画像が設けたとしても、消費者の反応は鈍いだろうし、音楽アルバムの売り上げが多大になることは期待できないので、かかる手間や費用が報われない可能性が高い。
【０００７】
画像製作に要した労力や経費が報われるか否かは、知名度の高い音楽アルバムと低い音楽アルバムとの間の落差が激しいことは明らかであるが、従来のオーディオデータ−画像データの多重化方式は、アーティストの知名度や、売り上げの見込数に拘らず、各音楽コンテンツに少なくとも1つの画像を割り当てることが要求されるので、この点において製作者にとって不満が残るものであった。
【０００８】
本発明の目的は、複数の音楽コンテンツからなる音楽アルバムを製作する場合において、各音楽コンテンツに割り当てるべき画像を製作する手間を削減することができる半導体メモリカードを提供することである。
【０００９】
【課題を解決するための手段】
ここで音楽コンテンツと表示すべき画像について考えてみると、音楽コンテンツの歌詞については、音楽コンテンツ毎に異なるものを設けることは必要不可欠となるが、背景画については、複数の音楽コンテンツの再生時に表示させるべき背景画を共通化して良い場合がある。例えば、複数の音楽コンテンツが同一人物により作詞・作曲・歌唱されている場合、それら複数の音楽コンテンツの再生時において、その人物の共通の写真を背景画として表示させることにより、製作者の手間を省くというオーディオデータ（オーディオオブジェクト）及び画像データ（静止画オブジェクト）の格納方式が考えられる。
【００１０】
複数音楽コンテンツ間の画像データ（静止画オブジェクト）の共通化を図って上記目的を達成するため、本発明に係る半導体メモリカードは、複数のオーディオオブジェクト、静止画オブジェクト、再生経路情報、第１ポインタ情報、第２ポインタ情報、シンボリックカウンタを格納する半導体メモリカードであって、再生経路情報は、オーディオオブジェクトの再生順序を示し、第１ポインタ情報は、再生経路情報に対応するものであって、該再生経路情報に従ったオーディオオブジェクトの全再生時間中における静止画オブジェクトの再生順序を示し、第２ポインタ情報は、特定のオーディオオブジェクトに対応するものであって、該オーディオオブジェクトの全再生時間中における静止画オブジェクトの再生順序を示し、シンボリックカウンタは、各静止画オブジェクトに対応づけられており、対応する静止画オブジェクトが第１ポインタ情報又は第２ポインタ情報により指定されているか否かを示し、指定されている静止画オブジェクトについては、幾つの第１ポインタ情報、第２ポインタ情報により指定されているかの指定数を示す、ことを特徴としている。
【００１１】
【発明の実施の形態】
以降、図面を参照しながら半導体メモリカード（フラッシュメモリカード）の実施形態について説明を行う。
尚、以降の各文には、その文頭に以下のような体系を有する分類番号を付している。
【００１２】
{x1-x2_x3-x4}
分類番号の桁数は、その項目の階層的な深さを意味している。具体的にいうと、x1は、説明に引用している図番である。本明細書に添付している図には、明細書において引用する順番に沿った番号を付しているので、この図番の順序が、説明の順序とほぼ同一となる。x2は、x1に示される図を引用して説明する場合の説明の順序を示す。x3は、x2の構成要素をより詳細に説明するために説明図を引用する場合、その説明図の図番を示し、x4は、x3に示される図を引用して説明する場合の説明の順序を示す。
【００１３】
（第１実施形態）
{1-1_2} フラッシュメモリカード３１の外観形状
初めに、フラッシュメモリカード３１の外観形状について説明する。図１は、フラッシュメモリカード３１を上面から見た場合の形状示す図であり、図２は、フラッシュメモリカード３１をその下面から見た場合の構造を示す図である。図１、図２に示すように、フラッシュメモリカード３１の大きさは、長さが約32.0 mm、幅は約24.0 mm、厚さ約2.0 mmであり、指先で把持できる程度の大きさ（切手サイズの大きさ）である。下面には、機器との接続のための9本のコネクタが設けられており、側面には、記憶内容の上書きを許可するか禁止するかを操作者が設定することができるプロテクトスイッチ３２が設けられている。
【００１４】
{3-1} フラッシュメモリカード３１の物理構造
図３は、本実施形態に係る半導体メモリカード（以下、フラッシュメモリカード３１と称する）の階層構造を示す図である。本図に示すように、フラッシュメモリカード３１の階層構造は、物理層、ファイルシステム層、応用層からなる点で、DVD（Digital Video Disc）の階層構造と同一であるが、各層における論理構造、物理構造は大きく相違する。
【００１５】
{3-2} フラッシュメモリカード３１の物理構造
先ずフラッシュメモリカード３１の物理層について説明する。フラッシュメモリは、複数のセクタからなり、各セクタは512バイトのディジタルデータを格納する。例えば64MByteタイプのフラッシュメモリカード３１の場合、そのメモリー容量は、67108864(=64×1024×1024)バイトであり、このときの有効セクタ数は131072(=67108864/512)となる。更に、この有効セクタからエラー用の代替セクタ数を差し引けば、残りの有効セクタ数は、128,000となり、ここに各種データが記録されることなる。
【００１６】
{3-2_4A-1} 物理層における3つの領域
これら有効セクタからなる領域には、図４（ａ）に示す3つの領域が設けられる。図４（ａ）は、フラッシュメモリカード３１の物理層に設けられた『システム領域』、『プロテクト領域』、『ユーザデータ領域』を示す図である。以降、これら3つの領域について説明する。
【００１７】
『ユーザデータ領域』は、フラッシュメモリカード３１と接続された機器が様々なデータを自由に書き込むことができ、データを自由に読み出すことができる領域であり、その内部領域がファイルシステムにより管理されている。
『システム領域』は、フラッシュメモリカード３１のそれぞれについてユニークな値を持つメディアIDが格納される領域である。ユーザデータ領域が書込可能であるのに対して、システム領域は、読出専用であり、ここに格納されたメディアIDを書き換えることはできない。
【００１８】
『プロテクト領域』は、ユーザデータ領域同様、データ書き込みが可能な領域である。ユーザデータ領域との差違は、ユーザデータ領域では、データの読み書きが自由に行なえるのに対して、プロテクト領域では、フラッシュメモリカード３１と接続された機器と、フラッシュメモリカード３１とが互いの正当性を確認した場合のみ読み書きすることができる点、即ち、フラッシュメモリカード３１と接続された機器と、フラッシュメモリカード３１との相互認証が成功した場合のみ、読み書き可能となる点である。
【００１９】
{3-2_4A-2} 物理層における3つの領域の用途
フラッシュメモリカード３１に接続された機器がフラッシュメモリカード３１にデータを書き込む際、そのデータの著作権保護の要否に応じて、これら3つの領域は利用される。ここで、著作権の保護が必要なデータをフラッシュメモリカード３１に書き込む場合、当該データは、所定の暗号鍵(FileKeyと呼ばれる。)を用いて暗号化された後にユーザデータ領域に格納される。このFileKeyは著作権者が自由に設定できるものであり、これだけでも、当該データの著作権は保護されるが、更に万全を期すため、この暗号化に用いたFileKey自身も暗号化する。FileKey自身を暗号化する際、鍵として用いられるのは、システム領域に格納されているメディアIDを所定の演算式に適用することにより得られる任意の値であり、プロテクト領域は、当該任意の値を用いて暗号化されたFileKeyを格納する。著作権保護が必要なデータは、所定のFileKeyを用いて暗号化し、このFileKey自身もメディアIDに基づいた値を用いて暗号化するという二段階の暗号化がなされるので、不正コピーなどの著作権侵害行為は、極めて困難になる。
【００２０】
{3-2_4B-1} ファイルシステムの概要
フラッシュメモリカード３１の物理層の構成は以上説明した通りであり、著作権保護の改良がなされていることがわかる。続いてこの物理層上に存在するファイルシステム層の構成について説明する。
DVDのファイルシステム層は、UDF(universal disk format)型のファイルシステムであるの対して、フラッシュメモリカード３１のファイルシステム層は、FAT型のファイルシステム（FAT:File Allocation Table,ISO/IEC 9293）であり、この点がDVDと異なる。
【００２１】
図４（ｂ）は、ファイルシステム層におけるプロテクト領域及びユーザデータ領域の構成を示す図である。図４（ｂ）においてファイルシステムにおけるプロテクト領域及びユーザデータ領域は、『パーティションブートセクタ』と、『ファイルアロケーションテーブル(FAT)』と、『ルートディレクトリエントリ』と、『データ領域』とを含んでおり、プロテクト領域とユーザデータ領域は共に同じ構成となっていることがこの図からも明らかである。図５は、これらファイルシステム構成の詳細を示す図である。以降、ユーザデータ領域についての構成を図４、図５を参照しながら説明する。
【００２２】
{3-2_4B-2} パーティションブートセクタ
『パーティションブートセクタ』は、フラッシュメモリカード３１が汎用パーソナルコンピュータに装填され、当該汎用パーソナルコンピュータのオペレーティングシステムの起動ディスクにフラッシュメモリカード３１を割り当てられた場合、汎用パーソナルコンピュータがブート時に参照すべき内容が記載されているセクタである。
【００２３】
{3-2_4B-3_5} データ領域
『データ領域』は、クラスタを最小単位にして、フラッシュメモリカード３１に接続された機器によりアクセスされる領域である。フラッシュメモリカード３１のセクタサイズが512バイトであるのに対して、クラスタサイズは、16Kバイトであるので、ファイルシステム層では32個のセクタを一単位として、データの読み書きが行われる。クラスタサイズを16Kバイトとした理由は、以下の通りである。即ち、フラッシュメモリカード３１にデータを書き込む場合、当該フラッシュメモリカード３１に格納されているデータを一旦イレーズ(消去)してから、データ書き込みを行わねばならない。フラッシュメモリカード３１において、そのようにデータをイレーズできるサイズは、16Kバイトであるので、このイレーズ可能なサイズにクラスタサイズを設定することにより、データ書き込みが好適に行われるようにしている。図５における破線の引き出し線ff2は、データ領域に含まれる複数のクラスタ002,003,004,005・・・・・を示す。図中の番号002,003,004,005,006,007,008・・・・・・・は、各クラスタを識別するために付与された3桁の16進数表記のクラスタ番号を示す。データ領域に対するアクセスは、クラスタを最小単位として行われるので、データ領域の内部位置は、これらのクラスタ番号を用いて、指示される。
【００２４】
{3-2_4B-4_5} ファイルアロケーションテーブル
『ファイルアロケーションテーブル』は、ISO/IEC 9293に準拠したファイルシステム構造を有しており、複数のFAT値からなる。各FAT値は各クラスタに対応づけられており、対応するクラスタが読み出された場合、次にどのクラスタを読み出せばよいかを示す。図５の破線の引き出し線ff1は、ファイルアロケーションテーブルに含まれる複数のFAT値002,003,004,005・・を示す。このFAT値に付与された数値『002,003,004,005・・』は、各FAT値がどのクラスタに対応づけられているか、つまり、各FAT値が対応づけられているクラスタのクラスタ番号を示す。
【００２５】
{3-2_4B-5_5-1} ルートディレクトリエントリ
『ルートディレクトリエントリ』は、ルートディレクトリにどのようなファイルが存在するかを示す情報である。具体的にいうと、ルートディレクトリエントリーには、存在するファイルの『ファイル名』と、そのファイルの『拡張子』と、『ファイル属性』と、ファイルの『更新時刻及び年月日』と、ファイルの先頭部が格納されている『ファイル最初のクラスタ番号』とが記載されている。
【００２６】
{3-2_4B-5_5-2} サブディレクトリのディレクトリエントリ
ルートディレクトリにあるファイルについての情報は、このルートディレクトリエントリーに記載されるが、サブディレクトリについての情報は、このルートディレクトリエントリーには記載されない。サブディレクトリについてのディレクトリエントリーは、データ領域内に作成される。図５のデータ領域内に記載されたSD_Audioディレクトリエントリーは、サブディレクトリについてのディレクトリエントリーの一例であり、本SD_Audioディレクトリエントリーは、ルートディレクトリエントリー同様、そのサブディレクトリに存在するファイルの『ファイル名』と、そのファイルの『拡張子』と、『ファイル属性』と、ファイルの『更新時刻及び年月日』と、ファイルの先頭部が格納されている『ファイル最初のクラスタ番号』とが記述される。
【００２７】
{3-2_4B-5_6-1} AOBファイルの格納方式
ここで、SD_AudioディレクトリにAOB001.SA1というファイルを格納する場合、AOB001.SA1がどのように格納されるか、即ち、ファイル格納方式の一例を図６を参照しながら説明する。上述したようにデータ領域の最小アクセス単位はクラスタであるので、AOB001.SA1は、クラスタサイズを最小単位にしてデータ領域に格納せねばならない。AOB001.SA1は、先ずクラスタサイズに分割されて、各クラスタに書き込まれる。図６は、AOB001.SA1をクラスタサイズに合わせて5つに分割し、各分割部分を、クラスタ003,004,005,00A,00Cに格納する状態を想定した図である。
【００２８】
{3-2_4B-5_7-1} AOBファイルの格納方式
AOB001.SA1が分割格納されると、ディレクトリエントリー及びファイルアロケーションテーブルは、図７のように設定されねばならない。
図７は、AOB001.SA1が複数のクラスタに記録されている場合のディレクトリエントリー及びファイルアロケーションテーブルについての設定例を示す図である。本図においてAOB001.SA1の先頭部分がクラスタ003に記録されている場合、SD_Audioディレクトリエントリーにおける『最初のクラスタ番号』には、その先頭部分が格納されているクラスタについてのクラスタ番号003が記載される。以降、AOB001.SA1の後続する部分は、クラスタ004、クラスタ005に格納されていることがわかる。AOB001.SA1の先頭部分を格納しているクラスタ003には、FAT値003(004)が対応しているが、このFAT値は、AOBファイルの後続する部分を格納しているクラスタ004を示すものである。またこれに後続している部分を格納しているクラスタ004,005には、FAT値004(005),FAT値005(00A)が対応しているが、これのFAT値は、AOBファイルの次の後続する部分を格納しているクラスタ005,00Aを示すものである。
【００２９】
これらFAT値に記載されたクラスタ番号を矢印fk1,fk2,fk3,fk4,fk5・・・・・に示すように順次読みとってゆけば、AOB001.SA1の分割部分を全て読み取ることができる。以上の説明により、フラッシュメモリカード３１のデータ領域は、クラスタを最小単位としてアクセスされ、また各クラスタにはそれぞれFAT値が対応づけられていることがわかる。尚、AOBファイルの末尾の部分を格納したクラスタ(図７の一例では、クラスタ00C)に対応づけられているFAT値には、そのクラスタがファイルの最終部分を格納していることを示すクラスタ番号『FFF』が記述される。
【００３０】
以上で、本発明のフラッシュメモリカード３１のファイルシステムに関する説明を終え、続いて、上述したファイルシステム上に存在する応用層の構成について説明する。
{3-3} フラッシュメモリカード３１における応用層の概要
フラッシュメモリカード３１における応用層の概要は、図３に記載された通りである。図３における破線の引き出し線PN1に示すようにフラッシュメモリカード３１における応用層は、プレゼンテーションデータと、プレゼンテーションデータの再生を制御するためのナビゲーションデータとからなる。
【００３１】
本図の破線の引き出し線PN2に示すように、プレゼンテーションデータは、音楽等の音声データをエンコードすることにより得られたオーディオオブジェクト群(AOB群)を含み、ナビゲーションデータは、プレイリストマネージャー(PlaylistManager(PLMG))と、トラックマネージャー(Track Manager(TKMG))とを含む。
{3-3_8A,B-1} ディレクトリ構成
図８（ａ）、（ｂ）は、応用層におけるこれら2つのデータを格納する場合、ファイルシステム層においてユーザデータ領域及びプロテクト領域には、どのようなディレクトリが構成され、どのようなファイルが当該ディレクトリの配下に作成されるかを示す図である。本図における『SD_AUDIO.PLM』、『SD_AUDIO.TKM』は、プレイリストマネージャー(PlaylistManager(PLMG))、トラックマネージャー(Track Manager(TKMG))といったナビゲーションデータを収録したファイルであり、『AOB001.SA1』『AOB002.SA1』『AOB003.SA1』『AOB004.SA1』・・・・・は、プレゼンテーションデータであるオーディオオブジェクトを格納したファイル（以下、AOBファイルという）である。
【００３２】
『AOB0xx.SA1』における拡張子『SA』は、『Secure Audio』の略であり、これらの格納内容は、著作権保護の必要性があることを示す（尚、図８（ａ）にはAOBファイルが8個だけ記述されているが、これは単なる一例であり、SD_AudioディレクトリはAOBファイルを最大999個まで格納することができる。）。このようにプレゼンテーションデータに著作権保護の必要性がある場合、プロテクト領域には、SD_Audioディレクトリという名称のサブディレクトリが設けられ、そのSD_Audioディレクトリの配下に暗号鍵格納ファイルAOBSA1.KEYが作成される。図８（ｂ）は、SD_Audioの下に格納された暗号鍵格納ファイルAOBSA1.KEYを示す図である。暗号鍵格納ファイルAOBSA1.KEYには、複数の暗号鍵FileKeyを所定の順序に配列してなる暗号鍵列であるFileKey#1〜#8が格納されている。
【００３３】
電子音楽配信において音楽会社のサーバコンピュータは、この図８（ａ）、（ｂ）に示すSD_Audioディレクトリを保持しており、当該音楽コンテンツの購入要求が消費者から発せられれば、このSD_Audioディレクトリを圧縮し、暗号化した後、購入要求を発した消費者が所有するSD_Audioディレクトリを公衆ネットワークを介して送信する。消費者が所有するコンピュータがこのSD_Audioディレクトリを受信すると、このディレクトリの暗号化を解除すると共に、伸長を行い、SD_Audioディレクトリを得る（尚、ここでいう公衆ネットワークは、ISDN回線等の有線通信網、携帯電話に代表される無線通信網等、公衆に利用が解放されている全てのネットワークを含む）。尚、AOBファイルを音楽会社のサーバコンピュータからダウンロードし、消費者が所有するコンピュータが、フラッシュメモリカード３１においてこの図８（ａ）、（ｂ）に示すSD_Audioディレクトリを作成しても良い。
【００３４】
{3-3_9-1} AOBSA1.KEYと、AOBファイルとの対応
図９は、SD_Audioの下にあるAOBSA1.KEYと、AOBファイルとの対応を示す図である。本図においてユーザデータ領域における暗号化ファイルを暗号化する際に用いたFileKeyは、プロテクト領域に対応する暗号鍵格納ファイルに格納される。
【００３５】
暗号化されたAOBファイルと、暗号鍵格納ファイルとは、以下の一定の規則(1)(2)(3)に基づく対応関係を有する。
(1)暗号鍵格納ファイルは、暗号化されたファイルが格納されているディレクトリと同じディレクトリ名に配置される。図９のユーザデータ領域においてSD_AudioディレクトリにAOBファイルが配されており、暗号鍵格納ファイルもSD_Audioディレクトリに配されていることからも、この規則に従った、ファイル配置が行われていることがわかる。
【００３６】
(2)暗号鍵格納ファイルには、データ領域におけるAOBファイルのファイル名の先頭3文字と、所定の拡張子「.key」とを組み合わせたファイル名が付与される。AOBファイルのファイル名が『AOB001.SA1』である場合、暗号鍵格納ファイルには、矢印nk1,nk2に示すように、この先頭３文字『AOB』と、『SA1』と、拡張子『.key』とからなる『AOBSA1.KEY』というファイル名が付与されることがわかる。
【００３７】
(3) AOBファイルのファイル名には、暗号鍵格納ファイル内の暗号鍵列において、そのオーディオオブジェクトに対応するFilekeyが何番目に位置するか、即ち、対応するFileKeyの順位を示すシリアル番号が付与される。
図９における暗号鍵格納ファイル内の『File Key Entry#1,#2,#3・・・・・#8』は、暗号鍵格納ファイル内の各FileKeyが格納されている領域の先頭位置を示す。一方AOBファイルのファイル名には、"001","002","003","004"といったシリアル番号が付与されている。これらのAOBファイル内のシリアル番号は、対応するFileKeyが暗号鍵列において何番目に位置するかを意味するので、各AOBファイルを暗号化する際に用いたFileKeyは、同一のシリアル番号を有する『File Key Entry』に存在することなる。図９における矢印AK1,AK2,AK3は、AOBファイルとFileKeyとの対応関係を示す。即ち、ユーザデータ領域におけるAOB001.SA1は『File Key Entry#1』に格納されているFileKeyと対応しており、AOB002.SA1は、『File Key Entry#2』以降に格納されたFileKey、AOB003.SA1は『File Key Entry#3』以降に格納されたFileKeyに対応していることを示す。以上の(3)からもわかるように、AOBファイルの暗号化に用いたFileKeyは、各ファイル毎に異なるものであり、それらは、ファイル名に組み込まれている"001","002","003","004"といったシリアル番号と、同一のシリアル番号を有する『File Key Entry』に格納されている。各AOBファイルは異なるFileKeyを用いて暗号化されるので、仮に、特定のAOBファイルの暗号化キーが暴露された場合でも、他のAOBファイルは、暴露されたFileKeyを用いても暗号化を解除することはできない。これにより、AOBファイルを暗号化した際のFileKeyが暴露された場合の損害を最小限に留めることができる。
【００３８】
{3-3_10-1} AOBファイルの内部構成
続いてAOBファイルの内部構成について説明する。図１０は、AOBファイルのデータ構成を階層的に示す図である。本図の第１段目は、AOBファイルを示し、第２段目は、AOBを示す。第３段目は、AOB_BLOCKを示し、第４段目はAOB_ELEMENT、第５段目は、AOB_FRAMEを示す。
【００３９】
図１０の第５段目における『AOB_FRAME』は、AOBを構成する最小単位であり、ADTSヘッダと、ADTS（Audio Data Transport Stream）形式のオーディオデータとからなる。ADTS形式のオーディオデータは、MPEG2-AAC [ Low Complexity Profile]にて符号化され、16Kbps〜144Kbpsの伝送速度で再生されるストリームデータである（尚、既存のコンパクトディスクに記録されるPCMデータの伝送速度は1.5Mbpsであるので、PCMデータと比較して、一段と低いことがわかる。）。これらのAOB_FRAME列のデータ構造は、電子音楽配信にて配信されるオーディオデータトランスポートに含まれるオーディオフレーム列と同一である。即ち、AOB_FRAME列として格納されるべきオーディオデータトランスポートストリームは、MPEG2-ACCにてエンコードされ、更に暗号化された状態で、公衆ネットワークを伝送し、消費者宛に伝送される。AOBファイルは、そのように伝送されたオーディオデータトランスポートストリームを、AOB_FRAME列として分割して格納しているのである。
【００４０】
｛3-3_10-1_11｝MPEG2-AACについて
MPEG2-AACの詳細に関しては、ISO/IEC 13818-7:1997(E) Information technology - Generic coding of moving pictures and associated audio information - Part7 Advanced Audio Coding (AAC)を参照されたい。ここで注意すべきは、AOBは、ISO/IEC13818-7に記述されているパラメータ表を図１１（ａ）のように制限して適用されたMPEG2-AAC方式にて圧縮されている点である。図１１（ａ）は、ISO/IEC13818-7に記述されているパラメータ表を示す図であり、Parameter欄と、Value欄と、Comment欄の内容を示すコメント欄とからなる。
【００４１】
パラメータ欄『profile』は、ISO/IEC 13838-7で規定されているLC-profileの制限が適用されていることを示す。
パラメータ欄『sampling_frequency#index』は、『48kHz,44.1kHz,32kHz,24kHz,22.05kHZ,16kHz』といったサンプリング周波数が適用されていることを示す。パラメータ欄『number_of_data_block_in_frame』は、1header/1raw_data_blockに設定されていることを示す。
【００４２】
尚、AOB_FRAMEは、MPEG-AAC方式にて符号化されているものとして説明したが、AOB_FRAMEは、MPEG-Layer3(MP3)方式、Windows（登録商標） Media Audio(WMA方式等他の符号化方式にて符号化されてもよい。この際、図１１（ａ）に示したパラメータの代わりに、図１１（ｂ）、図１１（ｃ）に示すパラメータ表を用いねばならない。
【００４３】
{3-3_10-2_12} AOB_FRAMEの構成
『AOB_FRAME』は、以上の制限下で符号化されたオーディオデータを含むが、AOB_FRAMEに含まれるオーディオデータのデータ長は、その再生時間が20ミリ秒となるデータに過ぎない。しかし、MPEG2-AAC方式は可変長符号化方式であるので、各AOB_FRAMEに含まれるオーディオデータのデータ長は、それぞれのAOB_FRAME毎に異なる。以下、図１２を参照しながら、AOB_FRAMEの構成の詳細について説明する。本図の第１段目は、AOB_FRAMEの全体構成を示し、第２段目は、AOB_FRAMEのそれぞれの部位がどのように暗号化されているかを示す。この第２段目を参照すれば、ADTSヘッダは、非暗号化部、即ち、暗号化がなされていないことがわかる。また、オーディオデータは、暗号化された部分と、非暗号化部分との双方を含む。暗号化部分は、8バイトの暗号化データを複数配したものである。8バイトの暗号化データは、64ビットの元データを56ビットのFileKeyを用いて暗号化することにより生成されている。非暗号化部分は、そのように64ビット単位に暗号化が行われた際、64ビットに満たないために暗号化されずに残したものである。
【００４４】
第３段目は、非暗号化部分であるADTSヘッダの内容を示す図である。ADTSヘッダは7バイトであり、12ビットの同期ワード(FFFと設定されている)と、同じAOB_FRAMEに含まれるオーディオデータのデータ長と、そのオーディオデータをエンコードする際のサンプリング周波数とが記載されている。
{3-3_10-3_13} AOB_FRAMEのバイト長設定
図１３は、3つのAOB_FRAMEにおいて、それぞれのAOB_FRAMEにおけるオーディオデータのバイト長がどのように設定されるかを示す図である。本図において、AOB_FRAME#1に含まれるオーディオデータ#1のデータ長はx1、AOB_FRAME#2に含まれるオーディオデータ#2のデータ長はx2、AOB_FRAME#3に含まれるオーディオデータ#3のデータ長はx3であり、x1,x2,x3というようにそれぞれのデータ長が互いに異なる場合、AOB_FRAME#1に含まれるADTSヘッダには、データ長x1が記載され、AOB_FRAME#2に含まれるADTSヘッダには、データ長x2、AOB_FRAME#3に含まれるADTSヘッダには、データ長x3が記載される。オーディオデータそのものは、暗号化されているが、ADTSヘッダ自体は暗号化されていないので、各AOB_FRAMEにおけるADTSヘッダから、オーディオデータのデータ長を読み取ってゆけば、後続するAOB_FRAMEがどこから存在するかを知得することができる。以上でAOB_FRAMEについての説明を終える。
【００４５】
{3-3_10-4} AOB_ELEMENTについて
続いて図１０において第４段目に位置するAOB_ELEMENTについて説明する。
『AOB_ELEMENT』は、連続する複数のAOB_FRAMEの集合である。ここで、どれだけの数のAOB_FRAMEがAOB_ELEMENTに含まれるかは、図１１（ａ）に示したsampling_frequency_indexの設定と、符号化方式とに従って変化する。即ち、AOB_ELEMENTに含まれるAOB_FRAMEの個数は、そのAOB_ELEMENTに含まれるAOB_FRAMEの再生時間が大体2秒になるように定められており、サンプリング周波数と、符号化方式に応じて、異なる個数となる。
【００４６】
{3-3_10-5_14} AOB_ELEMENTに含まれるAOB_FRAME数
図１４は、sampling_frequencyと、AOB_ELEMENTに含まれるAOB_FRAME数との対応を示す図である。本図においてNはAOB_ELEMENTの再生期間を秒単位に示したものであり、符号化方式がMPEG-AAC方式であれば"2"となる。またsampling_frequencyが48kHzである場合、AOB_ELEMENTに含まれるフレーム数は、94(=47×2)個となり、sampling_frequencyが44.1kHzである場合、AOB_ELEMENTに含まれるフレーム数は86(=43×2)個、sampling_frequencyが32kHzである場合、AOB_ELEMENTに含まれるフレーム数は64(=32×2)個、sampling_frequencyが24kHzである場合、フレーム数は48(=24×2)個、sampling_frequencyが22.05kHzである場合、AOB_ELEMENTに含まれるフレーム数は44(=22×2)個、sampling_frequencyが16kHzである場合、AOB_ELEMENTに含まれるフレーム数は32(=16×2)個となる。但し、AOBを分割などの編集を行った場合、AOBの先頭と最後のAOB_ELEMENTのAOB_FRAME数は、図１４の個数より少なくなる場合がある。
【００４７】
AOB_ELEMENTには、ヘッダ等の特別な情報は付与されていないが、その代わりにそのデータ長がタイムサーチテーブルに示されている。
{3-3_10-6_15} AOB_ELEMENT及びAOB_FRAMEの時間長の一例
図１５は、AOB_ELEMENTの時間長及びAOB_FRAMEの時間長の一例を示す図である。本図の第１段目は、複数AOB_BLOCKの並びであり、第２段目は、複数AOB_ELEMENTの並びを示す。第３段目は、複数AOB_FRAMEの並びを示す。
【００４８】
本図を参照すると、AOB_ELEMENTは、約2.0秒という再生時間長に相当し、本図におけるAOB_FRAMEは、20msecという再生時間長に対応することが判る。AOB_ELEMENTのそれぞれに付されている『TMSRT_entry』という文字列は、各AOB_ELEMENTのデータ長がタイムサーチテーブルに記載されていることを示す。このようなTMSRT_entryを参照して、順方向サーチ再生、逆方向サーチ再生を行うことにより、例えば2.0秒をスキップして、240ミリ秒分だけ再生するという間欠な再生を実現することができるのである。
【００４９】
{3-3_10-7} AOB_BLOCKについて
以上でAOB_ELEMENTについての説明を終え、続いてAOB_ELEMENTの上位、即ち、図１０のAOBファイルのデータ構成を示す図における第３段目に位置するのAOB_BLOCKについて説明する。
『AOB_BLOCK』は、有効なAOB_ELEMENTからなる領域であり、AOBファイル中に一つ存在する。AOB_ELEMENTが2秒という再生時間に相当するのに対して、AOB_BLOCKは8.4分の再生時間を上限とした再生時間に相当する。各AOBを8.4分の再生時間に限定した理由は、AOB_BLOCKに含まれるAOB_ELEMENTの個数を制限することにより、タイムサーチテーブルのサイズを504バイト以下に抑制するためである。
【００５０】
{3-3_10-8} タイムサーチテーブルの抑制
以下、再生時間の限定により、タイムサーチテーブルの抑制が可能となった理由を詳細に説明する。
順方向サーチ再生、逆方向サーチ再生の再生を行う際、2秒分読み出しをスキップして240ミリ秒だけ再生するという『2秒スキップ240ミリ秒再生』が行われる。このように2秒という時間長をスキップする場合、原則として、AOB_FRAMEのADTSヘッダに示されているデータ長を順次参照してゆけばよいのだが、その場合、2秒という時間間隔をスキップするために100個(=2秒／20ミリ秒)ものAOB_FRAMEを順次検出せねばならず、再生装置に余分な処理負荷を与えてしまう。そのような処理負荷を軽減するには、その2秒間隔の読出先アドレスをタイムサーチテーブルに記述して、順方向サーチ再生及び逆方向サーチ再生が命じられた際、再生装置がこれを参照すればよい。即ち、タイムサーチテーブルには、2秒先、4秒先の読出先アドレスを算出するための情報、具体的には、各AOB_ELEMENTについてのデータ長を記述しておき、再生装置は、これを参照して、順方向サーチ再生-逆方向サーチ再生を行えばよいのである。2秒に相当するデータ長がどの程度になるかについて考察する。オーディオデータの再生時のビットレートは、上述したように16Kbps〜144Kbpsの範囲であるので、2秒当たりに再生されるデータ長は4Kbyte(=16Kbps×2／8)〜36Kbyte(=144Kbps×2/8)となる。
【００５１】
2秒当たりのデータ長が4Kbyte〜36Kbyteであるなら、オーディオデータのデータ長が記述されるためのタイムサーチテーブル内のエントリーのデータ長は、2バイト(16ビット)必要となる。何故なら、エントリーに16ビット長を割り当てたならば、0〜64KByteの数値が記述されることができるからである。一方、タイムサーチテーブルの総データサイズを例えば504バイト(これは後述するTKTMSRTのデータサイズである)内に制限する場合を考えると、このタイムサーチテーブル内に設けるべきエントリーは、252(=504/2)個に制限せねばならない。上述したように、エントリーは、2秒毎に設けられるものであるので252エントリーに対応する再生時間は、504秒(=2秒×252)となり、8分24秒(=8.4分)となる。このようにAOB_BLOCKにおける再生時間を8.4分以下に制限したことにより、タイムサーチテーブルのデータサイズを504バイト以下とすることができる。
【００５２】
{3-3_10-9} AOBについて
以上でAOB_BLOCKについての説明を終え、続いてAOBについて説明する。
図１０の第２段目に位置するAOBは、AOB_BLOCKの前後に無効領域が付与された領域であり、AOBファイル中に一つ存在する。
この無効領域は、当該、AOB_BLOCKと同じクラスタに格納され、当該AOB_BLOCKと供に読み書きされる領域である。AOBにおいて、何処から何処までがAOB_BLOCKに該当するのかは、ナビゲーションデータに含まれるBIT(その詳細についての説明は、後段で行う。)にて指定される。
【００５３】
以上で、各AOBファイルにどのようなデータが格納されているかが明らかとなった。続いて、図９に示した8つのAOBファイルに含まれるAOB、AOB_BLOCKが連続して読み出されることにより、どのような内容が再生されるかを説明する。
{3-3_10-10_16}
図１６は、AOBファイルに収録されている各AOB、AOB_BLOCKが連続して再生されることにより、どのような再生内容が再生されるかを示す。第１段目は、ユーザデータ領域における8つのAOBファイルを示し、第２段目は、各AOBファイルに収録されている8つのAOBを示す。第３段目は、それぞれのAOBに含まれる8つのAOB_BLOCKを示す。
【００５４】
第５段目は、5つのコンテンツ部からなるタイトルを示す。5つのコンテンツ部は、SongA、SongB、SongC、SongD、SongEという5つの曲のそれぞれを示し、タイトルは、これら5つの曲（コンテンツ）からなる音楽アルバムを示す。破線AS1,AS2,AS3・・・・AS7,AS8は、音楽アルバムの分割部分と、AOB_BLOCKとの対応関係を示し、第４段目は、第５段目の音楽アルバムがどのような単位で分割されるかを示す。
【００５５】
これらの破線を参照すると、各AOB#1に含まれるAOB_Blockは、6.1分という時間にて再生される曲(SongA)であり、各AOB#2に含まれるAOB_Blockは、3.3分という時間にて再生される曲(SongB)、各AOB#3に含まれるAOB_Blockは、5.5分という時間にて再生される曲(SongC)である。以上のようにAOB001.SA1〜AOB003.SA1は、それぞれが独立した曲に対応するものであることがわかる。第６段目は、TrackA〜Eからなるトラックシーケンスを示す。これらTrackA〜Eは、SongA、SongB、SongC、SongD、SongEという5つの曲のそれぞれと1対1に対応しており、一個の独立した再生単位として扱われる。
【００５６】
一方、AOB#4は、30.6分という時間にて再生される曲(SongD)の先頭部分であり、8.4分という再生時間にて再生される。AOB#5、AOB#6に含まれるAOB_BLOCKはSongDの中間部分であり、8.4分という再生時間、AOB#7に含まれるAOB_BLOCKは、SongDの終端部分であり、5.4分という再生時間にて再生される。このように30.6分という再生時間を有する曲は、(8.4分+8.4分+8.4分+5.4分)という単位で分割され、各AOBに含まれていることがわかる。この図からも理解できるように、AOBファイルに含まれる全ての曲は、再生時間長が8.4分という時間長以内に収められていることがわかる。
【００５７】
以上の説明によりAOBの再生時間長を制限することにより、各AOBに対応づけられているタイムサーチテーブルのデータサイズも制限されていることが明らかとなった。続いて、このタイムサーチテーブルを含むナビゲーションデータについて説明する。
{3-3_8A,B-2}
ナビゲーションデータは、『SD_Audio.PLM』『SD_Audio.TKM』という2つのファイルからなることは既に述べた通りである。ファイル『SD_Audio.PLM』は、プレイリストマネージャ(Playlistmanager)を含み、ファイル『SD_Audio.TKM』は、トラックマネージャ(TrackManager)を含む。
【００５８】
プレゼンテーションデータの説明で述べたように、複数のAOBファイルは、符号化されたAOBを収録しているが、これらのAOBの再生時間がどれだけであるか、また、それぞれのAOBがどのような曲名であり、作曲者は誰であるか等は何等記載されていない。一方、複数のAOBは、複数のAOBファイルに収録されているのみなので、それらをどのような順序で再生させるかは一切記載されていない。トラックマネージャ、プレイリストマネージャーは、こういった情報を再生装置に通知するために設けられている。
【００５９】
ここでトラックマネージャーは、AOBファイルに収録されているAOBと、トラックとの対応関係を示し、これらのAOBの再生時間がどれだけであるか、また、それぞれのAOBがどのような曲名であり、作曲者は誰であるか等の諸情報を示す複数のトラック管理情報を含む。トラックとは、ユーザにとって意味のある再生単位であり、フラッシュメモリカード３１に音楽著作物を格納しようとする場合、トラックは曲に対応し、フラッシュメモリカード３１にリーディングブックを格納しようとする場合（リーディングブックとは、書籍ではなく、読み上げ音声により表現された文書著作物をいう）、ブックジャンルであるなら、トラックは、文の章／節に対応する。トラックマネージャーは、複数AOBファイルに収録されている複数のAOBをトラックの集合として管理するために設けられている。
【００６０】
プレイリストとは、トラックの複数の再生順序を規定するものであり、プレイリストマネージャーは、このようなプレイリストを複数含んでいる。
以降、トラックマネージャーについて図面を参照しながら説明する。
{17-1_18} Playlistmanager及びTrackManagerの詳細構成
図１７は、実施形態におけるPlaylistmanager及びTrackManagerの構成を段階的に詳細化した図であり、図１８は、PlayListManager及びTrackManagerのサイズを示す図である。即ち、本図において右段に位置する論理フォーマットは、その左段に位置する論理フォーマットを詳細化したものであり、破線に示す引き出し線は、右段の論理フォーマットがその左段の論理フォーマット内のどの部分を詳細化したかを明確にしている。
【００６１】
このような表記に従って図１７におけるTrackManagerの構成を参照すると、TrackManagerは、破線の引き出し線h1に示すように、Track Information(TKIと略す)#1,#2,#3,#4・・・・・#nからなる。これらのTKIはAOBファイルに収録されているAOBを、トラックとして管理するための情報であり、各AOBファイルに対応している。
【００６２】
図１７を参照すると各TKIは、破線の引き出し線h2に示すように、Track_General_Informatin(TKGI) 、TKIに固有なテキスト情報が記述されるTrack_Text_Infomation_Data_Area(TKTXTI_DA)、タイムサーチテーブルの役割を有するTrack_Time_Serch_Table(TKTMSRT)からなることがわかる。図１８を参照すると、TKI自体は固定サイズ（1024バイト）であり、TKGIとTKTXTI_DAとは合計で512バイト固定長であることがわかる。TKTMSRTも512バイト固定長である。またTrackManagerにおいて、TKIは、最大999個まで設定することができる。
【００６３】
このTKTMSRTは、破線の引き出し線h3に示すように、TMSRT_Headerと、TMSRT_etry#1,#2,#3・・・・・#nとからなることがわかる。
{17-2_19} TKIと、AOBファイル及びAOBとの相互関係
図１９は、図１７に示したTKIと、図１６に示したAOBファイル及びAOBとの相互関係を示す図である。図１９の第１段目における四角枠はTrackA〜Eとからなるトラックシーケンス、図１９の第２段目における四角枠はTrackManagerを示し、第３、第４段目は図１６に示した8つのAOBファイルを示す。第５段目における8つの枠は、8つのAOBを示す。この8つのAOBファイルは、図１６に示した8つのAOBを収録していたものであり、TrackA、TrackB、TrackC、TrackD、TrackEを含む音楽アルバムを形成している。第２段目は、8つのTKIを示す。これらTKIに付与された数値"1","2","3","4"は、各TKIを識別するためのシリアル番号であり、各TKIは、同じシリアル番号001,002,003,004,005・・・・・が付与されたAOBファイルと対応づけられている。この点に注意して、図１９を参照すれば、TKI#1がAOB001.SA1に対応していて、TKI#2がAOB002.SA1、TKI#3がAOB003.SA1、TKI#4がAOB004.SA1に対応していることがわかる（本図における矢印TA1,TA2,TA3,TA4・・・・・・は、各TKIがどのAOBファイルと対応しているかを示す。）。このように各TKIは、各AOBファイルに収録されているAOBと、1対1の対応関係を有するので、各TKIには、AOBに固有な情報を詳細に記載しておくことができる。
【００６４】
{17-3_20} TKTMSRTのデータ構造について
AOBファイルに収録されているAOBに固有な情報として、先ず初めにTKTMSRTについて説明する。図２０は、図１７に示したTKTMSRTの詳細なデータ構造を示す図である。本図の右側には、タイムサーチテーブルヘッダ(TMSRT_Header)の詳細なデータ構造が示されている。図２０において、タイムサーチテーブルヘッダのデータサイズは8バイトであり、TMSRT_ID(0バイト目から1バイト目まで)、reserved(2バイト目から3バイト目まで)、Total TMSRT_entry_Number(4バイト目から7バイト目まで)という3つのフィールドを有する。『TMSRT_ID』には、TMSRTを一意に識別できるIDが記述される。『Total TMSRT_entry Number』には、当該TMSRT内にあるTMSRT_entryの総数が記述される。
【００６５】
{17-3_21-1} TKTMSRTの具体例について
続いてTKTMSRTについてより詳細に説明する。図２１は、TKTMSRTについての一例を示す図である。本図の左側に、AOBを示し、右側にTKTMSRTを示す。本図左側のAOBは、複数のAOB_ELEMENT#1,#2,#3・・・・・・#nからなり、その右側における複数の領域AR1,AR2,AR3・・・・・・ARnを占有している。また図中の『0』『32000』『64200』『97000』『1203400』『1240000』といった数値は、AOBに含まれるAOB_BLOCK先頭からの各AOB_ELEMENTの占有領域AR1,AR2,AR3,ARn-1,ARnまでの相対アドレスを示す。AOB_ELEMENT#2は、AOB_BLOCK先頭から『32000』だけ隔てられた位置に記録されていることを示す。AOB_ELEMENT#3は、AOB_BLOCK先頭から『64200』だけ隔てられた位置に、AOB_ELEMENT#n-1は、AOB_BLOCK先頭から『1203400』だけ隔てられた位置に記録されていることを示す。
【００６６】
注意すべきは、各占有領域の先頭アドレスの間隔が一定値ではないこと、即ち、各AOB_ELEMENTの占有領域が、それぞれ異なるサイズだけ複数クラスタを占有していることである。各占有領域のサイズがそれぞれ異なるのは、各AOB_FRAMEにおける符号割り当てが可変長だからである。
各AOB_ELEMENTの占有サイズが異なるので、各AOB_ELEMENTの先頭にジャンプする場合、各AOB_ELEMENTがAOB内の何処に存在するかを予め再生装置に指示しておく必要がある。このような目的をもって、複数のTMSRT_entryは記載されている。矢印RT1,RT2,RT3・・・・・・RTn-1,RTnは、これら各AOB_ELEMENTの占有領域AR1,AR2,AR3・・・・・・ARn-1,ARnと、TMSRT_entry#1、TMSRT_entry#2、TMSRT_entry#3・・・・・・TMSRT_entry#n-1,TMSRT_entry#nとの対応関係を示す。即ち、AOB_ELEMENT#1の占有領域AR1がどれだけのサイズを占有しているかがTMSRT_entry#1に記載され、AOB_ELEMENT#2、AOB_ELEMENT#3の占有領域AR2,AR3がどれだけのサイズを占有しているかがTMSRT_entry#2、TMSRT_entry#3に記載される。
【００６７】
ここで、占有領域AR1は、AOBの先頭から、AOB_ELEMENT#2の先頭『32000』迄を占有しているので、TMSRT_entry#1は32000(=32000-0)と記述され、占有領域AR2は、AOB_ELEMENT#1の先頭『32000』から、AOB_ELEMENT#2の先頭『64200』迄を占有しているので、TMSRT_entry#2は『32200(=64200-32000)』と記述、占有領域AR3は、AOB_ELEMENT#3の先頭『64200』から、AOB_ELEMENT#4の先頭『97000』迄を占有しているので、TMSRT_entry#3は『32800(=97000-64200)』、占有領域ARn-1は、AOB_ELEMENT#n-1の先頭『1203400』から、AOB_ELEMENT#nの先頭『1240000』迄を占有しているので、TMSRT_entry#n-1は『36600(=1240000-1203400)』と記述されている。
【００６８】
{17-3_21-2} TKTMSRTの読み出し方式
このようにタイムサーチテーブルには、AOB_ELEMENTのデータサイズが記載されていることがわかる。一方、AOB_ELEMENTの説明で述べたように、各AOB_BLOCKのデータ長は、再生時間が8.4分内になるように定めらているので、1つのAOBに含まれるAOB_ELEMENTの総数は、所定数(図２０に示す252個)以下に抑えられている。AOB_ELEMENT数が所定数以下に抑えられるので、AOB_ELEMENTに対応するTMSRT_entryの総数も所定数以下となり、これらを含むTKTMSRTのデータサイズも所定サイズ以下となる。TKTMSRTのサイズを抑制したため、再生装置は、以下のようにTKIを読み出して、利用することができる。
【００６９】
あるAOBが読み出されて、その再生が開始されると、それに対応するTKIを読み出して、メモリに格納する。以降、当該AOBの再生が継続している期間において、このTKIをメモリに格納しておく。当該AOBの再生が終われば、これに後続するAOBが読み出されて、その再生が開始されると、それに対応するTKIを読み出して、それまでメモリ上に格納されていたTKIを、新たに読み出されたTKIを用いて上書きする。以降、当該AOBの再生が継続している期間において、このTKIをメモリに格納しておく。
【００７０】
TKIの読み出しと、メモリへの格納とをこのように行えば、再生装置におけるメモリの実装量が小規模であっても、必要なTKIを読み出すだけで順方向サーチ再生、逆方向サーチ再生といった特殊再生を行うことができる。尚、本実施形態では、あるAOB_ELEMENTの先頭アドレスから次のAOB_ELEMENTの先頭アドレスまでのデータ長をTMSRT_entryとして記載したが、AOB_BLOCKの先頭から、各AOB_ELEMENTの先頭までの相対アドレスを記載してもよい。
【００７１】
{17-3_21-3} AOB_ELEMENTを含むクラスタの特定
最後にTKTMSRTを参照して、任意のAOB_ELEMENTをどうやって読み出せばよいかについて説明する。各AOB_ELEMENTのサイズが記載されたTKTMSRTを参照して、AOBにおいて先頭からy番目に位置するAOB_ELEMENT#yを読み出す場合、以下の｛数式１｝を満たすクラスタuを求めて、そのクラスタuの先頭からオフセットv以降を読み出せばよい。
｛数式１｝
クラスタu = (AOB_ELEMENT#1からAOB_ELEMENT#y-1までのTMSRT_entryの総和+DATA_Offset)／クラスタサイズ
オフセットv =(AOB_ELEMENT#1からAOB_ELEMENT#y-1までのTMSRT_entryの総和+DATA_Offset) mod クラスタサイズ
c =a mod bとある場合、cは、aをbで割った場合の余りを示し、DATA_Offsetは、BITに記載されている情報であり、後述する。
【００７２】
{17-4} TKTXTI_DAについて
以上で、タイムサーチマップ(TKTMSRT)の説明を終わる。次に、図１７においてTKTMSRTの上段に記載されているTrack Text Information Data Area(TKTXTI_DA)について説明する。
Track Text Information Data Area(TKTXTI_DA)には、アーティスト名、アルバム名、編曲者名、プロデューサ名等を示すテキスト情報が記述される。テキストデータが存在しない場合でも、この領域は確保される。
【００７３】
{17-5} TKGIについて
続いてTKTXTI_DAの上段にあるTKGIについて説明する。図１７においてTKIのTKGIは、破線の引き出し線h4に示すように、TKIの識別子『TKI_ID』、TKI番号『TKIN』、TKIのサイズ『TKI_SZ』、次のTKIへのリンクポインタ『TKI_LNK_PTR』、ブロック属性『TKI_BLK_ATR』、再生時間『TKI_PB_TM』、TKIのオーディオ属性『TKI_AOB_ATR』、『ISRC』、ブロック情報『BIT』という一連の情報が記録されていることがわかる（尚、本図は、説明の簡略化のため、一部のフィールドについては省略して表記している。）。
【００７４】
{17-5_22-1} TKGIについて
以下、図２２を参照しながらTKGIの詳細構成について説明する。本図と、図１７との違いは、図１７に示したTKGIのデータ構成が図中左側に配置されており、図１７では明らかにされてなかった『TKI_BLK_ATR』,『TKI_AOB_ATR』,『ISRC』のビット構成が、図中の右側に配置されている点である。
【００７５】
{17-5_22-2} TKI_IDについて
『TKI_ID』には、TKIを一意に識別できるID(本実施形態では2バイトの"A4"というコード)が記述される。
{17-5_22-3} TKINについて
『TKIN』には、1から999までの範囲のTKI番号が記述される。なお、このTKI番号は他のTKIのTKINに記述されるTKI番号と重複してはならない。このようなTKINとして、TrackManagerにおけるTKIの順位、即ち、TrackManagerにおいてTKIが何番目に位置するかを記述するものとする。本図におけるTKI#1なら、TKI番号は、"1"と記載され、TKI#2ならTKI番号は、"2"と、TKI#3ならTKI番号は、"3"と記載される。
【００７６】
{17-5_22-4} TKI_SZについて
『TKI_SZ』には、TKIのデータサイズがバイト数単位で記述される。図２２では、TKIのデータサイズが1024バイトと規定されているので、本実施形態において1024バイトと記述される。
{17-5_22-5} TKI_LNK_PTRについて
『TKI_LNK_PTR』には、当該TKIのリンク先のTKIについてのTKINが記述される。ここで、TKI間の対応関係について説明する。
【００７７】
トラックが複数のAOBから構成され、それらが複数のAOBファイルに収録されている場合、それら複数のAOBファイルに対応づけられている複数のTKIは一体となって、当該トラックを管理することになる。このように複数のTKIが一体となっている場合、これらTKIに対応するAOBファイルに、どのTKIに対応するAOBファイルが後続するかを示す必要がある。TKI_LNK_PTRは、各TKIに後続するTKIについてのTKINを記述するという用途に用いられる。
【００７８】
{17-5_22-6_19} TKI_LNK_PTRについて
以降、図１９に示した8つのTKIにおいて、TKI_LNK_PTRがどのように設定されているかについて説明する。１トラックを構成するTKI#1〜TKI#3、TKI#8において、そのTKI_LNK_PTRは設定されないが、TrackDを構成する4つのAOBファイルに対応するTKI#4、TKI#5、TKI#6、TKI#7は、各TKI_LNK_PTRが次のTKI_LNK_PTRを指示するよう設定されている。即ち、矢印TL4,TL5,TL6に示すように、TKI#4のTKI_LNK_PTRはTKI#5を指示しており、TKI#5のTKI_LNK_PTRはTKI#6を、TKI#6のTKI_LNK_PTRはTKI#7を指示している。これらは、何れもTrackDを構成する。4つのAOBファイルに対応づけられているTKIにおけるこれらTKI_LNK_PTRを参照することにより、TKI#4〜TKI#7という4つのTKI、及びAOB004.SA1〜AOB007.SA1という4つのAOBファイルが、一体となってTrackDを構成しているということがわかる。
【００７９】
{17-5_22-7} TKI_BLK_ATRについて
『TKI_BLK_ATR』には、TKIについての属性が記述される。図２２においてTKI_BLK_ATRから破線にて引き出された枠に、TKI_BLK_ATRのビット構成を示す。本図においてTKI_BLK_ATRは16ビットであり、b3ビットからb15ビットまでが将来の拡張のために確保されている。ビット番号b2からb0までの3ビットを用いて、TKIについての属性が記述される。
【００８０】
TKIが使用されており、１個のTKIが１個のトラックに含まれる場合、TKI_BLK_ATRには"000b"の値が記述される(以降、この設定を『Track』という。)。TKIが使用されており、１トラックが複数のTKIを含み、当該TKIがその先頭である場合は、TKI_BLK_ATRには"001b"の値が記述される（以降、この設定を『Head_of_Track』という。）。TKIが使用されており、１トラックが複数のTKIから構成され、当該TKIがその中間である場合は、TKI_BLK_ATRには"010b"の値が記述される（以降、この設定を『Midpoint_of_Track』という）。TKIが使用されており、１トラックが複数のTKIから構成され、当該TKIがその終端である場合、TKI_BLK_ATRには"011b"の値が記述される（以降、この設定を『End_of_Track』という。）。TKIが未使用であり、TKIの領域がある場合、すなわち削除されたTKIである場合は、"100b"の値が記述される（以降、この設定を『Unused』という）。TKIが未使用であり、TKIの領域がない場合、すなわち初期状態のTKIである場合は、"101b"の値が記述される。
【００８１】
{17-5_22-8_19} TKI_BLK_ATRの設定例
図１９の一例では、それぞれのTKIについてのTKI_BLK_ATRがどのように設定されているかについて説明する。
各TKIにおけるTKI_BLK_ATRを参照すれば、TKI#1（AOB001.SA1）、TKI#2（AOB002.SA1）、TKI#3（AOB003.SA1）、TKI#8（AOB008.SA1）という4つの組みは、それぞれが独立したトラックに対応しているので、TKI#1、TKI#2、TKI#3、TKI#8のTKI_BLK_ATRは、『Track』と設定されている。
【００８２】
TKI#4におけるTKI_BLK_ATRは『Head_of_Track』と設定され、TKI#7におけるTKI_BLK_ATRは『End_of_Track』と、TKI#5、TKI#6は『Midpoint_of_Track』と設定されていることがわかる。このことは、TKI#4と対応関係を有するTKI#4（AOB004.SA1）はトラックの先頭部と、TKI#5、TKI#6と対応関係を有するTKI#5（AOB005.SA1）及びTKI#6（AOB006.SA1）はトラックの中間部と、TKI#7と対応関係を有するTKI#7（AOB007.SA1）はトラックの終端部であることを意味する。
【００８３】
このように各TKIにおけるTKI_BLK_ATRの記載に従って、TKI（AOBファイル）の組みを分類すれば、TKI#1（AOB001.SA1）が1つ目のトラック(TrackA)を構成していることがわかる。TKI#2（AOB002.SA1）が2つ目のトラック(TrackB)、TKI#3（AOB003.SA1）が3つ目のトラック(TrackC)を構成していることがわかる。
TKI#4（AOB004.SA1）が4つ目のトラック(TrackD)の先頭部分を構成しており、TKI#5（AOB005.SA1）、TKI#6（AOB006.SA1）がTrackDの中間部分を構成しており、TKI#7（AOB007.SA1）がTrackDの終端部分を構成していることがわかる。TKI#8（AOB008.SA1）は独立して5つ目のTrackEの終端部分を構成していることがわかる。
【００８４】
{17-5_22-9} TKI_PB_TMについて
『TKI_PB_TM』には、TKIに対応するAOBファイルに収録されているAOBにより構成されるトラック(曲)の再生時間が記述される。
トラックが複数のTKIから構成される場合、先頭のTKIについてのTKI_PB_TMには、トラック全体の再生時間が記述される。また2番目以降のTKIには、それぞれのTKIに対応するAOBの再生時間が記述される。
【００８５】
{17-5_22-10} TKI_AOB_ATRについて
『TKI_AOB_ATR』には、TKIに対応するAOBファイルに収録されているAOBがどのようなサンプリング周波数でサンプリングされているか、どのようなビットレートで転送されるか、チャネル数がどれだけであるか等、AOBを生成する際のエンコード条件が記述される。『TKI_AOB_ATR』から破線にて引き出された枠は、TKI_AOB_ATRのビット構成を示す。本図においてTKI_AOB_ATRは、20ビットであり、ビット番号b16からビット番号b19までのフィールドには、コーディングモードが記述される。MPEG-2 AAC(with ADTS header)でエンコードされている場合には、"0000b"の値が、MPEG-layer3(MP3)でエンコードされている場合には、"0001b"の値が、Windows（登録商標） Media Audio(WMA)でエンコードされている場合、"0010b"がそれぞれ記述される。
【００８６】
ビット番号b15からビット番号b8までのフィールドには、ビットレートが記述される。MPEG-2 AAC(with ADTS header)でエンコードされている場合には、"16"〜"72"の値が、MPEG1-layer3(MP3)でエンコードされている場合には"16"〜"96"の値が、MPEG2-layer3(MP3) LSFでエンコードされている場合には"16"〜"80"の値が、Windows（登録商標） Media Audio(WMA)でエンコードされている場合、"8"〜"16"の値がそれぞれ記述される。
【００８７】
ビット番号b7からビット番号b4には、サンプリング周波数が記述される。48kHzの場合は"0000b"、44.1kHzの場合は"0001b"、32kHzの場合は"0010b"、24kHzの場合は"0011b"、22.05kHzの場合は"0100b"、16kHzの場合は"0101b"の値が記述される。
ビット番号b3からビット番号b1までのフィールドには、チャネル数が記述される。1ch(mono)の場合は、"000b"が記述される。2ch(stereo)の場合は、"001b"が記述される。
【００８８】
ビット番号b31からビット番号b20、およびビット番号b0の領域は、将来の拡張用に予約されている。
{17-5_22-11} ISRCについて
『ISRC』には、TKGIにおけるISRC（International Standard Recording Code）が記述される。図２２における『ISRC』から破線にて引き出された枠はISRCの内容を示す。この枠に示されているように、ISRCは、10バイトからなり、ビット番号b4からビット番号b7までのフィールドにRecording-item code(#12)が記述され、ビット番号b8からビット番号b11までのフィールドにRecording code/Recording-item code(#11)が記述される。
【００８９】
ビット番号b12からビット番号b23までのフィールドにRecording code(ISRC#10,#9,#8)が記述される。ビット番号b24からビット番号b31までのフィールドにYear-of-Recording code(ISRC#6,#7)が記述される。
以降、ビット番号b32からビット番号b37までのフィールド、ビット番号b40からビット番号b45までのフィールド、ビット番号b48からビット番号b53までのフィールドには、First Owner Code(ISRC#3,#4,#5)が記述される。ビット番号b56からビット番号b61までのフィールド、ビット番号b64からビット番号b69までのフィールドには、Country code(ISRC#1,#2,#3)が記述される。ビット番号b79のフィールドには、1ビットのValidity flagが記述される。尚、ISRCの詳細については、ISO3901 : 1986 ''Documentation-International Standard Recording Code (ISRC) ''を参照されたい。
【００９０】
{17-5_22-12_23A-1} BITについて
『ブロック情報テーブル(BIT)』は、AOB_BLOCKを管理するテーブルである。図２３（ａ）、（ｂ）は、BITの詳細構成を示す図である。図２３（ａ）に示すように、BITは、60バイト目から63バイト目までを占めるDATA_OFFSETフィールドと、64バイト目から67バイト目までを占めるSZ_DATAフィールドと、68バイト目から71バイト目までを占めるTMSRTE_Nsフィールドと、72バイト目から73バイト目までを占めるFNs_1st_TMSRTEフィールドと、74バイト目から75バイト目までを占めるFNs_Last_TMSRTEフィールドと、76バイト目から77バイト目までを占めるFNs_Middle_TMSRTEフィールドと、78バイト目から79バイト目までを占めるTIME_LENGTHフィールドとからなる。以下、各構成要素の説明を行う。
【００９１】
{17-5_22-12_23A-2} DATA_Offsetについて
『DATA_OFFSET』には、クラスタ境界から各AOB_BLOCKの先頭までの相対アドレスがバイト単位で記述される。これにより、AOBからAOB_BLOCKまでの間に無効領域がどれだけ存在するかが表現される。AOBとしてフラッシュメモリカード３１に格納されている音楽が、エアチェックして録音された音楽であり、その音楽のイントロの部分にディスクジョッキーの音声が混じっている場合、BITにおけるDATA_Offsetを設定することにより、この不要音声をAOB_BLOCKから除外して再生させないようにすることができる。
【００９２】
{17-5_22-12_23A-3} SZ_DATAについて
『SZ_DATA』には、各AOB_BLOCKのデータ長がバイト単位で記述される。SZ_DATAとDATA_Offsetとを加算した値をAOBを収録しているファイルサイズ(クラスタサイズの整数倍)から差し引けば、AOB_BLOCKに後続する無効領域がどれだけのサイズであるかを求めることができる。
【００９３】
{17-5_22-12_23A-4} TMSRTE_Nsについて
『TMSRTE_Ns』には、各AOB_BLOCKに含まれるTMSRT_entryの総数が記述される。
{17-5_22-12_23A-5} 『FNs_1st_TMSRTE』、『FNs_Last_TMSRTE』、『FNs_Middle_TMSRTE』について
『FNs_1st_TMSRTE』には、当該AOB_BLOCK中の先頭に位置するAOB_ELEMENTに含まれるAOB_FRAME数が記述される。
【００９４】
『FNs_Last_TMSRTE』には、AOB_BLOCKの最後尾のAOB_ELEMENTに含まれるAOB_FRAMEの個数が記述される。
『FNs_Middle_TMSRTE』には、先頭と最後尾のAOB_ELEMENTを除くAOB_ELEMENT、即ち、AOB_BLOCKの中間部に位置するAOB_ELEMENTに含まれるAOB_FRAMEの個数が記述される。
【００９５】
『TIME_LENGTH』は、図２３（ｃ）に示すフォーマットにてAOB_ELEMENTの再生期間をミリ秒オーダーの時間精度で記述するフィールドである。図２３（ｃ）に示すように、TIME_LENGTHフィールドは、16ビット長であり、符号化方式がMPEG-AAC方式やMPEG-Layer3方式であれば、AOB_ELEMENTの再生期間は2秒となるので、TIME_LENGTHには、2000の値が記述される。
【００９６】
{17-5_22-13_23B}
図２３（ｂ）は、FNs_Middle_TMSRTEにAOB_FRAMEが幾つ格納されているかを示す図である。本図は図１４同様、sampling_frequencyと、中間部のAOB_ELEMENTに含まれるAOB_FRAME数との対応関係を示している。本図におけるsampling_frequencyと、AOB_ELEMENTに含まれるフレーム個数との対応関係は図１４と全く同一であり、サンプリング周波数に応じて異なる個数になっていることがわかる。『FNs_1st_TMSRTE』及び『FNs_Last_TMSRTE』におけるフレーム数は、『FNs_Middle_TMSRTE』におけるフレーム数と原則同一のフレーム数に設定されるが、AOB_BLOCKの先頭又は末尾に位置するAOB_ELEMENTに無効領域を設定する場合、『FNs_1st_TMSRTE』及び『FNs_Last_TMSRTE』は、『FNs_Middle_TMSRTE』と異なる値となる。
【００９７】
{17-5_22-14_24} AOB_ELEMENTの格納例
図２４は、AOB_ELEMENT#1〜#4からなるAOBが格納されているクラスタ007〜クラスタ00Eを示す図である。AOBが図２４に示すように格納されている場合に、BITがどのように設定されるかについて説明する。これらクラスタ007〜クラスタ00Eに格納されているAOB_ELEMENT#1〜AOB_ELEMENT#4のそれぞれには、三角旗状の記号が付与されているが、これらは、AOB_ELEMENT#1〜AOB_ELEMENT#4のそれぞれに、TKIに含まれるTMSRT_entryが設定されていることを示す。
【００９８】
この際、AOB先端におけるAOB_ELEMENT#1の先端部分は、クラスタ007に格納されており、AOB末尾におけるAOB_ELEMENT#4の終端部分は、クラスタ00Eに格納されている。AOB_ELEMENT#1〜#4は、クラスタ007の途中md0からクラスタ00Eの途中md4迄を占有している。BIT内のSZ_DATAは、矢印sd1に示すようにAOB_ELEMENT#1からAOB_ELEMENT#4の最後までを指示しており、クラスタ007,00E内の領域であって、AOB_ELEMENTにより占有されていない部分ud0,ud1を指示していない。
【００９９】
これに対して、AOBは、クラスタ007、クラスタ00E内の領域であって、AOB_ELEMENT#1、AOB_ELEMENT#4により占有されていない部分ud0,ud1までも含んでいる。BIT内のDATA_Offsetは、非占有部分ud0のデータ長、即ち、クラスタ007の先頭から、AOB_ELEMENT#1の先頭までの相対値を指示している。
本図においてAOB_ELEMENT#1は、クラスタ007の途中md0からクラスタ008の途中md1までを占有している。このAOB_ELEMENT#1は、クラスタ008全体を占有しているのではなく、その終端部分以降は、AOB_ELEMENT#2に占有されている。AOB_ELEMENT#4は、クラスタ00Cの途中部分md3から、クラスタ00Eの途中部分md4までを占有している。このようにAOB_ELEMENTには、クラスタの境界を跨ぐように、記録されているものが存在することがわかる。つまり、AOB_ELEMENTは、クラスタの境界とは全く関係無く、記録されているのである。BIT内の『FNs_1st_TMSRTE』は、クラスタ007〜クラスタ008におけるAOB_ELEMENT#1のフレーム数を示しており、BIT内の『FNs_Last_TMSRTE』は、クラスタ00C〜クラスタ00EにおけるAOB_ELEMENT#4のフレーム数を示している。
【０１００】
このように、各AOB_ELEMENTは、クラスタの境界に関係なく、自由に配置されており、BITにより、クラスタ境界からAOB_ELEMENTまでのオフセットや各AOB_ELEMENT毎のフレーム数が管理されていることがわかる。
{17-5_22-14_25} 各AOB_ELEMENT毎のフレーム数の利用法１
BITに記載されている各AOB_ELEMENT毎のフレーム数がどのように利用されるかを以下に説明する。BITに記載されているフレーム数は、先ず第１に、再生経過時刻を2秒スキップして、240ミリ秒だけ再生するという順方向サーチ再生、逆方向サーチ再生を行う場合に用いられる。
【０１０１】
図２５は、AOB内の任意のAOB_ELEMENT#yにおけるAOB_FRAME#xから順方向サーチ再生を行う場合、次に再生すべきAOB_FRAME#x+1をどのように設定するかを示す図である。
本図は、AOB_ELEMENT#yに含まれるAOB_FRAME#xが再生されている時点において、順方向サーチ再生が指示された場合を想定して作図した図である。本図において、tは、所定の間欠再生時間(=240ミリ秒)、f(t)は、間欠再生時間に相当するフレーム数、間欠スキップ時間skip_timeは、間欠再生を行う際にスキップすべき時間長（この場合は2秒)、この間欠スキップ時間skip_timeに対応するフレーム数をf(skip_time)とする。ここで間欠再生は、以下の▲１▼▲２▼▲３▼の手順を繰り返すことにより行われる。
【０１０２】
▲１▼TKTMSRTに記載されているTMSRT_entryを参照して、旗(AOB_ELEMENT)の先頭へとジャンプする。
▲２▼240ミリ秒だけ再生を行う
▲３▼次の旗(AOB_ELEMENT)の先頭へとジャンプする。
尚、本実施形態では、240ミリ秒再生し、2秒後の箇所にジャンプし、240ミリ秒再生するという、より正確な間欠再生を実現する方法について説明する。
【０１０３】
AOB_ELEMENT#yに含まれるAOB_FRAME#xから、2秒+240ミリ秒後のAOB_FRAME#x+1は、AOB_ELEMENT#y+1内に存在する筈である。2秒+240ミリ秒後のAOB_FRAME#x+1を特定する場合、次のAOB_ELEMENT#y+1についての先頭アドレスは、TKTMSRTにおけるTMSRT_entryを読み出すことにより即座に算出することができるが、そのAOB_ELEMENT#y+1の先頭アドレスからAOB_FRAME#x+1までに介在するAOB_FRAME数は、TMSRT_entryのみでは知り得ない。そのようなAOB_FRAME数を算出するためには、AOB_FRAME#xがAOB_ELEMENT#yの先頭から何番目に位置するかを示す#xと、f(t)と、f(skip_time)との和から、AOB_ELEMENT#yに含まれる全フレーム数を差し引くことにより求める必要がある。そのように、次のAOB_ELEMENT#y+1におけるAOB_FRAME#x+1の相対フレーム位置を簡易に算出するため、BITに各AOB_ELEMENTについての『FNs_1st_TMSRTE』、『FNs_Middle_TMSRTE』、『FNs_Last_TMSRTE』を記載しているのである。
【０１０４】
{17-5_22-15_26A} 各AOB_ELEMENT毎のフレーム数の利用法２
BITに記載されているフレーム数は、第２に、任意の再生時刻から再生を開始するという機能（タイムサーチ機能）を実行する際に利用される。図２６（ａ）は、任意の再生開始時刻が指定された場合、その指定時刻に対応するAOB_ELEMENT、AOB_FRAMEをどのように特定するかを示す図である。
【０１０５】
任意の時刻が指定されて再生が指示された場合、再生指定時刻をJmp_Entry(秒)とすると、以下の式を満たすAOB_ELEMENT#yと、AOB_FRAME位置xとから、再生を開始すればよい。
｛数式２｝
Jmp_Entry(秒)＝(FNs_1st_TMSRTE＋FNs_middle_TMSRTE×y＋x)×20msec
これら『FNs_1st_TMSRTE』及び『FNs_Middle_TMSRTE』はBITに記載されているので、これらを｛数式２｝に適用することによりAOB_ELEMENT#y、AOB_FRAME#xが算出されれば、このAOBに対応するTKTMSRTを参照して、AOBにおいてy+2番目に位置するAOB_ELEMENT#y+2の先頭アドレスを求めて、この先頭アドレスから、AOB_FRAME#xの探索を始め、x番目のAOB_FRAMEが探索されれば、このx番目のAOB_FRAMEから再生を開始する。これにより、Jmp_Entry(秒)にて指定された時刻から、再生を開始することができる。
【０１０６】
この際、AOBファイルのADTSヘッダ部分を検索せず、TKTMSRTにTMSRT_entryが記述されているAOB_ELEMENT単位で検索を行えばよいので、再生指定時刻に対応する再生位置を高速に探し出すことができる。
同様に、複数のAOBからなるトラックに対して、タイムサーチ機能が実行され、Jmp_Entry(秒)が指定された場合、以下の｛数式３｝を満たすAOB_ELEMENT#yと、AOB_FRAME#xとを算出すればよい。
｛数式３｝
Jmp_Entry(秒) = AOB#1からAOB#nまでの再生時間の総和
+（FNs_1st_TMSRTE(#n+1)+FNs_middle_TMSRTE(#n+1)・y+x）・20msec
ここでAOB#1からAOB#nまでのAOBの再生時間の総和は、以下の通りである。
AOB#1からAOB#nまでの再生時間の総和＝
(『FNs_1st_TMSRTE』(#1)+『FNs_Middle_TMSRTE』(#1)・(TMSRT_entry数#1-2)+『FNs_Last_TMSRTE』(#1)
+ 『FNs_1st_TMSRTE』(#2)+『FNs_Middle_TMSRTE』(#2)・TMSRT_entry数#2-2)+『FNs_Last_TMSRTE』(#2)
+ 『FNs_1st_TMSRTE』(#3)+『FNs_Middle_TMSRTE』(#3)・TMSRT_entry数#3-2)+『FNs_Last_TMSRTE』(#3)
・・・・・・・・・
+ 『FNs_1st_TMSRTE』(#n)+『FNs_Middle_TMSRTE』(#n)・TMSRT_entry数#n-2)+『FNs_Last_TMSRTE』(#n))・20msec
｛数式３｝を満たすAOB#n、AOB_ELEMENT#y、AOB_FRAME#xが算出されれば、このAOB#n+1に対応するTKTMSRTを参照して、y+2番目のAOB_ELEMENT#y+2に位置するアドレスから、AOB_FRAME#xの探索を始め、x番目のAOB_FRAMEが探索されれば、このx番目のAOB_FRAMEから再生を開始する。
【０１０７】
{17-5_22-16_27A,B} AOBファイル及びTKIの削除
TKIに含まれる情報を全て説明したところで、一部のトラックが削除された場合(case1)、一部のトラックが削除された後、新たなトラックを記録する場合(case2)、複数のトラックのうち、任意の2つを1つのトラックに統合する場合(case3)、1つのトラックを分割して、2つのトラックを得る場合(case4)において、TKIがどのように更新されるかについて説明する。
【０１０８】
先ず初めに、一部のトラックが削除された場合(case1)について説明する。
図２７（ａ）、（ｂ）は、トラックを削除する場合を想定した図である。本図は、図１９に示したTrackManagerを示すものであり、本図においてTrackBを削除することを操作者が希望しているものとする。このTrackBに対応するAOBは、AOB002.SA1に収録されており、それがTKI#2に対応づけられているので、AOB002.SA1が削除されると共に、TKI#2のTKI_BLK_ATRが『Unused』に設定される。AOB002.SA1が削除され、TKI#2のTKI_BLK_ATRが『Unused』に設定された状態を図２７（ｂ）に示す。AOB002.SA1が削除されたので、データ領域においてAOB002.SA1が占有していた領域は空き領域に解放される。それと共に、TrackManagerにおいては、TKI#2のTKI_BLK_ATRが『Unused』に設定されていることがわかる。
【０１０９】
{17-5_22-17_28A,B} 新たにAOBファイルを記録する場合のTKIの割り当て
続いて一部のトラックが削除された後、新たなトラックを記録する場合(case2)について説明する。
図２８（ａ）は、トラックの削除が複数回行われた後のTrackManagerを示す図である。本図において、複数のトラックが削除され、これらがTKI#2、TKI#4、TKI#5、TKI#7、TKI#8に対応づけられているとすれば、これらのTKIのTKI_BLK_ATRが『Unused』に設定される。AOBファイルの削除は、通常のファイルと同様に行われるが、TrackManagerは、該当するTKIのTKI_BLK_ATRが『Unused』に設定されるのみで削除処理は完了する。そうすると、本図に示すように『Unused』のTKIが虫食い状にTrackManager上に現れることになる。
【０１１０】
図２８（ｂ）は、『Unused』のTKIが存在しており、ここに新たなTKI、AOBファイルを書き込む場合、その書き込みがどのように行われるかを示す図である。
ここで4つのAOBからなるトラックを書き込もうとする場合を想定する。ここでAOBの記録にどの空きTKIを割り当てるかは、後述するDPL_TK_SRPにより決定されるか、又は、任意のTKIが割り当てられる。その4つのAOBには、TrackManagerにおいて、『Unused』に設定されているTKI#2、TKI#4、TKI#7、TKI#8が割り当てられる。
【０１１１】
これら4つのAOBは1つのトラックを構成するものなので、TKI#2についてのTKI_BLK_ATRを『Head_of_Track』と、TKI#4、TKI#7についてのTKI_BLK_ATRを『Midpoint_of_Track』と、TKI#8についてのTKI_BLK_ATRは、『End_of_Track』と設定される。トラックTrackDを構成する4つのTKI#2、TKI#4、TKI#7、TKI#8は、各TKI_LNK_PTRが、トラックTrackDを構成する次のTKI_LNK_PTRを指示するよう設定されている。即ち、矢印TL2,TL4,TL7に示すように、TKI#2のTKI_LNK_PTRはTKI#4を指示しており、TKI#4のTKI_LNK_PTRはTKI#7を、TKI#7のTKI_LNK_PTRはTKI#8を指示している。
【０１１２】
その後、TKI#2、TKI#4、TKI#7、TKI#8のそれぞれと同じ番号を有する4つのファイルAOB002.SA1、AOB004.SA1、AOB007.SA1、AOB008.SA1が作成されて、これら4つのファイルにTrackDを構成する4つのAOBが収録される。
かかるTKI_BLK_ATR、TKI_LNK_PTRの設定により、4つ目のトラックTrackDは、TKI#2、TKI#4、TKI#7、TKI#8を用いて管理されることなる。
【０１１３】
以上のように、フラッシュメモリカード３１に新たにトラックを書き込む場合、それまでTrackManagerに『Unused』に設定されているTKIを、その新規に記録すべきトラックについてのTKIに割り当てていることがわかる。
{17-5_22-18_29A,B} 2つのトラックを統合する場合のTKI設定
続いてトラックの統合(case3)を行う際の、TKIの更新について説明する。
【０１１４】
図２９（ａ）、（ｂ）は、2つのトラックを1つに統合する場合にTKIがどのように設定されるかを示す図である。図２９（ａ）は、図１９に示したTrackManagerと同一であり、図２９（ａ）において、TrackCとTrackEとを1つのトラックに統合するという編集操作を操作者が希望しているものとする。これらTrackC、TrackEに対応するAOBがAOB003.SA1、AOB008.SA1に収録されており、それらがTKI#3、TKI#8に対応づけられているので、これらTKI#3及びTKI#8のTKI_BLK_ATRの書き換えが行われる。図２９（ｂ）は、TKIのTKI_BLK_ATRの書き換え後を示す図である。本図においてTKI#3、TKI#8のTKI_BLK_ATRはTrackと記載されているが、図２９（ｂ）では、TKI#3のTKI_BLK_ATRは『Head_of_Track』に書き換えられ、TKI#8のTKI_BLK_ATRは『End_of_Track』に書き換えられている。このように、TKI_BLK_ATRが書き換えられることにより、TKI#3、TKI#8、これらに対応するAOB003.SA1、AOB008.SA1は、TrackCという1つのトラックとして扱われる。これに加えて、TKI#3のTKI_LNK_PTRがリンク先としてTKI#8を指示するように書き換えられる。
【０１１５】
ここで留意すべきは、TKIのTKI_BLK_ATRは書き換えられたが、AOB003.SA1とAOB008.SA1とを統合するという処理は行われなかった点である。何故なら、これらのAOBファイルは、互いに異なるFileKeyにて暗号化されているので、これらを1つに統合するとなると、暗号化されたAOBファイルを復号して再度暗号化するという復号化−暗号化という2つの処理が各AOBファイルについて行う必要があり、多大な処理負荷が要求されるからである。また、統合後のAOBファイルは、1つのFileKeyにて暗号化されるので、統合前と比較して、著作権保護の弱体化を招くからである。
【０１１６】
加えてTKIは、元々TKTMSRTのサイズが大きくならないように定められているのに、編集操作においてこれを1つに統合するとなると、統合後のTKIのサイズが、大きくなり過ぎる恐れがあるからである。
以上のように、本実施形態におけるトラックの統合化編集は、AOBファイルの暗号化を維持したまま、TKI_BLK_ATRの属性変更のみで実現されることがわかる。
【０１１７】
{17-5_22-18_29A,B-1_30,31} トラックを統合する場合に満たすべき条件
トラックの統合は、TKI_BLK_ATRの属性変更にて実現されることは上述した通りであるが、トラックの統合にあたっては、統合されるトラックに含まれるAOBが以下の条件を満たしていることが要求される。
1つ目の条件とは、後続するトラックに含まれるAOBと、先行するトラックに含まれるAOBとのオーディオ属性（オーディオコーディングモード、ビットレート、サンプリング周波数、チャネル数）が一致していることである。これは、AOBのオーディオ属性が前後のAOBで異なると、再生装置は、デコーダの動作を一旦リセットする必要があり、連続する2つのAOBをシームレスに（途切れることなく）再生することが困難になるという理由による。
【０１１８】
2つ目の条件とは、統合後により得られるトラックにおいて、AOB_FRAME数が『FNs_Middle_TMSRTE』に満たないAOB_ELEMENTのみからなるAOBが3つ以上連続しないことである。
AOB_ELEMENTのうち少なくとも1つが、『FNs_Middle_TMSRTE』にて指示されたフレーム数と同数のAOB_FRAMEを有しているか否かにより、AOBは2つのタイプに分類される。1つ目のタイプのAOBは、『FNs_Middle_TMSRTE』にて指示されたフレーム数と同数のAOB_FRAMEを有するAOB_ELEMENTを少なくとも1つ有しているAOBであり、2つ目のタイプのAOBは、『FNs_Middle_TMSRTE』にて指示されたフレーム数と同数のAOB_FRAMEを有しているAOB_ELEMENTを一切有していないAOBである。即ち、2つ目のタイプのAOBにおけるAOB_ELEMENTは、何れも『FNs_Middle_TMSRTE』にて指示されたフレーム数を下回っており、上述した2つ目の条件は、Type2のAOBが3つ以上連続することを禁じているのである。その禁止理由は以下の通りである。即ちAOBを順次読み出してゆく際、再生装置内のバッファは、充分な数のAOB_FRAMEにて満たされていることが望ましいが、Type2のAOBが連続していると、再生装置内のバッファを、AOB_FRAMEで満たすことができなくなる。そうすると、再生装置内のバッファがアンダーフローを起こし、AOBの再生の連続性が保てなくなる。そうしたアンダフローの発生を避けるため、Type2のAOBが3つ以上連続することを2つ目の条件は禁じているのである。
【０１１９】
図３０（ａ）は、Type1のAOBを示し、図３０（ｂ）は、Type2のAOBを示す図である。図３０（ｂ）におけるAOBは2つ以下のAOB_ELEMENTのみからなり、それら2つ以下のAOB_ELEMENTは、『FNs_Middle_TMSRTE』に示されるAOB_FRAMEを有していない（尚、この場合BITには、FNs_1st_TMSRTEのみが記述される。）。
『FNs_Middle_TMSRTE』に示されるAOB_FRAMEを有していないことがType2AOBの要件なので、たった1つのAOB_FRAMEにより構成されるAOBであっても、このType2のAOBに分類されることなる。
【０１２０】
図３１（ａ）は、Type1＋Type2＋Type2＋Type1の組み合わせで、複数トラックを1つに統合する場合を示す図である。この場合、Type2のAOBが3つ連続することは避けられているので、これらは1つのトラックに統合される。
図３１（ｂ）は、Type1＋Type2＋Type2＋Type2＋Type1の組み合わせで、複数トラックを1つに統合する場合を示す図である。この場合、Type2のAOBが3つ連続しているので、これらを1つのトラックに統合することは禁じられる。
【０１２１】
{17-5_22-18_29A,B-1_32} Type1、Type2の組合せを考慮したトラック統合 図３１（ａ）に示したトラックの統合によれば、先行するトラックの終端がType1である場合、このトラックは、先頭にType2のAOBを配したトラック、又は、先頭にType1のAOBを配したトラックと統合することができる。図３２（ａ）は、先行するトラックの終端にType1のAOBが配され、後続するトラックの先頭にType1のAOBが配されている配置パターンを示す図である。また図３２（ｂ）は、先行するトラックの終端にType1のAOBが配され、後続するトラックの先頭にType2のAOBが配されている配置パターンを示す図である。これらは何れも、条件2を満たすので、1つのトラックに統合することができる。
【０１２２】
先行するトラックの終端がType2であり、そのType2の直前にType1のAOBが配置されている場合、このトラックは、先頭がType1のトラック、又は、先頭にType2のAOBが配され、その直後にType1のAOBが配置されたトラックと統合することができる。
図３２（ｃ）は、先行するトラックの終端にType1、Type2順でAOBが配され、後続するトラックの先頭にType1のAOBが配されている配置パターンを示す図である。図３２（ｄ）は、先行するトラックの終端にType1、Type2順でAOBが配され、後続するトラックの先頭に、Type2、Type1のAOBが配されている配置パターンを示す図である。これらも、条件2を満たすので、1つのトラックに統合することができる。
【０１２３】
先行するトラックの終端がType2であり、そのType2の直前にType2のAOBが配置されている場合、このトラックは、先頭にType1のAOBが配されたトラックと統合することができる。図３２（ｅ）は、先行するトラックの終端にType2、Type2のAOBが配され、後続するトラックの先頭にType1のAOBが配されている配置パターンを示す図である。これも、条件2を満たすので、1つのトラックに統合することができる。以上のように、トラックの統合にあたっては、統合されるべき2つのトラックが上述した2つの条件を満たすかを前もって判定し、これらの2つの条件を満たすと判定された場合のみ、2つのトラックを1つに統合する。
【０１２４】
続いてトラックの分割(case4)を行う際の、TKIの更新について説明する。
{17-5_22-19_33A,B} トラックを分割する場合のTKI設定
図３３（ａ）、（ｂ）は、1つのトラックを2つのトラックに分割する場合を想定した図である。本図におけるTrackManagerは、図２７に示すTrackManagerと同一であり、本図において、TrackCをTrackC−TrackFという2つのトラックに分割するという編集を操作者が希望しているものとする。TrackCをTrackC−TrackFに分割しようとすると、TrackFに対応するAOB002.SA1が生成される。図３３（ａ）では、TKI#2が『Unused』に設定されており、分割の結果、図３３（ｂ）に示すように『Unused』に設定されているTKI#2は、新たに生成されたAOB002.SA1に割り当てられる。
【０１２５】
{17-5_22-19_33A,B-1_34A,B}
ディレクトリエントリー及びFAT値の更新
ここでAOB003.SA1を分割して、AOB002.SA1を生成する際、ディレクトリエントリー及びFAT値を更新せねばならない。これらディレクトリエントリー及びFAT値をどのように更新するかを以下に説明する。図３４（ａ）は、分割前において、AOB003.SA1が属するSD_AudioディレクトリについてのSD_Audioディレクトリエントリーがどのように記述されているかを示す図である。AOB003.SA1は、複数に分割されて、クラスタ007,008,009,00A・・・・00D,00Eに格納されているものとする。この場合、ディレクトリエントリーにおけるAOB003.SA1について『ファイル最初のクラスタ番号』は、『007』と記述され、クラスタ007,008,009,00A・・・・00Dに対応するFAT値007,008,009,00A・・・・00Dは、それぞれ(008),(009),(00A)・・・・(00D),(00E)と記述されている。
【０１２６】
この状態でAOB003.SA1の後半部を分割してAOB002.SA1を得る場合、SD_Audioディレクトリエントリーには、AOB002.SA1についての『ファイル名』、『ファイル拡張子』、『ファイル最初のクラスタ番号』が追加される。図３４（ｂ）は、分割後において、AOB003.SA1が属するSD_AudioディレクトリについてのSD_Audioディレクトリエントリーがどのように記述されているかを示す図である。
【０１２７】
本図におけるクラスタ00Fは、操作者により指定された分割境界を含むクラスタ00Bの内容のコピーを格納したものである。クラスタ00Bに格納されているAOB002.SA1の分割部分に後続する分割部分は、クラスタ00C,00D,00E以降に格納されている。AOB002.SA1の先頭部分はクラスタ00Fに格納され、残りの部分は、クラスタ00C,00D,00E以降に格納されているので、AOB002.SA1についての『ファイル最初のクラスタ番号』には、クラスタ00Fを示すクラスタ番号00Fが記述され、クラスタ00F,00C,00D,00Eに対応づけられているFAT値00F,00C,00D,00Eには、(00C),(00D),(00E)が記述される。
【０１２８】
{17-5_22-19_33A,B-2_35A,B} TKI内の情報要素の設定
以上のディレクトリエントリー及びFAT値の更新によりAOB002.SA1を得た後、AOB002.SA1についてのTKI内の情報要素をどのように設定するかについて説明する。分割されたトラックについてのTKIを生成する場合、TKIの情報要素には、元のTKIに記載されているものをコピーして継承すればよいもの(1)、元のTKIに基づいて更新せねばならないもの(2)の二種類が存在する。前者に該当するのは、TKTXTI_DA,ISRCであり、後者に該当するのは、BIT、TKTMSRTを初めとする残りの構成要素である。これら両者が存在するので、本実施形態では、分割されたトラックについてのTKIを生成する際、分割元のTKIをコピ−して新たなTKIの雛型を作成すると共に、それに含まれるTKTMSRT、BITを分割・更新を行い、残りの情報要素を更新するという手順がなされる。
【０１２９】
図３５（ａ）は、AOBを任意のAOB_FRAMEで分割する場合を想定した図である。本図において第１段目は、4つのAOB_ELEMENTであるAOB_ELEMENT#1、AOB_ELEMENT#2、AOB_ELEMENT#3、AOB_ELEMENT#4を示す。これら4つのAOB_ELEMENTのそれぞれのデータ長は、4つのTMSRT_entry#k-1,#k,#k+1,#k+2(ここでk=2とする)としてTKTMSRTに設定されている。本図において、AOB_ELEMENT#2において分割境界bd1が設定されたとすると、AOB_ELEMENT#2は、分割境界bd1より前方のフレームからなる領域▲１▼と、分割境界bd1より後方のフレームからなる領域▲２▼とに分割される。図３５（ｂ）は、AOB_ELEMENT#2の途中部分でAOBが分割されて、AOB#1、AOB#2という2つのAOBが得られた状態を示す図である。
【０１３０】
{17-5_22-19_33A,B-3_36} BITの設定
図３６は、図３５に示したようにAOBが分割された場合に、BITがどのように設定されるかを示す図である。図３５に示したAOBは、分割境界bd1にて分割されており、その分割により得られたAOB#1は、AOB_ELEMENT#1と、AOB_ELEMENT#2という2つのAOB_ELEMENTを含み、AOB#2は、AOB_ELEMENT#1、AOB_ELEMENT#2、AOB_ELEMENT#3という3つのAOB_ELEMENTを含んでいることがわかる。
【０１３１】
これらのAOB_ELEMENTのそれぞれにも、三角旗状の記号が付与されているが、これらは、それぞれAOBに対応するTKIに含まれるTMSRT_entryが設定されていることを示す。先ず最初に分割により得られたAOB#1について説明する。AOB#1に含まれるAOB_ELEMENT#1、AOB_ELEMENT#2は、クラスタ007〜クラスタ00Aを占有しているので、AOB#1は、クラスタ007〜クラスタ00Aを一単位として扱われる。ここでAOB#1におけるAOB_ELEMENT#2は、クラスタ00Aの終端迄を占有しているのではなく、クラスタ00Aの存在する分割境界bd1迄を占有しているのでAOB#1についてのSZ_DATAは、領域md0から、クラスタ00Aにおける分割境界bd1までのデータ長を指示することになる。AOB#1の『FNs_1st_TMSRTE』は分割前と変わらないが、AOB#1の『FNs_Last_TMSRTE』は、AOB_ELEMENT#2の分割前の先頭から、分割境界bd1までのフレーム数を指示している点が分割前と異なる。
【０１３２】
続いて分割により得られたAOB#2について説明する。AOB#2に含まれるAOB_ELEMENT#1、AOB_ELEMENT#2、AOB_ELEMENT#3は、クラスタ00B〜クラスタ00Fを占有している。クラスタ00Fとは、クラスタ00Aの内容のコピーを格納しているクラスタである（クラスタ00Fにクラスタ00Aのコピーを格納している理由は、クラスタ00Aは、AOB#1のAOB_ELEMENT#2により占有されているので、このクラスタと異なるクラスタをAOB#2に含まれるAOB_ELEMENT#1に割り当てる必要があるからである。）。
【０１３３】
AOB#2におけるAOB_ELEMENT#1は、クラスタ00Fの先端から占有しているのではなく、クラスタ00Fの存在する分割境界bd1以降を占有しているのでAOB#2についてのSZ_DATAは、クラスタ00Bの先頭から、クラスタ00Eにおける途中部分までのデータ長と、クラスタ00FにおいてAOB_ELEMENT#1が占有しているデータ長との和を指示することになる。
【０１３４】
クラスタ00Fに格納されているクラスタ00Aのコピーには、AOB#1のAOB_ELEMENT#2が記録されており、AOB#1のAOB_ELEMENT#2により占有されている部分を、AOB#2から除外されねばならないので、AOB#2のBITについてのDATA_Offsetは、クラスタ00FにおいてAOB#1のAOB_ELEMENT#2により占有されているサイズが設定されている。
【０１３５】
この図からもわかるように、AOBの分割においては、分割境界を含むAOB_ELEMENTのみが2つに分割され、その分割境界の前後のAOB_ELEMENTは、分割前のものから変化していないことがわかる。そのため、AOB#2の『FNs_Last_TMSRTE』は、分割前のAOB_ELEMENT#4の『FNs_Last_TMSRTE』と同じ値に設定され、AOB#2の『FNs_1st_TMSRTE』は、AOB#2のAOB_ELEMENT#1、即ち、分割前のAOB_ELEMENT#2における分割境界以降の終端部分に含まれるフレーム数が設定される。
【０１３６】
{17-5_22-19_33A,B-4_37} BITの設定
図３７は、分割の前後でBITがどのように変化するかを更に具体的に示す図である。図３７の左側のBITは、分割前のBITの設定例を示す。トラックを分割する前のBITは、Data_OffsetがXに設定され、SZ_DATAが『52428』、TMSRTE_Nsが『n』個と設定される。FNs_1st_TMSRTEは『80フレーム』、FNs_Middle_TMSRTEについては『94フレーム』に設定され、FNs_Last_TMSRTEは『50フレーム』に設定されることがわかる。
【０１３７】
図３７の右側に、分割後の2つのトラックについてのBITの設定を示す。本BITに対応するAOBが図３５（ａ）に示すように分割された場合、１トラック目のBITにおいて、Data_Offsetは分割前と同一値『x』に設定されるが、SZ_DATAに分割点bd1までのデータ長『Q』に更新され、TMSRTE_Nｓには、1番目のTMSRT_entryからk番目のTMSRT_entryまでのTMSRT_entryの個数である『k個』に更新される。FNs_1st_TMSRTE及びFNs_Middle_TMSRTEについては分割前同様、80,94フレームに設定されるが、分割後の1トラック目のAOBの最後のAOB_ELEMENTには、図３５（ａ）においてp個のAOB_FRAMEが含まれているので、FNs_Last_TMSRTEは『pフレーム』に設定される。
【０１３８】
２トラック目のBITは、Data_OffsetがRに設定され、SZ_DATAがオリジナルのSZ#DATA52428−分割点bd1までのデータ長『Q』、TMSRTE_Nsがn-k+1個と設定される（k番目のTMSRT_entryからn番目のTMSRT_entryまでのTMSRT_entry個数であるn-k個と、分割のために新たに追加されたk番目のTMSRT_entryの個数である1個とを加算した数である。）。FNs_Middle_TMSRTE及びFNs_Last_TMSRTEについては分割前同様、94,50フレームに設定されるが、分割後の2トラック目のAOBの最初のAOB_ELEMENTには、94-p個のAOB_FRAMEが含まれているので、FNs_1st_TMSRTEは『94-pフレーム』に設定される。
【０１３９】
{17-5_22-19_33A,B-5_38} BITの設定
図３８は、分割後のTKTMSRTを示す図である。まずTMSRTについては以下のようになる。１トラック目のTMSRTは分割前のAOBのTMSRTのはじめからk番目のエントリまで(TMSRT_entry#1〜TMSRT_entry#k)を含む。ここで注意すべきは、分割境界を含むAOB_ELEMENT#kは、領域▲１▼を含むのみなので、このk番目のエントリーは、この領域▲１▼に相当する部分のデータサイズのみが含まれている。２トラック目のTMSRTは、分割前のk番目のエントリからn番目のエントリまで(TMSRT_entry#k〜TMSRT_entry#n)を含む。ここで注意すべきは、分割境界を含むAOB_ELEMENT#kは、2トラック目において領域▲２▼を含むのみなので、分割前のk番目のエントリーは、この領域▲２▼に相当する部分のデータサイズのみが含まれている。
【０１４０】
TKIをコピ−すると共に、TKTMSRT、BITを分割・更新を行い、残りの情報要素を更新すれば、分割により得られた新たなトラックについてのTKIが得られることになる。統合の場合と同様、暗号化されたAOBファイルを復号化することなく、暗号化された状態のままAOBファイルに対応するトラックを2つに分割することができる。AOBファイル分割の際に復号・再暗号化が伴わないので、トラックを分割する際の処理負荷が軽減されていることがわかる。これにより、再生装置の処理性能が低い場合でも、トラックの編集を行うことができる。
【０１４１】
以上長文となったが、TKIについての説明を終了する。続いてプレイリストについて説明する。
{17-6} Playlistmanager
図１７に示すPlaylistmanagerは、破線の引き出し線h5に示すように、フラッシュメモリカード３１内に格納されているプレイリストを管理するPlaylistManager_Information(PLMGI)と、フラッシュメモリカード３１に格納される全トラックを管理するDefault_Playlist_Information(DPLI)と、PlaylistInformation(PLI)#1,#2,#3,#4,#5・・・・・#nとからなり、Default_Playlist情報は、破線の引き出し線h6に示すように、Default_Playlist_General_Information(DPLGI),Default_Playlist_Track_Serch_Pointer(DPL_TK_SRP)#1,#2,#3,#4・・・・#mからなることがわかる。また各PLIは、破線の引き出し線h7に示すように、Playlist_General_Information(PLGI),Playlist_Track_Serch_Pointer(PL_TK_SRP)#1,#2,#3,#4・・・・#mからなることがわかる。
【０１４２】
ここでDefault_Playlist情報と、PlayList情報との差違について説明しておく。Default_Playlist情報は、全てのトラックを指定することが義務付けられているのに対して、PlayList情報は、そのような義務は存在せず、任意のトラックを指定すれば良い。そのため、ユーザが、自分の好みのトラックのみを指定しているようなPlayList情報を生成してフラッシュメモリカード３１に記憶させたり、またフラッシュメモリカード３１に記憶される複数のトラックのうち、所定のジャンルのトラックのみを指定しているようなPlayList情報を再生装置が自動的に生成してフラッシュメモリカード３１に記憶させるという用途に適している。
【０１４３】
{17-7_18} プレイリストの個数、データサイズ
図１８を参照すると、プレイリストの最大数は99個である。また、Playlist Manager Information(PLMGI)とDefault Playlist Information(DPLI)は、合計で2560バイトの固定長である。Playlist Information(PLI)もまた、512バイトの固定長である。Default_Playlist情報に含まれるDPL_TK_SRPは、DPL_TK_ATR,DPL_TKINを含んでいる。一方、PlayList情報に含まれるPL_TK_SRPは、PL_TKINのみを含んでいる。これらのDPL_TK_ATR,DPL_TKIN,PL_TKINは、図３９に示すフォーマットを有する。
【０１４４】
{17-8_39-1} DPL_TK_SRPのフォーマット
図３９（ａ）は、DPL_TK_SRPのフォーマットを示す図である。図３９（ａ）においてDPL_TK_SRPは、0ビット目から9ビット目までに、DPL_TKINが記述され、13ビット目から15ビットまでには、DPL_TK_ATRが記述され、10ビット目から12ビットまでは予約用に確保(reserved)されている。
【０１４５】
次に、0ビット目から9ビット目までのフィールドを占めるDPL_TKINには、TKI番号が記述される。ここにTKI番号を記述することにより、TKIを特定することが可能となる。
{17-9_39B} PL_TK_SRPのフォーマット
図３９（ｂ）は、PL_TK_SRPのフォーマットを示す図である。PL_TK_SRPは、0ビット目から9ビット目までのフィールドを有しており、ここにPL_TKIN、即ち、TKI番号が記述される。
【０１４６】
{17-8_39A-2} DPL_TK_ATRの構成
図３９（ａ）の『DPL_TK_ATR』から破線の矢印h51,h52にて引き出された枠内に、DPL_TK_ATRの設定例を示す。この枠内の記載からも理解できるように、DPL_TK_SRPについてのDPL_TK_ATRの設定は、TKIについてのTKI_BLK_ATRの設定と同一であり、『Track』、『Head_of_Track』、『Midpoint_of_Track』、『End_of_Track』の何れかが設定される。
【０１４７】
具体的には、TKINにて指定されたTKIが使用中であり、当該TKIに対応するAOBファイルに１個のトラックに対応するオーディオオブジェクトが収録されている場合（TKIのTKI_BLK_ATRにおける『Track』）、DPL_TK_ATRは"000b"の値が設定される。
TKINにて指定されたTKIが使用中であり、当該TKIに対応するAOBファイルにトラックの先頭部のみに対応するオーディオオブジェクトが収録されている場合（TKIのTKI_BLK_ATRにおける『Head_of_Track』）、DPL_TK_ATRは"001b"の値が設定される。
【０１４８】
TKINにて指定されたTKIが使用中であり、当該TKIに対応するAOBファイルにトラックの中間部のみに対応するオーディオオブジェクトが収録されている場合（TKIのTKI_BLK_ATRにおける『Midpoint_of_Track』）、DPL_TK_ATRには"010b"の値が設定される。
TKINにて指定されたTKIが使用中であり、当該TKIに対応するAOBファイルにトラックの終端部のみに対応するオーディオオブジェクトが収録されている場合（TKIのTKI_BLK_ATRにおける『End_of_Track』）、DPL_TK_ATRには、"011b"の値が設定される。
【０１４９】
TKINにて指定されたTKIが未使用であり、TKIの領域のみが確保されている場合、すなわち削除されたTKIである場合（TKIのTKI_BLK_ATRにおける『Unused』）、"100b"の値が設定される。
TKINにて指定されたTKIが未使用であり、TKIの領域が確保されていない場合、すなわち初期状態のTKIである場合は、"101b"の値が設定される。
【０１５０】
『DPL_TK_SRP』は、DPL_TKINにTKIの番号を記述することにより、複数のTKIのうち、何れかのものとの対応関係を有する。また、Default_Playlist情報におけるDPL_TK_SRPの順位は、DPL_TK_SRPと対応関係を有するTKIに対応するAOB（AOBファイル）が何番目に再生されるかを示す。これらのことにより、Default_Playlist情報におけるDPL_TK_SRPの順序は、複数のトラックをどのような順序で再生させるか、即ち、トラックの再生順序を定義することなる。
【０１５１】
{17-9_40-1} Default_Playlist情報、TKI、AOBファイルの相互関係
図４０は、Default_Playlist情報、TKI、AOBファイルの相互関係を示す図である。本図における第２、第３、第４段目は、図１９の第１段目、第２段目、第３段目と同一であり、8つのTKIを含むTrackManager、8つのAOBファイルを示す。図１９と異なるのは、第１段目にDefault_Playlist情報を示す四角枠が記述されている点である。第１段目の枠に含まれる8つの小枠は、Default_Playlist情報に含まれる8つのDPL_TK_SRPを示す。これらの小枠の上段はDPL_TK_ATRを示し、下段はDPL_TKINを示す。
【０１５２】
本図における矢印DT1,DT2,DT3,DT4・・・・・を参照すれば、DPL_TK_SRP#1と、TKI#1との間に対応関係が成立しており、DPL_TK_SRP#2と、TKI#2との間、DPL_TK_SRP#3と、TKI#3との間、DPL_TK_SRP#4と、TKI#4との間にも対応関係が成立していることがわかる。
更に、各DPL_TK_SRPにおけるDPL_TK_ATRを参照すれば、DPL_TK_SRP#1、DPL_TK_SRP#2、DPL_TK_SRP#3、DPL_TK_SRP#8は何れも、Trackと設定されている。即ち、DPL_TK_SRP#1→TKI#1（AOB001.SA1）、DPL_TK_SRP#2→TKI#2（AOB002.SA1）、DPL_TK_SRP#3→TKI#3（AOB003.SA1）、DPL_TK_SRP#8→TKI#8（AOB008.SA1）という4つの組みは、それぞれが独立したトラックに対応しているのである。
【０１５３】
DPL_TK_SRP#4、DPL_TK_SRP#5、DPL_TK_SRP#6、DPL_TK_SRP#7のDPL_TK_ATRは何れもTrackと設定されず、DPL_TK_SRP#4におけるDPL_TK_ATRは『Head_of_Track』と設定され、DPL_TK_SRP#7におけるDPL_TK_ATRは『End_of_Track』と、DPL_TK_SRP#5、DPL_TK_SRP#6は『Midpoint_of_Track』と設定されていることがわかる。このことは、DPL_TK_SRP#4と対応関係を有するTKI#4（AOB004.SA1）が、トラックの先頭部であり、DPL_TK_SRP#5,#6と対応関係を有するTKI#5（AOB005.SA1）及びTKI#6（AOB006.SA1）が、トラックの中間部と、DPL_TK_SRP#7と対応関係を有するTKI#7（AOB007.SA1）が、トラックの終端部であることを意味する。
【０１５４】
DefaultPlaylistにおけるDPL_TK_SRPの順序は、各TKIに対応づけられているAOBをどのような順序で再生させるかを示す。本図のDefaultPlaylist内のDPL_TK_SRP#1,#2,#3,#4・・・・・・#8のDPL_TKINは、TKI#1,#2,#3,#4・・・・・・#8を示しているので、矢印(1)(2)(3)(4)・・・・・(8)に示すようにTKI#1に対応するAOB001.SA1が1番目に再生され、TKI#2に対応するAOB002.SA1が2番目、TKI#3に対応するAOB003.SA1が3番目、TKI#4に対応するAOB004.SA1が4番目に再生されることになる。
【０１５５】
{17-10_41} DefaultPlaylist、PlayList情報の設定例
図４１は、DefaultPlaylist、PlayList情報の設定例を、図４０と同様の表記で示した図である。本図における第１段目における四角枠はDefault_Playlist情報を示し、第２段目における3つの四角枠はPlayList情報を示す。DefaultPlaylistに含まれる小枠は、DefaultPlaylistに含まれる8つのDPL_TK_SRPを示し、PlayList情報に含まれる小枠は、3つ又は4つのPL_TK_SRPを示す。本図のDefault_Playlist情報に含まれる各DPL_TK_SRPのTKINの設定は、図４０と同一である。しかし、PlayList情報に含まれるPL_TK_SRPのTKINの設定は、DPL_TK_SRPのそれと全く異なることがわかる。
【０１５６】
{17-10_42} DPL_TK_SRPとTKIとの対応
図４２は、図４０と同じ表記法を用いてDPL_TK_SRPとTKIとの対応を示す図である。図４２においてPlaylist#1は、PL_TK_SRP#1,#2,#3からなる。このうちPL_TK_SRP#1のPL_TKINは#3と記載されており、PL_TK_SRP#2のPL_TKINは#1と、PL_TK_SRP#3のPL_TKINは#2と記載されているので、PlayList情報#1を用いてトラックを再生する場合、矢印(11)(12)(13)に示すように複数のAOBはAOB#3,#1,#2の順序で再生される。
【０１５７】
Playlist#2は、PL_TK_SRP#1,#2,#3からなる。このうちPL_TK_SRP#1のPL_TKINは#8と記載されており、PL_TK_SRP#2,#3のPL_TKINは#3、#1と記載されているので、PlayList情報#2を用いてトラックを再生する場合、矢印(21)(22)(23)に示すように複数のAOBはAOB#8,#3,#1という順序、即ちPlaylist#1と全く異なる順序で再生される。
【０１５８】
Playlist#3は、PL_TK_SRP#1,#2,#3,#4からなる。このうちPL_TK_SRP#1,#2,#3,#4のPL_TKINは#8,#4,#3,#1と記載されているので、PlayList情報#3を用いてトラックを再生する場合以下に示す再生順序でAOBが再生される。先ず矢印(31)に示すようにTrackEを構成するAOB#8が再生され、矢印(32)に示すようにTrackDを構成するAOB#4,AOB#5,AOB#6,AOB#7がこれに続いて再生される。続いて、矢印(33)(34)に示すようにTrackC、TrackAを構成するAOB#3,AOB#1という順序で再生される。ここで注意すべきは、トラックが複数のTKIから構成される場合、PL_TK_SRPのエントリーには、複数TKIのうち、先頭のTKI番号のみが記述されている点である。具体的にいうと、Default_Playlist情報におけるDPL_TK_SRPは、TrackDについての4つのTKIであるTKI#4、TKI#5、TKI#6、TKI#7を指定していたが、PlayList情報におけるPL_TK_SRPは、それら4つのTKIを指定する必要はない。Playlist#3のPL_TK_SRP#2がTKI#4〜TKI#7のうち、TKI#4のみを指定していることは、このことを意味している。
【０１５９】
一方、複数のDPL_TK_SRPを含むDPLIは、1セクタに収まるようなデータサイズを有しており、RAM上に常駐されている。そのため、Playlistに基づいて各トラックを再生する場合、RAM上に常駐されているDPL_TK_SRPを参照することにより、各TKIを高速に検索することが可能となる。即ち、複数TKIのうち、先頭のTKI番号のみが記述されているPL_TK_SRPを用いてTKI(AOB)を再生するには、PL_TK_SRPに記述されているTKIを元にRAM上に常駐されているDPL_TK_SRPを検索し、トラックが複数のTKIから構成されているか否かを判定する。複数のTKIから構成されている場合には、対応するTKI(AOB)を全て再生するという手順を経るのである。
【０１６０】
以上のように、PlayListManagerにはDefaultPlaylist、複数のPlayList情報が記述され、これらを構成するDPL_TK_SRP、PL_TK_SRPのDPL_TKIN、PL_TKINにそれぞれ相異なる再生順序が記載されていれば、複数AOBは、それぞれ相異なる再生順序で再生されることになる。全く異なる再生順序で再生されれば、操作者は、複数の音楽アルバムが格納されているような感覚でフラッシュメモリカード３１を利用することができる。
【０１６１】
また、注意すべきは、何れもAOBファイルに対応づけられているDPL_TK_SRP、TKIのうち、DPL_TK_SRPのデータサイズは小さく(2バイトに過ぎない)、TKIのデータサイズは大きい(1024バイトもある。)点である。TrackManagerにおけるTKIの順序を入れ替えることは、フラッシュメモリカード３１に対するアクセスが多く発生するが、Default_Playlist情報、PlayList情報におけるDPL_TK_SRPの順序を入れ替えても、フラッシュメモリカード３１に対するアクセスはそれほど多くなならない。この点に鑑み、ナビゲーションデータは、その編集時において、編集操作に応じてDefaultPlaylistにおけるDPL_TK_SRPの順序を積極的に変化させる一方、TrackManagerにおけるTKIの順序は、編集操作にかかわらず、一定に維持するようにしている。
【０１６２】
{17-9_40-2_43A,B} DPL_TK_SRPの順序を入れ替え
次に、Default_Playlist情報におけるDPL_TK_SRPの順序を入れ替えることにより、トラックの再生順序を変更するという編集操作がどう行われるかについて説明する。図４３（ａ）、（ｂ）は、トラックの順序を入れ替える場合を想定した図である。図４３（ａ）におけるDPL_TK_SRP、TKIの設定は、図４０と同じである。図４０（ａ）においてDPL_TK_SRP#3におけるDPL_TKINはTKI#3、DPL_TK_SRP#8におけるDPL_TKINはTKI#8と設定されていたが、この状態において、太枠で囲ったDPL_TK_SRP#3と、DPL_TK_SRP#8との順番を入れ替える。図４３（ｂ）における(1)(2)(3)(4)(5)(6)(7)(8)は、順番入れ替え後のトラックの再生順序を示す。このことに留意すると、図４３（ａ）における再生順序は、TrackA、TrackB、TrackC、TrackD、TrackEであるが、図４３（ｂ）におけるDefault_Playlist情報では、DPL_TK_SRP#3、DPL_TK_SRP#8についてのDPL_TKINの順序が入れ替えられたので、TrackA、TrackB、TrackE、TrackD、TrackCの順序で再生されることになる。このように、Default_Playlist情報における、DPL_TK_SRPの順序を入れ替えることにより、簡易にトラックの再生順序を変更することができる。
【０１６３】
トラックの変更操作という編集操作について説明したところで、TKIの場合と同様、一部のトラックが削除された場合(case1)、一部のトラックが削除された後、新たなトラックを記録する場合(case2)、複数のトラックのうち、任意の2つを1つのトラックに統合する場合(case3)、1つのトラックを分割して、2つのトラックを得る場合(case4)において、DPL_TK_SRP及びTKIがどのように更新されるかについて説明する。
【０１６４】
{17-9_40-3_44A,B} トラックを削除する場合
先ず初めに、一部のトラックが削除された場合(case1)について説明する。
図４４（ａ）、（ｂ）は、図４０に示したDefaultPlaylistのうち、DPL_TK_SRP#2及びTKI#2を削除する場合にDefaultPlaylist、TrackManager、AOBファイルがどのように更新されるかを示す図である。図４４は、TKIの削除の説明で引用した図２７と同一部分を有する。即ち、図４４における第２、第３、第４段目は図２７と同一である。異なるのは図４０同様、第１段目に複数のDPL_TK_SRPを含むDefault_Playlist情報が記載されている点である。図４４（ａ）において太枠で囲ったDPL_TK_SRP#2→TKI#2（AOB002.SA1）からなるTrackBをユーザが削除したものとする。この場合、Default_Playlist情報においてはDPL_TK_SRP#2が削除されて、DPL_TK_SRP#3〜DPL_TK_SRP#8は、DPL_TK_SRP#2が占有していたフィールドを詰めるように、順番が1つずつ繰り上がる。このように各DPL_TK_SRPの順番を繰り上がり、一番最後のDPL_TK_SRP#8が『Unused』に設定される。これに対してTKIは、図２７（ａ）、（ｂ）を用いて説明したように『Unused』に設定されているのみで、TKI#2を詰めるような移動は行われていない。またAOB002.SA1は、削除されていることがわかる。DPL_TK_SRPについては順番の繰り上げが行われたが、TKIについては順番の繰り上げが行われていないので、図４４（ｂ）では、DPL_TK_SRPにおけるDPL_TKINが更新されている。即ち、新たなDPL_TK_SRP#2のDPL_TKINは、矢印DT11に示すようにTKI#3を指示しており、DPL_TK_SRP#3のDPL_TKINは矢印DT12に示すようにTKI#4を、DPL_TK_SRP#4のDPL_TKINはTKI#5、DPL_TK_SRP#5のDPL_TKINはTKI#6をそれぞれ指示している。更に、『Unused』に設定されたDPL_TK_SRP#8のDPL_TKINは、矢印DT13に示すように、『Unused』に設定されたTKI#2を設定していることがわかる。
【０１６５】
トラックの削除が行われた場合、使用中であるDPL_TK_SRPが先頭に繰り上げられるが、それに対応するTKIは、もとの配置を保ったまま、未使用に設定されることがわかる。このように、TKIの配置を編集前後において、不動とするので、編集処理に伴う処理負荷を軽減することができる。
{17-9_40-4_45A,B} トラックを記録する場合のTKIの割り当て
続いて一部のトラックが削除された後、新たなトラックを記録する場合(case2)について説明する。図４５（ａ）、（ｂ）は、『Unused』のTKIと、DPL_TK_SRPとが存在しており、ここに新たなTKI、DPL_TK_SRPを書き込む場合、その書き込みがどのように行われるかを示す図である。図４５（ａ）、（ｂ）において、『Unused』のTKIに新たなTKIを割り当てるケースを説明した際、引用した図２８（ａ）〜（ｂ）と同一部分を有する。即ち、図４５（ａ）、（ｂ）における第２、第３、第４段目は、図２８（ａ）、（ｂ）の第１、第２、第３段目と同一である。異なるのは、図４５の第１段目に複数のDPL_TK_SRPからなるDefault_Playlist情報が記述されている点である。図４５（ａ）において、DPL_TK_SRP#4〜DPL_TK_SRP#8が『Unused』であり、一方、図２８（ａ）に示したようにTKI#2、TKI#4、TKI#5、TKI#7、TKI#8が『Unused』であることがわかる。TrackManagerにおいて『Unused』のTKIが虫食い状に存在しているのに対して、Default_Playlist情報において『Unused』のDPL_TK_SRPがまとめられているのは、上述したように、DPL_TK_SRPは、『Unused』以外のDPL_TK_SRPの繰り上げが行われるのに対して、TKIは、そのような繰り上げが行われないからである。
【０１６６】
ここで4つのAOBからなるTrackDを書き込もうとする場合を想定する。その4つのAOBのそれぞれについてのTKIは、TrackManagerにおいて、『Unused』に設定されているTKI#2、TKI#4、TKI#7、TKI#8のそれぞれに書き込まれる。
一方、これら4つのAOBについてのDPL_TK_SRPは、Default_Playlist情報におけるDPL_TK_SRP#4〜DPL_TK_SRP#7に書き込まれる。これら4つのAOBは1つのトラックを構成するものなので、DPL_TK_SRP#4についてのDPL_TK_ATRは『Head_of_Track』と、DPL_TK_SRP#5、DPL_TK_SRP#6についてのDPL_TK_ATRは『Midpoint_of_Track』と、DPL_TK_SRP#7についてのDPL_TK_ATRは『End_of_Track』と設定されている。
【０１６７】
また、DPL_TK_SRP#4についてのDPL_TKINはTKI#2と設定され、DPL_TK_SRP#5についてのDPL_TKINはTKI#4、DPL_TK_SRP#6についてのDPL_TKINはTKI#7、DPL_TK_SRP#7についてのDPL_TKINはTKI#8と設定されている。
以上のようなDPL_TKIN、DPL_TK_ATRの設定により、TKI#2,TKI#4,TKI#7,TKI#8は、4つ目のトラックTrackDとして管理されることなる。
【０１６８】
以上の処理において、『Unused』のTKIに対する書き込みが行われたが、TKI#1、TKI#2、TKI#3、TKI#4に関しては、何の変動もなされていない点は図２８の場合と同様である。
{17-9_40-5_46A,B} トラックの統合(case3)を行う場合について
続いてトラックの統合(case3)を行う際の、Default_Playlist情報の更新について説明する。図４６（ａ）、（ｂ）は、トラックの統合を行う場合を想定した図である。本図は、TKIの統合処理を説明した際に引用した図２９（ａ）、（ｂ）と同一部分を有する。即ち、図４６（ａ）、（ｂ）における第２、第３、第４段目は、図２９（ａ）、（ｂ）における第１段目、第２段目と同一である。差違点は、図４６（ａ）、（ｂ）では、Default_Playlist情報が記載されており、それに含まれるDPL_TK_SRP#8が『Unused』に設定されていて、同じく『Unused』に設定されているTKI#2と対応関係を有している点である。本図において、図２９に示したようなトラックの統合処理が、AOBファイル及びTKIに対してなされると、DPL_TK_SRP#3〜DPL_TK_SRP#6の内容を1つずつずらして、太枠で囲ったDPL_TK_SRP#7の記述内容をDPL_TK_SRP#3にコピーする。TKIについては、図２９に示した場合と同様の更新処理がなされる。
【０１６９】
{17-9_40-6_47A,B} トラックの分割(case4)を行う場合について
続いてトラックの分割(case4)を行う際の、Default_Playlist情報の更新について説明する。
図４７（ａ）、（ｂ）は、トラックの分割を行う場合を想定した図である。本図は、TKIについての分割処理を説明した際に引用した図３３（ａ）、（ｂ）と同一部分を有する。即ち、本図における第２段目、第３段目は、図３３（ａ）、（ｂ）における第１段目、第２段目と同一である。差違点は、図４７（ａ）、（ｂ）では、Default_Playlist情報が記載されており、それに含まれるDPL_TK_SRP#8が『Unused』に設定されていて、同じく『Unused』に設定されているTKI#2と対応関係を有している点である。この状態において、図３３の場合と同様に、太枠で囲ったTKI#3、AOB003.SA1を2つに分割しようとすると、DPL_TK_SRP#3〜DPL_TK_SRP#7の順序を一つずつ繰り下げて、Default_Playlist情報における『Unused』のDPL_TK_SRPをDPL_TK_SRP#3まで移動する。移動後のDPL_TK_SRP#3には、分割により得られたTKI#2が対応づけられる。TKI#2に対応づけられているAOB002.SA1は、元々AOB003.SA1の後半部を格納したものであるが、TKI#2に対応づけられているDPL_TK_SRP#3の前に、DPL_TK_SRP#2が存在し、このDPL_TK_SRP#2は、TKI#2−AOB002.SA1が対応づけられている。即ち、AOB002.SA1及びAOB003.SA1は、元のAOB003.SA1の後半部分、前半部分を格納しているが、これらを指定しているDPL_TK_SRP#2、DPL_TK_SRP#3は、AOB003.SA1、AOB002.SA1の順序で、これらのAOBファイルを再生するよう再生順序を指定しているので、元のAOB003.SA1の後半部分、前半部分は、DPL_TK_SRPの再生順序指定により、前半部分、後半部分の順に、再生されることなる。
【０１７０】
{17-9_40-8} 編集処理の応用
以上の4つの編集操作を組み合わせることにより、操作者は、様々な編集操作を行うことができる。即ち、あるトラックの先頭部分にディスクジョッキーのアナウンスが入っており、これを削除したい場合、上記のトラックの分割処理にて、そのアナウンス部分を一個のトラックとして分割し、その後、そのトラックを削除すれば、ディスクジョッキーのアナウンスのみを部分的に削除することができる。
【０１７１】
以上でナビゲーションデータについての説明を終え、続いて、このようなナビゲーションデータ、プレゼンテーションデータを再生するために構成された再生装置について説明する。
{48-1} 再生装置の外観
図４８は、本実施形態に係るフラッシュメモリカード３１についての携帯型の再生装置を示す図である。本図において再生装置は、フラッシュメモリカード３１が挿入される挿入口、再生、順方向サーチ再生、逆方向サーチ再生、早送り、巻き戻し、停止等のキー操作を操作者から受け付けるためのキーパネルと、液晶ディスプレィとを有しており、通常の携帯型音響機器同様の外観を有する。キーパネルには、プレイリスト／トラックの選択を受け付けるPlaylistキー、トラックの先頭へのスキップを受け付ける『|<<キー』、次トラックの先頭へのスキップを受け付ける『>>|キー』、早送り、巻き戻し、順方向サーチ再生、逆方向サーチ再生を受け付ける『>>キー』,『<<キー』、フラッシュメモリカード３１に静止画が格納されている場合に、静止画を表示させる操作を受け付けるDisplayキー、録音操作を操作者から受け付けるRecキー、Stereo/Monoral選択、サンプリング周波数選択を操作者から受け付けるAudioキー、ブックマークの指定を受け付けるMarkキー、トラックの編集、タイトル入力を受け付けるEditキーが備えられている。
【０１７２】
{48-2} フラッシュメモリカード３１の携帯型再生装置における改良点
このフラッシュメモリカード３１の携帯型再生装置が通常の携帯型音響機器と異なるのは、以下の改良点(1)〜(4)である。即ち、操作者からDefault_Playlist情報、PlayList情報、トラックの指定を受け付けるために、液晶ディスプレィには、プレイリスト、トラックの一覧表示がなされること(1)、また、そのように一覧表示されたプレイリスト又はトラックのうち、任意のものを再生対象又は編集対象として指定させるためのキー割り当てがなされていること(2)、トラックの再生進行と共に、液晶ディスプレィには、トラックの再生経過時刻が表示されること(3)、タイムサーチ機能や分割編集を行う際に、再生開始時間を設定するために用いられるジョグダイアルが設けられていること(4)である。
【０１７３】
{48-2_49_50} 改良点(2)の詳細
改良点(2)の詳細は以下の通りである。図４９は、プレイリストの選択が行われる際の液晶ディスプレィの表示内容の一例を示す図であり、図５０は、トラックの選択が行われる際の液晶ディスプレィの表示内容の一例を示す図である。
図４９における『DEFAULTPLAYLIST』『PLAYLIST#1』『PLAYLIST#2』『PLAYLIST#3』『PLAYLIST#4』は、フラッシュメモリカード３１に格納されているデフォルトプレイリストと、4つのプレイリストを示すASCII文字列である。また、図５０（ａ）における『TRACK#1』『TRACK#2』『TRACK#3』『TRACK#4』『TRACK#5』は、フラッシュメモリカード３１に格納されているデフォルトプレイリストにて、再生順序が指定される5つのトラックを示すASCII文字列である。図４９及び図５０（ａ）にて、ハッチングを付したこれらのプレイリスト及びトラックは、再生対象又は編集対象として指定されていることを示す。このように液晶ディスプレィにプレイリストにて再生順序が規定されるトラックが一覧表示され、TRACK#1が再生対象に指定された状態で>>|キーの押下がなされると、図５０（ｂ）に示すように一覧表示された複数トラックのうち、その下のTRACK#2が再生対象に指定される。TRACK#2が、再生対象に指定された状態で>>|キーの押下がなされると、図５０（ｃ）に示すように一覧表示された複数トラックのうち、更に下段のTRACK#3が再生対象に指定される。TRACK#3が再生対象に指定された状態で|<<キーの押下がなされると、一覧表示された複数トラックのうち、図５０（ｄ）に示すように一段上のTRACK#2が再生対象に指定される。このように>>|キー、|<<キーの押下に応じて、何れかのトラックが再生対象として選択されるので、何れかのトラックが再生対象として選択された際に、図５０（ｅ）に示すように再生キーが押下されれば、そのトラックの再生が開始され、Editキーが押下されれば、そのトラックが編集対象として指定される。
【０１７４】
{48-3_51} 改良点(4)の詳細
続いて改良点(4)の詳細について説明する。図５１は、ジョグダイアルの操作例を示す図である。ジョグダイアルにより、操作者による回転操作を受け付けて、その回転量に応じて、液晶ディスプレィに表示されている再生経過時刻を増減させる。例えば図５１（ａ）に示すように、液晶ディスプレィに再生開始時刻が『00:00:20』と表示されているものとする。この場合、図５１（ｂ）に示すように、ジョグダイアルが反時計回りに回転されたとすると、再生開始時刻は、その回転量に応じて減少して『00:00:10』となる。また図５１（ｃ）に示すように、ジョグダイアルが時計回りに回転されたとすると、再生開始時刻は、その回転量に応じて増加して『00:00:30』となる。
【０１７５】
このように再生時間時間を増減させるのは、トラックにおける任意の再生時刻を指定するためであり、ジョグダイアルの回転により、任意の再生時刻が指定され、再生キーが押下されれば、上記｛数式２｝｛数式３｝に従って指定された位置からAOBを再生する。
また、分割編集においてジョグダイアルは、任意の再生開始時間を分割境界として特定する際、分割境界を微調整するために用いられる。
【０１７６】
{52-1} 再生装置の内部構成について
続いて再生装置の内部構成について説明する。図５２は、再生装置の内部構成を示す図である。本図において再生装置は、フラッシュメモリカード３１を接続するためのカードコネクタ１と、キーパネル、ジョグダイアルと接続されるユーザインターフェイス部２と、RAM３と、ROM４と、プレイリスト、トラックを一覧表示する一覧表示枠、再生経過時刻が表示される再生経過時刻枠を有する液晶ディスプレィ５と、液晶ディスプレィを駆動するためのLCDドライバ６と、AOBファイル毎に異なるFileKeyを用いて、AOB_FRAMEの暗号化を解除するデ・スクランブラ７と、デ・スクランブラ７によりAOB_FRAMEのデスクランブルが行われれば、当該AOB_FRAMEのADTSヘッダを参照して、当該AOB_FRAMEを復号することにより、PCMデータを得るAACデコーダ８と、AACデコーダ８の復号により得られたPCMデータをD/A変換して、ヘッドホン端子を介してスピーカーに出力するD/Aコンバータ９と、再生装置内の統合処理を行うCPU１０とを備える。このハードウェア構成からも判るように、本再生装置には、TrackManager、Default_Playlist情報を処理するための新規の構成は見られない。TrackManager、Default_Playlist情報の処理のために設けられているのは、RAM３内に確保されているDPLI常駐領域１１、PLI格納領域１２、TKI格納領域１３、FileKey格納領域１４、ダブルバッファ１５と、ROM４に格納されている再生制御プログラム及び編集制御プログラムである。
【０１７７】
{52-2} DPLI常駐領域１１
DPLI常駐領域１１は、カードコネクタ１に接続されフラッシュメモリカード３１から読み出されたDefault_Playlist情報を常駐させるために確保されている領域である。
{52_12} PLI格納領域１２
PLI格納領域１２は、操作者により選択され、再生対象になっているPlayList情報を格納しておくために確保されている領域である。
【０１７８】
{52-3} TKI格納領域１３
TKI格納領域１３は、TrackManagerに含まれる複数のTKIのうち、再生対象になっているAOBファイルに対応するTKIのみを格納しておくために確保されている領域であり、TKI1個分のデータサイズを有する。
{52-4} FileKey格納領域１４
FileKey格納領域１４は、プロテクト領域内のAOBSA1.KEYに含まれる複数のFileKeyのうち、再生対象になっているAOBファイルに対応するFileKeyのみを格納しておくために確保されている領域である。
【０１７９】
{52-5} ダブルバッファ１５
ダブルバッファ１５は、フラッシュメモリカード３１から読み出されたクラスタデータ（クラスタ一個当たりに格納されるデータ）を順次入力して格納するという入力処理と、格納されたクラスタデータから暗号化AOB_FRAMEを読み出して、順次デ・スクランブラ７に出力するという出力処理とを並列に行う場合に用いられる入出力バッファである。ダブルバッファ１５は、AOB_FRAMEとしての出力が済んだクラスタが占有していた領域を順次空き領域に解放し、この空き領域を、新たに読み出されたクラスタの格納に用いるという領域確保、即ち、リングポインタを用いた巡回式の領域確保を行う。
【０１８０】
{52-5_53_54A,B} ダブルバッファ１５における入出力
図５３は、ダブルバッファ１５におけるデータ入出力がどのように行われるかを示す図である。図５４（ａ）、（ｂ）は、リングポインタを用いた巡回式の領域確保がどのように行われるかを示す図である。
これらの図において左下向きの矢印は、クラスタデータの書込先アドレスについてポインタ、即ち、書込先ポインタを示す。左上向きの矢印は、クラスタデータの読出先アドレスについてのポインタ、即ち、読出先ポインタを示す。これらのポインタは、リングポインタとして用いられる。
【０１８１】
{54-6_53} フラッシュメモリカード３１がカードコネクタ１に接続されると、このフラッシュメモリカード３１のユーザデータ領域におけるクラスタデータは、矢印w1,w2に示すようにフラッシュメモリカード３１から読み出される。読み出されたクラスタデータは、ダブルバッファ１５において、書込先ポインタWP1,WP2に示される位置に順次格納されてゆく。
【０１８２】
{52-7_54A} このように格納されたクラスタデータに含まれるAOB_FRAMEのうち、読出先ポインタ▲１▼▲２▼▲３▼▲４▼▲５▼▲６▼▲７▼▲８▼▲９▼に指示される位置に存在するAOB_FRAMEは、矢印r1,r2,r3,r4,r5・・・・・・に示すように順次デ・スクランブラ７へと出力されてゆく。ここでダブルバッファ１５にクラスタデータ002,003が格納されており、読出先ポインタにてに示さる読出先が図５３の▲１▼▲２▼▲３▼▲４▼に示すように移動して、▲５▼に達した場合、クラスタ002に含まれるAOB_FRAMEは全て読み出されたことになるので、新たにクラスタ004を読み出して、図５４（ａ）の矢印w6に示すように、クラスタ002が占有していた領域に上書きする。
【０１８３】
{52-8_54B} また読出先ポインタにてに示さる読出先が▲６▼▲７▼に示すように移動して、▲９▼に達すれば、クラスタ003に含まれるAOB_FRAMEは全て読み出されたことになるので、新たにクラスタ005を読み出して、図５４（ｂ）の矢印w7に示すように、クラスタ003が占有していた領域に上書きする。以上のような、AOB_FRAMEの出力と、クラスタデータの上書きとが何度も繰り返されて、AOBファイルに含まれるAOB_FRAMEが順次デ・スクランブラ７、AACデコーダ８に出力されてゆく。
【０１８４】
{52-9_55〜58} ROM４に格納されている再生制御プログラム
続いてROM４に格納されている再生制御プログラムについて説明する。
図５５は、AOBファイル読み出し処理の処理手順を示すフローチャートであり、図５６、図５７、図５８は、AOB_FRAME出力処理の処理手順を示すフローチャートである。
【０１８５】
{52-9_55-1} これらのフローチャートにおいて、変数wとは、複数DPL_TK_SRPのそれぞれを指示する変数であり、変数zとは、それぞれのAOBファイルと、それに対応するTKIと、それに含まれるAOBとを一意に指示するための変数である。変数yとは、変数zにて指示されるAOB#zに含まれる個々のAOB_ELEMENTを指示するための変数であり、変数xとは、変数yにて指示されるAOB_ELEMENT#yに含まれるそれぞれのAOB_FRAMEを指示する変数である。先ず図５５を参照しながらAOBファイル読出処理の処理手順について説明する。
【０１８６】
{52-9_55-2} ステップＳ１においてCPU１０はPlayListManagerを読み出して、Default_Playlist情報及びPlayList情報を一覧表示する。ステップＳ２においてCPU１０は、Default_Playlist情報、PlayList情報の何れに従ってAOBを再生させるかの指定を待つ。ここで、Default_Playlist情報が指定された場合、ステップＳ２からステップＳ３に移行して、変数wを初期化し（#w←1）、ステップＳ４では、Default_Playlist情報におけるDPL_TK_SRP#wに対応づけられたDPL_TKINにより指定されているTKI#zを特定して、そのTKI#zのみをTKI格納領域１３に読み出す。そして、ステップＳ５においてTKI#zと同じ番号を有するAOBファイル#zを特定する。ここまでの手順で、ようやく、再生すべきAOBファイルが特定されたことになる。特定されたAOBファイルは、暗号化されているので、このAOBファイルの暗号化を解除すべく、以降ステップＳ６、ステップＳ７の処理を行う。即ち、ステップＳ６では、プロテクト領域をアクセスして、暗号鍵格納ファイルにおいて当該AOBファイル#zと同じ番号を有するFile Key Entry#zに格納されているFileKey#zを読み出す。ステップＳ７においてCPU１０は、FileKey#zをデ・スクランブラ７に設定する。かかる設定により、FileKeyはデ・スクランブラ７に設定されたので、以降、AOBファイルに含まれるAOB_FRAMEが順次デ・スクランブラ７に投入されれば、AOB_FRAMEは順次再生されることになる。
【０１８７】
{52-9_55-3} 以降、AOBファイルを格納している各クラスタを順次読み出してゆく。ステップＳ８では、ディレクトリエントリーにおけるそのAOBファイル#zについての『ファイル最初のクラスタ番号』を特定し、ステップＳ９においてCPU１０は、そのクラスタに格納されているデータをフラッシュメモリカード３１から読み出す。ステップＳ１０では、FAT値にクラスタ番号がFFFと記述されているか否かを判定し、もしFAT値がFFF以外の値なら、ステップＳ１１においてそのFAT値にて指示されているクラスタに格納されているデータを読み出す。かかる読み出し後、ステップＳ１０に移行する。ここで、何れかのクラスタに格納されているデータを読み出し、そのクラスタに対応づけられているFAT値を参照した際、そのFAT値にFFF以外の何れかのクラスタ番号が記述されている限り、ステップＳ１０−ステップＳ１１の処理は繰り返し行われる。これにより、そのFAT値により指示されているクラスタが順次読み出されてゆく。そのFAT値にクラスタ番号がFFFと記述されている場合、AOBファイル#zを構成するクラスタは全て読み出されたことになるので、ステップＳ１０からステップＳ１２に移行する。
【０１８８】
{52-9_55-4} ステップＳ１２においてCPU１０は、変数#wがDPL_TK_SRPの総数と一致したか否かを判定する。一致しないなら、ステップＳ１３に移行して、変数#wをインクリメントした後（#w←#w+1）、ステップＳ４に移行する。ステップＳ４においてDefault_Playlist情報におけるDPL_TK_SRP#wのDPL_TKIN#wにより指定されているTKI#zを特定して、そのTKI#zのみをTKI格納領域１３に読み出す。この際、TKI格納領域１３にはそれまで使用されていたTKIが格納されているが、CPU１０は、TKI格納領域１３に既に格納されているTKIを新たに読み出したTKIを用いて上書きする。このような上書きによりTKI格納領域１３には、最新のTKIのみが格納されることになる。このようにTKIが上書きされれば、ステップＳ５〜ステップＳ１２の処理をAOBファイル#zについて繰り返す。ステップＳ５〜ステップＳ１２の処理が繰り返され、Default_Playlist情報に含まれる全てのDPL_TK_SRPに対応するTKI、AOBファイルが読み出されれば、変数#wとDPL_TK_SRPの総数とが一致して、ステップＳ１２がYesとなり、本フローチャートを終了する。
【０１８９】
{52-9_56_57_58} AOB_FRAME出力処理
かかるAOBファイル読出処理と並行して、CPU１０は、図５６、図５７、図５８のフローチャートに従い、AOB_FRAME出力処理を行う。本フローチャートにおいてplay_timeとは、これまで再生が経過した時間、即ち、再生経過時刻を示す変数であり、液晶ディスプレィ５の時刻表示枠内の時刻は、このplay_timeの更新に応じて、表示内容が書き換えられる。また、play_dataとは、これまで再生されたデータ長である。
【０１９０】
{52-9_56-1} ステップＳ２１において、CPU１０は、AOBファイル#zについてのクラスタデータがダブルバッファ15に蓄積されたかを監視している。クラスタデータが蓄積されない限り、このステップＳ２１を繰り返し行うが、クラスタデータが蓄積されれば、ステップＳ２２において、#x、#yの初期化を行い（#x←1,#y←1）、その後、ステップＳ２３において、AOBファイル#zについてのクラスタにおいて、TKI#zに含まれるBIT#zのData_Offset以降からAOB_ELEMENT#yにおけるAOB_FRAME#xを検出する。ここでSZ_DATAから7バイトは、ADTSヘッダが占有しているものとして、当該ADTSヘッダを参照し、ADTSヘッダに示されているデータ長が本体部のオーディオデータであると解析して、当該ADTSヘッダと、本体部のオーディオデータとを読み出し、デ・スクランブラ７に出力する。デ・スクランブラ７によりAOB_FRAMEの暗号化が解除され、AACデコーダ８により復号が行われれば、音声として再生されることになる。
【０１９１】
{52-9_56-2} 検出後、ステップＳ２４において、AOB_FRAME#xをデ・スクランブラ7に出力し、ステップＳ２５において、再生経過時刻play_timeをAOB_FRAME#xに相当する再生時間だけインクリメントし、再生済みデータ数play_dataをAOB_FRAME#xに相当するデータ数だけインクリメントする。ここでAOB_FRAMEの再生時間長は、20msecであるので、再生経過時刻play_timeには、20msecが加算されることになる。
【０１９２】
1番目のAOB_FRAMEがデ・スクランブラ７に出力されれば、ステップＳ２６においてAOB_FRAME#xのADTSヘッダを参照して、次のAOB_FRAMEが何処に存在するかを特定する。ステップＳ２７では、変数#xのインクリメントを行い（#x←#x+1）、次のAOB_FRAMEをAOB_FRAME#xとする。ステップＳ２８においてAOB_FRAME#xをデ・スクランブラ7に投入する。その後、ステップＳ２９では、play_timeを、AOB_FRAME#xに相当する再生時間だけインクリメントすると供に、play_dataをAOB_FRAME#xに相当するデータ数だけインクリメントする。AOB_FRAME#xをインクリメントした後、ステップＳ３０においてCPU１０は、#xが『FNs_1st_TMSRTE』に達したかを判定する。#xが『FNs_1st_TMSRTE』に達しないのなら、ステップＳ３１において、Playキー以外のキーが押下されたかどうかを確認した後、ステップＳ２６に移行する。以降、#xが『FNs_1st_TMSRTE』に達するまで、または、Playキー以外のキーが押下されるまで、ステップＳ２６〜ステップＳ３１の処理は繰り返し行われる。ここでPlayキー以外のキーが押下された場合、本フローチャートを終了して、押下されたキーに該当する処理を行う。押下されたキーが停止キーなら再生処理を停止し、押下されたキーが一時停止キーなら一時停止を行う。
【０１９３】
{52-9_57-1} 一方、#xが『FNs_1st_TMSRTE』に達したなら、ステップＳ３０がYesとなり、図５７のステップＳ３２に移行する。ステップＳ２６からステップＳ３０までの処理にて、AOB_ELEMENTに含まれる全てのAOB_FRAMEがデ・スクランブラ７に投入されたので、次のAOB_ELEMENTに処理対象を移行すべく、ステップＳ３２において#yをインクリメントすると共に、#xを初期化する（#y←#y+1,#x←1）。
【０１９４】
その後、ステップＳ３３においてTKTMSRTを参照してAOB_ELEMENT#yについての先頭アドレスを算出する。以降、ステップＳ３４〜ステップＳ４２からなる処理を行う。ステップＳ３４〜ステップＳ４２の処理は、AOB_ELEMENTに含まれるAOB_FRAMEを次々と読み出す処理である点で、ステップＳ２４〜ステップＳ３１からなる処理と同一であるといえる。ステップＳ２４〜ステップＳ３１の処理と異なるのは、後者におけるループ処理の終了条件は、#xが『FNs_1st_TMSRTE』に達することであるのに対し、前者におけるループ処理の終了条件は、#xが『FNs_Middle_TMSRTE』に達することである。#xが『FNs_Middle_TMSRTE』に達して、ステップＳ３４〜ステップＳ４２からなるループ処理が終了すると、ステップＳ４１がYesとなってステップＳ４３に移行する。ステップＳ４３においてCPU１０は#yをインクリメントすると共に、#xを初期化する（#y←#y+1,#x←1）。その後、ステップＳ４４において、変数yが、TKI#zのTMSRT_Headerにおける(TotalTMSRT_entry_Number-1)と等しい値に達したかを判定する。#yが(TotalTMSRT_entry_Number-1)より小さい場合、AOB_ELEMENT#yは未だ、最後のAOB_ELEMENTに達してしていないので、ステップＳ４４からステップＳ３２に移行することにより、ステップＳ３２〜ステップＳ４２の処理を継続して行う。#yが(TotalTMSRT_entry_Number-1)に達した場合、最後のAOB_ELEMENTの1つ前のAOB_ELEMENTまで、AOB_FRAMEの読み出し処理は完遂したと考えられるので、ステップＳ４４がYesとなり、図５８のステップＳ４５に移行する。
【０１９５】
{52-9_57-2} ステップＳ４５〜ステップＳ５４の処理は、最後のAOB_ELEMENTに含まれる複数のAOB_FRAMEをそれぞれ読み出す処理であるという点において、上述したステップＳ３３〜ステップＳ４２の処理と同一といえる。異なるのは、ステップＳ３３〜ステップＳ４２におけるループ処理は、ステップＳ４１において#xが『FNs_Middle_TMSRTE』に達することがループ処理の終了条件であったのに対して、ステップＳ５３では、#xが『FNs_Last_TMSRTE』であり、かつ、これまで読み出されたデータサイズを示すPlay_dataがSZ_DATAに達することが、ループ処理の終了条件になっている点である。
【０１９６】
このステップＳ５３の条件が満たされるまで、ステップＳ４９〜ステップＳ５４の処理は繰り返し行われ、この条件が満たされれば、ステップＳ５３がYesとなって、ステップＳ５５に移行する。ステップＳ５５においてCPU１０は、#zをインクリメントしてからステップＳ２１に移行して（#z←#z+1）、次のAOBファイルがダブルバッファ１５に蓄積されるのを待つ。蓄積されれば、ステップＳ２１からステップＳ２２に移行し、次のAOBファイルについて、ステップＳ２２〜ステップＳ５４の処理を繰り返し行う。即ち、次のDPL_TK_SRPのDPL_TKINにより指定されているTKIを特定し、そのTKIに対応するAOBファイル、即ち、TKIと同じ番号を有するAOBファイルを特定する。その後、プロテクト領域をアクセスして、暗号鍵格納ファイルにおいて当該TKIと同じ番号を有するFileKeyを特定し、当該FileKeyを読み出して、当該FileKeyをデ・スクランブラに設定してから、そのTKIと同じ番号を有するAOBファイルに含まれるAOB_FRAMEを順次読み出して再生してゆくのである。
【０１９７】
{52-9_57-3_59} 再生経過時刻の更新
図５９は、液晶ディスプレィ５の時刻表示枠に表示される再生経過時刻が、変数Play_Timeの更新したがい、増加してゆく様子を示す図である。本図（ａ）では、再生経過時刻は00:00:00.000であるが、AOB_FRAME#1の再生が終了した時点で、再生経過時刻にAOB_FRAMEの時間長20msecが加算されて00:00:00.020に更新されている。AOB_FRAME#2の再生が終了した時点で、再生経過時刻にAOB_FRAMEの時間長20msecが加算されて00:00:00.040に、AOB_FRAME#6の再生が終了した時点で、再生経過時刻は00:00:00.120となっていることがわかる。
【０１９８】
以上がAOB_FRAME出力処理の全貌である。本フローチャートのステップＳ３１において、Playキー以外のキーの押下時に、本フローチャートの処理を中断することは既に述べた通りであり、そのようなPlayキー以外のキーとして一時停止キーや停止キーがあることも説明済みであるが、一時停止キーや停止キー以外にも、特殊再生を再生装置に行わせるためのキーが押下された場合も、図５６、図５７、図５８のフローチャートの処理は中断し、その押下されたキーに応じた処理が実行される。以降、>>キーが押下され、順方向サーチ再生を実行する場合のCPU１０の処理手順と、一時停止キーや停止キーが押下された後に、ジョグダイアルが操作されることにより、タイムサーチ機能が実行される場合のCPU１０の処理手順とについて説明する。
【０１９９】
{52-10_60} 順方向サーチ再生
図６０は、順方向サーチ再生を行う場合のCPU１０の処理手順を示すフローチャートである。>>キーが操作者により押下されて図５６、図５７、図５８のステップＳ３１、ステップＳ４２、ステップＳ５４がYesになった際、CPU１０により実行されるのが本フローチャートである。
【０２００】
ステップＳ６１において、CPU１０はAOB_ELEMENT#yのAOB_FRAME#xからx+f(t)-1までをデ・スクランブラ7に投入する。ここで、『t』とは、間欠再生時間であり、f(t)を、間欠再生時間に相当するフレーム数、d(t)を間欠再生時間に相当するデータ数とすると、ステップＳ６２では、再生経過時刻を示すplay_time、再生済みデータ数を示すplay_dataを、t:間欠再生時間、f(t):間欠再生時間に相当するフレーム数、d(t):間欠再生時間に相当するデータ数に基づいて更新する（x←x+f(t)、play_time←play_time+t、play_data←play_data+d(t) 尚、一般に間欠再生時間は240ミリ秒(12個のAOB_FRAMEの再生時間長)に相当する。）。
【０２０１】
{52-10_60-1_61A,B} 図６１（ａ）、（ｂ）は、順方向サーチ再生時において、再生経過時刻がインクリメントされてゆく様子を示す図である。図６１（ａ）は、再生経過時刻の初期状態を示し、再生時点は、AOB_ELEMENT#51のAOB_FRAME#1であることを示す。この場合の再生経過時刻は、00:00:01.000であることがわかる。ここで、間欠再生時間として、1番目から12番目までのAOB_FRAMEがデ・スクランブラ７に投入されて、再生経過時刻に1AOB_FRAMEの時間長である240ミリ秒が加算されると、図６１（ｂ）に示すように、再生経過時刻は、00:00:01.240となる。
【０２０２】
{52-10_60-2} これらを更新した後、ステップＳ６３においてCPU１０は、インクリメント後のAOB_FRAME#xと、AOB_ELEMENT#yの総フレーム数との大小比較して、インクリメント後のAOB_FRAME#xがAOB_ELEMENT#y内に存在するかを判定する。具体的には、AOBの先頭に位置するAOB_ELEMENTのフレーム数は『FNs_1st_TMSRTE』であり、中間のもののフレーム数は『FNs_Middle_TMSRTE』、最後のもののフレーム数は『FNs_Last_TMSRTE』に示されるので、これらと、AOB_FRAME#xとを比較することにより、判定を行う。もし更新後のAOB_FRAME#xがAOB_ELEMENT内に存在しないのなら、ステップＳ６４においてAOB_ELEMENT#yに後続するAOB_ELEMENTが存在するかを判定する。ここでAOB_ELEMENT#yが最後のAOB_ELEMENTであり、後続するAOB_ELEMENTが存在しない場合、ステップＳ６４がNoとなり、本フローチャートの処理を終了するが、後続するAOB_ELEMENTが存在する場合、ステップＳ６５において、AOB_FRAME#xからAOB_ELEMENT#yにおけるフレーム数を減じ、ステップＳ６６において#yを更新することにより（y←y+1）、AOB_FRAME#xを後続するAOB_ELEMENT#yにおけるAOB_FRAMEのフレーム位置に変換する。もし更新後のAOB_FRAME#xがAOB_ELEMENT内に存在するのなら、これらステップＳ６５〜ステップＳ６６をスキップして、ステップＳ６７に移行する。
【０２０３】
{52-10_60-3} 続いて、間欠スキップ間隔に応じて、AOB_FRAME#x、再生経過時刻play_time、再生済みデータ数play_dataの更新を行う。ここで、間欠スキップ間隔に相当する時間をskip_time(2秒)とし、間欠スキップ間隔skip_timeに相当するフレーム数をf(skip_time)、間欠スキップ間隔skip_timeに相当するデータ数d(skip_time)とすると、ステップＳ６７において、これらを用いてAOB_FRAME#x、再生経過時刻play_time、再生済みデータ数play_dataを更新する（x←x+f(skip_time),play_time←play_time+skip_time,play_data←play_data+d(skip_time)）。
【０２０４】
{52-10_60-4_61C} 図６１（ｃ）に示すように、AOB_ELEMENT#51内のフレーム位置を示すAOB_FRAME#xに間欠スキップ間隔を加算したものとする。この加算後の#xがAOB_ELEMENT#51のフレーム数を上回れば、AOB_ELEMENTを次のAOB_ELEMENTに更新すると共に、加算後の#xから、AOB_ELEMENT#51のフレーム数を減じることにより、AOB_FRAME#xを、AOB_ELEMENT#52におけるフレーム位置に変換する。この場合、AOB_ELEMENT#yがAOB_ELEMENT#52となり、再生経過時刻は、00:00:01.240に2.000を加算することにより、00:00:03.240となる。AOB_FRAME#xは、AOB_ELEMENT#52におけるAOB_FRAME#62(=(3240msec-2000msec)/20msec)となる。
【０２０５】
{52-10_60-5_61(d)} その後、AOB_ELEMENT#52におけるAOB_FRAME#62がデ・スクランブラ７に投入されれば、図６１（ｄ）に示すように再生経過時刻は、00:00:03.240に0.240を加算することにより、00:00:03.480となる。
ステップＳ６７において間欠的スキップ時間に応じた更新を行えば、ステップＳ６８〜ステップＳ７１の処理を行う。このステップＳ６８〜ステップＳ７１の処理は、ステップＳ６３〜ステップＳ６６の処理と同一であり、間欠スキップ間隔skip_timeに相当するフレーム数が加算された後のAOB_FRAMEがAOB_ELEMENT#y内に存在するかどうかの判定がなされて、存在するのなら、その次のAOB_ELEMENTをAOB_ELEMENT#yとし、AOB_FRAME#xを、新たなAOB_ELEMENT#yにおけるフレーム位置に変換する。
【０２０６】
間欠再生時間及び間欠的スキップ時間に応じて、AOB_FRAME#x、AOB_ELEMENT#yがインクリメントされれば、ステップＳ７２において、CPU１０は、TKTMSRTを参照してAOB_ELEMENT#yについての先頭アドレスを算出し、ステップＳ７３においてAOB_ELEMENT#yにおける先頭アドレスからADTSヘッダの探索を開始することにより、AOB_FRAME#xを検出する。そして、ステップＳ７４において、順方向スキップキー以外のキーが押下されたか否かを判定した後、ステップＳ６１においてAOB_ELEMENT#yのAOB_FRAME#xからx+f(t)-1までをデ・スクランブラ7に投入し、再度ステップＳ６２〜ステップＳ７３の処理を繰り返し行う。
【０２０７】
以上の処理にて、AOB_FRAME#x、AOB_ELEMENT#yがインクリメントされ、再生位置が進行してゆく。その後、操作者により再生キーが押下されれば、ステップＳ７４がNoとなり、本フローチャートの処理を終了する。
{52-11} タイムサーチ機能の実行
タイムサーチ機能が行われた場合の処理について説明する。Default_Playlist情報におけるトラックを一覧表示し、任意のトラックの指定を受け付ける。トラックが指定され、ジョグダイアルが操作されると、再生開始時刻を更新する。再生開始時刻が増減した後、再生キーが押下されると、その再生が指定された時刻をJmp_Entry(秒)と特定する。一方、指定されたトラックが複数のAOBからなるか、単一のAOBからなるかを判定する。単一のAOBからなる場合、｛数式２｝を満たすAOB_ELEMENT#yと、AOB_FRAME#xとを算出する。｛数式２｝を満たすAOB_ELEMENT#y、AOB_FRAME#xが算出されれば、このAOBに対応するTKTMSRTにおいて、y+2番目に位置するアドレスから、AOB_FRAME#xの探索を始め、x番目のAOB_FRAMEが探索されれば、このx番目のAOB_FRAMEから再生を開始する。
【０２０８】
{52-12}
複数のAOBからなる場合、｛数式３｝を満たすAOB#n、AOB_ELEMENT#yと、AOB_FRAME#xとを算出する。｛数式３｝を満たすAOB#n、AOB_ELEMENT#y、AOB_FRAME#xが算出されれば、このAOB#nに対応するTKTMSRTにおいて、y+2番目に位置するアドレスから、AOB_FRAME#xの探索を始め、x番目のAOB_FRAMEが探索されれば、このx番目のAOB_FRAMEから再生を開始する。
【０２０９】
続いてBITにおけるFNs_1st_TMSRTEは80フレームであり、FNs_Last_TMSRTEは50フレーム、FNs_Middle_TMSRTEが94フレームであるAOBにおいて、任意の再生時刻から再生を開始する場合について説明する。
{52-13_62A,B}
ここで、タイムサーチ機能が行われる場合の具体例として、ジョグダイアルにより、再生開始時刻が指定された場合に再生を開始すべきAOB_ELEMENT、再生を開始すべきフレーム位置をどのように特定するかについて説明する。図６２は、タイムサーチ機能が行われる場合の具体例を示す図である。ここで図６２（ａ）に示すように、再生装置が把持されて、あるAOBが再生対象として指定された状態で、その右手の親指により、ジョグダイアルの回転操作がなされ、 再生開始時刻=00:04:40.000(=280.00sec)が指定されたものとする。このAOBについてTKI内のBITが、図６２（ｂ）に示す内容である場合、再生開始時刻=00:04:40.000(=280.00sec)を｛数式２｝に適用すると、
280sec ＝(FNs_1st_TMSRTE＋FNs_middle_TMSRTE・y＋x)×20msec
＝( 80 + 94・148 + 8)×20msec
となるので、｛数式２｝を満たすAOB_ELEMENT#y、AOB_FRAME#xとして、y=148,x=8のAOB_FRAMEが得られる。
【０２１０】
このようにy=148と特定されたので、y+2番目のAOB_ELEMENT#150(=148+2)のエントリーアドレスをTKTMSRTから取得して、ここから8番目のAOB_FRAMEから、再生を開始すれば、 再生経過時刻=00:04:40.000(=280.00sec)から、再生を開始することができる。
{52-14_63_64_65}
以上でPlayキーが押下された場合の、CPU１０の処理内容の説明を終える。続いてROMに格納されている編集制御プログラムについて説明する。本編集制御プログラムは、Editキーが押下された場合に実行されるものであり、図６３、図６４、図６５にその処理手順を示す。以降、これらのフローチャートを参照しながら、編集制御プログラムの処理内容について説明する。
【０２１１】
{52-14_63-1} 編集制御プログラム
Editキーが押下されれば、図６３のステップＳ１０１において削除、分割、統合といった典型的な編集操作の何れを行うかを操作者に提示する対話画面を表示し、その後、ステップＳ１０２において、対話画面に対する処理が指定されたかを判定する。ここで対話画面の操作において、>>|キー、|<<キーをそれぞれ上下カーソル操作を受け付けるためのキー、即ち、上下カーソルキーとして用いるものとする。削除処理が指定されると、ステップＳ１０３、ステップＳ１０４からなるループ処理に移行する。ステップＳ１０３では、>>|キー、|<<キーが押下されたか否かを判定し、ステップＳ１０４では、編集キーが押下されたか否かを判定する。>>|、|<<キーが押下されれば、ステップＳ１０３からステップＳ１０５に移行して、指示されたトラックを編集対象として指定する。一方、編集キーが押下されれば、削除すべきトラックが特定されたとして、図４４に示した処理を行い、指定されたトラックについてのTKIのTKI_BLK_ATRを『Unused』に設定することにより、特定されたトラックを削除する。
【０２１２】
{52-14_63-2} 統合編集処理
統合編集が指定されると、ステップＳ１０２からステップＳ１０７〜ステップＳ１０９からなるループ処理に移行する。ステップＳ１０７〜ステップＳ１０９からなるループ処理では、>>|キー、|<<キーの押下と、編集キーの押下とを受け付ける。>>|｜、|<<キーが押下されれば、ステップＳ１０７からステップＳ１１０に移行して、指示されたトラックに対するハイライト表示を行う。編集キーが押下されれば、ステップＳ１０８がYesとなり、ステップＳ１１１に移行する。ステップＳ１１１では、カーソルキーにて指示されたトラックを、編集対象として指定し、再度、ステップＳ１０７〜ステップＳ１０９からなるループ処理に移行する。
【０２１３】
2トラック目の編集対象が特定されれば、ステップＳ１０９がYesとなって、ステップＳ１１２に移行する。ステップＳ１１２では、先行するトラック、後続するトラックについてのTKIのBITを参照することにより、両トラックの末尾及び先頭に配置されているAOB（その前後にもAOBが配されている場合は、その前後のAOB）のタイプがType1、Type2の何れであるかを判定する。
【０２１４】
各AOBのタイプが判明したのなら、ステップＳ１１３においてそれら各タイプのAOBの配置画像に示した何れの配置パターンに該当するかを判定する。図３２（ａ）〜（ｄ）の何れかの配置パターンに該当し、統合後においても、Type2AOBが3つ連続しないことが明らかならば、ステップＳ１１５において先行するトラック、後続するトラックを1つのトラックに統合する。即ち、これらに対応づけられたTKI、DPL_TK_SRPに対して、図４６に示した操作を行い、TKIのTKI_BLK_ATRを書き換えることにより、それら操作対象として選択された複数のトラックを1つのトラックに統合する。図３２（ａ）〜（ｄ）の何れの配置パターンにも該当せず、統合後にType2のAOBが3つ連続してしまう場合は、ステップＳ１１４において統合後のトラックにアンダーフローの発生の恐れがある旨を表示し、統合処理を中断する。
【０２１５】
{52-14_64-1} トラックの分割処理
トラックの分割が指定されると、ステップＳ１０２からステップＳ１１６〜ステップＳ１１７からなるループ処理に移行する。ステップＳ１１６〜ステップＳ１１７からなるループ処理では、>>|キー、|<<キーの押下と、編集キーの押下とを受け付ける。>>|｜、|<<キーが押下されれば、ステップＳ１１６からステップＳ１１８に移行して、指示されたトラックを編集対象として指定する。編集キーが押下されれば、ステップＳ１１７がYesとなり、ステップＳ１１９に移行する。ステップＳ１１９では、カーソルキーにて指示されたトラックを、編集対象として指定する。その後、ステップＳ１２０では、分割が指定されたトラックの再生を開始して、ステップＳ１２１においてMarkキーの押下を受け付ける。Markキーの押下が行われると、トラックの再生を一時停止し、ステップＳ１２２〜ステップＳ１２３からなるループ処理に移行する。ステップＳ１２２では、ジョグダイアルに対する回転操作を受け付け、ジョグダイアルに対して回転操作がなされると、ステップＳ１２４においてその回転操作に伴い、再生開始時間を増減させる。その後、ステップＳ１２２〜ステップＳ１２３からなるループ処理に再度移行する。回転操作により再生開始時刻が増減された状態で、編集キーが押下されれば、ステップＳ１２３からステップＳ１２５に移行し、ステップＳ１２５において、編集キーが押下された再生時間を分割境界として指定する（尚、分割境界の指定にあたっては、アンドゥ機能（編集の取り消し）が可能である。）。その後、ステップＳ１２６において図４７で説した処理を行い、DPLI、TKIを更新することにより、トラックの分割を行う。
【０２１６】
{52-14_65-1} プレイリストの設定編集処理
プレイリストの設定編集が指定されると、図６５のフローチャートに移行する。本フローチャートにおいて変数kとは、これから設定されるプレイリストにより、再生順序が規定される個々のトラックを指示するための変数であり、図６５のフローチャートでは、先ずステップＳ１３１においてこの変数kに1を設定した後、ステップＳ１３２〜ステップＳ１３４からなるループ処理に移行する。ステップＳ１３２〜ステップＳ１３４からなるループ処理では、>>|キー、|<<キーの押下と、編集キーの押下と、停止キーの押下とを受け付ける。>>|キー、|<<キーが押下されれば、ステップＳ１３２からステップＳ１３５に移行して、>>|キー、|<<キーにより指示されたトラックを指定する。編集キーが押下されれば、ステップＳ１３３がYesとなり、ステップＳ１３６に移行する。ステップＳ１３６では、編集キーにて指示されたトラックを、k番目に再生されるべきトラックとして特定する。その後、ステップＳ１３７において、変数kをインクリメントして、ステップＳ１３２〜ステップＳ１３４のループ処理に移行する。このような処理を繰り返すことにより、2トラック目、3トラック目、4トラック目のトラックが順次特定される。このようにして、新たに作成されたプレイリストにて再生されるべき複数のトラックが特定された状態で停止キーが押下されると、ステップＳ１３４からステップＳ１３８に移行して、これらに対応づけられたTKIを特定するPL_TK_SRPからなるPlayList情報を生成する。
【０２１７】
（記録装置）
{66-1} 記録装置
続いて、フラッシュメモリカード３１の記録装置についての一例を説明する。図６６は、フラッシュメモリカード３１の記録装置の一例を示す図である。本図における記録装置は、インターネットを介した通信が可能であり、電子音楽配信によりSD_Audioディレクトリィが暗号化された状態で通信回線を介して伝送されてくる場合、又は、電子音楽配信によりオーディオデータトランスポートストリームが配信されてくる場合にこれらを受信することができる汎用パーソナルコンピュータである。
【０２１８】
{67-1} 記録装置のハードウェア構成
図６７は、記録装置のハードウェア構成を示す図である。本図において記録装置は、フラッシュメモリカード３１を接続するためのカードコネクタ２１と、RAM２２と、記録装置の統合制御を行うための記録制御プログラムを格納した固定ディスク装置２３と、マイクから入力された音声をA/D変換して、PCMデータを得るA/Dコンバータ２４と、単位時間当たりのPCMデータをエンコードして、ADTSヘッダを付与することにより、AOB_FRAMEを得るACCエンコーダ２５と、各AOBファイル毎のFileKeyを用いて、AOB_FRAMEを暗号化するスクランブル部２６と、電子音楽配信によりSD_Audioディレクトリィが暗号化された状態で通信回線を介して伝送されてくる場合、又は、電子音楽配信によりオーディオデータトランスポートストリームが通信回線を介して伝送されてくる場合に、オーディオデータトランスポートストリームを受信するモデム装置２７と、記録装置内の統合制御を行うCPU２８と、操作者からの操作を受け付けるキーボード２９と、ディスプレィ３０とを有する。
【０２１９】
{67-2} 入力経路RT1〜RT4
電子音楽配信によりデータ領域及びプロテクト領域に書き込むべきSD_Audioディレクトリィが暗号化された状態で通信回線を介して伝送されてくる場合、記録装置はこれらを正当に受信した時点で、フラッシュメモリカード３１のデータ領域及びプロテクト領域に書き込めばよい。しかし、SD_Audioディレクトリィでは無く、電子音楽配信によりオーディオデータトランスポートストリームそのものが伝送されてくる場合、またPCMデータの状態で記録装置に入力されてくる場合、原音の状態で記録装置に入力されてくる場合、記録装置は、以下に示す4つの入力経路を経て、フラッシュメモリカード３１にオーディオデータトランスポートストリームを書き込むことなる。
【０２２０】
本図における記録装置がフラッシュメモリカード３１に、オーディオデータトランスポートストリームを格納する際、オーディオデータトランスポートストリームの入力経路には、図６７に示す入力経路RT1、入力経路RT2、入力経路RT3、入力経路RT4がある。
{67-3} 入力経路RT1
入力経路RT1は、電子音楽配信によりSD_Audioディレクトリィが暗号化された状態で通信回線を介して伝送されてくる場合、又は、オーディオデータトランスポートストリームが通信回線を介して伝送されてくる場合の入力経路であり、この場合、トランスポートストリームに含まれるAOB_FRAMEは、一個のAOBに属するもの毎に異なるFileKeyを用いて暗号化されている。暗号化済みのトランスポートストリームに対しては、再度の暗号化、符号化の必要は存在しないので、SD_Audioディレクトリィ又はオーディオデータトランスポートストリームは、暗号化された状態で、RAM２２に格納される。
【０２２１】
{67-4} 入力経路RT2
入力経路RT2は、マイクから音声が入力されてくる場合の入力経路である。この場合、A/Dコンバータ２４にマイクから入力された音声をA/D変換を行わせて、PCMデータを得る。そしてPCMデータのエンコードをAACエンコーダ２５に行わせて、ADTSヘッダを付与することにより、AOB_FRAMEを得る。その後、スクランブル部２６に各AOBファイル毎のFileKeyを用いて、AOB_FRAMEを暗号化を行わせることにより、暗号化がなされたオーディオデータを得る。その後、オーディオデータをRAM２２に格納する。
【０２２２】
{67-5} 入力経路RT3
入力経路RT3は、CDから読み出されたPCMデータが装置に入力されてくる場合の入力経路である。PCMデータの状態で入力されてくるので、当該PCMデータは、そのままAACエンコーダ２５に入力される。そのように入力されたPCMデータのエンコードをAACエンコーダ２５に行わせて、ADTSヘッダを付与することにより、AOB_FRAMEを得る。その後、スクランブル部２６に各AOB_FRAME毎のFileKeyを用いて、AOB_FRAMEを暗号化を行わせることにより、暗号化がなされたオーディオデータを得る。その後、オーディオデータはRAM２２に格納される。
【０２２３】
{67-6} 入力経路RT4
入力経路RT4は、3つの入力経路RT1,RT2,RT3において入力されたトランスポートストリームを、フラッシュメモリカード３１に書き込む際の入力経路である。
かかるオーディオデータの格納に伴い、TKI、Default_Playlist情報は生成される。再生装置の場合と同様、かかる記録装置の機能主体も、ROMに記録されている記録プログラムである。即ち、AOBの記録やTrackManager、PlayListManagerの記録といった本実施形態特有の処理は、固定ディスク装置に記録されている記録プログラムにより実現される。
【０２２４】
{67-7_68} 記録処理の処理手順
以降、フローチャートを参照しながら、上記入力経路RT1,RT2,RT3,RT4において、トランスポートストリームをフラッシュメモリカード３１に書き込む場合の記録処理の処理手順について説明する。図６８は、記録処理の処理手順を示すフローチャートである。本フローチャートにおいて引用する変数としては、Frame_Number、Data_Sizeといったものがある。Frame_Numberとは、これまでAOBファイルに記録されたAOB_FRAMEの総数を管理するための変数であり、Data_Sizeとは、これまでAOBファイルに記録されたAOB_FRAMEのデータサイズを管理するための変数である。
【０２２５】
本フローチャートが実行されると、ステップＳ２００においてCPU２８は、DefaultPlaylist,TrackManagerを作成し、ステップＳ２０１において、変数#z,#wを初期化する（z←1,w←1）。ステップＳ２０２では、AOBファイル#zを作成してフラッシュメモリカード３１におけるデータ領域に格納する。この状態で、データ領域におけるSD_Audioディレクトリのディレクトリエントリーには、AOBファイル#zのファイル名、ファイル拡張子、最初のクラスタ番号が設定されることになる。続くステップＳ２０３において、CPU２８は、TKI#zを作成してTrackManagerに格納し、ステップＳ２０４においてCPU２８は、DPL_TK_SRP#wを作成してDefaultPlaylist情報に格納する。以降ステップＳ２０５において変数#yを初期化し（y←1）、ステップＳ２０６において、Frame_Number、Data_Sizeのそれぞれを初期化する（Frame_Number←0、Data_Size←0）。
【０２２６】
ステップＳ２０７においてCPU２８は、AOBファイル#zに書き込むべき、オーディオデータトランスポートストリームの入力が終了したかを判定する。AACエンコーダ２５により符号化され、スクランブル部２６により暗号化されたオーディオデータトランスポートストリームが続々とRAM２２に格納されており、クラスタデータの書き込みを継続する必要がある場合、ステップＳ２０７がNoとなりステップＳ２０９に移行する。ステップＳ２０９においてCPU２８は、クラスタサイズ分のAACオーディオデータがRAM２２に蓄積したかを判定する。RAM２２にクラスタデータが蓄積した場合、ステップＳ２０９がYesとなり、ステップＳ２１０に移行して、RAM２２に蓄積されたクラスタサイズのAACオーディオデータをフラッシュメモリカード３１に書き込んだ後ステップＳ２１１に移行する。クラスタデータの蓄積が完了していない場合、ステップＳ２１０をスキップしてステップＳ２１１に移行する。ステップＳ２１１においてCPU２８は、Frame_Numberをインクリメントし(Frame_Number←Frame_Number+1)、Data_SizeをそのAOB_FRAMEのデータサイズだけインクリメントする。かかる更新を行った後、ステップＳ２１２においてFrame_Numberが、『FNs_Middle_TMSRTE』として定めているフレーム数に達したか否かを判定する。ここで『FNs_Middle_TMSRTE』は、オーディオデータトランスポートストリームが符号化された際のサンプリング周波数に応じた値となるので、Frame_Numberが、『FNs_Middle_TMSRTE』に達した場合は、ステップＳ２１２はYesとなるが、そうでない場合、ステップＳ２１２はNoになり、ステップＳ２０７に移行する。以降、ステップＳ２０７、ステップＳ２１２がYesとなるまで、ステップＳ２０７〜ステップＳ２１２は繰り返し行われる。
【０２２７】
Frame_Numberが『FNs_Middle_TMSRTE』に達してステップＳ２１２がYesとなった場合、ステップＳ２１２からステップＳ２１３に移行し、Data_SizeをAOB_ELEMENT#yについてのTMSRT_entry#yとしてTKI#zのTKTMSRTに格納してステップＳ２１４において#yをインクリメントした後（y←y+1）、ステップＳ２１５において変数yが252に達したか否かを判定する。ここで252という値は、一個のAOBに格納できるAOB_ELEMENTの総数を示す値であり、変数yが252に達しない場合、ステップＳ２１６に移行する。ステップＳ２１６では、無音状態が所定時間以上継続しており、オーディオデータがトラック間の境界に達したか否かを判定する。無音状態が存在しない場合、ステップＳ２０６〜ステップＳ２１５の処理を繰り返し行う。変数yが252に達した場合、又は、無音状態が所定時間以上継続した場合、ステップＳ２１５、ステップＳ２１６の何れか一方がYesとなり、ステップＳ２１７に移行して、変数#z,#wをインクリメントする（z←z+1,w←w+1）。その後、インクリメントされた#zについて、ステップＳ２０２〜ステップＳ２１６の処理を繰り返し行う。かかる繰り返しにより、複数のAOB_ELEMENTを含むAOBが次々とフラッシュメモリカード３１に書き込まれてゆく。
【０２２８】
ここで、AACエンコーダ２５、スクランブル部２６、モデム装置２７からのオーディオデータトランスポートストリームの伝送が終了した場合、AOBファイル#zに書き込むべき、オーディオデータトランスポートストリームの入力が終了したことになるので、ステップＳ２０７がYesとなり、ステップＳ２０８に移行する。ステップＳ２０８においてCPU２８は、Data_SizeをAOB_ELEMENT#yについてのTMSRT_entry#yとしてTKI#zのTKTMSRTに格納し、RAM22に蓄積されたオーディオデータをAOB#zに対応するAOBファイルに格納した後、本フローチャートの処理を終了する。
【０２２９】
以上の処理により、暗号化されたオーディオデータトランスポートストリームは、フラッシュメモリカード３１に格納されたことになるが、この暗号化を解除するためのFileKeyは、以下の処理により、プロテクト領域に格納される。
入力経路RT2,RT3の場合は、一個のAOBの符号化が開始される度に、CPU２８は異なるFileKeyを生成して、スクランブル部２６に設定し、そのFileKeyでスクランブル部２６に暗号化を行わせると共に、それらのFileKeyをプロテクト領域に存在する暗号鍵格納ファイルのFileKey Entry以降に格納する。
【０２３０】
一方入力経路RT1の場合は、AOBファイル、TKMGを格納したファイル、PLMGを格納したファイル、AOB毎の異なるFileKeyを格納した暗号鍵格納ファイルは、電子音楽配信のプロバイダより、送信される。CPU２８は、それらを受信して、AOBファイル、TKMGを格納したファイル、PLMGを格納したファイルをユーザデータ領域に書き込み、AOB毎の異なるFileKeyを格納した暗号鍵格納ファイルをプロテクト領域に書き込む。
【０２３１】
以上のように本実施形態によれば、AOBを格納したファイルは、それぞれ異なる暗号鍵にて暗号化されているので、1つのファイルを暗号化に用いられた暗号鍵が解読され、暴露されたとしても、その解読によって復号できるAOBは、1つのファイルに格納されているAOBだけであり、他のファイルに格納されたAOBには何の影響も及ぼさない。暗号鍵が暴露された場合の損失を最小限に抑える事ができる。
【０２３２】
なお、上記実施形態は現状において最善の効果が期待できるシステム例として説明したに過ぎない。本発明は、その要旨を逸脱しない範囲で実施変更することができる。具体的には、以下の（ａ）〜（ｆ）に示すような変更実施が可能である。
（ａ）本実施の形態では、記録媒体を半導体メモリ（フラッシュメモリカード）として説明を行ったが、これに限られるものではなく、DVD-RAMなどの光ディスクやハードディスクなどに置き換えることができる。
【０２３３】
（ｂ）本実施の形態では、音楽データとしてAACを使用したが、これに限られるものではなく、MP3（MPEG 1 Audio Layer 3）、Dolby-AC3、DTS（Digital Theater System）などであってもよい。
（ｃ）TKMGを格納したファイル、PLMGを格納したファイルのそのものを電子音楽配信にて配信するのではなく、TKMG,PLMGの元となる情報を、AOBファイル、AOB毎の異なる暗号鍵を格納した暗号鍵格納ファイルと共に配信し、記録装置において、このTKMG,PLMGの元となる情報を加工することによりTKMG,PLMGを得て、フラッシュメモリカードに記録しても良い。
【０２３４】
（ｄ）説明の便宜上、記録装置、再生装置をそれぞれ別装置としたが、携帯型再生装置に記録装置の機能を具備してもよいし、パソコン型の記録装置に再生装置の機能を具備させてもよい。また、これら携帯型再生装置、パソコン型記録装置以外にも、ネットワークからコンテンツをダウンロードすることができる通信機器に、これら再生装置、記録装置の機能を具備させてもよい。例えば、インタネットのアクセスが可能な携帯型電話機に、第１実施形態に示した再生装置、記録装置の機能を具備させ、携帯型電話機が無線ネットワークを介してダウンロードしたコンテンツを、第１実施形態に示したように、フラッシュメモリカード３１に格納しても良い。更に、本実施形態ではインターネットとの接続のために記録装置は、モデム装置２７を有していたが、これに替えて、ISDN回線との接続を行うためのターミナルアダプタ等を具備していてもよい。
【０２３５】
（ｅ）図５５〜図５８、図６０、図６３〜図６５、図６８のフローチャートを参照して説明した手順等を実行形式プログラムにより実現し、これを記録媒体に記録して流通・販売の対象にしても良い。このような記録媒体には、ICカードや光ディスク、フレキシブルディスク等があるが、これらに記録された機械語プログラムは汎用コンピュータにインストールされることにより利用に供される。この汎用コンピュータは、インストールした実行形式プログラムを逐次実行して、本実施形態に示した再生装置、記録装置の機能を実現するのである。
【０２３６】
（ｆ）本実施形態においてフラッシュメモリカード３１に複数のAOBと、複数のFileKeyとを格納させたが、フラッシュメモリカード３１に1つのAOBと、1つのFileKeyとを格納させてよい。また、AOBの暗号化を行わず、AAC方式のAOBをフラッシュメモリカード３１に格納させてもよい。
（第２実施形態）
第２実施形態は、第１実施形態に示したAOBファイルと共に、これらと共に表示すべき静止画をどのように格納するかという改良に関する。
【０２３７】
{69-1} 第２実施形態におけるフラッシュメモリカードの階層構造
図６９は、本実施形態に係るフラッシュメモリカード３１の階層構造を示す図である。第１実施形態の階層構造と異なるのは、第２実施形態では、プレゼンテーションデータにPOB群が新たに追加されており、ナビゲーションデータにPOBManagerが新たに追加されている点である。これらPOB群が、JPEG（Joint Photographic Experts Group）形式の静止画データであり、PlayListManager及びTrackManagerにより参照される。POBManagerは、これらPOBがPlayListManager及びTrackManagerによりどのように参照されるかが記述されている管理情報である。
【０２３８】
{69-1_70A-1}ファイルシステム層におけるユーザデータ領域の構成
新規な情報要素がプレゼンテーションデータ及びナビゲーションデータに追加されたので、ファイルシステム層におけるユーザデータ領域及びプロテクト領域の内部構成は、図７０（ａ）、（ｂ）のように改変されている。本図と、図８（ａ）に示した第１実施形態のユーザデータ領域とが異なるのは、POBXXX.JPG、POBXXX.SP1といったファイルが追加されており、POB000.POMというファイルが追加されている点である。
【０２３９】
POBXXX.JPG、POBXXX.SP1は、図６９に示したPOB群に対応するものであり、POB000.POMは、POBManagerに対応するものである。POBXXX.JPGと、POBXXX.SP1の違いは、著作権の有無の相違である。前者は、単にJPEG方式の静止画データを収録したファイルであるのに対して、後者は、静止画の著作権を保護するため、暗号化されている点である(その拡張子のSP1は"Secure Picture"の略であり、著作権保護の必要性があることはこれからも明らかである。)。ユーザが個人的に撮影した家族写真や記念写真等の静止画データは、専ら個人的な楽しみのもとでフラッシュメモリカードに記録するものであり、著作権の保護に神経を尖らせる必要はないので前者の形態でフラッシュメモリカードに格納しておけばよいが、電子音楽配信により配信されたアーティストの写真やイラストは、音楽コンテンツ同様、アーティストにより創作された創作物であり、ユーザがコピーすることにより、その著作権が侵害される恐れがあるので、後者の形態でフラッシュメモリカードに格納される。図中のPOBXXX.SP1及びPOBXXX.JPGに付されている001,002,003といった数値は、POBのそれぞれに割り当てられたPOB番号であり、複数のPOBはこれらPOB番号により一意に特定される。
【０２４０】
{69-2_70B-1}ファイルシステム層におけるユーザデータ領域の構成
図７０（ｂ）は、第２実施形態におけるプロテクト領域の構成を示す図である。プロテクト領域には、図８（ｂ）に示したプロテクト領域の構成と比較して、POBSP1.keyという暗号鍵格納ファイルが新規に追加されている。これは、図７０（ａ）におけるPOBXXX.SP1の暗号化を解除するためのFilekeyを格納したファイルであり、POBXXX.SP1を読み出す場合、このファイルからFilekeyを取り出さねばならない。
【０２４１】
電子音楽配信において音楽会社のサーバコンピュータは、この図７０（ａ）、（ｂ）に示すSD_Audioディレクトリを保持しており、当該音楽コンテンツの購入要求が消費者から発せられれば、このSD_Audioディレクトリを圧縮し、暗号化した後、購入要求を発した消費者にSD_Audioディレクトリを送信する。消費者が所有するコンピュータがこのSD_Audioディレクトリを受信すると、このディレクトリの暗号化を解除すると共に、伸長を行い、SD_Audioディレクトリを得る。尚、トラック(AOB)と、このトラックに対応する静止画(POB)とを音楽会社のサーバコンピュータからダウンロードし、消費者が所有するコンピュータが、フラッシュメモリカード３１においてこの図７０（ａ）、（ｂ）に示すSD_Audioディレクトリを作成しても良い。
【０２４２】
{69-3_71A,B,C-1} POBXXX.JPG、POBXXX.SP1の内部構成
続いて、POBXXX.JPG、POBXXX.SP1の内部構成について説明する。図７１（ａ）は、POBXXX.JPGの内部構成を示す図である。本図においてPOBXXX.JPGは、暗号化されていない静止画データを含んでおり、通常のJPEGファイルと同じファイル構成を有する。
【０２４３】
図７１（ｂ）は、POBXXX.SP1の内部構成を示す図である。本図に示すように、POBXXX.SP1はPOB_Header(POB_H)と、暗号化されたJPEG方式の静止画データとからなることがわかる。
破線の引き出し線hp1に、POB_Hの内部構成を示す。本図に示すように、POB_Hは、POBファイルの識別番号を示し、２バイト長の値"FFE0"に設定されるPOB_IDと、1バイト長の予約領域と、POBXXX.SP1に暗号化された実体部が存在するか、存在しないかを示す1バイト長のPOB_ATRと、POBのデータ長を示す4バイト長のPOB_SZとからなる。
【０２４４】
このPOBXXX.SP1には暗号化された実体部が存在するので、POB_ATRは『実体有り』を示す"0"に設定されているが、POBXXX.SP1に暗号化された実体部が存在せず、代わりに静止画データを格納しているファイルについてのファイルパスを格納しているものがある。図７１（ｃ）は、暗号化された実体部の代わりにファイルパスを格納したPOBファイルの一例を示す図である。『\DCIM\Ctg_001\photo001.JPG』の『photo001.JPG』は、デジタルスチルカメラにより撮影された静止画データを収録したファイルであり、そのファイルについてのファイルパスを示す。POBファイル内にこのようなディレクトリパス、ファイル名が指定されている場合、POBファイルにおけるこのような記載内容により、『\DCIM\Ctg_001\photo001.JPG』の『photo001.JPG』に収録されている静止画データは間接的に参照されることになる。このPOBXXX.SP1において、POBManagerにおけるPOB_ATRは『実体無し』を示す"1"に設定される。
【０２４５】
例えばデジタルスチルカメラにより撮影された静止画データを、特有のファイルに収録すること、当該ファイルを特有のディレクトリに格納することを、デジタルスチルカメラ専用のデバイスドライバがフラッシュメモリカードに要求している場合であっても(図７１（ｃ）の一例では、デジタルスチルカメラ専用のデバイスドライバは、\DCIM\Ctg_001\photo001.JPGに格納することを要求している)、図７１（ｃ）におけるPOBファイルは、当該参照先ファイルパスを介して、静止画データを収録したJPGファイルを指定するので、デジタルスチルカメラにより撮影された静止画データを、特有ファイル、特有ディレクトリに格納しつつも、そのような静止画を音楽コンテンツの再生と共に表示させることができる。
【０２４６】
以上で第２実施形態におけるプレゼンテーションデータについての説明を終える。
{72-1} PlayListManager及びTrackManagerについて
プレゼンテーションデータにおけるPOBXXX.JPG及びPOBXXX.SP1は、第１実施形態に示したトラックの再生と同期して表示される。トラックとの同期表示を実現するため第２実施形態におけるPlayListManager及びTrackManagerは、図７２に示す構成を有する。図７２は、第２実施形態におけるPlayListManager、TrackManagerの詳細構成を示す図である。本図と図１７に示した第１実施形態のPlayListManager、TrackManagerの構成とが異なるのは、図１７において明らかにされていなかったDefault Playlist General Infomation(DPLGI)、Playlist General Infomation(PLGI)の内部構成が明らかにされており、TKGIの内部構成に、TKI_POB_ATRと、20個のTKI_POB_SRPとが新規に設けられている点である。
【０２４７】
{72-2} DPLGIについて
デフォルトプレイリスト全体情報(DPLGI)は、破線の引き出し線h61に示すように、DPLIを一意に識別できるIDが記述されるDPLI_IDフィールドと、DPLIから参照されるトラック数が記述されるDPLI_TK_Nsフィールドと、デフォルトプレイリストから参照されるすべてのトラックの再生時間の総和がミリ秒の単位で記述されるDPLI_PB_TMフィールドと、DPLI_POB_ATRフィールドと、60個のDPLI_POB_SRPフィールドとからなる。
【０２４８】
{72-3} PLGIについて
プレイリスト全体情報(PLGI)は、破線の引き出し線h62に示すように、PLIを一意に識別できるIDが記述されるPLI_IDフィールドと、PLIから参照されるトラック数が記述でき、最大９９個のトラックを参照することができるPLI_TK_Nsフィールドと、ミリ秒の単位でプレイリストから参照されるすべてのトラックの再生時間の総和が記述されるPLI_PB_TMフィールドと、PLI_POB_ATRフィールドと、20個のPLI_POB_SRPフィールドとからなる。
【０２４９】
{72-4_73} 第２実施形態における追加改良点のまとめ
以上の説明からもわかるように、本実施形態においてTKGIには、TKI_POB_ATR、TKI_POB_SRPという2つの情報が追加されており、DPLGIにも、DPLI_POB_ATR−DPLI_POB_SRPという2つの情報、PLGIにも、PLI_POB_ATR−PLI_POB_SRPという2つの情報が追加されていることがわかる。TKI_POB_SRP、PLI_POB_SRP、DPLI_POB_SRPは何れも、共通の構成を有しておりPOBを指定することができる。図７３は、TKI_POB_SRP、PLI_POB_SRP、DPLI_POB_SRPにより、図７０に示したPOBファイルが指定されている状態を示す図である。以降、TKI_POB_ATR（DPLI_POB_ATR、PLI_POB_ATR）、TKI_POB_SRP（DPLI_POB_SRP、PLI_POB_SRP）のデータ構造について説明する。
【０２５０】
{74-1} TKI_POB_SRP
TKI_POB_SRPは、Default_Playlist情報、PlayList情報により指定された再生順序により再生が行われている時間帯のうち、特定のAOBが再生される再生期間に表示すべきPOBを指定するフィールドである。言い換えれば、TrackManagerはTKI_POB_SRPを設定することにより、トラック毎に表示すべきPOBを指定することができる。
【０２５１】
図７４は、TKI_POB_SRP、TKI_POB_ATRのデータ構造を示す図である。
本図においてTKI_POB_SRPは、ビット番号b25からビット番号b16までの『POB指定フィールド』と、ビット番号b11からビット番号b8までの『number of Pixel』フィールドと、ビット番号b7からビット番号b6までの『Huffman table』フィールドと、ビット番号b5からビット番号b4までの『Chominance sampling』フィールドと、ビット番号b3からビット番号b0迄を占める『Picture Coding Mode』フィールドと、ビット番号b12からビット番号b15、ビット番号b26からビット番号b31までの予約領域とからなる。
【０２５２】
『POB指定フィールド』は、このTKIに対応するAOBファイルが再生されている期間において、表示すべきPOBの番号（参照すべきPOBの番号）が1から999の範囲で記述されるフィールドである。このTKIに対応するAOBファイルが再生されている期間において、静止画を表示しない場合“0”が記述される。
『Picture Coding Mode』フィールドは、POB指定フィールドにて指定される静止画を表示する際、その静止画がどのような方式で符号化されているかを再生装置に通知するためのフィールドである。JPEG（Joint Photograph Expert Group）の場合、“0000b”の値が記述される。
【０２５３】
『Chominance sampling』フィールドは、POB指定フィールドで指定されている静止画を符号化した際、輝度成分、2つの色差成分のサンプリングがどのような比率で行われたかを示すフィールドである。輝度成分と、2つの色差成分との比率が4:2:2の比率である場合、00bitに設定され、4:2:0の比率である場合、01bitに設定される。
【０２５４】
『Huffman table』フィールドは、POB指定フィールドで指定されている静止画を表示する際、典型的なハフマンテーブルを用いるか否かを示すフィールドである。ハフマンテーブルを用いる場合、00bitに設定される。
『number of Pixel』フィールドは、POB指定フィールドにて指定された静止画データのイメージサイズが記述されるフィールドである。当該静止画データのイメージサイズが96×96の場合“0000b”の値が記述される。640×480の場合は、“0001b”、160×120〜1800×1200のイメージサイズであって、640×480以外のイメージサイズであれば“0010b”の値が記述される。
【０２５５】
TKGIは、以上のような構成を有するTKI_POB_SRPを20個有しているので、トラックの再生時に最大20枚の静止画を再生させることができる。尚、1つのトラックが複数のTKIから構成される場合、TKI_POB_SRPは先頭のTKIのみ有効となる。
{74-2} TKI_POB_ATR
『TKI_POB_ATR』は、TKGIにおける20個のTKI_POB_SRPにて指定されたPOBを、どのような態様で表示させるかを指定するために設けられている。TKI_POB_ATRは、ビット番号b0からビット番号b1迄を占めるDisplay order modeフィールドと、ビット番号b2からビット番号b3迄を占めるDisplay Timing modeフィールドとからなる。
【０２５６】
『Display order mode』フィールドは、TKGI内の20個のTKI_POB_SRPにて指定されているPOBをどのような順序で表示させるかが設定される。AOBの再生時間において、POBをどのように再生させるかには、3つの態様がある。1つ目の態様は、TKGI内の最大20個のTKI_POB_SRPにて指定されているPOBをTKGI内のTKI_POB_SRPの順序に従って表示する場合であり、これをシーケンシャルモードという。2つ目の態様は、TKGI内の20個のTKI_POB_SRPにて指定されているPOBを無作為に選んで再生するモードであり、これをランダムモードという。3つ目の態様は、重複を避けるようにTKGI内の20個のTKI_POB_SRPにて指定されているPOBを無作為に選んで再生するモードであり、シャッフルモードという。Display order modeフィールドは、シーケンシャルモードに設定される場合“00b”の値が設定される。一方ランダムモードに設定される場合“01b”、シャフルモードに設定される場合“10b”の値に記述される。
【０２５７】
『Display Timing mode』フィールドは、TKGI内の最大20個のTKI_POB_SRPにて指定されているPOBの表示と、TKIに対応づけられているAOBファイルの再生とを同期させるか否かが設定されるフィールドである。映像と音声とが同期しているモードをスライドショーモードといい、映像表示のみをスキップさせることはできない。一方、映像と音声とが同期していないモードをブラウザブルモードといい、映像表示のみをスキップさせることができる。
【０２５８】
以上のようにTKGIは、自身に対応するAOBファイルが再生されている期間において、どのPOBを表示させるか、それらPOBの表示をどのような順序で行うか、POBの表示と、TKIに対応づけられているAOBファイルの再生とを同期させるか否かが設定される。
{74-3_75} TKI#1〜TKI#3に含まれるTKI_POB_SRPの設定例
図７５は、TrackManagerに含まれるTKI#1〜TKI#3についてのTKI_POB_SRPの設定例を示す図である。第１段目は、TrackManagerを示し、第２段目は、9つのPOBファイルを示す。第１段目におけるTrackManagerは、8つのTKIを含み、矢印は、それらTKI内のTKI_POB_SRPがどのPOBファイルを参照しているかを示す。矢印に示される参照関係によると、TKI#1は3つのTKI_POB_SRPを含み、それら3つのTKI_POB_SRPはPOB001〜POB003を指定している。またTKI#2は3つのTKI_POB_SRPを含み、それら3つのTKI_POB_SRPはPOB004〜POB006を、TKI#3は3つのTKI_POB_SRPを含み、それら3つのTKI_POB_SRPはPOB007〜POB009を指定していることがわかる。
【０２５９】
本実施形態においてPOB001〜009には、無地の背景に、歌詞を示す文字列を配したJPEG画像データを用いるものとする。ここで歌詞の記述に用いられている文字列は、より歌詞のイメージに合うようなフォントにて描かれており、輪郭強調や装飾等が施されている。
図７５における最下段に、各POBの内容を示す。POB001〜POB003の内容は、TrackAの歌詞カード であり、POB004〜POB006の内容はTrackBの歌詞カード、POB007〜POB009の内容は、TrackCの歌詞カードである。これらは何れも各トラックが再生されている期間に再生しないと意味がないので、TKIに含まれるTKI_POB_SRPにより、各トラックが再生されている期間において再生されるよう設定されている。
【０２６０】
各トラックが再生されている期間は、第１実施形態において図１６に示した通りである。即ち、TKI#1に対応するAOB001.SA1の再生時間は6.1分、TKI#2に対応するAOB002.SA1の再生時間は3.3分、TKI#3に対応するAOB003.SA1の再生時間は5.5分なので、これらの期間において、TKIに設定されているTKI_POB_SRPの設定は有効となり、再生装置は、その有効なTKI_POB_SRPに従って、POBを表示することができる。
【０２６１】
TKI#1に対応するAOB001.SA1の再生時間は6.1分であり、この期間にPOB001〜POB003を均等に表示させるとすれば、一枚当りの表示時間は2.03分 ＝(6.1分/3)となる。TKI#2に対応するAOB002.SA1の再生時間は3.3分であり、再生装置はPOB004〜POB006の一枚当りの表示時間は1.1分 ＝(3.3分/3)、TKI#3に対応するAOB003.SA1の再生時間は5.5分でありPOB007〜POB009の一枚当りの表示時間は1.83分 ＝(5.5分/3)となる。
【０２６２】
{74-4_76} TKI#4〜TKI#8に含まれるTKI_POB_SRPの設定例
図７６は、TrackManagerに含まれるTKI#4〜TKI#8に含まれるTKI_POB_SRPの設定例を示す図である。第１段目は、TrackManagerを示し、第２段目は、10個のPOBファイルを示す。矢印に示される参照関係によると、TKI#4は図７６における7本の矢印に示される7つのTKI_POB_SRPを含み、それら7つのTKI_POB_SRPはそれぞれPOB010〜POB016を指定している。またTKI#8は3つのTKI_POB_SRPを含み、それらTKI_POB_SRPはPOB017〜POB019を指定していることがわかる。本実施形態においてPOB010〜019も、POB001〜009同様、無地の背景に、歌詞を示す文字列を配したJPEG画像データを用いるものとする。尚、TKI#4のみにTKI_POB_SRPが設定され、TKI#5〜#7にTKI_POB_SRPが設定されていないのは、上述したように1つのトラックが複数のTKIから構成される場合、TKI_POB_SRPは先頭のTKIのみ有効となるからである。
【０２６３】
POB010〜POB016の内容は、第１実施形態の図１６に示したTrackDの歌詞カード、POB017〜POB019の内容はTrackEの歌詞カードである。TKI#4〜TKI#7に対応するAOB004.SA1〜AOB007.SA1の再生時間は30.6分であり、POB010〜POB016の一枚当りの表示時間は4.37分 (＝30.6分/7)となり、これらの期間において、各POBを均等に表示させることができる。TKI#8に対応するAOB008.SA1の再生時間は7.0分であり、POB017〜POB019の一枚当りの表示時間は2.33分 (＝7.0分/3)となる。
【０２６４】
{77-1} DPLGIに含まれるDPLI_POB_SRP及びDPLI_POB_ATR
TKI_POB_SRPがトラック毎に、表示すべきPOBを指定することができるのに対して、DPLGIにおけるDPLI_POB_SRPは、Default_Playlist情報により指定された順序に従って、複数AOBが再生される時間帯において表示すべきPOBを指定するものである。図７７はDPLGIに含まれているDPLI_POB_SRP及びDPLI_POB_ATRを示す図である。DPLGIに含まれるDPLI_POB_SRP及びDPLI_POB_ATRもTKI_POB_SRP及びTKI_POB_ATRと同一のデータ構造を有していることは、この図７７からも明らかである。Default_Playlist情報は、複数AOBファイルの再生順序を規定するものなので、図７７におけるDPLI_POB_SRP及びDPLI_POB_ATRは、Default_Playlist情報により再生順序が規定されている複数のAOBファイルが再生されている期間において、どのPOBを表示させるか、それらPOBの表示をどのような順序で行うか、POBの表示と、TKIに対応づけられているAOBファイルの再生とを同期させるか否かを設定することができる。
【０２６５】
{77-2_78} 20個のDPLI_POB_SRPの設定例
図７８は、Default_Playlist情報に含まれる20個のDPLI_POB_SRPの設定例を示す図である。第１段目は、Default_Playlist情報を示し、それに含まれる枠はDPLGIと、20個のDPLI_POB_SRPとを示す。第２段目は、POB020〜POB039からなる20個のPOBファイルを示す。矢印に示される参照関係によると、20個のDPLI_POB_SRPはそれぞれPOB020〜POB039を指定している。
【０２６６】
POB020は、TrackA〜TrackEからなる音楽アルバムを記録したパッケージソフトのジャケットに使用されているイラストであり、POB021は、当該音楽アルバムをプロデュースした製作会社のロゴマーク、POB022〜POB025は、アーティストの肖像、POB026〜POB031は、プロモーションビデオのワンシーンであり、POB032〜POB039は、TrackA〜TrackEがコンサートで演奏された際に撮影された写真である。Default_Playlist情報におけるDPLI_POB_SRPは、音楽コンテンツを創作したものにより定義されるものなので、音楽コンテンツのトラックのイメージや、アーティストのタレントイメージにあったPOBを表示するよう指定されている。
【０２６７】
Default_Playlist情報にて再生順序が指定されているAOBファイルが再生されている期間において、このDPLGIに含まれるDPLI_POB_SRPにて指定されるPOBファイルが表示されることになる。例えば、図４０の一例では、Default_Playlist情報により8つのTKIを介して、TrackA〜TrackEという5つのトラックの再生順序が指定されていた。一方、図７８の一例においてDefault_Playlist情報に含まれるDPLI_POB_SRPにより、20個のPOBファイルが指定されているとすると、52.5分という再生時間においてこのDefault_Playlist情報によるDPLI_POB_SRPの指定は有効となる。更に、この52.5分という再生時間を、POB020〜POB039に均等に割り当てるとすると、一枚当りの表示時間は2.625分 ＝(52.5分/20)となる。
【０２６８】
{77-3_79} 再生時間の経過に伴う前景画−背景画の遷移
図７９は、Default_Playlist情報に含まれるDPLI_POB_SRPにて指定されたPOBを背景画とし、TrackManagerに含まれるTKI_POB_SRPにて指定されるPOBを前景画とした場合、これらがどのように合成されるかを示すタイミングチャートである。図７９の第１段目は、図７８の第２段目と同一のPOBを示すものであり、図７９の第２段目は、図７５、図７６の第２段目と同一のPOBを示すものである。本図の横方向は、1分を単位時間とした時間軸である。また本図のPOBの横幅は、各POBの再生がどれだけの間継続しているかを分単位で示す。
【０２６９】
本図の時間軸を参照すると、再生開始から6.1分までの期間において、POB001〜POB003(TrackAの歌詞カード)が前景画として、POB020、POB021(ジャケットイラストと製作会社のロゴマーク)、POB022(アーティストの肖像)が背景画として表示されることになる。
再生開始6.1分経過後から14.9(=6.1+3.3+5.5)分が経過するまでの期間において、POB004〜POB009(TrackB、TrackCの歌詞カード)が前景画として、POB022〜POB025(アーティストの肖像)が背景画として表示されることになる。
【０２７０】
再生開始14.9分経過後においてPOB010〜POB011(TrackDの歌詞カード)が前景画として、POB025(アーティストの肖像)、POB026〜POB028(プロモーションビデオのワンシーン)が背景画として表示される。
{77-4_80} 本タイミングチャートによれば、Default_Playlist情報の再生開始から6.1分経過後に、POB004を前景画(TrackBの歌詞)とし、POB022(アーティストの写真)を背景画とした合成映像が表示されることになる。図８０は、Default_Playlist情報の再生開始から6分経過後に、前景画、背景画がどのように合成されるかを示す図である。
【０２７１】
{77-5_81}またDefault_Playlist情報の再生開始から16分経過後には、POB010(TrackDの歌詞)を前景画とし、POB026(プロモーションビデオのワンシーン)を背景画とした合成映像が表示されることになる。図８１は、Default_Playlist情報の再生開始から16分経過後に、前景画、背景画がどのように合成されるかを示す図である。
【０２７２】
上記のように、Default_Playlist情報内のDPLI_POB_SRPにて指定されたPOBファイルと、TrackManagerにおけるTKI_POB_SRPにて指定されたPOBファイルとをそれぞれ前景画、背景画として合成して表示させれば、そのトラックについての歌詞ともに、そのトラックを作詞・作曲したアーティストの肖像や、プロモーションビデオ、コンサートシーン等を背景画として表示させることができる。また、どの時間帯にどのPOBファイルを表示させるかは、TrackManager、Default_Playlist情報におけるTKI_POB_SRP、DPLI_POB_SRPを書き換えることにより、容易に変更することができる
{82-1} PLGIに含まれるPLI_POB_SRP及びPLI_POB_ATR
PLGIに含まれているPLI_POB_SRP及びPLI_POB_ATRも、DPLGIに含まれるDPLI_POB_SRP及びDPLI_POB_ATR、TKIに含まれるTKI_POB_SRP及びTKI_POB_ATRと同一のデータ構造を有している。図８２はPLGIに含まれているPLI_POB_SRP及びPLI_POB_ATRを示す図である。PlayList情報は、Default_Playlist情報と異なり、ユーザが独自に定めた再生順序を規定するものなので、PLI_POB_SRP及びPLI_POB_ATRは、PlayList情報により再生順序が規定されている複数のAOBファイルが再生されている期間において、どのPOBを表示させるか、それらPOBの表示をどのような順序で行うか、POBの表示と、TKIに対応づけられているAOBファイルの再生とを同期させるか否かをユーザが自分の考えで設定することができる（尚、Default_Playlist情報のDPLI_POB_SRPを音楽会社が設定したというのは一例に過ぎず、Default_Playlist情報におけるDPLI_POB_SRPの設定もユーザが自由に設定しても良い。）。
【０２７３】
{82-2_83} PlayList情報に含まれるPLI_POB_SRPの設定例
続いて、PlayList情報に含まれるPLI_POB_SRPの設定例について説明する。
図８３は、PlayList情報に含まれる20個のPLI_POB_SRPの設定例を示す図である。第１段目は、PlayList情報を示し、それに含まれる枠はPLGIと、20個のPLI_POB_SRPとを示す。第２段目は、POB040〜POB059からなる20個のPOBファイルを示す。矢印に示される参照関係によると、20個のPLI_POB_SRPはそれぞPOB040〜POB059を指定している。
【０２７４】
POB020〜POB039が何れも音楽コンテンツの製作者が作成した静止画データであるのに対して、POB040〜POB059は何れもユーザの個人的な写真である。即ち、POB040は、ユーザの家族の写真であり、POB041は、ユーザの卒業写真、POB042〜POB045は、ユーザのペットの写真、POB046〜POB051は、ヨーロッパ旅行時の記念写真であり、POB052〜POB059は、アメリカ旅行時における記念写真である。尚、説明の簡略化を図るため、このPlayList情報にて再生順序が指定されるAOBファイルの総再生時間と、このPlayList情報により表示するよう指定されるPOBの数とは、Default_Playlist情報と同一とする。そうすると、このPlayList情報により指定されるTrackA〜TrackEの総再生時間は52.5分となり、POB040〜POB059をこの再生時間において、均等に表示させる場合は、一枚当りの表示時間は2.625分 ＝(52.5分/20)となる。
【０２７５】
{82-3_84} 再生時間の経過に伴う前景画−背景画の遷移
図８４は、Playlist情報に含まれるPLI_POB_SRPにて指定されたPOBを背景画とし、TrackManagerに含まれるTKI_POB_SRPにて指定されるPOBを前景画とした場合、これらがどのように合成されるかを示すタイミングチャートである。図８４の第１段目は、図８３の第２段目と同一のPOBを示すものであり、図８４の第２段目は、図７５、図７６の第２段目と同一のPOBを示すものである。本図の横方向は、1分を単位時間とした時間軸である。また本図のPOBの横幅は、各POBの再生がどれだけの間継続しているかを分単位で示す。
【０２７６】
本図において再生開始直後から6.1分が経過するまでの期間において、POB001〜POB003(TrackAの歌詞カード)が前景画として、POB040、POB041(家族写真と卒業写真)、POB042が背景画として表示されることになる。
6.1分経過後から14.9分が経過するまでの期間において、POB004〜POB009(TrackB、TrackCの歌詞カード)が前景画として、POB042〜POB045(ペットの写真)が背景画として表示されることなる。14.9分以降には、POB010〜POB011(TrackDの歌詞カード)が前景画として、POB045,POB046〜POB048(ヨーロッパ旅行時における記念写真)が背景画として表示されることになる。
【０２７７】
Default_Playlist情報に指定されていたPOBは、音楽コンテンツの製作会社が考えたものであり、音楽コンテンツのトラックのイメージや、アーティストのタレントイメージにあったPOBが指定されているのに対して、PlayList情報に指定されていたPOBは、ユーザが個人的に選んだものであり、ユーザ個人の思い入れが強いものとなっている。
【０２７８】
{82-4_85} 図８４によると、Playlist情報の再生開始から6.1分経過後に、POB004を前景画(TrackBの歌詞)とし、POB042(ペットの写真)を背景画とした合成映像が表示されることになる。図８５は、Playlist情報の再生開始から6.1分経過後に、前景画、背景画がどのように合成されるかを示す図である。
{82-5_86} Playlist情報の再生開始から16分経過後には、POB010(TrackDの歌詞)を前景画とし、POB046(ヨーロッパ旅行の写真)を背景画とした合成映像が表示されることになる。図８６は、Playlist情報の再生開始から16分経過後に、前景画、背景画がどのように合成されるかを示す図である。これらの合成画像における歌詞内容は、図８０、図８１と同一であるが、背景画が異なるため、見た印象は、図８０、図８１に示した合成画像と大きく異なっていることがわかる。
【０２７９】
上記のように、ユーザが独自に定義したPlayList情報内のPLI_POB_SRPに、Default_Playlist情報にて指定されたPOBファイルとは異なるPOBファイルを指定させることにより、ユーザは、自分の思い出のトラックの再生時に、その思い出にまつわる写真等を表示させることができる。
{82-6_87} Default_Playlist情報のDPLI_POB_SRPにおいて、共通のPOBを指定させた設定例
図７８、図７９、図８２、図８３の一例では、Default_Playlist情報に含まれる全てのDPLI_POB_SRPにそれぞれ異なるPOBファイルを指定させたが、Default_Playlist情報に含まれるDPLI_POB_SRPのうち、何れかのものに重複したPOBファイルを指定させれば、複数のトラックが再生されている期間において、共通のPOBファイルを表示させることにより、POBファイルの個数を少なくし、タイトル製作者の手間を削減することができる。図８７は、Default_Playlist情報における複数のDPLI_POB_SRPのうち、DPLI_POB_SRPに共通のPOBファイルを指定させることにより、POBファイルの数の削減を図った例である。本図において、DPLI_POB_SRP#1と、DPLI_POB_SRP#4とはPOB020を指定しており、DPLI_POB_SRP#2と、DPLI_POB_SRP#5とはPOB021を指定していることがわかる。
【０２８０】
{82-7_88} 再生時間の経過に伴う前景画−背景画の遷移
図８８は、Default_Playlist情報に含まれるDPLI_POB_SRPにて指定されたPOBを背景画とし、TrackManagerに含まれるTKI_POB_SRPにて指定されるPOBを前景画とした場合、これらがどのように合成されるかを示すタイミングチャートである。本タイミングチャートにおいて再生開始直後、7.875分経過後、15.75分経過後とにおいて、パッケージソフトのジャケットイラストを示すPOB020は繰り返し三回表示されていることがわかる。また再生開始から2.625分経過後、10.5分経過後、18.375分経過後において、製作会社のロゴを示すPOB021は繰り返し三回表示されていることがわかる。図８７のようにDPLI_POB_SRPを指定した場合、同一のPOBが繰り返し表示されるので、ジャケットイラストやロゴマーク等、POBの中に繰り返し表示すべきものが存在する場合に好適となる。
【０２８１】
以上長文となったが、TKGI、DPLGI、PLGIについての説明を終える。
{69-4_89} POBMGについて
第２実施形態において、ナビゲーションデータに追加された新規の情報要素であるPOBManagerについて説明する。図８９は、POBMGの内部構成を示す図である。本図に示すようにPOBMGは、POB管理情報(POBMGI)と、POB Count Information(POBCI)#1・・・・・・#nとからなる。
【０２８２】
{69-4_89-1} POBMGIについて
POB管理情報(POBMGI)は、破線の引き出し線に示すように、0バイト目から1バイト目迄を占めるPOBMGI識別情報と、2バイト目から3バイト目迄を占める予約フィールド(reserved)と、4バイト目から5バイト目迄を占めるPOB_Nsフィールドと、6バイト目から7バイト目までを占める予約フィールド(reserved)とからなる。
【０２８３】
POBMGI識別情報フィールドには、POBMGIを一意に識別できるIDが記述され（ISO646のキャラクタセットコード"A6"である。）、POB_Nsフィールドには、"0"から"999"までのPOBの数が記述される。以上で、POB管理情報(POBMGI)の説明を終わる。
{69-4_89-2} POBCIについて
次に、POB Count Information (POBCI)の説明を行う。POB Count Information (POBCI)は、POBのそれぞれに対応づけて設けられている管理情報である。そのビット構成は、破線の引き出し線に示す通りである。即ち、ビット番号b0からビット番号b9までを占めているPOB_RCNフィールドと、ビット番号b10からビット番号b13までを占めている予約領域フィールドと、ビット番号b14からビット番号b15迄を占めているdata existenceフィールドとからなる。
【０２８４】
{69-4_89-3} POB_RCNについて
『POB_RCN』フィールドは、POBCIにより対応づけられているPOBの表示がDPLGI、PLGI、TKGIにより指定されているか否かを示し、指定されている場合、その指定回数、即ち、表示が指定されている回数が1から999の範囲で記述される。第１実施形態で述べたように、TKIは削除可能であり、Default_Playlist情報、PlayList情報における再生順序の指定も自由に削除することができる。POB_refernce_countにおけるPOB指定数は、それに対応するPOBを指定していたTKIが削除された場合、削除されたTKI数だけデクリメントされる。またDefault_Playlist情報、PlayList情報が削除された場合も、削除されたTKI数だけデクリメントされる。DPLGI、PLGI、TKGIにより表示が指定されていない場合POB_refernce_countは0となる。POB_refernce_countが0となったPOBは何れのTKI、PlayList情報からも参照されないPOBであるので、再生装置は、TKI、PlayList情報の削除が行われる度に、このrefernce_count_numberが0となったPOBを検出し、refernce_count_numberが0となったPOBを収録しているPOBファイルを削除することにより、フラッシュメモリカードにおいて格納される静止画データ数を削減することができる。複数のPOBのうち、特定のPOBが特定のトラックのみと密接な関係を有しているものであり、そのトラックと同期して再生されないのではそのPOBをフラッシュメモリカードに格納しておく意味が存在しない場合（例えば、フラッシュメモリカードに格納されているトラックの歌詞を示す静止画が静止画データとして格納されているようなケースがこれに該当する）、refernce_count_numberに基づいて、削除を行うことにより、フラッシュメモリカードに余分なPOBを格納しておくという無駄がなくなる。尚、TKIが削除されるケース以外にも、DPLI_POB_SRP,PLI_POB_SRP,TKI_POB_SRPにて指定されているPOBが編集作業により削除された場合にも、同様のrefernce_count_numberのデクリメントを行っても良い。
【０２８５】
{69-4_89-4} data existenceについて
ビット番号b14からビット番号b15迄を占めているdata existenceフィールドには、このPOB番号に対応するPOBが存在するか否かが指定される。POB番号に対応するPOBが存在する場合、01bに設定され、POBが存在しない場合、00bが設定される。POBが存在すると指定されている場合、TKI、PlayList情報の削除が行われてたとえPOB_refernce_countが0になったとしても、当該POB_refernce_countに対応するPOBはフラッシュメモリカードに格納しておく価値があるとみなしてPOBの削除はなされない。TKI、PlayList情報により参照されているか否かに拘らず、POB単独でも保存価値がある場合、そのPOBに対応するdata existanceを1に設定し、TKI、PlayList情報により参照されていなければ、保存価値が無いようなPOBは、そのPOBに対応するdata existanceを0に設定することにより、保存価値のあるPOBは、フラッシュメモリカードに残しておくことができる。その一方、トラックと一体となって初めて保存価値があるようなPOBは、トラックの削除と共に削除することにより、フラッシュメモリカードの格納容量を有効利用することができる。
【０２８６】
以上で、POBManager(POBMG)の説明を終わる。
{69-5} TKIの編集時における更新
第１実施形態において述べた4つの編集ケース、一部のトラックが削除された場合(case1)、複数のトラックのうち、任意の2つを1つのトラックに統合する場合(case3)、1つのトラックを分割して、2つのトラックを得る場合(case4)、トラックの順番を入れ替えた場合(case5)において、TKI_POB_SRP及びDPLI_POB_SRPがどのように更新されるかについて説明する。
【０２８７】
トラックが削除された場合(case1)、第１実施形態に示したよう、そのTKIについてのTKI_BLK_ATRを『Unused』に設定すると共に、そのTKIにおけるTKI_POB_SRPを削除する。それと共に、そのTKI_POB_SRPにより指定されていたPOBに対応するPOBManagerにおけるPOB_refernce_countをデクリメントする。DPLGI、PLGIにおけるPLI_POB_SRP、DPLI_POB_SRPにて指定されていたPOBについては、その削除によっても、変化はない。
【０２８８】
DPL_TK_SRPにて指定されたトラックの順序が入れ代わった場合(case5)、トラックの順序が入れ代わるので、TKI_POB_SRPにて指定されたPOBの表示順序は入れ替え後の順位となる。
トラックの統合(case3)については、TKIにおけるTKI_POB_SRPも統合させるのが望ましい。何故なら、上述したように1つのトラックが複数のTKIから構成される場合、TKI_POB_SRPは先頭のTKIのみ有効となるので、トラックの統合操作により後半のTKIのTKI_POB_SRPにて指定されているPOBを、前半のTKIのTKI_POB_SRPに指定させる必要があるからである。
【０２８９】
また、トラックの分割時(case4)においては、TKIのTKI_BLK_ATRを変更し、TKTMSRT、BITを2つに分割する必要があるのは、第１実施形態に説明した通りであるが、それと同様に、TKGIにて指定されている複数のTKI_POB_SRPを2つに分割して、元のTKIと、分割により得られたTKIとに分配させてもよい。
{69-6}TKI_POB_SRP、DPLI_POB_SRP設定の応用例
以上の説明したTrackManager、PlayListManagerのデータ構造では、AOBファイルとPOBとの対応づけを、TKI_POB_SRP、DPLI_POB_SRP、PLI_POB_SRPの設定により自由に変化させることができるので、音楽コンテンツの提供者は、歌詞がないタイプ、歌詞があるタイプ、歌詞と背景画とがあるタイプ等、付随している静止画データの多少に応じて、価格が異なる複数の音楽コンテンツを消費者に販売することができる。
【０２９０】
歌詞がないタイプの購入を消費者が希望した場合、第１実施形態に示した8つのAOBファイルと、図７８に示したPOB020〜POB039をTKI#1〜TKI#8におけるTKI_POB_SRPに指定させたTrackManagerとを含むSD_Audioディレクトリを作成して、これを圧縮した後、消費者が所有する汎用パーソナルコンピュータに送信する。尚、トラック(AOB)と、このトラックに対応する静止画(POB)とを音楽会社のサーバコンピュータからダウンロードし、消費者が所有するコンピュータが、フラッシュメモリカード３１においてこの図７０（ａ）、（ｂ）に示すSD_Audioディレクトリを作成しても良い。
【０２９１】
歌詞があるタイプの購入を消費者が希望した場合、第１実施形態に示した8つのAOBファイルと、図７５、図７６に示した歌詞に対応するPOB001〜POB019をTKI#1〜TKI#8におけるTKI_POB_SRPに指定させたTrackManagerとを含むSD_Audioディレクトリを作成して、これを圧縮した後、消費者が所有する汎用パーソナルコンピュータに送信する。
【０２９２】
歌詞と背景画とがあるタイプの購入を消費者が希望した場合、第１実施形態に示した8つのAOBファイルと、歌詞に対応するPOB001〜POB019をTKI#1〜TKI#8におけるTKI_POB_SRPに指定させたTrackManagerと、図７８に示したPOB020〜POB039をDPLI_POB_SRPに指定させたPlayListManagerとを含むSD_Audioディレクトリを作成して、これを圧縮した後、消費者が所有する汎用パーソナルコンピュータに送信すればよい。
【０２９３】
本実施形態では、TKI_POB_SRP、DPLI_POB_SRP、PLI_POB_SRPの設定によりオーディオデータに任意の静止画データを付随させることができるので、付随する静止画データの多少に応じて、価格帯の異なる音楽コンテンツを簡易に作成することができる。
{90-1_91} 第２実施形態に係る再生装置について
続いて、第２実施形態に係る再生装置について説明する。第２実施形態に係る再生装置が第１実施形態のものと異なる点は、大きく3つある。そのうち第１の差違点は、第１実施形態における再生装置が携帯型であるのに対して、第２実施形態における再生装置が車載型である点である。図９０は、第２実施形態に係る再生装置がどのように用いられるかを示す図であり、図９１は、第２実施形態に係る再生装置本体のみの外観を示す図である。本図において、第２実施形態に係る再生装置が第１実施形態の再生装置と異なるのは、第２実施形態に係る再生装置は、図９０に示すように自動車の車内に設置されており、大型の液晶ディスプレィ５と、車載スピーカーとに接続されている点である。再生装置に接続されている液晶ディスプレィ５が大型なので、第２実施形態における再生装置は、上述した各種静止画データを好適に表示することができる。
【０２９４】
第２の差違点は、第２実施形態におけるデ・スクランブラ７は、オーディオデータの暗号化を解除する以外にもPOBの暗号化を解除する点である。即ち、POBファイルがPOBXXX.SP1であり、収録されているPOBが暗号化されている場合、デ・スクランブラ７には、プロテクト領域における暗号鍵格納ファイルPOBSP1.KEYのKey Entryに格納されているFilekeyが設定され、POBXXX.SP1における暗号化を解除する。 最後に、第３に異なるのは、第２実施形態におけるROM４に、POBを前景画又は背景画として表示する処理内容を記載したプログラムが格納されており、これに基づいて、CPU１０が画面表示を行う点である。
【０２９５】
{90-2_92_93_94}
続いて、第２実施形態に係る再生装置の内部構成について説明する。図９２に示した再生装置の内部構成が、第１実施形態と異なるのは、複数のVRAM６１が設けられている点である。
複数のVRAM６１は、それぞれが一枚のグラフィックスプレーン0に対応しているVRAMからなる。各グラフィックスプレーンのVRAMは、各画素毎に0%〜100%の透過率αが設定され、液晶ディスプレィ５に表示されるべき画像の画素値は以下の式により算出される。図９３（ａ）は、複数のVRAM６１に格納された静止画がどのように重ね合わせられるかを示す図である。
各画素の画素値 = グラフィックスプレーン0の画素値×(1-α) ＋ グラフィックスプレーン1の画素値×α
前景画側において歌詞を表す文字の部分は、透過率が0%に設定される。従って、グラフィックスプレーン1に記憶されている背景画は、一切画面上に現れない。前景画において無地の背景部分は、透過率が100%に設定される。従ってグラフィックスプレーン0における静止画の無地の部分にグラフィックスプレーン１に記憶されている背景画がはめ込まれることなる。このように透過率αを設定すれば、歌詞が記載された透明シートを背景画に被せたような、合成画像、即ち、図８０、図８１に示したような合成画像を得ることができる。
【０２９６】
尚、図９３（ａ）に示したような合成画像以外にも、例えば図９３（ｂ）に示すように、歌詞を下半分に配し、背景画に上半分に配した合成画像を表示しても良い。
{94-1} 前景画表示処理についてのフローチャート
図９４は、前景画表示処理についての処理手順を示すフローチャートである。Default_Playlist情報が指定されTKI#zに基づいた再生が開始されると、ステップＳ４０２において、CPU１０は当該TKIに含まれるTKGIに含まれるTKI_POB_SRPがPOBファイルを指定しているか否かを判定する。TKI_POB_SRPがPOBファイルを指定している場合、ステップＳ４０３においてCPU１０は、TKGIに含まれるTKI_POB_SRPが何枚のPOBファイルを指定しているかを計数する。ステップＳ４０４においてPOBファイルの枚数に基づいて、POBファイル一枚当たりの表示時間POB_timeを決定する。続いて、ステップＳ４０５においてCPU１０は、TKGIにおけるTKI_POB_ATRを参照して、各POBファイルをどのような表示モードで表示させるかを決定する。TKI_POB_ATRがシーケンシャルモードと記載されているなら、ステップＳ４０５からステップＳ４０６に移行して変数iを初期化し、ステップＳ４０７において、i番目のTKI_POB_SRPにて指定されているPOBファイルを表示時間POB_timeだけ表示する。この際、TKI_POB_SRPで指定されているPOBファイルの拡張子がJPGであるなら、当該POBをそのまま表示する。TKI_POB_SRPで指定されているPOBの拡張子がSP1であり、暗号化されているのなら、これに対応するFilekeyをプロテクト領域から読み出して、当該POBの暗号化を復号した上で、当該POBを表示する。その後、ステップＳ４０８では、変数iがPOB_Nsに達したかを判定し、達していないならステップＳ４０９において変数iをインクリメントして、ステップＳ４０７に移行する。以降、変数iがPOB_Nsに達するまで、ステップＳ４０６〜ステップＳ４０９を繰り返し行う。これにより、TKGIのTKI_POB_SRPにて指定されるPOBが順次表示されてゆく。変数iがPOB_Nsに達した場合、本フローチャートの処理を終了する。
【０２９７】
TKI_POB_ATRがランダムモードと記載されているなら、ステップＳ４１０において変数iを初期化した後、ステップＳ４１１において1からPOB_Nsまでの範囲の乱数rを発生して、ステップＳ４１２において乱数rに相当するr番目のTKI_POB_SRPにて指定されているPOBファイルをステップＳ４０４において決定された表示時間POB_timeだけ表示する。その後、ステップＳ４１３において変数iがPOB_Nsに達したかを判定し、達していないならステップＳ４１４において変数iをインクリメントして、ステップＳ４１１に移行する。当該表示を終えると、ステップＳ４１１において1からPOB_Nsまでの範囲の乱数rを再度発生して、ステップＳ４１２において乱数rに相当するr番目のTKI_POB_SRPにて指定されているPOBファイルを読み出して、ステップＳ４０４において決定された表示時間POB_timeだけ表示する。この際、シーケンシャルモードの場合と同様に、TKI_POB_SRPで指定されているPOBファイルの拡張子がJPGであるなら、当該POBをそのまま表示する。TKI_POB_SRPで指定されているPOBの拡張子がSP1であり、暗号化されているのなら、これに対応するFilekeyをプロテクト領域から読み出して、当該POBの暗号化を復号した上で、当該POBを表示する。
【０２９８】
以降、変数iがPOB_Nsに達するまで、ステップＳ４１１〜ステップＳ４１４を繰り返し行う。これにより、TKGIのTKI_POB_SRPにて指定されるPOBがランダムな順序で表示されてゆく。変数iがPOB_Nsに達した場合、本フローチャートの処理を終了する。
TKI_POB_ATRがシャッフルモードと記載されているなら、ステップＳ４０５からステップＳ４１５に移行して、ステップＳ４１５において変数iを初期化した後、ステップＳ４１６において1からPOB_Nsまでの範囲の乱数rを発生し、その後、ステップＳ４１８では、発生した乱数rと、表示済みPOB番号とが一致するか否かを判定する。一致するなら、ステップＳ４１６に移行して、再度乱数を発生する。一致しないのなら、ステップＳ４１８からステップＳ４１９に移行して、乱数rに相当するr番目のTKI_POB_SRPにて指定されているPOBファイルをステップＳ４０４において決定された表示時間POB_timeだけ表示する。この際、シーケンシャルモード、ランダムモードの場合と同様に、TKI_POB_SRPで指定されているPOBファイルの拡張子がJPGであるなら、当該POBをそのまま表示する。TKI_POB_SRPで指定されているPOBの拡張子がSP1であり、暗号化されているのなら、これに対応するFilekeyをプロテクト領域から読み出して、当該POBの暗号化を復号した上で、当該POBを表示する。当該表示を終えると、ステップＳ４１７において変数rを表示済みPOB番号として格納する。その後、ステップＳ４２０において変数iがPOB_Nsに達したかを判定し、達していないならステップＳ４２１において変数iをインクリメントして、ステップＳ４１６に移行する。以降、変数iがPOB_Nsに達するまで、ステップＳ４１６〜ステップＳ４２１を繰り返し行う。これにより、TKGIのTKI_POB_SRPにて指定されるPOBが順次表示されてゆく。変数iがPOB_Nsに達した場合、本フローチャートの処理を終了する。
【０２９９】
{95-1} 背景画表示処理についてのフローチャート
前景画表示処理についての説明を以上で終え、続いて背景画表示処理の処理手順について説明する。図９５は、背景画表示処理の処理手順を示すフローチャートである。本フローチャートは、図９４において『TKGIのTKI_POB_SRP、TKI_POB_ATR』に基づいて行われていた処理を『DPLGIのDPLI_POB_SRP、DPLI_POB_ATR』に置き換えたものであり、基本的な処理手順は、図９４のフローチャートと同一である。
【０３００】
Default_Playlist情報が選択されると、ステップＳ４０２〜Ｓ４０５の場合と同様、ステップＳ５０２〜Ｓ５０５においてCPU１０は、当該DPLGIに含まれるDPLI_POB_SRPがPOBファイルを指定しているか否かを判定し、指定している場合、何枚のPOBファイルを指定しているかを計数して、POBファイル一枚当たりの表示時間POB_timeを決定し、またDPLI_POB_ATRに従って、どの表示モードで表示させるかを決定する。DPLI_POB_ATRがシーケンシャルモードと記載されているなら、ステップＳ４０６〜ステップＳ４０９の場合と同様、ステップＳ５０６〜ステップＳ５０９において、変数iに従って、DPLGIに含まれるDPLI_POB_SRPに従い、POBファイルを順次表示してゆく。
【０３０１】
DPLI_POB_ATRがランダムモードと記載されているなら、ステップＳ４１０〜ステップＳ４１４の場合と同様、ステップＳ５１０〜ステップＳ５１４において、変数rに従って、DPLGIに含まれるDPLI_POB_SRPに従い、POBファイルを順次表示してゆく。
DPLI_POB_ATRがシャッフルモードと記載されているなら、ステップＳ４１５〜ステップＳ４２１の場合と同様、ステップＳ５１５〜ステップＳ５２１において、変数rに従って、DPLGIに含まれるDPLI_POB_SRPに従い、POBファイルを順次表示してゆく。
【０３０２】
{96-1}背景画表示処理についてのフローチャート
DPLGIのDPLI_POB_SRPを参照した場合の前景画表示処理についての説明を以上で終え、続いてPLGIのPLI_POB_SRPを参照する場合の背景画表示処理の処理手順について説明する。図９６は、背景画表示処理の処理手順を示すフローチャートである。本フローチャートは、図９５において『DPLGIのDPLI_POB_SRP、DPLI_POB_ATR』に基づいて行われていた処理を『PLGIのPLI_POB_SRP、DPLI_POB_ATR』に置き換えたものであり、前景画と基本的な処理手順は、図９５のフローチャートと同一なので、同一の参照符号を付して、詳細な説明は省略する。
【０３０３】
{94-2_95-2_97A,B,C} 液晶ディスプレィ５における表示例
図９４、図９５のフローチャートに示す処理手順により、TKI_POB_SRPにて指定された前景画、DPLGIにより指定された背景画が合成された場合に、どのような合成画像が液晶ディスプレィ５に表示されるかを図９７（ａ）〜（ｃ）に示す。
【０３０４】
図９７（ａ）に示すように、Default_Playlist情報が指定され、これに記載された再生順序に従い、POBの表示が開始されたとする。この場合、図９４のフローチャートに示す前景画表示処理と、図９５のフローチャートに示す背景画表示処理とが行われて、TKGIに含まれる複数のTKI_POB_SRPより表示が指定されたPOB、DPLGIに含まれる複数のDPLI_POB_SRPより表示が指定されたPOBが順次表示されてゆく。そのため再生開始から6分経過後に図８０に示した画像合成が行われ、液晶ディスプレィ５には、図９７（ｂ）に示す合成画像が表示される。
【０３０５】
また再生開始から16分経過後に図８１に示した画像合成が行われ、液晶ディスプレィ５には、図９７（ｃ）に示す合成画像が表示される。
{94-2_96-1_98A,B,C} 液晶ディスプレィ５における表示例
図９４、図９６のフローチャートに示す処理手順により、TKI_POB_SRPにて指定された前景画、PLI_POB_SRPにて指定された背景画が合成された場合に、どのような合成画像が液晶ディスプレィ５に表示されるかを図９８（ａ）〜（ｃ）に示す。
【０３０６】
図９８（ａ）に示すように、PlayList情報が指定され、これに記載された再生順序に従い、POBの表示が開始されたとする。この場合、図９４のフローチャートに示す前景画表示処理と、図９６のフローチャートに示す背景画表示処理とが行われて、TKGIに含まれる複数のTKI_POB_SRPより表示が指定されたPOB、PLGIに含まれる複数のPLI_POB_SRPより表示が指定されたPOBが順次表示されてゆく。そのため再生開始から6分経過後に図８５に示した画像合成が行われ、液晶ディスプレィ５には、図９８（ｂ）に示す合成画像が表示される。また再生開始から16分経過後に図８６に示した画像合成が行われ、液晶ディスプレィ５には、図９８（ｃ）に示す合成画像が表示される。
【０３０７】
{99_1}第２実施形態に係る記録装置
続いて、第２実施形態に係る記録装置について説明する。第２実施形態に係る記録装置が新規なのは、複数のPOBをフラッシュメモリカード３１に記録すると共に、TKI_POB_SRP、DPLI_POB_SRP、PLI_POB_SRPを設定する点、また、TKI_POB_ATR、DPLI_POB_ATR、PLI_POB_ATRを設定する点である。こうした一連の処理は、第２実施形態に係るCPU１０が図９９のフローチャートに記載された手順を経ることによりなされる。以降、図９９のフローチャートを参照しながら、第２実施形態に係る記録装置の記録処理について説明する。
【０３０８】
ステップＳ６０１において、CPU１０は本フローチャートで用いられる各変数の初期化を行う。本フローチャートで用いられる変数には、変数#x、#y、#z、#u、#vy、#wがある。#xは、複数のPOBのうち処理対象となるPOBを特定する変数であり、#yは、複数トラックシーケンスのうち処理対象となるトラックシーケンス(PLI)を特定する変数、#zは、複数トラックのうち処理対象となるトラック(TKI)を特定する変数である。
【０３０９】
#uは、複数のDPLI_POB_SRPのうち、処理対象となるDPLI_POB_SRPを特定する変数であり、#vyは、#yにて指示されるPLI（PLI#y）に含まれる複数PLI_POB_SRPのうち、処理対象となるPLI_POB_SRPを特定する変数である。#wは、#zにて指示されるTKI#y）に含まれる複数TKI_POB_SRPのうち処理対象となるTKI_POB_SRPを特定する変数である。
【０３１０】
これらの変数が初期化されると、ステップＳ６０２においてPOB#xを表示する。これにより、操作者は、POBがどのような写真、イラスト、歌詞であるかを視覚的に確認することができる。ステップＳ６０３においてPOB#xは、トラックシーケンスが再生される全時間帯を通じて表示させるべき静止画データであるか、特定のトラックが再生される時間帯にのみ表示させるべき静止画データであるかという選択を操作者から仰ぎ、何れかの選択を受け付ける。
【０３１１】
『POB#xをトラックシーケンスに割り当てるべき』と操作者が判断した場合、ステップＳ６０４においてPOB#xを表示させるべきトラックシーケンスの選択待ちを行い、もし選択がなされれば、ステップＳ６０５においてそのトラックシーケンス#yを指定しているプレイリストはDPLIであるか、PLIであるかを判定する。そのプレイリストがDPLIならばステップＳ６０６においてDPLIにおけるDPLI_POB_SRP#uにPOB#xを設定し、ステップＳ６０７においてDPLIにおけるDPLI_POB_ATR#uをPOB#xに基づいて設定する。こうしてDPLI_POB_SRP、DPLI_POB_ATRの双方を設定したのなら、ステップＳ６０８において#uのインクリメントを行い（#u←#u+1）、その後、ステップＳ６０９において#xのインクリメントを行う（#x←#x+1）。
【０３１２】
ステップＳ６０５においてPLIが選択された場合、ステップＳ６１０においてPLI#yにおけるPLI_POB_SRP#vyにPOB#xを設定し、ステップＳ６１１においてPLIにおけるPLI_POB_ATR#vyをPOB#xに基づいて設定する。そして、ステップＳ６１２において#vyをインクリメントした後（#vy←#vy+1）、#xをインクリメントするようステップＳ６０９に移行する。
【０３１３】
ステップＳ６０３においてPOB#xをトラックに割り当てるべきと判断した場合、ステップＳ６１３においてトラックの指定を受け付け、ステップＳ６１４において指定されたトラック#zについてのTKI#zに設定されているTKI_POB_SRP#wにPOB#xを設定する。その後、ステップＳ６１５においてTKI#zにおけるTKI_POB_ATR#wをPOB#xに基づいて設定し、ステップＳ６１６において#wをインクリメントした後（#w←#w+1）、ステップＳ６１７において#xがPOBのラストナンバー#nに達したか否かを判定する。達しないならば、ステップＳ６０９に移行して#xのインクリメントを行い、#xがPOBのラストナンバー#nに達したならば、ステップＳ６１８においてPOB#1〜#n,DPLI及びPLIを含むPLMGTKIを含むTKMGをフラッシュメモリカードに記録して、処理を終了する。
【０３１４】
以上のように本実施形態によれば、アーティストの写真や会社のロゴマーク等、複数のトラックが再生されている時間帯において、背景画として共通に表示させたい静止画データが存在する場合、Default_Playlist情報、PlayList情報におけるDPLGI、PLGI内のDPLI_POB_SRP、PLI_POB_SRPにて、その静止画データを指定することにより、それらのプレイリスト情報により再生順序が指定される複数のトラックが再生されている時間帯において、共通の静止画データを表示させておくことができる。また、歌詞等のように、背景画とは別に特定のトラックが再生されている期間にのみ表示させたい静止画データが存在する場合、そのような静止画データをTKIにおけるTKI_POB_SRPにて指定することができる。
【０３１５】
尚、上記実施形態は現状において最善の効果が期待できるシステム例として説明したに過ぎない。本発明は、その要旨を逸脱しない範囲で実施変更することができる。具体的には、以下の（ａ）（ｂ）（ｃ）に示すような変更実施が可能である。
（ａ）図９４、図９５、図９６、図９９のフローチャートを参照して説明した手順等を実行形式プログラムにより実現し、これを記録媒体に記録して流通・販売の対象にしても良い。
【０３１６】
（ｂ）本実施形態に係るプレゼンテーションデータ、ナビゲーションデータを音楽コンテンツに適用する場合を一例として説明を行ったが、本実施形態に係るプレゼンテーションデータ、ナビゲーションデータをアナウンサーや声優が書物を読み上げる音声により構成されるリーディングブックに適用してよいことはいうまでもない。この場合、その書物に含まれる文章の文字列を含む静止画を前景画としてTKI_POB_SRPにて指定させ、一方、その文書の挿絵を背景画としてDPLI_POB_SRP、PLI_POB_SRPに指定させるのが望ましい。
【０３１７】
（ｃ）本実施形態では、DPLI_POB_SRP−PLI_POB_SRPにより指定されていたPOBを背景画とし、TKI_POB_SRPにより指定されていたPOBを前景画としていたが、両者の関係を入れ替えても良い。更に、DPLI_POB_SRP−PLI_POB_SRPで指定されていたPOB、及び、TKI_POB_SRPにより指定されていたPOBの何れか一方のみを表示させてもよい。加えて、POBを前景画、背景画と区別することなく表示させてもよい。例えば、DPLI_POB_SRP(PLI_POB_SRP)にて指定されたPOBを表示し、次にTKI_POB_SRPにて指定されたPOBを表示させてよいことはいうまでもない。
【０３１８】
（第３実施形態）
第２実施形態では、PlayList情報及びTKIが有効な期間に各POBを均等な割合で表示させるとしたが、第３実施形態は、フレーズ期間テーブルと、ハイライト座標テーブルとをフラッシュメモリカード３１に格納させて、音声再生と、歌詞表示とを緻密に同期させる実施形態である。
【０３１９】
前者のフレーズ期間テーブルとは、各歌詞を示すPOBを指定するTKI_POB_SRPと、フレーズ期間の始期・終期を示す情報とを対応づけたテーブルである。図１００（ａ）は、フレーズ期間テーブルの一例を示す図である。ここでフレーズ期間は、AOBの再生時において、歌詞に記述されているフレーズが現れる期間を、ミリ秒単位の時間精度で表しており、再生装置は、第１実施形態に示したような再生経過時刻の更新に伴い、更新された再生経過期間が、テーブルに記載されているフレーズ期間のどれに相当するかの監視を行う。かかる監視により、現在再生されているAOB、AOB_ELEMENT、AOB_FRAMEの歌詞を記載したPOBがどれであるかを知ることができる。POBのフレーズ期間が何時であるかをミリ秒単位の時間精度で記載したテーブルを用いれば、上述したミリ秒単位の時間精度で、AOB再生と、歌詞表示とを同期させることができる。
【０３２０】
また、第１実施形態に示したようなジョグダイアルを用いた再生開始時刻の指定がなされ、頭出しを行う場合、AOB、AOB_ELEMENTについては、第１実施形態に示した数式１〜数式３を用いることにより、指定された再生開始時刻がどのAOBのどのAOB_ELEMENTのAOB_FRAMEに該当するかを判定する。一方静止画については、指定された再生開始時刻がどのフレーズ期間に対応するかを判定する。そして、指定されたフレーズ期間に対応するPOBを表示させる。こうして、ジョグダイアルを用いて頭出しを行う場合にも、その該当するPOBを適宜表示することができる。尚、本実施形態では、フレーズ期間テーブルに時刻を記載したが、その歌詞と同期すべきAOB、AOB_ELEMENT、AOB_FRAMEを示すAOB番号、AOB_ELEMENT番号、AOB_FRAME番号をフレーズ期間テーブルに記載しても良い。
【０３２１】
一方、後者のハイライト座標テーブルとは、歌詞に含まれる文字についての表示座標と、AOBにおいて、その文字に対応するAOB_ELEMENT及びAOB_FRAMEが再生される期間とを対応づけたテーブルである。図１００（ｂ）は、ハイライト座標テーブルの一例を示す図である。こうしたハイライト座標テーブルを設けておき、フレーズ期間に対応して表示されている歌詞のうち、今再生されているAOB_ELEMENT及びAOB_FRAMEに対応する文字のみを、異なる色にて表示するという動作を再生装置に行わせる。
【０３２２】
例えば歌詞に『小さなウィンドゥからあなたにアクセス』というフレーズが含まれている場合、ハイライト座標テーブルには、『小』『さ』『な』『ウ』『ィ』『ン』『ド』『ゥ』という文字の表示座標と、その文字に対応するAOB_ELEMENT及びAOB_FRAMEが再生される期間とを対応づけておく。そして再生装置は、第１実施形態に示したようなAOBの再生進行に伴い、ハイライト座標テーブルにおける文字の表示座標にて指示された箇所の色を変更する。
【０３２３】
これにより再生装置は、歌詞のうち、AOBにて再生されている箇所がどこであるかが、一目で判るような映像表示を行うことができ、現行のカラオケソフトのような再生を実現することが可能となる。
以上のように本実施形態によれば、フレーズ期間テーブルと、ハイライト座標テーブルという2つのテーブルを用いることにより、現行のカラオケソフトのような、音声再生と、歌詞表示とを緻密に同期させることが可能となる。
【０３２４】
【発明の効果】
本発明に係る半導体メモリカードは、複数のオーディオオブジェクト、静止画オブジェクト、再生経路情報、第１ポインタ情報、第２ポインタ情報、シンボリックカウンタを格納する半導体メモリカードであって、再生経路情報は、オーディオオブジェクトの再生順序を示し、第１ポインタ情報は、再生経路情報に対応するものであって、該再生経路情報に従ったオーディオオブジェクトの全再生時間中における静止画オブジェクトの再生順序を示し、第２ポインタ情報は、特定のオーディオオブジェクトに対応するものであって、該オーディオオブジェクトの全再生時間中における静止画オブジェクトの再生順序を示し、シンボリックカウンタは、各静止画オブジェクトに対応づけられており、対応する静止画オブジェクトが第１ポインタ情報又は第２ポインタ情報により指定されているか否かを示し、指定されている静止画オブジェクトについては、幾つの第１ポインタ情報、第２ポインタ情報により指定されているかの指定数を示しているので、オーディオシーケンスに含まれる複数のオーディオオブジェクトが、再生経路情報に示される再生順序に準じて再生されている時間帯において、背景画として共通に表示させたい静止画オブジェクトが存在する場合、第１ポインタ情報において、再生経路情報と対応づけてその静止画オブジェクトを指定させる。これによりオーディオシーケンスに含まれる複数のオーディオオブジェクトが再生されている時間帯において、共通の静止画オブジェクトを表示させておくことができる。
【０３２５】
複数のオーディオオブジェクトに対して共通の静止画を割り当てることができるので、知名度が低い音楽アルバムに相当するオーディオシーケンスについては、複数のオーディオオブジェクトが再生されている期間において、静止画オブジェクト等を共通に表示させることにより、画像製作に要する手間や費用を倹約することができる。
【０３２６】
逆に知名度が高い音楽アルバムに相当するオーディオシーケンスについては、各オーディオオブジェクトが再生されている期間において、各オーディオオブジェクトに対して複数の静止画を割り当てて、一つのオーディオオブジェクトに対して複数の静止画オブジェクトを表示させることにより、各オーディオオブジェクトの再生を豪華に演出することができる。そうした静止画表示にてアーティストのファンの心理を掴むことにより、オーディオシーケンス（音楽アルバム）の売り上げを高めることができる。
【０３２７】
また、歌詞等のように、背景画とは別に特定のオーディオオブジェクトが再生されている期間にのみ表示させたい静止画オブジェクトが存在する場合、そのような静止画オブジェクトを第２ポインタ情報にて指定して、特定のオーディオオブジェクトに割り当てることができる。
更に、対応する静止画オブジェクトが第１ポインタ情報又は第２ポインタ情報により指定されているか否かがシンボリックカウンタに示されている。このシンボリックカウンタには、幾つの第１ポインタ情報、第２ポインタ情報により指定されているかの指定数さえも表現されているので、半導体メモリカードの記録装置がオーディオオブジェクトやオーディオシーケンスの削除を行った際、削除されたオーディオオブジェクトについての第２ポインタ情報や削除されたオーディオシーケンスについての第１ポインタ情報を特定し、これら第１ポインタ情報、第２ポインタ情報により表示が指定される静止画オブジェクトについての割当数をデクリメントしてゆく。何れかの静止画オブジェクトについての割当数が0に達したなら、当該静止画オブジェクトはどの第１ポインタ情報や第２ポインタ情報からも参照されない静止画オブジェクトであるとして、当該静止画オブジェクトを削除してしまうことができる。このようにオーディオオブジェクトの削除と連動して、静止画オブジェクトの削除を行うことにより、半導体メモリカードにおける記憶効率を向上させることができる。
【図面の簡単な説明】
【図１】フラッシュメモリカード３１を上面から見た場合の形状を示す図である。
【図２】フラッシュメモリカード３１をその下面から見た場合の形状を示す図である。
【図３】本実施形態に係るフラッシュメモリカード３１の階層構造を示す図である。
【図４】（ａ）フラッシュメモリカード３１の物理層に設けられたシステム領域と、プロテクト領域と、ユーザデータ領域の構成を示す図である。
（ｂ）ファイルシステム層におけるプロテクト領域及びユーザデータ領域の構成を示す図である。
【図５】ファイルシステム層における構成の詳細を示す図である。
【図６】 AOB001.SA1をクラスタサイズに合わせて5つに分割し、各分割部分を、クラスタ003,004,005,00A,00Cに格納する状態を想定した図である。
【図７】 AOB001.SA1が複数のクラスタに記録されている場合のディレクトリエントリー及びファイルアロケーションテーブルについての設定例を示す図である。
【図８】（ａ）（ｂ）応用層におけるこれら2つのデータを格納する場合、ファイルシステム層においてユーザデータ領域及びプロテクト領域には、どのようなディレクトリが構成され、どのようなファイルが当該ディレクトリの配下に作成されるかを示す図である。
【図９】 SD_Audioディレクトリの下にあるAOBSA1.KEYと、AOBファイルとの対応を示す図である。
【図１０】 AOBファイルのデータ構成を階層的に示す図である。
【図１１】（ａ）ISO/IEC13818-7に記述されているパラメータを表形式に示す図である。
（ｂ）MPEG-Layer3(MP3)方式にて符号化する際に使用すべきパラメータを表形式に示す図である。
（ｃ）Windows（登録商標） Media Audio(WMA)方式にて符号化する際に使用すべきパラメータを表形式に示す図である。
【図１２】 AOB_FRAMEの構成の詳細を示す図である。
【図１３】 3つのAOB_FRAMEにおいて、それぞれのAOB_FRAMEにおけるオーディオデータのバイト長がどのように設定されるかを示す図である。
【図１４】 sampling_frequencyと、AOB_ELEMENTに含まれるAOB_FRAME数との対応を示す図である。
【図１５】 AOB_ELEMENTの時間長及びAOB_FRAMEの時間長の一例を示す図である。
【図１６】 AOBファイルに収録されている各AOB、AOB_BLOCKが連続して再生されることにより、どのような再生内容が再生されるかを示す図である。
【図１７】第１実施形態におけるPlaylistmanager及びTrackManagerの構成を段階的に詳細化した図である。
【図１８】 PlayListManager及びTrackManagerのサイズを示す図である。
【図１９】図１７に示したTKIと、図１６に示したAOBファイル及びAOBとの相互関係を示す図である。
【図２０】図１７に示したTKTMSRTの詳細なデータ構造を示す図である。
【図２１】 TKTMSRTについての一例を示す図である。
【図２２】 TKGIの詳細構成を示す図である。
【図２３】（ａ）（ｂ）BITの詳細構成を示す図である。
（ｃ）TIME_LENGTHフィールドのデータフォーマットを示す図である。
【図２４】 AOB_ELEMENT#1〜#4からなるAOBが格納されているクラスタ007〜クラスタ00Eを示す図である。
【図２５】 AOB内の任意のAOB_ELEMENT#yにおけるAOB_FRAME#xから順方向サーチ再生を行う場合、次に再生すべきAOB_FRAME#x+1をどのように設定するかを示す図である。
【図２６】（ａ）（ｂ）任意の再生開始時刻が指定された場合、その指定時刻に対応するAOB、AOB_ELEMENT、AOB_FRAMEをどのように特定するかを示す図である。
【図２７】（ａ）（ｂ）トラックを削除する場合を想定した図である。
【図２８】（ａ）トラックの削除が複数回行われた後のTrackManagerを示す図である。
（ｂ）『Unused』のTKIが存在しており、ここに新たなTKI、AOBファイルを書き込む場合、その書き込みがどのように行われるかを示す図である。
【図２９】（ａ）（ｂ）2つのトラックを統合する場合にTKIがどのように設定されるかを示す図である。
【図３０】（ａ） Type1のAOBを示す図である。
（ｂ）Type2のAOBを示す図である。
【図３１】（ａ）Type1＋Type2＋Type2＋Type1の組み合わせで、複数トラックを1つに統合する場合を示す図である。
（ｂ）Type1＋Type2＋Type2＋Type2＋Type1の組み合わせで、複数トラックを1つに統合する場合を示す図である。
【図３２】（ａ）先行するトラックの終端にType1のAOBが配され、後続するトラックの先頭にType1のAOBが配されている配置パターンを示す図である。
（ｂ）先行するトラックの終端にType1のAOBが配され、後続するトラックの先頭にType2のAOBが配されている配置パターンを示す図である。
（ｃ） 先行するトラックの終端にType1、Type2順でAOBが配され、後続するトラックの先頭にType1のAOBが配されている配置パターンを示す図である。
（ｄ） 先行するトラックの終端にType1、Type2順でAOBが配され、後続するトラックの先頭に、Type2、Type1のAOBが配されている配置パターンを示す図である。
（ｅ） 先行するトラックの終端にType2、Type2のAOBが配され、後続するトラックの先頭にType1のAOBが配されている配置パターンを示す図である。
【図３３】（ａ）（ｂ）1つのトラックを2つのトラックに分割する場合を想定した図である。
【図３４】（ａ）（ｂ）分割前後において、AOB003.SA1が属するSD_AudioディレクトリについてのSD_Audioディレクトリエントリーがどのように記述されているかかを示す図である。
【図３５】（ａ）AOBをAOB_ELEMENT#2の途中部分で分割する場合を想定した図である。
（ｂ）AOB_ELEMENT#2の途中部分でAOBが分割されて、AOB#1、AOB#2という2つのAOBが得られた状態を示す図である。
【図３６】図３５に示したようにAOBが分割された場合に、BITがどのように設定されるかを示す図である。
【図３７】分割の前後でBITがどのように変化するかを具体的に示す図である。
【図３８】分割の前後でTKTMSRTがどのように変化するかを具体的に示す図である。
【図３９】（ａ）DPL_TK_SRPのフォーマットを示す図である。
（ｂ）PL_TK_SRPのフォーマットを示す図である。
【図４０】 Default_Playlist情報、TKI、AOBファイルの相互関係を示す図である。
【図４１】 DefaultPlaylist、PlayList情報の設定例を、図４０と同様の表記で示した図である。
【図４２】図４０と同じ表記法を用いてDPL_TK_SRPとTKIとの対応を示す図である。
【図４３】（ａ）（ｂ）トラックの順序を入れ替える場合を想定した図である。
【図４４】（ａ）（ｂ）図４０に示したDefaultPlaylistのうち、DPL_TK_SRP#2及びTKI#2を削除する場合にDefaultPlaylist、TrackManager、AOBファイルがどのように更新されるかを示す図である。
【図４５】（ａ）（ｂ）『Unused』のTKIと、DPL_TK_SRPとが存在しており、ここに新たなTKI、DPL_TK_SRPを書き込む場合、その書き込みがどのように行われるかを示す図である。
【図４６】（ａ）（ｂ）トラックの統合を行う場合を想定した図である。
【図４７】（ａ）（ｂ）トラックの分割を行う場合を想定した図である。
【図４８】本実施形態に係るフラッシュメモリカード３１についての携帯型の再生装置を示す図である。
【図４９】プレイリストの選択が行われる際の液晶ディスプレィの表示内容の一例を示す図である。
【図５０】（ａ）〜（ｅ）トラックの選択が行われる際の液晶ディスプレィの表示内容の一例を示す図である。
【図５１】（ａ）〜（ｃ）ジョグダイアルの操作例を示す図である。
【図５２】再生装置の内部構成を示す図である。
【図５３】ダブルバッファ１５におけるデータ入出力がどのように行われるかを示す図である。
【図５４】（ａ）（ｂ）リングポインタを用いた巡回式の領域確保がどのように行われるかを示す図である。
【図５５】 AOBファイル読み出し処理の処理手順を示すフローチャートである。
【図５６】 AOB_FRAME出力処理の処理手順を示すフローチャートである。
【図５７】 AOB_FRAME出力処理の処理手順を示すフローチャートである。
【図５８】 AOB_FRAME出力処理の処理手順を示すフローチャートである。
【図５９】（ａ）〜（ｄ）液晶ディスプレィ５の時刻表示枠に表示される再生経過時刻が、変数Play_Timeの更新したがい、増加してゆく様子を示す図である。
【図６０】順方向サーチ再生処理時におけるCPU１０の処理手順を示すフローチャートである。
【図６１】（ａ）〜（ｄ）順方向サーチ再生時において、再生経過時刻がインクリメントされてゆく様子を示す図である。
【図６２】（ａ）〜（ｂ）タイムサーチ機能が行われる場合の具体例を示す図である。
【図６３】編集制御プログラムの処理手順を示すフローチャートである。
【図６４】編集制御プログラムの処理手順を示すフローチャートである。
【図６５】編集制御プログラムの処理手順を示すフローチャートである。
【図６６】フラッシュメモリカード３１の記録装置の一例を示す図である。
【図６７】記録装置のハードウェア構成を示す図である。
【図６８】記録処理の処理手順を示すフローチャートである。
【図６９】第２実施形態におけるフラッシュメモリカードの階層構造を示す図である。
【図７０】（ａ）（ｂ）ファイルシステム層におけるユーザデータ領域及びプロテクト領域の内部構成を示す図である。
【図７１】（ａ）POBXXX.JPGの内部構成を示す図である。
（ｂ）暗号化された静止画データを含むPOBファイルの内部構成を示す図である。
（ｃ）暗号化された実体部の代わりにファイルパスを格納したPOBファイルの一例を示す図である。
【図７２】第２実施形態におけるPlayListManager、TrackManagerの詳細構成を示す図である。
【図７３】 TKI_POB_SRP、PLI_POB_SRP、DPLI_POB_SRPにより、図７０に示したPOBファイルが指定されている状態を示す図である。
【図７４】 TKI_POB_SRP、TKI_POB_ATRのデータ構造を示す図である。
【図７５】 TrackManagerに含まれるTKI#1〜TKI#3についてのTKI_POB_SRPの設定例を示す図である。
【図７６】 TrackManagerに含まれるTKI#4〜TKI#8に含まれるTKI_POB_SRPの設定例を示す図である。
【図７７】 DPLGIに含まれているDPLI_POB_SRP及びDPLI_POB_ATRを示す図である。
【図７８】 Default_Playlist情報に含まれる20個のDPLI_POB_SRPの設定例を示す図である。
【図７９】 Default_Playlist情報に含まれるDPLI_POB_SRPにて指定されたPOBを背景画とし、TrackManagerに含まれるTKI_POB_SRPにて指定されるPOBを前景画とした場合、これらがどのように合成されるかを示すタイミングチャートである。
【図８０】 Default_Playlist情報の再生開始から6分経過後に、前景画、背景画がどのように合成されるかを示す図である。
【図８１】 Default_Playlist情報の再生開始から16分経過後に、前景画、背景画がどのように合成されるかを示す図である。
【図８２】 PLGIに含まれているPLI_POB_SRP及びPLI_POB_ATRを示す図である。
【図８３】 PlayList情報に含まれる20個のPLI_POB_SRPの設定例を示す図である。
【図８４】 Playlist情報に含まれるPLI_POB_SRPにて指定されたPOBを背景画とし、TrackManagerに含まれるTKI_POB_SRPにて指定されるPOBを前景画とした場合、これらがどのように合成されるかを示すタイミングチャートである。
【図８５】 Playlist情報の再生開始から6分経過後に、前景画、背景画がどのように合成されるかを示す図である。
【図８６】 Default_Playlist情報の再生開始から16分経過後に、前景画、背景画がどのように合成されるかを示す図である。
【図８７】 Default_Playlist情報における複数のDPLI_POB_SRPのうち、DPLI_POB_SRPに共通のPOBファイルを指定させることにより、POBファイルの数の削減を図った例である。
【図８８】 Default_Playlist情報に含まれるDPLI_POB_SRPにて指定されたPOBを背景画とし、TrackManagerに含まれるTKI_POB_SRPにて指定されるPOBを前景画とした場合、これらがどのように合成されるかを示すタイミングチャートである。
【図８９】 POBMGの内部構成を示す図である。
【図９０】第２実施形態に係る再生装置がどのように用いられるかを示す図である。
【図９１】第２実施形態に係る再生装置本体のみの外観を示す図である。
【図９２】第２実施形態に係る再生装置の内部構成を示す図である。
【図９３】（ａ）複数のVRAM６１に格納された静止画がどのように重ね合わせられるかを示す図である。
（ｂ）複数のVRAM６１に格納された静止画がどのように重ね合わせられるかを示す図である。
【図９４】前景画表示処理についての処理手順を示すフローチャートである。
【図９５】背景画表示処理の処理手順を示すフローチャートである。
【図９６】背景画表示処理の処理手順を示すフローチャートである。
【図９７】（ａ）〜（ｃ）図９４、図９５のフローチャートに示す処理手順により、TKI_POB_SRPにて指定された前景画、DPLGIにより指定された背景画が合成された場合に、どのような合成画像が液晶ディスプレィ５に表示されるかを示す図である。
【図９８】（ａ）〜（ｃ）図９４、図９６のフローチャートに示す処理手順により、TKI_POB_SRPにて指定された前景画、PLI_POB_SRPにて指定された背景画が合成された場合に、どのような合成画像が液晶ディスプレィ５に表示されるかを示す図である。
【図９９】第２実施形態に係る記録装置の処理手順を示すフローチャートである。
【図１００】（ａ）フレーズ期間テーブルの一例を示す図である。
（ｂ）ハイライト座標テーブルの一例を示す図である。
【符号の説明】
１ カードコネクタ
２ ユーザインターフェイス部
３ RAM
４ ROM
５ 液晶ディスプレィ
６ LCDドライバ
７ デ・スクランブラ
８ AACデコーダ
９ A/Dコンバータ
１１ DPLI常駐領域
１２ PLI格納領域
１３ TKI格納領域
１４ FileKey格納領域
１５ ダブルバッファ
２１ カードコネクタ
２２ RAM
２３ 固定ディスク装置
２４ コンバータ
２４ A/DステップＳ
２５ AACエンコーダ
２６ スクランブル部
２７ モデム装置
２８ CPU
２９ キーボード
３０ ディスプレィ
３１ フラッシュメモリカード
３２ プロテクトスイッチ
６１ VRAM
Claims (4)
- 複数のオーディオオブジェクト、静止画オブジェクト、再生経路情報、第１ポインタ情報、第２ポインタ情報、シンボリックカウンタを格納する半導体メモリカードであって、
再生経路情報は、オーディオオブジェクトの再生順序を示し、
第１ポインタ情報は、再生経路情報に対応するものであって、該再生経路情報に従ったオーディオオブジェクトの全再生時間中における静止画オブジェクトの再生順序を示し、
第２ポインタ情報は、特定のオーディオオブジェクトに対応するものであって、該オーディオオブジェクトの全再生時間中における静止画オブジェクトの再生順序を示し、
シンボリックカウンタは、各静止画オブジェクトに対応づけられており、対応する静止画オブジェクトが第１ポインタ情報又は第２ポインタ情報により指定されているか否かを示し、指定されている静止画オブジェクトについては、幾つの第１ポインタ情報、第２ポインタ情報により指定されているかの指定数を示す、半導体メモリカード。 - 請求項１に記載されている半導体メモリカードについての編集装置であって、
半導体メモリカードに記録されているオーディオオブジェクトの削除要求をユーザから受け付ける入力受付手段と、
削除要求のあったオーディオオブジェクトを半導体メモリカードから削除するオーディオオブジェクト削除手段と、
オーディオオブジェクトの再生順序を定義している再生経路情報から、削除要求のあったオーディオオブジェクトを除いた再生順序に更新する再生経路情報編集手段と、
削除要求のあったオーディオオブジェクトに関連付けられている第２ポインタ情報を削除する第２ポインタ情報編集手段と、
第２ポインタ情報によって指定されていた静止画オブジェクトに対応するシンボリックカウンタをデクリメントするシンボリックカウンタ編集手段と、
シンボリックカウンタ編集手段によって、特定の静止画オブジェクトのシンボリックカウンタをデクリメントした結果、シンボリックカウンタが０になったときは、当該静止画オブジェクトを半導体メモリカードから削除する静止画オブジェクト削除手段と、
を備える、編集装置。 - 請求項１に記載されている半導体メモリカードの編集をコンピュータに行わせるプログラムを記録した記録媒体であって、
半導体メモリカードに記録されているオーディオオブジェクトの削除要求をユーザから受け付ける入力受付ステップと、
削除要求のあったオーディオオブジェクトを半導体メモリカードから削除するオーディオオブジェクト削除ステップと、
オーディオオブジェクトの再生順序を定義している再生経路情報から、削除要求のあったオーディオオブジェクトを除いた再生順序に更新する再生経路情報編集ステップと、
削除要求のあったオーディオオブジェクトに関連付けられている第２ポインタ情報を削除する第２ポインタ情報編集ステップと、
第２ポインタ情報によって指定されていた静止画オブジェクトに対応するシンボリックカウンタをデクリメントするシンボリックカウンタ編集ステップと、
シンボリックカウンタ編集ステップによって、特定の静止画オブジェクトのシンボリックカウンタをデクリメントした結果、シンボリックカウンタが０になったときは、当該静止画オブジェクトを半導体メモリカードから削除する静止画オブジェクト削除ステップと、
を包含するプログラムを記録した記録媒体。 - 請求項１に記載されている半導体メモリカードの編集方法であって、
半導体メモリカードに記録されているオーディオオブジェクトの削除要求をユーザから受け付ける入力受付ステップと、
削除要求のあったオーディオオブジェクトを半導体メモリカードから削除するオーディオオブジェクト削除ステップと、
オーディオオブジェクトの再生順序を定義している再生経路情報から、削除要求のあったオーディオオブジェクトを除いた再生順序に更新する再生経路情報編集ステップと、
削除要求のあったオーディオオブジェクトに関連付けられている第２ポインタ情報を削除する第２ポインタ情報編集ステップと、
第２ポインタ情報によって指定されていた静止画オブジェクトに対応するシンボリックカウンタをデクリメントするシンボリックカウンタ編集ステップと、
シンボリックカウンタ編集ステップによって、特定の静止画オブジェクトのシンボリックカウンタをデクリメントした結果、シンボリックカウンタが０になったときは、当該静止画オブジェクトを半導体メモリカードから削除する静止画オブジェクト削除ステップと、
を包含する半導体メモリカードの編集方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002156443A JP4469125B2 (ja) | 1999-05-28 | 2002-05-29 | 半導体メモリカード、編集装置、編集方法、コンピュータ読み取り可能な記録媒体 |
Applications Claiming Priority (7)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP14989399 | 1999-05-28 | ||
| JP23672499 | 1999-08-24 | ||
| JP11-372604 | 1999-12-28 | ||
| JP11-236724 | 1999-12-28 | ||
| JP11-149893 | 1999-12-28 | ||
| JP37260499 | 1999-12-28 | ||
| JP2002156443A JP4469125B2 (ja) | 1999-05-28 | 2002-05-29 | 半導体メモリカード、編集装置、編集方法、コンピュータ読み取り可能な記録媒体 |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000156756A Division JP3327898B2 (ja) | 1999-05-28 | 2000-05-26 | 半導体メモリカード、再生装置、再生方法、コンピュータ読み取り可能な記録媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003099098A JP2003099098A (ja) | 2003-04-04 |
| JP4469125B2 true JP4469125B2 (ja) | 2010-05-26 |
Family
ID=27472975
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002156443A Expired - Fee Related JP4469125B2 (ja) | 1999-05-28 | 2002-05-29 | 半導体メモリカード、編集装置、編集方法、コンピュータ読み取り可能な記録媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4469125B2 (ja) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3847764B2 (ja) * | 2004-11-12 | 2006-11-22 | オンキヨー株式会社 | ネットワーク型コンテンツ再生システム |
| CN116071690B (zh) * | 2023-04-03 | 2023-06-09 | 江西师范大学 | 一种基于场景关键帧的情景特征提取方法 |
-
2002
- 2002-05-29 JP JP2002156443A patent/JP4469125B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003099098A (ja) | 2003-04-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2338725C (en) | Semiconductor memory card, playback apparatus, recording apparatus, playback method, recording method, and a computer-readable storage medium | |
| JP4150278B2 (ja) | 半導体メモリカード、再生装置、再生方法、及びコンピュータ読み取り可能な記録媒体 | |
| CA2338695C (en) | Semiconductor memory card, playback apparatus, recording apparatus, playback method, recording method, and computer-readable recording medium | |
| JP3366896B2 (ja) | 半導体メモリカード、記録再生装置、記録再生方法、コンピュータ読み取り可能な記録媒体 | |
| JP4145646B2 (ja) | データ管理方法、データ管理装置、データ管理プログラム、データ管理プログラムを格納したコンピュータ読み取り可能な記憶媒体 | |
| JP4469125B2 (ja) | 半導体メモリカード、編集装置、編集方法、コンピュータ読み取り可能な記録媒体 | |
| JP3327898B2 (ja) | 半導体メモリカード、再生装置、再生方法、コンピュータ読み取り可能な記録媒体 | |
| RU2259604C2 (ru) | Плата полупроводниковой памяти, устройство воспроизведения, устройство записи, способ воспроизведения, способ записи и считываемый посредством компьютера носитель информации | |
| JP2003162300A (ja) | 半導体メモリカードについての再生装置、コンピュータ読み取り可能な記録媒体、再生方法 | |
| RU2255382C2 (ru) | Плата полупроводниковой памяти, устройство воспроизведения, устройство записи, способ воспроизведения, способ записи и считываемый посредством компьютера носитель записи | |
| MXPA01000997A (en) | Semiconductor memory card, playback apparatus, recording apparatus, playback method, recording method, and computer-readable recording medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20070327 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20100202 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20100226 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4469125 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130305 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130305 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140305 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |