JP4478218B2 - データ記録装置及びデータ記録媒体 - Google Patents
データ記録装置及びデータ記録媒体 Download PDFInfo
- Publication number
- JP4478218B2 JP4478218B2 JP09085397A JP9085397A JP4478218B2 JP 4478218 B2 JP4478218 B2 JP 4478218B2 JP 09085397 A JP09085397 A JP 09085397A JP 9085397 A JP9085397 A JP 9085397A JP 4478218 B2 JP4478218 B2 JP 4478218B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- file
- array
- recorded
- entry
- 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.)
- Expired - Lifetime
Links
- 238000013479 data entry Methods 0.000 claims description 12
- 238000003491 array Methods 0.000 claims 1
- 239000012634 fragment Substances 0.000 description 50
- 238000010586 diagram Methods 0.000 description 25
- 238000000034 method Methods 0.000 description 7
- 238000007906 compression Methods 0.000 description 6
- 230000006835 compression Effects 0.000 description 6
- 238000013467 fragmentation Methods 0.000 description 5
- 238000006062 fragmentation reaction Methods 0.000 description 5
- 230000006837 decompression Effects 0.000 description 4
- 239000000463 material Substances 0.000 description 4
- 230000002085 persistent effect Effects 0.000 description 3
- 238000004891 communication Methods 0.000 description 2
- 238000013144 data compression Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 238000003032 molecular docking Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
-
- 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/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
- G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
- G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
- G11B27/34—Indicating arrangements
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F2003/0697—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers device management, e.g. handlers, drivers, I/O schedulers
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
- G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
- G11B20/10—Digital recording or reproducing
- G11B20/12—Formatting, e.g. arrangement of data block or words on the record carriers
- G11B20/1217—Formatting, e.g. arrangement of data block or words on the record carriers on 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
-
- 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
Description
【０００１】
【発明の属する技術分野】
本発明は、データ記録装置及びデータ記録媒体に関する。
【０００２】
【従来の技術及び発明が解決しようとする課題】
磁気ディスク媒体や光磁気ディスク媒体等のデータ記録媒体には、通常、「ヘッダ」情報が書き込まれている。このヘッダ情報とは、そのディスク媒体上に記録されているデータ・ファイルの記録位置、現在使用状況、及び属性を定めた情報である。一般的に、ヘッダ情報は、多数のエントリを有する１つまたは複数の長大なテーブル（表）で構成されており、それらエントリの各々が、そのディスク媒体上に記録されている特定の論理ファイルないしセクションの１つずつに関連付けられている。
また、コンピュータのデータベース等のデータ記録装置の方面でも、同様に多数のエントリを有する長大なテーブルが使用されている。
【０００３】
多くの場合、その種のテーブルのエントリは、データ・ファイルがディスク媒体上に記録される順番にセットアップされ（並べられ）、またデータベースの場合であれば、データベース・エントリがそのデータベースにロードされる順番にセットアップされる。しかし、一度記録したファイルまたはロードしたデータベース・エントリのいずれかを後になって削除すると、それによってテーブル内に空きスペースが発生するが、その空きスペースを埋めるためにそのテーブルの全てのエントリを並べ直すことは、面倒であるので、しないのが普通である。ところが、それをしないでいると、一般的な傾向として、ある程度の期間に亘って使用した後には、そのテーブルのあちこちに空きエントリができてくる。
【０００４】
しかし、そのようなテーブルに新たにエントリを追加するときに、そのエントリをそこに割り当てるため、空き状態にあるテーブル・エントリをサーチするとなると、新たなエントリを１つ追加する度にそのテーブルの広範な部分を順番に読み出す作業が必要になる。この作業に伴うデータ処理及び記録媒体へのアクセスのための費用は、馬鹿にならず引き合わないことが多い。従って、新たなテーブル・エントリを追加するには、そのテーブル内の空きスペースにそのエントリを割り当てるよりは、むしろ、既存のエントリ列の最後にそのエントリを付け加える方が容易である。
【０００５】
【課題を解決するための手段】
本発明データ記録装置は、順序付けられた複数のデータ項目から成るデータ・アレイが記録媒体上に記録され、このデータ・アレイから１つのデータ項目を削除したならば新たに記録されるデータ項目をそこに記録することができる空きデータ記録スペースが生じるデータ記録装置において、記録されているデータ・アレイ内の各データ項目位置に夫々が対応した複数のマスク・アレイ・データ・エントリから成るマスク・アレイをこの記録媒体上に記録する手段を備え、この複数のマスク・アレイ・データ・エントリの各々はこのマスク・アレイ内の１個のデータ・ビットから成り、このデータ・ビットの位置及び論理状態により、このデータ・アレイ内のそのマスク・アレイ・データ・エントリに対応した位置にデータ項目が有効に記録されているか否かを示すようにし、このデータ・アレイはファイル・ヘッダ・テーブル及び編集テーブルを有し、このファイル・ヘッダ・テーブル内の各データ項目はこの記録媒体上における夫々のデータ・ファイルの記録位置を定めていると共にこの編集テーブルはこのデータ・ファイルの編集された部分を特定するための情報を表し、このファイル・ヘッダ・テーブル及び編集テーブルにそれぞれ対応したマスク・アレイが記録されるものである。
【０００６】
本発明は、比較的小さなアレイである「マスク」アレイを使用することで上述の問題を解決したものである。このマスク・アレイ内の特定の位置にある１個または複数個の（ただし、１個とする方が好ましい）データ・ビットによって、データ・アレイ内のそれに対応する位置が、空き状態にあるか否かを示すようにしている。従って、データ・アレイそのものと比べてはるかに小さいマスク・アレイにアクセスしてその内容を調べるだけで、そのデータ・アレイ内の最初の空きエントリを探し出すことができる。
【０００７】
また、本発明データ記録媒体は、順序付けられた複数のデータ項目から成るデータ・アレイが記録され、このデータ・アレイから１つのデータ項目を削除したならば新たに記録されるデータ項目をそこに記録することができる空きデータ記録スペースが生じるデータ記録媒体において、記録されているデータ・アレイ内の各データ項目位置に夫々が対応した複数のマスク・アレイ・データ・エントリから成るマスク・アレイが更に記録され、この複数のマスク・アレイ・データ・エントリの各々はこのマスク・アレイ内の１個のデータ・ビットから成り、このデータ・ビットの位置及び論理状態により、このデータ・アレイ内のそのマスク・アレイ・データ・エントリに対応した位置にデータ項目が有効に記録されているか否かを示すようにし、このデータ・アレイはファイル・ヘッダ・テーブル及び編集テーブルを有し、このファイル・ヘッダ・テーブル内の各データ項目はこの記録媒体上における夫々のデータ・ファイルの記録位置を定めていると共にこの編集テーブルはこのデータ・ファイルの編集された部分を特定するための情報を表し、このファイル・ヘッダ・テーブル及び編集テーブルにそれぞれ対応したマスク・アレイが記録されるものである。
【０００８】
【発明の実施の形態】
以下に添付図面を参照しつつ、本発明をその具体的な実施の形態に即して説明して行く。なお、添付図面中、同一ないし対応する要素には同一の参照番号を付した。
図１は、ディジタル・ビデオ編集システム及びそれに付随するビデオ記録装置のブロック図である。
図示のビデオ編集システムはパーソナル・コンピュータ（ＰＣ）１００を含んでおり、このＰＣ１００は、カーソル制御デバイス１１０（マウス等）と、ディスプレイ画面メモリ１２０と、ディスプレイ画面１３０とを有する。本例ではＰＣ１００として、ノートブック型（携帯型）コンピュータであるＩＢＭ社の「シンクパッド」を使用しているため、ＰＣ１００、カーソル制御デバイス１１０、ディスプレイ画面メモリ１２０、及びディスプレイ画面（ＬＣＤ画面）の全てが、単一の携帯型装置として一体化されている（なお、ＩＢＭ社のシンクパッドのカーソル制御デバイス１１０はジョイスティック型の制御デバイスである）。従って、ＰＣとその構成要素との間のデータ通信は、ＰＣの内部バスを介して行われる。
【０００９】
ＰＣ１００は、ＳＣＳＩバスを介してビデオ記録コントローラ１４０との間で通信を行い、更にビデオ記録コントローラ１４０は同じくＳＣＳＩバスを介して光磁気ディスク１５０との間で通信を行う。
【００１０】
本例では、ビデオ記録コントローラ１４０と光磁気ディスク１５０とは、使用時にノートブック型コンピュータをその上に載せて結合する「ドッキングステーション」として製作されている。
【００１１】
このビデオ編集システムは、オフライン方式の非線形編集コントローラとして動作するようにしたものであり、入力してくる放送品質のオーディオ信号及びビデオ信号に対して非常に圧縮比の大きなデータ圧縮処理を施し（この結果、放送用の基準をかなり下回る品質レベルになる）、それを光磁気ディスク１５０に記録する。こうしてソース・ビデオのうちの１つまたは複数のセクションを光磁気ディスク１５０に記録したならば、この編集コントローラを操作するオペレータは、その記録したセクションに処理操作を加えることで、エディット・デシジョン・リスト（ＥＤＬ）を作成することができる。このＥＤＬは、編集されたビデオ出力シーケンスを構成する連続した複数の部分の各々を構成するソース・マテリアル（素材）の「イン・ポイント（始点）」及び「アウト・ポイント（終点）」を定めるビデオのタイムコードのリストである。ただし、光磁気ディスク１５０に記録されるビデオ信号は、放送用の基準をかなり下回る品質レベルのものであるため、このＥＤＬは、それをオリジナルのビデオ・データ（即ち、最初にビデオ記録コントローラ１４０へ供給されたデータ）に適用することで、放送用ないし配布用のビデオを制作することを意図したものである。
【００１２】
図２は、ビデオ記録コントローラ１４０及び光磁気ディスク１５０のブロック図である。
光磁気ディスク１５０は着脱可能なディスク媒体１６０を使用する自立型の装置であり、読み書きヘッド及びそれに付随する回路１７０と、プロセッサ１８０とを備えている。プロセッサ１８０は、ディスク媒体のフォーマッティング及びディスク媒体上でのデータ操作の作業のうちの非常に低レベルの部分を担当するものである。この種の製品の一例は、ソニー社の「ＨＳＤ−６５０型」光磁気ディスク・ドライブである。このソニー社の製品を用いた場合には、光磁気ディスク１５０は「論理ブロック・アドレス（ＬＢＡ）」を（外部の回路から）受け取る。１つのＬＢＡは、ディスク媒体上の多数の論理データ・ブロック（ＬＢ）のうちの１つを定めている。ディスク媒体１６０上の論理ブロックの位置設定及びフォーマッティングはプロセッサ１８０に委されているため、外部から光磁気ディスク１５０を見た限りでは、１つの大容量の（この場合は６５２メガバイト）記録媒体に見え、ＬＢＡにより、その大容量の記録媒体上の小さな記録ブロックに個別にアドレスすることができる。なお、光磁気ディスク１５０は、ＳＣＳＩリンクを介して、読み書き用バッファ及び制御回路１９０との間で通信を行うようにしている。
【００１３】
ＳＣＳＩインターフェース２００は、ノートブック型ＰＣ１００との間で通信を行うために備えられており、また、オーディオ／ビデオ（Ａ／Ｖ）圧縮／伸長回路２１０は、光磁気ディスク１５０に書き込むオーディオ・データ／ビデオ・データに圧縮処理を施し、光磁気ディスク１５０から読み出されたオーディオ・データ／ビデオ・データに伸長処理を施すために備えられている。Ａ／Ｖ圧縮／伸張回路２１０は、公知の画像内圧縮法を採用しており、光磁気ディスクに記録されているデータから個々の画像を再生する際に、他の圧縮画像を参照する必要がない。更に詳しく説明すると、入力ポート２２０へ供給されて入力してくる放送用品質の画像（画像データ）に対して、先ず最初に、水平方向と垂直方向との各々に関して４：１の間引き処理を施す。その間引き処理を施した画像に対して更に、公知のＪＰＥＧ圧縮法を用いて圧縮処理を施すことにより、１画像面あたり約５キロバイトの圧縮画像データを生成する。このように圧縮して記録した画像を光磁気ディスク１５０から読み出すときには、その読み出した圧縮画像に対してＪＰＥＧ伸長処理だけを施す。そのため、ＰＣ１００へ供給される画像は、フル・レートのビデオ画像と比べてはるかに小さなサイズ（４：１に間引かれたサイズ）になっている。しかし、これによって不都合が生じることはなく、なぜならば、こうしてＰＣ１００へ供給される画像は、エディット・デシジョンの位置をどこにするかを決めるためだけに用いられるからである。こうして決定されたエディット・デシジョンが、引き続いて（ＥＤＬを介して）オリジナルの（即ち、圧縮されていない）ビデオ信号に適用される。
【００１４】
光磁気ディスク１５０に記録するオーディオ及びビデオ・データをフォーマッティングする作業の一部を、読み書きバッファ及び制御回路１９０に関するプログラム・ファームウェアに担当させることも可能であるが、本例では、事実上その作業の全てをＰＣ１００に担当させている。従って、ビデオ記録コントローラ１４０は、「能動」記録コントローラというよりはむしろ「非能動」記録コントローラとして動作するように設定してあり、即ち、このビデオ記録コントローラ１４０は、ＰＣ１００からの指示（この指示はＬＢアドレス信号の信号レベルの形で発せられる）に従って、光磁気ディスク１５０に対するデータの読み書きを行う。
【００１５】
光磁気ディスク１５０に記録されているビデオ・データの再生を開始するときには、ＰＣ１００が、再生すべき複数のＬＢをその順序に従って記したＬＢリストを、ビデオ記録コントローラ１４０へダウンロードする。すると、そのリスト中のそれらＬＢに記録されているビデオ・フレームが、そのリスト中の順序に従って再生され、伸長処理を施されてＰＣ１００へ返され、ディスプレイされる。このことから明らかなように、ＰＣ１００は、ビデオ記録コントローラ１４０へ送出するＬＢリストを作成するために、光磁気ディスク１５０のヘッダ領域に記録されているデータにしばしばアクセスする必要がある。
【００１６】
そのために、光磁気ディスク１５０にデータをどのように書き込んでおくかということが、本例の動作上の多くの特徴を成しているので、これより、光磁気ディスクのデータ構成について説明する。
【００１７】
先ず手始めに、図３のＡ及びＢは、５２５ライン方式（走査線数が５２５本のテレビジョン方式）のビデオ信号の場合及び６２５ライン方式のビデオ信号の場合における、ディスク媒体１６０上のデータ構成を模式的に示したものである。
【００１８】
それら２つの場合のいずれにおいても、基本的に、ディスク媒体上の領域が、次のように分割されている。即ち、先頭にヘッダ領域があり、続いてビデオ・データ領域があり、その次にオーディオ・データ領域があり、更にその次に、僅かの使用しないセクタ（論理ブロック）がある。１つのセクタに対応するデータ量は２０４８バイトである。ビデオ及びオーディオ・データに対して施す圧縮処理は、２種類のライン方式の各々について調節され、１枚のディスク媒体に約４４〜４５分のビデオ素材及びオーディオ素材を収められるようにしている。
【００１９】
以下に、図４〜図１５を参照して、ヘッダ領域、ビデオ・データ領域、及びオーディオ・データ領域について詳細に説明する。重要なことなのでここで再度述べておくが、それら３つの領域のフォーマッティングは、論理ブロック・アドレス（ＬＢＡ）に関して行われるものである。非常に低レベルのフォーマッティングはディスク・ドライブが自ら担当するのに対して、このＬＢレベルのフォーマッティングは、ソフトウェア制御の下にＰＣ１００が担当するものである。
【００２０】
図４は、１枚のディスク媒体のヘッダ領域の内容を模式的に示した図である。
このディスク・ヘッダ領域は、長さが２５６セクタ（論理ブロック２５６個）であり、以下に列挙する部分から構成されている。
ディスク・ヘッダ： 論理ブロック１個
実ファイル・マスク： 論理ブロック１個
実ファイル・ネーム・テーブル： 論理ブロック２個
実ファイル・ヘッダ・テーブル： 論理ブロック１６個
仮想ファイル・マスク： 論理ブロック１個
仮想ファイル・ネーム・テーブル： 論理ブロック２個
仮想ファイル・ヘッダ・テーブル： 論理ブロック１６個
ルート・マップ： 論理ブロック６４個
ビデオ編集テーブル・マスク： 論理ブロック１個
ビデオ編集テーブル： 論理ブロック６４個
オーディオ編集テーブル・マスク： 論理ブロック１個
オーディオ編集テーブル： 論理ブロック６４個
これら部分の各々について、以下に更に詳細に説明する。
【００２１】
図５はディスク・ヘッダの部分のファイルを更に詳細に示した図である。このディスク・ヘッダ・ファイルの構成要素の殆どは、説明するまでもなく、その名称を見ただけで内容が明らかなものである。ディスク・ヘッダ・ファイルは、ディスク媒体を（ＰＣの制御の下に）初めてフォーマットする際に書き込まれるファイルであり、このファイルに含まれているのは、使用しているソフトウェアの識別データ、ボリューム・ラベル、そのディスク媒体上の実ファイル及び「仮想ファイル」の個数を表すデータ（実ファイル及び仮想ファイルについては後に詳述する）、それにルート・マップを定めるデータ（ルート・マップについても後に詳述する）であり、またその最後に、そのディスク媒体上に記録されているビデオ・データのライン方式（走査線が何本のテレビジョン方式か）を示すための１ビットを割り当ててある。本例では、１枚のディスク媒体１６０上には、５２５ライン方式のビデオ・データか、６２５ライン方式のビデオ・データかの、いずれか一方しか記録させないようにしており、そのため同じ１枚のディスク媒体上に異なったライン方式のビデオ・データが混在することはない。
【００２２】
１枚のディスク媒体上に記録し得るデータ・ファイルの最大個数は、ファイル・ネーム・テーブル及びファイル・ヘッダ・テーブルの夫々にどれほどのスペースを割り当てるかによって予め決められる。本例の場合、記録可能なデータ・ファイルの最大個数は、実ファイルが２５５個、それに仮想ファイルが２５５個である。
【００２３】
「実」ファイルは、入力ポート２２０からのオーディオ／ビデオ・データを、ディスク媒体１６０上に記録することによって作成されるファイルである。１個の実ファイルは、ファイル・ネームと、ファイル・ヘッダと、ディスク媒体１６０上にデータが記録されたデータ領域とで構成される。ディスク媒体１６０上に記録されたデータの位置は、ファイル・ヘッダによって（ＬＢＡで）定められる。一度作成された実ファイルは、編集操作によって変更を受けることはなく、作成されたときと同じ形のまま維持されるか、さもなくばディスク上から削除されるかのいずれかである。
【００２４】
これに対して「仮想」ファイルは、編集作業を実行することによって作成されるファイルである。１個の仮想ファイルは、ファイル・ネームと、１つのビデオ編集テーブルを指し示すファイル・ヘッダとだけで構成される。仮想ファイルはディスク媒体上に記録されている特定のデータに対して持続的な関連性を持つものではなく、そのディスク媒体上に記録されている１つないし複数の実ファイルに含まれているデータのセクションを指し示す一連のポインタを間接的に与えるものである。
【００２５】
この構成によれば、実際にディスク媒体上のスペースを大幅に節約することができ、これが可能であるのは、編集作業時にデータを記録し直す必要がないからである。一例として、あるディスク媒体上に３個の実ファイルが記録されており、オペレータが、それら３個の実ファイルの各々から例えば１０秒ずつの部分を取り出してつなぎ合わせたものをもって、編集されたビデオ出力シーケンスとしたいと考えたものとする。この場合、それら３個の実ファイルの夫々の部分を物理的に新たな出力用ファイルへコピーする必要はない。即ち、そのようなコピーを行う代わりに、１つの仮想ファイルを作成して、その仮想ファイルが各実ファイル内の選択された部分を指し示すポインタを与えるようにするのである。しかも実際には、仮想ファイルのためのファイル・ヘッダ領域は前もって割り当てられているため、新たに仮想ファイルを作成するのにディスク媒体上のスペースを更に余計に取ることもない。
【００２６】
ヘッダ領域内には、実ファイルのためのファイル・ネーム・テーブルが１つ設けられると共に、それとは別に、仮想ファイルのための同様のファイル・ネーム・テーブルがもう１つ設けられている。それら２つのファイル・ネーム・テーブルは同一形式であり、その具体例を図６に模式的に示した。
【００２７】
これら２つのファイル・ネーム・テーブルの各々は、ファイル・ネームのリスト（１つのファイル・ネームは最大１６文字までである）から成り、そのリスト内における個々のファイル・ネームの位置が、実ファイル・ヘッダ・テーブルまたは仮想ファイル・ヘッダ・テーブル内の対応する位置を指し示すインデックス（即ちファイル番号）となる。従って図示例において、第１番ファイルとは、そのファイル・ネームが、ファイル・ネーム・テーブル内のバイト１７〜３２を占めているファイルである。ファイル・ヘッダ・テーブル内に記入されている当該ファイルについての更に詳細な情報にアドレスする際にも同じファイル番号が使用されるが、それについては後に詳述する。
【００２８】
図７は、実ファイル・ヘッダ・テーブルを模式的に示した図である。実ファイル・ヘッダ・テーブルには、ディスク媒体上に記録できる実ファイルの各々に対応して１つずつのレコード（即ちエントリ）が含まれている。この実ファイル・ヘッダ・テーブルの１つのエントリには、最初にファイル・ネームを転記した項目があり、次にその実ファイルの作成日及び作成時刻がある。次にくるのがその実ファイル内の先頭フレームのタイムコードであり、その次がその実ファイルに含まれるフレームの個数である。
【００２９】
実ファイル・ヘッダ・テーブルのエントリ内の次の３つの項目は、ディスク媒体上におけるその実ファイルのフラグメンテーション（断片化）に関するものである。フラグメンテーションとは、ある１つのファイルのデータが、ディスク媒体上にある連続していない２箇所以上の領域（ここでいう領域は、ＬＢＡで表される領域である）に亘って分割されている状態をいう。これらの項目については後に図９を参照して説明する。
【００３０】
更に続いてテキスト形式の注記のためのスペースとして６４バイトが割り当てられており、それに続く２つの項目は、その実ファイルからの先頭部画像と末尾部画像とを定めている。これら２つの画像は、編集操作時にＰＣのディスプレイ画面上に表示され、それによって、その実ファイルが如何なる性質のものであるかを示すと共に、その実ファイルを識別できるようにするものである。通常は、先頭部画像にはその実ファイル中の文字通り先頭の画像を使用し、末尾部画像にはその実ファイル中の文字通り最後の画像を用いればよい。ただし、オペレータが、その実ファイル中のその他の画像をもって先頭部画像及び末尾部画像としたいのであれば、そのように設定することも可能にしてある。
【００３１】
続く次の１バイトは、考えられる４本のオーディオ・チャネルのうちのどれをその実ファイルに使用するのかを示すために割り当てられているものである。このレコード（エントリ）内の残りのスペースは使用されていない。
【００３２】
この実ファイル・ヘッダ・テーブルに関しては、更にルート・マップの説明もせねばならないが（後に図９を参照して説明する）、ここで特に次の点を再度強調しておく。それは、実ファイル・ヘッダ・テーブルは、ファイル・ネームとの間に持続的な（少なくともその実ファイルが削除されるまでは持続的な）対応関係を有する実データの、ディスク媒体上における位置を定めるものだということである。
【００３３】
図８は、仮想ファイル・ヘッダ・テーブルを模式的に示した図である。仮想ファイル・ヘッダ・テーブルの１つのエントリ内の項目のうちの幾つかは、実ファイル・ヘッダ・テーブルの１つのエントリ内の対応する項目と完全に同一であり、それらについては重複を避けるために説明を省略する。
【００３４】
仮想ファイル・ヘッダ・テーブルと実ファイル・ヘッダ・テーブルとの主たる相違は、仮想ファイル・ヘッダ・テーブルが、ビデオ編集テーブル・インデックスの中の１以上のエントリ及びオーディオ編集テーブル・インデックスの中の１以上のエントリによって、その仮想ファイルに関連したデータを定めていることである（なお、ダブルチェックのために、仮想ファイル・ヘッダ・テーブルのエントリには、予想されるフレームの総数を示す項目を含めてあり、また、編集された出力シーケンスのタイムコードをタイム・プリセット・ワードによって特定の値に設定できるようにしてある）。
【００３５】
ビデオ編集テーブル・インデックス及びオーディオ編集テーブル・インデックスについては後に詳述することとし、ここでは、それらインデックスの概要だけを簡単に述べておく。それらインデックスの各々は、その編集テーブル内の幾つかのエントリが連結されて構成された１つの連結リストであり、各エントリは夫々、１個の実ファイルの１つの部分を表している。それらの連結は、オペレータが、ＰＣ１００に記憶させたＥＤＬエントリをモニタするために、編集された出力シーケンスのプレビューを行うＰＣコマンドを発したときに作成される。ビデオ編集テーブル（ＶＥＴ）の適正なエントリに対応した仮想ファイルも、この時点で（即ち、出力プレビュー・コマンドが発せられた時点で）作成される。
【００３６】
即ち、仮想ファイル・ヘッダ・テーブル内の１つのエントリが、ＶＥＴ内の先頭のエントリを指し示すと共に、そのＶＥＴ内のエントリの総数を定めることによって、１以上の実ファイルにおける複数の部分が連続したシーケンスを定める、特定の長さの連結リストが形成される。
【００３７】
仮想ファイルは、実ファイルの場合と同様にオープンして再生することができる。即ち、ある仮想ファイルを再生するには、ディスク媒体１６０からその仮想ファイルに対応した複数のＶＥＴエントリのリストを読み出し、そして、それら部分をディスク媒体１６０から正しい順序で再生できるように導出されたルート・マップのそれらＶＥＴエントリに対応した部分を読み出す。
【００３８】
図９は、ディスク媒体の「ルート・マップ」を模式的に示した図である。
ルート・マップ（ＲＭ）は、インデックスによって互いにつなぎ合されて幾つかの連結リストが形成される、ディスク媒体上に記録されたレコードのテーブルである。それら連結リストの各々が、そのディスク媒体の表面の複数の物理的位置のパス即ち「ルート」を記述している。ＲＭ内の複数のレコードの各々は、ディスク媒体上の連続する複数のセクタのブロックである「フラグメント」を記述しており、またそれと共に、後続のフラグメントを連結順に記述している別のルート・マップ・レコードのインデックスを含んでいる。１つのルートの記述は、先ず、ディスク媒体上の１つのフラグメントを記述することから始まり、その次に、ルート・マップ内の一連のルート・マップ・インデックスが続き、「ネクスト・レコード」インデックス値が「０」に設定されたレコード（エントリ）で終わる。即ち、「ネクスト・レコード」インデックス値が「０」であることは、そのレコードがそのルートの終点であることを表している（なお、これを可能にするために、ルート・マップ内の先頭のレコード（本来はインデックス「０」で表される）は、使用しないようにしている）。
【００３９】
各実ファイルは、ルート・マップ内に、ディスク媒体上のどこにその実ファイルのデータが存在するのかを記述する１つのルートを有する。また、ルート・マップには、各実ファイルに対応した１つのルートに加えて、ディスク媒体上の空きスペースを記述した別のルート（空きスペース・ルート）が含まれている。この「空きスペース・ルート」の始点は、ディスク・ヘッダ領域内の「空きスペース始点」インデックスによって示されており（図５）、このインデックスは、ＲＭ内のある１つのエントリを指している。この「空きスペース・ルート」は常に、ディスク媒体上のスペースの現在割り当て状態を反映するように維持されている。
【００４０】
新たに１つのファイルを記録する際には、データ書き込み作業を前述の「空きスペース・ルート」に沿って行う。そのデータ書き込みが完了した時点で、ＲＭ内のインデックスの書き直しを行って、その「空きスペース・ルート」から新ファイルのために使用されたルートを削除する。その結果、「空きスペース始点」インデックスは「空きスペース・ルート」に沿う更に向こうの位置を指し示すようになり、新ファイルのために使用されたスペースはとばされる。また、その新ファイルのために作成されたファイル・ヘッダは、その新ファイルのデータを書き込んだ場所を記述したルートを指し示すポインタを含んでいる。こうして、空きスペースであった幾つかのフラグメントにデータが書き込まれるが、書き込みが行われたフラグメントのうち、最後のフラグメントは、通常、その一部分だけしか新ファイルによって消費されていない。この場合には、部分的にしか消費されていないそのフラグメントの残りの部分を記述した新たなエントリをＲＭ内に作成し、その作成したエントリを「空きスペース・ルート」の先頭に連結させる。
【００４１】
一方、幾つかの実ファイルを削除したときには、削除した実ファイルがそれまで占めていた夫々のルートを「空きスペース・ルート」の末尾に連結させることによって、それらルートを「空きスペース・ルート」に再編入させる。ここで、それらルートを「空きスペース・ルート」に連結させる位置が「空きスペース・ルート」の末尾であるという点は重要である。なぜならば、そうすることで、ディスク媒体が満杯に近くなるまでフラグメンテーションを発生させずに済むからである。また、ＲＭ内の複数のルートの各々について、そのルートを構成している複数のフラグメントのうちの、最後のフラグメントを指し示すポインタを維持することによって、各連結最後の項目（エントリ）にアクセスする際に、その連結を表す連結リストをわざわざサーチすることなく、それらの項目に迅速にアクセスできるようにしている。
【００４２】
また、ＲＭ内のエントリ（レコード）の総数のカウントを、ディスク・ヘッダ領域内に含まれている変数「ディスク上のフラグメント数」で示し（図５）、この値を更新維持するようにしている。このカウントは、ディスク媒体のフラグメンテーションの程度を表す指標にもなる。
【００４３】
図１０は、ビデオ編集テーブル（ＶＥＴ）を模式的に示した図である。
ＶＥＴは、１つまたは複数のビデオ編集操作を表したテーブルであり、個々のビデオ編集操作を表すのに、その編集操作に必要と判断された部分（編集部分）を含んでいる実ファイルを特定するのに必要な情報と、その編集部分の始点及び長さを特定するのに必要な情報とで表すようにしている。このテーブルの各エントリ（ＶＥＴエントリ）は、それらの情報に加えて更に、仮想ファイル内でそのＶＥＴエントリの後に続くネクストＶＥＴエントリを指し示すインデックスをも含んでいる。
【００４４】
またこのＶＥＴにおいては、１つの編集部分の始点を表すのに、その編集部分を含んでいる実ファイルの始点からのオフセットを用いるのではなく、その編集部分の始点を含んでいるフラグメント（即ちルート・マップ・エントリ）の始点からのオフセットを用いている。従って、そのフラグメントの始点からのオフセットと、フレーム個数で表したその編集部分の長さとが定められている。このようにして編集部分を表すようにしたため、実ファイル・ヘッダ・テーブルを参照した上でルート・マップをたどるという面倒な手順を取ることなく、編集部分の始点を発見することができる。
【００４５】
図１１は、オーディオ編集テーブル（ＡＥＴ）を模式的に示した図である。
ＡＥＴは、以上に説明したＶＥＴと基本的に同一のテーブルであるが、ＡＥＴは、出力素材における左右の出力チャネルへのオーディオ・チャネルの割り当てを定めたバイトを含んでいる点が異なっている。この割り当てバイト内に適切なビットを設定することで、４本のオーディオチャネル（第１チャネル〜第４チャネル）の各々を個別に、左出力チャネル、右出力チャネル、或いは両出力チャネルに割り当てることができ、また、いずれの出力チャネルにも割り当てないようにすることもできる。
【００４６】
図１２は、「使用状態」マスクがどのように用いられるかを説明した図である。
ここで再び図４を参照して説明すると、ヘッダ領域内の複数の部分のうちマスクが割り当てられている部分は、２番目、５番目、９番目、及び１１番目の部分であり、それら部分に割り当てられているマスクは、夫々、「実ファイル・マスク」、「仮想ファイル・マスク」、「ＶＥＴマスク」、及び「ＡＥＴマスク」と名付けられている。
【００４７】
それらマスクの各々は、複数のデータ・ビットから成る小さなサイズのデータ・アレイである。１つのマスク内の各データビットは、そのマスクに対応したテーブル内の夫々のエントリが、現在使用されているか否かを表す。例えば、実ファイル・マスクでは、その中の各ビットが実ファイル・ネーム・テーブル内の１つ１つのエントリに対応しており、また、ＶＥＴマスクでは、その中の各ビットがビデオ編集テーブル（ＶＥＴ）内の１つ１つのエントリに対応しており、その他のマスクも同様である。
【００４８】
既述のごとく、ネーム・テーブル、ヘッダ・テーブル、及び編集テーブルはいずれも、その中のエントリが、特に決められた順番に従うことなく使用されたり、また（エントリ削除によって）空いたりする。それらテーブルに対応した夫々の「使用状態」マスクは、対応するテーブルに新たに１つのエントリを加える必要が生じたとき（例えば、新たに１個の実ファイルを記録しようとするとき）に、そのテーブル内のエントリのうちのどのエントリが空きエントリになっているのかを、ＰＣに迅速に知らせるために用いられている。
【００４９】
即ち、あるテーブルに新たに１つのエントリを加える必要が生じたときには、使用状態マスク内の「０」に設定されている最初のビット（この設定は「非使用」を表す）を特定すれば、その使用状態マスクの始点からのそのビットの位置が、その使用状態マスクに対応したテーブル内の空きエントリを指し示すインデックスとなる。そして、そのテーブルのエントリを使用するときに、使用状態マスク内のその対応するビットの論理状態を「１」に設定する（この設定は「使用」を表す）。
【００５０】
以上の技法によれば、様々なテーブルの中を空きエントリを求めてサーチする時間を節約することができ、また、その空きエントリをサーチする際にそれらテーブル（それらテーブルが非常に長大なものである場合がある）からの読み出しを行うために何度もディスクにアクセスせずに済む。
【００５１】
図１３は、オーディオ・データ・パケットを模式的に示した図であり、このパケットは、対応するビデオ信号の１フレームに関するオーディオ・データを含んでいる。
【００５２】
このオーディオ・データ・パケットは、ヘッダと、対応するビデオ・フレームのタイムコードと、必要なオーディオ・サンプルとを含んでいる。（同じライン方式の）オーディオ・データ・パケットは、全て同じ長さ（一定長）であるため、オーディオ・データ領域内における、ある１つのオーディオ・データ・パケットから別の１つのオーディオ・データ・パケットまでのオフセットが、オーディオ・データ・パケット何個分に相当するかが分かれば、それらオーディオ・データ・パケットの一方に対する他方の相対位置を知ることができる。
【００５３】
図１４は、図１３と同様のビデオ・データ・パケットを模式的に示した図である。このビデオ・データ・パケットも、ヘッダと、１個のビデオ・フレームのタイムコードと、その１ビデオ・フレームのビデオ・データとを含んでいる。ここでも、１枚のディスク媒体上に記録される、１つのビデオ・ライン方式に対応しているビデオ・データ・パケットは、全て同じ長さ（一定長）である。
【００５４】
最後の図１５は、実ファイルを表すのにルート・マップをどのように使用するか、また、仮想ファイルを表すのにビデオ編集テーブル（ＶＥＴ）をどのように使用するかを説明した模式図である。
【００５５】
図１５は、ディスク媒体の表面を模式的に示しており、このディスク媒体の表面には複数個の論理ブロックが、図中の左上から右下への順序で並んで存在している。図中に細長い長方形で示した４つのセクション３００、３１０、３２０、及び３３０は、ディスク媒体上のフラグメントを表したものであり、ここでいうフラグメントとは、ディスク媒体上の１つの連続したデータ・セクションのことである（実ファイルのフラグメンテーション（断片化）は、先に作成したファイルを削除した後に、新たなファイルを作成した場合に発生しうる）。
【００５６】
フラグメント３２０及び３３０は、その一部分だけにハッチングを施してあるが、このことについては後に詳述する。
【００５７】
フラグメント３００、３１０、３２０、３３０は、その各々がルート・マップ内の夫々１つのエントリに対応している。ルート・マップ内の１つのエントリは、ただ１つの実ファイルにしか関与することができない。もし、ある１つの実ファイルを作成する際にあるフラグメントの一部だけが使用されたとしても、そのフラグメントの残りの部分はより小さな別のフラグメントとして表されるようになる。
【００５８】
フラグメント３００、３１０、３２０、３３０は、ルート・マップを構成しているリストが連結されていることによって、互いに連係している。即ち、ルート・マップ内の各エントリが、ルート・マップ内のネクスト・レコード（ネクスト・エントリ）を指し示している。従って、ルート・マップ内のエントリのうち、フラグメント３００に対応したエントリは、フラグメント３１０に対応したエントリを指し示すポインタを含んでおり、このフラグメント３１０に対応したエントリは、フラグメント３２０に対応したエントリを指し示すポインタを含んでおり、以下同様である。フラグメント３００〜３３０に対応した夫々のエントリは、ルート・マップ内においてどんな順序であっても構わず、特に、連続して並んでいる必要はない。
【００５９】
図１５に示した４つのフラグメント３００〜３３０は、１個の実ファイルに対応したものであり、実ファイル・ヘッダ・テーブルのエントリに含まれている「ルート・マップ内の先頭エントリ」という名の項目（図７参照）が、フラグメント３００に対応したエントリを指している。
【００６０】
従って、この実ファイルをオープンして再生するとき、そのファイル・ヘッダが光磁気ディスク１５０からＰＣ１００へロードされる。ＰＣ１００はそのロードされたファイル・ヘッダから、ＲＭ内の先頭エントリ（図１５の例ではフラグメント３００を指している）と、ＲＭ内のエントリ個数、即ちフラグメント個数（図示例では４個である）と、ＲＭ内の最後のエントリ（図１５の例ではフラグメント３４０を指している）とを読み取る。
【００６１】
この実ファイルを再生するには、先ず最初にフラグメント３００からオーディオ・データ・フレーム及びビデオ・データ・フレームを読み出して再生する。フラグメント３００の末尾に達したならば、このフラグメント３００に対応したＲＭエントリ内のポインタに基づいて、ＲＭを形成している連結リスト内のネクストＲＭエントリ（このネクストＲＭエントリはフラグメント３１０に対応している）にアクセスする。そしてフラグメント３１０のデータを続けて再生する。更に続けてフラグメント３２０のデータを再生し、それに続けてフラグメント３３０のデータを再生する。
【００６２】
ここで、この実ファイルに含まれているフラグメントが以上の４個だけであるとするならば、フラグメント３３０の末尾まで再生した時点で、再生動作は停止する。なぜならば、この時点で (a)それまでに再生したフラグメントの個数が実ファイル・ヘッダ内に定められているフラグメント総数に等しくなり、また、 (b)「最終フラグメント」ポインタがフラグメント３３０を指し示しているからである。ただし、ルート・マップ内でフラグメント３３０に対応したエントリはなお、ネクスト・ルート・マップ・エントリを指し示しており、それによって１つの連続した連結リストが形成されている。
【００６３】
ビデオ編集テーブルの１つのエントリ（１つのＶＥＴエントリ）は、この実ファイル内の一部分、即ちハッチングを施した部分３４０を表している。この場合、そのＶＥＴエントリには、フラグメント３２０に対応したルート・マップ・エントリを指し示すインデックスと、この部分３４０のフラグメント３２０の始点からのオフセットを表すオフセット値（フレーム数で表される）と、この部分３４０の全長を表す長さ値（これもフレーム数で表される）とが含まれている。従って、この項目（即ち部分３４０）をＶＥＴに基づいて再生する際には、先ず、フラグメント３２０に対応したルート・マップ・エントリにアクセスし、このフラグメント３２０の始点から数えて然るべき数の（この数は変数「オフセット」値に等しい）フレームのところから再生動作を開始する。この再生動作は、ルート・マップに定められているフラグメントの連結リストに従って後続のフラグメント３３０へ続き、所要の長さ（フレーム数で表される）の再生が完了した時点で停止する。
【００６４】
ある１つの仮想ファイルを再生するには、ディスク媒体１６０からその仮想ファイルに対応した一連のＶＥＴエントリを読み出す。それには先ず、その仮想ファイルのヘッダ（仮想ファイル・ヘッダ）をロードする。この仮想ファイル・ヘッダには、対応した一連のＶＥＴエントリのうちの先頭ＶＥＴエントリと、それらＶＥＴエントリの総数とが定められている。ＶＥＴは連結リストであって、その中の各エントリがただ１つのネクスト・エントリを指し示しているため、１つの仮想ファイルに対応した一連のＶＥＴエントリを適切に取り出すことができる。そして、ＰＣ１００が（上で説明したようにして）その仮想ファイルの各ＶＥＴエントリに夫々が対応した、一連のルート・マップ・エントリと一連のオフセットとを取り出して、ビデオ記録コントローラ１４０へダウンロードすることにより、ディスク媒体１６０からの再生動作が開始する。
【００６５】
更にオーディオ・データについても、ＡＥＴに基づいて以上と同様の処理を行う。
従って、ビデオ記録コントローラ１４０に関する限り、再生するファイルが実ファイルと仮想ファイルとのいずれであるかにかかわらず、単に、ディスク媒体１６０上の再生すべきＬＢ（論理ブロック）を順序に従って記したリストを受け取り、それに従って再生を行うだけである。
【００６６】
【発明の効果】
以上のように、編集された出力シーケンスを表すのに、ディスク上の複数の実データ領域を連結させて指し示す仮想ファイルの形で表すようにしたため、再生を順方向にも逆方向にも行え、また様々な再生速度で行うことができる。というのは、１つの編集されたの出力シーケンスの全体を単一のファイル、即ち、複数の記録領域を連結させた単一のシーケンスで表すようにしたからである。従って、編集された出力シーケンスを見るために幾つもの実ファイルを特定の順序で次々とオープンしたりクローズしたりせずに済むのである。
【００６７】
また、仮想ファイル及びＶＥＴエントリは、ディスク媒体１６０上に記録されるため、編集作業が完了した時点でディスク媒体１６０上に保持されている。従って、編集作業が完了した後にそのディスク媒体１６０を使用する際には、編集コントローラで仮想ファイルをオープンして再生することができる。
【００６８】
また、ルート・マップを用いることによって、以上に説明したものとは異なったタイプの「ダミー」ファイルである「ＡＬＬ」というファイル・ネームを持つファイルを作成することができる。このファイルをオープンして再生するときには、ＰＣ１００は、ビデオ記録コントローラ１４０に対して単に、ディスク媒体１６０上に記録されている全てのビデオ・データをルート・マップによって指定されている順序で再生するように命令する。これを利用することで、オペレータはディスク媒体１６０の全ての内容を極めて容易に見ることができる。
【図面の簡単な説明】
【図１】ディジタル・ビデオ編集システムのブロック図である。
【図２】ビデオ記録コントローラのブロック図である。
【図３】夫々５２５ライン方式のビデオと６２５ライン方式のビデオとに対応した、ディスク媒体上のデータ構成を模式的に示した図である。
【図４】ディスク・ヘッダ領域の内容を模式的に示した表図である。
【図５】ディスク・ヘッダ・ファイルの内容を模式的に示した表図である。
【図６】ファイル・ネーム・テーブルを模式的に示した図である。
【図７】実ファイル・ヘッダ・テーブルを模式的に示した図である。
【図８】仮想ファイル・ヘッダ・テーブルを模式的に示した図である。
【図９】ディスク媒体のルート・マップを模式的に示した図である。
【図１０】ビデオ編集テーブルを模式的に示した図である。
【図１１】オーディオ編集テーブルを模式的に示した図である。
【図１２】Ａ及びＢは使用状態マスクの機能を説明した模式図である。
【図１３】オーディオ・データ・パケットを模式的に示した図である。
【図１４】ビデオ・データ・パケットを模式的に示した図である。
【図１５】実ファイルを及び仮想ファイルを表すのにルート・マップ及びビデオ編集テーブルをどのように用いるかを示した模式図である。
【符号の説明】
１００ パーソナル・コンピュータ（ＰＣ）、１４０ ビデオ記録コントローラ、１５０ 光磁気ディスク、１６０ ディスク記録媒体、３００、３１０、３２０、３３０ フラグメント
【発明の属する技術分野】
本発明は、データ記録装置及びデータ記録媒体に関する。
【０００２】
【従来の技術及び発明が解決しようとする課題】
磁気ディスク媒体や光磁気ディスク媒体等のデータ記録媒体には、通常、「ヘッダ」情報が書き込まれている。このヘッダ情報とは、そのディスク媒体上に記録されているデータ・ファイルの記録位置、現在使用状況、及び属性を定めた情報である。一般的に、ヘッダ情報は、多数のエントリを有する１つまたは複数の長大なテーブル（表）で構成されており、それらエントリの各々が、そのディスク媒体上に記録されている特定の論理ファイルないしセクションの１つずつに関連付けられている。
また、コンピュータのデータベース等のデータ記録装置の方面でも、同様に多数のエントリを有する長大なテーブルが使用されている。
【０００３】
多くの場合、その種のテーブルのエントリは、データ・ファイルがディスク媒体上に記録される順番にセットアップされ（並べられ）、またデータベースの場合であれば、データベース・エントリがそのデータベースにロードされる順番にセットアップされる。しかし、一度記録したファイルまたはロードしたデータベース・エントリのいずれかを後になって削除すると、それによってテーブル内に空きスペースが発生するが、その空きスペースを埋めるためにそのテーブルの全てのエントリを並べ直すことは、面倒であるので、しないのが普通である。ところが、それをしないでいると、一般的な傾向として、ある程度の期間に亘って使用した後には、そのテーブルのあちこちに空きエントリができてくる。
【０００４】
しかし、そのようなテーブルに新たにエントリを追加するときに、そのエントリをそこに割り当てるため、空き状態にあるテーブル・エントリをサーチするとなると、新たなエントリを１つ追加する度にそのテーブルの広範な部分を順番に読み出す作業が必要になる。この作業に伴うデータ処理及び記録媒体へのアクセスのための費用は、馬鹿にならず引き合わないことが多い。従って、新たなテーブル・エントリを追加するには、そのテーブル内の空きスペースにそのエントリを割り当てるよりは、むしろ、既存のエントリ列の最後にそのエントリを付け加える方が容易である。
【０００５】
【課題を解決するための手段】
本発明データ記録装置は、順序付けられた複数のデータ項目から成るデータ・アレイが記録媒体上に記録され、このデータ・アレイから１つのデータ項目を削除したならば新たに記録されるデータ項目をそこに記録することができる空きデータ記録スペースが生じるデータ記録装置において、記録されているデータ・アレイ内の各データ項目位置に夫々が対応した複数のマスク・アレイ・データ・エントリから成るマスク・アレイをこの記録媒体上に記録する手段を備え、この複数のマスク・アレイ・データ・エントリの各々はこのマスク・アレイ内の１個のデータ・ビットから成り、このデータ・ビットの位置及び論理状態により、このデータ・アレイ内のそのマスク・アレイ・データ・エントリに対応した位置にデータ項目が有効に記録されているか否かを示すようにし、このデータ・アレイはファイル・ヘッダ・テーブル及び編集テーブルを有し、このファイル・ヘッダ・テーブル内の各データ項目はこの記録媒体上における夫々のデータ・ファイルの記録位置を定めていると共にこの編集テーブルはこのデータ・ファイルの編集された部分を特定するための情報を表し、このファイル・ヘッダ・テーブル及び編集テーブルにそれぞれ対応したマスク・アレイが記録されるものである。
【０００６】
本発明は、比較的小さなアレイである「マスク」アレイを使用することで上述の問題を解決したものである。このマスク・アレイ内の特定の位置にある１個または複数個の（ただし、１個とする方が好ましい）データ・ビットによって、データ・アレイ内のそれに対応する位置が、空き状態にあるか否かを示すようにしている。従って、データ・アレイそのものと比べてはるかに小さいマスク・アレイにアクセスしてその内容を調べるだけで、そのデータ・アレイ内の最初の空きエントリを探し出すことができる。
【０００７】
また、本発明データ記録媒体は、順序付けられた複数のデータ項目から成るデータ・アレイが記録され、このデータ・アレイから１つのデータ項目を削除したならば新たに記録されるデータ項目をそこに記録することができる空きデータ記録スペースが生じるデータ記録媒体において、記録されているデータ・アレイ内の各データ項目位置に夫々が対応した複数のマスク・アレイ・データ・エントリから成るマスク・アレイが更に記録され、この複数のマスク・アレイ・データ・エントリの各々はこのマスク・アレイ内の１個のデータ・ビットから成り、このデータ・ビットの位置及び論理状態により、このデータ・アレイ内のそのマスク・アレイ・データ・エントリに対応した位置にデータ項目が有効に記録されているか否かを示すようにし、このデータ・アレイはファイル・ヘッダ・テーブル及び編集テーブルを有し、このファイル・ヘッダ・テーブル内の各データ項目はこの記録媒体上における夫々のデータ・ファイルの記録位置を定めていると共にこの編集テーブルはこのデータ・ファイルの編集された部分を特定するための情報を表し、このファイル・ヘッダ・テーブル及び編集テーブルにそれぞれ対応したマスク・アレイが記録されるものである。
【０００８】
【発明の実施の形態】
以下に添付図面を参照しつつ、本発明をその具体的な実施の形態に即して説明して行く。なお、添付図面中、同一ないし対応する要素には同一の参照番号を付した。
図１は、ディジタル・ビデオ編集システム及びそれに付随するビデオ記録装置のブロック図である。
図示のビデオ編集システムはパーソナル・コンピュータ（ＰＣ）１００を含んでおり、このＰＣ１００は、カーソル制御デバイス１１０（マウス等）と、ディスプレイ画面メモリ１２０と、ディスプレイ画面１３０とを有する。本例ではＰＣ１００として、ノートブック型（携帯型）コンピュータであるＩＢＭ社の「シンクパッド」を使用しているため、ＰＣ１００、カーソル制御デバイス１１０、ディスプレイ画面メモリ１２０、及びディスプレイ画面（ＬＣＤ画面）の全てが、単一の携帯型装置として一体化されている（なお、ＩＢＭ社のシンクパッドのカーソル制御デバイス１１０はジョイスティック型の制御デバイスである）。従って、ＰＣとその構成要素との間のデータ通信は、ＰＣの内部バスを介して行われる。
【０００９】
ＰＣ１００は、ＳＣＳＩバスを介してビデオ記録コントローラ１４０との間で通信を行い、更にビデオ記録コントローラ１４０は同じくＳＣＳＩバスを介して光磁気ディスク１５０との間で通信を行う。
【００１０】
本例では、ビデオ記録コントローラ１４０と光磁気ディスク１５０とは、使用時にノートブック型コンピュータをその上に載せて結合する「ドッキングステーション」として製作されている。
【００１１】
このビデオ編集システムは、オフライン方式の非線形編集コントローラとして動作するようにしたものであり、入力してくる放送品質のオーディオ信号及びビデオ信号に対して非常に圧縮比の大きなデータ圧縮処理を施し（この結果、放送用の基準をかなり下回る品質レベルになる）、それを光磁気ディスク１５０に記録する。こうしてソース・ビデオのうちの１つまたは複数のセクションを光磁気ディスク１５０に記録したならば、この編集コントローラを操作するオペレータは、その記録したセクションに処理操作を加えることで、エディット・デシジョン・リスト（ＥＤＬ）を作成することができる。このＥＤＬは、編集されたビデオ出力シーケンスを構成する連続した複数の部分の各々を構成するソース・マテリアル（素材）の「イン・ポイント（始点）」及び「アウト・ポイント（終点）」を定めるビデオのタイムコードのリストである。ただし、光磁気ディスク１５０に記録されるビデオ信号は、放送用の基準をかなり下回る品質レベルのものであるため、このＥＤＬは、それをオリジナルのビデオ・データ（即ち、最初にビデオ記録コントローラ１４０へ供給されたデータ）に適用することで、放送用ないし配布用のビデオを制作することを意図したものである。
【００１２】
図２は、ビデオ記録コントローラ１４０及び光磁気ディスク１５０のブロック図である。
光磁気ディスク１５０は着脱可能なディスク媒体１６０を使用する自立型の装置であり、読み書きヘッド及びそれに付随する回路１７０と、プロセッサ１８０とを備えている。プロセッサ１８０は、ディスク媒体のフォーマッティング及びディスク媒体上でのデータ操作の作業のうちの非常に低レベルの部分を担当するものである。この種の製品の一例は、ソニー社の「ＨＳＤ−６５０型」光磁気ディスク・ドライブである。このソニー社の製品を用いた場合には、光磁気ディスク１５０は「論理ブロック・アドレス（ＬＢＡ）」を（外部の回路から）受け取る。１つのＬＢＡは、ディスク媒体上の多数の論理データ・ブロック（ＬＢ）のうちの１つを定めている。ディスク媒体１６０上の論理ブロックの位置設定及びフォーマッティングはプロセッサ１８０に委されているため、外部から光磁気ディスク１５０を見た限りでは、１つの大容量の（この場合は６５２メガバイト）記録媒体に見え、ＬＢＡにより、その大容量の記録媒体上の小さな記録ブロックに個別にアドレスすることができる。なお、光磁気ディスク１５０は、ＳＣＳＩリンクを介して、読み書き用バッファ及び制御回路１９０との間で通信を行うようにしている。
【００１３】
ＳＣＳＩインターフェース２００は、ノートブック型ＰＣ１００との間で通信を行うために備えられており、また、オーディオ／ビデオ（Ａ／Ｖ）圧縮／伸長回路２１０は、光磁気ディスク１５０に書き込むオーディオ・データ／ビデオ・データに圧縮処理を施し、光磁気ディスク１５０から読み出されたオーディオ・データ／ビデオ・データに伸長処理を施すために備えられている。Ａ／Ｖ圧縮／伸張回路２１０は、公知の画像内圧縮法を採用しており、光磁気ディスクに記録されているデータから個々の画像を再生する際に、他の圧縮画像を参照する必要がない。更に詳しく説明すると、入力ポート２２０へ供給されて入力してくる放送用品質の画像（画像データ）に対して、先ず最初に、水平方向と垂直方向との各々に関して４：１の間引き処理を施す。その間引き処理を施した画像に対して更に、公知のＪＰＥＧ圧縮法を用いて圧縮処理を施すことにより、１画像面あたり約５キロバイトの圧縮画像データを生成する。このように圧縮して記録した画像を光磁気ディスク１５０から読み出すときには、その読み出した圧縮画像に対してＪＰＥＧ伸長処理だけを施す。そのため、ＰＣ１００へ供給される画像は、フル・レートのビデオ画像と比べてはるかに小さなサイズ（４：１に間引かれたサイズ）になっている。しかし、これによって不都合が生じることはなく、なぜならば、こうしてＰＣ１００へ供給される画像は、エディット・デシジョンの位置をどこにするかを決めるためだけに用いられるからである。こうして決定されたエディット・デシジョンが、引き続いて（ＥＤＬを介して）オリジナルの（即ち、圧縮されていない）ビデオ信号に適用される。
【００１４】
光磁気ディスク１５０に記録するオーディオ及びビデオ・データをフォーマッティングする作業の一部を、読み書きバッファ及び制御回路１９０に関するプログラム・ファームウェアに担当させることも可能であるが、本例では、事実上その作業の全てをＰＣ１００に担当させている。従って、ビデオ記録コントローラ１４０は、「能動」記録コントローラというよりはむしろ「非能動」記録コントローラとして動作するように設定してあり、即ち、このビデオ記録コントローラ１４０は、ＰＣ１００からの指示（この指示はＬＢアドレス信号の信号レベルの形で発せられる）に従って、光磁気ディスク１５０に対するデータの読み書きを行う。
【００１５】
光磁気ディスク１５０に記録されているビデオ・データの再生を開始するときには、ＰＣ１００が、再生すべき複数のＬＢをその順序に従って記したＬＢリストを、ビデオ記録コントローラ１４０へダウンロードする。すると、そのリスト中のそれらＬＢに記録されているビデオ・フレームが、そのリスト中の順序に従って再生され、伸長処理を施されてＰＣ１００へ返され、ディスプレイされる。このことから明らかなように、ＰＣ１００は、ビデオ記録コントローラ１４０へ送出するＬＢリストを作成するために、光磁気ディスク１５０のヘッダ領域に記録されているデータにしばしばアクセスする必要がある。
【００１６】
そのために、光磁気ディスク１５０にデータをどのように書き込んでおくかということが、本例の動作上の多くの特徴を成しているので、これより、光磁気ディスクのデータ構成について説明する。
【００１７】
先ず手始めに、図３のＡ及びＢは、５２５ライン方式（走査線数が５２５本のテレビジョン方式）のビデオ信号の場合及び６２５ライン方式のビデオ信号の場合における、ディスク媒体１６０上のデータ構成を模式的に示したものである。
【００１８】
それら２つの場合のいずれにおいても、基本的に、ディスク媒体上の領域が、次のように分割されている。即ち、先頭にヘッダ領域があり、続いてビデオ・データ領域があり、その次にオーディオ・データ領域があり、更にその次に、僅かの使用しないセクタ（論理ブロック）がある。１つのセクタに対応するデータ量は２０４８バイトである。ビデオ及びオーディオ・データに対して施す圧縮処理は、２種類のライン方式の各々について調節され、１枚のディスク媒体に約４４〜４５分のビデオ素材及びオーディオ素材を収められるようにしている。
【００１９】
以下に、図４〜図１５を参照して、ヘッダ領域、ビデオ・データ領域、及びオーディオ・データ領域について詳細に説明する。重要なことなのでここで再度述べておくが、それら３つの領域のフォーマッティングは、論理ブロック・アドレス（ＬＢＡ）に関して行われるものである。非常に低レベルのフォーマッティングはディスク・ドライブが自ら担当するのに対して、このＬＢレベルのフォーマッティングは、ソフトウェア制御の下にＰＣ１００が担当するものである。
【００２０】
図４は、１枚のディスク媒体のヘッダ領域の内容を模式的に示した図である。
このディスク・ヘッダ領域は、長さが２５６セクタ（論理ブロック２５６個）であり、以下に列挙する部分から構成されている。
ディスク・ヘッダ： 論理ブロック１個
実ファイル・マスク： 論理ブロック１個
実ファイル・ネーム・テーブル： 論理ブロック２個
実ファイル・ヘッダ・テーブル： 論理ブロック１６個
仮想ファイル・マスク： 論理ブロック１個
仮想ファイル・ネーム・テーブル： 論理ブロック２個
仮想ファイル・ヘッダ・テーブル： 論理ブロック１６個
ルート・マップ： 論理ブロック６４個
ビデオ編集テーブル・マスク： 論理ブロック１個
ビデオ編集テーブル： 論理ブロック６４個
オーディオ編集テーブル・マスク： 論理ブロック１個
オーディオ編集テーブル： 論理ブロック６４個
これら部分の各々について、以下に更に詳細に説明する。
【００２１】
図５はディスク・ヘッダの部分のファイルを更に詳細に示した図である。このディスク・ヘッダ・ファイルの構成要素の殆どは、説明するまでもなく、その名称を見ただけで内容が明らかなものである。ディスク・ヘッダ・ファイルは、ディスク媒体を（ＰＣの制御の下に）初めてフォーマットする際に書き込まれるファイルであり、このファイルに含まれているのは、使用しているソフトウェアの識別データ、ボリューム・ラベル、そのディスク媒体上の実ファイル及び「仮想ファイル」の個数を表すデータ（実ファイル及び仮想ファイルについては後に詳述する）、それにルート・マップを定めるデータ（ルート・マップについても後に詳述する）であり、またその最後に、そのディスク媒体上に記録されているビデオ・データのライン方式（走査線が何本のテレビジョン方式か）を示すための１ビットを割り当ててある。本例では、１枚のディスク媒体１６０上には、５２５ライン方式のビデオ・データか、６２５ライン方式のビデオ・データかの、いずれか一方しか記録させないようにしており、そのため同じ１枚のディスク媒体上に異なったライン方式のビデオ・データが混在することはない。
【００２２】
１枚のディスク媒体上に記録し得るデータ・ファイルの最大個数は、ファイル・ネーム・テーブル及びファイル・ヘッダ・テーブルの夫々にどれほどのスペースを割り当てるかによって予め決められる。本例の場合、記録可能なデータ・ファイルの最大個数は、実ファイルが２５５個、それに仮想ファイルが２５５個である。
【００２３】
「実」ファイルは、入力ポート２２０からのオーディオ／ビデオ・データを、ディスク媒体１６０上に記録することによって作成されるファイルである。１個の実ファイルは、ファイル・ネームと、ファイル・ヘッダと、ディスク媒体１６０上にデータが記録されたデータ領域とで構成される。ディスク媒体１６０上に記録されたデータの位置は、ファイル・ヘッダによって（ＬＢＡで）定められる。一度作成された実ファイルは、編集操作によって変更を受けることはなく、作成されたときと同じ形のまま維持されるか、さもなくばディスク上から削除されるかのいずれかである。
【００２４】
これに対して「仮想」ファイルは、編集作業を実行することによって作成されるファイルである。１個の仮想ファイルは、ファイル・ネームと、１つのビデオ編集テーブルを指し示すファイル・ヘッダとだけで構成される。仮想ファイルはディスク媒体上に記録されている特定のデータに対して持続的な関連性を持つものではなく、そのディスク媒体上に記録されている１つないし複数の実ファイルに含まれているデータのセクションを指し示す一連のポインタを間接的に与えるものである。
【００２５】
この構成によれば、実際にディスク媒体上のスペースを大幅に節約することができ、これが可能であるのは、編集作業時にデータを記録し直す必要がないからである。一例として、あるディスク媒体上に３個の実ファイルが記録されており、オペレータが、それら３個の実ファイルの各々から例えば１０秒ずつの部分を取り出してつなぎ合わせたものをもって、編集されたビデオ出力シーケンスとしたいと考えたものとする。この場合、それら３個の実ファイルの夫々の部分を物理的に新たな出力用ファイルへコピーする必要はない。即ち、そのようなコピーを行う代わりに、１つの仮想ファイルを作成して、その仮想ファイルが各実ファイル内の選択された部分を指し示すポインタを与えるようにするのである。しかも実際には、仮想ファイルのためのファイル・ヘッダ領域は前もって割り当てられているため、新たに仮想ファイルを作成するのにディスク媒体上のスペースを更に余計に取ることもない。
【００２６】
ヘッダ領域内には、実ファイルのためのファイル・ネーム・テーブルが１つ設けられると共に、それとは別に、仮想ファイルのための同様のファイル・ネーム・テーブルがもう１つ設けられている。それら２つのファイル・ネーム・テーブルは同一形式であり、その具体例を図６に模式的に示した。
【００２７】
これら２つのファイル・ネーム・テーブルの各々は、ファイル・ネームのリスト（１つのファイル・ネームは最大１６文字までである）から成り、そのリスト内における個々のファイル・ネームの位置が、実ファイル・ヘッダ・テーブルまたは仮想ファイル・ヘッダ・テーブル内の対応する位置を指し示すインデックス（即ちファイル番号）となる。従って図示例において、第１番ファイルとは、そのファイル・ネームが、ファイル・ネーム・テーブル内のバイト１７〜３２を占めているファイルである。ファイル・ヘッダ・テーブル内に記入されている当該ファイルについての更に詳細な情報にアドレスする際にも同じファイル番号が使用されるが、それについては後に詳述する。
【００２８】
図７は、実ファイル・ヘッダ・テーブルを模式的に示した図である。実ファイル・ヘッダ・テーブルには、ディスク媒体上に記録できる実ファイルの各々に対応して１つずつのレコード（即ちエントリ）が含まれている。この実ファイル・ヘッダ・テーブルの１つのエントリには、最初にファイル・ネームを転記した項目があり、次にその実ファイルの作成日及び作成時刻がある。次にくるのがその実ファイル内の先頭フレームのタイムコードであり、その次がその実ファイルに含まれるフレームの個数である。
【００２９】
実ファイル・ヘッダ・テーブルのエントリ内の次の３つの項目は、ディスク媒体上におけるその実ファイルのフラグメンテーション（断片化）に関するものである。フラグメンテーションとは、ある１つのファイルのデータが、ディスク媒体上にある連続していない２箇所以上の領域（ここでいう領域は、ＬＢＡで表される領域である）に亘って分割されている状態をいう。これらの項目については後に図９を参照して説明する。
【００３０】
更に続いてテキスト形式の注記のためのスペースとして６４バイトが割り当てられており、それに続く２つの項目は、その実ファイルからの先頭部画像と末尾部画像とを定めている。これら２つの画像は、編集操作時にＰＣのディスプレイ画面上に表示され、それによって、その実ファイルが如何なる性質のものであるかを示すと共に、その実ファイルを識別できるようにするものである。通常は、先頭部画像にはその実ファイル中の文字通り先頭の画像を使用し、末尾部画像にはその実ファイル中の文字通り最後の画像を用いればよい。ただし、オペレータが、その実ファイル中のその他の画像をもって先頭部画像及び末尾部画像としたいのであれば、そのように設定することも可能にしてある。
【００３１】
続く次の１バイトは、考えられる４本のオーディオ・チャネルのうちのどれをその実ファイルに使用するのかを示すために割り当てられているものである。このレコード（エントリ）内の残りのスペースは使用されていない。
【００３２】
この実ファイル・ヘッダ・テーブルに関しては、更にルート・マップの説明もせねばならないが（後に図９を参照して説明する）、ここで特に次の点を再度強調しておく。それは、実ファイル・ヘッダ・テーブルは、ファイル・ネームとの間に持続的な（少なくともその実ファイルが削除されるまでは持続的な）対応関係を有する実データの、ディスク媒体上における位置を定めるものだということである。
【００３３】
図８は、仮想ファイル・ヘッダ・テーブルを模式的に示した図である。仮想ファイル・ヘッダ・テーブルの１つのエントリ内の項目のうちの幾つかは、実ファイル・ヘッダ・テーブルの１つのエントリ内の対応する項目と完全に同一であり、それらについては重複を避けるために説明を省略する。
【００３４】
仮想ファイル・ヘッダ・テーブルと実ファイル・ヘッダ・テーブルとの主たる相違は、仮想ファイル・ヘッダ・テーブルが、ビデオ編集テーブル・インデックスの中の１以上のエントリ及びオーディオ編集テーブル・インデックスの中の１以上のエントリによって、その仮想ファイルに関連したデータを定めていることである（なお、ダブルチェックのために、仮想ファイル・ヘッダ・テーブルのエントリには、予想されるフレームの総数を示す項目を含めてあり、また、編集された出力シーケンスのタイムコードをタイム・プリセット・ワードによって特定の値に設定できるようにしてある）。
【００３５】
ビデオ編集テーブル・インデックス及びオーディオ編集テーブル・インデックスについては後に詳述することとし、ここでは、それらインデックスの概要だけを簡単に述べておく。それらインデックスの各々は、その編集テーブル内の幾つかのエントリが連結されて構成された１つの連結リストであり、各エントリは夫々、１個の実ファイルの１つの部分を表している。それらの連結は、オペレータが、ＰＣ１００に記憶させたＥＤＬエントリをモニタするために、編集された出力シーケンスのプレビューを行うＰＣコマンドを発したときに作成される。ビデオ編集テーブル（ＶＥＴ）の適正なエントリに対応した仮想ファイルも、この時点で（即ち、出力プレビュー・コマンドが発せられた時点で）作成される。
【００３６】
即ち、仮想ファイル・ヘッダ・テーブル内の１つのエントリが、ＶＥＴ内の先頭のエントリを指し示すと共に、そのＶＥＴ内のエントリの総数を定めることによって、１以上の実ファイルにおける複数の部分が連続したシーケンスを定める、特定の長さの連結リストが形成される。
【００３７】
仮想ファイルは、実ファイルの場合と同様にオープンして再生することができる。即ち、ある仮想ファイルを再生するには、ディスク媒体１６０からその仮想ファイルに対応した複数のＶＥＴエントリのリストを読み出し、そして、それら部分をディスク媒体１６０から正しい順序で再生できるように導出されたルート・マップのそれらＶＥＴエントリに対応した部分を読み出す。
【００３８】
図９は、ディスク媒体の「ルート・マップ」を模式的に示した図である。
ルート・マップ（ＲＭ）は、インデックスによって互いにつなぎ合されて幾つかの連結リストが形成される、ディスク媒体上に記録されたレコードのテーブルである。それら連結リストの各々が、そのディスク媒体の表面の複数の物理的位置のパス即ち「ルート」を記述している。ＲＭ内の複数のレコードの各々は、ディスク媒体上の連続する複数のセクタのブロックである「フラグメント」を記述しており、またそれと共に、後続のフラグメントを連結順に記述している別のルート・マップ・レコードのインデックスを含んでいる。１つのルートの記述は、先ず、ディスク媒体上の１つのフラグメントを記述することから始まり、その次に、ルート・マップ内の一連のルート・マップ・インデックスが続き、「ネクスト・レコード」インデックス値が「０」に設定されたレコード（エントリ）で終わる。即ち、「ネクスト・レコード」インデックス値が「０」であることは、そのレコードがそのルートの終点であることを表している（なお、これを可能にするために、ルート・マップ内の先頭のレコード（本来はインデックス「０」で表される）は、使用しないようにしている）。
【００３９】
各実ファイルは、ルート・マップ内に、ディスク媒体上のどこにその実ファイルのデータが存在するのかを記述する１つのルートを有する。また、ルート・マップには、各実ファイルに対応した１つのルートに加えて、ディスク媒体上の空きスペースを記述した別のルート（空きスペース・ルート）が含まれている。この「空きスペース・ルート」の始点は、ディスク・ヘッダ領域内の「空きスペース始点」インデックスによって示されており（図５）、このインデックスは、ＲＭ内のある１つのエントリを指している。この「空きスペース・ルート」は常に、ディスク媒体上のスペースの現在割り当て状態を反映するように維持されている。
【００４０】
新たに１つのファイルを記録する際には、データ書き込み作業を前述の「空きスペース・ルート」に沿って行う。そのデータ書き込みが完了した時点で、ＲＭ内のインデックスの書き直しを行って、その「空きスペース・ルート」から新ファイルのために使用されたルートを削除する。その結果、「空きスペース始点」インデックスは「空きスペース・ルート」に沿う更に向こうの位置を指し示すようになり、新ファイルのために使用されたスペースはとばされる。また、その新ファイルのために作成されたファイル・ヘッダは、その新ファイルのデータを書き込んだ場所を記述したルートを指し示すポインタを含んでいる。こうして、空きスペースであった幾つかのフラグメントにデータが書き込まれるが、書き込みが行われたフラグメントのうち、最後のフラグメントは、通常、その一部分だけしか新ファイルによって消費されていない。この場合には、部分的にしか消費されていないそのフラグメントの残りの部分を記述した新たなエントリをＲＭ内に作成し、その作成したエントリを「空きスペース・ルート」の先頭に連結させる。
【００４１】
一方、幾つかの実ファイルを削除したときには、削除した実ファイルがそれまで占めていた夫々のルートを「空きスペース・ルート」の末尾に連結させることによって、それらルートを「空きスペース・ルート」に再編入させる。ここで、それらルートを「空きスペース・ルート」に連結させる位置が「空きスペース・ルート」の末尾であるという点は重要である。なぜならば、そうすることで、ディスク媒体が満杯に近くなるまでフラグメンテーションを発生させずに済むからである。また、ＲＭ内の複数のルートの各々について、そのルートを構成している複数のフラグメントのうちの、最後のフラグメントを指し示すポインタを維持することによって、各連結最後の項目（エントリ）にアクセスする際に、その連結を表す連結リストをわざわざサーチすることなく、それらの項目に迅速にアクセスできるようにしている。
【００４２】
また、ＲＭ内のエントリ（レコード）の総数のカウントを、ディスク・ヘッダ領域内に含まれている変数「ディスク上のフラグメント数」で示し（図５）、この値を更新維持するようにしている。このカウントは、ディスク媒体のフラグメンテーションの程度を表す指標にもなる。
【００４３】
図１０は、ビデオ編集テーブル（ＶＥＴ）を模式的に示した図である。
ＶＥＴは、１つまたは複数のビデオ編集操作を表したテーブルであり、個々のビデオ編集操作を表すのに、その編集操作に必要と判断された部分（編集部分）を含んでいる実ファイルを特定するのに必要な情報と、その編集部分の始点及び長さを特定するのに必要な情報とで表すようにしている。このテーブルの各エントリ（ＶＥＴエントリ）は、それらの情報に加えて更に、仮想ファイル内でそのＶＥＴエントリの後に続くネクストＶＥＴエントリを指し示すインデックスをも含んでいる。
【００４４】
またこのＶＥＴにおいては、１つの編集部分の始点を表すのに、その編集部分を含んでいる実ファイルの始点からのオフセットを用いるのではなく、その編集部分の始点を含んでいるフラグメント（即ちルート・マップ・エントリ）の始点からのオフセットを用いている。従って、そのフラグメントの始点からのオフセットと、フレーム個数で表したその編集部分の長さとが定められている。このようにして編集部分を表すようにしたため、実ファイル・ヘッダ・テーブルを参照した上でルート・マップをたどるという面倒な手順を取ることなく、編集部分の始点を発見することができる。
【００４５】
図１１は、オーディオ編集テーブル（ＡＥＴ）を模式的に示した図である。
ＡＥＴは、以上に説明したＶＥＴと基本的に同一のテーブルであるが、ＡＥＴは、出力素材における左右の出力チャネルへのオーディオ・チャネルの割り当てを定めたバイトを含んでいる点が異なっている。この割り当てバイト内に適切なビットを設定することで、４本のオーディオチャネル（第１チャネル〜第４チャネル）の各々を個別に、左出力チャネル、右出力チャネル、或いは両出力チャネルに割り当てることができ、また、いずれの出力チャネルにも割り当てないようにすることもできる。
【００４６】
図１２は、「使用状態」マスクがどのように用いられるかを説明した図である。
ここで再び図４を参照して説明すると、ヘッダ領域内の複数の部分のうちマスクが割り当てられている部分は、２番目、５番目、９番目、及び１１番目の部分であり、それら部分に割り当てられているマスクは、夫々、「実ファイル・マスク」、「仮想ファイル・マスク」、「ＶＥＴマスク」、及び「ＡＥＴマスク」と名付けられている。
【００４７】
それらマスクの各々は、複数のデータ・ビットから成る小さなサイズのデータ・アレイである。１つのマスク内の各データビットは、そのマスクに対応したテーブル内の夫々のエントリが、現在使用されているか否かを表す。例えば、実ファイル・マスクでは、その中の各ビットが実ファイル・ネーム・テーブル内の１つ１つのエントリに対応しており、また、ＶＥＴマスクでは、その中の各ビットがビデオ編集テーブル（ＶＥＴ）内の１つ１つのエントリに対応しており、その他のマスクも同様である。
【００４８】
既述のごとく、ネーム・テーブル、ヘッダ・テーブル、及び編集テーブルはいずれも、その中のエントリが、特に決められた順番に従うことなく使用されたり、また（エントリ削除によって）空いたりする。それらテーブルに対応した夫々の「使用状態」マスクは、対応するテーブルに新たに１つのエントリを加える必要が生じたとき（例えば、新たに１個の実ファイルを記録しようとするとき）に、そのテーブル内のエントリのうちのどのエントリが空きエントリになっているのかを、ＰＣに迅速に知らせるために用いられている。
【００４９】
即ち、あるテーブルに新たに１つのエントリを加える必要が生じたときには、使用状態マスク内の「０」に設定されている最初のビット（この設定は「非使用」を表す）を特定すれば、その使用状態マスクの始点からのそのビットの位置が、その使用状態マスクに対応したテーブル内の空きエントリを指し示すインデックスとなる。そして、そのテーブルのエントリを使用するときに、使用状態マスク内のその対応するビットの論理状態を「１」に設定する（この設定は「使用」を表す）。
【００５０】
以上の技法によれば、様々なテーブルの中を空きエントリを求めてサーチする時間を節約することができ、また、その空きエントリをサーチする際にそれらテーブル（それらテーブルが非常に長大なものである場合がある）からの読み出しを行うために何度もディスクにアクセスせずに済む。
【００５１】
図１３は、オーディオ・データ・パケットを模式的に示した図であり、このパケットは、対応するビデオ信号の１フレームに関するオーディオ・データを含んでいる。
【００５２】
このオーディオ・データ・パケットは、ヘッダと、対応するビデオ・フレームのタイムコードと、必要なオーディオ・サンプルとを含んでいる。（同じライン方式の）オーディオ・データ・パケットは、全て同じ長さ（一定長）であるため、オーディオ・データ領域内における、ある１つのオーディオ・データ・パケットから別の１つのオーディオ・データ・パケットまでのオフセットが、オーディオ・データ・パケット何個分に相当するかが分かれば、それらオーディオ・データ・パケットの一方に対する他方の相対位置を知ることができる。
【００５３】
図１４は、図１３と同様のビデオ・データ・パケットを模式的に示した図である。このビデオ・データ・パケットも、ヘッダと、１個のビデオ・フレームのタイムコードと、その１ビデオ・フレームのビデオ・データとを含んでいる。ここでも、１枚のディスク媒体上に記録される、１つのビデオ・ライン方式に対応しているビデオ・データ・パケットは、全て同じ長さ（一定長）である。
【００５４】
最後の図１５は、実ファイルを表すのにルート・マップをどのように使用するか、また、仮想ファイルを表すのにビデオ編集テーブル（ＶＥＴ）をどのように使用するかを説明した模式図である。
【００５５】
図１５は、ディスク媒体の表面を模式的に示しており、このディスク媒体の表面には複数個の論理ブロックが、図中の左上から右下への順序で並んで存在している。図中に細長い長方形で示した４つのセクション３００、３１０、３２０、及び３３０は、ディスク媒体上のフラグメントを表したものであり、ここでいうフラグメントとは、ディスク媒体上の１つの連続したデータ・セクションのことである（実ファイルのフラグメンテーション（断片化）は、先に作成したファイルを削除した後に、新たなファイルを作成した場合に発生しうる）。
【００５６】
フラグメント３２０及び３３０は、その一部分だけにハッチングを施してあるが、このことについては後に詳述する。
【００５７】
フラグメント３００、３１０、３２０、３３０は、その各々がルート・マップ内の夫々１つのエントリに対応している。ルート・マップ内の１つのエントリは、ただ１つの実ファイルにしか関与することができない。もし、ある１つの実ファイルを作成する際にあるフラグメントの一部だけが使用されたとしても、そのフラグメントの残りの部分はより小さな別のフラグメントとして表されるようになる。
【００５８】
フラグメント３００、３１０、３２０、３３０は、ルート・マップを構成しているリストが連結されていることによって、互いに連係している。即ち、ルート・マップ内の各エントリが、ルート・マップ内のネクスト・レコード（ネクスト・エントリ）を指し示している。従って、ルート・マップ内のエントリのうち、フラグメント３００に対応したエントリは、フラグメント３１０に対応したエントリを指し示すポインタを含んでおり、このフラグメント３１０に対応したエントリは、フラグメント３２０に対応したエントリを指し示すポインタを含んでおり、以下同様である。フラグメント３００〜３３０に対応した夫々のエントリは、ルート・マップ内においてどんな順序であっても構わず、特に、連続して並んでいる必要はない。
【００５９】
図１５に示した４つのフラグメント３００〜３３０は、１個の実ファイルに対応したものであり、実ファイル・ヘッダ・テーブルのエントリに含まれている「ルート・マップ内の先頭エントリ」という名の項目（図７参照）が、フラグメント３００に対応したエントリを指している。
【００６０】
従って、この実ファイルをオープンして再生するとき、そのファイル・ヘッダが光磁気ディスク１５０からＰＣ１００へロードされる。ＰＣ１００はそのロードされたファイル・ヘッダから、ＲＭ内の先頭エントリ（図１５の例ではフラグメント３００を指している）と、ＲＭ内のエントリ個数、即ちフラグメント個数（図示例では４個である）と、ＲＭ内の最後のエントリ（図１５の例ではフラグメント３４０を指している）とを読み取る。
【００６１】
この実ファイルを再生するには、先ず最初にフラグメント３００からオーディオ・データ・フレーム及びビデオ・データ・フレームを読み出して再生する。フラグメント３００の末尾に達したならば、このフラグメント３００に対応したＲＭエントリ内のポインタに基づいて、ＲＭを形成している連結リスト内のネクストＲＭエントリ（このネクストＲＭエントリはフラグメント３１０に対応している）にアクセスする。そしてフラグメント３１０のデータを続けて再生する。更に続けてフラグメント３２０のデータを再生し、それに続けてフラグメント３３０のデータを再生する。
【００６２】
ここで、この実ファイルに含まれているフラグメントが以上の４個だけであるとするならば、フラグメント３３０の末尾まで再生した時点で、再生動作は停止する。なぜならば、この時点で (a)それまでに再生したフラグメントの個数が実ファイル・ヘッダ内に定められているフラグメント総数に等しくなり、また、 (b)「最終フラグメント」ポインタがフラグメント３３０を指し示しているからである。ただし、ルート・マップ内でフラグメント３３０に対応したエントリはなお、ネクスト・ルート・マップ・エントリを指し示しており、それによって１つの連続した連結リストが形成されている。
【００６３】
ビデオ編集テーブルの１つのエントリ（１つのＶＥＴエントリ）は、この実ファイル内の一部分、即ちハッチングを施した部分３４０を表している。この場合、そのＶＥＴエントリには、フラグメント３２０に対応したルート・マップ・エントリを指し示すインデックスと、この部分３４０のフラグメント３２０の始点からのオフセットを表すオフセット値（フレーム数で表される）と、この部分３４０の全長を表す長さ値（これもフレーム数で表される）とが含まれている。従って、この項目（即ち部分３４０）をＶＥＴに基づいて再生する際には、先ず、フラグメント３２０に対応したルート・マップ・エントリにアクセスし、このフラグメント３２０の始点から数えて然るべき数の（この数は変数「オフセット」値に等しい）フレームのところから再生動作を開始する。この再生動作は、ルート・マップに定められているフラグメントの連結リストに従って後続のフラグメント３３０へ続き、所要の長さ（フレーム数で表される）の再生が完了した時点で停止する。
【００６４】
ある１つの仮想ファイルを再生するには、ディスク媒体１６０からその仮想ファイルに対応した一連のＶＥＴエントリを読み出す。それには先ず、その仮想ファイルのヘッダ（仮想ファイル・ヘッダ）をロードする。この仮想ファイル・ヘッダには、対応した一連のＶＥＴエントリのうちの先頭ＶＥＴエントリと、それらＶＥＴエントリの総数とが定められている。ＶＥＴは連結リストであって、その中の各エントリがただ１つのネクスト・エントリを指し示しているため、１つの仮想ファイルに対応した一連のＶＥＴエントリを適切に取り出すことができる。そして、ＰＣ１００が（上で説明したようにして）その仮想ファイルの各ＶＥＴエントリに夫々が対応した、一連のルート・マップ・エントリと一連のオフセットとを取り出して、ビデオ記録コントローラ１４０へダウンロードすることにより、ディスク媒体１６０からの再生動作が開始する。
【００６５】
更にオーディオ・データについても、ＡＥＴに基づいて以上と同様の処理を行う。
従って、ビデオ記録コントローラ１４０に関する限り、再生するファイルが実ファイルと仮想ファイルとのいずれであるかにかかわらず、単に、ディスク媒体１６０上の再生すべきＬＢ（論理ブロック）を順序に従って記したリストを受け取り、それに従って再生を行うだけである。
【００６６】
【発明の効果】
以上のように、編集された出力シーケンスを表すのに、ディスク上の複数の実データ領域を連結させて指し示す仮想ファイルの形で表すようにしたため、再生を順方向にも逆方向にも行え、また様々な再生速度で行うことができる。というのは、１つの編集されたの出力シーケンスの全体を単一のファイル、即ち、複数の記録領域を連結させた単一のシーケンスで表すようにしたからである。従って、編集された出力シーケンスを見るために幾つもの実ファイルを特定の順序で次々とオープンしたりクローズしたりせずに済むのである。
【００６７】
また、仮想ファイル及びＶＥＴエントリは、ディスク媒体１６０上に記録されるため、編集作業が完了した時点でディスク媒体１６０上に保持されている。従って、編集作業が完了した後にそのディスク媒体１６０を使用する際には、編集コントローラで仮想ファイルをオープンして再生することができる。
【００６８】
また、ルート・マップを用いることによって、以上に説明したものとは異なったタイプの「ダミー」ファイルである「ＡＬＬ」というファイル・ネームを持つファイルを作成することができる。このファイルをオープンして再生するときには、ＰＣ１００は、ビデオ記録コントローラ１４０に対して単に、ディスク媒体１６０上に記録されている全てのビデオ・データをルート・マップによって指定されている順序で再生するように命令する。これを利用することで、オペレータはディスク媒体１６０の全ての内容を極めて容易に見ることができる。
【図面の簡単な説明】
【図１】ディジタル・ビデオ編集システムのブロック図である。
【図２】ビデオ記録コントローラのブロック図である。
【図３】夫々５２５ライン方式のビデオと６２５ライン方式のビデオとに対応した、ディスク媒体上のデータ構成を模式的に示した図である。
【図４】ディスク・ヘッダ領域の内容を模式的に示した表図である。
【図５】ディスク・ヘッダ・ファイルの内容を模式的に示した表図である。
【図６】ファイル・ネーム・テーブルを模式的に示した図である。
【図７】実ファイル・ヘッダ・テーブルを模式的に示した図である。
【図８】仮想ファイル・ヘッダ・テーブルを模式的に示した図である。
【図９】ディスク媒体のルート・マップを模式的に示した図である。
【図１０】ビデオ編集テーブルを模式的に示した図である。
【図１１】オーディオ編集テーブルを模式的に示した図である。
【図１２】Ａ及びＢは使用状態マスクの機能を説明した模式図である。
【図１３】オーディオ・データ・パケットを模式的に示した図である。
【図１４】ビデオ・データ・パケットを模式的に示した図である。
【図１５】実ファイルを及び仮想ファイルを表すのにルート・マップ及びビデオ編集テーブルをどのように用いるかを示した模式図である。
【符号の説明】
１００ パーソナル・コンピュータ（ＰＣ）、１４０ ビデオ記録コントローラ、１５０ 光磁気ディスク、１６０ ディスク記録媒体、３００、３１０、３２０、３３０ フラグメント
Claims (3)
- 順序付けられた複数のデータ項目から成るデータ・アレイが記録媒体上に記録され、前記データ・アレイから１つのデータ項目を削除したならば新たに記録されるデータ項目をそこに記録することができる空きデータ記録スペースが生じるデータ記録装置において、
記録されているデータ・アレイ内の各データ項目位置に夫々が対応した複数のマスク・アレイ・データ・エントリから成るマスク・アレイを前記記録媒体上に記録する手段を備え、前記複数のマスク・アレイ・データ・エントリの各々は前記マスク・アレイ内の１個のデータ・ビットから成り、前記データ・ビットの位置及び論理状態により、前記データ・アレイ内のそのマスク・アレイ・データ・エントリに対応した位置にデータ項目が有効に記録されているか否かを示すようにし、前記データ・アレイはファイル・ヘッダ・テーブル及び編集テーブルを有し、前記ファイル・ヘッダ・テーブル内の各データ項目は前記記録媒体上における夫々のデータ・ファイルの記録位置を定めていると共に前記編集テーブルは前記データ・ファイルの編集された部分を特定するための情報を表し、前記ファイル・ヘッダ・テーブル及び編集テーブルにそれぞれ対応したマスク・アレイが記録されることを特徴とするデータ記録装置。 - 前記記録媒体はディスク記録媒体であることを特徴とする請求項１記載のデータ記録装置。
- 順序付けられた複数のデータ項目から成るデータ・アレイが記録され、前記データ・アレイから１つのデータ項目を削除したならば新たに記録されるデータ項目をそこに記録することができる空きデータ記録スペースが生じるデータ記録媒体において、
記録されているデータ・アレイ内の各データ項目位置に夫々が対応した複数のマスク・アレイ・データ・エントリから成るマスク・アレイが更に記録され、前記複数のマスク・アレイ・データ・エントリの各々は前記マスク・アレイ内の１個のデータ・ビットから成り、前記データ・ビットの位置及び論理状態により、前記データ・アレイ内のそのマスク・アレイ・データ・エントリに対応した位置にデータ項目が有効に記録されているか否かを示すようにし、前記データ・アレイはファイル・ヘッダ・テーブル及び編集テーブルを有し、前記ファイル・ヘッダ・テーブル内の各データ項目は前記記録媒体上における夫々のデータ・ファイルの記録位置を定めていると共に前記編集テーブルは前記データ・ファイルの編集された部分を特定するための情報を表し、前記ファイル・ヘッダ・テーブル及び編集テーブルにそれぞれ対応したマスク・アレイが記録されることを特徴とするデータ記録媒体。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB9607692:2 | 1996-04-12 | ||
| GB9607692A GB2312059B (en) | 1996-04-12 | 1996-04-12 | Data storage |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH1031881A JPH1031881A (ja) | 1998-02-03 |
| JP4478218B2 true JP4478218B2 (ja) | 2010-06-09 |
Family
ID=10792021
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP09085397A Expired - Lifetime JP4478218B2 (ja) | 1996-04-12 | 1997-04-09 | データ記録装置及びデータ記録媒体 |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US6215748B1 (ja) |
| JP (1) | JP4478218B2 (ja) |
| GB (1) | GB2312059B (ja) |
Families Citing this family (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2000017874A1 (fr) * | 1998-09-18 | 2000-03-30 | Kabushiki Kaisha Toshiba | Procede d'enregistrement d'informations, dispositif d'enregistrement d'informations et support d'informations |
| GB9822841D0 (en) | 1998-10-20 | 1998-12-16 | Koninkl Philips Electronics Nv | File systems supporting data sharing |
| US6629001B1 (en) * | 1999-09-15 | 2003-09-30 | Intel Corporation | Configurable controller for audio channels |
| US6856755B1 (en) * | 1999-11-10 | 2005-02-15 | Thomson Licensing S.A. | Method and apparatus for editing in a forward or reverse direction on a rewriteable disc media |
| JP2003304388A (ja) * | 2002-04-11 | 2003-10-24 | Sony Corp | 付加情報検出処理装置、コンテンツ再生処理装置、および方法、並びにコンピュータ・プログラム |
| GB2391103B (en) * | 2002-07-19 | 2005-08-17 | Autodesk Canada Inc | Image data processing apparatus |
| US7028106B2 (en) * | 2003-12-05 | 2006-04-11 | Hewlett-Packard Development Company, L.P. | Remapping routing information entries in an expander |
| US8032672B2 (en) * | 2006-04-14 | 2011-10-04 | Apple Inc. | Increased speed of processing of audio samples received over a serial communications link by use of channel map and steering table |
| US8055668B2 (en) * | 2008-02-13 | 2011-11-08 | Camouflage Software, Inc. | Method and system for masking data in a consistent manner across multiple data sources |
| KR102557384B1 (ko) * | 2018-02-14 | 2023-07-19 | 삼성전자주식회사 | 전자장치 및 그 제어방법 |
Family Cites Families (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4939598A (en) * | 1988-02-08 | 1990-07-03 | International Business Machines Corporation | Managing data storage space on large capacity record media |
| GB2218833A (en) * | 1988-05-16 | 1989-11-22 | Ardent Computer Corp | File system |
| US5371885A (en) * | 1989-08-29 | 1994-12-06 | Microsoft Corporation | High performance file system |
| JPH043368A (ja) * | 1990-04-20 | 1992-01-08 | Sony Corp | データ記録方法 |
| US5271018A (en) * | 1990-04-27 | 1993-12-14 | Next, Inc. | Method and apparatus for media defect management and media addressing |
| US5287500A (en) * | 1991-06-03 | 1994-02-15 | Digital Equipment Corporation | System for allocating storage spaces based upon required and optional service attributes having assigned piorities |
| JPH0546447A (ja) * | 1991-08-08 | 1993-02-26 | Hitachi Ltd | 空き領域検索方法 |
| CA2055295C (en) * | 1991-11-12 | 2000-05-23 | Jean Gilles Fecteau | Logical mapping of data objects using data spaces |
| US5390315A (en) * | 1992-06-15 | 1995-02-14 | International Business Machines Corporation | Allocation of uniform contiguous blocks of DASD storage by maintaining both a bit and a bit map record of available storage |
| EP1339062A3 (en) * | 1993-01-06 | 2005-11-09 | Sony Corporation | Recording method of recording medium |
| US5687397A (en) * | 1993-02-26 | 1997-11-11 | Sony Corporation | System for expansion of data storage medium to store user data |
| CA2125331C (en) * | 1993-06-08 | 2000-01-18 | Isao Satoh | Optical disk, and information recording/reproduction apparatus |
| US5838666A (en) * | 1993-06-14 | 1998-11-17 | Sony Corporation | Recording medium management method where recording is carried out by data recording units in accordance with management tables |
| JP3503231B2 (ja) * | 1994-11-30 | 2004-03-02 | ソニー株式会社 | 記録装置 |
| US5732402A (en) * | 1995-02-10 | 1998-03-24 | International Business Machines Corporation | System and method for data space management using buddy system space allocation |
| US5819290A (en) * | 1995-04-10 | 1998-10-06 | Sony Corporation | Data recording and management system and method for detecting data file division based on quantitative number of blocks |
| US5715221A (en) * | 1995-04-21 | 1998-02-03 | Matsushita Electric Industrial | Method for managing defects in an information recording medium, and a device and information recording medium using said method |
| US5715455A (en) * | 1995-05-18 | 1998-02-03 | International Business Machines Corporation | Apparatus and method for storing file allocation table efficiently in memory |
| US5778394A (en) * | 1996-12-23 | 1998-07-07 | Emc Corporation | Space reclamation system and method for use in connection with tape logging system |
-
1996
- 1996-04-12 GB GB9607692A patent/GB2312059B/en not_active Expired - Fee Related
-
1997
- 1997-04-09 US US08/833,721 patent/US6215748B1/en not_active Expired - Fee Related
- 1997-04-09 JP JP09085397A patent/JP4478218B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JPH1031881A (ja) | 1998-02-03 |
| GB2312059B (en) | 2000-11-15 |
| US6215748B1 (en) | 2001-04-10 |
| GB2312059A (en) | 1997-10-15 |
| GB9607692D0 (en) | 1996-06-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3857381B2 (ja) | 編集装置及びデータ記録媒体 | |
| US6341278B1 (en) | Recording and reproducing apparatus and method for accessing data stored on a randomly accessible recording medium, and for managing data thereon | |
| JP4242966B2 (ja) | リアルタイム記録／再生情報を貯蔵する記録媒体 | |
| KR100465355B1 (ko) | 정보데이터기록재생장치및방법 | |
| RU2181219C2 (ru) | Носитель записи для запоминания виртуально удаленной информации неподвижного изображения, способ записи и/или воспроизведения и устройство их реализации | |
| US5566379A (en) | Economical recording and reproducing apparatus which performs real-time processing of digital audio data | |
| US7058770B2 (en) | Method and apparatus for controlling the recording of digital information, by using unit management table | |
| JP4478218B2 (ja) | データ記録装置及びデータ記録媒体 | |
| JP4256075B2 (ja) | ファイルシステム及び記憶領域の管理方法 | |
| US5974220A (en) | Video editing method, non-linear video editing apparatus, and video editing program storage medium | |
| KR100484332B1 (ko) | 정보데이터기록·재생장치 | |
| KR100374032B1 (ko) | 이동통신시스템의코딩및주파수다이버시티구현방법및장치 | |
| JP4401132B2 (ja) | 循環記録装置 | |
| US6516134B1 (en) | Data recording/reproducing method and apparatus | |
| JPH08241230A (ja) | データ管理方法およびデータ記録装置 | |
| JP3521165B2 (ja) | ファイル管理システム及び方法 | |
| JPH11195287A (ja) | フアイル管理装置及びフアイル管理方法 | |
| JPH08227371A (ja) | データ管理方法 | |
| WO1999000728A1 (fr) | Dispositif de gestion de fichiers, procede de gestion de fichiers et support d'enregistrement associe a un programme de gestion de fichiers | |
| KR20000035410A (ko) | 데이터 기록 장치 및 방법과, 데이터 재생 방법 및 기록매체 | |
| JP4006712B2 (ja) | フアイル管理装置及びフアイル管理方法 | |
| JP2000224523A (ja) | デ―タ記録再生装置とその方法 | |
| JP3311143B2 (ja) | マルチメディア番組蓄積及び再生システム | |
| RU2303823C2 (ru) | Способ обработки, записи и воспроизведения файлов реального времени | |
| JP4134429B2 (ja) | 情報記録媒体と情報記録再生方法及び情報記録再生システム装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060425 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060725 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20060829 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061222 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20070115 |
|
| A912 | Re-examination (zenchi) completed and case transferred to appeal board |
Free format text: JAPANESE INTERMEDIATE CODE: A912 Effective date: 20070223 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20100315 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130319 Year of fee payment: 3 |