RU2252448C2 - Device and editing method - Google Patents

Abstract

FIELD: computer science.

SUBSTANCE: editing is performed for data files, which are segmented on blocks, each of which has known data length, and to which attribute file is added, having known length, while segmented blocks are recorded on energy independent memory device., method includes selecting two files of data, recorded in data area for their combination, attribute file is separated from the last data file from selected two; control data are edited recorded in control area by setting a logical link between two data files, and attribute file added to first placed file is edited; and edited control data are recorded to control area, and attribute file - to data area.

EFFECT: broader functional capabilities.

4 cl, 5 dwg

Description

Technical field

The present invention relates to an editing apparatus and method for executing an editing process, such as a process of dividing or combining file (s) recorded in a memory card using a TRF (File allocation table).

State of the art

EEPROM (Electrically Erasable Programmable ROM), that is, an electrically rewritable memory device, requires a large amount of space, since each bit is represented by two transistors. Thus, integration in various EPROM devices is limited. To solve this problem, flash memory was developed in which one bit is represented by one transistor using the erase all bits system. Flash is supposed to replace conventional recording media such as magnetic disks and optical disks in the future.

A memory device in the form of a card using flash memory is also known. A memory device in the form of a card can easily be connected to and disconnected from the device. A digital recording / reproducing sound device may be made in which a card storage device is used in place of a conventional compact disc (CD) or mini-disc (MD).

The file management system used in conventional personal computers is called TRF (file allocation table). In the TRF system, when a specific file is determined, in connection with this file, predetermined parameters are sequentially set. In this case, the file size becomes a variable. One file consists of at least one control module (sector, cluster, etc.). Data corresponding to the control module is recorded in a table called TRF. In the TRF file system, the file structure can be easily generated regardless of the physical characteristics of the recording medium. Thus, the TRF file system can be used for a magneto-optical disk, as well as for a flexible magnetic disk and for a hard disk. In the above memory device in the form of a card, a file system with TRF is also used.

However, in the CD on which sound data is recorded, TRF is not used at all. In the era of MD application, on which sound data can be recorded and played back, music programs are recorded and edited using a modified TRF system called Link-P. With its use, the system itself can be controlled by a CPU with low energy consumption. However, when using such a system, it is impossible to exchange data with a personal computer. Thus, the MD system was developed as an isolated audiovisual system.

The Link-P system used in the MD consists of the PFD Pointer (P-DFA), P-Empty area Pointer, P-FRA Pointer (Free Area Pointer), and P-TNo1 ... pointers P-TNo255. The DFO index represents the starting point of a segment that contains information about MD defects. The Empty Area pointer represents the usage state of the segment. The CBO pointer represents the starting point of the segment used to control the area to which recording can be made. Pointers P-TNo1, P-TNo2, ..., P-TNo255 represent the starting points of the segments corresponding to individual music programs.

Further, in FIGS. 42A-42E, it can be seen that the process of sequentially searching for areas to which recording can be made distributed on the recording medium can be described using the CBO area. In figures 42A-42E, the region of the CBO is located at 03h. In this case, as shown in FIG. 42A, access is made to the segment 03h. The start address and end address recorded in the 03h segment represent the start address and end address of the disk portion.

As shown in FIG. 42A, the communication information recorded in the segment 03h represents that the next segment address is 18h. Thus, as shown in FIG. 42B, segment 18h is accessed. Communication information recorded in segment 18h indicates that the next segment address is 1Fh. Similarly, as shown in FIG. 42C, access is made to the 1Fh segment. As shown in FIG. 42D, in accordance with the communication information in the 1Fh segment, the 2Bh segment is accessed. As shown in FIG. 42E, in accordance with the communication information in the 2Bh segment, access is made to the E3h segment. Communication information is monitored in this manner until zero (00h) is detected as communication information. In this way, the addresses of the areas to which recording can be made distributed over the MD are sequentially recognized. The areas in which recording can be made, distributed in memory, can be obtained by alternately monitoring the output optical signal and sequential access to these addresses. Likewise, using the links U-DFO or P-TNoN, successful access to defective areas that are distributed in memory can be made.

Using the Link-P system used for mini-disks, an editing process such as a split process and a combination process of a music program (s) can be easily performed. At the same time, although the music program can be easily edited using a conventional optical disc, you cannot edit files using a regular non-volatile memory. As in the case of the editing process using the Link-P system, the separation process or the process of combining a music program (s) can be performed using TRF editing. However, if the TRF is destroyed, the editing process cannot be completed. In addition, after the file has been edited, it cannot be accessed. In particular, when data is overwritten at the same position of the block in flash memory, part of it located in the block will be destroyed. To solve this problem, data is recorded in such a way that re-recording is not performed in the same block. However, when applying this method, when the data recorded in the flash memory is re-edited, defective blocks are formed. When the block that is used to manage TRF information is destroyed, the editing process cannot be completed. In addition, you cannot access the edited file.

SUMMARY OF THE INVENTION

The present invention is directed to an editing device and an editing method for use with non-volatile memory by adding an attribute file to the beginning of each data file and controlling the parts that are allocated in the memory using the attribute file so that it becomes possible to carry out the editing process, even if the TRF region is destroyed.

According to a first aspect of the present invention, an editing device for editing a data file recorded in a non-volatile storage device for segmenting a single data file that is sequentially reproduced in the form of data blocks, each of which has a predetermined length, this non-volatile storage device having a data area for recording each block together with an attribute file having a predetermined length and a control region The part for recording control data necessary for managing the data file recorded in the data area comprises an operating means for selecting two data files recorded in the data area for performing the combination process of the selected two data files, a separation means for separating the file attribute from the last data file of the selected two data files, an editing tool for editing control data recorded in the control area by creating a logical connection between two data files and editing an attribute file that is added to the first data file of the selected two data files, and a recording tool for writing control data edited with the editing tool to the control area and writing the attribute file added to the first data file located in the data area.

In accordance with a second aspect of the present invention, an editing device for editing a data file recorded in a non-volatile storage device for segmenting a single data file that is sequentially reproduced in the form of blocks, each of which has a predetermined data length, and this is a non-volatile storage device has a data area for recording each block together with an attribute file having a predetermined length, and a control area for recording control data for managing a data file recorded in the data area, comprises operating means for setting a split point of a particular data file recorded in the data area, editing means for editing an added attribute file and control data, in accordance with the split point of the data file set by the operating means, generating means for generating a data attribute file following the split point that is set by the operating tool and a recording means for writing control data edited by the editing tool to the control area and write the attribute file added to the data file in front of the split point to the data area .

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 depicts a block diagram of the structure of a digital recording / reproducing sound device using a non-volatile memory device such as cards in accordance with the present invention;

Figure 2 is a block diagram of the internal structure of a DSP 30 in accordance with the present invention;

FIG. 3 is a block diagram of an internal structure of a card type memory 40 in accordance with the present invention; FIG.

4 is a diagram of a file management structure of a memory device of a card type used as an information storage medium in accordance with the present invention;

5 is a block diagram of a physical data structure in a flash memory 42 of a card type memory 40 in accordance with the present invention;

6 is a data structure of a card type memory 40 in accordance with the present invention;

7 is a diagram of a hierarchy of a file structure in a card type memory 40;

Fig. 8 is a data structure diagram of a reproduction management file PBLIST.MSF, which is a subdirectory recorded in a card type memory 40;

Fig.9 is a diagram of the data structure, in the case when one ATRAC3 data file is divided into blocks with a predetermined length, and attribute files are added to it;

Fig. 10A is a diagram of a file structure before editing using a combining process;

10B is a diagram of a file structure after editing using a combination process;

Fig. 10C is a diagram of a file structure after editing using a separation process;

11 is a data structure diagram of a playback control file PBLIS;

12A is a data structure diagram of a portion of a header of a playback control file PBLIST;

12B is a data structure diagram of a portion of the main data of a playback control file PBLIST;

12C is a diagram of a data structure of a data part of additional information of a reproduction management file PBLIST;

Fig. 13 is a table showing the correlation of data types of additional information and code values;

Fig. 14 is a table showing the correlation of data types of additional information and code values;

Fig. 15 is a table showing the correlation of data types of additional information and code values;

Figa is a diagram of the data structure of additional information;

Figv is a diagram of the data structure in the case when the additional information data is the name of the artist;

16C is a data structure diagram in a case where the additional information data is a copyright code.

Fig.16D is a diagram of a data structure in the case when the additional information data is date / time information;

16E is a diagram of a data structure in the case where the additional information data is a reproduction protocol;

17 is a diagram of a detailed data structure of an ATRAC3 data file;

Fig. 18 is a data structure diagram of an upper portion of an attribute header that contains an ATRAC3 data file.

Fig. 19 is a data structure diagram of a middle portion of an attribute header that constitutes an ATRAC3 data file;

Fig. 20 is a table showing the correlation of the recording mode, recording time, etc.

21 is a table representing a copy control state;

Fig is a diagram of the data structure of the lower part of the attribute header, which is part of the ATRAC3 data file;

23 is a data structure diagram of a data block header of an ATRAC3 data file;

Figa - 24C - algorithms representing a recovery method in accordance with the present invention, when the destruction of the TRF region;

25 is a diagram of a file structure in a card type memory 40 in accordance with a second embodiment of the present invention;

26 is a diagram of the relationship between the information management file TRKLIST.MSF and the ATRAC3 data file A3Dnnnnn.MSA;

Fig. 27 is a diagram of a detailed data structure of a music recording information management file TRKLIST.MSF;

FIG. 28 is a diagram of a detailed data structure of a file NAME1 for managing a name; FIG.

Fig. 29 is a diagram of a detailed data structure of a file NAME2 for managing a name;

30 is a diagram of a detailed data structure of an ATRAC3 data file A3Dnnnnn.MSA;

Fig is a diagram of a detailed data structure of the file INFLIST.MSF, which represents additional information;

32 is a diagram of a detailed data structure of an INFLIST.MSF file that represents additional information data;

Fig. 33 is a flowchart representing a recovery method in accordance with a second embodiment of the present invention in a case where the TRF region has been destroyed;

Fig. 34 is a diagram of a memory card for explaining a data transition in a combining process for combining specific files in a memory card structure (see Fig. 6) in accordance with a first embodiment;

Fig. 35A is a diagram of a memory card before two files have been combined;

Fig. 35B is a diagram of a memory card after two files have been combined;

Fig. 36 is a flowchart for explaining a combining process in accordance with a first embodiment of the present invention;

Fig. 37 is a diagram of a memory card for explaining data movement during a separation process for separating a specific program in a memory card structure (see Fig. 6) in accordance with a first embodiment of the present invention;

Fig. 38A is a diagram of a memory card before a particular program has been combined.

Figv is a diagram of a memory card after a particular program has been combined;

Fig. 39 is a flowchart for explaining a separation process in accordance with a first embodiment of the present invention;

40 is a flowchart for explaining a combining process in accordance with a second embodiment of the present invention;

Fig. 41. - an algorithm for explaining the separation process in accordance with the second embodiment of the present invention;

Figa is a diagram of a control method for one part of the U-TOC (User Content Table), designed to control areas in which can be recorded, distributed on a conventional magneto-optical disk;

Fig. 42B is a diagram of a control method for a part combined in accordance with the part shown in Fig. 42A;

F ig 42C is a diagram of the control method for the part combined in accordance with the part shown in figv;

Fig. 42D is a diagram of a control method for a part combined in accordance with the part shown in Fig. 42C; and

Fig. 42E is a diagram of a control method for the - part combined in accordance with the part shown in Fig. 42D.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Next will be described an embodiment of the present invention. 1 is a block diagram depicting the structure of a digital recording / reproducing apparatus using a memory device such as a card in accordance with one embodiment of the present invention. A digital recording / reproducing device records and reproduces a digital audio signal using a removable memory device such as a card. In fact, the recording / reproducing device is an audio system comprising an amplifier unit, a speaker, a CD player, a magnetic disk recorder, a tuner, etc. However, it should be noted that the present invention can be applied to other types of sound recording devices. In other words, the present invention can be applied with portable recording / reproducing devices. In addition, the present invention can be applied with a set of equipment that records digital audio data that is transmitted via a satellite communications channel, digital broadcast station or the Internet. In addition, the present invention can be applied to a system that records / reproduces not only audio data, but also moving and still image data. The system in accordance with this embodiment of the present invention can record and reproduce additional information, such as an image or text, not related to a digital audio signal.

The recording / reproducing device comprises an encoding / decoding microcircuit 10, a security microcircuit 20, a DSP (Digital Signal Processor) 30. Each of these devices is represented by a single microcircuit. The recording / reproducing apparatus has a detachable memory card type 40. The memory card type 40 is a single chip and contains flash memory (non-volatile memory), a memory control unit and a security unit. The security unit has a coding scheme according to the standard SKD (DES) (Data Encoding Standard). According to this embodiment, a microcomputer may be used in place of the DSP 30 in the recording / reproducing apparatus.

The encoding / decoding chip 10 has an audio interface 11, and an encoding / decoding unit 12. The encoding / decoding unit 12 encodes digital audio data in accordance with a highly efficient encoding method and writes encoded data to a card type memory 40. In addition, the encoding / decoding unit 12 decodes the encoded data that is read from the card type memory 40. As a highly efficient coding method, the ATRAC3 format is used, which is a modified ATRAC (Adaptive Converting Acoustic Encoding) format used in mini-disks.

In the ATRAC3 format, audio data sampled at a frequency of 44.1 kHz and which are divided into groups of 16 bits are encoded with high efficiency. In ATRAC3 format, the smallest processed audio data module is the ZM (SU) sound module. One ZM is data in which data from 1024 samples (1024 × 16 bits × 2 channels) are compressed to data that occupies several hundred bytes. The duration of one ZM is approximately 23 ms. With a highly efficient coding method, the volume of audio data is compressed to data with a volume of approximately 10 times less than the original data. As in the case of the ATRAC1 format used in mini-disks, the audio signal, compressed and then converted to its original form, in accordance with the ATRAC3 format, to a lesser extent degrades the sound reproduction quality.

The line input selector 13 selectively provides a mini-disc playback output signal, a tuner output signal, or a tape player output signal to an A / D converter 14. The A / D converter 14 converts the input line signal to a digital audio signal (sampling frequency = 44.1 kHz; the number of bits in the partition group 16). The digital input selector 16 selectively supplies the digital output signal MD, KD or CS (Satellite Digital Broadcasting) to the digital input receiver 17. The digital input signal is transmitted via, for example, an optical cable. The output signal of the digital input receiver 17 is supplied to the Converter 15 sampling speed. The sampling rate converter 15 converts the digital input signal into a digital audio signal (sampling frequency = 44.1 kHz; the number of bits in the partition group 16).

The encoding / decoding unit 12 of the audio encoding, decoding microcircuit 10 supplies the encoded data to the ACS encoding circuit 22 through the interface 21 of the microcircuit 20. The ACD encoding circuit 22 has a FIFO 23 (information processing scheme operating according to the principle: the first incoming information is served in the first turn). ACS coding scheme 22 is included in such a way that it protects the copyright of the content. The card type memory 40 also has an ACS coding scheme. The ACS encoding circuit 22 of the recording / reproducing device comprises a plurality of master codes and an accumulation code unique to the device. ACS encoding circuit 22 also has a random number generation circuit. ACS encoding circuit 22 22, together with a card type storage device 40 that has an ACS encoding scheme, can perform the process of identifying and processing a session key (a cryptographic key valid in only one information processing session). In addition, the ACS coding scheme 22 can re-encode data using the accumulation key of the ACS coding scheme.

The encoded audio data at the output of the ACS encoding circuit 22 is supplied to the DSP (Digital Signal Processor) 30. The DSP 30 is connected to a memory card type 40 through an interface. In this example, a card type storage device 40 is connected to an attachment / detachment mechanism (not shown) of a recording / reproducing device. The DSP 30 writes encoded data to a flash memory of a card type memory 40. The encoded data is sequentially transmitted between the DSP 30 and the card type memory 40. In addition, an external SRAM (Static Random Access Memory) 31 is connected to the DSP 30. The recording / reproducing device RAM 31 has sufficient capacity required to control a card type memory 40.

The bus interface 32 is connected to the DSP 30. Data is supplied from an external controller (not shown) to the DSP 30 via the bus 33. An external controller controls all operations of the audio system. An external controller provides data, such as a recording command or a playback command, that are generated in accordance with user actions using the operating part in the DSP 30 via the bus interface 32. In addition, the external controller provides additional information, such as image information, and information in the form of characters on the DSP 30 via the bus interface 32. Bus 33 is a bi-directional communication channel. Additional information that is read from the card type memory 40 is supplied to the external controller via the DSP 30, the bus interface 32 and the bus 33. In practice, the external controller is located, for example, in the amplifier block of the audio system. In addition, the external controller gives a command to a part of the display to display additional information, the status of the operating mode of the recording device, etc. One common display portion is used for the entire audio system. Since the data exchanged via bus 33 is not copyrighted data, it is not encoded.

The encoded audio data that is read from the card type memory 40 using the DSP 30 is decoded in the security chip 20. The audio encoder / decoder 10 decodes encoded data corresponding to the ATRAC3 format. The audio output of the encoder / decoder 10 is supplied to the D / A: converter 18. The D / A converter 18 converts the output of the audio encoder / decoder 10 to an analog signal. An analog audio signal is output to line output 19.

An analog audio signal is supplied to an amplifier unit (not shown) through line output 19. An analog sound signal is output through a speaker or headphones. The external controller provides a sound muting signal to the D / A converter 18. When the sound muting signal is set to turn on the sound muting mode, the external controller prohibits the output of the audio signal from line output 19.

FIG. 2 is a block diagram depicting the internal structure of the DSP 30. The DSP 30 shown in FIG. 2 includes a central unit 34, a flash memory 35, a RAM 36, a bus interface 37, a memory card type interface 38, and bridges between the buses. DSP 30 performs the same function as a microcomputer. The central unit 34 is equivalent to the CPU. Flash memory 35 stores a program that allows the DSP 30 to execute predetermined processes. RAM 36 and external RAM 31 are used in the same way as RAM in a recording / reproducing device.

The DSP 30 controls the recording process for writing encoded audio data and additional information to a card type memory 40 corresponding to an operational signal, such as a recording command, received via the bus interfaces 32 and 37, and a reading process for reading them from it. In other words, the DSP 30 is located between the software application side of the audio system, which records / plays audio data and additional information, and a memory card type 40. The DSP 30 operates when access is made to a memory card type 40. In addition, the DSP 30 operates in accordance with software, such as a file system.

The DSP 30 manages the files recorded in the card type memory 40 using a TRF system that is used in conventional personal computers. In addition, the file system in accordance with this embodiment of the present invention uses a control file. The control file will be described below. A control file is used to manage data files recorded in a card type memory 40. The control file, as the first file management information, is used to manage audio data files. On the other hand, TRF, as the second file management information, is used to manage all files, including audio data files and control files recorded in a flash memory of a card type memory 40. The control file is recorded in a memory card type 40. TRF is recorded in flash memory along with the root directory, etc., even before the memory card type 40 is sent to the user. The structure of the TRF will be described in detail below.

In accordance with this embodiment of the present invention, in order to protect copyright in data, encoding of audio data that has been compressed in accordance with the ATRAC3 format is performed. On the other hand, since there is no need to protect the copyright of the control file, it is not encoded. There are two types of memory card type, which are a type with encoding and a type without encoding. Moreover, a memory device such as a card, which is used with a recording / reproducing device into which data protected by copyright is recorded, is not limited to the type of encoding.

Voice data and image data that are recorded by users are recorded in memory devices such as cards without encoding.

Figure 3 is a block diagram depicting the internal structure of a card type memory 40. The memory card type 40 includes a control unit 41 and a flash memory 42, which are made in the form of a single chip. A bi-directional serial interface is located between the DSP 30 of the recording / reproducing device and the memory card type 40. The bi-directional serial interface contains ten lines, which are a synchronization line SCK for transmitting a synchronization signal that is transmitted along with data, a status SBS line for transmitting a signal that represents a status, a data DIO line for transmitting data, an INT line interrupts, two GND ground lines, two INT lines, and two redundant lines.

The synchronization line SCK is used to transmit a clock signal synchronously with the data. The status line SBS is used to transmit a signal that represents the status of the card type memory 40. A DIO data line is used to input and output commands and encoded audio data. The interrupt line INT is used to transmit an interrupt signal that causes the card type memory 40 to interrupt the operation of the DSP 30 of the recording / reproducing device. When the card type storage device 40 is connected to the recording / reproducing device, the card type storage device 40 generates an interrupt signal. However, in accordance with this embodiment of the present invention, since the interrupt signal is transmitted via the DIO data line, the interrupt line INT is grounded.

The serial / parallel conversion, parallel / serial conversion and interface unit 43 (S / P, P / S, I / F unit) is an interface located between the DSP 30 of the recording / reproducing device and the control unit 41 of the card type memory 40. The S / P, P / S, and IF block 43 converts the serial data received from the DSP 30 of the recording / reproducing device into parallel data, and transmits the parallel data to the control unit 41. In addition, the S / P, P / S, and IF block 43 converts the parallel data received from the control unit 41 into serial data and transmits this serial data to the DSP 30. When the S / P, P / S and IF block 43 receives command and data via the DIO data line, block 43 S / P, P / S and I / F separates them into data that has normal access to flash memory 42 and those that are encoded.

Data is transmitted in a format in which data is transmitted via the DIO data line after the command is transmitted. Block 43 S / P, P / S and IF determine the command code and determines whether this command and data are those that are normally accessed or encoded data. According to the result, the S / P, P / S, and IF block 43 writes a command that has normal access to the command register 44, and writes data that has normal access to the page buffer 45, and the write register 46. The memory card type device 40 has a circuit ^: 47 error correction code associated with the register 46 records. The error correction code encoding circuit 47 generates a redundancy code, which is an error correction code for data temporarily stored in the page buffer 45.

The output of the command register 44, the buffer 45 of the page 45, the register 46 of the record and the encoding circuit 47 of the error correction code are supplied to the flash memory interface and to the sequencing means 51 (hereinafter referred to as the memory I / F interface and sequencing means). The memory I / F interface and sequencer 51 are an interface located between the control unit 41 and the flash memory 42 and controls the data exchanged between them. Data is written to flash memory via an I / F memory interface and sequencer 51.

Sound data that has been compressed in accordance with the ATRAC3 format and recorded in flash memory (hereinafter, this audio data is referred to as ATRAC3 data) is encoded in the security chip 20 of the recording / reproducing device and in the security block 52 of the memory card type 40, so that to protect ATRAC3 data copyright. The security unit 52 comprises a buffer memory 53, an ACS encoding circuit 54 and a non-volatile memory 55. The card type storage unit 52 has a plurality of authentication keys and a unique recording key for each card type storage device. The non-volatile memory 55 contains a key necessary for encoding data. A key recorded in non-volatile memory 55 cannot be analyzed. According to this embodiment, for example, the write key is stored in non-volatile memory 55. The security unit 52 also has a random number generating circuit. The security unit 52 checks the validity of the corresponding recording / reproducing device and shares the session key with it. In addition, the security unit 52 re-encodes the content using the write key through the ACS encoding circuit 54.

For example, when a card type storage device 40 is connected to a recording / reproducing device, they are jointly checked for authenticity. Mutual authentication is performed on the security chip 20 of the recording / reproducing device and the security block 52 of the card-type memory 40. After the recording / reproducing device determines the attached card type storage device 40 as an applicable card type storage device 40, and the card type storage device 40 determines the recording / reproducing device as an applicable recording / reproducing device, they will be mutually verified for authenticity. After the mutual authentication process has been successfully completed, the recording / reproducing device and the card type memory 40 generate the corresponding session keys and exchange them with each other. Whenever the recording / reproducing device and the card type memory 40 determine the authenticity of each other, they generate corresponding session keys.

When data is recorded in the card type memory 40, the recording / reproducing device encodes the data key with the session key and transmits the encoded data to the card type memory 40. A card type memory 40 decodes the data key using the session key, re-encodes the data key with the recording key, and transmits the data key to the recording / reproducing device. The write key is a unique key for each memory card type 40. When the recording / reproducing device receives the encoded data key, the recording / reproducing device performs a formatting process for the encoded data key, and writes the encoded data key and encoded data to the recording / reproducing device 40 of the card type.

In the above section, the process of writing to a card type memory 40 has been described. In the following description, a reading process of a card type memory 40 will be described. Data that is read from flash memory 42 is fed to a page buffer 45, a read register 48, and error correction circuit 49 via a memory interface and sequencer 51. Error correction circuit 49 corrects errors in data written to page buffer 45. The output from the buffer 45 of the page in which the errors were corrected, and the output from the read register 48 are supplied to the S / P, P / S, and I / F block 43. The output of the S / P, P / S, and I / F unit 43 is supplied to the DSP 30 of the recording / reproducing unit via the serial interface described above.

When data is read from a card type memory 40, a data key encoded using the write key and content encoded using the block key are read from the flash memory 42. The security block 52 decodes the data key using the write key. The security unit 52 re-encodes the decoded content key using the session key and transmits the newly encoded content key to the recording / reproducing device. The recording / reproducing device decodes the content key using the received session key and generates a block key using the encoded content key. The recording / reproducing device sequentially decodes the encoded ATRAC3 data.

The configuration ROM 50 is a storage device in which partition information, various types of attribute information, etc. are stored. a memory device 40 type of card.

The card type storage device 40 also has a write protection switch 60. When the switch 60 is in the anti-erasure position, even if a command that causes the card type memory 40 to erase the data recorded in the flash memory 42 is supplied from the recording / reproducing device side to the card type memory 40, for the type 40 memory cards will not be allowed to erase data recorded in flash memory 42. Counter 61 of the generator is a generator that generates a clock signal that is used to synchronize the process s in the storage device 40 type of card.

4 is a flowchart showing a hierarchy of processes in a file system of a computer system that uses a card type storage device 40 as a recording medium. In this hierarchy, the top level is the application work layer. After the application layer, the file management layer, the logical address management layer, the physical address management layer and the flash memory access layer follow. In the above hierarchical structure, the file management layer is a TRF file system. Physical addresses are assigned to individual blocks of flash memory. The relationship between the blocks of flash memory and its physical addresses does not change. Logical addresses represent addresses that are logically processed at the file management process level.

5 is a block diagram representing a physical structure of data processed in a flash memory 42 of a memory card type 40. In memory 42, a data module (denoted as a segment) is divided into a predetermined number of blocks (fixed length). One block is divided into a predetermined number of pages (fixed length). In flash memory, data is erased in each block at the same time. Data is written to flash memory 42 and read from it page by page. The size of each block is the same. Similarly, each page is the same size. One block consists of pages from page 0 to page m. One block has a recording capacity of, for example, 8 KB (kilobytes) or 16 KB. One page has a recording capacity of 512 B (bytes). When one block has a write capacity of 8 KB, the total write capacity of flash memory 42 is 4 MB (512 blocks) or 8 MB (1024 blocks). When one block has a write capacity of 16 KB, the total write capacity of flash memory 42 is 16 MB (1024 blocks), 32 MB (2048 blocks), or 64 MB (4096 blocks).

One page consists of a piece of data of size 512 bytes and a redundant part of size 16 bytes. The first three bytes of the redundant part are the rewriting part, which is overwritten every time the data is updated. The first three bytes consistently contain the block status area, page status area, and update status area. The remaining 13 bytes of the redundant part are fixed data, which depends on the content of the data part. These 13 bytes contain the control flag area (1 byte), the logical address area (2 bytes), the format reserve area (5 bytes), the KIO information distribution area (2 bytes), and the KIO data area (3 bytes). The KIO information distribution area contains redundant data for the error correction process conducted in relation to the control flag area, the logical address area, and the format reserve area. The KIO data area contains redundant data for the error correction process carried out with respect to 512 bytes of data.

The control flag area contains a system flag (1: user block, 0: boot block), conversion table flag (1: invalid, 0: table block), copy prohibition flag (1: enabled, 0: not allowed) and access permission flag ( 1: free access, 0: read protection).

The first two blocks - blocks 0 and 1, are boot blocks. Block 1 is a backup of block 0. The boot blocks are the top valid blocks in a card-type storage device. When a card-type storage device is connected to a recording / reproducing device, boot blocks are first accessed. The remaining blocks are user blocks. The boot block page 0 contains a header area, a login area, and a download and attribute information area. Page 1 of the boot block contains the forbidden block data area. Page 2 of the boot block contains the CIS / IDI area (Card Information Structure / Driver Identification Information).

The header area of the boot block contains the boot block identifier and the number of valid inputs. System inputs represent the initial position of the data of the forbidden blocks, the size of their data, the type of their data, the initial position of the data in the ISK / ID area, the size of their data and the type of their data. The download and attribute information contains the type of the memory card type (read-only type, rewritable type or hybrid type), block size, number of blocks, total number of blocks, protected / unprotected type, date of manufacture of the card (date of manufacture), etc. .

Since flash memory has limitations on the number of times it can be overwritten due to wear of the insulating film, it is necessary to protect some recording areas (blocks) from accessing them too often. Thus, when data in a specific logical address recorded in a specific physical address is overwritten, updated data of a particular block is written to an unused block, and not to the original block. Thus, after updating the data, the relationship between the logical address and the physical address changes. This process is called a permutation process. Therefore, the same block is protected from an excessive number of accesses. Thus, the lifespan of flash memory can be extended.

The logical address is associated with data written to the block. Even if the block with the original data is different from the block with the updated data, the address in the TRF does not change. In this way, the same data can be accessed correctly. However, due to the fact that the permutation process is carried out, a conversion table is required, which shows the correlation between logical addresses and physical addresses (this table is denoted as a logical-physical address translation table). Thanks to the link to the conversion table of the logical-physical address, a physical address is obtained corresponding to the logical address indicated in the TRF. Thus, access to the block with the specified physical address can be made.

The DSP 30 writes a conversion table of the logical-physical address to RAM. When the write capacity of RAM is small, the conversion table of the logical-physical address can be written to flash memory. The logical-physical address translation table shows the correlation of logical addresses (2 bytes), sorted in ascending order, with physical addresses (2 bytes). Since the maximum flash recording capacity is 128 MB (8192 blocks), 8192 addresses can be assigned with two bytes. The logical-physical address translation table is managed for each segment. Thus, the size of the logical-physical address translation table is proportional to the recording capacity of flash memory. When the flash recording capacity is 8 MB (two segments), two pages are used as a logical-physical address translation table for each of the segments. When the conversion table is written to flash memory, one predetermined bit from the control flag area in the redundant part of each page represents whether or not the current block is a block containing the logical-physical address translation table.

The card-type storage device described above can be used with the TRF file system in a personal computer system as a recording medium in the form of a disk. The flash memory has an IPL area, a TRF area, and a root directory area (not shown in FIG. 5). The IPL area contains the address of the program that should be initially loaded into the memory of the recording / reproducing device. In addition, the IPL area contains various types of memory information. The TRF region contains information related to blocks (clusters). TRF determines unused blocks, the next block number, defective blocks and the last block number. The root directory area contains the directory entries, which are the file attribute, update date [day, month, year], file size, etc.

Next, with reference to FIG. 6, a control method using the TRF table will be discussed.

6 is a diagram showing a memory card. The top area of the memory card is part of the partition table. After the part of the partition table, there follows the block area, boot sector, TRF area, TRF backup area, root directory area, subdirectory area and data area. On the memory card, the logical addresses were converted to physical addresses corresponding to the logical-physical address translation table.

The boot sector, the TRF area, the TRF backup area, the root directory area, the subdirectory area, and the data area all refer to the TRF partition area.

Part of the partition table contains the start addresses and end addresses of the TRF partition area.

The TRF used for a conventional floppy disk does not contain such a partition table. Since the first record has only a partition table, an empty area is located here. The boot sector contains the size of the TRF structure (12-bit TRF or 16-bit TRF), the cluster size, and the size of each area. TRF is used to control the position of the file recorded in the data area. The TRF copy area is the TRF backup area. The root directory area contains file names, addresses of their initial clusters and their various attributes. The root directory area uses 32 bytes per file.

The subdirectory area is obtained using the directory attribute file, which is written as a directory. In the embodiment of FIG. 6, the subdirectory region has four files, with the names PBLIST.MSF, CAT.MSF, DOG.MSF and MAN.MFA. The subdirectory area is used to control file names and the position of the record in the TRF. In other words, the file segment named CAT.MSF is assigned the address "10" in TRF. The file segment named DOG.MSF is assigned the address "10" in the TRF. The area after cluster 2 is used as the data area. In this embodiment, audio data that has been compressed is recorded in accordance with the ATRAC3 format. The upper segment of the file with the name MAN.MSA is assigned the address "110" in TRF. According to this embodiment of the present invention, the audio data with the file name CAT.MSF is recorded in the cluster 5 to 8. The audio data DOG-1, as the first half of the file with the file name DOG.MSF, is recorded in the clusters 10 to 12. The audio data of DOG-2, as the second half of the file with the file name DOG.MSF, are recorded in clusters 100 and 101. The audio data with the file name MAN.MSF are recorded in clusters 110 and 111.

In this embodiment of the present invention, an example is described in which a separate file is divided into two parts and distributedly recorded. In this embodiment, the “blank” area in the data area is an area to which recording is possible. The area after cluster 200 is used to manage file names. The CAT.MSF file is written to the cluster 200. The DOG.MSF file is written to the cluster 201. The MAN.MSF file is written to the cluster 202. When the file position changes, the area after the cluster 200 is rearranged. When a memory device is attached in the form of a card, the areas of the sections of the beginning and end of the TRF are recorded at the top of the partition table. After the part of the boot sector is played, the area of the root directory and the area of the subdirectory are played. A segment of the playback control information PBLIST.MSF in the sub-directory area is determined. Thus, the address of the final part of the segment of the file PBLIST.MSF is obtained. In this embodiment, since the address “200” is recorded at the end of the PBLIST.MSF file, a reference is made to the cluster 200.

The area after cluster 200 is used to control file playback order. In this embodiment, the CAT.MSA file is the first program. The DOG.MSA file is a second program. The MAN.MSA file is the third program. After a link is made to the area located after cluster 200, a link is made to the file segments CAT.MSA, DOG.MSA and MAN.MSA. 6, the end of the CAT.MSA file segment is assigned the address “5”. The end of the DOG.MSA file segment is assigned the address "10". The end of the MAN.MSA file segment is assigned the address "110". When the TRF searches for the input address with the address "5", the address "6" of the cluster is obtained. When the TRF searches for the input address with the address "5", the address "7" of the cluster is obtained. When the TRF searches for the input address with address "8", the code is "FFF", which indicates the end. Thus, the CAT.MSA file uses clusters 5, 6, 7, and 8. Thanks to the references to clusters 5, 6, 7, and 8 in the data area, ATRAC3 data with the file name CAT.MSA can be accessed.

Next, a method for searching a DOG.MSF file that has been distributed distributed in various places will be described. The end of the DOG.MSA file segment is assigned the address "10". When the TRF searches for the input address with the address "10", the address "11" of the cluster is obtained. When an input address is searched in the TRF with reference to the address "11", the address "12" of the cluster is obtained. When an input address is searched in the TRF with reference to the address "12", the address "101" of the cluster is obtained.

When a reference is made to the address "101", the code is "FFF", which indicates the end. Thus, clusters 10, 11, 12, 100, and 101 are used in the DOG.MSF file. When reference is made to clusters 10, 11, and 12, the first part of the ATRAC3 data of the DOG.MSF file can be accessed. When reference is made to clusters 100 and 101, access to the second part of the ATRAC3 data of the DOG.MSF file can be made. In addition, when an input address with address "110" is searched in the TRF, the address "101" of the cluster is obtained. When a search is made for the address “111” of the TRF entry with the address “101”, the code is “FFF”, which represents the end. Thus, it is obvious that clusters 110 and 111 are used in the MAN.MSA file. As described above, data files distributed in different places of the flash memory can be connected and played back in sequence.

According to this embodiment of the present invention, in addition to a file management system defined in a card type storage device 40, a control file is used to control music recordings and parts of music files. The control file is written to the user block of the flash memory 42 of a memory card type 40. Thus, as will be described below, even if the TRF of the card type storage device 40 is destroyed, the file can be restored.

The control file is generated by the DSP 30. When the power of the recording / reproducing device is turned on, the DSP 30 determines whether or not a memory card type device 40 was connected to the recording / reproducing device. If the card type storage device 40 is connected, the DSP 30 authenticates the card type storage device 40. In the case where the DSP 30 successfully authenticates the memory card type 40, the DSP 30 reads the boot block of the flash memory 42. Thus, the DSP 30 reads the physical-logical address translation table and writes the read data to the RAM. TRF and the root directory were written to the flash memory of a card type storage device 40 before the card 40 was put up for sale. When data is written to a card type memory 40, a control file is generated.

In other words, a write command generated by a remote user controller or similar device is supplied to the DSP 30 from an external controller via the bus and the bus interface 32. The encoding / decoding chip 10 compresses the received audio data and provides the resulting ATRAC3 data to the security chip 20. Security chip 20 decodes ATRAC3 data. The decrypted ATRAC3 data is written to the flash memory 42 of a card type memory 40. After that, TRF and control files are updated. Whenever a file is updated (in fact, whenever the audio data recording process ends), the TRF and control files recorded in the RAM 31 and 36 are overwritten. When the card-type storage device 40 is disconnected, or when the power of the recording / reproducing device is turned off, the TRF and the control file, which are finally supplied from the RAM 31 and 36 and are written to the flash memory 42. Alternatively, whenever the audio recording process is completed , TRF and the control file recorded in flash memory 42 may be overwritten. When audio data is being edited, the contents of the control file are updated.

In the data structure, in accordance with this embodiment, additional information is contained in a control file. Additional information is updated and recorded in flash memory 42. In another data structure of the control file, in addition to the control file of the music recording, an additional information control file is generated. Additional information is supplied from the external controller to the DSP 30 via the bus and the bus interface 32. Additional information is written to the flash memory 42 of a memory card type 40. Since additional information is not supplied to the security chip 20, it is not encrypted. When the card-type storage device 40 is disconnected from the recording / reproducing device, or when its power is turned off, additional information is recorded from the RAM of the DSP 30 to the flash memory 42.

7 is a diagram depicting a file structure in a card type memory 40. This file structure contains a still image directory and a moving image directory, a voice directory, a control directory, and a music (HIFI) directory. According to this embodiment, a music program is recorded and played. Next will be described the music directory. The music directory contains two types of files. The first type is a playback control file BLIST.MSF (hereinafter referred to as PBLIST). Another type is the ATRAC3 data file A3Dnnnn.MSA, which contains encoded music data. Up to 400 ATRAC3 data files (namely 400 music programs) can be recorded in the music directory. ATRAC3 data files are recorded in the playback control file and generated in the recording / reproducing device.

8 is a diagram showing a structure of a reproduction management file. Fig. 9 is a diagram showing the structure of an ATRAC3 data file. The playback control file is a file with a fixed length of 16 KB. The ATRAC3 data file consists of an attribute header and an encoded music data area for each music program. Attribute data has a fixed length of 16 KB. The structure of the attribute header is similar to the structure of the playback control file.

The playback control file shown in FIG. 8 consists of a title, an NM-S name of a card type storage device 40 (for a single byte code), an NM2-S name (a card type storage device for a two byte code), a TRKTBL program sequence table and an additional card-type information INF-S. The attribute header (shown in FIG. 9) located at the beginning of the data file consists of a header, a program name NM1 (for a single-byte code), a program name NM2 (for a two-byte code), music recording information TRKINF (such as music recording key information ), portions of PRTINF information and additional information INF records. The header contains information about the total number of parts, the attribute of the name, the amount of additional information, etc.

The attribute data is followed by the ATRAC3 music data. Every 16 KB of music data is segmented into blocks. Each block begins with a title. The header contains the initial value for decoding the encoded data. Only music data of the ATRAC3 data file is encoded. Thus, other data, such as a playback control file, header, etc. not encoded.

Next, with reference to FIGS. 10A to 10C, the relationship between music programs and ATRAC3 data files is described. One recording is equivalent to one music program. In addition, one music program consists of ATRAC3 data alone (see FIG. 9). An ATRAC3 data file is audio data that has been compressed in accordance with the ATRAC3 format. An ATRAC3 data file is recorded clustered into a card type memory 40. One cluster has a capacity of 16 KB. Many files are not contained in one cluster. The smallest erasable unit of information in flash memory 42 is one block. In the case of a memory card type 40 for music data, the term block is synonymous with a cluster. In addition, one cluster is equivalent to one sector.

One music program mainly consists of one part. However, when a music program is edited, one music program may consist of many parts. A part is a block of data that is recorded sequentially. Usually one record consists of one part. The combination of the parts of the music program is controlled by the PRTINF information of the part in the attribute header of each music program. In other words, the size of the part is represented by the size of the PRTSIZE part (4 bytes) of the information of the PRTINF part. The first two bytes of the size of the PRTSIZE part represent the total number of clusters of the current part. The next two bytes represent the position of the beginning of the sound module (ZM) and the end of the sound module (ZM), indicating the start and end clusters, respectively. Hereinafter, the sound module is abbreviated as ZM. With this designation of the parts, when music data is recorded, the transfer of music data can be suppressed. When music data is edited block by block, although its movement can be suppressed, the editable block module is significantly larger in size than the edited ZM module.

ZM is the minimum module of the part. In addition, ZM is a minimal data module in the case when audio data is compressed in accordance with the ATRAC3 format. 1 ZM is audio data in which the data of 1024 samples at a frequency of 44/1 kHz (1024 × 16 bit × 2 channels) are compressed into data that occupy about 10 times less space than the original data. The duration of 1 ZM is about 23 ms. Usually one part consists of several thousand ZM. When one cluster consists of 42 ZM, one cluster allows you to produce sound in one second. The number of parts making up one record depends on the size of the additional information. Since the number of parts is obtained by subtracting the title, program name, additional data, etc. from one block, in the case when there is no additional information, the maximum number of parts (645 parts) can be used.

10A is a diagram showing a file structure in a case where two music programs of a CD or the like are recorded sequentially. The first program (file) 1 consists, for example, of five clusters. Since one group cannot contain two files of the first program and the second program, file 2 starts from the beginning of the next group. Thus, the end of part 1 corresponding to file 1 is in the middle of one cluster, and the remaining area of the cluster does not contain any data. Similarly, the second music program (file) 2 consists of one part. In the case of file 1, the size of the part is 5. The first cluster begins in the 0th ZM. The last cluster ends in the 4th ZM.

There are four types of editing processes, which are the separation process, the combining process, the erasing process, and the moving process. The splitting process is performed to split one music recording into two parts. When the separation process is performed, the total number of music recordings increases by one. During the splitting process, one file is split into two files in the file system. Thus, in this case, the playback control file and the TRF are updated. The combining process is performed to combine two music recordings into one music recording. When the combining process is performed, the total number of music recordings decreases by one. In the process of combining two files are combined into one file in the file system. Thus, when the combining process is performed, the playback control file and the TRF are updated. The erase process is performed to erase the music recording. The number of music recordings after the music recording is erased is reduced by one. The moving process is performed to change the sequence of the arrangement of music recordings. Thus, when the erasing process or the moving process is performed, the playback control file and the TRF are updated.

FIG. 10B is a diagram showing the result of combining two programs (file 1 and file 2) shown in FIG. 10A. As a result of the combination process, the combined file consists of two parts. On figs presents a diagram depicting the separation result, with which 1 program (file 1) is divided in the middle of cluster 2. As a result of the separation process, file 1 consists of clusters 0, 1, and the initial part of cluster 2. File 2 consists of the remainder of cluster 2 and cluster 3 and 4.

As described above, in accordance with this embodiment of the present invention, since the part designation is defined as a combined result (see FIG. 10B), the initial position of part 1, the final position of part 1, and the final part of part 2 can be defined in 3D. Thus, in order to compress the occupied volume by combining, there is no need to move the music data of part 2. In addition, with respect to the separation result (see FIG. 10C), there is no need to move the data and compress the space at the beginning of file 2.

11 is a diagram showing a detailed data structure of a playback control file PBLIST. 12A and 12B show a portion of the header and the remainder of the playback control file PBLIST. The playback control file size is one cluster (one block = 16 KB). The size of the header shown in FIG. 12A is 32 bytes. The rest of the playback control file PBLIST shown in FIG. 12B contains a namespace NM1-S (256 bytes) (for a memory device such as a card), a namespace NM2-S (512 bytes), a content key area, a MAC area, an S area -YMAhms, an area of the playback sequence control table TRKTBL (800 bytes), an INF-S area of additional card type storage information (14720 bytes), and an excess header information area. The starting position of these areas is defined in the playback control file.

The first 32 bytes from (0 × 0000) to (0 × 0010) depicted in FIG. 12A are used for: a header. In a file, 16-byte areas are designated as segments. On figa the header is placed in the first and second segments. The header contains the following areas. The area designated as “reserve” is an undefined area. Typically, zero (0 × 00) is written in the reserved area. However, even if any data is recorded in the reserved area, this data recorded in the reserved area is ignored. In future versions, some reserved areas may be used. In addition, data is not allowed in the reserved area. When the area used when necessary is not used, it is considered as a reserved area.

= BLKID-TLO (4 bytes)

Means: BLOCKID file identifier

Function: Identifies the top of the playback control file.

Value: Fixed value = "TL = 0" (for example, 0 × 544C2D30)

= Mcode (2 bytes)

Value: MANUFACTURER CODE

Function: Identifies the manufacturer and model of the recorder / player.

Value: Top bit 10 bits (manufacturer code);

lower bit 6 bits (model code).

= REVISION (4 bytes)

Value: Number of times to rewrite PBLIST

Function: Increments by one whenever the playback control file is overwritten.

Value: starts at 0 and increases by 1.

= S-UMDhms (4 bytes) (if necessary)

Value: Year, month, day, hour, minute and second recorded by a recording / reproducing device using a reliable clock.

Function: Identifies the date and time of the last recording.

Value: bits 25 to 31: Year 0 to 99 (1980-2079)

Bits 21 to 24: Month 0 to 12

Bits 16 to 20: Day 0 to 31

Bits 11 to 15: Hour 0 to 23

Bits 05 to 10: Minute 0 to 59

Bits 00 to 04: Second 0 to 29 (two-bit interval)

= SY1C + L (2 bytes)

Value: The name attribute (single-byte code) of a card-type storage device recorded in the NM1-S area.

Function: Represents a character encoding and a language encoding as a single-byte code.

Value: character code: one byte of the highest order

00: Non-character code, binary number

01: ASCII (American Standard Code for Information Interchange)

02: ASCII + KANA

03: modified 8859-1

81: MS - JIS

82: KS S 5601-1989

83: GB (UK) 2312-80

90: S-JIS (Japanese Industry Standard) (for voice)

language code (L): one byte of the lowest order

identifies language based on EBU Tech 3258 standard

00: Not installed

08: German

09: English

OA: Spanish

OF: French

15: Italian

1D: Dutch

65: Korean

69: japanese

75: Chinese

When no data is recorded, 0 is recorded in this entire area.

= SN2C + L (2 bytes)

Value: An attribute of the name of the memory card type in the NM2-S area.

Function: Represents a character encoding and language encoded in single-byte code.

Value: Same as for SN1C + L

= SINFSIZE (2 bytes)

Value: The total size of the additional information of the memory card type in the INF-S area.

Function: Represents the data size as an increment of 16 bytes. When no data is recorded, 0 is recorded in this entire area.

Size: Size: from 0 × 0001 to 0 × 39С (924)

= T-TRK (2 bytes)

Value: Total number of music recordings

Function: Represents the total number of music recordings.

Value: 1 to 0 × 0190 (maximum 400 music recordings)

When data is recorded, 0 is recorded in this entire area.

= VerNo (2 bytes)

Value: Format version number

Function: Represents the major version number (one byte of the upper order) and the number of the minor version (one byte of the lower order).

Value: 0 × 0100 (Version 1.0)

0 × 0203 (Version 2.3)

Next, the areas (see FIG. 13B) that follow the header will be described.

= NM1-S

Value: Name of the memory card type (as a single-byte code)

Function: Represents the name of the memory card type in the form of a single-byte code (maximum value 256). At the end of this area, a (0 × 00) end code is recorded. The size is calculated based on the end code. When no data has been written, zero (0 × 00) is written from the beginning (0 × 0020) of this area in at least one byte.

Value: Different character code

= NM2-S

Value: Name of the memory card type (as a double-byte code)

Function: Represents the name of a memory card type device as a two-byte code (maximum value 512). At the end of this area, a (0 × 00) end code is recorded. The size is calculated based on the end code. When data is not written, zero (0 × 00) is written from the beginning (0 × 0120) of this area with at least two bytes.

Value: Different character code

= CONTENTS KEY

Value: Value for the music program. Protected with Mg (M) and recorded. Just like CONTENTS KEY.

Function: Used as the key needed to calculate the MAC in S-YMAhms.

Value: 0 to 0 × FFFFFFFFFFFFFFFFF

= MAC

Value: Value of check for falsification of copyright protection information

Function: Represents the value produced by S-YMDhms and CONTENTS KEY.

Value: 0 to 0 × FFFFFFFFFFFFFFFFF

= TRK-nnn

Value: SQN (sequence) number of the played ATRAC3 data file.

Function: Represents FNo TRKINF.

Size: 1 to 400 (0 × 190)

When there is no musical recording, this entire area is filled with zeros.

= INF-S

Meaning: Additional information on a storage device such as a card (for example, information that relates to photographs, songs, consultants, etc.)

Function: Represents additional variable-length information with a header. Many types of additional information may be used. Each of the types of additional information contains an identifier ID and a data size. Each area of additional information, including the header, consists of at least 16 bytes and a multiple of 4 bytes. Details are described in the next section.

Value: see the "Data Structure of Additional Information" section.

= S-YМДhms (4 bytes) (if necessary)

Value: Year, month, day, hour, minute and second recorded by the recorder / player using the clock.

Function: Identifies the last recorded date and time. In the case of EMD, this area is mandatory.

Value: bits 25 to 31: Year 0 to 99 (1980 to 2079)

bits 21 to 24: Month 0 to 12

bits 16 to 24: Day 0 to 31

Bits 11 to 15: Hour 0 to 23

bits 05 to 10: minutes 0 to 59

bits 00 to 04: Seconds 0 to 29 (two-second intervals)

In the last segment of the playback control file, the same BLKID-TL0, MCode, and REVISION values are recorded as in the header.

When data is being written to a card-type storage device, it may be accidentally or accidentally disconnected, or the power of the recording / reproducing device may be turned off. In the event of such an incorrect operation, a defect shall be detected. As described above, the REVISION area is located at the beginning and at the end of each block. Whenever data is recorded, the REVISION area is incremented by one. If a recording crashes in the middle of a block, the value of the REVISION area at the beginning of the block will not correspond to the value of the REVISION area at the end of the block.

Due to this, such an emergency shutdown can be detected. Since there are two areas of REVISION, abnormal termination can be detected with high probability. When an abnormal termination is detected, an alarm is generated, such as an error message.

In addition, since a fixed BLKID-TLO value is recorded at the beginning of the block (16 KB), in the case when the TRF is destroyed, this fixed value is used as a reference for recovery data. In other words, by referring to this fixed value, the file type can be determined. Since a fixed BLKID-TLO value is recorded as an excess value in a portion of the header and end of each block, high reliability can be ensured. Alternatively, the same playback control file may be recorded as a redundant file.

The amount of data in the ATRAC3 data file is much larger than in the music information management file. In addition, as will be described later, the BLOCK SERIAL block number is added to the ATRAC3 data file. However, since many ATRAC3 files are written to a card-type memory, both CONNUMO and BLOCK SERIAL are used to avoid redundancy. Otherwise, when the TRF is destroyed, the file will be difficult to recover. In other words, a single ATRAC3 data file can consist of many blocks that are distributed in different places. To identify blocks of the same file, CONNUMO is used. In addition, BLOCK SERIAL is used to identify the block order in the ATRAC3 data file.

Similarly, the manufacturer’s code (Mcode) is redundantly written at the beginning and at the end of each block in order to identify the manufacturer and model in the case when the file is not correctly recorded in the state when the TRF was not destroyed.

On figs presents a diagram depicting the data structure of additional information. Additional information consists of the following header and variable-length data. The header contains the following areas.

= INF

Value: FIELD ID

Function: Represents the beginning of additional information (fixed value).

Value: 0 × 69

= Id

Value: Additional Information Key Code

Function: Represents a category of additional information.

Value: 0 to 0 × FF

= SIZE

Value: Size of individual additional information

Function: Represents the size of each type of additional information. Although the data size is not limited, it should be at least 16 bytes and a multiple of 4 bytes. The rest of the data must be filled with zeros (0 × 00).

Value: from 16 to 14784 (0 × 39CO)

= Mcode

Value: MAKER CODE

Function: Identifies the manufacturer and model of the recording / reproducing device.

Value: 10 bits of the highest order (manufacturer code), 10 bits of the lower order (machine code).

= C + L

Value: An attribute of characters in a data area starting with byte 12.

Function: Represents a character code and language code as a single-byte code.

Value: Same as for SNC + L

= DATA

Meaning: Individual additional information

Function: Represents each type of additional information with variable-length data. Valid data always starts with byte 12. The length (size) of the valid data must be at least 4 bytes and a multiple of 4 bytes. The rest of the data area must be filled with zeros (0 × 00).

Value: It is determined individually in accordance with the contents of each type of additional information.

Fig. 13 is a table in which key code values (from 0 to 63 additional information and their types are correlated. Key code values (0 to 31) are assigned to musical symbol information. Key code values (32 to 63) are assigned to URL ( Unified Index of Information Resource) (World Wide Web Information.) Musical mark information and URL information contain mark information of album name, artist name, SM, etc. as additional information.

On Fig presents a table that shows the correlation of the values of the key code (from 64 to 127) additional information and its types. Key code values (64 to 95) are assigned to paths / others. Key code values (96 to 127) are assigned to control data / digital data. For example, ID = 98 represents TOC-ID as additional information. TOC-ID represents the first number of the music program, the last number of the music program, the number of the current program, the total duration of the performance and the current duration of the music program, in accordance with the TOS CD (CD) information.

On Fig shows a table that shows the correlation of the values of the keys (from 128 to 159) additional information and their types. Key code values (128 to 159) are assigned by synchronous playback information. On Fig EMR means electronic musical distribution.

Next, with reference to FIGS. 16A-16E, real examples of additional information will be described. As in FIG. 12C, FIG. 16A shows a data structure of additional information. On figv code ID 3 key (artist name as additional information). SIZE = 0 × 1C (28 bytes), which represents the length of the additional information data, including the header, equal to 28 bytes; C + L represents that the character code is C = 0 × 01 (ASCII) and L = 0 × 09 of the language (English). Data of variable length after byte 12 represents the data of one byte "SIMON & GRAFUNKEL", which means the name of the artist. Since the data length of the additional information must be a multiple of 4 bytes, the rest is filled (0 × 00).

In FIG. 16C, the key code ID = 97 represents ISRC (International Standard Record Code: Copyright Code) as additional information. SIZE = 0 × 14 (20 bytes), which represents that the data length of the additional information is 20 bytes. C = 0 × 00 and L = 0 × 00 represents that the characters and language have not been set. Thus, this data is binary code. Variable length data is an eight-byte ISRC code representing copyright information (nationality, copyright holder, year of recording, and serial number).

In FIG. 16D, the key code ID = 97 represents the date and time of recording as additional information. The size SIZE = 0 × 10 (16 bytes) represents that the length of the additional information data is 16 bytes. C = 0 × 00 and L = represent that the characters and language have not been set. Variable-length data is a four-byte (32-bit) code representing the date and time of recording (year, month, day, hour, minute, second).

In FIG. 16E, the key code ID = 107 represents the playback protocol as additional information. The size SIZE = 0 × 10 (16 bytes) represents that the length of the additional information data is 16 bytes. C = 0 × 00 and L = 0 × 00 represent that the characters and language have not been set. Variable-length data is a four-byte code representing the playback protocol (year, month, day, hour, minute, second). When the recording / reproducing device has a function of a reproduction protocol, it records data of 16 bytes whenever it reproduces music data.

17 is a diagram depicting the location of data in an ATRAC3 data file A3Dnnnn in the case where 1 SU is N bytes (eg, N = 384 bytes). On Fig shows the attribute header (1 block) of the data file and the music data file (1 block). On Fig shows the first byte (from 0 × 0000 to 0 × 7FF0) of each segment of the two blocks (16 × 2 = 32 kilobytes). As shown in FIG. 18, the first 32 bytes of the attribute header are used as the header; 256 bytes are used as the NM1 area of music programs (256 bytes); and 512 bytes are used as the NM2 area of the music program name (512 bytes). The attribute header header contains the following areas.

= BLKID-HD0 (4 bytes)

Value: Identifier area BLOCKID FIELD ID

Function: Identifies the top of the ATRAC3 data file.

Value: Fixed value = "HD = 0" (For example, 0 × 48442D30)

= MCode (2 bytes)

Value: Manufacturer Code (MAKER CODE)

Function: Identifies the manufacturer and model of the recorder / player.

Value: 10 bits of the highest order (manufacturer code); 6 bits lower order (machine code)

= BLOCK SERIAL (4 bytes)

Value: music sequence number

Function: Starts at 0 and increases by 1. Even if the music program is being edited, this value does not change.

Value: 0 to 0 × FFFFFFFF.

= N1C + L (2 bytes)

Value: Represents the data attribute (NM1) of a music recording (music program name).

Function: Represents the character code and NM1 language code as a single-byte code.

Value: Same as for SN1C + L

= N2C + L (2 bytes)

Value: Represents the data attribute (NM2) of a music recording (music program name).

Function: Represents the character code and NM1 language code as a single-byte code.

Value: Same as for SN1C + L

= INFSIZE (2 bytes)

Value: The total size of the additional information of the current music recording.

Function: Represents the data size as a multiple of 16 bytes. When data is not being written, this area must be completely filled with zeros.

Value: from 0 × 0000 to 0 × 3С6 (966)

= T-PRT (2 bytes)

Value: Total Bytes

Function: Represents the number of parts that make up the current music recording. Typically, the T-PRT value is 1.

Value: from 1 to 285 (645 decimal).

= T-SU (4 bytes)

Value: total amount of ZM.

Function: Represents the total number of ZM in one musical recording, which is equivalent to the duration of the program.

Value: 0 × 01 to 0 × 00lFFFFF

= INX (2 bytes) (if necessary)

Value: Relative position INDEX

Function: Used as a pointer that represents the top of the representative part of the music program. The value of INX is set by a value that represents the number of MPs divided by 4 as the current position of the program. This value of INX is equivalent to a value 4 times greater than the number of ZM (approximately 93 ms).

Value: 0 to 0 × FFFF (maximum approximately 6084 seconds)

= XT (2 bytes) (if necessary)

Value: Duration of playback INDEX

Function: Indicates the playback time specified by the INX-nnn value equal to the number of ZM divided by 4. The INDEX value is equivalent to four times longer than the normal ZM (approximately 93 ms).

Value: 0 × 0000 (no installation); from 0 × 01 to 0 × FFFE (up to 6084 seconds); 0 × FFFF (until the end of the music program) I:

Next will be described area NM1 and NM2 of the name of the music program.

= NM1

Value: character string of the name of the music program

Function: Represents the name of a music program as a single-byte code (up to 256 characters) (variable length). The namespace must be completed with a code (0 × 00) ending. The size should be calculated from the end code. When no data has been written, zero (0 × 00) should be written from the beginning (0 × 0020) of the area in at least one byte.

Value: Various character codes

= NM2

Value: character string of the name of the music program

Function: Represents the name of the music program as a double-byte code (up to 512 characters) (variable length). The namespace must be completed with a code (0 × 00) ending. The size should be calculated from the end code. When data is not being written, zero (0 × 100) must be written from the beginning (0 × 0120) of the area with at least two bytes.

Value: Various character codes

Data of 80 bytes, starting from the fixed position (0 × 320) of the attribute header, is designated as the TRKINF area of music information. This area is mainly used for general management of security information and copy control information. 19 shows a portion of TRKINF. The TRKINF area contains the following areas.

= CONTENTS KEY (8 bytes)

Meaning: The size of each music program. The value of the CONTENTS KEY is protected in the security unit of the memory card type and is then recorded.

Function: Used as a key to play a music program. It is used to calculate the magnitude of the MAC.

Value: 0 to 0 × FFFFFFFFFFFFFFFFF

= MAC (8 bytes)

Value: The amount of verification of copyright forgery information

Function: Represents a value generated with a variety of TRKINF values, including collected content numbers and secret sequence number.

A secret sequence number is a sequence number recorded in a secret area of a card type storage device. At the same time, a storage device of this type, which does not contain protection against the use of fake copyrights, cannot read data from the secret area of a storage device such as a card. On the other hand, a recording device of this type, in which copyright is protected and a computer that works with a program that can read data from a memory device such as a card, can access a secret area.

= A (1 byte)

Value: Attribute of the part.

Function: Represents information such as part compression mode.

Value: Details will be described below (see FIGS. 19 and 20).

The value of region A will be described below. In the following description, monophonic mode (N = 0 or 1) is defined as a special connection mode in which bit 7 = 1, sub-signal = 0, main signal = (L + R). A player of this type, which does not provide protection against fake copyright, can ignore the information recorded in bits 2 and 1.

Bit 0 of area A represents information representing the on / off position. Bit 1 of region A represents skip information or normal playback information. Bit 2 of area A represents data type information such as audio data, FAX data, etc. Bit 3 of area A is undefined. Using a combination of bits 4, 5, and 6, ATRAC3 mode information is determined as shown in FIG. In other words, N represents a mode value of 3 bits. For the five types of modes, which are monaural (N = 0 or 1), LP slow-speed playback (N = 2), SP standard playback (N = 4), EX advanced mode (N = 5), and high-quality HQ mode (N = 7) the recording duration (only for a memory device such as a card with a capacity of 64 MB), data transfer rate and the number of memory per block are presented in a list. The number of bytes per 1 MP depends on each mode. The number of bytes 1 ZM in monaural mode is 136 bytes. The number of bytes of 1 GP in LP mode is 192 bytes. The number of bytes of 1 GP in SP mode is 304 bytes. The number of bytes of 1 ZM in EX mode is 384 bytes. The number of bytes of 1 ZM in HQ mode is 512 bytes. Bit 7 of region A represents ATRAC3 (0: Dual, 1: Connected) (0: Dual, I: Joint).

For example, an example will be described in which a memory device such as a 64 MB card in SP mode is used. A 64 MB card contains 3968 blocks. In SP mode, since 1 memory is 304 bytes, one block contains 53 memory. 1 GP is equivalent to (1024/44100) seconds. Thus, one block is (1024/44100) × 53 × (3968-10) = 4863 seconds = 81 minutes. The transmission speed is (44100/1024) × 304 × 8 = 104737 bps.

= LT (one byte)

Value: play restriction flag (bits 7 and 6) and security section (bits 5 to 0).

Function: Represents a limitation of the current music recording.

Value: bit 7: 0 = no limit, 1 = limited

Bit 6: 0 = not expired, 1 = expired

Bits 5 to 0: security section (playback prohibited for any value other than 0)

= FNo (2 bytes)

Value: File number.

Function: Represents the originally recorded music number, which indicates the position of the MAC count value recorded in a secret area in a card-type storage device.

Size: 1 to 0 × 190 (400)

= MG (D) serial number SERIAL-nnn (16 bytes)

Value: Represents the serial number of the security unit (security chip 20) of the recording / reproducing device.

Function: Unique value for each recording / reproducing device.

Value: 0 to 0 × FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

= CONNUM (4 bytes)

Value: Content Accumulation Number

Function: Represents the unique value accumulated for each music program. The value is controlled by the safety unit of the recording / reproducing device. The upper limit of the value is 2 ³² , that is 4 200 000 000. It is used to identify the recorded program.

Value: 0 to 0 × FFFFFFFF

YMDhms-S (4 bytes) (if necessary)

Value: Date and time that the music recording began to be played with playback restriction

Function: Represents the date and time at which EMD data playback is allowed.

Value: Same as in date and time in other areas

= YMDhms-E (4 bytes) (if necessary)

Value: End date and time of music recording with playback limitation

Function: Represents the date and time at which data playback expires on EMD.

Value: Same as in date and time in other areas

= MT (1 byte) (if necessary)

Value: Maximum number of times allowed to play

Function: Represents the maximum number of play times specified by EMD.

Value: 1 to 0 × FF. When the value of the MT region is not used, it is 00.

= ST (1 byte) (if necessary)

Value: Number of times to play

Function: Represents the number of play times in the number of allowed play times. Whenever data is reproduced, the size of the CT region decreases by 1.

Value: 0 × 00 to 0 × FF. When not used, the value of the CT region is set to 0 × 00. When 1 is recorded in bit 7 of the LT region, the value of the CT region is 00, this data is prohibited for playback.

= SS (1 byte)

Value: Copy Control COPY CONTROL

Function: Controls the copy operation.

Value: bits 6 and 7 represent information regarding copy control, bits 4 and 5 represent information related to copy control during a high speed digital copy operation, bits 2 and 3 represent the authentication level of the security unit, bits 0 and 1 are not defined.

SS example:

(bits 7 and 6)

11: Unlimited copying allowed

01: copying prohibited

00: one copy operation is allowed (bits 3 and 2)

00: analog / digital authentication level

input record MG is 0.

When a digital recording operation is being performed using data from the CD, (bits 7 and 6): 00 and (bits 3 and 2): 00.

= CN (1 byte) (if necessary)

Value: Number of allowed copy times in a system with high speed sequential copy control

Function: Extends the copy resolution with respect to the number of times it is copied, not limited to the copy permission once and the permission for free copying. Valid only in the first copy generation. The size of the CN region decreases by one whenever a copy operation is performed. Value:

00: Copying prohibited

01 to 0 × FE: Number of times

0 × FF: Unlimited copy times

After the TRKINF area of the music recording information, there follows the (PRTINF) area of the control information of the 24-byte part, which starts at 0 × 0370. When a single musical recording consists of many parts, the values of the PRTINF areas of each individual part are sequentially located on the time axis. On Fig depicts a portion of the PRTINF region. Next, the areas in the PRTINF area in order will be described.

= PRTSIZE (4 bytes)

Value: Part Size

Function: Represents the size of the part.

Cluster: 2 bytes (high order), start of memory: 1 byte (high), end of memory: 1 byte (low order).

Value: cluster: from 1 to 0 × 1F40 (8000)

beginning of ZM: from 0 to 0 × AO (160)

end of ZM: from 0 to 0 × AO (16) (Note that ZM starts at 0)

= PRTKEY (8 bytes)

Value: Part Coding Value

Function: Encodes a part.

Initial value = 0. Note that you must apply the editing rules.

Value: 0 to 0 × FFFFFFFFFFFFFFFFF

= CONNUMO (4 bytes)

Value: Initially generated content accumulation number key

Function: Uniquely describes the identifier of the content ID.

Value: The same value as the key value of the initial value of the content accumulation number.

As shown in FIG. 17, the ATRAC3 data file attribute header contains additional INF information. The additional information is the same as the additional information INF-S (see FIGS. 11 and 12B) of the playback control file, except that the initial position is not fixed. The position of the last byte (a multiple of four bytes) at the end of one or many parts is followed by additional information INF.

= INF

Meaning: Additional information related to the music recording

Function: provides additional variable-length information with a header. Many different types of additional information can be posted. Each of the areas of additional information has an identifier ID and data size. Each area of additional information consists of at least 16 bytes and a multiple of 4 bytes.

Value: Same as additional information of the INF-S playback control file.

After the attribute header described above, data of each block of the ATRAC3 data file is followed. As shown in FIG. 23, a header is added to each block. Next, the data of each block will be described.

= BLKID-A3D (4 bytes)

Value: BLOCKID FILE ID

Function: Identifies the top of the ATRAC3 data.

Value: Fixed value = "A3D" (for example, 0 × 41334420)

= MCode (2 bytes)

Value: Manufacturer Code (MAKER CODE)

Function: Identifies the manufacturer and model of the recorder / player.

Value: 10 bits of the highest order (manufacturer code); 6 bits of the least significant bit (model code)

= CONNUMO (4 bytes)

Value: Accumulated amount of originally created content

Function: Identifies the unique identifier for the content ID. Even if the content is edited, the size of the CONNUMO area does not change.

Value: Same as for the contents of the original key of the accumulation number

= BLOCK SERIAL (4 bytes)

Value: Sequence number assigned to each music entry

Function: Starts at 0 and increments by 1. Even if the contents are edited, the value of the BLOCK SERIAL area does not change.

Value: 0 to 0 × FFFFFFFF

= BLOCK-SEED (8 bytes)

Value: Key to encode one block

Function: The beginning of the block is a random value that is generated by the security unit of the recording / reproducing device. This random value is followed by a value that increases by 1. When the value of the BLOCK-SEED area is lost because sound is not produced for about one second, which is equivalent to one block, the same data will be written to the header and to the end of the block. Even if the contents are edited, the value of the BLOCK-SEED block does not change.

Value: Original 8-bit random number = INITIALIZATION VECTOR (8 bytes)

Value: Value required for encoding / decoding ATRAC3 data

Function: Represents the initial value needed to encode and decode ATRAC3 data for each block. The block starts at 0. The next block starts with the last encoded 8-bit value in the last GP. When a block is split, the last eight bytes are used immediately before the start of the block. Even if the contents are edited, the size of the INITIALIZATION VECTOR area does not change.

Value: 0 to 0 × FFFFFFFFFFFFFFFFF

= SU-nnn

Value: Sound Module Data

Function: Represents data compressed from 1024 samples. The number of bytes of output depends on the compression mode. Even if the content is edited, the size of the SU-nnn area does not change. For example, in SP mode, N = 384 bytes.

Value: ATRAC3 data value

On Fig, since N = 384, 42 ZM are recorded in one block. The first two segments (4 bytes) of one block are used as a header. In the last segment (two bytes), the BLKID-A3D, MCode, CONNUMO, and BLOCK SERIAL regions are written as redundant information. Thus, M bytes of the remaining area of one block are (16 384 - 384 × 42 - 16 × 3 = 208) bytes. As described above, a BLOCK SEED area of eight bytes is recorded as redundant information.

When the TRF region is destroyed, a search is made for all flash memory blocks. It is determined whether the value of the BLKID region at the beginning of each block is TL0, HD0, or A3D. As shown in FIGS. 24A-24C, in step SP1, it is determined whether or not the value of the BLKID area at the beginning of the BLKID-TLO block is equal. If the result in step SP1 is "No", go to step SP2. At step SP2, the block number is incremented by one. After that, in step SP3, it is determined whether the last block was found.

If the result in step SP3 is “No,” they are returned to step SP1.

If in step SP1, the result is determined to be “Yes”, proceed to step SP4. At step SP4, it is determined that the block that was searched is a playback control file PBLIST. After that, go to step SP5. In step SP5, the total number of T-TRK music entries in the playback control file PBLIST is recorded as N in the register. For example, when 10 ATRAC3 data files (10 music programs) are recorded in memory, the number 10 is written to T-TRK.

Then, with reference to the total number of T-TRK music recordings, a sequential reference is made to TRK-001 to TRK-400 blocks. In this example, since 10 music programs were recorded, reference is made to blocks from TRK-001 to TRK-010. Since the FNO file number was recorded in TRK - XXX (where X = 1 to 400) in step SP7, a table is recorded in the memory that correlates the TRK - XXX number of the music record and the FNO file number. Next, in step SP8, the number N recorded in the register is reduced by one. The cycle consisting of steps SP6, SP7 and SP8 is repeated until N becomes equal to 0 in step SP9.

If the result determined in step SP9 is determined to be "Yes", go to step SP10. At step SP10, the pointer is reset to the top of the block. The search process is repeated from the top of the block. Then, the flow is passed to step SP11. At step SP11, it is determined whether or not the value of the region ID BLKID of the top of the block BLKID-HDO is equal. If the determined result in step SP11 is “No”, proceed to step SP12. At step SP12, the block number is incremented by one. At step SP13, it is determined whether the last block was found or not.

If the result in step SP13 is “No,” they are returned to step SP11. The search process is repeated until the result in step SP11 becomes “Yes”.

If the result in step SP11 is “Yes”, go to step SP14. At step SP14, it is determined that the block is the attribute header (see FIG. 8) (0 × 0000 to 0 × 03FFF, as shown in FIG. 18) at the beginning of the ATRAC3 data file.

Then, in step SP15, with reference to the FNO file number, the BLOCK SERIAL sequence number of the same ATRAC data file, and the CONNUMO key of the content accumulation number contained in the attribute header is recorded in the memory. When 10 ATRAC3 data files have already been written, since there are 10 blocks for which the value of the BLKID ID area in the upper block is BLKID-TLO, the search process continues until 10 blocks are found.

If the result determined in step SP13 is “Yes”, go to step SP16. At step SP16, the pointer is reset to the top of the block. The search process is repeated from the top of the block.

Then go to step SP17. At step SP17, it is determined whether or not the value of the region ID BLKID of the vertex of the block BLKID-A3D is equal.

If the result determined in step SP17 is “No”, go to step SP18. At step SP18, the block number is incremented by one. After that, at step SP18 ’, it is determined whether the last block was found or not. If the result determined in step SP18 ’is“ No, ”they are returned to step SP17.

If the result determined in step SP17 is “Yes”, proceed to step SP19. In step SP19, it is determined that the block contains ATRAC3 data. After that, go to step SP20. At step SP20, with reference to the BLOCK SERIAL sequence number recorded in the ATRAC3 data unit, and to the CONNUMO key of the content accumulation number, they are recorded in the memory.

In the same ATRAC3 data file, a common number is assigned to the CONNUMO key of the content accumulation number. In other words, when one ATRAC3 data file consists of 10 blocks, a common number is assigned to all CONNUMO area values.

In addition, when the ATRAC3 data consists of 10 blocks, serial numbers from 1 to 0 are assigned to the BLOCK SERIAL area values of 10 blocks.

In accordance with the values of the CONNUMO and BLOCK SERIAL areas, it is determined whether the same content and the playback order of the current block are composed in the same content (namely, the connection sequence) in the current block.

When 10 ATRAC3 data files (namely, 10 music programs) are recorded, and each of the ATRAC3 data files consists of 10 blocks, 100 data blocks are obtained.

With reference to the sizes of the CONNUMO and BLOCK SERIAL areas, the order of playing music programs from 100 data blocks and the order of their connection can be obtained.

When the result determined in step SP19 is “Yes,” all blocks of the playback control file, ATRAC3 data file, and attribute file are searched. Thus, in step SP21, based on the values of the CONNUMO / BLOCK SERIAL, FNO, and TRK-X areas in the order of block numbers, blocks recorded in the memory, a file connection state is obtained.

After the file connection status is obtained, TRF can be generated in the free memory area.

Next, a control file according to a second embodiment of the present invention will be described. 25 shows a file structure in accordance with a second embodiment of the present invention. With reference to FIG. 25, the music directory contains music recording information management file TRKLIST.MSF (hereinafter referred to as TRKLIST), backup music information management file TRKLISTB.MSF (hereinafter referred to as TRKLISTB), additional information file INFLIST.MSF (which consists from the artist’s name, ISRC code, time stamp, still image data, etc. (this file is designated as INFIST)), the ATRAC3 data file A3Dnnnn.MSF (hereinafter referred to as A3nnnn). The TRKLIST file consists of two areas NAME1 and NAME 2. Area NAME1 is an area that contains the name of a memory device such as a card and the name of the program (for a single-byte code corresponding to the ASCII / 8859-1 character encoding system). Area NAME2 is an area that contains the name of the memory card type and the name of the program (for a two-byte code corresponding to MS-JIS / Hankul / Chinese code).

FIG. 26 shows the relationship between the music recording information management file TRKLIST, the regions NAME1 and NAME2, and the ATRAC3 data file A3Dnnnn. The TRKLIST file is a fixed-length file of 64 kilobytes (= 16K × 4). An area of 32 kilobytes of this file is used to manage music recordings. The remaining 32 kilobyte area is used for areas NAME1 and NAME 2. Although the areas NAME1 and NAME2 for the program name can be located in a different file than in the music information management file, it is convenient to use general file management in a system with a small storage capacity management of music recording information and program name files.

The music recording information area TRKINF-nnnn and part of the music recording information management file information PRTINF-nnnn area are used to manage the data file A3Dnnnn and additional INFLIST information. Only the ATRAC3 data file A3Dnnnn is encoded. 26, the data length in the horizontal direction is 16 bytes (0 to F). The hexadecimal digit in the vertical direction represents the value at the beginning of the current line.

According to a second embodiment, three files are used, which are a music recording management file TRKLIST, (including a program name file), additional information management file INFLIST, and data management file A3Dnnnn. According to the first embodiment (see FIGS. 7, 8 and 9), two files are used, which are a playback control file PBLIST for controlling an entire memory device such as a card, an ATRAC3 data file for recording programs.

Next, a data structure according to a second embodiment will be described. To simplify the data structure according to the second embodiment, a description of blocks similar to the corresponding blocks of the first embodiment will be omitted.

FIG. 27 shows a detailed structure of a music recording information management file TRKLIST. In the TRKLIST file for managing music recording information, one cluster (block) consists of 16 kilobytes. The size and date of the TRKLISTB file are the same as the size and date of the TRKLISTB file. The first 32 bytes of the music information management file are used as a header. As with the playback control PBLIST file header, the TRKLIST file header contains the BLKID-TL0 / TL1 region (4 bytes) (backup ID file ID), the T-TRK region (2 bytes) for the total number of music records, the manufacturer’s MCode region (2 bytes), the REVIZION area (4 bytes) the number of times the TRKLIST was overwritten, and the S-YMDhms area (4 bytes) (if necessary) for the date and time of the update. The meaning and functions of these data areas are the same as the meaning and functions of similar data in the first embodiment. In addition, the TRKLIST file contains the following areas.

= YMDhms (4 bytes)

Represents the date (year, month, day) of the last update of the TRKLIST file.

= N1 (1 byte) (if necessary)

Represents the serial number of a card-type storage device (numbering side). When a single card type memory device is used, the value of the region N1 is 0 × 01.

= N2 (1 byte) (if necessary)

Represents the serial number of a card type storage device (denominator side). When a single card type memory device is used, the value of the region N2 is set to 0 × 01.

= MSID (2 bytes) (if necessary)

Represents a card type storage ID. When multiple card type storage devices are used, the magnitude of the MSID area of each card type storage device is the same B.O. (T.B.D). (B.O.'s designation (to be determined) represents that this quantity should be determined in the future).

= S-TRK (2 bytes).

Represents a special musical recording (B.O.). Typically, the value of the STRK region is set to 0 × 0000.

= PASS (2 bytes) (if necessary)

Represents a password (B.O.).

= APP (2 bytes) (if necessary)

Represents the definition of a playback application (B.O.). (usually the value of the APP region is set to 0 × 0000).

= INF-S (2 bytes) (if necessary)

Represents a pointer to additional information for the entire memory card type. When there is no additional information, the value of the INF-S area is set to 0 × 00.

The last 16 bytes of the TRKLIST file are used for the BLKID-TLO region, the MCode region, and the REVISION region, which are the same as in the header. The backup TRKLISTB file contains the above header. In this case, the header contains the BLKID-TL1 region, the MCode region, and the REVISION region.

After the header, there is a TRKINF area for music information intended for information that corresponds to each music record and a PRTINF area for information part for information that corresponds to each part of music recordings (music programs). On Fig depicts the area that follows the area TRKLIST. The lower part of the TRKLISTB area shows the detailed structure of these areas. 27, the hatched region represents an unused region.

The music recording information region TRKINF-nnn and the part information region PRTINF-nnn comprise regions of an ATRAC3 data file. In other words, the music information information region TRKINF-nnn and the part information information region PRTINF-nnn comprise a playback restriction flag region LT (1 byte), a content key CONTENTS KEY region (8 bytes), a security block sequence number MG (D) SERIAL a recording / reproducing device (16 bytes) and an XT area (2 bytes) (if necessary) to represent part of the characteristic of a music program, an INX area (2 bytes) (if necessary), a YMDhms-S area (4 bytes) (if if necessary), area YМДhms-Е (4 bytes) (if necessary i), MT region (1 byte) (if necessary), CT region (1 byte) (if necessary), SS region (1 byte) (if necessary), CN region (1 byte) (if necessary) (these areas YМДhms-S, YМДhms-Е, МТ, СТ, СС and CN are used for information related to playback restriction and information related to copy control), area A (1 byte) for part attribute, PRTSIZE area for part size (4 bytes), the PRTKEY area of the part key (8 bytes) and the CONNUM area of the content accumulation number (4 bytes). The values, functions and values of these areas are the same as the values, functions and values of these areas in the first embodiment. In addition, the music recording information area TRKINF-nnn and the part information area PRTINF-nnn contains the following areas.

= TO (1 byte)

Fixed value (T0 = 0 × 74)

= INF-nnn (if necessary) (2 bytes)

Represents a pointer to additional information (from 0 to 409) for each musical recording. 00: music program without additional information.

= FNM-nnn (4 bytes)

Represents the file number (0 × 0000 to 0 × FFFF) of an ATRK3 data file.

The nnnn number (ASCII encoded) of the name (A3Dnnnn) of the ATRAC3 data file is converted to 0 × nnnnn.

= APP_CTL (4 bytes) (if necessary)

Represents an application parameter (T.B.D). (Typically, the value of the APP_CTL region is set to 0 × 0000).

= P-nnn (2 bytes)

Represents the number of parts (1 to 2039) that make up a music program. This region corresponds to the above-described T-PART region.

= PR (1 byte)

Fixed value (PR = 0 × 50).

Next, the areas NAME1 (for single-byte code) and NAME2 (for double-byte code), which are intended for name management, will be described. On Fig shows a detailed structure of the area NAME1 (for single-bit coding area). Each of the areas NAME1 and NAME2 (which will be described below) is segmented into eight bytes. Thus, one segment of these areas consists of eight bytes. At 0 × 8000, that is, at the beginning of each of these areas, a header is placed. After the title is followed by a pointer and a title. The last segment of region NAME1 contains the same regions as the header.

= BLKID-NM1 (4 bytes)

Represents the contents of a block (fixed value) (NM1 = 0 × 4E4D2D31).

= PNMI-nnn (4 bytes) (if necessary)

Represents a pointer to an NM1 region (for single-byte code).

= PNM1-S

Represents a pointer to a name representing a card-type storage device.

nnn (= 1 to 408) represents a pointer to the name of the music program.

This pointer represents the initial position (2 bytes) of the block, the type of character encoding (2 bits), and the data size (14 bits).

= NMl-nnn (if necessary)

Represents the name of a card-type storage device and the name of a music program for a single-byte code (variable length). The end code (0 × 00) is written at the end of this area.

On Fig shows a detailed data structure, the area NAME2 (for a two-byte code). At 0 × 8000, which represents the beginning of the area, a header is placed. After the title is followed by a pointer and a title. The last segment of the NAME2 region contains the same regions as the header.

= BLKID-NM2 (4 bytes)

Represents the contents of a block (fixed value) (NM2 = 0 × 4E4D2D32).

= PNM2-nnn (4 bytes) (if necessary)

Represents a pointer to an NM2 region (for double-byte code).

PNM2-S represents a pointer to a name representing a card-type storage device, nnn (= 1 to 408) represents a pointer to a name of a music program.

The pointer represents the initial position (2 bytes) of the block, the type of character encoding (2 bits), and the data size (14 bits).

= NM2-nnn (if necessary)

Represents the name of a card-type storage device and the name of a music program for a double-byte code (variable). The end code (0 × 0000) is written at the end of this area.

On Fig shows the layout of the data (for one block) file A3Dnnnn data ATRAC3, in the case when 1 ZM consists of N bytes. In this file, one segment consists of eight bytes. On Fig shows the value of the upper part (from 0 × 0000 to 0 × 3FF8) of each segment. The first four file segments are used for the header. The header is placed in the same way as in the case with the data block following the header of the data file attribute (see Fig. 17) in the first example. The header consists of the BLKID-A3D area (4 bytes), the manufacturer code MCode area (2 bytes), the BLOCK SEED area (8 bytes) necessary for the encoding process, the CONNUMO area (4 bytes) for the original content accumulation number, the BLOCK SERIAL serial number numbers (4 bytes) for each music recording and the INITIALIZATION VECTOR area (8 bytes) required for the encoding / decoding process. The second last block segment redundantly contains the BLOCK SEED area. The last segment contains the BLKID-A3D and MCode regions. As in the case of the first embodiment, after the header is followed by the data PM-nnnn of the sound module.

On Fig shows a detailed data structure of the file INFLIST control additional information that contains additional information. In the second embodiment, at the beginning (0x0000) of the INFLIST file, the following header is placed. Following the heading is the next pointer and area.

= BLKID-INF (4 bytes)

Represents the contents of a block (fixed value) (INF = 0 × 494E464F).

= T-DAT (2 blocks)

Represents the total number of data areas (0 to 409).

= MCode (2 bytes)

Represents the manufacturer / recorder code

= YMDhms (4 bytes)

Represents the date and time the record was updated.

= INF-nnnn (4 bytes)

Represents a pointer to the DATA area of additional information (variable length with a change of 2 bytes (segment) at a time). The initial position is represented by the upper bit 16 bits (from 0000 to FFFF).

= DataSlot-0000 (0 × 0800)

Represents the amount of displacement from the beginning (one segment at a time).

The data size is represented by the low-order bit of 16 bits (from 0001 to 7FFF). The inhibit flag is set in the most significant bit MSB = 0 (enable), MSB = 1 (disable)

The data size represents the total amount of music program data.

(Data starts from the beginning of each segment. (A segment area that is not a data area is populated with 00).

The first INF represents a pointer to additional information for the entire album (usually INF-409).

On Fig shows the structure of additional information. An 8-byte header is located at the beginning of the additional information data area. The structure of the additional information is the same as the structure in the first embodiment (see FIG. 12C). In other words, the additional information contains an IN area (2 bytes) as an ID identifier, an area key ID code (1 byte), a SIZE size area (2 bytes) that represents the size of each additional information area, and a manufacturer code area MCode (2 bytes) . In addition, the additional information contains the SID area (1 byte), which is a sub ID.

According to a second embodiment of the present invention, in addition to a file system defined as a card type storage format, a music information or music data management file TRKLISSR is used. Thus, even if the TRF is destroyed, the file can be restored. 33 shows a file recovery process. To restore the file, a connected computer is used that works with the file recovery program and which can access a storage device such as a card and storage device (hard disk, RAM, etc.). The computer is configured to perform a function equivalent to the DSP30. Next, a file recovery process using a music recording management file TRKLIST will be described.

A search is made of all flash memory blocks whose TRF has been destroyed for the presence of TL-0, as the values (BLKID) in the upper position of each block. In addition, all blocks are searched for the presence of NM-1, as a quantity (BLKID) located in the upper position of each block. After that, a search is made of all blocks for the presence of NM-2 as a quantity (BLKID) located in the upper position of each block. The entire contents of the four blocks (music information management file) is recorded, for example, on the hard disk of the computer performing the recovery.

The total number of music records is obtained from the data following the fourth byte of the music information management file. The 20th byte of the music recording information area TRKINF-001, the size of the CONNUM-001 of the first music program, and the value of the next area of P-001 are obtained. The number of parts is obtained with the size of the region P-001. The values of the PRTSIZE regions of all parts of the record 1 of the PRTINF region are obtained. Calculates and gets the total number of blocks (clusters) n.

After the music recording information management file is received, the flow proceeds to step 102. At step 102, a voice data file is searched (ATRAC3 data file). All blocks that are not a control file in flash memory are searched. Blocks are assembled whose upper value (BLKID) is A3D.

A search is made for a block in which the value of the CONNUMO region in the 16th byte A3Dnnnn is the same as the value of the CONNUM-001 region of the first music program of the music information management file and in which the value of the BLOCK SERIAL region, which starts with the 20th byte, equals 0. After the first block is received, a block (cluster) is searched with the same value of the CONNUM area as the first block, and in which the BLOCK SERIAL value is increased by 1 (1 = 0 + 1). After the second block is received, a block is searched with the same value of the CONNUMO region as the second block and in which the value of the BLOCK SERIAL region increases by 1 (2 = 1 + 1).

By repeating this process, a search is performed in the ATRC3 data file until n blocks (clusters) of music record 1 are received. When all blocks (clusters) are received, they are sequentially written to the hard disk.

The same process as for music recording 1 is performed for music recording 2. In other words, a block is searched in which the value of the CONNUMO region is the same as the value of the CONNUM-002 region of the first music program of the music information management file and, in where the value of the BLOCK SERIAL region begins in the 20th byte. After that, in the same way as for music record 1, a search is performed in the ATRAC3 data file until the last block (cluster) n ’is detected. After all the blocks (clusters) are received, they will be sequentially written to the hard drive.

By repeating the above process for all music recordings (number of music recordings: m), all ATRAC3 data will be written to the hard drive under the control of the computer performing the recovery.

At step 103, a memory device of the type of card whose TRF has been destroyed will be reinitialized and then the TRF will be restored. A predetermined directory is formed in a memory card type device. After that, the music recording information management file and the ATRAC3 data file for m music recordings are copied from the hard disk to a card-type storage device. This completes the recovery process.

In the control file and data file, important parameters (in particular, codes in the headers) can be written not three times, but three times. When data is written with redundancy, the same data can be written in any position until then, provided that they are separated by one another for one or more pages.

Combination process

Next will be described the process of combining files (music program) and the separation process using the file management method in accordance with the first embodiment of the present invention (see Fig. 4 to 24).

Combination process in TRF

Next, the combination process in the TRF will be described. In this case, two CAT.MSA and MAN.MSA files from three files (music programs) CAT.MSA, DOG.MSA and MAN.MSA are combined.

As shown in FIG. 34, when the user combines the two files into one file, the write address at the end of the cluster management data in the TRF corresponding to the CAT.MSA file changes from “FFF” to the starting address “110” in the TRF corresponding to the MAN file. MSA (see shaded part in FIG. 34).

Thus, clusters 5, 6, 7, 8, 110, and 111 are used in the combined CAT.MSA file. In addition, the MAN.MSA file name is deleted from the subdirectory area. In addition, the MAN.MSA file name managed by the cluster 202 is erased (see the shaded part in FIG. 34).

Attribute Header Editing

In the previous section, the editing method in TRF was described, designed to combine two CAT.MSA and MAN.MSA files. Next, with reference to FIGS. 35A and 35B, a method for editing the attribute headers of the playback control file PBLIST.MSF shown in FIG. 11 and the ATRAC3 data file shown in FIG. 17 will be described.

Fig. 35A is a diagram showing a memory card of two files CAT.MSA and MAN.MSA that have not been edited.

The memory card shown in FIG. 35A depicts a state in which logical addresses have been converted to physical addresses. In addition, although the parts are distributed in memory, they are arranged in series to simplify the description. As shown in FIG. 35A, the attribute file of the CAT.MSA file contains the total number of T-SU sound modules: 100, the total number of T-PRT parts: 3, the content key, MAC and part size and part key for each part.

On the other hand, the MAN.MSA file attribute file contains the total number of T-SU sound modules: 70, the total number of T-PRT parts: 2, the content key, MAC and part size, as well as the part key for each part, and the accumulation number CONNUMO content.

The CAT.MSA file attribute file data is updated as follows.

Actually, as the data that needs to be updated when music programs are combined, the number of parts of a single file increases. Thus, the T-PRT contained in the attribute file is edited. In addition, since the file area is combined, the total number of sound modules increases. Thus, the T-SU is edited.

In other words, as shown in FIG. 35B, the T-SU value is written to address 170, to which the total number of T-SU sound modules: 100 of the CAT.MSA file and the total number of T SU: sound modules of the MAN.MSA file are added. In addition, the T-PRT value is written to address 5, which adds the total number of T-PRT parts: 3 CAT.MSA files and the total number of T-PRT parts: 2 MAN.MSA files.

In addition, when the ATRAC3 (music program) data files are combined, the content keys located in the attribute keys are recreated. In addition, the MAC is changed, which is the value of the copyright forgery check.

In addition, the part information (see FIG. 22) contained in the attribute file block of the combined file MAN.MSA is changed (copied) to the file attribute block of the CAT.MSA file. In addition, the PRTKEY of each part contained in the block of the attribute file into which the part of the information was added is re-encoded with a new content key.

As shown in FIG. 9, since the attribute file is added to the header part of the ATRAC3 data file, if the two ATRAC3 data files are simply combined, the attribute block of the CAT.MSA file, the multiple ATRAC3 data blocks of the CAT.MSA file, the attribute block of the MAN file. The MSA and the multiple ATRC3 data blocks of the MAN.MSA file are sequentially combined. Thus, one file will have two attribute files.

To solve this problem, in accordance with the present invention, when the combination process is performed, as shown in FIG. 35B, the attribute file of the data file constituting the second part (in the embodiment, the MAN.MSA file) is updated.

Thus, a block of an attribute file of a CAT.MSA file, a plurality of ATRAC3 data blocks of a CAT.MSA file and a plurality of ATRAC3 data blocks of a MAN.MSA file are sequentially placed.

Edit Playback Control File

In addition, in the playback control file PBLIST shown in FIG. 11, since the data files are combined, the total number of music recordings is reduced by one. Thus, the T-TRK is edited so that they move in the direction of TRK-001 without a gap.

Combining process steps

On Fig shows a program algorithm depicting the process of combining files. At step SP201, the user selects two files that will be combined in a predetermined manner. In this embodiment, the user selects the CAT.MSA and MAN.MSA files. At step SP202, the communication state of the TRF is edited. At step SP203, the name of the file that has links in the opposite direction is deleted from the subdirectory. At step SP204, the name of the data file that is combined in the opposite direction is erased from the data area. In step SP205, the ATRAC3 data file on the front side is updated in accordance with the attribute file of the second ATRAC3 data part. As described above, the total number of parts is edited. In addition, the total number of T-SU sound modules is edited.

At step SP206, the attribute file of the second part of the ATRC3 data file is erased. In step SP207, T-TRK and TRK - XXX, the playback control files are edited.

Thus, the combining process is performed in the order (1) editing the TRF, (2) editing the attribute file and (3) editing the playback control file. However, this order can be changed.

Separation process

In this embodiment, a combination process for combining two files has been described. Next, a separation process for separating one file at a specific split point will be described.

The process of separation in TRF

On Fig presents a block diagram depicting a memory card designed to explain the separation process for the file CAT.MSA from the files depicted in Fig.6.

It is assumed that the user performs the separation operation on the border of clusters 6 and 7 of the CAT.MSA file and that during the separation process two files CAT1.MSA and CAT2.MSA are formed.

First of all, DOG.MSA and MAN.MSA files recorded in clusters 201 and 202 are moved to clusters 202 and 203, respectively. In addition, the CAT1.MSA file in which the MSA extension is added to the CAT1 file name that is entered by the user is recorded in the cluster 200. In addition, the CAT2.MSA file in which the MSA extension is added to the CAT2 file name that is entered by the user, is written to cluster 201.

Then the file name CAT.MSA, which is written in the subdirectory, is written into the file name CAT1.MSA. In addition, the CAT2.MSA file name is added to the unused segment.

At the end of the CAT2.MSA file segment, cluster number "7" of the divided CAT2.MSA file is written.

The entry address is rewritten to "FFF" so that the cluster 6 becomes the endpoint of the segment of the CAT1.MSA file name subdirectory in the TRF. The separation process is performed in the TRF as described above.

Attribute Header Editing

When the data file is split, an attribute file must be generated so that it is added to the split file in the second part.

This process will now be described with reference to FIGS. 38A and 38B.

As in Figs. 35A and 35B, Figs. 38A and 38B show memory cards in which logical addresses have been converted to physical addresses. On figa and 38B, for simplicity, the individual parts are arranged sequentially in memory, and not distributed. As shown in FIG. 38A, the file attribute file of the CAT.MSA file contains the total number of T-SU sound modules: 17, the total number of T-PRT parts: 5, the content key, MAC, part size and part key for each part, and the CONNUMO number accumulation of content.

Now suppose that the user indicates the need to carry out the separation process at a specific point in the CAT.MSA file. For example, it is assumed that the user performs a separation operation at the boundary between parts 3 and 4 of FIG. 38A. Attribute file data is updated as follows.

Like truly updated data, when a music program is split, the number of parts that make up single files decreases. Thus, the T-TRT contained in the attribute file is edited. In addition, when the file is split, since the total number of sound modules is reduced, the T-SU is also edited. In other words, as shown in FIG. 38B, the total number of sound blocks of the CAT1.MSA file, which is divided in the first part, is rewritten in T-SU: 100. In addition, the total number of parts of the CAT1.MSA file is overwritten in T-PART: 3.

In addition, since the file is divided, the content key, the MAC verification value of the copyright information, and the part key for each part are rewritten.

In addition, the file attribute file CAT2.MSA, which is shared on the opposite side, is created again.

In relation to the newly created attribute file, the total number of sound blocks and the total number of parts are rewritten in T-SU: 70 and 1-PART: 2, respectively.

In addition, since the file is divided, the content key, the MAC verification value of the copyright forgery information, and the part key for each part are rewritten.

Playback edit control file

Next, a method for editing a playback control PBLIST file in a split process will be described. When a file is split into two files, the number of files increases by one. In this case, the total number of T-TRK music recordings increases by L. In addition, the TRK-X table (where X is any integer in the range from 1 to 400) is edited so that the received music program numbers are shifted.

Stages of the separation process

Fig. 39 is an algorithm depicting a separation process.

In step SP301, when the user selects the file to be divided, while listening to the music recorded in the file, he or she selects the split point in a predetermined manner. At step SP302, the communication state of the TRF is edited as described above. At step SP303, the name of the data file that is shared on the reverse side is added to the subdirectory. In step SP304, a data file name that is split on the front side is added to the data area. The file name is entered by the user. In step SP305, the data file attribute file on the front side of the split point is edited. In addition, in step SP306, an attribute file is generated to be added to the reverse side data file. The attribute file is newly created, and this attribute file is edited in accordance with the split point of the divided file. In step SP307, the playback control file PBLIST is edited. The above separation process is performed in the order of (1) editing the TRF, (2) editing the attribute file, and (3) editing the playback control file. However, this order can be changed.

A feature of the present invention is that a user can edit a data file (ATRAC3 file) recorded in a memory card type device. Next, editing processes (for example, the combining process and the separation process) corresponding to the music recording management file TRKLIST, described with reference to FIG. 25 to 32. However, the following description may apply to the TRKINF region of the music recording information and the PRTINF region of the information portion of the ATRAC3 data file.

In this section, with reference to FIG. 40, a combination process will be described (see FIG. 10B) for combining two musical recordings A and B constituting one part. 40 is an algorithm depicting a combination process. In step 401, the information region PRTINF of the music recording part B in the second part moves below the information region PRTINF of the music recording part A. Thus, in the music recording information management file TRKLIST, the music recording information region TRKINF and the music recording information part PRTINF are located A, the PRTINF region of the information of the part of the music recording B and the TRKINF region of the information of the music record of the music B.

In step 402, the TRF chain of the music recording file ATRAC3 of the music record B is connected in the second part of the TRF chain of the ATRAC3 data file of the music recording A. In step 403, the TRKINF region of the music recording information B is deleted from the music recording information management file TRKLIST. Thus, in the music information management file TRKLIST, the music information recording area TRKINF of the music recording information A, the information recording area PRTINF of the music recording part A, and the information recording area PRTINF of the music recording part B are arranged in series. At 404, the ATRAC3 data file of the music record B is deleted from the directory. At step 405, the value P-nnn, which represents the number of parts that make up the music program in the TRKINF area of the music information of the music record A, changes from 1 to 1 + 1 = 2.

Thus, the key values are changed. In this example, the content key of the original music recording A is designated as KC_A; and the content key of the original music recording B is designated as KC_B. Similarly, the key of a part of the original musical recording is designated as KP_A; and the key of a part of the original music recording B is designated as KP_B.

At step 406, after the music records A and B are combined, the content key of the new music record N will be generated as KC_N. CONNUM will also be regenerated. At step 407, a new part key will be generated. A new part key is generated using an exclusive OR operation on the content key KS_A, the part key KP_A, and the content key K__N. At 408, a key of a part of the second part is generated (namely, a key of a part for the PRTINF area of information of the part of the original music recording B). As with the new part key, the reverse key of the second part is generated by performing an exclusive OR operation with respect to the content key KS_B, the part key KP_B and the content key KC_N.

At step 409, the key KC_N of the contents of the new music record N is encoded using the accumulation key of a memory device of the card type and stored in CONTENTS KEY-nnn in the music recording information area TRKINF. CONNUM is stored in the CONNUM-nnn area TRKINF music recording information. In addition, each part key is stored in the PRTKEY-nnn area of the PRTINF information of the part.

Next, with reference to FIG. 41, a separation process will be described (see FIG. 10C) for splitting a music record A, consisting of one part, into two music records A and B. FIG. 41 is a flowchart depicting a process separation. At step 501, the split point is selected using 3D. At step 502, the PRTSIZE of the PRTINF area of the information of the part of the new music recording A is changed. In fact, the number of clusters is calculated from the beginning (initial MR) to the split point (final MR). The cluster size, the initial ZM and the final ZM are changed in accordance with the position of the ZM at the cluster separation point and stored in the PRTSIZE information area of the part of the new music recording A.

At step 503, one cluster is completely copied, which is the last cluster of the new music A, which contains the split point. The copied cluster is regarded as the top of the new music record B. At step 504, the total number of parts of the newly formed music record B is stored in the value Pnnn, which represents the number of parts that make up the music program in the TRKINF area of the music information regarding the music record B. In this example, the clusters, which are preceded by a split point, become the second part, which is a newly formed musical recording B. Total counts about the parts of the newly formed music recording B. In step 505, the file number FNW-nnn of the new ATRAC3 data file is generated and recorded in the FNW-nnn region TRKINF of the music recording information.

In step 506, the music recording information region TRKINF of the new music recording B and the part information region PRTINF of the part information region PRTINF of the new music recording part A of the music recording information management file TRKLIST. The music recording information region TRKINF of the music recording located in the second part of the original music recording A, and the part information region PRTINF are moved back by the music recording information region TRKINF and the music recording information section PRTINF.

At step 507, the TRF chain of the ATRAC3 data file of the new music recording A changes at the split point. At step 508, since the music recording B is added again, the file B of the ATRAC3 data file is added to the directory. At step 509, after the TRF chain of the ATRAC3 data file, the newly generated music record B, the rest of the original music record A follows (namely, the cluster chain including the split point).

As a new music entry B is added, key sizes are added. However, the key values of the new musical recording A are not changed.

At step 510, after dividing the music recording, a key KS B is generated for the content key of the contents of the new music record B. In addition, CONNUM is again generated. At step 511, a key KP_B of the part of the new music recording B is generated. The key of the part of the new music record is generated by performing an exclusive-OR operation with respect to the original KC_A, KP_A and KC_B.

At step 512, the key KS_B of the content of the new music record B is encoded using the accumulation key of a card-type storage device and the CONTENTS KEY-nnn of the music recording information area TRKINF is stored. In addition, CONNUM is stored in the CONNUM-nnn field TRKINF of the music recording information. Each part key is directly stored in the PRTKEY-nnn area of the PRTINF information of the part.

Thus, even if editing processes such as combining and dividing processes are performed, the TRKINF region of the music recording information and the PRTINF region of the part information are arranged in the same order as the ATRAC3 data files. In other words, unlike the Link-P system, the TRKINF area of the music information of a single file that has been edited, and the communication address of the PRTINF area of the part information is arranged sequentially, and not by accident.

Furthermore, when another editing process is performed, such as an erase process or a moving process, the music recording information region TRKINF and the part information region PRTINF are changed in the same order as the ATRAC3 data files.

In accordance with the present invention, even if the TRF flash memory is destroyed, an attribute file is added at the beginning of each file so that it can control the parts that are allocated in memory using the attribute file. Thus, the editing process is performed correctly. In addition, the editing process can be correctly performed on a storage medium, such as flash memory, in which there is a tendency for defective blocks to occur.

After describing specific preferred embodiments of the present invention, with reference to the accompanying drawings, it should be understood that the present invention is not limited to these specific embodiments and that various changes and modifications can be made by one skilled in the art without departing from the scope and spirit of the present invention, as defined in the attached claims.

Claims (24)

1. An editing device for editing a data file recorded in a non-volatile storage device for segmenting a single data file that is sequentially reproduced in blocks, each of which has a predetermined data length, and this non-volatile storage device has a data area for records of each block together with an attribute file that has a predetermined length, and a control area intended for control recording data intended for the file control data recorded in the data area, comprising: operating means for selecting two data files recorded in the data area, for performing the process of combining the two selected data files; separation means for separating the attribute file from the last data file from the selected two data files; editing means for editing control data recorded in the control area by establishing a logical connection between two data files and for editing an attribute file added to the first data file from the selected two data files; and recording means for recording control data edited by the editing means in the control area and writing an attribute file added to the first data file to the data area. 2. The editing device according to claim 1, characterized in that it is arranged to use the file allocation table as control data recorded in the control area. 3. The editing device according to claim 1, characterized in that it is adapted to use control data, some of which is intended to at least control the total number of data files recorded in the data area. 4. The editing device according to claim 1, characterized in that it is configured to use an attribute file additionally containing a key for encoding a data file, and rewriting the key during the editing process. 5. The editing device according to claim 1, characterized in that it is configured to write the total amount of data of the corresponding data file to the attribute file and overwrite the total amount of data of the attribute file for the first data file to a value in which the total amount of data of the attribute file added to the first located data file is added to the total data of the attribute file added to the last located data file. 6. The editing device according to claim 1, characterized in that it is configured to assign an attribute file added to the last located data file as a file to which recording can be made. 7. The editing device according to claim 1, characterized in that it is adapted to edit the attribute file added to the first data file located in accordance with the attribute file corresponding to the last data file located. 8. The editing device according to claim 1, characterized in that it is adapted to use a data file that is played sequentially, consisting of at least one part, in which many blocks are grouped, and in which the number of parts is controlled using the attribute file. 9. The editing device according to claim 8, characterized in that the editing means is adapted to edit the attribute file added to the first data file in accordance with the amount in which the number of parts controlled by the attribute file for the first data file is added up, and The number of parts managed by the attribute file for the last data file. 10. The editing device according to claim 8, characterized in that it is arranged to use an attribute file containing a key for encoding a part. 11. The editing device according to p. 10, characterized in that it is configured to overwrite the key for encoding the part during the editing process. 12. The editing device according to claim 10, characterized in that it is adapted to use an attribute file containing a key for encoding a data file and a key for encoding a part encoded in accordance with the key recorded in the attribute file. 13. An editing method for editing a data file recorded in a non-volatile storage device for segmenting a single data file that is sequentially reproduced in blocks, each of which has a predetermined data length, the non-volatile storage device having a data area for recording each block together with an attribute file having a predetermined length, and a control area for recording control data x for managing a data file recorded in the data area, comprising the steps of selecting two data files recorded in the data area to perform a process of combining these selected two data files; separating the attribute file from the last data file from the selected two data files; editing control data recorded in the control area by establishing a logical connection between two data files, and editing an attribute file added to the first data file of the two selected data files; and writing the edited control data to the control area and writing an attribute file added to the first data file to the data area. 14. An editing device for editing a data file recorded in a non-volatile storage device for segmenting a single data file, which is sequentially reproduced in blocks, each of which has a predetermined data length, and this non-volatile storage device has a data area for recordings of each block together with an attribute file having a predetermined length and a control area for recording their data intended for managing a data file recorded in a data area containing an operating means for setting a split point of a particular data file recorded in a data area; editing means for editing the added attribute file and control data in accordance with the split point of the data file set by the operating means; generating means for generating an attribute file for a data file located after the split point that is set by the operating means, and recording means for recording control data edited by the specified editing means in the control area and writing an attribute file added to the first file located data to the data area. 15. The editing device according to claim 14, characterized in that it is arranged to use the file allocation table as control data recorded in the control area. 16. The editing device according to claim 14, characterized in that it is arranged to use control data, some of which is intended to control at least the total number of data files, recorded in the data area. 17. The editing device according to claim 14, characterized in that it is arranged to use an attribute file containing a key for encoding a data file and rewrite the key for encoding a data file when performing the editing process. 18. The editing device according to claim 14, characterized in that it is arranged to control the total amount of data of the corresponding data file by means of an attribute file for the data file located after the split point. 19. The editing device according to 14, characterized in that it is configured to use a data file that reproduces and sequentially consists of at least one part, in which many blocks are grouped, and in which the number of parts is controlled using the attribute file. 20. The editing device according to claim 14, characterized in that the editing means is adapted to edit the number of parts controlled by the attribute file located before the split point of the data file, and the number of parts managed by the attribute file located after the split point of the data file, which is installed by an operating facility. 21. The editing device according to claim 19, characterized in that it is arranged to use an attribute file containing a key for encoding a part. 22. The editing device according to p. 21, characterized in that it is configured to overwrite the key for encoding the part during the editing process. 23. The editing device according to claim 21, characterized in that it is adapted to use an attribute file containing a key for encoding a data file and a key for encoding a part encoded in accordance with a key recorded in the attribute file. 24. An editing method for editing a data file recorded in a non-volatile storage device for segmenting a sequentially reproduced single data file into blocks, each of which has a predetermined data length, this non-volatile storage device having a data area for recording each block together with an attribute file having a predetermined length, and a control area for recording control data, for managing a data file recorded in the data area, comprising the steps of setting a split point of a particular data file recorded in the data area; editing the added attribute file and control data in accordance with the split point of the data file; generating an attribute file for the data file located after the split point; and writing control data to the control area, and writing an attribute file added to the data file located before the split point to the data area.

Images