JP4281185B2 - 編集装置および方法 - Google Patents
編集装置および方法 Download PDFInfo
- Publication number
- JP4281185B2 JP4281185B2 JP34910899A JP34910899A JP4281185B2 JP 4281185 B2 JP4281185 B2 JP 4281185B2 JP 34910899 A JP34910899 A JP 34910899A JP 34910899 A JP34910899 A JP 34910899A JP 4281185 B2 JP4281185 B2 JP 4281185B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- file
- recorded
- attribute
- data file
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Classifications
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
- G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
- G11B27/02—Editing, e.g. varying the order of information signals recorded on, or reproduced from, record carriers
- G11B27/031—Electronic editing of digitised analogue information signals, e.g. audio or video signals
- G11B27/034—Electronic editing of digitised analogue information signals, e.g. audio or video signals on discs
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11C—STATIC STORES
- G11C7/00—Arrangements for writing information into, or reading information out from, a digital store
- G11C7/16—Storage of analogue signals in digital stores using an arrangement comprising analogue/digital [A/D] converters, digital memories and digital/analogue [D/A] converters
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
- G11B2220/00—Record carriers by type
- G11B2220/60—Solid state media
- G11B2220/61—Solid state media wherein solid state memory is used for storing A/V content
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99941—Database schema or data structure
- Y10S707/99942—Manipulating data structure, e.g. compression, compaction, compilation
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99941—Database schema or data structure
- Y10S707/99943—Generating database or data structure, e.g. via user interface
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
- Y10S707/99953—Recoverability
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99956—File allocation
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Management Or Editing Of Information On Record Carriers (AREA)
- Compression Or Coding Systems Of Tv Signals (AREA)
- Read Only Memory (AREA)
- Processing Or Creating Images (AREA)
- Signal Processing For Digital Recording And Reproducing (AREA)
- Storage Device Security (AREA)
Description
【発明の属する技術分野】
この発明は、FAT(File Allocation Table )を用いてメモリカード上に記録されたファイルの分割もしくは結合処理等の編集を行う編集装置及び方法に関する。
【0002】
【従来の技術】
EEPROM(Electrically Erasable Programmable ROM)と呼ばれる電気的に書き換え可能な不揮発性メモリは、1ビットを2個のトランジスタで構成するために、1ビット当たりの占有面積が大きく、集積度を高くするのに限界があった。この問題を解決するために、全ビット一括消去方式により1ビットを1トランジスタで実現することが可能なフラッシュメモリが開発された。フラッシュメモリは、磁気ディスク、光ディスク等の記録媒体に代わりうるものとして期待されている。
【0003】
フラッシュメモリを機器に対して着脱自在に構成したメモリカードも知られている。このメモリカードを使用すれば、従来のCD(コンパクトディスク:登録商標)、MD(ミニディスク:登録商標)等のディスク状媒体に換えてメモリカードを使用するディジタルオーディオ記録/再生装置を実現することができる。
【0004】
従来、パーソナルコンピュータで使用されるファイル管理システムは、FAT(File Allocation Table) システムと呼ばれる。このFATシステムでは、必要なファイルが定義されると、その中に必要なパラメータがファイルの先頭から順番にセットされていた。その結果、ファイルのサイズが可変長で、1ファイルが1または複数の管理単位(セクタ、クラスタ等)で構成される。この管理単位の関連事項がFATと呼ばれるテーブルに書かれる。このFATシステムは、記録媒体の物理的特性と無関係に、ファイル構造を容易に構築することができる。従って、FATシステムは、フロッピーディスク、ハードディスクのみならず、光磁気ディスク、でも採用することができる。上述したメモリカードにおいても、FATシステムが採用されている。
【0005】
しかしながら、オーディオデータが記録されているCD等では、FATシステムの概念は全くなく、記録/再生が可能なMDの時代になって初めてLink−P(以下、リンクPと称する)と呼ばれるFATを変形したような方法で音楽の記録や編集が実現された。このためシステム自体は、簡素化され小さなCPUでも制御が可能なものとなっていたが、パーソナルコンピュータとのデータのやり取りは全くできず、独立したAV機器として発展してきた。
【0006】
このMDで採用されているリンクPなるシステムは、MD上に生じた欠陥の位置に係る情報を格納するスロットの先頭位置を示すP−DFA(Pointer for Defective Area)、スロットの使用状況を示すP−Empty(Pointer for Empty slot)、記録可能領域を管理するスロットの先頭位置を示すP−FRA(Pointer for FReely Area )および各プログラム番号に対応したスロットの先頭位置を各々示すP−TNo1、P−TNo2、・・・P−TNo255から構成される。
【0007】
P−FRAを参照して離散的に記録されているデータを連続的に再生する処理の一例を図42を用いて説明する。この図42は、P−FRAに03hが記録されている。この場合には、まず、図42Aに示すようにスロット03hがアクセスされる。このスロット03hに記録されているスタートアドレスおよびエンドアドレスは、ディスク上に記録された1つのパーツの起点アドレスと終点アドレスを示す。
【0008】
スロット03hに記録されているリンク情報は、後続すべきスロットのアドレス18hを示している(図42A)。そこで、スロット18hがアクセスされる。スロット18hに記録されているリンク情報が後続すべきスロットのアドレスが1Fhであることを示している(図42B)ので、さらにスロット1Fhがアクセスされる(図42C)。そして、スロット1Fhのリンク情報に従って、スロット2Bhがアクセスされ(図42D)、さらにスロット2Bhのリンク情報に従ってスロットE3hがアクセスされる(図42E)。このようにして、リンク情報としてnull(すなわち00h)が現れるまで次々にリンク情報をたどることにより、MD上に離散的に記録されたデータのアドレスが順に認識される。光ピックアップを制御して、MD上のこれらのアドレスに順にアクセスしていくことにより、離散的に記録されたデータをつなげることが可能となる。また、P−DFA、P−Empty、P−TNoNを参照しても同様に離散的に記録されているデータを連続的に再生することができる。
【0009】
【発明が解決しようとする課題】
このMDに適応されているリンクPを用いれば曲の入れ替えや曲に対する分割処理や結合処理に関して容易に行うことができる。
【0010】
しかしながら、従来光デイスクで曲の編集を行えるものは存在していたが、不揮発性メモリでファイルの編集を行えるものは存在しなかった。
【0011】
特に、曲の分割処理や曲の結合処理を行う場合に、FATの編集を行えば基本的にMDに適応されているリンクPの編集同様に実現できるが、FATが破壊された場合には編集処理は行えなくなるばかりか編集処理後のファイルのアクセスも不可能となる。
【0012】
特に、フラッシュメモリにおいては、同一個所を何度も書き換えると、そのブロック部分が破壊されるのでブロックを移動しながら記録を行うのが一般的である。
【0013】
しかしながら、ブロックを移動しながら書き換えを行っていっても何度も編集を行っている内にフラッシュメモリ上に欠陥ブロックが発生することがあり、このときFAT情報を管理しているブロックが壊れてしまうと編集処理は行えなくなるばかりか編集処理後のファイルのアクセスも不可能となる問題があった。
【0014】
従って、この発明の目的は、データファイルをFATシステムで管理し、データファイルが編集されてもメモリの小さなCPUでも容易に扱えるようにした編集装置及び方法を提供することにある。
【0015】
【課題を解決するための手段】
上述した課題を解決するために、請求項1の発明は、連続して再生される単一データファイルを所定長単位でブロック化し、ブロック化されたデータファイルと、データファイルのブロック化された情報からなる属性ファイルとが記録されたデータ領域と、データ領域に記録されたデータファイルを管理する管理データが記録された管理領域から成る不揮発性メモリにファイルアロケーションに対応して記録されたデータファイルを編集する編集装置において、データ領域に記録されている複数のデータファイルの中から2つのデータファイルを結合処理するために、結合処理後の再生時に、再生する順番が先になる第1のデータファイルと、再生する順番が後になる第2のデータファイルとを選択する操作手段と、操作手段にて選択された第1および第2のデータファイルを論理的にリンクするように第1のデータファイルを管理する第1の管理データの第1のデータファイルの終端を示すアドレスを、第2のデータファイルの先頭を示すアドレスへ変更する編集手段と、操作手段にて選択された第1のデータファイルのブロック化された情報が記録された第1の属性ファイルの情報を変更すると共に、第2のデータファイルのブロック化された情報が記録された第2の属性ファイルを削除する属性ファイル変更手段と、編集手段にて編集された第1の管理データを管理領域に記録すると共に、変更手段にて変更された第1の属性ファイルをデータ領域に記録する記録手段とからなることを特徴とする編集装置である。
【0016】
請求項11に記載の発明は、連続して再生される単一データファイルを所定長単位でブロック化し、ブロック化されたデータファイルと、データファイルのブロック化された情報からなる属性ファイルとが記録されたデータ領域と、データ領域に記録されたデータファイルを管理する管理データが記録された管理領域から成る不揮発性メモリにファイルアロケーションに対応して記録されたデータファイルを編集する編集方法において、データ領域に記録されている複数のデータファイルの中から2つのデータファイルを結合処理するために、結合処理後の再生時に、再生する順番が先になる第1のデータファイルと、再生する順番が後になる第2のデータファイルとを選択するステップと、操作手段にて選択された第1および第2のデータファイルを論理的にリンクするように第1のデータファイルを管理する第1の管理データの第1のデータファイルの終端を示すアドレスを、第2のデータファイルの先頭を示すアドレスへ変更するステップと、操作手段にて選択された第1のデータファイルのブロック化された情報が記録された第1の属性ファイルの情報を変更すると共に、第2のデータファイルのブロック化された情報が記録された第2の属性ファイルを削除するステップと、変更された第1の管理データを管理領域に記録すると共に、変更された第1の属性ファイルをデータ領域に記録するステップとからなることを特徴とする編集方法である。
【0017】
請求項12に記載の発明は、連続して再生される単一データファイルを所定長単位でブロック化し、ブロック化されたデータファイルと、データファイルのブロック化された情報からなる属性ファイルとが記録されたデータ領域と、データ領域に記録されたデータファイルを管理する管理データが記録された管理領域から成る不揮発性メモリにファイルアロケーションに対応して記録されたデータファイルを編集する装置において、データ領域に記録されている所定のデータファイル中から分割処理するためのデータファイルを選択し、選択されたデータファイルの再生時に、再生する順番が先になる第1のデータファイルと、再生する順番が後になる第2のデータファイルとの分割点を設定する操作手段と、分割点が設定されたデータファイルを管理する管理データを、設定された分割点に対応するように、第1のデータファイルを管理する第1の管理データと、第2のデータファイルを管理する第2の管理データとを形成する編集手段と、分割点が設定されたデータファイルのブロック化された情報が記録された属性ファイルから、設定された分割点に対応するように、第1のデータファイルのブロック化された情報が記録された第1の属性ファイルと、第2のデータファイルのブロック化された情報が記録された第2の属性ファイルとを生成する生成手段と、編集手段にて形成された第1および第2の管理データを管理領域に記録すると共に、生成手段にて生成された第1および第2の属性ファイルをデータ領域に記録する記録手段とからなることを特徴とする編集装置である。
【0018】
請求項21に記載の発明は、連続して再生される単一データファイルを所定長単位でブロック化し、ブロック化されたデータファイルと、データファイルのブロック化された情報からなる属性ファイルとが記録されたデータ領域と、データ領域に記録されたデータファイルを管理する管理データが記録された管理領域から成る不揮発性メモリにファイルアロケーションに対応して記録されたデータファイルを編集する編集方法において、データ領域に記録されている所定のデータファイル中から分割処理するためのデータファイルを選択し、選択されたデータファイルの再生時に、再生する順番が先になる第1のデータファイルと、再生する順番が後になる第2のデータファイルとの分割点を設定するステップと、分割点が設定されたデータファイルを管理する管理データを、設定された分割点に対応するように、第1のデータファイルを管理する第1の管理データと、第2のデータファイルを管理する第2の管理データとを形成するステップと、分割点が設定されたデータファイルのブロック化された情報が記録された属性ファイルから、設定された分割点に対応するように、第1のデータファイルのブロック化された情報が記録された第1の属性ファイルと、第2のデータファイルのブロック化された情報が記録された第2の属性ファイルとを生成するステップと、形成された第1および第2の管理データを管理領域に記録すると共に、生成された第1および第2の属性ファイルをデータ領域に記録するステップとからなることを特徴とする編集方法である。
【0019】
着脱可能な不揮発性メモリに記憶されたデータファイルに対して編集操作、例えば2つのトラックAおよびBを1つのトラックAにするコンバインを行った場合、トラックBのパーツ情報領域PRTINFがトラックAのパーツ情報領域PRTINFの後に移動され、トラックBのトラック情報領域TRKINFが削除される。このとき、トラックAの音のファイルのチェーンの後に、トラックBの音のファイルのチェーンが移動される。そして、トラックAのトラック情報領域TRKINFが更新され、2つのパーツ情報領域PRTINFが隣接して並べられる。すなわち、トラックAのトラック情報領域TRKINF、トラックAのパーツ情報領域PRTINF、トラックBのパーツ情報領域PRTINFの順番に隣接される。
【0020】
【発明の実施の形態】
以下、この発明の一実施形態について説明する。図1は、この発明の一実施形態におけるメモリカードを使用したディジタルオーディオレコーダ/プレーヤの全体の構成を示す。この一実施形態は、記録媒体として、着脱自在のメモリカードを使用するディジタルオーディオ信号の記録および再生機である。より具体的には、このレコーダ/プレーヤは、アンプ装置、スピーカ、CDプレーヤ、MDレコーダ、チューナ等と共にオーディオシステムを構成する。この発明は、これ以外のオーディオレコーダに対しても適用できる。すなわち、携帯型記録再生装置に対しても適用できる。また、衛星を使用したデータ通信、ディジタル放送、インターネット等を経由して配信されるディジタルオーディオ信号を記録するセットトップボックスに対しても適用できる。さらに、ディジタルオーディオ信号以外に動画データ、静止画データ等の記録/再生に対してもこの発明を適用できる。一実施形態においても、ディジタルオーディオ信号以外の画像、文字等の付加情報を記録/再生可能としている。
【0021】
記録再生装置は、それぞれ1チップICで構成されたオーディオエンコーダ/デコーダIC10、セキュリティIC20、DSP(Digital Signal Processor)30を有する。さらに、記録再生装置本体に対して着脱自在のメモリカード40を備える。メモリカード40は、フラッシュメモリ(不揮発性メモリ)、メモリコントロールブロック、DES(Data Encryption Standard)の暗号化回路を含むセキュリティブロックが1チップ上にIC化されたものである。なお、この一実施形態では、DSP30を使用しているが、マイクロコンピュータを使用しても良い。
【0022】
オーディオエンコーダ/デコーダIC10は、オーディオインタフェース11およびエンコーダ/デコーダブロック12を有する。エンコーダ/デコーダブロック12は、ディジタルオーディオ信号をメモリカード40に書き込むために高能率符号化し、また、メモリカード40から読み出されたデータを復号する。高能率符号化方法としては、ミニディスクで採用されているATRAC(Adaptive Transform Acoustic Coding)を改良したATRAC3が使用される。
【0023】
上述のATRAC3では、サンプリング周波数=44.1kHzでサンプリングした量子化ビットが16ビットのオーディオデータを高能率符号化処理する。ATRAC3でオーディオデータを処理する時の最小のデータ単位がサウンドユニットSUである。1SUは、1024サンプル分(1024×16ビット×2チャンネル)を数百バイトに圧縮したものであり、時間にして約23m秒である。上述の高能率符号化処理により約1/10にオーディオデータが圧縮される。ミニディスクで適用されたATRAC1と同様に、ATRAC3方式において、信号処理されたオーディオ信号の圧縮/伸長処理による音質の劣化は少ない。
【0024】
ライン入力セレクタ13は、MDの再生出力、チューナの出力、テープ再生出力を選択的にA/D変換器14に供給する。A/D変換器14は、入力されるライン入力信号をサンプリング周波数=44.1kHz、量子化ビット=16ビットのディジタルオーディオ信号へ変換する。ディジタル入力セレクタ16は、MD、CD、CS(衛星ディジタル放送)のディジタル出力を選択的にディジタル入力レシーバ17に供給する。上述のディジタル入力は、例えば光ケーブルを介して伝送される。ディジタル入力レシーバ17の出力がサンプリングレートコンバータ15に供給され、ディジタル入力のサンプリング周波数が44.1kHz、量子化ビットが16ビットのデジタルオーディオ信号に変換される。
【0025】
オーディオエンコーダ/デコーダIC10のエンコーダ/デコーダブロック12からの符号化データがセキュリティIC20のインタフェース21を介してDESの暗号化回路22に供給される。DESの暗号化回路22は、FIFO23を有している。DESの暗号化回路22は、コンテンツの著作権を保護するために備えられている。メモリカード40にも、DESの暗号化回路が組み込まれている。記録再生装置のDESの暗号化回路22は、複数のマスターキーと機器毎にユニークなストレージキーを持つ。さらに、DESの暗号化回路22は、乱数発生回路を持ち、DESの暗号化回路を内蔵するメモリカードと認証およびセッションキーを共有することができる。よりさらに、DESの暗号化回路22は、DESの暗号化回路を通してストレージキーでキーをかけなおすことができる。
【0026】
DESの暗号化回路22からの暗号化されたオーディオデータがDSP(Digit al Signal Processor) 30に供給される。DSP30は、着脱機構(図示しない)に装着されたメモリカード40とメモリインタフェースを介しての通信を行い、暗号化されたデータをフラッシュメモリに書き込む。DSP30とメモリカード40との間では、シリアル通信がなされる。また、メモリカードの制御に必要なメモリ容量を確保するために、DSP30に対して外付けのSRAM(Static Random Access Memory) 31が接続される。
【0027】
さらに、DSP30に対して、バスインタフェース32が接続され、図示しない外部のコントローラからのデータがバス33を介してDSP30に供給される。外部のコントローラは、オーディオシステム全体の動作を制御し、操作部からのユーザの操作に応じて発生した録音指令、再生指令等のデータをDSP30にバスインタフェース32を介して与える。また、画像情報、文字情報等の付加情報のデータもバスインタフェース32を介してDSP30に供給される。バス33は、双方向通信路であり、メモリカード40から読み出された付加情報データ、制御信号等がDSP30、バスインターフェース32、バス33を介して外部のコントローラに取り込まれる。外部のコントローラは、具体的には、オーディオシステム内に含まれる他の機器例えばアンプ装置に含まれている。さらに、外部のコントローラによって、付加情報の表示、レコーダの動作状態等を表示するための表示が制御される。表示部は、オーディオシステム全体で共用される。ここで、バス33を介して送受信されるデータは、著作物ではないので、暗号化がされない。
【0028】
DSP30によってメモリカード40から読み出した暗号化されたオーディオデータは、セキュリティIC20によって復号化され、オーディオエンコーダ/デコーダIC10によってATRAC3の復号化処理を受ける。オーディオエンコーダ/デコーダ10の出力がD/A変換器18に供給され、アナログオーディオ信号へ変換される。そして、アナログオーディオ信号がライン出力端子19に取り出される。
【0029】
ライン出力は、図示しないアンプ装置に伝送され、スピーカまたはヘッドホンにより再生される。D/A変換器18に対してミューティング信号が外部のコントローラから供給される。ミューティング信号がミューティングのオンを示す時には、ライン出力端子19からのオーディオ出力が禁止される。
【0030】
図2は、DSP30の内部構成を示す。DSP30は、Core34と、フラッシュメモリ35と、SRAM36と、バスインタフェース37と、メモリカードインタフェース38と、バスおよびバス間のブリッジとで構成される。DSP30は、マイクロコンピュータと同様な機能を有し、Core34がCPUに相当する。フラッシュメモリ35にDSP30の処理のためのプログラムが格納されている。SRAM36と外部のSRAM31とがRAMとして使用される。
【0031】
DSP30は、バスインタフェース32、37を介して受け取った録音指令等の操作信号に応答して、所定の暗号化されたオーディオデータ、所定の付加情報データをメモリカード40に対して書き込み、また、これらのデータをメモリカード40から読み出す処理を制御する。すなわち、オーディオデータ、付加情報の記録/再生を行うためのオーディオシステム全体のアプリケーションソフトウェアと、メモリカード40との間にDSP30が位置し、メモリカード40のアクセス、ファイルシステム等のソフトウェアによってDSP30が動作する。
【0032】
DSP30におけるメモリカード40上のファイル管理は、既存のパーソナルコンピュータで使用されているFATシステムが使用される。このファイルシステムに加えて、一実施形態では、後述するようなデータ構成の管理ファイルが使用される。管理ファイルは、メモリカード40上に記録されているデータファイルを管理する。第1のファイル管理情報としての管理ファイルは、オーディオデータのファイルを管理するものである。第2のファイル管理情報としてのFATは、オーディオデータのファイルと管理ファイルを含むメモリカード40のフラッシュメモリ上のファイル全体を管理する。管理ファイルは、メモリカード40に記録される。また、FATは、ルートディレクトリ等と共に、予め出荷時にフラッシュメモリ上に書き込まれている。FATの詳細に関しては後述する。
【0033】
なお、一実施形態では、著作権を保護するために、ATRAC3により圧縮されたオーディオデータを暗号化している。一方、管理ファイルは、著作権保護が必要ないとして、暗号化を行わないようにしている。また、メモリカードとしても、暗号化機能を持つものと、これを持たないものとがありうる。一実施形態のように、著作物であるオーディオデータを記録するレコーダが対応しているメモリカードは、暗号化機能を持つメモリカードのみである。上述の暗号化機能を有さないメモリカードには、個人が録音したVoiceまたは録画した画像が記録される。
【0034】
図3は、メモリカード40の構成を示す。メモリカード40は、コントロールブロック41とフラッシュメモリ42が1チップICとして構成されたものである。プレーヤ/レコーダのDSP30とメモリカード40との間の双方向シリアルインタフェースは、10本の線からなる。主要な4本の線は、データ伝送時にクロックを伝送するためのクロック線SCKと、ステータスを伝送するためのステータス線SBSと、データを伝送するデータ線DIO、インターラプト線INTとである。その他に電源供給用線として、2本のGND線および2本のVCC線が設けられる。2本の線Reservは、未定義の線である。
【0035】
クロック線SCKは、データに同期したクロックを伝送するための線である。ステータス線SBSは、メモリカード40のステータスを表す信号を伝送するための線である。データ線DIOは、コマンドおよび暗号化されたオーディオデータを入出力するための線である。インターラプト線INTは、メモリカード40からプレーヤ/レコーダのDSP30に対しての割り込みを要求するインターラプト信号を伝送する線である。メモリカード40を装着した時にインターラプト信号が発生する。但し、この一実施形態では、インターラプト信号をデータ線DIOを介して伝送するようにしているので、インターラプト線INTを接地している。
【0036】
コントロールブロック41のシリアル/パラレル変換・パラレル/シリアル変換・インタフェースブロック(S/P・P/S・IFブロックと略す)43は、上述した複数の線を介して接続されたレコーダのDSP30とコントロールブロック41とのインタフェースである。S/P・P/S・IFブロック43は、プレーヤ/レコーダのDSP30から受け取ったシリアルデータをパラレルデータに変換し、コントロールブロック41に取り込み、コントロールブロック41からのパラレルデータをシリアルデータに変換してプレーヤ/レコーダのDSP30に送る。また、S/P・P/S・IFブロック43は、データ線DIOを介して伝送されるコマンドおよびデータを受け取った時に、フラッシュメモリ42に対する通常のアクセスのためのコマンドおよびデータと、暗号化に必要なコマンドおよびデータとを分離する。
【0037】
データ線DIOを介して伝送されるフォーマットでは、最初にコマンドが伝送され、その後にデータが伝送される。S/P・P/S・IFブロック43は、コマンドのコードを検出して、通常のアクセスに必要なコマンドおよびデータか、暗号化に必要なコマンドおよびデータかを判別する。この判別結果に従って、通常のアクセスに必要なコマンドをコマンドレジスタ44に格納し、データをページバッファ45およびライトレジスタ46に格納する。ライトレジスタ46と関連してエラー訂正符号化回路47が設けられている。ページバッファ45に一時的に蓄えられたデータに対して、エラー訂正符号化回路47がエラー訂正符号の冗長コードを生成する。
【0038】
コマンドレジスタ44、ページバッファ45、ライトレジスタ46およびエラー訂正符号化回路47の出力データがフラッシュメモリインタフェースおよびシーケンサ(メモリI/F・シーケンサと略す)51に供給される。メモリIF・シーケンサ51は、コントロールブロック41とフラッシュメモリ42とのインタフェースであり、両者の間のデータのやり取りを制御する。メモリIF・シーケンサ51を介してデータがフラッシュメモリ42に書き込まれる。
【0039】
フラッシュメモリ42に書き込まれるATRAC3により圧縮されたオーディオデータ(以下、ATRAC3データと表記する)は、著作権保護のために、プレーヤ/レコーダのセキュリティIC20とメモリカード40のセキュリティブロック52とによって、暗号化されたものである。セキュリティブロック52は、バッファメモリ53と、DESの暗号化回路54と、不揮発性メモリ55とを有する。
【0040】
メモリカード40のセキュリティブロック52は、複数の認証キーとメモリカード毎にユニークなストレージキーを持つ。不揮発性メモリ55は、暗号化に必要なキーを格納するもので、チップ解析を行っても解析不能な構造となっている。この実施形態では、例えばストレージキーが不揮発性メモリ55に格納される。さらに、乱数発生回路を持ち、対応可能なプレーヤ/レコーダと認証ができ、セッションキーを共有できる。DESの暗号化回路54を通して、コンテンツキーをストレージキーでキーのかけ直しを行う。
【0041】
例えばメモリカード40をプレーヤ/レコーダに装着した時に相互に認証がなされる。認証は、プレーヤ/レコーダのセキュリティIC20とメモリカード40のセキュリティブロック52によって行わせる。プレーヤ/レコーダは、装着されたメモリカード40が対応可能なメモリカードであることを認証し、また、メモリカード40が相手のプレーヤ/レコーダが対応可能なプレーヤ/レコーダであることを認証すると、相互認証処理が正常に行われたことを意味する。認証が行われると、プレーヤ/レコーダとメモリカード40がそれぞれセッションキーを生成し、セッションキーを共有する。セッションキーは、認証の度に生成される。
【0042】
メモリカード40に対するコンテンツの書き込み時には、プレーヤ/レコーダがセッションキーでコンテンツキーを暗号化してメモリカード40に渡す。メモリカード40では、コンテンツキーをセッションキーで復号し、ストレージキーで暗号化してプレーヤ/レコーダに渡す。ストレージキーは、メモリカード40の一つ一つにユニークなキーであり、プレーヤ/レコーダは、暗号化されたコンテンツキーを受け取ると、フォーマット処理を行い、暗号化されたコンテンツキーと暗号化されたコンテンツをメモリカード40に書き込む。
【0043】
以上、メモリカード40に対する書き込み処理について説明したが、以下メモリカード40からの読み出し処理について説明する。フラッシュメモリ42から読み出されたデータがメモリIF・シーケンサ51を介してページバッファ45、リードレジスタ48、エラー訂正回路49に供給される。ページバッファ45に記憶されたデータがエラー訂正回路49によってエラー訂正がなされる。エラー訂正がされたページバッファ45の出力およびリードレジスタ48の出力がS/P・P/S・IFブロック43に供給され、上述したシリアルインタフェースを介してプレーヤ/レコーダのDSP30に供給される。
【0044】
読み出し時には、ストレージキーで暗号化されたコンテンツキーとブロックキーで暗号化されたコンテンツとがフラッシュメモリ42から読み出される。セキュリティブロック52によって、ストレージキーでコンテンツキーが復号される。復号したコンテンツキーがセッションキーで再暗号化されてプレーヤ/レコーダ側に送信される。プレーヤ/レコーダは、受信したセッションキーでコンテンツキーを復号する。プレーヤ/レコーダは、復号したコンテンツキーでブロックキーを生成する。このブロックキーによって、暗号化されたATRAC3データを順次復号する。
【0045】
なお、ConfigROM50は、メモリカード40のバージョン情報、各種の属性情報等が格納されているメモリである。また、メモリカード40には、ユーザが必要に応じて操作可能な誤消去防止用のスイッチ60が備えられている。このスイッチ60が消去禁止の接続状態にある場合には、フラッシュメモリ42を消去することを指示するコマンドがレコーダ側から送られてきても、フラッシュメモリ42の消去が禁止される。さらに、OSC Cont.61は、メモリカード40の処理のタイミング基準となるクロックを発生する発振器である。
【0046】
図4は、メモリカードを記憶媒体とするコンピュータシステムのファイルシステム処理階層を示す。ファイルシステム処理階層としては、アプリケーション処理層が最上位であり、その下に、ファイル管理処理層、論理アドレス管理層、物理アドレス管理層、フラッシュメモリアクセスが順次積層される。上述の階層構造において、ファイル管理処理層がFATシステムである。物理アドレスは、フラッシュメモリの各ブロックに対して付されたもので、ブロックと物理アドレスの対応関係は、不変である。論理アドレスは、ファイル管理処理層が論理的に扱うアドレスである。
【0047】
図5は、メモリカード40におけるフラッシュメモリ42のデータの物理的構成の一例を示す。フラッシュメモリ42は、セグメントと称されるデータ単位が所定数のブロック(固定長)へ分割され、1ブロックが所定数のページ(固定長)へ分割される。フラッシュメモリ42では、ブロック単位で消去が一括して行われ、書き込みと読み出しは、ページ単位で一括して行われる。各ブロックおよび各ページは、それぞれ同一のサイズとされ、1ブロックがページ0からページmで構成される。1ブロックは、例えば8KB(Kバイト)バイトまたは16KBの容量とされ、1ページが512Bの容量とされる。フラッシュメモリ42全体では、1ブロック=8KBの場合で、4MB(512ブロック)、8MB(1024ブロック)とされ、1ブロック=16KBの場合で、16MB(1024ブロック)、32MB(2048ブロック)、64MB(4096ブロック)の容量とされる。
【0048】
1ページは、512バイトのデータ部と16バイトの冗長部とからなる。冗長部の先頭の3バイトは、データの更新に応じて書き換えられるオーバーライト部分とされる。3バイトの各バイトに、先頭から順にブロックステータス、ページステータス、更新ステータスが記録される。冗長部の残りの13バイトの内容は、原則的にデータ部の内容に応じて固定とされる。13バイトは、管理フラグ(1バイト)、論理アドレス(2バイト)、フォーマットリザーブの領域(5バイト)、分散情報ECC(2バイト)およびデータECC(3バイト)からなる。分散情報ECCは、管理フラグ、論理アドレス、フォーマットリザーブに対する誤り訂正用の冗長データであり、データECCは、512バイトのデータに対する誤り訂正用の冗長データである。
【0049】
管理フラグとして、システムフラグ(その値が1:ユーザブロック、0:ブートブロック)、変換テーブルフラグ(1:無効、0:テーブルブロック)、コピー禁止指定(1:OK、0:NG)、アクセス許可(1:free、0:リードプロテクト)の各フラグが記録される。
【0050】
先頭の二つのブロック0およびブロック1がブートブロックである。ブロック1は、ブロック0と同一のデータが書かれるバックアップ用である。ブートブロックは、カード内の有効なブロックの先頭ブロックであり、メモリカードを機器に装填した時に最初にアクセスされるブロックである。残りのブロックがユーザブロックである。ブートブロックの先頭のページ0にヘッダ、システムエントリ、ブート&アトリビュート情報が格納される。ページ1に使用禁止ブロックデータが格納される。ページ2にCIS(Card Information Structure)/IDI(Identify Drive Information)が格納される。
【0051】
ブートブロックのヘッダは、ブートブロックID、ブートブロック内の有効なエントリ数が記録される。システムエントリには、使用禁止ブロックデータの開始位置、そのデータサイズ、データ種別、CIS/IDIのデータ開始位置、そのデータサイズ、データ種別が記録される。ブート&アトリビュート情報には、メモリカードのタイプ(読み出し専用、リードおよびライト可能、両タイプのハイブリッド等)、ブロックサイズ、ブロック数、総ブロック数、セキュリティ対応か否か、カードの製造に関連したデータ(製造年月日等)等が記録される。
【0052】
フラッシュメモリは、データの書き換えを行うことにより絶縁膜の劣化を生じ、書き換え回数が制限される。従って、ある同一の記憶領域(ブロック)に対して繰り返し集中的にアクセスがなされることを防止する必要がある。従って、ある物理アドレスに格納されているある論理アドレスのデータを書き換える場合、フラッシュメモリのファイルシステムでは、同一のブロックに対して更新したデータを再度書き込むことはせずに、未使用のブロックに対して更新したデータを書き込むようになされる。その結果、データ更新前における論理アドレスと物理アドレスの対応関係が更新後では、変化する。スワップ処理を行うことで、同一のブロックに対して繰り返して集中的にアクセスがされることが防止され、フラッシュメモリの寿命を延ばすことが可能となる。
【0053】
論理アドレスは、一旦ブロックに対して書き込まれたデータに付随するので、更新前のデータと更新後のデータの書き込まれるブロックが移動しても、FATからは、同一のアドレスが見えることになり、以降のアクセスを適正に行うことができる。スワップ処理により論理アドレスと物理アドレスとの対応関係が変化するので、両者の対応を示す論理−物理アドレス変換テーブルが必要となる。このテーブルを参照することによって、FATが指定した論理アドレスに対応する物理アドレスが特定され、特定された物理アドレスが示すブロックに対するアクセスが可能となる。
【0054】
論理−物理アドレス変換テーブルは、DSP30によってSRAM上に格納される。若し、RAM容量が少ない時は、フラッシュメモリ中に格納することができる。このテーブルは、概略的には、昇順に並べた論理アドレス(2バイト)に物理アドレス(2バイト)をそれぞれ対応させたテーブルである。フラッシュメモリの最大容量を128MB(8192ブロック)としているので、2バイトによって8192のアドレスを表すことができる。また、論理−物理アドレス変換テーブルは、セグメント毎に管理され、そのサイズは、フラッシュメモリの容量に応じて大きくなる。例えばフラッシュメモリの容量が8MB(2セグメント)の場合では、2個のセグメントのそれぞれに対して2ページが論理−物理アドレス変換テーブル用に使用される。論理−物理アドレス変換テーブルを、フラッシュメモリ中に格納する時には、上述した各ページの冗長部における管理フラグの所定の1ビットによって、当該ブロックが論理−物理アドレス変換テーブルが格納されているブロックか否かが指示される。
【0055】
上述したメモリカードは、ディスク状記録媒体と同様にパーソナルコンピュータのFATシステムによって使用可能なものである。図5には示されてないが、フラッシュメモリ上にIPL領域、FAT領域およびルート・ディレクトリ領域が設けられる。IPL領域には、最初にレコーダのメモリにロードすべきプログラムが書かれているアドレス、並びにメモリの各種情報が書かれている。FAT領域には、ブロック(クラスタ)の関連事項が書かれている。FATには、未使用のブロック、次のブロック番号、不良ブロック、最後のブロックをそれぞれ示す値が規定される。さらに、ルートディレクトリ領域には、ディレクトリエントリ(ファイル属性、更新年月日、開始クラスタ、ファイルサイズ等)が書かれている。
【0056】
図6にFAT管理による管理方法を説明する。この図6は、メモリ内の模式図を示しており、上からパーティションテーブル部、空き領域、ブートセクタ、FAT領域、FATのバックアップ領域、Root Directory領域、Sub Directory領域、データ領域が積層されている。なお、メモリマップは、論理―物理アドレス変換テーブルに基づいて、論理アドレスから物理アドレスへ変換した後のメモリマップである。
【0057】
上述したブートセクタ、FAT領域、FATのバックアップ領域、RootDirectory領域、Sub Directory領域、データ領域を全部まとめてFATパーティション領域と称する。
【0058】
上述のパーティションテーブル部には、FATパーティション領域の始めと終わりのアドレスが記録されている。通常フロッピディスクで使用されているFATには、パーティションテーブル部は備えられていない。最初のトラックには、パーティションテーブル以外のものは置かないために空きエリアができてしまう。
【0059】
次に、ブートセクタには、12ビットFATおよび16ビットFATの何れかであるかでFAT構造の大きさ、クラスタサイズ、それぞれの領域のサイズが記録されている。FATは、データ領域に記録されているファイル位置を管理するものである。FATのコピー領域は、FATのバックアップ用の領域である。ルートデイレクトリ部は、ファイル名、先頭クラスタアドレス、各種属性が記録されており、1ファイルにつき32バイト使用する。
【0060】
サブデイレクトリ部は、デレクトリというファイルの属性のファイルとして存在しており、図6の実施形態ではPBLIST.MSF、CAT.MSA、DOG.MSA、MAN. MSFという4つのファイルが存在する。このサブデイレクトリ部には、ファイル名とFAT上の記録位置が管理されている。すなわち、図6においては、CAT.MSAというファイル名が記録されているスロットには「5」というFAT上のアドレスが管理されており、DOG.MSAというファイル名が記録されているスロットには「10」というFAT上のアドレスが管理されている。
【0061】
クラスタ2以降が実際のデータ領域で、このデータ領域にこの実施形態では、ATRAC3で圧縮処理されたオーデイオデータが記録される。さらに、MAN. MSAというファイル名が記録されているスロットには「110」というFAT上のアドレスが管理されている。
【0062】
この発明の実施形態では、クラスタ5、6、7および8にCAT.MSAというファイル名のATRAC3で圧縮処理されたオーデイオデータが記録され、クラスタ10、11および、12にDOG.MSAというファイル名の前半パートであるDOG−1がATRAC3で圧縮処理されたオーデイオデータが記録され、クラスタ100および101にDOG.MSAというファイル名の後半パートであるDOG−2がATRAC3で圧縮処理されたオーデイオデータが記録されている。さらに、クラスタ110および111にMAN.MSAというファイル名のATRAC3で圧縮処理されたオーデイオデータが記録されている。
【0063】
この実施形態においては、単一のファイルが2分割されて離散的に記録されている例を示している。また、データ領域上のEmptyとかかれた領域は記録可能領域である。
【0064】
クラスタ200以降は、ファイルネームを管理する領域であり、クラスタ200には、CAT.MSAというファイルが、クラスタ201には、DOG.MSAというファイルが、クラスタ202にはMAN.MSAというファイルが記録されている。ファイル順を並び替える場合には、このクラスタ200以降で並び替えを行えばよい。
【0065】
この実施形態のメモリカードが初めて挿入された場合には、先頭のパーティションテーブル部を参照してFATパーティション領域の始めと終わりのアドレスが記録されている。ブートセクタ部の再生を行った後にRoot Directory、Sub Directory部の再生を行う。そして、Sub Directory部に記録されている再生管理情報PBLIST.MSFが記録されているスロットを検索して、PBLIST.MSFが記録されているスロットの終端部のアドレスを参照する。
【0066】
この実施形態の場合には、PBLIST.MSFが記録されているスロットの終端部には「200」というアドレスが記録されているのでクラスタ200を参照する。クラスタ200以降は、ファイル名を管理するとともにファイルの再生順を管理する領域であり、この実施形態の場合には、CAT. MSAというファイルが1曲目となり、DOG.MSAというファイルが2曲目となり、MAN.MSAというファイルが3曲目となる。
【0067】
ここで、クラスタ200以降を全て参照したら、サブデレクトリ部に移行して、CAT. MSA、DOG.MSAおよびMAN.MSAという名前のファイル名と合致するスロットを参照する。この図6においては、CAT.MSAというファイル名が記録されたスロットの終端には「5」というアドレスが記録され、DOG. MSAというファイルが記録されたスロットの終端には「10」というアドレスが記録され、MAN.MSAというファイルが記録されたスロットの終端には110というアドレスが記録されている。
【0068】
CAT.MSAというファイル名が記録されたスロットの終端に記録された「5」というアドレスに基づいて、FAT上のエントリアドレスを検索する。エントリアドレス5には、「6」というクラスタアドレスがエントリされており、「6」というエントリアドレスを参照すると「7」というクラスタアドレスがエントリされており、「7」というエントリアドレスを参照すると「8」というクラスタアドレスがエントリされており、「8」というエントリアドレスを参照すると「FFF」という終端を意味するコードが記録されている。
【0069】
よって、CAT.MSAというファイルは、クラスタ5、6、7、8のクラスタ領域を使用しており、データ領域のクラスタ5、6、7、8を参照することでCAT.MSAというATRAC3データが実際に記録されている領域をアクセスすることができる。
【0070】
次に、離散記録されているDOG. MSAというファイルを検索する方法を以下に示す。DOG. MSAというファイル名が記録されたスロットの終端には「10」というアドレスが記録されている。ここで、「10」というアドレスに基づいて、FAT上のエントリアドレスを検索する。エントリアドレス10には、「11」というクラスタアドレスがエントリされており、「11」というエントリアドレスを参照すると「12」というクラスタアドレスがエントリされており、「12」というエントリアドレスを参照すると「100」というクラスタアドレスがエントリされている。さらに、「100」というエントリアドレスを参照すると「101」というクラスタアドレスがエントリされており、「101」というエントリアドレスを参照するとFFFという終端を意味するコードが記録されている。
【0071】
よって、DOG.MSAというファイルは、クラスタ10、11、12、100、101というクラスタ領域を使用しており、データ領域のクラスタ10、11、12を参照することでDOG.MSAというファイルの前半パートに対応するATRAC3データが実際に記録されている領域をアクセスすることができる。さらに、データ領域のクラスタ100、101を参照することでDOG.MSAというファイルの後半パートに対応するATRAC3データが実際に記録されている領域をアクセスすることができる。
【0072】
さらに、MAN.MSAというファイル名が記録されたスロットの終端に記録された「110」というアドレスに基づいて、FAT上のエントリアドレスを検索する。エントリアドレス110には、「111」というクラスタアドレスがエントリされており、「111」というエントリアドレスを参照すると「FFF」という終端を意味するコードが記録されている。
【0073】
よって、MAN.MSAというファイルは、クラスタ110、111というクラスタ領域を使用しており、データ領域のクラスタ110、111を参照することでMAN.MSAというATRAC3データが実際に記録されている領域をアクセスすることができる。
【0074】
以上のようにフラッシュメモリ上で離散して記録されたデータファイルを連結してシーケンシャルに再生することが可能となる。
【0075】
この一実施形態では、上述したメモリカード40のフォーマットで規定されるファイル管理システムとは別個に、音楽用ファイルに対して、各トラックおよび各トラックを構成するパーツを管理するための管理ファイルを持つようにしている。この管理ファイルは、メモリカード40のユーザブロックを利用してフラッシュメモリ42上に記録される。それによって、後述するように、メモリカード40上のFATが壊れても、ファイルの修復を可能となる。
【0076】
この管理ファイルは、DSP30により作成される。例えば最初に電源をオンした時に、メモリカード40の装着されているか否かが判定され、メモリカードが装着されている時には、認証が行われる。認証により正規のメモリカードであることが確認されると、フラッシュメモリ42のブートブロックがDSP30に読み込まれる。そして、論理−物理アドレス変換テーブルが読み込まれる。読み込まれたデータは、SRAMに格納される。ユーザが購入して初めて使用するメモリカードでも、出荷時にフラッシュメモリ42には、FATや、ルートディレクトリの書き込みがなされている。管理ファイルは、録音がなされると、作成される。
【0077】
すなわち、ユーザのリモートコントロール等によって発生した録音指令が外部のコントローラからバスおよびバスインターフェース32を介してDSP30に与えられる。そして、受信したオーディオデータがエンコーダ/デコーダIC10によって圧縮され、エンコーダ/デコーダIC10からのATRAC3データがセキュリティIC20により暗号化される。DSP30が暗号化されたATRAC3データをメモリカード40のフラッシュメモリ42に記録する。この記録後にFATおよび管理ファイルが更新される。ファイルの更新の度、具体的には、オーディオデータの記録を開始し、記録を終了する度に、SRAM31および36上でFATおよび管理ファイルが書き換えられる。そして、メモリカード40を外す時に、またはパワーをオフする時に、SRAM31、36からメモリカード40のフラッシュメモリ42上に最終的なFATおよび管理ファイルが格納される。この場合、オーディオデータの記録を開始し、記録を終了する度に、フラッシュメモリ42上のFATおよび管理ファイルを書き換えても良い。編集を行った場合も、管理ファイルの内容が更新される。
【0078】
さらに、この一実施形態のデータ構成では、付加情報も管理ファイル内に作成、更新され、フラッシュメモリ42上に記録される。管理ファイルの他のデータ構成では、付加情報管理ファイルがトラック管理用の管理ファイルとは別に作成される。付加情報は、外部のコントローラからバスおよびバスインターフェース32を介してDSP30に与えられる。DSP30が受信した付加情報をメモリカード40のフラッシュメモリ42上に記録する。付加情報は、セキュリティIC20を通らないので、暗号化されない。付加情報は、メモリカード40を取り外したり、電源オフの時に、DSP30のSRAMからフラッシュメモリ42に書き込まれる。
【0079】
図7は、メモリカード40のファイル構成の全体を示す。ディレクトリとして、静止画用ディレクトリ、動画用ディレクトリ、Voice用ディレクトリ、制御用ディレクトリ、音楽用(HIFI)ディレクトリが存在する。この一実施形態は、音楽の記録/再生を行うので、以下、音楽用ディレクトリについて説明する。音楽用ディレクトリには、2種類のファイルが置かれる。その1つは、再生管理ファイルPBLIST.MSF(以下、単にPBLISTと表記する)であり、他のものは、暗号化された音楽データを収納したATRAC3データファイルA3Dnnnn.MSA(以下、単にA3Dnnnと表記する)とからなる。ATRAC3データファイルは、最大数が400までと規定されている。すなわち、最大400曲まで収録可能である。ATRAC3データファイルは、再生管理ファイルに登録した上で機器により任意に作成される。
【0080】
図8は、再生管理ファイルの構成を示し、図9が1FILE(1曲)のATRAC3データファイルの構成を示す。再生管理ファイルは、16KB固定長のファイルである。ATRAC3データファイルは、曲単位でもって、先頭の属性ヘッダと、それに続く実際の暗号化された音楽データとからなる。属性ヘッダも16KB固定長とされ、再生管理ファイルと類似した構成を有する。
【0081】
図8に示す再生管理ファイルは、ヘッダ、1バイトコードのメモリカードの名前NM1−S、2バイトコードのメモリカードの名前NM2−S、曲順の再生テーブルTRKTBL、メモリカード全体の付加情報INF−Sとからなる。図9に示すデータファイルの先頭の属性ヘッダは、ヘッダ、1バイトコードの曲名NM1、2バイトコードの曲名NM2、トラックのキー情報等のトラック情報TRKINF、パーツ情報PRTINFと、トラックの付加情報INFとからなる。ヘッダには、総パーツ数、名前の属性、付加情報のサイズの情報等が含まれる。
【0082】
属性ヘッダに対してATRAC3の音楽データが続く。音楽データは、16KBのブロック毎に区切られ、各ブロックの先頭にヘッダが付加されている。ヘッダには、暗号を復号するための初期値が含まれる。なお、暗号化の処理を受けるのは、ATRAC3データファイル中の音楽データのみであって、それ以外の再生管理ファイル、ヘッダ等のデータは、暗号化されない。
【0083】
図10を参照して、曲とATRAC3データファイルの関係について説明する。1トラックは、1曲を意味する。1曲は、1つのATRAC3データファイル(図9参照)で構成される。ATRAC3データファイルは、ATRAC3により圧縮されたオーディオデータである。メモリカード40に対しては、クラスタと呼ばれる単位で記録される。1クラスタは、例えば16KBの容量である。1クラスタに複数のファイルが混じることがない。フラッシュメモリ42を消去する時の最小単位が1ブロックである。音楽データを記録するのに使用するメモリカード40の場合、ブロックとクラスタは、同意語であり、且つ1クラスタ=1セクタと定義されている。
【0084】
1曲は、基本的に1パーツで構成されるが、編集が行われると、複数のパーツから1曲が構成されることがある。パーツは、録音開始からその停止までの連続した時間内で記録されたデータの単位を意味し、通常は、1トラックが1パーツで構成される。曲内のパーツのつながりは、各曲の属性ヘッダ内のパーツ情報PRTINFで管理する。すなわち、パーツサイズは、PRTINFの中のパーツサイズPRTSIZEという4バイトのデータで表す。パーツサイズPRTSIZEの先頭の2バイトがパーツが持つクラスタの総数を示し、続く各1バイトが先頭および末尾のクラスタ内の開始サウンドユニット(以下、SUと略記する)の位置、終了SUの位置を示す。このようなパーツの記述方法を持つことによって、音楽データを編集する際に通常、必要とされる大量の音楽データの移動をなくすことが可能となる。ブロック単位の編集に限定すれば、同様に音楽データの移動を回避できるが、ブロック単位は、SU単位に比して編集単位が大きすぎる。
【0085】
SUは、パーツの最小単位であり、且つATRAC3でオーディオデータを圧縮する時の最小のデータ単位である。44.1kHzのサンプリング周波数で得られた1024サンプル分(1024×16ビット×2チャンネル)のオーディオデータを約1/10に圧縮した数百バイトのデータがSUである。1SUは、時間に換算して約23m秒になる。通常は、数千に及ぶSUによって1つのパーツが構成される。1クラスタが42個のSUで構成される場合、1クラスタで約1秒の音を表すことができる。1つのトラックを構成するパーツの数は、付加情報サイズに影響される。パーツ数は、1ブロックの中からヘッダや曲名、付加情報データ等を除いた数で決まるために、付加情報が全く無い状態が最大数(645個)のパーツを使用できる条件となる。
【0086】
図10Aは、CD等からのオーディオデータを2曲連続して記録する場合のファイル構成を示す。1曲目(ファイル1)が例えば5クラスタで構成される。1曲目と2曲目(ファイル2)の曲間では、1クラスタに二つのファイルが混在することが許されないので、次のクラスタの最初からファイル2が作成される。従って、ファイル1に対応するパーツ1の終端(1曲目の終端)がクラスタの途中に位置し、クラスタの残りの部分には、データが存在しない。第2曲目(ファイル2)も同様に1パーツで構成される。ファイル1の場合では、パーツサイズが5、開始クラスタのSUが0、終了クラスタが4となる。
【0087】
編集操作として、デバイド、コンバイン、イレーズ、ムーブの4種類の操作が規定される。デバイドは、1つのトラックを2つに分割することである。デバイドがされると、総トラック数が1つ増加する。デバイドは、一つのファイルをファイルシステム上で分割して2つのファイルとし、再生管理ファイルおよびFATを更新する。コンバインは、2つのトラックを1つに統合することである。コンバインされると、総トラック数が1つ減少する。コンバインは、2つのファイルをファイルシステム上で統合して1つのファイルにし、再生管理ファイルおよびFATを更新する。イレーズは、トラックを消去することである。消された以降のトラック番号が1つ減少する。ムーブは、トラック順番を変えることである。以上イレーズおよびムーブ処理についても、再生管理ファイルおよびFATを更新する。
【0088】
図10Aに示す二つの曲(ファイル1およびファイル2)をコンバインした結果を図10Bに示す。コンバインされた結果は、1つのファイルであり、このファイルは、二つのパーツからなる。また、図10Cは、一つの曲(ファイル1)をクラスタ2の途中でデバイドした結果を示す。デバイドによって、クラスタ0、1およびクラスタ2の前側からなるファイル1と、クラスタ2の後側とクラスタ3および4とからなるファイル2とが発生する。
【0089】
上述したように、この一実施形態では、パーツに関する記述方法があるので、コンバインした結果である図10Bにおいて、パーツ1の開始位置、パーツ1の終了位置、パーツ2の開始位置、パーツ2の終了位置をそれぞれSU単位でもって規定できる。その結果、コンバインした結果のつなぎ目の隙間をつめるために、パーツ2の音楽データを移動する必要がない。また、パーツに関する記述方法があるので、デバイドした結果である図10Cにおいて、ファイル2の先頭の空きを詰めるように、データを移動する必要がない。
【0090】
図11は、再生管理ファイルPBLISTのより詳細なデータ構成を示し、図12Aおよび図12Bは、再生管理ファイルPBLISTを構成するヘッダとそれ以外の部分をそれぞれ示す。再生管理ファイルPBLISTは、1クラスタ(1ブロック=16KB)のサイズである。図12Aに示すヘッダは、32バイトから成る。図12Bに示すヘッダ以外の部分は、メモリカード全体に対する名前NM1−S(256バイト)、名前NM2−S(512バイト)、CONTENTSKEY、MAC、S−YMDhmsと、再生順番を管理するテーブルTRKTBL(800バイト)、メモリカード全体に対する付加情報INF−S(14720バイト)および最後にヘッダ中の情報の一部が再度記録されている。これらの異なる種類のデータ群のそれぞれの先頭は、再生管理ファイル内で所定の位置となるように規定されている。
【0091】
再生管理ファイルは、図12Aに示す(0x0000)および(0x0010)で表される先頭から32バイトがヘッダである。なお、ファイル中で先頭から16バイト単位で区切られた単位をスロットと称する。ファイルの第1および第2のスロットに配されるヘッダには、下記の意味、機能、値を持つデータが先頭から順に配される。なお、Reservedと表記されているデータは、未定義のデータを表している。通常ヌル(0x00)が書かれるが、何が書かれていてもReservedのデータが無視される。将来のバージョンでは、変更がありうる。また、この部分への書き込みは禁止する。Optionと書かれた部分も使用しない場合は、全てReservedと同じ扱いとされる。
【0092】
BLKID−TL0(4バイト)
意味:BLOCKID FILE ID
機能:再生管理ファイルの先頭であることを識別するための値
値:固定値=”TL=0”(例えば0x544C2D30)
MCode(2バイト)
意味:MAKER CODE
機能:記録した機器の、メーカー、モデルを識別するコード
値:上位10ビット(メーカーコード) 下位6ビット(機種コード)
REVISION(4バイト)
意味:PBLISTの書き換え回数
機能:再生管理ファイルを書き換える度にインクリメント
値:0より始まり+1づつ増加する
S−YMDhms(4バイト)(Option)
意味:信頼できる時計を持つ機器で記録した年・月・日・時・分・秒
機能:最終記録日時を識別するための値
値: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秒単位)。
【0093】
SN1C+L(2バイト)
意味:NM1−S領域に書かれるメモリカードの名前(1バイト)の属性を表す
機能:使用する文字コードと言語コードを各1バイトで表す
値:文字コード(C)は上位1バイトで下記のように文字を区別する
00: 文字コードは設定しない。単なる2進数として扱うこと
01: ASCII(American Standard Code for Information Interchange)
02:ASCII+KANA 03:modifided8859-1
81:MS-JIS 82:KS C 5601-1989 83:GB(Great Britain)2312-80
90:S-JIS(Japanese Industrial Standards)(for Voice)。
【0094】
言語コード(L)は下位1バイトで下記のようにEBU Tech 3258 規定に準じて言語を区別する
00: 設定しない 08:German 09:English 0A:Spanish
0F:French 15:Italian 1D:Dutch
65:Korean 69:Japanese 75:Chinese
データが無い場合オールゼロとすること。
【0095】
SN2C+L(2バイト)
意味:NM2−S領域に書かれるメモリカードの名前(2バイト)の属性を表す
機能:使用する文字コードと言語コードを各1バイトで表す
値:上述したSN1C+Lと同一
SINFSIZE(2バイト)
意味:INF−S領域に書かれるメモリカード全体に関する付加情報の全てを合計したサイズを表す
機能:データサイズを16バイト単位の大きさで記述、無い場合は必ずオール
ゼロとすること
値:サイズは0x0001から0x39C(924)
T−TRK(2バイト)
意味:TOTAL TRACK NUMBER
機能:総トラック数
値:1から0x0190(最大400トラック)、データが無い場合はオールゼロとすること
VerNo(2バイト)
意味:フォーマットのバージョン番号
機能:上位がメジャーバージョン番号、下位がマイナーバージョン番号
【0096】
上述したヘッダに続く領域に書かれるデータ(図13B)について以下に説明する。
【0097】
NM1−S
意味:メモリカード全体に関する1バイトの名前
機能:1バイトの文字コードで表した可変長の名前データ(最大で256)
名前データの終了は、必ず終端コード(0x00)を書き込むこと
サイズはこの終端コードから計算すること、データの無い場合は少なくとも先頭(0x0020)からヌル(0x00)を1バイト以上記録すること
値:各種文字コード
NM2−S
意味:メモリカード全体に関する2バイトの名前
機能:2バイトの文字コードで表した可変長の名前データ(最大で512)
名前データの終了は、必ず終端コード(0x00)を書き込むこと
サイズはこの終端コードから計算すること、データの無い場合は少なくとも先頭(0x0120)からヌル(0x00)を2バイト以上記録すること
値:各種文字コード。
【0098】
CONTENTS KEY
意味:曲ごとに用意された値でMG(M)で保護されてから保存される。ここでは、1曲目に付けられるCONTENTS KEYと同じ値
機能:S−YMDhmsのMACの計算に必要となる鍵となる
値:0から0xFFFFFFFFFFFFFFFFまで
MAC
意味:著作権情報改ざんチェック値
機能:S−YMDhmsの内容とCONTENTS KEYから作成される値
値:0から0xFFFFFFFFFFFFFFFFまで。
【0099】
TRK−nnn
意味:再生するATRAC3データファイルのSQN(シーケンス)番号
機能:TRKINFの中のFNoを記述する
値:1から400(0x190)
トラックが存在しない時はオールゼロとすること
INF−S
意味:メモリカード全体に関する付加情報データ(例えば写真、歌詞、解説等の情報)
機能:ヘッダを伴った可変長の付加情報データ
複数の異なる付加情報が並べられることがある。それぞれにIDとデータサイズが付けられている。個々のヘッダを含む付加情報データは最小16バイト以上で4バイトの整数倍の単位で構成される。その詳細については、後述する
値:付加情報データ構成を参照
S−YMDhms(4バイト)(Option)
意味:信頼できる時計を持つ機器で記録した年・月・日・時・分・秒
機能:最終記録日時を識別するための値、EMDの時は必須
【0100】
再生管理ファイルの最後のスロットとして、ヘッダ内のものと同一のBLKID−TL0と、MCodeと、REVISIONとが書かれる。
【0101】
民生用オーディオ機器として、メモリカードが記録中に抜かれたり、電源が切れることがあり、復活した時にこれらの異常の発生を検出することが必要とされる。上述したように、REVISIONをブロックの先頭と末尾に書き込み、この値を書き換える度に+1インクリメントするようにしている。若し、ブロックの途中で異常終了が発生すると、先頭と末尾のREVISIONの値が一致せず、異常終了を検出することができる。REVISIONが2個存在するので、高い確率で異常終了を検出することができる。異常終了の検出時には、エラーメッセージの表示等の警告が発生する。
【0102】
また、1ブロック(16KB)の先頭部分に固定値BLKID−TL0を挿入しているので、FATが壊れた場合の修復の目安に固定値を使用できる。すなわち、各ブロックの先頭の固定値を見れば、ファイルの種類を判別することが可能である。しかも、この固定値BLKID−TL0は、ブロックのヘッダおよびブロックの終端部分に二重に記述するので、その信頼性のチェックを行うことができる。なお、再生管理ファイルPBLISTの同一のものを二重に記録しても良い。
【0103】
ATRAC3データファイルは、トラック情報管理ファイルと比較して、相当大きなデータ量であり、ATRAC3データファイルに関しては、後述するように、ブロック番号BLOCK SERIALが付けられている。但し、ATRAC3データファイルは、通常複数のファイルがメモリカード上に存在するので、CONNUM0でコンテンツの区別を付けた上で、BLOCK SERIALを付けないと、重複が発生し、FATが壊れた場合のファイルの復旧が困難となる。換言すると単一のATRAC3データファイルは、複数のBLOCKで構成されると共に、離散して配置される可能性があるので、同一ATRAC3データファイルを構成するBLOCKを判別するためにCONNUM0を用いると共に、同一ATRAC3データファイル内の昇降順をブロック番号BLOCK SERIALで決定する。
【0104】
同様に、FATの破壊までにはいたらないが、論理を間違ってファイルとして不都合のあるような場合に、書き込んだメーカーの機種が特定できるように、メーカーコード(MCode)がブロックの先頭と末尾に記録されている。
【0105】
図12Cは、付加情報データの構成を示す。付加情報の先頭に下記のヘッダが書かれる。ヘッダ以降に可変長のデータが書かれる。
【0106】
INF
意味:FIELD ID
機能:付加情報データの先頭を示す固定値
値:0x69
ID
意味:付加情報キーコード
機能:付加情報の分類を示す
値:0から0xFF
SIZE
意味:個別の付加情報の大きさ
機能:データサイズは自由であるが、必ず4バイトの整数倍でなければならない。また、最小16バイト以上のこと。データの終わりより余りがでる場合はヌル(0x00)で埋めておくこと
値:16から14784(0x39C0)
MCode
意味:MAKER CODE
機能:記録した機器の、メーカー、モデルを識別するコード
値:上位10ビット(メーカーコード) 下位6ビット(機種コード)
C+L
意味:先頭から12バイト目からのデータ領域に書かれる文字の属性を表す
機能:使用する文字コードと言語コードを各1バイトで表す
値:前述のSNC+Lと同じ
DATA
意味:個別の付加情報データ
機能:可変長データで表す。実データの先頭は常に12バイト目より始まり、長さ(サイズ)は最小4バイト以上、常に4バイトの整数倍でなければならない。データの最後から余りがある場合はヌル(0x00)で埋めること
値:内容により個別に定義される。
【0107】
図13は、付加情報キーコードの値(0〜63)と、付加情報の種類の対応の一例を示す。キーコードの値(0〜31)が音楽に関する文字情報に対して割り当てられ、その(32〜63)がURL(Uniform Resource Locator)(Web関係)に対して割り当てられている。アルバムタイトル、アーティスト名、CM等の文字情報が付加情報として記録される。
【0108】
図14は、付加情報キーコードの値(64〜127)と、付加情報の種類の対応の一例を示す。キーコードの値(64〜95)がパス/その他に対して割り当てられ、その(96〜127)が制御/数値・データ関係に対して割り当てられている。例えば(ID=98)の場合では、付加情報がTOC(Table of Content)−IDとされる。TOC−IDは、CD(コンパクトディスク)のTOC情報に基づいて、最初の曲番号、最後の曲番号、その曲番号、総演奏時間、その曲演奏時間を示すものである。
【0109】
図15は、付加情報キーコードの値(128〜159)と、付加情報の種類の対応の一例を示す。キーコードの値(128〜159)が同期再生関係に対して割り当てられている。図15中のEMD(Electronic Music Distribution)は、電子音楽配信の意味である。
【0110】
図16を参照して付加情報のデータの具体例について説明する。図16Aは、図12Cと同様に、付加情報のデータ構成を示す。図16Bは、キーコードID=3とされる、付加情報がアーティスト名の例である。SIZE=0x1C(28バイト)とされ、ヘッダを含むこの付加情報のデータ長が28バイトであることが示される。また、C+Lが文字コードC=0x01とされ、言語コードL=0x09とされる。この値は、前述した規定によって、ASCIIの文字コードで、英語の言語であることを示す。そして、先頭から12バイト目から1バイトデータでもって、「SIMON&GRAFUNKEL」のアーティスト名のデータが書かれる。付加情報のサイズは、4バイトの整数倍と決められているので、1バイトの余りが(0x00)とされる。
【0111】
図16Cは、キーコードID=97とされる、付加情報がISRC(International Standard Recording Code:著作権コード) の例である。SIZE=0x14(20バイト)とされ、この付加情報のデータ長が20バイトであることが示される。また、C+LがC=0x00、L=0x00とされ、文字、言語の設定が無いこと、すなわち、データが2進数であることが示される。そして、データとして8バイトのISRCのコードが書かれる。ISRCは、著作権情報(国、所有者、録音年、シリアル番号)を示すものである。
【0112】
図16Dは、キーコードID=97とされる、付加情報が録音日時の例である。SIZE=0x10(16バイト)とされ、この付加情報のデータ長が16バイトであることが示される。また、C+LがC=0x00、L=0x00とされ、文字、言語の設定が無いことが示される。そして、データとして4バイト(32ビット)のコードが書かれ、録音日時(年、月、日、時、分、秒)が表される。
【0113】
図16Eは、キーコードID=107とされる、付加情報が再生ログの例である。SIZE=0x10(16バイト)とされ、この付加情報のデータ長が16バイトであることが示される。また、C+LがC=0x00、L=0x00とされ、文字、言語の設定が無いことが示される。そして、データとして4バイト(32ビット)のコードが書かれ、再生ログ(年、月、日、時、分、秒)が表される。再生ログ機能を持つものは、1回の再生毎に16バイトのデータを記録する。
【0114】
図17は、1SUがNバイト(例えばN=384バイト)の場合のATRAC3データファイルA3Dnnnnのデータ配列を示す。図17には、データファイルの属性ヘッダ(1ブロック)と、音楽データファイル(1ブロック)とが示されている。図17では、この2ブロック(16×2=32Kバイト)の各スロットの先頭のバイト(0x0000〜0x7FF0)が示されている。図18に分離して示すように、属性ヘッダの先頭から32バイトがヘッダであり、256バイトが曲名領域NM1(256バイト)であり、512バイトが曲名領域NM2(512バイト)である。属性ヘッダのヘッダには、下記のデータが書かれる。
【0115】
BLKID−HD0(4バイト)
意味:BLOCKID FILE ID
機能:ATRAC3データファイルの先頭であることを識別するための値
値:固定値=”HD=0”(例えば0x48442D30)
MCode(2バイト)
意味:MAKER CODE
機能:記録した機器の、メーカー、モデルを識別するコード
値:上位10ビット(メーカーコード) 下位6ビット(機種コード)
BLOCK SERIAL(4バイト)
意味:トラック毎に付けられた連続番号
機能:ブロックの先頭は0から始まり次のブロックは+1づつインクリメント編集されても値を変化させない
値:0より始まり0xFFFFFFFFまで。
【0116】
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:曲の終わりまで。
【0117】
次に曲名領域NM1およびNM2について説明する。
【0118】
NM1
意味:曲名を表す文字列
機能:1バイトの文字コードで表した可変長の曲名(最大で256)
名前データの終了は、必ず終端コード(0x00)を書き込むこと
サイズはこの終端コードから計算すること、データの無い場合は少なくとも先頭(0x0020)からヌル(0x00)を1バイト以上記録すること
値:各種文字コード
NM2
意味:曲名を表す文字列
機能:2バイトの文字コードで表した可変長の名前データ(最大で512)
名前データの終了は、必ず終端コード(0x00)を書き込むこと
サイズはこの終端コードから計算すること、データの無い場合は少なくとも先頭(0x0120)からヌル(0x00)を2バイト以上記録すること
値:各種文字コード。
【0119】
属性ヘッダの固定位置(0x320)から始まる、80バイトのデータをトラック情報領域TRKINFと呼び、主としてセキュリティ関係、コピー制御関係の情報を一括して管理する。図19にTRKINFの部分を示す。TRKINF内のデータについて、配置順序に従って以下に説明する。
【0120】
CONTENTS KEY(8バイト)
意味:曲毎に用意された値で、メモリカードのセキュリティブロックで保護されてから保存される
機能:曲を再生する時、まず必要となる最初の鍵となる。MAC計算時に使用される
値:0から0xFFFFFFFFFFFFFFFFまで
MAC(8バイト)
意味:著作権情報改ざんチェック値
機能:コンテンツ累積番号を含む複数のTRKINFの内容と隠しシーケンス番号から作成される値
隠しシーケンス番号とは、メモリカードの隠し領域に記録されているシーケンス番号のことである。著作権対応でないレコーダは、隠し領域を読むことができない。また、著作権対応の専用のレコーダ、またはメモリカードを読むことを可能とするアプリケーションを搭載したパーソナルコンピュータは、隠し領域をアクセスすることができる。
【0121】
A(1バイト)
意味:パーツの属性
機能:パーツ内の圧縮モード等の情報を示す
値:図20を参照して以下に説明する
ただし、N=0,1のモノラルは、bit7が1でサブ信号を0、メイン信号(L+R)のみの特別なJointモードをモノラルとして規定する。bit2,1の情報は通常の再生機は無視しても構わない。
【0122】
Aのビット0は、エンファシスのオン/オフの情報を形成し、ビット1は、再生SKIPか、通常再生かの情報を形成し、ビット2は、データ区分、例えばオーディオデータか、FAX等の他のデータかの情報を形成する。ビット3は、未定義である。ビット4、5、6を組み合わせることによって、図示のように、ATRAC3のモード情報が規定される。すなわち、Nは、この3ビットで表されるモードの値であり、モノ(N=0,1)、LP(N=2)、SP(N=4)、EX(N=5)、HQ(N=7)の5種類のモードについて、記録時間(64MBのメモリカードの場合)、データ転送レート、1ブロック内のSU数がそれぞれ示されている。1SUのバイト数は、(モノ:136バイト、LP:192バイト、SP:304バイト、EX:384バイト、HQ:512バイト)である。さらに、ビット7によって、ATRAC3のモード(0:Dual 1:J0int )が示される。
【0123】
一例として、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
となる。
【0124】
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億曲分用意されており、記録した曲の識別に使用する
値:0から0xFFFFFFFF。
【0125】
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の場合は再生を禁止すること。
【0126】
CC(1バイト)
意味:COPY CONTROL
機能:コピー制御
値:図21に示すように、ビット6および7によってコピー制御情報を表し、ビット4および5によって高速ディジタルコピーに関するコピー制御情報を表し、ビット2および3によってセキュリティブロック認証レベルを表す。ビット0および1は、未定義
CCの例:(bit7,6)11:無制限のコピーを許可、01:コピー禁止、00:1回のコピーを許可
(bit3,2)00:アナログないしディジタルインからの録音、MG認証レベルは0とする
CDからのディジタル録音では(bit7,6)は00、(bit3,2)は00となる
CN(1バイト)(Option)
意味:高速ディジタルコピーHSCMS(High speed Serial Copy Management System)におけるコピー許可回数
機能:コピー1回か、コピーフリーかの区別を拡張し、回数で指定する。コピー第1世代の場合にのみ有効であり、コピーごとに減算する
値:00:コピー禁止、01から0xFE:回数、0xFF:回数無制限。
【0127】
上述したトラック情報領域TRKINFに続いて、0x0370から始まる24バイトのデータをパーツ管理用のパーツ情報領域PRTINFと呼び、1つのトラックを複数のパーツで構成する場合に、時間軸の順番にPRTINFを並べていく。図22にPRTINFの部分を示す。PRTINF内のデータについて、配置順序に従って以下に説明する。
【0128】
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の役割
値:コンテンツ累積番号初期値キーと同じ値とされる。
【0129】
ATRAC3データファイルの属性ヘッダ中には、図17に示すように、付加情報INFが含まれる。この付加情報は、開始位置が固定化されていない点を除いて、再生管理ファイル中の付加情報INF−S(図11および図12B参照)と同一である。1つまたは複数のパーツの最後のバイト部分(4バイト単位)の次を開始位置として付加情報INFのデータが開始する。
【0130】
INF
意味:トラックに関する付加情報データ
機能:ヘッダを伴った可変長の付加情報データ。複数の異なる付加情報が並べられることがある。それぞれにIDとデータサイズが付加されている。個々のヘッダを含む付加情報データは、最小16バイト以上で4バイトの整数倍の単位
値:再生管理ファイル中の付加情報INF−Sと同じである。
【0131】
上述した属性ヘッダに対して、ATRAC3データファイルの各ブロックのデータが続く。図23に示すように、ブロック毎にヘッダが付加される。各ブロックのデータについて以下に説明する。
【0132】
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のデータ値。
【0133】
図17では、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が二重に記録される。
【0134】
ここで、上述したFAT領域が壊れた場合には、フラッシュメモリの全ブロックの探索を開始し、ブロック先頭部のブロックID BLKIDがTL0か、HD0か、A3Dかを各ブロックについて判別する。この処理を図24に示すフローチャートを参照して、説明する。ブロック先頭のブロックID BLKIDがBLKID−TL0であるか否かをステップSP1で判別する。
【0135】
このステップSP1において、ブロック先頭のブロックID BLKIDがBLKID−TL0で無い場合には、ステップSP2において、ブロック番号をインクリメント処理して、ステップSP3において、ブロックの終端部まで検索したかを判別する。ステップSP3において、ブロックの終端部まで至ってないと判別された場合には、再度ステップSP1に戻る。
【0136】
そして、ステップSP1において、ブロック先頭のブロックID BLKIDがBLKID−TL0と判別された場合には、ステップSP4において、検索したブロックが再生管理ファイルPBLISTであると判定される。次に、ステップSP5において、再生管理ファイルPBLIST内に含まれる総トラック数T−TRKを参照して、レジスタにNとして記憶する。一例として、メモリ上に10曲のATRAC3データファイルが存在する場合には(すなわち10ファイル)T−TRKには10が記録されている。
【0137】
次に、ステップSP6において、総トラック数T−TRKに基づいてブロック内に記録されているTRK−001からTRK−400を順次参照する。上述した一例の場合には、メモリ内に10曲収録されているのでTRK−001からTRK−010までを参照すればよい。
【0138】
ステップSP7において、TRK−XXX(XXX=001〜400)には、対応するファイル番号FNOが記録されているので、トラック番号TRK−XXXとファイル番号FNOの対応表をメモリに記憶する。
【0139】
ステップSP8において、レジスタに記憶したNをデクリメント処理して、ステップSP9において、N=0になるまでステップSP6、SP7およびSP8を繰り返す。ステップSP9において、N=0と判断されたらステップSP10において、先頭のブロックにポインタをリセットして、先頭のブロックから探索をやり直す。
【0140】
次に、ステップSP11において、ブロック先頭のブロックID BLKIDがBLKID−HD0か否かを判別する。このステップSP11において、ブロック先頭のブロックID BLKIDがBLKID−HD0で無い場合には、ステップSP12において、ブロック番号をインクリメント処理して、ステップSP13において、ブロックの終端部まで検索したか否かを判別する。
【0141】
そして、ステップSP13において、ブロックの終端部まで至ってないと判別された場合には、再度ステップSP11に制御が戻る。
【0142】
ステップSP11において、ブロック先頭のブロックID BLKIDがBLKID−HD0であると判断されるまで、先頭ブロックからの探索を開始する。ステップSP11において、ブロック先頭のブロックID BLKIDがBLKID−HD0と判断された場合には、ステップSP14において、そのブロックは、図18の0x0000〜0x03FFF に示すATRAC3データファイルの先頭部分の属性ヘッダ(図8参照)と判断される。
【0143】
次に、ステップSP15において、属性ヘッダ内に記録されているファイル番号FNO、同一ATRAC3データファイル内での通し番号を表すBLOCKSERIAL、コンテンツ累積番号キーCONNUM0を参照して、メモリに記憶する。ここで、10個のATRAC3データファイルが存在する(すなわち、10曲収録されている)場合には、先頭のブロックID BLKIDがBLKID−TL0と判断されるブロックが10個存在するので、10個索出されるまで処理を続ける。
【0144】
ステップSP13において、ブロックの終端部まで至っていると判別された場合には、ステップSP16において、先頭のブロックにポインタをリセットして、先頭のブロックから探索をやり直す。
【0145】
次に、ステップSP17において、ブロック先頭のブロックID BLKIDがBLKID−A3Dか否かを判断する。このステップSP17において、ブロック先頭のブロックID BLKIDがBLKID−A3Dで無い場合には、ステップSP18において、ブロック番号をインクリメント処理して、ステップSP19において、ブロックの終端部まで検索したか否かを判別する。ステップSP19において、ブロックの終端部まで至ってないと判別された場合には、再度ステップSP17に制御が戻る。
【0146】
そして、ステップSP17において、ブロック先頭のブロックID BLKIDがBLKID−A3Dであると判断された場合には、ステップSP20において、ブロックはATRAC3データファイルが実際に記録されているブロックと判断される。
【0147】
次に、ステップSP21において、ATRAC3データブロック内に記録されている通し番号BLOCK SERIAL、コンテンツ累積番号キーCONNUM0を参照して、メモリに記憶する。このコンテンツ累積番号キーCONNUM0は同一ATRAC3データファイル内では共通の番号が付与されている。即ち1つのATRAC3データファイルが10個のブロックから構成されている場合には、ブロック内に各々記録されているCONNUM0には全部共通の番号が記録されている。
【0148】
さらに、1つのATRAC3データファイルが10個のブロックから構成されている場合には、10個のブロックの各々のBLOCK SERIALには1〜10のいずれかの通し番号が付与されている。CONNUM0およびBLOCKSERIALに基づいて同一コンテンツを構成するブロックか、さらに同一コンテンツ内の再生順序(連結順序)が判る。
【0149】
この実施形態では、10個のATRAC3データファイル(即ち10曲)が記録され、例えば各々のATRAC3データファイルが10個のブロックから構成される場合には、100個のデータブロックが存在することになる。この100個のデータファイルがどの曲番を構成し、どの順序で連結されるべきかはCONNUM0およびBLOCK SERIALを参照して行われる。
【0150】
ステップSP19において、ブロックの終端部まで至っていると判別された場合には、全ブロックに対して、再生管理ファイル、ATRAC3データファイル、属性ファイルの全ての検索が終了したことを意味するので、ステップSP22は、メモリ上に記憶されたブロック番号に対応するCONNUM0、BLOCKSERIAL、FNO、TRK−XXXに基づいてファイルの連結状態を再現する。連結状態が確認できたらメモリ上の破壊されていない空きエリアにFATを作成し直しても良い。
【0151】
次に、上述した管理ファイルと異なるデータ構成の管理ファイル他の例について、説明する。図25は、メモリカード40のファイル構成の他の例を全体として示す。音楽用ディレクトリには、トラック情報管理ファイルTRKLIST.MSF(以下、単にTRKLISTと表記する)と、トラック情報管理ファイルのバックアップTRKLISTB.MSF(以下、単にTRKLISTBと表記する)と、アーチスト名、ISRCコード、タイムスタンプ、静止画像データ等の各種付加情報データを記述するINFLIST.MSF(以下、単にINFISTと表記する)と、ATRAC3データファイルA3Dnnnn.MSA(以下、単にA3Dnnnnと表記する)とが含まれる。TRKLISTには、NAME1およびNAME2が含まれる。NAME1は、メモリカード名、曲名ブロック(1バイトコード用)で、ASCII/8859−1の文字コードにより曲名データを記述する領域である。NAME2は、メモリカード名、曲名ブロック(2バイトコード用)で、MS−JIS/ハングル語/中国語等により曲名データを記述する領域である。
【0152】
図26は、音楽用ディレクトリのトラック情報管理ファイルTRKLISTと、NAME1および2と、ATRAC3データファイルA3Dnnnn間の関係を示す。TRKLISTは、全体で64Kバイト(=16K×4)の固定長で、その内の32Kバイトがトラックを管理するパラメータを記述するのに使用され、残りの32KバイトがNAME1および2を記述するのに使用される。曲名等を記述したファイルNAME1および2は、トラック情報管理ファイルと別扱いでも実現できるが、RAM容量の小さいシステムは、トラック情報管理ファイルと曲名ファイルとを分けない方が管理ファイルをまとめて管理することができ、操作しやすくなる。
【0153】
トラック情報管理ファイルTRKLIST内のトラック情報領域TRKINF−nnnnおよびパーツ情報領域PRTINF−nnnnによって、データファイルA3Dnnnnおよび付加情報用のINFLISTが管理される。なお、暗号化の処理を受けるのは、ATRAC3データファイルA3Dnnnnのみである。図26中で、横方向が16バイト(0〜F)であり、縦方向に16進数(0xか16進数を意味する)でその行の先頭の値が示されている。
【0154】
他の例では、トラック情報管理ファイルTRKLIST(曲名ファイルを含む)と、付加情報管理ファイルINFLISTと、データファイルA3Dnnnnとの3個のファイルの構成とされ、TRKLISTによってINFLISTおよびA3Dnnnnが管理される。前述したデータ構成の一例(図7、図8および図9)では、メモリカードの全体を管理する再生管理ファイルPBLISTと、各トラック(曲)のデータファイルATRAC3との2種類のファイルの構成とされる。
【0155】
以下、データ構成の他の例について説明するが、上述したデータ構成の一例と同一の点については、その説明を省略することにする。
【0156】
図27は、トラック情報管理ファイルTRKLISTのより詳細な構成を示す。トラック情報管理ファイルTRKLISTは、1クラスタ(1ブロック)=16KBのサイズで、その後に続くバックアップ用のTRKLISTBも同一サイズ、同一データのものである。トラック情報管理ファイルは、先頭から32バイトがヘッダである。ヘッダには、上述した再生管理ファイルPBLIST中のヘッダと同様に、BLKID−TL0/TL1(バックアップファイルのID)(4バイト)、総トラック数T−TRK(2バイト)、メーカーコードMCode(2バイト)、TRKLISTの書き換え回数REVISION(4バイト)、更新日時のデータS−YMDhms(4バイト)(Option)が書かれる。これらのデータの意味、機能、値は、前述した通りである。これらのデータ以外に下記のデータが書かれる。
【0157】
YMDhms(4バイト)
最後にTRKLISTが更新された年月日
N1(1バイト)(Option)
メモリカードの連番号(分子側)で、1枚使用時はすべて(0x01)
N2(1バイト)(Option)
メモリカードの連番号(分母側)で、1枚使用時はすべて(0x01)
MSID(2バイト)(Option)
メモリカードのIDで、複数組の時は、MSIDが同一番号(T.B.D.)
(T.B.D.は、将来定義されうることを意味する)
S−TRK(2バイト)
特別トラック(401〜408)の記述(T.B.D.)で、通常は、0x0000
PASS(2バイト)(Option)
パスワード(T.B.D.)
APP(2バイト)(Option)
再生アプリケーションの規定(T.B.D.)(通常は、0x0000)
INF−S(2バイト)(Option)
メモリカード全体の付加情報ポインタであり、付加情報がないときは、0x00とする。
【0158】
TRKLISTの最後の16バイトとして、ヘッダ内のものと同一のBLKID−TL0と、MCodeと、REVISIONとが配される。また、バックアップ用のTRKLISTBにも上述したヘッダが書かれる。この場合、BLKID−TL1と、MCodeと、REVISIONとが配される。
【0159】
ヘッダの後にトラック(曲)ごとの情報を記述するトラック情報領域TRKINFと、トラック(曲)内のパーツの情報を記述するパーツ情報領域PRTINFが配置される。図27では、TRKLISTの部分に、これらの領域が全体的に示され、下側のTRKLISTBの部分にこれらの領域の詳細な構成が示されている。また、斜線で示す領域は、未使用の領域を表す。
【0160】
トラック情報領域TRKINF−nnnおよびパーツ情報領域PRTINF−nnnに、上述したATRAC3データファイルに含まれるデータが同様に書かれる。すなわち、再生制限フラグLT(1バイト)、コンテンツキーCONTENTS KEY(8バイト)、記録機器のセキュリティブロックのシリアル番号MG(D)SERIAL(16バイト)、曲の特徴的部分を示すためのXT(2バイト)(Option)およびINX(2バイト)(Option)、再生制限情報およびコピー制御に関連するデータYMDhms−S(4バイト)(Option)、YMDhms−E(4バイト)(Option)、MT(1バイト)(Option)、CT(1バイト)(Option)、CC(1バイト)、CN(1バイト)(Option)、パーツの属性を示すA(1バイト)、パーツサイズPRTSIZE(4バイト)、パーツキーPRTKEY(8バイト)、コンテンツ累積番号CONNUM(4バイト)が書かれている。これらのデータの意味、機能、値は、前述した通りである。これらのデータ以外に下記のデータが書かれる。
【0161】
T0(1バイト)
固定値(T0=0x74)
INF−nnn(Option)(2バイト)
各トラックの付加情報ポインタ(0〜409)、00:付加情報がない曲の意味
FNM−nnn(4バイト)
ATRAC3データのファイル番号(0x0000〜0xFFFF)
ATRAC3データファイル名(A3Dnnnnn)のnnnnn (ASCII)番号を0xnnnnnに変換した値
APP CTL(4バイト)(Option)
アプリケーション用パラメータ(T.B.D.)(通常、0x0000)
P−nnn(2バイト)
曲を構成するパーツ数(1〜2039)で、前述のT−PARTに対応する
PR(1バイト)
固定値(PR=0x50)。
【0162】
次に、名前をまとめて管理する名前の領域NAME1およびNAME2について説明する。図28は、NAME1(1バイトコードを使用する領域)のより詳細なデータ構成を示す。NAME1および後述のNAME2は、ファイルの先頭から8バイト単位で区切られ、1スロット=8バイトとされている。先頭の0x8000には、ヘッダが書かれ、その後ろにポインタおよび名前が記述される。NAME1の最後のスロットにヘッダと同一データが記述される。
【0163】
BLKID−NM1(4バイト)
ブロックの内容を特定する固定値(NM1=0x4E4D2D31)
PNM1−nnn(4バイト)(Option)
NM1(1バイトコード)へのポインタ
PNM1−Sは、メモリカードを代表する名前のポインタ
nnn(=1〜408)は、曲名のポインタ
ポインタは、ブロック内の開始位置(2バイト)と文字コードタイプ(2ビット)とデータサイズ(14ビット)を記述
NM1−nnn(Option)
1バイトコードで、メモリカード名、曲名データを可変長で記述
名前データの終端コード(0x00)を書き込む。
【0164】
図29は、NAME2(2バイトコードを使用する領域)のより詳細なデータ構成を示す。先頭(0x8000)には、ヘッダが書かれ、ヘッダの後ろにポインタおよび名前が記述される。NAME2の最後のスロットにヘッダと同一データが記述される。
【0165】
BLKID−NM2(4バイト)
ブロックの内容を特定する固定値(NM2=0x4E4D2D32)
PNM2−nnn(4バイト)(Option)
NM2(2バイトコード)へのポインタ
PNM2−Sは、メモリカードを代表する名前のポインタ
nnn(=1〜408)は、曲名のポインタ
ポインタは、ブロック内の開始位置(2バイト)と文字コードタイプ(2ビット)とデータサイズ(14ビット)を記述
NM2−nnn(Option)
2バイトコードで、メモリカード名、曲名データを可変長で記述
名前データの終端コード(0x0000)を書き込む。
【0166】
図30は、1SUがNバイトの場合のATRAC3データファイルA3Dnnnnのデータ配列(1ブロック分)を示す。このファイルは、1スロット=8バイトである。図30では、各スロットの先頭(0x0000〜0x3FF8)の値が示されている。ファイルの先頭から4個のスロットがヘッダである。前述したデータ構成の一例におけるデータファイル(図17参照)の属性ヘッダに続くデータブロックと同様に、ヘッダが設けられる。すなわち、このヘッダには、BLKID−A3D(4バイト)、メーカーコードMCode(2バイト)、暗号化に必要なBLOCK SEED(8バイト)、最初に作られたコンテンツ累積番号CONNUM0(4バイト)、トラック毎の連続番号BLOCK SERIAL(4バイト)、暗号化/復号化に必要なINITIALIZATION VECTOR(8バイト)が書かれる。なお、ブロックの最後の一つ前のスロットに、BLOCK SEEDが二重記録され、最後のスロットにBLKID−A3DおよびMCodeが記録される。そして、前述したデータ構成の一例と同様に、ヘッダの後にサウンドユニットデータSU−nnnnが順に配される。
【0167】
図31は、付加情報を記述するための付加情報管理ファイルINFLISTのより詳細なデータ構成を示す。他のデータ構成においては、このファイルINFLISTの先頭(0x0000)には、下記のヘッダが記述される。ヘッダ以降にポインタおよびデータが記述される。
【0168】
BLKID−INF(4バイト)
ブロックの内容を特定する固定値(INF=0x494E464F)
T−DAT(2バイト)
総データ数を記述(0〜409)
MCode(2バイト)
記録した機器のメーカーコード
YMDhms(4バイト)
記録更新日時
INF−nnn(4バイト)
付加情報のDATA(可変長、2バイト(スロット)単位)へのポインタ
開始位置は、上位16ビットで示す(0000〜FFFF)
DataSlot−0000の(0x0800)先頭からのオフセット値(スロット単位)を示す
データサイズは、下位16ビットで示す(0001〜7FFF)(最上位ビットMSBに無効フラグをセットする。MSB=0(有効を示す)、MSB=1(無効を示す)
データサイズは、その曲のもつ総データ数を表す
(データは、各スロットの先頭から始まり、データの終了後は、スロットの終わりまで00を書き込むこと)
最初のINFは、アルバム全体の持つ付加情報を示すポインタ(通常INF−409で示される)。
【0169】
図32は、付加情報データの構成を示す。一つの付加情報データの先頭に8バイトのヘッダが付加される。この付加情報の構成は、上述したデータ構成の一例における付加情報の構成(図12C参照)と同様のものである。すなわち、IDとしてのIN(1バイト)、キーコードID(1バイト)、個々の付加情報の大きさを示すSIZE(2バイト)、メーカーコードMCode(2バイト)が書かれる。さらに、SID(1バイト)は、サブIDである。
【0170】
上述したこの発明の一実施形態では、メモリカードのフォーマットとして規定されているファイルシステムとは別に音楽用データに対するトラック情報管理ファイルTRKLISTを使用するので、FATが何らかの事故で壊れても、ファイルを修復することが可能となる。図33は、ファイル修復処理の流れを示す。ファイル修復のためには、ファイル修復プログラムで動作し、メモリカードをアクセスできるコンピュータ(DSP30と同様の機能を有するもの)と、コンピュータに接続された記憶装置(ハードディスク、RAM等)とが使用される。最初のステップ101では、次の処理がなされる。なお、図25〜図32を参照して説明したトラック管理ファイルTRKLISTに基づいてファイルを修復する処理を説明する。
【0171】
FATが壊れたフラッシュメモリの全ブロックを探索し、ブロックの先頭の値(BLKID)がTL−0を探す。このフラッシュメモリの全ブロックを探索し、ブロックの先頭の値(BLKID)がTL−1を探す。このフラッシュメモリの全ブロックを探索し、ブロックの先頭の値(BLKID)がNM−1を探す。このフラッシュメモリの全ブロックを探索し、ブロックの先頭の値(BLKID)がNM−2を探す。この4ブロック(トラック情報管理ファイル)の全内容は、修復用コンピュータによって例えばハードディスクに収集する。
【0172】
トラック情報管理ファイルの先頭から4バイト目以降のデータから総トラック数mの値を見つけ把握しておく。トラック情報領域TRKINF−001の先頭から20バイト目、1曲目のCONNUM−001とそれに続くP−001の値を見つける。P−001の内容から構成されるパーツの総数を把握し、続くPRTINFの中のトラック1を構成する全てのPRTSIZEの値を見つけ出し、それらを合計した総ブロック(クラスタ)数nを計算し、把握しておく。
【0173】
トラック情報管理ファイルは見つかったので、ステップ102では、音のデータファイル(ATRAC3データファイル)を探索する。フラッシュメモリの管理ファイル以外の全ブロックを探索し、ATRAC3データファイルであるブロックの先頭の値(BLKID)がA3Dのブロック群の収集を開始する。
【0174】
A3Dnnnnの中で先頭から16バイト目に位置するCONNUM0の値がトラック情報管理ファイルの1曲目のCONNUM−001と同一で、20バイト目からのBLOCK SERIALの値が0のものを探し出す。これが見つかったら、次のブロック(クラスタ)として同一のCONNUM0の値で、20バイト目からのBLOCK SERIALの値が+1されたもの(1=0+1)を探し出す。これが見つかったら、同様に、次のブロック(クラスタ)として同一のCONNUM0の値で、20バイト目からのBLOCK SERIALの値が+1されたもの(2=1+1)を探し出す。
【0175】
この処理を繰り返して、トラック1の総クラスタであるn個になるまでATRAC3データファイルを探す。全てが見つかったら、探したブロック(クラスタ)の内容を全てハードディスクに順番に保存する。
【0176】
次のトラック2に関して、上述したトラック1に関する処理を行う。すなわち、CONNUM0の値がトラック情報管理ファイルの1曲目のCONNUM−002と同一で、20バイト目からのBLOCK SERIALの値が0のものを探し出し、以下、トラック1の場合と同様に、最後のブロック(クラスタ)n’までATRAC3データファイルを探し出す。全てが見つかったら、探したブロック(クラスタ)の内容を全て外部のハードディスクに順番に保存する。
【0177】
全トラック(トラック数m)について、以上の処理を繰り返すことによって、全てのATRAC3データファイルが修復用コンピュータが管理する外部のハードディスクに収集される。
【0178】
そして、ステップ103では、FATが壊れたメモリカードを再度初期化し、FATを再構築し、所定のディレクトリを作り、トラック情報管理ファイルと、mトラック分のATRAC3データファイルをハードディスク側からメモリカードへコピーする。これによって、修復作業が完了する。
【0179】
なお、管理ファイル、データファイルにおいて、重要なパラメータ(主としてヘッダ内のコード)を二重に限らず、三重以上記録しても良く、重要なパラメータに対して専用のエラー訂正符号の符号化を行うようにしても良い。また、このように多重記録する場合の位置は、ファイルの先頭および末尾の位置に限らず、1ページ単位以上離れた位置であれば有効である。
【0180】
以下、上述した実施形態および図4〜図24で説明したこの発明の第1の実施形態に示すファイル管理方法を用いて、ファイル(曲)の結合編集処理、分割編集処理に関する処理手順を示す。
【0181】
FAT上の結合編集処理
上述した図6に示すCAT.MSA、DOG.MSA、MAN.MSAという3つのファイル(曲)のうちCAT.MSAとMAN.MSAの2つのファイルを結合する際のFAT上の処理を示す。図34に示すように、ユーザによって2つのファイルを1つのファイルの結合する際にCAT.MSAに対応するFAT上のクラスタ管理データの終端のクラスタ8のエントリーアドレスを「FFF」から連結されるMAN.MSAに対応するFAT上の開始アドレス「110」に編集する。これによって連結されたCAT.MSAというファイルは、クラスタ5、6、7、8、110、111というクラスタ領域を使用していることになる。さらに、サブディレクトリ領域からMAN.MSAを削除すると共に、クラスタ202で管理されていたMAN.MSAというファイル名も削除する。
【0182】
属性ヘッダの編集
CAT.MSAとMAN.MSAの2つのファイルを結合する際のFAT上の編集手順を以上に述べたが、図11に示す再生管理ファイルPBLIST. MSFと図17に示すATRAC3データファイルの属性ヘッダの編集方法を図35を用いて説明する。図35Aに編集前のCAT.MSAとMAN.MSAの2つのファイルのメモリマップ上の模式図を示す。この模式図は、論理アドレスから物理アドレスへ変換された後のメモリマップであると共に、各パーツは本来離散的にメモリ上に記録されているが説明を簡略化するために連続的に配置してある。
【0183】
図35Aに示すようにCAT.MSAの属性ファイルには総サウンドユニット数T−SU:100、トータルパーツ数T−PRT:3、コンテンツキー、MAC、および各パーツに対応するパーツサイズとパーツキーが管理されている。さらに、MAN.MSAの属性ファイルには総サウンドユニット数T−SU:70、トータルパーツ数T−PRT:2、コンテンツキー、MACおよび各パーツに対応するパーツサイズとパーツキー、コンテンツ累積番号CONNUM0が管理されている。
【0184】
ファイルCAT.MSAに対する属性ファイルの内容を以下のように更新をする。具体的に更新する内容としては、曲を連結することで、単一ファイルを構成するパーツ数が増加するので、属性ファイルに含まれるT−PRTを編集すると共に、トータルサウンドユニット数もファイルを連結することで増加するのでT−SUも編集する。すなわち、図35Bに示すように、CAT.MSAの総サウンドユニット数T−SU:100と、MAN.MSAの総サウンドユニット数T−SU:70とを加算した値170に総サウンドユニット数T−SUは書き換えられると共に、CAT.MSAの総パーツ数T−PRT:3と、MAN.MSAの総パーツ数T−PRT:2とを加算した値5に総パーツ数T−PRTは書き換えられる。
【0185】
さらに、ATRAC3データファイル(曲)を結合処理時に属性ファイルの含まれるコンテンツキーに関しては新たに生成しなおすと共に、さらに、著作権改ざんチェック値であるMACも変更する。また、連結されるファイルMAN.MSAの属性ファイルブロックに含まれているパーツ情報(図22)をCAT.MSAに対する属性ファイルブロックに追加(複写)する。さらに、パーツ情報を追加後の属性ファイルブロックに含まれている各パーツごとのパーツキーPRTKEYを新しいコンテンツキーを用いて暗号化しなおす。
【0186】
図9にATRAC3データファイルにはヘッダ部分に属性ファイルが付加されているので、2つのATRAC3データファイルを単に結合してしまうと、ファイルCAT.MSAに対する属性ファイルブロック、ファイルCAT.MSAに対する複数のATARC3データブロック、ファイルMAN.MSAに対する属性ファイルブロック、ファイルMAN.MSAに対する複数のATARC3データブロックという順に結合されてしまい属性ファイルが1つのファイルに2つ存在するという問題点が生じる。
【0187】
そこで、この発明は、図35Bに示すように結合処理をする際に後続のファイル(この実施形態ではファイルMAN.MSA)の属性ファイルを削除して、ファイルCAT.MSAに対する属性ファイルブロック、CAT.MSAに対する複数のATARC3データブロック、ファイルMAN.MSAに対する複数のATARC3データブロックという順で並べる。
【0188】
再生管理ファイルの編集
さらに、上述した図11の再生管理ファイルPBLISTに関しても、ファイルを連結することで総トラック数がひとつ減るのでT―TRKを編集すると共に、TRK−001からTRK−400の前詰めの処理を行う。
【0189】
結合編集処理の手順
図36にファイル結合時の編集処理の手順を示す。ステップSP201にて、ユーザが結合したい2つのファイルを所定の操作で選択する。上述した実施形態の場合にはCAT.MSAとMAN.MSAという2つのファイルである。次にステップSP202にて、上述した手順でFATの連結状態を編集する。次に、ステップSP203にて、サブディレクトリから後方に連結されるファイル名を削除すると共に、ステップSP204にて、データ領域から後方に連結されるファイル名を削除する。
【0190】
ステップSP205にて、後方に連結されるATRAC3データファイルの属性ファイルに基づいて前方に位置するATRACデータファイルの更新を行う。詳細は上述したように総パーツ数T−PRTを編集すると共に、トータルサウンドユニット数T−SUの編集を行う。ステップSP206にて、後方に連結されるATRAC3データファイルの属性ファイルを削除する。ステップSP207にて、上述した再生管理ファイル中のT−TRK、TRK−XXXの編集処理を行う。
【0191】
この手順の一例では、FATの編集、属性ファイルの編集、再生管理ファイルの編集という手順で説明したが当然これらの手順は入れ替わってもよい。
【0192】
分割処理
この実施形態では、2つのファイルを結合するためのコンバイン処理に関して説明したが、1つのファイルを所定位置で分割する際の分割処理に関して以下に説明する。
【0193】
FAT上での分割編集処理
図37は、上述した図6に示した3つのファイルのうちからCAT. MSAを分割処理を説明するためのメモリマップである。CAT.MSAをクラスタ6とクラスタ7を境界に分割処理操作がユーザによって行われたとする。分割処理操作によってCAT1. MSAとCAT2. MSAという2つのファイルが作成されたとする。
【0194】
まず、以前クラスタ202に記録されているMAN.MSAをクラスタ203に移動し、同様にクラスタ201に記録されているDOG.MSAをクラスタ202に移動する。さらに、クラスタ200のファイルネームをCAT1とユーザが入力し、そのCAT1に識別子MSAを付与したCAT1.MSAをクラスタ200に記録する。同様に、分割処理されたクラスタ201のファイルネームをCAT2とユーザが入力し、そのCAT2に識別子MSAを付与したCAT2.MSAをクラスタ201に記録する。
【0195】
次に、サブディレクトリに記録されていたCAT.MSAをCAT1.MSAに書き換えると共に、未使用スロットにCAT2.MSAを追加する。追加されたCAT2.MSAが記録されているスロットには、分割されたCAT2.MSAが記録されているクラスタ番号「7」が終端に記録される。次に、サブディレクトリのCAT1.MSAスロットが指し示すFAT上の終点をクラスタ6になるように、クラスタ6のエントリーアドレスを「FFF」に書き換える。以上が分割処理時のFAT上での編集手順である。
【0196】
属性ヘッダの編集
さらに、編集されるファイルが2分割された場合には分割された後方のファイルに属性ファイルを付加するために属性ファイルの生成を行わなければならない。
【0197】
以下、図38を用いて説明を行う。上述した図35と同様に、図38は、論理アドレスから物理アドレスへ変換した後のメモリマップであると共に、各パーツは本来離散的にメモリ上に記録されているが説明を簡略化するために連続的に配置してある。
【0198】
図38Aに示すようにCAT.MSAの属性ファイルには総サウンドユニット数T−SU:170、トータルパーツ数T−PRT:5、コンテンツキー、MAC、および各パーツに対応するパーツサイズPRTSIZEとパーツキーPRTKEY、コンテンツ累積番号CONNUM0が管理されている。ファイルCAT.MSAに対してユーザが所定のポイントで分割指示を行ったとする。例えば図38Aのパーツ3とパーツ4の境界でユーザによって分割指示が行われたとする。
【0199】
属性ファイルの内容を以下のように更新をする。具体的に更新する内容としては、曲を分割することで、単一ファイルを構成するパーツ数が減少するので、属性ファイルに含まれるT−PRTを編集すると共に、トータルサウンドユニット数もファイルを分割することで減少するのでT−SUも編集する。すなわち、図38Bに示すように、分割後に前方に位置するCAT1.MSAの総サウンドユニット数がT−SU:100に書き換えられると共に、CAT1.MSAの総パーツ数がT−PRT:3に書き換えられる。さらに、分割処理に伴い、コンテンツキー、著作権改ざんチェック値MAC、および各パーツに対応するパーツキーPRTKEYを書き換える。
【0200】
さらに、分割処理された後方に位置するCAT2.MSAに対して属性ファイルを新規に作成する。新規に作成する属性ファイルに関しては、総サウンドユニット数T−SU:70、総パーツ数T−PRT:2に書き換えられる。さらに、分割処理に伴い、コンテンツキー、著作権改ざんチェック値MAC、および各パーツに対応するパーツキーPRTKEYを書き換える。
【0201】
再生管理ファイルの編集
また、分割処理時の再生管理ファイルPBLISTの編集方法を以下で説明する。分割処理時にはファイル数が2分割の場合には1つ増加するのでトラック総数を表すT−TRKを1増加させる。さらに、分割処理された曲以降の曲番号をシフトするためにTRK−XXX(XXX:001から400の整数)のテーブルの編集も行う。
【0202】
分割処理の手順
図39に分割処理時の手順を示す。ユーザは、ステップSP301で分割処理をしたいファイルを選択してファイルの演奏を行いながら分割ポイントを所定の操作を行い選択する。次に、ステップSP302にて、FAT上の連結状態を上述のように編集処理する。さらに、ステップSP303にて、Sub Directoryから分割処理されたデータファイルの後方に位置するデータファイルのファイル名を追加する。
【0203】
さらに、ステップSP304にて、データ領域に分割処理されたデータファイルの後方に位置するデータファイルのファイル名を追加する。ファイル名はユーザによって操作キーにて入力された名前である。続いて、ステップSP305にて、分割ポイントの前方に位置するデ−タファイルの属性ファイルを編集すると共に、ステップSP306にて、分割点を基準に後続するデータファイルに付加する属性ファイルも生成する。新規属性ファイルの作成の仕方および分割処理されたファイルの分割ポイントに基づいて属性ファイルの編集は上述した通りである。次に、ステップSP307にて、再生管理ファイルPBLSITの編集を行う。
【0204】
この手順の一例では、FATの編集、属性ファイルの編集、再生管理ファイルの編集という手順で説明したが当然これらの手順は入れ替わってもよい。
【0205】
この発明は、メモリカードに記録されているデータファイル(ATRAC3ファイル)の編集操作ができるものである。以下、図25〜図32を参照して説明したトラック管理ファイルTRKLISTに基づいて編集操作、例えばコンバイン、デバイドに関連する部分をより詳細に説明する。ただし、以下の説明は、ATRAC3データファイルの属性ヘッダ中のトラック情報領域TRKINFおよびパーツ情報領域PRTINFに関連する部分を使用しても同様に適用することができる。
【0206】
ここで、それぞれ1つのパーツから構成される2つのトラックAおよびBを1つにするコンバイン(図10B参照)について、図40に示すフローチャートを用いて説明する。ステップSP401では、連結される後続のトラックBのパーツ情報領域PRTINF1個を、トラックAのパーツ情報領域PRTINFの下に移動させる。その結果、トラック情報管理ファイルTRKLISTでは、トラックAのトラック情報領域TRKINF、トラックAのパーツ情報領域PRTINF、トラックBのパーツ情報領域PRTINF、トラックBのトラック情報領域TRKINFの順に並べられる。
【0207】
ステップSP402では、トラックBのATRAC3データファイルのFATのチェーンをトラックAのATRAC3データファイルのFATのチェーンの後ろに接続させる。ステップSP403では、トラックBのトラック情報領域TRKINFがトラック情報管理ファイルTRKLISTから削除される。よって、トラックAのトラック情報領域TRKINF、トラックAのパーツ情報領域PRTINF、トラックBのパーツ情報領域PRTINFの順に並べられる。ステップSP404では、トラックBの音のファイルがディレクトリから削除される。ステップSP405では、トラックAのトラック情報領域TRKINFの曲を構成するパーツ数を示すP−nnnが1から1+1=2へ変更される。
【0208】
そして、これに伴いキーの値も変更される。元のトラックAのコンテンツキーをKC_Aとし、元のトラックBのコンテンツキーをKC_Bとする。同じく元のトラックAのパーツキーをKP_Aとし、元のトラックBのパーツキーをKP_Bとする。
【0209】
ステップSP406では、コンバインの後、新たにできたトラックNのコンテンツキーがKC_Nとして生成され、CONNUMも同時に新規に生成される。ステップSP407では、新しいパーツキーが生成される。新しいパーツキーは、KC_AとKP_AとKC_Nとの排他的論理和(XOR)によって生成される。ステップSP408では、後ろのパーツキー、すなわち元のトラックBのパーツ情報領域PRTINF用のパーツキーが生成される。この後ろのパーツキーは、新しいパーツキーと同様に、KC_BとKP_BとKC_Nとの排他的論理和(XOR)によって生成される。
【0210】
ステップSP409では、新しいトラックNのコンテンツキーKC_Nがメモリカードのストレージキーで暗号化され、トラック情報領域TRKINFのCONTENTS KEY−nnnに保存される。また、CONNUMはそのままトラック情報領域TRKINFのCONNUM−nnnに保存され、各パーツキーもそのままパーツ情報領域PRTINFのPRTKEY−nnnに保存される。
【0211】
次に、1つのパーツから構成されるトラックAを2つのトラックAおよびBに分割するデバイド(図10C参照)について、図41に示すフローチャートを用いて説明する。ステップSP501では、まず分割点がSUの単位で決定される。ステップSP502では、新しいトラックAのパーツ情報領域PRTINFのPRTSIZEが変更される。具体的には、先頭(スタートSU)から分割点(エンドSU)までのクラスタ数を数え、そのクラスタの中の分割点のSUの位置まで、すなわちクラスタサイズ、スタートSU、エンドSUが変更され、新しいトラックAのパーツ情報領域PRTINFのPRTSIZEに登録される。
【0212】
ステップSP503では、新しいトラックAの最後のクラスタ部分である分割点を含む1クラスタが完全に複写され、複写されたクラスタを新しいトラックBの先頭のパーツとする。ステップSP504では、新たに生成されたトラックBの総パーツ数がトラックBのトラック情報領域TRKINFの曲を構成するパーツ数を示すP−nnnに保存される。ここでは、分割点以降のクラスタがそのまま2つ目のパーツ、すなわち新たに生成されたトラックBとなり、新たに生成されたトラックBの総パーツが数えられる。ステップSP505では、新しい音のファイル番号FNW−nnnが生成され、トラック情報領域TRKINFのFNW−nnnに保存される。
【0213】
ステップSP506では、新しいトラックBのトラック情報領域TRKINFおよびパーツ情報領域PRTINFの2つが、トラック情報管理ファイルTRKLISTの中の新しいトラックAのパーツ情報領域PRTINFの後ろ部分に追加される。元のトラックAの後ろに存在したトラックのトラック情報領域TRKINFおよびパーツ情報領域PRTINFは、全てこの追加されたトラックBのトラック情報領域TRKINFおよびパーツ情報領域PRTINFの分だけ、後ろにずれることになる。
【0214】
ステップSP507では、新しいトラックAのATRAC3データファイルのFATのチェーンを分割点までとする変更が行われる。ステップSP508では、新しくトラックBが増えたのでディレクトリにATRAC3データファイルBが追加される。ステップSP509では、新たに出来たトラックBのATRAC3データファイル用のFATのチェーンは、複写された分割点を含む1クラスタを先頭に元のトラックAの残りの部分、すなわち分割点を含むクラスタ以降のクラスタのチェーンが後ろに接続される。
【0215】
そして、新しいトラックBの追加によりキーの値も追加される。新しいトラックAのキーの値は、変更しない。
【0216】
ステップSP510では、デバイドの後、新たにできたトラックBのコンテンツキーKC_Bが生成され、CONNUMも同時に新規に生成される。ステップSP511では、新しいトラックBのパーツキーKP_Bが生成される。新しいトラックBのパーツキーは、元のKC_AとKP_AとKC_Bとの排他的論理和(XOR)によって生成される。
【0217】
ステップSP512では、新しいトラックBのコンテンツキーKC_Bがメモリカードのストレージキーで暗号化され、トラック情報領域TRKINFのCONTENTS KEY−nnnに保存される。また、CONNUMはそのままトラック情報領域TRKINFのCONNUM−nnnに保存され、各パーツキーもそのままパーツ情報領域PRTINFのPRTKEY−nnnに保存される。
【0218】
このように、コンバインおよびデバイドなどの編集操作を行っても、トラック情報管理ファイルTRKLIST.MSFの内容は、ATRAC3データファイルの順番と同じ順番でトラック情報領域TRKINFおよびパーツ情報領域PRTINFが並べられる。すなわち、リンクPとは異なり、編集後の1つのファイルのトラック情報領域TRKINFおよびパーツ情報領域PRTINFのリンク先がランダムにならず、連続的に配置することができる。
【0219】
また、説明は省略するが、イレーズ、ムーブの編集操作を行った場合も、ATRAC3データファイルの順番と同じ順番でトラック情報領域TRKINFおよびパーツ情報領域PRTINFが並べられる。
【0220】
このように、メモリカードに記憶されているデータファイルに対して編集操作を行っても、この実施形態では、データファイルの情報が記述されたトラック情報領域TRKINFと、そのトラック情報領域TRKINFに記述されたパーツに関するパーツ情報領域PRTINFとを隣接させるという単純な方法でMDの採用されたリンクPの難しさを解決している。
【0221】
【発明の効果】
この発明に依れば、フラッシュメモリ上のFATが破壊されても、この発明は各ファイルの先頭に属性ファイルを付加して属性ファイルで離散的に存在するパーツを管理するようにしたので編集処理が安定して行われるとともに、フラッシュメモリのようなブロックの欠陥に配慮が必要な記録媒体に対しても安定した編集処理を行えるという利点が存在する。
【図面の簡単な説明】
【図1】この発明の不揮発性メモリカードを使用したデジタルオーディオレコーダ/プレーヤーに関するブロック図である。
【図2】この発明に適応されるDSPの内部ブロック図を示す。
【図3】この発明に適応されるメモリカードの内部ブロック図を示す。
【図4】この発明に適応されるメモリカードを記憶媒体とするファイル管理構造を示す模式図である。
【図5】この発明に適応されるメモリカード内のフラッシュメモリのデータの物理的構造を示す。
【図6】この発明に適応されるメモリカード内のデータ構造を示す、
【図7】メモリカード内に記憶されるファイル構造を示す枝図面である。
【図8】メモリカード内に記憶されるサブディレクトリーである再生管理ファイルPBLIST. MSFのデータ構造を示す。
【図9】連続した1つのATRAC3データファイルを所定単位長ごとに分割するとともに属性ファイルを付加した場合のデータ構造図である。
【図10】この発明のコンバイン編集処理および分割編集処理を説明するための構造図である。
【図11】再生管理ファイルPBLISTのデータ構造図を示す。
【図12】再生管理ファイルPBLISTのデータ構造図を示す。
【図13】付加情報データの種類の対応表を示す。
【図14】付加情報データの種類の対応表を示す。
【図15】付加情報データの種類の対応表を示す。
【図16】付加情報データのデータ構造を示す。
【図17】ATRAC3データファイルの詳細なデータ構造図である。
【図18】ATRAC3データファイルを構成する属性ヘッダーの上段のデータ構造図である。
【図19】ATRAC3データファイルを構成する属性ヘッダーの中段のデータ構造図である。
【図20】録音モードの種類と各録音モードにおける録音時間等を示す表である。
【図21】コピー制御状態を示す表である。
【図22】ATRAC3データファイルを構成する属性ヘッダーの下段のデータ構造図である。
【図23】ATRAC3データファイルのデータブロックのヘッダーのデータ構造図である。
【図24】この発明におけるFAT領域が破壊された場合の回復方法を示すフローチャートである。
【図25】メモリカード40内に記憶されるファイル構造を示す第2の実施形態における枝図面である。
【図26】トラック情報管理ファイルTRKLIST.MSFとATRAC3データファイルA3Dnnnnn.MSAとの関係を示す図である。
【図27】トラック情報管理ファイルTRKLIST.MSFの詳細なデータ構造を示す。
【図28】名前を管理するNAME1の詳細なデータ構造である。
【図29】名前を管理するNAME2の詳細なデータ構造である。
【図30】ATRAC3データファイルA3Dnnnnn.MSAの詳細なデータ構造を示す。
【図31】付加情報を示すINFLIST. MSFの詳細なデータ構造を示す。
【図32】付加情報データのを示すINFLIST. MSFの詳細なデータ構造を示す。
【図33】この発明の第2の実施形態におけるFAT領域が破壊された場合の回復方法を示す遷移図である。
【図34】メモリマップ構造の所定ファイル同士を結合処理した際の遷移を説明するためのメモリマップ図である。
【図35】結合編集処理の説明に用いるメモリマップ図である。
【図36】第1の実施形態で結合処理を説明するためのフローチャートである。
【図37】メモリマップ構造の所定ファイルを分割処理した際の遷移を説明するためのメモリマップ図である。
【図38】結合編集処理の説明に用いるメモリマップ図である。
【図39】第1の実施形態で分割処理を説明するためのフローチャートである。
【図40】第2の実施形態で結合処理を説明するためのフローチャートである。
【図41】第2の実施例で分割処理を説明するためのフローチャートである。
【図42】従来の光磁気ディスクに離散的に存在する記録可能領域を管理するためのU−TOC(User-Table of Content )の1つのパーツの管理形態を示す図である。
【符号の説明】
10・・・オーディオエンコーダ/デコーダIC、20・・・セキュリティIC、30・・・DSP、40・・・メモリカード、42・・・フラッシュメモリ、52・・・セキュリティブロック、PBLIST・・・再生管理ファイル、TRKLIST・・・トラック情報管理ファイル、INFLIST・・・付加情報管理ファイル、A3Dnnn・・・オーディオデータファイル
Claims (21)
- 連続して再生される単一データファイルを所定長単位でブロック化し、上記ブロック化されたデータファイルと、上記データファイルのブロック化された情報からなる属性ファイルとが記録されたデータ領域と、上記データ領域に記録されたデータファイルを管理する管理データが記録された管理領域から成る不揮発性メモリにファイルアロケーションに対応して記録されたデータファイルを編集する編集装置において、
上記データ領域に記録されている複数のデータファイルの中から2つのデータファイルを結合処理するために、結合処理後の再生時に、再生する順番が先になる第1のデータファイルと、再生する順番が後になる第2のデータファイルとを選択する操作手段と、
上記操作手段にて選択された上記第1および第2のデータファイルを論理的にリンクするように上記第1のデータファイルを管理する第1の管理データの第1のデータファイルの終端を示すアドレスを、上記第2のデータファイルの先頭を示すアドレスへ変更する編集手段と、
上記操作手段にて選択された上記第1のデータファイルのブロック化された情報が記録された第1の属性ファイルの情報を変更すると共に、上記第2のデータファイルのブロック化された情報が記録された第2の属性ファイルを削除する属性ファイル変更手段と、
上記編集手段にて変更された上記第1の管理データを上記管理領域に記録すると共に、上記変更手段にて変更された上記第1の属性ファイルを上記データ領域に記録する記録手段と
からなることを特徴とする編集装置。 - 請求項1において、
上記データ領域には、さらに総データファイル数が少なくとも管理されている再生管理データが記録されていることを特徴とする編集装置。 - 請求項1において、
上記第1の属性ファイルには、上記第1のデータファイルに対して暗号化するためのキーが記録されており、上記変更処理に伴いキーを書き換えることを特徴とする編集装置。 - 請求項1において、
上記第1および第2の属性ファイルには、対応する上記第1および第2のデータファイルの総データ量が記録されており、上記変更手段にて変更される上記第1の属性ファイルの総データ量を、上記第1の属性ファイルの総データ量と、上記第2の属性ファイルの総データ量とを加算した値に書き換えることを特徴とする編集装置。 - 請求項1において、
上記変更手段にて、変更された上記第2の属性ファイルを記録可能ブロックとして指定することを特徴とする編集装置。 - 請求項1において、
連続して再生される上記第1および第2のデータファイルは、ブロック化された複数のブロックを集合化した少なくとも1つ以上のパーツから構成され、上記第1および第2の属性ファイルは上記パーツ数を管理することを特徴とする編集装置。 - 請求項6において、
上記変更手段にて、上記第1の属性ファイルで管理されているパーツ数と、上記第2の属性ファイルで管理されているパーツ数とを加算した値に基づいて、上記第1の属性ファイルを変更することを特徴とする編集装置。 - 請求項6において、
上記第1および第2の属性ファイルには、各パーツを暗号化するためのパーツキーが記録されていることを特徴とする編集装置。 - 請求項8において、
上記変更時上記パーツキーを書換えることを特徴とする編集装置。 - 請求項8において、
上記第1および第2の属性ファイルには、上記データファイルに対して暗号化するためのキーが記録されており、上記キーに基づいて上記パーツキーを暗号化することを特徴とする編集装置。 - 連続して再生される単一データファイルを所定長単位でブロック化し、上記ブロック化されたデータファイルと、上記データファイルのブロック化された情報からなる属性ファイルとが記録されたデータ領域と、上記データ領域に記録されたデータファイルを管理する管理データが記録された管理領域から成る不揮発性メモリにファイルアロケーションに対応して記録されたデータファイルを編集する編集方法において、
上記データ領域に記録されている複数のデータファイルの中から2つのデータファイルを結合処理するために、結合処理後の再生時に、再生する順番が先になる第1のデータファイルと、再生する順番が後になる第2のデータファイルとを選択するステップと、
上記操作手段にて選択された上記第1および第2のデータファイルを論理的にリンクするように上記第1のデータファイルを管理する第1の管理データの第1のデータファイルの終端を示すアドレスを、上記第2のデータファイルの先頭を示すアドレスへ変更するステップと、
上記操作手段にて選択された上記第1のデータファイルのブロック化された情報が記録された第1の属性ファイルの情報を変更すると共に、上記第2のデータファイルのブロック化された情報が記録された第2の属性ファイルを削除するステップと、
変更された上記第1の管理データを上記管理領域に記録すると共に、変更された上記第1の属性ファイルを上記データ領域に記録するステップと
からなることを特徴とする編集方法。 - 連続して再生される単一データファイルを所定長単位でブロック化し、上記ブロック化されたデータファイルと、上記データファイルのブロック化された情報からなる属性ファイルとが記録されたデータ領域と、上記データ領域に記録されたデータファイルを管理する管理データが記録された管理領域から成る不揮発性メモリにファイルアロケーションに対応して記録されたデータファイルを編集する装置において、
上記データ領域に記録されている所定のデータファイル中から分割処理するためのデータファイルを選択し、上記選択されたデータファイルの再生時に、再生する順番が先になる第1のデータファイルと、再生する順番が後になる第2のデータファイルとの分割点を設定する操作手段と、
上記分割点が設定されたデータファイルを管理する管理データを、上記設定された分割点に対応するように、上記第1のデータファイルを管理する第1の管理データと、上記第2のデータファイルを管理する第2の管理データとを形成する編集手段と、
上記分割点が設定されたデータファイルのブロック化された情報が記録された属性ファイルから、上記設定された分割点に対応するように、上記第1のデータファイルのブロック化された情報が記録された第1の属性ファイルと、上記第2のデータファイルのブロック化された情報が記録された第2の属性ファイルとを生成する生成手段と、
上記編集手段にて形成された上記第1および第2の管理データを上記管理領域に記録すると共に、上記生成手段にて生成された上記第1および第2の属性ファイルを上記データ領域に記録する記録手段と
からなることを特徴とする編集装置。 - 請求項12において、
上記データ領域には、さらに総データファイル数が少なくとも管理されている再生管理データが記録されていることを特徴とする編集装置。 - 請求項12において、
上記第1および第2の属性ファイルには、上記第1および第2のデータファイルに対して暗号化するためのキーが記録されており、上記生成処理に伴いキーを書き換えることを特徴とする編集装置。 - 請求項12において、
上記生成手段にて、生成される上記第1および第2の属性ファイルには、対応する上記第1および第2のデータファイルの総データ量が管理されていることを特徴とする編集装置。 - 請求項12において、
連続して再生される上記第1および第2のデータファイルは、ブロック化された複数のブロックを集合化した少なくとも1つ以上のパーツから構成され、上記第1および第2の属性ファイルは上記パーツ数を管理することを特徴とする編集装置。 - 請求項16において、
上記生成手段では、上記操作手段にて設定された分割点に基づいて、上記第1の属性ファイルで管理されているパーツ数と、上記第2の属性ファイルで管理されているパーツ数とを生成することを特徴とする編集装置。 - 請求項16において、
上記第1および第2の属性ファイルには、各パーツを暗号化するためのパーツキーが記録されていることを特徴とする編集装置。 - 請求項18において、
上記生成時上記パーツキーを書換えることを特徴とする編集装置。 - 請求項18において、
上記第1および第2の属性ファイルには、上記データファイルに対して暗号化するためのキーが記録されており、上記キーに基づいて上記パーツキーを暗号化することを特徴とする編集装置。 - 連続して再生される単一データファイルを所定長単位でブロック化し、上記ブロック化されたデータファイルと、上記データファイルのブロック化された情報からなる属性ファイルとが記録されたデータ領域と、上記データ領域に記録されたデータファイルを管理する管理データが記録された管理領域から成る不揮発性メモリにファイルアロケーションに対応して記録されたデータファイルを編集する編集方法において、
上記データ領域に記録されている所定のデータファイル中から分割処理するためのデータファイルを選択し、上記選択されたデータファイルの再生時に、再生する順番が先になる第1のデータファイルと、再生する順番が後になる第2のデータファイルとの分割点を設定するステップと、
上記分割点が設定されたデータファイルを管理する管理データを、上記設定された分割点に対応するように、上記第1のデータファイルを管理する第1の管理データと、上記第2のデータファイルを管理する第2の管理データとを形成するステップと、
上記分割点が設定されたデータファイルのブロック化された情報が記録された属性ファイルから、上記設定された分割点に対応するように、上記第1のデータファイルのブロック化された情報が記録された第1の属性ファイルと、上記第2のデータファイルのブロック化された情報が記録された第2の属性ファイルとを生成するステップと、
形成された上記第1および第2の管理データを上記管理領域に記録すると共に、生成された上記第1および第2の属性ファイルを上記データ領域に記録するステップと
からなることを特徴とする編集方法。
Priority Applications (15)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP34910899A JP4281185B2 (ja) | 1999-03-25 | 1999-12-08 | 編集装置および方法 |
DE60039383T DE60039383D1 (de) | 1999-03-03 | 2000-03-03 | Editierapparat und Editierverfahren |
DE60043600T DE60043600D1 (de) | 1999-03-03 | 2000-03-03 | Bearbeitungsvorrichtung und Bearbeitungsverfahren |
EP08003239A EP1927989B1 (en) | 1999-03-03 | 2000-03-03 | Editing apparatus and editing method |
EP00301763A EP1041575B1 (en) | 1999-03-03 | 2000-03-03 | Editing apparatus and editing method |
MYPI20001113 MY127997A (en) | 1999-03-25 | 2000-03-21 | Editing apparatus and editing method |
NO20001485A NO325128B1 (no) | 1999-03-25 | 2000-03-22 | Redigeringsanordning og fremgangsmate til redigering |
CNB001047175A CN1162781C (zh) | 1999-03-25 | 2000-03-24 | 编辑设备和编辑方法 |
US09/535,003 US7089271B1 (en) | 1999-03-25 | 2000-03-24 | Editing apparatus and editing method |
HU0001239A HU229696B1 (en) | 1999-03-25 | 2000-03-24 | Method and apparatus for editing recorded programs |
KR20000015067A KR100720838B1 (ko) | 1999-03-25 | 2000-03-24 | 편집 장치 및 편집 방법 |
US11/079,576 US7634493B2 (en) | 1999-03-25 | 2005-03-14 | Editing apparatus and editing method |
US11/079,838 US7526086B2 (en) | 1999-03-25 | 2005-03-14 | Editing apparatus and editing method |
US11/079,750 US7519277B2 (en) | 1999-03-25 | 2005-03-14 | Editing apparatus and editing method |
US11/079,671 US20050191029A1 (en) | 1999-03-25 | 2005-03-14 | Editing apparatus and editing method |
Applications Claiming Priority (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP8153599 | 1999-03-25 | ||
JP11-81535 | 1999-06-29 | ||
JP11-183412 | 1999-06-29 | ||
JP18341299 | 1999-06-29 | ||
JP34910899A JP4281185B2 (ja) | 1999-03-25 | 1999-12-08 | 編集装置および方法 |
Publications (3)
Publication Number | Publication Date |
---|---|
JP2001075856A JP2001075856A (ja) | 2001-03-23 |
JP2001075856A5 JP2001075856A5 (ja) | 2006-04-27 |
JP4281185B2 true JP4281185B2 (ja) | 2009-06-17 |
Family
ID=27303616
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP34910899A Expired - Lifetime JP4281185B2 (ja) | 1999-03-03 | 1999-12-08 | 編集装置および方法 |
Country Status (7)
Country | Link |
---|---|
US (4) | US7089271B1 (ja) |
JP (1) | JP4281185B2 (ja) |
KR (1) | KR100720838B1 (ja) |
CN (1) | CN1162781C (ja) |
HU (1) | HU229696B1 (ja) |
MY (1) | MY127997A (ja) |
NO (1) | NO325128B1 (ja) |
Families Citing this family (24)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR100425295B1 (ko) * | 2000-09-19 | 2004-03-30 | 삼성전자주식회사 | Av 시스템의 음악 기록/재생 모듈 |
US7526795B2 (en) * | 2001-03-27 | 2009-04-28 | Micron Technology, Inc. | Data security for digital data storage |
EP1402372B1 (en) * | 2001-07-05 | 2017-09-20 | Panasonic Intellectual Property Management Co., Ltd. | Recording apparatus, medium, method, and related computer program |
JP3855862B2 (ja) * | 2002-04-01 | 2006-12-13 | ソニー株式会社 | 編集方法および装置 |
AU2003201840A1 (en) * | 2002-04-01 | 2003-10-23 | Sony Corporation | Reproducing method, reproducing apparatus, recording method, recording apparatus, and method for generating a management table |
KR100503066B1 (ko) * | 2002-09-14 | 2005-07-21 | 삼성전자주식회사 | 음악 파일 저장 및 재생 장치와 그 방법 |
KR100502711B1 (ko) * | 2003-03-14 | 2005-07-20 | 주식회사 코원시스템 | 휴대용 정보 기록재생장치의 기록 데이터 복구방법 |
JP2004280752A (ja) * | 2003-03-19 | 2004-10-07 | Sony Corp | データ記憶装置、およびデータ記憶装置における管理情報更新方法、並びにコンピュータ・プログラム |
US20040243421A1 (en) * | 2003-05-29 | 2004-12-02 | Jannott Frederick P. | System and method of presenting construction specifications |
JP3888353B2 (ja) | 2004-01-07 | 2007-02-28 | ソニー株式会社 | データ編集装置及びデータ編集方法 |
JPWO2005124766A1 (ja) * | 2004-06-15 | 2008-04-17 | 松下電器産業株式会社 | ドライブ装置 |
JP4724412B2 (ja) * | 2004-11-25 | 2011-07-13 | キヤノン株式会社 | 画像データ記録装置 |
WO2006077822A1 (ja) * | 2005-01-24 | 2006-07-27 | Matsushita Electric Industrial Co., Ltd. | 署名生成装置及び署名検証装置 |
JP2006338371A (ja) * | 2005-06-02 | 2006-12-14 | Toshiba Corp | メモリシステム |
JP5025104B2 (ja) * | 2005-07-19 | 2012-09-12 | キヤノン株式会社 | 撮像装置及びその制御方法、コンピュータプログラム |
CN100485681C (zh) * | 2006-03-23 | 2009-05-06 | 北京握奇数据系统有限公司 | 智能卡存储系统及该系统中文件创建管理的方法 |
US8354997B2 (en) * | 2006-10-31 | 2013-01-15 | Navisense | Touchless user interface for a mobile device |
US7876895B2 (en) * | 2007-05-09 | 2011-01-25 | International Business Machines Corporation | System, method, and service for performing unified broadcast encryption and traitor tracing for digital content |
US8082387B2 (en) * | 2007-10-29 | 2011-12-20 | Micron Technology, Inc. | Methods, systems, and devices for management of a memory system |
JP4816740B2 (ja) * | 2009-02-09 | 2011-11-16 | ソニー株式会社 | 情報処理装置、および情報処理方法、並びにプログラム |
US9054920B2 (en) * | 2011-03-31 | 2015-06-09 | Alcatel Lucent | Managing data file transmission |
JP6142669B2 (ja) | 2013-05-22 | 2017-06-07 | 株式会社ソシオネクスト | データ編集プログラム、データ編集装置、データ編集方法 |
JP6173896B2 (ja) * | 2013-12-10 | 2017-08-02 | 株式会社日立製作所 | データ処理方法およびデータ処理サーバ |
CN109917926A (zh) * | 2017-12-12 | 2019-06-21 | 李金泽 | 猎道输入法 |
Family Cites Families (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5664181A (en) * | 1992-03-17 | 1997-09-02 | International Business Machines Corporation | Computer program product and program storage device for a data transmission dictionary for encoding, storing, and retrieving hierarchical data processing information for a computer system |
US5805762A (en) * | 1993-01-13 | 1998-09-08 | Hitachi America, Ltd. | Video recording device compatible transmitter |
JP3578491B2 (ja) * | 1994-09-05 | 2004-10-20 | 富士通株式会社 | Cgアニメーション編集装置 |
JP3511721B2 (ja) | 1995-03-15 | 2004-03-29 | ソニー株式会社 | 情報処理方法及び装置 |
US5845240A (en) * | 1996-07-24 | 1998-12-01 | Fielder; Mark | Selective recall and preservation of continuously recorded data |
US6085323A (en) * | 1996-04-15 | 2000-07-04 | Kabushiki Kaisha Toshiba | Information processing system having function of securely protecting confidential information |
US5845210A (en) | 1996-08-15 | 1998-12-01 | Ericsson, Inc. | Method and apparatus for supporting data transmission over analog and digital cellular telephone air interfaces |
TW346586B (en) * | 1997-05-16 | 1998-12-01 | Feng Bao Systems Co Ltd Ing | Method for editing a multimedia simultaneous teaching system |
US6353700B1 (en) * | 1998-04-07 | 2002-03-05 | Womble Multimedia, Inc. | Method and apparatus for playing an MPEG data file backward |
US6278678B1 (en) * | 1999-02-12 | 2001-08-21 | Sony Corporation | Editing apparatus, editing method, and recording medium |
MY122279A (en) * | 1999-03-03 | 2006-04-29 | Sony Corp | Nonvolatile memory and nonvolatile memory reproducing apparatus |
-
1999
- 1999-12-08 JP JP34910899A patent/JP4281185B2/ja not_active Expired - Lifetime
-
2000
- 2000-03-21 MY MYPI20001113 patent/MY127997A/en unknown
- 2000-03-22 NO NO20001485A patent/NO325128B1/no not_active IP Right Cessation
- 2000-03-24 HU HU0001239A patent/HU229696B1/hu not_active IP Right Cessation
- 2000-03-24 US US09/535,003 patent/US7089271B1/en not_active Expired - Fee Related
- 2000-03-24 KR KR20000015067A patent/KR100720838B1/ko not_active IP Right Cessation
- 2000-03-24 CN CNB001047175A patent/CN1162781C/zh not_active Expired - Fee Related
-
2005
- 2005-03-14 US US11/079,838 patent/US7526086B2/en not_active Expired - Fee Related
- 2005-03-14 US US11/079,576 patent/US7634493B2/en not_active Expired - Fee Related
- 2005-03-14 US US11/079,671 patent/US20050191029A1/en not_active Abandoned
Also Published As
Publication number | Publication date |
---|---|
CN1268847A (zh) | 2000-10-04 |
HUP0001239A2 (hu) | 2001-07-30 |
KR100720838B1 (ko) | 2007-05-25 |
JP2001075856A (ja) | 2001-03-23 |
NO325128B1 (no) | 2008-02-04 |
HU229696B1 (en) | 2014-05-28 |
NO20001485L (no) | 2000-09-26 |
US20050180729A1 (en) | 2005-08-18 |
KR20010006865A (ko) | 2001-01-26 |
US7089271B1 (en) | 2006-08-08 |
US20050175318A1 (en) | 2005-08-11 |
CN1162781C (zh) | 2004-08-18 |
US7526086B2 (en) | 2009-04-28 |
US20050191029A1 (en) | 2005-09-01 |
NO20001485D0 (no) | 2000-03-22 |
HU0001239D0 (en) | 2000-05-28 |
MY127997A (en) | 2007-01-31 |
US7634493B2 (en) | 2009-12-15 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4135049B2 (ja) | 不揮発性メモリ | |
JP4214651B2 (ja) | データコミュニケーションシステム、データ管理方法 | |
JP4543554B2 (ja) | データ処理装置およびデータ処理方法 | |
JP4281185B2 (ja) | 編集装置および方法 | |
JP4779183B2 (ja) | 再生装置および再生方法 | |
JP4842417B2 (ja) | 記録装置 | |
JP4207335B2 (ja) | 記録装置、記録再生システム | |
JP4749522B2 (ja) | 再生装置および再生方法 | |
JP2001117821A (ja) | 記録媒体、編集装置、記録システム | |
JP4524921B2 (ja) | 記録装置、記録方法、再生装置および再生方法 | |
JP4406988B2 (ja) | 不揮発性記録媒体、記録方法、記録装置 | |
KR100838901B1 (ko) | 재생 장치 및 재생 방법 | |
JP4897138B2 (ja) | 再生装置および再生方法 | |
JP4293196B2 (ja) | 再生装置、編集方法 | |
US7519277B2 (en) | Editing apparatus and editing method | |
JP4284797B2 (ja) | 記録装置 | |
EP1041574B1 (en) | Nonvolatile memory | |
EP1041575B1 (en) | Editing apparatus and editing method | |
RU2252448C2 (ru) | Устройство и способ редактирования |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060314 |
|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060314 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20081202 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090126 |
|
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: 20090224 |
|
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: 20090309 |
|
R151 | Written notification of patent or utility model registration |
Ref document number: 4281185 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R151 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120327 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130327 Year of fee payment: 4 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140327 Year of fee payment: 5 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
EXPY | Cancellation because of completion of term |