JP4190571B2

JP4190571B2 - コンテンツデータ記録装置

Info

Publication number: JP4190571B2
Application number: JP2008014300A
Authority: JP
Inventors: 雄一金井
Original assignee: Sanyo Electric Co Ltd
Current assignee: Sanyo Electric Co Ltd
Priority date: 2008-01-24
Filing date: 2008-01-24
Publication date: 2008-12-03
Anticipated expiration: 2024-11-30
Also published as: JP2008176796A

Description

本発明は、複数のコンテンツデータのそれぞれが、個別ファイルとして記録される場合におけるコンテンツデータ記録装置に関する。

従来、ＣＤ−ＲやＤＶＤなど、取り外し可能（リムーバブル）な記録媒体（以下、“リムーバブル記録媒体”と適宜省略する）にオーディオデータなどのコンテンツデータを記録するためのフォーマットとして、ＵＤＦ（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）である。

リムーバブルＨＤＤ１１２６は、音楽レコーダ１０００からの取り外しが可能なリムーバブル記録媒体である。リムーバブルＨＤＤ１１２６は、ＣＤ１１０１からリッピングされたオーディオデータを記録し、上述したコンテンツデータ構造によって当該オーディオデータが管理される。

リムーバブルＨＤＤ１１２６には、上述したように、複数の音楽コンテンツ（ＭＣ３０_１，３０_２など）のそれぞれが、個別ファイルとして記録される。

モデム１１２８は、音楽レコーダ１０００（制御部１１１６）と、コンテンツサーバ１１３２及びメタデータサーバ１１３４とを、インターネット網１１３０を介して通信可能に接続するための通信デバイスである。

なお、音楽レコーダ１０００は、インターネット網１１３０との接続に用いられる通信回線の方式に基づいて、モデム１１２８以外の通信デバイス、例えば、メディアコンバータなどを実装することもできる。

（コンテンツデータ記録装置の動作）
次に、上述した本実施例に係る音楽レコーダ１０００（コンテンツデータ記録装置）の動作について説明する。

（１）リムーバルＨＤＤの初期化
図１２は、音楽レコーダ１０００に接続されるリムーバブルＨＤＤ１１２６の初期化処理フローを示している。

図１２に示すように、ステップＳ１０において、音楽レコーダ１０００は、ＡＵＲ＿ＲＯＯＴディレクトリを作成する。

ステップＳ２０において、音楽レコーダ１０００は、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルを作成する。具体的には、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルを構成するフィールドは、以下のように設定される。

・Ｆｌａｇ＝０
・ＮｕｍｏｆＵＩＥＴＧｓ＝１
・ＵＩＥＴＧＩＤ（１）＝００００（ＡＳＣＩＩ）
・ＴｒａｃｋＬｉｎｋＬｏｃａｔｉｏｎ＝ “．／ＰＲＯＧ＿ＳＥＴ．ＭＧＲ＃ＴｒａｃｋＬｉｎｋｓ”
・ＮｕｍｂｅｒｏｆＴｒａｃｋＧｒｏｕｐｓ＝１
・ＭａｘｉｍｕｍＴｒａｃｋＧｒｏｕｐＩＤ＝００００
ステップＳ３０において、音楽レコーダ１０００は、ＴｒａｃｋＬｉｎｋｓストリームファイルを作成する。具体的には、ＴｒａｃｋＬｉｎｋｓストリームファイルを構成するフィールドは、以下のように設定される。

・ＮｕｍｂｅｒｏｆＴｒａｃｋＬｉｎｋｓ＝０
・ＮｕｍｂｅｒｏｆＶａｌｉｄＴｒａｃｋＬｉｎｋｓ＝０
ステップＳ４０において、音楽レコーダ１０００は、ＴＧ＿００００ストリームファイルを作成する。具体的には、ＴＧ＿００００ストリームファイルを構成するフィールドは、以下のように設定される。

・ＴＧＳｐｅｃｉｆｉｃＳｔｒｕｃｔｕｒｅＴＹＰＥ＝０ｘ００
・ＴＧＦｌａｇ＝０ｘ０２
・ＴＧｓｐｅｃｉｆｉｃｓｔｒｕｃｔｕｒｅｎａｍｅ＝ “ＴｒａｃｋＢａｓｅ”
・ＬｉｎｋＣｏｕｎｔ＝０
・Ｎｕｍｂｅｒｏｆｅｌｅｍｅｎｔｓ＝０
ステップＳ５０において、音楽レコーダ１０００は、ＲＴ＿ＡＵＲＳディレクトリを作成する。

（２）ＣＤリッピング（１曲）
図１３は、ＣＤ１１０１（図１１参照）に含まれる音楽コンテンツ（オーディオデータ）から、１曲分のオーディオデータをリッピングし、リムーバブルＨＤＤ１１２６に記録するフローを示している。

図１３に示すように、ステップＳ１１０において、音楽レコーダ１０００は、ＣＤ１１０１に含まれるオーディオデータに基づいて、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルを作成する。具体的には、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルを構成するフィールドは、以下のように設定される。なお、以下に示すフィールドにおいて、具体的な内容がないフィールドについては、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルの内容に応じて適切なデータが記述される。

・ＮｕｍｂｅｒｏｆＴｒａｃｋｓ＝１
・ＡＵＤＦｌａｇ
・ＰｌａｙｂａｃｋＴｉｍｅ
・ＦｉｌｅＳｉｚｅ
・ＡｕｄｉｏＦｏｒｍａｔ＝（ＡＡＣ）
・Ｂｉｔｒａｔｅ
・ＦｉｌｅＣｒｅａｔｅｄＤａｔｅ
・ＣｈａｒａｃｔｅｒＳｅｔ（Ｕｎｉｃｏｄｅ）
・ＭｅｔａＤａｔａＦｉｌｅＦｏｒｍａｔ
・ＬｉｃｅｎｓｅＦｌａｇ
・ＬｉｃｅｎｓｅＦｉｌｅＬｏｃａｔｉｏｎ
ステップＳ１２０において、音楽レコーダ１０００は、ＴｒａｃｋＬｉｎｋｓストリームファイルの内容を更新する。具体的には、音楽レコーダ１０００は、以下に示すように、ＴｒａｃｋＬｉｎｋｓストリームファイルの内容を更新する。なお、以下に示すフィールドにおいて、具体的な内容がないフィールドについては、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルの内容などに応じて適切なデータが記述される。

・ＮｕｍｂｅｒｏｆＴｒａｃｋＬｉｎｋｓ＝ｎ＋１
・ＮｕｍｂｅｒｏｆＶａｌｉｄＴｒａｃｋＬｉｎｋｓ＝ｎ＋１
・ＴＬ構造体追加
・ＴＬＳｐｅｃｉｆｉｃＳｔｒｕｃｔｕｒｅＴＹＰＥ＝０ｘ１
・ＴＬＦｌａｇ
・ＬｉｎｋＣｏｕｎｔ＝１（ｆｒｏｍＴＧ＿００００）
・ＭｕｓｉｃＣｏｎｔｅｎｔＩＤ＝ｘｘｘｘｘｘｘ
・ＭｅｔａＤａｔａ
・ＭｙＲａｔｅＩｎｆｏ
・ＬａｓｔＡｃｃｅｓｓｅｄＴｉｍｅ
・ＰｌａｙｂａｃｋＣｏｕｎｔｅｒ
・ＲｅｓｕｍｅＰｏｉｎｔ
ステップＳ１３０において、音楽レコーダ１０００は、ＴＧ＿００００ストリームファイルの内容を更新する。具体的には、音楽レコーダ１０００は、以下に示すように、ＴＧ＿００００ストリームファイルの内容を更新する。

・Ｎｕｍｂｅｒｏｆｅｌｅｍｅｎｔｓ＝ｎ＋１
・ｅｌｅｍｅｎｔＩＤを追加
（３）ＣＤリッピング（音楽アルバム）
図１４は、ＣＤ１１０１に含まれる音楽コンテンツ（オーディオデータ）から、複数曲によって構成されるオーディオデータをリッピングし、リムーバブルＨＤＤ１１２６に記録するフローを示している。

図１４に示すように、ステップＳ２１０において、音楽レコーダ１０００は、ＣＤ１１０１に含まれるオーディオデータに基づいて、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルを作成する。具体的には、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルを構成するフィールドは、以下のように設定される。なお、以下に示すフィールドにおいて、具体的な内容がないフィールドについては、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルの内容に応じて適切なデータが記述される。

・ＮｕｍｂｅｒｏｆＴｒａｃｋｓ＝ｍ（音楽アルバムにｍ曲収容されている）
・ＡＵＤＦｌａｇ
・ＰｌａｙｂａｃｋＴｉｍｅ
・ＦｉｌｅＳｉｚｅ
・ＡｕｄｉｏＦｏｒｍａｔ＝（ＡＡＣ）
・Ｂｉｔｒａｔｅ
・ＦｉｌｅＣｒｅａｔｅｄＤａｔｅ
・ＣｈａｒａｃｔｅｒＳｅｔ（Ｕｎｉｃｏｄｅ）
・ＭｅｔａＤａｔａＦｉｌｅＦｏｒｍａｔ
・ＬｉｃｅｎｓｅＦｌａｇ
・ＬｉｃｅｎｓｅＦｉｌｅＬｏｃａｔｉｏｎ
ステップＳ２２０において、音楽レコーダ１０００は、ＴｒａｃｋＬｉｎｋｓストリームファイルの内容を更新する。具体的には、音楽レコーダ１０００は、以下に示すように、ＴｒａｃｋＬｉｎｋｓストリームファイルの内容を更新する。なお、以下に示すフィールドにおいて、具体的な内容がないフィールドについては、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルの内容などに応じて適切なデータが記述される。

・ＮｕｍｂｅｒｏｆＴｒａｃｋＬｉｎｋｓ＝ｎ＋ｍ
・ＮｕｍｂｅｒｏｆＶａｌｉｄＴｒａｃｋＬｉｎｋｓ＝ｎ+ｍ
・ｍ個のＴＬ構造体追加
ステップＳ２３０において、音楽レコーダ１０００は、ＴＧ＿００００ストリームファイルの内容を更新する。具体的には、音楽レコーダ１０００は、以下に示すように、ＴＧ＿００００ストリームファイルの内容を更新する。

・Ｎｕｍｂｅｒｏｆｅｌｅｍｅｎｔｓ＝ｎ+ｍ
・ｅｌｅｍｅｎｔＩＤを追加（ｍ個）
ステップＳ２４０において、音楽レコーダ１０００は、ＴＧ＿ｘｘｘｘストリームファイルを作成する。具体的には、ＴＧ＿ｘｘｘｘストリームファイルを構成するフィールドは、以下のように設定される。

・ＴＧＳｐｅｃｉｆｉｃＳｔｒｕｃｔｕｒｅＴＹＰＥ＝０ｘ０１
・ＴＧＦｌａｇ＝０ｘ０３
・ＴＧｓｐｅｃｉｆｉｃｓｔｒｕｃｔｕｒｅｎａｍｅ＝アルバムタイトル
・ＬｉｎｋＣｏｕｎｔ＝０
・Ｎｕｍｂｅｒｏｆｅｌｅｍｅｎｔｓ＝ｍ
・ｅｌｅｍｅｎｔＩＤ：ｍ個のＩＤを追加する
・各ｅｌｅｍｅｎｔのＴＬ構造体に含まれるＬｉｎｋＣｏｕｎｔに“１”を加算
ステップＳ２５０において、音楽レコーダ１０００は、ステップＳ２４０において作成したＴＧ＿ｘｘｘｘストリームファイルがリンクされる上位のＴＧ（例えば、図１０に示したＴＧ１０_Ａ）があるか否かを判定する。

ＴＧ＿ｘｘｘｘストリームファイルがリンクされる上位のＴＧがある場合（ステップＳ２５０のＹｅｓ）、ステップＳ２６０において、音楽レコーダ１０００は、当該上位ＴＧについてメンテナンスを実行する。具体的には、以下のようなメンテナンスが実行される。

・Ｎｕｍｂｅｒｏｆｅｌｅｍｅｎｔｓ＝ｎ＋１
・ｅｌｅｍｅｎｔＩＤ：追加したＴＧ＿ｘｘｘｘストリームファイルのｘｘｘ
ｘ部分を追加
ＴＧ＿ｘｘｘｘストリームファイルがリンクされる上位のＴＧがない場合（ステップＳ２５０のＮｏ）、ステップＳ２７０において、音楽レコーダ１０００は、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの内容を更新する。具体的には、音楽レコーダ１０００は、以下に示すように、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの内容を更新する。

・Ｆｌａｇ＝０
・ＮｕｍｏｆＵＩＥＴＧｓ＝２
・ＵＩＥＴＧＩＤ（２）＝ｘｘｘｘ（ＡＳＣＩＩ）
・ＮｕｍｂｅｒｏｆＴｒａｃｋＧｒｏｕｐｓ＝２
・ＵＩＥＴＧＩＤ（２）Ｎａｍｅ＝アルバムタイトル
・ＭａｘｉｍｕｍＴｒａｃｋＧｒｏｕｐＩＤ＝ｘｘｘｘ
以上、音楽レコーダ１０００が、ＣＤ１１０１に含まれる音楽コンテンツ（音楽コンテンツ）をリッピングする場合の動作について説明したが、音楽レコーダ１０００は、インターネット網１１３０を介して接続されているコンテンツサーバ１１３２に格納されている音楽コンテンツをダウンロードし、リムーバブルＨＤＤ１１２６に記録することもできる。

（４）ＣＤＤＢからのメタデータ取得
図１５は、ＣＤＤＢから、音楽コンテンツに関するメタデータを取得するフローを示している。

図１５に示すように、ステップＳ３１０において、ユーザは、ＣＤ１１０１をＣＤドライブ１１０２（図１１参照）に挿入する。

ＣＤ１１０１がＣＤドライブ１１０２（図１１参照）に挿入されると、ステップＳ３２０において、音楽レコーダ１０００は、メタデータサーバ１１３４からＣＤ１１０１に対応するメタデータを取得する。

具体的には、音楽レコーダ１０００は、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルのメタデータ管理情報を取得し、取得したメタデータ管理情報に基づいて、ＭｅｔａＤａｔａストリームファイルにメタデータを登録する。なお、音楽レコーダ１０００は、必要により、メタデータに用いられる文字コードを変換する。

ステップＳ３３０において、音楽レコーダ１０００は、対応するＴＬ構造体（表８参照）にメタデータを登録する。音楽レコーダ１０００は、登録対象のメタデータがフィールド長より長い場合、当該フィールドに記述することができない当該メタデータの部分を削除する。

（５）再生（タイトル検索・メタデータ表示）
図１６は、リムーバブルＨＤＤ１１２６に含まれる音楽コンテンツ（オーディオデータ）を再生するフローを示している。

図１６に示すように、ステップＳ４１０において、音楽レコーダ１０００は、ＡＵＲ＿ＲＯＯＴディレクトリの配下に位置するＡＵＤ＿ＳＥＴ．ＭＧＲファイルをオープンし、ＵＩＥＴＧ＿ＩＤのリスト及び名前をユーザに表示する。

ステップＳ４２０において、ユーザは、ＵＩＥＴＧ＿ＩＤのリストの中から、１つの
ＴＧ＿ＩＤを選択する。

ステップＳ４３０において、音楽レコーダ１０００は、選択されたＴＧ＿ＩＤに対応するＴＧ＿ｘｘｘｘストリームファイルをオープンし、ｅｌｅｍｅｎｔ＿ＩＤのリストをユーザに表示する。

ステップＳ４４０において、音楽レコーダ１０００は、ｅｌｅｍｅｎｔがＴＧか否かを判定する。

ｅｌｅｍｅｎｔがＴＧの場合（ステップＳ４４０のＹｅｓ）、音楽レコーダ１０００は、ステップＳ４２０からの処理を繰り返す。ｅｌｅｍｅｎｔがＴＧでない場合、すなわち、ｅｌｅｍｅｎｔがＴＬの場合（ステップＳ４４０のＮｏ）、ステップＳ４５０において、ユーザは、ｅｌｅｍｅｎｔ＿ＩＤのリストの中から、１つのＴＬ＿ＩＤを選択する。

ステップＳ４６０において、音楽レコーダ１０００は、ＴｒａｃｋＬｉｎｋｓストリームファイルから、選択されたＴＬ＿ＩＤに対応するＴＬ構造体を取得する。

ステップＳ４７０において、音楽レコーダ１０００は、取得したＴＬ構造体の“ＭｕｓｉｃＣｏｎｔｅｎｔｓＩＤ”、“ＳｔａｒｔＰｏｉｎｔｉｎＣｏｎｔｅｎｔｓＦｉｌｅ”及び“ＣｏｎｔｅｎｔｓＬｅｎｇｔｈ”から、ＡＵＤｘｘｘｘｘｘｘｘ．ＡＩＦファイルに含まれるＡｕｄｉｏＤａｔａストリームファイルの再生位置を確保する。

ステップＳ４８０において、音楽レコーダ１０００は、*ＵＤＦ＿ＬＩＣＥＮＣＥセキュアストリームファイルから、ライセンスファイル（復号鍵）を取得する。

ステップＳ４９０において、音楽レコーダ１０００は、取得した復号鍵を用いて、ＡｕｄｉｏＤａｔａストリームファイルに含まれるオーディオデータを復号して再生する。

ステップＳ５００において、音楽レコーダ１０００は、ＴＬ構造体のＰｌａｙｂａｃｋＣｏｕｎｔｅｒに“１”加算する。なお、ＰｌａｙｂａｃｋＣｏｕｎｔｅｒに加算するタイミングは、再生開始時ままたは再生終了時の何れでもよい。

ステップＳ５１０において、音楽レコーダ１０００は、オーディオデータ、つまり、音楽コンテンツの再生が途中で停止されたか否かを判定する。

音楽コンテンツの再生が途中で停止された場合（ステップＳ５１０のＹｅｓ）、ステップＳ５２０において、音楽レコーダ１０００は、当該停止した位置に対して、リジュームポイントを設定する。

（６）プレイリスト作成（ＴＧ）
図１７は、プレイリスト（ＴＧ）を作成するフローを示している。

図１７に示すように、ステップＳ６１０において、ユーザは、プレイリストのフォルダを作成する。プレイリストのフォルダがユーザによって作成されると、音楽レコーダ１０００は、ＴＧ＿ｘｘｘｘストリームファイルを生成する。具体的には、当該ＴＧ＿ｘｘｘｘストリームファイルを構成するフィールドは、以下のように設定される。

・ＴＧＳｐｅｃｉｆｉｃＳｔｒｕｃｔｕｒｅＴＹＰＥ＝０ｘ０２
・ＴＧＦｌａｇ＝０ｘ０３
・ＴＧｓｐｅｃｉｆｉｃｓｔｒｕｃｔｕｒｅｎａｍｅ＝プレーリストタイト
ル
・ＬｉｎｋＣｏｕｎｔ＝０
・Ｎｕｍｂｅｒｏｆｅｌｅｍｅｎｔｓ＝０
ステップＳ６２０において、ユーザは、ＴＧ＿００００ストリームファイルからユーザがプレイリストに登録するものをピックアップする。

ステップＳ６３０において、音楽レコーダ１０００は、ＴＧ＿ｘｘｘｘストリームファイルの内容を更新する。具体的には、音楽レコーダ１０００は、以下に示すように、ＴＧ＿ｘｘｘｘストリームファイルの内容を更新する。

・Ｎｕｍｂｅｒｏｆｅｌｅｍｅｎｔｓ＝ｎ＋１
・ｅｌｅｍｅｎｔＩＤ：選択されたＴＬ＿ＩＤを追加
・各ｅｌｅｍｅｎｔのＴＬ構造体に含まれるＬｉｎｋＣｏｕｎｔに“１”を加算
ステップＳ６４０において、音楽レコーダ１０００は、さらにプレイリストに追加するものがあるか否かを判定する。

さらにプレイリストに追加するものがある場合（ステップＳ６４０のＹｅｓ）、ユーザは、ステップＳ６２０からの処理を繰り返す。

プレイリストに追加するものがない場合（ステップＳ６４０のＮｏ）、ステップＳ６５０において、音楽レコーダ１０００は、ステップＳ６３０において更新したＴＧ＿ｘｘｘｘストリームファイルがリンクされる上位のＴＧ（例えば、図１０に示したＴＧ１０_Ａ）があるか否かを判定する。

ＴＧ＿ｘｘｘｘストリームファイルがリンクされる上位のＴＧがある場合（ステップＳ６５０のＹｅｓ）、ステップＳ６６０において、音楽レコーダ１０００は、当該上位ＴＧについて、メンテナンスを実行する。具体的には、ステップＳ２６０と同様なメンテナンスが実行される。

ＴＧ＿ｘｘｘｘストリームファイルがリンクされる上位のＴＧがない場合（ステップＳ２５０のＮｏ）、ステップＳ６７０において、音楽レコーダ１０００は、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの内容を更新する。具体的には、音楽レコーダ１０００は、ステップＳ２７０と同様に、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの内容を更新する。

なお、音楽レコーダ１０００がＴＧ＿ｘｘｘｘストリームファイルを生成する場合、“ｘｘｘｘ”部分の簡易的な割り当て方法としては、“ＭａｘｉｍｕｍＴｒａｃｋＧｒｏｕｐＩＤ”フィールド（表６参照）を参照して、現状の最大値に“１”を加算した値を割り当てるとともに、“ＭａｘｉｍｕｍＴｒａｃｋＧｒｏｕｐＩＤ”フィールドにも、現状の最大値に“１”を加算した値を割り当てる方法が用いられる。

また、他の割り当て方法としては、全てのＴＧ＿ＩＤをサーチして、欠損している番号（例えば、一度生成されて、その後削除した場合）があれば、当該番号を割り当てる方法がある。この場合、欠損している番号がなければ、上述したように、現状の最大値に“１”を加算した値を割り当てるとともに、“ＭａｘｉｍｕｍＴｒａｃｋＧｒｏｕｐＩＤ”フィールドにも、現状の最大値に“１”を加算した値を割り当てる。

すなわち、簡易的な割り当て方法では、全てのＴＧ＿ＩＤをサーチする必要がなく、より高速に“ｘｘｘｘ”部分の割り当て処理を実行することができる。

（７）メタデータによるリストのソート
図１８は、メタデータによって、リストをソートするフローを示している。図１８に示すように、ステップＳ７１０において、ユーザは、ＴＬのリストで表現されているＴＧを選択する。

ステップＳ７２０において、ユーザは、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルに含まれるＭｅｔａＤａｔａストリームファイル（メタデータ構造体）から検索したいフィールドを選択する。

ステップＳ７３０において、音楽レコーダ１０００は、ＴＧのｅｌｅｍｅｎｔであるＴＬに対応するＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルのＭｅｔａＤａｔａストリームファイルから候補のメタデータを検索する。ステップＳ７４０において、音楽レコーダ１０００は、該当するＴＬをメタデータ順にソートする。

より具体的には、図２６に示すように、５つのトラック（ＴＬ２０_１〜２０_５，ＭＣ３０_１〜ＭＣ３０_５）から構成されるＴｒａｃｋ＿Ｂａｓｅ（ＴＧ１０_ＴＢ）からメタデータによってリストをソートする場合、音楽レコーダ１０００は、ＴＬ＿ＩＤ＃１〜ＴＬ＿ＩＤ＃５のＴＬについて、以下の処理を実行する。

（ｉ）ＴＬ＿ＩＤ＃ｎ（ｎ＝１〜５）のＴＬ（ＴＬ２０_１〜２０_５）に対して、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルに属するＭｅｔａＤａｔａストリームファイルをオープンする。

（ｉｉ）ＭｅｔａＤａｔａストリームファイルの先頭から、“Ｇｅｎｒｅ”フィールドの先頭までのバイト数を演算する（表２６において、１＋ａ＋１＋ｂ＋１＋ｃ＋１＋ｄを演算することに該当）。

（ｉｉｉ） “ＬｅｎｇｔｈｏｆＧｅｎｒｅ”フィールドの値（＝ｅ）を取得する。

（ｉｖ） “ＬｅｎｇｔｈｏｆＧｅｎｒｅ”フィールドに続く“Ｇｅｎｒｅ”フィールドに記述されているデータを取得する。

（ｖ）ＴＬ＿ＩＤとＧｅｎｒｅデータとのリストを、既に取得したリスト（例えば、ＴＬ＿ＩＤ＃３の場合、ＴＬ＿ＩＤ＃１及びＴＬ＿ＩＤ＃２に係るリスト）と比較し、アルファベット順（日本語の場合は５０音順）にソートする。

ＴＬ＿ＩＤ＃１〜ＴＬ＿ＩＤ＃５のＴＬ（ＴＬ２０_１〜２０_５）について、上述した（ｉ）〜（ｖ）の処理を実行した音楽レコーダ１０００は、ソートされたＴＬ＿ＩＤ順にリストの内容を表示する。

（８）メタデータによるリストの高速ソート
図１９は、メタデータによって、リストを高速にソートするフローを示している。図１９に示すように、ステップＳ７１０Ａにおいて、ユーザは、ＴＬのリストで表現されているＴＧを選択する。

ステップＳ７２０Ａにおいて、ユーザは、ＴＬ構造体によって定義されているメタデータフィールドから、検索したいフィールドを選択する。

ステップＳ７３０Ａにおいて、音楽レコーダ１０００は、ＴＧのｅｌｅｍｅｎｔであるＴＬに対応するＴＬ構造体から候補のメタデータを検索する。ステップＳ７４０Ａにおいて、音楽レコーダ１０００は、該当するＴＬをメタデータ順にソートする。

すなわち、図１８に示したメタデータによるリストのソート方法では、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルに含まれるＭｅｔａＤａｔａストリームファイル（メタデータ構造体）をオープンして内容を検索しなければならないが、図１９に示したメタデータによるリストのソート方法では、３２４バイトの固定長を有するＴＬ構造体（表８参照）が用いられるため、より高速にソートを実行することができる。

より具体的には、図２６に示すように、５つのトラック（ＴＬ２０_１〜２０_５，ＭＣ３０_１〜ＭＣ３０_５）から構成されるＴｒａｃｋ＿Ｂａｓｅ（ＴＧ１０_ＴＢ）からメタデータによってリストを高速にソートする場合、音楽レコーダ１０００は、ＴｒａｃｋＬｉｎｋｓストリームファイルをオープンし、以下の処理を実行する。

（ｉ）ＴＬ＿ＩＤ＃１の“Ｇｅｎｒｅ”フィールドの先頭位置を取得する。具体的には、ＴＬ＿ＩＤ＃１の“Ｇｅｎｒｅ”フィールドの先頭位置が、ＴｒａｃｋＬｉｎｋｓストリームファイルの先頭から２１０バイト目（表７において、ＴＬ＿ＩＤ＃１に係るＴＬ構造体のデータは、８バイト目から開始され、表８において、“Ｇｅｎｒｅ”フィールドは、２０２バイト目から開始されている）であることを認識する。

（ｉｉ） “Ｇｅｎｒｅ”フィールドに記述されているデータを取得し、ＴＬ＿ＩＤとＧｅｎｒｅデータとのリストを記憶する。

（ｉｉｉ）ＴＬ＿ＩＤ＃２の“Ｇｅｎｒｅ”フィールドの先頭位置（５３４バイト目（２１０＋３２４バイト、表７及び表８参照））を取得する。同様に、ＴＬ＿ＩＤ＃３，＃４，＃５の先頭位置は、（２１０＋２×３２４）バイト目、（２１０＋３×３２４）バイト目、（２１０＋４×３２４）バイト目となる。

（ｉｖ）ＴＬ＿ＩＤとＧｅｎｒｅデータとのリストを、既に取得したリスト（例えば、ＴＬ＿ＩＤ＃３の場合、ＴＬ＿ＩＤ＃１及びＴＬ＿ＩＤ＃２に係るリスト）と比較し、アルファベット順（日本語の場合は５０音順）にソートする。

ＴＬ＿ＩＤ＃１〜ＴＬ＿ＩＤ＃５のＴＬ（ＴＬ２０_１〜２０_５）について、上述した（ｉ）〜（ｉｖ）の処理を実行した音楽レコーダ１０００は、ソートされたＴＬ＿ＩＤ順にリストの内容を表示する。

（９）メタデータによるリストの高速検索
図２０は、メタデータによって、リストを高速に検索するフローを示している。図２０に示すように、ステップＳ８１０において、ユーザは、ＴＬのリストで表現されているＴＧを選択する。

ステップＳ８２０において、ユーザは、ＴＬ構造体によって定義されているメタデータフィールドから、検索したいフィールドを選択する。

ステップＳ８３０において、ユーザは、選択したフィールドに対応する文字を入力する。

ステップＳ８４０において、音楽レコーダ１０００は、ＴＧのｅｌｅｍｅｎｔであるＴＬに対応するＴＬ構造体からメタデータを検索し、ユーザが入力した文字とマッチングを実行する。ステップＳ８５０において、音楽レコーダ１０００は、該当するＴＬのリストをユーザに表示する。

本検索方法でも、３２４バイトの固定長を有するＴＬ構造体（表８参照）が用いられるため、ＭｅｔａＤａｔａストリームファイルをオープンする場合と比較して、より高速な検索を実行することができる。

（１０）リジュームポイントの設定
図２１は、リジュームポイントを設定するフローを示している。図２１に示すように、ステップＳ９１０において、音楽レコーダ１０００は、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルからＵＩＥＴＧのリストをユーザに表示する。

ステップＳ９２０において、ユーザは、ＵＩＥＴＧリストから１つのＴＧを選択する。ステップＳ９３０において、音楽レコーダ１０００は、“ＬａｓｔＡｃｃｅｓｓｅｄＵＩＥＴＧ＿ＩＤ”フィールドに選択されたＴＧ＿ＩＤを記述する。また、音楽レコーダ１０００は、当該ＴＧ＿ＩＤを記述した時刻を“ＬａｓｔＡｃｃｅｓｓｅｄＵＩＥＴＧ＿ＩＤｒｅｃｏｒｄｅｄｄａｔｅ”に記述する。

ステップＳ９４０において、音楽レコーダ１０００は、選択されたＴＧのｅｌｅｍｅｎｔリストをユーザに表示する。

ｅｌｅｍｅｎｔがＴＧである場合（ステップＳ９５０のＮｏ）、ステップＳ９８０において、ユーザは、ＴＧリストから１つのＴＧを選択する。ステップＳ９９０において、音楽レコーダ１０００は、“Ｒｅｓｕｍｅｅｌｅｍｅｎｔ”に当該ＴＧ＿ＩＤを追加する
。

ｅｌｅｍｅｎｔがＴＬである場合（ステップＳ９５０のＹｅｓ）、ステップＳ９６０において、ユーザは、ＴＬリストから、１つのＴＬを選択する。ステップＳ９７０において、音楽レコーダ１０００は、“Ｒｅｓｕｍｅｅｌｅｍｅｎｔ”に当該ＴＬ＿ＩＤを追加する。

以降、音楽レコーダ１０００は、選択されたＴＬ＿ＩＤと対応するＴＬ構造体に基づいて、オーディオデータを再生する（図１６のステップＳ４７０以降の処理を参照）。

（１１）リジューム再生
図２２は、リジュームポイントに基づいて、オーディオデータを再生（リジューム再生）するフローを示している。図２２に示すように、ステップＳ１０１０において、音楽レコーダ１０００は、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの“ＬａｓｔＡｃｃｅｓｓｅｄＵＩＥＴＧ＿ＩＤ”に記述されているＴＧ＿ＩＤに該当するＴＧ＿ｘｘｘｘストリームファイルをオープンする。

ステップＳ１０２０において、音楽レコーダ１０００は、該当するＴＧの“Ｒｅｓｕｍｅｅｌｅｍｅｎｔ”に記述されているｅｌｅｍｅｎｔ＿ＩＤを取得する。

ステップＳ１０３０において、音楽レコーダ１０００は、ｅｌｅｍｅｎｔがＴＧか否かを判定する。ｅｌｅｍｅｎｔがＴＧの場合（ステップＳ１０３０のＹｅｓ）、音楽レコーダ１０００は、ステップＳ１０２０からの処理を繰り返す。

ｅｌｅｍｅｎｔがＴＬの場合（ステップＳ１０３０のＮｏ）、ステップＳ１０４０において、音楽レコーダ１０００は、リジュームポイントが設定されているか否かを判定する。

リジュームポイントが設定されている場合（ステップＳ１０４０のＹｅｓ）、ステップＳ１０５０において、音楽レコーダ１０００は、リジュームポイントからオーディオデータを再生する。一方、リジュームポイントが設定されていない場合（ステップＳ１０４０のＮｏ）、ステップＳ１０６０において、音楽レコーダ１０００は、曲（または音楽アルバム）の最初からオーディオデータを再生する。

なお、リジュームポイント設定をオプション仕様とする場合、上述したように、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの“ＲｅｓｕｍｅＳｕｐｐｏｒｔＦｌａｇ”が使用される。リジュームをサポートしている音楽レコーダなど（コンテンツデータ記録装置）は、立上げ時（電源投入時など）に１ｂを記録する。一方、リジュームをサポートしていない音楽レコーダなどは、立上げ時に０ｂを記録する。

また、リムーバブルＨＤＤ１１２６（リムーバブル記録媒体）を移動後、他の音楽レコーダなどで再生する場合、当該他の音楽レコーダなどは、まず、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの“ＲｅｓｕｍｅＳｕｐｐｏｒｔＦｌａｇ”の内容を読み込み、値が１ｂの場合にはリジューム再生を行い、値が０ｂの場合にはリジューム再生を行わない。

（１２）タイトル削除
図２３は、音楽コンテンツ（オーディオデータ）と対応付けられているタイトルを削除するフローを示している。図２３に示すように、ステップＳ１１１０において、音楽レコーダ１０００は、ＴＧ＿００００ストリームファイル（Ｔｒａｃｋ＿Ｂａｓｅ（ＴＧ１０_ＴＢ））をオープンし、ｅｌｅｍｅｎｔ＿ＩＤのリストと名前をユーザに表示する。

ステップＳ１１２０において、ユーザは、削除するタイトルを１つ選択する。ステップＳ１１３０において、音楽レコーダ１０００は、当該タイトルのＴＬとリンクされているＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルが１トラックのみで構成されているか否かを判定する。

ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルが１トラックのみで構成されている場合（ステップＳ１１３０のＹｅｓ）、ステップＳ１１６０において、音楽レコーダ１０００は、当該ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルを削除する。

ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルが１トラックのみで構成されていない場合（ステップＳ１１３０のＮｏ）、すなわち、複数曲で構成されている場合、ステップＳ１１４０において、音楽レコーダ１０００は、ＴＬから当該ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルへのリンクをサーチする。

ステップＳ１１５０において、音楽レコーダ１０００は、ＴＬから当該ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルへのリンクが１以上存在するか否かを判定する。

当該ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルへのリンクが１以上存在する場合（ステップＳ１１５０のＹｅｓ）、音楽レコーダ１０００は、当該ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルを削除せず、ステップＳ１１７０の処理を実行する。

一方、当該ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルへのリンクが全く存在しない場合（ステップＳ１１５０のＮｏ）、ステップＳ１１６０において、音楽レコーダ１０００は、当該ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルを削除する。

ステップＳ１１７０において、音楽レコーダ１０００は、当該ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルと対応付けられているＴＬ構造体を削除するとともに、当該ＴＬ構造体をリンクしているＴＧから、当該ＴＬへのリンクを削除する。具体的には、ＴＬ構造体の“ＬｉｎｋＣｏｕｎｔ”にＴＧからリンクされている数が記述されているため、音楽レコーダ１０００は、“ＬｉｎｋＣｏｕｎｔ”に基づいて、当該ＴＬへのリンクを削除する。

また、ＴｒａｃｋＬｉｎｋｓストリームファイルからＴＬ構造体を削除した場合、他のＴＬ＿ＩＤが、“１”づつ小さくなる（ＴＬ＿ＩＤは、並び順のため）。このため、全てのＴＧに対して、削除したＴＬのＴＬ＿ＩＤ、及び当該ＴＬ以降のＴＬ＿ＩＤのメンテナンスが必要となる。

すなわち、音楽レコーダ１０００は、削除されたＴＬ＿ＩＤの値よりも大きな値のＴＬ＿ＩＤをリンクしているＴＧのメンテナンスを実行する。具体的には、当該ＴＬ＿ＩＤの値が、それぞれ“１”減らされる。

図２４は、図２３に示した“タイトル削除”のフローの変更部分を示している。図２４に示すステップＳ１１４１及びステップＳ１１４２の処理は、図２３に示すＳ１１７０の処理に代えて、実行される。

ステップＳ１１４１において、音楽レコーダ１０００は、削除するＴＬ構造体をリンクしているＴＧから、当該ＴＬのリンクを削除する
ステップＳ１１４２において、音楽レコーダ１０００は、当該ＴＬ構造体のＶａｌｉｄビッドをＯＦＦにするとともに、当該ＴＬ構造体をリンクしているＴＧから、当該ＴＬへのリンクを削除する
なお、この場合、上述したＴＬ＿ＩＤのメンテナンスは必要ない。つまり、ＴＬ構造体自体は削除されないためＴＬ＿ＩＤが変化しない。ただし、ＴＧに対しては、削除したＴＬ＿ＩＤの削除が必要となる。この簡易的な方法によれば、次回ＴＬを追加する場合、ＶａｌｉｄビッドがＯＦＦとなっている領域を再使用することができる。

（１３）プリセットモデルにおける購入
図２５は、リムーバブルＨＤＤ１１２６に予め暗号化された音楽コンテンツ（オーディオデータ）が記録されたプリセットモデルにおいて、ユーザが、所望の音楽コンテンツを購入するフローを示している。

プリセットモデルの場合、オーディオデータ（ＡｕｄｉｏＤａｔａストリームファイル）は、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルに記録される。また、ＴＬは、プリセットモデル専用にＰＲＴＬｓストリームファイルに記録される。ユーザは、このようにオーディオデータや各種ファイルが記録されたリムーバブルＨＤＤ１１２６を入手（購入）する。

この状態では、ユーザは、リムーバブルＨＤＤ１１２６に記録されている音楽コンテンツ（オーディオデータ）を視聴することができないため、購入手続きを行う必要がある。具体的には、図２５に示すように、ステップＳ１２１０において、ユーザは、音楽レコーダ１０００による高速検索（図２０参照）などを利用して、購入する音楽コンテンツを選択する。

ステップＳ１２２０において、ユーザは、当該音楽コンテンツを視聴するためのライセンス（復号鍵及び利用条件）を購入する。具体的には、ユーザは、コンテンツサーバ１１３２などにアクセスして、当該ライセンスを購入する。

ユーザによってライセンスが購入されると、ステップＳ１２３０において、音楽レコーダ１０００は、購入した音楽コンテンツに係るＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルに含まれるライセンス管理情報である“ＬｉｃｅｎｓｅＦｌａｇ”をセットすると同時に、*ＵＤＦ＿ＬＩＣＥＮＣＥセキュアストリームファイルを生成する。

ステップＳ１２４０において、音楽レコーダ１０００は、当該ＴＬをＰＲＴＬｓストリームファイルからＴｒａｃｋＬｉｎｋｓストリームファイルに移動する（詳細については、上述した図７及び図８に係る説明を参照）。なお、ＰＲＴＬｓストリームファイルにおけるタイトルは、図２４に示した簡易的な方法によって削除される。

（作用・効果）
以上説明した本実施形態及び本実施例によれば、音楽コンテンツなどのオーディオデータを利用するユーザは、トラックリンク情報及びメタデータ管理情報（ＭｅｔａＤａｔａストリームファイル）を含むＡＵＤ＿ＳＥＴ．ＭＧＲファイルを用いるため、音楽コンテンツの検索、再生がさらに容易かつ速やかに行え、音楽コンテンツの取扱いに係る利便性を向上させることができる。

（その他の実施形態）
上述したように、本発明の一実施形態を通じて本発明の内容を開示したが、この開示の一部をなす論述及び図面は、本発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施の形態が明らかとなろう。

例えば、上述した本発明の実施形態では、音楽コンテンツ（オーディオデータ）を例として説明したが、本発明は、音楽コンテンツのみではなく、例えば、静止画像や動画のコンテンツに適用することもできる。

また、上述した本発明の実施形態では、リムーバブルＨＤＤ１１２６（リムーバブル記録媒体）を例として説明したが、本発明は、コンテンツデータ記録装置などに内蔵されるハードディスクドライブ（ＨＤＤ）などにも適用することができる。

このように、本発明は、ここでは記載していない様々な実施の形態などを含むことは、もちろんである。したがって、本発明の技術的範囲は、上述の説明から妥当な特許請求の範囲に係る発明特定事項によってのみ定められるものである。

本発明の実施形態に係るファイルフォーマットの概要を示す図である。本発明の実施形態に係るディレクトリ及びファイルの構成を示す図である。本発明の実施形態に係るＡＵＤ＿ＳＥＴ．ＭＧＲの構成を示す図である。本発明の実施形態に係るＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルの構成を示す図である。本発明の実施形態に係る“Ｔｒａｃｋ＿Ｂａｓｅ”を用いたモデル構成例を示す図である。本発明の実施形態に係る“Ｐｒｅｓｅｔ＿Ｔｒａｃｋ＿Ｂａｓｅ”を用いたモデル構成例を示す図である。本発明の実施形態に係るモデル構成例において、暗号化された音楽コンテンツのライセンスが取得（購入）される前の状態を示す図である。本発明の実施形態に係るモデル構成例において、暗号化された音楽コンテンツのライセンスが取得（購入）された後の状態を示す図である。本発明の実施形態に係る音楽コンテンツ管理モデルの基本的な構成例を示す図である。本発明の実施形態において、音楽アルバムを管理する場合における構成例を示している。本発明の実施例に係る音楽レコーダ（コンテンツデータ記録装置）の構成を示す図である。本発明の実施例に係る音楽レコーダの動作フローを示す図である。本発明の実施例に係る音楽レコーダの動作フローを示す図である。本発明の実施例に係る音楽レコーダの動作フローを示す図である。本発明の実施例に係る音楽レコーダの動作フローを示す図である。本発明の実施例に係る音楽レコーダの動作フローを示す図である。本発明の実施例に係る音楽レコーダの動作フローを示す図である。本発明の実施例に係る音楽レコーダの動作フローを示す図である。本発明の実施例に係る音楽レコーダの動作フローを示す図である。本発明の実施例に係る音楽レコーダの動作フローを示す図である。本発明の実施例に係る音楽レコーダの動作フローを示す図である。本発明の実施例に係る音楽レコーダの動作フローを示す図である。本発明の実施例に係る音楽レコーダの動作フローを示す図である。本発明の実施例に係る音楽レコーダの動作フローを示す図である。本発明の実施例に係る音楽レコーダの動作フローを示す図である。本発明の実施例に係る音楽レコーダにおいて実行されるトラックリンクのソート動作を説明するためのモデル構成図である。

符号の説明

１０，１０_Ａ，１０_Ａ１〜１０_Ａ３，１０_ＡＴ，１０_Ｂ，１０_ＰＬ１〜１０_ＰＬ３，１０_ＰＬＴ，１０_ＰＴＢ，１０_ＴＢ…ＴＧ（トラックグループ）
２０_１〜２０_Ｎ＋１，２１_１〜２１_Ｎ＋１…ＴＬ（トラックリンク）
３０_１〜３０_４，３０_Ｍ…ＭＣ（記録済み音楽コンテンツ）
１００…ＲＯＯＴディレクトリ
１１０…ＡＵＲ＿ＲＯＯＴディレクトリ
１２０…ＡＵＤ＿ＳＥＴ．ＭＧＲ
１３０…ＲＴ＿ＡＵＲＳディレクトリ
１４０…ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイル
１０００…音楽レコーダ
１１０１…ＣＤ
１１０２…ＣＤドライブ
１１０４…ＡＡＣエンコーダ
１１０６…暗号化処理部
１１０８…復号化処理部
１１１０…ＡＡＣデコーダ
１１１２…Ｄ／Ａ変換部
１１１４…スピーカ
１１１６…制御部
１１１８…表示部
１１２０…リモコン受光部
１１２２…リモコン
１１２４…ＡＴＡインタフェース
１１２６…リムーバブルＨＤＤ
１１２８…モデム
１１３０…インターネット網
１１３２…コンテンツサーバ
１１３４…メタデータサーバ

Claims

記録媒体に記録されたコンテンツデータを視聴させるための制御手段と、
前記コンテンツデータにアクセスするアクセス手段とを備える記録装置であって、
前記記録媒体は、コンテンツデータを含むコンテンツファイル群と、前記コンテンツデータの管理情報であるトラックリンクを含むトラックリンクファイルを有し、
前記トラックリンクファイルは、視聴に制限がある第１のコンテンツデータを管理するための第１のトラックリンクファイルと、視聴に制限のない第２のコンテンツデータを管理するための第２のトラックリンクファイルとを有するように構成されており、
前記コンテンツファイル群は、コンテンツデータを記録するコンテンツファイルと、前記コンテンツデータの付加情報である可変長のメタデータを記録するメタデータファイルを含み、
前記トラックリンクは、固定長のデータ構造を有し、かつ、前記コンテンツファイルへのリンク情報と、前記可変長のメタデータが所定の長さより長い場合、前記可変長のメタデータから、その長い部分を削除することで生成した固定長のメタデータを含み、
前記制御手段は、前記第１のコンテンツデータを視聴するためのライセンスが取得されると、前記ライセンス情報を格納するライセンスファイルを生成する手段と、
前記ライセンスファイルを前記第１のコンテンツデータを含むコンテンツファイルに関連付ける手段と、
前記第１のコンテンツデータに対応したライセンスが取得されたことより、前記第１のコンテンツデータの視聴が許可されると、前記ライセンスが取得された第１のコンテンツデータに対応する第１のトラックリンクを、前記第１のトラックリンクファイルから前記第２のトラックリンクファイルへ移動する移動手段とを備え、
前記アクセス手段は、前記トラックリンクのリンク情報を参照することで、前記コンテンツデータにアクセスする、
ことを特徴とする記録装置。
前記記録装置は、前記固定長のメタデータに基づき、前記コンテンツデータのソートを実行する、
ことを特徴とする請求項１に記載の記録装置。