JP5314097B2 - 記録装置および情報記録方法 - Google Patents

記録装置および情報記録方法 Download PDF

Info

Publication number
JP5314097B2
JP5314097B2 JP2011169448A JP2011169448A JP5314097B2 JP 5314097 B2 JP5314097 B2 JP 5314097B2 JP 2011169448 A JP2011169448 A JP 2011169448A JP 2011169448 A JP2011169448 A JP 2011169448A JP 5314097 B2 JP5314097 B2 JP 5314097B2
Authority
JP
Japan
Prior art keywords
information
playlist
title
menu
recorded
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2011169448A
Other languages
English (en)
Other versions
JP2011227990A (ja
Inventor
洋 矢羽田
繁樹 松永
航 池田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Corp
Panasonic Holdings Corp
Original Assignee
Panasonic Corp
Matsushita Electric Industrial Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Corp, Matsushita Electric Industrial Co Ltd filed Critical Panasonic Corp
Priority to JP2011169448A priority Critical patent/JP5314097B2/ja
Publication of JP2011227990A publication Critical patent/JP2011227990A/ja
Application granted granted Critical
Publication of JP5314097B2 publication Critical patent/JP5314097B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/804—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components
    • H04N9/8042—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components involving data reduction
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G11B20/12—Formatting, e.g. arrangement of data block or words on the record carriers
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/02—Editing, e.g. varying the order of information signals recorded on, or reproduced from, record carriers
    • G11B27/031—Electronic editing of digitised analogue information signals, e.g. audio or video signals
    • G11B27/034—Electronic editing of digitised analogue information signals, e.g. audio or video signals on discs
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/19—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier
    • G11B27/28—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording
    • G11B27/32—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording on separate auxiliary tracks of the same or an auxiliary record carrier
    • G11B27/327—Table of contents
    • G11B27/329—Table of contents on a disc [VTOC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/91—Television signal processing therefor
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00—Record carriers by type
    • G11B2220/20—Disc-shaped record carriers
    • G11B2220/21—Disc-shaped record carriers characterised in that the disc is of read-only, rewritable, or recordable type
    • G11B2220/215—Recordable discs
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00—Record carriers by type
    • G11B2220/20—Disc-shaped record carriers
    • G11B2220/25—Disc-shaped record carriers characterised in that the disc is based on a specific recording technology
    • G11B2220/2537—Optical discs
    • G11B2220/2541—Blu-ray discs; Blue laser DVR discs
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00—Record carriers by type
    • G11B2220/20—Disc-shaped record carriers
    • G11B2220/25—Disc-shaped record carriers characterised in that the disc is based on a specific recording technology
    • G11B2220/2537—Optical discs
    • G11B2220/2562—DVDs [digital versatile discs]; Digital video discs; MMCDs; HDCDs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/84—Television signal recording using optical recording
    • H04N5/85—Television signal recording using optical recording on discs or drums
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/804—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components
    • H04N9/806—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components with processing of the sound signal
    • H04N9/8063—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components with processing of the sound signal using time division multiplex of the PCM audio and PCM video signals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/82—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only
    • H04N9/8205—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/82—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only
    • H04N9/8205—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal
    • H04N9/8227—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal the additional signal being at least another television signal

Description

本発明は、記録した映像データの再生をユーザに指示させるためのメニューが付与された形式で映像データを記録した情報記録媒体、その記録装置及び記録方法に関する。
映像データを記録した情報記録媒体の代表格は、ＤＶＤ（以下、「Ｓｔａｎｄａｒｄ Ｄｉｆｉｎｉｔｉｏｎ（ＳＤ）−ＤＶＤ」ともいう。）である。以下に従来のＤＶＤについて説明する。
図１は、ＳＤ−ＤＶＤの構造を示す図である。図１の下段に示すように、ＤＶＤディスク上にはリードインからリードアウトまでの間に論理アドレス空間が設けられている。その論理アドレス空間には先頭からファイルシステムのボリューム情報が記録され、続いて映像音声などのアプリケーションデータが記録されている。
ファイルシステムとは、ＩＳＯ９６６０やＵｎｉｖｅｒｓａｌ Ｄｉｓｃ Ｆｏｒｍａｔ（ＵＤＦ）等の規格により定められたデータを管理する仕組みのことであり、ディスク上のデータをディレクトリまたはファイルと呼ばれる単位で表現する仕組みである。
日常使っているパーソナルコンピュータ（ＰＣ）の場合でも、Ｆｉｌｅ Ａｌｌｏｃａｔｉｏｎ Ｔａｂｌｅｓ（ＦＡＴ）またはＮＴ Ｆｉｌｅ Ｓｙｓｔｅｍ（ＮＴＦＳ）と呼ばれるファイルシステムにより、ディレクトリやファイルという構造でハードディスクに記録されたデータがコンピュータ上で表現され、ユーザビリティを高めている。
ＳＤ−ＤＶＤの場合、ＵＤＦ及びＩＳＯ９６６０の両方のファイルシステムが使用されている。両方を合わせて「ＵＤＦブリッジ」とも呼ばれる。記録されているデータはＵＤＦまたはＩＳＯ９６６０どちらのファイルシステムドライバによってもデータの読み出しができるようになっている。なお、ここで取り扱うＤＶＤはパッケージメディア用のＲＯＭディスクであり、物理的に書き込みが不可能である。
ＤＶＤ上に記録されたデータは、ＵＤＦブリッジを通して、図１左上に示すようなディレクトリまたはファイルとして見ることができる。ルートディレクトリ（図１における「ＲＯＯＴ」）の直下に「ＶＩＤＥＯ＿ＴＳ」と呼ばれるディレクトリが置かれ、ここにＤＶＤのアプリケーションデータが記録されている。アプリケーションデータは、複数のファイルとして記録され、主なファイルとして以下の種類のファイルがある。
ＶＩＤＥＯ＿ＴＳ．ＩＦＯ ディスク再生制御情報ファイル
ＶＴＳ＿０１＿０．ＩＦＯ ビデオタイトルセット＃１再生制御情報ファイル
ＶＴＳ＿０１＿０．ＶＯＢ ビデオタイトルセット＃１ストリームファイル
．．．．．
上記例に示すように２つの拡張子が規定されている。「ＩＦＯ」は再生制御情報が記録されたファイルであることを示す拡張子であり、「ＶＯＢ」はＡＶデータであるＭＰＥＧストリームが記録されたファイルであることを示す拡張子である。
再生制御情報とは、ＤＶＤで採用されたインタラクティビティ（ユーザの操作に応じて再生を動的に変化させる技術）を実現するための情報や、メタデータのような、ＡＶデータに付属する情報などのことである。また、ＤＶＤでは一般的に再生制御情報のことをナビゲーション情報と呼ぶことがある。
再生制御情報ファイルは、ディスク全体を管理する「ＶＩＤＥＯ＿ＴＳ．ＩＦＯ」と、個々のビデオタイトルセット毎の再生制御情報である「ＶＴＳ＿０１＿０．ＩＦＯ」がある。なお、ＤＶＤでは複数のタイトル、言い換えれば複数の異なる映画や楽曲を１枚のディスクに記録することが可能である。
ここで、ファイル名ボディにある「０１」はビデオタイトルセットの番号を示しており、例えば、ビデオタイトルセット＃２の場合は、「ＶＴＳ＿０２＿０．ＩＦＯ」となる。
図１の右上部は、ＤＶＤのアプリケーション層でのＤＶＤナビゲーション空間であり、前述した再生制御情報が展開された論理構造空間である。「ＶＩＤＥＯ＿ＴＳ．ＩＦＯ」内の情報は、ＶＩＤＥＯ Ｍａｎａｇｅｒ Ｉｎｆｏｒｍａｔｉｏｎ（ＶＭＧＩ）として、「ＶＴＳ＿０１＿０．ＩＦＯ」または、他のビデオタイトルセット毎に存在する再生制御情報はＶｉｄｅｏ Ｔｉｔｌｅ Ｓｅｔ Ｉｎｆｏｒｍａｔｉｏｎ（ＶＴＳＩ）としてＤＶＤナビゲーション空間に展開される。
ＶＴＳＩの中にはＰｒｏｇｒａｍ Ｃｈａｉｎ（ＰＧＣ）と呼ばれる再生シーケンスの情報であるＰｒｏｇｒａｍ Ｃｈａｉｎ Ｉｎｆｏｒｍａｔｉｏｎ（ＰＧＣＩ）が記述されている。ＰＧＣＩは、Ｃｅｌｌの集合とコマンドと呼ばれる一種のプログラミング情報によって構成されている。
Ｃｅｌｌ自身はＶＯＢ（Ｖｉｄｅｏ Ｏｂｊｅｃｔの略であり、ＭＰＥＧストリームを指す）の一部区間または全部区間を指定する情報であり、Ｃｅｌｌの再生は、当該ＶＯＢのＣｅｌｌによって指定された区間を再生することを意味している。
コマンドは、ＤＶＤの仮想マシンによって処理されるものであり、例えば、ウェブページを表示するブラウザ上で実行されるＪａｖａ（登録商標）スクリプトなどに近いものである。しかしながらＪａｖａ（登録商標）スクリプトが論理演算の他にウィンドウやブラウザの制御（例えば、新しいブラウザのウィンドウを開くなど）を行うのに対して、ＤＶＤのコマンドは、論理演算の他にＡＶタイトルの再生制御、例えば、再生するチャプターの指定などを実行するだけのものである点で異なっている。
Ｃｅｌｌはディスク上に記録されているＶＯＢの開始及び終了アドレス（論理アドレス）をその内部情報として有しており、プレーヤは、Ｃｅｌｌに記述されたＶＯＢの開始及び終了アドレス情報を使ってデータの読み出し、再生を実行する。
図２は、ＡＶデータであるＭＰＥＧストリーム中に埋め込まれているナビゲーション情報を説明する概要図である。
ＳＤ−ＤＶＤの特長であるインタラクティビティは前述した「ＶＩＤＥＯ＿ＴＳ．ＩＦＯ」や「ＶＴＳ＿０１＿０．ＩＦＯ」などに記録されているナビゲーション情報だけによって実現されているのではなく、幾つかの重要な情報はナビゲーション・パック（ナビパックまたは、ＮＶ＿ＰＣＫという。）と呼ばれる専用キャリアを使いＶＯＢ内に映像、音声データと一緒に多重化されている。
ここでは簡単なインタラクティビティの例としてメニュー画面について説明する。メニュー画面上には、幾つかのボタンが現れ、それぞれのボタンには当該ボタンが選択実行された時の処理が定義されている。
また、メニュー画面上では一つのボタンが選択されており（選択ボタン上に半透明色がオーバーレイされることで該ボタンがハイライトされ、該ボタンが選択状態であることをユーザに示す）、ユーザは、リモコンの上下左右キーを使って、選択状態のボタンを上下左右の何れかのボタンに移動させることが出来る。
リモコンの上下左右キーを使って、選択実行したいボタンまでハイライトを移動させ、決定する（決定キーを押す）ことによって対応するコマンドのプログラムが実行される。一般的には対応するタイトルやチャプターの再生がコマンドによって実行されている（例えば、特許文献１参照）。
図２の左上部はＮＶ＿ＰＣＫに格納される情報の概要を示している。ＮＶ＿ＰＣＫ内には、ハイライトカラー情報と個々のボタン情報などが含まれている。ハイライトカラー情報には、カラーパレット情報が記述され、オーバーレイ表示されるハイライトの半透明色が指定される。
ボタン情報には、個々のボタンの位置情報である矩形領域情報と、当該ボタンから他のボタンへの移動情報（ユーザの上下左右キー操作それぞれに対応する移動先ボタンの指定）と、ボタンコマンド情報（当該ボタンが決定された時に実行されるコマンド）とが記述されている。
メニュー画面上のハイライトは、図２の右上部に示すように、オーバーレイ画像として作られる。オーバーレイ画像は、ボタン情報の矩形領域情報にカラーパレット情報の色を付した物である。このオーバーレイ画像は図２の右部に示す背景画像と合成されて画面上に表示される。
前述のようにして、ＤＶＤではメニュー画面を実現している。また、何故、ナビゲーションデータの一部をＮＶ＿ＰＣＫを使ってストリーム中に埋め込んでいるのかについては、以下の理由からである。
すなわち、ストリームと同期して動的にメニュー情報を更新、例えば、映画再生中の途中５分〜１０分の間にだけメニュー画面を表示するといった、同期タイミングが問題となりやすい処理を問題なく実現できるようにするためである。
また、もう一つの大きな理由は、ＮＶ＿ＰＣＫには特殊再生を支援するための情報を格納し、ＤＶＤ再生時の早送り、巻き戻しなどの非通常再生時にも円滑にＡＶデータをデコードし再生させる等、ユーザの操作性を向上させるためである。
図３は、ＤＶＤにおけるＶＯＢの構成を示す概要図である。図に示すように、映像、音声、字幕などのデータ（図３の（１））は、ＭＰＥＧシステム（ＩＳＯ／ＩＥＣ１３８１８−１）規格に基づいて、パケット及びパック化し（図３の（２））、それぞれを多重化して１本のＭＰＥＧプログラムストリームにしている（図３の（３））。
また、前述した通りインタラクティブを実現するためのボタンコマンドを含んだＮＶ＿ＰＣＫも一緒に多重化をされている。
ＭＰＥＧシステムの多重化の特徴として、多重化する個々のデータは、そのデコード順に基づくビット列になっているが、多重化されるデータ間、即ち、映像、音声、字幕の間は必ずしも再生順、言い換えればデコード順に基づいてビット列が形成されているわけではないことが挙げられる。
これはＭＰＥＧシステムストリームのデコーダモデル（図３の（４）、一般にＳｙｓｔｅｍ Ｔａｒｇｅｔ Ｄｅｃｏｄｅｒ、またはＳＴＤと呼ばれる）が多重化を解いた後に個々のエレメンタリストリームに対応するデコーダバッファを持ち、デコードタイミングまでに一時的にデータを蓄積している事に由来している。
このデコーダバッファは、個々のエレメンタリストリーム毎にサイズが異なり、映像に対しては、２３２ｋＢ、音声に対しては４ｋＢ、字幕に対しては５２ｋＢをそれぞれ有している。
このため、各デコーダバッファへのデータ入力タイミングは個々のエレメンタリストリームで異なるため、ＭＰＥＧシステムストリームとしてビット列を形成する順番と表示（デコード）されるタイミングにずれが生じている。
即ち、映像データと並んで多重化されている字幕データが必ずしも同一タイミングでデコードされているわけでは無い。
以上述べたようなＤＶＤに関する技術は、下記の特許文献２に記載されている。
特願平８−８３４７８号公報 特許第２８１３２４５号公報
ここで、現在、撮影した映像等のデジタルコンテンツ（以下、単に「コンテンツ」という。）を、情報記録媒体である前述のＤＶＤ等のディスクに逐次記録する各種のビデオカメラレコーダ（以下、単に「ビデオカメラ」という。）が多くのメーカーで生産され、広く流通している。
また、これらビデオカメラは、独自のメニュー画面を生成し、ディスクに書き込む機能を有している。このメニュー画面を以下、「ディスクメニュー」という。
ユーザは、ビデオカメラで情報記録媒体に映像を記録し、その情報記録媒体をプレーヤで再生すると、そのビデオカメラで生成されたディスクメニューを見ることができる。また、そのメニューから再生等の対象とするタイトルの選択を行うことができる。
しかしながら、様々なメーカーで生産される各種のビデオカメラにおいて、ディスクメニューに係る各種ファイルの記述内容や構成等が統一されているわけではない。
つまり、あるメーカーのビデオカメラで生成されたディスクメニューを、他のメーカーのビデオカメラが解釈することは実質的に不可能である。
そのため、例えば、あるメーカーのビデオカメラで映像が記録されたディスクが、他のメーカーのビデオカメラにロードされ、新たなタイトルの追加等が行われた場合、当該他のメーカーのカメラでは、記録済みのディスクメニューに関するファイルを削除し、新たにディスクメニューを作成する必要がある。
この場合、ディスクがロードされたビデオカメラでは、記録済みのディスクメニューに関連する各種ファイルを、そのディスクメニューの再生を制御するプログラム等を解析することにより探し出すという、極めて高度な解析作業が必要となる。
そのため、ディスクがセットされた後に、映像の記録等の動作が開始可能となるまで長時間掛かることになり、実質的には、上記の各種ファイルを探し出せないといった問題がある。
また、新たなディスクメニューを記録する際に、不要となった既存のディスクメニューに関連するファイルを削除しない場合、不要なファイルがディスクに蓄積していくことになる。これにより、ディスクの記録可能容量を不要に圧迫するだけでなく、当該ディスクを使用する記録装置および再生装置においてファイル管理に係る処理負荷が増加することになる。
そこで本発明は、上記従来の課題を考慮し、ある記録装置で生成されたメニューが情報記録媒体に記録された後にその情報記録媒体が他の記録装置にセットされた場合、当該他の記録装置において本来的には不要な処理負荷および処理時間を発生させないための記録装置、および、情報記録方法を提供することを目的とする。
上記目的を達成するために、本発明の情報記録方法は、映像情報を符号化する際に、映像情報への付随情報を同時に符号化して、情報記録媒体に情報を記録する情報記録方法であって、前記付随情報は、映像情報のピクチャ単位に付与されており、前記付随情報が、同じ種類且つ精度が異なる複数の情報を含む場合、精度の低い情報を、精度の高い情報よりも記録の順番で先に、前記情報記録媒体に記録することを特徴とする。
これにより、メタデータの検索性を向上することができ、同一種類のメタデータが別個の方法で記録されている場合であっても、機器の性能に応じて容易に解析することが可能となる。
また、情報記録媒体は、デジタルストリームの一部または全部である部分区間で構成されるＡＶコンテンツであるタイトルが記録された情報記録媒体であって、デジタルストリームにおける部分区間の位置と、再生順序とを指定することで前記タイトルを特定する情報を有するプレイリストと、前記プレイリストを呼び出すことにより前記タイトルの再生を制御するプログラムと、前記タイトルを識別するタイトル識別情報と、前記プログラムを識別するプログラム識別情報とが対応付けられて含まれているインデックス情報と、前記タイトル識別情報と前記プレイリストを識別するプレイリスト識別情報とが対応付けられて含まれている拡張情報とが記録されている。
これにより、本発明の情報記録媒体を使用する記録装置が、情報記録媒体に記録するタイトルの１つであるメニューを削除する際に、そのメニューの再生を制御するプログラムを解析することなく、そのメニューに関連するプレイリストを容易に特定することができる。
従って、例えば、記録装置であるビデオカメラにおいて、他のビデオカメラが生成しディスクに記録したディスクメニューを削除する際、ディスクメニューに関連するプレイリストを特定し、削除することができる。
また、この削除に係る作業において、プログラムの解析等を行う必要がなく、容易に削除すべきプレイリストを特定することができる。つまり、本発明の情報記録媒体を使用する記録装置において、本来的には不要な処理負荷および処理時間が発生することがない。
また、本発明の記録装置は、映像情報を符号化する際に、映像情報への付随情報を同時に符号化して、情報記録媒体に情報を記録する記録装置であって、前記付随情報は、映像情報のピクチャ単位に付与されており、前記付随情報が、同じ種類且つ精度が異なる複数の情報を含む場合、精度の低い情報を、精度の高い情報よりも記録の順番で先に、前記情報記録媒体に記録する記録手段を有する。
これにより、メタデータの検索性を向上することができ、同一種類のメタデータが別個の方法で記録されている場合であっても、機器の性能に応じて容易に解析することが可能となる。
また、記録装置は、前記情報記録媒体にデジタルストリームを記録する記録装置であって、前記情報記録媒体には、複数のタイトルが記録されており、前記複数のタイトルのうちの１つは、自身以外のタイトルをユーザに選択させるメニューであり、前記記録装置は、前記メニューの再生を制御するプログラムから呼び出されるプレイリストを、前記拡張情報に含まれる、前記メニューのタイトル識別情報に対応付けられた前記プレイリスト識別情報を用いて特定するプレイリスト特定手段と、前記メニューに換えて、新たなメニューを生成し前記情報記録媒体に記録するメニュー生成手段と、前記メニュー生成手段により前記新たなメニューが生成される場合、前記プレイリスト特定手段により特定されたプレイリストを削除する削除手段とを備えるとしてもよい。
これにより、本発明の記録装置は、容易にタイトルに関連するプレイリストを特定することができ、そのプレイリストを削除することができる。
従って、例えば、ビデオカメラとして本発明の記録装置を実現した場合、他メーカーのビデオカメラによりディスクメニューが記録されたＤＶＤや半導体メモリ等の情報記録媒体から、容易にそのディスクメニューに関連するプレイリストを削除することができる。
つまり、不要なファイルを削除した上で、新たなディスクメニューを生成し、当該情報記録媒体に記録することができる。また、このように、不要なファイルを削除することで、当該情報記録媒体の記録可能容量を無駄に消費することがなく、またファイル管理に係る処理負荷の増加を抑えることができる。
なお、本発明は、このような情報記録装置として実現することができるだけでなく、このような情報記録装置が備える特徴的な手段を有する集積回路として実現することもできる。これら特徴的な手段は、個別に１チップ化されても良いし、これらのうちの一部又はすべてを含むように１チップ化されても良い。
また、本発明は、このような情報記録装置が備える特徴的な手段をステップとする記録方法として実現したり、それらのステップをコンピュータに実行させるプログラムとして実現したりすることもできる。そして、そのようなプログラムは、ＣＤ−ＲＯＭ等の記録媒体やインターネット等の伝送媒体を介して配信することができるのは言うまでもない。
また、本発明は、本発明の情報記録媒体から情報を読み取って再生する再生装置として実現したり、このような再生装置が備える特徴的な手段をステップとする再生方法として実現したり、それらのステップをコンピュータに実行させるプログラムとして実現したりすることもできる。そして、そのようなプログラムは、ＣＤ−ＲＯＭ等の記録媒体やインターネット等の伝送媒体を介して配信することができるのは言うまでもない。
ある記録装置で生成されたメニューが情報記録媒体に記録された後にその情報記録媒体が他の記録装置にセットされた場合、当該他の記録装置において本来的には不要な処理負荷および処理時間を発生させないための記録装置、および、情報記録方法を提供することができる。
図１は、ＳＤ−ＤＶＤの構造を示す図である。 図２は、ＡＶデータであるＭＰＥＧストリーム中に埋め込まれているナビゲーション情報を説明する概要図である。 図３は、ＤＶＤにおけるＶＯＢの構成を示す概要図である。 図４は、ＢＤ−ＲＯＭのデータ階層を示す図である。 図５は、ＢＤ−ＲＯＭに記録されている論理データの構造を示す図である。 図６は、ＢＤ−ＲＯＭを再生するＢＤ−ＲＯＭプレーヤの基本的な構成の概要を示す図である。 図７は、図６に示すプレーヤの構成を詳細化したブロック図である。 図８は、ＢＤ−ＲＯＭのアプリケーション空間を示す図である。 図９は、ＭＰＥＧストリーム（ＶＯＢ）の構成を示す図である。 図１０は、ＭＰＥＧストリームにおけるパックの構成を示す図である。 図１１は、ＡＶデータとプレーヤ構成との関係を説明するための図である。 図１２は、トラックバッファを使ったＶＯＢデータ連続供給モデルを説明するための図である。 図１３は、ＶＯＢ管理情報ファイルの内部構造を示す図である。 図１４は、ＶＯＢＵ情報の詳細を説明するための図である。 図１５は、タイムマップを使ったアドレス情報取得方法を説明するための図である。 図１６は、プレイリストの構成を示す図である。 図１７は、イベントハンドラテーブルの構成を示す図である。 図１８は、ＢＤ−ＲＯＭ全体情報であるＢＤ．ＩＮＦＯの構成を示す図である。 図１９は、グローバルイベントハンドラテーブルの構成を示す図である。 図２０は、タイムイベントの例を示す図である。 図２１は、ユーザのメニュー操作によるユーザイベントの例を示す図である。 図２２は、グローバルイベントの例を示す図である。 図２３は、プログラムプロセッサの機能的な構成を説明するための図である。 図２４は、システムパラメータ（ＳＰＲＭ）の一覧を示す図である。 図２５は、２つの選択ボタンを持つメニュー画面の制御に係るイベントハンドラにおけるプログラムの例を示す図である。 図２６は、メニュー選択のユーザイベントに係るイベントハンドラにおけるプログラムの例を示す図である。 図２７は、ＢＤ−ＲＯＭプレーヤにおけるＡＶデータ再生の基本処理の流れを示すフローチャートである。 図２８は、ＢＤ−ＲＯＭプレーヤにおけるプレイリスト再生開始からＶＯＢ再生終了までの処理の流れを示すフローチャートである。 （Ａ）は、ＢＤ−ＲＯＭプレーヤにおけるタイムイベントに係る処理の流れを示すフローチャートであり、（Ｂ）は、ＢＤ−ＲＯＭプレーヤにおけるユーザイベントに係る処理の流れを示すフローチャートである。 図３０は、ＢＤ−ＲＯＭプレーヤにおける字幕データの処理の流れを示すフローチャートである。 図３１は、実施の形態２におけるディスクを使用するレコーダおよびプレーヤで表示されるメニューの例を示す図である。 図３２は、実施の形態２におけるＢＤ．ＩＮＦＯの内容を示す図である。 図３３は、実施の形態２におけるＢＤ．ＰＲＯＧの内容を示す図である。 図３４は、メニュー表示およびタイトル再生に係る表示および動作の遷移の一例を示す図である。 （Ａ）は、ディスクメニューの更新においてＢＤ．ＩＮＦＯ等の各ファイルをどのように扱うかを示す図であり、（Ｂ）は、（Ａ）に示される番号の意味を説明する図である。 図３６は、ＢＤ．ＩＮＦＯの“Ｅｘｔｅｎｓｉｏｎ”にプレイリストを特定するための情報を格納した状態を示す図である。 図３７は、実施の形態２における、ディスクメニューの更新前後のタイトルとプレイリスト（コンテンツ）との相関の例を示す図である。 図３８は、実施の形態２のレコーダの機能的な構成を示す機能ブロック図である。 図３９は、実施の形態２のレコーダ４００における記録/編集時のタイトル構成の更新時の動作の流れの概要を示すフロー図である。 図４０は、実施の形態３における、ＢＤディスク全体管理情報およびTitle情報を記録するファイルの構成図である。 図４１は、実施の形態３における、プログラムを格納するＯｂｊｅｃｔ情報を記録するファイルの構成図である。 図４２は、実施の形態３における、ＢＤ−ＲＯＭでの多重化の例を示す図である。 図４３は、実施の形態３における、ナビゲーション機能のページのデータ構造を示す図である。 図４４は、実施の形態３における、ナビゲーション機能のボタンのデータ構造を示す図である。 図４５は、実施の形態３における、ナビゲーション機能の例を示す図である。 図４６は、実施の形態３における、スライドショウ機能の構造を示す図である。 （Ａ）は、実施の形態３における、再生メニューの例を示す図であり、（Ｂ）は、実施の形態３における、メニュー画面の遷移の例を示す図である。 図４８は、実施の形態３における、各Ｔｉｔｌｅが参照するプレイリスト並びにオブジェクトの情報を格納するメタデータの例を示す図である。 図４９は、実施の形態４における、メタデータをＩｎｄｅｘＥｘｔｅｎｓｉｏｎＤａｔａ（）に格納した場合の例を示す図である。 図５０は、実施の形態４における、Ｒｅａｌ ＰｌａｙＬｉｓｔ（実シナリオ情報）及びＶｉｒｔａｕｌ ＰｌａｙＬｉｓｔ（仮想シナリオ情報）とＳｈｏｔ（撮影または録画した映像単位）との関係を示す図である。 図５１は、実施の形態４における、Ｓｈｏｔの先頭を示すＭａｒｋとＳｈｏｔの撮影順との関係を示す図である。 （Ａ）は、実施の形態４における、メタデータのデータ構造の一例を示す図であり、（Ｂ）は、（Ａ）に示すメタデータに基づき生成されたＳｈｏｔメニューの一例を示す図である。 図５３は、実施の形態５における、メタデータの一部をＩｎｄｅｘＥｘｔｅｎｓｉｏｎＤａｔａ（）に格納した場合の例を示す図である。 図５４は、実施の形態５における、メタデータの一部をＰｌａｙＬｉｓｔＥｘｔｅｎｓｉｏｎＤａｔａ（）に格納した場合の例を示す図である。場合の例を示す図である。 （Ａ）は、実施の形態５における、メタデータのデータ構造の一例を示す図であり、（Ｂ）は、（Ａ）に示すメタデータに基づき生成されたＳｈｏｔメニューの一例を示す図である。 図５６は、映像の編集により撮影日時情報が失われる例を示す図である。 図５７は、実施の形態６における、Ｍａｒｋを用いて編集時でも撮影日時を保持する方法を示す図である。 図５８は、実施の形態７における、メタデータの格納位置を説明する図である。 図５９は、実施の形態７における、メタデータのデータ構造を説明する図である。 図６０は、実施の形態７における、メタデータの識別情報（ＩＤ）と種類とを説明する図である。 図６１は、実施の形態７における、メタデータの取得処理を示すフロー図である。 図６２は、ＤＶとＥＸＩＦで同種情報を持つことを説明する図である。 図６３は、同種情報を持つ場合の記録ルールを説明する図である。 図６４は、ＢＤ−ＲＯＭディスク記録されているストリームのデータ構造を説明する図である。 図６５は、従来のスライドショウに係るデータ構造を説明する図である。 図６６は、実施の形態８における、スライドショウに係るデータ構造を説明する図である。 図６７は、実施の形態８における、Ｓｔｉｌｌ Ｕｎｉｔのデータ構造を説明する図である。 図６８は、実施の形態８における、副映像を用いた静止画スライドショウを説明する図である。 図６９は、実施の形態８における、副映像を用いた静止画スライドショウの作成のための処理の流れを示すフロー図である。
以下、添付の図面を参照しながら、本発明を実施するための最良の形態ついて説明する。
なお、本願請求項１に係る発明に最も近い実施の形態は実施の形態２であるが、理解を容易にするために、実施の形態２における情報記録媒体等の基本的な構成を説明する実施の形態１を先に説明する。
（実施の形態１）
まず、ＢＤ（Ｂｌｕ−ｒａｙ Ｄｉｓｃ）−ＲＯＭおよびＢＤ−ＲＯＭを再生するＢＤ−ＲＯＭプレーヤの基本的な構成および動作について、図１〜図３０を用いて説明する。
（ディスク上の論理データ構造）
図４は、ＢＤ−ＲＯＭのデータ階層を示す図である。
図４に示すように、ディスク媒体であるＢＤ−ＲＯＭ１０４上には、ＡＶデータ１０３と、ＡＶデータに関する管理情報及びＡＶ再生シーケンスなどのＢＤ管理情報１０２と、インタラクティブを実現するＢＤ再生プログラム１０１とが記録されている。
なお、各タイトルの実体データは、ＡＶデータ１０３として存在し、各タイトルのシナリオ制御記述データ（以下、単に「シナリオ」ともいう。）は、ＢＤ管理情報１０２として存在する。
なお、本実施の形態では、映画などのＡＶコンテンツを再生するためのＡＶアプリケーションを主眼においてＢＤ−ＲＯＭの説明を行うが、ＢＤ−ＲＯＭをＣＤ−ＲＯＭやＤＶＤ−ＲＯＭの様にコンピュータ用途の記録媒体として使用することも当然のことながら可能である。
図５は、前述のＢＤ−ＲＯＭ１０４に記録されている論理データの構造を示す図である。ＢＤ−ＲＯＭ１０４は、他の光ディスク、例えばＤＶＤやＣＤなどと同様にその内周から外周に向けてらせん状に記録領域を持ち、内周のリードインと外周のリードアウトの間に論理データを記録できる論理アドレス空間を有している。
また、リードインの内側にはＢｕｒｓｔ Ｃｕｔｔｉｎｇ Ａｒｅａ（ＢＣＡ）と呼ばれる、ドライブでしか読み出せない特別な領域がある。この領域はアプリケーションから読み出せないため、例えば著作権保護技術などに利用されることがよくある。
論理アドレス空間には、ファイルシステム情報（ボリューム）を先頭に映像データなどのアプリケーションデータが記録されている。ファイルシステムとは従来技術で説明した通り、ＵＤＦやＩＳＯ９６６０等の規格により定められたデータを管理する仕組みのことであり、通常のＰＣと同じように記録されている論理データをディレクトリ、ファイル構造を使って読み出しする事が可能になっている。
本実施の形態の場合、ＢＤ−ＲＯＭ１０４上のディレクトリ、ファイル構造は、ルートディレクトリ（ＲＯＯＴ）直下にＢＤＶＩＤＥＯディレクトリが置かれている。このディレクトリはＢＤ−ＲＯＭで扱うＡＶデータや管理情報などのデータ（図４に示すＢＤ再生プログラム１０１、ＢＤ管理情報１０２、ＡＶデータ１０３）が記録されているディレクトリである。
ＢＤＶＩＤＥＯディレクトリの下には、次の７種類のファイルが記録されている。
ＢＤ．ＩＮＦＯ（ファイル名固定）
「ＢＤ管理情報」の一つであり、ＢＤ−ＲＯＭ全体に関する情報を記録したファイルである。ＢＤ−ＲＯＭプレーヤは最初にこのファイルを読み出す。
ＢＤ．ＰＲＯＧ（ファイル名固定）
「ＢＤ再生プログラム」の一つであり、ＢＤ−ＲＯＭ全体に関わるプログラムを記録したファイルである。
ＸＸＸ．ＰＬ（「ＸＸＸ」は可変、拡張子「ＰＬ」は固定）
「ＢＤ管理情報」の一つであり、シナリオを記録するプレイリスト（Ｐｌａｙ Ｌｉｓｔ）情報を記録したファイルである。プレイリスト毎に１つのファイルを持っている。
ＸＸＸ．ＰＲＯＧ（「ＸＸＸ」は可変、拡張子「ＰＲＯＧ」は固定）
「ＢＤ再生プログラム」の一つであり、前述したプレイリスト毎のプログラムを記録したファイルである。プレイリストとの対応はファイルボディ名（「ＸＸＸ」が一致する）によって識別される。
ＹＹＹ．ＶＯＢ（「ＹＹＹ」は可変、拡張子「ＶＯＢ」は固定）
「ＡＶデータ」の一つであり、ＶＯＢ（従来例で説明したＶＯＢと同じ）を記録したファイルである。１つのＶＯＢは１つのファイルに対応する。
ＹＹＹ．ＶＯＢＩ（「ＹＹＹ」は可変、拡張子「ＶＯＢＩ」は固定）
「ＢＤ管理情報」の一つであり、ＡＶデータであるＶＯＢに関わる管理情報を記録したファイルである。ＶＯＢとの対応はファイルボディ名（「ＹＹＹ」が一致する）によって識別される。
ＺＺＺ．ＰＮＧ（「ＺＺＺ」は可変、拡張子「ＰＮＧ」は固定）
「ＡＶデータ」の一つであり、字幕及びメニュー画面を構成するためのイメージデータであるＰＮＧ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍ（Ｗ３Ｃ）によって標準化された画像フォーマットであり「ピング」と読む。）形式のイメージファイルである。１つのＰＮＧイメージは１つのファイルに対応する。
（プレーヤの構成）
次に、前述のＢＤ−ＲＯＭ１０４を再生するプレーヤの構成について図６及び図７を用いて説明する。
図６は、ＢＤ−ＲＯＭ１０４を再生するＢＤ−ＲＯＭプレーヤの基本的な構成の概要を示す図である。
図６に示すＢＤ−ＲＯＭプレーヤにおいて、ＢＤ−ＲＯＭ１０４上のデータは、光ピックアップ２０２を通して読み出される。読み出されたデータはそれぞれのデータの種類に応じて専用のメモリに記録される。
ＢＤ再生プログラム（「ＢＤ．ＰＲＯＧ」または「ＸＸＸ．ＰＲＯＧ」ファイル）はプログラム記録メモリ２０３に、ＢＤ管理情報（「ＢＤ．ＩＮＦＯ」、「ＸＸＸ．ＰＬ」または「ＹＹＹ．ＶＯＢＩ」ファイル）は管理情報記録メモリ２０４に、ＡＶデータ（「ＹＹＹ．ＶＯＢ」または「ＺＺＺ．ＰＮＧ」ファイル）はＡＶ記録メモリ２０５にそれぞれ記録される。
プログラム記録メモリ２０３に記録されたＢＤ再生プログラムはプログラム処理部２０６によって処理される。管理情報記録メモリ２０４に記録されたＢＤ管理情報は管理情報処理部２０７によって処理される。
また、ＡＶ記録メモリ２０５に記録されたＡＶデータはプレゼンテーション処理部２０８によって処理される。
プログラム処理部２０６は、管理情報処理部２０７から再生するプレイリストの情報やプログラムの実行タイミングなどのイベント情報を受け取りプログラムの処理を行う。また、プログラムで再生するプレイリストを動的に変更する事が可能であり、この場合は管理情報処理部２０７に対して変更後のプレイリストの再生命令を送ることで実現する。
プログラム処理部２０６は、更に、ユーザからのイベント、例えば、ユーザが操作するリモコンからのリクエストを受け付け、ユーザイベントに対応するプログラムがある場合は、実行処理する。
管理情報処理部２０７は、プログラム処理部２０６の指示を受け、その指示に対応するプレイリスト及びそのプレイリストに対応したＶＯＢの管理情報を解析する。更に、プレゼンテーション処理部２０８に再生の対象となるＡＶデータの再生を指示する。
また、管理情報処理部２０７は、プレゼンテーション処理部２０８から基準時刻情報を受け取り、時刻情報に基づいてプレゼンテーション処理部２０８にＡＶデータ再生の停止指示を行う。更に、プログラム処理部２０６に対してプログラム実行タイミングを示すイベントを生成する。
プレゼンテーション処理部２０８は、映像、音声、および字幕それぞれのデータに対応するデコーダを持ち、管理情報処理部２０７からの指示に従い、ＡＶデータのデコード及び出力を行う。映像データ及び字幕データは、デコード後にそれぞれの専用プレーンに描画される。
具体的には、映像データはビデオプレーン２１０に描画され、字幕データ等のイメージデータはイメージプレーン２０９に描画される。更に、２つのプレーンに描画された映像の合成処理が合成処理部２１１によって行われＴＶなどの表示デバイスへ出力される。
図６で示すように、ＢＤ−ＲＯＭプレーヤは図４で示したＢＤ−ＲＯＭ１０４に記録されているデータ構造に基づいた構成をとっている。
図７は、図６に示すプレーヤの構成を詳細化したブロック図である。図６に示す各構成部と、図７に示す各構成部との対応は以下の通りである。
ＡＶ記録メモリ２０５はイメージメモリ３０８とトラックバッファ３０９に対応する。プログラム処理部２０６はプログラムプロセッサ３０２とＵＯ（Ｕｓｅｒ Ｏｐｅｒａｔｉｏｎ）マネージャ３０３に対応する。管理情報処理部２０７はシナリオプロセッサ３０５とプレゼンテーションコントローラ３０６とに対応する。プレゼンテーション処理部２０８はクロック３０７、デマルチプレクサ３１０、イメージプロセッサ３１１、ビデオプロセッサ３１２とサウンドプロセッサ３１３とに対応する。
ＢＤ−ＲＯＭ１０４から読み出されたＶＯＢデータ（ＭＰＥＧストリーム）はトラックバッファ３０９に、イメージデータ（ＰＮＧ）はイメージメモリ３０８にそれぞれ記録される。
デマルチプレクサ３１０は、クロック３０７から得られる時刻に基づき、トラックバッファ３０９に記録されたＶＯＢデータを抜き出す。更に、ＶＯＢデータに含まれる映像データをビデオプロセッサ３１２に音声データをサウンドプロセッサ３１３にそれぞれ送り込む。
ビデオプロセッサ３１２及びサウンドプロセッサ３１３はそれぞれＭＰＥＧシステム規格で定められる通りに、デコーダバッファとデコーダからそれぞれ構成されている。即ち、デマルチプレクサ３１０から送りこまれる映像、音声それぞれのデータは、それぞれのデコーダバッファに一時的に記録され、クロック３０７に従い個々のデコーダでデコード処理される。
イメージメモリ３０８に記録されたＰＮＧデータは、次の２つの処理方法がある。ＰＮＧデータが字幕用の場合は、プレゼンテーションコントローラ３０６によってデコードタイミングが指示される。クロック３０７からの時刻情報をシナリオプロセッサ３０５が一旦受け、適切な字幕表示が行えるように、字幕表示時刻（開始及び終了）になればプレゼンテーションコントローラ３０６に対して字幕の表示、非表示の指示を出す。
プレゼンテーションコントローラ３０６からデコード／表示の指示を受けたイメージプロセッサ３１１は対応するＰＮＧデータをイメージメモリ３０８から抜き出し、デコードし、イメージプレーン２０９に描画する。
また、ＰＮＧデータがメニュー画面用の場合は、プログラムプロセッサ３０２によってデコードタイミングが指示される。プログラムプロセッサ３０２がいつイメージのデコードを指示するかは、プログラムプロセッサ３０２が処理しているＢＤプログラムに因るものであって一概には決まらない。
イメージデータ及び映像データは、図６で説明したようにそれぞれデコード後にイメージプレーン２０９およびビデオプレーン２１０に描画され、合成処理部２１１によって合成出力される。
ＢＤ−ＲＯＭ１０４から読み出された管理情報（シナリオ、ＡＶ管理情報）は、管理情報記録メモリ２０４に記録されるが、シナリオ情報（「ＢＤ．ＩＮＦＯ」及び「ＸＸＸ．ＰＬ」）はシナリオプロセッサ３０５によって読み出され処理される。また、ＡＶ管理情報（「ＹＹＹ．ＶＯＢＩ」）はプレゼンテーションコントローラ３０６によって読み出され処理される。
シナリオプロセッサ３０５は、プレイリストの情報を解析し、プレイリストによって参照されているＶＯＢとその再生位置をプレゼンテーションコントローラ３０６に指示し、プレゼンテーションコントローラ３０６は対象となるＶＯＢの管理情報（「ＹＹＹ．ＶＯＢＩ」）を解析して、対象となるＶＯＢを読み出すようにドライブコントローラ３１７に指示を出す。
ドライブコントローラ３１７はプレゼンテーションコントローラ３０６の指示に従い、光ピックアップを移動させ、対象となるＡＶデータの読み出しを行う。読み出されたＡＶデータは、前述したようにイメージメモリ３０８またはトラックバッファ３０９に記録される。
また、シナリオプロセッサ３０５は、クロック３０７の時刻を監視し、管理情報で設定されているタイミングでイベントをプログラムプロセッサ３０２に投げる。
プログラム記録メモリ２０３に記録されたＢＤプログラム（「ＢＤ．ＰＲＯＧ」または「ＸＸＸ．ＰＲＯＧ」）は、プログラムプロセッサ３０２によって実行処理される。プログラムプロセッサ３０２がＢＤプログラムを処理するのは、シナリオプロセッサ３０５からイベントが送られてきた場合か、ＵＯマネージャ３０３からイベントが送られてきた場合である。
ＵＯマネージャ３０３は、ユーザからリモコンキーによってリクエストが送られてきた場合に、当該リクエストに対応するイベントを生成しプログラムプロセッサ３０２に送る。
このような各構成部の動作により、ＢＤ−ＲＯＭの再生がおこなわれる。
（アプリケーション空間）
図８は、ＢＤ−ＲＯＭのアプリケーション空間を示す図である。
ＢＤ−ＲＯＭのアプリケーション空間では、プレイリスト（ＰｌａｙＬｉｓｔ）が一つの再生単位になっている。プレイリストはセル（Ｃｅｌｌ）の再生シーケンスから構成される静的なシナリオと、プログラムによって記述される動的なシナリオとを有している。
プログラムによる動的なシナリオが無い限り、プレイリストは個々のセルを順に再生するだけであり、また、全てのセルの再生を終了した時点でプレイリストの再生は終了する。
一方で、プログラムは、プレイリストを超えての再生記述や、ユーザの選択またはプレーヤの状態に応じて再生する対象を動的に変えることが可能である。典型的な例としてはメニュー画面を介した再生対象の動的変更が挙げられる。ＢＤ−ＲＯＭの場合、メニューとはユーザの選択によって再生するシナリオ、即ちプレイリストを動的に選択するための機能の構成要素の１つである。
また、ここで言うプログラムは、時間イベントまたはユーザイベントによって実行されるイベントハンドラの事である。
時間イベントは、プレイリスト中に埋め込まれた時刻情報に基づいて生成されるイベントである。図７で説明したシナリオプロセッサ３０５からプログラムプロセッサ３０２に送られるイベントがこれに相当する。時間イベントが発行されると、プログラムプロセッサ３０２はＩＤによって対応付けられるイベントハンドラを実行処理する。
前述した通り、実行されるプログラムが他のプレイリストの再生を指示することが可能であり、この場合には、現在再生されているプレイリストの再生は中止され、指定されたプレイリストの再生へと遷移する。
ユーザイベントは、ユーザのリモコンキー操作によって生成されるイベントである。ユーザイベントは大きく２つのタイプに分けられる。一つ目は、リモコンが備えるカーソルキー（「上」「下」「左」「右」キー）または「決定」キーの操作によって生成されるメニュー選択のイベントである。
メニュー選択のイベントに対応するイベントハンドラはプレイリスト内の限られた期間でのみ有効である。つまり、プレイリストの情報として、個々のイベントハンドラの有効期間が設定されている。プログラムプロセッサ３０２は、リモコンの「上」「下」「左」「右」キーまたは「決定」キーが押された時に有効なイベントハンドラを検索して、有効なイベントハンドラがある場合は当該イベントハンドラが実行処理される。他の場合は、メニュー選択のイベントは無視されることになる。
二つ目のユーザイベントは、「メニュー」キーの操作によって生成されるメニュー画面呼び出しのイベントである。メニュー画面呼び出しのイベントが生成されると、グローバルイベントハンドラが呼ばれる。
グローバルイベントハンドラはプレイリストに依存せず、常に有効なイベントハンドラである。この機能を使うことにより、ＤＶＤのメニューコールを実装することができる。メニューコールを実装することにより、タイトル再生中に音声、字幕メニューなどを呼び出し、音声または字幕を変更後に中断した地点からのタイトル再生を実行することができる。
プレイリストで静的シナリオを構成する単位であるセル（Ｃｅｌｌ）はＶＯＢ（ＭＰＥＧストリーム）の全部または一部の再生区間を参照したものである。セルはＶＯＢ内の再生区間を開始、終了時刻の情報として持っている。個々のＶＯＢと一対になっているＶＯＢ管理情報（ＶＯＢＩ）は、その内部にタイムマップ（Ｔｉｍｅ ＭａｐまたはＴＭ）を有しており、このタイムマップによって前述したＶＯＢの再生、終了時刻をＶＯＢ内（即ち対象となるファイル「ＹＹＹ．ＶＯＢ」内）での読み出し開始アドレス及び終了アドレスを導き出すことが可能である。なおタイムマップの詳細は図１４を用いて後述する。
（ＶＯＢの詳細）
図９は、本実施の形態で使用するＭＰＥＧストリーム（ＶＯＢ）の構成を示す図である。図９に示すように、ＶＯＢは複数のＶｉｄｅｏ Ｏｂｊｅｃｔ Ｕｎｉｔ（ＶＯＢＵ）によって構成されている。ＶＯＢＵは、ＭＰＥＧビデオストリームにおけるＧｒｏｕｐ Ｏｆ Ｐｉｃｔｕｒｅｓ（ＧＯＰ）を基準とする単位であり、音声データも含んだ多重化ストリームとしての一再生単位である。
ＶＯＢＵは０．４秒から１．０秒の再生時間を持ち、通常は０．５秒の再生時間を持っている。これはＭＰＥＧのＧＯＰの構造が通常は１５フレーム／秒（ＮＴＳＣの場合）であることによって導かれるものである。
ＶＯＢＵは、その内部に映像データであるビデオパック（Ｖ＿ＰＣＫ）と、音声データであるオーディオパック（Ａ＿ＰＣＫ）とを有している。各パックは１セクタで構成され、本実施の形態の場合は２ｋＢ単位で構成されている。
図１０は、ＭＰＥＧストリームにおけるパックの構成を示す図である。
図１０に示すように、映像データ及び音声データといったエレメンタリデータは、ペイロードと呼ばれるパケットのデータ格納領域に先頭から順次入れられていく。ペイロードにはパケットヘッダが付けられ１つのパケットを構成する。
パケットヘッダには、ペイロードに格納してあるデータがどのストリームのデータであるのかを示す情報、映像データであるのか音声データであるのかを示す情報、また、映像データまたは音声データがそれぞれ複数ストリームある場合は、どのストリームのデータなのかを識別するためのＩＤ（ｓｔｒｅａｍ＿ｉｄ）、および、当該ペイロードのデコード及び表示時刻情報であるタイムスタンプであるＤｅｃｏｄｅ Ｔｉｍｅ Ｓｔａｍｐ（ＤＴＳ）及びＰｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ Ｓｔａｍｐ（ＰＴＳ）が記録されている。
ＤＴＳおよびＰＴＳは必ずしも全てのパケットヘッダに記録されている訳ではなく、ＭＰＥＧによって記録するルールが規定されている。ルールの詳細についてはＭＰＥＧシステム（ＩＳＯ／ＩＥＣ１３８１８−１）規格書に記述されているので省略する。
パケットには更にヘッダ（パックヘッダ）が付けられ、パックを構成する。パックヘッダには、当該パックがいつデマルチプレクサを通過し、個々のエレメンタリストリームのデコーダバッファに入力されるかを示すタイムスタンプであるＳｙｓｔｅｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ（ＳＣＲ）が記録されている。
（ＶＯＢのインターリーブ記録）
図１１及び図１２を用いてＶＯＢファイルのインターリーブ記録について説明する。
図１１は、ＡＶデータとＢＤ−ＲＯＭプレーヤの構成との関係を説明するための図である。
図１１上段の図は、図７を用いて前述したプレーヤ構成図の一部である。図の通り、ＢＤ−ＲＯＭ上のデータは、光ピックアップを通してＶＯＢ即ちＭＰＥＧストリームであればトラックバッファ３０９へ入力され、ＰＮＧ即ちイメージデータであればイメージメモリ３０８へと入力される。
トラックバッファ３０９はＦｉｒｓｔ−Ｉｎ Ｆｉｒｓｔ−Ｏｕｔ（ＦＩＦＯ）であり、入力されたＶＯＢのデータは入力された順にデマルチプレクサ３１０へと送られる。この時、前述したＳＣＲに従って個々のパックはトラックバッファ３０９から引き抜かれデマルチプレクサ３１０を介してビデオプロセッサ３１２またはサウンドプロセッサ３１３へとデータが送り届けられる。
一方で、イメージデータの場合は、どのイメージを描画するかはプレゼンテーションコントローラ３０６（図７参照）によって指示される。また、描画に使ったイメージデータは、字幕用イメージデータの場合は同時にイメージメモリ３０８から削除されるが、メニュー用のイメージデータの場合は、イメージメモリ内にそのまま残される。
これはメニューの描画はユーザ操作に依存するところがあるため、同一イメージを複数回描画する可能性があるためである。
図１１下段の図は、ＢＤ−ＲＯＭ上でのＶＯＢファイル及びＰＮＧファイルのインターリーブ記録を示す図である。
一般的にＲＯＭ、例えばＣＤ−ＲＯＭやＤＶＤ−ＲＯＭの場合、一連の連続再生単位となるＡＶデータは連続記録されている。連続記録されている限り、ドライブは順次データを読み出しプレーヤ側に送り届けるだけでよい。
しかしながら、連続再生すべきＡＶデータが分断されてディスク上に離散配置されている場合は、個々の連続区間の間でシーク操作が入ることになり、この間データの読み出しが止まることになる。つまり、データの供給が止まる可能性がある。
ＢＤ−ＲＯＭの場合も同様に、ＶＯＢファイルは連続領域に記録することができる方が望ましいが、例えば字幕データのようにＶＯＢに記録されている映像データと同期して再生されるデータがあり、ＶＯＢファイルと同様に字幕データも何らかの方法によってＢＤ−ＲＯＭから読み出す事が必要になる。
字幕データの読み出し方法の一手段として、ＶＯＢの再生開始前に一まとめで字幕用のイメージデータ（ＰＮＧファイル）を読み出してしまう方法がある。しかしながら、この場合には一時記録に使用する大量のメモリが必要となり、現実的ではない。
そこで、本実施の形態では、ＶＯＢファイルを幾つかのブロックに分けて、ＶＯＢファイルとイメージデータとをインターリーブ記録する方式を使用する。
図１１下段はそのインターリーブ記録を説明するための図である。ＶＯＢファイルとイメージデータを適切にインターリーブ配置することで、前述したような大量の一時記録メモリ無しに、必要なタイミングでイメージデータをイメージメモリに格納することが可能になる。
しかしながらイメージデータを読み出している際には、ＶＯＢデータの読み込みは当然のことながら停止することになる。
図１２は、上記のインターリーブ記録における問題を解決するトラックバッファ３０９を使ったＶＯＢデータ連続供給モデルを説明するための図である。
既に説明したように、ＶＯＢのデータは、一旦トラックバッファ３０９に蓄積される。トラックバッファ３０９へのデータ入力レートをトラックバッファ３０９からのデータ出力レートより高く設定すると、ＢＤ−ＲＯＭからデータを読み出し続けている限り、トラックバッファ３０９のデータ蓄積量は増加をしていくことになる。
ここでトラックバッファ３０９への入力レートをＶａ、トラックバッファからの出力レートをＶｂとする。図１２の上段の図に示すようにＶＯＢの一連続記録領域が論理アドレスの“ａ１”から“ａ２”まで続くとする。また、“ａ２”から“ａ３”の間は、イメージデータが記録されていて、ＶＯＢデータの読み出しが行えない区間であるとする。
図１２の下段の図は、トラックバッファ３０９の蓄積量を示す図である。横軸が時間、縦軸がトラックバッファ３０９内部に蓄積されているデータ量を示している。時刻“ｔ１”がＶＯＢの一連続記録領域の開始点である“ａ１”の読み出しを開始した時刻を示している。
この時刻以降、トラックバッファ３０９にはレートＶａ−Ｖｂでデータが蓄積されていくことになる。このレートは言うまでもなくトラックバッファの入出力レートの差である。時刻“ｔ２”は一連続記録領域の終了点である“ａ２”のデータを読み込む時刻である。
即ち時刻“ｔ１”から“ｔ２”の間レートＶａ−Ｖｂでトラックバッファ内はデータ量が増加していき、時刻“ｔ２”でのデータ蓄積量はＢ（ｔ２）は下記の（式１）によって求めることができる。
Ｂ（ｔ２） ＝ （Ｖａ−Ｖｂ）×（ｔ２−ｔ１） （式１）
この後、ＢＤ−ＲＯＭ上のアドレス“ａ３”まではイメージデータが続くため、トラックバッファへの入力は０となり、出力レートである“−Ｖｂ”でトラックバッファ内のデータ量は減少していくことになる。このデータ量の減少は読み出し位置“ａ３”まで、つまり、時刻でいう“ｔ３”まで続く。
ここで大事なことは、時刻“ｔ３”より前にトラックバッファに蓄積されているデータ量が０になると、デコーダへ供給するＶＯＢのデータが無くなってしまい、ＶＯＢの再生がストップしてしまうことである。
しかしながら、時刻“ｔ３”でトラックバッファにデータが残っている場合には、ＶＯＢの再生がストップすることなく連続して行われることを意味している。
このＶＯＢの再生がストップすることなく連続して行われるための条件は下記の（式２）によって示すことができる。
Ｂ（ｔ２） ≧ −Ｖｂ×（ｔ３−ｔ２） （式２）
即ち、（式２）を満たすようにイメージデータの配置を決めればよい事になる。
（ナビゲーションデータ構造）
図１３から図１９を用いて、ＢＤ−ＲＯＭに記録されたナビゲーションデータ（ＢＤ管理情報）の構造について説明をする。
図１３は、ＶＯＢ管理情報ファイル（“ＹＹＹ．ＶＯＢＩ”）の内部構造を示す図である。
ＶＯＢ管理情報は、当該ＶＯＢのストリーム属性情報（Ａｔｔｒｉｂｕｔｅ）とタイムマップ（ＴＭＡＰ）とを有している。ストリーム属性情報は、ビデオ属性（Ｖｉｄｅｏ）、オーディオ属性（Ａｕｄｉｏ＃０〜Ａｕｄｉｏ＃ｍ）個々に持つ構成となっている。特にオーディオストリームの場合は、ＶＯＢが複数本のオーディオストリームを同時に持つことができることから、オーディオストリーム数（Ｎｕｍｂｅｒ）によって、オーディオ属性のデータフィールドの数が特定される。
下記はビデオ属性（Ｖｉｄｅｏ）の持つフィールドとそれぞれが持ち得る値の例である。
圧縮方式（Ｃｏｄｉｎｇ）：
ＭＰＥＧ１
ＭＰＥＧ２
ＭＰＥＧ４
解像度（Ｒｅｓｏｌｕｔｉｏｎ）：
１９２０ｘ１０８０
１２８０ｘ７２０
７２０ｘ４８０
７２０ｘ５６５
アスペクト比（Ａｓｐｅｃｔ）：
４：３
１６：９
フレームレート（Ｆｒａｍｅｒａｔｅ）：
６０
５９．９４
５０
３０
２９．９７
２５
２４
下記はオーディオ属性（Ａｕｄｉｏ）の持つフィールドとそれぞれが持ち得る値の例である。
圧縮方式（Ｃｏｄｉｎｇ）：
ＡＣ３
ＭＰＥＧ１
ＭＰＥＧ２
ＬＰＣＭ
チャンネル数（Ｃｈ）：
１〜８
言語属性（Ｌａｎｇｕａｇｅ）：
ＪＰＮ、ＥＮＧ、・・・
タイムマップ（ＴＭＡＰ）はＶＯＢＵ毎の情報を持つテーブルであって、当該ＶＯＢが有するＶＯＢＵ数（Ｎｕｍｂｅｒ）と各ＶＯＢＵ情報（ＶＯＢＵ＃１〜ＶＯＢＵ＃ｎ）を持つ。
個々のＶＯＢＵ情報は、ＶＯＢＵの再生時間長（Ｄｕｒａｔｉｏｎ）とＶＯＢＵのデータサイズ（Ｓｉｚｅ）とを有している。
図１４は、ＶＯＢＵ情報の詳細を説明するための図である。
広く知られているように、ＭＰＥＧストリームは時間的側面とデータサイズとしての側面との２つの物理量についての側面を有している。例えば、音声の圧縮規格であるＡｕｄｉｏ Ｃｏｄｅ ｎｕｍｂｅｒ ３（ＡＣ３）は固定ビットレートでの圧縮を行っているため、時間とアドレスとの関係は１次式によって求めることができる。
しかしながらＭＰＥＧビデオデータの場合、個々のフレームは固定の表示時間、例えばＮＴＳＣの場合、１フレームは１／２９．９７秒の表示時間を持つが、個々のフレームの圧縮後のデータサイズは絵の特性や圧縮に使ったピクチャタイプ、いわゆるＩ／Ｐ／Ｂピクチャによってデータサイズは大きく変わってくる。
従って、ＭＰＥＧビデオの場合は、時間とアドレスとの関係は一般式の形で表現することは不可能である。
当然の事として、ＭＰＥＧビデオデータを多重化しているＭＰＥＧストリーム、即ちＶＯＢについても、時間とデータとを一般式の形で表現することは不可能である。
これに代わって、ＶＯＢ内での時間とアドレスとの関係を結びつけるのがタイムマップ（ＴＭＡＰ）である。図１４に示すように、ＶＯＢＵ毎にＶＯＢＵ内のフレーム数と、ＶＯＢＵ内のパック数とをそれぞれエントリとして持つテーブルがタイムマップ（ＴＭＡＰ）である。
図１５を使って、タイムマップ（ＴＭＡＰ）の使い方を説明する。
図１５は、タイムマップを使ったアドレス情報取得方法を説明するための図である。
図１５に示すように時刻情報（Ｔｉｍｅ）が与えられた場合、まずは当該時刻がどのＶＯＢＵに属するのかを検索する。具体的には、タイムマップのＶＯＢＵ毎のフレーム数を加算して行き、フレーム数の和が、当該時刻をフレーム数に換算した値を超えるまたは一致するＶＯＢＵが当該時刻に対応するＶＯＢＵになる。
次に、タイムマップのＶＯＢＵ毎のサイズを当該ＶＯＢＵの直前のＶＯＢＵまで加算して行き、その値が与えられた時刻を含むフレームを再生するために読み出すべきパックの先頭アドレス（Ａｄｄｒｅｓｓ）になっている。
このようにして、ＭＰＥＧストリームにおいて、与えられた時刻情報に対応するアドレスを得ることができる。
次に図１６を使って、プレイリスト（“ＸＸＸ．ＰＬ”）の内部構造を説明する。
図１６は、プレイリストの構成を示す図である。
プレイリストは、セルリスト（ＣｅｌｌＬｉｓｔ）とイベントリスト（ＥｖｅｎｔＬｉｓｔ）とから構成されている。
セルリスト（ＣｅｌｌＬｉｓｔ）は、プレイリスト内の再生セルシーケンスを示す情報であり、本リストの記述順でセルが再生される事になる。
セルリスト（ＣｅｌｌＬｉｓｔ）の中身は、セルの数（Ｎｕｍｂｅｒ）と各セル情報（Ｃｅｌｌ＃１〜Ｃｅｌｌ＃ｎ）である。
各セル情報（Ｃｅｌｌ＃〜Ｃｅｌｌ＃ｎ）は、ＶＯＢファイル名（ＶＯＢＮａｍｅ）、当該ＶＯＢ内での有効区間開始時刻（Ｉｎ）及び有効区間終了時刻（Ｏｕｔ）と、字幕テーブル（ＳｕｂｔｉｔｌｅＴａｂｌｅ）を持っている。
有効区間開始時刻（Ｉｎ）及び有効区間終了時刻（Ｏｕｔ）は、それぞれ当該ＶＯＢ内でのフレーム番号で表現され、前述したタイムマップ（ＴＭＡＰ）を使うことによって再生に必要なＶＯＢデータのアドレスを得る事ができる。
字幕テーブル（ＳｕｂｔｉｔｌｅＴａｂｌｅ）は、当該ＶＯＢと同期再生される字幕情報を持つテーブルである。字幕は音声同様に複数の言語を持つことができ、字幕テーブル（ＳｕｂｔｉｔｌｅＴａｂｌｅ）は言語数（Ｎｕｍｂｅｒ）とそれに続く個々の言語ごとのテーブル（Ｌａｎｇｕａｇｅ＃１〜Ｌａｎｇｕａｇｅ＃ｋ）とから構成されている。
各言語のテーブル（Ｌａｎｇｕａｇｅ＃１〜Ｌａｎｇｕａｇｅ＃ｋ）は、言語情報（Ｌａｎｇｕａｇｅ）と、表示される字幕の字幕情報数（Ｎｕｍｂｅｒ）と、表示される字幕の字幕情報（Ｓｐｅｅｃｈ＃１〜Ｓｐｅｅｃｈ＃ｊ）とから構成され、各字幕情報（Ｓｐｅｅｃｈ＃１〜Ｓｐｅｅｃｈ＃ｊ）は対応するイメージデータファイル名（Ｎａｍｅ）、字幕表示開始時刻（Ｉｎ）及び字幕表示終了時刻（Ｏｕｔ）と、字幕の表示位置（Ｐｏｓｉｔｉｏｎ）とから構成されている。
イベントリスト（ＥｖｅｎｔＬｉｓｔ）は、当該プレイリスト内で発生するイベントを定義したテーブルである。イベントリストは、イベント数（Ｎｕｍｂｅｒ）に続いて個々のイベント（Ｅｖｅｎｔ＃１〜Ｅｖｅｎｔ＃ｍ）とから構成され、各イベント（Ｅｖｅｎｔ＃１〜Ｅｖｅｎｔ＃ｍ）は、イベントの種類（Ｔｙｐｅ）、イベントのＩＤ（ＩＤ）、イベント生成時刻（Ｔｉｍｅ）と有効期間（Ｄｕｒａｔｉｏｎ）とから構成されている。
図１７は、個々のプレイリスト毎のイベントハンドラ（時間イベントと、メニュー選択用のユーザイベント）を持つイベントハンドラテーブル（“ＸＸＸ．ＰＲＯＧ”）の構成を示す図である。
イベントハンドラテーブルは、定義されているイベントハンドラ／プログラム数（Ｎｕｍｂｅｒ）と個々のイベントハンドラ／プログラム（Ｐｒｏｇｒａｍ＃１〜Ｐｒｏｇｒａｍ＃ｎ）を有している。
各イベントハンドラ／プログラム（Ｐｒｏｇｒａｍ＃１〜Ｐｒｏｇｒａｍ＃ｎ）内の記述は、イベントハンドラ開始の定義（＜ｅｖｅｎｔ＿ｈａｎｄｌｅｒ＞タグ）と前述したイベントのＩＤと対になるイベントハンドラのＩＤ（ｅｖｅｎｔ＿ｈａｎｄｌｅｒ ｉｄ）を持ち、その後に当該プログラムが“ｆｕｎｃｔｉｏｎ”に続く括弧“｛”と“｝”との間に記述される。
次に図１８を用いてＢＤ−ＲＯＭ全体に関する情報（“ＢＤ．ＩＮＦＯ”）の内部構造について説明をする。
図１８は、ＢＤ−ＲＯＭ全体情報であるＢＤ．ＩＮＦＯの構成を示す図である。
ＢＤ−ＲＯＭ全体情報は、タイトルリスト（ＴｉｔｌｅＬｉｓｔ）とグローバルイベント用のイベントリスト（ＥｖｅｎｔＬｉｓｔ）とから構成されている。
タイトルリスト（ＴｉｔｌｅＬｉｓｔ）は、ディスク内のタイトル数（Ｎｕｍｂｅｒ）と、これに続く各タイトル情報（Ｔｉｔｌｅ＃１〜Ｔｉｔｌｅ＃ｎ）とから構成されている。
各タイトル情報（Ｔｉｔｌｅ１〜Ｔｉｔｌｅ＃ｎ）は、タイトルに含まれるプレイリストのテーブル（ＰＬＴａｌｂｌｅ）とタイトル内のチャプターリスト（ＣｈａｐｔｅｒＬｉｓｔ）とを含んでいる。プレイリストのテーブル（ＰＬＴａｂｌｅ）はタイトル内のプレイリストの数（Ｎｕｍｂｅｒ）と、プレイリスト名（Ｎａｍｅ）即ちプレイリストのファイル名を有している。
チャプターリスト（ＣｈａｐｔｅｒＬｉｓｔ）は、当該タイトルに含まれるチャプター数（Ｎｕｍｂｅｒ）と各チャプター情報（Ｃｈａｐｔｅｒ＃１〜Ｃｈａｐｔｅｒ＃ｎ）とから構成され、各チャプター情報（Ｃｈａｐｔｅｒ＃１〜Ｃｈａｐｔｅｒ＃ｎ）は当該チャプターが含むセルのテーブル（ＣｅｌｌＴａｂｌｅ）を持ち、セルのテーブル（ＣｅｌｌＴａｂｌｅ）はセル数（Ｎｕｍｂｅｒ）と各セルのエントリ情報（ＣｅｌｌＥｎｔｒｙ＃１〜ＣｅｌｌＥｎｔｒｙ＃ｋ）とから構成されている。
セルのエントリ情報（ＣｅｌｌＥｎｔｒｙ＃１〜ＣｅｌｌＥｎｔｒｙ＃ｋ）は当該セルを含むプレイリスト名と、プレイリスト内でのセル番号によって記述されている。
イベントリスト（ＥｖｅｎｔＬｉｓｔ）は、グローバルイベントの数（Ｎｕｍｂｅｒ）と各グローバルイベントの情報（Ｅｖｅｎｔ＃１〜Ｅｖｅｎｔ＃ｍ）とを持っている。ここで注意すべきは、最初に定義されるグローバルイベントは、ファーストイベント（ＦｉｒｓｔＥｖｅｎｔ）と呼ばれ、ＢＤ−ＲＯＭがプレーヤに挿入された時、最初に実行されるイベントである。
各グローバルイベントの情報（Ｅｖｅｎｔ＃１〜Ｅｖｅｎｔ＃ｍ）はイベントタイプ（Ｔｙｐｅ）とイベントのＩＤ（ＩＤ）だけを持っている。
図１９は、グローバルイベントハンドラテーブル（“ＢＤ．ＰＲＯＧ”）の構成を示す図である。本テーブルは、図１７で説明したイベントハンドラテーブルと同一内容であり、その説明は省略する。
（イベント発生のメカニズム）
図２０から図２２を使ってイベント発生のメカニズムについて説明する。
図２０は、タイムイベントの例を示す図である。
前述したとおり、タイムイベントはプレイリスト（“ＸＸＸ．ＰＬ”）のイベントリスト（ＥｖｅｎｔＬｉｓｔ）で定義される。
タイムイベントとして定義されているイベント、即ちイベントタイプ（Ｔｙｐｅ）が“ＴｉｍｅＥｖｅｎｔ”の場合、イベント生成時刻（“ｔ１”）になった時点で、ＩＤ“Ｅｘ１”を持つタイムイベントがシナリオプロセッサ３０５からプログラムプロセッサ３０２に対して出力される。
プログラムプロセッサ３０２は、イベントＩＤ“Ｅｘ１”を持つイベントハンドラを探し、対象のイベントハンドラを実行処理する。例えば、本実施の形態の場合では、２つのボタンイメージの描画を行うことなどが可能である。
図２１は、ユーザのメニュー操作によるユーザイベントの例を示す図である。
前述したとおり、メニュー操作によるユーザイベントもプレイリスト（“ＸＸＸ．ＰＬ”）のイベントリスト（ＥｖｅｎｔＬｉｓｔ）で定義される。
ユーザイベントとして定義されるイベント、即ちイベントタイプ（Ｔｙｐｅ）が“ＵｓｅｒＥｖｅｎｔ”の場合、イベント生成時刻（“ｔ１”）になった時点で、当該ユーザイベントがレディとなる。この時、イベント自身は未だ生成されてはいない。
当該イベントは、有効規格情報（Ｄｕｒａｔｉｏｎ）で記される期間（“Ｔ１”）レディ状態にある。
図２１に示すように、ユーザによりリモコンキーの「上」「下」「左」「右」キーのいずれかのキー、または「決定」キーが押された場合、まずＵＯイベントがＵＯマネージャ３０３によって生成されプログラムプロセッサ３０２に出力される。
プログラムプロセッサ３０２は、シナリオプロセッサ３０５に対してＵＯイベントを流し、シナリオプロセッサ３０５はＵＯイベントを受け取った時刻に有効なユーザイベントが存在するかを検索する。
シナリオプロセッサ３０５は、検索の結果、対象となるユーザイベントがあった場合、ユーザイベントを生成し、プログラムプロセッサ３０２に出力する。
プログラムプロセッサ３０２では、イベントＩＤ、例えば、図２１に示す例の場合では“Ｅｖ１”を持つイベントハンドラを探し、対象のイベントハンドラを実行処理する。本例の場合、プレイリスト＃２の再生を開始する。
生成されるユーザイベントには、どのリモコンキーがユーザによって押されたかの情報は含まれていない。選択されたリモコンキーの情報は、ＵＯイベントによってプログラムプロセッサ３０２に伝えられ、仮想プレーヤが持つレジスタに記録保持される。
イベントハンドラのプログラムは、このレジスタの値を調べ、分岐処理を実行することが可能である。
図２２は、グローバルイベントの例を示す図である。
前述のように、グローバルイベントはＢＤ−ＲＯＭ全体情報（“ＢＤ．ＩＮＦＯ”）のイベントリスト（ＥｖｅｎｔＬｉｓｔ）で定義される。
グローバルイベントとして定義されるイベント、即ちイベントタイプ（Ｔｙｐｅ）が“ＧｌｏｂａｌＥｖｅｎｔ”であるイベントは、ユーザのリモコンキー操作があった場合にのみ生成される。
ユーザによりメニューキーが押された場合、先ずＵＯイベントがＵＯマネージャ３０３によって生成されプログラムプロセッサ３０２に出力される。プログラムプロセッサ３０２は、シナリオプロセッサ３０５に対してＵＯイベントを流す。
シナリオプロセッサ３０５は、該当するグローバルイベントを生成し、プログラムプロセッサ３０２に送る。プログラムプロセッサ３０２は、イベントＩＤ“ｍｅｎｕ”を持つイベントハンドラを探し、対象のイベントハンドラを実行する。例えば、図２２に示す例の場合、プレイリスト＃３の再生を開始している。
本実施の形態では、単にメニューキーと呼んでいるが、ＤＶＤを再生するプレーヤにおけるリモコンのように複数のメニューキーがあってもよい。各メニューキーに対応するＩＤをそれぞれ定義することで各メニューキーに対応する適切な処理が可能である。
（仮想プレーヤマシン）
図２３は、プログラムプロセッサの機能的な構成を説明するための図である。
図２３を用いてプログラムプロセッサ３０２の機能的な構成を説明する。
プログラムプロセッサ３０２は、内部に仮想プレーヤマシンを持つ処理モジュールである。仮想プレーヤマシンはＢＤ−ＲＯＭとして定義された機能モデルであって、各ＢＤ−ＲＯＭプレーヤの実装には依存しないものである。即ち、どのＢＤ−ＲＯＭプレーヤにおいても同様の機能を実行できることを保証している。
仮想プレーヤマシンは大きく２つの機能を持っている。プログラミング関数とプレーヤ変数（レジスタ）である。
プログラミング関数は、Ｊａｖａ（登録商標） Ｓｃｒｉｐｔをベースとして、以下に記す３つの機能をＢＤ−ＲＯＭ固有関数として定義している。
リンク関数：現在の再生を停止し、指定するプレイリスト、セル、時刻からの再生を開始する
Ｌｉｎｋ（ＰＬ＃，Ｃｅｌｌ＃，ｔｉｍｅ）
ＰＬ＃ ： プレイリスト名
Ｃｅｌｌ＃ ： セル番号
ｔｉｍｅ ： セル内での再生開始時刻
ＰＮＧ描画関数：指定ＰＮＧデータをイメージプレーンに描画する
Ｄｒａｗ（Ｆｉｌｅ，Ｘ，Ｙ）
Ｆｉｌｅ ： ＰＮＧファイル名
Ｘ ： Ｘ座標位置
Ｙ ： Ｙ座標位置
イメージプレーンクリア関数：イメージプレーンの指定領域をクリアする
Ｃｌｅａｒ（Ｘ，Ｙ，Ｗ，Ｈ）
Ｘ ： Ｘ座標位置
Ｙ ： Ｙ座標位置
Ｗ ： Ｘ方向幅
Ｈ ： Ｙ方向幅
また、プレーヤ変数は、プレーヤの状態を示すシステムパラメータ（ＳＰＲＭ）と、一般用途として使用可能なゼネラルパラメータ（ＧＰＲＭ）とがある。
図２４は、システムパラメータ（ＳＰＲＭ）の一覧を示す図である。
ＳＰＲＭ（０） ： 言語コード
ＳＰＲＭ（１） ： 音声ストリーム番号
ＳＰＲＭ（２） ： 字幕ストリーム番号
ＳＰＲＭ（３） ： アングル番号
ＳＰＲＭ（４） ： タイトル番号
ＳＰＲＭ（５） ： チャプター番号
ＳＰＲＭ（６） ： プログラム番号
ＳＰＲＭ（７） ： セル番号
ＳＰＲＭ（８） ： 選択キー情報
ＳＰＲＭ（９） ： ナビゲーションタイマー
ＳＰＲＭ（１０） ： 再生時刻情報
ＳＰＲＭ（１１） ： カラオケ用ミキシングモード
ＳＰＲＭ（１２） ： パレンタル用国情報
ＳＰＲＭ（１３） ： パレンタルレベル
ＳＰＲＭ（１４） ： プレーヤ設定値（ビデオ）
ＳＰＲＭ（１５） ： プレーヤ設定値（オーディオ）
ＳＰＲＭ（１６） ： 音声ストリーム用言語コード
ＳＰＲＭ（１７） ： 音声ストリーム用言語コード（拡張）
ＳＰＲＭ（１８） ： 字幕ストリーム用言語コード
ＳＰＲＭ（１９） ： 字幕ストリーム用言語コード（拡張）
ＳＰＲＭ（２０） ： プレーヤリージョンコード
ＳＰＲＭ（２１） ： 予備
ＳＰＲＭ（２２） ： 予備
ＳＰＲＭ（２３） ： 再生状態
ＳＰＲＭ（２４） ： 予備
ＳＰＲＭ（２５） ： 予備
ＳＰＲＭ（２６） ： 予備
ＳＰＲＭ（２７） ： 予備
ＳＰＲＭ（２８） ： 予備
ＳＰＲＭ（２９） ： 予備
ＳＰＲＭ（３０） ： 予備
ＳＰＲＭ（３１） ： 予備
なお、本実施の形態では、仮想プレーヤのプログラミング関数をＪａｖａ（登録商標） Ｓｃｒｉｐｔベースとしたが、Ｊａｖａ（登録商標） Ｓｃｒｉｐｔではなく、ＵＮＩＸ（登録商標） ＯＳなどで使われているＢ−Ｓｈｅｌｌや、Ｐｅｒｌ Ｓｃｒｉｐｔなど他のプログラミング関数であってもよい。言い換えれば、本発明における使用プログラム言語はＪａｖａ（登録商標） Ｓｃｒｉｐｔに限定されるものでは無い。
（プログラムの例）
図２５及び図２６は、イベントハンドラにおけるプログラムの例を示す図である。
図２５は、２つの選択ボタンを持つメニュー画面の制御に係るイベントハンドラにおけるプログラムの例を示す図である。
セル（ＰｌａｙＬｉｓｔ＃１．Ｃｅｌｌ＃１）先頭でタイムイベントを使って図２５左側のプログラムが実行される。ここでは、最初にゼネラルパラメータの一つＧＰＲＭ（０）に“１”がセットされている。ＧＰＲＭ（０）は、当該プログラムの中で、選択されているボタンを識別するのに使っている。最初の状態では、左側に配置するボタン１が選択されている状態を初期値として持たされている。
次に、ＰＮＧの描画を描画関数である“Ｄｒａｗ”を使ってボタン１、ボタン２それぞれについて行っている。ボタン１は、座標（１０、２００）を起点（左上端）としてＰＮＧイメージ“１ｂｌａｃｋ．ｐｎｇ”を描画している。ボタン２は、座標（３３０，２００）を起点（左上端）としてＰＮＧイメージ“２ｗｈｉｔｅ．ｐｎｇ”を描画している。
また、本セル最後ではタイムイベントを使って図２５右側のプログラムが実行される。ここでは、Ｌｉｎｋ関数を使って当該セルの先頭から再度再生するように指定している。
図２６は、メニュー選択のユーザイベントに係るイベントハンドラにおけるプログラムの例を示す図である。
「左」キー、「右」キー、「決定」キー何れかのリモコンキーが押された場合それぞれに対応するプログラムがイベントハンドラに書かれている。ユーザによりリモコンキーが押された場合、図２１を用いて説明したように、ユーザイベントが生成され、図２６のイベントハンドラが起動されることになる。
本イベントハンドラでは、選択ボタンを識別しているＧＰＲＭ（０）の値と、選択されたリモコンキーを識別するＳＰＲＭ（８）を使って以下のように分岐処理を行っている。
条件１）ボタン１が選択されている、かつ、選択キーが「右」キーの場合
ＧＰＲＭ（０）を２に再設定して、選択状態にあるボタンを右のボタン２に変更する。
ボタン１、ボタン２のイメージをそれぞれ書き換える。
条件２）選択キーが「決定（ＯＫ）」の場合で、ボタン１が選択されている場合
プレイリスト＃２の再生を開始する。
条件３）選択キーが「決定（ＯＫ）」の場合で、ボタン２が選択されている場合
プレイリスト＃３の再生を開始する。
図２６に示すプログラムは、上記のように解釈され実行される。
（プレーヤ処理フロー）
図２７から図３０を用いてプレーヤでの処理の流れを説明する。
図２７は、ＢＤ−ＲＯＭプレーヤにおけるＡＶデータ再生の基本処理の流れを示すフロー図である。
ＢＤ−ＲＯＭが挿入されると（Ｓ１０１）、ＢＤ−ＲＯＭプレーヤは“ＢＤ．ＩＮＦＯ”の読み込みと解析（Ｓ１０２）、および、“ＢＤ．ＰＲＯＧ”の読み込み（Ｓ１０３）を実行する。“ＢＤ．ＩＮＦＯ”及び“ＢＤ．ＰＲＯＧ”は共に管理情報記録メモリ２０４に一旦格納され、シナリオプロセッサ３０５によって解析される。
続いて、シナリオプロセッサ３０５は、“ＢＤ．ＩＮＦＯ”ファイル内のファーストイベント（ＦｉｒｓｔＥｖｅｎｔ）情報に従い、最初のイベントを生成する（Ｓ１０４）。生成されたファーストイベントは、プログラムプロセッサ３０２で受け取られ、当該イベントに対応するイベントハンドラを実行処理する（Ｓ１０５）。
ファーストイベントに対応するイベントハンドラには、最初に再生するべきプレイリストを指定する情報が記録されていることが期待される。仮に、プレイリスト再生が指示されていない場合には、プレーヤは何も再生することなく、ユーザイベントを受け付けるのを待ち続けるだけになる（Ｓ２０１でＮｏ）。
ＵＯマネージャ３０３は、ユーザからのリモコン操作を受け付けると（Ｓ２０１でＹｅｓ）、プログラムプロセッサ３０２に対するＵＯイベントを生成する（Ｓ２０２）。
プログラムプロセッサ３０２は、ＵＯイベントがメニューキーによるものであるかを判別し（Ｓ２０３）、メニューキーの場合（Ｓ２０３でＹｅｓ）は、シナリオプロセッサ３０５にＵＯイベントを流し、シナリオプロセッサ３０５がユーザイベントを生成する（Ｓ２０４）。プログラムプロセッサ３０２は生成されたユーザイベントに対応するイベントハンドラを実行処理する（Ｓ２０５）。
図２８は、ＢＤ−ＲＯＭプレーヤにおけるプレイリスト再生開始からＶＯＢ再生終了までの処理の流れを示すフロー図である。
前述したように、ファーストイベントハンドラまたはグローバルイベントハンドラによってプレイリスト再生が開始される（Ｓ３０１）。シナリオプロセッサ３０５は、再生対象のプレイリスト再生に必要な情報として、プレイリスト“ＸＸＸ．ＰＬ”の読み込みと解析（Ｓ３０２）、および、プレイリストに対応するプログラム情報“ＸＸＸ．ＰＲＯＧ”の読み込みを行う（Ｓ３０３）。
続いてシナリオプロセッサ３０５は、プレイリストに登録されているセル情報に基づいてセルの再生を開始する（Ｓ３０４）。セル再生は、シナリオプロセッサからプレゼンテーションコントローラ３０６に対して要求が出される事を意味し、プレゼンテーションコントローラ３０６はＡＶデータ再生を開始する（Ｓ３０５）。
ＡＶデータの再生が開始されると、プレゼンテーションコントローラ３０６は、再生するセルに対応するＶＯＢの情報ファイル“ＸＸＸ．ＶＯＢＩ”を読み込み（Ｓ４０２）、解析する。プレゼンテーションコントローラ３０６は、タイムマップを使って再生開始するＶＯＢＵとそのアドレスを特定し、ドライブコントローラ３１７に読み出しアドレスを指示する。ドライブコントローラ３１７は対象となるＶＯＢデータ“ＹＹＹ．ＶＯＢ”を読み出す（Ｓ４０３）。
読み出されたＶＯＢデータはデコーダに送られ再生が開始される（Ｓ４０４）。ＶＯＢ再生は、当該ＶＯＢの再生区間が終了するまで続けられ（Ｓ４０５）、終了すると次のセルが存在する場合（Ｓ４０６でＹｅｓ）、Ｃｅｌｌの再生（Ｓ３０４）へ移行する。また、次のセルが無い場合（Ｓ４０６でＮｏ）は、再生に係る処理が終了する。
図２９は、ＡＶデータ再生開始後からのイベント処理の流れを示すフロー図である。
図２９（Ａ）は、ＢＤ−ＲＯＭプレーヤにおけるタイムイベントに係る処理の流れを示すフロー図である。
なお、ＢＤ−ＲＯＭプレーヤはイベントドリブン型のプレーヤモデルである。プレイリストの再生を開始すると、タイムイベント系、ユーザイベント系、字幕表示系のイベント処理プロセスがそれぞれ起動され、平行してイベント処理を実行するようになる。
ＢＤ−ＲＯＭプレーヤにおいてプレイリスト再生の再生が開始されると（Ｓ５０１）、プレイリスト再生が終了していないことが確認され（Ｓ５０２でＮｏ）、シナリオプロセッサ３０５は、タイムイベント発生時刻になったかを確認する。
タイムイベント発生時刻になっている場合（Ｓ５０３でＹｅｓ）には、シナリオプロセッサ３０５はタイムイベントを生成する（Ｓ５０４）。プログラムプロセッサ３０２はタイムイベントを受け取り、イベントハンドラを実行処理する（Ｓ５０５）。
また、タイムイベント発生時刻になっていない場合（Ｓ５０３でＮｏ）、および、イベントハンドラの実行処理が終了した場合、プレイリスト再生の終了確認（Ｓ５０２）以降の処理を繰り返す。
また、プレイリスト再生が終了したことが確認されると（Ｓ５０２でＹｅｓ）、タイムイベント系の処理は強制的に終了する。
図２９（Ｂ）は、ＢＤ−ＲＯＭプレーヤにおけるユーザイベントに係る処理の流れを示すフロー図である。
ＢＤ−ＲＯＭプレーヤ１においてプレイリストの再生が開始されると（Ｓ６０１）、プレイリスト再生が終了していないことが確認され（Ｓ６０２でＮｏ）、ＵＯマネージャ３０３は、ＵＯの受け付けがあったかを確認する。
ＵＯの受け付けがあった場合（Ｓ６０３でＹｅｓ）、ＵＯマネージャ３０３はＵＯイベントを生成する（Ｓ６０４）。プログラムプロセッサ３０２はＵＯイベントを受け取り、そのＵＯイベントがメニューコールであるかを確認する。
メニューコールであった場合（Ｓ６０５でＹｅｓ）、プログラムプロセッサ３０２はシナリオプロセッサ３０５にイベントを生成させ（Ｓ６０７）、プログラムプロセッサ３０２はイベントハンドラを実行処理する（Ｓ６０８）。
また、ＵＯイベントがメニューコールで無いと判断された場合（Ｓ６０５でＮｏ）、ＵＯイベントはカーソルキーまたは「決定」キーによるイベントである事を示している。この場合、現在時刻がユーザイベント有効期間内であるかをシナリオプロセッサ３０５が判断し、有効期間内である場合（Ｓ６０６でＹｅｓ）には、シナリオプロセッサ３０５がユーザイベントを生成し（Ｓ６０７）、プログラムプロセッサ３０２が対象のイベントハンドラを実行処理する（Ｓ６０８）。
また、ＵＯ受付が無い場合（Ｓ６０３でＮｏ）、現在時刻がユーザイベント有効期間内にない場合（Ｓ６０６でＮｏ）、および、イベントハンドラの実行処理が終了した場合、プレイリスト再生の終了確認（Ｓ６０２）以降の処理を繰り返す。
また、プレイリスト再生が終了したことが確認されると（Ｓ６０２でＹｅｓ）、ユーザイベント系の処理は強制的に終了する。
図３０は、ＢＤ−ＲＯＭプレーヤにおける字幕データの処理の流れを示すフロー図である。
ＢＤ−ＲＯＭプレーヤにおいてプレイリストの再生が開始されると、プレイリスト再生が終了していないことが確認され（Ｓ７０２でＮｏ）、シナリオプロセッサ３０５は、字幕表示開始時刻になったかを確認する。字幕表示開始時刻になっている場合（Ｓ７０３でＹｅｓ）、シナリオプロセッサ３０５はプレゼンテーションコントローラ３０６に字幕描画を指示し、プレゼンテーションコントローラ３０６はイメージプロセッサ３１１に字幕描画を指示する。イメージプロセッサ３１１は、その指示に従い字幕をイメージプレーン２０９に字幕を描画する（Ｓ７０４）。
また、字幕表示開始時刻になっていない場合（Ｓ７０３でＮｏ）、字幕表示終了時刻であるかを確認する。字幕表示終了時刻であると判断された場合（Ｓ７０５でＹｅｓ）、プレゼンテーションコントローラ３０６がイメージプロセッサ３１１に字幕消去指示を行う。
イメージプロセッサ３１１は、その指示に従い描画されている字幕をイメージプレーン２０９から消去する（Ｓ７０６）。
また、イメージプロセッサ３１１による字幕描画（Ｓ７０４）が終了した場合、イメージプロセッサ３１１による字幕消去（Ｓ７０６）のが終了した場合、および、字幕表示終了時刻でないと判断（Ｓ７０５でＮｏ）された場合、プレイリスト再生の終了確認（Ｓ７０２）以降の処理を繰り返す。
また、プレイリスト再生が終了したことが確認されると（Ｓ７０２でＹｅｓ）、字幕表示系の処理は強制的に終了する。
以上の動作により、ＢＤ−ＲＯＭプレーヤは、ユーザの指示またはＢＤ−ＲＯＭに記録されているＢＤ管理情報等に基づき、ＢＤ−ＲＯＭの再生に係る基本的な処理を行う。
（実施の形態２）
次に本発明の実施の形態２について説明する。
基本的には、実施の形態１に基づく内容であり、拡張した部分または異なる部分を中心に説明する。
なお、実施の形態２では、実施の形態１に記載のデータ構造を基本のデータ構造として有するディスクを用い、本発明の特徴であるディスクメニューに関するデータ構造について説明を行う。
また、このディスクに情報を記録し、記録した情報を編集する記録装置としてビデオカメラを想定し、ビデオカメラの構成および動作についても説明を行う。
図３１は、実施の形態２におけるディスクを使用するレコーダおよびプレーヤにおけるメニュー表示の例を示す図である。
図３１に示す、Ｒｅｃｏｒｄｅｒ−ＡおよびＲｅｃｏｒｄｅｒ−Ｂは、それぞれＡ社およびＢ社のレコーダである。また、各レコーダには、複数のコンテンツが記録されたディスクがセットされた状態である。
図３１の上段は、それぞれのレコーダが表示する機器メニューの例を示している。
機器メニューとは、レコーダが、自機にセットされたディスクに記録されているタイトルの名前等を、自機の表示部または自機に接続された表示装置に表示することを目的とする簡易なメニューである。
なお、“タイトル”とは、デジタルストリームの一部または全部である部分区間で構成されるＡＶコンテンツである。また、タイトルに関連するプレイリストにより、ＭＰＥＧストリーム等のデジタルストリームにおける部分区間の位置と、再生順序とが指定されることで当該タイトルが特定される。例えば、ユーザが撮影した１つの映像コンテンツが１つのタイトルとしてディスクに記録される。
図に示すように、Ｒｅｃｏｒｄｅｒ−Ａが表示する機器メニューは、ディスクに記録されているタイトルのサムネイルを複数並べて表示している。
また、Ｒｅｃｏｒｄｅｒ−Ｂが表示する機器メニューは、ディスクに記録されているコンテンツの記録日時をリスト形式で表示している。
このようにサムネイル等を用いて機器が独自に生成したメニューを表示するのは以下の理由による。すなわち、記録／撮影の日付やサムネイル（ＪＰＥＧ）の表示は処理時間が少なくユーザレスポンスが良いこと、および、ビデオカメラのような小さい表示デバイスしか装備していない機器にて適切なメニュー表示を行うためである。
これらレコーダは、機器メニューのほかに、ディスクメニューを生成し、ディスクに記録する機能を有している。
図３１の下段は、各レコーダが生成しディスクに記録したディスクメニューの例を示す図である。これらディスクメニューは各レコーダでは再生されず、当該ディスクを再生するプレーヤによって再生され、ユーザに提示される。
ディスクメニューは、“タイトル”の一種であり、自身以外のタイトルをユーザに選択させるものである。また、このように、レコーダにより生成されディスク等の情報記録媒体に記録される。
具体的には、実施の形態１で説明したＢＤ．ＩＮＦＯやＢＤ．ＰＲＯＧなどによって提供される機能によって構成されるメニューであって、ＴＶに接続されたプレーヤにて再生されることを想定しているメニューである。
そのため、大きな画面上に様々な情報を表示するように設計され、前述の機器メニューとは異なり、アニメーション効果や階層化された論理構成などを用いることもあり見た目も良い場合が多い。
図に示すように、レコーダごとにディスクメニューのデザインが異なるため、同じような記録／撮影を行っても図の下段のように異なる表示方式（デザイン）のディスクメニューが生成される。
このように、Ａ社のレコーダＲｅｃｏｒｄｅｒ−ＡとＢ社のレコーダＲｅｃｏｒｄｅｒ−Ｂでは、ディスクメニューが異なる。これは、ディスクメニューの実装はレコーダのメーカーごとに自由であるためである。
そのため、レコーダやビデオカメラ等の機器において、他のメーカーの機器でディスクメニューが記録されたディスクがセットされた場合、このディスクメニューを解釈できないことにより、前述のように、ディスクメニューの削除に伴う処理時間の増加等の問題が発生する。この問題についての詳細は図３４を用いて後述する。
図３２は、実施の形態２におけるＢＤ．ＩＮＦＯの内容を示す図である。図に示すようにＢＤ．ＩＮＦＯには、ディスクに記録されているタイトルを識別する情報群を格納する領域である“Ｉｎｄｅｘ”が存在する。当該ディスクを再生するプレーヤは、この“Ｉｎｄｅｘ”に格納されている情報に基づき、タイトルの再生等を行う。
なお、“Ｉｎｄｅｘ”に格納されている情報は、本発明の情報記録媒体におけるインデックス情報の一例である。
また、“Ｉｎｄｅｘ”には、“ＦｉｒｓｔＰｌａｙｂａｃｋ”、“ＴｏｐＭｅｎｕ”、および“Ｔｉｔｌｅ＃１”等のそれぞれのタイトルの再生を制御するプログラムの参照番号（ＰｒｏｇｒａｍＩＤＲｅｆ）だけが記述されている。
ＰｒｏｇｒａｍＩＤＲｅｆは、本発明の情報記録媒体におけるプログラム識別情報の一例であり、これらＰｒｏｇｒａｍＩＤＲｅｆにより、各プログラムが特定される。また、特定されたプログラムは、プレイリストを呼び出すことによりタイトルの再生を制御する。
なお、“ＦｉｒｓｔＰｌａｙｂａｃｋ”とは、ディスク挿入時に最初に再生すべきタイトル等を意味しており、情報として、そのタイトルの再生のためのプログラムの参照番号が格納される。
また、“ＴｏｐＭｅｎｕ”とは、リモコンでメニューボタンが押された場合などに選択されるタイトルであるディスクメニューを意味しており、情報として、ディスクメニューの再生のためのプログラムの参照番号が格納される。
また、図３２に示すＢＤ．ＩＮＦＯ内の“Ｉｎｄｅｘ”に格納されている、“ＦｉｒｓｔＰｌａｙｂａｃｋ”、“ＴｏｐＭｅｎｕ”、および“Ｔｉｔｌｅ＃１”等のそれぞれの名前は、本発明の情報記録媒体におけるタイトル識別情報の一例である。
また、ユーザが撮影した映像コンテンツ等の、ディスクメニュー以外のタイトルのタイトル識別情報は、“Ｔｉｔｌｅ”＋“＃タイトル番号”という形式である。タイトル番号については後述する。
具体的には、ディスクロード時に、“ＦｉｒｓｔＰｌａｙｂａｃｋ”に格納されているＰｒｏｇｒａｍＩＤＲｅｆに示される番号で指定されるプログラムが自動で実行される。また、ユーザがリモコンのメニューキーを押せば“ＴｏｐＭｅｎｕ”に登録されているＰｒｏｇｒａｍＩＤＲｅｆの番号で指定されるプログラムが実行される。
プレーヤの通常の動作としては、“ＦｉｒｓｔＰｌａｙｂａｃｋ”から参照されるプログラムに応じてディスクローディング時のオープニング映像を再生した後、もしくは一切何も表示せずに“ＴｏｐＭｅｎｕ”にジャンプし、“ＴｏｐＭｅｎｕ”にて規定されるディスクメニューを表示することになる。
また、“Ｔｉｔｌｅ＃１”〜“Ｔｉｔｌｅ＃ｎ”のそれぞれにはユーザが撮影および記録した映像コンテンツの再生を制御するプログラムを指定するＰｒｏｇｒａｍＩＤＲｅｆだけが登録される。
図３３は、実施の形態２におけるＢＤ．ＰＲＯＧの内容を示す図である。ＢＤ．ＩＮＦＯにて参照されるＰｒｏｇｒａｍＩＤＲｅｆの番号はＢＤ．ＰＲＯＧでのＰｒｏｇｒａｍの並び順である。
図に示すように、例えば、Ｐｒｏｇｒａｍ＃１は何らかの処理を行った後、ＧＰＲＭ０の値が０であるかの条件判定を行い、その値に応じて、ＧＰＲＭ０＝０であれば、１１１．ＰＬを、ＧＰＲＭ０がＧＰＲＭ３と同じであれば、ＧＰＲＭ０に２を加えた値の番号を持つＰＬの再生を行い、後続の処理を行うように記述されている。
このようにＢＤ．ＰＲＯＧに含まれるプログラムには、条件分岐（ｉｆ）、プレーヤ変数の一種であるＧＰＲＭ（ゼネラルパラメータ）を使った演算処理、および、プレイリストの再生命令（ＰｌａｙＰｌａｙＬｉｓｔ）などのコマンドを自由に組み合わせることができる。
図３４は、メニュー表示およびタイトル再生に係る表示および動作の遷移の一例を示す図である。
具体的には、プレーヤにおいて、前述のＢＤ．ＩＮＦＯおよびＢＤ．ＰＲＯＧによりメニューが再生され、その後、ユーザの指示により、ユーザが記録した映像コンテンツであるタイトルを再生し、またメニューに戻る一連の処理をデータ構造の面から説明する図である。
図３４において、表示および動作の遷移は、ＴｏｐＭｅｎｕとして左下のディスクメニューがＴＶに表示されている所から始まる。
このＴｏｐＭｅｎｕにおいて、ユーザがリモコンを使って一番右のボタン（Ｂｕｔｔｏｎ３）を選択し決定したことにより、ＴｏｐＭｅｎｕに関連するプレイリストである１００．ＰＬに指定されたストリーム（１００．ＶＯＢ）に多重化されているボタンプログラム（Ｂｕｔｔｏｎ Ｐｒｏｇｒａｍ３）が実行される。
ボタンプログラム（Ｂｕｔｔｏｎ Ｐｒｏｇｒａｍ３）は、Ｔｉｔｌｅ３の再生を意図するコマンド（ＪｕｍｐＴｉｔｌｅ（３））が書かれており、そのコマンドが実行されることによってＴｉｔｌｅ３の再生に遷移する。
具体的には、ＢＤ．ＩＮＦＯに記述された“Ｔｉｔｌｅ３”に示されるＰｒｏｇｒａｍＩＤＲｅｆのフィールドの値がｋであるために、ＢＤ．ＰＲＯＧのｋ番目のプログラム（Ｐｒｏｇｒａｍ＃ｋ）が実行される。
プログラム（Ｐｒｏｇｒａｍ＃ｋ）には、プレイリスト（２００．ＰＬ）の再生命令があるために２００．ＰＬの再生を行い、再生が終了した後で後続のコマンド処理が続けられる。
プログラム（Ｐｒｏｇｒａｍ＃ｋ）の最後では、ＴｏｐＭｅｎｕに戻るコマンド（ＪｕｍｐＴｏｐＭｅｎｕ（））が実行されるため元のＴｏｐＭｅｎｕが再び表示される。
以上がデータ構造から見たＴｏｐＭｅｎｕとＴｉｔｌｅ再生の仕組みである。
上記の表示および動作の遷移は、プレーヤが、ディスクメニューに関連するプレイリスト等の記述に沿って処理を行うことで実現され、ディスクメニューを生成したのがどのメーカーであるかによって問題が生じることはない。
しかし、１つのディスクが、互いに異なるメーカーのビデオカメラ間を移動する場合を想定すると、ディスクメニューについて、ビデオカメラ側、つまり、ディスクメニューを生成しディスクに記録する記録装置側における互換性がないことが問題となる。
すなわち、あるディスクにＲｅｃｏｒｄｅｒ−Ａだけが記録および編集を行う限りにおいては問題ない。しかし、Ｒｅｃｏｒｄｅｒ−Ａが記録を行ったディスクを、他メーカーの製品であるＲｅｃｏｒｄｅｒ−Ｂにセットし、Ｒｅｃｏｒｄｅｒ−Ｂ上で記録／編集を行う場合、Ｒｅｃｏｒｄｅｒ−Ａが生成したディスクメニューの設計ポリシーをＲｅｃｏｒｄｅｒ−Ｂは特定することができない。
そのため、ディスクメニューの既存部分を残しつつ、編集内容に応じた追加等をすることができないという問題がある。
これは、図３３に示すように、ＢＤ．ＰＲＯＧのＰｒｏｇｒａｍが再生状態に応じて変化するプレーヤ変数を使った条件分岐を行えるためである。
つまり、上記問題は、所定のＰｒｏｇｒａｍだけを見てもどのように動作するのかは、他の要素との関連があり特定することが実装上不可能であるだけなく、Ｒｅｃｏｒｄｅｒ−Ａで生成されたディスクメニューに使っている素材（背景やボタン映像の選択）のポリシーもＲｅｃｏｒｄｅｒ−Ｂには特定できないことに起因する。
例えば、Ｔｉｔｌｅ１を最初から最後まで再生したか否かをプレーヤ変数のＧＰＲＭ１００の値で管理しており、Ｔｉｔｌｅ２の再生がＴｉｔｌｅ１を再生済みであれば途中から、そうでなければＴｉｔｌｅ２の先頭からの再生を行うようにプログラムされている場合を想定する。
このような場合に、ＧＰＲＭ１００がＴｉｔｌｅ１の再生経歴を示す情報であり、それがＴｉｔｌｅ２の再生を制御するように設計されており、これ以外の他の要素が影響しないことを検証するためには、全ての再生可能なパターンでの再生をシミュレートすることが必要になる。
そのため、全てのＢＤ．ＰＲＯＧのプログラム（Ｐｒｏｇｒａｍ）、およびストリームに多重化された全てのボタンプログラム（Ｂｕｔｔｏｎ Ｐｒｏｇｒａｍ）を取得し解析し、プレーヤ変数の設定の意味を特定していかなければならず、データの読み込みおよび解析に膨大な時間がかかると思われる。
従って、ディスクメニューをＲｅｃｏｒｄｅｒ−ＡからＲｅｃｏｒｄｅｒ−Ｂに引き継ぐことは実質的に不可能である。
そこで、Ｒｅｃｏｒｄｅｒ−Ａが生成しディスクに記録したディスクメニューは、Ｒｅｃｏｒｄｅｒ−Ｂがそのディスクに対して記録および編集などを行う場合、ディスクメニューに関連する各種ファイルを全て削除し、一から作り直すことが、ディスク全体のデータの整合性を取る最も確実で簡易な方法である。
また、既存のディスクメニューに関連する各種ファイルを削除せずに、新たなディスクメニューを生成することも考えられるが、この場合、不要なファイルがディスクに蓄積していくことになる。これにより、ディスクの記録可能容量が無駄に消費されるだけでなく、ディスクをロードする機器において、ファイル管理に係る処理負担が増加することになる。
図３５は、異なるメーカーのレコーダ間でディスクの移動があった場合のディスクメニューの更新におけるルールを示す図である。
図３５（Ａ）は、ディスクメニューの更新においてＢＤ．ＩＮＦＯ等の各ファイルをどのように扱うかを示す図であり、図３５（Ｂ）は、図３５（Ａ）に示される番号の意味を説明する図である。
例えば、Ｒｅｃｏｒｄｅｒ−Ａによりコンテンツが記録されたディスクに対しＲｅｃｏｒｄｅｒ−Ｂがさらに記録および編集する場合、その編集によって追加または削除されたコンテンツをディスクメニューに反映しなければならない。
このように、Ｒｅｃｏｒｄｅｒ−Ｂが、Ｒｅｃｏｒｄｅｒ−Ａによりディスクメニューが記録されたディスクに対してコンテンツの記録および編集を行い、ディスクメニューを更新しなければならない場合、ＦｉｒｓｔＰｌａｙｂａｃｋおよびＴｏｐＭｅｎｕに関連する箇所の全て（ＢＤ．ＩＮＦＯの該当部分、ＢＤ．ＰＲＯＧの該当部分、ＸＸＸ．ＰＬの全て、ＹＹＹ．ＶＯＢＩの全て、ＹＹＹ．ＶＯＢの全て）を変更する。なお、「変更する」とは、当該データを削除して新たなものを生成することも含む。以下の記載においても同様である。
さらに、新しいＦｉｒｓｔＰｌａｙｂａｃｋおよびＴｏｐＭｅｎｕと整合性がとれたＴｉｔｌｅと、そのＴｉｔｌｅ用のＰｒｏｇｒａｍを規定しなおすために、Ｔｉｔｌｅに関しても関連する箇所の全て（ＢＤ．ＩＮＦＯの該当部分、ＢＤ．ＰＲＯＧの該当部分）を変更する。
逆に言えば、ディスクメニューの更新時にそのまま残るのは、ユーザが撮影した映像を格納している各Ｔｉｔｌｅのプレイリスト以下だけとなる。
また、上記の変更だけでメニュー更新が実現可能なように、Ｔｉｔｌｅで使用するストリーム（ＹＹＹ．ＶＯＢ）にはメニュー動作に影響するＢｕｔｔｏｎ Ｐｒｏｇｒａｍを含ませないことも重要である。
このようなルールに従えば、異なるメーカーのレコーダ間でディスクを移動させた場合においても、ディスク全体のデータ整合性を維持しつつ、ディスクメニューを更新することができる。
しかしながら、このルールによれば、ＦｉｒｓｔＰｌａｙｂａｃｋおよびＴｏｐＭｅｎｕが使用するプレイリストを特定する必要があるが、これは前述のように実質的に不可能である。そのため、ディスクメニューの更新時に、どのＸＸＸ．ＰＬを削除すれば良いのかは分からないという問題が依然として残存する。
そこで、図３６に示すようにＢＤ．ＩＮＦＯの“Ｅｘｔｅｎｓｉｏｎ”に、以下のような情報を格納しておくことが有効である。
図３６は、ＢＤ．ＩＮＦＯの“Ｅｘｔｅｎｓｉｏｎ”にプレイリストを特定するための情報を格納した状態を示す図である。
“Ｅｘｔｅｎｓｉｏｎ”は、ＢＤ．ＩＮＦＯの末尾に設けられた拡張領域であり、このように、規格に規定されていない情報を格納することができる領域である。また、“Ｅｘｔｅｎｓｉｏｎ”からは、プレーヤは情報を読み出す義務がないため、規格に規定されていない情報を格納した場合であってもプレーヤに何らかの悪影響を与えることはない。
なお、“Ｅｘｔｅｎｓｉｏｎ”に格納されている情報は、本発明の情報記録媒体における拡張情報の一例である。
以下に、“Ｅｘｔｅｎｓｉｏｎ”に格納されている情報について説明を行う。
（１）“ＭａｋｅｒＩｎｆｏ”は、本発明の情報記録媒体における生産者識別情報の一例であり、メーカーを識別する識別子である“ＭａｋｅｒＩＤ”と、このＢＤ．ＩＮＦＯを記録した機器を特定する識別子“ＭｏｄｅｌＩＤ”とを含む情報である。
（２）“ＤｉｓｃＩｎｆｏ”は、このディスク上に記録可能な、もしくは既に記録されている映像のフレームレートを特定する情報であり、以下の各情報を含んでいる。
“ＩｓＮＴＳＣ”は、２９．９７／５９．９４Ｈｚのフレームレートの映像符号化を行って良いか、もしくはそれらのフレームレートの映像が既に記録されているかを示す情報である。
“ＩｓＰＡＬ”は、２５／５０Ｈｚのフレームレートの映像符号化を行って良いか、もしくはそれらのフレームレートの映像が既に記録されているかを示す情報である。
“ＩｓＦＩＬＭ”は２３．９７／２４Ｈｚのフレームレートの映像符号化を行って良いか、もしくはそれらのフレームレートの映像が既に記録されているかを示す。
なお、“ＩｓＮＴＳＣ”と“ＩｓＰＡＬ”が１つのディスクに混在するのは一部のコンテンツが再生できない事態を招きうるため禁止される。
因みに“ＩｓＦＩＬＭ”は“ＩｓＮＴＳＣ”および“ＩｓＰＡＬ”のどちらとも共存が可能である。例えばレコーダは２９．９７／５９．９４Ｈｚのフレームレートの映像符号化を行って記録する場合には事前に“ＩｓＮＴＳＣ＝１”となっているかを確認して記録する。
もし“ＩｓＮＴＳＣ＝０”の場合には、“ＩｓＰＡＬ＝０”であるかを確認し“ＩｓＮＴＳＣ＝１”と書き換えて記録する。もしくは“ＩｓＮＴＳＣ＝０”かつ“ＩｓＰＡＬ＝１”であってもディスク上に２５／５０Ｈｚのフレームレートの映像がないことを確認した上で、“ＩｓＮＴＳＣ＝１”および“ＩｓＰＡＬ＝０”と書き換えて記録することができる。このようにすることで、ディスク上でのＮＴＳＣ／ＰＡＬ混在をストリームのフレームレートを全て調べることなく簡易に防ぐことが可能である。
（３）“ＦｉｒｓｔＰｌａｙｂａｃｋ”は、ＢＤ．ＩＮＦＯ内の“Ｉｎｄｅｘ”に含まれる“ＦｉｒｓｔＰｌａｙｂａｃｋ”により指定されるプログラムから呼び出されるプレイリストの総数を示す“ＰｌａｙＬｉｓｔＮｕｍｂｅｒ”と、そのプレイリストの番号を示す“ＰｌａｙＬｉｓｔＩＤ”とを含む情報である。
なお、ＰｌａｙＬｉｓｔＩＤは、本発明の情報記録媒体におけるプレイリスト識別情報の一例である。
（４）“ＴｏｐＭｅｎｕ”は、ＢＤ．ＩＮＦＯ内の“Ｉｎｄｅｘ”に含まれる“ＴｏｐＭｅｎｕ”により指定されるプログラムから呼び出される可能性のあるプレイリストの総数を示す“ＰｌａｙＬｉｓｔＮｕｍｂｅｒ”と、そのプレイリストの番号を示す“ＰｌａｙＬｉｓｔＩＤ”とを含む情報である。
（５）“ＴｉｔｌｅＰＬＰａｉｒＮｕｍｂｅｒ”は、下記に示す“ＴｉｔｌｅＰＬＰａｉｒ”の総数を示す情報である。
（６）“ＴｉｔｌｅＰＬＰａｉｒ”は、プレイリストの番号を示す“ＰｌａｙＬｉｓｔＩＤ”と、そのプレイリストにより特定されるタイトルのタイトル番号（Ｔｉｔｌｅ＃ｎとＸＸＸ．ＰＬは１対１で使用することを想定）を示す“ＴｉｔｌｅＩＤ”とを含む情報である。
タイトル番号とは、上述のように、タイトル識別情報である“Ｔｉｔｌｅ＃ｎ”の“ｎ”の部分の数字である。つまり、タイトル番号はタイトル識別情報に対応する数字である。
このように、ＢＤ．ＩＮＦＯの拡張領域である“Ｅｘｔｅｎｓｉｏｎ”に記述された“ＭａｋｅｒＩｎｆｏ”に示される情報によって、ビデオカメラ等のレコーダはこのディスクに記録されたメニューを生成したレコーダのメーカーを特定する情報と機器を特定する情報を得ることができる。
ディスクがセットされたレコーダにおいて、仮に、自機がディスクメニューを記録したディスクであることが判明した場合、ディスクメニュー（ＦｉｒｓｔＰｌａｙｂａｃｋ／ＴｏｐＭｅｎｕ）を一から作り直すことなく、特定の差分情報の更新だけを行えばよく、メニューの更新時間を短縮することが可能である。
また、ディスクがセットされたレコーダは、“ＭａｋｅｒＩｎｆｏ”に示される情報を参照することにより、他メーカーのレコーダでディスクメニューが記録されたディスクであるか否かの判定が可能であり、他メーカーのレコーダでディスクメニューが記録されたディスクであると判定した場合は、ディスクメニューを一からつくり直すことにより更新する。
さらに、ＢＤ．ＩＮＦＯの拡張領域である“Ｅｘｔｅｎｓｉｏｎ”に記述された“ＦｉｒｓｔＰｌａｙｂａｃｋ”に示される情報および“ＴｏｐＭｅｎｕ”に示される情報によって、ディスクメニューで使用されているプレイリスト（ＸＸＸ．ＰＬ）を容易に特定できる。そのため、そのプレイリストを解析することにより使用するＹＹＹ．ＶＯＢＩ、ＹＹＹ．ＶＯＢを特定することができる。
すなわち、ディスクメニューに関連するＸＸＸ．ＰＬ、ＹＹＹ．ＶＯＢＩ、ＹＹＹ．ＶＯＢファイルの全てを容易に特定でき、これらを削除することが可能となる。
つまり、削除の対象となるタイトルに関連するプレイリスト、当該タイトルの管理情報、および、当該プレイリストに指定されるデジタルストリームの部分区間を削除することができる。
このように、ディスクメニューに関連するプレイリストを容易に特定できる情報をディスクに記憶させておくことで、ディスクメニューに関連する各種ファイルを容易に特定でき、これらを削除した上でディスクメニューを新たに生成することができる。
これにより、互いに異なるメーカーの機器間でディスクが移動した場合であっても、ディスクメニューに関連する各種ファイルを削除した上で、新たなディスクメニューを生成することができる。
つまり、前述のような情報が記録された情報記録媒体は、いずれのメーカーの記録装置においても、不要な処理負荷や処理時間が発生させることなく、ディスク全体のデータの整合性を保ちながら、容易にディスクメニューを更新させることができる。
次に、ディスクメニューの更新時のタイトル番号の保持について説明する。
多くの公開文献や実施の形態１でも示されているように、ＤＶＤ−ＶｉｄｅｏやＢＤ−ＲＯＭのような情報記録媒体を再生するプレーヤではタイトルとチャプターという２つの階層を用いてユーザにコンテンツを提供している。
一般的なプレーヤではタイトルサーチという機能が実装されている。ユーザは、この機能により、ＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）のディスクメニューを経由せずに、直接リモコンの数字キーなどを使ってタイトル番号を指定し、そのタイトルから再生を開始することが可能である。
なお、タイトル番号とは、ＢＤ．ＩＮＦＯのＩｎｄｅｘ部分にて表現されたＴｉｔｌｅのループ順を意味しているため、タイトル１とは、ループ順で先頭のＴｉｔｌｅを意味する。
ここで、将来的には、ディスクのラベルにタイトル番号とそのコンテンツの内容を表すような情報（記録日時や放送局のチャンネル、サムネイル映像など）を印刷することもあると思われる。
ＣＤ−ＤＡ（Ｃｏｍｐａｃｔ Ｄｉｓｃ Ｄｉｇｉｔａｌ Ａｕｄｉｏ）のようなオーディオコンテンツを収録したディスクのラベルに、曲番号と曲名の組み合わせを印刷しているように、本発明の記録装置を利用するユーザにとってタイトルとそのコンテンツとの関連はタイトルサーチの機能が利用できる以上、とても重要である。
ここで、あるコンテンツと、そのコンテンツに付されたタイトル番号との関係、つまり、あるコンテンツに関連するプレイリストと、そのプレイリストに関連付けられたタイトル番号との関係は、パッケージメディア（Ｒｅａｄ Ｏｎｌｙ Ｍｅｄｉａ）では変更されることがないため、考える必要がない。
しかし、情報の記録および編集が可能な情報記録媒体においては、あるメーカーのレコーダで生成されたディスクメニューが、他のメーカーのレコーダで更新される際に、上記のコンテンツとタイトル番号との関係は維持されない。
そのため、例えば、ユーザが、上記のＲｅｃｏｒｄｅｒ−Ａで映像コンテンツを記録したディスクにおいて、タイトル番号が“１”であると認識していたコンテンツが、その後にＲｅｃｏｒｄｅｒ−Ｂによりディスクメニューが更新されたために、不意にタイトル番号が“３”に変更される場合がある。
もちろん、ディスクメニューの更新の前に、どのコンテンツ、つまりタイトルが、どのプレイリストと関連しているのか、つまり、どのプレイリストを参照しているのかを容易に知ることができるのであれば、その時点でコンテンツに付されているタイトル番号を取得し、更新の際に維持しておくことは可能である。
しかし、どのタイトルがどのプレイリストと関連しているかを取得するためには、図３２に示すＴｉｔｌｅ＃１・・・Ｔｉｔｌｅ＃ｎに示される、ＢＤ．ＰＲＯＧに記録されている各Ｐｒｏｇｒａｍを解析する必要があり、前述のように非常に困難である。
従って、本実施の形態では、図３６に示すようにＢＤ．ＩＮＦＯの“Ｅｘｔｅｎｓｉｏｎ”に、タイトル番号（ＴｉｔｌｅＩＤ）とそのプレイリスト番号（ＰｌａｙＬｉｓｔＩＤ）とを含む情報として“ＴｉｔｌｅＰＬＰａｉｒ”を記述する。
また、タイトル番号とそのプレイリスト番号とは順次追加記録される。つまり、ＴｉｔｌｅＰＬＰａｉｒの中の記述順はそのプレイリスト（ＰｌａｙＬｉｓｔＩＤで特定されるプレイリスト）の記録日時順である。
これによって、以前のタイトル番号とそのコンテンツ（つまり、プレイリスト）との対応を崩さないようにメニューを更新することが可能となり、ユーザにとっては不意にタイトル番号とコンテンツの相関が変更されることを防ぐことができる。
なお、あるディスクにおいて記録されていたタイトルが削除された場合には、タイトル番号がＢＤ．ＩＮＦＯのＩｎｄｅｘ内のループ順であることから、削除したタイトルにダミーのプレイリストを付与してもよい。
更に、そのコンテンツとして“Ｄｅｌｅｔｅｄ Ｔｉｔｌｅ”などと既にそのタイトルに関連していたコンテンツが削除されたことをユーザに認識させるような映像等のコンテンツを、削除されたタイトルに関連するプレイリストに関連付ける。こうすることにより、他のタイトル番号に影響させないことができる。
また、上記の削除されたことを示すコンテンツはタイトルサーチの操作においてのみ再生可能であって、ディスクメニューでは選択されないように実装される。
図３７は、実施の形態２における、ディスクメニューの更新前後のタイトルとプレイリスト（コンテンツ）との相関の例を示す図である。
あるディスクにおいて、ある時点で図３７（Ａ）に示すように、ディスク上に３つのタイトルがあり、それぞれのタイトルが１０１．ＰＬ、１０２．ＰＬ、１０３．ＰＬのプレイリストと関連付けられていると想定する。また、各プレイリストが上記の順番で、コンテンツＡ、Ｂ、Ｃに関連するものである場合を想定する。
この想定下において、レコーダでＴｉｔｌｅ２を全削除し、新規にコンテンツＤを記録した場合、図３７（Ｂ）に示すようにタイトルとプレイリスト（コンテンツ）の関係が一部変更される。
具体的には、削除されたＴｉｔｌｅ２はＢＤ．ＩＮＦＯのＩｎｄｅｘから削除されることなくそのまま残され、Ｔｉｔｌｅ２のプレイリスト１０２．ＰＬが参照するＡＶストリーム（ＹＹＹ．ＶＯＢ）が、Ｔｉｔｌｅ２がユーザの編集操作によって削除されたことを示す映像や音声情報に置き換わる。
また、Ｔｉｔｌｅ１およびＴｉｔｌｅ３については、タイトル番号とプレイリスト（コンテンツ）との関係は維持される。つまり、それらタイトルに付与されたタイトル番号に変更はない。
また、新たに記録されたコンテンツＤは図３６に示すＴｉｔｌｅＰＬＰａｉｒの中で最後に追加される。
つまり、ＴｉｔｌｅＰＬＰａｉｒの中の記述順はそのプレイリスト（ＰｌａｙＬｉｓｔＩＤで特定されるプレイリスト）の記録日時順を示すことになるため、記録日時順でメニュー表示を行う場合に有用である。
次に、図３２、図３３、および図３６に示すデータ構造を有するディスクに対し、前述のようなメニューの更新や各種情報の操作を行うレコーダの構成および動作について以下に述べる。
図３８は、実施の形態２のレコーダの機能的な構成を示す機能ブロック図である。
図３８に示すレコーダ４００は、本発明の記録装置の一例であり、例えば、映像をデジタルストリームとして記録するビデオカメラとして実現される。
なお、レコーダ４００は、デジタルストリームを記録する記録装置が本来有する、エンコーダ等の他の構成部を備えているが、本発明の特徴を明確にするために、それら他の構成部についての図示および説明は省略する。
レコーダ４００は、図３８に示すようにプレイリスト特定部４０１、削除部４０２、メニュー生成部４０３、メーカー判定部４０４、受付部４０５、編集部４０６、番号読出部４０７、撮影部４０８、および表示部４０９を備える。
また、情報記録媒体として、図３２、図３３、および図３６に示すデータ構造を有するディスク１０５を使用する。
プレイリスト特定部４０１は、ディスクメニュー等のタイトルの再生を制御するプログラムから呼び出されるプレイリスト、つまり、処理の対象とするタイトルに関連するプレイリストを図３６に示すＰｌａｙＬｉｓｔＩＤを用いて特定する処理部である。
メニュー生成部４０３は、ディスク１０５に記録されているメニューに換えて、新たなメニューを生成しディスク１０５記録する処理部である。
削除部４０２は、メニュー生成部４０３により新たなメニューが生成される場合、ディスク１０５に記録されているメニューに関連するプレイリストを削除する処理部である。なお、削除するプレイリストは、プレイリスト特定部４０１により特定される。
メーカー判定部４０４は、図３６に示すＥｘｔｅｎｓｉｏｎに含まれるＭａｋｅｒＩｎｆｏに示されるメーカーが、レコーダ４００を生産したメーカーと一致するか否かを判定する処理部である。
受付部４０５は、ユーザまたはレコーダ４００に接続された機器から入力される、レコーダに対する指示等を受け付ける処理部である。
編集部４０６は、ディスク１０５に記録されているタイトルの編集を行う処理部である。
番号読出部４０７は、“Ｅｘｔｅｎｓｉｏｎ”に含まれるタイトル番号、つまり、ＴｉｔｌｅＩＤをディスク１０５から読み出す処理部である。
撮影部４０８は、映像をデジタルストリームとしてディスク１０５に記録する処理部である。
表示部４０９は、レコーダ４００が備える小型の液晶デバイス等である。表示部４０９には、図３１の上段に示す簡易な機器メニューが表示される。
このように構成されたレコーダ４００の基本的な動作の概要は以下のようになる。なお、レコーダ４００を生産したメーカーとは異なるメーカーのレコーダにより生成されたディスクメニューがディスク１０５に既に記録されていると場合を想定する。
このディスク１０５がレコーダ４００にセットされると、プレイリスト特定部４０１は、ディスクに記録されているディスクメニューに関連するプレイリストを、“Ｅｘｔｅｎｓｉｏｎ”に含まれる、“ＴｏｐＭｅｎｕ”に対応付けられたＰｌａｙＬｉｓｔＩＤを用いて特定する。
メニュー生成部４０３は、新たなディスクメニューを生成しディスク１０５に記録する。また、削除部４０２は、プレイリスト特定部４０１により特定されたプレイリストをはじめ、他メーカーのレコーダにより生成されたディスクメニューに関連する各種ファイルを削除する。
このようにして、レコーダ４００は、他メーカーのレコーダにより生成されたディスクメニューを削除し、新たなディスクメニューをディスクに記録することができる。
次に、レコーダ４００がディスク１０５上のタイトル構成を更新する際の動作の流れを説明する。
図３９は、実施の形態２のレコーダ４００における記録/編集時のタイトル構成の更新時の動作の流れの概要を示すフロー図である。
ユーザの指示等により、新たなタイトルの記録または既存のタイトルに対する編集が開始される（Ｓ８０１）と、編集部４０６は、ＢＤ．ＩＮＦＯおよびＢＤ．ＰＲＯＧをディスク１０５から読み込む（Ｓ８０２）。さらに、番号読出部４０７は、ディスク１０５に記録されているタイトル番号の最後の番号を取得する。
具体的には、ＢＤ．ＩＮＦＯの“Ｉｎｄｅｘ”に含まれる“Ｔｉｔｌｅ＃１”から並んで存在するタイトル識別情報から最後のタイトル番号（Ｔｎ）を取得する（Ｓ８０３）。
例えば、“Ｉｎｄｅｘ”に“Ｔｉｔｌｅ＃１”、“Ｔｉｔｌｅ＃２”、“Ｔｉｔｌｅ＃３”と存在する場合、“３”が取得される。
その後、編集部４０６が、ＸＸＸ．ＰＬ、ＹＹＹ．ＶＯＢＩ、およびＹＹＹ．ＶＯＢを必要に応じて更新し（Ｓ８０４）、新規にタイトルを記録した場合、上記Ｔｎ以降の番号に、新規に記録したタイトルを割り振り、読み出したＢＤ．ＩＮＦＯにその番号とタイトルとを記録する（Ｓ８０５）。
例えば、Ｔｎ＝“３”である場合、新たなタイトルが記録されると、そのタイトルにはタイトル番号“４”が付与される。
この場合、編集部４０６により、ＢＤ．ＩＮＦＯの“Ｉｎｄｅｘ”に“Ｔｉｔｌｅ＃４”が追加され、更に、“Ｅｘｔｅｎｓｉｏｎ”にＴｉｔｌｅＩＤである“４”と、Ｔｉｔｌｅ４に関連するプレイリストのＰｌａｙＬｉｓｔＩＤとが対応付けられて追加される。
また、上記Ｔｎ以前のタイトル番号のタイトルで削除されたものがある場合、編集部４０６は、その削除されたタイトルのタイトル番号を削除するのではなく、そのタイトル番号に関連するプレイリストに示されるデジタルストリームの部分区間をタイトルが削除されたことを示す内容のダミーのデジタルストリームに置き換える。つまり、削除されたタイトルにダミーのデジタルストリームを付与する（Ｓ８０６）。
ダミーのデジタルストリームとは、前述のように、“Ｄｅｌｅｔｅｄ Ｔｉｔｌｅ”等の映像のデータ等である。
この削除の際には、具体的には、プレイリスト特定部４０１が、削除されたタイトルのタイトル番号、つまりＴｉｔｌｅＩＤと対応付けられているＰｌａｙＬｉｓｔＩＤから、削除されたタイトルに関連するプレイリストを特定する。
このような動作により、例えば、タイトル番号“２”のタイトルが削除された場合、タイトル番号“２”を削除するのではなく、タイトル番号“２”に、“Ｄｅｌｅｔｅｄ Ｔｉｔｌｅ”と名付けられた映像等のデータが対応付けられる。
このように、更新されたＢＤ．ＩＮＦＯおよびＢＤ．ＰＲＯＧ等をディスク１０５に書き込む（Ｓ８０７）。以上により、一連の記録／編集に係る動作を終了する。
上記のように、タイトル番号とそのコンテンツ（関連するプレイリスト番号）の関係を崩すことなくＢＤ．ＩＮＦＯを更新することで、ディスクメニューではなく、タイトルサーチで直接コンテンツの再生を行うような場合であっても、ディスクメニューの更新の度にタイトル番号とコンテンツとの関係が変わることを防ぐことができ、ユーザの利便性を高めることができる。
またこの際に、ディスクメニューでは削除したタイトルは選択できない（一切表示されない）ように作りこむことで、ＧＵＩを使ったディスクメニューからコンテンツ再生を制御するユーザに対してもＴｉｔｌｅ２をダミーで残す悪影響を与えることがないようにすることができる。
なお、本実施の形態において、図３２等に示すデータ構造を有する情報記録媒体としてディスクを用いたが、情報を記録できる媒体であれば、ＢＤおよびＤＶＤ等のディスクでなくてもよい。例えば、フラッシュメモリ等の半導体メモリでもよい。
なお、“ＦｉｒｓｔＰｌａｙｂａｃｋ”、“ＴｏｐＭｅｎｕ”に関連するコンテンツ（ＶＯＢファイル）が、“Ｔｉｔｌｅ”からも参照されている場合、ディスクメニューを削除すると、“ＦｉｒｓｔＰｌａｙｂａｃｋ”と“ＴｏｐＭｅｎｕ”として登録されたプレイリストとそのプレイリストから参照されるコンテンツ（ＶＯＢファイル）とが削除され、タイトルの再生に支障をきたすこととなる。従って、これは禁止されるべきである。
本実施の形態で言えば、ＢＤ．ＩＮＦＯの“Ｅｘｔｅｎｓｉｏｎ”に記述される“ＦｉｒｓｔＰｌａｙｂａｃｋ”、“ＴｏｐＭｅｎｕ”のプレイリストが参照するコンテンツ（ＸＸＸ．ＶＯＢ）が、同じくＢＤ．ＩＮＦＯの“Ｅｘｔｅｎｓｉｏｎ”に記述される“Ｔｉｔｌｅ”のプレイリストが参照することは禁止される。
ディスクメニュー（ＦｉｒｓｔＰｌａｙｂａｃｋ／ＴｏｐＭｅｎｕ）とそのディスクに記録されたタイトルが同じＶＯＢを参照しないことが、迅速なディスクメニューの更新、つまりディスクメニューに関わるファイルの特定と削除のために必要である。
なお、ＢＤ．ＩＮＦＯ内の“Ｅｘｔｅｎｓｉｏｎ”として説明した情報が無い場合であっても、“ＦｉｒｓｔＰｌａｙｂａｃｋ”、“ＴｏｐＭｅｎｕ”が参照するプレイリストのファイル番号と、“Ｔｉｔｌｅ”が参照するプレイリストのファイル番号とを別個の範囲とすることでディスクメニューの更新のために、更新が必要なプレイリストファイルを迅速に特定することが可能である。
また、プレイリストを削除する際、図３６に示す“ＴｉｔｌｅＰＬＰａｉｒ”に含まれる“ＰｌａｙＬｉｓｔＩＤ”から、当該プレイリストが他のタイトルにも関連していないか事前に検索し、関連していなければ削除するという対策を取ってもよい。
（実施の形態３）
次に本発明の実施の形態３について説明する。
基本的には実施の形態１に基づく内容であり、拡張または異なる部分を中心に説明する。
本発明の実施の形態１において、図１８を用いてＢＤ管理情報の１つで、ディスク全体の情報を管理する“ＢＤ．ＩＮＦＯ”の例を説明したが、本実施の形態では図４０の形式を取るものとする。
ＢＤ．ＩＮＦＯはディスクに１つだけ存在し、当該ディスクが挿入された際に一番初めに解釈される。図４０におけるＢＤ．ＩＮＦＯは、ＡｐｐＩｎｆｏとＴｉｔｌｅＬｉｓｔ、ＥｘｔｅｎｓｉｏｎＤａｔａからなり、ＡｐｐＩｎｆｏにはディスク全体に関する情報が格納される。
なお、図４０に示す“ＴｉｔｌｅＬｉｓｔ”および“ＥｘｔｅｎｓｉｏｎＤａｔａ”のそれぞれは、図３６に示す、実施の形態２における“Ｉｎｄｅｘ”および“Ｅｘｔｅｎｓｉｏｎ”に相当する情報領域である。
ＴｉｔｌｅＬｉｓｔには当該ディスクに格納されるＴｉｔｌｅの情報が格納されており、ＦｉｒｓｔＰｌａｙｂａｃｋとＴｏｐＭｅｎｕという二つの特別なＴｉｔｌｅと複数の通常のＴｉｔｌｅからなる。通常のＴｉｔｌｅの総数はＴｉｔｌｅＬｉｓｔ以下のＮｕｍｂｅｒに格納される。ＦｉｒｓｔＰｌａｙｂａｃｋとＴｏｐＭｅｎｕと各Ｔｉｔｌｅは各々タイトル選択時に実行すべき後述するＯｂｊｅｃｔへのリンク情報（ＯｂｊｅｃｔのＩＤ）を持っている。ＦｉｒｓｔＰｌａｙｂａｃｋは、ディスク挿入時に一番最初に選択されるタイトルであり、ＴｏｐＭｅｎｕは、リモコンでメニューボタンが押された場合などに選択される再生メニュー用のタイトルである。
次にＯｂｊｅｃｔに関する情報を格納する“ＢＤ．ＰＲＯＧ”について図４１を用いて説明する。Ｏｂｊｅｃｔとは複数のナビゲーションコマンドからなるプログラム群であり、Ｏｂｊｅｃｔを実行する際はナビゲーションコマンドを１つずつ逐次実行される。
図４１に示すように“ＢＤ．ＰＲＯＧ”は格納するＯｂｊｅｃｔの総数を示すＮｕｍｂｅｒおよび各Ｏｂｊｅｃｔのエントリからなる。図中にある各Ｏｂｊｅｃｔの添え字（＃１など）はＯｂｊｅｃｔのＩＤであり、各ＯｂｊｅｃｔはＩＤ順に並ぶものとする。
前述のようにタイトルからはこのＯｂｊｅｃｔＩＤを元にタイトル選択時に実行されるＯｂｊｅｃｔが参照されている。各ＯｂｊｅｃｔはＯｂｊｅｃｔＩｎｆｏ領域とＰｒｏｇｒａｍ領域とからなる。ＯｂｊｅｃｔＩｎｆｏ領域にはＯｂｊｅｃｔの設定情報が格納される。Ｐｒｏｇｒａｍ領域には当該Ｏｂｊｅｃｔ実行時に逐次実行するナビゲーションコマンド群が格納される。
なお、図４１に示す“ＢＤ．ＰＲＯＧ”は実施の形態１において図１８を用いて説明した“ＢＤ．ＰＲＯＧ”に変わるものであり、合わせて図１７を用いて説明した“ＸＸＸ．ＰＲＯＧ”は廃止される。
また、実施の形態１において説明したイベントに関しては、他の機能により代替される。例えば図２０を用いて説明したタイムイベント及び図２１を用いて説明したユーザイベントは、詳しくは後述するがストリーム中に埋め込まれるナビゲーションコマンドに相当するボタンにより代替される。
また、図２２を用いて説明したグローバルイベントは、リモコンキー操作毎にプレーヤの実行動作が規定されることとなる。
例えば図２２で説明したようにリモコンのＭｅｎｕキーが押された場合、前述したＢＤ．ＩＮＦＯで規定されるタイトルの１つであるＴｏｐＭｅｎｕが自動選択されるよう規定されており、結果、ＴｏｐＭｅｎｕからリンクが張られたＯｂｊｅｃｔが選択され、ＢＤ．ＰＲＯＧ中の当該ＯｂｊｅｃｔのＰｒｏｇｒａｍ領域に格納されたコマンド群が実行されることになる。
次に、本実施の形態におけるナビゲーション機能の１つであるボタンおよびページについて説明する。
本発明の実施の形態１にて、図２０〜図２１を用いてイベントを契機としたボタン描画の例を説明したが、ＢＤ−ＲＯＭ規格に於いては、前述したＤＶＤのＮＶ＿ＰＣＫと同じく、ナビゲーションコマンドをページ及びにボタン（ＮＶ＿ＤＳ）として、ＭＰＥＧ−ＴＳ形式のストリーム中にビデオエレメンタリストリーム（Ｖ＿ＰＥＳ）やオーディオエレメンタリストリーム（Ａ＿ＰＥＳ）と一緒に埋め込むことができる。
ＢＤ−ＲＯＭにおいて、インタラクティブを実現するナビゲーション機能をストリーム化し、映像、音声、字幕などのＡＶデータと共にストリームに多重化する構成について説明する。
なお、本発明の実施の形態１では、ＢＤ−ＲＯＭ Ｄｉｓｃに記録するＡＶストリームをＭＰＥＧ−ＰＳに準じた形で説明していたが、本実施の形態ではＡＶストリームをＭＰＥＧ−ＴＳ形式で実現する。
本実施の形態におけるＡＶストリームを、図４２を用いて説明する。
図４２に示すように、映像、音声、字幕そしてインタラクティブを実現するナビゲーションなどのエレメンタリストリーム（図４２の（１））は、それぞれＰＥＳストリーム化され（図４２の（２））、さらにそれぞれが一本のＭＰＥＧ−ＴＳに多重化される（図４２の（３））。
なお、ＭＰＥＧ−ＴＳにおける多重化も、多重化する個々のデータはそのデコード順に基づくビット列になっているが、多重化されるデータ間、即ち、映像、音声、字幕、ナビゲーションの間は必ずしも再生順、言い換えればデコード順に基づいてビット列が形成されているわけではない。
ＭＰＥＧ−ＴＳのデコーダモデル（図４２の（４））も多重化を解いた後に個々のエレメンタリストリームに対応するデコーダバッファを持ち、デコードタイミングまでに一時的にデータを蓄積している。
次にＢＤ−ＲＯＭにおけるページとボタンの具体的な内容を説明する。
ＢＤ−ＲＯＭにおけるナビゲーション機能ではページとボタンの二つの概念を提供している。
ページはボタンをグループ化して管理する単位であり、ボタンはユーザの操作に応じて実動作を行う単位である。
具体的にディスプレイセット（ＮＶ＿ＤＳ）としてページがどの様な情報を持ちＭＰＥＧ−ＴＳに多重化されているのかを図４３を用いて説明する。
図４３に示すように、ページは、自身の「ページＩＤ」と、ページ遷移時のアニメーション効果が設定された「アニメーション情報」と、ページ内の描画パレットが設定された「パレット情報」と、ページがｏｎになった際に選択状態にするボタンのボタンＩＤが設定された「デフォルト選択ボタンＩＤ」と、ページがｏｎになった際に実行するボタンのボタンＩＤが設定された「デフォルト実行ボタンＩＤ」と、当該ページに所属するボタン群の情報が設定された「所属ボタン情報」とがＮＶ＿ＤＳに設定され、図４２を用いて前述したようにＭＰＥＧ−ＴＳに多重化される。
次に、ディスプレイセットとしてボタンがどの様な情報を持ちＭＰＥＧ−ＴＳに多重化されているのかを図４４を用いて説明する。
図４４に示すように、ボタンは、自身の「ボタンＩＤ」と、自身の大きさやボタン画像として描画する内容等を示す「領域情報」と、ボタンが選択された際に自身に設定されたナビゲーションコマンドを自動実行するか否かを示す「自動実行可否フラグ」と、自身が選択された状態でリモコンによるユーザ操作（上下左右）が発生した際にどのボタンに遷移するかが設定された「ボタン遷移情報」と、ボタンが選択されたり押下されたりするなどボタンの状態が変化した際に鳴らす効果音や実行するアニメーション効果などが設定された「状態情報」と、ボタンが押下されるなどボタンが有効になった際に実行するナビゲーションコマンド群が設定された「実行コマンド」とがＮＶ＿ＤＳに設定され、図４２を用いて前述したようにＭＰＥＧ−ＴＳに多重化される。
以上、ＢＤ−ＲＯＭにおけるナビゲーション機能の１つであるページとボタンについて説明したが、前述したタイムイベント及びユーザイベントはこのページとボタンにより実現される。
例えばタイムイベントは、ボタンをストリームの所望の位置に再生されるように埋め込み、前記「自動実行可否フラグ」を設定しておくことで、ストリーム再生中に所定の時刻に前記ボタンに設定された「実行コマンド」が実行されることになる。
また、ユーザイベントに関しても所望の動作を行うように「ボタン遷移情報」及び「実行コマンド」を設定したボタンをストリームに多重化しておくことで実現可能である。
また、ページおよびボタンを活用することで、撮影した映像を再生する再生メニューなどインタラクティブなユーザインターフェースを実現出来る。
例えば図４５に示すように階層化されたメニューを実現する場合、トップメニューと二つのサブメニュー毎に各メニューに表示したいボタンを取りまとめるページを用意する。トップメニューではボタン１、２を取りまとめるページ１、サブメニュー１ではボタン３を表示するページ２、サブメニュー２ではボタン４，５を取りまとめるページ３を設け、前述したようにストリームに多重化する。
トップメニューからサブメニューへの遷移はボタン１、２のようにメニュー遷移用のボタンを用意し、ボタン押下に合わせて切り替えるよう設定する。例えばボタン１はトップメニューからサブメニュー１への遷移を行うために、ボタン押下時にページ１をｏｆｆにし、ページ２をｏｎにするナビゲーションコマンドが前記実行コマンド領域に設定されている。
また、ボタン２でも同様にトップメニューからサブメニュー２への遷移を行うために、ボタン押下時にページ１をｏｆｆにし、ページ２をｏｎにするナビゲーションコマンドが前記実行コマンド領域に設定されている。
また、実行コマンド領域で指定可能なナビゲーションコマンドはページ遷移以外にも様々なナビゲーションコマンドを指定可能である。例えばボタン３のようにプレイリスト再生中にチャプターを切り替えるナビゲーションコマンドを設定したり、ボタン５のように表示する字幕ストリームを切り替えるナビゲーションコマンドを設定することもできる。
ここで、ボタンの実行コマンド領域にはプレイリストの再生を開始させるナビゲーションコマンドは指定できない規定となっており、前述のＯｂｊｅｃｔにおけるＰｒｏｇｒａｍ領域でのみ指定できる。
従って、ボタン４押下時にプレイリストＸＸＸ．ＰＬを再生させたい場合、まず当該ボタンからプレイリストＸＸＸ．ＰＬを再生させるナビゲーションコマンドが記述されたＯｂｊｅｃｔ（図中のＯｂｊｅｃｔ＃Ｎ）へ遷移し、そのＯｂｊｅｃｔから所望のプレイリスト（図中ではＸＸＸ．ＰＬ）を再生するナビゲーションコマンドを実行してもらう必要がある。
以上説明したように、ページ及びボタンで再生メニューを作成する場合、ページ及びボタン以外にも、ボタンから遷移されボタンでは実行出来ないナビゲーションコマンドを実行してもらうためのＯｂｊｅｃｔが必要となる。図４０と図４１とを用いてＴｉｔｌｅとＯｂｊｅｃｔとの関係を説明したが、Ｏｂｊｅｃｔには前述のようにＴｉｔｌｅから参照されるＯｂｊｅｃｔだけではなく、ボタンから参照されるＯｂｊｅｃｔが存在しうる。
以上説明したように、ページとボタンとの組み合わせにより容易にインタラクティブなユーザインターフェースを実現可能である。
なお、再生メニューなどのインタラクティブなユーザインターフェースにおけるＧＵＩ描画にＢＤ−ＲＯＭのスライドショウ機能を活用することもできる。
まず、図４６を用いてＶ＿ＰＥＳにおけるスライドショウ機能について説明する。まず当該Ｖ＿ＰＥＳがスライドショウであるか否かは、例えば当該Ｖ＿ＰＥＳが含まれたＡＶデータのＶＯＢ管理情報ファイルＶＯＢＩにおいて設定されるものとする。
上記スライドショウである旨を設定されたＶ＿ＰＥＳは、例えば全てＩフレーム（Ｉピクチャ）のみで構成されており、一枚のスライドショウとして表示される画面の静止画像がそれぞれＩフレームとしてＶ＿ＰＥＳに埋め込まれる。同時に、各Ｉフレームの先頭毎にプレイリストにおいてチャプターイベントが設定される。
また、各Ｉフレームの表示時間は無限大または固定時間が設定されており、設定された時間が経過するか、チャプタースキップまたはバックが実行されることで前の静止画に進んだり、前の静止画に戻ったりする。このようにＩフレームとチャプターによりスライドショウ機能が実現される。
ここで、図４４を用いて前述したようにディスプレイセット（ＮＶ＿ＤＳ）においてボタンの描画内容を記述可能であるが、描画情報を設定しないボタンも実現可能である。また、ボタンの実行コマンド領域を駆使して、チャプタースキップ、チャプターバックに相当するボタンも実現可能である。
従って、ページとボタンとスライドショウ機能とを併用し、メニューのＧＵＩ描画をＩフレームイメージとしてスライドショウに設定し、ユーザ操作によるメニュー遷移やナビゲーションコマンド実行などのメニュー制御をページ及びボタンに行わせることもできる。
例えば図４７を用いて説明すると、まず図４７（Ａ）に示すようなメニューを構成する各メニュー画面イメージをＩフレームイメージとしてＶ＿ＰＥＳに埋め込んでスライドショウを構成する。
次に図４７（Ｂ）に示すようなメニュー画面の遷移や押下時の動作をページとボタン、そしてボタンから遷移されるＯｂｊｅｃｔにより実現する。具体的にはサムネイルＦの選択時にリモコンの右ボタンが押された場合など、メニュー画面を切り換える場合に対応するためには、チャプター変更に相当するナビゲーションコマンドをボタンに設定すればよい。
また、サムネイルＡ押下時にサムネイルＡに対応する動画を再生する場合には、ボタン押下時にサムネイルＡに対応する動画を再生するためのＯｂｊｅｃｔに遷移するようボタンを設定すればよい。
以上説明したようにメニューはスライドショウとページ及びボタンを併用することでも実現可能であり、このようなメニューは図４２を用いて前述したように１つのＭＰＥＧ−ＴＳに多重化される。
再生メニューをＢＤ−ＲＯＭ形式で記録されたディスクに設定する方法について述べる。前述のようにＢＤ．ＩＮＦＯにおけるＴｏｐＭｅｎｕはメニュー専用のＴｉｔｌｅであるため前述のメニューを実現するＭＰＥＧ−ＴＳはＴｏｐＭｅｎｕタイトルが選択された際に自動実行される必要がある。
従って、ＴｏｐＭｅｎｕから参照するＯｂｊｅｃｔを作成してＢＤ．ＰＲＯＧに登録し、当該ＯｂｊｅｃｔのＰｒｏｇｒａｍ領域には、前記メニューを実現するＭＰＥＧ−ＴＳを再生するプレイリストを再生させるナビゲーションコマンドを設定すればよい。
また、ディスク挿入時に自動的に再生メニューが表示されるようにするには、ＦｉｒｓｔＰｌａｙｂａｃｋから参照するＯｂｊｅｃｔを作成してＢＤ．ＰＲＯＧに登録し、当該ＯｂｊｅｃｔのＰｒｏｇｒａｍ領域には、ＴｏｐＭｅｎｕにタイトル遷移するナビゲーションコマンドを設定すればよい。
ここで、他機器で既に映像を記録されたディスクに対し、自機器で新規に映像を追記したとする。この場合ＴｏｐＭｅｎｕから実行される再生メニューに、当然追記した映像のサムネイル並びに当該映像を再生させるナビゲーション情報を反映させる必要がある。
しかしながら、再生メニューの構成は各社各様であり、ＴｏｐＭｅｎｕから参照されるＯｂｊｅｃｔのＰｒｏｇｒａｍ領域がどのようになっているか容易には判別出来ない。
従って、一端再生メニューを削除し自機器で再生成することになる。しかし、この場合、実施の形態２で説明したように、再生メニューを削除するにあたって、ＢＤ．ＩＮＦＯで規定されているＦｉｒｓｔＰｌａｙＢａｃｋおよびＴｏｐＭｅｎｕから参照されるＯｂｊｅｃｔがどれであるかは解るが、そこから再生されるＰｌａｙＬｉｓｔ（図４７で説明した再生メニューを構成するＭＰＥＧ−ＴＳを再生するＰｌａｙＬｉｓｔ）がどれかを判別するにはＯｂｊｅｃｔのＰｒｏｇｒａｍ領域を逐次解析していく必要がある。
また、前述のように再生メニューのボタンからＰｌａｙＬｉｓｔを再生するにはボタンからＰｌａｙＬｉｓｔ再生用のＯｂｊｅｃｔに遷移し、そのＯｂｊｅｃｔからＰｌａｙＬｉｓｔを再生する必要がある。
このようなボタンのみから参照されるＯｂｊｅｃｔを識別するには、再生メニューを構成するＭＰＥＧ−ＴＳの多重化をほどき、ボタンのＮＶ＿ＤＳを逐次解析していき、ボタンから遷移しているＯｂｊｅｃｔのＩＤを逐次解析していく必要があり大変な手間となる。
従って本実施の形態では、ＦｉｒｓｔＰｌａｙｂａｃｋやＴｏｐＭｅｎｕなどＮＶ＿ＤＳを含むストリームを再生するＴｉｔｌｅにおいて、ＮＶ＿ＤＳから遷移するＯｂｊｅｃｔのＩＤをメタデータとして記録するものとする。
また、当該メタデータは、図４０におけるＢＤ．ＩＮＦＯのＥｘｔｅｎｓｉｏｎＤａｔａに格納するものとする。
本実施の形態におけるメタデータの例を図４８に示す。
図４８に示すようにＢＤ．ＩＮＦＯのＥｘｔｅｎｓｉｏｎＤａｔａ領域には、ＦｉｒｓｔＰｌａｙｂａｃｋのメタデータを格納するＦｉｒｓｔＰｌａｙｂａｃｋＭｅｔａ（）領域と、ＴｏｐＭｅｎｕのメタデータを格納するＴｏｐＭｅｎｕＭｅｔａ（）領域とが存在する。さらに、Ｔｉｔｌｅ毎に各Ｔｉｔｌｅの属性を示すＴｉｔｌｅ Ｄｏｍａｉｎ領域と各Ｔｉｔｌｅのメタデータを格納するＴｉｔｌｅＭｅｔａ（）領域とが存在する。
Ｔｉｔｌｅ Ｄｏｍａｉｎは、Ｍｅｎｕ、Ｒｅａｌ、Ｖｉｒｔａｕｌ、ＳｌｉｄｅＳｈｏｗの四つの属性（Ｄｏｍａｉｎ）のいずれかを示す情報である。
Ｍｅｎｕ Ｄｏｍａｉｎは、ＦｉｒｓｔＰｌａｙＢａｃｋとＴｏｐＭｅｎｕから遷移されたＴｉｔｌｅなど、ＦｉｒｓｔＰｌａｙｂａｃｋとＴｏｐＭｅｎｕ以外に、映像をユーザに選択させて再生する再生メニューやディスク挿入時の自動再生シーケンス制御などを実現するＴｉｔｌｅが有する属性である。
Ｒｅａｌ Ｄｏｍａｉｎは、実際に撮影または録画した映像をシーケンシャルに再生するだけのＴｉｔｌｅが有する属性である。
Ｖｉｒｔｕａｌ Ｄｏｍａｉｎは、撮影または録画した映像をユーザが編集した結果作成したプレイリストを再生するだけのＴｉｔｌｅが有する属性である。
Ｓｌｉｄｅｓｈｏｗ Ｄｏｍａｉｎはスライドショウを再生するＴｉｔｌｅが有する属性である。
ＦｉｒｓｔＰｌａｙｂａｃｋＭｅｔａ（）とＴｏｐＭｅｎｕＭｅｔａ（）とＴｉｔｌｅＭｅｔａ（）の構造は同一である。具体的には、ＦｉｒｓｔＰｌａｙｂａｃｋとＴｏｐＭｅｎｕと各Ｔｉｔｌｅが参照するＰｌａｙＬｉｓｔのファイル名一覧であるＰＬＮａｍｅＬｉｓｔ領域と参照するＯｂｊｅｃｔのＩＤの一覧であるＯｂｊｅｃｔＩＤＬｉｓｔ領域からなる。
なお、各ＴｉｔｌｅＭｅｔａ（）において、ＰｌａｙＬｉｓｔの記録順情報を持たせるため、ＰＬＮａｍｅＬｉｓｔ領域に記録されるＰｌａｙＬｉｓｔのファイル名は当該ＰｌａｙＬｉｓｔの作成順であってもよい。
以上、本実施の形態におけるメタデータの例を説明したが、本実施の形態のメタデータにより、各Ｔｉｔｌｅが参照するＯｂｊｅｃｔやＯｂｊｅｃｔから再生されるストリームを解析することなく、各Ｔｉｔｌｅで使用されるデータ（ＰｌａｙＬｉｓｔ及びＰｌａｙＬｉｓｔから参照されるデジタルストリームと、プログラム群であるＯｂｊｅｃｔ）を識別することができる。
特にＦｉｒｓｔＰｌａｙｂａｃｋＭｅｔａ（）とＴｏｐＭｅｎｕＭｅｔａ（）と前記Ｔｉｔｌｅ ＤｏｍａｉｎがＭｅｎｕであるＴｉｔｌｅのＴｉｔｌｅＭｅｔａ（）を解析することにより、当該ディスクにおける再生メニューを構成するデータ（ＰｌａｙＬｉｓｔ及びＰｌａｙＬｉｓｔから参照されるデジタルストリームと、プログラム群であるＯｂｊｅｃｔ）を識別可能である。
そのため、他機器が作成した再生メニューであっても容易に削除可能となる。特に再生メニューを実現するストリームにボタン（ＮＶ＿ＤＳ）が含まれそのボタンからＯｂｊｅｃｔが参照されている場合でも容易に識別可能であり、削除も容易となる。
なお、例えばＴｏｐＭｅｎｕから参照するＯｂｊｅｃｔやＰｌａｙＬｉｓｔが、任意のＴｉｔｌｅ＃Ａでも参照されている場合、本メタデータに基づいてＴｏｐＭｅｎｕから参照されるＯｂｊｅｃｔやＰｌａｙＬｉｓｔを削除、編集するとＴｉｔｌｅ＃Ａの動作に支障が出る可能性がある。
この場合、規格として、Ｔｉｔｌｅ作成と同時に作成され当該Ｔｉｔｌｅが参照しているＯｂｊｅｃｔやＰｌａｙＬｉｓｔに関しては、後から作成されたＴｉｔｌｅが参照することを禁止してもよい。
また、ＯｂｊｅｃｔやＰｌａｙＬｉｓｔを削除・編集する際、図４８を用いて説明したメタデータを元に、当該ＯｂｊｅｃｔやＰｌａｙＬｉｓｔが他のＴｉｔｌｅからも参照されていないか事前に検索し、参照されていなければ削除するという対策を取ってもよい。
また、ＰＬＮａｍｅＬｉｓｔ領域およびＯｂｊｅｃｔＩＤＬｉｓｔ領域に、当該ＰｌａｙＬｉｓｔまたはＯｂｊｅｃｔを参照しているＴｉｔｌｅの逆参照情報を持たせるなどの対策を取ってもよい。
以上、本発明の実施の形態３について説明したが、本実施の形態の記録方法およびデータ構造は、各Ｔｉｔｌｅ配下のＰｌａｙＬｉｓｔ並びにＯｂｊｅｃｔメタデータを記録した情報記録媒体と、それを記録する記録装置、記録方法、記録プログラム、並びに本実施の形態の記録方法を実現する半導体に適用される。
（実施の形態４）
従来、ビデオカメラで撮影した映像などを逐次ディスクに記録する場合において、映像を次世代光ディスクの商用映像データ用のフォーマットであるＢＤ−ＲＯＭ形式で映像を記録した場合、映像の記録順序を保持する方法が存在しなかった。
そこで、実施の形態４として、ＢＤ−ＲＯＭの拡張領域に記録するメタデータを記録順に配置し、かつ、編集による順序入れ替えを禁止する記録方法について説明する。
この記録方法により、ビデオカメラで撮影した映像をＢＤ−ＲＯＭ形式で記録した場合においても、撮影した映像の撮影順を保持することが可能であり、再生メニュー等においてユーザの期待する順序で撮影した映像のサムネイルを並べることが出来る。
なお、本実施の形態において、撮影した映像を記録するＡＶストリームは、実施の形態３と同じく、ＭＰＥＧ−ＴＳ形式のストリーム（図４２参照）である。
また、本実施の形態では、ビデオカメラや据置ビデオレコーダーなどに於いて、撮影または録画する映像をＢＤ−ＲＯＭ形式により記録する方法について述べる。
まず撮影の単位とＢＤ管理情報との対応関係について述べる。
撮影した映像並びに音声はそれぞれＶ＿ＰＥＳならびにＡ＿ＰＥＳとして前述の図４２に示すようにＭＰＥＧ−ＴＳ形式のストリームに記録されていく。ここで撮影開始ボタンを押してからボタンを放す、または撮影停止ボタンを押すまでの撮影単位をＳｈｏｔと呼ぶこととすると、１つのｓｈｏｔは、一本のストリームとして記録してもよいし、一本のストリームに複数のＳｈｏｔを格納してもよい。
ここでＳｈｏｔは各Ｓｈｏｔ毎または撮影日などのグループ単位毎に前述したプレイリスト（ＰｌａｙＬｉｓｔ）に関連づけられる。そして最終的には各ＰｌａｙＬｉｓｔ単体またはＰｌａｙＬｉｓｔ単位で、前述のＢＤ管理情報であるＢＤ．ＩＮＦＯで管理されるＴｉｔｌｅに関連づけられる。
図１６においてプレイリスト“ＸＸＸ．ＰＬ”の詳細について述べたが、本実施の形態で述べるビデオカメラなどで撮影したストリームにおいては、必ず撮影の単位であるＳｈｏｔ毎にプレイリストで管理するＥＶＥＮＴ（Ｍａｒｋ）を付けるものとする。
以前述べたように、撮影の単位であるＳｈｏｔは、プレイリストのＭａｒｋに一対一対応することとなる。従って、Ｓｈｏｔの撮影日時やＳｈｏｔのサムネイル等のＳｈｏｔに関連するデータの管理もＭａｒｋ単位で行うことにより、Ｓｈｏｔと、Ｓｈｏｔと関連するデータとの対応関係が明確になり、参照や管理が容易になる。
以上、撮影の単位であるＳｈｏｔとＢＤ管理情報におけるＭａｒｋとの対応関係について述べたが、そもそもＢＤ−ＲＯＭ形式は予め編集された映画などを記録し配布する用途に用いるものである。
そのため、例えば前述のＳｈｏｔの撮影日時やそのサムネイル等、撮影した映像を記録する場合にＢＤ管理情報では記録できない情報がいくつか存在する。
従って本実施の形態では、これらＢＤ管理情報では記録出来ない情報を、メタデータとして別途管理するものとする。
メタデータ格納場所としては、ＢＤ管理情報とは別のファイルに格納するものとしてもよいし、ＢＤ管理情報の各拡張領域に格納するものとしてもよい。
ＢＤ管理情報の拡張領域とは、実施の形態２で説明した“Ｅｘｔｅｎｓｉｏｎ”に相当する領域のことである。
例えば、図１８においてＢＤ−ＲＯＭ形式で記録されたディスクが挿入された際にＢＤ−Ｐｌａｙｅｒが最初に読み出すＢＤ管理情報であるＢＤ．ＩＮＦＯの詳細について述べたが、図１８を用いて説明した構造に加えてデータの末尾に拡張領域としてＩｎｄｅｘＥｘｔｅｎｓｉｏｎＤａｔａ（）を持つ。
従って、本実施の形態では、前記ＢＤ−ＲＯＭで規定出来ない情報をこのＩｎｄｅｘＥｘｔｅｎｓｉｏｎＤａｔａ（）にて規定するものとする。なお、説明するまでもないが、ＰｌａｙＬｉｓｔやＶＯＢ管理情報ファイル（ＣｌｉｐＩｎｆｏｒｍａｔｉｏｎ）の拡張領域に分散してメタデータを格納してもよい。
本実施の形態で規定するＩｎｄｅｘＥｘｔｅｎｓｉｏｎＤａｔａ（）の例を図４９に示す。
図４９は本実施の形態にて規定するメタデータをＢＤ．ＩＮＦＯの拡張領域であるＩｎｄｅｘＥｘｔｅｎｓｉｏｎＤａｔａ（）に格納した場合の例を示す図である。
なお、本実施の形態はこれに限定するものではなく、例えば、ＢＤ．ＩＮＦＯとは別のファイルに図４９に示す構造ならびにデータを持ったメタデータを記録して持たせてもよいし、図４９に示すメタデータを、ＢＤ管理情報の各ファイルに分散させて持たせてもよい。
まず、前述したＢＤ管理情報“ＢＤ．ＩＮＦＯ”の末尾にあるＩｎｄｅｘＥｘｔｅｎｓｉｏｎＤａｔａ（）に、“ＤｉｓｃＩｎｆｏ”領域と“ＰＬＴａｂｌｅ”領域の二つの領域を持たせる。
“ＤｉｓｃＩｎｆｏ”領域はディスク全体に関するメタデータを格納するための領域であり、例として“Ｄｉｓｃタイトル”にはディスクのタイトル情報を格納し、“Ｄｉｓｃサムネイル”には、ディスクを代表するサムネイル画像に関する情報を格納する。
“ＰＬＴａｂｌｅ”領域はＢＤ管理情報の１つであるＰｌａｙＬｉｓｔに関するメタデータをＰｌａｙＬｉｓｔ毎に格納する領域であり、“ＰＬ＿Ｎｕｍｂｅｒ”領域と各ＰｌａｙＬｉｓｔのメタデータ領域（図中の“ＰＬ＃１”〜“ＰＬ＃ｍ”）とからなる。
“ＰＬ＿Ｎｕｍｂｅｒ”とプレイリスト“ＸＸＸ．ＰＬ”のファイル総数とは同数となり、以降各ＰｌａｙＬｉｓｔ（プレイリスト“ＸＸＸ．ＰＬ”）毎のメタデータが“ＰＬ＃１”から順に格納される。
各ＰｌａｙＬｉｓｔのメタデータは、例として“ＰＬ＿ＦｉｌｅＮａｍｅ”領域と“ＰＬ＿Ｔｙｐｅ”領域、“ＰＬ作成日時”領域、“ＰＬタイトル”領域、“ＭａｒｋＴａｂｌｅ”領域の５つの領域からなる。
“ＰＬ＿ＦｉｌｅＮａｍｅ”領域は、当該メタデータ領域（“ＰＬ＃１”〜“ＰＬ＃ｍ”）がどのＰｌａｙＬｉｓｔのメタデータを格納しているかを示す情報であり、例えばＰｌａｙＬｉｓｔファイル“ＸＸＸ．ＰＬ”のファイルボディ“ＸＸＸ”が格納される。
また、“ＰＬ＿Ｔｙｐｅ”領域には、当該ＰｌａｙＬｉｓｔの種別が格納される。ＢＤ−ＲＯＭにおいては映像は全て予めオーサリングされているためＰｌａｙＬｉｓｔに種別を設ける必要がないが、撮影または録画する映像をＢＤ−ＲＯＭ形式で記録する場合は大きく二つに大別される。
まず１つ目は撮影または録画したオリジナルの映像を一から再生するシナリオが記録されるＰｌａｙＬｉｓｔであり、以降本実施の形態ではＲｅａｌ ＰｌａｙＬｉｓｔと呼ぶ。
もう一つは、ユーザがオリジナルの映像に対して再生順序の入れ替えや再生箇所の指定などの編集を行ったシナリオが記録されるＰｌａｙＬｉｓｔであり、以降本実施の形態ではＶｉｒｔｕａｌ ＰｌａｙＬｉｓｔと呼ぶ。
ここで、撮影または録画した映像の単位であるＳｈｏｔとＲｅａｌ ＰｌａｙＬｉｓｔ、Ｖｉｒｔｕａｌ ＰｌａｙＬｉｓｔとの対応関係を図５０に示す。
図５０に示すように、Ｒｅａｌ ＰｌａｙＬｉｓｔは撮影したＳｈｏｔが格納されたストリームを撮影順に再生するものであり、基本的にストリームが記録される際にストリーム情報と共に生成される。
また、Ｒｅａｌ ＰｌａｙＬｉｓｔは、例えばＳｈｏｔの撮影後に追加または修正されていく。
一方、Ｖｉｒｔｕａｌ ＰｌａｙＬｉｓｔはユーザによる映像編集の結果として記録した映像の一部を所望の順序で再生するためのものであり、ユーザの編集処理時に作成される。
このように撮影または録画したストリームは複数のＰｌａｙＬｉｓｔから参照される可能性がある。このためあるＰｌａｙＬｉｓｔを削除する際に当該ＰｌａｙＬｉｓｔが参照するストリームも同時に削除すると、存在しないストリームを参照するＰｌａｙＬｉｓｔが出来てしまう可能性がある。
従って、あるストリームは、必ず１つのＲｅａｌ ＰｌａｙＬｉｓｔからは参照されるため、Ｖｉｒｔｕａｌ ＰｌａｙＬｉｓｔ削除時は参照するストリーム及びストリーム情報は削除せず、Ｒｅａｌ ＰｌａｙＬｉｓｔ削除時は参照するストリーム及びストリーム情報を削除し、当該ストリームを参照するＶｉｒｔｕａｌ ＰｌａｙＬｉｓｔを修正するものとしてもよい。
以上、Ｒｅａｌ ＰｌａｙＬｉｓｔとＶｉｒｔｕａｌ ＰｌａｙＬｉｓｔについて説明したが、これらの識別情報を前記“ＰＬ＿Ｔｙｐｅ”に格納するものとする。
なお、メニュー用ストリームがどのストリームであるかを容易に判別するため、メニュー用ストリームを参照するＰｌａｙＬｉｓｔであることを前記“ＰＬ＿Ｔｙｐｅ”に持たせてもよいし、後述するＭａｒｋ用のメタデータやストリーム情報のメタデータに持たせてもよい。
また、図３４の説明の中で述べたプログラムが多重化されたストリーム（Ｉｎｔｅｒａｃｔｉｖｅ Ｇｒａｐｈｉｃｓ（ＩＧ） Ｓｔｒｅａｍ）を参照するＰｌａｙＬｉｓｔであることを前記“ＰＬ＿Ｔｙｐｅ”に持たせてもよいし、後述するＭａｒｋ用のメタデータやストリーム情報のメタデータに持たせてもよい。
例えば、スライドショウを実現するＰｌａｙＬｉｓｔである場合、当該ストリームは、ページ送りやページ戻り用のボタン及びボタンコマンド（ＩＧ Ｓｔｒｅａｍ）をストリーム中に含む場合もあり得る。
この場合例えば、ある機器でスライドショウを作成した後、別の機器で当該スライドショウを変更する場合に、単純に編集してもよいのか、それともＩＧ Ｓｔｒｅａｍを含んでおりそれを考慮した上で編集する必要があるのかを判断することが出来る。
例えばＩＧ Ｓｔｒｅａｍを含んだＲｅａｌ ＰｌａｙＬｉｓｔであることが前記ＰＬ＿Ｔｙｐｅに指定された識別子で判明した場合、当該機器はまずＩＧ Ｓｔｒｅａｍを検出していき、検出したＩＧ Ｓｔｒｅａｍを全て削除した上で、スライドショウを編集することが可能となる。
なお、図示していないが、あるディスクがどの機器で記録されたディスクであるのかどうかという情報を、例えば本実施の形態のメタデータにおける“ＤｉｓｃＩｎｆｏ”に持たせてもよい。
これにより、記録装置は前記ＩＧ Ｓｔｒｅａｍを含むストリームは当該機器で作成されたものかどうかを判別することが可能である。
例えば、前記ＰＬ＿ＴｙｐｅによりＩＧ Ｓｔｒｅａｍを含むＰｌａｙＬｉｓｔであることが判別された場合、当該機器で作成したものである場合は直接修正してもよい。
以下、図４９の説明を続行する。
“ＰＬ作成日時”領域には当該ＰｌａｙＬｉｓｔを作成した日時を記録する。
“ＰＬタイトル”領域にはＰｌａｙＬｉｓｔのタイトル名を記録する。
“ＭａｒｋＴａｂｌｅ”領域は当該ＰｌａｙＬｉｓｔメタデータが参照するＰｌａｙＬｉｓｔが管理する各Ｍａｒｋのメタデータを格納する領域であり、“Ｍａｒｋ＿Ｎｕｍｂｅｒ”領域と各Ｍａｒｋのメタデータ領域（図中の“Ｍａｒｋ＃１”〜“Ｍａｒｋ＃ｎ”）からなる。
図４９に示す例では“Ｍａｒｋ＿Ｎｕｍｂｅｒ”と当該ＰｌａｙＬｉｓｔが管理するＭａｒｋの数とが同数となり、以降当該ＰｌａｙＬｉｓｔが管理する順番に従って、Ｍａｒｋ毎のメタデータが“Ｍａｒｋ＃１”から順に格納される。
なお、本実施の形態ではＰｌａｙＬｉｓｔが管理するＭａｒｋとメタデータで管理するＭａｒｋとか一対一対応するものとして記述するが、これに限るものではない。
例えば、再生を一時停止した地点を示すＭａｒｋなどＢＤ管理情報では規定出来ないＭａｒｋをメタデータでのみ管理してもよい。
この場合、例えば図４９に示すＭａｒｋのメタデータ領域にＢＤ管理情報で規定するＭａｒｋを参照しているのか否かを示す情報と、参照している場合はそのＭａｒｋのＩＤを、参照していない場合はメタデータで管理するＭａｒｋが指すストリームの位置情報を格納する領域を別途設ける必要がある。
各Ｍａｒｋのメタデータは、例として“Ｍａｒｋ＿Ｔｙｐｅ”領域、“サムネイル”領域、“撮影日時”領域、および“ＰＬ参照情報”領域の４つの領域からなる。
“Ｍａｒｋ＿Ｔｙｐｅ”領域は当該ＰｌａｙＬｉｓｔで管理するＭａｒｋの種別を記録するものであり、本実施の形態では当該ＭａｒｋがＳｈｏｔの先頭を示すＭａｒｋ（Ｓｈｏｔ−Ｍａｒｋ）であるか否かを示す。
この場合、Ｍａｒｋの機能の性質上、Ｓｈｏｔの先頭を示すＭａｒｋを管理するのは前述のＲｅａｌ ＰｌａｙＬｉｓｔのみとなる。
また、本実施の形態では当該ＰｌａｙＬｉｓｔを代表するサムネイルにあたるストリーム位置をＭａｒｋとして管理するものとする。
具体的には、“Ｍａｒｋ＿Ｔｙｐｅ”領域にて、当該ＭａｒｋがＰｌａｙＬｉｓｔの代表サムネイルを示すＭａｒｋ（ＰＬ−Ｍａｒｋ）なのか否かを識別する情報も持たせるものとする。その他、ユーザが付加するＢｏｏｋＭａｒｋであるか否かなどを規定してもよい。
次に“サムネイル”領域は当該Ｍａｒｋの指すストリーム位置における画像をサムネイルとして指定する。
なお、当該ＭａｒｋがＳｈｏｔの先頭を示すＭａｒｋである場合、基本はＳｈｏｔの先頭の画像がサムネイルとして設定される。しかしＳｈｏｔを代表するサムネイルを参照させるために、当該Ｍａｒｋが指すストリーム位置の画像ではなく、ユーザの設定や自動判別などにより抽出した、当該Ｍａｒｋが指すストリーム位置とは別の位置の画像を代表サムネイルとしてもよい。
“撮影日時”領域は、当該ＭａｒｋがＳｈｏｔの先頭を示すＭａｒｋである場合、当該Ｓｈｏｔの撮影日時を記録する。
“ＰＬ参照情報”領域は、当該ＭａｒｋがＳｈｏｔの先頭を示すＭａｒｋである場合のみ設定されるものとし、当該Ｓｈｏｔを参照するＰｌａｙＬｉｓｔの参照情報を格納するものとする。
このＰＬ参照情報は、前述したように当該ＳｈｏｔまたはＳｈｏｔを含むストリームが削除された際に、当該Ｓｈｏｔを参照しており削除時に修正の必要があるＰｌａｙＬｉｓｔを容易に検索するために付加するものである。
なお、前述のようにＳｈｏｔと当該Ｓｈｏｔを管理するＲｅａｌ ＰｌａｙＬｉｓｔとは、一方が削除された際に自動的にもう一方も削除される関係にある。従って、“ＰＬ参照情報”領域に格納する参照情報はＶｉｒｔｕａｌ ＰｌａｙＬｉｓｔに対する参照情報のみ格納するものとしてもよい。
なお、Ｒｅａｌ ＰｌａｙＬｉｓｔの編集/削除時に更新されるべきＶｉｒｔｕａｌ ＰｌａｙＬｉｓｔを効率良く特定するために、Ｒｅａｌ ＰｌａｙＬｉｓｔとＶｉｒｔｕａｌ ＰｌａｙＬｉｓｔのプレイリストファイル番号を予め別個に定義しておくことも考えられる。こうすることで、Ｒｅａｌ ＰｌａｙＬｉｓｔ編集時に内容を確認するべきプレイリストファイルを瞬時に特定することができる。この場合、ＢＤ．ＩＮＦＯのＥｘｔｅｎｓｉｏｎのような特別な情報は必要がない。
以上、本実施の形態におけるメタデータの種類とその格納方法について説明したが、Ｓｈｏｔを一覧メニューとして表示する際、撮影・録画順にそのサムネイルを表示することで、Ｓｈｏｔの相関関係が掴みやすくユーザの利便性を向上することができる。
本実施の形態ではこのような撮影・録画順のソートならびにメニュー表示を容易とするため、図４９で示したメタデータにおいて、ＰｌａｙＬｉｓｔのメタデータ（図中“ＰＬ＃１”〜“ＰＬ＃ｍ”）を格納する順番を記録順に格納するものとする。
基本的にはＰｌａｙＬｉｓｔのメタデータの格納位置は編集等でも変更しないものとする。また図５１に示すように、Ｒｅａｌ ＰｌａｙＬｉｓｔにおいて、Ｓｈｏｔの先頭を示すＭａｒｋは、ＰｌａｙＬｉｓｔにおけるＭａｒｋの付加順ならびに当該Ｍａｒｋのメタデータの記録順も撮影順に並ぶものとし、当該順序は削除を除き編集等で入れ替えないものとする。
以上により、Ｒｅａｌ ＰｌａｙＬｉｓｔのメタデータの格納順と、当該Ｒｅａｌ ＰｌａｙＬｉｓｔが管理するＭａｒｋにおいてＳｈｏｔの先頭を示すＭａｒｋのメタデータの格納順とにより、当該ディスクに記録されたＳｈｏｔの撮影・録画順序を識別することが可能となる。
以上により、Ｓｈｏｔの撮影順にサムネイルや撮影日時等を一覧表示した再生メニューを生成する場合は、図４９に示すメタデータを参照するだけでよい。
また、“ＰＬ＿Ｔｙｐｅ”がＲｅａｌ ＰｌａｙＬｉｓｔであるＰｌａｙＬｉｓｔのメタデータを順次解析し、当該ＰｌａｙＬｉｓｔのメタデータにおいて、Ｍａｒｋ＿Ｔｙｐｅ＝Ｓｈｏｔ−Ｍａｒｋ（当該ＭａｒｋがＳｈｏｔの先頭を示す）であるＭａｒｋのメタデータを順次参照しメニュー表示すればよい。
例えば本実施の形態のメタデータが図５２（Ａ）に簡易的に示す状態である場合を想定する。この場合、ＰｌａｙＬｉｓｔ＃１、＃２、＃４はＲｅａｌ ＰｌａｙＬｉｓｔであり、ＰｌａｙＬｉｓｔ＃３はＶｉｒｔｕａｌ ＰｌａｙＬｉｓｔである。
従って、ＰｌａｙＬｉｓｔの記録順は、ＰｌａｙＬｉｓｔ＃１、＃２、＃４の順になる。
また、図中において、“（Ｓｈｏｔ）”が付されたＭａｒｋは、Ｓｈｏｔの先頭を示すＭａｒｋを表している。
従って、各ＰｌａｙＬｉｓｔの中でＳｈｏｔの先頭を示すＭａｒｋの記録順を抽出すると、Ｓｈｏｔの記録順がＰｌａｙＬｉｓｔ＃１のＭａｒｋ＃１，＃３、ＰｌａｙＬｉｓｔ＃２のＭａｒｋ＃１、ＰｌａｙＬｉｓｔ＃４のＭａｒｋ＃１，＃２の順であることが分かる。
このようにして、最終的にＳｈｏｔの一覧メニューを図５２（Ｂ）のように表示することが出来る。
なお、Ｒｅａｌ ＰｌａｙＬｉｓｔ及びＶｉｒｔｕａｌ ＰｌａｙＬｉｓｔの作成順も前記メタデータの格納順序により識別することも可能である。
また、各ＰｌａｙＬｉｓｔが管理するＭａｒｋにおいて、Ｍａｒｋ＿ＴｙｐｅがＰｌａｙＬｉｓｔの代表サムネイルを示すＭａｒｋ（ＰＬ−Ｍａｒｋ）を検索することで、必要があればＰｌａｙＬｉｓｔのサムネイルを作成順に一覧表示したメニューも作成可能である。
以上、実施の形態４について説明したが、実施の形態４の記録方法およびデータ構造は、撮影または録画した映像をＢＤ−ＲＯＭ形式で記録する場合に、映像の記録順序を保持するようにメタデータを記録した情報記録媒体と、それを記録する記録装置、記録方法、記録プログラム、並びに実施の形態４の記録方法を実現する半導体に適用される。
（実施の形態５）
従来、ビデオカメラで撮影した映像などを逐次ディスクに記録する場合において、映像を次世代光ディスクの商用映像データ用のフォーマットであるＢＤ−ＲＯＭ形式で映像を記録した場合、映像の撮影日時を保持する方法が存在しなかった。
そこで、実施の形態５として、撮影した映像毎の撮影日時情報をＢＤ−ＲＯＭの拡張領域にメタデータとして記録する記録方法について説明する。
この記録方法により、ビデオカメラで撮影した映像をＢＤ−ＲＯＭ形式で記録した場合においても、撮影した映像の撮影日時を保持することが可能であり、ユーザに対して撮影した映像の撮影日時を適切な形で提示することができる。
なお、本実施の形態において、撮影した映像を記録するＡＶストリームは、実施の形態３と同じく、ＭＰＥＧ−ＴＳ形式のストリーム（図４２参照）である。
また、本実施の形態では、ビデオカメラや据置ビデオレコーダーなどに於いて、撮影または録画する映像をＢＤ−ＲＯＭ形式により情報記録媒体に記録する方法について述べる。
なお、本実施の形態では情報記録媒体の例として次世代ディスクであるＢＤ−ＲＯＭ Ｄｉｓｃを例に挙げているが、これに限られることはない。
例えば、本実施の形態におけるアプリケーション及びデータ構造をＤＶＤなどの光ディスクや他の情報記録媒体である、メモリーカード（ＳＤメモリーカードやメモリースティックなど）やハードディスクなどに書き込む場合でも同様の効果を得る。
また、情報記録媒体ではなく、本実施の形態におけるアプリケーション及びデータ構造をネットワークを介して配布する場合においても同様の効果を得る。
撮影の単位とＢＤ管理情報との対応関係は、実施の形態４と同じである。
すなわち、撮影した映像並びに音声はそれぞれＶ＿ＰＥＳならびにＡ＿ＰＥＳとして前述の図４２に示すようにＭＰＥＧ−ＴＳ形式のストリームに記録されていく。
ここで撮影開始ボタンを押してからボタンを放す、または撮影停止ボタンを押すまでなど、ユーザが撮影または録画した映像の単位（撮影単位）をＳｈｏｔと呼ぶこととすると、１つのｓｈｏｔは、一本のストリームとして記録してもよいし、一本のストリームに複数のＳｈｏｔを格納してもよい。
詳しくは後述するが、Ｓｈｏｔは、Ｓｈｏｔ毎または撮影日などのグループ単位毎に前述したプレイリスト（ＰｌａｙＬｉｓｔ）に関連づけて管理されるものとし、各Ｓｈｏｔの先頭には当該プレイリストにて管理するＥｖｅｎｔが設定されるものとする。
本発明の実施の形態１において、図１８を用いてＢＤ管理情報の１つで、ディスク全体の情報を管理する“ＢＤ．ＩＮＦＯ”の例を説明したが、本実施の形態では図５３の形式を取るものとする。
図５３に示すＢＤ．ＩＮＦＯはディスクに１つだけ存在し、当該ディスクが挿入された際に一番初めに解釈される。図５３に示すＢＤ．ＩＮＦＯは、“ＡｐｐＩｎｆｏ”と“ＴｉｔｌｅＬｉｓｔ”、“ＥｘｔｅｎｓｉｏｎＤａｔａ”からなり、“ＡｐｐＩｎｆｏ”にはディスク全体に関する情報が格納される。
“ＴｉｔｌｅＬｉｓｔ”には当該ディスクに格納されるタイトルの情報が格納されており、“ＦｉｒｓｔＰｌａｙｂａｃｋ”と“ＴｏｐＭｅｎｕ”という二つの特別なタイトルと複数の通常のタイトルとからなる。
通常のタイトルの総数は“ＴｉｔｌｅＬｉｓｔ”以下の“Ｎｕｍｂｅｒ”に格納される。“ＦｉｒｓｔＰｌａｙｂａｃｋ”と“ＴｏｐＭｅｎｕ”と各“Ｔｉｔｌｅ”は、それぞれタイトル選択時に実行すべき後述するＯｂｊｅｃｔへのリンク情報（ＯｂｊｅｃｔのＩＤ）を持っている。
ＦｉｒｓｔＰｌａｙｂａｃｋは、ディスク挿入時に一番最初に選択されるタイトルであり、ＴｏｐＭｅｎｕは、リモコンでメニューボタンが押された場合などに選択される再生メニュー用のタイトルである。
なお、本実施の形態において、Ｏｂｊｅｃｔに関する情報を格納する“ＢＤ．ＰＲＯＧ”のデータ構造は、実施の形態図３で説明した図４１に示すＢＤ．ＰＲＯＧのデータ構造と同じである。
なお、図４１に示す“ＢＤ．ＰＲＯＧ”は実施の形態１において図１８を用いて説明した“ＢＤ．ＰＲＯＧ”に変わるものであり、合わせて図１７を用いて説明した“ＸＸＸ．ＰＲＯＧ”は廃止される。
以上、本実施の形態におけるＢＤ管理情報について述べたが、前記Ｓｈｏｔを管理するプレイリストは、各プレイリスト単位で、前述のＢＤ管理情報であるＢＤ．ＩＮＦＯで管理されるＴｉｔｌｅに関連づけられる。
具体的には、Ｔｉｔｌｅが参照するＯｂｊｅｃｔにおいて、当該Ｔｉｔｌｅに対応するプレイリストを再生するナビゲーションコマンドが記述される。
また、図１６においてプレイリスト“ＸＸＸ．ＰＬ”の詳細を説明したが、プレイリストにて管理するイベントは、以後Ｍａｒｋと呼ぶことにする。Ｍａｒｋは前述の通り、当該プレイリスト内で生成されるイベント（Ｍａｒｋ）を定義したものであり、プレイリストでは複数のＭａｒｋをＩＤで管理している。
また、各ＭａｒｋはＭａｒｋの種別（Ｍａｒｋ＿Ｔｙｐｅ）、ＭａｒｋのＩＤ（Ｍａｒｋ＿ＩＤ）、イベント（Ｍａｒｋ）の生成時刻時刻（Ｔｉｍｅ）と有効期間（Ｄｕｒａｔｉｏｎ）から構成されている。ここでＭａｒｋの種別であるＭａｒｋ＿Ｔｙｐｅには、ＥｎｔｒｙＭａｒｋとＬｉｎｋＰｏｉｎｔの二つの種別がある。
ＥｎｔｒｙＭａｒｋはＣｈａｐｔｅｒとしてユーザが識別可能であるＭａｒｋであり、プレイリストの先頭から何番目のＥｎｔｒｙＭａｒｋであるかをユーザに提示することでＣｈａｐｔｅｒ番号を提示可能である。
またリモコン操作により再生するチャプターを前後のチャプターに切り替えることも可能である。
ＬｉｎｋＰｏｉｎｔは、ユーザは識別できないＭａｒｋであり、前述のようなＣｈａｐｔｅｒとしては識別されず、プログラムからの再生位置指定など主にプログラムにて識別する再生時刻情報として用いられる。
以上Ｍａｒｋについて説明したが、本実施の形態で述べるビデオカメラなどで撮影または録画した映像を管理するプレイリストにおいては、撮影の単位であるＳｈｏｔ毎にそのＳｈｏｔの先頭にあたる再生時刻に対して必ず当該プレイリストにて管理するＥｎｔｒｙＭａｒｋを設定するものとする。
これにより、撮影の単位であるＳｈｏｔはプレイリストのＥｎｔｒｙＭａｒｋに一対一対応することとなる。これによりユーザは撮影したＳｈｏｔをＣｈａｐｔｅｒとして識別可能となり、Ｃｈａｐｔｅｒ切替操作により再生するＳｈｏｔを選択することも可能となる。
また、本実施の形態ではＳｈｏｔの撮影日時やＳｈｏｔのサムネイル等のＳｈｏｔに関連する情報の管理もＥｎｔｒｙＭａｒｋ単位で行うこととする。これにより、Ｓｈｏｔと、Ｓｈｏｔと関連するデータとの対応関係が明確になり、参照や管理が容易になる。
以上、撮影の単位であるＳｈｏｔとＢＤ管理情報におけるＭａｒｋとの対応関係について述べたが、そもそもＢＤ−ＲＯＭ形式は予め編集された映画などを記録し配布する用途に用いるため、例えば前述のＳｈｏｔの撮影日時やそのサムネイル等、撮影した映像を記録する場合にＢＤ管理情報では記録できない情報がいくつか存在する。
従って本実施の形態では、これらＢＤ管理情報では記録出来ない情報を、メタデータとして別途管理するものとする。メタデータ格納場所としては、ＢＤ管理情報とは別のファイルに格納するものとしてもよいし、ＢＤ管理情報の各拡張領域に格納するものとしてもよい。
ＢＤ管理情報の拡張領域とは、実施の形態２で説明した“Ｅｘｔｅｎｓｉｏｎ”に相当する領域のことである。
本実施の形態においては、ＢＤ．ＩＮＦＯは図５３に示すようにデータの末尾に拡張領域としてＩｎｄｅｘＥｘｔｅｎｓｉｏｎＤａｔａ（）を持つ。また、各プレイリスト情報を格納するＸＸＸ．ＰＬの詳細について図１６を用いて説明したが、プレイリストＸＸＸ．ＰＬにおいても図１６を用いて説明した構造に加えて、図５４に示すように、データの末尾に拡張領域としてＰｌａｙＬｉｓｔＥｘｔｅｎｓｉｏｎＤａｔａ（）を持つ。
従って、本実施の形態では、前記ＢＤ−ＲＯＭで規定出来ない情報をこのＩｎｄｅｘＥｘｔｅｎｓｉｏｎＤａｔａ（）やＰｌａｙＬｉｓｔＥｘｔｅｎｓｉｏｎＤａｔａ（）にて規定するものとする。
なお、説明するまでもないが、以後述べるメタデータの格納方法についてはあくまでも例であり、以後述べる情報をメタデータとして格納することが重要であってＶＯＢ管理情報ファイル（ＣｌｉｐＩｎｆｏｒｍａｔｉｏｎ）の拡張領域に格納したり、別の構造を取っても構わない。
本実施の形態で規定するＩｎｄｅｘＥｘｔｅｎｓｉｏｎＤａｔａ（）の例を、図５３を用いて説明する。
まず、前述したＢＤ管理情報“ＢＤ．ＩＮＦＯ”の末尾にあるＩｎｄｅｘＥｘｔｅｎｓｉｏｎＤａｔａ（）に、“ＤｉｓｃＩｎｆｏ”領域と“ＰＬＴａｂｌｅ”領域の二つの領域を持たせる。
“ＤｉｓｃＩｎｆｏ”領域はディスク全体に関するメタデータを格納するための領域である。例として“Ｄｉｓｃタイトル”にはＤｉｓｃのタイトル情報を格納し、“Ｄｉｓｃサムネイル”には、ディスクを代表するサムネイル画像に関する情報を格納する。
“ＰＬＴａｂｌｅ”領域はＢＤ管理情報の１つであるＰｌａｙＬｉｓｔのメタデータを格納する領域であり、“ＰＬ＿Ｎｕｍｂｅｒ”領域と各ＰｌａｙＬｉｓｔのメタデータ領域（図中の“ＰＬ＃１”〜“ＰＬ＃ｍ”）からなる。
“ＰＬ＿Ｎｕｍｂｅｒ”とプレイリスト“ＸＸＸ．ＰＬ”のファイル総数とは同数となり、以降ＰｌａｙＬｉｓｔ（プレイリスト“ＸＸＸ．ＰＬ”）毎のメタデータが“ＰＬ＃１”から順に格納される。
各ＰｌａｙＬｉｓｔのメタデータは、例として“ＰＬ＿ＦｉｌｅＮａｍｅ”領域と“ＰＬ＿Ｔｙｐｅ”領域を持つ。
“ＰＬ＿ＦｉｌｅＮａｍｅ”領域は、当該メタデータ領域（“ＰＬ＃１”〜“ＰＬ＃ｍ”）がどのＰｌａｙＬｉｓｔのメタデータを格納しているかを示す情報である。例えばＰｌａｙＬｉｓｔファイル“ＸＸＸ．ＰＬ”のファイルボディ“ＸＸＸ”が格納される。
また、“ＰＬ＿Ｔｙｐｅ”領域には、当該ＰｌａｙＬｉｓｔの種別が格納される。ＢＤ−ＲＯＭにおいては映像は全て予めオーサリングされているためＰｌａｙＬｉｓｔに種別を設ける必要がないが、撮影または録画する映像をＢＤ−ＲＯＭ形式で記録する場合は大きく二つに大別される。
まず１つ目は撮影または録画したオリジナルの映像を管理し、順次先頭から再生するシナリオが記録されるＰｌａｙＬｉｓｔであり、以降本実施の形態ではＲｅａｌ ＰｌａｙＬｉｓｔと呼ぶ。
もう一つは、ユーザがオリジナルの映像に対して再生順序の入れ替えや再生箇所の指定などの編集を行ったシナリオが記録されるＰｌａｙＬｉｓｔであり、以降本実施の形態ではＶｉｒｔｕａｌ ＰｌａｙＬｉｓｔと呼ぶ。
撮影または録画した映像の単位であるＳｈｏｔとＲｅａｌ ＰｌａｙＬｉｓｔ、Ｖｉｒｔｕａｌ ＰｌａｙＬｉｓｔとの対応関係は、実施の形態４において図５０を用いて説明した当該対応関係と同じである。
すなわち、図５０に示すように、Ｒｅａｌ ＰｌａｙＬｉｓｔは撮影したＳｈｏｔが格納されたストリームを撮影順に再生するものであり、基本的にストリームが記録される際にストリーム情報と共に生成される。例えばＲｅａｌ ＰｌａｙＬｉｓｔはＳｈｏｔの撮影後に追加または修正されていく。
一方、Ｖｉｒｔｕａｌ ＰｌａｙＬｉｓｔはユーザによる映像編集の結果として記録した映像の一部を所望の順序で再生するためのものであり、ユーザの編集処理時に作成される。
このように撮影または録画したストリームは複数のＰｌａｙＬｉｓｔから参照される可能性がある。このためあるＰｌａｙＬｉｓｔを削除する際に当該ＰｌａｙＬｉｓｔが参照するストリームも同時に削除すると存在しないストリームを参照するＰｌａｙＬｉｓｔが出来てしまう可能性がある。
従って、必ず１つのＲｅａｌ ＰｌａｙＬｉｓｔからは参照されるため、Ｖｉｒｔｕａｌ ＰｌａｙＬｉｓｔ削除時は参照するストリーム及びストリーム情報は削除せず、Ｒｅａｌ ＰｌａｙＬｉｓｔ削除時は参照するストリーム及びストリーム情報を削除し、当該ストリームを参照するＶｉｒｔｕａｌ ＰｌａｙＬｉｓｔを修正するものとしてもよい。
以上、Ｒｅａｌ ＰｌａｙＬｉｓｔとＶｉｒｔｕａｌ ＰｌａｙＬｉｓｔについて説明したが、これらの識別情報を前記“ＰＬ＿Ｔｙｐｅ”に格納するものとする。またその他の種別として、当該プレイリストで再生されるストリームがメニュー用ストリームであることを示す種別や、スライドショウであることを示す種別を設けてもよい。
また、図３４の説明の中で述べたプログラムが多重化されたストリーム（Ｉｎｔｅｒａｃｔｉｖｅ Ｇｒａｐｈｉｃｓ（ＩＧ） Ｓｔｒｅａｍ）を参照するＰｌａｙＬｉｓｔであることを前記“ＰＬ＿Ｔｙｐｅ”に合わせて記録してもよい。
例えば、当該プレイリストのＰＬ＿Ｔｙｐｅがスライドショウであった場合、当該ストリームは、ページ送りやページ戻り用のボタン及びボタンコマンド（ＩＧ Ｓｔｒｅａｍ）をストリーム中に含む場合もあり得る。
この場合、例えばある機器でスライドショウを作成した後、別の機器で当該スライドショウを変更する場合に、単純に編集してもよいのか、それともＩＧ Ｓｔｒｅａｍを含んでおりそれを考慮した上で編集する必要があるのかを判断することが出来る。
例えばＩＧ Ｓｔｒｅａｍを含んだスライドショウであることが前記ＰＬ＿Ｔｙｐｅに指定された識別子で判明した場合、当該機器はまずＩＧ Ｓｔｒｅａｍを検出していき、検出したＩＧ Ｓｔｒｅａｍを全て削除した上で、スライドショウを編集することが可能となる。
なお、図示していないがあるディスクがどの機器で記録されたディスクであるのかどうかという情報を、例えば本実施の形態のメタデータにおける“ＤｉｓｃＩｎｆｏ”に持たせてもよい。
これにより、記録装置は前記ＩＧ Ｓｔｒｅａｍを含むスライドショウが当該機器で作成されたものかどうかを判別することが可能である。
例えば、前記ＰＬ＿ＴｙｐｅによりＩＧ Ｓｔｒｅａｍを含むスライドショウであることを判別した場合、当該機器で作成したものである場合は直接修正してもよい。
次に、本実施の形態で規定するＰｌａｙＬｉｓｔＥｘｔｅｎｓｉｏｎＤａｔａ（）の例を図５４に示す。
ＰｌａｙＬｉｓｔＥｘｔｅｎｓｉｏｎＤａｔａ（）は、“ＰＬ作成日時”領域、“ＰＬタイトル”領域、“ＰＬサムネイル”領域、および“ＭａｒｋＴａｂｌｅ”領域の４つの領域からなる。
“ＰＬ作成日時”領域には当該ＰｌａｙＬｉｓｔを作成した日時を記録する。
“ＰＬタイトル”領域にはＰｌａｙＬｉｓｔのタイトル名を記録する。
“ＰＬサムネイル”領域には当該ＰｌａｙＬｉｓｔを代表するサムネイルへの参照情報を記録する。
“ＭａｒｋＴａｂｌｅ”領域は当該ＰｌａｙＬｉｓｔメタデータが参照するＰｌａｙＬｉｓｔが管理する各Ｍａｒｋのメタデータを格納する領域であり、“Ｍａｒｋ＿Ｎｕｍｂｅｒ”領域と各Ｍａｒｋのメタデータ領域（図中の“Ｍａｒｋ＃１”〜“Ｍａｒｋ＃ｎ”）からなる。
図５４に示す例では“Ｍａｒｋ＿Ｎｕｍｂｅｒ”と当該ＰｌａｙＬｉｓｔが管理するＭａｒｋの数とが同数となり、以降当該ＰｌａｙＬｉｓｔが管理する順番に従って、Ｍａｒｋ毎のメタデータが“Ｍａｒｋ＃１”から順に格納される。
なお、本実施の形態ではＰｌａｙＬｉｓｔが管理するＭａｒｋとメタデータで管理するＭａｒｋとか一対一対応するものとして記述するが、これに限るものではない。
例えば、再生を一時停止した地点を示すＭａｒｋなどＢＤ管理情報では規定出来ないＭａｒｋをメタデータでのみ管理してもよい。
この場合、例えば図５４に示すＭａｒｋのメタデータ領域に、ＢＤ管理情報で規定するＭａｒｋを参照しているのか否かを示す情報と、参照している場合はそのＭａｒｋのＩＤを、参照していない場合はメタデータで管理するＭａｒｋが指すストリームの位置情報を格納する領域を別途設ける必要がある。
各Ｍａｒｋのメタデータは、例として“Ｍａｒｋ＿Ｔｙｐｅ”領域と“サムネイル”領域、および“撮影日時”領域、の３つの領域からなる。
“Ｍａｒｋ＿Ｔｙｐｅ”領域は当該ＰｌａｙＬｉｓｔで管理するＭａｒｋの種別を記録するものである。Ｍａｒｋ＿ｔｙｐｅの１つとして、例えば当該ＭａｒｋがＳｈｏｔの先頭を示すＭａｒｋであるＳｈｏｔ−Ｍａｒｋがある。このＳｈｏｔ−Ｍａｒｋを管理するのは前述のＲｅａｌ ＰｌａｙＬｉｓｔのみとしてもよい。
その他のＭａｒｋ＿Ｔｙｐｅとしては、後述するＯｌｄＳｈｏｔＭａｒｋの他に、例えばスライドショウにおける各静止画の開始位置を意味するＳｌｉｄｅｓｈｏｗＭａｒｋを定義してもよい。
例えばＲｅａｌ ＰｌａｙＬｉｓｔが再生するストリームは動画とスライドショウの混在を許すとした場合、当該ＳｌｉｄｅｓｈｏｗＭａｒｋとＳｈｏｔＭａｒｋにより各Ｃｈａｐｔｅｒが動画なのか静止画なのか判別することができる。
またメニュー表示において動画Ｓｈｏｔのサムネイルのみを表示する場合であっても、ＭａｒｋがＥｎｔｒｙＭａｒｋであり、かつ、ＭａｒｋのメタデータにおけるＭａｒｋＴｙｐｅがＳｈｏｔＭａｒｋのもののみサムネイル一覧表示するといったことが可能となる。
また、例えばＭａｋｅｒＰｒｉｖａｔｅというＭａｒｋＴｙｐｅを定義しておき、メーカー独自機能を実現するＭａｒｋを実現可能としてもよい。
次に“サムネイル”領域は当該Ｍａｒｋの指すストリーム位置における画像をサムネイルとして指定する。なお、当該ＭａｒｋがＳｈｏｔの先頭を示すＭａｒｋである場合、基本はＳｈｏｔの先頭の画像がサムネイルとして設定される。
しかしＳｈｏｔを代表するサムネイルを参照させるために、当該Ｍａｒｋが指すストリーム位置の画像ではなく、ユーザの設定や自動判別などにより抽出した、当該Ｍａｒｋが指すストリーム位置とは別の位置の画像を代表サムネイルとしてもよい。
“撮影日時”領域は、当該ＭａｒｋがＳｈｏｔの先頭を示すＭａｒｋである場合、当該Ｓｈｏｔの撮影日時を記録する。
なお、Ｍａｒｋのメタデータとして記録される情報は、上記説明の内容に限られることはない。例えば、ＢＤ−ＲＯＭ規格では記録出来ない、撮影した情報に関する情報をメタデータとして持たせてもよい。
以上、本実施の形態におけるメタデータの種類とその格納方法について説明した。Ｓｈｏｔを一覧メニューとして表示する際、撮影・録画順にそのサムネイルを表示することで、Ｓｈｏｔの相関関係が掴みやすくユーザの利便性を向上することができる。
本実施の形態ではこのような撮影・録画順のソートならびにメニュー表示を容易とするため、図５３および図５４で示したメタデータにおいて、図５３におけるＰｌａｙＬｉｓｔのメタデータ（図中“ＰＬ＃１”〜“ＰＬ＃ｍ”）を格納する順番を記録順に格納するものとする。
また、基本的にはＰｌａｙＬｉｓｔのメタデータの格納位置は編集等でも変更しないものとする。また前述の図５１に示すように、Ｒｅａｌ ＰｌａｙＬｉｓｔにおいて、Ｓｈｏｔの先頭を示すＳｈｏｔ−Ｍａｒｋは当該Ｓｈｏｔの撮影順に並ぶものとし、当然プレイリストにて管理するＭａｒｋの付加順及び図５４で説明した当該Ｍａｒｋのメタデータの記録順も同様に撮影順に並ぶものとする。
また、当該順序は削除を除き編集等で入れ替えないものとする。以上により、Ｒｅａｌ ＰｌａｙＬｉｓｔのメタデータの格納順と、当該Ｒｅａｌ ＰｌａｙＬｉｓｔが管理するＭａｒｋにおいてＳｈｏｔの先頭を示すＭａｒｋのメタデータの格納順とにより、当該ディスクに記録されたＳｈｏｔの撮影・録画順序を識別することが可能となる。
以上により、Ｓｈｏｔの撮影順にサムネイルや撮影日時等を一覧表示した再生メニューを生成する場合は、図５３および図５４に示すメタデータを参照するだけでよい。
また、“ＰＬ＿Ｔｙｐｅ”がＲｅａｌ ＰｌａｙＬｉｓｔであるＰｌａｙＬｉｓｔのメタデータを順次解析し、当該ＰｌａｙＬｉｓｔのメタデータに於いて、Ｍａｒｋ＿Ｔｙｐｅ＝Ｓｈｏｔ−Ｍａｒｋ（当該ＭａｒｋがＳｈｏｔの先頭を示す）であるＭａｒｋのメタデータを順次参照しメニュー表示すればよい。
例えば本実施の形態のメタデータが図５５（Ａ）に簡易的に示す状態である場合を想定する。この場合、ＰｌａｙＬｉｓｔ＃１、＃２、＃４はＲｅａｌ ＰｌａｙＬｉｓｔであり、ＰｌａｙＬｉｓｔ＃３はＶｉｒｔｕａｌ ＰｌａｙＬｉｓｔである。
従って、ＰｌａｙＬｉｓｔの記録順は、ＰｌａｙＬｉｓｔ＃１，＃２，＃４の順になる。
また、図中において、“（Ｓｈｏｔ）”が付されたＭａｒｋは、Ｓｈｏｔの先頭を示すＭａｒｋを表している。また、図中において、“（ＯｌｄＳｈｏｔ）”が付されたＭａｒｋは、後述する、失われるメタデータを保持するためのＭａｒｋを表している。
従って、各ＰｌａｙＬｉｓｔの中でＳｈｏｔの先頭を示すＭａｒｋの記録順を抽出すると、Ｓｈｏｔの記録順がＰｌａｙＬｉｓｔ＃１のＭａｒｋ＃１，＃３、ＰｌａｙＬｉｓｔ＃２のＭａｒｋ＃１、ＰｌａｙＬｉｓｔ＃４のＭａｒｋ＃１，＃２の順であることがわかる。
このようにして、最終的にＳｈｏｔの一覧メニューを図５５（Ｂ）のように表示することが出来る。
以上、説明したように本実施の形態の記録方法およびデータ構造により、撮影または録画した映像（Ｓｈｏｔ）の記録順を管理することが可能であり、また各Ｓｈｏｔ毎に撮影または録画した映像の撮影日時やサムネイルといった情報をメタデータとして管理することが可能となる。
（実施の形態６）
次に本発明の実施の形態６について説明する。
なお、本実施の形態では情報記録媒体の例として次世代ディスクであるＢＤ−ＲＯＭ Ｄｉｓｃを例に挙げているが、あくまでも例であり、本実施の形態のアプリケーション及びデータ構造をＤＶＤなどの光ディスクや他の情報記録媒体である、メモリーカード（ＳＤメモリーカードやメモリースティックなど）やハードディスクなどに書き込む場合でも同様の効果を得る。
また、情報記録媒体ではなく、本実施の形態のアプリケーション及びデータ構造をネットワークを介して配布する場合においても同様の効果を得る。
実施の形態５において、撮影または録画した映像の撮影日時やサムネイルといったＢＤ−ＲＯＭ規格では記録出来ない情報をＳｈｏｔ単位で情報記録媒体に記録する方法について説明した。
実施の形態６では、Ｓｈｏｔの編集作業によりＳｈｏｔの撮影日時やサムネイルといった情報が失われるという問題を解決する記録方法について説明する。
上記問題の具体例を、図５６を用いて説明する。
まず初期状態として図５６（Ａ）に示すように１つのプレイリスト（Ｒｅａｌ ＰｌａｙＬｉｓｔ）が撮影時間２０分の３つのＳｈｏｔ（Ｓｈｏｔ１〜Ｓｈｏｔ３）を管理しているものと想定する。
ここで図５５（Ａ）に示すようにＭａｒｋＴｙｐｅ＝ＳｈｏｔＭａｒｋのＭａｒｋを各Ｓｈｏｔの先頭に付与し、各Ｓｈｏｔの撮影日時やサムネイル、必要があれば前述の撮影時間などの情報を実施の形態６で述べたようにＭａｒｋのメタデータで管理するものとする。
またＳｈｏｔＭａｒｋは本実施の形態ではユーザにＣｈａｐｔｅｒとして識別させるためＥｎｔｒｙＭａｒｋとする。
以上、説明した初期状態から、図５６（Ｂ）に示すようにＳｈｏｔ１とＳｈｏｔ２を結合する編集を行った場合を想定する。この場合、Ｓｈｏｔ２はＳｈｏｔ１の後ろに結合され、Ｓｈｏｔ１とＳｈｏｔ２とは、１つのＳｈｏｔである撮影時間４０分のＳｈｏｔ１となる。さらに、Ｓｈｏｔ２の先頭に付与されていたＳｈｏｔＭａｒｋは削除される。
この状態で、図５６（Ｃ）に示すようにＳｈｏｔ１を旧Ｓｈｏｔ２の先頭よりも後ろの時間位置にあたる２５分の地点で２つに分割する編集を行う場合を想定する。
このように分割してできた新たなＳｈｏｔをＳｈｏｔ４とすると、Ｓｈｏｔ４の先頭にも新規にＭａｒｋＴｙｐｅ＝ＳｈｏｔＭａｒｋのＥｎｔｒｙＭａｒｋを設定し、Ｍａｒｋのメタデータを記録することになる。
この場合、Ｓｈｏｔ４の撮影日時を正確に計算することは不可能である。ここで、例えば、Ｓｈｏｔ１の撮影日時である“９月１日１２時０分”に、前述の分割した時間位置である２５分を加えることが考えられる。しかし、この加算で得られる“９月１日１２時２５分”という日時は、Ｓｈｏｔ４の撮影日時として正しくない。
このように、Ｓｈｏｔの結合、分割といった処理をおこなうことで、Ｓｈｏｔの撮影日時が失われるという問題がある。
そこで本実施の形態では、ＭａｒｋＴｙｐｅとして新規にＯｌｄＳｈｏｔＭａｒｋというＭａｒｋＴｙｐｅを設けるものとする。
このＭａｒｋＴｙｐｅ＝ＯｌｄｓｈｏｔＭａｒｋは図５６（Ｂ）で示した結合処理によって失われるメタデータを保持するためのＭａｒｋであり、ユーザがＣｈａｐｔｅｒとして識別するためのＭａｒｋではない。そのため、本実施の形態ではＭａｒｋＴｙｐｅ＝ＯｌｄＳｈｏｔＭａｒｋはＬｉｎｋＰｏｉｎｔにのみ設定可能とする。
編集処理によってもＳｈｏｔの撮影日時等のメタデータを保持し、例えばＳｈｏｔの正確な撮影日時を設定可能とする本実施の形態の具体内容について、図５７を用いて説明する。
まず図５７（Ａ）に初期状態を示す。これは図５６（Ａ）で示した初期状態と同じである。また以後行う編集も図５６（Ｂ）に示す編集内容と同じ編集を実行することを想定する。
すなわち、図５７（Ａ）に示す初期状態から、図５７（Ｂ）に示すようにＳｈｏｔ１とＳｈｏｔ２の結合処理を行いＳｈｏｔ４を生成する編集を行ったとする。
この場合、まずＳｈｏｔ４の先頭に付与すべきＥｎｔｒｙＭａｒｋはＳｈｏｔ１のものと同様であり特に処理は行わない。
一方、Ｓｈｏｔ２は消失するためＳｈｏｔ２の先頭に付与していたＭａｒｋＴｙｐｅ＝ＳｈｏｔＭａｒｋのＥｎｔｒｙＭａｒｋをＬｉｎｋＰｏｉｎｔに変更する。
次に、図５４を用いて説明したＭａｒｋＴｙｐｅをＳｈｏｔＭａｒｋからＯｌｄＳｈｏｔＭａｒｋに変更する。これによりＳｈｏｔ２の先頭を示していたＭａｒｋはＢＤ−ＲＯＭにおける管理情報としては、ＬｉｎｋＰｏｉｎｔとして保持される。そのため、Ｍａｒｋと一対一として管理されるＭａｒｋのメタデータも同じく保持される。
次に、図５７（Ｃ）に示すように、Ｓｈｏｔ４の先頭から２５分の地点でＳｈｏｔ４を２つに分割する編集を行い、Ｓｈｏｔ５とＳｈｏｔ６の２つのＳｈｏｔを生成する編集を行ったとする。
この場合、Ｓｈｏｔ５の先頭に付与すべきＥｎｔｒｙＭａｒｋはＳｈｏｔ４のものと同様であり特に処理は行わない。
一方、Ｓｈｏｔ６の先頭にはＥｎｔｒｙＭａｒｋが設定されていないため、Ｓｈｏｔ６の先頭にも新規にＭａｒｋＴｙｐｅ＝ＳｈｏｔＭａｒｋのＥｎｔｒｙＭａｒｋを設定する必要がある。また、当該ＥｎｔｒｙＭａｒｋのメタデータも新規に記録することになる。
この場合のＳｈｏｔ６の撮影日時を計算する方法を以下に述べる。まず、分割前のＳｈｏｔ４において、分割地点にあたるＳｈｏｔ６の先頭より前に存在するＭａｒｋを検索する。
ここでＭａｒｋＴｙｐｅ＝ＯｌｄＳｈｏｔＭａｒｋのＬｉｎｋＰｏｉｎｔを検出する前に、ＭａｒｋＴｙｐｅ＝ＳｈｏｔＭａｒｋのＥｎｔｒｙＭａｒｋを検出、つまりＳｈｏｔ４の先頭に到達した場合は、単純にＳｈｏｔ４の撮影日時に分割した地点の時間を加えたものがＳｈｏｔ４の撮影日時となる。
しかし、本例の場合、図５７（Ｃ）に示すように、旧Ｓｈｏｔ２の先頭よりも後方でＳｈｏｔ４を分割しているため、ＭａｒｋＴｙｐｅ＝ＯｌｄＳｈｏｔＭａｒｋのＬｉｎｋＰｏｉｎｔが先に検出される。
この場合は、旧Ｓｈｏｔ２の先頭にあたるＭａｒｋＴｙｐｅ＝ＯｌｄＳｈｏｔＭａｒｋのＬｉｎｋＰｏｉｎｔのメタデータを参照して“９月５日９時３０分”という日時情報が得られる。
次に、検出したＭａｒｋＴｙｐｅ＝ＯｌｄＳｈｏｔＭａｒｋのＬｉｎｋＰｏｉｎｔの地点（旧Ｓｈｏｔ２の先頭）からＳｈｏｔ６の先頭までの再生時間である５分を、先ほど得た日時情報（９月５日９時３０分）に加える。
このようにして算出される“９月５日９時３５分”という正しい日時情報が、Ｓｈｏｔ６の撮影日時情報となる。
なお、図示しないが、図５７（Ｂ）に示すＳｈｏｔ４を先頭から２０分の地点、すなわち旧Ｓｈｏｔ２の先頭の地点で分割する場合は、単に旧Ｓｈｏｔ２の先頭を示すＬｉｎｋＰｏｉｎｔをＥｎｔｒｙＭａｒｋに変更し、ＭａｒｋのメタデータにおけるＭａｒｋＴｙｐｅをＳｈｏｔｍａｒｋに変更するだけでよい。
なお、図５６および図５７を用いて説明した例はＳｈｏｔの結合や分割といった、あくまでもストリームの再生位置を指定しているＲｅａｌ ＰｌａｙＬｉｓｔの再生制御データの変更による編集作業で発生する問題を例としている。
しかしながら、Ｓｈｏｔのある区間を中抜き削除するといったＡＶストリーム自体を編集する場合においても適用出来る。
例えば、ストリームの一部を削除する場合は、削除部分の直後の再生時刻にＭａｒｋを設定し、当該Ｍａｒｋのメタデータに５７（Ｃ）に示す手法と同様に計算した撮影日時を設定すればよい。
なお、ＭａｒｋをＥｎｔｒｙＭａｒｋとし、メタデータにおけるＭａｒｋＴｙｐｅをＳｈｏｔＭａｒｋにするか、ＭａｒｋをＬｉｎｋＰｏｉｎｔとしメタデータにおけるＭＡｒｋＴｙｐｅをＯｌｄＳｈｏｔＭａｒｋにするかについては、以下のように判断する。
すなわち、削除部分の前後の映像の扱いにより、削除部分の前後の映像を各々別のＳｈｏｔとして扱う場合は前者として設定し、削除部分の前後の映像を結合し１つのＳｈｏｔとして扱う場合は後者として設定する。
以上のように本実施の形態の記録方法およびデータ構造により、Ｓｈｏｔの結合や分割といった処理を行ってもＳｈｏｔの撮影日時を保持することができる。
なお、撮影日時情報など撮影および録画した映像の情報は、メタデータとしてＢＤ−ＲＯＭの管理情報の拡張領域に格納する方法だけでなく、ストリーム中に例えばＳＥＩ＿ＭＥＳＳＥＧＥに埋め込むことも可能である。
またこの場合分割等の編集処理を行ってもその地点でストリームから撮影日時を検出することも可能である。
従って、図５６（Ｂ）に示すＳｈｏｔの結合を行った場合、ストリーム中に撮影日時情報を持たせている場合は、前述のようにＳｈｏｔ２のＥｎｔｒｙＭａｒｋをＬｉｎｋＰｏｉｎｔに変更しＭａｒｋＴｙｐｅ＝ＳｈｏｔＭａｒｋをＯｌｄＳｈｏｔに変更するといった一連の処理を行わないものとしてもよい。
また、図５６（Ｃ）に示すＳｈｏｔの分割を行った場合、まずストリーム中の撮影日時情報を調べ、ストリーム中に撮影日時情報が記録されている場合は、図５６（Ｃ）を用いて説明した撮影日時計算処理を行わずストリームから撮影日時を検出し、メタデータとして設定してもよい。
以上、本発明の実施の形態５および６について説明したが、これら実施の形態で示した記録方法およびデータ構造は、撮影または録画した映像をＢＤ−ＲＯＭ形式で記録する場合に、映像の記録順序を保持するようにメタデータを記録した情報記録媒体と、それを記録する記録装置、記録方法、記録プログラム、並びに、これら実施の形態の記録方法を実現する半導体に適用される。
また、実施の形態５および６の記録方法およびデータ構造によれば、映像を撮影した順序を記録可能であり、特に、民生機器産業において利用される可能性をもつ。
（実施の形態７）
従来、ストリーム内にメタデータを記録する場合には、その記録順が不明であり、数多くのメタデータの全体を検索し解析しなければ、必要なメタデータが記述されているのか否かが分からない。
また、同一種類のメタデータを記述する異なるメタデータがあるような場合、読み出し機器の解析処理が煩雑になるという課題もある。
そこで、実施の形態７として、映像情報を符号化する際に、映像情報への付属情報を同時に符号化する情報記録装置であって、付属情報は、映像情報のピクチャ単位に付与され、１つの付属情報は識別情報（ＩＤ）と実情報（データ）から構成され、同一ピクチャ内で同一種類の情報を格納できる前記付属情報を複数記述する場合には、所定の識別情報（ＩＤ）を持つ付属情報を記録することを特徴とする情報記録装置、および、当該情報記録装置における記録方法について説明を行う。
この情報記録装置および記録方法によれば、メタデータの検索性を向上することができ、同一種類のメタデータが別個の方法で記録されている場合であっても、機器の性能に応じて容易に解析することが可能となる。
なお、実施の形態７は、ムービー機器でのメタデータに関する内容である。基本的には実施の形態１に基づく内容であり、拡張または異なる部分を中心に説明する。
図５８は、ＰＥＳパケット以下のデータ構造を示す図である。ＢＤやデジタル放送のようにＭＰＥＧ２−ＴＳを使う場合には、１つのＰＥＳパケットに１つのピクチャが格納されることが一般的である。
１つのＭＰＥＧ−４ ＡＶＣで符号化されたピクチャは、アクセスユニットの先頭を示すＡＵ Ｄｅｌｉｍｉｔｅｒ（Ａｃｃｅｓｓ Ｕｎｉｔ Ｄｅｌｉｍｉｔｅｒ）、シーケンス属性を示すＳＰＳ（Ｓｅｑｕｅｎｃｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ピクチャ属性を示すＰＰＳ（Ｐｉｃｔｕｒｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、付属情報などを格納するＳＥＩ（Ｓｕｐｐｌｅｍｅｎｔａｌ Ｅｎｈａｎｃｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ）、および、スライス符号情報を示すＳｌｉｃｅなどから構成される。
付属情報を格納するＳＥＩは、ＣｌｏｓｅｄＣａｐｔｉｏｎ情報やその他の情報を格納している。
ここでは、主にビデオカメラレコーダ向けのメタデータをＨＤＭとして束ね、ＳＥＩの中に格納している。
図５９には、ＳＥＩのデータ構造を示した。図に示されたように当該ＳＥＩにどのような付属情報が入っているかを示す識別情報（ｔｙｐｅ＿ｉｎｄｉｃａｔｏｒ）により、格納されているデータ種類が特定できる。
例えば、“ｔｙｐｅ＿ｉｎｄｉｃａｔｏｒ ＝ ０ｘ００００００２０”であれば、ＨＤＭデータが格納されているということがわかる。
ＨＤＭデータは、ＨＤＭ＿ｐａｃｋ＿ＩＤ（８ビット）とＨＤＭ＿ｐａｃｋ＿ｄａｔａ（３２ビット）から構成されるＨＤＭ＿ｐａｃｋの集合体である。
このＩＤ値によって、どのような種類の付属情報が、後続のＨＤＭ＿ｐａｃｋ＿ｄａｔａに記録されているのかを示している。ここで示されるように、ＨＤＭ＿ｐａｃｋは連続してＨＤＭ＿ｍｅｔａ（）内に記録される。
ちなみに、ＨＤＭ＿ｐａｃｋは、ＤＶ（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ）カメラが使用している付属情報のＤＶパックと同じデータ構造（８ビットのＩＤ＋３２ビットのデータ）である。
図６０は、ＨＤＭ＿ｐａｃｋのＩＤ値と格納している情報との関係を示す表である。
ＴＩＭＥ列（上位４ビットが０００１ｂ）のＴＩＭＥ ＣＯＤＥ、ＢＩＮＡＲＹ ＧＲＯＵＰと、ＣＡＭＥＲＡ列（上位４ビットが０１１１ｂ）の全てのＨＤＭ＿ｐａｃｋはＤＶパックと同じである。
ＲＥＣ ＤＡＴＥ＆ＴＩＭＥは、この付属情報（ピクチャ）が撮影された日時情報である。
ＥＸＩＦ列（上位４ビットが１０１０ｂ）、ＧＰＳ列（上位４ビットが１０１１ｂ、１１００ｂ）はデジタルスチルカメラで使われているＥｘｉｆの情報と同じである。
ただし、Ｅｘｉｆで使われている３２ｂｉｔ／３２ｂｉｔのＲＡＴＩＯＮＡＬ表記ではサイズが大きいため、１６ｂｉｔ／１６ｂｉｔのＲＡＴＩＯＮＡＬ表記としている。
ＥＸＩＦ ＯＰＴＩＯＮ、ＧＰＳ ＯＰＴＩＯＮには、この表に記載のないＥｘｉｆ／ＧＰＳの情報を書き込みたい場合に使うパックである。
具体的には、ＨＤＭ＿ｐａｃｋ＿ｄａｔａにＥｘｉｆのＴａｇ値を書くＥｘｉｆ＿Ｔａｇ（１６ビット）、Ｅｘｉｆに１６ビット表記のＲＡＴＩＯＮＡＬ１６、符号付きのＳＲＡＴＩＯＮＡＬ１６を新規追加したＥｘｉｆ＿Ｔｙｐｅ（８ビット）、および、続くパック数を示すＰａｃｋ＿Ｌｅｎｇｔｈ（８ビット）を記述し、Ｅｘｉｆのメタデータを後続のパックに記録することができる。
ＭＡＫＥＲ列（上位４ビットが１１１０ｂ）には、メーカーコードと記録したモデルコードを１６ビットずつで記述するＭＡＫＥＲ＆ＭＯＤＥＬパックと、各メーカーが独自に使うことのできるＭＡＫＥＲ ＯＰＴＩＯＮパックが規定されている。
このように、ＨＤＭ＿ｐａｃｋ＿ＩＤ値によって、どのデータが記録されているパックなのか、すぐに特定することができる。しかし、ＨＤＭ＿ｍｅｔａ（）の中での記録規則が無いと常に最後のパックまで検索が必要となり、高速なメタデータの検索／抽出が不可能になる。
また、ＳＥＩはピクチャ単位で２５６バイトの上限サイズと共に書き込まれるデータであるため、このメタデータの処理にはリアルタイム性（高速性）が要求される。
また、全てのパックをピクチャごとに記録する必要はないため、最後のパックまで検索しても所望のメタデータを格納したパックが見つからないことも考えられる。
そこで、ＨＤＭ＿ｍｅｔａ（）内でのＨＤＭ＿ｐａｃｋ（）の記録順は、ＨＤＭ＿ｐａｃｋ（）のＨＤＭ＿ｐａｃｋ＿ＩＤの小さい順番に並ぶことと規定することが重要である。
これにより、所望のパックを検索するために、ＨＤＭ＿ｍｅｔａ（）内でさらなるサーチが必要か否かを判定することが可能となる。また、所望のパックのＩＤ値を超えた場合、それより先に所望のパックが存在していないことが分かり、サーチ処理を早期に終了することが可能となる。
図６１は、上記処理の流れを示すフロー図である。
ＨＤＭメタの取得が開始されると（Ｓ９０１）、ＨＤＭパック数を取得する（Ｓ９０２）。ＨＤＭメタを取得し、データの最後尾であれば（Ｓ９０３でＹｅｓ）、ＨＤＭメタの取得に係る処理を終了する（Ｓ９０４）。
また、データの最後尾でなければ（Ｓ９０３でＮｏ）、取得したい情報を全て取得したか否かを判断する。全て取得した場合は（Ｓ９０５でＹｅｓ）、ＨＤＭメタの取得に係る処理を終了する（Ｓ９０４）。また、全て取得していない場合は（Ｓ９０５でＮｏ）、解析を続けても取得した情報が取得できるか否かを判断する。
取得できない場合は（Ｓ９０６でＹｅｓ）は、ＨＤＭメタの取得に係る処理を終了する（Ｓ９０４）。また、取得できる場合は（Ｓ９０６でＮｏ）、１つＨＤＭ＿ｐａｃｋ（）を取得し、上記のデータの最後尾であるか否かの判断（Ｓ９０３）に戻る。
図６１に示すように、ＨＤＭ＿ｍｅｔａ（）内のパックは、ＩＤ順で記述されているため、所望のパックを最低の処理負荷で検索／抽出することができる。
図６２は、ＤＶにて定義されているＣＡＭＥＲＡ列のパックと、ＥＸＩＦにて定義されているＥＸＩＦ列のパックとの格納している情報の同一性を比較したものである。
図６２に示すように、ＥＸＩＦ列のパックにて格納される情報が、ＣＡＭＥＲＡ列のパックでも記述できるケースがあることが分かる。即ち２重に定義された状態となっている。
これは、ＨＤＭ＿ｍｅｔａ（）がＤＶとＥｘｉｆの主要なメタデータを利用しているために、焦点距離などの光学パラメーターなどで一部重複していることを示している。
例えば、ＥＸＩＦ列のＦＯＣＡＬ ＬＥＮＧＴＨ（焦点距離）は、ＣＡＭＥＲＡ列のＣＯＮＳＵＭＥＲ ＣＡＭＥＲＡ１とＣＯＮＳＵＭＥＲ ＣＡＭＥＲＡ２のそれぞれにて記述することが可能である。
安価な機器では、静止画向けで高品位なＥＸＩＦ列の情報までは不必要だが、ＤＶで使われているＣＡＭＥＲＡ列程度の精度の情報で十分な場合も想定される。
また、このように同種の情報が２重持ちされているため、ＨＤＭ＿ｍｅｔａ（）を解析する処理が煩雑になる課題もある。
そこで、ＥＸＩＦ列のパックを記録する場合には、そのパックが格納する情報をＣＡＭＥＲＡ列においても記述できるのであれば、そのＣＡＭＥＲＡ列のパックも記録することが重要である。
先ほどのＩＤ順で記録されるルールを加味して考慮すれば、安価な機器は、ＩＤ順にサーチを行い、自らが欲しい情報の精度であるＣＡＭＥＲＡ列のパックだけを解析し、以降にＥＸＩＦ列のパックがあったとしても、ＣＡＭＥＲＡ列の情報だけを取得した時点で、解析処理を止め、ユーザにその情報を提供することが可能となる。
また、ＥＸＩＦ列まで対応した機器においては、ＣＡＭＥＲＡ列で所望のデータを取得できても、ＥＸＩＦ列まで解析を行い、より高精度な付属情報を取得することが容易に可能となる。
図６３は、ＤＶとＥＸＩＦとで同種情報を持つ場合の記録ルールの例を説明する図である。この例では、ＥＸＩＦ列のＥＸＰＯＳＵＲＥ ＴＩＭＥ、Ｆ ＮＵＭＢＥＲ、ＥＸＰＯＳＵＲＥ ＢＩＡＳ、ＭＡＸ ＡＰＥＲＴＵＲＥ、ＦＬＡＳＨ、および、ＦＯＣＡＬ ＬＥＮＧＴＨのパックが記録されているために、対応するＣＡＭＥＲＡ列のパックも記録されている。
また、Ｆ ＮＵＭＢＥＲおよびＦＯＣＡＬ ＬＥＮＧＴＨが記録されているため、ＣＯＮＳＵＭＥＲ ＣＡＭＥＲＡ１が記録されており、同様にＥＸＰＯＳＵＲＥ ＴＩＭＥが記録されているため、ＳＨＵＴＴＥＲが記録されている。
このように、精度が異なる同種の情報を記録する場合には、精度の低い方の情報が必ず記録順として先になるように記録されていることが肝要である。
なお、対応するパックの相関が複雑になったり、ＥＸＩＦ列のデータを追加するために、ＥＸＩＦ列よりも前方のＣＡＭＥＲＡ列のデータを追加することになるが、このために、メモリ上での挿入処理が煩雑になることも考えられる。
このような場合には、ＥＸＩＦ列に所定のパックを記録する場合には、必ずＣＡＭＥＲＡ列のＣＯＮＳＵＭＥＲ ＣＡＭＥＲＡ１だけは記録する、といった規則を設けることも効果的である。
図６２によれば、所定のパックとは、Ｆ ＮＵＭＢＥＲ、ＥＸＰＯＳＵＲＥ ＰＲＯＧ．、ＦＯＣＡＬ ＬＥＮＧＴＨ、ＷＨＩＴＥ ＢＡＬＡＮＣＥを指している。
勿論、より簡単に、ＥＸＩＦ列に何か記録する場合には、必ずＣＡＭＥＲＡ列の所定のパックを記録するとしてもよい。
また、ＣＡＭＥＲＡ列を使うか、ＥＸＩＦ列を使うかを当該ストリームの管理情報（ＹＹＹ．ＶＯＢＩ）などで示しておくことも考えられる。
ＤＶは動画向けのメタデータとして設計され、ＥＸＩＦは静止画向けのメタデータとして設計されているため、当該ＶＯＢが動画か、静止画かの情報をＶＯＢＩに記録させ、その値に応じて、動画であればＣＡＭＥＲＡ列を使い、静止画であればＥＸＩＦ列を使うことも可能である。
本実施の形態の情報記録装置および記録方法は、光ディスクなどに記録するメタデータに情報の重複がある場合や、その種類が膨大である場合などに、メタデータの検索処理を簡易化することができ、大幅に再生（検索）処理時間を減らすことができる。そのため、ハードディスクや半導体メモリなどの記録メディア上に記録する場合にも同様に有用である。
（実施の形態８）
近年、デジタルスチルカメラなどで撮影した静止画を、動画と共に管理したいというユーザ要求が近年高まってきている。
しかしながら、デジタルスチルカメラの静止画は一般には非常に高画素（１９２０ｘ１０８０以上）のＪＰＥＧであって、ＨＤＴＶへの出力を行うことが前提である民生ＡＶ機器にとっては、そのＣｏｄｅｃとサイズの両面から扱いにくいという課題があった。
また、次世代ＤＶＤ規格（ＢＤ−ＲＯＭ規格）では、スライドショウとして静止画を扱うことは可能であるが、基本的にはパッケージメディアを対象とした規格である。そのため、スライドショウの静止画の再生順番を入れ替えたり、１枚を削除するといった編集作業が実現困難である。
そこで実施の形態８として、ＢＤ−ＲＯＭ規格のスライドショウにデジタルスチルカメラの静止画を取り込む際に編集容易な形で取り込めるようにする記録方法について説明する。
具体的には、１つの静止画映像を含むシステムストリームである静止画ユニットを生成し、前記静止画ユニットの再生を管理する再生管理情報と共に情報記録媒体に記録する情報記録装置であって、静止画ユニットは記録する情報記録媒体の記録単位（セクタ）の整数倍のデータサイズとする情報記録装置および記録方法について説明する。
本実施の形態では、上記情報記録装置および記録方法によって、静止画スライドショウを用いて、動画と静止画を同列で管理することができ、イベント単位（例えば子供の運動会で撮影した動画と静止画）などでコンテンツを管理することが可能となる。
また、その際に静止画スライドショウに編集耐性を与えることで、静止画スライドショーの再生順序の入れ替えや削除といった編集作業が容易かつ高速になる。
実施の形態８は、上述のように、ＢＤ−ＲＯＭの静止画スライドショウにおけるストリーム構造に関する内容である。基本的には実施の形態１に基づく内容であり、拡張または異なる部分を中心に説明する。
図６４は、ＢＤのストリーム構造を示している。ＢＤで扱うストリームは記録するメディアのセクタサイズなどとは無関係に、ＴＳパケット（１８８バイト）とそのＴＳパケットのデコーダへの入力時刻を復元するＡＴＳ（Ａｒｒｉｖａｌ Ｔｉｍｅ Ｓｔａｍｐ、４バイト）を加えたＴｉｍｅｄ ＴＳ Ｐａｃｋｅｔと呼ばれる１９２バイトの繰り返しで構成されている。
ＢＤがＴＳパケット（ＭＰＥＧ−２ Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ）を採用している理由は、デジタル放送がＭＰＥＧ２−ＴＳを用いて行われていることとの親和性を確保するためである。
１９２バイトのＴｉｍｅｄ ＴＳ Ｐａｃｋｅｔは、ＤＶＤやＢＤの２ＫＢのセクタサイズとは合致しないため、これを３２個集めた単位（Ａｌｉｇｎｅｄ Ｕｎｉｔとも呼ばれる６ＫＢ）を最小記録単位としている。
従って、仮に編集がある場合には、このＡｌｉｇｎｅｄ Ｕｎｉｔ（６ＫＢ）単位での追加／削除がなされ、ＢＤで扱うストリーム自体が整数個のＡｌｉｇｎｅｄ Ｕｎｉｔから構成されるように扱われる。
図６５は、デジタルスチルカメラなどで撮影した静止画をＢＤ−ＲＯＭで規定するスライドショウとして取り込んだ場合のフォーマット構成を示す。
図に示すように、“ＸＸＸ．ＰＲＯＧ”は“ＸＸＸ．ＰＬ”を再生するようなプログラム（再生管理情報）であり、“ＸＸＸ．ＰＬ”は、１つのＣｅｌｌから成るプレイリストである。
Ｃｅｌｌ＃１は、３つのＳｔｉｌｌ Ｕｎｉｔ（１つの静止画映像を含むＭＰＥＧ２−ＴＳの区間）を含む“ＹＹＹ．ＶＯＢ”ストリーム全体を指し示している。また、再生開始時刻（Ｉｎ＃１）と再生終了時刻（Ｏｕｔ＃１）とは、この３つのＳｔｉｌｌ Ｕｎｉｔの再生期間を指定する情報である。
各Ｓｔｉｌｌ Ｕｎｉｔ内の、Ｉ−ｐｉｃｔｕｒｅに付与されたＰＴＳの値はそれぞれＰＴＳ＃１、ＰＴＳ＃２、およびＰＴＳ＃３であって、ユーザのスキップ指令などのインタラクションが無い場合には、そのＰＴＳタイミングから自動で切り替わり再生される。
従って、ユーザが何も操作をしない場合には、ＰＴＳ＃２−ＰＴＳ＃１の時間がＳｔｉｌｌ Ｕｎｉｔ＃１の静止画の表示時間となる。
ユーザが次の静止画にスキップするなどといった操作を行う場合には、その操作のタイミングで次のＳｔｉｌｌ Ｕｎｉｔの再生を開始するようすることもできる。
このような、ＢＤ−ＲＯＭのスライドショウを使ってユーザがデジタルスチルカメラの静止画を取り込む場合、Ｃｅｌｌ内のＳＴＣ時間軸（ＭＰＥＧストリームの内部基準時間）が連続して経過しないといけないなど制限があるために、例えばＳｔｉｌｌ Ｕｎｉｔ＃２だけを削除するなどの編集をされた場合、ストリームからの部分削除時に、ＰＴＳ＃３などのストリームに埋め込まれた時刻情報などを修正していく必要がでてくる。
また、Ｓｔｉｌｌ Ｕｎｉｔ＃２がセクタアライメントされていないため、つまり、データ長が６ＫＢの整数倍にされていないため、ストリームからの中抜き編集において、セクタ単位の削除処理ができず煩雑となる。
これは、Ｓｔｉｌｌ Ｕｎｉｔ＃２の最初と最後のＴｉｍｅｄ ＴＳ Ｐａｃｋｅｔが、両端のＳｔｉｌｌ Ｕｎｉｔ（Ｓｔｉｉｌ Ｕｎｉｔ＃１と＃３）のＴｉｍｅｄ ＴＳ Ｐａｃｋｅｔと同じセクタに記録されているためである。
このようにスライドショウの編集には、セクタアライメントと時刻情報の変更という２つの処理が付きまとう。以下に、この課題を解決するための方法を説明する。
図６６に示す“ＸＸＸ．ＰＲＯＧ”は図６５に示すものと同一だが、“ＸＸＸ．ＰＬ”を構成するＣｅｌｌをＳｔｉｌｌ Ｕｎｉｔと１対１に対応させている。この利点は、特定のＳｔｉｌｌ Ｕｎｉｔを削除してもストリーム内部のタイムスタンプの修正が不要になるということである（図に示すように、各Ｃｅｌｌはそれぞれ独自のＳＴＣ時間軸上に配置されている。）。
また、図６７に詳細に示すように、１つのＳｔｉｌｌ ＵｎｉｔのデータサイズがＡｌｉｇｎｅｄ Ｕｎｉｔ（６ＫＢ）の整数倍となるように、ダミーのＴｉｍｅｄ ＴＳ Ｐａｃｋｅｔ（ＮＵＬＬパケットでよい）を追加することが可能である。
このようにすることで、１枚の静止画単位（１つのＳｔｉｌｌ Ｕｎｉｔ単位）での削除や、順番の入れ替えにも容易に対応することができるようになる。
１つのＳｔｉｌｌ Ｕｎｉｔは、例えばＭＰＥＧ２−Ｖｉｄｅｏを用いる場合には、シーケンスヘッダ、ＧＯＰヘッダ、Ｉピクチャ、シーケンスエンドコードからなる１枚の静止画を示す主映像ストリームと、プログラム構成に必要なＰＳＩ／ＳＩパケット（ＰＡＴ、ＰＭＴ、およびＳＩＴなど）、基準時刻ＳＴＣを生成する時刻情報を運ぶＰＣＲパケット、および静止画（主映像ストリーム）に重畳して表示する副映像ストリームとから構成される。
前述のような制限を加えることで、例えば図６６のＳｔｉｌｌ Ｕｎｉｔ＃２を削除したり、Ｓｔｉｌｌ Ｕｎｉｔ＃２とＳｔｉｌｌ Ｕｎｉｔ＃３の順番を変更する処理が、単純なプレイリストファイルのＣｅｌｌ情報の修正と、ストリーム（Ｓｔｉｌｌ Ｕｎｉｔ）の部分削除／部分並び替えで済むようになる。
つまり、修正箇所以降のストリームを解析し、ＰＴＳの値を変更していくなどの処理は不要である。
図６８には、副映像情報として、デジタルスチルカメラなどで良く使われているＥｘｉｆ情報を字幕ストリームとして取り込む例を示している。
Ｅｘｉｆ情報とは、シャッター速度やＩＳＯ感度、撮影日時などの静止画に関連する付加情報を格納した情報であり、各種様々な静止画に関連する情報を格納している情報である。
このような静止画に付随する情報は常には表示される必要は無いため、図６８（Ｃ）に示すような副映像情報を、ＢＤ−ＲＯＭにおける字幕ストリームのような仕組み（ユーザが意図的に表示／非表示を選択可能な仕組み）として多重化することも考えられる。
この場合、ユーザは、図６８（Ｂ）のような静止画だけの静止画スライドショウだけではなく、もしユーザが望むならば、それに付随する情報も表示する図６８（Ａ）のような形式で静止画スライドショウを楽しむこともできる。
図６９は、デジタルスチルカメラの静止画とＥｘｉｆ情報から、図６８（Ａ）〜図６８（Ｃ）に示すような主映像と副映像に区別されたスライドショウを作成するためのフロー図である。
静止画の取り込みが開始されると（Ｓ１００１）、まず、変換する静止画を読み込む（Ｓ１００２）。静止画からＥｘｉｆ情報を抽出し（Ｓ１００３）、Ｅｘｉｆ情報の一部を主映像に重畳する副映像としてエンコードする（Ｓ１００４）。
また、静止画を１９２０×１０８０の画素数にリサイズする（Ｓ１００５）。リサイズ後、１枚のＩ−ｐｉｃｔｕｒｅからなる主映像（ＭＰＥＧ２−Ｖｉｄｅｏ等）としてエンコードする（Ｓ１００６）。
以上により、主映像と副映像とが生成され、主映像と副映像とを合わせたＳｔｉｌ Ｕｎｉｔを生成する（Ｓ１００７）。
Ｓｔｉｌ Ｕｎｉｔがセクタアラインメントされている場合は（Ｓ１００８でＹｅｓ）、静止画の取り込みに係る処理を終了する（Ｓ１０１０）。
また、Ｓｔｉｌ Ｕｎｉｔがセクタアラインメントされていない場合は（Ｓ１００８でＮｏ）、ダミーパケット（ＮＵＬＬパケット）を追加し、セクタアラインメントにする（Ｓ１００９）。その後、静止画の取り込みに係る処理を終了する（Ｓ１０１０）。
一般的にはデジタルスチルカメラの画素数はフルＨＤの１９２０ｘ１０８０を超えるものが多いため、ＨＤサイズにリサイズしてＩ−ｐｉｃｔｕｒｅとしてエンコードを行う。また、所定のＥｘｉｆ情報を抽出し、字幕ストリーム（ＰＧストリーム：Ｐｒｅｓｅｎｔａｔｉｏｎ Ｇｒａｐｈｉｃｓストリーム）としてエンコードを行う。
エンコードが済んで多重化を行い、Ｓｔｉｌｌ Ｕｎｉｔ単位でセクタアライメントがとれるよう、ダミーパケットを挿入して多重化を終える。
本実施の形態にかかる光ディスクおよびその記録／再生装置、記録／再生方法は、光ディスクに記録された静止画スライドショウの１論理単位を記録媒体の記録単位（セクタ）に合わせることで、静止画スライドショウの編集が極めて容易となる。
また、光ディスクに限らず、ハードディスクや半導体メモリなどの記録メディア上に記録する場合にも有用であり、このような種々の記録メディアに記録するＡＶレコーダや、記録された記録メディア、これらの記録メディアを再生するＡＶプレーヤに適用できる。
本発明によれば、映像コンテンツ等を追記した際に、既存のディスクメニューに関連するファイルを容易に識別し削除可能な情報記録媒体を提供できる。この情報記録媒体は、ディスク媒体のみならず、半導体メモリ等の他の記録媒体としても実現可能である。従って映像コンテンツの制作に携わる映画産業・民生機器産業において使用される情報記録媒体として特に有用である。
１ ＢＤ−ＲＯＭプレーヤ
２ オーディオ専用プレーヤ
１０４ ＢＤ−ＲＯＭ
１０５ ディスク
２０２ 光ピックアップ
２０３ プログラム記録メモリ
２０４ 管理情報記録メモリ
２０５ ＡＶ記録メモリ
２０６ プログラム処理部
２０７ 管理情報処理部
２０８ プレゼンテーション処理部
２０９ イメージプレーン
２１０ ビデオプレーン
２１１ 合成処理部
３０２ プログラムプロセッサ
３０３ ＵＯマネージャ
３０５ シナリオプロセッサ
３０６ プレゼンテーションコントローラ
３０７ クロック
３０８ イメージメモリ
３０９ トラックバッファ
３１０ デマルチプレクサ
３１１ イメージプロセッサ
３１２ ビデオプロセッサ
３１３ サウンドプロセッサ
３１７ ドライブコントローラ
４００ レコーダ
４０１ プレイリスト特定部
４０２ 削除部
４０３ メニュー生成部
４０４ メーカー判定部
４０５ 受付部
４０６ 編集部
４０７ 番号読出部
４０８ 撮影部
４０９ 表示部
Ｓ８０１ 記録／編集開始ステップ
Ｓ８０２ ＢＤ．ＩＮＦＯ、ＢＤ．ＰＲＯＧ読み込みステップ
Ｓ８０３ タイトル番号取得ステップ
Ｓ８０４ 関連ファイル更新ステップ
Ｓ８０５ 新規タイトル番号付与ステップ
Ｓ８０６ ダミーデータ付与ステップ
Ｓ８０７ 更新済ＢＤ．ＩＮＦＯおよび更新済ＢＤ．ＰＲＯＧ書込みステップ

Claims (4)

  1. 映像情報を符号化する際に、前記映像情報に関するパラメータを同時に符号化して、情報記録媒体に情報を記録する情報記録方法であって、
    前記パラメータは、前記映像情報のピクチャ単位に付与されており、
    前記パラメータが、同じ種類且つ精度が異なる複数のパラメータを含む場合、
    精度の低いパラメータを、精度の高いパラメータよりも記録の順番で先に、前記情報記録媒体に記録する
    ことを特徴とする情報記録方法。
  2. 前記映像情報に関するパラメータは、前記映像情報を撮影する際の光学パラメータである
    ことを特徴とする請求項１記載の情報記録方法。
  3. 映像情報を符号化する際に、前記映像情報に関するパラメータを同時に符号化して、情報記録媒体に情報を記録する記録装置であって、
    前記パラメータは、前記映像情報のピクチャ単位に付与されており、
    前記パラメータが、同じ種類且つ精度が異なる複数のパラメータを含む場合、
    精度の低いパラメータを、精度の高いパラメータよりも記録の順番で先に、前記情報記録媒体に記録する記録手段を有する
    ことを特徴とする記録装置。
  4. 前記映像情報に関するパラメータは、前記映像情報を撮影する際の光学パラメータである
    ことを特徴とする請求項３記載の記録装置。
JP2011169448A 2005-07-27 2011-08-02 記録装置および情報記録方法 Active JP5314097B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2011169448A JP5314097B2 (ja) 2005-07-27 2011-08-02 記録装置および情報記録方法

Applications Claiming Priority (13)

Application Number Priority Date Filing Date Title
JP2005216992 2005-07-27
JP2005216992 2005-07-27
JP2005280933 2005-09-27
JP2005280933 2005-09-27
JP2005289091 2005-09-30
JP2005289091 2005-09-30
JP2005304559 2005-10-19
JP2005304559 2005-10-19
JP2005318894 2005-11-01
JP2005318894 2005-11-01
JP2006145954 2006-05-25
JP2006145954 2006-05-25
JP2011169448A JP5314097B2 (ja) 2005-07-27 2011-08-02 記録装置および情報記録方法

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2006200084A Division JP4827642B2 (ja) 2005-07-27 2006-07-21 記録装置、記録方法、プログラムおよび集積回路

Publications (2)

Publication Number Publication Date
JP2011227990A JP2011227990A (ja) 2011-11-10
JP5314097B2 true JP5314097B2 (ja) 2013-10-16

Family

ID=37683276

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2011169447A Pending JP2011227989A (ja) 2005-07-27 2011-08-02 記録装置および情報記録方法
JP2011169448A Active JP5314097B2 (ja) 2005-07-27 2011-08-02 記録装置および情報記録方法

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2011169447A Pending JP2011227989A (ja) 2005-07-27 2011-08-02 記録装置および情報記録方法

Country Status (6)

Country Link
US (1) US20100284667A1 (ja)
EP (1) EP1909281A4 (ja)
JP (2) JP2011227989A (ja)
KR (1) KR101248305B1 (ja)
CN (3) CN101228584B (ja)
WO (1) WO2007013378A1 (ja)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPWO2007108345A1 (ja) * 2006-03-17 2009-08-06 パナソニック株式会社 記録再生装置
US8509590B2 (en) 2007-05-28 2013-08-13 Panasonic Corporation Metadata recording device and method thereof
US20090288076A1 (en) * 2008-05-16 2009-11-19 Mark Rogers Johnson Managing Updates In A Virtual File System
EP2350860B1 (en) * 2008-11-06 2015-04-08 Deluxe Media Inc. Placeholders in index table for updating a portable storage medium
US20120311446A1 (en) * 2010-04-13 2012-12-06 Toshihisa Nakano Content recording device, content recording method, content recording program, recording medium, integrated circuit and content recording and reproduction system
CN101795370A (zh) * 2010-04-19 2010-08-04 四川长虹电器股份有限公司 用户自定义电视菜单显示顺序的方法和装置
KR101781861B1 (ko) * 2011-04-04 2017-09-26 엘지전자 주식회사 영상표시장치 및 이를 이용한 텍스트 디스플레이 방법
CN102270100B (zh) * 2011-08-22 2013-01-09 深圳市开立科技有限公司 一种触摸屏界面的菜单处理方法和触摸屏系统
US9100724B2 (en) * 2011-09-20 2015-08-04 Samsung Electronics Co., Ltd. Method and apparatus for displaying summary video
US9888115B2 (en) * 2013-02-28 2018-02-06 Lennard A. Gumaer Media device and method of using a media device
JP6168453B2 (ja) * 2013-09-19 2017-07-26 パナソニックＩｐマネジメント株式会社 信号記録装置、カメラレコーダおよび信号処理装置
CN104240737B (zh) * 2014-09-22 2017-01-18 广东欧珀移动通信有限公司 一种蓝光播放机跳过片头播放碟片的方法及系统
EP3258700A4 (en) * 2015-02-13 2017-12-20 Panasonic Intellectual Property Management Co., Ltd. Content reproduction system, video recording apparatus, terminal apparatus, and content reproduction method
CN106293353B (zh) * 2015-05-22 2020-06-16 腾讯科技（深圳）有限公司 列表元素的展开控制方法和装置

Family Cites Families (49)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5448440A (en) 1994-06-16 1995-09-05 Minnesota Mining And Manufacturing Company Data storage device with roller lubricant that provides excellent drag force characteristics
JP2813245B2 (ja) 1995-08-21 1998-10-22 松下電器産業株式会社 光ディスクの再生装置及び再生方法
JPH09282848A (ja) * 1996-04-05 1997-10-31 Pioneer Electron Corp 情報記録媒体並びにその記録装置及び再生装置
JP3879170B2 (ja) * 1997-03-31 2007-02-07 ソニー株式会社 撮像装置及び撮像方法
JP3114971B2 (ja) * 1997-08-07 2000-12-04 松下電器産業株式会社 光ディスク、再生装置および再生方法
US6222805B1 (en) * 1997-08-07 2001-04-24 Matsushita Electric Industrial Co., Ltd. Optical disk, reproduction apparatus, and reproduction method
JPH11213628A (ja) * 1998-01-21 1999-08-06 Toshiba Corp 記録媒体とその再生装置および記録再生装置
US6816666B1 (en) * 1998-02-03 2004-11-09 Sanyo Electric Co., Ltd. Information recorder, recording method, and recording media
KR100331322B1 (ko) * 1998-06-22 2002-08-27 삼성전자 주식회사 제조업체간의 특수기능을 지원하기 위한 부가정보를 저장하는 기록매체 및 기록 및/또는 편집장치와 그방법
JP3873463B2 (ja) * 1998-07-15 2007-01-24 株式会社日立製作所 情報記録装置
JP3382159B2 (ja) * 1998-08-05 2003-03-04 株式会社東芝 情報記録媒体とその再生方法及び記録方法
US6904227B1 (en) * 1999-02-15 2005-06-07 Nec Corporation Device and method for editing video and/or audio data recorded in a disc storage medium
JP4599740B2 (ja) * 2000-04-21 2010-12-15 ソニー株式会社 情報処理装置および方法、記録媒体、プログラム、並びに記録媒体
US7477833B2 (en) * 2000-04-21 2009-01-13 Sony Corporation Information processing apparatus and method, program, and recorded medium specifying particular picture characteristics
US7043484B2 (en) * 2000-12-05 2006-05-09 Dvdemand Technologies Inc. System and method for producing storage media images
JP4250328B2 (ja) * 2000-12-06 2009-04-08 キヤノン株式会社 記録装置
US7028021B2 (en) * 2001-01-31 2006-04-11 Hewlett-Packard Development Company, L.P. Aggregating device collection data
JP4658374B2 (ja) * 2001-05-10 2011-03-23 株式会社リコー 無線通信方法及びそのマスター端末
JP4205574B2 (ja) * 2001-05-31 2009-01-07 キヤノン株式会社 画像処理装置及びその制御方法
EP1298665A1 (en) * 2001-09-27 2003-04-02 Samsung Electronics Co., Ltd. Method, apparatus and storage medium for recording information
KR100513331B1 (ko) * 2002-06-19 2005-09-07 엘지전자 주식회사 재기록 가능 기록매체의 파일 임시 삭제 및 복구방법
KR20040000290A (ko) * 2002-06-24 2004-01-03 엘지전자 주식회사 고밀도 광디스크의 멀티 경로 데이터 스트림 관리방법
CN1695197B (zh) * 2002-09-12 2012-03-14 松下电器产业株式会社 播放设备、播放方法、以及记录介质的记录方法
EP1474803A1 (en) * 2002-12-11 2004-11-10 Matsushita Electric Industrial Co., Ltd. Recording apparatus, computer-readable program, and system lsi
JP2003272358A (ja) * 2003-01-29 2003-09-26 Nec Corp 記録情報の編集方法およびディスク記憶媒体の記録編集装置
US8055117B2 (en) * 2003-02-15 2011-11-08 Lg Electronics Inc. Recording medium having data structure for managing reproduction duration of still pictures recorded thereon and recording and reproducing methods and apparatuses
US7606463B2 (en) * 2003-02-24 2009-10-20 Lg Electronics, Inc. Recording medium having data structure for managing playback control and recording and reproducing methods and apparatuses
EP1517554A4 (en) * 2003-03-13 2010-06-16 Panasonic Corp DATA PROCESSING DEVICE
JP3912536B2 (ja) * 2003-03-25 2007-05-09 ソニー株式会社 記録方法、記録装置、記録媒体、撮像装置および撮像方法
RU2360301C2 (ru) * 2003-05-27 2009-06-27 Эл Джи Электроникс Инк. Носитель записи со структурой данных для управления основными данными и данными дополнительного содержимого к ним и способы и устройства записи и воспроизведения
TW200601300A (en) * 2003-06-30 2006-01-01 Matsushita Electric Ind Co Ltd Apparatus and computer-readable program for generating volume image
US8280230B2 (en) * 2003-07-03 2012-10-02 Panasonic Corporation Recording medium, reproduction apparatus, recording method, integrated circuit, program and reproduction method
JP4102264B2 (ja) * 2003-07-18 2008-06-18 株式会社東芝 デジタルａｖ情報記録媒体とこの媒体を用いる記録／再生方法および記録／再生装置
US20050015389A1 (en) * 2003-07-18 2005-01-20 Microsoft Corporation Intelligent metadata attribute resolution
US7426647B2 (en) * 2003-09-18 2008-09-16 Vulcan Portals Inc. Low power media player for an electronic device
JP2005101996A (ja) * 2003-09-25 2005-04-14 Toshiba Corp 情報記録媒体、情報記録方法、情報再生方法、情報記録装置、情報再生装置
EP2270796A3 (en) * 2003-11-10 2015-03-18 Panasonic Corporation Recording medium, playback apparatus, program, playback method, system integrated circuit
JP2005166228A (ja) * 2003-11-10 2005-06-23 Toshiba Corp 情報記録媒体、情報記録方法、情報再生方法、情報記録装置、情報再生装置
KR101008624B1 (ko) * 2003-12-11 2011-01-17 엘지전자 주식회사 고밀도 광디스크의 파일 구성방법 및 재생방법과기록재생장치
KR20050066264A (ko) * 2003-12-26 2005-06-30 엘지전자 주식회사 고밀도 광디스크의 메뉴 구성방법 및 실행방법과기록재생장치
US7765158B2 (en) * 2004-01-27 2010-07-27 Panasonic Corporation Playback apparatus and server apparatus
KR101089974B1 (ko) * 2004-01-29 2011-12-05 소니 주식회사 재생 장치, 재생 방법, 및 기록 매체
EP1730947A2 (en) * 2004-02-10 2006-12-13 LG Electronics Inc. Recording medium having a data structure for managing various data streams and recording and reproducing methods and apparatuses
US7551843B2 (en) * 2004-03-10 2009-06-23 Panasonic Corporation Authoring system, program, and authoring method
KR101058007B1 (ko) * 2004-05-18 2011-08-19 삼성전자주식회사 기록 매체에 저장된 데이터를 삭제하는 방법 및 삭제된데이터를 복원하는 방법
JP4214951B2 (ja) * 2004-05-21 2009-01-28 船井電機株式会社 記録再生装置
WO2006049476A2 (en) * 2004-11-08 2006-05-11 Lg Electronics Inc. Method and apparatus for reproducing data from recording medium using local storage
EP1817772A4 (en) * 2004-12-03 2010-01-06 Lg Electronics Inc METHOD AND DEVICE FOR ADMINISTERING DATA STORED IN A LOCAL MEMORY
JP4207922B2 (ja) * 2005-04-19 2009-01-14 ソニー株式会社 フリッカ補正方法、フリッカ補正装置及び撮像装置

Also Published As

Publication number Publication date
JP2011227990A (ja) 2011-11-10
KR101248305B1 (ko) 2013-03-27
CN101996664B (zh) 2012-11-28
CN101964914A (zh) 2011-02-02
CN101964914B (zh) 2015-10-14
KR20080031013A (ko) 2008-04-07
JP2011227989A (ja) 2011-11-10
EP1909281A4 (en) 2013-05-01
CN101996664A (zh) 2011-03-30
CN101228584B (zh) 2010-12-15
CN101228584A (zh) 2008-07-23
US20100284667A1 (en) 2010-11-11
EP1909281A1 (en) 2008-04-09
WO2007013378A1 (ja) 2007-02-01

Similar Documents

Publication Publication Date Title
JP5314097B2 (ja) 記録装置および情報記録方法
JP6541853B2 (ja) 再生装置及び再生方法
JP6840278B2 (ja) 再生装置、及び、再生方法
JP6227829B2 (ja) 再生装置および再生方法
JP6487588B2 (ja) 再生方法および再生装置
JP2019075819A (ja) デコーダシステムおよびデコード方法
JP6272533B2 (ja) 再生方法、および再生装置
WO2016038811A1 (ja) 記録媒体、再生装置、および再生方法
JP4827642B2 (ja) 記録装置、記録方法、プログラムおよび集積回路
WO2016021120A1 (ja) 再生装置、再生方法および記録媒体
JP2007048383A (ja) 情報記録媒体およびその記録装置、記録方法、記録プログラム
JP2007049461A (ja) 情報記録媒体、情報記録装置およびその方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20110802

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20121113

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20121120

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130118

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20130611

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130704

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

Ref document number: 5314097

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

S131 Request for trust registration of transfer of right

Free format text: JAPANESE INTERMEDIATE CODE: R313133

SZ02 Written request for trust registration

Free format text: JAPANESE INTERMEDIATE CODE: R313Z02

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250