JP4284797B2 - 記録装置 - Google Patents
記録装置 Download PDFInfo
- Publication number
- JP4284797B2 JP4284797B2 JP34886899A JP34886899A JP4284797B2 JP 4284797 B2 JP4284797 B2 JP 4284797B2 JP 34886899 A JP34886899 A JP 34886899A JP 34886899 A JP34886899 A JP 34886899A JP 4284797 B2 JP4284797 B2 JP 4284797B2
- Authority
- JP
- Japan
- Prior art keywords
- recording
- data
- block
- file
- memory card
- 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 - Fee Related
Links
Images
Landscapes
- Memory System (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、例えばオーディオデータやビデオデータなどのプログラム（コンテンツ）を記録媒体に記録する記録装置に関するものである。
【０００２】
【従来の技術】
ＥＥＰＲＯＭ(Electrically Erasable Programmable ROM)と呼ばれる電気的に書き換え可能な不揮発性メモリは、１ビットを２個のトランジスタで構成するために、１ビット当たりの占有面積が大きく、集積度を高くするのに限界があった。この問題を解決するために、全ビット一括消去方式により１ビットを１トランジスタで実現することが可能なフラッシュメモリが開発された。フラッシュメモリは、磁気ディスク、光ディスク等の記録媒体に代わりうるものとして期待されている。
【０００３】
フラッシュメモリを機器に対して着脱自在に構成したメモリカードも知られている。このメモリカードを使用すれば、従来のＣＤ（コンパクトディスク）、ＭＤ（ミニディスク）等のディスク状媒体に換えてメモリカードを使用するディジタルオーディオデータ等の記録／再生装置を実現することができる。
【０００４】
そして、フラッシュメモリを用いたメモリカードを記録媒体としてオーディオデータやビデオデータ等のプログラム（コンテンツともいう）を記録再生するシステムでは、例えば従来、パーソナルコンピュータで使用されるファイル管理システムである、ＦＡＴ(File Allocation Table) ファイルシステムを採用することや、ファイル管理情報の工夫により、容易にコンテンツの編集が可能となる。
例えば１つの楽曲としてのオーディオデータが１つのコンテンツとして記録されると仮定すると、そのコンテンツを分割して２つのコンテンツ、すなわち２つの曲にするデバイド編集や、逆に２つのコンテンツを結合させて１つのコンテンツ、すなわち１つの曲にするコンバイン編集なども可能である。
これにより、ユーザーサイドでは、メモリカードに記録したコンテンツを任意に加工して楽しむといったことも可能となる。
【０００５】
【発明が解決しようとする課題】
ところで、従来よりオーディオデータとしてのコンテンツを編集可能なシステムとしてミニディスクシステムが知られている。このミニディスクシステムでは、コンテンツを管理する管理情報である、いわゆるＴＯＣデータを書き換えることで、コンテンツの編集を実現してきた。
そしてミニディスク（光磁気ディスク）上では、コンテンツを記録するプログラム領域と、ＴＯＣデータを記録する管理情報領域がそれぞれ別に、所定の容量で設定されており、ＴＯＣデータの情報量がプログラム（コンテンツ）の記録容量に影響を与えることはなかった。また、編集を何度繰り返したとしても、それは全て管理情報領域内でのＴＯＣデータの書換が行われるのみであるため、これもプログラム（コンテンツ）の記録容量に影響を与えることはない。
【０００６】
ところが、フラッシュメモリの場合は、同一位置に書込を繰り返すと、著しくメモリ寿命が縮まるという性質があることから、絶えず書き込み位置を移動させることが好適であるとされている。
このため、メモリカードにおいてコンテンツを記録する領域と、コンテンツを管理する管理情報を記録する領域とを特定せず、例えば管理情報を更新する場合は、新たな領域に新たな管理情報を書き込み、旧管理情報を消去するような記録動作を行っている。
これは、コンテンツの記録動作や編集動作に伴って管理情報の更新が必要とされる場合は、からなず管理情報を新たに書き込めるだけの領域が確保されていることが必要となることを意味する。換言すれば、所定以上の空き容量がなければ、管理情報の更新ができないものとなり、これにより記録動作が完結せず、また編集ができない状態となる。
またブロックといわれる所定単位でデータの管理等を行うメモリカードでは、例えばデバイド編集などの際に新たに１ブロック分が必要となることがある。これも、所定以上の空き容量がなければ、コンテンツの編集ができないということを意味する。
【０００７】
つまりフラッシュメモリを用いたメモリカードを記録媒体とする場合は、コンテンツの記録によりメモリカードの残りの記録可能容量が所定未満となってしまうと、記録後に必要な管理情報の更新や、記録されているコンテンツについての編集が実行できなくなるという不都合がある。
【０００８】
【課題を解決するための手段】
本発明はこのような問題に鑑みて、プログラム（コンテンツ）の記録に応じた管理情報の更新や、編集処理が適切に実行できるようにすることを目的とする。
【０００９】
このために本発明の記録装置は、コンテンツとしてのプログラムを入力する入力手段と、所定数の固定長とされたブロック単位で記録が行われる記録媒体に対して、前記入力手段に入力された前記プログラムを前記ブロック単位にブロック化して記録していくプログラム記録手段と、前記ブロック単位に記録されたプログラムを管理する、プログラム数、各プログラムのデータサイズを記録した管理情報を記録媒体に記録し、又は更新する管理情報記録手段と、前記管理情報記録手段による管理情報の記録又は更新、及び／又は記録されたプログラムの編集に用いられるブロックとして所要量の余りブロック量を設定するとともに、前記プログラム記録手段による記録動作により、記録媒体上で、前記余りブロック量を除いた記録可能なブロック残量がゼロとなったら、前記プログラム記録手段による記録動作を終了させる制御手段と、を備え、前記制御手段は、前記プログラム記録手段による記録動作の際に、記録媒体上に記録されているプログラムの平均データサイズと、記録媒体の容量に応じて、前記余りブロック量を設定するようにする。
つまり、管理情報の記録又は更新や、記録されたプログラムの編集に用いられるブロックとして、余りブロック量を設定しておき、プログラムの記録動作は、余りブロック量として設定された容量を残した状態で終了されるようにする。
【００１０】
【発明の実施の形態】
以下、本発明の実施の形態について説明していく。この実施の形態では、記録媒体の例としての不揮発性メモリ（フラッシュメモリ）を搭載するメモリカードを挙げ、記録装置の例として、メモリカードに対して記録再生動作を行うことのできるレコーダを挙げる。
また、実施の形態において扱うことのできるプログラム（コンテンツ）としてのデータは、オーディオデータ、動画データ、静止画データ等のビデオデータ、テキストデータ、プログラムデータ等、各種のものがあるが、説明上は楽曲等のオーディオデータを扱うものとする。なお、主たるコンテンツとしてオーディオデータを扱う場合でも、ディジタルオーディオ信号以外の画像、文字等を付加情報として記録／再生可能となる。
説明は次の順序で行う。
１．レコーダの構成
２．メモリカードの構成
３．ファイルシステム
３−１ 処理構造及びデータ構造
３−２ ディレクトリ構成
３−３ 管理構造及び編集方式
３−４ 再生管理ファイル
３−５ データファイル
４．記録処理
４−１ 処理例１
４−２ 処理例２
４−３ 処理例３
【００１１】
１．レコーダの構成
図１により、オーディオデータ等のプログラム（コンテンツ）をメモリカードに対して記録再生することのできるメモリカード記録再生装置（以下、レコーダ１）の構成を説明する。
このレコーダ１は、記録媒体として、着脱自在のメモリカードを使用する。そしてこのレコーダ１は、単体のオーディオ装置として構成してもよいし、パーソナルコンピュータ、或いはオーディオ／ビジュアル機器に内蔵された装置部として構成してもよい。
単体のオーディオ装置とする場合は、例えばレコーダ１は据置型或いは携帯用小型の記録再生装置とされる。その場合、アンプ装置、スピーカ、ＣＤプレーヤ、ＭＤレコーダ、チューナ等と共にオーディオシステムを構成することもできる。
また他の機器に内蔵される形態としては、例えばパーソナルコンピュータにおいてＣＤ−ＲＯＭドライブやフロッピーディスクドライブと同様の位置づけで、メモリカードドライブとして採用することができる。
さらにレコーダ１をビデオカメラやゲーム機器に内蔵して、メモリカードをビデオデータやオーディオデータの記録媒体として用いることも可能である。
またレコーダ１は、上記の単体型、内蔵型に関わらず、衛星を使用したデータ通信、ディジタル放送、インターネット等を経由して配信されるディジタルオーディオ信号等を記録するレコーダとしても適用できる。
【００１２】
図１はこれら各種の態様で実現できるメモリカード記録再生装置としての一般的な構成を示すものである。
レコーダ１は、それぞれ１チップＩＣで構成されたオーディオエンコーダ／デコーダＩＣ１０、セキュリティＩＣ２０、ＤＳＰ(Digital Signal Processor)３０を有する。そしてレコーダ１に対して着脱自在のメモリカード４０が記録媒体として用いられる。
メモリカード４０は、フラッシュメモリ（不揮発性メモリ）、メモリコントロールブロック、ＤＥＳ(Data Encryption Standard)の暗号化回路を含むセキュリティブロックが１チップ上にＩＣ化されたものである。
なお本例では、ＤＳＰ３０を使用しているが、ＤＳＰに代えてマイクロコンピュータを使用しても良い。
【００１３】
オーディオエンコーダ／デコーダＩＣ１０は、オーディオインタフェース１１およびエンコーダ／デコーダブロック１２を有する。エンコーダ／デコーダブロック１２は、ディジタルオーディオ信号をメモリカード４０に書き込むために高能率符号化し、また、メモリカード４０から読み出されたデータを復号する。高能率符号化方法としては、ミニディスクで採用されているＡＴＲＡＣ(Adaptive Transform Acoustic Coding)を改良したもの（ＡＴＲＡＣ３と表記する）が使用できる。
【００１４】
ＡＴＲＡＣ３では、４４．１ｋHzでサンプリングした１サンプル１６ビットのオーディオデータを処理する。ＡＴＲＡＣ３でオーディオデータを処理する時の最小のデータ単位がサウンドユニットＳＵである。１ＳＵは、１０２４サンプル分（１０２４×１６ビット×２チャンネル）を数百バイトに圧縮したものであり、時間にして約２３ｍ秒である。ＡＴＲＡＣ３により約１／１０にオーディオデータが圧縮される。ミニディスクにおいてそうであるように、ＡＴＲＡＣ３の工夫された信号処理によって、圧縮／伸長処理による音質の劣化は少ない。
【００１５】
ライン入力セレクタ１３は、ＭＤの再生出力、チューナの出力、テープ再生出力を選択的にＡ／Ｄ変換器１４に供給する。Ａ／Ｄ変換器１４は、選択されたライン入力信号を（サンプリング周波数＝４４．１ｋHz、１サンプル＝１６ビット）のディジタルオーディオ信号へ変換する。
ディジタル入力セレクタ１６は、ＭＤ、ＣＤ、ＣＳ（衛星ディジタル放送）のディジタル出力を選択的にディジタル入力レシーバ１７に供給する。ディジタル入力は、例えば光ケーブルを介して伝送される。ディジタル入力レシーバ１７の出力がサンプリングレートコンバータ１５に供給され、ディジタル入力のサンプリング周波数が４４．１ｋHzに変換される。
【００１６】
オーディオエンコーダ／デコーダＩＣ１０のエンコーダ／デコーダブロック１２でのエンコード処理により得られた符号化データは、セキュリティＩＣ２０のインタフェース２１を介してＤＥＳの暗号化回路２２に供給される。
ＤＥＳの暗号化回路２２は、ＦＩＦＯ２３を有している。ＤＥＳの暗号化回路２２は、コンテンツの著作権を保護するための備えられている。
なお後述するが、メモリカード４０にも、ＤＥＳの暗号化回路が組み込まれている。
レコーダ１のＤＥＳの暗号化回路２２は、複数のマスターキーと機器毎にユニークなストレージキーを持つ。さらに、ＤＥＳの暗号化回路２２は、乱数発生回路を持ち、ＤＥＳの暗号化回路を内蔵するメモリカード４０と認証およびセッションキーを共有することができる。よりさらに、ＤＥＳの暗号化回路２２は、ＤＥＳの暗号化回路を通してストレージキーでキーをかけなおすことができる。
【００１７】
ＤＥＳの暗号化回路２２からの暗号化されたオーディオデータがＤＳＰ(Digit al Signal Processor) ３０に供給される。ＤＳＰ３０は、図示しない着脱機構に装着されたメモリカード４０との間で、図２に示すメモリインタフェース３８を介しての通信を行い、暗号化されたデータをフラッシュメモリに書き込む。
ＤＳＰ３０とメモリカード４０との間では、シリアル通信がなされる。また、メモリカード４０の制御に必要なメモリ容量を確保するために、ＤＳＰ３０に対して外付けのＳＲＡＭ(Static Random Access Memory) ３１が接続される。
【００１８】
さらにＤＳＰ３０に対して、端子３２が接続され、図示しない外部機器又は外部回路部との間でコンテンツデータや制御データの相互通信を行うことができるようにされている。ＤＳＰ３０は図２に示すインターフェース３７を介して、外部機器等との間で通信を行う。
例えばこのレコーダ１が単体で構成される場合は、インターフェース３７及び端子３２は、例えばＵＳＢ、ＩＥＥＥ１３９４、ＩＥＣ９５８、シリアルポート通信、パラレルポート通信など、所定の通信方式に応じたものとされ、パーソナルコンピュータやオーディオ／ビジュアル機器等との間で通信可能とされる。
【００１９】
また、このレコーダ１がパーソナルコンピュータやオーディオ／ビジュアル機器などに内蔵される場合は、インターフェース３７及び端子３２は、例えばそれらの機器のシステムコントローラと接続される内部バス等の構成をとることになる。
【００２０】
端子３２に接続された機器或いは部位からは、各種のデータがＤＳＰ３０に供給される。例えばレコーダ１がオーディオシステムやコンピュータシステムの一部とされている場合は、そのオーディオシステムやコンピュータシステムの全体の動作を制御する外部のシステムコントローラからは、ユーザの操作に応じて発生した録音指令、再生指令等のデータをＤＳＰ３０に与える。
また、画像情報、文字情報等の付加情報のデータも端子３２を介してＤＳＰ３０に供給される。
さらにＤＳＰ３０は、端子３２を介して、メモリカード４０から読み出された付加情報データ、制御信号等を外部のシステムコントローラに供給することもできる。
【００２１】
なお、図１にはユーザーが各種の操作を行う操作キー等が設けられた操作部３９、及びユーザーに対して各種の情報の提示を行う表示部３３を示している。これらは特にレコーダ１が単体で構成される場合に必要となるものであり、例えばレコーダ１がパーソナルコンピュータに内蔵される場合などは、ＤＳＰ３０に操作部３９及び表示部３３が直接接続される必要はない。
つまり単体の場合はＤＳＰ３０が操作部３９からの操作入力の処理や表示部３３での表示制御を行うことになるが、内蔵型の場合は、その装置のシステムコントローラがこれらの制御を行い、必要に応じてＤＳＰ３０に操作情報を供給したり、或いはＤＳＰ３０から表示すべき内容を示す情報を受け取ったりすればよいためである。
【００２２】
ＤＳＰ３０によってメモリカード４０から読み出したコンテンツとしての暗号化されたオーディオデータは、セキュリティＩＣ２０によって復号化され、オーディオエンコーダ／デコーダＩＣ１０によってＡＴＲＡＣ３の復号化処理を受ける。
そしてオーディオエンコーダ／デコーダ１０の復号化出力がＤ／Ａ変換器１８に供給され、アナログオーディオ信号へ変換される。そして、アナログオーディオ信号がライン出力端子１９に取り出される。
【００２３】
ライン出力は、図示しないアンプ装置等に伝送され、スピーカまたはヘッドホンにより再生される。
なおＤ／Ａ変換器１８に対してミューティング信号が外部のコントローラから供給される。ミューティング信号がミューティングのオンを示す時には、ライン出力端子１９からのオーディオ出力が禁止される。
【００２４】
なお、図１ではライン出力端子１９のみを示しているが、もちろんデジタル出力端子、ヘッドホン端子等が設けられてもよい。
また外部機器へのコンテンツデータの出力は、上述のように端子３２を介して行うこともできる。
【００２５】
図２は、ＤＳＰ３０の内部構成を示す。ＤＳＰ３０は、コア３４と、フラッシュメモリ３５と、ＳＲＡＭ３６と、インタフェース３７と、メモリカードインタフェース３８と、バスおよびバス間のブリッジとで構成される。
このＤＳＰ３０はマイクロコンピュータと同様に機能し、コア３４がＣＰＵに相当する。
フラッシュメモリ３５にはＤＳＰ３０の処理のためのプログラムが格納されている。またＳＲＡＭ３６と外部のＳＲＡＭ３１とが、各種処理のためのワークメモリとして使用される。
【００２６】
ＤＳＰ３０は、インタフェース３７を介して受け取った録音指令等の操作信号（又は図１に示す操作部３９から入力された操作信号）に応答して、所定の暗号化されたオーディオデータ、所定の付加情報データをメモリカード４０に対して書き込み、また、これらのデータをメモリカード４０から読み出す処理を制御する。
すなわち、オーディオデータ、付加情報の記録／再生を行うためのオーディオシステム全体のアプリケーションソフトウェアと、メモリカード４０との間にＤＳＰ３０が位置し、メモリカード４０のアクセス、ファイルシステム等のソフトウェアによってＤＳＰ３０が動作する。
【００２７】
ＤＳＰ３０におけるメモリカード４０上のファイル管理は、既存のパーソナルコンピュータで使用されているＦＡＴファイルシステムが使用される。このファイルシステムに加えて、本例では、後述するようなデータ構成の再生管理ファイルが使用される。
再生管理ファイルは、メモリカード４０上に記録されているデータファイルを管理する。
すなわち第１のファイル管理情報としての再生管理ファイルは、オーディオデータのファイルを管理するものであり、第２のファイル管理情報としてのＦＡＴは、オーディオデータのファイルと再生管理ファイルを含むメモリカード０のフラッシュメモリ上のファイル全体を管理する。
再生管理ファイルは、メモリカード４０に記録される。また、ＦＡＴは、ルートディレクトリ等と共に、予め出荷時にフラッシュメモリ上に書き込まれている。
【００２８】
なお本例では、著作権を保護するために、ＡＴＲＡＣ３により圧縮されたオーディオデータを暗号化している。一方、管理ファイルは、著作権保護が必要ないとして、暗号化を行わないようにしている。また、メモリカード４０としても、暗号化機能を持つものと、持たないものとがありうる。本例のように、著作物であるオーディオデータを記録するレコーダ１が使用できるものは、暗号化機能を持つメモリカードのみである。
【００２９】
２．メモリカードの構成
図３は、メモリカード４０の構成を示す。メモリカード４０は、コントロールブロック４１とフラッシュメモリ４２が１チップＩＣとして構成されたものである。
レコーダ１のＤＳＰ３０とメモリカード４０との間の双方向シリアルインタフェースは、１０本の線からなる。主要な４本の線は、データ伝送時にクロックを伝送するためのクロック線ＳＣＫと、ステータスを伝送するためのステータス線ＳＢＳと、データを伝送するデータ線ＤＩＯ、インターラプト線ＩＮＴとである。その他に電源供給用線として、２本のＧＮＤ線および２本のＶＣＣ線が設けられる。２本の線Ｒｅｓｅｒｖは、未定義の線である。
【００３０】
クロック線ＳＣＫは、データに同期したクロックを伝送するための線である。ステータス線ＳＢＳは、メモリカード４０のステータスを表す信号を伝送するための線である。データ線ＤＩＯは、コマンドおよび暗号化されたオーディオデータを入出力するための線である。インターラプト線ＩＮＴは、メモリカード４０からレコーダ１のＤＳＰ３０に対しての割り込みを要求するインターラプト信号を伝送する線である。メモリカード４０を装着した時にインターラプト信号が発生する。但し、本例では、インターラプト信号をデータ線ＤＩＯを介して伝送するようにしているので、インターラプト線ＩＮＴを接地している。
【００３１】
コントロールブロック４１のシリアル／パラレル変換・パラレル／シリアル変換・インタフェースブロック（Ｓ／Ｐ，Ｐ／Ｓ，ＩＦブロックと略す）４３は、上述した複数の線を介して接続されたレコーダのＤＳＰ３０とコントロールブロック４１とのインタフェースである。Ｓ／Ｐ，Ｐ／Ｓ，ＩＦブロック４３は、レコーダ１のＤＳＰ３０から受け取ったシリアルデータをパラレルデータに変換し、コントロールブロック４１に取り込み、コントロールブロック４１からのパラレルデータをシリアルデータに変換してレコーダ１のＤＳＰ３０に送る。また、Ｓ／Ｐ，Ｐ／Ｓ，ＩＦブロック４３は、データ線ＤＩＯを介して伝送されるコマンドおよびデータを受け取った時に、フラッシュメモリ４２に対する通常のアクセスのためのコマンドおよびデータと、暗号化に必要なコマンドおよびデータとを分離する。
【００３２】
つまり、データ線ＤＩＯを介して伝送されるフォーマットでは、最初にコマンドが伝送され、その後にデータが伝送される。Ｓ／Ｐ，Ｐ／Ｓ，ＩＦブロック４３は、コマンドのコードを見て、通常のアクセスに必要なコマンドおよびデータか、暗号化に必要なコマンドおよびデータかを判別する。この判別結果に従って、通常のアクセスに必要なコマンドをコマンドレジスタ４４に格納し、データをページバッファ４５およびライトレジスタ４６に格納する。ライトレジスタ４６と関連してエラー訂正符号化回路４７が設けられている。ページバッファ４５に一時的に蓄えられたデータに対して、エラー訂正符号化回路４７がエラー訂正符号の冗長コードを生成する。
【００３３】
コマンドレジスタ４４、ページバッファ４５、ライトレジスタ４６およびエラー訂正符号化回路４７の出力データがフラッシュメモリインタフェースおよびシーケンサ（メモリＩ／Ｆ，シーケンサと略す）５１に供給される。メモリＩＦ，シーケンサ５１は、コントロールブロック４１とフラッシュメモリ４２とのインタフェースであり、両者の間のデータのやり取りを制御する。メモリＩＦ，シーケンサ５１を介してデータがフラッシュメモリ４２に書き込まれる。
【００３４】
フラッシュメモリ４２に書き込まれるコンテンツ（ＡＴＲＡＣ３により圧縮されたオーディオデータ、以下ＡＴＲＡＣ３データと表記する）は、著作権保護のために、レコーダ１のセキュリティＩＣ２０とメモリカード４０のセキュリティブロック５２とによって、暗号化されたものである。セキュリティブロック５２は、バッファメモリ５３と、ＤＥＳの暗号化回路５４と、不揮発性メモリ５５とを有する。
【００３５】
メモリカード４０のセキュリティブロック５２は、複数の認証キーとメモリカード毎にユニークなストレージキーを持つ。不揮発性メモリ５５は、暗号化に必要なキーを格納するもので、外部からは見えない。例えばストレージキーが不揮発性メモリ５５に格納される。
さらに、乱数発生回路を持ち、専用（ある決められたデータフォーマット等の使用が同じシステム内の意味）レコーダ１と認証ができ、セッションキーを共有できる。よりさらに、ＤＥＳの暗号化回路５４を通してストレージキーでキーのかけ直しができる。
【００３６】
例えばメモリカード４０をレコーダ１に装着した時に認証がなされる。認証は、レコーダ１のセキュリティＩＣ２０とメモリカード４０のセキュリティブロック５２によってなされる。
レコーダ１は、装着されたメモリカード４０が本人（同じシステム内のメモリカード）であることを認め、また、メモリカード４０が相手のレコーダが本人（同じシステム内のレコーダ）であることを認めると、互いに相手が本人であることを確認する。認証が行われると、レコーダ１とメモリカード４０がそれぞれセッションキーを生成し、セッションキーを共有する。セッションキーは、認証の度に生成される。
【００３７】
そして、メモリカード４０に対するコンテンツの書き込み時には、レコーダ１がセッションキーでコンテンツキーを暗号化してメモリカード４０に渡す。メモリカード４０では、コンテンツキーをセッションキーで復号し、ストレージキーで暗号化してレコーダ１に渡す。
ストレージキーは、メモリカード４０の一つ一つにユニークなキーであり、レコーダ１は、暗号化されたコンテンツキーを受け取ると、フォーマット処理を行い、暗号化されたコンテンツキーと暗号化されたコンテンツをメモリカード４０に書き込む。
【００３８】
フラッシュメモリ４２からのデータ読出時には、読み出されたデータがメモリＩＦ，シーケンサ５１を介してページバッファ４５、リードレジスタ４８、エラー訂正回路４９に供給される。そしてページバッファ４５に記憶されたデータがエラー訂正回路４９によってエラー訂正がなされる。
エラー訂正されたページバッファ４５の出力およびリードレジスタ４８の出力はＳ／Ｐ，Ｐ／Ｓ，ＩＦブロック４３に供給され、上述したシリアルインタフェースを介してレコーダ１のＤＳＰ３０に供給される。
【００３９】
このような読出時には、ストレージキーで暗号化されたコンテンツキーとブロックキーで暗号化されたコンテンツとがフラッシュメモリ４２から読み出される。そしてセキュリティブロック５２によって、ストレージキーでコンテンツキーが復号される。
さらに復号されたコンテンツキーがセッションキーで暗号化されてレコーダ１側に送信される。レコーダ１は、受信したセッションキーでコンテンツキーを復号する。レコーダ１は、復号したコンテンツキーでブロックキーを生成する。このブロックキーによって、暗号化されたＡＴＲＡＣ３データを順次復号する。
【００４０】
なお、コンフィグレーションＲＯＭ５０には、メモリカード４０のバージョン情報、各種の属性情報等が格納されている。
また、メモリカード４０には、ユーザが必要に応じて操作可能な誤消去防止用のスイッチ６０が備えられている。このスイッチ６０が消去禁止の接続状態にある場合には、フラッシュメモリ４２を消去することを指示するコマンドがレコーダ側から送られてきても、フラッシュメモリ４２の消去が禁止される。
さらに、発振器６１は、メモリカード４０の処理のタイミング基準となるクロックを発生する。
【００４１】
３．ファイルシステム
３−１ 処理構造及びデータ構造
図４は、メモリカード４０を記憶媒体とするシステムのファイルシステム処理階層を示す。
ファイルシステム処理階層としては、アプリケーション処理層が最上位であり、その下に、ファイル管理処理層、論理アドレス管理層、物理アドレス管理層、フラッシュメモリアクセスが順次おかれる。
この階層構造において、ファイル管理処理層がＦＡＴファイルシステムである。物理アドレスは、フラッシュメモリの各ブロックに対して付されたもので、ブロックと物理アドレスの対応関係は、不変である。論理アドレスは、ファイル管理処理層が論理的に扱うアドレスである。
【００４２】
図５は、メモリカード４０におけるフラッシュメモリ４２のデータの物理的構成の一例を示す。
フラッシュメモリ４２は、セグメントと称されるデータ単位が所定数のブロック（固定長）へ分割され、１ブロックが所定数のページ（固定長）へ分割される。フラッシュメモリ４２では、ブロック単位で消去が一括して行われ、書き込みと読み出しは、ページ単位で一括して行われる。
【００４３】
各ブロックおよび各ページは、それぞれ同一のサイズとされ、１ブロックがページ０からページｍで構成される。１ブロックは、例えば８ＫＢ（Ｋバイト）バイトまたは１６ＫＢの容量とされ、１ページが５１２Ｂの容量とされる。フラッシュメモリ４２全体では、１ブロック＝８ＫＢの場合で、４ＭＢ（５１２ブロック）、８ＭＢ（１０２４ブロック）とされ、１ブロック＝１６ＫＢの場合で、１６ＭＢ（１０２４ブロック）、３２ＭＢ（２０４８ブロック）、６４ＭＢ（４０９６ブロック）の容量とされる。
【００４４】
１ページは、５１２バイトのデータ部と１６バイトの冗長部とからなる。冗長部の先頭の３バイトは、データの更新に応じて書き換えられるオーバーライト部分とされる。３バイトの各バイトに、先頭から順にブロックステータス、ページステータス、更新ステータスが記録される。
冗長部の残りの１３バイトの内容は、原則的にデータ部の内容に応じて固定とされる。この１３バイトは、管理フラグ（１バイト）、論理アドレス（２バイト）、フォーマットリザーブの領域（５バイト）、分散情報ＥＣＣ（２バイト）およびデータＥＣＣ（３バイト）からなる。
分散情報ＥＣＣは、管理フラグ、論理アドレス、フォーマットリザーブに対する誤り訂正用の冗長データであり、データＥＣＣは、５１２バイトのデータに対する誤り訂正用の冗長データである。
【００４５】
管理フラグとして、システムフラグ（その値が１：ユーザブロック、０：ブートブロック）、変換テーブルフラグ（１：無効、０：テーブルブロック）、コピー禁止指定（１：ＯＫ、０：ＮＧ）、アクセス許可（１：ｆｒｅｅ、０：リードプロテクト）の各フラグが記録される。
【００４６】
セグメントにおける先頭の二つのブロック、すなわちブロック０およびブロック１がブートブロックである。ブロック１は、ブロック０と同一のデータが書かれるバックアップ用である。
ブートブロックは、メモリカード４０内の有効なブロックの先頭ブロックであり、メモリカード４０を機器に装填した時に最初にアクセスされるブロックである。残りのブロックがユーザブロックである。
ブートブロックの先頭のページ０にヘッダ、システムエントリ、ブート＆アトリビュート情報が格納される。ページ１に使用禁止ブロックデータが格納される。ページ２にＣＩＳ(Card Information Structure)／ＩＤＩ(Identify Drive Information)が格納される。
【００４７】
ブートブロックのヘッダは、ブートブロックＩＤ、ブートブロック内の有効なエントリ数が記録される。システムエントリには、使用禁止ブロックデータの開始位置、そのデータサイズ、データ種別、ＣＩＳ／ＩＤＩのデータ開始位置、そのデータサイズ、データ種別が記録される。
ブート＆アトリビュート情報には、メモリカード４０のタイプ（読み出し専用、リードおよびライト可能、両タイプのハイブリッド等）、ブロックサイズ、ブロック数、総ブロック数、セキュリティ対応か否か、カードの製造に関連したデータ（製造年月日等）等が記録される。
【００４８】
いわゆるフラッシュメモリは、データの書き換えを行うことにより絶縁膜の劣化を生じ、書き換え回数が制限される。従って、ある同一の記憶領域（ブロック）に対して繰り返し集中的にアクセスがなされることを防止する必要がある。従って、ある物理アドレスに格納されているある論理アドレスのデータを書き換える場合、フラッシュメモリのファイルシステムでは、同一のブロックに対して更新したデータを再度書き込むことはせずに、未使用のブロックに対して更新したデータを書き込むようになされる。その結果、データ更新前における論理アドレスと物理アドレスの対応関係が更新後では、変化する。このような処理（スワップ処理と称する）を行うことで、同一のブロックに対して繰り返して集中的にアクセスがされることが防止され、フラッシュメモリの寿命を延ばすことが可能となる。
【００４９】
論理アドレスは、一旦ブロックに対して書き込まれたデータに付随するので、更新前のデータと更新後のデータの書き込まれるブロックが移動しても、ＦＡＴからは、同一のアドレスが見えることになり、以降のアクセスを適正に行うことができる。スワップ処理により論理アドレスと物理アドレスとの対応関係が変化するので、両者の対応を示す論理−物理アドレス変換テーブルが必要となる。このテーブルを参照することによって、ＦＡＴが指定した論理アドレスに対応する物理アドレスが特定され、特定された物理アドレスが示すブロックに対するアクセスが可能となる。
【００５０】
論理−物理アドレス変換テーブルは、ＤＳＰ３０によってＳＲＡＭ３１、３６上に格納される。若し、ＲＡＭ容量が少ない時は、フラッシュメモリ４２中に格納することができる。
このテーブルは、概略的には、昇順に並べた論理アドレス（２バイト）に物理アドレス（２バイト）をそれぞれ対応させたテーブルである。フラッシュメモリ４２の最大容量を１２８ＭＢ（８１９２ブロック）としているので、２バイトによって８１９２のアドレスを表すことができる。また、論理−物理アドレス変換テーブルは、セグメント毎に管理され、そのサイズは、フラッシュメモリ４２の容量に応じて大きくなる。例えばフラッシュメモリ４２の容量が８ＭＢ（２セグメント）の場合では、２個のセグメントのそれぞれに対して２ページが論理−物理アドレス変換テーブル用に使用される。
論理−物理アドレス変換テーブルを、フラッシュメモリ４２中に格納する時には、上述した各ページの冗長部における管理フラグの所定の１ビットによって、当該ブロックが論理−物理アドレス変換テーブルが格納されているブロックか否かが指示される。
【００５１】
上述したメモリカード４０は、ディスク状記録媒体と同様にパーソナルコンピュータのＦＡＴファイルシステムによって使用可能なものである。
図５には示されてないが、フラッシュメモリ４２上にＩＰＬ領域、ＦＡＴ領域およびルート・ディレクトリ領域が設けられる。
ＩＰＬ領域には、最初にレコーダ１のメモリにロードすべきプログラムが書かれているアドレス、並びにメモリの各種情報が書かれている。
ＦＡＴ領域には、ブロック（クラスタ）の関連事項が書かれている。ＦＡＴには、未使用のブロック、次のブロック番号、不良ブロック、最後のブロックをそれぞれ示す値が規定される。
さらに、ルートディレクトリ領域には、ディレクトリエントリ（ファイル属性、更新年月日、開始クラスタ、ファイルサイズ等）が書かれている。
【００５２】
本例では、上述したメモリカード４０のフォーマットで規定されるファイル管理システムとは別個に、音楽用ファイルに対して、各トラックおよび各トラックを構成するパーツを管理するための再生管理ファイルを持つようにしている。この再生管理ファイルは、メモリカード４０のユーザブロックを利用してフラッシュメモリ４２上に記録される。それによって、メモリカード４０上のＦＡＴが壊れても、ファイルの修復が可能となる。
【００５３】
この再生管理ファイルは、ＤＳＰ３０により作成される。例えば最初に電源をオンした時に、メモリカード４０が装着されているか否かが判定され、メモリカード４０が装着されている時には、認証が行われる。認証により正規のメモリカードであることが確認されると、フラッシュメモリ４２のブートブロックがＤＳＰ３０に読み込まれる。そして、論理−物理アドレス変換テーブルが読み込まれる。読み込まれたデータは、ＳＲＡＭ３１、３６に格納される。ユーザが購入して初めて使用するメモリカード４０でも、出荷時にフラッシュメモリ４２には、ＦＡＴや、ルートディレクトリの書き込みがなされている。再生管理ファイルは、録音がなされると、作成される。
【００５４】
すなわち、ユーザの操作等によって発生した録音指令がＤＳＰ３０に与えられると、受信したオーディオデータがエンコーダ／デコーダＩＣ１０によって圧縮され、エンコーダ／デコーダＩＣ１０からのＡＴＲＡＣ３データがセキュリティＩＣ２０により暗号化される。そしてＤＳＰ３０が暗号化されたＡＴＲＡＣ３データをメモリカード４０のフラッシュメモリ４２に記録するが、この記録後にＦＡＴおよび再生管理ファイルが更新される。
ファイルの更新の度、具体的には、オーディオデータの記録を開始し、記録を終了する度に、ＳＲＡＭ３１および３６上でＦＡＴおよび再生管理ファイルが書き換えられる。そして、メモリカード４０を外す時に、またはパワーをオフする時に、ＳＲＡＭ３１、３６からメモリカード４０のフラッシュメモリ４２上に最終的なＦＡＴおよび再生管理ファイルが格納される。この場合、オーディオデータの記録を開始し、記録を終了する度に、フラッシュメモリ４２上のＦＡＴおよび再生管理ファイルを書き換えても良い。編集を行った場合も、再生管理ファイルの内容が更新される。
【００５５】
さらに、本例のデータ構成では、付加情報も再生管理ファイル内に作成、更新され、フラッシュメモリ４２上に記録される。なお、再生管理ファイルとは別に付加情報管理ファイルが作成されるようにしてもよい。
付加情報は、外部のコントローラからバスおよびバスインターフェース３２を介してＤＳＰ３０に与えられる。ＤＳＰ３０が受信した付加情報をメモリカード４０のフラッシュメモリ４２上に記録する。付加情報は、セキュリティＩＣ２０を通らないので、暗号化されない。付加情報は、メモリカード４０を取り外したり、電源オフの時に、ＤＳＰ３０のＳＲＡＭからフラッシュメモリ４２に書き込まれる。
【００５６】
３−２ ディレクトリ構成
図６は、メモリカード４０のディレクトリ構成を示す。図示するようにルートディレクトリから、静止画用ディレクトリ、動画用ディレクトリ、音声用ディレクトリ、制御用ディレクトリ、音楽用（ＨＩＦＩ）ディレクトリが形成される。
本例では、音楽の記録／再生を中心に説明を行うので、以下、音楽用ディレクトリについて説明する。
音楽用ディレクトリには、２種類のファイルが置かれる。その１つは、再生管理ファイルＰＢＬＩＳＴ．ＭＳＦ（以下、単にＰＢＬＩＳＴと表記する）であり、他のものは、暗号化された音楽データを収納したＡＴＲＡＣ３データファイルＡ３Ｄｎｎｎｎ．ＭＳＡ（以下、単にＡ３Ｄｎｎｎと表記する）とからなる。
ＡＴＲＡＣ３データファイルは、最大数が４００までと規定されている。ＡＴＲＡＣ３データファイルは、再生管理ファイルに登録した上で機器により任意に作成される。
【００５７】
３−３ 管理構造及び編集方式
図７は、再生管理ファイルの構成を示し、図８が一つ（１曲）のＡＴＲＡＣ３データファイルの構成を示す。
再生管理ファイルは、１６ＫＢ固定長のファイルである。
図７に示すように再生管理ファイルは、ヘッダ、１バイトコードのメモリカードの名前ＮＭ１−Ｓ、２バイトコードのメモリカードの名前ＮＭ２−Ｓ、曲順の再生テーブルＴＲＫＴＢＬ、及びメモリカード全体の付加情報ＩＮＦ−Ｓとからなる。
【００５８】
また図８に示すＡＴＲＡＣ３データファイル（以下、単にデータファイルともいう）は、本発明でいうプログラム（又はコンテンツ）に相当するものであり、即ち曲単位のファイルである。そしてデータファイルは、先頭の属性ヘッダと、それに続く実際の暗号化された音楽データとからなる。属性ヘッダは１６ＫＢ固定長とされ、再生管理ファイルと類似した構成を有する。
データファイルの先頭の属性ヘッダは、ヘッダ、１バイトコードの曲名ＮＭ１、２バイトコードの曲名ＮＭ２、トラックのキー情報等のトラック情報ＴＲＫＩＮＦ、パーツ情報ＰＲＴＩＮＦと、トラックの付加情報ＩＮＦとからなる。ヘッダには、総パーツ数、名前の属性、付加情報のサイズの情報等が含まれる。
【００５９】
このデータファイルにおいては、属性ヘッダに対してＡＴＲＡＣ３の音楽データが続く。音楽データは、１６ＫＢのブロック毎に区切られ、各ブロックの先頭にヘッダが付加されている。ヘッダには、暗号を復号するための初期値が含まれる。
なお、暗号化の処理を受けるのは、ＡＴＲＡＣ３データファイル中の音楽データのみであって、それ以外の再生管理ファイル、ヘッダ等のデータは、暗号化されない。
【００６０】
図９を参照して、曲（コンテンツ）とＡＴＲＡＣ３データファイルの関係について説明する。
１つのコンテンツは、１曲として管理されるデータ群を意味する。１曲は、１つのＡＴＲＡＣ３データファイル（図８参照）で構成される。ＡＴＲＡＣ３データファイルは、ＡＴＲＡＣ３により圧縮されたオーディオデータが記録されている。
【００６１】
なお、メモリカード４０に対しては、クラスタと呼ばれる単位でデータの記録が行われる。１クラスタは例えば１６ＫＢの容量である。この１クラスタには複数のファイルが混じることがない。またフラッシュメモリ４２を消去する時の最小単位が１ブロックである。
音楽データを記録するのに使用するメモリカード４０の場合、ブロックとクラスタは、同意語であり、且つ１クラスタ＝１セクタと定義されている。
【００６２】
１曲は、基本的に１パーツで構成されるが、編集が行われると、複数のパーツから１曲が構成されることがある。パーツとは、録音開始からその停止までの連続した時間内で記録されたデータの単位を意味し、通常は、１つのコンテンツは１パーツで構成される。
１つのコンテンツが複数のパーツで構成される場合、曲内のパーツのつながりは、各曲の属性ヘッダ内のパーツ情報ＰＲＴＩＮＦ（後述）で管理する。すなわち、パーツサイズは、ＰＲＴＩＮＦの中のパーツサイズＰＲＴＳＩＺＥという４バイトのデータで表す。パーツサイズＰＲＴＳＩＺＥの先頭の２バイトがパーツが持つクラスタの総数を示し、続く各１バイトが先頭および末尾のクラスタ内の開始サウンドユニット（ＳＵと略記する）の位置、終了ＳＵの位置を示す。
このようなパーツの記述方法を持つことによって、音楽データを編集する際に通常、必要とされる大量の音楽データの移動をなくすことが可能となる。
なおブロック単位の編集に限定すれば、同様に音楽データの移動を回避できるが、ブロック単位は、ＳＵ単位に比して編集単位が大きすぎる。
【００６３】
ＳＵは、パーツの最小単位であり、且つＡＴＲＡＣ３でオーディオデータを圧縮する時の最小のデータ単位である。４４．１ｋHzのサンプリング周波数で得られた１０２４サンプル分（１０２４×１６ビット×２チャンネル）のオーディオデータを約１／１０に圧縮した数百バイトのデータがＳＵである。
１ＳＵは、時間に換算して約２３ｍ秒になる。通常は、数千に及ぶＳＵによって１つのパーツが構成される。
１クラスタが４２個のＳＵで構成される場合、１クラスタで約１秒の音を表すことができる。
１つのコンテンツを構成するパーツの数は、付加情報サイズに影響される。
パーツ数は、１ブロックの中からヘッダや曲名、付加情報データ等を除いた数で決まるために、付加情報が全く無い状態が最大数（６４５個）のパーツを使用できる条件となる。
【００６４】
図９は、ＣＤ等からのオーディオデータを２曲連続して記録した場合のファイル構成を示す。
図９（ａ）に１曲目（データファイル＃１）が例えば５つのクラスタ（ＣＬ０〜ＣＬ４）で構成された場合を、また図９（ｃ）に２曲目（データファイル＃２）が例えば６つのクラスタ（ＣＬ５〜ＣＬ１０）で構成された場合を示している。
１曲目と２曲目の曲間では、１クラスタに二つのファイルが混在することが許されないので、次のクラスタ（ＣＬ５）の最初からデータファイル＃２が作成される。
従って、データファイル＃１の終端（１曲目の終端）がクラスタの途中に位置しても、図９（ｂ）に拡大して示すように、そのクラスタの残りの部分には、データ（ＳＵ）が存在しないものとされる。
第２曲目（データファイル＃２）も同様である。
そしてこの例の場合は、データファイル＃１、＃２ともに１パーツで構成される。
【００６５】
メモリカード４０に記録されたデータファイルに対しては、編集として、デバイド、コンバイン、イレーズ、ムーブの４種類の処理が規定される。
デバイドは、１つのトラックを２つに分割することである。デバイドがされると、総トラック数が１つ増加する。デバイドは、一つのファイルをファイルシステム上で分割して２つのファイルとし、再生管理ファイルを更新する。
コンバインは、２つのトラックを１つに結合することである。コンバインされると、総トラック数が１つ減少する。コンバインは、２つのファイルをファイルシステム上で統合して１つのファイルにし、再生管理ファイルを更新する。
イレーズは、トラックを消去することである。消された以降のトラック番号が１つ減少する。
編集処理としてのムーブは、トラック順番を変えることである。この場合も再生管理ファイルを更新する。
なお、ここでいう編集処理としての「ムーブ」は、データの移動を伴うものではなく。例えばＨＤＤ等の記録媒体からメモリカード等の記録媒体へのデータの「ムーブ」とは意味が異なる。記録媒体から記録媒体へのムーブとは、データをコピーした上でコピー元の記録媒体からそのデータを消去することで実現するものである。
【００６６】
図９に示す二つの曲（データファイル＃１、＃２）をコンバインした結果を図１０に示す。コンバインされたことでデータファイル＃１、＃２は、１つのデータファイル＃１となり、このデータファイル＃１は、二つのパーツから形成されるものとなる。
上述したように本例ではパーツに関する記述方法があるので、コンバインした結果（図１０）において、パーツ１の開始位置、パーツ１の終了位置、パーツ２の開始位置、パーツ２の終了位置をそれぞれＳＵ単位で規定できる。その結果、コンバインした結果のつなぎ目の隙間をつめるために、パーツ２の音楽データを移動する必要がない。
【００６７】
また、図１１は、図９（ａ）の一つの曲（データファイル＃１）をクラスタ２の途中でデバイドした結果を示す。
デバイドによって、クラスタＣＬ０、ＣＬ１およびクラスタＣＬ２の前側からなるデータファイル＃１と、クラスタＣＬ２（ＣＬ１１）の後側とクラスタＣＬ３、ＣＬ４とからなるデータファイル＃２とが発生する。
上述したように、１つのクラスタに二つのファイルが混在することは許されないので、このようにクラスタＣＬ２内の或る位置を分割点とするデバイド編集の場合は、まず、クラスタＣＬ２のデータが、あいている別のクラスタＣＬ１１にコピーされる。そしてデータファイル＃２においては、クラスタＣＬ１１における分割点に相当する位置がスタートポイントとされ、そのクラスタＣＬ１１に、クラスタＣＬ３、ＣＬ４が続くようにされるものとなる。
従って、デバイド編集の場合は、再生管理ファイルの更新だけでなく、１つのクラスタを新たに使用することが必要となる。
【００６８】
なお、上述のようにパーツに関する記述方法があるので、デバイドした結果（図１１）において、データファイル＃２の先頭（クラスタＣＬ１１）の空きを詰めるように、データを移動する必要がない。
【００６９】
３−４ 再生管理ファイル
図１２は、再生管理ファイルＰＢＬＩＳＴのより詳細なデータ構成を示す。
再生管理ファイルＰＢＬＩＳＴは、１クラスタ（１ブロック＝１６ＫＢ）のサイズである。
先頭の３２バイトがヘッダとされる。
またヘッダ以外の部分がメモリカード全体に対する名前ＮＭ１−Ｓ（２５６バイト）、名前ＮＭ２−Ｓ（５１２バイト）、ＣＯＮＴＥＮＴＳ ＫＥＹ、ＭＡＣ、Ｓ−ＹＭＤｈｍｓと、再生順番を管理するテーブルＴＲＫＴＢＬ（８００バイト）と、メモリカード全体に対する付加情報ＩＮＦ−Ｓ（１４７２０バイト）であり、最後にヘッダ中の情報の一部が再度記録される。これらの異なる種類のデータ群のそれぞれの先頭は、再生管理ファイル内で所定の位置となるように規定されている。
【００７０】
再生管理ファイルにおいては、（０ｘ００００）および（０ｘ００１０）で表される先頭から３２バイトがヘッダである。
なお、ファイル中で先頭から１６バイト単位で区切られた単位をスロットと称する。
再生管理ファイルの第１および第２のスロットに配されるヘッダには、下記の意味、機能、値を持つデータが先頭から順に配される。
なお、Ｒｅｓｅｒｖｅｄと表記されているデータは、未定義のデータを表している。通常ヌル（０ｘ００）が書かれるが、何が書かれていてもＲｅｓｅｒｖｅｄのデータは無視される。将来のバージョンでは、変更がありうる。また、この部分への書き込みは禁止する。Ｏｐｔｉｏｎと書かれた部分も使用しない場合は、全てＲｅｓｅｒｖｅｄと同じ扱いとされる。
【００７１】
ＢＬＫＩＤ−ＴＬ０（４バイト）
意味：BLOCKID FILE ID
機能：再生管理ファイルの先頭であることを識別するための値。
値：固定値＝”ＴＬ＝０”（例えば０ｘ５４４Ｃ２Ｄ３０）
ＭＣｏｄｅ（２バイト）
意味：MAKER CODE
機能：記録した機器の、メーカー、モデルを識別するコード。
値：上位１０ビット（メーカーコード） 下位６ビット（機種コード）
ＲＥＶＩＳＩＯＮ（４バイト）
意味：再生管理ファイル（ＰＢＬＩＳＴ）の書き換え回数。
機能：再生管理ファイルを書き換える度にインクリメントする。
値：０より始まり＋１づつ増加する。
【００７２】
ＳＮ１Ｃ＋Ｌ（２バイト）
意味：ＮＭ１−Ｓ領域に書かれるメモリカードの名前（１バイト）の属性を表す。
機能：使用する文字コードと言語コードを各１バイトで表す。
値：文字コード（Ｃ）は上位１バイトで下記のように文字を区別する。
00: 文字コードは設定しない。単なる２進数として扱う。
01: ASCII 02:ASCII+KANA 03:modifided8859-1
81:MS-JIS 82:KS C 5601-1989 83:GB2312-80 90:S-JIS(for Voice) 。
言語コード（Ｌ）は下位１バイトで下記のようにEBU Tech 3258 規定に準じて言語を区別する。
00: 設定しない 08:German 09:English 0A:Spanish
0F:French 15:Italian 1D:Dutch
65:Korean 69:Japanese 75:Chinese
データが無い場合オールゼロとする。
【００７３】
ＳＮ２Ｃ＋Ｌ（２バイト）
意味：ＮＭ２−Ｓ領域に書かれるメモリカードの名前（２バイト）の属性を表す。
機能：使用する文字コードと言語コードを各１バイトで表す。
値：上述したＳＮ１Ｃ＋Ｌと同一。
ＳＩＮＦＳＩＺＥ（２バイト）
意味：ＩＮＦ−Ｓ領域に書かれるメモリカード全体に関する付加情報の全てを合計したサイズを表す。
機能：データサイズを１６バイト単位の大きさで記述、無い場合は必ずオールゼロとする。
値：サイズは０ｘ０００１から０ｘ３９Ｃ（９２４）。
【００７４】
Ｔ−ＴＲＫ（２バイト）
意味：TOTAL TRACK NUMBER
機能：総トラック数。
値：１から０ｘ０１９０（最大４００トラック）、データが無い場合はオールゼロとする。
ＶｅｒＮｏ（２バイト）
意味：フォーマットのバージョン番号。
機能：上位がメジャーバージョン番号、下位がマイナーバージョン番号。
値：例 ０ｘ０１００（Ｖｅｒ１．０）
０ｘ０２０３（Ｖｅｒ２．３）
【００７５】
上述したヘッダに続く領域に書かれるデータは以下のようになる。
【００７６】
ＮＭ１−Ｓ
意味：メモリカード全体に関する１バイトの名前。
機能：１バイトの文字コードで表した可変長の名前データ（最大で２５６）。
名前データの終了は、必ず終端コード（０ｘ００）を書き込む。
サイズはこの終端コードから計算する。データの無い場合は少なくとも先頭（０ｘ００２０）からヌル（０ｘ００）を１バイト以上記録する。
値：各種文字コード
ＮＭ２−Ｓ
意味：メモリカード全体に関する２バイトの名前。
機能：２バイトの文字コードで表した可変長の名前データ（最大で５１２）。
名前データの終了は、必ず終端コード（０ｘ００）を書き込む。
サイズはこの終端コードから計算する。データの無い場合は少なくとも先頭（０ｘ０１２０）からヌル（０ｘ００）を２バイト以上記録する。
値：各種文字コード。
【００７７】
ＣＯＮＴＥＮＴＳ ＫＥＹ
意味：曲ごとに用意された値。
ＭＧ（Ｍ）で保護されてから保存される。ここでは、１曲目に付けられるＣＯＮＴＥＮＴＳ ＫＥＹと同じ値となる。
機能：Ｓ−ＹＭＤｈｍｓのＭＡＣの計算に必要な鍵となる。
値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦまで。
ＭＡＣ
意味：著作権情報改ざんチェック値
機能：Ｓ−ＹＭＤｈｍｓの内容とＣＯＮＴＥＮＴＳ ＫＥＹから作成される値
値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦまで。
【００７８】
ＴＲＫ−ｎｎｎ
意味：再生するＡＴＲＡＣ３データファイルのＳＱＮ（シーケンス）番号
機能：ＴＲＫＩＮＦの中のＦＮｏを記述する。
値：１から４００（０ｘ１９０）
トラックが存在しない時はオールゼロとする。
ＩＮＦ−Ｓ
意味：メモリカード全体に関する付加情報データ（例えば写真、歌詞、解説等の情報）
機能：ヘッダを伴った可変長の付加情報データ。
複数の異なる付加情報が並べられることがある。それぞれにＩＤとデータサイズが付けられている。個々のヘッダを含む付加情報データは最小１６バイト以上で４バイトの整数倍の単位で構成される。その詳細については、後述する
値：付加情報データ構成を参照
Ｓ−ＹＭＤｈｍｓ（４バイト）（Ｏｐｔｉｏｎ）
意味：信頼できる時計を持つ機器で記録した年・月・日・時・分・秒
機能：最終記録日時を識別するための値、ＥＭＤの時は必須。
値：２５〜３１ビット 年 ０〜９９（１９８０〜２０７９）
２１〜２４ビット 月 ０〜１２
１６〜２０ビット 日 ０〜３１
１１〜１５ビット 時 ０〜２３
０５〜１０ビット 分 ０〜５９
００〜０４ビット 秒 ０〜２９（２秒単位）。
【００７９】
再生管理ファイルの最後のスロットとして、ヘッダ内のものと同一のＢＬＫＩＤ−ＴＬ０と、ＭＣｏｄｅと、ＲＥＶＩＳＩＯＮとが書かれる。
【００８０】
例えば民生用オーディオ機器としては、メモリカードが記録中に抜かれたり、電源が切れることがあり、復活した時にこれらの異常の発生を検出することが必要とされる。
上述したように、ＲＥＶＩＳＩＯＮはブロックの先頭と末尾に書き込むようにし、この値を書き換える度に＋１インクリメントするようにしている。従って若し、ブロックの途中で異常終了が発生すると、先頭と末尾のＲＥＶＩＳＩＯＮの値が一致せず、異常終了を検出することができる。
このようにＲＥＶＩＳＩＯＮが２個存在することで、高い確率で異常終了を検出することができる。異常終了の検出時には、エラーメッセージの表示等の警告が発生する。
【００８１】
また、１ブロック（１６ＫＢ）の先頭部分に固定値ＢＬＫＩＤ−ＴＬ０を挿入しているので、ＦＡＴが壊れた場合の修復の目安に固定値を使用できる。すなわち、各ブロックの先頭の固定値を見れば、ファイルの種類を判別することが可能である。しかも、この固定値ＢＬＫＩＤ−ＴＬ０は、ブロックのヘッダおよびブロックの終端部分に二重に記述するので、その信頼性のチェックを行うことができる。なお、再生管理ファイルＰＢＬＩＳＴの同一のものを二重に記録しても良い。
【００８２】
なおＡＴＲＡＣ３データファイルは、再生管理ファイルと比較して、相当大きなデータ量（例えば数千のブロックが繋がる場合もある）であり、ＡＴＲＡＣ３データファイルに関しては、後述するように、ブロック番号ＢＬＯＣＫ ＳＥＲＩＡＬが付けられている。但し、ＡＴＲＡＣ３データファイルは、通常複数のファイルがメモリカード上に存在するので、ＣＯＮＮＵＭ０でコンテンツの区別を付けた上で、ＢＬＯＣＫ ＳＥＲＩＡＬを付けないと、重複が発生し、ＦＡＴが壊れた場合のファイルの復旧が困難となる。
【００８３】
同様に、ＦＡＴの破壊までにはいたらないが、論理を間違ってファイルとして不都合のあるような場合に、書き込んだメーカーの機種が特定できるように、メーカーコード（ＭＣｏｄｅ）がブロックの先頭と末尾に記録されている。
【００８４】
図１３は、再生管理ファイルに記録される付加情報データ（ＩＮＦ−Ｓ）の構成を示す。
付加情報の先頭に下記のヘッダが書かれる。ヘッダ以降に可変長のデータが書かれる。
【００８５】
ＩＮＦ
意味：FIELD ID
機能：付加情報データの先頭を示す固定値。
値：０ｘ６９
ＩＤ
意味：付加情報キーコード
機能：付加情報の分類を示す。
値：０から０ｘＦＦ
ＳＩＺＥ
意味：個別の付加情報の大きさ
機能：データサイズは自由であるが、必ず４バイトの整数倍でなければならない。また、最小１６バイト以上のこと。データの終わりより余りがでる場合はヌル（０ｘ００）で埋めておく。
値：１６から１４７８４（０ｘ３９Ｃ０）
ＭＣｏｄｅ
意味：MAKER CODE
機能：記録した機器の、メーカー、モデルを識別するコード。
値：上位１０ビット（メーカーコード） 下位６ビット（機種コード）
Ｃ＋Ｌ
意味：先頭から１２バイト目からのデータ領域に書かれる文字の属性を表す
機能：使用する文字コードと言語コードを各１バイトで表す。
値：前述のＳＮ１Ｃ＋Ｌと同じ
ＤＡＴＡ
意味：個別の付加情報データ
機能：可変長データで表す。実データの先頭は常に１２バイト目より始まり、長さ（サイズ）は最小４バイト以上、常に４バイトの整数倍でなければならない。データの最後から余りがある場合はヌル（０ｘ００）で埋める。
値：内容により個別に定義される。
【００８６】
図１４は、付加情報キーコードの値（０〜６３）と、付加情報の種類の対応の一例を示す。キーコードの値（０〜３１）が音楽関係（文字情報）に対して割り当てられ、その（３２〜６３）がＵＲＬ(Uniform Resource Locator)（Ｗｅｂ関係）に対して割り当てられている。アルバムタイトル、アーティスト名、ＣＭ等の文字情報が付加情報として記録される。
【００８７】
図１５は、付加情報キーコードの値（６４〜１２７）と、付加情報の種類の対応の一例を示す。キーコードの値（６４〜９５）がパス／その他に対して割り当てられ、その（９６〜１２７）が制御／数値・データ関係に対して割り当てられている。
例えば（ＩＤ＝９８）の場合では、付加情報がＴＯＣ−ＩＤとされる。ＴＯＣ−ＩＤは、ＣＤ（コンパクトディスク）のＴＯＣ情報に基づいて、最初の曲番号、最後の曲番号、その曲番号、総演奏時間、その曲演奏時間を示すものである。
【００８８】
図１６は、付加情報キーコードの値（１２８〜１５９）と、付加情報の種類の対応の一例を示す。キーコードの値（１２８〜１５９）が同期再生関係に対して割り当てられている。図１６中のＥＭＤ(Electronic Music Distribution）は、電子音楽配信の意味である。
【００８９】
図１７を参照して付加情報のデータの具体例について説明する。図１７（ａ）は、図１３と同様に、付加情報のデータ構成を示す。
図１７（ｂ）は、キーコードＩＤ＝３とされる、付加情報がアーティスト名の例である。ＳＩＺＥ＝０ｘ１Ｃ（２８バイト）とされ、ヘッダを含むこの付加情報のデータ長が２８バイトであることが示される。また、Ｃ＋Ｌが文字コードＣ＝０ｘ０１とされ、言語コードＬ＝０ｘ０９とされる。この値は、前述した規定によって、ＡＳＣＩＩの文字コードで、英語の言語であることを示す。そして、先頭から１２バイト目から１バイトデータでもって、「ＳＩＭＯＮ＆ＧＲＡＦＵＮＫＥＬ」のアーティスト名のデータが書かれる。付加情報のサイズは、４バイトの整数倍と決められているので、１バイトの余りが（０ｘ００）とされる。
【００９０】
図１７（ｃ）は、キーコードＩＤ＝９７とされる、付加情報がＩＳＲＣ(International Standard Recording Code：著作権コード) の例である。ＳＩＺＥ＝０ｘ１４（２０バイト）とされ、この付加情報のデータ長が２０バイトであることが示される。また、Ｃ＋ＬがＣ＝０ｘ００、Ｌ＝０ｘ００とされ、文字、言語の設定が無いこと、すなわち、データが２進数であることが示される。そして、データとして８バイトのＩＳＲＣのコードが書かれる。ＩＳＲＣは、著作権情報（国、所有者、録音年、シリアル番号）を示すものである。
【００９１】
図１７（ｄ）は、キーコードＩＤ＝９７とされる、付加情報が録音日時の例である。ＳＩＺＥ＝０ｘ１０（１６バイト）とされ、この付加情報のデータ長が１６バイトであることが示される。また、Ｃ＋ＬがＣ＝０ｘ００、Ｌ＝０ｘ００とされ、文字、言語の設定が無いことが示される。そして、データとして４バイト（３２ビット）のコードが書かれ、録音日時（年、月、日、時、分、秒）が表される。
【００９２】
図１７（ｅ）は、キーコードＩＤ＝１０７とされる、付加情報が再生ログの例である。ＳＩＺＥ＝０ｘ１０（１６バイト）とされ、この付加情報のデータ長が１６バイトであることが示される。また、Ｃ＋ＬがＣ＝０ｘ００、Ｌ＝０ｘ００とされ、文字、言語の設定が無いことが示される。そして、データとして４バイト（３２ビット）のコードが書かれ、再生ログ（年、月、日、時、分、秒）が表される。再生ログ機能を持つものは、１回の再生毎に１６バイトのデータを記録する。
【００９３】
３−５ データファイル
図１８は、１ＳＵがＮバイト（例えばＮ＝３８４バイト）の場合のＡＴＲＡＣ３データファイル（Ａ３Ｄｎｎｎｎ）のデータ配列を示す。
図１８には、図８で示したようなデータファイルとして、属性ヘッダとしてのブロックと、実際に音楽データが記録されるブロックとが示されている。
図１８には各ブロック（１６×２＝３２Ｋバイト）の各スロットの先頭のバイト（０ｘ００００〜０ｘ７ＦＦ０）が示されている。
【００９４】
図１８に示すように、属性ヘッダの先頭から３２バイトはヘッダとされ、２５６バイトが曲名領域ＮＭ１（２５６バイト）であり、５１２バイトが曲名領域ＮＭ２（５１２バイト）である。
属性ヘッダのヘッダには、下記のデータが書かれる。
【００９５】
ＢＬＫＩＤ−ＨＤ０（４バイト）
意味：BLOCKID FILE ID
機能：ＡＴＲＡＣ３データファイルの先頭であることを識別するための値。
値：固定値＝”ＨＤ＝０”（例えば０ｘ４８４４２Ｄ３０）
ＭＣｏｄｅ（２バイト）
意味：MAKER CODE
機能：記録した機器の、メーカー、モデルを識別するコード。
値：上位１０ビット（メーカーコード） 下位６ビット（機種コード）
ＢＬＯＣＫ ＳＥＲＩＡＬ（４バイト）
意味：トラック毎に付けられた連続番号
機能：ブロックの先頭は０から始まり次のブロックは＋１づつインクリメント編集されても値を変化させない。
値：０より始まり０ｘＦＦＦＦＦＦＦＦまで。
【００９６】
Ｎ１Ｃ＋Ｌ（２バイト）
意味：トラック（曲名）データ（ＮＭ１）の属性
機能：ＮＭ１に使用される文字コードと言語コードを各１バイトで表す。
値：ＳＮ１Ｃ＋Ｌと同一
Ｎ２Ｃ＋Ｌ（２バイト）
意味：トラック（曲名）データ（ＮＭ２）の属性
機能：ＮＭ２に使用される文字コードと言語コードを各１バイトで表す。
値：ＳＮ１Ｃ＋Ｌと同一
ＩＮＦＳＩＺＥ（２バイト）
意味：トラックに関する付加情報の全てを合計したサイズ
機能：データサイズを１６バイト単位の大きさで記述。無い場合は必ずオールゼロとする。
値：サイズは０ｘ００００から０ｘ３Ｃ６（９６６）
Ｔ−ＰＲＴ（２バイト）
意味：トータルパーツ数
機能：トラックを構成するパーツ数を表す。通常は１。
値：１から０ｘ２８５（６４５dec ）
Ｔ−ＳＵ（４バイト）
意味：トータルＳＵ数
機能：１トラック中の実際の総ＳＵ数を表す。曲の演奏時間に相当する。
値：０ｘ０１から０ｘ００１ＦＦＦＦＦ
ＩＮＸ（２バイト）（Ｏｐｔｉｏｎ）
意味：INDEX の相対場所
機能：曲のさびの部分（特徴的な部分）の先頭を示すポインタ。曲の先頭からの位置をＳＵの個数を１／４した数で指定する。これは、通常のＳＵの４倍の長さの時間（約９３ｍ秒）に相当する。
値：０から０ｘＦＦＦＦ（最大、約６０８４秒）
ＸＴ（２バイト）（Ｏｐｔｉｏｎ）
意味：INDEX の再生時間
機能：ＩＮＸ-nnnで指定された先頭から再生すべき時間のＳＵの個数を１／４した数で指定する。これは、通常のＳＵの４倍の長さの時間（約９３ｍ秒）に相当する。
値：０ｘ００００：無設定 ０ｘ０１から０ｘＦＦＦＥ（最大６０８４秒）
０ｘＦＦＦＦ：曲の終わりまで。
【００９７】
次に属性ヘッダにおける曲名領域ＮＭ１およびＮＭ２について説明する。
【００９８】
ＮＭ１
意味：曲名を表す文字列
機能：１バイトの文字コードで表した可変長の曲名（最大で２５６）。
名前データの終了は、必ず終端コード（０ｘ００）を書き込む。
サイズはこの終端コードから計算する。データの無い場合は少なくとも先頭（０ｘ００２０）からヌル（０ｘ００）を１バイト以上記録する。
値：各種文字コード
ＮＭ２
意味：曲名を表す文字列
機能：２バイトの文字コードで表した可変長の名前データ（最大で５１２）。
名前データの終了は、必ず終端コード（０ｘ００）を書き込む。
サイズはこの終端コードから計算する。データの無い場合は少なくとも先頭（０ｘ０１２０）からヌル（０ｘ００）を２バイト以上記録する。
値：各種文字コード。
【００９９】
属性ヘッダの固定位置（０ｘ０３２０）から始まる、８０バイトのデータをトラック情報領域ＴＲＫＩＮＦと呼び、主としてセキュリティ関係、コピー制御関係の情報を一括して管理する。ＴＲＫＩＮＦ内のデータについて、配置順序に従って以下に説明する。
【０１００】
ＣＯＮＴＥＮＴＳ ＫＥＹ（８バイト）
意味：曲毎に用意された値で、メモリカードのセキュリティブロックで保護されてから保存される。
機能：曲を再生する時、まず必要となる最初の鍵となる。Ｃ−ＭＡＣ［ｎ］計算時に使用される。
値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦまで
Ｃ−ＭＡＣ［ｎ］（８バイト）
意味：著作権情報改ざんチェック値
機能：コンテンツ累積番号を含む複数のＴＲＫＩＮＦの内容と隠しシーケンス番号から作成される値。
隠しシーケンス番号とは、メモリカードの隠し領域に記録されているシーケンス番号のことである。著作権対応でないレコーダは、隠し領域を読むことができない。また、著作権対応の専用のレコーダ、またはメモリカードを読むことを可能とするアプリケーションを搭載したパーソナルコンピュータは、隠し領域をアクセスすることができる。
【０１０１】
Ａ（１バイト）
意味：パーツの属性
機能：パーツ内の圧縮モード等の情報を示す
値：図１９を参照して以下に説明する
ただし、Ｎ＝０，１のモノラルは、ｂｉｔ７が１でサブ信号を０、メイン信号（Ｌ＋Ｒ）のみの特別なＪｏｉｎｔモードをモノラルとして規定する。ｂｉｔ２，１の情報は通常の再生機は無視しても構わない。
【０１０２】
Ａのビット０は、エンファシスのオン／オフの情報を形成し、ビット１は、再生ＳＫＩＰか、通常再生かの情報を形成し、ビット２は、データ区分、例えばオーディオデータか、ＦＡＸ等の他のデータかの情報を形成する。
ビット３は、未定義である。
ビット４、５、６を組み合わせることによって、図示のように、レート情報が規定される。
すなわち、Ｎは、この３ビットで表されるレートの値であり、モノ（Ｎ＝０，１），ＬＰ（Ｎ＝２），ＳＰ（Ｎ＝４），ＥＸ（Ｎ＝５，６），ＨＱ（Ｎ＝７）の５種類のモードについて、記録時間（６４ＭＢのメモリカードの場合）、データ転送レート、１ブロック内のＳＵ数、１ＳＵのバイト数がそれぞれ示されている。
ビット７は、ＡＴＲＡＣ３のモード（０：Dual １：Joint ）が示される。
【０１０３】
一例として、６４ＭＢのメモリカードを使用し、ＳＰモードの場合について説明する。６４ＭＢのメモリカードには、３９６８ブロックがある。ＳＰモードでは、１ＳＵが３０４バイトであるので、１ブロックに５３ＳＵが存在する。１ＳＵは、（１０２４／４４１００）秒に相当する。従って、１ブロックは、
（１０２４／４４１００）×５３×（３９６８−１６）＝４８６３秒＝８１分
転送レートは、
（４４１００／１０２４）×３０４×８＝１０４７３７ bps
となる。
【０１０４】
ＬＴ（１バイト）
意味：再生制限フラグ（ビット７およびビット６）とセキュリティバージョン（ビット５〜ビット０）
機能：このトラックに関して制限事項があることを表す。
値：ビット７： ０＝制限なし １＝制限有り
ビット６： ０＝期限内 １＝期限切れ
ビット５〜ビット０：セキュリティバージョン０（０以外であれば再生禁止とする）
ＦＮｏ（２バイト）
意味：ファイル番号
機能：最初に記録された時のトラック番号であり、且つこの値は、メモリカード内の隠し領域に記録されたＭＡＣ計算用の値の位置を特定する。
値：１から０ｘ１９０（４００）
ＭＧ（Ｄ）ＳＥＲＩＡＬ−ｎｎｎ（１６バイト）
意味：記録機器のセキュリティブロック（セキュリティＩＣ２０）のシリアル番号。
機能：記録機器ごとに全て異なる固有の値。
値：０から0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
ＣＯＮＮＵＭ（４バイト）
意味：コンテンツ累積番号
機能：曲毎に累積されていく固有の値で記録機器のセキュリティブロックによって管理される。２の３２乗、４２億曲分用意されており、記録した曲の識別に使用する。
【０１０５】
値：０から０ｘＦＦＦＦＦＦＦＦ。
【０１０６】
ＹＭＤｈｍｓ−Ｓ（４バイト）（Ｏｐｔｉｏｎ）
意味：再生制限付きのトラックの再生開始日時
機能：ＥＭＤで指定する再生開始を許可する日時。
値：上述した日時の表記と同じ。
ＹＭＤｈｍｓ−Ｅ（４バイト）（Ｏｐｔｉｏｎ）
意味：再生制限付きのトラックの再生終了日時
機能：ＥＭＤで指定する再生許可を終了する日時。
値：上述した日時の表記と同じ。
ＭＴ（１バイト）（Ｏｐｔｉｏｎ）
意味：再生許可回数の最大値
機能：ＥＭＤで指定される最大の再生回数。
値：１から０ｘＦＦ 未使用の時は、０ｘ００である。
ＬＴのｂｉｔ７の値が０の場合はＭＴの値は００とする。
ＣＴ（１バイト）（Ｏｐｔｉｏｎ）
意味：再生回数
機能：再生許可された回数の内で、実際に再生できる回数。再生の度にデクリメントする。
値：０ｘ００〜０ｘＦＦ 未使用の時は、０ｘ００である。
ＬＴのｂｉｔ７が１でＣＴの値が００の場合は再生を禁止する。
【０１０７】
ＣＣ（１バイト）
意味：COPY CONTROL
機能：コピー制御
値：図２０に示すように、ビット６および７によってコピー制御情報を表し、ビット４および５によって高速ディジタルコピーに関するコピー制御情報を表し、ビット１，２，３によってコピー属性を表す。ビット０は未定義である。
ＣＣの例：
ビット７・・・０：コピー禁止、１：コピー許可
ビット６・・・０：オリジナル、１：第１世代以上
ビット５，４・・・００：コピー禁止、０１：コピー第１世代、１０：コピー可
ビット３，２，１
００１：オリジナルソースから記録したコンテンツであることを示す。
０１０：ＬＣＭからコピーしたコンテンツであることを示す。
０１１：ＬＣＭからムーブしたコンテンツであることを示す。
１００以上：未定義。
なおＬＣＭとは、Licensed Compliant Moduleであり、例えばパーソナルコンピュータやコンシューマ機器におけるＨＤＤなどが相当する。
例えばＣＤからのディジタル録音では（ｂｉｔ７，６）は０１、（ｂｉｔ５，４）は００、（ｂｉｔ３，２，１）は００１或いは０１０となる。
【０１０８】
ＣＮ（１バイト）（Ｏｐｔｉｏｎ）
意味：高速ディジタルコピーＨＳＣＭＳ(High speed Serial Copy Management System)におけるコピー許可回数
機能：コピー１回か、コピーフリーかの区別を拡張し、回数で指定する。コピー第１世代の場合にのみ有効であり、コピーごとに減算する。
値：００：コピー禁止、０１から０ｘＦＥ：回数、０ｘＦＦ：回数無制限。
【０１０９】
データファイルにおける属性ヘッダにおいては、以上のようなトラック情報領域ＴＲＫＩＮＦに続いて、０ｘ０３７０から始まる２４バイトのデータをパーツ管理用のパーツ情報領域ＰＲＴＩＮＦと呼び、１つのトラックを複数のパーツで構成する場合に、時間軸の順番にＰＲＴＩＮＦを並べていく。ＰＲＴＩＮＦ内のデータについて、配置順序に従って以下に説明する。
【０１１０】
ＰＲＴＳＩＺＥ（４バイト）
意味：パーツサイズ
機能：パーツの大きさを表す。クラスタ：２バイト（最上位）、開始ＳＵ：１バイト（上位）、終了ＳＵ：１バイト（最下位）
値：クラスタ：１から０ｘ１Ｆ４０（８０００）、開始ＳＵ：０から０ｘＡ０（１６０）、終了ＳＵ：０から０ｘＡ０（１６０）（但し、ＳＵの数え方は、０，１，２，と０から開始する）
ＰＲＴＫＥＹ（８バイト）
意味：パーツを暗号化するための値
機能：初期値＝０、編集時は編集の規則に従う。
値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦ
ＣＯＮＮＵＭ０（４バイト）
意味：最初に作られたコンテンツ累積番号キー
機能：コンテンツをユニークにするためのＩＤの役割。
値：コンテンツ累積番号初期値キーと同じ値とされる。
【０１１１】
ＡＴＲＡＣ３データファイルの属性ヘッダ中には、図１８に示すように、付加情報ＩＮＦが含まれる。この付加情報は、開始位置が固定化されていない点を除いて、再生管理ファイル中の付加情報ＩＮＦ−Ｓ（図１２参照）と同一である。１つまたは複数のパーツの最後のバイト部分（４バイト単位）の次を開始位置として付加情報ＩＮＦのデータが開始する。
【０１１２】
ＩＮＦ
意味：トラックに関する付加情報データ
機能：ヘッダを伴った可変長の付加情報データ。複数の異なる付加情報が並べられることがある。それぞれにＩＤとデータサイズが付加されている。個々のヘッダを含む付加情報データは、最小１６バイト以上で４バイトの整数倍の単位
値：再生管理ファイル中の付加情報ＩＮＦ−Ｓと同じである。
【０１１３】
以上のような属性ヘッダに対して、ＡＴＲＡＣ３データが記録される各ブロックのデータが続く。図８にも示したように、ブロック毎にヘッダが付加される。図１８に示す、ブロック内のデータについて以下に説明する。
【０１１４】
ＢＬＫＩＤ−Ａ３Ｄ（４バイト）
意味：BLOCKID FILE ID
機能：ＡＴＲＡＣ３データの先頭であることを識別するための値。
値：固定値＝”Ａ３Ｄ”（例えば０ｘ４１３３４４２０）
ＭＣｏｄｅ（２バイト）
意味：MAKER CODE
機能：記録した機器の、メーカー、モデルを識別するコード。
値：上位１０ビット（メーカーコード） 下位６ビット（機種コード）
ＣＯＮＮＵＭ０（４バイト）
意味：最初に作られたコンテンツ累積番号
機能：コンテンツをユニークにするためのＩＤの役割、編集されても値は変化させない。
値：コンテンツ累積番号初期値キーと同じ値とされる。
ＢＬＯＣＫ ＳＥＲＩＡＬ（４バイト）
意味：トラック毎に付けられた連続番号
機能：ブロックの先頭は０から始まり次のブロックは＋１づつインクリメント編集されても値を変化させない。
値：０より始まり０ｘＦＦＦＦＦＦＦＦまで。
ＢＬＯＣＫ−ＳＥＥＤ（８バイト）
意味：１ブロックを暗号化するための１つの鍵
機能：ブロックの先頭は、記録機器のセキュリティブロックで乱数を生成、続くブロックは、＋１インクリメントされた値。この値が失われると、１ブロックに相当する約１秒間、音が出せないために、ヘッダとブロック末尾に同じものが二重に書かれる。編集されても値を変化させない。
値：初期は８バイトの乱数。
ＩＮＩＴＩＡＬＩＺＡＴＩＯＮ ＶＥＣＴＯＲ（８バイト）
意味：ブロック毎にＡＴＲＡＣ３データを暗号化、復号化する時に必要な初期値
機能：ブロックの先頭は０から始まり、次のブロックは最後のＳＵの最後の暗号化された８バイトの値。デバイドされたブロックの途中からの場合は開始ＳＵの直前の最後の８バイトを用いる。編集されても値を変化させない。
値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦ
ＳＵ−ｎｎｎ
意味：サウンドユニットのデータ
機能：１０２４サンプルから圧縮されたデータ、圧縮モードにより出力されるバイト数が異なる。編集されても値を変化させない（一例として、ＳＰモードの時では、Ｎ＝３８４バイト）。
値：ＡＴＲＡＣ３のデータ値。
【０１１５】
図１８では、Ｎ＝３８４であるので、１ブロックに４２ＳＵが書かれる。また、１ブロックの先頭の２つのスロット（４バイト）がヘッダとされ、最後の１スロット（２バイト）にＢＬＫＩＤ−Ａ３Ｄ、ＭＣｏｄｅ、ＣＯＮＮＵＭ０、ＢＬＯＣＫ ＳＥＲＩＡＬが二重に書かれる。従って、１ブロックの余りの領域Ｍバイトは、（１６，３８４−３８４×４２−１６×３＝２０８（バイト）となる。この中に上述したように、８バイトのＢＬＯＣＫ ＳＥＥＤが二重に記録される。
【０１１６】
４．記録処理
４−１ 処理例１
以下、本例のレコーダ１によるコンテンツ（曲）の記録動作時の処理例について説明していく。
上述してきた説明から理解されるように、メモリカード４０に対するコンテンツの記録は、コンテンツデータの記録だけではなく、１ブロック（１クラスタ）分の容量である再生管理ファイルの生成又は更新があって、完了するものである。またコンテンツのデバイド、コンバイン等の編集は再生管理ファイルの更新によって実現される。
また、メモリカード４０上での再生管理ファイルの記録位置（絶対アドレス）は、再生管理ファイルの更新のための書込のたびに異なる位置とされていく。
さらに、デバイド編集が行われる場合は、１クラスタ（１ブロック）を新たに使用することが必要となる。
【０１１７】
このような事情から、もしコンテンツの記録をメモリカードの全ての容量に対して行ってしまうと、その記録動作にかかる再生管理ファイルの作成又は更新ができなくなる。或いは、コンテンツと再生管理ファイルを含めてメモリカードの全ての容量を使い切ってしまうと、その後、デバイド等の編集ができないものとなってしまう。
そこで本例では、記録動作時には、或る程度の容量が残されるようにして記録が終了するようにするものである。
ただ、このような処理により、コンテンツを記録できる容量が、残される容量の分だけ減ることになるため、残される容量は適切な量としなければならない。
【０１１８】
一般に平均的な演奏時間の音楽を記録する場合、１つの記録媒体（メモリカード）の曲数（コンテンツ数）は２０曲程度までとなる。
また、ＦＭ放送等を１時間分録音した場合は、その１時間分のデータは１つのコンテンツとして扱われる。ユーザーは、録音した放送からデバイドによって、各曲を分割する操作を行う。
これらの事情から、２０回程度のデバイドが行われる可能性が高いとして、例えば２０クラスタ（２０ブロック）分程度を、上記の残される容量とする方式が考えられる。
また、既に１０曲（３０分）のコンテンツが記録されているような状態では、統計的にはあと１０クラスタ（１０ブロック）分程度を、上記の残される容量とすれば、その後のデバイド編集などに、ほぼ対応できると推定できる。そこで、記録開始時に、既に記録されているコンテンツ数に応じて、残される容量を設定する方式も考えられる。
或いは、既に記録されているコンテンツの平均的なサイズと全容量の関係から残される容量を設定するようにしてもよい。
大まかにいえば、メモリカードにおいてコンテンツ数が少なくその各コンテンツのサイズが大きい場合は、その後に何回か編集される可能性が高くなるため、その傾向に応じて、残される容量を設定すると好適である。
【０１１９】
いづれにしても本例では、記録後における編集回数の可能性に応じて、残される容量が設定されるようにする。
【０１２０】
レコーダ１のＤＳＰ３０が、ライン入力セレクタ１３又はデジタル入力セレクタ１６から入力され、オーディオエンコーダ／デコーダ１０でエンコード処理、セキュリティＩＣ２０で暗号化処理が施されたデータを、メモリカード４０に記録していく際の処理を図２１に示す。
【０１２１】
記録が開始される際には、ＤＳＰ３０は、まずステップＦ１０１で、装填されているメモリカード４０の管理情報（再生管理ファイル）から、メモリカード４０に既にコンテンツ（データファイル）が記録されているか否かを判別する。
まだ１つもデータファイルが記録されていないメモリカード４０であった場合は、処理をステップＦ１０２に進め、変数Ｌに「２０」をセットする。
これは上述のように、通常、２０曲程度の収録状態が考えられ、換言すれば２０回程度のデバイドが行われる可能性が考えられるためである。もちろん「２０」という値は一例にすぎず、メモリカードの容量等に応じて適切な値が設定されるべきである。また、この「２０」に相当する値を、ユーザーが自分の事情や記録内容、例えば編集を何回も行うか否かに合わせて、任意に増減できるようにしてもよい。
【０１２２】
そしてステップＦ１０８で、Ｌクラスタ、即ちこの場合は２０クラスタ（２０ブロック）分を、余りブロックとして確保する。
ここでいう余りブロックとは、上述した残される容量のことであり、つまり記録終了時点で残されるべき容量としてのブロック数である。
【０１２３】
メモリカード４０にすでに１つ以上のデータファイルが記録されていた場合は、ＤＳＰ３０の処理はステップＦ１０３に進み、記録されているデータファイルの平均ファイルサイズＭを算出する。
これは、既にデータファイルの記録に使用されている容量を、データファイル数で割れば算出できる。
平均ファイルサイズＭが算出できたら、ステップＦ１０４で、メモリカード４０の全容量を平均ファイルサイズＭで割って、予測総ファイル数Ｎを算出する。
予測総ファイル数Ｎとは、メモリカード４０の全容量を使用した場合に、いくつのデータファイルが記録されているかの予測値である。
【０１２４】
そしてＤＳＰ３０はステップＦ１０５で予測総ファイル数Ｎが「２０」以下であるか否かを判別する。ここでの「２０」も、一般的な平均としての収録曲数として用いており、「２０」に限定されるものではない。
【０１２５】
予測総ファイル数Ｎが「２０」以下である場合は、２０曲は記録される可能性があると判断して、ステップＦ１０６で、「２０」から既に記録されているデータファイル数を減算した値を、変数Ｌにセットする。
そしてステップＦ１０８で、Ｌクラスタ（Ｌブロック）分を、余りブロックとして確保する。
【０１２６】
一方、ステップＦ１０５で、予測総ファイル数Ｎが「２０」を越えているとされた場合は、予測総ファイル数Ｎの数だけデータファイルが記録される可能性があると判断して、ステップＦ１０７で、予測総ファイル数Ｎから既に記録されているデータファイル数を減算した値を、変数Ｌにセットする。
そしてステップＦ１０８で、Ｌクラスタ（Ｌブロック）分を、余りブロックとして確保する。
【０１２７】
ステップＦ１０８として余りブロックが設定されたら、ステップＦ１０９からオーディオデータによるデータファイルの記録を開始する。
データファイルは上述したようにブロック単位で記録されていくことになる。
【０１２８】
記録動作中は、ステップＦ１１０で、余りブロックを除いてメモリカード４０における記録可能な残り容量がゼロになったか否かを監視している。
またステップＦ１１１では、記録終了、即ちユーザの指示した１又は複数のデータファイルの記録が完了したか、或いはユーザーが操作部３９から記録停止操作を行ったことなどにより記録が終了されるものとなったか、を監視する。
さらにステップＦ１１２では、供給されているオーディオデータとして、ファイルチェンジ、即ち曲が変わって、別のデータファイルの記録に移行することになったかを監視する。
このファイルチェンジ、即ち曲の変化は、例えばＭＤ、ＣＤ等の記録媒体から曲がデジタルオーディオデータとして供給されている場合において、そのデジタルデータ内に含まれているトラックナンバ情報を監視することなどで可能となる。また、ライン入力セレクタ１３からのアナログオーディオ信号について記録している場合でも、例えば無音期間の検出などにより、ファイルチェンジと判断するようにしてもよい。
【０１２９】
ステップＦ１１０で肯定結果がでるより前に、ステップＦ１１１で記録終了となった場合は、ＤＳＰ３０はステップＦ１１８で、記録したコンテンツについての再生管理ファイルの作成（又は更新）を行って、記録処理を終える。
この場合は、メモリカード４０における記録可能な容量は、その後の記録や編集のためには、まだ十分に残されている状態である。
【０１３０】
記録動作中においてステップＦ１１２で、記録するオーディオデータについてのファイルチェンジが検出された場合は、そのファイルチェンジポイントまでのオーディオデータが記録されたブロックで、１つのデータファイルが形成されることになる。
そこでステップＦ１１３で変数Ｌをデクリメントし、その時点で変数Ｌが「１」よりも大きければ、ステップＦ１０８に戻って、Ｌクラスタ分を余りブロックとして確保する。つまり余りブロックとしての設定を１ブロック少なくする。
これは、１つのデータファイルが記録されたことで、その後のデバイド回数の可能性が１回減ったと考えることができるためである。
そして、ステップＦ１０９から新たなデータファイルとして、続くオーディオデータを新たなブロックの先頭とした上で、その後の記録を行っていく。
【０１３１】
なお、記録中に１９回トラックチェンジが検出されると、ステップＦ１１４の時点で変数Ｌ＝０となる。
そしてこれは、続くオーディオデータが、２０曲目として記録されていく場合である。この場合、録音後においてデバイド編集が行われる可能性がきわめて低いものとなるため、それだけを考えれば、変数Ｌ＝０となることに応じて、余りブロックをゼロとしてしまってもよいが、実際には録音後に再生管理ファイルの書込が必要となるため、少なくとも録音終了時点で１ブロックは残されていなければならない。
そこで、ステップＦ１１４で変数Ｌが１未満（つまり０）となった場合は、ステップＦ１１６で、変数Ｌ＝１として、ステップＦ１０８で少なくとも１ブロックは余りブロックとして確保されるようにする。
また、この場合、余りブロックが記録終了後の再生管理ファイルの書込に用いられ、それによってメモリカード４０の全容量が消費されると、その後の編集はできないものとなる。
そこで、ステップＦ１１５では、ユーザーに対して記録終了後の編集ができなくなるおそれがあることを提示する。例えば表示部３３にその旨のメッセージを表示する。但し、その後、ステップＦ１１０で肯定結果が出る前に、ステップＦ１１１で記録終了と判断された場合、即ち余りブロック以外にも記録可能なブロックが残されている場合は、まだ記録又は編集が可能であるため、この時点では必ずしも警告表示を行わなくてもよい。
【０１３２】
ステップＦ１１０において、その時点で余りエリアとして設定されているブロック数を残して、他に記録可能なブロックが使い切られてしまったと判断された場合は、ＤＳＰ３０はステップＦ１１７に進み、強制的に記録動作を停止する。
そしてステップＦ１１８で記録したコンテンツについての再生管理ファイルの作成（又は更新）を行って、記録処理を終える。
この場合は、メモリカード４０における記録可能な容量は、余りエリアとして設定されていたブロック数のみが残されている状態である。
そしてその余りブロックとしてのブロック数は、上述したように、通常２０曲が収録されること、平均データサイズと全容量の関係から収録曲数が推定されること、及びそれらの収録曲数から、既に収録済みの曲数が減算されることなどに応じて設定される。さらに記録中に曲が分かれれば（ファイルチェンジ）、余りブロック数はデクリメントされていく。
これらのことから、記録終了時点で、その後に少なくとも一般的に予測されるだけの編集回数は、編集可能とするに足りるブロック数となる。
従って、コンテンツ記録時に、ユーザーがメモリカード４０の記録可能エリアを使い切ってしまったと感じる場合でも、少なくとも通常必要となる回数の編集は、可能とされることになり、ユーザーに不都合を感じさせるものではなくなる。
また一方で、上記のように余りブロック数が変数Ｌに応じて設定され、また記録中にデクリメントされることで、余りブロック数は、通常必要とされる編集回数を、コンテンツ記録状況に応じて、最低限の回数として設定されるものとなる。これは、余りブロック数を多く設定しすぎて、それによりコンテンツの記録可能容量を必要以上に小さくしてしまうものではないことを意味する。
つまり、本例の記録処理により、なるべくコンテンツの記録容量は減少させないようにした上で、その後に必要とされる編集は実行可能な状態とすることができる。
【０１３３】
なお、上述のように余りブロックが１ブロックまで減ぜられた状態で、ステップＦ１１０，Ｆ１１７で記録が終了されると、その余りブロックとされた１ブロックは、再生管理ファイルの記録に用いられるものとなり、その時点で全てのブロックが使用済みとなる。つまり以降は、編集ができない。（本例の考え方によれば、この場合は、２０或いはそれ以上の曲数に既に分割されているため、デバイド編集の必要がない状態となっている）。
そこで、ステップＦ１１５として説明した警告処理は、このような場合に実行するようにしてもよい。
またその時点で、編集操作を無効とする編集禁止処理を行ってもよい。
なお、この場合において、再生管理ファイルが新規に或るブロックに記録されるのではなく、いままでの再生管理ファイルが「更新」される場合は、旧再生管理ファイルが記録されていたブロックは、書込可能なブロックとなる。
従って、コンバイン、ムーブ、イレーズなど、再生管理ファイルの更新のみで実現される編集は可能である。
そこで、そのような場合は、上記警告や編集禁止処理は、デバイド編集に限ったものとして行ってもよい。
【０１３４】
ところで、以上の処理の説明では、記録終了時点のステップＦ１１８での再生管理ファイルの書込に用いるブロックも、少なくとも余りブロックとして確保されるものとして説明したが、ステップＦ１１８での再生管理ファイルの書込に用いるブロックは、「余りブロック」とは別に確保されているとして、図２１の処理を考えてもよい。
その場合、上記のように余りブロックが１ブロックまで減ぜられた状態で、ステップＦ１１０，Ｆ１１７で記録が終了され、再生管理ファイルの記録が行われても、余りブロックとされた１ブロックは残されている。従って、コンバイン、ムーブ、イレーズなど、再生管理ファイルの更新のみで実現される編集は可能である。またさらに再生管理ファイルが更新された場合は、旧再生管理ファイルの記録されていたブロックも書込可能となるため、２ブロックが書き込み可能であり、デバイドも可能である。
従って、上記警告表示や編集禁止処理は、これらの事情に応じて行うことが好ましい。
【０１３５】
また、図２１の処理例では、ファイルチェンジに応じて余りブロック数が単純に減ぜられていくようにしたが、ファイルチェンジのタイミングまでのオーディオデータで形成されたデータファイルを含めて、ステップＦ１０３〜Ｆ１０７のような平均ファイルサイズと全容量に応じた余りブロック設定が行われるようにして、余りブロックの設定が変化されていくようにしてもよい。
【０１３６】
４−２ 処理例２
続いて図２２で、処理例２としての記録処理を説明する。
なお図２２において、上記図２１と同一の処理については、ステップＦ１０１〜Ｆ１１８として同一ステップ番号を付し、説明を省略する。
即ちこの処理例２は、上記図２１の処理に、ステップＦ１００及びＦ１１９〜１２１が追加されたものである。
【０１３７】
この場合は、ユーザーが、記録後における編集を可能とするために余りブロックを設定するか、或いは、そのようなことを考慮せずに、できるだけコンテンツの記録可能容量を多くするかを選択できるようにしたものである。
つまりユーザーは、例えば操作部３９からの操作により、余りブロック量を除いた記録可能なブロック残量がゼロとなったら記録動作を終了させる動作モードと、メモリカード４０上で記録可能なブロック残量がゼロとなるまで記録動作を続行可能とする動作モード（使い切り設定）とを選択できるようにしている。
【０１３８】
ユーザーが、使い切り設定を行わずに記録を開始させた場合は、ＤＳＰ３０の記録処理は図２１と同様の処理となる（Ｆ１０１〜Ｆ１１８）。
ところがユーザーが使い切り設定を行って記録動作を開始させた場合は、ＤＳＰ３０はステップＦ１１９，Ｆ１２０，Ｆ１２１の処理を行う。
即ちステップＦ１１９からオーディオデータによるデータファイルの記録を開始する。データファイルはブロック単位で記録されていくことになる。
【０１３９】
そして記録動作中は、ステップＦ１２０で、メモリカード４０における記録可能な残り容量が残り１ブロックになったか否かを監視している。
またステップＦ１２１では、記録終了、即ちユーザの指示した１又は複数のデータファイルの記録が完了したか、或いはユーザーが操作部３９から記録停止操作を行ったことなどにより記録が終了されるものとなったか、を監視する。
なお、記録中に供給されているオーディオデータとして、ファイルチェンジが検出された場合は、そのファイルチェンジポイントまでのオーディオデータが記録されたブロックで、１つのデータファイルが形成される。そして新たなデータファイルとして、続くオーディオデータを新たなブロックの先頭とした上で、その後の記録を行っていく。
【０１４０】
ステップＦ１２０で肯定結果がでるより前に、ステップＦ１２１で記録終了となった場合は、ＤＳＰ３０はステップＦ１１８で、記録したコンテンツについての再生管理ファイルの作成（又は更新）を行って、記録処理を終える。
この場合は、メモリカード４０における記録可能な容量は、その後の記録や編集のためには、まだ十分に残されている状態である。
【０１４１】
ステップＦ１２０において、その時点で１ブロック数を残して、記録可能なブロックが使い切られてしまったと判断された場合は、ＤＳＰ３０はステップＦ１１７に進み、強制的に記録動作を停止する。
そしてステップＦ１１８で、残りの１ブロックに対して、記録したコンテンツについての再生管理ファイルの作成（又は更新）を行って、記録処理を終える。
この場合は、メモリカード４０における記録可能な容量が最大限、コンテンツの記録に用いられたことになる。
つまりこの処理例２では、ユーザーの選択によって、もし記録後の編集を考えない場合であるなら、メモリカード４０の容量をコンテンツの記録に最大限利用できるようにするものである。
【０１４２】
４−３ 処理例３
図２３に処理例３を示す。
この処理例は、余りブロックの設定を固定化したもので、また記録終了時点では、少なくとも固定値の余りブロックとしてのブロック数は、記録可能として確保されるようにした例である。
【０１４３】
即ち記録が開始される際には、ＤＳＰ３０はステップＦ２０１で、或る設定された固定値としてｘクラスタ分を余りブロックとして設定する。
そしてステップＦ２０２からオーディオデータによるデータファイルの記録を開始する。データファイルはブロック単位で記録されていく。
【０１４４】
そして記録動作中は、ステップＦ２０３で、メモリカード４０における記録可能な残り容量が、ｘ個の余りブロックを除いてゼロとなったか否かを監視し、またステップＦ２０４では、記録終了、即ちユーザの指示した１又は複数のデータファイルの記録が完了したか、或いはユーザーが操作部３９から記録停止操作を行ったことなどにより記録が終了されるものとなったか、を監視する。
なお、記録中に供給されているオーディオデータとして、ファイルチェンジが検出された場合は、そのファイルチェンジポイントまでのオーディオデータが記録されたブロックで、１つのデータファイルが形成される。そして新たなデータファイルとして、続くオーディオデータを新たなブロックの先頭とした上で、その後の記録を行っていく。
【０１４５】
ステップＦ２０３で肯定結果がでるより前に、ステップＦ２０４で記録終了となった場合は、ＤＳＰ３０はステップＦ２０６で、記録したコンテンツについての再生管理ファイルの作成（又は更新）を行って、記録処理を終える。
この場合は、メモリカード４０における記録可能な容量は、その後の記録や編集のためには、まだ十分に残されている状態である。
【０１４６】
ステップＦ２０３において、その時点でｘブロック数を残して、記録可能なブロックが使い切られてしまったと判断された場合は、ＤＳＰ３０はステップＦ２０５に進み、強制的に記録動作を停止する。
そしてステップＦ２０６で、ｘブロックのうちの１ブロックを用いて、記録したコンテンツについての再生管理ファイルの作成（又は更新）を行って、記録処理を終える。
この場合は、メモリカード４０における記録可能な容量として余りブロックとして設定された（ｘ−１）ブロック分だけ残された状態となる。
【０１４７】
つまりこの処理例３では、記録終了時点で、少なくとも（ｘ−１）ブロック分の容量が残され、その分だけその後の編集が可能となる。
固定的に設定されるｘの値としては、例えば統計的に妥当と考えられる値としてもよいし、例えばユーザーが任意に設定できるようにして、ユーザーの事情や記録内容に合致した処理が行われるようにすることもできる。
【０１４８】
以上、本発明の実施の形態としての例を説明してきたが、実施の形態の例はあくまでも一例であり、レコーダの構成、処理方式などは、多様に考えられる。
特に余りブロック数の設定方式は、各種の多様な変形例が考えられる。
また上記例ではオーディオデータとしてのコンテンツ（プログラム）を想定して説明したが、ビデオデータとしてのコンテンツについても、全く同様に本発明を適用できる。テキストデータその他のコンテンツについても同様である。
【０１４９】
【発明の効果】
以上の説明から分かるように本発明では、記録動作に際して所要量の余りブロック量を設定するとともに、プログラム記録動作により、記録媒体上で、余りブロック量を除いた記録可能なブロック残量がゼロとなったら、プログラム記録動作を終了させるようにしているため、プログラム（コンテンツ）の記録終了後において、少なくとも上記余りブロック量に相当する記録可能容量が残されるものとなる。
そして管理情報の記録又は更新、及び／又は記録されたプログラムの編集に用いられるブロックとして、余りブロック量が設定されていることで、プログラムの記録を完結させるための管理情報の書込／更新、或いはその後のプログラムの編集のために用いる領域が確保されていることになり、つまり記録や編集が適切に実行できる状態を確保できるという効果がある。
また、余りブロック量は、プログラム記録手段による記録動作の際に、記録媒体上に記録されているプログラム数に応じて設定すること、或いは記録媒体上に記録されているプログラムの平均データサイズと記録媒体の容量に応じて設定することで、その記録媒体のプログラム記録状況に合致した適切な量とすることができ、余りブロック量が多すぎてむやみにプログラム記録領域が削減されたり、或いは逆に、その後の編集等のために十分なブロック量が確保できないということを避けられる。
【０１５０】
また記録媒体において記録可能なブロック残量が所定以下となったら、その記録媒体に記録されているプログラムについての編集処理が不可とされることの警告を出力することで、ユーザーに状況を告知できる。
【０１５１】
また記録媒体上で前記余りブロック量を除いた記録可能なブロック残量がゼロとなったらプログラム記録動作を終了させる動作モードと、記録媒体上で記録可能なブロック残量がゼロとなるまでプログラム記録動作を続行可能とする動作モードとを選択できるようにすることで、ユーザーの事情に応じて、記録媒体の記録容量を有効に利用できるようにすることができる。
【図面の簡単な説明】
【図１】本発明の実施の形態のレコーダのブロック図である。
【図２】実施の形態のレコーダのＤＳＰのブロック図である。
【図３】実施の形態のメモリカードの構成を示すブロック図である。
【図４】実施の形態におけるメモリカードのファイルシステム処理階層の構成の説明図である。
【図５】実施の形態のメモリカードのデータの物理的構成のフォーマットの説明図である。
【図６】実施の形態のメモリカードのディレクトリ構造の説明図である。
【図７】実施の形態のメモリカードの再生管理ファイルのデータ構成の説明図である。
【図８】実施の形態のメモリカードのデータファイルのデータ構成の説明図である。
【図９】実施の形態のデータファイルの構成の説明図である。
【図１０】実施の形態のデータファイルのコンバイン編集処理の説明図である。
【図１１】実施の形態のデータファイルのデバイド編集処理の説明図である。
【図１２】実施の形態の再生管理ファイルの構成の説明図である。
【図１３】実施の形態の再生管理ファイルの付加情報領域の構成の説明図である。
【図１４】実施の形態の付加情報キーコードの説明図である。
【図１５】実施の形態の付加情報キーコードの説明図である。
【図１６】実施の形態の付加情報キーコードの説明図である。
【図１７】実施の形態における付加情報の具体的なデータ構成の説明図である。
【図１８】実施の形態のデータファイルの構成の説明図である。
【図１９】実施の形態のデータファイルの属性ヘッダの「Ａ」の説明図である。
【図２０】実施の形態のデータファイルの属性ヘッダの「ＣＣ」の説明図である。
【図２１】実施の形態の記録処理のフローチャートである。
【図２２】実施の形態の記録処理のフローチャートである。
【図２３】実施の形態の記録処理のフローチャートである。
【符号の説明】
１，１Ａ，１Ｂ レコーダ、１０ オーディオエンコーダ／デコーダＩＣ、２０ セキュリティＩＣ、３０ ＤＳＰ、４０ メモリカード、４２ フラッシュメモリ、５２ セキュリティブロック
【発明の属する技術分野】
本発明は、例えばオーディオデータやビデオデータなどのプログラム（コンテンツ）を記録媒体に記録する記録装置に関するものである。
【０００２】
【従来の技術】
ＥＥＰＲＯＭ(Electrically Erasable Programmable ROM)と呼ばれる電気的に書き換え可能な不揮発性メモリは、１ビットを２個のトランジスタで構成するために、１ビット当たりの占有面積が大きく、集積度を高くするのに限界があった。この問題を解決するために、全ビット一括消去方式により１ビットを１トランジスタで実現することが可能なフラッシュメモリが開発された。フラッシュメモリは、磁気ディスク、光ディスク等の記録媒体に代わりうるものとして期待されている。
【０００３】
フラッシュメモリを機器に対して着脱自在に構成したメモリカードも知られている。このメモリカードを使用すれば、従来のＣＤ（コンパクトディスク）、ＭＤ（ミニディスク）等のディスク状媒体に換えてメモリカードを使用するディジタルオーディオデータ等の記録／再生装置を実現することができる。
【０００４】
そして、フラッシュメモリを用いたメモリカードを記録媒体としてオーディオデータやビデオデータ等のプログラム（コンテンツともいう）を記録再生するシステムでは、例えば従来、パーソナルコンピュータで使用されるファイル管理システムである、ＦＡＴ(File Allocation Table) ファイルシステムを採用することや、ファイル管理情報の工夫により、容易にコンテンツの編集が可能となる。
例えば１つの楽曲としてのオーディオデータが１つのコンテンツとして記録されると仮定すると、そのコンテンツを分割して２つのコンテンツ、すなわち２つの曲にするデバイド編集や、逆に２つのコンテンツを結合させて１つのコンテンツ、すなわち１つの曲にするコンバイン編集なども可能である。
これにより、ユーザーサイドでは、メモリカードに記録したコンテンツを任意に加工して楽しむといったことも可能となる。
【０００５】
【発明が解決しようとする課題】
ところで、従来よりオーディオデータとしてのコンテンツを編集可能なシステムとしてミニディスクシステムが知られている。このミニディスクシステムでは、コンテンツを管理する管理情報である、いわゆるＴＯＣデータを書き換えることで、コンテンツの編集を実現してきた。
そしてミニディスク（光磁気ディスク）上では、コンテンツを記録するプログラム領域と、ＴＯＣデータを記録する管理情報領域がそれぞれ別に、所定の容量で設定されており、ＴＯＣデータの情報量がプログラム（コンテンツ）の記録容量に影響を与えることはなかった。また、編集を何度繰り返したとしても、それは全て管理情報領域内でのＴＯＣデータの書換が行われるのみであるため、これもプログラム（コンテンツ）の記録容量に影響を与えることはない。
【０００６】
ところが、フラッシュメモリの場合は、同一位置に書込を繰り返すと、著しくメモリ寿命が縮まるという性質があることから、絶えず書き込み位置を移動させることが好適であるとされている。
このため、メモリカードにおいてコンテンツを記録する領域と、コンテンツを管理する管理情報を記録する領域とを特定せず、例えば管理情報を更新する場合は、新たな領域に新たな管理情報を書き込み、旧管理情報を消去するような記録動作を行っている。
これは、コンテンツの記録動作や編集動作に伴って管理情報の更新が必要とされる場合は、からなず管理情報を新たに書き込めるだけの領域が確保されていることが必要となることを意味する。換言すれば、所定以上の空き容量がなければ、管理情報の更新ができないものとなり、これにより記録動作が完結せず、また編集ができない状態となる。
またブロックといわれる所定単位でデータの管理等を行うメモリカードでは、例えばデバイド編集などの際に新たに１ブロック分が必要となることがある。これも、所定以上の空き容量がなければ、コンテンツの編集ができないということを意味する。
【０００７】
つまりフラッシュメモリを用いたメモリカードを記録媒体とする場合は、コンテンツの記録によりメモリカードの残りの記録可能容量が所定未満となってしまうと、記録後に必要な管理情報の更新や、記録されているコンテンツについての編集が実行できなくなるという不都合がある。
【０００８】
【課題を解決するための手段】
本発明はこのような問題に鑑みて、プログラム（コンテンツ）の記録に応じた管理情報の更新や、編集処理が適切に実行できるようにすることを目的とする。
【０００９】
このために本発明の記録装置は、コンテンツとしてのプログラムを入力する入力手段と、所定数の固定長とされたブロック単位で記録が行われる記録媒体に対して、前記入力手段に入力された前記プログラムを前記ブロック単位にブロック化して記録していくプログラム記録手段と、前記ブロック単位に記録されたプログラムを管理する、プログラム数、各プログラムのデータサイズを記録した管理情報を記録媒体に記録し、又は更新する管理情報記録手段と、前記管理情報記録手段による管理情報の記録又は更新、及び／又は記録されたプログラムの編集に用いられるブロックとして所要量の余りブロック量を設定するとともに、前記プログラム記録手段による記録動作により、記録媒体上で、前記余りブロック量を除いた記録可能なブロック残量がゼロとなったら、前記プログラム記録手段による記録動作を終了させる制御手段と、を備え、前記制御手段は、前記プログラム記録手段による記録動作の際に、記録媒体上に記録されているプログラムの平均データサイズと、記録媒体の容量に応じて、前記余りブロック量を設定するようにする。
つまり、管理情報の記録又は更新や、記録されたプログラムの編集に用いられるブロックとして、余りブロック量を設定しておき、プログラムの記録動作は、余りブロック量として設定された容量を残した状態で終了されるようにする。
【００１０】
【発明の実施の形態】
以下、本発明の実施の形態について説明していく。この実施の形態では、記録媒体の例としての不揮発性メモリ（フラッシュメモリ）を搭載するメモリカードを挙げ、記録装置の例として、メモリカードに対して記録再生動作を行うことのできるレコーダを挙げる。
また、実施の形態において扱うことのできるプログラム（コンテンツ）としてのデータは、オーディオデータ、動画データ、静止画データ等のビデオデータ、テキストデータ、プログラムデータ等、各種のものがあるが、説明上は楽曲等のオーディオデータを扱うものとする。なお、主たるコンテンツとしてオーディオデータを扱う場合でも、ディジタルオーディオ信号以外の画像、文字等を付加情報として記録／再生可能となる。
説明は次の順序で行う。
１．レコーダの構成
２．メモリカードの構成
３．ファイルシステム
３−１ 処理構造及びデータ構造
３−２ ディレクトリ構成
３−３ 管理構造及び編集方式
３−４ 再生管理ファイル
３−５ データファイル
４．記録処理
４−１ 処理例１
４−２ 処理例２
４−３ 処理例３
【００１１】
１．レコーダの構成
図１により、オーディオデータ等のプログラム（コンテンツ）をメモリカードに対して記録再生することのできるメモリカード記録再生装置（以下、レコーダ１）の構成を説明する。
このレコーダ１は、記録媒体として、着脱自在のメモリカードを使用する。そしてこのレコーダ１は、単体のオーディオ装置として構成してもよいし、パーソナルコンピュータ、或いはオーディオ／ビジュアル機器に内蔵された装置部として構成してもよい。
単体のオーディオ装置とする場合は、例えばレコーダ１は据置型或いは携帯用小型の記録再生装置とされる。その場合、アンプ装置、スピーカ、ＣＤプレーヤ、ＭＤレコーダ、チューナ等と共にオーディオシステムを構成することもできる。
また他の機器に内蔵される形態としては、例えばパーソナルコンピュータにおいてＣＤ−ＲＯＭドライブやフロッピーディスクドライブと同様の位置づけで、メモリカードドライブとして採用することができる。
さらにレコーダ１をビデオカメラやゲーム機器に内蔵して、メモリカードをビデオデータやオーディオデータの記録媒体として用いることも可能である。
またレコーダ１は、上記の単体型、内蔵型に関わらず、衛星を使用したデータ通信、ディジタル放送、インターネット等を経由して配信されるディジタルオーディオ信号等を記録するレコーダとしても適用できる。
【００１２】
図１はこれら各種の態様で実現できるメモリカード記録再生装置としての一般的な構成を示すものである。
レコーダ１は、それぞれ１チップＩＣで構成されたオーディオエンコーダ／デコーダＩＣ１０、セキュリティＩＣ２０、ＤＳＰ(Digital Signal Processor)３０を有する。そしてレコーダ１に対して着脱自在のメモリカード４０が記録媒体として用いられる。
メモリカード４０は、フラッシュメモリ（不揮発性メモリ）、メモリコントロールブロック、ＤＥＳ(Data Encryption Standard)の暗号化回路を含むセキュリティブロックが１チップ上にＩＣ化されたものである。
なお本例では、ＤＳＰ３０を使用しているが、ＤＳＰに代えてマイクロコンピュータを使用しても良い。
【００１３】
オーディオエンコーダ／デコーダＩＣ１０は、オーディオインタフェース１１およびエンコーダ／デコーダブロック１２を有する。エンコーダ／デコーダブロック１２は、ディジタルオーディオ信号をメモリカード４０に書き込むために高能率符号化し、また、メモリカード４０から読み出されたデータを復号する。高能率符号化方法としては、ミニディスクで採用されているＡＴＲＡＣ(Adaptive Transform Acoustic Coding)を改良したもの（ＡＴＲＡＣ３と表記する）が使用できる。
【００１４】
ＡＴＲＡＣ３では、４４．１ｋHzでサンプリングした１サンプル１６ビットのオーディオデータを処理する。ＡＴＲＡＣ３でオーディオデータを処理する時の最小のデータ単位がサウンドユニットＳＵである。１ＳＵは、１０２４サンプル分（１０２４×１６ビット×２チャンネル）を数百バイトに圧縮したものであり、時間にして約２３ｍ秒である。ＡＴＲＡＣ３により約１／１０にオーディオデータが圧縮される。ミニディスクにおいてそうであるように、ＡＴＲＡＣ３の工夫された信号処理によって、圧縮／伸長処理による音質の劣化は少ない。
【００１５】
ライン入力セレクタ１３は、ＭＤの再生出力、チューナの出力、テープ再生出力を選択的にＡ／Ｄ変換器１４に供給する。Ａ／Ｄ変換器１４は、選択されたライン入力信号を（サンプリング周波数＝４４．１ｋHz、１サンプル＝１６ビット）のディジタルオーディオ信号へ変換する。
ディジタル入力セレクタ１６は、ＭＤ、ＣＤ、ＣＳ（衛星ディジタル放送）のディジタル出力を選択的にディジタル入力レシーバ１７に供給する。ディジタル入力は、例えば光ケーブルを介して伝送される。ディジタル入力レシーバ１７の出力がサンプリングレートコンバータ１５に供給され、ディジタル入力のサンプリング周波数が４４．１ｋHzに変換される。
【００１６】
オーディオエンコーダ／デコーダＩＣ１０のエンコーダ／デコーダブロック１２でのエンコード処理により得られた符号化データは、セキュリティＩＣ２０のインタフェース２１を介してＤＥＳの暗号化回路２２に供給される。
ＤＥＳの暗号化回路２２は、ＦＩＦＯ２３を有している。ＤＥＳの暗号化回路２２は、コンテンツの著作権を保護するための備えられている。
なお後述するが、メモリカード４０にも、ＤＥＳの暗号化回路が組み込まれている。
レコーダ１のＤＥＳの暗号化回路２２は、複数のマスターキーと機器毎にユニークなストレージキーを持つ。さらに、ＤＥＳの暗号化回路２２は、乱数発生回路を持ち、ＤＥＳの暗号化回路を内蔵するメモリカード４０と認証およびセッションキーを共有することができる。よりさらに、ＤＥＳの暗号化回路２２は、ＤＥＳの暗号化回路を通してストレージキーでキーをかけなおすことができる。
【００１７】
ＤＥＳの暗号化回路２２からの暗号化されたオーディオデータがＤＳＰ(Digit al Signal Processor) ３０に供給される。ＤＳＰ３０は、図示しない着脱機構に装着されたメモリカード４０との間で、図２に示すメモリインタフェース３８を介しての通信を行い、暗号化されたデータをフラッシュメモリに書き込む。
ＤＳＰ３０とメモリカード４０との間では、シリアル通信がなされる。また、メモリカード４０の制御に必要なメモリ容量を確保するために、ＤＳＰ３０に対して外付けのＳＲＡＭ(Static Random Access Memory) ３１が接続される。
【００１８】
さらにＤＳＰ３０に対して、端子３２が接続され、図示しない外部機器又は外部回路部との間でコンテンツデータや制御データの相互通信を行うことができるようにされている。ＤＳＰ３０は図２に示すインターフェース３７を介して、外部機器等との間で通信を行う。
例えばこのレコーダ１が単体で構成される場合は、インターフェース３７及び端子３２は、例えばＵＳＢ、ＩＥＥＥ１３９４、ＩＥＣ９５８、シリアルポート通信、パラレルポート通信など、所定の通信方式に応じたものとされ、パーソナルコンピュータやオーディオ／ビジュアル機器等との間で通信可能とされる。
【００１９】
また、このレコーダ１がパーソナルコンピュータやオーディオ／ビジュアル機器などに内蔵される場合は、インターフェース３７及び端子３２は、例えばそれらの機器のシステムコントローラと接続される内部バス等の構成をとることになる。
【００２０】
端子３２に接続された機器或いは部位からは、各種のデータがＤＳＰ３０に供給される。例えばレコーダ１がオーディオシステムやコンピュータシステムの一部とされている場合は、そのオーディオシステムやコンピュータシステムの全体の動作を制御する外部のシステムコントローラからは、ユーザの操作に応じて発生した録音指令、再生指令等のデータをＤＳＰ３０に与える。
また、画像情報、文字情報等の付加情報のデータも端子３２を介してＤＳＰ３０に供給される。
さらにＤＳＰ３０は、端子３２を介して、メモリカード４０から読み出された付加情報データ、制御信号等を外部のシステムコントローラに供給することもできる。
【００２１】
なお、図１にはユーザーが各種の操作を行う操作キー等が設けられた操作部３９、及びユーザーに対して各種の情報の提示を行う表示部３３を示している。これらは特にレコーダ１が単体で構成される場合に必要となるものであり、例えばレコーダ１がパーソナルコンピュータに内蔵される場合などは、ＤＳＰ３０に操作部３９及び表示部３３が直接接続される必要はない。
つまり単体の場合はＤＳＰ３０が操作部３９からの操作入力の処理や表示部３３での表示制御を行うことになるが、内蔵型の場合は、その装置のシステムコントローラがこれらの制御を行い、必要に応じてＤＳＰ３０に操作情報を供給したり、或いはＤＳＰ３０から表示すべき内容を示す情報を受け取ったりすればよいためである。
【００２２】
ＤＳＰ３０によってメモリカード４０から読み出したコンテンツとしての暗号化されたオーディオデータは、セキュリティＩＣ２０によって復号化され、オーディオエンコーダ／デコーダＩＣ１０によってＡＴＲＡＣ３の復号化処理を受ける。
そしてオーディオエンコーダ／デコーダ１０の復号化出力がＤ／Ａ変換器１８に供給され、アナログオーディオ信号へ変換される。そして、アナログオーディオ信号がライン出力端子１９に取り出される。
【００２３】
ライン出力は、図示しないアンプ装置等に伝送され、スピーカまたはヘッドホンにより再生される。
なおＤ／Ａ変換器１８に対してミューティング信号が外部のコントローラから供給される。ミューティング信号がミューティングのオンを示す時には、ライン出力端子１９からのオーディオ出力が禁止される。
【００２４】
なお、図１ではライン出力端子１９のみを示しているが、もちろんデジタル出力端子、ヘッドホン端子等が設けられてもよい。
また外部機器へのコンテンツデータの出力は、上述のように端子３２を介して行うこともできる。
【００２５】
図２は、ＤＳＰ３０の内部構成を示す。ＤＳＰ３０は、コア３４と、フラッシュメモリ３５と、ＳＲＡＭ３６と、インタフェース３７と、メモリカードインタフェース３８と、バスおよびバス間のブリッジとで構成される。
このＤＳＰ３０はマイクロコンピュータと同様に機能し、コア３４がＣＰＵに相当する。
フラッシュメモリ３５にはＤＳＰ３０の処理のためのプログラムが格納されている。またＳＲＡＭ３６と外部のＳＲＡＭ３１とが、各種処理のためのワークメモリとして使用される。
【００２６】
ＤＳＰ３０は、インタフェース３７を介して受け取った録音指令等の操作信号（又は図１に示す操作部３９から入力された操作信号）に応答して、所定の暗号化されたオーディオデータ、所定の付加情報データをメモリカード４０に対して書き込み、また、これらのデータをメモリカード４０から読み出す処理を制御する。
すなわち、オーディオデータ、付加情報の記録／再生を行うためのオーディオシステム全体のアプリケーションソフトウェアと、メモリカード４０との間にＤＳＰ３０が位置し、メモリカード４０のアクセス、ファイルシステム等のソフトウェアによってＤＳＰ３０が動作する。
【００２７】
ＤＳＰ３０におけるメモリカード４０上のファイル管理は、既存のパーソナルコンピュータで使用されているＦＡＴファイルシステムが使用される。このファイルシステムに加えて、本例では、後述するようなデータ構成の再生管理ファイルが使用される。
再生管理ファイルは、メモリカード４０上に記録されているデータファイルを管理する。
すなわち第１のファイル管理情報としての再生管理ファイルは、オーディオデータのファイルを管理するものであり、第２のファイル管理情報としてのＦＡＴは、オーディオデータのファイルと再生管理ファイルを含むメモリカード０のフラッシュメモリ上のファイル全体を管理する。
再生管理ファイルは、メモリカード４０に記録される。また、ＦＡＴは、ルートディレクトリ等と共に、予め出荷時にフラッシュメモリ上に書き込まれている。
【００２８】
なお本例では、著作権を保護するために、ＡＴＲＡＣ３により圧縮されたオーディオデータを暗号化している。一方、管理ファイルは、著作権保護が必要ないとして、暗号化を行わないようにしている。また、メモリカード４０としても、暗号化機能を持つものと、持たないものとがありうる。本例のように、著作物であるオーディオデータを記録するレコーダ１が使用できるものは、暗号化機能を持つメモリカードのみである。
【００２９】
２．メモリカードの構成
図３は、メモリカード４０の構成を示す。メモリカード４０は、コントロールブロック４１とフラッシュメモリ４２が１チップＩＣとして構成されたものである。
レコーダ１のＤＳＰ３０とメモリカード４０との間の双方向シリアルインタフェースは、１０本の線からなる。主要な４本の線は、データ伝送時にクロックを伝送するためのクロック線ＳＣＫと、ステータスを伝送するためのステータス線ＳＢＳと、データを伝送するデータ線ＤＩＯ、インターラプト線ＩＮＴとである。その他に電源供給用線として、２本のＧＮＤ線および２本のＶＣＣ線が設けられる。２本の線Ｒｅｓｅｒｖは、未定義の線である。
【００３０】
クロック線ＳＣＫは、データに同期したクロックを伝送するための線である。ステータス線ＳＢＳは、メモリカード４０のステータスを表す信号を伝送するための線である。データ線ＤＩＯは、コマンドおよび暗号化されたオーディオデータを入出力するための線である。インターラプト線ＩＮＴは、メモリカード４０からレコーダ１のＤＳＰ３０に対しての割り込みを要求するインターラプト信号を伝送する線である。メモリカード４０を装着した時にインターラプト信号が発生する。但し、本例では、インターラプト信号をデータ線ＤＩＯを介して伝送するようにしているので、インターラプト線ＩＮＴを接地している。
【００３１】
コントロールブロック４１のシリアル／パラレル変換・パラレル／シリアル変換・インタフェースブロック（Ｓ／Ｐ，Ｐ／Ｓ，ＩＦブロックと略す）４３は、上述した複数の線を介して接続されたレコーダのＤＳＰ３０とコントロールブロック４１とのインタフェースである。Ｓ／Ｐ，Ｐ／Ｓ，ＩＦブロック４３は、レコーダ１のＤＳＰ３０から受け取ったシリアルデータをパラレルデータに変換し、コントロールブロック４１に取り込み、コントロールブロック４１からのパラレルデータをシリアルデータに変換してレコーダ１のＤＳＰ３０に送る。また、Ｓ／Ｐ，Ｐ／Ｓ，ＩＦブロック４３は、データ線ＤＩＯを介して伝送されるコマンドおよびデータを受け取った時に、フラッシュメモリ４２に対する通常のアクセスのためのコマンドおよびデータと、暗号化に必要なコマンドおよびデータとを分離する。
【００３２】
つまり、データ線ＤＩＯを介して伝送されるフォーマットでは、最初にコマンドが伝送され、その後にデータが伝送される。Ｓ／Ｐ，Ｐ／Ｓ，ＩＦブロック４３は、コマンドのコードを見て、通常のアクセスに必要なコマンドおよびデータか、暗号化に必要なコマンドおよびデータかを判別する。この判別結果に従って、通常のアクセスに必要なコマンドをコマンドレジスタ４４に格納し、データをページバッファ４５およびライトレジスタ４６に格納する。ライトレジスタ４６と関連してエラー訂正符号化回路４７が設けられている。ページバッファ４５に一時的に蓄えられたデータに対して、エラー訂正符号化回路４７がエラー訂正符号の冗長コードを生成する。
【００３３】
コマンドレジスタ４４、ページバッファ４５、ライトレジスタ４６およびエラー訂正符号化回路４７の出力データがフラッシュメモリインタフェースおよびシーケンサ（メモリＩ／Ｆ，シーケンサと略す）５１に供給される。メモリＩＦ，シーケンサ５１は、コントロールブロック４１とフラッシュメモリ４２とのインタフェースであり、両者の間のデータのやり取りを制御する。メモリＩＦ，シーケンサ５１を介してデータがフラッシュメモリ４２に書き込まれる。
【００３４】
フラッシュメモリ４２に書き込まれるコンテンツ（ＡＴＲＡＣ３により圧縮されたオーディオデータ、以下ＡＴＲＡＣ３データと表記する）は、著作権保護のために、レコーダ１のセキュリティＩＣ２０とメモリカード４０のセキュリティブロック５２とによって、暗号化されたものである。セキュリティブロック５２は、バッファメモリ５３と、ＤＥＳの暗号化回路５４と、不揮発性メモリ５５とを有する。
【００３５】
メモリカード４０のセキュリティブロック５２は、複数の認証キーとメモリカード毎にユニークなストレージキーを持つ。不揮発性メモリ５５は、暗号化に必要なキーを格納するもので、外部からは見えない。例えばストレージキーが不揮発性メモリ５５に格納される。
さらに、乱数発生回路を持ち、専用（ある決められたデータフォーマット等の使用が同じシステム内の意味）レコーダ１と認証ができ、セッションキーを共有できる。よりさらに、ＤＥＳの暗号化回路５４を通してストレージキーでキーのかけ直しができる。
【００３６】
例えばメモリカード４０をレコーダ１に装着した時に認証がなされる。認証は、レコーダ１のセキュリティＩＣ２０とメモリカード４０のセキュリティブロック５２によってなされる。
レコーダ１は、装着されたメモリカード４０が本人（同じシステム内のメモリカード）であることを認め、また、メモリカード４０が相手のレコーダが本人（同じシステム内のレコーダ）であることを認めると、互いに相手が本人であることを確認する。認証が行われると、レコーダ１とメモリカード４０がそれぞれセッションキーを生成し、セッションキーを共有する。セッションキーは、認証の度に生成される。
【００３７】
そして、メモリカード４０に対するコンテンツの書き込み時には、レコーダ１がセッションキーでコンテンツキーを暗号化してメモリカード４０に渡す。メモリカード４０では、コンテンツキーをセッションキーで復号し、ストレージキーで暗号化してレコーダ１に渡す。
ストレージキーは、メモリカード４０の一つ一つにユニークなキーであり、レコーダ１は、暗号化されたコンテンツキーを受け取ると、フォーマット処理を行い、暗号化されたコンテンツキーと暗号化されたコンテンツをメモリカード４０に書き込む。
【００３８】
フラッシュメモリ４２からのデータ読出時には、読み出されたデータがメモリＩＦ，シーケンサ５１を介してページバッファ４５、リードレジスタ４８、エラー訂正回路４９に供給される。そしてページバッファ４５に記憶されたデータがエラー訂正回路４９によってエラー訂正がなされる。
エラー訂正されたページバッファ４５の出力およびリードレジスタ４８の出力はＳ／Ｐ，Ｐ／Ｓ，ＩＦブロック４３に供給され、上述したシリアルインタフェースを介してレコーダ１のＤＳＰ３０に供給される。
【００３９】
このような読出時には、ストレージキーで暗号化されたコンテンツキーとブロックキーで暗号化されたコンテンツとがフラッシュメモリ４２から読み出される。そしてセキュリティブロック５２によって、ストレージキーでコンテンツキーが復号される。
さらに復号されたコンテンツキーがセッションキーで暗号化されてレコーダ１側に送信される。レコーダ１は、受信したセッションキーでコンテンツキーを復号する。レコーダ１は、復号したコンテンツキーでブロックキーを生成する。このブロックキーによって、暗号化されたＡＴＲＡＣ３データを順次復号する。
【００４０】
なお、コンフィグレーションＲＯＭ５０には、メモリカード４０のバージョン情報、各種の属性情報等が格納されている。
また、メモリカード４０には、ユーザが必要に応じて操作可能な誤消去防止用のスイッチ６０が備えられている。このスイッチ６０が消去禁止の接続状態にある場合には、フラッシュメモリ４２を消去することを指示するコマンドがレコーダ側から送られてきても、フラッシュメモリ４２の消去が禁止される。
さらに、発振器６１は、メモリカード４０の処理のタイミング基準となるクロックを発生する。
【００４１】
３．ファイルシステム
３−１ 処理構造及びデータ構造
図４は、メモリカード４０を記憶媒体とするシステムのファイルシステム処理階層を示す。
ファイルシステム処理階層としては、アプリケーション処理層が最上位であり、その下に、ファイル管理処理層、論理アドレス管理層、物理アドレス管理層、フラッシュメモリアクセスが順次おかれる。
この階層構造において、ファイル管理処理層がＦＡＴファイルシステムである。物理アドレスは、フラッシュメモリの各ブロックに対して付されたもので、ブロックと物理アドレスの対応関係は、不変である。論理アドレスは、ファイル管理処理層が論理的に扱うアドレスである。
【００４２】
図５は、メモリカード４０におけるフラッシュメモリ４２のデータの物理的構成の一例を示す。
フラッシュメモリ４２は、セグメントと称されるデータ単位が所定数のブロック（固定長）へ分割され、１ブロックが所定数のページ（固定長）へ分割される。フラッシュメモリ４２では、ブロック単位で消去が一括して行われ、書き込みと読み出しは、ページ単位で一括して行われる。
【００４３】
各ブロックおよび各ページは、それぞれ同一のサイズとされ、１ブロックがページ０からページｍで構成される。１ブロックは、例えば８ＫＢ（Ｋバイト）バイトまたは１６ＫＢの容量とされ、１ページが５１２Ｂの容量とされる。フラッシュメモリ４２全体では、１ブロック＝８ＫＢの場合で、４ＭＢ（５１２ブロック）、８ＭＢ（１０２４ブロック）とされ、１ブロック＝１６ＫＢの場合で、１６ＭＢ（１０２４ブロック）、３２ＭＢ（２０４８ブロック）、６４ＭＢ（４０９６ブロック）の容量とされる。
【００４４】
１ページは、５１２バイトのデータ部と１６バイトの冗長部とからなる。冗長部の先頭の３バイトは、データの更新に応じて書き換えられるオーバーライト部分とされる。３バイトの各バイトに、先頭から順にブロックステータス、ページステータス、更新ステータスが記録される。
冗長部の残りの１３バイトの内容は、原則的にデータ部の内容に応じて固定とされる。この１３バイトは、管理フラグ（１バイト）、論理アドレス（２バイト）、フォーマットリザーブの領域（５バイト）、分散情報ＥＣＣ（２バイト）およびデータＥＣＣ（３バイト）からなる。
分散情報ＥＣＣは、管理フラグ、論理アドレス、フォーマットリザーブに対する誤り訂正用の冗長データであり、データＥＣＣは、５１２バイトのデータに対する誤り訂正用の冗長データである。
【００４５】
管理フラグとして、システムフラグ（その値が１：ユーザブロック、０：ブートブロック）、変換テーブルフラグ（１：無効、０：テーブルブロック）、コピー禁止指定（１：ＯＫ、０：ＮＧ）、アクセス許可（１：ｆｒｅｅ、０：リードプロテクト）の各フラグが記録される。
【００４６】
セグメントにおける先頭の二つのブロック、すなわちブロック０およびブロック１がブートブロックである。ブロック１は、ブロック０と同一のデータが書かれるバックアップ用である。
ブートブロックは、メモリカード４０内の有効なブロックの先頭ブロックであり、メモリカード４０を機器に装填した時に最初にアクセスされるブロックである。残りのブロックがユーザブロックである。
ブートブロックの先頭のページ０にヘッダ、システムエントリ、ブート＆アトリビュート情報が格納される。ページ１に使用禁止ブロックデータが格納される。ページ２にＣＩＳ(Card Information Structure)／ＩＤＩ(Identify Drive Information)が格納される。
【００４７】
ブートブロックのヘッダは、ブートブロックＩＤ、ブートブロック内の有効なエントリ数が記録される。システムエントリには、使用禁止ブロックデータの開始位置、そのデータサイズ、データ種別、ＣＩＳ／ＩＤＩのデータ開始位置、そのデータサイズ、データ種別が記録される。
ブート＆アトリビュート情報には、メモリカード４０のタイプ（読み出し専用、リードおよびライト可能、両タイプのハイブリッド等）、ブロックサイズ、ブロック数、総ブロック数、セキュリティ対応か否か、カードの製造に関連したデータ（製造年月日等）等が記録される。
【００４８】
いわゆるフラッシュメモリは、データの書き換えを行うことにより絶縁膜の劣化を生じ、書き換え回数が制限される。従って、ある同一の記憶領域（ブロック）に対して繰り返し集中的にアクセスがなされることを防止する必要がある。従って、ある物理アドレスに格納されているある論理アドレスのデータを書き換える場合、フラッシュメモリのファイルシステムでは、同一のブロックに対して更新したデータを再度書き込むことはせずに、未使用のブロックに対して更新したデータを書き込むようになされる。その結果、データ更新前における論理アドレスと物理アドレスの対応関係が更新後では、変化する。このような処理（スワップ処理と称する）を行うことで、同一のブロックに対して繰り返して集中的にアクセスがされることが防止され、フラッシュメモリの寿命を延ばすことが可能となる。
【００４９】
論理アドレスは、一旦ブロックに対して書き込まれたデータに付随するので、更新前のデータと更新後のデータの書き込まれるブロックが移動しても、ＦＡＴからは、同一のアドレスが見えることになり、以降のアクセスを適正に行うことができる。スワップ処理により論理アドレスと物理アドレスとの対応関係が変化するので、両者の対応を示す論理−物理アドレス変換テーブルが必要となる。このテーブルを参照することによって、ＦＡＴが指定した論理アドレスに対応する物理アドレスが特定され、特定された物理アドレスが示すブロックに対するアクセスが可能となる。
【００５０】
論理−物理アドレス変換テーブルは、ＤＳＰ３０によってＳＲＡＭ３１、３６上に格納される。若し、ＲＡＭ容量が少ない時は、フラッシュメモリ４２中に格納することができる。
このテーブルは、概略的には、昇順に並べた論理アドレス（２バイト）に物理アドレス（２バイト）をそれぞれ対応させたテーブルである。フラッシュメモリ４２の最大容量を１２８ＭＢ（８１９２ブロック）としているので、２バイトによって８１９２のアドレスを表すことができる。また、論理−物理アドレス変換テーブルは、セグメント毎に管理され、そのサイズは、フラッシュメモリ４２の容量に応じて大きくなる。例えばフラッシュメモリ４２の容量が８ＭＢ（２セグメント）の場合では、２個のセグメントのそれぞれに対して２ページが論理−物理アドレス変換テーブル用に使用される。
論理−物理アドレス変換テーブルを、フラッシュメモリ４２中に格納する時には、上述した各ページの冗長部における管理フラグの所定の１ビットによって、当該ブロックが論理−物理アドレス変換テーブルが格納されているブロックか否かが指示される。
【００５１】
上述したメモリカード４０は、ディスク状記録媒体と同様にパーソナルコンピュータのＦＡＴファイルシステムによって使用可能なものである。
図５には示されてないが、フラッシュメモリ４２上にＩＰＬ領域、ＦＡＴ領域およびルート・ディレクトリ領域が設けられる。
ＩＰＬ領域には、最初にレコーダ１のメモリにロードすべきプログラムが書かれているアドレス、並びにメモリの各種情報が書かれている。
ＦＡＴ領域には、ブロック（クラスタ）の関連事項が書かれている。ＦＡＴには、未使用のブロック、次のブロック番号、不良ブロック、最後のブロックをそれぞれ示す値が規定される。
さらに、ルートディレクトリ領域には、ディレクトリエントリ（ファイル属性、更新年月日、開始クラスタ、ファイルサイズ等）が書かれている。
【００５２】
本例では、上述したメモリカード４０のフォーマットで規定されるファイル管理システムとは別個に、音楽用ファイルに対して、各トラックおよび各トラックを構成するパーツを管理するための再生管理ファイルを持つようにしている。この再生管理ファイルは、メモリカード４０のユーザブロックを利用してフラッシュメモリ４２上に記録される。それによって、メモリカード４０上のＦＡＴが壊れても、ファイルの修復が可能となる。
【００５３】
この再生管理ファイルは、ＤＳＰ３０により作成される。例えば最初に電源をオンした時に、メモリカード４０が装着されているか否かが判定され、メモリカード４０が装着されている時には、認証が行われる。認証により正規のメモリカードであることが確認されると、フラッシュメモリ４２のブートブロックがＤＳＰ３０に読み込まれる。そして、論理−物理アドレス変換テーブルが読み込まれる。読み込まれたデータは、ＳＲＡＭ３１、３６に格納される。ユーザが購入して初めて使用するメモリカード４０でも、出荷時にフラッシュメモリ４２には、ＦＡＴや、ルートディレクトリの書き込みがなされている。再生管理ファイルは、録音がなされると、作成される。
【００５４】
すなわち、ユーザの操作等によって発生した録音指令がＤＳＰ３０に与えられると、受信したオーディオデータがエンコーダ／デコーダＩＣ１０によって圧縮され、エンコーダ／デコーダＩＣ１０からのＡＴＲＡＣ３データがセキュリティＩＣ２０により暗号化される。そしてＤＳＰ３０が暗号化されたＡＴＲＡＣ３データをメモリカード４０のフラッシュメモリ４２に記録するが、この記録後にＦＡＴおよび再生管理ファイルが更新される。
ファイルの更新の度、具体的には、オーディオデータの記録を開始し、記録を終了する度に、ＳＲＡＭ３１および３６上でＦＡＴおよび再生管理ファイルが書き換えられる。そして、メモリカード４０を外す時に、またはパワーをオフする時に、ＳＲＡＭ３１、３６からメモリカード４０のフラッシュメモリ４２上に最終的なＦＡＴおよび再生管理ファイルが格納される。この場合、オーディオデータの記録を開始し、記録を終了する度に、フラッシュメモリ４２上のＦＡＴおよび再生管理ファイルを書き換えても良い。編集を行った場合も、再生管理ファイルの内容が更新される。
【００５５】
さらに、本例のデータ構成では、付加情報も再生管理ファイル内に作成、更新され、フラッシュメモリ４２上に記録される。なお、再生管理ファイルとは別に付加情報管理ファイルが作成されるようにしてもよい。
付加情報は、外部のコントローラからバスおよびバスインターフェース３２を介してＤＳＰ３０に与えられる。ＤＳＰ３０が受信した付加情報をメモリカード４０のフラッシュメモリ４２上に記録する。付加情報は、セキュリティＩＣ２０を通らないので、暗号化されない。付加情報は、メモリカード４０を取り外したり、電源オフの時に、ＤＳＰ３０のＳＲＡＭからフラッシュメモリ４２に書き込まれる。
【００５６】
３−２ ディレクトリ構成
図６は、メモリカード４０のディレクトリ構成を示す。図示するようにルートディレクトリから、静止画用ディレクトリ、動画用ディレクトリ、音声用ディレクトリ、制御用ディレクトリ、音楽用（ＨＩＦＩ）ディレクトリが形成される。
本例では、音楽の記録／再生を中心に説明を行うので、以下、音楽用ディレクトリについて説明する。
音楽用ディレクトリには、２種類のファイルが置かれる。その１つは、再生管理ファイルＰＢＬＩＳＴ．ＭＳＦ（以下、単にＰＢＬＩＳＴと表記する）であり、他のものは、暗号化された音楽データを収納したＡＴＲＡＣ３データファイルＡ３Ｄｎｎｎｎ．ＭＳＡ（以下、単にＡ３Ｄｎｎｎと表記する）とからなる。
ＡＴＲＡＣ３データファイルは、最大数が４００までと規定されている。ＡＴＲＡＣ３データファイルは、再生管理ファイルに登録した上で機器により任意に作成される。
【００５７】
３−３ 管理構造及び編集方式
図７は、再生管理ファイルの構成を示し、図８が一つ（１曲）のＡＴＲＡＣ３データファイルの構成を示す。
再生管理ファイルは、１６ＫＢ固定長のファイルである。
図７に示すように再生管理ファイルは、ヘッダ、１バイトコードのメモリカードの名前ＮＭ１−Ｓ、２バイトコードのメモリカードの名前ＮＭ２−Ｓ、曲順の再生テーブルＴＲＫＴＢＬ、及びメモリカード全体の付加情報ＩＮＦ−Ｓとからなる。
【００５８】
また図８に示すＡＴＲＡＣ３データファイル（以下、単にデータファイルともいう）は、本発明でいうプログラム（又はコンテンツ）に相当するものであり、即ち曲単位のファイルである。そしてデータファイルは、先頭の属性ヘッダと、それに続く実際の暗号化された音楽データとからなる。属性ヘッダは１６ＫＢ固定長とされ、再生管理ファイルと類似した構成を有する。
データファイルの先頭の属性ヘッダは、ヘッダ、１バイトコードの曲名ＮＭ１、２バイトコードの曲名ＮＭ２、トラックのキー情報等のトラック情報ＴＲＫＩＮＦ、パーツ情報ＰＲＴＩＮＦと、トラックの付加情報ＩＮＦとからなる。ヘッダには、総パーツ数、名前の属性、付加情報のサイズの情報等が含まれる。
【００５９】
このデータファイルにおいては、属性ヘッダに対してＡＴＲＡＣ３の音楽データが続く。音楽データは、１６ＫＢのブロック毎に区切られ、各ブロックの先頭にヘッダが付加されている。ヘッダには、暗号を復号するための初期値が含まれる。
なお、暗号化の処理を受けるのは、ＡＴＲＡＣ３データファイル中の音楽データのみであって、それ以外の再生管理ファイル、ヘッダ等のデータは、暗号化されない。
【００６０】
図９を参照して、曲（コンテンツ）とＡＴＲＡＣ３データファイルの関係について説明する。
１つのコンテンツは、１曲として管理されるデータ群を意味する。１曲は、１つのＡＴＲＡＣ３データファイル（図８参照）で構成される。ＡＴＲＡＣ３データファイルは、ＡＴＲＡＣ３により圧縮されたオーディオデータが記録されている。
【００６１】
なお、メモリカード４０に対しては、クラスタと呼ばれる単位でデータの記録が行われる。１クラスタは例えば１６ＫＢの容量である。この１クラスタには複数のファイルが混じることがない。またフラッシュメモリ４２を消去する時の最小単位が１ブロックである。
音楽データを記録するのに使用するメモリカード４０の場合、ブロックとクラスタは、同意語であり、且つ１クラスタ＝１セクタと定義されている。
【００６２】
１曲は、基本的に１パーツで構成されるが、編集が行われると、複数のパーツから１曲が構成されることがある。パーツとは、録音開始からその停止までの連続した時間内で記録されたデータの単位を意味し、通常は、１つのコンテンツは１パーツで構成される。
１つのコンテンツが複数のパーツで構成される場合、曲内のパーツのつながりは、各曲の属性ヘッダ内のパーツ情報ＰＲＴＩＮＦ（後述）で管理する。すなわち、パーツサイズは、ＰＲＴＩＮＦの中のパーツサイズＰＲＴＳＩＺＥという４バイトのデータで表す。パーツサイズＰＲＴＳＩＺＥの先頭の２バイトがパーツが持つクラスタの総数を示し、続く各１バイトが先頭および末尾のクラスタ内の開始サウンドユニット（ＳＵと略記する）の位置、終了ＳＵの位置を示す。
このようなパーツの記述方法を持つことによって、音楽データを編集する際に通常、必要とされる大量の音楽データの移動をなくすことが可能となる。
なおブロック単位の編集に限定すれば、同様に音楽データの移動を回避できるが、ブロック単位は、ＳＵ単位に比して編集単位が大きすぎる。
【００６３】
ＳＵは、パーツの最小単位であり、且つＡＴＲＡＣ３でオーディオデータを圧縮する時の最小のデータ単位である。４４．１ｋHzのサンプリング周波数で得られた１０２４サンプル分（１０２４×１６ビット×２チャンネル）のオーディオデータを約１／１０に圧縮した数百バイトのデータがＳＵである。
１ＳＵは、時間に換算して約２３ｍ秒になる。通常は、数千に及ぶＳＵによって１つのパーツが構成される。
１クラスタが４２個のＳＵで構成される場合、１クラスタで約１秒の音を表すことができる。
１つのコンテンツを構成するパーツの数は、付加情報サイズに影響される。
パーツ数は、１ブロックの中からヘッダや曲名、付加情報データ等を除いた数で決まるために、付加情報が全く無い状態が最大数（６４５個）のパーツを使用できる条件となる。
【００６４】
図９は、ＣＤ等からのオーディオデータを２曲連続して記録した場合のファイル構成を示す。
図９（ａ）に１曲目（データファイル＃１）が例えば５つのクラスタ（ＣＬ０〜ＣＬ４）で構成された場合を、また図９（ｃ）に２曲目（データファイル＃２）が例えば６つのクラスタ（ＣＬ５〜ＣＬ１０）で構成された場合を示している。
１曲目と２曲目の曲間では、１クラスタに二つのファイルが混在することが許されないので、次のクラスタ（ＣＬ５）の最初からデータファイル＃２が作成される。
従って、データファイル＃１の終端（１曲目の終端）がクラスタの途中に位置しても、図９（ｂ）に拡大して示すように、そのクラスタの残りの部分には、データ（ＳＵ）が存在しないものとされる。
第２曲目（データファイル＃２）も同様である。
そしてこの例の場合は、データファイル＃１、＃２ともに１パーツで構成される。
【００６５】
メモリカード４０に記録されたデータファイルに対しては、編集として、デバイド、コンバイン、イレーズ、ムーブの４種類の処理が規定される。
デバイドは、１つのトラックを２つに分割することである。デバイドがされると、総トラック数が１つ増加する。デバイドは、一つのファイルをファイルシステム上で分割して２つのファイルとし、再生管理ファイルを更新する。
コンバインは、２つのトラックを１つに結合することである。コンバインされると、総トラック数が１つ減少する。コンバインは、２つのファイルをファイルシステム上で統合して１つのファイルにし、再生管理ファイルを更新する。
イレーズは、トラックを消去することである。消された以降のトラック番号が１つ減少する。
編集処理としてのムーブは、トラック順番を変えることである。この場合も再生管理ファイルを更新する。
なお、ここでいう編集処理としての「ムーブ」は、データの移動を伴うものではなく。例えばＨＤＤ等の記録媒体からメモリカード等の記録媒体へのデータの「ムーブ」とは意味が異なる。記録媒体から記録媒体へのムーブとは、データをコピーした上でコピー元の記録媒体からそのデータを消去することで実現するものである。
【００６６】
図９に示す二つの曲（データファイル＃１、＃２）をコンバインした結果を図１０に示す。コンバインされたことでデータファイル＃１、＃２は、１つのデータファイル＃１となり、このデータファイル＃１は、二つのパーツから形成されるものとなる。
上述したように本例ではパーツに関する記述方法があるので、コンバインした結果（図１０）において、パーツ１の開始位置、パーツ１の終了位置、パーツ２の開始位置、パーツ２の終了位置をそれぞれＳＵ単位で規定できる。その結果、コンバインした結果のつなぎ目の隙間をつめるために、パーツ２の音楽データを移動する必要がない。
【００６７】
また、図１１は、図９（ａ）の一つの曲（データファイル＃１）をクラスタ２の途中でデバイドした結果を示す。
デバイドによって、クラスタＣＬ０、ＣＬ１およびクラスタＣＬ２の前側からなるデータファイル＃１と、クラスタＣＬ２（ＣＬ１１）の後側とクラスタＣＬ３、ＣＬ４とからなるデータファイル＃２とが発生する。
上述したように、１つのクラスタに二つのファイルが混在することは許されないので、このようにクラスタＣＬ２内の或る位置を分割点とするデバイド編集の場合は、まず、クラスタＣＬ２のデータが、あいている別のクラスタＣＬ１１にコピーされる。そしてデータファイル＃２においては、クラスタＣＬ１１における分割点に相当する位置がスタートポイントとされ、そのクラスタＣＬ１１に、クラスタＣＬ３、ＣＬ４が続くようにされるものとなる。
従って、デバイド編集の場合は、再生管理ファイルの更新だけでなく、１つのクラスタを新たに使用することが必要となる。
【００６８】
なお、上述のようにパーツに関する記述方法があるので、デバイドした結果（図１１）において、データファイル＃２の先頭（クラスタＣＬ１１）の空きを詰めるように、データを移動する必要がない。
【００６９】
３−４ 再生管理ファイル
図１２は、再生管理ファイルＰＢＬＩＳＴのより詳細なデータ構成を示す。
再生管理ファイルＰＢＬＩＳＴは、１クラスタ（１ブロック＝１６ＫＢ）のサイズである。
先頭の３２バイトがヘッダとされる。
またヘッダ以外の部分がメモリカード全体に対する名前ＮＭ１−Ｓ（２５６バイト）、名前ＮＭ２−Ｓ（５１２バイト）、ＣＯＮＴＥＮＴＳ ＫＥＹ、ＭＡＣ、Ｓ−ＹＭＤｈｍｓと、再生順番を管理するテーブルＴＲＫＴＢＬ（８００バイト）と、メモリカード全体に対する付加情報ＩＮＦ−Ｓ（１４７２０バイト）であり、最後にヘッダ中の情報の一部が再度記録される。これらの異なる種類のデータ群のそれぞれの先頭は、再生管理ファイル内で所定の位置となるように規定されている。
【００７０】
再生管理ファイルにおいては、（０ｘ００００）および（０ｘ００１０）で表される先頭から３２バイトがヘッダである。
なお、ファイル中で先頭から１６バイト単位で区切られた単位をスロットと称する。
再生管理ファイルの第１および第２のスロットに配されるヘッダには、下記の意味、機能、値を持つデータが先頭から順に配される。
なお、Ｒｅｓｅｒｖｅｄと表記されているデータは、未定義のデータを表している。通常ヌル（０ｘ００）が書かれるが、何が書かれていてもＲｅｓｅｒｖｅｄのデータは無視される。将来のバージョンでは、変更がありうる。また、この部分への書き込みは禁止する。Ｏｐｔｉｏｎと書かれた部分も使用しない場合は、全てＲｅｓｅｒｖｅｄと同じ扱いとされる。
【００７１】
ＢＬＫＩＤ−ＴＬ０（４バイト）
意味：BLOCKID FILE ID
機能：再生管理ファイルの先頭であることを識別するための値。
値：固定値＝”ＴＬ＝０”（例えば０ｘ５４４Ｃ２Ｄ３０）
ＭＣｏｄｅ（２バイト）
意味：MAKER CODE
機能：記録した機器の、メーカー、モデルを識別するコード。
値：上位１０ビット（メーカーコード） 下位６ビット（機種コード）
ＲＥＶＩＳＩＯＮ（４バイト）
意味：再生管理ファイル（ＰＢＬＩＳＴ）の書き換え回数。
機能：再生管理ファイルを書き換える度にインクリメントする。
値：０より始まり＋１づつ増加する。
【００７２】
ＳＮ１Ｃ＋Ｌ（２バイト）
意味：ＮＭ１−Ｓ領域に書かれるメモリカードの名前（１バイト）の属性を表す。
機能：使用する文字コードと言語コードを各１バイトで表す。
値：文字コード（Ｃ）は上位１バイトで下記のように文字を区別する。
00: 文字コードは設定しない。単なる２進数として扱う。
01: ASCII 02:ASCII+KANA 03:modifided8859-1
81:MS-JIS 82:KS C 5601-1989 83:GB2312-80 90:S-JIS(for Voice) 。
言語コード（Ｌ）は下位１バイトで下記のようにEBU Tech 3258 規定に準じて言語を区別する。
00: 設定しない 08:German 09:English 0A:Spanish
0F:French 15:Italian 1D:Dutch
65:Korean 69:Japanese 75:Chinese
データが無い場合オールゼロとする。
【００７３】
ＳＮ２Ｃ＋Ｌ（２バイト）
意味：ＮＭ２−Ｓ領域に書かれるメモリカードの名前（２バイト）の属性を表す。
機能：使用する文字コードと言語コードを各１バイトで表す。
値：上述したＳＮ１Ｃ＋Ｌと同一。
ＳＩＮＦＳＩＺＥ（２バイト）
意味：ＩＮＦ−Ｓ領域に書かれるメモリカード全体に関する付加情報の全てを合計したサイズを表す。
機能：データサイズを１６バイト単位の大きさで記述、無い場合は必ずオールゼロとする。
値：サイズは０ｘ０００１から０ｘ３９Ｃ（９２４）。
【００７４】
Ｔ−ＴＲＫ（２バイト）
意味：TOTAL TRACK NUMBER
機能：総トラック数。
値：１から０ｘ０１９０（最大４００トラック）、データが無い場合はオールゼロとする。
ＶｅｒＮｏ（２バイト）
意味：フォーマットのバージョン番号。
機能：上位がメジャーバージョン番号、下位がマイナーバージョン番号。
値：例 ０ｘ０１００（Ｖｅｒ１．０）
０ｘ０２０３（Ｖｅｒ２．３）
【００７５】
上述したヘッダに続く領域に書かれるデータは以下のようになる。
【００７６】
ＮＭ１−Ｓ
意味：メモリカード全体に関する１バイトの名前。
機能：１バイトの文字コードで表した可変長の名前データ（最大で２５６）。
名前データの終了は、必ず終端コード（０ｘ００）を書き込む。
サイズはこの終端コードから計算する。データの無い場合は少なくとも先頭（０ｘ００２０）からヌル（０ｘ００）を１バイト以上記録する。
値：各種文字コード
ＮＭ２−Ｓ
意味：メモリカード全体に関する２バイトの名前。
機能：２バイトの文字コードで表した可変長の名前データ（最大で５１２）。
名前データの終了は、必ず終端コード（０ｘ００）を書き込む。
サイズはこの終端コードから計算する。データの無い場合は少なくとも先頭（０ｘ０１２０）からヌル（０ｘ００）を２バイト以上記録する。
値：各種文字コード。
【００７７】
ＣＯＮＴＥＮＴＳ ＫＥＹ
意味：曲ごとに用意された値。
ＭＧ（Ｍ）で保護されてから保存される。ここでは、１曲目に付けられるＣＯＮＴＥＮＴＳ ＫＥＹと同じ値となる。
機能：Ｓ−ＹＭＤｈｍｓのＭＡＣの計算に必要な鍵となる。
値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦまで。
ＭＡＣ
意味：著作権情報改ざんチェック値
機能：Ｓ−ＹＭＤｈｍｓの内容とＣＯＮＴＥＮＴＳ ＫＥＹから作成される値
値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦまで。
【００７８】
ＴＲＫ−ｎｎｎ
意味：再生するＡＴＲＡＣ３データファイルのＳＱＮ（シーケンス）番号
機能：ＴＲＫＩＮＦの中のＦＮｏを記述する。
値：１から４００（０ｘ１９０）
トラックが存在しない時はオールゼロとする。
ＩＮＦ−Ｓ
意味：メモリカード全体に関する付加情報データ（例えば写真、歌詞、解説等の情報）
機能：ヘッダを伴った可変長の付加情報データ。
複数の異なる付加情報が並べられることがある。それぞれにＩＤとデータサイズが付けられている。個々のヘッダを含む付加情報データは最小１６バイト以上で４バイトの整数倍の単位で構成される。その詳細については、後述する
値：付加情報データ構成を参照
Ｓ−ＹＭＤｈｍｓ（４バイト）（Ｏｐｔｉｏｎ）
意味：信頼できる時計を持つ機器で記録した年・月・日・時・分・秒
機能：最終記録日時を識別するための値、ＥＭＤの時は必須。
値：２５〜３１ビット 年 ０〜９９（１９８０〜２０７９）
２１〜２４ビット 月 ０〜１２
１６〜２０ビット 日 ０〜３１
１１〜１５ビット 時 ０〜２３
０５〜１０ビット 分 ０〜５９
００〜０４ビット 秒 ０〜２９（２秒単位）。
【００７９】
再生管理ファイルの最後のスロットとして、ヘッダ内のものと同一のＢＬＫＩＤ−ＴＬ０と、ＭＣｏｄｅと、ＲＥＶＩＳＩＯＮとが書かれる。
【００８０】
例えば民生用オーディオ機器としては、メモリカードが記録中に抜かれたり、電源が切れることがあり、復活した時にこれらの異常の発生を検出することが必要とされる。
上述したように、ＲＥＶＩＳＩＯＮはブロックの先頭と末尾に書き込むようにし、この値を書き換える度に＋１インクリメントするようにしている。従って若し、ブロックの途中で異常終了が発生すると、先頭と末尾のＲＥＶＩＳＩＯＮの値が一致せず、異常終了を検出することができる。
このようにＲＥＶＩＳＩＯＮが２個存在することで、高い確率で異常終了を検出することができる。異常終了の検出時には、エラーメッセージの表示等の警告が発生する。
【００８１】
また、１ブロック（１６ＫＢ）の先頭部分に固定値ＢＬＫＩＤ−ＴＬ０を挿入しているので、ＦＡＴが壊れた場合の修復の目安に固定値を使用できる。すなわち、各ブロックの先頭の固定値を見れば、ファイルの種類を判別することが可能である。しかも、この固定値ＢＬＫＩＤ−ＴＬ０は、ブロックのヘッダおよびブロックの終端部分に二重に記述するので、その信頼性のチェックを行うことができる。なお、再生管理ファイルＰＢＬＩＳＴの同一のものを二重に記録しても良い。
【００８２】
なおＡＴＲＡＣ３データファイルは、再生管理ファイルと比較して、相当大きなデータ量（例えば数千のブロックが繋がる場合もある）であり、ＡＴＲＡＣ３データファイルに関しては、後述するように、ブロック番号ＢＬＯＣＫ ＳＥＲＩＡＬが付けられている。但し、ＡＴＲＡＣ３データファイルは、通常複数のファイルがメモリカード上に存在するので、ＣＯＮＮＵＭ０でコンテンツの区別を付けた上で、ＢＬＯＣＫ ＳＥＲＩＡＬを付けないと、重複が発生し、ＦＡＴが壊れた場合のファイルの復旧が困難となる。
【００８３】
同様に、ＦＡＴの破壊までにはいたらないが、論理を間違ってファイルとして不都合のあるような場合に、書き込んだメーカーの機種が特定できるように、メーカーコード（ＭＣｏｄｅ）がブロックの先頭と末尾に記録されている。
【００８４】
図１３は、再生管理ファイルに記録される付加情報データ（ＩＮＦ−Ｓ）の構成を示す。
付加情報の先頭に下記のヘッダが書かれる。ヘッダ以降に可変長のデータが書かれる。
【００８５】
ＩＮＦ
意味：FIELD ID
機能：付加情報データの先頭を示す固定値。
値：０ｘ６９
ＩＤ
意味：付加情報キーコード
機能：付加情報の分類を示す。
値：０から０ｘＦＦ
ＳＩＺＥ
意味：個別の付加情報の大きさ
機能：データサイズは自由であるが、必ず４バイトの整数倍でなければならない。また、最小１６バイト以上のこと。データの終わりより余りがでる場合はヌル（０ｘ００）で埋めておく。
値：１６から１４７８４（０ｘ３９Ｃ０）
ＭＣｏｄｅ
意味：MAKER CODE
機能：記録した機器の、メーカー、モデルを識別するコード。
値：上位１０ビット（メーカーコード） 下位６ビット（機種コード）
Ｃ＋Ｌ
意味：先頭から１２バイト目からのデータ領域に書かれる文字の属性を表す
機能：使用する文字コードと言語コードを各１バイトで表す。
値：前述のＳＮ１Ｃ＋Ｌと同じ
ＤＡＴＡ
意味：個別の付加情報データ
機能：可変長データで表す。実データの先頭は常に１２バイト目より始まり、長さ（サイズ）は最小４バイト以上、常に４バイトの整数倍でなければならない。データの最後から余りがある場合はヌル（０ｘ００）で埋める。
値：内容により個別に定義される。
【００８６】
図１４は、付加情報キーコードの値（０〜６３）と、付加情報の種類の対応の一例を示す。キーコードの値（０〜３１）が音楽関係（文字情報）に対して割り当てられ、その（３２〜６３）がＵＲＬ(Uniform Resource Locator)（Ｗｅｂ関係）に対して割り当てられている。アルバムタイトル、アーティスト名、ＣＭ等の文字情報が付加情報として記録される。
【００８７】
図１５は、付加情報キーコードの値（６４〜１２７）と、付加情報の種類の対応の一例を示す。キーコードの値（６４〜９５）がパス／その他に対して割り当てられ、その（９６〜１２７）が制御／数値・データ関係に対して割り当てられている。
例えば（ＩＤ＝９８）の場合では、付加情報がＴＯＣ−ＩＤとされる。ＴＯＣ−ＩＤは、ＣＤ（コンパクトディスク）のＴＯＣ情報に基づいて、最初の曲番号、最後の曲番号、その曲番号、総演奏時間、その曲演奏時間を示すものである。
【００８８】
図１６は、付加情報キーコードの値（１２８〜１５９）と、付加情報の種類の対応の一例を示す。キーコードの値（１２８〜１５９）が同期再生関係に対して割り当てられている。図１６中のＥＭＤ(Electronic Music Distribution）は、電子音楽配信の意味である。
【００８９】
図１７を参照して付加情報のデータの具体例について説明する。図１７（ａ）は、図１３と同様に、付加情報のデータ構成を示す。
図１７（ｂ）は、キーコードＩＤ＝３とされる、付加情報がアーティスト名の例である。ＳＩＺＥ＝０ｘ１Ｃ（２８バイト）とされ、ヘッダを含むこの付加情報のデータ長が２８バイトであることが示される。また、Ｃ＋Ｌが文字コードＣ＝０ｘ０１とされ、言語コードＬ＝０ｘ０９とされる。この値は、前述した規定によって、ＡＳＣＩＩの文字コードで、英語の言語であることを示す。そして、先頭から１２バイト目から１バイトデータでもって、「ＳＩＭＯＮ＆ＧＲＡＦＵＮＫＥＬ」のアーティスト名のデータが書かれる。付加情報のサイズは、４バイトの整数倍と決められているので、１バイトの余りが（０ｘ００）とされる。
【００９０】
図１７（ｃ）は、キーコードＩＤ＝９７とされる、付加情報がＩＳＲＣ(International Standard Recording Code：著作権コード) の例である。ＳＩＺＥ＝０ｘ１４（２０バイト）とされ、この付加情報のデータ長が２０バイトであることが示される。また、Ｃ＋ＬがＣ＝０ｘ００、Ｌ＝０ｘ００とされ、文字、言語の設定が無いこと、すなわち、データが２進数であることが示される。そして、データとして８バイトのＩＳＲＣのコードが書かれる。ＩＳＲＣは、著作権情報（国、所有者、録音年、シリアル番号）を示すものである。
【００９１】
図１７（ｄ）は、キーコードＩＤ＝９７とされる、付加情報が録音日時の例である。ＳＩＺＥ＝０ｘ１０（１６バイト）とされ、この付加情報のデータ長が１６バイトであることが示される。また、Ｃ＋ＬがＣ＝０ｘ００、Ｌ＝０ｘ００とされ、文字、言語の設定が無いことが示される。そして、データとして４バイト（３２ビット）のコードが書かれ、録音日時（年、月、日、時、分、秒）が表される。
【００９２】
図１７（ｅ）は、キーコードＩＤ＝１０７とされる、付加情報が再生ログの例である。ＳＩＺＥ＝０ｘ１０（１６バイト）とされ、この付加情報のデータ長が１６バイトであることが示される。また、Ｃ＋ＬがＣ＝０ｘ００、Ｌ＝０ｘ００とされ、文字、言語の設定が無いことが示される。そして、データとして４バイト（３２ビット）のコードが書かれ、再生ログ（年、月、日、時、分、秒）が表される。再生ログ機能を持つものは、１回の再生毎に１６バイトのデータを記録する。
【００９３】
３−５ データファイル
図１８は、１ＳＵがＮバイト（例えばＮ＝３８４バイト）の場合のＡＴＲＡＣ３データファイル（Ａ３Ｄｎｎｎｎ）のデータ配列を示す。
図１８には、図８で示したようなデータファイルとして、属性ヘッダとしてのブロックと、実際に音楽データが記録されるブロックとが示されている。
図１８には各ブロック（１６×２＝３２Ｋバイト）の各スロットの先頭のバイト（０ｘ００００〜０ｘ７ＦＦ０）が示されている。
【００９４】
図１８に示すように、属性ヘッダの先頭から３２バイトはヘッダとされ、２５６バイトが曲名領域ＮＭ１（２５６バイト）であり、５１２バイトが曲名領域ＮＭ２（５１２バイト）である。
属性ヘッダのヘッダには、下記のデータが書かれる。
【００９５】
ＢＬＫＩＤ−ＨＤ０（４バイト）
意味：BLOCKID FILE ID
機能：ＡＴＲＡＣ３データファイルの先頭であることを識別するための値。
値：固定値＝”ＨＤ＝０”（例えば０ｘ４８４４２Ｄ３０）
ＭＣｏｄｅ（２バイト）
意味：MAKER CODE
機能：記録した機器の、メーカー、モデルを識別するコード。
値：上位１０ビット（メーカーコード） 下位６ビット（機種コード）
ＢＬＯＣＫ ＳＥＲＩＡＬ（４バイト）
意味：トラック毎に付けられた連続番号
機能：ブロックの先頭は０から始まり次のブロックは＋１づつインクリメント編集されても値を変化させない。
値：０より始まり０ｘＦＦＦＦＦＦＦＦまで。
【００９６】
Ｎ１Ｃ＋Ｌ（２バイト）
意味：トラック（曲名）データ（ＮＭ１）の属性
機能：ＮＭ１に使用される文字コードと言語コードを各１バイトで表す。
値：ＳＮ１Ｃ＋Ｌと同一
Ｎ２Ｃ＋Ｌ（２バイト）
意味：トラック（曲名）データ（ＮＭ２）の属性
機能：ＮＭ２に使用される文字コードと言語コードを各１バイトで表す。
値：ＳＮ１Ｃ＋Ｌと同一
ＩＮＦＳＩＺＥ（２バイト）
意味：トラックに関する付加情報の全てを合計したサイズ
機能：データサイズを１６バイト単位の大きさで記述。無い場合は必ずオールゼロとする。
値：サイズは０ｘ００００から０ｘ３Ｃ６（９６６）
Ｔ−ＰＲＴ（２バイト）
意味：トータルパーツ数
機能：トラックを構成するパーツ数を表す。通常は１。
値：１から０ｘ２８５（６４５dec ）
Ｔ−ＳＵ（４バイト）
意味：トータルＳＵ数
機能：１トラック中の実際の総ＳＵ数を表す。曲の演奏時間に相当する。
値：０ｘ０１から０ｘ００１ＦＦＦＦＦ
ＩＮＸ（２バイト）（Ｏｐｔｉｏｎ）
意味：INDEX の相対場所
機能：曲のさびの部分（特徴的な部分）の先頭を示すポインタ。曲の先頭からの位置をＳＵの個数を１／４した数で指定する。これは、通常のＳＵの４倍の長さの時間（約９３ｍ秒）に相当する。
値：０から０ｘＦＦＦＦ（最大、約６０８４秒）
ＸＴ（２バイト）（Ｏｐｔｉｏｎ）
意味：INDEX の再生時間
機能：ＩＮＸ-nnnで指定された先頭から再生すべき時間のＳＵの個数を１／４した数で指定する。これは、通常のＳＵの４倍の長さの時間（約９３ｍ秒）に相当する。
値：０ｘ００００：無設定 ０ｘ０１から０ｘＦＦＦＥ（最大６０８４秒）
０ｘＦＦＦＦ：曲の終わりまで。
【００９７】
次に属性ヘッダにおける曲名領域ＮＭ１およびＮＭ２について説明する。
【００９８】
ＮＭ１
意味：曲名を表す文字列
機能：１バイトの文字コードで表した可変長の曲名（最大で２５６）。
名前データの終了は、必ず終端コード（０ｘ００）を書き込む。
サイズはこの終端コードから計算する。データの無い場合は少なくとも先頭（０ｘ００２０）からヌル（０ｘ００）を１バイト以上記録する。
値：各種文字コード
ＮＭ２
意味：曲名を表す文字列
機能：２バイトの文字コードで表した可変長の名前データ（最大で５１２）。
名前データの終了は、必ず終端コード（０ｘ００）を書き込む。
サイズはこの終端コードから計算する。データの無い場合は少なくとも先頭（０ｘ０１２０）からヌル（０ｘ００）を２バイト以上記録する。
値：各種文字コード。
【００９９】
属性ヘッダの固定位置（０ｘ０３２０）から始まる、８０バイトのデータをトラック情報領域ＴＲＫＩＮＦと呼び、主としてセキュリティ関係、コピー制御関係の情報を一括して管理する。ＴＲＫＩＮＦ内のデータについて、配置順序に従って以下に説明する。
【０１００】
ＣＯＮＴＥＮＴＳ ＫＥＹ（８バイト）
意味：曲毎に用意された値で、メモリカードのセキュリティブロックで保護されてから保存される。
機能：曲を再生する時、まず必要となる最初の鍵となる。Ｃ−ＭＡＣ［ｎ］計算時に使用される。
値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦまで
Ｃ−ＭＡＣ［ｎ］（８バイト）
意味：著作権情報改ざんチェック値
機能：コンテンツ累積番号を含む複数のＴＲＫＩＮＦの内容と隠しシーケンス番号から作成される値。
隠しシーケンス番号とは、メモリカードの隠し領域に記録されているシーケンス番号のことである。著作権対応でないレコーダは、隠し領域を読むことができない。また、著作権対応の専用のレコーダ、またはメモリカードを読むことを可能とするアプリケーションを搭載したパーソナルコンピュータは、隠し領域をアクセスすることができる。
【０１０１】
Ａ（１バイト）
意味：パーツの属性
機能：パーツ内の圧縮モード等の情報を示す
値：図１９を参照して以下に説明する
ただし、Ｎ＝０，１のモノラルは、ｂｉｔ７が１でサブ信号を０、メイン信号（Ｌ＋Ｒ）のみの特別なＪｏｉｎｔモードをモノラルとして規定する。ｂｉｔ２，１の情報は通常の再生機は無視しても構わない。
【０１０２】
Ａのビット０は、エンファシスのオン／オフの情報を形成し、ビット１は、再生ＳＫＩＰか、通常再生かの情報を形成し、ビット２は、データ区分、例えばオーディオデータか、ＦＡＸ等の他のデータかの情報を形成する。
ビット３は、未定義である。
ビット４、５、６を組み合わせることによって、図示のように、レート情報が規定される。
すなわち、Ｎは、この３ビットで表されるレートの値であり、モノ（Ｎ＝０，１），ＬＰ（Ｎ＝２），ＳＰ（Ｎ＝４），ＥＸ（Ｎ＝５，６），ＨＱ（Ｎ＝７）の５種類のモードについて、記録時間（６４ＭＢのメモリカードの場合）、データ転送レート、１ブロック内のＳＵ数、１ＳＵのバイト数がそれぞれ示されている。
ビット７は、ＡＴＲＡＣ３のモード（０：Dual １：Joint ）が示される。
【０１０３】
一例として、６４ＭＢのメモリカードを使用し、ＳＰモードの場合について説明する。６４ＭＢのメモリカードには、３９６８ブロックがある。ＳＰモードでは、１ＳＵが３０４バイトであるので、１ブロックに５３ＳＵが存在する。１ＳＵは、（１０２４／４４１００）秒に相当する。従って、１ブロックは、
（１０２４／４４１００）×５３×（３９６８−１６）＝４８６３秒＝８１分
転送レートは、
（４４１００／１０２４）×３０４×８＝１０４７３７ bps
となる。
【０１０４】
ＬＴ（１バイト）
意味：再生制限フラグ（ビット７およびビット６）とセキュリティバージョン（ビット５〜ビット０）
機能：このトラックに関して制限事項があることを表す。
値：ビット７： ０＝制限なし １＝制限有り
ビット６： ０＝期限内 １＝期限切れ
ビット５〜ビット０：セキュリティバージョン０（０以外であれば再生禁止とする）
ＦＮｏ（２バイト）
意味：ファイル番号
機能：最初に記録された時のトラック番号であり、且つこの値は、メモリカード内の隠し領域に記録されたＭＡＣ計算用の値の位置を特定する。
値：１から０ｘ１９０（４００）
ＭＧ（Ｄ）ＳＥＲＩＡＬ−ｎｎｎ（１６バイト）
意味：記録機器のセキュリティブロック（セキュリティＩＣ２０）のシリアル番号。
機能：記録機器ごとに全て異なる固有の値。
値：０から0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
ＣＯＮＮＵＭ（４バイト）
意味：コンテンツ累積番号
機能：曲毎に累積されていく固有の値で記録機器のセキュリティブロックによって管理される。２の３２乗、４２億曲分用意されており、記録した曲の識別に使用する。
【０１０５】
値：０から０ｘＦＦＦＦＦＦＦＦ。
【０１０６】
ＹＭＤｈｍｓ−Ｓ（４バイト）（Ｏｐｔｉｏｎ）
意味：再生制限付きのトラックの再生開始日時
機能：ＥＭＤで指定する再生開始を許可する日時。
値：上述した日時の表記と同じ。
ＹＭＤｈｍｓ−Ｅ（４バイト）（Ｏｐｔｉｏｎ）
意味：再生制限付きのトラックの再生終了日時
機能：ＥＭＤで指定する再生許可を終了する日時。
値：上述した日時の表記と同じ。
ＭＴ（１バイト）（Ｏｐｔｉｏｎ）
意味：再生許可回数の最大値
機能：ＥＭＤで指定される最大の再生回数。
値：１から０ｘＦＦ 未使用の時は、０ｘ００である。
ＬＴのｂｉｔ７の値が０の場合はＭＴの値は００とする。
ＣＴ（１バイト）（Ｏｐｔｉｏｎ）
意味：再生回数
機能：再生許可された回数の内で、実際に再生できる回数。再生の度にデクリメントする。
値：０ｘ００〜０ｘＦＦ 未使用の時は、０ｘ００である。
ＬＴのｂｉｔ７が１でＣＴの値が００の場合は再生を禁止する。
【０１０７】
ＣＣ（１バイト）
意味：COPY CONTROL
機能：コピー制御
値：図２０に示すように、ビット６および７によってコピー制御情報を表し、ビット４および５によって高速ディジタルコピーに関するコピー制御情報を表し、ビット１，２，３によってコピー属性を表す。ビット０は未定義である。
ＣＣの例：
ビット７・・・０：コピー禁止、１：コピー許可
ビット６・・・０：オリジナル、１：第１世代以上
ビット５，４・・・００：コピー禁止、０１：コピー第１世代、１０：コピー可
ビット３，２，１
００１：オリジナルソースから記録したコンテンツであることを示す。
０１０：ＬＣＭからコピーしたコンテンツであることを示す。
０１１：ＬＣＭからムーブしたコンテンツであることを示す。
１００以上：未定義。
なおＬＣＭとは、Licensed Compliant Moduleであり、例えばパーソナルコンピュータやコンシューマ機器におけるＨＤＤなどが相当する。
例えばＣＤからのディジタル録音では（ｂｉｔ７，６）は０１、（ｂｉｔ５，４）は００、（ｂｉｔ３，２，１）は００１或いは０１０となる。
【０１０８】
ＣＮ（１バイト）（Ｏｐｔｉｏｎ）
意味：高速ディジタルコピーＨＳＣＭＳ(High speed Serial Copy Management System)におけるコピー許可回数
機能：コピー１回か、コピーフリーかの区別を拡張し、回数で指定する。コピー第１世代の場合にのみ有効であり、コピーごとに減算する。
値：００：コピー禁止、０１から０ｘＦＥ：回数、０ｘＦＦ：回数無制限。
【０１０９】
データファイルにおける属性ヘッダにおいては、以上のようなトラック情報領域ＴＲＫＩＮＦに続いて、０ｘ０３７０から始まる２４バイトのデータをパーツ管理用のパーツ情報領域ＰＲＴＩＮＦと呼び、１つのトラックを複数のパーツで構成する場合に、時間軸の順番にＰＲＴＩＮＦを並べていく。ＰＲＴＩＮＦ内のデータについて、配置順序に従って以下に説明する。
【０１１０】
ＰＲＴＳＩＺＥ（４バイト）
意味：パーツサイズ
機能：パーツの大きさを表す。クラスタ：２バイト（最上位）、開始ＳＵ：１バイト（上位）、終了ＳＵ：１バイト（最下位）
値：クラスタ：１から０ｘ１Ｆ４０（８０００）、開始ＳＵ：０から０ｘＡ０（１６０）、終了ＳＵ：０から０ｘＡ０（１６０）（但し、ＳＵの数え方は、０，１，２，と０から開始する）
ＰＲＴＫＥＹ（８バイト）
意味：パーツを暗号化するための値
機能：初期値＝０、編集時は編集の規則に従う。
値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦ
ＣＯＮＮＵＭ０（４バイト）
意味：最初に作られたコンテンツ累積番号キー
機能：コンテンツをユニークにするためのＩＤの役割。
値：コンテンツ累積番号初期値キーと同じ値とされる。
【０１１１】
ＡＴＲＡＣ３データファイルの属性ヘッダ中には、図１８に示すように、付加情報ＩＮＦが含まれる。この付加情報は、開始位置が固定化されていない点を除いて、再生管理ファイル中の付加情報ＩＮＦ−Ｓ（図１２参照）と同一である。１つまたは複数のパーツの最後のバイト部分（４バイト単位）の次を開始位置として付加情報ＩＮＦのデータが開始する。
【０１１２】
ＩＮＦ
意味：トラックに関する付加情報データ
機能：ヘッダを伴った可変長の付加情報データ。複数の異なる付加情報が並べられることがある。それぞれにＩＤとデータサイズが付加されている。個々のヘッダを含む付加情報データは、最小１６バイト以上で４バイトの整数倍の単位
値：再生管理ファイル中の付加情報ＩＮＦ−Ｓと同じである。
【０１１３】
以上のような属性ヘッダに対して、ＡＴＲＡＣ３データが記録される各ブロックのデータが続く。図８にも示したように、ブロック毎にヘッダが付加される。図１８に示す、ブロック内のデータについて以下に説明する。
【０１１４】
ＢＬＫＩＤ−Ａ３Ｄ（４バイト）
意味：BLOCKID FILE ID
機能：ＡＴＲＡＣ３データの先頭であることを識別するための値。
値：固定値＝”Ａ３Ｄ”（例えば０ｘ４１３３４４２０）
ＭＣｏｄｅ（２バイト）
意味：MAKER CODE
機能：記録した機器の、メーカー、モデルを識別するコード。
値：上位１０ビット（メーカーコード） 下位６ビット（機種コード）
ＣＯＮＮＵＭ０（４バイト）
意味：最初に作られたコンテンツ累積番号
機能：コンテンツをユニークにするためのＩＤの役割、編集されても値は変化させない。
値：コンテンツ累積番号初期値キーと同じ値とされる。
ＢＬＯＣＫ ＳＥＲＩＡＬ（４バイト）
意味：トラック毎に付けられた連続番号
機能：ブロックの先頭は０から始まり次のブロックは＋１づつインクリメント編集されても値を変化させない。
値：０より始まり０ｘＦＦＦＦＦＦＦＦまで。
ＢＬＯＣＫ−ＳＥＥＤ（８バイト）
意味：１ブロックを暗号化するための１つの鍵
機能：ブロックの先頭は、記録機器のセキュリティブロックで乱数を生成、続くブロックは、＋１インクリメントされた値。この値が失われると、１ブロックに相当する約１秒間、音が出せないために、ヘッダとブロック末尾に同じものが二重に書かれる。編集されても値を変化させない。
値：初期は８バイトの乱数。
ＩＮＩＴＩＡＬＩＺＡＴＩＯＮ ＶＥＣＴＯＲ（８バイト）
意味：ブロック毎にＡＴＲＡＣ３データを暗号化、復号化する時に必要な初期値
機能：ブロックの先頭は０から始まり、次のブロックは最後のＳＵの最後の暗号化された８バイトの値。デバイドされたブロックの途中からの場合は開始ＳＵの直前の最後の８バイトを用いる。編集されても値を変化させない。
値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦ
ＳＵ−ｎｎｎ
意味：サウンドユニットのデータ
機能：１０２４サンプルから圧縮されたデータ、圧縮モードにより出力されるバイト数が異なる。編集されても値を変化させない（一例として、ＳＰモードの時では、Ｎ＝３８４バイト）。
値：ＡＴＲＡＣ３のデータ値。
【０１１５】
図１８では、Ｎ＝３８４であるので、１ブロックに４２ＳＵが書かれる。また、１ブロックの先頭の２つのスロット（４バイト）がヘッダとされ、最後の１スロット（２バイト）にＢＬＫＩＤ−Ａ３Ｄ、ＭＣｏｄｅ、ＣＯＮＮＵＭ０、ＢＬＯＣＫ ＳＥＲＩＡＬが二重に書かれる。従って、１ブロックの余りの領域Ｍバイトは、（１６，３８４−３８４×４２−１６×３＝２０８（バイト）となる。この中に上述したように、８バイトのＢＬＯＣＫ ＳＥＥＤが二重に記録される。
【０１１６】
４．記録処理
４−１ 処理例１
以下、本例のレコーダ１によるコンテンツ（曲）の記録動作時の処理例について説明していく。
上述してきた説明から理解されるように、メモリカード４０に対するコンテンツの記録は、コンテンツデータの記録だけではなく、１ブロック（１クラスタ）分の容量である再生管理ファイルの生成又は更新があって、完了するものである。またコンテンツのデバイド、コンバイン等の編集は再生管理ファイルの更新によって実現される。
また、メモリカード４０上での再生管理ファイルの記録位置（絶対アドレス）は、再生管理ファイルの更新のための書込のたびに異なる位置とされていく。
さらに、デバイド編集が行われる場合は、１クラスタ（１ブロック）を新たに使用することが必要となる。
【０１１７】
このような事情から、もしコンテンツの記録をメモリカードの全ての容量に対して行ってしまうと、その記録動作にかかる再生管理ファイルの作成又は更新ができなくなる。或いは、コンテンツと再生管理ファイルを含めてメモリカードの全ての容量を使い切ってしまうと、その後、デバイド等の編集ができないものとなってしまう。
そこで本例では、記録動作時には、或る程度の容量が残されるようにして記録が終了するようにするものである。
ただ、このような処理により、コンテンツを記録できる容量が、残される容量の分だけ減ることになるため、残される容量は適切な量としなければならない。
【０１１８】
一般に平均的な演奏時間の音楽を記録する場合、１つの記録媒体（メモリカード）の曲数（コンテンツ数）は２０曲程度までとなる。
また、ＦＭ放送等を１時間分録音した場合は、その１時間分のデータは１つのコンテンツとして扱われる。ユーザーは、録音した放送からデバイドによって、各曲を分割する操作を行う。
これらの事情から、２０回程度のデバイドが行われる可能性が高いとして、例えば２０クラスタ（２０ブロック）分程度を、上記の残される容量とする方式が考えられる。
また、既に１０曲（３０分）のコンテンツが記録されているような状態では、統計的にはあと１０クラスタ（１０ブロック）分程度を、上記の残される容量とすれば、その後のデバイド編集などに、ほぼ対応できると推定できる。そこで、記録開始時に、既に記録されているコンテンツ数に応じて、残される容量を設定する方式も考えられる。
或いは、既に記録されているコンテンツの平均的なサイズと全容量の関係から残される容量を設定するようにしてもよい。
大まかにいえば、メモリカードにおいてコンテンツ数が少なくその各コンテンツのサイズが大きい場合は、その後に何回か編集される可能性が高くなるため、その傾向に応じて、残される容量を設定すると好適である。
【０１１９】
いづれにしても本例では、記録後における編集回数の可能性に応じて、残される容量が設定されるようにする。
【０１２０】
レコーダ１のＤＳＰ３０が、ライン入力セレクタ１３又はデジタル入力セレクタ１６から入力され、オーディオエンコーダ／デコーダ１０でエンコード処理、セキュリティＩＣ２０で暗号化処理が施されたデータを、メモリカード４０に記録していく際の処理を図２１に示す。
【０１２１】
記録が開始される際には、ＤＳＰ３０は、まずステップＦ１０１で、装填されているメモリカード４０の管理情報（再生管理ファイル）から、メモリカード４０に既にコンテンツ（データファイル）が記録されているか否かを判別する。
まだ１つもデータファイルが記録されていないメモリカード４０であった場合は、処理をステップＦ１０２に進め、変数Ｌに「２０」をセットする。
これは上述のように、通常、２０曲程度の収録状態が考えられ、換言すれば２０回程度のデバイドが行われる可能性が考えられるためである。もちろん「２０」という値は一例にすぎず、メモリカードの容量等に応じて適切な値が設定されるべきである。また、この「２０」に相当する値を、ユーザーが自分の事情や記録内容、例えば編集を何回も行うか否かに合わせて、任意に増減できるようにしてもよい。
【０１２２】
そしてステップＦ１０８で、Ｌクラスタ、即ちこの場合は２０クラスタ（２０ブロック）分を、余りブロックとして確保する。
ここでいう余りブロックとは、上述した残される容量のことであり、つまり記録終了時点で残されるべき容量としてのブロック数である。
【０１２３】
メモリカード４０にすでに１つ以上のデータファイルが記録されていた場合は、ＤＳＰ３０の処理はステップＦ１０３に進み、記録されているデータファイルの平均ファイルサイズＭを算出する。
これは、既にデータファイルの記録に使用されている容量を、データファイル数で割れば算出できる。
平均ファイルサイズＭが算出できたら、ステップＦ１０４で、メモリカード４０の全容量を平均ファイルサイズＭで割って、予測総ファイル数Ｎを算出する。
予測総ファイル数Ｎとは、メモリカード４０の全容量を使用した場合に、いくつのデータファイルが記録されているかの予測値である。
【０１２４】
そしてＤＳＰ３０はステップＦ１０５で予測総ファイル数Ｎが「２０」以下であるか否かを判別する。ここでの「２０」も、一般的な平均としての収録曲数として用いており、「２０」に限定されるものではない。
【０１２５】
予測総ファイル数Ｎが「２０」以下である場合は、２０曲は記録される可能性があると判断して、ステップＦ１０６で、「２０」から既に記録されているデータファイル数を減算した値を、変数Ｌにセットする。
そしてステップＦ１０８で、Ｌクラスタ（Ｌブロック）分を、余りブロックとして確保する。
【０１２６】
一方、ステップＦ１０５で、予測総ファイル数Ｎが「２０」を越えているとされた場合は、予測総ファイル数Ｎの数だけデータファイルが記録される可能性があると判断して、ステップＦ１０７で、予測総ファイル数Ｎから既に記録されているデータファイル数を減算した値を、変数Ｌにセットする。
そしてステップＦ１０８で、Ｌクラスタ（Ｌブロック）分を、余りブロックとして確保する。
【０１２７】
ステップＦ１０８として余りブロックが設定されたら、ステップＦ１０９からオーディオデータによるデータファイルの記録を開始する。
データファイルは上述したようにブロック単位で記録されていくことになる。
【０１２８】
記録動作中は、ステップＦ１１０で、余りブロックを除いてメモリカード４０における記録可能な残り容量がゼロになったか否かを監視している。
またステップＦ１１１では、記録終了、即ちユーザの指示した１又は複数のデータファイルの記録が完了したか、或いはユーザーが操作部３９から記録停止操作を行ったことなどにより記録が終了されるものとなったか、を監視する。
さらにステップＦ１１２では、供給されているオーディオデータとして、ファイルチェンジ、即ち曲が変わって、別のデータファイルの記録に移行することになったかを監視する。
このファイルチェンジ、即ち曲の変化は、例えばＭＤ、ＣＤ等の記録媒体から曲がデジタルオーディオデータとして供給されている場合において、そのデジタルデータ内に含まれているトラックナンバ情報を監視することなどで可能となる。また、ライン入力セレクタ１３からのアナログオーディオ信号について記録している場合でも、例えば無音期間の検出などにより、ファイルチェンジと判断するようにしてもよい。
【０１２９】
ステップＦ１１０で肯定結果がでるより前に、ステップＦ１１１で記録終了となった場合は、ＤＳＰ３０はステップＦ１１８で、記録したコンテンツについての再生管理ファイルの作成（又は更新）を行って、記録処理を終える。
この場合は、メモリカード４０における記録可能な容量は、その後の記録や編集のためには、まだ十分に残されている状態である。
【０１３０】
記録動作中においてステップＦ１１２で、記録するオーディオデータについてのファイルチェンジが検出された場合は、そのファイルチェンジポイントまでのオーディオデータが記録されたブロックで、１つのデータファイルが形成されることになる。
そこでステップＦ１１３で変数Ｌをデクリメントし、その時点で変数Ｌが「１」よりも大きければ、ステップＦ１０８に戻って、Ｌクラスタ分を余りブロックとして確保する。つまり余りブロックとしての設定を１ブロック少なくする。
これは、１つのデータファイルが記録されたことで、その後のデバイド回数の可能性が１回減ったと考えることができるためである。
そして、ステップＦ１０９から新たなデータファイルとして、続くオーディオデータを新たなブロックの先頭とした上で、その後の記録を行っていく。
【０１３１】
なお、記録中に１９回トラックチェンジが検出されると、ステップＦ１１４の時点で変数Ｌ＝０となる。
そしてこれは、続くオーディオデータが、２０曲目として記録されていく場合である。この場合、録音後においてデバイド編集が行われる可能性がきわめて低いものとなるため、それだけを考えれば、変数Ｌ＝０となることに応じて、余りブロックをゼロとしてしまってもよいが、実際には録音後に再生管理ファイルの書込が必要となるため、少なくとも録音終了時点で１ブロックは残されていなければならない。
そこで、ステップＦ１１４で変数Ｌが１未満（つまり０）となった場合は、ステップＦ１１６で、変数Ｌ＝１として、ステップＦ１０８で少なくとも１ブロックは余りブロックとして確保されるようにする。
また、この場合、余りブロックが記録終了後の再生管理ファイルの書込に用いられ、それによってメモリカード４０の全容量が消費されると、その後の編集はできないものとなる。
そこで、ステップＦ１１５では、ユーザーに対して記録終了後の編集ができなくなるおそれがあることを提示する。例えば表示部３３にその旨のメッセージを表示する。但し、その後、ステップＦ１１０で肯定結果が出る前に、ステップＦ１１１で記録終了と判断された場合、即ち余りブロック以外にも記録可能なブロックが残されている場合は、まだ記録又は編集が可能であるため、この時点では必ずしも警告表示を行わなくてもよい。
【０１３２】
ステップＦ１１０において、その時点で余りエリアとして設定されているブロック数を残して、他に記録可能なブロックが使い切られてしまったと判断された場合は、ＤＳＰ３０はステップＦ１１７に進み、強制的に記録動作を停止する。
そしてステップＦ１１８で記録したコンテンツについての再生管理ファイルの作成（又は更新）を行って、記録処理を終える。
この場合は、メモリカード４０における記録可能な容量は、余りエリアとして設定されていたブロック数のみが残されている状態である。
そしてその余りブロックとしてのブロック数は、上述したように、通常２０曲が収録されること、平均データサイズと全容量の関係から収録曲数が推定されること、及びそれらの収録曲数から、既に収録済みの曲数が減算されることなどに応じて設定される。さらに記録中に曲が分かれれば（ファイルチェンジ）、余りブロック数はデクリメントされていく。
これらのことから、記録終了時点で、その後に少なくとも一般的に予測されるだけの編集回数は、編集可能とするに足りるブロック数となる。
従って、コンテンツ記録時に、ユーザーがメモリカード４０の記録可能エリアを使い切ってしまったと感じる場合でも、少なくとも通常必要となる回数の編集は、可能とされることになり、ユーザーに不都合を感じさせるものではなくなる。
また一方で、上記のように余りブロック数が変数Ｌに応じて設定され、また記録中にデクリメントされることで、余りブロック数は、通常必要とされる編集回数を、コンテンツ記録状況に応じて、最低限の回数として設定されるものとなる。これは、余りブロック数を多く設定しすぎて、それによりコンテンツの記録可能容量を必要以上に小さくしてしまうものではないことを意味する。
つまり、本例の記録処理により、なるべくコンテンツの記録容量は減少させないようにした上で、その後に必要とされる編集は実行可能な状態とすることができる。
【０１３３】
なお、上述のように余りブロックが１ブロックまで減ぜられた状態で、ステップＦ１１０，Ｆ１１７で記録が終了されると、その余りブロックとされた１ブロックは、再生管理ファイルの記録に用いられるものとなり、その時点で全てのブロックが使用済みとなる。つまり以降は、編集ができない。（本例の考え方によれば、この場合は、２０或いはそれ以上の曲数に既に分割されているため、デバイド編集の必要がない状態となっている）。
そこで、ステップＦ１１５として説明した警告処理は、このような場合に実行するようにしてもよい。
またその時点で、編集操作を無効とする編集禁止処理を行ってもよい。
なお、この場合において、再生管理ファイルが新規に或るブロックに記録されるのではなく、いままでの再生管理ファイルが「更新」される場合は、旧再生管理ファイルが記録されていたブロックは、書込可能なブロックとなる。
従って、コンバイン、ムーブ、イレーズなど、再生管理ファイルの更新のみで実現される編集は可能である。
そこで、そのような場合は、上記警告や編集禁止処理は、デバイド編集に限ったものとして行ってもよい。
【０１３４】
ところで、以上の処理の説明では、記録終了時点のステップＦ１１８での再生管理ファイルの書込に用いるブロックも、少なくとも余りブロックとして確保されるものとして説明したが、ステップＦ１１８での再生管理ファイルの書込に用いるブロックは、「余りブロック」とは別に確保されているとして、図２１の処理を考えてもよい。
その場合、上記のように余りブロックが１ブロックまで減ぜられた状態で、ステップＦ１１０，Ｆ１１７で記録が終了され、再生管理ファイルの記録が行われても、余りブロックとされた１ブロックは残されている。従って、コンバイン、ムーブ、イレーズなど、再生管理ファイルの更新のみで実現される編集は可能である。またさらに再生管理ファイルが更新された場合は、旧再生管理ファイルの記録されていたブロックも書込可能となるため、２ブロックが書き込み可能であり、デバイドも可能である。
従って、上記警告表示や編集禁止処理は、これらの事情に応じて行うことが好ましい。
【０１３５】
また、図２１の処理例では、ファイルチェンジに応じて余りブロック数が単純に減ぜられていくようにしたが、ファイルチェンジのタイミングまでのオーディオデータで形成されたデータファイルを含めて、ステップＦ１０３〜Ｆ１０７のような平均ファイルサイズと全容量に応じた余りブロック設定が行われるようにして、余りブロックの設定が変化されていくようにしてもよい。
【０１３６】
４−２ 処理例２
続いて図２２で、処理例２としての記録処理を説明する。
なお図２２において、上記図２１と同一の処理については、ステップＦ１０１〜Ｆ１１８として同一ステップ番号を付し、説明を省略する。
即ちこの処理例２は、上記図２１の処理に、ステップＦ１００及びＦ１１９〜１２１が追加されたものである。
【０１３７】
この場合は、ユーザーが、記録後における編集を可能とするために余りブロックを設定するか、或いは、そのようなことを考慮せずに、できるだけコンテンツの記録可能容量を多くするかを選択できるようにしたものである。
つまりユーザーは、例えば操作部３９からの操作により、余りブロック量を除いた記録可能なブロック残量がゼロとなったら記録動作を終了させる動作モードと、メモリカード４０上で記録可能なブロック残量がゼロとなるまで記録動作を続行可能とする動作モード（使い切り設定）とを選択できるようにしている。
【０１３８】
ユーザーが、使い切り設定を行わずに記録を開始させた場合は、ＤＳＰ３０の記録処理は図２１と同様の処理となる（Ｆ１０１〜Ｆ１１８）。
ところがユーザーが使い切り設定を行って記録動作を開始させた場合は、ＤＳＰ３０はステップＦ１１９，Ｆ１２０，Ｆ１２１の処理を行う。
即ちステップＦ１１９からオーディオデータによるデータファイルの記録を開始する。データファイルはブロック単位で記録されていくことになる。
【０１３９】
そして記録動作中は、ステップＦ１２０で、メモリカード４０における記録可能な残り容量が残り１ブロックになったか否かを監視している。
またステップＦ１２１では、記録終了、即ちユーザの指示した１又は複数のデータファイルの記録が完了したか、或いはユーザーが操作部３９から記録停止操作を行ったことなどにより記録が終了されるものとなったか、を監視する。
なお、記録中に供給されているオーディオデータとして、ファイルチェンジが検出された場合は、そのファイルチェンジポイントまでのオーディオデータが記録されたブロックで、１つのデータファイルが形成される。そして新たなデータファイルとして、続くオーディオデータを新たなブロックの先頭とした上で、その後の記録を行っていく。
【０１４０】
ステップＦ１２０で肯定結果がでるより前に、ステップＦ１２１で記録終了となった場合は、ＤＳＰ３０はステップＦ１１８で、記録したコンテンツについての再生管理ファイルの作成（又は更新）を行って、記録処理を終える。
この場合は、メモリカード４０における記録可能な容量は、その後の記録や編集のためには、まだ十分に残されている状態である。
【０１４１】
ステップＦ１２０において、その時点で１ブロック数を残して、記録可能なブロックが使い切られてしまったと判断された場合は、ＤＳＰ３０はステップＦ１１７に進み、強制的に記録動作を停止する。
そしてステップＦ１１８で、残りの１ブロックに対して、記録したコンテンツについての再生管理ファイルの作成（又は更新）を行って、記録処理を終える。
この場合は、メモリカード４０における記録可能な容量が最大限、コンテンツの記録に用いられたことになる。
つまりこの処理例２では、ユーザーの選択によって、もし記録後の編集を考えない場合であるなら、メモリカード４０の容量をコンテンツの記録に最大限利用できるようにするものである。
【０１４２】
４−３ 処理例３
図２３に処理例３を示す。
この処理例は、余りブロックの設定を固定化したもので、また記録終了時点では、少なくとも固定値の余りブロックとしてのブロック数は、記録可能として確保されるようにした例である。
【０１４３】
即ち記録が開始される際には、ＤＳＰ３０はステップＦ２０１で、或る設定された固定値としてｘクラスタ分を余りブロックとして設定する。
そしてステップＦ２０２からオーディオデータによるデータファイルの記録を開始する。データファイルはブロック単位で記録されていく。
【０１４４】
そして記録動作中は、ステップＦ２０３で、メモリカード４０における記録可能な残り容量が、ｘ個の余りブロックを除いてゼロとなったか否かを監視し、またステップＦ２０４では、記録終了、即ちユーザの指示した１又は複数のデータファイルの記録が完了したか、或いはユーザーが操作部３９から記録停止操作を行ったことなどにより記録が終了されるものとなったか、を監視する。
なお、記録中に供給されているオーディオデータとして、ファイルチェンジが検出された場合は、そのファイルチェンジポイントまでのオーディオデータが記録されたブロックで、１つのデータファイルが形成される。そして新たなデータファイルとして、続くオーディオデータを新たなブロックの先頭とした上で、その後の記録を行っていく。
【０１４５】
ステップＦ２０３で肯定結果がでるより前に、ステップＦ２０４で記録終了となった場合は、ＤＳＰ３０はステップＦ２０６で、記録したコンテンツについての再生管理ファイルの作成（又は更新）を行って、記録処理を終える。
この場合は、メモリカード４０における記録可能な容量は、その後の記録や編集のためには、まだ十分に残されている状態である。
【０１４６】
ステップＦ２０３において、その時点でｘブロック数を残して、記録可能なブロックが使い切られてしまったと判断された場合は、ＤＳＰ３０はステップＦ２０５に進み、強制的に記録動作を停止する。
そしてステップＦ２０６で、ｘブロックのうちの１ブロックを用いて、記録したコンテンツについての再生管理ファイルの作成（又は更新）を行って、記録処理を終える。
この場合は、メモリカード４０における記録可能な容量として余りブロックとして設定された（ｘ−１）ブロック分だけ残された状態となる。
【０１４７】
つまりこの処理例３では、記録終了時点で、少なくとも（ｘ−１）ブロック分の容量が残され、その分だけその後の編集が可能となる。
固定的に設定されるｘの値としては、例えば統計的に妥当と考えられる値としてもよいし、例えばユーザーが任意に設定できるようにして、ユーザーの事情や記録内容に合致した処理が行われるようにすることもできる。
【０１４８】
以上、本発明の実施の形態としての例を説明してきたが、実施の形態の例はあくまでも一例であり、レコーダの構成、処理方式などは、多様に考えられる。
特に余りブロック数の設定方式は、各種の多様な変形例が考えられる。
また上記例ではオーディオデータとしてのコンテンツ（プログラム）を想定して説明したが、ビデオデータとしてのコンテンツについても、全く同様に本発明を適用できる。テキストデータその他のコンテンツについても同様である。
【０１４９】
【発明の効果】
以上の説明から分かるように本発明では、記録動作に際して所要量の余りブロック量を設定するとともに、プログラム記録動作により、記録媒体上で、余りブロック量を除いた記録可能なブロック残量がゼロとなったら、プログラム記録動作を終了させるようにしているため、プログラム（コンテンツ）の記録終了後において、少なくとも上記余りブロック量に相当する記録可能容量が残されるものとなる。
そして管理情報の記録又は更新、及び／又は記録されたプログラムの編集に用いられるブロックとして、余りブロック量が設定されていることで、プログラムの記録を完結させるための管理情報の書込／更新、或いはその後のプログラムの編集のために用いる領域が確保されていることになり、つまり記録や編集が適切に実行できる状態を確保できるという効果がある。
また、余りブロック量は、プログラム記録手段による記録動作の際に、記録媒体上に記録されているプログラム数に応じて設定すること、或いは記録媒体上に記録されているプログラムの平均データサイズと記録媒体の容量に応じて設定することで、その記録媒体のプログラム記録状況に合致した適切な量とすることができ、余りブロック量が多すぎてむやみにプログラム記録領域が削減されたり、或いは逆に、その後の編集等のために十分なブロック量が確保できないということを避けられる。
【０１５０】
また記録媒体において記録可能なブロック残量が所定以下となったら、その記録媒体に記録されているプログラムについての編集処理が不可とされることの警告を出力することで、ユーザーに状況を告知できる。
【０１５１】
また記録媒体上で前記余りブロック量を除いた記録可能なブロック残量がゼロとなったらプログラム記録動作を終了させる動作モードと、記録媒体上で記録可能なブロック残量がゼロとなるまでプログラム記録動作を続行可能とする動作モードとを選択できるようにすることで、ユーザーの事情に応じて、記録媒体の記録容量を有効に利用できるようにすることができる。
【図面の簡単な説明】
【図１】本発明の実施の形態のレコーダのブロック図である。
【図２】実施の形態のレコーダのＤＳＰのブロック図である。
【図３】実施の形態のメモリカードの構成を示すブロック図である。
【図４】実施の形態におけるメモリカードのファイルシステム処理階層の構成の説明図である。
【図５】実施の形態のメモリカードのデータの物理的構成のフォーマットの説明図である。
【図６】実施の形態のメモリカードのディレクトリ構造の説明図である。
【図７】実施の形態のメモリカードの再生管理ファイルのデータ構成の説明図である。
【図８】実施の形態のメモリカードのデータファイルのデータ構成の説明図である。
【図９】実施の形態のデータファイルの構成の説明図である。
【図１０】実施の形態のデータファイルのコンバイン編集処理の説明図である。
【図１１】実施の形態のデータファイルのデバイド編集処理の説明図である。
【図１２】実施の形態の再生管理ファイルの構成の説明図である。
【図１３】実施の形態の再生管理ファイルの付加情報領域の構成の説明図である。
【図１４】実施の形態の付加情報キーコードの説明図である。
【図１５】実施の形態の付加情報キーコードの説明図である。
【図１６】実施の形態の付加情報キーコードの説明図である。
【図１７】実施の形態における付加情報の具体的なデータ構成の説明図である。
【図１８】実施の形態のデータファイルの構成の説明図である。
【図１９】実施の形態のデータファイルの属性ヘッダの「Ａ」の説明図である。
【図２０】実施の形態のデータファイルの属性ヘッダの「ＣＣ」の説明図である。
【図２１】実施の形態の記録処理のフローチャートである。
【図２２】実施の形態の記録処理のフローチャートである。
【図２３】実施の形態の記録処理のフローチャートである。
【符号の説明】
１，１Ａ，１Ｂ レコーダ、１０ オーディオエンコーダ／デコーダＩＣ、２０ セキュリティＩＣ、３０ ＤＳＰ、４０ メモリカード、４２ フラッシュメモリ、５２ セキュリティブロック
Claims (3)
- コンテンツとしてのプログラムを入力する入力手段と、
所定数の固定長とされたブロック単位で記録が行われる記録媒体に対して、前記入力手段に入力された前記プログラムを前記ブロック単位にブロック化して記録していくプログラム記録手段と、
前記ブロック単位に記録されたプログラムを管理する、プログラム数、各プログラムのデータサイズを記録した管理情報を記録媒体に記録し、又は更新する管理情報記録手段と、
前記管理情報記録手段による管理情報の記録又は更新、及び／又は記録されたプログラムの編集に用いられるブロックとして所要量の余りブロック量を設定するとともに、前記プログラム記録手段による記録動作により、記録媒体上で、前記余りブロック量を除いた記録可能なブロック残量がゼロとなったら、前記プログラム記録手段による記録動作を終了させる制御手段と、
を備え、
前記制御手段は、前記プログラム記録手段による記録動作の際に、記録媒体上に記録されているプログラムの平均データサイズと、記録媒体の容量に応じて、前記余りブロック量を設定する
記録装置。 - 前記制御手段は、記録媒体において記録可能なブロック残量が所定以下となったら、その記録媒体に記録されているプログラムについての編集処理が不可とされることの警告を出力する請求項１に記載の記録装置。
- 記録媒体上で前記余りブロック量を除いた記録可能なブロック残量がゼロとなったら前記プログラム記録手段による記録動作を終了させる制御を前記制御手段に実行させる動作モードと、記録媒体上で記録可能なブロック残量がゼロとなるまで前記プログラム記録手段による記録動作を続行可能とする制御を前記制御手段に実行させる動作モードとを選択できるようにした請求項１に記載の記録装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP34886899A JP4284797B2 (ja) | 1999-12-08 | 1999-12-08 | 記録装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP34886899A JP4284797B2 (ja) | 1999-12-08 | 1999-12-08 | 記録装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001166972A JP2001166972A (ja) | 2001-06-22 |
| JP4284797B2 true JP4284797B2 (ja) | 2009-06-24 |
Family
ID=18399937
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP34886899A Expired - Fee Related JP4284797B2 (ja) | 1999-12-08 | 1999-12-08 | 記録装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4284797B2 (ja) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4236489B2 (ja) | 2003-03-14 | 2009-03-11 | 三洋電機株式会社 | 画像処理装置 |
| JP6478760B2 (ja) * | 2015-03-27 | 2019-03-06 | キヤノン株式会社 | 記録装置及びその制御方法並びにコンピュータプログラム |
-
1999
- 1999-12-08 JP JP34886899A patent/JP4284797B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2001166972A (ja) | 2001-06-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4207335B2 (ja) | 記録装置、記録再生システム | |
| JP4842417B2 (ja) | 記録装置 | |
| JP4779183B2 (ja) | 再生装置および再生方法 | |
| US7058285B2 (en) | Recording medium editing apparatus based on content supply source | |
| JP4543554B2 (ja) | データ処理装置およびデータ処理方法 | |
| JP4214651B2 (ja) | データコミュニケーションシステム、データ管理方法 | |
| JP4135049B2 (ja) | 不揮発性メモリ | |
| JP4749522B2 (ja) | 再生装置および再生方法 | |
| JP4524921B2 (ja) | 記録装置、記録方法、再生装置および再生方法 | |
| JP4406988B2 (ja) | 不揮発性記録媒体、記録方法、記録装置 | |
| JP4897138B2 (ja) | 再生装置および再生方法 | |
| JP4293196B2 (ja) | 再生装置、編集方法 | |
| JP4284797B2 (ja) | 記録装置 | |
| KR100726905B1 (ko) | 데이터 기억 장치 및 방법 | |
| AU2007202015B2 (en) | Recording medium editing apparatus based on content supply source | |
| JP2001075598A (ja) | 不揮発性記憶媒体および情報収集装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060307 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20081202 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090130 |
|
| 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: 20090303 |
|
| 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: 20090316 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120403 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120403 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120403 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130403 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |