(57)【要約】データストリームの編集処理時間を短縮化することが可能な編集処理を提供する。  データ処理装置は、記録媒体の単位領域ごとにコンテンツデータの書き込みおよび読み出しを行う。単位領域にはコンテンツデータを格納した複数のパケットが記録されている。データ処理装置は、複数のパケットを読み出す再生部と、第（ｎ＋１）パケットから第（ｎ＋ｍ）パケット（ｎ、ｍ：１以上の整数）までに格納されたコンテンツデータを分割して、第１パケットから第（ｎ＋ｍ）パケットまでの複数のパケットに格納する制御部と、第１パケットから（ｎ＋ｍ）パケットを含む複数のパケットを単位領域に書き込む記録部とを備えている。
2006088100.tif 000002
【特許請求の範囲】
【請求項１】
記録媒体の単位領域ごとにコンテンツデータの書き込みおよび読み出しを行うデータ処理装置であって、前記単位領域には前記コンテンツデータを格納した複数のパケットが記録されており、
前記複数のパケットを読み出す再生部と、
第（ｎ＋１）パケットから第（ｎ＋ｍ）パケット（ｎ、ｍ：１以上の整数）までに格納されたコンテンツデータを分割して、第１パケットから前記第（ｎ＋ｍ）パケットまでの複数のパケットに格納する制御部と、
前記第１パケットから前記（ｎ＋ｍ）パケットを含む複数のパケットを前記単位領域に書き込む記録部と
を備えたデータ処理装置。
【請求項２】
前記制御部は、分割された前記コンテンツデータを、前記第１パケットから前記第（ｎ＋ｍ）パケットまでの各パケットに順次格納する、請求項１に記載のデータ処理装置。
【請求項３】
前記制御部は、分割された前記コンテンツデータを、前記第１パケットの次の第２パケットから順次格納する、請求項１に記載のデータ処理装置。
【請求項４】
前記第（ｎ＋１）パケットが、前記データストリームの再生を管理するための管理情報を格納したパケットであるときにおいて、前記制御部は、前記管理情報を前記第１パケットに格納する、請求項３に記載のデータ処理装置。
【請求項５】
各パケットのパケット長は所定長に固定されており、
前記制御部は、前記コンテンツデータとともに、前記コンテンツデータとは異なるパディングデータを前記少なくとも１つのパケットに格納することにより、前記少なくとも１つのパケットのパケット長を前記所定長に調整する、請求項１に記載のデータ処理装置。
【請求項６】
前記制御部は、分割された前記コンテンツデータを、前記第１パケットから前記第（ｎ＋ｍ）パケットまでの２以上のパケットに格納する、請求項５に記載のデータ処理装置。
【請求項７】
前記制御部は、前記パディングデータを含まないパケットと、前記パディングデータを含むパケットとをそれぞれ１以上生成する、請求項６に記載のデータ処理装置。
【請求項８】
各パケットには、前記パケットの処理時刻を示す時刻情報が格納されており、
前記制御部は、前記第（ｎ＋１）パケットから前記第（ｎ＋ｍ）パケットまでのパケットのうち、前記コンテンツデータを最初に格納していた第ｐパケット（ｐ：ｎ＋１≦ｐ≦ｎ＋ｍを満たす整数）の時刻情報を取得し、前記時刻情報を、分割された前記コンテンツデータが最初に格納される第ｑパケット（ｑ：１≦ｑ≦ｐ−１を満たす整数）の処理時刻を示す時刻情報に変更して前記第ｑパケットに格納する、請求項１に記載のデータ処理装置。
【請求項９】
各パケットのパケット長は所定長に固定されており、
前記制御部は、前記第ｐパケットと前記第ｑパケットとの間のパケット数、および、前記データストリームのデータレートに基づいて、前記時刻情報を変更する、請求項８に記載のデータ処理装置。
【請求項１０】
各パケットには、前記データストリームのデータレートを示すレート情報が格納されており、
前記制御部は、前記第ｐパケット内のレート情報に基づいて前記時刻情報を変更する、請求項９に記載のデータ処理装置。
【請求項１１】
前記制御部は、前記レート情報に基づいて特定される１パケットあたりの転送時間および前記パケット数に基づいて、前記時刻情報を変更する、請求項１１に記載のデータ処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】  本発明は、メディアに記録されたコンテンツを編集する技術に関する。
【背景技術】
【０００２】  近年、ＤＶＤ等の光ディスク、ハードディスク等の磁気ディスク、半導体メモリ等のメディアにコンテンツのデジタルデータを書き込み、保存できるデジタル機器（光ディスクレコーダ、カムコーダ等）の普及が進んでいる。このようなコンテンツは、例えば、放送された番組やカムコーダ等によって撮影された映像および音声である。【０００３】  近年はＰＣにもコンテンツの記録、再生および編集機能が実装されており、ＰＣも上述のデジタル機器に含めることができる。ＰＣでは、文書データなどのデータを記録するために、従来からハードディスク、光ディスク、半導体メモリ等のメディアが利用されている。したがって、そのようなメディアでは、ＰＣと連携可能なデータ管理構造、例えばＦＡＴ（Ｆｉｌｅ  Ａｌｌｏｃａｔｉｏｎ  Ｔａｂｌｅ）を用いたファイルシステムが採用されている。現在多く利用されているＦＡＴ３２ファイルシステムでは、最大４ギガバイトのサイズを有するファイルを取り扱うことができ、また最大記録可能容量が２テラバイトのメディアを管理することができる。【０００４】  メディアの最大記録可能容量の増加に伴い、記録されるコンテンツの再生時間が長くなっている。光ディスク、ハードディスク、半導体メモリ等はいわゆるランダムアクセスが可能なメディアであるため、そのようなメディアに長時間のコンテンツのデータストリームを格納するときには、コンテンツの任意の位置から再生できると便利である。【０００５】  例えば特許文献１では、データストリームの先頭から一定の時間間隔ごとに、再生時刻とその時刻に再生されるＡＶデータの格納アドレスとの対応を規定したタイムマップ情報を生成している。ユーザ指定された開始時刻、終了時刻それぞれを、タイムマップ情報を参照して開始アドレス、終了アドレスに変換し、そのアドレスに格納されているデータを読み出すことにより、その時刻からコンテンツを再生することが可能になっている。【０００６】  近年のデジタル機器の中には、ランダムアクセスが可能なメディアに記録されたコンテンツの編集機能を有するものが存在する。この機能は、ユーザがコンテンツの好みの箇所を残すために利用されるだけでなく、不要部分を削除してメディアの空き領域を確保するために利用される。【０００７】  たとえばカムコーダを使用して屋外で録画を行っていたときに、想定以上に空き領域が無くなることがある。このとき、それまで録画したコンテンツのうちの不要部分を削除すると空き領域を確保することができる。これにより、新たなコンテンツをさらに続けてそのメディアに記録できる。【０００８】  データストリームの部分削除等の編集処理を行うときの留意点は、データストリームの構成単位と、メディアの記録単位との関係である。いま、データストリームが固定長のパケット単位で構成されており、メディアではパケット長とは異なるサイズの論理ブロック単位でデータが記録され、管理されるとする。データストリームの一部削除時に、論理ブロック単位内の一部のデータが削除の対象とされることがある。このときには、論理ブロック単位に収まるようにデータストリームのパケットの配置を調整する必要がある。【０００９】  たとえば特許文献２は、データスト���ームの部分削除時にデータストリームのパケットを論理ブロック単位に格納する一例を開示している。具体的には特許文献２では、データストリームの部分削除後に残されるパケットのデータ長を論理ブロックのブロック長に合致させるために、ダミーデータのみを含むパケット（ヌルパケット）が挿入されている。
【特許文献１】特開平１１−１５５１３０号公報
【特許文献２】国際公開第０１／００４８９３号パンフレット（図１３〜図１６）
【発明の開示】
【発明が解決しようとする課題】
【００１０】  上述のヌルパケットを挿入する方法は、ヌルパケットを検出し、解釈できるデジタル機器においては有効であるが、それができないデジタル機器においては不都合が生じる。具体的には、コンテンツの再生時に、そのデータストリームのヌルパケットを契機として再生される映像が乱れ、最悪の場合には再生が停止することがある。その理由は、機器がヌルパケットおよびそのダミーデータをビデオデータとして誤って解釈するためである。【００１１】  特に、近年のほとんどのデジタル機器が対応するＭＰＥＧ規格によれば、デジタル機器はグループ・オブ・ピクチャ（ＧＯＰ）と呼ばれる再生単位の先頭から順に映像を復号化する必要がある。しかし、再生単位の先頭にダミーデータが存在すると、もはやそれ以後のビデオデータの復号化ができなくなり、再生が停止する。【００１２】  このようなダミーデータの挿入を避けるため、削除されたデータに続くデータを順次繰り上げて、論理ブロック先頭から開始されるようにデータストリームを書き換える方法も考えられる。しかし、この方法では数ギガバイトにわたる書き換えが必要となることもあり非常に時間を要するため、適切ではない。書き換え時間は、データストリームの中間部分の削除（部分削除）処理よりも先頭部分を含む削除（前方削除）処理の方が長くなる。【００１３】  なお、映像の符号化データや音声の符号化データのデータサイズを意図的に増加させて、論理ブロック先頭から開始されるようにデータストリームを修正する方法も考えられる。しかし、その方法にはデータサイズの細かな制御のために複雑な処理が必要となる。そればかりでなく、データサイズが変化することにより、データストリームの先頭から、ＩＳＯ／ＩＥＣ１３８１８−１規格のシステムターゲットデコーダのバッファシミュレーションを再実施する必要が発生し、データストリーム全体の修正が必要になるため、適切ではない。【００１４】  本発明の目的は、データストリームの編集処理時間を短縮化できる装置等を提供することである。特に、データストリームが固定長のパケットから構成され、かつ記録領域の割り付けサイズが固定長のパケットサイズよりも大きく整数倍である場合に、データストリームを書き換えることなく、編集処理を高速に実行できる装置および方法を提供することである。
【課題を解決するための手段】
【００１５】  本発明によるデータ処理装置は、記録媒体の単位領域ごとにコンテンツデータの書き込みおよび読み出しを行う。前記単位領域には前記コンテンツデータを格納した複数のパケットが記録されている。前記データ処理装置は、前記複数のパケットを読み出す再生部と、第（ｎ＋１）パケットから第（ｎ＋ｍ）パケット（ｎ、ｍ：１以上の整数）までに格納されたコンテンツデータを分割して、第１パケットから前記第（ｎ＋ｍ）パケットまでの複数のパケットに格納する制御部と、前記第１パケットから前記（ｎ＋ｍ）パケットを含む複数のパケットを前記単位領域に書き込む記録部とを備えている。【００１６】  前記制御部は、分割された前記コンテンツデータを、前記第１パケットから前記第（ｎ＋ｍ）パケットまでの各パケットに順次格納してもよい。【００１７】  前記制御部は、分割された前記コンテンツデータを、前記第１パケットの次の第２パケットから順次格納してもよい。【００１８】  前記第（ｎ＋１）パケットが、前記データストリームの再生を管理するための管理情報を格納したパケットであるときにおいて、前記制御部は、前記管理情報を前記第１パケットに格納してもよい。【００１９】  各パケットのパケット長は所定長に固定されていてもよい。このとき前記制御部は、前記コンテンツデータとともに、前記コンテンツデータとは異なるパディングデータを前記少なくとも１つのパケットに格納することにより、前記少なくとも１つのパケットのパケット長を前記所定長に調整してもよい。【００２０】  前記制御部は、分割された前記コンテンツデータを、前記第１パケットから前記第（ｎ＋ｍ）パケットまでの２以上のパケットに格納してもよい。【００２１】  前記制御部は、前記パディングデータを含まないパケットと、前記パディングデータを含むパケットとをそれぞれ１以上生成してもよい。【００２２】  各パケットには、前記パケットの処理時刻を示す時刻情報が格納されていてもよい。このとき前記制御部は、前記第（ｎ＋１）パケットから前記第（ｎ＋ｍ）パケットまでのパケットのうち、前記コンテンツデータを最初に格納していた第ｐパケット（ｐ：ｎ＋１≦ｐ≦ｎ＋ｍを満たす整数）の時刻情報を取得し、前記時刻情報を、分割された前記コンテンツデータが最初に格納される第ｑパケット（ｑ：１≦ｑ≦ｐ−１を満たす整数）の処理時刻を示す時刻情報に変更して前記第ｑパケットに格納してもよい。【００２３】  各パケットのパケット長は所定長に固定されていてもよい。このとき前記制御部は、前記第ｐパケットと前記第ｑパケットとの間のパケット数、および、前記データストリームのデータレートに基づいて、前記時刻情報を変更してもよい。【００２４】  各パケットには、前記データストリームのデータレートを示すレート情報が格納されていてもよい。このとき前記制御部は、前記第ｐパケット内のレート情報に基づいて前記時刻情報を変更してもよい。【００２５】  前記制御部は、前記レート情報に基づいて特定される１パケットあたりの転送時間および前記パケット数に基づいて、前記時刻情報を変更してもよい。
【発明の効果】
【００２６】  本発明によれば、記録媒体の単位領域ごとにコンテンツデータの書き込みおよび読み出しを行う機器においてコンテンツデータを編集する際に、単位領域内の第（ｎ＋１）パケットから第（ｎ＋ｍ）パケット（ｎ、ｍ：１以上の整数）までに格納されたコンテンツデータを分割して、第１パケットから第（ｎ＋ｍ）パケットまでの複数のパケットに格納する。そして、第１パケットから第（ｎ＋ｍ）パケットは記録媒体の単位領域に記録し直される。これにより、当初の第１パケットから第ｎパケットまでのコンテンツデータが実質的に削除される。【００２７】  書き換え後の単位領域にはダミーデータのみを含むヌルパケットが含まれないため、ヌルパケットに対応していない機器でもそのコンテンツデータを解釈してコンテンツを再生できる。これにより、どのような機器であってもヌルパケットに起因してコンテンツの再生の乱れが生じたり、再生処理が停止することはない。【００２８】  また、単位領域を超えてコンテンツデータを書き換える必要もないため、後続の全てのデータを削除されたデータ相当だけ前にシフトする必要もない。よって編集処理に要する時間が著しく短縮化される。
【図面の簡単な説明】
【００２９】
【図１】本発明の実施形態によるレコーダ１０の構成を示す図である。
【図２】データストリームファイル２０のデータ構造を示す図である。
【図３】（ａ）はレコーダ１０による編集前のプログラムストリーム３５を示す部分であり、（ｂ）はレコーダ１０による編集後のプログラムストリーム３６を示す部分である。
【図４】削除編集前のビデオパック＃３のデータ構造を示す図である。
【図５】（ａ）は削除編集後のビデオパック＃１のデータ構造を示す図であり、（ｂ）は削除編集後のビデオパック＃２のデータ構造を示す図であり、（ｃ）は削除編集後のビデオパック＃３のデータ構造を示す図である。
【図６】削除編集処理前のプログラムストリーム３５とＶＯＢＵとＦＡＴファイルシステムのクラスタの配置に関する対応関係を示す図である。
【図７】削除編集処理後のプログラムストリーム３６とＶＯＢＵとＦＡＴファイルシステムのクラスタの配置に関する対応関係を示す図である。
【図８】レコーダ１０の削除編集処理の手順を示すフローチャートである。
【図９】メモリカード１３０のファイルシステムの階層構造を示す図である。
【図１０】プログラムストリームの管理情報の例を示す図である。
【図１１】各ＶＯＢＵがＲＤＩパックから開始されるプログラムストリーム３７のパック配列とＶＯＢＵとＦＡＴファイルシステムのクラスタの配置に関する対応関係を示す図である。
【図１２】削除編集処理後のプログラムストリーム３８とＶＯＢＵとＦＡＴファイルシステムのクラスタの配置に関する対応関係を示す図である。
【符号の説明】
【００３０】  １０  レコーダ
１００  映像信号入力部
１０１  映像圧縮部
１０２  音声信号入力部
１０３  音声圧縮部
１０４  システムエンコード部
１１０  映像信号出力部
１１１  映像伸長部
１１２  音声信号出力部
１１３  音声伸長部
１１４  システムデコード部
１２０  記録部
１２１  再生部
１３０  取り外し可能なメモリカード
１６０  連続データ領域検出部
１６１  記録制御部
１６２  再生制御部
１６３  論理ブロック管理部
１６４  編集制御部
１７０  ＭＰＥＧエンコーダ
１７１  ＭＰＥＧデコーダ
１７５  メディア制御部
１８０  システム制御部
１８１  ＣＰＵ
１８２  ＲＯＭ
１８３  ＲＡＭ
【発明を実施するための最良の形態】
【００３１】  以下、添付の図面を参照しながら、本発明によるデータ処理装置の実施形態を説明する。【００３２】  図１は、本実施形態によるレコーダ１０の構成を示す。レコーダは、映像および音声を含む動画のデータストリーム（動画ストリーム）をメモリカード１３０に書き込む機能（録画機能）、メモリカード１３０に書き込まれた動画ストリームを読み出して、動画を再生する機能（再生機能）およびメモリカード１３０に書き込まれた動画ストリームを読み出して、動画を編集する機能（編集機能）を有する。レコーダ１０は、たとえば持ち運び可能なカムコーダ、テレビ放送番組等を録画する据え置き型の記録装置である。【００３３】  以下、レコーダ１０の構成要素を説明する。レコーダ１０は、映像信号入力部１００と、音声信号入力部１０２と、映像表示部１１０と、音声出力部１１２と、ＭＰＥＧエンコーダ１７０と、ＭＰＥＧデコーダ１７１と、メディア制御部１７５と、システム制御部１８０と、ＣＰＵ１８１とを有している。【００３４】  レコーダ１０には、メモリカード１３０が取り外し可能に挿入され、メモリカード１３０に動画を録画できる。なお、メモリカード１３０はレコーダ１０の必須の構成要素ではない。【００３５】  本明細書においては、メモリカード１３０は、ＰＣにおいて一般的に用いられているＦＡＴ（ＦＡＴ１６またはＦＡＴ３２）ファイルシステムでフォーマットされているとする。メモリカード１３０において、空き領域の管理単位であり、かつ領域の書き込み／読み出し単位である論理ブロック（クラスタ）のデータサイズは、メモリカードの記録容量に応じて定められている。たとえばメモリカードの記録容量が１Ｇバイト以下の場合には各クラスタのデータサイズは１６ｋバイトであり、１Ｇバイトを超える場合には３２ｋバイト以上であるとする。ただし、１クラスタが１６ｋバイトのときは、１クラスタは３２個のセクタから構成され、１クラスタが３２ｋバイトのときは、１クラスタは６４個のセクタから構成される。【００３６】  映像信号入力部１００は、たとえばＣＣＤカメラや、アンテナ（図示せず）と接続された映像入力端子（図示せず）である。音声信号入力部１０２は、たとえばマイクや、アンテナ（図示せず）と接続された音声入力端子（図示せず）である。【００３７】  ＭＰＥＧエンコーダ１７０（以下「エンコーダ１７０」と記述する。）は映像圧縮部１０１と音声圧縮部１０３とシステムエンコード部１０４とを有している。映像圧縮部１０１は、映像信号入力部１００から映像信号を受け取り、ＭＰＥＧ規格に基づいて圧縮符号化する。音声圧縮部１０３は、音声信号入力部１０２から映像信号を受け取り、ＭＰＥＧ規格に基づいて（圧縮）符号化する。その結果、ビデオデータおよびオーディオデータが出力される。【００３８】  システムエンコード部１０４は、ビデオデータおよびオーディオデータをインターリーブして動画ストリームを生成する。より具体的には、システムエンコード部１０４は、ビデオデータおよびオーディオデータをそれぞれ格納したパケットを生成し、そのパケットを配列して動画ストリームを生成する。このとき、さらに他のデータ（文字データ、管理情報など）もパケット化されて動画��トリームの一部として配列され得る。【００３９】  メディア制御部１７５は、記録部１２０および再生部１２１を有しており、それぞれ、メモリカード１３０に対する動画ストリームの書き込みおよび読み出しを制御する。【００４０】  レコーダ１０の他の構成要素を説明する。ＭＰＥＧデコーダ１７０（以下「デコーダ１７１」と記述する。）は、映像伸長部１１１と音声伸長部１１３とシステムエンコード部１１４とを有している。処理の順序で説明すると、システムエンコード部１１４は動画ストリーム、すなわち上述のプログラムストリームをパケットの種類に応じて分離し、ビデオデータのパケットを映像伸長部１１１に送り、オーディオデータのパケットを音声伸長部１１３に送る。映像伸長部１１１は、ビデオデータをＭＰＥＧ規格に基づいて伸長し、映像信号出力部１１０に送る。音声伸長部１１３は、オーディオデータをＭＰＥＧ規格等に基づいて伸長し、音声信号出力部１１２に送る。【００４１】  映像信号出力部１１０は、たとえばレコーダ１０がカムコーダのときには液晶表示画面、録画機のときには映像信号を出力する端子である。音声信号出力部１１２は、たとえばスピーカや音声信号を出力する端子である。【００４２】  システム制御部１８０は、ＣＰＵ１８１とＲＯＭ１８２とＲＡＭ１８３とを有している。ＣＰＵ１８１は、たとえばＲＯＭ１８２に格納されたコンピュータプログラムを読み出し、ＲＡＭ１８３上に展開して実行することにより、各種の機能を実現できる。たとえばＣＰＵ１８１は、連続データ領域検出部１６０、記録制御部１６１、再生制御部１６２、論理ブロック管理部１６３、編集制御部１６４として機能する。以下では、ＣＰＵ１８１によって実現する各機能を独立した構成要素として取り扱う。各構成要素間のデータの授受は、プログラム間のデータの受け渡しに相当する。【００４３】  動画の録画時には、記録制御部１６１はプログラムストリームの記録を開始する前に連続データ領域検出部１６０に指示して、空き領域が例えば４Ｍバイト分だけ連続している領域を捜させる。連続データ領域検出部１６０はあらかじめ読み出した空き領域に関するＦＡＴ情報を参照して連続した空き領域を探索する。そして記録制御部１６１は、検出された空き領域上にプログラムストリームの記録を開始するよう記録部１２０に指示する。そして、ひとつの連続した空き領域へのプログラムストリームの書込みが終わるまでに、連続した空き領域を継続的に探索しプログラムストリームの記録を継続する。また、所定の時間間隔（例えば１０秒）でプログラムストリームに対する管理データの書込みを行う。【００４４】  また動画の再生時は、ユーザが再生すべきコンテンツを選択すると、再生制御部１６２は再生部１２１に指示して、コンテンツに対応するデータストリームの管理情報を管理ファイルから読み出させる。そして再生制御部１６２は、その管理ファイルに記載されたアドレス情報を参照してメモリカード１３０からさらにプログラムストリームを読み出すよう、再生部１２１に指示する。【００４５】  動画の編集時において、編集制御部１６４は、たとえば記録済みのコンテンツの一部に対する削除の指示をユーザから受け取る。このとき編集制御部１６４は、再生部１２１に対して指示して編集対象のデータを読み出させる。編集対象のデータはメモリカード１３０の論理ブロック単位で読み出される。【００４６】  編集制御部１６４は、読み出されたデータのうちから削除するべき部分を特定し、その部分を削除する。その後、編集制御部１６４は削除されなかったデータに対して後述の処理を行ってパック内のデータサイズを調整し、メモリカード１３０のクラスタの先頭からビデオパックを配置するよう記録部１２０に指示する。【００４７】  本実施形態においては、エンコーダ１７０によって生成され、メディア制御部１７５によってメモリカード１３０に書き込まれる動画ストリームはＭＰＥＧ２規格のプログラムストリームであるとする。プログラムストリームは、「パック」と呼ばれる固定長のデータ単位から構成される。「パック」はパケットの１つの例示的な形態として知られている。【００４８】  ここで図２を参照しながら、プログラムストリームを説明する。メモリカード１３０に書き込まれたプログラムストリームは、データストリームファイルとして管理される。図２は、データストリームファイル２０のデータ構造を示す。以下に説明するデータ構造は、たとえばＳＤメモリカード等のメモリカード１３０、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ等の光ディスクに動画を記録するためのＤＶＤビデオレコーディング規格に準拠している。【００４９】  データストリームファイル２０は、たとえばＭＰＥＧプログラムストリーム２１に示すようなＶＯＢ（ＶｉｄｅｏＯｂｊｅｃｔ；ビデオオブジェクト）を複数含んでいる。そして各ＶＯＢは、１以上のビデオオブジェクトユニット（Ｖｉｄｅｏ  ＯＢｊｅｃｔ  ＵＮＩＴ：以下「ＶＯＢＵ」という。）から構成される。【００５０】  各ＶＯＢＵは、２０４８バイト単位のＭＰＥＧプログラムストリームの下位階層であるパックから構成されており、映像の再生時間にして０．４〜１秒分のデータを含む。【００５１】  以下、ＶＯＢＵ２２を例に挙げて説明する。ＶＯＢＵ２２は、圧縮されたビデオデータが格納されたビデオパック（Ｖ＿ＰＣＫ）２３と、圧縮されたオーディオデータが格納されたオーディオパック（Ａ＿ＰＣＫ）２４の２種類を含んでいる。ＶＯＢＵ２２内の全ビデオパック（Ｖ＿ＰＣＫ）２３のビデオデータを再生すると、上述の０．４〜１秒の映像になる。また、ＶＯＢＵ２２内のオーディオデータは、各音声フレームの復号に利用される。１つの音声フレームのデータがＶＯＢＵ境界をまたいで格納されることはない。【００５２】  なお、各ＶＯＢＵの先頭にはリアルタイムデータ情報パック（ＲＤＩ＿ＰＣＫ）が記録されてもよい。ＲＤＩパックには、再生を管理するための管理情報（たとえばレターボックス情報）が必要に応じて格納される。【００５３】  本実施の形態のプログラムストリームには、上述のパック以外の他の種類のパックは含まれないとする。また、ビデオパックおよびオーディオパック内には少なくとも１バイトのビデオデータおよびオーディオデータを格納したＰＥＳパケットが含まれるとする。ひとつのビデオパックおよびオーディオパック内には、最大１個のパディングストリームを含むＰＥＳパケットを含むことが可能である。このＰＥＳ���ケットはパック長を２０４８バイトに調整するために設けられ、パディングストリームを含むことを示すＰＥＳヘッダおよびパディングストリームを含んでいる。【００５４】  プログラムストリーム２１には、システム時刻基準ＳＣＲ、映像／音声の復号時刻情報（ＤＴＳ）および出力時刻情報（ＰＴＳ）等の時刻情報が格納されている。システム時刻基準ＳＣＲは、再生装置のＳＴＣレジスタに基準値を設定するために利用される。この基準値に基づいて同期信号ＳＴＣが生成され、同期信号ＳＴＣの値とデコード時刻情報（ＤＴＳ）の値とが一致するタイミングで映像および音声がそれぞれ復号化される。そして同期信号ＳＴＣの値と出力時刻情報（ＰＴＳ）の値とが一致するタイミングで、映像および音声がそれぞれ出力される。本実施形態においては、ひとつの連続したプログラムストリーム（ＶＯＢ）中のシステム時刻基準ＳＣＲ、映像の復号時刻情報（ＤＴＳ）および出力時刻情報（ＰＴＳ）の各値は所定の周期で連続的に変化しているとする。【００５５】  各ＶＯＢＵの先頭のビデオパック２３は、パックヘッダ２５およびパックデータ（ビデオデータ）２６を含んでいる。さらに、ビデオデータ２６はシーケンスヘッダ２８、ＧＯＰヘッダ２９、および圧縮されたＩピクチャデータ３０を含んでいる。図においては、さらに他のＰＥＳヘッダおよびＰピクチャフレームデータ３１が示されている。【００５６】  なお、Ｉピクチャデータのデータサイズは一般に大きく、２０４８バイトを大きく超えることがある。よって、ビデオデータ２６にはＩピクチャデータの一部（たとえば先頭部分）しか格納されないこともある。【００５７】  Ｉピクチャ３２からピクチャ３３までの複数枚のピクチャが１つのグループ・オブ・ピクチャ（ＧＯＰ）を構成している。ＧＯＰとは、単独で再生され得る映像フレームであるＩピクチャ３２と、次のＩピクチャの直前のピクチャ３３までの、Ｐピクチャおよび／またはＢピクチャを含む複数の映像フレームをまとめた再生単位である。【００５８】  次に、図３から図５までを参照しながら、本実施形態によるレコーダ１０の特徴的な処理を説明する。【００５９】  図３（ａ）はレコーダ１０による編集前のプログラムストリーム３５を示し、図３（ｂ）はレコーダ１０による編集後のプログラムストリーム３６を示す。理解を容易にするため、図３（ａ）および（ｂ）にはビデオパックのみが示されている。【００６０】  まず図３（ａ）を参照する。前提として、プログラムストリーム３５を構成する各パックには、ダミーデータのみが格納されたヌルパケットは含まれていないとする。【００６１】  ユーザが、たとえば動画の先頭から所定の場面までを削除したいとして指定すると、プログラムストリーム３５の先頭からその場面に対応するデータまでの範囲が削除範囲Ｄとして特定される。この削除範囲Ｄは複数のクラスタに跨がっているとする。そして、最後のクラスタの先頭から順にビデオパック＃１、＃２、＃３・・・が配置されており、削除範囲Ｄの終端はビデオパック＃２であるとする。【００６２】  本実施形態によるレコーダ１０の特徴のひとつは、最後のクラスタに関して、ビデオパック＃１、＃２内のビデオデータＶ１およびＶ２を削除すると���もに、削除範囲Ｄ以降に配置されていたビデオパック＃３のビデオデータＶ３を分割して、その一部をそれぞれ新たなビデオデータとして格納したビデオパック＃１、＃２を生成することにある。ビデオパック＃３には、当初のビデオデータの一部が残される。【００６３】  ここで図３（ｂ）を参照する。図３（ｂ）によれば、ビデオパック＃３のビデオデータＶ３がビデオデータＶ３−１、Ｖ３−２およびＶ３−３に分割されて、それぞれクラスタ先頭のビデオパック＃１、次のビデオパック＃２、および、ビデオパック＃３に格納されていることが理解される。なお、各パックのデータサイズを調整するため、ダミーデータ（スタッフィングバイトまたはパディングストリーム）が利用されている。【００６４】  編集後のクラスタにはダミーデータのみを含むヌルパケットは含まれていない。そして、ＭＰＥＧ規格上許容されているパディングストリームが利用されるため、少なくともＭＰＥＧ規格に対応さえしていれば、どのような機器であっても映像を乱れなく確実に再生できる。【００６５】  また、単位領域を超えてコンテンツデータを書き換える必要もないため、削除されたデータ相当量だけ後続の全データを前にシフトする必要もない。よってシフトする場合と比較すると、編集処理に要する時間が著しく短縮化される。【００６６】  なお、ビデオデータＶ１およびＶ２の削除処理は、実際にデータを削除した後にビデオパック＃１および＃２にビデオデータＶ３−１およびＶ３−２を格納してもよいし、ビデオパック＃１および＃２にビデオデータＶ３−１およびＶ３−２を上書きしてもよい。【００６７】  図４および図５を参照しながら、削除編集前のビデオパック＃３と、削除編集後のビデオパック＃１〜＃３を詳細に説明する。【００６８】  図４は、削除編集前のビデオパック＃３のデータ構造を示す。編集前のビデオデータＶ３は２００２バイトである。【００６９】  レコーダ１０は削除すべき範囲Ｄを特定した後、ビデオデータＶ３を、２０００バイトのビデオデータＶ３−１と、１バイトのビデオデータＶ３−２と、１バイトのビデオデータＶ３−３とに分ける。このビデオデータＶ３−１はビデオパック＃１に移動され、データＶ３−２はビデオパック＃２に移動される。一方、ビデオデータＶ３−３はビデオパック＃３に残される。なお、パックヘッダは２４バイト、ＰＥＳヘッダは２２バイトである。パックヘッダ、ＰＥＳヘッダおよびビデオデータＶ３のデータサイズの合計は２０４８バイトである。【００７０】  パックヘッダにはパック開始コード（０ｘ００００、０ｘ０１ＢＡ）、ＳＣＲ（システム・クロック・リファレンス）フィールド、多重化ビットレート（Ｐｒｏｇｒａｍ  Ｍｕｘ  Ｒａｔｅ）フィールド、システムヘッダ等が含まれる。【００７１】  図５（ａ）〜（ｃ）は、それぞれ削除編集後のビデオパック＃１、＃２および＃３のデータ構造を示す。図５（ａ）に示されるビデオパック＃１には、２０００バイトのビデオデータＶ３−１が格納されている。このとき、パックヘッダのデータサイズは２４バイトであり、ＰＥＳヘッダのデータサイズも２４バイトである。【００７２】  ＤＶＤビデオレコーディング規格では、パックのデータサイズを調整するため���、ＰＥＳヘッダにスタッフィングバイトを付加することが許容されている。スタッフィングバイトは、予め定められたダミーデータとして機能し、意味を持たない値として、たとえば”０ｘＦＦ”（１６進数）等のバイトデータが予め定められている。【００７３】  本実施形態においては、バックのデータサイズ（２０４８バイト）、パックヘッダのデータサイズ（２４バイト）、および、ビデオデータＶ３−１のデータサイズ（２０００バイト）が特定されているため、ＰＥＳヘッダのデータサイズも２４バイトに特定される。その結果、パック長を２０４８バイトに調整するために、当初の２２バイトのＰＥＳヘッダに対して２バイトのスタッフィングバイトが追加される。【００７４】  図５（ｂ）および図５（ｃ）に示されるビデオパック＃２および＃３は、それぞれ２個のＰＥＳパケットを含む。ＰＥＳパケットは、ＰＥＳヘッダとその後のデータとから構成されるパケットである。【００７５】  たとえばビデオパック＃２の１つ目のＰＥＳパケットには、１バイトのビデオデータＶ３−２が格納されている。２個目のＰＥＳパケットにはパディングストリームＰが格納されており、これによりパック長が調整されている。パディングデータもスタッフィングバイトと同様に、意味を持たない値として”０ｘＦＦ”（１６進数）等のバイトデータが定められている。ビデオパック＃２とビデオパック＃３との違いは、ビデオデータ値とＳＣＲ値のみである。【００７６】  ビデオパック＃１（図５（ａ））ではスタッフィングバイトによってパックサイズを調整し、ビデオパック＃２および＃３（図５（ｂ）および（ｃ））ではパディングストリームＰによってパックサイズを調整している。その理由は、規格上、スタッフィングバイトとして調整可能なサイズの上限が定められており（たとえば７バイト以下等）、その上限によっては、スタッフィングバイトの挿入によってはパックサイズを調整できないケースがあるためである。また、スタッフィングバイトとパディングストリームとを同一のパック内に同時に設けることも規格上認められていないケースもある。これらのケースにおいては、調整すべきサイズが上限値よりも大きいときは、パック長をスタッフィングバイトによって調整するのではなく、パディングストリームによって調整すればよい。本実施形態においては、８バイト以上（例えば１ｋバイト）の場合は、２個目のＰＥＳヘッダを記録して、そのヘッダからパディングストリームＰを設けるとする。【００７７】  ＰＥＳヘッダには、そのヘッダの後に格納されているデータに応じて個別のストリームＩＤが設定される。ビデオストリームのＰＥＳヘッダにはビデオストリームＩＤ（たとえば０ｘＥ０）が付加され、オーディオストリームのＰＥＳヘッダにはオーディオストリームＩＤ（たとえば０ｘＥ１）が付加される。これらは互いに異なる値である。そして本実施形態においては、パディングストリームＰのＰＥＳヘッダには、ビデオ／オーディオの各ストリームＩＤとはさらに異なるＩＤ（たとえば０ｘＢＥ）が設定される。【００７８】  なお、ビデオパック＃２および＃３に格納されるビデオデータはそれぞれ１バイトとしたが、これは例である。ビデオデータは、たとえば１０バ���トや１ｋバイトであってもよいし、ビデオパック＃２および＃３のビデオデータサイズもそれぞれ異なる値であってもよい。その値に応じて、スタッフィングバイトまたはパディングストリームを利用してパック長を調整すればよい。【００７９】  削除編集処理に関連して、ＳＣＲ値を変更する必要がある点にも留意する必要がある。図４のパックヘッダのデータ構造に示されるように、各パックヘッダにはＳＣＲ値が付加されている。削除編集前のビデオパック＃３のビデオデータには、ビデオパック＃１および＃２の後に読み出されることを前提としたＳＣＲ値が設定されている。レコーダ１０は削除編集処理において、ビデオパック＃１のパックヘッダに対して、削除編集前のビデオパック＃３に設定されていたＳＣＲ値よりも２パック分のデータ転送時間だけ早いＳＣＲ値を設定する。これにより、再生時の動作基準時刻を２パック分のデータ転送時間だけ早めることができる。【００８０】  次に、図６および図７を参照しながら、削除編集前後のプログラムストリーム、ＶＯＢＵおよびクラスタの関係を詳細に説明する。【００８１】  図６は、削除編集処理前のプログラムストリーム３５とＶＯＢＵとＦＡＴファイルシステムのクラスタの配置に関する対応関係を示す。図６の（ａ）は削除編集前のプログラムストリーム３５の構成を示し、（ｂ）はＶＯＢＵの配列を示し、（ｃ）はＦＡＴファイルシステムのクラスタの配列を示す。【００８２】  ユーザによって指定された削除範囲Ｄは、ビデオパック（Ｖ＿ＰＣＫ）＃２から前のパックであり、特定のＶＯＢの先頭からＶＯＢＵ＃（ｉ−１）までであるとする。よって、削除処理後はＶＯＢＵ＃ｉ以降からＶＯＢ末尾までのデータが残される。ＦＡＴファイルシステムで管理されるクラスタ＃Ｊにおいては、先頭の２個のＶ＿ＰＣＫ（合計４キロバイト）が削除される。【００８３】  なお、ビデオパック＃３はＶＯＢＵ＃ｉの先頭パックであるため、そのビデオデータには図２に示すようにシーケンスヘッダ、ＧＯＰヘッダ、Ｉピクチャのデータが含まれている。【００８４】  図７は、削除編集処理後のプログラムストリーム３６とＶＯＢＵとＦＡＴファイルシステムのクラスタの配置に関する対応関係を示す。図７の（ａ）は削除編集後のプログラムストリーム３６の構成を示し、（ｂ）はＶＯＢＵの配列を示し、（ｃ）はＦＡＴファイルシステムのクラスタの配列を示す。【００８５】  プログラムストリーム３６のビデオパック＃１〜＃３のデータ構造は、それぞれ図５（ａ）〜（ｃ）に示すとおりである。当初のビデオパック＃１および＃２は一旦削除され、その後、編集処理前のビデオパック＃３に格納されていたビデオデータの一部を新たに格納したパックとして生成されている。図７においては、ビデオパック＃１および＃２を「追加されたＶパック」として示している。【００８６】  一方、ビデオパック＃１よりも前に配置されていたデータ、すなわちクラスタ＃ｊよりも前のクラスタに配置されていた範囲ｄ内のデータは、実際に削除されている。削除編集処理の結果、当初のＶＯＢＵ＃ｉはクラスタ＃Ｊの先頭から配置されている。【００８７】  なお、クラスタ＃Ｊ内のビデオパック＃３以降の後続パックは編集処理前後で変化はない���指示された範囲Ｄを埋めるように後続のプログラムストリームのデータを移動させる必要はないため、そのような移動を行う場合と比較すると、処理は非常に高速である。【００８８】  次に、図８を参照しながら、上述の処理を行うレコーダ１０の処理手順を説明する。図８は、レコーダ１０の削除編集処理の手順を示す。以下の処理は、主として図１のシステム制御部１８０全体、より特定的にはＣＰＵ１８１によって実行される。ただし、以下の説明ではＣＰＵ１８１によって実現される機能的な構成要素を処理の主体として説明する。【００８９】  ステップＳ８１において、編集制御部１６４はユーザに編集モード画面を提示して、どのプログラムストリームに対して削除処理を行うかの指示をユーザから受け、さらにそのプログラムストリームの削除すべき部分と、残すべき部分の境界を指定させる。【００９０】  たとえば、編集モード画面において、ユーザが編集を希望するコンテンツを指定すると、編集制御部１６４はメディア制御部１７５に対してそのプログラムストリームの読み出しを指示する。デコーダ１７１がそのプログラムストリームを復号化すると、映像信号出力部１１０および音声信号出力部１１２は映像および音声を出力する。【００９１】  編集モード画面に映像および音声が出力され始めると、ユーザは指定すべき場面が表示されたときに、リモコン等の決定ボタンを押す。これにより、編集制御部１６４はユーザが選択した箇所がある１個のＶＯＢ内のＶＯＢＵ＃（ｉ−１）とＶＯＢＵ＃ｉの境界であることを検出することができる。以下では、ユーザはさらにその境界（編集点）から前に存在する全てのデータを削除するよう指定したとする。これにより、ユーザが削除を指示した範囲Ｄが特定される。【００９２】  次のステップＳ８２において、編集制御部１６４は編集点がクラスタの先頭に一致するか否かを判断する。編集点がクラスタの先頭に一致しないときにはステップＳ８３に進み、先頭に一致するときにはステップＳ８７に進む。【００９３】  ステップＳ８３において、削除範囲直後のビデオパックを読み出す。このビデオパックは、上述の説明におけるビデオパック＃３（図３、４、６）に対応する。なお、各ＶＯＢＵの先頭アドレスはプログラムストリーム毎に全て管理ファイルに記録されている。よって、この管理ファイルを参照することにより、ＶＯＢＵ先頭のビデオパック＃３のデータを取り出すことは容易である。管理ファイルに関しては、図９、図１０等を参照しながら後述する。【００９４】  次のステップＳ８４においては、ビデオパック＃０が記録されているクラスタ＃Ｊ上で、削除されるパック数を求める。このパック数は、上述の説明においては、ビデオパック＃１および＃２の２つである。【００９５】  パック数を求めるための計算は以下のとおりである。まず編集制御部１６４は、ＶＯＢＵ＃ｉのデータストリームファイル先頭からのアドレスオフセット値（差分値）をクラスタサイズ（たとえば３２ｋバイト）で除算する。その後、その余り値をさらに２０４８バイトで除算する。これにより、パック数が得られる。【００９６】  その後編集制御部１６４は、ワークメモリとして機能するＲＡＭ１８３上で、ビデオパック＃３のビデオデ���タを、クラスタ＃Ｊ上で削除された後の２パックにも分割して格納できるように準備する。つまり、図３（ｂ）および図７（ａ）に示すように、編集前のビデオパック＃３のビデオデータを、ビデオパック＃１、およびビデオパック＃２に分配するためのビデオデータの分割処理を行う。【００９７】  なお、ＶＯＢＵ＃ｉのデータストリームファイル先頭からのオフセット値は管理ファイル内に格納された情報から算出可能であるとする。例えば、管理ファイル内に格納されたＶＯＢＵのデータサイズ（後述する図１０）を累計すれば、オフセット値を算出できる。【００９８】  次のステップＳ８５では、編集制御部１６４は、ＲＡＭ１８３上のビデオパック＃１および＃２の各パックヘッダにＳＣＲ値を設定する。すなわち編集制御部１６４は、ビデオパック＃３のＳＣＲ値を基準として、ビデオパック＃１には２パックのデータ転送時間だけ早いＳＣＲ値を設定し、ビデオパック＃２には１パックのデータ転送時間だけ早いＳＣＲ値を設定する。それぞれ、ビデオパック＃３のＳＣＲ値から２パックまたは１パックのデータ転送時間に対応するＳＣＲ値を減算すればよい。【００９９】  具体的には、パック１つのデータ転送時間に対応するＳＣＲ値は、プログラムストリームのデータ転送速度（たとえば１０．０８Ｍｂｐｓ）に対するパックデータ長（２０４８バイト）のデータが転送される時間を２７ＭＨｚのクロック値で表現した値として求められる。具体的には、（２０４８×８／１０．０８×１０６）＊２７＊１０６である。なお、データ転送速度を示す値は、パックヘッダの多重化ビットレート（Ｐｒｏｇｒａｍ  Ｍｕｘ  Ｒａｔｅ）フィールドに記述されているため、編集制御部１６４はその値をビデオパック＃３から読み出して、ＳＣＲ値の演算に利用することができる。【０１００】  ステップＳ８６においては、編集制御部１６４はＲＡＭ１８３上に作成されたビデオパック＃１、＃２および＃３を、それぞれクラスタＪの先頭から格納するように、メディア制御部１７５に指示する。メディア制御部１７５の記録部１２０は、新たに生成されたビデオパック＃１、＃２および＃３を受け取って、メモリカード１３０のクラスタＪの先頭から書き込む。【０１０１】  ステップＳ８７において、編集制御部１６４は、データストリームのＦＡＴ情報を更新する。編集制御部１６４はメディア制御部１７５に指示して、削除されたプログラムストリーム部分を示すＦＡＴ情報を削除させ、削除編集処理後のプログラムストリーム（ＶＯＢ）がクラスタ＃Ｊの先頭から始まるようにＦＡＴ情報を設定させる。【０１０２】  なお、処理がステップＳ８２からステップＳ８７にジャンプしたときには、編集点より前に存在する全クラスタが削除されることを意味する。よって、編集点以降のクラスタが最初のクラスタになるようにＦＡＴ情報を更新すればよい。【０１０３】  最後のステップＳ８８において、編集制御部１６４は、プログラムストリームの管理情報を修正する。管理情報は、メモリカード１３０に管理ファイルとして記録されている。【０１０４】  具体的には、管理情報内のＶＯＢＵ＃ｉのデータサイズおよびＩフレームのデータサイズの値はパック数で記述されるため、編集制御部１６４はそれ���の値を２パック分増加させる。編集処理によって、ＶＯＢＵ＃ｉの最初のビデオデータ（Ｉフレームのビデオデータ）の一部がビデオパック＃１および＃２に分割して格納され、管理情報を更新する必要が生じたためである。また、ＶＯＢＵ＃（ｉ−１）よりも前の部分が削除されたため、編集制御部１６４は関連する管理データも併せて削除する。【０１０５】  図９は、メモリカード１３０のファイルシステムの階層構造を示す。管理ファイルＶＲ＿ＭＡＮＧＥＲ．ＩＦＯおよびデータストリームファイルＶＲ＿ＭＯＶＩＥ．ＶＲＯがルートディレクトリ下のＤＶＤ＿ＲＴＡＶディレクトリ内に格納されている。【０１０６】  図１０は、プログラムストリームの管理情報の例を示す。管理情報はＶＯＢＵごとに生成されている。図１０によれば、各ＶＯＢＵに対応して管理情報が存在することが示されている。【０１０７】  管理情報として、各ＶＯＢＵのＶＯＢＵデータサイズ、ＶＯＢＵの先頭のＩピクチャ終端を含むパックのアドレスオフセット値、およびＶＯＢＵに含まれる映像フィールド数が規定されている。なお図２から明らかなように、ＶＯＢが複数存在する場合には、図１０に示す管理情報の組がＶＯＢの数に応じて存在する。【０１０８】  以上の構成により、レコーダ１０がデータストリームの一部を削除する際に、クラスタの先頭を含む部分が削除の対象となっている場合には、１クラスタ内のデータストリームのデータを処理するだけで、編集処理が完了する。これにより、編集処理の複雑さが大幅に軽減されるとともに、残されたデータを順次前に詰めて記録しなおす処理と比較すると著しく短時間で処理が完了する。【０１０９】  本実施形態においては、データストリームの削除処理を説明した。しかしこれは例であり、他には、たとえばデータストリームを分割する処理にも適用できる。具体的には、分割点がクラスタの途中に存在するときには、その分割点直後のパックから後続のそのクラスタ内のパックを読み出して他のクラスタに書き込む必要がある。このとき、分割点直後のパックのビデオデータを利用して、そのクラスタの先頭からパックを配置すればよい。【０１１０】  上述の実施形態では、削除範囲直後のＶＯＢＵに関し、先頭ビデオパック内のビデオデータを分割して編集後に得られるストリーム先頭の３つのビデオパックに分配して格納する例を説明した。しかし、本発明はその例（第１例とする）に限定されることはない。【０１１１】  第２例として、削除範囲直後のＶＯＢＵではなく、その次のＶＯＢＵを対象として上述の処理を行ってもよい。このときは、削除範囲直後のＶＯＢＵがクラスタ＃Ｊの先頭に配置しなおした後で、続くＶＯＢＵ内の先頭ビデオパックのビデオデータを複数のビデオパックに分配する必要がある。ＳＣＲ値の変更が必要となるパックは、削除範囲直後のＶＯＢＵの各パックおよび続くＶＯＢＵにおいてビデオデータが分配されたパックである。分割されるビデオデータを格納していたパックの位置が編集後のデータストリーム先頭から離れるほど、ＳＣＲ値の変更が必要になるパック数が増加する。【０１１２】  さらに第３例として、先頭ビデオパックをそのままクラスタの先頭に移動するとともに、２つ目以降のビデオパックのビデオデータを分割して複数のビデオパックに分配してもよい。ＳＣＲ値の変更が必要となるパックは、クラスタの先頭に移動された先頭ビデオパックと、ビデオデータが分配されたパックである。【０１１３】  第３例による処理は、特にプログラムストリームの各ＶＯＢＵが、リアルタイムデータ情報パック（ＲＤＩパック）から始まるときに効果的である。図１１は、各ＶＯＢＵがＲＤＩパックから開始されるプログラムストリーム３７のパック配列とＶＯＢＵとＦＡＴファイルシステムのクラスタの配置に関する対応関係を示す。ＶＯＢＵ＃ｉの先頭はＲＤＩパック（ＲＤＩ＿ＰＣＫ）１１であることが理解される。【０１１４】  このようなプログラムストリーム３７に対して、図１１に示すように削除範囲Ｄが指示されたとする。先の実施形態の説明と同様、クラスタ＃Ｊ先頭のビデオパック＃１および＃２が削除され、ＲＤＩパック１１およびビデオパック＃３の順にパックが配置されたＶＯＢＵ＃ｉが削除編集後に残されるとする。【０１１５】  図１２は、削除編集処理後のプログラムストリーム３８とＶＯＢＵとＦＡＴファイルシステムのクラスタの配置に関する対応関係を示す。レコーダ１０が、図１２に示すプログラムストリーム３８を生成する手順は以下のとおりである。【０１１６】  なお以下の処理は、レコーダ１０が図１１に示すクラスタ＃Ｊから複数のパックを読み出した後、ＲＡＭ１８３上で実行されるとして説明する。実行されるタイミングは、クラスタ＃Ｊより前のデータを実際に削除した後であってもよいし、削除する前であってもよい。【０１１７】  まず編集制御部１６４は、編集前のＲＤＩパック１１を、ＲＤＩパック１２としてＲＡＭ１８３の記録領域に配置する。この移動は、存在していたビデオパック＃１をＲＤＩパック１２で上書きすることによって実現してもよいし、ビデオパック＃１を一旦削除してその後ＲＤＩパックを書き込むことによって実現してもよい。さらに読み出したクラスタ＃Ｊのデータを格納した領域とは異なる領域において行ってもよい。【０１１８】  続いて編集制御部１６４は、図１１に示すビデオパック＃３のビデオデータに対して、図３に示すビデオパック＃３と同じ処理を行う。これにより、ビデオパック＃３内のビデオデータは分割されて、３つのビデオパックが生成される。編集制御部１６４は、生成した３つのビデオパックをＲＤＩパック１２の後から順に配置する。これらのビデオパックは、図１２に示すビデオパック＃１〜＃３に対応する。【０１１９】  ビデオパックの生成または配置にあわせて、編集制御部１６４は各パックのパックヘッダ内にＳＣＲ値を設定する。具体的には、先頭のＲＤＩパック１２のＳＣＲ値は、編集前のＲＤＩパック（図１１）の値よりも２パックの転送時間相当だけ小さく設定する。編集後のビデオパック＃１のＳＣＲ値は、編集前のビデオパック＃３（図１１）の値よりも、２パックの転送時間相当だけ小さく設定する。これらはそれぞれ編集前のビデオパック＃１および＃２と同じ値である。同様に、編集後のビデオパック＃２のＳＣＲ値は編集前のＲＤＩパック（図１１）の値と同じになり、編集後のビデオパック＃３のＳＣＲ値は変動しない。【０１２０】  その後、編集制御部１６４はメディア��御部１７５に対し、ＲＤＩパック１２、ビデオパック＃１〜＃３等を、メモリカード１３０のクラスタ＃Ｊの先頭から順に書き込むよう指示する。なお、ビデオパック＃３以降のパックのデータは、変更しなくてもよい。その結果、図１２に示すプログラムストリーム３８がメモリカード１３０に書き込まれる。【０１２１】  上述の説明では、プログラムストリームの前方削除処理、すなわち、図８の「編集点」に相当する位置から前のデータを全て削除する処理を例に挙げて説明した。しかし、本発明の適用できる範囲は前方削除処理に限られない。たとえば本発明は、データストリームの中間部分を削除する処理に際しても適用できるし、また１つのデータストリームを編集点から２つに分割する処理に際しても適用できる。【０１２２】  より具体的には、中間部分を削除する処理では、中間部分の後に残されるデータストリームの先頭部分に対して本発明の処理を適用すればよい。また、１つのデータストリームを分割する処理では、編集点の後のデータストリームの先頭部分に対して本発明の処理を適用すればよい。いずれの場合も、その先頭部分のデータが格納されたクラスタ内に存在するデータに対して、図８に示すステップＳ８２以降の処理を行えばよい。【０１２３】  上述の実施形態およびその変形例を総合すると、レコーダ１０の処理は以下のように一般化することができる。すなわち、単位領域（クラスタ）にコンテンツデータを格納したプログラムストリームが記録されているときにおいて、メディア制御部１７５の再生部１２１がクラスタ単位でプログラムストリームのパックを読み出す。すると編集制御部１６４は、第（ｎ＋１）パケットから第（ｎ＋ｍ）パケット（ｎ、ｍ：１以上の整数）までの少なくとも１つに格納されたコンテンツデータを分割して、第１パケットから第（ｎ＋ｍ）パケットまでの複数のパケットに格納する。その後、メディア制御部１７５の記録部１２０は、第１パケットから（ｎ＋ｍ）パケットを含む複数のパケットを、元のクラスタに書き込む。これにより、編集処理時間を著しく短縮できる。【０１２４】  これまで説明した実施形態では、メモリカード１３０はリムーバブルであるとしたがこれは例である。上述したファイルシステムによりファイルを管理するメディアであれば、他の半導体記録媒体（たとえばＦｅＲＡＭ、ＭＲＡＭ）であってもよいし、光ディスク（たとえばＤＶＤ−ＲＡＭ、ＭＯ、ＤＶＤ−Ｒ、ＤＶＤ−ＲＷ、ＤＶＤ＋ＲＷ、ＤＶＤ＋Ｒ、ＣＤ−Ｒ、ＣＤ−ＲＷ）であってもよい。さらにレコーダ１０に内蔵されたハードディスクなどの非可換メディアであってもよい。【０１２５】  なお、上述の実施形態においては、ＦＡＴファイルシステムに関して説明したが、パックサイズの整数倍で記録領域が割り付けられるファイルシステムであれば、ＦＡＴファイルシステムに限られない。たとえば、１個の論理ブロックのサイズが３２キロバイトであるＵＤＦファイルシステムであってもよい。【０１２６】  なお、図１等の各機能ブロックは、典型的にはＣＰＵ１８１に代表される集積回路（Ｌａｒｇｅ  Ｓｃａｌｅ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ；ＬＳＩ）のチップとして実現される。これらは個別に１チップ化されてもよいし、��部または全てを含むように１チップ化されてもよい。例えば、図１においては、ＭＰＥＧエンコーダ部１７０とシステム制御部１８０とは別個の機能ブロックとして示されている。これらはそれぞれ別個の半導体チップとして実装されてもよいし、物理的に同一のチップによって実現してもよい。また、システム制御部１８０、ＭＰＥＧエンコーダ１７０およびＭＰＥＧデコーダ１７１の機能を集積化して、１つのチップ回路として実現してもよい。ただし、例えば符号化または復号化の対象となるデータを格納するメモリのみを集積化の対象から除外してもよい。【０１２７】  なお、上述の「ＬＳＩ」は、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサーを利用してもよい。【０１２８】  さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオテクノロジーを利用したいわゆるバイオ素子として集積化を行ってもよい。【０１２９】  本実施形態においては、全プログラムストリーム（全ＶＯＢ）を１個のデータストリームファイルに格納したが、それぞれ別々のデータストリームファイルとして分離してもよい。また、データストリームファイルに関する全管理データを１個の管理ファイルに格納したが、別々のデータストリームファイルの管理データファイルとして分離してもよい。【０１３０】  また、本実施形態においては、データストリームはプログラムストリームであるとして説明したが、トランスポートストリームやＰＥＳストリーム等の他のマルチメディア情報を含むビットストリームであってもよい。また、映像はＭＰＥＧ−２ビデオストリームを例としたが、ＭＰＥＧ−４ビデオストリームやＭＰＥＧ−４ＡＶＣストリームであってもよい。また、音声もリニアＰＣＭオーディオストリームやＡＣ−３ストリーム等であってもよい。【０１３１】  なお、ＳＣＲの減算処理を実施する場合には、ＶＯＢＵ＃ｉの中の最初に表示されるピクチャのＰＴＳ（プレゼンテーションタイムスタンプ）値とＳＣＲの最小値の間隔が１秒以内であることを確認することが必要とされる。特殊な符号化を実施していない限り１秒以上となることは非常に稀である。逆に、ＭＰＥＧエンコーダは各ＶＯＢＵの最初に表示されるピクチャのＰＴＳと各ＶＯＢＵの先頭ＳＣＲの時間間隔を例えば０．９秒を越えないように符号化することが好ましい。
【産業上の利用可能性】
【０１３２】  本発明のデータ処理装置（レコーダ）によれば、記録されたコンテンツの前方削除処理や分割処理の簡略化が可能であり、短時間のうちに編集処理を完了することができる。ユーザに対しては待ち時間を少なくできるため利便性が向上する。さらに、動作時間の減少によってデータ処理装置の電力消費を抑えることができるため、特にバッテリで駆動する機器、たとえばカムコーダ等のモバイルＡＶ機器に非常に有用である。
【図１】
2006088100.tif 000003
【図２】
2006088100.tif 000004
【図３】
2006088100.tif 000005
【図４】
2006088100.tif 000006
【図５】
2006088100.tif 000007
【図６】
2006088100.tif 000008
【図７】
2006088100.tif 000009
【図８】
2006088100.tif 000010
【図９】
2006088100.tif 000011
【図１０】
2006088100.tif 000012
【図１１】
2006088100.tif 000013
【図１２】
2006088100.tif 000014
【手続補正書】
【提出日】平成18年8月1日(2006.8.1)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
記録媒体の単位領域ごとにコンテンツデータの書き込みおよび読み出しを行うデータ処理装置であって、前記単位領域には前記コンテンツデータを格納した複数のパケットが記録されており、
前記複数のパケットを読み出す再生部と、
第（ｎ＋１）パケットから第（ｎ＋ｍ）パケット（ｎ、ｍ：１以上の整数）までに格納されたコンテンツデータを分割して、第１パケットから前記第（ｎ＋ｍ）パケットまでの複数のパケットに格納する制御部と、
前記第１パケットから前記（ｎ＋ｍ）パケットを含む複数のパケットを前記単位領域に書き込む記録部と
を備えたデータ処理装置。
【請求項２】
前記制御部は、分割された前記コンテンツデータを、前記第１パケットから前記第（ｎ＋ｍ）パケットまでの各パケットに順次格納する、請求項１に記載のデータ処理装置。
【請求項３】
前記制御部は、分割された前記コンテンツデータを、前記第１パケットの次の第２パケットから順次格納する、請求項１に記載のデータ処理装置。
【請求項４】
前記第（ｎ＋１）パケットが、前記データストリームの再生を管理するための管理情報を格納したパケットであるときにおいて、前記制御部は、前記管理情報を前記第１パケットに格納する、請求項３に記載のデータ処理装置。
【請求項５】
各パケットのパケット長は所定長に固定されており、
前記制御部は、前記コンテンツデータとともに、前記コンテンツデータとは異なるパディングデータを前記少なくとも１つのパケットに格納することにより、前記少なくとも１つのパケットのパケット長を前記所定長に調整する、請求項１に記載のデータ処理装置。
【請求項６】
前記制御部は、分割された前記コンテンツデータを、前記第１パケットから前記第（ｎ＋ｍ）パケットまでの２以上のパケットに格納する、請求項５に記載のデータ処理装置。
【請求項７】
前記制御部は、前記パディングデータを含まないパケットと、前記パディングデータを含むパケットとをそれぞれ１以上生成する、請求項６に記載のデータ処理装置。
【請求項８】
各パケットには、前記パケットの処理時刻を示す時刻情報が格納されており、
前記制御部は、前記第（ｎ＋１）パケットから前記第（ｎ＋ｍ）パケットまでのパケットのうち、前記コンテンツデータを最初に格納していた第ｐパケット（ｐ：ｎ＋１≦ｐ≦ｎ＋ｍを満たす整数）の時刻情報を取得し、前記時刻情報を、分割された前記コンテンツデータが最初に格納される第ｑパケット（ｑ：１≦ｑ≦ｐ−１を満たす整数）の処理時刻を示す時刻情報に変更して前記第ｑパケットに格納する、請求項１に記載のデータ処理装置。
【請求項９】
各パケットのパケット長は所定長に固定されており、
前記制御部は、前記第ｐパケットと前記第ｑパケットとの間のパケット数、および、前記データストリームのデータレートに基づいて、前記時刻情報を変更する、請求項８に記載のデータ処理装置。
【請求項１０】
各パケットには、前記データストリームのデータレートを示すレート情報が格納されており、
前記制御部は、前記第ｐパケット内のレート情報に基づいて前記時刻情報を変更する、請求項９に記載のデータ処理装置。
【請求項１１】
前記制御部は、前記レート情報に基づいて特定される１パケットあたりの転送時間および前記パケット数に基づいて、前記時刻情報を変更する、請求項１０に記載のデータ処理装置。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、メディアに記録されたコンテンツを編集する技術に関する。
【背景技術】
【０００２】
近年、ＤＶＤ等の光ディスク、ハードディスク等の磁気ディスク、半導体メモリ等のメディアにコンテンツのデジタルデータを書き込み、保存できるデジタル機器（光ディスクレコーダ、カムコーダ等）の普及が進んでいる。このようなコンテンツは、例えば、放送された番組やカムコーダ等によって撮影された映像および音声である。
【０００３】
近年はＰＣにもコンテンツの記録、再生および編集機能が実装されており、ＰＣも上述のデジタル機器に含めることができる。ＰＣでは、文書データなどのデータを記録するために、従来からハードディスク、光ディスク、半導体メモリ等のメディアが利用されている。したがって、そのようなメディアでは、ＰＣと連携可能なデータ管理構造、例えばＦＡＴ（File Allocation Table）を用いたファイルシステムが採用されている。現在多く利用されているＦＡＴ３２ファイルシステムでは、最大４ギガバイトのサイズを有するファイルを取り扱うことができ、また最大記録可能容量が２テラバイトのメディアを管理することができる。
【０００４】
メディアの最大記録可能容量の増加に伴い、記録されるコンテンツの再生時間が長くなっている。光ディスク、ハードディスク、半導体メモリ等はいわゆるランダムアクセスが可能なメディアであるため、そのようなメディアに長時間のコンテンツのデータストリームを格納するときには、コンテンツの任意の位置から再生できると便利である。
【０００５】
たとえば特許文献１では、データストリームの先頭から一定の時間間隔ごとに、再生時刻とその時刻に再生されるＡＶデータの格納アドレスとの対応を規定したタイムマップ情報が生成されている。ユーザ指定された開始時刻、終了時刻それぞれを、タイムマップ情報を参照して開始アドレス、終了アドレスに変換し、そのアドレスに格納されているデータを読み出すことにより、その時刻からコンテンツを再生することが可能になっている。
【０００６】
近年のデジタル機器の中には、ランダムアクセスが可能なメディアに記録されたコンテンツの編集機能を有するものが存在する。この機能は、ユーザがコンテンツの好みの箇所を残すために利用されるだけでなく、不要部分を削除してメディアの空き領域を確保するために利用される。
【０００７】
たとえばカムコーダを使用して屋外で録画を行っていたときに、想定以上に空き領域が無くなることがある。このとき、それまで録画したコンテンツのうちの不要部分を削除すると空き領域を確保することができる。これにより、新たなコンテンツをさらに続けてそのメディアに記録できる。
【０００８】
データストリームの部分削除等の編集処理を行うときの留意点は、データストリームの構成単位と、メディアの記録単位との関係である。いま、データストリームが固定長のパケット単位で構成されており、メディアではパケット長とは異なるサイズの論理ブロック単位でデータが記録され、管理されるとする。データストリームの一部削除時に、論理ブロック単位内の一部のデータが削除の対象とされることがある。このときには、論理ブロック単位に収まるようにデータストリームのパケットの配置を調整する必要がある。
【０００９】
たとえば特許文献２は、データストリームの部分削除時にデータストリームのパケットを論理ブロック単位に格納する一例を開示している。具体的には特許文献２では、データストリームの部分削除後に残されるパケットのデータ長を論理ブロックのブロック長に合致させるために、ダミーデータのみを含むパケット（ヌルパケット）が挿入されている。
【特許文献１】特開平１１−１５５１３０号公報
【特許文献２】国際公開第０１／００４８９３号パンフレット（図１３〜図１６）
【発明の開示】
【発明が解決しようとする課題】
【００１０】
上述のヌルパケットを挿入する方法は、ヌルパケットを検出し、解釈できるデジタル機器においては有効であるが、それができないデジタル機器においては不都合が生じる。具体的には、コンテンツの再生時に、そのデータストリームのヌルパケットを契機として再生される映像が乱れ、最悪の場合には再生が停止することがある。その理由は、機器がヌルパケットおよびそのダミーデータをビデオデータとして誤って解釈するためである。
【００１１】
特に、近年のほとんどのデジタル機器が対応するＭＰＥＧ規格によれば、デジタル機器はグループ・オブ・ピクチャ（ＧＯＰ）と呼ばれる再生単位の先頭から順に映像を復号化する必要がある。しかし、再生単位の先頭にダミーデータが存在すると、もはやそれ以後のビデオデータの復号化ができなくなり、再生が停止する。
【００１２】
このようなダミーデータの挿入を避けるため、削除されたデータに続くデータを順次繰り上げて、論理ブロック先頭から開始されるようにデータストリームを書き換える方法も考えられる。しかし、この方法では数ギガバイトにわたる書き換えが必要となることもあり非常に時間を要するため、適切ではない。書き換え時間は、データストリームの中間部分の削除（部分削除）処理よりも先頭部分を含む削除（前方削除）処理の方が長くなる。
【００１３】
なお、映像の符号化データや音声の符号化データのデータサイズを意図的に増加させて、論理ブロック先頭から開始されるようにデータストリームを修正する方法も考えられる。しかし、その方法にはデータサイズの細かな制御のために複雑な処理が必要となる。そればかりでなく、データサイズが変化することにより、データストリームの先頭から、ＩＳＯ／ＩＥＣ１３８１８−１規格のシステムターゲットデコーダのバッファシミュレーションを再実施する必要が発生し、データストリーム全体の修正が必要になるため、適切ではない。
【００１４】
本発明の目的は、データストリームの編集処理時間を短縮化できる装置等を提供することである。特に、データストリームが固定長のパケットから構成され、かつ記録領域の割り付けサイズが固定長のパケットサイズよりも大きく整数倍である場合に、データストリームを書き換えることなく、編集処理を高速に実行できる装置および方法を提供することである。
【課題を解決するための手段】
【００１５】
本発明によるデータ処理装置は、記録媒体の単位領域ごとにコンテンツデータの書き込みおよび読み出しを行う。前記単位領域には前記コンテンツデータを格納した複数のパケットが記録されている。前記データ処理装置は、前記複数のパケットを読み出す再生部と、第（ｎ＋１）パケットから第（ｎ＋ｍ）パケット（ｎ、ｍ：１以上の整数）までに格納されたコンテンツデータを分割して、第１パケットから前記第（ｎ＋ｍ）パケットまでの複数のパケットに格納する制御部と、前記第１パケットから前記（ｎ＋ｍ）パケットを含む複数のパケットを前記単位領域に書き込む記録部とを備えている。
【００１６】
前記制御部は、分割された前記コンテンツデータを、前記第１パケットから前記第（ｎ＋ｍ）パケットまでの各パケットに順次格納してもよい。
【００１７】
前記制御部は、分割された前記コンテンツデータを、前記第１パケットの次の第２パケットから順次格納してもよい。
【００１８】
前記第（ｎ＋１）パケットが、前記データストリームの再生を管理するための管理情報を格納したパケットであるときにおいて、前記制御部は、前記管理情報を前記第１パケットに格納してもよい。
【００１９】
各パケットのパケット長は所定長に固定されていてもよい。このとき前記制御部は、前記コンテンツデータとともに、前記コンテンツデータとは異なるパディングデータを前記少なくとも１つのパケットに格納することにより、前記少なくとも１つのパケットのパケット長を前記所定長に調整してもよい。
【００２０】
前記制御部は、分割された前記コンテンツデータを、前記第１パケットから前記第（ｎ＋ｍ）パケットまでの２以上のパケットに格納してもよい。
【００２１】
前記制御部は、前記パディングデータを含まないパケットと、前記パディングデータを含むパケットとをそれぞれ１以上生成してもよい。
【００２２】
各パケットには、前記パケットの処理時刻を示す時刻情報が格納されていてもよい。このとき前記制御部は、前記第（ｎ＋１）パケットから前記第（ｎ＋ｍ）パケットまでのパケットのうち、前記コンテンツデータを最初に格納していた第ｐパケット（ｐ：ｎ＋１≦ｐ≦ｎ＋ｍを満たす整数）の時刻情報を取得し、前記時刻情報を、分割された前記コンテンツデータが最初に格納される第ｑパケット（ｑ：１≦ｑ≦ｐ−１を満たす整数）の処理時刻を示す時刻情報に変更して前記第ｑパケットに格納してもよい。
【００２３】
各パケットのパケット長は所定長に固定されていてもよい。このとき前記制御部は、前記第ｐパケットと前記第ｑパケットとの間のパケット数、および、前記データストリームのデータレートに基づいて、前記時刻情報を変更してもよい。
【００２４】
各パケットには、前記データストリームのデータレートを示すレート情報が格納されていてもよい。このとき前記制御部は、前記第ｐパケット内のレート情報に基づいて前記時刻情報を変更してもよい。
【００２５】
前記制御部は、前記レート情報に基づいて特定される１パケットあたりの転送時間および前記パケット数に基づいて、前記時刻情報を変更してもよい。
【発明の効果】
【００２６】
本発明によれば、記録媒体の単位領域ごとにコンテンツデータの書き込みおよび読み出しを行う機器においてコンテンツデータを編集する際に、単位領域内の第（ｎ＋１）パケットから第（ｎ＋ｍ）パケット（ｎ、ｍ：１以上の整数）までに格納されたコンテンツデータを分割して、第１パケットから第（ｎ＋ｍ）パケットまでの複数のパケットに格納する。そして、第１パケットから第（ｎ＋ｍ）パケットは記録媒体の単位領域に記録し直される。これにより、当初の第１パケットから第ｎパケットまでのコンテンツデータが実質的に削除される。
【００２７】
書き換え後の単位領域にはダミーデータのみを含むヌルパケットが含まれないため、ヌルパケットに対応していない機器でもそのコンテンツデータを解釈してコンテンツを再生できる。これにより、どのような機器であってもヌルパケットに起因してコンテンツの再生の乱れが生じたり、再生処理が停止することはない。
【００２８】
また、単位領域を超えてコンテンツデータを書き換える必要もないため、後続の全てのデータを削除されたデータ相当だけ前にシフトする必要もない。よって編集処理に要する時間が著しく短縮化される。
【発明を実施するための最良の形態】
【００２９】
以下、添付の図面を参照しながら、本発明によるデータ処理装置の実施形態を説明する。
【００３０】
図１は、本実施形態によるレコーダ１０の構成を示す。レコーダは、映像および音声を含む動画のデータストリーム（動画ストリーム）をメモリカード１３０に書き込む機能（録画機能）、メモリカード１３０に書き込まれた動画ストリームを読み出して、動画を再生する機能（再生機能）およびメモリカード１３０に書き込まれた動画ストリームを読み出して、動画を編集する機能（編集機能）を有する。レコーダ１０は、たとえば持ち運び可能なカムコーダ、テレビ放送番組等を録画する据え置き型の記録装置である。
【００３１】
以下、レコーダ１０の構成要素を説明する。レコーダ１０は、映像信号入力部１００と、音声信号入力部１０２と、映像表示部１１０と、音声出力部１１２と、ＭＰＥＧエンコーダ１７０と、ＭＰＥＧデコーダ１７１と、メディア制御部１７５と、システム制御部１８０と、ＣＰＵ１８１とを有している。
【００３２】
レコーダ１０には、メモリカード１３０が取り外し可能に挿入され、メモリカード１３０に動画を録画できる。なお、メモリカード１３０はレコーダ１０の必須の構成要素ではない。
【００３３】
本明細書においては、メモリカード１３０は、ＰＣにおいて一般的に用いられているＦＡＴ（ＦＡＴ１６またはＦＡＴ３２）ファイルシステムでフォーマットされているとする。メモリカード１３０において、空き領域の管理単位であり、かつ領域の書き込み／読み出し単位である論理ブロック（クラスタ）のデータサイズは、メモリカードの記録容量に応じて定められている。たとえばメモリカードの記録容量が１Ｇバイト以下の場合には各クラスタのデータサイズは１６ｋバイトであり、１Ｇバイトを超える場合には３２ｋバイト以上であるとする。ただし、１クラスタが１６ｋバイトのときは、１クラスタは３２個のセクタから構成され、１クラスタが３２ｋバイトのときは、１クラスタは６４個のセクタから構成される。
【００３４】
映像信号入力部１００は、たとえばＣＣＤカメラや、アンテナ（図示せず）と接続された映像入力端子（図示せず）である。音声信号入力部１０２は、たとえばマイクや、アンテナ（図示せず）と接続された音声入力端子（図示せず）である。
【００３５】
ＭＰＥＧエンコーダ１７０（以下「エンコーダ１７０」と記述する。）は映像圧縮部１０１と音声圧縮部１０３とシステムエンコード部１０４とを有している。映像圧縮部１０１は、映像信号入力部１００から映像信号を受け取り、ＭＰＥＧ規格に基づいて圧縮符号化する。音声圧縮部１０３は、音声信号入力部１０２から映像信号を受け取り、ＭＰＥＧ規格に基づいて（圧縮）符号化する。その結果、ビデオデータおよびオーディオデータが出力される。
【００３６】
システムエンコード部１０４は、ビデオデータおよびオーディオデータをインターリーブして動画ストリームを生成する。より具体的には、システムエンコード部１０４は、ビデオデータおよびオーディオデータをそれぞれ格納したパケットを生成し、そのパケットを配列して動画ストリームを生成する。このとき、さらに他のデータ（文字データ、管理情報など）もパケット化されて動画ストリームの一部として配列され得る。
【００３７】
メディア制御部１７５は、記録部１２０および再生部１２１を有しており、それぞれ、メモリカード１３０に対する動画ストリームの書き込みおよび読み出しを制御する。
【００３８】
レコーダ１０の他の構成要素を説明する。ＭＰＥＧデコーダ１７０（以下「デコーダ１７１」と記述する。）は、映像伸長部１１１と音声伸長部１１３とシステムエンコード部１１４とを有している。処理の順序で説明すると、システムエンコード部１１４は動画ストリーム、すなわち上述のプログラムストリームをパケットの種類に応じて分離し、ビデオデータのパケットを映像伸長部１１１に送り、オーディオデータのパケットを音声伸長部１１３に送る。映像伸長部１１１は、ビデオデータをＭＰＥＧ規格に基づいて伸長し、映像信号出力部１１０に送る。音声伸長部１１３は、オーディオデータをＭＰＥＧ規格等に基づいて伸長し、音声信号出力部１１２に送る。
【００３９】
映像信号出力部１１０は、たとえばレコーダ１０がカムコーダのときには液晶表示画面、録画機のときには映像信号を出力する端子である。音声信号出力部１１２は、たとえばスピーカや音声信号を出力する端子である。
【００４０】
システム制御部１８０は、ＣＰＵ１８１とＲＯＭ１８２とＲＡＭ１８３とを有している。ＣＰＵ１８１は、たとえばＲＯＭ１８２に格納されたコンピュータプログラムを読み出し、ＲＡＭ１８３上に展開して実行することにより、各種の機能を実現できる。たとえばＣＰＵ１８１は、連続データ領域検出部１６０、記録制御部１６１、再生制御部１６２、論理ブロック管理部１６３、編集制御部１６４として機能する。以下では、ＣＰＵ１８１によって実現する各機能を独立した構成要素として取り扱う。各構成要素間のデータの授受は、プログラム間のデータの受け渡しに相当する。
【００４１】
動画の録画時には、記録制御部１６１はプログラムストリームの記録を開始する前に連続データ領域検出部１６０に指示して、空き領域が例えば４Ｍバイト分だけ連続している領域を捜させる。連続データ領域検出部１６０はあらかじめ読み出した空き領域に関するＦＡＴ情報を参照して連続した空き領域を探索する。そして記録制御部１６１は、検出された空き領域上にプログラムストリームの記録を開始するよう記録部１２０に指示する。そして、ひとつの連続した空き領域へのプログラムストリームの書込みが終わるまでに、連続した空き領域を継続的に探索しプログラムストリームの記録を継続する。また、所定の時間間隔（例えば１０秒）でプログラムストリームに対する管理データの書込みを行う。
【００４２】
また動画の再生時は、ユーザが再生すべきコンテンツを選択すると、再生制御部１６２は再生部１２１に指示して、コンテンツに対応するデータストリームの管理情報を管理ファイルから読み出させる。そして再生制御部１６２は、その管理ファイルに記載されたアドレス情報を参照してメモリカード１３０からさらにプログラムストリームを読み出すよう、再生部１２１に指示する。
【００４３】
動画の編集時において、編集制御部１６４は、たとえば記録済みのコンテンツの一部に対する削除の指示をユーザから受け取る。このとき編集制御部１６４は、再生部１２１に対して指示して編集対象のデータを読み出させる。編集対象のデータはメモリカード１３０の論理ブロック単位で読み出される。
【００４４】
編集制御部１６４は、読み出されたデータのうちから削除するべき部分を特定し、その部分を削除する。その後、編集制御部１６４は削除されなかったデータに対して後述の処理を行ってパック内のデータサイズを調整し、メモリカード１３０のクラスタの先頭からビデオパックを配置するよう記録部１２０に指示する。
【００４５】
本実施形態においては、エンコーダ１７０によって生成され、メディア制御部１７５によってメモリカード１３０に書き込まれる動画ストリームはＭＰＥＧ２規格のプログラムストリームであるとする。プログラムストリームは、「パック」と呼ばれる固定長のデータ単位から構成される。「パック」はパケットの１つの例示的な形態として知られている。
【００４６】
ここで図２を参照しながら、プログラムストリームを説明する。メモリカード１３０に書き込まれたプログラムストリームは、データストリームファイルとして管理される。図２は、データストリームファイル２０のデータ構造を示す。以下に説明するデータ構造は、たとえばＳＤメモリカード等のメモリカード１３０、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ等の光ディスクに動画を記録するためのＤＶＤビデオレコーディング規格に準拠している。
【００４７】
データストリームファイル２０は、たとえばＭＰＥＧプログラムストリーム２１に示すようなＶＯＢ（Ｖｉｄｅｏ  Ｏｂｊｅｃｔ；ビデオオブジェクト）を複数含んでいる。そして各ＶＯＢは、１以上のビデオオブジェクトユニット（Ｖｉｄｅｏ  Ｏｂｊｅｃｔ  Ｕｎｉｔ：以下「ＶＯＢＵ」という。）から構成される。
【００４８】
各ＶＯＢＵは、２０４８バイト単位のＭＰＥＧプログラムストリームの下位階層であるパックから構成されており、映像の再生時間にして０．４〜１秒分のデータを含む。
【００４９】
以下、ＶＯＢＵ２２を例に挙げて説明する。ＶＯＢＵ２２は、圧縮されたビデオデータが格納されたビデオパック（Ｖ＿ＰＣＫ）２３と、圧縮されたオーディオデータが格納されたオーディオパック（Ａ＿ＰＣＫ）２４の２種類を含んでいる。ＶＯＢＵ２２内の全ビデオパック（Ｖ＿ＰＣＫ）２３のビデオデータを再生すると、上述の０．４〜１秒の映像になる。また、ＶＯＢＵ２２内のオーディオデータは、各音声フレームの復号に利用される。１つの音声フレームのデータがＶＯＢＵ境界をまたいで格納されることはない。
【００５０】
なお、各ＶＯＢＵの先頭にはリアルタイムデータ情報パック（ＲＤＩ＿ＰＣＫ）が記録されてもよい。ＲＤＩパックには、再生を管理するための管理情報（たとえばレターボックス情報）が必要に応じて格納される。
【００５１】
本実施の形態のプログラムストリームには、上述のパック以外の他の種類のパックは含まれないとする。また、ビデオパックおよびオーディオパック内には少なくとも１バイトのビデオデータおよびオーディオデータを格納したＰＥＳパケットが含まれるとする。ひとつのビデオパックおよびオーディオパック内には、最大１個のパディングストリームを含むＰＥＳパケットを含むことが可能である。このＰＥＳパケットはパック長を２０４８バイトに調整するために設けられ、パディングストリームを含むことを示すＰＥＳヘッダおよびパディングストリームを含んでいる。
【００５２】
プログラムストリーム２１には、システム時刻基準ＳＣＲ、映像／音声の復号時刻情報（ＤＴＳ）および出力時刻情報（ＰＴＳ）等の時刻情報が格納されている。システム時刻基準ＳＣＲは、再生装置のＳＴＣレジスタに基準値を設定するために利用される。この基準値に基づいて同期信号ＳＴＣが生成され、同期信号ＳＴＣの値とデコード時刻情報（ＤＴＳ）の値とが一致するタイミングで映像および音声がそれぞれ復号化される。そして同期信号ＳＴＣの値と出力時刻情報（ＰＴＳ）の値とが一致するタイミングで、映像および音声がそれぞれ出力される。本実施形態においては、ひとつの連続したプログラムストリーム（ＶＯＢ）中のシステム時刻基準ＳＣＲ、映像の復号時刻情報（ＤＴＳ）および出力時刻情報（ＰＴＳ）の各値は所定の周期で連続的に変化しているとする。
【００５３】
各ＶＯＢＵの先頭のビデオパック２３は、パックヘッダ２５およびパックデータ（ビデオデータ）２６を含んでいる。さらに、ビデオデータ２６はシーケンスヘッダ２８、ＧＯＰヘッダ２９、および圧縮されたＩピクチャデータ３０を含んでいる。図においては、さらに他のＰＥＳヘッダおよびＰピクチャフレームデータ３１が示されている。
【００５４】
なお、Ｉピクチャデータのデータサイズは一般に大きく、２０４８バイトを大きく超えることがある。よって、ビデオデータ２６にはＩピクチャデータの一部（たとえば先頭部分）しか格納されないこともある。
【００５５】
Ｉピクチャ３２からピクチャ３３までの複数枚のピクチャが１つのグループ・オブ・ピクチャ（ＧＯＰ）を構成している。ＧＯＰとは、単独で再生され得る映像フレームであるＩピクチャ３２と、次のＩピクチャの直前のピクチャ３３までの、Ｐピクチャおよび／またはＢピクチャを含む複数の映像フレームをまとめた再生単位である。
【００５６】
次に、図３から図５までを参照しながら、本実施形態によるレコーダ１０の特徴的な処理を説明する。
【００５７】
図３（ａ）はレコーダ１０による編集前のプログラムストリーム３５を示し、図３（ｂ）はレコーダ１０による編集後のプログラムストリーム３６を示す。理解を容易にするため、図３（ａ）および（ｂ）にはビデオパックのみが示されている。
【００５８】
まず図３（ａ）を参照する。前提として、プログラムストリーム３５を構成する各パックには、ダミーデータのみが格納されたヌルパケットは含まれていないとする。
【００５９】
ユーザが、たとえば動画の先頭から所定の場面までを削除したいとして指定すると、プログラムストリーム３５の先頭からその場面に対応するデータまでの範囲が削除範囲Ｄとして特定される。この削除範囲Ｄは複数のクラスタに跨がっているとする。そして、最後のクラスタの先頭から順にビデオパック＃１、＃２、＃３・・・が配置されており、削除範囲Ｄの終端はビデオパック＃２であるとする。
【００６０】
本実施形態によるレコーダ１０の特徴のひとつは、最後のクラスタに関して、ビデオパック＃１、＃２内のビデオデータＶ１およびＶ２を削除するとともに、削除範囲Ｄ以降に配置されていたビデオパック＃３のビデオデータＶ３を分割して、その一部をそれぞれ新たなビデオデータとして格納したビデオパック＃１、＃２を生成することにある。ビデオパック＃３には、当初のビデオデータの一部が残される。
【００６１】
ここで図３（ｂ）を参照する。図３（ｂ）によれば、ビデオパック＃３のビデオデータＶ３がビデオデータＶ３−１、Ｖ３−２およびＶ３−３に分割されて、それぞれクラスタ先頭のビデオパック＃１、次のビデオパック＃２、および、ビデオパック＃３に格納されていることが理解される。なお、各パックのデータサイズを調整するため、ダミーデータ（スタッフィングバイトまたはパディングストリーム）が利用されている。
【００６２】
編集後のクラスタにはダミーデータのみを含むヌルパケットは含まれていない。そして、ＭＰＥＧ規格上許容されているパディングストリームが利用されるため、少なくともＭＰＥＧ規格に対応さえしていれば、どのような機器であっても映像を乱れなく確実に再生できる。
【００６３】
また、単位領域を超えてコンテンツデータを書き換える必要もないため、削除されたデータ相当量だけ後続の全データを前にシフトする必要もない。よってシフトする場合と比較すると、編集処理に要する時間が著しく短縮化される。
【００６４】
なお、ビデオデータＶ１およびＶ２の削除処理は、実際にデータを削除した後にビデオパック＃１および＃２にビデオデータＶ３−１およびＶ３−２を格納してもよいし、ビデオパック＃１および＃２にビデオデータＶ３−１およびＶ３−２を上書きしてもよい。
【００６５】
図４および図５を参照しながら、削除編集前のビデオパック＃３と、削除編集後のビデオパック＃１〜＃３を詳細に説明する。
【００６６】
図４は、削除編集前のビデオパック＃３のデータ構造を示す。編集前のビデオデータＶ３は２００２バイトである。
【００６７】
レコーダ１０は削除すべき範囲Ｄを特定した後、ビデオデータＶ３を、２０００バイトのビデオデータＶ３−１と、１バイトのビデオデータＶ３−２と、１バイトのビデオデータＶ３−３とに分ける。このビデオデータＶ３−１はビデオパック＃１に移動され、データＶ３−２はビデオパック＃２に移動される。一方、ビデオデータＶ３−３はビデオパック＃３に残される。なお、パックヘッダは２４バイト、ＰＥＳヘッダは２２バイトである。パックヘッダ、ＰＥＳヘッダおよびビデオデータＶ３のデータサイズの合計は２０４８バイトである。
【００６８】
パックヘッダにはパック開始コード（０ｘ００００、０ｘ０１ＢＡ）、ＳＣＲ（システム・クロック・リファレンス）フィールド、多重化ビットレート（Ｐｒｏｇｒａｍ  Ｍｕｘ  Ｒａｔｅ）フィールド、システムヘッダ等が含まれる。
【００６９】
図５（ａ）〜（ｃ）は、それぞれ削除編集後のビデオパック＃１、＃２および＃３のデータ構造を示す。図５（ａ）に示されるビデオパック＃１には、２０００バイトのビデオデータＶ３−１が格納されている。このとき、パックヘッダのデータサイズは２４バイトであり、ＰＥＳヘッダのデータサイズも２４バイトである。
【００７０】
ＤＶＤビデオレコーディング規格では、パックのデータサイズを調整するために、ＰＥＳヘッダにスタッフィングバイトを付加することが許容されている。スタッフィングバイトは、予め定められたダミーデータとして機能し、意味を持たない値として、たとえば“０ｘＦＦ”（１６進数）等のバイトデータが予め定められている。
【００７１】
本実施形態においては、パックのデータサイズ（２０４８バイト）、パックヘッダのデータサイズ（２４バイト）、および、ビデオデータＶ３−１のデータサイズ（２０００バイト）が特定されているため、ＰＥＳヘッダのデータサイズも２４バイトに特定される。その結果、パック長を２０４８バイトに調整するために、当初の２２バイトのＰＥＳヘッダに対して２バイトのスタッフィングバイトが追加される。
【００７２】
図５（ｂ）および図５（ｃ）に示されるビデオパック＃２および＃３は、それぞれ２個のＰＥＳパケットを含む。ＰＥＳパケットは、ＰＥＳヘッダとその後のデータとから構成されるパケットである。
【００７３】
たとえばビデオパック＃２の１つ目のＰＥＳパケットには、１バイトのビデオデータＶ３−２が格納されている。２個目のＰＥＳパケットにはパディングストリームＰが格納されており、これによりパック長が調整されている。パディングデータもスタッフィングバイトと同様に、意味を持たない値として“０ｘＦＦ”（１６進数）等のバイトデータが定められている。ビデオパック＃２とビデオパック＃３との違いは、ビデオデータ値とＳＣＲ値のみである。
【００７４】
ビデオパック＃１（図５（ａ））ではスタッフィングバイトによってパックサイズを調整し、ビデオパック＃２および＃３（図５（ｂ）および（ｃ））ではパディングストリームＰによってパックサイズを調整している。その理由は、規格上、スタッフィングバイトとして調整可能なサイズの上限が定められており（たとえば７バイト以下等）、その上限によっては、スタッフィングバイトの挿入によってはパックサイズを調整できないケースがあるためである。また、スタッフィングバイトとパディングストリームとを同一のパック内に同時に設けることも規格上認められていないケースもある。これらのケースにおいては、調整すべきサイズが上限値よりも大きいときは、パック長をスタッフィングバイトによって調整するのではなく、パディングストリームによって調整すればよい。本実施形態においては、８バイト以上（例えば１ｋバイト）の場合は、２個目のＰＥＳヘッダを記録して、そのヘッダからパディングストリームＰを設けるとする。
【００７５】
ＰＥＳヘッダには、そのヘッダの後に格納されているデータに応じて個別のストリームＩＤが設定される。ビデオストリームのＰＥＳヘッダにはビデオストリームＩＤ（たとえば０ｘＥ０）が付加され、オーディオストリームのＰＥＳヘッダにはオーディオストリームＩＤ（たとえば０ｘＥ１）が付加される。これらは互いに異なる値である。そして本実施形態においては、パディングストリームＰのＰＥＳヘッダには、ビデオ／オーディオの各ストリームＩＤとはさらに異なるＩＤ（たとえば０ｘＢＥ）が設定される。
【００７６】
なお、ビデオパック＃２および＃３に格納されるビデオデータはそれぞれ１バイトとしたが、これは例である。ビデオデータは、たとえば１０バイトや１ｋバイトであってもよいし、ビデオパック＃２および＃３のビデオデータサイズもそれぞれ異なる値であってもよい。その値に応じて、スタッフィングバイトまたはパディングストリームを利用してパック長を調整すればよい。
【００７７】
削除編集処理に関連して、ＳＣＲ値を変更する必要がある点にも留意する必要がある。図４のパックヘッダのデータ構造に示されるように、各パックヘッダにはＳＣＲ値が付加されている。削除編集前のビデオパック＃３のビデオデータには、ビデオパック＃１および＃２の後に読み出されることを前提としたＳＣＲ値が設定されている。レコーダ１０は削除編集処理において、ビデオパック＃１のパックヘッダに対して、削除編集前のビデオパック＃３に設定されていたＳＣＲ値よりも２パック分のデータ転送時間だけ早いＳＣＲ値を設定する。これにより、再生時の動作基準時刻を２パック分のデータ転送時間だけ早めることができる。
【００７８】
次に、図６および図７を参照しながら、削除編集前後のプログラムストリーム、ＶＯＢＵおよびクラスタの関係を詳細に説明する。
【００７９】
図６は、削除編集処理前のプログラムストリーム３５とＶＯＢＵとＦＡＴファイルシステムのクラスタの配置に関する対応関係を示す。図６の（ａ）は削除編集前のプログラムストリーム３５の構成を示し、（ｂ）はＶＯＢＵの配列を示し、（ｃ）はＦＡＴファイルシステムのクラスタの配列を示す。
【００８０】
ユーザによって指定された削除範囲Ｄは、ビデオパック（Ｖ＿ＰＣＫ）＃２から前のパックであり、特定のＶＯＢの先頭からＶＯＢＵ＃（ｉ−１）までであるとする。よって、削除処理後はＶＯＢＵ＃ｉ以降からＶＯＢ末尾までのデータが残される。ＦＡＴファイルシステムで管理されるクラスタ＃Ｊにおいては、先頭の２個のＶ＿ＰＣＫ（合計４キロバイト）が削除される。
【００８１】
なお、ビデオパック＃３はＶＯＢＵ＃ｉの先頭パックであるため、そのビデオデータには図２に示すようにシーケンスヘッダ、ＧＯＰヘッダ、Ｉピクチャのデータが含まれている。
【００８２】
図７は、削除編集処理後のプログラムストリーム３６とＶＯＢＵとＦＡＴファイルシステムのクラスタの配置に関する対応関係を示す。図７の（ａ）は削除編集後のプログラムストリーム３６の構成を示し、（ｂ）はＶＯＢＵの配列を示し、（ｃ）はＦＡＴファイルシステムのクラスタの配列を示す。
【００８３】
プログラムストリーム３６のビデオパック＃１〜＃３のデータ構造は、それぞれ図５（ａ）〜（ｃ）に示すとおりである。当初のビデオパック＃１および＃２は一旦削除され、その後、編集処理前のビデオパック＃３に格納されていたビデオデータの一部を新たに格納したパックとして生成されている。図７においては、ビデオパック＃１および＃２を「追加されたＶパック」として示している。
【００８４】
一方、ビデオパック＃１よりも前に配置されていたデータ、すなわちクラスタ＃ｊよりも前のクラスタに配置されていた範囲ｄ内のデータは、実際に削除されている。削除編集処理の結果、当初のＶＯＢＵ＃ｉはクラスタ＃Ｊの先頭から配置されている。
【００８５】
なお、クラスタ＃Ｊ内のビデオパック＃３以降の後続パックは編集処理前後で変化はない。指示された範囲Ｄを埋めるように後続のプログラムストリームのデータを移動させる必要はないため、そのような移動を行う場合と比較すると、処理は非常に高速である。
【００８６】
次に、図８を参照しながら、上述の処理を行うレコーダ１０の処理手順を説明する。図８は、レコーダ１０の削除編集処理の手順を示す。以下の処理は、主として図１のシステム制御部１８０全体、より特定的にはＣＰＵ１８１によって実行される。ただし、以下の説明ではＣＰＵ１８１によって実現される機能的な構成要素を処理の主体として説明する。
【００８７】
ステップＳ８１において、編集制御部１６４はユーザに編集モード画面を提示して、どのプログラムストリームに対して削除処理を行うかの指示をユーザから受け、さらにそのプログラムストリームの削除すべき部分と、残すべき部分の境界を指定させる。
【００８８】
たとえば、編集モード画面において、ユーザが編集を希望するコンテンツを指定すると、編集制御部１６４はメディア制御部１７５に対してそのプログラムストリームの読み出しを指示する。デコーダ１７１がそのプログラムストリームを復号化すると、映像信号出力部１１０および音声信号出力部１１２は映像および音声を出力する。
【００８９】
編集モード画面に映像および音声が出力され始めると、ユーザは指定すべき場面が表示されたときに、リモコン等の決定ボタンを押す。これにより、編集制御部１６４はユーザが選択した箇所がある１個のＶＯＢ内のＶＯＢＵ＃（ｉ−１）とＶＯＢＵ＃ｉの境界であることを検出することができる。以下では、ユーザはさらにその境界（編集点）から前に存在する全てのデータを削除するよう指定したとする。これにより、ユーザが削除を指示した範囲Ｄが特定される。
【００９０】
次のステップＳ８２において、編集制御部１６４は編集点がクラスタの先頭に一致するか否かを判断する。編集点がクラスタの先頭に一致しないときにはステップＳ８３に進み、先頭に一致するときにはステップＳ８７に進む。
【００９１】
ステップＳ８３において、削除範囲直後のビデオパックを読み出す。このビデオパックは、上述の説明におけるビデオパック＃３（図３、４、６）に対応する。なお、各ＶＯＢＵの先頭アドレスはプログラムストリーム毎に全て管理ファイルに記録されている。よって、この管理ファイルを参照することにより、ＶＯＢＵ先頭のビデオパック＃３のデータを取り出すことは容易である。管理ファイルに関しては、図９、図１０等を参照しながら後述する。
【００９２】
次のステップＳ８４においては、ビデオパック＃０が記録されているクラスタ＃Ｊ上で、削除されるパック数を求める。このパック数は、上述の説明においては、ビデオパック＃１および＃２の２つである。
【００９３】
パック数を求めるための計算は以下のとおりである。まず編集制御部１６４は、ＶＯＢＵ＃ｉのデータストリームファイル先頭からのアドレスオフセット値（差分値）をクラスタサイズ（たとえば３２ｋバイト）で除算する。その後、その余り値をさらに２０４８バイトで除算する。これにより、パック数が得られる。
【００９４】
その後編集制御部１６４は、ワークメモリとして機能するＲＡＭ１８３上で、ビデオパック＃３のビデオデータを、クラスタ＃Ｊ上で削除された後の２パックにも分割して格納できるように準備する。つまり、図３（ｂ）および図７（ａ）に示すように、編集前のビデオパック＃３のビデオデータを、ビデオパック＃１、およびビデオパック＃２に分配するためのビデオデータの分割処理を行う。
【００９５】
なお、ＶＯＢＵ＃ｉのデータストリームファイル先頭からのオフセット値は管理ファイル内に格納された情報から算出可能であるとする。例えば、管理ファイル内に格納されたＶＯＢＵのデータサイズ（後述する図１０）を累計すれば、オフセット値を算出できる。
【００９６】
次のステップＳ８５では、編集制御部１６４は、ＲＡＭ１８３上のビデオパック＃１および＃２の各パックヘッダにＳＣＲ値を設定する。すなわち編集制御部１６４は、ビデオパック＃３のＳＣＲ値を基準として、ビデオパック＃１には２パックのデータ転送時間だけ早いＳＣＲ値を設定し、ビデオパック＃２には１パックのデータ転送時間だけ早いＳＣＲ値を設定する。それぞれ、ビデオパック＃３のＳＣＲ値から２パックまたは１パックのデータ転送時間に対応するＳＣＲ値を減算すればよい。
【００９７】
具体的には、パック１つのデータ転送時間に対応するＳＣＲ値は、プログラムストリームのデータ転送速度（たとえば１０．０８Ｍｂｐｓ）に対するパックデータ長（２０４８バイト）のデータが転送される時間を２７ＭＨｚのクロック値で表現した値として求められる。具体的には、（２０４８×８／１０．０８×１０６）＊２７＊１０６である。なお、データ転送速度を示す値は、パックヘッダの多重化ビットレート（Ｐｒｏｇｒａｍ  Ｍｕｘ  Ｒａｔｅ）フィールドに記述されているため、編集制御部１６４はその値をビデオパック＃３から読み出して、ＳＣＲ値の演算に利用することができる。
【００９８】
ステップＳ８６においては、編集制御部１６４はＲＡＭ１８３上に作成されたビデオパック＃１、＃２および＃３を、それぞれクラスタＪの先頭から格納するように、メディア制御部１７５に指示する。メディア制御部１７５の記録部１２０は、新たに生成されたビデオパック＃１、＃２および＃３を受け取って、メモリカード１３０のクラスタＪの先頭から書き込む。
【００９９】
ステップＳ８７において、編集制御部１６４は、データストリームのＦＡＴ情報を更新する。編集制御部１６４はメディア制御部１７５に指示して、削除されたプログラムストリーム部分を示すＦＡＴ情報を削除させ、削除編集処理後のプログラムストリーム（ＶＯＢ）がクラスタ＃Ｊの先頭から始まるようにＦＡＴ情報を設定させる。
【０１００】
なお、処理がステップＳ８２からステップＳ８７にジャンプしたときには、編集点より前に存在する全クラスタが削除されることを意味する。よって、編集点以降のクラスタが最初のクラスタになるようにＦＡＴ情報を更新すればよい。
【０１０１】
最後のステップＳ８８において、編集制御部１６４は、プログラムストリームの管理情報を修正する。管理情報は、メモリカード１３０に管理ファイルとして記録されている。
【０１０２】
具体的には、管理情報内のＶＯＢＵ＃ｉのデータサイズおよびＩフレームのデータサイズの値はパック数で記述されるため、編集制御部１６４はそれらの値を２パック分増加させる。編集処理によって、ＶＯＢＵ＃ｉの最初のビデオデータ（Ｉフレームのビデオデータ）の一部がビデオパック＃１および＃２に分割して格納され、管理情報を更新する必要が生じたためである。また、ＶＯＢＵ＃（ｉ−１）よりも前の部分が削除されたため、編集制御部１６４は関連する管理データも併せて削除する。
【０１０３】
図９は、メモリカード１３０のファイルシステムの階層構造を示す。管理ファイルＶＲ＿ＭＡＮＧＥＲ．ＩＦＯおよびデータストリームファイルＶＲ＿ＭＯＶＩＥ．ＶＲＯがルートディレクトリ下のＤＶＤ＿ＲＴＡＶディレクトリ内に格納されている。
【０１０４】
図１０は、プログラムストリームの管理情報の例を示す。管理情報はＶＯＢＵごとに生成されている。図１０によれば、各ＶＯＢＵに対応して管理情報が存在することが示されている。
【０１０５】
管理情報として、各ＶＯＢＵのＶＯＢＵデータサイズ、ＶＯＢＵの先頭のＩピクチャ終端を含むパックのアドレスオフセット値、およびＶＯＢＵに含まれる映像フィールド数が規定されている。なお図２から明らかなように、ＶＯＢが複数存在する場合には、図１０に示す管理情報の組がＶＯＢの数に応じて存在する。
【０１０６】
以上の構成により、レコーダ１０がデータストリームの一部を削除する際に、クラスタの先頭を含む部分が削除の対象となっている場合には、１クラスタ内のデータストリームのデータを処理するだけで、編集処理が完了する。これにより、編集処理の複雑さが大幅に軽減されるとともに、残されたデータを順次前に詰めて記録しなおす処理と比較すると著しく短時間で処理が完了する。
【０１０７】
本実施形態においては、データストリームの削除処理を説明した。しかしこれは例であり、他には、たとえばデータストリームを分割する処理にも適用できる。具体的には、分割点がクラスタの途中に存在するときには、その分割点直後のパックから後続のそのクラスタ内のパックを読み出して他のクラスタに書き込む必要がある。このとき、分割点直後のパックのビデオデータを利用して、そのクラスタの先頭からパックを配置すればよい。
【０１０８】
上述の実施形態では、削除範囲直後のＶＯＢＵに関し、先頭ビデオパック内のビデオデータを分割して編集後に得られるストリーム先頭の３つのビデオパックに分配して格納する例を説明した。しかし、本発明はその例（第１例とする）に限定されることはない。
【０１０９】
第２例として、削除範囲直後のＶＯＢＵではなく、その次のＶＯＢＵを対象として上述の処理を行ってもよい。このときは、削除範囲直後のＶＯＢＵがクラスタ＃Ｊの先頭に配置しなおした後で、続くＶＯＢＵ内の先頭ビデオパックのビデオデータを複数のビデオパックに分配する必要がある。ＳＣＲ値の変更が必要となるパックは、削除範囲直後のＶＯＢＵの各パックおよび続くＶＯＢＵにおいてビデオデータが分配されたパックである。分割されるビデオデータを格納していたパックの位置が編集後のデータストリーム先頭から離れるほど、ＳＣＲ値の変更が必要になるパック数が増加する。
【０１１０】
さらに第３例として、先頭ビデオパックをそのままクラスタの先頭に移動するとともに、２つ目以降のビデオパックのビデオデータを分割して複数のビデオパックに分配してもよい。ＳＣＲ値の変更が必要となるパックは、クラスタの先頭に移動された先頭ビデオパックと、ビデオデータが分配されたパックである。
【０１１１】
第３例による処理は、特にプログラムストリームの各ＶＯＢＵが、リアルタイムデータ情報パック（ＲＤＩパック）から始まるときに効果的である。図１１は、各ＶＯＢＵがＲＤＩパックから開始されるプログラムストリーム３７のパック配列とＶＯＢＵとＦＡＴファイルシステムのクラスタの配置に関する対応関係を示す。ＶＯＢＵ＃ｉの先頭はＲＤＩパック（ＲＤＩ＿ＰＣＫ）１１であることが理解される。
【０１１２】
このようなプログラムストリーム３７に対して、図１１に示すように削除範囲Ｄが指示されたとする。先の実施形態の説明と同様、クラスタ＃Ｊ先頭のビデオパック＃１および＃２が削除され、ＲＤＩパック１１およびビデオパック＃３の順にパックが配置されたＶＯＢＵ＃ｉが削除編集後に残されるとする。
【０１１３】
図１２は、削除編集処理後のプログラムストリーム３８とＶＯＢＵとＦＡＴファイルシステムのクラスタの配置に関する対応関係を示す。レコーダ１０が、図１２に示すプログラムストリーム３８を生成する手順は以下のとおりである。
【０１１４】
なお以下の処理は、レコーダ１０が図１１に示すクラスタ＃Ｊから複数のパックを読み出した後、ＲＡＭ１８３上で実行されるとして説明する。実行されるタイミングは、クラスタ＃Ｊより前のデータを実際に削除した後であってもよいし、削除する前であってもよい。
【０１１５】
まず編集制御部１６４は、編集前のＲＤＩパック１１を、ＲＤＩパック１２としてＲＡＭ１８３の記録領域に配置する。この移動は、存在していたビデオパック＃１をＲＤＩパック１２で上書きすることによって実現してもよいし、ビデオパック＃１を一旦削除してその後ＲＤＩパックを書き込むことによって実現してもよい。さらに読み出したクラスタ＃Ｊのデータを格納した領域とは異なる領域において行ってもよい。
【０１１６】
続いて編集制御部１６４は、図１１に示すビデオパック＃３のビデオデータに対して、図３に示すビデオパック＃３と同じ処理を行う。これにより、ビデオパック＃３内のビデオデータは分割されて、３つのビデオパックが生成される。  編集制御部１６４は、生成した３つのビデオパックをＲＤＩパック１２の後から順に配置する。これらのビデオパックは、図１２に示すビデオパック＃１〜＃３に対応する。
【０１１７】
ビデオパックの生成または配置にあわせて、編集制御部１６４は各パックのパックヘッダ内にＳＣＲ値を設定する。具体的には、先頭のＲＤＩパック１２のＳＣＲ値は、編集前のＲＤＩパック（図１１）の値よりも２パックの転送時間相当だけ小さく設定する。編集後のビデオパック＃１のＳＣＲ値は、編集前のビデオパック＃３（図１１）の値よりも、２パックの転送時間相当だけ小さく設定する。これらはそれぞれ編集前のビデオパック＃１および＃２と同じ値である。同様に、編集後のビデオパック＃２のＳＣＲ値は編集前のＲＤＩパック（図１１）の値と同じになり、編集後のビデオパック＃３のＳＣＲ値は変動しない。
【０１１８】
その後、編集制御部１６４はメディア制御部１７５に対し、ＲＤＩパック１２、ビデオパック＃１〜＃３等を、メモリカード１３０のクラスタ＃Ｊの先頭から順に書き込むよう指示する。なお、ビデオパック＃３以降のパックのデータは、変更しなくてもよい。その結果、図１２に示すプログラムストリーム３８がメモリカード１３０に書き込まれる。
【０１１９】
上述の説明では、プログラムストリームの前方削除処理、すなわち、図８の「編集点」に相当する位置から前のデータを全て削除する処理を例に挙げて説明した。しかし、本発明の適用できる範囲は前方削除処理に限られない。たとえば本発明は、データストリームの中間部分を削除する処理に際しても適用できるし、また１つのデータストリームを編集点から２つに分割する処理に際しても適用できる。
【０１２０】
より具体的には、中間部分を削除する処理では、中間部分の後に残されるデータストリームの先頭部分に対して本発明の処理を適用すればよい。また、１つのデータストリームを分割する処理では、編集点の後のデータストリームの先頭部分に対して本発明の処理を適用すればよい。いずれの場合も、その先頭部分のデータが格納されたクラスタ内に存在するデータに対して、図８に示すステップＳ８２以降の処理を行えばよい。
【０１２１】
上述の実施形態およびその変形例を総合すると、レコーダ１０の処理は以下のように一般化することができる。すなわち、単位領域（クラスタ）にコンテンツデータを格納したプログラムストリームが記録されているときにおいて、メディア制御部１７５の再生部１２１がクラスタ単位でプログラムストリームのパックを読み出す。すると編集制御部１６４は、第（ｎ＋１）パケットから第（ｎ＋ｍ）パケット（ｎ、ｍ：１以上の整数）までの少なくとも１つに格納されたコンテンツデータを分割して、第１パケットから第（ｎ＋ｍ）パケットまでの複数のパケットに格納する。その後、メディア制御部１７５の記録部１２０は、第１パケットから（ｎ＋ｍ）パケットを含む複数のパケットを、元のクラスタに書き込む。これにより、編集処理時間を著しく短縮できる。
【０１２２】
これまで説明した実施形態では、メモリカード１３０はリムーバブルであるとしたがこれは例である。上述したファイルシステムによりファイルを管理するメディアであれば、他の半導体記録媒体（たとえばＦｅＲＡＭ、ＭＲＡＭ）であってもよいし、光ディスク（たとえばＤＶＤ−ＲＡＭ、ＭＯ、ＤＶＤ−Ｒ、ＤＶＤ−ＲＷ、ＤＶＤ＋ＲＷ、ＤＶＤ＋Ｒ、ＣＤ−Ｒ、ＣＤ−ＲＷ）であってもよい。さらにレコーダ１０に内蔵されたハードディスクなどの非可換メディアであってもよい。
【０１２３】
なお、上述の実施形態においては、ＦＡＴファイルシステムに関して説明したが、パックサイズの整数倍で記録領域が割り付けられるファイルシステムであれば、ＦＡＴファイルシステムに限られない。たとえば、１個の論理ブロックのサイズが３２キロバイトであるＵＤＦファイルシステムであってもよい。
【０１２４】
なお、図１等の各機能ブロックは、典型的にはＣＰＵ１８１に代表される集積回路（Ｌａｒｇｅ  Ｓｃａｌｅ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ；ＬＳＩ）のチップとして実現される。これらは個別に１チップ化されてもよいし、一部または全てを含むように１チップ化されてもよい。例えば、図１においては、ＭＰＥＧエンコーダ部１７０とシステム制御部１８０とは別個の機能ブロックとして示されている。これらはそれぞれ別個の半導体チップとして実装されてもよいし、物理的に同一のチップによって実現してもよい。また、システム制御部１８０、ＭＰＥＧエンコーダ１７０およびＭＰＥＧデコーダ１７１の機能を集積化して、１つのチップ回路として実現してもよい。ただし、例えば符号化または復号化の対象となるデータを格納するメモリのみを集積化の対象から除外してもよい。
【０１２５】
なお、上述の「ＬＳＩ」は、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサーを利用してもよい。
【０１２６】
さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオテクノロジーを利用したいわゆるバイオ素子として集積化を行ってもよい。
【０１２７】
本実施形態においては、全プログラムストリーム（全ＶＯＢ）を１個のデータストリームファイルに格納したが、それぞれ別々のデータストリームファイルとして分離してもよい。また、データストリームファイルに関する全管理データを１個の管理ファイルに格納したが、別々のデータストリームファイルの管理データファイルとして分離してもよい。
【０１２８】
また、本実施形態においては、データストリームはプログラムストリームであるとして説明したが、トランスポートストリームやＰＥＳストリーム等の他のマルチメディア情報を含むビットストリームであってもよい。また、映像はＭＰＥＧ−２ビデオストリームを例としたが、ＭＰＥＧ−４ビデオストリームやＭＰＥＧ−４ＡＶＣストリームであってもよい。また、音声もリニアＰＣＭオーディオストリームやＡＣ−３ストリーム等であってもよい。
【０１２９】
なお、ＳＣＲの減算処理を実施する場合には、ＶＯＢＵ＃ｉの中の最初に表示されるピクチャのＰＴＳ（プレゼンテーションタイムスタンプ）値とＳＣＲの最小値の間隔が１秒以内であることを確認することが必要とされる。特殊な符号化を実施していない限り１秒以上となることは非常に稀である。逆に、ＭＰＥＧエンコーダは各ＶＯＢＵの最初に表示されるピクチャのＰＴＳと各ＶＯＢＵの先頭ＳＣＲの時間間隔を例えば０．９秒を越えないように符号化することが好ましい。
【産業上の利用可能性】
【０１３０】
本発明のデータ処理装置（レコーダ）によれば、記録されたコンテンツの前方削除処理や分割処理の簡略化が可能であり、短時間のうちに編集処理を完了することができる。ユーザに対しては待ち時間を少なくできるため利便性が向上する。さらに、動作時間の減少によってデータ処理装置の電力消費を抑えることができるため、特にバッテリで駆動する機器、たとえばカムコーダ等のモバイルＡＶ機器に非常に有用である。
【図面の簡単な説明】
【０１３１】
【図１】本発明の実施形態によるレコーダ１０の構成を示す図である。
【図２】データストリームファイル２０のデータ構造を示す図である。
【図３】（ａ）はレコーダ１０による編集前のプログラムストリーム３５を示す部分であり、（ｂ）はレコーダ１０による編集後のプログラムストリーム３６を示す部分である。
【図４】削除編集前のビデオパック＃３のデータ構造を示す図である。
【図５】（ａ）は削除編集後のビデオパック＃１のデータ構造を示す図であり、（ｂ）は削除編集後のビデオパック＃２のデータ構造を示す図であり、（ｃ）は削除編集後のビデオパック＃３のデータ構造を示す図である。
【図６】削除編集処理前のプログラムストリーム３５とＶＯＢＵとＦＡＴファイルシステムのクラスタの配置に関する対応関係を示す図である。
【図７】削除編集処理後のプログラムストリーム３６とＶＯＢＵとＦＡＴファイルシステムのクラスタの配置に関する対応関係を示す図である。
【図８】レコーダ１０の削除編集処理の手順を示すフローチャートである。
【図９】メモリカード１３０のファイルシステムの階層構造を示す図である。
【図１０】プログラムストリームの管理情報の例を示す図である。
【図１１】各ＶＯＢＵがＲＤＩパックから開始されるプログラムストリーム３７のパック配列とＶＯＢＵとＦＡＴファイルシステムのクラスタの配置に関する対応関係を示す図である。
【図１２】削除編集処理後のプログラムストリーム３８とＶＯＢＵとＦＡＴファイルシステムのクラスタの配置に関する対応関係を示す図である。
【符号の説明】
【０１３２】
１０  レコーダ
１００  映像信号入力部
１０１  映像圧縮部
１０２  音声信号入力部
１０３  音声圧縮部
１０４  システムエンコード部
１１０  映像信号出力部
１１１  映像伸長部
１１２  音声信号出力部
１１３  音声伸長部
１１４  システムデコード部
１２０  記録部
１２１  再生部
１３０  取り外し可能なメモリカード
１６０  連続データ領域検出部
１６１  記録制御部
１６２  再生制御部
１６３  論理ブロック管理部
１６４  編集制御部
１７０  ＭＰＥＧエンコーダ
１７１  ＭＰＥＧデコーダ
１７５  メディア制御部
１８０  システム制御部
１８１  ＣＰＵ
１８２  ＲＯＭ
１８３  ＲＡＭ
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】全図
【補正方法】変更
【補正の内容】
【図１】
2006088100.tif 000015
【図２】
2006088100.tif 000016
【図３】
2006088100.tif 000017
【図４】
2006088100.tif 000018
【図５】
2006088100.tif 000019
【図６】
2006088100.tif 000020
【図７】
2006088100.tif 000021
【図８】
2006088100.tif 000022
【図９】
2006088100.tif 000023
【図１０】
2006088100.tif 000024
【図１１】
2006088100.tif 000025
【図１２】
2006088100.tif 000026
【国際調査報告】
2006088100.tif 000027
2006088100.tif 000028