JPWO2004095285A1 - 記録媒体およびこれを用いる記録装置並びに再生装置 - Google Patents
記録媒体およびこれを用いる記録装置並びに再生装置 Download PDFInfo
- Publication number
- JPWO2004095285A1 JPWO2004095285A1 JP2005505698A JP2005505698A JPWO2004095285A1 JP WO2004095285 A1 JPWO2004095285 A1 JP WO2004095285A1 JP 2005505698 A JP2005505698 A JP 2005505698A JP 2005505698 A JP2005505698 A JP 2005505698A JP WO2004095285 A1 JPWO2004095285 A1 JP WO2004095285A1
- Authority
- JP
- Japan
- Prior art keywords
- information
- file
- extended
- directory
- recording
- 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.)
- Withdrawn
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/7921—Processing of colour television signals in connection with recording for more than one processing mode
-
- 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
- G11B27/102—Programmed access in sequence to addressed parts of tracks of operating record carriers
- G11B27/105—Programmed access in sequence to addressed parts of tracks of operating record carriers of operating 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
- 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]
-
- 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/10527—Audio or video recording; Data buffering arrangements
- G11B2020/1062—Data buffering arrangements, e.g. recording or playback buffers
-
- 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
- G11B2220/216—Rewritable 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/2525—Magneto-optical [MO] 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
-
- 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
- G11B2220/2575—DVD-RAMs
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N5/00—Details of television systems
- H04N5/76—Television signal recording
- H04N5/765—Interface circuits between an apparatus for recording and another apparatus
- H04N5/77—Interface circuits between an apparatus for recording and another apparatus between a recording apparatus and a television camera
- H04N5/772—Interface circuits between an apparatus for recording and another apparatus between a recording apparatus and a television camera the recording apparatus and the television camera being placed in the same enclosure
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N5/00—Details of television systems
- H04N5/76—Television signal recording
- H04N5/765—Interface circuits between an apparatus for recording and another apparatus
- H04N5/775—Interface circuits between an apparatus for recording and another apparatus between a recording apparatus and a television receiver
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N5/00—Details of television systems
- H04N5/76—Television signal recording
- H04N5/78—Television signal recording using magnetic recording
- H04N5/781—Television signal recording using magnetic recording on disks or drums
-
- 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
- H04N5/00—Details of television systems
- H04N5/76—Television signal recording
- H04N5/907—Television signal recording using static stores, e.g. storage tubes or semiconductor memories
-
- 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
-
- 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
- H04N9/8047—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 using transform coding
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Management Or Editing Of Information On Record Carriers (AREA)
- Signal Processing For Digital Recording And Reproducing (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
記録媒体に情報の記録を行う記録部と、前記情報を、パス名により参照可能なディレクトリ階層構造を有したファイルシステム情報を用いてファイルとして管理するファイルシステム処理部と、ディレクトリ及びファイルを、コンテンツ管理情報を用いて管理するコンテンツ管理情報処理部と、ディレクトリ及びファイルに対する拡張情報を管理する拡張情報処理部とを備えた記録装置である。コンテンツ管理情報は、パス名を変換して得られるオブジェクト参照情報によりディレクトリ及びファイルを参照するメディアオブジェクト管理情報と、拡張情報を管理する拡張オブジェクト管理情報とを含み、ディレクトリ及びファイルと拡張情報とが、オブジェクト参照情報を経由して対応付けられている。
Description
本発明は、主に、記録装置、記録方法及び当該記録装置又は記録方法により記録された記録媒体並びに当該記録媒体を再生する再生装置及び再生方法に関する。特に、画像データや音声データを記録媒体にファイルとして記録する記録再生装置、記録再生方法及び当該記録再生装置又は記録再生方法により記録された記録媒体に関する。
近年、動画情報や静止画情報、音声情報等のAVデータをデジタル化して記録・再生することが良く行われている。このようなデジタル情報を蓄積する記録媒体としては、フラッシュメモリ等の半導体メモリ、あるいはディスクメディアであるDVD、ハードディスク、MD(ミニディスク)等が存在する。
これらの記録媒体に対して、MPEG2やJPEG等の符号化方式で符号化されたAVデータの記録や再生が行われている。かかるAVデータの記録において、各AVデータはファイルシステムによりファイルとして管理されており、それぞれの再生に際してもファイル単位での指定が行われている。
そして、上述した半導体メディアやディスクメディアにおいては、ランダムアクセス性という優れた特徴が存在する。ランダムアクセス性を利用することにより、ユーザからの指示等に従って、記録済みのファイルを任意の順番で再生することが可能となる。
さらにそれを発展させた技術として、プログラム再生機能の実現が挙げられる。例えば、特開2002−199335号公報に開示されている記録/再生システムにおいては、AVデータをメディアオブジェクトと呼ぶファイルとして記録し、複数のメディアオブジェクトをプログラムと呼ばれるディレクトリの下に記録している。このような記録形態とすることによって、記録媒体上には当該プログラムを複数個作成することが可能となる。
また、各プログラムに対してプログラム情報(PRG_INFO)と呼ばれる情報を管理し、メディアオブジェクトとは異なるファイルとして記録媒体上に記録する。PRG_INFOに登録されるメディアオブジェクトの情報を参照することにより、記録媒体上に記録されたAVファイルの再生順序を自由に制御することが可能となる。
上述したような機能は、一般に「プログラム再生」と呼ばれており、ディスクメディアにおけるランダムアクセス性を利用することにより実現されている。
このように、AVデータをメディアオブジェクトとして記録し、そのメディアオブジェクトを参照するプログラムもファイルとして記録する場合、当該プログラムファイルからメディアオブジェクトへの参照情報を持たなければならない。参照情報の形式は、ファイルに対するパス情報、すなわちファイルを管理するファイルシステム内で、当該ファイルの名前と階層位置を示す情報を用いるのが一般的である。
ここで、メディアオブジェクトとプログラムファイルとの関係の一例を図30に示す。図30は、メディアオブジェクトのディレクトリ構造と、プログラムファイルの構造の説明図である。
各プログラムファイル10002は、各メディアオブジェクト10001への参照を、ROOTディレクトリ10000からのフルパス名10003の形式で保持している。なお、図30に例示したフルパス名においては、パス区切り文字は”/”として記述している。
上述したメディアオブジェクトやプログラムファイルは、全てUDFやFAT等のファイルシステムを利用して管理される。ファイルシステムは、パーソナルコンピュータ(以下、「PC」という。)のアーキテクチャで一般的に利用され、ファイルシステムを導入することにより、上述のプログラムファイルを編集したり、再生したりするPC上のアプリケーションソフトを作成することが容易となる。
図30に示すように、プログラムファイル10002は、3つのメディアオブジェクト10001のプログラム再生を指示するものである。ここに示すように、複数のメディアオブジェクトがそれぞれ異なる親ディレクトリの下に記録されていてもプログラム再生を指示することが可能である。
また、半導体メディアやディスクメディアの異なる特徴として、データの追加と、それによる機能拡張の容易性が挙げられる。
特開2000−57745号公報や特開2001−160269号公報の記録再生装置では、図31に示すように、AVデータであるビットストリームファイル10010と、それを管理する情報ファイル10011が存在する。この情報ファイル10011に新たなデータ(製造業体情報項目10012)を追加していくことにより、この記録再生装置に対する新たな機能の追加が可能となる。
しかし、上述した構成のようなプログラムファイルによるプログラム再生を実現するためには、それを処理する記録または再生装置などに、追加のハードウエア及びソフトウエア資源が要求される。
よって、ハードウエア及びソフトウエア資源が限られる記録/再生装置では、その実現が不可能な場合がある。
そのため、メディアオブジェクトの単純な記録及び再生に関しては基本機能としてすべての記録/再生機器で実現されることが想定されるが、上述のようなプログラム再生機能は拡張機能として位置づけられ、ある機器では処理可能であるが、別の機器では処理不可能となるような場合がありうる。
このような場合においても、DVDのようなディスクメディアは、一つのディスクメディアが複数の記録/再生機器で記録または再生がされる。
そのため、プログラム再生のような拡張機能に対応しない機器でディスクメディア上の情報を操作(メディアオブジェクトの編集や削除など)した場合、メディアオブジェクトの情報とプログラムファイルとの情報の間に不整合が発生してしまう。
そして、このような不整合状態にあるディスクメディアを、プログラム再生に対応した記録/再生機器で再生しようとすると、プログラムファイルで参照しているはずのメディアオブジェクトが存在しないので、場合によっては機器の誤動作の発生や、最悪の場合は動作が停止してしまう等、の不都合が生じる。
このような不都合を回避するためには、ある拡張機能に対応した記録/再生機器は、その拡張機能を使用する前に、拡張機能に関するデータの整合性をすべて確認する必要があるが、このデータの量が多くなる(例えばプログラムファイルの数が非常に多なる)と、その確認処理に時間がかかり、ユーザにとって非常に不便である。
また、特開2000−57745号公報及び特開2001−160269号公報に記載されているような、情報ファイルに拡張機能のためのデータを追加していく構成においては、情報ファイルの容量増加が避けられない。
情報ファイルの基本的な部分は、すべての記録/再生装置で必要とされるが、拡張機能に関する部分は、その拡張機能に対応した機器にのみ必要なデータであり、拡張機能に対応しない機器にとっては無駄なデータであり、ハードウエア資源の浪費となってしまう。
これらの記録媒体に対して、MPEG2やJPEG等の符号化方式で符号化されたAVデータの記録や再生が行われている。かかるAVデータの記録において、各AVデータはファイルシステムによりファイルとして管理されており、それぞれの再生に際してもファイル単位での指定が行われている。
そして、上述した半導体メディアやディスクメディアにおいては、ランダムアクセス性という優れた特徴が存在する。ランダムアクセス性を利用することにより、ユーザからの指示等に従って、記録済みのファイルを任意の順番で再生することが可能となる。
さらにそれを発展させた技術として、プログラム再生機能の実現が挙げられる。例えば、特開2002−199335号公報に開示されている記録/再生システムにおいては、AVデータをメディアオブジェクトと呼ぶファイルとして記録し、複数のメディアオブジェクトをプログラムと呼ばれるディレクトリの下に記録している。このような記録形態とすることによって、記録媒体上には当該プログラムを複数個作成することが可能となる。
また、各プログラムに対してプログラム情報(PRG_INFO)と呼ばれる情報を管理し、メディアオブジェクトとは異なるファイルとして記録媒体上に記録する。PRG_INFOに登録されるメディアオブジェクトの情報を参照することにより、記録媒体上に記録されたAVファイルの再生順序を自由に制御することが可能となる。
上述したような機能は、一般に「プログラム再生」と呼ばれており、ディスクメディアにおけるランダムアクセス性を利用することにより実現されている。
このように、AVデータをメディアオブジェクトとして記録し、そのメディアオブジェクトを参照するプログラムもファイルとして記録する場合、当該プログラムファイルからメディアオブジェクトへの参照情報を持たなければならない。参照情報の形式は、ファイルに対するパス情報、すなわちファイルを管理するファイルシステム内で、当該ファイルの名前と階層位置を示す情報を用いるのが一般的である。
ここで、メディアオブジェクトとプログラムファイルとの関係の一例を図30に示す。図30は、メディアオブジェクトのディレクトリ構造と、プログラムファイルの構造の説明図である。
各プログラムファイル10002は、各メディアオブジェクト10001への参照を、ROOTディレクトリ10000からのフルパス名10003の形式で保持している。なお、図30に例示したフルパス名においては、パス区切り文字は”/”として記述している。
上述したメディアオブジェクトやプログラムファイルは、全てUDFやFAT等のファイルシステムを利用して管理される。ファイルシステムは、パーソナルコンピュータ(以下、「PC」という。)のアーキテクチャで一般的に利用され、ファイルシステムを導入することにより、上述のプログラムファイルを編集したり、再生したりするPC上のアプリケーションソフトを作成することが容易となる。
図30に示すように、プログラムファイル10002は、3つのメディアオブジェクト10001のプログラム再生を指示するものである。ここに示すように、複数のメディアオブジェクトがそれぞれ異なる親ディレクトリの下に記録されていてもプログラム再生を指示することが可能である。
また、半導体メディアやディスクメディアの異なる特徴として、データの追加と、それによる機能拡張の容易性が挙げられる。
特開2000−57745号公報や特開2001−160269号公報の記録再生装置では、図31に示すように、AVデータであるビットストリームファイル10010と、それを管理する情報ファイル10011が存在する。この情報ファイル10011に新たなデータ(製造業体情報項目10012)を追加していくことにより、この記録再生装置に対する新たな機能の追加が可能となる。
しかし、上述した構成のようなプログラムファイルによるプログラム再生を実現するためには、それを処理する記録または再生装置などに、追加のハードウエア及びソフトウエア資源が要求される。
よって、ハードウエア及びソフトウエア資源が限られる記録/再生装置では、その実現が不可能な場合がある。
そのため、メディアオブジェクトの単純な記録及び再生に関しては基本機能としてすべての記録/再生機器で実現されることが想定されるが、上述のようなプログラム再生機能は拡張機能として位置づけられ、ある機器では処理可能であるが、別の機器では処理不可能となるような場合がありうる。
このような場合においても、DVDのようなディスクメディアは、一つのディスクメディアが複数の記録/再生機器で記録または再生がされる。
そのため、プログラム再生のような拡張機能に対応しない機器でディスクメディア上の情報を操作(メディアオブジェクトの編集や削除など)した場合、メディアオブジェクトの情報とプログラムファイルとの情報の間に不整合が発生してしまう。
そして、このような不整合状態にあるディスクメディアを、プログラム再生に対応した記録/再生機器で再生しようとすると、プログラムファイルで参照しているはずのメディアオブジェクトが存在しないので、場合によっては機器の誤動作の発生や、最悪の場合は動作が停止してしまう等、の不都合が生じる。
このような不都合を回避するためには、ある拡張機能に対応した記録/再生機器は、その拡張機能を使用する前に、拡張機能に関するデータの整合性をすべて確認する必要があるが、このデータの量が多くなる(例えばプログラムファイルの数が非常に多なる)と、その確認処理に時間がかかり、ユーザにとって非常に不便である。
また、特開2000−57745号公報及び特開2001−160269号公報に記載されているような、情報ファイルに拡張機能のためのデータを追加していく構成においては、情報ファイルの容量増加が避けられない。
情報ファイルの基本的な部分は、すべての記録/再生装置で必要とされるが、拡張機能に関する部分は、その拡張機能に対応した機器にのみ必要なデータであり、拡張機能に対応しない機器にとっては無駄なデータであり、ハードウエア資源の浪費となってしまう。
本発明は、上述したような状況に鑑みてなされたものであり、拡張機能のためのデータ追加を効率的に行え、なおかつ、拡張機能に対応していない機器がメディアオブジェクトの編集や削除を行った場合にも、データ間の不整合を最小限に抑制し、適切なデータ処理方法を決定可能とする記録装置、記録方法及び当該記録装置又は記録方法により記録された記録媒体、並びに当該記録媒体を再生する再生装置及び再生方法を提供することを目的とする。
上記目的を達成するために本発明にかかる記録装置は、記録媒体に情報の記録を行う記録部と、前記情報を、パス名により参照可能なディレクトリ階層構造を有したファイルシステム情報を用いてファイルとして管理するファイルシステム処理部と、前記ディレクトリ及び前記ファイルを、コンテンツ管理情報を用いて管理するコンテンツ管理情報処理部と、前記ディレクトリ及び前記ファイルに対する拡張情報を管理する拡張情報処理部と、を備えた記録装置であって、前記コンテンツ管理情報は、前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、前記拡張情報を管理する拡張オブジェクト管理情報とを含み、前記ディレクトリ及び前記ファイルと前記拡張情報とが、前記オブジェクト参照情報を経由して対応付けられていることを特徴とする。
また、本発明にかかる記録装置は、前記拡張オブジェクト管理情報に、前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性に関する状態を管理する整合性状態管理情報を含み、前記ディレクトリ及び前記ファイルに対する操作を行う時、処理可能な種類の前記拡張情報については、前記拡張情報を更新し、処理不可能な種類の前記拡張情報については、前記拡張情報を更新せず、前記ディレクトリ及び前記ファイルと、前記拡張情報との整合性の状態に応じて前記整合性状態管理情報を更新することが好ましい。
また、本発明にかかる記録装置は、前記整合性状態管理情報が、前記メディアオブジェクト管理情報毎に設けられ、前記拡張情報の種別毎に、少なくとも、前記拡張情報から前記ディレクトリ及び前記ファイルへの参照関係の有無を示す情報と、前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性が保証されているか否かを示す情報を含むことが好ましい。
また、本発明にかかる記録装置は、前記コンテンツ管理情報に、第1の更新日時情報を含み、前記拡張情報には、第2の更新日時情報を含み、前記メディアオブジェクト管理情報を更新した時、前記第1の更新日時情報を更新し、処理可能な種類の前記拡張情報については、前記第2の更新日時情報に前記第1の更新日時情報と同じ値を設定し、処理不可能な種類の前記拡張情報については、前記第2の更新日時情報を更新しないことが好ましい。
また、本発明にかかる第1の再生装置は、上述した記録装置により記録された記録媒体から情報の再生を行う再生装置であって、前記情報を前記記録媒体から再生する再生部と、前記ファイルシステム情報を処理するファイルシステム処理部と、前記拡張情報を処理する拡張情報処理部と、前記コンテンツ管理情報を処理するコンテンツ管理情報処理部とを備え、前記拡張情報処理部は、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する時、前記整合性状態管理情報の設定値に従って前記拡張情報に対する処理手順を決定することを特徴とする。
また、本発明にかかる第2の再生装置は、上述した記録装置により記録された記録媒体から情報の再生を行う再生装置であって、前記情報を前記記録媒体から再生する再生部と、前記ファイルシステム情報を処理するファイルシステム処理部と、前記拡張情報を処理する拡張情報処理部と、前記コンテンツ管理情報を処理するコンテンツ管理情報処理部とを備え、前記拡張情報処理部は、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する時、前記第1の更新日時情報と前記第2の更新日時情報とが一致するかどうかで、前記拡張情報に対する処理手順を決定することを特徴とする。
かかる構成により、拡張機能のためのデータ追加を効率的に行え、なおかつ、拡張機能に対応していない機器がメディアオブジェクトの編集や削除を行った場合にも、データ間の不整合を最小限に抑制し、適切なデータ処理方法を決定可能となる。
また、本発明の他の側面は、記録媒体への情報の記録方法である。この記録方法は、記録媒体に、コンテンツ情報を、パス名により参照可能なディレクトリ階層構造を有するファイルシステム情報を用いて、ファイルとして記録する工程と、前記ディレクトリ及び前記ファイルを管理するコンテンツ管理情報を前記記録媒体へ記録する工程と、前記ディレクトリ及び前記ファイルに対する拡張情報を前記記録媒体へ記録する工程とを備えた記録方法であって、前記コンテンツ管理情報は、前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、前記拡張情報を管理する拡張オブジェクト管理情報とを含み、前記記録方法は、前記ディレクトリ及び前記ファイルと前記拡張情報とを前記オブジェクト情報を経由して対応付ける工程を含むことを特徴とする。
また、本発明のさらに他の側面は、記録媒体からの情報の再生方法である。第1の再生方法は、情報を前記記録媒体から再生する工程と、前記ファイルシステム情報を処理する工程と、前記拡張情報を処理する工程と、前記コンテンツ管理情報を処理する工程とを備え、前記拡張情報処理工程が、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する前に、前記整合性状態管理情報の設定値に従って前記拡張情報に対する処理手順を決定する工程を含むことを特徴とする。第2の再生方法は、情報を前記記録媒体から再生する工程と、前記ファイルシステム情報を処理する工程と、前記拡張情報を処理する工程と、前記コンテンツ管理情報を処理する工程とを備え、前記拡張情報処理工程が、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する前に、前記第1の更新日時情報と前記第2の更新日時情報とが一致するかどうかで、前記拡張情報に対する処理手順を決定する工程を含む。
また、本発明のさらに他の側面は記録媒体である。この記録媒体は、情報が記録された記録媒体であって、前記情報をパス名により参照可能なディレクトリ階層構造として管理するファイルシステム情報と、前記ディレクトリ及び前記ファイルを管理するコンテンツ管理情報と、前記ディレクトリ及び前記ファイルに対する拡張情報とが記録されており、前記コンテンツ管理情報は、前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、前記拡張情報を管理する拡張オブジェクト管理情報とを含み、前記ディレクトリ及び前記ファイルと前記拡張情報とが前記オブジェクト情報を経由して対応付けられていることを特徴とする。
また、本発明のさらに他の側面は、記録媒体へ情報の記録を行う記録装置において、当該記録装置の記録動作を制御するプログラムである。このプログラムは、記録媒体に、コンテンツ情報を、パス名により参照可能なディレクトリ階層構造を有するファイルシステム情報を用いて、ファイルとして記録する工程と、前記ディレクトリ及び前記ファイルを管理するコンテンツ管理情報を前記記録媒体へ記録する工程と、前記ディレクトリ及び前記ファイルに対する拡張情報を前記記録媒体へ記録する工程とを前記記録装置に実行させる命令を含み、前記コンテンツ管理情報は、前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、前記拡張情報を管理する拡張オブジェクト管理情報とを含み、前記プログラムは、前記ディレクトリ及び前記ファイルと前記拡張情報とを前記オブジェクト情報を経由して対応付ける工程を前記記録装置に実行させる命令をさらに含むことを特徴とする。
また、本発明のさらに他の側面は、記録媒体から情報の再生を行う再生装置において、当該再生装置の再生動作を制御するプログラムである。このプログラムは、前記情報を前記記録媒体から再生する工程と、前記ファイルシステム情報を処理する工程と、前記拡張情報を処理する工程と、前記コンテンツ管理情報を処理する工程とを前記再生装置に実行させる命令を含むと共に、前記拡張情報処理工程において、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する前に、前記整合性状態管理情報の設定値に従って前記拡張情報に対する処理手順を決定する工程を前記再生装置に実行させる命令を含むことを特徴とする。
また、本発明のさらに他の側面は、記録媒体から情報の再生を行う再生装置において、当該再生装置の再生動作を制御するプログラムである。このプログラムは、前記情報を前記記録媒体から再生する工程と、前記ファイルシステム情報を処理する工程と、前記拡張情報を処理する工程と、前記コンテンツ管理情報を処理する工程とを前記再生装置に実行させる命令を含むと共に、前記拡張情報処理工程において、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する前に、前記第1の更新日時情報と前記第2の更新日時情報とが一致するかどうかで、前記拡張情報に対する処理手順を決定する工程を前記再生装置に実行させる命令を含むことを特徴とする。
また、本発明のさらに他の側面は、上述のプログラムを、コンピュータによる読み取りが可能な媒体に記録したプログラム提供媒体(プログラム製品)である。
また、本発明のさらに他の側面は、記録媒体に記録されたデータ構造である。このデータ構造は、記録媒体に記録されたコンテンツ情報をパス名により参照可能なディレクトリ階層構造として管理するファイルシステム情報と、前記ディレクトリ及び前記ファイルを管理するコンテンツ管理情報と、前記ディレクトリ及び前記ファイルに対する拡張情報とを含み、前記コンテンツ管理情報は、前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、前記拡張情報を管理する拡張オブジェクト管理情報とを含み、前記ディレクトリ及び前記ファイルと前記拡張情報とが前記オブジェクト情報を経由して対応付けられていることを特徴とする。
上記目的を達成するために本発明にかかる記録装置は、記録媒体に情報の記録を行う記録部と、前記情報を、パス名により参照可能なディレクトリ階層構造を有したファイルシステム情報を用いてファイルとして管理するファイルシステム処理部と、前記ディレクトリ及び前記ファイルを、コンテンツ管理情報を用いて管理するコンテンツ管理情報処理部と、前記ディレクトリ及び前記ファイルに対する拡張情報を管理する拡張情報処理部と、を備えた記録装置であって、前記コンテンツ管理情報は、前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、前記拡張情報を管理する拡張オブジェクト管理情報とを含み、前記ディレクトリ及び前記ファイルと前記拡張情報とが、前記オブジェクト参照情報を経由して対応付けられていることを特徴とする。
また、本発明にかかる記録装置は、前記拡張オブジェクト管理情報に、前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性に関する状態を管理する整合性状態管理情報を含み、前記ディレクトリ及び前記ファイルに対する操作を行う時、処理可能な種類の前記拡張情報については、前記拡張情報を更新し、処理不可能な種類の前記拡張情報については、前記拡張情報を更新せず、前記ディレクトリ及び前記ファイルと、前記拡張情報との整合性の状態に応じて前記整合性状態管理情報を更新することが好ましい。
また、本発明にかかる記録装置は、前記整合性状態管理情報が、前記メディアオブジェクト管理情報毎に設けられ、前記拡張情報の種別毎に、少なくとも、前記拡張情報から前記ディレクトリ及び前記ファイルへの参照関係の有無を示す情報と、前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性が保証されているか否かを示す情報を含むことが好ましい。
また、本発明にかかる記録装置は、前記コンテンツ管理情報に、第1の更新日時情報を含み、前記拡張情報には、第2の更新日時情報を含み、前記メディアオブジェクト管理情報を更新した時、前記第1の更新日時情報を更新し、処理可能な種類の前記拡張情報については、前記第2の更新日時情報に前記第1の更新日時情報と同じ値を設定し、処理不可能な種類の前記拡張情報については、前記第2の更新日時情報を更新しないことが好ましい。
また、本発明にかかる第1の再生装置は、上述した記録装置により記録された記録媒体から情報の再生を行う再生装置であって、前記情報を前記記録媒体から再生する再生部と、前記ファイルシステム情報を処理するファイルシステム処理部と、前記拡張情報を処理する拡張情報処理部と、前記コンテンツ管理情報を処理するコンテンツ管理情報処理部とを備え、前記拡張情報処理部は、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する時、前記整合性状態管理情報の設定値に従って前記拡張情報に対する処理手順を決定することを特徴とする。
また、本発明にかかる第2の再生装置は、上述した記録装置により記録された記録媒体から情報の再生を行う再生装置であって、前記情報を前記記録媒体から再生する再生部と、前記ファイルシステム情報を処理するファイルシステム処理部と、前記拡張情報を処理する拡張情報処理部と、前記コンテンツ管理情報を処理するコンテンツ管理情報処理部とを備え、前記拡張情報処理部は、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する時、前記第1の更新日時情報と前記第2の更新日時情報とが一致するかどうかで、前記拡張情報に対する処理手順を決定することを特徴とする。
かかる構成により、拡張機能のためのデータ追加を効率的に行え、なおかつ、拡張機能に対応していない機器がメディアオブジェクトの編集や削除を行った場合にも、データ間の不整合を最小限に抑制し、適切なデータ処理方法を決定可能となる。
また、本発明の他の側面は、記録媒体への情報の記録方法である。この記録方法は、記録媒体に、コンテンツ情報を、パス名により参照可能なディレクトリ階層構造を有するファイルシステム情報を用いて、ファイルとして記録する工程と、前記ディレクトリ及び前記ファイルを管理するコンテンツ管理情報を前記記録媒体へ記録する工程と、前記ディレクトリ及び前記ファイルに対する拡張情報を前記記録媒体へ記録する工程とを備えた記録方法であって、前記コンテンツ管理情報は、前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、前記拡張情報を管理する拡張オブジェクト管理情報とを含み、前記記録方法は、前記ディレクトリ及び前記ファイルと前記拡張情報とを前記オブジェクト情報を経由して対応付ける工程を含むことを特徴とする。
また、本発明のさらに他の側面は、記録媒体からの情報の再生方法である。第1の再生方法は、情報を前記記録媒体から再生する工程と、前記ファイルシステム情報を処理する工程と、前記拡張情報を処理する工程と、前記コンテンツ管理情報を処理する工程とを備え、前記拡張情報処理工程が、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する前に、前記整合性状態管理情報の設定値に従って前記拡張情報に対する処理手順を決定する工程を含むことを特徴とする。第2の再生方法は、情報を前記記録媒体から再生する工程と、前記ファイルシステム情報を処理する工程と、前記拡張情報を処理する工程と、前記コンテンツ管理情報を処理する工程とを備え、前記拡張情報処理工程が、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する前に、前記第1の更新日時情報と前記第2の更新日時情報とが一致するかどうかで、前記拡張情報に対する処理手順を決定する工程を含む。
また、本発明のさらに他の側面は記録媒体である。この記録媒体は、情報が記録された記録媒体であって、前記情報をパス名により参照可能なディレクトリ階層構造として管理するファイルシステム情報と、前記ディレクトリ及び前記ファイルを管理するコンテンツ管理情報と、前記ディレクトリ及び前記ファイルに対する拡張情報とが記録されており、前記コンテンツ管理情報は、前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、前記拡張情報を管理する拡張オブジェクト管理情報とを含み、前記ディレクトリ及び前記ファイルと前記拡張情報とが前記オブジェクト情報を経由して対応付けられていることを特徴とする。
また、本発明のさらに他の側面は、記録媒体へ情報の記録を行う記録装置において、当該記録装置の記録動作を制御するプログラムである。このプログラムは、記録媒体に、コンテンツ情報を、パス名により参照可能なディレクトリ階層構造を有するファイルシステム情報を用いて、ファイルとして記録する工程と、前記ディレクトリ及び前記ファイルを管理するコンテンツ管理情報を前記記録媒体へ記録する工程と、前記ディレクトリ及び前記ファイルに対する拡張情報を前記記録媒体へ記録する工程とを前記記録装置に実行させる命令を含み、前記コンテンツ管理情報は、前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、前記拡張情報を管理する拡張オブジェクト管理情報とを含み、前記プログラムは、前記ディレクトリ及び前記ファイルと前記拡張情報とを前記オブジェクト情報を経由して対応付ける工程を前記記録装置に実行させる命令をさらに含むことを特徴とする。
また、本発明のさらに他の側面は、記録媒体から情報の再生を行う再生装置において、当該再生装置の再生動作を制御するプログラムである。このプログラムは、前記情報を前記記録媒体から再生する工程と、前記ファイルシステム情報を処理する工程と、前記拡張情報を処理する工程と、前記コンテンツ管理情報を処理する工程とを前記再生装置に実行させる命令を含むと共に、前記拡張情報処理工程において、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する前に、前記整合性状態管理情報の設定値に従って前記拡張情報に対する処理手順を決定する工程を前記再生装置に実行させる命令を含むことを特徴とする。
また、本発明のさらに他の側面は、記録媒体から情報の再生を行う再生装置において、当該再生装置の再生動作を制御するプログラムである。このプログラムは、前記情報を前記記録媒体から再生する工程と、前記ファイルシステム情報を処理する工程と、前記拡張情報を処理する工程と、前記コンテンツ管理情報を処理する工程とを前記再生装置に実行させる命令を含むと共に、前記拡張情報処理工程において、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する前に、前記第1の更新日時情報と前記第2の更新日時情報とが一致するかどうかで、前記拡張情報に対する処理手順を決定する工程を前記再生装置に実行させる命令を含むことを特徴とする。
また、本発明のさらに他の側面は、上述のプログラムを、コンピュータによる読み取りが可能な媒体に記録したプログラム提供媒体(プログラム製品)である。
また、本発明のさらに他の側面は、記録媒体に記録されたデータ構造である。このデータ構造は、記録媒体に記録されたコンテンツ情報をパス名により参照可能なディレクトリ階層構造として管理するファイルシステム情報と、前記ディレクトリ及び前記ファイルを管理するコンテンツ管理情報と、前記ディレクトリ及び前記ファイルに対する拡張情報とを含み、前記コンテンツ管理情報は、前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、前記拡張情報を管理する拡張オブジェクト管理情報とを含み、前記ディレクトリ及び前記ファイルと前記拡張情報とが前記オブジェクト情報を経由して対応付けられていることを特徴とする。
図1は、本発明の実施の形態1にかかる記録再生装置の外観と関連機器とのインタフェースの例示図である。
図2は、本発明の実施の形態1にかかる記録再生装置に組み込まれるドライブ装置110とその周辺の概略構成を示すブロック図である。
図3は、本発明の実施の形態1にかかる記録再生装置の構成の一例を示すブロック図である。
図4は、本発明の実施の形態1にかかる記録再生装置の構成の他の例を示すブロック図である。
図5は、本発明の実施の形態1にかかる記録再生装置の構成のさらに他の例を示すブロック図である。
図6は、本発明の実施の形態1にかかる記録再生装置の構成のさらに他の例を示すブロック図である。
図7(a)は、記録可能なディスクメディア100の記録領域を表した図である。図7(b)は、図7(a)において同心円状に示されるリードイン領域と、リードアウト領域と、データ領域を横方向に配置した説明図である。図7(c)は、論理セクタにより構成されるディスクメディア100の論理的なデータ空間を示す図である。
図8は、ディスクメディア100に記録されるディレクトリとファイルの階層構造を示す図である。
図9(a)は、UDF規格におけるディレクトリ階層を管理するためのデータ構造の例示図である。図9(b)は、UDF規格におけるディレクトリ階層を管理するためのデータ構造のパーティション空間内での配置の例示図である。
図10(a)は、UDF規格で定義されるファイルセットディスクリプタFSDのデータ構造の例示図である。図10(b)は、UDF規格で定義されるlong_adのデータ構造の例示図である。図10(c)は、UDF規格で定義されるADImpUseのデータ構造の例示図である。
図11(a)は、UDF規格で定義される拡張ファイルエントリのデータ構造の例示図である。図11(b)は、UDF規格で定義されるAllocation Descriptorのデータ構造の例示図である。図11(c)は、UDF規格で定義されるファイル識別記述子FIDのデータ構造の例示図である。
図12(a)は、UDF規格で定義されるImplementation Use Extended Attributeのデータ構造を示す図である。図12(b)は、Implementation Use2100中に格納される拡張属性のデータ構造を示す図である。
図13(a)は、ディスクメディア100上のアドレス空間を示す図である。図13(b)は、トラックバッファに蓄積してあるデータをデコーダへ供給することでAVデータの連続再生が可能になる時の状態を示した図である。
図14は、ディスクメディア100上に記録されるデータの階層構造と、それらを処理するシステム制御部104及びその内部構造を示す図である。
図15(a)は、本発明の実施の形態1にかかる記録再生装置におけるメディアオブジェクトマネージャ320のデータ構造の例示図である。図15(b)は、本発明の実施の形態1にかかる記録再生装置における拡張オブジェクト管理情報(EO_INFO)720のデータ構造の例示図である。図15(c)は、属性フラグ 724に設定される値の例示図である。
図16(a)は、本発明の実施の形態1にかかる記録再生装置におけるメディアオブジェクト管理情報(MO_INFO)700のデータ構造の例示図である。図16(b)は、MoType741に設定される値の例示図である。図16(c)は、OBJ_ID型のフィールドへ値を設定するときの変換規則の例示図である。
図17(a)は、本発明の実施の形態1にかかる記録再生装置におけるプログラムマネージャ330のデータ構造の例示図である。図17(b)は、本発明の実施の形態1にかかる記録再生装置におけるプログラム情報(PRG_INFO)800のデータ構造の例示図である。
図18は、ディレクトリ及びメディアオブジェクトとMO_INFO700との関係を示す図である。
図19は、メディアオブジェクトマネージャ320に対するプログラムマネージャ330の関係を示す図である。
図20は、本発明の実施の形態1におけるディレクトリ及びメディアオブジェクトとメディアオブジェクトマネージャ320と拡張オブジェクトの関係を示す図である。
図21(a)は、拡張オブジェクト管理情報テーブル710に設定される値の一例である。図21(b)は、拡張オブジェクト管理情報テーブル710に設定される値の他の例である。
図22は、本発明の実施の形態1にかかる記録再生装置における拡張情報の記録処理を示すフローチャートである。
図23は、本発明の実施の形態1にかかる記録再生装置における拡張情報の管理処理を示すフローチャートである。
図24は、本発明の実施の形態1にかかる記録再生装置における拡張情報の再生処理を示すフローチャートである。
図25は、本発明の実施の形態2におけるディレクトリ及びメディアオブジェクトとメディアオブジェクトマネージャ320と拡張オブジェクトの関係を示す図である。
図26(a)は、本発明の実施の形態2にかかる記録再生装置におけるメディアオブジェクト管理情報(MO_INFO)2000のデータ構造の例示図である。図26(b)は、本発明の実施の形態2にかかる記録再生装置における拡張オブジェクト管理情報(EO_INFO)2100のデータ構造の例示図である。
図27(a)は、本発明の実施の形態3にかかる記録再生装置におけるメディアオブジェクト管理情報(MO_INFO)3000のデータ構造の例示図である。図27(b)は、拡張データ属性フラグ3100に設定される値の例示図である。
図28は、本発明の実施の形態3にかかる記録再生装置における拡張データ属性フラグの管理処理を示すフローチャートである。
図29は、拡張データ属性フラグ3100に設定される値の例示図である。
図30は、従来のディレクトリ及びメディアオブジェクトとプログラムファイル10002との関係を示す図である。
図31は、従来のディレクトリ及びビットストリームファイルと情報ファイルとの関係を示す図である。
図2は、本発明の実施の形態1にかかる記録再生装置に組み込まれるドライブ装置110とその周辺の概略構成を示すブロック図である。
図3は、本発明の実施の形態1にかかる記録再生装置の構成の一例を示すブロック図である。
図4は、本発明の実施の形態1にかかる記録再生装置の構成の他の例を示すブロック図である。
図5は、本発明の実施の形態1にかかる記録再生装置の構成のさらに他の例を示すブロック図である。
図6は、本発明の実施の形態1にかかる記録再生装置の構成のさらに他の例を示すブロック図である。
図7(a)は、記録可能なディスクメディア100の記録領域を表した図である。図7(b)は、図7(a)において同心円状に示されるリードイン領域と、リードアウト領域と、データ領域を横方向に配置した説明図である。図7(c)は、論理セクタにより構成されるディスクメディア100の論理的なデータ空間を示す図である。
図8は、ディスクメディア100に記録されるディレクトリとファイルの階層構造を示す図である。
図9(a)は、UDF規格におけるディレクトリ階層を管理するためのデータ構造の例示図である。図9(b)は、UDF規格におけるディレクトリ階層を管理するためのデータ構造のパーティション空間内での配置の例示図である。
図10(a)は、UDF規格で定義されるファイルセットディスクリプタFSDのデータ構造の例示図である。図10(b)は、UDF規格で定義されるlong_adのデータ構造の例示図である。図10(c)は、UDF規格で定義されるADImpUseのデータ構造の例示図である。
図11(a)は、UDF規格で定義される拡張ファイルエントリのデータ構造の例示図である。図11(b)は、UDF規格で定義されるAllocation Descriptorのデータ構造の例示図である。図11(c)は、UDF規格で定義されるファイル識別記述子FIDのデータ構造の例示図である。
図12(a)は、UDF規格で定義されるImplementation Use Extended Attributeのデータ構造を示す図である。図12(b)は、Implementation Use2100中に格納される拡張属性のデータ構造を示す図である。
図13(a)は、ディスクメディア100上のアドレス空間を示す図である。図13(b)は、トラックバッファに蓄積してあるデータをデコーダへ供給することでAVデータの連続再生が可能になる時の状態を示した図である。
図14は、ディスクメディア100上に記録されるデータの階層構造と、それらを処理するシステム制御部104及びその内部構造を示す図である。
図15(a)は、本発明の実施の形態1にかかる記録再生装置におけるメディアオブジェクトマネージャ320のデータ構造の例示図である。図15(b)は、本発明の実施の形態1にかかる記録再生装置における拡張オブジェクト管理情報(EO_INFO)720のデータ構造の例示図である。図15(c)は、属性フラグ 724に設定される値の例示図である。
図16(a)は、本発明の実施の形態1にかかる記録再生装置におけるメディアオブジェクト管理情報(MO_INFO)700のデータ構造の例示図である。図16(b)は、MoType741に設定される値の例示図である。図16(c)は、OBJ_ID型のフィールドへ値を設定するときの変換規則の例示図である。
図17(a)は、本発明の実施の形態1にかかる記録再生装置におけるプログラムマネージャ330のデータ構造の例示図である。図17(b)は、本発明の実施の形態1にかかる記録再生装置におけるプログラム情報(PRG_INFO)800のデータ構造の例示図である。
図18は、ディレクトリ及びメディアオブジェクトとMO_INFO700との関係を示す図である。
図19は、メディアオブジェクトマネージャ320に対するプログラムマネージャ330の関係を示す図である。
図20は、本発明の実施の形態1におけるディレクトリ及びメディアオブジェクトとメディアオブジェクトマネージャ320と拡張オブジェクトの関係を示す図である。
図21(a)は、拡張オブジェクト管理情報テーブル710に設定される値の一例である。図21(b)は、拡張オブジェクト管理情報テーブル710に設定される値の他の例である。
図22は、本発明の実施の形態1にかかる記録再生装置における拡張情報の記録処理を示すフローチャートである。
図23は、本発明の実施の形態1にかかる記録再生装置における拡張情報の管理処理を示すフローチャートである。
図24は、本発明の実施の形態1にかかる記録再生装置における拡張情報の再生処理を示すフローチャートである。
図25は、本発明の実施の形態2におけるディレクトリ及びメディアオブジェクトとメディアオブジェクトマネージャ320と拡張オブジェクトの関係を示す図である。
図26(a)は、本発明の実施の形態2にかかる記録再生装置におけるメディアオブジェクト管理情報(MO_INFO)2000のデータ構造の例示図である。図26(b)は、本発明の実施の形態2にかかる記録再生装置における拡張オブジェクト管理情報(EO_INFO)2100のデータ構造の例示図である。
図27(a)は、本発明の実施の形態3にかかる記録再生装置におけるメディアオブジェクト管理情報(MO_INFO)3000のデータ構造の例示図である。図27(b)は、拡張データ属性フラグ3100に設定される値の例示図である。
図28は、本発明の実施の形態3にかかる記録再生装置における拡張データ属性フラグの管理処理を示すフローチャートである。
図29は、拡張データ属性フラグ3100に設定される値の例示図である。
図30は、従来のディレクトリ及びメディアオブジェクトとプログラムファイル10002との関係を示す図である。
図31は、従来のディレクトリ及びビットストリームファイルと情報ファイルとの関係を示す図である。
以下、本発明の実施の形態にかかる記録装置、記録方法及び当該記録装置又は記録方法により記録された記録媒体、並びに再生装置、再生方法について、図面を参照しながら説明する。
(実施の形態1)
図1は、本発明の実施の形態1にかかる記録再生装置の一例である、DVDレコーダの外観と、関連機器とのインタフェースを説明するための図である。図1に示すように、本発明にかかる記録再生装置の一実施形態としてのDVDレコーダ1は、記録媒体であるディスクメディアとしてDVDディスク2が装填され、ビデオ情報等の記録再生が行なわれる。DVDレコーダ1の操作は、一般的にはリモートコントローラ3や機器上のスイッチ(図示せず)によって行なわれる。
DVDレコーダ1に入力されるビデオ情報には、アナログ信号とデジタル信号の両者があり、アナログ信号としてはアナログ放送が、デジタル信号としてはデジタル放送がある。一般的に、アナログ放送は、テレビジョン装置4に内蔵されている受信機により受信、復調され、NTSC方式等のアナログビデオ信号としてDVDレコーダ1に入力される。
また、デジタル放送は、受信機であるセットトップボックス(STB)5でデジタル信号に復調され、DVDレコーダ1に入力され記録される。
一方、ビデオ情報が記録されたDVDディスク2は、DVDレコーダ1により再生され外部に出力される。出力される信号も入力される信号と同様に、アナログ信号とデジタル信号の両者があり、アナログ信号であれば直接テレビジョン装置4に入力され、デジタル信号であればSTB5を経由し、アナログ信号に変換された後にテレビジョン装置4に入力され、テレビジョン(TV)で映像として表示される。
さらに、本発明にかかる記録再生装置の他の実施形態として、DVDディスク2を利用する装置にDVDビデオカメラ6がある。DVDビデオカメラ6は、DVDレコーダにレンズやCCDからなるカメラ装置を組み合わせた装置であり、撮影した動画情報を符号化して記録する。
また、DVDディスク2は、DVDレコーダ1やDVDビデオカメラ6以外に、PC7等でビデオ情報が記録再生される場合もある。PC7等でビデオ情報が記録されたDVDディスク2であっても、DVDレコーダに装填されれば、DVDレコーダは当該DVDディスクを再生する。
なお、上述したアナログ放送やデジタル放送のビデオ情報には、通常、音声情報が付随している。付随している音声情報もビデオ情報と同様に、DVDレコーダで記録再生される。
また、ビデオ情報は、動画の他に、静止画の場合もある。例えば、DVDビデオカメラ6の写真機能で静止画が記録されたり、PC7上で他の記録装置(ハードディスク)等から静止画がDVDディスク2へコピーされたりする場合が該当する。
なお、DVDレコーダとSTB5等の外部機器との間のデジタルインタフェースとしては様々なインタフェースが考えられる。例えば、IEEE1394、ATAPI、SCSI、USB、等である。
また、上記では、DVDレコーダ1とテレビジョン(TV)4との間の信号として、NTSC方式のアナログ(コンポジット)ビデオ信号を用いる場合について例示したが、輝度信号と色差信号を個別に伝送するコンポーネント信号であってもよい。
さらには、AV機器とテレビジョンの間の映像伝送インタフェースとしては、アナログインタフェースをデジタルインタフェース、例えば、DVIに置きかえる研究開発が進められており、DVDレコーダとテレビジョンがデジタルインタフェースで接続されることも当然予想される。
このようなDVDレコーダ1やDVDビデオカメラ6等の記録再生装置において、記録媒体であるディスクメディア2は、複数の記録再生装置上で記録・再生される。この時の記録装置は同一の製造メーカの場合もあるし、異なる製造メーカによる記録装置の場合もあり得る。
様々な記録再生装置における記録・再生の互換性確保のため、記録媒体における記録フォーマットやファイルフォーマットの規格化・標準化が行われるのが一般的である。例えば、DVD−Video Recording規格等、様々な統一規格が策定されている。
記録再生装置の製造メーカは、ユーザの利便性に配慮して、統一規格に準拠した記録再生装置の製品化を行う。
その一方で、各製造メーカは、他社製品との差別化を図るべく、独自の拡張機能を自社製品に盛り込んで記録再生装置を製品化する場合が多く見られる。この拡張機能とは、統一規格には含まれておらず、各製造メーカが、その内容を独自に設けるさまざまな機能である。拡張機能の実現のために、図1には示していない追加のハードウエアやソフトウエア、周辺機器が必要に応じて記録再生装置に設けられる場合がある。例えば、位置情報を取得するGPSレシーバ、等である。
図2は、本実施の形態1にかかる記録再生装置に組み込まれるドライブ装置110とその周辺の概略構成を示すブロック図である。図2において、ドライブ装置110は、記録媒体に対して情報の記録再生を行う光ピックアップ101と、ECC(Error Correcting Code)処理部102を備え、例えばDVDディスクのような記録媒体であるディスクメディア100に対してデータの記録及び再生を行う。
ディスクメディア100には、セクタと呼ばれる最小単位でデータが記録される。また、複数のセクタで一つのECCブロックを構成し、ECCブロックを1単位としてECC処理部102でエラー訂正処理が施される。なお、ECCブロックはECCクラスタと呼ばれることもある。
ディスクメディア100の一例であるDVD−RAMディスクの場合、セクタのサイズは2KBであり、16セクタを1ECCブロックとして構成されている。当該セクタサイズは、ディスクメディア100の種類に応じて変動するものであり、1セクタは512B(バイト)であっても良いし、8KB等であっても良い。
また、ECCブロックについても、1セクタを1ECCブロックとして構成しても良いし、16セクタを、あるいは32セクタ等を1ECCブロックとして構成しても良い。今後、記録できる情報容量の増大に伴い、セクタサイズ及びECCブロックを構成するセクタ数は増大するものと予想される。
また、ドライブ装置110は、トラックバッファ103と接続されており、トラックバッファ103は、システムバス105を経由して記録再生装置のシステム全体を制御するシステム制御部104と接続されている。
トラックバッファ103は、ディスクメディア100にAVデータをより効率良く記録するため、AVデータを可変ビットレート(VBR)で記録するためのバッファである。ディスクメディア100への読み書きレート(Va)が固定レートであるのに対して、AVデータはその内容(ビデオであれば画像)の持つ複雑さに応じてビットレート(Vb)が変化する。トラックバッファ103は、このビットレートの差を吸収するためのバッファである。
図3は、ドライブ装置110を含む、本実施の形態1にかかる記録再生装置のブロック構成図である。図3に示すように、本実施の形態1にかかる記録再生装置は、システム全体の管理及び制御を司るシステム制御部104、ユーザへの表示及びユーザからの要求を受け付けるユーザI/F(インタフェース)部200、VHF及びUHFを受信するアナログ放送チューナ210、映像をAV信号へ変換するカメラ部211、デジタル放送を受信するデジタル放送チューナ212、AV信号入力をデジタル信号に変換し、MPEGプログラムストリーム等にエンコードする動画エンコーダ221、AV信号入力をJPEGストリーム等にエンコードする静止画エンコーダ222、デジタル放送で送られるMPEGトランスポートストリームを解析する解析部223、MPEG等の動画データをデコードする動画デコーダ240、静止画データをデコードする静止画デコーダ241、テレビ及びスピーカ等の表示部250、等を備えている。
動画エンコーダ221、静止画エンコーダ222や解析部223には、AVデータの入力源として、アナログ放送チューナ210、カメラ部211、デジタル放送チューナ212等が接続されている。
なお、上述したエンコーダやチューナ、カメラ部については、全てを同時に備える必要はなく、記録再生装置の使用目的に応じて必要なものだけを備えれば良い。例えば、記録再生装置がDVD等の光ディスク用レコーダの場合であれば、図4に示すように、図3に示した構成のうち、カメラ部211を省いた構成としても良い。また、記録再生装置がビデオカメラの場合であれば、図5に示すように、図3に示した構成のうち、アナログ放送チューナ210およびデジタル放送チューナ212を省き、集音用のマイク部261をさらに備えた構成としても良い。また、記録再生装置がパーソナルコンピュータの場合であれば、図4と同様の構成としても良い。あるいは、図6に示すように、図3に示した構成のうち、アナログ放送チューナ210、カメラ部211、およびデジタル放送チューナ212を省いた構成としても良い。
さらに、図3に示す記録再生装置は、図2で示したように、書き込みデータを一時的に格納するトラックバッファ103と、ディスクメディア100にデータを書き込むドライブ装置110とを備えている。
また、IEEE1394やUSB等の通信手段により外部機器にデータを出力するインタフェースであるデジタルI/F(インタフェース)部230を備えても良い。
なお、本実施の形態1にかかる記録再生装置の詳しい動作については後ほど説明を行う。
次に、図7は、本実施の形態1にかかる記録再生装置において記録可能なディスクメディア100の外観と物理構造を表した図である。なお、例えばDVD−RAMのようなディスクメディアは、記録面を保護するのを目的として、カートリッジに収納された状態で記録再生装置に装填される。ただし、記録面の保護が別の構成で行なわれたり、容認できる場合にはカートリッジに収納せずに、記録再生装置に直接装填できるようにしてもよい。
図7(a)は、記録可能なディスクメディア100の記録領域の一例を示した図である。図7(a)の例では、最内周にリードイン領域141が、最外周にリードアウト領域142が、その間にデータ領域143が配置されている。リードイン領域141は、光ピックアップ101がディスクメディア100へアクセスする時に、サーボを安定させるために必要な基準信号や他のメディアとの識別信号等が記録されている。リードアウト領域142もリードイン領域141と同様の基準信号等が記録されている。またデータ領域143は、最小のアクセス単位であるセクタに分割されている。
図7(b)は、図7(a)において同心円状に示されているリードイン領域141と、リードアウト領域142と、データ領域143を横方向に配置した説明図である。
リードイン領域141とリードアウト領域142は、その内部に欠陥管理領域(DMA:Defect Management Area)144,147を有する。欠陥管理領域とは、欠陥が生じたセクタの位置を示す位置情報と、その欠陥セクタを交替するセクタが後述する交替領域のいずれに存在するかを示す交替位置情報とが記録されている領域をいう。
また、データ領域143は、その内部に交替領域145とユーザ領域146を有している。交替領域145は、欠陥セクタが存在する場合に代替セクタとして使用される領域である。ユーザ領域146は、ファイルシステムが記録用領域として利用することができる領域をいう。なお、ディスクメディアの種類によっては交替領域を持たないディスクメディアも存在し、この場合、必要に応じて、後述するUDF等のファイルシステムにおいて、欠陥セクタの交替処理を行う場合もある。
データ領域143にある各セクタへアクセスするため、内周から順に物理セクタ番号(PSN:Physical Sector Number)をデータ領域へ割り当てることが一般に行われている。PSNによって管理されるセクタを物理セクタと呼ぶ。
また、データ記録に使用されるセクタのみを連続的に示すように、内周から順に論理セクタ番号LSN(Logical Sector Number)をユーザ領域の物理セクタに割り当てることも行われる。LSNによって管理されるセクタを論理セクタと呼ぶ。
図7(c)は、図7(b)のユーザ領域146内で、論理セクタにより構成される論理的なデータ空間を示す図である。論理的なデータ空間は、ボリューム空間と呼称され、ユーザデータを記録する。ボリューム空間においては、記録データをファイルシステムで管理する。
DVD−RAM等のディスクメディアでは、ファイルシステムは、UDFと呼称され、ECMA167及びISO13346規格に準拠したものが一般的に使用される。
UDFのパーティション空間292では、データアクセスの単位ごとに論理ブロック番号LBN(Logical Block Number)が割り当てられ、データの配置や管理が行われる。
データの配置のために、パーティション空間292で連続的に配置される1群のセクタはエクステントと呼ばれる単位で管理され、さらに関連のあるエクステントの集合がファイルとして管理される。
エクステント及びエクステントの集合であるファイルを管理する情報制御ブロック(ICB)であるファイルエントリ(FE)及び拡張ファイルエントリ(EFE)と呼ばれる構造、さらには1群のファイルをディレクトリとして管理するための情報であるファイル識別記述子(FID)等がボリューム空間内のパーティション空間内に記録される。
そして、パーティション空間等を管理するためのボリューム構造情報290(及びそのバックアップである291)が、ボリューム領域の先頭と終端に記録される。
図8は、本発明の実施の形態1にかかる記録再生装置により記録されるディスクメディア100におけるディレクトリとファイルの階層構造の一例を示す図である。図8に示すように、ROOTディレクトリ300の下に、階層化されたサブディレクトリ(301〜305等)があり、さらにその階層下に、動画データや静止画データを含むファイルである各種メディアオブジェクト(310〜313等)や、各メディアオブジェクトを管理するためのファイルであるメディアオブジェクトマネージャ320(ファイル名:MOI_MGR)や、複数のメディアオブジェクトをグループ化し、再生順序や分類情報を管理するプログラムマネージャ330(ファイル名:PRGM0001.EXT)等が格納されている。
ここでプログラムマネージャ330は拡張情報を格納する拡張オブジェクトの一種であり、プログラム再生機能に対応した記録再生装置がその記録及び再生等の処理を行う。
なお、本実施の形態においてはメディアオブジェクトマネージャ320の構造や機能は統一規格の一種であるとし、全ての本発明の記録再生装置において記録や再生が保証されるものとする。
また、拡張情報とは、統一規格に含まれない拡張機能を製造メーカが独自に実現する上で必要な様々な情報のことである。拡張情報は拡張オブジェクトと呼ばれるファイルに格納されてディスクメディア100に記録される。上述の、プログラム再生機能は拡張機能の一例である。
本実施の形態1においては、記録及び再生用の対象となるAVデータを含む各種メディアオブジェクトのディレクトリ階層やファイル名は、後述するDCF規格及びそれに類した形式を利用して以降の説明を行う。ただし、ディレクトリ階層やファイル名の命名則はこれに限られるものではなく、他の命名則を用いても良い。
メディアオブジェクトのうち、MPEG2等の動画データを含む動画オブジェクトは、ABCDnnnn.MPGというように、最初の4文字が任意のアルファベット文字の組み合わせであり、次のnnnnが10進数であるような命名側に従って動画ファイルとして記録される。動画ファイルは、MPEG2方式やMPEG4方式等で圧縮されたAVデータを含んでおり、プログラムストリーム(PS)や、トランスポートストリーム(TS)、あるいは他の形式のファイルとして記録される。
また、各々の動画ファイルに関する属性情報は、属性情報ファイル(ファイル名:ABCDnnnn.MOI)に記録される。属性情報ファイルには、それぞれの動画ファイルの識別情報、記録された日時、動画データの代表画像(サムネイルピクチャ)、動画データの再生時刻をディスクメディア100上の論理アドレスに変換するためのアクセスマップ情報及びその管理情報、等を有している。アクセスマップ情報を持つことにより、動画データの持つ時間軸とデータ(ビット列)軸との間の変換を行うことが可能となり、動画データに対する時間軸を基準にしたランダムアクセスが可能となる。
属性情報ファイルは、例えばApple社のQuickTimeファイルフォーマットに準拠する形式でもよい。QuickTimeファイルフォーマットでは、前記属性情報は、ムービーリソース(movieresource)と呼ばれる。また同様に、前記アクセスマップ情報は、サンプルテーブル(Sample Table)と呼ばれる。
一つの動画オブジェクトは、一つの属性情報ファイルと一つ又はそれ以上の動画ファイルとで構成され、それらはファイル名により関連づけられるものとする。すなわち、関連のある属性情報ファイルと動画ファイルは、そのファイル名において拡張子を除く部分、例えば動画オブジェクト310では、動画ファイル311と属性情報ファイル312が”ABCD0001”の部分が同一に設定されることによって、その関連付けがなされていることとする。
ただし、属性情報ファイルと動画ファイルの関連付けは上述の方法に限定されるものではなく、属性情報ファイル内に関連付けられた動画ファイルへのリンク情報、例えば動画ファイルへのパス名等を保持したり、両者の対応付けをテーブル情報として保持したりする等、他の方法であっても良い。なお、一つの動画オブジェクトに、一つの属性情報ファイルと一つ又はそれ以上の動画ファイル以外を含むようにしてもよい。また、属性情報ファイルと動画ファイルを一体として、1つのファイルで動画オブジェクトを構成するようにしてもよい。
メディアオブジェクトのうち、JPEG等の静止画データを含む静止画オブジェクトは、各々の静止画情報が静止画ファイル(ファイル名:ABCDnnnn.JPG)等として記録される。静止画ファイルは、JPEG方式等で圧縮された映像データであり、例えば、DCFフォーマットやExifフォーマットによりファイルとして記録される。
上記のメディアオブジェクトは、DCF規格あるいはそれに類するディレクトリ構造にしたがって記録される。すなわち、ROOTディレクトリ300の下にDCFイメージルートディレクトリ302(ディレクトリ名:DCIM)があり、さらにその下に静止画ファイルを格納するためのDCFディレクトリ305がある。(ディレクトリ名:300ABCDE)。そして、DCFディレクトリ305の下に静止画オブジェクトの一種であるDCF基本ファイル313(例えば、ファイル名:ABCD0001.JPG)が格納される。
また、ROOTディレクトリ300の下にVIDEOイメージルートディレクトリ301(ディレクトリ名:VIDEO)があり、さらにその下に、主に動画オブジェクトを格納するためのVIDEOディレクトリ304がある。(例えば、ディレクトリ名:100ABCDE)。そして、VIDEOディレクトリ304下に、動画オブジェクト310を構成する属性情報ファイル312(拡張子がMOIであるファイル)と動画ファイル311(拡張子がMPGであるファイル)が格納される。
なお、メディアオブジェクトとして、AC−3やAAC等による圧縮音声ファイルや非圧縮の音声ファイル、MotionJPEGファイル、DCF規格で定められたDCF拡張画像ファイル、DCFサムネイルファイル、PNGファイル等、他のファイルフォーマットのAVファイルを記録してもよい。
記録されたメディアオブジェクトを管理するコンテンツ管理情報は、管理データディレクトリ303(ディレクトリ名:INFO)下のメディアオブジェクトマネージャファイル320として記録される。
また、メディアオブジェクトに対して拡張情報を付加する拡張オブジェクトも管理データディレクトリ303に記録される。図8では、拡張オブジェクトの例として、プログラムマネージャファイル330が記録されている。なお、メディアオブジェクトマネージャファイル320及び拡張オブジェクトの記録位置は管理データディレクトリ303下に限られるものではなく、例えば、VIDEOイメージルートディレクトリ301下、等でもよい。メディアオブジェクトマネージャファイル320及びプログラムマネージャファイル330の構造については後述する。
次に、図9、図10及び図11を用いて、本実施の形態1にかかる記録再生装置で用いられるディスクメディア上でデータをファイルとして管理する、UDFファイルシステムの構造を説明する。
図9は、UDFファイルシステムにおけるディレクトリ階層を管理するためのデータ構造を示す図である。なお、図9は、図8に示したディレクトリ階層構造に対応しているが、そのうちROOTディレクトリ300から属性情報ファイル312へ至るまでのファイルシステム情報のみを示しており、他のディレクトリやファイルに対する同様の情報については、説明を簡単にするため省略している。
ディレクトリ階層構造の起点はファイルセットディスクリプタ(FSD:File Set Descriptor)400である。FSD400は、図10(a)に示されるデータ構造を有している。FSD400は、拡張ファイルエントリ(EFE:Extended File Entry)510への参照情報401(ディスクメディア100上での記録位置)をRoot Directory ICB501の値として保持している。また、FSD400は、System Stream Directory ICB502からNamed Streamと呼ばれるデータを参照可能である。
Root Directory ICB501及びSystem Stream Directory ICB502は、図10(b)に示すlong_ad503という構造を持つ。long_ad503は、参照先のエクステントの長さ(Extent Length)と、位置(Extent Location)を保持する。さらに、Implementation Use504には、図10(c)に示すADImpUseの形式によりUDF UniqueID505と呼ばれる値が保持される。
また、EFE510は、図11(a)に示される構造を有している。EFE510は、ディスクメディア100上に記録された各ディレクトリやファイルを構成するエクステントの集合を管理するための構造体であり、各エクステントのディスクメディア100上での記録位置とデータ長を管理するため、図11(b)に示す構造を有するアロケーション記述子(AD:Allocation Descriptor)514と呼ばれる構造を含んでいる。各ディレクトリやファイルは複数のエクステントから構成されるので、EFE510には複数のAD514が含まれる。
その他にも、EFE510には、図11(a)に示すように、データの種別を表すディスクリプタタグ(Descriptor Tag)や、各ディレクトリやファイルごとに、ディスクメディア100上で重複しない一意のID値を設定するUnique ID511、EFE510ごとの拡張属性を設定可能なStream Directory ICB512や、拡張属性(EAs; Extended Attributes)513等が含まれる。
EAs513は、UDFファイルシステムで規定される拡張属性を格納するための領域であり、ECMA167規格等で定められた拡張属性データや、様々なアプリケーションシステム等が必要に応じて使用できる。EAs513中には、属性タイプ(Attribute Type)や属性サブタイプ(Attribute Subtype)と呼ばれるフィールドが存在し、ここに適切な値を設定することにより、この拡張属性中に含まれるデータの種別を識別できるようになっている。特定の属性タイプや属性サブタイプの値とそれに対応するデータ構造がECMA167規格等ですでに定義されている。
図12(a)に、EAs513に含まれる拡張属性データの一種で、任意のアプリケーションシステムが使用可能な処理システム用拡張属性(Implementation Use Extended Attribute)530と呼ばれる構造を示す。
アプリケーションシステムがこの処理システム用拡張属性530を使用する時には、Attribute Type、Attribute Subtype及びImplementation Identifierの各フィールドに適切な値を設定することにより、処理システム用拡張属性530中に含まれる拡張属性が、どんなアプリケーションシステムにより使用されるかを識別できるようになっている。
そして、実際の拡張属性の値は、Implementation Use Length(IU_L)でデータ長が示される可変長のフィールドImplementation Use531中に格納される。Implementation Use531中に格納される拡張属性のデータ構造は、それを使用するアプリケーションごとに決められる。
本実施の形態においてImplementation Use531中に格納される拡張属性のデータの一例として、Media Object Management Information540の構造を、図12(b)に示す。ここでは、Mo(Media Object)Unique ID541というフィールドが設けられている。本フィールドの利用例については後述する。
ROOTディレクトリ300等のディレクトリデータを含むエクステント420(図9(a)参照)は、各ディレクトリやファイルのファイル名を保持するファイル識別記述子FID(File Identifier Descriptor)520で構成される。あるディレクトリ下にサブディレクトリやファイルが存在する場合、それぞれのディレクトリ又はファイルに対してFID520が保持される。
例えば、図8によれば、ROOTディレクトリ300の下にはVIDEOイメージルートディレクトリ301とDCIMイメージルートディレクトリ302があるので、図9(a)に示すように、ROOTディレクトリ300のエクステント420には、各々に対応するFID421及び422が保持されている。
FID520は、図11(c)に示される構造を持つ。FID520は、UDF上で管理される各ディレクトリやファイルの名前(ファイル識別子)をファイル識別子(File Identifier)521として保持する。FID520はさらに、対応するディレクトリ又はファイルの実データを管理するEFE510への参照情報(例えば図9(a)の430)を、ICB522として保持する。
そのほかにも、FID520には、データの種別を表すディスクリプタタグ(Descriptor Tag)や、ファイル識別子521のデータ長を表すファイル識別子長さ(Length of File Identifier)等が含まれる。
以降、同様にEFE510とFID520の参照関係を保持することによりディレクトリの階層構造が管理され、この参照関係を順次たどることによって、任意のディレクトリやファイルの実データであるエクステントへアクセスすることが可能となる。
ファイルに関しても、EFE510によりエクステントの集合が管理される。図9の場合、エクステントの集合442がファイルを構成し、これは図8における属性情報ファイル312に相当する。
上記のFSD400やEFE510、FID520は、パーティション空間292内に配置される。図9(b)は、図9(a)のデータ構造のパーティション空間内での配置の例示図である。ここで、図9(a)と図9(b)で同じデータに関しては同じ番号を付与している。
エクステント442へアクセスするためには、FSD400から順にEFE510、FID520、・・・、EFE440のように、順次、データへアクセスする。
上述のような階層構造を持ったファイルシステムにおいて、特定のディレクトリやファイルを参照するために、パス名が利用できる。パス名は、例えば、図9のエクステント442(ファイル名:ABCD0001.MOI)に対しては、”/VIDEO/100ABCDE/ABCD0001.MOI”のように表される。ここでは、ROOTディレクトリ300及びパス区切り文字を”/”で表している。
このように、パス名は、ROOTディレクトリ300から、対象のディレクトリやファイルにたどり着くまでディレクトリ階層をたどっていく時、その経路上に存在するディレクトリの名前(ファイル識別子521に格納されている情報)を、パス区切り文字で区切りながら一続きに記述したものである。このパス名を利用すれば、ファイルシステム上で管理される任意のディレクトリやファイルを参照することが可能となる。
次に、ディスクメディア100へ記録を行なう、本実施の形態にかかる記録再生装置の動作について説明する。
まず、図13を用いて、ディスクメディア100上でのAVデータの分散配置について説明する。すなわち、図2に示すようなシステムにおいて、トラックバッファ103を有効利用することによって、AVデータを離散配置することが可能になる。
図13(a)は、ディスクメディア100上のアドレス空間を示す図である。図13(a)においては、左端がアドレス値が0の点であり、右に向かってアドレス値が増加していくものとしている。また、’0’、a1〜a4は、その位置におけるアドレス値を示している。
図13(a)に示されるように、AVデータが[a1、a2]の連続領域A1と[a3、a4]の連続領域A2に分かれて記録されている場合、光ピックアップ101がa2からa3へシーク動作を行なっている間、トラックバッファ103に蓄積してあるデータを動画デコーダ240へ供給することでAVデータの連続再生が可能になる。
この時のトラックバッファ103内のデータ蓄積量の状態を示したのが、図13(b)である。位置a1で読み出しが開始されたAVデータは、時刻t1からトラックバッファ103に入力されると共に、トラックバッファ103からデータの出力が開始される。これにより、トラックバッファ103への入力レート(Va)とトラックバッファ103からの出力レート(Vb)のレート差(Va−Vb)の分だけトラックバッファ103にデータが蓄積されていく。この状態が、光ピックアップ101がa2に達するまで、すなわち時刻t2に達するまで継続する。
この間にトラックバッファ103に蓄積されたデータ量をB(t2)とすると、時間t2から、位置a3のデータの読み出しを開始する時刻t3までの間、トラックバッファ103に蓄積されているデータ量B(t2)を消費して動画デコーダ240へ供給し続けられれば良い。
換言すると、シーク前に読み出すデータ量([a1、a2])が一定量以上確保されていれば、シークが発生した場合であっても、AVデータの連続供給が可能となる。
AVデータの連続供給が可能な連続領域のサイズは、ECCブロック数N_eccに換算すると、(数1)のように求められる。(数1)において、N_secはECCブロックを構成するセクタ数であり、S_sizeはセクタサイズ、Tjはシーク性能(最大シーク時間)である。
また、連続領域の中には欠陥セクタが生じる場合がある。この場合を考慮すると、AVデータの連続供給が可能な連続領域のサイズは(数2)のように求められる。(数2)において、dN_eccは容認する欠陥セクタのサイズであり、Tsは連続領域の中で欠陥セクタをスキップするのに要する時間である。
なお、本実施の形態1においては、ディスクメディア100からデータを読み出す場合、すなわち再生の場合について説明しているが、ディスクメディア100へデータを書き込む場合、すなわち記録又は録画の場合も同様に考えることができる。
上述したように、ディスクメディア100では、一定量以上のデータが連続記録されていれば、ディスク上にAVデータを分散記録しても連続再生が可能である。なお、例えばDVDでは、この連続領域をCDAと呼称する。あるいは、AVデータを記録する特別なエクステントであることから、AVエクステントと呼ばれることもある。
次に、図3を用いて、本実施の形態1にかかる記録再生装置の動作について説明する。図3に示した記録再生装置においては、例えばユーザI/F部200がユーザからの要求を受け付けた場合に動作を開始する。
ユーザI/F部200は、ユーザからの要求をシステム制御部104に伝え、システム制御部104は、ユーザからの要求を解釈すると共に各モジュールへの処理要求を行なう。
以下、アナログ放送をMPEG−2 PSにエンコードして動画オブジェクトとして記録する動作を例に挙げて説明する。
システム制御部104は、アナログ放送チューナ210への受信と動画エンコーダ221へのエンコードを要求する。動画エンコーダ221は、アナログ放送チューナ210から送られてくるAV信号を、ビデオエンコード、オーディオエンコード及びシステムエンコードしてトラックバッファ103に送出する。動画エンコーダ221は、エンコード開始後、アクセスマップ情報等を作成するために必要な情報をエンコード処理と平行してシステム制御部104に送る。
次に、システム制御部104は、ドライブ装置110に対して記録要求を出し、ドライブ装置110は、トラックバッファ103に蓄積されているデータを取り出してディスクメディア100に記録する。この際、前述した連続領域であるCDAをディスク上の記録可能領域から検索し、見つかったCDAにデータを記録していく。
この時、CDAとして記録可能な領域の検索は、UDF等のファイルシステムが管理する空き領域情報、例えば、スペースビットマップディスクリプタ(Space Bitmap Descriptor)に基づいて実行される。
録画終了は、ユーザからのストップ要求によって指示される。ユーザからの録画停止要求は、ユーザI/F部200を通してシステム制御部104に伝えられ、システム制御部104は、アナログ放送チューナ210と動画エンコーダ221に対して停止要求を出す。動画エンコーダ221は、システム制御部104からのエンコード停止要求を受けてエンコード処理を終了する。
システム制御部104は、エンコード処理終了後、動画エンコーダ221から受け取った情報に基づいて、アクセスマップ情報とその管理情報、等を含む属性情報を生成する。
次に、システム制御部104は、ドライブ装置110に対してトラックバッファ103に蓄積されているデータの記録終了と属性情報の記録を要求し、ドライブ装置110が、トラックバッファ103の残りデータと、属性情報を属性情報ファイル、例えば、図9に示す動画オブジェクトを構成しているファイルであるABCD0001.MOIとしてディスクメディア100に記録し、動画オブジェクトの録画処理を終了する。
なお、上記のほかに、システム制御部104は、図10や図11、図12で説明したようなUDFファイルシステムの情報を必要に応じて生成したり更新したりする。すなわち、動画オブジェクトを構成するファイルに対して、EFE510やFID520を生成し、必要な情報を設定した上でディスクメディア100上に記録する。
記録再生装置がビデオカメラである場合は、図5を参照して説明したように、AV信号源がアナログ放送チューナ210ではなくカメラ部211へ変わるだけで、他の処理は同様である。
また、デジタル放送を動画オブジェクトとして記録する動作には、動画データのエンコードは行わず、デジタル放送チューナ212及び解析部223を通じてMPEG2 TSのデータをディスクメディア100へ動画オブジェクトとして記録するようシステム制御部104が制御を行う。このとき、上述と同様に、ファイルシステム情報の記録も行われる。
次に、静止画オブジェクトの記録に関して、カメラ部211から送られてくるAV信号をJPEGエンコードして記録する動作について説明する。
システム制御部104は、カメラ部211へAV信号の出力を、静止画エンコーダ222へAV信号のエンコード実施を要求する。静止画エンコーダ222は、カメラ部211から送られるAV信号をJPEGエンコードし、トラックバッファ103に送出する。
ドライブ装置110は、システム制御部104からの指示を受けながら、トラックバッファ103に蓄積されているデータをディスクメディア100に記録する。この時、データの記録可能領域の検索は、UDF等のファイルシステムが管理する空き領域情報をもとに実行される。
一つの静止画オブジェクトが記録されたら撮影は終了する。あるいは、ユーザから連続撮影の指示があった場合は、ユーザからの撮影停止要求によって終了するか、所定の枚数の静止画オブジェクトを記録して終了する。ユーザからの撮影停止要求は、ユーザI/F部200を通してシステム制御部104に伝えられ、システム制御部104はカメラ部211と静止画エンコーダ222に対して停止要求を出す。
さらに、システム制御部104は、UDFファイルシステムの情報についても必要な処理を行う。すなわち、静止画オブジェクトを構成するファイルに対して、EFE510やFID520等を生成し、必要な情報を設定した上でディスクメディア100上に記録する。
以上のような手順でディスクメディア100に記録される各メディアオブジェクトは、後々の管理のために、図8で示したメディアオブジェクトマネージ320に登録される。各メディアオブジェクトとメディアオブジェクトマネージ320との関係については後述する。なお、本発明においてはEFE510を用いて説明を行っているが、その代わりにFEを用いてもかまわない。
図14は、本実施の形態1における記録再生装置で用いられるディスクメディア100上に記録されるデータの階層構造と、それらを処理するシステム制御部104及びその内部構造の一例を示す図である。
ディスクメディア100上にはファイルシステム情報600が記録される。ファイルシステム情報600には、図7(c)で示したボリューム構造情報290や、図10、図11及び図12で示したFSD400、EFE510、FID520、また上述したスペースビットマップディスクリプタ(Space Bitmap Descriptor)等が含まれる。
また、複数のメディアオブジェクトをまとめて管理するためのメディアオブジェクトマネージャ320が同様にファイルとして管理され、コンテンツ管理情報601を構成する。
さらに、メディアオブジェクトに拡張情報602を付与する拡張オブジェクト603もファイルとして管理される。プログラムマネージャ330も拡張オブジェクトの一例であり、複数のメディアオブジェクトの内容や記録日時等に応じて整理分類したり、ユーザが自由な再生順序を設定するプログラム再生を行ったりするための拡張情報を格納するために設けられている。
これらのディスクメディア100に記録されるデータは、システムバス105を通じて、システム制御部104により操作される。
一方、システム制御部104は、より詳細には、オペレーティングシステム(OS)とアプリケーションシステムとからなる。
オペレーティングシステムには、ファイルシステム情報600を制御するファイルシステム処理部610や、特に図示されていないハードウエアの制御を行うデバイスドライバ部、メモリ制御部、等が含まれ、アプリケーションシステムに対して、API(Application Program Interface)を通じてさまざまな共通機能を提供する。これにより、アプリケーションシステムをハードウエアやファイルシステムの詳細とは分離した形で実現することが可能となる。
一方、アプリケーションシステムでは、特定のアプリケーションのための制御動作を行う。本実施の形態1においては、例えば図3を用いて説明したように、動画オブジェクトや静止画オブジェクトの記録あるいは再生処理に関する制御を行う。
また、アプリケーションシステム中のコンテンツ管理情報処理部611は、コンテンツ管理情報601及びそこに含まれるメディアオブジェクトマネージャ320に対する操作を行う。
そして、拡張情報処理部612は、拡張情報602及びそこに含まれる拡張オブジェクト603に対する操作を行う。拡張オブジェクト603に対する操作については、後でさらに説明する。
また、アプリケーションシステムには、その他にも必要に応じて、AVデータの表示や、ユーザインタフェースを処理する部分等を含む場合もある。
メディアオブジェクトマネージャ320のデータ構造については、図15〜図16を用いて以下に説明する。
図15(a)は、メディアオブジェクトマネージャ320のデータ構造の例示図である。図15(a)に示すようにメディアオブジェクトマネージャ320は、ヘッダ部700とデータ部701とから構成される。
ヘッダ部700には、ファイルのタイプを表すDataType、ファイルのサイズを表すDataSize、メディアオブジェクトマネージャ320の更新日時であるModTime702、等が含まれる。また、拡張情報602を管理するための拡張オブジェクト管理情報テーブル710が含まれる。なお、LastMoUniqueID703については後述する。
データ部701は、メディアオブジェクト管理情報テーブル730を含む。メディアオブジェクト管理情報テーブル730は、メディアオブジェクトマネージャ320中に含まれるメディアオブジェクト管理情報(MO_INFO)700の数を示すNumMoInfoと、NumMoInfo個のMO_INFO700から構成される。
なお、図15等におけるフィールド名欄の表記は、データ型とフィールド名を続けて記述しており、データ型については、例えば以下のような意味を示している。
constは、フィールドが定数であることを意味しており、constがない場合は変数であることを示している。unsignedは、当該フィールドは符号無しの値であることを示しており、unsignedがない場合は符号付きの値であることを示している。また、int()は、フィールドはカッコ内のビット長を持つ整数値であることを示している。例えば、カッコ内の値が’16’である場合には、16ビット長であることを意味する。また、stringは文字列情報であることを意味する。
図15(b)は、メディアオブジェクトマネージャ320に含まれる拡張オブジェクト管理情報(EO_INFO)720のデータ構造である。EO_INFO720は、プログラムマネージャ330のような拡張オブジェクトを登録・管理するデータ構造であり、各拡張オブジェクトをそれぞれ識別するための型情報を示すEoType721及びEoSubType722を持つ。
EoType721及びEoSubType722には、例えば、拡張オブジェクトの所有者(オーナー)情報やその使用目的を示す情報を数値やアルファベット値として格納しても良い。
さらにEO_INFO720は、拡張オブジェクトへの参照情報をパス名により保持する拡張オブジェクト参照情報EoRef723、図15(c)で示される属性フラグであるEoFlags724、拡張オブジェクトの概要を示す文字列情報を格納するTextDesc726、等から構成される。
図15(c)は、EO_INFO720が指し示す拡張オブジェクトに関する様々な情報をフラグとして格納するEoFlags724の構造例である。本実施の形態においては、0ビット目をValidフィールドとしている。
Validフィールドの値が1bの場合、メディアオブジェクトマネージャ320及びそれが管理するメディアオブジェクトと、EO_INFO720が指し示す拡張オブジェクトとの整合性が維持されており、該拡張オブジェクトに含まれる情報が有効であることが保障されている状態を示す。一方、Validフィールドの値が0bの場合は、その保障がないことを示す。
図16(a)は、メディアオブジェクトマネージャ320に含まれるメディアオブジェクト管理情報(MO_INFO)740のデータ構造である。
MO_INFO740は、登録されるメディアオブジェクトの型情報を示すMoType741、メディアオブジェクトへの参照情報であるオブジェクト参照情報MoRef742、少なくともメディアオブジェクトマネージャ320内で重複しない値であるメディアユニークIDが設定されるMoUniqueID743、等から構成される。
重複しないメディアユニークIDの設定方法は、例えば、初期値を0とし、メディアオブジェクトを新たに記録するたびにメディアユニークIDの値を1ずつ加算しながら割り当てていく。そして、ある時点でのメディアユニークIDの最大値をLastMoUniqueID703に記録しておくことにより、記録を一旦中断した時にも次に割り当てるメディアユニークIDの値(すなわち、LastMoUniqueID703に1を加算した値)を容易に決めることができる。
あるいは、図11を用いて説明したように、UDFファイルシステムはファイルシステム上で、各ファイルに対して重複しないUniqueID511を設定するので、このUnique ID511の値をメディアユニークIDの値として流用することも可能である。
なお、本実施の形態においては、MoUniqueID743に設定された値と同じ値を図11(a)で示したEFE510のEAs513中にMoUniqueID541として設定するようにしてもよい。
その他にも、各種属性情報を示すAttributes、当該メディアオブジェクトの再生時間であるPlayBackDuration、MO_INFO740とは異なる場所に格納されるテキスト情報への参照情報TextIDやサムネイル情報への参照情報ThumID等も含んでいる。
図16(b)に示すように、MoType741に設定される値は、参照先のメディアオブジェクトの種類により決まる。
MoTypeの値が’1’である場合、あるオブジェクトメディア情報に登録されているメディアオブジェクトの種類は、ファイルシステム上のあるディレクトリである。同様に、値が’2’の場合には動画オブジェクト(拡張子:MOI)を、値が’3’の時は静止画オブジェクト(拡張子:JPG)を、それぞれ示す。以下同様に、メディアオブジェクトの種類ごとに異なるMoTypeの値を割り当てることとする。
また、MoRef742へ設定される値は、参照先のメディアオブジェクトの持つパス名情報を図16(c)に示す変換規則により変換することにより決定される。
最初のフィールドParent Dir NoはMO_INFO740が参照するメディアオブジェクトの親ディレクトリのパス名により決められる。すなわち、親ディレクトリがVIDEOイメージルートディレクトリ301の場合は’0’、DCIMイメージルートディレクトリ302の場合は’1’となる。それ以外の値については、本実施の形態1では使用しないので予約値としている。
もちろん、変換規則によって与えられる値は別の組み合わせであってもよく、例えば、VIDEOイメージルートディレクトリ301に’1’を、DCIMイメージルートディレクトリ302に’2’を割り当て、その他の場合を予約値とするようにしてもかまわない。
次のフィールドであるDir Noには、MO_INFO740に登録されたメディアオブジェクトのディレクトリ番号部分を抜き出して格納する。ここでディレクトリ番号とは、メディアオブジェクトの上位ディレクトリのディレクトリ名における数値部分である。
次のフィールドであるFile Noには、MO_INFO740に登録されたメディアオブジェクトのファイル番号を抜き出して格納する。ここでファイル番号とは、メディアオブジェクトのファイル名における数値部分である。
例えば、メディアオブジェクトのパス名が、“/VIDEO/100ABCDE/ABCD0001.MOI”である場合、当該メディアオブジェクトは“/VIDEO”ディレクトリを親ディレクトリとして持つので、OBJ_IDのParent Dir Noの値は’0’、そして当該メディアオブジェクトの上位ディレクトリ名の数値部分の値が100であるので、OBJ_IDのDir Noの値は’100’となる。さらに、当該メディアオブジェクトのファイル名の数値部分の値をとって、OBJ_IDのFile Noの値は’0001’となる。
以上より、MoRef742に設定される値は、“/”を区切りとし、Parent Dir No、Dir No、File Noの順に並べる表記によれば、0/100/0001となる。以降、OBJ_IDの値を必要に応じて同様の表記により示す。
OBJ_IDをこのような形式としても、DCF規格の命名規則のように、メディアオブジェクトの名前やその上位ディレクトリの名前に含まれる数値部分の値が重複しないような命名規則を守っておけば、上述のMoType741の値から導かれる拡張子情報とあわせて、ファイルシステム上で、MoRef742が参照しているメディアオブジェクトを特定することが可能である。このような構成はMO_INFO740のデータ量を減らす目的に好適である。
もちろん、OBJ_IDのデータ構造は、MO_INFO740とメディアオブジェクトが一意に対応づけられる形式であれば他の形式でもよい。例えば、メディアオブジェクトのパス情報をそのまま格納する方法もある。すなわち、“/VIDOE/100ABCDE/ABCD0001.MOI”のように、“/”をパス区切り文字としたフルパス名の文字列を格納してもよい。
あるいは、MoType740の部分の代わりに、ファイルの拡張子を格納するようにしてもよい。例えば“/VIDOE/100ABCDE/ABCD0001.MOI”というファイルに対しては“MOI”の部分を格納するようにしてもよい。
なお、動画オブジェクトについては、属性情報ファイル(例えば、図8における312)だけをメディアオブジェクト管理情報に登録してもよい。対応する動画ファイル(この場合、図8における311)は、上述のようにファイル名の対応付け等により属性情報ファイルから知ることができるからである。あるいは、逆に、動画ファイルをメディアオブジェクト管理情報に登録するようにしてもよい。同様に対応する属性情報ファイルを知ることができるからである。もちろん、属性情報ファイルと動画ファイルの両方を登録してもかまわない。
次に本実施の形態における拡張オブジェクトの一例であるプログラムマネージャ330のデータ構造について、図17を用いて以下に説明する。
拡張オブジェクトの共通構造として、ヘッダ部800とデータ部801を持つ。
ヘッダ部800は、ファイルのタイプを表すDataType(拡張オブジェクトを示す固定値を設定)、ファイルのサイズを表すDataSize、拡張オブジェクトの型情報を示すEoType811及びEoSubType812、更新時刻を示すModTime813、拡張オブジェクトの概要を示す文字列情報を格納するTextDesc814、等から構成される。
ヘッダ部800において、EoType811、EoSubType812の値により拡張オブジェクトの種類分けを行う。
また、拡張オブジェクトはEO_INFO720から参照されるが、この時、EoType811、EoSubType812及びTextDesc814の値が、EO_INFO720中のEoType721、EoSubType722及びTextDesc726へと設定される。
一方、データ部801は、拡張オブジェクトの種類ごとに固有の拡張データを格納し、EoType811、EoSubType812の値により異なるデータ構造を持つ。
図17(a)は、プログラム再生を行うための拡張オブジェクトであるプログラムマネージャ330の場合の例であり、拡張データとして次のような構造を持つ。
プログラムマネージャ330に登録されたすべてのメディアオブジェクトの再生時間の合計であるPlayBackDuration、プログラムマネージャ330中に含まれるプログラム情報(PRG_INFO)820の数を示すNumPrgInfo、そして、NumPrgInfo個のPRG_INFO820からなるプログラム情報テーブル830で構成される。
そして、図17(b)はプログラムマネージャ330に含まれるプログラム情報(PRG_INFO)820のデータ構造である。PRG_INFO820は、MO_INFO740をグループ化し、ディスクメディア100上に記録された複数のメディアオブジェクトの分類を行ったり、あるいは、PRG_INFO820から参照しているメディアオブジェクトを順に再生することにより、プログラム再生を実現するときの一つの単位である。
図17(b)に示すように、PRG_INFO820は、プログラム情報であることを示すDataType、PRG_INFO820のサイズを示すDataSize、プログラムの各種属性情報を示すAttributes、プログラムの再生時間であるPayBackDuration、PRG_INFO820中に含まれるMO_INFO740への参照の数を示すNumMoInfo、そして、NumMoInfo個のMoIDからなるMO_INFO740への参照テーブル、等から構成される。
その他にも、PRG_INFO820とは異なる場所に格納されるテキスト情報への参照情報TextIDやサムネイル情報への参照情報ThumID等も含んでもよい。
本構造により、拡張オブジェクトであるプログラムマネージャ330は、任意のメディアオブジェクトをグループ化することが可能となる。これにより、ファイルシステム上のディレクトリ構造とは独立して、仮想的なフォルダー構造を構成し、メディアオブジェクトの自由な分類整理を行える。また、ユーザの望みの再生順序でメディアオブジェクトを再生するプログラム再生等の機能も実現できる。
次に、図18を用いて、ファイルシステムで管理されるディレクトリやメディアオブジェクトと、MO_INFO740との関係を説明する。
メディアオブジェクトマネージャ320には、複数のMO_INFO740が含まれており、それぞれにメディアオブジェクトが登録されている。例えば、MoInfo[1]900には、ディレクトリ304が登録されている。この時、MoInfo[1]900のフィールドの値は次のように設定される。
まずMoTypeは、図16(b)より、ディレクトリを示す’1’が設定される。MoRefは、図16(c)より、親ディレクトリ’0’、ディレクトリ番号’100’、ファイル番号’0000’となり、フィールド値全体としては0/100/0000となる。
MoUniqueID743は、ここでは’100’が設定されており、他のMO_INFOに設定されている値と重複していない。
また、MoInfo[2]901のフィールドの値は次のように設定される。まずMoTypeは、動画オブジェクトを示す’2’が設定される。MoRef711は、親ディレクトリ’0’、ディレクトリ番号’100’、ファイル番号’0001’となり、フィールド値全体としては0/100/0001となる。MoUniqueIDは、重複しない値として’101’が設定されている。以降、その他のMoInfoも同様に値が設定される。
図19は、このようなメディアオブジェクトマネージャ320に対する、プログラムマネージャ330の関係を示すものである。上述のように、プログラムマネージャ330には複数のPRG_INFO800(PrgInfo[1]910〜)が含まれる。
各PRG_INFO800は、MO_INFO700への参照情報を、メディアユニークIDとして保持する。すなわち、MO_INFO700がMoUniqueID712で保持しているメディアユニークIDの値を参照情報とする。
例えば、PrgInfo[1]910では、図19中の波線矢印で示すように、MoInfo[2]とMoInfo[5]とMoInfo[8]への参照を持つので、MoIDのテーブル(MoID[])の値として、101、104、201を保持する。PrgInfo[2]911でも同様に、MoInfo[6]とMoInfo[8]への参照を持つので、MoID[]の値として、105、201を保持する。
この状態において、プログラム再生を実施するための処理について説明する。例えば、PrgInfo[1]910によるプログラム再生の開始が指示されたとすると、コンテンツ管理情報処理部611は、PrgInfo[1]910内のメディアオブジェクト情報への参照テーブルMoID[]内の値を読み出す。上述したとおり、MoID[]には、プログラム再生の対象となるメディアオブジェクトへの参照情報がメディアユニークIDとして保持されている。
よって、プログラム再生を行うには、MoID[]に保持されているメディアユニークIDの指し示すMO_INFO740をメディアオブジェクトマネージャ320中から検索し、それが見つかったら、MO_INFO740が参照するメディアオブジェクトの再生を行う。
MoID[]に保持されているすべてのメディアユニークIDに対して同様の手順を繰り返すことによりプログラム再生が実行される。
図20は、複数の拡張オブジェクトが存在する場合において、ファイルシステムで管理されるディレクトリやメディアオブジェクト、メディアオブジェクトマネージャ320との関係を示すものである。ここでは、プログラムマネージャ330とは異なる拡張オブジェクト1000と1001が存在する。
図19を用いて説明したのと同様に、拡張オブジェクト1000と1001はメディアオブジェクトマネージャ320を経由して(例えば、プログラムマネージャ330と同様にメディアユニークIDにより)メディアオブジェクトに対応付けられており、さまざまな拡張情報を提供する。
例えば、拡張オブジェクト1000は、各メディアオブジェクトがこれまでに何回再生されたかの再生回数のカウント値を保持する拡張オブジェクトである。各メディアオブジェクトが再生されるたびにそのカウント値を増加させて、拡張オブジェクト1000内に保持する。このようなカウント値を拡張情報として保持しておくことにより、あるメディアオブジェクトをユーザが既に視聴したかどうかを示すことが出来る。
あるいは、再生回数のカウント値をユーザの録画映像に対する好みの判定に用いることも出来る。例えばカウント値が大きい場合は、ユーザの好みの映像が録画されていると判断し、逆に、カウント値が少ないメディアオブジェクトは好みではないと判断する。このような情報は、例えば、記録媒体100上の空き容量が少なくなったとき、不要なメディアオブジェクトの削除を行う時の参考情報として用いることが可能である。
また、拡張オブジェクト1001は、各メディアオブジェクトに対するGPS情報を格納する。各メディアオブジェクトが記録された時点での位置情報を記録しておき、後に検索や表示するために用いることが可能である。
ユーザが旅行の記念撮影などを行った時に、GPS情報があれば、行き先の位置情報を頼りに、多数のメディアオブジェクトから目的のメディアオブジェクトを容易に探し出すことが可能となる。
なお、拡張オブジェクトとして保持するデータとしては、上記に限られるものではなく、他のデータでもよい。例えば、各メディアオブジェクトに対するcameraパラメータ(記録時のカメラの種別、ズームの有無、フラッシュの有無、等)や、MPEG7などのメタデータ等でもよい。その他、製造メーカが他社製品との差別化やユーザに対する独自の利便性を提供することを目的として、メディアオブジェクトマネージャ320等の統一規格に含まれない機能を実現するために利用してよい。
図21は、図20の状態において、拡張オブジェクト管理情報テーブル710に設定される値の例を示す図である。
図21(a)の一つの行がEO_INFO720に相当する。各EO_INFOのEoType及びEoSubtypeは、それぞれの拡張オブジェクトの内容を識別するための値(ここではそれぞれ2文字のアスキーコード)が設定される。なお、各EoType及びEoSubtypeの値は一例であり、各拡張オブジェクトが識別可能であれば他の値でもかまわない。
EoRefとして、ここでは、拡張オブジェクトのファイル名を格納する。なお、拡張オブジェクトを参照する時のデータ形式は他の形式でもよく、MO_INFO740がメディアオブジェクトを参照する時に使用するOBJ_IDのように、ファイル番号などの特定の変換規則を利用することも可能である。
EoFlagsについては、ここでは、すべての情報が有効であるとし、Valid=1bがすべて設定されている。TextDescは、それぞれの拡張オブジェクトの保持する情報の内容を簡単な文字列として保持している。
図22は、本実施の形態において、新規の拡張オブジェクト及び拡張データを記録するための処理を示すフローチャートである。
まず、拡張情報処理部612が、拡張オブジェクト管理情報テーブル710をメディアオブジェクトマネージャ320から読み出す(ステップS101)。
次に、拡張オブジェクト管理情報テーブル710中の各EO_INFO720の値を調べることにより、追加したい拡張データを含む拡張オブジェクトがすでに存在しているかどうかを調べる(ステップS102)。
拡張オブジェクトが存在していない場合は新規に作成し(ステップS103)、対応するEO_INFO720を拡張オブジェクト管理情報テーブル710へと追加する(ステップS104)。拡張オブジェクトが存在していた場合及び新規に作成した後は、その拡張オブジェクトへ拡張データを追加する(ステップS105)。
図23は、本実施の形態において、メディアオブジェクト及びMOINFO740に対する何らかの操作が行われた後、拡張オブジェクト管理情報テーブル710に対して行われる処理を示すフローチャートである。ここで、メディアオブジェクト及びMO_INFO740に対する何らかの操作とは、例えば、メディアオブジェクトやMO_INFO740中のデータ値の書き換えや編集及び削除、等のことである。
このような操作が行われると、メディアオブジェクト及びメディアオブジェクトマネージャ320と、拡張オブジェクト及び拡張データ間の情報の不整合が発生する場合がある。
例えば、拡張データの一種であるPRG_INFO820から参照されているメディアオブジェクトが削除されてしまうと、PRG_INFO820からの参照先がなくなってしまい、プログラム再生の実行の際に不都合が生じる。
プログラム再生以外の他の拡張データの場合も同じで、参照先のメディアオブジェクトやMO_INFO740が変更されると、不整合が発生する。
そこで本実施の形態においては、メディアオブジェクト及びメディアオブジェクトマネージャ320に対して何らかの操作が行われると以下の処理を実施する。
まず、拡張情報処理部612は、拡張オブジェクト管理情報テーブル710をメディアオブジェクトマネージャ320から読み出す(ステップS201)。
拡張オブジェクト管理情報テーブル710には、TotalNumEoInfo704で示される数だけEO_INFO720が存在するので、ステップS202からステップS208のループ処理によりすべてのEO_INFO720に対する処理を行う。
まず、ループ処理のカウント値を初期化し(ステップS202)する。
そして、最初の拡張オブジェクトに対して、処理可能かどうかを判別する(ステップS203)。この判別には、EoType721及びEoSubtype722やEoRef723が利用可能である。
ある記録再生装置は、特定の種類の拡張オブジェクトしか操作できない場合があるので、もし、処理不可能な拡張オブジェクトであることがわかったら、Validフラグ731を0bに設定する(ステップS204)。これにより、該拡張オブジェクトとメディアオブジェクト及びメディアオブジェクトマネージャ320との間での整合性を保障しない状態であることを示す。一方、処理可能な拡張オブジェクトであることがわかったら、該拡張オブジェクトの内容を更新し(ステップS205)、Validフラグ731を1bに設定する(ステップS206)。
ここで、該拡張オブジェクトの内容を更新とは、先に行われたメディアオブジェクト及びメディアオブジェクトマネージャ320に対する操作の結果と、該拡張オブジェクトの内容が整合するような処理である。
例えば、拡張オブジェクトがプログラムマネージャ330であり、メディアオブジェクト及びメディアオブジェクトマネージャ320に対する操作が、メディアオブジェクト及びそれを参照するMO_INFO740の削除であった場合、プログラムマネージャ330に対しては、該MO_INFO740を参照するPRG_INFO820を更新し、削除された該MO_INFO740への参照を削除する処理を行う。他の種類の拡張オブジェクトに対しても、それぞれの拡張情報に応じた更新処理を実施する。
更新処理を実施することにより、該拡張オブジェクトとメディアオブジェクト及びメディアオブジェクトマネージャ320との間での整合性を保障できるので、Validフラグ731を1bに設定している。
以降、カウント値を加算しながら、TotalNumEoInfoの値に等しくなるまで処理を繰り返す(ステップS207、ステップS208)。
図23のような処理が終了した後の拡張オブジェクト管理情報テーブル710に設定される値の例を図21(b)に示す。
ここでは、一例として、拡張オブジェクトとしてプログラム再生のみを処理可能であり、他の種類の拡張オブジェクトの処理ができない記録再生装置による処理後の設定値の例を記す。2行目以降のEO_INFO720のValidフラグが0bに設定され、これらの拡張オブジェクトのデータの有効性が保障されない状態であることを示している。
図24は、本実施の形態において、特定の種類の拡張オブジェクトを指定してそのデータを利用する際の処理に関するフローチャートである。
まず、拡張情報処理部612は、拡張オブジェクト管理情報テーブル710をメディアオブジェクトマネージャ320から読み出す(ステップS301)。
次に、拡張オブジェクト管理情報テーブル710内を検索し、目的の拡張オブジェクトを参照しているEO_INFO720を得る(ステップS302)。目的の拡張オブジェクトの検出は、EoType721及びEoSubtype722の値を調べることにより行える。あるいは拡張オブジェクトのパス名の命名側を決めておくことにより、EoRef723の値を見ることにより検出可能である。
もし、目的の拡張オブジェクトを参照しているEO_INFO720が見つからなければ、例外処理を行い(ステップS303)、本フローチャートで示す処理を終了する。例外処理とは例えば、ユーザに所望の拡張オブジェクトが存在しないことを知らせるメッセージを表示したり、あるいは、新たに、該拡張オブジェクトを作成したりする処理などである。
もし、目的の拡張オブジェクトを参照しているEO_INFO720が見つかれば、Validフラグの値が1bであるかを調べる(ステップS304)。
Validフラグの値が1bでなければ例外処理を実施する(ステップS305)。ここでの例外処理とは例えば、ユーザに所望の拡張オブジェクトとメディアオブジェクトマネージャ320との間で不整合が存在することを知らせるメッセージを表示したり、記録媒体100の書き込みを禁止したり、あるいは、該拡張オブジェクトとメディアオブジェクトマネージャ320の不整合を解消すべく、該拡張オブジェクト内の情報を更新する処理を実施したりする処理、等である。
一方、Validフラグの値が1bであれば、該拡張オブジェクトに対する通常処理を実施する(ステップS306)。通常処理とは、例えば、該拡張オブジェクトが、プログラムマネージャ330であれば、プログラム再生を実施することである。
他の拡張オブジェクトに関しても、あるメディアオブジェクトに関連付けられている拡張データをユーザに対して表示する(GPS情報の表示など)、等、夫々の種類に応じた動作を行う。
図24中の例外処理を行う場合に、少なくともTextDesc726の値を表示するようにすれば、どんな拡張情報が設定されているかをユーザに知らせることが可能である。
以上により、メディアオブジェクトマネージャ320のデータ容量を大幅には増加させず、拡張情報の追加が行える。
これは、DVDレコーダやDVDビデオカメラのような民生の家電機器等のハードウエア資源が限られる記録再生装置において望ましい構成である。また、メディアオブジェクトの編集や削除を行った場合に、ある記録再生装置が対応していない拡張機能が存在しても、データの不整合を最小限に抑制し、かつ、適切なデータ処理方法を決定可能となり、機器の誤動作やシステム停止、ユーザに対する利便性の低下等を回避することが可能となる。
これは、DVDレコーダやDVDビデオカメラなどの可搬型の記録媒体を用いた記録再生装置において、1つの記録媒体が複数の製造メーカによる記録再生装置で記録・再生される場合において望ましい構成である。
(実施の形態2)
本実施の形態では、実施の形態1とは異なる拡張オブジェクトの管理の方法について述べる。実施の形態1では、拡張オブジェクト管理情報テーブル710により拡張オブジェクトを管理したが、本実施の形態では、MO_INFOにより各拡張オブジェクトを管理する。
このときの、拡張オブジェクトとMO_INFOの関係を図25に示す。ここでは、メディアオブジェクトマネージャ320に含まれるMO_INFOであるMoInfo[i]〜MoInfo[i+2]がそれぞれ拡張オブジェクト1000、330、1001を参照、管理しているものとする。ただし、本実施の形態におけるMO_INFOは、図26に示す構造を持つものとする。
図26(a)におけるMO_INFO2000は、MO_INFO740に対して、EO_INFO2100のフィールドが追加されている点を除いて同一である。
EO_INFO2100は、EO_INFO720と異なる構造を持ち、図26(b)で示す構造を持つ。
EO_INFO2100は、EO_INFO720からEoRef723とTextDesc726を除いた構造を持ち、EoRef723の代わりにMoType741とMoRef742を、TextDesc726の代わりにTextID744を用いることで同様の機能を果たす。すなわち、MoType741とMoRef742により拡張オブジェクトを参照し、TextDesc726により拡張オブジェクトに対する文字列情報を格納する。
なお、上記機能を実現するために、図16(b)のMoType741の値に対して、拡張オブジェクト(拡張子:EXT)を示す値(例えば“4”)を定義することとする。
また、MoRef 742による参照を行うために、拡張オブジェクトのディレクトリ名やファイル名は、ディレクトリ番号及びファイル番号による一意な参照が可能となるような命名則を用いる。
上記構成により、メディアオブジェクトと拡張オブジェクトを共通の枠組みで管理することが可能となり、装置の実装上、好都合である。
(実施の形態3)
本実施の形態では、異なる拡張オブジェクトの管理の方法について述べる。
実施の形態1では、拡張オブジェクト管理情報テーブル710のValidフラグ731において拡張オブジェクトの有効性を管理したが、本実施の形態では、MO_INFOにおいて各拡張オブジェクトの有効性を管理する。
このとき、メディアオブジェクトを参照・管理するMO_INFOは図27に示すデータ構造を持つものとする。
図27(a)におけるMO_INFO3000は、MO_INFO740に対して、拡張データ属性フラグ(RefValidFlag)3100のフィールドが追加されている点を除いて同一である。
RefValidFlag3100は、図27(b)に示す情報を保持する。RefValidFlag3100では、2ビットがひとつの拡張オブジェクトに対応している。
例えば、ビット0〜1は、拡張オブジェクトの内、ファイル番号が0001番を持つものに対応する。同様に、ビット1〜2はファイル番号が0002番に対応し、以降も同様である。
そして、この各2ビットの解釈は、次のとおりである。すなわち、上位ビットは、該MO_INFO3000が管理するメディアオブジェクトに対して、拡張オブジェクトからの参照が存在する(1b)か、存在しない(0b)かを示す。そして、下位ビットは、MO_INFO3000が管理するメディアオブジェクトに対する拡張データが有効である(1b)か無効である(0b)かを示す。
すなわち、この下位ビットは、Validフラグ731と同じ意味を持つ。ただし、このRefValidFlag3100の下位ビットは、MO_INFO3000単位で拡張データが有効かどうかを示すことができ、より詳細な単位での拡張データの管理が可能となっている。
具体的には、例えば図20に示したのと同様な参照関係が存在する場合、図20中のMoInfo[1]のRefValidFlag3100に設定される値は、図27(b)の右端の列「設定値の例」のようになる。
すなわち、MoInfo[1]は、ファイル番号0001を持つ拡張オブジェクトであるプログラムマネージャ330からの参照を持ち、かつその値が有効であるとすると、ビット0〜1は11bという値に設定される。また、同様に、ファイル番号0002を持つ拡張オブジェクトからも参照されており、かつその値が有効であるとすると、ビット2〜3は11bという値に設定される。
一方、ファイル番号0016を持つ拡張オブジェクトも存在するが、そこからは参照されていないので、ビット30〜31は00bという値に設定される。
また、上記状態から、図23を用いて説明した処理と同様、メディアオブジェクトに対する編集操作等が行われると拡張オブジェクトとの整合性が保証されない場合が発生する。
例えば、拡張データの一種であるPRG_INFO820から参照されているメディアオブジェクトが編集され、その再生時間長が変化してしまう(例えば、再生時間が短くなる)と、プログラムの再生時間であるPlayBackDurationが実際の値と異なってしまい、プログラム再生の実行の際にユーザに混乱を与えてしまう。
そこでこの時、図28で示す処理を実施する。
まず、拡張情報処理部612は、編集対象のメディアオブジェク管理情報3000からRefValidFlag3100を読み出す(ステップS401)。
RefValidFlag3100のフィールド長に応じた数だけ拡張オブジェクトが存在する可能性があるので、ステップS402からステップS409のループ処理により、存在するすべての拡張オブジェクトに対する処理を行う。
次に、ループ処理のカウント値を初期化(ステップS402)する。
そして、最初の拡張オブジェクトに対して、該メディアオブジェクトに対して参照する拡張オブジェクトが存在するかを判別する(ステップS203)。この判別は、該拡張オブジェクトに対応するRefValidFlag3100中の2ビットの内、上位ビットの値により行われる。もし、参照が存在しない場合は、ステップ408へ進む。
参照が存在した場合は、該拡張オブジェクトに対して、処理可能かどうかを判別する(ステップS404)。
ある記録再生装置は、特定の種類の拡張オブジェクトしか操作できない場合があるので、もし、処理不可能な拡張オブジェクトであることがわかったら、該拡張オブジェクトに対応するRefValidFlag3100中の2ビットの内、下位ビットの値を0bに設定する(ステップS405)。これにより、該拡張オブジェクトと該メディアオブジェクトとの間での整合性を保障しない状態であることを示す。
一方、処理可能な拡張オブジェクトであることがわかったら、該拡張オブジェクトの内容を更新し(ステップS406)、該拡張オブジェクトに対応するRefValidFlag3100中の2ビットの内、下位ビットの値を1bに設定する(ステップS407)。ここで、拡張オブジェクトの内容を更新とは、例えば、メディアオブジェクトの編集に伴い、プログラムのPlayBackDurationを更新する処理である。
以降、カウント値を加算しながら、全てのRefValidFlag3100に対して処理を繰り返す(ステップS408、ステップS409)。
図28のような処理が終了した後のRefValidFlag3100に設定される値の例を図29に示す。
ここでは、一例として、拡張オブジェクトとしてプログラム再生のみを処理可能であり、他の種類の拡張オブジェクトの処理ができない記録再生装置による処理後の設定値の例を記す。RefValidFlag3100ビット2については1bのまま変化がなく、一方、ビット3が0bに設定され、この拡張オブジェクトからの参照は依然として存在するが、そのデータの有効性が保障されない状態であることを示している。
以上のように、実施の形態1においては、拡張オブジェクト全体に対して有効かどうかをValidフラグ731を用いて管理したが、本実施の形態においては、RefValidFlag3100の下位ビットを用いることにより、メディアオブジェクト及びMO_INFO毎に有効性の管理が可能となり、拡張オブジェクト全体を更新せず、その一部だけを更新するような、より柔軟な管理が可能となる。
また、図24を用いて説明したのと同様、RefValidFlag3100の下位ビットの値を見る(すなわち、図24のステップS304に相当する処理を実施する)ことにより、拡張オブジェクトの情報が有効な場合は通常処理を行い、有効性が保証されない場合は、適切な例外処理や書き込みの禁止、ユーザへのメッセージの表示などを行うことが可能である。
このような構成は、特にメディアオブジェクトマネージャのデータ量が大きい場合、必ずしもその全体を更新しなくてよいので、データ処理量の効率化に有効である。
なお、本実施の形態においては、RefValidFlag3100を32ビット長としたが、他のデータ長でもよく、あるいは、可変長にすることも可能である。可変長にすることにより効率的に拡張オブジェクトの数の変化に対応可能となる。
また、上記においては、RefValidFlag3100のビット0〜1をファイル番号が0001番である拡張オブジェクトに対応するとしたが、RefValidFlag3100の各ビットと拡張オブジェクトとの対応関係についてはこれに限るものではない。例えば、ビット30〜31のようなRefValidFlag3100の上位ビットにファイル番号が0001番である拡張オブジェクトを対応させるようにしても良い。
また、RefValidFlag3100と拡張オブジェクトをそのファイル番号により対応づけたが、他の方法による対応付けを行ってもよい。
(実施の形態4)
本実施の形態では、更新日時情報を用いた拡張オブジェクトの有効性管理方法について述べる。
図15(a)で示したように、メディアオブジェクトマネージャ320には、その更新日時を示すModTime702が設けられている。メディアオブジェクトマネージャ320の内容が更新されるたびに、ModTime702の値も更新するものとする。
一方、拡張オブジェクトにもその更新日時を示すModTime812が設けられている。ModTime813も同様に、拡張オブジェクトの内容が更新されるたびに、その値が更新されるものとする。
ただし、図23の処理手順で示したとおり、本発明の記録再生装置においては、処理可能な拡張オブジェクトのみをその内容を更新するものとする(図23のステップS205)。
これにより、メディアオブジェクトに対する編集操作等が行われると、メディアオブジェクトマネージャ320が更新され、さらに、処理可能な拡張オブジェクトのみが更新される。
結果として、ModTime702の値と、処理可能な拡張オブジェクトのModTime813が一致する。一方、処理不可能な拡張オブジェクトは更新されないのでそのModTime813も更新されず、ModTime702の値と一致しなくなる。
よって、本発明の記録再生装置において、ある拡張オブジェクトを処理しようとする時、ModTime702の値とのModTime813の値を比較することにより、該拡張オブジェクトが有効であるかどうかを知ることができる。
これはすなわち、図24で示したValidフラグの値が1bであるかどうかを調べる(図24のステップS304)のと同様の効果があることを意味する。
なお、図17では、拡張オブジェクトとしてプログラムマネージャ330を用いて説明したが、他の拡張オブジェクトでも、ModTime813と同じフィールドを持つことにより同様の効果を得ること可能である。
なお、上述の実施例において、MO_INFO740、2000、3000は、Property Entryと呼ばれることもある。また、MoType741及びMoRef742をあわせて、Binary File Identifierと呼ばれることもある。また、MoUniqueID743は、entry_numberと呼ばれることもある。また、拡張オブジェクトはメーカ独自ファイル、あるいは、プライベートファイルと呼ばれることもある。また、RefValidFlag3100は、vflagsと呼ばれることもある。
なお、上述したいずれの実施の形態においても、記録再生装置及び記録媒体をDVDのような光ディスクメディアを例に挙げて説明しているが、特に限定されるものではなく、その他磁気記録メディアを用いたハードディスクドライブ、光磁気ディスクメディア等、他の記録装置や記録媒体であっても良い。
以上のように、本発明にかかる記録再生装置及び方法によれば、拡張機能のためのデータ追加を効率的に行える。これは、DVDレコーダやDVDビデオカメラのような民生の家電機器等のハードウエア資源が限られる記録再生装置において望ましい構成である。また、メディアオブジェクトの編集や削除を行った場合に、統一規格では定められていないため、ある記録再生装置では対応していない拡張機能または拡張オブジェクトが存在しても、データの不整合を最小限に抑制し、かつ、適切なデータ処理方法を決定可能となり、機器の誤動作やシステム停止、ユーザに対する利便性の低下等を回避することが可能となる。
特に、DVDレコーダやDVDビデオカメラなどの可搬型の記録媒体を用いた民生用の記録再生装置では、1つの記録媒体が複数の製造メーカによる異なる拡張機能を持った記録再生装置で記録・再生されることが想定される。よって、本発明にかかる記録再生装置及び方法により、より大きな効果を得ることが可能となる。
なお、上記の実施形態では、本発明の側面のうち、主に、記録装置、再生装置、記録媒体、記録方法、再生方法に関する実施形態を説明した。しかし、本発明は、他の側面として、前記記録装置の記録動作を制御するプログラム、前記再生装置の再生動作を制御するプログラム、これらのプログラムの提供媒体(プログラム製品)、および、記録媒体に記録されたデータ構造、としても実施することが可能である。当業者であれば、上述の実施形態の説明から、これらの側面の実施形態についても容易に理解することが可能であろう。
(実施の形態1)
図1は、本発明の実施の形態1にかかる記録再生装置の一例である、DVDレコーダの外観と、関連機器とのインタフェースを説明するための図である。図1に示すように、本発明にかかる記録再生装置の一実施形態としてのDVDレコーダ1は、記録媒体であるディスクメディアとしてDVDディスク2が装填され、ビデオ情報等の記録再生が行なわれる。DVDレコーダ1の操作は、一般的にはリモートコントローラ3や機器上のスイッチ(図示せず)によって行なわれる。
DVDレコーダ1に入力されるビデオ情報には、アナログ信号とデジタル信号の両者があり、アナログ信号としてはアナログ放送が、デジタル信号としてはデジタル放送がある。一般的に、アナログ放送は、テレビジョン装置4に内蔵されている受信機により受信、復調され、NTSC方式等のアナログビデオ信号としてDVDレコーダ1に入力される。
また、デジタル放送は、受信機であるセットトップボックス(STB)5でデジタル信号に復調され、DVDレコーダ1に入力され記録される。
一方、ビデオ情報が記録されたDVDディスク2は、DVDレコーダ1により再生され外部に出力される。出力される信号も入力される信号と同様に、アナログ信号とデジタル信号の両者があり、アナログ信号であれば直接テレビジョン装置4に入力され、デジタル信号であればSTB5を経由し、アナログ信号に変換された後にテレビジョン装置4に入力され、テレビジョン(TV)で映像として表示される。
さらに、本発明にかかる記録再生装置の他の実施形態として、DVDディスク2を利用する装置にDVDビデオカメラ6がある。DVDビデオカメラ6は、DVDレコーダにレンズやCCDからなるカメラ装置を組み合わせた装置であり、撮影した動画情報を符号化して記録する。
また、DVDディスク2は、DVDレコーダ1やDVDビデオカメラ6以外に、PC7等でビデオ情報が記録再生される場合もある。PC7等でビデオ情報が記録されたDVDディスク2であっても、DVDレコーダに装填されれば、DVDレコーダは当該DVDディスクを再生する。
なお、上述したアナログ放送やデジタル放送のビデオ情報には、通常、音声情報が付随している。付随している音声情報もビデオ情報と同様に、DVDレコーダで記録再生される。
また、ビデオ情報は、動画の他に、静止画の場合もある。例えば、DVDビデオカメラ6の写真機能で静止画が記録されたり、PC7上で他の記録装置(ハードディスク)等から静止画がDVDディスク2へコピーされたりする場合が該当する。
なお、DVDレコーダとSTB5等の外部機器との間のデジタルインタフェースとしては様々なインタフェースが考えられる。例えば、IEEE1394、ATAPI、SCSI、USB、等である。
また、上記では、DVDレコーダ1とテレビジョン(TV)4との間の信号として、NTSC方式のアナログ(コンポジット)ビデオ信号を用いる場合について例示したが、輝度信号と色差信号を個別に伝送するコンポーネント信号であってもよい。
さらには、AV機器とテレビジョンの間の映像伝送インタフェースとしては、アナログインタフェースをデジタルインタフェース、例えば、DVIに置きかえる研究開発が進められており、DVDレコーダとテレビジョンがデジタルインタフェースで接続されることも当然予想される。
このようなDVDレコーダ1やDVDビデオカメラ6等の記録再生装置において、記録媒体であるディスクメディア2は、複数の記録再生装置上で記録・再生される。この時の記録装置は同一の製造メーカの場合もあるし、異なる製造メーカによる記録装置の場合もあり得る。
様々な記録再生装置における記録・再生の互換性確保のため、記録媒体における記録フォーマットやファイルフォーマットの規格化・標準化が行われるのが一般的である。例えば、DVD−Video Recording規格等、様々な統一規格が策定されている。
記録再生装置の製造メーカは、ユーザの利便性に配慮して、統一規格に準拠した記録再生装置の製品化を行う。
その一方で、各製造メーカは、他社製品との差別化を図るべく、独自の拡張機能を自社製品に盛り込んで記録再生装置を製品化する場合が多く見られる。この拡張機能とは、統一規格には含まれておらず、各製造メーカが、その内容を独自に設けるさまざまな機能である。拡張機能の実現のために、図1には示していない追加のハードウエアやソフトウエア、周辺機器が必要に応じて記録再生装置に設けられる場合がある。例えば、位置情報を取得するGPSレシーバ、等である。
図2は、本実施の形態1にかかる記録再生装置に組み込まれるドライブ装置110とその周辺の概略構成を示すブロック図である。図2において、ドライブ装置110は、記録媒体に対して情報の記録再生を行う光ピックアップ101と、ECC(Error Correcting Code)処理部102を備え、例えばDVDディスクのような記録媒体であるディスクメディア100に対してデータの記録及び再生を行う。
ディスクメディア100には、セクタと呼ばれる最小単位でデータが記録される。また、複数のセクタで一つのECCブロックを構成し、ECCブロックを1単位としてECC処理部102でエラー訂正処理が施される。なお、ECCブロックはECCクラスタと呼ばれることもある。
ディスクメディア100の一例であるDVD−RAMディスクの場合、セクタのサイズは2KBであり、16セクタを1ECCブロックとして構成されている。当該セクタサイズは、ディスクメディア100の種類に応じて変動するものであり、1セクタは512B(バイト)であっても良いし、8KB等であっても良い。
また、ECCブロックについても、1セクタを1ECCブロックとして構成しても良いし、16セクタを、あるいは32セクタ等を1ECCブロックとして構成しても良い。今後、記録できる情報容量の増大に伴い、セクタサイズ及びECCブロックを構成するセクタ数は増大するものと予想される。
また、ドライブ装置110は、トラックバッファ103と接続されており、トラックバッファ103は、システムバス105を経由して記録再生装置のシステム全体を制御するシステム制御部104と接続されている。
トラックバッファ103は、ディスクメディア100にAVデータをより効率良く記録するため、AVデータを可変ビットレート(VBR)で記録するためのバッファである。ディスクメディア100への読み書きレート(Va)が固定レートであるのに対して、AVデータはその内容(ビデオであれば画像)の持つ複雑さに応じてビットレート(Vb)が変化する。トラックバッファ103は、このビットレートの差を吸収するためのバッファである。
図3は、ドライブ装置110を含む、本実施の形態1にかかる記録再生装置のブロック構成図である。図3に示すように、本実施の形態1にかかる記録再生装置は、システム全体の管理及び制御を司るシステム制御部104、ユーザへの表示及びユーザからの要求を受け付けるユーザI/F(インタフェース)部200、VHF及びUHFを受信するアナログ放送チューナ210、映像をAV信号へ変換するカメラ部211、デジタル放送を受信するデジタル放送チューナ212、AV信号入力をデジタル信号に変換し、MPEGプログラムストリーム等にエンコードする動画エンコーダ221、AV信号入力をJPEGストリーム等にエンコードする静止画エンコーダ222、デジタル放送で送られるMPEGトランスポートストリームを解析する解析部223、MPEG等の動画データをデコードする動画デコーダ240、静止画データをデコードする静止画デコーダ241、テレビ及びスピーカ等の表示部250、等を備えている。
動画エンコーダ221、静止画エンコーダ222や解析部223には、AVデータの入力源として、アナログ放送チューナ210、カメラ部211、デジタル放送チューナ212等が接続されている。
なお、上述したエンコーダやチューナ、カメラ部については、全てを同時に備える必要はなく、記録再生装置の使用目的に応じて必要なものだけを備えれば良い。例えば、記録再生装置がDVD等の光ディスク用レコーダの場合であれば、図4に示すように、図3に示した構成のうち、カメラ部211を省いた構成としても良い。また、記録再生装置がビデオカメラの場合であれば、図5に示すように、図3に示した構成のうち、アナログ放送チューナ210およびデジタル放送チューナ212を省き、集音用のマイク部261をさらに備えた構成としても良い。また、記録再生装置がパーソナルコンピュータの場合であれば、図4と同様の構成としても良い。あるいは、図6に示すように、図3に示した構成のうち、アナログ放送チューナ210、カメラ部211、およびデジタル放送チューナ212を省いた構成としても良い。
さらに、図3に示す記録再生装置は、図2で示したように、書き込みデータを一時的に格納するトラックバッファ103と、ディスクメディア100にデータを書き込むドライブ装置110とを備えている。
また、IEEE1394やUSB等の通信手段により外部機器にデータを出力するインタフェースであるデジタルI/F(インタフェース)部230を備えても良い。
なお、本実施の形態1にかかる記録再生装置の詳しい動作については後ほど説明を行う。
次に、図7は、本実施の形態1にかかる記録再生装置において記録可能なディスクメディア100の外観と物理構造を表した図である。なお、例えばDVD−RAMのようなディスクメディアは、記録面を保護するのを目的として、カートリッジに収納された状態で記録再生装置に装填される。ただし、記録面の保護が別の構成で行なわれたり、容認できる場合にはカートリッジに収納せずに、記録再生装置に直接装填できるようにしてもよい。
図7(a)は、記録可能なディスクメディア100の記録領域の一例を示した図である。図7(a)の例では、最内周にリードイン領域141が、最外周にリードアウト領域142が、その間にデータ領域143が配置されている。リードイン領域141は、光ピックアップ101がディスクメディア100へアクセスする時に、サーボを安定させるために必要な基準信号や他のメディアとの識別信号等が記録されている。リードアウト領域142もリードイン領域141と同様の基準信号等が記録されている。またデータ領域143は、最小のアクセス単位であるセクタに分割されている。
図7(b)は、図7(a)において同心円状に示されているリードイン領域141と、リードアウト領域142と、データ領域143を横方向に配置した説明図である。
リードイン領域141とリードアウト領域142は、その内部に欠陥管理領域(DMA:Defect Management Area)144,147を有する。欠陥管理領域とは、欠陥が生じたセクタの位置を示す位置情報と、その欠陥セクタを交替するセクタが後述する交替領域のいずれに存在するかを示す交替位置情報とが記録されている領域をいう。
また、データ領域143は、その内部に交替領域145とユーザ領域146を有している。交替領域145は、欠陥セクタが存在する場合に代替セクタとして使用される領域である。ユーザ領域146は、ファイルシステムが記録用領域として利用することができる領域をいう。なお、ディスクメディアの種類によっては交替領域を持たないディスクメディアも存在し、この場合、必要に応じて、後述するUDF等のファイルシステムにおいて、欠陥セクタの交替処理を行う場合もある。
データ領域143にある各セクタへアクセスするため、内周から順に物理セクタ番号(PSN:Physical Sector Number)をデータ領域へ割り当てることが一般に行われている。PSNによって管理されるセクタを物理セクタと呼ぶ。
また、データ記録に使用されるセクタのみを連続的に示すように、内周から順に論理セクタ番号LSN(Logical Sector Number)をユーザ領域の物理セクタに割り当てることも行われる。LSNによって管理されるセクタを論理セクタと呼ぶ。
図7(c)は、図7(b)のユーザ領域146内で、論理セクタにより構成される論理的なデータ空間を示す図である。論理的なデータ空間は、ボリューム空間と呼称され、ユーザデータを記録する。ボリューム空間においては、記録データをファイルシステムで管理する。
DVD−RAM等のディスクメディアでは、ファイルシステムは、UDFと呼称され、ECMA167及びISO13346規格に準拠したものが一般的に使用される。
UDFのパーティション空間292では、データアクセスの単位ごとに論理ブロック番号LBN(Logical Block Number)が割り当てられ、データの配置や管理が行われる。
データの配置のために、パーティション空間292で連続的に配置される1群のセクタはエクステントと呼ばれる単位で管理され、さらに関連のあるエクステントの集合がファイルとして管理される。
エクステント及びエクステントの集合であるファイルを管理する情報制御ブロック(ICB)であるファイルエントリ(FE)及び拡張ファイルエントリ(EFE)と呼ばれる構造、さらには1群のファイルをディレクトリとして管理するための情報であるファイル識別記述子(FID)等がボリューム空間内のパーティション空間内に記録される。
そして、パーティション空間等を管理するためのボリューム構造情報290(及びそのバックアップである291)が、ボリューム領域の先頭と終端に記録される。
図8は、本発明の実施の形態1にかかる記録再生装置により記録されるディスクメディア100におけるディレクトリとファイルの階層構造の一例を示す図である。図8に示すように、ROOTディレクトリ300の下に、階層化されたサブディレクトリ(301〜305等)があり、さらにその階層下に、動画データや静止画データを含むファイルである各種メディアオブジェクト(310〜313等)や、各メディアオブジェクトを管理するためのファイルであるメディアオブジェクトマネージャ320(ファイル名:MOI_MGR)や、複数のメディアオブジェクトをグループ化し、再生順序や分類情報を管理するプログラムマネージャ330(ファイル名:PRGM0001.EXT)等が格納されている。
ここでプログラムマネージャ330は拡張情報を格納する拡張オブジェクトの一種であり、プログラム再生機能に対応した記録再生装置がその記録及び再生等の処理を行う。
なお、本実施の形態においてはメディアオブジェクトマネージャ320の構造や機能は統一規格の一種であるとし、全ての本発明の記録再生装置において記録や再生が保証されるものとする。
また、拡張情報とは、統一規格に含まれない拡張機能を製造メーカが独自に実現する上で必要な様々な情報のことである。拡張情報は拡張オブジェクトと呼ばれるファイルに格納されてディスクメディア100に記録される。上述の、プログラム再生機能は拡張機能の一例である。
本実施の形態1においては、記録及び再生用の対象となるAVデータを含む各種メディアオブジェクトのディレクトリ階層やファイル名は、後述するDCF規格及びそれに類した形式を利用して以降の説明を行う。ただし、ディレクトリ階層やファイル名の命名則はこれに限られるものではなく、他の命名則を用いても良い。
メディアオブジェクトのうち、MPEG2等の動画データを含む動画オブジェクトは、ABCDnnnn.MPGというように、最初の4文字が任意のアルファベット文字の組み合わせであり、次のnnnnが10進数であるような命名側に従って動画ファイルとして記録される。動画ファイルは、MPEG2方式やMPEG4方式等で圧縮されたAVデータを含んでおり、プログラムストリーム(PS)や、トランスポートストリーム(TS)、あるいは他の形式のファイルとして記録される。
また、各々の動画ファイルに関する属性情報は、属性情報ファイル(ファイル名:ABCDnnnn.MOI)に記録される。属性情報ファイルには、それぞれの動画ファイルの識別情報、記録された日時、動画データの代表画像(サムネイルピクチャ)、動画データの再生時刻をディスクメディア100上の論理アドレスに変換するためのアクセスマップ情報及びその管理情報、等を有している。アクセスマップ情報を持つことにより、動画データの持つ時間軸とデータ(ビット列)軸との間の変換を行うことが可能となり、動画データに対する時間軸を基準にしたランダムアクセスが可能となる。
属性情報ファイルは、例えばApple社のQuickTimeファイルフォーマットに準拠する形式でもよい。QuickTimeファイルフォーマットでは、前記属性情報は、ムービーリソース(movieresource)と呼ばれる。また同様に、前記アクセスマップ情報は、サンプルテーブル(Sample Table)と呼ばれる。
一つの動画オブジェクトは、一つの属性情報ファイルと一つ又はそれ以上の動画ファイルとで構成され、それらはファイル名により関連づけられるものとする。すなわち、関連のある属性情報ファイルと動画ファイルは、そのファイル名において拡張子を除く部分、例えば動画オブジェクト310では、動画ファイル311と属性情報ファイル312が”ABCD0001”の部分が同一に設定されることによって、その関連付けがなされていることとする。
ただし、属性情報ファイルと動画ファイルの関連付けは上述の方法に限定されるものではなく、属性情報ファイル内に関連付けられた動画ファイルへのリンク情報、例えば動画ファイルへのパス名等を保持したり、両者の対応付けをテーブル情報として保持したりする等、他の方法であっても良い。なお、一つの動画オブジェクトに、一つの属性情報ファイルと一つ又はそれ以上の動画ファイル以外を含むようにしてもよい。また、属性情報ファイルと動画ファイルを一体として、1つのファイルで動画オブジェクトを構成するようにしてもよい。
メディアオブジェクトのうち、JPEG等の静止画データを含む静止画オブジェクトは、各々の静止画情報が静止画ファイル(ファイル名:ABCDnnnn.JPG)等として記録される。静止画ファイルは、JPEG方式等で圧縮された映像データであり、例えば、DCFフォーマットやExifフォーマットによりファイルとして記録される。
上記のメディアオブジェクトは、DCF規格あるいはそれに類するディレクトリ構造にしたがって記録される。すなわち、ROOTディレクトリ300の下にDCFイメージルートディレクトリ302(ディレクトリ名:DCIM)があり、さらにその下に静止画ファイルを格納するためのDCFディレクトリ305がある。(ディレクトリ名:300ABCDE)。そして、DCFディレクトリ305の下に静止画オブジェクトの一種であるDCF基本ファイル313(例えば、ファイル名:ABCD0001.JPG)が格納される。
また、ROOTディレクトリ300の下にVIDEOイメージルートディレクトリ301(ディレクトリ名:VIDEO)があり、さらにその下に、主に動画オブジェクトを格納するためのVIDEOディレクトリ304がある。(例えば、ディレクトリ名:100ABCDE)。そして、VIDEOディレクトリ304下に、動画オブジェクト310を構成する属性情報ファイル312(拡張子がMOIであるファイル)と動画ファイル311(拡張子がMPGであるファイル)が格納される。
なお、メディアオブジェクトとして、AC−3やAAC等による圧縮音声ファイルや非圧縮の音声ファイル、MotionJPEGファイル、DCF規格で定められたDCF拡張画像ファイル、DCFサムネイルファイル、PNGファイル等、他のファイルフォーマットのAVファイルを記録してもよい。
記録されたメディアオブジェクトを管理するコンテンツ管理情報は、管理データディレクトリ303(ディレクトリ名:INFO)下のメディアオブジェクトマネージャファイル320として記録される。
また、メディアオブジェクトに対して拡張情報を付加する拡張オブジェクトも管理データディレクトリ303に記録される。図8では、拡張オブジェクトの例として、プログラムマネージャファイル330が記録されている。なお、メディアオブジェクトマネージャファイル320及び拡張オブジェクトの記録位置は管理データディレクトリ303下に限られるものではなく、例えば、VIDEOイメージルートディレクトリ301下、等でもよい。メディアオブジェクトマネージャファイル320及びプログラムマネージャファイル330の構造については後述する。
次に、図9、図10及び図11を用いて、本実施の形態1にかかる記録再生装置で用いられるディスクメディア上でデータをファイルとして管理する、UDFファイルシステムの構造を説明する。
図9は、UDFファイルシステムにおけるディレクトリ階層を管理するためのデータ構造を示す図である。なお、図9は、図8に示したディレクトリ階層構造に対応しているが、そのうちROOTディレクトリ300から属性情報ファイル312へ至るまでのファイルシステム情報のみを示しており、他のディレクトリやファイルに対する同様の情報については、説明を簡単にするため省略している。
ディレクトリ階層構造の起点はファイルセットディスクリプタ(FSD:File Set Descriptor)400である。FSD400は、図10(a)に示されるデータ構造を有している。FSD400は、拡張ファイルエントリ(EFE:Extended File Entry)510への参照情報401(ディスクメディア100上での記録位置)をRoot Directory ICB501の値として保持している。また、FSD400は、System Stream Directory ICB502からNamed Streamと呼ばれるデータを参照可能である。
Root Directory ICB501及びSystem Stream Directory ICB502は、図10(b)に示すlong_ad503という構造を持つ。long_ad503は、参照先のエクステントの長さ(Extent Length)と、位置(Extent Location)を保持する。さらに、Implementation Use504には、図10(c)に示すADImpUseの形式によりUDF UniqueID505と呼ばれる値が保持される。
また、EFE510は、図11(a)に示される構造を有している。EFE510は、ディスクメディア100上に記録された各ディレクトリやファイルを構成するエクステントの集合を管理するための構造体であり、各エクステントのディスクメディア100上での記録位置とデータ長を管理するため、図11(b)に示す構造を有するアロケーション記述子(AD:Allocation Descriptor)514と呼ばれる構造を含んでいる。各ディレクトリやファイルは複数のエクステントから構成されるので、EFE510には複数のAD514が含まれる。
その他にも、EFE510には、図11(a)に示すように、データの種別を表すディスクリプタタグ(Descriptor Tag)や、各ディレクトリやファイルごとに、ディスクメディア100上で重複しない一意のID値を設定するUnique ID511、EFE510ごとの拡張属性を設定可能なStream Directory ICB512や、拡張属性(EAs; Extended Attributes)513等が含まれる。
EAs513は、UDFファイルシステムで規定される拡張属性を格納するための領域であり、ECMA167規格等で定められた拡張属性データや、様々なアプリケーションシステム等が必要に応じて使用できる。EAs513中には、属性タイプ(Attribute Type)や属性サブタイプ(Attribute Subtype)と呼ばれるフィールドが存在し、ここに適切な値を設定することにより、この拡張属性中に含まれるデータの種別を識別できるようになっている。特定の属性タイプや属性サブタイプの値とそれに対応するデータ構造がECMA167規格等ですでに定義されている。
図12(a)に、EAs513に含まれる拡張属性データの一種で、任意のアプリケーションシステムが使用可能な処理システム用拡張属性(Implementation Use Extended Attribute)530と呼ばれる構造を示す。
アプリケーションシステムがこの処理システム用拡張属性530を使用する時には、Attribute Type、Attribute Subtype及びImplementation Identifierの各フィールドに適切な値を設定することにより、処理システム用拡張属性530中に含まれる拡張属性が、どんなアプリケーションシステムにより使用されるかを識別できるようになっている。
そして、実際の拡張属性の値は、Implementation Use Length(IU_L)でデータ長が示される可変長のフィールドImplementation Use531中に格納される。Implementation Use531中に格納される拡張属性のデータ構造は、それを使用するアプリケーションごとに決められる。
本実施の形態においてImplementation Use531中に格納される拡張属性のデータの一例として、Media Object Management Information540の構造を、図12(b)に示す。ここでは、Mo(Media Object)Unique ID541というフィールドが設けられている。本フィールドの利用例については後述する。
ROOTディレクトリ300等のディレクトリデータを含むエクステント420(図9(a)参照)は、各ディレクトリやファイルのファイル名を保持するファイル識別記述子FID(File Identifier Descriptor)520で構成される。あるディレクトリ下にサブディレクトリやファイルが存在する場合、それぞれのディレクトリ又はファイルに対してFID520が保持される。
例えば、図8によれば、ROOTディレクトリ300の下にはVIDEOイメージルートディレクトリ301とDCIMイメージルートディレクトリ302があるので、図9(a)に示すように、ROOTディレクトリ300のエクステント420には、各々に対応するFID421及び422が保持されている。
FID520は、図11(c)に示される構造を持つ。FID520は、UDF上で管理される各ディレクトリやファイルの名前(ファイル識別子)をファイル識別子(File Identifier)521として保持する。FID520はさらに、対応するディレクトリ又はファイルの実データを管理するEFE510への参照情報(例えば図9(a)の430)を、ICB522として保持する。
そのほかにも、FID520には、データの種別を表すディスクリプタタグ(Descriptor Tag)や、ファイル識別子521のデータ長を表すファイル識別子長さ(Length of File Identifier)等が含まれる。
以降、同様にEFE510とFID520の参照関係を保持することによりディレクトリの階層構造が管理され、この参照関係を順次たどることによって、任意のディレクトリやファイルの実データであるエクステントへアクセスすることが可能となる。
ファイルに関しても、EFE510によりエクステントの集合が管理される。図9の場合、エクステントの集合442がファイルを構成し、これは図8における属性情報ファイル312に相当する。
上記のFSD400やEFE510、FID520は、パーティション空間292内に配置される。図9(b)は、図9(a)のデータ構造のパーティション空間内での配置の例示図である。ここで、図9(a)と図9(b)で同じデータに関しては同じ番号を付与している。
エクステント442へアクセスするためには、FSD400から順にEFE510、FID520、・・・、EFE440のように、順次、データへアクセスする。
上述のような階層構造を持ったファイルシステムにおいて、特定のディレクトリやファイルを参照するために、パス名が利用できる。パス名は、例えば、図9のエクステント442(ファイル名:ABCD0001.MOI)に対しては、”/VIDEO/100ABCDE/ABCD0001.MOI”のように表される。ここでは、ROOTディレクトリ300及びパス区切り文字を”/”で表している。
このように、パス名は、ROOTディレクトリ300から、対象のディレクトリやファイルにたどり着くまでディレクトリ階層をたどっていく時、その経路上に存在するディレクトリの名前(ファイル識別子521に格納されている情報)を、パス区切り文字で区切りながら一続きに記述したものである。このパス名を利用すれば、ファイルシステム上で管理される任意のディレクトリやファイルを参照することが可能となる。
次に、ディスクメディア100へ記録を行なう、本実施の形態にかかる記録再生装置の動作について説明する。
まず、図13を用いて、ディスクメディア100上でのAVデータの分散配置について説明する。すなわち、図2に示すようなシステムにおいて、トラックバッファ103を有効利用することによって、AVデータを離散配置することが可能になる。
図13(a)は、ディスクメディア100上のアドレス空間を示す図である。図13(a)においては、左端がアドレス値が0の点であり、右に向かってアドレス値が増加していくものとしている。また、’0’、a1〜a4は、その位置におけるアドレス値を示している。
図13(a)に示されるように、AVデータが[a1、a2]の連続領域A1と[a3、a4]の連続領域A2に分かれて記録されている場合、光ピックアップ101がa2からa3へシーク動作を行なっている間、トラックバッファ103に蓄積してあるデータを動画デコーダ240へ供給することでAVデータの連続再生が可能になる。
この時のトラックバッファ103内のデータ蓄積量の状態を示したのが、図13(b)である。位置a1で読み出しが開始されたAVデータは、時刻t1からトラックバッファ103に入力されると共に、トラックバッファ103からデータの出力が開始される。これにより、トラックバッファ103への入力レート(Va)とトラックバッファ103からの出力レート(Vb)のレート差(Va−Vb)の分だけトラックバッファ103にデータが蓄積されていく。この状態が、光ピックアップ101がa2に達するまで、すなわち時刻t2に達するまで継続する。
この間にトラックバッファ103に蓄積されたデータ量をB(t2)とすると、時間t2から、位置a3のデータの読み出しを開始する時刻t3までの間、トラックバッファ103に蓄積されているデータ量B(t2)を消費して動画デコーダ240へ供給し続けられれば良い。
換言すると、シーク前に読み出すデータ量([a1、a2])が一定量以上確保されていれば、シークが発生した場合であっても、AVデータの連続供給が可能となる。
AVデータの連続供給が可能な連続領域のサイズは、ECCブロック数N_eccに換算すると、(数1)のように求められる。(数1)において、N_secはECCブロックを構成するセクタ数であり、S_sizeはセクタサイズ、Tjはシーク性能(最大シーク時間)である。
また、連続領域の中には欠陥セクタが生じる場合がある。この場合を考慮すると、AVデータの連続供給が可能な連続領域のサイズは(数2)のように求められる。(数2)において、dN_eccは容認する欠陥セクタのサイズであり、Tsは連続領域の中で欠陥セクタをスキップするのに要する時間である。
なお、本実施の形態1においては、ディスクメディア100からデータを読み出す場合、すなわち再生の場合について説明しているが、ディスクメディア100へデータを書き込む場合、すなわち記録又は録画の場合も同様に考えることができる。
上述したように、ディスクメディア100では、一定量以上のデータが連続記録されていれば、ディスク上にAVデータを分散記録しても連続再生が可能である。なお、例えばDVDでは、この連続領域をCDAと呼称する。あるいは、AVデータを記録する特別なエクステントであることから、AVエクステントと呼ばれることもある。
次に、図3を用いて、本実施の形態1にかかる記録再生装置の動作について説明する。図3に示した記録再生装置においては、例えばユーザI/F部200がユーザからの要求を受け付けた場合に動作を開始する。
ユーザI/F部200は、ユーザからの要求をシステム制御部104に伝え、システム制御部104は、ユーザからの要求を解釈すると共に各モジュールへの処理要求を行なう。
以下、アナログ放送をMPEG−2 PSにエンコードして動画オブジェクトとして記録する動作を例に挙げて説明する。
システム制御部104は、アナログ放送チューナ210への受信と動画エンコーダ221へのエンコードを要求する。動画エンコーダ221は、アナログ放送チューナ210から送られてくるAV信号を、ビデオエンコード、オーディオエンコード及びシステムエンコードしてトラックバッファ103に送出する。動画エンコーダ221は、エンコード開始後、アクセスマップ情報等を作成するために必要な情報をエンコード処理と平行してシステム制御部104に送る。
次に、システム制御部104は、ドライブ装置110に対して記録要求を出し、ドライブ装置110は、トラックバッファ103に蓄積されているデータを取り出してディスクメディア100に記録する。この際、前述した連続領域であるCDAをディスク上の記録可能領域から検索し、見つかったCDAにデータを記録していく。
この時、CDAとして記録可能な領域の検索は、UDF等のファイルシステムが管理する空き領域情報、例えば、スペースビットマップディスクリプタ(Space Bitmap Descriptor)に基づいて実行される。
録画終了は、ユーザからのストップ要求によって指示される。ユーザからの録画停止要求は、ユーザI/F部200を通してシステム制御部104に伝えられ、システム制御部104は、アナログ放送チューナ210と動画エンコーダ221に対して停止要求を出す。動画エンコーダ221は、システム制御部104からのエンコード停止要求を受けてエンコード処理を終了する。
システム制御部104は、エンコード処理終了後、動画エンコーダ221から受け取った情報に基づいて、アクセスマップ情報とその管理情報、等を含む属性情報を生成する。
次に、システム制御部104は、ドライブ装置110に対してトラックバッファ103に蓄積されているデータの記録終了と属性情報の記録を要求し、ドライブ装置110が、トラックバッファ103の残りデータと、属性情報を属性情報ファイル、例えば、図9に示す動画オブジェクトを構成しているファイルであるABCD0001.MOIとしてディスクメディア100に記録し、動画オブジェクトの録画処理を終了する。
なお、上記のほかに、システム制御部104は、図10や図11、図12で説明したようなUDFファイルシステムの情報を必要に応じて生成したり更新したりする。すなわち、動画オブジェクトを構成するファイルに対して、EFE510やFID520を生成し、必要な情報を設定した上でディスクメディア100上に記録する。
記録再生装置がビデオカメラである場合は、図5を参照して説明したように、AV信号源がアナログ放送チューナ210ではなくカメラ部211へ変わるだけで、他の処理は同様である。
また、デジタル放送を動画オブジェクトとして記録する動作には、動画データのエンコードは行わず、デジタル放送チューナ212及び解析部223を通じてMPEG2 TSのデータをディスクメディア100へ動画オブジェクトとして記録するようシステム制御部104が制御を行う。このとき、上述と同様に、ファイルシステム情報の記録も行われる。
次に、静止画オブジェクトの記録に関して、カメラ部211から送られてくるAV信号をJPEGエンコードして記録する動作について説明する。
システム制御部104は、カメラ部211へAV信号の出力を、静止画エンコーダ222へAV信号のエンコード実施を要求する。静止画エンコーダ222は、カメラ部211から送られるAV信号をJPEGエンコードし、トラックバッファ103に送出する。
ドライブ装置110は、システム制御部104からの指示を受けながら、トラックバッファ103に蓄積されているデータをディスクメディア100に記録する。この時、データの記録可能領域の検索は、UDF等のファイルシステムが管理する空き領域情報をもとに実行される。
一つの静止画オブジェクトが記録されたら撮影は終了する。あるいは、ユーザから連続撮影の指示があった場合は、ユーザからの撮影停止要求によって終了するか、所定の枚数の静止画オブジェクトを記録して終了する。ユーザからの撮影停止要求は、ユーザI/F部200を通してシステム制御部104に伝えられ、システム制御部104はカメラ部211と静止画エンコーダ222に対して停止要求を出す。
さらに、システム制御部104は、UDFファイルシステムの情報についても必要な処理を行う。すなわち、静止画オブジェクトを構成するファイルに対して、EFE510やFID520等を生成し、必要な情報を設定した上でディスクメディア100上に記録する。
以上のような手順でディスクメディア100に記録される各メディアオブジェクトは、後々の管理のために、図8で示したメディアオブジェクトマネージ320に登録される。各メディアオブジェクトとメディアオブジェクトマネージ320との関係については後述する。なお、本発明においてはEFE510を用いて説明を行っているが、その代わりにFEを用いてもかまわない。
図14は、本実施の形態1における記録再生装置で用いられるディスクメディア100上に記録されるデータの階層構造と、それらを処理するシステム制御部104及びその内部構造の一例を示す図である。
ディスクメディア100上にはファイルシステム情報600が記録される。ファイルシステム情報600には、図7(c)で示したボリューム構造情報290や、図10、図11及び図12で示したFSD400、EFE510、FID520、また上述したスペースビットマップディスクリプタ(Space Bitmap Descriptor)等が含まれる。
また、複数のメディアオブジェクトをまとめて管理するためのメディアオブジェクトマネージャ320が同様にファイルとして管理され、コンテンツ管理情報601を構成する。
さらに、メディアオブジェクトに拡張情報602を付与する拡張オブジェクト603もファイルとして管理される。プログラムマネージャ330も拡張オブジェクトの一例であり、複数のメディアオブジェクトの内容や記録日時等に応じて整理分類したり、ユーザが自由な再生順序を設定するプログラム再生を行ったりするための拡張情報を格納するために設けられている。
これらのディスクメディア100に記録されるデータは、システムバス105を通じて、システム制御部104により操作される。
一方、システム制御部104は、より詳細には、オペレーティングシステム(OS)とアプリケーションシステムとからなる。
オペレーティングシステムには、ファイルシステム情報600を制御するファイルシステム処理部610や、特に図示されていないハードウエアの制御を行うデバイスドライバ部、メモリ制御部、等が含まれ、アプリケーションシステムに対して、API(Application Program Interface)を通じてさまざまな共通機能を提供する。これにより、アプリケーションシステムをハードウエアやファイルシステムの詳細とは分離した形で実現することが可能となる。
一方、アプリケーションシステムでは、特定のアプリケーションのための制御動作を行う。本実施の形態1においては、例えば図3を用いて説明したように、動画オブジェクトや静止画オブジェクトの記録あるいは再生処理に関する制御を行う。
また、アプリケーションシステム中のコンテンツ管理情報処理部611は、コンテンツ管理情報601及びそこに含まれるメディアオブジェクトマネージャ320に対する操作を行う。
そして、拡張情報処理部612は、拡張情報602及びそこに含まれる拡張オブジェクト603に対する操作を行う。拡張オブジェクト603に対する操作については、後でさらに説明する。
また、アプリケーションシステムには、その他にも必要に応じて、AVデータの表示や、ユーザインタフェースを処理する部分等を含む場合もある。
メディアオブジェクトマネージャ320のデータ構造については、図15〜図16を用いて以下に説明する。
図15(a)は、メディアオブジェクトマネージャ320のデータ構造の例示図である。図15(a)に示すようにメディアオブジェクトマネージャ320は、ヘッダ部700とデータ部701とから構成される。
ヘッダ部700には、ファイルのタイプを表すDataType、ファイルのサイズを表すDataSize、メディアオブジェクトマネージャ320の更新日時であるModTime702、等が含まれる。また、拡張情報602を管理するための拡張オブジェクト管理情報テーブル710が含まれる。なお、LastMoUniqueID703については後述する。
データ部701は、メディアオブジェクト管理情報テーブル730を含む。メディアオブジェクト管理情報テーブル730は、メディアオブジェクトマネージャ320中に含まれるメディアオブジェクト管理情報(MO_INFO)700の数を示すNumMoInfoと、NumMoInfo個のMO_INFO700から構成される。
なお、図15等におけるフィールド名欄の表記は、データ型とフィールド名を続けて記述しており、データ型については、例えば以下のような意味を示している。
constは、フィールドが定数であることを意味しており、constがない場合は変数であることを示している。unsignedは、当該フィールドは符号無しの値であることを示しており、unsignedがない場合は符号付きの値であることを示している。また、int()は、フィールドはカッコ内のビット長を持つ整数値であることを示している。例えば、カッコ内の値が’16’である場合には、16ビット長であることを意味する。また、stringは文字列情報であることを意味する。
図15(b)は、メディアオブジェクトマネージャ320に含まれる拡張オブジェクト管理情報(EO_INFO)720のデータ構造である。EO_INFO720は、プログラムマネージャ330のような拡張オブジェクトを登録・管理するデータ構造であり、各拡張オブジェクトをそれぞれ識別するための型情報を示すEoType721及びEoSubType722を持つ。
EoType721及びEoSubType722には、例えば、拡張オブジェクトの所有者(オーナー)情報やその使用目的を示す情報を数値やアルファベット値として格納しても良い。
さらにEO_INFO720は、拡張オブジェクトへの参照情報をパス名により保持する拡張オブジェクト参照情報EoRef723、図15(c)で示される属性フラグであるEoFlags724、拡張オブジェクトの概要を示す文字列情報を格納するTextDesc726、等から構成される。
図15(c)は、EO_INFO720が指し示す拡張オブジェクトに関する様々な情報をフラグとして格納するEoFlags724の構造例である。本実施の形態においては、0ビット目をValidフィールドとしている。
Validフィールドの値が1bの場合、メディアオブジェクトマネージャ320及びそれが管理するメディアオブジェクトと、EO_INFO720が指し示す拡張オブジェクトとの整合性が維持されており、該拡張オブジェクトに含まれる情報が有効であることが保障されている状態を示す。一方、Validフィールドの値が0bの場合は、その保障がないことを示す。
図16(a)は、メディアオブジェクトマネージャ320に含まれるメディアオブジェクト管理情報(MO_INFO)740のデータ構造である。
MO_INFO740は、登録されるメディアオブジェクトの型情報を示すMoType741、メディアオブジェクトへの参照情報であるオブジェクト参照情報MoRef742、少なくともメディアオブジェクトマネージャ320内で重複しない値であるメディアユニークIDが設定されるMoUniqueID743、等から構成される。
重複しないメディアユニークIDの設定方法は、例えば、初期値を0とし、メディアオブジェクトを新たに記録するたびにメディアユニークIDの値を1ずつ加算しながら割り当てていく。そして、ある時点でのメディアユニークIDの最大値をLastMoUniqueID703に記録しておくことにより、記録を一旦中断した時にも次に割り当てるメディアユニークIDの値(すなわち、LastMoUniqueID703に1を加算した値)を容易に決めることができる。
あるいは、図11を用いて説明したように、UDFファイルシステムはファイルシステム上で、各ファイルに対して重複しないUniqueID511を設定するので、このUnique ID511の値をメディアユニークIDの値として流用することも可能である。
なお、本実施の形態においては、MoUniqueID743に設定された値と同じ値を図11(a)で示したEFE510のEAs513中にMoUniqueID541として設定するようにしてもよい。
その他にも、各種属性情報を示すAttributes、当該メディアオブジェクトの再生時間であるPlayBackDuration、MO_INFO740とは異なる場所に格納されるテキスト情報への参照情報TextIDやサムネイル情報への参照情報ThumID等も含んでいる。
図16(b)に示すように、MoType741に設定される値は、参照先のメディアオブジェクトの種類により決まる。
MoTypeの値が’1’である場合、あるオブジェクトメディア情報に登録されているメディアオブジェクトの種類は、ファイルシステム上のあるディレクトリである。同様に、値が’2’の場合には動画オブジェクト(拡張子:MOI)を、値が’3’の時は静止画オブジェクト(拡張子:JPG)を、それぞれ示す。以下同様に、メディアオブジェクトの種類ごとに異なるMoTypeの値を割り当てることとする。
また、MoRef742へ設定される値は、参照先のメディアオブジェクトの持つパス名情報を図16(c)に示す変換規則により変換することにより決定される。
最初のフィールドParent Dir NoはMO_INFO740が参照するメディアオブジェクトの親ディレクトリのパス名により決められる。すなわち、親ディレクトリがVIDEOイメージルートディレクトリ301の場合は’0’、DCIMイメージルートディレクトリ302の場合は’1’となる。それ以外の値については、本実施の形態1では使用しないので予約値としている。
もちろん、変換規則によって与えられる値は別の組み合わせであってもよく、例えば、VIDEOイメージルートディレクトリ301に’1’を、DCIMイメージルートディレクトリ302に’2’を割り当て、その他の場合を予約値とするようにしてもかまわない。
次のフィールドであるDir Noには、MO_INFO740に登録されたメディアオブジェクトのディレクトリ番号部分を抜き出して格納する。ここでディレクトリ番号とは、メディアオブジェクトの上位ディレクトリのディレクトリ名における数値部分である。
次のフィールドであるFile Noには、MO_INFO740に登録されたメディアオブジェクトのファイル番号を抜き出して格納する。ここでファイル番号とは、メディアオブジェクトのファイル名における数値部分である。
例えば、メディアオブジェクトのパス名が、“/VIDEO/100ABCDE/ABCD0001.MOI”である場合、当該メディアオブジェクトは“/VIDEO”ディレクトリを親ディレクトリとして持つので、OBJ_IDのParent Dir Noの値は’0’、そして当該メディアオブジェクトの上位ディレクトリ名の数値部分の値が100であるので、OBJ_IDのDir Noの値は’100’となる。さらに、当該メディアオブジェクトのファイル名の数値部分の値をとって、OBJ_IDのFile Noの値は’0001’となる。
以上より、MoRef742に設定される値は、“/”を区切りとし、Parent Dir No、Dir No、File Noの順に並べる表記によれば、0/100/0001となる。以降、OBJ_IDの値を必要に応じて同様の表記により示す。
OBJ_IDをこのような形式としても、DCF規格の命名規則のように、メディアオブジェクトの名前やその上位ディレクトリの名前に含まれる数値部分の値が重複しないような命名規則を守っておけば、上述のMoType741の値から導かれる拡張子情報とあわせて、ファイルシステム上で、MoRef742が参照しているメディアオブジェクトを特定することが可能である。このような構成はMO_INFO740のデータ量を減らす目的に好適である。
もちろん、OBJ_IDのデータ構造は、MO_INFO740とメディアオブジェクトが一意に対応づけられる形式であれば他の形式でもよい。例えば、メディアオブジェクトのパス情報をそのまま格納する方法もある。すなわち、“/VIDOE/100ABCDE/ABCD0001.MOI”のように、“/”をパス区切り文字としたフルパス名の文字列を格納してもよい。
あるいは、MoType740の部分の代わりに、ファイルの拡張子を格納するようにしてもよい。例えば“/VIDOE/100ABCDE/ABCD0001.MOI”というファイルに対しては“MOI”の部分を格納するようにしてもよい。
なお、動画オブジェクトについては、属性情報ファイル(例えば、図8における312)だけをメディアオブジェクト管理情報に登録してもよい。対応する動画ファイル(この場合、図8における311)は、上述のようにファイル名の対応付け等により属性情報ファイルから知ることができるからである。あるいは、逆に、動画ファイルをメディアオブジェクト管理情報に登録するようにしてもよい。同様に対応する属性情報ファイルを知ることができるからである。もちろん、属性情報ファイルと動画ファイルの両方を登録してもかまわない。
次に本実施の形態における拡張オブジェクトの一例であるプログラムマネージャ330のデータ構造について、図17を用いて以下に説明する。
拡張オブジェクトの共通構造として、ヘッダ部800とデータ部801を持つ。
ヘッダ部800は、ファイルのタイプを表すDataType(拡張オブジェクトを示す固定値を設定)、ファイルのサイズを表すDataSize、拡張オブジェクトの型情報を示すEoType811及びEoSubType812、更新時刻を示すModTime813、拡張オブジェクトの概要を示す文字列情報を格納するTextDesc814、等から構成される。
ヘッダ部800において、EoType811、EoSubType812の値により拡張オブジェクトの種類分けを行う。
また、拡張オブジェクトはEO_INFO720から参照されるが、この時、EoType811、EoSubType812及びTextDesc814の値が、EO_INFO720中のEoType721、EoSubType722及びTextDesc726へと設定される。
一方、データ部801は、拡張オブジェクトの種類ごとに固有の拡張データを格納し、EoType811、EoSubType812の値により異なるデータ構造を持つ。
図17(a)は、プログラム再生を行うための拡張オブジェクトであるプログラムマネージャ330の場合の例であり、拡張データとして次のような構造を持つ。
プログラムマネージャ330に登録されたすべてのメディアオブジェクトの再生時間の合計であるPlayBackDuration、プログラムマネージャ330中に含まれるプログラム情報(PRG_INFO)820の数を示すNumPrgInfo、そして、NumPrgInfo個のPRG_INFO820からなるプログラム情報テーブル830で構成される。
そして、図17(b)はプログラムマネージャ330に含まれるプログラム情報(PRG_INFO)820のデータ構造である。PRG_INFO820は、MO_INFO740をグループ化し、ディスクメディア100上に記録された複数のメディアオブジェクトの分類を行ったり、あるいは、PRG_INFO820から参照しているメディアオブジェクトを順に再生することにより、プログラム再生を実現するときの一つの単位である。
図17(b)に示すように、PRG_INFO820は、プログラム情報であることを示すDataType、PRG_INFO820のサイズを示すDataSize、プログラムの各種属性情報を示すAttributes、プログラムの再生時間であるPayBackDuration、PRG_INFO820中に含まれるMO_INFO740への参照の数を示すNumMoInfo、そして、NumMoInfo個のMoIDからなるMO_INFO740への参照テーブル、等から構成される。
その他にも、PRG_INFO820とは異なる場所に格納されるテキスト情報への参照情報TextIDやサムネイル情報への参照情報ThumID等も含んでもよい。
本構造により、拡張オブジェクトであるプログラムマネージャ330は、任意のメディアオブジェクトをグループ化することが可能となる。これにより、ファイルシステム上のディレクトリ構造とは独立して、仮想的なフォルダー構造を構成し、メディアオブジェクトの自由な分類整理を行える。また、ユーザの望みの再生順序でメディアオブジェクトを再生するプログラム再生等の機能も実現できる。
次に、図18を用いて、ファイルシステムで管理されるディレクトリやメディアオブジェクトと、MO_INFO740との関係を説明する。
メディアオブジェクトマネージャ320には、複数のMO_INFO740が含まれており、それぞれにメディアオブジェクトが登録されている。例えば、MoInfo[1]900には、ディレクトリ304が登録されている。この時、MoInfo[1]900のフィールドの値は次のように設定される。
まずMoTypeは、図16(b)より、ディレクトリを示す’1’が設定される。MoRefは、図16(c)より、親ディレクトリ’0’、ディレクトリ番号’100’、ファイル番号’0000’となり、フィールド値全体としては0/100/0000となる。
MoUniqueID743は、ここでは’100’が設定されており、他のMO_INFOに設定されている値と重複していない。
また、MoInfo[2]901のフィールドの値は次のように設定される。まずMoTypeは、動画オブジェクトを示す’2’が設定される。MoRef711は、親ディレクトリ’0’、ディレクトリ番号’100’、ファイル番号’0001’となり、フィールド値全体としては0/100/0001となる。MoUniqueIDは、重複しない値として’101’が設定されている。以降、その他のMoInfoも同様に値が設定される。
図19は、このようなメディアオブジェクトマネージャ320に対する、プログラムマネージャ330の関係を示すものである。上述のように、プログラムマネージャ330には複数のPRG_INFO800(PrgInfo[1]910〜)が含まれる。
各PRG_INFO800は、MO_INFO700への参照情報を、メディアユニークIDとして保持する。すなわち、MO_INFO700がMoUniqueID712で保持しているメディアユニークIDの値を参照情報とする。
例えば、PrgInfo[1]910では、図19中の波線矢印で示すように、MoInfo[2]とMoInfo[5]とMoInfo[8]への参照を持つので、MoIDのテーブル(MoID[])の値として、101、104、201を保持する。PrgInfo[2]911でも同様に、MoInfo[6]とMoInfo[8]への参照を持つので、MoID[]の値として、105、201を保持する。
この状態において、プログラム再生を実施するための処理について説明する。例えば、PrgInfo[1]910によるプログラム再生の開始が指示されたとすると、コンテンツ管理情報処理部611は、PrgInfo[1]910内のメディアオブジェクト情報への参照テーブルMoID[]内の値を読み出す。上述したとおり、MoID[]には、プログラム再生の対象となるメディアオブジェクトへの参照情報がメディアユニークIDとして保持されている。
よって、プログラム再生を行うには、MoID[]に保持されているメディアユニークIDの指し示すMO_INFO740をメディアオブジェクトマネージャ320中から検索し、それが見つかったら、MO_INFO740が参照するメディアオブジェクトの再生を行う。
MoID[]に保持されているすべてのメディアユニークIDに対して同様の手順を繰り返すことによりプログラム再生が実行される。
図20は、複数の拡張オブジェクトが存在する場合において、ファイルシステムで管理されるディレクトリやメディアオブジェクト、メディアオブジェクトマネージャ320との関係を示すものである。ここでは、プログラムマネージャ330とは異なる拡張オブジェクト1000と1001が存在する。
図19を用いて説明したのと同様に、拡張オブジェクト1000と1001はメディアオブジェクトマネージャ320を経由して(例えば、プログラムマネージャ330と同様にメディアユニークIDにより)メディアオブジェクトに対応付けられており、さまざまな拡張情報を提供する。
例えば、拡張オブジェクト1000は、各メディアオブジェクトがこれまでに何回再生されたかの再生回数のカウント値を保持する拡張オブジェクトである。各メディアオブジェクトが再生されるたびにそのカウント値を増加させて、拡張オブジェクト1000内に保持する。このようなカウント値を拡張情報として保持しておくことにより、あるメディアオブジェクトをユーザが既に視聴したかどうかを示すことが出来る。
あるいは、再生回数のカウント値をユーザの録画映像に対する好みの判定に用いることも出来る。例えばカウント値が大きい場合は、ユーザの好みの映像が録画されていると判断し、逆に、カウント値が少ないメディアオブジェクトは好みではないと判断する。このような情報は、例えば、記録媒体100上の空き容量が少なくなったとき、不要なメディアオブジェクトの削除を行う時の参考情報として用いることが可能である。
また、拡張オブジェクト1001は、各メディアオブジェクトに対するGPS情報を格納する。各メディアオブジェクトが記録された時点での位置情報を記録しておき、後に検索や表示するために用いることが可能である。
ユーザが旅行の記念撮影などを行った時に、GPS情報があれば、行き先の位置情報を頼りに、多数のメディアオブジェクトから目的のメディアオブジェクトを容易に探し出すことが可能となる。
なお、拡張オブジェクトとして保持するデータとしては、上記に限られるものではなく、他のデータでもよい。例えば、各メディアオブジェクトに対するcameraパラメータ(記録時のカメラの種別、ズームの有無、フラッシュの有無、等)や、MPEG7などのメタデータ等でもよい。その他、製造メーカが他社製品との差別化やユーザに対する独自の利便性を提供することを目的として、メディアオブジェクトマネージャ320等の統一規格に含まれない機能を実現するために利用してよい。
図21は、図20の状態において、拡張オブジェクト管理情報テーブル710に設定される値の例を示す図である。
図21(a)の一つの行がEO_INFO720に相当する。各EO_INFOのEoType及びEoSubtypeは、それぞれの拡張オブジェクトの内容を識別するための値(ここではそれぞれ2文字のアスキーコード)が設定される。なお、各EoType及びEoSubtypeの値は一例であり、各拡張オブジェクトが識別可能であれば他の値でもかまわない。
EoRefとして、ここでは、拡張オブジェクトのファイル名を格納する。なお、拡張オブジェクトを参照する時のデータ形式は他の形式でもよく、MO_INFO740がメディアオブジェクトを参照する時に使用するOBJ_IDのように、ファイル番号などの特定の変換規則を利用することも可能である。
EoFlagsについては、ここでは、すべての情報が有効であるとし、Valid=1bがすべて設定されている。TextDescは、それぞれの拡張オブジェクトの保持する情報の内容を簡単な文字列として保持している。
図22は、本実施の形態において、新規の拡張オブジェクト及び拡張データを記録するための処理を示すフローチャートである。
まず、拡張情報処理部612が、拡張オブジェクト管理情報テーブル710をメディアオブジェクトマネージャ320から読み出す(ステップS101)。
次に、拡張オブジェクト管理情報テーブル710中の各EO_INFO720の値を調べることにより、追加したい拡張データを含む拡張オブジェクトがすでに存在しているかどうかを調べる(ステップS102)。
拡張オブジェクトが存在していない場合は新規に作成し(ステップS103)、対応するEO_INFO720を拡張オブジェクト管理情報テーブル710へと追加する(ステップS104)。拡張オブジェクトが存在していた場合及び新規に作成した後は、その拡張オブジェクトへ拡張データを追加する(ステップS105)。
図23は、本実施の形態において、メディアオブジェクト及びMOINFO740に対する何らかの操作が行われた後、拡張オブジェクト管理情報テーブル710に対して行われる処理を示すフローチャートである。ここで、メディアオブジェクト及びMO_INFO740に対する何らかの操作とは、例えば、メディアオブジェクトやMO_INFO740中のデータ値の書き換えや編集及び削除、等のことである。
このような操作が行われると、メディアオブジェクト及びメディアオブジェクトマネージャ320と、拡張オブジェクト及び拡張データ間の情報の不整合が発生する場合がある。
例えば、拡張データの一種であるPRG_INFO820から参照されているメディアオブジェクトが削除されてしまうと、PRG_INFO820からの参照先がなくなってしまい、プログラム再生の実行の際に不都合が生じる。
プログラム再生以外の他の拡張データの場合も同じで、参照先のメディアオブジェクトやMO_INFO740が変更されると、不整合が発生する。
そこで本実施の形態においては、メディアオブジェクト及びメディアオブジェクトマネージャ320に対して何らかの操作が行われると以下の処理を実施する。
まず、拡張情報処理部612は、拡張オブジェクト管理情報テーブル710をメディアオブジェクトマネージャ320から読み出す(ステップS201)。
拡張オブジェクト管理情報テーブル710には、TotalNumEoInfo704で示される数だけEO_INFO720が存在するので、ステップS202からステップS208のループ処理によりすべてのEO_INFO720に対する処理を行う。
まず、ループ処理のカウント値を初期化し(ステップS202)する。
そして、最初の拡張オブジェクトに対して、処理可能かどうかを判別する(ステップS203)。この判別には、EoType721及びEoSubtype722やEoRef723が利用可能である。
ある記録再生装置は、特定の種類の拡張オブジェクトしか操作できない場合があるので、もし、処理不可能な拡張オブジェクトであることがわかったら、Validフラグ731を0bに設定する(ステップS204)。これにより、該拡張オブジェクトとメディアオブジェクト及びメディアオブジェクトマネージャ320との間での整合性を保障しない状態であることを示す。一方、処理可能な拡張オブジェクトであることがわかったら、該拡張オブジェクトの内容を更新し(ステップS205)、Validフラグ731を1bに設定する(ステップS206)。
ここで、該拡張オブジェクトの内容を更新とは、先に行われたメディアオブジェクト及びメディアオブジェクトマネージャ320に対する操作の結果と、該拡張オブジェクトの内容が整合するような処理である。
例えば、拡張オブジェクトがプログラムマネージャ330であり、メディアオブジェクト及びメディアオブジェクトマネージャ320に対する操作が、メディアオブジェクト及びそれを参照するMO_INFO740の削除であった場合、プログラムマネージャ330に対しては、該MO_INFO740を参照するPRG_INFO820を更新し、削除された該MO_INFO740への参照を削除する処理を行う。他の種類の拡張オブジェクトに対しても、それぞれの拡張情報に応じた更新処理を実施する。
更新処理を実施することにより、該拡張オブジェクトとメディアオブジェクト及びメディアオブジェクトマネージャ320との間での整合性を保障できるので、Validフラグ731を1bに設定している。
以降、カウント値を加算しながら、TotalNumEoInfoの値に等しくなるまで処理を繰り返す(ステップS207、ステップS208)。
図23のような処理が終了した後の拡張オブジェクト管理情報テーブル710に設定される値の例を図21(b)に示す。
ここでは、一例として、拡張オブジェクトとしてプログラム再生のみを処理可能であり、他の種類の拡張オブジェクトの処理ができない記録再生装置による処理後の設定値の例を記す。2行目以降のEO_INFO720のValidフラグが0bに設定され、これらの拡張オブジェクトのデータの有効性が保障されない状態であることを示している。
図24は、本実施の形態において、特定の種類の拡張オブジェクトを指定してそのデータを利用する際の処理に関するフローチャートである。
まず、拡張情報処理部612は、拡張オブジェクト管理情報テーブル710をメディアオブジェクトマネージャ320から読み出す(ステップS301)。
次に、拡張オブジェクト管理情報テーブル710内を検索し、目的の拡張オブジェクトを参照しているEO_INFO720を得る(ステップS302)。目的の拡張オブジェクトの検出は、EoType721及びEoSubtype722の値を調べることにより行える。あるいは拡張オブジェクトのパス名の命名側を決めておくことにより、EoRef723の値を見ることにより検出可能である。
もし、目的の拡張オブジェクトを参照しているEO_INFO720が見つからなければ、例外処理を行い(ステップS303)、本フローチャートで示す処理を終了する。例外処理とは例えば、ユーザに所望の拡張オブジェクトが存在しないことを知らせるメッセージを表示したり、あるいは、新たに、該拡張オブジェクトを作成したりする処理などである。
もし、目的の拡張オブジェクトを参照しているEO_INFO720が見つかれば、Validフラグの値が1bであるかを調べる(ステップS304)。
Validフラグの値が1bでなければ例外処理を実施する(ステップS305)。ここでの例外処理とは例えば、ユーザに所望の拡張オブジェクトとメディアオブジェクトマネージャ320との間で不整合が存在することを知らせるメッセージを表示したり、記録媒体100の書き込みを禁止したり、あるいは、該拡張オブジェクトとメディアオブジェクトマネージャ320の不整合を解消すべく、該拡張オブジェクト内の情報を更新する処理を実施したりする処理、等である。
一方、Validフラグの値が1bであれば、該拡張オブジェクトに対する通常処理を実施する(ステップS306)。通常処理とは、例えば、該拡張オブジェクトが、プログラムマネージャ330であれば、プログラム再生を実施することである。
他の拡張オブジェクトに関しても、あるメディアオブジェクトに関連付けられている拡張データをユーザに対して表示する(GPS情報の表示など)、等、夫々の種類に応じた動作を行う。
図24中の例外処理を行う場合に、少なくともTextDesc726の値を表示するようにすれば、どんな拡張情報が設定されているかをユーザに知らせることが可能である。
以上により、メディアオブジェクトマネージャ320のデータ容量を大幅には増加させず、拡張情報の追加が行える。
これは、DVDレコーダやDVDビデオカメラのような民生の家電機器等のハードウエア資源が限られる記録再生装置において望ましい構成である。また、メディアオブジェクトの編集や削除を行った場合に、ある記録再生装置が対応していない拡張機能が存在しても、データの不整合を最小限に抑制し、かつ、適切なデータ処理方法を決定可能となり、機器の誤動作やシステム停止、ユーザに対する利便性の低下等を回避することが可能となる。
これは、DVDレコーダやDVDビデオカメラなどの可搬型の記録媒体を用いた記録再生装置において、1つの記録媒体が複数の製造メーカによる記録再生装置で記録・再生される場合において望ましい構成である。
(実施の形態2)
本実施の形態では、実施の形態1とは異なる拡張オブジェクトの管理の方法について述べる。実施の形態1では、拡張オブジェクト管理情報テーブル710により拡張オブジェクトを管理したが、本実施の形態では、MO_INFOにより各拡張オブジェクトを管理する。
このときの、拡張オブジェクトとMO_INFOの関係を図25に示す。ここでは、メディアオブジェクトマネージャ320に含まれるMO_INFOであるMoInfo[i]〜MoInfo[i+2]がそれぞれ拡張オブジェクト1000、330、1001を参照、管理しているものとする。ただし、本実施の形態におけるMO_INFOは、図26に示す構造を持つものとする。
図26(a)におけるMO_INFO2000は、MO_INFO740に対して、EO_INFO2100のフィールドが追加されている点を除いて同一である。
EO_INFO2100は、EO_INFO720と異なる構造を持ち、図26(b)で示す構造を持つ。
EO_INFO2100は、EO_INFO720からEoRef723とTextDesc726を除いた構造を持ち、EoRef723の代わりにMoType741とMoRef742を、TextDesc726の代わりにTextID744を用いることで同様の機能を果たす。すなわち、MoType741とMoRef742により拡張オブジェクトを参照し、TextDesc726により拡張オブジェクトに対する文字列情報を格納する。
なお、上記機能を実現するために、図16(b)のMoType741の値に対して、拡張オブジェクト(拡張子:EXT)を示す値(例えば“4”)を定義することとする。
また、MoRef 742による参照を行うために、拡張オブジェクトのディレクトリ名やファイル名は、ディレクトリ番号及びファイル番号による一意な参照が可能となるような命名則を用いる。
上記構成により、メディアオブジェクトと拡張オブジェクトを共通の枠組みで管理することが可能となり、装置の実装上、好都合である。
(実施の形態3)
本実施の形態では、異なる拡張オブジェクトの管理の方法について述べる。
実施の形態1では、拡張オブジェクト管理情報テーブル710のValidフラグ731において拡張オブジェクトの有効性を管理したが、本実施の形態では、MO_INFOにおいて各拡張オブジェクトの有効性を管理する。
このとき、メディアオブジェクトを参照・管理するMO_INFOは図27に示すデータ構造を持つものとする。
図27(a)におけるMO_INFO3000は、MO_INFO740に対して、拡張データ属性フラグ(RefValidFlag)3100のフィールドが追加されている点を除いて同一である。
RefValidFlag3100は、図27(b)に示す情報を保持する。RefValidFlag3100では、2ビットがひとつの拡張オブジェクトに対応している。
例えば、ビット0〜1は、拡張オブジェクトの内、ファイル番号が0001番を持つものに対応する。同様に、ビット1〜2はファイル番号が0002番に対応し、以降も同様である。
そして、この各2ビットの解釈は、次のとおりである。すなわち、上位ビットは、該MO_INFO3000が管理するメディアオブジェクトに対して、拡張オブジェクトからの参照が存在する(1b)か、存在しない(0b)かを示す。そして、下位ビットは、MO_INFO3000が管理するメディアオブジェクトに対する拡張データが有効である(1b)か無効である(0b)かを示す。
すなわち、この下位ビットは、Validフラグ731と同じ意味を持つ。ただし、このRefValidFlag3100の下位ビットは、MO_INFO3000単位で拡張データが有効かどうかを示すことができ、より詳細な単位での拡張データの管理が可能となっている。
具体的には、例えば図20に示したのと同様な参照関係が存在する場合、図20中のMoInfo[1]のRefValidFlag3100に設定される値は、図27(b)の右端の列「設定値の例」のようになる。
すなわち、MoInfo[1]は、ファイル番号0001を持つ拡張オブジェクトであるプログラムマネージャ330からの参照を持ち、かつその値が有効であるとすると、ビット0〜1は11bという値に設定される。また、同様に、ファイル番号0002を持つ拡張オブジェクトからも参照されており、かつその値が有効であるとすると、ビット2〜3は11bという値に設定される。
一方、ファイル番号0016を持つ拡張オブジェクトも存在するが、そこからは参照されていないので、ビット30〜31は00bという値に設定される。
また、上記状態から、図23を用いて説明した処理と同様、メディアオブジェクトに対する編集操作等が行われると拡張オブジェクトとの整合性が保証されない場合が発生する。
例えば、拡張データの一種であるPRG_INFO820から参照されているメディアオブジェクトが編集され、その再生時間長が変化してしまう(例えば、再生時間が短くなる)と、プログラムの再生時間であるPlayBackDurationが実際の値と異なってしまい、プログラム再生の実行の際にユーザに混乱を与えてしまう。
そこでこの時、図28で示す処理を実施する。
まず、拡張情報処理部612は、編集対象のメディアオブジェク管理情報3000からRefValidFlag3100を読み出す(ステップS401)。
RefValidFlag3100のフィールド長に応じた数だけ拡張オブジェクトが存在する可能性があるので、ステップS402からステップS409のループ処理により、存在するすべての拡張オブジェクトに対する処理を行う。
次に、ループ処理のカウント値を初期化(ステップS402)する。
そして、最初の拡張オブジェクトに対して、該メディアオブジェクトに対して参照する拡張オブジェクトが存在するかを判別する(ステップS203)。この判別は、該拡張オブジェクトに対応するRefValidFlag3100中の2ビットの内、上位ビットの値により行われる。もし、参照が存在しない場合は、ステップ408へ進む。
参照が存在した場合は、該拡張オブジェクトに対して、処理可能かどうかを判別する(ステップS404)。
ある記録再生装置は、特定の種類の拡張オブジェクトしか操作できない場合があるので、もし、処理不可能な拡張オブジェクトであることがわかったら、該拡張オブジェクトに対応するRefValidFlag3100中の2ビットの内、下位ビットの値を0bに設定する(ステップS405)。これにより、該拡張オブジェクトと該メディアオブジェクトとの間での整合性を保障しない状態であることを示す。
一方、処理可能な拡張オブジェクトであることがわかったら、該拡張オブジェクトの内容を更新し(ステップS406)、該拡張オブジェクトに対応するRefValidFlag3100中の2ビットの内、下位ビットの値を1bに設定する(ステップS407)。ここで、拡張オブジェクトの内容を更新とは、例えば、メディアオブジェクトの編集に伴い、プログラムのPlayBackDurationを更新する処理である。
以降、カウント値を加算しながら、全てのRefValidFlag3100に対して処理を繰り返す(ステップS408、ステップS409)。
図28のような処理が終了した後のRefValidFlag3100に設定される値の例を図29に示す。
ここでは、一例として、拡張オブジェクトとしてプログラム再生のみを処理可能であり、他の種類の拡張オブジェクトの処理ができない記録再生装置による処理後の設定値の例を記す。RefValidFlag3100ビット2については1bのまま変化がなく、一方、ビット3が0bに設定され、この拡張オブジェクトからの参照は依然として存在するが、そのデータの有効性が保障されない状態であることを示している。
以上のように、実施の形態1においては、拡張オブジェクト全体に対して有効かどうかをValidフラグ731を用いて管理したが、本実施の形態においては、RefValidFlag3100の下位ビットを用いることにより、メディアオブジェクト及びMO_INFO毎に有効性の管理が可能となり、拡張オブジェクト全体を更新せず、その一部だけを更新するような、より柔軟な管理が可能となる。
また、図24を用いて説明したのと同様、RefValidFlag3100の下位ビットの値を見る(すなわち、図24のステップS304に相当する処理を実施する)ことにより、拡張オブジェクトの情報が有効な場合は通常処理を行い、有効性が保証されない場合は、適切な例外処理や書き込みの禁止、ユーザへのメッセージの表示などを行うことが可能である。
このような構成は、特にメディアオブジェクトマネージャのデータ量が大きい場合、必ずしもその全体を更新しなくてよいので、データ処理量の効率化に有効である。
なお、本実施の形態においては、RefValidFlag3100を32ビット長としたが、他のデータ長でもよく、あるいは、可変長にすることも可能である。可変長にすることにより効率的に拡張オブジェクトの数の変化に対応可能となる。
また、上記においては、RefValidFlag3100のビット0〜1をファイル番号が0001番である拡張オブジェクトに対応するとしたが、RefValidFlag3100の各ビットと拡張オブジェクトとの対応関係についてはこれに限るものではない。例えば、ビット30〜31のようなRefValidFlag3100の上位ビットにファイル番号が0001番である拡張オブジェクトを対応させるようにしても良い。
また、RefValidFlag3100と拡張オブジェクトをそのファイル番号により対応づけたが、他の方法による対応付けを行ってもよい。
(実施の形態4)
本実施の形態では、更新日時情報を用いた拡張オブジェクトの有効性管理方法について述べる。
図15(a)で示したように、メディアオブジェクトマネージャ320には、その更新日時を示すModTime702が設けられている。メディアオブジェクトマネージャ320の内容が更新されるたびに、ModTime702の値も更新するものとする。
一方、拡張オブジェクトにもその更新日時を示すModTime812が設けられている。ModTime813も同様に、拡張オブジェクトの内容が更新されるたびに、その値が更新されるものとする。
ただし、図23の処理手順で示したとおり、本発明の記録再生装置においては、処理可能な拡張オブジェクトのみをその内容を更新するものとする(図23のステップS205)。
これにより、メディアオブジェクトに対する編集操作等が行われると、メディアオブジェクトマネージャ320が更新され、さらに、処理可能な拡張オブジェクトのみが更新される。
結果として、ModTime702の値と、処理可能な拡張オブジェクトのModTime813が一致する。一方、処理不可能な拡張オブジェクトは更新されないのでそのModTime813も更新されず、ModTime702の値と一致しなくなる。
よって、本発明の記録再生装置において、ある拡張オブジェクトを処理しようとする時、ModTime702の値とのModTime813の値を比較することにより、該拡張オブジェクトが有効であるかどうかを知ることができる。
これはすなわち、図24で示したValidフラグの値が1bであるかどうかを調べる(図24のステップS304)のと同様の効果があることを意味する。
なお、図17では、拡張オブジェクトとしてプログラムマネージャ330を用いて説明したが、他の拡張オブジェクトでも、ModTime813と同じフィールドを持つことにより同様の効果を得ること可能である。
なお、上述の実施例において、MO_INFO740、2000、3000は、Property Entryと呼ばれることもある。また、MoType741及びMoRef742をあわせて、Binary File Identifierと呼ばれることもある。また、MoUniqueID743は、entry_numberと呼ばれることもある。また、拡張オブジェクトはメーカ独自ファイル、あるいは、プライベートファイルと呼ばれることもある。また、RefValidFlag3100は、vflagsと呼ばれることもある。
なお、上述したいずれの実施の形態においても、記録再生装置及び記録媒体をDVDのような光ディスクメディアを例に挙げて説明しているが、特に限定されるものではなく、その他磁気記録メディアを用いたハードディスクドライブ、光磁気ディスクメディア等、他の記録装置や記録媒体であっても良い。
以上のように、本発明にかかる記録再生装置及び方法によれば、拡張機能のためのデータ追加を効率的に行える。これは、DVDレコーダやDVDビデオカメラのような民生の家電機器等のハードウエア資源が限られる記録再生装置において望ましい構成である。また、メディアオブジェクトの編集や削除を行った場合に、統一規格では定められていないため、ある記録再生装置では対応していない拡張機能または拡張オブジェクトが存在しても、データの不整合を最小限に抑制し、かつ、適切なデータ処理方法を決定可能となり、機器の誤動作やシステム停止、ユーザに対する利便性の低下等を回避することが可能となる。
特に、DVDレコーダやDVDビデオカメラなどの可搬型の記録媒体を用いた民生用の記録再生装置では、1つの記録媒体が複数の製造メーカによる異なる拡張機能を持った記録再生装置で記録・再生されることが想定される。よって、本発明にかかる記録再生装置及び方法により、より大きな効果を得ることが可能となる。
なお、上記の実施形態では、本発明の側面のうち、主に、記録装置、再生装置、記録媒体、記録方法、再生方法に関する実施形態を説明した。しかし、本発明は、他の側面として、前記記録装置の記録動作を制御するプログラム、前記再生装置の再生動作を制御するプログラム、これらのプログラムの提供媒体(プログラム製品)、および、記録媒体に記録されたデータ構造、としても実施することが可能である。当業者であれば、上述の実施形態の説明から、これらの側面の実施形態についても容易に理解することが可能であろう。
本発明は、これらに限定されないが、例えばDVD等の記録媒体や、DVDレコーダやDVDビデオカメラ等の記録・再生装置に利用可能である。
本発明は、主に、記録装置、記録方法及び当該記録装置又は記録方法により記録された記録媒体並びに当該記録媒体を再生する再生装置及び再生方法に関する。特に、画像データや音声データを記録媒体にファイルとして記録する記録再生装置、記録再生方法及び当該記録再生装置又は記録再生方法により記録された記録媒体に関する。
近年、動画情報や静止画情報、音声情報等のAVデータをデジタル化して記録・再生することが良く行われている。このようなデジタル情報を蓄積する記録媒体としては、フラッシュメモリ等の半導体メモリ、あるいはディスクメディアであるDVD、ハードディスク、MD(ミニディスク)等が存在する。
これらの記録媒体に対して、MPEG2やJPEG等の符号化方式で符号化されたAVデータの記録や再生が行われている。かかるAVデータの記録において、各AVデータはファイルシステムによりファイルとして管理されており、それぞれの再生に際してもファイル単位での指定が行われている。
そして、上述した半導体メディアやディスクメディアにおいては、ランダムアクセス性という優れた特徴が存在する。ランダムアクセス性を利用することにより、ユーザからの指示等に従って、記録済みのファイルを任意の順番で再生することが可能となる。
さらにそれを発展させた技術として、プログラム再生機能の実現が挙げられる。例えば、特開2002−199335号公報に開示されている記録/再生システムにおいては、AVデータをメディアオブジェクトと呼ぶファイルとして記録し、複数のメディアオブジェクトをプログラムと呼ばれるディレクトリの下に記録している。このような記録形態とすることによって、記録媒体上には当該プログラムを複数個作成することが可能となる。
また、各プログラムに対してプログラム情報(PRG_INFO)と呼ばれる情報を管理し、メディアオブジェクトとは異なるファイルとして記録媒体上に記録する。PRG_INFOに登録されるメディアオブジェクトの情報を参照することにより、記録媒体上に記録されたAVファイルの再生順序を自由に制御することが可能となる。
上述したような機能は、一般に「プログラム再生」と呼ばれており、ディスクメディアにおけるランダムアクセス性を利用することにより実現されている。
このように、AVデータをメディアオブジェクトとして記録し、そのメディアオブジェトを参照するプログラムもファイルとして記録する場合、当該プログラムファイルからメディアオブジェクトへの参照情報を持たなければならない。参照情報の形式は、ファイルに対するパス情報、すなわちファイルを管理するファイルシステム内で、当該ファイルの名前と階層位置を示す情報を用いるのが一般的である。
ここで、メディアオブジェクトとプログラムファイルとの関係の一例を図30に示す。図30は、メディアオブジェクトのディレクトリ構造と、プログラムファイルの構造の説明図である。
各プログラムファイル10002は、各メディアオブジェクト10001への参照を、ROOTディレクトリ10000からのフルパス名10003の形式で保持している。なお、図30に例示したフルパス名においては、パス区切り文字は“/”として記述している。
上述したメディアオブジェクトやプログラムファイルは、全てUDFやFAT等のファイルシステムを利用して管理される。ファイルシステムは、パーソナルコンピュータ(以下、「PC」という。)のアーキテクチャで一般的に利用され、ファイルシステムを導入することにより、上述のプログラムファイルを編集したり、再生したりするPC上のアプリケーションソフトを作成することが容易となる。
図30に示すように、プログラムファイル10002は、3つのメディアオブジェクト10001のプログラム再生を指示するものである。ここに示すように、複数のメディアオブジェクトがそれぞれ異なる親ディレクトリの下に記録されていてもプログラム再生を指示することが可能である。
また、半導体メディアやディスクメディアの異なる特徴として、データの追加と、それによる機能拡張の容易性が挙げられる。
特開2000−57745号公報や特開2001−160269号公報の記録再生装置では、図31に示すように、AVデータであるビットストリームファイル10010と、それを管理する情報ファイル10011が存在する。この情報ファイル10011に新たなデータ(製造業体情報項目10012)を追加していくことにより、この記録再生装置に対する新たな機能の追加が可能となる。
特開2002−199335号公報
特開2000−57745号公報
特開2001−160269号公報
しかし、上述した構成のようなプログラムファイルによるプログラム再生を実現するためには、それを処理する記録または再生装置などに、追加のハードウエア及びソフトウエア資源が要求される。
よって、ハードウエア及びソフトウエア資源が限られる記録/再生装置では、その実現が不可能な場合がある。
そのため、メディアオブジェクトの単純な記録及び再生に関しては基本機能としてすべての記録/再生機器で実現されることが想定されるが、上述のようなプログラム再生機能は拡張機能として位置づけられ、ある機器では処理可能であるが、別の機器では処理不可能となるような場合がありうる。
このような場合においても、DVDのようなディスクメディアは、一つのディスクメディアが複数の記録/再生機器で記録または再生がされる。
そのため、プログラム再生のような拡張機能に対応しない機器でディスクメディア上の情報を操作(メディアオブジェクトの編集や削除など)した場合、メディアオブジェクトの情報とプログラムファイルとの情報の間に不整合が発生してしまう。
そして、このような不整合状態にあるディスクメディアを、プログラム再生に対応した記録/再生機器で再生しようとすると、プログラムファイルで参照しているはずのメディアオブジェクトが存在しないので、場合によっては機器の誤動作の発生や、最悪の場合は動作が停止してしまう等、の不都合が生じる。
このような不都合を回避するためには、ある拡張機能に対応した記録/再生機器は、その拡張機能を使用する前に、拡張機能に関するデータの整合性をすべて確認する必要があるが、このデータの量が多くなる(例えばプログラムファイルの数が非常に多なる)と、その確認処理に時間がかかり、ユーザにとって非常に不便である。
また、特開2000−57745号公報及び特開2001−160269号公報に記載されているような、情報ファイルに拡張機能のためのデータを追加していく構成においては、情報ファイルの容量増加が避けられない。
情報ファイルの基本的な部分は、すべての記録/再生装置で必要とされるが、拡張機能に関する部分は、その拡張機能に対応した機器にのみ必要なデータであり、拡張機能に対応しない機器にとっては無駄なデータであり、ハードウエア資源の浪費となってしまう。
本発明は、上述したような状況に鑑みてなされたものであり、拡張機能のためのデータ追加を効率的に行え、なおかつ、拡張機能に対応していない機器がメディアオブジェクトの編集や削除を行った場合にも、データ間の不整合を最小限に抑制し、適切なデータ処理方法を決定可能とする記録装置、記録方法及び当該記録装置又は記録方法により記録された記録媒体、並びに当該記録媒体を再生する再生装置及び再生方法を提供することを目的とする。
上記目的を達成するために本発明にかかる記録装置は、記録媒体に情報の記録を行う記録部と、前記情報を、パス名により参照可能なディレクトリ階層構造を有したファイルシステム情報を用いてファイルとして管理するファイルシステム処理部と、前記ディレクトリ及び前記ファイルを、コンテンツ管理情報を用いて管理するコンテンツ管理情報処理部と、前記ディレクトリ及び前記ファイルに対する拡張情報を管理する拡張情報処理部と、を備えた記録装置であって、前記コンテンツ管理情報は、前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、前記拡張情報を管理する拡張オブジェクト管理情報とを含み、前記ディレクトリ及び前記ファイルと前記拡張情報とが、前記オブジェクト参照情報を経由して対応付けられていることを特徴とする。
また、本発明にかかる記録装置は、前記拡張オブジェクト管理情報に、前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性に関する状態を管理する整合性状態管理情報を含み、前記ディレクトリ及び前記ファイルに対する操作を行う時、処理可能な種類の前記拡張情報については、前記拡張情報を更新し、処理不可能な種類の前記拡張情報については、前記拡張情報を更新せず、前記ディレクトリ及び前記ファイルと、前記拡張情報との整合性の状態に応じて前記整合性状態管理情報を更新することが好ましい。
また、本発明にかかる記録装置は、前記整合性状態管理情報が、前記メディアオブジェクト管理情報毎に設けられ、前記拡張情報の種別毎に、少なくとも、前記拡張情報から前記ディレクトリ及び前記ファイルへの参照関係の有無を示す情報と、前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性が保証されているか否かを示す情報を含むことが好ましい。
また、本発明にかかる記録装置は、前記コンテンツ管理情報に、第1の更新日時情報を含み、前記拡張情報には、第2の更新日時情報を含み、前記メディアオブジェクト管理情報を更新した時、前記第1の更新日時情報を更新し、処理可能な種類の前記拡張情報については、前記第2の更新日時情報に前記第1の更新日時情報と同じ値を設定し、処理不可能な種類の前記拡張情報については、前記第2の更新日時情報を更新しないことが好ましい。
また、本発明にかかる第1の再生装置は、上述した記録装置により記録された記録媒体から情報の再生を行う再生装置であって、前記情報を前記記録媒体から再生する再生部と、前記ファイルシステム情報を処理するファイルシステム処理部と、前記拡張情報を処理する拡張情報処理部と、前記コンテンツ管理情報を処理するコンテンツ管理情報処理部とを備え、前記拡張情報処理部は、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する時、前記整合性状態管理情報の設定値に従って前記拡張情報に対する処理手順を決定することを特徴とする。
また、本発明にかかる第2の再生装置は、上述した記録装置により記録された記録媒体から情報の再生を行う再生装置であって、前記情報を前記記録媒体から再生する再生部と、前記ファイルシステム情報を処理するファイルシステム処理部と、前記拡張情報を処理する拡張情報処理部と、前記コンテンツ管理情報を処理するコンテンツ管理情報処理部とを備え、前記拡張情報処理部は、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する時、前記第1の更新日時情報と前記第2の更新日時情報とが一致するかどうかで、前記拡張情報に対する処理手順を決定することを特徴とする。
かかる構成により、拡張機能のためのデータ追加を効率的に行え、なおかつ、拡張機能に対応していない機器がメディアオブジェクトの編集や削除を行った場合にも、データ間の不整合を最小限に抑制し、適切なデータ処理方法を決定可能となる。
また、本発明の他の側面は、記録媒体への情報の記録方法である。この記録方法は、記録媒体に、コンテンツ情報を、パス名により参照可能なディレクトリ階層構造を有するファイルシステム情報を用いて、ファイルとして記録する工程と、前記ディレクトリ及び前記ファイルを管理するコンテンツ管理情報を前記記録媒体へ記録する工程と、前記ディレクトリ及び前記ファイルに対する拡張情報を前記記録媒体へ記録する工程とを備えた記録方法であって、前記コンテンツ管理情報は、前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、前記拡張情報を管理する拡張オブジェクト管理情報とを含み、前記記録方法は、前記ディレクトリ及び前記ファイルと前記拡張情報とを前記オブジェクト情報を経由して対応付ける工程を含むことを特徴とする。
また、本発明のさらに他の側面は、記録媒体からの情報の再生方法である。第1の再生方法は、情報を前記記録媒体から再生する工程と、前記ファイルシステム情報を処理する工程と、前記拡張情報を処理する工程と、前記コンテンツ管理情報を処理する工程とを備え、前記拡張情報処理工程が、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する前に、前記整合性状態管理情報の設定値に従って前記拡張情報に対する処理手順を決定する工程を含むことを特徴とする。第2の再生方法は、情報を前記記録媒体から再生する工程と、前記ファイルシステム情報を処理する工程と、前記拡張情報を処理する工程と、前記コンテンツ管理情報を処理する工程とを備え、前記拡張情報処理工程が、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する前に、前記第1の更新日時情報と前記第2の更新日時情報とが一致するかどうかで、前記拡張情報に対する処理手順を決定する工程を含む。
また、本発明のさらに他の側面は記録媒体である。この記録媒体は、情報が記録された記録媒体であって、前記情報をパス名により参照可能なディレクトリ階層構造として管理するファイルシステム情報と、前記ディレクトリ及び前記ファイルを管理するコンテンツ管理情報と、前記ディレクトリ及び前記ファイルに対する拡張情報とが記録されており、前記コンテンツ管理情報は、前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、前記拡張情報を管理する拡張オブジェクト管理情報とを含み、前記ディレクトリ及び前記ファイルと前記拡張情報とが前記オブジェクト情報を経由して対応付けられていることを特徴とする。
また、本発明のさらに他の側面は、記録媒体へ情報の記録を行う記録装置において、当該記録装置の記録動作を制御するプログラムである。このプログラムは、記録媒体に、コンテンツ情報を、パス名により参照可能なディレクトリ階層構造を有するファイルシステム情報を用いて、ファイルとして記録する工程と、前記ディレクトリ及び前記ファイルを管理するコンテンツ管理情報を前記記録媒体へ記録する工程と、前記ディレクトリ及び前記ファイルに対する拡張情報を前記記録媒体へ記録する工程とを前記記録装置に実行させる命令を含み、前記コンテンツ管理情報は、前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、前記拡張情報を管理する拡張オブジェクト管理情報とを含み、前記プログラムは、前記ディレクトリ及び前記ファイルと前記拡張情報とを前記オブジェクト情報を経由して対応付ける工程を前記記録装置に実行させる命令をさらに含むことを特徴とする。
また、本発明のさらに他の側面は、記録媒体から情報の再生を行う再生装置において、当該再生装置の再生動作を制御するプログラムである。このプログラムは、前記情報を前記記録媒体から再生する工程と、前記ファイルシステム情報を処理する工程と、前記拡張情報を処理する工程と、前記コンテンツ管理情報を処理する工程とを前記再生装置に実行させる命令を含むと共に、前記拡張情報処理工程において、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する前に、前記整合性状態管理情報の設定値に従って前記拡張情報に対する処理手順を決定する工程を前記再生装置に実行させる命令を含むことを特徴とする。
また、本発明のさらに他の側面は、記録媒体から情報の再生を行う再生装置において、当該再生装置の再生動作を制御するプログラムである。このプログラムは、前記情報を前記記録媒体から再生する工程と、前記ファイルシステム情報を処理する工程と、前記拡張情報を処理する工程と、前記コンテンツ管理情報を処理する工程とを前記再生装置に実行させる命令を含むと共に、前記拡張情報処理工程において、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する前に、前記第1の更新日時情報と前記第2の更新日時情報とが一致するかどうかで、前記拡張情報に対する処理手順を決定する工程を前記再生装置に実行させる命令を含むことを特徴とする。
また、本発明のさらに他の側面は、上述のプログラムを、コンピュータによる読み取りが可能な媒体に記録したプログラム提供媒体(プログラム製品)である。
また、本発明のさらに他の側面は、記録媒体に記録されたデータ構造である。このデータ構造は、記録媒体に記録されたコンテンツ情報をパス名により参照可能なディレクトリ階層構造として管理するファイルシステム情報と、前記ディレクトリ及び前記ファイルを管理するコンテンツ管理情報と、前記ディレクトリ及び前記ファイルに対する拡張情報とを含み、前記コンテンツ管理情報は、前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、前記拡張情報を管理する拡張オブジェクト管理情報とを含み、前記ディレクトリ及び前記ファイルと前記拡張情報とが前記オブジェクト情報を経由して対応付けられていることを特徴とする。
以下、本発明の実施の形態にかかる記録装置、記録方法及び当該記録装置又は記録方法により記録された記録媒体、並びに再生装置、再生方法について、図面を参照しながら説明する。
(実施の形態1)
図1は、本発明の実施の形態1にかかる記録再生装置の一例である、DVDレコーダの外観と、関連機器とのインタフェースを説明するための図である。図1に示すように、本発明にかかる記録再生装置の一実施形態としてのDVDレコーダ1は、記録媒体であるディスクメディアとしてDVDディスク2が装填され、ビデオ情報等の記録再生が行なわれる。DVDレコーダ1の操作は、一般的にはリモートコントローラ3や機器上のスイッチ(図示せず)によって行なわれる。
図1は、本発明の実施の形態1にかかる記録再生装置の一例である、DVDレコーダの外観と、関連機器とのインタフェースを説明するための図である。図1に示すように、本発明にかかる記録再生装置の一実施形態としてのDVDレコーダ1は、記録媒体であるディスクメディアとしてDVDディスク2が装填され、ビデオ情報等の記録再生が行なわれる。DVDレコーダ1の操作は、一般的にはリモートコントローラ3や機器上のスイッチ(図示せず)によって行なわれる。
DVDレコーダ1に入力されるビデオ情報には、アナログ信号とデジタル信号の両者があり、アナログ信号としてはアナログ放送が、デジタル信号としてはデジタル放送がある。一般的に、アナログ放送は、テレビジョン装置4に内蔵されている受信機により受信、復調され、NTSC方式等のアナログビデオ信号としてDVDレコーダ1に入力される。
また、デジタル放送は、受信機であるセットトップボックス(STB)5でデジタル信号に復調され、DVDレコーダ1に入力され記録される。
一方、ビデオ情報が記録されたDVDディスク2は、DVDレコーダ1により再生され外部に出力される。出力される信号も入力される信号と同様に、アナログ信号とデジタル信号の両者があり、アナログ信号であれば直接テレビジョン装置4に入力され、デジタル信号であればSTB5を経由し、アナログ信号に変換された後にテレビジョン装置4に入力され、テレビジョン(TV)で映像として表示される。
さらに、本発明にかかる記録再生装置の他の実施形態として、DVDディスク2を利用する装置にDVDビデオカメラ6がある。DVDビデオカメラ6は、DVDレコーダにレンズやCCDからなるカメラ装置を組み合わせた装置であり、撮影した動画情報を符号化して記録する。
また、DVDディスク2は、DVDレコーダ1やDVDビデオカメラ6以外に、PC7等でビデオ情報が記録再生される場合もある。PC7等でビデオ情報が記録されたDVDディスク2であっても、DVDレコーダに装填されれば、DVDレコーダは当該DVDディスクを再生する。
なお、上述したアナログ放送やデジタル放送のビデオ情報には、通常、音声情報が付随している。付随している音声情報もビデオ情報と同様に、DVDレコーダで記録再生される。
また、ビデオ情報は、動画の他に、静止画の場合もある。例えば、DVDビデオカメラ6の写真機能で静止画が記録されたり、PC7上で他の記録装置(ハードディスク)等から静止画がDVDディスク2へコピーされたりする場合が該当する。
なお、DVDレコーダとSTB5等の外部機器との間のデジタルインタフェースとしては様々なインタフェースが考えられる。例えば、IEEE1394、ATAPI、SCSI、USB、等である。
また、上記では、DVDレコーダ1とテレビジョン(TV)4との間の信号として、NTSC方式のアナログ(コンポジット)ビデオ信号を用いる場合について例示したが、輝度信号と色差信号を個別に伝送するコンポーネント信号であってもよい。
さらには、AV機器とテレビジョンの間の映像伝送インタフェースとしては、アナログインタフェースをデジタルインタフェース、例えば、DVIに置きかえる研究開発が進められており、DVDレコーダとテレビジョンがデジタルインタフェースで接続されることも当然予想される。
このようなDVDレコーダ1やDVDビデオカメラ6等の記録再生装置において、記録媒体であるディスクメディア2は、複数の記録再生装置上で記録・再生される。この時の記録装置は同一の製造メーカの場合もあるし、異なる製造メーカによる記録装置の場合もあり得る。
様々な記録再生装置における記録・再生の互換性確保のため、記録媒体における記録フォーマットやファイルフォーマットの規格化・標準化が行われるのが一般的である。例えば、DVD−Video Recording規格等、様々な統一規格が策定されている。
記録再生装置の製造メーカは、ユーザの利便性に配慮して、統一規格に準拠した記録再生装置の製品化を行う。
その一方で、各製造メーカは、他社製品との差別化を図るべく、独自の拡張機能を自社製品に盛り込んで記録再生装置を製品化する場合が多く見られる。この拡張機能とは、統一規格には含まれておらず、各製造メーカが、その内容を独自に設けるさまざまな機能である。拡張機能の実現のために、図1には示していない追加のハードウエアやソフトウエア、周辺機器が必要に応じて記録再生装置に設けられる場合がある。例えば、位置情報を取得するGPSレシーバ、等である。
図2は、本実施の形態1にかかる記録再生装置に組み込まれるドライブ装置110とその周辺の概略構成を示すブロック図である。図2において、ドライブ装置110は、記録媒体に対して情報の記録再生を行う光ピックアップ101と、ECC(Error Correcting Code)処理部102を備え、例えばDVDディスクのような記録媒体であるディスクメディア100に対してデータの記録及び再生を行う。
ディスクメディア100には、セクタと呼ばれる最小単位でデータが記録される。また、複数のセクタで一つのECCブロックを構成し、ECCブロックを1単位としてECC処理部102でエラー訂正処理が施される。なお、ECCブロックはECCクラスタと呼ばれることもある。
ディスクメディア100の一例であるDVD−RAMディスクの場合、セクタのサイズは2KBであり、16セクタを1ECCブロックとして構成されている。当該セクタサイズは、ディスクメディア100の種類に応じて変動するものであり、1セクタは512B(バイト)であっても良いし、8KB等であっても良い。
また、ECCブロックについても、1セクタを1ECCブロックとして構成しても良いし、16セクタを、あるいは32セクタ等を1ECCブロックとして構成しても良い。今後、記録できる情報容量の増大に伴い、セクタサイズ及びECCブロックを構成するセクタ数は増大するものと予想される。
また、ドライブ装置110は、トラックバッファ103と接続されており、トラックバッファ103は、システムバス105を経由して記録再生装置のシステム全体を制御するシステム制御部104と接続されている。
トラックバッファ103は、ディスクメディア100にAVデータをより効率良く記録するため、AVデータを可変ビットレート(VBR)で記録するためのバッファである。ディスクメディア100への読み書きレート(Va)が固定レートであるのに対して、AVデータはその内容(ビデオであれば画像)の持つ複雑さに応じてビットレート(Vb)が変化する。トラックバッファ103は、このビットレートの差を吸収するためのバッファである。
図3は、ドライブ装置110を含む、本実施の形態1にかかる記録再生装置のブロック構成図である。図3に示すように、本実施の形態1にかかる記録再生装置は、システム全体の管理及び制御を司るシステム制御部104、ユーザへの表示及びユーザからの要求を受け付けるユーザI/F(インタフェース)部200、VHF及びUHFを受信するアナログ放送チューナ210、映像をAV信号へ変換するカメラ部211、デジタル放送を受信するデジタル放送チューナ212、AV信号入力をデジタル信号に変換し、MPEGプログラムストリーム等にエンコードする動画エンコーダ221、AV信号入力をJPEGストリーム等にエンコードする静止画エンコーダ222、デジタル放送で送られるMPEGトランスポートストリームを解析する解析部223、MPEG等の動画データをデコードする動画デコーダ240、静止画データをデコードする静止画デコーダ241、テレビ及びスピーカ等の表示部250、等を備えている。
動画エンコーダ221、静止画エンコーダ222や解析部223には、AVデータの入力源として、アナログ放送チューナ210、カメラ部211、デジタル放送チューナ212等が接続されている。
なお、上述したエンコーダやチューナ、カメラ部については、全てを同時に備える必要はなく、記録再生装置の使用目的に応じて必要なものだけを備えれば良い。例えば、記録再生装置がDVD等の光ディスク用レコーダの場合であれば、図4に示すように、図3に示した構成のうち、カメラ部211を省いた構成としても良い。また、記録再生装置がビデオカメラの場合であれば、図5に示すように、図3に示した構成のうち、アナログ放送チューナ210およびデジタル放送チューナ212を省き、集音用のマイク部261をさらに備えた構成としても良い。また、記録再生装置がパーソナルコンピュータの場合であれば、図4と同様の構成としても良い。あるいは、図6に示すように、図3に示した構成のうち、アナログ放送チューナ210、カメラ部211、およびデジタル放送チューナ212を省いた構成としても良い。
さらに、図3に示す記録再生装置は、図2で示したように、書き込みデータを一時的に格納するトラックバッファ103と、ディスクメディア100にデータを書き込むドライブ装置110とを備えている。
また、IEEE1394やUSB等の通信手段により外部機器にデータを出力するインタフェースであるデジタルI/F(インタフェース)部230を備えても良い。
なお、本実施の形態1にかかる記録再生装置の詳しい動作については後ほど説明を行う。
次に、図7は、本実施の形態1にかかる記録再生装置において記録可能なディスクメディア100の外観と物理構造を表した図である。なお、例えばDVD−RAMのようなディスクメディアは、記録面を保護するのを目的として、カートリッジに収納された状態で記録再生装置に装填される。ただし、記録面の保護が別の構成で行なわれたり、容認できる場合にはカートリッジに収納せずに、記録再生装置に直接装填できるようにしてもよい。
図7(a)は、記録可能なディスクメディア100の記録領域の一例を示した図である。図7(a)の例では、最内周にリードイン領域141が、最外周にリードアウト領域142が、その間にデータ領域143が配置されている。リードイン領域141は、光ピックアップ101がディスクメディア100へアクセスする時に、サーボを安定させるために必要な基準信号や他のメディアとの識別信号等が記録されている。リードアウト領域142もリードイン領域141と同様の基準信号等が記録されている。またデータ領域143は、最小のアクセス単位であるセクタに分割されている。
図7(b)は、図7(a)において同心円状に示されているリードイン領域141と、リードアウト領域142と、データ領域143を横方向に配置した説明図である。
リードイン領域141とリードアウト領域142は、その内部に欠陥管理領域(DMA:Defect Management Area)144,147を有する。欠陥管理領域とは、欠陥が生じたセクタの位置を示す位置情報と、その欠陥セクタを交替するセクタが後述する交替領域のいずれに存在するかを示す交替位置情報とが記録されている領域をいう。
また、データ領域143は、その内部に交替領域145とユーザ領域146を有している。交替領域145は、欠陥セクタが存在する場合に代替セクタとして使用される領域である。ユーザ領域146は、ファイルシステムが記録用領域として利用することができる領域をいう。なお、ディスクメディアの種類によっては交替領域を持たないディスクメディアも存在し、この場合、必要に応じて、後述するUDF等のファイルシステムにおいて、欠陥セクタの交替処理を行う場合もある。
データ領域143にある各セクタへアクセスするため、内周から順に物理セクタ番号(PSN:Physical Sector Number)をデータ領域へ割り当てることが一般に行われている。PSNによって管理されるセクタを物理セクタと呼ぶ。
また、データ記録に使用されるセクタのみを連続的に示すように、内周から順に論理セクタ番号LSN(Logical Sector Number)をユーザ領域の物理セクタに割り当てることも行われる。LSNによって管理されるセクタを論理セクタと呼ぶ。
図7(c)は、図7(b)のユーザ領域146内で、論理セクタにより構成される論理的なデータ空間を示す図である。論理的なデータ空間は、ボリューム空間と呼称され、ユーザデータを記録する。ボリューム空間においては、記録データをファイルシステムで管理する。
DVD−RAM等のディスクメディアでは、ファイルシステムは、UDFと呼称され、ECMA167及びISO13346規格に準拠したものが一般的に使用される。
UDFのパーティション空間292では、データアクセスの単位ごとに論理ブロック番号LBN(Logical Block Number)が割り当てられ、データの配置や管理が行われる。
データの配置のために、パーティション空間292で連続的に配置される1群のセクタはエクステントと呼ばれる単位で管理され、さらに関連のあるエクステントの集合がファイルとして管理される。
エクステント及びエクステントの集合であるファイルを管理する情報制御ブロック(ICB)であるファイルエントリ(FE)及び拡張ファイルエントリ(EFE)と呼ばれる構造、さらには1群のファイルをディレクトリとして管理するための情報であるファイル識別記述子(FID)等がボリューム空間内のパーティション空間内に記録される。
そして、パーティション空間等を管理するためのボリューム構造情報290(及びそのバックアップである291)が、ボリューム領域の先頭と終端に記録される。
図8は、本発明の実施の形態1にかかる記録再生装置により記録されるディスクメディア100におけるディレクトリとファイルの階層構造の一例を示す図である。図8に示すように、ROOTディレクトリ300の下に、階層化されたサブディレクトリ(301〜305等)があり、さらにその階層下に、動画データや静止画データを含むファイルである各種メディアオブジェクト(310〜313等)や、各メディアオブジェクトを管理するためのファイルであるメディアオブジェクトマネージャ320(ファイル名:MOI_MGR)や、複数のメディアオブジェクトをグループ化し、再生順序や分類情報を管理するプログラムマネージャ330(ファイル名:PRGM0001.EXT)等が格納されている。
ここでプログラムマネージャ330は拡張情報を格納する拡張オブジェクトの一種であり、プログラム再生機能に対応した記録再生装置がその記録及び再生等の処理を行う。
なお、本実施の形態においてはメディアオブジェクトマネージャ320の構造や機能は統一規格の一種であるとし、全ての本発明の記録再生装置において記録や再生が保証されるものとする。
また、拡張情報とは、統一規格に含まれない拡張機能を製造メーカが独自に実現する上で必要な様々な情報のことである。拡張情報は拡張オブジェクトと呼ばれるファイルに格納されてディスクメディア100に記録される。上述の、プログラム再生機能は拡張機能の一例である。
本実施の形態1においては、記録及び再生用の対象となるAVデータを含む各種メディアオブジェクトのディレクトリ階層やファイル名は、後述するDCF規格及びそれに類した形式を利用して以降の説明を行う。ただし、ディレクトリ階層やファイル名の命名則はこれに限られるものではなく、他の命名則を用いても良い。
メディアオブジェクトのうち、MPEG2等の動画データを含む動画オブジェクトは、ABCDnnnn.MPGというように、最初の4文字が任意のアルファベット文字の組み合わせであり、次のnnnnが10進数であるような命名側に従って動画ファイルとして記録される。動画ファイルは、MPEG2方式やMPEG4方式等で圧縮されたAVデータを含んでおり、プログラムストリーム(PS)や、トランスポートストリーム(TS)、あるいは他の形式のファイルとして記録される。
また、各々の動画ファイルに関する属性情報は、属性情報ファイル(ファイル名:ABCDnnnn.MOI)に記録される。属性情報ファイルには、それぞれの動画ファイルの識別情報、記録された日時、動画データの代表画像(サムネイルピクチャ)、動画データの再生時刻をディスクメディア100上の論理アドレスに変換するためのアクセスマップ情報及びその管理情報、等を有している。アクセスマップ情報を持つことにより、動画データの持つ時間軸とデータ(ビット列)軸との間の変換を行うことが可能となり、動画データに対する時間軸を基準にしたランダムアクセスが可能となる。
属性情報ファイルは、例えばApple社のQuickTimeファイルフォーマットに準拠する形式でもよい。QuickTimeファイルフォーマットでは、前記属性情報は、ムービーリソース(movie resource)と呼ばれる。また同様に、前記アクセスマップ情報は、サンプルテーブル(Sample Table)と呼ばれる。
一つの動画オブジェクトは、一つの属性情報ファイルと一つ又はそれ以上の動画ファイルとで構成され、それらはファイル名により関連づけられるものとする。すなわち、関連のある属性情報ファイルと動画ファイルは、そのファイル名において拡張子を除く部分、例えば動画オブジェクト310では、動画ファイル311と属性情報ファイル312が“ABCD0001”の部分が同一に設定されることによって、その関連付けがなされていることとする。
ただし、属性情報ファイルと動画ファイルの関連付けは上述の方法に限定されるものではなく、属性情報ファイル内に関連付けられた動画ファイルへのリンク情報、例えば動画ファイルへのパス名等を保持したり、両者の対応付けをテーブル情報として保持したりする等、他の方法であっても良い。なお、一つの動画オブジェクトに、一つの属性情報ファイルと一つ又はそれ以上の動画ファイル以外を含むようにしてもよい。また、属性情報ファイルと動画ファイルを一体として、1つのファイルで動画オブジェクトを構成するようにしてもよい。
メディアオブジェクトのうち、JPEG等の静止画データを含む静止画オブジェクトは、各々の静止画情報が静止画ファイル(ファイル名:ABCDnnnn.JPG)等として記録される。静止画ファイルは、JPEG方式等で圧縮された映像データであり、例えば、DCFフォーマットやExifフォーマットによりファイルとして記録される。
上記のメディアオブジェクトは、DCF規格あるいはそれに類するディレクトリ構造にしたがって記録される。すなわち、ROOTディレクトリ300の下にDCFイメージルートディレクトリ302(ディレクトリ名:DCIM)があり、さらにその下に静止画ファイルを格納するためのDCFディレクトリ305がある。(ディレクトリ名:300ABCDE)。そして、DCFディレクトリ305の下に静止画オブジェクトの一種であるDCF基本ファイル313(例えば、ファイル名:ABCD0001.JPG)が格納される。
また、ROOTディレクトリ300の下にVIDEOイメージルートディレクトリ301(ディレクトリ名:VIDEO)があり、さらにその下に、主に動画オブジェクトを格納するためのVIDEOディレクトリ304がある。(例えば、ディレクトリ名:100ABCDE)。そして、VIDEOディレクトリ304下に、動画オブジェクト310を構成する属性情報ファイル312(拡張子がMOIであるファイル)と動画ファイル311(拡張子がMPGであるファイル)が格納される。
なお、メディアオブジェクトとして、AC−3やAAC等による圧縮音声ファイルや非圧縮の音声ファイル、MotionJPEGファイル、DCF規格で定められたDCF拡張画像ファイル、DCFサムネイルファイル、PNGファイル等、他のファイルフォーマットのAVファイルを記録してもよい。
記録されたメディアオブジェクトを管理するコンテンツ管理情報は、管理データディレクトリ303(ディレクトリ名:INFO)下のメディアオブジェクトマネージャファイル320として記録される。
また、メディアオブジェクトに対して拡張情報を付加する拡張オブジェクトも管理データディレクトリ303に記録される。図8では、拡張オブジェクトの例として、プログラムマネージャファイル330が記録されている。なお、メディアオブジェクトマネージャファイル320及び拡張オブジェクトの記録位置は管理データディレクトリ303下に限られるものではなく、例えば、VIDEOイメージルートディレクトリ301下、等でもよい。メディアオブジェクトマネージャファイル320及びプログラムマネージャファイル330の構造については後述する。
次に、図9、図10及び図11を用いて、本実施の形態1にかかる記録再生装置で用いられるディスクメディア上でデータをファイルとして管理する、UDFファイルシステムの構造を説明する。
図9は、UDFファイルシステムにおけるディレクトリ階層を管理するためのデータ構造を示す図である。なお、図9は、図8に示したディレクトリ階層構造に対応しているが、そのうちROOTディレクトリ300から属性情報ファイル312へ至るまでのファイルシステム情報のみを示しており、他のディレクトリやファイルに対する同様の情報については、説明を簡単にするため省略している。
ディレクトリ階層構造の起点はファイルセットディスクリプタ(FSD:File Set Descriptor)400である。FSD400は、図10(a)に示されるデータ構造を有している。FSD400は、拡張ファイルエントリ(EFE:Extended File Entry)510への参照情報401(ディスクメディア100上での記録位置)をRoot Directory ICB501の値として保持している。また、FSD400は、System Stream Directory ICB502からNamed Streamと呼ばれるデータを参照可能である。
Root Directory ICB501及びSystem Stream Directory ICB502は、図10(b)に示すlong_ad503という構造を持つ。long_ad503は、参照先のエクステントの長さ(Extent Length)と、位置(Extent Location)を保持する。さらに、Implementation Use504には、図10(c)に示すADImpUseの形式によりUDF UniqueID505と呼ばれる値が保持される。
また、EFE510は、図11(a)に示される構造を有している。EFE510は、ディスクメディア100上に記録された各ディレクトリやファイルを構成するエクステントの集合を管理するための構造体であり、各エクステントのディスクメディア100上での記録位置とデータ長を管理するため、図11(b)に示す構造を有するアロケーション記述子(AD:Allocation Descriptor)514と呼ばれる構造を含んでいる。各ディレクトリやファイルは複数のエクステントから構成されるので、EFE510には複数のAD514が含まれる。
その他にも、EFE510には、図11(a)に示すように、データの種別を表すディスクリプタタグ(Descriptor Tag)や、各ディレクトリやファイルごとに、ディスクメディア100上で重複しない一意のID値を設定するUnique ID511、EFE510ごとの拡張属性を設定可能なStream Directory ICB512や、拡張属性(EAs; Extended Attributes)513等が含まれる。
EAs513は、UDFファイルシステムで規定される拡張属性を格納するための領域であり、ECMA167規格等で定められた拡張属性データや、様々なアプリケーションシステム等が必要に応じて使用できる。EAs513中には、属性タイプ(Attribute Type)や属性サブタイプ(Attribute Subtype)と呼ばれるフィールドが存在し、ここに適切な値を設定することにより、この拡張属性中に含まれるデータの種別を識別できるようになっている。特定の属性タイプや属性サブタイプの値とそれに対応するデータ構造がECMA167規格等ですでに定義されている。
図12(a)に、EAs513に含まれる拡張属性データの一種で、任意のアプリケーションシステムが使用可能な処理システム用拡張属性(Implementation Use Extended Attribute)530と呼ばれる構造を示す。
アプリケーションシステムがこの処理システム用拡張属性530を使用する時には、Attribute Type、Attribute Subtype及びImplementation Identifierの各フィールドに適切な値を設定することにより、処理システム用拡張属性530中に含まれる拡張属性が、どんなアプリケーションシステムにより使用されるかを識別できるようになっている。
そして、実際の拡張属性の値は、Implementation Use Length(IU_L)でデータ長が示される可変長のフィールドImplementation Use531中に格納される。Implementation Use531中に格納される拡張属性のデータ構造は、それを使用するアプリケーションごとに決められる。
本実施の形態においてImplementation Use531中に格納される拡張属性のデータの一例として、Media Object Management Information540の構造を、図12(b)に示す。ここでは、Mo(Media Object) Unique ID541というフィールドが設けられている。本フィールドの利用例については後述する。
ROOTディレクトリ300等のディレクトリデータを含むエクステント420(図9(a)参照)は、各ディレクトリやファイルのファイル名を保持するファイル識別記述子FID(File Identifier Descriptor)520で構成される。あるディレクトリ下にサブディレクトリやファイルが存在する場合、それぞれのディレクトリ又はファイルに対してFID520が保持される。
例えば、図8によれば、ROOTディレクトリ300の下にはVIDEOイメージルートディレクトリ301とDCIMイメージルートディレクトリ302があるので、図9(a)に示すように、ROOTディレクトリ300のエクステント420には、各々に対応するFID421及び422が保持されている。
FID520は、図11(c)に示される構造を持つ。FID520は、UDF上で管理される各ディレクトリやファイルの名前(ファイル識別子)をファイル識別子(File Identifier)521として保持する。FID520はさらに、対応するディレクトリ又はファイルの実データを管理するEFE510への参照情報(例えば図9(a)の430)を、ICB522として保持する。
そのほかにも、FID520には、データの種別を表すディスクリプタタグ(Descriptor Tag)や、ファイル識別子521のデータ長を表すファイル識別子長さ(Length of File Identifier)等が含まれる。
以降、同様にEFE510とFID520の参照関係を保持することによりディレクトリの階層構造が管理され、この参照関係を順次たどることによって、任意のディレクトリやファイルの実データであるエクステントへアクセスすることが可能となる。
ファイルに関しても、EFE510によりエクステントの集合が管理される。図9の場合、エクステントの集合442がファイルを構成し、これは図8における属性情報ファイル312に相当する。
上記のFSD400やEFE510、FID520は、パーティション空間292内に配置される。図9(b)は、図9(a)のデータ構造のパーティション空間内での配置の例示図である。ここで、図9(a)と図9(b)で同じデータに関しては同じ番号を付与している。
エクステント442へアクセスするためには、FSD400から順にEFE510、FID520、・・・、EFE440のように、順次、データへアクセスする。
上述のような階層構造を持ったファイルシステムにおいて、特定のディレクトリやファイルを参照するために、パス名が利用できる。パス名は、例えば、図9のエクステント442(ファイル名:ABCD0001.MOI)に対しては、“/VIDEO/100ABCDE/ABCD0001.MOI”のように表される。ここでは、ROOTディレクトリ300及びパス区切り文字を“/”で表している。
このように、パス名は、ROOTディレクトリ300から、対象のディレクトリやファイルにたどり着くまでディレクトリ階層をたどっていく時、その経路上に存在するディレクトリの名前(ファイル識別子521に格納されている情報)を、パス区切り文字で区切りながら一続きに記述したものである。このパス名を利用すれば、ファイルシステム上で管理される任意のディレクトリやファイルを参照することが可能となる。
次に、ディスクメディア100へ記録を行なう、本実施の形態にかかる記録再生装置の動作について説明する。
まず、図13を用いて、ディスクメディア100上でのAVデータの分散配置について説明する。すなわち、図2に示すようなシステムにおいて、トラックバッファ103を有効利用することによって、AVデータを離散配置することが可能になる。
図13(a)は、ディスクメディア100上のアドレス空間を示す図である。図13(a)においては、左端がアドレス値が0の点であり、右に向かってアドレス値が増加していくものとしている。また、“0”、a1〜a4は、その位置におけるアドレス値を示している。
図13(a)に示されるように、AVデータが[a1、a2]の連続領域A1と[a3、a4]の連続領域A2に分かれて記録されている場合、光ピックアップ101がa2からa3へシーク動作を行なっている間、トラックバッファ103に蓄積してあるデータを動画デコーダ240へ供給することでAVデータの連続再生が可能になる。
この時のトラックバッファ103内のデータ蓄積量の状態を示したのが、図13(b)である。位置a1で読み出しが開始されたAVデータは、時刻t1からトラックバッファ103に入力されると共に、トラックバッファ103からデータの出力が開始される。これにより、トラックバッファ103への入力レート(Va)とトラックバッファ103からの出力レート(Vb)のレート差(Va−Vb)の分だけトラックバッファ103にデータが蓄積されていく。この状態が、光ピックアップ101がa2に達するまで、すなわち時刻t2に達するまで継続する。
この間にトラックバッファ103に蓄積されたデータ量をB(t2)とすると、時間t2から、位置a3のデータの読み出しを開始する時刻t3までの間、トラックバッファ103に蓄積されているデータ量B(t2)を消費して動画デコーダ240へ供給し続けられれば良い。
換言すると、シーク前に読み出すデータ量([a1、a2])が一定量以上確保されていれば、シークが発生した場合であっても、AVデータの連続供給が可能となる。
AVデータの連続供給が可能な連続領域のサイズは、ECCブロック数N_eccに換算すると、(数1)のように求められる。(数1)において、N_secはECCブロックを構成するセクタ数であり、S_sizeはセクタサイズ、Tjはシーク性能(最大シーク時間)である。
(数1)
N_ecc=Vb×Tj/((N_sec×8×S_size)×(1-Vb/Va))
N_ecc=Vb×Tj/((N_sec×8×S_size)×(1-Vb/Va))
また、連続領域の中には欠陥セクタが生じる場合がある。この場合を考慮すると、AVデータの連続供給が可能な連続領域のサイズは(数2)のように求められる。(数2)において、dN_eccは容認する欠陥セクタのサイズであり、Tsは連続領域の中で欠陥セクタをスキップするのに要する時間である。
(数2)
N_ecc=dN_ecc+Vb×(Tj+Ts)/((N_sec×8×S_size)×(1-Vb/Va))
N_ecc=dN_ecc+Vb×(Tj+Ts)/((N_sec×8×S_size)×(1-Vb/Va))
なお、本実施の形態1においては、ディスクメディア100からデータを読み出す場合、すなわち再生の場合について説明しているが、ディスクメディア100へデータを書き込む場合、すなわち記録又は録画の場合も同様に考えることができる。
上述したように、ディスクメディア100では、一定量以上のデータが連続記録されていれば、ディスク上にAVデータを分散記録しても連続再生が可能である。なお、例えばDVDでは、この連続領域をCDAと呼称する。あるいは、AVデータを記録する特別なエクステントであることから、AVエクステントと呼ばれることもある。
次に、図3を用いて、本実施の形態1にかかる記録再生装置の動作について説明する。図3に示した記録再生装置においては、例えばユーザI/F部200がユーザからの要求を受け付けた場合に動作を開始する。
ユーザI/F部200は、ユーザからの要求をシステム制御部104に伝え、システム制御部104は、ユーザからの要求を解釈すると共に各モジュールへの処理要求を行なう。
以下、アナログ放送をMPEG−2 PSにエンコードして動画オブジェクトとして記録する動作を例に挙げて説明する。
システム制御部104は、アナログ放送チューナ210への受信と動画エンコーダ221へのエンコードを要求する。動画エンコーダ221は、アナログ放送チューナ210から送られてくるAV信号を、ビデオエンコード、オーディオエンコード及びシステムエンコードしてトラックバッファ103に送出する。動画エンコーダ221は、エンコード開始後、アクセスマップ情報等を作成するために必要な情報をエンコード処理と平行してシステム制御部104に送る。
次に、システム制御部104は、ドライブ装置110に対して記録要求を出し、ドライブ装置110は、トラックバッファ103に蓄積されているデータを取り出してディスクメディア100に記録する。この際、前述した連続領域であるCDAをディスク上の記録可能領域から検索し、見つかったCDAにデータを記録していく。
この時、CDAとして記録可能な領域の検索は、UDF等のファイルシステムが管理する空き領域情報、例えば、スペースビットマップディスクリプタ(Space Bitmap Descriptor)に基づいて実行される。
録画終了は、ユーザからのストップ要求によって指示される。ユーザからの録画停止要求は、ユーザI/F部200を通してシステム制御部104に伝えられ、システム制御部104は、アナログ放送チューナ210と動画エンコーダ221に対して停止要求を出す。動画エンコーダ221は、システム制御部104からのエンコード停止要求を受けてエンコード処理を終了する。
システム制御部104は、エンコード処理終了後、動画エンコーダ221から受け取った情報に基づいて、アクセスマップ情報とその管理情報、等を含む属性情報を生成する。
次に、システム制御部104は、ドライブ装置110に対してトラックバッファ103に蓄積されているデータの記録終了と属性情報の記録を要求し、ドライブ装置110が、トラックバッファ103の残りデータと、属性情報を属性情報ファイル、例えば、図9に示す動画オブジェクトを構成しているファイルであるABCD0001.MOIとしてディスクメディア100に記録し、動画オブジェクトの録画処理を終了する。
なお、上記のほかに、システム制御部104は、図10や図11、図12で説明したようなUDFファイルシステムの情報を必要に応じて生成したり更新したりする。すなわち、動画オブジェクトを構成するファイルに対して、EFE510やFID520を生成し、必要な情報を設定した上でディスクメディア100上に記録する。
記録再生装置がビデオカメラである場合は、図5を参照して説明したように、AV信号源がアナログ放送チューナ210ではなくカメラ部211へ変わるだけで、他の処理は同様である。
また、デジタル放送を動画オブジェクトとして記録する動作には、動画データのエンコードは行わず、デジタル放送チューナ212及び解析部223を通じてMPEG2 TSのデータをディスクメディア100へ動画オブジェクトとして記録するようシステム制御部104が制御を行う。このとき、上述と同様に、ファイルシステム情報の記録も行われる。
次に、静止画オブジェクトの記録に関して、カメラ部211から送られてくるAV信号をJPEGエンコードして記録する動作について説明する。
システム制御部104は、カメラ部211へAV信号の出力を、静止画エンコーダ222へAV信号のエンコード実施を要求する。静止画エンコーダ222は、カメラ部211から送られるAV信号をJPEGエンコードし、トラックバッファ103に送出する。
ドライブ装置110は、システム制御部104からの指示を受けながら、トラックバッファ103に蓄積されているデータをディスクメディア100に記録する。この時、データの記録可能領域の検索は、UDF等のファイルシステムが管理する空き領域情報をもとに実行される。
一つの静止画オブジェクトが記録されたら撮影は終了する。あるいは、ユーザから連続撮影の指示があった場合は、ユーザからの撮影停止要求によって終了するか、所定の枚数の静止画オブジェクトを記録して終了する。ユーザからの撮影停止要求は、ユーザI/F部200を通してシステム制御部104に伝えられ、システム制御部104はカメラ部211と静止画エンコーダ222に対して停止要求を出す。
さらに、システム制御部104は、UDFファイルシステムの情報についても必要な処理を行う。すなわち、静止画オブジェクトを構成するファイルに対して、EFE510やFID520等を生成し、必要な情報を設定した上でディスクメディア100上に記録する。
以上のような手順でディスクメディア100に記録される各メディアオブジェクトは、後々の管理のために、図8で示したメディアオブジェクトマネージ320に登録される。各メディアオブジェクトとメディアオブジェクトマネージ320との関係については後述する。なお、本発明においてはEFE510を用いて説明を行っているが、その代わりにFEを用いてもかまわない。
図14は、本実施の形態1における記録再生装置で用いられるディスクメディア100上に記録されるデータの階層構造と、それらを処理するシステム制御部104及びその内部構造の一例を示す図である。
ディスクメディア100上にはファイルシステム情報600が記録される。ファイルシステム情報600には、図7(c)で示したボリューム構造情報290や、図10、図11及び図12で示したFSD400、EFE510、FID520、また上述したスペースビットマップディスクリプタ(Space Bitmap Descriptor)等が含まれる。
また、複数のメディアオブジェクトをまとめて管理するためのメディアオブジェクトマネージャ320が同様にファイルとして管理され、コンテンツ管理情報601を構成する。
さらに、メディアオブジェクトに拡張情報602を付与する拡張オブジェクト603もファイルとして管理される。プログラムマネージャ330も拡張オブジェクトの一例であり、複数のメディアオブジェクトの内容や記録日時等に応じて整理分類したり、ユーザが自由な再生順序を設定するプログラム再生を行ったりするための拡張情報を格納するために設けられている。
これらのディスクメディア100に記録されるデータは、システムバス105を通じて、システム制御部104により操作される。
一方、システム制御部104は、より詳細には、オペレーティングシステム(OS)とアプリケーションシステムとからなる。
オペレーティングシステムには、ファイルシステム情報600を制御するファイルシステム処理部610や、特に図示されていないハードウエアの制御を行うデバイスドライバ部、メモリ制御部、等が含まれ、アプリケーションシステムに対して、API(Application Program Interface)を通じてさまざまな共通機能を提供する。これにより、アプリケーションシステムをハードウエアやファイルシステムの詳細とは分離した形で実現することが可能となる。
一方、アプリケーションシステムでは、特定のアプリケーションのための制御動作を行う。本実施の形態1においては、例えば図3を用いて説明したように、動画オブジェクトや静止画オブジェクトの記録あるいは再生処理に関する制御を行う。
また、アプリケーションシステム中のコンテンツ管理情報処理部611は、コンテンツ管理情報601及びそこに含まれるメディアオブジェクトマネージャ320に対する操作を行う。
そして、拡張情報処理部612は、拡張情報602及びそこに含まれる拡張オブジェクト603に対する操作を行う。拡張オブジェクト603に対する操作については、後でさらに説明する。
また、アプリケーションシステムには、その他にも必要に応じて、AVデータの表示や、ユーザインタフェースを処理する部分等を含む場合もある。
メディアオブジェクトマネージャ320のデータ構造については、図15〜図16を用いて以下に説明する。
図15(a)は、メディアオブジェクトマネージャ320のデータ構造の例示図である。図15(a)に示すようにメディアオブジェクトマネージャ320は、ヘッダ部700とデータ部701とから構成される。
ヘッダ部700には、ファイルのタイプを表すDataType、ファイルのサイズを表すDataSize、メディアオブジェクトマネージャ320の更新日時であるModTime702、等が含まれる。また、拡張情報602を管理するための拡張オブジェクト管理情報テーブル710が含まれる。なお、LastMoUniqueID703については後述する。
データ部701は、メディアオブジェクト管理情報テーブル730を含む。メディアオブジェクト管理情報テーブル730は、メディアオブジェクトマネージャ320中に含まれるメディアオブジェクト管理情報(MO_INFO)700の数を示すNumMoInfoと、NumMoInfo個のMO_INFO700から構成される。
なお、図15等におけるフィールド名欄の表記は、データ型とフィールド名を続けて記述しており、データ型については、例えば以下のような意味を示している。
constは、フィールドが定数であることを意味しており、constがない場合は変数であることを示している。unsignedは、当該フィールドは符号無しの値であることを示しており、unsignedがない場合は符号付きの値であることを示している。また、int()は、フィールドはカッコ内のビット長を持つ整数値であることを示している。例えば、カッコ内の値が“16”である場合には、16ビット長であることを意味する。また、stringは文字列情報であることを意味する。
図15(b)は、メディアオブジェクトマネージャ320に含まれる拡張オブジェクト管理情報(EO_INFO)720のデータ構造である。EO_INFO720は、プログラムマネージャ330のような拡張オブジェクトを登録・管理するデータ構造であり、各拡張オブジェクトをそれぞれ識別するための型情報を示すEoType721及びEoSubType722を持つ。
EoType721及びEoSubType722には、例えば、拡張オブジェクトの所有者(オーナー)情報やその使用目的を示す情報を数値やアルファベット値として格納しても良い。
さらにEO_INFO720は、拡張オブジェクトへの参照情報をパス名により保持する拡張オブジェクト参照情報EoRef723、図15(c)で示される属性フラグであるEoFlags724、拡張オブジェクトの概要を示す文字列情報を格納するTextDesc726、等から構成される。
図15(c)は、EO_INFO720が指し示す拡張オブジェクトに関する様々な情報をフラグとして格納するEoFlags724の構造例である。本実施の形態においては、0ビット目をValidフィールドとしている。
Validフィールドの値が1bの場合、メディアオブジェクトマネージャ320及びそれが管理するメディアオブジェクトと、EO_INFO720が指し示す拡張オブジェクトとの整合性が維持されており、該拡張オブジェクトに含まれる情報が有効であることが保障されている状態を示す。一方、Validフィールドの値が0bの場合は、その保障がないことを示す。
図16(a)は、メディアオブジェクトマネージャ320に含まれるメディアオブジェクト管理情報(MO_INFO)740のデータ構造である。
MO_INFO740は、登録されるメディアオブジェクトの型情報を示すMoType741、メディアオブジェクトへの参照情報であるオブジェクト参照情報MoRef742、少なくともメディアオブジェクトマネージャ320内で重複しない値であるメディアユニークIDが設定されるMoUniqueID743、等から構成される。
重複しないメディアユニークIDの設定方法は、例えば、初期値を0とし、メディアオブジェクトを新たに記録するたびにメディアユニークIDの値を1ずつ加算しながら割り当てていく。そして、ある時点でのメディアユニークIDの最大値をLastMoUniqueID703に記録しておくことにより、記録を一旦中断した時にも次に割り当てるメディアユニークIDの値(すなわち、LastMoUniqueID703に1を加算した値)を容易に決めることができる。
あるいは、図11を用いて説明したように、UDFファイルシステムはファイルシステム上で、各ファイルに対して重複しないUnique ID511を設定するので、このUnique ID511の値をメディアユニークIDの値として流用することも可能である。
なお、本実施の形態においては、MoUniqueID743に設定された値と同じ値を図11(a)で示したEFE510のEAs513中にMoUniqueID541として設定するようにしてもよい。
その他にも、各種属性情報を示すAttributes、当該メディアオブジェクトの再生時間であるPlayBackDuration、MO_INFO740とは異なる場所に格納されるテキスト情報への参照情報TextIDやサムネイル情報への参照情報ThumID等も含んでいる。
図16(b)に示すように、MoType741に設定される値は、参照先のメディアオブジェクトの種類により決まる。
MoTypeの値が“1”である場合、あるオブジェクトメディア情報に登録されているメディアオブジェクトの種類は、ファイルシステム上のあるディレクトリである。同様に、値が“2”の場合には動画オブジェクト(拡張子:MOI)を、値が“3”の時は静止画オブジェクト(拡張子:JPG)を、それぞれ示す。以下同様に、メディアオブジェクトの種類ごとに異なるMoTypeの値を割り当てることとする。
また、MoRef742へ設定される値は、参照先のメディアオブジェクトの持つパス名情報を図16(c)に示す変換規則により変換することにより決定される。
最初のフィールドParent Dir NoはMO_INFO740が参照するメディアオブジェクトの親ディレクトリのパス名により決められる。すなわち、親ディレクトリがVIDEOイメージルートディレクトリ301の場合は“0”、DCIMイメージルートディレクトリ302の場合は“1”となる。それ以外の値については、本実施の形態1では使用しないので予約値としている。
もちろん、変換規則によって与えられる値は別の組み合わせであってもよく、例えば、VIDEOイメージルートディレクトリ301に’1’を、DCIMイメージルートディレクトリ302に’2’を割り当て、その他の場合を予約値とするようにしてもかまわない。
次のフィールドであるDir Noには、MO_INFO740に登録されたメディアオブジェクトのディレクトリ番号部分を抜き出して格納する。ここでディレクトリ番号とは、メディアオブジェクトの上位ディレクトリのディレクトリ名における数値部分である。
次のフィールドであるFile Noには、MO_INFO740に登録されたメディアオブジェクトのファイル番号を抜き出して格納する。ここでファイル番号とは、メディアオブジェクトのファイル名における数値部分である。
例えば、メディアオブジェクトのパス名が、“/VIDEO/100ABCDE/ABCD0001.MOI”である場合、当該メディアオブジェクトは“/VIDEO”ディレクトリを親ディレクトリとして持つので、OBJ_IDのParent Dir Noの値は“0”、そして当該メディアオブジェクトの上位ディレクトリ名の数値部分の値が100であるので、OBJ_IDのDir Noの値は“100”となる。さらに、当該メディアオブジェクトのファイル名の数値部分の値をとって、OBJ_IDのFile Noの値は“0001”となる。
以上より、MoRef742に設定される値は、“/”を区切りとし、Parent Dir No、Dir No、File Noの順に並べる表記によれば、0/100/0001となる。以降、OBJ_IDの値を必要に応じて同様の表記により示す。
OBJ_IDをこのような形式としても、DCF規格の命名規則のように、メディアオブジェクトの名前やその上位ディレクトリの名前に含まれる数値部分の値が重複しないような命名規則を守っておけば、上述のMoType741の値から導かれる拡張子情報とあわせて、ファイルシステム上で、MoRef742が参照しているメディアオブジェクトを特定することが可能である。このような構成はMO_INFO740のデータ量を減らす目的に好適である。
もちろん、OBJ_IDのデータ構造は、MO_INFO740とメディアオブジェクトが一意に対応づけられる形式であれば他の形式でもよい。例えば、メディアオブジェトのパス情報をそのまま格納する方法もある。すなわち、“/VIDOE/100ABCDE/ABCD0001.MOI”のように、“/”をパス区切り文字としたフルパス名の文字列を格納してもよい。
あるいは、MoType740の部分の代わりに、ファイルの拡張子を格納するようにしてもよい。例えば“/VIDOE/100ABCDE/ABCD0001.MOI”というファイルに対しては“MOI”の部分を格納するようにしてもよい。
なお、動画オブジェクトについては、属性情報ファイル(例えば、図8における312)だけをメディアオブジェクト管理情報に登録してもよい。対応する動画ファイル(この場合、図8における311)は、上述のようにファイル名の対応付け等により属性情報ファイルから知ることができるからである。あるいは、逆に、動画ファイルをメディアオブジェクト管理情報に登録するようにしてもよい。同様に対応する属性情報ファイルを知ることができるからである。もちろん、属性情報ファイルと動画ファイルの両方を登録してもかまわない。
次に本実施の形態における拡張オブジェクトの一例であるプログラムマネージャ330のデータ構造について、図17を用いて以下に説明する。
拡張オブジェクトの共通構造として、ヘッダ部800とデータ部801を持つ。
ヘッダ部800は、ファイルのタイプを表すDataType(拡張オブジェクトを示す固定値を設定)、ファイルのサイズを表すDataSize、拡張オブジェクトの型情報を示すEoType811及びEoSubType812、更新時刻を示すModTime813、拡張オブジェクトの概要を示す文字列情報を格納するTextDesc814、等から構成される。
ヘッダ部800において、EoType811、EoSubType812の値により拡張オブジェクトの種類分けを行う。
また、拡張オブジェクトはEO_INFO720から参照されるが、この時、EoType811、EoSubType812及びTextDesc814の値が、EO_INFO720中のEoType721、EoSubType722及びTextDesc726へと設定される。
一方、データ部801は、拡張オブジェクトの種類ごとに固有の拡張データを格納し、EoType811、EoSubType812の値により異なるデータ構造を持つ。
図17(a)は、プログラム再生を行うための拡張オブジェクトであるプログラムマネージャ330の場合の例であり、拡張データとして次のような構造を持つ。
プログラムマネージャ330に登録されたすべてのメディアオブジェクトの再生時間の合計であるPlayBackDuration、プログラムマネージャ330中に含まれるプログラム情報(PRG_INFO)820の数を示すNumPrgInfo、そして、NumPrgInfo個のPRG_INFO820からなるプログラム情報テーブル830で構成される。
そして、図17(b)はプログラムマネージャ330に含まれるプログラム情報(PRG_INFO)820のデータ構造である。PRG_INFO820は、MO_INFO740をグループ化し、ディスクメディア100上に記録された複数のメディアオブジェクトの分類を行ったり、あるいは、PRG_INFO820から参照しているメディアオブジェクトを順に再生することにより、プログラム再生を実現するときの一つの単位である。
図17(b)に示すように、PRG_INFO820は、プログラム情報であることを示すDataType、PRG_INFO820のサイズを示すDataSize、プログラムの各種属性情報を示すAttributes、プログラムの再生時間であるPayBackDuration、PRG_INFO820中に含まれるMO_INFO740への参照の数を示すNumMoInfo、そして、NumMoInfo個のMoIDからなるMO_INFO740への参照テーブル、等から構成される。
その他にも、PRG_INFO820とは異なる場所に格納されるテキスト情報への参照情報TextIDやサムネイル情報への参照情報ThumID等も含んでもよい。
本構造により、拡張オブジェクトであるプログラムマネージャ330は、任意のメディアオブジェクトをグループ化することが可能となる。これにより、ファイルシステム上のディレクトリ構造とは独立して、仮想的なフォルダー構造を構成し、メディアオブジェクトの自由な分類整理を行える。また、ユーザの望みの再生順序でメディアオブジェクトを再生するプログラム再生等の機能も実現できる。
次に、図18を用いて、ファイルシステムで管理されるディレクトリやメディアオブジェクトと、MO_INFO740との関係を説明する。
メディアオブジェクトマネージャ320には、複数のMO_INFO740が含まれており、それぞれにメディアオブジェクトが登録されている。例えば、MoInfo[1]900には、ディレクトリ304が登録されている。この時、MoInfo[1]900のフィールドの値は次のように設定される。
まずMoTypeは、図16(b)より、ディレクトリを示す“1”が設定される。MoRefは、図16(c)より、親ディレクトリ“0”、ディレクトリ番号“100”、ファイル番号“0000”となり、フィールド値全体としては0/100/0000となる。
MoUniqueID743は、ここでは“100”が設定されており、他のMO_INFOに設定されている値と重複していない。
また、MoInfo[2]901のフィールドの値は次のように設定される。まずMoTypeは、動画オブジェクトを示す“2”が設定される。MoRef711は、親ディレクトリ“0”、ディレクトリ番号“100”、ファイル番号“0001”となり、フィールド値全体としては0/100/0001となる。MoUniqueIDは、重複しない値として“101”が設定されている。以降、その他のMoInfoも同様に値が設定される。
図19は、このようなメディアオブジェクトマネージャ320に対する、プログラムマネージャ330の関係を示すものである。上述のように、プログラムマネージャ330には複数のPRG_INFO800(PrgInfo[1]910〜)が含まれる。
各PRG_INFO800は、MO_INFO700への参照情報を、メディアユニークIDとして保持する。すなわち、MO_INFO700がMoUniqueID712で保持しているメディアユニークIDの値を参照情報とする。
例えば、PrgInfo[1]910では、図19中の波線矢印で示すように、MoInfo[2]とMoInfo[5]とMoInfo[8]への参照を持つので、MoIDのテーブル(MoID[])の値として、101、104、201を保持する。PrgInfo[2]911でも同様に、MoInfo[6]とMoInfo[8]への参照を持つので、MoID[]の値として、105、201を保持する。
この状態において、プログラム再生を実施するための処理について説明する。例えば、PrgInfo[1]910によるプログラム再生の開始が支持されたとすると、コンテンツ管理情報処理部611は、PrgInfo[1]910内のメディアオブジェクト情報への参照テーブルMoID[]内の値を読み出す。上述したとおり、MoID[]には、プログラム再生の対象となるメディアオブジェクトへの参照情報がメディアユニークIDとして保持されている。
よって、プログラム再生を行うには、MoID[]に保持されているメディアユニークIDの指し示すMO_INFO740をメディアオブジェクトマネージャ320中から検索し、それが見つかったら、MO_INFO740が参照するメディアオブジェクトの再生を行う。
MoID[]に保持されているすべてのメディアユニークIDに対して同様の手順を繰り返すことによりプログラム再生が実行される。
図20は、複数の拡張オブジェクトが存在する場合において、ファイルシステムで管理されるディレクトリやメディアオブジェクト、メディアオブジェクトマネージャ320との関係を示すものである。ここでは、プログラムマネージャ330とは異なる拡張オブジェクト1000と1001が存在する。
図19を用いて説明したのと同様に、拡張オブジェクト1000と1001はメディアオブジェクトマネージャ320を経由して(例えば、プログラムマネージャ330と同様にメディアユニークIDにより)メディアオブジェクトに対応付けられており、さまざまな拡張情報を提供する。
例えば、拡張オブジェクト1000は、各メディアオブジェクトがこれまでに何回再生されたかの再生回数のカウント値を保持する拡張オブジェクトである。各メディアオブジェクトが再生されるたびにそのカウント値を増加させて、拡張オブジェクト1000内に保持する。このようなカウント値を拡張情報として保持しておくことにより、あるメディアオブジェクトをユーザが既に視聴したかどうかを示すことが出来る。
あるいは、再生回数のカウント値をユーザの録画映像に対する好みの判定に用いることも出来る。例えばカウント値が大きい場合は、ユーザの好みの映像が録画されていると判断し、逆に、カウント値が少ないメディアオブジェクトは好みではないと判断する。このような情報は、例えば、記録媒体100上の空き容量が少なくなったとき、不要なメディアオブジェクトの削除を行う時の参考情報として用いることが可能である。
また、拡張オブジェクト1001は、各メディアオブジェクトに対するGPS情報を格納する。各メディアオブジェクトが記録された時点での位置情報を記録しておき、後に検索や表示するために用いることが可能である。
ユーザが旅行の記念撮影などを行った時に、GPS情報があれば、行き先の位置情報を頼りに、多数のメディアオブジェクトから目的のメディアオブジェクトを容易に探し出すことが可能となる。
なお、拡張オブジェクトとして保持するデータとしては、上記に限られるものではなく、他のデータでもよい。例えば、各メディアオブジェクトに対するcameraパラメータ(記録時のカメラの種別、ズームの有無、フラッシュの有無、等)や、MPEG7などのメタデータ等でもよい。その他、製造メーカが他社製品との差別化やユーザに対する独自の利便性を提供することを目的として、メディアオブジェクトマネージャ320等の統一規格に含まれない機能を実現するために利用してよい。
図21は、図20の状態において、拡張オブジェクト管理情報テーブル710に設定される値の例を示す図である。
図21(a)の一つの行がEO_INFO720に相当する。各EO_INFOのEoType及びEoSubtypeは、それぞれの拡張オブジェクトの内容を識別するための値(ここではそれぞれ2文字のアスキーコード)が設定される。なお、各EoType及びEoSubtypeの値は一例であり、各拡張オブジェクトが識別可能であれば他の値でもかまわない。
EoRefとして、ここでは、拡張オブジェクトのファイル名を格納する。なお、拡張オブジェクトを参照する時のデータ形式は他の形式でもよく、MO_INFO740がメディアオブジェクトを参照する時に使用するOBJ_IDのように、ファイル番号などの特定の変換規則を利用することも可能である。
EoFlagsについては、ここでは、すべての情報が有効であるとし、Valid=1bがすべて設定されている。TextDescは、それぞれの拡張オブジェクトの保持する情報の内容を簡単な文字列として保持している。
図22は、本実施の形態において、新規の拡張オブジェクト及び拡張データを記録するための処理を示すフローチャートである。
まず、拡張情報処理部612が、拡張オブジェクト管理情報テーブル710をメディアオブジェクトマネージャ320から読み出す(ステップS101)。
次に、拡張オブジェクト管理情報テーブル710中の各EO_INFO720の値を調べることにより、追加したい拡張データを含む拡張オブジェクトがすでに存在しているかどうかを調べる(ステップS102)。
拡張オブジェクトが存在していない場合は新規に作成し(ステップS103)、対応するEO_INFO720を拡張オブジェクト管理情報テーブル710へと追加する(ステップS104)。拡張オブジェクトが存在していた場合及び新規に作成した後は、その拡張オブジェクトへ拡張データを追加する(ステップS105)。
図23は、本実施の形態において、メディアオブジェクト及びMO_INFO740に対する何らかの操作が行われた後、拡張オブジェクト管理情報テーブル710に対して行われる処理を示すフローチャートである。ここで、メディアオブジェクト及びMO_INFO740に対する何らかの操作とは、例えば、メディアオブジェクトやMO_INFO740中のデータ値の書き換えや編集及び削除、等のことである。
このような操作が行われると、メディアオブジェクト及びメディアオブジェクトマネージャ320と、拡張オブジェクト及び拡張データ間の情報の不整合が発生する場合がある。
例えば、拡張データの一種であるPRG_INFO820から参照されているメディアオブジェクトが削除されてしまうと、PRG_INFO820からの参照先がなくなってしまい、プログラム再生の実行の際に不都合が生じる。
プログラム再生以外の他の拡張データの場合も同じで、参照先のメディアオブジェクトやMO_INFO740が変更されると、不整合が発生する。
そこで本実施の形態においては、メディアオブジェクト及びメディアオブジェクトマネージャ320に対して何らかの操作が行われると以下の処理を実施する。
まず、拡張情報処理部612は、拡張オブジェクト管理情報テーブル710をメディアオブジェクトマネージャ320から読み出す(ステップS201)。
拡張オブジェクト管理情報テーブル710には、TotalNumEoInfo704で示される数だけEO_INFO720が存在するので、ステップS202からステップS208のループ処理によりすべてのEO_INFO720に対する処理を行う。
まず、ループ処理のカウント値を初期化し(ステップS202)する。
そして、最初の拡張オブジェクトに対して、処理可能かどうかを判別する(ステップS203)。この判別には、EoType721及びEoSubtype722やEoRef723が利用可能である。
ある記録再生装置は、特定の種類の拡張オブジェクトしか操作できない場合があるので、もし、処理不可能な拡張オブジェクトであることがわかったら、Validフラグ731を0bに設定する(ステップS204)。これにより、該拡張オブジェクトとメディアオブジェクト及びメディアオブジェクトマネージャ320との間での整合性を保障しない状態であることを示す。一方、処理可能な拡張オブジェクトであることがわかったら、該拡張オブジェクトの内容を更新し(ステップS205)、Validフラグ731を1bに設定する(ステップS206)。
ここで、該拡張オブジェクトの内容を更新とは、先に行われたメディアオブジェクト及びメディアオブジェクトマネージャ320に対する操作の結果と、該拡張オブジェクトの内容が整合するような処理である。
例えば、拡張オブジェクトがプログラムマネージャ330であり、メディアオブジェクト及びメディアオブジェクトマネージャ320に対する操作が、メディアオブジェクト及びそれを参照するMO_INFO740の削除であった場合、プログラムマネージャ330に対しては、該MO_INFO740を参照するPRG_INFO820を更新し、削除された該MO_INFO740への参照を削除する処理を行う。他の種類の拡張オブジェクトに対しても、それぞれの拡張情報に応じた更新処理を実施する。
更新処理を実施することにより、該拡張オブジェクトとメディアオブジェクト及びメディアオブジェクトマネージャ320との間での整合性を保障できるので、Validフラグ731を1bに設定している。
以降、カウント値を加算しながら、TotalNumEoInfoの値に等しくなるまで処理を繰り返す(ステップS207、ステップS208)。
図23のような処理が終了した後の拡張オブジェクト管理情報テーブル710に設定される値の例を図21(b)に示す。
ここでは、一例として、拡張オブジェクトとしてプログラム再生のみを処理可能であり、他の種類の拡張オブジェクトの処理ができない記録再生装置による処理後の設定値の例を記す。2行目以降のEO_INFO 720のValidフラグが0bに設定され、これらの拡張オブジェクトのデータの有効性が保障されない状態であることを示している。
図24は、本実施の形態において、特定の種類の拡張オブジェクトを指定してそのデータを利用する際の処理に関するフローチャートである。
まず、拡張情報処理部612は、拡張オブジェクト管理情報テーブル710をメディアオブジェクトマネージャ320から読み出す(ステップS301)。
次に、拡張オブジェクト管理情報テーブル710内を検索し、目的の拡張オブジェクトを参照しているEO_INFO720を得る(ステップS302)。目的の拡張オブジェクトの検出は、EoType721及びEoSubtype722の値を調べることにより行える。あるいは拡張オブジェクトのパス名の命名側を決めておくことにより、EoRef723の値を見ることにより検出可能である。
もし、目的の拡張オブジェクトを参照しているEO_INFO720が見つからなければ、例外処理を行い(ステップS303)、本フローチャートで示す処理を終了する。例外処理とは例えば、ユーザに所望の拡張オブジェクトが存在しないことを知らせるメッセージを表示したり、あるいは、新たに、該拡張オブジェクトを作成したりする処理などである。
もし、目的の拡張オブジェクトを参照しているEO_INFO720が見つかれば、Validフラグの値が1bであるかを調べる(ステップS304)。
Validフラグの値が1bでなければ例外処理を実施する(ステップS305)。ここでの例外処理とは例えば、ユーザに所望の拡張オブジェクトとメディアオブジェクトマネージャ320との間で不整合が存在することを知らせるメッセージを表示したり、記録媒体100の書き込みを禁止したり、あるいは、該拡張オブジェクトとメディアオブジェクトマネージャ320の不整合を解消すべく、該拡張オブジェクト内の情報を更新する処理を実施したりする処理、等である。
一方、Validフラグの値が1bであれば、該拡張オブジェクトに対する通常処理を実施する(ステップS306)。通常処理とは、例えば、該拡張オブジェクトが、プログラムマネージャ330であれば、プログラム再生を実施することである。
他の拡張オブジェクトに関しても、あるメディアオブジェクトに関連付けられている拡張データをユーザに対して表示する(GPS情報の表示など)、等、夫々の種類に応じた動作を行う。
図24中の例外処理を行う場合に、少なくともTextDesc726の値を表示するようにすれば、どんな拡張情報が設定されているかをユーザに知らせることが可能である。
以上により、メディアオブジェクトマネージャ320のデータ容量を大幅には増加させず、拡張情報の追加が行える。
これは、DVDレコーダやDVDビデオカメラのような民生の家電機器等のハードウエア資源が限られる記録再生装置において望ましい構成である。また、メディアオブジェクトの編集や削除を行った場合に、ある記録再生装置が対応していない拡張機能が存在しても、データの不整合を最小限に抑制し、かつ、適切なデータ処理方法を決定可能となり、機器の誤動作やシステム停止、ユーザに対する利便性の低下等を回避することが可能となる。
これは、DVDレコーダやDVDビデオカメラなどの可搬型の記録媒体を用いた記録再生装置において、1つの記録媒体が複数の製造メーカによる記録再生装置で記録・再生される場合において望ましい構成である。
(実施の形態2)
本実施の形態では、実施の形態1とは異なる拡張オブジェクトの管理の方法について述べる。実施の形態1では、拡張オブジェクト管理情報テーブル710により拡張オブジェクトを管理したが、本実施の形態では、MO_INFOにより各拡張オブジェクトを管理する。
本実施の形態では、実施の形態1とは異なる拡張オブジェクトの管理の方法について述べる。実施の形態1では、拡張オブジェクト管理情報テーブル710により拡張オブジェクトを管理したが、本実施の形態では、MO_INFOにより各拡張オブジェクトを管理する。
このときの、拡張オブジェクトとMO_INFOの関係を図25に示す。ここでは、メディアオブジェクトマネージャ320に含まれるMO_INFOであるMoInfo[i]〜MoInfo[i+2]がそれぞれ拡張オブジェクト1000、330、1001を参照、管理しているものとする。ただし、本実施の形態におけるMO_INFOは、図26に示す構造を持つものとする。
図26(a)におけるMO_INFO2000は、MO_INFO740に対して、EO_INFO2100のフィールドが追加されている点を除いて同一である。
EO_INFO2100は、EO_INFO720と異なる構造を持ち、図26(b)で示す構造を持つ。
EO_INFO2100は、EO_INFO720からEoRef723とTextDesc726を除いた構造を持ち、EoRef723の代わりにMoType741とMoRef742を、TextDesc726の代わりにTextID744を用いることで同様の機能を果たす。すわわち、MoType741とMoRef742により拡張オブジェクトを参照し、TextDesc726により拡張オブジェクトに対する文字列情報を格納する。
なお、上記機能を実現するために、図16(b)のMoType741の値に対して、拡張オブジェクト(拡張子:EXT)を示す値(例えば“4”)を定義することとする。
また、MoRef 742による参照を行うために、拡張オブジェクトのディレクトリ名やファイル名は、ディレクトリ番号及びファイル番号による一意な参照が可能となるような命名即を用いる。
上記構成により、メディアオブジェクトと拡張オブジェクトを共通の枠組みで管理することが可能となり、装置の実装上、好都合である。
(実施の形態3)
本実施の形態では、異なる拡張オブジェクトの管理の方法について述べる。
本実施の形態では、異なる拡張オブジェクトの管理の方法について述べる。
実施の形態1では、拡張オブジェクト管理情報テーブル710のValidフラグ731において拡張オブジェクトの有効性を管理したが、本実施の形態では、MO_INFOにおいて各拡張オブジェクトの有効性を管理する。
このとき、メディアオブジェクトを参照・管理するMO_INFOは図27に示すデータ構造を持つものとする。
図27(a)におけるMO_INFO3000は、MO_INFO740に対して、拡張データ属性フラグ(RefValidFlag)3100のフィールドが追加されている点を除いて同一である。
RefValidFlag3100は、図27(b)に示す情報を保持する。RefValidFlag3100では、2ビットがひとつの拡張オブジェクトに対応している。
例えば、ビット0〜1は、拡張オブジェクトの内、ファイル番号が0001番を持つものに対応する。同様に、ビット1〜2はファイル番号が0002番に対応し、以降も同様である。
そして、この各2ビットの解釈は、次のとおりである。すなわち、上位ビットは、該MO_INFO3000が管理するメディアオブジェクトに対して、拡張オブジェクトからの参照が存在する(1b)か、存在しない(0b)かを示す。そして、下位ビットは、MO_INFO3000が管理するメディアオブジェクトに対する拡張データが有効である(1b)か無効である(0b)かを示す。
すなわち、この下位ビットは、Validフラグ731と同じ意味を持つ。ただし、このRefValidFlag3100の下位ビットは、MO_INFO3000単位で拡張データが有効かどうかを示すことができ、より詳細な単位での拡張データの管理が可能となっている。
具体的には、例えば図20に示したのと同様な参照関係が存在する場合、図20中のMoInfo[1]のRefValidFlag3100に設定される値は、図27(b)の右端の列「設定値の例」のようになる。
すなわち、MoInfo[1]は、ファイル番号0001を持つ拡張オブジェクトであるプログラムマネージャ330からの参照を持ち、かつその値が有効であるとすると、ビット0〜1は11bという値に設定される。また、同様に、ファイル番号0002を持つ拡張オブジェクトからも参照されており、かつその値が有効であるとすると、ビット2〜3は11bという値に設定される。
一方、ファイル番号0016を持つ拡張オブジェクトも存在するが、そこからは参照されていないので、ビット30〜31は00bという値に設定される。
また、上記状態から、図23を用いて説明した処理と同様、メディアオブジェクトに対する編集操作等が行われると拡張オブジェクトとの整合性が保証されない場合が発生する。
例えば、拡張データの一種であるPRG_INFO820から参照されているメディアオブジェクトが編集され、その再生時間長が変化してしまう(例えば、再生時間が短くなる)と、プログラムの再生時間であるPlayBackDurationが実際の値と異なってしまい、プログラム再生の実行の際にユーザに混乱を与えてしまう。
そこでこの時、図28で示す処理を実施する。
まず、拡張情報処理部612は、編集対象のメディアオブジェク管理情報3000からRefValidFlag3100を読み出す(ステップS401)。
RefValidFlag3100のフィールド長に応じた数だけ拡張オブジェクトが存在する可能性があるので、ステップS402からステップS409のループ処理により、存在するすべての拡張オブジェクトに対する処理を行う。
次に、ループ処理のカウント値を初期化(ステップS402)する。
そして、最初の拡張オブジェクトに対して、該メディアオブジェクトに対して参照する拡張オブジェクトが存在するかを判別する(ステップS203)。この判別は、該拡張オブジェクトに対応するRefValidFlag3100中の2ビットの内、上位ビットの値により行われる。もし、参照が存在しない場合は、ステップ408へ進む。
参照が存在した場合は、該拡張オブジェクトに対して、処理可能かどうかを判別する(ステップS404)。
ある記録再生装置は、特定の種類の拡張オブジェクトしか操作できない場合があるので、もし、処理不可能な拡張オブジェクトであることがわかったら、該拡張オブジェクトに対応するRefValidFlag3100中の2ビットの内、下位ビットの値を0bに設定する(ステップS405)。これにより、該拡張オブジェクトと該メディアオブジェクトとの間での整合性を保障しない状態であることを示す。
一方、処理可能な拡張オブジェクトであることがわかったら、該拡張オブジェクトの内容を更新し(ステップS406)、該拡張オブジェクトに対応するRefValidFlag3100中の2ビットの内、下位ビットの値を1bに設定する(ステップS407)。ここで、拡張オブジェクトの内容を更新とは、例えば、メディアオブジェクトの編集に伴い、プログラムのPlayBackDurationを更新する処理である。
以降、カウント値を加算しながら、全てのRefValidFlag3100に対して処理を繰り返す(ステップS408、ステップS409)。
図28のような処理が終了した後のRefValidFlag3100に設定される値の例を図29に示す。
ここでは、一例として、拡張オブジェクトとしてプログラム再生のみを処理可能であり、他の種類の拡張オブジェクトの処理ができない記録再生装置による処理後の設定値の例を記す。RefValidFlag3100ビット2については1bのまま変化がなく、一方、ビット3が0bに設定され、この拡張オブジェクトからの参照は依然として存在するが、そのデータの有効性が保障されない状態であることを示している。
以上のように、実施の形態1においては、拡張オブジェクト全体に対して有効かどうかをValidフラグ731を用いて管理したが、本実施の形態においては、RefValidFlag3100の下位ビットを用いることにより、メディアオブジェクト及びMO_INFO毎に有効性の管理が可能となり、拡張オブジェクト全体を更新せず、その一部だけを更新するような、より柔軟な管理が可能となる。
また、図24を用いて説明したのと同様、RefValidFlag3100の下位ビットの値を見る(すなわち、図24のステップS304に相当する処理を実施する)ことにより、拡張オブジェクトの情報が有効な場合は通常処理を行い、有効性が保証されない場合は、適切な例外処理や書き込みの禁止、ユーザへのメッセージの表示などを行うことが可能である。
このような構成は、特にメディアオブジェクトマネージャのデータ量が大きい場合、必ずしもその全体を更新しなくてよいので、データ処理量の効率化に有効である。
なお、本実施の形態においては、RefValidFlag3100を32ビット長としたが、他のデータ長でもよく、あるいは、可変長にすることも可能である。可変長にすることにより効率的に拡張オブジェクトの数の変化に対応可能となる。
また、上記においては、RefValidFlag3100のビット0〜1をファイル番号が0001番である拡張オブジェクトに対応するとしたが、RefValidFlag3100の各ビットと拡張オブジェクトとの対応関係についてはこれに限るものではない。例えば、ビット30〜31のようなRefValidFlag3100の上位ビットにファイル番号が0001番である拡張オブジェクトを対応させるようにしても良い。
また、RefValidFlag3100と拡張オブジェクトをそのファイル番号により対応づけたが、他の方法による対応付けを行ってもよい。
(実施の形態4)
本実施の形態では、更新日時情報を用いた拡張オブジェクトの有効性管理方法について述べる。
本実施の形態では、更新日時情報を用いた拡張オブジェクトの有効性管理方法について述べる。
図15(a)で示したように、メディアオブジェクトマネージャ320には、その更新日時を示すModTime702が設けられている。メディアオブジェクトマネージャ320の内容が更新されるたびに、ModTime702の値も更新するものとする。
一方、拡張オブジェクトにもその更新日時を示すModTime812が設けられている。ModTime813も同様に、拡張オブジェクトの内容が更新されるたびに、その値が更新されるものとする。
ただし、図23の処理手順で示したとおり、本発明の記録再生装置においては、処理可能な拡張オブジェクトのみをその内容を更新するものとする(図23のステップS205)。
これにより、メディアオブジェクトに対する編集操作等が行われると、メディアオブジェクトマネージャ320が更新され、さらに、処理可能な拡張オブジェクトのみが更新される。
結果として、ModTime702の値と、処理可能な拡張オブジェクトのModTime813が一致する。一方、処理不可能な拡張オブジェクトは更新されないのでそのModTime813も更新されず、ModTime702の値と一致しなくなる。
よって、本発明の記録再生装置において、ある拡張オブジェクトを処理しようとする時、ModTime702の値とのModTime813の値を比較することにより、該拡張オブジェクトが有効であるかどうかを知ることができる。
これはすなわち、図24で示したValidフラグの値が1bであるかどうかを調べる(図24のステップS304)のと同様の効果があることを意味する。
なお、図17では、拡張オブジェクトとしてプログラムマネージャ330を用いて説明したが、他の拡張オブジェクトでも、ModTime813と同じフィールドを持つことにより同様の効果を得ること可能である。
なお、上述の実施例において、MO_INFO740、2000、3000は、Property Entryと呼ばれることもある。また、MoType741及びMoRef742をあわせて、Binary File Identifierと呼ばれることもある。また、MoUniqueID743は、entry_numberと呼ばれることもある。また、拡張オブジェクトはメーカ独自ファイル、あるいは、プライベートファイルと呼ばれることもある。また、RefValidFlag3100は、vflagsと呼ばれることもある。
なお、上述したいずれの実施の形態においても、記録再生装置及び記録媒体をDVDのような光ディスクメディアを例に挙げて説明しているが、特に限定されるものではなく、その他磁気記録メディアを用いたハードディスクドライブ、光磁気ディスクメディア等、他の記録装置や記録媒体であっても良い。
以上のように、本発明にかかる記録再生装置及び方法によれば、拡張機能のためのデータ追加を効率的に行える。これは、DVDレコーダやDVDビデオカメラのような民生の家電機器等のハードウエア資源が限られる記録再生装置において望ましい構成である。また、メディアオブジェクトの編集や削除を行った場合に、統一規格では定められていないため、ある記録再生装置では対応していない拡張機能または拡張オブジェクトが存在しても、データの不整合を最小限に抑制し、かつ、適切なデータ処理方法を決定可能となり、機器の誤動作やシステム停止、ユーザに対する利便性の低下等を回避することが可能となる。
特に、DVDレコーダやDVDビデオカメラなどの可搬型の記録媒体を用いた民生用の記録再生装置では、1つの記録媒体が複数の製造メーカによる異なる拡張機能を持った記録再生装置で記録・再生されることが想定される。よって、本発明にかかる記録再生装置及び方法により、より大きな効果を得ることが可能となる。
なお、上記の実施形態では、本発明の側面のうち、主に、記録装置、再生装置、記録媒体、記録方法、再生方法に関する実施形態を説明した。しかし、本発明は、他の側面として、前記記録装置の記録動作を制御するプログラム、前記再生装置の再生動作を制御するプログラム、これらのプログラムの提供媒体(プログラム製品)、および、記録媒体に記録されたデータ構造、としても実施することが可能である。当業者であれば、上述の実施形態の説明から、これらの側面の実施形態についても容易に理解することが可能であろう。
本発明は、これらに限定されないが、例えばDVD等の記録媒体や、DVDレコーダやDVDビデオカメラ等の記録・再生装置に利用可能である。
Claims (27)
- 記録媒体に情報の記録を行う記録部と、
前記情報を、パス名により参照可能なディレクトリ階層構造を有したファイルシステム情報を用いてファイルとして管理するファイルシステム処理部と、
前記ディレクトリ及び前記ファイルを、コンテンツ管理情報を用いて管理するコンテンツ管理情報処理部と、
前記ディレクトリ及び前記ファイルに対する拡張情報を管理する拡張情報処理部と、を備えた記録装置であって、
前記コンテンツ管理情報は、
前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、
前記拡張情報を管理する拡張オブジェクト管理情報とを含み、
前記ディレクトリ及び前記ファイルと前記拡張情報とが、前記オブジェクト参照情報を経由して対応付けられていることを特徴とする記録装置。 - 前記拡張オブジェクト管理情報は、
前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性に関する状態を管理する整合性状態管理情報を含み、
前記ディレクトリ及び前記ファイルに対する操作を行う時、
処理可能な種類の前記拡張情報については、前記拡張情報を更新し、
処理不可能な種類の前記拡張情報については、前記拡張情報を更新せず、
前記ディレクトリ及び前記ファイルと、前記拡張情報との整合性の状態に応じ
て前記整合性状態管理情報を更新する、請求項1に記載の記録装置。 - 前記整合性状態管理情報が、
前記メディアオブジェクト管理情報毎に設けられ、
前記拡張情報の種別毎に、
少なくとも、前記拡張情報から前記ディレクトリ及び前記ファイルへの参照関係の有無を示す情報と、
前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性が保証されているか否かを示す情報を含む、
請求項2に記載の記録装置。 - 前記コンテンツ管理情報は、第1の更新日時情報を含み、
前記拡張情報には、第2の更新日時情報を含み、
前記メディアオブジェクト管理情報を更新した時、
前記第1の更新日時情報を更新し、
処理可能な種類の前記拡張情報については、前記第2の更新日時情報に前記第1の更新日時情報と同じ値を設定し、
処理不可能な種類の前記拡張情報については、前記第2の更新日時情報を更新しない、請求項1に記載の記録装置。 - 記録媒体に、コンテンツ情報を、パス名により参照可能なディレクトリ階層構造を有するファイルシステム情報を用いて、ファイルとして記録する工程と、
前記ディレクトリ及び前記ファイルを管理するコンテンツ管理情報を前記記録媒体へ記録する工程と、
前記ディレクトリ及び前記ファイルに対する拡張情報を前記記録媒体へ記録する工程とを備えた記録方法であって、
前記コンテンツ管理情報は、
前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、
前記拡張情報を管理する拡張オブジェクト管理情報とを含み、
前記記録方法は、
前記ディレクトリ及び前記ファイルと前記拡張情報とを前記オブジェクト情報を経由して対応付ける工程を含むことを特徴とする記録方法。 - 前記拡張オブジェクト管理情報は、
前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性に関する状態を管理する整合性状態管理情報を含み、
前記記録方法は、
前記ディレクトリ及び前記ファイルに対する操作を行う時、
処理可能な種類の前記拡張情報を更新する工程と、
前記ディレクトリ及び前記ファイルと、前記拡張情報との整合性の状態に応じて前記整合性状態管理情報を更新する工程とを含む、請求項5に記載の記録方法。 - 前記整合性状態管理情報が、
前記メディアオブジェクト管理情報毎に設けられ、
前記拡張情報の種別毎に、
少なくとも、前記拡張情報から前記ディレクトリ及び前記ファイルへの参照関係の有無を示す情報と、
前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性が保証されているか否かを示す情報を含む、請求項6に記載の記録方法。 - 前記コンテンツ管理情報は、第1の更新日時情報を含み、
前記拡張情報には、第2の更新日時情報を含み、
前記コンテンツ管理情報を更新する工程と、
前記第1の更新日時情報を更新する工程と、
処理可能な種類の前記拡張情報については、前記第2の更新日時情報に前記第1の更新日時情報と同じ値を設定する工程とを含む、請求項5に記載の記録方法。 - 情報が記録された記録媒体であって、
前記情報をパス名により参照可能なディレクトリ階層構造として管理するファイルシステム情報と、
前記ディレクトリ及び前記ファイルを管理するコンテンツ管理情報と、
前記ディレクトリ及び前記ファイルに対する拡張情報とが記録されており、
前記コンテンツ管理情報は、
前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、
前記拡張情報を管理する拡張オブジェクト管理情報とを含み、
前記ディレクトリ及び前記ファイルと前記拡張情報とが前記オブジェクト情報を経由して対応付けられていることを特徴とする記録媒体。 - 前記拡張オブジェクト管理情報は、
前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性に関する状態を管理する整合性状態管理情報を含む、請求項9に記載の記録媒体。 - 前記整合性状態管理情報が、
前記メディアオブジェクト管理情報毎に設けられ、
前記拡張情報の種別毎に、
少なくとも、前記拡張情報から前記ディレクトリ及び前記ファイルへの参照関係の有無を示す情報と、
前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性が保証されているか否かを示す情報を含む、請求項10に記載の記録媒体。 - 前記コンテンツ管理情報は、第1の更新日時情報を含み、
前記拡張情報には、第2の更新日時情報を含み、
前記ディレクトリ及び前記ファイルと、それに対応する前記拡張情報との整合性が保証されている場合に、
前記第1の更新日時情報と前記第2の更新日時情報に同じ値が記録されている、
請求項9に記載の記録媒体。 - 請求項10または11に記載の記録媒体から情報の再生を行う再生装置であって、
前記情報を前記記録媒体から再生する再生部と、
前記ファイルシステム情報を処理するファイルシステム処理部と、
前記拡張情報を処理する拡張情報処理部と、
前記コンテンツ管理情報を処理するコンテンツ管理情報処理部とを備え、
前記拡張情報処理部は、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する時、前記整合性状態管理情報の設定値に従って前記拡張情報に対する処理手順を決定することを特徴とする再生装置。 - 請求項12に記載の記録媒体から情報の再生を行う再生装置であって、
前記情報を前記記録媒体から再生する再生部と、
前記ファイルシステム情報を処理するファイルシステム処理部と、
前記拡張情報を処理する拡張情報処理部と、
前記コンテンツ管理情報を処理するコンテンツ管理情報処理部とを備え、
前記拡張情報処理部は、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する時、前記第1の更新日時情報と前記第2の更新日時情報とが一致するかどうかで、前記拡張情報に対する処理手順を決定することを特徴とする再生装置。 - 請求項10または11に記載の記録媒体から情報の再生を行う再生方法であって、
前記情報を前記記録媒体から再生する工程と、
前記ファイルシステム情報を処理する工程と、
前記拡張情報を処理する工程と、
前記コンテンツ管理情報を処理する工程とを備え、
前記拡張情報処理工程が、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する前に、前記整合性状態管理情報の設定値に従って前記拡張情報に対する処理手順を決定する工程を含むことを特徴とする再生方法。 - 請求項12に記載の記録媒体から情報の再生を行う再生方法であって、
前記情報を前記記録媒体から再生する工程と、
前記ファイルシステム情報を処理する工程と、
前記拡張情報を処理する工程と、
前記コンテンツ管理情報を処理する工程とを備え、
前記拡張情報処理工程が、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する前に、前記第1の更新日時情報と前記第2の更新日時情報とが一致するかどうかで、前記拡張情報に対する処理手順を決定する工程を含むことを特徴とする再生方法。 - 記録媒体へ情報の記録を行う記録装置において、当該記録装置の記録動作を制御するプログラムであって、
前記プログラムは、
記録媒体に、コンテンツ情報を、パス名により参照可能なディレクトリ階層構造を有するファイルシステム情報を用いて、ファイルとして記録する工程と、
前記ディレクトリ及び前記ファイルを管理するコンテンツ管理情報を前記記録媒体へ記録する工程と、
前記ディレクトリ及び前記ファイルに対する拡張情報を前記記録媒体へ記録する工程とを前記記録装置に実行させる命令を含み、
前記コンテンツ管理情報は、
前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、
前記拡張情報を管理する拡張オブジェクト管理情報とを含み、
前記プログラムは、
前記ディレクトリ及び前記ファイルと前記拡張情報とを前記オブジェクト情報を経由して対応付ける工程を前記記録装置に実行させる命令をさらに含むことを特徴とするプログラム。 - 前記拡張オブジェクト管理情報は、
前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性
に関する状態を管理する整合性状態管理情報を含み、
前記プログラムは、
前記記録装置が前記ディレクトリ及び前記ファイルに対する操作を行う時、
処理可能な種類の前記拡張情報を更新する工程と、
前記ディレクトリ及び前記ファイルと、前記拡張情報との整合性の状態に応じ
て前記整合性状態管理情報を更新する工程と前記記録装置に実行させる命令を含む、請求項17に記載のプログラム。 - 前記整合性状態管理情報が、
前記メディアオブジェクト管理情報毎に設けられ、
前記拡張情報の種別毎に、
少なくとも、前記拡張情報から前記ディレクトリ及び前記ファイルへの参照関係の有無を示す情報と、
前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性が保証されているか否かを示す情報を含む、請求項18に記載のプログラム。 - 前記コンテンツ管理情報は、第1の更新日時情報を含み、
前記拡張情報には、第2の更新日時情報を含み、
前記プログラムは、
前記コンテンツ管理情報を更新する工程と、
前記第1の更新日時情報を更新する工程と、
処理可能な種類の前記拡張情報については、前記第2の更新日時情報に前記第1の更新日時情報と同じ値を設定する工程を前記記録装置に実行させる命令を含む、請求項17に記載のプログラム。 - 請求項10または11に記載の記録媒体から情報の再生を行う再生装置において、当該再生装置の再生動作を制御するプログラムであって、
前記プログラムは、
前記情報を前記記録媒体から再生する工程と、
前記ファイルシステム情報を処理する工程と、
前記拡張情報を処理する工程と、
前記コンテンツ管理情報を処理する工程とを前記再生装置に実行させる命令を含むと共に、
前記拡張情報処理工程において、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する前に、前記整合性状態管理情報の設定値に従って前記拡張情報に対する処理手順を決定する工程を前記再生装置に実行させる命令を含むことを特徴とするプログラム。 - 請求項12に記載の記録媒体から情報の再生を行う再生装置において、当該再生装置の再生動作を制御するプログラムであって、
前記プログラムは、
前記情報を前記記録媒体から再生する工程と、
前記ファイルシステム情報を処理する工程と、
前記拡張情報を処理する工程と、
前記コンテンツ管理情報を処理する工程とを前記再生装置に実行させる命令を含むと共に、
前記拡張情報処理工程において、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する前に、前記第1の更新日時情報と前記第2の更新日時情報とが一致するかどうかで、前記拡張情報に対する処理手順を決定する工程を前記再生装置に実行させる命令を含むことを特徴とするプログラム。 - 請求項17〜22のいずれか一項に記載のプログラムを媒体に記録したプログラム提供媒体。
- 記録媒体に記録されたデータ構造であって、
前記記録媒体に記録されたコンテンツ情報をパス名により参照可能なディレクトリ階層構造として管理するファイルシステム情報と、
前記ディレクトリ及び前記ファイルを管理するコンテンツ管理情報と、
前記ディレクトリ及び前記ファイルに対する拡張情報とを含み、
前記コンテンツ管理情報は、
前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、
前記拡張情報を管理する拡張オブジェクト管理情報とを含み、
前記ディレクトリ及び前記ファイルと前記拡張情報とが前記オブジェクト情報を経由して対応付けられていることを特徴とするデータ構造。 - 前記拡張オブジェクト管理情報は、
前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性に関する状態を管理する整合性状態管理情報を含む、請求項24に記載のデータ構造。 - 前記整合性状態管理情報が、
前記メディアオブジェクト管理情報毎に設けられ、
前記拡張情報の種別毎に、
少なくとも、前記拡張情報から前記ディレクトリ及び前記ファイルへの参照関係の有無を示す情報と、
前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性が保証されているか否かを示す情報を含む、請求項25に記載のデータ構造。 - 前記コンテンツ管理情報は、第1の更新日時情報を含み、
前記拡張情報には、第2の更新日時情報を含み、
前記ディレクトリ及び前記ファイルと、それに対応する前記拡張情報との整合性が保証されている場合に、
前記第1の更新日時情報と前記第2の更新日時情報に同じ値が記録されている、請求項24に記載のデータ構造。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003092229 | 2003-03-28 | ||
JP2003092229 | 2003-03-28 | ||
PCT/JP2004/004421 WO2004095285A1 (ja) | 2003-03-28 | 2004-03-29 | 記録媒体およびこれを用いる記録装置並びに再生装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
JPWO2004095285A1 true JPWO2004095285A1 (ja) | 2006-07-13 |
Family
ID=33307893
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2005505698A Withdrawn JPWO2004095285A1 (ja) | 2003-03-28 | 2004-03-29 | 記録媒体およびこれを用いる記録装置並びに再生装置 |
Country Status (4)
Country | Link |
---|---|
US (1) | US20060133223A1 (ja) |
JP (1) | JPWO2004095285A1 (ja) |
CN (1) | CN1723446A (ja) |
WO (1) | WO2004095285A1 (ja) |
Families Citing this family (38)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8539063B1 (en) | 2003-08-29 | 2013-09-17 | Mcafee, Inc. | Method and system for containment of networked application client software by explicit human input |
US7840968B1 (en) | 2003-12-17 | 2010-11-23 | Mcafee, Inc. | Method and system for containment of usage of language interfaces |
JP4739708B2 (ja) * | 2004-08-25 | 2011-08-03 | 株式会社日立製作所 | 放送番組の記録方法及び放送受信装置、並びに、そのための情報記録装置 |
US7873955B1 (en) * | 2004-09-07 | 2011-01-18 | Mcafee, Inc. | Solidifying the executable software set of a computer |
US7856661B1 (en) | 2005-07-14 | 2010-12-21 | Mcafee, Inc. | Classification of software on networked systems |
US7757269B1 (en) | 2006-02-02 | 2010-07-13 | Mcafee, Inc. | Enforcing alignment of approved changes and deployed changes in the software change life-cycle |
US7895573B1 (en) | 2006-03-27 | 2011-02-22 | Mcafee, Inc. | Execution environment file inventory |
US7870387B1 (en) * | 2006-04-07 | 2011-01-11 | Mcafee, Inc. | Program-based authorization |
US8352930B1 (en) | 2006-04-24 | 2013-01-08 | Mcafee, Inc. | Software modification by group to minimize breakage |
JP4552889B2 (ja) * | 2006-05-10 | 2010-09-29 | ソニー株式会社 | 記録装置、記録方法および記録プログラム、ならびに、撮像装置および撮像方法 |
US8555404B1 (en) | 2006-05-18 | 2013-10-08 | Mcafee, Inc. | Connectivity-based authorization |
US9424154B2 (en) | 2007-01-10 | 2016-08-23 | Mcafee, Inc. | Method of and system for computer system state checks |
US8332929B1 (en) | 2007-01-10 | 2012-12-11 | Mcafee, Inc. | Method and apparatus for process enforced configuration management |
WO2008099647A1 (ja) * | 2007-02-16 | 2008-08-21 | Panasonic Corporation | 再生装置 |
WO2008126493A1 (ja) * | 2007-04-09 | 2008-10-23 | Mitsubishi Electric Corporation | 情報記録装置、情報記録方法、情報記録媒体、情報再生装置、情報再生方法、情報伝送装置、及び情報伝送方法 |
US20090043832A1 (en) * | 2007-05-03 | 2009-02-12 | Kivati Software, Llc | Method of determining and storing the state of a computer system |
US8195931B1 (en) | 2007-10-31 | 2012-06-05 | Mcafee, Inc. | Application change control |
US8515075B1 (en) | 2008-01-31 | 2013-08-20 | Mcafee, Inc. | Method of and system for malicious software detection using critical address space protection |
US8615502B2 (en) * | 2008-04-18 | 2013-12-24 | Mcafee, Inc. | Method of and system for reverse mapping vnode pointers |
US8544003B1 (en) | 2008-12-11 | 2013-09-24 | Mcafee, Inc. | System and method for managing virtual machine configurations |
US8381284B2 (en) | 2009-08-21 | 2013-02-19 | Mcafee, Inc. | System and method for enforcing security policies in a virtual environment |
US8341627B2 (en) * | 2009-08-21 | 2012-12-25 | Mcafee, Inc. | Method and system for providing user space address protection from writable memory area in a virtual environment |
US9552497B2 (en) | 2009-11-10 | 2017-01-24 | Mcafee, Inc. | System and method for preventing data loss using virtual machine wrapped applications |
US8925101B2 (en) | 2010-07-28 | 2014-12-30 | Mcafee, Inc. | System and method for local protection against malicious software |
US8938800B2 (en) | 2010-07-28 | 2015-01-20 | Mcafee, Inc. | System and method for network level protection against malicious software |
US8549003B1 (en) | 2010-09-12 | 2013-10-01 | Mcafee, Inc. | System and method for clustering host inventories |
US9075993B2 (en) | 2011-01-24 | 2015-07-07 | Mcafee, Inc. | System and method for selectively grouping and managing program files |
US9112830B2 (en) | 2011-02-23 | 2015-08-18 | Mcafee, Inc. | System and method for interlocking a host and a gateway |
US9594881B2 (en) | 2011-09-09 | 2017-03-14 | Mcafee, Inc. | System and method for passive threat detection using virtual memory inspection |
US8694738B2 (en) | 2011-10-11 | 2014-04-08 | Mcafee, Inc. | System and method for critical address space protection in a hypervisor environment |
US8973144B2 (en) | 2011-10-13 | 2015-03-03 | Mcafee, Inc. | System and method for kernel rootkit protection in a hypervisor environment |
US9069586B2 (en) | 2011-10-13 | 2015-06-30 | Mcafee, Inc. | System and method for kernel rootkit protection in a hypervisor environment |
US8713668B2 (en) | 2011-10-17 | 2014-04-29 | Mcafee, Inc. | System and method for redirected firewall discovery in a network environment |
US8800024B2 (en) | 2011-10-17 | 2014-08-05 | Mcafee, Inc. | System and method for host-initiated firewall discovery in a network environment |
US8739272B1 (en) | 2012-04-02 | 2014-05-27 | Mcafee, Inc. | System and method for interlocking a host and a gateway |
US8973146B2 (en) | 2012-12-27 | 2015-03-03 | Mcafee, Inc. | Herd based scan avoidance system in a network environment |
CN105580023B (zh) | 2013-10-24 | 2019-08-16 | 迈克菲股份有限公司 | 网络环境中的代理辅助的恶意应用阻止 |
CN109309695A (zh) * | 2017-07-27 | 2019-02-05 | 中兴通讯股份有限公司 | 图片处理方法、相应装置及存储介质 |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH11162089A (ja) * | 1997-11-28 | 1999-06-18 | Toshiba Corp | データ再生制御装置、同装置に用いられる記録媒体、データ再生制御方法 |
JP2001022626A (ja) * | 1999-07-12 | 2001-01-26 | Sony Corp | 情報処理装置および方法、並びに媒体 |
WO2001080557A1 (en) * | 2000-04-18 | 2001-10-25 | Matsushita Electric Industrial Co., Ltd. | A storage medium, a data obtaining apparatus, a data holding apparatus, a data obtaining method, and a data holding method |
JP4421129B2 (ja) * | 2000-04-18 | 2010-02-24 | パナソニック株式会社 | データ取得装置、データ格納装置及びその方法 |
JP2003076590A (ja) * | 2001-09-06 | 2003-03-14 | Konica Corp | 画像管理装置、方法およびその方法をコンピュータに実行させるためのプログラム |
-
2004
- 2004-03-29 WO PCT/JP2004/004421 patent/WO2004095285A1/ja active Application Filing
- 2004-03-29 US US10/541,743 patent/US20060133223A1/en not_active Abandoned
- 2004-03-29 CN CN200480001702.6A patent/CN1723446A/zh active Pending
- 2004-03-29 JP JP2005505698A patent/JPWO2004095285A1/ja not_active Withdrawn
Also Published As
Publication number | Publication date |
---|---|
WO2004095285A1 (ja) | 2004-11-04 |
US20060133223A1 (en) | 2006-06-22 |
CN1723446A (zh) | 2006-01-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JPWO2004095285A1 (ja) | 記録媒体およびこれを用いる記録装置並びに再生装置 | |
US8275241B2 (en) | Data management device and method for managing recording medium | |
US6493504B1 (en) | Storage medium, recording apparatus, playback apparatus, recording method, and computer-readable storage medium | |
US20010054168A1 (en) | Recording medium for storing real time recording/reproduction information, method and apparatus for recording and reproducing in real time, and file operating method using the same | |
US20040184775A1 (en) | Recording/reproducing apparatus, recording/reproducing method, computer program providing medium, and recording medium | |
JP4527164B2 (ja) | 記録媒体、記録装置、及び再生装置 | |
JP2002056651A (ja) | 記録装置および方法、再生装置および方法、記録媒体、プログラム、並びに記録媒体 | |
US8165455B2 (en) | Data processing apparatus and data processing method, and computer program | |
US20010043805A1 (en) | Optical disc recording apparatus, computer-readable recording medium recording a file management program, and optical disc | |
KR20040064215A (ko) | 정보 기록 장치 및 방법, 정보 재생 장치 및 방법, 정보기록 매체, 프로그램 저장 매체 및 프로그램 | |
US20070094231A1 (en) | Method of efficiently managing multimedia content and storage medium storing therein multimedia content using the same | |
JP2001157155A (ja) | 記録媒体、記録装置、再生装置、記録方法、及びコンピュータ読みとり可能な記録媒体 | |
US20060120224A1 (en) | Recording/reproduction device, recording/reproduction method, and recording medium | |
JP2001069460A (ja) | 記録方法、記録装置およびコンピュータ読み取り可能な記録媒体 | |
US8046341B2 (en) | Information processing apparatus for reproducing metadata and method, program, and recording medium | |
JP2004252959A (ja) | 記録再生装置、記録再生方法、コンピュータプログラム提供媒体、コンピュータプログラム、および記録媒体 | |
KR100960767B1 (ko) | 기록 방법 및 기록 장치 | |
KR101025088B1 (ko) | 기록 방법 | |
JP2003158714A (ja) | 情報記録装置および方法ならびに情報再生装置および方法 | |
JP2004171311A (ja) | データ管理装置、データ管理方法、記録媒体、データ管理プログラム、データ管理プログラムを格納したコンピュータ読み取り可能な記憶媒体 | |
US6788876B1 (en) | Information recording medium, information recording/reproduction system apparatus, and information recording/reproduction method | |
JP2004302853A (ja) | 記録装置、記録方法及び記録装置又は記録方法により記録された記録媒体、並びに記録媒体を再生する再生装置及び再生方法 | |
JP2006031744A (ja) | Avデータ記録装置および再生装置 | |
WO2006006571A1 (ja) | データ処理装置 | |
JP2001069461A (ja) | 再生装置、再生方法、およびコンピュータ読み取り可能な記録媒体 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A300 | Application deemed to be withdrawn because no request for examination was validly filed |
Free format text: JAPANESE INTERMEDIATE CODE: A300 Effective date: 20070605 |