JP3938594B2 - ファイル名生成装置 - Google Patents

Description

本発明は、ファイル名を生成する装置に関し、特に、ビデオカメラやデジタルスチルカメラ等の撮影装置においてファイル名を生成する技術に関する。

ビデオカメラやデジタルスチルカメラ等の撮影装置では、メモリカードやハードディスク、光ディスク等のランダムアクセス可能な記憶媒体にデータを格納することができる。このように記憶媒体にデータを格納する場合は、利用性等の観点から、データをファイルとして格納するのが一般的である。

そこで、記憶媒体上のファイルを管理するために、ファイルシステムと呼ばれるモジュールが用いられる。ファイルシステムの代表的なものには、ＦＡＴ（非特許文献１参照）がある。ファイルシステムの動作は複雑であるため、通常は、撮影装置にオペレーティングシステム（ＯＳ）を搭載することにより、ソフトウェアとしてファイルシステムを実装する。

ここで、撮影装置に装着された記憶媒体にファイルを格納する場合は、撮影者にファイル名を指定する手間を取らせないように、撮影装置に搭載されたプログラムが自動的に連続番号等のファイル名を生成するのが一般的である。しかし、このように自動的にファイル名を生成する方法によると、記憶媒体上のファイルをＰＣにコピーする際、以前に記憶媒体からコピーしてきた同じ名称のファイルがＰＣに存在する場合がある。この場合、既存のファイルを上書き消去する可能性があるため、これを回避するために、ファイル名の生成方法について多くの方法が提案されている。

たとえば、特許文献１には、撮影時刻を含む名称でディレクトリを生成する方法が開示されている。また、特許文献２には、ファイル名をできる限り重複させないように生成し、かつそのファイルを撮影年月日毎に整理し易くするための方法が開示されている。さらに、特許文献３には、同一の撮影装置で撮影する限りは、ファイル名が重複しないようにする方法が開示されている。すなわち、特許文献１から３に開示される方法は、撮影時刻をファイル名に含めることによって、既存のファイルを上書き消去するという問題を回避しようとしている。
特開平１１−１６４２３４号公報 特開２００１−１０９６５１号公報 特開平１０−１７７６４６号公報 Ｓｔａｎｄａｒｄ ＥＣＭＡ−１０７： Ｖｏｌｕｍｅ ａｎｄ Ｆｉｌｅ Ｓｔｒｕｃｔｕｒｅ ｏｆ Ｄｉｓｋ Ｃａｒｔｒｉｄｇｅｓ ｆｏｒ Ｉｎｆｏｒｍａｔｉｏｎ Ｉｎｔｅｒｃｈａｎｇｅ

ところで、放送局におけるニュース取材などでは、複数人の撮影者が同時刻に複数台の撮影装置を用いて別々に撮影を行うのが一般的である。そして、このように撮影して得られたファイルを編集等の都合から一つのＰＣや記憶媒体に集める場合がある。

この場合は、前記従来のように、撮影時刻をファイル名に含めるだけでは、ファイル名が重複する可能性が高い。ファイル名が重複する場合は、重複するいずれかのファイル名を変更しなければ、既存のファイルを上書き消去してしまう可能性がある。

本発明は、前記課題を解決するものであって、複数台の装置によって生成されたファイル間で、ファイル名が重複する確率を低減させることを目的とする。

前記目的を達成するために、本発明に係るファイル名生成装置は、ファイル名を生成する装置であって、グローバルユニークな識別子を生成する識別子生成手段と、前記識別子生成手段によって生成されたグローバルユニークな識別子を含むファイル名を生成するファイル名生成手段とを備えることを特徴とする。これによって、複数台の撮影装置によって生成されたファイル間で、ファイル名が重複することを回避することができる。

ここで、前記グローバルユニークな識別子には、ファイルが生成された順番を特定する情報と、ファイル生成に関係するハードウェアを特定する情報とが含まれる。ファイルが生成された順番を特定する情報をファイル名に含めれば、一台の装置内においてファイル名が重複することが回避され、一方、ファイル生成に関係するハードウェアを特定する情報をファイル名に含めれば、他の装置との間でファイル名が重複することが回避される。

より具体的には、前記グローバルユニークな識別子には、ファイルが生成された日時、及びファイルが生成された順番を示す連続番号のうちのいずれかと、ファイル名生成装置のシリアル番号、及び生成されたファイルが格納される記憶媒体のシリアル番号のうちのいずれかとが含まれる。すなわち、前記「ファイルが生成された順番を特定する情報」とは、ファイルが生成された日時や、ファイルが生成された順番を示す連続番号のことである。一方、前記「ファイル生成に関係するハードウェアを特定する情報」とは、ファイル名生成装置のシリアル番号や、生成されたファイルが格納される記憶媒体のシリアル番号のことである。このように、連番と記憶媒体のシリアル番号とを組み合わせるだけでも、グローバルユニークな識別子を生成することができる。

ここで、前記ファイル名生成装置は、さらに、前記識別子生成手段によって生成されたグローバルユニークな識別子のハッシュ値を算出する算出手段を備え、前記ファイル名生成手段は、前記算出手段によって算出されたハッシュ値を含むファイル名を生成するようにしてもよい。これによって、グローバルユニークな識別子が所定長さの文字列に変換されることになり、ファイル名を短くすることが可能となる。

また、前記ハッシュ値は、Ｎ進数（Ｎ＞１０）の英数字で表現されるようにしてもよい。これによって、限られた文字数でより多くの値を表現することが可能となる。

また、前記ハッシュ値を含むファイル名は８文字以下とし、そのファイルの拡張子は３文字以下としてもよい。これによって、いわゆる８．３形式の短いファイル名しかサポートしていないファイルシステム上でも本発明を適用することが可能となる。

また、前記ファイル名生成装置は、さらに、前記ファイル名生成手段によって生成されたファイル名でマルチメディアデータを記憶媒体に格納する格納手段を備えてもよい。これによって、ビデオカメラ等の撮影装置において生成したマルチメディアデータをメモリカード等の記憶媒体に格納することが可能となる。

なお、本発明は、このようなファイル名生成装置として実現することができるだけでなく、このようなファイル名生成装置が備える特徴的な手段をステップとするファイル名生成方法として実現したり、それらのステップをコンピュータに実行させるプログラムとして実現したりすることもできる。そして、そのようなプログラムは、ＣＤ−ＲＯＭ等の記憶媒体やインターネット等の伝送媒体を介して配信することができるのは言うまでもない。

以上の説明から明らかなように、本発明に係るファイル名生成装置によれば、グローバルユニークな識別子を含むファイル名が生成されるので、複数台の装置によって生成されたファイル間でも、ファイル名が重複することがない。

以下、本発明の実施の形態について図面を用いて詳細に説明する。

（実施の形態１）
図１は、本発明を適用した編集システムの概略外観図である。ここでは、３台の撮影装置１０ａ、１０ｂ、１０ｃによって得られた映像や音声などのマルチメディアデータ（以下、単に「データ」という場合がある）を１台の編集機３０で編集する場面を想定している。撮影装置１０ａ、１０ｂ、１０ｃと編集機３０とは、それぞれ、記憶媒体２０ａ、２０ｂ、２０ｃを介してデータの受け渡しを行う。

撮影装置１０ａ、１０ｂ、１０ｃ（以下、個々の装置を区別しない場合は「撮影装置１０」という）は、映像や音声などのマルチメディアデータを生成するビデオカメラやデジタルスチルカメラ等である。記憶媒体２０ａ、２０ｂ、２０ｃ（以下、個々の媒体を区別しない場合は「記憶媒体２０」という）は、撮影装置１０によって生成されたデータを編集機３０に渡すためのメモリカードやハードディスク、光ディスク等である。編集機３０は、記憶媒体２０に格納されているデータを編集するためのソフトウェアが搭載されたＰＣ等である。

図２は、本実施の形態１における撮影装置１０の概略機能ブロック図である。図２に示されるように、撮影装置１０は、機能的には、撮影部１１とＵＭＩＤ（Ｕｎｉｑｕｅ Ｍａｔｅｒｉａｌ Ｉｄｅｎｔｉｆｉｅｒ）生成部１２と連番発行部１３とファイル名生成部１４と格納部１５とを備えている。撮影部１１は、映像データを生成するカメラ部や、音声データを生成するマイクロホン等から構成される。ＵＭＩＤ生成部１２は、撮影部１１によってデータが生成されると、後述するＵＭＩＤを生成する。連番発行部１３は、撮影部１１によってデータが生成されると、「０００１」等の連続番号（以下「連番」という）を発行する。ファイル名生成部１４は、ＵＭＩＤ生成部１２によって生成されたＵＭＩＤと、連番発行部１３によって発行された連番とを含むファイル名を生成する。格納部１５は、ファイル名生成部１４によって生成されたファイル名で、撮影部１１によって生成されたデータを記憶媒体２０に格納する。もちろん、本撮影装置１０は、当該装置を操作するための操作部や、記憶媒体２０に格納されているデータを再生するための再生部なども備えているが、これらは本発明の主眼とするところではないので、ここでは図示していない。

図３は、ＳＭＰＴＥ３３０Ｍで定義された拡張ＵＭＩＤのデータフォーマットを示す図である。ＵＭＩＤは、編集以前の素材（映像や音声など）をグローバルユニークに特定することができる識別子（世界中で唯一無二の識別子）であり、図３に示されるように、３２バイトの基本ＵＭＩＤ６３０と、３２バイトのソースパック６３１とからなる。

基本ＵＭＩＤ６３０は、１２バイトのユニバーサルラベル６３２と、１バイトの長さ６３３と、３バイトのインスタンスＮｏ６３４と、１６バイトのマテリアルＮｏ６３５とからなる。ユニバーサルラベル６３２のうち、第１バイトから第１０バイトまでは固定のバイト列であり、第１１および第１２バイトには、映像であるか音声であるかを表した情報と、マテリアルＮＯの生成の仕方を表した情報が設定される。長さ６３３は、インスタンスＮｏ６３４以降の長さである。インスタンスＮｏ６３４は、元素材であるかコピーされた素材であるかを表す。

マテリアルＮｏ６３５は、標準規格において定義されているいくつかの手法のうちの１つにより生成された０ではない番号であり、たとえば、７バイトの日時と、１バイトのタイムゾーン（又は乱数）と、８バイトのマシンノードとからなる（ＳＭＴＰＴＥ ３３０Ｍ Ａｎｎｅｘ Ａ Ａ．４ ＩＥＥＥ １３９４ ｎｅｔｗｏｒｋ ｍｅｔｈｏｄ）。7バイトの日時は、最初の４バイトが時刻であり、残り3バイトが日付である。マシンノードには、ＩＥＥＥ１３９４によって定義されたＥＵＩ−６４ネットワーク・ノードＩＤを使用することができる。又は、マテリアルＮｏ６３５は、８バイトのタイムスナップと、２バイトの乱数と、６バイトのマシンノードとからなる（ＳＭＴＰＴＥ ３３０Ｍ Ａｎｎｅｘ Ａ Ａ．１ ＳＭＰＴＥ ｍｅｔｈｏｄ）。タイムスナップは、フレーム、秒、分、時を表す値であり、これらの各値は、たとえば機器内部のタイムコードジェネレータが発生する時計情報から取得する。乱数は、たとえばソフトウェアで自走するＭ系列発生器から取得する。マシンノードは、最初の３バイトが組織名に与えられた固有の値であり、残り３バイトが使用機材に与えられた機材固有のシリアル番号である。

ソースパック６３１は、メタデータを表し、８バイトの時刻６３６、１２バイトの場所６３７、４バイトの国６３８、４バイトの組織６３９、４バイトのユーザ６４０からなる。これら情報はたとえばＧＰＳから取得することができる。

ここで、撮影装置１０は、編集との親和性を考慮して、映像データと音声データを別ファイルで記憶媒体２０に格納することとする。つまり、撮影時に複数のファイルが同時に生成されることになる。このように同時に生成された映像と音声のファイルをまとめてクリップと呼ぶ。このクリップには、映像と音声以外に、サムネールやメタデータが含まれることもある。また、クリップの構成要素である映像と音声のファイルのことをエッセンスファイルと呼ぶ。

図４は、本実施の形態１における撮影装置１０の動作を示すフローチャートである。以下、図４を用いて、本実施の形態１における撮影装置１０の動作を説明する。

まず、連番発行部１３は、「０００１」等の連番を発行して（Ｓ１１）、この連番をファイル名生成部１４に渡す。一方、ＵＭＩＤ生成部１２は、「０６０Ａ２Ｂ３４０１０１０１０５０１０１０Ｄ４３１３００００００ＢＥＦ８４６７Ｃ５３３００５ＣＣ００４０００１００４２０００２４」等の基本ＵＭＩＤを生成して（Ｓ１２）、この基本ＵＭＩＤをファイル名生成部１４に渡す。これによって、ファイル名生成部１４は、前記連番と前記基本ＵＭＩＤとを含むファイル名を生成して（Ｓ１３）、このファイル名を格納部１５に渡す。格納部１５は、ファイル名生成部１４によって生成されたファイル名で、図示しない撮像部によって生成されたデータをファイルとして記憶媒体２０に格納する（Ｓ１４）。

図５は、本実施の形態１におけるファイル名の形式を示す図である。４文字のＸＸＸＸ部６５０には、クリップ名（ここでは連番）が入る。この連番によってユーザへの可視性や理解容易性を確保することができる（後述する）。ＹＹ…ＹＹ部６５１には、ＡＳＣＩＩ表現された基本ＵＭＩＤ（ここでは６４文字のＡＳＣＩＩ文字）が入る。１文字のＺ部６５２には、音声ファイルである場合は、そのチャンネル番号が入る。３文字以内のＥＸＴ部６５３には、ファイルの拡張子が入る。

たとえば、撮影装置１０において１番目に撮影された１チャンネル目のＭＸＦ音声ファイルのファイル名は、「０００１＿０６０Ａ２Ｂ３４０１０１０１０５０１０１０Ｄ４３１３００００００ＢＥＦ８４６７Ｃ５３３００５ＣＣ００４０００１００４２０００２４＿０．ｍｘｆ」となる。ＭＸＦファイルについてはＳＭＰＴＥ３７７Ｍに定義されている。

図６は、記憶媒体２０におけるディレクトリ構造を示す図である。ここでは、Ｃｏｎｔｅｎｔｓディレクトリの下にＡｕｄｉｏディレクトリとＭｅｔａディレクトリとＶｉｄｅｏディレクトリとが存在する状態を表している。Ａｕｄｉｏディレクトリには音声データが格納され、Ｍｅｔａディレクトリにはメタデータが格納され、Ｖｉｄｅｏディレクトリには映像データが格納されている。すなわち、クリップごとにディレクトリが分かれるのではなく、エッセンスファイルの種別ごとにディレクトリが分かれる構造となっている。

図７は、編集機３０におけるディレクトリ構造を示す図である。ここでは、記憶媒体２０におけるディレクトリ構造と同様、Ｃｏｎｔｅｎｔｓディレクトリの下にＡｕｄｉｏディレクトリとＭｅｔａディレクトリとＶｉｄｅｏディレクトリとが存在する状態を表している。そして、「０００１＿０１５Ｃ２Ａ２３０１０１０１０８０１０１０Ｃ２１２３００００００ＣＤＣ５３４２Ａ３４５００２ＢＤ００２０００３００２１０００３５」という文字列を含むエッセンスファイルＦ１＿１、Ｆ１＿２、Ｆ１＿３と、「０００１＿０６０Ａ２Ｂ３４０１０１０１０５０１０１０Ｄ４３１３００００００ＢＥＦ８４６７Ｃ５３３００５ＣＣ００４０００１００４２０００２４」という文字列を含むエッセンスファイルＦ２＿１、Ｆ２＿２、Ｆ２＿３とが混在している状態を表している。

前述したクリップについて説明すると、クリップ名（連番）は「０００１」であり、基本ＵＭＩＤは「０６０Ａ２Ｂ３４０１０１０１０５０１０１０Ｄ４３１３００００００ＢＥＦ８４６７Ｃ５３３００５ＣＣ００４０００１００４２０００２４」である。したがって、このクリップのエッセンスファイルは、それぞれ、ファイル名の中に「０００１＿０６０Ａ２Ｂ３４０１０１０１０５０１０１０Ｄ４３１３００００００ＢＥＦ８４６７Ｃ５３３００５ＣＣ００４０００１００４２０００２４」という文字列を含むことになる。

ユーザは、この文字列を含むファイルＦ２＿１、Ｆ２＿２、Ｆ２＿３は、同一クリップのエッセンスファイルであると識別することができる。もちろん、１台の撮影装置１０内では、「０００１」というクリップ名（連番）をみるだけで、同一クリップのエッセンスファイルであると識別することができる。

以上のように、本実施の形態１によれば、基本ＵＭＩＤを含むファイル名が生成されるので、複数台の撮影装置によって生成されたファイル間でも、ファイル名が重複することがない。すなわち、複数台の撮影装置によって生成されたクリップを編集機の同一ディレクトリにコピーしても、ファイル名が重複することがないので、ファイル名の打ち直しやクリップの上書き消去という問題は発生しない。

なお、ここでは、基本ＵＭＩＤをファイル名に含めることとしているが、グローバルユニークな識別子をファイル名に含める以上、前記と同様の効果を得ることができる。ここで、ＵＭＩＤを生成するためには、前記したように、撮影装置１０のシリアル番号を取得することが必要である。ＵＭＩＤ以外のグローバルユニークな識別子を生成する手法を採用したとしても、その識別子は特定のホストに問い合わせて取得する必要があり、すべての撮影装置１０に適用するのは困難である。

そこで、簡便にグローバルユニークな識別子を生成する必要がある場合は、記憶媒体２０のシリアル番号を用いるようにしてもよい。すなわち、記憶媒体２０のシリアル番号をファイル名に含めれば、他の記憶媒体２０との間でファイル名が重複することはないので、あとは個々の記憶媒体２０内での一意性さえ保証できればよいことになる。記憶媒体２０内での一意性を保証するには、たとえば連番を用いることができる。すなわち、図８に示されるように、ＸＸＸＸ部６５０には連番を入れ、ＹＹ…ＹＹ部６７１には記憶媒体２０のシリアル番号を入れる。

図９は、グローバルユニークな識別子の内部構成例を示す図である。図９に示されるように、ファイルが生成された順番を特定する情報と、ファイル生成に関係するハードウェアを特定する情報とが含まれる文字列は、グローバルユニークな識別子ということができる。ここで、ファイルが生成された順番を特定する情報とは、たとえば、ファイルが生成された日時や、前記した連番のことである。一方、ファイル生成に関係するハードウェアを特定する情報とは、たとえば、撮影装置１０のシリアル番号や、撮影装置１０に装着されている記憶媒体２０のシリアル番号又はボリュームラベルのことである。

なお、グローバルユニークな識別子が含まれている以上、その他の情報がファイル名に含まれていてもよい。たとえば、基本ＵＭＩＤに代えて、拡張ＵＭＩＤをファイル名に含めるようにしてもよい。

なお、ここでは、基本ＵＭＩＤだけでなく連番をもファイル名に含めることとしているが、本発明はこれに限定されるものではない。すなわち、連番をファイル名に含めたのは、ユーザへの可視性や理解容易性を確保するためであるから、ファイル名が重複するという従来の課題を解決することだけを考えた場合は、連番をファイル名に含める必要はない。

なお、ここでは、撮影装置１０が自動的にファイル名を生成することを前提にしているので、連番をクリップ名としたが、本発明はこれに限定されるものではない。すなわち、クリップ名は、ユーザへの可視性や理解容易性を確保するための情報であるから、撮影の都度ユーザが任意のクリップ名を入力するようにしてもよい。

（実施の形態２）
前記実施の形態１では、長いファイル名（ロングファイル名）をサポートしているファイルシステムを前提として説明したが、一部のファイルシステムでは、長いファイル名をサポートしていない。たとえば、ＦＡＴファイルシステムでは、８文字以下の主ファイル名と３文字以下の拡張子とからなる、いわゆる８．３形式の短いファイル名（ショートファイル名）をサポートしている。

したがって、前記実施の形態１で説明したように、「０００１＿０６０Ａ２Ｂ３４０１０１０１０５０１０１０Ｄ４３１３００００００ＢＥＦ８４６７Ｃ５３３００５ＣＣ００４０００１００４２０００２４＿０．ｍｘｆ」というファイル名を生成したとしても、このファイルをＦＡＴファイルシステム上で管理する場合は、「０００１＿０６０〜．ｍｘｆ」というファイル名になり、ファイル名の重複を回避するという本発明の効果を得ることができない。以下、本実施の形態２における撮影装置１０の構成を前記実施の形態１と異なる点のみ説明する。

図１０は、ＦＡＴフォーマットを示す図である。メモリカードやハードディスク等の物理ドライブ６００は、通常、領域の先頭に置かれるマスターブートレコード６０２と、１個以上の論理ドライブ６０１から構成される。１個の論理ドライブ６０１は、１種類のファイルシステムでフォーマットされる。ＦＡＴフォーマットの場合、領域の先頭からパーティションブートセクタ６０３、ファイルアロケーションテーブル（ＦＡＴ）６０４、ＦＡＴのバックアップ６０４ｂ、ルートディレクトリエントリ６０５というシステム領域が配置され、システム領域の後ろにユーザデータ領域６０６が配置される。パーティションブートセクタ６０３には、パーティションのセクタ数といったパーティションを起動するのに必要な情報が格納される。ＦＡＴ６０４には、ファイルの格納情報が配置される。ユーザデータ領域６０６には、ファイルのデータ自体が置かれる。ファイルはクラスタと呼ばれる単位（通常４ＫＢ〜３２ＫＢ）で格納される。

図１１は、ＦＬＯＷＥＲ０２．ＡＶＩというファイル名を持つファイルのディレクトリエントリを示している。ルートディレクトリエントリ６０５には、ルートディレクトリに置かれているファイル又はディレクトリの情報がエントリとして格納される。階層構造のディレクトリにおいて、全てのファイル及びディレクトリは、図１１に示されるように、３２バイトからなるディレクトリエントリ６０７として格納される。このようにＦＡＴフォーマットにおいては、ファイルはファイル名が８文字、拡張子が３文字の８．３形式で格納される。ディレクトリエントリ６０７には、ファイルのデータが置かれる先頭のクラスタ番号６０８が含まれる。この先頭のクラスタ番号６０８によりファイルのデータにアクセスできる。

図１２は、ＦＡＴ６０４に配置されるファイルの格納情報を示す図である。ＦＡＴ６０４は、ユーザデータ領域６０６上のクラスタを管理するためのテーブルである。ＦＡＴ６０４には１２ビットや１６ビットといった単位でファイルの次のデータの存在するクラスタ番号を格納する。たとえば、ユーザデータ領域６０６に格納するファイル６２０を部分データ６２１、６２２、６２３に分けてクラスタ番号３、４、７のクラスタに格納する場合、ＦＡＴ６０４には、クラスタを連結するための情報として、クラスタ番号３の位置に４を格納し、クラスタ番号４の位置に７を格納する。最後にクラスタ番号７の位置に終了マークを格納する。ファイル６２０における先頭のクラスタ番号３は、前述のようにファイル６２０のディレクトリエントリ６０７に格納される。

図１３は、本実施の形態２における撮影装置１０の概略機能ブロック図である。図１３に示されるように、本実施の形態２における撮影装置１０は、算出部１６を追加した点を除き、前記実施の形態１における撮影装置１０と同じである。算出部１６は、ＵＭＩＤ生成部１２によって生成された基本ＵＭＩＤを用いてハッシュ値を算出する。この算出方法の詳細については後述する。

図１４は、本実施の形態２における撮影装置１０の動作を示すフローチャートである。以下、図１４を用いて、本実施の形態２における撮影装置１０の動作を説明する。

まず、連番発行部１３は、「０００１」等の連番を発行して（Ｓ２１）、この連番をファイル名生成部１４に渡す。一方、ＵＭＩＤ生成部１２は、「０６０Ａ２Ｂ３４０１０１０１０５０１０１０Ｄ４３１３００００００ＢＥＦ８４６７Ｃ５３３００５ＣＣ００４０００１００４２０００２４」等の基本ＵＭＩＤを生成して（Ｓ２２）、この基本ＵＭＩＤを算出部１６に渡す。これによって、算出部１６は、ＵＭＩＤ生成部１２によって生成された基本ＵＭＩＤを用いてハッシュ値を算出して（Ｓ２３）、このハッシュ値をファイル名生成部１４に渡す。これによって、ファイル名生成部１４は、前記連番と前記ハッシュ値とを含むファイル名を生成して（Ｓ２４）、このファイル名を格納部１５に渡す。格納部１５は、ファイル名生成部１４によって生成されたファイル名で、図示しない撮像部によって生成されたデータをファイルとして記憶媒体２０に格納する（Ｓ２５）。

図１５は、本実施の形態２におけるファイル名の形式を示す図である。ＸＸＸＸ部６６０には、４文字の連番が入る。ＹＹ部６６１には、２文字のハッシュ値が入る。ＺＺ部６６２には、２文字のチャンネル数が入る。なお、ＹＹ部６６１に入る情報は数字になることもあるため、可視性向上のために、音声データでない場合のＺＺ部６６２は０詰めとする。ＥＸＴ部６５３には、３文字以内のファイルの拡張子が入る。

図１６は、記憶媒体２０におけるディレクトリ構造を示す図である。たとえば、撮影装置１０において１番目に撮影された１チャンネル目のＭＸＦ音声ファイルのファイル名は、前記実施の形態１によると「０００１＿０６０Ａ２Ｂ３４０１０１０１０５０１０１０Ｄ４３１３００００００ＢＥＦ８４６７Ｃ５３３００５ＣＣ００４０００１００４２０００２４＿０．ｍｘｆ」であったところ、本実施の形態２によると「０００１ＵＱ０１．ｍｘｆ」になる。以下、ＹＹ部６６１に入れるハッシュ値「ＵＱ」を生成する手順を説明する。

図１７は、ハッシュ値「ＵＱ」を生成する手順を示す図である。
まず、基本ＵＭＩＤ「０６０Ａ２Ｂ３４０１０１０１０５０１０１０Ｄ４３１３００００００ＢＥＦ８４６７Ｃ５３３００５ＣＣ００４０００１００４２０００２４」からマテリアルＮｏ「ＢＥＦ８４６７Ｃ５３３００５ＣＣ００４０００１００４２０００２４」を抽出する（Ｓ１０１）。次に、このように抽出したマテリアルＮｏを、「ＢＥＦ８」「４６７Ｃ」「５３３０」「０５ＣＣ」「００４０」「００１０」「０４２０」「００２４」のように、２バイトずつ８ブロックに区切る（Ｓ１０２）。次に、このように区切った２バイトのＡＳＣＩＩ文字を、｛０ｘＦ８ＢＥ、０ｘ７Ｃ４６、０ｘ３０５３、０ｘＣＣ０５、０ｘ４０００、０ｘ１０００、０ｘ２００４、０ｘ２４００｝のように、リトルエンディアンにより２バイトの数字に変更する（Ｓ１０３）。次に、これら２バイト数字８個の各ビットの排他的論理和０ｘ２ＣＡＡを求める（Ｓ１０４）。次に、このように求めた排他的論理和０ｘ２ＣＡＡを、３６進数２桁のうち最大の素数である１２９１で割ったときの余り１１０６を求める（Ｓ１０５）。最後に、その余り１１０６を０詰めの３６進数２桁で表現し、ＵＱというハッシュ値を得る（Ｓ１０６）。

以上のように、本実施の形態２によれば、グローバルユニークな識別子のハッシュ値をファイル名に含めるようにしているので、同じローカル識別子（連番）を持つファイル同士でも、そのファイル名が重複する確率を１２９１分の１にまで低減させることができる。

なお，ここでは、ハッシュ値が２文字である場合を例示しているが、ハッシュ値が３文字以上の場合（Ｎ文字の場合）には、Ｓ１０２においてマテリアルＮｏをＮバイトずつ区切ればよい。また、Ｓ１０３においてＡＳＣＩＩ文字をリトルエンディアンにより数字に変更することとしているが、ビッグエンディアンにより数字に変更してもよい。さらに、Ｓ１０５では、０〜９およびＡ〜Ｚを用いて３６進表現することとしているが、使用する英数字を減らしたり、ファイル名として使用可能な記号を加えたりすることで、３６進数以外の表現とすることも可能である。

なお、ここでは、いわゆる８．３形式の短いファイル名を生成することを前提に説明したが、グローバルユニークな識別子のハッシュ値をファイル名に含める方法は、長いファイル名など８．３形式以外のファイル名の生成方法としても有効である。

なお、ここでは、グローバルユニークな識別子のハッシュ値をファイル名に含めることによって、いわゆる８．３形式の短いファイル名を生成することとしているが、本発明はこれに限定されるものではない。すなわち、撮影装置１０毎に異なる識別子をユーザが事前に撮影装置１０に設定しておき、その設定された識別子をファイル名生成部１４がＹＹ部６６１に入れるようにしてもよい。

なお、ここでは、マテリアルＮｏのハッシュ値を算出することとしているが、本発明はこれに限定されるものではない。すなわち、グローバルユニークな識別子のハッシュ値を算出する構成である以上、前記と同様の効果を得ることができる。

（実施の形態３）
前記実施の形態１と２では、グローバルユニークな識別子を含むファイル名を生成する手法について説明した。本実施の形態３では、グローバルユニークな識別子を含むファイル名のファイルを編集機３０において検索する手法について説明する。

図１８は、編集機３０の概略機能ブロック図である。この編集機３０は、機能的には、格納部３１と記憶部３２と入力部３３と検索部３４と表示部３５とを備えている。格納部３１は、記憶媒体２０上のデータを記憶部３２にコピー（格納）する。記憶部３２は、データを記憶するためのハードディスク等である。入力部３３は、情報を入力するためのキーボード等である。検索部３４は、入力部３３によって入力された情報をもとに記憶部３２を検索する。表示部３５は、検索部３４によって検索された情報を表示するディスプレイ等である。

図１９は、編集機３０における検索動作を示すフローチャートである。図２０(Ａ)は、編集機３０において表示される検索キーワード入力画面の一例を示す図である。図２０(Ｂ)は、編集機３０において表示される検索結果画面の一例を示す図である。以下、図１９及び図２０(Ａ)(Ｂ)を用いて、編集機３０における検索動作を説明する。

まず、表示部３５には、図２０（Ａ）に示されるように、検索キーワードを入力するための画面が表示される。ここで、ユーザが入力部３３を用いて「２００４年４月１日１２時３０分」等の撮影開始日時を入力欄Ｌに入力して実行ボタンＢをクリックすると（Ｓ３１）、この検索キーワード「２００４年４月１日１２時３０分」は検索部３４に受け付けられる。

ここで、検索部３４は、検索キーワード「２００４年４月１日１２時３０分」を用いて、ＵＭＩＤにおけるタイムスナップを生成する（Ｓ３２）。すなわち、ＵＭＩＤにタイムスナップを入れる方式は、年月日時分秒フレームを８バイトのデータに入れる方式であるので、２００４年４月１日１２時３０分００秒００フレームは、データ列｛０ｘ８７、 ０ｘ０Ａ、 ０ｘ２５、 ０ｘ０５、 ０ｘ９６、 ０ｘ３０、 ０ｘ０５、 ０ｘ８０｝で表現される。したがって、撮影開始日時が「２００４年４月１日１２時３０分」のファイルの名称には、「８７０Ａ２５０５９６３００５８０」の文字列が含まれることになる。

そこで、検索部３４は、記憶部３２を検索して（Ｓ３３）、ファイル名に「８７０Ａ２５０５９６３００５８０」の文字列が含まれるファイルを検索し、表示部３５に渡す。この結果、図２０（Ｂ）に示されるように、表示部３５には、撮影開始日時が「２００４年４月１日１２時３０分」のファイルの一覧が表示されることになる（Ｓ３４）。

以上のように、本実施の形態３によれば、グローバルユニークな識別子を含むファイル名でファイルを生成した場合でも、そのファイルを編集機等において容易に検索することができる。

なお、ここでは、撮影開始日時を検索キーワードとしているが、検索キーワードは特に限定されるものではない。たとえば、「東京」や「大阪」など、撮影した場所を検索キーワードとしてもよい。ただし、撮影した場所の情報は、基本ＵＭＩＤに含まれていないので、この場合は、たとえば拡張ＵＭＩＤをファイル名に含める必要がある。又は、以下のような対応表を予め作成しておけば、基本ＵＭＩＤをファイル名に含めるようにした場合でも、撮影した場所をもとに検索をすることができる。

図２１は、ＵＭＩＤと撮影場所とを対応付けた表の一例を示す図である。ここでは、説明を簡略化するために、ＵＭＩＤの詳細は省略して、単にＵＭＩＤ＿１〜ＵＭＩＤ＿４とだけ記載している。ＵＭＩＤ＿１と東京とが対応付けされているのは、ＵＭＩＤ＿１のファイルに収められている素材が東京で撮影されたことを表している。ＵＭＩＤ＿２と大阪、ＵＭＩＤ＿３と東京がそれぞれ対応付けされている意味も同様である。この対応表Ｔを作成するタイミングは、撮影装置１０から記憶媒体２０が外される前（ファイルを記憶媒体２０から編集機３０にコピーする前）であればよく、特に限定されるものではない。

たとえば、ファイルの中にソースパックを含める構成を採用している場合は、撮影装置１０から記憶媒体２０が外される前に、格納部３１がファイルを開いてソースパックから場所情報を取得する。そして、この場所情報をもとに前記のような対応表Ｔを作成して、この対応表Ｔを記憶媒体２０に格納しておく。さらに、この記憶媒体２０を編集機３０側で読み取って、その中に記憶されている対応表Ｔを編集機３０側の記憶部３２にコピーしておく。このようにすれば、たとえば、検索キーワードとして「東京」が入力された場合でも、この検索キーワード「東京」をもとに対応表Ｔを検索して、「東京」に対応するＵＭＩＤ＿１、ＵＭＩＤ＿３等を抽出することができる。

なお、前記の説明では特に言及しなかったが、従来の検索方法によると、ファイルを開いて中身を参照する必要があった。たとえば、検索キーワードとして撮影開始日時が入力された場合、従来は、ファイル名から撮影開始日時を知ることができないので、ファイルを開いて、その中に設定されているソースパックを参照する必要があった。それに対して、本実施の形態３によると、前記したようにファイル名だけで撮影開始日時を知ることができるので、ファイルを開く必要がない。すなわち、検索処理に要する時間を短縮することができるという効果がある。

なお、前記実施の形態２では、グローバルユニークな識別子のハッシュ値をファイル名に含めることとしているが、この場合にも、同様の手順で検索することができる。たとえば、ユーザが入力部３３を用いて「２００４年４月１日１２時３０分」等の撮影開始日時を入力欄Ｌに入力して実行ボタンＢをクリックすると、検索部３４は、この検索キーワード「２００４年４月１日１２時３０分」をもとに、前記した手順で「８７０Ａ２５０５９６３００５８０」の文字列を得る。そして、この文字列「８７０Ａ２５０５９６３００５８０」のハッシュ値を算出し、その値がファイル名に含まれるファイルを検索するようになっている。もっとも、ハッシュ値の算出は検索部３４が行ってもよいし、前記実施の形態２と同様、検索部３４とは別の算出部１６が行ってもよい。

なお、ここでは、グローバルユニークな識別子をもとにファイルを検索することとしているが、連番（ローカルな識別子）をもとにファイルを検索してもよいのはもちろんである。

また、ここでは、映像データと音声データのファイル名を生成する手法について説明したが、本発明はこれに限定されるものではない。すなわち、その他の素材についてファイル名を生成する場合にも、本発明を適用することができる。

本発明に係るファイル名生成装置は、ファイル名の重複を回避することが必要なビデオカメラやデジタルスチルカメラ等の用途にも適用できる。

図１は、本発明を適用した編集システムの概略外観図である。 図２は、実施の形態１における撮影装置の概略機能ブロック図である。 図３は、拡張ＵＭＩＤのデータフォーマットを示す図である。 図４は、実施の形態１における撮影装置の動作を示すフローチャートである。 図５は、実施の形態１におけるファイル名の形式を示す図である。 図６は、記憶媒体におけるディレクトリ構造を示す図である。 図７は、編集機におけるディレクトリ構造を示す図である。 図８は、実施の形態１における別のファイル名の形式を示す図である。 図９は、グローバルユニークな識別子の内部構成例を示す図である。 図１０は、ＦＡＴフォーマットを示す図である。 図１１は、ディレクトリエントリを示す図である。 図１２は、ＦＡＴに配置されるファイルの格納情報を示す図である。 図１３は、実施の形態２における撮影装置の概略機能ブロック図である。 図１４は、実施の形態２における撮影装置の動作を示すフローチャートである。 図１５は、実施の形態２におけるファイル名の形式を示す図である。 図１６は、記憶媒体におけるディレクトリ構造を示す図である。 図１７は、ハッシュ値を生成する手順を示す図である。 図１８は、編集機の概略機能ブロック図である。 図１９は、編集機における検索動作を示すフローチャートである。 図２０(Ａ)は、編集機において表示される検索キーワード入力画面の一例を示す図である。図２０(Ｂ)は、編集機において表示される検索結果画面の一例を示す図である。 図２１は、ＵＭＩＤと撮影場所とを対応付けた表の一例を示す図である。

符号の説明

１０ ビデオカメラ
１１ 撮影部
１２ ＵＭＩＤ生成部
１３ 連番発行部
１４ ファイル名生成部
１５ 格納部
１６ 算出部
２０ 記憶媒体
３０ 編集機
６００ 物理ドライブ
６０１ 論理ドライブ
６０２ マスターブートレコード
６０３ パーティションブートセクタ
６０４ ファイルアロケーションテーブル＃１
６０４ｂ ファイルアロケーションテーブル＃２
６０５ ルートディレクトリエントリ
６０６ ユーザデータ
６０７ ディレクトリエントリ
６０８ 先頭のクラスタ番号
６１０ クラスタ
６１１ クラスタ番号
６２０ ファイル
６２１ 部分データ
６３０ 基本ＵＭＩＤ
６３１ ソースパック
６３２ ユニバーサルラベル
６３３ 長さ（有効データ長）
６３４ インスタンスＮｏ
６３５ マテリアルＮｏ
６３６ 時間
６３７ 場所
６３８ 国
６３９ 組織
６４０ ユーザ
６５０ クリップ名
６５１ ＡＳＣＩＩ表現された基本ＵＭＩＤ
６５２ チャンネル番号
６５３ 拡張子
６６０ 格納の順番
６６１ ＵＭＩＤのハッシュ値
６６２ チャンネル番号
６７１ メディアのシリアル番号

Claims (9)

1. ファイル名を生成する装置であって、
   ファイルが生成された順番を特定する情報と、ファイル生成に関係するハードウェアを特定する情報とが含まれる識別子を生成する識別子生成手段と、
   前記識別子生成手段によって生成された前記識別子のハッシュ値として、ファイル名を構成する文字として許容されたＮ文字の前記ハッシュ値を算出する算出手段と、
   ファイルが生成される度に番号を発行する番号発行手段と、
   前記算出手段によって算出されたＮ文字の前記ハッシュ値と、前記番号発行手段によって発行された前記番号とを含むファイル名を生成するファイル名生成手段とを備え、
   前記算出手段は、前記識別子をＮバイトずつ複数のブロックに区切り、得られたブロックの全てを用いて排他的論理和を求めることによりＮバイトの演算値を得、得られたＮバイトの演算値を、Ｌ進数（Ｌ＞１０）Ｎ桁のうち最大の素数で割ったときの余りを求め、求めた余りをＬ進数（Ｌ＞１０）の英数字で表現することによりＮ文字の前記ハッシュ値とする
   ことを特徴とするファイル名生成装置。
2. 前記識別子生成手段は、ファイルが生成された日時、及びファイルが生成された順番を示す連続番号のうち少なくともいずれか一方と、生成されたファイルが格納される記憶媒体のシリアル番号とが含まれる識別子を生成する
   ことを特徴とする請求項１記載のファイル名生成装置。
3. 前記識別子生成手段は、ファイルが生成されたときに生成される乱数と、ファイル名生成装置のシリアル番号、及び生成されたファイルが格納される記憶媒体のシリアル番号のうち少なくともいずれか一方とが含まれる識別子を生成する
   ことを特徴とする請求項１記載のファイル名生成装置。
4. 前記算出手段は、２文字の前記ハッシュ値を生成し、
   前記番号発行手段は、４文字の前記番号を発行し、
   前記ファイル名生成手段は、前記算出手段によって算出された２文字の前記ハッシュ値と、前記番号発行手段によって発行された４文字の前記番号とを含むファイル名を生成する
   ことを特徴とする請求項１記載のファイル名生成装置。
5. 前記算出手段は、２文字の前記ハッシュ値を生成し、
   前記番号発行手段は、４文字の前記番号を発行し、
   前記ファイル名生成手段は、前記算出手段によって算出された２文字の前記ハッシュ値と、前記番号発行手段によって発行された４文字の前記番号と、２文字のチャンネル番号とを含むファイル名を生成する
   ことを特徴とする請求項１記載のファイル名生成装置。
6. 前記ファイル名生成装置は、さらに、
   前記ファイル名生成手段によって生成されたファイル名でマルチメディアデータを記憶媒体に格納する格納手段を備える
   ことを特徴とする請求項１記載のファイル名生成装置。
7. 前記識別子生成手段は、前記識別子として、ＳＭＰＴＥ３３０Ｍで定義されるＵＭＩＤ（Ｕｎｉｑｕｅ Ｍａｔｅｒｉａｌ Ｉｄｅｎｔｉｆｉｅｒ）を生成する
   ことを特徴とする請求項１記載のファイル名生成装置。
8. ファイル名を生成する方法であって、
   ファイルが生成された順番を特定する情報と、ファイル生成に関係するハードウェアを特定する情報とが含まれる識別子を生成する識別子生成ステップと、
   前記識別子生成ステップにおいて生成された前記識別子のハッシュ値として、ファイル名を構成する文字として許容されたＮ文字の前記ハッシュ値を算出する算出ステップと、
   ファイルが生成される度に番号を発行する番号発行ステップと、
   前記算出ステップにおいて算出されたＮ文字の前記ハッシュ値と、前記番号発行ステップにおいて発行された前記番号とを含むファイル名を生成するファイル名生成ステップとを含み、
   前記算出ステップでは、前記識別子をＮバイトずつ複数のブロックに区切り、得られたブロックの全てを用いて排他的論理和を求めることによりＮバイトの演算値を得、得られたＮバイトの演算値を、Ｌ進数（Ｌ＞１０）Ｎ桁のうち最大の素数で割ったときの余りを求め、求めた余りをＬ進数（Ｌ＞１０）の英数字で表現することによりＮ文字の前記ハッシュ値とする
   ことを特徴とするファイル名生成方法。
9. ファイル名を生成するためのプログラムであって、
   ファイルが生成された順番を特定する情報と、ファイル生成に関係するハードウェアを特定する情報とが含まれる識別子を生成する識別子生成ステップと、
   前記識別子生成ステップにおいて生成された前記識別子のハッシュ値として、ファイル名を構成する文字として許容されたＮ文字の前記ハッシュ値を算出する算出ステップと、
   ファイルが生成される度に番号を発行する番号発行ステップと、
   前記算出ステップにおいて算出されたＮ文字の前記ハッシュ値と、前記番号発行ステップにおいて発行された前記番号とを含むファイル名を生成するファイル名生成ステップとをコンピュータに実行させるためのプログラムであって、
   前記算出ステップでは、前記識別子をＮバイトずつ複数のブロックに区切り、得られたブロックの全てを用いて排他的論理和を求めることによりＮバイトの演算値を得、得られたＮバイトの演算値を、Ｌ進数（Ｌ＞１０）Ｎ桁のうち最大の素数で割ったときの余りを求め、求めた余りをＬ進数（Ｌ＞１０）の英数字で表現することによりＮ文字の前記ハッシュ値とする
   ことを特徴とするプログラム。

Images