JP4474716B2 - 編集装置、編集方法 - Google Patents
編集装置、編集方法 Download PDFInfo
- Publication number
- JP4474716B2 JP4474716B2 JP2000032665A JP2000032665A JP4474716B2 JP 4474716 B2 JP4474716 B2 JP 4474716B2 JP 2000032665 A JP2000032665 A JP 2000032665A JP 2000032665 A JP2000032665 A JP 2000032665A JP 4474716 B2 JP4474716 B2 JP 4474716B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- file
- recording
- management
- frame
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明はファイルが記憶される記録媒体、及びこの記録媒体に記憶されたファイルに対する編集を行うことのできる編集装置、編集方法に関するものである。
【０００２】
【従来の技術】
近年、例えばフラッシュメモリなどの固体記憶素子を搭載した小型の記録媒体を形成し、専用のドライブ装置や、或いはドライブ装置をオーディオ／ビデオ機器、情報機器などに内蔵して、コンピュータデータ、画像データ、音声データなどを記憶できるようにするものが開発されている。
【０００３】
【発明が解決しようとする課題】
ところで、このような固体記憶素子を利用した記憶システムにおいては、記憶したファイルに対する編集処理を行うことが求められている。
そしてさらに、単に編集可能とするだけでなく、その編集処理がより効率化されること、例えば記録媒体内でのファイル編集のために必要となるデータ移動・複製・書換などが最小限であることや、編集のための処理時間や消費電力を最小限とすることが要求されている。
【０００４】
【課題を解決するための手段】
本発明はこのような要望に応じて、効率的な編集処理を実現できる記憶システムを構築することを目的とする。
【０００７】
また本発明の編集装置は、記録媒体に記録された、固定長の記録データブロックを１または複数連結した主データと、上記主データに付加されて上記主データの上記記録媒体におけるアドレスとして示される記録位置及び再生されない無効データの位置を上記アドレスの更新により管理可能とする管理データとから構成されるデータファイルを、分割する編集装置として、上記データファイルを分割する分割位置を指定して、上記分割位置のアドレスにおいて前後となる第１のデータファイルと第２のデータファイルに分割することを指示できる操作手段と、上記操作手段の分割指示に応じて、上記管理データにおける主データの記録位置及び無効データの位置を更新して第１の管理データとすることで、該第１の管理データで管理される上記第１のデータファイルが生成される第１データファイル生成手段と、上記操作手段の分割指示に応じて、主データの記録位置及び無効データの位置を管理する第２の管理データを生成し、上記分割位置より後のデータファイル部分に付加することで、上記第２の管理データで管理される上記第２のデータファイルが生成される第２データファイル生成手段と、を備え、上記第１の管理データが管理する無効データは、少なくとも上記分割位置を含む上記記録データブロックのうちの、上記分割位置より後ろに位置されていた主データ部分であり、上記第２の管理データが管理する無効データは、少なくとも上記分割位置を含む上記記録データブロックのうちの、上記分割位置より前に位置されていた主データであるようにする。
【０００８】
さらに本発明では、記録媒体に記録された、固定長の記録データブロックを１または複数連結した主データと、上記主データに付加されて上記主データの上記記録媒体におけるアドレスとして示される記録位置及び再生されない無効データの位置を上記アドレスの更新により管理可能とする管理データとから構成されるデータファイルを分割する編集装置における編集方法として、上記データファイルを、第１のデータファイルと第２のデータファイルに分割するための分割位置を設定する設定手順と、上記設定手順で設定された分割位置に基づいて、上記管理データにおける主データの記録位置及び無効データの位置を更新して第１の管理データとすることで、該第１の管理データで管理される上記第１のデータファイルが生成されるようにする第１データファイル生成手順と、上記設定手順で設定された分割位置に基づいて、主データの記録位置及び無効データの位置を管理する第２の管理データを生成し、上記分割位置よりアドレスにおいて後のデータファイル部分に付加することで、上記第２の管理データで管理される上記第２のデータファイルが生成されるようにする第２データファイル生成手順と、が行われ、上記第１の管理データが管理する無効データは、少なくとも上記分割位置を含む上記記録データブロックのうちの、上記分割位置よりアドレスにおいて後ろに位置されていた主データ部分であり、上記第２の管理データが管理する無効データは、少なくとも上記分割位置を含む上記記録データブロックのうちの、上記分割位置よりアドレスにおいて前に位置されていた主データであるようにする。
【０００９】
即ち本発明では、データファイル毎に管理データが記録され、その管理データが書き換えられること、必要に応じて分割位置を含む単位データが複製されること、及び管理データ内で再生対象としない部分を設定できることで、データファイルを分割するという編集のために必要となるデータ移動・複製・書換を最小限とする。そしてまたそれによって編集のための処理時間や消費電力を最小限とするものである。
【００１０】
【発明の実施の形態】
以下、本発明の実施の形態について説明する。なお、実施の形態としての記録媒体は板状の外形形状を有する板状メモリとし、また本発明の編集装置、編集方法は、板状メモリに対してファイルの記録再生を行うことのできるドライブ装置及びそのドライブ装置による編集方法が相当するものとする。
説明は次の順序で行う。
１．板状メモリの外形形状
２．板状メモリのフォーマット
２−１．メモリファイルシステム処理階層
２−２．物理的データ構造
２−３．物理アドレス及び論理アドレスの概念
２−４．論理−物理アドレス変換テーブル
３．ドライブ装置の構成
４．ＦＡＴ構造
５．板状メモリのファイル構造
５−１ ディレクトリ構成
５−２ メッセージリストファイル
５−３ メッセージデータファイル
６．デバイド編集処理
【００１１】
１．板状メモリの外形形状
まず図１により、本例の記録媒体である、板状メモリ１の外形形状について説明する。
板状メモリ１は、例えば図１に示すような板状の筐体内部に例えば所定容量ののメモリ素子を備える。本例としては、このメモリ素子としてフラッシュメモリ（Flash Memory）が用いられるものである。
図１に平面図、正面図、側面図、底面図として示す筐体は例えばプラスチックモールドにより形成され、サイズの具体例としては、図に示す幅Ｗ１１、Ｗ１２、Ｗ１３のそれぞれが、Ｗ１１＝６０ｍｍ、Ｗ１２＝２０ｍｍ、Ｗ１３＝２．８ｍｍとなる。
【００１２】
筐体の正面下部から底面側にかけて例えば９個の電極を持つ端子部２が形成されており、この端子部２から、内部のメモリ素子に対する読出又は書込動作が行われる。
筐体の平面方向の左上部は切欠部３とされる。この切欠部３は、この板状メモリ１を、例えばドライブ装置本体側の着脱機構へ装填する際などに挿入方向を誤ることを防止するためのものとなる。
また筐体底面側には使用性の向上のため滑り止めを目的とした凹凸部４が形成されている。
さらに底面側には、記憶内容の誤消去を防止する目的のスライドスイッチ５が形成されている。
【００１３】
２．板状メモリのフォーマット
２−１．メモリファイルシステム処理階層
続いて、板状メモリ１を記録媒体とするシステムにおけるフォーマットについて説明していく。
図２は、板状メモリ１を記録媒体とするシステムのファイルシステム処理階層を示すものである。
この図に示すように、ファイルシステム処理階層としては、アプリケーション処理層の下に、順次、ファイル管理処理層、論理アドレス層、物理アドレス層、フラッシュメモリアクセスがおかれる。
この階層では、ファイル管理処理層がいわゆるＦＡＴ（File Allocation Table）となる。
また、この図から分かるように、本例のファイルシステムでは論理アドレス及び物理アドレスという概念が導入されているが、これについては後述する。
【００１４】
２−２．物理的データ構造
図３には、板状メモリ１内の記憶素子である、フラッシュメモリの物理的データ構造が示されている。
フラッシュメモリとしての記憶領域は、セグメントという固定長のデータ単位が大元となる。このセグメントは、１セグメントあたり４ＭＢ（メガバイト）或いは８ＭＢとして規定されるサイズであり、１つのフラッシュメモリ内におけるセグメント数は、そのフラッシュメモリの容量に依存して異なってくる。
【００１５】
そして、この１セグメントを図３（ａ）に示すように、ブロックという固定長のデータ単位として８ＫＢ（キロバイト）又は１６ＫＢにより区切るようにされる。原則として、１セグメントは５１２ブロックに区切られることから、図３（ａ）に示すブロックｎについては、ｎ＝５１１とされることになる。但し、フラッシュメモリでは、書き込み不可な損傷エリアであるディフェクトエリアとしてのブロック数が所定数の範囲で許可されているため、データ書き込みが有効とされる実質的なブロック数を対象とすれば、上記ｎは５１１よりも少なくなる。
【００１６】
図３（ａ）に示すようにして形成されるブロック０〜ｎのうち、先頭の２つのブロック０，１はブートブロックといわれる。但し、実際には有効なブロックの先頭から２つのブロックがブートブロックとして規定されることになっており、必ずしもブートブロックがブロック０，１である保証はない。
そして、残りのブロックが、ユーザデータが格納されるユーザブロックとなる。
【００１７】
１ブロックは、図３（ｄ）に示すようにして、ページ０〜ｍにより分割される。１ページの容量は、図３（ｅ）に示すように、５１２バイトのデータエリアと１６バイトの冗長部よりなる、５２８（＝５１２＋１６）バイトの固定長とされる。なお、冗長部の構造については図３（ｆ）により後述する。
また、１ブロック内のページ数としては、１ブロックの容量が８ＫＢの場合には１６ページ、１６ＫＢの場合には３２ページとなる。
【００１８】
このような、図３（ｄ）（ｅ）に示されるブロック内のページ構造は、上記ブートブロックとユーザブロックとで共通である。
また、フラッシュメモリでは、データの読み出し、及び書き込みはページ単位で行われ、データの消去はブロック単位で行われるものとされる。そして、データの書き込みは、消去済みのページに対してしか行われないものとされている。従って、実際のデータの書き換えや書き込みは、ブロック単位を対象として行われることになる。
【００１９】
先頭のブートブロックは、図３（ｂ）に示すように、ページ０に対してヘッダーが格納され、ページ１には初期不良データの位置（アドレス）を示す情報が格納される。また、ページ２にはＣＩＳ／ＩＤＳといわれる情報が格納される。
２つめのブートブロックは図３（ｃ）に示すように、ブートブロックとしてのバックアップのための領域とされている。
【００２０】
図３（ｅ）に示された冗長部（１６バイト）は、図３（ｆ）に示す構造を有する。
この冗長部は、図のように先頭の第０バイト〜第２バイトの３バイトが、データエリアのデータ内容の更新に応じて書き換えが可能なオーバーライトエリアとされる。このオーバーライトエリアのうち、第０バイトにはブロックステータスが格納され、第１バイトにはデータステータスが格納される(Block Flag Data)。また、第２バイトの上位の所定ビットを利用して変換テーブルフラグ(Page Data Status1)が格納される。
【００２１】
原則として第３バイト〜第１５バイトは、その内容が現ページのデータ内容に応じて固定とされ、書き換えが不可とされる情報が格納される領域となる。
第３バイトには管理フラグ(Block Info)が格納され、第４，第５バイトから成る２バイトの領域には、後述する論理アドレス(Logic Address)が格納される。第６〜第１０バイトの５バイトの領域は、フォーマットリザーブの領域とされ、続く第１１，第１２バイトの２バイトが、上記フォーマットリザーブに対して誤り訂正を施すための分散情報ＥＣＣを格納する領域とされる。
残る第１３〜第１５バイトには、図３（ｅ）に示すデータエリアのデータに対して誤り訂正を行うためのデータＥＣＣが格納される。
【００２２】
上記図３（ｆ）に示した冗長部の第３バイトに格納される管理フラグは、図４に示すようにして、ビット７〜ビット０の各ビットに、その内容が定義されている。
ビット７，６、及びビット１，０はリザーブ（未定義）領域とされている。
ビット５は現ブロックに対してのアクセス許可の「有効」（‘１’；Free）／「無効」(‘０’；Read Protected）を示すフラグが格納される。ビット４には現ブロックについてのコピー禁止指定（‘１’；ＯＫ ／‘０’；ＮＧ）についてのフラグが格納される。
【００２３】
ビット３は変換テーブルフラグとされる。この変換テーブルフラグは、現ブロックが後述する論理−物理アドレス変換テーブルであるのか否かを示す識別子であり、このビット３の値が‘０’とされていれば、現ブロックは論理−物理アドレス変換テーブルであることが識別され、‘０’であれば無効となる。つまり、現ブロックは論理−物理アドレス変換テーブルではないことが識別される。
【００２４】
ビット２はシステムフラグが格納され、‘１’であれば現ブロックがユーザブロックであることが示され、‘０’であればブートブロックであることが示される。
【００２５】
ここで、セグメント及びブロックと、フラッシュメモリ容量との関係を図８（左３列を参照）により説明しておく。
板状メモリ１のフラッシュメモリ容量としては、４ＭＢ，８ＭＢ，１６ＭＢ，３２ＭＢ，６４ＭＢ，１２８ＭＢの何れかであるものとして規定されている。
そして、最も容量の小さい４ＭＢの場合であると、１ブロックは８ＫＢと規定された上で、そのブロック数としては５１２個とされる。つまり、４ＭＢはちょうど１セグメントの容量を有するものとされる。そして、４ＭＢの容量であれば、同様に１ブロック＝８ＫＢの容量が規定された上で、２セグメント＝１０２４ブロックとなる。なお、前述したように、１ブロック＝８ＫＢであれば、１ブロック内のページ数は１６ページとなる。
但し１６ＭＢの容量では、１ブロックあたりの容量として８ＫＢと１６ＫＢの両者が存在することが許可されている。このため、２０４８ブロック＝４セグメント（１ブロック＝８ＫＢ）のものと、１０２４ブロック＝２セグメント（１ブロック＝１６ＫＢ）のものとの２種類が在ることになる。１ブロック＝１６ＫＢの場合には、１ブロック内のページ数は３２ページとなる。
【００２６】
また、３２ＭＢ，６４ＭＢ，１２８ＭＢの容量では、１ブロックあたりの容量は１６ＫＢのみであるとして規定される。従って、３２ＭＢでは２０４８ブロック＝４セグメントとなり、６４ＭＢでは４０９６ブロック＝８セグメントとなり、１２８ＭＢでは８１９２ブロック＝１６セグメントとなる。
【００２７】
２−３．物理アドレス及び論理アドレスの概念
次に、上述したようなフラッシュメモリの物理的データ構造を踏まえたうえで、図５に示すデータ書き換え動作に従って、本例のファイルシステムにおける物理アドレスと論理アドレスの概念について説明する。
【００２８】
図５（ａ）には、或るセグメント内から４つのブロックを抜き出して、これを模式的に示している。
各ブロックに対しては物理アドレスが付される。この物理アドレスはメモリにおけるブロックの物理的な配列順に従って決まるもので、或るブロックとこれに対応付けされた物理アドレスとの関係は不変となる。ここでは、図５（ａ）に示す４ブロックに対して、上から順に物理アドレスの値として、１０５，１０６，１０７，１０８が付されている。なお、実際の物理アドレスは２バイトにより表現される。
【００２９】
ここで、図５（ａ）に示すように、物理アドレス１０５，１０６で示されるブロックがデータの記憶されている使用ブロックで、物理アドレス１０７，１０８で示されるブロックがデータが消去（即ち、未記録領域）された未使用ブロックとなっている状態であるとする。
【００３０】
そして、論理アドレスであるが、この論理アドレスは、ブロックに対して書き込まれたデータに付随するようにして割り振られるアドレスとされる。そして、この論理アドレスが、後述するＦＡＴファイルシステムが利用するアドレスとされている。
図５（ａ）では、４つの各ブロックに対して、上から順に論理アドレスの値として、１０２，１０３，１０４，１０５が付されている状態が示されている。なお、論理アドレスも実際には２バイトにより表現されるものである。
【００３１】
ここで、上記図５（ａ）に示す状態から、例えば物理アドレス１０５に格納されているデータの更新として、内容の書き換え又は一部消去を行うとする。
このような場合、フラッシュメモリのファイルシステムでは、同じブロックに対して更新したデータを再度書き込むことはせずに、未使用のブロックに対してその更新したデータを書き込むようにされる。
つまり、例えば図５（ｂ）に示すようにして、物理アドレス１０５のデータは消去したうえで、更新されたデータはこれまで未使用ブロックであった物理アドレス１０７で示されるブロックに書き込むようにされる（処理▲１▼）。
【００３２】
そして、処理▲２▼として示すように、データ更新前（図５（ａ））の状態では物理アドレス１０５に対応していた論理アドレス１０２が、更新されたデータが書き込まれたブロックの物理アドレス１０７に対応するように、論理アドレスについての変更を行うものである。これに伴って、データ更新前は物理アドレス１０７に対応していた論理アドレス１０４については、物理アドレス１０５に対応するように変更されている。
【００３３】
つまり、物理アドレスはブロックに対して固有に付されるアドレスであり、論理アドレスは、一旦ブロックに対して書き込まれたデータに付随するようにしてついて回る、ブロック単位の書き込みデータに固有となるアドレスであるとみることができる。
【００３４】
このようなブロックのスワップ処理が行われることで、或る同一の記憶領域（ブロック）に対して繰り返し集中的にアクセスされることが無くなり、書き換え回数の上限があるフラッシュメモリの寿命を延ばすことが可能となる。
そして、この際に論理アドレスを上記処理▲２▼のようにして扱うことで、ブロックのスワップ処理によって更新前と更新後のデータとで書き込まれるブロックの移動があるようにされても、ＦＡＴからは同一のアドレスが見えることになり、以降のアクセスを適正に実行することができるものである。
なお、後述する論理−物理アドレス変換テーブル上での更新のための管理を簡略にすることなどを目的として、ブロックのスワップ処理は、１セグメント内で完結するものとして規定されている。逆に言えば、ブロックのスワップ処理はセグメント間で跨るようにしては行われない。
【００３５】
２−４．論理−物理アドレス変換テーブル
上記図５による説明から分かるように、ブロックのスワップ処理が行われることで、物理アドレスと論理アドレスの対応は変化する。従って、フラッシュメモリに対するデータの書き込み及び読み出しのためのアクセスを実現するには、物理アドレスと論理アドレスとの対応が示される論理−物理アドレス変換テーブルが必要となる。つまり、論理−物理アドレス変換テーブルをＦＡＴが参照することで、ＦＡＴが指定した論理アドレスに対応する物理アドレスが特定され、この特定された物理アドレスにより示されるブロックにアクセスすることが可能になるものである。逆に言えば、論理−物理アドレス変換テーブルが無ければ、ＦＡＴによるフラッシュメモリへのアクセスが不可能となる。
【００３６】
従来では、例えばセット本体に対して板状メモリ１が装着されたときに、セット本体側のマイクロプロセッサが板状メモリ１の記憶内容をチェックすることで、セット本体側で論理−物理アドレス変換テーブルの構築を行い、更にこの構築された論理−物理アドレス変換テーブルをセット本体側のＲＡＭに格納するようにしていた。つまり、板状メモリ１内には、論理−物理アドレス変換テーブルの情報は格納されてはいなかった。
これに対して本例では、以降説明するように板状メモリ１に対して、論理−物理アドレス変換テーブルを格納するように構成している。
【００３７】
図６は、本例の板状メモリ１に対して格納される論理−物理アドレス変換テーブルの構築形態を概念的に示すものである。
つまり、本例では、例えば論理アドレスの昇順に従って、これに対応する２バイトの物理アドレスを格納するようにしたテーブル情報を論理−物理アドレス変換テーブルとして構築するようにされる。
なお、前述したように、物理アドレス、及び論理アドレスは共に２バイトで表現される。これは、１２８ＭＢの最大容量のフラッシュメモリの場合には８１９２個のブロックが存在するため、最大で、この８１９２個のブロック数をカバーできるだけのビット数が必要とされることに基づく。
このため、図６において例示している物理アドレスと論理アドレスとについても、実際に即して２バイトで表現している。
但し、ここでは、この２バイトを１６進数により表記している。つまり、「０ｘ」によりその後続く値が１６進法表記であることが示される。なお、この「０ｘ」により１６進数であることを表す表記は、以降の説明において１６進数を表記する場合にも同様に用いることとする。（但し、表記の煩雑化を防ぐため「０ｘ」を省略している図面もある。）
【００３８】
図７に、上記図６に示した概念に基づく論理−物理アドレス変換テーブルの構造例を示す。
論理−物理アドレス変換テーブルは、フラッシュメモリの最後のセグメント内の或るブロックに対して、図７に示すようにして格納される。
先ず図７（ａ）に示すように、ブロックを分割するページのうち、ページ０，１からなる２ページの領域がセグメント０用の論理−物理アドレス変換テーブルとして割り当てられる。例えば、図８にて説明したように、フラッシュメモリが４ＭＢの容量であれば１セグメントしか有さないために、このページ０，１のみの領域が論理−物理アドレス変換テーブルの領域となる。
また、例えばフラッシュメモリが８ＭＢの容量であれば２セグメントを有するため、セグメント０用の論理−物理アドレス変換テーブルとして割り当てられるページ０，１に加え、これに続くページ２，３の２ページがセグメント１用の論理−物理アドレス変換テーブルとして割り当てられることになる。
【００３９】
以降、フラッシュメモリの容量の増加に応じて、続く２ページごとにセグメントごとの論理−物理アドレス変換テーブルの割り当て領域が設定されていくことになる。そして、最大の１２８ＭＢの容量を有する場合であれば１６セグメントが存在するため、最大では、セグメント１５用までのページが論理−物理アドレス変換テーブルの領域として割り当てられることになる。従って、最大の１２８ＭＢの容量のフラッシュメモリでは、３０ページが使用されることになり、図７（ａ）に示すページＮとしては、最大でＮ＝２９となる。
これまでの説明から分かるように、論理−物理アドレス変換テーブルは、セグメントごとに管理されるものである。
【００４０】
図７（ｂ）は、１セグメントあたりの論理−物理アドレス変換テーブルの構造を示すものとして、２ページ分のデータエリアを抜き出して示している。つまり、１ページのデータエリアは５１２バイト（図３（ｅ）参照）であることから、図７（ｂ）には、１０２４（＝５１２×２）バイトが展開されている状態が示されている。
【００４１】
図７（ｂ）に示すように、この２ページ分のデータエリアである１０２４バイトについて２バイトごとに区切り、この２バイトごとの領域を、先頭から順次、論理アドレス０用、論理アドレス１用・・・・、のようにして割付を行い、最後は先頭から９９１バイト目と９９２バイト目の２バイトの領域を論理アドレス４９５用の領域として割り付けるように規定を行う。これら２バイトごとの領域に対して、各論理アドレスが対応する物理アドレスを書き込むようにする。従って、本例の論理−物理アドレス変換テーブルでは、実際のデータ更新によるブロックのスワップ処理などにより物理アドレスと論理アドレスの対応が変更された場合には、論理アドレスを基準として、物理アドレスの格納状態が更新されるようにしてテーブル情報の書き換えが行われることになる。
【００４２】
また、残る９９３バイト目から最後の１０２４バイト目までの計３２バイトの領域は、余剰ブロックの物理アドレスが格納される領域として割り当てられる。つまり、１６個の余剰ブロックの物理アドレスを管理することができる。ここでいう余剰ブロックとは、例えばブロック単位でデータの更新を行う際に書き換え対象となるデータを一時待避させる領域として設定されたいわゆるワークブロックなどを言うものである。
【００４３】
ところで、１セグメントは５１２ブロックに分割されているものであると先に説明したのにも関わらず、図７に示したテーブル構造では、管理可能なブロック数が論理アドレス０用〜論理アドレス４９５用の４９６ブロックとしている。これは、実際上、上記した余剰アドレスが設定されることと、前述したように、フラッシュメモリでは、或ブロック数のディフェクト（使用不可領域）が許可されている。そのため現実には、相当数のディフェクトブロックが存在することに依る。
従って、実際には、書き込み／消去が有効なブロックを管理するのに、４９６ブロックを管理できるように構成しておけば充分とされるものである。
【００４４】
そして、このようにして論理−物理アドレス変換テーブルが格納されるブロックについては、これを形成する各ページの冗長部における管理フラグ（図４参照）のデータ内容として、この管理フラグのビット３に対して‘０’がセットされることになる。これにより、当該ブロックが論理−物理アドレス変換テーブルが格納されているブロックであることが示されることになる。
【００４５】
論理−物理アドレス変換テーブルが格納されるブロックも、論理−物理アドレス変換テーブルの内容の書き換えがあった場合には、例外なく、先に図５にて説明したスワップ処理が行われる。従って、論理−物理アドレス変換テーブルが記録されているブロックは不定であり、或る特定のブロックに論理−物理アドレス変換テーブルを格納するように規定することは出来ない。
そこで、ＦＡＴは、フラッシュメモリにアクセスして上記した管理フラグのビット３が‘０’とされているブロックを検索することで、論理−物理アドレス変換テーブルが格納されているブロックを識別するようにされる。但し、論理−物理アドレス変換テーブルが格納されているブロックの検索がＦＡＴによって容易に行われるようにすることを考慮して、論理−物理アドレス変換テーブルが格納されているブロックは、そのフラッシュメモリ内における最後のナンバが付されたセグメントに在るように、本例では規定するものとされる。これにより、ＦＡＴは最後のナンバが付されたセグメントのブロックのサーチだけで、論理−物理アドレス変換テーブルを検索することができる。つまり、論理−物理アドレス変換テーブルを検索するのに、フラッシュメモリの全てのセグメントを検索する必要は無いようにされる。
上記図７に示した論理−物理アドレス変換テーブルは、例えば板状メモリ１の製造時において格納するようにされる。
【００４６】
ここで、再度図８を参照して、フラッシュメモリ容量と論理−物理アドレス変換テーブルのサイズとの関係を説明しておく。
上記図７にて説明したように、１セグメントを管理するための論理−物理アドレス変換テーブルのサイズは２ページ分の１０２４バイト、つまり１ＫＢとなる。従って、図８の最右列に記されているように、フラッシュメモリが４ＭＢ（１セグメント）の容量では論理−物理アドレス変換テーブルは１ＫＢのサイズとなる。また、フラッシュメモリの容量が８ＭＢ（２セグメント）では論理−物理アドレス変換テーブルは２ＫＢ（４ページ）となる。
また、フラッシュメモリの容量が１６ＭＢの場合、２０４８ブロック＝４セグメントのものでは論理−物理アドレス変換テーブルは４ＫＢ（８ページ）、１０２４ブロック＝２セグメントのものでは論理−物理アドレス変換テーブルは２ＫＢ（４ページ）となる。
そして、フラッシュメモリの容量が３２ＭＢ（４セグメント）では論理−物理アドレス変換テーブルは４ＫＢ（８ページ）、フラッシュメモリの容量が６４ＭＢ（８セグメント）では論理−物理アドレス変換テーブルは８ＫＢ（１６ページ）となり、フラッシュメモリの容量が最大の１２８ＭＢ（１６セグメント）では論理−物理アドレス変換テーブルは１６ＫＢ（３２ページ）となる。
【００４７】
３．ドライブ装置の構成
続いて図９で本例のドライブ装置の構成を説明する。
図９は、これまで説明した板状メモリ１に対応してデータの読出・書込・編集を行うことの出来るドライブ装置のセット本体（本体装置）の構成を示している。この図に示すセット本体１００と板状メモリ１とにより、ファイル記憶システムが構成される。
なお、セット本体１００が、板状メモリ１に対する書込や読出の対象として扱うことのできる主データの種類は多様であり、例えば動画データ、静止画データ、マイクロホンから入力される口述音声等のマイクロホン入力音声データ（以下、メッセージデータ）、ＣＤ（Compact Disc：商標）やＭＤ（Mini Disc：商標）等の記録媒体に記録された高音質なオーディオデータ（以下、音楽用データ）、制御用データ、電話帳データなどがある。
本例では、説明の簡略化のため、主データとしてメッセージデータ（マイクロホン入力音声データ）を記憶／再生するシステムとして説明していくが、セット本体１００内に、動画、静止画、音楽等のデータの入出力系／処理系を備えることにより、上記の動画データ等のデータファイルの記憶システムとできることはいうまでもない。
【００４８】
セット本体１００の構成としては、当該セット本体１００が着脱可能に装填される着脱機構１２０が備えられ、この着脱機構１２０に装填された板状メモリ１と、マイクロプロセッサ１０９とのデータの授受は、ホストインターフェイスＩＣ１０１を介することで行われる。
【００４９】
また、このセット本体１００には、例えば、マイクロフォン１０３が備えられて、このマイクロフォン１０３により収音された音声は、マイクアンプ１０４を介して音声信号としてＤＳＰ(Digital Signal Processor)１０２に対して供給される。ＤＳＰ１０２では、この入力された音声信号をデジタルオーディオデータに変換して、エンコード処理等をはじめとする所要の信号処理を施し、記録データとして制御用マイクロプロセッサ１０９に供給する。
マイクロプロセッサ１０９は、この記録データをホストインターフェイスＩＣ１０１を介して板状メモリ１に記録するための処理を実行することが可能とされる。
【００５０】
また、マイクロプロセッサ１０９は、板状メモリ１に記録されているオーディオデータ又はメッセージデータとしてのデータファイルをホストインターフェイスＩＣ１０１を介して読み出し、この読み出したデータをＤＳＰ１０２に供給する。
ＤＳＰ１０２では、供給されたデータについて復調処理をはじめとする所要の信号処理を施して、最終的にはアナログ音声信号としてスピーカアンプ１０５に出力する。スピーカアンプ１０５では、入力された音声信号を増幅してスピーカ１０６に出力する。これにより、再生音声が出力される。
【００５１】
また、マイクロプロセッサ１０９は、表示ドライバ１０７を制御することで、表示部１０８に対して、所要の画像を表示させることが可能とされる。例えばユーザーの操作のためのメニューやガイド表示、或いは板状メモリ１に記憶されたファイル内容などの表示が実行される。また、例えば板状メモリ１に対して動画若しくは静止画の画像データが記録されているとすれば、この画像データを読み出して、表示部１０８に表示させるようにすることも可能とされる。
【００５２】
操作部１１２には、セット本体１００に対する各種操作をユーザが行うための各種キーが設けられている。マイクロプロセッサ１０９は、この操作部１１２に対して行われた操作に応じたコマンドを受信し、コマンドに応じた所要の制御処理を実行する。
操作内容としては、ファイル記憶指示、ファイル選択指示、ファイル再生指示、編集指示（後述するデバイド指示その他）などが可能とされる。
【００５３】
なお、この図に示すセット本体１００の構成はあくまでも一例であり、これに限定されるものではない。つまり、板状メモリ１に対応してデータの送受信が可能な構成を採る限りは、どのようなタイプの電子機器とされていても構わないものである。
【００５４】
４．ＦＡＴ構造
図２のファイルシステム階層で説明したように、ファイル管理処理はＦＡＴにより行われることになる。
即ち図９に示した構成のドライブ装置により、板状メモリ１に対する記録再生（データ書込／読出）を実現するには、アプリケーション処理での要求に伴ってＦＡＴによるファイル記憶位置管理が参照され、さらに上述した論理−物理アドレス変換が行われて実際のアクセスが行われることになる。
ここで、ＦＡＴの構造について説明しておく。
【００５５】
図１０はＦＡＴによる管理構造の概要を示している。
なお、本例ではＦＡＴ及び論理−物理アドレス変換テーブルは板状メモリ１内に格納されることになるが、図１０に示すＦＡＴ構造が、板状メモリ１内での管理構造となるものである。
【００５６】
そして、図示するようにＦＡＴ管理構造は、パーティションテーブル、空き領域、ブートセクタ、ＦＡＴ、ＦＡＴのコピー、ルートディレクトリ、データ領域から成る。
データ領域には、クラスタ２、クラスタ３・・・として単位データを示しているが、このクラスタとは、管理単位となるＦＡＴで扱う１データ単位である。
一般にＦＡＴでは、クラスタサイズは標準で４Ｋバイトとされるが、このクラスタサイズは５１２バイト〜３２Ｋバイトの間で２のべき乗の大きさをとることができる。
本例の板状メモリ１では、上述したように１つのブロックが８Ｋバイト又は１６Ｋバイトとされるが、１ブロック＝８Ｋバイトとされる板状メモリ１の場合は、ＦＡＴで扱うクラスタは８Ｋバイトとされる。また１ブロック＝１６Ｋバイトとされる板状メモリ１の場合は、ＦＡＴで扱うクラスタは１６Ｋバイトとされる。即ち、８Ｋバイト又は１６ＫバイトがＦＡＴ管理上でのデータ単位であり、かつ板状メモリ１でのブロックとしての１つのデータ単位とされる。なお、従って板状メモリからみれば、ＦＡＴで扱われるクラスタサイズ＝その板状メモリのブロックサイズとなる。このため、本例の以降の説明については、簡略化のためにブロック＝クラスタとして考えることとする。
【００５７】
そして図１０左側にブロックナンバとしてｘ・・・（ｘ＋ｍ−１）、（ｘ＋ｍ）（ｘ＋ｍ＋１）（ｘ＋ｍ＋２）・・・と示したが、例えばこのように各ブロックにおいてＦＡＴ構造を構築する各種データは記憶されることになる。
なお、実際には必ずしもこのように物理的に連続する各ブロックに各情報が記憶されるものではない。
【００５８】
ＦＡＴ構造において、まずパーティションテーブルには、ＦＡＴパーティション（最大２Ｇバイト）の先頭と終端のアドレスが記述されている。
ブート領域には、いわゆる１２ｂｉｔＦＡＴ、１６ｂｉｔＦＡＴの別や、ＦＡＴ構造（大きさ、クラスタサイズ、各領域のサイズなど）が記述される。
【００５９】
ＦＡＴは、後述するように各ファイルを構成するクラスタのリンク構造を示すテーブルとなり、またＦＡＴについては続く領域にコピーが記述される。
ルートディレクトリには、ファイル名、先頭クラスタ番号、各種属性が記述される。これらの記述は１つのファイルにつき３２バイト使用される。
【００６０】
ＦＡＴにおいては、ＦＡＴのエントリとクラスタは１対１で対応しており、各クラスタのエントリにはリンク先、つまり後に続くクラスタの番号が記述される。つまり、複数のクラスタ（＝ブロック）で形成されている或るファイルについてみると、まずディレクトリによって先頭のクラスタ番号が示され、ＦＡＴにおけるその先頭クラスタのエントリには、次のクラスタ番号が示される。さらに次のクラスタ番号のエントリには、さらに次のクラスタ番号が示される。このようにクラスタのリンクがＦＡＴに記述される。
【００６１】
図１１はこのようなリンクの概念を模式的に示している（数値は１６進値）。例えば２つのファイル「ＭＡＩＮ．Ｃ」「ＦＵＮＣ．Ｃ」が存在するとすると、ディレクトリにはこの２つのファイルの先頭クラスタ番号が例えば「００２」「００４」と記述される。
そしてファイル「ＭＡＩＮ．Ｃ」については、クラスタ番号「００２」のエントリに次のクラスタ番号「００３」が記述され、またクラスタ番号「００３」のエントリに次のクラスタ番号「００６」が記述される。さらに、クラスタ番号００６がこのファイル「ＭＡＩＮ．Ｃ」の最後のクラスタであるとすると、クラスタ番号「００６」のエントリには、最後のクラスタであることを示す「ＦＦＦ」が記述される。
これによりファイル「ＭＡＩＮ．Ｃ」がクラスタ「００２」→「００３」→「００６」という順番で記憶されている。即ち、仮にクラスタ番号と板状メモリ１でのブロック番号が一致していると仮定すると、ファイル「ＭＡＩＮ．Ｃ」は、板状メモリ１内でブロック「００２」「００３」「００６」に記憶されていることが表現されている。（但し、ＦＡＴで扱うクラスタは、上述のように論理アドレスで扱うものとなるため、ブロックの物理アドレスとそのまま一致するものではない）
【００６２】
また同様にファイル「ＦＵＮＣ．Ｃ」については、ＦＡＴにより、クラスタ「００４」→「００５」に記憶されていることが表現される。
【００６３】
なお、未使用のブロックに対応するクラスタについては、そのエントリは「０００」とされる。
【００６４】
ところでルートディレクトリの領域に記憶される各ファイルのディレクトリにおいては、図１１に示した先頭クラスタ番号だけでなく、例えば図１２のように各種データが記述される。
即ちファイル名、拡張子、属性、変更時刻情報、変更日付情報、先頭クラスタ番号、ファイルサイズが、それぞれ図示するバイト数で記述される。
【００６５】
また或るディレクトリの下層となるサブディレクトリについては、図１０のルートディレクトリの領域ではなく、データ領域に記憶される。つまりサブディレクトリは、ディレクトリ構造を持つファイルとして扱われる。そしてサブディレクトリの場合はサイズは無制限とされ、また自分自身へのエントリと親ディレクトリへのエントリが必要になる。
【００６６】
図１３に、或るルートディレクトリ内にファイル「ＤＩＲ１」（属性＝ディレクトリ：つまりサブディレクトリ）があり、さらにその中にファイル「ＤＩＲ２」（属性＝ディレクトリ：つまりサブディレクトリ）があり、さらにその中にファイル「ＦＩＬＥ」が存在する場合の構造例を示している。
つまりルートディレクトリの領域には、サブディレクトリであるファイル「ＤＩＲ１」としての先頭クラスタ番号が示され、上述したＦＡＴにより、クラスタＸ、Ｙ、Ｚがリンクされている状態となる。
この図からわかるように、サブディレクトリ「ＤＩＲ１」「ＤＩＲ２」についてはファイルとして扱われてＦＡＴのリンクに組み込まれる。
【００６７】
以上の説明を図２９を用いてまとめる。
図２９にＦＡＴ管理による管理方法を説明する。
図２９は、板状メモリ１内の模式図（メモリマップ）を示しており、上からパーティションテーブル、空き領域、ブートセクター、ＦＡＴ領域、ＦＡＴのコピー領域、ルートディレクトリ領域、サブディレクトリ領域、データ領域が積層されている。
なお、このメモリマップは上述した論理−物理アドレス変換テーブルに基づく、論理アドレス→物理アドレス変換後のメモリマップである。
【００６８】
ブートセクター、ＦＡＴ領域、ＦＡＴのコピー領域、ルートディレクトリ領域、サブディレクトリ領域、データ領域を全部まとめてＦＡＴパーティション領域と称する。
【００６９】
上記パーティションテーブルにはＦＡＴパーティション領域のはじめと終わりのアドレスが記録されている。
なお通常フロッピーディスクで使用されているＦＡＴには上記パーティションテーブルは備えられていない。
またメモリ内の先頭領域にはパーティションテーブル以外のものは置かないために図示するように空きエリアが生ずる。
【００７０】
ブートセクターには１２ビットＦＡＴ／１６ビットＦＡＴであるかの別に応じてＦＡＴ構造の大きさ、クラスタサイズ、それぞれの領域のサイズが記録されている。
ＦＡＴはデータ領域に記録されているファイル位置を管理するものである。
ＦＡＴのコピー領域はＦＡＴのバックアップ用の領域である。
【００７１】
ルートディレクトリはファイル名、先頭クラスタアドレス、各種属性が記録されており、１ファイルにつき３２バイト使用する。
サブディレクトリはディレクトリというファイルの属性のファイルとして存在しており、この図２９の例ではＰＢＬＩＳＴ．ＭＳＶ，ＣＡＴ．ＭＳＶ，ＤＯＧ．ＭＳＶ、ＭＡＮ．ＭＳＶという４つのファイルが存在する。
【００７２】
このサブディレクトリにはファイル名とＦＡＴ上の記録位置が管理されている。即ち、図２９においては、ＣＡＴ．ＭＳＶというファイル名が記録されているスロットには”５”というＦＡＴ上のアドレスが管理されており、ＤＯＧ．ＭＳＶというファイル名が記録されているスロットには”１０”というＦＡＴ上のアドレスが管理されている。更に、ＭＡＮ．ＭＳＶというファイル名が記録されているスロットには”１１０”というＦＡＴ上のアドレスが管理されている。
【００７３】
クラスタ２以降が実際のデータ領域で、このエリアに本例ではＡＤＰＣＭで圧縮処理された音声データ（メッセージデータ）が記録される。
本例では、クラスタ５〜クラスタ８にＣＡＴ．ＭＳＶというファイル名のＡＤＰＣＭで圧縮処理された音声データが記録され、クラスタ１０〜クラスタ１２にＤＯＧ．ＭＳＶというファイル名の前半パートであるＤＯＧ−１がＡＤＰＣＭで圧縮処理された音声データが記録され、クラスタ１００〜クラスタ１０１にＤＯＧ．ＭＳＶというファイル名の後半パートであるＤＯＧ−２がＡＤＰＣＭで圧縮処理された音声データが記録されている。
更に、クラスタ１１０〜クラスタ１１１にＭＡＮ．ＭＳＶというファイル名のＡＤＰＣＭで圧縮処理された音声データが記録されている。
またデータ領域上のＥｍｐｒｙとかかれた領域は記録可能領域である。
【００７４】
この例において、ＤＯＧ．ＭＳＶというファイル名のファイルは、単一のファイルが２分割されて離散的に記録されている例となっている。
【００７５】
クラスタ２００以降はファイルネームを管理する領域であり、クラスタ２００にはＣＡＴ．ＭＳＶというファイルが、クラスタ２０１にはＤＯＧ．ＭＳＶというファイルが、クラスタ２０２にはＭＡＮ．ＭＳＶというファイルが記録されている。
ファイル順を並び替える場合には上記クラスタ２００以降で並び替えを行えばよい。
【００７６】
最初、このような板状メモリ１が挿入された場合には、ドライブ装置は、先頭のパーティションテーブルを参照してＦＡＴパーティション領域のはじめと終わりのアドレスを把握する。
そしてブートセクタの再生を行った後にルートディレクトリ，サブディレクトリの再生を行う。
そしてサブディレクトリに記録されている再生管理情報である、ＰＢＬＩＳＴ．ＭＳＦが記録されているスロットを検索して、ＰＢＬＩＳＴ．ＭＳＦが記録されているスロットの終端部のアドレスを参照する。
図２９の例では、ＰＢＬＩＳＴ．ＭＳＦが記録されているスロットの終端部には”２００”というアドレスが記録されているので、これに基づいてクラスタ２００を参照することになる。
【００７７】
上述したようにクラスタ２００以降はファイル名を管理するとともにファイルの再生順を管理する領域であり、この例の場合にはＣＡＴ．ＭＳＶというファイルが１番目となり、ＤＯＧ．ＭＳＶというファイルが２番目となり、ＭＡＮ．ＭＳＶというファイルが３番目となる。
【００７８】
ここでクラスタ２００以降を全て参照したら、サブディレクトリに移行して、上記ＣＡＴ．ＭＳＶ及びＤＯＧ．ＭＳＶ及びＭＡＮ．ＭＳＶという名前のファイル名と合致するスロットを参照する。
図２９においては、ＣＡＴ．ＭＳＶというファイル名が記録されたスロットの終端には”５”というアドレスが記録され、ＤＯＧ．ＭＳＶというファイルが記録されたスロットの終端には”１０”というアドレスが記録され、ＭＡＮ．ＭＳＶというファイルが記録されたスロットの終端には１１０というアドレスが記録されている。
【００７９】
ここで、ＣＡＴ．ＭＳＶのスロットにおける”５”というアドレスに基づいて、ＦＡＴ上のエントリーアドレスを検索すると”６”というクラスタアドレスがエントリーをされており、”６”というエントリーアドレスを参照すると”７”というクラスターアドレスがエントリーされており、”７”というエントリーアドレスを参照すると”８”というクラスターアドレスがエントリーされており、”８”というエントリーアドレスを参照すると”ＦＦＦ”という終端を意味するコードが記録されている。
よって、ＣＡＴ．ＭＳＶというファイルは、クラスタ５，６，７，８の領域を使用しており、データ領域のクラスタ５，６，７，８を参照することでＣＡＴ．ＭＳＶというＡＤＰＣＭデータが実際に記録されている領域をアクセスすることができる。
【００８０】
また離散的に記録されているＤＯＧ．ＭＳＶというファイルを検索する場合は以下のようになる。
ＤＯＧ・ＭＳＶというファイルが記録されたスロットの終端には”１０”というアドレスが記録されている。
ここで、上記”１０”というアドレスに基づいて、ＦＡＴ上のエントリーアドレスを検索すると”１１”というクラスタアドレスがエントリーをされており、”１１”というエントリーアドレスを参照すると”１２”というクラスターアドレスがエントリーされており、”１２”というエントリーアドレスを参照すると”１００”というクラスターアドレスがエントリーされており、”１００”というエントリーアドレスを参照すると”１０１”というクラスターアドレスがエントリーされており、”１０１”というエントリーアドレスを参照するとＦＦＦという終端を意味するコードが記録されている。
【００８１】
よって、ＤＯＧ．ＭＳＶというファイルは、クラスタ１０，１１，１２、１００，１０１というクラスタ領域を使用しており、データ領域のクラスタ１０，１１，１２を参照することでＤＯＧ．ＭＳＶというファイルの前半パートに対応するＡＤＰＣＭデータが実際に記録されている領域をアクセスすることができる。更に、データ領域のクラスタ１００，１０１を参照することでＤＯＧ．ＭＳＶというファイルの後半パートに対応するＡＤＰＣＭデータが実際に記録されている領域をアクセスすることができる。
【００８２】
また、上記ＭＡＮ．ＭＳＶのスロットにおける”１１０”というアドレスに基づいて、ＦＡＴ上のエントリーアドレスを検索すると”１１１”というクラスタアドレスがエントリーをされており、”１１１”というエントリーアドレスを参照すると”ＦＦＦ”という終端を意味するコードが記録されている。
よって、ＭＡＮ．ＭＳＶというファイルは、クラスタ１１０，１１１という領域を使用していることがわかる。
【００８３】
以上のように板状メモリ１上に記録されたデータファイルをＦＡＴを参照して再生することができ、またデータファイルが離散的に記録されていても、それらを連結してシーケンシャルに再生することが可能となる。
【００８４】
５．板状メモリのファイル構造
５−１ ディレクトリ構成
次に、板状メモリ１に記憶されるファイル構造について説明していく。
まずディレクトリ構成例を図１４に示す。
上述したように、板状メモリ１で扱うことのできる主データとしては、動画データ、静止画データ、メッセージデータ、オーディオデータ、制御用データ、電話帳データなどがあるが、このためディレクトリ構造としては、ルートディレクトリから、「ＶＯＩＣＥ」（メッセージ用ディレクトリ）、「ＤＣＩＭ」（静止画用ディレクトリ）、「ＭＯｘｘｘｘｎｎ」（動画用ディレクトリ）、「ＣＯＮＴＲＯＬ」（制御用ディレクトリ）、「ＨＩＦＩ」（オーディオ用ディレクトリ）、「ＴＥＬ」（電話帳ディレクトリ）が配される。
【００８５】
本例では、特にメッセージデータのファイルについて詳しく述べていくこととする。
ディレクトリ「ＶＯＩＣＥ」のサブディレクトリとしては、図示するように、メッセージリストファイル（ＭＳＧＬＩＳＴ．ＭＳＦ）、メッセージリストファイルのコピーとされるメッセージリストファイルＢ（ＭＳＧＬＩＳＴＢ．ＭＳＦ）、フォルダ（ＦＯＬＤＥＲ１、ＦＯＬＤＥＲ２・・・）等が形成される。
また、例えばフォルダ内には、実際のメッセージデータのファイル（ファイル名「９８１２０１００．ＭＳＶ」等）が形成される。
【００８６】
なお、もちろんこのようなディレクトリ構成は一例にすぎず、例えばフォルダ（ＦＯＬＤＥＲ１等）の下にさらにフォルダが形成される場合などもある。
このような「ＶＯＩＣＥ」ディレクトリ内の構造は、メッセージリストファイルに登録した上で機器により任意に作成するものである。
なお、メッセージリストファイルはディレクトリ構造の管理ファイルとなり、このメッセージリストファイルはバックアップのためのコピーを常に板状メモリ内に持つことで、事故による消失を防ぐようにする。
【００８７】
５−２ メッセージリストファイル
上記メッセージリストファイルの構造について図１５〜図１８を用いて説明する。
図１５はメッセージリストファイルのデータ構成を示しており、縦及び横の数値はバイト数（１６進表記）を示している。
【００８８】
図示するようにメッセージリストファイルの先頭の３２バイトはヘッダーとされる。
続いて６４バイトのフォルダエントリと各３２バイトの複数のメッセージエントリが配される。
そしてメッセージリストファイル内では、このフォルダエントリとメッセージエントリの組が以降、所要数記述されることになる。
【００８９】
このようなメッセージリストファイルでは、フォルダエントリで記述されるフォルダの並び順がフォルダの切り換え・表示順を表す。またメッセージエントリに記述されるメッセージデータの並び順が、メッセージデータの切り換え・表示・再生順番を表す。
【００９０】
メッセージリストファイル先頭の３２バイトのヘッダーの構造を図１６に示す。
図示するようにヘッダーには、４バイトのメッセージリストファイルＩＤ（ＭＳＧ−ＩＤ）、２バイトのフォーマットバージョンナンバ（ＦＭＴ−ＶＥＲ）、２バイトのメーカーコード（ＭＣｏｄｅ）、８バイトの編集日時（ＹＭＤＨＭＳＷ）、４バイトのファイルナンバ（ＦＩＬＥ−ＮＯ）、２バイトのフォルダエントリサイズ（ＦＳＩＺＥ）、２バイトのメッセージエントリサイズ（ＭＳＩＺＥ）、２バイトのフォルダエントリオフセット（ＯＦＦＳＥＴ）、２バイトのキャラクタコード（ＣＣＯＤＥ）、２バイトのリビジョンナンバ（ＲＥＶ）が記述される。
なお（Ｒ）はリザーブの意味であり、後述の図１７、図２０についても同様である。
【００９１】
まず先頭のメッセージリストファイルＩＤ（ＭＳＧ−ＩＤ）は、当該ファイルがメッセージリストファイルであることの識別をするための値とされる。例えばその値は、「0x4D53474C」( ="MSGL")という固定値とされる。
【００９２】
フォーマットバージョンナンバ（ＦＭＴ−ＶＥＲ）は、板状メモリに対するシステムにおいてメッセージデータファイル記憶のために規定されたフォーマットのバージョンナンバであり、この値により使用しているバージョンの番号が識別される。値としては、例えば上位２ビットがメジャー番号、下位２ビットがマイナー番号とされ、これにより「0x0100」 がバージョン1.0を示すなどのように設定される。
【００９３】
メーカーコード（ＭＣｏｄｅ）は、メッセージリストファイルを最後に編集した機器の、メーカー・モデルを識別するコードである。
編集日時（ＹＭＤＨＭＳＷ）は、メッセージリストファイルを最後に編集した年・月・日・時・分・秒・曜日を示す値となる。つまり最終編集日時を識別するための値という機能を持つ。値としては、バイナリとされ、年（西暦）が２バイト、その他が１バイトづつ割り当てられた計８バイトとなる。なお、曜日（日〜土）については特定の値が設定される。
【００９４】
ファイルナンバ（ＦＩＬＥ−ＮＯ）は、最後に作成したメッセージのファイル名番号を示す。これはメッセージのファイル名を作成する際に使用する為の通し番号となる。そしてファイル作成の度にインクリメントされることで、次に作成するファイル名の値を保持することになる。なお、日にちが変わっていたら０にリセットする。
【００９５】
フォルダエントリサイズ（ＦＳＩＺＥ）は、図１５に示したフォルダエントリのサイズを示す値とされる。
例えばその値は、６４という固定値とされ、フォルダエントリーのサイズが６４バイトであることを示している。
メッセージエントリサイズ（ＭＳＩＺＥ）は、図１５に示したメッセージエントリのサイズを示す値とされる。
例えばその値は、３２という固定値とされ、メッセージエントリのサイズが３２バイトであることを示している。
フォルダエントリオフセット（ＯＦＦＳＥＴ）は、最初のフォルダエントリの開始位置を、ファイルの先頭からのオフセット値で表すものである。例えば図１５に示したデータ構成においては、「０ｘ００２０」となる。
【００９６】
続いてフォルダエントリの構造を図１７に示す。
フォルダエントリには２バイトのフォルダＩＤ（ＦＬＤ−ＩＤ）、２バイトのメーカーコード（ＭＣｏｄｅ）、１２バイトのフォルダネーム（ＦＬＤ−ＮＡＭＥ）、２バイトのキャラクタコード（Ｃ−ＣＯＤＥ）、４４バイトのディスプレイネーム（ＤＩＳＰ−ＮＡＭＥ）が記述される。
【００９７】
フォルダＩＤ（ＦＬＤ−ＩＤ）は、フォルダエントリデータの先頭を識別するための値である。例えばその値は「0x4644」( ="FD")の固定値とされる。
メーカーコード（ＭＣｏｄｅ）は、このフォルダを作成した機器の、メーカー及びモデルを識別するためのコードとなる。
【００９８】
フォルダネーム（ＦＬＤ−ＮＡＭＥ）としては、ＦＡＴ上でのフォルダの名前が文字列で記録される。値は、例えばJIS X 0201で規定されたコードで、ディレクトリ名を記録する。基本的にはディレクトリ名（最大８バイト）＋”．”（ドット）＋拡張子（最大３バイト）となるが、拡張子を必要としない場合はディレクトリのみとし、”．”及び拡張子は省略することが可能とされる。また、文字列の最後には、終端記号「０ｘ００」を記述する。ただし、文字列でフォルダネーム（ＦＬＤ−ＮＡＭＥ）の記録領域がすべて満たされて、終端記号を記録するエリアが無い場合は、終端記号の記録は不要とされる。
【００９９】
キャラクタコード（Ｃ−ＣＯＤＥ）は、次のディスプレイネームを記述する文字コードを識別するコードとなる。値は、例えば「0x90」がＪＩＳＸ０２０８−１９９７（いわゆるｓｈｉｆｔ ＪＩＳ）、「0x03」がＩＳＯ８８５９−１などのように決められる。
ディスプレイネーム（ＤＩＳＰ−ＮＡＭＥ）は、機器上に表示されるフォルダ名であり、機器上に表示されるフォルダ名の文字列が記録される。値は、上記キャラクタコードで指定された文字コードで記録されることになる。また文字列の最後には終端記号「0x00」を１バイト以上記録し、終端記号「0x00」以降の値は任意とする。もしディスプレイネーム（ＤＩＳＰ−ＮＡＭＥ）の記録領域がすべてにフォルダ名を記録して、終端記号を記録するエリアが無い場合は、終端記号の記録は不要とされる。
なお、機器が自動的に作成する場合は、ＦＡＴ上のフォルダ名を記録する。
【０１００】
次に、メッセージエントリの構造を図１８に示す。
メッセージエントリには、１バイトのメッセージＩＤ（ＭＩＤ）、１バイトのプライオリティ（ＰＲＩ）、１バイトのアラームモード（ＡＬ−Ｍ）、５バイトのアラームデイト（ＡＬ−ＤＡＴＥ）、８バイトのファイルネーム（ＦＩＬＥ−ＮＡＭＥ）、６バイトの記録日時（ＲＥＣ−ＤＡＴＥ）が記述される。
【０１０１】
メッセージＩＤ（ＭＩＤ）は、メッセージエントリデータの先頭を識別するための値である。値は例えば「0x4D」 ( ="M")の固定値とされる。
プライオリティ（ＰＲＩ）は、メッセージの重要度又は優先度を表す。値は例えば「0x00」〜「0x03」の４段階とされ、値の大きい方が重要度が高いことを示す。また未使用時は「0x00」とされる。
【０１０２】
アラームモード（ＡＬ−Ｍ）は、アラーム機能のモードを表す。
各ビットは次のように定義される。
bit1、bit0・・・日時設定
bit1=0,bit0=0：指定時刻に動作する。
bit1=0,bit0=1：指定曜日に動作する。
bit1=1,bit0=0：指定月日時刻に動作する。
bit1=1,bit0=1：RESERVED
bit2・・・リザーブ（０固定）
bit3・・・残留フラグ
0：アラーム動作後bit7を０にクリアする。
1：アラーム動作後bit7を０にクリアしない。
bit4・・・リザーブ（０固定）
bit5・・・メッセージ再生フラグ
0：アラーム時刻にメッセージを再生しない。
1：アラーム時刻にメッセージを再生する。
bit6・・・アラーム音フラグ
0：アラーム時刻にアラーム音を鳴らさない。
1：アラーム時刻にアラーム音を鳴らす。
bit7・・・アラーム設定フラグ
0：アラームがセットされていない。
1：アラームがセットされている。
なお、アラーム機能を使用しないときはアラームモード（ＡＬ−Ｍ）は「0x00」とする。またbit5, bit6が重複して１のときは、アラーム音→メッセージ再生の順で動作する。
【０１０３】
アラームデイト（ＡＬ−ＤＡＴＥ）は、アラーム動作日時を示す。値は年・月・日・時・分・曜日の順で各１バイトのバイナリで記録する。年は西暦１９８０年からのオフセット値で表される。つまり「０」〜「１２７」は１９８０年〜２１０７年を表し、年を設定しない場合は「0xFF」を記入する。また「０」〜「１２７」及び「0xFF」以外の値は使用不可とされている。
【０１０４】
ファイルネーム（ＦＩＬＥ−ＮＡＭＥ）はメッセージのＦＡＴ上のファイル名が記録される。値は、拡張子を除くファイル名を、例えばJIS X 0201で規定されたコードで記録する。文字列の最後には、終端記号「０ｘ００」を記述する。もしファイルネーム（ＦＩＬＥ−ＮＡＭＥ）の記録領域がすべて文字列で満たされて、終端記号を記録するエリアが無い場合は、終端記号の記録は不要とされる。
【０１０５】
記録日時（ＲＥＣ−ＤＡＴＥ）には、メッセージが記録された日時が記録される。値は年・月・日・時・分・秒の順で１バイトのバイナリで記録する。年は西暦１９８０年からのオフセット値で表し、「０」〜「１２７」は１９８０年〜２１０７年を表す。年を使用しない場合は「0xFF」を記入する。また「０」〜「１２７」及び「0xFF」以外の値は使用されない。
【０１０６】
メッセージリストファイルは以上のように構成されるが、このようなメッセージリストファイルは、「ＶＯＩＣＥ」ディレクトリの直下に置かれる。そしてこのメッセージリストファイルは、各機器間で共通に使用される。
機器リセット時・板状メモリ挿入時等、機器側が初めて板状メモリ１を認識するときは以下の（１）〜（７）の処理を行うことになる。
【０１０７】
（１）「ＶＯＩＣＥ」ディレクトリに存在するサブディレクトリのエントリと、メッセージリストファイルの内容の整合がとれているか確認する。
（２）新たに発生したサブディレクトリをメッセージリストファイルに追加する。
（３）削除されているサブディレクトリをメッセージリストファイルから削除する。（ＰＣ上でメッセージリストファイルの編集なしに、サブディレクトリの追加・削除等が行われることがあるので、これらの作業を必要とする。）
（４）「ＶＯＩＣＥ」ディレクトリ内のサブディレクトリに存在するファイルエントリと、メッセージリストファイルの内容の整合がとれているか確認する。
（５）新たに発生したファイルをメッセージリストファイルに追加する。
（６）削除されているファイルをメッセージリストファイルから削除する。（ＰＣ上でメッセージリストファイルの編集なしに、ファイルの追加・削除等が行われることがあるので、これらの作業を必要とする。
（７）セットで使用するディレクトリが存在しない場合は、新たに作成する。
【０１０８】
このメッセージリストファイルの最大サイズは32768バイト（32×1024−32）と固定される。
最後のメッセージエントリの後ろには３２バイトの領域を「０ｘ００」で埋めるようにされる。
またエントリできるメッセージ（ＦＡＴ上のファイル）の最大数はＶＯＩＣＥディレクトリのサブディレクトリが１つの場合で１０２０個となる。
またメッセージリストファイルにおいて、フォルダエントリ（サブディレクトリ）はメッセージエントリの２つ分のエリアを必要とするので、フォルダエントリを１つ増やす度にエントリできるメッセージの最大数は２つ減ることとなる。
【０１０９】
５−３ メッセージデータファイル
続いて実際のメッセージデータが格納されるメッセージデータファイルについて説明する。
メッセージデータファイルのファイル名は、メッセージリストファイルに登録した上で機器側が任意に作成するものである。
【０１１０】
図１９はメッセージデータファイルのデータ構造を示している。
図示するようにメッセージデータファイルは、フォーマットフレーム（FORMAT FRAME）、ＴＯＣフレーム（TOC FRAME）、タイトルフレーム（TITLE FRAME）、メーカーフレーム（MAKER FRAME）、オーサーフレーム（AUTHOR FRAME）、インフォメーションフレーム（INFORMATION FRAME）、スペースフレーム（SPACE FRAME）、データフレーム（DATA FRAME）を含んで構成される。
但し、タイトルフレーム（TITLE FRAME）、メーカーフレーム（MAKER FRAME）、オーサーフレーム（AUTHOR FRAME）、インフォメーションフレーム（INFORMATION FRAME）を設けることは任意であり、基本的には、太枠で囲ったフォーマットフレーム（FORMAT FRAME）、ＴＯＣフレーム（TOC FRAME）、スペースフレーム（SPACE FRAME）、データフレーム（DATA FRAME）によってメッセージデータファイルが構成されることになる。
【０１１１】
フォーマットフレームは、当該メッセージデータファイルの基本的な管理情報となり、コーデックの種類等が示される。詳細は後述する。
ＴＯＣフレームは、当該メッセージデータファイルの各フレームの配列状態を表す管理情報となる。つまりＴＯＣフレームの記述によりメッセージデータファイルのフレーム構造が識別される。
データフレームは、実際のメッセージデータが格納される領域となる。
スペースフレームは、詳しくは後述するが、再生不可の未使用のエリアとされ、これがＴＯＣフレームの拡大の場合の予備領域や、ファイル内の再生不可エリアの設定のために機能する。
【０１１２】
このような各フレームにおいて、データフレームとスペースフレームは同一ファイル内に複数個存在する場合もある。
ただし、データフレームとスペースフレーム以外のフレームは、同一ファイル内に１つとなる。
また、フォーマットフレームは必ずファイルの先頭に配置される。そしてＴＯＣフレームはフォーマットフレームの直後に配置される。
上述した必須でないフレーム（タイトルフレーム、メーカーフレーム、オーサーフレーム、インフォメーションフレームは、ＴＯＣフレームの後にまとめて配置される。これらは後述するフレームＩＤが小さい順番に配置されることになる。
また、必須でないフレームの並びの次には、必ずスペースフレームが配置される。
【０１１３】
フォーマットフレームの構造を図２０で説明する。
フォーマットフレームは使用コーデック等を記述する必須のフレームとなり、必ずファイルの先頭にあることが要求される。
このフォーマットフレームには図示するように、８バイトのファイルＩＤ（ＦＩＬＥ−ＩＤ）、４バイトのサイズオブフォーマットフレーム（ＳＩＺＥ−ＦＭＴ）、２バイトのフォーマットバージョンナンバ（ＦＭＴ−ＶＥＲ）、１６バイトのカンパニーネーム（Ｃ−ＮＡＭＥ）、１６バイトのセットネーム（Ｓ−ＮＡＭＥ）、２バイトのセットファームウエアバージョンナンバ（ＳＥＴ−ＶＥＲ）、８バイトの記録日時（ＤＡＴＥ−ＴＩＭＥ）、２バイトのフォーマットＩＤ（ＦＭＴ−ＩＤ）、２バイトのチャンネル数（ＣＨＡＮ）、４バイトのサンプリング周波数（ＳＡＭＰ）、４バイトのアベレージバイトｐｅｒ秒（ＢＹＴＥ）、２バイトのブロックアライメント（ＡＬＩＧＮ）、２バイトのビットｐｅｒサンプル（ＢＩＴ）、２バイトのサイズオブエキストラエリア（ＥＸＴ）が記述される。なお、エキストラエリアが設けられる場合がある。
【０１１４】
ファイルＩＤ（ＦＩＬＥ−ＩＤ）は、例えばＩＳＯ８８５９−１文字コードを使用してボイスフォーマットファイル（本例でいうメッセージデータファイルフォーマット）であることを表す。値は例えば「MS_VOICE」の固定値とされる。
サイズオブフォーマットフレーム（ＳＩＺＥ−ＦＭＴ）は、当該フォーマットフレームのサイズをバイト単位で表す。後述するが、フォーマットフレームのサイズがここに記述されることで、ＴＯＣフレームへのアクセスが可能となる。
【０１１５】
フォーマットバージョンナンバ（ＦＭＴ−ＶＥＲ）は、ボイスフォーマットのバージョンを表す。上位１バイトがメジャーバージョンナンバ、下位１バイトがマイナーバージョンナンバとなる。例えば値が「0x0100」であればバージョン１．０、「0x0203」であればバージョン２．３となる。
【０１１６】
カンパニーネーム（Ｃ−ＮＡＭＥ）は、例えばＩＳＯ８８５９−１文字コードを使用してファイル作成セットの会社名を表す文字列が記入される。文字列の最後には終端記号「０ｘ００」を記述する。カンパニーネーム（Ｃ−ＮＡＭＥ）の領域のすべてが文字列で満たされた場合は、終端記号を記入は省かれる。
【０１１７】
セットネーム（Ｓ−ＮＡＭＥ）は、例えばＩＳＯ８８５９−１文字コードを使用してファイル作成セットの名前を表す文字列が記入される。文字列の最後には終端記号「０ｘ００」を記述する。セットネーム（Ｓ−ＮＡＭＥ）の領域のすべてが文字列で満たされた場合は、終端記号を記入は省かれる。
【０１１８】
セットファームウエアバージョンナンバ（ＳＥＴ−ＶＥＲ）は、機器のファームウエアのバージョンを表す。上位１バイトがメジャーバージョンナンバ、下位１バイトがマイナーバージョンナンバとなる。例えば「０ｘ０１００」はバージョン１．０、「０ｘ０２０３」はバージョン２．３となる。
【０１１９】
記録日時（ＤＡＴＥ−ＴＩＭＥ）は、値がバイナリで表され、年は西暦で２バイト、月、日、時、分、秒、曜日は各々に１バイトが用いられる。
フォーマットＩＤ（ＦＭＴ−ＩＤ）には、使用コーデックが例えば次のように示される。
0x0002：G726 ADPCM 22kHz / 3bit
0x0005：G726 ADPCM 11kHz / 3bit
0x0007：G726 ADPCM 8kHz / 4bit
0x0009：G726 ADPCM 8kHz / 2bit
【０１２０】
チャンネル数（ＣＨＡＮ）により、チャンネル数が次のように表される。
0x0001：モノラル
0x0002：ステレオ
サンプリング周波数（ＳＡＭＰ）によりサンプリング周波数が次のように表される。
0x00001F40：8kHz
0x00002B11：11.025kHz
【０１２１】
アベレージバイトｐｅｒ秒（ＢＹＴＥ）により、１秒あたりのデータがバイト数で表される。これはデータサイズから再生時間を算出する際に使用される。
ブロックアライメント（ＡＬＩＧＮ）では、切り離せないデータの一群を、バイト単位で表す。これはデータの頭出し時に使用される。例えば「０ｘ００３０」では４８バイトであり、「０ｘ００１０」では１６バイトとなる。
【０１２２】
ビットｐｅｒサンプル（ＢＩＴ）は、１サンプリングあたりのビット数を次のように表す。
0x0004：4bit
0x0003：3bit
0x0002：2bit
【０１２３】
サイズオブエキストラエリア（ＥＸＴ）には、コーデックに特有の情報を記述するエリア（エクストラデータエリア）のサイズをバイト単位で表す。つまりエクストラデータエリアが作成される場合は、そのサイズが示される。
なお、エクストラデータエリアは１６バイト単位で作成される。またエクストラデータエリアが必用無い場合はサイズオブエキストラエリア（ＥＸＴ）の値は「0x0000」とされる。
【０１２４】
以上のようなフォーマットフレームに続いて、図３１に示すようなＴＯＣフレームが配される。
ＴＯＣフレームはファイル内の各フレームの配列状態を記述するが、１フレームあたり８バイトを使用するため、ＴＯＣフレームのサイズは（８バイト×全フレーム数）となる。
またこのことは、フレームの追加や削除に応じてＴＯＣフレームのサイズは変更されることを意味する。
全フレーム数が奇数の場合、最後の未使用エリアの８バイトには「０ｘ００」が記入される。図３１の例では、アドレス「０ｘ００２８」〜「０ｘ００２Ｆ」には「０ｘ００」が記入されている。
【０１２５】
図３１に示すように、１つのフレームあたりに用いられる８バイトは次のような構成となる。
フレームＩＤ（FRAME ID） ：１Byte
リザーブ（Ｒ） ：３Byte （0x00固定値）
フレームサイズ（FRAME SIZE）：４Byte
【０１２６】
まずフレームＩＤ（FRAME ID）によりフレームの種類が次のように表される。
フォーマットフレーム ：0x01
ＴＯＣフレーム ：0x02
スペースフレーム ：0x03
データフレーム ：0x04
タイトルフレーム ：0x05
メーカーフレーム ：0x06
オーサーフレーム ：0x07
インフォメーションフレーム：0x08
【０１２７】
またフレームサイズ（FRAME SIZE）に、フレームＩＤで指定したフレームのサイズがバイト単位で記述される。
【０１２８】
ＴＯＣフレームには、このような８バイトのデータ群が、フレームの並び順に各フレームについて記述される。ＴＯＣフレーム内容の具体例は後述する。
また、このＴＯＣフレームの内容により、そのメッセージデータファイルのフレーム構造が認識されるわけである。従って当該メッセージデータファイルへのアクセスの際には、まずフォーマットフレームが確認された後、ＴＯＣフレーム内容が確認されることになる。なお、ＴＯＣフレームへのアクセスは、上記フォーマットフレームのサイズオブフォーマットフレーム（ＳＩＺＥ−ＦＭＴ）により、フォーマットフレームのサイズが記述されていることで可能となる。つまりファイル先頭からサイズオブフォーマットフレーム分のオフセットを与えたアドレスがＴＯＣフレームの先頭アドレスとなる。
【０１２９】
上述したようにＴＯＣフレームに続いては、タイトルフレーム、メーカーフレーム、オーサーフレームが設けられる場合があるが、これらは次のような情報となる。
【０１３０】
タイトルフレームは、タイトルを記録するフレームとされ、先頭の２バイトで例えば次のように記録されているタイトルのキャラクタコードタイプを表す。
0x0000：JISx0208-1997（SJIS）
0x0001：ISO8859-1
例えばタイトルフレームは１６バイトの倍数であって、タイトルの文字列の最後には終端記号「０ｘ００」が記入される。
【０１３１】
メーカーフレームはファイルを作成した機種の会社名、機種名、ファームウエアバージョンＮｏを記述する。タイトルフレームと同様に先頭の２バイトでキャラクタコードタイプを表し、続いて文字列が記入される。メーカーフレームのサイズは１６バイトの倍数であって、文字列の最後には終端記号「０ｘ００」が記入される。
【０１３２】
オーサーフレームは著作権者の名称等を文字列で表す。同じく先頭の２バイトでキャラクタコードタイプを表し、続いて文字列が記入される。オーサーフレームのサイズは１６バイトの倍数であって、文字列の最後には終端記号「０ｘ００」が記入される。
【０１３３】
インフォメーションフレームは付加情報を記録するフレームとされる。付加情報とは例えばアルバム名、アーティスト名、指揮者、さらには平均音量学習用には再生回数と言った種類があって、先頭の１バイトで情報の分類ＩＤが指定され、先頭から３バイト目と４バイト目で情報文字列の記述されているキャラクタコードタイプを表し、フレームの先頭から９バイト目から情報として文字列が記入される。インフォメーションフレームのサイズは１６バイトの倍数とされ、使用されないエリアは０ｘ００でうめられる。
【０１３４】
これらのオプションとなるフレームもしくはＴＯＣフレームの後はスペースフレームとなる。
スペースフレームは、再生不可のエリアに相当するフレームとなり、必ず設けられる。このフレームは再生処理時に読み飛ばすことが必要となる。
このフレームはＴＯＣフレームが拡大されたときの予備として用いられたり、或いは後述するデバイド処理時などに、１クラスタ内に再生不可のエリアが発生した場合に使用される。フレーム内のデータは任意であるが、特定のダミーデータを記録しても良い。スペースフレームのサイズは１６バイトの倍数とされる。
スペースフレームの扱いについては後述する。
【０１３５】
データフレームは実際のメッセージデータが格納される。
メッセージデータは、データフレームの先頭バイトのＭＳＢから、指定されたビット数で隙間無く格納される。データの格納境界はバイト境界となる。
図３２に示したような１サンプリングあたり４ビット、もしくは図３３に示したような１サンプリングあたり２ビットのデータは１バイトが格納の境界であり、図３４に示したような１サンプリングあたり３ビットのデータは３バイトが格納の境界になる。
メッセージデータの分割処理を行う場合、この格納の単位が分割するデータの単位になる。
【０１３６】
以上のような各種フレームによりメッセージデータファイルが構成されるが、メッセージデータファイルのフレーム構成例を図２１、図２２に示す。
なお、以降の説明では、オプションであるタイトルフレーム、メーカーフレーム、オーサーフレーム、インフォメーションフレームは設けられないものとする。
【０１３７】
通常にメッセージデータを録音した場合のフレーム構造は図２１（ａ）のようになり、複数のクラスタ（ブロック）に対して、図示するようにファイル先頭側からフォーマットフレーム、ＴＯＣフレーム、スペースフレーム、データフレームが形成される。
なお、ここで示している１ファイルを構成する複数のブロック（クラスタ）はＦＡＴでリンクされるブロックであり、これまでの説明から理解されるように物理的に連続するブロックとは限らない。
【０１３８】
このようなフレーム構成の情報は、ＴＯＣフレームに示されることになるが、例えばこの場合ＴＯＣフレームの内容は図２１（ｂ）のようになる。
即ち上述したように１フレームにつき８バイトの情報が、形成されているフレームの順に記述されることになる。
従って、まず最初の８バイトにフレームＩＤが「0x01」とされて、フォーマットフレームのサイズが示される。
次の８バイトにはフレームＩＤが「0x02」とされて、ＴＯＣフレーム自身のサイズが示される。フレーム数は４つのため、ＴＯＣフレームのサイズは４×８バイト＝３２バイト（＝0x00000020）となる。
さらに次の８バイトにはフレームＩＤが「0x03」とされて、スペースフレームのサイズが示される。
最後の８バイトにはフレームＩＤが「0x04」とされて、データフレームのサイズが示される。
【０１３９】
また、メッセージデータファイルでは、スペースフレームを利用することにより、一部のデータを消去部分として再生不可とすることができる。
例えば図２２（ａ）は、データフレームの途中に消去して再生させたくないメッセージ部分が存在した場合に、そこをスペースフレームとした例を示している。スペースフレームは再生時に跳ばされるため、再生されるメッセージとしては、一部が消去された状態と同等となる。
【０１４０】
例えば図２１から図２２のようにフレーム構成が変化した場合は、ＴＯＣフレームの内容は図２２（ｂ）のように更新される 。
最初の８バイトのフォーマットフレームのサイズは同様である。
次の８バイトとしてフレームＩＤが「0x02」とされて、ＴＯＣフレーム自身のサイズが示されるが、このとき、フレーム数が２つ増えて６個となったため、ＴＯＣフレームのサイズは６×８バイト＝４８バイト（＝0x00000030）となる。
次の８バイトにはフレームＩＤが「0x03」とされて、スペースフレームのサイズが示されるが、ＴＯＣフレームが１６バイト拡大される際に、スペースフレームの１６バイトが用いられたことで、スペースフレームのサイズは１６バイト減って「0x00000180」とされる。
次の８バイトには、再生させたくないメッセージが存在する新たなスペースフレームで分断された最初のデータフレームのサイズが示され、続く８バイトに新たなスペースフレームのサイズが示される。そして最後の８バイトに分断された後ろ側のデータフレームのサイズが示される。
【０１４１】
例えばこのようにＴＯＣフレームによりメッセージデータファイルのフレーム構成が管理されることになり、また、スペースフレーム、データフレームの追加などによるフレーム構成の変化や、後述するデバイド（ファイル分割）、コンバイン（ファイル連結）などの編集処理によるフレーム構成の変化に応じて、ＴＯＣフレームの内容は更新されていくことになる。
【０１４２】
ところで、スペースフレームは次のように扱われることになる。
まず新規にメッセージデータファイルを作成する際には、図２３に示すように、ＴＯＣフレームの後に１２８バイト以上６４０（＝１２８＋５１２）バイト以下のスペースフレームを配置する。
この時、データフレームの開始位置がセクタ境界になるようにスペースフレームのサイズが決められることとなる。
【０１４３】
また、詳しくは後述するが、メッセージデータファイルの分割（デバイド）処理時には、分割ポイントが含まれるクラスタにおいて、再生禁止データエリアをスペースフレームとする。
即ち図２４のように、或るクラスタの途中の位置が分割点とされた場合、分割による後半のファイルでは、メッセージデータの先頭が、そのクラスタの分割点となる。あくまでファイルの最小単位はクラスタとなるため、このようにそのクラスタ内の分割点以前のデータは、再生してはいけないデータが含まれることとなるが、その部分（図２４の斜線部分）は、スペースフレームとして再生されないようにする。
【０１４４】
また、メッセージデータファイルの分割、結合処理の結果、２つのスペースフレームがとなり合う状況になる場合もあり得る。このようにとなり合う２つのスペースフレームが存在する場合は、それを１つのスペースフレームにまとめる。つまり具体的には、１つのスペースフレームとしてＴＯＣフレームで管理されるようにする。
【０１４５】
以上説明したようにメッセージデータファイルにはメッセージデータが格納されるデータフレームのみならずフォーマットフレーム，ＴＯＣフレーム，タイトルフレーム，メーカーフレーム，オーサーフレーム，インフォメーションフレーム，スペースフレームを設けることができ、特にフォーマットフレーム，ＴＯＣフレーム、スペースフレームは必須とされるが、これは以下の理由による。
【０１４６】
板状メモリ１は図９に示したようなドライブ装置で利用されるのはもちろん、ＰＣ（パーソナルコンピュータ）等のＦＡＴシステムが使用可能な装置でも利用されることが可能とされている。
すなわち、当該メッセージデータファイルを図９に示したようなドライブ装置で記録し管理するようにした板状メモリ１をＰＣ等に装着してファイルの移動やファイル名の変更が可能である。
【０１４７】
このようにＰＣ等において板状メモリ内１に記録されたメッセージデータファイルをＦＡＴシステムを利用して移動させたり、ファイル名称の変更を行った場合、先に説明したメッセージリストファイルにて管理されているメッセージデータファイルとの整合が取れないものとなる。この問題を解決するために板状メモリ１が図９に示したようなドライブ装置に初めて認識されるときには、先に説明したようなメッセージリストファイルの内容とＶＯＩＣＥディレクトリに存在するサブディレクトリのエントリとの整合をとる処理を行うことで、例えばユーザーがメッセージデータファイルを好みのファイル名にＰＣにおいて変更したとしても図９に示したようなドライブ装置で利用可能となるのである。
【０１４８】
このときにメッセージファイルがデータフレームだけでなく他のフレームを合わせて設けていたとすると、図９に示したようなドライブ装置で記録し管理するようにした板状メモリ１をＰＣ等においてファイルの移動が行われたとしても、データフレームを再生するのに必要な情報も同時に移動されているためドライブ装置では大きな支障なく再生が可能となるためである。
【０１４９】
ところで以上の情報を使ってメッセージを再生する場合にメッセージの記録時間や残り時間を表示したりすることが望まれる。この場合たとえば図９に示したドライブ装置の表示部１０８に表示することが考えられる。
通常ＦＡＴファイルシステムにおいてはシステムとして管理するファイルサイズを例えばバイト単位で表示するなどしているが、メッセージデータファイルにおいてはＦＡＴファイルシステムが管理するファイルサイズをそのまま利用せず以下の方法で時間に換算をしている。
【０１５０】
まず、ＴＯＣフレームを用いて当該メッセージファイル内にあるデータフレームの合計サイズを算出し、フォーマットフレームに記録されているアベレージバイトｐｅｒ秒の値を用いて先に算出した合計サイズを全体の再生時間に換算する。また、残り時間を算出する場合は例えば、全体の再生時間から再生済みのメッセージの再生時間を引くことによって算出できる。
このような算出を行うことでスペースフレームやその他のフレームのデータ量による算出誤差を取り除くことが可能となる。
【０１５１】
６．デバイド編集処理
続いて本例のシステムにおける特徴的な編集動作となるデバイド編集処理について説明していく。
デバイド編集とは、１つのメッセージデータファイルを、任意の分割点を設定（例えばユーザーが操作により分割点を指示）し、その分割点の前後で２つのメッセージデータファイルに分ける処理である。
この動作を図９及び図２５〜図２８を参照しながら説明する。
図２５は、図９に示したドライブ装置のマイクロプロセッサ１０９の制御により実行される処理のフローチャートであり、また図２６は板状メモリ１上での或るメッセージデータファイルのデバイド処理状態を概念的に示すものである。さらに、図２７、図２８はデバイド処理前後でのＦＡＴ内容を示している。
【０１５２】
或る板状メモリ１がドライブ装置に装填されることで、ユーザーは表示部１０８においてその板状メモリ１に記憶されているメッセージデータファイルを確認することができる。
そしてユーザーが或るメッセージデータファイルを、その途中の或る位置で分割して２つのファイルに分けたいと思った場合は、まず表示部１０８のファイル名表示等を確認しながら操作部１１２からの操作により、その分割させたいメッセージデータファイルを選択する。
【０１５３】
ユーザーがこのようなファイル選択操作を行ったら、マイクロプロセッサ１０９は図２５のステップＦ１０１として、分割対象のメッセージデータファイルを設定する。
続いてユーザーは、その選択されたファイルのどの位置を分割点とするかの操作を行うことになる。
この分割点設定操作については多様な操作例が考えられるが、このとき例えばマイクロプロセッサ１０９は分割対象となったメッセージデータファイルを再生させ、ユーザーは再生メッセージを聞きながら、分割点としたいタイミングで分割点としてのエンター操作を行うことなどが考えられる。
また、メッセージを聞きながらタイミングを見計らって分割点を指定する操作では、分割させたいポイントと指示した分割点が微妙にずれる場合もあるため、ユーザーが分割点を微調整できるような操作機能を付加することが好ましい。
【０１５４】
ユーザーが分割点を指示する操作を行ったら、マイクロプロセッサ１０９はステップＦ１０２で分割点を決定し、実際のデバイド動作に移る。
まずステップＦ１０３では、設定された分割点が或るクラスタ（ブロック）の途中の位置であった場合は、そのクラスタのデータを未使用のクラスタにコピーして、同一内容のクラスタを２つとする。
但し後述するが、設定された分割点がクラスタ（ブロック）の境界位置であった場合は、そのクラスタのデータを複製する必要はない。
また、管理ヘッダを有するファイル先頭のクラスタのデータを未使用のクラスタにコピーして、同一内容のクラスタを２つとする。なお、ここでいう管理ヘッダとはフォーマットフレーム、ＴＯＣフレーム、スペースフレームから構成されたデータ部分のことである。
【０１５５】
続いてステップＦ１０４でＦＡＴのクラスタリンクを変更する。さらにステップＦ１０５でＦＡＴのディレクトリエントリを変更する。
これにより、上記ステップＦ１０３で新たに複製した分割点を含むクラスタ→、ヘッダを含むクラスタとを使用して、元の１つのファイルが２つのファイルに分割されるように新たなクラスタリンクが形成されることになる。具体例は後述する。
【０１５６】
次に、ステップＦ１０６で、元々のファイル先頭の管理ヘッダにおけるＴＯＣフレームを更新する。これにより、元々のファイルの分割点より前半部分に相当する新たな第１のファイルが形成される。
またステップＦ１０７で、複製されファイル先頭にリンクされた管理ヘッダを含むクラスタにおいて、その管理ヘッダを更新する。これによって元々のファイルの分割点より後半部分に相当する新たな第２のファイルが形成される。
以上の処理によりデバイド処理が完了するわけであるが、この処理によって実行されるデバイド処理例を図２６〜図２８で述べる。
【０１５７】
図２６（ａ）に示すファイルＦ１が、ユーザーがデバイド対象として選択したメッセージデータファイルであるとする。
そして仮にこのファイルＦ１は、クラスタＣＬ（２）〜ＣＬ（９）に記憶されているものとする。
このファイルＦ１のクラスタリンクを示すＦＡＴは図２７のようになっている。即ち図示していないディレクトリエントリ（図１１参照）によってファイルＦ１の先頭のクラスタがクラスタＣＬ２とされ、図２７のＦＡＴのクラスタＣＬ（２）のエントリには、「００３」と記憶されている。つまりクラスタＣＬ（２）がクラスタＣＬ（３）にリンクすることが示される。またクラスタＣＬ（３）のエントリには「００４」と記憶され、クラスタＣＬ（４）にリンクすることが示される。以降同様にリンク状態が記録され、最後のクラスタＣＬ（９）のエントリには最終クラスタであることを示す値「ＦＦＦ」が記憶される。
このようなＦＡＴによって、図２６（ａ）のファイルＦ１がクラスタＣＬ（２）〜ＣＬ（９）に格納されていることが管理される。なお、クラスタＣＬ（Ａ）以降は「０００」つまり未使用とされている状態としている。
【０１５８】
ここで、ファイルＦ１に対してユーザーが、図２６（ａ）に示す分割点ＤＰでの分割を指示したとする。
分割点ＤＰはクラスタＣＬ（５）の途中の位置である。
このため上記図２５のステップＦ１０３の処理として、クラスタＣＬ（５）が未使用のクラスタＣＬ（Ａ）にコピーされる。
また管理ヘッダを含む先頭のクラスタＣＬ（２）が未使用のクラスタＣＬ（Ｂ）にコピーされる。
【０１５９】
そして上記図２５のステップＦ１０４、Ｆ１０５でＦＡＴのクラスタリンク及びディレクトリエントリが更新され、図２６（ｂ）（ｃ）に示すようなクラスタリンクが形成される。
分割後の２つのファイルをファイルＦ１−１、Ｆ１−２とすると、まずファイルＦ１−１についてのディレクトリエントリが形成され、先頭のクラスタがクラスタＣＬ（２）と指示される。
そして図２８に示すように、ＦＡＴにおいてクラスタＣＬ（２）のエントリには「００３」、クラスタＣＬ（３）のエントリには「００４」、クラスタＣＬ（４）のエントリには「００Ａ」、クラスタＣＬ（Ａ）のエントリには「ＦＦＦ」と記憶される。
これによって、ファイルＦ１−１が、図２６（ｂ）のようにクラスタＣＬ（２）→ＣＬ（３）→ＣＬ（４）→ＣＬ（Ａ）に記憶されていると管理される状態となる。
【０１６０】
また、ファイルＦ１−２についてのディレクトリエントリが形成され、先頭のクラスタがクラスタＣＬ（Ｂ）と指示される。
そして図２８に示すように、ＦＡＴにおいてクラスタＣＬ（Ｂ）のエントリには「００５」、クラスタＣＬ（５）のエントリには「００６」、クラスタＣＬ（６）のエントリには「００７」、クラスタＣＬ（７）のエントリには「００８」、クラスタＣＬ（８）のエントリには「００９」、クラスタＣＬ（９）のエントリには「ＦＦＦ」と記憶される。
これによって、ファイルＦ１−２が、図２６（ｃ）のようにクラスタＣＬ（Ｂ）→ＣＬ（５）→ＣＬ（６）→ＣＬ（７）→ＣＬ（８）→ＣＬ（９）に記憶されていると管理される状態となる。
【０１６１】
続いてステップＦ１０６ではファイルＦ１−１の管理ヘッダ、即ちクラスタＣＬ（２）の内容が更新される。
具体的には、ＴＯＣフレームに記述されているデータフレームのサイズが更新されることになる。
図２６（ｂ）からわかるように、この場合、最後のクラスタＣＬ（Ａ）は分割点ＤＰのデータを含むクラスタとなり、このファイルＦ１−１にとっては、クラスタＣＬ（Ａ）の分割点ＤＰ相当位置より後ろのメッセージデータは不要なデータとなる。
そこで、データフレームが一点鎖線の矢印で示す範囲となるように（つまり斜線部分を除外するように）、データフレームのサイズが更新されることになる。
これによって、ファイルＦ１−１では、クラスタＣＬ（Ａ）の斜線部分は無効領域とされ、従って、ファイルＦ１−１は、もとのファイルＦ１の分割点ＤＰより前のデータが再生対象とされたファイルとなる。
【０１６２】
次に上記図２５のステップＦ１０７では、ファイルＦ１−２の管理ヘッダ、即ちクラスタＣＬ（Ｂ）の内容が更新される。
具体的には、ＴＯＣフレームに記述されているデータフレームのサイズが更新されるとともに、スペースフレームの設定が更新されることになる。
図２６（ｃ）からわかるように、２番目のクラスタＣＬ（５）は分割点ＤＰのデータを含むクラスタとなる。このファイルＦ１−２にとっては、クラスタＣＬ（５）内での分割点ＤＰより前のメッセージデータは不要なデータとなる。
また、クラスタＣＬ（Ｂ）はクラスタＣＬ（２）をコピーしたものであるが、クラスタＣＬ（２）においてスペースフレームの後ろに存在したデータフレームのメッセージデータも、ファイルＦ１−２にとっては不要なデータとなる。
そこで、元々のクラスタＣＬ（２）に存在し、クラスタＣＬ（Ｂ）にコピーされたスペースフレームが、クラスタＣＬ（５）の分割点ＤＰまで拡大されるように、ＴＯＣフレームでスペースフレームのサイズを更新する。
またＴＯＣフレームでのデータフレームのサイズも更新されることになる。
これによって、ファイルＦ１−２では、クラスタＣＬ（Ｂ）からＣＬ（５）にかけてスペースフレームが拡大され、その部分が再生禁止領域となる。従って、ファイルＦ１−２は、もとのファイルＦ１の分割点ＤＰより後ろのデータが再生対象とされたファイルとなる。
【０１６３】
このような分割処理を、上述した図２９のメモリマップ及び図３０でみると以下のようになる。
図３０は図２９に示した３つのファイルのうちからＣＡＴ．ＭＳＶを分割処理した際を例に挙げて説明するためのメモリマップである。
【０１６４】
いま図２９のようにクラスタ５〜クラスタ８に記録されているデータファイルであるＣＡＴ．ＭＳＶをクラスタ６とクラスタ７を境界、つまり分割点として分割することを指示する操作がユーザによって行われたとする。
この操作に応じて、上述のデバイド処理が行われ、図３０に示すようにＣＡＴ１．ＭＳＶとＣＡＴ２．ＭＳＶという２つのファイルが作成されたとする。
【０１６５】
このように２つのファイル（ＣＡＴ１．ＭＳＶとＣＡＴ２．ＭＳＶ）が形成されるまでの経過は例えば次のようになる。
まず、図２９の状態でクラスタ２０１及び２０２に記録されているＤＯＧ．ＭＳＶとＭＡＮ．ＭＳＶをクラスタ２０２及び２０３に移動する。
更に、クラスタ２００のファイルネームとして、例えばユーザが入力したＣＡＴ１に識別子ＭＳＶを付与したＣＡＴ１．ＭＳＶを記録するとともに、クラスタ２０１には、例えばユーザが入力したＣＡＴ２に識別子ＭＳＶを付与したＣＡＴ２．ＭＳＶを記録する。
【０１６６】
次にサブディレクトリに記録されていたＣＡＴ．ＭＳＶをＣＡＴ１．ＭＳＶに書き換えるとともに未使用スロットにＣＡＴ２．ＭＳＶを追加する。
上記ＣＡＴ２．ＭＳＶが記録されているスロットには分割されたＣＡＴ２．ＭＳＶが記録されているクラスタ番号”７”が終端に記録される。
次にサブディレクトリーのＣＡＴ１．ＭＳＶスロットが指し示すＦＡＴ上の終点がクラスタ６になるようにＦＡＴのエントリーアドレスを”ＦＦＦ”に書き換える。
以上により、図３０の状態となり、これが分割処理時のＦＡＴ上での編集手順となる。
【０１６７】
以上の説明から理解されるように、本例ではデバイド処理に際して、分割位置を含むクラスタと管理ヘッダを含むクラスタが複製され、また分割後の各ファイルの管理ヘッダ（ＴＯＣフレーム）の一部が更新され、データフレーム、スペースフレームのサイズが変更されるのみで、分割点から前後の２つのメッセージデータファイルに分割されることになる。
これは、メッセージデータファイルを分割するという編集のために必要となるデータの複製や書換が最小限となっていることを意味する。
そしてこれによって編集処理が効率化され、編集処理のためのアクセスも最小限となるため、処理時間や消費電力を最小限とできる。
【０１６８】
なお、分割点ＤＰがクラスタの境界とされた場合は、分割点を含むクラスタの複製は不要となる。
例えば上記図２６（ａ）のファイルＦ１のクラスタＣＬ（５）とＣＬ（６）の境界が分割点となった場合は、分割後のファイルＦ１−１は、クラスタＣＬ（２）〜ＣＬ（５）により形成され、ファイルＦ１−２は、クラスタＣＬ（２）から複製された或るクラスタＣＬ（Ｘ）からクラスタＣＬ（６）・・・ＣＬ（９）により形成されることになる。
従ってその様な場合は、分割処理のための複製は管理ヘッダを含むクラスタのみとなり、処理はより簡易かつ短時間で実現できるものとなる。
【０１６９】
また、図２６の例では、クラスタＣＬ（５）とそれをコピーしたクラスタＣＬ（Ａ）について、クラスタＣＬ（５）をファイルＦ１−１側に組み込み、クラスタＣＬ（Ａ）をファイルＦ１−２側に組み込んだが、クラスタＣＬ（Ａ）をファイルＦ１−１側に組み込み、クラスタＣＬ（５）をファイルＦ１−２側に組み込むようにしてもよい。
管理ヘッダを含むクラスタについても同様である。
【０１７０】
ところで、元々のクラスタＣＬ（５）のデータが記憶されていて新たにスペースフレームに組み込んだ領域、つまりファイルＦ１−２のクラスタＣＬ（５）の前半部分では、その音声データをそのまま残しておくようにしてもよいし、例えばゼロデータなどのダミーデータを充填しても良い。或いは何らかの付加データの記憶領域として利用できるようにしても良い。
これは、スペースフレームとはしないで無効領域とされたエリア、つまりファイルＦ１−１のクラスタＣＬ（Ａ）の後半の斜線部分についても同様である。
【０１７１】
スペースフレームとした部分のデータの扱いはこのように各種考えられるが、例えばメッセージデータをそのまま残しておくとすると、分割された２つのファイルを後に元の１つのファイルに戻すような場合に、そのクラスタがそのまま使用できることになるため、処理が効率的となる。
さらに、分割処理の結果２つのスペースフレームが隣り合う状況になった場合、それらを１つのスペースフレームにまとめる処理を行っても良い。
【０１７２】
また分割処理の手順や処理内容としては、上記例に限らず各種考えられる。
例えば上記例では分割点を含むクラスタを複製した後、分割後の各ファイルにおいてＴＯＣフレームの更新により一部をスペースフレームもしくは無効部分としたが、例えば分割点より前のメッセージデータにダミーデータを加えて１クラスタ分のデータを生成して未使用クラスタに記憶させ、さらに分割点より後ろのメッセージデータにダミーデータを加えて１クラスタ分のデータを生成して未使用クラスタに記憶させ、これらのクラスタを分割後の各ファイルを構成するクラスタリンクに組み込むという手法も考えられる。
この場合は、その各クラスタのダミーデータ部分が、上記例と同様にスペースフレーム又は無効部分として管理されればよいことはいうまでもない。
【０１７３】
以上、実施の形態としてのシステム構成及びデバイド編集動作について述べてきたが、本発明はこれらの構成及び動作に限定されるものではない。
特に実施の形態においては板状メモリを用いたシステムにおいて主データがメッセージデータであるメッセージデータファイルのデバイド処理を例にあげたが、上述したように板状メモリ１を用いたシステムではメッセージデータファイル以外に、オーディオデータファイル、動画データファイルなども扱うことができる。
そしてこのオーディオデータファイル、動画データファイルについても、上記同様にデバイド処理が実行されることで、デバイド編集を効率化できる。
【０１７４】
また、本発明のシステムとしては、図１のような板状メモリに限定されるものではなく、他の外形形状とされた固体メモリ媒体（メモリチップ、メモリカード、メモリモジュール等）でも構わない。
また、これまで説明したファイルシステムのフォーマットも、例えば実際に応じてその細部の規定などは変更されて構わない。
更には、フラッシュメモリ容量のバリエーションも図８に示したものに限定されるものではない。もちろん、本発明の記録媒体のメモリ素子はフラッシュメモリに限られず、他の種のメモリ素子でもよい。
【０１７５】
【発明の効果】
以上の説明からわかるように、本発明の記録媒体は、記録されるデータファイルは、ファイル毎にそのデータファイルにかかる管理データ（ファイル内管理データ）が記憶され、しかもその管理データは少なくとも主データの位置及び再生対象とならない無効データ部分を管理できるものとされている。
また、１又は複数のデータファイルを管理するデータファイル管理情報により、各データファイルが管理される。
つまり、階層的な管理データが形成されていることで、データファイルの編集の際に、管理データの更新を最小限とすることができる。
【０１７６】
また、本発明の編集装置、編集方法によれば、データファイルの分割編集の際には、必要に応じて分割位置を含む記録データブロック（例えば上述したクラスタ／ブロック）が複製される。また分割対象となったデータファイルの管理データが書き換えられることで分割後の第１のデータファイルが形成される。さらに、分割による第２のデータファイルのための管理データが生成され第２のデータファイルの先頭に付加されるとともにその第２のデータファイル内に分割位置より前の主データ部分が存在する場合はそれが再生対象外の部分として扱われるようにすることで第２のデータファイルが形成される。さらに分割位置を含む記録データブロックは、複製され、それぞれ分割して生成される２つのデータファイルの構成部分となるように、記録データブロックの結合状態が編集される。これらのことにより、データファイルを分割するという編集のために必要となるデータ移動・複製・書換を最小限とすることができるという効果がある。
そしてまたそれによって編集のための処理時間や消費電力を最小限とできるという利点も有る。
【図面の簡単な説明】
【図１】本発明の実施の形態の板状メモリの外形形状を示す平面図、正面図、側面図、底面図である。
【図２】実施の形態のファイルシステム処理階層の説明図である。
【図３】実施の形態の板状メモリの物理的データ構造の説明図である。
【図４】実施の形態の板状メモリの管理フラグ内容の説明図である。
【図５】実施の形態の板状メモリにおけるデータ更新処理と物理アドレス及び論理アドレスの概念の説明図である。
【図６】実施の形態の論理−物理アドレス変換テーブルの管理形態の説明図である。
【図７】実施の形態の論理−物理アドレス変換テーブルの構造の説明図である。
【図８】実施の形態の板状メモリのフラッシュメモリ容量／ブロック数／１ブロックの容量／１ページの容量／論理−物理アドレス変換テーブルのサイズの関係の説明図である。
【図９】実施の形態のドライブ装置のブロック図である。
【図１０】ＦＡＴ構造の説明図である。
【図１１】ＦＡＴによるクラスタ管理形態の説明図である。
【図１２】ディレクトリの内容の説明図である。
【図１３】サブディレクトリ及びファイルの格納形態の説明図である。
【図１４】実施の形態の板状メモリのディレクトリ構成の説明図である。
【図１５】実施の形態のメッセージリストファイルの説明図である。
【図１６】実施の形態のメッセージリストファイルのヘッダの説明図である。
【図１７】実施の形態のメッセージリストファイルのフォルダエントリの説明図である。
【図１８】実施の形態のメッセージリストファイルのメッセージエントリの説明図である。
【図１９】実施の形態のメッセージデータファイルの構造の説明図である。
【図２０】実施の形態のメッセージデータファイルのフォーマットフレームの説明図である。
【図２１】実施の形態のメッセージデータファイルのフレーム構成例の説明図である。
【図２２】実施の形態のメッセージデータファイルのフレーム構成例の説明図である。
【図２３】実施の形態のメッセージデータファイルのスペースフレームの扱いの説明図である。
【図２４】実施の形態のメッセージデータファイルのスペースフレームの扱いの説明図である。
【図２５】実施の形態のデバイド処理のフローチャートである。
【図２６】実施の形態のデバイド処理の説明図である。
【図２７】実施の形態のデバイド処理前のＦＡＴの説明図である。
【図２８】実施の形態のデバイド処理後のＦＡＴの説明図である。
【図２９】実施の形態のＦＡＴ管理構造の説明図である。
【図３０】実施の形態のデバイド処理後のＦＡＴ管理構造の説明図である。
【図３１】実施の形態のＴＯＣフレームの構成の説明図である。
【図３２】実施の形態のデータフレームのデータ格納境界の説明図である。
【図３３】実施の形態のデータフレームのデータ格納境界の説明図である。
【図３４】実施の形態のデータフレームのデータ格納境界の説明図である。
【符号の説明】
１ 板状メモリ、２ 端子部、４ 凹凸部、５ スライドスイッチ、１００ セット本体、１０３ マイクロフォン、１０４ マイクアンプ、１０５ スピーカアンプ、１０６ スピーカ、１０７ 表示ドライバ、１０８ 表示部、１０９マイクロプロセッサ、１１２ 操作部、１２０ 着脱機構
【発明の属する技術分野】
本発明はファイルが記憶される記録媒体、及びこの記録媒体に記憶されたファイルに対する編集を行うことのできる編集装置、編集方法に関するものである。
【０００２】
【従来の技術】
近年、例えばフラッシュメモリなどの固体記憶素子を搭載した小型の記録媒体を形成し、専用のドライブ装置や、或いはドライブ装置をオーディオ／ビデオ機器、情報機器などに内蔵して、コンピュータデータ、画像データ、音声データなどを記憶できるようにするものが開発されている。
【０００３】
【発明が解決しようとする課題】
ところで、このような固体記憶素子を利用した記憶システムにおいては、記憶したファイルに対する編集処理を行うことが求められている。
そしてさらに、単に編集可能とするだけでなく、その編集処理がより効率化されること、例えば記録媒体内でのファイル編集のために必要となるデータ移動・複製・書換などが最小限であることや、編集のための処理時間や消費電力を最小限とすることが要求されている。
【０００４】
【課題を解決するための手段】
本発明はこのような要望に応じて、効率的な編集処理を実現できる記憶システムを構築することを目的とする。
【０００７】
また本発明の編集装置は、記録媒体に記録された、固定長の記録データブロックを１または複数連結した主データと、上記主データに付加されて上記主データの上記記録媒体におけるアドレスとして示される記録位置及び再生されない無効データの位置を上記アドレスの更新により管理可能とする管理データとから構成されるデータファイルを、分割する編集装置として、上記データファイルを分割する分割位置を指定して、上記分割位置のアドレスにおいて前後となる第１のデータファイルと第２のデータファイルに分割することを指示できる操作手段と、上記操作手段の分割指示に応じて、上記管理データにおける主データの記録位置及び無効データの位置を更新して第１の管理データとすることで、該第１の管理データで管理される上記第１のデータファイルが生成される第１データファイル生成手段と、上記操作手段の分割指示に応じて、主データの記録位置及び無効データの位置を管理する第２の管理データを生成し、上記分割位置より後のデータファイル部分に付加することで、上記第２の管理データで管理される上記第２のデータファイルが生成される第２データファイル生成手段と、を備え、上記第１の管理データが管理する無効データは、少なくとも上記分割位置を含む上記記録データブロックのうちの、上記分割位置より後ろに位置されていた主データ部分であり、上記第２の管理データが管理する無効データは、少なくとも上記分割位置を含む上記記録データブロックのうちの、上記分割位置より前に位置されていた主データであるようにする。
【０００８】
さらに本発明では、記録媒体に記録された、固定長の記録データブロックを１または複数連結した主データと、上記主データに付加されて上記主データの上記記録媒体におけるアドレスとして示される記録位置及び再生されない無効データの位置を上記アドレスの更新により管理可能とする管理データとから構成されるデータファイルを分割する編集装置における編集方法として、上記データファイルを、第１のデータファイルと第２のデータファイルに分割するための分割位置を設定する設定手順と、上記設定手順で設定された分割位置に基づいて、上記管理データにおける主データの記録位置及び無効データの位置を更新して第１の管理データとすることで、該第１の管理データで管理される上記第１のデータファイルが生成されるようにする第１データファイル生成手順と、上記設定手順で設定された分割位置に基づいて、主データの記録位置及び無効データの位置を管理する第２の管理データを生成し、上記分割位置よりアドレスにおいて後のデータファイル部分に付加することで、上記第２の管理データで管理される上記第２のデータファイルが生成されるようにする第２データファイル生成手順と、が行われ、上記第１の管理データが管理する無効データは、少なくとも上記分割位置を含む上記記録データブロックのうちの、上記分割位置よりアドレスにおいて後ろに位置されていた主データ部分であり、上記第２の管理データが管理する無効データは、少なくとも上記分割位置を含む上記記録データブロックのうちの、上記分割位置よりアドレスにおいて前に位置されていた主データであるようにする。
【０００９】
即ち本発明では、データファイル毎に管理データが記録され、その管理データが書き換えられること、必要に応じて分割位置を含む単位データが複製されること、及び管理データ内で再生対象としない部分を設定できることで、データファイルを分割するという編集のために必要となるデータ移動・複製・書換を最小限とする。そしてまたそれによって編集のための処理時間や消費電力を最小限とするものである。
【００１０】
【発明の実施の形態】
以下、本発明の実施の形態について説明する。なお、実施の形態としての記録媒体は板状の外形形状を有する板状メモリとし、また本発明の編集装置、編集方法は、板状メモリに対してファイルの記録再生を行うことのできるドライブ装置及びそのドライブ装置による編集方法が相当するものとする。
説明は次の順序で行う。
１．板状メモリの外形形状
２．板状メモリのフォーマット
２−１．メモリファイルシステム処理階層
２−２．物理的データ構造
２−３．物理アドレス及び論理アドレスの概念
２−４．論理−物理アドレス変換テーブル
３．ドライブ装置の構成
４．ＦＡＴ構造
５．板状メモリのファイル構造
５−１ ディレクトリ構成
５−２ メッセージリストファイル
５−３ メッセージデータファイル
６．デバイド編集処理
【００１１】
１．板状メモリの外形形状
まず図１により、本例の記録媒体である、板状メモリ１の外形形状について説明する。
板状メモリ１は、例えば図１に示すような板状の筐体内部に例えば所定容量ののメモリ素子を備える。本例としては、このメモリ素子としてフラッシュメモリ（Flash Memory）が用いられるものである。
図１に平面図、正面図、側面図、底面図として示す筐体は例えばプラスチックモールドにより形成され、サイズの具体例としては、図に示す幅Ｗ１１、Ｗ１２、Ｗ１３のそれぞれが、Ｗ１１＝６０ｍｍ、Ｗ１２＝２０ｍｍ、Ｗ１３＝２．８ｍｍとなる。
【００１２】
筐体の正面下部から底面側にかけて例えば９個の電極を持つ端子部２が形成されており、この端子部２から、内部のメモリ素子に対する読出又は書込動作が行われる。
筐体の平面方向の左上部は切欠部３とされる。この切欠部３は、この板状メモリ１を、例えばドライブ装置本体側の着脱機構へ装填する際などに挿入方向を誤ることを防止するためのものとなる。
また筐体底面側には使用性の向上のため滑り止めを目的とした凹凸部４が形成されている。
さらに底面側には、記憶内容の誤消去を防止する目的のスライドスイッチ５が形成されている。
【００１３】
２．板状メモリのフォーマット
２−１．メモリファイルシステム処理階層
続いて、板状メモリ１を記録媒体とするシステムにおけるフォーマットについて説明していく。
図２は、板状メモリ１を記録媒体とするシステムのファイルシステム処理階層を示すものである。
この図に示すように、ファイルシステム処理階層としては、アプリケーション処理層の下に、順次、ファイル管理処理層、論理アドレス層、物理アドレス層、フラッシュメモリアクセスがおかれる。
この階層では、ファイル管理処理層がいわゆるＦＡＴ（File Allocation Table）となる。
また、この図から分かるように、本例のファイルシステムでは論理アドレス及び物理アドレスという概念が導入されているが、これについては後述する。
【００１４】
２−２．物理的データ構造
図３には、板状メモリ１内の記憶素子である、フラッシュメモリの物理的データ構造が示されている。
フラッシュメモリとしての記憶領域は、セグメントという固定長のデータ単位が大元となる。このセグメントは、１セグメントあたり４ＭＢ（メガバイト）或いは８ＭＢとして規定されるサイズであり、１つのフラッシュメモリ内におけるセグメント数は、そのフラッシュメモリの容量に依存して異なってくる。
【００１５】
そして、この１セグメントを図３（ａ）に示すように、ブロックという固定長のデータ単位として８ＫＢ（キロバイト）又は１６ＫＢにより区切るようにされる。原則として、１セグメントは５１２ブロックに区切られることから、図３（ａ）に示すブロックｎについては、ｎ＝５１１とされることになる。但し、フラッシュメモリでは、書き込み不可な損傷エリアであるディフェクトエリアとしてのブロック数が所定数の範囲で許可されているため、データ書き込みが有効とされる実質的なブロック数を対象とすれば、上記ｎは５１１よりも少なくなる。
【００１６】
図３（ａ）に示すようにして形成されるブロック０〜ｎのうち、先頭の２つのブロック０，１はブートブロックといわれる。但し、実際には有効なブロックの先頭から２つのブロックがブートブロックとして規定されることになっており、必ずしもブートブロックがブロック０，１である保証はない。
そして、残りのブロックが、ユーザデータが格納されるユーザブロックとなる。
【００１７】
１ブロックは、図３（ｄ）に示すようにして、ページ０〜ｍにより分割される。１ページの容量は、図３（ｅ）に示すように、５１２バイトのデータエリアと１６バイトの冗長部よりなる、５２８（＝５１２＋１６）バイトの固定長とされる。なお、冗長部の構造については図３（ｆ）により後述する。
また、１ブロック内のページ数としては、１ブロックの容量が８ＫＢの場合には１６ページ、１６ＫＢの場合には３２ページとなる。
【００１８】
このような、図３（ｄ）（ｅ）に示されるブロック内のページ構造は、上記ブートブロックとユーザブロックとで共通である。
また、フラッシュメモリでは、データの読み出し、及び書き込みはページ単位で行われ、データの消去はブロック単位で行われるものとされる。そして、データの書き込みは、消去済みのページに対してしか行われないものとされている。従って、実際のデータの書き換えや書き込みは、ブロック単位を対象として行われることになる。
【００１９】
先頭のブートブロックは、図３（ｂ）に示すように、ページ０に対してヘッダーが格納され、ページ１には初期不良データの位置（アドレス）を示す情報が格納される。また、ページ２にはＣＩＳ／ＩＤＳといわれる情報が格納される。
２つめのブートブロックは図３（ｃ）に示すように、ブートブロックとしてのバックアップのための領域とされている。
【００２０】
図３（ｅ）に示された冗長部（１６バイト）は、図３（ｆ）に示す構造を有する。
この冗長部は、図のように先頭の第０バイト〜第２バイトの３バイトが、データエリアのデータ内容の更新に応じて書き換えが可能なオーバーライトエリアとされる。このオーバーライトエリアのうち、第０バイトにはブロックステータスが格納され、第１バイトにはデータステータスが格納される(Block Flag Data)。また、第２バイトの上位の所定ビットを利用して変換テーブルフラグ(Page Data Status1)が格納される。
【００２１】
原則として第３バイト〜第１５バイトは、その内容が現ページのデータ内容に応じて固定とされ、書き換えが不可とされる情報が格納される領域となる。
第３バイトには管理フラグ(Block Info)が格納され、第４，第５バイトから成る２バイトの領域には、後述する論理アドレス(Logic Address)が格納される。第６〜第１０バイトの５バイトの領域は、フォーマットリザーブの領域とされ、続く第１１，第１２バイトの２バイトが、上記フォーマットリザーブに対して誤り訂正を施すための分散情報ＥＣＣを格納する領域とされる。
残る第１３〜第１５バイトには、図３（ｅ）に示すデータエリアのデータに対して誤り訂正を行うためのデータＥＣＣが格納される。
【００２２】
上記図３（ｆ）に示した冗長部の第３バイトに格納される管理フラグは、図４に示すようにして、ビット７〜ビット０の各ビットに、その内容が定義されている。
ビット７，６、及びビット１，０はリザーブ（未定義）領域とされている。
ビット５は現ブロックに対してのアクセス許可の「有効」（‘１’；Free）／「無効」(‘０’；Read Protected）を示すフラグが格納される。ビット４には現ブロックについてのコピー禁止指定（‘１’；ＯＫ ／‘０’；ＮＧ）についてのフラグが格納される。
【００２３】
ビット３は変換テーブルフラグとされる。この変換テーブルフラグは、現ブロックが後述する論理−物理アドレス変換テーブルであるのか否かを示す識別子であり、このビット３の値が‘０’とされていれば、現ブロックは論理−物理アドレス変換テーブルであることが識別され、‘０’であれば無効となる。つまり、現ブロックは論理−物理アドレス変換テーブルではないことが識別される。
【００２４】
ビット２はシステムフラグが格納され、‘１’であれば現ブロックがユーザブロックであることが示され、‘０’であればブートブロックであることが示される。
【００２５】
ここで、セグメント及びブロックと、フラッシュメモリ容量との関係を図８（左３列を参照）により説明しておく。
板状メモリ１のフラッシュメモリ容量としては、４ＭＢ，８ＭＢ，１６ＭＢ，３２ＭＢ，６４ＭＢ，１２８ＭＢの何れかであるものとして規定されている。
そして、最も容量の小さい４ＭＢの場合であると、１ブロックは８ＫＢと規定された上で、そのブロック数としては５１２個とされる。つまり、４ＭＢはちょうど１セグメントの容量を有するものとされる。そして、４ＭＢの容量であれば、同様に１ブロック＝８ＫＢの容量が規定された上で、２セグメント＝１０２４ブロックとなる。なお、前述したように、１ブロック＝８ＫＢであれば、１ブロック内のページ数は１６ページとなる。
但し１６ＭＢの容量では、１ブロックあたりの容量として８ＫＢと１６ＫＢの両者が存在することが許可されている。このため、２０４８ブロック＝４セグメント（１ブロック＝８ＫＢ）のものと、１０２４ブロック＝２セグメント（１ブロック＝１６ＫＢ）のものとの２種類が在ることになる。１ブロック＝１６ＫＢの場合には、１ブロック内のページ数は３２ページとなる。
【００２６】
また、３２ＭＢ，６４ＭＢ，１２８ＭＢの容量では、１ブロックあたりの容量は１６ＫＢのみであるとして規定される。従って、３２ＭＢでは２０４８ブロック＝４セグメントとなり、６４ＭＢでは４０９６ブロック＝８セグメントとなり、１２８ＭＢでは８１９２ブロック＝１６セグメントとなる。
【００２７】
２−３．物理アドレス及び論理アドレスの概念
次に、上述したようなフラッシュメモリの物理的データ構造を踏まえたうえで、図５に示すデータ書き換え動作に従って、本例のファイルシステムにおける物理アドレスと論理アドレスの概念について説明する。
【００２８】
図５（ａ）には、或るセグメント内から４つのブロックを抜き出して、これを模式的に示している。
各ブロックに対しては物理アドレスが付される。この物理アドレスはメモリにおけるブロックの物理的な配列順に従って決まるもので、或るブロックとこれに対応付けされた物理アドレスとの関係は不変となる。ここでは、図５（ａ）に示す４ブロックに対して、上から順に物理アドレスの値として、１０５，１０６，１０７，１０８が付されている。なお、実際の物理アドレスは２バイトにより表現される。
【００２９】
ここで、図５（ａ）に示すように、物理アドレス１０５，１０６で示されるブロックがデータの記憶されている使用ブロックで、物理アドレス１０７，１０８で示されるブロックがデータが消去（即ち、未記録領域）された未使用ブロックとなっている状態であるとする。
【００３０】
そして、論理アドレスであるが、この論理アドレスは、ブロックに対して書き込まれたデータに付随するようにして割り振られるアドレスとされる。そして、この論理アドレスが、後述するＦＡＴファイルシステムが利用するアドレスとされている。
図５（ａ）では、４つの各ブロックに対して、上から順に論理アドレスの値として、１０２，１０３，１０４，１０５が付されている状態が示されている。なお、論理アドレスも実際には２バイトにより表現されるものである。
【００３１】
ここで、上記図５（ａ）に示す状態から、例えば物理アドレス１０５に格納されているデータの更新として、内容の書き換え又は一部消去を行うとする。
このような場合、フラッシュメモリのファイルシステムでは、同じブロックに対して更新したデータを再度書き込むことはせずに、未使用のブロックに対してその更新したデータを書き込むようにされる。
つまり、例えば図５（ｂ）に示すようにして、物理アドレス１０５のデータは消去したうえで、更新されたデータはこれまで未使用ブロックであった物理アドレス１０７で示されるブロックに書き込むようにされる（処理▲１▼）。
【００３２】
そして、処理▲２▼として示すように、データ更新前（図５（ａ））の状態では物理アドレス１０５に対応していた論理アドレス１０２が、更新されたデータが書き込まれたブロックの物理アドレス１０７に対応するように、論理アドレスについての変更を行うものである。これに伴って、データ更新前は物理アドレス１０７に対応していた論理アドレス１０４については、物理アドレス１０５に対応するように変更されている。
【００３３】
つまり、物理アドレスはブロックに対して固有に付されるアドレスであり、論理アドレスは、一旦ブロックに対して書き込まれたデータに付随するようにしてついて回る、ブロック単位の書き込みデータに固有となるアドレスであるとみることができる。
【００３４】
このようなブロックのスワップ処理が行われることで、或る同一の記憶領域（ブロック）に対して繰り返し集中的にアクセスされることが無くなり、書き換え回数の上限があるフラッシュメモリの寿命を延ばすことが可能となる。
そして、この際に論理アドレスを上記処理▲２▼のようにして扱うことで、ブロックのスワップ処理によって更新前と更新後のデータとで書き込まれるブロックの移動があるようにされても、ＦＡＴからは同一のアドレスが見えることになり、以降のアクセスを適正に実行することができるものである。
なお、後述する論理−物理アドレス変換テーブル上での更新のための管理を簡略にすることなどを目的として、ブロックのスワップ処理は、１セグメント内で完結するものとして規定されている。逆に言えば、ブロックのスワップ処理はセグメント間で跨るようにしては行われない。
【００３５】
２−４．論理−物理アドレス変換テーブル
上記図５による説明から分かるように、ブロックのスワップ処理が行われることで、物理アドレスと論理アドレスの対応は変化する。従って、フラッシュメモリに対するデータの書き込み及び読み出しのためのアクセスを実現するには、物理アドレスと論理アドレスとの対応が示される論理−物理アドレス変換テーブルが必要となる。つまり、論理−物理アドレス変換テーブルをＦＡＴが参照することで、ＦＡＴが指定した論理アドレスに対応する物理アドレスが特定され、この特定された物理アドレスにより示されるブロックにアクセスすることが可能になるものである。逆に言えば、論理−物理アドレス変換テーブルが無ければ、ＦＡＴによるフラッシュメモリへのアクセスが不可能となる。
【００３６】
従来では、例えばセット本体に対して板状メモリ１が装着されたときに、セット本体側のマイクロプロセッサが板状メモリ１の記憶内容をチェックすることで、セット本体側で論理−物理アドレス変換テーブルの構築を行い、更にこの構築された論理−物理アドレス変換テーブルをセット本体側のＲＡＭに格納するようにしていた。つまり、板状メモリ１内には、論理−物理アドレス変換テーブルの情報は格納されてはいなかった。
これに対して本例では、以降説明するように板状メモリ１に対して、論理−物理アドレス変換テーブルを格納するように構成している。
【００３７】
図６は、本例の板状メモリ１に対して格納される論理−物理アドレス変換テーブルの構築形態を概念的に示すものである。
つまり、本例では、例えば論理アドレスの昇順に従って、これに対応する２バイトの物理アドレスを格納するようにしたテーブル情報を論理−物理アドレス変換テーブルとして構築するようにされる。
なお、前述したように、物理アドレス、及び論理アドレスは共に２バイトで表現される。これは、１２８ＭＢの最大容量のフラッシュメモリの場合には８１９２個のブロックが存在するため、最大で、この８１９２個のブロック数をカバーできるだけのビット数が必要とされることに基づく。
このため、図６において例示している物理アドレスと論理アドレスとについても、実際に即して２バイトで表現している。
但し、ここでは、この２バイトを１６進数により表記している。つまり、「０ｘ」によりその後続く値が１６進法表記であることが示される。なお、この「０ｘ」により１６進数であることを表す表記は、以降の説明において１６進数を表記する場合にも同様に用いることとする。（但し、表記の煩雑化を防ぐため「０ｘ」を省略している図面もある。）
【００３８】
図７に、上記図６に示した概念に基づく論理−物理アドレス変換テーブルの構造例を示す。
論理−物理アドレス変換テーブルは、フラッシュメモリの最後のセグメント内の或るブロックに対して、図７に示すようにして格納される。
先ず図７（ａ）に示すように、ブロックを分割するページのうち、ページ０，１からなる２ページの領域がセグメント０用の論理−物理アドレス変換テーブルとして割り当てられる。例えば、図８にて説明したように、フラッシュメモリが４ＭＢの容量であれば１セグメントしか有さないために、このページ０，１のみの領域が論理−物理アドレス変換テーブルの領域となる。
また、例えばフラッシュメモリが８ＭＢの容量であれば２セグメントを有するため、セグメント０用の論理−物理アドレス変換テーブルとして割り当てられるページ０，１に加え、これに続くページ２，３の２ページがセグメント１用の論理−物理アドレス変換テーブルとして割り当てられることになる。
【００３９】
以降、フラッシュメモリの容量の増加に応じて、続く２ページごとにセグメントごとの論理−物理アドレス変換テーブルの割り当て領域が設定されていくことになる。そして、最大の１２８ＭＢの容量を有する場合であれば１６セグメントが存在するため、最大では、セグメント１５用までのページが論理−物理アドレス変換テーブルの領域として割り当てられることになる。従って、最大の１２８ＭＢの容量のフラッシュメモリでは、３０ページが使用されることになり、図７（ａ）に示すページＮとしては、最大でＮ＝２９となる。
これまでの説明から分かるように、論理−物理アドレス変換テーブルは、セグメントごとに管理されるものである。
【００４０】
図７（ｂ）は、１セグメントあたりの論理−物理アドレス変換テーブルの構造を示すものとして、２ページ分のデータエリアを抜き出して示している。つまり、１ページのデータエリアは５１２バイト（図３（ｅ）参照）であることから、図７（ｂ）には、１０２４（＝５１２×２）バイトが展開されている状態が示されている。
【００４１】
図７（ｂ）に示すように、この２ページ分のデータエリアである１０２４バイトについて２バイトごとに区切り、この２バイトごとの領域を、先頭から順次、論理アドレス０用、論理アドレス１用・・・・、のようにして割付を行い、最後は先頭から９９１バイト目と９９２バイト目の２バイトの領域を論理アドレス４９５用の領域として割り付けるように規定を行う。これら２バイトごとの領域に対して、各論理アドレスが対応する物理アドレスを書き込むようにする。従って、本例の論理−物理アドレス変換テーブルでは、実際のデータ更新によるブロックのスワップ処理などにより物理アドレスと論理アドレスの対応が変更された場合には、論理アドレスを基準として、物理アドレスの格納状態が更新されるようにしてテーブル情報の書き換えが行われることになる。
【００４２】
また、残る９９３バイト目から最後の１０２４バイト目までの計３２バイトの領域は、余剰ブロックの物理アドレスが格納される領域として割り当てられる。つまり、１６個の余剰ブロックの物理アドレスを管理することができる。ここでいう余剰ブロックとは、例えばブロック単位でデータの更新を行う際に書き換え対象となるデータを一時待避させる領域として設定されたいわゆるワークブロックなどを言うものである。
【００４３】
ところで、１セグメントは５１２ブロックに分割されているものであると先に説明したのにも関わらず、図７に示したテーブル構造では、管理可能なブロック数が論理アドレス０用〜論理アドレス４９５用の４９６ブロックとしている。これは、実際上、上記した余剰アドレスが設定されることと、前述したように、フラッシュメモリでは、或ブロック数のディフェクト（使用不可領域）が許可されている。そのため現実には、相当数のディフェクトブロックが存在することに依る。
従って、実際には、書き込み／消去が有効なブロックを管理するのに、４９６ブロックを管理できるように構成しておけば充分とされるものである。
【００４４】
そして、このようにして論理−物理アドレス変換テーブルが格納されるブロックについては、これを形成する各ページの冗長部における管理フラグ（図４参照）のデータ内容として、この管理フラグのビット３に対して‘０’がセットされることになる。これにより、当該ブロックが論理−物理アドレス変換テーブルが格納されているブロックであることが示されることになる。
【００４５】
論理−物理アドレス変換テーブルが格納されるブロックも、論理−物理アドレス変換テーブルの内容の書き換えがあった場合には、例外なく、先に図５にて説明したスワップ処理が行われる。従って、論理−物理アドレス変換テーブルが記録されているブロックは不定であり、或る特定のブロックに論理−物理アドレス変換テーブルを格納するように規定することは出来ない。
そこで、ＦＡＴは、フラッシュメモリにアクセスして上記した管理フラグのビット３が‘０’とされているブロックを検索することで、論理−物理アドレス変換テーブルが格納されているブロックを識別するようにされる。但し、論理−物理アドレス変換テーブルが格納されているブロックの検索がＦＡＴによって容易に行われるようにすることを考慮して、論理−物理アドレス変換テーブルが格納されているブロックは、そのフラッシュメモリ内における最後のナンバが付されたセグメントに在るように、本例では規定するものとされる。これにより、ＦＡＴは最後のナンバが付されたセグメントのブロックのサーチだけで、論理−物理アドレス変換テーブルを検索することができる。つまり、論理−物理アドレス変換テーブルを検索するのに、フラッシュメモリの全てのセグメントを検索する必要は無いようにされる。
上記図７に示した論理−物理アドレス変換テーブルは、例えば板状メモリ１の製造時において格納するようにされる。
【００４６】
ここで、再度図８を参照して、フラッシュメモリ容量と論理−物理アドレス変換テーブルのサイズとの関係を説明しておく。
上記図７にて説明したように、１セグメントを管理するための論理−物理アドレス変換テーブルのサイズは２ページ分の１０２４バイト、つまり１ＫＢとなる。従って、図８の最右列に記されているように、フラッシュメモリが４ＭＢ（１セグメント）の容量では論理−物理アドレス変換テーブルは１ＫＢのサイズとなる。また、フラッシュメモリの容量が８ＭＢ（２セグメント）では論理−物理アドレス変換テーブルは２ＫＢ（４ページ）となる。
また、フラッシュメモリの容量が１６ＭＢの場合、２０４８ブロック＝４セグメントのものでは論理−物理アドレス変換テーブルは４ＫＢ（８ページ）、１０２４ブロック＝２セグメントのものでは論理−物理アドレス変換テーブルは２ＫＢ（４ページ）となる。
そして、フラッシュメモリの容量が３２ＭＢ（４セグメント）では論理−物理アドレス変換テーブルは４ＫＢ（８ページ）、フラッシュメモリの容量が６４ＭＢ（８セグメント）では論理−物理アドレス変換テーブルは８ＫＢ（１６ページ）となり、フラッシュメモリの容量が最大の１２８ＭＢ（１６セグメント）では論理−物理アドレス変換テーブルは１６ＫＢ（３２ページ）となる。
【００４７】
３．ドライブ装置の構成
続いて図９で本例のドライブ装置の構成を説明する。
図９は、これまで説明した板状メモリ１に対応してデータの読出・書込・編集を行うことの出来るドライブ装置のセット本体（本体装置）の構成を示している。この図に示すセット本体１００と板状メモリ１とにより、ファイル記憶システムが構成される。
なお、セット本体１００が、板状メモリ１に対する書込や読出の対象として扱うことのできる主データの種類は多様であり、例えば動画データ、静止画データ、マイクロホンから入力される口述音声等のマイクロホン入力音声データ（以下、メッセージデータ）、ＣＤ（Compact Disc：商標）やＭＤ（Mini Disc：商標）等の記録媒体に記録された高音質なオーディオデータ（以下、音楽用データ）、制御用データ、電話帳データなどがある。
本例では、説明の簡略化のため、主データとしてメッセージデータ（マイクロホン入力音声データ）を記憶／再生するシステムとして説明していくが、セット本体１００内に、動画、静止画、音楽等のデータの入出力系／処理系を備えることにより、上記の動画データ等のデータファイルの記憶システムとできることはいうまでもない。
【００４８】
セット本体１００の構成としては、当該セット本体１００が着脱可能に装填される着脱機構１２０が備えられ、この着脱機構１２０に装填された板状メモリ１と、マイクロプロセッサ１０９とのデータの授受は、ホストインターフェイスＩＣ１０１を介することで行われる。
【００４９】
また、このセット本体１００には、例えば、マイクロフォン１０３が備えられて、このマイクロフォン１０３により収音された音声は、マイクアンプ１０４を介して音声信号としてＤＳＰ(Digital Signal Processor)１０２に対して供給される。ＤＳＰ１０２では、この入力された音声信号をデジタルオーディオデータに変換して、エンコード処理等をはじめとする所要の信号処理を施し、記録データとして制御用マイクロプロセッサ１０９に供給する。
マイクロプロセッサ１０９は、この記録データをホストインターフェイスＩＣ１０１を介して板状メモリ１に記録するための処理を実行することが可能とされる。
【００５０】
また、マイクロプロセッサ１０９は、板状メモリ１に記録されているオーディオデータ又はメッセージデータとしてのデータファイルをホストインターフェイスＩＣ１０１を介して読み出し、この読み出したデータをＤＳＰ１０２に供給する。
ＤＳＰ１０２では、供給されたデータについて復調処理をはじめとする所要の信号処理を施して、最終的にはアナログ音声信号としてスピーカアンプ１０５に出力する。スピーカアンプ１０５では、入力された音声信号を増幅してスピーカ１０６に出力する。これにより、再生音声が出力される。
【００５１】
また、マイクロプロセッサ１０９は、表示ドライバ１０７を制御することで、表示部１０８に対して、所要の画像を表示させることが可能とされる。例えばユーザーの操作のためのメニューやガイド表示、或いは板状メモリ１に記憶されたファイル内容などの表示が実行される。また、例えば板状メモリ１に対して動画若しくは静止画の画像データが記録されているとすれば、この画像データを読み出して、表示部１０８に表示させるようにすることも可能とされる。
【００５２】
操作部１１２には、セット本体１００に対する各種操作をユーザが行うための各種キーが設けられている。マイクロプロセッサ１０９は、この操作部１１２に対して行われた操作に応じたコマンドを受信し、コマンドに応じた所要の制御処理を実行する。
操作内容としては、ファイル記憶指示、ファイル選択指示、ファイル再生指示、編集指示（後述するデバイド指示その他）などが可能とされる。
【００５３】
なお、この図に示すセット本体１００の構成はあくまでも一例であり、これに限定されるものではない。つまり、板状メモリ１に対応してデータの送受信が可能な構成を採る限りは、どのようなタイプの電子機器とされていても構わないものである。
【００５４】
４．ＦＡＴ構造
図２のファイルシステム階層で説明したように、ファイル管理処理はＦＡＴにより行われることになる。
即ち図９に示した構成のドライブ装置により、板状メモリ１に対する記録再生（データ書込／読出）を実現するには、アプリケーション処理での要求に伴ってＦＡＴによるファイル記憶位置管理が参照され、さらに上述した論理−物理アドレス変換が行われて実際のアクセスが行われることになる。
ここで、ＦＡＴの構造について説明しておく。
【００５５】
図１０はＦＡＴによる管理構造の概要を示している。
なお、本例ではＦＡＴ及び論理−物理アドレス変換テーブルは板状メモリ１内に格納されることになるが、図１０に示すＦＡＴ構造が、板状メモリ１内での管理構造となるものである。
【００５６】
そして、図示するようにＦＡＴ管理構造は、パーティションテーブル、空き領域、ブートセクタ、ＦＡＴ、ＦＡＴのコピー、ルートディレクトリ、データ領域から成る。
データ領域には、クラスタ２、クラスタ３・・・として単位データを示しているが、このクラスタとは、管理単位となるＦＡＴで扱う１データ単位である。
一般にＦＡＴでは、クラスタサイズは標準で４Ｋバイトとされるが、このクラスタサイズは５１２バイト〜３２Ｋバイトの間で２のべき乗の大きさをとることができる。
本例の板状メモリ１では、上述したように１つのブロックが８Ｋバイト又は１６Ｋバイトとされるが、１ブロック＝８Ｋバイトとされる板状メモリ１の場合は、ＦＡＴで扱うクラスタは８Ｋバイトとされる。また１ブロック＝１６Ｋバイトとされる板状メモリ１の場合は、ＦＡＴで扱うクラスタは１６Ｋバイトとされる。即ち、８Ｋバイト又は１６ＫバイトがＦＡＴ管理上でのデータ単位であり、かつ板状メモリ１でのブロックとしての１つのデータ単位とされる。なお、従って板状メモリからみれば、ＦＡＴで扱われるクラスタサイズ＝その板状メモリのブロックサイズとなる。このため、本例の以降の説明については、簡略化のためにブロック＝クラスタとして考えることとする。
【００５７】
そして図１０左側にブロックナンバとしてｘ・・・（ｘ＋ｍ−１）、（ｘ＋ｍ）（ｘ＋ｍ＋１）（ｘ＋ｍ＋２）・・・と示したが、例えばこのように各ブロックにおいてＦＡＴ構造を構築する各種データは記憶されることになる。
なお、実際には必ずしもこのように物理的に連続する各ブロックに各情報が記憶されるものではない。
【００５８】
ＦＡＴ構造において、まずパーティションテーブルには、ＦＡＴパーティション（最大２Ｇバイト）の先頭と終端のアドレスが記述されている。
ブート領域には、いわゆる１２ｂｉｔＦＡＴ、１６ｂｉｔＦＡＴの別や、ＦＡＴ構造（大きさ、クラスタサイズ、各領域のサイズなど）が記述される。
【００５９】
ＦＡＴは、後述するように各ファイルを構成するクラスタのリンク構造を示すテーブルとなり、またＦＡＴについては続く領域にコピーが記述される。
ルートディレクトリには、ファイル名、先頭クラスタ番号、各種属性が記述される。これらの記述は１つのファイルにつき３２バイト使用される。
【００６０】
ＦＡＴにおいては、ＦＡＴのエントリとクラスタは１対１で対応しており、各クラスタのエントリにはリンク先、つまり後に続くクラスタの番号が記述される。つまり、複数のクラスタ（＝ブロック）で形成されている或るファイルについてみると、まずディレクトリによって先頭のクラスタ番号が示され、ＦＡＴにおけるその先頭クラスタのエントリには、次のクラスタ番号が示される。さらに次のクラスタ番号のエントリには、さらに次のクラスタ番号が示される。このようにクラスタのリンクがＦＡＴに記述される。
【００６１】
図１１はこのようなリンクの概念を模式的に示している（数値は１６進値）。例えば２つのファイル「ＭＡＩＮ．Ｃ」「ＦＵＮＣ．Ｃ」が存在するとすると、ディレクトリにはこの２つのファイルの先頭クラスタ番号が例えば「００２」「００４」と記述される。
そしてファイル「ＭＡＩＮ．Ｃ」については、クラスタ番号「００２」のエントリに次のクラスタ番号「００３」が記述され、またクラスタ番号「００３」のエントリに次のクラスタ番号「００６」が記述される。さらに、クラスタ番号００６がこのファイル「ＭＡＩＮ．Ｃ」の最後のクラスタであるとすると、クラスタ番号「００６」のエントリには、最後のクラスタであることを示す「ＦＦＦ」が記述される。
これによりファイル「ＭＡＩＮ．Ｃ」がクラスタ「００２」→「００３」→「００６」という順番で記憶されている。即ち、仮にクラスタ番号と板状メモリ１でのブロック番号が一致していると仮定すると、ファイル「ＭＡＩＮ．Ｃ」は、板状メモリ１内でブロック「００２」「００３」「００６」に記憶されていることが表現されている。（但し、ＦＡＴで扱うクラスタは、上述のように論理アドレスで扱うものとなるため、ブロックの物理アドレスとそのまま一致するものではない）
【００６２】
また同様にファイル「ＦＵＮＣ．Ｃ」については、ＦＡＴにより、クラスタ「００４」→「００５」に記憶されていることが表現される。
【００６３】
なお、未使用のブロックに対応するクラスタについては、そのエントリは「０００」とされる。
【００６４】
ところでルートディレクトリの領域に記憶される各ファイルのディレクトリにおいては、図１１に示した先頭クラスタ番号だけでなく、例えば図１２のように各種データが記述される。
即ちファイル名、拡張子、属性、変更時刻情報、変更日付情報、先頭クラスタ番号、ファイルサイズが、それぞれ図示するバイト数で記述される。
【００６５】
また或るディレクトリの下層となるサブディレクトリについては、図１０のルートディレクトリの領域ではなく、データ領域に記憶される。つまりサブディレクトリは、ディレクトリ構造を持つファイルとして扱われる。そしてサブディレクトリの場合はサイズは無制限とされ、また自分自身へのエントリと親ディレクトリへのエントリが必要になる。
【００６６】
図１３に、或るルートディレクトリ内にファイル「ＤＩＲ１」（属性＝ディレクトリ：つまりサブディレクトリ）があり、さらにその中にファイル「ＤＩＲ２」（属性＝ディレクトリ：つまりサブディレクトリ）があり、さらにその中にファイル「ＦＩＬＥ」が存在する場合の構造例を示している。
つまりルートディレクトリの領域には、サブディレクトリであるファイル「ＤＩＲ１」としての先頭クラスタ番号が示され、上述したＦＡＴにより、クラスタＸ、Ｙ、Ｚがリンクされている状態となる。
この図からわかるように、サブディレクトリ「ＤＩＲ１」「ＤＩＲ２」についてはファイルとして扱われてＦＡＴのリンクに組み込まれる。
【００６７】
以上の説明を図２９を用いてまとめる。
図２９にＦＡＴ管理による管理方法を説明する。
図２９は、板状メモリ１内の模式図（メモリマップ）を示しており、上からパーティションテーブル、空き領域、ブートセクター、ＦＡＴ領域、ＦＡＴのコピー領域、ルートディレクトリ領域、サブディレクトリ領域、データ領域が積層されている。
なお、このメモリマップは上述した論理−物理アドレス変換テーブルに基づく、論理アドレス→物理アドレス変換後のメモリマップである。
【００６８】
ブートセクター、ＦＡＴ領域、ＦＡＴのコピー領域、ルートディレクトリ領域、サブディレクトリ領域、データ領域を全部まとめてＦＡＴパーティション領域と称する。
【００６９】
上記パーティションテーブルにはＦＡＴパーティション領域のはじめと終わりのアドレスが記録されている。
なお通常フロッピーディスクで使用されているＦＡＴには上記パーティションテーブルは備えられていない。
またメモリ内の先頭領域にはパーティションテーブル以外のものは置かないために図示するように空きエリアが生ずる。
【００７０】
ブートセクターには１２ビットＦＡＴ／１６ビットＦＡＴであるかの別に応じてＦＡＴ構造の大きさ、クラスタサイズ、それぞれの領域のサイズが記録されている。
ＦＡＴはデータ領域に記録されているファイル位置を管理するものである。
ＦＡＴのコピー領域はＦＡＴのバックアップ用の領域である。
【００７１】
ルートディレクトリはファイル名、先頭クラスタアドレス、各種属性が記録されており、１ファイルにつき３２バイト使用する。
サブディレクトリはディレクトリというファイルの属性のファイルとして存在しており、この図２９の例ではＰＢＬＩＳＴ．ＭＳＶ，ＣＡＴ．ＭＳＶ，ＤＯＧ．ＭＳＶ、ＭＡＮ．ＭＳＶという４つのファイルが存在する。
【００７２】
このサブディレクトリにはファイル名とＦＡＴ上の記録位置が管理されている。即ち、図２９においては、ＣＡＴ．ＭＳＶというファイル名が記録されているスロットには”５”というＦＡＴ上のアドレスが管理されており、ＤＯＧ．ＭＳＶというファイル名が記録されているスロットには”１０”というＦＡＴ上のアドレスが管理されている。更に、ＭＡＮ．ＭＳＶというファイル名が記録されているスロットには”１１０”というＦＡＴ上のアドレスが管理されている。
【００７３】
クラスタ２以降が実際のデータ領域で、このエリアに本例ではＡＤＰＣＭで圧縮処理された音声データ（メッセージデータ）が記録される。
本例では、クラスタ５〜クラスタ８にＣＡＴ．ＭＳＶというファイル名のＡＤＰＣＭで圧縮処理された音声データが記録され、クラスタ１０〜クラスタ１２にＤＯＧ．ＭＳＶというファイル名の前半パートであるＤＯＧ−１がＡＤＰＣＭで圧縮処理された音声データが記録され、クラスタ１００〜クラスタ１０１にＤＯＧ．ＭＳＶというファイル名の後半パートであるＤＯＧ−２がＡＤＰＣＭで圧縮処理された音声データが記録されている。
更に、クラスタ１１０〜クラスタ１１１にＭＡＮ．ＭＳＶというファイル名のＡＤＰＣＭで圧縮処理された音声データが記録されている。
またデータ領域上のＥｍｐｒｙとかかれた領域は記録可能領域である。
【００７４】
この例において、ＤＯＧ．ＭＳＶというファイル名のファイルは、単一のファイルが２分割されて離散的に記録されている例となっている。
【００７５】
クラスタ２００以降はファイルネームを管理する領域であり、クラスタ２００にはＣＡＴ．ＭＳＶというファイルが、クラスタ２０１にはＤＯＧ．ＭＳＶというファイルが、クラスタ２０２にはＭＡＮ．ＭＳＶというファイルが記録されている。
ファイル順を並び替える場合には上記クラスタ２００以降で並び替えを行えばよい。
【００７６】
最初、このような板状メモリ１が挿入された場合には、ドライブ装置は、先頭のパーティションテーブルを参照してＦＡＴパーティション領域のはじめと終わりのアドレスを把握する。
そしてブートセクタの再生を行った後にルートディレクトリ，サブディレクトリの再生を行う。
そしてサブディレクトリに記録されている再生管理情報である、ＰＢＬＩＳＴ．ＭＳＦが記録されているスロットを検索して、ＰＢＬＩＳＴ．ＭＳＦが記録されているスロットの終端部のアドレスを参照する。
図２９の例では、ＰＢＬＩＳＴ．ＭＳＦが記録されているスロットの終端部には”２００”というアドレスが記録されているので、これに基づいてクラスタ２００を参照することになる。
【００７７】
上述したようにクラスタ２００以降はファイル名を管理するとともにファイルの再生順を管理する領域であり、この例の場合にはＣＡＴ．ＭＳＶというファイルが１番目となり、ＤＯＧ．ＭＳＶというファイルが２番目となり、ＭＡＮ．ＭＳＶというファイルが３番目となる。
【００７８】
ここでクラスタ２００以降を全て参照したら、サブディレクトリに移行して、上記ＣＡＴ．ＭＳＶ及びＤＯＧ．ＭＳＶ及びＭＡＮ．ＭＳＶという名前のファイル名と合致するスロットを参照する。
図２９においては、ＣＡＴ．ＭＳＶというファイル名が記録されたスロットの終端には”５”というアドレスが記録され、ＤＯＧ．ＭＳＶというファイルが記録されたスロットの終端には”１０”というアドレスが記録され、ＭＡＮ．ＭＳＶというファイルが記録されたスロットの終端には１１０というアドレスが記録されている。
【００７９】
ここで、ＣＡＴ．ＭＳＶのスロットにおける”５”というアドレスに基づいて、ＦＡＴ上のエントリーアドレスを検索すると”６”というクラスタアドレスがエントリーをされており、”６”というエントリーアドレスを参照すると”７”というクラスターアドレスがエントリーされており、”７”というエントリーアドレスを参照すると”８”というクラスターアドレスがエントリーされており、”８”というエントリーアドレスを参照すると”ＦＦＦ”という終端を意味するコードが記録されている。
よって、ＣＡＴ．ＭＳＶというファイルは、クラスタ５，６，７，８の領域を使用しており、データ領域のクラスタ５，６，７，８を参照することでＣＡＴ．ＭＳＶというＡＤＰＣＭデータが実際に記録されている領域をアクセスすることができる。
【００８０】
また離散的に記録されているＤＯＧ．ＭＳＶというファイルを検索する場合は以下のようになる。
ＤＯＧ・ＭＳＶというファイルが記録されたスロットの終端には”１０”というアドレスが記録されている。
ここで、上記”１０”というアドレスに基づいて、ＦＡＴ上のエントリーアドレスを検索すると”１１”というクラスタアドレスがエントリーをされており、”１１”というエントリーアドレスを参照すると”１２”というクラスターアドレスがエントリーされており、”１２”というエントリーアドレスを参照すると”１００”というクラスターアドレスがエントリーされており、”１００”というエントリーアドレスを参照すると”１０１”というクラスターアドレスがエントリーされており、”１０１”というエントリーアドレスを参照するとＦＦＦという終端を意味するコードが記録されている。
【００８１】
よって、ＤＯＧ．ＭＳＶというファイルは、クラスタ１０，１１，１２、１００，１０１というクラスタ領域を使用しており、データ領域のクラスタ１０，１１，１２を参照することでＤＯＧ．ＭＳＶというファイルの前半パートに対応するＡＤＰＣＭデータが実際に記録されている領域をアクセスすることができる。更に、データ領域のクラスタ１００，１０１を参照することでＤＯＧ．ＭＳＶというファイルの後半パートに対応するＡＤＰＣＭデータが実際に記録されている領域をアクセスすることができる。
【００８２】
また、上記ＭＡＮ．ＭＳＶのスロットにおける”１１０”というアドレスに基づいて、ＦＡＴ上のエントリーアドレスを検索すると”１１１”というクラスタアドレスがエントリーをされており、”１１１”というエントリーアドレスを参照すると”ＦＦＦ”という終端を意味するコードが記録されている。
よって、ＭＡＮ．ＭＳＶというファイルは、クラスタ１１０，１１１という領域を使用していることがわかる。
【００８３】
以上のように板状メモリ１上に記録されたデータファイルをＦＡＴを参照して再生することができ、またデータファイルが離散的に記録されていても、それらを連結してシーケンシャルに再生することが可能となる。
【００８４】
５．板状メモリのファイル構造
５−１ ディレクトリ構成
次に、板状メモリ１に記憶されるファイル構造について説明していく。
まずディレクトリ構成例を図１４に示す。
上述したように、板状メモリ１で扱うことのできる主データとしては、動画データ、静止画データ、メッセージデータ、オーディオデータ、制御用データ、電話帳データなどがあるが、このためディレクトリ構造としては、ルートディレクトリから、「ＶＯＩＣＥ」（メッセージ用ディレクトリ）、「ＤＣＩＭ」（静止画用ディレクトリ）、「ＭＯｘｘｘｘｎｎ」（動画用ディレクトリ）、「ＣＯＮＴＲＯＬ」（制御用ディレクトリ）、「ＨＩＦＩ」（オーディオ用ディレクトリ）、「ＴＥＬ」（電話帳ディレクトリ）が配される。
【００８５】
本例では、特にメッセージデータのファイルについて詳しく述べていくこととする。
ディレクトリ「ＶＯＩＣＥ」のサブディレクトリとしては、図示するように、メッセージリストファイル（ＭＳＧＬＩＳＴ．ＭＳＦ）、メッセージリストファイルのコピーとされるメッセージリストファイルＢ（ＭＳＧＬＩＳＴＢ．ＭＳＦ）、フォルダ（ＦＯＬＤＥＲ１、ＦＯＬＤＥＲ２・・・）等が形成される。
また、例えばフォルダ内には、実際のメッセージデータのファイル（ファイル名「９８１２０１００．ＭＳＶ」等）が形成される。
【００８６】
なお、もちろんこのようなディレクトリ構成は一例にすぎず、例えばフォルダ（ＦＯＬＤＥＲ１等）の下にさらにフォルダが形成される場合などもある。
このような「ＶＯＩＣＥ」ディレクトリ内の構造は、メッセージリストファイルに登録した上で機器により任意に作成するものである。
なお、メッセージリストファイルはディレクトリ構造の管理ファイルとなり、このメッセージリストファイルはバックアップのためのコピーを常に板状メモリ内に持つことで、事故による消失を防ぐようにする。
【００８７】
５−２ メッセージリストファイル
上記メッセージリストファイルの構造について図１５〜図１８を用いて説明する。
図１５はメッセージリストファイルのデータ構成を示しており、縦及び横の数値はバイト数（１６進表記）を示している。
【００８８】
図示するようにメッセージリストファイルの先頭の３２バイトはヘッダーとされる。
続いて６４バイトのフォルダエントリと各３２バイトの複数のメッセージエントリが配される。
そしてメッセージリストファイル内では、このフォルダエントリとメッセージエントリの組が以降、所要数記述されることになる。
【００８９】
このようなメッセージリストファイルでは、フォルダエントリで記述されるフォルダの並び順がフォルダの切り換え・表示順を表す。またメッセージエントリに記述されるメッセージデータの並び順が、メッセージデータの切り換え・表示・再生順番を表す。
【００９０】
メッセージリストファイル先頭の３２バイトのヘッダーの構造を図１６に示す。
図示するようにヘッダーには、４バイトのメッセージリストファイルＩＤ（ＭＳＧ−ＩＤ）、２バイトのフォーマットバージョンナンバ（ＦＭＴ−ＶＥＲ）、２バイトのメーカーコード（ＭＣｏｄｅ）、８バイトの編集日時（ＹＭＤＨＭＳＷ）、４バイトのファイルナンバ（ＦＩＬＥ−ＮＯ）、２バイトのフォルダエントリサイズ（ＦＳＩＺＥ）、２バイトのメッセージエントリサイズ（ＭＳＩＺＥ）、２バイトのフォルダエントリオフセット（ＯＦＦＳＥＴ）、２バイトのキャラクタコード（ＣＣＯＤＥ）、２バイトのリビジョンナンバ（ＲＥＶ）が記述される。
なお（Ｒ）はリザーブの意味であり、後述の図１７、図２０についても同様である。
【００９１】
まず先頭のメッセージリストファイルＩＤ（ＭＳＧ−ＩＤ）は、当該ファイルがメッセージリストファイルであることの識別をするための値とされる。例えばその値は、「0x4D53474C」( ="MSGL")という固定値とされる。
【００９２】
フォーマットバージョンナンバ（ＦＭＴ−ＶＥＲ）は、板状メモリに対するシステムにおいてメッセージデータファイル記憶のために規定されたフォーマットのバージョンナンバであり、この値により使用しているバージョンの番号が識別される。値としては、例えば上位２ビットがメジャー番号、下位２ビットがマイナー番号とされ、これにより「0x0100」 がバージョン1.0を示すなどのように設定される。
【００９３】
メーカーコード（ＭＣｏｄｅ）は、メッセージリストファイルを最後に編集した機器の、メーカー・モデルを識別するコードである。
編集日時（ＹＭＤＨＭＳＷ）は、メッセージリストファイルを最後に編集した年・月・日・時・分・秒・曜日を示す値となる。つまり最終編集日時を識別するための値という機能を持つ。値としては、バイナリとされ、年（西暦）が２バイト、その他が１バイトづつ割り当てられた計８バイトとなる。なお、曜日（日〜土）については特定の値が設定される。
【００９４】
ファイルナンバ（ＦＩＬＥ−ＮＯ）は、最後に作成したメッセージのファイル名番号を示す。これはメッセージのファイル名を作成する際に使用する為の通し番号となる。そしてファイル作成の度にインクリメントされることで、次に作成するファイル名の値を保持することになる。なお、日にちが変わっていたら０にリセットする。
【００９５】
フォルダエントリサイズ（ＦＳＩＺＥ）は、図１５に示したフォルダエントリのサイズを示す値とされる。
例えばその値は、６４という固定値とされ、フォルダエントリーのサイズが６４バイトであることを示している。
メッセージエントリサイズ（ＭＳＩＺＥ）は、図１５に示したメッセージエントリのサイズを示す値とされる。
例えばその値は、３２という固定値とされ、メッセージエントリのサイズが３２バイトであることを示している。
フォルダエントリオフセット（ＯＦＦＳＥＴ）は、最初のフォルダエントリの開始位置を、ファイルの先頭からのオフセット値で表すものである。例えば図１５に示したデータ構成においては、「０ｘ００２０」となる。
【００９６】
続いてフォルダエントリの構造を図１７に示す。
フォルダエントリには２バイトのフォルダＩＤ（ＦＬＤ−ＩＤ）、２バイトのメーカーコード（ＭＣｏｄｅ）、１２バイトのフォルダネーム（ＦＬＤ−ＮＡＭＥ）、２バイトのキャラクタコード（Ｃ−ＣＯＤＥ）、４４バイトのディスプレイネーム（ＤＩＳＰ−ＮＡＭＥ）が記述される。
【００９７】
フォルダＩＤ（ＦＬＤ−ＩＤ）は、フォルダエントリデータの先頭を識別するための値である。例えばその値は「0x4644」( ="FD")の固定値とされる。
メーカーコード（ＭＣｏｄｅ）は、このフォルダを作成した機器の、メーカー及びモデルを識別するためのコードとなる。
【００９８】
フォルダネーム（ＦＬＤ−ＮＡＭＥ）としては、ＦＡＴ上でのフォルダの名前が文字列で記録される。値は、例えばJIS X 0201で規定されたコードで、ディレクトリ名を記録する。基本的にはディレクトリ名（最大８バイト）＋”．”（ドット）＋拡張子（最大３バイト）となるが、拡張子を必要としない場合はディレクトリのみとし、”．”及び拡張子は省略することが可能とされる。また、文字列の最後には、終端記号「０ｘ００」を記述する。ただし、文字列でフォルダネーム（ＦＬＤ−ＮＡＭＥ）の記録領域がすべて満たされて、終端記号を記録するエリアが無い場合は、終端記号の記録は不要とされる。
【００９９】
キャラクタコード（Ｃ−ＣＯＤＥ）は、次のディスプレイネームを記述する文字コードを識別するコードとなる。値は、例えば「0x90」がＪＩＳＸ０２０８−１９９７（いわゆるｓｈｉｆｔ ＪＩＳ）、「0x03」がＩＳＯ８８５９−１などのように決められる。
ディスプレイネーム（ＤＩＳＰ−ＮＡＭＥ）は、機器上に表示されるフォルダ名であり、機器上に表示されるフォルダ名の文字列が記録される。値は、上記キャラクタコードで指定された文字コードで記録されることになる。また文字列の最後には終端記号「0x00」を１バイト以上記録し、終端記号「0x00」以降の値は任意とする。もしディスプレイネーム（ＤＩＳＰ−ＮＡＭＥ）の記録領域がすべてにフォルダ名を記録して、終端記号を記録するエリアが無い場合は、終端記号の記録は不要とされる。
なお、機器が自動的に作成する場合は、ＦＡＴ上のフォルダ名を記録する。
【０１００】
次に、メッセージエントリの構造を図１８に示す。
メッセージエントリには、１バイトのメッセージＩＤ（ＭＩＤ）、１バイトのプライオリティ（ＰＲＩ）、１バイトのアラームモード（ＡＬ−Ｍ）、５バイトのアラームデイト（ＡＬ−ＤＡＴＥ）、８バイトのファイルネーム（ＦＩＬＥ−ＮＡＭＥ）、６バイトの記録日時（ＲＥＣ−ＤＡＴＥ）が記述される。
【０１０１】
メッセージＩＤ（ＭＩＤ）は、メッセージエントリデータの先頭を識別するための値である。値は例えば「0x4D」 ( ="M")の固定値とされる。
プライオリティ（ＰＲＩ）は、メッセージの重要度又は優先度を表す。値は例えば「0x00」〜「0x03」の４段階とされ、値の大きい方が重要度が高いことを示す。また未使用時は「0x00」とされる。
【０１０２】
アラームモード（ＡＬ−Ｍ）は、アラーム機能のモードを表す。
各ビットは次のように定義される。
bit1、bit0・・・日時設定
bit1=0,bit0=0：指定時刻に動作する。
bit1=0,bit0=1：指定曜日に動作する。
bit1=1,bit0=0：指定月日時刻に動作する。
bit1=1,bit0=1：RESERVED
bit2・・・リザーブ（０固定）
bit3・・・残留フラグ
0：アラーム動作後bit7を０にクリアする。
1：アラーム動作後bit7を０にクリアしない。
bit4・・・リザーブ（０固定）
bit5・・・メッセージ再生フラグ
0：アラーム時刻にメッセージを再生しない。
1：アラーム時刻にメッセージを再生する。
bit6・・・アラーム音フラグ
0：アラーム時刻にアラーム音を鳴らさない。
1：アラーム時刻にアラーム音を鳴らす。
bit7・・・アラーム設定フラグ
0：アラームがセットされていない。
1：アラームがセットされている。
なお、アラーム機能を使用しないときはアラームモード（ＡＬ−Ｍ）は「0x00」とする。またbit5, bit6が重複して１のときは、アラーム音→メッセージ再生の順で動作する。
【０１０３】
アラームデイト（ＡＬ−ＤＡＴＥ）は、アラーム動作日時を示す。値は年・月・日・時・分・曜日の順で各１バイトのバイナリで記録する。年は西暦１９８０年からのオフセット値で表される。つまり「０」〜「１２７」は１９８０年〜２１０７年を表し、年を設定しない場合は「0xFF」を記入する。また「０」〜「１２７」及び「0xFF」以外の値は使用不可とされている。
【０１０４】
ファイルネーム（ＦＩＬＥ−ＮＡＭＥ）はメッセージのＦＡＴ上のファイル名が記録される。値は、拡張子を除くファイル名を、例えばJIS X 0201で規定されたコードで記録する。文字列の最後には、終端記号「０ｘ００」を記述する。もしファイルネーム（ＦＩＬＥ−ＮＡＭＥ）の記録領域がすべて文字列で満たされて、終端記号を記録するエリアが無い場合は、終端記号の記録は不要とされる。
【０１０５】
記録日時（ＲＥＣ−ＤＡＴＥ）には、メッセージが記録された日時が記録される。値は年・月・日・時・分・秒の順で１バイトのバイナリで記録する。年は西暦１９８０年からのオフセット値で表し、「０」〜「１２７」は１９８０年〜２１０７年を表す。年を使用しない場合は「0xFF」を記入する。また「０」〜「１２７」及び「0xFF」以外の値は使用されない。
【０１０６】
メッセージリストファイルは以上のように構成されるが、このようなメッセージリストファイルは、「ＶＯＩＣＥ」ディレクトリの直下に置かれる。そしてこのメッセージリストファイルは、各機器間で共通に使用される。
機器リセット時・板状メモリ挿入時等、機器側が初めて板状メモリ１を認識するときは以下の（１）〜（７）の処理を行うことになる。
【０１０７】
（１）「ＶＯＩＣＥ」ディレクトリに存在するサブディレクトリのエントリと、メッセージリストファイルの内容の整合がとれているか確認する。
（２）新たに発生したサブディレクトリをメッセージリストファイルに追加する。
（３）削除されているサブディレクトリをメッセージリストファイルから削除する。（ＰＣ上でメッセージリストファイルの編集なしに、サブディレクトリの追加・削除等が行われることがあるので、これらの作業を必要とする。）
（４）「ＶＯＩＣＥ」ディレクトリ内のサブディレクトリに存在するファイルエントリと、メッセージリストファイルの内容の整合がとれているか確認する。
（５）新たに発生したファイルをメッセージリストファイルに追加する。
（６）削除されているファイルをメッセージリストファイルから削除する。（ＰＣ上でメッセージリストファイルの編集なしに、ファイルの追加・削除等が行われることがあるので、これらの作業を必要とする。
（７）セットで使用するディレクトリが存在しない場合は、新たに作成する。
【０１０８】
このメッセージリストファイルの最大サイズは32768バイト（32×1024−32）と固定される。
最後のメッセージエントリの後ろには３２バイトの領域を「０ｘ００」で埋めるようにされる。
またエントリできるメッセージ（ＦＡＴ上のファイル）の最大数はＶＯＩＣＥディレクトリのサブディレクトリが１つの場合で１０２０個となる。
またメッセージリストファイルにおいて、フォルダエントリ（サブディレクトリ）はメッセージエントリの２つ分のエリアを必要とするので、フォルダエントリを１つ増やす度にエントリできるメッセージの最大数は２つ減ることとなる。
【０１０９】
５−３ メッセージデータファイル
続いて実際のメッセージデータが格納されるメッセージデータファイルについて説明する。
メッセージデータファイルのファイル名は、メッセージリストファイルに登録した上で機器側が任意に作成するものである。
【０１１０】
図１９はメッセージデータファイルのデータ構造を示している。
図示するようにメッセージデータファイルは、フォーマットフレーム（FORMAT FRAME）、ＴＯＣフレーム（TOC FRAME）、タイトルフレーム（TITLE FRAME）、メーカーフレーム（MAKER FRAME）、オーサーフレーム（AUTHOR FRAME）、インフォメーションフレーム（INFORMATION FRAME）、スペースフレーム（SPACE FRAME）、データフレーム（DATA FRAME）を含んで構成される。
但し、タイトルフレーム（TITLE FRAME）、メーカーフレーム（MAKER FRAME）、オーサーフレーム（AUTHOR FRAME）、インフォメーションフレーム（INFORMATION FRAME）を設けることは任意であり、基本的には、太枠で囲ったフォーマットフレーム（FORMAT FRAME）、ＴＯＣフレーム（TOC FRAME）、スペースフレーム（SPACE FRAME）、データフレーム（DATA FRAME）によってメッセージデータファイルが構成されることになる。
【０１１１】
フォーマットフレームは、当該メッセージデータファイルの基本的な管理情報となり、コーデックの種類等が示される。詳細は後述する。
ＴＯＣフレームは、当該メッセージデータファイルの各フレームの配列状態を表す管理情報となる。つまりＴＯＣフレームの記述によりメッセージデータファイルのフレーム構造が識別される。
データフレームは、実際のメッセージデータが格納される領域となる。
スペースフレームは、詳しくは後述するが、再生不可の未使用のエリアとされ、これがＴＯＣフレームの拡大の場合の予備領域や、ファイル内の再生不可エリアの設定のために機能する。
【０１１２】
このような各フレームにおいて、データフレームとスペースフレームは同一ファイル内に複数個存在する場合もある。
ただし、データフレームとスペースフレーム以外のフレームは、同一ファイル内に１つとなる。
また、フォーマットフレームは必ずファイルの先頭に配置される。そしてＴＯＣフレームはフォーマットフレームの直後に配置される。
上述した必須でないフレーム（タイトルフレーム、メーカーフレーム、オーサーフレーム、インフォメーションフレームは、ＴＯＣフレームの後にまとめて配置される。これらは後述するフレームＩＤが小さい順番に配置されることになる。
また、必須でないフレームの並びの次には、必ずスペースフレームが配置される。
【０１１３】
フォーマットフレームの構造を図２０で説明する。
フォーマットフレームは使用コーデック等を記述する必須のフレームとなり、必ずファイルの先頭にあることが要求される。
このフォーマットフレームには図示するように、８バイトのファイルＩＤ（ＦＩＬＥ−ＩＤ）、４バイトのサイズオブフォーマットフレーム（ＳＩＺＥ−ＦＭＴ）、２バイトのフォーマットバージョンナンバ（ＦＭＴ−ＶＥＲ）、１６バイトのカンパニーネーム（Ｃ−ＮＡＭＥ）、１６バイトのセットネーム（Ｓ−ＮＡＭＥ）、２バイトのセットファームウエアバージョンナンバ（ＳＥＴ−ＶＥＲ）、８バイトの記録日時（ＤＡＴＥ−ＴＩＭＥ）、２バイトのフォーマットＩＤ（ＦＭＴ−ＩＤ）、２バイトのチャンネル数（ＣＨＡＮ）、４バイトのサンプリング周波数（ＳＡＭＰ）、４バイトのアベレージバイトｐｅｒ秒（ＢＹＴＥ）、２バイトのブロックアライメント（ＡＬＩＧＮ）、２バイトのビットｐｅｒサンプル（ＢＩＴ）、２バイトのサイズオブエキストラエリア（ＥＸＴ）が記述される。なお、エキストラエリアが設けられる場合がある。
【０１１４】
ファイルＩＤ（ＦＩＬＥ−ＩＤ）は、例えばＩＳＯ８８５９−１文字コードを使用してボイスフォーマットファイル（本例でいうメッセージデータファイルフォーマット）であることを表す。値は例えば「MS_VOICE」の固定値とされる。
サイズオブフォーマットフレーム（ＳＩＺＥ−ＦＭＴ）は、当該フォーマットフレームのサイズをバイト単位で表す。後述するが、フォーマットフレームのサイズがここに記述されることで、ＴＯＣフレームへのアクセスが可能となる。
【０１１５】
フォーマットバージョンナンバ（ＦＭＴ−ＶＥＲ）は、ボイスフォーマットのバージョンを表す。上位１バイトがメジャーバージョンナンバ、下位１バイトがマイナーバージョンナンバとなる。例えば値が「0x0100」であればバージョン１．０、「0x0203」であればバージョン２．３となる。
【０１１６】
カンパニーネーム（Ｃ−ＮＡＭＥ）は、例えばＩＳＯ８８５９−１文字コードを使用してファイル作成セットの会社名を表す文字列が記入される。文字列の最後には終端記号「０ｘ００」を記述する。カンパニーネーム（Ｃ−ＮＡＭＥ）の領域のすべてが文字列で満たされた場合は、終端記号を記入は省かれる。
【０１１７】
セットネーム（Ｓ−ＮＡＭＥ）は、例えばＩＳＯ８８５９−１文字コードを使用してファイル作成セットの名前を表す文字列が記入される。文字列の最後には終端記号「０ｘ００」を記述する。セットネーム（Ｓ−ＮＡＭＥ）の領域のすべてが文字列で満たされた場合は、終端記号を記入は省かれる。
【０１１８】
セットファームウエアバージョンナンバ（ＳＥＴ−ＶＥＲ）は、機器のファームウエアのバージョンを表す。上位１バイトがメジャーバージョンナンバ、下位１バイトがマイナーバージョンナンバとなる。例えば「０ｘ０１００」はバージョン１．０、「０ｘ０２０３」はバージョン２．３となる。
【０１１９】
記録日時（ＤＡＴＥ−ＴＩＭＥ）は、値がバイナリで表され、年は西暦で２バイト、月、日、時、分、秒、曜日は各々に１バイトが用いられる。
フォーマットＩＤ（ＦＭＴ−ＩＤ）には、使用コーデックが例えば次のように示される。
0x0002：G726 ADPCM 22kHz / 3bit
0x0005：G726 ADPCM 11kHz / 3bit
0x0007：G726 ADPCM 8kHz / 4bit
0x0009：G726 ADPCM 8kHz / 2bit
【０１２０】
チャンネル数（ＣＨＡＮ）により、チャンネル数が次のように表される。
0x0001：モノラル
0x0002：ステレオ
サンプリング周波数（ＳＡＭＰ）によりサンプリング周波数が次のように表される。
0x00001F40：8kHz
0x00002B11：11.025kHz
【０１２１】
アベレージバイトｐｅｒ秒（ＢＹＴＥ）により、１秒あたりのデータがバイト数で表される。これはデータサイズから再生時間を算出する際に使用される。
ブロックアライメント（ＡＬＩＧＮ）では、切り離せないデータの一群を、バイト単位で表す。これはデータの頭出し時に使用される。例えば「０ｘ００３０」では４８バイトであり、「０ｘ００１０」では１６バイトとなる。
【０１２２】
ビットｐｅｒサンプル（ＢＩＴ）は、１サンプリングあたりのビット数を次のように表す。
0x0004：4bit
0x0003：3bit
0x0002：2bit
【０１２３】
サイズオブエキストラエリア（ＥＸＴ）には、コーデックに特有の情報を記述するエリア（エクストラデータエリア）のサイズをバイト単位で表す。つまりエクストラデータエリアが作成される場合は、そのサイズが示される。
なお、エクストラデータエリアは１６バイト単位で作成される。またエクストラデータエリアが必用無い場合はサイズオブエキストラエリア（ＥＸＴ）の値は「0x0000」とされる。
【０１２４】
以上のようなフォーマットフレームに続いて、図３１に示すようなＴＯＣフレームが配される。
ＴＯＣフレームはファイル内の各フレームの配列状態を記述するが、１フレームあたり８バイトを使用するため、ＴＯＣフレームのサイズは（８バイト×全フレーム数）となる。
またこのことは、フレームの追加や削除に応じてＴＯＣフレームのサイズは変更されることを意味する。
全フレーム数が奇数の場合、最後の未使用エリアの８バイトには「０ｘ００」が記入される。図３１の例では、アドレス「０ｘ００２８」〜「０ｘ００２Ｆ」には「０ｘ００」が記入されている。
【０１２５】
図３１に示すように、１つのフレームあたりに用いられる８バイトは次のような構成となる。
フレームＩＤ（FRAME ID） ：１Byte
リザーブ（Ｒ） ：３Byte （0x00固定値）
フレームサイズ（FRAME SIZE）：４Byte
【０１２６】
まずフレームＩＤ（FRAME ID）によりフレームの種類が次のように表される。
フォーマットフレーム ：0x01
ＴＯＣフレーム ：0x02
スペースフレーム ：0x03
データフレーム ：0x04
タイトルフレーム ：0x05
メーカーフレーム ：0x06
オーサーフレーム ：0x07
インフォメーションフレーム：0x08
【０１２７】
またフレームサイズ（FRAME SIZE）に、フレームＩＤで指定したフレームのサイズがバイト単位で記述される。
【０１２８】
ＴＯＣフレームには、このような８バイトのデータ群が、フレームの並び順に各フレームについて記述される。ＴＯＣフレーム内容の具体例は後述する。
また、このＴＯＣフレームの内容により、そのメッセージデータファイルのフレーム構造が認識されるわけである。従って当該メッセージデータファイルへのアクセスの際には、まずフォーマットフレームが確認された後、ＴＯＣフレーム内容が確認されることになる。なお、ＴＯＣフレームへのアクセスは、上記フォーマットフレームのサイズオブフォーマットフレーム（ＳＩＺＥ−ＦＭＴ）により、フォーマットフレームのサイズが記述されていることで可能となる。つまりファイル先頭からサイズオブフォーマットフレーム分のオフセットを与えたアドレスがＴＯＣフレームの先頭アドレスとなる。
【０１２９】
上述したようにＴＯＣフレームに続いては、タイトルフレーム、メーカーフレーム、オーサーフレームが設けられる場合があるが、これらは次のような情報となる。
【０１３０】
タイトルフレームは、タイトルを記録するフレームとされ、先頭の２バイトで例えば次のように記録されているタイトルのキャラクタコードタイプを表す。
0x0000：JISx0208-1997（SJIS）
0x0001：ISO8859-1
例えばタイトルフレームは１６バイトの倍数であって、タイトルの文字列の最後には終端記号「０ｘ００」が記入される。
【０１３１】
メーカーフレームはファイルを作成した機種の会社名、機種名、ファームウエアバージョンＮｏを記述する。タイトルフレームと同様に先頭の２バイトでキャラクタコードタイプを表し、続いて文字列が記入される。メーカーフレームのサイズは１６バイトの倍数であって、文字列の最後には終端記号「０ｘ００」が記入される。
【０１３２】
オーサーフレームは著作権者の名称等を文字列で表す。同じく先頭の２バイトでキャラクタコードタイプを表し、続いて文字列が記入される。オーサーフレームのサイズは１６バイトの倍数であって、文字列の最後には終端記号「０ｘ００」が記入される。
【０１３３】
インフォメーションフレームは付加情報を記録するフレームとされる。付加情報とは例えばアルバム名、アーティスト名、指揮者、さらには平均音量学習用には再生回数と言った種類があって、先頭の１バイトで情報の分類ＩＤが指定され、先頭から３バイト目と４バイト目で情報文字列の記述されているキャラクタコードタイプを表し、フレームの先頭から９バイト目から情報として文字列が記入される。インフォメーションフレームのサイズは１６バイトの倍数とされ、使用されないエリアは０ｘ００でうめられる。
【０１３４】
これらのオプションとなるフレームもしくはＴＯＣフレームの後はスペースフレームとなる。
スペースフレームは、再生不可のエリアに相当するフレームとなり、必ず設けられる。このフレームは再生処理時に読み飛ばすことが必要となる。
このフレームはＴＯＣフレームが拡大されたときの予備として用いられたり、或いは後述するデバイド処理時などに、１クラスタ内に再生不可のエリアが発生した場合に使用される。フレーム内のデータは任意であるが、特定のダミーデータを記録しても良い。スペースフレームのサイズは１６バイトの倍数とされる。
スペースフレームの扱いについては後述する。
【０１３５】
データフレームは実際のメッセージデータが格納される。
メッセージデータは、データフレームの先頭バイトのＭＳＢから、指定されたビット数で隙間無く格納される。データの格納境界はバイト境界となる。
図３２に示したような１サンプリングあたり４ビット、もしくは図３３に示したような１サンプリングあたり２ビットのデータは１バイトが格納の境界であり、図３４に示したような１サンプリングあたり３ビットのデータは３バイトが格納の境界になる。
メッセージデータの分割処理を行う場合、この格納の単位が分割するデータの単位になる。
【０１３６】
以上のような各種フレームによりメッセージデータファイルが構成されるが、メッセージデータファイルのフレーム構成例を図２１、図２２に示す。
なお、以降の説明では、オプションであるタイトルフレーム、メーカーフレーム、オーサーフレーム、インフォメーションフレームは設けられないものとする。
【０１３７】
通常にメッセージデータを録音した場合のフレーム構造は図２１（ａ）のようになり、複数のクラスタ（ブロック）に対して、図示するようにファイル先頭側からフォーマットフレーム、ＴＯＣフレーム、スペースフレーム、データフレームが形成される。
なお、ここで示している１ファイルを構成する複数のブロック（クラスタ）はＦＡＴでリンクされるブロックであり、これまでの説明から理解されるように物理的に連続するブロックとは限らない。
【０１３８】
このようなフレーム構成の情報は、ＴＯＣフレームに示されることになるが、例えばこの場合ＴＯＣフレームの内容は図２１（ｂ）のようになる。
即ち上述したように１フレームにつき８バイトの情報が、形成されているフレームの順に記述されることになる。
従って、まず最初の８バイトにフレームＩＤが「0x01」とされて、フォーマットフレームのサイズが示される。
次の８バイトにはフレームＩＤが「0x02」とされて、ＴＯＣフレーム自身のサイズが示される。フレーム数は４つのため、ＴＯＣフレームのサイズは４×８バイト＝３２バイト（＝0x00000020）となる。
さらに次の８バイトにはフレームＩＤが「0x03」とされて、スペースフレームのサイズが示される。
最後の８バイトにはフレームＩＤが「0x04」とされて、データフレームのサイズが示される。
【０１３９】
また、メッセージデータファイルでは、スペースフレームを利用することにより、一部のデータを消去部分として再生不可とすることができる。
例えば図２２（ａ）は、データフレームの途中に消去して再生させたくないメッセージ部分が存在した場合に、そこをスペースフレームとした例を示している。スペースフレームは再生時に跳ばされるため、再生されるメッセージとしては、一部が消去された状態と同等となる。
【０１４０】
例えば図２１から図２２のようにフレーム構成が変化した場合は、ＴＯＣフレームの内容は図２２（ｂ）のように更新される 。
最初の８バイトのフォーマットフレームのサイズは同様である。
次の８バイトとしてフレームＩＤが「0x02」とされて、ＴＯＣフレーム自身のサイズが示されるが、このとき、フレーム数が２つ増えて６個となったため、ＴＯＣフレームのサイズは６×８バイト＝４８バイト（＝0x00000030）となる。
次の８バイトにはフレームＩＤが「0x03」とされて、スペースフレームのサイズが示されるが、ＴＯＣフレームが１６バイト拡大される際に、スペースフレームの１６バイトが用いられたことで、スペースフレームのサイズは１６バイト減って「0x00000180」とされる。
次の８バイトには、再生させたくないメッセージが存在する新たなスペースフレームで分断された最初のデータフレームのサイズが示され、続く８バイトに新たなスペースフレームのサイズが示される。そして最後の８バイトに分断された後ろ側のデータフレームのサイズが示される。
【０１４１】
例えばこのようにＴＯＣフレームによりメッセージデータファイルのフレーム構成が管理されることになり、また、スペースフレーム、データフレームの追加などによるフレーム構成の変化や、後述するデバイド（ファイル分割）、コンバイン（ファイル連結）などの編集処理によるフレーム構成の変化に応じて、ＴＯＣフレームの内容は更新されていくことになる。
【０１４２】
ところで、スペースフレームは次のように扱われることになる。
まず新規にメッセージデータファイルを作成する際には、図２３に示すように、ＴＯＣフレームの後に１２８バイト以上６４０（＝１２８＋５１２）バイト以下のスペースフレームを配置する。
この時、データフレームの開始位置がセクタ境界になるようにスペースフレームのサイズが決められることとなる。
【０１４３】
また、詳しくは後述するが、メッセージデータファイルの分割（デバイド）処理時には、分割ポイントが含まれるクラスタにおいて、再生禁止データエリアをスペースフレームとする。
即ち図２４のように、或るクラスタの途中の位置が分割点とされた場合、分割による後半のファイルでは、メッセージデータの先頭が、そのクラスタの分割点となる。あくまでファイルの最小単位はクラスタとなるため、このようにそのクラスタ内の分割点以前のデータは、再生してはいけないデータが含まれることとなるが、その部分（図２４の斜線部分）は、スペースフレームとして再生されないようにする。
【０１４４】
また、メッセージデータファイルの分割、結合処理の結果、２つのスペースフレームがとなり合う状況になる場合もあり得る。このようにとなり合う２つのスペースフレームが存在する場合は、それを１つのスペースフレームにまとめる。つまり具体的には、１つのスペースフレームとしてＴＯＣフレームで管理されるようにする。
【０１４５】
以上説明したようにメッセージデータファイルにはメッセージデータが格納されるデータフレームのみならずフォーマットフレーム，ＴＯＣフレーム，タイトルフレーム，メーカーフレーム，オーサーフレーム，インフォメーションフレーム，スペースフレームを設けることができ、特にフォーマットフレーム，ＴＯＣフレーム、スペースフレームは必須とされるが、これは以下の理由による。
【０１４６】
板状メモリ１は図９に示したようなドライブ装置で利用されるのはもちろん、ＰＣ（パーソナルコンピュータ）等のＦＡＴシステムが使用可能な装置でも利用されることが可能とされている。
すなわち、当該メッセージデータファイルを図９に示したようなドライブ装置で記録し管理するようにした板状メモリ１をＰＣ等に装着してファイルの移動やファイル名の変更が可能である。
【０１４７】
このようにＰＣ等において板状メモリ内１に記録されたメッセージデータファイルをＦＡＴシステムを利用して移動させたり、ファイル名称の変更を行った場合、先に説明したメッセージリストファイルにて管理されているメッセージデータファイルとの整合が取れないものとなる。この問題を解決するために板状メモリ１が図９に示したようなドライブ装置に初めて認識されるときには、先に説明したようなメッセージリストファイルの内容とＶＯＩＣＥディレクトリに存在するサブディレクトリのエントリとの整合をとる処理を行うことで、例えばユーザーがメッセージデータファイルを好みのファイル名にＰＣにおいて変更したとしても図９に示したようなドライブ装置で利用可能となるのである。
【０１４８】
このときにメッセージファイルがデータフレームだけでなく他のフレームを合わせて設けていたとすると、図９に示したようなドライブ装置で記録し管理するようにした板状メモリ１をＰＣ等においてファイルの移動が行われたとしても、データフレームを再生するのに必要な情報も同時に移動されているためドライブ装置では大きな支障なく再生が可能となるためである。
【０１４９】
ところで以上の情報を使ってメッセージを再生する場合にメッセージの記録時間や残り時間を表示したりすることが望まれる。この場合たとえば図９に示したドライブ装置の表示部１０８に表示することが考えられる。
通常ＦＡＴファイルシステムにおいてはシステムとして管理するファイルサイズを例えばバイト単位で表示するなどしているが、メッセージデータファイルにおいてはＦＡＴファイルシステムが管理するファイルサイズをそのまま利用せず以下の方法で時間に換算をしている。
【０１５０】
まず、ＴＯＣフレームを用いて当該メッセージファイル内にあるデータフレームの合計サイズを算出し、フォーマットフレームに記録されているアベレージバイトｐｅｒ秒の値を用いて先に算出した合計サイズを全体の再生時間に換算する。また、残り時間を算出する場合は例えば、全体の再生時間から再生済みのメッセージの再生時間を引くことによって算出できる。
このような算出を行うことでスペースフレームやその他のフレームのデータ量による算出誤差を取り除くことが可能となる。
【０１５１】
６．デバイド編集処理
続いて本例のシステムにおける特徴的な編集動作となるデバイド編集処理について説明していく。
デバイド編集とは、１つのメッセージデータファイルを、任意の分割点を設定（例えばユーザーが操作により分割点を指示）し、その分割点の前後で２つのメッセージデータファイルに分ける処理である。
この動作を図９及び図２５〜図２８を参照しながら説明する。
図２５は、図９に示したドライブ装置のマイクロプロセッサ１０９の制御により実行される処理のフローチャートであり、また図２６は板状メモリ１上での或るメッセージデータファイルのデバイド処理状態を概念的に示すものである。さらに、図２７、図２８はデバイド処理前後でのＦＡＴ内容を示している。
【０１５２】
或る板状メモリ１がドライブ装置に装填されることで、ユーザーは表示部１０８においてその板状メモリ１に記憶されているメッセージデータファイルを確認することができる。
そしてユーザーが或るメッセージデータファイルを、その途中の或る位置で分割して２つのファイルに分けたいと思った場合は、まず表示部１０８のファイル名表示等を確認しながら操作部１１２からの操作により、その分割させたいメッセージデータファイルを選択する。
【０１５３】
ユーザーがこのようなファイル選択操作を行ったら、マイクロプロセッサ１０９は図２５のステップＦ１０１として、分割対象のメッセージデータファイルを設定する。
続いてユーザーは、その選択されたファイルのどの位置を分割点とするかの操作を行うことになる。
この分割点設定操作については多様な操作例が考えられるが、このとき例えばマイクロプロセッサ１０９は分割対象となったメッセージデータファイルを再生させ、ユーザーは再生メッセージを聞きながら、分割点としたいタイミングで分割点としてのエンター操作を行うことなどが考えられる。
また、メッセージを聞きながらタイミングを見計らって分割点を指定する操作では、分割させたいポイントと指示した分割点が微妙にずれる場合もあるため、ユーザーが分割点を微調整できるような操作機能を付加することが好ましい。
【０１５４】
ユーザーが分割点を指示する操作を行ったら、マイクロプロセッサ１０９はステップＦ１０２で分割点を決定し、実際のデバイド動作に移る。
まずステップＦ１０３では、設定された分割点が或るクラスタ（ブロック）の途中の位置であった場合は、そのクラスタのデータを未使用のクラスタにコピーして、同一内容のクラスタを２つとする。
但し後述するが、設定された分割点がクラスタ（ブロック）の境界位置であった場合は、そのクラスタのデータを複製する必要はない。
また、管理ヘッダを有するファイル先頭のクラスタのデータを未使用のクラスタにコピーして、同一内容のクラスタを２つとする。なお、ここでいう管理ヘッダとはフォーマットフレーム、ＴＯＣフレーム、スペースフレームから構成されたデータ部分のことである。
【０１５５】
続いてステップＦ１０４でＦＡＴのクラスタリンクを変更する。さらにステップＦ１０５でＦＡＴのディレクトリエントリを変更する。
これにより、上記ステップＦ１０３で新たに複製した分割点を含むクラスタ→、ヘッダを含むクラスタとを使用して、元の１つのファイルが２つのファイルに分割されるように新たなクラスタリンクが形成されることになる。具体例は後述する。
【０１５６】
次に、ステップＦ１０６で、元々のファイル先頭の管理ヘッダにおけるＴＯＣフレームを更新する。これにより、元々のファイルの分割点より前半部分に相当する新たな第１のファイルが形成される。
またステップＦ１０７で、複製されファイル先頭にリンクされた管理ヘッダを含むクラスタにおいて、その管理ヘッダを更新する。これによって元々のファイルの分割点より後半部分に相当する新たな第２のファイルが形成される。
以上の処理によりデバイド処理が完了するわけであるが、この処理によって実行されるデバイド処理例を図２６〜図２８で述べる。
【０１５７】
図２６（ａ）に示すファイルＦ１が、ユーザーがデバイド対象として選択したメッセージデータファイルであるとする。
そして仮にこのファイルＦ１は、クラスタＣＬ（２）〜ＣＬ（９）に記憶されているものとする。
このファイルＦ１のクラスタリンクを示すＦＡＴは図２７のようになっている。即ち図示していないディレクトリエントリ（図１１参照）によってファイルＦ１の先頭のクラスタがクラスタＣＬ２とされ、図２７のＦＡＴのクラスタＣＬ（２）のエントリには、「００３」と記憶されている。つまりクラスタＣＬ（２）がクラスタＣＬ（３）にリンクすることが示される。またクラスタＣＬ（３）のエントリには「００４」と記憶され、クラスタＣＬ（４）にリンクすることが示される。以降同様にリンク状態が記録され、最後のクラスタＣＬ（９）のエントリには最終クラスタであることを示す値「ＦＦＦ」が記憶される。
このようなＦＡＴによって、図２６（ａ）のファイルＦ１がクラスタＣＬ（２）〜ＣＬ（９）に格納されていることが管理される。なお、クラスタＣＬ（Ａ）以降は「０００」つまり未使用とされている状態としている。
【０１５８】
ここで、ファイルＦ１に対してユーザーが、図２６（ａ）に示す分割点ＤＰでの分割を指示したとする。
分割点ＤＰはクラスタＣＬ（５）の途中の位置である。
このため上記図２５のステップＦ１０３の処理として、クラスタＣＬ（５）が未使用のクラスタＣＬ（Ａ）にコピーされる。
また管理ヘッダを含む先頭のクラスタＣＬ（２）が未使用のクラスタＣＬ（Ｂ）にコピーされる。
【０１５９】
そして上記図２５のステップＦ１０４、Ｆ１０５でＦＡＴのクラスタリンク及びディレクトリエントリが更新され、図２６（ｂ）（ｃ）に示すようなクラスタリンクが形成される。
分割後の２つのファイルをファイルＦ１−１、Ｆ１−２とすると、まずファイルＦ１−１についてのディレクトリエントリが形成され、先頭のクラスタがクラスタＣＬ（２）と指示される。
そして図２８に示すように、ＦＡＴにおいてクラスタＣＬ（２）のエントリには「００３」、クラスタＣＬ（３）のエントリには「００４」、クラスタＣＬ（４）のエントリには「００Ａ」、クラスタＣＬ（Ａ）のエントリには「ＦＦＦ」と記憶される。
これによって、ファイルＦ１−１が、図２６（ｂ）のようにクラスタＣＬ（２）→ＣＬ（３）→ＣＬ（４）→ＣＬ（Ａ）に記憶されていると管理される状態となる。
【０１６０】
また、ファイルＦ１−２についてのディレクトリエントリが形成され、先頭のクラスタがクラスタＣＬ（Ｂ）と指示される。
そして図２８に示すように、ＦＡＴにおいてクラスタＣＬ（Ｂ）のエントリには「００５」、クラスタＣＬ（５）のエントリには「００６」、クラスタＣＬ（６）のエントリには「００７」、クラスタＣＬ（７）のエントリには「００８」、クラスタＣＬ（８）のエントリには「００９」、クラスタＣＬ（９）のエントリには「ＦＦＦ」と記憶される。
これによって、ファイルＦ１−２が、図２６（ｃ）のようにクラスタＣＬ（Ｂ）→ＣＬ（５）→ＣＬ（６）→ＣＬ（７）→ＣＬ（８）→ＣＬ（９）に記憶されていると管理される状態となる。
【０１６１】
続いてステップＦ１０６ではファイルＦ１−１の管理ヘッダ、即ちクラスタＣＬ（２）の内容が更新される。
具体的には、ＴＯＣフレームに記述されているデータフレームのサイズが更新されることになる。
図２６（ｂ）からわかるように、この場合、最後のクラスタＣＬ（Ａ）は分割点ＤＰのデータを含むクラスタとなり、このファイルＦ１−１にとっては、クラスタＣＬ（Ａ）の分割点ＤＰ相当位置より後ろのメッセージデータは不要なデータとなる。
そこで、データフレームが一点鎖線の矢印で示す範囲となるように（つまり斜線部分を除外するように）、データフレームのサイズが更新されることになる。
これによって、ファイルＦ１−１では、クラスタＣＬ（Ａ）の斜線部分は無効領域とされ、従って、ファイルＦ１−１は、もとのファイルＦ１の分割点ＤＰより前のデータが再生対象とされたファイルとなる。
【０１６２】
次に上記図２５のステップＦ１０７では、ファイルＦ１−２の管理ヘッダ、即ちクラスタＣＬ（Ｂ）の内容が更新される。
具体的には、ＴＯＣフレームに記述されているデータフレームのサイズが更新されるとともに、スペースフレームの設定が更新されることになる。
図２６（ｃ）からわかるように、２番目のクラスタＣＬ（５）は分割点ＤＰのデータを含むクラスタとなる。このファイルＦ１−２にとっては、クラスタＣＬ（５）内での分割点ＤＰより前のメッセージデータは不要なデータとなる。
また、クラスタＣＬ（Ｂ）はクラスタＣＬ（２）をコピーしたものであるが、クラスタＣＬ（２）においてスペースフレームの後ろに存在したデータフレームのメッセージデータも、ファイルＦ１−２にとっては不要なデータとなる。
そこで、元々のクラスタＣＬ（２）に存在し、クラスタＣＬ（Ｂ）にコピーされたスペースフレームが、クラスタＣＬ（５）の分割点ＤＰまで拡大されるように、ＴＯＣフレームでスペースフレームのサイズを更新する。
またＴＯＣフレームでのデータフレームのサイズも更新されることになる。
これによって、ファイルＦ１−２では、クラスタＣＬ（Ｂ）からＣＬ（５）にかけてスペースフレームが拡大され、その部分が再生禁止領域となる。従って、ファイルＦ１−２は、もとのファイルＦ１の分割点ＤＰより後ろのデータが再生対象とされたファイルとなる。
【０１６３】
このような分割処理を、上述した図２９のメモリマップ及び図３０でみると以下のようになる。
図３０は図２９に示した３つのファイルのうちからＣＡＴ．ＭＳＶを分割処理した際を例に挙げて説明するためのメモリマップである。
【０１６４】
いま図２９のようにクラスタ５〜クラスタ８に記録されているデータファイルであるＣＡＴ．ＭＳＶをクラスタ６とクラスタ７を境界、つまり分割点として分割することを指示する操作がユーザによって行われたとする。
この操作に応じて、上述のデバイド処理が行われ、図３０に示すようにＣＡＴ１．ＭＳＶとＣＡＴ２．ＭＳＶという２つのファイルが作成されたとする。
【０１６５】
このように２つのファイル（ＣＡＴ１．ＭＳＶとＣＡＴ２．ＭＳＶ）が形成されるまでの経過は例えば次のようになる。
まず、図２９の状態でクラスタ２０１及び２０２に記録されているＤＯＧ．ＭＳＶとＭＡＮ．ＭＳＶをクラスタ２０２及び２０３に移動する。
更に、クラスタ２００のファイルネームとして、例えばユーザが入力したＣＡＴ１に識別子ＭＳＶを付与したＣＡＴ１．ＭＳＶを記録するとともに、クラスタ２０１には、例えばユーザが入力したＣＡＴ２に識別子ＭＳＶを付与したＣＡＴ２．ＭＳＶを記録する。
【０１６６】
次にサブディレクトリに記録されていたＣＡＴ．ＭＳＶをＣＡＴ１．ＭＳＶに書き換えるとともに未使用スロットにＣＡＴ２．ＭＳＶを追加する。
上記ＣＡＴ２．ＭＳＶが記録されているスロットには分割されたＣＡＴ２．ＭＳＶが記録されているクラスタ番号”７”が終端に記録される。
次にサブディレクトリーのＣＡＴ１．ＭＳＶスロットが指し示すＦＡＴ上の終点がクラスタ６になるようにＦＡＴのエントリーアドレスを”ＦＦＦ”に書き換える。
以上により、図３０の状態となり、これが分割処理時のＦＡＴ上での編集手順となる。
【０１６７】
以上の説明から理解されるように、本例ではデバイド処理に際して、分割位置を含むクラスタと管理ヘッダを含むクラスタが複製され、また分割後の各ファイルの管理ヘッダ（ＴＯＣフレーム）の一部が更新され、データフレーム、スペースフレームのサイズが変更されるのみで、分割点から前後の２つのメッセージデータファイルに分割されることになる。
これは、メッセージデータファイルを分割するという編集のために必要となるデータの複製や書換が最小限となっていることを意味する。
そしてこれによって編集処理が効率化され、編集処理のためのアクセスも最小限となるため、処理時間や消費電力を最小限とできる。
【０１６８】
なお、分割点ＤＰがクラスタの境界とされた場合は、分割点を含むクラスタの複製は不要となる。
例えば上記図２６（ａ）のファイルＦ１のクラスタＣＬ（５）とＣＬ（６）の境界が分割点となった場合は、分割後のファイルＦ１−１は、クラスタＣＬ（２）〜ＣＬ（５）により形成され、ファイルＦ１−２は、クラスタＣＬ（２）から複製された或るクラスタＣＬ（Ｘ）からクラスタＣＬ（６）・・・ＣＬ（９）により形成されることになる。
従ってその様な場合は、分割処理のための複製は管理ヘッダを含むクラスタのみとなり、処理はより簡易かつ短時間で実現できるものとなる。
【０１６９】
また、図２６の例では、クラスタＣＬ（５）とそれをコピーしたクラスタＣＬ（Ａ）について、クラスタＣＬ（５）をファイルＦ１−１側に組み込み、クラスタＣＬ（Ａ）をファイルＦ１−２側に組み込んだが、クラスタＣＬ（Ａ）をファイルＦ１−１側に組み込み、クラスタＣＬ（５）をファイルＦ１−２側に組み込むようにしてもよい。
管理ヘッダを含むクラスタについても同様である。
【０１７０】
ところで、元々のクラスタＣＬ（５）のデータが記憶されていて新たにスペースフレームに組み込んだ領域、つまりファイルＦ１−２のクラスタＣＬ（５）の前半部分では、その音声データをそのまま残しておくようにしてもよいし、例えばゼロデータなどのダミーデータを充填しても良い。或いは何らかの付加データの記憶領域として利用できるようにしても良い。
これは、スペースフレームとはしないで無効領域とされたエリア、つまりファイルＦ１−１のクラスタＣＬ（Ａ）の後半の斜線部分についても同様である。
【０１７１】
スペースフレームとした部分のデータの扱いはこのように各種考えられるが、例えばメッセージデータをそのまま残しておくとすると、分割された２つのファイルを後に元の１つのファイルに戻すような場合に、そのクラスタがそのまま使用できることになるため、処理が効率的となる。
さらに、分割処理の結果２つのスペースフレームが隣り合う状況になった場合、それらを１つのスペースフレームにまとめる処理を行っても良い。
【０１７２】
また分割処理の手順や処理内容としては、上記例に限らず各種考えられる。
例えば上記例では分割点を含むクラスタを複製した後、分割後の各ファイルにおいてＴＯＣフレームの更新により一部をスペースフレームもしくは無効部分としたが、例えば分割点より前のメッセージデータにダミーデータを加えて１クラスタ分のデータを生成して未使用クラスタに記憶させ、さらに分割点より後ろのメッセージデータにダミーデータを加えて１クラスタ分のデータを生成して未使用クラスタに記憶させ、これらのクラスタを分割後の各ファイルを構成するクラスタリンクに組み込むという手法も考えられる。
この場合は、その各クラスタのダミーデータ部分が、上記例と同様にスペースフレーム又は無効部分として管理されればよいことはいうまでもない。
【０１７３】
以上、実施の形態としてのシステム構成及びデバイド編集動作について述べてきたが、本発明はこれらの構成及び動作に限定されるものではない。
特に実施の形態においては板状メモリを用いたシステムにおいて主データがメッセージデータであるメッセージデータファイルのデバイド処理を例にあげたが、上述したように板状メモリ１を用いたシステムではメッセージデータファイル以外に、オーディオデータファイル、動画データファイルなども扱うことができる。
そしてこのオーディオデータファイル、動画データファイルについても、上記同様にデバイド処理が実行されることで、デバイド編集を効率化できる。
【０１７４】
また、本発明のシステムとしては、図１のような板状メモリに限定されるものではなく、他の外形形状とされた固体メモリ媒体（メモリチップ、メモリカード、メモリモジュール等）でも構わない。
また、これまで説明したファイルシステムのフォーマットも、例えば実際に応じてその細部の規定などは変更されて構わない。
更には、フラッシュメモリ容量のバリエーションも図８に示したものに限定されるものではない。もちろん、本発明の記録媒体のメモリ素子はフラッシュメモリに限られず、他の種のメモリ素子でもよい。
【０１７５】
【発明の効果】
以上の説明からわかるように、本発明の記録媒体は、記録されるデータファイルは、ファイル毎にそのデータファイルにかかる管理データ（ファイル内管理データ）が記憶され、しかもその管理データは少なくとも主データの位置及び再生対象とならない無効データ部分を管理できるものとされている。
また、１又は複数のデータファイルを管理するデータファイル管理情報により、各データファイルが管理される。
つまり、階層的な管理データが形成されていることで、データファイルの編集の際に、管理データの更新を最小限とすることができる。
【０１７６】
また、本発明の編集装置、編集方法によれば、データファイルの分割編集の際には、必要に応じて分割位置を含む記録データブロック（例えば上述したクラスタ／ブロック）が複製される。また分割対象となったデータファイルの管理データが書き換えられることで分割後の第１のデータファイルが形成される。さらに、分割による第２のデータファイルのための管理データが生成され第２のデータファイルの先頭に付加されるとともにその第２のデータファイル内に分割位置より前の主データ部分が存在する場合はそれが再生対象外の部分として扱われるようにすることで第２のデータファイルが形成される。さらに分割位置を含む記録データブロックは、複製され、それぞれ分割して生成される２つのデータファイルの構成部分となるように、記録データブロックの結合状態が編集される。これらのことにより、データファイルを分割するという編集のために必要となるデータ移動・複製・書換を最小限とすることができるという効果がある。
そしてまたそれによって編集のための処理時間や消費電力を最小限とできるという利点も有る。
【図面の簡単な説明】
【図１】本発明の実施の形態の板状メモリの外形形状を示す平面図、正面図、側面図、底面図である。
【図２】実施の形態のファイルシステム処理階層の説明図である。
【図３】実施の形態の板状メモリの物理的データ構造の説明図である。
【図４】実施の形態の板状メモリの管理フラグ内容の説明図である。
【図５】実施の形態の板状メモリにおけるデータ更新処理と物理アドレス及び論理アドレスの概念の説明図である。
【図６】実施の形態の論理−物理アドレス変換テーブルの管理形態の説明図である。
【図７】実施の形態の論理−物理アドレス変換テーブルの構造の説明図である。
【図８】実施の形態の板状メモリのフラッシュメモリ容量／ブロック数／１ブロックの容量／１ページの容量／論理−物理アドレス変換テーブルのサイズの関係の説明図である。
【図９】実施の形態のドライブ装置のブロック図である。
【図１０】ＦＡＴ構造の説明図である。
【図１１】ＦＡＴによるクラスタ管理形態の説明図である。
【図１２】ディレクトリの内容の説明図である。
【図１３】サブディレクトリ及びファイルの格納形態の説明図である。
【図１４】実施の形態の板状メモリのディレクトリ構成の説明図である。
【図１５】実施の形態のメッセージリストファイルの説明図である。
【図１６】実施の形態のメッセージリストファイルのヘッダの説明図である。
【図１７】実施の形態のメッセージリストファイルのフォルダエントリの説明図である。
【図１８】実施の形態のメッセージリストファイルのメッセージエントリの説明図である。
【図１９】実施の形態のメッセージデータファイルの構造の説明図である。
【図２０】実施の形態のメッセージデータファイルのフォーマットフレームの説明図である。
【図２１】実施の形態のメッセージデータファイルのフレーム構成例の説明図である。
【図２２】実施の形態のメッセージデータファイルのフレーム構成例の説明図である。
【図２３】実施の形態のメッセージデータファイルのスペースフレームの扱いの説明図である。
【図２４】実施の形態のメッセージデータファイルのスペースフレームの扱いの説明図である。
【図２５】実施の形態のデバイド処理のフローチャートである。
【図２６】実施の形態のデバイド処理の説明図である。
【図２７】実施の形態のデバイド処理前のＦＡＴの説明図である。
【図２８】実施の形態のデバイド処理後のＦＡＴの説明図である。
【図２９】実施の形態のＦＡＴ管理構造の説明図である。
【図３０】実施の形態のデバイド処理後のＦＡＴ管理構造の説明図である。
【図３１】実施の形態のＴＯＣフレームの構成の説明図である。
【図３２】実施の形態のデータフレームのデータ格納境界の説明図である。
【図３３】実施の形態のデータフレームのデータ格納境界の説明図である。
【図３４】実施の形態のデータフレームのデータ格納境界の説明図である。
【符号の説明】
１ 板状メモリ、２ 端子部、４ 凹凸部、５ スライドスイッチ、１００ セット本体、１０３ マイクロフォン、１０４ マイクアンプ、１０５ スピーカアンプ、１０６ スピーカ、１０７ 表示ドライバ、１０８ 表示部、１０９マイクロプロセッサ、１１２ 操作部、１２０ 着脱機構
Claims (19)
- 記録媒体に記録された、固定長の記録データブロックを１または複数連結した主データと、上記主データに付加されて上記主データの上記記録媒体におけるアドレスとして示される記録位置及び再生されない無効データの位置を上記アドレスの更新により管理可能とする管理データとから構成されるデータファイルを、分割する編集装置として、
上記データファイルを分割する分割位置を指定して、上記分割位置のアドレスにおいて前後となる第１のデータファイルと第２のデータファイルに分割することを指示できる操作手段と、
上記操作手段の分割指示に応じて、上記管理データにおける主データの記録位置及び無効データの位置を更新して第１の管理データとすることで、該第１の管理データで管理される上記第１のデータファイルが生成される第１データファイル生成手段と、
上記操作手段の分割指示に応じて、主データの記録位置及び無効データの位置を管理する第２の管理データを生成し、上記分割位置より後のデータファイル部分に付加することで、上記第２の管理データで管理される上記第２のデータファイルが生成される第２データファイル生成手段と、
を備え、
上記第１の管理データが管理する無効データは、少なくとも上記分割位置を含む上記記録データブロックのうちの、上記分割位置より後ろに位置されていた主データ部分であり、
上記第２の管理データが管理する無効データは、少なくとも上記分割位置を含む上記記録データブロックのうちの、上記分割位置より前に位置されていた主データである
編集装置。 - 上記操作手段によって、上記データファイルが分割される記録データブロックが指定される請求項１に記載の編集装置。
- 上記操作手段によって指示された分割位置を含む記録データブロックを上記記録媒体の空きエリアに複製する複製手段と、
上記複製手段の複製により２つとされた記録データブロックの一方が、上記第１のデータファイルの構成部分となり、上記複製手段の複製により２つとされた記録データブロックの他方が、上記第２のデータファイルの構成部分となるように記録データブロックの結合状態を編集する結合編集手段と、
をさらに備えた請求項１に記載の編集装置。 - 上記無効データとして管理される部分に、ダミーデータが記録される請求項１に記載の編集装置。
- 上記操作手段によって指示された分割位置を含む記録データブロックを管理している上記管理データを複製する管理データ複製手段をさらに備え、
上記第２データファイル生成手段は、上記管理データ複製手段により複製された管理データを更新して上記第２の管理データを生成する請求項１に記載の編集装置。 - 上記操作手段によって指示された分割位置に基づく分割処理において、上記無効データの位置として管理される複数の領域が物理的に隣接した場合は、その複数の領域が、無効データが記録された１つの領域として管理されるように、上記第１の管理データ又は上記第２の管理データを更新する無効データ領域編集手段をさらに備えた請求項１に記載の編集装置。
- 固定長の記録データブロックを１または複数連結した主データと、上記主データに付加されて上記主データの記録位置及び再生されない無効データの位置を管理可能とする管理データとから構成されるデータファイルが記録された記録媒体を着脱可能とする着脱手段をさらに備え、
上記操作手段によって指示された分割位置に基づく分割処理により形成される上記第１のデータファイルと上記第２のデータファイルは、上記記録媒体上に作られる請求項１に記載の編集装置。 - 上記記録媒体は不揮発性メモリである請求項７に記載の編集装置。
- 上記主データは、オーディオデータである請求項１に記載の編集装置。
- 上記主データは、動画データである請求項１に記載の編集装置。
- 記録媒体に記録された、固定長の記録データブロックを１または複数連結した主データと、上記主データに付加されて上記主データの上記記録媒体におけるアドレスとして示される記録位置及び再生されない無効データの位置を上記アドレスの更新により管理可能とする管理データとから構成されるデータファイルを分割する編集装置における編集方法として、
上記データファイルを、第１のデータファイルと第２のデータファイルに分割するための分割位置を設定する設定手順と、
上記設定手順で設定された分割位置に基づいて、上記管理データにおける主データの記録位置及び無効データの位置を更新して第１の管理データとすることで、該第１の管理データで管理される上記第１のデータファイルが生成されるようにする第１データファイル生成手順と、
上記設定手順で設定された分割位置に基づいて、主データの記録位置及び無効データの位置を管理する第２の管理データを生成し、上記分割位置よりアドレスにおいて後のデータファイル部分に付加することで、上記第２の管理データで管理される上記第２のデータファイルが生成されるようにする第２データファイル生成手順と、
が行われ、
上記第１の管理データが管理する無効データは、少なくとも上記分割位置を含む上記記録データブロックのうちの、上記分割位置よりアドレスにおいて後ろに位置されていた主データ部分であり、
上記第２の管理データが管理する無効データは、少なくとも上記分割位置を含む上記記録データブロックのうちの、上記分割位置よりアドレスにおいて前に位置されていた主データである
編集方法。 - 上記設定手順において、上記分割位置が含まれる記録データブロックが設定される請求項１１に記載の編集方法。
- 上記設定手順において設定された分割位置を含む記録データブロックを上記記録媒体の空きエリアに複製する複製手順と、
上記複製手順での複製により２つとされた記録データブロックの一方が、上記第１のデータファイルの構成部分となり、上記複製手順での複製により２つとされた記録データブロックの他方が、上記第２のデータファイルの構成部分となるように記録データブロックの結合状態を編集する結合編集手順と、
がさらに行われる請求項１１に記載の編集方法。 - 上記無効データとして管理される部分にダミーデータが記録されるダミーデータ記録手順がさらに行われる請求項１１に記載の編集方法。
- 上記設定手順によって設定された分割位置を含む記録データブロックを管理している上記管理データを複製する管理データ複製手順をさらに備え、
上記第２データファイル生成手順では、上記管理データ複製手順において複製された管理データを更新して上記第２の管理データを生成する請求項１１に記載の編集方法。 - 上記設定手順によって設定された分割位置に基づく分割処理において、上記無効データの位置として管理される複数の領域が物理的に隣接した場合は、その複数の領域が、無効データが記録された１つの領域として管理されるように、上記第１の管理データ又は上記第２の管理データを更新する無効データ領域編集手順がさらに請求項１２に記載の編集方法。
- 着脱可能な記録媒体上に存在する、固定長の記録データブロックを１または複数連結した主データと上記主データに付加されて上記主データの記録位置及び再生されない無効データの位置を管理可能とする管理データとから構成されるデータファイルについて、上記設定手順によって設定された分割位置に基づく分割処理がさらに行われる請求項１２に記載の編集方法。
- 上記主データは、オーディオデータである請求項１１に記載の編集方法。
- 上記主データは、動画データである請求項１１に記載の編集方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000032665A JP4474716B2 (ja) | 1999-02-12 | 2000-02-03 | 編集装置、編集方法 |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP3500099 | 1999-02-12 | ||
| JP11-35000 | 1999-02-12 | ||
| JP2000032665A JP4474716B2 (ja) | 1999-02-12 | 2000-02-03 | 編集装置、編集方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000298611A JP2000298611A (ja) | 2000-10-24 |
| JP4474716B2 true JP4474716B2 (ja) | 2010-06-09 |
Family
ID=26373882
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000032665A Expired - Lifetime JP4474716B2 (ja) | 1999-02-12 | 2000-02-03 | 編集装置、編集方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4474716B2 (ja) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2003296177A (ja) | 2002-04-03 | 2003-10-17 | Sony Corp | 記録装置および方法、記録媒体、並びにプログラム |
| JP4238514B2 (ja) * | 2002-04-15 | 2009-03-18 | ソニー株式会社 | データ記憶装置 |
| JP2011048437A (ja) * | 2009-08-25 | 2011-03-10 | Alpine Electronics Inc | 文字列検索システム、文字列データベースのデータ構造及びナビゲーション装置 |
| JP6071399B2 (ja) * | 2012-10-05 | 2017-02-01 | キヤノン株式会社 | 画像処理装置及び画像処理装置の制御方法 |
| JP6142669B2 (ja) | 2013-05-22 | 2017-06-07 | 株式会社ソシオネクスト | データ編集プログラム、データ編集装置、データ編集方法 |
-
2000
- 2000-02-03 JP JP2000032665A patent/JP4474716B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP2000298611A (ja) | 2000-10-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR100628543B1 (ko) | 기록매체 | |
| JP4085478B2 (ja) | 記憶媒体及び電子機器システム | |
| KR100704998B1 (ko) | 기록방법, 관리방법 및 기록장치 | |
| US6434103B1 (en) | Recording medium, recording apparatus, recording method, editing apparatus and editing method | |
| TW508592B (en) | Recording medium, recording apparatus and recording/reproducing system | |
| JP4076078B2 (ja) | ファイル管理方法 | |
| US6662269B1 (en) | Data rewriting apparatus, control method, and recording medium | |
| JP2001325128A (ja) | ファイル管理方法、記録又は再生装置 | |
| JP4474716B2 (ja) | 編集装置、編集方法 | |
| JP2000057037A (ja) | 記録装置および記録方法、再生装置および再生方法、並びに記録媒体 | |
| JP4441968B2 (ja) | 記録方法、管理方法、及び記録装置 | |
| JP2001325134A (ja) | ディレクトリ設定方法、記録装置 | |
| JP4403338B2 (ja) | 情報処理装置、情報処理方法 | |
| JP2002007204A (ja) | 情報処理装置、情報処理方法 | |
| JP2001101056A (ja) | 編集装置 | |
| TWI235361B (en) | Information recording medium, information recording method, information recording apparatus, information reproduction method, and information reproduction apparatus | |
| JP2001331328A (ja) | 情報処理装置、情報処理方法 | |
| JP2008090870A (ja) | 記憶媒体及び電子機器システム | |
| JP2001331280A (ja) | 情報処理装置、情報処理方法 | |
| JP2002007179A (ja) | 情報処理装置、ファイルシステム | |
| JP2008077450A (ja) | ファイル管理装置、ファイル管理方法及びプログラム | |
| JPH08190779A (ja) | データ記録再生装置及びデータ再生装置 | |
| KR100390486B1 (ko) | 디지털 데이터 재생장치의 파일 이름 저장 방법 | |
| KR20010086849A (ko) | 디지털 데이터 녹음/재생 장치 및 이 장치의 데이터 복구방법 | |
| JP2006107685A (ja) | 光ディスク書き込み方式、光ディスク読み取り方式及びそれらのプログラム、並びに該プログラムを記録した記録媒体 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20061218 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090929 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20091130 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20100216 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20100301 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130319 Year of fee payment: 3 |