RU2255382C2 - Semiconductor memory board, reproduction device, recording device, reproduction method, recording method and data carrier read by a computer - Google Patents

Abstract

FIELD: data carriers.

SUBSTANCE: board has protected area, wherein a series of encoding keys is stored, unprotected area, wherein at least one sound record is stored and control information. Reproduction device has reading means, decoding means and reproduction means. Recording device has encoding means and recording means. Methods describe operation of said devices. Data carriers contain software, which reflects operations of said methods.

EFFECT: broader functional capabilities.

10 cl, 109 dwg

Description

FIELD OF THE INVENTION

The present invention relates to a semiconductor memory board in which sound data and control data are stored, and to a playback device, a recording device, a reproducing method, a recording method, and a recording medium having readability by a computer related to this semiconductor memory board. In particular, the present invention relates to improved storage of control information and audio data distributed as information content by an information distribution service, for example, an electronic music distribution service.

BACKGROUND

In recent years, there has been a gradual introduction of the hardware infrastructure necessary to ensure the electronic distribution of music. This leads to the possibility of major changes in the music industry, in which the distribution of products is usually carried out in the form of off-the-shelf computer programs in retail packaging using media such as compact discs (CDs) and magnetic tape tapes.

Musical information content (that is, songs and albums) can be delivered to consumers electronically if the consumer has a personal computer that downloads information content from a computer server, which is managed by a record company. To listen to digitally downloaded music on a portable playback device, the user must save the music data on the portable recording medium. Currently, the most suitable storage media for storing musical information distributed electronically are semiconductor memory cards.

Examples of such devices are flash memory cards with an ATA interface and SEALED FLASH MEMORY cards, which are already available for use. Such semiconductor memory cards comprise a semiconductor device called EEPROM flash memory (programmable read-only memory with group (parallel) electrical erasure). Flash memory can read and write data at much higher speeds than MD (minidisk) (MD) or PCD (rewritable compact disc) (CD-R). This means that digital music can be transferred in a short time, despite the fact that it has a large amount of data.

The main drawback inherent in semiconductor memory cards is the risk that the user may make illegal copies of copyrighted music that has been downloaded electronically from the music distribution service. Since semiconductor memory cards can record data at higher speeds than PCDs or MDs, copying is considered to be the most serious problem for such memory cards. In order to overcome possible dangers related to copyright infringement, music presented in digital form must be encrypted using a reliable encryption method before it is stored in the semiconductor memory board.

One of the methods of remembering, which takes into account the need to prevent unauthorized copying, is the method of memorizing recordings of musical works, used in the standard for sound DVD (DCD - universal digital disc). One example of this method is that in which a “music record” corresponding to a regular music album contains a plurality of “information content elements” that correspond to phonograms in the album. Elements of information content that make up a piece of music are encrypted by using an encryption key called a "piece of music", the choice of which is made by the manufacturer of the disc before recording on an audio DVD (DCD) disc. This piece of music is encrypted using an encryption key (usually called a "disc key"), which is unique to each audio DVD (DLC) disc, and stored in the header area of the sector of the audio DVD (DCD) disc. The encryption of this disc key itself is carried out using the encryption key (usually called the "master key"), the choice of which is carried out by the manufacturers of the decoding device for information content, and it is recorded in the initial area of the audio DVD (DCD) of the disc. Ordinary users cannot access the header area of the sector and the start area, which makes it extremely difficult for users to obtain a key to a piece of music recorded on an audio DVD (DCD) disc.

Semiconductor memory cards have a limited memory capacity compared to magnetic or optical information carriers, therefore, as a rule, it is necessary to compress music presented in digital form with a high compression ratio when it is stored in the semiconductor memory board. One coding method that provides a sufficiently high compression ratio for music presented in digital form is the MPEG2-AAC standard (Motion Pictures Experts Group 2 - Advanced Audio Coding} (Moving Pictures Experts Group 2 - Advanced Audio Coding} One of the distinguishing features of the MPEG2-AAC compression standard is that it uses restrictions due to human hearing, and the length of the binary data assigned to each sound frame is changed in such a way that A small frame, which is the smallest unit of playback, displays approximately 20 ms of sound. Large-length binary data is assigned to sound frames that have many frequencies within the audible range of a person’s ear, and shorter binary data is assigned to sound frames that have fewer similar sounds or frequencies outside the range of audibility of the human ear.

Since the amount of data assigned to each sound frame in the MPEG2-AAC standard depends on the number of audible frequencies in the frame (or in other words, because the MPEG2-AAC standard uses variable bit rate coding (VBR)), then even at high compression ratios, high quality audio information can be obtained. Such audio information is suitable for distribution over a public network and for storing semiconductor memory cards that have a limited memory capacity.

FIRST PROBLEM

When the storage of information content is carried out in accordance with known methods, the decryption of the key of the musical composition used to encrypt the musical information allows the user to decrypt all the musical information recorded on the recording medium. This leads to the first problem, which consists in the insecurity of a single key of a musical work, which allows users to easily decrypt all phonograms stored in the semiconductor memory board.

Despite the fact that decryption of the keys of a musical work is rare, such insecurity can lead to enormous losses for the copyright owner. Given the fact that in recent years there has been a tremendous increase in the computing power of home computers, it is becoming increasingly difficult to assert that the key of a piece of music used to encrypt music presented in digital form will be completely protected from decryption. This necessitates the creation of such a data structure that will minimize damage to copyright owners when decrypting a key to a piece of music.

SECOND PROBLEM

Since for music presented in digital form, which is intended for distribution by electronic means of music distribution, it is necessary to protect copyright, such music is usually distributed in encrypted form. It is also necessary to encrypt that music, presented in digital form, which is stored in the semiconductor memory board. However, this leads to a second problem, namely, that if the music stored in the semiconductor memory card is encrypted, the user who paid the proper price when purchasing the music in digital form will not be able to edit the music in a simple way. In the case when storing the information content of a musical work is performed in encrypted form, it is very difficult for the user to change the order of the phonograms or to delete part of the phonogram. Given that the user has paid the proper price, it is advisable not to limit his / her ability to perform such editing of music information.

Mini-disk recorders (MDs), which, like a semiconductor memory card, can be used to record music, allow you to perform many functions for editing phonograms by the fact that they provide for the presence of OHL (table of contents) (TOC). Such functions include changing the playback order of phonograms, splitting phonograms and combining phonograms into one phonogram. If the recorders on the semiconductor memory cards are not able to provide the same functions as conventional recorders on the MD, then it is believed that consumers will consider the playback devices with the semiconductor memory cards as having worse capabilities than the recorders on the MD, which, therefore, detrimental to the commercial success of products with semiconductor memory cards.

THIRD PROBLEM

To provide special functions for reproducing music presented in digital form, which has been subjected to encoding with PSPDD (VBR), as, for example, in the MPEG2-AAC standard, playback devices must be equipped with large-capacity memory. This increases the cost of manufacturing such devices and leads to a third problem for the prior art.

Special playback functions that are provided in the playback devices of MD or CD (CDs) include the ability to start playback from any soundtrack on the disc (determining the playback location), the music search function, in which intermittently play short sections of music in order to enable users to “jump” through phonograms in the forward or reverse direction at a high speed, and the time search function by which Users can start playback from the point that you entered as time measured from the beginning of the disc. In order to capture the market currently held by MD or CD playback devices, it is necessary that the playback devices with semiconductor memory cards have the same special playback functions as the MD playback devices. When the music content is encoded with a constant binary data rate (PostRSPD) (CBR), then playback from the point specified by using the time code (a similar point is located one or two minutes from the beginning of the phonogram) can be done simply by reference to an address that is offset by a multiple of the amount of data in a single interval of playback time, multiplied by an integer. However, when music content has been encoded using the PDCPD method, for example MPEG2-AAC, those setpoints that correspond to one or two minutes before the current location will rarely have an offset multiple of the data volume in a unit playback time interval multiplied by an integer number. As a result, the playback device will be forced to access the pre-created time search table to indicate which addresses correspond to the points ahead in time in one minute and two minutes.

Despite the fact that the time search table for a short phonogram does not have to contain a large number of installation points during playback, this statement is not valid for the time search tables for long phonograms, so the time search tables for long phonograms are very large . To provide special playback capabilities, the playback device must access the time table by loading it into its memory in the first place.

Since long phonograms have large time search tables, this means that the playback device must be equipped with a large capacity memory for storing a time search table. It also increases the cost of producing playback devices.

SUMMARY OF THE INVENTION

The first objective of the present invention is to provide a semiconductor memory card that protects the copyright of the music content stored therein, while users are allowed to edit the music content.

The second objective of the present invention is to provide a playback device that can perform special playback functions, for example, searching for music content recorded on a semiconductor memory board, in the forward and reverse direction without using a large capacity memory.

The first objective of the present invention can be achieved by developing a structure of a semiconductor memory board in which at least one soundtrack is stored, including: a protected area, which can be accessed by means of a device physically connected to the semiconductor memory board and having reading means stored in data, only if the authenticity of this device is established, and in the protected area a sequence of encryption keys is stored, with standing of the plurality of encryption keys arranged into a predetermined order; and an unprotected area, which can be accessed by any device physically connected to the semiconductor memory board and having a means of reading the data stored in it, and at least one soundtrack and control information are stored in the unprotected area, at least one a sound track contains a lot of encrypted sound objects, and control information indicates which encryption key from the set of encryption keys corresponds to each sound A new object stored in an unprotected area.

By means of the claimed structure, encoding of a plurality of audio objects using a plurality of encryption keys can be carried out in such a way that if the encryption key used to encrypt a particular audio object is decoded and declassified, such declassification will allow decryption of only a specific audio object and, therefore, will not act on other sound objects. This means that the proposed semiconductor memory board minimizes the damage caused by the declassification of one of the encryption keys.

Preferably, the control information indicates for each sound object the location of the sound object in memory and a number indicating the position of the encryption key corresponding to the sound object in the sequence of encryption keys.

In addition, each soundtrack may additionally contain (1) attribute information and (2) layout information for each sound object contained in the soundtrack, moreover, the attribute information indicates which type of the following types is of type (a) , type (b), type (c) and type (d) - each sound object belongs; moreover, type (a) represents the entire soundtrack, type (b) represents the first part of the soundtrack, type (c) represents the middle part of the soundtrack, and type (g) is the final part of the soundtrack, and the layout information for each sound object of type (b) or type (c) indicates which sound object follows this sound object.

Using the claimed structure leads to the achievement of the results described below. The attribute information indicates how the encrypted audio objects were arranged in the audio phonograms, while when two audio objects are controlled as two separate audio phonograms, such phonograms can be combined as a single phonogram by simply changing the attribute information for indications that sound objects correspond to the beginning and end of the phonogram. Since sound phonograms can be combined by changing attribute information, the combination of phonograms can be performed at high speed without the need for decoding of sound phonograms.

Moreover, a plurality of sound objects may contain at least one sound object containing only reliable data intended for reproduction; and at least one sound object containing (1) reliable data and (2) false data located before and / or after the reliable data, wherein the false data is not required to be reproduced, with each sound track additionally containing information about the blocks for each sound object from the sound track, and this information about the blocks contains the offset measured relative to the location of the corresponding sound object in the memory, which is indicated in the control information; and information about the length, in which the length of the valid data is indicated, which starts from the place indicated by the offset, moreover, the attribute information for the sound object indicates whether the valid data specified by the offset and the length information is valid, (a) correspond to the entire phonogram, (b) correspond to the first part of the phonogram, (c) correspond to the middle part of the phonogram, or (d) correspond to the final part of the phonogram.

Preferably, the reproduction of sound phonograms can be carried out in accordance with the standard playback mode or with an intermittent playback mode, and the standard playback mode is such a mode in which the reproduction of reliable data in sound objects constituting sound phonograms is carried out without any omissions of reliable data, and intermittent playback is a mode in which repeatedly carry out (1) skip access molecular weight data equivalent to the first period, and (2) reproduction valid data equivalent to a second period, and each sound track further comprises a plurality of pieces of information of entry points that indicate the location of the internal space verified data within the audio object at intervals that are equivalent to the first period; and information about the blocks for the sound object, in which are set: the offset, which indicates the difference between (1) the location of the internal location indicated by the first piece of information about the entry points for the sound object, and (2) the memory location for the sound object specified in control information, and the length of reliable data, the start position of which is indicated by this offset.

If there is invalid data at the beginning of the sound frame, the length of these invalid data and the length of the valid data in the sound frame can be set in the block information. As a result, when a user records broadcasts in which the music presenter speaks during the introduction to the song, in order to play back the song without the introduction part, which contains the voice of the music presenter, the proper data offset can be set in the block information . Such editing operations can be performed by simply indicating in the block information which data should not be reproduced, and they are performed with sound objects in an encrypted state. This means that editing phonograms can be done at high speed.

The second objective of the present invention can be achieved by means of a recording device for a semiconductor memory card, comprising: a first generation device for sequentially generating sound frames from an input signal that comes from outside the recording device, the sound frame being the smallest amount of data that can be implemented independent decoding; a recording device for creating a file in the semiconductor memory board and recording sequentially created sound frames in the form of a file; the second generation device for generation, performed whenever the recording device writes to the file a predetermined number of sound frames, a piece of input information indicating the length of the data of the sound element consisting of sound frames recorded in the file, in which whenever the second generation device generates a predetermined number of pieces of input information, the recording device creates a new file and writes to the new file those sound frames sequentially I generated them after that.

When the audio data stream corresponds to a music album that contains a long phonogram, then to ensure that the number of pieces of input information for a single file does not exceed a predetermined value, the long phonogram is divided into many files. Limiting the number of pieces of input information in a file reduces the amount of control information in the file. The following describes how the playback device uses this control information. When the playback device reads the file and starts playing the sound object contained in the file, the playback device also reads the control information for the file and stores it in the internal memory. This control information must be stored in memory as long as the reproduction of the sound object continues. When the reproduction of these sound objects is completed, the next sound object is read. At the beginning of the reproduction of this next sound object, the corresponding control information is read and rewritten into the internal memory of the playback device instead of the control information that has been stored up to now.

Therefore, the playback device repeatedly performs a process in which control information is loaded into its internal memory only for the currently reproduced sound object. This allows the playback device with limited memory capacity to perform special playback functions, such as forward and reverse search.

The control information determines the distribution order of a plurality of sound objects among sound phonograms and the order of their use when reproducing sound phonograms in such a way that phonograms can be easily edited by simply updating the control information.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other objectives, advantages and features of the invention will become apparent from the following description when considered with reference to the accompanying drawings, which depict a specific embodiment of the invention.

In the drawings:

Figure 1 is a top view of the card 31 flash memory;

Figure 2 is a bottom view of the structure of the card 31 flash memory on;

Figure 3 - hierarchical structure of the card 31 flash memory in embodiments of the invention,

4A is a special area, an identification area, and a user area created at the physical level of the flash memory card 31;

Fig. 4B shows the structure of an identification area and a user area at the file system level;

5 is a detailed file system level structure;

6 is an embodiment of the invention when the sound object (AOB) file “AOB001.SA1” is divided into five parts that are stored in clusters 003, 004, 005, 00A, and 00C;

Fig.7 is one example of the installation of catalog elements and file allocation tables in the case when the sound object (AOB) file “AOB001.SA1” is recorded in a plurality of clusters;

Figa and Figb - directories created in the user area and in the field of identification at the file system level in the case when the application level is recorded two of the above data types, as well as what types of files are written to directories;

Fig.9 - the correspondence between the file “AOBSA1.KEY" and the files GOITER (sound objects) (AOW files) in the directories of the EDM (source sound data) (SD_Audio);

Figure 10 - hierarchical data structure in the file GOITER (sound object) (AOW file);

11A - parameters determined by the standard ISO / IEC 13818-7 (International Organization for Standardization / International Electrotechnical Commission, ISO / IEC), presented in table form;

11B - parameters that should be used when encoding a file in the MPEG format 3 level (MPEG-Layer 3) (MP3), presented in table form;

Figv - parameters that should be used when encoding a file in the format of Windos Media Audio (WMA) (sound format for the Windows operating system), presented in table form;

Fig - detailed structure KADRA_ZOB (frame sound object) (AOW_FRAME);

Fig - setting the length of the audio data in bytes in each of the three FRAME_ZOB (AOB_FRAMEs);

Fig. 14 shows the correspondence between the sampling rate and the number of GOITER_FRAMES (AOB_FRAMES) contained in the GOITER ELEMENT (AOB_FLEMENT);

Fig - examples of the duration of the playback ELEMENTS_THE (AOB_FLEMENTS) and the duration of the playback FRAME_THE (AOB_FRAMES);

Fig - the result of playback in the case when sequential playback of GOITER (AOBs) and BLOCKS_ GOITER (AOB_BLOCKS) recorded in the file GOITER (AOW file);

Fig - detailed hierarchical structure of the administrator of the list of playable files (PlaylistManager) and the administrator of phonograms (TrackManager) used in embodiments of the invention;

Fig. 18 shows the amount of memory for the administrator of the list of playable files (PlaylistManager) and the administrator of phonograms (TrackManager);

FIG. 19 is a correspondence between phonogram information information (IDF) (TKIs) shown in FIG. 17 and GOITER (AOBs) and GOITER (AOW file) files as shown in FIG. 16;

FIG. 20 is a detailed data structure of TPFGPVR (time phonogram search tables) (TKTMSRT) shown in FIG. 17;

Fig - one of the exemplary options TPFGPVR (TKTMSRT);

Fig. 22 is a detailed structure of an OIFG (General Phonogram Information) (TKGI);

Figa and Figb - detailed structure of the TIB (table of information about the block) (BIT), and Fig.23B - area Duration_by_time (Time_Length);

Fig. 24 shows a cluster 007 through OOE, in which a GOITER (AOW) consisting of ELEMENTS_THE GOAL FROM the 1st ELEMENT_REA (AOB_ELEMENT # 1) through the 4th ELEMENT_REA (AOB_ELEMENT # 4);

Fig - installation of the next (x + 1) th FRAME_ZOB (AOB_FRAME # x + 1) for playback when performing a search in the forward direction, starting from (x) th FRAME_ZOB (AOB_FRAME # x) in an arbitrary (Y) - om ELEMENT_ GOITER (AOB_ELE-MENT # y) in GOITER (AOW);

FIG. 26A and FIG. 26B define goiter (AOB), GOITER ELEMENT (AOB ELEMENT), and GOITER FRAME (AOB FRAME) corresponding to an arbitrary playback time code;

Figa and Fig. 27 B - erasure of the phonogram;

Figa - administrator phonograms (TrackManager) after the erasure of the phonogram was performed several times;

Fig.28 B - recording new IDF (TKI) and file GOITER (AOW file) in the case when in the administrator of phonograms (TrackManager) there are "unused" IDF (TKI);

Figa and Fig.29B - setting the values of the IDF (TKI) in the case when to create a new phonogram combine the two phonograms;

Figa - GOITER (AOW) of the 1st type (Type1);

Figb - GOITER (AOW) of the 2nd type (Type2);

Figa - combining multiple phonograms into one phonogram for a set of GOITT (AOW) of the 1st type + 2nd type + 2nd type + 1st type (Type1 + Type 2 + Type 2 + Type1);

Figb - combining multiple phonograms into one phonogram for a set of GOITT (AOW) of the 1st type + 2nd type + 2nd type + 2nd type + 1st type (Type1 + Type2 + Type2 + Type2 + Type1 );

Figa - an example in which at the end of the previous phonogram is GOITER (AOW) of the 1st type (Type1), and at the beginning of the next phonogram is GOITER (AOW) of the 1st type (Type1);

Fig. 32B is an example in which at the end of the first phonogram there is a GOITER (AOW) of the 1st type, and at the beginning of the next phonogram there is a GOITER (AOW) of the 2nd type;

Figv is an example in which at the end of the first phonogram there is GOITER (AOW) of the 1st type and 2nd type, and at the beginning of the next phonogram there is GOITER (AOW) of the 1st type;

Fig. 32G is an example in which at the end of the first phonogram there is GOITER (AOW) of the 1st type and 2nd type, and at the beginning of the next phonogram there is GOITER (AOW) of the 2nd type and 1st type;

Fig. 32D is an example in which at the end of the first phonogram there are two GOITERS (AOW) of the 2nd type, and at the beginning of the next phonogram there is GOITER (AOW) of the 1st type;

Figa and Figb - separation of the phonogram to create two phonograms;

Figa and Fig.34B - the contents of the elements of the source audio data directory (SD_Audio) in the source audio data directory (SD_Audio), containing the file GOITER (AOW file) "AOB003.SA1", before and after separation of the phonogram;

Figa - separation of GOITER (AOW) by dividing the 2nd ELEMENT_ GOITER (AOB_ELEMENT # 2) in half;

Fig.35 - two GOITERS (AOW), 1st GOITER (AOW # 1) and 2nd GOITER (AOW # 2), obtained by dividing GOITER (AOW) in the middle of the 2nd GOITER (AOW_ELEMENT # 2);

Fig - setting the state of the TIB (BIT) in the case when the GOITER (AOW) is divided in such a way as shown in Fig.35;

Fig. 37 is a specific example of changes in TIB (BIT) before and after separation;

Fig. 38 is a specific example of changes in TFTGPVR (TKTMSRT) before and after separation,

Figa - format UP_FG_SVFU (search index phonogram from the list of playable files, the default) (DPL_TK_SRP);

Fig. 39B shows the UP_FG_SVF format (search phonogram search pointer from the list of playable files) (PL_TK_SRP);

Fig - the relationship between the Information of the list of playable files (Default_Playlist_Information), IDF (TKI), and files GOITER (AOW files);

Fig. 41 is an example of value settings for the Default_Playlist_playable_list_files_list) and several ISWFs (playlist file information) (PLIs);

Fig. 42 shows the correspondence of UP_FG_SVFU (phonogram search pointers from the playlist set by default) (DPL_TK_SRP) IDF (TKI), the same notation used as in FIG. 40;

Figa and Figb - rebuilding the sequence of phonograms;

Fig. 44A and Fig. 44B show an update of the List of reproducible_ files by default (Default_Playlist), the administrator of phonograms (TrackManager) and files of GOITER (AOW file) in the case when the List of reproducible_ files_ by default (Default_Playlist) shown in Fig. 40 has been deleted. 2) and IDF No. 2 (TK1 # 2);

Figa and Figb - recording new IDF (TKI) and UP_FG_SVFU (DPL_TK_SRP) in the case when there are “unused" IDF (TKI) and UP_FG_SVFU (DPL_TK_SRP);

Figa and Figb - implementation of the combination of phonograms;

Figa and Figb - implementation of the separation of the phonogram;

Fig. 48 is a view of a portable playback device for a flash card 31 of embodiments of the present invention;

Fig - one of the examples of display on the liquid crystal panel when selecting a list of playable files;

Figa - Figa - examples of display on the liquid crystal panel when selecting a phonogram;

Figa - 51B are examples of operations performed by means of a rotary disk with step switching;

Fig - internal structure of the playback device;

Fig - data transfer to and from the double buffer 15;

Figa and Fig.54B - the implementation of the cyclic distribution of areas in the double buffer 15 using circular pointers;

Fig. 55 is a flowchart showing a procedure for reading a GOITTER file (AOW file);

Fig. 56 is a flowchart showing a procedure for outputting a GOITTER file (AOW file);

Fig. 57 is a flowchart showing a procedure for outputting a GOITTER file (AOW file);

Fig. 58 is a flowchart showing a procedure for outputting a GOITTER file (AOW file);

Figa - 59G - the implementation of the update of the playback time code displayed in the window of the playback time code on the liquid crystal panel 5, in accordance with the update of the variable Play_time (Play_time);

Fig. 60 is a flowchart showing CPU (central processing unit) processing 10 when the forward search function is used;

Figa - Fig.61 - the implementation of the increment of the code playback time in the case when using the search function in the forward direction;

Figa and Figb - specific examples of using the search function in time;

Fig. 63 is a flowchart showing processing in an editing control program;

Fig. 64 is a flowchart showing processing in an editing control program;

Fig. 65 is a flowchart showing processing in an editing control program;

FIG. 66 is one example embodiment of a recording apparatus for recording data on a flash memory card 31; FIG.

Fig - composition of the hardware recording device;

Fig. 68 is a flowchart showing processing during recording;

Fig - hardware device board 31 flash memory;

Fig - sequence of the process of transmitting information that is used when the playback device connected to the card 31 flash memory reads the encryption key “File Key” (FileKey) and reproduces GOITER (AOW); and

Fig - detailed sequence of the process of transmitting information that is used in the mutual identification of Fig.

BEST MODE FOR CARRYING OUT THE INVENTION

Below, with reference to the accompanying drawings, a description is given of a semiconductor memory board (flash memory card), which is an embodiment of the present invention.

The paragraphs below are arranged in a hierarchical system using reference numbers in accordance with the notation defined below.

{x1-x2_x3-x4}

The length of the reference number indicates the hierarchical level of the description section. As a specific example, the number x1 is the number of the drawing to which reference is made in the description. The drawings attached to this description are numbered in the order in which they are mentioned in the description, so the order of the drawings approximately corresponds to the order of presentation. The explanation of some of the drawings is divided into paragraphs having a reference number x2 indicating the paragraph number for that paragraph from the description of the drawing, which is indicated by the reference number x1. The reference number x3 indicates the number of the additional drawing, which is needed for a more detailed explanation of the paragraph indicated by the paragraph number x2 of the paragraph. Finally, reference number x4 indicates the paragraph number in the description of this additional drawing.

FIRST IMPLEMENTATION

(1-1_2) Appearance of the flash card 31

This explanation begins with a description of the appearance of the flash memory card 31. Figure 1 shows the external view of the flash memory card 31 from above, and Figure 2 shows the structure of the flash memory card 31 in a bottom view. As shown in FIGS. 1 and 2, the flash memory card 31 is approximately the same size as the postage stamp and is thus large enough to be held in the hand. It is approximately 32.0 mm long, 24.0 mm wide and 2.0 mm thick.

It can be seen that, at its lower edge, the flash memory card 31 has nine slots for connecting the card to a compatible device and a protective switch 32 located on one side, which allows the user to set whether or not to overwrite the stored contents of the flash memory card 31.

{3-1} Physical structure of flash card 31

FIG. 3 shows the hierarchical structure of a semiconductor memory board (hereinafter referred to as “flash memory card 31”) of the present embodiment. As shown in FIG. 3, the flash memory card 31 is designed to have a physical layer, a file system layer and an application layer similar to DVD (DVD) (digital video disc), however, the logical and physical structures of these layers are very different from those on the digital video disc (DVD).

{3-2} Physical layer 31 flash memory card

The following is a description of the physical layer of the flash card 31. Flash memory consists of many sectors, each of which stores 512 bytes of digital data. As one example, a 64 MB flash card 31 will have a memory capacity of 67108864 (= 64 * 1024 * 1024) bytes, so this card contains 131072 (= 67108864/512) active sectors. When subtracting the number of backup sectors that are created for use in case of errors, the remaining number of active sectors into which various types of data can be recorded is approximately 128,000.

{3-2_4A-1} Three areas in the physical layer

These three areas depicted in FIG. 4A are created in a memory area consisting of these active sectors. These areas are the "special area", "identification area" and "user area", and their more detailed description is given below. The user area is characterized in that the device to which the flash memory card 31 is connected can freely read or write various kinds of data from or to this area. Management of areas within the user area is carried out through the file system.

In a special area, the identifier (ID) of the medium is stored, which is a unique number that is uniquely assigned to each flash card 31. Unlike the user area, this area is intended to be read only, so the media identifier (ID) stored in the special area cannot be changed.

An identification area, like a user area, is an area in which rewriting is provided. This area differs from the user area in that the device connected to the flash memory card 31 can access (i.e. read or write data) to the identification area only if the flash memory card 31 and the device previously confirmed that both of them are genuine devices. In other words, reading data from the identification area or writing to it can be carried out only if mutual identification was successfully performed by the flash memory card 31 and the device connected to the flash memory card 31.

{3-2_4A-2} Use of these three areas in the physical layer

When a device connected to the flash memory card 31 writes data to the flash memory card 31, the area that is used to store this data depends on whether copyright protection is necessary for the data being recorded. When data for which copyright protection is required is recorded on the flash memory board 31, before data is written to the user area, it is encrypted using a predefined encryption key (called a “FileKey”) ) This “FileKey” can be easily set by the copyright owner, and although using this “FileKey” provides a certain degree of copyright protection, the file key itself is also encrypted (FileKey) used to encrypt recorded data to provide better protection for copyright. To encrypt the file key (FileKey), any number obtained by performing predetermined computational operations with the identifier (ID) of the medium, which is stored in a special area, can be used. The encrypted file key (FileKey) created in this way is stored in the identification area.

Since the data for which copyright protection is necessary is subjected to a two-stage encryption process, in which the data is encrypted using a file key (FileKey), which itself is encrypted using the media identifier (ID), infringe copyright, for example, to make illegal copies This data is extremely complex.

{3-2_4B-1} Brief description of the file system

It is understood that the physical layer design of the flash memory card 31 enhances copyright protection for data recorded on the flash memory card 31. The following is a description of the level of the file system located at this physical level. Despite the fact that at the file system level of a digital video disc (DVD) they use a file system of the UDF type (universal drive format), at the file system level of a flash card 31 use a file system of the FAT type (TRF) (file allocation table) described in the standard in ISO / IEC 9293.

On Figb shows the structure of the identification area and the user area at the file system level. As shown in FIG. 4B, both the identification area and the user area in the file system include “partition boot sectors”, “file allocation table (TRF)” (FAT), “root directory”, and “data area”, and this means that the identification area and the user area have the same structure. Figure 5 shows in more detail the various parts of these file systems. The following is a description of the structure of the user area with reference to Figa, Fig.4B and Fig.5.

{3-2_4B-2} Partition boot sectors

Partition boot sectors are sectors in which data is accessed by a standard personal computer connected to a flash memory card 31 when the flash memory card 31 is installed as a boot disk for an operating system (OS) ) personal computer.

{3-2_4B-3_5} Data Area

The data area can be accessed elementwise by means of a device connected to the flash memory card 31, wherein the volume of one element cannot be less than the size of one “cluster”. Despite the fact that the volume of each sector in the flash memory card 31 is 512 bytes, and the cluster volume is 16 kb (kilobytes), therefore, reading and writing data at the file system level is carried out in units equal to 32 sectors.

The reason that the cluster size is set to 16 kb is because when writing data to the flash memory card 31, before recording, you must first erase some of the data stored in the flash memory card 31.

The smallest amount of data that can be erased in the flash memory card 31 is 16 kb, so setting the smallest possible amount of erased data to the cluster size means that data can be written in the best way. The arrow ff2, which is shown in FIG. 5 by a dashed line, indicates a plurality of clusters 002,003,004,005 ... contained in the data area. The numbers 002,003,004,005,006,007,008 ... used in FIG. 5 are three-digit hexadecimal cluster numbers that are uniquely assigned to identify each cluster. Since the smallest element size by which access can be made is equal to one cluster, the memory cells inside the data area are indicated by using cluster numbers.

{3-2_4B-4_5} File allocation system

The file allocation system has a file system structure according to the ISO / IEC 9293 standard, and thus consists of many TRF values. Each TRF (FAT) value corresponds to a cluster and indicates which cluster should be read after the cluster corresponding to the TRF (FAT) value. The arrow ff1, which is shown in FIG. 5 by a dashed line, indicates the plurality of TRF values (FAT) 002,003,004,005 ... that the file allocation table contains. The 002,003,004,005 ... numbers assigned to each TRF (FAT) value indicate which cluster corresponds to each TRF (FAT) value and, therefore, represent the cluster numbers for clusters corresponding to the TRF (FAT) values.

{3-2_4B-5_5-1} Elements of the root directory

"Elements of the root directory" are information indicating what types of files are present in the root directory. Specific examples are the "file name" of an existing file, its "file name extension", "time / date of correction" and "the number of the first cluster in the file" indicating where the beginning of the file is stored, and they can be written as an element The root directory of the file.

{3-2_4B-5_5-2} Directory elements for subdirectories

Information related to files in the root directory is recorded as elements of the root directory, but information related to subdirectories is not recorded as elements of the root directory. Instead, directory entries for subdirectories are created in the data area. In FIG. 5, one example of a directory entry for a subdirectory is a source audio data directory entry (SD-Audio) defined in a data area. Like the root directory element, the source audio data directory element (SD-Audio) contains the “file name” for the file located in this subdirectory, its “file name extension”, “update time / date” and “number of the first cluster in the file” indicating where the beginning of the file is remembered.

{3-2_4B-5_6-1} Format for storing goiter files (sound objects) (AOB)

Below with reference to FIG. 6, a description will be made of a method for storing a file by showing how a file with the name “AOB001.SA1” is stored in the source audio data directory (SD-Audio). Since the smallest unit of access to the data area is one cluster, the storage of the file "AOB001.SA1" in the data area must be performed in parts whose size does not exceed one cluster. Therefore, before storing the file "AOB001.SA1" it is first divided into clusters. In Fig.6, the file "AOB001.SA1" is divided into five parts according to the cluster size, and the resulting parts are stored in clusters with numbers 003, 004, 005, 00A, and 00C.

{3-2_4B-5_7-1} Format for storing goiter files (sound objects) (AOB)

When the file "AOB001.SA1" is divided into parts and stored, it is necessary to set the values of the directory element and the file allocation table, as shown in Fig.7. Figure 7 shows one example of how to set the values of the directory element and the file allocation table when storing the file "AOB001.SA1" in the case when it was divided into parts and remembered. In Fig. 7, the beginning of the file "AOB001.SA1" is stored in cluster 003, therefore, to indicate the cluster in which the first part of the file is stored, write to the directory element of the original audio data (SD-Audio) as "the number of the first cluster in the file" cluster number 003. As shown in Fig. 7, the subsequent parts of the file "AOB001.SA1" are stored in clusters 004 and 005. As a result, despite the fact that the value 003 (004) TRF (FAT) corresponds to cluster 003, in which the first part of the file is stored " AOB001.SA1 ", this value indicates that cluster 004 is the cluster in which the next part of the file" AOB001.SA1 "is stored. Similarly, despite the fact that the values 004 (005) and 005 (00A) TRF (FAT) correspond to clusters 004 and 005, in which the following parts of the file “AOB001.SA1” are stored, these values, respectively, indicate that the cluster 005 and cluster 00A are clusters in which the following parts of the file "AOB001.SA1" are stored. By reading the clusters with those cluster numbers that are recorded in these TRF values (FAT), in the order indicated by the arrows fk1, fk2, fk3, fk4, fk5 ... in Fig. 7, all the parts obtained by partitioning can be read file "AOB001.SA1". As explained above, access to the data area of the flash card 31 is performed in units of clusters, each of which is associated with a TRF value (FAT). It should be noted that the value of the TRF (FAT) corresponding to the cluster in which the final part of the GOA file (AOW file) is stored (the OOS cluster in the example shown in Fig. 7) is set to the FFF cluster number in order to show that in the corresponding cluster, the final part of the file is stored.

This completes the description of the file system in the flash card 31 of the present invention. The following is a description of the application layer that exists in this file system.

{3-3} A brief description of the application layer in the flash card 31

Figure 3 shows a General view of the application layer in the card 31 flash memory. As shown by the arrow PN2 shown in FIG. 3 by the dashed line, the application layer in the flash memory card 31 consists of reproducible data and navigation data, which are used to control the reproduction of the reproduced data. As shown by the arrow PN2, the reproduced data contains sets of sound objects (sets of GOITT (AOV)), which are created by encoding sound data, representing, for example, music. The navigation data includes a “playlist manager” (ADSF) (PlaylistManager) (PLMG) and a “phonogram manager” (ADFG) (TrackManager) (TKMG).

{3-3_8A, B-1} Directory structure

On figa and figv shows which directories are in the user area and the identification area at the file system level in the case when these two types of data are stored in the application level, and also shows which files are in these directories.

The file names are "SD_AUDIO.PLM" ("Source_sound_data.PLM", where the extension ".PLM" means "administrator of the playlist" - translator's note) and "SD_AUDIO.TKM" ("Source_sound_data.TKM", where the extension is .TKM) means “phonogram manager” - translator’s note) in Fig. 8A indicate the files in which the administrator of the playlist (PlaylistManager) (PLMG) and the phonogram manager (ADFG) (TrackManager) (TKMG), which form the navigation information, are stored . Here the names of the files "AOB001.SA1", "AOB002.SA1", "AOB003. SA1", "AOB004.SA1", ... denote those files (files "GOITER" ("AOV" files)) in which the storage sound objects representing reproducible data. The “FOR” characters in the file name extension for the “AOBOxx.SA1” file names are an abbreviation of the term “Secure Audio Data” (Secure Audio) and indicate the need to ensure copyright protection for the stored contents of this file. It should be noted that although only eight GOITER files (AOW files) are shown in the example of FIG. 8A, a maximum of 999 GOITER files (AOW files) can be stored in the source audio data directory (SD-Audio).

In the case when it is necessary to protect copyright for reproduced data, a subdirectory called the "source audio data directory (SD-Audio)" is created in the identification area, and a file "is created in this source audio data directory (SD-Audio)" AOBSA1.KEY "in which the encryption key is stored.

On figb shows the file "AOBSA1.KEY" storing the encryption key, which is stored under the symbol "source audio data (SD-Audio)" (that is, inside the "directory of original audio data (SD-Audio)"). In this file "AOBSA1.KEY" storing the encryption key, remember the sequence of encryption keys, which is created by placing a plurality of encryption keys in a predetermined order.

The source audio data directory (SD-Audio) shown in Fig. 8A and Fig. 8B is stored in a computer server, which is managed by a recording company distributing music electronically. When a consumer orders music information, the corresponding source audio data directory (SD-Audio) is compressed, encrypted, and transmitted to the consumer via a public network. The consumer computer receives this directory of source audio data (SD-Audio), decrypts it, expands its compressed data, and thus receives the original directory of source audio data (SD-Audio). It should be noted that the term "public network" here refers to any type of network that can be used by consumers, for example, a wired communication network, such as a digital integrated services network (ISDN), or a wireless network such as a mobile telephone system. It is also possible that the consumer’s computer downloads the GO file (AOW file) from the computer server, which is managed by the recording company, and then creates the source audio data directory (SD-Audio) in the flash memory card 31, similar to the one shown on figa and figb.

{3-3_9-1} Correspondence between the file "AOBSA1.KEY" and goiter files (AOW files)

Figure 9 shows the correspondence between the file "AOBSA1.KEY" in the directory of the original audio data (SD-Audio) and files GOITER (sound objects) (AOW files). The file keys (FileKeys) shown in FIG. 9, used in encrypting files in a user area, are stored in a corresponding encryption key storage file located in the identification area.

The correspondence of the encrypted GOITER files (AOW files) and the encryption key storage file is established according to the predefined rules (1), (2), and (3) described below.

(1) The encryption key storage file is located in a directory having the same directory name as the directory in which the encrypted file is stored. In accordance with this rule, the GOIT files shown in FIG. 9 are located in the source audio data directory (SD-Audio) in the user area, and the encryption key storage file is located in the directory called the source audio data directory (SD- Audio) and is located in the identification area.

(2) An encryption key storage file is assigned a file name created by combining the first three characters of the file name of the GOITER files (AOW files) located in the data area with the predefined extension ".key" ("key"). When the GOITER file (AOW file) has the file name "AOB001.SA1", the encryption key storage file is assigned the file name "AOBSA1.KEY" created by adding the first three characters "AOB", "SA1", and the extension ".key" as shown in Fig. 9 by the arrows nk1 and nk2.

(3) the file name GOITER (AOW file) is assigned a sequence number that indicates the location of the file key (FileKey) corresponding to this sound object in the sequence of encryption keys specified in the encryption key storage file.

"Records No. 1, No. 2, No. 3 ... No. 8 on file keys" ("File Key Entries, # 1, # 2, # 3 ... # 8") indicate the initial locations of the areas in which the corresponding keys are stored files (FileKeys) in the encryption key storage file. In this case, the file names GOITER (AOW files) are assigned serial numbers "001", "002", "003", "004", .... These serial numbers indicate the locations of the corresponding file keys (FileKeys) in the sequence of encryption keys in this way that the key of the file (FileKey), which was used to encrypt each file of the GOITER (AOW file), is located in the "File Key Entry" ("FileKey Entry") under the same serial number. In Fig. 9, arrows Ak1, Ak2, Ak3, ... indicate the correspondence between GOIT files (AOW files) and file keys (FileKeys). In other words, the file key “AOB001.SA1” corresponds to the file key (FileKey) whose location in memory is indicated as “Record No. 1 on the file key” (“FileKey Entryft”), the file key “AOB002.SA1” corresponds to that file key (FileKey ), the location of which in memory is indicated as "Record No. 2 on the file key" ("FileKey Entry # 2") ", and the file" AOB003.SA1 "corresponds to the file key (FileKey), the location of which in memory is indicated as" Record No. 3 about the file key "(" FileKey Entry # 3 "). From rule (3) it is clear that different file keys (FileKeys) are used to encrypt different GOITER files (AOW files), and these file keys (Fi leKeys) is stored in the "File Key Entries" ("FileKey Entries") under serial numbers "001", "002", "003", "004", etc., which are specified in the names of the corresponding GOITER files.

Since each GOITER (AOW file) is encrypted using different file keys (FileKey), declassification of the encryption key used for one GOITTER file (AOW file) will not allow users to decrypt the remaining GOITER (AOW files). This means that in the case when storing the GOIT files (AOW files) in the flash memory board 31 is encrypted, the damage caused by declassifying one file key (FileKey) can be minimized.

{3-3_10-1} Internal structure of the file GOITER (AOW file)

Below is a description of the internal structure of the file GOITER (AOW file). Figure 10 shows the hierarchical data structure of the file GOITER (AOW file). In Fig. 10, the GOITER file (AOW file) is shown at the first level, and the sound object (GOITTER) (AOW) is shown at the second level. On the third level, ARE_BLOCKS is shown, on the fourth level is ALEMENT (AOB_ELEMENT), and on the fifth level is AOB_FRAME.

In FIG. 10, AOB_FRAME at the fifth level is the smallest constituent element of the GOITER (AOB) and consists of audio data in ADTS format (transport audio data stream) and an ADTS header. Sound data in ADTS format is encrypted in accordance with the MPEG2-AAC format (with a combination of parameters providing low integration), and they represent a stream of data that can be reproduced with a transmission speed from 16 kilobits / s to 144 kilobits / s. It should be noted that the bit rate for PCM (Pulse Code Modulation) (PCM) data recorded on a regular CD is 1.5 megabits per second, so for data in ADTS format, a lower bit rate is usually used. than for PCM. The sequence of Frames_Auto (AOB_FRAMEs) has the same data structure as the sequence of audio frames contained in the transport stream of audio data, which is sent by the electronic music distribution service. This means that the transport stream of audio data intended for storing in the form of a sequence FRAME_THE (AOB_FRAME) is encoded according to the MPEG2-AAC standard, encrypted, and transmitted to the consumer over a public network. Files GOITER (AOW file) are created by splitting the transmitted transport stream of audio data in the form of a sequence of FRAME_THE (AOB_FRAMEs) and storing these FRAME_THE (AOB_FRAMEs).

{3-3_10-1_11} MPEG2-AAC Standard

A detailed description of the MPEG2-AAC standard is given in ISO / IEC 13818-7: 1997 (E), Information Technology - Universal Coding for Moving Images and Related Audio Information - Part 7: Advanced Audio Coding (AIP) (AAS) ( "Information Technology - Generic Coding of Moving Pictures and Associated Audio Information - Part7 Advanced Audio Coding (AAC).")

It should be noted that compression of sound objects according to MPEG2-AAC can only be carried out using the parameters from the parameter table shown in Fig. 11A, which is specified in the ISO / IEC 13818-7 standard. This parameter table consists of the Parameter column, the Value column, and the Note column.

The designation “parameter set” given in the “Parameter” column indicates that only a set of parameters providing low integration (LC-profile) can be used, which is stipulated by the ISO / IEC 13838-7 standard. The symbol "sampling_frequency # index" in the "Parameter" column indicates that sampling frequencies of "48 kHz, 44.1 kHz, 32 kHz, 24 kHz, 22.05 kHz and 16 kHz" can be used .

The symbol “number_of_data_blocks_in_frame” (“number_of_data_blok_in_frame”) in the “Parameter” column indicates that the ratio is used: one header for one source_data_block.

It should be noted that, despite the fact that this explanation describes the option in which the encoding of AED_FRAMEs is performed in MPEG-AAC format, instead, the encoding of AED_FRAMEs can be carried out in accordance with another format, for example, in Level 3 MPEG format (MPEG-Layer3) (MP3) or in Windows Media Audio (WMA) format (sound environment format for the Windows operating system). In these cases, the parameters indicated in the parameter tables of FIG. 11B or FIG. 11B should be used.

{3-3_10-2_12} Structure of FRAME_THEAD (AOB_FRAME)

While each AOB_FRAME contains audio data that is encoded in accordance with the restrictions described above, the data length for the audio data in each AOB_FRAME is limited to a playback time of only 20 ms. However, since the MPEG2-AAC standard is a variable bit rate (VBR) encoding method, the data length for the audio data in each AOB_FRAME will change. Below is a description of the structure KADRA_ZOB (AOB_FRAME) with reference to Fig.12.

12, the general structure is shown at the first level, and the encryption of each part of AAD_FRAME is shown at the second level. From the drawing it can be seen that the ADTS header corresponds to the unencrypted part. Sound data contains both the encrypted part and the unencrypted part. The encrypted part of the audio data consists of many fragments with encrypted data of eight bytes each, each of which is created by encrypting an eight-byte fragment of the audio data using a 56-bit file key (FileKey). When the 64-bit fragments of the audio data are encoded, the unencrypted portion of the audio data is simply a finite portion of the data that cannot be encrypted because it is shorter than 64 bits.

12, the third level shows the contents of the ADTS header, which is located in the unencrypted part of AOB_FRAME. The ADTS header is seven bytes long and contains a 12-bit synchronization word (which is set to FFF), information about the data length for the audio data in this AOB_FRAME, and about the sampling frequency that was used when encoding the audio data.

{3-3_10-3_13} Setting AOB_FRAME frame length in bytes

13 shows how, in each of the three GOITER FRAMES (AOB_FRAMEs), the length of the audio data in bytes is set. In Fig. 13, audio data No. 1 (audio data # 1) contained in FRAME # 1 (AOB_FRAME # 1) has a data length of x1, audio data No. 1 (audio data # 1) contained in FRAME_ZOB No. 2 ( AOB_FRAME # 2), have a data length equal to x2, and audio data No. 1 (audio data # l) contained in FRAME_ZOB No. 3 (AOB_FRAME # 3) have a data length equal to x3. In the case when all the data has different data lengths x1, x2, and x3, the data length x1 is recorded in the ADTS header KADRA_ZOB No. 1 (AOB_FRAME # 1), the data length x2 is recorded in the ADTS header KADRA_ZOB No. 2 (AOB_FRAME # 2), and the length x3 of the data is recorded in the ADTS header KADRA_ZOB No. 3 (AOB_FRAME # 3).

Although the audio data is encrypted, the ADTS header is not encrypted, so that the playback device can find out about the data length for the audio data in AOB_FBAME by reading the data length information indicated in the ADTS HEADER (AOB_FRAME) header.

This concludes the description of KADRA_ZOB (AOB_FRAME).

{3-3_10-4} GOITER ELEMENT (AOB_ELEMENT)

The following is a description of ALEBLE (AOB_ELEMENT), which is shown in FIG. 10 at the fourth level.

"GOITER ELEMENT" (AOB_ELEMENT) is a group of consecutive GOITER_COUNT (AOB_FRAMEs). The number of GOALS (AOB_FRAMEs) in the GOITER (AOB_ELEMENT) depends on the value set as the sampling_frequency_index index shown in FIG. 11A and the encoding method used. The number of GOALS (AOB_FRAMEs) in the GOITER (AOB_ELEMENT) is set so that the total playing time of the contained GOALS (AOB_FRAMEs) is approximately equal to two seconds, and this number depends on the sampling frequency and the encoding method used.

{3-3_10-5_14} Number of GOITER_COUNT (AOB_FRAMES) in GOITER_OLE (AOB_ELEMENT)

On Fig shows the correspondence between the sampling frequency and the number of FRAMES_BOARDS (AOB_FRAMEs) contained in the element GOITER (AOB_ELEMENT). The number N shown in FIG. 14 represents the playing time of the AOB_ELEMENT in seconds. In the case where MPEG-AAC is used as the encoding method, the value of N is “2”.

When sampling_frequency is 48 kHz, the number of AOB_ELEMENTs contained in AOB_ELEMENT is set to 94 (= 47 * 2), and when sampling_frequency is 44.1 kHz ABOFRAME contained in ELEMENT_ZOB (AOB_ELEMENT) is set equal to 86 (= 43 * 2). When sampling_frequency is 32 kHz, the number of GOALS (AOB_FRAMEs) is set to 64 (= 32 * 2), when the sampling_frequency is 24 kHz, the number of GOALS (AOB_FRAMEs) is set to 48 (= 24 * 2) (sampling_frequency) is 22.05 kHz, the number of GOALS (AOB_FRAMEs) is set to 44 (= 22 * 2), and when the sampling_frequency is 16 kHz, the number of GOALS (AOB_FRAMEs) contained in the element AEZOBE_ 32 () (= 16 * 2). However, in the case when an editing operation was performed, for example, splitting GOITER (AOB), the number of GOALS (AOB_FRAMEs) contained in the element GOITER (AOB_ELEMENT) at the beginning or at the end of GOITER (AOB) may be less than their number , which is obtained by similar calculations.

Until a heading is created for each AOB_ELEMENT or other special information is provided, instead, the data length of each ALEBLE (AOB_ELEMENT) will be indicated in the time search table.

{3-3_10-6_15} One example of the playing time of GOITER (AOB_ELEMENTs) and GOITER_FRAMEs (AOB_FRAMEs)

On Fig shows one example of the duration of the playback ELEMENT_ GOITER (AOB_ELEMENTS) and FRAME_REA (AOB_FRAMEs). On Fig at the first level shows a lot of BLOCKS_ goiter (AOB_BLOCKs), and at the second level shows a lot of ELEMENTS_ goitre (AOB_ELEMEMTs). The third level shows a lot of FRAMES_THEAD (AOB_FRAMEs).

As shown in FIG. 15, AOB_ELEMENT has a playback time of about 2.0 seconds, and AOB_FRAME has a playback time of 20 milliseconds. The "TMPVR Element" (time search table element) ("TMSRT_entry") assigned to each GOITER (AOB_ELEMENT) indicates that the data length of each GOITER (AOB_ELEMENT) is given in the time search table. By referring to “TMSRT_entries”, the playback device can search forward or backward, for example, intermittently reproducing short segments by repeatedly reproducing audio data of 240 milliseconds duration and then skipping two seconds of audio data in the right direction.

{3-3_10-7} BLOCK_ GOITER (AOB_BLOCK)

This completes the description of CLEARING ELEMENT (AOB_ELEMENT). The following is a description of the concept of AOB_BLOCKs shown at the third level of the data structure of the GOITER file (AOW file) shown in FIG. 10.

Each "AOB_BLOCK" consists of the corresponding ALEBLE ELEMENTS (AOB_ELEMENTS). In each FILE_ GOITER (AOB_FILE) there is only one BLOCK_ GOITER (AOB_BLOCK). While AOB_ELEMENT ELEMENT has a playback time of about two seconds, AOB_BLOCK has a maximum playback time of 8.4 minutes. A limit of 8.4 minutes has been imposed in order to limit the size of the search table by time to 504 bytes or less.

{3-3_10-8} Restrictions on Time Search Table

The following is a detailed description of why the scope of the lookup table is limited in time by limiting the duration of playback.

When the playback device searches forwards or backwards, the playback device skips reading audio data for two seconds before playing back for 240 milliseconds. If two seconds of data were skipped, the playback device could theoretically access the data length information specified in the ADTS (AOB_FRAMEs) headers, although this would mean that to skip only two seconds of audio data, the playback device should perform sequential detection 100 (2 seconds / 20 milliseconds) GOALFRAME (AOB_FRAMEs). This would lead to excessive load when performing processing in the playback device.

To reduce the load during processing in the playback device, the read addresses for the data at intervals of two seconds can be recorded in the time search table, which is then accessed by the playback device when performing a search in the forward or reverse direction. By recording information that allows you to quickly detect read addresses that are two or four seconds in the forward or backward direction by the time search table (such information is the data volumes of ELEMENT_ZOB (AOV_ELEMENTS)), when performing a search in the forward or reverse direction, the playback device should simply access this information. The amount of data for audio data having a playback time of two seconds will depend on the binary data rate used to play the audio data. As indicated earlier, a binary data rate of 16 kbit / s (kilobits per second) to 144 kbit / s is used, so that the amount of data played in two seconds is in the range of 4 Kbit (= 16 Kbit / s s x 2/8) to 36 kbps (= 144 kbps x 2/8). Since the amount of data reproduced in two seconds ranges from 4 kbps to 36 kbps, the data length of each element in the time search table must be two bytes (= 16 bits) to record the length of the audio data. This is because a number in the range of 0-64 kbps can be displayed using a 16-bit value.

However, if there is a need for the total amount of data in the lookup table to be limited to 504 bytes (this is equal to the amount of data in the TKTMSRT, as described below), then, for example, the maximum number of items in the lookup table over time can be calculated as 504/2 = 252.

Since a recording element is created every two seconds, the playback time corresponding to their maximum number of 252 elements is 504 seconds (= 2s * 252), or, in other words, 8 minutes and 24 seconds (= 8.4 minutes). This means that setting the maximum playback duration for BLOCK_THE (AOB_BLOCK) to 8.4 minutes limits the amount of data in the lookup table by time to 504 bytes.

{3-3_10-9} Description of Sound Objects (GOITERS) (AOBs)

This completes the description of AOB_BLOCKs. The following is a description of GOITERS (sound objects) (AOBs).

GOITER (AOW) shown in the second level of Fig. 10 are areas having unreliable areas at both ends. Each GOITER (AOW file) contains only one GOITER (AOW).

The irregular sections are areas that are read and written with AOB_BLOCKs and stored in the same clusters as AOB_BLOCKs. The start and end positions of GOITER blocks (AOB_BLOCKs) in GOITER (AOW) are indicated by TIB (block information tables) (BITs) contained in the navigation data. A detailed description of these TIBs is given below.

This completes the explanation of what data is stored in the file GOITER (AOW file). The following is a description of what content is reproduced by sequentially reading the eight GOITERS (AOB) and GOITER BLOCKs (AOB_BLOCKs) shown in the GOITER (AOW file) of FIG. 9.

{3-3_10-10_16}

On Fig shows the reproduced content by sequentially reading GOITER (AOW) and BLOCK_ GOITER (AOB_BLOCKs) in this file GOITER (AOW file). On Fig on the first level shows eight files GOITER (AOW files) in the user area, and on the second level shows eight GOITERS (AOW) recorded in these files GOITER (AOW files). At the third level, eight AOB_BLOCKs are contained in these GOITERS (AOB).

The fifth level shows the headers of the five parts of the information content formed by these goiter files (AOW files). In this example, the “content items” are five songs: “Song A” (SongA), “Song B” (SongB), “Song C” (SongC), “Song G” (SongD) and “Song D” (SongE) ), and a “piece of music” is a music album consisting of these five songs. The dashed lines AS1, AS1, AS3, ... AS7, and AS8 indicate the correspondence between BLOCKs and those parts into which the album is divided, and the fourth level of Fig. 16 shows the units that were used to divide the parts of the music album shown on the fifth level.

With reference to the dashed lines, it can be noted that BLOCK_ GOITER (AOB_BLOCK) contained in GOITER No. 1 (AOB # 1) is a song (Song A) (SongA), the playback time of which is 6.1 minutes. BLOCK_ GOITER (AOB_BLOCK), contained in GOITER No. 2 (AOB # 2), is a song (Song B) (SongB), the duration of which is 3.3 minutes. BLOCK_ GOITER (AOB_BLOCK), contained in GOITER No. 3 (AOB # 3), is a song (Song B) (SongC), the playback duration of which is 5.5 minutes. Thus, each of the files “AOB001.SA1” through “AOB003.SA1” corresponds to different songs. The sixth level in FIG. 16 is a sequence of phonograms consisting of phonograms starting from Phonogram A (TrackA) and ending with “Phonogram D” (TrackE). These phonograms from “Phonogram A” to “Phonogram D” (TrackA-TrackE) correspond to five songs: “Song A” (Son-gA), “Song B” (SongB), “Song B” (SongC), “Song G” "(SongD) and" Song D "(SongE), each of which is considered a separate unit of reproduction.

On the other hand, GOITER # 4 (AOB # 4) has a playing time of 8.4 minutes and represents the first (or “initial”) part of the song “Song G” (SongD) having a playing time of 30.6 minutes. GOAL BLOCKS (AOB_BLOCKs) contained in GOITER # 5 (AOB # 5) and GALL # 6 (AOB # 6) are the middle parts of the song “Song G” (SongD) and also have a playback time of 8.4 minutes. BLOCK_ GOITER (AOB_BLOCK), contained in GOITER No. 7 (AOB # 7), represents the final part of the song “Song G” (SongD) and has a playback time of 5.4 minutes. Thus, a song that has a total playing time of 30.6 minutes is divided into parts (8.4 + 8.4 + 8.4 + 5.4 minutes), each of which is contained in a different GOITER (AOB) . From Fig.16 shows that the maximum duration of the playback of each song contained in the file GOITER (AOW file), can not be more than 8.4 minutes.

This explanation clearly shows that the above-described limitation of the duration of the reproduction of sound objects (SCA) (AOB) limits the amount of data in the search table by the time corresponding to each GOITER (AOB). The following is a description of the navigation data contained in each time search table.

{3-3_8A, B-2}

The navigation data consists of the two previously mentioned files "SD_Audio.PLM" and "SD_Audio.TKM". the file "SD_Audio.PLM" contains the administrator of the list of playable files (PlaylistManager), and the file "SD_Audio.TKM" contains the administrator of the phonograms (TrackManager).

As mentioned in the description section for reproducible data, the encoded GOITER (AOW) is stored in a variety of GOITER files (AOW files), but they do not contain any other information, for example, about the duration of the GOITER (AOW), the names of the songs displayed by the GOITER (AOB), or a list of songwriters. While a plurality of GOITERS (AOW) are recorded in a plurality of GOITER files (AOW files), no guidance is provided regarding the playback order of the GOITER (AOW). To ensure the transmission of such information to the playback device, a phonogram manager (TrackManager) and an administrator of the list of playable files (PlaylistManager) are provided.

The Phonogram Administrator (TrackManager) indicates the correspondence between the GOITERS (AOBs) recorded in the GOITER files (AOW files) and the phonograms, and contains a lot of pieces of phonogram control information, each of which provides a lot of information, for example, about the duration of the GOITER ( AOB), song titles and songwriters of various GOITERS (AOB).

In this description, the term “phonogram” refers to a user-friendly reproduction unit, so that when the copyrighted music is stored in the flash memory board 31, each song is a separate phonogram. Otherwise, when a “voiced book” is recorded in the flash memory board 31 (that is, copyrighted literature that is stored as an audio recording), each chapter or paragraph can be represented as a separate phonogram. To manage multiple GOITERS (AOW) recorded in multiple GOITER files (AOW files) in the form of a set of phonograms, a phonogram manager (TrackManager) is created.

The playlist (Playlist) sets the playback order of many phonograms. The administrator of the list of playable files (PlaylistManager) can contain many lists of playable files (Playlists).

Below is a description of the phonogram administrator (TrackManager) with reference to the drawings.

{17-1_18} Detailed structure of the administrator of the list of playable files (PlaylistManager) and the administrator of phonograms (TrackManager)

On Fig shows a detailed hierarchical structure of the administrator of the list of playable files (PlaylistManager) and the administrator of the phonograms (TrackManager) in this embodiment. On Fig shows the volume of the administrator of the list of playable files (PlaylistManager) and the administrator of phonograms (TrackManager). On the right side of FIG. 17, a more detailed explanation of the objects on the left is shown, and dashed lines indicate which objects are shown in more detail.

As shown in FIG. 17, the phonogram manager (TrackManager) consists of phonogram information information (IDF) (TKI) No. 1, No. 2, No. 3, No. 4 ... No. n, which is indicated by the dashed line h1. These IDFs (TKIs) represent information for managing GOITERS (AOW) recorded in goiter files (AOW files) in the form of phonograms, and each of them correspond to different GOITER files (AOW files). From Fig.17 it can be seen that each IDF (TKI) consists of General_information_of_phonogram (OIFG) (Track_General_Information) (TKGI), Text_information_of_phonogram (OD_TKINFG data area of text information about the phonogram) (Track_Text_Information) (TKTX text that can be written to intended exclusively for the phonogram, and the Phonogram Search Table by time (TPFGPVR) Track_Time_Search_Table (TKTMSRT), which serves as a time search table.

From Fig. 18 it is seen that each IDF (TKI) has an unchanged volume of 1024 bytes, which means that the total amount of OIFG (TKGI) and OD_TKINFG (TKTXTI_DA) is set to 512 bytes due to the fact that the volume of TPFGPVR (TKTMSRT) is set equal to 512 bytes. In the phonogram manager (TrackManager), the total number of IDFs (TKI) can be set to 999.

As shown by the dashed line h3, TPFGPVR (TKTMSRT) consists of TITLE_TPPVR (TMSRT_HEADER) and from TPPP Elements №1, №2, №3, ... №n (TMSRT ENTRIES # 1, # 2, # 3 ... #n )

{17-2_19} Compliance of IDF (TKI) files with GOITER (AOW files) and GOITER (AOW)

On Fig shows how the IDF (TKI) shown in Fig correspond to the files GOITER (AOW files) and GOITER (AOW), which are shown in Fig.16. In Fig. 19, the rectangles on the first level indicate the sequence of phonograms, which consists of phonograms from Phonogram A to Phonogram D (TrackA - TrackE), the large frame on the second level indicates the phonogram administrator (TrackManager), and on the third and fourth levels those eight files are shown GOITER (AOW files), which are shown in Fig.16. These eight GOITER files (AOW files) are recorded in eight GOITER (AOW) shown in Fig. 16, and they form a music album containing phonograms: "Phonogram A" (TrackA), "Phonogram B" (TrackB), " Phonogram B "(TrackC),

“Phonogram D” (TrackD), and “Phonogram D” (TrackE). The second level shows eight IDFs (TKI). The numbers "1", "2", "3", "4" assigned by each IDF (TKI) are serial numbers that are used to identify each IDF (TKI), and each IDF (TKI) corresponds to that GOITER (AOW) file file), which is assigned the same serial number 001, 002, 003, 004, 005 ....

With this in mind, it can be seen from Fig. 19 that IDF No. 1 (TK1 # 1) corresponds to the file "AOB001.SA1", that IDF No. 2 (TK1 # 2) corresponds to the file "AOB002.SA1", IDF No. 3 (TKI # 3) correspond to the file "AOB003.SA1", and IDF No. 4 (TKI # 4) correspond to the file "AOB004.SA1". The correspondence between the IDF (TKI) and the FRAMEs (AOB_FRAMEs) is indicated in FIG. 19 by the arrows TA1, TA2, TA3, TA4 ....

Thus, each IDF (TKI) corresponds to a different GOITER (AOW) recorded in the GOITER (AOW file) and gives detailed information that applies only to the corresponding GOITER (AOW).

{17-3_20} Data structure TPFGPVR (TKTMSRT)

The following is a description of information that relates to single GOITERS (AOW) recorded in GOITER files (AOW files), starting with TPFGPVR (TKTMSRT). On Fig shows in detail the data structure TPFHPVR (TKTMSRT).

On the right side of FIG. 20, a detailed data structure of the header of the time search table (TITF_Header_Title) (TMSRT_Header) is shown. In FIG. 20, the TMPRH_Header_TMSRT_Header has a data volume of eight bytes and consists of three fields. The first two bytes are TTPVR_ID (time search table identifier) (TMSRT_ID), the next two bytes are reserved, and the final four bytes are the total Number of GPT_V_Relements (Total_TMSRT_entry_Number).

In the field "ID_TPRVR" ("TMSRT_ID") write a unique identifier for identifying the TPVR. In the "Total TMSRT_entry_Number" field, write the total number of TMSRT_entries contained in the currently used TMSRT.

{17-3_21-1} Case Study TPFHRMR (TKTMSRT)

Below is a detailed description of TPFGPVR (TKTMSRT). On Fig shows one example of TPFGPVR (TKTMSRT). On the left side of Fig.21 shows GOITER (AOW), and on the right side shows the corresponding TPFGPVR (TKTMSRT). GOITER (AOW) in the left part of Fig. 21 consists of a set of numbered GOITER ELEMENTS No. 1, No. 2, No. 3 ... No. n (AOB_ELEMENTs # 1, # 2, # 3 ... #n), which are located in areas with numbers AR1, AR2, AR3 ... ARn, shown on the right.

The numbers "0", "32000", "64200", "97000", "1203400" and "1240000" indicate the relative addresses of the areas AR1, AR2, AR3, ARn-1, ARn occupied by AOB_ELEMENTS elements relative to the beginning BLOCK_ZOB (AOB_BLOCK). For example, ITEM_ GOITER # 2 (AOB_ELEMENT # 2) is recorded in the place that is located at a distance of "32000" from the beginning of BLOCK_ZOB (AOB_BLOCK), ITEM_CHAM # 3 (AOB_ELEMENT # 3) is recorded in the place which is located at a distance of "64200" from the beginning of BLOCK_ZOB (AOB_BLOCK), and the ELEMENT_ZOB No. (n-1) (AOB_ELEMENT # n-1) is recorded in the place which is located at a distance of "1203400" from the beginning of BLOCK_ZOB (AOB_BLOCK).

It should be noted that the distance between each occupied area and the beginning of AOB_BLOCK is not a multiple of any value, which means that the areas where AOB_ELEMENTs are located are not the same in size. The reason that the occupied areas have different sizes is to use a different amount of data to encode each of the AOB_FRAME FRAMES.

Since the size of the area occupied by each AOB_ELEMENT ELEMENT (AOB_ELEMENT) is different, before proceeding to the beginning of the AOB_ELEMENT ELEMENT (AOB_ELEMENT), it is necessary to notify the playback device in advance of the location of each AOB_ELEMENT ELEMENT (AOB). To do this, in the TPFGPVR (TKTMSRT) create a lot of Elements_TPPVR (TMSRT_entries). The arrows RT1, RT2, RT3 ... RTn-1, RTn show the correspondence between the areas AR1, AR2, AR3 ... ARn-1, Arn occupied by each GOIT_ELEMENT element (AOB_ELEMENT), and TPPVR element # 1 (TMSRT_entry # 1), TPPVR element No. 2 (TMSRT_entry # 2), Element_TRPVR No. 3 (TMSRT_entry # 3), ... Element_RSTVR No. (n-1) (TMSRT_entry # n-1), Element_RSTVR No. n (TMSRT_entry # n). In other words, the size of the AR1 area occupied by the GOITTEN ITEM_1 (AOB_ELEMENT # 1) is recorded in Element_TRPVR No. 1 (TMSRT_entry # 1), and the sizes of the AR2 and AR3 areas are recorded in Elements_TRPVR No. 2 and No. 3 (TMSRT_entry # 2, # 3) in which are located ELEMENT_ZOB №2 (AOB_ELEMENT # 2) and ELEMENT_ZOB №3 (AOB_ELEMENT # 3).

Since the filled section AR1 occupies the area from the beginning of GOITER (AOW) to the beginning of GOITER # 2 (AOB_ELEMENT # 2) "32000", the size "32000" (= 32000-0) is recorded in Element_TPPVR No. 1 (TMSRT_entry # 1). The filled AR2 section occupies the area from the beginning of GOAL ITEM # 2 (AOB_ELEMENT # 2) "32000" to the beginning of GOAL ITEM # 3 (AOB_ELEMENT # 3) "64200", therefore, the size "32200" (= 64200) is written to Element_TPPVR No. 2 (TMSRT_entry # 2) -32000). The filled AR3 section occupies the area from the beginning of GOAL ITEM # 3 (AOB_ELEMENT # 3) “64200” to the beginning of GOAL ITEM # 4 (AOB_ELEMENT # 4) “97000”, therefore, the size “32800” (= 97000) is written to Element_TRAC # 3 (TMSRT_entry # 3) -64,200). In the same way, the filled ARn-1 section occupies the area from the beginning of GOITER ITEM No. (n-1) (AOB_ELEMENT # n-1) "1203400" to the beginning of GOITER ITEM_Number (AOB_ELEMENT # n) "1240000", and in Element_TPPVR No. (n- 1) (TMSRT_entry # n-1) record the size "36600" (= 1240000-1203400).

{17-3_21-2} Implementation of reading TPFGPVR (TKTMSRT)

Thus, in the time search table, the data volumes of CLEANING ELEMENTS (AOB_ELEMENTs) were recorded. However, since the data length of each GOITER (AOB_BLOCK) is limited to a maximum value of 8.4 minutes, the total number of GOITER ELEMENTS (AOB_ELEMENTs) contained in one GOITER (AOB) is limited to a predetermined number (“252”, as shown in FIG. 20) or less of it. Since the number of GOITERS (AOB_ELEMENTS) is limited, the number of TOBAC Elements (TMSRT_entries) corresponding to GOITELS (AO_ELEMENTs) is also limited, which limits the amount of TFPTMSRT containing these TPMSTent_MS to the predetermined TMS volume (TMS). Since the scope of TPSFMR (TKTMSRT) is limited, the playback device can read and use IDFs (TKIs) as follows.

The playback device reads a specific GOITER (AOW) and at the beginning of the playback GOITER (AOW) reads the corresponding IDF (TKI) and stores them in memory. These corresponding IDFs (TKIs) are stored in memory as long as the reproduction of this GOITER (AOW) continues. When the playback of GOITER (AOW) ends, the next GOITER (AOW) is read, and when playback of this GOITER (AOW) begins, the playback device overwrites the IDFs (TKI) corresponding to this next GOITER (AOV) in memory instead of the previous IDFs (TKI) ) These next IDFs (TKIs) are stored in memory as long as the reproduction of this next GOITER (AOW) continues.

By reading and storing the IDF (TKI) of this kind, the required memory capacity in the reproducing apparatus can be minimized while it is possible to perform special reproducing functions, such as searching in the forward and reverse directions. Although the present embodiment describes an example in which the data length from the first address of the AOB_ELEMENT element to the first address of the next AOB_ELEMENT element is recorded in the TMSRT_entry Element, relative addresses from the beginning of the AOBBL block can be recorded in it ) to the first addresses of GOAL ELEMENTS (AOB_ELEMENTs).

{17-3_21-3} Definition of a cluster containing A CART ELEMENT (AOB_ELEMENT)

The following is a description of how the reading of AOB_ELEMENT ELEMENT using TKTMSRT can be accomplished. TPFGPVR (TKTMSRT) contains the volume of each GOITER (AOB_ELEMENT), therefore, in the case when it is necessary to read ITEM_THE GOITER #y (AOB_ELEMENT # y), which is the y-th element GOITER (AOB_ELEMENT) from the beginning of GOITER, ARE GOAL (OOB) a cluster u satisfying the Equation 1 below, and read data located with a shift v from the beginning of the cluster u.

Equation 1

Cluster u = (The total number of Elements_TPPVR from ELEMENT_ GOITER No. 1 to ELEMENT_ GOITER No. (y-1) + DATA_Shift) / Cluster size

Shift v = ((The total number of Elements_TPPVR from ELEMENT_ZOB №1 to ELEMENT_ZOB № (y-1) mod Cluster size,

where the expression “c = a mod b” means that “c” is the residue obtained by dividing “a” by “b”.

DATA_Offset is recorded in the TIB (BIT), and its description is given below.

{17-4} ODKTINFG (data area for phonogram text information) (TKTXTI_DA)

This completes the description of the time search table (TPFGPVR) (TKTMSRT). The following is a description of the Text_Information_On_phonogram Data Area (OD_TKINFG) (Track_Text_Information Data Area) (TKTXTI_DA), which is recorded at the top of the TPFGPVR (TKTMSRT).

Data area of Text_information_on_phonogram

(OD_TKINFG) (TKTXTI_DA) is used to store textual information in which the artist’s name, album name, sound engineer, producer and other similar information are indicated. This area is created even when such textual information does not exist.

{17-5} OIFG (General information about the phonogram) (TKGI)

The following is a description of the OIFG (TKGI), which is written in the upper part of the OD_TKINFG (TKTXTI_DA). On Fig shows several data sets, such as identifier "ID_ID" (TKI_ID) for IDF (TKI), IDF number (TKI) "NIDF" (TKIN), volume IDF (TKI) "OB_IDF" (TKI_SZ), communication indicator with the following IDF (TKI) "UKZ_SVZ_IDF" (TKI_LNK_PTR), attributes of the block "ATR_BLK_IDF" (TKI_BLK_ATR), duration of playback "PR_VP_IDF" (TKI_RV_TM), sound data attributes "ATR_ZOBK_ZOBK_ZOB_TZ_K_ZOB_TZ_K_ZOB_ID (ISRC), and information about the blocks "TIB" (BIT). It should be noted that in order to simplify the presentation, only a part of this information is shown in FIG.

{17-5_22-1} OIFG (TKGI)

The following is a detailed description of the structure of UIFG (TKGI) with reference to Fig.22. The difference between Fig.17 and Fig.22 is that on the left side of this drawing shows the data structure of the OIFG (TKGI) shown in Fig.17, and that the structure of the bits "ATR_BLK_IDF" (TKI_BLK_ATR), "ATR_ZOB_IDF" ( TKI_AOB_ATR) and ISCO (ISRC).

{17-5_22-2} IDF ID (TKI_ID)

In the field "ID_IDF" (TKI_ID) write a unique identifier for IDF (TKI). In the present embodiment, the double-byte code “A4” is used.

{17-5_22-3} NIDF (TKIN)

In the field "NIDF" (TKIN) write the IDF number (TKI) in the range from 1 to 999. It should be noted that the NIDF (TKIN) of each IDF (TKI) is unique. In the present embodiment, the location of each IDF (TKI) in the phonogram manager (TrackManager) is used as a NIDF (TKIN). This means that “1” is written as IDF number (TKI) for IDF No. 1 (TKI # 1), and “2” is written as IDF number (TKI) for IDF No. 2 (TKI # 2), and as IDF numbers (TKI) for IDF No. 3 (TKI # 3) record "3".

{17-5_22-4} OB_IDF (TKI_SZ)

In the field "OB_IDF" (TKI_SZ) write the amount of IDF data (TKI) in bytes. 22, an IDF data volume (TKI) is set to 1024 bytes, therefore, each IDF (TKI) in the present embodiment has a length of 1024 bytes.

{17-5_22-5} UKZ_SVZ_IDF (TKI_LNK_PTR)

In the field "UKZ_SVZ_IDF" (TKI_LNK_PTR) write NIDF IDF (TKIN TKI), which are associated with these IDF (TKI). The following is a description of similar relationships between IDF (TKI).

When a phonogram consists of a set of GOITERS (AOW) recorded in a set of GOITER files (AOW files), then these Goiter files (AOW files) are managed as a single phonogram by linking together a set of IDFs (TKIs) that correspond to these GOITER (AOW) files files). To link multiple IDFs (TKI) to each other, you must specify the IDF (TKI) file GOITER (AOW file), which follows the file call (AOV file) currently used IDF (TKI). Therefore, in UKZ_SVZ_IDF (TKI_LNK_PTR) record NIDF those IDFs (TKIN TKI), which follow the IDF (TKI) currently used.

{17-5_22-6_19} UKZ_SVZ_IDF (TKI_LNK_PTR)

Below is a description of the parameter settings performed for UKZ_SVZ_IDF (TKI_LNK_PTR) in eight IDF (TKI) shown in Fig.19. Each phonogram information data numbered No. 1 through No. 3 and No. 8 corresponds to individual phonograms, therefore no information is entered into their UKZ_SVZ_IDF (TKI_LNK_PTR). Information on the phonogram IDF No. 4, IDF No. 5, IDF No. 6, IDF No. 7 (TKI # 4, TKI # 5, TKI # 6, TKI # 7) correspond to four GOITER files (AOW files) that form the phonogram G ( TrackD), therefore, in UKZ_SVZ_IDF (TKI_LNK_PTR) of these IDFs (TKI) indicate information about the next phonogram. As shown in FIG. 19, arrows TL4, TL5, and TL6, in UKZ_SVZ_IDF (TKI_LNK_PTR) IDF No. 4 (TKI # 4) set the value "IDF No. 5" (TKI # 5), in UKZ_SVZ_IDF (TKI_LNK_PTR) IDF No. 5 (TKI_LNK_PTR) # 5) set the value "IDF No. 6" (TKI # 6), and in UKZ_SVZ_IDF (TKI_LNK_PTR) IDF No. 6 (TKI # 6) set the value "IDF No. 7" (TKI # 7).

As a result, the playback device can access UKZ_SVZ_IDF (TKI_LNK_PTRs), which are indicated in the IDF (TKI) corresponding to these four GOITER files (AOW files), thus finding out that these four IDF (TKI) with IDF No. 4 (TKI # 4) according to IDF No. 7 (TKI # 7) and these four goiter files (AOW files) from "AOB004.SA1" to "AOB007.SA1" form one phonogram. Phonogram G (TrackD).

{17-5_22-7} ATR_BLK_IDF (TKI_BLK_ATR)

In the field "ATR_BLK_IDF" (TKI_BLK_ATR) write the attributes of the currently used IDF (TKI). In Fig. 22, dashed lines coming from ATR_BLK_IDF (TKI_BLK_ATR) indicate information that explains the bit structure of ATR_BLK_IDF (TKI_BLK_ATR). 22, ATR_BLK_IDF (TKI_BLK_ATR) is shown to be 16 bits long, with bits b3 through b15 being reserved for future use. Three bits from bits b2 through b0 are used to indicate the IDF attributes (TKI).

When only IDFs (TKI) correspond to the whole phonogram, then the value “00b” is written in ATR_BLK_IDF (TKI_BLK_ATR) (this set value is hereinafter referred to as the “Phonogram”). When several IDFs (TKI) correspond to the same phonogram, then in ATR_BLK_IDF (TKI_BLK_ATR) of the first IDFs (TKI) the value “001b” is recorded (this set value is hereinafter referred to as “Beginning of the Phonogram” (“Head_of_Track”)), in ATR_BLKRF_BLK_BLK_BLK_BLK_BLK_BLK_BLK_BLK_BLK_BLK_BLK_BLK_BLK_BLK_BLK_BLK_BLK_BLK_BLK_BLK_BLK_BLK_BLKIDBL ) those IDFs (TKI) that correspond to GOITTER (AOW) in the middle of the phonogram record the value "010b" (this set value is hereinafter referred to as the "Midpoint Phonogram" ("Midpoint_of_Track")), and in the ATR_BLK_IDF (TKI_BLK_ATR) of those IDFs (TKI) which correspond to GOITER (AOW) at the end of the phonogram record the value "011b" (this set value is hereinafter referred to as "K ntsom phonogram "(" End_of_Track ")). In the case when an IDF (TKI) is not used, but an IDF area (TKI) exists, that is, when there are remote IDFs (TKI), in the ATR_BLK_IDF (TKI_BLK_ATR) write the value "100b" (this set value is hereinafter referred to as " Unused "). When an IDF (TKI) is not used, and an IDF area (TKI) does not exist, then the value "101b" is written in ATR_BLK_IDF (TKI_BLK_ATR).

{17-5_22-8_19} Example of setting the values ATR_BLK_IDF (TKI_BLK_ATR)

Below is a description of setting the values ATR_BLK_IDF (TKI_BLK_ATR) for each IDF (TKI) in the example shown in Fig.19.

With reference to the ATR_BLK_IDF (TKI_BLK_ATR) of each IDF (TKI) it can be seen that each of the four pairs of IDF No. 1 is "AOB001.SA1"), IDF No. 2 ("AOB002.SA1"), IDF No. 3 ("AOV003. SA1") and IDF No. 8 ("AOB008.SA1") [TKI # 1 ("AOB001.SA1"), TKI # 2 ("AOB002.SA1"), TKI # 3 ("AOB003. SA1"), TKI # 8 (" AOB008 ".SA1")] corresponds to separate phonograms, since ATR_BLK_IDF (TKI_BLK_ATR) of each of IDF No. 1, IDF No. 2, IDF No. 3 and IDF No. 8 (TKI # I, TKI # 2, TKI # 3, TKI # 8) set to Phonogram.

ATR_BLK_IDF (TKI_BLK_ATR) IDF No. 4 (TKI # 4) is set as "Begin_Phonograms" ("Head_of_Track"), ATR_BLK_IDF (TKI_BLK_ATR) IDF No. 7 (TKI #K_K_K_K_KL_FR ) IDF No. 5 and IDF No. 6 (TKI # 5, TKI # 6) are set as "Mid_Phonograms" ("Midpoint_of_Track"). This means that the file GOITER (AOW file) ("AOB004. SA1"), corresponding to IDF No. 4 (TKI # 4), is the beginning of the phonogram, the files GOITER (AOB files) ("AOB005.SA1") and ("AOB006. SA1 "), corresponding to IDF No. 5 and IDF No. 6 (TK1 # 5, TK1 # 6), are the middle parts of the phonogram, and the GOITER file (AOW file) (" AOB007.SA1 "), corresponding to IDF No. 7 (TKI # 7 ) is the end of the phonogram.

By organizing the sets of IDF (TKI) and corresponding goiter files (AOW files) in accordance with the settings ATR_BLK_IDF (TKI_BLK_ATR) in IDF (TKI), it can be seen that the combination of IDF No. 1 (TKI # I) and "AOB001.SA1" forms the first phonogram (Soundtrack A) (TrackA). Similarly, the combination of IDF No. 2 (TKI # 2) and "AOB002.SA1" forms the second phonogram (Phonogram B) (TrackB), and the combination of IDF No. 3 (TKI # 3) and "AOB003.SA1" forms the third phonogram (Phonogram B) (TrackC). The combination of IDF No. 4 (TKI # 4) and "AOB004.SA1" forms the first part of the fourth phonogram (Phonogram G) (TrackD), the combination of IDF No. 5 (TKI # 5) with "AOB005.SA1" and IDF No. 6 (TKI # 6) with "AOB006.SA1" form the middle parts of Phonogram G (TrackD), and the combination of IDF No. 7 (TKI # 7) and "AOB007.SA1" form the final part of Phonogram G {TrackD). Finally, the combination of IDF No. 8 (TKI # 8) and "AOB008.SA1" forms the fifth phonogram (Phonogram D) (TrackE).

{17-5_22-9} PR_VP_IDF (TKI_RV_TM)

In the field "PR_VP_IDF" (TKI_RV_TM) IDF (TKI) record the duration of the soundtrack (song) consisting of GOITER (AOW) recorded in the corresponding IDF (TKI) file GOITER (AOV file).

When a phonogram consists of a set of IDFs (TKI), the full duration of the phonogram playback is recorded in the PR_VP_IDF (TKI_RV_TM) of the first IDFs (TKI) corresponding to the phonogram, and the duration of the corresponding GOITER (AOW) is recorded in the second and subsequent IDF (TKI) phonograms.

{17-5_22-10} ATR_ZOB_IDF (TKI_AOB_ATR)

In the field "ATR_CRAFT_IDF" (TKI_АОВ_ATR) IDF (TKI), write down the encoding conditions that were used to create the GOITER (AOW), that is, information such as (1) the sampling frequency at which the GOITER (AOW) recorded in corresponding GOITER (AOW file) file, (2) binary data rate and (3) number of channels. On Fig dashed lines going from "ATR_ZOB_IDF" (TKI_AOB_ATR), shows the structure ATR_ZOB_IDF (TKI_AOB_ATR) in bits.

As shown in FIG. 22, ATR_THE_IDF (TKI_AOB_ATR) consists of 32 bits, the encoding mode being recorded in a four-bit field from bit b16 to bit b19. In the case when the coding of GOITERS (AOW) is carried out in accordance with the MPEG-2 AAC standard (with the ADTS heading), then the value "0000b" is written in this field, and when the encoding of GOITERS (AOW) is carried out in accordance with the MPEG 3- standard level (MPEG-Layer 3) (MP3), then the value "0001b" is written to it. When the encoding of the CALL (AOW) is carried out in the format of the sound environment for the Windows operating system (Windows Media Audio) (WMA), then the value "0010b" is written in this field.

The binary data rate that was used when encoding GOITER (AOW) is recorded in a field of eight bits between bit b15 and bit b8. In the case when the encryption of GOITER (AOW) is carried out according to the MPEG-2 AAC standard (with the ADTS heading), then the value from "16" to "72" is written in this field, and when the encryption of GOITER (AOW) is carried out according to the MPEG1 3 standard level (MPEGl-Layer 3) (MP3), then the value from "16" to "96" is recorded in it. When GOITER (AOW) is encoded according to the 3rd level MPEG1 standard with communication channel support function (MPEGl-Layer 3 LSF) (MP3), then the value from "16" to "80" is written in this field, and when GOITER is encoded ( AOB) is implemented in the sound environment format for the Windows operating system (Windows Media Audio) (WMA), then a value from "8" to "16" is written in this field.

The sampling frequency that was used when encoding GOITER (AOW) is recorded in a field of four bits between bit b7 and bit b4. When the sampling frequency is 48 kHz, the value "0000b" is written in this field. When the sampling frequency is 44.1 kHz, then this value is “00001b” when the sampling frequency is 32 kHz, this value is “0010b” when the sampling frequency is 24 kHz, this value is “0011b” when the sampling frequency is 22 , 05 kHz, this value is “0100b”, and when the sampling frequency is 16 kHz, this value is “0101b”.

The number of channels is recorded in a field of three bits from bit b3 to bit b1. In the case when one channel is used (that is, monaural mode), the value "000b" is written in this field, and when two channels are used (that is, in stereo mode), the value "001b" is written in this field.

A field of twelve bits from bit b31 to bit 20, as well as bit b0, are reserved for future use.

{17-5_22-11} ISCO (International Standard Recording Code) (ISRC)

An ISCO (International Standard Code for Recording) (ISRC) is recorded at the TIFG (TKGI). In FIG. 22, the contents of ISCO (ISRC) are shown in dashed lines from the “ISRC” field. As shown in the drawing, ISCO (ISRC) consists of ten bytes, and the code of the recorded element (Recording-item code) (No. 12) is written in the field of four bits between bit b4 and bit b7. Recording code / Recording code / Recording-item code (No. 11) is recorded in a four-bit field between bit b8 and bit b11.

The recording code (ISCO No. 10, No. 9, No. 8) (ISRC # 10, # 9, # 8) is recorded in a field of twelve bits between bit b2 and bit b23. The year-of-recording code (ISCO # 6, # 7) (ISRC # 6, # 7) is recorded in a field of eight bits from bit b24 to bit b31.

The code of the first owner (First Owner Code) (ISCO No. 3, No. 4, No. 5) (ISRC # 3, # 4, # 5) is written in a field of six bits between bit b32 and bit b37, in a field of six bits between bit b40 and bit b45, and in a six-bit field between bit b48 and bit b53. The Country Code (ISCO # 1, # 2, # 3) (ISRC # 1, # 2, # 3) is written in a six-bit field between bit b56 and bit b61 and in a six-bit field between bit b64 and bit b69. A single-bit Validity flag is recorded in a single-bit field consisting of bit b79. A detailed description of ISCO can be found in document 1303901: 1986, "Documentation-International Standard Recording Code (ISRC)".

{17-5_22-12_23A-1} TIB (BIT)

A "Block Information Table" (TIB) (BIT) is a table for controlling AOB_BLOCK, a detailed structure of which is shown in Fig. 23A and Fig. 23B.

As shown in Fig. 23A, a TIB (BIT) consists of a DATA_DIFFERENT (DATA_OFFSET) field, which occupies an area from 60th byte to 63rd byte, an OBDATA field ("data volume" - (SZ_DATA), which occupies an area of 64 -th byte by 67th byte, fields KOL_ETPPVR (“the number of elements in the time search table (TPRVR)” (TMSRTE_NS), which occupies the area from 68th byte to 71th bytes, field KOLK_1go_ETPPR (“number of frames in the first to the TPNR element (FNs_1st_TMSRTE), which occupies the area from the 72nd byte to the 73rd byte, the field KOLK_POSL_ETPPVR ("the number of frames in the last TPNR element" (FNs_Last_TMSRTE), which occupies the area from 74th byte to 75th byte, the field KOLK_Medium_ETPPVR (“the number of frames in the middle elements of the TPPVR” ((FNs_Last_TMSRTE), which occupies the area from the 76th byte to the 77th byte, and the field CONTINUOUS_TIME ("duration by time "- approx. translator) (TIME_LENGTH), which occupies the area from the 78th byte to the 79th byte.

A detailed description of each of these fields is given below.

{17-5_22-12_23A-2} DATA SHIFT (DATA_OFFSET)

In the field "SHIFT_DATA" (DATA_OFFSET) write the relative address of the beginning of BLOCK_ZOB (AOB_BLOCK) with respect to the boundary between the clusters in the form of a value specified in bytes. It indicates the size of the inactive section between GOITER (AOW) and GOITER BLOCK (AOB_BLOCK). One example of this is the following: when a user records a radio program on a flash memory card 31 in the form of a GOITER (AOB) and wants to delete the initial part of the phonogram in which the host of the music program says, DATA_OFFSET in TIB during the introduction to the song ( BIT) can be set such that the phonogram is played back without the part of it that contains the voice of the host music show.

{17-5_22-12_23A-3} OBDATA (SZ_DATA)

In the field "OBDATA" (SZ_DATA) write the data length BLOCK_ZOB (AOB_BLOCK), expressed in bytes. The size of the inactive section located after the BLOCK_ZOB (AOB_BLOCK) can be found by subtracting from the file volume (which is a multiple of the integer number of cluster sizes) the value obtained by adding the DATA DATA (SZ_DATA) and the DATA SHIFT (DATA_OFFSET).

{17-5_22-12_23A-4} COL_ETPPVR (TMSRTE_Ns)

In the field "KOL_ETPVR" (TMSRTE_Ns) record the total number of Elements TPPVR (TMSRT_Entries) contained in the BLOCK_ZOB (AOB_BLOCK).

{17-5_22-12_2ZA-5} "KOLK_1go_ETPPVR" (FNs_lst_TMSRTE), "KOLK_Sost_ETPPVR" (FNs_Last_TMSRTE), "KOLK_Medium_ETPPVR" (FNs_Middle_TMSRTE)

In the field "FIRS_1st_ETPPVR" (FNs_lst_TMSRTE) write the number of CARD_CHAMDS (AOB_FRAMEs) contained in the CLEARING element (AOB_ELEMENT), which is located at the beginning of the AOB_BLOCK currently in use.

In the field "FIRS_Last_TMSRTE" (FNs_Last_TMSRTE), write the number of GOITERS (AOB_FRAMEs) contained in the GOITER (AOB_ELEMENT), which is located at the beginning of the AOB_BLOCK currently used.

In the field "FIRS_Medium_ETPVR" (FNs_Middle_TMSRTE) write the number of GOITERS (AOB_FRAMEs) contained in each GOITER (AOB_ELEMENT), except at the beginning and end of the GOITER (AOBsELECT, (AOB_ELOB, ALE_OBEL, i.e. are in the middle of BLOCK_ZOB (AOB_BLOCK).

In the "TIME_LENGTH "_TIME_LENGTH field, the playing time of the AOB_ELEMENT element is recorded in the format shown in FIG. 23C with an accuracy of milliseconds. As shown in FIG. 23C, the “TIME_LENGTH” field is 16 bits long. In the case when an encoding method according to MPEG-AAC or MPEG level 3 (MPEG-LAYER3) standards is used, the playback time of the AOB_ELEMENT element is two seconds, therefore, the value "2000" is recorded in the "TIME_LENGTH" field.

{17-5_22-13_23B}

FIG. 23B shows the number of GOITER_FRAMES (AOB_FRAMEs) indicated in “FIR_Meddle_TMSRTE”. On Figb, as well as on Fig, shows the relationship between the sampling frequency and the number of GOALS (AOB_FRAMEs) contained in the element GOITER (AOB_ELEMENT), which is located in the middle of the BLOCK GOITER (AOB_BLOCK).

The relationship between the sampling rate and the number of frames contained in AOB_ELEMENT shown in FIG. 23B is the same as that shown in FIG. 14, namely, the number of frames in AOB_ELEMENT depends on the sampling frequency used. . The number of frames recorded in "KOLK_1go_ETPPVR" (FNs_lst_TMSRTE) and in "KOLK_Post_ETPPVR" (FNs_Last_TMSRTE) will be essentially equal to their number recorded in "KOLK_MED_ETPPVR" (however, ATTENT_ENTRELENT, and / or at the end of the GOIT BLOCK (AOB_BLOCK) there is an inactive section, then the values specified in "QTY_1st_TMSRTTE" and / or in "KOLK_LAST_ETPWR (FNs_Last_TMSRTE)" differ from the values of TST_CTT_MT_RTL_CONTL_CONTLED_NAME.

{17-5_22-14_24} Example of a memorized GOITER (AOB_ELEMENT)

On Fig shows the clusters from 007th to 00th, in which the GOITER (AOW) is stored, consisting of GOITER ELEMENTS with GOITER ELEMENT # 1 (AOB_ELEMENT # 1) and GOITER ELEMENT No. 4 (AOB_ELEMENT # 4). The following is a description of the setting of parameters in the TIB (BIT) for the case when storing the GOITER (AOW) is performed as shown in Fig.24. GOITER ELEMENTS from GOITER ELEMENT No. 1 (AOB_ELEMENT # 1) to GOITER ELEMENT No. 4 (AOB_ELEMENT # 4), which were stored in clusters from cluster 007 through cluster 00E, are indicated by triangular flags in FIG. 24, and in IDF (TKI) for each from ELEMENT_ GOITER from ELEMENT_ GOITER No. 1 (AOB ELEMENT # 1) to ELEMENT_ GOITER No. 4 (AOB_ELEMENT # 4) the values of Elements_TPPVR (TMSRT_Entries) are set.

In this example, the first part of GOITER # 1 (AOB_ELEMENT # 1) located at the beginning of GOITER (AOB) is stored in cluster 007, and the last part of GOITER # 4 (AOB_ELEMENT # 4) located at the end of GOITER (AOB) is stored in the cluster 00E. GOITER ELEMENTS (AOB_ELEMENTs) No. 1 through No. 4 occupy the area from md0 in cluster 007 to md4 in cluster 00E. As shown in Fig. 24 by the sdl arrow, SOB_DATA (SZ DATA) in TIB (BIT) indicates that AOB_ELEMENTS items # 1 to # 4 occupy the area from the beginning of cluster 007 to the end of cluster 00E, but does not indicate that in clusters 007 and 00Е there are inactive sections ud0 and ud1 that are not occupied by AOB_ELEMENT ELEMENT.

On the other hand, GOITER (AOW) also contains sections of ud0 and ud1 located in clusters 007 and 00E but not occupied by GOITER ELEMENT No. 1 (AOB_ELEMENT # 1) or GOITER ELEMENT No. 4 (AOB_ELEMENT # 4). The DATA Offset specified in the TIB (BIT) indicates the length of the unoccupied area ud0, namely, the location value of the beginning of GOITTEN ITEM # 1 (AOB_ELEMENT # 1) relative to the beginning of cluster 007.

As shown in FIG. 24, GOITER # 1 (AOB_ELEMENT # 1) occupies a region from md0 in cluster 007 to md1 in cluster 008.

This GOITER ITEM # 1 (AOB_ELEMENT # 1) does not occupy the entire cluster 008, while the rest of the cluster is occupied by GOITER ITEM # 2 (AOB_ELEMENT # 2). GOAL ELEMENT No. 4 (AOB_ELEMENT # 4) occupies the area from md3 located in the middle of the 00C cluster to md4 located in the middle of the 00E cluster. In this way, the storage of GOITERS (AOB_ELEMENTs) through the boundaries of the clusters can be made, or, in other words, the recording of GOALS (AOB_ELEMENTs) can be carried out without taking into account the boundaries between the clusters. "KOLK_1go_ETPPVR" (FNs_lst_TMSRTE) in TIB (BIT) indicates the number of frames in GOITTEN ITEM # 1 (AOB_ELEMENT # 1), which is located in clusters 007 and 008, and "KOLK_POST_ETPOTVR" (FNs_LAST ВЕЛЕБТЭБТЭТРТЭТРТЭБТРТМТЭБТРТБББББББББББББББББББББББББББББББ and number 4 (AOB_ELEMENT # 4), which is located in clusters from 00C to 00E.

In a similar way, free placement of CLEARING ELEMENTS (AOB_ELEMENTS) can be carried out without taking into account the boundaries between clusters. TIB (BIT) provides information that indicates the offset from the cluster boundary to the GOITER (AOB_ELEMENT) and the number of frames in each GOITER (AOB_ELEMENT).

{17-5_22-14_25} Using the number of frames defined in each GOITTER (AOB_ELEMENT) (Part 1)

The following is a description of the use of the information on the number of frames in each BIT element (AOB_ELEMENT) contained in the TIB (BIT). This number of frames specified in the TIB (BIT) is used when performing a search in the forward or reverse direction. As mentioned above, in such operations, data is reproduced within 240 milliseconds after data is skipped in advance, the reproduction duration of which is two seconds.

On Fig shows how to set the parameters of the next reproduced KADRA_ZOB No. (x + 1) (AOB_FRAME # x + 1) when performing a search in the forward direction, which starts with KADRA_ZOB No.x (AOB_FRAME # x) in the ELEMENT_ZOB No. (AOB_ELEMENT #y) GOITER (AOB).

On Fig shows the option in which the user selects the search operation in the forward direction when playing back FRAME_CHAIN No. (AOB_FRAME # x) contained in the element GOITER # GO (AOB_ELEMENT # y). 25, “t” is the duration of intermittent playback (here it is 240 milliseconds), “f (t)” indicates the number of frames corresponding to this duration of intermittent playback, “skip time” (skip_time) indicates the length of time interval, which should be skipped between discontinuous playback cycles (here it is two seconds), "f (skip_time)" ("f (skip_time)") indicates the number of frames that corresponds to this skip time. Intermittent playback is performed by repeating the three procedures described below (1), (2), and (3).

(1) the reproducing apparatus accesses the TMPRVE Element (TMSRT_Entry) in the TKTMSRT (TKTMSRT) and proceeds to the beginning of the flag symbol (GOITTING ELEMENT) (AOB_ELEMENT).

(2) the playback device performs playback for 240 milliseconds.

(3) the playback device advances to the beginning of the next flag symbol (GOITTING ELEMENT) (AOB_ELEMENT).

GOAL_ZOB No. (x + 1) (AOB_FRAME # x + 1), which is located 2 seconds later + 240 milliseconds from GOAL_ZOB NOx (AOB_FRAME # x) contained in GOAL_ZOB NO. (AOB_ELEMENT # y), will most likely be located in GOAL_ZOB NO. (y + 1) (AOB_ELEMENT # y + 1). When determining FRAME_ZOB No. (x + 1) (AOB_FRAME # x + 1) located after 2 seconds + 240 milliseconds from FRAME_ZOB No.x (AOB_FRAME # x), despite the fact that the playback device cannot play from the TPSRR element (TMSRT_Entry) find out about the number of GOITER_FRAME (AOB_FBAMEs) located between the starting addresses of GOITER_FIELD NO. (y + 1) (AOB_ELEMEMT # y + 1) and GOITER_FRAME NO. 1) (AOB_ELEMENT # y + 1) can be directly calculated by reading the TPRVR Element (TMSRT_Entry) from TGFVRV (TKTMSRT).

To calculate this number of GOITERS (AOB_FRAMEs), it is necessary to subtract the total number of frames contained in GOITER_IT element #y (AOB_ELEMENT # y) from the sum (1) of number NOx (number # x), which indicates the position of GOITER_CHADENE No.x (AOB_FRAME # x) relative to the start of GOITTER ELEMENT No.y (AOB_ELEMENT # y), (2) f (t) and (3) f (skip time) ("f (skip_time)"). To simplify the calculation of the relative position of the frame KADRA_ GOITER No. (x + 1) (AOB_FRAME # x + l) in ITEM_CRAFT No. (y + 1) (AOB_ELEMENT # y + 1), in “TITLE (BIT) for each ITEM_CRAFT (AOB_ELEMENT) write" RING_1 "(FNs_lst_TMSRTE)," KOLK_Medium_TMSRTE "(FNs_Middle_TMSRTE), and" KOLK_Last_ETPSVR "(FNs_Last_TMSRTE) as described above.

{17-5_22-15_26A} Using the number of frames specified in each AOB_ELEMENT ELEMENT (part 2)

The number of frames recorded in the TIB (BIT) is also used when the playback device performs a time search function at which playback starts at the point indicated by the time code. FIG. 26A shows how a playback device can determine AOB_ELEMENT and AOB_FRAME corresponding to a user-specified playback start time. In the case when it is necessary to start playback from the moment of time specified by the user, the specified time (in seconds) is set in the "Record_o_junction" (Jmp_Entry) field, while the playback should start from ELEMENT_ZOB No. (AOB_ELEMENT # y) and from the place x FRAME_ZOB (AOW_FRAME) satisfying Equation 2 below.

Equation 2

Transition record (in seconds) = (KOLK_1go_ETPPVR + KOLK_Sredn_ETPPVR * y + x) * 20 ms

Since "KOLK_1go_ETPPVR" (FNs_lst_TMSRTE) and "KOLK_Med__ETPPVR" (FNs_Middle_TMSRTE) are contained in TIV (BIT), they can be substituted into Equation 2 for calculating CLEAR ITEM # AOB_ELAME # yOB_ELAME # YOB_ELAME # YOB_ELAME # YOB_ELEMENT # yOB. After that, the playback device can perform a call to the Crawler (TKTMSRT) GOITER (AOW) to calculate the first address of GOITER ITEM_Number (y + 2) (AOB_ELEMENT # y + 2) (which is the (y + 2) th ITEM_HOW (AOB_ELEMENT) in this GOITER (AOW)) and, proceeding from this first address, start the search KADRA_ZOB Nox (AOB_FRAME # x). When the x-th FRAME (AOB_FRAME) is detected, the playback device starts playback from this frame. Thus, the playback device can start playing data from the point in time specified in the Transition Record (Jmp_Entry) (in seconds).

Thus, for the playback device, there is no need to search for parts of the ADTS header in AOB_FRAMEs, but simply search in AOB_ELEMENTS ELEMENTS, which are indicated in the TMSRT_Entries Elements from TKTMSRT. This means that the playback device can quickly find the playback location corresponding to the specified playback time.

Similarly, when the value of Transition_On_Junction (Jmp_Entry) is set, and the time search function is used for a phonogram consisting of a set of GOITERS (AOW), the playback device only needs to calculate ELEMENT_ GOITER No. (AOB_ELEMENT # y) and FRAME_ZOB No.X (AOB_FRAME # x) that satisfy the Equation 3 below.

Equation 3

Transition_Record (in seconds) =

Playback duration from GOITER No. 1 to GOITER No.n + (KOLK_1go_ETPPVR (No. (n + 1)) + KOLK_Sredn_ETPPVR (No. (n + 1)) * y + x) * 20 ms

The total duration of the reproduction of GOITER (AOV) from GOITER No. 1 (AOV # 1) to GOITER No.n (AOV # n) is equal to:

The total duration of the reproduction of GOITERS from GOITER No. 1 to GOITER No.n =

["KOLK_1go_ETPPVR" (No. 1) + "KOLK_Medium_ETPPVR" (No. 1) * (Number of Elements_TPPVR (No. 1) - 2) + "KOLK_Posl_ETPPVR" (No. 1) + "KOLK_1go_ETPPVR" (No. 2) + (KOLK_1go_ETPPVR "(No. 2) + ( 2) * The number of Elements_TPPVR (No. 2) - 2) + "KOLK_Posl_ETPPVR" (No. 2) + "KOLK_1go_ETPPVR" (No. 3) + ("KOLK_Medium_ETPPVR" (No. 3) * The number of Elements_TPPVR (No. 3) - 2_PL KOL "(No. 3) ... +" KOLK_1go_ETPPVR "(No. n) + (" KOLK_Medium_ETPPVR "(No. n) * Number of Elements_TPPVR (No. n) - 2) +" KOLK_Sent_ETPPVR "(No. n)] * 20 ms

After calculating GOITER No. n (AOB # n), GOITTER ELEMENT No. (AOB_ELEMENT # y), and GOITER_ GOITER No.x (AOB_FRAME # x) satisfying Equation 3, the playback device accesses TPFGVR (TKTMSRT) corresponding to GOITER No. (n + 1) (AOW # n + 1), searches for the x-th CARD_OBRAIN (AOB_FRAME) from the address where the (y + 2) th ELEMENT_ goiter (AOB_ELEMENT) is located (that is, the ELEMENT_ goiter No. (y + 2) (AOB_ELEMENT # y +2)), and starts playback from this x-th KADRA_ZOB (AOB_FRAME).

{17-5_22-16_27A, B} Erasing a CALL file (AOW file) and IDF (TKI)

This concludes the description of all the information contained in the IDF (TKI). The following is a description of how an IDF update (TKI) is implemented in the following four cases. In the first case (Example 1), the phonogram is deleted. In the second case (Example 2), a phonogram is deleted and a new phonogram is recorded. In the third case (Example 3) from a variety of phonograms, two are selected and their combination into one phonogram. Finally, in the fourth case (Example 4), one phonogram is separated and two phonograms are created.

The following is a description of the case in which the phonogram is deleted.

On figa and figb shows a partial erasure of the phonogram. The example shown in Fig. 27A and Fig. 27B corresponds to the phonogram manager (TrackManager) shown in Fig. 19, and it is assumed that the user indicated a partial erasure of the Phonogram B (TrackB). GOITER (AOW) corresponding to Phonogram B (TrackB) is recorded in "AOB002.SA1", which corresponds to IDF No. 2 (TKI # 2). This means that the erasure of "AOB002.SA1" is accompanied by the setting in ATR_BLK_IDF (TKI_BLK_ATR) IDF No. 2 (TKI # 2) of the value "Unused". This is the state in which "AOB002.SA1" has been deleted, and ATR_BLK_IDF (TKI_BLK_ATR) IDF No. 2 (TKI # 2) is set to "Unused", shown in Fig.27B. Since "AOB002.SA1" was deleted, the area that was previously occupied by "AOB002.SA1" freed up and became an unused area. As mentioned above, another change is that in ATR_BLK_IDF (TKI_BLK_ATR) IDF No. 2 (TKI # 2) is set to "Unused".

{17-5_22-17_28A, B} Assignment of IDF (TKI) when recording a new GOITER (AOW)

Below is a description of Case 2, in which, after erasing the phonogram, a new phonogram is recorded.

On figa shows the administrator of phonograms (TrakkManager) after the erasure of the phonograms was performed several times. As shown in Fig. 28A, if the phonograms to which IDF No. 2, IDF No. 4, IDF No. 7 and IDF No. 8 (TKI # 2, TKI # 4, TKI # 7, TKI # 8) were deleted, then in ATR_BLK_IDF (TKI_BLK_ATR) of these IDFs (TKI) set to "Unused". Since deleting GOITER files (AOW files) is performed in exactly the same way as regular data files, updating the phonogram manager (TrackManager) is carried out simply by setting the value "Unused" in ATR_BLK_IDF (TKI_BLK_ATR) of the corresponding IDF (TKI). This means that the IDF (TKI), in the ATR_BLK_IDF (TKI_BLK_ATRs) which are set to "Unused", can occur in various places of the phonograms administrator (TrackManager).

On figb shows how to record new IDF (TKI) and file GOITER (AOW file) in the case when the administrator phonograms (TrackManager) have IDF (TKI), ATR_BLK_IDF (TKI_BLK_ATR) which has the value "Unused". Like FIG. 28A, in IDF No. 2, IDF No. 4, IDF No. 7 and IDF No. 8 (TKI # 2, TKI # 4, TKI # 7, TKI # 8) of FIG. 28B, the values are “Unused”.

As shown in FIG. 28B, a new recordable phonogram consists of four GOITERS (AOB). Unused IDFs (TKIs) intended for recording these GOITERS (AOW) are determined according to UP_FG_SVFU (phonogram search pointers from the list of reproduced files set by default - translator's note) (DPL_TK_SRPs) or they can be chosen arbitrarily. In this example, to record an IDF (TKI) of a new phonogram, unused IDFs (TKI) are used, having numbers IDF No. 2, IDF No. 4, IDF No. 7 and IDF No. 8 (TKI # 2, TKI # 4, TKI # 7, TKI # 8).

Since one phonogram consists of these four GOITERS (AOW), in ATR_BLK_ITsF (TKI_BLK_ATR) ICF No. 2 (TKI # 2) set the value "Beginning of the phonogram" ("Head_of_Track"), in ATR_BLK_IDF (TKI_BLK_ATR and IDF IDID) TKI # 4, TKI # 7) set the value to “Middle Phonogram” (“Middle_of_Track”), and to ATR_BLK_IDF (TKI_BLK_ATR) IDF No. 8 (TKI # 8) set the value “End_of_Track”. UKZ_SVZ_IDF (TKI_LNK_PTR) in each of these four IDFs (TKI): IDF No. 2, IDF No. 4, IDF No. 7 and IDF No. 8 (TKI # 2, TKI # 4, TKI # 7, TKI # 8) used for education of the new Phonogram G (TrackD), set so that they indicate those IDFs (TKI) that form the next part of the Phonogram G (TrackD), while, as shown by the arrows TL2, TL4, and TL7, in UKZ_SVZ_IDF (TKI_LNK_PTR) IDF No. 2 (TKI # 2) set the value of IDF No. 4 (TK1 # 4), in UKZ_SVZ_IDF (TKI_LMK_PTR) IDF No. 4 (TKI # 4) set the value of IDF No. 7 (TKI # 7), and in UKZ_SVZ_IDF (TKI_LNKTR) 7 (TKI # 7) set the value of IDF No. 8 (TKI # 8).

After that create the files "AOB002.SA1", "AOB004.SA1", "AOB007.SA1" and "AOB008.SA1", having the same numbers as IDF No. 2, IDF No. 4, IDF No. 7 and IDF No. 8 (TKI # 2, TKI # 4, TKI # 7, TKI # 8), and these four files store four GOITERS (AOW) that form Phonogram G (TrackD).

By appropriately setting the values UKZ_SVZ_IDF (TKI_LNK_PTRs) and ATR_BLK_IDF (TKI_BLK_ATRs), this fourth phonogram can be controlled. Phonogram G (TrackD), using IDF No. 2, IDF No. 4, IDF No. 7 and IDF No. 8 (TKI # 2, TKI # 4, TKI # 7, TKI # 8).

As described above, when a new phonogram is recorded in the flash memory card 31, then those TKIs in the phonogram manager (TrackManager) whose values are set to “Unused” are allocated as TKIs for newly recorded phonograms.

{17-5_22-18_29A, B} Setting IDF values (TKI) when combining two phonograms

The following is a description of the IDF update (TKI) when combining phonograms (Example 3).

On figa and figb shows how to set the IDF (TKI) when creating a new phonogram by combining two phonograms. In the example of Fig. 29A, the same Phonogram Manager (TrackManager) is used as in Fig. 19, and it shows the case when the user performs the operation to combine Phonogram B (TrackC) and Phonogram D (TrackE) into one phonogram editing.

In this case, GOITERS (AOB), which correspond to Phonogram B (TrackC) and Phonogram D (TrackE), are recorded in the files GOITER (AOW files) "AOB003.SA1" and "AOB008. SA1", which correspond to IDF No. 3 (TKI # 3) and IDF No. 8 (TKI # 8), while overwriting ATR_BLK_IDF (TKI_BLK_ATRs) in IDF No. 3 and IDF No. 8 (TKI # 3, TKI # 8). On Figb shows ATR_BLK_IDF (TKI_BLK_ATR) of these IDFs (TKIs) after overwriting. In FIG. 29A, ATR_BLK_IDF (TKI_BLK_ATRs) in IDF No. 3 and IDF No. 8 (TKI # 3, TKI # 8) are recorded as “Phonogram”, but in FIG. 29B ATR_BLK_IDF (TKI_BLK_ATR) in IDF No. 3 (TKI # 3 are rewritten) so that it gets the value "Start_Phonograms" ("Head_of_Track"), and ATR_BLK_IDF (TKI_BLK_ATR) IDF # 8 (TKI # 8) is overwritten so that it gets the value "End Phonogram" ("End_of_Track"). By overwriting TKI_BLK_ATRS, the processing of GOIT files (AOW files) "AOB003.SA1" and "AOB008.SA1", which correspond to IDF No. 3 (TKI # 3) and IDF No. 8 (TKI # 8) located at the end, is performed as parts of one phonogram, namely, the new Phonogram B (TrackC). During this operation, UKZ_SVZ_IDF (TKI_LNK_PTR) is simultaneously rewritten in IDF No. 3 (TKI # 3) so that IDF No. 8 (TKI # 8) is indicated in them.

Here, in particular, one should pay attention to the fact that until ATR_BLK_IDF (TKI_BLK_ATRs) has been overwritten into IDF (TKI), no processing is performed to physically merge GOITER files (AOB files) "AOB003.SA1" and " AOB008.SA1 ". This is due to the fact that each of the GOITER (AOW file) files is encrypted using different file keys (FileKeys), therefore, when combining GOITER files (AOW files), it would be necessary to perform two processing operations for each GOITER file (AOW file), First, decrypt the encrypted GOITCH file (AOW file), and then re-encrypt the result, which would lead to excessive processing load. Moreover, the GOIT file (AOW file) combined in this way is encrypted using only one file key (FileKey), which leads to less security of the combined phonogram as compared to the phonograms that were used to create it.

IDFs (TKIs) were originally designed to reduce the amount of TKTMSRTs; therefore, when physically merging GOIT files (AOW files) through an editing operation, there is a risk that the IDFs (TKIs) become too large.

For the above reasons, during editing operations by which phonograms are combined, the GOIT files (AOW files) remain in an encrypted state, and these operations are carried out simply by changing the attributes specified in ATR_BLK_IDF (TKI_BLK_ATRs).

{17-5_22-18_29A, B-1_30.31} Conditions that must be satisfied when combining phonograms

As described above, the combination of phonograms is carried out by changing the attributes ATR_BLK_IDF (TKI_BLK_ATR), but CALL (AOB) contained in the combined phonograms must satisfy the conditions below.

The first condition is that the GOITER (AOW) that forms the last part of the new phonogram must have the same attributes of audio data (audio encoding mode, binary data rate, sampling frequency, number of channels, etc. ), as the GOITER (AOW), forming the first part of the new phonogram. In the event that a GOITER (AOW) has sound data attributes that are different from the attributes of the previous or subsequent GOITER (AOW), the playback device will have to resume the decoder from its original state, which complicates the seamless (i.e., continuous) reproduction of successive GOITERS (AOW) )

The second condition is that in a phonogram created by combining, three or more GOITERS (AOB), which consist only of those GOITER ELEMENTS (AOB_ELEMENTs), the number of GOITER FRAMES (AOB_FRAMEs) in which is less than the required number for " COLK_Edit_MEDDL (FNs_Middle_TMSRTE). "

GOITER (AOW) is divided into two types, depending on whether at least one AOB_ELEMENT element contains the number of GOITER_FIELDS (AOB_FRAMEs), equal to the number of frames, which is caused by "FIR_ENTER_TMSRTE" (FNs_Middle_TMSRTE). GOITER of the 1st type (Typel AOB) contains at least one GOITER (AOB_ELEMENT) having this number of GOITER_RAF (AOB_FRAMEs), and GOITER of the 2nd type (Toure 2 AOB) does not contain the GOITER ELEMENT (AOB_ELEMENT), which has this number of GOALS (AOB_FRAMEs).

In other words, GOITER ELEMENTS (AOB_ELEMENTS) in type 2 GOITER (Type 2 AOW) have a number of GOITER_FRAMEs (AOB_FRAMEs) less than "KOLK_Meddle_ETPVR" (FNs_Middle_TMSRTE), and in the second type of OBO2, it is stipulated that cannot be put together.

The reason for the second condition is as follows. When the playback device sequentially reads GOITERS (AOW), it is preferable that in the buffer of the playback device accumulate a sufficient number of GOITERS (AOB_FRAMEs), however, this cannot be done if there are two types of GOITERS (one after another) ( Ture2 AOB). In this case, a buffer underflow of the playback device may occur, so it is not possible to guarantee that the playback device will perform continuous playback. Therefore, in order to avoid such buffer underruns, the second condition is used, which stipulates that three or more second type GOITERS (Toure2 AOBs), one after the other, cannot be combined together.

On Figa shows the GOITER of the 1st type (Type1 AOB), and Fig.30B shows two examples of the GOITER of the 2nd type (Toure 2 AOB). In FIG. 30B, both GOITER (AOB) consist of at least two GOITER (AOB_ELEMENTs), and not one of the GOITER (AOB_ELEMENTs) contains that number of GOITER_FRAMEs (AOB_FRAMEs), which is set for "FIRST_ETRESET_NAME. Since the absence of GOITER ELEMENT (AOB_ELEMENT), having the number of GOITER_FIELDS (AOB_FRAMEs), which is provided for "FIR_Middle_TMSRTE", is a condition for GOITER (AOW) to be referred to as GOITTER of the 2nd type (type 2), all GOITERS (AOW) shown in this drawing are type 2 GOITERS (Toure 2 AOW).

On Figa shows the combination in a single phonogram of GOITER type 1 + type 2 + type 2 + type 1 (Type1 + Type2 + Type2 + Type1 AOBs). Since this association does not include the binding of three GOITERS of the 2nd type (Toure 2 AOV) among themselves, these GOITERS (AOV) can be arranged together to form a single phonogram.

On Figb shows the binding in a single phonogram of GOITER type 1 + type 2 + type 2 + type 2 + type 1 (Type1 + Type2 + Type2 + Type2 + Type1 AOBs). Such a combination would lead to the presence of three successive second-type GOITERS (Ture2 AOB) and therefore prohibited.

{17-5_22-18_29A, B-1_32} Combining Phonograms taking into account combinations of type 1 and type 2 goiters (Type1, Type2 AOBs)

When combining GOITER (AOW) into a single phonogram, as shown in Fig. 31A, if the last GOITER (AOW) in the first phonogram is a type 1 GOITER (Type1 AOW), then combining can be carried out regardless of whether the first part of this soundtrack is GOITTER of the 1st type (Type1 AOB) or GOITER of the 2nd type (Type2 AOB). On Figa shows the option in which the last GOITER (AOV) of the first phonogram is a type 1 GOITER (Type1 AOB), and the first GOITER (AOV) of the next phonogram is also a type 1 GOITER (Type1 AOB). On Figv shows the option in which the last GOITER (AOB) of the first phonogram is a type 1 GOITER (Type1 AOB), and the first GOITER (AOV) of the next phonogram is a type 2 GOITER (Type2 AOB). Since both of these options satisfy the second condition, the displayed phonograms can be combined into a single phonogram.

In the case when the last GOITER (AOB) of the first phonogram is a type 2 GOITER (Ture2 AOB), and the previous GOITER (AOV) of the first phonogram is a type 1 GOITER (Type1 AOB), this first phonogram can be combined with the next phonogram that starts with type 1 goiter (Type1 AOW), regardless of whether the first goiter (AOW) in the first soundtrack is type 1 goiter (Type1 AOW) or type 2 goiter (Ture2 AOV) .

On Figv shows the case in which the first phonogram ends with a goiter of the 1st type (Type1 AOB) and a goiter of the 2nd type (Ture2 AOB) in this order, and the second phonogram starts with a goiter of the 1st type (Type1 AOB) . On Figg shows the case in which the first phonogram ends with a goiter of the 1st type (Type1 AOB) and a goiter of the 2nd type (Toure 2 AOV) in the indicated order, and the second phonogram starts with a goiter of the 2nd type (Ture2 AOB) and GOITER of the 1st type (Type1 AOB) in the indicated order. Since both of these cases satisfy the second condition, the phonograms shown can be combined into a single phonogram.

In the case when the first phonogram ends with a GOITER of the 2nd type (Toure 2 AOV), and the immediately preceding GOITER (AOW) is also a goiter of the 2nd type (Toure2 AOV), this first phonogram can be combined with the next phonogram starting with GOITER type 1 (Type1 AOB). Fig. 32D shows the case in which the first phonogram ends with two GOITERS of the 2nd type (Toure 2 AOB), and the second phonogram starts with GOITER of the 1st type (Type1 AOB). Since this case satisfies the second condition,

then the displayed phonograms can be combined into a single phonogram. Thus, when combining two phonograms, an analysis is made of whether these two phonograms satisfy the first and second conditions, and the combination of these two phonograms is carried out only if it is decided that they satisfy these conditions.

The following is a description of the IDF update (TKI) for Example 4 in which phonogram separation is performed.

{17-5_22-19_ZZA, B} Setting parameters for IDF (TKI), in case of separation of a phonogram

On figa and figb shows examples of the separation of one phonogram with the creation of two new phonograms. In these examples, the phonogram manager (TrackManager) has the same contents as the administrator shown in FIG. 27, it being assumed that the user has performed an editing operation by which Phonogram B (TrackC) is divided into two new phonograms, namely, to Phonogram B (TrackC) and Phonogram E (TrackF). When Phonogram B (TrackC) needs to be divided into new phonograms: Phonogram B (TrackC) and Phonogram E (TrackF), then create a GOITER file (AOW file) "AOB002.SA1" corresponding to Phonogram E (TrackF). 33A shows that IDF No. 2 (TKI # 2) is set to “Unused”, and these IDF No. 2 (TKI # 2} is assigned to the newly created GOITER file (AOB file) “AOB002.SA1”.

{17-5_22-19_ZZA, B-1_34A, B} Updating catalog elements and TRF values (FAT)

In the case when the creation of "AOB002.SA1" is carried out the separation of the file GOITER (AOW file) "AOB003.SA1", it is necessary to update the catalog elements and values TRF (FAT). The explanation for this update is given below. Fig. 34A shows how an element of the source audio data directory (SD-AUDIO) is recorded in the source audio data directory (SD-Audio) to which the GOITER file "AOB003.SA1" belongs, before the file is split.

File GOITER (AOW file) "AOB003.SA1" is divided into many parts that are stored in clusters 007, 008, 009, 00A ... 00D, 00E. In this case, the number of the first cluster for the AOB003.SA1 file specified in the directory element of the Crawler (AOW file) file is written as "007". Also as values TRF (FAT) 007, 008, 009, 00A ... 00D, which correspond to clusters 007, 008, 009, 00A ... 00D, write the values (008), (009), (00A) .. . (00D), (00E).

In the case where the separation of the GOITER (AOW file) "AOB003.SA1" filed in such a way that its last part became the new GOITER (AOW file) file "AOB002.SA1", into the directory element of the source audio data (SD-Audio) add "file name", "file name extension" and "number of the first cluster in the file" for the new GOITER (AOW file) file "AOB002. SA1". On Figa shows how the recording element of the source audio data directory (SD-Audio) in the source audio data directory (SD-Audio), which belongs to the file GOITER (AOW file) "AOB003.SA1", after splitting the file GOITER (AOW file) "AOB003.SA1".

In cluster 00F shown in FIG. 34B, a copy of cluster 00B is stored which contains the boundary specified by the user when dividing the file. Parts of the GOITER (AOW file) "AOB002.SA1" that follow the part contained in cluster 00B are stored as before in clusters 00C, 00D, 00E. Since the first part of the GOITER (AOW file) "AOB002.SA1" is stored in the 00F cluster, and the remaining parts are stored in the 00C, 00D, 00E clusters, in the field "the number of the first cluster in the file" for the new GOITT (AOW file) " AOB002.SA1 "write the value" 00F ", and as the values of TRF (FAT) 00F, 00С, 00D, 00Е, which correspond to the clusters 00F, 00С, 00D and 00Е, write the values (00С), (00D), (00Е) .

{17-5_22-19_ZZA, B-2_35A, B} Setting the values of information fields in IDF (TKI)

Below is a description of how to set the values of the information fields in the IDF (TKI) for the file GOITER (AOW file) "AOB002.SA1" when creating this file by updating the catalog elements and the values of the TRF (FAT). When creating an IDF (TKI) for a split phonogram, there are two types of information fields in an IDF (TKI). They are (1) information that can be copied from the original IDF (TKI) and (2) information obtained by updating the information in the original IDF (TKI). OD_TKINFG (TKTXTI_DA) and ISCO (ISRC) are of the first type, and TIB (BIT), TPFGPVR (TKTMSRT) and other information fields are of the second type. Since both types of information exist, in the present embodiment, the IDFs (TKIs) for the split soundtrack are created by copying the original IDFs (TKIs) to create a template for the new IDFs (TKIs), and then the split / update TPFGPVR (TKTMSRT) and TIB (BIT) ) in this template and updating the remaining information fields.

On figa shows an example in which the separation of the frame_CHAIN (AOB_FRAME) in the goiter (AOW). In Fig. 35A, at the first level, four GOITER (AOB_ELEMENTs) are depicted, namely, GOITER NO. 1, GOITER NO. 2, GOITER NO. 3 and GOAL NO. 4 (AOB_ELEMENT # 1, AOB_ELEMENT # 2, AOB_ELEMENT # 3, AOB_ELEMENT). The length of the data of these GOITER ITEMS (AOB_ELEMENTs) is set in TPFGPVR (TKTMSRT) by means of four Elements_TPPVR No. 1, No. 2, No. 3 and No. 4 (TMSRT_Entries # 1, # 2, # 3, # 4). If, as shown in FIG. 35A, the separation boundary gr1 (bdl) is located in GOITER # 2 (AOB_ELEMENT # 2), then GOITER # 2 (AOB_ELEMENT # 2) is divided into the first region (1), consisting of frames located to the border gr1 (bdl), and the second region (2), consisting of frames located after the border gr1 (bdl). FIG. 35B shows these two GOITERS (AOBs), GOITER No. 1, and GOITER No. 2 (AOB # 1, AOB # 2) obtained by dividing the GOITER (AOW) in half through ITEM_ GOITER No. 2 (AOB_ELEMENT # 2).

{17-5_22-19_ZZA, B-3_36} Setting TIB parameters (BIT)

On Fig shows how to set the parameters of the TIB (BIT) in the case when the separation of the GOITER (AOW) is carried out as shown in Fig. 35. The separation of the GOITER (AOW), shown in Fig.35, is carried out along the boundary Gr1 (bdl). GOITER №1 (AOB # 1), created through such a separation, contains two GOITER_AUTES (AOB_ELEMENTs), GOITER_ELEMENT # 1 (AOB_ELEMENT # 1) and GOITER_ELEMENT # 2 (AOB_ELEMENT # 2), and the other GOITER # 2 (AOB # 2) ) created through such a separation contains three GOITER (AOB_ELEMENTs), GOITER # 1 (AOB_ELEMENT # 1), GOITER # 2 (AOB_ELEMENT # 2) and GOITER # 3 (AOB_ELEMENT # 3).

In Figure 36, these GOITER ELEMENTS (AOB_ELEMENTs) are also indicated by triangular flags to indicate the set parameters of the TMSRT_Entries Elements contained in the IDF (TKI) that correspond to these GOITER (AOB). In the description, GOK No. 1 (AOB # 1), which is obtained by such a separation, will first be considered. ITEM_ GOITER # 1 (AOB_ELEMENT # 1) and ITEM_ GOITER # 2 (AOB_ELEMENT # 2), which are contained in GOITER # 1 (AOB # 1), are located in clusters from cluster 007 to cluster 00A, therefore processing GOITER # 1 (AOB # 1) carried out in such a way as if it consists of clusters from cluster 007 to cluster 00A. GOITTEN ITEM # 2 (AOB_ELEMENT # 2) in GOITER N1 (AOB # 1) has such a length of data that it does not end at the end of cluster 00A, but at the border gr1 (bdl), which is inside cluster 00A, therefore OBDATA (SZ_DATA) for GOITER # 1 (AOB # 1) is defined as the amount of data from the region md0 to the boundary gr1 (bd1) in cluster 00A. "KOLK_1go_ETPPVR" (FNs_lst_TMSRTE) for GOITER No. 1 (AOB # 1) is the same as before the separation, and "KOLK_Sent ETPPVR" (FNs_Last_TMSRTE) for GOITER No. 1 (AOV # 1) differs from the value used before the separation , so that now it indicates the number of frames between the beginning of GOITTEN_CLEAN # 2 (AOB_ELEMENT # 2) before separation and the border gr1 (bdl).

Below is a description of GOITER # 2 (AOB # 2), which is obtained through such a separation. The GOITER # 2 (AOB_ELEMENT # 1), GOITER NO. 2 (AOB_ELEMENT # 2) and GOITER NO. 2 (AOB_ELEMENT # 3) contained in GOITER # 2 (AOB # 2) are located in clusters from cluster 00B to cluster 007. Cluster 00F contains a copy of the contents of cluster 00A. The reason for saving a copy of cluster 00A in cluster 00F is that cluster 00A is occupied by GOITER # 2 (AOB_ELEMENT # 2) from GOITER No. 1 (AOB # 1), so for ITEM_ GOITER # 1 (AOB_ELEMENT # 1) from GOITER No. 2 (AOV # 2) it is necessary to highlight a different cluster.

GOITER ITEM # 1 (AOB_ELEMENT # 1) from GOITER # 2 (AOB # 2) has a data length such that its beginning is not located at the beginning of the 00F cluster, but at the border gr1 (bdl), which is inside the 00F cluster, therefore OBDATA ( SZ_DATA) for GOITER # 2 (AOB # 2) is set as the amount of data from the beginning of the 00B cluster to the point in the middle of the 00E cluster plus the data volume of that part of the 00F cluster that is occupied by GOITER_ITIT # 1 (AOB_ELEMENT # 1).

That part of GOITER # 2 (AOB_ELEMENT # 2) from GOITER No. 1 (AOB # 1), which is contained in the copy of cluster 00A stored in cluster 00F, should be excluded from GOITER No. 2 (AOB # 2), therefore, in the DATA_Shift ( DATA_Offset) in TIB (BIT) GOITER No. 2 (AOB # 2) set the value equal to the volume of that part of GOITER ITEM_2 (AOB_ELEMENT # 2) from GOITER No. 1 (AOV # 1), which is contained in cluster 00F.

From Fig. 36 it can be seen that the separation of GOITER (AOB) leads to the fact that only the CLEANING ELEMENT (AOB_ELEMENT) containing the separation boundary is divided into two parts, and the remaining CLEARING ELEMENTS (AOB_ELEMENTs) located before and after the divided GOAL ELEMENT (AOB_ELEMENT), remain unchanged. As a result, the value of "COLL_SET_ETPPVR" (FNs_Last_TMSRTE) of GOITER No. 2 (AOB # 2) is set to the same as for "ITEM_ GOITER No. 4" (AOB_ELEMENT # 4) before separation, and the value of "COLL_1Go_ETPVR" (FNs2ST_ST_L) (AOB # 2) is set to the same as in GOITTING NO. 1 element (AOB_ELEMENT # 1) GOITER No. 2 (AOV # 2), namely, equal to the number of frames contained in the part after the border obtained by splitting GOITER NO. 2 (AOB_ELEMENT # 2).

{17-5_22-19_ZZA, B-4_37} Setting TIB values (BIT)

On Fig shows a more specific example of changes made in the TIB (BIT) as a result of separation of the phonogram. On the left side of Fig. 37, as an example, the values set in the TIB (BIT) before separation are shown. In this TIB (BIT), Data_Offset is set to "X", DATA (SZ_DATA) is set to "52428", and TMSRTE_Ns is set to "n". KOLK_1go_ETPPVR (FNs_lst_TMSRTE) is set to "80 frames", KOLK_Meddle_ETPPVR (FNs_Middle_TMSRTE) is set to "94th frames", and KOLK_Post_ETp_ETPPVR (FNs_TE) to 50 frames_Last_MS.

On the right side of Fig. 37, the values set in the two TIBs (BIT) created by dividing the phonogram are shown. In the case where the GOITER (AOW) corresponding to the TIB (BIT) from the left part of Fig. 37 is divided as shown in Fig. 35A, the Data Shift (Data_0ffset) in the TIB (BIT) of the first phonogram created by separation is set equal to "X", as in the phonogram before separation, the "OBDATA" (SZ_DATA) is updated so that it is equal to the length of the data "Q" from the beginning to the point Q of separation, and KOL_ETPPVR (TMSRTE_Ns) is set to "k", which indicates the number of TMPVR Elements (TMSRT_entries) from the first TMPR_ Element (TMSRT_entry) to the k-th TPRVR Element (TMSRT_entry). KOLK_1go_ETPPVR (FNs_lst_TMSRTE) and KOLK_Med__ETPPVR (FNs_Middle_TMSRTE) are set equal to "80" and "94" frames, respectively, the same as in TIB (BIT) before separation, but since the final ALEBEOLE_BACKGROUND (BACKGROUND) created by dividing contains "p" CARTRIDES (AOB_FRAMEs), then KOLK_POS__ETPPVR (FNs_Last_TMSRTE) is set equal to "p frames".

In TIB (BIT) of the second phonogram created by splitting, “Data_Offset” is set to “R”, “ABOUT DATA” (SZ DATA) is set to a value; (the original DATABASE "52428" is the length of the data to the split point Q), and KOL_ETPPVR (TMSRTE_Ns) is set equal to the value "n-k + 1", which is obtained by adding one (for the k-th TPPVR Element (TMSRT_entry), which is newly added as a result of the separation) to the number of TMPVR Elements (TMSRT_entries) from the k-th TMPVR Element (TMSRT_entry) to the n-th TSPVR Element (TMSRT_entry).

The values of KOLK_Med_ETPVR (FNs_Middle_TMSRTE) and KOLK_Post_ETPPVR (FNs_Last_TMSRTE) are set to the same as in TIB (BIT) before separation, that is, respectively, “94 frames” and “50 frames”.

The first GOITER (AOB_ELEMENT) in the GOITER (AOW) of this second phonogram contains the "94-p" GOITER_COUNT (AOB_FRAMEs), therefore, in the FIR__st_TMSRTE) of the TIB that sets this phonogram to “p-94” .

{17-5_22-19_ZZA, B-5_38} Setting TIB values (BIT)

On Fig shows TPFHPVR (TKTMSRT) after separation. First of all, an explanation will be given of setting the TPRVR values. The TPSRV (TMSRT) of the first phonogram contains the TPSRV Elements (TMSRT_entries) from the first Element_TVPVR (TMSRT_entry) GOITER (AOW) to the division by the k-th Element_TVPVR (TMSRT_entry), that is, the Elements_TVPVR from No. 1 to No. k (TMSRT_entry # # 1R_ #k).

Here it should be noted that ITEM_CRAFT №k (AOB_ELEMENT # k), which contains the separation boundary, contains only region (1), therefore the k-th TMSRT_entry Element_ contains only the data that corresponds to this region (1 ) The second soundtrack (TMSRT) of the second phonogram contains Elements_TMSRT (TMSRT entries) from the k-th Element_TVPVR (TMSRT_entry) GOITER (AOB) to the separation to the nth Element TPVR (TMSRT_entry), that is, Elements_ТППВР from Nk to # n (TMSRT_. .. # n). It should be noted here that the TPRVR Element #k (AOB_ELEMENT # k) containing the separation boundary contains only the region (2), therefore, the k-th TPRVR Element (TMSRT_entry) contains the volume of only the data that corresponds to this region (2).

Copying IDF (TKI) is accompanied by the separation and updating TPFGPVR (TKTMSRT) and TIB (BIT), and the creation of IDF (TKI) for new phonograms created by separation, will be completed immediately after updating the rest of the information. In the same way as when combining phonograms, AOB files are not decrypted, so that two phonograms can be created by splitting the AOB file in its encrypted state. Since the separation of the file GOITER (AOB file) does not include decryption and re-encryption, the computational load when splitting a phonogram can be reduced. This means that editing phonograms can even be done using a playback device with limited processing power.

This concludes the description of IDF (TKI). The following is a list of playable files.

{17-6} Playlist Manager (PlaylistManager)

As shown by the dashed lines h5 in FIG. 17, the reproduced playlist manager (PlaylistManager) shown consists of PlaylistManager_Information (PLMGI) administrator_admin information (PlaylistManager_Information) for managing playlist files that are stored in the flash card 31; from Default_laylist_Information (DPLI) Information_of_list_of_playable_files (Defaults), used to control the entire phonogram stored in flash memory card 31, and of File_of_play_of_list_of_number, No. 2, No. 3 (No. 3, No. 3, No. 4, Playlistlnformation # 1, # 2, # 3, # 4 ... # m (PLI)). Each IFI (PLI) represents information for a user-defined list of playable files. As shown by dotted lines h6, ISVFU (DPLI) consists of Obschey_informatsii_o_spiske_vosproizvodimyh faylov_po_umolchaniyu (OISVF) (Default_Playlist_General_Information (DPLGI)) and Ukazateley_poiska_fonogramm_v_spiske_vosproizvodimyh_ faylov_po_umolchaniyu (UP_FG_SVFU) №1, №2, №3, №4, ... №m (Default_Playlist_Track_Search_Pointers (DPL_TK_SRP ) # 1, # 2, # 3, # 4 ... #m).

The HMIS (DPLI) referred to here differs from each HMIS (PLI) as follows. While the DPMI (DPLI) must contain all the phonograms stored in the flash memory board 52, the IPVF (PLI) does not have such a restriction and any number of phonograms can be indicated in it. This opens up various possibilities for the user. Typical examples of this are the possibility of the user creating Information_of_list_ of playable files (Playlist_Information), which indicates only his / her favorite phonograms, and storing this Information_of_list of playable files (Playlist_Information) in a flash memory card 31, or the possibility of automatically creating Information_of_list of Playback_files (playlist_information) playback, in which only phonograms of a certain genre are indicated, selected from a plurality of phonograms stored in the flash card 31 amyati, and preservation of the resultant information about the list of playable files in the board 31, the flash memory.

{17-7_18} The number of lists of playable files and the amount of data contained in them

As shown in FIG. 18, no more than 99 lists of playable files can be stored on one flash memory card 31. In addition, the total amount of data of the Information_administrator_list of playable_files of the IACWF) (PlaylistManager_Information (PLMGI)) and Information_of the list of reproducible_files of the IASWF (Default_Playlist_Information (DPLI)) are set to 2560 bytes. Each IFI (PLI) has a fixed length of 512 bytes. "UP_FG_SVFU" (DPL_TK_SRP), contained in the Information on the playlist set by default, contains "ATR_FG_SVFU" (phonogram attribute from the list of playable files, set by default - approx. Translator) (DPL_TK_ATR) and "NIDF_SVFU" information data about the phonogram in the list of playable files set by default - approx. translator) (DPL_TKIN). On the other hand, the field "UP_FG_SVF" (PL_TK_SRP) available in the ISWF (PLI) contains only "UP_FG_SVF" (PL_TK_SRP). The format of the fields ATR_FG_SVFU (DPL_TK_ATR), NIDF_SVFU (DPL_TKIN), and NIDF_SVFU (PL_TKIN) are shown in Fig. 39.

{17-8_39-1} Format UP_FG_SVFU (DPL_TK_SRP)

On figa shows the format UP_FG_SVFU (DPL_TK_SRP). On Figa NIDF_SVFU (DPL_TKIN) is written from the 0th to the 9th bit in UP_FG_SVFU (DPI_TK_SRP), and ATR_FG_SVFU (DPL_TK_ATR) is recorded from the 13th to the 15th bit. Bits 10 through 12 in UP_FG_SVFU (DPL_TK_SRP) are reserved for future use.

In NIDF_SVFU (DPL_TKIN) the IDF number (TKI) is written, which takes bits from the 0th to the 9th in the UP_FG_SVFU (DPL_TK_SRP). This allows you to accurately set the IDF (TKI).

{17-9_39B} Format UP_FG_SVF (PL_TK_SRP)

On Figb shows the format UP_FG_SVF (PL_TK_SRP). It is a ten-bit field into which NIDF_SWF (PL_TKIN) is written, that is, an IDF number (TKI).

{17-8_39A-2} Structure ATR_FG_SVFU (DPL_TK_ATR)

The dashed lines h51 and h52 in Fig. 39A, coming from ATP_FG_SVFU (DPL_TK_ATR), indicate an example of setting values ATP_FG_SVFU (DPL_TK_ATR). From this drawing it is clear that the installation of ATR_FG_SVFU (DPL_TK_ATR) for UP_FG_SVFU (DPL_TK_SRP) is carried out in the same way as the setting of ATR_BLK_IDF (TKI_BLK_ATR) for IDFs (TKI), namely, ATR_AT_F from one of the following: Phonogram "," Beginning of phonograms "," Mid_phonograms "and" End_phonograms "(" Track "," Head_of_Track "," Midpoint_of_Track "," End_of_Track ").

In a more detailed presentation, when using IDF (TKI) specified by NIDF (TKIN), and in the file GOITER (AOW file) corresponding to the specified IDF (TKI), record a sound object (GOITER) (AOW), which corresponds to one full the phonogram (that is, when ATR_BLK_IDF (TKI_BLK_ATR) IDF (TKI) has the value "Phonogram" ("Track"), then in "ATR_FG_SVFU" (DPL_TK_ATR) set the value to "00b".

In the case when using IDF (TKI) indicated by NIDF (TKIN), and in the file GOITER (AOW file) corresponding to the specified IDF (TKI), record a sound object (GOITER) (AOW), which corresponds only to the beginning of the phonogram (that is, when АТР_БЛК_ИЦФ (TKI_BLK_AIR) IDF (TKI) has the value "Begin Phonogram" ("Head_of_Track")), set "ATR_FG_SVFU" (DPL_TK_ATR) to "001b". In the case when using IDF (TKI) indicated by NIDF (TKIN), and in the file GOITER (AOW file) corresponding to the specified IDF (TKI), record a sound object (GOITER) (AOW), which corresponds to the middle part of the phonogram (that is, when ATR_BLK_IDF (TKI_BLK_ATR) IDF (TKI) has the value "Midpoint_of_Track", in "ATR_FG_SVFU" (DPL_TK_ATR) set the value to "00b". In that case, when T (if), then indicated by NIDF (TKIN), and in the file GOITER (AOW file) corresponding to the specified IDF (TKI), record a sound object (GOITER) (JSC B), which corresponds to the final part of the phonogram (that is, when ATR_BLK_IDF (TKI_BLK_ATR) IDF (TKI) has the value "End_fonogram" "End_of_Track"), then the value "ATR_FG_SVFU" (DPL_TK_ATR) is set to "equal to".

Otherwise, when the IDF (TKI) indicated by (TKI) is not used, and the area for the IDF (TKI) is simply set to correspond to the state when the IDF (TKI) was deleted (i.e., when ATR_BLK_IDF (TKI_BLK_ATR ) IDF (TKI) has the value "Unused"), in "ATR_FG_SVFU" (DPL_TK_ATR) set the value to "100b".

When the IDF (TKI) indicated by the NIDF (TKIN) is not used, and the area for the IDF (TKI) is not defined, that is, when the IDF (TKI) is in the initial state, “ATR_FG_SVFU” (DPL_TK_ATR) is set to “101b "

Since the IDF number (TKI) is recorded in NIDF_SVFU (DPL_TKIN), it is clear which of the many IDFs (TKI) correspond to each UP_FG_SVFU (DPL_TK_SRP). The position UP_FG_SVFU (DPL_TK_SRP) in the Information_of the list of reproducible_files_of the default (Default_Playlist_Information) indicates when the GOITER (AOW) corresponding to those IDF (TKI) will be reproduced, which in turn correspond to the UP_FG_SVFOV (S) of the VLF (PSS_FVR) (i.e. playable files by default (Default_Piaylist). As a result, the order of the elements UP_FG_SVFU (DPL_TK_SRP) in the List of playable files by default (Default_Playlist) indicates the order in which multiple phonograms will be played, or, in other words, determines the playback order of the phonograms.

{17-9_40-1} Relationship between Information_of_list_of_playable_files_of_default (Default_Playlist_Information), IDF (TKI) and GOITER files (AOW files)

Fig. 40 shows the relationship between Default_Playlist_Information, Default Playlist_Information, IDF (TKI), and Goiter files (AOB files). The second, third and fourth levels in this drawing are similar to the first, second and third levels, illustrated in Fig. 19, and they show a phonogram manager (TrackManager) containing eight IDFs (TKI) and eight GOITER files. FIG. 40 differs from FIG. 19 in that a rectangle denoting Default_Playlist_Information_playlist_information_list (Default_Playlist_Information) is shown at the first level. This rectangle shows eight small sections representing the eight UP_FG_SVFU (DPL_TK_SRP) contained in the Default_laylist_Information_playable_list_information (Default_Playlist_Information). ATR_FG_SVFU (DPL_TK_ATR) is shown at the top of each section, and NIDF_SVFU (DPL_TKIN) is shown at the bottom.

As shown in FIG. 40, the arrows DT1, DT2, DT3, DT4, ..., UP_FG_SVFU No. 1 (DPL_TK_SRP # 1) and IDF No. 1 (TKI # 1) are connected in the same way as UP_FG_SVFU No. 2 (DPL_TK_SRP # 2) with IDF No. 2 (TKI # 2), UP_FG_SVFU No. 3 (DPL_TK_SRP # 3) With IDF No. 3 (TKI # 3), and UP_FG_SVFU No. 4 (DPL_TK_SRP # 4) With IDF No. 4 (TKI # 4).

When considering the fields ATR_FG_SVFU (DPL_TK_ATR) in UP_FG_SVFU (DPL TK_SRP) it is clear that for each of UP_FG_SVFU No. 1, UP_FG_SVFU No. 2, UP_FG_SVFU # 3, and UP_FG_SVFLTKPTK_TL_KPTF_8 # 3 (3), ) has been set to "Phonogram" ("Track"). In other words, the four following sets: UP_FG_SVFU No. 1 → IDF No. 1 (DPL_TK_SRP # 1 → TKI # 1) ("AOB001.SA1"), UP_FG_SVFU No. 2 → IDF No. 2 (DPL_TK_SRP # 2 → TKI # 2) ("AOB002 . SA1 "), UP_FG_SVFU No. 3 → IDF No. 3 (DPL_TK_SRP # 3 → TKI # 3) (" АОВ003. SA1 "), UP_FG_SVFU No. 8 → IDF No. 8 (DPL_TK_SRP # 8 → TKI # 8) (" AOB008.SA1 ") correspond to four separate phonograms.

Meanwhile, none of ATR_FG_SVFU (DPL_TK_ATR) for UP_FG_SVFU №4, UP_FG_SVFU №5, №6 UP_FG_SVFU and UP_FG_SVFU №7 (DPL_TK_SRP # 4, DPL_TK_SRP # 5, DPL_TK_SRP # 6, DPL_TK_SRP # 7) is set to "Soundtrack" ("Track"). Instead, in ATR_FG_SVFU (DPL_TK_ATR) for UP_FG_SVFU No. 4 (DPL_TK_SRP # 4) the value "Begin soundtrack" ("Head_of_Track") is set in ATR_FG_SVFU (DPL_TK_ATR) for UP_FGF_C_FST_FST_FST_FST_FST_F_F_F_F_F_F_F_F_F_FST_FST_FST_F_FST_FG_FST_F_F_FST_FG_FST_FN_ "), a in ATR_FG_SVFU (DPL_TK_ATR) for UP_FG_SVFU No. 5 (DPL_TK_SRP # 5) and for UP_FG_SVFU No. 6 (DPL_TK_SRP # 6) the values" Midpoint_fonogram "(" Midpoint_of_Track ") are set.

This means that IDF No. 4 (TKI # 4) ("AOB004.SA1"), which are associated with UP_FG_SVFU No. 4 (DPL_TK_SRP # 4), represent the beginning of the phonogram, IDF No. 5 (TKI # 5) ("AOB005.SA1 ") and IDF No. 6 (TKI # 6) (" AOB006.SA1 "), which are associated, respectively, with UP_FG_SVFU No. 5 (DPL_TK_SRP # 5) and UP_FG_SVFU No. 6 (DPL TK SR # 6), are parts in in the middle of the track, and IDF No. 7 (TKI # 7) ("AOB007.SA1"), which are associated with UP_FG_SVFU No. 7 (DPL_TK_SRP # 7), represent the end of the track.

Elements UP_FG_SVFU (DPL_TK_SRP) in the List of reproducible_files_of_default (DefaultPlaylist) indicate the playback order of the GOITER (AOW) corresponding to each IDF (TKI). NIDF_SVFU (DPL_TKINs) UP_FG_SVFU No. 1, No. 2, No. 3, No. 4, ... No. 8 (DPL_TK_SRP # 1, # 2, # 3, # 4 ... # 8) in the Default_Playlist of Default_Playlist from FIG. 40 indicate IDF No. 1, No. 2, No. 3, No. 4, ... No. 8 (TKI # 1, # 2, # 3, # 4 ... # 8). As shown by the arrows (1) (2) (3) (4) ... (8), the file GOITER (AOW file) "AOB001.SA1" corresponding to IDF No. 1 (TK1 # 1) will be played first; the second will be played "AOB002.SA1" corresponding to IDF No. 2 (TK1 # 2); the third will play "AOB003.SA1" corresponding to IDF No. 3 (TK1 # 3); and the fourth will play "AOB004.SA1" corresponding to IDF No. 4 (TKI # 4).

{17-10_41} Example of setting parameters for the Default_Playlist and Playlist_Information_List_Files (DefaultPlaylist) and Information

FIG. 41 shows an example of setting parameters for the Default_Playlist and Playlist_Information using the same conventions as in FIG. 40. In Fig. 41, a rectangle on the first level denotes the Default_Playlist, and three rectangles on the second level indicate the PLIs.

The rectangle by which the Default Playback List (DefaultPlaylist) is designated is divided into small sections, in which eight values of the UP_FG_SVFU (DPL_TK_SRP) values are contained in the Default Playback List of Files (DefaultPlaylist), and there are three boxes in each of them, in three PL boxes, four values UP_FG_SVF (PL_TK_SRP). NIDF (TKIN) of each UP_FG_SVFU (DPL_TK_SRP) contained in the Information_of the list of playable files (Playlist_Information) are set to the same as in FIG. 40. However, the set NIDF values (TKIN) UP_FG_SVF (PL_TK_SRP) contained in each ISWF (PLI) are completely different from those set in UP_FG_SVFU (DPL_TK_SRP).

{17-10_42} Correspondence between UP_FG_SVFU (DPL_TK_SRP) and IDF (TKI)

On Fig shows the correspondence between UP_FG_SVFU (DPL_TK_SRP) and IDF (TKI) using the same conventions as in Fig.40. In Fig. 42, the list of playable files No. 1 (Playlist # 1) consists of UP_FG_SVF No. 1, No. 2, No. 3 (PL_TK_SRP # 1, ft2, # 3). In them, as NIDF_SVF (PL_TKIN) in UP_FG_SVF No. 1 (PL_TK_SRP # 1), recorded No. 3 (# 3), as NIDF_SVF (PL_TKIN) in UP_FG_SVF No. 2 (PL_TK_SRP No. 2) recorded No. 1 (# 1), a as NIDF_SVF (PL_TKIN) in UP_FG_SVF No. 3 (PL_TK_SRP # 3) -№2 (# 2). This means that when playing phonograms according to the List of playable files No. 1 (Playlist # 1), the reproduction of the set of GOITERS (AOW) will be performed in the following order: GOITER No. 3, GOITER No. 1, GOITER No. 2 (AOV # 3, AOB # I, AOV # 2), as shown by the arrows (11) (12) (13).

The list of playable files No. 2 (Playlist # 2) consists of UP_FG_SVF No. 1, No. 2, No. 3 (PL_TK_SRP # 1, # 2, # 3). In them, as NIDF_SVF (PL_TKIN) in UP_FG_SVF No. 1 (PL_TK_SRP # 1), recorded No. 8 (# 8), as NIDF_SVF (PL_TKIN) in UP_FG_SVF No. 2 (PL_TK_SRP # 2) recorded No. 3 (# 3), and as NIDF_SVF (PL_TKIN) in UP_FG_SVF No. 3 (PL_TK_SRP # 3) - No. 1 (# 1). This means that when playing phonograms according to the List of reproducible_files No. 2 (Playlist # 2), the reproduction of a set of GOITERS (AOW) will be performed in the following order: GOITER No. 8, GOITER No. 3, GOITER No. 1 (AOV # 8, AOV # 3, AOV # 1), which is shown by arrows (21) (22) (23), that is, in an order that is completely different from that indicated in the List of playable files No. 1 (Playlist # 1).

The list of playable files No. 3 (Piaylist # 3) consists of UP_FG_SVF No. 1, No. 2, No. 3, No. 4 (PL_TK_SRP # 1, # 2, ı3, # 4). NIDF_SVF (PL_TKIN) of these UP_FG_SVF from No. 1 to No. 4 (PL_TK_SRP # 1- # 4) are set equal, respectively, to No. 8, No. 4, No. 3 and No. 1 (# 8, # 4, # 3, # 1). This means that, when playing back phonograms according to the List of reproducible_files No. 3 (Playlist # 3), the reproduction of a set of GOITER (AOW) will be performed in the following order. First, as shown by the arrow (31), the GOITER №8 (AOB # 8), which is a Phonogram D (TrackE), is reproduced. Then, GOITER No. 4, GOITER No. 5, GOITER No. 6 and GOITER No. 7 (AOV # 4, AOV # 5, AOV # 6, AOB # 7) are reproduced, which form Phonogram G (TrackD), which is shown by the arrow (32 ) After that, they reproduce GOITER No. 3 and GOITER No. 1 (AOW # 3, AOB # 1), which form themselves, respectively. Phonogram B (TrackC) and Phonogram A (TrackA), as shown by arrows (33) and (34).

It should be especially noted that if a phonogram consists of a set of IDF (TKI), then only the IDF number (TKI) of the beginning of the phonogram is recorded in the element UP_FG_SVF (PL_TK_SRP). In a more detailed presentation, despite the fact that the values UP_FG_SVFU (DPL_TK_SRP) given in the Information_o_list_of reproducible_files_of_default (Default_Playlist_Information) define those four IDFs (TKI) (IDF No. 4, IDF No. 6, IDF No. 6, IDF No. 5, IDF No. 5, IDF No. 5, IDF No. 5, IDF No. 5, IDF No. 6, IDF No. 5, IDF # 4, TKI # 5, TKI # 6, TKI # 7), which form Phonogram G (TrackD), in UP_FG_SVF (PL_TK_SRP) listed in the Information_of_List_of Playback_files (Playlist_Information) all four IDFs (TKI) do not have to be indicated. For this reason, in UP_FG_SVF No. 2 (PL_TK_SRP # 2) in the List of playable_files_№3 (Playlist # 3) from all IDFs No. 4 to No. 7 (TKI # 4- # 7), only IDF No. 4 (TKI # 4) is indicated.

On the other hand, the volume of ISVFU data (DPLI), which contains a lot of UP_FG_SVFU (DPL_TK_SRP), does not exceed the size of one sector, and it is always loaded into the RAM (random access memory) of the playback device. In the case when the phonograms are reproduced according to the List of playable files (Playlist), the playback device performs a call to UP_FG_SVFU (DPL TC SRP), which is loaded into its RAM, and thus can search for IDF (TKI) at high speed. To play IDF (GOITER) (TKI (AOW)) using UP_FG_SVF (PL_TK_SRP), which indicates the IDF number (TKI) of only the first IDF (TKI), the playback device searches UP_FG_SVFU (DPL_TK_SRP) loaded in its RAM, based on the ID (TKI), indicated by UP_FG_SVF (PL_TK_SRP), and concludes whether the current phonogram really consists of a set of IDF (TKI). If so, then the playback device performs the corresponding operation to play all the corresponding IDFs (GOITERS) (TKIs (AOBs)).

As described above, the PlaylistManager Administrator records the Default_Playlist and the set of PLIs. If in NIDF_SVFU (DPL_TKINs) and NIDF_SVFU (PL_TKINs) those UP_FG_SVFU (DPL_TK_SRPs) and UP_FG_SVFU (PL_TK_SRPs), which form such lists of playable files, a different playback order is recorded in different order, it becomes possible to execute it differently. By offering the user a multitude of playback order options that are implemented in this way, the user can get the impression that several music albums are stored in the flash card 31.

It should be especially noted that UP_FG_SVFU (DPL_TK_SRP), corresponding to the GOITER (AOW) file, has a small amount of data (no more than two bytes), and IDFs (TKI) corresponding to the GOITER (AOW file) have a large amount of data (up to 1,024 bytes). When reordering IDFs (TKI) in the phonogram manager (TrackManager), you need to perform a large number of access operations to the 31 flash memory board, however, reordering UP_FG_SVFU (DPL_TK_SRPs) in the Information_of_list_of_playable_files_ by default (There can be less (Default) or PLAYlist) access operations to the board 31 flash memory.

With this in mind, when editing navigation data, there is a significant change in the order of UP_FG_SVFU (DPL_TK_SRPs) in the Default_Playlist according to the editing operation, however, the order of the IDF (TKI) in the phonogram manager (TrackManager) remains unchanged despite the editing operation .

{17-9_40-2_43A, B} Reordering UP_FG_SVFU (DPL_TK_SRP)

The following is a description of the editing operation, in which the order of playing the phonograms is changed by reordering UP_FG_SVFU (DPL_TK_SRPs) in the Default_laylist_Information_playable_list_information (Default_Playlist_Information). On Figa and Figb shows one example of a reordering of phonograms. UP_FG_SVFU (DPL_TK_SRPs) and IDF (TKI) of Fig. 43A have the same set parameters as in Fig. 40.

In Fig. 43A, the value of NIDF_SVFU (DPL_TKIN) in UP_FG_SVFU No. 3 (DPL_TK_SRP # 3) is set to the corresponding IDF No. 8 (TK1 # 3), and the value of NIDF_SVFU (DPL_TKIN) in UP_FG_SVFU No. 8 (DPL_8K) is set to TKI # 8). The following is a description of an example where these UP_FG_SVFU (DPL_TK_SRPs) highlighted in FIG. 43A by a thick outline are reversed.

The numbers (1) (2) (3) (4) (5) (6) (7) (8) in FIG. 43B indicate the order in which phonograms are played after this editing operation. It should be noted here that Fig. 43A shows the following playback order: Phonogram A, Phonogram B, Phonogram B, Phonogram D, Phonogram D (TrackA, TrackB, TrackC, TrackD, TrackE), and Fig. 43B in the Default_laylist_of_play_files (Default_Playlist_Information) implemented permutation NIDF_SVFU (DPL_TKINs) UP_FG_SVFU №3 and UP_FG_SVFU №8 (DPL_TK_SRP # 3, DPL_TK_SRP # 8) with each other, so phonograms reproduction is performed in the following order: Soundtrack A soundtrack B, D Soundtrack, Soundtrack T, phonograms (TrackA, TrackB, TrackE, TrackD, TrackC). In this way, the order of playing back phonograms can be easily implemented by changing the order UP_FG_SVFU (DPL_TK_SRPs) in the Default_laylist_Information_playlist_file_information (Default_Playlist_Information).

In the above description, the editing operation is considered, in which the sequence of the phonograms is changed, and the following four operations are described, the explanation of which was given when describing the changes in the IDF (TKIs). These operations are: the first example (Example 1), in which a phonogram is deleted, the second example (Example 2), in which a new phonogram is recorded, and the third example (Example 3), in which two randomly selected phonograms are combined to create a new phonogram and the fourth example (Example 4), in which the phonogram is separated to create two new phonograms.

{17-9_40-3_44A, B} Erasing a soundtrack

The following is a description of Example 1, in which the phonogram is deleted.

Fig. 44A and Fig. 44B show how to update the List of playable default files (DefaultPlaylist), the phonogram manager (TrackManager) and GOITER files (AOW files) in the case when the Default Playlist_File2 is deleted from the List of reproducible_files (DefaultPlay_File2) (DPL_TK_SRP # 2) and IDF No. 2 (TKI # 2). In these drawings, the same part of the GOITER (AOW) is removed as in FIG. 27, which was used to describe the removal of IDF (TKI). As a result, the second, third, and fourth levels in Fig. 44A and Fig. 44B are the same as in Fig. 27. The difference from FIG. 27 is that the first level shows the same as FIG. 40, Default_laylist_Information information_list_of_playable_files (Default_Playlist_Information) containing a plurality of UP_FG_SWFU (DPL_TK_SRPs).

In this example, the case in which the user deletes Phonogram B (TrackB) consisting of UP_FG_SVFU No. 2 → IDF No. 2 (DPL_TK_SRP # 2 → TKI # 2) ("AOB002.SA1"), which is highlighted in Fig. 44A, is considered. thick outline. In this example, UP_FG_SVFU No. 2 (DPL_TK_SRP # 2) is deleted from Default_lay_list_of_playable_files (Default_Playlist_Information), and each of UP_FG_SVFU # 3 to # 8 (DPL_TK_SRP # 3 - moves DPL_TKSR one position in this way forward one way relative to 8] filling in the place in the sequence that was freed up when deleting UP_FG_SVFU No. 2 (DPL_TK_SRP # 2).

After performing such a permutation UP_FG_SVFU (DPL_TK_SRPs), the last UP_FG_SVFU No. 8 (DPL_TK_SRP # 8) is set to "Unused". On the other hand, as shown in FIG. 21A and FIG. 27B, the IDFs (TKIs) corresponding to the deleted part are set to “Unused”, while other IDFs (TKIs) are not moved to fill the gap created during deletion . The removal of IDF (TKI) is also accompanied by the removal of the file GOITER (AOW file) "AOB002.SA1".

In this way, UP_FG_SVFU (DPL_TK_SRP s) is moved forward in the playback order without moving IDFs (TKI), therefore, in FIG. 44B, only NIDF_SVFU (DPL_TKINs) in UP_FG_SVFU (DPL_TK_SRPs) are updated. In this example, NIDF_SVFU (DPL_TKIN) in UP_FG_SVFU No. 2 (DPL_TK_SRP # 2) is set so that it indicates IDF No. 3 (TKI # 3), which is indicated by the arrow DT11, NIDF_SVFU (DPL_TKIN) in UP_FG_SVFU_SVFU_SVFU_SVFU_SVFU_SVFU_SVFU_SVFU_SVFU_SVFU_SVFU_SVFU_SVFU_SVFU_SVFU_SVFU_SVFU_SVFU_SVFU_SVFU_SVFU_SVFU_SVFU_SVFU_SVFU_SVFU_SVFU_SVFU_SVFU_SVFU_SVFU_SVFU_SVFU_SVFU_SLVU such that it indicates IDF No. 4 (TKI # 4), which is indicated by the arrow DT12, NIDF_SVFU (DPL_TKIN) in UP_FG_SVFU No. 4 (DPL_TK_SRP # 4) is set so that it indicates IDF No. 5 (TKI # 5), and NIDF_SVFU ( DPL_TKIN) in UP_FG_SVFU No. 5 (DPL_TK_SRP # 5) is set such that it indicates IDF No. 6 (TKI # 6). NIDF_SVFU (DPL_TKIN) in UP_FG_SVFU No. 8 (DPL_TK_SRP # 8), the value of which was previously set to "Unused", set to the appropriate IDF No. 2 (TKI # 2), as shown by arrow DT13.

When the phonogram is deleted, UP_FG_SVFU (DPL_TK_SRP), used for subsequent phonograms in playback order, is advanced, and the IDFs (TKI) corresponding to the deleted phonogram are set to "Unused" while maintaining their current location. Thus, the editing operation is not accompanied by the movement of IDF (TKI), which reduces the computational load when editing phonograms.

{17-9_40-4_45A, B) Assignment of IDF (TKI) when recording phonograms

The following is a description of Example 2, in which, after deleting part of the phonogram, a new phonogram is recorded. On figa and figb shows the execution of the write operation of the new IDF (TKI) and UP_FG_SVFU (DPL_TK_SRP) in the presence of "Unused" IDF (TKI) and UP_FG_SVFU (DPL_TK_SRP) are present.

These figures are substantially similar to FIGS. 28A and FIG. 28B, which were used to explain the assignment of new IDFs (TKIs) to IDFs (TKIs) having a value of “Unused”. The second, third and fourth levels in Fig. 45A and Fig. 45B are identical to the first three levels in Fig. 28A and Fig. 28B. The difference between these drawings is that in Fig. 45A and Fig. 45B, the first levels show Default_playlist_Information_list_information, consisting of a plurality of DPL_TK_SRPs UP_FG_SRFU. On Figa in UP_FG_SVFU from No. 4 to No. 8 (DPL_TK_SRP # 4-DPL_TK_SRP # 8) set to "Unused". However, in FIG. 28, in IDF No. 2, IDF No. 4, IDF No. 5, IDF No. 7, IDF No. 8 (TKI # 2, TKI # 4, TKI # 5, TKI # 7, TKI # 8), the values "Unused "

Despite the fact that IDFs (TKIs) with the values "Unused" are located in different places of the phonogram manager (TrackManager), the Default_laylist_Information and Default_laylist_information files are located next to each other in DPL_TK_SRPs. This is due to the fact that, as described above, in the Default_Playlist_Information default_playlist_of_list (DPL_TK_SRPs) used information, they advance forward, but for IDFs (TKIs), this promotion is not carried out.

The following explanation describes an example in which a Phonogram G (TrackD) is recorded, consisting of four GOITERS (AOB). IDF (TKI) for these four GOITERS (AOW) are recorded, respectively, in the following "Unused" IDF (TKI) in the phonogram manager (TrackManager): IDF No. 2, IDF No. 4, IDF No. 7 and IDF No. 8 (TKI # 2 , TKI # 4, TKI # 7, TKI # 8).

UP_FG_SVFU (DPL_TK_SRPs) for these four GOITERS (AOW) are recorded in UP_FG_SVFU from No. 4 to No. 7 (DPL_TK_SRP # 4 - DPL_TK_SRP # 7) in the Default_play_playlist_information Default_file information (Default_list). Since these four SCA (AOB) form a single soundtrack, the value ATR_FG_SVFU (DPL_TK_ATR) UP_FG_SVFU №4 (DPL_TK_SRP # 4) is set as "Home Audio records" ( "Head of Track"), the value ATR_FG_SVFU (DPL_TK_ATRs) UP_FG_SVFU №5 (DPL_TK_SRP # 5) and UP_FG_SVFU No. 6 (DPL_TK_SRP # 6) are set as "Middle_On_Fonograms" ("Middle_of_Track"), and the value ATR_FG_SVFU (DPL_TK_ATR) UP_FG_SVFU # 7 (DPL_TK_SRF_on_Kone_Fone_Not_From_Not_on_) "End_ 7").

NIDF_SVFU (DPL_TKIN) UP_FG_SVFU No. 4 (DPL_TK_SRP # 4) are set to the corresponding IDF No. 2 (TKI # 2), NIDF_SVFU (DPL_TKIN) UP_FG_SVFU No. 5 (DPL_TK_FS_FUL_FID_I_FID_I_FID_FUL_FID_I_FID_I_FID_FUL_FID_FUL_FD_I_FID_FIL_FUL_FUL_FUL_FID_FL_TK_FID_FID 6 (DPL_TK_SRP # 6) - corresponding to IDF No. 7 (TKI # 7), and NIDF_SVFU (DPL_TKIN) UP_FG_SVFU No. 7 (DPL_TK_SRP # 7) - corresponding to IDF No. 8 (TKI # 8).

By a similar setting of the values NIDF_SVFU (DPL_TKINs) and ATR_FG_SVFU (DPL_TK_ATRs), the control of IDF No. 2, IDF No. 4, IDF No. 7 and IDF No. 8 (TKI # 2, TKI # 4, TKI # 7, TKI # 4 of the background, is carried out as Phonogram G (TrackD).

In the above processing, recording is carried out in "Unused" IDFs (TKI), while they do not have any effect on other IDFs (TKI), IDF No. 1, IDF No. 2, IDF No. 3 and IDF No. 4 (TKI # I, TKI # 2 , TKI # 3, and TKI # 4), which was also shown in FIG. 28A and FIG. 28B.

{17-9_40-5_46A, B} Example 3: Combining phonograms

The following is a description of updating the Default_laylist_Information Information_of_list_of_playable_files (Default) when combining phonograms (that is, in Example 3). On figa and figb shows one example of a combination of phonograms.

These figures are substantially similar to Figs. 29A and 29B, which were used to explain the IDF combining procedure (TKI). The second, third, and fourth levels in Fig. 46A and Fig. 46B are identical to the two first levels in Fig. 29A and Fig. 29B. The difference between these drawings is that at the first level of Fig. 46A and Fig. 46B, Default_playlist_Information is shown, in which UP_FG_SVFU No. 8 (DPL_TK_SRP # 8) has the set value "Unused" and associated with TID No. 2 # 2), the value of which is also set to "Unused". When performing the editing operation shown in FIG. 29A and FIG. 29B for combining phonograms for files GOITER (AOW) and IDF (TKI), the contents of each UP_FG_SVFU No. 3 to No. 6 (DPL_TK_SRP # 3 - DPL_TK_SRP # 6) are moved down one position, and the contents of UP_FG_SVFU No. 7 (DPL_TK_SRP # 7), indicated by a thick outline, are copied to UP_FG_SVFU No. 3 (DPL_TK_SRP # 3), as shown in Fig. 46A and Fig. 46B. An IDF update (TKI) is also performed as shown in FIG. 29A and FIG. 29B.

{17-9_40-6_47A, B} Example 4: Phonogram separation

The following is a description of updating the Default_Playlist_Inforination Default_list_of_playable_files when splitting a track (Example 4).

On figa and figb shows one example of the separation of the phonogram. These drawings are largely similar to FIGS. 33A and 33B, which were used to explain the IDF separation procedure (TKI). The second and third levels in FIG. 47A and FIG. 47B are identical to the two first levels in FIG. 33A and FIG. 33B. The difference between these drawings is that at the first level of Fig. 47A and Fig. 47B, Default_playlist_Information is shown, in which UP_FG_SVFU No. 8 (DPL_TK_SRP # 8) has the set value "Unused" and associated with IDF No. 2 # 2), the value of which is also set to "Unused".

As in Fig. 33A and Fig. 33B, if the user indicates that IDF No. 3 (TKI # 3) ("AOB003.SA1"), which are highlighted by a thick outline, should be divided into two parts, then each of UP_FG_SVFU from No.3 to No.7 (DPL_TK_SRP # 3 - DPL_TK_SRP # 7) is moved down one order of magnitude, and UP_FG_SVFU (DPL_TK_SRP), which is set to "Unused", is moved inside the list of the No. 3 (DPL_TK_SRP # 3).

This new UP_FG_SVFU No. 3 (DPL_TK_SRP # 3) corresponds to the new IDFs (TKI) created by splitting, namely, IDF No. 2 (TKI # 2). In the GOITER (AOW file) "AOB002. SA1" corresponding to IDF No. 2 (TKI # 2), save what was originally the last part of the GOITER (AOW file) "AOV003.SA1". UP_FG_SVFU No. 2 (DPL_TK_SRP No. 2), corresponding to IDF No. 2 (TKI # 2) and "AOB002. SA1", located in front of UP_FG_SVFU No. 3 (DPL_TK_SRP # 3), which corresponds to IDF No. 2 (TKI # 2).

That is, in "AOB002. SA1" and "AOV003. SA1", respectively, the second and first parts of the original "AOVOOZ.SA1" are stored, and the files UP_FG_SVFU No. 2 (DPL_TK_SRP # 2) and UP_FG_SVFU No. 3 (DPL_TK_SRP # 3, respectively) are stored. ) indicate that the reproduction of these GOITERS (AOB) should be performed in the following order: "AOB003. SA1" and "AOB002.SA1". As a result, the reproduction of the second and first parts of the original "AOB003.SA1" will be performed in the following order: the first part, the second part, which corresponds to the playback order that is specified in UP_FG_SVFU (DPL_TK_SRP).

{17-9_40-8} Applying Editing Processing

By combining the four editing procedures above, a user can perform a wide variety of editing operations. For example, in the case where the recorded phonogram has an introduction, on top of which the speech of the leading music program is recorded, the user can first divide the phonogram so as to separate the part that contains the voice of the leader of the music program. Then the user can delete this phonogram, having left for itself that part of the phonogram that does not contain the voice of the host of the musical transmission.

This completes the description of the navigation data. The following is a description of a reproducing apparatus having a proper structure capable of reproducing the navigation data and reproduced data described above.

{48-1} Appearance of the playback device

On Fig depicts a portable playback device for the card 31 flash memory of the present invention. The playback device shown in FIG. 48 has a slot for inserting a flash memory card 31, a keypad for receiving user instructions for performing operations such as playback, forward search, reverse search, forward rewind, rewind, stop, etc. .d., and LCD (liquid crystal) panel. In terms of appearance, this playback device is similar to other types of portable music players (players).

The keypad contains:

the "Playlist" button, by which a list of playable files or soundtracks is selected;

the "| <<" key, by which a skip operation is performed, in which the playback position is shifted to the beginning of the current phonogram;

the key ">> |", by which the skip operation is performed, in which the playback position is shifted to the beginning of the next phonogram;

the "<<" key and the ">>" key, by means of which, respectively, the search operation in the reverse direction and the search operation in the forward direction are performed, which allows the user to quickly play the current phonogram;

the “Display” key, by which the operation of displaying still images stored in the flash memory card 31 is performed on the screen;

the "Rec" key, by which a recording operation is performed;

the "Sound" key, by which the user selects the sampling frequency or the mode used: stereo or monaural;

the "Mark" key, by which the user indicates specific marked places in the phonograms;

and

the "Edit" key, by which the user edits the phonograms or enters the titles of the phonograms.

{48-2} Improvements made in this portable playback device for the flash card 31.

The differences between this portable playback device for the flash memory card 31 and the conventional portable music player are the following four enhancements from (1) to (4).

(1) A table of the list of playable files and a list of phonograms is displayed on the LCD panel, which allows the user to display Default_laylist_Information, Default Sound Information List (PLI), or individual phonograms.

(2) The keys on the keypad are aligned with the lists of playable files and / or phonograms displayed on the LCD panel, which allows the user to select a phonogram or list of playable files for playback or editing.

(3) On the LCD panel 5, a time code is displayed that indicates the location inside the track when playing the track.

(4) A rotary disc with step switching is provided, which allows the user to set the time code value used as the start time of the playback when using the time search function or as a separation boundary when dividing a phonogram.

{48-2_49_50} Improvement (2)

The following is a detailed description of the enhancement (2). On Fig shows one example of the image on the LCD screen when the user selects a list of playable files, and the drawings from Fig. 50A to Fig. 50D show examples of content display when the user selects a phonogram.

On Fig lines with ASCII characters (American standard code for the exchange of information) "PLAY_LIST_DEFAULT_FILES" ("DEFAULT PLAY-LIST"), "PLAY_LIST_FILES # 1" ("PLAY_LIST_LIMP # 1 PLAYLIST # 2 ")," PLAYLIST_FILES No. 3 "(" PLAYLIST # 3 ") and" PLAYLIST_FILES No. 4 "(" PLAYLIST # 4 ") display the list of playable files set by default, and four lists of playable files in the memory card 31 flash memories.

Meanwhile, the ASCII character strings are “Phonogram No. 1”, “Phonogram No. 2”, “Phonogram No. 3”, “Phonogram No. 4”, “Phonogram No. 5” (“Track # 1”, “Track # 2”, “Track # 3 "," Track # 4 "," Track # 5 ") display five phonograms, which are indicated in the playback order, which is indicated by the list of playable files set by default, stored in the card 31 flash memory. On Fig and 50A through the shaded highlighted list of playable files and phonograms, that phonogram or list of playable files that are currently indicated as intended for playback or editing is shown.

If the user presses the ">>" key at the moment when Phonogram No. 1 (Track # 1) is marked as the one intended for playback in the playback order indicated in the list of playable files displayed on the LCD panel by default as shown in Fig. 50B, the Phonogram No. 2 (Track # 2) will be indicated in the list of phonograms as intended for playback. If the user presses the ">>" key again, then, as shown in Fig. 50B, the Phonogram No. 3 (Track # 3) will be indicated in the list of phonograms as intended for playback.

If the user presses the ">>" key at the moment when Phonogram No. 3 (Track # 3) is marked as the one intended for playback in the playback order indicated in the list of playable files displayed on the LCD panel by default as shown in Fig. 50G, the Phonogram No. 2 (Track # 2) will be indicated in the list of phonograms as intended for playback. As shown in Fig. 50D, if at the moment when any of the phonograms is checked, the user presses the "Play" key, then playback of the specified phonogram starts, and if the user presses the "Edit" key, then the specified phonogram will be selected as intended for editing.

{48-3_51} Improvement (4)

The following is a detailed description of the enhancement (4). In the drawings FIG. 51A to FIG. 51B, an example of the operation of a rotary disk with step switching is shown. When the user rotates the rotary dial in steps to a predetermined angle, the value of the playback time code displayed on the LCD panel is increased or decreased in accordance with this predetermined angle. In the example of FIG. 51A, a case is shown in which the initial value of the playback time code displayed on the LCD panel is “00:00:20”.

When the user rotates the rotary dial with step change counterclockwise as shown in FIG. 51B, the value of the play time code is reduced to “0:00:10” in accordance with the magnitude of the angle by which the rotary dial with step change is rotated. Conversely, in the case where the user rotates the rotary dial with stepwise clockwise rotation as shown in Fig. 51B, the value of the playback time code is increased to the value “0:00:30” in accordance with the value of the angle by which rotatable rotary dial with step change.

By allowing the user to change the playback time code in a similar manner, the playback device allows the user to specify any playback time code in the phonogram simply by rotating the rotary dial with step switching. If the user then presses the "Play" (Play) key, then the GOITER (AOW) is reproduced starting from the place that is found according to Equation 2 and Equation 3.

By using a rotary dial with step switching when performing a phonogram separation operation, a user can fine-tune the playback time code when used as a separation boundary.

{52-1} The internal structure of the playback device

The following is a description of the internal structure of the playback device. This internal structure is shown in FIG.

As shown in Fig. 52, the playback device includes a board connector 1 for connecting the playback device to the flash memory card 31, a user interface unit 2, which is connected to a keypad and to a rotary disk with step switching, RAM 3, ROM 4, LCD panel 5 having a list window for displaying a list of phonograms or lists of reproduced files and a window of a playback time code for displaying a playback time code, an LCD control device 6 for controlling the first LCD panel 5, a case decoder 7 sequences for decryption of GOITER_FRAMEs (AOB_FRAMEs) using different file keys (FileKey) for each GOITER file (AOW file), decoder 8 of ultrasonic scanning (advanced audio information encoding) (AAC) for accessing ADTS FRAME (AOB_FRAME), the decryption of which implemented by means of a decoder 7 random sequences, and the implementation of decoding KADRA_ZOB (AOB_FRAME) to obtain PCM data (PCM), digital-to-analog converter (DAC) 9 for digital-to-analog conversion of PCM data and output received as a result, analog signals to a loudspeaker or to a headphone jack, and a central processing unit (CPU) 10 for centralized control of a playback device.

From this hardware structure, it is understood that the present playback device does not have any special hardware devices for processing the phonogram manager (TrackManager) and Default_laylist_Information_On_playable_list_information (Default_Playlist_Information). For processing the administrator of the phonograms (Track-Manager) and Information_of_list_of_playable_files_of_default (Default_Playlist_Information), in RAM 3 create a storage area 11 permanent storage ISVFU (DPLI), storage area 12 ISVF (PLI), storage area 13 IDF (TKI), storage area 14 Key file (FileKey) and a double buffer 15, and in ROM 4, a playback control program and an editing control program are stored.

{52-2} ISVFU Permanent Storage Area 11 (DPLI)

The ISVFU storage area 11 (DPLI) is an area for permanently storing Default_Playlist_Information_List_Playlist_Information, which was read from the flash memory card 31 connected to the card slot 1.

{52_12} ISVF Storage Area 12 (PLI)

ISVF storage area 12 (PLI) is an area that is reserved for storing Playlist_Information information_of_list_of_ information selected by the user for playback.

{52-3} IDF Storage Area 13 (TKI)

The storage area IDF (TKI) is an area that is reserved for storing only those IDFs (TKI) from the set of IDFs (TKI) contained in the administrator of phonograms (TrackManager), which correspond to the file GOITER (AOW file), currently specified in as intended for playback. For this reason, the capacity of the IDF storage area 13 (TKI) is equal to the data volume corresponding to one IDF (TKI).

{52-4} Storage area 14 of the file key (FileKey)

The storage area 14 of the file key (FileKey) is an area that is reserved for storing only that file key (FileKey) from the plurality of file keys (FileKeys) contained in the "AOBSA1.KEY" in the identification area that correspond to the file GOITER (AOW file) currently indicated as intended for playback.

{52-5} Double buffer 15

The double buffer 15 is an input-output buffer, which is used in parallel to the input process, in which the cluster data (data stored in one cluster) read from the flash memory card 31 is sequentially input and the output process is read GOITERS (AOB_FRAMEs) from the cluster data and sequential output of GOITERS (AOB_FRAMEs) to the decoder 7 random sequences.

The double buffer 15 sequentially frees the areas that were occupied by the cluster data output in the form of AOB_FRAMEs, and thus provides areas for storing the next readable clusters. This means that in the double buffer 15 carry out the cyclic allocation of areas for storing cluster data using ring pointers.

{52-5_53_54AB) Input and output via double buffer 15

Fig. 53 shows how input and output are performed for the double buffer 15. Figs. 54A and Fig. 54B show how, in the double buffer 15, the regions for storing the cluster data are used using circular pointers.

The arrows pointing down and to the left are the address pointers where the cluster data is being written, that is, the write pointers. The up and left arrows represent address pointers from where the cluster data is read, that is, read pointers. These pointers are used as a circular pointer.

{54-6_53}

When connecting the flash memory board 31 to the connector of the board 1, the cluster data is read from the user area in the flash memory board 31 and stored in the double buffer 15, as shown by the arrows w1 and w2.

The read cluster data is sequentially stored in those places of the double buffer 15, which are indicated by the write pointers wp1 and wp2.

{52-7_54A}

, которые последовательно указаны посредством указателя считывания, что показано стрелками r1, r2, r3, r4, r5....Of all the FACING_THE CARD (AOW_FRAMEs) contained in the cluster data stored in this way, one random output of the FACING_THE (AOB_FRAMEs) located in those places is carried out to the decoder 7 random sequences

which are sequentially indicated by a read pointer, as shown by the arrows r1, r2, r3, r4, r5 ....

последовательно указывают посредством указателя считывания. Когда указатель считывания доходит до позиции считывания 5, все КАДРы_ЗОБ (AOB_FRAMEs), содержащиеся в кластере 002, оказываются считанными, при этом выполняют считывание кластера 004 и, как показано стрелкой w6 на Фиг.54А, его перезапись в ту область, которая была ранее занята кластером 002.In this case, as shown in FIG. 53, the data 002 and 003 are stored in the double buffer 15 of the cluster, and the read positions

sequentially indicated by a read pointer. When the read pointer reaches read position 5, all AOB_FRAMEs contained in cluster 002 are read, while reading cluster 004 and, as shown by arrow w6 in FIG. 54A, overwriting it to the area that was previously occupied cluster 002.

{52-8_54B}

и

, и в конечном счете достигает позиции считывания

, причем в этот момент будет завершено считывание всех КАДРов_ЗОБ (AOB_FRAMEs), содержащихся в кластере 003, поэтому осуществляют считывание кластера 005 и, как показано стрелкой w7 на Фиг.54В, его перезапись в ту область, которая была ранее занята кластером 003.Then the read pointer reaches the read positions

and

, and ultimately reaches the reading position

and at that moment, the reading of all AOB_FRAMEs contained in cluster 003 will be completed, therefore, cluster 005 will be read and, as shown by arrow w7 in Fig. 54B, it will be rewritten to the area that was previously occupied by cluster 003.

The operations described above for outputting CARD_CHAW (AOB_FRAME) and overwriting cluster data are performed repeatedly, thereby sequentially outputting all CARD_CHAIN (AOB_FRAMEs) contained in the GOITER file (AOW file) to random sequence decoder 7 and to USPI decoder 8 (AAC).

{52-9_55-58} A playback control program stored in ROM 4

The following is a description of the playback control program, which is stored in ROM 4.

Fig. 55 is a flowchart showing processing during the reading procedure of a GOITCHEST file (AOW file).

Fig. 56, Fig. 57, and Fig. 58 are flowcharts showing processing during the output procedure AOB_FRAME.

{52-9_55-1}

In these flowcharts, the variables w, z, y, and them are used. Variable w denotes one of the many UP_FG_SVFU (DPL_TK_SRPs). The variable z denotes the file GOITER (AOW file), recorded in the user area, IDF (TKI) corresponding to this file GOITER (AOW file), and GOITER (AOW) contained in this file GOITER (AOW file). The variable y is indicated by GOITER (AOB_ELEMENT) contained in GOITER No. z (AOB # z), which is indicated by the variable z. The variable x is designated KOBR_ZOB (AOB_FRAME), contained in the ELEMENT_ZOB No. (AOB_ELEMENT # y), which is indicated by the variable y. Below, with reference to Fig. 55, first of all, an explanation of the processing when performing the procedure for reading the file GOITER (AOW file).

{52-9_55-2}

In step S1, the central processing unit (CPU) 10 reads the administrator of the playlist file (PlaylistManager) and displays a list containing the default_playlist_of_file_default (Default_Playlist_Information) and the IFI (PLI).

In step 32, the CPU 10 waits for instructions to play the GOITER (AOW) according to either Default_laylist_Information Information_O_List_ of Playable_Files or one of the IFIs (PLIs).

In the case when the Default_List_Playlist_Information is specified, the processing proceeds from operation 32 to operation 33, in which the w variable is initialized (No. (w-1)) (# w-1), and then to operation S4, in which determine IDF No. z (TKI # z), indicated by NIDF_SVFU (DPL_TKIN), corresponding UP_FG_SVFU No. w (DPL_TK_3RP # w) in the Information_of_the_playable_files_of_the_default (Default_Playlist_Information), and TI # read only memory and their storage in the field 13 of the storage IDF (TKI).

In step 35, a GOITTLE No. z file (AOV file #z) is determined, which has the same number as IDF No. z (TKI # z). In this way, the GOITER (AOW file) that is intended for playback is finally determined.

The GOITER (AOW file) defined in this way is in an encrypted state and must be decrypted; therefore, operations S6 and S7 are performed. In step S6, the reproducing apparatus accesses the identification area and reads the Key No. z of the file (FileKey # z), which is stored in the Entry_of_key_file #z (FileKey_Entry # z) in the file for storing the encryption key, and the Entry_o_key_file # 2 (FileKey_Entry # z) has the same number as the GOITER file defined above (AOW file). When performing operation 37, SP 10 sets 7 random sequences in the decoder to the value of Key No. z of the file (FileKey # z). The result of this operation is that if there are 7 random sequences of the File Key (FileKey) installed in the decoder, sequential playback of AOB_FRAMEs can be performed by sequentially inputting 7 sequences of GOITER (AOB_FRAMEs) contained in the GOITER (AOW file) into the decoder. .

{52-9_55-3}

After that, the playback device performs sequential reading of those clusters in which the GOITER (AOW file) is stored. In step S8, the “first cluster number in the file” is indicated in the directory entry for GOITER No. z (AOB_file # z). In step S9, the CPU 10 reads data stored in this cluster from the flash memory card 31. In step S10, the CPU 10 determines whether the cluster number in the TRF (FAT) is “FFF”. If this is not the case, then before returning to operation S10, operation S11 is performed, in which the CPU reads the data stored in the cluster, which is indicated by the value of the TRF (FAT).

In the case when the playback device reads the data stored in any of the clusters and accesses the FAT value corresponding to that cluster, the processing performed by performing operations S10 and S11 is repeated until the FAT value is set to “FFF” " This leads to the fact that the playback device sequentially reads the clusters determined by the FAT values. When the cluster number determined by the FAT value becomes "FFF", this means that all the clusters constituting the GOITER No. z file (AOB file # z) have been read, and in the process, they proceed from operation S10 to operation S12.

{52-9_55-4}

In step S12, the CPU 10 determines whether the variable #w (#w) matches the total number of UP_FG_SVFU (DPL_TK_SRPs). If this is not so, then before returning the processing to operation S4, during processing, they proceed to operation 313, in which the variable No.w is incremented by one (w ← w + 1) (# w- # w + 1 ) In operation S4, the playback device determines the IDF No. z (TKI # z), which are indicated by NIDF_SVFU No. w (DPL_TKIN # w) UP_FG_SVFU No. w (DPL_TK_SRP # w) in the Information_of_list_of_playable_files_of_the_default (Default_Playlist and Data_Inscription in Default_Playlist ) only IDF No. z (TKI # z). Previously used IDFs (TKIs) that were previously stored in the storage area 13 of IDFs (TKIs), however, currently used IDFs (TKIs) will be overwritten by new IDFs No. z (TKI # z), which are read by CPU 10.

This rewriting leads to the fact that in the storage area 13 IDF (TKI) is remembered only the most recent IDF (TKI). After overwriting the IDF (TKI), the processing performed by operations S5 to S12 is repeated for the GOITER No. z file (AOB file # z). After this processing is performed, all IDFs (TKIs) and GOITER files (AOW files) corresponding to all UP_FG_SVFU (DPL_TK_SRPs) contained in the Information_of_playable_files_of_default_files (Default_Playlist_Information) will be read with the number zF #z and the value will be the same as z # (z) with the number z (#z) (DPL_TK_SRP), therefore, when performing operation S12, the decision is “Yes” and the processing is completed according to this flowchart.

{52-9_56_57_58} Processing upon output of FRAME_CRAFT (AOB_FRAME)

Simultaneously with the reading of the GOITER file (AOW file), the CPU 10 performs the output procedure AOB_FRAME in accordance with the flowcharts shown in Fig. 56, Fig. 57, and Fig. 58. In these flowcharts, the variable Play_Time (Play_time) indicates the duration of playback of the current phonogram to the present point in time, that is, the code of the playback time. In accordance with the changes of this code, the playback time updates the time, which is displayed in the window of the playback time code on the LCD panel 5. Meanwhile, the variable "reproducible_data" (play_data) displays the length of the data for the current phonogram that has been reproduced so far .

{52-9_56-1}

In step S21, the CPU 10 controls whether the cluster data for the GOK file No. z (AOB file # z) is accumulated in the double buffer 15. This operation S21 is repeatedly performed until the cluster data is accumulated, and at this point during processing they proceed to operation S22, in which the variables x and y are initialized (No. x ← 1, No. y ← 1). After that, when performing operation S23, the CPU 10 searches for clusters for the GOITER #z file (AOB file # z) and detects the GOAL_CHAD Nox (AOB_FRAME # x) in the GOITER_NAME (AOB_ELEMENT # y), which is located no earlier than that Data_Shift (Data 0ffset), which is specified in TIB No. z (BIT # z) contained in IDF No. z (TKI # z). In this example, the ADTS header is assumed to occupy seven bytes, starting with OBDATA (SZ_DATA). By reference to the ADTS header, data having the length indicated in the ADTS header can be identified as audio data. Carry out a joint reading of the audio data and the ADTS header and their output to the decoder 7 random sequences. The random sequence decoder 7 decodes the GOALS (AOB_FRAMEs), which are then decoded by the USPD decoder 8 (AAC) and reproduced in the form of sound.

{52-9_56-2}

After this detection has been performed, in step S24, the CADRA_ZOB #x (AOB_FRAME # x) is output to the decoder 7 random sequences, and in step S25, the variable Play_time is incremented by an amount equal to the duration of the playback CADRA_ZOB No.x (AOB_FRAME # x), and the increment of the variable "reproducible_data" (play_data) by the amount of data corresponding to CARD FRAME #x (AOB_FRAME # x). Since in this case the playback time KADRA_ZOB (AOB_FRAME) is 20 ms, 20 ms is added to the variable "Play_time" (Play_time).

Immediately after the first FRAME (AOB_FRAME) is output to the decoder 7 random sequences, the playback device performs an operation S26, in which it accesses the ADTS header FRAME_CHAIN No. (AOB_FRAME # x) and determines the location of the next FRAME (AOB_FRAME). In step S27, the reproducing apparatus increments the variable x (# x ← # x + 1) and sets GOITER #X (AOB_FRAME # x) as the next GOAD_FRAME (AOW_FRAME). In step S28, KADRA_ZOB No.x (AOB_FRAME # x) is input into the decoder 7 random sequences. After that, at the step of performing operation S29, the variable “Play_time” is incremented by an amount equal to the duration of the playback FRAME_X (AOB_FRAME # x), and the increment of the variable “reproduced_data” (play_data) is increased by the amount of data corresponding to the RAM_ZOB No.x (AOB_FRAME # x). After the increment on KADR_KIT No.x (AOB_FRAME # x) is performed, operation S30 is performed, in which the CPU 10 determines whether the variable x (# x) has reached the value set in FNs_lst_TMSRTE).

If the variable x (# x) has not reached the value specified in FNs_lst_TMSRTE, then operation S31 is performed, in which the playback device checks whether the user has pressed any key other than the “Play” key (“Play” ), and then return to operation S26. After that, the playback device repeats the processing, performing operations S26 to S31 until the value of the variable x (# x) reaches the value indicated in FN_1st_TMSRTE, or until the user presses any other a key than the Play key.

In the case when the user presses a key other than the “Play” key, the processing according to this flowchart is completed and the proper processing is performed in accordance with the pressed key. In the event that the pressed key is the Stop key, the playback process is stopped, and if the pressed key is the Pause key, the playback is paused.

{52-9_57-1}

Otherwise, if the value of the variable x (# x) has reached the value specified in FNs_lst_TMSRTE, then, in step S30, the decision is Yes, and processing is continued by performing step S32 shown in FIG. 57. Since when processing from operation S26 to operation S30, all random AOB_FBAMEs contained in the currently used CLEANING ELEMENT (AOB_ELEMENT) were necessarily entered into the descrambler 7 of random sequences, while performing operation S32, the increment of the variable y (# y) is performed so so that the following ELEMENT_ZOB (AOB_ELEMENT) is indicated as the data to be processed, and the initialization of the variable x (# x) is performed as follows: (# y ← # y + 1, # x-1).

After that, in step 333, the playback device calls the TPFGPVR (TKTMSRT) and calculates the first address of GOAL ITEM # AOB_ELEMENT # y.

Then, the playback device performs a procedure consisting of operations S34 to S42. In this procedure, one after the other, GOALS OF GOITER (AOB_FRAMEs) contained in the element GOITER (AOB_ELEMENT) is read, that is, it is similar to the procedure consisting of operations S24 to S31. The difference between the procedure consisting of operations from S24 to S31 is that the final state of the procedure consisting of operations from S24 to S31 is the achievement of the variable x (#x) of the value indicated by "KOLK_1go_ETPPVR" (FNs_lst_TMSRTE), and the final state The procedure, consisting of operations S34 to S42, is to achieve the variable x (# x) of the value indicated by "FN_Middle_TMSRTE".

When the variable x (# x) reaches the value indicated by “FNs_Middle_TMSRTE”, the cycle procedure consisting of operations S34 to S42 is completed, when the operation S41 is made, the decision is “Yes” and the processing proceeds to operation S43. In step S43, the CPU 10 increments the variable y (# y) and initializes the variable x (# x): (# y ← # y + 1, # x ← 1). After that, in step S44, the variable y is analyzed and a decision is made whether the variable y (# y) has reached a value less by one than the Total_MS_TIPVR_Telements (TotalTMSRT_entry_Number) in the TTPVR_Header (TMSRT_HEADER) in the IDF No.z (TKI # z).

If the variable y (#y) is less than (Total_Number_TR_AT_elements_ - 1) (TotalTMSRT_entry_Number - 1), then GOITER ITEM # 1 (AOB_ELEMENT # y) is not the last GOITER ITEM (AOB_ELEMENT), so during processing they return from operation S44 to operation and carry out the cycle procedure from operation S32 to operation S42. When the variable y (#y) reaches the value (Total_Number_ of_TIPVR_elements - 1) (TotalTMSRT_entry_Number - 1), it can be assumed that the reading procedure has reached the penultimate AOB_ELEMENT ELEMENT, therefore, when performing operation S44, the decision is “Yes” and proceeds further to perform operation S45 of FIG.

{52-9_57-2}

The similarity of the procedure consisting of operations S45 to S54 with the procedure consisting of operations S33 to S42 is that it reads each of the GOITER_FIELDS (AOB_FRAMEs) in the final GOITER_OBIT (AOB_ELEMENT).

The difference from the procedure consisting of operations S33 to S42 is that the cycle procedure consisting of operations S33 to S42 is completed when, when performing operation S41, it was decided that the variable x (# x) reached the value specified in "FNs_Middle_TMSRTE" (FNs_Middle_TMSRTE), and the cycle procedure consisting of operations S45 to S54 is terminated when, when performing operation S53, it was decided that the variable x (# x) reached the value specified in "FIR__POST_ETPVR" (FNs_Last_ TMSRTE), with the variable "playable data" (play_data) decrees flushes that the read volume before the present point in time has reached the value of data that is set as "OB_DANNYH" (SZ_DATA).

The procedure consisting of operation S49 to S54 is repeated until the conditions from operation S53 are satisfied, at which point in step S53 a decision is made “Yes” and processing proceeds to operation S55. In the process, before returning to operation S21, in which the CPU 10 waits for the accumulation of the next GOK file (AOW file) in the double buffer 15, perform operation S55, in which the CPU 10 increments the variable z (#z): ( # z ← # z + 1). After that, during processing, proceed to step S22 and repeat the procedure consisting of operations S22 to S54. This means that the IDF (TKI) specified by NIDF_SVFU (DPL_TKIN) of the next UP_FG_SVFU (DPL TK 3RP) and the corresponding IDF (TKI) GOITER (AOW file) are defined, that is, that GOITER (AOW file) is defined, which has the same number as the IDF (TKI).

After that, the playback device accesses the identification area and determines from the file keys (FileKey) located in the encryption key storage file that File Key (FileKey), which has the same number as the IDF (TKI), and then reads of this Key File (FileKey) and setting its value in the decoder 7 random sequences. As a result of this, sequential reading and reproduction of CARTRONS (AOB_FRAMEs) contained in the file GOITER (AOW file), which has the same number as the IDF (TKI).

{52-9 57-3 59} Updating the play time code

On Figa-59G shows how to increase the code of the playback time, which is displayed in the display window of the code of the playback time on the LCD panel 5, in accordance with the update of the variable "Playback" (Play_time). In Fig. 59A, the value of the reproduction time code is “00: 00; 00,000”, however, upon completion of the reproduction of KADRA_ZOB # 1 (AOB_FRAME # 1), a value of the reproduction time KADRA_ZOB # 1 (AOB_FRAME # 1) of 20 ms is added to the playback time code updating it to the value "00: 00: 00,020", as shown in Fig.59B. Upon completion of the playback, KADRA_ZOB No. 2 (AOB_FRAME # 2), the playback time KADRA_ZOB No. 2 (AOB_FRAME # 2) equal to 20 ms is added to the playback time code, updating it to the value “00: 00: 00,040”, as shown in Fig. 59B. Similarly, upon completion of playback KADRA_ZOB No. 6 (AOB_FRAME # 6), a playback duration value of KADRA_ZOB No. 6 (AOB_FRAME # 6), equal to 20 ms, is updated to the value “00: 00: 00,120”, as shown on Fig.

This concludes the description of the output procedure KADRA_ZOB (AOB_FRAME).

If, when performing operation S31 shown in the flowchart of FIG. 56, the user presses a key other than the “Play” key, then the processing in this flowchart ends. The processing that is performed when the "Stop" or "Pause" key is pressed has already been described previously, however, in the case when the user presses one of those keys that are provided for the device to play a special a playback mode, processing in this flowchart or in the flowcharts shown in Fig. 56, Fig. 57. or Fig. 58 is stopped and proper processing is performed in accordance with the pressed key.

The following is a description of the procedure performed by the CPU 10 (1) when the search function is performed in the forward direction in response to the user pressing the ">>" key and (2) when the time search function is performed in response to the user activating the rotary dial with step switching after pressing the "Pause" or "Stop" key.

{52-10_60} Forward Search Function

Fig. 60 is a flowchart showing a procedure performed by the CPU 10 when performing the forward search function. In the case when the user presses the ">>" key, when performing operation S31, operation S42 or operation S54 from the flowcharts shown in Fig. 56, Fig. 57 and Fig. 58. decide "Yes" and the CPU 10 performs processing according to the flowchart of Fig. 60.

In step S61, the GOITER frames (AOB_frames) from No. x to No. (x + f (t) -1) (# x ÷ # (x + f (t) -1)) are input into the decoder 7 random sequences. Here, “t” is the duration of the discontinuous playback, f (t) is (displays) the number (number) of frames corresponding to the duration of the discontinuous playback, and d (t) is the amount of data corresponding to the duration of the discontinuous playback. In step S62, a corresponding update is made to the variable "Play_time" (Play_time), indicating the time elapsed since the start of playback, and the variable "play_data" (play_data), indicating the amount of reproduced data, using the duration "t" of intermittent playback, the number f (t ) frames corresponding to the duration of discontinuous playback, and the volume d (t) of data corresponding to the duration of discontinuous playback; (x ← x + f (t), play_time ← _play time + t, playable data ← playable data + d (t)) (x ← x + f (t), play_time ← play_time + t, play_data ← play_data + d (t) ) It should be noted that the duration of intermittent playback is usually 240 ms (which is equivalent to the playback duration of twelve AOB_FRAMEs).

{52-10_60-1_61A, B}

On Figa and 61B shows the procedure for incrementing the code of the playback time during the search operation in the forward direction. On Figa shows the initial value of the code of the playback time, while the playback point is FRAME_CHAWER No. 1 (AOB_FRAME # 1) IN ITEM_CHAIT No. 51 (AOB_ELEMENT # 51).

In this case, the playback time code is “00: 00: 01,000”. When the first to twelfth frames are entered into the decoder 7 random sequences as the duration of the discontinuous playback, the playback time of the twelve frames of the goiter (AOB_Frames) (i.e., 240 ms) is added to the code of the playback time, and the playback time code becomes equal to " 00: 00: 01,240 ", as shown in Fig.61B.

{52-10_60-2}

After this update, in step S63, the CPU 10 compares the value of the variable x (# x) obtained after the increment with the total number of frames in the GOIT_ELEMENT element # AOB_ELEMENT # y and analyzes whether the value of the variable x (# x) does not exceed the value obtained after the increment, the total number of frames in CART ITEM #u (AOB_ELEMENT # y).

As indicated above, the number of frames in the GOITER (AOB_ELEMENT) located at the beginning of the GOITER (AOB) is "FIR__st_TMSRTE" (FNs_lst_TMSRTE), the number of frames in the GOITER (AOB_ELEMENT) located in the middle of the GOITER (AOB_ELEMENT) is equal to the GOITER (AOB_ELEMENT) equal to FNs_Middle_TMSRTE), and the number of frames in the GOITER (AOB_ELEMENT), which is located at the end of the GOITER (AOB), is equal to "FIR_SET_ETPPVR" (FNs_Last_TMSRTE).

The CPU 10 takes the above decision by comparing the corresponding one of these values with the variable x (# x). When the value of the variable "x" goes beyond the given CLEANING ELEMENT (AOB_ELEMENT # y), then in step S64, the CPU 10 analyzes whether there is any ELEMEHT_CRAFT (AOB_ELEMENT) coming after the CLEARING ELEMENT # AOB_ELEMENT # y )

In the case when GOITER # ELEMENT (AOB_ELEMENT # y) is the last GOITER (AOB_ELEMENT) in the GOITER (AOB_BLOCK), there is no GOITER ELEMENT (AOB_ELEMENT) located after GOITER # ELEMENT # SOB (SOB_ELEMENT), when they accept (AOB_64), the decision is "No", and the processing in the present flowchart is completed.

Otherwise, if GOITER ELEMENT (AOB_ELEMENT), next to GOITER ELEMENT # (AOB_ELEMENT # y) exists, then, in step S65, the value of the variable "x" (# x) is reduced by the number of GOITER_FRAMEs (AOB_FRAMEs) in GOITER_ELEMENT No. ( AOB_ELEMENT # y), and during operation S66, the variable y (#y) is updated: (y ← y + 1) (# y ← # y + 1). As a result, the variable “x” (# x) now indicates the position of the frame for the frame in the next GOITER # AOB_ELEMENT # y indicated by the updated variable “y” (# y). And vice versa, in the case when the variable "x" (# x) indicates the CARTRIDGE (AOB_FRAME), which is present in the current ELEMENT_ GOITER (AOB_ELEMENT) (that is, when the decision "Yes" was made in operation S63), operations S64-S66 skip and proceed to processing operation S67.

{52-10_60-3}

After that, the variables "x" (# x), "Play time" (Play_time) and "Playable data" (play_data) are updated in accordance with the duration of the skip during intermittent playback. Skip_time (skip_time), which is equivalent to skip during intermittent playback, is two seconds; the number of frames equivalent to this skip time (skip_time) is specified as f (skip time) (f (skip_time)), and the amount of frames equivalent to this skip time (skip_time) is specified as d (skip time) (d (skip_time)). In step S67, these values are used to update the variables “x” (# x), “Play_time” (Play_time), and “playable_data” (play_data): (x ← x + f (skip_time), Playback_time ← Playback_time + skip_time, and playable data ← playable data + d (skip_time))

(# x ← # x + f (skip_time), play_time ← play_time + skip_time, play_data ← play_data + d (skip_time)).

{52-10_60-4_61B}

As shown in FIG. 61B, to the value of the variable “x” (# x), which indicates the position of the frame inside the GOITER # 51 (AOB_ELEMENT # 51), the skip duration during interrupted playback is added. When the value of the updated variable "x" (# x) exceeds the number of frames in GOITER # 51 (AOB_ELEMENT # 51), then the variable "y" (# y) is updated so that it indicates the next GOIT_ELEMENT (AOB_ELEMENT), and from the variable "x" (# x) subtract the number of frames contained in GOITER_ Element No. 51 (AOB_ELEMENT # 51). As a result, the variable "x" (# x) will now indicate the position of the frame inside the GOITER # 52 (AOB_ELEMENT # 52), which is indicated by the updated variable "y" (# y), then to the current value "00: 00: 01,240" the code of the playback time add the value of 2,000 (= 2 seconds), while its value becomes equal to "00: 00: 03,240". The variable "x" (# x) is updated by the following calculations: (3240 ms - 2000 ms) / 20 ms, as a result of which the value "62" is obtained, and, therefore, it indicates KOBR_ZOB No. 62 (AOB_FRAME # 62) in the ZOB_ELEMENT No. 52 (AOB_ELEMENT # 52).

{52-10_60-5_61 (D)}

After entering GOALFRAME # 62 (AOB_FRAME # 62) from GOITER_COUNT # 52 (AOB_ELEMENT # 52) into the decoder 7 random sequences update the playback time code by adding the value “0.240” to the current value “00: 00: 03,240”, as a result, get the value "00: 00: 03,480", as shown in Fig.

In operation S67, the variables are updated in accordance with the skip time during intermittent playback, and then the processing operations S68 through S71 are performed. When performing these operations S68 to S71, the same processing is performed as when performing processing operations S63 to S66; thus, before checking whether the variable “x” (# x) still indicates AOB_FRAME within the current GOIT_ELEMENT # A (AOB_ELEMENT # y), the variable “x” (# x) is updated for the number of frames which is equivalent to skip time during intermittent playback, skip time (skip_time). If such a check yields a negative result, then the variable "U" (#y) is updated so that the GOAL ELEMENT (AOB_ELEMENT) is set as the GOITER ELEMENT (AOB_ELEMENT # y), and the variable "x" (# x) is converted so that it indicates the position of the frame in this next AOB_ELEMENT ELEMENT.

After updating the variables "x" and "y" (# x, # y) in accordance with the discontinuous playback time and skip time during intermittent playback, in step S72, the CPU 10 accesses the TKTMSRT and calculates the start address for GOITTEN ITEM No. (AOB_ELEMENT # y). Then, in step S73, in order to detect GOAL_CHANGE No.x (AOB_FRAME # x), the CPU 10 starts searching for the ADTS header starting from the start address of GOAL_CHANGE No. (AOB_ELEMENT # y). In step S74, the CPU 10 decides whether the user has pressed a key other than the forward search key. If not, then 7 random sequences are entered into the decoder 7 GOALS (AOB_FRAMEs) with FRAME_CHAIN No.x (AOB_FRAME # x) by FRAME_CHAW No. (x + f (t) -1) (AOB_FRAME # x + f (t) -1), and the processing is repeated, performing operations S62 to S73.

Using the above procedure, an increment of the variables “x” and “y” (# x, # y) is performed, which indicate KOBR_KIT No.x (AOB_FRAME # x) and ELEMENT_KIT No. (AOB_ELEMENT # y), and thus the playback position is moved forward. If after that the user presses the "Play" button, then, as shown in Fig. 74, the decision is "No" and the processing is completed according to the present flowchart.

{52-11} Implementation of the time search function

The following is a description of the processing when using the time search function. First, the phonograms are displayed on the screen from Information_of_list_of reproducible_files_of_default (Default_Playlist_Information), and the user indicates the desired phonogram. After this phonogram is indicated and the user has activated the rotary disk with step switching, the update of the playback time code is performed. If after that the user presses the “Play” key, the play time code at this point is used to set the value of the “Jumper_Entry” (Jmp_Entry) variable, expressed in seconds.

Then a decision is made whether the indicated phonogram consists of a plurality of GOITERS (AOW) or from one GOITER (AOW). If the phonogram consists of one GOITER (AOW), then the calculation of the variables "y" and "x" (# y, # x) is performed in such a way that they satisfy Equation 2. After that, they search for FRAME_ZOB No.x (AOB_FRAME # x), starting from the address in the (y + 2) -th position TPFGPVR (TKTMSRT) corresponding to this GOITER (AOW). After this KADR_ZOB Nox (AOB_FRAME # x) is detected, playback starts with KADRA_ZOB Nox (AOB_FRAM # x).

{52-12}

In the event that the phonogram consists of a set of GOITERS (AOW), then the calculation of the variables "n" (indicating GOITER (AOW)), "y" and "x" (# n, # y, # x) is performed so that they satisfied Equation 3. After that, they search for KADRA_ZOB No.x (AOB_FRAME # x), starting from the address in the (y + 2) -th position of TPFGPVR (TKTMSRT) corresponding to GOITER No.n (AOB # n). After this KADR_ZOB Nox (AOB_FRAME # x) is detected, playback begins with KADRA_ZOB Nox (AOB_FRAME # x).

Below is a description of the case when playback starts from an arbitrary position on GOITER (AOW), for which "FIR__st_TMSRTE" in TIB (BIT) has a value of "80 frames", "FIR__Meddle_ETPVR" (FNs_Middle_TMSRTE) has a value of T "94 frames", and "KOLK_Last_ETPPVR" (FNs_Last_TMSRTE) in TIB (BIT) has the value "50 frames".

{52-13_62A, B}

The following is a description of one specific example of the use of the time search function, which shows how the position of the GOITER (AOB_ELEMENT) and the frame from which playback should start are determined when the playback time code is indicated by a rotary dial with step switching.

As shown in FIG. 62A, the user holds the reproducing device in his / her hand and rotates the rotary dial with step switching with the thumb of his / her right hand and indicates the reproduction time code equal to “00: 04: 40,000 (= 280 seconds)”. In the case when the TIB (BIT) in the IDF (TKI) for this GOITER (AOW) has the form shown in Fig.62B, then Equation 2 is used as follows:

280 seconds = (KOLK_1go_ETPPVR + (KOLK_Medium_ETPPVR * y) + x) * 20 ms = (80+ (94 * 148) +8) * 20 ms (280 sec = (FNs_lst_TMSRTE + (FNs_Middle_TMSRTE * y) + x) * 20 m (80+ (94 * 148) +8) * 20 msec) this way. Equation 2 is satisfied with the following values: y = 148 and x = 8.

Since y = 148, the element address obtained from TPFGPVR (TKTMSRT) corresponds to GOITTER_CLEAN # 150 (AOB_ELEMENT # 150) (= 148 + 2). In this case, playback from the place indicated by the time code 00: 04: 40,000 (= 280.00 seconds) can be performed by playing back from the eighth FRAME (AOB_FRAME) counted from the address of this element.

{52-14_63_64_65}

This completes the explanation of the processing performed by the CPU 10 in response to the user pressing the “Play” key. The following is a description of the editing control program stored in the ROM 4. This editing control program is executed when the user presses the “Edit” key, and it contains the procedures shown in FIG. 63, FIG. 64, and FIG. 65. The following is a description of the processing in this program in accordance with the sequence diagrams shown in these drawings.

{52-14_63-1} Editing control program

In the case when the user presses the "Edit" key, the operation S101 of Fig. 63 is performed, in which a dialog box is displayed on the screen, asking the user which of the three main editing operations is: "delete", " separation "and" association "should be performed. In operation S102, the CPU 10 decides what action the user took in response to displaying a dialog box on the screen. In this example, it is believed that the "| <<" and ">> |" keys on the keypad are also used to indicate the Up and Down cursor operations (that is, these keys are used as the Up arrow cursor keys) "and" Down "). In the case where the user indicates the operation "delete", during processing, they proceed to the execution of a cyclic procedure consisting of operations S103 and S104.

In operation S103, the CPU 10 decides whether the user has pressed the "| <<" or ">> |" key. In step S104, the CPU 10 decides whether the user has pressed the “Edit” key. In that case, if the user presses the key "| <<" or ">> |", then during processing, a transition is made from operation S103 to operation S105, in which the specified phonogram is determined as a phonogram intended for editing. But if the user pressed the "Edit" key, then the specified phonogram is defined as a phonogram intended for deletion. Shown in Fig. 44, the processing process is performed in this way. that if you delete the specified phonogram, the value ATR_BLK_IDF (TKI_BLK_ATR) of each IDF (TKI) of the specified phonogram is set to "Unused".

{52-14_63-2} The process of combining

In the case where the user selects the combining process, the processing proceeds from operation S102 to a cyclic procedure consisting of operations S107 to 3109. In a cyclic procedure consisting of operations S107 to S109, the playback device receives information entered by the user by means of the keys " | << "or" >> | " and “Edit”. When the user presses the "| <<" or ">> |" key, during processing they switch from operation S107 to operation S110, in which the indicated phonogram is highlighted on the display screen. In case the user presses the “Edit” key, then in step S108 a decision is made “Yes”, and in the processing procedure, they proceed to step S111. In step S111, the currently selected phonogram is set as the first phonogram used in this editing process, and the processing returns to a cyclic procedure consisting of operations S107 to S109.

In the case when the second phonogram is selected for editing, when performing operation S108, the decision is “Yes”, and in the processing, they proceed to operation S112. In operation S112, the CPU 110 makes a call to the TIB (BIT) in the IDF (TKI) of the first and second phonograms and makes a decision about which GOITERS (AOW) (of the 1st type or 2nd type) are located, respectively, at the beginning and at the end of each of these phonograms and phonograms located on both sides of these phonograms, if any.

After recognizing the type of each corresponding GOITER (AOW) in step S113, the CPU 10 decides whether the location of the GOITER (AOW) matches a specific pattern. In the case when the location of the GOITER (AOW) corresponds to one of the four patterns shown in the drawings of FIG. 32A to FIG. 32G, from which it is clear that after combining three consecutive placement of three GOITERS (AOW) of the 2nd type will not occur, the first and the second phonogram is combined into a single phonogram in step S115.

In other words, the operation shown in Fig. 46 is performed for IDF (TKI) and UP_FG_SVFU (DPL_TK_SRP), which correspond to these GOITERS (AOW). The combination of multiple phonograms selected for editing into a single phonogram is carried out by overwriting ATR_BLK_IDF (TKI_BLK_ATRs) in IDF (TKI). In the event that the location of the GOITER (AOW) does not match any of the patterns shown in the drawings of FIG. 32A to FIG. 32G, which means that after combining there will be three or more GOITERS (AOW) of the 2nd type, then the CPU 10 decides that the combined phonogram may cause a buffer underrun, and thus the combining process is terminated.

{52-14_64-1} The process of splitting a phonogram

When the user indicates that the phonogram should be split, during processing, they move from operation S102 to a cyclic procedure consisting of operations S116 to S117. In a cyclic procedure consisting of operations S116 through S117, the reproducing apparatus obtains information entered by the user by means of the keys “| <<” or “>> |” and “Edit”.

In the case when the user presses the "| <<" or ">> |" key, during processing they switch from operation S116 to operation S118, in which the selected phonogram is set as intended for editing. If the user presses the “Edit” key, then during operation S117 a decision is made “Yes”, and in the processing procedure, they proceed to operation S119.

In step S119, the marked phonogram is determined as a phonogram intended for editing, and in the processing procedure, they proceed to step S120, at which the playback of this phonogram begins. In step S121, the reproducing apparatus receives information entered by the user by means of the “Mark” key.

When the user presses the “Mark” key, the phonogram playback is stopped and during processing they proceed to the execution of the cyclic procedure consisting of operations S122 and S123. In step S122, the reproducing apparatus obtains data on user actions performed by the rotary dial with step switching. When the user rotates the rotary disk with step switching, then in step S124, the play time code is updated in accordance with the angle of rotation of the rotary disk with step switching.

After that, the cyclic procedure consisting of operations S122 and S123 is repeated. If the user presses the “Edit” key, then in the processing procedure, they switch from operation S123 to operation S125, in which the playback time code that was displayed when the user presses the “Edit” key is set as the separation boundary ("Edit"). It should be noted that for such a method of setting the separation boundary, the “Undo” function may be provided, allowing the user to cancel the selected separation boundary.

After that, in operation S126, processing is carried out, the explanation of which is given by referring to FIG. 47, in which the ISVFU (DPLI) and IDF (TKI) are updated, and the selected phonogram is separated.

{52-14_65-1} The process of compiling a list of playable files

In that case, when the user selects the option of compiling a list of playable files, during processing, they proceed to the procedure shown in the flowchart of FIG. 65. The variable "k" defined in this flowchart is used in this flowchart to indicate the position of the phonogram in the playback order that is specified by an editable list of playable files. The sequence of operations shown in the diagram of Fig. 65 begins with the fact that before proceeding to the cyclic procedure consisting of the operation S132 to S134 during processing, perform operation S131, in which the initial value of this variable k is set equal to " 1".

In a cyclic procedure consisting of operations S132 through S134, the playback device receives data on user actions performed by means of the keys “| <<”, “>> 1”, “Edit” and “Stop” (“Stop” "). In the case when the user presses the key "| <<" or ">> |", during processing, they switch from operation S132 to operation S135, in which, in accordance with pressing the key "| <<" or ">> |" indicate a new phonogram. If the user has pressed the “Edit” key, then at operation S133 a decision is made “Yes” and in the course of processing they proceed to operation S136.

In step S136, the phonogram indicated at the time the user presses the “Edit” key is selected as the kth phonogram in the playback order. After that, in step S137, the variable k is incremented and the processing returns to a cyclic procedure consisting of operations S132 through S134. This procedure is repeated in such a way as to make a sequential selection of the second, third and fourth phonograms. If after the task of several phonograms intended for reproduction in the indicated order by means of a new list of playable files has been made, the user presses the “Stop” key, then during processing they proceed from operation S134 to operation S138, in which generation of ISVF (PLI), consisting of UP_FG_SVF (PL_TK_SRPs), in which the IDFs (TKI) corresponding to these phonograms are indicated.

{66-1} Recorder

The following is a description of one example of a recording device for a flash card 31. On Fig shows one of the example examples of a recording device. This recorder can be connected to the Internet and is a standard personal computer that can receive an encrypted directory of EDI (source audio data) (SD_Audio), which is transmitted to the recorder via communication channels by the electronic music distribution service or the audio transport stream data, the transfer of which to the recording device via communication channels is carried out by the electronic music distribution service.

{67-1} Hardware composition of the recorder FIG. 67 illustrates the hardware composition of the recorder.

As shown in Fig. 67, the recording device includes a board connector 21 for connecting the recording device to the flash memory card 31, RAM random access memory 22, a non-removable disk device 23 for storing a recording management program that centrally controls the recording device , analog-to-digital Converter 24, designed to implement analog-to-digital conversion entered through a microphone of audio data, which ensures the creation of PCM data (with pulse code modulation), an ultrasound encoder 25 (advanced audio information coding - (AAS)) encoding PCM data in units of constant time duration and assigning ADTS headers to create AOB_FRAMEs, 26 encryption device designed to encryption of GOITER frames (AOB_frames) using different File Keys for each AOB_BLOCK BLOCK, modem 27 for receiving the transport of audio data stream when the music distribution service electronically transferring to the recording device via communication lines an encrypted directory of EDI (original audio data) (SD Audio), or when the music distribution service electronically transferred audio data to the recording device through communication lines, the CPU 28 to perform centralized control a recording device, a keyboard 29 for receiving user input and a visual display device 30.

{67-2} Input Circuits RT1-RT4

In the case when the music distribution service electronically transmits to the recording device, via the communication lines, the encrypted directory of the EDI (source audio data) (SD_Audio), which must be recorded in the data area and in the identification area, then immediately after the proper reception of the encrypted directory of the EDI (SD_Audio) the recorder can write the encrypted IDD directory (SD_Audio) to the data area and to the identification area of the flash memory card 31.

However, in those cases (1) when a transport stream of audio data, the format of which does not correspond to the CDM directory (SD_Audio), is transmitted to the recording device electronically by the music distribution service, (2) when data in PCM format are entered into the recording device , or (3) when the analog audio data is recorded by the recording device, the following four input paths are used in the recording device to record the transport audio data stream to the flash memory card 31.

{67-3} Input path RT1

The input path RT1 is used when the music distribution service electronically transmits to the recording device via the communication lines the encrypted CDM directory (SD_Audio), or when the music distribution service electronically transfers sound data to the recording device through the communication lines. In this case, the GOITER (AOB_FRAMEs) contained in the transport stream are encrypted in such a way that for the GOITER frames (AOB_FRAMEs) of various GOITER (AOB), different File Keys (FileKeys) are used. Since encryption or encoding of the encrypted transport stream is not necessary, direct storage of the CDM directory (SD_Audio) or the transport of audio data stream in RAM 22 in an encrypted state can be performed.

{67-4} Input path RT2

The input path RT2 is used in the case when the input of audio data is carried out through a microphone. In this case, the analog-to-digital conversion of audio data inputted through the microphone is performed by means of the analog-to-digital converter 24, creating PCM (PCM) data. Then, in order to create GOITERS (AOB_FRAMEs), PCM data is encoded using an ultrasound encoder (AAS) 25 and ADTS headers are assigned. After that, the encryption device 26 encrypts the GOITER (AOB_FRAMEs) using different file keys (FileKey) for each of the GOITER (AOB_FRAMEs) in the different GOITER_FILE (AOB_FILEs), as a result of which encrypted audio data is generated. After that, the encrypted audio data is stored in RAM 22.

{67-5} Input path RT3

The RT3 input path is used when PCM data read from a compact disc (CD) is input into the recorder. Since the data are entered in PCM (PCM) format, the data can be directly entered into the coding device 25 UKZI (AAS). To create GOALS (AOB_FRAMEs), the PCM is encoded with this data by means of an ultrasound encoder 25 (AAC) and the assignment of ADTS headers.

After that, the encryption device 26 encrypts the GOITER frames (AOB_FRAMEs) using various file keys (FileKey) for the GOITER FRAMES (AOB_FRAMEs) in the various GOITER_FILES (AOB_FILEs), thereby creating encrypted audio data. After that, the encrypted audio data is stored in RAM 22.

{67-6} Input path RT4

The input path RT4 is used when the transport stream entered into the recording device through one of the three input paths RT1, RT2, and RT3 is recorded on the flash memory card 31.

Such storing of audio data is accompanied by the creation of an IDF (TKI) and Information_of_list of reproducible_files_of_default (Default_Playlist_Information). As well as for the playback device, in the ROM, the main functions that ensure the operability of the recording device are stored. That is, in a non-removable disk device 23, a recording program is stored that contains a processing procedure characteristic of the recording device, namely, recording the GOITER (AOW), the phonogram manager (TrackManager) and the administrator of the playlist (PlaylistManager).

{67-7_68} Processing performed on the recorder

The processing description in the recording procedure, in which the transport stream received through the input paths RT1, RT2, RT3 and RT4 is carried out in the flash memory card 31, is given below with reference to the flowchart of FIG. 68, which shows this processing.

The following variables are used in this flowchart: FrameNumber (Frame_Number) and Data_Size. The Frame_Number variable is used to control the total number of those AOB_FRAMEs that have already been recorded in AOB_FILE. The Data_Size variable is used to control the amount of data of those CRAFTS (AOB_frames) that have already been written to the Crawl FILE (AOB_FILE).

Processing in this flowchart begins with operation S200, in which the CPU 28 generates a default playlist (DefaultPlaylist) and a phonogram manager (TrackManager). In step S201, the CPU 28 initializes the variable "z" (#z): (z ← 1). In step S202, the CPU 28 generates a GOITTER # ZF file (AOB_FILE # z) and stores it in the data area of the flash memory card 31. At this moment, in the catalog element from the Catalog of the Publishing House (SD_Audio) located in the data area, specify the file name, file name extension and the number of the first cluster for ZOB FILE #z (AOB_FILE # z). After that, during operation S203, the CPU 28 generates an IDF No. z (TKI # z) and stores them in the phonogram manager (TrackManager). In step S204, the CPU 28 generates UP_FG_SVFU #w (DPL_TK_SRP # w) and stores it in the Default_laylist_Information_playlist_file_information (Default_Playlist_Information). After that, during operation S205, the CPU 28 initializes the variable "y" (# y): (# y ← 1), and during operation S206, the CPU 28 initializes the Frame_Number and Data_Size: (Frame_Number ← 0 , Data_Volume ← 0).

In step S207, the CPU 28 decides whether the input of the transport stream of audio data intended for recording in FILE_ZOB No. ... (AOB_FILE #) is completed. In the case when the input of the transport stream of audio data encoded by means of an ultrasonic encoding device (AAS) 25 and encrypted by means of the encryption device 26 in the RAM 22 is not completed and it is necessary to continue recording the cluster data, then, in step S207, the CPU 28 makes a decision "No ", and in the processing routine proceed to step S209.

In step S209, the CPU decides whether the amount of audio data of the ultrasound scan (AAS) that is stored in the RAM 22 is at least equal to the size of the cluster. If this is true, then the CPU 28 makes the decision “Yes” and in the processing procedure proceeds to operation S210, in which the amount of sound data of the ultrasound scan (AAS) equal to the cluster size is recorded on the flash memory card 31. Then, the processing procedure proceeds to step S211.

In the case when in RAM 22 a sufficient amount of sound data of an ultrasound scan (AAS) is not accumulated, operation S210 is skipped and in the processing procedure proceed to operation S211. In step S211, the CPU increments the Frame_Number (Frame_Number ← Frame_Number + 1) and increases the value of the Data_Size variable by the amount of the AOB_FRAME data.

After such an update, an operation S212 is performed in which the CPU 28 decides whether the value of the Frame_Number (Franie_Nuniber) variable has reached the number of frames set in "FN_Middle_TMSRTE", and the value of "F_C_Med_Enter_VAL" (FNTMS_ID is set to sampling rate used when encoding the transport stream of audio data. In the event that the Frame_Number value has reached the number of frames specified in FNs_Middle_TMSRTE, in step S212, the CPU 28 makes a Yes decision. If this is not the case, then the CPU 28 makes the decision “No,” and in the process of processing return to operation S207. Therefore, the processing procedure performed by operations S207 through S212 is repeated until a decision of “Yes” is made in either S207 or S212.

When the Frame Number variable reaches the value "FNs_Middle_TMSRTE", then in step S212, the CPU 28 makes a decision "Yes" and in the processing procedure proceeds from step S212 to step S213, in which the variable Data_Size is stored in TPFGPVR (TKTMSRT) IDF No. z (TKI # z) in the form of Element_TRPVR No. y (TMSRT_entry # y) for ELEMENT_ZOB No. (AOB_ELEMENT # y). Before performing operation S215, in which it is checked whether the variable "y" (# y) has reached the value "252", operation S214 is performed, in which the CPU 28 increments the variable "y" (# y): (# y ← # y + 1).

The value "252" is used because it represents the maximum number of GOITERS (AOB_ELEMENTs) that can be stored in one GOITER (AOB). If the variable "Y" (# y) has a value less than S52, then during processing they proceed to operation 3216, in which the CPU 28 decides whether there is a pause in the encoded audio data with a predetermined duration, that is, whether the sound data reached the gap between the phonograms. In the absence of such a long pause, a repetition of the processing consisting of operations S206 through S215 is performed. In the event that the variable "y" (# y) has reached the value 252, or there is a pause of a predetermined duration in the encoded audio data, then when performing one of operations S215 and S216, the decision is "Yes" and in the processing procedure proceed to operation S217 , at which the variable "z" (#z) is incremented: (# z ← # z + 1).

After that, the processing performed by operations S202 to S216 is repeated for the variable “z” (#z) increased by one. By repeating such processing, the CPU 28 can write sequentially to the flash card 31 of the GOITER (AOW) containing a plurality of GOITER elements (AOB_ELEMENTs).

When the transmission of the transport stream of audio data by means of an encoding device 25 UKZI (AAS), the encryption device 26 and modem 27 is completed, it means that the input of the transport stream of audio data intended for recording in FILE_ZOB No. z (AOB_FILE # z) is also completed therefore, in step S207, a decision is made “Yes” and in the processing procedure proceeds to step S208. When performing operation S208, the CPU 28 stores the value of the Data_Size variable in the TPFGPVR (TKTMSRT) IDF No. z (TKI # z) in the form of the TPPVR element No. (TMSRT_Entry # y) for the GOITER_NO element (AOB_ELEMENT # y). After storing the sound data accumulated in RAM 22 in a GOITER (AOB_file) file corresponding to GOITER No. z (AOB # z), processing in this flowchart is completed.

As a result of the above processing, the encrypted transport stream of audio data is stored in the flash memory card 31. Then, the procedure below is used, which ensures that the FileKey, which is necessary for decrypting this encrypted transport stream of audio data, is stored in the identification area.

After the input of the transport stream of audio data through the input path RT1 has been completed, the music distribution service provider electronically transfers the GOITER file (s) (AOW file (s)), the ADFG storage file (TKMG), the ASVF storage file ( PLMG) and an encryption key storage file in which various file keys (FileKey) are stored, one for each GOITER (AOB). The CPU 28 receives these files and writes the GOITER file (s) (AOW file (s)), the ADFG storage file (TKMG) and the ASVF storage file (PLMG) to the user area in the flash memory card 31. And in the identification area of the CPU 28, only the encryption key storage file is recorded, in which various file keys (FileKey) are stored, one for each GOITER (AOB).

In the event that the input of audio data is performed through the input path RT2 or RT3, then whenever encoding of a new GOITER (AOW) begins, the CPU 28 generates various file keys (FileKey) and sets the value obtained from the key generation in the device 26 encryption. In addition to the fact that this file key (FileKey) is used in the encryption device 26 to encrypt the current GOITER (AOB), it is stored in accordance with the File_Key Entry in the storage file of the encryption key, which is located in the identification area.

According to the embodiment of the present invention described above, the encryption of files in which GOITER is stored is performed using various encryption keys, therefore, if the encryption key used to encrypt one file is decrypted and declassified, then the declassified encryption key can be used to decrypt only the file in which one GOITER (AOW) is stored, and such a declassification of the key will not apply to other GOITERS (AOW) that are stored in other files. This minimizes the damage caused by declassifying one of the encryption keys.

It should be noted that, although the above description refers to that example of a system that is believed to be the most effective embodiment of the present invention, the invention is not limited to this system. Various modifications are possible within the scope of the patent claims of the invention, and the following are examples of such modifications from (a) to (e).

(a) In the above embodiment, a semiconductor memory (flash memory card) is described as the recording medium used, however, the present invention can be applied to other media, including optical disks, for example, DCD based RAM ( DVD-RAM), or for hard disk drives.

(b) In the above embodiment, the described audio data was in AAS format (Advanced Encoding of Audio Information - USI), however, the present invention can also be applied to audio data having a different format, for example, MP3 (MPEG1 Audio Layer 3), Dolby -ASZ or DTS (digital theater system).

(c) Despite the fact that the description indicated that the ADFG storage file (TKMG) and the ASVF storage file (PLMG) were received from the electronic music distribution service provider in a complete form, the transfer of the basic information used to create the ADFG (TKMG) and ASVF (PLMG) can be implemented together with the encryption key storage file, in which various encryption keys are stored, one for each GOITER (AOB). After that, the recorder can process this information to obtain ADPG (TKMG) and ASVF (PLMG), which it then writes to the flash memory card.

(d) For ease of explanation, the recording device and the playback device have been described as separate devices, however, the portable playback device can be equipped with the functions of a recording device, and the recording device in the form of a personal computer can be equipped with the functions of a playback device. In addition to a portable playback device and a personal computer-based recording device, a communication device capable of downloading information content from the network can also be equipped with the functions of the playback device and the recording device.

As one example, the functions of the playback device and the recording device described in the above embodiment may be provided with a mobile telephone having Internet access. As in the embodiment described above, this mobile telephone can store information content downloaded via a wireless communication network in a flash memory card 31. Also, despite the fact that the recorder described in the above embodiment is equipped with a modem 27 for connecting to the Internet, any other device capable of connecting to the Internet can be used instead, for example, an ISDN terminal adapter (digital network with integrated services - CSKU).

(e) Shown in the flowcharts shown in Figs. 55-58, Fig. 60, Figs. 63-65 and Fig. 68, the procedures can be performed by executable programs, the sale and sale of which can be carried out on a recorded medium recording form. This recording medium may be an integrated circuit board (1C card), an optical disk, a floppy disk or similar devices with programs recorded on a recording medium, the use being carried out after they are installed in standard computer equipment. By performing processing in accordance with such installed programs, standard computer hardware can perform the same functions as the playback device and the recording device described in the above embodiment.

(e) Although the embodiment described above describes an embodiment in which a plurality of GOITERS (AOW) and a plurality of file keys (FileKeys) are stored in a flash card 31, it is necessary to store only one GOITER (AOW) and one File Key (FileKey). Also, encryption of GOITER (AOW) is not a prerequisite, therefore, the storage of GOITER (AOW) in the flash memory board 31 can be carried out in AAS format (advanced sound information encoding - UKZI).

SECOND EMBODIMENT FOR CARRYING OUT THE INVENTION

In the first embodiment, only a brief reference is made to the various areas of memory in the flash memory card 31, and no description is given of the internal structure of the used hardware. However, in this second embodiment, a detailed description of the hardware of the flash memory card 31 is provided.

{69-1} The hardware device of the flash card 31

On Fig shows the hardware device of the card 31 flash memory. As shown in FIG. 69, the flash memory card 31 includes three integrated circuits (ICs), namely, a control IC 302, a flash memory 303, and a ROM (read only memory) 304.

The ROM 304 contains a special area described in the first embodiment and used to store the identifier (ID) of the medium mentioned in the first embodiment, and, in addition, the protected identifier (ID) 343 of the medium, which is created by encrypting the protected identifier (ID) carrier.

The control IC 302 is a control circuit consisting of active elements (logic elements), and includes an authorized access device 321, an instruction decoder 322, a master key storage device 323, a special area access control device 324, an area access control device 325 an identification device 326 for access control to an area that does not require identification and an encryption / decryption circuit 327.

The authorized access device 321 is a scheme that performs mutual authentication in the request-confirmation format with a device that is trying to access the flash memory card 31. This authorized access device 321 includes a random number generator, an encryptor, and the like. and verifies the authenticity of the devices a attempting to access the flash memory card 31, determining whether the device contains the same encryptor as the authorized access device 321.

In this case, mutual authentication in the request-confirmation format means that for authentication of the second device, the first device transmits the request data to the second device. The second device processes this request data in a predetermined manner, which proves its authenticity, and transmits the resulting data to the first device as response data. The first device compares the request data with the response data and decides whether to recognize the second device as genuine. Since this process is a mutual identification, the processing is then repeated, reversing the roles of the devices.

The decoder 322 commands is a controller that contains a decoding circuit, a control circuit, etc. that interpret and execute the command (command for the card 31 flash memory), the input of which is carried out through the contact COMMAND connector. The command decoder 322 controls the devices 321-327 in the control IC 302 in accordance with the type of command entered.

The commands that are provided to the flash memory card 31 include instructions for reading, writing, or deleting data in the flash memory 303. As examples of commands related to reading and writing data, the command “Number of elements in address” can be given. secure reading "(" SecureRead address count ") and" Number of elements in a secure record address "(" SecureWrite address count "), through which access to the authentication area, and through the commands" Number of elements in read address "(" Read address count ") and" The number of elements in the record address "( "Write address count") access an area that does not require identification. In these commands, the term “address” means the number of the first sector to be accessed in the read (or write) area, and the term “number of elements” means the total number of read (or write) sectors. In this case, the sector is a single element for reading and writing data in the flash memory card 31, which is 512 bytes in the present example.

In the master key storage device 323, the master key 323a is stored in an encrypted state in advance. The master key is the encryption key used to encrypt the media identifier (ID). When the flash memory card 31 is connected to the device, the master key 323a is transmitted to the device in encrypted form. The master key 323a is encrypted in such a way that it can be decrypted using only the device that receives the master key by using special key information (which is usually called a “device key”).

The special area access control device 324 is an electronic circuit that reads the identifier (ID) of a medium stored in the ROM 304 in which a special area is created. The media identifier (ID) read by the special area access control device 324 is then transmitted to a device connected to the flash memory card 31, which then encrypts the media identifier (ID) using the master key obtained by decrypting the encrypted master key using the key devices.

The identification area access control device 325 and the non-identification area access control device 326 are electronic circuits that read data and write data to the flash memory 303 for, respectively, the identification area and the area requiring no identification. This identification area access control device 325 and the non-identification area access control device 326 transfer data to and from an external device (for example, a recording device and a playback device described in the first embodiment).

It should be noted that each of these access control devices 325 and 326 contains an internal buffer that can store one data block, and input and output are performed through the connector pins, marked with

DATA1 to DATA4 (DATA1 - DATA4). From the point of view of logical operations, this input and output is carried out sector-by-sector, but when overwriting the contents of flash memory 303, data is input or output block by block (each block has a volume equal to 32 sectors (16 Kbytes)). In a more detailed description, in the case when the data is overwritten in one sector, the corresponding block is read from the flash memory 303 and stored in the buffer of the corresponding access control device, this block is deleted from the flash memory, the corresponding sector is rewritten in the buffer memory and then the block from the buffer memory is written back to the flash memory 303.

The encryption / decryption circuit 327 performs encryption or decryption using the master key 323a stored in the master key storage device 323, which is controlled by the authentication area access control device 325 or the area-free access control device 326. In the case where it is necessary to write data to the flash memory 303, the encryption / decryption circuit 327 encrypts the data and writes it to the flash memory 303. Otherwise, when it is necessary to read the data from the flash memory 303, the encryption circuit 327 / decryption performs data decryption. This encryption / decryption scheme 327 is needed to prevent users from performing unauthorized actions, for example, disassembling the flash memory card 31 and directly analyzing the contents of the flash memory 303 to obtain passwords stored in the identification area.

{69_70} The sequence of information exchange during the reproduction of GOITERS (AOW)

On Fig shows the sequence of information exchange, performed when reading by the playback device connected to the card 31 of the flash memory, the encryption key, the File Key (FileKey) and playing GOITER (AOW).

The playback device sends a command to the flash memory card 31 to read the master key (sc1). After issuing this command, the command decoder 322 receives the encrypted master key 3236 stored in the master key storage device 323 and transmits it to the playback device (sc2).

The playback device that receives the secure identifier (ID) of the medium uses the key 211a of the device that is stored in it (sc3) to decrypt the secure identifier (ID) of the medium. The decryption algorithm used in the decryption process corresponds to the encryption algorithm that was used to generate the encrypted master key 323b stored in the flash memory card 31, therefore, if the device key 211a used by the playback device is the key to be used (i.e., the correct key) , then by performing such a decryption, the playback device can safely obtain the master key.

After receiving the master key, the playback device issues a special command to the flash memory card 31 to read out the medium identifier (ID) (sc4). The special area access control device 324 obtains a medium identifier (ID) from the ROM 304 of the flash memory card 31 and transmits it to the playback device (sc5). Then, the encryption / decryption circuit 327 encrypts the medium identifier (ID) using the master key obtained by the above decryption process (sc6). For this encryption, the same algorithm is used as the algorithm that was used to generate the secure identifier 343 (ID) of the medium stored in the flash memory card 31. The resulting secure media identifier (ID) is exactly the same as the secure media identifier 343 (ID) from the flash memory card 31.

Then, the playback device, which managed to obtain a secure identifier (ID) of the medium, performs the mutual authentication operation with the authorized access device 321 from the flash memory card 31 (sc7). This process leads to the fact that both the playback device and the authorized access device 321 contain (a) information (YES / NO) (OK / NG), which indicates whether another device was successfully authenticated, and (b) changing over time, a secure key whose contents depend on the authentication result.

In case of a successful mutual authentication result, the playback device generates an access command to the identification area of the flash memory card 31. As one example, one can cite the case in which, when reading data from the identification area, the playback device encrypts the parameters (that is, an “address” representing an address consisting of 24 bits and a “number of elements” whose data length is equal to eight bits) of the command "Secure-Read address count" using a secure key (sc8), and associates these parameters with a sign of this command (that is, a 6-bit code indicating that this team is a protected team read "(" SecureRead ")), creating an encrypted command (sc9), which the playback device transmits to the card 31 flash memory (sc10).

After receiving this encrypted command, the flash memory card 31 recognizes the type of command by the sign (sc11). In the present example, the flash memory card 31 determines that this command is a “Secure-Read” command for reading from the identification area.

After the read command is recognized, the encryption / decryption circuit 327 decrypts the parameters contained in the command using the secure key (sc12) obtained by mutual authentication (sc13).

The algorithm that was used to decrypt the parameters corresponds to the encryption algorithm that was used by the playback device when generating the encrypted command, therefore, if mutual authentication is successful, that is, when the secure key in the flash memory card 31 corresponds to the secure key in the playback device, the parameters obtained by such decryption will be those parameters that the playback device uses.

Upon receipt of a command containing valid parameters, the access control device 325 to the identification area accesses the sectors indicated by the reliable parameters and reads the encryption key of the File_key (FiieKey) stored in these sectors from the identification area. Encryption / decryption scheme 327 encrypts the encryption key File_Key stored in the file "AOBSA1.KEY" in the authentication area (sc15) using the secure key (sc14) obtained by mutual authentication. After that, the access to the identification area access control device 325 transmits the encryption key File_Key, stored in the file "AOBSA1.KEY" in the identification area, to the playback device (sc16).

The playback device decrypts (sc18) the encryption key File_Key (FileKey), which was received by it using the secure key (sc17) obtained by mutual authentication. Due to the fact that the decryption algorithm used here corresponds to the algorithm used by the flash memory card 31 to encrypt the encryption key FileKey, the original encryption key FileKey can be obtained. After that, the obtained encryption key is decrypted using the FileKey using the master key 323b and the media identifier (ID), and as a result, the FileKey encryption key is received (sc20).

After receiving the encryption key File_Key (FileKey) and from the area that does not require identification, read the GOITER (AOW) corresponding to this encryption key File_Key (File21) (sc21), decrypt the GOK (AOB) using this encryption key File_key ( FileKey) and simultaneously play music.

{69_70_71} Detailed sequence of information exchange during mutual authentication

On Fig shows a detailed sequence of exchange of information that is used in mutual authentication of Fig.70. In this example, the flash memory card 31 and the playback device perform mutual authentication in the request-confirmation format.

To authenticate the playback device, the authorized access device 321 from the flash memory card 31 generates a random number (sc30) and transmits this random number to the playback device as request data (sc50). In order to prove its own authenticity, the playback device encrypts the request data (sc31) and transfers the result to the authorized access device 321 in the flash memory card 31 as response data (sc32). The authorized access device 321 in the flash memory card 31 encrypts a random number transmitted by it as request data (sc33), and compares this encrypted random number with the response data (sc34).

In the case where the encrypted random number matches the response data, the playback device will be recognized as genuine ("YES"), and after that, the flash memory card 31 will accept the access commands to the identification area received from the playback device. Otherwise, when the encrypted random number and the response data do not match, the playback device will not be recognized as genuine, and after that, the flash memory card 31 will reject any access commands to the identification area received from the playback device.

The same authentication procedure is performed by the playback device to confirm the authenticity of the flash card 31.

In other words, the reproducing apparatus generates a random number (sc40) and transmits this random number to the authorized access device 321 in the flash memory card 31 as request data (sc51). In order to prove the authenticity of the flash memory card 31, the authorized access device 321 encrypts the request data (sc41) and transmits the result to the playback device as response data (sc42).

The playback device encrypts a random number transmitted by it as request data (sc43), and compares this encrypted random number with response data (sc44).

In the case where the encrypted random number and the response data are the same, the flash memory card 31 (“YES”) will be recognized as genuine, and then the playback device will try to access the identification area of the flash memory card 31. Otherwise, when the encrypted random number and the response data do not match, the flash memory card 31 will not be recognized as genuine (“NO”), and the reproducing apparatus will not attempt to access the identification area of the flash memory card 31.

In the event that the flash memory card 31 and the playback device are genuine, then in mutual authentication, both devices will use the same encryption algorithm. Both the flash memory card 31 and the reproducing apparatus perform an EXCLUSIVE OR logical operation on two encrypted random numbers (that is, on an encrypted random number transmitted to the other device as request data and on a random number that was encrypted in order to verify the received data response) used in mutual authentication processes (sc45, sc46), and the result of the EXCLUSIVE OR operation is set as a secure key, which is used when accessing the board identification area 31 flash memories. Thus, the same secure key in the flash memory card 31 and in the playback device will be installed only if mutual authentication is successful. Since in this way a shared key that is changed over time (that is, which is used only for this session) of a protected key can be implemented, the successful condition of mutual authentication is a necessary condition for access to the authentication area.

One alternative is one in which a secure key can be created by each device by performing an EXCLUSIVE OR logical operation on encrypted request data created by the same device, response data received from another device, and a protected media identifier (ID) .

In the above embodiments, there is data that is stored in the field of identification and for which copyright protection is required, and other data that is stored in a field that does not require identification. This allows you to implement a semiconductor memory board, in which you can simultaneously store both works of art in digital form, requiring copyright protection, and works of art in digital form, not subject to such restrictions.

Despite the fact that the description of the present invention was made entirely by way of examples with reference to the accompanying drawings, it should be noted that for specialists in the art it is obvious the possibility of various modifications and modifications. Therefore, in the event that such modifications and modifications are not beyond the scope of the patent claims of the present invention, they should be considered as falling under it.

INDUSTRIAL APPLICATION

The semiconductor memory board of the present invention is adapted for use mainly in the field of consumer electronics as a recording medium for recording music or other material that is distributed electronically or otherwise. The recording and reproducing devices of the present invention allow consumers to fully utilize the capabilities of such a semiconductor memory card.

Claims (20)

1. A semiconductor memory board storing at least one soundtrack containing a protected area that can be accessed by means of a device physically connected to the semiconductor memory board and having a means of reading the data stored in it, only if the authenticity is established this device, and in the protected area is stored a sequence of encryption keys, consisting of many encryption keys located in a predetermined order, and unprotected about a part that can be accessed by any device physically connected to the semiconductor memory board and having a means of reading the data stored in it, wherein at least one sound track and control information, at least one sound track, are stored in an unprotected area contains many encrypted audio objects, and the control information indicates which encryption key from the set of encryption keys corresponds to each audio object, in an unprotected area. 2. The semiconductor memory board according to claim 1, in which the control information indicates for each sound object the location of the sound object in the memory and a number indicating the position of the encryption key corresponding to the sound object in the sequence of encryption keys. 3. The semiconductor memory board according to claim 2, in which each soundtrack additionally contains (1) attribute information and (2) layout information for each sound object contained in the soundtrack, the attribute information indicating which type of the following types is - type (a), type (b), type (c) and type (d) - each sound object belongs, while type (a) represents the entire sound track, type (b) represents the first part of the sound track, type (c) represents the middle part of the sound track, and type (d) represents the final part of the sound phonograms, and layout information for each sound object belonging to type (b) or type (c) indicates which sound object follows this sound object. 4. The semiconductor memory board according to claim 3, in which the plurality of sound objects contains at least one sound object containing only reliable data intended for reproduction, and at least one sound object containing (1) reliable data and (2) false data located before and / or after reliable data, and false data is not required to be reproduced, with each sound track additionally containing information about blocks for each sound object from the sound phonograms, and this information about the blocks contains an offset measured relative to the location of the corresponding sound object in the memory, which is indicated in the control information, and information about the length, in which the length of the reliable data is indicated, which starts from the place indicated by the offset, and information about the attribute for the sound object indicates whether the valid data specified by the offset and information about the length (a) correspond to the entire sound track, (b) correspond dissolved first part sound soundtrack, (c) correspond to the middle part of an audio soundtrack, or (d) correspond to the end portion of the sound track. 5. The semiconductor memory board according to claim 4, in which the reproduction of sound phonograms can be carried out in accordance with the standard playback mode or with an intermittent playback mode, and the standard playback mode is a mode in which the reproduction of reliable data in sound objects constituting sound phonograms are carried out without any omissions of reliable data, and the intermittent playback mode is such a mode in which carry out (1) the passage of reliable data equivalent to the first period, and (2) the reproduction of reliable data equivalent to the second period, and each sound track additionally contains many pieces of information about the entry points that indicate the location of the internal location of the reliable data inside the sound object at intervals, equivalent to the first period, and information about the blocks for the sound object in which an offset is specified that indicates the difference between (1) the location of the internal location specified m moiety by a first point on the input information for the audio object and (2) in the memory location for the audio object given in the management information, and valid data length, which start position indicated by this offset. 6. A playback device for a semiconductor memory card containing (1) a protected area that can be accessed by a device physically connected to the semiconductor memory card and having a means of reading data stored in it, only if the authenticity of this device is established moreover, in the protected area is stored a sequence of encryption keys, consisting of many encryption keys located in a predetermined order, and (2) an unprotected area, access to which can be implemented by any device that is physically connected to the semiconductor memory board and has a means of reading the data stored in it, and at least one phonogram and control information are stored in an unprotected area, while at least one phonogram contains a lot of encrypted audio objects, and control information indicates which encryption key from the set of encryption keys corresponds to each sound object stored in a protected area, wherein said reproducing device comprises a reading means for reading from a semiconductor memory board one of a plurality of sound objects contained in at least one soundtrack, and reading from an encryption key sequence stored in a protected area of the semiconductor memory board, an encryption key that corresponds to the readable sound object, decryption means for decrypting the read sound object using by using the read encryption key, and playback means for reproducing the decrypted sound object, in which, after decryption of the read sound object by means of decryption, the reading means reads another sound object contained in the soundtrack, reads from the encryption key sequence the encryption key corresponding to to another sound object, and transfers the newly read encryption key to the decryption tool ki. 7. A recording device for recording on a semiconductor memory card an audio product consisting of a plurality of information content elements, the recording device comprising an encryption means that assigns to each information content element contained in the audio product at least one of the plurality of encryption keys and encrypts each content element using the encryption keys assigned to the content elements, thereby creating an a lot of sound objects, and a recording tool that writes to the semiconductor memory card a plurality of encryption keys in the form of a sequence of encryption keys and a plurality of sound objects in the form of at least one soundtrack. 8. The recording device according to claim 7, in which after recording a plurality of encryption keys and a plurality of sound objects, the recording means also writes control information to the semiconductor memory card, the control information indicating for each sound object a correspondence between that area on the semiconductor memory board, in which the sound object is stored, and the location in memory of the encryption key corresponding to the given sound object. 9. The recording device of claim 8, in which, for each sound object, the recording means also writes information about the attribute and layout information to the semiconductor memory card, the attribute information for each sound object indicating which type of the following types - type (a), type (b), type (c) and type (d) - it belongs, while type (a) represents the entire soundtrack, type (b) represents the first part of the soundtrack, type (c ) represents the middle part of the soundtrack, and type (g) pre represents the final part of the soundtrack, and the layout information for each sound object belonging to type (b) or type (c) indicates which sound object follows this sound object. 10. A recording device for a semiconductor memory card, comprising first generating means for sequentially generating sound frames from an input signal received from outside the recording device, the sound frame being the smallest amount of data for which independent decoding can be performed, recording means to create a file in the semiconductor memory board and write to the file sound frames created in the process of sequential generation, the second means of generation for generation, performed whenever a recording device records a predetermined number of sound frames into a file, a piece of data input information that indicates the data length of the sound element consisting of sound frames recorded in the file, in which, whenever the second generation device generates a predetermined number of pieces of information about data entry, the recording device creates a new file and writes to the new file those sound frames, the serial generator tion of which is carried out after this. 11. A computer-readable storage medium storing a program which, when executed by a computer, reproduces information from a semiconductor memory card by a computer, the semiconductor memory card comprising (1) a protected area that can be accessed by means of a device physically connected to semiconductor memory card and having a means of reading the data stored in it, only if the authenticity of this device is established and, in the protected area, a sequence of encryption keys is stored, consisting of a set of encryption keys arranged in a predetermined order, and (2) an unprotected area that can be accessed by any device physically connected to the semiconductor memory board and having a means of reading data stored in it, and in the unprotected area is stored at least one soundtrack and control information, while at least one soundtrack contains there are many encrypted audio objects, and the control information indicates which encryption key from the set of encryption keys corresponds to each audio object stored in an unprotected area, said program comprising the following operations: a read operation in which one of the semiconductor memory card is read from one of a plurality of sound objects contained in at least one phonogram, and reading from a sequence of encryption keys stored in a guard region of the semiconductor memory board, the encryption key that corresponds to the read sound object, the decryption operation, in which the read sound object is decrypted using the read encryption key, and the playback operation, in which the decrypted sound object is reproduced, and after decryption operation, decryption of the read sound object is completed, a read operation is performed in which another sound is read An encryption key corresponding to another sound object is read from the encryption key sequence of the object contained in the soundtrack, and the newly read encryption key is transferred to the decryption operation. 12. A computer-readable storage medium that stores a program that, when executed by a computer, records information through a computer to a semiconductor memory card, the program comprising the following operations: an encryption operation in which each element of information content contained in a piece of music is assigned at least one of the plurality of encryption keys, and each content item is encrypted using the assigned ele entu of content encryption keys, thereby creating a plurality of audio objects, the recording operation in which the charge in the semiconductor memory to record a plurality of encryption keys as an encryption key sequence and the plurality of audio objects as at least one audio track. 13. The computer-readable storage medium according to claim 12, wherein after recording the plurality of encryption keys and the plurality of sound objects, the recording information also records control information onto the semiconductor memory card, the control information indicating for each sound object corresponding to that area on the semiconductor memory board in which the sound object is stored, and the location in the memory of the encryption key corresponding to the sound object. 14. The computer-readable storage medium according to claim 13, wherein, for each sound object, when performing a recording operation, attribute information and arrangement information are also recorded on the semiconductor memory card, the attribute information for each sound object indicating which type of the following types - type (a), type (b), type (c) and type (d) - does it belong to, while type (a) represents the entire soundtrack, type (b) represents the first part of the sound phonograms, type (c) represents the middle part of the soundtrack, and type (d) represents the end part of the soundtrack, and the layout information for each sound object belonging to type (b) or type (c) indicates which sound object follows this sound object. 15. A computer-readable storage medium that stores a program that, when executed by a computer, writes information through a computer to a semiconductor memory card, the program comprising the following operations: a first generation operation, in which the sound frames are sequentially generated from the input signal, the reception of which produced from outside the recorder, the sound frame being the smallest amount of data for which there can be ENO independent decoding; a recording operation in which a file is created in the semiconductor memory board and the sound frames created in the process of sequential generation are recorded in the file; the second generation operation, in which whenever a recording device records a predetermined number of sound frames into a file, a piece of data input information is generated that indicates the data length of the sound element consisting of sound frames recorded in the file, in which each time when a predetermined number of pieces of data input information is generated during the second generation operation, when a write operation is performed, a new file is created and recorded in a new file of those sound frames sequentially generated after that. 16. A reproducing method for reproducing data from a semiconductor memory card comprising (1) a protected area that can be accessed by a device physically connected to the semiconductor memory card and having a means of reading data stored therein, only if the authenticity of this device is established, and in the protected area is stored a sequence of encryption keys, consisting of many encryption keys located in a predetermined order e; and (2) an unprotected area that can be accessed by any device that is physically connected to the semiconductor memory card and has a means of reading the data stored in it, at least one soundtrack and control information are stored in the unprotected area, at least one phonogram contains a plurality of encrypted audio objects, and the control information indicates which encryption key from the set of encryption keys corresponds to each a sound object stored in an unprotected area, said reproduction method comprising the following operations: a read operation in which one of a plurality of sound objects contained in at least one sound track is read from a semiconductor memory board and read from a sequence of encryption keys, stored in the protected area of the semiconductor memory board, the encryption key that corresponds to the read sound object, the decryption operation, when which decrypts the read sound object using the read encryption key, and a playback operation, in which the decrypted sound object is reproduced, and after the decryption operation decrypts the read sound object, the read operation is performed, in which another sound object is read, contained in the soundtrack, from the sequence of encryption keys read the encryption key corresponding to another sound object, and transmit the newly read encryption key in the decryption operation. 17. A recording method for recording onto a semiconductor memory board an audio composition consisting of a plurality of information content elements, said recording method comprising the following operations: an encryption operation in which at least one of each information content element contained in a musical composition is assigned sets of encryption keys, and each content item is encrypted using the key assigned to the content item encryption, resulting in the creation of many sound objects, and a recording operation in which a plurality of encryption keys are recorded on the semiconductor memory card as a sequence of encryption keys and a plurality of sound objects in the form of at least one sound track. 18. The recording method according to 17, in which after recording a plurality of encryption keys and a plurality of sound objects during a recording operation, control information is also recorded on the semiconductor memory card, the control information indicating for each sound object a correspondence between that area on the semiconductor memory board where the sound object is stored, and the location in memory of the encryption key corresponding to the sound object. 19. The recording method according to claim 18, wherein for each sound object, when performing the recording operation, the attribute information and the layout information are also recorded on the semiconductor memory card, the attribute information for each sound object indicating which type of of the following types - type (a), type (b), type (c) and type (d) - it belongs, while type (a) represents the entire soundtrack, type (b) represents the first part of the soundtrack, type (c) represents the middle part of the soundtrack, type (g) represents the final part of the audio soundtrack and the layout information for each audio object belonging to the type (b) or type (c) it indicates which audio object follows the audio object thereafter. 20. A recording method for recording onto a semiconductor memory card, comprising the following operations: a first generation operation, in which the audio frames are sequentially generated from an input signal received from outside the recording device, the audio frame being the smallest amount of data for which independent decoding can be performed; a recording operation in which a file is created in the semiconductor memory board and the sound frames created in the process of sequential generation are recorded in the file; the second generation operation, in which whenever a recording device records a predetermined number of sound frames into a file, a piece of data input information is generated that indicates the data length of the sound element consisting of sound frames recorded in the file, in which each time when a predetermined number of pieces of data input information is generated during the second generation operation, when a write operation is performed, a new file is created and recorded in a new file of those sound frames sequentially generated after that.

Images