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
【発明の属する技術分野】
本発明は、例えばオーディオデータやビデオデータなどのプログラム(コンテンツ)を記録媒体に記録する記録装置に関するものである。
【0002】
【従来の技術】
EEPROM(Electrically Erasable Programmable ROM)と呼ばれる電気的に書き換え可能な不揮発性メモリは、1ビットを2個のトランジスタで構成するために、1ビット当たりの占有面積が大きく、集積度を高くするのに限界があった。この問題を解決するために、全ビット一括消去方式により1ビットを1トランジスタで実現することが可能なフラッシュメモリが開発された。フラッシュメモリは、磁気ディスク、光ディスク等の記録媒体に代わりうるものとして期待されている。
【0003】
フラッシュメモリを機器に対して着脱自在に構成したメモリカードも知られている。このメモリカードを使用すれば、従来のCD(コンパクトディスク)、MD(ミニディスク)等のディスク状媒体に換えてメモリカードを使用するディジタルオーディオデータ等の記録/再生装置を実現することができる。
【0004】
そして、フラッシュメモリを用いたメモリカードを記録媒体としてオーディオデータやビデオデータ等のプログラム(コンテンツともいう)を記録再生するシステムでは、例えば従来、パーソナルコンピュータで使用されるファイル管理システムである、FAT(File Allocation Table) ファイルシステムを採用することや、ファイル管理情報の工夫により、容易にコンテンツの編集が可能となる。
例えば1つの楽曲としてのオーディオデータが1つのコンテンツとして記録されると仮定すると、そのコンテンツを分割して2つのコンテンツ、すなわち2つの曲にするデバイド編集や、逆に2つのコンテンツを結合させて1つのコンテンツ、すなわち1つの曲にするコンバイン編集なども可能である。
これにより、ユーザーサイドでは、メモリカードに記録したコンテンツを任意に加工して楽しむといったことも可能となる。
【0005】
【発明が解決しようとする課題】
ところで、従来よりオーディオデータとしてのコンテンツを編集可能なシステムとしてミニディスクシステムが知られている。このミニディスクシステムでは、コンテンツを管理する管理情報である、いわゆるTOCデータを書き換えることで、コンテンツの編集を実現してきた。
そしてミニディスク(光磁気ディスク)上では、コンテンツを記録するプログラム領域と、TOCデータを記録する管理情報領域がそれぞれ別に、所定の容量で設定されており、TOCデータの情報量がプログラム(コンテンツ)の記録容量に影響を与えることはなかった。また、編集を何度繰り返したとしても、それは全て管理情報領域内でのTOCデータの書換が行われるのみであるため、これもプログラム(コンテンツ)の記録容量に影響を与えることはない。
【0006】
ところが、フラッシュメモリの場合は、同一位置に書込を繰り返すと、著しくメモリ寿命が縮まるという性質があることから、絶えず書き込み位置を移動させることが好適であるとされている。
このため、メモリカードにおいてコンテンツを記録する領域と、コンテンツを管理する管理情報を記録する領域とを特定せず、例えば管理情報を更新する場合は、新たな領域に新たな管理情報を書き込み、旧管理情報を消去するような記録動作を行っている。
これは、コンテンツの記録動作や編集動作に伴って管理情報の更新が必要とされる場合は、からなず管理情報を新たに書き込めるだけの領域が確保されていることが必要となることを意味する。換言すれば、所定以上の空き容量がなければ、管理情報の更新ができないものとなり、これにより記録動作が完結せず、また編集ができない状態となる。
またブロックといわれる所定単位でデータの管理等を行うメモリカードでは、例えばデバイド編集などの際に新たに1ブロック分が必要となることがある。これも、所定以上の空き容量がなければ、コンテンツの編集ができないということを意味する。
【0007】
つまりフラッシュメモリを用いたメモリカードを記録媒体とする場合は、コンテンツの記録によりメモリカードの残りの記録可能容量が所定未満となってしまうと、記録後に必要な管理情報の更新や、記録されているコンテンツについての編集が実行できなくなるという不都合がある。
【0008】
【課題を解決するための手段】
本発明はこのような問題に鑑みて、プログラム(コンテンツ)の記録に応じた管理情報の更新や、編集処理が適切に実行できるようにすることを目的とする。
【0009】
このために本発明の記録装置は、コンテンツとしてのプログラムを入力する入力手段と、所定数の固定長とされたブロック単位で記録が行われる記録媒体に対して、前記入力手段に入力された前記プログラムを前記ブロック単位にブロック化して記録していくプログラム記録手段と、前記ブロック単位に記録されたプログラムを管理する、プログラム数、各プログラムのデータサイズを記録した管理情報を記録媒体に記録し、又は更新する管理情報記録手段と、前記管理情報記録手段による管理情報の記録又は更新、及び/又は記録されたプログラムの編集に用いられるブロックとして所要量の余りブロック量を設定するとともに、前記プログラム記録手段による記録動作により、記録媒体上で、前記余りブロック量を除いた記録可能なブロック残量がゼロとなったら、前記プログラム記録手段による記録動作を終了させる制御手段と、を備え、前記制御手段は、前記プログラム記録手段による記録動作の際に、記録媒体上に記録されているプログラムの平均データサイズと、記録媒体の容量に応じて、前記余りブロック量を設定するようにする。
つまり、管理情報の記録又は更新や、記録されたプログラムの編集に用いられるブロックとして、余りブロック量を設定しておき、プログラムの記録動作は、余りブロック量として設定された容量を残した状態で終了されるようにする。
【0010】
【発明の実施の形態】
以下、本発明の実施の形態について説明していく。この実施の形態では、記録媒体の例としての不揮発性メモリ(フラッシュメモリ)を搭載するメモリカードを挙げ、記録装置の例として、メモリカードに対して記録再生動作を行うことのできるレコーダを挙げる。
また、実施の形態において扱うことのできるプログラム(コンテンツ)としてのデータは、オーディオデータ、動画データ、静止画データ等のビデオデータ、テキストデータ、プログラムデータ等、各種のものがあるが、説明上は楽曲等のオーディオデータを扱うものとする。なお、主たるコンテンツとしてオーディオデータを扱う場合でも、ディジタルオーディオ信号以外の画像、文字等を付加情報として記録/再生可能となる。
説明は次の順序で行う。
1.レコーダの構成
2.メモリカードの構成
3.ファイルシステム
3−1 処理構造及びデータ構造
3−2 ディレクトリ構成
3−3 管理構造及び編集方式
3−4 再生管理ファイル
3−5 データファイル
4.記録処理
4−1 処理例1
4−2 処理例2
4−3 処理例3
【0011】
1.レコーダの構成
図1により、オーディオデータ等のプログラム(コンテンツ)をメモリカードに対して記録再生することのできるメモリカード記録再生装置(以下、レコーダ1)の構成を説明する。
このレコーダ1は、記録媒体として、着脱自在のメモリカードを使用する。そしてこのレコーダ1は、単体のオーディオ装置として構成してもよいし、パーソナルコンピュータ、或いはオーディオ/ビジュアル機器に内蔵された装置部として構成してもよい。
単体のオーディオ装置とする場合は、例えばレコーダ1は据置型或いは携帯用小型の記録再生装置とされる。その場合、アンプ装置、スピーカ、CDプレーヤ、MDレコーダ、チューナ等と共にオーディオシステムを構成することもできる。
また他の機器に内蔵される形態としては、例えばパーソナルコンピュータにおいてCD−ROMドライブやフロッピーディスクドライブと同様の位置づけで、メモリカードドライブとして採用することができる。
さらにレコーダ1をビデオカメラやゲーム機器に内蔵して、メモリカードをビデオデータやオーディオデータの記録媒体として用いることも可能である。
またレコーダ1は、上記の単体型、内蔵型に関わらず、衛星を使用したデータ通信、ディジタル放送、インターネット等を経由して配信されるディジタルオーディオ信号等を記録するレコーダとしても適用できる。
【0012】
図1はこれら各種の態様で実現できるメモリカード記録再生装置としての一般的な構成を示すものである。
レコーダ1は、それぞれ1チップICで構成されたオーディオエンコーダ/デコーダIC10、セキュリティIC20、DSP(Digital Signal Processor)30を有する。そしてレコーダ1に対して着脱自在のメモリカード40が記録媒体として用いられる。
メモリカード40は、フラッシュメモリ(不揮発性メモリ)、メモリコントロールブロック、DES(Data Encryption Standard)の暗号化回路を含むセキュリティブロックが1チップ上にIC化されたものである。
なお本例では、DSP30を使用しているが、DSPに代えてマイクロコンピュータを使用しても良い。
【0013】
オーディオエンコーダ/デコーダIC10は、オーディオインタフェース11およびエンコーダ/デコーダブロック12を有する。エンコーダ/デコーダブロック12は、ディジタルオーディオ信号をメモリカード40に書き込むために高能率符号化し、また、メモリカード40から読み出されたデータを復号する。高能率符号化方法としては、ミニディスクで採用されているATRAC(Adaptive Transform Acoustic Coding)を改良したもの(ATRAC3と表記する)が使用できる。
【0014】
ATRAC3では、44.1kHzでサンプリングした1サンプル16ビットのオーディオデータを処理する。ATRAC3でオーディオデータを処理する時の最小のデータ単位がサウンドユニットSUである。1SUは、1024サンプル分(1024×16ビット×2チャンネル)を数百バイトに圧縮したものであり、時間にして約23m秒である。ATRAC3により約1/10にオーディオデータが圧縮される。ミニディスクにおいてそうであるように、ATRAC3の工夫された信号処理によって、圧縮/伸長処理による音質の劣化は少ない。
【0015】
ライン入力セレクタ13は、MDの再生出力、チューナの出力、テープ再生出力を選択的にA/D変換器14に供給する。A/D変換器14は、選択されたライン入力信号を(サンプリング周波数=44.1kHz、1サンプル=16ビット)のディジタルオーディオ信号へ変換する。
ディジタル入力セレクタ16は、MD、CD、CS(衛星ディジタル放送)のディジタル出力を選択的にディジタル入力レシーバ17に供給する。ディジタル入力は、例えば光ケーブルを介して伝送される。ディジタル入力レシーバ17の出力がサンプリングレートコンバータ15に供給され、ディジタル入力のサンプリング周波数が44.1kHzに変換される。
【0016】
オーディオエンコーダ/デコーダIC10のエンコーダ/デコーダブロック12でのエンコード処理により得られた符号化データは、セキュリティIC20のインタフェース21を介してDESの暗号化回路22に供給される。
DESの暗号化回路22は、FIFO23を有している。DESの暗号化回路22は、コンテンツの著作権を保護するための備えられている。
なお後述するが、メモリカード40にも、DESの暗号化回路が組み込まれている。
レコーダ1のDESの暗号化回路22は、複数のマスターキーと機器毎にユニークなストレージキーを持つ。さらに、DESの暗号化回路22は、乱数発生回路を持ち、DESの暗号化回路を内蔵するメモリカード40と認証およびセッションキーを共有することができる。よりさらに、DESの暗号化回路22は、DESの暗号化回路を通してストレージキーでキーをかけなおすことができる。
【0017】
DESの暗号化回路22からの暗号化されたオーディオデータがDSP(Digit al Signal Processor) 30に供給される。DSP30は、図示しない着脱機構に装着されたメモリカード40との間で、図2に示すメモリインタフェース38を介しての通信を行い、暗号化されたデータをフラッシュメモリに書き込む。
DSP30とメモリカード40との間では、シリアル通信がなされる。また、メモリカード40の制御に必要なメモリ容量を確保するために、DSP30に対して外付けのSRAM(Static Random Access Memory) 31が接続される。
【0018】
さらにDSP30に対して、端子32が接続され、図示しない外部機器又は外部回路部との間でコンテンツデータや制御データの相互通信を行うことができるようにされている。DSP30は図2に示すインターフェース37を介して、外部機器等との間で通信を行う。
例えばこのレコーダ1が単体で構成される場合は、インターフェース37及び端子32は、例えばUSB、IEEE1394、IEC958、シリアルポート通信、パラレルポート通信など、所定の通信方式に応じたものとされ、パーソナルコンピュータやオーディオ/ビジュアル機器等との間で通信可能とされる。
【0019】
また、このレコーダ1がパーソナルコンピュータやオーディオ/ビジュアル機器などに内蔵される場合は、インターフェース37及び端子32は、例えばそれらの機器のシステムコントローラと接続される内部バス等の構成をとることになる。
【0020】
端子32に接続された機器或いは部位からは、各種のデータがDSP30に供給される。例えばレコーダ1がオーディオシステムやコンピュータシステムの一部とされている場合は、そのオーディオシステムやコンピュータシステムの全体の動作を制御する外部のシステムコントローラからは、ユーザの操作に応じて発生した録音指令、再生指令等のデータをDSP30に与える。
また、画像情報、文字情報等の付加情報のデータも端子32を介してDSP30に供給される。
さらにDSP30は、端子32を介して、メモリカード40から読み出された付加情報データ、制御信号等を外部のシステムコントローラに供給することもできる。
【0021】
なお、図1にはユーザーが各種の操作を行う操作キー等が設けられた操作部39、及びユーザーに対して各種の情報の提示を行う表示部33を示している。これらは特にレコーダ1が単体で構成される場合に必要となるものであり、例えばレコーダ1がパーソナルコンピュータに内蔵される場合などは、DSP30に操作部39及び表示部33が直接接続される必要はない。
つまり単体の場合はDSP30が操作部39からの操作入力の処理や表示部33での表示制御を行うことになるが、内蔵型の場合は、その装置のシステムコントローラがこれらの制御を行い、必要に応じてDSP30に操作情報を供給したり、或いはDSP30から表示すべき内容を示す情報を受け取ったりすればよいためである。
【0022】
DSP30によってメモリカード40から読み出したコンテンツとしての暗号化されたオーディオデータは、セキュリティIC20によって復号化され、オーディオエンコーダ/デコーダIC10によってATRAC3の復号化処理を受ける。
そしてオーディオエンコーダ/デコーダ10の復号化出力がD/A変換器18に供給され、アナログオーディオ信号へ変換される。そして、アナログオーディオ信号がライン出力端子19に取り出される。
【0023】
ライン出力は、図示しないアンプ装置等に伝送され、スピーカまたはヘッドホンにより再生される。
なおD/A変換器18に対してミューティング信号が外部のコントローラから供給される。ミューティング信号がミューティングのオンを示す時には、ライン出力端子19からのオーディオ出力が禁止される。
【0024】
なお、図1ではライン出力端子19のみを示しているが、もちろんデジタル出力端子、ヘッドホン端子等が設けられてもよい。
また外部機器へのコンテンツデータの出力は、上述のように端子32を介して行うこともできる。
【0025】
図2は、DSP30の内部構成を示す。DSP30は、コア34と、フラッシュメモリ35と、SRAM36と、インタフェース37と、メモリカードインタフェース38と、バスおよびバス間のブリッジとで構成される。
このDSP30はマイクロコンピュータと同様に機能し、コア34がCPUに相当する。
フラッシュメモリ35にはDSP30の処理のためのプログラムが格納されている。またSRAM36と外部のSRAM31とが、各種処理のためのワークメモリとして使用される。
【0026】
DSP30は、インタフェース37を介して受け取った録音指令等の操作信号(又は図1に示す操作部39から入力された操作信号)に応答して、所定の暗号化されたオーディオデータ、所定の付加情報データをメモリカード40に対して書き込み、また、これらのデータをメモリカード40から読み出す処理を制御する。
すなわち、オーディオデータ、付加情報の記録/再生を行うためのオーディオシステム全体のアプリケーションソフトウェアと、メモリカード40との間にDSP30が位置し、メモリカード40のアクセス、ファイルシステム等のソフトウェアによってDSP30が動作する。
【0027】
DSP30におけるメモリカード40上のファイル管理は、既存のパーソナルコンピュータで使用されているFATファイルシステムが使用される。このファイルシステムに加えて、本例では、後述するようなデータ構成の再生管理ファイルが使用される。
再生管理ファイルは、メモリカード40上に記録されているデータファイルを管理する。
すなわち第1のファイル管理情報としての再生管理ファイルは、オーディオデータのファイルを管理するものであり、第2のファイル管理情報としてのFATは、オーディオデータのファイルと再生管理ファイルを含むメモリカード0のフラッシュメモリ上のファイル全体を管理する。
再生管理ファイルは、メモリカード40に記録される。また、FATは、ルートディレクトリ等と共に、予め出荷時にフラッシュメモリ上に書き込まれている。
【0028】
なお本例では、著作権を保護するために、ATRAC3により圧縮されたオーディオデータを暗号化している。一方、管理ファイルは、著作権保護が必要ないとして、暗号化を行わないようにしている。また、メモリカード40としても、暗号化機能を持つものと、持たないものとがありうる。本例のように、著作物であるオーディオデータを記録するレコーダ1が使用できるものは、暗号化機能を持つメモリカードのみである。
【0029】
2.メモリカードの構成
図3は、メモリカード40の構成を示す。メモリカード40は、コントロールブロック41とフラッシュメモリ42が1チップICとして構成されたものである。
レコーダ1のDSP30とメモリカード40との間の双方向シリアルインタフェースは、10本の線からなる。主要な4本の線は、データ伝送時にクロックを伝送するためのクロック線SCKと、ステータスを伝送するためのステータス線SBSと、データを伝送するデータ線DIO、インターラプト線INTとである。その他に電源供給用線として、2本のGND線および2本のVCC線が設けられる。2本の線Reservは、未定義の線である。
【0030】
クロック線SCKは、データに同期したクロックを伝送するための線である。ステータス線SBSは、メモリカード40のステータスを表す信号を伝送するための線である。データ線DIOは、コマンドおよび暗号化されたオーディオデータを入出力するための線である。インターラプト線INTは、メモリカード40からレコーダ1のDSP30に対しての割り込みを要求するインターラプト信号を伝送する線である。メモリカード40を装着した時にインターラプト信号が発生する。但し、本例では、インターラプト信号をデータ線DIOを介して伝送するようにしているので、インターラプト線INTを接地している。
【0031】
コントロールブロック41のシリアル/パラレル変換・パラレル/シリアル変換・インタフェースブロック(S/P,P/S,IFブロックと略す)43は、上述した複数の線を介して接続されたレコーダのDSP30とコントロールブロック41とのインタフェースである。S/P,P/S,IFブロック43は、レコーダ1のDSP30から受け取ったシリアルデータをパラレルデータに変換し、コントロールブロック41に取り込み、コントロールブロック41からのパラレルデータをシリアルデータに変換してレコーダ1のDSP30に送る。また、S/P,P/S,IFブロック43は、データ線DIOを介して伝送されるコマンドおよびデータを受け取った時に、フラッシュメモリ42に対する通常のアクセスのためのコマンドおよびデータと、暗号化に必要なコマンドおよびデータとを分離する。
【0032】
つまり、データ線DIOを介して伝送されるフォーマットでは、最初にコマンドが伝送され、その後にデータが伝送される。S/P,P/S,IFブロック43は、コマンドのコードを見て、通常のアクセスに必要なコマンドおよびデータか、暗号化に必要なコマンドおよびデータかを判別する。この判別結果に従って、通常のアクセスに必要なコマンドをコマンドレジスタ44に格納し、データをページバッファ45およびライトレジスタ46に格納する。ライトレジスタ46と関連してエラー訂正符号化回路47が設けられている。ページバッファ45に一時的に蓄えられたデータに対して、エラー訂正符号化回路47がエラー訂正符号の冗長コードを生成する。
【0033】
コマンドレジスタ44、ページバッファ45、ライトレジスタ46およびエラー訂正符号化回路47の出力データがフラッシュメモリインタフェースおよびシーケンサ(メモリI/F,シーケンサと略す)51に供給される。メモリIF,シーケンサ51は、コントロールブロック41とフラッシュメモリ42とのインタフェースであり、両者の間のデータのやり取りを制御する。メモリIF,シーケンサ51を介してデータがフラッシュメモリ42に書き込まれる。
【0034】
フラッシュメモリ42に書き込まれるコンテンツ(ATRAC3により圧縮されたオーディオデータ、以下ATRAC3データと表記する)は、著作権保護のために、レコーダ1のセキュリティIC20とメモリカード40のセキュリティブロック52とによって、暗号化されたものである。セキュリティブロック52は、バッファメモリ53と、DESの暗号化回路54と、不揮発性メモリ55とを有する。
【0035】
メモリカード40のセキュリティブロック52は、複数の認証キーとメモリカード毎にユニークなストレージキーを持つ。不揮発性メモリ55は、暗号化に必要なキーを格納するもので、外部からは見えない。例えばストレージキーが不揮発性メモリ55に格納される。
さらに、乱数発生回路を持ち、専用(ある決められたデータフォーマット等の使用が同じシステム内の意味)レコーダ1と認証ができ、セッションキーを共有できる。よりさらに、DESの暗号化回路54を通してストレージキーでキーのかけ直しができる。
【0036】
例えばメモリカード40をレコーダ1に装着した時に認証がなされる。認証は、レコーダ1のセキュリティIC20とメモリカード40のセキュリティブロック52によってなされる。
レコーダ1は、装着されたメモリカード40が本人(同じシステム内のメモリカード)であることを認め、また、メモリカード40が相手のレコーダが本人(同じシステム内のレコーダ)であることを認めると、互いに相手が本人であることを確認する。認証が行われると、レコーダ1とメモリカード40がそれぞれセッションキーを生成し、セッションキーを共有する。セッションキーは、認証の度に生成される。
【0037】
そして、メモリカード40に対するコンテンツの書き込み時には、レコーダ1がセッションキーでコンテンツキーを暗号化してメモリカード40に渡す。メモリカード40では、コンテンツキーをセッションキーで復号し、ストレージキーで暗号化してレコーダ1に渡す。
ストレージキーは、メモリカード40の一つ一つにユニークなキーであり、レコーダ1は、暗号化されたコンテンツキーを受け取ると、フォーマット処理を行い、暗号化されたコンテンツキーと暗号化されたコンテンツをメモリカード40に書き込む。
【0038】
フラッシュメモリ42からのデータ読出時には、読み出されたデータがメモリIF,シーケンサ51を介してページバッファ45、リードレジスタ48、エラー訂正回路49に供給される。そしてページバッファ45に記憶されたデータがエラー訂正回路49によってエラー訂正がなされる。
エラー訂正されたページバッファ45の出力およびリードレジスタ48の出力はS/P,P/S,IFブロック43に供給され、上述したシリアルインタフェースを介してレコーダ1のDSP30に供給される。
【0039】
このような読出時には、ストレージキーで暗号化されたコンテンツキーとブロックキーで暗号化されたコンテンツとがフラッシュメモリ42から読み出される。そしてセキュリティブロック52によって、ストレージキーでコンテンツキーが復号される。
さらに復号されたコンテンツキーがセッションキーで暗号化されてレコーダ1側に送信される。レコーダ1は、受信したセッションキーでコンテンツキーを復号する。レコーダ1は、復号したコンテンツキーでブロックキーを生成する。このブロックキーによって、暗号化されたATRAC3データを順次復号する。
【0040】
なお、コンフィグレーションROM50には、メモリカード40のバージョン情報、各種の属性情報等が格納されている。
また、メモリカード40には、ユーザが必要に応じて操作可能な誤消去防止用のスイッチ60が備えられている。このスイッチ60が消去禁止の接続状態にある場合には、フラッシュメモリ42を消去することを指示するコマンドがレコーダ側から送られてきても、フラッシュメモリ42の消去が禁止される。
さらに、発振器61は、メモリカード40の処理のタイミング基準となるクロックを発生する。
【0041】
3.ファイルシステム
3−1 処理構造及びデータ構造
図4は、メモリカード40を記憶媒体とするシステムのファイルシステム処理階層を示す。
ファイルシステム処理階層としては、アプリケーション処理層が最上位であり、その下に、ファイル管理処理層、論理アドレス管理層、物理アドレス管理層、フラッシュメモリアクセスが順次おかれる。
この階層構造において、ファイル管理処理層がFATファイルシステムである。物理アドレスは、フラッシュメモリの各ブロックに対して付されたもので、ブロックと物理アドレスの対応関係は、不変である。論理アドレスは、ファイル管理処理層が論理的に扱うアドレスである。
【0042】
図5は、メモリカード40におけるフラッシュメモリ42のデータの物理的構成の一例を示す。
フラッシュメモリ42は、セグメントと称されるデータ単位が所定数のブロック(固定長)へ分割され、1ブロックが所定数のページ(固定長)へ分割される。フラッシュメモリ42では、ブロック単位で消去が一括して行われ、書き込みと読み出しは、ページ単位で一括して行われる。
【0043】
各ブロックおよび各ページは、それぞれ同一のサイズとされ、1ブロックがページ0からページmで構成される。1ブロックは、例えば8KB(Kバイト)バイトまたは16KBの容量とされ、1ページが512Bの容量とされる。フラッシュメモリ42全体では、1ブロック=8KBの場合で、4MB(512ブロック)、8MB(1024ブロック)とされ、1ブロック=16KBの場合で、16MB(1024ブロック)、32MB(2048ブロック)、64MB(4096ブロック)の容量とされる。
【0044】
1ページは、512バイトのデータ部と16バイトの冗長部とからなる。冗長部の先頭の3バイトは、データの更新に応じて書き換えられるオーバーライト部分とされる。3バイトの各バイトに、先頭から順にブロックステータス、ページステータス、更新ステータスが記録される。
冗長部の残りの13バイトの内容は、原則的にデータ部の内容に応じて固定とされる。この13バイトは、管理フラグ(1バイト)、論理アドレス(2バイト)、フォーマットリザーブの領域(5バイト)、分散情報ECC(2バイト)およびデータECC(3バイト)からなる。
分散情報ECCは、管理フラグ、論理アドレス、フォーマットリザーブに対する誤り訂正用の冗長データであり、データECCは、512バイトのデータに対する誤り訂正用の冗長データである。
【0045】
管理フラグとして、システムフラグ(その値が1:ユーザブロック、0:ブートブロック)、変換テーブルフラグ(1:無効、0:テーブルブロック)、コピー禁止指定(1:OK、0:NG)、アクセス許可(1:free、0:リードプロテクト)の各フラグが記録される。
【0046】
セグメントにおける先頭の二つのブロック、すなわちブロック0およびブロック1がブートブロックである。ブロック1は、ブロック0と同一のデータが書かれるバックアップ用である。
ブートブロックは、メモリカード40内の有効なブロックの先頭ブロックであり、メモリカード40を機器に装填した時に最初にアクセスされるブロックである。残りのブロックがユーザブロックである。
ブートブロックの先頭のページ0にヘッダ、システムエントリ、ブート&アトリビュート情報が格納される。ページ1に使用禁止ブロックデータが格納される。ページ2にCIS(Card Information Structure)/IDI(Identify Drive Information)が格納される。
【0047】
ブートブロックのヘッダは、ブートブロックID、ブートブロック内の有効なエントリ数が記録される。システムエントリには、使用禁止ブロックデータの開始位置、そのデータサイズ、データ種別、CIS/IDIのデータ開始位置、そのデータサイズ、データ種別が記録される。
ブート&アトリビュート情報には、メモリカード40のタイプ(読み出し専用、リードおよびライト可能、両タイプのハイブリッド等)、ブロックサイズ、ブロック数、総ブロック数、セキュリティ対応か否か、カードの製造に関連したデータ(製造年月日等)等が記録される。
【0048】
いわゆるフラッシュメモリは、データの書き換えを行うことにより絶縁膜の劣化を生じ、書き換え回数が制限される。従って、ある同一の記憶領域(ブロック)に対して繰り返し集中的にアクセスがなされることを防止する必要がある。従って、ある物理アドレスに格納されているある論理アドレスのデータを書き換える場合、フラッシュメモリのファイルシステムでは、同一のブロックに対して更新したデータを再度書き込むことはせずに、未使用のブロックに対して更新したデータを書き込むようになされる。その結果、データ更新前における論理アドレスと物理アドレスの対応関係が更新後では、変化する。このような処理(スワップ処理と称する)を行うことで、同一のブロックに対して繰り返して集中的にアクセスがされることが防止され、フラッシュメモリの寿命を延ばすことが可能となる。
【0049】
論理アドレスは、一旦ブロックに対して書き込まれたデータに付随するので、更新前のデータと更新後のデータの書き込まれるブロックが移動しても、FATからは、同一のアドレスが見えることになり、以降のアクセスを適正に行うことができる。スワップ処理により論理アドレスと物理アドレスとの対応関係が変化するので、両者の対応を示す論理−物理アドレス変換テーブルが必要となる。このテーブルを参照することによって、FATが指定した論理アドレスに対応する物理アドレスが特定され、特定された物理アドレスが示すブロックに対するアクセスが可能となる。
【0050】
論理−物理アドレス変換テーブルは、DSP30によってSRAM31、36上に格納される。若し、RAM容量が少ない時は、フラッシュメモリ42中に格納することができる。
このテーブルは、概略的には、昇順に並べた論理アドレス(2バイト)に物理アドレス(2バイト)をそれぞれ対応させたテーブルである。フラッシュメモリ42の最大容量を128MB(8192ブロック)としているので、2バイトによって8192のアドレスを表すことができる。また、論理−物理アドレス変換テーブルは、セグメント毎に管理され、そのサイズは、フラッシュメモリ42の容量に応じて大きくなる。例えばフラッシュメモリ42の容量が8MB(2セグメント)の場合では、2個のセグメントのそれぞれに対して2ページが論理−物理アドレス変換テーブル用に使用される。
論理−物理アドレス変換テーブルを、フラッシュメモリ42中に格納する時には、上述した各ページの冗長部における管理フラグの所定の1ビットによって、当該ブロックが論理−物理アドレス変換テーブルが格納されているブロックか否かが指示される。
【0051】
上述したメモリカード40は、ディスク状記録媒体と同様にパーソナルコンピュータのFATファイルシステムによって使用可能なものである。
図5には示されてないが、フラッシュメモリ42上にIPL領域、FAT領域およびルート・ディレクトリ領域が設けられる。
IPL領域には、最初にレコーダ1のメモリにロードすべきプログラムが書かれているアドレス、並びにメモリの各種情報が書かれている。
FAT領域には、ブロック(クラスタ)の関連事項が書かれている。FATには、未使用のブロック、次のブロック番号、不良ブロック、最後のブロックをそれぞれ示す値が規定される。
さらに、ルートディレクトリ領域には、ディレクトリエントリ(ファイル属性、更新年月日、開始クラスタ、ファイルサイズ等)が書かれている。
【0052】
本例では、上述したメモリカード40のフォーマットで規定されるファイル管理システムとは別個に、音楽用ファイルに対して、各トラックおよび各トラックを構成するパーツを管理するための再生管理ファイルを持つようにしている。この再生管理ファイルは、メモリカード40のユーザブロックを利用してフラッシュメモリ42上に記録される。それによって、メモリカード40上のFATが壊れても、ファイルの修復が可能となる。
【0053】
この再生管理ファイルは、DSP30により作成される。例えば最初に電源をオンした時に、メモリカード40が装着されているか否かが判定され、メモリカード40が装着されている時には、認証が行われる。認証により正規のメモリカードであることが確認されると、フラッシュメモリ42のブートブロックがDSP30に読み込まれる。そして、論理−物理アドレス変換テーブルが読み込まれる。読み込まれたデータは、SRAM31、36に格納される。ユーザが購入して初めて使用するメモリカード40でも、出荷時にフラッシュメモリ42には、FATや、ルートディレクトリの書き込みがなされている。再生管理ファイルは、録音がなされると、作成される。
【0054】
すなわち、ユーザの操作等によって発生した録音指令がDSP30に与えられると、受信したオーディオデータがエンコーダ/デコーダIC10によって圧縮され、エンコーダ/デコーダIC10からのATRAC3データがセキュリティIC20により暗号化される。そしてDSP30が暗号化されたATRAC3データをメモリカード40のフラッシュメモリ42に記録するが、この記録後にFATおよび再生管理ファイルが更新される。
ファイルの更新の度、具体的には、オーディオデータの記録を開始し、記録を終了する度に、SRAM31および36上でFATおよび再生管理ファイルが書き換えられる。そして、メモリカード40を外す時に、またはパワーをオフする時に、SRAM31、36からメモリカード40のフラッシュメモリ42上に最終的なFATおよび再生管理ファイルが格納される。この場合、オーディオデータの記録を開始し、記録を終了する度に、フラッシュメモリ42上のFATおよび再生管理ファイルを書き換えても良い。編集を行った場合も、再生管理ファイルの内容が更新される。
【0055】
さらに、本例のデータ構成では、付加情報も再生管理ファイル内に作成、更新され、フラッシュメモリ42上に記録される。なお、再生管理ファイルとは別に付加情報管理ファイルが作成されるようにしてもよい。
付加情報は、外部のコントローラからバスおよびバスインターフェース32を介してDSP30に与えられる。DSP30が受信した付加情報をメモリカード40のフラッシュメモリ42上に記録する。付加情報は、セキュリティIC20を通らないので、暗号化されない。付加情報は、メモリカード40を取り外したり、電源オフの時に、DSP30のSRAMからフラッシュメモリ42に書き込まれる。
【0056】
3−2 ディレクトリ構成
図6は、メモリカード40のディレクトリ構成を示す。図示するようにルートディレクトリから、静止画用ディレクトリ、動画用ディレクトリ、音声用ディレクトリ、制御用ディレクトリ、音楽用(HIFI)ディレクトリが形成される。
本例では、音楽の記録/再生を中心に説明を行うので、以下、音楽用ディレクトリについて説明する。
音楽用ディレクトリには、2種類のファイルが置かれる。その1つは、再生管理ファイルPBLIST.MSF(以下、単にPBLISTと表記する)であり、他のものは、暗号化された音楽データを収納したATRAC3データファイルA3Dnnnn.MSA(以下、単にA3Dnnnと表記する)とからなる。
ATRAC3データファイルは、最大数が400までと規定されている。ATRAC3データファイルは、再生管理ファイルに登録した上で機器により任意に作成される。
【0057】
3−3 管理構造及び編集方式
図7は、再生管理ファイルの構成を示し、図8が一つ(1曲)のATRAC3データファイルの構成を示す。
再生管理ファイルは、16KB固定長のファイルである。
図7に示すように再生管理ファイルは、ヘッダ、1バイトコードのメモリカードの名前NM1−S、2バイトコードのメモリカードの名前NM2−S、曲順の再生テーブルTRKTBL、及びメモリカード全体の付加情報INF−Sとからなる。
【0058】
また図8に示すATRAC3データファイル(以下、単にデータファイルともいう)は、本発明でいうプログラム(又はコンテンツ)に相当するものであり、即ち曲単位のファイルである。そしてデータファイルは、先頭の属性ヘッダと、それに続く実際の暗号化された音楽データとからなる。属性ヘッダは16KB固定長とされ、再生管理ファイルと類似した構成を有する。
データファイルの先頭の属性ヘッダは、ヘッダ、1バイトコードの曲名NM1、2バイトコードの曲名NM2、トラックのキー情報等のトラック情報TRKINF、パーツ情報PRTINFと、トラックの付加情報INFとからなる。ヘッダには、総パーツ数、名前の属性、付加情報のサイズの情報等が含まれる。
【0059】
このデータファイルにおいては、属性ヘッダに対してATRAC3の音楽データが続く。音楽データは、16KBのブロック毎に区切られ、各ブロックの先頭にヘッダが付加されている。ヘッダには、暗号を復号するための初期値が含まれる。
なお、暗号化の処理を受けるのは、ATRAC3データファイル中の音楽データのみであって、それ以外の再生管理ファイル、ヘッダ等のデータは、暗号化されない。
【0060】
図9を参照して、曲(コンテンツ)とATRAC3データファイルの関係について説明する。
1つのコンテンツは、1曲として管理されるデータ群を意味する。1曲は、1つのATRAC3データファイル(図8参照)で構成される。ATRAC3データファイルは、ATRAC3により圧縮されたオーディオデータが記録されている。
【0061】
なお、メモリカード40に対しては、クラスタと呼ばれる単位でデータの記録が行われる。1クラスタは例えば16KBの容量である。この1クラスタには複数のファイルが混じることがない。またフラッシュメモリ42を消去する時の最小単位が1ブロックである。
音楽データを記録するのに使用するメモリカード40の場合、ブロックとクラスタは、同意語であり、且つ1クラスタ=1セクタと定義されている。
【0062】
1曲は、基本的に1パーツで構成されるが、編集が行われると、複数のパーツから1曲が構成されることがある。パーツとは、録音開始からその停止までの連続した時間内で記録されたデータの単位を意味し、通常は、1つのコンテンツは1パーツで構成される。
1つのコンテンツが複数のパーツで構成される場合、曲内のパーツのつながりは、各曲の属性ヘッダ内のパーツ情報PRTINF(後述)で管理する。すなわち、パーツサイズは、PRTINFの中のパーツサイズPRTSIZEという4バイトのデータで表す。パーツサイズPRTSIZEの先頭の2バイトがパーツが持つクラスタの総数を示し、続く各1バイトが先頭および末尾のクラスタ内の開始サウンドユニット(SUと略記する)の位置、終了SUの位置を示す。
このようなパーツの記述方法を持つことによって、音楽データを編集する際に通常、必要とされる大量の音楽データの移動をなくすことが可能となる。
なおブロック単位の編集に限定すれば、同様に音楽データの移動を回避できるが、ブロック単位は、SU単位に比して編集単位が大きすぎる。
【0063】
SUは、パーツの最小単位であり、且つATRAC3でオーディオデータを圧縮する時の最小のデータ単位である。44.1kHzのサンプリング周波数で得られた1024サンプル分(1024×16ビット×2チャンネル)のオーディオデータを約1/10に圧縮した数百バイトのデータがSUである。
1SUは、時間に換算して約23m秒になる。通常は、数千に及ぶSUによって1つのパーツが構成される。
1クラスタが42個のSUで構成される場合、1クラスタで約1秒の音を表すことができる。
1つのコンテンツを構成するパーツの数は、付加情報サイズに影響される。
パーツ数は、1ブロックの中からヘッダや曲名、付加情報データ等を除いた数で決まるために、付加情報が全く無い状態が最大数(645個)のパーツを使用できる条件となる。
【0064】
図9は、CD等からのオーディオデータを2曲連続して記録した場合のファイル構成を示す。
図9(a)に1曲目(データファイル#1)が例えば5つのクラスタ(CL0〜CL4)で構成された場合を、また図9(c)に2曲目(データファイル#2)が例えば6つのクラスタ(CL5〜CL10)で構成された場合を示している。
1曲目と2曲目の曲間では、1クラスタに二つのファイルが混在することが許されないので、次のクラスタ(CL5)の最初からデータファイル#2が作成される。
従って、データファイル#1の終端(1曲目の終端)がクラスタの途中に位置しても、図9(b)に拡大して示すように、そのクラスタの残りの部分には、データ(SU)が存在しないものとされる。
第2曲目(データファイル#2)も同様である。
そしてこの例の場合は、データファイル#1、#2ともに1パーツで構成される。
【0065】
メモリカード40に記録されたデータファイルに対しては、編集として、デバイド、コンバイン、イレーズ、ムーブの4種類の処理が規定される。
デバイドは、1つのトラックを2つに分割することである。デバイドがされると、総トラック数が1つ増加する。デバイドは、一つのファイルをファイルシステム上で分割して2つのファイルとし、再生管理ファイルを更新する。
コンバインは、2つのトラックを1つに結合することである。コンバインされると、総トラック数が1つ減少する。コンバインは、2つのファイルをファイルシステム上で統合して1つのファイルにし、再生管理ファイルを更新する。
イレーズは、トラックを消去することである。消された以降のトラック番号が1つ減少する。
編集処理としてのムーブは、トラック順番を変えることである。この場合も再生管理ファイルを更新する。
なお、ここでいう編集処理としての「ムーブ」は、データの移動を伴うものではなく。例えばHDD等の記録媒体からメモリカード等の記録媒体へのデータの「ムーブ」とは意味が異なる。記録媒体から記録媒体へのムーブとは、データをコピーした上でコピー元の記録媒体からそのデータを消去することで実現するものである。
【0066】
図9に示す二つの曲(データファイル#1、#2)をコンバインした結果を図10に示す。コンバインされたことでデータファイル#1、#2は、1つのデータファイル#1となり、このデータファイル#1は、二つのパーツから形成されるものとなる。
上述したように本例ではパーツに関する記述方法があるので、コンバインした結果(図10)において、パーツ1の開始位置、パーツ1の終了位置、パーツ2の開始位置、パーツ2の終了位置をそれぞれSU単位で規定できる。その結果、コンバインした結果のつなぎ目の隙間をつめるために、パーツ2の音楽データを移動する必要がない。
【0067】
また、図11は、図9(a)の一つの曲(データファイル#1)をクラスタ2の途中でデバイドした結果を示す。
デバイドによって、クラスタCL0、CL1およびクラスタCL2の前側からなるデータファイル#1と、クラスタCL2(CL11)の後側とクラスタCL3、CL4とからなるデータファイル#2とが発生する。
上述したように、1つのクラスタに二つのファイルが混在することは許されないので、このようにクラスタCL2内の或る位置を分割点とするデバイド編集の場合は、まず、クラスタCL2のデータが、あいている別のクラスタCL11にコピーされる。そしてデータファイル#2においては、クラスタCL11における分割点に相当する位置がスタートポイントとされ、そのクラスタCL11に、クラスタCL3、CL4が続くようにされるものとなる。
従って、デバイド編集の場合は、再生管理ファイルの更新だけでなく、1つのクラスタを新たに使用することが必要となる。
【0068】
なお、上述のようにパーツに関する記述方法があるので、デバイドした結果(図11)において、データファイル#2の先頭(クラスタCL11)の空きを詰めるように、データを移動する必要がない。
【0069】
3−4 再生管理ファイル
図12は、再生管理ファイルPBLISTのより詳細なデータ構成を示す。
再生管理ファイルPBLISTは、1クラスタ(1ブロック=16KB)のサイズである。
先頭の32バイトがヘッダとされる。
またヘッダ以外の部分がメモリカード全体に対する名前NM1−S(256バイト)、名前NM2−S(512バイト)、CONTENTS KEY、MAC、S−YMDhmsと、再生順番を管理するテーブルTRKTBL(800バイト)と、メモリカード全体に対する付加情報INF−S(14720バイト)であり、最後にヘッダ中の情報の一部が再度記録される。これらの異なる種類のデータ群のそれぞれの先頭は、再生管理ファイル内で所定の位置となるように規定されている。
【0070】
再生管理ファイルにおいては、(0x0000)および(0x0010)で表される先頭から32バイトがヘッダである。
なお、ファイル中で先頭から16バイト単位で区切られた単位をスロットと称する。
再生管理ファイルの第1および第2のスロットに配されるヘッダには、下記の意味、機能、値を持つデータが先頭から順に配される。
なお、Reservedと表記されているデータは、未定義のデータを表している。通常ヌル(0x00)が書かれるが、何が書かれていてもReservedのデータは無視される。将来のバージョンでは、変更がありうる。また、この部分への書き込みは禁止する。Optionと書かれた部分も使用しない場合は、全てReservedと同じ扱いとされる。
【0071】
BLKID−TL0(4バイト)
意味:BLOCKID FILE ID
機能:再生管理ファイルの先頭であることを識別するための値。
値:固定値=”TL=0”(例えば0x544C2D30)
MCode(2バイト)
意味:MAKER CODE
機能:記録した機器の、メーカー、モデルを識別するコード。
値:上位10ビット(メーカーコード) 下位6ビット(機種コード)
REVISION(4バイト)
意味:再生管理ファイル(PBLIST)の書き換え回数。
機能:再生管理ファイルを書き換える度にインクリメントする。
値:0より始まり+1づつ増加する。
【0072】
SN1C+L(2バイト)
意味:NM1−S領域に書かれるメモリカードの名前(1バイト)の属性を表す。
機能:使用する文字コードと言語コードを各1バイトで表す。
値:文字コード(C)は上位1バイトで下記のように文字を区別する。
00: 文字コードは設定しない。単なる2進数として扱う。
01: ASCII 02:ASCII+KANA 03:modifided8859-1
81:MS-JIS 82:KS C 5601-1989 83:GB2312-80 90:S-JIS(for Voice) 。
言語コード(L)は下位1バイトで下記のようにEBU Tech 3258 規定に準じて言語を区別する。
00: 設定しない 08:German 09:English 0A:Spanish
0F:French 15:Italian 1D:Dutch
65:Korean 69:Japanese 75:Chinese
データが無い場合オールゼロとする。
【0073】
SN2C+L(2バイト)
意味:NM2−S領域に書かれるメモリカードの名前(2バイト)の属性を表す。
機能:使用する文字コードと言語コードを各1バイトで表す。
値:上述したSN1C+Lと同一。
SINFSIZE(2バイト)
意味:INF−S領域に書かれるメモリカード全体に関する付加情報の全てを合計したサイズを表す。
機能:データサイズを16バイト単位の大きさで記述、無い場合は必ずオールゼロとする。
値:サイズは0x0001から0x39C(924)。
【0074】
T−TRK(2バイト)
意味:TOTAL TRACK NUMBER
機能:総トラック数。
値:1から0x0190(最大400トラック)、データが無い場合はオールゼロとする。
VerNo(2バイト)
意味:フォーマットのバージョン番号。
機能:上位がメジャーバージョン番号、下位がマイナーバージョン番号。
値:例 0x0100(Ver1.0)
0x0203(Ver2.3)
【0075】
上述したヘッダに続く領域に書かれるデータは以下のようになる。
【0076】
NM1−S
意味:メモリカード全体に関する1バイトの名前。
機能:1バイトの文字コードで表した可変長の名前データ(最大で256)。
名前データの終了は、必ず終端コード(0x00)を書き込む。
サイズはこの終端コードから計算する。データの無い場合は少なくとも先頭(0x0020)からヌル(0x00)を1バイト以上記録する。
値:各種文字コード
NM2−S
意味:メモリカード全体に関する2バイトの名前。
機能:2バイトの文字コードで表した可変長の名前データ(最大で512)。
名前データの終了は、必ず終端コード(0x00)を書き込む。
サイズはこの終端コードから計算する。データの無い場合は少なくとも先頭(0x0120)からヌル(0x00)を2バイト以上記録する。
値:各種文字コード。
【0077】
CONTENTS KEY
意味:曲ごとに用意された値。
MG(M)で保護されてから保存される。ここでは、1曲目に付けられるCONTENTS KEYと同じ値となる。
機能:S−YMDhmsのMACの計算に必要な鍵となる。
値:0から0xFFFFFFFFFFFFFFFFまで。
MAC
意味:著作権情報改ざんチェック値
機能:S−YMDhmsの内容とCONTENTS KEYから作成される値
値:0から0xFFFFFFFFFFFFFFFFまで。
【0078】
TRK−nnn
意味:再生するATRAC3データファイルのSQN(シーケンス)番号
機能:TRKINFの中のFNoを記述する。
値:1から400(0x190)
トラックが存在しない時はオールゼロとする。
INF−S
意味:メモリカード全体に関する付加情報データ(例えば写真、歌詞、解説等の情報)
機能:ヘッダを伴った可変長の付加情報データ。
複数の異なる付加情報が並べられることがある。それぞれにIDとデータサイズが付けられている。個々のヘッダを含む付加情報データは最小16バイト以上で4バイトの整数倍の単位で構成される。その詳細については、後述する
値:付加情報データ構成を参照
S−YMDhms(4バイト)(Option)
意味:信頼できる時計を持つ機器で記録した年・月・日・時・分・秒
機能:最終記録日時を識別するための値、EMDの時は必須。
値:25〜31ビット 年 0〜99(1980〜2079)
21〜24ビット 月 0〜12
16〜20ビット 日 0〜31
11〜15ビット 時 0〜23
05〜10ビット 分 0〜59
00〜04ビット 秒 0〜29(2秒単位)。
【0079】
再生管理ファイルの最後のスロットとして、ヘッダ内のものと同一のBLKID−TL0と、MCodeと、REVISIONとが書かれる。
【0080】
例えば民生用オーディオ機器としては、メモリカードが記録中に抜かれたり、電源が切れることがあり、復活した時にこれらの異常の発生を検出することが必要とされる。
上述したように、REVISIONはブロックの先頭と末尾に書き込むようにし、この値を書き換える度に+1インクリメントするようにしている。従って若し、ブロックの途中で異常終了が発生すると、先頭と末尾のREVISIONの値が一致せず、異常終了を検出することができる。
このようにREVISIONが2個存在することで、高い確率で異常終了を検出することができる。異常終了の検出時には、エラーメッセージの表示等の警告が発生する。
【0081】
また、1ブロック(16KB)の先頭部分に固定値BLKID−TL0を挿入しているので、FATが壊れた場合の修復の目安に固定値を使用できる。すなわち、各ブロックの先頭の固定値を見れば、ファイルの種類を判別することが可能である。しかも、この固定値BLKID−TL0は、ブロックのヘッダおよびブロックの終端部分に二重に記述するので、その信頼性のチェックを行うことができる。なお、再生管理ファイルPBLISTの同一のものを二重に記録しても良い。
【0082】
なおATRAC3データファイルは、再生管理ファイルと比較して、相当大きなデータ量(例えば数千のブロックが繋がる場合もある)であり、ATRAC3データファイルに関しては、後述するように、ブロック番号BLOCK SERIALが付けられている。但し、ATRAC3データファイルは、通常複数のファイルがメモリカード上に存在するので、CONNUM0でコンテンツの区別を付けた上で、BLOCK SERIALを付けないと、重複が発生し、FATが壊れた場合のファイルの復旧が困難となる。
【0083】
同様に、FATの破壊までにはいたらないが、論理を間違ってファイルとして不都合のあるような場合に、書き込んだメーカーの機種が特定できるように、メーカーコード(MCode)がブロックの先頭と末尾に記録されている。
【0084】
図13は、再生管理ファイルに記録される付加情報データ(INF−S)の構成を示す。
付加情報の先頭に下記のヘッダが書かれる。ヘッダ以降に可変長のデータが書かれる。
【0085】
INF
意味:FIELD ID
機能:付加情報データの先頭を示す固定値。
値:0x69
ID
意味:付加情報キーコード
機能:付加情報の分類を示す。
値:0から0xFF
SIZE
意味:個別の付加情報の大きさ
機能:データサイズは自由であるが、必ず4バイトの整数倍でなければならない。また、最小16バイト以上のこと。データの終わりより余りがでる場合はヌル(0x00)で埋めておく。
値:16から14784(0x39C0)
MCode
意味:MAKER CODE
機能:記録した機器の、メーカー、モデルを識別するコード。
値:上位10ビット(メーカーコード) 下位6ビット(機種コード)
C+L
意味:先頭から12バイト目からのデータ領域に書かれる文字の属性を表す
機能:使用する文字コードと言語コードを各1バイトで表す。
値:前述のSN1C+Lと同じ
DATA
意味:個別の付加情報データ
機能:可変長データで表す。実データの先頭は常に12バイト目より始まり、長さ(サイズ)は最小4バイト以上、常に4バイトの整数倍でなければならない。データの最後から余りがある場合はヌル(0x00)で埋める。
値:内容により個別に定義される。
【0086】
図14は、付加情報キーコードの値(0〜63)と、付加情報の種類の対応の一例を示す。キーコードの値(0〜31)が音楽関係(文字情報)に対して割り当てられ、その(32〜63)がURL(Uniform Resource Locator)(Web関係)に対して割り当てられている。アルバムタイトル、アーティスト名、CM等の文字情報が付加情報として記録される。
【0087】
図15は、付加情報キーコードの値(64〜127)と、付加情報の種類の対応の一例を示す。キーコードの値(64〜95)がパス/その他に対して割り当てられ、その(96〜127)が制御/数値・データ関係に対して割り当てられている。
例えば(ID=98)の場合では、付加情報がTOC−IDとされる。TOC−IDは、CD(コンパクトディスク)のTOC情報に基づいて、最初の曲番号、最後の曲番号、その曲番号、総演奏時間、その曲演奏時間を示すものである。
【0088】
図16は、付加情報キーコードの値(128〜159)と、付加情報の種類の対応の一例を示す。キーコードの値(128〜159)が同期再生関係に対して割り当てられている。図16中のEMD(Electronic Music Distribution)は、電子音楽配信の意味である。
【0089】
図17を参照して付加情報のデータの具体例について説明する。図17(a)は、図13と同様に、付加情報のデータ構成を示す。
図17(b)は、キーコードID=3とされる、付加情報がアーティスト名の例である。SIZE=0x1C(28バイト)とされ、ヘッダを含むこの付加情報のデータ長が28バイトであることが示される。また、C+Lが文字コードC=0x01とされ、言語コードL=0x09とされる。この値は、前述した規定によって、ASCIIの文字コードで、英語の言語であることを示す。そして、先頭から12バイト目から1バイトデータでもって、「SIMON&GRAFUNKEL」のアーティスト名のデータが書かれる。付加情報のサイズは、4バイトの整数倍と決められているので、1バイトの余りが(0x00)とされる。
【0090】
図17(c)は、キーコードID=97とされる、付加情報がISRC(International Standard Recording Code:著作権コード) の例である。SIZE=0x14(20バイト)とされ、この付加情報のデータ長が20バイトであることが示される。また、C+LがC=0x00、L=0x00とされ、文字、言語の設定が無いこと、すなわち、データが2進数であることが示される。そして、データとして8バイトのISRCのコードが書かれる。ISRCは、著作権情報(国、所有者、録音年、シリアル番号)を示すものである。
【0091】
図17(d)は、キーコードID=97とされる、付加情報が録音日時の例である。SIZE=0x10(16バイト)とされ、この付加情報のデータ長が16バイトであることが示される。また、C+LがC=0x00、L=0x00とされ、文字、言語の設定が無いことが示される。そして、データとして4バイト(32ビット)のコードが書かれ、録音日時(年、月、日、時、分、秒)が表される。
【0092】
図17(e)は、キーコードID=107とされる、付加情報が再生ログの例である。SIZE=0x10(16バイト)とされ、この付加情報のデータ長が16バイトであることが示される。また、C+LがC=0x00、L=0x00とされ、文字、言語の設定が無いことが示される。そして、データとして4バイト(32ビット)のコードが書かれ、再生ログ(年、月、日、時、分、秒)が表される。再生ログ機能を持つものは、1回の再生毎に16バイトのデータを記録する。
【0093】
3−5 データファイル
図18は、1SUがNバイト(例えばN=384バイト)の場合のATRAC3データファイル(A3Dnnnn)のデータ配列を示す。
図18には、図8で示したようなデータファイルとして、属性ヘッダとしてのブロックと、実際に音楽データが記録されるブロックとが示されている。
図18には各ブロック(16×2=32Kバイト)の各スロットの先頭のバイト(0x0000〜0x7FF0)が示されている。
【0094】
図18に示すように、属性ヘッダの先頭から32バイトはヘッダとされ、256バイトが曲名領域NM1(256バイト)であり、512バイトが曲名領域NM2(512バイト)である。
属性ヘッダのヘッダには、下記のデータが書かれる。
【0095】
BLKID−HD0(4バイト)
意味:BLOCKID FILE ID
機能:ATRAC3データファイルの先頭であることを識別するための値。
値:固定値=”HD=0”(例えば0x48442D30)
MCode(2バイト)
意味:MAKER CODE
機能:記録した機器の、メーカー、モデルを識別するコード。
値:上位10ビット(メーカーコード) 下位6ビット(機種コード)
BLOCK SERIAL(4バイト)
意味:トラック毎に付けられた連続番号
機能:ブロックの先頭は0から始まり次のブロックは+1づつインクリメント編集されても値を変化させない。
値:0より始まり0xFFFFFFFFまで。
【0096】
N1C+L(2バイト)
意味:トラック(曲名)データ(NM1)の属性
機能:NM1に使用される文字コードと言語コードを各1バイトで表す。
値:SN1C+Lと同一
N2C+L(2バイト)
意味:トラック(曲名)データ(NM2)の属性
機能:NM2に使用される文字コードと言語コードを各1バイトで表す。
値:SN1C+Lと同一
INFSIZE(2バイト)
意味:トラックに関する付加情報の全てを合計したサイズ
機能:データサイズを16バイト単位の大きさで記述。無い場合は必ずオールゼロとする。
値:サイズは0x0000から0x3C6(966)
T−PRT(2バイト)
意味:トータルパーツ数
機能:トラックを構成するパーツ数を表す。通常は1。
値:1から0x285(645dec )
T−SU(4バイト)
意味:トータルSU数
機能:1トラック中の実際の総SU数を表す。曲の演奏時間に相当する。
値:0x01から0x001FFFFF
INX(2バイト)(Option)
意味:INDEX の相対場所
機能:曲のさびの部分(特徴的な部分)の先頭を示すポインタ。曲の先頭からの位置をSUの個数を1/4した数で指定する。これは、通常のSUの4倍の長さの時間(約93m秒)に相当する。
値:0から0xFFFF(最大、約6084秒)
XT(2バイト)(Option)
意味:INDEX の再生時間
機能:INX-nnnで指定された先頭から再生すべき時間のSUの個数を1/4した数で指定する。これは、通常のSUの4倍の長さの時間(約93m秒)に相当する。
値:0x0000:無設定 0x01から0xFFFE(最大6084秒)
0xFFFF:曲の終わりまで。
【0097】
次に属性ヘッダにおける曲名領域NM1およびNM2について説明する。
【0098】
NM1
意味:曲名を表す文字列
機能:1バイトの文字コードで表した可変長の曲名(最大で256)。
名前データの終了は、必ず終端コード(0x00)を書き込む。
サイズはこの終端コードから計算する。データの無い場合は少なくとも先頭(0x0020)からヌル(0x00)を1バイト以上記録する。
値:各種文字コード
NM2
意味:曲名を表す文字列
機能:2バイトの文字コードで表した可変長の名前データ(最大で512)。
名前データの終了は、必ず終端コード(0x00)を書き込む。
サイズはこの終端コードから計算する。データの無い場合は少なくとも先頭(0x0120)からヌル(0x00)を2バイト以上記録する。
値:各種文字コード。
【0099】
属性ヘッダの固定位置(0x0320)から始まる、80バイトのデータをトラック情報領域TRKINFと呼び、主としてセキュリティ関係、コピー制御関係の情報を一括して管理する。TRKINF内のデータについて、配置順序に従って以下に説明する。
【0100】
CONTENTS KEY(8バイト)
意味:曲毎に用意された値で、メモリカードのセキュリティブロックで保護されてから保存される。
機能:曲を再生する時、まず必要となる最初の鍵となる。C−MAC[n]計算時に使用される。
値:0から0xFFFFFFFFFFFFFFFFまで
C−MAC[n](8バイト)
意味:著作権情報改ざんチェック値
機能:コンテンツ累積番号を含む複数のTRKINFの内容と隠しシーケンス番号から作成される値。
隠しシーケンス番号とは、メモリカードの隠し領域に記録されているシーケンス番号のことである。著作権対応でないレコーダは、隠し領域を読むことができない。また、著作権対応の専用のレコーダ、またはメモリカードを読むことを可能とするアプリケーションを搭載したパーソナルコンピュータは、隠し領域をアクセスすることができる。
【0101】
A(1バイト)
意味:パーツの属性
機能:パーツ内の圧縮モード等の情報を示す
値:図19を参照して以下に説明する
ただし、N=0,1のモノラルは、bit7が1でサブ信号を0、メイン信号(L+R)のみの特別なJointモードをモノラルとして規定する。bit2,1の情報は通常の再生機は無視しても構わない。
【0102】
Aのビット0は、エンファシスのオン/オフの情報を形成し、ビット1は、再生SKIPか、通常再生かの情報を形成し、ビット2は、データ区分、例えばオーディオデータか、FAX等の他のデータかの情報を形成する。
ビット3は、未定義である。
ビット4、5、6を組み合わせることによって、図示のように、レート情報が規定される。
すなわち、Nは、この3ビットで表されるレートの値であり、モノ(N=0,1),LP(N=2),SP(N=4),EX(N=5,6),HQ(N=7)の5種類のモードについて、記録時間(64MBのメモリカードの場合)、データ転送レート、1ブロック内のSU数、1SUのバイト数がそれぞれ示されている。
ビット7は、ATRAC3のモード(0:Dual 1:Joint )が示される。
【0103】
一例として、64MBのメモリカードを使用し、SPモードの場合について説明する。64MBのメモリカードには、3968ブロックがある。SPモードでは、1SUが304バイトであるので、1ブロックに53SUが存在する。1SUは、(1024/44100)秒に相当する。従って、1ブロックは、
(1024/44100)×53×(3968−16)=4863秒=81分
転送レートは、
(44100/1024)×304×8=104737 bps
となる。
【0104】
LT(1バイト)
意味:再生制限フラグ(ビット7およびビット6)とセキュリティバージョン(ビット5〜ビット0)
機能:このトラックに関して制限事項があることを表す。
値:ビット7: 0=制限なし 1=制限有り
ビット6: 0=期限内 1=期限切れ
ビット5〜ビット0:セキュリティバージョン0(0以外であれば再生禁止とする)
FNo(2バイト)
意味:ファイル番号
機能:最初に記録された時のトラック番号であり、且つこの値は、メモリカード内の隠し領域に記録されたMAC計算用の値の位置を特定する。
値:1から0x190(400)
MG(D)SERIAL−nnn(16バイト)
意味:記録機器のセキュリティブロック(セキュリティIC20)のシリアル番号。
機能:記録機器ごとに全て異なる固有の値。
値:0から0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
CONNUM(4バイト)
意味:コンテンツ累積番号
機能:曲毎に累積されていく固有の値で記録機器のセキュリティブロックによって管理される。2の32乗、42億曲分用意されており、記録した曲の識別に使用する。
【0105】
値:0から0xFFFFFFFF。
【0106】
YMDhms−S(4バイト)(Option)
意味:再生制限付きのトラックの再生開始日時
機能:EMDで指定する再生開始を許可する日時。
値:上述した日時の表記と同じ。
YMDhms−E(4バイト)(Option)
意味:再生制限付きのトラックの再生終了日時
機能:EMDで指定する再生許可を終了する日時。
値:上述した日時の表記と同じ。
MT(1バイト)(Option)
意味:再生許可回数の最大値
機能:EMDで指定される最大の再生回数。
値:1から0xFF 未使用の時は、0x00である。
LTのbit7の値が0の場合はMTの値は00とする。
CT(1バイト)(Option)
意味:再生回数
機能:再生許可された回数の内で、実際に再生できる回数。再生の度にデクリメントする。
値:0x00〜0xFF 未使用の時は、0x00である。
LTのbit7が1でCTの値が00の場合は再生を禁止する。
【0107】
CC(1バイト)
意味:COPY CONTROL
機能:コピー制御
値:図20に示すように、ビット6および7によってコピー制御情報を表し、ビット4および5によって高速ディジタルコピーに関するコピー制御情報を表し、ビット1,2,3によってコピー属性を表す。ビット0は未定義である。
CCの例:
ビット7・・・0:コピー禁止、1:コピー許可
ビット6・・・0:オリジナル、1:第1世代以上
ビット5,4・・・00:コピー禁止、01:コピー第1世代、10:コピー可
ビット3,2,1
001:オリジナルソースから記録したコンテンツであることを示す。
010:LCMからコピーしたコンテンツであることを示す。
011:LCMからムーブしたコンテンツであることを示す。
100以上:未定義。
なおLCMとは、Licensed Compliant Moduleであり、例えばパーソナルコンピュータやコンシューマ機器におけるHDDなどが相当する。
例えばCDからのディジタル録音では(bit7,6)は01、(bit5,4)は00、(bit3,2,1)は001或いは010となる。
【0108】
CN(1バイト)(Option)
意味:高速ディジタルコピーHSCMS(High speed Serial Copy Management System)におけるコピー許可回数
機能:コピー1回か、コピーフリーかの区別を拡張し、回数で指定する。コピー第1世代の場合にのみ有効であり、コピーごとに減算する。
値:00:コピー禁止、01から0xFE:回数、0xFF:回数無制限。
【0109】
データファイルにおける属性ヘッダにおいては、以上のようなトラック情報領域TRKINFに続いて、0x0370から始まる24バイトのデータをパーツ管理用のパーツ情報領域PRTINFと呼び、1つのトラックを複数のパーツで構成する場合に、時間軸の順番にPRTINFを並べていく。PRTINF内のデータについて、配置順序に従って以下に説明する。
【0110】
PRTSIZE(4バイト)
意味:パーツサイズ
機能:パーツの大きさを表す。クラスタ:2バイト(最上位)、開始SU:1バイト(上位)、終了SU:1バイト(最下位)
値:クラスタ:1から0x1F40(8000)、開始SU:0から0xA0(160)、終了SU:0から0xA0(160)(但し、SUの数え方は、0,1,2,と0から開始する)
PRTKEY(8バイト)
意味:パーツを暗号化するための値
機能:初期値=0、編集時は編集の規則に従う。
値:0から0xFFFFFFFFFFFFFFFF
CONNUM0(4バイト)
意味:最初に作られたコンテンツ累積番号キー
機能:コンテンツをユニークにするためのIDの役割。
値:コンテンツ累積番号初期値キーと同じ値とされる。
【0111】
ATRAC3データファイルの属性ヘッダ中には、図18に示すように、付加情報INFが含まれる。この付加情報は、開始位置が固定化されていない点を除いて、再生管理ファイル中の付加情報INF−S(図12参照)と同一である。1つまたは複数のパーツの最後のバイト部分(4バイト単位)の次を開始位置として付加情報INFのデータが開始する。
【0112】
INF
意味:トラックに関する付加情報データ
機能:ヘッダを伴った可変長の付加情報データ。複数の異なる付加情報が並べられることがある。それぞれにIDとデータサイズが付加されている。個々のヘッダを含む付加情報データは、最小16バイト以上で4バイトの整数倍の単位
値:再生管理ファイル中の付加情報INF−Sと同じである。
【0113】
以上のような属性ヘッダに対して、ATRAC3データが記録される各ブロックのデータが続く。図8にも示したように、ブロック毎にヘッダが付加される。図18に示す、ブロック内のデータについて以下に説明する。
【0114】
BLKID−A3D(4バイト)
意味:BLOCKID FILE ID
機能:ATRAC3データの先頭であることを識別するための値。
値:固定値=”A3D”(例えば0x41334420)
MCode(2バイト)
意味:MAKER CODE
機能:記録した機器の、メーカー、モデルを識別するコード。
値:上位10ビット(メーカーコード) 下位6ビット(機種コード)
CONNUM0(4バイト)
意味:最初に作られたコンテンツ累積番号
機能:コンテンツをユニークにするためのIDの役割、編集されても値は変化させない。
値:コンテンツ累積番号初期値キーと同じ値とされる。
BLOCK SERIAL(4バイト)
意味:トラック毎に付けられた連続番号
機能:ブロックの先頭は0から始まり次のブロックは+1づつインクリメント編集されても値を変化させない。
値:0より始まり0xFFFFFFFFまで。
BLOCK−SEED(8バイト)
意味:1ブロックを暗号化するための1つの鍵
機能:ブロックの先頭は、記録機器のセキュリティブロックで乱数を生成、続くブロックは、+1インクリメントされた値。この値が失われると、1ブロックに相当する約1秒間、音が出せないために、ヘッダとブロック末尾に同じものが二重に書かれる。編集されても値を変化させない。
値:初期は8バイトの乱数。
INITIALIZATION VECTOR(8バイト)
意味:ブロック毎にATRAC3データを暗号化、復号化する時に必要な初期値
機能:ブロックの先頭は0から始まり、次のブロックは最後のSUの最後の暗号化された8バイトの値。デバイドされたブロックの途中からの場合は開始SUの直前の最後の8バイトを用いる。編集されても値を変化させない。
値:0から0xFFFFFFFFFFFFFFFF
SU−nnn
意味:サウンドユニットのデータ
機能:1024サンプルから圧縮されたデータ、圧縮モードにより出力されるバイト数が異なる。編集されても値を変化させない(一例として、SPモードの時では、N=384バイト)。
値:ATRAC3のデータ値。
【0115】
図18では、N=384であるので、1ブロックに42SUが書かれる。また、1ブロックの先頭の2つのスロット(4バイト)がヘッダとされ、最後の1スロット(2バイト)にBLKID−A3D、MCode、CONNUM0、BLOCK SERIALが二重に書かれる。従って、1ブロックの余りの領域Mバイトは、(16,384−384×42−16×3=208(バイト)となる。この中に上述したように、8バイトのBLOCK SEEDが二重に記録される。
【0116】
4.記録処理
4−1 処理例1
以下、本例のレコーダ1によるコンテンツ(曲)の記録動作時の処理例について説明していく。
上述してきた説明から理解されるように、メモリカード40に対するコンテンツの記録は、コンテンツデータの記録だけではなく、1ブロック(1クラスタ)分の容量である再生管理ファイルの生成又は更新があって、完了するものである。またコンテンツのデバイド、コンバイン等の編集は再生管理ファイルの更新によって実現される。
また、メモリカード40上での再生管理ファイルの記録位置(絶対アドレス)は、再生管理ファイルの更新のための書込のたびに異なる位置とされていく。
さらに、デバイド編集が行われる場合は、1クラスタ(1ブロック)を新たに使用することが必要となる。
【0117】
このような事情から、もしコンテンツの記録をメモリカードの全ての容量に対して行ってしまうと、その記録動作にかかる再生管理ファイルの作成又は更新ができなくなる。或いは、コンテンツと再生管理ファイルを含めてメモリカードの全ての容量を使い切ってしまうと、その後、デバイド等の編集ができないものとなってしまう。
そこで本例では、記録動作時には、或る程度の容量が残されるようにして記録が終了するようにするものである。
ただ、このような処理により、コンテンツを記録できる容量が、残される容量の分だけ減ることになるため、残される容量は適切な量としなければならない。
【0118】
一般に平均的な演奏時間の音楽を記録する場合、1つの記録媒体(メモリカード)の曲数(コンテンツ数)は20曲程度までとなる。
また、FM放送等を1時間分録音した場合は、その1時間分のデータは1つのコンテンツとして扱われる。ユーザーは、録音した放送からデバイドによって、各曲を分割する操作を行う。
これらの事情から、20回程度のデバイドが行われる可能性が高いとして、例えば20クラスタ(20ブロック)分程度を、上記の残される容量とする方式が考えられる。
また、既に10曲(30分)のコンテンツが記録されているような状態では、統計的にはあと10クラスタ(10ブロック)分程度を、上記の残される容量とすれば、その後のデバイド編集などに、ほぼ対応できると推定できる。そこで、記録開始時に、既に記録されているコンテンツ数に応じて、残される容量を設定する方式も考えられる。
或いは、既に記録されているコンテンツの平均的なサイズと全容量の関係から残される容量を設定するようにしてもよい。
大まかにいえば、メモリカードにおいてコンテンツ数が少なくその各コンテンツのサイズが大きい場合は、その後に何回か編集される可能性が高くなるため、その傾向に応じて、残される容量を設定すると好適である。
【0119】
いづれにしても本例では、記録後における編集回数の可能性に応じて、残される容量が設定されるようにする。
【0120】
レコーダ1のDSP30が、ライン入力セレクタ13又はデジタル入力セレクタ16から入力され、オーディオエンコーダ/デコーダ10でエンコード処理、セキュリティIC20で暗号化処理が施されたデータを、メモリカード40に記録していく際の処理を図21に示す。
【0121】
記録が開始される際には、DSP30は、まずステップF101で、装填されているメモリカード40の管理情報(再生管理ファイル)から、メモリカード40に既にコンテンツ(データファイル)が記録されているか否かを判別する。
まだ1つもデータファイルが記録されていないメモリカード40であった場合は、処理をステップF102に進め、変数Lに「20」をセットする。
これは上述のように、通常、20曲程度の収録状態が考えられ、換言すれば20回程度のデバイドが行われる可能性が考えられるためである。もちろん「20」という値は一例にすぎず、メモリカードの容量等に応じて適切な値が設定されるべきである。また、この「20」に相当する値を、ユーザーが自分の事情や記録内容、例えば編集を何回も行うか否かに合わせて、任意に増減できるようにしてもよい。
【0122】
そしてステップF108で、Lクラスタ、即ちこの場合は20クラスタ(20ブロック)分を、余りブロックとして確保する。
ここでいう余りブロックとは、上述した残される容量のことであり、つまり記録終了時点で残されるべき容量としてのブロック数である。
【0123】
メモリカード40にすでに1つ以上のデータファイルが記録されていた場合は、DSP30の処理はステップF103に進み、記録されているデータファイルの平均ファイルサイズMを算出する。
これは、既にデータファイルの記録に使用されている容量を、データファイル数で割れば算出できる。
平均ファイルサイズMが算出できたら、ステップF104で、メモリカード40の全容量を平均ファイルサイズMで割って、予測総ファイル数Nを算出する。
予測総ファイル数Nとは、メモリカード40の全容量を使用した場合に、いくつのデータファイルが記録されているかの予測値である。
【0124】
そしてDSP30はステップF105で予測総ファイル数Nが「20」以下であるか否かを判別する。ここでの「20」も、一般的な平均としての収録曲数として用いており、「20」に限定されるものではない。
【0125】
予測総ファイル数Nが「20」以下である場合は、20曲は記録される可能性があると判断して、ステップF106で、「20」から既に記録されているデータファイル数を減算した値を、変数Lにセットする。
そしてステップF108で、Lクラスタ(Lブロック)分を、余りブロックとして確保する。
【0126】
一方、ステップF105で、予測総ファイル数Nが「20」を越えているとされた場合は、予測総ファイル数Nの数だけデータファイルが記録される可能性があると判断して、ステップF107で、予測総ファイル数Nから既に記録されているデータファイル数を減算した値を、変数Lにセットする。
そしてステップF108で、Lクラスタ(Lブロック)分を、余りブロックとして確保する。
【0127】
ステップF108として余りブロックが設定されたら、ステップF109からオーディオデータによるデータファイルの記録を開始する。
データファイルは上述したようにブロック単位で記録されていくことになる。
【0128】
記録動作中は、ステップF110で、余りブロックを除いてメモリカード40における記録可能な残り容量がゼロになったか否かを監視している。
またステップF111では、記録終了、即ちユーザの指示した1又は複数のデータファイルの記録が完了したか、或いはユーザーが操作部39から記録停止操作を行ったことなどにより記録が終了されるものとなったか、を監視する。
さらにステップF112では、供給されているオーディオデータとして、ファイルチェンジ、即ち曲が変わって、別のデータファイルの記録に移行することになったかを監視する。
このファイルチェンジ、即ち曲の変化は、例えばMD、CD等の記録媒体から曲がデジタルオーディオデータとして供給されている場合において、そのデジタルデータ内に含まれているトラックナンバ情報を監視することなどで可能となる。また、ライン入力セレクタ13からのアナログオーディオ信号について記録している場合でも、例えば無音期間の検出などにより、ファイルチェンジと判断するようにしてもよい。
【0129】
ステップF110で肯定結果がでるより前に、ステップF111で記録終了となった場合は、DSP30はステップF118で、記録したコンテンツについての再生管理ファイルの作成(又は更新)を行って、記録処理を終える。
この場合は、メモリカード40における記録可能な容量は、その後の記録や編集のためには、まだ十分に残されている状態である。
【0130】
記録動作中においてステップF112で、記録するオーディオデータについてのファイルチェンジが検出された場合は、そのファイルチェンジポイントまでのオーディオデータが記録されたブロックで、1つのデータファイルが形成されることになる。
そこでステップF113で変数Lをデクリメントし、その時点で変数Lが「1」よりも大きければ、ステップF108に戻って、Lクラスタ分を余りブロックとして確保する。つまり余りブロックとしての設定を1ブロック少なくする。
これは、1つのデータファイルが記録されたことで、その後のデバイド回数の可能性が1回減ったと考えることができるためである。
そして、ステップF109から新たなデータファイルとして、続くオーディオデータを新たなブロックの先頭とした上で、その後の記録を行っていく。
【0131】
なお、記録中に19回トラックチェンジが検出されると、ステップF114の時点で変数L=0となる。
そしてこれは、続くオーディオデータが、20曲目として記録されていく場合である。この場合、録音後においてデバイド編集が行われる可能性がきわめて低いものとなるため、それだけを考えれば、変数L=0となることに応じて、余りブロックをゼロとしてしまってもよいが、実際には録音後に再生管理ファイルの書込が必要となるため、少なくとも録音終了時点で1ブロックは残されていなければならない。
そこで、ステップF114で変数Lが1未満(つまり0)となった場合は、ステップF116で、変数L=1として、ステップF108で少なくとも1ブロックは余りブロックとして確保されるようにする。
また、この場合、余りブロックが記録終了後の再生管理ファイルの書込に用いられ、それによってメモリカード40の全容量が消費されると、その後の編集はできないものとなる。
そこで、ステップF115では、ユーザーに対して記録終了後の編集ができなくなるおそれがあることを提示する。例えば表示部33にその旨のメッセージを表示する。但し、その後、ステップF110で肯定結果が出る前に、ステップF111で記録終了と判断された場合、即ち余りブロック以外にも記録可能なブロックが残されている場合は、まだ記録又は編集が可能であるため、この時点では必ずしも警告表示を行わなくてもよい。
【0132】
ステップF110において、その時点で余りエリアとして設定されているブロック数を残して、他に記録可能なブロックが使い切られてしまったと判断された場合は、DSP30はステップF117に進み、強制的に記録動作を停止する。
そしてステップF118で記録したコンテンツについての再生管理ファイルの作成(又は更新)を行って、記録処理を終える。
この場合は、メモリカード40における記録可能な容量は、余りエリアとして設定されていたブロック数のみが残されている状態である。
そしてその余りブロックとしてのブロック数は、上述したように、通常20曲が収録されること、平均データサイズと全容量の関係から収録曲数が推定されること、及びそれらの収録曲数から、既に収録済みの曲数が減算されることなどに応じて設定される。さらに記録中に曲が分かれれば(ファイルチェンジ)、余りブロック数はデクリメントされていく。
これらのことから、記録終了時点で、その後に少なくとも一般的に予測されるだけの編集回数は、編集可能とするに足りるブロック数となる。
従って、コンテンツ記録時に、ユーザーがメモリカード40の記録可能エリアを使い切ってしまったと感じる場合でも、少なくとも通常必要となる回数の編集は、可能とされることになり、ユーザーに不都合を感じさせるものではなくなる。
また一方で、上記のように余りブロック数が変数Lに応じて設定され、また記録中にデクリメントされることで、余りブロック数は、通常必要とされる編集回数を、コンテンツ記録状況に応じて、最低限の回数として設定されるものとなる。これは、余りブロック数を多く設定しすぎて、それによりコンテンツの記録可能容量を必要以上に小さくしてしまうものではないことを意味する。
つまり、本例の記録処理により、なるべくコンテンツの記録容量は減少させないようにした上で、その後に必要とされる編集は実行可能な状態とすることができる。
【0133】
なお、上述のように余りブロックが1ブロックまで減ぜられた状態で、ステップF110,F117で記録が終了されると、その余りブロックとされた1ブロックは、再生管理ファイルの記録に用いられるものとなり、その時点で全てのブロックが使用済みとなる。つまり以降は、編集ができない。(本例の考え方によれば、この場合は、20或いはそれ以上の曲数に既に分割されているため、デバイド編集の必要がない状態となっている)。
そこで、ステップF115として説明した警告処理は、このような場合に実行するようにしてもよい。
またその時点で、編集操作を無効とする編集禁止処理を行ってもよい。
なお、この場合において、再生管理ファイルが新規に或るブロックに記録されるのではなく、いままでの再生管理ファイルが「更新」される場合は、旧再生管理ファイルが記録されていたブロックは、書込可能なブロックとなる。
従って、コンバイン、ムーブ、イレーズなど、再生管理ファイルの更新のみで実現される編集は可能である。
そこで、そのような場合は、上記警告や編集禁止処理は、デバイド編集に限ったものとして行ってもよい。
【0134】
ところで、以上の処理の説明では、記録終了時点のステップF118での再生管理ファイルの書込に用いるブロックも、少なくとも余りブロックとして確保されるものとして説明したが、ステップF118での再生管理ファイルの書込に用いるブロックは、「余りブロック」とは別に確保されているとして、図21の処理を考えてもよい。
その場合、上記のように余りブロックが1ブロックまで減ぜられた状態で、ステップF110,F117で記録が終了され、再生管理ファイルの記録が行われても、余りブロックとされた1ブロックは残されている。従って、コンバイン、ムーブ、イレーズなど、再生管理ファイルの更新のみで実現される編集は可能である。またさらに再生管理ファイルが更新された場合は、旧再生管理ファイルの記録されていたブロックも書込可能となるため、2ブロックが書き込み可能であり、デバイドも可能である。
従って、上記警告表示や編集禁止処理は、これらの事情に応じて行うことが好ましい。
【0135】
また、図21の処理例では、ファイルチェンジに応じて余りブロック数が単純に減ぜられていくようにしたが、ファイルチェンジのタイミングまでのオーディオデータで形成されたデータファイルを含めて、ステップF103〜F107のような平均ファイルサイズと全容量に応じた余りブロック設定が行われるようにして、余りブロックの設定が変化されていくようにしてもよい。
【0136】
4−2 処理例2
続いて図22で、処理例2としての記録処理を説明する。
なお図22において、上記図21と同一の処理については、ステップF101〜F118として同一ステップ番号を付し、説明を省略する。
即ちこの処理例2は、上記図21の処理に、ステップF100及びF119〜121が追加されたものである。
【0137】
この場合は、ユーザーが、記録後における編集を可能とするために余りブロックを設定するか、或いは、そのようなことを考慮せずに、できるだけコンテンツの記録可能容量を多くするかを選択できるようにしたものである。
つまりユーザーは、例えば操作部39からの操作により、余りブロック量を除いた記録可能なブロック残量がゼロとなったら記録動作を終了させる動作モードと、メモリカード40上で記録可能なブロック残量がゼロとなるまで記録動作を続行可能とする動作モード(使い切り設定)とを選択できるようにしている。
【0138】
ユーザーが、使い切り設定を行わずに記録を開始させた場合は、DSP30の記録処理は図21と同様の処理となる(F101〜F118)。
ところがユーザーが使い切り設定を行って記録動作を開始させた場合は、DSP30はステップF119,F120,F121の処理を行う。
即ちステップF119からオーディオデータによるデータファイルの記録を開始する。データファイルはブロック単位で記録されていくことになる。
【0139】
そして記録動作中は、ステップF120で、メモリカード40における記録可能な残り容量が残り1ブロックになったか否かを監視している。
またステップF121では、記録終了、即ちユーザの指示した1又は複数のデータファイルの記録が完了したか、或いはユーザーが操作部39から記録停止操作を行ったことなどにより記録が終了されるものとなったか、を監視する。
なお、記録中に供給されているオーディオデータとして、ファイルチェンジが検出された場合は、そのファイルチェンジポイントまでのオーディオデータが記録されたブロックで、1つのデータファイルが形成される。そして新たなデータファイルとして、続くオーディオデータを新たなブロックの先頭とした上で、その後の記録を行っていく。
【0140】
ステップF120で肯定結果がでるより前に、ステップF121で記録終了となった場合は、DSP30はステップF118で、記録したコンテンツについての再生管理ファイルの作成(又は更新)を行って、記録処理を終える。
この場合は、メモリカード40における記録可能な容量は、その後の記録や編集のためには、まだ十分に残されている状態である。
【0141】
ステップF120において、その時点で1ブロック数を残して、記録可能なブロックが使い切られてしまったと判断された場合は、DSP30はステップF117に進み、強制的に記録動作を停止する。
そしてステップF118で、残りの1ブロックに対して、記録したコンテンツについての再生管理ファイルの作成(又は更新)を行って、記録処理を終える。
この場合は、メモリカード40における記録可能な容量が最大限、コンテンツの記録に用いられたことになる。
つまりこの処理例2では、ユーザーの選択によって、もし記録後の編集を考えない場合であるなら、メモリカード40の容量をコンテンツの記録に最大限利用できるようにするものである。
【0142】
4−3 処理例3
図23に処理例3を示す。
この処理例は、余りブロックの設定を固定化したもので、また記録終了時点では、少なくとも固定値の余りブロックとしてのブロック数は、記録可能として確保されるようにした例である。
【0143】
即ち記録が開始される際には、DSP30はステップF201で、或る設定された固定値としてxクラスタ分を余りブロックとして設定する。
そしてステップF202からオーディオデータによるデータファイルの記録を開始する。データファイルはブロック単位で記録されていく。
【0144】
そして記録動作中は、ステップF203で、メモリカード40における記録可能な残り容量が、x個の余りブロックを除いてゼロとなったか否かを監視し、またステップF204では、記録終了、即ちユーザの指示した1又は複数のデータファイルの記録が完了したか、或いはユーザーが操作部39から記録停止操作を行ったことなどにより記録が終了されるものとなったか、を監視する。
なお、記録中に供給されているオーディオデータとして、ファイルチェンジが検出された場合は、そのファイルチェンジポイントまでのオーディオデータが記録されたブロックで、1つのデータファイルが形成される。そして新たなデータファイルとして、続くオーディオデータを新たなブロックの先頭とした上で、その後の記録を行っていく。
【0145】
ステップF203で肯定結果がでるより前に、ステップF204で記録終了となった場合は、DSP30はステップF206で、記録したコンテンツについての再生管理ファイルの作成(又は更新)を行って、記録処理を終える。
この場合は、メモリカード40における記録可能な容量は、その後の記録や編集のためには、まだ十分に残されている状態である。
【0146】
ステップF203において、その時点でxブロック数を残して、記録可能なブロックが使い切られてしまったと判断された場合は、DSP30はステップF205に進み、強制的に記録動作を停止する。
そしてステップF206で、xブロックのうちの1ブロックを用いて、記録したコンテンツについての再生管理ファイルの作成(又は更新)を行って、記録処理を終える。
この場合は、メモリカード40における記録可能な容量として余りブロックとして設定された(x−1)ブロック分だけ残された状態となる。
【0147】
つまりこの処理例3では、記録終了時点で、少なくとも(x−1)ブロック分の容量が残され、その分だけその後の編集が可能となる。
固定的に設定されるxの値としては、例えば統計的に妥当と考えられる値としてもよいし、例えばユーザーが任意に設定できるようにして、ユーザーの事情や記録内容に合致した処理が行われるようにすることもできる。
【0148】
以上、本発明の実施の形態としての例を説明してきたが、実施の形態の例はあくまでも一例であり、レコーダの構成、処理方式などは、多様に考えられる。
特に余りブロック数の設定方式は、各種の多様な変形例が考えられる。
また上記例ではオーディオデータとしてのコンテンツ(プログラム)を想定して説明したが、ビデオデータとしてのコンテンツについても、全く同様に本発明を適用できる。テキストデータその他のコンテンツについても同様である。
【0149】
【発明の効果】
以上の説明から分かるように本発明では、記録動作に際して所要量の余りブロック量を設定するとともに、プログラム記録動作により、記録媒体上で、余りブロック量を除いた記録可能なブロック残量がゼロとなったら、プログラム記録動作を終了させるようにしているため、プログラム(コンテンツ)の記録終了後において、少なくとも上記余りブロック量に相当する記録可能容量が残されるものとなる。
そして管理情報の記録又は更新、及び/又は記録されたプログラムの編集に用いられるブロックとして、余りブロック量が設定されていることで、プログラムの記録を完結させるための管理情報の書込/更新、或いはその後のプログラムの編集のために用いる領域が確保されていることになり、つまり記録や編集が適切に実行できる状態を確保できるという効果がある。
また、余りブロック量は、プログラム記録手段による記録動作の際に、記録媒体上に記録されているプログラム数に応じて設定すること、或いは記録媒体上に記録されているプログラムの平均データサイズと記録媒体の容量に応じて設定することで、その記録媒体のプログラム記録状況に合致した適切な量とすることができ、余りブロック量が多すぎてむやみにプログラム記録領域が削減されたり、或いは逆に、その後の編集等のために十分なブロック量が確保できないということを避けられる。
【0150】
また記録媒体において記録可能なブロック残量が所定以下となったら、その記録媒体に記録されているプログラムについての編集処理が不可とされることの警告を出力することで、ユーザーに状況を告知できる。
【0151】
また記録媒体上で前記余りブロック量を除いた記録可能なブロック残量がゼロとなったらプログラム記録動作を終了させる動作モードと、記録媒体上で記録可能なブロック残量がゼロとなるまでプログラム記録動作を続行可能とする動作モードとを選択できるようにすることで、ユーザーの事情に応じて、記録媒体の記録容量を有効に利用できるようにすることができる。
【図面の簡単な説明】
【図1】本発明の実施の形態のレコーダのブロック図である。
【図2】実施の形態のレコーダのDSPのブロック図である。
【図3】実施の形態のメモリカードの構成を示すブロック図である。
【図4】実施の形態におけるメモリカードのファイルシステム処理階層の構成の説明図である。
【図5】実施の形態のメモリカードのデータの物理的構成のフォーマットの説明図である。
【図6】実施の形態のメモリカードのディレクトリ構造の説明図である。
【図7】実施の形態のメモリカードの再生管理ファイルのデータ構成の説明図である。
【図8】実施の形態のメモリカードのデータファイルのデータ構成の説明図である。
【図9】実施の形態のデータファイルの構成の説明図である。
【図10】実施の形態のデータファイルのコンバイン編集処理の説明図である。
【図11】実施の形態のデータファイルのデバイド編集処理の説明図である。
【図12】実施の形態の再生管理ファイルの構成の説明図である。
【図13】実施の形態の再生管理ファイルの付加情報領域の構成の説明図である。
【図14】実施の形態の付加情報キーコードの説明図である。
【図15】実施の形態の付加情報キーコードの説明図である。
【図16】実施の形態の付加情報キーコードの説明図である。
【図17】実施の形態における付加情報の具体的なデータ構成の説明図である。
【図18】実施の形態のデータファイルの構成の説明図である。
【図19】実施の形態のデータファイルの属性ヘッダの「A」の説明図である。
【図20】実施の形態のデータファイルの属性ヘッダの「CC」の説明図である。
【図21】実施の形態の記録処理のフローチャートである。
【図22】実施の形態の記録処理のフローチャートである。
【図23】実施の形態の記録処理のフローチャートである。
【符号の説明】
1,1A,1B レコーダ、10 オーディオエンコーダ/デコーダIC、20 セキュリティIC、30 DSP、40 メモリカード、42 フラッシュメモリ、52 セキュリティブロック
Claims (3)
- コンテンツとしてのプログラムを入力する入力手段と、
所定数の固定長とされたブロック単位で記録が行われる記録媒体に対して、前記入力手段に入力された前記プログラムを前記ブロック単位にブロック化して記録していくプログラム記録手段と、
前記ブロック単位に記録されたプログラムを管理する、プログラム数、各プログラムのデータサイズを記録した管理情報を記録媒体に記録し、又は更新する管理情報記録手段と、
前記管理情報記録手段による管理情報の記録又は更新、及び/又は記録されたプログラムの編集に用いられるブロックとして所要量の余りブロック量を設定するとともに、前記プログラム記録手段による記録動作により、記録媒体上で、前記余りブロック量を除いた記録可能なブロック残量がゼロとなったら、前記プログラム記録手段による記録動作を終了させる制御手段と、
を備え、
前記制御手段は、前記プログラム記録手段による記録動作の際に、記録媒体上に記録されているプログラムの平均データサイズと、記録媒体の容量に応じて、前記余りブロック量を設定する
記録装置。 - 前記制御手段は、記録媒体において記録可能なブロック残量が所定以下となったら、その記録媒体に記録されているプログラムについての編集処理が不可とされることの警告を出力する請求項1に記載の記録装置。
- 記録媒体上で前記余りブロック量を除いた記録可能なブロック残量がゼロとなったら前記プログラム記録手段による記録動作を終了させる制御を前記制御手段に実行させる動作モードと、記録媒体上で記録可能なブロック残量がゼロとなるまで前記プログラム記録手段による記録動作を続行可能とする制御を前記制御手段に実行させる動作モードとを選択できるようにした請求項1に記載の記録装置。
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 |