コンテンツデータ構造、コンテンツデータ記録媒体及びコンテンツデータ記録装置
【課題】 取り外し可能（リムーバブル）な記録媒体に記録されたオーディオデータなどのコンテンツデータの取扱いに係る利便性を向上させることができるコンテンツデータ構造、コンテンツデータ記録媒体及びコンテンツデータ記録装置を提供する。
【解決手段】 本発明に係るコンテンツデータ記録媒体は、複数のコンテンツデータのそれぞれが、個別ファイルとして記録されており、少なくともコンテンツデータ記録媒体上におけるコンテンツデータの位置及びサイズを示すリンク情報と、コンテンツデータの内容を記述し、個別ファイルの検索に用いられるメタデータと、リンク情報とメタデータとを含む管理ファイルとを有し、管理ファイルを用いて、コンテンツデータ記録媒体にアクセスするアクセス装置にコンテンツデータを検索させる。
【解決手段】 本発明に係るコンテンツデータ記録媒体は、複数のコンテンツデータのそれぞれが、個別ファイルとして記録されており、少なくともコンテンツデータ記録媒体上におけるコンテンツデータの位置及びサイズを示すリンク情報と、コンテンツデータの内容を記述し、個別ファイルの検索に用いられるメタデータと、リンク情報とメタデータとを含む管理ファイルとを有し、管理ファイルを用いて、コンテンツデータ記録媒体にアクセスするアクセス装置にコンテンツデータを検索させる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のコンテンツデータのそれぞれが、個別ファイルとして記録される場合におけるコンテンツデータ構造、コンテンツデータ記録媒体及びコンテンツデータ記録装置に関する。
【背景技術】
【０００２】
従来、ＣＤ−ＲやＤＶＤなど、取り外し可能（リムーバブル）な記録媒体（以下、“リムーバブル記録媒体”と適宜省略する）にオーディオデータなどのコンテンツデータを記録するためのフォーマットとして、ＵＤＦ（Universal Disk Format）が広く用いられている。
【０００３】
また、ＵＤＦを拡張して、リムーバブル記録媒体に記録されるコンテンツデータの知的財産権（例えば、著作権）を保護するためのアクセス制御など、セキュリティの確保に関する機能を提供するセキュアＵＤＦの規格も策定されている（非特許文献１参照）。
【非特許文献１】“セキュアＵＤＦ規格１．００版（Secure UDF Specification Revision 1．00）”、［ｏｎｌｉｎｅ］、２００２年２月２６日、オスタ（ＯＳＴＡ）、全文、［平成１６年１１月２６日検索］、インターネット＜URL：http://www.osta.org/specs/pdf/SecureUDF_1_00.pdf＞
【発明の開示】
【発明が解決しようとする課題】
【０００４】
上述したように、セキュアＵＤＦでは、暗号化など、セキュリティの確保に関する様々な仕様が規定されているが、リムーバブル記録媒体に記録されているコンテンツデータを取り扱う利用者の利便性については、さらに改善の余地があった。
【０００５】
そこで、本発明は、このような状況に鑑みてなされたものであり、取り外し可能（リムーバブル）な記録媒体に記録されたオーディオデータなどのコンテンツデータの取扱いに係る利便性を向上させることができるコンテンツデータ構造、コンテンツデータ記録媒体及びコンテンツデータ記録装置を提供することを目的とする。
【課題を解決するための手段】
【０００６】
上述した問題を解決するため、本発明は、次のような特徴を有している。まず、本発明の第１の特徴は、複数のコンテンツデータのそれぞれが、個別ファイルとして記録されるコンテンツデータ記録媒体において用いられるコンテンツデータ構造であって、少なくとも前記コンテンツデータ記録媒体上における前記コンテンツデータの位置及びサイズを示すリンク情報セグメントと、前記コンテンツデータの内容を記述し、前記個別ファイルの検索に用いられるメタデータセグメントと、前記リンク情報セグメントと前記メタデータセグメントとを含む管理ファイル領域とを有し、前記管理ファイル領域を用いて、前記コンテンツデータ記録媒体にアクセスするアクセス装置に前記コンテンツデータを検索させることを要旨とする。
【０００７】
本発明の第２の特徴は、本発明の第１の特徴に係り、前記管理ファイルセグメントには、前記アクセス装置に前記コンテンツデータの再生を許可するライセンス管理情報セグメントが含まれることを要旨とする。
【０００８】
本発明の第３の特徴は、複数のコンテンツデータ（例えば、ＭＣ３０１，３０２）のそれぞれが、個別ファイルとして記録されるコンテンツデータ記録媒体（リムーバブルＨＤＤ１１２６）であって、少なくとも前記コンテンツデータ記録媒体上における前記コンテンツデータの位置及びサイズを示すリンク情報（例えば、ＴＬ２０１〜２０Ｎ＋１）と、前記コンテンツデータの内容を記述し、前記個別ファイルの検索に用いられるメタデータ（例えば、ＭｅｔａＤａｔａストリームファイル）と、前記リンク情報と前記メタデータとを含む管理ファイル（例えば、ＡＵＤ＿ＳＥＴ．ＭＧＲ１２０）とを有し、前記管理ファイルを用いて、前記コンテンツデータ記録媒体にアクセスするアクセス装置（音楽レコーダ１０００）に前記コンテンツデータを検索させることを要旨とする。
【０００９】
本発明の第４の特徴は、本発明の第３の特徴に係り、前記管理ファイルには、前記アクセス装置に前記コンテンツデータの再生を許可するライセンス管理情報（例えば、*ＵＤＦ＿ＬＩＣＥＮＣＥセキュアストリームファイル）が含まれることを要旨とする。
【００１０】
本発明の第５の特徴は、複数のコンテンツデータのそれぞれが、個別ファイルとして記録されるコンテンツデータ記録装置（例えば、音楽レコーダ１０００）であって、少なくとも前記コンテンツデータ記録媒体上における前記コンテンツデータの位置及びサイズを示すリンク情報を生成するリンク情報生成部（制御部１１１６）と、前記コンテンツデータの内容を記述し、前記個別ファイルの検索に用いられるメタデータを取得するメタ情報取得部（制御部１１１６及びモデム１１２８）と、前記リンク情報と前記メタデータとを含む管理ファイルを生成する管理ファイル生成部（制御部１１１６）と、前記管理ファイルを用いて、前記コンテンツデータを検索するコンテンツ検索部（制御部１１１６）とを有することを要旨とする。
【００１１】
本発明の第６の特徴は、本発明の第５の特徴に係り、前記管理ファイルには、前記コンテンツデータの再生を許可するライセンス管理情報が含まれており、前記ライセンス管理情報に基づいて、前記コンテンツデータを再生するコンテンツ再生部（復号化処理部１１０８及び制御部１１１６）をさらに有することを要旨とする。
【００１２】
かかる特徴によれば、コンテンツデータ（例えば、音楽コンテンツなどのオーディオデータ）を利用するユーザは、リンク情報及びメタデータ（例えば、音楽コンテンツのタイトルやアーティスト名）とを含む管理ファイルを用いるため、コンテンツデータの検索、再生がさらに容易かつ速やかに行え、コンテンツデータの取扱いに係る利便性を向上させることができる。
【発明の効果】
【００１３】
本発明の特徴によれば、取り外し可能（リムーバブル）な記録媒体に記録されたオーディオデータなどのコンテンツデータの取扱いに係る利便性を向上させることができるコンテンツデータ構造、コンテンツデータ記録媒体及びコンテンツデータ記録装置を提供することができる。
【発明を実施するための最良の形態】
【００１４】
次に、本発明の実施形態の一例について、図面を参照しながら説明する。なお、以下の図面の記載において、同一または類似の部分には、同一または類似の符号を付している。
【００１５】
（本実施形態に係るコンテンツデータ構造）
まず、本実施形態に係るコンテンツデータ構造、具体的には、ハードディスクや、書き換え可能な光ディスク、メモリカードなどのリムーバブル記録媒体に音楽コンテンツ（オーディオデータ）を蓄積する場合に用いられるファイルフォーマットの概要、ディレクトリ構成、及び各ファイル構成について説明する。
【００１６】
（１） ファイルフォーマットの概要
図１は、本実施形態に係るファイルフォーマット（オーディオフォーマット）の概要を示している。“記録済音楽コンテンツ”（Recorded Music Contents、以下、ＭＣと省略する）は、リムーバブル記録媒体に蓄積される音楽コンテンツの実体である。
【００１７】
（１．１）記録済音楽コンテンツ（Recorded Music Contents）
ＭＣ３０１，３０２は、ＣＤをリッピングしたり、通信ネットワークを介して配信されたりしたコンテンツである。
【００１８】
ＭＣ３０１，３０２は、音楽でいうところの１曲で構成される場合、及び複数曲で構成される場合がある。いわゆる“音楽アルバム”という単位は、１つのＭＣで表現することも可能である。なお、“トラック”は、音楽１曲分で構成され、“音楽アルバム”は、複数の曲によって構成される。
【００１９】
また、ＭＣ３０１，３０２は、音楽コンテンツのみではなく、当該音楽コンテンツのメタデータ（曲のタイトルやアーティスト名など）を含む。
【００２０】
さらに、音楽コンテンツが暗号化されている場合には、ＭＣ３０１，３０２は、暗号化された当該音楽コンテンツを復号するための復号鍵や、当該音楽コンテンツの利用条件などが記載されたライセンスファイルとの関連性を示す情報を有する。なお、ＭＣ３０１，３０２に含まれる音楽コンテンツ（オーディオデータ）は、圧縮された状態でリムーバブル記録媒体に記録することも、もちろん可能である。
【００２１】
（１．２）トラックリンク（Track Link）
“トラックリンク”（Track Link、以下ＴＬと省略する）は、ＭＣの中の１曲へのリンク情報（トラックリンク情報）である。ＴＬ２０１〜２０Ｎ＋１によって、音楽コンテンツへの１曲単位のアクセスが可能となる。また、ＴＬ２０１〜２０Ｎ＋１は、ＭＣ３０１，３０２へのトラックリンク情報以外に、ＴＬのＩＤ、ユーザの検索・提示用のメタデータ、最後に再生された音楽コンテンツの位置を記録するリジューム情報、及び後述する“トラックグループ”からのリンク数を記録するリンクカウント情報などを有する。
【００２２】
（１．３）トラックグループ（Track Group）
“トラックグループ”（Track Group、以下ＴＧと省略する）は、ＴＬの集合体（ＴＬのリストで表現される）、またはＴＧの集合体（ＴＧのリストで表現される）である。
【００２３】
ＴＬの集合体によって表現されるＴＧ１０は、当該リストの順序に意味がある場合と、意味がない場合とに区別される。例えば、“音楽アルバム”や、ユーザが気に入った曲を集めた“プレイリスト”などは、リストの順序に意味がある。なお、“プレイリスト”は、ユーザが自由に作成可能であり、複数の曲のリストによって構成される。
【００２４】
一方、ＴＧ１０が、リムーバブル記録媒体に記録された全曲を管理する“基本トラックセット”である場合、リストの順序に意味がない。また、ＴＧの集合体で表現されるＴＧは、リストの順序に意味がない。当該ＴＧの使用例としては、プレイリストを集めたトッププレイリストなどがある。
【００２５】
ＴＧには、グループリストや、ＴＧのＩＤが記録される。また、リストの順序に意味がある場合、リジューム情報などが記録される。
【００２６】
（２）ディレクトリ・ファイル構成
図２は、本実施形態において用いられるディレクトリ及びファイルの構成（ファイルシステム）を示している。なお、本実施形態では、ファイルシステムとして、セキュアＵＤＦが使用される。
【００２７】
ＡＵＲ＿ＲＯＯＴディレクトリ１１０は、ＲＯＯＴディレクトリ１００の配下に位置し、音楽コンテンツ（オーディオデータ）をリムーバブル記録媒体に記録するアプリケーションのルートディレクトリ、つまり、オーディオフォーマット用のルートディレクトリである。
【００２８】
ＡＵＤ＿ＳＥＴ．ＭＧＲ１２０は、リムーバブル記録媒体に記録済みである全ての音楽コンテンツを管理するファイルである。なお、ＡＵＤ＿ＳＥＴ．ＭＧＲ１２０では、上述したＴＬやＴＧも管理される。
【００２９】
ＲＴ＿ＡＵＲＳディレクトリ１３０は、音楽コンテンツの実体が記録されているディレクトリである。具体的には、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイル１４０が音楽コンテンツの実体である。“ｘｘｘｘｘｘｘ”には、７桁（００００００００〜９９９９９９９まで）の数字（ＡＳＣＩＩコード）が記述される。
【００３０】
（３）ＡＵＤ＿ＳＥＴ．ＭＧＲの構成
図３は、ＡＵＤ＿ＳＥＴ．ＭＧＲの構成を示している。主ファイルであるＡＵＤ＿ＳＥＴ．ＭＧＲ１２０には、ＵＤＦによって定義されるストリームファイルがいくつか付属している。ＡＵＤ＿ＳＥＴ．ＭＧＲ１２０は、ユーザインタフェースへのエントリ情報、ＴＬ及びＴＧの管理情報を有する。
【００３１】
ＴｒａｃｋＬｉｎｋｓストリームファイルは、再生可能な状態の全てのトラックリンク情報を管理する。ＴＧ＿００００は、ＴｒａｃｋＬｉｎｋｓストリームファイルに記述されている全トラックを管理しているＴＧであり、リムーバブル記録媒体を使用する装置（例えば、コンテンツデータ記録装置）によってメンテナンスが実行される。
【００３２】
ＰＲＴＬｓストリームファイルは、再生可能な状態にない全てのトラックリンク情報を管理している。ＴＧ＿９９９９は、ＰＲＴＬｓに記述されている全トラックを管理しているＴＧであり、プリセットモデルの場合にのみ存在する。ＴＧ＿ｘｘｘｘは、ユーザあるいは機器が自由に定義できるＴＧである。ｘｘｘｘは、４桁（００００〜９９９９まで）の数字（ＡＳＣＩＩコード）が記述される。なお、プリセットモデルの内容については、後述する。
【００３３】
（３．１）ＡＵＤ＿ＳＥＴ．ＭＧＲファイル
主ファイルであるＡＵＤ＿ＳＥＴ．ＭＧＲ１２０は、表１に示すようなモジュールの列、すなわち、（ｉ）ユーザインタフェースエントリ情報、（ｉｉ）トラックリンク管理情報、及び（ｉｉｉ）トラックグループ管理情報によって構成される。
【表１】
【００３４】
（３．１．１）ユーザインタフェースエントリ情報
ユーザインタフェースエントリ情報は、表２に示すようなエントリ構造を有する。
【表２】
【００３５】
“Ａｕｄｉｏ Ｆｏｒｍａｔ Ｉｄｅｎｔｉｆｉｅｒ”には、ＡＳＣＩＩコードによって、“ＡＵＤＩＯ”と記述される。“Ｂｏｏｋ Ｖｅｒｓｉｏｎ”には、ブックのバージョンが記述される。バージョン１．０の場合は、“０ｘ１０”と記述する。
【００３６】
“Ｆｌａｇ”は、表３に示すような構造を有する。
【表３】
【００３７】
“Ｒｅｓｅｒｖｅｄ”（ｂｉｔ７〜１）は、将来のためにリザーブされているビットであり、０ｂに設定される。“Ｐｒｅｓｅｔ”（ｂｉｔ０）は、プリセットモデルなどにおいて、ライセンスを購入していない音楽コンテンツが存在する場合には１ｂ、当該音楽コンテンツが存在しない場合には０ｂに設定される。
【００３８】
“Ｌａｓｔ Ａｃｃｅｓｓｅｄ ＵＩＥ ＴＧ＿ＩＤ”（表２参照）には、最後にアクセスしたＴＧのＩＤが記述される。Ｌａｓｔ Ａｃｃｅｓｓｅｄ ＵＩＥ ＴＧ＿ＩＤは、リジュームポイント（Ｒｅｓｕｍｅ Ｐｏｉｎｔ）に使用される。
【００３９】
“Ｒｅｓｕｍｅ Ｓｕｐｐｏｒｔ Ｆｌａｇ”は、表４に示すような構造を有する。
【表４】
【００４０】
“Ｒｅｓｅｒｖｅｄ”（ｂｉｔ７〜１）は、将来のためにリザーブされているビットであり、０ｂに設定される。“Ｒｅｓｕｍｅ”（ｂｉｔ０）は、リジューム機能をサポートしている機器では１ｂ、リジューム機能をサポートしていない機器では０ｂと記述される。
【００４１】
“Ｌａｓｔ Ａｃｃｅｓｓｅｄ ＵＩＥ ＴＧ＿ＩＤ ｒｅｃｏｒｄｅｄ Ｄａｔｅ”（表２参照）には、最後にアクセスしたＴＧのＩＤが記録された時刻が記述される。“ＴＩＭＥ”フォーマットは、１４バイト分のＡＳＣＩＩコードによって、次のように表現される。すなわち、西暦４桁、月２桁、日２桁、時２桁（２４時間表示）、分２桁、及び秒２桁で表現される。タイマーを有しない機器の場合では、オール０に設定される。
【００４２】
“Ｎｕｍｂｅｒ ｏｆ ＵＩＥ ＴＧｓ”には、ＡＵＤ＿ＳＥＴ．ＭＧＲ１２０の配下に位置するユーザインタフェースのエントリとなる最上位ＴＧのＩＤの総数が記述される。
【００４３】
“ＵＩＥ ＴＧ＿ＩＤ（１） ｆｏｒ Ｂａｓｅ Ｔｒａｃｋ Ｓｅｔ”には、１番目のＵＩＥ ＴＧ＿ＩＤが記述される。具体的には、ＡＳＣＩＩコードで００００が記述される。当該ＵＩＥ ＴＧ＿ＩＤは、ストリームファイルＴＧ＿００００に対応している。ＵＩＥ ＴＧ＿ＩＤは、ストリームファイルＴＧ＿ｘｘｘｘのうち、ｘｘｘｘに対応する。ＴＧ＿００００は、全トラックを管理するＴＧとして必ず存在する。
【００４４】
“ＵＩＥ ＴＧ＿ＩＤ（１） Ｎａｍｅ”には、ＡＳＣＩＩコードでＵＩＥ ＴＧ＿ＩＤ（１）の名前が記述される。すなわち、対応するＴＧ構造体のＴＧ Ｓｐｅｃｉｆｉｃ Ｓｔｒｕｃｔｕｒｅ Ｎａｍｅがコピーされる。具体的には、ＵＩＥ ＴＧ＿ＩＤ（１） Ｎａｍｅ”には、ＴｒａｃｋＳｅｔＢａｓｅと記述される。
【００４５】
“ＵＩＥ ＴＧ＿ＩＤ（２）”には、２番目のＵＩＥ ＴＧ＿ＩＤが記述される。具体的には、４桁の数字がＡＳＣＩＩコードで記述される。４桁の数字は、ストリームファイルＴＧ＿ｘｘｘｘに対応している。
【００４６】
“ＵＩＥ ＴＧ＿ＩＤ（２） Ｎａｍｅ”には、“ＵＩＥ ＴＧ＿ＩＤ（１） Ｎａｍｅ”と同様に、ＡＳＣＩＩコードでＵＩＥ ＴＧ＿ＩＤ（２）の名前が記述される。
【００４７】
“ＵＩＥ ＴＧ＿ＩＤ（ｎ）”には、ｎ番目のＵＩＥ ＴＧ＿ＩＤが記述される。具体的には、４桁の数字がＡＳＣＩＩコードで記述される。４桁の数字は、ストリームファイルＴＧ＿ｘｘｘｘに対応している。また、“ＵＩＥ ＴＧ＿ＩＤ（ｎ） Ｎａｍｅ”には、“ＵＩＥ ＴＧ＿ＩＤ（１） Ｎａｍｅ”と同様に、ＡＳＣＩＩコードでＵＩＥ ＴＧ＿ＩＤ（ｎ）の名前が記述される。
【００４８】
（３．１．２）トラックリンク管理情報
トラックリンク管理情報は、表５に示すようなエントリ構造を有する。
【表５】
【００４９】
“Ｔｒａｃｋ Ｌｉｎｋ Ｌｏｃａｔｉｏｎ”には、ＴＬが記録されるファイル名（ＴｒａｃｋＬｉｎｋｓ）が、ＡＳＣＩＩコードで記述される。
【００５０】
“Ｐｒｅｒｅｃｏｒｄｅｄ Ｔｒａｃｋ Ｌｉｎｋ Ｌｏｃａｔｉｏｎ”には、リムーバブル記録媒体の購入時から記録されているＴＬが記録されるファイル名が、ＡＳＣＩＩコードで記述される。“Ｐｒｅｒｅｃｏｒｄｅｄ Ｔｒａｃｋ Ｌｉｎｋ Ｌｏｃａｔｉｏｎ”は、プリセットモデルにおいて使用される。プリセットモデルの場合、“Ｐｒｅｒｅｃｏｒｄｅｄ Ｔｒａｃｋ Ｌｉｎｋ Ｌｏｃａｔｉｏｎ”には、ＰＲＴＬｓと記述される。プリセットモデル以外では、“Ｐｒｅｒｅｃｏｒｄｅｄ Ｔｒａｃｋ Ｌｉｎｋ Ｌｏｃａｔｉｏｎ”は、無視される。
【００５１】
（３．１．３）トラックグループ管理情報
トラックグループ管理情報は、表６に示すようなエントリ構造を有する。
【表６】
【００５２】
“Ｎｕｍｂｅｒ ｏｆ Ｔｒａｃｋ Ｇｒｏｕｐｓ”には、ＴＧの総数が記述される。“Ｍａｘｉｍｕｍ Ｔｒａｃｋ Ｇｒｏｕｐ ＩＤ”には、ＴＧ＿ＩＤの最大値が記述される。具体的には、４桁の数字がＡＳＣＩＩコードで記述される。ただし、“９９９９”は、プリセットモデル用として割り当てられるため、当該最大値として考慮しない。
【００５３】
（３．２）ＴｒａｃｋＬｉｎｋｓストリームファイル・ＰＲＴＬｓストリームファイル
ＴｒａｃｋＬｉｎｋｓストリームファイル及びＰＲＴＬｓストリームファイルは、表７に示すような構造を有する。
【表７】
【００５４】
“Ｎｕｍｂｅｒ ｏｆ Ｔｒａｃｋ Ｌｉｎｋｓ”には、ＴｒａｃｋＬｉｎｋｓストリームファイルまたはＰＲＴＬｓストリームファイルに含まれているＴＬの総数が記述される。“Ｎｕｍｂｅｒ ｏｆ Ｖａｌｉｄ Ｔｒａｃｋ Ｌｉｎｋｓ”には、ＴｒａｃｋＬｉｎｋｓストリームファイル及びＰＲＴＬｓストリームファイルに含まれているＴＬの中で有効なＴＬ数が記述される。
【００５５】
“Ｔｒａｃｋ Ｌｉｎｋ Ｉｎｆｏｒｍａｔｉｏｎ（１）〜（ｎ）”は、ＴＬ構造体がｎ個並んだ構造である。ｎは、“Ｎｕｍｂｅｒ ｏｆ Ｔｒａｃｋ Ｌｉｎｋｓ”フィールドの数値である。ＴＬのＩＤは、表７に示したように、“１”から昇順で割り当てられる。
【００５６】
なお、本実施形態では、ＴｒａｃｋＬｉｎｋｓストリームファイルのＴＬのＩＤは、ＴＬ＿ＩＤと表記され、ＰＲＴＬｓストリームファイルのＴＬのＩＤは、ＰＲＴＬ＿ＩＤと表記される。
【００５７】
（３．２．１）ＴＬ構造体
ＴＬ構造体は、表８に示すような構造を有する。
【表８】
【００５８】
“ＴＬ ＴＹＰＥ”には、ＴＬ Ｓｐｅｃｉｆｉｃな構造体のＴＹＰＥ（表９参照）が記述される。なお、本実施形態では、日本方式（ＴＹＰＥ１）が定義されている。
【表９】
【００５９】
“Ｌｅｎｇｔｈ ｏｆ Ｓｔｒｕｃｔｕｒｅ”（表８参照）には、ＴＬ構造体の長さ（バイト数）が記述される。
【００６０】
“ＴＬ Ｆｌａｇ”は、表１０に示すような構造を有する。
【表１０】
【００６１】
“Ｖ（ｂｉｔ７）”には、ＴＬ構造体が有効であるか否かを示す情報が記述される。具体的には、ＴＬ構造体が有効である場合、“Ｖ（ｂｉｔ７）”は、１ｂに設定される。ＴＬ構造体が無効である場合、“Ｖ（ｂｉｔ７）”は、０ｂに設定される。“Ｖ（ｂｉｔ７）”は、ＴＬ構造体の簡易消去に利用される。
【００６２】
“Ｒｅｓｅｒｖｅｄ（ｂｉｔ６〜３）”は、将来のためにリザーブされているビットであり、０ｂに設定される。“ＰＳ（ｂｉｔ２）”では、プリセットモデルに係る曲へのリンクの場合には１ｂ、そうでない場合には０ｂが設定される。
【００６３】
“ＰＥ（ｂｉｔ１）”では、再生可能な曲へのリンクの場合、つまり、その曲のライセンスを有している場合、またはその曲が暗号化されてない場合には１ｂ、再生が不可能な場合、つまり、その曲が暗号化されており、その曲のライセンスを有していない場合には０ｂが設定される。
【００６４】
“Ｐａｒｔ（ｂｉｔ０）”では、ＭＣとして複数曲が記録されている場合であって、その一部を指定する場合には、１ｂに設定される。ＭＣが１曲の場合には、０ｂとに設定される。“Ｐａｒｔ（ｂｉｔ０）”が１ｂのときに限って、“Ｓｔａｒｔ Ｐｏｉｎｔ ｉｎ Ｃｏｎｔｅｎｔｓ Ｆｉｌｅ”及び“Ｃｏｎｔｅｎｔ Ｌｅｎｇｔｈ”フィールドが有効となる。
【００６５】
“Ｌｉｎｋ Ｃｏｕｎｔ”（表８参照）には、ＴＧからリンクされているリンク総数が記述される。“Ｍｕｓｉｃ Ｃｏｎｔｅｎｔｓ ＩＤ”には、Ｍｕｓｉｃ Ｃｏｎｔｅｎｔｓ ＩＤが記述される。具体的には、コンテンツファイルのＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルのｘｘｘｘｘｘｘに相当する数字がＡＳＣＩＩコードで記述される。
【００６６】
“Ｓｔａｒｔ Ｐｏｉｎｔ ｉｎ Ｃｏｎｔｅｎｔｓ Ｆｉｌｅ”では、音楽コンテンツファイルのリンク開始位置が、当該ファイルの先頭からのバイト位置によって指定される。“Ｃｏｎｔｅｎｔ Ｌｅｎｇｔｈ”には、音楽コンテンツファイルへのリンク範囲（バイト長）が記述される。上述したように、ＴＬ＿ＦｌａｇのＰａｒｔビット（表１０参照）が１ｂの場合にのみ、“Ｓｔａｒｔ Ｐｏｉｎｔ ｉｎ Ｃｏｎｔｅｎｔｓ Ｆｉｌｅ”及びＣｏｎｔｅｎｔ Ｌｅｎｇｔｈ”フィールドが有効となる。
【００６７】
“Ｌａｓｔ Ａｃｃｅｓｓｅｄ Ｔｉｍｅ”には、最後に再生された音楽コンテンツファイルへのアクセス時刻が記録される。“Ｒｅｓｕｍｅ Ｐｏｉｎｔ”では、音楽コンテンツファイル（ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイル）の再生開始位置が、当該ファイルの先頭からのバイト位置によって指定される。
【００６８】
“Ｐｌａｙｂａｃｋ Ｃｏｕｎｔｅｒ”には、再生開始を指示した回数が記述される。なお、“Ｐｌａｙｂａｃｋ Ｃｏｕｎｔｅｒ”フィールドに記述される回数には、リジュームによる再生は含まない。“Ｍｙ Ｒａｔｉｎｇ Ｉｎｆｏ”には、ユーザによって入力される１０段階の重み付け情報が記述される。
【００６９】
“Ｃｈａｒａｃｔｅｒ Ｓｅｔ ｏｆ Ｍｅｔａｄａｔａ”では、メタデータフィールドの文字コード（表１１参照）が定義される。
【表１１】
【００７０】
“Ｔｉｔｌｅ（ＭｅｔａＤａｔａ、以下ＭＤ）”（表８参照）には、トラックタイトルが記述される。文字コードは、“Ｃｈａｒａｃｔｅｒ Ｓｅｔ ｏｆ Ｍｅｔａｄａｔａ”フィールドにおいて指定されたものが使用される。トラックタイトルの終端は、ＮＵＬＬ文字を格納することによって行われる。
【００７１】
“Ｔｉｔｌｅカナ（ＭＤ）”には、トラックタイトルの検索用カナが、全角カタカナによって記述される。文字コードは、“Ｃｈａｒａｃｔｅｒ Ｓｅｔ ｏｆ Ｍｅｔａｄａｔａ”フィールドにおいて指定されたものが使用される。トラックタイトルの終端は、ＮＵＬＬ文字を格納することによって行われる。
【００７２】
“Ａｒｔｉｓｔ Ｎａｍｅ（ＭＤ）”には、アーティスト名が記述される。文字コードは、“Ｃｈａｒａｃｔｅｒ Ｓｅｔ ｏｆ Ｍｅｔａｄａｔａ”フィールドにおいて指定されたものが使用される。トラックタイトルの終端は、ＮＵＬＬ文字を格納することによって行われる。
【００７３】
“Ａｒｔｉｓｔ Ｎａｍｅカナ（ＭＤ）”には、アーティスト名の検索用カナが、全角カタカナによって記述される。文字コードは、“Ｃｈａｒａｃｔｅｒ Ｓｅｔ ｏｆ Ｍｅｔａｄａｔａ”フィールドにおいて指定されたものが使用される。トラックタイトルの終端は、ＮＵＬＬ文字を格納することによって行われる。
【００７４】
“Ｇｅｎｒｅ（ＭＤ）”には、ジャンルが記述される。文字コードは、“Ｃｈａｒａｃｔｅｒ Ｓｅｔ ｏｆ Ｍｅｔａｄａｔａ”フィールドにおいて指定されたものが使用される。トラックタイトルの終端は、ＮＵＬＬ文字を格納することによって行われる。
【００７５】
“Ｇｅｎｒｅカナ（ＭＤ）”には、ジャンルの検索用カナが、全角カタカナによって記述される。文字コードは、“Ｃｈａｒａｃｔｅｒ Ｓｅｔ ｏｆ Ｍｅｔａｄａｔａ”フィールドにおいて指定されたものが使用される。トラックタイトルの終端は、ＮＵＬＬ文字を格納することによって行われる。
【００７６】
“Ｃｏｍｐｏｓｅｒ（ＭＤ）”には、作曲者名が、全角カタカナによって記述される。文字コードは、“Ｃｈａｒａｃｔｅｒ Ｓｅｔ ｏｆ Ｍｅｔａｄａｔａ”フィールドにおいて指定されたものが使用される。トラックタイトルの終端は、ＮＵＬＬ文字を格納することによって行われる。
【００７７】
“Ａｌｂｕｍ Ｔｉｔｌｅ（ＭＤ）”には、音楽アルバム（ＣＤ）のタイトルが、全角カタカナによって記述される。文字コードは、“Ｃｈａｒａｃｔｅｒ Ｓｅｔ ｏｆ Ｍｅｔａｄａｔａ”フィールドにおいて指定されたものが使用される。トラックタイトルの終端は、ＮＵＬＬ文字を格納することによって行われる。
【００７８】
“Ｔｒａｃｋ Ｎｕｍｂｅｒ ｉｎ ＣＤ（ＭＤ）”では、音楽アルバムの場合におけるトラック番号が記述される。
【００７９】
（３．３）ＴＧ＿ｘｘｘｘストリームファイル
ＴＧ＿ｘｘｘｘストリームファイルは、表１２に示すような構造を有する。
【表１２】
【００８０】
“ＴＧ Ｓｐｅｃｉｆｉｃ Ｓｔｒｕｃｔｕｒｅ ＴＹＰＥ”には、ＴＧ Ｓｐｅｃｉｆｉｃな構造体のＴＹＰＥ（表１３参照）が記述される。
【表１３】
【００８１】
“ＴＧ Ｆｌａｇ”は、表１４に示すような構造を有する。
【表１４】
【００８２】
“Ｒｅｓｅｒｖｅｄ（ｂｉｔ７〜２）”は、将来のためにリザーブされているビットであり、０ｂに設定される。なお、このビットは、文字コードの識別情報用として使用される予定である。
【００８３】
“ＴＬ/ＴＧ（ｂｉｔ１）”では、ＴＬのリストの場合には１ｂ、ＴＧのリストの場合には０ｂに設定される。“Ｓ/Ｇ（ｂｉｔ０）”では、リストの順序が再生順である場合には１ｂ、再生順でない場合には０ｂに設定される。
【００８４】
“ＴＧ Ｓｐｅｃｉｆｉｃ Ｓｔｒｕｃｔｕｒｅ Ｎａｍｅ”（表１２参照）には、ＴＧ Ｓｐｅｃｉｆｉｃな構造体の名前が、ＡＳＣＩＩコードで記述される。“Ｌｉｎｋ Ｃｏｕｎｔ”には、ＴＧからリンクされているリンク総数が記述される。なお、ユーザインタフェースエントリ情報から参照されている場合も、リンク数１としてカウントされる。
【００８５】
“Ｒｅｓｕｍｅ ｅｌｅｍｅｎｔ”には、リジュームのエレメントの番号が記述される。当該番号は、ｅｌｅｍｅｎｔ ＩＤ（ｘ）のｘに相当する番号である。“Ｒｅｓｕｍｅ ｅｌｅｍｅｎｔ”は、ＴＧ＿ＦｌａｇのＳ／Ｇビットが１の場合にのみ有効となる。
【００８６】
“ＴＧ Ｓｐｅｃｉｆｉｃ Ｓｔｒｕｃｔｕｒｅ ＴＹＰＥ Ｓｐｅｃｉｆｉｃ Ａｒｅａ”は、ＴＧ Ｓｐｅｃｉｆｉｃな構造体に依存した構造を定義するための領域である。“Ｎｕｍｂｅｒ ｏｆ ｅｌｅｍｅｎｔｓ”には、ＴＧに属するｅｌｅｍｅｎｔの総数が記述される。“ｅｌｅｍｅｎｔ ＩＤ（１）〜（ｎ）”には、各ｅｌｅｍｅｎｔ ＩＤが記述される。
【００８７】
“ｅｌｅｍｅｎｔ ＩＤ（１） Ｎａｍｅ〜ｅｌｅｍｅｎｔ ＩＤ（ｎ） Ｎａｍｅ”には、ｅｌｅｍｅｎｔ ＩＤの名前が記述される。
【００８８】
（３．３．１）ＴＧ＿００００ストリームファイル
ＴＧ＿００００ストリームファイルは、ＴｒａｃｋＬｉｎｋｓストリームファイルによって管理されているＴＬを管理するＴＧである。上述したＴＧ＿ｘｘｘｘ構造体（ＴＧ＿ｘｘｘｘストリームファイル）で定義されるが、次のような制約がある。
【００８９】
・ ＴＧ Ｓｐｅｃｉｆｉｃ Ｓｔｒｕｃｔｕｒｅ ＴＹＰＥ ＝ ０ｘ００
・ ＴＧ Ｆｌａｇ ＝ ０ｘ２
・ ＴＧ Ｓｐｅｃｉｆｉｃ Ｓｔｒｕｃｔｕｒｅ Ｎａｍｅ ＝ Ｔｒａｃｋ＿Ｂａｓｅ
・ Ｌｉｎｋ Ｃｏｕｎｔ ＝ ０
・ Ｎｕｍｂｅｒ ｏｆ ｅｌｅｍｅｎｔｓ： ＴｒａｃｋＬｉｎｋｓストリームファイルによって管理されている有効なＴＬ数と一致する
・ ｅｌｅｍｅｎｔ ＩＤ（１）〜（ｎ）： ＴＬ＿ＩＤが記述される
（３．３．２）ＴＧ＿９９９９ストリームファイル
ＴＧ＿９９９９ストリームファイルは、プリセットモデルの場合にのみ、初期状態において存在し、ＰＲＴＬｓストリームファイルによって管理されているＴＬを管理するＴＧである。上述したＴＧ＿ｘｘｘｘ構造体（ＴＧ＿ｘｘｘｘストリームファイル）で定義されるが、次のような制約がある。
【００９０】
・ ＴＧ Ｓｐｅｃｉｆｉｃ Ｓｔｒｕｃｔｕｒｅ ＴＹＰＥ ＝ ０ｘＦＦ
・ ＴＧ Ｆｌａｇ ＝ ０ｘ２
・ ＴＧ Ｓｐｅｃｉｆｉｃ Ｓｔｒｕｃｔｕｒｅ Ｎａｍｅ ＝ Ｐｒｅｓｅｔ＿Ｔｒａｃｋ＿Ｂａｓｅ
・ Ｌｉｎｋ Ｃｏｕｎｔ ＝ ０
・ Ｎｕｍｂｅｒ ｏｆ ｅｌｅｍｅｎｔｓ： ＰＲＴＬｓストリームファイルによって管理されている有効なＴＬ数と一致する
・ ｅｌｅｍｅｎｔ ＩＤ（１）〜（ｎ）： ＰＲＴＬ＿ＩＤが記述される
（３．３．３）ＴＧ＿ｘｘｘｘストリームファイル
ＴＧ＿ｘｘｘｘストリームファイルは、ＴＬのリストまたはＴＧのリストによって表現される。ＴＬのリストで表現される場合は、ｅｌｅｍｅｎｔ＿ＩＤには、ＴｒａｃｋＬｉｎｋｓストリームファイルによって管理されているＴＬ＿ＩＤが記述されなければならない。なお、ＰＲＴＬｓストリームファイルのＰＲＴＬ＿ＩＤは、参照することができない。
【００９１】
（４）ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルの構成
図４は、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルの構成を示している。同図に示すように、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイル１４０は、ＡｕｄｉｏＤａｔａストリームファイル（ＡｕｄｉｏＤａｔａ）、ＭｅｔａＤａｔａストリームファイル（ＭｅｔａＤａｔａ）、及び*ＵＤＦ＿ＬＩＣＥＮＣＥセキュアストリームファイル（*ＵＤＦ＿ＬＩＣＥＮＣＥ）によって構成されている。
【００９２】
（４．１）ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイル
主ファイルであるＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイル１４０は、表１５に示すようなモジュールの列、すなわち、（ｉ）オーディデータ管理情報、（ｉｉ）メタデータ管理情報、及び（ｉｉｉ）ライセンス管理情報によって構成される。
【表１５】
【００９３】
（４．１．１）オーディデータ管理情報
オーディデータ管理情報は、表１６に示すようなエントリ構造を有する。
【表１６】
【００９４】
“Ｎｕｍｂｅｒ ｏｆ Ｔｒａｃｋｓ”には、ＡｕｄｉｏＤａｔａストリームファイルに記録されているトラック数が記述される。
【００９５】
“ＡＵＤ Ｆｌａｇ”は、表１７に示すような構造を有する。
【表１７】
【００９６】
“Ｒｅｓｅｒｖｅｄ（ｂｉｔ７〜１）”は、将来のためにリザーブされているビットであり、０ｂに設定される。“Ｅｎｃ（ｂｉｔ０）”には、ＡｕｄｉｏＤａｔａストリームファイルのＴｒａｃｋ Ｄａｔａ部分が暗号化されている場合には１ｂ、暗号化されていない場合には０ｂに設定される。
【００９７】
“Ｐｌａｙｂａｃｋ Ｔｉｍｅ”（表１６参照）には、全トラックの再生時間が記述される。“Ｆｉｌｅ Ｓｉｚｅ”には、ＡｕｄｉｏＤａｔａストリームファイルのファイルサイズが記述される。“Ａｕｄｉｏ Ｆｏｒｍａｔ（Ｃｏｄｅｃ）”には、Ａｕｄｉｏ Ｆｏｒｍａｔ（表１８参照）が記述される。
【表１８】
【００９８】
“Ｂｉｔ Ｒａｔｅ”（表１６参照）には、ビットレート（単位：ｋｂｐｓ）が記述される。“Ｆｉｌｅ Ｃｒｅａｔｅ Ｄａｔｅ”には、ファイル作成日が記述される。“Ａｕｄｉｏ Ｆｉｌｅ Ｌｏｃａｔｉｏｎ”には、オーディオデータが記録されるファイル名が、ＡＳＣＩＩコードで記述（ＡｕｄｉｏＤａｔａと記述）される。
【００９９】
（４．１．２）メタデータ管理情報
メタデータ管理情報は、表１９に示すような構造を有する。
【表１９】
【０１００】
“Ｃｈａｒａｃｔｅｒ Ｓｅｔ ｉｎ Ｍｅｔａｄａｔａ Ｆｉｌｅ”では、ＭｅｔａＤａｔａストリームファイルの文字コード（表２０参照）が定義される。
【表２０】
【０１０１】
“ＭｅｔａＤａｔａ Ｆｏｒｍａｔ”には、ＴＧ Ｓｐｅｃｉｆｉｃな構造体のＴＹＰＥ（表２１参照）が記述される。
【表２１】
【０１０２】
“ＭｅｔａＤａｔａ Ｆｉｌｅ Ｌｏｃａｔｉｏｎ”（表１９参照）には、メタデータが記録されるファイル名が、ＡＳＣＩＩコードで記述（ＭｅｔａＤａｔａと記述）される。
【０１０３】
（４．１．３）ライセンス管理情報
ライセンス管理情報は、表２２に示すような構造を有する。
【表２２】
【０１０４】
“Ｌｉｃｅｎｓｅ Ｆｌａｇ”は、表２３に示すような構造を有する。
【表２３】
【０１０５】
“Ｒｅｓｅｒｖｅｄ（ｂｉｔ７〜２）”は、将来のためにリザーブされているビットであり、０ｂに設定される。
【０１０６】
“ＰＳ（ｂｉｔ１）”では、プリセットモデルの場合には１ｂ、そうでない場合には０ｂが設定される。“ＬＥ（ｂｉｔ０）”では、ライセンスが存在する場合には１ｂ、存在しない場合には０ｂに設定される。
【０１０７】
“Ｌｉｃｅｎｓｅ Ｆｉｌｅ Ｌｏｃａｔｉｏｎ”（表２２参照）には、ライセンス（復号鍵及び利用条件）が記録されるファイル名がＡＳＣＩＩコードで記述される。具体的には、Ｌｉｃｅｎｓｅ ＦｌａｇのＬＥビットが１ｂの場合のみ、*ＵＤＦ＿ＬＩＣＥＮＳＥと記述される。
【０１０８】
（４．２）ＡｕｄｉｏＤａｔａストリームファイル
ＡｕｄｉｏＤａｔａストリームファイルは、表２４に示すようなモジュールの列、すなわち、（ｉ）Ａｕｄｉｏ Ｄａｔａ Ｈｅａｄｅｒ及び（ｉｉ）Ｔｒａｃｋ Ｄａｔａによって構成される。
【表２４】
【０１０９】
（４．２．１）Ａｕｄｉｏ Ｄａｔａ Ｈｅａｄｅｒ
Ａｕｄｉｏ Ｄａｔａ Ｈｅａｄｅｒは、表２５に示すようなエントリ構造を有する。なお、Ａｕｄｉｏ Ｄａｔａ Ｈｅａｄｅｒは、暗号化の対象とならない。
【表２５】
【０１１０】
“Ｌｅｎｇｔｈ ｏｆ Ａｕｄｉｏ Ｄａｔａ Ｈｅａｄｅｒ”には、Ａｕｄｉｏ Ｄａｔａ Ｈｅａｄｅｒ長（バイト数）が記述される。“Ｎｕｍｂｅｒ ｏｆ Ｔｒａｃｋｓ”には、ＡｕｄｉｏＤａｔａストリームファイルに記録されているトラック数が記述される。“Ｌｅｎｇｔｈ ｏｆ Ｔｒａｃｋ Ｄａｔａ（＃１）〜（＃ｎ）には、Ｔｒａｃｋ Ｄａｔａ長（バイト数）が記述される。
【０１１１】
（４．２．２）Ｔｒａｃｋ Ｄａｔａ
Ｔｒａｃｋ Ｄａｔａには、Ａｕｄｉｏ Ｆｏｒｍａｔに準じたデータが記録される。なお、Ｔｒａｃｋ Ｄａｔａは、暗号化されている場合もある。
【０１１２】
（４．３）ＭｅｔａＤａｔａストリームファイル
ＭｅｔａＤａｔａストリームファイルは、表２６に示すような構造を有する。
【表２６】
【０１１３】
（４．４）*ＵＤＦ＿ＬＩＣＥＮＣＥセキュアストリームファイル
*ＵＤＦ＿ＬＩＣＥＮＣＥセキュアストリームファイルには、ライセンス（復号鍵及び利用条件）が記述されている。アプリケーションは、*ＵＤＦ＿ＬＩＣＥＮＣＥセキュアストリームファイルが存在すれば、暗号化されたＡｕｄｉｏＤａｔａストリームファイルを復号できる。
【０１１４】
（音楽コンテンツ管理モデル構成例）
次に、上述した本実施形態に係るコンテンツデータ構造を用いた音楽コンテンツの管理モデル構成例について説明する。
【０１１５】
（１）構成例１
図５は、“Ｔｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＴＢ）”を用いたモデル構成例を示している。
【０１１６】
Ｔｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＴＢ）は、視聴可能状態で記録されたトラックの全リストを管理しているＴＧである。なお、音楽コンテンツ（ＭＣ３０１，３０２）が暗号化されている場合には、復号するためのライセンスが必要となる。
【０１１７】
Ｔｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＴＢ）は、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの配下において、ＴＧ＿００００ストリームファイルとして存在する。Ｔｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＴＢ）は、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの配下において、ＴｒａｃｋＬｉｎｋｓストリームファイルとして管理されている全てのＴＬ（ＴＬ２０１〜２０Ｎ＋１）を管理する。
【０１１８】
（２）構成例２
図６は、Ｐｒｅｓｅｔ＿Ｔｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＰＴＢ）を用いたモデル構成例を示しているＰｒｅｓｅｔ＿Ｔｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＰＴＢ）は、“プリセットモデル”の場合にのみ存在するファイル（ＴＧ）である。
【０１１９】
プリセットモデルとは、暗号化された音楽コンテンツ（ＭＣ３０３，３０４）をリムーバブル記録媒体に記録した状態でユーザに販売し、ユーザは、表示されるリストの中から気に入ったトラックを購入するというビジネスモデルである。
【０１２０】
プリセットモデルでは、ユーザは、気に入ったトラックの購入時に暗号化された音楽コンテンツ（ＭＣ３０３，３０４）を復号するためのライセンスのみを取得すれば良い。このため、ユーザは、気に入ったトラック（音楽コンテンツ）をサーバなどからダウンロードする必要がなく、速やかに音楽コンテンツを購入できる。
【０１２１】
また、プリセットモデルでは、暗号化された音楽コンテンツ（ＭＣ３０３，３０４）は、視聴可能な音楽コンテンツと同様にＲＴ＿ＡＵＲＳディレクトリ１３０の配下に位置するＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイル１４０（図２参照）に記録される。ただし、当初は、ライセンス（*ＵＤＦ＿ＬＩＣＥＮＣＥセキュアストリームファイル）がない状態であるため、そのままでは、暗号化された音楽コンテンツ（ＭＣ３０３，３０４）は、再生することができない。
【０１２２】
ＴＬ２１１〜２１Ｎ＋１は、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの配下において、ＰＲＴＬｓストリームファイルとして管理され、視聴可能な音楽コンテンツを管理しているＴｒａｃｋＬｉｎｋｓストリームファイルとは別に管理される。
【０１２３】
さらに、プリセットモデルでは、視聴が不可能な状態で記録された、つまり、復号するためのライセンスを有していないトラックの全リストを管理しているＴＧが、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの配下において、ＴＧ＿９９９９ストリームファイルとして存在する。
【０１２４】
ＴＧ＿９９９９ストリームファイルは、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの配下に位置するＰＲＴＬｓストリームファイルとして管理されている全てのＴＬを管理する。ＰＲＴＬｓストリームファイルとして管理されているＴＬは、ユーザが定義するＴＧからリンクすることができないという制限を有する。
【０１２５】
ユーザが、暗号化された音楽コンテンツのライセンスを取得（購入）した場合、当該ＭＣに対応するＴＬは、ＰＲＴＬｓストリームファイルから削除され、ＴｒａｃｋＬｉｎｋｓストリームファイルに追加される。
【０１２６】
図７及び図８は、ユーザが、暗号化された音楽コンテンツのライセンスを取得（購入）した場合に、当該ＭＣに対応するＴＬが、ＰＲＴＬｓストリームファイルから削除され、ＴｒａｃｋＬｉｎｋｓストリームファイルに追加される様子を示している。
【０１２７】
図７は、ライセンス（復号鍵及び利用条件）の取得前における音楽コンテンツの管理状態を示している。図７に示すように、ＭＣ３０３，３０４については、ライセンスが取得済み（図において、“Ｌｉｃｅｎｃｅ”と表記されている）である。一方、ＭＣ３０１，３０２，３０Ｍについては、ライセンスがまだ取得されていない状態である。
【０１２８】
ここで、ユーザは、ＭＣ３０２のライセンスを新たに取得したものとする。図８は、ＭＣ３０２のライセンスが取得された後における音楽コンテンツの管理状態を示している。図８に示すように、ＰＲＴＬｓストリームファイルから、ＭＣ３０２に対応するＴＬ２１２が削除されている。
【０１２９】
一方、ＴｒａｃｋＬｉｎｋｓストリームファイルには、ＭＣ３０２に対応するＴＬとして、ＴＬ２０３（ＴＬ＿ＩＤ＃３）が追加されている。
【０１３０】
（３）構成例３
図９は、音楽コンテンツ（オーディオデータ）管理モデルの基本的な構成例を示している。図９に示すように、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルに含まれるユーザインタフェースエントリ情報（表２参照）に、最初にアクセスするべきＵＩＥ ＴＧ＿ＩＤのリストが存在する。
【０１３１】
図９に示した構成例では、２つのリストが存在する。１つは、ＴＧ＿ＩＤが００００であるＴｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＴＢ）であり、視聴可能な全てのＴＬを管理する。Ｔｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＴＢ）は、必ず存在し、コンテンツデータ記録装置は、Ｔｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＴＢ）の内容をメンテナンスする必要がある。
【０１３２】
もう１つは、ＴＧ＿ＩＤが０００１であり、プレイリストのエントリとなるＰｌａｙ Ｌｉｓｔ Ｔｏｐ（１０ＰＬＴ）である。Ｐｌａｙ Ｌｉｓｔ Ｔｏｐ（１０ＰＬＴ）は、ＴＧのリストとして表現される。図９に示した構成例では、３つのプレイリストを管理している。
【０１３３】
Ｐｌａｙ Ｌｉｓｔ＃１，＃２，＃３（ＴＧ１０ＰＬ１，１０ＰＬ２，１０ＰＬ３）は、ＴＧ＿ＩＤ０００２，０００３，０００４にそれぞれ対応している。ユーザは、Ｐｌａｙ Ｌｉｓｔ＃１，＃２，＃３（ＴＧ１０ＰＬ１，１０ＰＬ２，１０ＰＬ３）を新規に作成したり、消去したりすることができる。また、ユーザは、Ｐｌａｙ Ｌｉｓｔ＃１，＃２，＃３（ＴＧ１０ＰＬ１，１０ＰＬ２，１０ＰＬ３）の内容を編集することができる。それぞれのプレイリストは、ＴＬ（ＴＬ２０１〜２０Ｎ）のリストで表現されている。
【０１３４】
（４）構成例４
図１０は、音楽アルバムを管理する場合における構成例を示している。図９に示したプレイリスト（Ｐｌａｙ Ｌｉｓｔ＃１，＃２，＃３（ＴＧ１０ＰＬ１，１０ＰＬ２，１０ＰＬ３））との違いは、ＣＤをリッピングする際にコンテンツデータ記録装置が、関連するフォルダ及びファイル（Ａｌｂｕｍ Ｔｏｐ（ＴＧ１０ＡＴ），Ａｒｔｉｓｔ Ａ（ＴＧ１０Ａ），Ａｒｔｉｓｔ Ｂ（ＴＧ１０Ｂ），Ａｌｂｕｍ＃１，＃２，＃３（ＴＧ１０Ａ１，ＴＧ１０Ａ２，ＴＧ１０Ａ３）を生成し、当該フォルダ及びファイルは、ユーザからの編集が不可となることである。
【０１３５】
また、本構成例では、Ｔｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＴＢ）は、音楽アルバムの情報については管理しない。
【実施例】
【０１３６】
次に、上述したコンテンツデータ構造を用いた実施例について、図面を参照しながら説明する。
【０１３７】
（コンテンツデータ記録装置の構成）
図１１は、本実施例に係る音楽レコーダ１０００（コンテンツデータ記録装置）の構成を示している。
【０１３８】
図１１に示すように、音楽レコーダ１０００は、ＣＤ１１０１をドライブするＣＤドライブ１１０２を有している。
【０１３９】
ＡＡＣエンコーダ１１０４は、ＣＤドライブ１１０２によって読み込まれた音楽コンテンツ（オーディオデータ）のデータ量を圧縮するものである。具体的には、ＡＡＣエンコーダ１１０４は、ＭＰＥＧ−４ ＡＡＣ（ＩＳＯ／ＩＥＣ１４４９６−３）に基づいて、オーディオデータを圧縮する。
【０１４０】
暗号化処理部１１０６は、ＡＡＣエンコーダ１１０４によって圧縮されたオーディオデータを暗号化するものである。また、復号化処理部１１０８は、暗号化されたオーディオデータを復号化するものである。
【０１４１】
ＡＡＣデコーダ１１１０は、復号化処理部１１０８によって出力され、ＭＰＥＧ−４ ＡＡＣに基づいて圧縮されているオーディオデータを復号（伸長）するものである、
Ｄ／Ａ変換部１１１２は、ＡＡＣデコーダ１１１０によって出力されたオーディオデータを、アナログ信号に変換するものである。Ｄ／Ａ変換部１１１２によって出力されたアナログ信号は、スピーカ１１１４を駆動する。
【０１４２】
制御部１１１６は、ＭＰＵなどによって構成されており、制御部１１１６と接続されている各部を制御するものである。また、制御部１１１６は、タイマーを内蔵しており、日付や時刻の情報を取得することができる。
【０１４３】
制御部１１１６は、リムーバブルＨＤＤ１１２６上におけるＭＣの位置及びサイズなどを示すトラックリンク情報（リンク情報）を生成するものであり、本実施形態では、リンク情報生成部を構成する。
【０１４４】
また、制御部１１１６は、ＭＣの内容（例えば、タイトルやアーティスト名）を記述し、ＭＣ（個別ファイル）の検索に用いられるメタデータを取得するものであり、本実施形態では、モデム１１２８とともに、メタデータ取得部を構成する。
【０１４５】
さらに、制御部１１１６は、トラックリンク情報とメタデータとを含むＡＵＤ＿ＳＥＴ．ＭＧＲファイル（管理ファイル）を生成するものであり、本実施形態では、管理ファイル生成部を構成する。
【０１４６】
また、制御部１１１６は、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルを用いて、ＭＣを検索するものであり、本実施形態では、コンテンツ検索部を構成する。なお、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルには、上述したように、ＭＣの再生を許可するライセンス管理情報（*ＵＤＦ＿ＬＩＣＥＮＣＥセキュアストリームファイル）が含まれている。制御部１１１６は、当該ライセンス管理情報に基づいて、ＭＣを再生するものであり、本実施形態では、復号化処理部１１０８とともに、コンテンツ再生部を構成する。
【０１４７】
表示部１１１８は、制御部１１１６によって出力された情報、例えば、音楽コンテンツのトラック数、トラック番号、及びタイトルやアーティスト名などのメタデータを表示するものである。リモコン受光部１１２０は、リモコン１１２２から送信された赤外線光を受光するものである。
【０１４８】
ＡＴＡインタフェース１１２４は、制御部１１１６とリムーバブルＨＤＤ１１２６とを通信可能に接続するためのインタフェース（At Attachment）である。
【０１４９】
リムーバブルＨＤＤ１１２６は、音楽レコーダ１０００からの取り外しが可能なリムーバブル記録媒体である。リムーバブルＨＤＤ１１２６は、ＣＤ１１０１からリッピングされたオーディオデータを記録し、上述したコンテンツデータ構造によって当該オーディオデータが管理される。
【０１５０】
リムーバブルＨＤＤ１１２６には、上述したように、複数の音楽コンテンツ（ＭＣ３０１，３０２など）のそれぞれが、個別ファイルとして記録される。
【０１５１】
モデム１１２８は、音楽レコーダ１０００（制御部１１１６）と、コンテンツサーバ１１３２及びメタデータサーバ１１３４とを、インターネット網１１３０を介して通信可能に接続するための通信デバイスである。
【０１５２】
なお、音楽レコーダ１０００は、インターネット網１１３０との接続に用いられる通信回線の方式に基づいて、モデム１１２８以外の通信デバイス、例えば、メディアコンバータなどを実装することもできる。
【０１５３】
（コンテンツデータ記録装置の動作）
次に、上述した本実施例に係る音楽レコーダ１０００（コンテンツデータ記録装置）の動作について説明する。
【０１５４】
（１）リムーバルＨＤＤの初期化
図１２は、音楽レコーダ１０００に接続されるリムーバブルＨＤＤ１１２６の初期化処理フローを示している。
【０１５５】
図１２に示すように、ステップＳ１０において、音楽レコーダ１０００は、ＡＵＲ＿ＲＯＯＴディレクトリを作成する。
【０１５６】
ステップＳ２０において、音楽レコーダ１０００は、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルを作成する。具体的には、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルを構成するフィールドは、以下のように設定される。
【０１５７】
・ Ｆｌａｇ ＝ ０
・ Ｎｕｍ ｏｆ ＵＩＥ ＴＧｓ ＝ １
・ ＵＩＥ ＴＧ ＩＤ（１） ＝ ００００（ＡＳＣＩＩ）
・ Ｔｒａｃｋ Ｌｉｎｋ Ｌｏｃａｔｉｏｎ ＝ “．／ＰＲＯＧ＿ＳＥＴ．ＭＧＲ＃ＴｒａｃｋＬｉｎｋｓ”
・ Ｎｕｍｂｅｒ ｏｆ Ｔｒａｃｋ Ｇｒｏｕｐｓ ＝ １
・ Ｍａｘｉｍｕｍ Ｔｒａｃｋ Ｇｒｏｕｐ ＩＤ ＝ ００００
ステップＳ３０において、音楽レコーダ１０００は、ＴｒａｃｋＬｉｎｋｓストリームファイルを作成する。具体的には、ＴｒａｃｋＬｉｎｋｓストリームファイルを構成するフィールドは、以下のように設定される。
【０１５８】
・ Ｎｕｍｂｅｒ ｏｆ Ｔｒａｃｋ Ｌｉｎｋｓ ＝ ０
・ Ｎｕｍｂｅｒ ｏｆ Ｖａｌｉｄ Ｔｒａｃｋ Ｌｉｎｋｓ ＝ ０
ステップＳ４０において、音楽レコーダ１０００は、ＴＧ＿００００ストリームファイルを作成する。具体的には、ＴＧ＿００００ストリームファイルを構成するフィールドは、以下のように設定される。
【０１５９】
・ ＴＧ Ｓｐｅｃｉｆｉｃ Ｓｔｒｕｃｔｕｒｅ ＴＹＰＥ ＝ ０ｘ００
・ ＴＧ Ｆｌａｇ ＝ ０ｘ０２
・ ＴＧ ｓｐｅｃｉｆｉｃ ｓｔｒｕｃｔｕｒｅ ｎａｍｅ ＝ “Ｔｒａｃｋ Ｂａｓｅ”
・ Ｌｉｎｋ Ｃｏｕｎｔ ＝ ０
・ Ｎｕｍｂｅｒ ｏｆ ｅｌｅｍｅｎｔｓ ＝ ０
ステップＳ５０において、音楽レコーダ１０００は、ＲＴ＿ＡＵＲＳディレクトリを作成する。
【０１６０】
（２）ＣＤリッピング（１曲）
図１３は、ＣＤ１１０１（図１１参照）に含まれる音楽コンテンツ（オーディオデータ）から、１曲分のオーディオデータをリッピングし、リムーバブルＨＤＤ１１２６に記録するフローを示している。
【０１６１】
図１３に示すように、ステップＳ１１０において、音楽レコーダ１０００は、ＣＤ１１０１に含まれるオーディオデータに基づいて、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルを作成する。具体的には、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルを構成するフィールドは、以下のように設定される。なお、以下に示すフィールドにおいて、具体的な内容がないフィールドについては、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルの内容に応じて適切なデータが記述される。
【０１６２】
・ Ｎｕｍｂｅｒ ｏｆ Ｔｒａｃｋｓ ＝ １
・ ＡＵＤ Ｆｌａｇ
・ Ｐｌａｙｂａｃｋ Ｔｉｍｅ
・ Ｆｉｌｅ Ｓｉｚｅ
・ Ａｕｄｉｏ Ｆｏｒｍａｔ ＝ （ＡＡＣ）
・ Ｂｉｔ ｒａｔｅ
・ Ｆｉｌｅ Ｃｒｅａｔｅｄ Ｄａｔｅ
・ Ｃｈａｒａｃｔｅｒ Ｓｅｔ （Ｕｎｉｃｏｄｅ）
・ ＭｅｔａＤａｔａＦｉｌｅ Ｆｏｒｍａｔ
・ Ｌｉｃｅｎｓｅ Ｆｌａｇ
・ Ｌｉｃｅｎｓｅ Ｆｉｌｅ Ｌｏｃａｔｉｏｎ
ステップＳ１２０において、音楽レコーダ１０００は、ＴｒａｃｋＬｉｎｋｓストリームファイルの内容を更新する。具体的には、音楽レコーダ１０００は、以下に示すように、ＴｒａｃｋＬｉｎｋｓストリームファイルの内容を更新する。なお、以下に示すフィールドにおいて、具体的な内容がないフィールドについては、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルの内容などに応じて適切なデータが記述される。
【０１６３】
・ Ｎｕｍｂｅｒ ｏｆ Ｔｒａｃｋ Ｌｉｎｋｓ ＝ ｎ＋１
・ Ｎｕｍｂｅｒ ｏｆ Ｖａｌｉｄ Ｔｒａｃｋ Ｌｉｎｋｓ ＝ ｎ＋１
・ ＴＬ構造体追加
・ ＴＬ Ｓｐｅｃｉｆｉｃ Ｓｔｒｕｃｔｕｒｅ ＴＹＰＥ ＝ ０ｘ１
・ ＴＬ Ｆｌａｇ
・ Ｌｉｎｋ Ｃｏｕｎｔ ＝ １ （ｆｒｏｍ ＴＧ＿００００）
・ Ｍｕｓｉｃ Ｃｏｎｔｅｎｔ ＩＤ ＝ ｘｘｘｘｘｘｘ
・ ＭｅｔａＤａｔａ
・ Ｍｙ Ｒａｔｅ Ｉｎｆｏ
・ Ｌａｓｔ Ａｃｃｅｓｓｅｄ Ｔｉｍｅ
・ Ｐｌａｙｂａｃｋ Ｃｏｕｎｔｅｒ
・ Ｒｅｓｕｍｅ Ｐｏｉｎｔ
ステップＳ１３０において、音楽レコーダ１０００は、ＴＧ＿００００ストリームファイルの内容を更新する。具体的には、音楽レコーダ１０００は、以下に示すように、ＴＧ＿００００ストリームファイルの内容を更新する。
【０１６４】
・ Ｎｕｍｂｅｒ ｏｆ ｅｌｅｍｅｎｔｓ ＝ ｎ＋１
・ ｅｌｅｍｅｎｔ ＩＤを追加
（３）ＣＤリッピング（音楽アルバム）
図１４は、ＣＤ１１０１に含まれる音楽コンテンツ（オーディオデータ）から、複数曲によって構成されるオーディオデータをリッピングし、リムーバブルＨＤＤ１１２６に記録するフローを示している。
【０１６５】
図１４に示すように、ステップＳ２１０において、音楽レコーダ１０００は、ＣＤ１１０１に含まれるオーディオデータに基づいて、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルを作成する。具体的には、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルを構成するフィールドは、以下のように設定される。なお、以下に示すフィールドにおいて、具体的な内容がないフィールドについては、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルの内容に応じて適切なデータが記述される。
【０１６６】
・ Ｎｕｍｂｅｒ ｏｆ Ｔｒａｃｋｓ ＝ ｍ（音楽アルバムにｍ曲収容されている）
・ ＡＵＤ Ｆｌａｇ
・ Ｐｌａｙｂａｃｋ Ｔｉｍｅ
・ Ｆｉｌｅ Ｓｉｚｅ
・ Ａｕｄｉｏ Ｆｏｒｍａｔ ＝ （ＡＡＣ）
・ Ｂｉｔ ｒａｔｅ
・ Ｆｉｌｅ Ｃｒｅａｔｅｄ Ｄａｔｅ
・ Ｃｈａｒａｃｔｅｒ Ｓｅｔ （Ｕｎｉｃｏｄｅ）
・ ＭｅｔａＤａｔａＦｉｌｅ Ｆｏｒｍａｔ
・ Ｌｉｃｅｎｓｅ Ｆｌａｇ
・ Ｌｉｃｅｎｓｅ Ｆｉｌｅ Ｌｏｃａｔｉｏｎ
ステップＳ２２０において、音楽レコーダ１０００は、ＴｒａｃｋＬｉｎｋｓストリームファイルの内容を更新する。具体的には、音楽レコーダ１０００は、以下に示すように、ＴｒａｃｋＬｉｎｋｓストリームファイルの内容を更新する。なお、以下に示すフィールドにおいて、具体的な内容がないフィールドについては、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルの内容などに応じて適切なデータが記述される。
【０１６７】
・ Ｎｕｍｂｅｒ ｏｆ Ｔｒａｃｋ Ｌｉｎｋｓ ＝ ｎ＋ｍ
・ Ｎｕｍｂｅｒ ｏｆ Ｖａｌｉｄ Ｔｒａｃｋ Ｌｉｎｋｓ ＝ ｎ+ｍ
・ ｍ個のＴＬ構造体追加
ステップＳ２３０において、音楽レコーダ１０００は、ＴＧ＿００００ストリームファイルの内容を更新する。具体的には、音楽レコーダ１０００は、以下に示すように、ＴＧ＿００００ストリームファイルの内容を更新する。
【０１６８】
・ Ｎｕｍｂｅｒ ｏｆ ｅｌｅｍｅｎｔｓ ＝ ｎ+ｍ
・ ｅｌｅｍｅｎｔ ＩＤを追加（ｍ個）
ステップＳ２４０において、音楽レコーダ１０００は、ＴＧ＿ｘｘｘｘストリームファイルを作成する。具体的には、ＴＧ＿ｘｘｘｘストリームファイルを構成するフィールドは、以下のように設定される。
【０１６９】
・ ＴＧ Ｓｐｅｃｉｆｉｃ Ｓｔｒｕｃｔｕｒｅ ＴＹＰＥ ＝ ０ｘ０１
・ ＴＧ Ｆｌａｇ ＝ ０ｘ０３
・ ＴＧ ｓｐｅｃｉｆｉｃ ｓｔｒｕｃｔｕｒｅ ｎａｍｅ ＝ アルバムタイトル
・ Ｌｉｎｋ Ｃｏｕｎｔ ＝ ０
・ Ｎｕｍｂｅｒ ｏｆ ｅｌｅｍｅｎｔｓ ＝ ｍ
・ ｅｌｅｍｅｎｔ ＩＤ： ｍ個のＩＤを追加する
・ 各ｅｌｅｍｅｎｔのＴＬ構造体に含まれるＬｉｎｋ Ｃｏｕｎｔに“１”を加算
ステップＳ２５０において、音楽レコーダ１０００は、ステップＳ２４０において作成したＴＧ＿ｘｘｘｘストリームファイルがリンクされる上位のＴＧ（例えば、図１０に示したＴＧ１０Ａ）があるか否かを判定する。
【０１７０】
ＴＧ＿ｘｘｘｘストリームファイルがリンクされる上位のＴＧがある場合（ステップＳ２５０のＹｅｓ）、ステップＳ２６０において、音楽レコーダ１０００は、当該上位ＴＧについてメンテナンスを実行する。具体的には、以下のようなメンテナンスが実行される。
【０１７１】
・ Ｎｕｍｂｅｒ ｏｆ ｅｌｅｍｅｎｔｓ ＝ ｎ＋１
・ ｅｌｅｍｅｎｔ ＩＤ： 追加したＴＧ＿ｘｘｘｘストリームファイルのｘｘｘｘ部分を追加
ＴＧ＿ｘｘｘｘストリームファイルがリンクされる上位のＴＧがない場合（ステップＳ２５０のＮｏ）、ステップＳ２７０において、音楽レコーダ１０００は、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの内容を更新する。具体的には、音楽レコーダ１０００は、以下に示すように、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの内容を更新する。
【０１７２】
・ Ｆｌａｇ ＝ ０
・ Ｎｕｍ ｏｆ ＵＩＥ ＴＧｓ ＝ ２
・ ＵＩＥ ＴＧ ＩＤ（２） ＝ ｘｘｘｘ（ＡＳＣＩＩ）
・ Ｎｕｍｂｅｒ ｏｆ Ｔｒａｃｋ Ｇｒｏｕｐｓ ＝ ２
・ ＵＩＥ ＴＧ ＩＤ（２） Ｎａｍｅ ＝ アルバムタイトル
・ Ｍａｘｉｍｕｍ Ｔｒａｃｋ Ｇｒｏｕｐ ＩＤ ＝ ｘｘｘｘ
以上、音楽レコーダ１０００が、ＣＤ１１０１に含まれる音楽コンテンツ（音楽コンテンツ）をリッピングする場合の動作について説明したが、音楽レコーダ１０００は、インターネット網１１３０を介して接続されているコンテンツサーバ１１３２に格納されている音楽コンテンツをダウンロードし、リムーバブルＨＤＤ１１２６に記録することもできる。
【０１７３】
（４）ＣＤＤＢからのメタデータ取得
図１５は、ＣＤＤＢから、音楽コンテンツに関するメタデータを取得するフローを示している。
【０１７４】
図１５に示すように、ステップＳ３１０において、ユーザは、ＣＤ１１０１をＣＤドライブ１１０２（図１１参照）に挿入する。
【０１７５】
ＣＤ１１０１がＣＤドライブ１１０２（図１１参照）に挿入されると、ステップＳ３２０において、音楽レコーダ１０００は、メタデータサーバ１１３４からＣＤ１１０１に対応するメタデータを取得する。
【０１７６】
具体的には、音楽レコーダ１０００は、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルのメタデータ管理情報を取得し、取得したメタデータ管理情報に基づいて、ＭｅｔａＤａｔａストリームファイルにメタデータを登録する。なお、音楽レコーダ１０００は、必要により、メタデータに用いられる文字コードを変換する。
【０１７７】
ステップＳ３３０において、音楽レコーダ１０００は、対応するＴＬ構造体（表８参照）にメタデータを登録する。音楽レコーダ１０００は、登録対象のメタデータがフィールド長より長い場合、当該フィールドに記述することができない当該メタデータの部分を削除する。
【０１７８】
（５）再生（タイトル検索・メタデータ表示）
図１６は、リムーバブルＨＤＤ１１２６に含まれる音楽コンテンツ（オーディオデータ）を再生するフローを示している。
【０１７９】
図１６に示すように、ステップＳ４１０において、音楽レコーダ１０００は、ＡＵＲ＿ＲＯＯＴディレクトリの配下に位置するＡＵＤ＿ＳＥＴ．ＭＧＲファイルをオープンし、ＵＩＥ ＴＧ＿ＩＤのリスト及び名前をユーザに表示する。
【０１８０】
ステップＳ４２０において、ユーザは、ＵＩＥ ＴＧ＿ＩＤのリストの中から、１つのＴＧ＿ＩＤを選択する。
【０１８１】
ステップＳ４３０において、音楽レコーダ１０００は、選択されたＴＧ＿ＩＤに対応するＴＧ＿ｘｘｘｘストリームファイルをオープンし、ｅｌｅｍｅｎｔ＿ＩＤのリストをユーザに表示する。
【０１８２】
ステップＳ４４０において、音楽レコーダ１０００は、ｅｌｅｍｅｎｔがＴＧか否かを判定する。
【０１８３】
ｅｌｅｍｅｎｔがＴＧの場合（ステップＳ４４０のＹｅｓ）、音楽レコーダ１０００は、ステップＳ４２０からの処理を繰り返す。ｅｌｅｍｅｎｔがＴＧでない場合、すなわち、ｅｌｅｍｅｎｔがＴＬの場合（ステップＳ４４０のＮｏ）、ステップＳ４５０において、ユーザは、ｅｌｅｍｅｎｔ＿ＩＤのリストの中から、１つのＴＬ＿ＩＤを選択する。
【０１８４】
ステップＳ４６０において、音楽レコーダ１０００は、ＴｒａｃｋＬｉｎｋｓストリームファイルから、選択されたＴＬ＿ＩＤに対応するＴＬ構造体を取得する。
【０１８５】
ステップＳ４７０において、音楽レコーダ１０００は、取得したＴＬ構造体の“Ｍｕｓｉｃ Ｃｏｎｔｅｎｔｓ ＩＤ”、“Ｓｔａｒｔ Ｐｏｉｎｔ ｉｎ Ｃｏｎｔｅｎｔｓ Ｆｉｌｅ”及び“Ｃｏｎｔｅｎｔｓ Ｌｅｎｇｔｈ”から、ＡＵＤｘｘｘｘｘｘｘｘ．ＡＩＦファイルに含まれるＡｕｄｉｏＤａｔａストリームファイルの再生位置を確保する。
【０１８６】
ステップＳ４８０において、音楽レコーダ１０００は、*ＵＤＦ＿ＬＩＣＥＮＣＥセキュアストリームファイルから、ライセンスファイル（復号鍵）を取得する。
【０１８７】
ステップＳ４９０において、音楽レコーダ１０００は、取得した復号鍵を用いて、ＡｕｄｉｏＤａｔａストリームファイルに含まれるオーディオデータを復号して再生する。
【０１８８】
ステップＳ５００において、音楽レコーダ１０００は、ＴＬ構造体のＰｌａｙｂａｃｋ Ｃｏｕｎｔｅｒに“１”加算する。なお、Ｐｌａｙｂａｃｋ Ｃｏｕｎｔｅｒに加算するタイミングは、再生開始時ままたは再生終了時の何れでもよい。
【０１８９】
ステップＳ５１０において、音楽レコーダ１０００は、オーディオデータ、つまり、音楽コンテンツの再生が途中で停止されたか否かを判定する。
【０１９０】
音楽コンテンツの再生が途中で停止された場合（ステップＳ５１０のＹｅｓ）、ステップＳ５２０において、音楽レコーダ１０００は、当該停止した位置に対して、リジュームポイントを設定する。
【０１９１】
（６）プレイリスト作成（ＴＧ）
図１７は、プレイリスト（ＴＧ）を作成するフローを示している。
【０１９２】
図１７に示すように、ステップＳ６１０において、ユーザは、プレイリストのフォルダを作成する。プレイリストのフォルダがユーザによって作成されると、音楽レコーダ１０００は、ＴＧ＿ｘｘｘｘストリームファイルを生成する。具体的には、当該ＴＧ＿ｘｘｘｘストリームファイルを構成するフィールドは、以下のように設定される。
【０１９３】
・ ＴＧ Ｓｐｅｃｉｆｉｃ Ｓｔｒｕｃｔｕｒｅ ＴＹＰＥ ＝ ０ｘ０２
・ ＴＧ Ｆｌａｇ ＝ ０ｘ０３
・ ＴＧ ｓｐｅｃｉｆｉｃ ｓｔｒｕｃｔｕｒｅ ｎａｍｅ ＝ プレーリストタイトル
・ Ｌｉｎｋ Ｃｏｕｎｔ ＝ ０
・ Ｎｕｍｂｅｒ ｏｆ ｅｌｅｍｅｎｔｓ ＝ ０
ステップＳ６２０において、ユーザは、ＴＧ＿００００ストリームファイルからユーザがプレイリストに登録するものをピックアップする。
【０１９４】
ステップＳ６３０において、音楽レコーダ１０００は、ＴＧ＿ｘｘｘｘストリームファイルの内容を更新する。具体的には、音楽レコーダ１０００は、以下に示すように、ＴＧ＿ｘｘｘｘストリームファイルの内容を更新する。
【０１９５】
・ Ｎｕｍｂｅｒ ｏｆ ｅｌｅｍｅｎｔｓ ＝ ｎ＋１
・ ｅｌｅｍｅｎｔ ＩＤ： 選択されたＴＬ＿ＩＤを追加
・ 各ｅｌｅｍｅｎｔのＴＬ構造体に含まれるＬｉｎｋ Ｃｏｕｎｔに“１”を加算
ステップＳ６４０において、音楽レコーダ１０００は、さらにプレイリストに追加するものがあるか否かを判定する。
【０１９６】
さらにプレイリストに追加するものがある場合（ステップＳ６４０のＹｅｓ）、ユーザは、ステップＳ６２０からの処理を繰り返す。
【０１９７】
プレイリストに追加するものがない場合（ステップＳ６４０のＮｏ）、ステップＳ６５０において、音楽レコーダ１０００は、ステップＳ６３０において更新したＴＧ＿ｘｘｘｘストリームファイルがリンクされる上位のＴＧ（例えば、図１０に示したＴＧ１０Ａ）があるか否かを判定する。
【０１９８】
ＴＧ＿ｘｘｘｘストリームファイルがリンクされる上位のＴＧがある場合（ステップＳ６５０のＹｅｓ）、ステップＳ６６０において、音楽レコーダ１０００は、当該上位ＴＧについて、メンテナンスを実行する。具体的には、ステップＳ２６０と同様なメンテナンスが実行される。
【０１９９】
ＴＧ＿ｘｘｘｘストリームファイルがリンクされる上位のＴＧがない場合（ステップＳ２５０のＮｏ）、ステップＳ６７０において、音楽レコーダ１０００は、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの内容を更新する。具体的には、音楽レコーダ１０００は、ステップＳ２７０と同様に、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの内容を更新する。
【０２００】
なお、音楽レコーダ１０００がＴＧ＿ｘｘｘｘストリームファイルを生成する場合、“ｘｘｘｘ”部分の簡易的な割り当て方法としては、“Ｍａｘｉｍｕｍ Ｔｒａｃｋ Ｇｒｏｕｐ ＩＤ”フィールド（表６参照）を参照して、現状の最大値に“１”を加算した値を割り当てるとともに、“Ｍａｘｉｍｕｍ Ｔｒａｃｋ Ｇｒｏｕｐ ＩＤ”フィールドにも、現状の最大値に“１”を加算した値を割り当てる方法が用いられる。
【０２０１】
また、他の割り当て方法としては、全てのＴＧ＿ＩＤをサーチして、欠損している番号（例えば、一度生成されて、その後削除した場合）があれば、当該番号を割り当てる方法がある。この場合、欠損している番号がなければ、上述したように、現状の最大値に“１”を加算した値を割り当てるとともに、“Ｍａｘｉｍｕｍ Ｔｒａｃｋ Ｇｒｏｕｐ ＩＤ”フィールドにも、現状の最大値に“１”を加算した値を割り当てる。
【０２０２】
すなわち、簡易的な割り当て方法では、全てのＴＧ＿ＩＤをサーチする必要がなく、より高速に“ｘｘｘｘ”部分の割り当て処理を実行することができる。
【０２０３】
（７）メタデータによるリストのソート
図１８は、メタデータによって、リストをソートするフローを示している。図１８に示すように、ステップＳ７１０において、ユーザは、ＴＬのリストで表現されているＴＧを選択する。
【０２０４】
ステップＳ７２０において、ユーザは、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルに含まれるＭｅｔａＤａｔａストリームファイル（メタデータ構造体）から検索したいフィールドを選択する。
【０２０５】
ステップＳ７３０において、音楽レコーダ１０００は、ＴＧのｅｌｅｍｅｎｔであるＴＬに対応するＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルのＭｅｔａＤａｔａストリームファイルから候補のメタデータを検索する。ステップＳ７４０において、音楽レコーダ１０００は、該当するＴＬをメタデータ順にソートする。
【０２０６】
より具体的には、図２６に示すように、５つのトラック（ＴＬ２０１〜２０５，ＭＣ３０１〜ＭＣ３０５）から構成されるＴｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＴＢ）からメタデータによってリストをソートする場合、音楽レコーダ１０００は、ＴＬ＿ＩＤ ＃１〜ＴＬ＿ＩＤ ＃５のＴＬについて、以下の処理を実行する。
【０２０７】
（ｉ） ＴＬ＿ＩＤ ＃ｎ（ｎ＝１〜５）のＴＬ（ＴＬ２０１〜２０５）に対して、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルに属するＭｅｔａＤａｔａストリームファイルをオープンする。
【０２０８】
（ｉｉ） ＭｅｔａＤａｔａストリームファイルの先頭から、“Ｇｅｎｒｅ”フィールドの先頭までのバイト数を演算する（表２６において、１＋ａ＋１＋ｂ＋１＋ｃ＋１＋ｄを演算することに該当）。
【０２０９】
（ｉｉｉ） “Ｌｅｎｇｔｈ ｏｆ Ｇｅｎｒｅ”フィールドの値（＝ｅ）を取得する。
【０２１０】
（ｉｖ） “Ｌｅｎｇｔｈ ｏｆ Ｇｅｎｒｅ”フィールドに続く“Ｇｅｎｒｅ”フィールドに記述されているデータを取得する。
【０２１１】
（ｖ） ＴＬ＿ＩＤとＧｅｎｒｅデータとのリストを、既に取得したリスト（例えば、ＴＬ＿ＩＤ＃３の場合、ＴＬ＿ＩＤ＃１及びＴＬ＿ＩＤ＃２に係るリスト）と比較し、アルファベット順（日本語の場合は５０音順）にソートする。
【０２１２】
ＴＬ＿ＩＤ ＃１〜ＴＬ＿ＩＤ ＃５のＴＬ（ＴＬ２０１〜２０５）について、上述した（ｉ）〜（ｖ）の処理を実行した音楽レコーダ１０００は、ソートされたＴＬ＿ＩＤ順にリストの内容を表示する。
【０２１３】
（８）メタデータによるリストの高速ソート
図１９は、メタデータによって、リストを高速にソートするフローを示している。図１９に示すように、ステップＳ７１０Ａにおいて、ユーザは、ＴＬのリストで表現されているＴＧを選択する。
【０２１４】
ステップＳ７２０Ａにおいて、ユーザは、ＴＬ構造体によって定義されているメタデータフィールドから、検索したいフィールドを選択する。
【０２１５】
ステップＳ７３０Ａにおいて、音楽レコーダ１０００は、ＴＧのｅｌｅｍｅｎｔであるＴＬに対応するＴＬ構造体から候補のメタデータを検索する。ステップＳ７４０Ａにおいて、音楽レコーダ１０００は、該当するＴＬをメタデータ順にソートする。
【０２１６】
すなわち、図１８に示したメタデータによるリストのソート方法では、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルに含まれるＭｅｔａＤａｔａストリームファイル（メタデータ構造体）をオープンして内容を検索しなければならないが、図１９に示したメタデータによるリストのソート方法では、３２４バイトの固定長を有するＴＬ構造体（表８参照）が用いられるため、より高速にソートを実行することができる。
【０２１７】
より具体的には、図２６に示すように、５つのトラック（ＴＬ２０１〜２０５，ＭＣ３０１〜ＭＣ３０５）から構成されるＴｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＴＢ）からメタデータによってリストを高速にソートする場合、音楽レコーダ１０００は、ＴｒａｃｋＬｉｎｋｓストリームファイルをオープンし、以下の処理を実行する。
【０２１８】
（ｉ） ＴＬ＿ＩＤ ＃１の“Ｇｅｎｒｅ”フィールドの先頭位置を取得する。具体的には、ＴＬ＿ＩＤ ＃１の“Ｇｅｎｒｅ”フィールドの先頭位置が、ＴｒａｃｋＬｉｎｋｓストリームファイルの先頭から２１０バイト目（表７において、ＴＬ＿ＩＤ ＃１に係るＴＬ構造体のデータは、８バイト目から開始され、表８において、“Ｇｅｎｒｅ”フィールドは、２０２バイト目から開始されている）であることを認識する。
【０２１９】
（ｉｉ） “Ｇｅｎｒｅ”フィールドに記述されているデータを取得し、ＴＬ＿ＩＤとＧｅｎｒｅデータとのリストを記憶する。
【０２２０】
（ｉｉｉ） ＴＬ＿ＩＤ ＃２の“Ｇｅｎｒｅ”フィールドの先頭位置（５３４バイト目（２１０＋３２４バイト、表７及び表８参照））を取得する。同様に、ＴＬ＿ＩＤ ＃３，＃４，＃５の先頭位置は、（２１０＋２×３２４）バイト目、（２１０＋３×３２４）バイト目、（２１０＋４×３２４）バイト目となる。
【０２２１】
（ｉｖ） ＴＬ＿ＩＤとＧｅｎｒｅデータとのリストを、既に取得したリスト（例えば、ＴＬ＿ＩＤ＃３の場合、ＴＬ＿ＩＤ＃１及びＴＬ＿ＩＤ＃２に係るリスト）と比較し、アルファベット順（日本語の場合は５０音順）にソートする。
【０２２２】
ＴＬ＿ＩＤ ＃１〜ＴＬ＿ＩＤ ＃５のＴＬ（ＴＬ２０１〜２０５）について、上述した（ｉ）〜（ｉｖ）の処理を実行した音楽レコーダ１０００は、ソートされたＴＬ＿ＩＤ順にリストの内容を表示する。
【０２２３】
（９）メタデータによるリストの高速検索
図２０は、メタデータによって、リストを高速に検索するフローを示している。図２０に示すように、ステップＳ８１０において、ユーザは、ＴＬのリストで表現されているＴＧを選択する。
【０２２４】
ステップＳ８２０において、ユーザは、ＴＬ構造体によって定義されているメタデータフィールドから、検索したいフィールドを選択する。
【０２２５】
ステップＳ８３０において、ユーザは、選択したフィールドに対応する文字を入力する。
【０２２６】
ステップＳ８４０において、音楽レコーダ１０００は、ＴＧのｅｌｅｍｅｎｔであるＴＬに対応するＴＬ構造体からメタデータを検索し、ユーザが入力した文字とマッチングを実行する。ステップＳ８５０において、音楽レコーダ１０００は、該当するＴＬのリストをユーザに表示する。
【０２２７】
本検索方法でも、３２４バイトの固定長を有するＴＬ構造体（表８参照）が用いられるため、ＭｅｔａＤａｔａストリームファイルをオープンする場合と比較して、より高速な検索を実行することができる。
【０２２８】
（１０）リジュームポイントの設定
図２１は、リジュームポイントを設定するフローを示している。図２１に示すように、ステップＳ９１０において、音楽レコーダ１０００は、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルからＵＩＥ ＴＧのリストをユーザに表示する。
【０２２９】
ステップＳ９２０において、ユーザは、ＵＩＥ ＴＧリストから１つのＴＧを選択する。ステップＳ９３０において、音楽レコーダ１０００は、“Ｌａｓｔ Ａｃｃｅｓｓｅｄ ＵＩＥ ＴＧ＿ＩＤ”フィールドに選択されたＴＧ＿ＩＤを記述する。また、音楽レコーダ１０００は、当該ＴＧ＿ＩＤを記述した時刻を“Ｌａｓｔ Ａｃｃｅｓｓｅｄ ＵＩＥ ＴＧ＿ＩＤ ｒｅｃｏｒｄｅｄ ｄａｔｅ”に記述する。
【０２３０】
ステップＳ９４０において、音楽レコーダ１０００は、選択されたＴＧのｅｌｅｍｅｎｔリストをユーザに表示する。
【０２３１】
ｅｌｅｍｅｎｔがＴＧである場合（ステップＳ９５０のＮｏ）、ステップＳ９８０において、ユーザは、ＴＧリストから１つのＴＧを選択する。ステップＳ９９０において、音楽レコーダ１０００は、“Ｒｅｓｕｍｅ ｅｌｅｍｅｎｔ”に当該ＴＧ＿ＩＤを追加する。
【０２３２】
ｅｌｅｍｅｎｔがＴＬである場合（ステップＳ９５０のＹｅｓ）、ステップＳ９６０において、ユーザは、ＴＬリストから、１つのＴＬを選択する。ステップＳ９７０において、音楽レコーダ１０００は、“Ｒｅｓｕｍｅ ｅｌｅｍｅｎｔ”に当該ＴＬ＿ＩＤを追加する。
【０２３３】
以降、音楽レコーダ１０００は、選択されたＴＬ＿ＩＤと対応するＴＬ構造体に基づいて、オーディオデータを再生する（図１６のステップＳ４７０以降の処理を参照）。
【０２３４】
（１１）リジューム再生
図２２は、リジュームポイントに基づいて、オーディオデータを再生（リジューム再生）するフローを示している。図２２に示すように、ステップＳ１０１０において、音楽レコーダ１０００は、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの“Ｌａｓｔ Ａｃｃｅｓｓｅｄ ＵＩＥ ＴＧ＿ＩＤ”に記述されているＴＧ＿ＩＤに該当するＴＧ＿ｘｘｘｘストリームファイルをオープンする。
【０２３５】
ステップＳ１０２０において、音楽レコーダ１０００は、該当するＴＧの“Ｒｅｓｕｍｅ ｅｌｅｍｅｎｔ”に記述されているｅｌｅｍｅｎｔ＿ＩＤを取得する。
【０２３６】
ステップＳ１０３０において、音楽レコーダ１０００は、ｅｌｅｍｅｎｔがＴＧか否かを判定する。ｅｌｅｍｅｎｔがＴＧの場合（ステップＳ１０３０のＹｅｓ）、音楽レコーダ１０００は、ステップＳ１０２０からの処理を繰り返す。
【０２３７】
ｅｌｅｍｅｎｔがＴＬの場合（ステップＳ１０３０のＮｏ）、ステップＳ１０４０において、音楽レコーダ１０００は、リジュームポイントが設定されているか否かを判定する。
【０２３８】
リジュームポイントが設定されている場合（ステップＳ１０４０のＹｅｓ）、ステップＳ１０５０において、音楽レコーダ１０００は、リジュームポイントからオーディオデータを再生する。一方、リジュームポイントが設定されていない場合（ステップＳ１０４０のＮｏ）、ステップＳ１０６０において、音楽レコーダ１０００は、曲（または音楽アルバム）の最初からオーディオデータを再生する。
【０２３９】
なお、リジュームポイント設定をオプション仕様とする場合、上述したように、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの“Ｒｅｓｕｍｅ Ｓｕｐｐｏｒｔ Ｆｌａｇ”が使用される。リジュームをサポートしている音楽レコーダなど（コンテンツデータ記録装置）は、立上げ時（電源投入時など）に１ｂを記録する。一方、リジュームをサポートしていない音楽レコーダなどは、立上げ時に０ｂを記録する。
【０２４０】
また、リムーバブルＨＤＤ１１２６（リムーバブル記録媒体）を移動後、他の音楽レコーダなどで再生する場合、当該他の音楽レコーダなどは、まず、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの“Ｒｅｓｕｍｅ Ｓｕｐｐｏｒｔ Ｆｌａｇ”の内容を読み込み、値が１ｂの場合にはリジューム再生を行い、値が０ｂの場合にはリジューム再生を行わない。
【０２４１】
（１２）タイトル削除
図２３は、音楽コンテンツ（オーディオデータ）と対応付けられているタイトルを削除するフローを示している。図２３に示すように、ステップＳ１１１０において、音楽レコーダ１０００は、ＴＧ＿００００ストリームファイル（Ｔｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＴＢ））をオープンし、ｅｌｅｍｅｎｔ＿ＩＤのリストと名前をユーザに表示する。
【０２４２】
ステップＳ１１２０において、ユーザは、削除するタイトルを１つ選択する。ステップＳ１１３０において、音楽レコーダ１０００は、当該タイトルのＴＬとリンクされているＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルが１トラックのみで構成されているか否かを判定する。
【０２４３】
ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルが１トラックのみで構成されている場合（ステップＳ１１３０のＹｅｓ）、ステップＳ１１６０において、音楽レコーダ１０００は、当該ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルを削除する。
【０２４４】
ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルが１トラックのみで構成されていない場合（ステップＳ１１３０のＮｏ）、すなわち、複数曲で構成されている場合、ステップＳ１１４０において、音楽レコーダ１０００は、ＴＬから当該ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルへのリンクをサーチする。
【０２４５】
ステップＳ１１５０において、音楽レコーダ１０００は、ＴＬから当該ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルへのリンクが１以上存在するか否かを判定する。
【０２４６】
当該ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルへのリンクが１以上存在する場合（ステップＳ１１５０のＹｅｓ）、音楽レコーダ１０００は、当該ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルを削除せず、ステップＳ１１７０の処理を実行する。
【０２４７】
一方、当該ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルへのリンクが全く存在しない場合（ステップＳ１１５０のＮｏ）、ステップＳ１１６０において、音楽レコーダ１０００は、当該ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルを削除する。
【０２４８】
ステップＳ１１７０において、音楽レコーダ１０００は、当該ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルと対応付けられているＴＬ構造体を削除するとともに、当該ＴＬ構造体をリンクしているＴＧから、当該ＴＬへのリンクを削除する。具体的には、ＴＬ構造体の“Ｌｉｎｋ Ｃｏｕｎｔ”にＴＧからリンクされている数が記述されているため、音楽レコーダ１０００は、“Ｌｉｎｋ Ｃｏｕｎｔ”に基づいて、当該ＴＬへのリンクを削除する。
【０２４９】
また、ＴｒａｃｋＬｉｎｋｓストリームファイルからＴＬ構造体を削除した場合、他のＴＬ＿ＩＤが、“１”づつ小さくなる（ＴＬ＿ＩＤは、並び順のため）。このため、全てのＴＧに対して、削除したＴＬのＴＬ＿ＩＤ、及び当該ＴＬ以降のＴＬ＿ＩＤのメンテナンスが必要となる。
【０２５０】
すなわち、音楽レコーダ１０００は、削除されたＴＬ＿ＩＤの値よりも大きな値のＴＬ＿ＩＤをリンクしているＴＧのメンテナンスを実行する。具体的には、当該ＴＬ＿ＩＤの値が、それぞれ“１”減らされる。
【０２５１】
図２４は、図２３に示した“タイトル削除”のフローの変更部分を示している。図２４に示すステップＳ１１４１及びステップＳ１１４２の処理は、図２３に示すＳ１１７０の処理に代えて、実行される。
【０２５２】
ステップＳ１１４１において、音楽レコーダ１０００は、削除するＴＬ構造体をリンクしているＴＧから、当該ＴＬのリンクを削除する
ステップＳ１１４２において、音楽レコーダ１０００は、当該ＴＬ構造体のＶａｌｉｄビッドをＯＦＦにするとともに、当該ＴＬ構造体をリンクしているＴＧから、当該ＴＬへのリンクを削除する
なお、この場合、上述したＴＬ＿ＩＤのメンテナンスは必要ない。つまり、ＴＬ構造体自体は削除されないためＴＬ＿ＩＤが変化しない。ただし、ＴＧに対しては、削除したＴＬ＿ＩＤの削除が必要となる。この簡易的な方法によれば、次回ＴＬを追加する場合、ＶａｌｉｄビッドがＯＦＦとなっている領域を再使用することができる。
【０２５３】
（１３）プリセットモデルにおける購入
図２５は、リムーバブルＨＤＤ１１２６に予め暗号化された音楽コンテンツ（オーディオデータ）が記録されたプリセットモデルにおいて、ユーザが、所望の音楽コンテンツを購入するフローを示している。
【０２５４】
プリセットモデルの場合、オーディオデータ（ＡｕｄｉｏＤａｔａストリームファイル）は、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルに記録される。また、ＴＬは、プリセットモデル専用にＰＲＴＬｓストリームファイルに記録される。ユーザは、このようにオーディオデータや各種ファイルが記録されたリムーバブルＨＤＤ１１２６を入手（購入）する。
【０２５５】
この状態では、ユーザは、リムーバブルＨＤＤ１１２６に記録されている音楽コンテンツ（オーディオデータ）を視聴することができないため、購入手続きを行う必要がある。具体的には、図２５に示すように、ステップＳ１２１０において、ユーザは、音楽レコーダ１０００による高速検索（図２０参照）などを利用して、購入する音楽コンテンツを選択する。
【０２５６】
ステップＳ１２２０において、ユーザは、当該音楽コンテンツを視聴するためのライセンス（復号鍵及び利用条件）を購入する。具体的には、ユーザは、コンテンツサーバ１１３２などにアクセスして、当該ライセンスを購入する。
【０２５７】
ユーザによってライセンスが購入されると、ステップＳ１２３０において、音楽レコーダ１０００は、購入した音楽コンテンツに係るＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルに含まれるライセンス管理情報である“Ｌｉｃｅｎｓｅ Ｆｌａｇ”をセットすると同時に、*ＵＤＦ＿ＬＩＣＥＮＣＥセキュアストリームファイルを生成する。
【０２５８】
ステップＳ１２４０において、音楽レコーダ１０００は、当該ＴＬをＰＲＴＬｓストリームファイルからＴｒａｃｋＬｉｎｋｓストリームファイルに移動する（詳細については、上述した図７及び図８に係る説明を参照）。なお、ＰＲＴＬｓストリームファイルにおけるタイトルは、図２４に示した簡易的な方法によって削除される。
【０２５９】
（作用・効果）
以上説明した本実施形態及び本実施例によれば、音楽コンテンツなどのオーディオデータを利用するユーザは、トラックリンク情報及びメタデータ管理情報（ＭｅｔａＤａｔａストリームファイル）を含むＡＵＤ＿ＳＥＴ．ＭＧＲファイルを用いるため、音楽コンテンツの検索、再生がさらに容易かつ速やかに行え、音楽コンテンツの取扱いに係る利便性を向上させることができる。
【０２６０】
（その他の実施形態）
上述したように、本発明の一実施形態を通じて本発明の内容を開示したが、この開示の一部をなす論述及び図面は、本発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施の形態が明らかとなろう。
【０２６１】
例えば、上述した本発明の実施形態では、音楽コンテンツ（オーディオデータ）を例として説明したが、本発明は、音楽コンテンツのみではなく、例えば、静止画像や動画のコンテンツに適用することもできる。
【０２６２】
また、上述した本発明の実施形態では、リムーバブルＨＤＤ１１２６（リムーバブル記録媒体）を例として説明したが、本発明は、コンテンツデータ記録装置などに内蔵されるハードディスクドライブ（ＨＤＤ）などにも適用することができる。
【０２６３】
このように、本発明は、ここでは記載していない様々な実施の形態などを含むことは、もちろんである。したがって、本発明の技術的範囲は、上述の説明から妥当な特許請求の範囲に係る発明特定事項によってのみ定められるものである。
【図面の簡単な説明】
【０２６４】
【図１】本発明の実施形態に係るファイルフォーマットの概要を示す図である。
【図２】本発明の実施形態に係るディレクトリ及びファイルの構成を示す図である。
【図３】本発明の実施形態に係るＡＵＤ＿ＳＥＴ．ＭＧＲの構成を示す図である。
【図４】本発明の実施形態に係るＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルの構成を示す図である。
【図５】本発明の実施形態に係る“Ｔｒａｃｋ＿Ｂａｓｅ”を用いたモデル構成例を示す図である。
【図６】本発明の実施形態に係る“Ｐｒｅｓｅｔ＿Ｔｒａｃｋ＿Ｂａｓｅ”を用いたモデル構成例を示す図である。
【図７】本発明の実施形態に係るモデル構成例において、暗号化された音楽コンテンツのライセンスが取得（購入）される前の状態を示す図である。
【図８】本発明の実施形態に係るモデル構成例において、暗号化された音楽コンテンツのライセンスが取得（購入）された後の状態を示す図である。
【図９】本発明の実施形態に係る音楽コンテンツ管理モデルの基本的な構成例を示す図である。
【図１０】本発明の実施形態において、音楽アルバムを管理する場合における構成例を示している。
【図１１】本発明の実施例に係る音楽レコーダ（コンテンツデータ記録装置）の構成を示す図である。
【図１２】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図１３】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図１４】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図１５】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図１６】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図１７】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図１８】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図１９】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図２０】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図２１】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図２２】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図２３】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図２４】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図２５】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図２６】本発明の実施例に係る音楽レコーダにおいて実行されるトラックリンクのソート動作を説明するためのモデル構成図である。
【符号の説明】
【０２６５】
１０，１０Ａ，１０Ａ１〜１０Ａ３，１０ＡＴ，１０Ｂ，１０ＰＬ１〜１０ＰＬ３，１０ＰＬＴ，１０ＰＴＢ，１０ＴＢ…ＴＧ（トラックグループ）
２０１〜２０Ｎ＋１，２１１〜２１Ｎ＋１…ＴＬ（トラックリンク）
３０１〜３０４，３０Ｍ…ＭＣ（記録済み音楽コンテンツ）
１００…ＲＯＯＴディレクトリ
１１０…ＡＵＲ＿ＲＯＯＴディレクトリ
１２０…ＡＵＤ＿ＳＥＴ．ＭＧＲ
１３０…ＲＴ＿ＡＵＲＳディレクトリ
１４０…ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイル
１０００…音楽レコーダ
１１０１…ＣＤ
１１０２…ＣＤドライブ
１１０４…ＡＡＣエンコーダ
１１０６…暗号化処理部
１１０８…復号化処理部
１１１０…ＡＡＣデコーダ
１１１２…Ｄ／Ａ変換部
１１１４…スピーカ
１１１６…制御部
１１１８…表示部
１１２０…リモコン受光部
１１２２…リモコン
１１２４…ＡＴＡインタフェース
１１２６…リムーバブルＨＤＤ
１１２８…モデム
１１３０…インターネット網
１１３２…コンテンツサーバ
１１３４…メタデータサーバ
【技術分野】
【０００１】
本発明は、複数のコンテンツデータのそれぞれが、個別ファイルとして記録される場合におけるコンテンツデータ構造、コンテンツデータ記録媒体及びコンテンツデータ記録装置に関する。
【背景技術】
【０００２】
従来、ＣＤ−ＲやＤＶＤなど、取り外し可能（リムーバブル）な記録媒体（以下、“リムーバブル記録媒体”と適宜省略する）にオーディオデータなどのコンテンツデータを記録するためのフォーマットとして、ＵＤＦ（Universal Disk Format）が広く用いられている。
【０００３】
また、ＵＤＦを拡張して、リムーバブル記録媒体に記録されるコンテンツデータの知的財産権（例えば、著作権）を保護するためのアクセス制御など、セキュリティの確保に関する機能を提供するセキュアＵＤＦの規格も策定されている（非特許文献１参照）。
【非特許文献１】“セキュアＵＤＦ規格１．００版（Secure UDF Specification Revision 1．00）”、［ｏｎｌｉｎｅ］、２００２年２月２６日、オスタ（ＯＳＴＡ）、全文、［平成１６年１１月２６日検索］、インターネット＜URL：http://www.osta.org/specs/pdf/SecureUDF_1_00.pdf＞
【発明の開示】
【発明が解決しようとする課題】
【０００４】
上述したように、セキュアＵＤＦでは、暗号化など、セキュリティの確保に関する様々な仕様が規定されているが、リムーバブル記録媒体に記録されているコンテンツデータを取り扱う利用者の利便性については、さらに改善の余地があった。
【０００５】
そこで、本発明は、このような状況に鑑みてなされたものであり、取り外し可能（リムーバブル）な記録媒体に記録されたオーディオデータなどのコンテンツデータの取扱いに係る利便性を向上させることができるコンテンツデータ構造、コンテンツデータ記録媒体及びコンテンツデータ記録装置を提供することを目的とする。
【課題を解決するための手段】
【０００６】
上述した問題を解決するため、本発明は、次のような特徴を有している。まず、本発明の第１の特徴は、複数のコンテンツデータのそれぞれが、個別ファイルとして記録されるコンテンツデータ記録媒体において用いられるコンテンツデータ構造であって、少なくとも前記コンテンツデータ記録媒体上における前記コンテンツデータの位置及びサイズを示すリンク情報セグメントと、前記コンテンツデータの内容を記述し、前記個別ファイルの検索に用いられるメタデータセグメントと、前記リンク情報セグメントと前記メタデータセグメントとを含む管理ファイル領域とを有し、前記管理ファイル領域を用いて、前記コンテンツデータ記録媒体にアクセスするアクセス装置に前記コンテンツデータを検索させることを要旨とする。
【０００７】
本発明の第２の特徴は、本発明の第１の特徴に係り、前記管理ファイルセグメントには、前記アクセス装置に前記コンテンツデータの再生を許可するライセンス管理情報セグメントが含まれることを要旨とする。
【０００８】
本発明の第３の特徴は、複数のコンテンツデータ（例えば、ＭＣ３０１，３０２）のそれぞれが、個別ファイルとして記録されるコンテンツデータ記録媒体（リムーバブルＨＤＤ１１２６）であって、少なくとも前記コンテンツデータ記録媒体上における前記コンテンツデータの位置及びサイズを示すリンク情報（例えば、ＴＬ２０１〜２０Ｎ＋１）と、前記コンテンツデータの内容を記述し、前記個別ファイルの検索に用いられるメタデータ（例えば、ＭｅｔａＤａｔａストリームファイル）と、前記リンク情報と前記メタデータとを含む管理ファイル（例えば、ＡＵＤ＿ＳＥＴ．ＭＧＲ１２０）とを有し、前記管理ファイルを用いて、前記コンテンツデータ記録媒体にアクセスするアクセス装置（音楽レコーダ１０００）に前記コンテンツデータを検索させることを要旨とする。
【０００９】
本発明の第４の特徴は、本発明の第３の特徴に係り、前記管理ファイルには、前記アクセス装置に前記コンテンツデータの再生を許可するライセンス管理情報（例えば、*ＵＤＦ＿ＬＩＣＥＮＣＥセキュアストリームファイル）が含まれることを要旨とする。
【００１０】
本発明の第５の特徴は、複数のコンテンツデータのそれぞれが、個別ファイルとして記録されるコンテンツデータ記録装置（例えば、音楽レコーダ１０００）であって、少なくとも前記コンテンツデータ記録媒体上における前記コンテンツデータの位置及びサイズを示すリンク情報を生成するリンク情報生成部（制御部１１１６）と、前記コンテンツデータの内容を記述し、前記個別ファイルの検索に用いられるメタデータを取得するメタ情報取得部（制御部１１１６及びモデム１１２８）と、前記リンク情報と前記メタデータとを含む管理ファイルを生成する管理ファイル生成部（制御部１１１６）と、前記管理ファイルを用いて、前記コンテンツデータを検索するコンテンツ検索部（制御部１１１６）とを有することを要旨とする。
【００１１】
本発明の第６の特徴は、本発明の第５の特徴に係り、前記管理ファイルには、前記コンテンツデータの再生を許可するライセンス管理情報が含まれており、前記ライセンス管理情報に基づいて、前記コンテンツデータを再生するコンテンツ再生部（復号化処理部１１０８及び制御部１１１６）をさらに有することを要旨とする。
【００１２】
かかる特徴によれば、コンテンツデータ（例えば、音楽コンテンツなどのオーディオデータ）を利用するユーザは、リンク情報及びメタデータ（例えば、音楽コンテンツのタイトルやアーティスト名）とを含む管理ファイルを用いるため、コンテンツデータの検索、再生がさらに容易かつ速やかに行え、コンテンツデータの取扱いに係る利便性を向上させることができる。
【発明の効果】
【００１３】
本発明の特徴によれば、取り外し可能（リムーバブル）な記録媒体に記録されたオーディオデータなどのコンテンツデータの取扱いに係る利便性を向上させることができるコンテンツデータ構造、コンテンツデータ記録媒体及びコンテンツデータ記録装置を提供することができる。
【発明を実施するための最良の形態】
【００１４】
次に、本発明の実施形態の一例について、図面を参照しながら説明する。なお、以下の図面の記載において、同一または類似の部分には、同一または類似の符号を付している。
【００１５】
（本実施形態に係るコンテンツデータ構造）
まず、本実施形態に係るコンテンツデータ構造、具体的には、ハードディスクや、書き換え可能な光ディスク、メモリカードなどのリムーバブル記録媒体に音楽コンテンツ（オーディオデータ）を蓄積する場合に用いられるファイルフォーマットの概要、ディレクトリ構成、及び各ファイル構成について説明する。
【００１６】
（１） ファイルフォーマットの概要
図１は、本実施形態に係るファイルフォーマット（オーディオフォーマット）の概要を示している。“記録済音楽コンテンツ”（Recorded Music Contents、以下、ＭＣと省略する）は、リムーバブル記録媒体に蓄積される音楽コンテンツの実体である。
【００１７】
（１．１）記録済音楽コンテンツ（Recorded Music Contents）
ＭＣ３０１，３０２は、ＣＤをリッピングしたり、通信ネットワークを介して配信されたりしたコンテンツである。
【００１８】
ＭＣ３０１，３０２は、音楽でいうところの１曲で構成される場合、及び複数曲で構成される場合がある。いわゆる“音楽アルバム”という単位は、１つのＭＣで表現することも可能である。なお、“トラック”は、音楽１曲分で構成され、“音楽アルバム”は、複数の曲によって構成される。
【００１９】
また、ＭＣ３０１，３０２は、音楽コンテンツのみではなく、当該音楽コンテンツのメタデータ（曲のタイトルやアーティスト名など）を含む。
【００２０】
さらに、音楽コンテンツが暗号化されている場合には、ＭＣ３０１，３０２は、暗号化された当該音楽コンテンツを復号するための復号鍵や、当該音楽コンテンツの利用条件などが記載されたライセンスファイルとの関連性を示す情報を有する。なお、ＭＣ３０１，３０２に含まれる音楽コンテンツ（オーディオデータ）は、圧縮された状態でリムーバブル記録媒体に記録することも、もちろん可能である。
【００２１】
（１．２）トラックリンク（Track Link）
“トラックリンク”（Track Link、以下ＴＬと省略する）は、ＭＣの中の１曲へのリンク情報（トラックリンク情報）である。ＴＬ２０１〜２０Ｎ＋１によって、音楽コンテンツへの１曲単位のアクセスが可能となる。また、ＴＬ２０１〜２０Ｎ＋１は、ＭＣ３０１，３０２へのトラックリンク情報以外に、ＴＬのＩＤ、ユーザの検索・提示用のメタデータ、最後に再生された音楽コンテンツの位置を記録するリジューム情報、及び後述する“トラックグループ”からのリンク数を記録するリンクカウント情報などを有する。
【００２２】
（１．３）トラックグループ（Track Group）
“トラックグループ”（Track Group、以下ＴＧと省略する）は、ＴＬの集合体（ＴＬのリストで表現される）、またはＴＧの集合体（ＴＧのリストで表現される）である。
【００２３】
ＴＬの集合体によって表現されるＴＧ１０は、当該リストの順序に意味がある場合と、意味がない場合とに区別される。例えば、“音楽アルバム”や、ユーザが気に入った曲を集めた“プレイリスト”などは、リストの順序に意味がある。なお、“プレイリスト”は、ユーザが自由に作成可能であり、複数の曲のリストによって構成される。
【００２４】
一方、ＴＧ１０が、リムーバブル記録媒体に記録された全曲を管理する“基本トラックセット”である場合、リストの順序に意味がない。また、ＴＧの集合体で表現されるＴＧは、リストの順序に意味がない。当該ＴＧの使用例としては、プレイリストを集めたトッププレイリストなどがある。
【００２５】
ＴＧには、グループリストや、ＴＧのＩＤが記録される。また、リストの順序に意味がある場合、リジューム情報などが記録される。
【００２６】
（２）ディレクトリ・ファイル構成
図２は、本実施形態において用いられるディレクトリ及びファイルの構成（ファイルシステム）を示している。なお、本実施形態では、ファイルシステムとして、セキュアＵＤＦが使用される。
【００２７】
ＡＵＲ＿ＲＯＯＴディレクトリ１１０は、ＲＯＯＴディレクトリ１００の配下に位置し、音楽コンテンツ（オーディオデータ）をリムーバブル記録媒体に記録するアプリケーションのルートディレクトリ、つまり、オーディオフォーマット用のルートディレクトリである。
【００２８】
ＡＵＤ＿ＳＥＴ．ＭＧＲ１２０は、リムーバブル記録媒体に記録済みである全ての音楽コンテンツを管理するファイルである。なお、ＡＵＤ＿ＳＥＴ．ＭＧＲ１２０では、上述したＴＬやＴＧも管理される。
【００２９】
ＲＴ＿ＡＵＲＳディレクトリ１３０は、音楽コンテンツの実体が記録されているディレクトリである。具体的には、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイル１４０が音楽コンテンツの実体である。“ｘｘｘｘｘｘｘ”には、７桁（００００００００〜９９９９９９９まで）の数字（ＡＳＣＩＩコード）が記述される。
【００３０】
（３）ＡＵＤ＿ＳＥＴ．ＭＧＲの構成
図３は、ＡＵＤ＿ＳＥＴ．ＭＧＲの構成を示している。主ファイルであるＡＵＤ＿ＳＥＴ．ＭＧＲ１２０には、ＵＤＦによって定義されるストリームファイルがいくつか付属している。ＡＵＤ＿ＳＥＴ．ＭＧＲ１２０は、ユーザインタフェースへのエントリ情報、ＴＬ及びＴＧの管理情報を有する。
【００３１】
ＴｒａｃｋＬｉｎｋｓストリームファイルは、再生可能な状態の全てのトラックリンク情報を管理する。ＴＧ＿００００は、ＴｒａｃｋＬｉｎｋｓストリームファイルに記述されている全トラックを管理しているＴＧであり、リムーバブル記録媒体を使用する装置（例えば、コンテンツデータ記録装置）によってメンテナンスが実行される。
【００３２】
ＰＲＴＬｓストリームファイルは、再生可能な状態にない全てのトラックリンク情報を管理している。ＴＧ＿９９９９は、ＰＲＴＬｓに記述されている全トラックを管理しているＴＧであり、プリセットモデルの場合にのみ存在する。ＴＧ＿ｘｘｘｘは、ユーザあるいは機器が自由に定義できるＴＧである。ｘｘｘｘは、４桁（００００〜９９９９まで）の数字（ＡＳＣＩＩコード）が記述される。なお、プリセットモデルの内容については、後述する。
【００３３】
（３．１）ＡＵＤ＿ＳＥＴ．ＭＧＲファイル
主ファイルであるＡＵＤ＿ＳＥＴ．ＭＧＲ１２０は、表１に示すようなモジュールの列、すなわち、（ｉ）ユーザインタフェースエントリ情報、（ｉｉ）トラックリンク管理情報、及び（ｉｉｉ）トラックグループ管理情報によって構成される。
【表１】
【００３４】
（３．１．１）ユーザインタフェースエントリ情報
ユーザインタフェースエントリ情報は、表２に示すようなエントリ構造を有する。
【表２】
【００３５】
“Ａｕｄｉｏ Ｆｏｒｍａｔ Ｉｄｅｎｔｉｆｉｅｒ”には、ＡＳＣＩＩコードによって、“ＡＵＤＩＯ”と記述される。“Ｂｏｏｋ Ｖｅｒｓｉｏｎ”には、ブックのバージョンが記述される。バージョン１．０の場合は、“０ｘ１０”と記述する。
【００３６】
“Ｆｌａｇ”は、表３に示すような構造を有する。
【表３】
【００３７】
“Ｒｅｓｅｒｖｅｄ”（ｂｉｔ７〜１）は、将来のためにリザーブされているビットであり、０ｂに設定される。“Ｐｒｅｓｅｔ”（ｂｉｔ０）は、プリセットモデルなどにおいて、ライセンスを購入していない音楽コンテンツが存在する場合には１ｂ、当該音楽コンテンツが存在しない場合には０ｂに設定される。
【００３８】
“Ｌａｓｔ Ａｃｃｅｓｓｅｄ ＵＩＥ ＴＧ＿ＩＤ”（表２参照）には、最後にアクセスしたＴＧのＩＤが記述される。Ｌａｓｔ Ａｃｃｅｓｓｅｄ ＵＩＥ ＴＧ＿ＩＤは、リジュームポイント（Ｒｅｓｕｍｅ Ｐｏｉｎｔ）に使用される。
【００３９】
“Ｒｅｓｕｍｅ Ｓｕｐｐｏｒｔ Ｆｌａｇ”は、表４に示すような構造を有する。
【表４】
【００４０】
“Ｒｅｓｅｒｖｅｄ”（ｂｉｔ７〜１）は、将来のためにリザーブされているビットであり、０ｂに設定される。“Ｒｅｓｕｍｅ”（ｂｉｔ０）は、リジューム機能をサポートしている機器では１ｂ、リジューム機能をサポートしていない機器では０ｂと記述される。
【００４１】
“Ｌａｓｔ Ａｃｃｅｓｓｅｄ ＵＩＥ ＴＧ＿ＩＤ ｒｅｃｏｒｄｅｄ Ｄａｔｅ”（表２参照）には、最後にアクセスしたＴＧのＩＤが記録された時刻が記述される。“ＴＩＭＥ”フォーマットは、１４バイト分のＡＳＣＩＩコードによって、次のように表現される。すなわち、西暦４桁、月２桁、日２桁、時２桁（２４時間表示）、分２桁、及び秒２桁で表現される。タイマーを有しない機器の場合では、オール０に設定される。
【００４２】
“Ｎｕｍｂｅｒ ｏｆ ＵＩＥ ＴＧｓ”には、ＡＵＤ＿ＳＥＴ．ＭＧＲ１２０の配下に位置するユーザインタフェースのエントリとなる最上位ＴＧのＩＤの総数が記述される。
【００４３】
“ＵＩＥ ＴＧ＿ＩＤ（１） ｆｏｒ Ｂａｓｅ Ｔｒａｃｋ Ｓｅｔ”には、１番目のＵＩＥ ＴＧ＿ＩＤが記述される。具体的には、ＡＳＣＩＩコードで００００が記述される。当該ＵＩＥ ＴＧ＿ＩＤは、ストリームファイルＴＧ＿００００に対応している。ＵＩＥ ＴＧ＿ＩＤは、ストリームファイルＴＧ＿ｘｘｘｘのうち、ｘｘｘｘに対応する。ＴＧ＿００００は、全トラックを管理するＴＧとして必ず存在する。
【００４４】
“ＵＩＥ ＴＧ＿ＩＤ（１） Ｎａｍｅ”には、ＡＳＣＩＩコードでＵＩＥ ＴＧ＿ＩＤ（１）の名前が記述される。すなわち、対応するＴＧ構造体のＴＧ Ｓｐｅｃｉｆｉｃ Ｓｔｒｕｃｔｕｒｅ Ｎａｍｅがコピーされる。具体的には、ＵＩＥ ＴＧ＿ＩＤ（１） Ｎａｍｅ”には、ＴｒａｃｋＳｅｔＢａｓｅと記述される。
【００４５】
“ＵＩＥ ＴＧ＿ＩＤ（２）”には、２番目のＵＩＥ ＴＧ＿ＩＤが記述される。具体的には、４桁の数字がＡＳＣＩＩコードで記述される。４桁の数字は、ストリームファイルＴＧ＿ｘｘｘｘに対応している。
【００４６】
“ＵＩＥ ＴＧ＿ＩＤ（２） Ｎａｍｅ”には、“ＵＩＥ ＴＧ＿ＩＤ（１） Ｎａｍｅ”と同様に、ＡＳＣＩＩコードでＵＩＥ ＴＧ＿ＩＤ（２）の名前が記述される。
【００４７】
“ＵＩＥ ＴＧ＿ＩＤ（ｎ）”には、ｎ番目のＵＩＥ ＴＧ＿ＩＤが記述される。具体的には、４桁の数字がＡＳＣＩＩコードで記述される。４桁の数字は、ストリームファイルＴＧ＿ｘｘｘｘに対応している。また、“ＵＩＥ ＴＧ＿ＩＤ（ｎ） Ｎａｍｅ”には、“ＵＩＥ ＴＧ＿ＩＤ（１） Ｎａｍｅ”と同様に、ＡＳＣＩＩコードでＵＩＥ ＴＧ＿ＩＤ（ｎ）の名前が記述される。
【００４８】
（３．１．２）トラックリンク管理情報
トラックリンク管理情報は、表５に示すようなエントリ構造を有する。
【表５】
【００４９】
“Ｔｒａｃｋ Ｌｉｎｋ Ｌｏｃａｔｉｏｎ”には、ＴＬが記録されるファイル名（ＴｒａｃｋＬｉｎｋｓ）が、ＡＳＣＩＩコードで記述される。
【００５０】
“Ｐｒｅｒｅｃｏｒｄｅｄ Ｔｒａｃｋ Ｌｉｎｋ Ｌｏｃａｔｉｏｎ”には、リムーバブル記録媒体の購入時から記録されているＴＬが記録されるファイル名が、ＡＳＣＩＩコードで記述される。“Ｐｒｅｒｅｃｏｒｄｅｄ Ｔｒａｃｋ Ｌｉｎｋ Ｌｏｃａｔｉｏｎ”は、プリセットモデルにおいて使用される。プリセットモデルの場合、“Ｐｒｅｒｅｃｏｒｄｅｄ Ｔｒａｃｋ Ｌｉｎｋ Ｌｏｃａｔｉｏｎ”には、ＰＲＴＬｓと記述される。プリセットモデル以外では、“Ｐｒｅｒｅｃｏｒｄｅｄ Ｔｒａｃｋ Ｌｉｎｋ Ｌｏｃａｔｉｏｎ”は、無視される。
【００５１】
（３．１．３）トラックグループ管理情報
トラックグループ管理情報は、表６に示すようなエントリ構造を有する。
【表６】
【００５２】
“Ｎｕｍｂｅｒ ｏｆ Ｔｒａｃｋ Ｇｒｏｕｐｓ”には、ＴＧの総数が記述される。“Ｍａｘｉｍｕｍ Ｔｒａｃｋ Ｇｒｏｕｐ ＩＤ”には、ＴＧ＿ＩＤの最大値が記述される。具体的には、４桁の数字がＡＳＣＩＩコードで記述される。ただし、“９９９９”は、プリセットモデル用として割り当てられるため、当該最大値として考慮しない。
【００５３】
（３．２）ＴｒａｃｋＬｉｎｋｓストリームファイル・ＰＲＴＬｓストリームファイル
ＴｒａｃｋＬｉｎｋｓストリームファイル及びＰＲＴＬｓストリームファイルは、表７に示すような構造を有する。
【表７】
【００５４】
“Ｎｕｍｂｅｒ ｏｆ Ｔｒａｃｋ Ｌｉｎｋｓ”には、ＴｒａｃｋＬｉｎｋｓストリームファイルまたはＰＲＴＬｓストリームファイルに含まれているＴＬの総数が記述される。“Ｎｕｍｂｅｒ ｏｆ Ｖａｌｉｄ Ｔｒａｃｋ Ｌｉｎｋｓ”には、ＴｒａｃｋＬｉｎｋｓストリームファイル及びＰＲＴＬｓストリームファイルに含まれているＴＬの中で有効なＴＬ数が記述される。
【００５５】
“Ｔｒａｃｋ Ｌｉｎｋ Ｉｎｆｏｒｍａｔｉｏｎ（１）〜（ｎ）”は、ＴＬ構造体がｎ個並んだ構造である。ｎは、“Ｎｕｍｂｅｒ ｏｆ Ｔｒａｃｋ Ｌｉｎｋｓ”フィールドの数値である。ＴＬのＩＤは、表７に示したように、“１”から昇順で割り当てられる。
【００５６】
なお、本実施形態では、ＴｒａｃｋＬｉｎｋｓストリームファイルのＴＬのＩＤは、ＴＬ＿ＩＤと表記され、ＰＲＴＬｓストリームファイルのＴＬのＩＤは、ＰＲＴＬ＿ＩＤと表記される。
【００５７】
（３．２．１）ＴＬ構造体
ＴＬ構造体は、表８に示すような構造を有する。
【表８】
【００５８】
“ＴＬ ＴＹＰＥ”には、ＴＬ Ｓｐｅｃｉｆｉｃな構造体のＴＹＰＥ（表９参照）が記述される。なお、本実施形態では、日本方式（ＴＹＰＥ１）が定義されている。
【表９】
【００５９】
“Ｌｅｎｇｔｈ ｏｆ Ｓｔｒｕｃｔｕｒｅ”（表８参照）には、ＴＬ構造体の長さ（バイト数）が記述される。
【００６０】
“ＴＬ Ｆｌａｇ”は、表１０に示すような構造を有する。
【表１０】
【００６１】
“Ｖ（ｂｉｔ７）”には、ＴＬ構造体が有効であるか否かを示す情報が記述される。具体的には、ＴＬ構造体が有効である場合、“Ｖ（ｂｉｔ７）”は、１ｂに設定される。ＴＬ構造体が無効である場合、“Ｖ（ｂｉｔ７）”は、０ｂに設定される。“Ｖ（ｂｉｔ７）”は、ＴＬ構造体の簡易消去に利用される。
【００６２】
“Ｒｅｓｅｒｖｅｄ（ｂｉｔ６〜３）”は、将来のためにリザーブされているビットであり、０ｂに設定される。“ＰＳ（ｂｉｔ２）”では、プリセットモデルに係る曲へのリンクの場合には１ｂ、そうでない場合には０ｂが設定される。
【００６３】
“ＰＥ（ｂｉｔ１）”では、再生可能な曲へのリンクの場合、つまり、その曲のライセンスを有している場合、またはその曲が暗号化されてない場合には１ｂ、再生が不可能な場合、つまり、その曲が暗号化されており、その曲のライセンスを有していない場合には０ｂが設定される。
【００６４】
“Ｐａｒｔ（ｂｉｔ０）”では、ＭＣとして複数曲が記録されている場合であって、その一部を指定する場合には、１ｂに設定される。ＭＣが１曲の場合には、０ｂとに設定される。“Ｐａｒｔ（ｂｉｔ０）”が１ｂのときに限って、“Ｓｔａｒｔ Ｐｏｉｎｔ ｉｎ Ｃｏｎｔｅｎｔｓ Ｆｉｌｅ”及び“Ｃｏｎｔｅｎｔ Ｌｅｎｇｔｈ”フィールドが有効となる。
【００６５】
“Ｌｉｎｋ Ｃｏｕｎｔ”（表８参照）には、ＴＧからリンクされているリンク総数が記述される。“Ｍｕｓｉｃ Ｃｏｎｔｅｎｔｓ ＩＤ”には、Ｍｕｓｉｃ Ｃｏｎｔｅｎｔｓ ＩＤが記述される。具体的には、コンテンツファイルのＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルのｘｘｘｘｘｘｘに相当する数字がＡＳＣＩＩコードで記述される。
【００６６】
“Ｓｔａｒｔ Ｐｏｉｎｔ ｉｎ Ｃｏｎｔｅｎｔｓ Ｆｉｌｅ”では、音楽コンテンツファイルのリンク開始位置が、当該ファイルの先頭からのバイト位置によって指定される。“Ｃｏｎｔｅｎｔ Ｌｅｎｇｔｈ”には、音楽コンテンツファイルへのリンク範囲（バイト長）が記述される。上述したように、ＴＬ＿ＦｌａｇのＰａｒｔビット（表１０参照）が１ｂの場合にのみ、“Ｓｔａｒｔ Ｐｏｉｎｔ ｉｎ Ｃｏｎｔｅｎｔｓ Ｆｉｌｅ”及びＣｏｎｔｅｎｔ Ｌｅｎｇｔｈ”フィールドが有効となる。
【００６７】
“Ｌａｓｔ Ａｃｃｅｓｓｅｄ Ｔｉｍｅ”には、最後に再生された音楽コンテンツファイルへのアクセス時刻が記録される。“Ｒｅｓｕｍｅ Ｐｏｉｎｔ”では、音楽コンテンツファイル（ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイル）の再生開始位置が、当該ファイルの先頭からのバイト位置によって指定される。
【００６８】
“Ｐｌａｙｂａｃｋ Ｃｏｕｎｔｅｒ”には、再生開始を指示した回数が記述される。なお、“Ｐｌａｙｂａｃｋ Ｃｏｕｎｔｅｒ”フィールドに記述される回数には、リジュームによる再生は含まない。“Ｍｙ Ｒａｔｉｎｇ Ｉｎｆｏ”には、ユーザによって入力される１０段階の重み付け情報が記述される。
【００６９】
“Ｃｈａｒａｃｔｅｒ Ｓｅｔ ｏｆ Ｍｅｔａｄａｔａ”では、メタデータフィールドの文字コード（表１１参照）が定義される。
【表１１】
【００７０】
“Ｔｉｔｌｅ（ＭｅｔａＤａｔａ、以下ＭＤ）”（表８参照）には、トラックタイトルが記述される。文字コードは、“Ｃｈａｒａｃｔｅｒ Ｓｅｔ ｏｆ Ｍｅｔａｄａｔａ”フィールドにおいて指定されたものが使用される。トラックタイトルの終端は、ＮＵＬＬ文字を格納することによって行われる。
【００７１】
“Ｔｉｔｌｅカナ（ＭＤ）”には、トラックタイトルの検索用カナが、全角カタカナによって記述される。文字コードは、“Ｃｈａｒａｃｔｅｒ Ｓｅｔ ｏｆ Ｍｅｔａｄａｔａ”フィールドにおいて指定されたものが使用される。トラックタイトルの終端は、ＮＵＬＬ文字を格納することによって行われる。
【００７２】
“Ａｒｔｉｓｔ Ｎａｍｅ（ＭＤ）”には、アーティスト名が記述される。文字コードは、“Ｃｈａｒａｃｔｅｒ Ｓｅｔ ｏｆ Ｍｅｔａｄａｔａ”フィールドにおいて指定されたものが使用される。トラックタイトルの終端は、ＮＵＬＬ文字を格納することによって行われる。
【００７３】
“Ａｒｔｉｓｔ Ｎａｍｅカナ（ＭＤ）”には、アーティスト名の検索用カナが、全角カタカナによって記述される。文字コードは、“Ｃｈａｒａｃｔｅｒ Ｓｅｔ ｏｆ Ｍｅｔａｄａｔａ”フィールドにおいて指定されたものが使用される。トラックタイトルの終端は、ＮＵＬＬ文字を格納することによって行われる。
【００７４】
“Ｇｅｎｒｅ（ＭＤ）”には、ジャンルが記述される。文字コードは、“Ｃｈａｒａｃｔｅｒ Ｓｅｔ ｏｆ Ｍｅｔａｄａｔａ”フィールドにおいて指定されたものが使用される。トラックタイトルの終端は、ＮＵＬＬ文字を格納することによって行われる。
【００７５】
“Ｇｅｎｒｅカナ（ＭＤ）”には、ジャンルの検索用カナが、全角カタカナによって記述される。文字コードは、“Ｃｈａｒａｃｔｅｒ Ｓｅｔ ｏｆ Ｍｅｔａｄａｔａ”フィールドにおいて指定されたものが使用される。トラックタイトルの終端は、ＮＵＬＬ文字を格納することによって行われる。
【００７６】
“Ｃｏｍｐｏｓｅｒ（ＭＤ）”には、作曲者名が、全角カタカナによって記述される。文字コードは、“Ｃｈａｒａｃｔｅｒ Ｓｅｔ ｏｆ Ｍｅｔａｄａｔａ”フィールドにおいて指定されたものが使用される。トラックタイトルの終端は、ＮＵＬＬ文字を格納することによって行われる。
【００７７】
“Ａｌｂｕｍ Ｔｉｔｌｅ（ＭＤ）”には、音楽アルバム（ＣＤ）のタイトルが、全角カタカナによって記述される。文字コードは、“Ｃｈａｒａｃｔｅｒ Ｓｅｔ ｏｆ Ｍｅｔａｄａｔａ”フィールドにおいて指定されたものが使用される。トラックタイトルの終端は、ＮＵＬＬ文字を格納することによって行われる。
【００７８】
“Ｔｒａｃｋ Ｎｕｍｂｅｒ ｉｎ ＣＤ（ＭＤ）”では、音楽アルバムの場合におけるトラック番号が記述される。
【００７９】
（３．３）ＴＧ＿ｘｘｘｘストリームファイル
ＴＧ＿ｘｘｘｘストリームファイルは、表１２に示すような構造を有する。
【表１２】
【００８０】
“ＴＧ Ｓｐｅｃｉｆｉｃ Ｓｔｒｕｃｔｕｒｅ ＴＹＰＥ”には、ＴＧ Ｓｐｅｃｉｆｉｃな構造体のＴＹＰＥ（表１３参照）が記述される。
【表１３】
【００８１】
“ＴＧ Ｆｌａｇ”は、表１４に示すような構造を有する。
【表１４】
【００８２】
“Ｒｅｓｅｒｖｅｄ（ｂｉｔ７〜２）”は、将来のためにリザーブされているビットであり、０ｂに設定される。なお、このビットは、文字コードの識別情報用として使用される予定である。
【００８３】
“ＴＬ/ＴＧ（ｂｉｔ１）”では、ＴＬのリストの場合には１ｂ、ＴＧのリストの場合には０ｂに設定される。“Ｓ/Ｇ（ｂｉｔ０）”では、リストの順序が再生順である場合には１ｂ、再生順でない場合には０ｂに設定される。
【００８４】
“ＴＧ Ｓｐｅｃｉｆｉｃ Ｓｔｒｕｃｔｕｒｅ Ｎａｍｅ”（表１２参照）には、ＴＧ Ｓｐｅｃｉｆｉｃな構造体の名前が、ＡＳＣＩＩコードで記述される。“Ｌｉｎｋ Ｃｏｕｎｔ”には、ＴＧからリンクされているリンク総数が記述される。なお、ユーザインタフェースエントリ情報から参照されている場合も、リンク数１としてカウントされる。
【００８５】
“Ｒｅｓｕｍｅ ｅｌｅｍｅｎｔ”には、リジュームのエレメントの番号が記述される。当該番号は、ｅｌｅｍｅｎｔ ＩＤ（ｘ）のｘに相当する番号である。“Ｒｅｓｕｍｅ ｅｌｅｍｅｎｔ”は、ＴＧ＿ＦｌａｇのＳ／Ｇビットが１の場合にのみ有効となる。
【００８６】
“ＴＧ Ｓｐｅｃｉｆｉｃ Ｓｔｒｕｃｔｕｒｅ ＴＹＰＥ Ｓｐｅｃｉｆｉｃ Ａｒｅａ”は、ＴＧ Ｓｐｅｃｉｆｉｃな構造体に依存した構造を定義するための領域である。“Ｎｕｍｂｅｒ ｏｆ ｅｌｅｍｅｎｔｓ”には、ＴＧに属するｅｌｅｍｅｎｔの総数が記述される。“ｅｌｅｍｅｎｔ ＩＤ（１）〜（ｎ）”には、各ｅｌｅｍｅｎｔ ＩＤが記述される。
【００８７】
“ｅｌｅｍｅｎｔ ＩＤ（１） Ｎａｍｅ〜ｅｌｅｍｅｎｔ ＩＤ（ｎ） Ｎａｍｅ”には、ｅｌｅｍｅｎｔ ＩＤの名前が記述される。
【００８８】
（３．３．１）ＴＧ＿００００ストリームファイル
ＴＧ＿００００ストリームファイルは、ＴｒａｃｋＬｉｎｋｓストリームファイルによって管理されているＴＬを管理するＴＧである。上述したＴＧ＿ｘｘｘｘ構造体（ＴＧ＿ｘｘｘｘストリームファイル）で定義されるが、次のような制約がある。
【００８９】
・ ＴＧ Ｓｐｅｃｉｆｉｃ Ｓｔｒｕｃｔｕｒｅ ＴＹＰＥ ＝ ０ｘ００
・ ＴＧ Ｆｌａｇ ＝ ０ｘ２
・ ＴＧ Ｓｐｅｃｉｆｉｃ Ｓｔｒｕｃｔｕｒｅ Ｎａｍｅ ＝ Ｔｒａｃｋ＿Ｂａｓｅ
・ Ｌｉｎｋ Ｃｏｕｎｔ ＝ ０
・ Ｎｕｍｂｅｒ ｏｆ ｅｌｅｍｅｎｔｓ： ＴｒａｃｋＬｉｎｋｓストリームファイルによって管理されている有効なＴＬ数と一致する
・ ｅｌｅｍｅｎｔ ＩＤ（１）〜（ｎ）： ＴＬ＿ＩＤが記述される
（３．３．２）ＴＧ＿９９９９ストリームファイル
ＴＧ＿９９９９ストリームファイルは、プリセットモデルの場合にのみ、初期状態において存在し、ＰＲＴＬｓストリームファイルによって管理されているＴＬを管理するＴＧである。上述したＴＧ＿ｘｘｘｘ構造体（ＴＧ＿ｘｘｘｘストリームファイル）で定義されるが、次のような制約がある。
【００９０】
・ ＴＧ Ｓｐｅｃｉｆｉｃ Ｓｔｒｕｃｔｕｒｅ ＴＹＰＥ ＝ ０ｘＦＦ
・ ＴＧ Ｆｌａｇ ＝ ０ｘ２
・ ＴＧ Ｓｐｅｃｉｆｉｃ Ｓｔｒｕｃｔｕｒｅ Ｎａｍｅ ＝ Ｐｒｅｓｅｔ＿Ｔｒａｃｋ＿Ｂａｓｅ
・ Ｌｉｎｋ Ｃｏｕｎｔ ＝ ０
・ Ｎｕｍｂｅｒ ｏｆ ｅｌｅｍｅｎｔｓ： ＰＲＴＬｓストリームファイルによって管理されている有効なＴＬ数と一致する
・ ｅｌｅｍｅｎｔ ＩＤ（１）〜（ｎ）： ＰＲＴＬ＿ＩＤが記述される
（３．３．３）ＴＧ＿ｘｘｘｘストリームファイル
ＴＧ＿ｘｘｘｘストリームファイルは、ＴＬのリストまたはＴＧのリストによって表現される。ＴＬのリストで表現される場合は、ｅｌｅｍｅｎｔ＿ＩＤには、ＴｒａｃｋＬｉｎｋｓストリームファイルによって管理されているＴＬ＿ＩＤが記述されなければならない。なお、ＰＲＴＬｓストリームファイルのＰＲＴＬ＿ＩＤは、参照することができない。
【００９１】
（４）ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルの構成
図４は、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルの構成を示している。同図に示すように、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイル１４０は、ＡｕｄｉｏＤａｔａストリームファイル（ＡｕｄｉｏＤａｔａ）、ＭｅｔａＤａｔａストリームファイル（ＭｅｔａＤａｔａ）、及び*ＵＤＦ＿ＬＩＣＥＮＣＥセキュアストリームファイル（*ＵＤＦ＿ＬＩＣＥＮＣＥ）によって構成されている。
【００９２】
（４．１）ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイル
主ファイルであるＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイル１４０は、表１５に示すようなモジュールの列、すなわち、（ｉ）オーディデータ管理情報、（ｉｉ）メタデータ管理情報、及び（ｉｉｉ）ライセンス管理情報によって構成される。
【表１５】
【００９３】
（４．１．１）オーディデータ管理情報
オーディデータ管理情報は、表１６に示すようなエントリ構造を有する。
【表１６】
【００９４】
“Ｎｕｍｂｅｒ ｏｆ Ｔｒａｃｋｓ”には、ＡｕｄｉｏＤａｔａストリームファイルに記録されているトラック数が記述される。
【００９５】
“ＡＵＤ Ｆｌａｇ”は、表１７に示すような構造を有する。
【表１７】
【００９６】
“Ｒｅｓｅｒｖｅｄ（ｂｉｔ７〜１）”は、将来のためにリザーブされているビットであり、０ｂに設定される。“Ｅｎｃ（ｂｉｔ０）”には、ＡｕｄｉｏＤａｔａストリームファイルのＴｒａｃｋ Ｄａｔａ部分が暗号化されている場合には１ｂ、暗号化されていない場合には０ｂに設定される。
【００９７】
“Ｐｌａｙｂａｃｋ Ｔｉｍｅ”（表１６参照）には、全トラックの再生時間が記述される。“Ｆｉｌｅ Ｓｉｚｅ”には、ＡｕｄｉｏＤａｔａストリームファイルのファイルサイズが記述される。“Ａｕｄｉｏ Ｆｏｒｍａｔ（Ｃｏｄｅｃ）”には、Ａｕｄｉｏ Ｆｏｒｍａｔ（表１８参照）が記述される。
【表１８】
【００９８】
“Ｂｉｔ Ｒａｔｅ”（表１６参照）には、ビットレート（単位：ｋｂｐｓ）が記述される。“Ｆｉｌｅ Ｃｒｅａｔｅ Ｄａｔｅ”には、ファイル作成日が記述される。“Ａｕｄｉｏ Ｆｉｌｅ Ｌｏｃａｔｉｏｎ”には、オーディオデータが記録されるファイル名が、ＡＳＣＩＩコードで記述（ＡｕｄｉｏＤａｔａと記述）される。
【００９９】
（４．１．２）メタデータ管理情報
メタデータ管理情報は、表１９に示すような構造を有する。
【表１９】
【０１００】
“Ｃｈａｒａｃｔｅｒ Ｓｅｔ ｉｎ Ｍｅｔａｄａｔａ Ｆｉｌｅ”では、ＭｅｔａＤａｔａストリームファイルの文字コード（表２０参照）が定義される。
【表２０】
【０１０１】
“ＭｅｔａＤａｔａ Ｆｏｒｍａｔ”には、ＴＧ Ｓｐｅｃｉｆｉｃな構造体のＴＹＰＥ（表２１参照）が記述される。
【表２１】
【０１０２】
“ＭｅｔａＤａｔａ Ｆｉｌｅ Ｌｏｃａｔｉｏｎ”（表１９参照）には、メタデータが記録されるファイル名が、ＡＳＣＩＩコードで記述（ＭｅｔａＤａｔａと記述）される。
【０１０３】
（４．１．３）ライセンス管理情報
ライセンス管理情報は、表２２に示すような構造を有する。
【表２２】
【０１０４】
“Ｌｉｃｅｎｓｅ Ｆｌａｇ”は、表２３に示すような構造を有する。
【表２３】
【０１０５】
“Ｒｅｓｅｒｖｅｄ（ｂｉｔ７〜２）”は、将来のためにリザーブされているビットであり、０ｂに設定される。
【０１０６】
“ＰＳ（ｂｉｔ１）”では、プリセットモデルの場合には１ｂ、そうでない場合には０ｂが設定される。“ＬＥ（ｂｉｔ０）”では、ライセンスが存在する場合には１ｂ、存在しない場合には０ｂに設定される。
【０１０７】
“Ｌｉｃｅｎｓｅ Ｆｉｌｅ Ｌｏｃａｔｉｏｎ”（表２２参照）には、ライセンス（復号鍵及び利用条件）が記録されるファイル名がＡＳＣＩＩコードで記述される。具体的には、Ｌｉｃｅｎｓｅ ＦｌａｇのＬＥビットが１ｂの場合のみ、*ＵＤＦ＿ＬＩＣＥＮＳＥと記述される。
【０１０８】
（４．２）ＡｕｄｉｏＤａｔａストリームファイル
ＡｕｄｉｏＤａｔａストリームファイルは、表２４に示すようなモジュールの列、すなわち、（ｉ）Ａｕｄｉｏ Ｄａｔａ Ｈｅａｄｅｒ及び（ｉｉ）Ｔｒａｃｋ Ｄａｔａによって構成される。
【表２４】
【０１０９】
（４．２．１）Ａｕｄｉｏ Ｄａｔａ Ｈｅａｄｅｒ
Ａｕｄｉｏ Ｄａｔａ Ｈｅａｄｅｒは、表２５に示すようなエントリ構造を有する。なお、Ａｕｄｉｏ Ｄａｔａ Ｈｅａｄｅｒは、暗号化の対象とならない。
【表２５】
【０１１０】
“Ｌｅｎｇｔｈ ｏｆ Ａｕｄｉｏ Ｄａｔａ Ｈｅａｄｅｒ”には、Ａｕｄｉｏ Ｄａｔａ Ｈｅａｄｅｒ長（バイト数）が記述される。“Ｎｕｍｂｅｒ ｏｆ Ｔｒａｃｋｓ”には、ＡｕｄｉｏＤａｔａストリームファイルに記録されているトラック数が記述される。“Ｌｅｎｇｔｈ ｏｆ Ｔｒａｃｋ Ｄａｔａ（＃１）〜（＃ｎ）には、Ｔｒａｃｋ Ｄａｔａ長（バイト数）が記述される。
【０１１１】
（４．２．２）Ｔｒａｃｋ Ｄａｔａ
Ｔｒａｃｋ Ｄａｔａには、Ａｕｄｉｏ Ｆｏｒｍａｔに準じたデータが記録される。なお、Ｔｒａｃｋ Ｄａｔａは、暗号化されている場合もある。
【０１１２】
（４．３）ＭｅｔａＤａｔａストリームファイル
ＭｅｔａＤａｔａストリームファイルは、表２６に示すような構造を有する。
【表２６】
【０１１３】
（４．４）*ＵＤＦ＿ＬＩＣＥＮＣＥセキュアストリームファイル
*ＵＤＦ＿ＬＩＣＥＮＣＥセキュアストリームファイルには、ライセンス（復号鍵及び利用条件）が記述されている。アプリケーションは、*ＵＤＦ＿ＬＩＣＥＮＣＥセキュアストリームファイルが存在すれば、暗号化されたＡｕｄｉｏＤａｔａストリームファイルを復号できる。
【０１１４】
（音楽コンテンツ管理モデル構成例）
次に、上述した本実施形態に係るコンテンツデータ構造を用いた音楽コンテンツの管理モデル構成例について説明する。
【０１１５】
（１）構成例１
図５は、“Ｔｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＴＢ）”を用いたモデル構成例を示している。
【０１１６】
Ｔｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＴＢ）は、視聴可能状態で記録されたトラックの全リストを管理しているＴＧである。なお、音楽コンテンツ（ＭＣ３０１，３０２）が暗号化されている場合には、復号するためのライセンスが必要となる。
【０１１７】
Ｔｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＴＢ）は、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの配下において、ＴＧ＿００００ストリームファイルとして存在する。Ｔｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＴＢ）は、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの配下において、ＴｒａｃｋＬｉｎｋｓストリームファイルとして管理されている全てのＴＬ（ＴＬ２０１〜２０Ｎ＋１）を管理する。
【０１１８】
（２）構成例２
図６は、Ｐｒｅｓｅｔ＿Ｔｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＰＴＢ）を用いたモデル構成例を示しているＰｒｅｓｅｔ＿Ｔｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＰＴＢ）は、“プリセットモデル”の場合にのみ存在するファイル（ＴＧ）である。
【０１１９】
プリセットモデルとは、暗号化された音楽コンテンツ（ＭＣ３０３，３０４）をリムーバブル記録媒体に記録した状態でユーザに販売し、ユーザは、表示されるリストの中から気に入ったトラックを購入するというビジネスモデルである。
【０１２０】
プリセットモデルでは、ユーザは、気に入ったトラックの購入時に暗号化された音楽コンテンツ（ＭＣ３０３，３０４）を復号するためのライセンスのみを取得すれば良い。このため、ユーザは、気に入ったトラック（音楽コンテンツ）をサーバなどからダウンロードする必要がなく、速やかに音楽コンテンツを購入できる。
【０１２１】
また、プリセットモデルでは、暗号化された音楽コンテンツ（ＭＣ３０３，３０４）は、視聴可能な音楽コンテンツと同様にＲＴ＿ＡＵＲＳディレクトリ１３０の配下に位置するＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイル１４０（図２参照）に記録される。ただし、当初は、ライセンス（*ＵＤＦ＿ＬＩＣＥＮＣＥセキュアストリームファイル）がない状態であるため、そのままでは、暗号化された音楽コンテンツ（ＭＣ３０３，３０４）は、再生することができない。
【０１２２】
ＴＬ２１１〜２１Ｎ＋１は、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの配下において、ＰＲＴＬｓストリームファイルとして管理され、視聴可能な音楽コンテンツを管理しているＴｒａｃｋＬｉｎｋｓストリームファイルとは別に管理される。
【０１２３】
さらに、プリセットモデルでは、視聴が不可能な状態で記録された、つまり、復号するためのライセンスを有していないトラックの全リストを管理しているＴＧが、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの配下において、ＴＧ＿９９９９ストリームファイルとして存在する。
【０１２４】
ＴＧ＿９９９９ストリームファイルは、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの配下に位置するＰＲＴＬｓストリームファイルとして管理されている全てのＴＬを管理する。ＰＲＴＬｓストリームファイルとして管理されているＴＬは、ユーザが定義するＴＧからリンクすることができないという制限を有する。
【０１２５】
ユーザが、暗号化された音楽コンテンツのライセンスを取得（購入）した場合、当該ＭＣに対応するＴＬは、ＰＲＴＬｓストリームファイルから削除され、ＴｒａｃｋＬｉｎｋｓストリームファイルに追加される。
【０１２６】
図７及び図８は、ユーザが、暗号化された音楽コンテンツのライセンスを取得（購入）した場合に、当該ＭＣに対応するＴＬが、ＰＲＴＬｓストリームファイルから削除され、ＴｒａｃｋＬｉｎｋｓストリームファイルに追加される様子を示している。
【０１２７】
図７は、ライセンス（復号鍵及び利用条件）の取得前における音楽コンテンツの管理状態を示している。図７に示すように、ＭＣ３０３，３０４については、ライセンスが取得済み（図において、“Ｌｉｃｅｎｃｅ”と表記されている）である。一方、ＭＣ３０１，３０２，３０Ｍについては、ライセンスがまだ取得されていない状態である。
【０１２８】
ここで、ユーザは、ＭＣ３０２のライセンスを新たに取得したものとする。図８は、ＭＣ３０２のライセンスが取得された後における音楽コンテンツの管理状態を示している。図８に示すように、ＰＲＴＬｓストリームファイルから、ＭＣ３０２に対応するＴＬ２１２が削除されている。
【０１２９】
一方、ＴｒａｃｋＬｉｎｋｓストリームファイルには、ＭＣ３０２に対応するＴＬとして、ＴＬ２０３（ＴＬ＿ＩＤ＃３）が追加されている。
【０１３０】
（３）構成例３
図９は、音楽コンテンツ（オーディオデータ）管理モデルの基本的な構成例を示している。図９に示すように、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルに含まれるユーザインタフェースエントリ情報（表２参照）に、最初にアクセスするべきＵＩＥ ＴＧ＿ＩＤのリストが存在する。
【０１３１】
図９に示した構成例では、２つのリストが存在する。１つは、ＴＧ＿ＩＤが００００であるＴｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＴＢ）であり、視聴可能な全てのＴＬを管理する。Ｔｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＴＢ）は、必ず存在し、コンテンツデータ記録装置は、Ｔｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＴＢ）の内容をメンテナンスする必要がある。
【０１３２】
もう１つは、ＴＧ＿ＩＤが０００１であり、プレイリストのエントリとなるＰｌａｙ Ｌｉｓｔ Ｔｏｐ（１０ＰＬＴ）である。Ｐｌａｙ Ｌｉｓｔ Ｔｏｐ（１０ＰＬＴ）は、ＴＧのリストとして表現される。図９に示した構成例では、３つのプレイリストを管理している。
【０１３３】
Ｐｌａｙ Ｌｉｓｔ＃１，＃２，＃３（ＴＧ１０ＰＬ１，１０ＰＬ２，１０ＰＬ３）は、ＴＧ＿ＩＤ０００２，０００３，０００４にそれぞれ対応している。ユーザは、Ｐｌａｙ Ｌｉｓｔ＃１，＃２，＃３（ＴＧ１０ＰＬ１，１０ＰＬ２，１０ＰＬ３）を新規に作成したり、消去したりすることができる。また、ユーザは、Ｐｌａｙ Ｌｉｓｔ＃１，＃２，＃３（ＴＧ１０ＰＬ１，１０ＰＬ２，１０ＰＬ３）の内容を編集することができる。それぞれのプレイリストは、ＴＬ（ＴＬ２０１〜２０Ｎ）のリストで表現されている。
【０１３４】
（４）構成例４
図１０は、音楽アルバムを管理する場合における構成例を示している。図９に示したプレイリスト（Ｐｌａｙ Ｌｉｓｔ＃１，＃２，＃３（ＴＧ１０ＰＬ１，１０ＰＬ２，１０ＰＬ３））との違いは、ＣＤをリッピングする際にコンテンツデータ記録装置が、関連するフォルダ及びファイル（Ａｌｂｕｍ Ｔｏｐ（ＴＧ１０ＡＴ），Ａｒｔｉｓｔ Ａ（ＴＧ１０Ａ），Ａｒｔｉｓｔ Ｂ（ＴＧ１０Ｂ），Ａｌｂｕｍ＃１，＃２，＃３（ＴＧ１０Ａ１，ＴＧ１０Ａ２，ＴＧ１０Ａ３）を生成し、当該フォルダ及びファイルは、ユーザからの編集が不可となることである。
【０１３５】
また、本構成例では、Ｔｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＴＢ）は、音楽アルバムの情報については管理しない。
【実施例】
【０１３６】
次に、上述したコンテンツデータ構造を用いた実施例について、図面を参照しながら説明する。
【０１３７】
（コンテンツデータ記録装置の構成）
図１１は、本実施例に係る音楽レコーダ１０００（コンテンツデータ記録装置）の構成を示している。
【０１３８】
図１１に示すように、音楽レコーダ１０００は、ＣＤ１１０１をドライブするＣＤドライブ１１０２を有している。
【０１３９】
ＡＡＣエンコーダ１１０４は、ＣＤドライブ１１０２によって読み込まれた音楽コンテンツ（オーディオデータ）のデータ量を圧縮するものである。具体的には、ＡＡＣエンコーダ１１０４は、ＭＰＥＧ−４ ＡＡＣ（ＩＳＯ／ＩＥＣ１４４９６−３）に基づいて、オーディオデータを圧縮する。
【０１４０】
暗号化処理部１１０６は、ＡＡＣエンコーダ１１０４によって圧縮されたオーディオデータを暗号化するものである。また、復号化処理部１１０８は、暗号化されたオーディオデータを復号化するものである。
【０１４１】
ＡＡＣデコーダ１１１０は、復号化処理部１１０８によって出力され、ＭＰＥＧ−４ ＡＡＣに基づいて圧縮されているオーディオデータを復号（伸長）するものである、
Ｄ／Ａ変換部１１１２は、ＡＡＣデコーダ１１１０によって出力されたオーディオデータを、アナログ信号に変換するものである。Ｄ／Ａ変換部１１１２によって出力されたアナログ信号は、スピーカ１１１４を駆動する。
【０１４２】
制御部１１１６は、ＭＰＵなどによって構成されており、制御部１１１６と接続されている各部を制御するものである。また、制御部１１１６は、タイマーを内蔵しており、日付や時刻の情報を取得することができる。
【０１４３】
制御部１１１６は、リムーバブルＨＤＤ１１２６上におけるＭＣの位置及びサイズなどを示すトラックリンク情報（リンク情報）を生成するものであり、本実施形態では、リンク情報生成部を構成する。
【０１４４】
また、制御部１１１６は、ＭＣの内容（例えば、タイトルやアーティスト名）を記述し、ＭＣ（個別ファイル）の検索に用いられるメタデータを取得するものであり、本実施形態では、モデム１１２８とともに、メタデータ取得部を構成する。
【０１４５】
さらに、制御部１１１６は、トラックリンク情報とメタデータとを含むＡＵＤ＿ＳＥＴ．ＭＧＲファイル（管理ファイル）を生成するものであり、本実施形態では、管理ファイル生成部を構成する。
【０１４６】
また、制御部１１１６は、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルを用いて、ＭＣを検索するものであり、本実施形態では、コンテンツ検索部を構成する。なお、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルには、上述したように、ＭＣの再生を許可するライセンス管理情報（*ＵＤＦ＿ＬＩＣＥＮＣＥセキュアストリームファイル）が含まれている。制御部１１１６は、当該ライセンス管理情報に基づいて、ＭＣを再生するものであり、本実施形態では、復号化処理部１１０８とともに、コンテンツ再生部を構成する。
【０１４７】
表示部１１１８は、制御部１１１６によって出力された情報、例えば、音楽コンテンツのトラック数、トラック番号、及びタイトルやアーティスト名などのメタデータを表示するものである。リモコン受光部１１２０は、リモコン１１２２から送信された赤外線光を受光するものである。
【０１４８】
ＡＴＡインタフェース１１２４は、制御部１１１６とリムーバブルＨＤＤ１１２６とを通信可能に接続するためのインタフェース（At Attachment）である。
【０１４９】
リムーバブルＨＤＤ１１２６は、音楽レコーダ１０００からの取り外しが可能なリムーバブル記録媒体である。リムーバブルＨＤＤ１１２６は、ＣＤ１１０１からリッピングされたオーディオデータを記録し、上述したコンテンツデータ構造によって当該オーディオデータが管理される。
【０１５０】
リムーバブルＨＤＤ１１２６には、上述したように、複数の音楽コンテンツ（ＭＣ３０１，３０２など）のそれぞれが、個別ファイルとして記録される。
【０１５１】
モデム１１２８は、音楽レコーダ１０００（制御部１１１６）と、コンテンツサーバ１１３２及びメタデータサーバ１１３４とを、インターネット網１１３０を介して通信可能に接続するための通信デバイスである。
【０１５２】
なお、音楽レコーダ１０００は、インターネット網１１３０との接続に用いられる通信回線の方式に基づいて、モデム１１２８以外の通信デバイス、例えば、メディアコンバータなどを実装することもできる。
【０１５３】
（コンテンツデータ記録装置の動作）
次に、上述した本実施例に係る音楽レコーダ１０００（コンテンツデータ記録装置）の動作について説明する。
【０１５４】
（１）リムーバルＨＤＤの初期化
図１２は、音楽レコーダ１０００に接続されるリムーバブルＨＤＤ１１２６の初期化処理フローを示している。
【０１５５】
図１２に示すように、ステップＳ１０において、音楽レコーダ１０００は、ＡＵＲ＿ＲＯＯＴディレクトリを作成する。
【０１５６】
ステップＳ２０において、音楽レコーダ１０００は、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルを作成する。具体的には、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルを構成するフィールドは、以下のように設定される。
【０１５７】
・ Ｆｌａｇ ＝ ０
・ Ｎｕｍ ｏｆ ＵＩＥ ＴＧｓ ＝ １
・ ＵＩＥ ＴＧ ＩＤ（１） ＝ ００００（ＡＳＣＩＩ）
・ Ｔｒａｃｋ Ｌｉｎｋ Ｌｏｃａｔｉｏｎ ＝ “．／ＰＲＯＧ＿ＳＥＴ．ＭＧＲ＃ＴｒａｃｋＬｉｎｋｓ”
・ Ｎｕｍｂｅｒ ｏｆ Ｔｒａｃｋ Ｇｒｏｕｐｓ ＝ １
・ Ｍａｘｉｍｕｍ Ｔｒａｃｋ Ｇｒｏｕｐ ＩＤ ＝ ００００
ステップＳ３０において、音楽レコーダ１０００は、ＴｒａｃｋＬｉｎｋｓストリームファイルを作成する。具体的には、ＴｒａｃｋＬｉｎｋｓストリームファイルを構成するフィールドは、以下のように設定される。
【０１５８】
・ Ｎｕｍｂｅｒ ｏｆ Ｔｒａｃｋ Ｌｉｎｋｓ ＝ ０
・ Ｎｕｍｂｅｒ ｏｆ Ｖａｌｉｄ Ｔｒａｃｋ Ｌｉｎｋｓ ＝ ０
ステップＳ４０において、音楽レコーダ１０００は、ＴＧ＿００００ストリームファイルを作成する。具体的には、ＴＧ＿００００ストリームファイルを構成するフィールドは、以下のように設定される。
【０１５９】
・ ＴＧ Ｓｐｅｃｉｆｉｃ Ｓｔｒｕｃｔｕｒｅ ＴＹＰＥ ＝ ０ｘ００
・ ＴＧ Ｆｌａｇ ＝ ０ｘ０２
・ ＴＧ ｓｐｅｃｉｆｉｃ ｓｔｒｕｃｔｕｒｅ ｎａｍｅ ＝ “Ｔｒａｃｋ Ｂａｓｅ”
・ Ｌｉｎｋ Ｃｏｕｎｔ ＝ ０
・ Ｎｕｍｂｅｒ ｏｆ ｅｌｅｍｅｎｔｓ ＝ ０
ステップＳ５０において、音楽レコーダ１０００は、ＲＴ＿ＡＵＲＳディレクトリを作成する。
【０１６０】
（２）ＣＤリッピング（１曲）
図１３は、ＣＤ１１０１（図１１参照）に含まれる音楽コンテンツ（オーディオデータ）から、１曲分のオーディオデータをリッピングし、リムーバブルＨＤＤ１１２６に記録するフローを示している。
【０１６１】
図１３に示すように、ステップＳ１１０において、音楽レコーダ１０００は、ＣＤ１１０１に含まれるオーディオデータに基づいて、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルを作成する。具体的には、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルを構成するフィールドは、以下のように設定される。なお、以下に示すフィールドにおいて、具体的な内容がないフィールドについては、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルの内容に応じて適切なデータが記述される。
【０１６２】
・ Ｎｕｍｂｅｒ ｏｆ Ｔｒａｃｋｓ ＝ １
・ ＡＵＤ Ｆｌａｇ
・ Ｐｌａｙｂａｃｋ Ｔｉｍｅ
・ Ｆｉｌｅ Ｓｉｚｅ
・ Ａｕｄｉｏ Ｆｏｒｍａｔ ＝ （ＡＡＣ）
・ Ｂｉｔ ｒａｔｅ
・ Ｆｉｌｅ Ｃｒｅａｔｅｄ Ｄａｔｅ
・ Ｃｈａｒａｃｔｅｒ Ｓｅｔ （Ｕｎｉｃｏｄｅ）
・ ＭｅｔａＤａｔａＦｉｌｅ Ｆｏｒｍａｔ
・ Ｌｉｃｅｎｓｅ Ｆｌａｇ
・ Ｌｉｃｅｎｓｅ Ｆｉｌｅ Ｌｏｃａｔｉｏｎ
ステップＳ１２０において、音楽レコーダ１０００は、ＴｒａｃｋＬｉｎｋｓストリームファイルの内容を更新する。具体的には、音楽レコーダ１０００は、以下に示すように、ＴｒａｃｋＬｉｎｋｓストリームファイルの内容を更新する。なお、以下に示すフィールドにおいて、具体的な内容がないフィールドについては、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルの内容などに応じて適切なデータが記述される。
【０１６３】
・ Ｎｕｍｂｅｒ ｏｆ Ｔｒａｃｋ Ｌｉｎｋｓ ＝ ｎ＋１
・ Ｎｕｍｂｅｒ ｏｆ Ｖａｌｉｄ Ｔｒａｃｋ Ｌｉｎｋｓ ＝ ｎ＋１
・ ＴＬ構造体追加
・ ＴＬ Ｓｐｅｃｉｆｉｃ Ｓｔｒｕｃｔｕｒｅ ＴＹＰＥ ＝ ０ｘ１
・ ＴＬ Ｆｌａｇ
・ Ｌｉｎｋ Ｃｏｕｎｔ ＝ １ （ｆｒｏｍ ＴＧ＿００００）
・ Ｍｕｓｉｃ Ｃｏｎｔｅｎｔ ＩＤ ＝ ｘｘｘｘｘｘｘ
・ ＭｅｔａＤａｔａ
・ Ｍｙ Ｒａｔｅ Ｉｎｆｏ
・ Ｌａｓｔ Ａｃｃｅｓｓｅｄ Ｔｉｍｅ
・ Ｐｌａｙｂａｃｋ Ｃｏｕｎｔｅｒ
・ Ｒｅｓｕｍｅ Ｐｏｉｎｔ
ステップＳ１３０において、音楽レコーダ１０００は、ＴＧ＿００００ストリームファイルの内容を更新する。具体的には、音楽レコーダ１０００は、以下に示すように、ＴＧ＿００００ストリームファイルの内容を更新する。
【０１６４】
・ Ｎｕｍｂｅｒ ｏｆ ｅｌｅｍｅｎｔｓ ＝ ｎ＋１
・ ｅｌｅｍｅｎｔ ＩＤを追加
（３）ＣＤリッピング（音楽アルバム）
図１４は、ＣＤ１１０１に含まれる音楽コンテンツ（オーディオデータ）から、複数曲によって構成されるオーディオデータをリッピングし、リムーバブルＨＤＤ１１２６に記録するフローを示している。
【０１６５】
図１４に示すように、ステップＳ２１０において、音楽レコーダ１０００は、ＣＤ１１０１に含まれるオーディオデータに基づいて、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルを作成する。具体的には、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルを構成するフィールドは、以下のように設定される。なお、以下に示すフィールドにおいて、具体的な内容がないフィールドについては、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルの内容に応じて適切なデータが記述される。
【０１６６】
・ Ｎｕｍｂｅｒ ｏｆ Ｔｒａｃｋｓ ＝ ｍ（音楽アルバムにｍ曲収容されている）
・ ＡＵＤ Ｆｌａｇ
・ Ｐｌａｙｂａｃｋ Ｔｉｍｅ
・ Ｆｉｌｅ Ｓｉｚｅ
・ Ａｕｄｉｏ Ｆｏｒｍａｔ ＝ （ＡＡＣ）
・ Ｂｉｔ ｒａｔｅ
・ Ｆｉｌｅ Ｃｒｅａｔｅｄ Ｄａｔｅ
・ Ｃｈａｒａｃｔｅｒ Ｓｅｔ （Ｕｎｉｃｏｄｅ）
・ ＭｅｔａＤａｔａＦｉｌｅ Ｆｏｒｍａｔ
・ Ｌｉｃｅｎｓｅ Ｆｌａｇ
・ Ｌｉｃｅｎｓｅ Ｆｉｌｅ Ｌｏｃａｔｉｏｎ
ステップＳ２２０において、音楽レコーダ１０００は、ＴｒａｃｋＬｉｎｋｓストリームファイルの内容を更新する。具体的には、音楽レコーダ１０００は、以下に示すように、ＴｒａｃｋＬｉｎｋｓストリームファイルの内容を更新する。なお、以下に示すフィールドにおいて、具体的な内容がないフィールドについては、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルの内容などに応じて適切なデータが記述される。
【０１６７】
・ Ｎｕｍｂｅｒ ｏｆ Ｔｒａｃｋ Ｌｉｎｋｓ ＝ ｎ＋ｍ
・ Ｎｕｍｂｅｒ ｏｆ Ｖａｌｉｄ Ｔｒａｃｋ Ｌｉｎｋｓ ＝ ｎ+ｍ
・ ｍ個のＴＬ構造体追加
ステップＳ２３０において、音楽レコーダ１０００は、ＴＧ＿００００ストリームファイルの内容を更新する。具体的には、音楽レコーダ１０００は、以下に示すように、ＴＧ＿００００ストリームファイルの内容を更新する。
【０１６８】
・ Ｎｕｍｂｅｒ ｏｆ ｅｌｅｍｅｎｔｓ ＝ ｎ+ｍ
・ ｅｌｅｍｅｎｔ ＩＤを追加（ｍ個）
ステップＳ２４０において、音楽レコーダ１０００は、ＴＧ＿ｘｘｘｘストリームファイルを作成する。具体的には、ＴＧ＿ｘｘｘｘストリームファイルを構成するフィールドは、以下のように設定される。
【０１６９】
・ ＴＧ Ｓｐｅｃｉｆｉｃ Ｓｔｒｕｃｔｕｒｅ ＴＹＰＥ ＝ ０ｘ０１
・ ＴＧ Ｆｌａｇ ＝ ０ｘ０３
・ ＴＧ ｓｐｅｃｉｆｉｃ ｓｔｒｕｃｔｕｒｅ ｎａｍｅ ＝ アルバムタイトル
・ Ｌｉｎｋ Ｃｏｕｎｔ ＝ ０
・ Ｎｕｍｂｅｒ ｏｆ ｅｌｅｍｅｎｔｓ ＝ ｍ
・ ｅｌｅｍｅｎｔ ＩＤ： ｍ個のＩＤを追加する
・ 各ｅｌｅｍｅｎｔのＴＬ構造体に含まれるＬｉｎｋ Ｃｏｕｎｔに“１”を加算
ステップＳ２５０において、音楽レコーダ１０００は、ステップＳ２４０において作成したＴＧ＿ｘｘｘｘストリームファイルがリンクされる上位のＴＧ（例えば、図１０に示したＴＧ１０Ａ）があるか否かを判定する。
【０１７０】
ＴＧ＿ｘｘｘｘストリームファイルがリンクされる上位のＴＧがある場合（ステップＳ２５０のＹｅｓ）、ステップＳ２６０において、音楽レコーダ１０００は、当該上位ＴＧについてメンテナンスを実行する。具体的には、以下のようなメンテナンスが実行される。
【０１７１】
・ Ｎｕｍｂｅｒ ｏｆ ｅｌｅｍｅｎｔｓ ＝ ｎ＋１
・ ｅｌｅｍｅｎｔ ＩＤ： 追加したＴＧ＿ｘｘｘｘストリームファイルのｘｘｘｘ部分を追加
ＴＧ＿ｘｘｘｘストリームファイルがリンクされる上位のＴＧがない場合（ステップＳ２５０のＮｏ）、ステップＳ２７０において、音楽レコーダ１０００は、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの内容を更新する。具体的には、音楽レコーダ１０００は、以下に示すように、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの内容を更新する。
【０１７２】
・ Ｆｌａｇ ＝ ０
・ Ｎｕｍ ｏｆ ＵＩＥ ＴＧｓ ＝ ２
・ ＵＩＥ ＴＧ ＩＤ（２） ＝ ｘｘｘｘ（ＡＳＣＩＩ）
・ Ｎｕｍｂｅｒ ｏｆ Ｔｒａｃｋ Ｇｒｏｕｐｓ ＝ ２
・ ＵＩＥ ＴＧ ＩＤ（２） Ｎａｍｅ ＝ アルバムタイトル
・ Ｍａｘｉｍｕｍ Ｔｒａｃｋ Ｇｒｏｕｐ ＩＤ ＝ ｘｘｘｘ
以上、音楽レコーダ１０００が、ＣＤ１１０１に含まれる音楽コンテンツ（音楽コンテンツ）をリッピングする場合の動作について説明したが、音楽レコーダ１０００は、インターネット網１１３０を介して接続されているコンテンツサーバ１１３２に格納されている音楽コンテンツをダウンロードし、リムーバブルＨＤＤ１１２６に記録することもできる。
【０１７３】
（４）ＣＤＤＢからのメタデータ取得
図１５は、ＣＤＤＢから、音楽コンテンツに関するメタデータを取得するフローを示している。
【０１７４】
図１５に示すように、ステップＳ３１０において、ユーザは、ＣＤ１１０１をＣＤドライブ１１０２（図１１参照）に挿入する。
【０１７５】
ＣＤ１１０１がＣＤドライブ１１０２（図１１参照）に挿入されると、ステップＳ３２０において、音楽レコーダ１０００は、メタデータサーバ１１３４からＣＤ１１０１に対応するメタデータを取得する。
【０１７６】
具体的には、音楽レコーダ１０００は、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルのメタデータ管理情報を取得し、取得したメタデータ管理情報に基づいて、ＭｅｔａＤａｔａストリームファイルにメタデータを登録する。なお、音楽レコーダ１０００は、必要により、メタデータに用いられる文字コードを変換する。
【０１７７】
ステップＳ３３０において、音楽レコーダ１０００は、対応するＴＬ構造体（表８参照）にメタデータを登録する。音楽レコーダ１０００は、登録対象のメタデータがフィールド長より長い場合、当該フィールドに記述することができない当該メタデータの部分を削除する。
【０１７８】
（５）再生（タイトル検索・メタデータ表示）
図１６は、リムーバブルＨＤＤ１１２６に含まれる音楽コンテンツ（オーディオデータ）を再生するフローを示している。
【０１７９】
図１６に示すように、ステップＳ４１０において、音楽レコーダ１０００は、ＡＵＲ＿ＲＯＯＴディレクトリの配下に位置するＡＵＤ＿ＳＥＴ．ＭＧＲファイルをオープンし、ＵＩＥ ＴＧ＿ＩＤのリスト及び名前をユーザに表示する。
【０１８０】
ステップＳ４２０において、ユーザは、ＵＩＥ ＴＧ＿ＩＤのリストの中から、１つのＴＧ＿ＩＤを選択する。
【０１８１】
ステップＳ４３０において、音楽レコーダ１０００は、選択されたＴＧ＿ＩＤに対応するＴＧ＿ｘｘｘｘストリームファイルをオープンし、ｅｌｅｍｅｎｔ＿ＩＤのリストをユーザに表示する。
【０１８２】
ステップＳ４４０において、音楽レコーダ１０００は、ｅｌｅｍｅｎｔがＴＧか否かを判定する。
【０１８３】
ｅｌｅｍｅｎｔがＴＧの場合（ステップＳ４４０のＹｅｓ）、音楽レコーダ１０００は、ステップＳ４２０からの処理を繰り返す。ｅｌｅｍｅｎｔがＴＧでない場合、すなわち、ｅｌｅｍｅｎｔがＴＬの場合（ステップＳ４４０のＮｏ）、ステップＳ４５０において、ユーザは、ｅｌｅｍｅｎｔ＿ＩＤのリストの中から、１つのＴＬ＿ＩＤを選択する。
【０１８４】
ステップＳ４６０において、音楽レコーダ１０００は、ＴｒａｃｋＬｉｎｋｓストリームファイルから、選択されたＴＬ＿ＩＤに対応するＴＬ構造体を取得する。
【０１８５】
ステップＳ４７０において、音楽レコーダ１０００は、取得したＴＬ構造体の“Ｍｕｓｉｃ Ｃｏｎｔｅｎｔｓ ＩＤ”、“Ｓｔａｒｔ Ｐｏｉｎｔ ｉｎ Ｃｏｎｔｅｎｔｓ Ｆｉｌｅ”及び“Ｃｏｎｔｅｎｔｓ Ｌｅｎｇｔｈ”から、ＡＵＤｘｘｘｘｘｘｘｘ．ＡＩＦファイルに含まれるＡｕｄｉｏＤａｔａストリームファイルの再生位置を確保する。
【０１８６】
ステップＳ４８０において、音楽レコーダ１０００は、*ＵＤＦ＿ＬＩＣＥＮＣＥセキュアストリームファイルから、ライセンスファイル（復号鍵）を取得する。
【０１８７】
ステップＳ４９０において、音楽レコーダ１０００は、取得した復号鍵を用いて、ＡｕｄｉｏＤａｔａストリームファイルに含まれるオーディオデータを復号して再生する。
【０１８８】
ステップＳ５００において、音楽レコーダ１０００は、ＴＬ構造体のＰｌａｙｂａｃｋ Ｃｏｕｎｔｅｒに“１”加算する。なお、Ｐｌａｙｂａｃｋ Ｃｏｕｎｔｅｒに加算するタイミングは、再生開始時ままたは再生終了時の何れでもよい。
【０１８９】
ステップＳ５１０において、音楽レコーダ１０００は、オーディオデータ、つまり、音楽コンテンツの再生が途中で停止されたか否かを判定する。
【０１９０】
音楽コンテンツの再生が途中で停止された場合（ステップＳ５１０のＹｅｓ）、ステップＳ５２０において、音楽レコーダ１０００は、当該停止した位置に対して、リジュームポイントを設定する。
【０１９１】
（６）プレイリスト作成（ＴＧ）
図１７は、プレイリスト（ＴＧ）を作成するフローを示している。
【０１９２】
図１７に示すように、ステップＳ６１０において、ユーザは、プレイリストのフォルダを作成する。プレイリストのフォルダがユーザによって作成されると、音楽レコーダ１０００は、ＴＧ＿ｘｘｘｘストリームファイルを生成する。具体的には、当該ＴＧ＿ｘｘｘｘストリームファイルを構成するフィールドは、以下のように設定される。
【０１９３】
・ ＴＧ Ｓｐｅｃｉｆｉｃ Ｓｔｒｕｃｔｕｒｅ ＴＹＰＥ ＝ ０ｘ０２
・ ＴＧ Ｆｌａｇ ＝ ０ｘ０３
・ ＴＧ ｓｐｅｃｉｆｉｃ ｓｔｒｕｃｔｕｒｅ ｎａｍｅ ＝ プレーリストタイトル
・ Ｌｉｎｋ Ｃｏｕｎｔ ＝ ０
・ Ｎｕｍｂｅｒ ｏｆ ｅｌｅｍｅｎｔｓ ＝ ０
ステップＳ６２０において、ユーザは、ＴＧ＿００００ストリームファイルからユーザがプレイリストに登録するものをピックアップする。
【０１９４】
ステップＳ６３０において、音楽レコーダ１０００は、ＴＧ＿ｘｘｘｘストリームファイルの内容を更新する。具体的には、音楽レコーダ１０００は、以下に示すように、ＴＧ＿ｘｘｘｘストリームファイルの内容を更新する。
【０１９５】
・ Ｎｕｍｂｅｒ ｏｆ ｅｌｅｍｅｎｔｓ ＝ ｎ＋１
・ ｅｌｅｍｅｎｔ ＩＤ： 選択されたＴＬ＿ＩＤを追加
・ 各ｅｌｅｍｅｎｔのＴＬ構造体に含まれるＬｉｎｋ Ｃｏｕｎｔに“１”を加算
ステップＳ６４０において、音楽レコーダ１０００は、さらにプレイリストに追加するものがあるか否かを判定する。
【０１９６】
さらにプレイリストに追加するものがある場合（ステップＳ６４０のＹｅｓ）、ユーザは、ステップＳ６２０からの処理を繰り返す。
【０１９７】
プレイリストに追加するものがない場合（ステップＳ６４０のＮｏ）、ステップＳ６５０において、音楽レコーダ１０００は、ステップＳ６３０において更新したＴＧ＿ｘｘｘｘストリームファイルがリンクされる上位のＴＧ（例えば、図１０に示したＴＧ１０Ａ）があるか否かを判定する。
【０１９８】
ＴＧ＿ｘｘｘｘストリームファイルがリンクされる上位のＴＧがある場合（ステップＳ６５０のＹｅｓ）、ステップＳ６６０において、音楽レコーダ１０００は、当該上位ＴＧについて、メンテナンスを実行する。具体的には、ステップＳ２６０と同様なメンテナンスが実行される。
【０１９９】
ＴＧ＿ｘｘｘｘストリームファイルがリンクされる上位のＴＧがない場合（ステップＳ２５０のＮｏ）、ステップＳ６７０において、音楽レコーダ１０００は、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの内容を更新する。具体的には、音楽レコーダ１０００は、ステップＳ２７０と同様に、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの内容を更新する。
【０２００】
なお、音楽レコーダ１０００がＴＧ＿ｘｘｘｘストリームファイルを生成する場合、“ｘｘｘｘ”部分の簡易的な割り当て方法としては、“Ｍａｘｉｍｕｍ Ｔｒａｃｋ Ｇｒｏｕｐ ＩＤ”フィールド（表６参照）を参照して、現状の最大値に“１”を加算した値を割り当てるとともに、“Ｍａｘｉｍｕｍ Ｔｒａｃｋ Ｇｒｏｕｐ ＩＤ”フィールドにも、現状の最大値に“１”を加算した値を割り当てる方法が用いられる。
【０２０１】
また、他の割り当て方法としては、全てのＴＧ＿ＩＤをサーチして、欠損している番号（例えば、一度生成されて、その後削除した場合）があれば、当該番号を割り当てる方法がある。この場合、欠損している番号がなければ、上述したように、現状の最大値に“１”を加算した値を割り当てるとともに、“Ｍａｘｉｍｕｍ Ｔｒａｃｋ Ｇｒｏｕｐ ＩＤ”フィールドにも、現状の最大値に“１”を加算した値を割り当てる。
【０２０２】
すなわち、簡易的な割り当て方法では、全てのＴＧ＿ＩＤをサーチする必要がなく、より高速に“ｘｘｘｘ”部分の割り当て処理を実行することができる。
【０２０３】
（７）メタデータによるリストのソート
図１８は、メタデータによって、リストをソートするフローを示している。図１８に示すように、ステップＳ７１０において、ユーザは、ＴＬのリストで表現されているＴＧを選択する。
【０２０４】
ステップＳ７２０において、ユーザは、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルに含まれるＭｅｔａＤａｔａストリームファイル（メタデータ構造体）から検索したいフィールドを選択する。
【０２０５】
ステップＳ７３０において、音楽レコーダ１０００は、ＴＧのｅｌｅｍｅｎｔであるＴＬに対応するＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルのＭｅｔａＤａｔａストリームファイルから候補のメタデータを検索する。ステップＳ７４０において、音楽レコーダ１０００は、該当するＴＬをメタデータ順にソートする。
【０２０６】
より具体的には、図２６に示すように、５つのトラック（ＴＬ２０１〜２０５，ＭＣ３０１〜ＭＣ３０５）から構成されるＴｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＴＢ）からメタデータによってリストをソートする場合、音楽レコーダ１０００は、ＴＬ＿ＩＤ ＃１〜ＴＬ＿ＩＤ ＃５のＴＬについて、以下の処理を実行する。
【０２０７】
（ｉ） ＴＬ＿ＩＤ ＃ｎ（ｎ＝１〜５）のＴＬ（ＴＬ２０１〜２０５）に対して、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルに属するＭｅｔａＤａｔａストリームファイルをオープンする。
【０２０８】
（ｉｉ） ＭｅｔａＤａｔａストリームファイルの先頭から、“Ｇｅｎｒｅ”フィールドの先頭までのバイト数を演算する（表２６において、１＋ａ＋１＋ｂ＋１＋ｃ＋１＋ｄを演算することに該当）。
【０２０９】
（ｉｉｉ） “Ｌｅｎｇｔｈ ｏｆ Ｇｅｎｒｅ”フィールドの値（＝ｅ）を取得する。
【０２１０】
（ｉｖ） “Ｌｅｎｇｔｈ ｏｆ Ｇｅｎｒｅ”フィールドに続く“Ｇｅｎｒｅ”フィールドに記述されているデータを取得する。
【０２１１】
（ｖ） ＴＬ＿ＩＤとＧｅｎｒｅデータとのリストを、既に取得したリスト（例えば、ＴＬ＿ＩＤ＃３の場合、ＴＬ＿ＩＤ＃１及びＴＬ＿ＩＤ＃２に係るリスト）と比較し、アルファベット順（日本語の場合は５０音順）にソートする。
【０２１２】
ＴＬ＿ＩＤ ＃１〜ＴＬ＿ＩＤ ＃５のＴＬ（ＴＬ２０１〜２０５）について、上述した（ｉ）〜（ｖ）の処理を実行した音楽レコーダ１０００は、ソートされたＴＬ＿ＩＤ順にリストの内容を表示する。
【０２１３】
（８）メタデータによるリストの高速ソート
図１９は、メタデータによって、リストを高速にソートするフローを示している。図１９に示すように、ステップＳ７１０Ａにおいて、ユーザは、ＴＬのリストで表現されているＴＧを選択する。
【０２１４】
ステップＳ７２０Ａにおいて、ユーザは、ＴＬ構造体によって定義されているメタデータフィールドから、検索したいフィールドを選択する。
【０２１５】
ステップＳ７３０Ａにおいて、音楽レコーダ１０００は、ＴＧのｅｌｅｍｅｎｔであるＴＬに対応するＴＬ構造体から候補のメタデータを検索する。ステップＳ７４０Ａにおいて、音楽レコーダ１０００は、該当するＴＬをメタデータ順にソートする。
【０２１６】
すなわち、図１８に示したメタデータによるリストのソート方法では、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルに含まれるＭｅｔａＤａｔａストリームファイル（メタデータ構造体）をオープンして内容を検索しなければならないが、図１９に示したメタデータによるリストのソート方法では、３２４バイトの固定長を有するＴＬ構造体（表８参照）が用いられるため、より高速にソートを実行することができる。
【０２１７】
より具体的には、図２６に示すように、５つのトラック（ＴＬ２０１〜２０５，ＭＣ３０１〜ＭＣ３０５）から構成されるＴｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＴＢ）からメタデータによってリストを高速にソートする場合、音楽レコーダ１０００は、ＴｒａｃｋＬｉｎｋｓストリームファイルをオープンし、以下の処理を実行する。
【０２１８】
（ｉ） ＴＬ＿ＩＤ ＃１の“Ｇｅｎｒｅ”フィールドの先頭位置を取得する。具体的には、ＴＬ＿ＩＤ ＃１の“Ｇｅｎｒｅ”フィールドの先頭位置が、ＴｒａｃｋＬｉｎｋｓストリームファイルの先頭から２１０バイト目（表７において、ＴＬ＿ＩＤ ＃１に係るＴＬ構造体のデータは、８バイト目から開始され、表８において、“Ｇｅｎｒｅ”フィールドは、２０２バイト目から開始されている）であることを認識する。
【０２１９】
（ｉｉ） “Ｇｅｎｒｅ”フィールドに記述されているデータを取得し、ＴＬ＿ＩＤとＧｅｎｒｅデータとのリストを記憶する。
【０２２０】
（ｉｉｉ） ＴＬ＿ＩＤ ＃２の“Ｇｅｎｒｅ”フィールドの先頭位置（５３４バイト目（２１０＋３２４バイト、表７及び表８参照））を取得する。同様に、ＴＬ＿ＩＤ ＃３，＃４，＃５の先頭位置は、（２１０＋２×３２４）バイト目、（２１０＋３×３２４）バイト目、（２１０＋４×３２４）バイト目となる。
【０２２１】
（ｉｖ） ＴＬ＿ＩＤとＧｅｎｒｅデータとのリストを、既に取得したリスト（例えば、ＴＬ＿ＩＤ＃３の場合、ＴＬ＿ＩＤ＃１及びＴＬ＿ＩＤ＃２に係るリスト）と比較し、アルファベット順（日本語の場合は５０音順）にソートする。
【０２２２】
ＴＬ＿ＩＤ ＃１〜ＴＬ＿ＩＤ ＃５のＴＬ（ＴＬ２０１〜２０５）について、上述した（ｉ）〜（ｉｖ）の処理を実行した音楽レコーダ１０００は、ソートされたＴＬ＿ＩＤ順にリストの内容を表示する。
【０２２３】
（９）メタデータによるリストの高速検索
図２０は、メタデータによって、リストを高速に検索するフローを示している。図２０に示すように、ステップＳ８１０において、ユーザは、ＴＬのリストで表現されているＴＧを選択する。
【０２２４】
ステップＳ８２０において、ユーザは、ＴＬ構造体によって定義されているメタデータフィールドから、検索したいフィールドを選択する。
【０２２５】
ステップＳ８３０において、ユーザは、選択したフィールドに対応する文字を入力する。
【０２２６】
ステップＳ８４０において、音楽レコーダ１０００は、ＴＧのｅｌｅｍｅｎｔであるＴＬに対応するＴＬ構造体からメタデータを検索し、ユーザが入力した文字とマッチングを実行する。ステップＳ８５０において、音楽レコーダ１０００は、該当するＴＬのリストをユーザに表示する。
【０２２７】
本検索方法でも、３２４バイトの固定長を有するＴＬ構造体（表８参照）が用いられるため、ＭｅｔａＤａｔａストリームファイルをオープンする場合と比較して、より高速な検索を実行することができる。
【０２２８】
（１０）リジュームポイントの設定
図２１は、リジュームポイントを設定するフローを示している。図２１に示すように、ステップＳ９１０において、音楽レコーダ１０００は、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルからＵＩＥ ＴＧのリストをユーザに表示する。
【０２２９】
ステップＳ９２０において、ユーザは、ＵＩＥ ＴＧリストから１つのＴＧを選択する。ステップＳ９３０において、音楽レコーダ１０００は、“Ｌａｓｔ Ａｃｃｅｓｓｅｄ ＵＩＥ ＴＧ＿ＩＤ”フィールドに選択されたＴＧ＿ＩＤを記述する。また、音楽レコーダ１０００は、当該ＴＧ＿ＩＤを記述した時刻を“Ｌａｓｔ Ａｃｃｅｓｓｅｄ ＵＩＥ ＴＧ＿ＩＤ ｒｅｃｏｒｄｅｄ ｄａｔｅ”に記述する。
【０２３０】
ステップＳ９４０において、音楽レコーダ１０００は、選択されたＴＧのｅｌｅｍｅｎｔリストをユーザに表示する。
【０２３１】
ｅｌｅｍｅｎｔがＴＧである場合（ステップＳ９５０のＮｏ）、ステップＳ９８０において、ユーザは、ＴＧリストから１つのＴＧを選択する。ステップＳ９９０において、音楽レコーダ１０００は、“Ｒｅｓｕｍｅ ｅｌｅｍｅｎｔ”に当該ＴＧ＿ＩＤを追加する。
【０２３２】
ｅｌｅｍｅｎｔがＴＬである場合（ステップＳ９５０のＹｅｓ）、ステップＳ９６０において、ユーザは、ＴＬリストから、１つのＴＬを選択する。ステップＳ９７０において、音楽レコーダ１０００は、“Ｒｅｓｕｍｅ ｅｌｅｍｅｎｔ”に当該ＴＬ＿ＩＤを追加する。
【０２３３】
以降、音楽レコーダ１０００は、選択されたＴＬ＿ＩＤと対応するＴＬ構造体に基づいて、オーディオデータを再生する（図１６のステップＳ４７０以降の処理を参照）。
【０２３４】
（１１）リジューム再生
図２２は、リジュームポイントに基づいて、オーディオデータを再生（リジューム再生）するフローを示している。図２２に示すように、ステップＳ１０１０において、音楽レコーダ１０００は、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの“Ｌａｓｔ Ａｃｃｅｓｓｅｄ ＵＩＥ ＴＧ＿ＩＤ”に記述されているＴＧ＿ＩＤに該当するＴＧ＿ｘｘｘｘストリームファイルをオープンする。
【０２３５】
ステップＳ１０２０において、音楽レコーダ１０００は、該当するＴＧの“Ｒｅｓｕｍｅ ｅｌｅｍｅｎｔ”に記述されているｅｌｅｍｅｎｔ＿ＩＤを取得する。
【０２３６】
ステップＳ１０３０において、音楽レコーダ１０００は、ｅｌｅｍｅｎｔがＴＧか否かを判定する。ｅｌｅｍｅｎｔがＴＧの場合（ステップＳ１０３０のＹｅｓ）、音楽レコーダ１０００は、ステップＳ１０２０からの処理を繰り返す。
【０２３７】
ｅｌｅｍｅｎｔがＴＬの場合（ステップＳ１０３０のＮｏ）、ステップＳ１０４０において、音楽レコーダ１０００は、リジュームポイントが設定されているか否かを判定する。
【０２３８】
リジュームポイントが設定されている場合（ステップＳ１０４０のＹｅｓ）、ステップＳ１０５０において、音楽レコーダ１０００は、リジュームポイントからオーディオデータを再生する。一方、リジュームポイントが設定されていない場合（ステップＳ１０４０のＮｏ）、ステップＳ１０６０において、音楽レコーダ１０００は、曲（または音楽アルバム）の最初からオーディオデータを再生する。
【０２３９】
なお、リジュームポイント設定をオプション仕様とする場合、上述したように、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの“Ｒｅｓｕｍｅ Ｓｕｐｐｏｒｔ Ｆｌａｇ”が使用される。リジュームをサポートしている音楽レコーダなど（コンテンツデータ記録装置）は、立上げ時（電源投入時など）に１ｂを記録する。一方、リジュームをサポートしていない音楽レコーダなどは、立上げ時に０ｂを記録する。
【０２４０】
また、リムーバブルＨＤＤ１１２６（リムーバブル記録媒体）を移動後、他の音楽レコーダなどで再生する場合、当該他の音楽レコーダなどは、まず、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの“Ｒｅｓｕｍｅ Ｓｕｐｐｏｒｔ Ｆｌａｇ”の内容を読み込み、値が１ｂの場合にはリジューム再生を行い、値が０ｂの場合にはリジューム再生を行わない。
【０２４１】
（１２）タイトル削除
図２３は、音楽コンテンツ（オーディオデータ）と対応付けられているタイトルを削除するフローを示している。図２３に示すように、ステップＳ１１１０において、音楽レコーダ１０００は、ＴＧ＿００００ストリームファイル（Ｔｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＴＢ））をオープンし、ｅｌｅｍｅｎｔ＿ＩＤのリストと名前をユーザに表示する。
【０２４２】
ステップＳ１１２０において、ユーザは、削除するタイトルを１つ選択する。ステップＳ１１３０において、音楽レコーダ１０００は、当該タイトルのＴＬとリンクされているＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルが１トラックのみで構成されているか否かを判定する。
【０２４３】
ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルが１トラックのみで構成されている場合（ステップＳ１１３０のＹｅｓ）、ステップＳ１１６０において、音楽レコーダ１０００は、当該ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルを削除する。
【０２４４】
ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルが１トラックのみで構成されていない場合（ステップＳ１１３０のＮｏ）、すなわち、複数曲で構成されている場合、ステップＳ１１４０において、音楽レコーダ１０００は、ＴＬから当該ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルへのリンクをサーチする。
【０２４５】
ステップＳ１１５０において、音楽レコーダ１０００は、ＴＬから当該ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルへのリンクが１以上存在するか否かを判定する。
【０２４６】
当該ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルへのリンクが１以上存在する場合（ステップＳ１１５０のＹｅｓ）、音楽レコーダ１０００は、当該ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルを削除せず、ステップＳ１１７０の処理を実行する。
【０２４７】
一方、当該ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルへのリンクが全く存在しない場合（ステップＳ１１５０のＮｏ）、ステップＳ１１６０において、音楽レコーダ１０００は、当該ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルを削除する。
【０２４８】
ステップＳ１１７０において、音楽レコーダ１０００は、当該ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルと対応付けられているＴＬ構造体を削除するとともに、当該ＴＬ構造体をリンクしているＴＧから、当該ＴＬへのリンクを削除する。具体的には、ＴＬ構造体の“Ｌｉｎｋ Ｃｏｕｎｔ”にＴＧからリンクされている数が記述されているため、音楽レコーダ１０００は、“Ｌｉｎｋ Ｃｏｕｎｔ”に基づいて、当該ＴＬへのリンクを削除する。
【０２４９】
また、ＴｒａｃｋＬｉｎｋｓストリームファイルからＴＬ構造体を削除した場合、他のＴＬ＿ＩＤが、“１”づつ小さくなる（ＴＬ＿ＩＤは、並び順のため）。このため、全てのＴＧに対して、削除したＴＬのＴＬ＿ＩＤ、及び当該ＴＬ以降のＴＬ＿ＩＤのメンテナンスが必要となる。
【０２５０】
すなわち、音楽レコーダ１０００は、削除されたＴＬ＿ＩＤの値よりも大きな値のＴＬ＿ＩＤをリンクしているＴＧのメンテナンスを実行する。具体的には、当該ＴＬ＿ＩＤの値が、それぞれ“１”減らされる。
【０２５１】
図２４は、図２３に示した“タイトル削除”のフローの変更部分を示している。図２４に示すステップＳ１１４１及びステップＳ１１４２の処理は、図２３に示すＳ１１７０の処理に代えて、実行される。
【０２５２】
ステップＳ１１４１において、音楽レコーダ１０００は、削除するＴＬ構造体をリンクしているＴＧから、当該ＴＬのリンクを削除する
ステップＳ１１４２において、音楽レコーダ１０００は、当該ＴＬ構造体のＶａｌｉｄビッドをＯＦＦにするとともに、当該ＴＬ構造体をリンクしているＴＧから、当該ＴＬへのリンクを削除する
なお、この場合、上述したＴＬ＿ＩＤのメンテナンスは必要ない。つまり、ＴＬ構造体自体は削除されないためＴＬ＿ＩＤが変化しない。ただし、ＴＧに対しては、削除したＴＬ＿ＩＤの削除が必要となる。この簡易的な方法によれば、次回ＴＬを追加する場合、ＶａｌｉｄビッドがＯＦＦとなっている領域を再使用することができる。
【０２５３】
（１３）プリセットモデルにおける購入
図２５は、リムーバブルＨＤＤ１１２６に予め暗号化された音楽コンテンツ（オーディオデータ）が記録されたプリセットモデルにおいて、ユーザが、所望の音楽コンテンツを購入するフローを示している。
【０２５４】
プリセットモデルの場合、オーディオデータ（ＡｕｄｉｏＤａｔａストリームファイル）は、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルに記録される。また、ＴＬは、プリセットモデル専用にＰＲＴＬｓストリームファイルに記録される。ユーザは、このようにオーディオデータや各種ファイルが記録されたリムーバブルＨＤＤ１１２６を入手（購入）する。
【０２５５】
この状態では、ユーザは、リムーバブルＨＤＤ１１２６に記録されている音楽コンテンツ（オーディオデータ）を視聴することができないため、購入手続きを行う必要がある。具体的には、図２５に示すように、ステップＳ１２１０において、ユーザは、音楽レコーダ１０００による高速検索（図２０参照）などを利用して、購入する音楽コンテンツを選択する。
【０２５６】
ステップＳ１２２０において、ユーザは、当該音楽コンテンツを視聴するためのライセンス（復号鍵及び利用条件）を購入する。具体的には、ユーザは、コンテンツサーバ１１３２などにアクセスして、当該ライセンスを購入する。
【０２５７】
ユーザによってライセンスが購入されると、ステップＳ１２３０において、音楽レコーダ１０００は、購入した音楽コンテンツに係るＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルに含まれるライセンス管理情報である“Ｌｉｃｅｎｓｅ Ｆｌａｇ”をセットすると同時に、*ＵＤＦ＿ＬＩＣＥＮＣＥセキュアストリームファイルを生成する。
【０２５８】
ステップＳ１２４０において、音楽レコーダ１０００は、当該ＴＬをＰＲＴＬｓストリームファイルからＴｒａｃｋＬｉｎｋｓストリームファイルに移動する（詳細については、上述した図７及び図８に係る説明を参照）。なお、ＰＲＴＬｓストリームファイルにおけるタイトルは、図２４に示した簡易的な方法によって削除される。
【０２５９】
（作用・効果）
以上説明した本実施形態及び本実施例によれば、音楽コンテンツなどのオーディオデータを利用するユーザは、トラックリンク情報及びメタデータ管理情報（ＭｅｔａＤａｔａストリームファイル）を含むＡＵＤ＿ＳＥＴ．ＭＧＲファイルを用いるため、音楽コンテンツの検索、再生がさらに容易かつ速やかに行え、音楽コンテンツの取扱いに係る利便性を向上させることができる。
【０２６０】
（その他の実施形態）
上述したように、本発明の一実施形態を通じて本発明の内容を開示したが、この開示の一部をなす論述及び図面は、本発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施の形態が明らかとなろう。
【０２６１】
例えば、上述した本発明の実施形態では、音楽コンテンツ（オーディオデータ）を例として説明したが、本発明は、音楽コンテンツのみではなく、例えば、静止画像や動画のコンテンツに適用することもできる。
【０２６２】
また、上述した本発明の実施形態では、リムーバブルＨＤＤ１１２６（リムーバブル記録媒体）を例として説明したが、本発明は、コンテンツデータ記録装置などに内蔵されるハードディスクドライブ（ＨＤＤ）などにも適用することができる。
【０２６３】
このように、本発明は、ここでは記載していない様々な実施の形態などを含むことは、もちろんである。したがって、本発明の技術的範囲は、上述の説明から妥当な特許請求の範囲に係る発明特定事項によってのみ定められるものである。
【図面の簡単な説明】
【０２６４】
【図１】本発明の実施形態に係るファイルフォーマットの概要を示す図である。
【図２】本発明の実施形態に係るディレクトリ及びファイルの構成を示す図である。
【図３】本発明の実施形態に係るＡＵＤ＿ＳＥＴ．ＭＧＲの構成を示す図である。
【図４】本発明の実施形態に係るＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルの構成を示す図である。
【図５】本発明の実施形態に係る“Ｔｒａｃｋ＿Ｂａｓｅ”を用いたモデル構成例を示す図である。
【図６】本発明の実施形態に係る“Ｐｒｅｓｅｔ＿Ｔｒａｃｋ＿Ｂａｓｅ”を用いたモデル構成例を示す図である。
【図７】本発明の実施形態に係るモデル構成例において、暗号化された音楽コンテンツのライセンスが取得（購入）される前の状態を示す図である。
【図８】本発明の実施形態に係るモデル構成例において、暗号化された音楽コンテンツのライセンスが取得（購入）された後の状態を示す図である。
【図９】本発明の実施形態に係る音楽コンテンツ管理モデルの基本的な構成例を示す図である。
【図１０】本発明の実施形態において、音楽アルバムを管理する場合における構成例を示している。
【図１１】本発明の実施例に係る音楽レコーダ（コンテンツデータ記録装置）の構成を示す図である。
【図１２】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図１３】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図１４】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図１５】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図１６】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図１７】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図１８】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図１９】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図２０】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図２１】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図２２】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図２３】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図２４】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図２５】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図２６】本発明の実施例に係る音楽レコーダにおいて実行されるトラックリンクのソート動作を説明するためのモデル構成図である。
【符号の説明】
【０２６５】
１０，１０Ａ，１０Ａ１〜１０Ａ３，１０ＡＴ，１０Ｂ，１０ＰＬ１〜１０ＰＬ３，１０ＰＬＴ，１０ＰＴＢ，１０ＴＢ…ＴＧ（トラックグループ）
２０１〜２０Ｎ＋１，２１１〜２１Ｎ＋１…ＴＬ（トラックリンク）
３０１〜３０４，３０Ｍ…ＭＣ（記録済み音楽コンテンツ）
１００…ＲＯＯＴディレクトリ
１１０…ＡＵＲ＿ＲＯＯＴディレクトリ
１２０…ＡＵＤ＿ＳＥＴ．ＭＧＲ
１３０…ＲＴ＿ＡＵＲＳディレクトリ
１４０…ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイル
１０００…音楽レコーダ
１１０１…ＣＤ
１１０２…ＣＤドライブ
１１０４…ＡＡＣエンコーダ
１１０６…暗号化処理部
１１０８…復号化処理部
１１１０…ＡＡＣデコーダ
１１１２…Ｄ／Ａ変換部
１１１４…スピーカ
１１１６…制御部
１１１８…表示部
１１２０…リモコン受光部
１１２２…リモコン
１１２４…ＡＴＡインタフェース
１１２６…リムーバブルＨＤＤ
１１２８…モデム
１１３０…インターネット網
１１３２…コンテンツサーバ
１１３４…メタデータサーバ
【特許請求の範囲】
【請求項１】
複数のコンテンツデータのそれぞれが、個別ファイルとして記録されるコンテンツデータ記録媒体において用いられるコンテンツデータ構造であって、
少なくとも前記コンテンツデータ記録媒体上における前記コンテンツデータの位置及びサイズを示すリンク情報セグメントと、
前記コンテンツデータの内容を記述し、前記個別ファイルの検索に用いられるメタデータセグメントと、
前記リンク情報セグメントと前記メタデータセグメントとを含む管理ファイル領域と
を有し、
前記管理ファイル領域を用いて、前記コンテンツデータ記録媒体にアクセスするアクセス装置に前記コンテンツデータを検索させることを特徴とするコンテンツデータ構造。
【請求項２】
前記管理ファイル領域には、前記アクセス装置に前記コンテンツデータの再生を許可するライセンス管理情報セグメントが含まれることを特徴とする請求項１に記載のコンテンツデータ構造。
【請求項３】
複数のコンテンツデータのそれぞれが、個別ファイルとして記録されるコンテンツデータ記録媒体であって、
少なくとも前記コンテンツデータ記録媒体上における前記コンテンツデータの位置及びサイズを示すリンク情報と、
前記コンテンツデータの内容を記述し、前記個別ファイルの検索に用いられるメタデータと、
前記リンク情報と前記メタデータとを含む管理ファイルと
を有し、
前記管理ファイルを用いて、前記コンテンツデータ記録媒体にアクセスするアクセス装置に前記コンテンツデータを検索させることを特徴とするコンテンツデータ記録媒体。
【請求項４】
前記管理ファイルには、前記アクセス装置に前記コンテンツデータの再生を許可するライセンス管理情報が含まれることを特徴とする請求項３に記載のコンテンツデータ記録媒体。
【請求項５】
複数のコンテンツデータのそれぞれが、個別ファイルとして記録されるコンテンツデータ記録装置であって、
少なくとも前記コンテンツデータ記録媒体上における前記コンテンツデータの位置及びサイズを示すリンク情報を生成するリンク情報生成部と、
前記コンテンツデータの内容を記述し、前記個別ファイルの検索に用いられるメタデータを取得するメタ情報取得部と、
前記リンク情報と前記メタデータとを含む管理ファイルを生成する管理ファイル生成部と、
前記管理ファイルを用いて、前記コンテンツデータを検索するコンテンツ検索部と
を有することを特徴とするコンテンツデータ記録装置。
【請求項６】
前記管理ファイルには、前記コンテンツデータの再生を許可するライセンス管理情報が含まれており
前記ライセンス管理情報に基づいて、前記コンテンツデータを再生するコンテンツ再生部をさらに有することを特徴とする請求項５に記載のコンテンツデータ記録装置。
【請求項１】
複数のコンテンツデータのそれぞれが、個別ファイルとして記録されるコンテンツデータ記録媒体において用いられるコンテンツデータ構造であって、
少なくとも前記コンテンツデータ記録媒体上における前記コンテンツデータの位置及びサイズを示すリンク情報セグメントと、
前記コンテンツデータの内容を記述し、前記個別ファイルの検索に用いられるメタデータセグメントと、
前記リンク情報セグメントと前記メタデータセグメントとを含む管理ファイル領域と
を有し、
前記管理ファイル領域を用いて、前記コンテンツデータ記録媒体にアクセスするアクセス装置に前記コンテンツデータを検索させることを特徴とするコンテンツデータ構造。
【請求項２】
前記管理ファイル領域には、前記アクセス装置に前記コンテンツデータの再生を許可するライセンス管理情報セグメントが含まれることを特徴とする請求項１に記載のコンテンツデータ構造。
【請求項３】
複数のコンテンツデータのそれぞれが、個別ファイルとして記録されるコンテンツデータ記録媒体であって、
少なくとも前記コンテンツデータ記録媒体上における前記コンテンツデータの位置及びサイズを示すリンク情報と、
前記コンテンツデータの内容を記述し、前記個別ファイルの検索に用いられるメタデータと、
前記リンク情報と前記メタデータとを含む管理ファイルと
を有し、
前記管理ファイルを用いて、前記コンテンツデータ記録媒体にアクセスするアクセス装置に前記コンテンツデータを検索させることを特徴とするコンテンツデータ記録媒体。
【請求項４】
前記管理ファイルには、前記アクセス装置に前記コンテンツデータの再生を許可するライセンス管理情報が含まれることを特徴とする請求項３に記載のコンテンツデータ記録媒体。
【請求項５】
複数のコンテンツデータのそれぞれが、個別ファイルとして記録されるコンテンツデータ記録装置であって、
少なくとも前記コンテンツデータ記録媒体上における前記コンテンツデータの位置及びサイズを示すリンク情報を生成するリンク情報生成部と、
前記コンテンツデータの内容を記述し、前記個別ファイルの検索に用いられるメタデータを取得するメタ情報取得部と、
前記リンク情報と前記メタデータとを含む管理ファイルを生成する管理ファイル生成部と、
前記管理ファイルを用いて、前記コンテンツデータを検索するコンテンツ検索部と
を有することを特徴とするコンテンツデータ記録装置。
【請求項６】
前記管理ファイルには、前記コンテンツデータの再生を許可するライセンス管理情報が含まれており
前記ライセンス管理情報に基づいて、前記コンテンツデータを再生するコンテンツ再生部をさらに有することを特徴とする請求項５に記載のコンテンツデータ記録装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【公開番号】特開２００６−１５５４１７（Ｐ２００６−１５５４１７Ａ）
【公開日】平成１８年６月１５日（２００６．６．１５）
【国際特許分類】
【出願番号】特願２００４−３４７６４７（Ｐ２００４−３４７６４７）
【出願日】平成１６年１１月３０日（２００４．１１．３０）
【出願人】（０００００１８８９）三洋電機株式会社 (18,308)
【Ｆターム（参考）】
【公開日】平成１８年６月１５日（２００６．６．１５）
【国際特許分類】
【出願日】平成１６年１１月３０日（２００４．１１．３０）
【出願人】（０００００１８８９）三洋電機株式会社 (18,308)
【Ｆターム（参考）】
[ Back to top ]