JP4139303B2 - レンダリング中のメディアプレイヤのメモリの最適化 - Google Patents

Description

本発明はデジタルメディアコンテンツの分野に関する。詳細には、本発明はレンダリング中のメディアプレイヤのメモリ使用の最適化に関する。

最近の技術の発達により、コンピュータのユーザは現在、様々なメディアおよびマルチメディアコンテンツを自分のパーソナルまたはラップトップコンピュータ上でプレイするなど、改善されたユーザ体験を提供する多数の機能を享受することができる。たとえば、大抵の今日のコンピュータはコンパクトディスク（ＣＤ）をプレイすることができるので、ユーザがコンピュータ上で作業する間に自分の好みの音楽アーティストを聴くことができる。多数のコンピュータはまたデジタル多用途ディスク（ＤＶＤ）ドライブも装備しており、ユーザが映画を見ることができる。

音楽がパーソナルコンピュータ（ＰＣ）上で、Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐオーディオレイヤ３（ＭＰ３）ファイルおよびＷＩＮＤＯＷＳ（登録商標）ＭＤＥＩＡ技術オーディオ（ＷＭＡ）ファイルなど、圧縮メディアファイルからプレイされるとき、ＰＣは通常、メモリ内ですべてのアルバム、アーティスト、ジャンル、年などの完全なデータベースを保持し、ユーザがこれらの属性の中でナビゲートできるようにする。しかし、音楽が書き込み可能ＣＤまたはＤＶＤにコピーされ、ポータブルＣＤプレイヤ、カーレシーバ、ＤＶＤプレイヤ、または、比較的低能力のプロセッサ、制限されたメモリ可用性、安価なドライブ機構、およびしばしば制限されたディスプレイおよびユーザ入力機能を有する他のいずれかの家電デバイスでプレイされるとき、同じ範囲のメタデータが使用可能ではない。

圧縮メディアコンテンツをレンダリングする、現在使用可能なメディアプレイヤは、オーディオの再生を開始するために長い時間を要する可能性がある（たとえば、通常は約３０秒であるが、数分以上を要する可能性があるものもある）。このようなメディアプレイヤの遅い起動時間は部分的には、メディアプレイヤが、メディアコンテンツを格納するメディア全体をスキャンして、個々の各メディアファイルから検索されたいずれかの関連メタデータ（たとえば、タイトル、アーティストおよびジャンル）と共にマルチプレイヤがレンダリングすることができるファイルのリストを構築するために、必要とされる時間による。しばしば、既存のメディアプレイヤは、圧縮メディアコンテンツに関連付けられたいかなるメタデータも検索または表示しない。このような既存のメディアプレイヤは、ジャンル毎のプレイ、またはアーティスト毎のプレイなど、豊富なナビゲーション機能を提供することができない。豊富なナビゲーション機能の欠乏は部分的には、メディアコンテンツからのメタデータをメニューおよびプレイリストに動的にソートおよび集約するための、既存のメディアプレイヤのメモリおよび処理能力が不十分であることによる。

これらの理由のため、レンダリング中にメディアプレイヤのメモリ使用を最適化するためのシステムが、これらおよび他の欠点の１つまたは複数に対処するために望まれる。

本発明は、メディアファイルのレンダリング中にメディアプレイヤのオペレーションを最適化するためのソフトウェアを含む。詳細には、本発明は、データ構造を作成するため、かつ、作成されたデータ構造を、得られたメタデータによりポピュレートするためのオーサリングソフトウェアを含む。本発明によれば、レンダリングソフトウェアはメタデータをデータ構造から検索し、レンダリングするためのメディアファイルを識別する。

本発明のメタデータキャッシュは、メモリ使用およびディスク読み取りの最適化を、テキストおよびバイナリメタデータを異なるキャッシュファイルに分離することによって、かつ、キャッシュの実際のレイアウトによって提供する。最適化されたメタデータキャッシュは、各圧縮メディアファイルからの関連メタデータを格納する。様々な機構が使用されて、たとえばコンピュータ可読媒体上のキャッシュおよび圧縮メディアファイルのコヒーレンシーが、メタデータキャッシュがメディア上の最後のセッション内に存在するときにこれを認識することのみによって保証される。メディアプレイヤはキャッシュを使用して、メディア上のオーディオ、ビデオまたはイメージファイル、および各ファイルについてのいずれかの関連情報を効率的に識別する。一実施形態では、本発明のソフトウェアは長い起動時間を著しく短縮し、これはメディアプレイヤが再生を開始するためにメタデータキャッシュファイルをロードすることのみが必要であり、メディア上のすべてのファイルを最初にスキャンする必要がないからである。さらに、メディアプレイヤは各メディアファイルのヘッダを開いて読み、メタデータをそこから収集する必要がない。したがって、ディスクシークオペレーションの総数および距離、およびディスク読み取りオペレーションの総数が最小限にされる。低速のメディアプレイヤ機構でさえ、本発明のソフトウェアによって作成されたメディアコンテンツをレンダリングするとき、改善された再生体験をユーザに提供する。

本発明によれば、メタデータキャッシュは、メモリ効率のよい方法で編成された関連バイナリおよびテキストメタデータを含み、これによりメモリフットプリントをディスクのローディングおよびディスクの再生中のいつでも最小限にする。メモリ使用が最小限にされ、ローディングが完了した後かつ再生が開始する前にメモリを効率的に再生することができる。これにより、最大可能な量のメモリを、圧縮された音楽サンプルまたは他のメディアファイルを格納するために、レンダリング中に使用可能にすることができる。メモリ使用がさらに、再生デバイスの階層機能リストに基づいて最適化される。すなわち、最も単純なオーディオ専用デバイスは最低量のメモリを使用するが、より高能力のビデオプレイヤはより多くのメモリを使用することができ、さらに同じメディアがなお、そのデバイスのすべての機能をサポートする各デバイスにおいてプレイ可能である。

本発明の一態様によれば、ある方法がメディアプレイヤのオペレーションを最適化する。メディアプレイヤは、その上に格納されたメディアファイルをレンダリングするためにコンピュータ可読媒体にアクセスする。コンピュータ可読媒体はまた、メディアファイルに関連付けられたメモリ最適化データも格納する。この方法は、１つまたは複数の選択されたメディアファイルについてのメタデータを得る。この方法はまた、選択されたメディアファイルをレンダリングする前にメディアプレイヤによってアクセス可能であるデータ構造も作成する。この方法はまた、作成されたデータ構造を、前記得られたメタデータによりポピュレートする。この方法はまた、ポピュレートされたデータ構造をコンピュータ可読媒体上で、選択されたメディアファイルと共に格納する。

本発明の一態様によれば、メディアオーサリングツールにおける１つまたは複数のコンピュータ可読媒体は、メディアプレイヤのオペレーションを最適化するためのコンピュータ実行可能コンポーネントを有する。メディアプレイヤは、その上に格納されたメディアファイルをレンダリングするためにコンピュータ可読媒体にアクセスする。コンピュータ可読媒体はまた、メディアファイルに関連付けられたメモリ最適化データも格納する。このコンポーネントは、１つまたは複数の選択されたメディアファイルについてのメタデータを得るための準備モジュールを含む。このコンポーネントはまた、選択されたメディアファイルをレンダリングする前にメディアプレイヤによってアクセス可能であるように適合されたデータ構造を作成するための初期化モジュールも含む。このコンポーネントはまた、初期化モジュールからの作成されたデータ構造を、準備モジュールからの得られたメタデータによりポピュレートするための編成モジュールも含む。このコンポーネントはまた、編成モジュールからのポピュレートされたデータ構造をコンピュータ可読媒体上で、選択されたメディアファイルと共に格納するためのライタモジュールも含む。

本発明のもう１つの態様によれば、ある方法がメディアプレイヤのオペレーションを最適化する。メディアプレイヤは、その上に格納されたメディアファイルをレンダリングするためにコンピュータ可読媒体にアクセスする。コンピュータ可読媒体はまた、メディアファイルに関連付けられたメモリ最適化データも格納する。この方法は、メディアファイルをレンダリングする前に、コンピュータ可読媒体上に格納されたメモリ最適化データを検索する。メモリ最適化データが、コンピュータ可読媒体上に格納された１つまたは複数の選択されたメディアファイルに関連付けられる。この方法はまた、検索されたメモリ最適化データに応答して、選択されたメディアファイルを識別する。選択されたメディアファイルが、メディアプレイヤによってレンダリングされるように適合される。

本発明のさらにもう１つの態様によれば、メディアプレイヤは、メディアプレイヤのオペレーションを最適化するためのコンピュータ実行可能コンポーネントを格納する、１つまたは複数のコンピュータ可読媒体を有する。メディアプレイヤは、その上に格納されたメディアファイルをレンダリングするためにコンピュータ可読媒体にアクセスする。コンピュータ可読媒体はまた、メディアファイルに関連付けられたメモリ最適化データも格納する。このコンポーネントは、メディアファイルをレンダリングする前に、コンピュータ可読媒体上に格納されたメモリ最適化ファイルを検索するための入力モジュールを含む。メモリ最適化データが、コンピュータ可読媒体上に格納された１つまたは複数の選択されたメディアファイルに関連付けられる。このコンポーネントはまた、入力モジュールからの検索されたメモリ最適化データに応答して、選択されたメディアファイルを識別するためのフィルタモジュールも含む。選択されたメディアファイルが、メディアプレイヤによってレンダリングされるように適合される。

本発明のさらにもう１つの態様によれば、コンピュータ可読媒体は、その上に格納された１つまたは複数のメディアファイルに関連付けられたメモリ最適化データを表すデータ構造を、その上に格納している。メモリ最適化データは、メディアプレイヤのオペレーションを最適化する。メディアプレイヤは、メディアファイルをレンダリングするためにコンピュータ可読媒体にアクセスする。データ構造は、１つまたは複数のメディアファイルに関連付けられたテキストおよびバイナリデータへの参照を格納する、オフセットフィールドを含むヘッダを含む。データ構造はまた、ディレクトリ番号を、メディアファイルに関連付けられたディレクトリ名と合致させる、ディレクトリテーブルも含み、ヘッダは、ディレクトリ番号によりメディアファイルを参照する。

別法として、本発明は様々な他の方法および装置を備えることができる。

他の特徴は、以下で部分的に明らかになり、部分的に示されるであろう。

対応する参照文字は、図面の全体にわたって対応する部分を示す。

本発明はアクセラレータファイル、アクセラレータデータ、メモリ最適化データなどを使用して、改善されたメディアプレイヤ体験を起動時にユーザのために、コンパクトバイナリ表現における１つまたは複数のメディアファイルおよびプレイリストからメタデータ情報をキャッシュすることによって提供する。コンパクト表現を、通常のポータブルＣＤプレイヤまたはＤＶＤプレイヤなどに見られるものなど、比較的低能力の中央処理装置（ＣＰＵ）によって直接、容易に操作することができる。メモリ最適化データは、本明細書ではアクセラレータファイルとも呼ばれ、制限されたメニューシステムも提供し、これによりプレイヤが、見るものまたはプレイするものの選択に関してあるＰＣのような機能性を提供することができる。たとえば、メニューは「アルバム」、「アーティスト」、「ジャンル」選択を提供することができ、これらが適切な項目によってグループ化されたプレイリストにつながる。別法として、メニューは、ディスク上に格納された３つのセットのホリデーフォトのうち１つを示すことを提供することができる。

本発明は、データ構造を作成するため、かつ、作成されたデータ構造を、得られたメタデータによりポピュレートするためのオーサリングソフトウェアを含む（図２を参照）。本発明はまた、メタデータをデータ構造から検索するため、かつ、レンダリングするためのメディアファイルを識別するためのレンダリングソフトウェアも含む（図４を参照）。一実施形態では、本発明のソフトウェアは、圧縮メディアフォーマットの一部として動作可能であり（図５を参照）、これは、機能が豊富なパーソナルコンピュータのメディアプレイヤならびに低コストのメディアプレイヤ上で再生するために設計された、コンパイルされたバイナリフォーマットにおけるメタデータ、メニューおよびプレイリストを含む小型ファイルのセットを有する。たとえば、通常のローエンドポータブルＣＤプレイヤは、１００キロバイトほどの作業メモリ、わずか１メガヘルツで実行する８ビット中央処理装置、および非常に低速で最大シーク時間がほぼ５秒のＣＤドライブ機構を有する可能性がある。

メディア環境
このとき図面を参照すると、図１は、本発明を使用することができる例示的マルチメディア環境を例示する。システム１００は１つまたは複数のコンピュータ１０２を有し、これが、メディアコンテンツを提供する１つまたは複数のデバイスに結合される。たとえば、このデバイスはＣＤ１０４、カムコーダ１０６またはカメラ１０８を含むことができる。

一実施形態では、コンピュータ１０２はメディアコンテンツを、家電デバイス１１２に関連付けられたメディアプレイヤプログラムによって使用するために、コンピュータ可読媒体１１０上に格納する。家電デバイス１１２には、いずれかの適切なレンダリングフィルタまたはメディアプレイヤ、または、デジタルメディアをレンダリングして、メディア１１０上で実施されるコンテンツをユーザが体験できるように構成されるデバイスが含まれる。たとえば、適切なメディアプレイヤアプリケーションには、ＣＤメディアプレイヤおよびＤＶＤメディアプレイヤが含まれる。

本発明では、メディアプレイヤ、家電デバイス１１２などを、メディアプレイヤの機能に従って３つの例示的レベルに編成することができる。各メディアプレイヤは、メディアプレイヤがレンダリングすることができるメディアのタイプを識別するメディアタイプを有する。たとえば、メディアタイプ（プレイリストサマリタイプ、メニューサマリタイプなどとも呼ばれる）には、オーディオ、ビデオおよび静止画像のうち１つまたは複数が含まれる。レベル１のメディアプレイヤには、ポータブルＣＤプレイヤ、カーレシーバおよびＤＶＤプレイヤなど、オーディオ専用プレイヤが含まれる。レベル１のメディアプレイヤに加えて、レベル２のメディアプレイヤには、オプショナルで画像をオーディオと共に同時にレンダリングすることができるポータブルおよびセットトップＤＶＤプレイヤを含む、オーディオおよび静止画像可能プレイヤが含まれる。レベル３のメディアプレイヤには、レベル２のメディアプレイヤおよびオーディオ、静止画像およびビデオ可能プレイヤが含まれる。例示的家電デバイス１１２には、それだけに限定されないが、ポータブルＣＤプレイヤ、ＭＰ３プレイヤ、自動車内のオーディオシステム、携帯情報端末、携帯電話などが含まれる。

本発明のソフトウェアおよびデータ構造は、それだけに限定されないが、メディアプレイヤおよびメディアオーサリングシステムを含むシステムにおいて動作可能である。本発明による例示的家電デバイス１１２またはメディアプレイヤは、１つまたは複数のコンピュータ可読媒体を有し、これはメディアプレイヤのオペレーションを最適化するためのコンピュータ実行可能コンポーネントを格納する。メディアプレイヤはコンピュータ可読媒体にアクセスして、メディア上に格納されたメディアファイルをレンダリングする。コンピュータ可読媒体はさらに、メディアファイルに関連付けられたデータを最適化するメモリを格納する。メディアプレイヤのコンポーネントには、入力モジュール１１４およびフィルタモジュール１１６が含まれる。入力モジュール１１４は、メディアファイルをレンダリングする前に、コンピュータ可読媒体上に格納されたメモリ最適化データを検索する。メモリ最適化データは、コンピュータ可読媒体上に格納された１つまたは複数の選択されたメディアファイルに関連付けられる。フィルタモジュール１１６は、選択されたメディアファイルを、入力モジュール１１４からの検索されたメモリ最適化データに応答して識別する。選択されたメディアファイルは、メディアプレイヤによってレンダリングされるように適合される。メモリ最適化データがテキストおよびバイナリデータを含む一実施形態では、メディアプレイヤはユーザインターフェイスモジュール１１８を含み、これは、選択されたメディアファイルのレンダリング中に、メモリ最適化データがそれに関連付けられる、選択されたメディアファイルと関連して、少なくとも一部のテキストデータを表示するためのものである。メモリ最適化データがメディア上に存在しないとき、メディアプレイヤは、メディア上に存在する実際のメディアファイルの順次再生を提供する。

プレイリスト
プレイリストは、コンピュータ可読媒体上のオーディオ、ビデオおよびイメージファイルのグループを編成するための好都合な方法である。プレイリストは、それだけに限定されないが、メディアファイル、オーディオファイルのグループ、ビデオファイルのグループ、タイムドイメージシーケンスのグループ、および、オーディオまたはオプショナルでビデオを有する画像の様々な複雑な並列組合せのグループのうち１つまたは複数を含むことができる。たとえば、ユーザは、異なるパフォーマまたは異なる種類の音楽またはビデオについてのプレイリストを作成することができる。ユーザはまた、作成されたプレイリストを、プレイリストのコンテンツをシャッフルまたは繰り返すことによって操作することもできる。プレイリストはメニューにおいて存在することができ、これによりユーザが容易に、メディア上に存在するメディアファイルのリストをナビゲートおよび閲覧することができ、レンダリングするプレイリストを選択することができる。

オーサリングソフトウェア
次に図２を参照すると、本発明のオーサリングソフトウェアは、データ構造を作成およびポピュレートして、メディアプレイヤのオペレーションを最適化する。２０２から進んで、入力メディア上の各入力メディアファイルについて、２０４でオーサリングソフトウェアが、入力メディアファイルがオーディオデータ、ビデオデータ、イメージデータまたはプレイリストを含むかどうかを判断する。入力メディアファイルがこのようなデータを含む場合、２０６でメタデータが入力メディアファイルから、グループの定義で使用するために得られる。メタデータは、それだけに限定されないが、プレイリスト、サムネイル画像、メニュー構造または言語選択を含む。２０２で判断されたように、入力メディア上にそれ以上のファイルがない場合、２０８で、オーサリングソフトウェアがメタデータを、１つまたは複数の選択されたメディアファイルについて得る。メタデータは、メディアファイルなどのソースから、あるいはインターネットなどのネットワークを介してサーバから得られる。２１０でオーサリングソフトウェアが、メディアファイルをレンダリングする前にメディアプレイヤによってアクセスするように適合されたデータ構造を作成し、２１２で、作成されたデータ構造を、得られたメタデータによりポピュレートする。加えて、２１４でオーサリングソフトウェアが、ポピュレートされたデータ構造をコンピュータ可読媒体上に格納する。一実施形態では、１つまたは複数のコンピュータ可読媒体は、図２に例示する方法を実行するためのコンピュータ実行可能命令を有する。

図３に例示するマルチセッションコンピュータ可読媒体を有する一実施形態では、オーサリングソフトウェアが、ポピュレートされたデータ構造をメディア上の最後のセッションとして格納する。図３では、メディアファイル３０２および加速データ３０４がメディア上に、４つのセッション（セッション１、２、３、４）により格納される。本発明のレンダリングソフトウェアは、セッション４（すなわち、メディア上の最後のセッション）に格納されたアクセラレータデータ３０４にアクセスする。

メモリ最適化データがメディア（図示せず）上の最後のセッション内にない場合、レンダリングソフトウェアは、レンダリング中にメディア上のすべてのセッション内のメモリ最適化データを無視する。これにより、メモリ最適化データおよびメディアファイルがコヒーレントであることが保証される。

オーサリングソフトウェアは、メモリを最適化するための追加の機能を実行する。オーサリングソフトウェアは数値識別子を、選択されたメディアファイルに関連付け、ここにおいて数値識別子は順番に順序付けされる。数値識別子の各々が、メディアファイルの各々に対応する。オーサリングソフトウェアは、メディアファイルに関連付けられたファイル名の代わりにデータ構造における数値識別子を参照して、メモリ使用を低減する。加えて、オーサリングソフトウェアはメディアファイルをディレクトリにより編成し、編成されたメディアファイルを、メディア上のファイルシステムによって使用されたものと同じアルゴリズムを使用して（ファイル名により）ソートして、メディアファイルの探索を容易にする。類似の方法で、オーサリングソフトウェアは数値識別子を、メディアファイルの１つへの各パスにおける各ディレクトリ名について決定する。オーサリングソフトウェアはディレクトリ名を、決定された数値識別子で置き換える。一実施形態では、オーサリングソフトウェアはメディアファイルを、サポートされたフォーマット、および、圧縮器および圧縮解除器（コーデック）に圧縮または変換し、これはすでにサポートされたファイルフォーマットおよびコーデックでない場合に行う。圧縮メディアファイルもまたコンピュータ可読媒体上に格納される。

オーサリングソフトウェアは、いずれかの共通プレイリストフォーマットにおける各ユーザ供給プレイリストを読み取り、このフォーマットには、それだけに限定されないが、Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐレイヤ３（ＭＰ３）、Ａｄｖａｎｃｅｄ Ｓｔｒｅａｍｉｎｇ Ｆｏｒｍａｔ（ＡＳＦまたはＡＳＸ）、またはＷＩＮＤＯＷＳ（登録商標）ブランドのオペレーティングシステムのプレイリスト（ＷＰＬ）フォーマットが含まれる。各プレイリストが数値フォーマットに、上述のように割り当てられた数値識別子を使用して変換され、再生中のメモリ使用がさらに最適化される。数値プレイリストもまたコンピュータ可読媒体上に格納される。

オーサリングソフトウェアはオプショナルで、各メニュー、プレイリストまたはメディアファイルについてのサムネイルを作成する。大きい画像が小さいサムネイルとしてメニュー表示用にレンダリングされ、メディア上のメディアファイルのナビゲーションおよび再生中のメモリおよび中央処理装置（ＣＰＵ）使用がさらに最適化される。サムネイルもまたコンピュータ可読媒体上に格納され、言語選択を再生時間に行うことができるようになる。

メディアオーサリングツールの実施形態では、１つまたは複数のコンピュータ可読媒体が、メディアプレイヤのオペレーションを最適化するためのコンピュータ実行可能コンポーネントを有する。このコンポーネントには、準備モジュール、初期化モジュール、編成モジュールおよびライタモジュールが含まれる。準備モジュールは、１つまたは複数の選択されたメディアファイルについてのメタデータを得る。初期化モジュールは、メディアファイルをレンダリングする前にメディアプレイヤによってアクセスするように適合されたデータ構造を作成する。編成モジュールは、初期化モジュールからの作成されたデータ構造を、準備モジュールからの得られたメタデータによりポピュレートする。ライタモジュールは、編成モジュールからのポピュレートされたデータ構造をコンピュータ可読媒体上に格納する。

一実施形態では、メタデータキャッシュのメモリおよびディスク読み取りの最適化が、テキストおよびバイナリメタデータを異なるキャッシュファイルに分離することによって実施される。この分離は結果として最適化となり、これはテキストメタデータが大きく、特定のプレイリストまたはメディアファイルの再生が開始するまで必要とされないからである。バイナリメタデータのすべてが単一のファイル（たとえば「ＣＯＮＴＥＮＴＳ．ＨＭＴ」）に含まれるが、テキストメタデータは別のファイル（たとえば「ＴＥＸＴ．ＨＭＴ」）に格納される。もう１つの最適化は、バイナリメタデータキャッシュの実際のレイアウトである。ＣＯＮＴＥＮＴＳ．ＨＭＴにおける情報がいくつかのセクションに編成される（付録Ａの図９を参照）。一般に、テキストおよびバイナリメタデータはアクセラレータデータ、メモリ最適化データなどと呼ばれる。

オーサリングソフトウェアまたはディスク作成ソフトウェアは、追加のデータをディスク上に格納することができ、これは、メニューに何を入れるかについてのいずれかの以前のユーザの決定を保持し、後にさらにデータがディスク追加されるときに再提示することができるようにするためである。たとえば、ユーザが、写真を「月毎に」表示するためのメニューオプションがないべきであることを決定した場合、その選択をディスク上で持続させることができる。このような持続性ファイルを、アプリケーションに特化したものにすることができる。

アクセラレータファイルは２つのカテゴリに分割され、すなわち、大抵は全体的または部分的にメモリ内で常に保持されるであろうファイル、および、必要とされるときにのみロードされるファイル（たとえば、メニューおよびプレイリスト）である。アクセラレータファイル内の情報は、オーディオデータ、イメージデータおよびビデオデータの順序で編成されて、許可された再生デバイスの３つのレベルに合致するようにされる。一実施形態では、オーディオ専用プレイヤは、それがプレイすることができないファイルについてのものであるキャッシュファイルの一部においてロードしなくてもよくなる。

アクセラレータファイル内の情報もまた２つのカテゴリに分割され、すなわち、大抵は全体的または部分的にメモリ内で常に保持されるであろう情報、および、起動中にのみ必要とされ、再生中にメモリから廃棄することができる情報である。たとえば、ＣＯＮＴＥＮＴＳ．ＨＭＴファイルでは、情報がファイル名と共に各ファイルテーブル（たとえば、以下で説明するオーディオ、メニュー画像、画像およびビデオ）の最後に編成され、これは、ファイル名をファイルシステムと合致させるプロセスが完了された後（プレイヤがそれを起動時に行うように選択すると仮定する）、これらをメモリから廃棄することができるからである。アクセラレータファイルをさらにメモリにおいてプレイヤによってコンパクト化することができ、これは、メディアファイルを互換性についてチェックするためにのみ使用される項目を廃棄することによって行う。たとえば、各オーディオファイルのビットレートおよびサンプルサイズがプレイヤによってチェックされた後、これらはもはやメモリで必要とされない。

各メディアファイルを一意の番号としてディスク上のすべての他の構造（メニューおよびプレイリスト）内で表すことによって、再生中のメモリ使用がさらに最小限にされる。キャッシュファイルの作成において、オーサリングソフトウェアは変換をより効率的にし、これはキャッシュ内のファイルを最初に、それらを含むディレクトリにより、次いでアルファベット順に、あるいはメディア上のファイルシステムによって使用されたものと同じアルゴリズムを使用して（ファイル名により）、ソートすることによって行う。これは、ＩＳＯ ９６６０ Ｊｏｌｉｅｔメディア上のファイルシステムレコードと同じ順序であり、そのためプレイヤは、Ｏ（ｎ ｌｏｇ ｎ）またはより悪いアルゴリズムではなく、単純なＯ（ｎ）探索アルゴリズムを行うことができる。

キャッシュファイルの先頭はディレクトリテーブルであり、そこで各ディレクトリについてのテキスト名がそのディレクトリ番号のための数値識別子に変換される。ディレクトリへのすべての参照はこのテーブルを介して行われ、したがってすべてのパス名がコンパクト数値表現までコンパクト化される。各ディレクトリが多数のファイルを含んでいるので、この構造はまた、ファイルおよびディレクトリ命名構造全体を表すための極めてコンパクトな方法も表す。

たとえば、ファイル１を「＼ＤｉｒＡ＼ＤｉｒＢ＼ＤｉｒＣ＼ファイル１」として格納することができ、ファイル２を「＼ＤｉｒＡ＼ＤｉｒＢ＼ＤｉｒＤ＼ファイル２」として格納することができる。これらのディレクトリパスをコンパクト化するために、以下の表は各ディレクトリコンポーネントを数値識別子で置き換える。

次いで、ファイル１へのディレクトリパスを単に「４」として識別することができ、これをトレースバックしてディレクトリ１−２−３−４を通じたフルパスを生成することができ、ファイル２へのディレクトリパスを単に「５」として識別することができ、これを１−２−３−５へトレースバックすることができ、結果としてメモリが節約される。

本発明では様々な手段を使用して、メディア上のメタデータキャッシュとメディアコンテンツの間のコヒーレンシーを保証する。たとえば、本発明のソフトウェアは、メディア上の最後のセッション内にないメタデータキャッシュファイルを無視し、ファイルの２つを共に結合する一意のランダム識別子を検証する。

メディアファイルについての論理セクタ番号
ＣＯＮＴＥＮＴＳ．ＨＭＴで解決されるもう１つの問題は、家電デバイスがメディア上の特定のファイルを再生のために位置付けることを容易にする方法である。パーソナルコンピュータ（ＰＣ）上で、ソフトウェアは単に、メモリ内にキャッシュされたファイルシステムにおけるファイル名をルックアップする。家電デバイスは、ファイルシステム全体を保持するために十分なランダムアクセスメモリを有していない可能性がある。したがって、メディア上のファイルを位置付けるためにファイルシステムのいくつかのブロックのシーク／読み取りがひどく遅い。家電デバイスがファイルを発見するための最も効率的な方法は、ファイルの論理セクタ番号（ＬＳＮ）をメタデータと共に格納することである。メディア上の各ファイルについてのＬＳＮおよびファイル長を格納するオプショナルのアクセラレータファイルにより、再生の高速な起動、および、メディアプレイヤのためのより低いメモリ要件が可能となる。しかし、ＬＳＮアクセラレータファイルはオプショナルであり、これはオーサリングソフトウェアのすべての実施が、ファイルを書き込む前に各ファイルのＬＳＮおよび長さを決定することができる可能性があるとは限らないからである。たとえば、ＬＳＮをキャッシュにオーサリングすることは、厳密に階層化されたアーキテクチャを有し、それによりファイルシステムがメディアのレイアウトから分離されるＰＣでは、必ずしも可能とは限らない。加えて、ファイルが異なるメディア上に更新、移動またはコピーされる場合、これらのオフセットが無効にされる。

メディアを単一のパスで書くか、あるいは、ファイルシステムの下のオペレーティングシステムのレベルで動作するオーサリングソフトウェアでは、本発明により、特殊なＬＳＮキャッシュファイルをメディア上に配置させることができる。メディア上の各ファイルについてのＬＳＮおよびファイル長を格納する、オプショナルのＬＳＮキャッシュファイル（たとえば、アクセラレータファイル）により、再生の高速な起動が可能となる。ＬＳＮファイルは、メディア上のアクセラレータファイルによって参照される各ファイルについての論理セクタ番号を含む。オーサリングソフトウェアは、ファイルを書き込む前に各ファイルのＬＳＮおよびファイル長を決定することができる。このファイルがメディア上の最後のセッション内に存在するとき、それがＣＯＮＴＥＮＴＳファイルに合致するとすれば（複数のファイルの間で合致された一意のランダムな世代番号によって検証される）、メディアプレイヤはこのファイルを使用して、メディア上に存在するあらゆるメディアファイルを位置付けることができ、プレイヤはファイルシステムを読み取りまたは解析してメディアファイルを位置付ける必要がない。

プレイヤは通常、アクセラレータファイル内のファイル名をＬＳＮへ、起動中に解決し、ファイルシステム全体を読み取ってテーブルをメモリ内で作成し、ファイル番号を各ファイルの開始ＬＳＮおよびバイト長についての値にマッピングする。一実施形態では、ＬＳＮキャッシュファイルが、他のアクセラレータファイルが作成された後に実行する別のメーカ提供ソフトウェアを使用して作成される。すべてのプレイヤは、この追加の加速ファイルが存在するかどうかにかかわらず、メディアをプレイする。十分に高速なドライブ機構を有するプレイヤはこの起動手順を回避して、単にディスク再生中にファイル毎のベースでファイル名を解決することができる。

このようなファイルの周囲にはいくつかの問題があり、これには、このようなメディアのファイルコピーが結果としてプレイ不可能なメディアとなる可能性が高いという事実が含まれる。このようなファイルを実施するように選択するプレイヤは、ファイル内のデータを利用する前にその妥当性をチェックするべきである。いずれかのＬＳＮが、メディア上にあるように現れないファイルをポイントした場合、ＬＳＮファイル全体を廃棄するべきであり、プレイヤはファイルシステムの読み取りに戻って、ファイルについてのＬＳＮおよびバイト長をルックアップするべきである。本発明のソフトウェアによるＬＳＮファイルの例示的実施態様については、付録Ａを参照されたい。

レンダリングソフトウェア
次に図４を参照すると、レンダリングソフトウェアはメディアプレイヤのオペレーションを最適化する。４０２でファイルシステムをロードした後、４０４でレンダリングソフトウェアが、入力メディアが有効なメディア（たとえば、アクセラレータデータを含むメディア）であるかどうかを判断する。４０６でレンダリングソフトウェアが、メディアファイルをレンダリングする前に、コンピュータ可読媒体上に格納されたメモリ最適化データを検索する。メモリ最適化データは、コンピュータ可読媒体上に格納された１つまたは複数の選択されたメディアファイルに関連付けられる。４０８でレンダリングソフトウェアが、選択されたメディアファイルを、検索されたメモリ最適化データに応答して識別する。選択されたメディアファイルは、メディアプレイヤによってレンダリングされるように適合される。選択されたメディアファイルを、コンピュータ可読媒体上で使用可能な複数のメディアファイルのサブセットにすることができる。メモリ最適化データがテキストおよびバイナリデータを含む一実施形態では、レンダリングソフトウェアが少なくとも一部のテキストデータをメディアプレイヤによって、選択されたメディアファイルのレンダリング中に、メモリ最適化データがそれに関連付けられる、選択されたメディアファイルと関連して、表示する。レンダリングソフトウェアは、選択されたメディアファイルに関連付けられたメタデータを、メモリ最適化データを介して得て、得られたメタデータをユーザへ、メディアプレイヤに関連付けられたディスプレイ上で表示する。一実施形態では、１つまたは複数のコンピュータ可読媒体は、図４に例示した方法を実行するためのコンピュータ可読命令を有する。

プレイヤは通常、起動中にアクセラレータファイル内のファイル名をＬＳＮに解決し、ファイルシステム全体を読み取ってテーブルをメモリ内で作成し、ファイル番号を各ファイルの開始ＬＳＮおよびバイト長についての値にマッピングする。十分に高速なドライブ機構を有するプレイヤはこの起動手順を回避して、単にディスク再生中にファイル毎のベースでファイル名を解決することができる。

４１０で、有効なＬＳＮファイルがメモリ最適化データにおいて存在した場合、レンダリングソフトウェアがＬＳＮファイルをロードし、４１４に進行して、選択されたメディアファイルをレンダリングする。４１０で、特殊なＬＳＮキャッシュファイルが存在しないか、あるいは有効でないとき、４１６で、プレイヤがファイルシステムを読み取って、ＣＯＮＴＥＮＴＳファイル内のファイル名をＬＳＮに変換しなければならない。

本発明では、ＣＯＮＴＥＮＴＳファイル内の各ファイルテーブルが、オフセットを有するバイナリメタデータのリストとして、バイナリメタデータの後に続くテキストファイル名のリストに編成される。これにより、プレイヤがバイナリメタデータのみをメモリに最初にロードすることができ、次いでファイル名を増分的に読み、各ブロックが処理されるときにこれを廃棄することができる。ファイルシステムを類似の方法でメモリ内に保持し、ＣＯＮＴＥＮＴＳファイル内のファイル名に対して増分的に合致させることができ、あるいはファイルシステムを増分的に読み取って、ＣＯＮＴＥＮＴＳファイルのメモリ内コピーに対して処理することができる。非常に小さいメモリを有するプレイヤはＣＯＮＴＥＮＴＳファイルおよびファイルシステムを増分的に読むこともできるが、かなり低速である可能性がある。

ファイルシステムがＣＯＮＴＥＮＴＳファイル内のファイル名と合致させられるとき、ファイル名への各４バイトオフセットをＬＳＮで置き換えることができ、次いでファイル名をメモリから廃棄することができる。したがって、本発明はメモリを効率的に再利用し、メモリからメモリへのコピーオペレーションの数を最小限にし、そうでない場合は、ファイル名合致プロセスが完了された後にメモリ内のデータ構造をコンパクト化することが必要とされる可能性がある。プレイヤが起動プロセスのこの段階を完了した後、４１６で、ファイル名テーブルおよびファイルシステム全体をメモリから廃棄することができ、プレイヤに残されるものは、例示的実施形態では、オーディオファイルにつき３２バイト、画像ファイルにつき１６バイト、およびビデオファイルにつき４４バイトである。レンダリングソフトウェアが４１４に進んで、選択されたメディアファイルをレンダリングする。最終的に、起動段階が完了した後、単一の番号を使用していかなるメディアファイルをも参照することができ、プレイヤは容易に、非常にコンパクトなメモリ内構造から、そのファイルについてのバイナリおよびテキストメタデータ、およびそのファイルについてのＬＳＮにアクセスすることができる。ファイル長またはサイズは、メモリテーブル内の別のフィールドに格納される。

４０４で、入力メディアがメモリ最適化データを含んでいなかった場合、４２０でレンダリングソフトウェアが入力メディアをファイルについてスキャンし、４１４でメディア上のいずれかのファイルをレンダリングする。

メタデータおよびメニュー表示
本発明によるレンダリングソフトウェアを有するメディアプレイヤは、再生中にメタデータ情報を表示する。本発明のレンダリングソフトウェアは、メタデータを表示のために得るための少なくとも２つの方法を有し、すなわち（ｉ）アクセラレータファイルから、および（ｉｉ）メディア上の実際のメディアファイルからである。一般に、実際のメディアファイルは、アクセラレータファイルに含まれたメタデータの最小セットよりも幅広い種類のメタデータを含むようになる。いくつかのメディアプレイヤは、この追加のメタデータを露出するように選択することができ、たとえば、音楽ファイルについての歌詞、アルバム、年またはジャンル、または静止画像について「取られたデータ」を示す。メディアプレイヤはメタデータ内のすべてのアルファベット、数字、スペースおよびハイフンを表示するが、表示することができない他の文字を変換または省略することができる。たとえば、いくつかの文字表示は完全文字セットを表示できない可能性がある。

一実施形態では、英数字表示を有するメディアプレイヤはユーザに、再生中に少なくとも音楽ファイルについてのアーティストおよびタイトルを表示する可能性を提供するべきである。アーティストタグまたはタイトルタグのない音楽ファイルは、それらがそのフィールドについて空タグを有するかのように処理される。一実施形態では、メディアプレイヤはメタデータを切り捨てるのではなく、メタデータをスクロールする。しかし、メディアプレイヤは、メモリ要件が決定するように、メタデータを少なくとも３３文字に切り捨てることができる。

本発明のソフトウェアによる加速再生メディア上のメニューは、サブメニューおよびプレイリストの単一の階層構造を含む。メニューツリーは、たとえばオプショナルの全体制限の合計ノード９，９９９以内で任意の深さ、任意の幅にすることができる。他の実施形態は、メニューツリーに関する他の、あるいは異なる制限を実施することができる。大抵のメディアプレイヤは、メディアが挿入されるとき、トップレベルメニューを表示する。しかし、カーレシーバは起動時にメニューをバイパスすることを選択して、メディア上の最初のプレイリストにより直ちに再生を開始することができ、あるいは先にプレイ中であったソングおよびプレイリストで再生を再開することができる。一実施形態では、メニューがフィルタリングされて、プレイヤが表示またはプレイすることができるメニュー項目のみが表示される（たとえば、オーディオ専用プレイヤはすべての画像およびビデオメニューエントリを除去して、純粋なオーディオ選択のみを表示する）。

本発明のレンダリングソフトウェアを様々な特徴と共に実施することができる。たとえば、各メニューは最大９，９９９エントリまで含むことができ、いくつかのメディアプレイヤはメニューのスクローリングまたはページ分けされたビューを表示することができる。ＴＶに接続されたプレイヤは、サムネイルメニューまたは単純なリストメニューを表示することができる（たとえば、現在のメニュー内のプレイリストまたはメニューなどのエントリがサムネイルを有するかどうかに基づく）。一実施形態では、ＴＶに接続されたプレイヤは、サムネイルが現在のメニュー内のあらゆるエントリについて存在する（すなわち、ゼロでないエントリ）ときにのみ、サムネイルメニューを表示する。画面上のサムネイルのレイアウトおよびページ毎に表示されたサムネイルの数は、プレイヤ依存である。いくつかのメディアプレイヤは連続スクローリングリストを表示するように選択することができ、他のメディアプレイヤはメニューにページ番号をつけて、次／前の選択を提供するように選択することができる。４：３のＴＶ受像機では、メディアプレイヤは３×２個のサムネイルのグリッドを表示する。１６：９のＴＶ受像機では、メディアプレイヤはその代わりに４×２のグリッドを表示するように選択することができる。プレイヤはメニュー項目の選択状態を指示する。これを行うことができる方法には多数の選択があり、プレイヤの機能によって決まる。豊富なユーザ体験に備えるために、メニューおよびプレイリストの項目は選択状態サムネイルを有する。サムネイルを表示することができるプレイヤはこのサムネイルを使用して、他の方法の代わりに選択を指示することができる。プレイヤはまたプレイリストまたはメニュー名も、関連付けられたサムネイルと共に表示する。プレイヤがすべてのサムネイルを即座に表示できない場合、テキストラベルが最初に表示され、サムネイルが１つずつ、復号化されるときに追加される。プレイヤは、ユーザが迅速に所与の項目にナビゲートできるようにするために、サムネイルの追加中でも次または前のページへのスクローリングを可能にすることができる。

本発明のメニュー表示はプレイヤ依存であり、各メーカがメニューを表示する方法を決定することができる。ポータブルＣＤプレイヤでは、たとえば、メニューを一度に一行表示することができ、次、前、プレイ／選択および停止ボタンを使用して、選択範囲中でナビゲートする。カーレシーバでは、再生がメディア上の最初のプレイリストで即時に開始することができる。次いで、ユーザは「メニュー」キーを押してメディアメニューを提示させ、次、前およびプレイ／選択を使用してこの中でナビゲートすることが必要となる。ＤＶＤプレイヤでは、オプショナルのサムネイルと共に、フルグラフィカル表示を完全に表示することができる。いくつかのＤＶＤプレイヤはメニュー項目に付番し、１〜９のキーをリモートコントロール上で使用するように選択することができるが、いくつかのＤＶＤプレイヤは単にメニュー項目をリストまたはグリッドフォーマットにおいて提示し、カーソルキーをナビゲーションおよび選択のために使用することができる。

例示的メディアコンテンツ環境
図５に例示するように、本発明は、例示的圧縮メディアフォーマット５０２の一部として動作可能であり、これは、機能が豊富なＰＣメディアプレイヤならびに低コストのメディアプレイヤ上で再生するために設計された、コンパイルされたバイナリフォーマットにおけるメタデータ、メニューおよびプレイリストを含む小型ファイルのセット５０４を有する。本発明の例示的圧縮メディアフォーマットは、様々なフォーマットにおけるオーディオ、静止画像およびビデオメディアファイル５０４を包含する。本発明と共に使用するための圧縮メディアフォーマットは、コンピュータ可読媒体５０８上のファイルシステム５０６における圧縮メディアファイルを編成するための論理フォーマットを定義し、コンピュータ可読媒体５０８は、光ディスク（たとえば、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＡＭ、ＤＶＤ−Ｒ、ＤＶＤ−ＲＷ、ＤＶＤ＋ＲＷ、ＤＶＤ＋Ｒ、ＤＶＤ−ＲＯＭ）、フラッシュメモリ（たとえば、ＣＯＭＰＡＣＴＦＬＡＳＨ（登録商標）ブランド、セキュアデジタル、ＭＥＭＯＲＹ ＳＴＩＣＫブランド）、磁気メディア（たとえば、ハードディスク）などである。

図６は、コンピュータ１３０の形式における汎用コンピューティングデバイスの一実施例を示す。本発明の一実施形態では、コンピュータ１３０などのコンピュータは、本明細書で例示し、説明した他の図面で使用するために適切である。コンピュータ１３０は、１つまたは複数のプロセッサまたは処理装置１３２およびシステムメモリ１３４を有する。例示した実施形態では、システムバス１３６は、システムメモリ１３４を含む様々なシステムコンポーネントをプロセッサ１３２に結合する。バス１３６は、いくつかのタイプのバス構造のいずれかの１つまたは複数を表し、これには、様々なバスアーキテクチャのいずれかを使用するメモリバスまたはメモリコントローラ、周辺バス、アクセラレーテッドグラフィックスポート、およびプロセッサまたはローカルバスが含まれる。例として、限定ではなく、このようなアーキテクチャには、業界標準アーキテクチャ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカルバス、およびメザニンバスとしても知られる周辺装置相互接続（ＰＣＩ）バスが含まれる。

コンピュータ１３０は通常、少なくともいくつかの形式のコンピュータ可読媒体を有する。コンピュータ可読媒体は、揮発性および不揮発性メディア、リムーバブルおよび非リムーバブルメディアを含み、これをコンピュータ１３０によってアクセスすることができるいかなる使用可能なメディアにすることもできる。例として、限定ではなく、コンピュータ可読媒体は、コンピュータ記憶メディアおよび通信メディアを含む。コンピュータ記憶メディアは、揮発性および不揮発性、リムーバブルおよび非リムーバブルのメディアを含み、これらはコンピュータ可読命令、データ構造、プログラムモジュールまたは他のデータなど、情報の格納のためのいずれかの方法または技術において実施される。たとえば、コンピュータ記憶メディアには、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光ディスク記憶、磁気カセット、磁気テープ、磁気ディスク記憶または他の磁気記憶デバイス、または、所望の情報を格納するために使用することができ、コンピュータ１３０によってアクセスすることができる他のいずれかのメディアが含まれる。通信メディアは通常、コンピュータ可読命令、データ構造、プログラムモジュール、または、搬送波または他の移送機構などの変調データ信号における他のデータを実施し、いずれかの情報配信メディアを含む。当業者は変調データ信号をよく知っており、これは、信号における情報を符号化するような方法でその特性の１つまたは複数が設定または変更されている信号である。ワイヤードネットワークまたはダイレクトワイヤード接続などのワイヤードメディア、および、音響、ＲＦ、赤外線および他のワイヤレスメディアなどのワイヤレスメディアが、通信メディアの例である。上記のいずれの組合せも、コンピュータ可読媒体の範囲内に含まれる。

システムメモリ１３４は、リムーバブルおよび／または非リムーバブル、揮発性および／または不揮発性メモリの形式におけるコンピュータ可読媒体を含む。例示した実施形態では、システムメモリ１３４は読み取り専用メモリ（ＲＯＭ）１３８およびランダムアクセスメモリ（ＲＡＭ）１４０を含む。基本入出力システム１４２（ＢＩＯＳ）は、起動中などにコンピュータ１３０内の複数の要素の間で情報を転送する助けとなる基本ルーチンを含み、通常はＲＯＭ１３８に格納される。ＲＡＭ１４０は通常、処理装置１３２によって即時アクセス可能および／または現在動作中であるデータおよび／またはプログラムモジュールを含む。例として、限定ではなく、図６は、オペレーティングシステム１４４、アプリケーションプログラム１４６、他のプログラムモジュール１４８およびプログラムデータ１５０を例示する。

コンピュータ１３０はまた、他のリムーバブル／非リムーバブル、揮発性／不揮発性のコンピュータ記憶メディアも含むことができる。たとえば図６は、非リムーバブル、不揮発性の磁気メディアに対する読み書きを行うハードディスクドライブ１５４を例示する。図６はまた、リムーバブル、不揮発性磁気ディスク１５８に対する読み書きを行う磁気ディスクドライブ１５６、および、ＣＤ−ＲＯＭまたは他の光メディアなど、リムーバブル、不揮発性の光ディスク１６２に対する読み書きを行う光ディスクドライブ１６０も示す。例示的オペレーティング環境で使用することができる他のリムーバブル／非リムーバブル、揮発性／不揮発性のコンピュータ記憶メディアには、それだけに限定されないが、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭなどが含まれる。ハードディスクドライブ１４４および磁気ディスクドライブ１５６および光ディスクドライブ１６０は通常システムバス１３６に、インターフェイス１６６などの不揮発性メモリインターフェイスによって接続される。

上述し、図６に例示したドライブまたは他の大容量記憶デバイス、およびそれらの関連付するコンピュータ記憶メディアは、コンピュータ１３０用のコンピュータ可読命令、データ構造、プログラムモジュールおよび他のデータの記憶装置を提供する。図６では、たとえば、ハードディスクドライブ１５４が、オペレーティングシステム１７０、アプリケーションプログラム１７２、他のプログラムモジュール１７４およびプログラムデータ１７６を格納するものとして例示される。これらのコンポーネントを、オペレーティングシステム１４４、アプリケーションプログラム１４６、他のプログラムモジュール１４８およびプログラムデータ１５０と同じものにも異なるものにもすることができることに留意されたい。オペレーティングシステム１７０、アプリケーションプログラム１７２、他のプログラムモジュール１７４およびプログラムデータ１７６にはここで異なる番号が与えられて、最低でも、それらが異なるコピーであることが例示される。

ユーザはコマンドおよび情報をコンピュータ１３０へ、キーボード１８０およびポインティングデバイス１８２（たとえば、マウス、トラックボール、ペンまたはタッチパッド）などの入力デバイスまたはユーザインターフェイス選択デバイスを通じて入力することができる。他の入力デバイス（図示せず）には、マイクロフォン、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナなどが含まれる可能性がある。これらおよび他の入力デバイスは処理装置１３２へ、システムバス１３６に結合されるユーザ入力インターフェイス１８４を通じて接続されるが、これを、パラレルポート、ゲームポートまたはユニバーサルシリアルバス（ＵＳＢ）など、他のインターフェイスおよびバス構造によって接続することができる。モニタ１８８または他のタイプの表示デバイスもシステムバス１３６へ、ビデオインターフェイス１９０などのインターフェイスを介して接続される。モニタ１８８に加えて、コンピュータはしばしば、プリンタおよびスピーカなど、出力周辺インターフェイス（図示せず）を通じて接続することができる他の周辺出力デバイス（図示せず）を含む。

コンピュータ１３０はネットワーク環境において、リモートコンピュータ１９４など、１つまたは複数のリモートコンピュータへの論理接続を使用して動作することができる。リモートコンピュータ１９４は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイスまたは他の共通ネットワークノードにすることができ、通常は、コンピュータ１３０に関連して上述した要素の多数またはすべてを含む。図６に示す論理接続は、ローカルエリアネットワーク（ＬＡＮ）１９６および広域ネットワーク（ＷＡＮ）１９８を含むが、他のネットワークも含むことができる。このようなネットワーキング環境は、オフィス、企業全体のコンピュータネットワーク、イントラネットおよびグローバルコンピュータネットワーク（たとえば、インターネット）において一般的である。

ローカルエリアネットワーキング環境において使用するとき、コンピュータ１３０がＬＡＮ１９６へ、ネットワークインターフェイスまたはアダプタ１８６を通じて接続される。広域ネットワーキング環境において使用するとき、コンピュータ１３０は通常、モデム１７８、またはインターネットなどのＷＡＮ１９８を介して通信を確立するための他の手段を含む。モデム１７８を内部または外部にすることができ、これはシステムバス１３６へ、ユーザ入力インターフェイス１９４または他の適切な機構を介して接続される。ネットワーク環境では、コンピュータ１３０に関して示したプログラムモジュールまたはその一部を、リモートメモリデバイス（図示せず）に格納することができる。例として、限定ではなく、図６はリモートアプリケーションプログラム１９２を、メモリデバイス上に存在するものとして例示する。図示のネットワーク接続は例示的であり、通信リンクを複数のコンピュータの間で確立する他の手段を使用できることは理解されよう。

一般に、コンピュータ１３０のデータプロセッサは、異なる時間にコンピュータの様々なコンピュータ可読記憶メディアに格納された命令を用いてプログラムされる。プログラムおよびオペレーティングシステムは通常、たとえばフロッピー（登録商標）ディスクまたはＣＤ−ＲＯＭにおいて配布される。そこから、これらがコンピュータの２次メモリにインストールまたはロードされる。実行時に、これらが少なくとも部分的にはコンピュータの１次電子メモリにロードされる。本明細書で説明した本発明は、これらおよび他の様々なタイプのコンピュータ可読記憶メディアが、以下で説明するステップをマイクロプロセッサまたは他のデータプロセッサと共に実施するための命令またはプログラムを含むとき、これらを含む。本発明はまた、コンピュータ自体が本明細書で説明した方法および技術に従ってプログラムされるとき、これも含む。

例示のため、オペレーティングシステムなど、プログラムおよび他の実行可能プログラムコンポーネントを本明細書で離散的ブロックとして例示する。しかし、このようなプログラムおよびコンポーネントが様々な時間にコンピュータの異なる記憶コンポーネント内に存在し、コンピュータのデータプロセッサによって実行されることを理解されたい。

コンピュータ１３０を含む例示的コンピューティングシステム環境に関連して説明したが、本発明は多数の他の汎用または専用コンピューティングシステム環境または構成により動作可能である。このコンピューティングシステム環境は、本発明の使用または機能性の範囲についていかなる限定も示唆するように意図されない。さらに、このコンピューティングシステム環境は、例示的オペレーティング環境において例示したコンポーネントのいずれか１つまたは組合せに関係するいかなる依存性または要件をも有するものとして解釈されるべきではない。本発明と共に使用するために適切である可能性のある周知のコンピューティングシステム、環境および／または構成の例には、それだけに限定されないが、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラマブルなコンシューマエレクトロニクス、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上のシステムまたはデバイスのいずれかを含む分散コンピューティング環境などが含まれる。

本発明を一般に、プログラムモジュールなど、１つまたは複数のコンピュータまたは他のデバイスによって実行されるコンピュータ実行可能命令に関連して説明することができる。一般に、プログラムモジュールには、それだけに限定されないが、特定のタスクを実行するか、あるいは特定の抽象データ型を実施するルーチン、プログラム、オブジェクト、コンポーネントおよびデータ構造が含まれる。本発明をまた分散コンピューティング環境において実施することもでき、ここではタスクが、通信ネットワークを通じてリンクされる複数のリモート処理デバイスによって実行される。分散コンピュータ環境では、プログラムモジュールは、メモリデバイスを含む、ローカルおよびリモートのコンピュータ記憶メディア内に位置することができる。

オペレーションにおいて、コンピュータ１３０は、図２に例示するものなどのコンピュータ実行可能命令を実行してデータ構造を作成し、作成されたデータ構造を、得られたメタデータによりポピュレートする。加えて、コンピュータ１３０は（メディアプレイヤの一部として）、図４に例示するものなどのコンピュータ実行可能命令を実行してメタデータをデータ構造から検索し、レンダリングするためのメディアファイルを識別する。

一実施形態では、アクセラレータファイルがメディア上で「ＨＩＧＨＭＡＴ」と呼ばれる最上位ディレクトリの下に存在し、図７に示すファイルシステムに例示する例示的ファイルを含む。アクセラレータファイルはメディア上で「ＨＩＧＨＭＡＴ」と呼ばれる最上位ディレクトリ下に存在し、以下のファイル、すなわちＣＯＮＴＥＮＴＳ．ＨＭＴ、ｎｎｎｎｎｎｎｎ．ＨＭＴ、ＭＥＮＵ．ＨＭＴおよびＴＥＸＴ．ＨＭＴを含む。ＣＯＮＴＥＮＴＳ．ＨＭＴファイルは、メディア上に存在するすべてのメディアファイルについての情報を含む。これはディレクトリテーブルとその後に続く、サポートされた各ファイルタイプ（オーディオ、ビデオ、画像およびプレイリスト）についてのファイルエントリテーブルを含む。メディア上の各プレイリストについて「ｎｎｎｎｎｎｎｎ．ＨＭＴ」と呼ばれる１つのファイルがあり、ｎｎｎｎｎｎｎｎは１６進プレイリストファイル識別子である。これらのプレイリストファイルは「ＰＬＡＹＬＩＳＴ」サブディレクトリに作成される。ＭＥＮＵ．ＨＭＴファイルはメニュー構造を含む。ＴＥＸＴ．ＨＭＴファイルは、再生中に必要とされたすべてのテキスト情報を含む。

代替実施形態では、以下のファイル、すなわち＜サムネイル＞．ＨＭＴおよび＜バックグラウンド＞．ＨＭＴが含まれる。各サムネイルについてメディア上に１つのファイルがある（たとえば、．ＨＭＴ拡張子を有する１６０×１２０ＪＰＧフォーマット）。オーサリングソフトウェアはファイルを適切に命名することができる。サムネイルファイルは「ＩＭＡＧＥＳ」サブディレクトリに作成される。各メニューバックグラウンドについてメディア上に１つのファイルがある。４：３の縦横比を有するバックグランドは、．ＨＭＴ拡張子を有する６４０×４８０ＪＰＧフォーマットである。１６：９の縦横比を有するバックグランドは、．ＨＭＴ拡張子を有する８５２×４８０ＪＰＧフォーマットである。オーサリングソフトウェアはファイルを適切に命名することができる。バックグラウンドファイルは「ＩＭＡＧＥＳ」サブディレクトリに作成される。

ＨＩＧＨＭＡＴディレクトリおよびその中のすべてのファイルに、ユーザの混乱を減らすために、メディアを作成するソフトウェアによって隠すようにマークを付けることができる。プレイヤは、これらのファイルおよびディレクトリが隠されるかどうかにかかわらず、メディアを処理するべきである。バイナリ構造のすべてが、リトルエンディアンのバイト順序を使用して符号化されるべきである。ファイルおよびディレクトリ名はビッグエンディアンのバイト順序を使用するべきである。プレイヤが未知の値に出会うとき、デフォルトの挙動を、合わないファイルを無視することにするべきである。たとえば、プレイリストサマリタイプが２５５に等しい場合、プレイリスト全体がスキップされるべきである。

多言語
本発明は多言語のメニューおよびテキストデータを単一の記憶メディア上でサポートする。これは、ロケール識別子（ＬＣＩＤ）の使用を通じて実施される。例示的ＬＣＩＤ８０２の構造を図８に例示する。より詳細に付録Ａで論じるように、アクセラレータファイル（たとえば、ＴＥＸＴ．ＨＭＴおよびＭＥＮＵ．ＨＭＴ）のファイルヘッダは、それらの言語を表すＬＣＩＤ８０２を含み、これらは合致しなければならない。ＣＯＮＴＥＮＴＳ．ＨＭＴは、この記憶メディア上の言語についてのＬＣＩＤのリストを含む。

メディアプレイヤは、ＬＣＩＤ８０２のリストにおける最初の項目をデフォルト言語として使用する。複数の言語が定義されている場合、プレイヤはプレイするためのＬＣＩＤ８０２をリストから選択するべきである（たとえば、メディアプレイヤの言語またはロケールに基づく）。プレイヤは対応するＴＥＸＴ．ＨＭＴおよびＭＥＮＵ．ＨＭＴを、これらのファイルについてのディレクトリ番号を使用することによってロードする。最初（デフォルト）のＬＣＩＤ８０２エントリは、ＣＯＮＴＥＮＴＳ．ＨＭＴの場所であるディレクトリ番号を有するべきであり、すなわち、デフォルト言語のＭＥＮＵ．ＨＭＴおよびＴＥＸＴ．ＨＭＴはＣＯＮＴＥＮＴＳ．ＨＭＴと同じディレクトリ内にある。

ＬＣＩＤ８０２自体はいくつかの部分を有し、最初の１０ビットは主要言語ＩＤ８０４であり、これは言語自体を含む。次の６ビットは副言語ＩＤ８０６を含み、これはしばしば、同じ主要言語ＩＤ８０４を共有する領域を区別するために使用される。次の４ビットはソートＩＤ８０８を表し、これは同じ言語および領域について使用することができる交互のソート順序の間で区別することができる。残りの１２ビットは将来の使用のために予約され、常にゼロであるべきである。たとえば、ＬＣＩＤ８０２は、より詳細に付録Ａで説明するＣＯＮＴＥＮＴＳ．ＨＭＴなどのファイルに格納することができる。

本発明のソフトウェアと共に使用するためのアクセラレータファイルの例示的構造に関する追加の詳細については、付録Ａを参照されたい。

本発明またはその実施形態の要素を紹介するとき、冠詞「ａ」、「ａｎ」、「ｔｈｅ」および「ｓａｉｄ」は、１つまたは複数の要素があることを意味するように意図される。「備える」、「含む」および「有する」という用語は包含的であるように意図され、列挙された要素以外の追加の要素が存在する可能性があることを意味する。

上記に鑑みて、本発明のいくつかの目的が達成され、他の有利な結果が達成されることがわかるであろう。

様々な変更を上記の構成、製品および方法に、本発明の範囲から逸脱することなく行うことができるので、上記の説明に含まれた、また、添付の図面に示すすべてのものが例示的として、限定する意味ではなく解釈されるべきであることが意図される。

付録Ａ
テキスト符号化
すべてのテキストデータはＵＣＳ−２ユニコードフォーマットで格納される。すべてのファイルおよびディレクトリ名は、それらがソースメディア上にあるときのケースを保持するべきである。リトルエンディアンのバイト順序が、ディレクトリおよびファイル名のうちビッグエンディアンのワードレイアウトを使用するべきであるものを除いて、指定されたすべてのワードレイアウトについて使用されるべきである。

ディレクトリネームのソート順序
ディレクトリテーブル内のエントリは、重要度の順序で適用された以下の基準を使用してソートされるべきである。
１）親ディレクトリ番号の相対値に従って昇順に。
２）２つのディレクトリが同じ親ディレクトリ番号を有する場合、これらの名前が、重要度の降順で以下の基準を使用してソートされるべきである。
２．１）２つのディレクトリ名がすべてのバイト位置で同じ値を有する場合、２つのディレクトリの値は等しい。
２．２）２つのディレクトリ名が同じ数のバイト位置を含まない場合、両方のディレクトリ名が同じ数のバイト位置を含むようになるまで、短い方のディレクトリ名が、すべて（００）に設定されたパディングバイトで右にパディングされる。
２．３）すべての必要なパディングを追加して、両方のディレクトリ名を等しい長さとして処理した後、ディレクトリ名の最初の位置で開始して、あるバイト位置が同じ値を含まないことが判明するまで、両方のバイト値が比較される。より高いコード位置の値を有するディレクトリ名がより大きい名前である。

ファイル名のソート順序
ファイル名テーブル内のエントリは、重要度の順序で適用された以下の基準を使用してソートされるべきである。
３）親ディレクトリ番号の相対値に従って昇順に。
４）２つのファイルが同じ親ディレクトリ番号を有する場合、これらの名前が、重要度の降順で以下の基準を使用してソートされるべきである。
２．１）２つのファイル名がすべてのバイト位置で同じ値を有する場合、２つのファイルの値は等しい。
２．２）２つのファイル名が同じ数のバイト位置を含まない場合、両方のファイル名が同じ数のバイト位置を含むようになるまで、短い方のファイル名が、すべて（００）に設定されたパディングバイトで右にパディングされる。
２．３）すべての必要なパディングを追加して、両方のファイル名を等しい長さとして処理した後、ファイル名の最初の位置で開始して、あるバイト位置が同じ値を含まないことが判明するまで、両方のバイト値が比較される。より高いコード位置の値を有するファイル名がより大きい名前である。

自然言語ソート
ユニコードボリュームにおいて、１６ビットＵＣＳ−２コードポイントが使用されて、パステーブルレコードの順序およびディレクトリレコードの順序が決定される。自然言語ソートをメディア上で提供しようとする試みは行われない。自然言語ソートはオプショナルで、表示アプリケーションによって望ましいように提供することができる。

ＣＯＮＴＥＮＴＳ．ＨＭＴ
ＣＯＮＴＥＮＴＳ．ＨＭＴは、ディスク上に存在するすべてのメディアファイルについての情報を含む。これはディレクトリテーブルとその後に続く、サポートされた各ファイルタイプ（オーディオ、ビデオ、メニュー画像、画像およびプレイリスト）についてのファイルエントリテーブルを含む。このファイルは、他のすべてのＨＩＧＨＭＡＴファイルが参照する主索引である。各ファイルを、それがＣＯＮＴＥＮＴＳ．ＨＭＴ内でリストされる順序によって一意に識別することができる。ファイル番号は１で開始し、隙間なく連続する。

コンテンツＩＤ
ＣＯＮＴＥＮＴＳ．ＨＭＴ内の各エントリは一意のＩＤを有し、これはファイル内のその相対位置から導出される。コンテンツＩＤという用語を、いずれかのファイルタイプへの参照として使用することができる。ＩＤは１で開始し、ファイル全体にわたって隙間なく連続する。ＣＩＤは、コンテンツＩＤの省略形として使用される。

プレイリストファイルＩＤ
プレイリストファイルはＣＯＮＴＥＮＴＳ．ＨＭＴ内の最初のファイルであり、存在する場合、ファイルＩＤ１で開始するべきである。

オーディオファイルＩＤ
オーディオファイルは、ＣＯＮＴＥＮＴＳ．ＨＭＴ内でプレイリストファイルのリストの後に続く。開始ファイルＩＤは、ここで定義されたプレイリストファイルの数に１を加えたものであるべきである。

サムネイルＩＤ
メニュー画像ファイルは、ＣＯＮＴＥＮＴＳ．ＨＭＴ内でオーディオファイルのリストの後に続く。開始ファイルＩＤは、ここで定義されたプレイリストファイルの数に、ここで定義されたオーディオファイルの数と１を加えたものであるべきである。

画像ファイルＩＤ
画像ファイルは、ＣＯＮＴＥＮＴＳ．ＨＭＴ内でメニュー画像ファイルのリストの後に続く。開始ファイルＩＤは、ここで定義されたプレイリストファイルの数に、ここで定義されたオーディオファイルの数と、ここで定義されたメニュー画像ファイルの数と１を加えたものであるべきである。

ビデオファイルＩＤ
ビデオファイルは、ＣＯＮＴＥＮＴＳ．ＨＭＴ内で画像ファイルのリストの後に続く。開始ファイルＩＤは、ここで定義されたプレイリストファイルの数に、ここで定義されたオーディオファイルの数と、ここで定義されたメニュー画像ファイルの数と、ここで定義された画像ファイルの数と１を加えたものであるべきである。

ファイル番号はこのファイル内に格納されず、これはこれらが容易にＣＯＮＴＥＮＴＳ．ＨＭＴ内のファイル情報の場所によって導出されるからである。各ファイルエントリテーブル内のファイルの数がＣＯＮＴＥＮＴＳ．ＨＭＴヘッダに格納される。これらの番号を使用して、ファイル内のどこで列挙を開始して特定のファイル参照を発見するかを識別することができる。ＭＥＮＵ．ＨＭＴ、ＴＥＸＴ．ＨＭＴおよびｎｎｎｎｎｎｎｎ．ＨＭＴファイルは、ファイルをこの一意の番号によって参照する。これは、これらのファイル内のスペースを節約し、同じ情報を多数の場所に格納しないために行われた。ＣＯＮＴＥＮＴＳ．ＨＭＴ内の類似のファイルタイプのグループ化により、プレイヤはそのファイルタイプを処理しない場合、ファイルのセクション全体を無視することができ、たとえば、オーディオ専用プレイヤは、ＣＯＮＴＥＮＴＳ．ＨＭＴのオーディオセクションの後のあらゆるものを廃棄することができる。ディレクトリテーブルは、多数の各ファイル内に含まれたパス情報の圧縮を可能にするように設計される。

ＣＯＮＴＥＮＴＳ．ＨＭＴファイルの構造
アクセラレータファイル内のオフセットは、ファイルの先頭からのバイトオフセットである。オーディオ、メニュー画像、画像およびビデオファイルテーブルは２Ｋ境界で開始するべきである。ディレクトリテーブルは、余計なパディングなしにＬＣＩＤテーブルを含むファイルヘッダの後に書き込まれるべきである。

図９は、コンピュータ可読媒体上のすべてのメディアファイルについての情報を表すデータ構造を例示する。

ファイルヘッダ
所与のタイプの使用可能なファイルがない場合、対応するテーブルが空にされるべきであり、これはファイルの数およびテーブルへのオフセットの両方がゼロであるとして書かれるべきである。

識別子
この８バイトエントリは、ＡＳＣＩＩによる「ＩＮＦＯ＿ＨＭＴ」を含む。

バージョン
この２バイトエントリは、このファイルを書くために使用されたＨＭＴ仕様のバージョンを表す。たとえば、バージョン１．２０は０×７８（１０進で１２０）として格納される。

ＨＭＴ世代
この８バイトエントリは、このＣＯＮＴＥＮＴＳ．ＨＭＴに合致するＬＳＮ．ＨＭＴの世代を表す。このＣＯＮＴＥＮＴＳ．ＨＭＴは、同じＨＭＴ世代番号を含むＬＳＮ．ＨＭＴファイルと共にのみ使用されるべきである。これらのＨＭＴ世代の値が合致しない場合、ＬＳＮ．ＨＭＴファイルはプレイヤによって無視されるべきである。０の値は、ＬＳＮ．ＨＭＴファイルがないことを意味する。

ＣＯＮＴＥＮＴＳ．ＨＭＴのサイズ
この４バイトエントリは、ＣＯＮＴＥＮＴＳ．ＨＭＴのサイズをバイトで含む。

ディレクトリの数
この４バイトエントリは、ここで定義されたディレクトリテーブル内のディレクトリの数を含む。

ディレクトリテーブルへのオフセット
この４バイトエントリは、ＣＯＮＴＥＮＴＳ．ＨＭＴの先頭からディレクトリテーブルへのバイトオフセットである。

プレイリストファイルの数
この４バイトエントリは、ここで定義されたプレイリストファイルテーブル内のプレイリストファイルの数を含む。少なくとも１つのプレイリストファイルがあるべきである。

プレイリストエントリのサイズ
この２バイトエントリは、バイトによるプレイリストエントリのサイズである。

プレイリストファイルテーブルへのオフセット
この４バイトエントリは、ＣＯＮＴＥＮＴＳ．ＨＭＴの先頭からプレイリストファイルテーブルへのバイトオフセットである。

オーディオファイルの数
この４バイトエントリは、ここで定義されたオーディオファイルテーブル内のオーディオファイルの数を含む。

オーディオエントリのサイズ
この２バイトエントリは、ここで定義された、バイトによるオーディオファイルエントリのサイズである。

オーディオファイルテーブルへのオフセット
この４バイトエントリは、ＣＯＮＴＥＮＴＳ．ＨＭＴの先頭からオーディオファイルテーブルへのバイトオフセットである。このオフセットは２Ｋの倍数であるべきであり、プレイリストファイルテーブルの終了とオーディオファイルテーブルの開始の間のいかなる隙間も無視されるべきである。０の値は、ＣＯＮＴＥＮＴＳ．ＨＭＴ内にオーディオエントリがないことを示す。ここで定義されたオーディオファイルの数も０であるべきである。

メニュー画像ファイルの数
この４バイトエントリは、ここで定義されたメニュー画像ファイルテーブル内のメニュー画像ファイルの数を含む。

メニュー画像エントリのサイズ
この２バイトエントリは、ここで定義された、バイトによるメニュー画像ファイルエントリのサイズである。

メニュー画像ファイルテーブルへのオフセット
この４バイトエントリは、ＣＯＮＴＥＮＴＳ．ＨＭＴの先頭からメニュー画像ファイルテーブルへのバイトオフセットである。このオフセットは２Ｋの倍数であるべきであり、オーディオファイルテーブルの終了とメニュー画像ファイルテーブルの開始の間のいかなる隙間も無視されるべきである。０の値は、ＣＯＮＴＥＮＴＳ．ＨＭＴ内にメニュー画像エントリがないことを示す。ここで定義されたメニュー画像ファイルの数も０であるべきである。

画像ファイルの数
この４バイトエントリは、ここで定義された画像ファイルテーブル内の画像ファイルの数を含む。

画像エントリのサイズ
この２バイトエントリは、ここで定義されたバイトによる画像ファイルエントリのサイズである。

画像ファイルテーブルへのオフセット
この４バイトエントリは、ＣＯＮＴＥＮＴＳ．ＨＭＴの先頭から画像ファイルテーブルへのバイトオフセットである。このオフセットは２Ｋの倍数であるべきであり、メニュー画像ファイルテーブルの終了と画像ファイルテーブルの開始の間のいかなる隙間も無視されるべきである。０の値は、ＣＯＮＴＥＮＴＳ．ＨＭＴ内に画像エントリがないことを示す。ここで定義された画像ファイルの数も０であるべきである。

ビデオファイルの数
この４バイトエントリは、ここで定義されたビデオファイルテーブル内のビデオファイルの数を含む。

ビデオエントリのサイズ
この２バイトエントリは、ここで定義されたバイトによるビデオファイルエントリのサイズである。

ビデオファイルテーブルへのオフセット
この４バイトエントリは、ＣＯＮＴＥＮＴＳ．ＨＭＴの先頭からビデオファイルテーブルへのバイトオフセットである。このオフセットは２Ｋの倍数であるべきであり、画像ファイルテーブルの終了とビデオファイルテーブルの開始の間のいかなる隙間も無視されるべきである。０の値は、ＣＯＮＴＥＮＴＳ．ＨＭＴ内にビデオエントリがないことを示す。ここで定義されたビデオファイルの数も０であるべきである。

ＬＣＩＤエントリの数
この２バイトエントリは、このディスク上の言語の数を表す。この値は少なくとも１でなければならない。

ディレクトリ番号
この４バイトエントリは、このロケール識別子についてのＴＥＸＴ．ＨＭＴおよびＭＥＮＵ．ＨＭＴを含むディレクトリの、ここで定義されたディレクトリテーブル内の索引である。これは、ＬＣＩＤをディレクトリ名とした、＼ＨＩＧＨＭＡＴのサブディレクトリのいずれかであるべきであるが、＼ＨＩＧＨＭＡＴ自体への参照はデフォルト言語について有効である。

ＬＣＩＤｎ
この４バイトエントリは、ロケール識別子を表す。

ディレクトリテーブル
ディレクトリエントリは１で開始して付番され、オフセットはテーブルの先頭であり、容易な直接索引付けを可能にする。ディレクトリ名は空白のＵＣＳ−２文字（２つの空バイト）で終了されるべきである。ディレクトリテーブルは、有効なＪＰＧ、ＨＭＴ、ＭＰ３、ＡＳＦ、ＷＭＡまたはＷＭＶファイルである少なくとも１つのファイルを含む、ディスク上のすべてのディレクトリを含むべきである。

ディレクトリテーブルは以下のようにフォーマットされるべきである。

ルートディレクトリはエントリ１に格納され、親エントリは０（無効なエントリ番号）であるべきである。ディレクトリエントリは、ここで定義されたソート順序でリストされるべきである。

親ディレクトリ番号
この４バイトエントリは、親ディレクトリについてのディレクトリテーブルにおける索引である。この値は最初のディレクトリエントリについて０であるべきである。

ディレクトリ名の長さへのオフセット
この４バイトエントリは、ＣＯＮＴＥＮＴＳ．ＨＭＴの先頭からこのエントリのためのディレクトリ名の長さへのバイトオフセットである。

ディレクトリ名の長さ
この２バイトエントリは、ディレクトリ名のバイト長から終了の空白ＵＣＳ−２文字（２つの空バイト）を除いたものを含む。

ディレクトリ名
この可変長エントリは、ディレクトリのＵＣＳ−２名である。この名前は、空白のＵＣＳ−２文字（２つの空バイト）で終了されるべきである。このエントリの最大長は、空白のＵＣＳ−２文字を含む１１１のＵＣＳ−２文字である。このエントリはビッグエンディアンのワードレイアウトを使用するべきである。

プレイリストファイルテーブル
プレイリストファイルテーブルは、プレイリストファイルエントリのリストを含む。各プレイリストファイルについて１つのプレイリストファイルエントリがあるべきである。プレイリストファイルについてのファイル名は格納されず、これは、各プレイリストについてのファイル名を、命名スキームと組み合わせて、ここで定義されたＣＯＮＴＥＮＴＳ．ＨＭＴ内のプレイリストファイルのＩＤを使用して導出することができるからである。各プレイリストファイルエントリは以下のようにフォーマットされるべきである。

ディレクトリ番号
この４バイトエントリは、このファイルを含むディレクトリの、ここで定義されたディレクトリテーブルにおける索引である。

プレイリストサマリタイプ
この値は、プレイリストファイルエントリに対応するプレイリストファイルのヘッダに格納されたものと同じである。

予約済
この１バイトエントリは将来の使用のために予約される。

オーディオファイルテーブル
オーディオファイルテーブルは、オーディオファイルエントリのリストと、その後に続くファイル名テーブルを含む。各オーディオファイルについて１つオーディオファイルエントリがあるべきである。Ｗｉｎｄｏｗｓ（登録商標）Ｍｅｄｉａ Ａｕｄｉｏファイルは．ＷＭＡ拡張子を有するべきであり、ＭＰ３ファイルは．ＭＰ３拡張子を有するべきである。他のすべてのファイル拡張子は無効である。ファイル名テーブルをオーディオファイルエントリの後に置くことにより、プレイヤが、最初のファイル名のＬＳＮへの変換が行われた後にファイル名テーブルをメモリから廃棄することができ、それによりメモリ内で各ファイルの再生のために必要とされた実際のデータのみを保つことができる。オーディオファイルエントリは、ここで定義されたソート順序でリストされるべきである。各オーディオファイルエントリは以下のようにフォーマットされるべきである。

ディレクトリ番号へのオフセット
この４バイトエントリは、ＣＯＮＴＥＮＴＳ．ＨＭＴの先頭からこのエントリのためのディレクトリ番号へのバイトオフセットである。

ファイルタイプ
この２バイトエントリはファイルタイプを表し、これはデータ符号化フォーマットを意味する。オーディオファイルについて定義された値のみがこのエントリについて有効である。

特殊フラグ
この２バイトエントリは、このファイルの特殊な属性を要約する。特殊フラグエントリは、以下の値を共に論理和することによって作成される。

特殊フラグエントリにより、プレイヤが、プレイすることができるファイルをフィルタすることができ、たとえば、保護付きのコンテンツをプレイすることができないプレイヤは、ＤＲＭ保護付きとしてマーク付けされたファイルを除くべきである。

チャネルの数
この１バイトエントリは、このファイル内のオーディオのチャネルの数を含む。

サンプルサイズ
この１バイトエントリは、チャネル毎のビットサイズを含む。

平均ビットレート
この４バイトエントリは、ビット毎秒によるオーディオストリーム平均ビットレートを含む。

ファイルビットレート
この４バイトエントリは、ビット毎秒による合計ファイルビットレートを含む。

再生時間
この４バイトエントリは、ミリ秒によるこのファイルの持続時間を含む。

サンプリング周波数
この４バイトエントリは、ヘルツによるサンプリング周波数を含む。

トラック番号
この２バイトエントリは、ソースメディア上のオーディオファイルのトラック番号を含む。０の値はトラック番号がないことを示す。

サムネイルＩＤ
この４バイトエントリは、ＣＯＮＴＥＮＴＳ．ＨＭＴ内のこのファイルについてのサムネイルである画像ファイルＩＤを表す。このファイルについてのサムネイルがない場合、この値は０であるべきである。この値をオーサリングアプリケーションによって使用して、サムネイルの再生成を防止することができる。

ディレクトリ番号
この４バイトエントリは、このファイルを含むディレクトリの、ここで定義されたディレクトリテーブルにおける索引である。

ファイル名の長さ
この２バイトエントリは、ファイル名のバイト長から終了の空白ＵＣＳ−２文字（２つの空バイト）を除いたものを含む。

ファイル名
これはＵＣＳ−２ファイル名である。この名前は、空白のＵＣＳ−２文字（２つの空バイト）で終了されるべきである。このエントリの最大長は、空白のＵＣＳ−２文字を含む１１１のＵＣＳ−２文字である。このエントリはビッグエンディアンのワードレイアウトを使用するべきである。

メニュー画像ファイルテーブル
メニュー画像ファイルテーブルは、ＭＥＮＵ．ＨＭＴファイルで使用されるサムネイルおよびバックグラウンド画像のすべてをリストするために使用される。すべてのメニュー画像ファイルは．ＨＭＴ拡張子を有するべきであり、他のすべてのファイル拡張子は無効である。メニュー画像ファイルテーブルは、メニュー画像ファイルエントリのリストとその後に続くファイル名テーブルを含む。各メニュー画像ファイルについて１つのメニュー画像ファイルエントリがあるべきである。メニュー画像ファイルエントリは、ここで定義されたソート順序でリストされるべきである。各メニュー画像ファイルエントリは以下のようにフォーマットされるべきである。

ディレクトリ番号へのオフセット
この４バイトエントリは、ＣＯＮＴＥＮＴＳ．ＨＭＴの先頭からこのエントリのためのディレクトリ番号へのバイトオフセットである。

ファイルタイプ
この２バイトエントリはファイルタイプを表し、これはデータ符号化フォーマットを意味する。ここで定義された有効な値は、サムネイル、メニューバックグラウンド（４×３）およびメニューバックグラウンド（１６×９）のみである。

特殊フラグ
この２バイトエントリは本明細書で定義される。

ディレクトリ番号
この４バイトエントリは、このファイルを含むディレクトリの、ここで定義されたディレクトリテーブルにおける索引である。

ファイル名の長さ
この２バイトエントリは、ファイル名のバイト長から終了の空白ＵＣＳ−２文字（２つの空バイト）を除いたものを含む。

ファイル名
これはＵＣＳ−２ファイル名である。この名前は、空白のＵＣＳ−２文字（２つの空バイト）で終了されるべきである。このエントリの最大長は、空白のＵＣＳ−２文字を含む１１１のＵＣＳ−２文字である。このエントリはビッグエンディアンのワードレイアウトを使用するべきである。

画像ファイルテーブル
画像ファイルテーブルは、画像ファイルエントリのリストとその後に続くファイル名テーブルを含む。各画像ファイルについて１つの画像ファイルエントリがあるべきである。すべての画像ファイルは．ＪＰＧまたは．ＪＰＥＧ拡張子を有するべきであり、他のすべてのファイル拡張子は無効である。画像ファイルエントリは、ここで定義されたソート順序でリストされるべきである。各画像ファイルエントリは以下のようにフォーマットされるべきである。

ディレクトリ番号へのオフセット
この４バイトエントリは、ＣＯＮＴＥＮＴＳ．ＨＭＴの先頭からこのエントリのためのディレクトリ番号へのバイトオフセットである。

ファイルタイプ
この２バイトエントリはファイルタイプを表し、これはデータ符号化フォーマットを意味する。画像ファイルについてここで定義された値のうち、サムネイル、メニューバックグラウンド（４×３）およびメニューバックグラウンド（１６×９）を除いたもののみが有効である。

特殊フラグ
この２バイトエントリはここで定義される。

サムネイルＩＤ
この４バイトエントリは、ＣＯＮＴＥＮＴＳ．ＨＭＴ内のこのファイルについてのサムネイルである画像ファイルＩＤを表す。この画像についてのサムネイルがない場合、この値は０であるべきである。この値をオーサリングアプリケーションによって使用して、サムネイルの再生成を防止することができる。

垂直サイズ
この２バイトエントリは、画像の垂直サイズをピクセルで表す。

水平サイズ
この２バイトエントリは、画像の水平サイズをピクセルで表す。

ディレクトリ番号
この４バイトエントリは、このファイルを含むディレクトリの、ここで定義されたディレクトリテーブルにおける索引である。

ファイル名の長さ
この２バイトエントリは、ファイル名のバイト長から終了の空白ＵＣＳ−２文字（２つの空バイト）を除いたものを含む。

ファイル名
これはＵＣＳ−２ファイル名である。この名前は、空白のＵＣＳ−２文字（２つの空バイト）で終了されるべきである。このエントリの最大長は、空白のＵＣＳ−２文字を含む１１１のＵＣＳ−２文字である。このエントリはビッグエンディアンのワードレイアウトを使用するべきである。

ビデオファイルテーブル
ビデオファイルテーブルは、ビデオファイルエントリのリストとその後に続くファイル名テーブルを含む。各ビデオファイルについて１つのビデオファイルエントリがあるべきである。Ｗｉｎｄｏｗｓ（登録商標）Ｍｅｄｉａ Ｖｉｄｅｏファイルのための有効なファイル拡張子は．ＷＭＶおよび．ＡＳＦであり、．ＷＭＶは好ましい拡張子である。オプショナルのＭＰ４ファイルのための有効なファイル拡張子は、．ＡＳＦであるべきである。他のすべてのファイル拡張子は無効である。ファイル名テーブルをビデオファイルエントリの後に置くことにより、プレイヤが、最初のファイル名のＬＳＮへの変換が行われた後にファイル名テーブルをメモリから廃棄することができ、それによりメモリ内で各ファイルの再生のために必要とされた実際のデータのみを保つことができる。ビデオファイルエントリは、ここで定義されたソート順序でリストされるべきである。各ビデオファイルエントリは、ここで定義されたオーディオファイルエントリとその後に続くビデオエントリのようにフォーマットされるべきである。

ファイルタイプ
この２バイトエントリはファイルタイプを表し、これはデータ符号化フォーマットを意味する。ビデオファイルについてここで定義された値のみがこのエントリについて有効である。

ビデオ平均ビットレート
この４バイトエントリは、ビット毎秒による平均ビットレートを含む。

ビデオ垂直サイズ
この２バイトエントリは、ピクセルによるビデオファイルの垂直サイズを含む。

ビデオ水平サイズ
この２バイトエントリは、ピクセルによるビデオファイルの水平サイズを含む。

フレームレート
このフィールドは、３０／１．００１（ＮＴＳＣ）、２５（ＰＡＬ）などのようなフレームレートを４バイトで含むべきである。このフィールドは（最初の２バイト整数）／（最後の２バイト整数）として記述することができる。オーサリングアプリケーションがフレームレートを決定することができない場合、この値は０であるべきである。オーサリングアプリケーションは最小公倍数の形式を使用してフレームレートを表すべきである。たとえば、ＮＴＳＣでは３００００／１００１０ではなく３０００／１００１である。

ディレクトリ番号
この４バイトエントリは、このファイルを含むディレクトリの、ここで定義されたディレクトリテーブルにおける索引である。

ファイル名の長さ
この２バイトエントリは、ファイル名のバイト長から終了の空白ＵＣＳ−２文字（２つの空バイト）を除いたものを含む。

ファイル名
これはＵＣＳ−２ファイル名である。この名前は、空白のＵＣＳ−２文字（２つの空バイト）で終了されるべきである。このエントリの最大長は、空白のＵＣＳ−２文字を含む１１１のＵＣＳ−２文字である。このエントリはビッグエンディアンのワードレイアウトを使用するべきである。

プレイリストファイル
各プレイリストは一意のｎｎｎｎｎｎｎｎ．ＨＭＴファイルとして表され、ｎｎｎｎｎｎｎｎは、ここで定義されたＣＯＮＴＥＮＴＳ．ＨＭＴ内のプレイリストファイルＩＤを表す１６進数である。これらのプレイリストファイルは、サブディレクトリ＼ＨＩＧＨＭＡＴ＼ＰＬＡＹＬＩＳＴで作成されるべきである。４つの異なるタイプのプレイリストグループがあり、これらはオーディオ（Ａ）、ビデオ（Ｖ）、タイムドイメージ（ＴＩ）およびパラレルイメージオーディオ（ＰＩＡ）である。各グループの特定の構造を以下に概説する。レベル１プレイヤは、オーディオグループのみをプレイするべきである。

ｎｎｎｎｎｎｎｎ．ＨＭＴファイルの構造
図１０は、プレイリストファイルを表すデータ構造を例示する。プレイリストファイルは、プレイリストヘッダと後に続く１つまたは複数のプレイリストグループを含む。このファイルは、ファイル内の複数のデータ構造の間に隙間がないように書かれるべきである。

識別子
この８バイトエントリは、ＡＳＣＩＩによる「ＰＬＩＳＴＨＭＴ」を含む。

バージョン
この２バイトエントリは、このファイルを書くために使用されたＨＭＴ仕様のバージョンを表す。たとえば、バージョン１．２０は０×７８（１０進で１２０）として格納される。

プレイリストファイルのサイズ
この４バイトエントリは、バイトによるこのプレイリストファイルのサイズを含む。

プレイリストサマリタイプ
この１バイトエントリは、その中に含まれたすべての個々のプレイリストエントリのタイプを要約する。サマリタイプは、以下の値を共に論理和することによって作成される。

ＰＩＡプレイリストは、ＴＩプレイリストとしてのみ要約されるべきであり、したがってオーディオファイル存在ビットを設定するべきでない。プレイリストサマリタイプにより、プレイヤが、プレイすることができるプレイリストのみを示すようにプレイリストのリストをフィルタリングすることができ、たとえば、オーディオ専用プレイヤは、画像またはビデオを含むすべてのプレイリストを除くことができる。

リピートカウント
この１バイトエントリは、このプレイリストの再生を繰り返す回数である。このプレイリストが、ここで定義された開始点で呼び出された場合、各リピートが終了すると、ファイルが即時に開始点に進む。０の値は、無限のリピートカウントを示す。たとえば、３つのグループであるグループＡ、グループＢおよびグループＣ、および２のリピートカウントが与えられると、再生順序はＡ→Ｂ→Ｃ→Ａ→Ｂ→Ｃ→終了である。同じ３つのグループで、ここで定義された２の開始グループ索引では、再生順序はＢ→Ｃ→Ａ→Ｂ→Ｃ→Ａである。プレイヤは、他のユーザ再生モードと共に再生するとき、リピートカウントを無視することができる。

サムネイルＩＤ
この４バイトエントリは、ＣＯＮＴＥＮＴＳ．ＨＭＴ内のこのプレイリストについてのサムネイルの索引を表す。このプレイリストについてのサムネイルがない場合、この値は０であるべきである。

グループの数
この４バイトエントリは、プレイリストグループのカウントを表す。

特殊フラグ
この２バイトエントリは、このファイルの特殊な属性を要約する。特殊フラグエントリは、以下の値を共に論理和することによって作成される。

次のグループのオフセット
この４バイトエントリは、ｎｎｎｎｎｎｎｎ．ＨＭＴの先頭から次のプレイリストグループへのオフセットである。このエントリは、これが最後のプレイリストグループである場合、０であるべきである。

前のグループのオフセット
この４バイトエントリは、ｎｎｎｎｎｎｎｎ．ＨＭＴの先頭から前のプレイリストグループへのオフセットである。このエントリは、これが最初のプレイリストグループである場合、０であるべきである。

グループ番号
この４バイトエントリはこのグループの番号であり、グループ番号を使用して、ＴＥＸＴ．ＨＭＴ内のグループ名をルックアップすることができる。グループメンバは１で開始して連続し、すべてのプレイリスト内のすべてのグループについて一意である。

プレイリストグループのタイプ
この１バイトエントリは、以下のように定義するプレイリストタイプを表す。

これらの各プレイリストグループタイプのグループデータのフォーマットは、以下のセクションで定義される。レベル２プレイヤは、タイプ３（ＰＩＡ）をプレイすることは必要とされず、これは、オーディオ再生中の画像のための並列復号化パスの追加の複雑さが、近いうちに使用可能となる可能性のあるハードウェアのいくつかの機能を超えるからである。タイプ３をプレイすることができないプレイヤは、それにもかかわらず、このようなプレイリストエントリが提示されるとき、よい体験を与えるべきである。ＰＩＡシーケンスは、タイムドイメージシーケンスとしてレンダリングされる（オーディオを無視する）べきである。

予約済
この１バイトエントリは将来の使用のために予約される。

グループデータ
これは、フォーマットにおいて、実際のプレイリストグループデータがある場所を表す。各プレイリストグループのフォーマットは以下で定義される。

オーディオプレイリストグループ

オーディオファイルの数
この４バイトエントリは、このグループ内でリストされるオーディオファイルＩＤの数を表す。

オーディオファイルＩＤ
このグループ内の各オーディオファイルについて１つの４バイトエントリがある。この値は、ここで定義されたＣＯＮＴＥＮＴＳ．ＨＭＴ内のオーディオファイルの索引である。

オーディオの開始点
このグループ内の各オーディオファイルについて１つの４バイトエントリがある。この値は、ミリ秒による再生の開始点へのオフセットである。

オーディオの終了点
このグループ内の各オーディオファイルについて１つの４バイトエントリがある。この値は、ミリ秒による再生の終了点へのオフセットである。０の値は、ファイルの最後までのプレイを示す。プレイヤは、２つの連続したファイルが同じファイルＩＤを有し、最初のファイルの終了点および次のファイルの開始点が等しい場合を認識するべきであり、次いで再生が途切れずに継続するべきである。

開始点オフセット
このグループ内の各オーディオファイルについて１つの８バイトエントリがある。この値は、オーディオファイルの先頭から、プレイヤがファイルの読み取りを開始するために使用することができる場所へのオフセットである。このオフセットは、本明細書のオーディオフィールドの開始点と共に使用されるべきである。オーディオフィールドの開始点が０である場合、このフィールドは０であるべきであり、この場合、プレイヤはファイルヘッダを検査することによって、読み取るための最初のパケットを位置付けるようになる。オーディオフィールドの開始点がゼロでない場合、オーディオ開始時間に迅速に到達するために、このフィールドがオーサリングソフトウェアによって、ファイル内で復号化を開始するための最も近い場所に設定されるべきである。プレイヤはこのフィールドを無視し、この中のオーディオフィールドの開始点のみを使用することができる。ＣＤメディアでは、上位の４バイトは常に０であるべきである。

終了点オフセット
このグループ内の各オーディオファイルについて１つの８バイトエントリがある。この値は、オーディオファイルの先頭から、プレイヤがファイルの読み取りを停止するために使用することができる場所へのオフセットである。このオフセットは、この中のオーディオフィールドの終了点と共に使用されるべきである。オーディオフィールドの終了点が０である場合、このフィールドは０であるべきであり、この場合、プレイヤはファイルの読み取りをどこで停止するかをそれ自体で決定することが必要となる。オーディオフィールドの終了点がゼロでない場合、すべての必要なデータが読み取られていることを保証するために、このフィールドがオーサリングソフトウェアによって、ファイル内で読み取りを終了するための最も近い場所に設定されるべきである。プレイヤはこのフィールドを無視し、この中のオーディオフィールドの終了点のみを使用することができる。ＣＤメディアでは、上位の４バイトは常に０であるべきである。

もう１つの実施形態では、表Ａ１９のオーディオプレイリストグループは以下のフィールドのみを含み、すなわち、オーディオファイルの数およびオーディオファイルＩＤ１からオーディオファイルＩＤｎまでである。オーディオの開始および終了点、およびグループ内の各オーディオファイルについてのオフセットは省略される。

ビデオプレイリストグループ

プレイヤは自動的にビデオのサイズを変更して、表示を全体にすることができる。

ビデオファイルの数
この４バイトエントリは、このビデオプレイリストグループ内でリストされるビデオファイルＩＤの数を表す。

ビデオファイルＩＤ
このグループ内の各ビデオファイルについて１つの４バイトエントリがある。この値は、ここで定義されたＣＯＮＴＥＮＴＳ．ＨＭＴ内のビデオファイルの索引である。

ビデオの開始点
このグループ内の各ビデオファイルについて１つの４バイトエントリがある。この値は、ミリ秒による再生の開始点へのオフセットである。この値はＩフレームに設定されるべきである。

ビデオの終了点
このグループ内の各ビデオファイルについて１つの４バイトエントリがある。この値は、ミリ秒による再生の終了点へのオフセットである。０の値は、ファイルの最後までのプレイを示す。プレイヤは、２つの連続したファイルが同じファイルＩＤを有し、最初のファイルの終了点および次のファイルの開始点が等しい場合を認識するべきであり、次いで再生が途切れずに継続するべきである。

開始点オフセット
このグループ内の各ビデオファイルについて１つの８バイトエントリがある。この値は、ビデオファイルの先頭から、プレイヤがファイルの読み取りを開始するために使用することができる場所へのオフセットである。このオフセットは、この中のビデオフィールドの開始点と共に使用されるべきである。ビデオフィールドの開始点が０である場合、このフィールドは０であるべきであり、この場合、プレイヤはファイルヘッダを検査することによって、読み取るための最初のパケットを位置付けるようになる。ビデオフィールドの開始点がゼロでない場合、ビデオ開始時間に迅速に到達するために、このフィールドがオーサリングソフトウェアによって、ファイル内で復号化を開始するための最も近い場所に設定されるべきである。プレイヤはこのフィールドを無視し、この中のビデオフィールドの開始点のみを使用することができる。ＣＤメディアでは、上位の４バイトは常に０であるべきである。

終了点オフセット
このグループ内の各ビデオファイルについて１つの８バイトエントリがある。この値は、ビデオファイルの先頭から、プレイヤがファイルの読み取りを停止するために使用することができる場所へのオフセットである。このオフセットは、この中のオーディオフィールドの終了点と共に使用されるべきである。ビデオフィールドの終了点が０である場合、このフィールドは０であるべきであり、この場合、プレイヤはファイルの読み取りをどこで停止するかをそれ自体で決定することが必要となる。ビデオフィールドの終了点がゼロでない場合、すべての必要なデータが読み取られていることを保証するために、このフィールドがオーサリングソフトウェアによって、ファイル内で読み取りを終了するための最も近い場所に設定されるべきである。プレイヤはこのフィールドを無視し、この中のビデオフィールドの終了点のみを使用することができる。ＣＤメディアでは、上位の４バイトは常に０であるべきである。

タイムドイメージグループ

画像ファイルの数
この４バイトエントリは、このグループ内でリストされる画像ファイルＩＤの数を表す。

初期トランジション
この２バイトエントリは、プレイリスト内の最初の画像を表示するために使用される初期トランジションを定義する。可能な値は、ここで定義されたＣＵＴおよびＦＡＤＥ ＩＮのみである。

最終トランジション
この２バイトエントリは、プレイリスト内の最後の画像の表示を終了させるために使用される最終トランジションを定義する。可能な値は、ここで定義されたＣＵＴおよびＦＡＤＥ ＯＵＴのみである。

画像ファイル
このグループ内の各画像ファイルについて１つの４バイトエントリがある。この値は、ここで定義されたＣＯＮＴＥＮＴＳ．ＨＭＴ内の画像ファイルの索引である。

持続時間
この４バイトエントリは、画像を表示する持続時間をミリ秒で表し、０の値は無限を表す。タイムドイメージプレイリストグループの最短画像持続時間は５秒（５０００ミリ秒）である。

トランジション
この２バイトエントリは、プレイヤが次の画像に変更するときに使用するためのトランジションのタイプを定義する。０の値はＣＵＴとして定義され、サポートされるべきであり、すべての他の値のサポートはオプショナルである。トランジションのリストは以下のように定義される。

トランジションの持続時間はメーカにより定義される。トランジション持続時間は、上で定義された画像持続時間に影響を及ぼすべきではない。たとえば、それぞれ２０および３０秒の持続時間の２つの画像の間の２秒の持続時間のトランジションは結果として、最初の画像の１９秒と、その後に続くこれらの画像の間の２秒のトランジションと、その後に続く第２の画像の２９秒となるべきである。ＰＩＡプレイリストグループに含まれたタイムドイメージグループでは、持続時間情報をプレイヤが考慮するべきである。

パラレルイメージオーディオプレイリストグループ
次／前プレイリスト項目機能を実施するとき、プレイヤはタイムドイメージプレイリストグループを通るべきである。プレイヤはオーディオを次／前の画像に同期化させるべきである。

オーディオプレイリストグループのオフセット
この４バイトエントリは、ｎｎｎｎｎｎｎｎ．ＨＭＴの先頭からＰＩＡエントリ内のオーディオプレイリストグループへのオフセットである。

タイムドイメージプレイリストグループ
このエントリは、ここで定義されたタイムドイメージグループである。

オーディオプレイリストエントリ
このエントリは、ここで定義されたオーディオエントリである。

ＭＥＮＵ．ＨＭＴ
ＭＥＮＵ．ＨＭＴファイルの構造

図１１は階層メニュー構造を例示する。このファイルは、ファイル内の複数のデータ構造の間に隙間がないように書かれるべきである。

メニューファイルヘッダ

識別子
この８バイトエントリは、ＡＳＣＩＩによる「ＭＥＮＵ＿ＨＭＴ」を含む。

バージョン
この２バイトエントリは、このファイルを書くために使用されたＨＭＴ仕様のバージョンを表す。たとえば、バージョン１．２０は０×７８（１０進で１２０）として格納される。

ＭＥＮＵ．ＨＭＴのサイズ
この４バイトエントリは、バイトによるＭＥＮＵ．ＨＭＴのサイズを含む。

ＬＣＩＤ
この４バイトエントリは、このＭＥＮＵ．ＨＭＴファイルの言語ＩＤである。

最初のメニューのオフセット
この２バイトエントリは、ＭＥＮＵ．ＨＭＴの先頭から、ここで定義された最初のメニューヘッダへのバイトオフセットである。

メニュータイトルの長さ
この２バイトエントリは、メニュータイトルのバイト長から終了の空白ＵＣＳ−２文字（２つの空バイト）を除いたものを含む。

メニュータイトル
これはＵＣＳ−２メニュータイトルである。このタイトルは、空白のＵＣＳ−２文字（２つの空バイト）で終了されるべきである。このエントリの最大長は、空白のＵＣＳ−２文字を含む６５のＵＣＳ−２文字である。プレイヤはこれを使用して、メニュー全体についてのタイトルを表示するべきである。空文字列（１つのＮＵＬＬ文字）は、表示するためのタイトルがないか、あるいはオーサリングソフトウェアがタイトルをバックグラウンド画像上にレンダリングしていることを示す。たとえば、「私のハワイの休日」、「２００２年スクールパーティ」である。

メニュー
メニューはバックグラウンド画像、一様なバックグラウンド色またはプレイヤのデフォルトの挙動のいずれもサポートする。バックグラウンド画像またはバックグラウンド色が定義された場合、テキスト色が定義されるべきである。バックグラウンド画像、バックグラウンド色およびテキスト色のエントリが０である場合、プレイヤはそのデフォルトの挙動を使用するべきである。各サブメニューは、厳密な階層メニュー構造を形成する単一の親メニューによって参照されるべきである。

メニューヘッダのサイズ
この４バイトエントリは、バイトによる、メニューおよびプレイリスト項目を含むメニューヘッダのサイズである。

親メニューへのオフセット
この４バイトエントリは、ＭＥＮＵ．ＨＭＴの先頭から親メニューへのバイトオフセットであり、これが最上位メニューである場合、この値は０である。

バックグラウンド画像ＩＤ（４：３）
この４バイトエントリは、４：３ディスプレイ上にこのメニューのバックグラウンドとして表示するための画像を定義する。この画像は、ＨＭＴ拡張子を有する６４０×４８０のＪＰＧファイルであるべきである。０の値は、バックグラウンド画像がないことを示す。この値は、ここで定義されたＣＯＮＴＥＮＴＳ．ＨＭＴ内のメニューイメージファイルの索引である。プレイヤは、バックグラウンド画像をディスプレイ上で中央に表示して、縦横比を保持するべきである。プレイヤは、いずれかの覆われていないエリアを埋めるためにここで定義されたものがある場合、バックグラウンド色を使用するべきである。

バックグラウンド画像ＩＤ（１６：９）
この４バイトエントリは、１６：９ディスプレイ上にこのメニューのバックグラウンドとして表示するための画像を定義する。この画像は、ＨＭＴ拡張子を有する８５２×４８０のＪＰＧファイルであるべきである。０の値は、バックグラウンド画像がないことを示す。この値が０でない場合、有効なバックグラウンド画像ＩＤ（４：３）もあるべきである。この値は、ここで定義されたＣＯＮＴＥＮＴＳ．ＨＭＴ内のメニュー画像ファイルの索引である。プレイヤは、バックグラウンド画像をディスプレイ上で中央に表示して、縦横比を保持するべきである。

バックグラウンド色
この４バイトエントリは、このメニューがディスプレイ上にレンダリングされるときに使用されるべきバックグラウンド色を定義する。これは、バイト順序０ｘＦＦＲＲＧＧＢＢを有するＲＧＢ値としてフォーマットされる。バックグラウンド画像ＩＤがここで定義される場合、バックグラウンド色は、バックグラウンド画像がある場合にそれによって覆われないディスプレイのエリア上でのみ可視であるべきである。０の値は、バックグラウンド色がないことを示す。プレイヤがカラーのレンダリングができない場合、このフィールドを無視することができる。

テキスト色
この４バイトエントリは、このメニュー上のテキストがディスプレイ上にレンダリングされるべきである色を定義する。これは、バイト順序０ｘＦＦＲＲＧＧＢＢを有するＲＧＢ値としてフォーマットされる。バックグラウンド画像ＩＤまたはバックグラウンド色がここで定義される場合、このエントリはゼロでない値を含むべきである。０の値は、プレイヤがそのデフォルトの挙動を使用するべきであることを意味するように定義される。プレイヤがカラーのレンダリングができない場合、このフィールドを無視することができる。

項目の数
この２バイトエントリは、このメニュー内のサブメニューまたはプレイリスト項目の数を定義する。

メニューサブタイトルの長さ
この２バイトエントリは、メニューサブタイトルのバイト長から終了の空白ＵＣＳ−２文字（２つの空バイト）を除いたものを含む。

メニューサブタイトル
これはＵＣＳ−２メニューサブタイトルである。このサブタイトルは、空白のＵＣＳ−２文字（２つの空バイト）で終了されるべきである。このエントリの最大長は、空白のＵＣＳ−２文字を含む６５のＵＣＳ−２文字である。プレイヤはこれを使用して、このメニューについてのサブタイトルを表示するべきである。空文字列（１つのＮＵＬＬ文字）は、表示するためのサブタイトルがないか、あるいはオーサリングソフトウェアがタイトルをバックグラウンド画像上にレンダリングしていることを示す。

メニューまたはプレイリスト項目
この可変サイズのエントリは、ここで定義されたメニュー項目またはここで定義されたプレイリスト項目である。

メニュー項目

エントリのタイプ
この１バイトエントリは、これがメニュー項目構造かプレイリスト項目構造かを定義する。メニュー項目では、この値は以下で定義するＭＥＮＵの値にするべきである。

メニューサマリタイプ
この値は、このメニュー項目を介してアクセス可能であるプレイリストのタイプを定義するために使用される。

サムネイルＩＤ
この４バイトエントリは、ここで定義されたＣＯＮＴＥＮＴＳ．ＨＭＴ内のこのメニュー項目についてのサムネイルＩＤを表し、このメニュー項目についてのサムネイルがない場合、この値は０であるべきである。

選択状態サムネイルＩＤ
この４バイトエントリは、ここで定義されたＣＯＮＴＥＮＴＳ．ＨＭＴ内のこのメニュー項目についての選択状態を表すサムネイルＩＤを定義する。０の値は、プレイヤが外接矩形（ｂｏｕｎｄｉｎｇ ｒｅｃｔａｎｇｌｅ）または他の強調表示を生成して、ここで定義された色を使用して選択を指示するべきであることを示す。

メニューへのオフセット
この４バイトエントリは、ＭＥＮＵ．ＨＭＴの先頭から、ここで定義されたメニューへのバイトオフセットを定義する。

メニュー名の長さ
この２バイトエントリは、メニュー名のバイト長から終了の空白ＵＣＳ−２文字（２つの空バイト）を除いたものを含む。

メニュー名
これはメニューのＵＣＳ−２名である。この名前は、空白のＵＣＳ−２文字（２つの空バイト）で終了されるべきである。このエントリの最大長は、空白のＵＣＳ−２文字を含む６５のＵＣＳ−２文字である。

プレイリスト項目

エントリのタイプ
この１バイトエントリは、これが、ここで定義されたメニュー項目構造かプレイリスト項目構造かを定義する。プレイリスト項目では、この値はここで定義されたＰＬＡＹＬＩＳＴの値にするべきである。

プレイリストサマリタイプ
この値は、このメニュー項目が参照するプレイリストのタイプを定義するために使用される。

サムネイルＩＤ
この４バイトエントリは、ここで定義されたＣＯＮＴＥＮＴＳ．ＨＭＴ内のこのメニュー項目についてのサムネイルＩＤを定義する。このメニュー項目についてのサムネイルがない場合、この値は０であるべきである。サムネイルＩＤは、ここで定義されたプレイリストヘッダ内のサムネイルＩＤと同じものにすることができる。

選択状態サムネイルＩＤ
この４バイトエントリは、ここで定義されたＣＯＮＴＥＮＴＳ．ＨＭＴ内のこのメニュー項目についての選択状態を表すサムネイルＩＤを定義する。０の値は、プレイヤが外接矩形または他の強調表示を生成して、ここで定義された色を使用して選択を指示するべきであることを示す。

プレイリストＩＤ
この４バイトエントリは、ここで定義されたＣＯＮＴＥＮＴＳ．ＨＭＴ内のこのメニュー項目についてのプレイリストのＩＤを定義する。

開始グループ索引
この４バイトエントリは、再生を開始するためのプレイリストファイル内のグループの索引を定義する。１の値はプレイリスト内の最初のグループを示す。

開始ファイル索引
この４バイトエントリは、再生を開始するためにここで参照されたグループ内のファイルの索引を定義する。１の値は、グループ内の最初のファイルを示す。ここで参照されたグループがパラレルプレイリストグループ（ＰＩＡ）である場合、この値は１であるべきであることに留意されたい。開始グループ索引および開始ファイル索引は共に、１つのプレイリストをメニュー内で何度も参照できるようにする。たとえば、メニューはディスク上のあらゆる画像についてのサムネイルを示すことができ、各サムネイルはユーザを、選択された画像で開始するすべての画像のループプレイリストに導く。

メニュー内のプレイリスト名の長さ
この２バイトエントリは、メニュー内のプレイリスト名のバイト長から終了の空白ＵＣＳ−２文字（２つの空バイト）を除いたものを含む。

メニュー内のプレイリスト名
これは、プレイリストがメニュー内で表れるときのＵＣＳ−２名である。この名前は、空白のＵＣＳ−２文字（２つの空バイト）で終了されるべきである。このエントリの最大長は、空白のＵＣＳ−２文字を含む６５のＵＣＳ−２文字である。

ＴＥＸＴ．ＨＭＴファイル
メタデータのＴＥＸＴ．ＨＭＴ内のフィールドへのマッピングを、以下の表で概説する。

ＴＥＸＴ．ＨＭＴファイルの構造
図１２は、テキストメタデータを表すデータ構造を例示する。このファイルは、ファイル内の複数のデータ構造の間に隙間がないように書かれるべきである。

ヘッダセクション

識別子
このフィールドは、８バイトのＡＳＣＩＩによる「ＴＥＸＴ＿ＨＭＴ」であるべきである。

バージョン
この２バイトエントリは、このファイルを書くために使用されたＨＭＴ仕様のバージョンを表す。たとえば、バージョン１．２０は０×７８（１０進で１２０）として格納される。

ファイルサイズ
このフィールドは、ＴＥＸＴ．ＨＭＴファイルのサイズを４バイトで含むべきである。

コンテンツエントリの数
この４バイトエントリは、ここで定義されたオフセットでのコンテンツテキストエントリの数を定義する。

グループエントリの数
この４バイトエントリは、ここで定義されたオフセットでのグループテキストエントリの数を定義する。

追加テキストエントリの数
この４バイトエントリは、ここで定義されたオフセットでの追加テキストエントリの数を定義する。

コンテンツテキストエントリのオフセット
この４バイトエントリは、ＴＥＸＴ．ＨＭＴの先頭からコンテンツテキストエントリテーブルへのオフセットである。

グループテキストエントリのオフセット
この４バイトエントリは、ＴＥＸＴ．ＨＭＴの先頭からグループテキストエントリテーブルへのオフセットである。

追加テキストエントリのオフセット
この４バイトエントリは、ＴＥＸＴ．ＨＭＴの先頭から追加テキストエントリテーブルへのオフセットである。

ＬＣＩＤ
この４バイトエントリは、このＭＥＮＵ．ＨＭＴファイルの言語ＩＤである。

ディスク名の長さ
この２バイトエントリは、ディスク名のバイト長から終了の空白ＵＣＳ−２文字（２つの空バイト）を除いたものを含む。

ディスク名
この可変長エントリはディスクの名前を表す。ディスク名はＵＣＳ−２であり、空白のＵＣＳ−２文字（２つの空バイト）で終了されるべきである。このエントリの最大長は、空白のＵＣＳ−２文字を含む６５のＵＣＳ−２文字である。

テキストエントリ
すべてのテキスト項目は、以下のフォーマットを使用して格納される。

長さ
この２バイトエントリは、テキストのバイト長から終了の空白ＵＣＳ−２文字（２つの空バイト）を除いたものを含む。

テキスト
これはＵＣＳ−２テキストエントリである。このテキストは、空白のＵＣＳ−２文字（２つの空バイト）で終了されるべきである。このテキストエントリの最大長は以下の通りである。

この長さはＵＣＳ−２文字として定義され、終了の空白のＵＣＳ−２文字を含む。

コンテンツテキストエントリテーブル
コンテンツテキストエントリテーブルは、コンテンツテキストエントリのリストを含む。ＣＯＮＴＥＮＴＳ．ＨＭＴ内の各ファイル（プレイリスト、オーディオ、メニュー画像、画像およびビデオ）について１つのコンテンツテキストエントリが、これらのファイルがＣＯＮＴＥＮＴＳ．ＨＭＴ内でリストされる順序と同じ順序で存在するべきである。

コンテンツＩＤ
この４バイトエントリは、ここで定義されたこのコンテンツテキストエントリについてのコンテンツＩＤを表す。

テキスト１エントリのオフセット
この４バイトエントリは、ＴＥＸＴ．ＨＭＴの先頭から、ここで定義されたテキスト１エントリの最初のバイトについてのオフセットを表す。ＣＯＮＴＥＮＴＳ．ＨＭＴ内の各コンテンツ項目がテキスト１エントリを有することが必要とされる。

テキスト２エントリのオフセット
この４バイトエントリは、ＴＥＸＴ．ＨＭＴの先頭から、ここで定義されたテキスト２エントリの最初のバイトについてのオフセットを表す。コンテンツ項目がテキスト２データを有していない場合、このエントリは０であるべきである。

テキスト３エントリのオフセット
この４バイトエントリは、ＴＥＸＴ．ＨＭＴの先頭から、ここで定義されたテキスト３エントリの最初のバイトについてのオフセットを表す。コンテンツ項目がテキスト３データを有していない場合、このエントリは０であるべきである。

テキスト４エントリのオフセット
この４バイトエントリは、ＴＥＸＴ．ＨＭＴの先頭から、ここで定義されたテキスト４エントリの最初のバイトについてのオフセットを表す。コンテンツ項目がテキスト４データを有していない場合、このエントリは０であるべきである。

テキスト５エントリのオフセット
この４バイトエントリは、ＴＥＸＴ．ＨＭＴの先頭から、ここで定義されたテキスト５エントリの最初のバイトについてのオフセットを表す。コンテンツ項目がテキスト５データを有していない場合、このエントリは０であるべきである。

追加テキストエントリのオフセット
この４バイトエントリは、ＴＥＸＴ．ＨＭＴの先頭から追加テキストエントリの最初のバイトについてのオフセットを表す。コンテンツ項目が追加テキストデータを有していない場合、このエントリは０であるべきである。

グループテキストエントリテーブル
グループテキストエントリテーブルは、グループテキストエントリのリストを含む。ＣＯＮＴＥＮＴＳ．ＨＭＴ内でリストされたプレイリストファイル内の各グループについて、１つのグループテキストエントリがあるべきである。これらのエントリは、グループ番号の昇順であるべきである。

グループ番号
この４バイトエントリは、このグループテキストエントリについてのグループ番号を表す。

グループ名テキストエントリのオフセット
この４バイトエントリは、ＴＥＸＴ．ＨＭＴの先頭から、ここで定義されたグループ名テキストエントリの最初のバイトについてのオフセットを表す。各グループが名前を有することが必要とされる。

追加テキストエントリテーブル
追加テキストエントリテーブルは、ここで定義されたゼロまたはそれ以上の追加テキストエントリとして定義される。これらのエントリは、コンテンツＩＤの昇順で格納されるべきである。追加テキストエントリおよび追加テキストエントリの数のフィールドがゼロである場合、追加テキストエントリのベースオフセット、および追加テキストデータのベースオフセットはすべて０であるべきである。

コンテンツＩＤ
この４バイトエントリは、ここで定義されたＣＯＮＴＥＮＴＳ．ＨＭＴ内のこの追加テキストエントリに関連付けられたファイルのコンテンツＩＤを表す。

追加テキストデータの数
この１バイトエントリは、この追加テキストエントリによって関連付けられた追加テキストデータの数を表す。

予約済
この１バイトエントリは将来の使用のために予約される。

ｎ番目のテキストデータのタイプ
この２バイトエントリは、以下の表で定義された値のうち１つを含む。

ｎ番目のテキストエントリのオフセット
この４バイトエントリは、ＴＥＸＴ．ＨＭＴの先頭から、ここで定義された各追加テキストエントリの最初のバイトについてのオフセットを表す。

ＬＳＮファイルヘッダ

識別子
この８バイトエントリは、ＡＳＣＩＩによる「ＬＳＮ＿ＨＭＴ」を含む。

バージョン
この２バイトエントリは、このファイルを書くために使用されたＨＭＴ仕様のバージョンを表す。たとえば、バージョン１．２０は０×７８（１０進で１２０）として格納される。

ＨＭＴ世代
この８バイトエントリは、このＬＳＮ．ＨＭＴに合致するＨＭＴファイルの世代を表す。このＬＳＮ．ＨＭＴは、同じＨＭＴ世代番号を含むＣＯＮＴＥＮＴＳ．ＨＭＴファイルと共にのみ使用されるべきである。オーサリングソフトウェアは一意の乱数値を生成して、２つのファイルが偶然に合致しないことを保証するべきである。

ＬＳＮ．ＨＭＴのサイズ
この４バイトエントリは、ＬＳＮ．ＨＭＴのサイズをバイトで含む。

ＬＳＮエントリの数
この４バイトエントリは、ＬＳＮ．ＨＭＴで定義されるエントリの数を含む。

ＬＳＮ
この４バイトエントリは、同じ索引を有するＣＯＮＴＥＮＴＳ．ＨＭＴ内の項目についての論理セクタ番号を含む。

ファイルサイズ
この４バイトエントリは、同じ索引を有するＣＯＮＴＥＮＴＳ．ＨＭＴ内の項目についてのファイルサイズをバイトで含む。

本発明を実施することができる適切なメディア環境の一実施例を例示するブロック図である。 本発明によるオーサリングソフトウェアの例示的オペレーションを例示する流れ図である。 マルチセッションコンピュータ可読媒体を例示する流れ図である。 本発明によるレンダリングソフトウェアの例示的オペレーションを例示する流れ図である。 本発明のソフトウェアと共に使用するための例示的圧縮メディアフォーマットを例示するブロック図である。 本発明を実施することができる適切なコンピューティングシステム環境の一実施例を例示するブロック図である。 メモリ最適化データのためのファイルシステム構造を例示する例示的ブロック図である。 ロケール情報を表すデータ構造を例示する例示的ブロック図である。 コンピュータ可読媒体上のすべてのメディアファイルについての情報を表すデータ構造を例示する例示的ブロック図である。 プレイリストファイルを表すデータ構造を例示する例示的ブロック図である。 階層メニュー構造を例示する例示的ブロック図である。 テキストメタデータを表すデータ構造を例示する例示的ブロック図である。

符号の説明

１００ システム
１０２ コンピュータ
１０４ ＣＤ
１０６ カムコーダ
１０８ カメラ
１１０ コンピュータ可読媒体
１１２ 家電デバイス
１１４ 入力モジュール
１１６ フィルタモジュール
１１８ ユーザインターフェイスモジュール

Claims (40)

1. メディアプレイヤを動作させる方法であって、
   コンピュータ可読媒体上に記憶されたすべてのメディアファイルから選択された１つまたは複数のメディアファイルについてのメタデータを取得するステップであって、前記得られたメタデータは、前記コンピュータ可読媒体上の前記選択されたメディアファイルのそれぞれの位置への参照を含み、前記得られたメタデータはさらに、前記選択されたメディアファイルのそれぞれに関連付けられたコンテンツを記述する、ステップと、
   前記選択されたメディアファイルをレンダリングする前に前記メディアプレイヤによってアクセス可能であるデータ構造を作成するステップと、
   前記作成されたデータ構造を、前記得られたメタデータによりポピュレートするステップと、
   前記ポピュレートされたデータ構造を、前記コンピュータ可読媒体上の複数のセッション中の最後のセッションで、メモリ最適化データとして、前記選択されたメディアファイルと共に格納するステップと、
   を含み、
   前記メモリ最適化データが前記コンピュータ可読媒体上の複数のセッション中の最後のセッション内にある場合、前記メディアプレイヤは、前記格納されたメモリ最適化データにアクセスして前記メタデータをユーザに提示し、前記参照を介してメディアファイルをナビゲートし、レンダリングし、
   前記メモリ最適化データが前記コンピュータ可読媒体上の複数のセッション中の最後のセッション内にない場合、前記メディアプレイヤは、前記選択されたメディアファイルから、または、データ通信ネットワークを介したネットワークサーバから、または、両方から、メタデータを直接取得して当該メタデータをユーザに提示し、当該メタデータ中のメディアファイルのそれぞれの位置への参照を介してメディアファイルをナビゲートし、レンダリングし、メモリ最適化データが前記複数のセッション中の最後のセッション以外のセッションにあったとしても、そのメモリ最適化データを無視することを特徴とする方法。
2. 前記ポピュレートするステップは、
   数値識別子を前記選択されたメディアファイルに関連づけるステップであって、前記数値識別子は、順番に順序付けられ、前記数値識別子のそれぞれは、前記選択されたメディアファイルの１つにそれぞれ対応する、ステップと、
   前記数値識別子を前記データ構造に格納するステップと、
   を含むことを特徴とする請求項１に記載の方法。
3. 前記選択されたメディアファイルは、プレイリストまたはメニュー画像ファイルまたは両方を備えることを特徴とする請求項１に記載の方法。
4. 前記ポピュレートするステップは、
   前記選択されたメディアファイルをディレクトリにより編成するステップと、
   前記編成されたメディアファイルをソートするステップと、
   をさらに含むことを特徴とする請求項１に記載の方法。
5. 前記メタデータを取得するステップは、前記選択されたメディアファイルの１つまたは複数を参照するプレイリストを生成するステップを含むことを特徴とする請求項１に記載の方法。
6. 前記コンピュータ可読媒体上に記憶されたすべてのメディアファイルは、圧縮されていることを特徴とする請求項１に記載の方法。
7. 前記メタデータを取得するステップは、前記選択されたメディアファイルのそれぞれについて、論理セクタ番号を識別するステップを含むことを特徴とする請求項１に記載の方法。
8. 前記メタデータを取得するステップは、前記選択されたメディアファイルを識別するメニュー情報を取得するステップを含むことを特徴とする請求項１に記載の方法。
9. 前記メタデータを取得するステップは、前記選択されたメディアファイルの１つまたは複数に対応するサムネイル画像を取得するステップを含むことを特徴とする請求項１に記載の方法。
10. 前記メタデータを取得するステップは、前記選択されたメディアファイルに関連付けられたメニュー情報に対応する言語を識別するステップを含むことを特徴とする請求項１に記載の方法。
11. 前記メタデータが、対応するメディアファイルのタイトル、作曲家、演奏者、ジャンル、スタジオ、ディレクター、評価、アーティスト、およびコンテンツの説明のうち１つまたは複数から選択されることを特徴とする請求項１に記載の方法。
12. 前記メタデータが、作曲家、演奏者、ジャンル、スタジオ、ディレクター、評価、およびアーティストのうち１つまたは複数を備えることを特徴とする請求項１に記載の方法。
13. 請求項１に記載の方法を実施するためのコンピュータ実行可能命令を有することを特徴とする１つまたは複数のコンピュータ可読媒体。
14. メディアプレイヤを動作させるためのコンピュータ実行可能コンポーネントを有する１つまたは複数のコンピュータ可読媒体であって、前記コンポーネントは、
    第２のコンピュータ可読媒体上に記憶されたすべてのメディアファイルから選択された１つまたは複数のメディアファイルについてのメタデータを取得するための準備モジュールであって、前記得られたメタデータは、前記第２のコンピュータ可読媒体上の前記選択されたメディアファイルのそれぞれの位置への参照を含み、前記得られたメタデータはさらに、前記選択されたメディアファイルのそれぞれに関連付けられたコンテンツを記述する、準備モジュールと、
    前記選択されたメディアファイルをレンダリングする前に前記メディアプレイヤによってアクセス可能であるデータ構造を作成するための初期化モジュールと、
    前記初期化モジュールからの前記作成されたデータ構造を、前記準備モジュールからの前記得られたメタデータによりポピュレートするための編成モジュールと、
    前記編成モジュールからの前記ポピュレートされたデータ構造を前記第２のコンピュータ可読媒体上の複数のセッション中の最後のセッションで、メモリ最適化データとして、前記選択されたメディアファイルと共に格納するためのライタモジュールと、
    を備え、
    前記メモリ最適化データが前記第２のコンピュータ可読媒体上の複数のセッション中の最後のセッション内にある場合、前記メディアプレイヤは、前記格納されたメモリ最適化データにアクセスして前記メタデータをユーザに提示し、前記参照を介してメディアファイルをナビゲートし、レンダリングし、
    前記メモリ最適化データが前記第２のコンピュータ可読媒体上の複数のセッション中の最後のセッション内にない場合、前記メディアプレイヤは、前記選択されたメディアファイルから、または、データ通信ネットワークを介したネットワークサーバから、または、両方から、メタデータを直接取得して当該メタデータをユーザに提示し、当該メタデータ中のメディアファイルのそれぞれの位置への参照を介してメディアファイルをナビゲートし、レンダリングし、メモリ最適化データが前記複数のセッション中の最後のセッション以外のセッションにあったとしても、そのメモリ最適化データを無視することを特徴とする、１つまたは複数のコンピュータ可読媒体。
15. 前記編成モジュールは、数値識別子を前記選択されたメディアファイルに関連付け、前記数値識別子が順番に順序付けられ、各々は前記選択されたメディアファイルの各々に対応し、前記編成モジュールは前記数値識別子を前記データ構造に格納することを特徴とする請求項１４に記載の１つまたは複数のコンピュータ可読媒体。
16. 前記準備モジュールは、前記選択されたメディアファイルの各々についての論理セクタ番号を識別することを特徴とする請求項１４に記載の１つまたは複数のコンピュータ可読媒体。
17. メディアプレイヤを動作させる方法であって、
    メディアファイルをレンダリングする前に、コンピュータ可読媒体上のメモリ最適化データを検索するステップであって、前記メモリ最適化データは、前記コンピュータ可読媒体上に格納されたすべてのメディアファイルから選択されるメディアファイルの１つまたは複数に関連付けられ、前記メモリ最適化データは、前記コンピュータ可読媒体上の前記選択されたメディアファイルのそれぞれの位置への参照を含み、前記メモリ最適化データはさらに、前記選択されたメディアファイルのそれぞれに関連付けられたコンテンツを記述する、ステップと、
    前記検索された、前記メモリ最適化データに応答して、前記選択されたメディアファイルを識別するステップと、
    を含み、
    前記メモリ最適化データが前記コンピュータ可読媒体上の複数のセッション中の最後のセッション内にある場合、前記メディアプレイヤは、前記格納されたメモリ最適化データにアクセスして前記選択されたメディアファイルのそれぞれに関連付けられた位置及びコンテンツにアクセスし、
    前記メモリ最適化データが前記コンピュータ可読媒体上の複数のセッション中の最後のセッション内にない場合、前記メディアプレイヤは、前記選択されたメディアファイルから、または、データ通信ネットワークを介したネットワークサーバから、または、両方から、前記位置及びコンテンツを直接取得し、メモリ最適化データが前記複数のセッション中の最後のセッション以外のセッションにあったとしても、そのメモリ最適化データを無視し、前記選択されたメディアファイルが、前記メディアプレイヤによってレンダリングされるように適合されることを特徴とする方法。
18. 前記メモリ最適化データの少なくとも一部を前記メディアプレイヤによって、前記選択されたメディアファイルのレンダリング中に前記メモリ最適化データに関連付けられた前記選択されたメディアファイルと関連して表示するステップを、さらに含むことを特徴とする請求項１７に記載の方法。
19. 前記識別するステップは、前記コンピュータ可読媒体上に格納された複数のメディアファイルから前記選択されたメディアファイルを識別するステップを含むことを特徴とする請求項１７に記載の方法。
20. 前記メモリ最適化データを介して前記選択されたメディアファイルに関連付けられるメタデータを取得するステップと、
    前記得られたメタデータをユーザに、前記メディアプレイヤに関連付けられたディスプレイ上で表示するステップと、
    を、前記選択されたメディアファイルをレンダリングする前に、さらに含むことを特徴とする請求項１７に記載の方法。
21. 前記メタデータを取得するステップは、前記メモリ最適化データを介して論理セクタ番号を読むステップを含み、前記論理セクタ番号のそれぞれが、前記選択されたメディアファイルの１つをそれぞれ識別することを特徴とする請求項２０に記載の方法。
22. 前記選択されたメディアファイルの１つを格納するファイルシステムと前記選択されたメディアファイルの前記１つに関連付けられたファイル名とを合致させることによって、前記選択されたメディアファイルの前記１つについて論理セクタ番号を識別するステップを、前記選択されたメディアファイルをレンダリングする前に、さらに含むことを特徴とする請求項２０に記載の方法。
23. 前記メタデータを取得するステップは、前記メモリ最適化データからメニュー情報を読むステップを含み、前記メニュー情報が、前記選択されたメディアファイルを識別することを特徴とする請求項２０に記載の方法。
24. 前記メニュー情報を読むステップは、前記選択されたメディアファイルの１つに対する前記メモリ最適化データからメニュー情報を読むステップを含むことを特徴とする請求項２３に記載の方法。
25. 前記メニュー情報は、前記選択されたメディアファイルに関連付けられたメニュー内の位置に対応し、前記メニュー情報への参照を格納するステップを、さらに含むことを特徴とする請求項２３に記載の方法。
26. 前記メタデータを取得するステップは、前記メモリ最適化データを介してサムネイル画像を取得するステップを含み、前記サムネイル画像が、前記選択されたメディアファイルの１つまたは複数に対応することを特徴とする請求項２０に記載の方法。
27. 前記メタデータを取得するステップは、前記メモリ最適化データからプレイリストを読むステップを含み、前記プレイリストが、前記選択されたメディアファイルの１つまたは複数を識別することを特徴とする請求項２０に記載の方法。
28. 前記メタデータを取得するステップは、前記メモリ最適化データから言語を識別するステップを含み、前記識別された言語が、前記選択されたメディアファイルに関連付けられたメニュー情報に対応することを特徴とする請求項２０に記載の方法。
29. 前記得られたメタデータを前記メディアプレイヤに関連付けられたメモリ内に格納するステップと、
    前記メモリから前記表示されたメタデータを消去するステップと、
    を、前記選択されたメディアファイルをレンダリングする前に、さらに含むことを特徴とする請求項２０に記載の方法。
30. 前記得られたメタデータが、対応するメディアファイルのタイトル、作曲家、演奏者、ジャンル、スタジオ、ディレクター、評価、アーティスト、およびコンテンツの説明のうち１つまたは複数から選択されることを特徴とする請求項２０に記載の方法。
31. 請求項１７に記載の方法を実施するためのコンピュータ実行可能命令を有することを特徴とする１つまたは複数のコンピュータ可読媒体。
32. メディアプレイヤのオペレーションを最適化するためのコンピュータ実行可能コンポーネントを格納する１つまたは複数のコンピュータ可読媒体を有するメディアプレイヤであって、前記メディアプレイヤは、第２のコンピュータ可読媒体にアクセスして、その上に格納されたメディアファイルをレンダリングし、前記第２のコンピュータ可読媒体はさらに、前記メディアファイルに関連付けられたメモリ最適化データを格納し、前記コンポーネントは、
    前記メディアファイルをレンダリングする前に、前記第２のコンピュータ可読媒体上の前記メモリ最適化データを検索する入力モジュールであって、前記メモリ最適化データは、前記コンピュータ可読媒体上に格納されたすべてのメディアファイルから選択されるメディアファイルの１つまたは複数に関連付けられ、前記メモリ最適化データは、前記第２のコンピュータ可読媒体上の前記選択されたメディアファイルのそれぞれの位置への参照を含み、前記メモリ最適化データはさらに、前記選択されたメディアファイルのそれぞれに関連付けられたコンテンツを記述する、入力モジュールと、
    前記検索された、前期入力モジュールからの前記メモリ最適化データに応答して、前記選択されたメディアファイルを識別するフィルタモジュールと、
    を備え、
    前記メモリ最適化データが前記第２のコンピュータ可読媒体上の複数のセッション中の最後のセッション内にある場合、前記メディアプレイヤは、前記格納されたメモリ最適化データにアクセスして前記選択されたメディアファイルのそれぞれに関連付けられた位置及びコンテンツにアクセスし、
    前記メモリ最適化データが前記第２のコンピュータ可読媒体上の複数のセッション中の最後のセッション内にない場合、前記メディアプレイヤは、前記選択されたメディアファイルから、または、データ通信ネットワークを介したネットワークサーバから、または、両方から、前記位置及びコンテンツを直接取得し、メモリ最適化データが前記複数のセッション中の最後のセッション以外のセッションにあったとしても、そのメモリ最適化データを無視し、前記選択されたメディアファイルが、前記メディアプレイヤによってレンダリングされるように適合されることを特徴とするメディアプレイヤ。
33. 前記メモリ最適化データの少なくとも一部を、前記選択されたメディアファイルのレンダリング中に前記メモリ最適化データに関連付けられた前記選択されたメディアファイルと関連して表示するユーザインターフェイスモジュールを、さらに備えることを特徴とする請求項３２に記載のメディアプレイヤ。
34. 前記フィルタモジュールは、前記コンピュータ可読媒体上に格納された複数のメディアファイルから前記選択されたメディアファイルを識別することを特徴とする請求項３２に記載のメディアプレイヤ。
35. 前記フィルタモジュールは、前記メモリ最適化データを介して前記選択されたメディアファイルに関連付けられるメタデータを取得し、前記フィルタモジュールは、前記得られたメタデータをユーザに、前記メディアプレイヤに関連付けられたディスプレイ上で表示することを特徴とする請求項３２に記載のメディアプレイヤ。
36. 前記フィルタモジュールは、前記メモリ最適化データを介して論理セクタ番号を読み、前記論理セクタ番号のそれぞれが、前記選択されたメディアファイルの１つをそれぞれ識別することを特徴とする請求項３２に記載のメディアプレイヤ。
37. 前記フィルタモジュールは、前記メモリ最適化データからメニュー情報を読み、前記メニュー情報が、前記選択されたメディアファイルを識別することを特徴とする請求項３２に記載のメディアプレイヤ。
38. 前記フィルタモジュールは、前記メモリ最適化データを介してサムネイル画像を取得し、前記サムネイル画像が、前記選択されたメディアファイルの１つまたは複数に対応することを特徴とする請求項３２に記載のメディアプレイヤ。
39. 前記フィルタモジュールは、前記メモリ最適化データからプレイリストを読み、前記プレイリストが、前記選択されたメディアファイルの１つまたは複数に対応することを特徴とする請求項３２に記載のメディアプレイヤ。
40. 前記フィルタモジュールは、前記メモリ最適化データから言語を識別し、前記識別された言語が、前記選択されたメディアファイルに関連付けられたメニュー情報に対応することを特徴とする請求項３２に記載のメディアプレイヤ。

Images