(57)【要約】【課題】  メディアファイルのレンダリング中のメディアプレイヤのオペレーションの最適化を提供すること。【解決手段】  本発明は、データ構造を作成するため、かつ、作成されたデータ構造を、得られたメタデータによりポピュレートするためのオーサリングソフトウェアを含む。本発明はまた、メタデータをデータ構造から検索するため、かつ、レンダリングするためのメディアファイルを識別するためのレンダリングソフトウェアも含む。一実施形態では、本発明は、圧縮メディアフォーマットの一部として動作可能であり、これは、機能が豊富なパーソナルコンピュータのメディアプレイヤならびに低コストのメディアプレイヤ上で再生するために設計された、コンパイルされたバイナリフォーマットにおけるメタデータ、メニューおよびプレイリストを含む小型ファイルのセットを有する。【選択図】  図１
2004164824.tif 000002
【特許請求の範囲】
【請求項１】
メディアプレイヤが、コンピュータ可読媒体にアクセスして当該コンピュータ可読媒体上に格納されたメディアファイルをレンダリングし、前記コンピュータ可読媒体がさらに前記メディアファイルに関連付けられたメモリ最適化データを格納する、メディアプレイヤのオペレーションを最適化する方法であって、
１つまたは複数の選択されたメディアファイルについてのメタデータを取得するステップと、
前記選択されたメディアファイルをレンダリングする前に前記メディアプレイヤによってアクセス可能であるデータ構造を作成するステップと、
前記作成されたデータ構造を、前記得られたメタデータによりポピュレートするステップと、
前記ポピュレートされたデータ構造を前記コンピュータ可読媒体上で、前記選択されたメディアファイルと共に格納するステップとを含むことを特徴とする方法。
【請求項２】
前記コンピュータ可読媒体はデータを複数のセッションに格納し、格納するステップは、前記ポピュレートされたデータ構造を、前記コンピュータ可読媒体上の最後のセッションに格納するステップを含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記選択されたメディアファイルをディレクトリにより編成するステップと、
前記編成されたメディアファイルをソートするステップとをさらに含み、前記編成するステップおよび前記ソートするステップは、前記選択されたメディアファイルの探索を容易にすることを特徴とする請求項１に記載の方法。
【請求項４】
前記取得するステップは、前記選択されたメディアファイルの１つまたは複数を参照するプレイリストを生成するステップを含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記選択されたメディアファイルがそれぞれディレクトリ名に関連付けられ、
数値識別子を各ディレクトリ名について決定するステップと、
前記データ構造を、前記決定された数値識別子によりポピュレートするステップとをさらに含むことを特徴とする請求項１に記載の方法。
【請求項６】
前記選択されたメディアファイルを圧縮するステップをさらに含み、前記メディアファイルが、前記コンピュータ可読媒体上に格納する前に圧縮されることを特徴とする請求項１に記載の方法。
【請求項７】
前記データ構造に格納された前記メタデータをユーザに、前記メディアプレイヤに関連付けられたディスプレイ上で表示するステップをさらに含み、前記メタデータはコンテンツ関係データを含み、前記コンテンツ関係データが、対応するメディアファイルのタイトル、作曲家、演奏者、ジャンル、スタジオ、ディレクター、評価、アーティスト、およびコンテンツの説明のうち１つまたは複数から選択されることを特徴とする請求項１に記載の方法。
【請求項８】
前記ポピュレートされたデータ構造はテキストおよびバイナリデータを備え、前記テキストデータの少なくとも一部を前記メディアプレイヤによって、前記選択されたメディアファイルのレンダリング中に前記選択されたメディアファイルと関連して表示するステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項９】
前記選択されたメディアファイルをレンダリングする前に、前記コンピュータ可読媒体上に格納された前記ポピュレートされたデータ構造を検索するステップと、
前記検索されたデータ構造に応答して、前記選択されたメディアファイルを識別するステップとをさらに含み、前記選択されたメディアファイルが、前記メディアプレイヤによってレンダリングされるように適合されることを特徴とする請求項１に記載の方法。
【請求項１０】
１つまたは複数のコンピュータ可読媒体は、請求項１に記載の方法を実行するためのコンピュータ実行可能命令を有することを特徴とする請求項１に記載の方法。
【請求項１１】
メディアプレイヤにおいて、１つまたは複数のコンピュータ可読媒体が、メディアプレイヤのオペレーションを最適化するためのコンピュータ実行可能コンポーネントを有し、前記メディアプレイヤは、コンピュータ可読媒体にアクセスして、その上に格納されたメディアファイルをレンダリングし、前記コンピュータ可読媒体はさらに、前記メディアファイルに関連付けられたメモリ最適化データを格納し、前記コンポーネントは、
１つまたは複数の選択されたメディアファイルについてのメタデータを取得するための準備モジュールと、
前記選択されたメディアファイルをレンダリングする前に前記メディアプレイヤによってアクセス可能であるように適合されたデータ構造を作成するための初期化モジュールと、
前記初期化モジュールからの前記作成されたデータ構造を、前記準備モジュールからの前記得られたメタデータによりポピュレートするための編成モジュールと、
前記編成モジュールからの前記ポピュレートされたデータ構造を前記コンピュータ可読媒体上で、前記選択されたメディアファイルと共に格納するためのライタモジュールとを備えることを特徴とするコンピュータ可読媒体。
【請求項１２】
前記編成モジュールは、数値識別子を前記選択されたメディアファイルに関連付け、前記数値識別子が順番に順序付けられ、各々は前記選択されたメディアファイルの各々に対応し、前記編成モジュールは前記数値識別子を前記データ構造に格納することを特徴とする請求項１１に記載のコンピュータ可読媒体。
【請求項１３】
前記準備モジュールは、前記選択されたメディアファイルの各々についての論理セクタ番号を識別することを特徴とする請求項１１に記載のコンピュータ可読媒体。
【請求項１４】
前記選択されたメディアファイルをレンダリングする前に、前記コンピュータ可読媒体上に格納された前記ポピュレートされたデータ構造を検索するための入力モジュールと、
前記入力モジュールを介して検索された前記データ構造に応答して、前記選択されたメディアファイルを識別するためのフィルタモジュールとをさらに備え、前記選択されたメディアファイルが、前記メディアプレイヤによってレンダリングされるように適合されることを特徴とする請求項１１に記載のコンピュータ可読媒体。
【請求項１５】
コンピュータ可読媒体上に格納された１つまたは複数のメディアファイルに関連付けられたメディアプレイヤのオペレーションを最適化するメモリ最適化データを表すデータ構造を格納しているコンピュータ可読媒体であって、前記メディアプレイヤは、前記コンピュータ可読媒体にアクセスして前記メディアファイルをレンダリングし、前記データ構造は、
１つまたは複数のメディアファイルに関連付けられたテキストおよびバイナリデータへの参照を格納する、オフセットフィールドを含むヘッダと、
ディレクトリ番号を、前記１つまたは複数のメディアファイルに関連付けられたディレクトリ名と合致させる、ディレクトリテーブルとを備え、前記ヘッダは、前記ディレクトリ番号により前記メディアファイルを参照することを特徴とするコンピュータ可読媒体。
【請求項１６】
前記ディレクトリテーブルは、前記ディレクトリ名の１つにそれぞれ対応する、順番に付番されたエントリを有することを特徴とする請求項１５に記載のコンピュータ可読媒体。
【請求項１７】
前記ヘッダは、オーディオメディアファイル、ビデオメディアファイルおよび静止画像メディアファイルについての別々のオフセットフィールドを含むことを特徴とする請求項１５に記載のコンピュータ可読媒体。
【請求項１８】
メタデータは、前記メディアファイルに関連付けられた、メニュー情報、プレイリスト情報およびサムネイル画像のうち１つまたは複数を備えることを特徴とする請求項１５に記載のコンピュータ可読媒体。
【請求項１９】
前記各メディアファイルについての論理セクタ番号を格納するセクタフィールドをさらに備えることを特徴とする請求項１５に記載のコンピュータ可読媒体。
【請求項２０】
前記コンピュータ可読媒体はデータをセクタに格納し、前記オフセットフィールドがセクタ境界で格納されることを特徴とする請求項１５に記載のコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はデジタルメディアコンテンツの分野に関する。詳細には、本発明はレンダリング中のメディアプレイヤのメモリ使用の最適化に関する。
【背景技術】
【０００２】
最近の技術の発達により、コンピュータのユーザは現在、様々なメディアおよびマルチメディアコンテンツを自分のパーソナルまたはラップトップコンピュータ上でプレイするなど、改善されたユーザ体験を提供する多数の機能を享受することができる。たとえば、大抵の今日のコンピュータはコンパクトディスク（ＣＤ）をプレイすることができるので、ユーザがコンピュータ上で作業する間に自分の好みの音楽アーティストを聴くことができる。多数のコンピュータはまたデジタル多用途ディスク（ＤＶＤ）ドライブも装備しており、ユーザが映画を見ることができる。
【０００３】
音楽がパーソナルコンピュータ（ＰＣ）上で、Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐオーディオレイヤ３（ＭＰ３）ファイルおよびＷＩＮＤＯＷＳ（登録商標）ＭＤＥＩＡ技術オーディオ（ＷＭＡ）ファイルなど、圧縮メディアファイルからプレイされるとき、ＰＣは通常、メモリ内ですべてのアルバム、アーティスト、ジャンル、年などの完全なデータベースを保持し、ユーザがこれらの属性の中でナビゲートできるようにする。しかし、音楽が書き込み可能ＣＤまたはＤＶＤにコピーされ、ポータブルＣＤプレイヤ、カーレシーバ、ＤＶＤプレイヤ、または、比較的低能力のプロセッサ、制限されたメモリ可用性、安価なドライブ機構、およびしばしば制限されたディスプレイおよびユーザ入力機能を有する他のいずれかの家電デバイスでプレイされるとき、同じ範囲のメタデータが使用可能ではない。
【０００４】
圧縮メディアコンテンツをレンダリングする、現在使用可能なメディアプレイヤは、オーディオの再生を開始するために長い時間を要する可能性がある（たとえば、通常は約３０秒であるが、数分以上を要する可能性があるものもある）。このようなメディアプレイヤの遅い起動時間は部分的には、メディアプレイヤが、メディアコンテンツを格納するメディア全体をスキャンして、個々の各メディアファイルから検索されたいずれかの関連メタデータ（たとえば、タイトル、アーティストおよびジャンル）と共にマルチプレイヤがレンダリングすることができるファイルのリストを構築するために、必要とされる時間による。しばしば、既存のメディアプレイヤは、圧縮メディアコンテンツに関連付けられたいかなるメタデータも検索または表示しない。このような既存のメディアプレイヤは、ジャンル毎のプレイ、またはアーティスト毎のプレイなど、豊富なナビゲーション機能を提供することができない。豊富なナビゲーション機能の欠乏は部分的には、メディアコンテンツからのメタデータをメニューおよびプレイリストに動的にソートおよび集約するための、既存のメディアプレイヤのメモリおよび処理能力が不十分であることによる。
【０００５】
これらの理由のため、レンダリング中にメディアプレイヤのメモリ使用を最適化するためのシステムが、これらおよび他の欠点の１つまたは複数に対処するために望まれる。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
本発明は、メディアファイルのレンダリング中にメディアプレイヤのオペレーションを最適化するためのソフトウェアを含む。詳細には、本発明は、データ構造を作成するため、かつ、作成されたデータ構造を、得られたメタデータによりポピュレートするためのオーサリングソフトウェアを含む。本発明によれば、レンダリングソフトウェアはメタデータをデータ構造から検索し、レンダリングするためのメディアファイルを識別する。
【課題を解決するための手段】
【０００７】
本発明のメタデータキャッシュは、メモリ使用およびディスク読み取りの最適化を、テキストおよびバイナリメタデータを異なるキャッシュファイルに分離することによって、かつ、キャッシュの実際のレイアウトによって提供する。最適化されたメタデータキャッシュは、各圧縮メディアファイルからの関連メタデータを格納する。様々な機構が使用されて、たとえばコンピュータ可読媒体上のキャッシュおよび圧縮メディアファイルのコヒーレンシーが、メタデータキャッシュがメディア上の最後のセッション内に存在するときにこれを認識することのみによって保証される。メディアプレイヤはキャッシュを使用して、メディア上のオーディオ、ビデオまたはイメージファイル、および各ファイルについてのいずれかの関連情報を効率的に識別する。一実施形態では、本発明のソフトウェアは長い起動時間を著しく短縮し、これはメディアプレイヤが再生を開始するためにメタデータキャッシュファイルをロードすることのみが必要であり、メディア上のすべてのファイルを最初にスキャンする必要がないからである。さらに、メディアプレイヤは各メディアファイルのヘッダを開いて読み、メタデータをそこから収集する必要がない。したがって、ディスクシークオペレーションの総数および距離、およびディスク読み取りオペレーションの総数が最小限にされる。低速のメディアプレイヤ機構でさえ、本発明のソフトウェアによって作成されたメディアコンテンツをレンダリングするとき、改善された再生体験をユーザに提供する。
【０００８】
本発明によれば、メタデータキャッシュは、メモリ効率のよい方法で編成された関連バイナリおよびテキストメタデータを含み、これによりメモリフットプリントをディスクのローディングおよびディスクの再生中のいつでも最小限にする。メモリ使用が最小限にされ、ローディングが完了した後かつ再生が開始する前にメモリを効率的に再生することができる。これにより、最大可能な量のメモリを、圧縮された音楽サンプルまたは他のメディアファイルを格納するために、レンダリング中に使用可能にすることができる。メモリ使用がさらに、再生デバイスの階層機能リストに基づいて最適化される。すなわち、最も単純なオーディオ専用デバイスは最低量のメモリを使用するが、より高能力のビデオプレイヤはより多くのメモリを使用することができ、さらに同じメディアがなお、そのデバイスのすべての機能をサポートする各デバイスにおいてプレイ可能である。
【０００９】
本発明の一態様によれば、ある方法がメディアプレイヤのオペレーションを最適化する。メディアプレイヤは、その上に格納されたメディアファイルをレンダリングするためにコンピュータ可読媒体にアクセスする。コンピュータ可読媒体はまた、メディアファイルに関連付けられたメモリ最適化データも格納する。この方法は、１つまたは複数の選択されたメディアファイルについてのメタデータを得る。この方法はまた、選択されたメディアファイルをレンダリングする前にメディアプレイヤによってアクセス可能であるデータ構造も作成する。この方法はまた、作成されたデータ構造を、前記得られたメタデータによりポピュレートする。この方法はまた、ポピュレートされたデータ構造をコンピュータ可読媒体上で、選択されたメディアファイルと共に格納する。
【００１０】
本発明の一態様によれば、メディアオーサリングツールにおける１つまたは複数のコンピュータ可読媒体は、メディアプレイヤのオペレーションを最適化するためのコンピュータ実行可能コンポーネントを有する。メディアプレイヤは、その上に格納されたメディアファイルをレンダリングするためにコンピュータ可読媒体にアクセスする。コンピュータ可読媒体はまた、メディアファイルに関連付けられたメモリ最適化データも格納する。このコンポーネントは、１つまたは複数の選択されたメディアファイルについてのメタデータを得るための準備モジュールを含む。このコンポーネントはまた、選択されたメディアファイルをレンダリングする前にメディアプレイヤによってアクセス可能であるように適合されたデータ構造を作成するための初期化モジュールも含む。このコンポーネントはまた、初期化モジュールからの作成されたデータ構造を、準備モジュールからの得られたメタデータによりポピュレートするための編成モジュールも含む。このコンポーネントはまた、編成モジュールからのポピュレートされたデータ構造をコンピュータ可読媒体上で、選択されたメディアファイルと共に格納するためのライタモジュールも含む。
【００１１】
本発明のもう１つの態様によれば、ある方法がメディアプレイヤのオペレーションを最適化する。メディアプレイヤは、その上に格納されたメディアファイルをレンダリングするためにコンピュータ可読媒体にアクセスする。コンピュータ可読媒体はまた、メディアファイルに関連付けられたメモリ最適化データも格納する。この方法は、メディアファイルをレンダリングする前に、コンピュータ可読媒体上に格納されたメモリ最適化データを検索する。メモリ最適化データが、コンピュータ可読媒体上に格納された１つまたは複数の選択されたメディアファイルに関連付けられる。この方法はまた、検索されたメモリ最適化データに応答して、選択されたメディアファイルを識別する。選択されたメディアファイルが、メディアプレイヤによってレンダリングされるように適合される。
【００１２】
本発明のさらにもう１つの態様によれば、メディアプレイヤは、メディアプレイヤのオペレーションを最適化するためのコンピュータ実行可能コンポーネントを格納する、１つまたは複数のコンピュータ可読媒体を有する。メディアプレイヤは、その上に格納されたメディアファイルをレンダリングするためにコンピュータ可読媒体にアクセスする。コンピュータ可読媒体はまた、メディアファイルに関連付けられたメモリ最適化データも格納する。このコンポーネントは、メディアファイルをレンダリングする前に、コンピュータ可読媒体上に格納されたメモリ最適化ファイルを検索するための入力モジュールを含む。メモリ最適化データが、コンピュータ可読媒体上に格納された１つまたは複数の選択されたメディアファイルに関連付けられる。このコンポーネントはまた、入力モジュールからの検索されたメモリ最適化データに応答して、選択されたメディアファイルを識別するためのフィルタモジュールも含む。選択されたメディアファイルが、メディアプレイヤによってレンダリングされるように適合される。
【００１３】
本発明のさらにもう１つの態様によれば、コンピュータ可読媒体は、その上に格納された１つまたは複数のメディアファイルに関連付けられたメモリ最適化データを表すデータ構造を、その上に格納している。メモリ最適化データは、メディアプレイヤのオペレーションを最適化する。メディアプレイヤは、メディアファイルをレンダリングするためにコンピュータ可読媒体にアクセスする。データ構造は、１つまたは複数のメディアファイルに関連付けられたテキストおよびバイナリデータへの参照を格納する、オフセットフィールドを含むヘッダを含む。データ構造はまた、ディレクトリ番号を、メディアファイルに関連付けられたディレクトリ名と合致させる、ディレクトリテーブルも含み、ヘッダは、ディレクトリ番号によりメディアファイルを参照する。
【００１４】
別法として、本発明は様々な他の方法および装置を備えることができる。
【００１５】
他の特徴は、以下で部分的に明らかになり、部分的に示されるであろう。
【００１６】
対応する参照文字は、図面の全体にわたって対応する部分を示す。
【発明を実施するための最良の形態】
【００１７】
本発明はアクセラレータファイル、アクセラレータデータ、メモリ最適化データなどを使用して、改善されたメディアプレイヤ体験を起動時にユーザのために、コンパクトバイナリ表現における１つまたは複数のメディアファイルおよびプレイリストからメタデータ情報をキャッシュすることによって提供する。コンパクト表現を、通常のポータブルＣＤプレイヤまたはＤＶＤプレイヤなどに見られるものなど、比較的低能力の中央処理装置（ＣＰＵ）によって直接、容易に操作することができる。メモリ最適化データは、本明細書ではアクセラレータファイルとも呼ばれ、制限されたメニューシステムも提供し、これによりプレイヤが、見るものまたはプレイするものの選択に関してあるＰＣのような機能性を提供することができる。たとえば、メニューは「アルバム」、「アーティスト」、「ジャンル」選択を提供することができ、これらが適切な項目によってグループ化されたプレイリストにつながる。別法として、メニューは、ディスク上に格納された３つのセットのホリデーフォトのうち１つを示すことを提供することができる。
【００１８】
本発明は、データ構造を作成するため、かつ、作成されたデータ構造を、得られたメタデータによりポピュレートするためのオーサリングソフトウェアを含む（図２を参照）。本発明はまた、メタデータをデータ構造から検索するため、かつ、レンダリングするためのメディアファイルを識別するためのレンダリングソフトウェアも含む（図４を参照）。一実施形態では、本発明のソフトウェアは、圧縮メディアフォーマットの一部として動作可能であり（図５を参照）、これは、機能が豊富なパーソナルコンピュータのメディアプレイヤならびに低コストのメディアプレイヤ上で再生するために設計された、コンパイルされたバイナリフォーマットにおけるメタデータ、メニューおよびプレイリストを含む小型ファイルのセットを有する。たとえば、通常のローエンドポータブルＣＤプレイヤは、１００キロバイトほどの作業メモリ、わずか１メガヘルツで実行する８ビット中央処理装置、および非常に低速で最大シーク時間がほぼ５秒のＣＤドライブ機構を有する可能性がある。
【００１９】
メディア環境
このとき図面を参照すると、図１は、本発明を使用することができる例示的マルチメディア環境を例示する。システム１００は１つまたは複数のコンピュータ１０２を有し、これが、メディアコンテンツを提供する１つまたは複数のデバイスに結合される。たとえば、このデバイスはＣＤ１０４、カムコーダ１０６またはカメラ１０８を含むことができる。
【００２０】
一実施形態では、コンピュータ１０２はメディアコンテンツを、家電デバイス１１２に関連付けられたメディアプレイヤプログラムによって使用するために、コンピュータ可読媒体１１０上に格納する。家電デバイス１１２には、いずれかの適切なレンダリングフィルタまたはメディアプレイヤ、または、デジタルメディアをレンダリングして、メディア１１０上で実施されるコンテンツをユーザが体験できるように構成されるデバイスが含まれる。たとえば、適切なメディアプレイヤアプリケーションには、ＣＤメディアプレイヤおよびＤＶＤメディアプレイヤが含まれる。
【００２１】
本発明では、メディアプレイヤ、家電デバイス１１２などを、メディアプレイヤの機能に従って３つの例示的レベルに編成することができる。各メディアプレイヤは、メディアプレイヤがレンダリングすることができるメディアのタイプを識別するメディアタイプを有する。たとえば、メディアタイプ（プレイリストサマリタイプ、メニューサマリタイプなどとも呼ばれる）には、オーディオ、ビデオおよび静止画像のうち１つまたは複数が含まれる。レベル１のメディアプレイヤには、ポータブルＣＤプレイヤ、カーレシーバおよびＤＶＤプレイヤなど、オーディオ専用プレイヤが含まれる。レベル１のメディアプレイヤに加えて、レベル２のメディアプレイヤには、オプショナルで画像をオーディオと共に同時にレンダリングすることができるポータブルおよびセットトップＤＶＤプレイヤを含む、オーディオおよび静止画像可能プレイヤが含まれる。レベル３のメディアプレイヤには、レベル２のメディアプレイヤおよびオーディオ、静止画像およびビデオ可能プレイヤが含まれる。例示的家電デバイス１１２には、それだけに限定されないが、ポータブルＣＤプレイヤ、ＭＰ３プレイヤ、自動車内のオーディオシステム、携帯情報端末、携帯電話などが含まれる。
【００２２】
本発明のソフトウェアおよびデータ構造は、それだけに限定されないが、メディアプレイヤおよびメディアオーサリングシステムを含むシステムにおいて動作可能である。本発明による例示的家電デバイス１１２またはメディアプレイヤは、１つまたは複数のコンピュータ可読媒体を有し、これはメディアプレイヤのオペレーションを最適化するためのコンピュータ実行可能コンポーネントを格納する。メディアプレイヤはコンピュータ可読媒体にアクセスして、メディア上に格納されたメディアファイルをレンダリングする。コンピュータ可読媒体はさらに、メディアファイルに関連付けられたデータを最適化するメモリを格納する。メディアプレイヤのコンポーネントには、入力モジュール１１４およびフィルタモジュール１１６が含まれる。入力モジュール１１４は、メディアファイルをレンダリングする前に、コンピュータ可読媒体上に格納されたメモリ最適化データを検索する。メモリ最適化データは、コンピュータ可読媒体上に格納された１つまたは複数の選択されたメディアファイルに関連付けられる。フィルタモジュール１１６は、選択されたメディアファイルを、入力モジュール１１４からの検索されたメモリ最適化データに応答して識別する。選択されたメディアファイルは、メディアプレイヤによってレンダリングされるように適合される。メモリ最適化データがテキストおよびバイナリデータを含む一実施形態では、メディアプレイヤはユーザインターフェイスモジュール１１８を含み、これは、選択されたメディアファイルのレンダリング中に、メモリ最適化データがそれに関連付けられる、選択されたメディアファイルと関連して、少なくとも一部のテキストデータを表示するためのものである。メモリ最適化データがメディア上に存在しないとき、メディアプレイヤは、メディア上に存在する実際のメディアファイルの順次再生を提供する。
【００２３】
プレイリスト
プレイリストは、コンピュータ可読媒体上のオーディオ、ビデオおよびイメージファイルのグループを編成するための好都合な方法である。プレイリストは、それだけに限定されないが、メディアファイル、オーディオファイルのグループ、ビデオファイルのグループ、タイムドイメージシーケンスのグループ、および、オーディオまたはオプショナルでビデオを有する画像の様々な複雑な並列組合せのグループのうち１つまたは複数を含むことができる。たとえば、ユーザは、異なるパフォーマまたは異なる種類の音楽またはビデオについてのプレイリストを作成することができる。ユーザはまた、作成されたプレイリストを、プレイリストのコンテンツをシャッフルまたは繰り返すことによって操作することもできる。プレイリストはメニューにおいて存在することができ、これによりユーザが容易に、メディア上に存在するメディアファイルのリストをナビゲートおよび閲覧することができ、レンダリングするプレイリストを選択することができる。
【００２４】
オーサリングソフトウェア
次に図２を参照すると、本発明のオーサリングソフトウェアは、データ構造を作成およびポピュレートして、メディアプレイヤのオペレーションを最適化する。２０２から進んで、入力メディア上の各入力メディアファイルについて、２０４でオーサリングソフトウェアが、入力メディアファイルがオーディオデータ、ビデオデータ、イメージデータまたはプレイリストを含むかどうかを判断する。入力メディアファイルがこのようなデータを含む場合、２０６でメタデータが入力メディアファイルから、グループの定義で使用するために得られる。メタデータは、それだけに限定されないが、プレイリスト、サムネイル画像、メニュー構造または言語選択を含む。２０２で判断されたように、入力メディア上にそれ以上のファイルがない場合、２０８で、オーサリングソフトウェアがメタデータを、１つまたは複数の選択されたメディアファイルについて得る。メタデータは、メディアファイルなどのソースから、あるいはインターネットなどのネットワークを介してサーバから得られる。２１０でオーサリングソフトウェアが、メディアファイルをレンダリングする前にメディアプレイヤによってアクセスするように適合されたデータ構造を作成し、２１２で、作成されたデータ構造を、得られたメタデータによりポピュレートする。加えて、２１４でオーサリングソフトウェアが、ポピュレートされたデータ構造をコンピュータ可読媒体上に格納する。一実施形態では、１つまたは複数のコンピュータ可読媒体は、図２に例示する方法を実行するためのコンピュータ実行可能命令を有する。
【００２５】
図３に例示するマルチセッションコンピュータ可読媒体を有する一実施形態では、オーサリングソフトウェアが、ポピュレートされたデータ構造をメディア上の最後のセッションとして格納する。図３では、メディアファイル３０２および加速データ３０４がメディア上に、４つのセッション（セッション１、２、３、４）により格納される。本発明のレンダリングソフトウェアは、セッション４（すなわち、メディア上の最後のセッション）に格納されたアクセラレータデータ３０４にアクセスする。
【００２６】
メモリ最適化データがメディア（図示せず）上の最後のセッション内にない場合、レンダリングソフトウェアは、レンダリング中にメディア上のすべてのセッション内のメモリ最適化データを無視する。これにより、メモリ最適化データおよびメディアファイルがコヒーレントであることが保証される。
【００２７】
オーサリングソフトウェアは、メモリを最適化するための追加の機能を実行する。オーサリングソフトウェアは数値識別子を、選択されたメディアファイルに関連付け、ここにおいて数値識別子は順番に順序付けされる。数値識別子の各々が、メディアファイルの各々に対応する。オーサリングソフトウェアは、メディアファイルに関連付けられたファイル名の代わりにデータ構造における数値識別子を参照して、メモリ使用を低減する。加えて、オーサリングソフトウェアはメディアファイルをディレクトリにより編成し、編成されたメディアファイルを、メディア上のファイルシステムによって使用されたものと同じアルゴリズムを使用して（ファイル名により）ソートして、メディアファイルの探索を容易にする。類似の方法で、オーサリングソフトウェアは数値識別子を、メディアファイルの１つへの各パスにおける各ディレクトリ名について決定する。オーサリングソフトウェアはディレクトリ名を、決定された数値識別子で置き換える。一実施形態では、オーサリングソフトウェアはメディアファイルを、サポートされたフォーマット、および、圧縮器および圧縮解除器（コーデック）に圧縮または変換し、これはすでにサポートされたファイルフォーマットおよびコーデックでない場合に行う。圧縮メディアファイルもまたコンピュータ可読媒体上に格納される。
【００２８】
オーサリングソフトウェアは、いずれかの共通プレイリストフォーマットにおける各ユーザ供給プレイリストを読み取り、このフォーマットには、それだけに限定されないが、Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐレイヤ３（ＭＰ３）、Ａｄｖａｎｃｅｄ  Ｓｔｒｅａｍｉｎｇ  Ｆｏｒｍａｔ（ＡＳＦまたはＡＳＸ）、またはＷＩＮＤＯＷＳ（登録商標）ブランドのオペレーティングシステムのプレイリスト（ＷＰＬ）フォーマットが含まれる。各プレイリストが数値フォーマットに、上述のように割り当てられた数値識別子を使用して変換され、再生中のメモリ使用がさらに最適化される。数値プレイリストもまたコンピュータ可読媒体上に格納される。
【００２９】
オーサリングソフトウェアはオプショナルで、各メニュー、プレイリストまたはメディアファイルについてのサムネイルを作成する。大きい画像が小さいサムネイルとしてメニュー表示用にレンダリングされ、メディア上のメディアファイルのナビゲーションおよび再生中のメモリおよび中央処理装置（ＣＰＵ）使用がさらに最適化される。サムネイルもまたコンピュータ可読媒体上に格納され、言語選択を再生時間に行うことができるようになる。
【００３０】
メディアオーサリングツールの実施形態では、１つまたは複数のコンピュータ可読媒体が、メディアプレイヤのオペレーションを最適化するためのコンピュータ実行可能コンポーネントを有する。このコンポーネントには、準備モジュール、初期化モジュール、編成モジュールおよびライタモジュールが含まれる。準備モジュールは、１つまたは複数の選択されたメディアファイルについてのメタデータを得る。初期化モジュールは、メディアファイルをレンダリングする前にメディアプレイヤによってアクセスするように適合されたデータ構造を作成する。編成モジュールは、初期化モジュールからの作成されたデータ構造を、準備モジュールからの得られたメタデータによりポピュレートする。ライタモジュールは、編成モジュールからのポピュレートされたデータ構造をコンピュータ可読媒体上に格納する。
【００３１】
一実施形態では、メタデータキャッシュのメモリおよびディスク読み取りの最適化が、テキストおよびバイナリメタデータを異なるキャッシュファイルに分離することによって実施される。この分離は結果として最適化となり、これはテキストメタデータが大きく、特定のプレイリストまたはメディアファイルの再生が開始するまで必要とされないからである。バイナリメタデータのすべてが単一のファイル（たとえば「ＣＯＮＴＥＮＴＳ．ＨＭＴ」）に含まれるが、テキストメタデータは別のファイル（たとえば「ＴＥＸＴ．ＨＭＴ」）に格納される。もう１つの最適化は、バイナリメタデータキャッシュの実際のレイアウトである。ＣＯＮＴＥＮＴＳ．ＨＭＴにおける情報がいくつかのセクションに編成される（付録Ａの図９を参照）。一般に、テキストおよびバイナリメタデータはアクセラレータデータ、メモリ最適化データなどと呼ばれる。
【００３２】
オーサリングソフトウェアまたはディスク作成ソフトウェアは、追加のデータをディスク上に格納することができ、これは、メニューに何を入れるかについてのいずれかの以前のユーザの決定を保持し、後にさらにデータがディスク追加されるときに再提示することができるようにするためである。たとえば、ユーザが、写真を「月毎に」表示するためのメニューオプションがないべきであることを決定した場合、その選択をディスク上で持続させることができる。このような持続性ファイルを、アプリケーションに特化したものにすることができる。
【００３３】
アクセラレータファイルは２つのカテゴリに分割され、すなわち、大抵は全体的または部分的にメモリ内で常に保持されるであろうファイル、および、必要とされるときにのみロードされるファイル（たとえば、メニューおよびプレイリスト）である。アクセラレータファイル内の情報は、オーディオデータ、イメージデータおよびビデオデータの順序で編成されて、許可された再生デバイスの３つのレベルに合致するようにされる。一実施形態では、オーディオ専用プレイヤは、それがプレイすることができないファイルについてのものであるキャッシュファイルの一部においてロードしなくてもよくなる。
【００３４】
アクセラレータファイル内の情報もまた２つのカテゴリに分割され、すなわち、大抵は全体的または部分的にメモリ内で常に保持されるであろう情報、および、起動中にのみ必要とされ、再生中にメモリから廃棄することができる情報である。たとえば、ＣＯＮＴＥＮＴＳ．ＨＭＴファイルでは、情報がファイル名と共に各ファイルテーブル（たとえば、以下で説明するオーディオ、メニュー画像、画像およびビデオ）の最後に編成され、これは、ファイル名をファイルシステムと合致させるプロセスが完了された後（プレイヤがそれを起動時に行うように選択すると仮定する）、これらをメモリから廃棄することができるからである。アクセラレータファイルをさらにメモリにおいてプレイヤによってコンパクト化することができ、これは、メディアファイルを互換性についてチェックするためにのみ使用される項目を廃棄することによって行う。たとえば、各オーディオファイルのビットレートおよびサンプルサイズがプレイヤによってチェックされた後、これらはもはやメモリで必要とされない。
【００３５】
各メディアファイルを一意の番号としてディスク上のすべての他の構造（メニューおよびプレイリスト）内で表すことによって、再生中のメモリ使用がさらに最小限にされる。キャッシュファイルの作成において、オーサリングソフトウェアは変換をより効率的にし、これはキャッシュ内のファイルを最初に、それらを含むディレクトリにより、次いでアルファベット順に、あるいはメディア上のファイルシステムによって使用されたものと同じアルゴリズムを使用して（ファイル名により）、ソートすることによって行う。これは、ＩＳＯ  ９６６０  Ｊｏｌｉｅｔメディア上のファイルシステムレコードと同じ順序であり、そのためプレイヤは、Ｏ（ｎ  ｌｏｇ  ｎ）またはより悪いアルゴリズムではなく、単純なＯ（ｎ）探索アルゴリズムを行うことができる。
【００３６】
キャッシュファイルの先頭はディレクトリテーブルであり、そこで各ディレクトリについてのテキスト名がそのディレクトリ番号のための数値識別子に変換される。ディレクトリへのすべての参照はこのテーブルを介して行われ、したがってすべてのパス名がコンパクト数値表現までコンパクト化される。各ディレクトリが多数のファイルを含んでいるので、この構造はまた、ファイルおよびディレクトリ命名構造全体を表すための極めてコンパクトな方法も表す。
【００３７】
たとえば、ファイル１を「＼ＤｉｒＡ＼ＤｉｒＢ＼ＤｉｒＣ＼ファイル１」として格納することができ、ファイル２を「＼ＤｉｒＡ＼ＤｉｒＢ＼ＤｉｒＤ＼ファイル２」として格納することができる。これらのディレクトリパスをコンパクト化するために、以下の表は各ディレクトリコンポーネントを数値識別子で置き換える。
【００３８】
【表１】
2004164824.tif 000003
【００３９】
次いで、ファイル１へのディレクトリパスを単に「４」として識別することができ、これをトレースバックしてディレクトリ１−２−３−４を通じたフルパスを生成することができ、ファイル２へのディレクトリパスを単に「５」として識別することができ、これを１−２−３−５へトレースバックすることができ、結果としてメモリが節約される。
【００４０】
本発明では様々な手段を使用して、メディア上のメタデータキャッシュとメディアコンテンツの間のコヒーレンシーを保証する。たとえば、本発明のソフトウェアは、メディア上の最後のセッション内にないメタデータキャッシュファイルを無視し、ファイルの２つを共に結合する一意のランダム識別子を検証する。
【００４１】
メディアファイルについての論理セクタ番号
ＣＯＮＴＥＮＴＳ．ＨＭＴで解決されるもう１つの問題は、家電デバイスがメディア上の特定のファイルを再生のために位置付けることを容易にする方法である。パーソナルコンピュータ（ＰＣ）上で、ソフトウェアは単に、メモリ内にキャッシュされたファイルシステムにおけるファイル名をルックアップする。家電デバイスは、ファイルシステム全体を保持するために十分なランダムアクセスメモリを有していない可能性がある。したがって、メディア上のファイルを位置付けるためにファイルシステムのいくつかのブロックのシーク／読み取りがひどく遅い。家電デバイスがファイルを発見するための最も効率的な方法は、ファイルの論理セクタ番号（ＬＳＮ）をメタデータと共に格納することである。メディア上の各ファイルについてのＬＳＮおよびファイル長を格納するオプショナルのアクセラレータファイルにより、再生の高速な起動、および、メディアプレイヤのためのより低いメモリ要件が可能となる。しかし、ＬＳＮアクセラレータファイルはオプショナルであり、これはオーサリングソフトウェアのすべての実施が、ファイルを書き込む前に各ファイルのＬＳＮおよび長さを決定することができる可能性があるとは限らないからである。たとえば、ＬＳＮをキャッシュにオーサリングすることは、厳密に階層化されたアーキテクチャを有し、それによりファイルシステムがメディアのレイアウトから分離されるＰＣでは、必ずしも可能とは限らない。加えて、ファイルが異なるメディア上に更新、移動またはコピーされる場合、これらのオフセットが無効にされる。
【００４２】
メディアを単一のパスで書くか、あるいは、ファイルシステムの下のオペレーティングシステムのレベルで動作するオーサリングソフトウェアでは、本発明により、特殊なＬＳＮキャッシュファイルをメディア上に配置させることができる。メディア上の各ファイルについてのＬＳＮおよびファイル長を格納する、オプショナルのＬＳＮキャッシュファイル（たとえば、アクセラレータファイル）により、再生の高速な起動が可能となる。ＬＳＮファイルは、メディア上のアクセラレータファイルによって参照される各ファイルについての論理セクタ番号を含む。オーサリングソフトウェアは、ファイルを書き込む前に各ファイルのＬＳＮおよびファイル長を決定することができる。このファイルがメディア上の最後のセッション内に存在するとき、それがＣＯＮＴＥＮＴＳファイルに合致するとすれば（複数のファイルの間で合致された一意のランダムな世代番号によって検証される）、メディアプレイヤはこのファイルを使用して、メディア上に存在するあらゆるメディアファイルを位置付けることができ、プレイヤはファイルシステムを読み取りまたは解析してメディアファイルを位置付ける必要がない。
【００４３】
プレイヤは通常、アクセラレータファイル内のファイル名をＬＳＮへ、起動中に解決し、ファイルシステム全体を読み取ってテーブルをメモリ内で作成し、ファイル番号を各ファイルの開始ＬＳＮおよびバイト長についての値にマッピングする。一実施形態では、ＬＳＮキャッシュファイルが、他のアクセラレータファイルが作成された後に実行する別のメーカ提供ソフトウェアを使用して作成される。すべてのプレイヤは、この追加の加速ファイルが存在するかどうかにかかわらず、メディアをプレイする。十分に高速なドライブ機構を有するプレイヤはこの起動手順を回避して、単にディスク再生中にファイル毎のベースでファイル名を解決することができる。
【００４４】
このようなファイルの周囲にはいくつかの問題があり、これには、このようなメディアのファイルコピーが結果としてプレイ不可能なメディアとなる可能性が高いという事実が含まれる。このようなファイルを実施するように選択するプレイヤは、ファイル内のデータを利用する前にその妥当性をチェックするべきである。いずれかのＬＳＮが、メディア上にあるように現れないファイルをポイントした場合、ＬＳＮファイル全体を廃棄するべきであり、プレイヤはファイルシステムの読み取りに戻って、ファイルについてのＬＳＮおよびバイト長をルックアップするべきである。本発明のソフトウェアによるＬＳＮファイルの例示的実施態様については、付録Ａを参照されたい。
【００４５】
レンダリングソフトウェア
次に図４を参照すると、レンダリングソフトウェアはメディアプレイヤのオペレーションを最適化する。４０２でファイルシステムをロードした後、４０４でレンダリングソフトウェアが、入力メディアが有効なメディア（たとえば、アクセラレータデータを含むメディア）であるかどうかを判断する。４０６でレンダリングソフトウェアが、メディアファイルをレンダリングする前に、コンピュータ可読媒体上に格納されたメモリ最適化データを検索する。メモリ最適化データは、コンピュータ可読媒体上に格納された１つまたは複数の選択されたメディアファイルに関連付けられる。４０８でレンダリングソフトウェアが、選択されたメディアファイルを、検索されたメモリ最適化データに応答して識別する。選択されたメディアファイルは、メディアプレイヤによってレンダリングされるように適合される。選択されたメディアファイルを、コンピュータ可読媒体上で使用可能な複数のメディアファイルのサブセットにすることができる。メモリ最適化データがテキストおよびバイナリデータを含む一実施形態では、レンダリングソフトウェアが少なくとも一部のテキストデータをメディアプレイヤによって、選択されたメディアファイルのレンダリング中に、メモリ最適化データがそれに関連付けられる、選択されたメディアファイルと関連して、表示する。レンダリングソフトウェアは、選択されたメディアファイルに関連付けられたメタデータを、メモリ最適化データを介して得て、得られたメタデータをユーザへ、メディアプレイヤに関連付けられたディスプレイ上で表示する。一実施形態では、１つまたは複数のコンピュータ可読媒体は、図４に例示した方法を実行するためのコンピュータ可読命令を有する。
【００４６】
プレイヤは通常、起動中にアクセラレータファイル内のファイル名をＬＳＮに解決し、ファイルシステム全体を読み取ってテーブルをメモリ内で作成し、ファイル番号を各ファイルの開始ＬＳＮおよびバイト長についての値にマッピングする。十分に高速なドライブ機構を有するプレイヤはこの起動手順を回避して、単にディスク再生中にファイル毎のベースでファイル名を解決することができる。
【００４７】
４１０で、有効なＬＳＮファイルがメモリ最適化データにおいて存在した場合、レンダリングソフトウェアがＬＳＮファイルをロードし、４１４に進行して、選択されたメディアファイルをレンダリングする。４１０で、特殊なＬＳＮキャッシュファイルが存在しないか、あるいは有効でないとき、４１６で、プレイヤがファイルシステムを読み取って、ＣＯＮＴＥＮＴＳファイル内のファイル名をＬＳＮに変換しなければならない。
【００４８】
本発明では、ＣＯＮＴＥＮＴＳファイル内の各ファイルテーブルが、オフセットを有するバイナリメタデータのリストとして、バイナリメタデータの後に続くテキストファイル名のリストに編成される。これにより、プレイヤがバイナリメタデータのみをメモリに最初にロードすることができ、次いでファイル名を増分的に読み、各ブロックが処理されるときにこれを廃棄することができる。ファイルシステムを類似の方法でメモリ内に保持し、ＣＯＮＴＥＮＴＳファイル内のファイル名に対して増分的に合致させることができ、あるいはファイルシステムを増分的に読み取って、ＣＯＮＴＥＮＴＳファイルのメモリ内コピーに対して処理することができる。非常に小さいメモリを有するプレイヤはＣＯＮＴＥＮＴＳファイルおよびファイルシステムを増分的に読むこともできるが、かなり低速である可能性がある。
【００４９】
ファイルシステムがＣＯＮＴＥＮＴＳファイル内のファイル名と合致させられるとき、ファイル名への各４バイトオフセットをＬＳＮで置き換えることができ、次いでファイル名をメモリから廃棄することができる。したがって、本発明はメモリを効率的に再利用し、メモリからメモリへのコピーオペレーションの数を最小限にし、そうでない場合は、ファイル名合致プロセスが完了された後にメモリ内のデータ構造をコンパクト化することが必要とされる可能性がある。プレイヤが起動プロセスのこの段階を完了した後、４１６で、ファイル名テーブルおよびファイルシステム全体をメモリから廃棄することができ、プレイヤに残されるものは、例示的実施形態では、オーディオファイルにつき３２バイト、画像ファイルにつき１６バイト、およびビデオファイルにつき４４バイトである。レンダリングソフトウェアが４１４に進んで、選択されたメディアファイルをレンダリングする。最終的に、起動段階が完了した後、単一の番号を使用していかなるメディアファイルをも参照することができ、プレイヤは容易に、非常にコンパクトなメモリ内構造から、そのファイルについてのバイナリおよびテキストメタデータ、およびそのファイルについてのＬＳＮにアクセスすることができる。ファイル長またはサイズは、メモリテーブル内の別のフィールドに格納される。
【００５０】
４０４で、入力メディアがメモリ最適化データを含んでいなかった場合、４２０でレンダリングソフトウェアが入力メディアをファイルについてスキャンし、４１４でメディア上のいずれかのファイルをレンダリングする。
【００５１】
メタデータおよびメニュー表示
本発明によるレンダリングソフトウェアを有するメディアプレイヤは、再生中にメタデータ情報を表示する。本発明のレンダリングソフトウェアは、メタデータを表示のために得るための少なくとも２つの方法を有し、すなわち（ｉ）アクセラレータファイルから、および（ｉｉ）メディア上の実際のメディアファイルからである。一般に、実際のメディアファイルは、アクセラレータファイルに含まれたメタデータの最小セットよりも幅広い種類のメタデータを含むようになる。いくつかのメディアプレイヤは、この追加のメタデータを露出するように選択することができ、たとえば、音楽ファイルについての歌詞、アルバム、年またはジャンル、または静止画像について「取られたデータ」を示す。メディアプレイヤはメタデータ内のすべてのアルファベット、数字、スペースおよびハイフンを表示するが、表示することができない他の文字を変換または省略することができる。たとえば、いくつかの文字表示は完全文字セットを表示できない可能性がある。
【００５２】
一実施形態では、英数字表示を有するメディアプレイヤはユーザに、再生中に少なくとも音楽ファイルについてのアーティストおよびタイトルを表示する可能性を提供するべきである。アーティストタグまたはタイトルタグのない音楽ファイルは、それらがそのフィールドについて空タグを有するかのように処理される。一実施形態では、メディアプレイヤはメタデータを切り捨てるのではなく、メタデータをスクロールする。しかし、メディアプレイヤは、メモリ要件が決定するように、メタデータを少なくとも３３文字に切り捨てることができる。
【００５３】
本発明のソフトウェアによる加速再生メディア上のメニューは、サブメニューおよびプレイリストの単一の階層構造を含む。メニューツリーは、たとえばオプショナルの全体制限の合計ノード９，９９９以内で任意の深さ、任意の幅にすることができる。他の実施形態は、メニューツリーに関する他の、あるいは異なる制限を実施することができる。大抵のメディアプレイヤは、メディアが挿入されるとき、トップレベルメニューを表示する。しかし、カーレシーバは起動時にメニューをバイパスすることを選択して、メディア上の最初のプレイリストにより直ちに再生を開始することができ、あるいは先にプレイ中であったソングおよびプレイリストで再生を再開することができる。一実施形態では、メニューがフィルタリングされて、プレイヤが表示またはプレイすることができるメニュー項目のみが表示される（たとえば、オーディオ専用プレイヤはすべての画像およびビデオメニューエントリを除去して、純粋なオーディオ選択のみを表示する）。
【００５４】
本発明のレンダリングソフトウェアを様々な特徴と共に実施することができる。たとえば、各メニューは最大９，９９９エントリまで含むことができ、いくつかのメディアプレイヤはメニューのスクローリングまたはページ分けされたビューを表示することができる。ＴＶに接続されたプレイヤは、サムネイルメニューまたは単純なリストメニューを表示することができる（たとえば、現在のメニュー内のプレイリストまたはメニューなどのエントリがサムネイルを有するかどうかに基づく）。一実施形態では、ＴＶに接続されたプレイヤは、サムネイルが現在のメニュー内のあらゆるエントリについて存在する（すなわち、ゼロでないエントリ）ときにのみ、サムネイルメニューを表示する。画面上のサムネイルのレイアウトおよびページ毎に表示されたサムネイルの数は、プレイヤ依存である。いくつかのメディアプレイヤは連続スクローリングリストを表示するように選択することができ、他のメディアプレイヤはメニューにページ番号をつけて、次／前の選択を提供するように選択することができる。４：３のＴＶ受像機では、メディアプレイヤは３×２個のサムネイルのグリッドを表示する。１６：９のＴＶ受像機では、メディアプレイヤはその代わりに４×２のグリッドを表示するように選択することができる。プレイヤはメニュー項目の選択状態を指示する。これを行うことができる方法には多数の選択があり、プレイヤの機能によって決まる。豊富なユーザ体験に備えるために、メニューおよびプレイリストの項目は選択状態サムネイルを有する。サムネイルを表示することができるプレイヤはこのサムネイルを使用して、他の方法の代わりに選択を指示することができる。プレイヤはまたプレイリストまたはメニュー名も、関連付けられたサムネイルと共に表示する。プレイヤがすべてのサムネイルを即座に表示できない場合、テキストラベルが最初に表示され、サムネイルが１つずつ、復号化されるときに追加される。プレイヤは、ユーザが迅速に所与の項目にナビゲートできるようにするために、サムネイルの追加中でも次または前のページへのスクローリングを可能にすることができる。
【００５５】
本発明のメニュー表示はプレイヤ依存であり、各メーカがメニューを表示する方法を決定することができる。ポータブルＣＤプレイヤでは、たとえば、メニューを一度に一行表示することができ、次、前、プレイ／選択および停止ボタンを使用して、選択範囲中でナビゲートする。カーレシーバでは、再生がメディア上の最初のプレイリストで即時に開始することができる。次いで、ユーザは「メニュー」キーを押してメディアメニューを提示させ、次、前およびプレイ／選択を使用してこの中でナビゲートすることが必要となる。ＤＶＤプレイヤでは、オプショナルのサムネイルと共に、フルグラフィカル表示を完全に表示することができる。いくつかのＤＶＤプレイヤはメニュー項目に付番し、１〜９のキーをリモートコントロール上で使用するように選択することができるが、いくつかのＤＶＤプレイヤは単にメニュー項目をリストまたはグリッドフォーマットにおいて提示し、カーソルキーをナビゲーションおよび選択のために使用することができる。
【００５６】
例示的メディアコンテンツ環境
図５に例示するように、本発明は、例示的圧縮メディアフォーマット５０２の一部として動作可能であり、これは、機能が豊富なＰＣメディアプレイヤならびに低コストのメディアプレイヤ上で再生するために設計された、コンパイルされたバイナリフォーマットにおけるメタデータ、メニューおよびプレイリストを含む小型ファイルのセット５０４を有する。本発明の例示的圧縮メディアフォーマットは、様々なフォーマットにおけるオーディオ、静止画像およびビデオメディアファイル５０４を包含する。本発明と共に使用するための圧縮メディアフォーマットは、コンピュータ可読媒体５０８上のファイルシステム５０６における圧縮メディアファイルを編成するための論理フォーマットを定義し、コンピュータ可読媒体５０８は、光ディスク（たとえば、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＡＭ、ＤＶＤ−Ｒ、ＤＶＤ−ＲＷ、ＤＶＤ＋ＲＷ、ＤＶＤ＋Ｒ、ＤＶＤ−ＲＯＭ）、フラッシュメモリ（たとえば、ＣＯＭＰＡＣＴＦＬＡＳＨ（登録商標）ブランド、セキュアデジタル、ＭＥＭＯＲＹ  ＳＴＩＣＫブランド）、磁気メディア（たとえば、ハードディスク）などである。
【００５７】
図６は、コンピュータ１３０の形式における汎用コンピューティングデバイスの一実施例を示す。本発明の一実施形態では、コンピュータ１３０などのコンピュータは、本明細書で例示し、説明した他の図面で使用するために適切である。コンピュータ１３０は、１つまたは複数のプロセッサまたは処理装置１３２およびシステムメモリ１３４を有する。例示した実施形態では、システムバス１３６は、システムメモリ１３４を含む様々なシステムコンポーネントをプロセッサ１３２に結合する。バス１３６は、いくつかのタイプのバス構造のいずれかの１つまたは複数を表し、これには、様々なバスアーキテクチャのいずれかを使用するメモリバスまたはメモリコントローラ、周辺バス、アクセラレーテッドグラフィックスポート、およびプロセッサまたはローカルバスが含まれる。例として、限定ではなく、このようなアーキテクチャには、業界標準アーキテクチャ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカルバス、およびメザニンバスとしても知られる周辺装置相互接続（ＰＣＩ）バスが含まれる。
【００５８】
コンピュータ１３０は通常、少なくともいくつかの形式のコンピュータ可読媒体を有する。コンピュータ可読媒体は、揮発性および不揮発性メディア、リムーバブルおよび非リムーバブルメディアを含み、これをコンピュータ１３０によってアクセスすることができるいかなる使用可能なメディアにすることもできる。例として、限定ではなく、コンピュータ可読媒体は、コンピュータ記憶メディアおよび通信メディアを含む。コンピュータ記憶メディアは、揮発性および不揮発性、リムーバブルおよび非リムーバブルのメディアを含み、これらはコンピュータ可読命令、データ構造、プログラムモジュールまたは他のデータなど、情報の格納のためのいずれかの方法または技術において実施される。たとえば、コンピュータ記憶メディアには、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光ディスク記憶、磁気カセット、磁気テープ、磁気ディスク記憶または他の磁気記憶デバイス、または、所望の情報を格納するために使用することができ、コンピュータ１３０によってアクセスすることができる他のいずれかのメディアが含まれる。通信メディアは通常、コンピュータ可読命令、データ構造、プログラムモジュール、または、搬送波または他の移送機構などの変調データ信号における他のデータを実施し、いずれかの情報配信メディアを含む。当業者は変調データ信号をよく知っており、これは、信号における情報を符号化するような方法でその特性の１つまたは複数が設定または変更されている信号である。ワイヤードネットワークまたはダイレクトワイヤード接続などのワイヤードメディア、および、音響、ＲＦ、赤外線および他のワイヤレスメディアなどのワイヤレスメディアが、通信メディアの例である。上記のいずれの組合せも、コンピュータ可読媒体の範囲内に含まれる。
【００５９】
システムメモリ１３４は、リムーバブルおよび／または非リムーバブル、揮発性および／または不揮発性メモリの形式におけるコンピュータ可読媒体を含む。例示した実施形態では、システムメモリ１３４は読み取り専用メモリ（ＲＯＭ）１３８およびランダムアクセスメモリ（ＲＡＭ）１４０を含む。基本入出力システム１４２（ＢＩＯＳ）は、起動中などにコンピュータ１３０内の複数の要素の間で情報を転送する助けとなる基本ルーチンを含み、通常はＲＯＭ１３８に格納される。ＲＡＭ１４０は通常、処理装置１３２によって即時アクセス可能および／または現在動作中であるデータおよび／またはプログラムモジュールを含む。例として、限定ではなく、図６は、オペレーティングシステム１４４、アプリケーションプログラム１４６、他のプログラムモジュール１４８およびプログラムデータ１５０を例示する。
【００６０】
コンピュータ１３０はまた、他のリムーバブル／非リムーバブル、揮発性／不揮発性のコンピュータ記憶メディアも含むことができる。たとえば図６は、非リムーバブル、不揮発性の磁気メディアに対する読み書きを行うハードディスクドライブ１５４を例示する。図６はまた、リムーバブル、不揮発性磁気ディスク１５８に対する読み書きを行う磁気ディスクドライブ１５６、および、ＣＤ−ＲＯＭまたは他の光メディアなど、リムーバブル、不揮発性の光ディスク１６２に対する読み書きを行う光ディスクドライブ１６０も示す。例示的オペレーティング環境で使用することができる他のリムーバブル／非リムーバブル、揮発性／不揮発性のコンピュータ記憶メディアには、それだけに限定されないが、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭなどが含まれる。ハードディスクドライブ１４４および磁気ディスクドライブ１５６および光ディスクドライブ１６０は通常システムバス１３６に、インターフェイス１６６などの不揮発性メモリインターフェイスによって接続される。
【００６１】
上述し、図６に例示したドライブまたは他の大容量記憶デバイス、およびそれらの関連付するコンピュータ記憶メディアは、コンピュータ１３０用のコンピュータ可読命令、データ構造、プログラムモジュールおよび他のデータの記憶装置を提供する。図６では、たとえば、ハードディスクドライブ１５４が、オペレーティングシステム１７０、アプリケーションプログラム１７２、他のプログラムモジュール１７４およびプログラムデータ１７６を格納するものとして例示される。これらのコンポーネントを、オペレーティングシステム１４４、アプリケーションプログラム１４６、他のプログラムモジュール１４８およびプログラムデータ１５０と同じものにも異なるものにもすることができることに留意されたい。オペレーティングシステム１７０、アプリケーションプログラム１７２、他のプログラムモジュール１７４およびプログラムデータ１７６にはここで異なる番号が与えられて、最低でも、それらが異なるコピーであることが例示される。
【００６２】
ユーザはコマンドおよび情報をコンピュータ１３０へ、キーボード１８０およびポインティングデバイス１８２（たとえば、マウス、トラックボール、ペンまたはタッチパッド）などの入力デバイスまたはユーザインターフェイス選択デバイスを通じて入力することができる。他の入力デバイス（図示せず）には、マイクロフォン、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナなどが含まれる可能性がある。これらおよび他の入力デバイスは処理装置１３２へ、システムバス１３６に結合されるユーザ入力インターフェイス１８４を通じて接続されるが、これを、パラレルポート、ゲームポートまたはユニバーサルシリアルバス（ＵＳＢ）など、他のインターフェイスおよびバス構造によって接続することができる。モニタ１８８または他のタイプの表示デバイスもシステムバス１３６へ、ビデオインターフェイス１９０などのインターフェイスを介して接続される。モニタ１８８に加えて、コンピュータはしばしば、プリンタおよびスピーカなど、出力周辺インターフェイス（図示せず）を通じて接続することができる他の周辺出力デバイス（図示せず）を含む。
【００６３】
コンピュータ１３０はネットワーク環境において、リモートコンピュータ１９４など、１つまたは複数のリモートコンピュータへの論理接続を使用して動作することができる。リモートコンピュータ１９４は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイスまたは他の共通ネットワークノードにすることができ、通常は、コンピュータ１３０に関連して上述した要素の多数またはすべてを含む。図６に示す論理接続は、ローカルエリアネットワーク（ＬＡＮ）１９６および広域ネットワーク（ＷＡＮ）１９８を含むが、他のネットワークも含むことができる。このようなネットワーキング環境は、オフィス、企業全体のコンピュータネットワーク、イントラネットおよびグローバルコンピュータネットワーク（たとえば、インターネット）において一般的である。
【００６４】
ローカルエリアネットワーキング環境において使用するとき、コンピュータ１３０がＬＡＮ１９６へ、ネットワークインターフェイスまたはアダプタ１８６を通じて接続される。広域ネットワーキング環境において使用するとき、コンピュータ１３０は通常、モデム１７８、またはインターネットなどのＷＡＮ１９８を介して通信を確立するための他の手段を含む。モデム１７８を内部または外部にすることができ、これはシステムバス１３６へ、ユーザ入力インターフェイス１９４または他の適切な機構を介して接続される。ネットワーク環境では、コンピュータ１３０に関して示したプログラムモジュールまたはその一部を、リモートメモリデバイス（図示せず）に格納することができる。例として、限定ではなく、図６はリモートアプリケーションプログラム１９２を、メモリデバイス上に存在するものとして例示する。図示のネットワーク接続は例示的であり、通信リンクを複数のコンピュータの間で確立する他の手段を使用できることは理解されよう。
【００６５】
一般に、コンピュータ１３０のデータプロセッサは、異なる時間にコンピュータの様々なコンピュータ可読記憶メディアに格納された命令を用いてプログラムされる。プログラムおよびオペレーティングシステムは通常、たとえばフロッピー（登録商標）ディスクまたはＣＤ−ＲＯＭにおいて配布される。そこから、これらがコンピュータの２次メモリにインストールまたはロードされる。実行時に、これらが少なくとも部分的にはコンピュータの１次電子メモリにロードされる。本明細書で説明した本発明は、これらおよび他の様々なタイプのコンピュータ可読記憶メディアが、以下で説明するステップをマイクロプロセッサまたは他のデータプロセッサと共に実施するための命令またはプログラムを含むとき、これらを含む。本発明はまた、コンピュータ自体が本明細書で説明した方法および技術に従ってプログラムされるとき、これも含む。
【００６６】
例示のため、オペレーティングシステムなど、プログラムおよび他の実行可能プログラムコンポーネントを本明細書で離散的ブロックとして例示する。しかし、このようなプログラムおよびコンポーネントが様々な時間にコンピュータの異なる記憶コンポーネント内に存在し、コンピュータのデータプロセッサによって実行されることを理解されたい。
【００６７】
コンピュータ１３０を含む例示的コンピューティングシステム環境に関連して説明したが、本発明は多数の他の汎用または専用コンピューティングシステム環境または構成により動作可能である。このコンピューティングシステム環境は、本発明の使用または機能性の範囲についていかなる限定も示唆するように意図されない。さらに、このコンピューティングシステム環境は、例示的オペレーティング環境において例示したコンポーネントのいずれか１つまたは組合せに関係するいかなる依存性または要件をも有するものとして解釈されるべきではない。本発明と共に使用するために適切である可能性のある周知のコンピューティングシステム、環境および／または構成の例には、それだけに限定されないが、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラマブルなコンシューマエレクトロニクス、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上のシステムまたはデバイスのいずれかを含む分散コンピューティング環境などが含まれる。
【００６８】
本発明を一般に、プログラムモジュールなど、１つまたは複数のコンピュータまたは他のデバイスによって実行されるコンピュータ実行可能命令に関連して説明することができる。一般に、プログラムモジュールには、それだけに限定されないが、特定のタスクを実行するか、あるいは特定の抽象データ型を実施するルーチン、プログラム、オブジェクト、コンポーネントおよびデータ構造が含まれる。本発明をまた分散コンピューティング環境において実施することもでき、ここではタスクが、通信ネットワークを通じてリンクされる複数のリモート処理デバイスによって実行される。分散コンピュータ環境では、プログラムモジュールは、メモリデバイスを含む、ローカルおよびリモートのコンピュータ記憶メディア内に位置することができる。
【００６９】
オペレーションにおいて、コンピュータ１３０は、図２に例示するものなどのコンピュータ実行可能命令を実行してデータ構造を作成し、作成されたデータ構造を、得られたメタデータによりポピュレートする。加えて、コンピュータ１３０は（メディアプレイヤの一部として）、図４に例示するものなどのコンピュータ実行可能命令を実行してメタデータをデータ構造から検索し、レンダリングするためのメディアファイルを識別する。
【実施例】
【００７０】
一実施形態では、アクセラレータファイルがメディア上で「ＨＩＧＨＭＡＴ」と呼ばれる最上位ディレクトリの下に存在し、図７に示すファイルシステムに例示する例示的ファイルを含む。アクセラレータファイルはメディア上で「ＨＩＧＨＭＡＴ」と呼ばれる最上位ディレクトリ下に存在し、以下のファイル、すなわちＣＯＮＴＥＮＴＳ．ＨＭＴ、ｎｎｎｎｎｎｎｎ．ＨＭＴ、ＭＥＮＵ．ＨＭＴおよびＴＥＸＴ．ＨＭＴを含む。ＣＯＮＴＥＮＴＳ．ＨＭＴファイルは、メディア上に存在するすべてのメディアファイルについての情報を含む。これはディレクトリテーブルとその後に続く、サポートされた各ファイルタイプ（オーディオ、ビデオ、画像およびプレイリスト）についてのファイルエントリテーブルを含む。メディア上の各プレイリストについて「ｎｎｎｎｎｎｎｎ．ＨＭＴ」と呼ばれる１つのファイルがあり、ｎｎｎｎｎｎｎｎは１６進プレイリストファイル識別子である。これらのプレイリストファイルは「ＰＬＡＹＬＩＳＴ」サブディレクトリに作成される。ＭＥＮＵ．ＨＭＴファイルはメニュー構造を含む。ＴＥＸＴ．ＨＭＴファイルは、再生中に必要とされたすべてのテキスト情報を含む。
【００７１】
代替実施形態では、以下のファイル、すなわち＜サムネイル＞．ＨＭＴおよび＜バックグラウンド＞．ＨＭＴが含まれる。各サムネイルについてメディア上に１つのファイルがある（たとえば、．ＨＭＴ拡張子を有する１６０×１２０ＪＰＧフォーマット）。オーサリングソフトウェアはファイルを適切に命名することができる。サムネイルファイルは「ＩＭＡＧＥＳ」サブディレクトリに作成される。各メニューバックグラウンドについてメディア上に１つのファイルがある。４：３の縦横比を有するバックグランドは、．ＨＭＴ拡張子を有する６４０×４８０ＪＰＧフォーマットである。１６：９の縦横比を有するバックグランドは、．ＨＭＴ拡張子を有する８５２×４８０ＪＰＧフォーマットである。オーサリングソフトウェアはファイルを適切に命名することができる。バックグラウンドファイルは「ＩＭＡＧＥＳ」サブディレクトリに作成される。
【００７２】
ＨＩＧＨＭＡＴディレクトリおよびその中のすべてのファイルに、ユーザの混乱を減らすために、メディアを作成するソフトウェアによって隠すようにマークを付けることができる。プレイヤは、これらのファイルおよびディレクトリが隠されるかどうかにかかわらず、メディアを処理するべきである。バイナリ構造のすべてが、リトルエンディアンのバイト順序を使用して符号化されるべきである。ファイルおよびディレクトリ名はビッグエンディアンのバイト順序を使用するべきである。プレイヤが未知の値に出会うとき、デフォルトの挙動を、合わないファイルを無視することにするべきである。たとえば、プレイリストサマリタイプが２５５に等しい場合、プレイリスト全体がスキップされるべきである。
【００７３】
多言語
本発明は多言語のメニューおよびテキストデータを単一の記憶メディア上でサポートする。これは、ロケール識別子（ＬＣＩＤ）の使用を通じて実施される。例示的ＬＣＩＤ８０２の構造を図８に例示する。より詳細に付録Ａで論じるように、アクセラレータファイル（たとえば、ＴＥＸＴ．ＨＭＴおよびＭＥＮＵ．ＨＭＴ）のファイルヘッダは、それらの言語を表すＬＣＩＤ８０２を含み、これらは合致しなければならない。ＣＯＮＴＥＮＴＳ．ＨＭＴは、この記憶メディア上の言語についてのＬＣＩＤのリストを含む。
【００７４】
メディアプレイヤは、ＬＣＩＤ８０２のリストにおける最初の項目をデフォルト言語として使用する。複数の言語が定義されている場合、プレイヤはプレイするためのＬＣＩＤ８０２をリストから選択するべきである（たとえば、メディアプレイヤの言語またはロケールに基づく）。プレイヤは対応するＴＥＸＴ．ＨＭＴおよびＭＥＮＵ．ＨＭＴを、これらのファイルについてのディレクトリ番号を使用することによってロードする。最初（デフォルト）のＬＣＩＤ８０２エントリは、ＣＯＮＴＥＮＴＳ．ＨＭＴの場所であるディレクトリ番号を有するべきであり、すなわち、デフォルト言語のＭＥＮＵ．ＨＭＴおよびＴＥＸＴ．ＨＭＴはＣＯＮＴＥＮＴＳ．ＨＭＴと同じディレクトリ内にある。
【００７５】
ＬＣＩＤ８０２自体はいくつかの部分を有し、最初の１０ビットは主要言語ＩＤ８０４であり、これは言語自体を含む。次の６ビットは副言語ＩＤ８０６を含み、これはしばしば、同じ主要言語ＩＤ８０４を共有する領域を区別するために使用される。次の４ビットはソートＩＤ８０８を表し、これは同じ言語および領域について使用することができる交互のソート順序の間で区別することができる。残りの１２ビットは将来の使用のために予約され、常にゼロであるべきである。たとえば、ＬＣＩＤ８０２は、より詳細に付録Ａで説明するＣＯＮＴＥＮＴＳ．ＨＭＴなどのファイルに格納することができる。
【００７６】
本発明のソフトウェアと共に使用するためのアクセラレータファイルの例示的構造に関する追加の詳細については、付録Ａを参照されたい。
【００７７】
本発明またはその実施形態の要素を紹介するとき、冠詞「ａ」、「ａｎ」、「ｔｈｅ」および「ｓａｉｄ」は、１つまたは複数の要素があることを意味するように意図される。「備える」、「含む」および「有する」という用語は包含的であるように意図され、列挙された要素以外の追加の要素が存在する可能性があることを意味する。
【００７８】
上記に鑑みて、本発明のいくつかの目的が達成され、他の有利な結果が達成されることがわかるであろう。
【００７９】
様々な変更を上記の構成、製品および方法に、本発明の範囲から逸脱することなく行うことができるので、上記の説明に含まれた、また、添付の図面に示すすべてのものが例示的として、限定する意味ではなく解釈されるべきであることが意図される。
【００８０】
付録Ａ
テキスト符号化
すべてのテキストデータはＵＣＳ−２ユニコードフォーマットで格納される。すべてのファイルおよびディレクトリ名は、それらがソースメディア上にあるときのケースを保持するべきである。リトルエンディアンのバイト順序が、ディレクトリおよびファイル名のうちビッグエンディアンのワードレイアウトを使用するべきであるものを除いて、指定されたすべてのワードレイアウトについて使用されるべきである。
【００８１】
ディレクトリネームのソート順序
ディレクトリテーブル内のエントリは、重要度の順序で適用された以下の基準を使用してソートされるべきである。
１）親ディレクトリ番号の相対値に従って昇順に。
２）２つのディレクトリが同じ親ディレクトリ番号を有する場合、これらの名前が、重要度の降順で以下の基準を使用してソートされるべきである。
２．１）２つのディレクトリ名がすべてのバイト位置で同じ値を有する場合、２つのディレクトリの値は等しい。
２．２）２つのディレクトリ名が同じ数のバイト位置を含まない場合、両方のディレクトリ名が同じ数のバイト位置を含むようになるまで、短い方のディレクトリ名が、すべて（００）に設定されたパディングバイトで右にパディングされる。
２．３）すべての必要なパディングを追加して、両方のディレクトリ名を等しい長さとして処理した後、ディレクトリ名の最初の位置で開始して、あるバイト位置が同じ値を含まないことが判明するまで、両方のバイト値が比較される。より高いコード位置の値を有するディレクトリ名がより大きい名前である。
【００８２】
ファイル名のソート順序
ファイル名テーブル内のエントリは、重要度の順序で適用された以下の基準を使用してソートされるべきである。
３）親ディレクトリ番号の相対値に従って昇順に。
４）２つのファイルが同じ親ディレクトリ番号を有する場合、これらの名前が、重要度の降順で以下の基準を使用してソートされるべきである。
２．１）２つのファイル名がすべてのバイト位置で同じ値を有する場合、２つのファイルの値は等しい。
２．２）２つのファイル名が同じ数のバイト位置を含まない場合、両方のファイル名が同じ数のバイト位置を含むようになるまで、短い方のファイル名が、すべて（００）に設定されたパディングバイトで右にパディングされる。
２．３）すべての必要なパディングを追加して、両方のファイル名を等しい長さとして処理した後、ファイル名の最初の位置で開始して、あるバイト位置が同じ値を含まないことが判明するまで、両方のバイト値が比較される。より高いコード位置の値を有するファイル名がより大きい名前である。
【００８３】
自然言語ソート
ユニコードボリュームにおいて、１６ビットＵＣＳ−２コードポイントが使用されて、パステーブルレコードの順序およびディレクトリレコードの順序が決定される。自然言語ソートをメディア上で提供しようとする試みは行われない。自然言語ソートはオプショナルで、表示アプリケーションによって望ましいように提供することができる。
【００８４】
ＣＯＮＴＥＮＴＳ．ＨＭＴ
ＣＯＮＴＥＮＴＳ．ＨＭＴは、ディスク上に存在するすべてのメディアファイルについての情報を含む。これはディレクトリテーブルとその後に続く、サポートされた各ファイルタイプ（オーディオ、ビデオ、メニュー画像、画像およびプレイリスト）についてのファイルエントリテーブルを含む。このファイルは、他のすべてのＨＩＧＨＭＡＴファイルが参照する主索引である。各ファイルを、それがＣＯＮＴＥＮＴＳ．ＨＭＴ内でリストされる順序によって一意に識別することができる。ファイル番号は１で開始し、隙間なく連続する。
【００８５】
コンテンツＩＤ
ＣＯＮＴＥＮＴＳ．ＨＭＴ内の各エントリは一意のＩＤを有し、これはファイル内のその相対位置から導出される。コンテンツＩＤという用語を、いずれかのファイルタイプへの参照として使用することができる。ＩＤは１で開始し、ファイル全体にわたって隙間なく連続する。ＣＩＤは、コンテンツＩＤの省略形として使用される。
【００８６】
プレイリストファイルＩＤ
プレイリストファイルはＣＯＮＴＥＮＴＳ．ＨＭＴ内の最初のファイルであり、存在する場合、ファイルＩＤ１で開始するべきである。
【００８７】
オーディオファイルＩＤ
オーディオファイルは、ＣＯＮＴＥＮＴＳ．ＨＭＴ内でプレイリストファイルのリストの後に続く。開始ファイルＩＤは、ここで定義されたプレイリストファイルの数に１を加えたものであるべきである。
【００８８】
サムネイルＩＤ
メニュー画像ファイルは、ＣＯＮＴＥＮＴＳ．ＨＭＴ内でオーディオファイルのリストの後に続く。開始ファイルＩＤは、ここで定義されたプレイリストファイルの数に、ここで定義されたオーディオファイルの数と１を加えたものであるべきである。
【００８９】
画像ファイルＩＤ
画像ファイルは、ＣＯＮＴＥＮＴＳ．ＨＭＴ内でメニュー画像ファイルのリストの後に続く。開始ファイルＩＤは、ここで定義されたプレイリストファイルの数に、ここで定義されたオーディオファイルの数と、ここで定義されたメニュー画像ファイルの数と１を加えたものであるべきである。
【００９０】
ビデオファイルＩＤ
ビデオファイルは、ＣＯＮＴＥＮＴＳ．ＨＭＴ内で画像ファイルのリストの後に続く。開始ファイルＩＤは、ここで定義されたプレイリストファイルの数に、ここで定義されたオーディオファイルの数と、ここで定義されたメニュー画像ファイルの数と、ここで定義された画像ファイルの数と１を加えたものであるべきである。
【００９１】
ファイル番号はこのファイル内に格納されず、これはこれらが容易にＣＯＮＴＥＮＴＳ．ＨＭＴ内のファイル情報の場所によって導出されるからである。各ファイルエントリテーブル内のファイルの数がＣＯＮＴＥＮＴＳ．ＨＭＴヘッダに格納される。これらの番号を使用して、ファイル内のどこで列挙を開始して特定のファイル参照を発見するかを識別することができる。ＭＥＮＵ．ＨＭＴ、ＴＥＸＴ．ＨＭＴおよびｎｎｎｎｎｎｎｎ．ＨＭＴファイルは、ファイルをこの一意の番号によって参照する。これは、これらのファイル内のスペースを節約し、同じ情報を多数の場所に格納しないために行われた。ＣＯＮＴＥＮＴＳ．ＨＭＴ内の類似のファイルタイプのグループ化により、プレイヤはそのファイルタイプを処理しない場合、ファイルのセクション全体を無視することができ、たとえば、オーディオ専用プレイヤは、ＣＯＮＴＥＮＴＳ．ＨＭＴのオーディオセクションの後のあらゆるものを廃棄することができる。ディレクトリテーブルは、多数の各ファイル内に含まれたパス情報の圧縮を可能にするように設計される。
【００９２】
ＣＯＮＴＥＮＴＳ．ＨＭＴファイルの構造
アクセラレータファイル内のオフセットは、ファイルの先頭からのバイトオフセットである。オーディオ、メニュー画像、画像およびビデオファイルテーブルは２Ｋ境界で開始するべきである。ディレクトリテーブルは、余計なパディングなしにＬＣＩＤテーブルを含むファイルヘッダの後に書き込まれるべきである。
【００９３】
図９は、コンピュータ可読媒体上のすべてのメディアファイルについての情報を表すデータ構造を例示する。
【００９４】
ファイルヘッダ
所与のタイプの使用可能なファイルがない場合、対応するテーブルが空にされるべきであり、これはファイルの数およびテーブルへのオフセットの両方がゼロであるとして書かれるべきである。
【００９５】
【表２】
2004164824.tif 000004
【００９６】
識別子
この８バイトエントリは、ＡＳＣＩＩによる「ＩＮＦＯ＿ＨＭＴ」を含む。
【００９７】
バージョン
この２バイトエントリは、このファイルを書くために使用されたＨＭＴ仕様のバージョンを表す。たとえば、バージョン１．２０は０×７８（１０進で１２０）として格納される。
【００９８】
ＨＭＴ世代
この８バイトエントリは、このＣＯＮＴＥＮＴＳ．ＨＭＴに合致するＬＳＮ．ＨＭＴの世代を表す。このＣＯＮＴＥＮＴＳ．ＨＭＴは、同じＨＭＴ世代番号を含むＬＳＮ．ＨＭＴファイルと共にのみ使用されるべきである。これらのＨＭＴ世代の値が合致しない場合、ＬＳＮ．ＨＭＴファイルはプレイヤによって無視されるべきである。０の値は、ＬＳＮ．ＨＭＴファイルがないことを意味する。
【００９９】
ＣＯＮＴＥＮＴＳ．ＨＭＴのサイズ
この４バイトエントリは、ＣＯＮＴＥＮＴＳ．ＨＭＴのサイズをバイトで含む。
【０１００】
ディレクトリの数
この４バイトエントリは、ここで定義されたディレクトリテーブル内のディレクトリの数を含む。
【０１０１】
ディレクトリテーブルへのオフセット
この４バイトエントリは、ＣＯＮＴＥＮＴＳ．ＨＭＴの先頭からディレクトリテーブルへのバイトオフセットである。
【０１０２】
プレイリストファイルの数
この４バイトエントリは、ここで定義されたプレイリストファイルテーブル内のプレイリストファイルの数を含む。少なくとも１つのプレイリストファイルがあるべきである。
【０１０３】
プレイリストエントリのサイズ
この２バイトエントリは、バイトによるプレイリストエントリのサイズである。
【０１０４】
プレイリストファイルテーブルへのオフセット
この４バイトエントリは、ＣＯＮＴＥＮＴＳ．ＨＭＴの先頭からプレイリストファイルテーブルへのバイトオフセットである。
【０１０５】
オーディオファイルの数
この４バイトエントリは、ここで定義されたオーディオファイルテーブル内のオーディオファイルの数を含む。
【０１０６】
オーディオエントリのサイズ
この２バイトエントリは、ここで定義された、バイトによるオーディオファイルエントリのサイズである。
【０１０７】
オーディオファイルテーブルへのオフセット
この４バイトエントリは、ＣＯＮＴＥＮＴＳ．ＨＭＴの先頭からオーディオファイルテーブルへのバイトオフセットである。このオフセットは２Ｋの倍数であるべきであり、プレイリストファイルテーブルの終了とオーディオファイルテーブルの開始の間のいかなる隙間も無視されるべきである。０の値は、ＣＯＮＴＥＮＴＳ．ＨＭＴ内にオーディオエントリがないことを示す。ここで定義されたオーディオファイルの数も０であるべきである。
【０１０８】
メニュー画像ファイルの数
この４バイトエントリは、ここで定義されたメニュー画像ファイルテーブル内のメニュー画像ファイルの数を含む。
【０１０９】
メニュー画像エントリのサイズ
この２バイトエントリは、ここで定義された、バイトによるメニュー画像ファイルエントリのサイズである。
【０１１０】
メニュー画像ファイルテーブルへのオフセット
この４バイトエントリは、ＣＯＮＴＥＮＴＳ．ＨＭＴの先頭からメニュー画像ファイルテーブルへのバイトオフセットである。このオフセットは２Ｋの倍数であるべきであり、オーディオファイルテーブルの終了とメニュー画像ファイルテーブルの開始の間のいかなる隙間も無視されるべきである。０の値は、ＣＯＮＴＥＮＴＳ．ＨＭＴ内にメニュー画像エントリがないことを示す。ここで定義されたメニュー画像ファイルの数も０であるべきである。
【０１１１】
画像ファイルの数
この４バイトエントリは、ここで定義された画像ファイルテーブル内の画像ファイルの数を含む。
【０１１２】
画像エントリのサイズ
この２バイトエントリは、ここで定義されたバイトによる画像ファイルエントリのサイズである。
【０１１３】
画像ファイルテーブルへのオフセット
この４バイトエントリは、ＣＯＮＴＥＮＴＳ．ＨＭＴの先頭から画像ファイルテーブルへのバイトオフセットである。このオフセットは２Ｋの倍数であるべきであり、メニュー画像ファイルテーブルの終了と画像ファイルテーブルの開始の間のいかなる隙間も無視されるべきである。０の値は、ＣＯＮＴＥＮＴＳ．ＨＭＴ内に画像エントリがないことを示す。ここで定義された画像ファイルの数も０であるべきである。
【０１１４】
ビデオファイルの数
この４バイトエントリは、ここで定義されたビデオファイルテーブル内のビデオファイルの数を含む。
【０１１５】
ビデオエントリのサイズ
この２バイトエントリは、ここで定義されたバイトによるビデオファイルエントリのサイズである。
【０１１６】
ビデオファイルテーブルへのオフセット
この４バイトエントリは、ＣＯＮＴＥＮＴＳ．ＨＭＴの先頭からビデオファイルテーブルへのバイトオフセットである。このオフセットは２Ｋの倍数であるべきであり、画像ファイルテーブルの終了とビデオファイルテーブルの開始の間のいかなる隙間も無視されるべきである。０の値は、ＣＯＮＴＥＮＴＳ．ＨＭＴ内にビデオエントリがないことを示す。ここで定義されたビデオファイルの数も０であるべきである。
【０１１７】
ＬＣＩＤエントリの数
この２バイトエントリは、このディスク上の言語の数を表す。この値は少なくとも１でなければならない。
【０１１８】
ディレクトリ番号
この４バイトエントリは、このロケール識別子についてのＴＥＸＴ．ＨＭＴおよびＭＥＮＵ．ＨＭＴを含むディレクトリの、ここで定義されたディレクトリテーブル内の索引である。これは、ＬＣＩＤをディレクトリ名とした、＼ＨＩＧＨＭＡＴのサブディレクトリのいずれかであるべきであるが、＼ＨＩＧＨＭＡＴ自体への参照はデフォルト言語について有効である。
【０１１９】
ＬＣＩＤｎ
この４バイトエントリは、ロケール識別子を表す。
【０１２０】
ディレクトリテーブル
ディレクトリエントリは１で開始して付番され、オフセットはテーブルの先頭であり、容易な直接索引付けを可能にする。ディレクトリ名は空白のＵＣＳ−２文字（２つの空バイト）で終了されるべきである。ディレクトリテーブルは、有効なＪＰＧ、ＨＭＴ、ＭＰ３、ＡＳＦ、ＷＭＡまたはＷＭＶファイルである少なくとも１つのファイルを含む、ディスク上のすべてのディレクトリを含むべきである。
【０１２１】
ディレクトリテーブルは以下のようにフォーマットされるべきである。
【０１２２】
【表３】
2004164824.tif 000005
【０１２３】
ルートディレクトリはエントリ１に格納され、親エントリは０（無効なエントリ番号）であるべきである。ディレクトリエントリは、ここで定義されたソート順序でリストされるべきである。
【０１２４】
親ディレクトリ番号
この４バイトエントリは、親ディレクトリについてのディレクトリテーブルにおける索引である。この値は最初のディレクトリエントリについて０であるべきである。
【０１２５】
ディレクトリ名の長さへのオフセット
この４バイトエントリは、ＣＯＮＴＥＮＴＳ．ＨＭＴの先頭からこのエントリのためのディレクトリ名の長さへのバイトオフセットである。
【０１２６】
ディレクトリ名の長さ
この２バイトエントリは、ディレクトリ名のバイト長から終了の空白ＵＣＳ−２文字（２つの空バイト）を除いたものを含む。
【０１２７】
ディレクトリ名
この可変長エントリは、ディレクトリのＵＣＳ−２名である。この名前は、空白のＵＣＳ−２文字（２つの空バイト）で終了されるべきである。このエントリの最大長は、空白のＵＣＳ−２文字を含む１１１のＵＣＳ−２文字である。このエントリはビッグエンディアンのワードレイアウトを使用するべきである。
【０１２８】
プレイリストファイルテーブル
プレイリストファイルテーブルは、プレイリストファイルエントリのリストを含む。各プレイリストファイルについて１つのプレイリストファイルエントリがあるべきである。プレイリストファイルについてのファイル名は格納されず、これは、各プレイリストについてのファイル名を、命名スキームと組み合わせて、ここで定義されたＣＯＮＴＥＮＴＳ．ＨＭＴ内のプレイリストファイルのＩＤを使用して導出することができるからである。各プレイリストファイルエントリは以下のようにフォーマットされるべきである。
【０１２９】
【表４】
2004164824.tif 000006
【０１３０】
ディレクトリ番号
この４バイトエントリは、このファイルを含むディレクトリの、ここで定義されたディレクトリテーブルにおける索引である。
【０１３１】
プレイリストサマリタイプ
この値は、プレイリストファイルエントリに対応するプレイリストファイルのヘッダに格納されたものと同じである。
【０１３２】
予約済
この１バイトエントリは将来の使用のために予約される。
【０１３３】
オーディオファイルテーブル
オーディオファイルテーブルは、オーディオファイルエントリのリストと、その後に続くファイル名テーブルを含む。各オーディオファイルについて１つオーディオファイルエントリがあるべきである。Ｗｉｎｄｏｗｓ（登録商標）Ｍｅｄｉａ  Ａｕｄｉｏファイルは．ＷＭＡ拡張子を有するべきであり、ＭＰ３ファイルは．ＭＰ３拡張子を有するべきである。他のすべてのファイル拡張子は無効である。ファイル名テーブルをオーディオファイルエントリの後に置くことにより、プレイヤが、最初のファイル名のＬＳＮへの変換が行われた後にファイル名テーブルをメモリから廃棄することができ、それによりメモリ内で各ファイルの再生のために必要とされた実際のデータのみを保つことができる。オーディオファイルエントリは、ここで定義されたソート順序でリストされるべきである。各オーディオファイルエントリは以下のようにフォーマットされるべきである。
【０１３４】
【表５】
2004164824.tif 000007
【０１３５】
【表６】
2004164824.tif 000008
【０１３６】
ディレクトリ番号へのオフセット
この４バイトエントリは、ＣＯＮＴＥＮＴＳ．ＨＭＴの先頭からこのエントリのためのディレクトリ番号へのバイトオフセットである。
【０１３７】
ファイルタイプ
この２バイトエントリはファイルタイプを表し、これはデータ符号化フォーマットを意味する。オーディオファイルについて定義された値のみがこのエントリについて有効である。
【０１３８】
【表７】
2004164824.tif 000009
【０１３９】
特殊フラグ
この２バイトエントリは、このファイルの特殊な属性を要約する。特殊フラグエントリは、以下の値を共に論理和することによって作成される。
【０１４０】
【表８】
2004164824.tif 000010
【０１４１】
特殊フラグエントリにより、プレイヤが、プレイすることができるファイルをフィルタすることができ、たとえば、保護付きのコンテンツをプレイすることができないプレイヤは、ＤＲＭ保護付きとしてマーク付けされたファイルを除くべきである。
【０１４２】
チャネルの数
この１バイトエントリは、このファイル内のオーディオのチャネルの数を含む。
【０１４３】
サンプルサイズ
この１バイトエントリは、チャネル毎のビットサイズを含む。
【０１４４】
平均ビットレート
この４バイトエントリは、ビット毎秒によるオーディオストリーム平均ビットレートを含む。
【０１４５】
ファイルビットレート
この４バイトエントリは、ビット毎秒による合計ファイルビットレートを含む。
【０１４６】
再生時間
この４バイトエントリは、ミリ秒によるこのファイルの持続時間を含む。
【０１４７】
サンプリング周波数
この４バイトエントリは、ヘルツによるサンプリング周波数を含む。
【０１４８】
トラック番号
この２バイトエントリは、ソースメディア上のオーディオファイルのトラック番号を含む。０の値はトラック番号がないことを示す。
【０１４９】
サムネイルＩＤ
この４バイトエントリは、ＣＯＮＴＥＮＴＳ．ＨＭＴ内のこのファイルについてのサムネイルである画像ファイルＩＤを表す。このファイルについてのサムネイルがない場合、この値は０であるべきである。この値をオーサリングアプリケーションによって使用して、サムネイルの再生成を防止することができる。
【０１５０】
ディレクトリ番号
この４バイトエントリは、このファイルを含むディレクトリの、ここで定義されたディレクトリテーブルにおける索引である。
【０１５１】
ファイル名の長さ
この２バイトエントリは、ファイル名のバイト長から終了の空白ＵＣＳ−２文字（２つの空バイト）を除いたものを含む。
【０１５２】
ファイル名
これはＵＣＳ−２ファイル名である。この名前は、空白のＵＣＳ−２文字（２つの空バイト）で終了されるべきである。このエントリの最大長は、空白のＵＣＳ−２文字を含む１１１のＵＣＳ−２文字である。このエントリはビッグエンディアンのワードレイアウトを使用するべきである。
【０１５３】
メニュー画像ファイルテーブル
メニュー画像ファイルテーブルは、ＭＥＮＵ．ＨＭＴファイルで使用されるサムネイルおよびバックグラウンド画像のすべてをリストするために使用される。すべてのメニュー画像ファイルは．ＨＭＴ拡張子を有するべきであり、他のすべてのファイル拡張子は無効である。メニュー画像ファイルテーブルは、メニュー画像ファイルエントリのリストとその後に続くファイル名テーブルを含む。各メニュー画像ファイルについて１つのメニュー画像ファイルエントリがあるべきである。メニュー画像ファイルエントリは、ここで定義されたソート順序でリストされるべきである。各メニュー画像ファイルエントリは以下のようにフォーマットされるべきである。
【０１５４】
【表９】
2004164824.tif 000011
【０１５５】
【表１０】
2004164824.tif 000012
【０１５６】
ディレクトリ番号へのオフセット
この４バイトエントリは、ＣＯＮＴＥＮＴＳ．ＨＭＴの先頭からこのエントリのためのディレクトリ番号へのバイトオフセットである。
【０１５７】
ファイルタイプ
この２バイトエントリはファイルタイプを表し、これはデータ符号化フォーマットを意味する。ここで定義された有効な値は、サムネイル、メニューバックグラウンド（４×３）およびメニューバックグラウンド（１６×９）のみである。
【０１５８】
特殊フラグ
この２バイトエントリは本明細書で定義される。
【０１５９】
ディレクトリ番号
この４バイトエントリは、このファイルを含むディレクトリの、ここで定義されたディレクトリテーブルにおける索引である。
【０１６０】
ファイル名の長さ
この２バイトエントリは、ファイル名のバイト長から終了の空白ＵＣＳ−２文字（２つの空バイト）を除いたものを含む。
【０１６１】
ファイル名
これはＵＣＳ−２ファイル名である。この名前は、空白のＵＣＳ−２文字（２つの空バイト）で終了されるべきである。このエントリの最大長は、空白のＵＣＳ−２文字を含む１１１のＵＣＳ−２文字である。このエントリはビッグエンディアンのワードレイアウトを使用するべきである。
【０１６２】
画像ファイルテーブル
画像ファイルテーブルは、画像ファイルエントリのリストとその後に続くファイル名テーブルを含む。各画像ファイルについて１つの画像ファイルエントリがあるべきである。すべての画像ファイルは．ＪＰＧまたは．ＪＰＥＧ拡張子を有するべきであり、他のすべてのファイル拡張子は無効である。画像ファイルエントリは、ここで定義されたソート順序でリストされるべきである。各画像ファイルエントリは以下のようにフォーマットされるべきである。
【０１６３】
【表１１】
2004164824.tif 000013
【０１６４】
【表１２】
2004164824.tif 000014
【０１６５】
ディレクトリ番号へのオフセット
この４バイトエントリは、ＣＯＮＴＥＮＴＳ．ＨＭＴの先頭からこのエントリのためのディレクトリ番号へのバイトオフセットである。
【０１６６】
ファイルタイプ
この２バイトエントリはファイルタイプを表し、これはデータ符号化フォーマットを意味する。画像ファイルについてここで定義された値のうち、サムネイル、メニューバックグラウンド（４×３）およびメニューバックグラウンド（１６×９）を除いたもののみが有効である。
【０１６７】
特殊フラグ
この２バイトエントリはここで定義される。
【０１６８】
サムネイルＩＤ
この４バイトエントリは、ＣＯＮＴＥＮＴＳ．ＨＭＴ内のこのファイルについてのサムネイルである画像ファイルＩＤを表す。この画像についてのサムネイルがない場合、この値は０であるべきである。この値をオーサリングアプリケーションによって使用して、サムネイルの再生成を防止することができる。
【０１６９】
垂直サイズ
この２バイトエントリは、画像の垂直サイズをピクセルで表す。
【０１７０】
水平サイズ
この２バイトエントリは、画像の水平サイズをピクセルで表す。
【０１７１】
ディレクトリ番号
この４バイトエントリは、このファイルを含むディレクトリの、ここで定義されたディレクトリテーブルにおける索引である。
【０１７２】
ファイル名の長さ
この２バイトエントリは、ファイル名のバイト長から終了の空白ＵＣＳ−２文字（２つの空バイト）を除いたものを含む。
【０１７３】
ファイル名
これはＵＣＳ−２ファイル名である。この名前は、空白のＵＣＳ−２文字（２つの空バイト）で終了されるべきである。このエントリの最大長は、空白のＵＣＳ−２文字を含む１１１のＵＣＳ−２文字である。このエントリはビッグエンディアンのワードレイアウトを使用するべきである。
【０１７４】
ビデオファイルテーブル
ビデオファイルテーブルは、ビデオファイルエントリのリストとその後に続くファイル名テーブルを含む。各ビデオファイルについて１つのビデオファイルエントリがあるべきである。Ｗｉｎｄｏｗｓ（登録商標）Ｍｅｄｉａ  Ｖｉｄｅｏファイルのための有効なファイル拡張子は．ＷＭＶおよび．ＡＳＦであり、．ＷＭＶは好ましい拡張子である。オプショナルのＭＰ４ファイルのための有効なファイル拡張子は、．ＡＳＦであるべきである。他のすべてのファイル拡張子は無効である。ファイル名テーブルをビデオファイルエントリの後に置くことにより、プレイヤが、最初のファイル名のＬＳＮへの変換が行われた後にファイル名テーブルをメモリから廃棄することができ、それによりメモリ内で各ファイルの再生のために必要とされた実際のデータのみを保つことができる。ビデオファイルエントリは、ここで定義されたソート順序でリストされるべきである。各ビデオファイルエントリは、ここで定義されたオーディオファイルエントリとその後に続くビデオエントリのようにフォーマットされるべきである。
【０１７５】
【表１３】
2004164824.tif 000015
【０１７６】
【表１４】
2004164824.tif 000016
【０１７７】
ファイルタイプ
この２バイトエントリはファイルタイプを表し、これはデータ符号化フォーマットを意味する。ビデオファイルについてここで定義された値のみがこのエントリについて有効である。
【０１７８】
ビデオ平均ビットレート
この４バイトエントリは、ビット毎秒による平均ビットレートを含む。
【０１７９】
ビデオ垂直サイズ
この２バイトエントリは、ピクセルによるビデオファイルの垂直サイズを含む。
【０１８０】
ビデオ水平サイズ
この２バイトエントリは、ピクセルによるビデオファイルの水平サイズを含む。
【０１８１】
フレームレート
このフィールドは、３０／１．００１（ＮＴＳＣ）、２５（ＰＡＬ）などのようなフレームレートを４バイトで含むべきである。このフィールドは（最初の２バイト整数）／（最後の２バイト整数）として記述することができる。オーサリングアプリケーションがフレームレートを決定することができない場合、この値は０であるべきである。オーサリングアプリケーションは最小公倍数の形式を使用してフレームレートを表すべきである。たとえば、ＮＴＳＣでは３００００／１００１０ではなく３０００／１００１である。
【０１８２】
ディレクトリ番号
この４バイトエントリは、このファイルを含むディレクトリの、ここで定義されたディレクトリテーブルにおける索引である。
【０１８３】
ファイル名の長さ
この２バイトエントリは、ファイル名のバイト長から終了の空白ＵＣＳ−２文字（２つの空バイト）を除いたものを含む。
【０１８４】
ファイル名
これはＵＣＳ−２ファイル名である。この名前は、空白のＵＣＳ−２文字（２つの空バイト）で終了されるべきである。このエントリの最大長は、空白のＵＣＳ−２文字を含む１１１のＵＣＳ−２文字である。このエントリはビッグエンディアンのワードレイアウトを使用するべきである。
【０１８５】
プレイリストファイル
各プレイリストは一意のｎｎｎｎｎｎｎｎ．ＨＭＴファイルとして表され、ｎｎｎｎｎｎｎｎは、ここで定義されたＣＯＮＴＥＮＴＳ．ＨＭＴ内のプレイリストファイルＩＤを表す１６進数である。これらのプレイリストファイルは、サブディレクトリ＼ＨＩＧＨＭＡＴ＼ＰＬＡＹＬＩＳＴで作成されるべきである。４つの異なるタイプのプレイリストグループがあり、これらはオーディオ（Ａ）、ビデオ（Ｖ）、タイムドイメージ（ＴＩ）およびパラレルイメージオーディオ（ＰＩＡ）である。各グループの特定の構造を以下に概説する。レベル１プレイヤは、オーディオグループのみをプレイするべきである。
【０１８６】
ｎｎｎｎｎｎｎｎ．ＨＭＴファイルの構造
図１０は、プレイリストファイルを表すデータ構造を例示する。プレイリストファイルは、プレイリストヘッダと後に続く１つまたは複数のプレイリストグループを含む。このファイルは、ファイル内の複数のデータ構造の間に隙間がないように書かれるべきである。
【０１８７】
【表１５】
2004164824.tif 000017
【０１８８】
【表１６】
2004164824.tif 000018
【０１８９】
識別子
この８バイトエントリは、ＡＳＣＩＩによる「ＰＬＩＳＴＨＭＴ」を含む。
【０１９０】
バージョン
この２バイトエントリは、このファイルを書くために使用されたＨＭＴ仕様のバージョンを表す。たとえば、バージョン１．２０は０×７８（１０進で１２０）として格納される。
【０１９１】
プレイリストファイルのサイズ
この４バイトエントリは、バイトによるこのプレイリストファイルのサイズを含む。
【０１９２】
プレイリストサマリタイプ
この１バイトエントリは、その中に含まれたすべての個々のプレイリストエントリのタイプを要約する。サマリタイプは、以下の値を共に論理和することによって作成される。
【０１９３】
【表１７】
2004164824.tif 000019
【０１９４】
ＰＩＡプレイリストは、ＴＩプレイリストとしてのみ要約されるべきであり、したがってオーディオファイル存在ビットを設定するべきでない。プレイリストサマリタイプにより、プレイヤが、プレイすることができるプレイリストのみを示すようにプレイリストのリストをフィルタリングすることができ、たとえば、オーディオ専用プレイヤは、画像またはビデオを含むすべてのプレイリストを除くことができる。
【０１９５】
リピートカウント
この１バイトエントリは、このプレイリストの再生を繰り返す回数である。このプレイリストが、ここで定義された開始点で呼び出された場合、各リピートが終了すると、ファイルが即時に開始点に進む。０の値は、無限のリピートカウントを示す。たとえば、３つのグループであるグループＡ、グループＢおよびグループＣ、および２のリピートカウントが与えられると、再生順序はＡ→Ｂ→Ｃ→Ａ→Ｂ→Ｃ→終了である。同じ３つのグループで、ここで定義された２の開始グループ索引では、再生順序はＢ→Ｃ→Ａ→Ｂ→Ｃ→Ａである。プレイヤは、他のユーザ再生モードと共に再生するとき、リピートカウントを無視することができる。
【０１９６】
サムネイルＩＤ
この４バイトエントリは、ＣＯＮＴＥＮＴＳ．ＨＭＴ内のこのプレイリストについてのサムネイルの索引を表す。このプレイリストについてのサムネイルがない場合、この値は０であるべきである。
【０１９７】
グループの数
この４バイトエントリは、プレイリストグループのカウントを表す。
【０１９８】
特殊フラグ
この２バイトエントリは、このファイルの特殊な属性を要約する。特殊フラグエントリは、以下の値を共に論理和することによって作成される。
【０１９９】
【表１８】
2004164824.tif 000020
【０２００】
次のグループのオフセット
この４バイトエントリは、ｎｎｎｎｎｎｎｎ．ＨＭＴの先頭から次のプレイリストグループへのオフセットである。このエントリは、これが最後のプレイリストグループである場合、０であるべきである。
【０２０１】
前のグループのオフセット
この４バイトエントリは、ｎｎｎｎｎｎｎｎ．ＨＭＴの先頭から前のプレイリストグループへのオフセットである。このエントリは、これが最初のプレイリストグループである場合、０であるべきである。
【０２０２】
グループ番号
この４バイトエントリはこのグループの番号であり、グループ番号を使用して、ＴＥＸＴ．ＨＭＴ内のグループ名をルックアップすることができる。グループメンバは１で開始して連続し、すべてのプレイリスト内のすべてのグループについて一意である。
【０２０３】
プレイリストグループのタイプ
この１バイトエントリは、以下のように定義するプレイリストタイプを表す。
【０２０４】
【表１９】
2004164824.tif 000021
【０２０５】
これらの各プレイリストグループタイプのグループデータのフォーマットは、以下のセクションで定義される。レベル２プレイヤは、タイプ３（ＰＩＡ）をプレイすることは必要とされず、これは、オーディオ再生中の画像のための並列復号化パスの追加の複雑さが、近いうちに使用可能となる可能性のあるハードウェアのいくつかの機能を超えるからである。タイプ３をプレイすることができないプレイヤは、それにもかかわらず、このようなプレイリストエントリが提示されるとき、よい体験を与えるべきである。ＰＩＡシーケンスは、タイムドイメージシーケンスとしてレンダリングされる（オーディオを無視する）べきである。
【０２０６】
予約済
この１バイトエントリは将来の使用のために予約される。
【０２０７】
グループデータ
これは、フォーマットにおいて、実際のプレイリストグループデータがある場所を表す。各プレイリストグループのフォーマットは以下で定義される。
【０２０８】
オーディオプレイリストグループ
【０２０９】
【表２０】
2004164824.tif 000022
【０２１０】
オーディオファイルの数
この４バイトエントリは、このグループ内でリストされるオーディオファイルＩＤの数を表す。
【０２１１】
オーディオファイルＩＤ
このグループ内の各オーディオファイルについて１つの４バイトエントリがある。この値は、ここで定義されたＣＯＮＴＥＮＴＳ．ＨＭＴ内のオーディオファイルの索引である。
【０２１２】
オーディオの開始点
このグループ内の各オーディオファイルについて１つの４バイトエントリがある。この値は、ミリ秒による再生の開始点へのオフセットである。
【０２１３】
オーディオの終了点
このグループ内の各オーディオファイルについて１つの４バイトエントリがある。この値は、ミリ秒による再生の終了点へのオフセットである。０の値は、ファイルの最後までのプレイを示す。プレイヤは、２つの連続したファイルが同じファイルＩＤを有し、最初のファイルの終了点および次のファイルの開始点が等しい場合を認識するべきであり、次いで再生が途切れずに継続するべきである。
【０２１４】
開始点オフセット
このグループ内の各オーディオファイルについて１つの８バイトエントリがある。この値は、オーディオファイルの先頭から、プレイヤがファイルの読み取りを開始するために使用することができる場所へのオフセットである。このオフセットは、本明細書のオーディオフィールドの開始点と共に使用されるべきである。オーディオフィールドの開始点が０である場合、このフィールドは０であるべきであり、この場合、プレイヤはファイルヘッダを検査することによって、読み取るための最初のパケットを位置付けるようになる。オーディオフィールドの開始点がゼロでない場合、オーディオ開始時間に迅速に到達するために、このフィールドがオーサリングソフトウェアによって、ファイル内で復号化を開始するための最も近い場所に設定されるべきである。プレイヤはこのフィールドを無視し、この中のオーディオフィールドの開始点のみを使用することができる。ＣＤメディアでは、上位の４バイトは常に０であるべきである。
【０２１５】
終了点オフセット
このグループ内の各オーディオファイルについて１つの８バイトエントリがある。この値は、オーディオファイルの先頭から、プレイヤがファイルの読み取りを停止するために使用することができる場所へのオフセットである。このオフセットは、この中のオーディオフィールドの終了点と共に使用されるべきである。オーディオフィールドの終了点が０である場合、このフィールドは０であるべきであり、この場合、プレイヤはファイルの読み取りをどこで停止するかをそれ自体で決定することが必要となる。オーディオフィールドの終了点がゼロでない場合、すべての必要なデータが読み取られていることを保証するために、このフィールドがオーサリングソフトウェアによって、ファイル内で読み取りを終了するための最も近い場所に設定されるべきである。プレイヤはこのフィールドを無視し、この中のオーディオフィールドの終了点のみを使用することができる。ＣＤメディアでは、上位の４バイトは常に０であるべきである。
【０２１６】
もう１つの実施形態では、表Ａ１９のオーディオプレイリストグループは以下のフィールドのみを含み、すなわち、オーディオファイルの数およびオーディオファイルＩＤ１からオーディオファイルＩＤｎまでである。オーディオの開始および終了点、およびグループ内の各オーディオファイルについてのオフセットは省略される。
【０２１７】
ビデオプレイリストグループ
【０２１８】
【表２１】
2004164824.tif 000023
【０２１９】
プレイヤは自動的にビデオのサイズを変更して、表示を全体にすることができる。
【０２２０】
ビデオファイルの数
この４バイトエントリは、このビデオプレイリストグループ内でリストされるビデオファイルＩＤの数を表す。
【０２２１】
ビデオファイルＩＤ
このグループ内の各ビデオファイルについて１つの４バイトエントリがある。この値は、ここで定義されたＣＯＮＴＥＮＴＳ．ＨＭＴ内のビデオファイルの索引である。
【０２２２】
ビデオの開始点
このグループ内の各ビデオファイルについて１つの４バイトエントリがある。この値は、ミリ秒による再生の開始点へのオフセットである。この値はＩフレームに設定されるべきである。
【０２２３】
ビデオの終了点
このグループ内の各ビデオファイルについて１つの４バイトエントリがある。この値は、ミリ秒による再生の終了点へのオフセットである。０の値は、ファイルの最後までのプレイを示す。プレイヤは、２つの連続したファイルが同じファイルＩＤを有し、最初のファイルの終了点および次のファイルの開始点が等しい場合を認識するべきであり、次いで再生が途切れずに継続するべきである。
【０２２４】
開始点オフセット
このグループ内の各ビデオファイルについて１つの８バイトエントリがある。この値は、ビデオファイルの先頭から、プレイヤがファイルの読み取りを開始するために使用することができる場所へのオフセットである。このオフセットは、この中のビデオフィールドの開始点と共に使用されるべきである。ビデオフィールドの開始点が０である場合、このフィールドは０であるべきであり、この場合、プレイヤはファイルヘッダを検査することによって、読み取るための最初のパケットを位置付けるようになる。ビデオフィールドの開始点がゼロでない場合、ビデオ開始時間に迅速に到達するために、このフィールドがオーサリングソフトウェアによって、ファイル内で復号化を開始するための最も近い場所に設定されるべきである。プレイヤはこのフィールドを無視し、この中のビデオフィールドの開始点のみを使用することができる。ＣＤメディアでは、上位の４バイトは常に０であるべきである。
【０２２５】
終了点オフセット
このグループ内の各ビデオファイルについて１つの８バイトエントリがある。この値は、ビデオファイルの先頭から、プレイヤがファイルの読み取りを停止するために使用することができる場所へのオフセットである。このオフセットは、この中のオーディオフィールドの終了点と共に使用されるべきである。ビデオフィールドの終了点が０である場合、このフィールドは０であるべきであり、この場合、プレイヤはファイルの読み取りをどこで停止するかをそれ自体で決定することが必要となる。ビデオフィールドの終了点がゼロでない場合、すべての必要なデータが読み取られていることを保証するために、このフィールドがオーサリングソフトウェアによって、ファイル内で読み取りを終了するための最も近い場所に設定されるべきである。プレイヤはこのフィールドを無視し、この中のビデオフィールドの終了点のみを使用することができる。ＣＤメディアでは、上位の４バイトは常に０であるべきである。
【０２２６】
タイムドイメージグループ
【０２２７】
【表２２】
2004164824.tif 000024
【０２２８】
画像ファイルの数
この４バイトエントリは、このグループ内でリストされる画像ファイルＩＤの数を表す。
【０２２９】
初期トランジション
この２バイトエントリは、プレイリスト内の最初の画像を表示するために使用される初期トランジションを定義する。可能な値は、ここで定義されたＣＵＴおよびＦＡＤＥ  ＩＮのみである。
【０２３０】
最終トランジション
この２バイトエントリは、プレイリスト内の最後の画像の表示を終了させるために使用される最終トランジションを定義する。可能な値は、ここで定義されたＣＵＴおよびＦＡＤＥ  ＯＵＴのみである。
【０２３１】
画像ファイル
このグループ内の各画像ファイルについて１つの４バイトエントリがある。この値は、ここで定義されたＣＯＮＴＥＮＴＳ．ＨＭＴ内の画像ファイルの索引である。
【０２３２】
持続時間
この４バイトエントリは、画像を表示する持続時間をミリ秒で表し、０の値は無限を表す。タイムドイメージプレイリストグループの最短画像持続時間は５秒（５０００ミリ秒）である。
【０２３３】
トランジション
この２バイトエントリは、プレイヤが次の画像に変更するときに使用するためのトランジションのタイプを定義する。０の値はＣＵＴとして定義され、サポートされるべきであり、すべての他の値のサポートはオプショナルである。トランジションのリストは以下のように定義される。
【０２３４】
【表２３】
2004164824.tif 000025
【０２３５】
トランジションの持続時間はメーカにより定義される。トランジション持続時間は、上で定義された画像持続時間に影響を及ぼすべきではない。たとえば、それぞれ２０および３０秒の持続時間の２つの画像の間の２秒の持続時間のトランジションは結果として、最初の画像の１９秒と、その後に続くこれらの画像の間の２秒のトランジションと、その後に続く第２の画像の２９秒となるべきである。ＰＩＡプレイリストグループに含まれたタイムドイメージグループでは、持続時間情報をプレイヤが考慮するべきである。
【０２３６】
パラレルイメージオーディオプレイリストグループ
次／前プレイリスト項目機能を実施するとき、プレイヤはタイムドイメージプレイリストグループを通るべきである。プレイヤはオーディオを次／前の画像に同期化させるべきである。
【０２３７】
【表２４】
2004164824.tif 000026
【０２３８】
オーディオプレイリストグループのオフセット
この４バイトエントリは、ｎｎｎｎｎｎｎｎ．ＨＭＴの先頭からＰＩＡエントリ内のオーディオプレイリストグループへのオフセットである。
【０２３９】
タイムドイメージプレイリストグループ
このエントリは、ここで定義されたタイムドイメージグループである。
【０２４０】
オーディオプレイリストエントリ
このエントリは、ここで定義されたオーディオエントリである。
【０２４１】
ＭＥＮＵ．ＨＭＴ
ＭＥＮＵ．ＨＭＴファイルの構造
【０２４２】
図１１は階層メニュー構造を例示する。このファイルは、ファイル内の複数のデータ構造の間に隙間がないように書かれるべきである。
【０２４３】
メニューファイルヘッダ
【０２４４】
【表２５】
2004164824.tif 000027
【０２４５】
識別子
この８バイトエントリは、ＡＳＣＩＩによる「ＭＥＮＵ＿ＨＭＴ」を含む。
【０２４６】
バージョン
この２バイトエントリは、このファイルを書くために使用されたＨＭＴ仕様のバージョンを表す。たとえば、バージョン１．２０は０×７８（１０進で１２０）として格納される。
【０２４７】
ＭＥＮＵ．ＨＭＴのサイズ
この４バイトエントリは、バイトによるＭＥＮＵ．ＨＭＴのサイズを含む。
【０２４８】
ＬＣＩＤ
この４バイトエントリは、このＭＥＮＵ．ＨＭＴファイルの言語ＩＤである。
【０２４９】
最初のメニューのオフセット
この２バイトエントリは、ＭＥＮＵ．ＨＭＴの先頭から、ここで定義された最初のメニューヘッダへのバイトオフセットである。
【０２５０】
メニュータイトルの長さ
この２バイトエントリは、メニュータイトルのバイト長から終了の空白ＵＣＳ−２文字（２つの空バイト）を除いたものを含む。
【０２５１】
メニュータイトル
これはＵＣＳ−２メニュータイトルである。このタイトルは、空白のＵＣＳ−２文字（２つの空バイト）で終了されるべきである。このエントリの最大長は、空白のＵＣＳ−２文字を含む６５のＵＣＳ−２文字である。プレイヤはこれを使用して、メニュー全体についてのタイトルを表示するべきである。空文字列（１つのＮＵＬＬ文字）は、表示するためのタイトルがないか、あるいはオーサリングソフトウェアがタイトルをバックグラウンド画像上にレンダリングしていることを示す。たとえば、「私のハワイの休日」、「２００２年スクールパーティ」である。
【０２５２】
メニュー
メニューはバックグラウンド画像、一様なバックグラウンド色またはプレイヤのデフォルトの挙動のいずれもサポートする。バックグラウンド画像またはバックグラウンド色が定義された場合、テキスト色が定義されるべきである。バックグラウンド画像、バックグラウンド色およびテキスト色のエントリが０である場合、プレイヤはそのデフォルトの挙動を使用するべきである。各サブメニューは、厳密な階層メニュー構造を形成する単一の親メニューによって参照されるべきである。
【０２５３】
【表２６】
2004164824.tif 000028
【０２５４】
メニューヘッダのサイズ
この４バイトエントリは、バイトによる、メニューおよびプレイリスト項目を含むメニューヘッダのサイズである。
【０２５５】
親メニューへのオフセット
この４バイトエントリは、ＭＥＮＵ．ＨＭＴの先頭から親メニューへのバイトオフセットであり、これが最上位メニューである場合、この値は０である。
【０２５６】
バックグラウンド画像ＩＤ（４：３）
この４バイトエントリは、４：３ディスプレイ上にこのメニューのバックグラウンドとして表示するための画像を定義する。この画像は、ＨＭＴ拡張子を有する６４０×４８０のＪＰＧファイルであるべきである。０の値は、バックグラウンド画像がないことを示す。この値は、ここで定義されたＣＯＮＴＥＮＴＳ．ＨＭＴ内のメニューイメージファイルの索引である。プレイヤは、バックグラウンド画像をディスプレイ上で中央に表示して、縦横比を保持するべきである。プレイヤは、いずれかの覆われていないエリアを埋めるためにここで定義されたものがある場合、バックグラウンド色を使用するべきである。
【０２５７】
バックグラウンド画像ＩＤ（１６：９）
この４バイトエントリは、１６：９ディスプレイ上にこのメニューのバックグラウンドとして表示するための画像を定義する。この画像は、ＨＭＴ拡張子を有する８５２×４８０のＪＰＧファイルであるべきである。０の値は、バックグラウンド画像がないことを示す。この値が０でない場合、有効なバックグラウンド画像ＩＤ（４：３）もあるべきである。この値は、ここで定義されたＣＯＮＴＥＮＴＳ．ＨＭＴ内のメニュー画像ファイルの索引である。プレイヤは、バックグラウンド画像をディスプレイ上で中央に表示して、縦横比を保持するべきである。
【０２５８】
バックグラウンド色
この４バイトエントリは、このメニューがディスプレイ上にレンダリングされるときに使用されるべきバックグラウンド色を定義する。これは、バイト順序０ｘＦＦＲＲＧＧＢＢを有するＲＧＢ値としてフォーマットされる。バックグラウンド画像ＩＤがここで定義される場合、バックグラウンド色は、バックグラウンド画像がある場合にそれによって覆われないディスプレイのエリア上でのみ可視であるべきである。０の値は、バックグラウンド色がないことを示す。プレイヤがカラーのレンダリングができない場合、このフィールドを無視することができる。
【０２５９】
テキスト色
この４バイトエントリは、このメニュー上のテキストがディスプレイ上にレンダリングされるべきである色を定義する。これは、バイト順序０ｘＦＦＲＲＧＧＢＢを有するＲＧＢ値としてフォーマットされる。バックグラウンド画像ＩＤまたはバックグラウンド色がここで定義される場合、このエントリはゼロでない値を含むべきである。０の値は、プレイヤがそのデフォルトの挙動を使用するべきであることを意味するように定義される。プレイヤがカラーのレンダリングができない場合、このフィールドを無視することができる。
【０２６０】
項目の数
この２バイトエントリは、このメニュー内のサブメニューまたはプレイリスト項目の数を定義する。
【０２６１】
メニューサブタイトルの長さ
この２バイトエントリは、メニューサブタイトルのバイト長から終了の空白ＵＣＳ−２文字（２つの空バイト）を除いたものを含む。
【０２６２】
メニューサブタイトル
これはＵＣＳ−２メニューサブタイトルである。このサブタイトルは、空白のＵＣＳ−２文字（２つの空バイト）で終了されるべきである。このエントリの最大長は、空白のＵＣＳ−２文字を含む６５のＵＣＳ−２文字である。プレイヤはこれを使用して、このメニューについてのサブタイトルを表示するべきである。空文字列（１つのＮＵＬＬ文字）は、表示するためのサブタイトルがないか、あるいはオーサリングソフトウェアがタイトルをバックグラウンド画像上にレンダリングしていることを示す。
【０２６３】
メニューまたはプレイリスト項目
この可変サイズのエントリは、ここで定義されたメニュー項目またはここで定義されたプレイリスト項目である。
【０２６４】
メニュー項目
【０２６５】
【表２７】
2004164824.tif 000029
【０２６６】
エントリのタイプ
この１バイトエントリは、これがメニュー項目構造かプレイリスト項目構造かを定義する。メニュー項目では、この値は以下で定義するＭＥＮＵの値にするべきである。
【０２６７】
【表２８】
2004164824.tif 000030
【０２６８】
メニューサマリタイプ
この値は、このメニュー項目を介してアクセス可能であるプレイリストのタイプを定義するために使用される。
【０２６９】
サムネイルＩＤ
この４バイトエントリは、ここで定義されたＣＯＮＴＥＮＴＳ．ＨＭＴ内のこのメニュー項目についてのサムネイルＩＤを表し、このメニュー項目についてのサムネイルがない場合、この値は０であるべきである。
【０２７０】
選択状態サムネイルＩＤ
この４バイトエントリは、ここで定義されたＣＯＮＴＥＮＴＳ．ＨＭＴ内のこのメニュー項目についての選択状態を表すサムネイルＩＤを定義する。０の値は、プレイヤが外接矩形（ｂｏｕｎｄｉｎｇ  ｒｅｃｔａｎｇｌｅ）または他の強調表示を生成して、ここで定義された色を使用して選択を指示するべきであることを示す。
【０２７１】
メニューへのオフセット
この４バイトエントリは、ＭＥＮＵ．ＨＭＴの先頭から、ここで定義されたメニューへのバイトオフセットを定義する。
【０２７２】
メニュー名の長さ
この２バイトエントリは、メニュー名のバイト長から終了の空白ＵＣＳ−２文字（２つの空バイト）を除いたものを含む。
【０２７３】
メニュー名
これはメニューのＵＣＳ−２名である。この名前は、空白のＵＣＳ−２文字（２つの空バイト）で終了されるべきである。このエントリの最大長は、空白のＵＣＳ−２文字を含む６５のＵＣＳ−２文字である。
【０２７４】
プレイリスト項目
【０２７５】
【表２９】
2004164824.tif 000031
【０２７６】
エントリのタイプ
この１バイトエントリは、これが、ここで定義されたメニュー項目構造かプレイリスト項目構造かを定義する。プレイリスト項目では、この値はここで定義されたＰＬＡＹＬＩＳＴの値にするべきである。
【０２７７】
プレイリストサマリタイプ
この値は、このメニュー項目が参照するプレイリストのタイプを定義するために使用される。
【０２７８】
サムネイルＩＤ
この４バイトエントリは、ここで定義されたＣＯＮＴＥＮＴＳ．ＨＭＴ内のこのメニュー項目についてのサムネイルＩＤを定義する。このメニュー項目についてのサムネイルがない場合、この値は０であるべきである。サムネイルＩＤは、ここで定義されたプレイリストヘッダ内のサムネイルＩＤと同じものにすることができる。
【０２７９】
選択状態サムネイルＩＤ
この４バイトエントリは、ここで定義されたＣＯＮＴＥＮＴＳ．ＨＭＴ内のこのメニュー項目についての選択状態を表すサムネイルＩＤを定義する。０の値は、プレイヤが外接矩形または他の強調表示を生成して、ここで定義された色を使用して選択を指示するべきであることを示す。
【０２８０】
プレイリストＩＤ
この４バイトエントリは、ここで定義されたＣＯＮＴＥＮＴＳ．ＨＭＴ内のこのメニュー項目についてのプレイリストのＩＤを定義する。
【０２８１】
開始グループ索引
この４バイトエントリは、再生を開始するためのプレイリストファイル内のグループの索引を定義する。１の値はプレイリスト内の最初のグループを示す。
【０２８２】
開始ファイル索引
この４バイトエントリは、再生を開始するためにここで参照されたグループ内のファイルの索引を定義する。１の値は、グループ内の最初のファイルを示す。ここで参照されたグループがパラレルプレイリストグループ（ＰＩＡ）である場合、この値は１であるべきであることに留意されたい。開始グループ索引および開始ファイル索引は共に、１つのプレイリストをメニュー内で何度も参照できるようにする。たとえば、メニューはディスク上のあらゆる画像についてのサムネイルを示すことができ、各サムネイルはユーザを、選択された画像で開始するすべての画像のループプレイリストに導く。
【０２８３】
メニュー内のプレイリスト名の長さ
この２バイトエントリは、メニュー内のプレイリスト名のバイト長から終了の空白ＵＣＳ−２文字（２つの空バイト）を除いたものを含む。
【０２８４】
メニュー内のプレイリスト名
これは、プレイリストがメニュー内で表れるときのＵＣＳ−２名である。この名前は、空白のＵＣＳ−２文字（２つの空バイト）で終了されるべきである。このエントリの最大長は、空白のＵＣＳ−２文字を含む６５のＵＣＳ−２文字である。
【０２８５】
ＴＥＸＴ．ＨＭＴファイル
メタデータのＴＥＸＴ．ＨＭＴ内のフィールドへのマッピングを、以下の表で概説する。
【０２８６】
【表３０】
2004164824.tif 000032
【０２８７】
ＴＥＸＴ．ＨＭＴファイルの構造
図１２は、テキストメタデータを表すデータ構造を例示する。このファイルは、ファイル内の複数のデータ構造の間に隙間がないように書かれるべきである。
【０２８８】
ヘッダセクション
【０２８９】
【表３１】
2004164824.tif 000033
【０２９０】
識別子
このフィールドは、８バイトのＡＳＣＩＩによる「ＴＥＸＴ＿ＨＭＴ」であるべきである。
【０２９１】
バージョン
この２バイトエントリは、このファイルを書くために使用されたＨＭＴ仕様のバージョンを表す。たとえば、バージョン１．２０は０×７８（１０進で１２０）として格納される。
【０２９２】
ファイルサイズ
このフィールドは、ＴＥＸＴ．ＨＭＴファイルのサイズを４バイトで含むべきである。
【０２９３】
コンテンツエントリの数
この４バイトエントリは、ここで定義されたオフセットでのコンテンツテキストエントリの数を定義する。
【０２９４】
グループエントリの数
この４バイトエントリは、ここで定義されたオフセットでのグループテキストエントリの数を定義する。
【０２９５】
追加テキストエントリの数
この４バイトエントリは、ここで定義されたオフセットでの追加テキストエントリの数を定義する。
【０２９６】
コンテンツテキストエントリのオフセット
この４バイトエントリは、ＴＥＸＴ．ＨＭＴの先頭からコンテンツテキストエントリテーブルへのオフセットである。
【０２９７】
グループテキストエントリのオフセット
この４バイトエントリは、ＴＥＸＴ．ＨＭＴの先頭からグループテキストエントリテーブルへのオフセットである。
【０２９８】
追加テキストエントリのオフセット
この４バイトエントリは、ＴＥＸＴ．ＨＭＴの先頭から追加テキストエントリテーブルへのオフセットである。
【０２９９】
ＬＣＩＤ
この４バイトエントリは、このＭＥＮＵ．ＨＭＴファイルの言語ＩＤである。
【０３００】
ディスク名の長さ
この２バイトエントリは、ディスク名のバイト長から終了の空白ＵＣＳ−２文字（２つの空バイト）を除いたものを含む。
【０３０１】
ディスク名
この可変長エントリはディスクの名前を表す。ディスク名はＵＣＳ−２であり、空白のＵＣＳ−２文字（２つの空バイト）で終了されるべきである。このエントリの最大長は、空白のＵＣＳ−２文字を含む６５のＵＣＳ−２文字である。
【０３０２】
テキストエントリ
すべてのテキスト項目は、以下のフォーマットを使用して格納される。
【０３０３】
【表３２】
2004164824.tif 000034
【０３０４】
長さ
この２バイトエントリは、テキストのバイト長から終了の空白ＵＣＳ−２文字（２つの空バイト）を除いたものを含む。
【０３０５】
テキスト
これはＵＣＳ−２テキストエントリである。このテキストは、空白のＵＣＳ−２文字（２つの空バイト）で終了されるべきである。このテキストエントリの最大長は以下の通りである。
【０３０６】
【表３３】
2004164824.tif 000035
【０３０７】
この長さはＵＣＳ−２文字として定義され、終了の空白のＵＣＳ−２文字を含む。
【０３０８】
コンテンツテキストエントリテーブル
コンテンツテキストエントリテーブルは、コンテンツテキストエントリのリストを含む。ＣＯＮＴＥＮＴＳ．ＨＭＴ内の各ファイル（プレイリスト、オーディオ、メニュー画像、画像およびビデオ）について１つのコンテンツテキストエントリが、これらのファイルがＣＯＮＴＥＮＴＳ．ＨＭＴ内でリストされる順序と同じ順序で存在するべきである。
【０３０９】
【表３４】
2004164824.tif 000036
【０３１０】
コンテンツＩＤ
この４バイトエントリは、ここで定義されたこのコンテンツテキストエントリについてのコンテンツＩＤを表す。
【０３１１】
テキスト１エントリのオフセット
この４バイトエントリは、ＴＥＸＴ．ＨＭＴの先頭から、ここで定義されたテキスト１エントリの最初のバイトについてのオフセットを表す。ＣＯＮＴＥＮＴＳ．ＨＭＴ内の各コンテンツ項目がテキスト１エントリを有することが必要とされる。
【０３１２】
テキスト２エントリのオフセット
この４バイトエントリは、ＴＥＸＴ．ＨＭＴの先頭から、ここで定義されたテキスト２エントリの最初のバイトについてのオフセットを表す。コンテンツ項目がテキスト２データを有していない場合、このエントリは０であるべきである。
【０３１３】
テキスト３エントリのオフセット
この４バイトエントリは、ＴＥＸＴ．ＨＭＴの先頭から、ここで定義されたテキスト３エントリの最初のバイトについてのオフセットを表す。コンテンツ項目がテキスト３データを有していない場合、このエントリは０であるべきである。
【０３１４】
テキスト４エントリのオフセット
この４バイトエントリは、ＴＥＸＴ．ＨＭＴの先頭から、ここで定義されたテキスト４エントリの最初のバイトについてのオフセットを表す。コンテンツ項目がテキスト４データを有していない場合、このエントリは０であるべきである。
【０３１５】
テキスト５エントリのオフセット
この４バイトエントリは、ＴＥＸＴ．ＨＭＴの先頭から、ここで定義されたテキスト５エントリの最初のバイトについてのオフセットを表す。コンテンツ項目がテキスト５データを有していない場合、このエントリは０であるべきである。
【０３１６】
追加テキストエントリのオフセット
この４バイトエントリは、ＴＥＸＴ．ＨＭＴの先頭から追加テキストエントリの最初のバイトについてのオフセットを表す。コンテンツ項目が追加テキストデータを有していない場合、このエントリは０であるべきである。
【０３１７】
グループテキストエントリテーブル
グループテキストエントリテーブルは、グループテキストエントリのリストを含む。ＣＯＮＴＥＮＴＳ．ＨＭＴ内でリストされたプレイリストファイル内の各グループについて、１つのグループテキストエントリがあるべきである。これらのエントリは、グループ番号の昇順であるべきである。
【０３１８】
【表３５】
2004164824.tif 000037
【０３１９】
グループ番号
この４バイトエントリは、このグループテキストエントリについてのグループ番号を表す。
【０３２０】
グループ名テキストエントリのオフセット
この４バイトエントリは、ＴＥＸＴ．ＨＭＴの先頭から、ここで定義されたグループ名テキストエントリの最初のバイトについてのオフセットを表す。各グループが名前を有することが必要とされる。
【０３２１】
追加テキストエントリテーブル
追加テキストエントリテーブルは、ここで定義されたゼロまたはそれ以上の追加テキストエントリとして定義される。これらのエントリは、コンテンツＩＤの昇順で格納されるべきである。追加テキストエントリおよび追加テキストエントリの数のフィールドがゼロである場合、追加テキストエントリのベースオフセット、および追加テキストデータのベースオフセットはすべて０であるべきである。
【０３２２】
【表３６】
2004164824.tif 000038
【０３２３】
コンテンツＩＤ
この４バイトエントリは、ここで定義されたＣＯＮＴＥＮＴＳ．ＨＭＴ内のこの追加テキストエントリに関連付けられたファイルのコンテンツＩＤを表す。
【０３２４】
追加テキストデータの数
この１バイトエントリは、この追加テキストエントリによって関連付けられた追加テキストデータの数を表す。
【０３２５】
予約済
この１バイトエントリは将来の使用のために予約される。
【０３２６】
ｎ番目のテキストデータのタイプ
この２バイトエントリは、以下の表で定義された値のうち１つを含む。
【０３２７】
【表３７】
2004164824.tif 000039
【０３２８】
ｎ番目のテキストエントリのオフセット
この４バイトエントリは、ＴＥＸＴ．ＨＭＴの先頭から、ここで定義された各追加テキストエントリの最初のバイトについてのオフセットを表す。
【０３２９】
ＬＳＮファイルヘッダ
【０３３０】
【表３８】
2004164824.tif 000040
【０３３１】
識別子
この８バイトエントリは、ＡＳＣＩＩによる「ＬＳＮ＿ＨＭＴ」を含む。
【０３３２】
バージョン
この２バイトエントリは、このファイルを書くために使用されたＨＭＴ仕様のバージョンを表す。たとえば、バージョン１．２０は０×７８（１０進で１２０）として格納される。
【０３３３】
ＨＭＴ世代
この８バイトエントリは、このＬＳＮ．ＨＭＴに合致するＨＭＴファイルの世代を表す。このＬＳＮ．ＨＭＴは、同じＨＭＴ世代番号を含むＣＯＮＴＥＮＴＳ．ＨＭＴファイルと共にのみ使用されるべきである。オーサリングソフトウェアは一意の乱数値を生成して、２つのファイルが偶然に合致しないことを保証するべきである。
【０３３４】
ＬＳＮ．ＨＭＴのサイズ
この４バイトエントリは、ＬＳＮ．ＨＭＴのサイズをバイトで含む。
【０３３５】
ＬＳＮエントリの数
この４バイトエントリは、ＬＳＮ．ＨＭＴで定義されるエントリの数を含む。
【０３３６】
ＬＳＮ
この４バイトエントリは、同じ索引を有するＣＯＮＴＥＮＴＳ．ＨＭＴ内の項目についての論理セクタ番号を含む。
【０３３７】
ファイルサイズ
この４バイトエントリは、同じ索引を有するＣＯＮＴＥＮＴＳ．ＨＭＴ内の項目についてのファイルサイズをバイトで含む。
【図面の簡単な説明】
【０３３８】
【図１】本発明を実施することができる適切なメディア環境の一実施例を例示するブロック図である。
【図２】本発明によるオーサリングソフトウェアの例示的オペレーションを例示する流れ図である。
【図３】マルチセッションコンピュータ可読媒体を例示する流れ図である。
【図４】本発明によるレンダリングソフトウェアの例示的オペレーションを例示する流れ図である。
【図５】本発明のソフトウェアと共に使用するための例示的圧縮メディアフォーマットを例示するブロック図である。
【図６】本発明を実施することができる適切なコンピューティングシステム環境の一実施例を例示するブロック図である。
【図７】メモリ最適化データのためのファイルシステム構造を例示する例示的ブロック図である。
【図８】ロケール情報を表すデータ構造を例示する例示的ブロック図である。
【図９】コンピュータ可読媒体上のすべてのメディアファイルについての情報を表すデータ構造を例示する例示的ブロック図である。
【図１０】プレイリストファイルを表すデータ構造を例示する例示的ブロック図である。
【図１１】階層メニュー構造を例示する例示的ブロック図である。
【図１２】テキストメタデータを表すデータ構造を例示する例示的ブロック図である。
【符号の説明】
【０３３９】
１００  システム
１０２  コンピュータ
１０４  ＣＤ
１０６  カムコーダ
１０８  カメラ
１１０  コンピュータ可読媒体
１１２  家電デバイス
１１４  入力モジュール
１１６  フィルタモジュール
１１８  ユーザインターフェイスモジュール
【図１】
2004164824.tif 000041
【図２】
2004164824.tif 000042
【図３】
2004164824.tif 000043
【図４】
2004164824.tif 000044
【図５】
2004164824.tif 000045
【図６】
2004164824.tif 000046
【図７】
2004164824.tif 000047
【図８】
2004164824.tif 000048
【図９】
2004164824.tif 000049
【図１０】
2004164824.tif 000050
【図１１】
2004164824.tif 000051
【図１２】
2004164824.tif 000052
【外国語明細書】
2004164824.tif 000053
2004164824.tif 000054
2004164824.tif 000055
2004164824.tif 000056
2004164824.tif 000057
2004164824.tif 000058
2004164824.tif 000059
2004164824.tif 000060
2004164824.tif 000061
2004164824.tif 000062
2004164824.tif 000063
2004164824.tif 000064
2004164824.tif 000065
2004164824.tif 000066
2004164824.tif 000067
2004164824.tif 000068
2004164824.tif 000069
2004164824.tif 000070
2004164824.tif 000071
2004164824.tif 000072
2004164824.tif 000073
2004164824.tif 000074
2004164824.tif 000075
2004164824.tif 000076
2004164824.tif 000077
2004164824.tif 000078
2004164824.tif 000079
2004164824.tif 000080
2004164824.tif 000081
2004164824.tif 000082
2004164824.tif 000083
2004164824.tif 000084
2004164824.tif 000085
2004164824.tif 000086
2004164824.tif 000087
2004164824.tif 000088
2004164824.tif 000089
2004164824.tif 000090
2004164824.tif 000091
2004164824.tif 000092
2004164824.tif 000093
2004164824.tif 000094
2004164824.tif 000095
2004164824.tif 000096
2004164824.tif 000097
2004164824.tif 000098
2004164824.tif 000099
2004164824.tif 000100
2004164824.tif 000101
2004164824.tif 000102
2004164824.tif 000103
2004164824.tif 000104
2004164824.tif 000105
2004164824.tif 000106
2004164824.tif 000107
2004164824.tif 000108
2004164824.tif 000109
2004164824.tif 000110
2004164824.tif 000111
2004164824.tif 000112
2004164824.tif 000113
2004164824.tif 000114
2004164824.tif 000115
2004164824.tif 000116
2004164824.tif 000117
2004164824.tif 000118
2004164824.tif 000119
2004164824.tif 000120
2004164824.tif 000121
2004164824.tif 000122
2004164824.tif 000123
2004164824.tif 000124
2004164824.tif 000125
2004164824.tif 000126
2004164824.tif 000127
2004164824.tif 000128
2004164824.tif 000129
2004164824.tif 000130