JP2006129078A - データファイル編集方法及び装置及び制御プログラム及び記憶媒体 - Google Patents

Abstract

【課題】MP4あるいは類似形式のファイルの結合編集を行なう場合に、編集処理を効率的に行なえるようにする。
【解決手段】MP4ファイルの結合編集において、追加結合するMP4ファイルの内容をフラグメントムービーの形式にすることによって、連結元となるファイルデータをコピーするなどの大きな編集を行なわずに、つなぎ合わせる新しいデータのコピーと最小限のファイル編集のみで連結されたMP4ファイルを生成する。
【選択図】 図５

Description

本発明はマルチメディアファイルの編集処理に好適な編集方法および装置およびプログラムに関する。特にMP4あるいは類似形式のファイルの結合編集処理技術に関するものである。

近年、動画・音声符号化形式の多様化にともない、様々な形式を均一的な枠組みの中で相互接続可能な形で処理出来るようにする必要性が高まってきている。そこで、ISO/IEC （International Organization for Standardization/International Engineering Consortium）JTC1/SC29/WG11によって、MPEGなどの動画・音声のコンテンツデータをファイルに記録するために「ISO Base Mediaファイル形式」という汎用のファイル形式が規格化されている（ISO/IEC 14496-12。非特許文献１参照）。

このファイル形式は特定の符号化形式を前提とはしていない基本ファイル形式として定義されており、所定の符号化形式や目的に適合させるにはこの規格を部分的に拡張した規格を別途定義することによって対応するといった特徴を持っている。その拡張の代表例として、MPEG-4の動画・音声符号化データを記録するための標準ファイル形式である「MP4ファイル形式」（ISO/IEC 14496-14。非特許文献２参照）のようなものがある。また、同じくMPEG-4の動画・音声を扱う形式であるが、第三世代携帯電話を中心とする無線端末上での利用を前提に制約が課せられた動画ファイル規格として、3GPP(Third Generation Partnership Project)によって定められた3GPPファイル形式（3GPP TS26.244。非特許文献３参照）のようなものもある。

近年では、デジタルカメラや携帯電話などの機器で動画・音声データをMPEG-4形式で符号化してファイルに記録する際の記録形式として、上記のようなファイル形式を採用するケースが増えてきており、今後更に普及してくると考えられる。

図１は、上記のMP4ファイル形式におけるデータ構造を説明するための概念図である。

図１に示されるように、MP4ファイル形式のファイルは、符号化された映像・音声データの実体を示すメディアデータ301、および映像・音声データの物理的位置、時間的位置や特性情報を示すメタデータ302の大きく２つのデータ構造から構成される。

メディアデータ301は、符号化データの基本単位を示す「サンプル」が連続して複数個記録されている「チャンク」と呼ばれるデータ構造から構成されている。ファイル内には、メディアデータ301は、チャンクの羅列として記述される。

メタデータ302には、このチャンクのファイル中でのオフセット位置、およびチャンク内に含まれるサンプルの時間情報、サイズ情報、ランダムアクセスの可否、特性情報といった情報が記録される。MP4形式では、コンテンツ全体のプレゼンテーションを「ムービー」、コンテンツを構成するメディアストリームのプレゼンテーションを「トラック」と呼んでいるが、上記の情報は各トラック毎に保持される。例えば図１のファイルは動画トラック、音声トラックの２トラックを含んでいることを示しているが、動画トラックのチャンク303、304、およびその中に含まれるサンプルの情報は、動画トラックのメタデータ領域305に記録される。

MP4ファイル形式では、ファイルに記録されるデータは「Box」と呼ばれるデータ構造の内部に記述され、Boxを単位としてファイルに記録される。

図２はBoxのフィールド定義を示す図である。Boxは、次のようなフィールドから構成される。

size: sizeフィールド自体を含む、Box全体のサイズ。

type: Boxの種類を表す4バイトのタイプ識別子。通常は4文字の英数字で表される。

その他のフィールドはBoxによってはオプションであるため、ここでは説明を省略する。

ファイル中に記録されるデータは、その種類によって異なるタイプのBoxに保持される。例えば、メディアデータ301は符号化データを格納するMedia Data Box（typeフィールドの内容は‘mdat’。以降の説明でBoxのタイプを示す識別子が用いられる場合は、そのタイプで示されるBoxを表現しているものとする）として、メタデータ302はコンテンツ全体のメタデータ情報を格納するMovie Box（‘moov’）として記録される。

また、前述のチャンクおよびサンプルに関する情報については、チャンクのファイル中でのオフセット位置はChunk Offset Box（‘stco’）、サンプルとチャンクとの対応関係はSample To Chunk Box（‘stsc’）、各サンプルの時間情報はTime To Sample Box(‘stts’)、各サンプルのサイズ情報はSample Size Box（‘stsz’）、ランダムアクセス可能なサンプルの情報はSync Sample Box（‘stss’）、サンプルに適用される特性情報はSample Description Box（‘stsd’）といったBoxとして、Movie Boxの内部にトラック毎に記録される。

また、MP4ファイル形式では、moovにすべてのメタデータを記録する形だけではなく、メタデータを時系列順に複数の領域に分割して記録するような形式も許可している。この形式は「フラグメントムービー」（Fragmented Movie）と呼ばれている。

図３に、フラグメントムービー形式のファイルの構造を示す。フラグメントムービー形式では、コンテンツのメディアデータおよびメタデータは任意の時間単位で分割することができ、分割された「フラグメント」はファイルの先頭から時系列順に記録される。例えば図３では、moov401は最初のフラグメントのメタデータを示しており、mdat402に含まれるデータに関する情報を保持する。次に出現するmoof403は２番目のフラグメントのメタデータであり、mdat404の情報を保持する、というように以下同様にして記録される。

このフラグメントムービー形式は3GPPファイル形式の後進の規格として標準化された3GPP2ファイル形式(3GPP2 C.S0050-0。非特許文献４参照)では利用を許可していることから、3GPP2準拠の無線端末を中心に広く普及してくることが考えられる。

このように、MP4ファイル形式のファイルでは、メディアデータに関する各種属性をメタデータ領域としてメディアデータと分離して保持することによって、メディアデータが物理的にどのように格納されているかに関わらず、所望のサンプルデータに容易にアクセスすることが可能になっている。
ISO/IEC 14496-12; "Information technology -- Coding of audio-visual objects -- Part 12: ISO base media file format"; ISO/IEC; 2004-01-23 ISO/IEC 14496-14; "Information technology -- Coding of audio-visual objects -- Part 14: MP4 file format"; ISO/IEC; 2003-11-24 3GPP TS 26.244 "Technical Specification Group Services and System Aspects Transparent end-to-end packet switched streaming service (PSS); 3GPP file format (3GP) (Release 6)" 3rd Generation Partnership Project; 2003-02-28 3GPP2 C.S0050-0 "3GPP2 File Formats for Multimedia Services" Version 1.0 3rd Generation Partnership Project 2; 2003-12-12

あるMP4ファイルの末尾に他のMP4ファイルを連結するという結合編集を行う場合、従来の処理方法では図４に示すように、一度メタデータとメディアデータを非多重化し、必要であればメディアデータの再符号化処理などを行ったのち、再度ひとつのファイルに多重化するという作業を行う必要があった。しかしながらこの処理には以下に挙げるような課題がある。

第一の課題として、連結元のファイルのメタデータを新しいメタデータとして再構築する場合は、一般にメタデータのサイズは連結前と比べて増大する。したがって連結ファイルにはメタデータを配置するための領域を確保するために、連結元のメディアデータを後方にずらすためのコピーを行わなければならず、データコピー処理に大きな処理負荷がかかってしまっていた。

第二の課題として、メタデータを分離し、内容を再構築するためには、メタデータの内容を一時的にメモリに保持しておく必要があり、メモリに制限のある環境では連結対象のファイルサイズが大きくなると作業用のメモリを確保するのが困難であった。

第三の課題として、従来の方法では連結対象の２ファイルとは別に、それらとほぼ同じサイズの出力ファイルが別に作成されるため、出力ファイルを保持できるだけの空き領域をファイル格納領域に確保しなければならなかった。

このように、従来の方法ではファイルの連結処理は非常に処理コストが高いものであり、処理速度やデータ転送速度、記憶容量などに制限のある実行環境では実現が困難であった。

従って、本発明は上述した課題に鑑みてなされたものであり、その目的は、MP4あるいは類似形式のファイルの結合編集を行なう場合に、編集処理を効率的に行なえるようにすることである。

上述した課題を解決し、目的を達成するために、本発明に係わるデータファイルの編集方法は、管理情報データと実データとを有する第１及び第２のデータファイルを結合して編集するためのデータファイルの編集方法であって、前記第１及び第２のデータファイルの構造を解析する解析工程と、前記第２のデータファイルをフラグメント形式に変換する変換工程と、フラグメント形式に変換された前記第２のデータファイルを前記第１のデータファイルの末尾に連結する連結工程と、を具備することを特徴とする。

また、この発明に係わるデータファイルの編集方法において、前記連結工程では、前記解析工程において解析された結果に基づいて前記第１及び第２のデータファイルが連結を行える構造を有しているか否かを判断し、連結可能な構造である場合に前記第１及び第２のデータファイルの連結を行うことを特徴とする。

また、この発明に係わるデータファイルの編集方法において、前記連結工程では、前記第１のデータファイル内に前記第２のデータファイルの情報を示す追加ファイル情報を追記することを特徴とする。

また、この発明に係わるデータファイルの編集方法において、前記連結工程では、前記第１のデータファイル内に前記追加ファイル情報を追記するための空き領域があるか否かを判断し、空き領域がある場合に前記第１及び第２のデータファイルの連結を行うことを特徴とする。

また、この発明に係わるデータファイルの編集方法において、前記連結工程では、前記空き領域に前記追加ファイル情報を追記することを特徴とする。

また、この発明に係わるデータファイルの編集方法において、前記連結工程では、前記第２のデータファイルの実データを構成するサンプルがすべて同一の属性を持つ場合に、前記追加ファイル情報にすべての前記サンプルに適用されるデフォルト属性を含めることを特徴とする。

また、この発明に係わるデータファイルの編集方法において、前記連結工程では、前記第１のデータファイルと前記第２のデータファイルのデコード条件が同一であるか否かを判断し、前記デコード条件が同一である場合に前記第１及び第２のデータファイルの連結を行うことを特徴とする。

また、この発明に係わるデータファイルの編集方法において、前記連結工程では、前記第１のデータファイルの管理情報データが前記第２のデータファイルの管理情報データよりも前に記録されている場合に前記第１及び第２のデータファイルの連結を行うことを特徴とする。

また、この発明に係わるデータファイルの編集方法において、前記連結工程では、前記第２のデータファイルのチャンクをフラグメントランとし、前記チャンクの管理情報データを前記フラグメントランの管理情報データに変換することを特徴とする。

また、この発明に係わるデータファイルの編集方法において、前記連結工程では、前記フラグメントランの位置を示すオフセット情報を、前記第１のデータファイルの前記フラグメントランのデータが出力される位置に更新することを特徴とする。

また、この発明に係わるデータファイルの編集方法において、前記連結工程では、前記第２のデータファイルの最初の管理情報データを前記フラグメント形式の管理情報データに再構成することを特徴とする。

また、この発明に係わるデータファイルの編集方法において、前記連結工程では、前記第２のデータファイルの１つ以上の前記チャンク毎に１つの前記フラグメント形式の管理情報データを形成することを特徴とする。

また、この発明に係わるデータファイルの編集方法において、前記連結工程では、前記第２のデータファイルの前記フラグメント形式の管理情報データの前記オフセット情報を更新して前記第１のデータファイルに記録することを特徴とする。

また、この発明に係わるデータファイルの編集方法において、前記連結工程では、前記第１及び第２のデータファイルが連結を行える構造を有しているか否かを示す識別情報が、前記第１のデータファイルおよび第２のデータファイルにあるか否かを判断し、前記識別情報がある場合に前記第１および第２のデータファイルの連結を行うことを特徴とする。

また、本発明に係わるデータファイルの編集装置は、管理情報データと実データとを有する第１及び第２のデータファイルを結合して編集するためのデータファイルの編集装置であって、前記第１及び第２のデータファイルの構造を解析する解析手段と、前記第２のデータファイルをフラグメント形式に変換する変換手段と、フラングメント形式に変換された前記第２のデータファイルを前記第１のデータファイルの末尾に連結する連結手段と、を具備することを特徴とする。

また、この発明に係わるデータファイルの編集装置において、前記連結手段は、前記解析手段によって解析された結果に基づいて前記第１及び第２のデータファイルが連結を行える構造を有しているか否かを判断し、連結可能な構造である場合に前記第１及び第２のデータファイルの連結を行うことを特徴とする。

また、この発明に係わるデータファイルの編集装置において、前記連結手段は、前記第１のデータファイル内に前記第２のデータファイルの情報を示す追加ファイル情報を追記することを特徴とする。

また、この発明に係わるデータファイルの編集装置において、前記連結手段は、前記第１のデータファイル内に前記追加ファイル情報を追記するための空き領域があるか否かを判断し、空き領域がある場合に前記第１及び第２のデータファイルの連結を行うことを特徴とする。

また、この発明に係わるデータファイルの編集装置において、前記連結手段は、前記空き領域に前記追加ファイル情報を追記することを特徴とする。

また、この発明に係わるデータファイルの編集装置において、前記連結手段は、前記第２のデータファイルの実データを構成するサンプルがすべて同一の属性を持つ場合に、前記追加ファイル情報にすべての前記サンプルに適用されるデフォルト属性を含めることを特徴とする。

また、この発明に係わるデータファイルの編集装置において、前記連結手段は、前記第１のデータファイルと前記第２のデータファイルのデコード条件が同一であるか否かを判断し、前記デコード条件が同一である場合に前記第１及び第２のデータファイルの連結を行うことを特徴とする。

また、この発明に係わるデータファイルの編集装置において、前記連結手段は、前記第１のデータファイルの管理情報データが前記第２のデータファイルの管理情報データよりも前に記録されている場合に前記第１及び第２のデータファイルの連結を行うことを特徴とする。

また、この発明に係わるデータファイルの編集装置において、前記連結手段は、前記第２のデータファイルのチャンクをフラグメントランとし、前記チャンクの管理情報データを前記フラグメントランの管理情報データに変換することを特徴とする。

また、この発明に係わるデータファイルの編集装置において、前記連結手段は、前記フラグメントランの位置を示すオフセット情報を、前記第１のデータファイルの前記フラグメントランのデータが出力される位置に更新することを特徴とする。

また、この発明に係わるデータファイルの編集装置において、前記連結手段は、前記第２のデータファイルの最初の管理情報データを前記フラグメント形式の管理情報データに再構成することを特徴とする。

また、この発明に係わるデータファイルの編集装置において、前記連結手段は、前記第２のデータファイルの１つ以上の前記チャンク毎に１つの前記フラグメント形式の管理情報データを形成することを特徴とする。

また、この発明に係わるデータファイルの編集装置において、前記連結手段は、前記第２のデータファイルの前記フラグメント形式の管理情報データの前記オフセット情報を更新して前記第１のデータファイルに記録することを特徴とする。

また、この発明に係わるデータファイルの編集装置において、前記連結手段は、前記第１及び第２のデータファイルが連結を行える構造を有しているか否かを示す識別情報が、前記第１のデータファイルおよび第２のデータファイルにあるか否かを判断し、前記識別情報がある場合に前記第１および第２のデータファイルの連結を行うことを特徴とする。

また、本発明に係わる制御プログラムは、上記のデータファイル編集方法をコンピュータに実行させることを特徴とする。

また、本発明に係わる記憶媒体は、上記の制御プログラムをコンピュータ読み取り可能に記憶したことを特徴とする。

本発明によれば、MP4あるいは類似形式のファイルの結合編集を行なう場合に、編集処理を効率的に行なうことが可能となる。

以下、本発明の実施形態を図面を参照しながら詳細に説明する。

なお、本発明の実施形態は処理対象のファイルがMP4ファイル形式である場合を中心に解説されているが、MP4に限らず類似のファイル形式を用いるケースに対しても適用できる。例えば、ISOではMP4と同様の基本構造を持つファイル形式規格として、「Motion JPEG 2000ファイル形式」（ISO/IEC 15444-3）や、「AVCファイル形式」（ISO/IEC 14496-15）といった標準規格が制定されている。これらの標準規格や、上述の3GPPファイル形式など、MP4で規定されるものと類似のファイル形式およびアーキテクチャが採用されている規格に対しても、本発明の一部あるいは全部を適用することが可能である。

また、本明細書で述べている「コンテンツデータがMP4ファイル形式で記述されている」という状態は、取り扱うデータの実体が物理的なファイルであることを示すものではない。メモリ上に記憶されているMP4ファイル形式で記述されたデータなどに対しても本発明を適用することができる。

本発明の実施形態では、図５で示されるように、連結元ファイル２０４に追加ファイル２０５の内容を続けて記述するという方法でファイルの結合編集を行う。また、その処理において、連結元ファイル２０４のメタデータを保持するmoov部分には、ファイル中にフラグメントが存在することを示すMovie Extends Box（‘mvex’）の情報を追加し、追加ファイル２０５のメタデータの内容を、２番目以降のフラグメントのメタデータ情報を保持するMovie Fragment Box（‘moof’）の形式に再構成して追加結合することによって、規格に矛盾することなく軽量な編集処理を実現している。

ただし、このような編集処理を行うためには、処理対象のファイルは次の条件を満たしていなければならない。
（条件１）連結元ファイル２０４のmoov部分には、mvexの内容を追加するため、100バイト程度の空き領域が確保されていなければならない。
（条件２）連結元ファイル２０４、追加ファイル２０５には、それぞれ同じデコード条件のトラックがなければならない。

上記の制約のため、本発明の実施形態の編集処理を行う対象となるファイルは、あらかじめ上記の条件を満たすような形で作成されていることが望ましい。上記の条件を満たさないファイルは、本発明の実施形態による結合編集を行うことが出来ない点には注意が必要である。

（第１の実施形態）
図６は、本発明の第１の実施形態におけるマルチメディアコンテンツの編集処理を実現する情報処理装置の構成を示すブロック図である。

図６において、CPU１０１はROM１０２あるいはRAM１０３あるいは外部記憶装置１０４に格納された制御プログラムとして記述された編集処理を実行する。外部記憶装置１０４に格納された制御プログラムは、RAM１０３にロードされ、CPU１０１によって実行されることになる。

外部記憶装置１０４には編集処理の対象となるMP4ファイル形式で記述されたコンテンツデータを格納することができる。

なお、編集の対象となるMP4ファイル形式のコンテンツデータは、ネットワーク（インターネット、LANを含む。有線、無線を問わない）よりネットワークI/F１０７を介して取得することも可能であるし、CD（Compact Disc）やDVD（Digital Versatile Disc）等のメディア１１２に記録されたコンテンツデータをメディアドライブ１０８を介して取得し、編集処理に利用することも可能である。さらに、映像入力装置１１０から映像I/F１０５を介して入力された映像データ、および、音声入力装置１１１から音声I/F１０６を介して入力された音声データを多重化することにより作成されたコンテンツデータも、編集処理に利用してもよい。

また、上記各構成はバス１０９により相互に通信可能に接続され、各種機能が達成される。

図７は、本発明の第１の実施形態において上記の編集処理を実行する機能モジュールの構成例を示す図である。このモジュール構成は、図６の情報処理装置において、CPUが実行する編集処理プログラムの構成要素を示す。

図７において、ファイル解析部２０１は、連結対象のコンテンツデータの構造を解析し、以降の処理に必要な情報を抽出する機能を有する。ファイル解析部２０１には、入力データとして、末尾にもう一方の内容が追加される側のデータを示す連結元ファイル２０４、および、連結元ファイル２０４の末尾に追加するデータを示す追加ファイル２０５が入力される。なお、本実施形態では、連結元ファイル２０４および追加データ２０５はMP4ファイル形式で記述されているものとする。

連結制御部２０２は、ファイル解析部２０１によって取得された情報に基づいて出力データの準備およびデータの出力指示を行う機能を有する。連結制御部２０２は、それ自体はデータの出力は行わず、ファイル出力部２０３に対して出力指示を行うことによって出力処理を行う。

ファイル出力部２０３は、連結制御部２０２からの出力指示にしたがって、ファイルデータの出力を行う。本実施形態では、ファイル出力部２０３は、連結元ファイル２０４に対してデータの出力を行う。すなわち、連結元ファイル２０４は入力データであると同時に、出力データとしても扱われる。

次に、本実施形態で行われる連結処理の基本的な手順について、図８のフローチャートを用いて説明する。

まず、ステップＳ１において、ファイル解析部２０１は入力された連結元ファイル２０４および追加ファイル２０５の内部構造を解析する。解析処理の結果、および解析によって得られたデータの内容は連結処理部２０２に渡され、後続の処理で利用される。

次に、ステップＳ２で、解析されたファイルが処理可能であるかどうかチェックする。チェック処理の手順については、後述の図９のフローチャートを用いて説明する。対象のファイルが処理可能でなければ、後続の処理はスキップし何らかの代替処理を行う。この場合の代替処理は、編集処理が行えない旨のエラーを出力したり、従来の方法で編集処理を行うといった、本発明の主題とは異なる例外処理を想定している。

ファイルが処理可能であれば、次に、ステップＳ３で、連結元ファイル２０４のmoov部分にmvexの内容を追加する。mvexの追加処理の手順については後述の図１４のフローチャートを用いて説明する。

次に、ステップＳ４で、追加ファイル２０５に含まれるメタデータの内容をmoof形式に再構成する。moof形式への変換処理の手順については後述の図２２のフローチャートを用いて説明する。

次に、ステップＳ５では、ステップＳ４で得られたmoof形式のメタデータ、および追加ファイル２０５のメディアデータの内容を、連結元ファイル２０４の末尾に出力する。

続いて、図８の編集処理のステップＳ２において行われる入力チェック処理の手順を、図９のフローチャートを用いて説明する。

＜ファイルのチェック処理＞
まず、ステップＳ１１において、ファイル解析部２０１は前述の処理ファイルの（条件１）で示されるように、連結元ファイル２０４のmoov部分にmvexの内容を保持するための空き領域があるかチェックする。

本実施形態では、既存のファイルをフラグメントとして連結することから、moovにはフラグメントの存在を示すmvexを挿入する必要がある。そのため、連結元ファイル２０４の作成時には、あらかじめ100バイト程度の空き領域をmoovの内部に作っておかなければならない。空き領域は、BoxのtypeフィールドにUUIDを用いて別途定義した拡張Boxか、あるいはUser Data Box(‘udta’)を用いて確保するようにする。ステップＳ１１では、これらのBoxがmoovに存在しなければ、空き領域が確保されていないとみなして、エラー処理を行う。

次に、ステップＳ１２において、ファイル解析部２０１は前述の処理ファイルの（条件２）で示されるように、連結元ファイル２０４、追加ファイル２０５に、それぞれ同じデコード条件のトラックがあるかチェックする。

本実施形態では、結合されるトラックは同一のデコード情報を共有することから、それぞれ同じ符号化形式で、サイズやプロファイルなどのデコード条件が同じでなければならない。MP4ファイル形式では、トラックのデコード情報は図１０で示されるようにSample Description Box(‘stsd’)に記述される。ステップＳ１２では、処理対象のファイル中から、同じストリームの種類（Video、Audio）を持ち、かつ同じ内容のデコード情報を持つトラックがあるかどうかをチェックし、存在しなければエラー処理を行う。

なお、デコード情報の同一性をどのようにチェックするかは、符号化形式によって異なるため、ここでは詳細は記載しない。また、処理対象のファイルに条件を満たすトラックも満たさないトラックも存在する場合、どのような処理を行うかはアプリケーションの仕様に依存するため、その詳細は記載しない。

次に、ステップＳ１３において、連結元ファイル２０４のmoov部分がmdatよりも前に配置されているかチェックする。

MP4ファイル内では、moovおよびmdatはどのような配置になっていても処理が可能であるが、フラグメントムービーの場合はHTTPファストスタートの高速化が図れるよう、moovはmdatよりも前に記述されていることが望ましい。そのため、ステップＳ１３では、連結元ファイル２０４のmoovの配置をチェックし、moovがmdatよりも前にない場合は、警告を出力するなどのエラー処理を行う。

なお、ステップＳ１３の処理は必須ではなく、省略しても編集処理は可能である。また、moovの配置が望ましい位置でない場合にどのような処理を行うかは、アプリケーションの仕様に依存するため、その詳細は記載しない。

上記のファイルのチェック処理が行われたら、引き続き、図８の編集処理のステップＳ３で示される、moovへのmvexの追加処理が行われる。

＜mvexの追加処理＞
まず、本実施形態でファイル結合編集を行なう際に、連結元ファイル２０４に加えられる変更内容について説明する。

図８のステップＳ３では、連結元ファイル２０４のmoov部分に含まれる空き領域に、mvex以下の3つのBoxを作成し、追加ファイル２０５の再生時間などの属性にしたがって内容の設定を行う。ここで追加されるmvex以下のBoxの構成を図１１に示す。

Movie Extends Box(‘mvex’)は、Movie Extends Header Box(‘mehd’)およびTrack Extends Box(‘trex’)を格納するためのコンテナであることを示す。

Movie Extends Header Box(‘mehd’)は、図１２で示されるフィールド定義を持ち、追加のフラグメント部分を含むムービー全体の再生時間の情報を保持する。Track Extends Box(‘trex’)は、図１３で示されるフィールド定義を持ち、フラグメントを構成するトラックの全サンプルに適用されるデフォルト設定情報を保持する。

上記のBox設定手順を、図１４のフローチャートを用いて説明する。

まず、ステップＳ２１において、連結処理部２０２はファイル解析部２０１から得られたmoovの空き領域の位置を取得し、その内部にmvhdを作成する。その際に、fragment_durationフィールドには、連結元ファイル２０４と追加ファイル２０５の再生時間の合計値をセットする。各ファイルの再生時間は、Movie Header Box(‘mvhd’)のtimescaleおよびdurationフィールドから取得可能である。ただし、mvhdは必須のBoxではないため、この処理は必ずしも行われなくてもよい。

次に、ステップＳ２２において、mvhdの後に続けてtrexを作成する。その際に、ファイル解析部２０１から連結対象のトラックの情報を取得し、trexの各フィールドに取得する。

track_IDフィールドには、連結対象のトラックのTrack Header Box(‘tkhd’)のtrack_IDの値をセットする。default_sample_description_indexには、連結対象トラックのデコード情報を示すSample Description Boxのインデックス番号をセットする。default_sample_durationには、連結対象トラックの全サンプルの再生時間が同じである場合に、デフォルトの再生時間をセットする。この値は、追加ファイル２０５のTime To Sample Box(‘stts’)のentry_countが1である場合に、sample_deltaフィールドによって示される。

default_sample_sizeには、連結対象トラックの全サンプルのサイズが同じである場合に、デフォルトのサイズをセットする。この値は、追加ファイル２０５のSample Size Box(‘stsz’)のsample_sizeフィールドから取得可能である。

default_sample_flagsには、連結対象トラックの各サンプルのランダムアクセス特性や優先度、パディングなどのデフォルトの属性をセットする。この値は、追加ファイル２０５のSync Sample Box(‘stss’)、Degradation Priority Box(‘stdp’)、Padding Bits Boxの各Boxに記述されている情報をもとに設定可能である。

次に、ステップＳ２３において、空き領域に設定されているBoxのタイプを ‘mvex’に書き換えることによって、空き領域をmvexに置き換える。

以上の処理によって、連結元ファイル２０４にmvexの内容が追加される。

なお、連結元ファイル２０４はフラグメントムービー形式として作成されていても良い。その場合は初めから存在する上記mvexのパラメータを変更するのみで、moovのサイズは変わらないため、連結元ファイル２０４のメディアデータをコピーする必要はない。

上記のファイルのチェック処理が行われたら、引き続き、図８の編集処理のステップＳ４で示される、追加ファイル２０５のメタデータをmoof形式に再構成する処理が行われる。

＜メタデータのmoof形式への再構成処理＞
まず、通常のムービーとフラグメントムービーのメタデータの形式の違いについて、簡単に説明する。

通常のフラグメントを用いないムービーでは、図１のようにメディアデータはチャンクおよびサンプルとして扱われ、それぞれのメタデータ情報を個別のBoxとして記録する。一方、フラグメントムービーの場合、フラグメント内のメディアデータは、連続するサンプルの集合を示す「フラグメントラン」というデータ構造として扱われる。

図１５は、フラグメントムービーにおけるフラグメントランを説明するための概念図である。

図１５で示されるように、メディアデータ501は同様にサンプルの連続からなるフラグメントランの羅列として構成される。しかし、メタデータの構成はチャンクと異なり、各フラグメントランに対応するBoxにそのフラグメントのすべてのメタデータが記録される。すなわち、通常のムービーで用いられるメタデータの種類を示す個別のBoxは、フラグメントに対しては適用されない。

両者のメタデータの違いを、実際のBox定義を用いてさらに詳細に説明する。

例として、moovに含まれるSample Size Box(‘stsz’)、Chunk Offset Box(‘stco’)、Sync Sample Box(‘stss’)について、moof形式ではどのように扱われるかについて説明する。

通常、moov以下のBox構成は図１６のようになっている。また、Sample Size Boxの定義は図１７で、Chunk Offset Boxの定義は図１８で、Sync Sample Boxの定義は図１９で示されるように、それぞれの情報は個別のBoxとして定義されている。

一方、moof以下のBox構成は図２０のようになっている。この中のTrack Fragment Run Box(‘trun’)に、各フラグメントランのメタデータが記録されている。trunの定義は図２１のようになっており、フラグメントランのオフセット位置や、フラグメントランを構成するサンプルのサイズなどの情報が、単一のBox内に記録されている。

したがって、メタデータの再構成処理では、上記に述べたような形式の違いを考慮した変換処理を行わなければならない。

上記の違いを踏まえて、追加するMP4ファイルのmoov部分を、フラグメントムービー形式のファイルで用いられるmoof形式に変換する手順について、図２２のフローチャートを用いて以下に説明する。なお、本実施形態では、追加するファイルのmdat全体をそのまま１つのフラグメントランとして変換する場合を想定する。説明を簡略化するため、本実施形態では処理対象ファイルのサンプルはすべて同じ再生時間を持ち、優先度、パディングビットなどは設定されていないものと想定する。すなわち、ここでの変換処理の対象となるメタデータは、Sample Size Box(‘stsz’)、Chunk Offset Box(‘stco’)、Sync Sample Box(‘stss’)のみとする。各サンプルの再生時間は前記mvexの追加処理で、tkhdのdefault_sample_durationに設定されているものとして、ここでの変換対象からは除外する。

まず、ステップＳ３０１において、連結処理部２０２はファイル解析部２０１から、追加ファイル２０４のmdatのファイル先頭からのオフセット位置を取得する。

次に、ステップＳ３０２において、以降のチャンクに対するループ処理の初期化を行う。ここでは、処理対象チャンクのインデックスとして用いられる変数ｉを1に初期化する。

次に、ステップＳ３０３において、ｉ番目のチャンクに対応するフラグメントランの内容を保持するエントリであるtrun[i]を作成する。このtrun[i]は、フラグメントランの内容がファイルに出力されるまでの間、RAMに保持される。

次に、ステップＳ３０４において、ｉ番目のチャンクのオフセット位置をstcoから取得し、trun[i]のdata_offsetフィールドに（mdatのオフセット−ｉ番目のチャンクのオフセット）の値をセットする。stcoのchunk_offsetフィールドはファイル先頭から当該チャンクまでのオフセット値をチャンク毎に格納しているが、フラグメントムービーでは、各フラグメント毎にフラグメントランまでのただ１つのオフセットと各サンプルのサイズによってサンプルの位置を確定するため、chunk_offsetの値はtrunのdata_offsetに格納されればよい。なお、data_offsetフィールドが用いられる場合、trunのtr_flagsにはdata_offset-presentビット(0x000001)をセットしなければならない。

次に、ステップＳ３０５において、ｉ番目のチャンクのサンプル数をSample To Chunk Box(‘stsc’)から取得し、trun[i]のsample_countフィールドにセットする。

次に、ステップＳ３０６において、以降のサンプルに対するループ処理の初期化を行う。ここでは、処理対象サンプルのインデックスとして用いられる変数ｊを1に初期化する。

次に、ステップＳ３０７において、ｉ番目のチャンク内のj番目のサンプルのサイズをstszから取得し、trun[i]のsample_size[j]フィールドをセットする。なお、sample_sizeフィールドが用いられる場合、trunのtr_flagsにはsample-size-presentビット(0x000200)をセットしなければならない。

次に、ステップＳ３０８において、ｉ番目のチャンク内のj番目のサンプルのランダムアクセス可否をstssから取得し、trun[i]のsample_flags[j]フィールドをセットする。なお、sample_flagsフィールドが用いられる場合、trunのtr_flagsにはsample-flags-presentビット(0x000400)をセットしなければならない。

次に、ステップＳ３０９において、ｉ番目のチャンクのすべてのサンプルが処理されたかチェックする。変数jがｉ番目のチャンク内のサンプル数に満たない場合は、変数ｊをインクリメントし、ステップＳ３０７からＳ３０８までの処理を繰り返す。

次に、ステップＳ３１０において、すべてのチャンクのサンプルが処理されたかチェックする。変数iがstcoで示されるチャンク数に満たない場合は、変数ｉをインクリメントし、ステップＳ３０３からＳ３１０までの処理を繰り返す。

以上の処理を変換対象の各トラックに対して行うことで、追加ファイル２０５のmoovの内容がmoof形式に再構成された形でRAM内に保持される。

＜データの追加処理＞
上記のメタデータのmoof形式への再構成処理によって得られたメタデータ、およびメディアデータの内容は、図８のステップＳ５の処理として連結元ファイル２０４の末尾に出力される。本実施形態では、RAMに保持されているmoof形式のメタデータの内容をまず出力し、その後に、追加ファイル２０５の最初のmdat以降の内容をそのまま連結元ファイル２０４に出力する。このようにすることで、追加ファイル２０５に複数のmdatが存在する場合にも矛盾なくmoofから参照することが可能になる。

ただし、この処理を行う際には、上記のメタデータのmoof形式への再構成処理によって設定された各フラグメントランのオフセット位置が、実際にファイルに出力された時のオフセット位置と一致するように調整を行う必要がある。

その第一の方法として、連結元ファイル２０４へのデータの出力前にmdatの出力位置をあらかじめ計算しておき、RAM上に保持されているすべてのtrunのdata-offsetフィールドに、mdatの出力位置の値を加算するという方法が考えられる。また、第二の方法としては、同じくmdatの出力位置をあらかじめ計算しておき、そのオフセット位置をtrafのbase_data_offsetフィールドにセットするという方法が考えられる。データの出力時には、いずれかの方法を用いて、メディアデータのオフセットが正しくなるように修正を行うことが必要である。

この様にして、本実施形態ではMP4ファイルを連結編集するにあたり、連結元のデータはわずかなメタデータの編集を行い、連結するデータはメタデータの形式を変換し連結元データに追加することによって、最小限のデータコピーで連結されたMP4ファイルを生成することが可能である。

なお、ここまでの説明では、追加ファイルがフラグメントムービーでない場合を前提に説明したが、追加ファイルはフラグメントムービーであってもよい。その場合は、最初のmoovおよびmdatは本明細書記載のいずれかの方法で再構成および出力処理を行い、後続のフラグメントを構成するmoofおよびmdatは、moofに含まれるいずれかのオフセット情報のみを変更することを除けば、基本的にはそのままデータコピーを行えばよい。

以上説明したように、上記の実施形態によれば、ファイル連結処理は連結元ファイルのメタデータ情報を一部変更するのみで実現できるため、連結元ファイルのメディアデータのコピーが発生しない。

さらに、メタデータ領域を再構成するためにすべてのメタデータを保持する必要はなく、必要なメモリ容量は少量で済む。

また、記録容量は追加分のデータをコピーするだけの容量があれば済む。

上記のように、本実施形態によれば、組み込み機器のように記録容量、メモリ容量が限られており、且つデータコピーが低速な環境においてもファイル連結処理を効率的に行うことが可能になる。

（第２の実施形態）
本発明の第２の実施の形態として、追加するファイルに含まれるある程度のチャンク毎にフラグメントを作成する場合について説明する。本実施形態では、適当な数のチャンクを１つのmdatとし、そのmdat毎にmoofを作成することになる。すなわち本実施形態は、複数のmoof形式のメタデータが出力されるという点で第１の実施形態と異なる。

複数のmoofを作成する場合、それぞれのmoofが正しい順序で記録されているかを確認できるようにするため、各moofに対して連番を設定する必要がある。

図２３は、moofに含まれるMovie Fragmnent Header Box(‘mfhd’)のフィールド定義を示す図である。moofを作成する際には、図２３に示されるmfhdのsequence_numberフィールドにフラグメントの出現順に増加する連番を設定しなければならない。

以下、本実施形態におけるメタデータの再構成処理の手順を、図２４のフローチャートを用いて説明する。

＜メタデータのmoof形式への再構成処理＞
図２４のステップＳ４０１からＳ４０９までの処理は、第１の実施形態における図２２のステップＳ３０１からＳ３０９までの処理と同じであるため、説明を省略する。なお、この場合、trunのdata_offsetにセットされるオフセット値は、各mdatの先頭となるチャンクのオフセットとなる。

次に、ステップＳ４１０において、ひとまとまりで出力される所定数のチャンクが処理されたかチェックする。このチェック処理は、所定数のチャンクをＮとした場合、ｊとＮの剰余が０になった場合はＮ個単位でのチャンクの処理が完了したことを示す。所定数のチャンクに満たない場合は、変数ｊをインクリメントし、ステップＳ４０７からＳ４０９までの処理を繰り返す。

次に、ステップＳ４１１で、ステップＳ４０１からＳ４１０までの処理によってRAMに保持されたmoof形式のメタデータの内容、および参照されるメディアデータの内容を、連結元ファイル２０４に追加する。追加処理の手順については後述する。

最後に、ステップＳ４１２において、すべてのチャンクのサンプルが処理されたかチェックする。変数iがstcoで示されるチャンク数に満たない場合は、変数ｉをインクリメントし、ステップＳ４０３からＳ４１２までの処理を繰り返す。

以上の処理を変換対象の各トラックに対して行うことで、追加ファイル２０５のmoovのうちの所定数のチャンクの内容がmoof形式に再構成された形でRAM内に保持される。

引き続き、上記ステップＳ４１１で行われる追加処理の詳細について、図２５のフローチャートを用いて説明する。

＜データの追加処理＞
まず、ステップＳ５１において、RAMに保持されている変換後のmoofの内容を連結元ファイル２０４の末尾に出力する。この処理は第１の実施形態で説明されているmoofの追加処理と同じである。ただし、mfhdのsequence_numberの値はmoofの出力を行う毎にインクリメントされた値をセットするようにする。

次に、ステップＳ５２において、連結元ファイル２０４の末尾にmdatを作成する。この処理は、mdatのsize、type等のヘッダ部分のみを出力する。

次に、ステップＳ５３において、trunに対するループ処理の初期化を行う。ここでは、trunのインデックスとして用いられる変数ｉを1に初期化する。

次に、ステップＳ５４において、trun[i]のサンプルに対するループ処理の初期化を行う。ここでは、処理対象サンプルのインデックスとして用いられる変数ｊを1に初期化する。

次に、ステップＳ５５において、trun[i]のj番目のサンプルデータを連結元ファイル２０４の末尾に出力する。ここでは、trun[i]のdata_offsetフィールドで示されるオフセット位置から、sample_size[j]フィールドで示されるサイズのデータが出力される。

次に、ステップＳ５６において、trun[i]のすべてのサンプルのデータが出力されたかチェックする。変数jがtrun[i]のsample_countフィールドの値に満たない場合は、変数ｊをインクリメントし、ステップＳ５５からＳ５６までの処理を繰り返す。

次に、ステップＳ５７において、出力対象のすべてのtrunのデータが出力されたかチェックする。変数iが出力対象のtrunの数に満たない場合は、変数ｉをインクリメントし、ステップＳ５４からＳ５７までの処理を繰り返す。

以上のような処理を行うことで、本実施形態では、MP4ファイルを連結編集する際に、連結するデータを所定数のチャンク毎に分割された形で連結元データに追加されたMP4ファイルを作成できる。この場合も、第１の実施形態と同様に、データコピーにかかるオーバーヘッドは最小限で済む。

（第３の実施形態）
本発明の第３の実施の形態として、追加するファイルの各チャンクにつき１つのフラグメントを作成する場合を説明する。本実施形態では、１つのチャンクを１つのmdatとし、そのmdat毎にmoofを作成することになる。

複数のmoofを作成する場合、それぞれのmoofが正しい順序で記録されているかを確認できるようにするために、各moofに対して連番を設定する必要がある。番号の設定方法については、第２の実施形態で示したため、説明を省略する。

以下、本実施形態におけるメタデータの再構成処理の手順を、図２６のフローチャートを用いて説明する。

＜メタデータのmoofへの再構成処理＞
図２６のステップＳ６０１からＳ６０９までの処理は、第１の実施形態における図２２のステップＳ３０１からＳ３０９までの処理と同じであるため、説明を省略する。なお、この場合の、trunのdata_offsetにセットされるオフセット値は、各mdatの先頭となるチャンクのオフセットとなる。

次に、ステップＳ６１０で、ステップＳ６０１からＳ６０９までの処理によってRAMに保持されたmoof形式のメタデータの内容、および参照されるメディアデータの内容を、連結元ファイル２０４に追加する。追加の手順については、第２の実施形態における図２５の処理と同じであるため、説明は省略する。

最後に、ステップＳ６１１において、すべてのチャンクのサンプルが処理されたかチェックする。変数iがstcoで示されるチャンク数に満たない場合は、変数iをインクリメントし、ステップＳ６０１からＳ６１１までの処理を繰り返す。

以上の処理を変換対象の各トラックに対して行うことで、追加ファイル２０５のmoovのチャンクの内容がmoof形式に再構成された形でRAM内に保持される。

以上のような処理を行うことで、本実施形態では、MP4ファイルを連結編集する際に、連結するデータをチャンク毎に分割された形で連結元データに追加されたMP4ファイルを作成できる。この場合も、第１及び第２の実施形態と同様に、データコピーにかかるオーバーヘッドは最小限で済む。

（第４の実施形態）
本発明の上記の第１から第３の実施形態では、処理を行うことができるファイルを識別するために、図９で示されるようなファイルの構成をチェックする処理が必要であった。しかし、処理可能なファイルの構成を識別する手段が別途提供される場合は、図９のような手順でのチェック処理は必ずしも行う必要はない。そこで第４の実施形態として、ファイル構成の識別手段が別途提供される場合を説明する。

MP4ファイル形式は、UUIDをtypeに用いる形の拡張Boxを利用することや、あるいはUser Data Box(‘udta’)を利用することで、システムに固有の独自データを記録することが認められている。この仕組みを用いて、本発明における処理可能ファイルの識別に用いられるmoovの空き領域の有無やデコード条件を一意に識別する識別用データをファイル中に記述すれば、ファイル解析時に識別用データの有無をチェックするのみで済むため、処理対象ファイルのチェック処理を簡素化することが可能になる。

また、上記識別用データとして、File Type Box(‘ftyp’)のブランド識別子を用いることも可能である。例えば処理可能なファイル形式を示すブランドを定義し、ファイルに記録することによって、ファイルの処理可否の判定はブランドのチェックのみで行えるようになる。

（その他の実施形態）
本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。

本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体（または記録媒体）を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはCPUやMPU）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム(OS)などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるCPUなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。プログラムを供給するための記録媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などがある。

本発明を上記記憶媒体に適用する場合、その記憶媒体には、先に説明したフローチャートに対応するプログラムコードが格納されることになる。

メタデータ、メディアデータの概念を説明する図である。 Boxのフィールド定義を示す図である。 ムービーフラグメントの概念を説明する図である。 従来のファイル結合処理を説明する図である。 本発明の実施形態におけるファイル結合処理を説明する図である。 本発明の実施形態のデータ処理を実現する情報処理装置の構成を示すブロック図である。 本発明の実施形態のモジュール構成例を示す図である。 本発明の実施形態の連結処理の基本的な手順を説明するフローチャートである。 本発明の実施形態において、ファイルが処理可能かチェックする処理を説明するフローチャートである。 Sample Description Box(‘stsd’)のフィールド定義を示す図である。 Movie Extends Box(‘mvex’)の構成を示す図である。 Movie Extends Header Box(‘mvhd’)のフィールド定義を示す図である。 Track Extends Box(‘trex’)のフィールド定義を示す図である。 本発明の実施形態において、Movie Box(‘moov’)にMovie Extends(‘mvex’)の内容を追加する処理を説明するフローチャートである。 フラグメントランの概念を説明する図である。 Movie Box(‘moov’)の構成を示す図である。 Sample Size Box(‘stsz’)のフィールド定義を示す図である。 Chunk Offset Box(‘stco’)のフィールド定義を示す図である。 Sycn Sample Box(‘stss’)のフィールド定義を示す図である。 Movie Fragment Box(‘moof’)の構成を示す図である。 Track Fragment Run Box(‘trun’)のフィールド定義を示す図である。 本発明の第１の実施形態において、Movie Data Box(‘mdat’)全体を単一のフラグメントランに変換する処理を説明するフローチャートである。 Movie Fragment Header Box(‘mfhd’)のフィールド定義を示す図である。 本発明の第２の実施形態において、所定数のチャンクを単一のフラグメントランに変換する処理を説明するフローチャートである。 本発明の第２の実施形態において、moof形式のメタデータの内容、および参照されるメディアデータの内容を、連結元ファイルに追加する処理を説明するフローチャートである。 本発明の第３の実施形態において、１つのチャンクを単一のフラグメントに変換する処理を説明するフローチャートである。

Claims (30)

1. 管理情報データと実データとを有する第１及び第２のデータファイルを結合して編集するためのデータファイルの編集方法であって、
   前記第１及び第２のデータファイルの構造を解析する解析工程と、
   前記第２のデータファイルをフラグメント形式に変換する変換工程と、
   フラグメント形式に変換された前記第２のデータファイルを前記第１のデータファイルの末尾に連結する連結工程と、
   を具備することを特徴とするデータファイルの編集方法。
2. 前記連結工程では、前記解析工程において解析された結果に基づいて前記第１及び第２のデータファイルが連結を行える構造を有しているか否かを判断し、連結可能な構造である場合に前記第１及び第２のデータファイルの連結を行うことを特徴とする請求項１に記載のデータファイルの編集方法。
3. 前記連結工程では、前記第１のデータファイル内に前記第２のデータファイルの情報を示す追加ファイル情報を追記することを特徴とする請求項１に記載のデータファイルの編集方法。
4. 前記連結工程では、前記第１のデータファイル内に前記追加ファイル情報を追記するための空き領域があるか否かを判断し、空き領域がある場合に前記第１及び第２のデータファイルの連結を行うことを特徴とする請求項３に記載のデータファイルの編集方法。
5. 前記連結工程では、前記空き領域に前記追加ファイル情報を追記することを特徴とする請求項４に記載のデータファイルの編集方法。
6. 前記連結工程では、前記第２のデータファイルの実データを構成するサンプルがすべて同一の属性を持つ場合に、前記追加ファイル情報にすべての前記サンプルに適用されるデフォルト属性を含めることを特徴とする請求項３に記載のデータファイルの編集方法。
7. 前記連結工程では、前記第１のデータファイルと前記第２のデータファイルのデコード条件が同一であるか否かを判断し、前記デコード条件が同一である場合に前記第１及び第２のデータファイルの連結を行うことを特徴とする請求項１に記載のデータファイルの編集方法。
8. 前記連結工程では、前記第１のデータファイルの管理情報データが前記第２のデータファイルの管理情報データよりも前に記録されている場合に前記第１及び第２のデータファイルの連結を行うことを特徴とする請求項１に記載のデータファイルの編集方法。
9. 前記連結工程では、前記第２のデータファイルのチャンクをフラグメントランとし、前記チャンクの管理情報データを前記フラグメントランの管理情報データに変換することを特徴とする請求項１に記載のデータファイルの編集方法。
10. 前記連結工程では、前記フラグメントランの位置を示すオフセット情報を、前記第１のデータファイルの前記フラグメントランのデータが出力される位置に更新することを特徴とする請求項９記載のデータファイルの編集方法。
11. 前記連結工程では、前記第２のデータファイルの最初の管理情報データを前記フラグメント形式の管理情報データに再構成することを特徴とする請求項１０に記載のデータファイルの編集方法。
12. 前記連結工程では、前記第２のデータファイルの１つ以上の前記チャンク毎に１つの前記フラグメント形式の管理情報データを形成することを特徴とする請求項１１に記載のデータファイルの編集方法。
13. 前記連結工程では、前記第２のデータファイルの前記フラグメント形式の管理情報データの前記オフセット情報を更新して前記第１のデータファイルに記録することを特徴とする請求項１１に記載のデータファイルの編集方法。
14. 前記連結工程では、前記第１及び第２のデータファイルが連結を行える構造を有しているか否かを示す識別情報が、前記第１のデータファイルおよび第２のデータファイルにあるか否かを判断し、前記識別情報がある場合に前記第１および第２のデータファイルの連結を行うことを特徴とする請求項１に記載のデータファイルの編集方法。
15. 管理情報データと実データとを有する第１及び第２のデータファイルを結合して編集するためのデータファイルの編集装置であって、
    前記第１及び第２のデータファイルの構造を解析する解析手段と、
    前記第２のデータファイルをフラグメント形式に変換する変換手段と、
    フラングメント形式に変換された前記第２のデータファイルを前記第１のデータファイルの末尾に連結する連結手段と、
    を具備することを特徴とするデータファイルの編集装置。
16. 前記連結手段は、前記解析手段によって解析された結果に基づいて前記第１及び第２のデータファイルが連結を行える構造を有しているか否かを判断し、連結可能な構造である場合に前記第１及び第２のデータファイルの連結を行うことを特徴とする請求項１５に記載のデータファイルの編集装置。
17. 前記連結手段は、前記第１のデータファイル内に前記第２のデータファイルの情報を示す追加ファイル情報を追記することを特徴とする請求項１５に記載のデータファイルの編集装置。
18. 前記連結手段は、前記第１のデータファイル内に前記追加ファイル情報を追記するための空き領域があるか否かを判断し、空き領域がある場合に前記第１及び第２のデータファイルの連結を行うことを特徴とする請求項１７に記載のデータファイルの編集装置。
19. 前記連結手段は、前記空き領域に前記追加ファイル情報を追記することを特徴とする請求項１８に記載のデータファイルの編集装置。
20. 前記連結手段は、前記第２のデータファイルの実データを構成するサンプルがすべて同一の属性を持つ場合に、前記追加ファイル情報にすべての前記サンプルに適用されるデフォルト属性を含めることを特徴とする請求項１７に記載のデータファイルの編集装置。
21. 前記連結手段は、前記第１のデータファイルと前記第２のデータファイルのデコード条件が同一であるか否かを判断し、前記デコード条件が同一である場合に前記第１及び第２のデータファイルの連結を行うことを特徴とする請求項１５に記載のデータファイルの編集装置。
22. 前記連結手段は、前記第１のデータファイルの管理情報データが前記第２のデータファイルの管理情報データよりも前に記録されている場合に前記第１及び第２のデータファイルの連結を行うことを特徴とする請求項１５に記載のデータファイルの編集装置。
23. 前記連結手段は、前記第２のデータファイルのチャンクをフラグメントランとし、前記チャンクの管理情報データを前記フラグメントランの管理情報データに変換することを特徴とする請求項１５に記載のデータファイルの編集装置。
24. 前記連結手段は、前記フラグメントランの位置を示すオフセット情報を、前記第１のデータファイルの前記フラグメントランのデータが出力される位置に更新することを特徴とする請求項２３記載のデータファイルの編集装置。
25. 前記連結手段は、前記第２のデータファイルの最初の管理情報データを前記フラグメント形式の管理情報データに再構成することを特徴とする請求項２４に記載のデータファイルの編集装置。
26. 前記連結手段は、前記第２のデータファイルの１つ以上の前記チャンク毎に１つの前記フラグメント形式の管理情報データを形成することを特徴とする請求項２５に記載のデータファイルの編集装置。
27. 前記連結手段は、前記第２のデータファイルの前記フラグメント形式の管理情報データの前記オフセット情報を更新して前記第１のデータファイルに記録することを特徴とする請求項２５に記載のデータファイルの編集装置。
28. 前記連結手段は、前記第１及び第２のデータファイルが連結を行える構造を有しているか否かを示す識別情報が、前記第１のデータファイルおよび第２のデータファイルにあるか否かを判断し、前記識別情報がある場合に前記第１および第２のデータファイルの連結を行うことを特徴とする請求項１５に記載のデータファイルの編集装置。
29. 請求項１乃至１４のいずれか１項に記載のデータファイル編集方法をコンピュータに実行させることを特徴とする制御プログラム。
30. 請求項２９に記載の制御プログラムをコンピュータ読み取り可能に記憶したことを特徴とする記憶媒体。

Images