JP3857381B2

JP3857381B2 - 編集装置及びデータ記録媒体

Info

Publication number: JP3857381B2
Application number: JP09227897A
Authority: JP
Inventors: マークグリーンウッドジョナサン; ジョンマグラースマーク
Original assignee: Sony United Kingdom Ltd
Current assignee: Sony Europe BV United Kingdom Branch
Priority date: 1996-04-12
Filing date: 1997-04-10
Publication date: 2006-12-13
Anticipated expiration: 2017-04-10
Also published as: EP0801391B1; GB9607693D0; DE69718231D1; GB2312079A; EP0801391A2; DE69718231T2; KR970071245A; US20030077066A1; EP0801391A3; US6640044B2; GB2312079B; JPH1064247A; KR100472155B1

Description

【０００１】
【発明の属する技術分野】
本発明は、記録媒体上に記録されたソース・マテリアルの編集装置及びそのためのデータ記録媒体に関する。
【０００２】
【従来の技術】
例えば、複数の「生」ソース・ビデオ・シーケンスに編集操作を加えて、それらシーケンスから最終的な１本の番組用のビデオを制作したり、或いは番組用のビデオの一部を制作したりするために、ビデオ編集コントローラが用いられている。また例えば、短いニュース記事であっても、そのニュース記事の様々な側面を示すために、複数のビデオ・シーケンスから抜粋した小さな抜粋部分を幾つもつなぎ合わせてあるのが普通であり、ここで使用する複数のビデオ・シーケンスには、新たに撮影したシーケンスもあれば、以前撮影してアーカイブ（保存記録）し保管しておいたシーケンスもある。この場合に、先ず、各シーケンスから必要とする部分、即ち「クリップ」を選出する必要があり、更に、選出した幾つもの部分を互いに連結させることにより、合成した１つの出力シーケンスを形成する必要がある。
【０００３】
最近では、コンピュータで構成した様々な非線形編集コントローラが利用可能になっている。この種の編集コントローラを用いることにより、ユーザは、コンピュータ画面上でソース・シーケンスを見ながら、必要シーケンスであるクリップの「イン・ポイント（始点）」及び「アウト・ポイント（終点）」を選定することができる。また、それらの選定は、コンピュータのキーボードまたはカーソル制御デバイス（例えばマウス、ジョイスティック、トラックボール等）を操作することで行うことができる。続いて、選出した複数のクリップの順序を定めることで、所望の出力シーケンスを形成することができる。
【０００４】
この種の、コンピュータで構成した編集システムに関しては、編集操作を実行する前に先ず、編集に必要な幾つものソース・シーケンスを、通常のテープ媒体から、そのコンピュータに接続したランダム・アクセス記録装置（例えばハード・ディスクや光磁気ディスク等）にロードするという方法が以前より提案されている。こうすることによって、ユーザは、テープ媒体を用いた場合に通常そうであるように待たされることなく、種々のビデオ・シーケンスを迅速に次々と見ることができる。テープ媒体を用いた場合に待たされるのは、別のテープへの交換や、同じテープ上の前後の部分へとぶためのシャトル動作に時間がかかるからである。
【０００５】
【発明が解決しようとする課題及び課題を解決するための手段】
本発明編集装置は、記録媒体上に記録されたビデオ・マテリアル及び／又はオーディオ・マテリアルのソース・マテリアルに編集操作を加えることにより、そのソース・マテリアルから選出した複数のソース・マテリアル・クリップより成る編集されたマテリアル・シーケンスを生成する編集装置において、編集操作を加えるソース・マテリアルのデータを包含しているこの前記記録媒体上の複数のソース・ファイルを選定する手段及び各々の編集されたマテリアル・シーケンスに対応して１つずつ設けられる仮想ファイルを前記記録媒体上に記録する手段を備え、各仮想ファイルはアドレス情報を包含しており、このアドレス情報は、その仮想ファイルに対応した編集されたマテリアル・シーケンスを構成する１つないし複数のソース・マテリアル・クリップを得る前記複数のソース・ファイル内の、前記記録媒体上における記録位置のシーケンスを定める情報であり、前記各仮想ファイルはファイル・ヘッダを包含しており、このファイル・ヘッダは、前記編集テーブル内の複数のエントリを順序付けて示した１つのリストを定めているものである。
【０００６】
本発明は以下の認識に基づいたものであり、その認識とは、例えばディスク・ドライブ等のランダム・アクセス記録媒体を用いた編集システムにおいて、多数のソース・マテリアルのファイル（ソース・ファイル）から選出された幾つものマテリアル・クリップより成る編集されたシーケンスを再生する動作は、これまでは、複雑でしかもプロセッサの負荷の大きな動作であったということである。更に具体的に説明すると、この種の従来のシステムにおいては、各々のソース・ファイルをオープンし（しかも通常、そのファイルが必要になる前にオープンしておく必要がある）、そのソース・ファイルから然るべきマテリアル・クリップを読み出し、そして、そのソース・ファイルをクローズするという動作を次々と行わねばならなかった。このような連続的順次動作は、「時刻表」的動作と呼ばれており、通常の再生速度で順方向に再生を行う分には良好に動作する。しかしながらこの方式の動作は、例えば逆方向再生、ジョグ再生、それにシャトル再生等の、あまり普通でない再生動作には不適当であったし、更に、編集されたシーケンスの中の任意の点から再生を開始するにも不適当であった。
【０００７】
本発明は、媒体上に記録するデータの構成を、編集された出力シーケンスを取り出すのに適したデータ構成とする新規な方式を提供するものであり、そのために、以下の説明において出力ファイルまたは「仮想」ファイルと呼ぶファイルによって出力シーケンスを表すようにする。この仮想ファイルは記録装置上に記録されるファイルであるが、固有のマテリアル・データを持たず、その代わりに一連の複数のポインタから成るポインタ・シーケンスを包含しており、それらポインタは、記録されているデータの「実」ファイル（即ちソース・ファイル）に関する部分を指し示している。
【０００８】
この仮想ファイルを再生するには、そのポインタ・シーケンスに含まれているポインタをたどりつつ、ディスク媒体上の該当する部分に含まれている必要なデータにアクセスして行く。また、少なくとも本発明の実施態様においては、これを行うために、実ファイルのフラグメンテーション（断片化）に対処するための技法と同様の技法を用いている。このようして行う仮想ファイルの再生は、先に説明した「時刻表」的動作とは異なり、順方向又は逆方向のいずれの方向にも容易に再生でき、また、仮想ファイル内の任意の始点から再生を開始することができる。
【０００９】
本発明データ記録媒体は、ビデオ・マテリアル及び／又はオーディオ・マテリアルのソース・マテリアルが記録され、その記録されたソース・マテリアルに編集操作が加えられることで、そのソース・マテリアルから選出されたソース・マテリアル・クリップより成る編集されたマテリアル・シーケンスが生成されるようにしたデータ記録媒体において、編集操作を加えるソース・マテリアルのデータを包含している複数のソース・ファイル及び各々の編集されたマテリアル・シーケンスに対応して１つずつ設けられた仮想ファイルが記録されており、各仮想ファイルはアドレス情報を包含しており、このアドレス情報は、その仮想ファイルに対応した編集されたマテリアル・シーケンスを構成する１つないし複数のソース・マテリアル・クリップを得る前記複数のソース・ファイル内の、記録媒体上における記録位置のシーケンスを定めた情報であり、前記各仮想ファイルはファイル・ヘッダを包含しており、このファイル・ヘッダは、前記編集テーブル内の複数のエントリを順序付けて示した１つのリストを定めているものである。
【００１０】
【発明の実施の形態】
以下に添付図面を参照しつつ、本発明をその具体的な実施の形態に即して説明して行く。なお、添付図面中、同一ないし対応する要素には同一の参照番号を付した。
図１は、ディジタル・ビデオ編集システム及びそれに付随するビデオ記録装置のブロック図である。
図示のビデオ編集システムはパーソナル・コンピュータ（ＰＣ）１００を含んでおり、このＰＣ１００は、カーソル制御デバイス１１０（マウス等）と、ディスプレイ画面メモリ１２０と、ディスプレイ画面１３０とを有する。本例ではＰＣ１００として、ノートブック型（携帯型）コンピュータであるＩＢＭ社の「シンクパッド」を使用しているため、ＰＣ１００、カーソル制御デバイス１１０、ディスプレイ画面メモリ１２０、及びディスプレイ画面（ＬＣＤ画面）の全てが、単一の携帯型装置として一体化されている（なお、ＩＢＭ社のシンクパッドのカーソル制御デバイス１１０はジョイスティック型の制御デバイスである）。従って、ＰＣとその構成要素との間のデータ通信は、ＰＣの内部バスを介して行われる。
【００１１】
ＰＣ１００は、ＳＣＳＩバスを介してビデオ記録コントローラ１４０との間で通信を行い、更にビデオ記録コントローラ１４０は同じくＳＣＳＩバスを介して光磁気ディスク１５０との間で通信を行う。
【００１２】
本例では、ビデオ記録コントローラ１４０と光磁気ディスク１５０とは、使用時にノートブック型コンピュータをその上に載せて結合する「ドッキングステーション」として製作されている。
【００１３】
このビデオ編集システムは、オフライン方式の非線形編集コントローラとして動作するようにしたものであり、入力してくる放送品質のオーディオ信号及びビデオ信号に対して非常に圧縮比の大きなデータ圧縮処理を施し（この結果、放送用の基準をかなり下回る品質レベルになる）、それを光磁気ディスク１５０に記録する。こうしてソース・ビデオのうちの１つまたは複数のセクションを光磁気ディスク１５０に記録したならば、この編集コントローラを操作するオペレータは、その記録したセクションに処理操作を加えることで、エディット・デシジョン・リスト（ＥＤＬ）を作成することができる。このＥＤＬは、編集されたビデオ出力シーケンスを構成する連続した複数の部分の各々を構成するソース・マテリアル（素材）の「イン・ポイント（始点）」及び「アウト・ポイント（終点）」を定めるビデオのタイムコードのリストである。ただし、光磁気ディスク１５０に記録されるビデオ信号は、放送用の基準をかなり下回る品質レベルのものであるため、このＥＤＬは、それをオリジナルのビデオ・データ（即ち、最初にビデオ記録コントローラ１４０へ供給されたデータ）に適用することで、放送用ないし配布用のビデオを制作することを意図したものである。
【００１４】
図２は、ビデオ記録コントローラ１４０及び光磁気ディスク１５０のブロック図である。
光磁気ディスク１５０は着脱可能なディスク媒体１６０を使用する自立型の装置であり、読み書きヘッド及びそれに付随する回路１７０と、プロセッサ１８０とを備えている。プロセッサ１８０は、ディスク媒体のフォーマッティング及びディスク媒体上でのデータ操作の作業のうちの非常に低レベルの部分を担当するものである。この種の製品の一例は、ソニー社の「ＨＳＤ−６５０型」光磁気ディスク・ドライブである。このソニー社の製品を用いた場合には、光磁気ディスク１５０は「論理ブロック・アドレス（ＬＢＡ）」を（外部の回路から）受け取る。１つのＬＢＡは、ディスク媒体上の多数の論理データ・ブロック（ＬＢ）のうちの１つを定めている。ディスク媒体１６０上の論理ブロックの位置設定及びフォーマッティングはプロセッサ１８０に委されているため、外部から光磁気ディスク１５０を見た限りでは、１つの大容量の（この場合は６５２メガバイト）記録媒体に見え、ＬＢＡにより、その大容量の記録媒体上の小さな記録ブロックに個別にアドレスすることができる。なお、光磁気ディスク１５０は、ＳＣＳＩリンクを介して、読み書き用バッファ及び制御回路１９０との間で通信を行うようにしている。
【００１５】
ＳＣＳＩインターフェース２００は、ノートブック型ＰＣ１００との間で通信を行うために備えられており、また、オーディオ／ビデオ（Ａ／Ｖ）圧縮／伸長回路２１０は、光磁気ディスク１５０に書き込むオーディオ・データ／ビデオ・データに圧縮処理を施し、光磁気ディスク１５０から読み出されたオーディオ・データ／ビデオ・データに伸長処理を施すために備えられている。Ａ／Ｖ圧縮／伸張回路２１０は、公知の画像内圧縮法を採用しており、光磁気ディスクに記録されているデータから個々の画像を再生する際に、他の圧縮画像を参照する必要がない。更に詳しく説明すると、入力ポート２２０へ供給されて入力してくる放送用品質の画像（画像データ）に対して、先ず最初に、水平方向と垂直方向との各々に関して４：１の間引き処理を施す。その間引き処理を施した画像に対して更に、公知のＪＰＥＧ圧縮法を用いて圧縮処理を施すことにより、１画像面あたり約５キロバイトの圧縮画像データを生成する。このように圧縮して記録した画像を光磁気ディスク１５０から読み出すときには、その読み出した圧縮画像に対してＪＰＥＧ伸長処理だけを施す。そのため、ＰＣ１００へ供給される画像は、フル・レートのビデオ画像と比べてはるかに小さなサイズ（４：１に間引かれたサイズ）になっている。しかし、これによって不都合が生じることはなく、なぜならば、こうしてＰＣ１００へ供給される画像は、エディット・デシジョンの位置をどこにするかを決めるためだけに用いられるからである。こうして決定されたエディット・デシジョンが、引き続いて（ＥＤＬを介して）オリジナルの（即ち、圧縮されていない）ビデオ信号に適用される。
【００１６】
光磁気ディスク１５０に記録するオーディオ及びビデオ・データをフォーマッティングする作業の一部を、読み書きバッファ及び制御回路１９０に関するプログラム・ファームウェアに担当させることも可能であるが、本例では、事実上その作業の全てをＰＣ１００に担当させている。従って、ビデオ記録コントローラ１４０は、「能動」記録コントローラというよりはむしろ「非能動」記録コントローラとして動作するように設定してあり、即ち、このビデオ記録コントローラ１４０は、ＰＣ１００からの指示（この指示はＬＢアドレス信号の信号レベルの形で発せられる）に従って、光磁気ディスク１５０に対するデータの読み書きを行う。
【００１７】
光磁気ディスク１５０に記録されているビデオ・データの再生を開始するときには、ＰＣ１００が、再生すべき複数のＬＢをその順序に従って記したＬＢリストを、ビデオ記録コントローラ１４０へダウンロードする。すると、そのリスト中のそれらＬＢに記録されているビデオ・フレームが、そのリスト中の順序に従って再生され、伸長処理を施されてＰＣ１００へ返され、ディスプレイされる。このことから明らかなように、ＰＣ１００は、ビデオ記録コントローラ１４０へ送出するＬＢリストを作成するために、光磁気ディスク１５０のヘッダ領域に記録されているデータにしばしばアクセスする必要がある。
【００１８】
そのために、光磁気ディスク１５０にデータをどのように書き込んでおくかということが、本例の動作上の多くの特徴を成しているので、これより、光磁気ディスクのデータ構成について説明する。
【００１９】
先ず手始めに、図３のＡ及びＢは、５２５ライン方式（走査線数が５２５本のテレビジョン方式）のビデオ信号の場合及び６２５ライン方式のビデオ信号の場合における、ディスク媒体１６０上のデータ構成を模式的に示したものである。
【００２０】
それら２つの場合のいずれにおいても、基本的に、ディスク媒体上の領域が、次のように分割されている。即ち、先頭にヘッダ領域があり、続いてビデオ・データ領域があり、その次にオーディオ・データ領域があり、更にその次に、僅かの使用しないセクタ（論理ブロック）がある。１つのセクタに対応するデータ量は２０４８バイトである。ビデオ及びオーディオ・データに対して施す圧縮処理は、２種類のライン方式の各々について調節され、１枚のディスク媒体に約４４〜４５分のビデオ素材及びオーディオ素材を収められるようにしている。
【００２１】
以下に、図４〜図１５を参照して、ヘッダ領域、ビデオ・データ領域、及びオーディオ・データ領域について詳細に説明する。重要なことなのでここで再度述べておくが、それら３つの領域のフォーマッティングは、論理ブロック・アドレス（ＬＢＡ）に関して行われるものである。非常に低レベルのフォーマッティングはディスク・ドライブが自ら担当するのに対して、このＬＢレベルのフォーマッティングは、ソフトウェア制御の下にＰＣ１００が担当するものである。
【００２２】
図４は、１枚のディスク媒体のヘッダ領域の内容を模式的に示した図である。このディスク・ヘッダ領域は、長さが２５６セクタ（論理ブロック２５６個）であり、以下に列挙する部分から構成されている。
ディスク・ヘッダ：論理ブロック１個
実ファイル・マスク：論理ブロック１個
実ファイル・ネーム・テーブル：論理ブロック２個
実ファイル・ヘッダ・テーブル：論理ブロック１６個
仮想ファイル・マスク：論理ブロック１個
仮想ファイル・ネーム・テーブル：論理ブロック２個
仮想ファイル・ヘッダ・テーブル：論理ブロック１６個
ルート・マップ：論理ブロック６４個
ビデオ編集テーブル・マスク：論理ブロック１個
ビデオ編集テーブル：論理ブロック６４個
オーディオ編集テーブル・マスク：論理ブロック１個
オーディオ編集テーブル：論理ブロック６４個
これら部分の各々について、以下に更に詳細に説明する。
【００２３】
図５はディスク・ヘッダの部分のファイルを更に詳細に示した図である。このディスク・ヘッダ・ファイルの構成要素の殆どは、説明するまでもなく、その名称を見ただけで内容が明らかなものである。ディスク・ヘッダ・ファイルは、ディスク媒体を（ＰＣの制御の下に）初めてフォーマットする際に書き込まれるファイルであり、このファイルに含まれているのは、使用しているソフトウェアの識別データ、ボリューム・ラベル、そのディスク媒体上の実ファイル及び「仮想ファイル」の個数を表すデータ（実ファイル及び仮想ファイルについては後に詳述する）、それにルート・マップを定めるデータ（ルート・マップについても後に詳述する）であり、またその最後に、そのディスク媒体上に記録されているビデオ・データのライン方式（走査線が何本のテレビジョン方式か）を示すための１ビットを割り当ててある。本例では、１枚のディスク媒体１６０上には、５２５ライン方式のビデオ・データか、６２５ライン方式のビデオ・データかの、いずれか一方しか記録させないようにしており、そのため同じ１枚のディスク媒体上に異なったライン方式のビデオ・データが混在することはない。
【００２４】
１枚のディスク媒体上に記録し得るデータ・ファイルの最大個数は、ファイル・ネーム・テーブル及びファイル・ヘッダ・テーブルの夫々にどれほどのスペースを割り当てるかによって予め決められる。本例の場合、記録可能なデータ・ファイルの最大個数は、実ファイルが２５５個、それに仮想ファイルが２５５個である。
【００２５】
「実」ファイルは、入力ポート２２０からのオーディオ／ビデオ・データを、ディスク媒体１６０上に記録することによって作成されるファイルである。１個の実ファイルは、ファイル・ネームと、ファイル・ヘッダと、ディスク媒体１６０上にデータが記録されたデータ領域とで構成される。ディスク媒体１６０上に記録されたデータの位置は、ファイル・ヘッダによって（ＬＢＡで）定められる。一度作成された実ファイルは、編集操作によって変更を受けることはなく、作成されたときと同じ形のまま維持されるか、さもなくばディスク上から削除されるかのいずれかである。
【００２６】
これに対して「仮想」ファイルは、編集作業を実行することによって作成されるファイルである。１個の仮想ファイルは、ファイル・ネームと、１つのビデオ編集テーブルを指し示すファイル・ヘッダとだけで構成される。仮想ファイルはディスク媒体上に記録されている特定のデータに対して持続的な関連性を持つものではなく、そのディスク媒体上に記録されている１つないし複数の実ファイルに含まれているデータのセクションを指し示す一連のポインタを間接的に与えるものである。
【００２７】
この構成によれば、実際にディスク媒体上のスペースを大幅に節約することができ、これが可能であるのは、編集作業時にデータを記録し直す必要がないからである。一例として、あるディスク媒体上に３個の実ファイルが記録されており、オペレータが、それら３個の実ファイルの各々から例えば１０秒ずつの部分を取り出してつなぎ合わせたものをもって、編集されたビデオ出力シーケンスとしたいと考えたものとする。この場合、それら３個の実ファイルの夫々の部分を物理的に新たな出力用ファイルへコピーする必要はない。即ち、そのようなコピーを行う代わりに、１つの仮想ファイルを作成して、その仮想ファイルが各実ファイル内の選択された部分を指し示すポインタを与えるようにするのである。しかも実際には、仮想ファイルのためのファイル・ヘッダ領域は前もって割り当てられているため、新たに仮想ファイルを作成するのにディスク媒体上のスペースを更に余計に取ることもない。
【００２８】
ヘッダ領域内には、実ファイルのためのファイル・ネーム・テーブルが１つ設けられると共に、それとは別に、仮想ファイルのための同様のファイル・ネーム・テーブルがもう１つ設けられている。それら２つのファイル・ネーム・テーブルは同一形式であり、その具体例を図６に模式的に示した。
【００２９】
これら２つのファイル・ネーム・テーブルの各々は、ファイル・ネームのリスト（１つのファイル・ネームは最大１６文字までである）から成り、そのリスト内における個々のファイル・ネームの位置が、実ファイル・ヘッダ・テーブルまたは仮想ファイル・ヘッダ・テーブル内の対応する位置を指し示すインデックス（即ちファイル番号）となる。従って図示例において、第１番ファイルとは、そのファイル・ネームが、ファイル・ネーム・テーブル内のバイト１７〜３２を占めているファイルである。ファイル・ヘッダ・テーブル内に記入されている当該ファイルについての更に詳細な情報にアドレスする際にも同じファイル番号が使用されるが、それについては後に詳述する。
【００３０】
図７は、実ファイル・ヘッダ・テーブルを模式的に示した図である。実ファイル・ヘッダ・テーブルには、ディスク媒体上に記録できる実ファイルの各々に対応して１つずつのレコード（即ちエントリ）が含まれている。この実ファイル・ヘッダ・テーブルの１つのエントリには、最初にファイル・ネームを転記した項目があり、次にその実ファイルの作成日及び作成時刻がある。次にくるのがその実ファイル内の先頭フレームのタイムコードであり、その次がその実ファイルに含まれるフレームの個数である。
【００３１】
実ファイル・ヘッダ・テーブルのエントリ内の次の３つの項目は、ディスク媒体上におけるその実ファイルのフラグメンテーション（断片化）に関するものである。フラグメンテーションとは、ある１つのファイルのデータが、ディスク媒体上にある連続していない２箇所以上の領域（ここでいう領域は、ＬＢＡで表される領域である）に亘って分割されている状態をいう。これらの項目については後に図９を参照して説明する。
【００３２】
更に続いてテキスト形式の注記のためのスペースとして６４バイトが割り当てられており、それに続く２つの項目は、その実ファイルからの先頭部画像と末尾部画像とを定めている。これら２つの画像は、編集操作時にＰＣのディスプレイ画面上に表示され、それによって、その実ファイルが如何なる性質のものであるかを示すと共に、その実ファイルを識別できるようにするものである。通常は、先頭部画像にはその実ファイル中の文字通り先頭の画像を使用し、末尾部画像にはその実ファイル中の文字通り最後の画像を用いればよい。ただし、オペレータが、その実ファイル中のその他の画像をもって先頭部画像及び末尾部画像としたいのであれば、そのように設定することも可能にしてある。
【００３３】
続く次の１バイトは、考えられる４本のオーディオ・チャネルのうちのどれをその実ファイルに使用するのかを示すために割り当てられているものである。このレコード（エントリ）内の残りのスペースは使用されていない。
【００３４】
この実ファイル・ヘッダ・テーブルに関しては、更にルート・マップの説明もせねばならないが（後に図９を参照して説明する）、ここで特に次の点を再度強調しておく。それは、実ファイル・ヘッダ・テーブルは、ファイル・ネームとの間に持続的な（少なくともその実ファイルが削除されるまでは持続的な）対応関係を有する実データの、ディスク媒体上における位置を定めるものだということである。
【００３５】
図８は、仮想ファイル・ヘッダ・テーブルを模式的に示した図である。仮想ファイル・ヘッダ・テーブルの１つのエントリ内の項目のうちの幾つかは、実ファイル・ヘッダ・テーブルの１つのエントリ内の対応する項目と完全に同一であり、それらについては重複を避けるために説明を省略する。
【００３６】
仮想ファイル・ヘッダ・テーブルと実ファイル・ヘッダ・テーブルとの主たる相違は、仮想ファイル・ヘッダ・テーブルが、ビデオ編集テーブル・インデックスの中の１以上のエントリ及びオーディオ編集テーブル・インデックスの中の１以上のエントリによって、その仮想ファイルに関連したデータを定めていることである（なお、ダブルチェックのために、仮想ファイル・ヘッダ・テーブルのエントリには、予想されるフレームの総数を示す項目を含めてあり、また、編集された出力シーケンスのタイムコードをタイム・プリセット・ワードによって特定の値に設定できるようにしてある）。
【００３７】
ビデオ編集テーブル・インデックス及びオーディオ編集テーブル・インデックスについては後に詳述することとし、ここでは、それらインデックスの概要だけを簡単に述べておく。それらインデックスの各々は、その編集テーブル内の幾つかのエントリが連結されて構成された１つの連結リストであり、各エントリは夫々、１個の実ファイルの１つの部分を表している。それらの連結は、オペレータが、ＰＣ１００に記憶させたＥＤＬエントリをモニタするために、編集された出力シーケンスのプレビューを行うＰＣコマンドを発したときに作成される。ビデオ編集テーブル（ＶＥＴ）の適正なエントリに対応した仮想ファイルも、この時点で（即ち、出力プレビュー・コマンドが発せられた時点で）作成される。
【００３８】
即ち、仮想ファイル・ヘッダ・テーブル内の１つのエントリが、ＶＥＴ内の先頭のエントリを指し示すと共に、そのＶＥＴ内のエントリの総数を定めることによって、１以上の実ファイルにおける複数の部分が連続したシーケンスを定める、特定の長さの連結リストが形成される。
【００３９】
仮想ファイルは、実ファイルの場合と同様にオープンして再生することができる。即ち、ある仮想ファイルを再生するには、ディスク媒体１６０からその仮想ファイルに対応した複数のＶＥＴエントリのリストを読み出し、そして、それら部分をディスク媒体１６０から正しい順序で再生できるように導出されたルート・マップのそれらＶＥＴエントリに対応した部分を読み出す。
【００４０】
図９は、ディスク媒体の「ルート・マップ」を模式的に示した図である。
ルート・マップ（ＲＭ）は、インデックスによって互いにつなぎ合されて幾つかの連結リストが形成される、ディスク媒体上に記録されたレコードのテーブルである。それら連結リストの各々が、そのディスク媒体の表面の複数の物理的位置のパス即ち「ルート」を記述している。ＲＭ内の複数のレコードの各々は、ディスク媒体上の連続する複数のセクタのブロックである「フラグメント」を記述しており、またそれと共に、後続のフラグメントを連結順に記述している別のルート・マップ・レコードのインデックスを含んでいる。１つのルートの記述は、先ず、ディスク媒体上の１つのフラグメントを記述することから始まり、その次に、ルート・マップ内の一連のルート・マップ・インデックスが続き、「ネクスト・レコード」インデックス値が「０」に設定されたレコード（エントリ）で終わる。即ち、「ネクスト・レコード」インデックス値が「０」であることは、そのレコードがそのルートの終点であることを表している（なお、これを可能にするために、ルート・マップ内の先頭のレコード（本来はインデックス「０」で表される）は、使用しないようにしている）。
【００４１】
各実ファイルは、ルート・マップ内に、ディスク媒体上のどこにその実ファイルのデータが存在するのかを記述する１つのルートを有する。また、ルート・マップには、各実ファイルに対応した１つのルートに加えて、ディスク媒体上の空きスペースを記述した別のルート（空きスペース・ルート）が含まれている。この「空きスペース・ルート」の始点は、ディスク・ヘッダ領域内の「空きスペース始点」インデックスによって示されており（図５）、このインデックスは、ＲＭ内のある１つのエントリを指している。この「空きスペース・ルート」は常に、ディスク媒体上のスペースの現在割り当て状態を反映するように維持されている。
【００４２】
新たに１つのファイルを記録する際には、データ書き込み作業を前述の「空きスペース・ルート」に沿って行う。そのデータ書き込みが完了した時点で、ＲＭ内のインデックスの書き直しを行って、その「空きスペース・ルート」から新ファイルのために使用されたルートを削除する。その結果、「空きスペース始点」インデックスは「空きスペース・ルート」に沿う更に向こうの位置を指し示すようになり、新ファイルのために使用されたスペースはとばされる。また、その新ファイルのために作成されたファイル・ヘッダは、その新ファイルのデータを書き込んだ場所を記述したルートを指し示すポインタを含んでいる。こうして、空きスペースであった幾つかのフラグメントにデータが書き込まれるが、書き込みが行われたフラグメントのうち、最後のフラグメントは、通常、その一部分だけしか新ファイルによって消費されていない。この場合には、部分的にしか消費されていないそのフラグメントの残りの部分を記述した新たなエントリをＲＭ内に作成し、その作成したエントリを「空きスペース・ルート」の先頭に連結させる。
【００４３】
一方、幾つかの実ファイルを削除したときには、削除した実ファイルがそれまで占めていた夫々のルートを「空きスペース・ルート」の末尾に連結させることによって、それらルートを「空きスペース・ルート」に再編入させる。ここで、それらルートを「空きスペース・ルート」に連結させる位置が「空きスペース・ルート」の末尾であるという点は重要である。なぜならば、そうすることで、ディスク媒体が満杯に近くなるまでフラグメンテーションを発生させずに済むからである。また、ＲＭ内の複数のルートの各々について、そのルートを構成している複数のフラグメントのうちの、最後のフラグメントを指し示すポインタを維持することによって、各連結最後の項目（エントリ）にアクセスする際に、その連結を表す連結リストをわざわざサーチすることなく、それらの項目に迅速にアクセスできるようにしている。
【００４４】
また、ＲＭ内のエントリ（レコード）の総数のカウントを、ディスク・ヘッダ領域内に含まれている変数「ディスク上のフラグメント数」で示し（図５）、この値を更新維持するようにしている。このカウントは、ディスク媒体のフラグメンテーションの程度を表す指標にもなる。
【００４５】
図１０は、ビデオ編集テーブル（ＶＥＴ）を模式的に示した図である。
ＶＥＴは、１つまたは複数のビデオ編集操作を表したテーブルであり、個々のビデオ編集操作を表すのに、その編集操作に必要と判断された部分（編集部分）を含んでいる実ファイルを特定するのに必要な情報と、その編集部分の始点及び長さを特定するのに必要な情報とで表すようにしている。このテーブルの各エントリ（ＶＥＴエントリ）は、それらの情報に加えて更に、仮想ファイル内でそのＶＥＴエントリの後に続くネクストＶＥＴエントリを指し示すインデックスをも含んでいる。
【００４６】
またこのＶＥＴにおいては、１つの編集部分の始点を表すのに、その編集部分を含んでいる実ファイルの始点からのオフセットを用いるのではなく、その編集部分の始点を含んでいるフラグメント（即ちルート・マップ・エントリ）の始点からのオフセットを用いている。従って、そのフラグメントの始点からのオフセットと、フレーム個数で表したその編集部分の長さとが定められている。このようにして編集部分を表すようにしたため、実ファイル・ヘッダ・テーブルを参照した上でルート・マップをたどるという面倒な手順を取ることなく、編集部分の始点を発見することができる。
【００４７】
図１１は、オーディオ編集テーブル（ＡＥＴ）を模式的に示した図である。
ＡＥＴは、以上に説明したＶＥＴと基本的に同一のテーブルであるが、ＡＥＴは、出力素材における左右の出力チャネルへのオーディオ・チャネルの割り当てを定めたバイトを含んでいる点が異なっている。この割り当てバイト内に適切なビットを設定することで、４本のオーディオチャネル（第１チャネル〜第４チャネル）の各々を個別に、左出力チャネル、右出力チャネル、或いは両出力チャネルに割り当てることができ、また、いずれの出力チャネルにも割り当てないようにすることもできる。
【００４８】
図１２は、「使用状態」マスクがどのように用いられるかを説明した図である。
ここで再び図４を参照して説明すると、ヘッダ領域内の複数の部分のうちマスクが割り当てられている部分は、２番目、５番目、９番目、及び１１番目の部分であり、それら部分に割り当てられているマスクは、夫々、「実ファイル・マスク」、「仮想ファイル・マスク」、「ＶＥＴマスク」、及び「ＡＥＴマスク」と名付けられている。
【００４９】
それらマスクの各々は、複数のデータ・ビットから成る小さなサイズのデータ・アレイである。１つのマスク内の各データビットは、そのマスクに対応したテーブル内の夫々のエントリが、現在使用されているか否かを表す。例えば、実ファイル・マスクでは、その中の各ビットが実ファイル・ネーム・テーブル内の１つ１つのエントリに対応しており、また、ＶＥＴマスクでは、その中の各ビットがビデオ編集テーブル（ＶＥＴ）内の１つ１つのエントリに対応しており、その他のマスクも同様である。
【００５０】
既述のごとく、ネーム・テーブル、ヘッダ・テーブル、及び編集テーブルはいずれも、その中のエントリが、特に決められた順番に従うことなく使用されたり、また（エントリ削除によって）空いたりする。それらテーブルに対応した夫々の「使用状態」マスクは、対応するテーブルに新たに１つのエントリを加える必要が生じたとき（例えば、新たに１個の実ファイルを記録しようとするとき）に、そのテーブル内のエントリのうちのどのエントリが空きエントリになっているのかを、ＰＣに迅速に知らせるために用いられている。
【００５１】
即ち、あるテーブルに新たに１つのエントリを加える必要が生じたときには、使用状態マスク内の「０」に設定されている最初のビット（この設定は「非使用」を表す）を特定すれば、その使用状態マスクの始点からのそのビットの位置が、その使用状態マスクに対応したテーブル内の空きエントリを指し示すインデックスとなる。そして、そのテーブルのエントリを使用するときに、使用状態マスク内のその対応するビットの論理状態を「１」に設定する（この設定は「使用」を表す）。
【００５２】
以上の技法によれば、様々なテーブルの中を空きエントリを求めてサーチする時間を節約することができ、また、その空きエントリをサーチする際にそれらテーブル（それらテーブルが非常に長大なものである場合がある）からの読み出しを行うために何度もディスクにアクセスせずに済む。
【００５３】
図１３は、オーディオ・データ・パケットを模式的に示した図であり、このパケットは、対応するビデオ信号の１フレームに関するオーディオ・データを含んでいる。
【００５４】
このオーディオ・データ・パケットは、ヘッダと、対応するビデオ・フレームのタイムコードと、必要なオーディオ・サンプルとを含んでいる。（同じライン方式の）オーディオ・データ・パケットは、全て同じ長さ（一定長）であるため、オーディオ・データ領域内における、ある１つのオーディオ・データ・パケットから別の１つのオーディオ・データ・パケットまでのオフセットが、オーディオ・データ・パケット何個分に相当するかが分かれば、それらオーディオ・データ・パケットの一方に対する他方の相対位置を知ることができる。
【００５５】
図１４は、図１３と同様のビデオ・データ・パケットを模式的に示した図である。このビデオ・データ・パケットも、ヘッダと、１個のビデオ・フレームのタイムコードと、その１ビデオ・フレームのビデオ・データとを含んでいる。ここでも、１枚のディスク媒体上に記録される、１つのビデオ・ライン方式に対応しているビデオ・データ・パケットは、全て同じ長さ（一定長）である。
【００５６】
最後の図１５は、実ファイルを表すのにルート・マップをどのように使用するか、また、仮想ファイルを表すのにビデオ編集テーブル（ＶＥＴ）をどのように使用するかを説明した模式図である。
【００５７】
図１５は、ディスク媒体の表面を模式的に示しており、このディスク媒体の表面には複数個の論理ブロックが、図中の左上から右下への順序で並んで存在している。図中に細長い長方形で示した４つのセクション３００、３１０、３２０、及び３３０は、ディスク媒体上のフラグメントを表したものであり、ここでいうフラグメントとは、ディスク媒体上の１つの連続したデータ・セクションのことである（実ファイルのフラグメンテーション（断片化）は、先に作成したファイルを削除した後に、新たなファイルを作成した場合に発生しうる）。
【００５８】
フラグメント３２０及び３３０は、その一部分だけにハッチングを施してあるが、このことについては後に詳述する。
【００５９】
フラグメント３００、３１０、３２０、３３０は、その各々がルート・マップ内の夫々１つのエントリに対応している。ルート・マップ内の１つのエントリは、ただ１つの実ファイルにしか関与することができない。もし、ある１つの実ファイルを作成する際にあるフラグメントの一部だけが使用されたとしても、そのフラグメントの残りの部分はより小さな別のフラグメントとして表されるようになる。
【００６０】
フラグメント３００、３１０、３２０、３３０は、ルート・マップを構成しているリストが連結されていることによって、互いに連係している。即ち、ルート・マップ内の各エントリが、ルート・マップ内のネクスト・レコード（ネクスト・エントリ）を指し示している。従って、ルート・マップ内のエントリのうち、フラグメント３００に対応したエントリは、フラグメント３１０に対応したエントリを指し示すポインタを含んでおり、このフラグメント３１０に対応したエントリは、フラグメント３２０に対応したエントリを指し示すポインタを含んでおり、以下同様である。フラグメント３００〜３３０に対応した夫々のエントリは、ルート・マップ内においてどんな順序であっても構わず、特に、連続して並んでいる必要はない。
【００６１】
図１５に示した４つのフラグメント３００〜３３０は、１個の実ファイルに対応したものであり、実ファイル・ヘッダ・テーブルのエントリに含まれている「ルート・マップ内の先頭エントリ」という名の項目（図７参照）が、フラグメント３００に対応したエントリを指している。
【００６２】
従って、この実ファイルをオープンして再生するとき、そのファイル・ヘッダが光磁気ディスク１５０からＰＣ１００へロードされる。ＰＣ１００はそのロードされたファイル・ヘッダから、ＲＭ内の先頭エントリ（図１５の例ではフラグメント３００を指している）と、ＲＭ内のエントリ個数、即ちフラグメント個数（図示例では４個である）と、ＲＭ内の最後のエントリ（図１５の例ではフラグメント３４０を指している）とを読み取る。
【００６３】
この実ファイルを再生するには、先ず最初にフラグメント３００からオーディオ・データ・フレーム及びビデオ・データ・フレームを読み出して再生する。フラグメント３００の末尾に達したならば、このフラグメント３００に対応したＲＭエントリ内のポインタに基づいて、ＲＭを形成している連結リスト内のネクストＲＭエントリ（このネクストＲＭエントリはフラグメント３１０に対応している）にアクセスする。そしてフラグメント３１０のデータを続けて再生する。更に続けてフラグメント３２０のデータを再生し、それに続けてフラグメント３３０のデータを再生する。
【００６４】
ここで、この実ファイルに含まれているフラグメントが以上の４個だけであるとするならば、フラグメント３３０の末尾まで再生した時点で、再生動作は停止する。なぜならば、この時点で (a)それまでに再生したフラグメントの個数が実ファイル・ヘッダ内に定められているフラグメント総数に等しくなり、また、 (b)「最終フラグメント」ポインタがフラグメント３３０を指し示しているからである。ただし、ルート・マップ内でフラグメント３３０に対応したエントリはなお、ネクスト・ルート・マップ・エントリを指し示しており、それによって１つの連続した連結リストが形成されている。
【００６５】
ビデオ編集テーブルの１つのエントリ（１つのＶＥＴエントリ）は、この実ファイル内の一部分、即ちハッチングを施した部分３４０を表している。この場合、そのＶＥＴエントリには、フラグメント３２０に対応したルート・マップ・エントリを指し示すインデックスと、この部分３４０のフラグメント３２０の始点からのオフセットを表すオフセット値（フレーム数で表される）と、この部分３４０の全長を表す長さ値（これもフレーム数で表される）とが含まれている。従って、この項目（即ち部分３４０）をＶＥＴに基づいて再生する際には、先ず、フラグメント３２０に対応したルート・マップ・エントリにアクセスし、このフラグメント３２０の始点から数えて然るべき数の（この数は変数「オフセット」値に等しい）フレームのところから再生動作を開始する。この再生動作は、ルート・マップに定められているフラグメントの連結リストに従って後続のフラグメント３３０へ続き、所要の長さ（フレーム数で表される）の再生が完了した時点で停止する。
【００６６】
ある１つの仮想ファイルを再生するには、ディスク媒体１６０からその仮想ファイルに対応した一連のＶＥＴエントリを読み出す。それには先ず、その仮想ファイルのヘッダ（仮想ファイル・ヘッダ）をロードする。この仮想ファイル・ヘッダには、対応した一連のＶＥＴエントリのうちの先頭ＶＥＴエントリと、それらＶＥＴエントリの総数とが定められている。ＶＥＴは連結リストであって、その中の各エントリがただ１つのネクスト・エントリを指し示しているため、１つの仮想ファイルに対応した一連のＶＥＴエントリを適切に取り出すことができる。そして、ＰＣ１００が（上で説明したようにして）その仮想ファイルの各ＶＥＴエントリに夫々が対応した、一連のルート・マップ・エントリと一連のオフセットとを取り出して、ビデオ記録コントローラ１４０へダウンロードすることにより、ディスク媒体１６０からの再生動作が開始する。
【００６７】
更にオーディオ・データについても、ＡＥＴに基づいて以上と同様の処理を行う。
従って、ビデオ記録コントローラ１４０に関する限り、再生するファイルが実ファイルと仮想ファイルとのいずれであるかにかかわらず、単に、ディスク媒体１６０上の再生すべきＬＢ（論理ブロック）を順序に従って記したリストを受け取り、それに従って再生を行うだけである。
【００６８】
【発明の効果】
以上のように、編集された出力シーケンスを表すのに、ディスク上の複数の実データ領域を連結させて指し示す仮想ファイルの形で表すようにしたため、再生を順方向にも逆方向にも行え、また様々な再生速度で行うことができる。というのは、１つの編集されたの出力シーケンスの全体を単一のファイル、即ち、複数の記録領域を連結させた単一のシーケンスで表すようにしたからである。従って、編集された出力シーケンスを見るために幾つもの実ファイルを特定の順序で次々とオープンしたりクローズしたりせずに済むのである。
【００６９】
また、仮想ファイル及びＶＥＴエントリは、ディスク媒体１６０上に記録されるため、編集作業が完了した時点でディスク媒体１６０上に保持されている。従って、編集作業が完了した後にそのディスク媒体１６０を使用する際には、編集コントローラで仮想ファイルをオープンして再生することができる。
【００７０】
また、ルート・マップを用いることによって、以上に説明したものとは異なったタイプの「ダミー」ファイルである「ＡＬＬ」というファイル・ネームを持つファイルを作成することができる。このファイルをオープンして再生するときには、ＰＣ１００は、ビデオ記録コントローラ１４０に対して単に、ディスク媒体１６０上に記録されている全てのビデオ・データをルート・マップによって指定されている順序で再生するように命令する。これを利用することで、オペレータはディスク媒体１６０の全ての内容を極めて容易に見ることができる。
【図面の簡単な説明】
【図１】ディジタル・ビデオ編集システムのブロック図である。
【図２】ビデオ記録コントローラのブロック図である。
【図３】夫々５２５ライン方式のビデオと６２５ライン方式のビデオとに対応した、ディスク媒体上のデータ構成を模式的に示した図である。
【図４】ディスク・ヘッダ領域の内容を模式的に示した表図である。
【図５】ディスク・ヘッダ・ファイルの内容を模式的に示した表図である。
【図６】ファイル・ネーム・テーブルを模式的に示した図である。
【図７】実ファイル・ヘッダ・テーブルを模式的に示した図である。
【図８】仮想ファイル・ヘッダ・テーブルを模式的に示した図である。
【図９】ディスク媒体のルート・マップを模式的に示した図である。
【図１０】ビデオ編集テーブルを模式的に示した図である。
【図１１】オーディオ編集テーブルを模式的に示した図である。
【図１２】Ａ及びＢは使用状態マスクの機能を説明した模式図である。
【図１３】オーディオ・データ・パケットを模式的に示した図である。
【図１４】ビデオ・データ・パケットを模式的に示した図である。
【図１５】実ファイルを及び仮想ファイルを表すのにルート・マップ及びビデオ編集テーブルをどのように用いるかを示した模式図である。
【符号の説明】
１００パーソナル・コンピュータ（ＰＣ）
１４０ビデオ記録コントローラ
１５０光磁気ディスク
１６０ディスク記録媒体
３００、３１０、３２０、３３０フラグメント

Claims

記録媒体上に記録されたビデオ・マテリアル及び／又はオーディオ・マテリアルのソース・マテリアルに編集操作を加えることにより、そのソース・マテリアルから選出した複数のソース・マテリアル・クリップより成る編集されたマテリアル・シーケンスを生成する編集装置において、
編集操作を加えるソース・マテリアルのデータを包含している前記記録媒体上の複数のソース・ファイルを選定する手段及び各々の編集されたマテリアル・シーケンスに対応して１つずつ設けられる仮想ファイルを前記記録媒体上に記録する手段を備え、
各仮想ファイルはアドレス情報を包含しており、このアドレス情報は、その仮想ファイルに対応した編集されたマテリアル・シーケンスを構成する１つないし複数のソース・マテリアル・クリップを得る前記複数のソース・ファイル内の、前記記録媒体上における記録位置のシーケンスを定める情報であり、前記各仮想ファイルはファイル・ヘッダを包含しており、このファイル・ヘッダは、編集テーブル内の複数のエントリを順序付けて示した１つのリストを定めていることを特徴とする編集装置。
前記記録媒体はディスク記録媒体であることを特徴とする請求項１記載の編集装置。
前記記録媒体上にルーティング・テーブルを記録してあり、該ルーティング・テーブルが包含している複数のエントリが、前記複数のソース・ファイルを記録してある前記記録媒体上の夫々の記録位置を示した１つの連結リストを定めていることを特徴とする請求項１記載の編集装置。
前記複数のソース・ファイルの各々がソース・ファイル・ヘッダを包含しており、そのソース・ファイル・ヘッダが、前記ルーティング・テーブル内の１個のエントリまたは互いに連結された一連のエントリから成るエントリ・グループを定めており、そのエントリ・グループが、そのソース・ファイルから選出されたデータ部分が夫々に記録されている前記記録媒体上の夫々の記録位置を定めていることを特徴とする請求項３記載の編集装置。
前記編集テーブルの各エントリが、前記ルーティング・テーブル内の１個のエントリまたは互いに連結された一連のエントリから成るエントリ・グループを定めており、そのエントリ・グループが、ある１つのソース・ファイルから選出されたデータ部分が夫々に記録されている前記記録媒体上の夫々の記録位置を定めていることを特徴とする請求項３または４記載の編集装置。
ビデオ・マテリアル及び／又はオーディオ・マテリアルのソース・マテリアルが記録され、その記録されたソース・マテリアルに編集操作が加えられることで、そのソース・マテリアルから選出されたソース・マテリアル・クリップより成る編集されたマテリアル・シーケンスが生成されるようにしたデータ記録媒体において、
編集操作を加えるソース・マテリアルのデータを包含している複数のソース・ファイル及び各々の編集されたマテリアル・シーケンスに対応して１つずつ設けられた仮想ファイルが記録されており、
各仮想ファイルはアドレス情報を包含しており、このアドレス情報は、その仮想ファイルに対応した編集されたマテリアル・シーケンスを構成する１つないし複数のソース・マテリアル・クリップを得る前記複数のソース・ファイル内の、記録媒体上における記録位置のシーケンスを定めた情報であり、前記各仮想ファイルはファイル・ヘッダを包含しており、このファイル・ヘッダは、編集テーブル内の複数のエントリを順序付けて示した１つのリストを定めていることを特徴とするデータ記録媒体。