Semiconductor memory board, reproduction device, recording device, reproduction method, recording method and data carrier read by a computer

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

 

The technical FIELD TO WHICH the INVENTION RELATES.

The present invention relates to a circuit Board of a semiconductor memory in which memorizes audio data and control data, and the playback device, recording device, method of reproduction, the recording method, and related to this motherboard semiconductor memory media account that has read through a computer. In particular, the present invention relates to an improved memory control information and audio data that are distributed in the form of informational content distribution service information such as service music distribution electronically.

The LEVEL of TECHNOLOGY

In recent years there has been a gradual introduction hardware infrastructure necessary to ensure the dissemination of music electronically. This leads to the possibility of large changes in the music industry, in which the distribution of products is usually carried out in the form of ready-made computer programs in retail packaging with the use of such media as CD-ROMs (CD) and magnetic cassette tape.

Music content (i.e., songs and albums) can be delivered to consumers in electronic form if potrebitelskogo computer that load content from a computer server, which is administered by the record company. To listen to the downloaded digital music on a portable playback device, the user must store the music data on a portable recording medium. Currently, the most suitable media for storing music information, which is carried out electronically, are Board semiconductor memory.

Examples of such devices are flash memory card with ATA Board and COMPACTED FLASH MEMORY, which is already available for use. Such fees semiconductor memory contain semiconductor device called a flash EEPROM (programmable permanent memory group (parallel) electrical erase). Flash memory can be read out and write data with much higher speeds than MD (MD) (MD) or PKD (rewritable CD) (CD-R). This means that the transmission of music in digital form can be carried out in a short time, despite the fact that it has a large amount of data.

The main disadvantage inherent in the cards semiconductor memory, is the risk that the user may shall prepare illegal copies of copyrighted musical works, loading is made from a music distribution service electronically. Because Board semiconductor memory to write data with a higher speed than PKD or MD, then I guess copying is the most serious problem for these memory cards. In order to overcome the possible dangers related to copyright infringement, the music presented in digital form, must be encrypted using a secure encryption method before implementing it memorizes the Board in a semiconductor memory.

One way of remembering, which take into account the need to prevent unauthorized copying is a way of storing records of musical works used in the standard DVD audio (UCD - digital versatile disk). One example of this method is one in which "the record of a musical work, which is associated with normal music the album contains many of the elements of the information content, which correspond to the phonograms in the album. The content elements that make up a musical work, encrypted by using the encryption key, referred to as the "key musical works"which were the focus of the manufacturer of the disk before burning to DVD audio (UCD) disk. This key musical compositions encrypted using the encryption key (usually called a "key disk"), which is unique for each audio DVD (UCD) disk, and remember in the header area of the sector sound DVD (UCD) disk. Encryption as the key drive is carried out using the encryption key (usually called "master key"), which is carried out by the manufacturer of the device decoding the information content, and the recording is carried out in the initial audio DVD (UCD) disk. Normal users can't access the header area of the sector and to the starting area, making it extremely difficult for unauthorized users receive key piece of music recorded on the audio DVD (UCD) disk.

Board semiconductor memory have limited storage capacity compared to magnetic or optical storage media, therefore, as a rule, it is necessary to compress music, represented in digital form, with a high compression ratio when memorizing Board in a semiconductor memory. One way of encoding, which provides a relatively high compression ratio for music, represented in digital form, is a standard MPEG2-AAC (Standard 2 expert group on the is itself moving image Advanced coding of audio information) (Motion Pictures Experts Group 2 - Advanced Audio Coding}. One of the distinguishing features of the standard compression MPEG2-AAC is that it uses the constraints caused by the human ear, and the length of the binary data is assigned to each audio frame, change in such a way that an audio frame, which is the smallest single element of the playback, displays, approximately, 20 MS audio signal. Binary data is of great length, assign audio frames, which have a lot of frequencies within the range of audibility of the human ear, and the binary data of the shorter assign audio frames, which have a lesser number of such sounds or frequencies outside the range of audibility of the human ear.

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

The FIRST PROBLEM

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

Despite the fact that the decryption keys of a musical work is rare, this insecurity can lead to huge losses to the copyright owner. Considering the fact that in recent years there has been a huge increase in computing power of home computers, it is becoming increasingly difficult to argue that the key musical compositions that are used to encrypt music, represented in digital form, will be fully protected from decryption. This necessitates the creation of such a data structure that will minimize the harm to copyright owners for the decryption key of a musical composition.

The SECOND PROBLEM

As for music, represented in digital form, which is intended for distribution means to distribute music electronically, think the MoE to ensure the protection of copyright, such music is usually spread in encrypted form. You also need to encrypt and the music represented in digital form, which is remembered in the circuit Board of the semiconductor memory. However, this leads to the second problem, namely, that in the case of storing music in the circuit Board of the semiconductor memory in encrypted form, the user who paid the proper price when buying musical works in digital form, will not be able to edit music in a simple way. In the case when memorizing information content of a piece of music performed in encrypted form, the user is very difficult to change the order of the phonograms, or to carry out the removal of part of the recording. Taking into account the fact that the user has paid the proper price, it is advisable not to restrict his/her from exercising the like editing music information.

The recording device on a mini-disk (MD), which, as well as fee semiconductor memory, can be used to record music, allow you to perform many editing functions phonograms through what they have provided OGLE (TOC) (TOC). Such functions include changing the playback order of phonograms, division of phonograms and the joint is out of phonograms in one soundtrack. If the recording device on the boards of the semiconductor memory is not able to provide the same functions as a conventional recording device on MD, it is assumed that consumers will regard the playback device with the boards of the semiconductor memory, as having the worst possible compared with the recording devices on the MD, which, consequently, causes damage to the commercial success of products with the boards of the semiconductor memory.

The THIRD PROBLEM

To provide special functions of music in digital form, which was subjected to encoding with PSPD (VBR), as, for example, in standard MPEG2-AAC, the playback device must be equipped with a high capacity memory. This increases the cost of production of such devices and leads to a third problem for the prior art.

Special playback functions, which are provided in the playback devices of the MD or CD (CD-ROM), include the ability to start playback from any records on disk (representing the location of the play), the search function of music in which carry out intermittent playback of short segments of music in order to enable the user to "jump" through the phonogram in the direct or reverse direction, the high speed, and the search function of time, whereby the user can start playback from the place, which is entered as the time measured from the beginning of the disc. In order to capture the market, currently held by the playback devices of the MD or CD, it is necessary that the playback devices with plates of a semiconductor memory has been provided by the same special playback functions and playback devices MD. When the music content is subjected to encoding with a constant speed transmission of binary data (Postcmd) (CBR), playback from the location that is set by using the time code (such a point is within one or two minutes from the beginning of phonograms), can be made simply by reference to the address offset value that is a multiple of the amount of data in a single interval of playback time, multiplied by an integer. However, when encoding music content made using the method PSPD, for example, MPEG2-AAC, those points that correspond to one or two minutes before the current location, rarely will be offset by the amount that is a multiple of the amount of data in a single interval of playback time, multiplied by an integer. As a result, the device reproduced what I will be forced to perform conversion to the table created in advance of the time search to indicate what addresses correspond to points that are ahead of time in one minute and two minutes.

Despite the fact that the table search time for a short film must contain a large number of installation points when playing, this assertion is not valid for table search time for a long, phonograms, so a lookup table in time for the long, phonograms very large. To ensure accessibility playback the playback device needs to access the table search time by loading it into memory first.

As long phonograms have a large lookup table on time, it means that the playback device must be equipped with a high capacity memory for storing a lookup table in time. This also increases the cost of production of playback devices.

The INVENTION

The first aim of the present invention is the creation of a Board, a semiconductor memory, which provides copyright protection to the stored music content, while users are allowed to edit the musical content.

The second objective of the present invention is a playback device, which is may perform special playback functions, for example search for music content recorded on the Board, a semiconductor memory, in forward and reverse direction without using a memory of large capacity.

The first objective of the present invention can be achieved by designing the structure of the Board, a semiconductor memory, which stores at least one audio soundtrack, including: the protected area, access to which can be carried out by a device that is physically connected to - semiconductor memory and having a means of reading the data stored in it, only if you have installed the authenticity of this device, and in the protected area stores a sequence of encryption keys, consisting of a set of encryption keys arranged in a predetermined order; and an unprotected area, access to which may be implemented by any device that is physically connect with - semiconductor memory and having a means of reading the data stored in it, and in an unsecured area stores at least one audio recording, and control information, and at least one audio soundtrack contains a lot of encrypted audio objects, and the control information indicates which encryption key from a set of keys W is grovania corresponds to each audio object, stored in an unsecured area.

Through the stated structure can be implemented encryption of the many sound objects using multiple encryption keys in such a way that if the encryption key used to encrypt a particular audio object decoded and classified, such declassification would allow decryption only specific audio object and, therefore, will not act in relation to the rest of the sound objects. This means that the proposed fee semiconductor memory minimizes the damage caused by the declassification of one of the encryption keys.

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

Each audio soundtrack may additionally contain (1) information about the attribute and (2) layout information for each audio object in the audio soundtrack, and information about the attribute tells which type of the following types : type (a)type (b), type (type) and (g) belongs to each audio object, and the type (a) represents the entire audio playback, type (b)represents the first part of the audio soundtracks, type (in) represents the middle part of the audio soundtracks, and type (g) represents the final part of the audio soundtracks, and information about the layout for each audio object type (b) or type (in) indicates which audio object should then sound object.

Using the stated structure leads to the achievement of the following results. Information about the attribute indicates how the implemented layout of encrypted audio objects in the audio phonograms, when control of two sound objects operate as two separate sound phonogram, the phonogram, may be combined in a single phonogram by simply changing the information about the attribute to indicate that the sound objects match the beginning and end tags. As the audio soundtrack can be combined by changing the information about the attribute, the Association of phonograms can be performed at high speed without having to perform decoding of an audio soundtracks.

While many sound objects may contain at least one audio object containing only reliable data for replay; and at least one audio object containing (1) reliable data and (2) inadequate given the s, located before and/or after reliable data, and playback of false data to carry out is not required, with each audio soundtrack additionally contains information about the blocks for each sound object from the sound of the phonogram, and this information blocks contains the offset measured relative to the location corresponding audio object in memory, which is specified in the control information; and information about the length, which indicates the length of reliable data, starting from the position specified by offset, and information about the attribute of the audio object specified whether or not valid data set by offset and length information, (a) correspond to the entire audio track, (b) correspond to the first part of the audio soundtracks, and (C) correspond to the middle part of the sound of the phonogram, or (d) correspond to the end portion of an audio recording.

Preferably, the sound of phonograms can be carried out in accordance with standard playback mode or intermittent playback mode and standard play mode is a mode in which the playback of reliable data in the audio objects constituting the sound of the phonogram, syshestvyut without any omission of reliable data, and intermittent playback mode is a mode in which repeatedly perform (1) skip reliable data equivalent to the first period, and (2) reproduction of reliable data equivalent to the second period, and each audio soundtrack also contains many pieces of information about the entry points that indicate where the internal layout of reliable data inside the sound object at intervals equivalent to the first period; and information on the blocks for the sound object, which is specified: the offset, which indicates the difference between (1) the internal location specified by the first piece of information about the entry points for the sound object, and (2) a location in memory for the sound object, specified in the control information, and the length of the valid data, the start position which is specified by the offset.

In the presence of unreliable data at the beginning of the audio frame length of these false data, and the length of valid data in the audio frame can be installed in the unit information. As a result, when the user records a broadcast, in which the leading music transfer said during the introduction to the song, to play a song without the entry, which contains the voice of the Vedas is the future of musical transmission, information units can be installed with the proper offset of the data. Such editing operations can be performed through simple instructions in the blocks in which data should not reproduce, and perform them with sound objects in an encrypted state. This means that the editing of phonograms can be performed at high speed.

The second objective of the present invention can be achieved by a recording device Board for a semiconductor memory, comprising: the first device generation for sequential generation of audio frames from the input signal, which is fed from outside the recording device, and the audio frame represents the least amount of data for which can be made independent decoding; a recording device to create the file in the circuit Board of the semiconductor memory and write sequentially generated audio frames in the file; the second generation device for generating performed whenever the recorder made an entry in the file, a predetermined number of audio frames, pieces of information about the input, which indicates the data length of the audio element, consisting of recorded sound file frames, in which whenever the second device generating the implementation of the and the generation of a predetermined number of pieces of information about the input, the recorder creates a new file and writes to a new file, the audio frames, sequential generation which is carried out thereafter.

When the audio data stream corresponds to a music album, which contains the long track, to ensure that the number of pieces of information about the input for a single file is not larger than a predetermined value, the long track divided into multiple files. The limitation in the file number of pieces of information about the input reduces the amount of control information file. Here's how the playback device uses this control information. When the playback device reads the file and starts playing it is contained in the file of the sound object, the playback device also performs read control information file and stores it in the internal memory. This control information must be stored in memory as long as you continue to play the sound object. When the playback of the audio objects have been completed, carry out the reading of the next sound object. At the beginning of the play this next sound object shall read the corresponding control information and overwrite it in the internal memory device in the works to replace the control information, which was kept up to the present time.

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

The control information defines the procedure for the distribution of multiple sound objects sound phonograms and their application audio playback of phonograms in such a way that you can easily edit phonograms by simply updating management information.

BRIEF DESCRIPTION of 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 show a particular embodiment of the invention.

In the drawings:

Figure 1 is a top view of circuit Board 31 flash memory;

Figure 2 is a bottom view of the structure of the circuit Board 31 of the flash memory;

Figure 3 - hierarchical structure of the circuit Board 31 flash memory options for carrying out the invention

Figa a special area in the region of the feature identification and the user, created at the physical layer circuit Board 31 flash memory;

Figb - structure identification and the user area on the file system level;

5 is a detailed structure of the file system;

6 is a variant of the invention, when a file of the sound object (AOW) “AOB001.SA1” is divided into five parts, which remember in clusters, 003, 004, 005, E, and 00C;

7 is one example of the installation directory and the file allocation table in the case where the file of the sound object(AOW) “AOB001.SA1” recorded in multiple clusters;

Figa and PIGB - directories created in the user area and in the identification area on the file system level in the case when the application layer is carried out record two types of data, as well as what types of files recorded in one directory;

Fig.9 is a correspondence between the file AOBSA1.KEY and files GOITER (sound objects) (AOW files) in the directory PUBLISHING (the original audio data) (SD_Audio);

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

Figa parameters, due to the standard ISO/IEC 13818-7 (International organization for standardization/International electrotechnical Commission, ISO/IEC), presented in the form of a table;

Figb - parameters that should be used when encoding MPEG file, 3-level (MPEG-Laer 3) (MP3) presented in the form of a table;

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

Fig - detailed structure QUADRAT (frame sound object) (_FRAME);

Fig - sets the length of the sound data in bytes in each of the three KUDROVO (AOB_FRAMEs);

Fig - correspondence between castoroides and number KUDROVO (AOB_FRAMES)contained in the ELEMENT GOITER (AOB_FLEMENT);

Fig examples of playing time LAMENTOSO (AOB_FLEMENTS) and playing time KUDROVO (AOB_FRAMES);

Fig is the result of play in the case, when making sequential playback GOITER (AOBs) and BLACKOUT (AOB_BLOCKS)recorded in the file GOITER (AOW file);

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

Fig - memory for the administrator of the playlist (PlaylistManager) and administrator of phonograms (TrackManager);

Fig, 19 is a correspondence between the information data phonograms (IDF) (TKIs), shown in Fig, and GOITER (AOBs) and files GOITER (file AOW), which is shown in Fig;

Fig - detailed data structure TMVGPBR (abliz search of phonograms time) (TKTMSRT), depicted on Fig;

Fig is one of the model options TMVGPBR (TKTMSRT);

Fig - detailed structure OFG (General information on the soundtrack) (TKGI);

Figa and PIGB - detailed structure of TIB (table information block) (BIT), and FIGU - region Prodolzhitelnost (Time_Length);

Fig cluster with 007 on AOE, which made remembering GOITER (AOW), consisting of ELEMENTOOL 1 ELEMENTAT (AOB_ELEMENT#1) on 4th ELEMENTAL ((AOB_ELEMENT#4);

Fig implementing the installation of the next (x+1)-th QUADRAT (AOB_FRAME#x+1) to play in the implementation of the search in the forward direction, starting from the (x)th QUADRAT (AOB_FRAME#x) in an arbitrary (U)-ω ELEMENTAT (AOB_ELE-MENT#y) GOITER (AOW);

Figa and Figb definition of GOITER (AOW), ELEMENTAL (AOB ELEMENT), and the FRAME GOITER (AOB FRAME)corresponding to an arbitrary time code playback;

Figa and Fig B - erasing of the phonogram;

Figa administrator of phonograms (TrackManager) after erasing the phonogram was made several times;

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

Figa and PIGB - set IDF (TKI) in the case when to create a new phonogram carry out the merger of the two phonograms;

Figa - GOITER (AOW) 1 type (Type1);

Figb - ZO is (AOW) 2nd type (Type2);

Figa - Union of the set of phonograms in one soundtrack for the total GOITER (AOW) 1 St + 2 St + 2-St + 1-St type (type 1 + Type 2 + Type 2 + Type1);

Figb - Union of the set of phonograms in one soundtrack for the total GOITER (AOW) 1st + 2nd + 2nd + 2nd + 1-th type (Type1 + Type2 + Type2 + Type2 + Type1);

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

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

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

Figg is an example in which the end of the first phonogram is GOITER (AOW) 1 type and 2-type, and in the beginning of the next phonogram is GOITER (AOW) 2-type 1-type;

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

Figa and PIGB - division of a phonogram to create two phonograms;

Figa and Figb content items in the catalog of the original audio data (SD_Audio) in the directory of the original audio data (SD_Audio), which contains the file GOITER (AOW file “AOB003.SA1”, before and after the separation of the phonogram;

Figa - division GOITER (AOW) by dividing the 2nd ELEMENTAT (AOB_ELEMENT#2) in half.

Figb two GOITER (AOW), 1st GOITER (AOW#1) and the 2nd CROP (AOW#2), obtained by dividing GOITER (AOW) in the middle of the 2nd ELEMENTAT (_ELEMENT#2);

Fig - installation state TIB (BIT) in the case when the GOITER (AOW) is divided thus, as shown in Fig;

Fig - specific example of changes in TIB (BIT) before and after separation;

Fig - specific example of changes in TMVGPBR (TKTMSRT) before and after separation

Figa format UPFLUSH (search index soundtracks from the playlist, the default) (DPL_TK_SRP);

Figb format UPPGIFT (search index soundtracks from the playlist) (PL_TK_SRP);

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

Fig - example installations of values for Spissky Default_Playlist) and several IVF (playlist) (PLIs);

Fig - compliance UPFLUSH (pointers search soundtracks from the playlist, the default) (DPL_TK_SRP) IDF (TKI), used the same notation that appears on Fig;

Figa and PIGB - rebuild the order of phonograms;

Figa and PIGB - upgr is of Spissky (Default_Playlist), administrator of phonograms (TrackManager) and files GOITER (AOW file) in the case when Spissky (Default_Playlist), shown in Fig, removed UPFLUSH NO. 2 (DPL_TK_SRP#2) and IDF No. 2 (TC#2);

Figa and PIGB - recording new IDF (TKI) and UPFLUSH (DPL_TK_SRP) in the case when there are “unused” IDF (TKI) and UPFLUSH (DPL_TK_SRP);

Figa and PIGB - implementation of Association of the phonogram;

Figa and PIGB - implementation separation of the phonogram;

Fig - type portable playback device for card 31 flash memory embodiments of the present invention;

Fig is one example of display on the liquid crystal panel when you select the playlist;

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

Figa - 51B report are examples of operations performed by the rotary disk speed switching;

Fig - the internal structure of the playback device;

Fig - implementation data in the double buffer 15 and from it;

Figa and PIGB - implementation cyclic distribution areas in the double buffer 15 using the ring pointers;

Fig - precedence diagram showing a procedure of reading the file GOITER (AOW file);

Fig diagram follower of the spine operations, showing the procedure output file GOITER (AOW file);

Fig - precedence diagram showing the procedure output file GOITER (AOW file);

Fig - precedence diagram showing the procedure output file GOITER (AOW file);

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

Fig - precedence diagram that illustrates the processing of the CPU (Central processing unit) 10 in the case when using the search function in the forward direction;

Figa - Figg - implementation increment time code playback when using the search function in the forward direction;

Figa and Fehb - specific examples of how to use the search function of time;

Fig - precedence diagram showing processing in the control program editing;

Fig - precedence diagram showing processing in the control program editing;

Fig - precedence diagram showing processing in the control program editing;

Fig - one given as an example, variants of the mouth of the STS write to write data to the card 31 flash memory;

Fig - hardware capture devices;

Fig - precedence diagram showing processing when recording;

Fig - appliance circuit Board 31 flash memory;

Fig sequence of the process of transmission of information which is used when the playback device coupled with the card 31 flash memory, reads the encryption key “Key File” (FileKey) and performs playback GOITER (AOW); and

Fig - detailed sequence of the process of transmission of information which is used when performing mutual identification of Pig.

The BEST WAY of carrying out the INVENTION

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

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

{x1-HH-x4}

The length of the reference number indicates the hierarchical level of a section description. As a concrete example, the number 1 represents the number of a drawing, on which there is a link in the description. The drawings attached to this description, numbered in the order in which they are mentioned in the description, therefore, is in the order of the drawings corresponds roughly to the order of presentation. Explanation of some of the drawings are divided into paragraphs, with the number x2 of links indicating the number of the paragraph for paragraph from the description of the drawing indicated by the number x1 links. Room X3 links indicates the number of the drawing, which is needed for a more detailed explanation of the paragraph, designated by the number x2 of the paragraph. Finally, the reference number x4 indicates the number of the paragraph in the description of this additional drawing.

The FIRST OPTION EXERCISE

(1-1_2) appearance fees 31 flash memory

This explanation begins with a description of the appearance of the card 31 flash memory. Figure 1 shows the appearance of the card 31 flash from above, and figure 2 shows the structure of a circuit Board 31 flash memory on the form below. As shown in figure 1 and figure 2, the card 31 flash memory is about the same size as a postage stamp and, therefore, is large enough to hold in your hand. It has dimensions of approximately 32.0 mm, length 24.0 mm in the width and thickness of 2.0 mm

It is seen that at its bottom edge of the card 31 flash memory has nine connectors to connect the card with a compatible device and located on one side of the protective switch 32, which allows the user to set whether to overwrite the stored content of the card 31 flash memory or prohibited.

{3-1} Physical article is ucture Board 31 flash memory

Figure 3 shows the hierarchical structure of the Board, a semiconductor memory (hereinafter referred to as “Board 31 flash memory”) from this version of the implementation. As shown in Figure 3, the card 31 flash memory created in such a way that has a physical layer, a file system layer and the application layer is similar to the DVD (CVP) (digital videodisc), however, the logical and physical structure of these levels are very different from those on a digital video disk (DVD).

{3-2} Physical layer circuit Board 31 flash memory

Below is a description of the physical layer circuit Board 31 flash memory. Flash memory consists of a number of sectors, each of which remembers 512 bytes of digital data. As one example, the card 31 flash memory capacity 64 MB will have a memory capacity of 67108864 (=64*1024*1024) bytes, so this card contains 131072 (=67108864/512) operating sectors. When you subtract the number of reserved sectors, which create for use in case of an error, the remaining number of sectors, which can be carried out record various kinds of data, equal to approximately 128000.

{3-A-1} Three areas in the physical level

These three areas depicted on Figa create a memory area consisting of these existing sectors. These areas are "special region", "region identification and blast user", as described in more detail below. The user differs in that the device with which are connected the card 31 flash memory can be freely read or write various kinds of data from this area or in it. Management areas within the user area, shall be implemented by the file system.

In a special area memorize the ID of the media, which is a unique number that uniquely assigns each Board 31 flash memory. Unlike the user area, this area is only for reading, so that the identifier (ID) of the media stored in a special area, cannot be changed.

The field of identification like the user area is an area in which provided the possibility of rewriting. This area is different from the user that the device is connected to the plate 31 of the flash memory can be accessed (i.e. to read or write data) to the field of identification only if the card 31 flash memory and the device previously confirmed that both of them are real devices. In other words, the data is read from the identification area or write can be performed only if you have successfully maintains the health of the identification card 31 flash memory and the device, connected to the plate 31 of the flash memory.

{3-A-2} the Use of these three areas in the physical level

When the device is connected to the plate 31 flash memory, writes data in the card 31 flash memory, it is an area which is used for storing these data depends on whether you want to provide copyright protection for recordable data. When the card 31 flash memory write data for which you want to protect the copyright, before data will be written to the user, they are encrypted using a predetermined encryption key (called a "Key file" ("FileKey")). This "Key file" ("FileKey") can be easily installed by the copyright owner, and, despite the fact that the use of this "Key file" ("FileKey") provides a certain degree of copyright protection, encrypt and the key file (FileKey)used to encrypt the recorded data to provide more robust protection of copyright. To encrypt the key file (FileKey) can be used any number obtained by performing predetermined arithmetic operations with the identifier (ID) of the medium, which is stored in a special area. Created in this way, the encrypted key file (FileKey), remember in the field of identification.

The village is olcu data for which you want to protect the copyright, is subjected to the two-stage process of encryption, where the encryption is performed with the use of a key file (FileKey), which is itself encrypted using an identifier (ID) of the media, to carry out copyright infringement, for example to make illegal copies of these data can be extremely difficult.

{3-B-1} is a Brief description of the file system

It is clear that the design of the physical layer circuit Board 31 flash memory enhances the protection of copyright for the data recorded in the circuit Board 31 flash memory. Below is a description of the file system that resides on a physical level. Despite the fact that at the file system level digital video disc (DVD) use file system type UDF (FOOD) (universal disk format)file system level Board 31 flash memory using the file system type is FAT (TRF) (file allocation table)described in the standard ISO/IEC 9293.

On Figb shows the structure of the identification area and the user area on the file system level. As shown in Figb, and the field of identification, and the user in the file system contain "partition boot sectors, file allocation table (TRF)"(FAT), "root", and "data area"and this means that the area identificat the AI and the user have the same structure. Figure 5 depicts the different parts of these file systems. Below is a description of the structure of the user with reference to Figa, Figb and 5.

{3-B-2} of the partition Boot sector

The partition boot sector are the sectors in which memorizes the data accessed by a standard personal computer connected to the plate 31 of the flash memory, in that case, when the card 31 flash memory is set as a boot disk for the operating system (OS) (OS) of a personal computer.

{3-B-3_5} data Area

Access to the data region can be carried out element-by-element through the device connected to the card 31 flash memory, and the volume of one element cannot be less than the size of a single "cluster". Despite the fact that the volume of each sector in the circuit Board 31 flash memory 512 bytes, and the volume of the cluster is equal to 16 KB (kilobytes), therefore, the reading and writing of data on 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 that when writing data to the card 31 flash memory before recording, you must first perform the erasing of data stored in the circuit Board 31 flash memory.

The smallest amount of data erasing which can be realized in the circuit Board 31 flash memory is 6 KB so the lowest possible volume erasable data is equal to the cluster size means that the data record can be carried out in the best way. Arrow ff2, which is depicted in Figure 5 by the dashed line, indicates many clusters 002,003,004,005...contained in the data area. Used figure 5 number 002,003,004,005,006,007,008... represent a three-digit hexadecimal numbers of clusters, which assigns a unique way to identify each cluster. Since the smallest element size, through which can be accessed, equal to one cluster, the memory cells within a data region denoted by the use of cluster numbers.

{3-B-4_5} System file allocation

The system host file has the structure of a file system according to ISO/IEC 9293, and thus consists of a set of values TRF (FAT). Each value TRF (FAT) corresponds to the cluster and indicates which cluster should be read after the cluster corresponding to the value of TRF (FAT). Arrow ff1, which is depicted in Figure 5 by the dashed line, indicates the set of values TRF (FAT) 002,003,004,005...that contains the file allocation table. Non 002,003,004,005...assigned to each value of TRF (FAT), indicate which cluster corresponds to each value of TRF (FAT) and, after vetelino, represent the number of clusters to clusters corresponding to values TRF (FAT).

{3-B-5_5-1} of the root directory

"The root directory" is 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 corrections" and "the number of the first cluster in the file that specifies where stored beginning of the file, and they can be recorded as an item in the root directory of the file.

{3-B-5_5-2} directory entries for subdirectories

Recording information related to the files in the root directory, perform the elements of the root directory, however, information related to the subdirectories are not written down in the form of the root directory. Instead, the elements of the directory to create subdirectories in the data area. Figure 5 is one example of a directory entry for a subdirectory is a directory entry of the original sound data (SD-Audio)specified in the data area. Like the item in the root directory, the directory entry of the original sound data (SD Audio) contains the "file name" in the subdirectory of the file "file name extension", "time/date updates" and "the number of the first cluster in the file indicating where Zapomni what about the beginning of the file.

{3-B-5_6-1} Format memory files GOITER (sound objects) (AOW)

Below with reference to Fig.6 describes the way of saving the file through a demonstration of how to perform the memorization of the file with name "AOB001.SA1" in the same directory as the source of the sound data (SD Audio). Because the least a single element of the access to the data region is one cluster, the memory file "AOB001.SA1" in the field of data should be done by parts, the size of which does not exceed one cluster. Therefore, before storing the file AOB001.SA1" his first divided into clusters. Figure 6 file AOB001.SA1" is divided into five parts according to the size of the cluster, and the resulting part remember in clusters with numbers 003, 004, 005, E, and 00C.

{3-B-5_7-1} Format memory files GOITER (sound objects) (AOW)

When the file AOB001.SA1" divided into parts and stored, you must set the value of an element of the directory and the file allocation table, as shown in Fig.7. 7 shows one example of how to set the value of an element of the directory and the file allocation table when memorizing file "AOB001.SA1" in that case, when it was divided into parts and stored. 7 the beginning of the file AOB001.SA1" remember in the cluster 003, therefore, to specify the cluster in which memorized the first part of the file in the directory entry of the original zvukovoy the data (SD Audio) as "number of the first cluster in the file record number 003 cluster. As shown in Fig.7, the next part of the file AOB001.SA1" remember in clusters 004 and 005. As a result, despite the fact that the value 003(004) TRF (FAT) corresponds to the cluster 003, in which memorized the first part of the file AOB001.SA1", this value indicates that the cluster 004 is the cluster in which remembered the next part of the file AOB001.SA1". Similarly, despite the fact that the values 004(005) and 005 (A) TRF (FAT) correspond to clusters 004 and 005, which saved the following part of the file AOB001.SA1", these values are, respectively, indicate that the cluster 005 and cluster A are clusters in which memorized the following part of the file AOB001.SA1". By reading clusters with the same numbers of clusters, which are recorded in these values TRF (FAT), in the manner shown by the arrows fk1, fk2, fk3, fk4, fk5... 7, can be carried out reading all of the parts obtained by dividing the file "AOB001.SA1". As explained above, access to the data area of the card 31 flash memory is performed in units of clusters, each of which is mapped to the value of TRF (FAT). It should be noted that the value of TRF (FAT), corresponding to the cluster in which memorized the end of the file GOITER (AOW file) (cluster OOS in the example shown in Fig.7), is set equal to the number of cluster FFF in order to show that in the corresponding cluster memorized the end of the file.

This end is jut a description of the file system in the card 31 flash memory of the present invention. The following is a description of the application layer that exists on the filesystem.

{3-3} Brief description of the application layer in the circuit Board 31 flash memory

Figure 3 shows a General view of the application layer in the circuit Board 31 flash memory. As shown by the arrow PN2, is shown in figure 3 by the dashed line, the application layer in the circuit Board 31 flash memory consists of reproduced data and navigation data, which are used to control playback of the playback data. As shown by the arrow PN2, reproducible data contain sets of sound objects (sets GOITER (AOW)), which create by encoding audio data representing, for example, music. Navigation data contain "administrator of the playlist (ADSVR) (PlaylistManager) (PLMG), and administrator of phonograms" (ADFG) (TrackManager) (TKMG).

{3-A, B-1}, the directory Structure

On Figa and Figv shows what directories are in the user area and the identification area on the file system level in the case when these two types of data remember at the application level, but also shows what files are in these directories.

The file names "SD_AUDIO.PLM" ("__.PLM", where the extension ".PLM" means the administrator of the playlist" - translator's note) and "SD_AUDIO.TM" ("Ichthyosauridae", where the extension "TCM" means the administrator of phonograms" - translator's note) Fig 8A indicate the files that implement remembering the administrator of the playlist (ASWF) (PlaylistManager) (PLMG) and administrator of phonograms (ADFG) (TrackManager) (TKMG), which form a navigation information. Here the file name "AOB001.SA1", "AOB002.SA1", "OW. SA1", "AOB004.SA1", ... denote those files (the files "GOITER" ("AOW" files)), which made remembering the sound of objects representing reproducible data. The symbols "FOR" in the file name extension for the file name "AOBOxx.SA1" are an abbreviation of the term "Protected audio data" (Secure Audio) and indicate the need for copyright protection for stored content of this file. It should be noted that although in the example of Figa shows only eight files GOITER (AOW files)in the directory of the source of the sound data (SD Audio) can store a maximum of 999 files GOITER (AOW files).

In the case when playback data you want to protect the copyright in the field of identification, create a subdirectory with the name "directory of the source of the sound data (SD-Audio)", and in the same directory as the source of the sound data (SD Audio) create a file "AOBSA1.KEY"in which to store the encryption key.

On Figb shows the file AOBSA1.KEY" storage encryption key, katalysatoren under the symbol "original sound data (SD Audio)" (i.e., inside the "directory of the source of the sound data (SD Audio)"). In this file AOBSA1.KEY" storage encryption key, remember the sequence of encryption keys, which is created by the location of the multiple encryption keys in a predetermined order.

The directory of the source of the sound data (SD Audio), shown in Figa and Figb, remember in a computer server that is administered by the record company that distribute music electronically. When the user carries out the order of the musical information corresponding to the directory of the source of the sound data (SD Audio) compress, encrypt and transmit the user through the public network. The computer of the user assumes this directory is the source of the sound data (SD Audio), decrypts it, unfolds it compressed data and thus receives the original directory of the source of the sound data (SD Audio). It should be noted that the term "public network" here refers to any kind of network that can be used by consumers, for example, to the network wired connection, such as digital communication network integrated services (CSCW) (ISDN), or wireless communication network such as the Internet and mobile telephony. It is also possible, in which the computer user carries out a file download GOITER (AOW file) from the computer server, driven by the e which carries the record company, and then creates in the circuit Board 31 flash memory directory of the source of the sound data (SD Audio), similar to that shown in Figa and Figb.

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

Figure 9 shows the correspondence between file "AOBSA1.KEY" in the same directory as the source of the sound data (SD-Audio) files GOITER (sound objects) (AOW files). Shown in Fig.9 keys files (FileKeys)used when encrypting files in the user area, remember in the corresponding file storing the encryption key in the identification.

According encrypted files GOITER (AOW files) and file storage encryption key is set according to predefined rules (1), (2)and (3)described below.

(1) File storage encryption key is in the directory with the same directory name as the directory in which you stored the encrypted file. In accordance with this rule is depicted in Fig.9 files GOITER (AOW files) are in the same directory as the source of the sound data (SD Audio) in the user area, and a file storing the encryption key is in the directory that has the name of the directory the source of the sound data (SD Audio) and is located in the area of identification.

(2) File storage encryption key assigned file name is created by combining the first three characters of the filename file GOITER (AOW files)located in area d is the R, with a pre-defined extension ".key" ("key"). When the file GOITER (AOW file has the file name "AOB001.SA1", the file storing the encryption key, assign the file name "AOBSA1.KEY", created by adding the first three characters "AOW", "SA1"and extension ".key", which is shown in Fig.9 arrows nk1 and nk2.

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

"Records№1, №2, №3...№8 about the keys file ("File Key Entries, #1, #2, #3 ... #8") specify the source location of the areas in which memorized the appropriate keys files (FileKeys) in the file storage of the encryption key. In this case, the file names GOITER (AOW files) assign sequence numbers"001", "002", "003", "004", .... These ordinal numbers indicate the location of the respective keys files (FileKeys) in the sequence of encryption keys so that the key file (FileKey)that was used to encrypt each file GOITER (AOW file)located in the "key file" ("FileKey Entry") under the same serial number. Figure 9 arrows Ak1, Ak2, Ak3, ... indicate the correspondence between files GOITER (AOW files and key files (FileKeys). In other words, the file "AOB001.SA1" corresponds to the key file (FileKey), the location of which in the memory specified as the recording No. 1 on the key file" ("FileKey Entryft"), file "AOB002.SA1" corresponds to the key file (FileKey), the location of which in the memory is listed as "Entry # 2-key file" ("FileKey Entry#2"), and the file AOB003.SA1" corresponds to the key file (FileKey), the location of which in space is displayed as Record No. 3 on the key file" ("FileKey Entry#3"). From rule (3) it is clear that to encrypt a variety of files GOITER (AOW files) use different keys files (FileKeys), and these keys files (FileKeys) remember in the "Records of the keys files" ("FileKey Entries") under serial numbers"001", "002", "003", "004" etc. that are specified in the file names of the corresponding CRAW.

Because each file GOITER (AOW file) encrypted using different keys file (FileKey), the declassification of the encryption key, which is used for a single file GOITER (AOW file)will not allow users to decrypt other files GOITER (AOW files). This means that when saving files GOITER (AOW files) in the circuit Board 31 flash memory is carried out in encrypted form, the damage caused by the declassification one key file (FileKey), can be minimized.

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

The following is a description of the internal structure of the file GOITER (AOW file). Figure 10 shows the hierarchical structure of the data file GOITER (AOW file). Figure 10 on the first level shows the file GOITER (AOW file), and the second level shows the sound of the howling object (GOITER) (AOW). On the third level shows BLOCKIT (AOB_BLOCKS), on the fourth level - ELEMENTAL (AOB_ELEMENT), and the fifth level - KADROV (AOB_FRAME).

Figure 10 KATZO (AOB_FRAME) on the fifth level is the smallest integral element of GOITER (AOW) and consists of audio data in ADTS format (transport stream of audio data) and the ADTS header. Audio data format ADTS encrypted in accordance with the MPEG2-AAC (with the set of parameters that provide low integration), and they represent a stream of data that can be reproduced with a transmission rate of 16 Kbits/s up to 144 Kbits/S. it Should be noted that the transmission rate for data PCM (pulse code modulation) (RSM), which is recorded on the normal CD is 1.5 Megabits/s, so that data in the format ADTS usually use a lower transmission rate than the PCM. The sequence KUDROVO (AOB_FRAMEs) has the same data structure as a sequence of audio frames contained in the transport stream of audio data, which sends the service music distribution electronically. This means that the transport stream of audio data intended for storage in a sequence KUDROVO (AOB_FRAME)code according to standard MPEG2-AAC, encrypt, and transmit to the consumer over the network General polovni is. Files GOITER (AOW file) is generated by the separation of transmitted transport stream audio data in sequence KUDROVO (AOB_FRAMEs) and memorizing these KUDROVO (AOB_FRAMEs).

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

Detailed description of the standard MPEG2-AAC contained in document ISO/IEC 13818-7:1997 (E) Information technology - Generic coding of moving pictures and associated audio information - Part 7: Advanced audio coding information (UCSI) (AAC) " ("Information Technology - Generic Coding of Moving Pictures and Associated Audio Information - Part7 Advanced Audio Coding (AAC)").

It should be noted that the compression of audio objects according to the MPEG2-AAC can only be done using the parameters from the parameter table shown in Figa, which is specified in ISO/IEC 13818-7. This table consists of the Parameter "column", column "Value", column "note".

Shown in the column "Parameter" symbol "set of parameters" indicates that it may only be used a set of parameters that provide low integration (LC profile), as stipulated by the ISO/IEC 13838-7. Legend indexnavigationbar" ("sampling_frequency#index") in the column "Parameter" indicates that can be used with the sampling frequency equal to 48 kHz, 44.1 kHz, 32 kHz, 24 kHz, 22.05 kHz and 16 kHz".

Conditional is oznaczenie "kolichestvennihyj" ("number_of_data_blok_in_frame") in the column "Parameter" specifies they use a ratio of one title for one blokada (raw_data_block).

It should be noted that, despite the fact that this note describes a variant in which the encoding KUDROVO (AOB_FRAMEs) implemented in the MPEG-AAC, instead coding KUDROVO (AOB_FRAMEs) can be carried out in accordance with a different format, such as MPEG 3 level (MPEG-Layer3) (MP3) or Windows Media Audio format (WMA) format (sound environment for the Windows operating system). In these cases, must be used the settings in the parameter tables of Figb or Figv.

{3-3_10-2_12} Structure QUADRAT (AOB_FRAME)

Despite the fact that each KATZO (AOB_FRAME) contains audio data that is encoded in accordance with the above limitations, the data length of the audio data in each CADRES (AOB_FRAME) limited playing time, is equal to only 20 MS. However, since the standard MPEG2-AAC is a method of encoding with variable baud rate (PSPD) (VBR), the data length of the audio data in each CADRES (AOB_FRAME) will change. Below is a description of the structure QUADRAT (AOB_FRAME) with reference to Fig.

On Fig on the first level shows the General structure, and the second level shows how to perform the encryption of each part QUADRAT (AOB_FRAME) can be seen From the drawing, the ADTS header corresponds to the unencrypted part. Audio data contain both encrypted portion and an unencrypted portion. The encrypted part of the audio data consists of a set of fragments with the encrypted data volume eight bytes, each of which is generated by encrypting byte of the sound fragment data using 56-bit key file (FileKey). When encoding a 64-bit fragments of audio data, the unencrypted portion of the audio data is simply the final piece of data that cannot be encrypted because it is shorter than 64 bits.

On Fig on the third level shows the contents of the header of ADTS, which is an unencrypted portion QUADRAT (AOB_FRAME). The ADTS header has a length of seven bytes and contains the 12-bit word synchronization (which is set to FFF), information about the data length of the audio data in this CADRES (AOB_FRAME), and the sampling frequency that was used to encode the audio data.

{3-3_10-3_13} sets the length QUADRAT (AOB_FRAME) in bytes

On Fig shows how each of the three FRAMES GOITER (AOB_FRAMEs) implement the installation length of audio data in bytes. On Fig audio data No. 1 (audio data#1)contained in CADRES NO. 1 (_FRAME#1)have a data length equal to x1, the sound is haunted data No. 1 (audio data#1), contained in CADRES NO. 2 (AOB_FRAME#2)has a data length equal to x2, and the sound data no. 1 (audio data#l)contained in CADRES NO. 3 (AOB_FRAME#3)has a data length equal to X3. In the case when all the data have different lengths x1, x2, and X3 of the data, the length x1 of the data recorded in the header of ADTS QUADRAT NO. 1 (AOB_FRAME#1), the length x2 of the data recorded in the header of ADTS QUADRAT NO. 2 (_FRAME#2), and the length X3 of the data recorded in the header of ADTS QUADRAT NO. 3 (AOB_FRAME#3).

Despite the fact that the audio data are encrypted, the ADTS header is not encrypted, so that the playback device can learn about the data length of the audio data in CADRES (AOB_FBAME) by reading information about the data length specified in the header of ADTS QUADRAT (AOB_FRAME).

This completes the description QUADRAT (AOB_FRAME).

{3-3_10-4} ELEMENTAL (AOB_ELEMENT)

The following is a description ELEMENTAT (AOB_ELEMENT), which is shown in Figure 10 on the fourth level.

"ELEMENTAL" (AOB_ELEMENT) is a group of consecutive KUDROVO (AOB_FRAMEs). The number KUDROVO (AOB_FRAMEs) in ELEMENTAT (AOB_ELEMENT) depends on the value set as indexcolormodel (sampling_frequency_index), which is shown in Figa, and the used encoding. The number KUDROVO (AOB_FRAMEs) in ELEMENTAT (AOB_ELEMENT) set such that the total playback time contained KUDROWS THE B (_FRAMEs) was approximately equal to two seconds, moreover, this number depends on the sampling frequency and the used encoding.

{3-3_10-5_14} Number KUDROVO (AOB_FRAMES) in ELEMENTAT (AOB_ELEMENT)

On Fig shows the correspondence between the sampling frequency and number KADROSU (AOB_FRAMEs)contained in ELEMENTAT (AOB_ELEMENT). The number N is shown in Fig, represents the duration of the playback ELEMENTAT (AOB_ELEMENT) in seconds. In the case when the encoding using the MPEG-AAC, the value N is "2".

When custodial (sampling_frequency) is equal to 48 kHz, the number KUDROVO (AOB_FRAMEs)contained in ELEMENTAT (AOB_ELEMENT), set equal to 94 (=47*2), and when custodial (sampling_frequency) 44.1 kHz, the number KUDROVO (AOB_FRAMEs)contained in ELEMENTAT (AOB_ELEMENT) set equal to 86 (=43*2). When custodial (sampling_frequency) is equal to 32 kHz, the number KUDROVO (AOB_FRAMEs) set equal to 64 (=32*2)when custodial (sampling_frequency) equal to 24 kHz, the number KUDROVO (AOB_FRAMEs) set equal to 48 (=24*2)when custodial (sampling_frequency) is equal to 22.05 kHz, the number KUDROVO (AOB_FRAMEs) set equal to 44 (=22*2), and when custodial (sampling_frequency) is 16 kHz, the number KUDROVO (_FRAMEs)contained in ELEMENTAT (AOB_ELEMENT), set equal to 32 (=16*2). However, in the case when the operation was performed editing, e.g. the measures separation GOITER (AOW), the number KUDROVO (AOB_FRAMEs)contained in ELEMENTAT (_ELEMENT) at the beginning or at the end of GOITER (AOW), may be less than the amount which is obtained by similar calculations.

Up until for each ELEMENTAT (AOB_ELEMENT) does not have a header or not provided other specific information, instead, the data length of each ELEMENTAT (_ELEMENT) will be specified in the lookup table at a time.

{3-3_10-6_15} One example of the playback duration of LAMENTOSO (AOB_ELEMENTs) AND KUDROVO (_FRAMEs)

On Fig shows one example of the playback duration of LAMENTOSO (AOB_ELEMENTS) and KUDROVO (AOB_FRAMEs). On Fig on the first level shows many BLACKOUT (AOB_BLOCKs), and the second level shows many LAMENTOSO (AOB_ELEMEMTs). On the third level shows many KUDROVO (AOB_FRAMEs).

As shown in Fig, ELEMENTAL (AOB_ELEMENT) has a duration of approximately 2.0 seconds, and KATZO (AOB_FRAME) has a duration of 20 milliseconds. "Elementar" (the table element time search) ("TMSRT_entry")assigned to each ELEMENTAT (_ELEMENT), indicates that the data length of each ELEMENTAT (AOB_ELEMENT) are given in table time search. By reference to "elementimpl" ("TMSRT_entries"), the playback device can perform the search in the forward or in the mod is coherent direction, when, for example, carry out intermittent playback of short segments by repeated playback of the sound data with a duration of 240 milliseconds, followed by skipping two seconds of audio data in the right direction.

{3-3_10-7} BLAKESON (AOB_BLOCK)

This completes the description ELEMENTAT (AOB_ELEMENT). The following is a description of the concept BLACKOUT (AOB_BLOCKs), shown at the third level of the data structure of the file GOITER (AOW file, shown in Figure 10.

Each "BLOKOV (AOB_BLOCK)" consists of the proper LAMENTOSO (AOB_ELEMENTS). Each FILETAB (AOB_FILE) there is only one BLAKESON (_BLOCK). While ELEMENTAL (AOB_ELEMENT) has a duration of about two seconds, BLAKESON (AOB_BLOCK) has a maximum duration equal to 8.4 minutes. Limitation 8.4 minutes imposed in order to limit the amount of table time search value 504 bytes or less.

{3-3_10-8} Restrictions on table search time

Below is a detailed description of why limit the amount of table time search by limiting the duration of playback.

When the playback device performs the search in the forward or in the reverse direction, the playback device before playback within 240 Millie the und, does skipping the reading of audio data within two seconds. When you pass two seconds of data, the playback device could theoretically make accessing information about the data length specified in the header ADTS KUDROVO (AOB_FRAMEs), although this would mean that the implementation passes only two seconds of audio data, the playback device needs to perform coherent detection 100 (2 seconds /20 milliseconds) KUDROVO (AOB_FRAMEs). This would lead to an excessive load when performing processing in the playback device.

To reduce the processing load in the playback device read address for the data intervals for two seconds can be recorded in a lookup table at a time, which then performs the conversion of the playback device when the search is in the forward or in the reverse direction. Performing the recording of information, which allows rapid detection of the address read across two or four seconds in the direct or reverse direction, the lookup table according to the time such information is the volume of data LAMENTOSO (_ELEMENTS)), when a search is performed in the forward or in the reverse direction, the playback device is simply to perform the treatment of this information. The amount of data to zvukovoy the data having a duration equal to two seconds, will depend on the transmission speed of binary data, which is used when reproducing the audio data. As indicated previously, use the baud rate in the range of 16 kbps (kilobits per second) up to 144 kbit/s, so the amount of data reproduction are carried out for two seconds, is in the range from 4 KB (=16 Kbit/s x 2/8) to 36 kbps (=144 Kbit/s x 2/8). Since the amount of data reproduced two seconds is in the range from 4 kbps to 36 kbps, the data length of each element in the lookup table in time to record the data length of the audio data must have a length of two bytes (=16 bits). This is because through 16-bit values, you can display a number in the range 0-64 KB.

However, if there is a need to total the table data search was limited to 504 bytes (it is equal to the amount of data TMVGPBR (TKTMSRT), as described below), then, for example, the maximum number of table entries search time can be calculated as 504/2=252.

Because the item record create every two seconds, the playback time corresponding to a maximum number equal to 252 elements, is 504 seconds (=2C*252), or, in other words, 8 minutes and 24 seconds (=8.4 minutes). This means that the installation max the maximum duration of play for BLOCAT (_BLOCK), equal to 8.4 minutes, limits the amount of data of the lookup table at time 504 bytes.

{3-3_10-9} Description sound objects (GOITER) (AOBs)

This complete description BLOCKOUT (AOB_BLOCKs). The following is a description of GOITER (audio objects (AOBs).

GOITER (AOW), shown at the second level of Figure 10 represent the areas that have both ends implausible plots. In each file GOITER (AOW file) is only one CROP (AOW).

Wrong areas represent the areas that are read and written together with BLOOMIT (AOB_BLOCKs) and stored in the same cluster, and that BLOCKIT (AOB_BLOCKs). Start and end positions of blocks GOITER (AOB_BLOCKs) GOITER (AOW) is indicated by TIB (tables information block) (BITs)contained in the navigation data. A detailed description of these TIB below.

This completes the explanation of what information is remembered in the file GOITER (AOW file). The following is a description of what content plays in sequential reading of these eight GOITER (AOW) and Blackout (AOB_BLOCKs), shown in the file GOITER (AOW file) from Fig.9.

{3-3_10-10_16}

On Fig shown reproducible content in sequential reading GOITER (AOW) and Blackout (AOB_BLOCKs) in this file GOITER (AOW file). On Fig on the first level shows the eight files GOITER (AOW files) in the user area, and the second level shows eight GOITER (AOW, recorded in these files GOITER (AOW files). On the third level shows the eight BLACKOUT (AOB_BLOCKs)contained in these GOITER (AOW).

On the fifth level shows the headlines of the five parts of the content of the educated these files GOITER (AOW files). In this example, "elements of information content are five songs: "Song A" (SongA), "Song B" (SongB), "Song" (SongC), "Song D" (SongD) and "Song D" (SongE), and "musical work" is a music album consisting of these five songs. Dotted lines AS1, AS1, AS3, ... AS7 and AS8 indicate the correspondence between Bloomit (_BLOCKs) and those parts that divided the album, and on the fourth level Fig shows the units that were used to split the music album shown on the fifth level.

With reference to the dotted line, you may notice that BLAKESON (AOB_BLOCK)contained in the CRAW No. 1 (AOW#1), is a song (Song A) (SongA), the duration of which is equal to 6.1 minutes. BLAKESON (_BLOCK)contained in the CRAW No. 2 (AOW#2), is a song (Song B) (SongB), the duration of which is equal to 3.3 minutes. BLAKESON (_BLOCK)contained in the CRAW No. 3 (AOW#3), is a song (Song) (SongC), the duration of which is equal to 5.5 minutes. Thus, each of the files with "AOB001.SA1" AOB00.SA1" corresponds to different songs. The sixth level on Fig is a sequence of phonograms composed of phonograms from A Phonogram (TrackA) and ending with the "Phonogram D" (TrackE). These soundtracks with "Soundtrack And" Phonogram D" (TrackA-TrackE) correspond to the five songs: "Song A" (Son-gA), "Song B" (SongB), "Song" (SongC), "Song D" (SongD) and "Song D" (SongE), each of which is considered a separate unit of playback.

On the other hand, GOITER No. 4 (AOW#4) has a duration equal to 8.4 minutes, and represents the first (or "primary") part of the song "Song D" (SongD)having a duration equal to 30,6 minutes. BLOCKIT (AOB_BLOCKs)contained in the CRAW No. 5 (AOW#5) and the CALL No. 6 (AOW#6)is the average parts of the song "Song D" (SongD) and also have a duration equal to 8.4 minutes. BLAKESON (_BLOCK)contained in the CRAW No. 7 (AOW#7), represents the final part of the song "Song D" (SongD) and has a duration equal to 5.4 minutes. Thus, the song, which has a total duration equal to 30,6 minutes, divided into parts (8,4+8,4+8,4+5.4 minutes), each of which is contained in various GOITER (AOW). From Fig can be seen that the maximum duration of display for each song contained in the file GOITER (AOW file)cannot be more than 8.4 minutes.

This explanation clearly shows that the description of the Noah higher limit playback of the audio objects (GOITER) (AOW) limits the amount of data of the lookup table on time associated with each CROP (AOW). Below is a description of the navigation data contained in each table time search.

{3-A, IN-2}

Navigation data consist of two previously mentioned files "SD_Audio.PLM" and "SD_Audio.TKM". file SD_Audio.PLM" contains the administrator of the playlist (PlaylistManager), and the file "SD_Audio.TKM" contains the administrator of phonograms (TrackManager).

As mentioned in the description section relating to the reproduced data, the encoded GOITER (AOW) remember many files GOITER (AOW files), but they do not contain any other information about, for example, the playback duration of GOITER (AOW), song titles displayed GOITER (AOW), or on the list of songwriters. Despite the fact that many GOITER (AOW) write many files GOITER (AOW files), does not provide any guidance regarding how to play GOITER (AOW). To ensure the transfer of such information to the playback device provided by an administrator of phonograms (TrackManager) and administrator of the playlist (PlaylistManager).

The administrator of phonograms (TrackManager) indicates the correspondence between GOITER (AOBs), recorded in the files GOITER (AOW files), and phonograms, and contains many pieces of information management phonogram, each of which provides a lot of information the data for example, the playback duration of GOITER (AOW), the song titles and songwriters different GOITER (AOW).

In this description, the term "soundtrack" refers to content for users unit of reproduction, so that when memorizing Board 31 flash music, copyrighted, each song is a separate soundtrack. Otherwise, when in the circuit Board 31 flash memory write "announced the book" (i.e., copyrighted literature, which remain in the form of sound recordings), each Chapter or paragraph may be presented as separate tags. To manage many GOITER (AOW)recorded in multiple files GOITER (AOW files) in the form of a set of phonograms, create an administrator of phonograms (TrackManager).

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

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

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

On Fig shows a detailed hierarchical structure of the administrator of the list of playable files is (PlaylistManager) and administrator of phonograms (TrackManager) in this embodiment. On Fig shows the volume of the administrator of the playlist (PlaylistManager) and administrator of phonograms (TrackManager). In the right part Fig provides a more detailed explanation of the objects on the left, and the dotted lines indicate what objects are shown in more detail.

As shown in Fig, the administrator of phonograms (TrackManager) consists of information about the phonograms (IDF) (TKI) №1, №2, №3, №4...№n that is indicated by the dashed line h1. These IDF (TKIs) are information management GOITER (AOW)is stored in the files GOITER (AOW files) in the form of phonograms, and each of them correspond to different files GOITER (AOW files). From Fig shows that every IDF (TKI) consist of Ordainedtothenations (OFG) (Track_General_Information) (TKGI), Textolite (ADDING the data area of the text information on the soundtrack) (Track_Text_Information) (TKTXTI_DA), which can be recorded text information is designed exclusively for the soundtrack, and the lookup table of Phonograms time (TMVGPBR) Track_Time_Search_Table (TKTMSRT), which serves as a lookup table in time.

From Fig shows that every IDF (TKI) have a constant amount equal to 1024 bytes, which means that the total amount OFG (TKGI) and ADDING (TKTXTI_DA) is set to 512 bytes due to the fact that the volume TMVGPBR (TKTMSRT) is set to 512 bytes. The administrator of phonograms TrackManager) the total number of IDF (TKI) can be set to 999.

As shown by the dashed line h3, TMVGPBR (TKTMSRT) consists of SEGALOWITZ (TMSRT_HEADER) and of the Elements TPWR№1, №2, №3, ... №n (TMSRT ENTRIES#1, #2, #3 ... #n).

{17-2_19} Under IDF (TKI) files GOITER (AOW files) and GOITER (AOW)

On Fig shows how the IDF (TKI), is depicted in Fig correspond to files GOITER (AOW files) and GOITER (AOW), which is depicted in Fig. On Fig rectangles on the first level specified sequence of phonograms, which consists of phonograms with the Soundtrack And the Soundtrack D. (TrackA - TrackE), a large frame on the second level of the designated administrator of phonograms (TrackManager), and the third and fourth levels are shown the eight files GOITER (AOW files)which are listed on Fig. These eight files GOITER (AOW files) record in eight GOITER (AOW), shown in Fig, and they form a music album containing soundtracks: Soundtrack And" (TrackA), "Phonogram B" (TrackB), "Soundtrack" (TrackC),

"Phonogram G" (TrackD), and the Soundtrack D" (TrackE). The second level shows eight IDF (TKI). Rooms"1", "2", "3", "4", assigned to each IDF (TKI) is a sequence number that is used to identify each IDF (TKI), and every IDF (TKI) correspond to the file GOITER (AOW file)that is assigned the same sequence number 001, 002, 003, 004, 005 ....

With this in mind, Fig shows that the IDF No. 1 (TC#1) correspond to the file "AOB001.SA1"that the IDF No. 2 (K1#2) correspond to the file "AOB002.SA1", IDF No. 3 (TC#3) correspond to the file "AOB003.SA1, and IDF No. 4 (TKI#4) correspond to the file "AOB004.SA1". The correspondence between IDF (TKI) and Quadramet (AOB_FRAMEs) indicated on Fig arrows TA1, TA2, TA3, TA4 ....

Thus, every IDF (TKI) correspond to different GOITER (AOW)recorded in the file GOITER (AOW file), and give detailed information that applies only to the appropriate GOITER (AOW).

{17-3_20} data Structure TMVGPBR (TKTMSRT)

Below is a description of the information that relates to a single CROP (AOW)is stored in the files GOITER (AOW files), since TMVGPBR (TKTMSRT). On Fig detail showing the data structure TMVGPBR (TKTMSRT).

In the right part Fig shows a detailed data structure of the table header search time (Segelbacher) (TMSRT_Header). On Fig Segelbacher (TMSRT_Header) has a data amount equal to eight bytes, and consists of three fields. The first two bytes represent ETPR (table ID time search) (TMSRT_ID), the following two bytes are reserved, and the final four bytes represent the total Kolichestvennogo (Total_TMSRT_entry_Number).

In the field "ETPR" ("TMSRT_ID") record a unique identifier to identify TPVR. In the field "Total Kolichestvennogo" ("Total TMSRT_entry_Number") record the total number Elementor (TMSRT_entries)contained in presently used in EMA TPVR (TMSRT).

{17-3_21-1} a Concrete example TMVGPBR (TKTMSRT)

The following detailed description TMVGPBR (TKTMSRT). On Fig shows one example TMVGPBR (TKTMSRT). In the left part Fig shown GOITER (AOW), and the right side shows the corresponding TMVGPBR (TKTMSRT). GOITER (AOW) in the left part Fig consists of a set of numbered Items GOITER№1, №2, №3 ... №n (AOB_ELEMENTs#1, #2, #3 ... #n)that are located in areas with non-AR1, AR2, AR3 ... ARn depicted in the right part.

Number"0", "32000", "64200", "97000", "1203400" and "1240000" indicate the relative addresses of the areas AR1, AR2, AR3, ARn-1, FRN, occupied Elementalism (AOB_ELEMENTS), relative to the beginning of Blocat (AOB_BLOCK). For example, ELEMENTAL NO. 2 (AOB_ELEMENT#2) recorded in the same place, which is at a distance "32000" from the beginning Blocat (_BLOCK), ELEMENTAL NO. 3 (_ELEMENT#3) recorded in the same place, which is at a distance "64200" from the beginning Blocat (AOB_BLOCK), and ELEMENTAL No.(n-1) (AOB_ELEMENT#n-1) recorded in the same place, which is at a distance "1203400" from the beginning Blocat (AOB_BLOCK).

It should be noted that the distance between each occupied area and the beginning of Blocat (AOB_BLOCK) is not a multiple of any value, and this means that areas where there are Elementat (AOB_ELEMENTs), not the same size. The reason that occupied the area are of different sizes, is to use different amounts of data for encoding each is from Kudrovo (AOB_FRAME).

Since the size of the area occupied by each Elementat (AOB_ELEMENT) is different, before you skip to the beginning of Elementat (AOB_ELEMENT) need to inform the playback device about the location of each Elementat (AOB_ELEMENT) GOITER (AOW). For this TMVGPBR (TKTMSRT) create many Elementor (TMSRT_entries). Arrows RT1, RT2, RT3 ... RTn-1, RTn shows the correspondence between the regions AR1, AR2, AR3 ... ARn-1, FRN, employed every Elementat (AB_ELEMENT), and Elementimpl No. 1 (TMSRT_entry#1), Elementimpl No. 2 (TMSRT_entry#2), Elementimpl No. 3 (TMSRT_entry#3), ... Elementimpl No.(n-1) (TMSRT_entry#n-1), Elementimpl No. n (TMSRT_entry#n). In other words, in Elementp No. 1 (TMSRT_entry#1) record the size of the area AR1, busy Elementat No. 1 (AOB_ELEMENT#1), and in Elementimpl No. 2 and No. 3 (TMSRT_entry#2,#3) write down the size of the areas AR2 and AR3, which are ELEMENTAL NO. 2 (AOB_ELEMENT#2) and ELEMENTAL NO. 3 (AOB_ELEMENT#3).

As the filled area AR1 is a region from the beginning GOITER (AOW) before Elementat No. 2 (AOB_ELEMENT#2) "32000", Elementp No. 1 (TMSRT_entry#1) record size "32000" (=32000-0). Filled area AR2 is a region from the beginning Elementat No. 2 (AOB_ELEMENT#2) "32000" before Elementat No. 3 (AOB_ELEMENT#3) "64200", so Elementp No. 2 (TMSRT_entry#2) record size "32200" (=64200-32000). Filled area AR3 is a region from the beginning Elementat No. 3 (AOB_ELEMENT#3) "64200" before Elementat No. 4 (AOB_ELEMENT#4) "97000", so El is entpr No. 3 (TMSRT_entry#3) record size "32800" (=97000-64200). Similarly filled plot ARn-1 is the region from start Elementat No.(n-1) (AOB_ELEMENT#n-1) "1203400" before Elementat No. n (AOB_ELEMENT#n) "1240000"and Elementp No.(n-1) (TMSRT_entry#n-1) record size "36600" (=1240000-1203400).

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

Thus, in the table, time search is carried out record amounts of data Lamentoso (_ELEMENTs). However, since the data length of each Blocat (AOB_BLOCK) is limited to a maximum value equal to 8.4 minutes, the total number Lamentoso (AOB_ELEMENTs), contained in a single CROP (AOW), is limited to a preset number ("252", as shown in Fig) or less. As the number Lamentoso (AOB_ELEMENTS) limited, the number Elementor (TMSRT_entries), corresponding Elementat (AO_ELEMENTs), also restricted, which limits the amount TMVGPBR (TKTMSRT)containing these Elementimpl (TMSRT_entries), a preset volume. Because the amount TMVGPBR (TKTMSRT) limited, the playback device can read and use IDF (TKIs) as follows.

The playback device reads a certain GOITER (AOW) and at the beginning of the play GOITER (AOW) carries out reading of the relevant IDF (TKI) and storing them in memory. These corresponding IDF (TKI) remain in memory as long as you continue to vosproizvedeny is this GOITER (AOW). When playing GOITER (AOW) ends, carry out the reading of the next CROP (AOW), and when you start playback of this GOITER (AOW), the playback device overwrites the IDF (TKI), corresponding to the following CROP (AOW), in memory instead of the previous IDF (TKI). These following IDF (TKI) remain in memory as long as you continue to play the next GOITER (AOW).

Through such reading and memorizing IDF (TKI) the required capacity of the memory in the playback device can be minimized while simultaneously exercising the special playback functions such as search in forward and reverse direction. Although in the present embodiment described the example in which in Elementp (TMSRT_entry) write data length from the first address Elementat (AOB_ELEMENT) to the first address of the next Elementat (AOB_ELEMENT), instead, it can be written relative address from the beginning Blocat (AOB_BLOCK) to the first address Lamentoso (AOB_ELEMENTs).

{17-3_21-3} the definition of the cluster containing ELEMENTAL (AOB_ELEMENT)

Below is a description of how this may be done reading Elementat (AOB_ELEMENT) using TMVGPBR (TKTMSRT). TMVGPBR (TKTMSRT) contains the volume of each Elementat (AOB_ELEMENT), so in that case, when neobhodimosti reading Elementat No. y (AOB_ELEMENT#y), representing the first ELEMENTAL (AOB_ELEMENT) from the beginning GOITER (AOW), then calculate the cluster u, satisfying the following Equation 1, and perform the read data located offset v from the beginning of the cluster u.

Equation 1

Cluster u = (Total number Elementor from Elementat No. 1 to Elementat No.(y-1) + Sdvigne)/cluster Size

Shift v = ((Total number Elementor from ELEMENTAT No. 1 to ELEMENTAT No.(y-1) mod cluster Size

where the expression “C = a mod b” means that “C” represents a remainder obtained by dividing "a" and "b".

Sdvigne (DATA_Offset) write in TIB (BIT), a description is given below.

{17-4} ADDING (data area for textual information about the soundtrack) (TKTXTI_DA)

This completes the description of the table search time (TMVGPBR) (TKTMSRT). Below is a description of the Field data Textolite (ADDING) (Track_Text_Information Data Area) (TKTXTI_DA), the recording of which is carried out in the upper part TMVGPBR (TKTMSRT).

The data area Textolite

(ADDING) (TKTXTI_DA) is used to store text information, which shows the artist name, album name, sound engineer, producer and other similar information. This area create, even when such text information does not exist.

{17-5} OFG (General information about the sound records. what the Amma) (TKGI)

The following is a description OFG (TKGI), which is recorded in the upper part ADDING (TKTXTI_DA). On Fig shows several sets of data, such as ID "IDEF" (TKI_ID) for IDF (TKI), IDF (TKI) "NDF" (TKIN), volume IDF (TKI) "OBID" (TKI_SZ), a link with the following IDF (TKI) "WKSSVC" (TKI_LNK_PTR), block attributes "TREBLED" (TKI_BLK_ATR), duration "PRITED" (DTM), the attributes of the sound data "ATTRID" (TKI__ATR), "ISCO (international standard recording code) (ISRC), and information about blocks "TIB" (BIT). It should be noted that for the sake of simplicity, on Fig shows only part of this information.

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

Below is a detailed description of the structure OFG (TKGI) with reference to Fig. The difference between Fig and Fig is that in the left part of the drawing shows a data structure OFG (TKGI), shown in Fig, and that clearly shows the structure of a bit TREBLED" (TKI_BLK_ATR), "ATTRID" (TKI_AOB_ATR) and "ISCO" (ISRC).

{17-5_22-2} EDITF (TKI_ID)

In the field "IDEF" (TKI_ID) record unique identifier for the IDF (TKI). In the present embodiment, use byte code "A4".

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

In the field "NDF" (TKIN) write down a number of IDF (TKI) in the range from 1 to 999. It should be noted that NIDF (TKIN) each IDF (TKI) is unique. In the present embodiment, as NIDF (TKIN) use R is the original memory location of each IDF (TKI) in the administrator of phonograms (TrackManager). This means that as a non IDF (TKI) for IDF No. 1 (TC#1) write "1"that, as a non IDF (TKI) for IDF No. 2 (TKI #2) write "2", and as the IDF (TKI) for IDF No. 3 (TC#3) write "3".

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

In the field "OBID" (TKI_SZ) write the amount of data IDF (TKI) in bytes. On Fig amount of data IDF (TKI) is set equal to 1024 bytes, so every IDF (TKI) in the present embodiment, have a length of 1024 bytes.

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

In the field "WKSSVC" (TKI_LNK_PTR) write NIDF IDF (TKIN TKI), which is associated with the real IDF (TKI). The following is a description of such relations between the IDF (TKI).

When the soundtrack consists of many GOITER (AOW)recorded in multiple files GOITER (AOW files), the management of these files GOITER (AOW files) operate as a single track by linking together many IDF (TKI)that correspond to these files GOITER (AOW files). To associate multiple IDF (TKI), you must specify the IDF (TKI) file GOITER (AOW file), followed by file CALL (AOW file) used in the present IDF (TKI). Therefore, in WKSSVC (TKI_LNK_PTR) write NIDF those IDF (TKIN TKI)that follow IDF (TKI), is currently in use.

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

Below is a description of the settings are performed for WKSSVC (TKI_LNK_PTR) in eight IDF (TKI), shows what's on Fig. Every information about the track, numbered # 1 to # 3 and # 8, correspond to the individual phonograms Treaty, therefore, in their WKSSVC (TKI_LNK_PTR) do not enter any information. Information about the soundtrack IDF No. 4, IDF No. 5, IDF No. 6, IDF No. 7 (TKI#4, TKI#5, TKI#6, TKI#7) correspond to the four files GOITER (AOW files), which form a phonogram G (TrackD), so WKSSVC (TKI_LNK_PTR) these IDF (TKI) indicate information about the next soundtrack. As shown in Fig arrows TL4, TL5 and TL6, WKSSVC (TKI_LNK_PTR) IDF No. 4 (TC#4) set the "IDF No. 5 (TC#5), WKSSVC (TKI_LNK_PTR) IDF No. 5 (TC#5) set the "IDF No. 6" (TKI#6), and in WKSSVC (TKI_LNK_PTR) IDF No. 6 (TKI#6) set the "IDF No. 7 (TKI#7).

As a result, the playback device can realize the conversion to WKSSVC (TKI_LNK_PTRs)that are listed in the IDF (TKI)corresponding to these four files GOITER (AOW files), figuring out in such a way that these four IDF (TKI) with IDF No. 4 (TC#4) IDF No. 7 (D#7) and these four files GOITER (AOW files) with "AOB004.SA1" AOB007.SA1" form one soundtrack. Soundtrack G (TrackD).

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

In the field "TREBLED" (TKI_BLK_ATR) write down the attributes currently used IDF (TKI). On Fig the dotted line going from TREBLED (TKI_BLK_ATR)indicate information that explains the structure of the bits TREBLED (TKI_BLK_ATR). On Fig TREBLED (TKI_BLK_ATR) display which has a length of 16 bits, and bits b3 through b15 are reserved for future use. Three bits with the bits b2 through b0 are used to specify attributes IDF (TKI).

When the entire soundtrack meet some IDF (TKI), in TREBLED (TKI_BLK_ATR) write the value "00b" (this set is hereinafter referred to as "Soundtrack"). When the same soundtrack meet several IDF (TKI), in TREBLED (TKI_BLK_ATR) first IDF (TKI) write the value of "001b" (this set is hereinafter referred to as "Start Playback" ("Head_of_Track")), TREBLED (TKI_BLK_ATRs) IDF (TKI), which correspond GOITER (AOW) in the middle of a phonogram, write the value "010b" (this set is hereinafter referred to as "Middle of Phonograms" ("Midpoint_of_Track")), and in TREBLED (TKI_BLK_ATR) IDF (TKI)that match GOITER (AOW) at the end of the phonogram, write the value "011b" (this set is hereinafter referred to as "End of playback" ("End_of_Track")). In the case where IDF (TKI) is not used, but the area IDF (TKI) exists, i.e., when there is a remote IDF (TKI), in TREBLED (TKI_BLK_ATR) write the value of "100b" (this set is hereinafter referred to as "Unused"). When IDF (TKI) is not used, and IDF (TKI) does not exist, TREBLED (TKI_BLK_ATR) write the value of "101b".

{17-5_22-8_19} Example setting TREBLED (TKI_BLK_ATR)

Below is a description of the setup value is s TREBLED (TKI_BLK_ATR) for each IDF (TKI) for example, depicted on Fig.

With reference to ATRAMI (TKI_BLK_ATR) each IDF (TKI) shows that each of the four pairs IDF No. 1 "001.SA1"), IDF No. 2 ("AOB002.SA1"), IDF No. 3 ("AOV. SA1") and IDF No. 8 ("AOB008.SA1") [TKI#1 ("AOB001.SA1"), TKI#2 ("AOB002.SA1"), TKI#3 ("AOV. SA1"), TKI#8 ("AOB008".SA1")] corresponds to a separate phonograms, because TREBLED (TKI_BLK_ATR) of each of the IDF No. 1, IDF No. 2 IDF # 3 and IDF No. 8 (TKI#I, TKI#2, TKI#3, TKI#8) is set as "Soundtrack".

TREBLED (TKI_BLK_ATR) IDF No. 4 (TC#4) is set as "Nacharam" ("Head_of_Track"), TREBLED (TKI_BLK_ATR) IDF No. 7 (TKI#7) is set as "Conectarme" ("End_of_Track"), and TREBLED (TKI_BLK_ATR) IDF # 5 and IDF No. 6 (TKI#5, TKI#6) is set as "Sredinom" ("Midpoint_of_Track"). This means that the file GOITER (AOW file) ("AOB004. SA1")corresponding to the IDF No. 4 (TC#4), is the beginning of a phonogram, the files GOITER (AOW files) ("AOB005.SA1") and ("AOB006.SA1")corresponding IDF # 5 and IDF No. 6 (TC#5, D#6)is the average parts of the soundtrack, and the file GOITER (AOW file) ("AOB007.SA1")corresponding to the IDF No. 7 (D#7) is the end tags.

Through streamlining sets IDF (TKI) and the corresponding files GOITER (AOW files) in accordance with the settings TREBLED (TKI_BLK_ATR) in the IDF (TKI) shows that the combination of the IDF No. 1 (TKI#I) and AOB001.SA1" forms the first soundtrack (the Soundtrack A) (TrackA). Similarly, the image of the totality of the IDF No. 2 (TC#2) and "AOB002.SA1" forms the second soundtrack (Soundtrack B) (TrackB), and the totality of the IDF No. (TC#3) and "AOB003.SA1" forms the third soundtrack (Soundtrack) (TrackC). The totality of the IDF No. 4 (TC#4) and "AOB004.SA1" forms the first part of the fourth phonograms (Phonograms G) (TrackD), together IDF No. 5 (TC#5) "AOB005.SA1 and IDF No. 6 (TC#6) "AOB006.SA1 form the middle part of the Phonogram G (TrackD), a combination of the IDF No. 7 (TKI#7) and "AOB007.SA1" forms the end portion of the Phonogram G {TrackD). Finally, the totality of the IDF No. 8 (CC#8) and "AOB008.SA1 constitutes the fifth soundtrack (Soundtrack D) (TrackE).

{17-5_22-9} PRITING (DTM)

In the field "PRITED" (DTM) IDF (TKI) record the duration of playback (song), consisting of GOITER (AOW), that recorded in the corresponding IDF (TKI) file GOITER (AOW file).

When the soundtrack consists of many IDF (TKI), in PRITING (DTM) first IDF (TKI)corresponding to the playback, record the total duration of playback, and the playback time of the corresponding GOITER (AOW) recorded in the second and subsequent IDF (TKI) tags.

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

In the field "ATTRID" (TKI__ATR) IDF (TKI) write down the conditions of encoding that was used when creating GOITER (AOW), that is, information such as (1) the sampling frequency, which was implemented discretization GOITER (AOW), recorded in the appropriate file GOITER (AOW file), (2) the baud rate and (3) the number of channels. On Fig by dashed lines from "ATTRID" (TKI_AOB_AR), shows the structure ATRTED (TKI_AOB_ATR) in bits.

As shown in Fig, ATTRID (TKI_AOB_ATR) consists of 32 bits, and the encoding mode write chetyrehsetovom field with bits b16 for a bit b19. In that case, when the encoding GOITER (AOW) carried out in accordance with the MPEG-2 AAC (ADTS header), this field is write the value "0000b", and when the encoding GOITER (AOW) carried out in accordance with the MPEG 3rd level (MPEG Layer 3) (FRN), then it writes the value "0001b". When coding the CALL (AOW) implemented in the format of a sound environment for the Windows operating system (Windows Media Audio) (W), this field records the value "0010b".

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

The sampling rate used when encoding GOITER (AOW), record in the field of four bits between bit bit b7 and b4. When the sampling frequency is 48 kHz, then this field record set to "0000b". When the sampling frequency is 44.1 kHz, the value is equal to "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 sample rate of 22.05 kHz, this value is "0100b", and when the sampling frequency is 16 kHz, this value is "0101b".

The number of channels recorded in a field of three bits from the bit b3 to the bit b1. In that case, when using a single channel (i.e., mono mode), this field is write the value "000b", and when using two channels (stereo mode), this field record set to "001b".

Box of twelve bits from bits b31 to 20 bits, and bits b0, are reserved for future use.

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

In AIFG (TKGI) write ISCO (International Standard Code of Accounts) (ISRC). On Fig content ISCO (ISRC) is shown by dashed lines from the fields "ISRC". As shown in the drawing, ISCO (ISRC) consists of ten bytes, and Code zapisywai the th element (Recording-item code (No. 12) write in a field of four bits between bit bit b4 and b7. Entryid/Code item being recorded (Recording code/Recording-item code) (No. 11) record in the field of four bits between bit bit b8 and b11.

Entryid (ISCO№10, №9, №8) (ISRC#10, #9, #8) write in a field of twelve bits between the bit b2 bit and b23. Code year of entry (Year-of-Recording code (ISCO No. 6, No. 7) (ISRC#6, #7) record in the field of eight bits from bits to bits b24 b31.

Code first owner (First Owner Code (ISCO№3, №4, №5) (ISRC #3, #4, #5) record in the field of six bits between bit b32 and a bit b37, in a field of six bits between bit b40 and a bit b45, and in a field of six bits between bit b48 and a bit b53. Country code (Country Code) (ISCO№1, №2, №3) (ISRC #1, #2, #3) record in the field of six bits between bit b56, and a bit b61 and in the field of six bits between bit b64 bit and b69. One-bit flag validity (Validity flag) record in the field of one-bits consisting of bits b79. Detailed description ISCO (ISRC) can be found in the document 1303901:1986 Technical documentation International standard registration code (ISCO)" ("Documentation-International Standard Recording Code (ISRC)").

{17-5_22-A-1} TIB (BIT)

"Table of information about blocks" (TIB) (BIT) is a table for managing Blockout (AOB_BLOCK), the detailed structure of which is shown in Figa and Figb.

As shown in Figa, TIB (BIT) consists of a field SDVIGNE (DATA_OFFSET), which occupies an area of 60-th byte in the 63rd byte field OBEDENNYH ("amount of data" -(SZ_DATA), which occupies an area of 64 the AIT on the 67th bytes field KOLHAPUR (“number of elements in the lookup table time (TPVR)” (TMSRTE_NS), which occupies an area of 68 bytes at the 71st byte field Kolker (“the number of frames in the first element TPWR” (FNs_1st_TMSRTE), which occupies an area of 72-th byte in the 73rd byte field COOLER ("the number of frames in the last element TPWR" (FNs_Last_TMSRTE), which occupies an area of 74-th byte in the 75th byte field Kolkasrags (“the number of frames in secondary elements TPWR” ((FNs_Last_TMSRTE), which occupies an area of 76-th byte in the 77-th byte, and field PRODOLZHEN ("duration time" - approx. translator) (TIME_LENGTH), which occupies an area of 78-th byte in the 79th bytes.

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

{17-5_22-A-2} SDVIGNE (DATA_OFFSET)

In the field "SDVIGNE" (DATA_OFFSET) record the relative start address Blocat (AOB_BLOCK) in relation to the border between clusters as the value, specified in bytes. It specifies the size of the inactive area between GOITER (AOW) and Block GOITER (AOB_BLOCK). One example of this is the following: when the user performs the recording of a radio in the circuit Board 31 of the flash memory in the form of GOITER (AOW) and want to remove the initial part of a phonogram, in which the leading music transfer said during the introduction to the song, SDVIGNE (DATA_OFFSET) TIB (BIT) can be installed as is the reproduction of a phonogram shall carry out without the part, which contains the voice leading music gear.

{17-5_22-A-3} OBEDENNYH (SZ_DATA)

In the field "OBEDENNYH" (SZ_DATA) write data length Blocat (AOB_BLOCK), expressed in bytes. The size of the inactive area, after Blocat (AOB_BLOCK), can be found by subtracting the volume of the file (which is a multiple integer of the cluster size) the values obtained by adding ABOUT DATA (SZ_DATA) and Digan (DATA_OFFSET).

{17-5_22-A-4} KOLHAPUR (TMSRTE_Ns)

In the field "KOLHAPUR" (TMSRTE_Ns) record the total number of Items TPVR (TMSRT_Entries)contained in Blakeson (_BLOCK).

{17-5_22-ZA-5} "Kolker" (FNs_lst_TMSRTE), "Cooler" (FNs_Last_TMSRTE), "Kolker" (FNs_Middle_TMSRTE)

In the field "Kolker" (FNs_lst_TMSRTE) record the amount Kudrovo (AOB_FRAMEs)contained in Elementat (_ELEMENT), which is located at the beginning of the currently used Blocat (AOB_BLOCK).

In the field "Cooler" (FNs_Last_TMSRTE) record the amount Kudrovo (AOB_FRAMEs)contained in Elementat (AOB_ELEMENT), which is located at the beginning of the currently used Blocat (AOB_BLOCK).

In the field "Kolker" (FNs_Middle_TMSRTE) record the amount Kudrovo (_FRAMEs)contained in each Elementat (AOB_ELEMENT), except for those at the beginning and end of the currently used Blocat (AOB_BLOCK), that is, in telemental (AOB_ELEMENTs), located in the middle of Blocat (_BLOCK).

In the field "PRODOLZHEN" (IME_LENGTH) record duration Elementat (AOB_ELEMENT) shown in Figs format with milliseconds. As shown in Figs, field PRODOLZHEN" (TIME_LENGTH) has a length of 16 bits. In that case, when using the method of encoding according to the MPEG-AAC or MPEG 3 level (MPEG-LAYER3), duration Elementat (AOB_ELEMENT) is two seconds, so in the "PRODOLZHEN" (TIME_LENGTH) write the value of "2000".

{17-5_22-V}

On Figb shows the number Kudrovo (AOB_FRAMEs)specified in "Kolker" (FNs_Middle_TMSRTE). On Figb, as well as Fig, shows the relationship between castoroides and number Kudrovo (AOB_FRAMEs)contained in Elementat (AOB_ELEMENT), which is in the middle Blocat (AOB_BLOCK).

The relationship between the sampling frequency and the number of frames contained in Elementat (AOB_ELEMENT), shown in Figb is the same as that which is shown in Fig, namely, the number of frames in Elementat (AOB_ELEMENT) depends on the sampling frequency. The number of frames recorded in "Kolker" (FNs_lst_TMSRTE) and "Cooler" (FNs_Last_TMSRTE) is essentially equal to the number recorded in the "Kolker" (FNs_Middle_TMSRTE), however the beam, when Elementat (AOB_ELEMENTS) at the beginning and/or end Blocat (AOB_BLOCK) there is inoperative plot, the values specified in "Kolker" (FNs_lst_TMSRTTE) and/or "Cooler (FNs_Last_TMSRTE)" differ from the values in "Kolker" (FNs_Middle_TMSRTE).

{17-5_22-14_24} Example memorized Elementat (AOB_ELEMENT)

On Fig shows clusters with 007 th E th, in which it is remembered GOITER (AOW), which consisted of Elementool with Elementat No. 1 (AOB_ELEMENT#1) ELEMENTAL NO. 4 (_ELEMENT#4). Below is a description of the parameter settings in the TIB (BIT) for the case when memorizing GOITER (AOW) is executed as shown in Fig. Elementit with Elementat No. 1 (AOB_ELEMENT#1) ELEMENTAL NO. 4 (_ELEMENT#4), remembering which implemented in clusters with cluster 007-th cluster E marked on Fig triangular flags, and IDF (TKI) for each of Elementool with Elementat No. 1 (AOB ELEMENT#1) ELEMENTAL NO. 4 (AOB_ELEMENT#4) is set to Elementor (TMSRT_Entries).

In this example, the first part Elementat No. 1 (_ELEMENT#1)at the beginning of GOITER (AOW), stored in the cluster 007, and the last part Elementat No. 4 (AOB_ELEMENT#4)at the end of GOITER (AOW), stored in the cluster I. Elementat (AOB_ELEMENTs) # 1 to # 4 occupy the area from md0 in the cluster 007 to md4 in the cluster I. As shown in Fig arrow sdl OBEDENNYH (SZ DATA) TIB (BIT) indicates that ELEMENTAT (AOB_ELEENTS) # 1 to # 4 occupy the area from the start of the cluster 007 until the end of the cluster E, but it does not indicate that the clusters 007 and E are inactive areas ud0 ud1 and who are not employed Elementat (AOB_ELEMENT).

On the other hand, GOITER (AOW) also contains lots ud0 ud1 and located in clusters 007 and E, but not occupied by the Element GOITER NO. 1 (_ELEMENT#1) or Elementat No. 4 (AOB_ELEMENT#4). Specified in TIB (BIT) Sdvigne (DATA Offset) specifies the length of the unoccupied area ud0, exactly, is the location of the beginning of Elementat No. 1 (_ELEMENT#1) relative to the beginning of the cluster 007.

As shown in Fig, ELEMENTAL NO. 1 (AOB_ELEMENT#1) covers an area from md0 in the cluster 007 to md1 cluster 008.

This ELEMENTAL NO. 1 (AOB_ELEMENT#1) does not occupy the entire cluster 008, while the rest of the cluster is ELEMENTAL NO. 2 (AOB_ELEMENT#2). ELEMENTAL NO. 4 (AOB_ELEMENT#4) occupies the area from md3, located in the middle of the cluster 00C to md4, located in the middle of the cluster I. Thus can be done memorizing Lamentoso (AOB_ELEMENTs) across the borders of the clusters, or, in other words, the recording Lamentoso (AOB_ELEMENTs) can be carried out without regard to boundaries between clusters. "Kolker" (FNs_lst_TMSRTE) TIB (BIT) specifies the number of frames in Elementet No. 1 (AOB_ELEMENT#1), which is located in clusters 007 and 008, and "Cooler" (FNs_Last_TMSRTE) TIB (BIT) specifies the number of frames in Elementet No. 4 (AOB_ELEMENT#4), which is located in clusters with 00C th E th.

Under the NYM method can be carried out free accommodation Lamentoso (AOB_ELEMENTS) without regard to the boundaries between clusters. TIB (BIT) provides the information indicating the offset from the border of the cluster to Elementat (_ELEMENT) and the number of frames in each Elementat (AOB_ELEMENT).

{17-5_22-14_25} using the number of frames specified in each Elementat (AOB_ELEMENT) (part 1)

Below is a description of use contained in TIB (BIT) information on the number of frames in each Elementat (AOB_ELEMENT). This is the number of frames specified in TIB (BIT), is used when a search is performed in the forward or in the reverse direction. As mentioned above, these operations carry out reproduction data for 240 milliseconds after previously completed a pass of the data, the duration of which is equal to two seconds.

On Fig shows how to perform the setting of the next playback QUADRAT No.(x+1) (AOB_FRAME#x+1) when doing a search in the forward direction, which begin with QUADRAT No. x (AOB_FRAME#x) in Elementet No. (AOB_ELEMENT#y) GOITER (AOB).

On Fig shows the variant in which the user selects the find operation in the forward direction during playback QUADRAT No. x (AOB_FRAME#x)contained in Elementet No. (AOB_ELEMENT#y). On Fig "t" represents the duration of the intermittent playback (here it is equal to 240 milliseconds), f(t)" indicates the number of frames corresponding to this item is abolitionniste choppy playback, "time passes" ("skip_time") specifies the length of time, a pass which must be carried out between cycles of intermittent playback (here it is equal to two seconds), f(Vremya)" ("f(skip_time)") indicates the number of frames that corresponds to that time passes. Choppy playback is carried out by repeating the following three procedures (1), (2)and (3).

(1) the playback device performs the conversion to Elementor (TMSRT_Entry) in TMVGPBR (TKTMSRT) and skips to the beginning of the symbol flag (Elementtop) (AOB_ELEMENT).

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

(3) the playback device skips to the beginning of the next character flag (Elementtop) (AOB_ELEMENT).

KADROV No.(x+1) (AOB_FRAME#x+1), which is 2 seconds + 240 milliseconds from QUADRAT No. x (AOB_FRAME#x)contained in Elementet No. (AOB_ELEMENT#y), will be in Elementet No.(y+1) (AOB_ELEMENT#y+1). When determining QUADRAT No.(x+1) (AOB_FRAME#x+1), which is 2 seconds + 240 milliseconds from QUADRAT No. x (AOB_FRAME#x), despite the fact that the Element TPVR (TMSRT_Entry) the playback device may not know about the number Kudrovo (AOB_FBAMEs)between start addresses Elementat No.(y+1) (AOB_ELEMEMT#y+1) and Quadrato No.(x+1) (AOB_FRAME#x+1), the first address of the next Elementat No.(+1) (AOB_ELEMENT#y+1) can be directly calculated by reading the Item TPVR (TMSRT_Entry) from TMVGPBR (TKTMSRT).

To calculate this number Kudrovo (_FRAMEs), you must subtract the total number of frames contained in Elementet No. y (AOB_ELEMENT#y) of the sum of (1) room No. x (number#x), which specifies the position Quadrat No. x (_FRAME#x) relative to the beginning Elementat No. y (AOB_ELEMENT#y), (2) f(t) and (3) f (time skip) (f(skip_time)"). To simplify the calculation of the relative position of the frame QUADRAT No.(x+1) (AOB_FRAME#x+l) in Elementet No.(y+1) (AOB_ELEMENT#y+1), TIB (BIT) for each Elementat (AOB_ELEMENT) write "Kolker" (FNs_lst_TMSRTE), "Kolker" (FNs_Middle_TMSRTE), and "Cooler" (FNs_Last_TMSRTE) as indicated above.

{17-5_22-A} using the number of frames specified in each ELEMENTAL (AOB_ELEMENT) (part 2)

The number of frames recorded in TIB (BIT), is also used when the playback device performs the function of search time at which playback starts at the point indicated by the time code. On Figa shows how the playback device can determine ELEMENTAL (AOB_ELEMENT) and KATZO (AOB_FRAME)corresponding to the user-specified start time of playback. In the case when you want to start playback from a user-specified point in time in the "Supised" (Jmp_Entry) set the specified time (in seconds), playback should be acato with Elementat No. (AOB_ELEMENT#y), and x QUADRAT (_FRAME), satisfying the following Equation 2.

Equation 2

A record of the transition (in seconds) = (Kolker + Kolker*y+x) *20 MS

Because "Kolker" (FNs_lst_TMSRTE) and "Kolker" (FNs_Middle_TMSRTE) contained in the AGAINST (BIT), they can be substituted into Equation 2 to calculate Elementat No. (AOB_ELEMENT#y) and QUADRAT No. x (AOB_FRAME#x). After this, the playback device can perform the conversion to TMVGPBR (TKTMSRT) GOITER (AOW) to calculate the first address Elementat No.(y+2) (AOB_ELEMENT#y+2) (which represents the (I+2)-th ELEMENTSOF (_ELEMENT) GOITER (AOW)) and, based on this first address, start the search QUADRAT No. x (AOB_FRAME#x). Upon detection of the x-th Kudrow (AOB_FRAME) the playback device starts playing from that frame. Thus, the playback device can play back data since the time specified in the Record about the transition (Jmp_Entry) (in seconds).

Thus, for playback devices there is no need to search parts of the ADTS header in Catracho (AOB_FRAMEs), and just needs to search in Elementat (AOB_ELEMENTS), which are specified in the Elements TPVR (TMSRT_Entries) from TMVGPBR (TKTMSRT). This means that the playback device can high speed to find a place to play, match play time.

Similarly,when set to Supised (Jmp_Entry), and the search function of time used for the soundtrack, consisting of many GOITER (AOW), the playback device need only perform the calculation Elementat No. (AOB_ELEMENT#y) and QUADRAT No. x (_FRAME#x)that satisfy the following Equation 3.

Equation 3

Supised (in seconds) =

Duration from GOITER No. 1 to CRAW No. n + (Kolker(No.(n+1)) + Kolkasrags(No.(n+1))*y+x)* 20 MS

The total duration of playback GOITER (AOW) with GOITER No. 1 (AOW#1) to CRAW No. n (AOW#n) is equal to:

The total duration of playback GOITER with GOITER No. 1 to CRAW # n =

["Kolker"(No. 1) + "Kolker"(No. 1) * (Number Elementor(No. 1) - 2) + "Cooler"(No. 1) + "Kolker"(No. 2) + ("Kolker"(No. 2) * The Number Elementor (No. 2) - 2) + "Cooler"(No. 2) + "Kolker"(No. 3) + ("Kolker"(No. 3) * The Number Elementor(No. 3) - 2) + "Cooler(No. 3)... + "Kolker"(No. n) + ("Kolker"(No. n) * Number Elementor(No. n) - 2) + "Cooler"(No. n)] * 20 MS

After calculating GOITER No. n (AOB#n), Elementat No. (AOB_ELEMENT#y), and QUADRAT No. x (AOB_FRAME#x)that satisfy the Equation 3, the playback device performs the conversion to TMVGPBR (TKTMSRT), corresponding GOITER no. (n+1) (AOW#n+1), finds the x-th KATZO (AOB_FRAME) from address, which is (y+2)-th ELEMENTAL (AOB_ELEMENT) (what eats what, ELEMENTAL No.(y+2) (AOB_ELEMENT#y+2)), and starts playback from that of the x-th QUADRAT (AOB_FRAME).

{17-5_22-A, B} the file is Erased CALL (AOW file) and IDF (TKI)

This completes the description of all information contained in the IDF (TKI). The following is a description of how to perform the update IDF (TKI) in the following four cases. In the first case (case 1) carry out the removal of tags. In the second case (Example 2) carry out the removal of phonograms and record a new soundtrack. In the third case (Example 3) from a variety of phonograms shall select two and combining them into one soundtrack. Finally, in the fourth case (case 4) carry out the separation of one of the phonogram and create two tags.

Below is a description of a case in which carry out the removal of tags.

On Figa and Figb shows a partial Erasure of the recording. The example shown in Figa and Figv corresponds to the administrator of phonograms (TrackManager) shown in Fig, and assume that the user has specified partial erase Phonogram B (TrackB). GOITER (AOW), corresponding to the Phonogram B (TrackB)recorded in "AOB002.SA1", which correspond to the IDF No. 2 (TKI#2). This means that wipe AOB002.SA1" accompanied by the installation in TREBLED (TKI_BLK_ATR) IDF No. 2 (TKI#2) "Unused". This is the state in which "AOB002.SA1" has been deleted, and in TREBLED (TKI_BLK_ATR) IDF No. 2 (TC#2) set the Leno is "Unused", shown in Figb. Because "AOB002.SA1" was removed, the area that was previously occupied by "AOB002.SA1", was released and became the unused area. As mentioned above, another change is that in TREBLED (TKI_BLK_ATR) IDF No. 2 (TC#2) set to "Unused".

{17-5_22-A, B} Assignment IDF (TKI) when writing a new CRAW (AOW)

Below is a description of the Case 2, in which, after Erasure of a phonogram shall record a new soundtrack.

On Figa shows the administrator of phonograms (Taskmanager) after erasing the phonogram was made several times. As shown in Figa, if you have removed the soundtrack, which correspond to the IDF No. 2, IDF No. 4, IDF # 7 and IDF No. 8 (TKI#2,TKI#4, D#7, D#8), TREBLED (TKI_BLK_ATR) these IDF (TKI) set to "Unused". Because deleting files GOITER (AOW files) perform exactly the same way as ordinary data files, update the administrator of phonograms (TrackManager) carried out simply by setting the value of "Unused" in TREBLED (TKI_BLK_ATR) corresponding IDF (TKI). This means that the IDF (TKI), in TREBLED (TKI_BLK_ATRs) which is set to "Unused" can occur in various places of the administrator of phonograms (TrackManager).

On Figb shows how to write new IDF (TKI) and file GOITER (AOW file) in the case when the Agency is the protection of phonograms (TrackManager) are IDF (TKI), TREBLED (TKI_BLK_ATR) which is set to "Unused". Like Figo, IDF No. 2, IDF No. 4, IDF # 7 and IDF No. 8 (TKI#2,TKI#4, TKI#7, TKI#8) from Figb set to "Unused".

As shown in Figb, new recorded the soundtrack consists of four GOITER (AOW). Unused IDF (TKI)that you want to write these GOITER (AOW), determined according to UPFLUSH (the directions of search soundtracks from the playlist, the default - approx. translator) (DPL_TK_SRPs) or they can be chosen arbitrarily. In the present example, the recording IDF (TKI) new phonogram use unused IDF (TKI), has rooms IDF No. 2, IDF No. 4, IDF # 7 and IDF No. 8 (TKI#2,TKI#4, D#7, TKI#8).

As one soundtrack consists of these four GOITER (AOW), ATRAMI (TKI_BLK_ATR) ICP NO. 2 (TC#2) set the "Start playback" ("Head_of_Track"), TREBLED (TKI_BLK_ATR) IDF # 4 IDF No. 7 (D#4, D#7) set the "Middle of Phonograms" ("Middle_of_Track"), and in TREBLED (TKI_BLK_ATR) IDF No. 8 (TKI#8) set the value "End_of_Track". WKSSVC (TKI_LNK_PTR) in each of these four IDF (TKI): IDF No. 2, IDF No. 4, IDF # 7 and IDF No. 8 (TKI#2, TKI#4, TKI#7, TKI#8)used for formation of a new Phonogram G (TrackD), set so that they point to the IDF (TKI), which form the next part of the Phonogram G (TrackD), in this case, as shown by arrows TL2, TL4, and TL7, WKSSVC (TKI_LNKPTR) IDF No. 2 (TKI#2) establish the value of the IDF No. 4 (TC#4), in WKSSVC (TKI_LMK_PTR) IDF No. 4 (TKI#4) set the value of the IDF No. 7 (TKI#7), and in WKSSVC (TKI_LNK_PTR) IDF No. 7 (D#7) set the value of the IDF No. 8 (TKI#8).

Then create the file "AOB002.SA1", "004.SA1", "AOB007.SA1" and "AOB008.SA1", having the same number as IDF No. 2, IDF No. 4, IDF # 7 and IDF No. 8 (TC#2, D#4, D#7, D#8), and in these four files provide memorizing four GOITER (AOW), forming a Phonogram G (TrackD).

By appropriate setting WKSSVC (TKI_LNK_PTRs) and TREBLED (TKI_BLK_ATRs), you can control this fourth soundtrack. The soundtrack G (TrackD)using the IDF No. 2, IDF No. 4, IDF # 7 and IDF No. 8 (TC#2, D#4, TKI#7, TKI#8).

As described above, when the card 31 flash memory recorded a new soundtrack, as IDF (TKI), for newly recorded soundtracks, allocate the IDF (TKI) in the administrator of phonograms (TrackManager)whose value is set as "Unused".

{17-5_22-A,B} the set IDF (TKI) when combining two soundtracks

Below is a description of the update IDF (TKI) at Association of phonograms (Example 3).

On Figa and Figb shows how to set the values of the IDF (TKI) when creating a new soundtrack by combining two of phonograms. In the example of Figa use the same administrator phonograms (TrackManager that on Fig, and it shows the case when the Association of Phonograms Is In (TrackC) and Phonograms (TrackE) one soundtrack, the user performs the editing operation.

In this case, GOITER (AOW), which correspond to the Soundtrack In (TrackC) and the Soundtrack D. (TrackE), write in files GOITER (AOW files) "AOB003.SA1" and "OW. SA1", which correspond to the IDF No. 3 (TC#3) and IDF No. 8 (CC#8), perform the overwrite TREBLED (TKI_BLK_ATRs) in IDF # 3 and IDF No. 8 (D#3, CC#8). On Figb shown TREBLED (TKI_BLK_ATR) these IDF (TKIs) after rewriting. On Figa TREBLED (TKI_BLK_ATRs) in IDF # 3 and IDF No. 8 (TKI#3,TKI#8) written as "Soundtrack", but Figb TREBLED (TKI_BLK_ATR) in the IDF No. 3 (TC#3) overwrite so that it receives the value "Nacharam" ("Head_of_Track"), TREBLED (TKI_BLK_ATR) IDF No. 8 (TKI#8) overwrite so that it retrieves the value of the "End of Playback" ("End_of_Track"). Through this rewriting TKI_BLK_ATRS, handling files GOITER (AOW files) "AOB003.SA1" and "AOB008.SA1", which correspond to the IDF No. 3 (TC#3) and IDF No. 8 (CC#8)located at the end of that exercise as a part of a phonogram, namely, the new Phonogram (TrackC). This operation simultaneously produce overwrite WKSSVC (TKI_LNK_PTR) in the IDF No. 3 (TC#3) so that they were listed IDF No. 8 (TKI#8).

It should, in particular, to draw attention to the fact that up until not implemented overwrite TREBLED (TKI_BLK_ATRs) in the IDF (TKI), do not perform any processing on the physical merging files GOITER (AOW files) "AOB003.SA1" and "AOB008.SA1". This is because each file GOITER (AOW file) is astrovan using different keys file (FileKeys), therefore, when combining files GOITER (AOW files) would need to be performed for each file GOITER (AOW file) two processes, first, to decrypt an encrypted file GOITER (AOW file), and then re-encrypt the result, which would lead to excessive processing overhead. Furthermore, combined in a similar way the file GOITER (AOW file) is encrypted using only one key file (FileKey), which leads to less security of the United phonogram compared with phonograms that were used for its creation.

IDF (TKI) were originally designed to reduce the amount TMVGPBR (TKTMSRT), so when the physical merging files GOITER (AOW files by editing operations there is a risk that the volume of the IDF (TKI) has become too large.

For the reasons given above when editing operations by which combine phonograms files GOITER (AOW files) remain in an encrypted state, and these operations are carried out simply by changing the attributes specified in TREBLED (TKI_BLK_ATRs).

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

As described above, the Association of phonograms is carried out by changing the attributes TREBLED (TKI_BLK_ATR), but the CALL (AOW)contained in the United phonograms should satisfy your high shall extend to the following conditions.

The first condition is that the GOITER (AOW), which forms the last part of the new phonogram must have the same attributes of the sound data (the mode of encoding audio data, the baud rate, sample rate, number of channels, etc), and GOITER (AOW), which forms the first part of the new soundtrack. In that case, if the GOITER (AOW) has the attributes of audio data different from the attributes of the previous or subsequent CROP (AOW), the playback device will resume operation of the decoder with the initial condition that complicates the whole (i.e., continuous) playback consistent GOITER (AOW).

The second condition is that the soundtrack, created by merging cannot be done linking three or more GOITER (AOW), which consist only of those Lamentoso (AOB_ELEMENTs), the number Kudrovo (_FRAMEs), which is less than the required quantity for "Kolkasrags (FNs_Middle_TMSRTE)".

GOITER (AOW) is divided into two types depending on whether it contains in itself, at least one ELEMENTSOF (AOB_ELEMENT) number Kudrovo (AOB_FRAMEs)equal to the number of frames, which caused "Kolker" (FNs_Middle_TMSRTE). GOITER 1st type (Typel AOW) contains at least one ELEMENTAL (AOB_ELEMENT), with this number Kudrovo (AOB_FRAMEs), and GOITER 2nd type (Tore the S) does not contain ELEMENTAL (AOB_ELEMENT), who has this number Kudrovo (AOB_FRAMEs).

In other words, ELEMENTAT (AOB_ELEMENTS) in the CRAW of the 2nd type (More AOW) have a number Kudrovo (AOB_FRAMEs) less than Kolker" (FNs_Middle_TMSRTE), and in the second condition stipulates that three GOITER 2nd type (More AOBs) cannot be linked together.

The reason why the second condition is the following. When the playback device performs a sequential read GOITER (AOW), preferred is the one in which the buffer of the playback device carry out the accumulation of a sufficient number Kudrovo (_FRAMEs), however, this cannot be accomplished by successive GOITER 2nd type (More AOW). In this case you can get a buffer underrun playback device, so it is impossible to guarantee that the playback device to perform continuous playback. Therefore, to avoid such devastation buffer, use the second condition, which stipulates that the following one, two, three or more GOITER 2nd type (More AOBs) cannot be linked together.

On Figa shows the CRAW of the 1st type (Type1 AOW), and Figb shows two examples GOITER 2nd type (More AOW). On Figb both GOITER (AOW) consist of not less than two Lamentoso (AOB_ELEMENTs), and none of Lamentoso (AOB_ELEMENTs) does not contain zebeta number Kudrovo (AOB_FRAMEs), which is set to "Kolker (FNs_Middle_TMSRTE)". Because no Elementat (AOB_ELEMENT), with the number Kudrovo (AOB_FRAMEs), which provides for "Kolker" (FNs_Middle_TMSRTE)is a condition that GOITER (AOW) is referred to as GOITER 2nd type (More AOW), this means that everything shown in this drawing GOITER (AOW) is a GOITER 2nd type (More AOW).

On Figa shown merging into a single soundtrack CRAW 1 type + 2 St + 2-St + 1-St type (Cure+Cure+Cure+Cure AOBs). Because this Association does not include the linking between the three GOITER 2nd type (More AOW), these GOITER (AOW) can be linked together, forming a single soundtrack.

On Figb shows the binding into a single soundtrack GOITER 1st + 2nd + 2nd + 2nd + 1-th type (Cure+Cure+Cure+Cure+Cure AOBs). Such a Union would lead to the presence of three successive GOITER 2nd type (More AOW) and is therefore prohibited.

{17-5_22-A, B-1_32} Association of Phonograms taking into account the combinations CRAW 1 type and 2-type (Type1, Type2 AOBs)

When combining GOITER (AOW) into a single soundtrack, which is shown in Figa, if the last GOITER (AOW) in the first soundtrack is a GOITER of the 1st type (Type1 AOW), the joining can be carried out regardless of whether the first part of this soundtrack the CRAW of the 1st type (Type1 AOW) Il the CRAW of the 2nd type (Type2 AOW). On Figa shows the variant in which the last GOITER (AOW) is the first of a phonogram is a GOITER of the 1st type (Type1 AOW), and the first CROP (AOW) the following phonograms is also a GOITER of the 1st type (Type1 AOW). On FIGU shows the variant in which the last GOITER (AOW) is the first of a phonogram is a GOITER of the 1st type (Type1 AOW), and the first CROP (AOW) following a phonogram is a GOITER 2nd type (Type2 AOW). Since both of these options satisfy the second condition, shown phonogram may be combined into a single record.

In the case when the last GOITER (AOW) is the first of a phonogram is a GOITER 2nd type (More AOW), and previous CROP (AOW) is the first of a phonogram is a GOITER of the 1st type (Type1 AOW), this is the first soundtrack can be combined with the next track, which begins with the CRAW of the 1st type (Type1 AOW) regardless of whether the first GOITER (AOW) in the first soundtrack Goiter 1st type (Type1 AOW) or Goiter 2nd type (More AOW).

On FIGU shows the case in which the first soundtrack ends with the Craw of the 1st type (Type1 AOW) and Goiter 2nd type (More AOW) in that order, and the second the soundtrack begins with the CRAW of the 1st type (Type1 AOW). On Figg shows the case in which the first soundtrack ends with the Craw of the 1st type (Type1 AOW) and Goiter 2nd type (More AOW) in that order and the second the soundtrack begins with the CRAW of the 2nd type (More AOW) and the CRAW of the 1st type (Type1 AOW) in that order. Since both of these cases satisfy the second condition, shown phonogram may be combined into a single record.

In the case when the first soundtrack ends with Goiter 2nd type (More AOW), and directly preceding CROP (AOW) is also a GOITER 2nd type (More AOW), this is the first soundtrack can be combined with the next track starts with GOITER 1st type (Type1 AOW). On Figg shows the case in which the first soundtrack ends with two GOITER 2nd type (More AOW), and the second the soundtrack begins with the CRAW of the 1st type (Type1 AOW). Because this case satisfies the second condition,

it depicts a phonogram may be combined into a single soundtrack. Thus, when combining two phonograms perform an analysis of whether these two soundtracks to the first and second conditions, and the combination of these two phonograms carried out only in case, if the decision is that they satisfy these conditions.

Below is a description of the update IDF (TKI) for Example 4, in which the separation of the recording.

{17-5_22-SA, B} set options for IDF (TKI), in case of division of a phonogram

On Figa and Figb shows examples of division one of the phonogram with the creation of two new phonograms. In these examples, the administrator of phonograms (TrackManager) has the same content as the administrator, shown in Fig, thus assume that the user has carried out the editing operation by which the Phonogram In (TrackC) is divided into two new soundtracks, namely, the Soundtrack In (TrackC) and Phonogram E (TrackF). When the Soundtrack In (TrackC) must be divided by the new phonograms: Phonogram (TrackC) and Phonogram E (TrackF), then create a file GOITER (AOW file) "AOB002.SA1"corresponding to the Soundtrack E (TrackF). On Figa shown that in the IDF No. 2 (TKI#2) set to “Unused”, and these IDF No. 2 (TKI#2} assign the newly created file GOITER (AOW file) "AOB002.SA1".

{17-5_22-SA, B-A, B} Update catalog items and values TRF (FAT)

In that case, when you have to create "AOB002.SA1" carry out the separation of the file GOITER (AOW file) "AOB003.SA1", it is necessary to update the catalog items and values TRF (FAT). The explanation of this update below. On Figa shows how the recorded catalog item source of the sound data (SD AUDIO) in the same directory as the source of the sound data (SD Audio)to which the file belongs GOITER (AOW file) "AOB003.SA1"to split the file.

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

In the case when the file division GOITER (AOW file) "AOB003.SA1" carried out in such a way that its last part was a new file GOITER (AOW file) "AOB002.SA1", in the directory entry of the original sound data (SD Audio) add "filename", "file name extension" and "the number of the first cluster in the file for the new file GOITER (AOW file) "AV. SA1". On Figa shows how accomplished recording element catalog the source of the sound data (SD Audio) in the same directory as the source of the sound data (SD Audio)to which the file belongs GOITER (AOW file) "AOB003.SA1", after splitting the file GOITER (AOW file) "AOB003.SA1".

In the cluster 00F shown in Figb, the saved copy of the cluster 00AM, which contains the boundary specified by the user when the file division. Part of the file GOITER (AOW file) "AOB002.SA1"that follow the part contained in the cluster 00AM, remember as before in clusters, 00C, 00D, E. Since the first part of the file GOITER (AOW file) "AOB002.SA1" stored in the cluster 00F, a remaining portion stored in clusters, 00C, 00D, E, then in the "number of the first cluster in the file for the new file GOITER (AOW file) "AOB002.SA1" write value "00F", and as values TRF (FAT) 00F, 00C, 00D, E, which correspond to clusters 00F, 00C, 00D and E, write values (00C), (00D), (E).

{17-5_22-SA, B-A, B} Set Zn the values of information fields in the IDF (TKI)

The following is a description of how to implement the installation of the values of information fields in the IDF (TKI) for file GOITER (AOW file) "AOB002.SA1" when creating this file by updating the catalog items and values TRF (FAT). When creating IDF (TKI) for the split of the phonogram in the IDF (TKI) there are two types of information fields. They are (1) information that can be copied from the original IDF (TKI) and (2) the information obtained by updating the information in the original IDF (TKI). ADDING (TKTXTI_DA) AND ISCO (ISRC) belong to the first type, and TIB (BIT), TMVGPBR (TKTMSRT) and other information fields belong to the second type. Since there are both types of information, in the present embodiment, IDF (TKI) for the split of the phonogram create by copying the original IDF (TKI) to create a template for the new IDF (TKI), and then perform the division/update TMVGPBR (TKTMSRT) and TIB (BIT) in the template and update the other fields.

On Figa shows an example in which the separation QUADRAT (AOB_FRAME) GOITER (AOW). On Figa on the first level depicts four Elementat (AOB_ELEMENTs), namely, ELEMENTAL NO. 1, ELEMENTAL NO. 2, ELEMENTAL No. 3 and ELEMENTAL NO. 4 (AOB_ELEMENT#1, AOB_ELEMENT#2, AOB_ELEMENT#3, AB_ELEMENT#4). The length of these Lamentoso (AOB_ELEMENTs) installed in TMVGPBR (TKTMSRT) through four Elementor No. 1, No. 2, the 3 and No. 4 (TMSRT_Entries #1, #2, #3, #4). If, as shown in Figa, the boundary separating gr (bdl) is Elementet No. 2 (AOB_ELEMENT#2), ELEMENTAL NO. 2 (AOB_ELEMENT#2) is divided into the first area (1), consisting of a frame located to the border gr (bdl), and the second area (2), consisting of the frames located after the border gr (bdl). On Figb shows these two GOITER (AOBs), GOITER No. 1 and GOITER No. 2 (AOB#1, AOW#2), obtained by dividing GOITER (AOW) in half through ELEMENTAL NO. 2 (_ELEMENT#2).

{17-5_22-SA,B-3_36} Set parameters TIB (BIT)

On Fig shows how to perform the installation parameters TIB (BIT) in the case where the separation GOITER (AOW) is carried out as shown in Fig. Division GOITER (AOW), shown in Fig carried out along the border Gr (bdl). GOITER No. 1 (AOW#1)created by this separation, contains two Elementat (AOB_ELEMENTs), ELEMENTAL NO. 1 (AOB_ELEMENT#1) and ELEMENTAL NO. 2 (AOB_ELEMENT#2), and the other CRAW No. 2 (AOW#2)created by this division contains three Elementat (AOB_ELEMENTs), ELEMENTAL NO. 1 (AOB_ELEMENT#1), ELEMENTAL NO. 2 (AOB_ELEMENT#2) and ELEMENTAL NO. 3 (AOB_ELEMENT#3).

On Fig these Elementat (AOB_ELEMENTs) also indicated the triangular boxes to specify the set parameters Elementor (TMSRT_Entries)contained in the IDF (TKI)that meet these GOITER (AOW). The description will first be considered GOITER No. 1 (AOB#1), which is obtained by this separation. LEMENTAL NO. 1 (AOB_ELEMENT#1) and ELEMENTAL NO. 2 (AOB_ELEMENT#2), contained in the CRAW No. 1 (AOB#1)located in clusters with cluster 007 on the cluster A, so treatment GOITER No. 1 (AOW#1) carried out in such a way as if it consists of clusters with cluster 007 on the cluster A. ELEMENTAL NO. 2 (AOB_ELEMENT#2) in the CRAW N1 (AOW#1) has a data length that they do not end at the end of the cluster A, and on the border gr (bdl), which is located within a cluster A, so OBEDENNYH (SZ_DATA) for GOITER No. 1 (AOB#1) is set as the amount of data from the field md0 to the border gr (bd1) in the cluster A. "Kolker" (FNs_lst_TMSRTE) for GOITER No. 1 (AOW#1) is the same as before the split, and "Colpo EPPUR" (FNs_Last_TMSRTE) for GOITER No. 1 (AOW#1) differs from the value that was used before the separation, the fact that it now shows the number of frames between the beginning Elementat No. 2 (AOB_ELEMENT#2) before the separation and boundary gr (bdl).

Below is a description of GOITER No. 2 (AOW#2), which is obtained by this separation. Contained in the CRAW No. 2 (AOW#2) ELEMENTAL NO. 1 (AOB_ELEMENT#1), ELEMENTAL NO. 2 (AOB_ELEMENT#2) and ELEMENTAL NO. 3 (AOB_ELEMENT#3) are located in clusters with cluster 00 A.M. on the cluster 007. The cluster 00F contains a copy of the content cluster A. The cause of conservation in the cluster 00F copy cluster A is that the cluster A busy Elementat No. 2 (_ELEMENT#2) from GOITER No. 1 (AOW#1), so for Elementat No. 1 (AOB_ELEMENT#1) from GOITER No. 2 (AOW#2) you must select a different cluster.

ALE IS NTTB NO. 1 (AOB_ELEMENT#1) from GOITER No. 2 (AOW#2) has such a length of the data in which its beginning is not the beginning of the cluster 00F, and on the border gr (bdl), which is located within a cluster 00F, so OBEDENNYH (SZ_DATA) for GOITER No. 2 (AOW#2) is set as the amount of data from the beginning of the cluster 00AM to the point in the middle of the cluster E plus the amount of data that part of the cluster 00F occupied Elementat No. 1 (AOB_ELEMENT#1).

The part Elementat No. 2 (AOB_ELEMENT#2) from GOITER No. 1 (AOB#1), which is contained in the copy of the cluster A stored in the cluster 00F, should be excluded from GOITER No. 2 (AOW#2), so Sdvigne (DATA_Offset) TIB (BIT) GOITER No. 2 (AOW#2) set the value equal to the volume of the part Elementat No. 2 (AOB_ELEMENT#2) from GOITER No. 1 (AOW#1), which is contained in the cluster 00F.

From Fig seen that the separation of GOITER (AOW) leads to two parts only ELEMENTAL (AOB_ELEMENT), containing the split line, and the rest Elementat (AOB_ELEMENTs)located before and after the split Elementat (AOB_ELEMENT), remain unchanged. As a result, the value "Cooler" (FNs_Last_TMSRTE) GOITER No. 2 (AOW#2) set the same as for "Elementat No. 4" (AOB_ELEMENT#4) to the separation and Kolker" (FNs_lst_TMSRTE) GOITER No. 2 (AOB#2) set the same as in Elementet No. 1 (AOB_ELEMENT#1) GOITER No. 2 (AOW#2), namely, equal to the number of frames contained in the part, which is after the boundary, obtained by dividing Elementat No. (AOB_ELEMENT#2).

{17-5_22-SA, B-4_37} set TIB (BIT)

On Fig shows a more specific example of the changes implemented in TIB (BIT) as a result of separation of the recording. In the left part Pig in the example shown, the values set in TIB (BIT) before splitting. In this TIB (BIT) Sdvigne (Data_Offset) is set to "X", OBEDENNYH (SZ_DATA) is set to "52428"and KOLHAPUR (TMSRTE_Ns) is set to "n". Kolker (FNs_lst_TMSRTE) is set to "80 frames", Kolkasrags (FNs_Middle_TMSRTE) is set to "94-m frames, and Cooler (FNs_Last_TMSRTE) set to 50 frames.

In the right part Fig shows the values set in two TIB (BIT), created by dividing the soundtrack. In the case when the GOITER (AOW), the corresponding TIB (BIT) from the left side Fig share as shown in Figa, the Offset Data (Data_0ffset) TIB (BIT) of the first soundtrack, created by division is set to "X"as the soundtrack to the division, "OBEDENNYH" (SZ_DATA) update so that it is equal to the length of the data "Q" from the beginning to the point Q separation and KOLHAPUR (TMSRTE_Ns) is set to "k", which specifies the number Elementor (TMSRT_entries from the first Elementat (TMSRT_entry) to k-Elementp (TMSRT_entry). Kolker (FNs_lst_TMSRTE) and Kolkasrags (FNs_Middle_TMSRTE) is set to "80" and "94" frames, so the mi, as in TIB (BIT) before the separation, but as the ultimate ELEMENTAL (AOB_ELEMENT) GOITER (AOW) is the first soundtrack, created by the division has a "p" Kudrovo (AOB_FRAMEs), Cooler (FNs_Last_TMSRTE) is set to "p frames".

In TIB (BIT) of the second soundtrack, created by splitting, "Sdvigne" (Data_Offset) is set to "R", "ABOUT the DATA" (SZ DATA) set equal to the value; (source OBEDENNYH "52428" - length data to the split point Q), and KOLHAPUR (TMSRTE_Ns) set equal to the value n-k+1, which is obtained by adding the number of units (for k-Elementp (TMSRT_entry), which is newly added to the result of the division) to the number Elementor (TMSRT_entries) from k- Elementat (TMSRT_entry) to the n-th Elementat (TMSRT_entry).

Values Kolkasrags (FNs_Middle_TMSRTE) and Cooler (FNs_Last_TMSRTE) set the same as in TIB (BIT) before the separation, that is, respectively, "94 frame rate of 50 frames".

First ELEMENTAL (AOB_ELEMENT) GOITER (AOW) this second soundtrack contains "94-R Kudrovo (AOB_FRAMEs), so Kolker (FNs_lst_TMSRTE) the TIB (BIT), which corresponds to the soundtrack, set the value of ' 94-R".

{17-5_22-SA, B-5_38} set TIB (BIT)

On Fig shown TMVGPBR (TKTMSRT) after separation. First of all, you'll see the explanation of set values TPVR (TMSRT). TPVR (TMSRT) first is th soundtrack contains Elements TPVR (TMSRT_entries) from the first Elementat (TMSRT_entry) GOITER (AOW) before separation on a k-th Elementp (TMSRT_entry), that is, Elementimpl # 1 to # k (TMSRT_entries#1...#k).

Here we should pay attention to the fact that ELEMENTAL # k (AOB_ELEMENT#k), which contains the boundary separating contains only the area (1), so k-th Elementp (TMSRT_entry) volume contains only those data that correspond to this region (1). TPVR (TMSRT) the second phonogram contains Elementimpl (TMSRT entries from k-Elementp (TMSRT_entry) GOITER (AOB) to split up the n-th Element TPVR (TMSRT_entry), that is, Elementimpl with Nk to # n (TMSRT_entries#k...#n). Here it should be noted that Elementp # k (AOB_ELEMENT#k)containing the boundary separating contains only the area (2), so k-th Elementp (TMSRT_entry) volume contains only those data that correspond to this area (2).

Copying IDF (TKI) is accompanied by separation and upgrading TMVGPBR (TKTMSRT) and TIB (BIT), and the creation of the IDF (TKI) for new phonograms, created by the separation will be completed immediately after you upgrade the rest of the information. Similarly, as with the Association of phonograms, decrypt files GOITER (AOB files) do not exercise, so two of the phonogram can be created by splitting the file GOITER (AOB file in its encrypted state. Since the division of the file GOITER (AOB file) does not include decryption and re-encryption, the computational load at the division of the phonogram can be reduced. This means, cytoreductive phonograms can be carried out even by a playback device with limited computational power.

This completes the description of the IDF (TKI). Below are lists of playable files.

{17-6} Administrator of the playlist (PlaylistManager)

As shown by the dotted lines h5 on Fig represented by the administrator of the playlist (PlaylistManager) consists of Informatieadvertising (IASWR) (PlaylistManager_Information (PLMGI))designed to manage a list of playable files, which are stored in the circuit Board 31 flash memory; Informatsiejobrashchatsja (SWFU) (Default_Playlist_Information (DPLI)), designed to manage all tracks stored in the circuit Board 31 flash memory, and Informatsiya№1, №2, №3, №4,... №m (IVF) (Playlistlnformation#1, #2, #3, #4...#m (PLI)). Each ISWF (PLI) represents information for a user-defined playlist. As shown by the dotted lines in h6, SWFU (DPLI) consists of Ordainments failover (OSVF) (Default_Playlist_General_Information (DPLGI)) and Castellamonte failover (UPFLUSH) №1, №2, №3, №4, ... №m (Default_Playlist_Track_Search_Pointers (DPL_TK_SRP) #1, #2, #3, #4... #m).

Mentioned here SWFU (DPLI) is different from each ISWF (PLI) as follows. While in SWFU (DPLI) must be specified all tracks stored in the Lata flash memory 52, ISWF (PLI) has no such restrictions and can be specified any number of phonograms. It offers a variety of opportunities. Typical examples of this are the ability to create user Informatises vosproizvedeniya (Playlist_Information), showing only his (her) favorite soundtracks, and save this Informatises vosproizvedeniya (Playlist_Information) in the circuit Board 31 flash memory, or the ability to automatically create Informatsiya (Playlist_Information) through a playback device, which shows only a phonogram in a particular genre, chosen from the set of phonograms stored in the circuit Board 31 flash memory, and save the resulting information about the playlist in the circuit Board 31 flash memory.

{17-7_18} the Number of reproducible lists of files and volume of data contained in them

As shown in Fig, on the same Board 31 flash memory may be made memorization of not more than 99 list of playable files. In addition, the total amount of data Informatieadvertising YUSUF) (PlaylistManager_Information (PLMGI)) and Informatsiejobrashchatsja (SWFU) (Default_Playlist_Information (DPLI)) set equal to 2560 bytes. Each ISWF (PLI) has a fixed length of 512 bytes. "UPPGIFT" (DPL_TK_SRP)contained in the playlist, the default, contains "ATRUGGLE" (attribute soundtracks from the playlist, the default - approx. translator) (DPL_TK_ATR) and "NEFFU" (number of data on the track in the playlist, the default - approx. translator) (DPL_TKIN). On the other hand, existing in ISWF (PLI) field UPPGIFT" (PL_TK_SRP) contains only "UPPGIFT" (PL_TK_SRP). Format fields ATRUGGLE (DPL_TK_ATR), NIDWU (DPL_TKIN), and NEFF (PL_TKIN) shown in Fig.

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

On Figa shows the format UPFLUSH (DPL_TK_SRP). On Figa NIDWU (DPL_TKIN) recorded with the 0-th to 9-th bit in UPFLUSH (DPI_TK_SRP), and ATRUGGLE (DPL_TK_ATR) recorded from 13 th to 15-th bit. Bits from 10 th to 12 th in UPFLUSH (DPL_TK_SRP) reserved for future use.

In NIDWU (DPL_TKIN) the recorded number of IDF (TKI), which is in UPFLUSH (DPL_TK_SRP) bits 0-th to 9-th. This allows you to accurately set IDF (TKI).

{17-B} Format UPPGIFT (PL_TK_SRP)

On Figb shows the format UPPGIFT (PL_TK_SRP). It is a field of ten bits, which record NEFF (PL_TKIN), that is, the number of IDF (TKI).

{17-A-2} Structure ATRUGGLE (DPL_TK_ATR)

The dotted line h51 and h52 on Figa coming from ATRUGGLE (DPL_TK_ATR), indicate the approximate installation option values ATRUGGLE DPL_TK_ATR). From this drawing it is clear that the installation ATRUGGLE (DPL_TK_ATR) for UPFLUSH (DPL_TK_SRP) perform the same way as the installation TREBLED (TKI_BLK_ATR) for IDF (TKI), namely, ATRUGGLE (DPL_TK_ATR) set with one of the following values: "Soundtrack", "Nacharam", "Sredinom" and "Conectarme" ("Track", "Head_of_Track", "Midpoint_of_Track", "End_of_Track").

In a more detailed manner, when using IDF (TKI)specified by NIDF (TKIN), and the file GOITER (AOW file)corresponding to the specified IDF (TKI), are recording the sound object (GOITER) (AOW), which corresponds to one full soundtrack (that is, when TREBLED (I_BLK_ATR) IDF (TKI) is set to "Soundtrack" ("Track")), "ATRUGGLE" (DPL_TK_ATR) set the value equal to "00b".

In that case, when using IDF (TKI)specified by NIDF (TKIN), and the file GOITER (AOW file)corresponding to the specified IDF (TKI), are recording the sound object (GOITER) (AOW), which matches only at the beginning of the record (that is, when ATRAMI (TKI_BLK_AIR) IDF (TKI) has the value "Start playback" ("Head_of_Track")), "ATRUGGLE" (DPL_TK_ATR) set the value equal to "001b". In that case, when using IDF (TKI)specified by NIDF (TKIN), and the file GOITER (AOW file)corresponding to the specified IDF (TKI), are recording the sound object (GOITER) (AOW), which corresponds environments is it part of the record (i.e., when TREBLED (TKI_BLK_ATR) IDF (TKI) is set to "Sredinom" ("Midpoint_of_Track"), "ATRUGGLE" (DPL_TK_ATR) set the value equal to "00b". In that case, when using IDF (TKI)specified by NIDF (TKIN), and the file GOITER (AOW file)corresponding to the specified IDF (TKI), are recording the sound object (GOITER) (AOW), which corresponds to the final part of this record (that is, when TREBLED (TKI_BLK_ATR) IDF (TKI) is set to "Conectarme" "End_of_Track"), "ATRUGGLE" (DPL_TK_ATR) set the value equal to "011b".

Otherwise, when IDF (TKI)specified by (NIDF (TKIN)do not apply, and the scope for IDF (TKI) simply sets the standards of that state, when performed removal of IDF (TKI) (that is, when TREBLED (TKI_BLK_ATR) IDF (TKI) is set to "Unused"), "ATRUGGLE" (DPL_TK_ATR) set the value to "100b".

When IDF (TKI)specified by NIDF (TKIN)do not apply, and the scope for IDF (TKI) is not defined, that is, when the IDF (TKI) is the initial state, "ATRUGGLE" (DPL_TK_ATR) set the value to "101b".

Because NIDWU (DPL_TKIN) the recorded number of IDF (TKI), it is clear which of the many IDF (TKI) match each UPFLUSH (DPL_TK_SRP). Position UPFLUSH (DPL_TK_SRP) in Informatsiejobrashchatsja (Default_Playlist_Information) indicates that, when it made the play GOITER (AOW), corresponding to the IDF (TKI), which in turn correspond UPFLUSH (DPL_TK_SRP), that is, the ordinal position of GOITER (AOW) in the playlist by default (Default_Piaylist). As a result, the order of the elements UPFLUSH (DPL_TK_SRP) in the playlist by default (Default_Playlist) denotes the order in which you will play a variety of phonograms, or, in other words, determines the playback order of phonograms.

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

On Fig shows the relationship between Informatsioon (Default_Playlist_Information), IDF (TKI) and files GOITER (AOW files). The second, third and fourth levels in this drawing is similar to the first, second and third levels, illustrated in Fig and shows the administrator of phonograms (TrackManager), which contains eight IDF (TKI) and eight files GOITER (AOW files). Fig differs from Fig the fact that the rectangle denoting Informatsijudlja (Default_Playlist_Information), depicted on the first level. This rectangle shows eight small areas, representing eight UPFLUSH (DPL_TK_SRP)contained in Informatsiejobrashchatsja (Default_Playlist_Information). In ve is chna part of each plot shows ATRUGGLE (DPL_TK_ATR), and in the lower part shows NIDWU (DPL_TKIN).

As shown in Fig, arrows DT1, DT2, DT3, DT4, ..., UPFLUSH NO. 1 (DPL_TK_SRP#1) and IDF No. 1 (TC#1) are connected as UPFLUSH NO. 2 (DPL_TK_SRP#2) with IDF No. 2 (TC#2), UPFLUSH NO. 3 (DPL_TK_SRP#3) WITH IDF No. 3 (TC#3), and UPFLUSH NO. 4 (DPL_TK_SRP#4) WITH IDF No. 4 (TKI#4).

When considering fields ATRUGGLE (DPL_TK_ATR) in UPFLUSH (DPL TK_SRP) shows that for each of UPFLUSH NO. 1, UPFLUSH NO. 2, UPFLUSH No. 3 and UPFLUSH NO. 8 (DPL_TK_SRP#1, DPL_TK_SRP#2, DPL_TK_SRP#3, DPL_TK_SRP#8) was set to "Soundtrack" ("Track"). In other words, the four following together: UPFLUSH No. 1 →IDF No. 1 (DPL_TK_SRP#1 → TKI#1) ("AOB001.SA1"), UPFLUSH No. 2 → IDF No. 2 (DPL_TK_SRP#2 → TKI#2) ("AOB002. SA1"), UPFLUSH No. 3 → IDF No. 3 (DPL_TK_SRP#3 → TC#3) ("AOV. SA1"), UPFLUSH No. 8 → IDF No. 8 (DPL_TK_SRP#8 → TKI#8) ("AOB008.SA1")correspond to four separate soundtracks.

Meanwhile, none of ATRUGGLE (DPL_TK_ATR) for UPFLUSH NO. 4, UPFLUSH NO. 5, UPFLUSH No. 6 and UPFLUSH NO. 7 (DPL_TK_SRP#4, DPL_TK_SRP#5, DPL_TK_SRP#6, DPL_TK_SRP#7) is not set to "Soundtrack" ("Track"). Instead, ATRUGGLE (DPL_TK_ATR) for UPFLUSH NO. 4 (DPL_TK_SRP#4) is set to "Start playback" ("Head_of_Track"), ATRUGGLE (DPL_TK_ATR) for UPFLUSH NO. 7 (DPL_TK_SRP#7) is set to "Conectarme" ("End_of_Track"), ATRUGGLE (DPL_TK_ATR) for UPFLUSH NO. 5 (DPL_TK_SRP#5) and for UPFLUSH NO. 6 (DPL_TK_SRP#6) is set to "Sredinom" ("Midpoint_of_Track").

This lake is achet, what IDF No. 4 (TKI#4) ("AOB004.SA1")that are associated with UPFLUSH NO. 4 (DPL_TK_SRP#4), represent the beginning of a phonogram, IDF No. 5 (TKI#5) ("AOB005.SA1") and IDF No. 6 (TKI#6) ("AOB006.SA1"), which are connected, respectively, with UPFLUSH NO. 5 (DPL_TK_SRP#5) and UPFLUSH No. 6 (DPL TK SR#6), represent the part in the middle of a phonogram and the IDF No. 7 (TKI#7) ("AOB007.SA1")that are associated with UPFLUSH NO. 7 (DPL_TK_SRP#7), represent the end tags.

Elements UPFLUSH (DPL_TK_SRP) in Speckien (DefaultPlaylist) indicate the playback order GOITER (AOW)corresponding to each IDF (TKI). NIDWU (DPL_TKINs) UPFLUSH№1, №2, №3, №4, ... №8 (DPL_TK_SRP#1, #2, #3, #4... #8) in Spicchio default (DefaultPlaylist) from Fig indicate IDF№1, №2, №3, №4, ... №8 (TKI#1, #2, #3, #4 ... #8). As shown by the arrows(1) (2) (3) (4)...(8), the first will play the file GOITER (AOW file) "AOB001.SA1"corresponding to the IDF No. 1 (TC#1); the second will be played "AOB002.SA1"corresponding to the IDF No. 2 (TC#2); the third will be played "AOB003.SA1"corresponding to the IDF No. 3 (TC#3); and the fourth will be reproduced "AOB004.SA1"corresponding to the IDF No. 4 (TKI#4).

{17-10_41} Example settings for Spissky (DefaultPlaylist) and Informatsiya (Playlist_Information)

On Fig shows an example of settings for Spissky (DefaultPlaylist) and Informatsiejobrashchatsja (Playlist_Information) using the same notations, as Fig. On Fig rectangle on the ground level indicated Spyzooka-default (DefaultPlaylist), and three rectangles in the second level denotes ISWF (PLIs).

The rectangle through which indicated Spookie (DefaultPlaylist), is divided into small areas, which identifies eight values UPFLUSH (DPL_TK_SRP)contained in Speckien (DefaultPlaylist), a in small areas in the rectangles that mark each ISWF (PLI), are the three or four values UPPGIFT (PL_TK_SRP). NIDF (TKIN) each UPFLUSH (DPL_TK_SRP)contained in Informatsiya (Playlist_Information) is set the same as on Fig. However, the set values NIDF (TKIN) UPPGIFT (PL_TK_SRP)contained in each IVF (PLI), are completely different from those established by UPFLUSH (DPL_TK_SRP).

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

On Fig shows the correspondence between UPFLUSH (DPL_TK_SRP) and IDF (TKI), using the same legend as on Fig. On Fig Spyzooka No. 1 (Playlist#1) consists of UPPGIFT №1, №2, №3 (PL_TK_SRP#1, ft2, #3). Them as NEFF (PL_TKIN) in UPPGIFT NO. 1 (PL_TK_SRP#1) recorded No. 3 (#3), as NEFF (PL_TKIN) in UPPGIFT NO. 2 (PL_TK_SRP No. 2) recorded No. 1 (#1), and as NEFF (PL_TKIN) in UPPGIFT NO. 3 (PL_TK_SRP#3)-№2 (#2). This means that when the reproduction of phonograms according Spyschool No. 1 (Playlist#1) reproduction of many GOITER (AOW) will be performed in the following order: GOITER NO. 3, GOITER NO. 1, GOITER No. 2 (AOW#3, AOB#I, AOW#2), as shown by the arrows(11) (12) (13).

The playlist No. 2 (Playlist#2) consists of UPPGIFT №1, №2, №3 (PL_TK_SRP#1, #2, #3). Them as NEFF (PL_TKIN) in UPPGIFT NO. 1 (PL_TK_SRP#1) recorded No. 8 (#8), as NEFF (PL_TKIN) in UPPGIFT NO. 2 (PL_TK_SRP#2) recorded No. 3 (#3), and as NEFF (PL_TKIN) in UPPGIFT NO. 3 (PL_TK_SRP#3) - №1 (#1). This means that when the reproduction of phonograms according Spyschool No. 2 (Playlist#2) reproduction of many GOITER (AOW) will be performed in the following order: GOITER NO. 8, GOITER NO. 3, GOITER No. 1 (AOW#8, AOW#3, AOW#1), as shown by the arrows(21) (22) (23), that is, in a manner completely different from that specified in Spissky No. 1 (Playlist#1).

Spyzooka No. 3 (Piaylist#3) consists of UPPGIFT№1, №2, №3, №4 (PL_TK_SRP#1, #2, I, #4). NEFF (PL_TKIN) these UPPGIFT # 1 to # 4 (PL_TK_SRP#1-#4) is set to, respectively, №8, №4, №3 and№1 (#8, #4, #3, #1). This means that, when the reproduction of phonograms according Spyschool No. 3 (Playlist#3) reproduction of many GOITER (AOW) will be performed in the following order. First, as shown by the arrow (31), have a play GOITER No. 8 (AOB#8) forming a Phonogram D (TrackE). Then perform the play GOITER NO. 4, GOITER NO. 5, GOITER No. 6 and GOITER No. 7 (AOW#4, AOW#5, AOW#6, AOB#7), which form a Phonogram G (TrackD), as shown by the arrow (32). Then perform the play GOITER No. 3 and GOITER No. 1 (AOW#3, AOB#1), which form a, respectively. Soundtrack In (TrackC) and Soundtrack (TrackA), as shown by the arrows (33) and (34).

It is worth noting here that if the soundtrack consists of many IDF (TKI), the element UPPGIFT (PL_TK_SRP) write only the number of IDF (TKI) of the beginning of the recording. In a more detailed manner, despite the fact that the values UPFLUSH (DPL_TK_SRP)that are listed in Informatsiia speckien (Default_Playlist_Information), define the four IDF (TKI) (IDF No. 4, IDF No. 5, IDF No. 6, IDF No. 7) (TKI#4, TKI#5, TKI#6, TKI#7), which form a Phonogram G (TrackD), UPPGIFT (PL_TK_SRP)contained in the set Informatsiya (Playlist_Information) does not necessarily have to be all four IDF (TKI). For this reason UPPGIFT NO. 2 (PL_TK_SRP#2) in the List vosproizvedeniya No. 3 (Playlist#3) from all IDF from No. 4 to No. 7 (TKI#4-#7) are only IDF No. 4 (TKI#4).

On the other hand, the amount of data SWFU (DPLI), which contains the set of UPFLUSH (DPL_TK_SRP), does not exceed the size of one sector, and it is always loaded into RAM (random access memory) devices. In the case where reproduction is. phonograms carried out according to the playlist (Playlist) the playback device performs the conversion to UPFLUSH (DPL TC SRP), which is loaded in RAM, and thus can search IDF (TKI) with a high speed. To play IDF (GOITER) (TKI (AOW)) using UPPGIFT (PL_TK_SRP), which specifies the number of the IDF (TKI) only the first IDF (TKI), the playback device performs the search UPFLUSH (DPL_TK_SRP)loaded in RAM, on the basis of the IDF (TKI)specified by UPPGIFT (PL_TK_SRP), and concludes whether the current soundtrack consists of many IDF (TKI). If so, the playback device performs a corresponding operation to reproduce all relevant IDF (GOITER) (TKIs (AOBs)).

As described above, in the Administrator of the playlist (PlaylistManager) recorded Spookie (DefaultPlaylist) and many ISWF (PLI). If NIDWU (DPL_TKINs) and NEFF (PL_TKINs) those UPFLUSH (DPL_TK_SRPs) and UPPGIFT (PL_TK_SRPs), which is formed of such lists playable files recorded various playback order, it becomes possible to carry out reproduction of GOITER (AOW) in a different order. Offering the user a lot done this way variations of the order of playback, the user can create the impression that in the circuit Board 31 flash memory memorized several musical and is Gromov.

It is worth noting here that UPFLUSH (DPL_TK_SRP)corresponding to the file GOITER (AOW), has a small amount of data (two bytes), and IDF (TKI)corresponding to the file GOITER (AOW file), have a large amount of data (up to 1024 bytes). When reordering IDF (TKI) in the administrator of phonograms (TrackManager), you must perform a large number of access operations Board 31 flash memory, however, the reordering UPFLUSH (DPL_TK_SRPs) in Informatsiejobrashchatsja (Default_Playlist_Information) or in ISWF (PLI) can be implemented with a smaller number of access operations Board 31 flash memory.

With this in mind, when editing the navigation data is a significant change in the order UPFLUSH (DPL_TK_SRPs) in Spissky default (DefaultPlaylist) in accordance with the editing operation, however, the order of the IDF (TKI) in the administrator of phonograms (TrackManager) remains unchanged, despite performing editing operations.

{17-9_40-A, B} Reordering UPFLUSH (DPL_TK_SRP)

Below is a description of the edit operations, which change the playback order of phonograms by reorder UPFLUSH (DPL_TK_SRPs) in Informatsiejobrashchatsja (Default_Playlist_Information). On Figa and Figb shows one example of reordering fo is ogram. UPFLUSH (DPL_TK_SRPs) and IDF (TKI) of Figa have the same settings as on Fig.

On Figa is NIDWU (DPL_TKIN) in UPFLUSH NO. 3 (DPL_TK_SRP#3) set the appropriate IDF No. 8 (TC#3), and the value NIDWU (DPL_TKIN) in UPFLUSH NO. 8 (DPL_TK_SRP#8) set the appropriate IDF No. 8 (TKI #8). Below is a description of the example, when these UPFLUSH (DPL_TK_SRPs)allocated to Figa thick contour, changing places.

Number(1) (2) (3) (4) (5) (6) (7) (8) on Figb indicate the playback order of phonograms after this editing operation. It should be noted that Figa shows the following order of play: the Soundtrack And the Soundtrack B, Soundtrack, Soundtrack, Soundtrack D. (TrackA, TrackB, TrackC, TrackD, TrackE), and Figb in Informatsiejobrashchatsja (Default_Playlist_Information) was replaced NIDWU (DPL_TKINs) UPFLUSH No. 3 and UPFLUSH NO. 8 (DPL_TK_SRP#3,DPL_TK_SRP#8) with each other, so the reproduction of phonograms perform in the following order: the Soundtrack And the Soundtrack B, Soundtrack D., Soundtrack, Soundtrack (TrackA, TrackB, TrackE, TrackD, TrackC). This method can be easily implemented change playback order of phonograms by reordering UPFLUSH (DPL_TK_SRPs) in Informatsiejobrashchatsja (Default_Playlist_Information).

In the above description discussed the operation R is datirovaniya, at which carry out the change the order of phonograms, and the following is a description of the following four operations, the explanation which was given in the description of changes in IDF (TKIs). These operations are: the first example (Example 1), in which the removal of a phonogram, the second example (Example 2)in which are recorded a new soundtrack, the third example (Example 3), in which the Union of two randomly selected soundtracks to create a new soundtrack, and the fourth example (Example 4), in which the separation of the phonogram to create two new phonograms.

{17-9_40-A, B} Erasing soundtracks

The following is a description of Example 1, in which the removal of tags.

On Figa and Figb shows how shall update Spissky (DefaultPlaylist), administrator of phonograms (TrackManager) and files GOITER (AOW files) in the case when shown on Fig Spissky (DefaultPlaylist) removed UPFLUSH NO. 2 (DPL_TK_SRP#2) and IDF No. 2 (TKI#2). These drawings shall remove the same part GOITER (AOW), which in the drawing Fig, which was used to describe the removal of IDF (TKI). As a result, second, third, and fourth levels on Figa and Figb are the same as on Fig. Unlike Fig is that at p the moat level picture of the same, as Fig, Informatsiyaonnaya (Default_Playlist_Information), which contains the set of UPFLUSH (DPL_TK_SRPs).

In this example, considered is a case in which the user carries out the destruction of Phonograms B (TrackB), consisting of UPFLUSH No. 2 → IDF No. 2 (DPL_TK_SRP#2→TKI#2) ("AOB002.SA1"), which Figa highlighted by a thick contour. In this example of Informatises vosproizvedeniya (Default_Playlist_Information) remove UPFLUSH NO. 2 (DPL_TK_SRP#2), and each of UPFLUSH from No. 3 to No. 8 (DPL_TK_SRP#3 - DPL_TK_SRP#8) is moved one position forward relative to the playback order, thus conducting filling the place in the sequence, which was released when removing UPFLUSH NO. 2 (DPL_TK_SRP#2).

After you perform this permutation UPFLUSH (DPL_TK_SRPs), in the last UPFLUSH NO. 8 (DPL_TK_SRP#8) set to "Unused". On the other hand, as shown in Figa and Figb, IDF (TKI)corresponding to the removed part, set the value of "Unused", while moving other IDF (TKI) to fill the gap created by removing, do not exercise. Remove IDF (TKI) is also accompanied by deleting the file GOITER (AOW file) "AOB002.SA1".

In this way are moving UPFLUSH (DPL_TK_SRP s) forward in order to play without moving IDF (TKI), so n is Figb update only NIDWU (DPL_TKINs) in UPFLUSH (DPL_TK_SRPs). In this example, NIDWU (DPL_TKIN) in UPFLUSH NO. 2 (DPL_TK_SRP#2) is set such that it indicates the IDF No. 3 (TC#3), as shown by the arrow DT11, NIDWU (DPL_TKIN) in UPFLUSH NO. 3 (DPL_TK_SRP#3) is set such that it indicates the IDF No. 4 (TC#4), as shown by the arrow DT12, NIDWU (DPL_TKIN) in UPFLUSH NO. 4 (DPL_TK_SRP#4) is set such that it indicates the IDF No. 5 (TKI #5), and NEFFU (DPL_TKIN) in UPFLUSH NO. 5 (DPL_TK_SRP#5) is set such that it indicates the IDF No. 6 (TKI#6). NIDWU (DPL_TKIN) in UPFLUSH NO. 8 (DPL_TK_SRP#8), the value of which has been previously set as "Unused", set the appropriate IDF No. 2 (TC#2), as shown by the arrow DT13.

When the soundtrack removed, UPFLUSH (DPL_TK_SRP)used for subsequent phonograms in order of play, advance, and IDF (TKI), the corresponding remote playback, set the value of "Unused" while maintaining their current location. Thus, the edit operation is not accompanied by the movement of IDF (TKI)that reduces the computational load when editing phonograms.

{17-9_40-A,B) Assigning IDF (TKI) when recording soundtracks

The following is a description of Example 2, in which, after removal of part of the phonogram record a new soundtrack. On Figa and Figb shows the write operation, the new IDF (TKI) and UPFLUSH (DPL_TK_SRP) in the presence of "Unused" IDF TKI) and UPFLUSH (DPL_TK_SRP) are present.

These figures largely similar Figa and Figb that were used to explain the appropriation of the new IDF (TKI) for IDF (TKI), has a value of "Unused". The second, third and fourth levels on Figa and Figb identical to the first three levels on Figa and Figb. The difference between these two drawings is that on Figa and Figb at the first level shown Informatsiyalarimizzi default (Default_Playlist_Information)consisting of a set of UPFLUSH (DPL_TK_SRPs). On Figa in UPFLUSH from No. 4 to No. 8 (DPL_TK_SRP#4-DPL_TK_SRP#8) is set to "Unused". However, Pig in the IDF No. 2, IDF No. 4, IDF No. 5, IDF No. 7, IDF No. 8 (TC#2, D#4, D#5, TKI#7, D#8) is set to "Unused ".

Despite the fact that the IDF (TKI), with the values "Unused", located in different places of the administrator of phonograms (TrackManager), Informacijos failover (Default_Playlist_Information) "Unused" UPFLUSH (DPL_TK_SRPs) are located next to each other. This is because, as described above, in Informatsiejobrashchatsja (Default_Playlist_Information) used UPFLUSH (DPL_TK_SRPs) moves forward, and IDF (TKIs) such promotion is not carried out.

The following explanation describes an example in which the audio recording of G (TrackD), consisting of four GOITER (AO is). IDF (TKI) for these four GOITER (AOW) record, respectively, in the following "Unused" IDF (TKI) in the administrator of phonograms (TrackManager): IDF No. 2, IDF No. 4, IDF # 7 and IDF No. 8 (TKI #2, TKI#4, TKI #7, TKI#8).

UPFLUSH (DPL_TK_SRPs) for these four GOITER (AOW) recorded in UPFLUSH from No. 4 to No. 7 (DPL_TK_SRP#4 - DPL_TK_SRP#7) in Informatsiejobrashchatsja (Default_Playlist_Information). As these four GOITER (AOW) form one of the soundtrack, the value ATRUGGLE (DPL_TK_ATR) UPFLUSH NO. 4 (DPL_TK_SRP#4) is set as "Start Playback" ("Head of Track"), values ATRUGGLE (DPL_TK_ATRs) UPFLUSH NO. 5 (DPL_TK_SRP#5) and UPFLUSH NO. 6 (DPL_TK_SRP#6) is set as "Sredinom" ("Middle_of_Track"), and the value ATRUGGLE (DPL_TK_ATR) UPFLUSH NO. 7 (DPL_TK_SRP#7) is set as "Conectarme" ("End_of_Track").

NIDWU (DPL_TKIN) UPFLUSH NO. 4 (DPL_TK_SRP#4) establish appropriate IDF No. 2 (TC#2), NIDWU (DPL_TKIN) UPFLUSH No. 5 (DPL_TK_SRPft5) establish appropriate IDF No. 4 (TC#4), NIDWU (DPL_TKIN) UPFLUSH NO. 6 (DPL_TK_SRP#6) corresponding IDF No. 7 (TKI#7), NIDWU (DPL_TKIN) UPFLUSH NO. 7 (DPL_TK_SRP#7) corresponding IDF No. 8 (CC#8).

With such a setting NIDWU (DPL_TKINs) and ATRUGGLE (DPL_TK_ATRs) management of the IDF No. 2, IDF No. 4, IDF # 7 and IDF No. 8 (TKI#2, TKI#4, TKI#7, TKI#8) perform as the fourth phonogram, the Phonogram G (TrackD).

When the above processing, the recording is carried out in a "Wasted" IDF (TKI) have no impact on other IDF (TKI), IDF No. 1, IDF No. 2 IDF # 3 and IDF No. 4 (TKI#I, TKI#2, TKI#3, and TKI#4), which was also shown in Figa and Figb.

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

Below is a description of the update Informatsiejobrashchatsja (Default_Playlist_Information) at Association of phonograms (i.e., Example 3). On Figa and Figb shows one example of the Association of phonograms.

These figures largely similar Figa and Figb that were used to explain the procedure of Association IDF (TKI). The second, third and fourth levels on Figa and Figb identical to the first two levels on Figa and Figb. The difference between these two drawings is that on the first level Figa and Figb shown Informacio speckien (Default_Playlist_Information), in which UPFLUSH NO. 8 (DPL_TK_SRP#8) set as "Unused" and is linked to the IDF No. 2 (TKI#2), which is also set as "Unused". When executing shown in Figa and Figb editing operations for the unification of phonograms for files GOITER (AOW) and IDF (TKI), the contents of each UPFLUSH from No. 3 to No. 6 (DPL_TK_SRP#3 - DPL_TK_SRP#6) move down one position, and the contents UPFLUSH NO. 7 (DPL_TK_SRP#7), marked by a thick outline, copy in UPFLUSH NO. 3 (DPL_TK_SRP#3), as shown in Figa and Figb. Also upgrading IDF (TKI) as p is shown on Figa and Figb.

{17-9_40-A,B} Example 4: Separation of the phonogram

Below is a description of the update Informatsiejobrashchatsja (Default_Playlist_Inforination) at the division of the phonogram (Example 4).

On Figa and Figb shows one example of the separation of the recording. These drawings are largely similar Figa and Figb that were used to explain the procedure division IDF (TKI). The second and third levels on Figa and Figb identical to the first two levels on Figa and Figb. The difference between these two drawings is that on the first level Figa and Figb shown Informacio speckien (Default_Playlist_Information), in which UPFLUSH NO. 8 (DPL_TK_SRP#8) set as "Unused" and is linked to the IDF No. 2 (TC#2), which is also set as "Unused".

As well as Figo and Figb, if the user specifies that the IDF No. 3 (TC#3) ("003.SA1"), which is highlighted by a thick outline, should be divided into two parts, each of UPFLUSH from No. 3 to No. 7 (DPL_TK_SRP#3 - DPL_TK_SRP#7) move down in order in one position, and UPFLUSH (DPL_TK_SRP)whose value is set as "Unused", moved within Informatsiejobrashchatsja (Default_Playlist_Information) into position UPFLUSH NO. 3 (DPL_TK_SRP#3).

This new UPFLUSH IS 3 (DPL_TK_SRP#3) correspond to the new IDF (TKI), created by separation, namely, the IDF No. 2 (TKI#2). In file GOITER (AOW file) "AOB002. SA1", the corresponding IDF No. 2 (TC#2), preserve what was originally the last part of the file GOITER (AOW file) "003.SA1". UPFLUSH NO. 2 (DPL_TK_SRP # 2), or the appropriate IDF No. 2 (TC#2) and "AOB002. SA1", located in front of UPFLUSH NO. 3 (DPL_TK_SRP#3), which correspond to the IDF No. 2 (TKI#2).

That is, in "AOB002. SA1" and "OW. SA1" remember, respectively, the second and the first part of the original ".SA1", and corresponding to these files UPFLUSH NO. 2 (DPL_TK_SRP#2) and UPFLUSH NO. 3 (DPL_TK_SRP#3) indicate that the reproduction of these GOITER (AOW) should be performed in the following order: "AV. SA1" and "AOB002.SA1". As a result, reproduction of the first and second parts of the source "003.SA1" will be performed in the following order: first part, second part, which corresponds to a playback order specified in UPFLUSH (DPL_TK_SRP).

{17-9_40-8} Application processing when editing

By combining the above four procedures editing, the user can perform a wide variety of editing operations. For example, in the case where the recorded soundtrack has an introduction, over which the recorded speech leading music transfer, you can first divide the soundtrack thus, to separate the part that contains the voice leading m is a piece of gear. The user can then delete the soundtrack, leaving himself with the portion of the soundtrack, which does not contain the voice leading music gear.

This completes the description of the navigation data. Below is a description of the playback device, with the proper structure, ensuring the reproduction of the above-described navigation data and reproduced data.

{48-1} the appearance of the playback device

On Fig depicts a portable playback device for card 31 flash memory of the present invention. Shown in Fig the playback device has an insertion slot of the card 31 flash memory, a keypad for receiving user instructions to perform operations such as playback, search forward, search backward, straight-forward, rewind, stop, etc. and LCD (liquid crystal) panel. From the point of view of the appearance of this device play like other types of portable media players for music players).

Keypad contains:

press "playlist" ("Playlist"), through which the selection of the playlist or phonogram;

press "|<<", which perform the operation of passes at which the playhead move the start of the current phonogram;

press ">>|", which perform the operation of passes, in which the playing position is shifted to the beginning of the next phonogram;

press<<" and press ">>", through which carry, respectively, a search operation in the reverse direction and the search operation in the forward direction, which allows the user to perform fast playback of the current phonogram;

press "display" ("Display"), whereby perform the operation of displaying on the screen of still images stored in the circuit Board 31 flash memory;

press "Record" ("Rec"), through which a write operation;

press "Sound" ("Audio") through which the user selects the sampling frequency or the used mode: stereo or mono;

press "Mark", "Mark"), through which the user performs a specific marked places in phonograms;

and

press Edit ("Edit"), through which the user performs editing of phonograms or enter headers of phonograms.

{48-2} Enhancements implemented in this portable playback device for card 31 flash memory.

The differences between this portable playback device for card 31 flash memory and conventional portable player is the user for music is composed in the following four enhancements (1)th to (4)-E.

(1) On the LCD panel display a table of the playlist and the list of phonograms, which allows to display to the user Informatsijudlja (Default_Playlist_Information), IVF (PLI) or specific tags.

(2) the Keys on the keypad corresponds displayed on the LCD panel lists the response files and/or phonograms, which allows the user to make a choice of the phonogram or the playlist for playback or editing.

(3) On the LCD panel 5 display the time code, which specifies the location within the soundtrack during playback of the recording.

(4) Provides for a rotary disk with a speed switch that allows the user to set the value of the time code is used as the start time of playback when using the search function of time or as the boundary of separation when the separation of the recording.

{48-2_49_50} Improvement (2)

Below is a detailed description of improvements (2). On Fig shows one example of the image on the display screen of the LCD panel when the user selects the playlist, and on the drawings with Figo on Figg shows examples of display content in the case where the user performs the selection of the tags.

On Fig line by ASCII (American standard code for information interchange) "SPASSOV FAILOVER" ("DEFAULT PLAY-LIST"), "SPASSOV FILE NO. 1" ("PLAYLIST#1"), "SPYZOOKA NO. 2" ("PLAYLIST#2"), "SPYZOOKA NO. 3" ("PLAYLIST#3) and "SPOOKIE NO. 4" ("PLAYLIST#4") display the playlist, the default, and four of the playlist, which are stored in the circuit Board 31 flash memory.

Meanwhile, a string of ASCII characters "Soundtrack №1", "Soundtrack №2", "Soundtrack №3", "Soundtrack №4", "Soundtrack №5" (Track#1 and Track#2", "Track#3", "Track#4", "Track#5") display five phonograms, which are listed in the playback order specified by the playlist, the default stored in the circuit Board 31 flash memory. On Fig and Figa selected by the shading of the playlist and sound shows the phonogram or the playlist that is currently indicated as intended for playback or editing.

If the user presses ">>" in the moment as intended for playback in the playback order specified in displayed on the LCD panel the playlist specified default is Y. marked Soundtrack №1 (Track#1), then, as shown in Figb, in the list of phonograms as intended for playback will be indicated Soundtrack №2 (Track#2). If the user again presses the key ">>", as shown in Figv, in the list of phonograms as intended for playback will be indicated Soundtrack №3 (Track#3).

If the user presses ">>" in the moment as intended for playback in the playback order specified in displayed on the LCD panel the playlist, the default, marked the Soundtrack №3 (Track#3), then, as shown in Figg, in the list of phonograms as intended for playback will be indicated Soundtrack №2 (Track#2). As shown in Figg, if at the moment when checked any of phonograms, the user presses the Play button ("Play"), it starts playing the specified sound, and if the user presses "Edit" ("Edit"), then this soundtrack will be selected as intended for editing.

{48-3_51} Improvement (4)

Below is a detailed description of the improvement (4). In the drawings, with Figo on FIGU shows an example of the operation of the rotary drive with manual switching. When the user rotates regards the now drive with manual switching at a given angle, the value displayed on the LCD panel time code playback increase or decrease in accordance with that given angle. In the example of Figa shows the case in which the original value is displayed on the LCD panel time code playback is"00:00:20".

When the user rotates the rotary disk with step switch counterclockwise as shown in Figb, the value of the time code playback is reduced to a value of "0:00:10" in accordance with the magnitude of the angle, which was rotated rotary disk with manual switching. Conversely, in the case when the user rotates the rotary disk with step switch clockwise as shown in Figv, the value of the time code playback increase to a value of "0:00:30" in accordance with the magnitude of the angle, which was rotated rotary disk with manual switching.

Allowing the user in a similar way to alter the code of the playback time, the playback device provides the user the ability to specify in the recording any time code playback simply by rotating the rotary disk with manual switching. If the user then presses the Play button ("Play"), playback GOITER (AOW) is carried out, starting from the place, colorotate according to Equation 2 and Equation 3.

Through the use of a rotary disk with manual switching when performing the split operation of a phonogram, the user can perform fine adjustment of the time code playback when using it as the boundary of separation.

{52-1} 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, the playback device contains a card connector 1 for connecting the playback device with the card 31 flash memory block 2 user interface, which is connected with keypad and rotary drive with manual switching, RAM 3, ROM 4, the LCD panel 5, which is a list box to display the list of phonograms or lists of playable files and the code window of play time to display the time code playback device 6 controls the LCD to control the first LCD panel 5, the decoder 7 random sequences for decoding Frames SOB(AOB_FRAMEs) using different keys file (FileKey) for each file GOITER (AOW file), the decoder 8 UCSI (advanced audio coding information) (AAC) for the implementation of access ADTS QUADRAT (_FRAME), the transcript of which is carried out by Dechy the operator 7 random sequences, and implementation of decoding QUADRAT (AOB_FRAME to retrieve data PCM (PCM), digital-to-analog Converter (DAC) 9 for digital-to-analog data conversion PCM and outputs the resulting analog signal to the loudspeaker or headphone Jack, and a Central processing unit (CPU) 10 for the implementation of centralized management of the playback device.

From this structure of the hardware it is clear that the playback device does not have any special hardware for processing administrator of phonograms (TrackManager) and Informatsiejobrashchatsja default (Default_Playlist_Information). To implement processing administrator of phonograms (Track Manager) and Informatsiia speckien (Default_Playlist_Information), RAM 3 create region 11 permanent storage SWFU (DPLI), region 12 storage ISWF (PLI), region 13 storage IDF (TKI), area of 14 Key store file (FileKey) and double buffer 15, and in ROM 4 remember the program control playback and control program editing.

{52-2} Region 11 permanent storage SWFU (DPLI)

Region 11 storage SWFU (DPLI) is an area for permanent storage Informatsiejobrashchatsja default (Default_Playlist_Information), which was considered one of th the from the Board on 31 flash memory, connected with the connector 1 of the Board.

{52_12} Region 12 storage ISWF (PLI)

Region 12 storage ISWF (PLI) is an area that is reserved for storing Informatises vosproizvedeniya (Playlist_Information)selected by the user for playback.

{52-3} Region 13 storage IDF (TKI)

Region 13 storage IDF (TKI) is the area that is reserved for storing only those IDF (TKI) from the set IDF (TKI), is contained in the administrator of phonograms (TrackManager), which correspond to the file GOITER (AOW file)specified in the present moment as held for playback. For this reason, the capacity region 13 storage IDF (TKI) is equal to the amount of data corresponding to one IDF (TKI).

{52-4} storage Area 14 key file (FileKey)

The storage area 14 of the key file (FileKey) is an area that is reserved for storing only the key file (FileKey) from a variety of file keys (FileKeys)contained in the "AOBSA1.KEY" in the field of identification, which correspond to the file GOITER (AOW file)specified in the present moment as held for playback.

{52-5} Double buffer 15

Double buffer 15 is a buffered I / o, which is used in parallel execution of process input, which perform serial input data the cluster (data, stored in the same cluster)read from the card 31 flash memory, and inference process, in which the reading Kudrovo (AOB_FRAMEs) of the cluster data and serial output Kudrovo (AOB_FRAMEs) in the decoder 7 random sequences.

Double buffer 15 sequentially releases the areas that were occupied by the data cluster, depicted in the form of Kudrovo (AOB_FRAMEs), and thus provides scope for memory read the following clusters. This means that in the double buffer 15 carry out cyclic allocation of areas for storing data cluster using the ring pointers.

{52-AB} Input and output through the double buffer 15

On Fig shows how perform I / o to the double buffer 15. On Figa and Figb shown that, as in the double buffer 15 carry out cyclic allocation of areas for storing data cluster using the ring pointers.

Arrows pointing down and to the left represent pointers address where write data cluster, that is, pointers to records. Arrows pointing up and to the left, represent pointers addresses where carry out the read cluster data, that is, the signs read. These pointers are used as ring pointer.

{54-6_53}

the ri connecting Board 31 flash memory to the card connector 1 perform the read cluster data from the user area in the circuit Board 31 flash memory and save them in the double buffer 15, that is shown by arrows w1 and w2.

Read data cluster consistently remember in those places double buffer 15, which is indicated by the write pointers wp1 and wp2.

{52-A}

From all Kudrovo (_FRAMEs), which are memorized in this way the cluster data, the decoder 7 random sequences perform odinochnyj conclusion Kudrovo (AOB_FRAMEs)located in those placesthat is sequentially specified by the read pointer, as shown by the arrows r1, r2, r3, r4, r5....

In this case, as shown in Fig, in the double buffer 15 remember cluster data 002 and 003, and the position of the readsequentially indicated by the read pointer. When the read pointer reaches the position reading 5, all Madryt (AOB_FRAMEs)contained in the cluster 002, be read at the same time carry out the reading cluster 004 and, as shown by the arrow w6 on Figa, it overwrites that area is ü, which was previously occupied by the cluster 002.

{52-B}

Then the read pointer reaches the position readingandand ultimately reaches the position readingand at this point will be completed reading all Kudrovo (AOB_FRAMEs)contained in the cluster 003, therefore, carry out the reading cluster 005 and, as shown by the arrow on w7 Figv, it overwrites that area that was previously occupied by the cluster 003.

The above described operation output QUADRAT (AOB_FRAME) and overwrite the data in the cluster perform repeatedly, thus conducting the serial output of all Kudrovo (AOB_FRAMEs)contained in the file GOITER (AOW file), the decoder random sequences 7 and the decoder 8 UCSI (AAS).

{52-9_55-58} Program control playback stored in the ROM 4

Below is a description of the program control playback, remembering which is implemented in the ROM 4.

Fig is a precedence diagram showing a processing procedure of reading the file GOITER (AOW file).

Fig, Fig, and Fig are flow diagrams showing the processing procedure of conclusion QUADRAT (AOB_FRAME).

{52-9_55-1}

In these schemes follow the Telenesti operations used variables w, z,,. The variable w is denoted by one of the many UPFLUSH (DPL_TK_SRPs). The variable z is indicated 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). Variable at the indicated ELEMENTAL (AOB_ELEMENT)contained in the CRAW No. z (AOB#z), which is denoted by the variable z. Variable x is denoted by KATZO (AOB_FRAME)contained in Elementet No. (AOB_ELEMENT#y), which is denoted by the variable y. Below, with reference to Fig shown, first of all, the explanation of the processing procedure of reading the file GOITER (AOW file).

{52-9_55-2}

At operation S1, the Central processing unit (CPU) 10 reads the administrator of the playlist (PlaylistManager) and displays a list containing Informatsijudlja (Default_Playlist_Information), IVF (PLI).

At operation 32, the CPU 10 waits for instructions on playback GOITER (AOW) according to any Informatises vosproizvedeniya (Default_Playlist_Information), or one of ISWF (PLIs).

In that case, when you specify Informatsiyaonnaya (Default_Playlist_Information), processing is transferred from operation 32 to operation 33, in which initialize (No.(w-1)) (#w-1) variable w, and then to operation S4, in which the IDF No. z (TKI#z)specified by NEFFU (DPL_TKIN), the corresponding UPFLUSH No. w (DPL_TK_3RP#w) in Informatsiejobrashchatsja (Default_Playlist_Information), and perform the read only these IDF No. z (TKI#z) of the circuit Board 31 flash memory and save them in the field of 13 storage IDF (TKI).

When performing operations 35 define the file GOITER No. z (AOW file #z), which has the same number as IDF No. z (TKI#z). In this way, finally determine the file GOITER (AOW file)that is used for playback.

The determined file GOITER (AOW file is in an encrypted state and must be decrypted, so perform the operation S6 and S7. In operation S6, the playback device accesses the identification area and reads the Key No. z file (FileKey#z), which is stored in Sapolil No. z (FileKey_Entry#z) in the file storage of the encryption key, and Zapiski No. 2 (FileKey_Entry#z) has the same number as the above-defined file GOITER (AOW file). When performing operations 37 S 10 sets the decoder 7 random sequences is Key No. z file (FileKey#z). The result of this operation is that when installed in the decoder 7 random sequences of Key file (FileKey) can be implemented consistent playback Kudrovo (AOB_FRAMEs) through the serial input to the decoder random is posledovatelnostei 7 Kudrovo (AOB_FRAMEs), contained in the file GOITER (AOW file).

{52-9_55-3}

After this, the playback device performs a sequential read those clusters in which the saved file GOITER (AOW file). At operation S8 in the directory entry indicates the number of the first cluster in the file" for File GOITER No. z (AOB_file#z). At operation S9, the CPU 10 carries out the reading of the card 31 flash memory data stored in the cluster. At operation S10, the CPU 10 determines whether the number of cluster in TRF (FAT) is "FFF". If not, then before returning to operation S10 perform an operation S11 in which the CPU performs the reading of data stored in the cluster that is specified by the values of TRF (FAT).

In the case where the playback device reads the data stored in any of the clusters, and the appeal to associated with that cluster is FAT, the processing carried out by execution of the operations S10 and S11, repeat until, until it is set to FAT, equal to "FFF". This leads to the fact that the playback device performs a sequential read of the clusters defined by the values of FAT. When the cluster number is determined by the value of FAT is equal to "FFF", it means that you are reading all clusters forming a file GOITER No. z (AOB file#z), in% the CE processing move from operation to operation S10 S12.

{52-9_55-4}

At operation S12, the CPU 10 determines whether the variable No. w (#w) with the total number UPFLUSH (DPL_TK_SRPs). If not, then before re-processing to operation S4, the process passes to operation 313, in which the increment variable No. w per unit (w←w+1) (#w-#w+1). When operation S4, the playback device determines the IDF No. z (TKI#z), which is indicated by NEFFU No. w (DPL_TKIN#w) UPFLUSH No. w (DPL_TK_SRP#w) in Informatsiejobrashchatsja (Default_Playlist_Information), and writes in the area of 13 storage IDF (TKI) only IDF No. z (TKI#z). Previously used up to this point, IDF (TKI) are stored in the storage region 13 IDF (TKI), but currently in IDF (TKI) will be overwritten IDF No. z (TKI#z), reading is performed by the CPU 10.

Such rewriting leads to the fact that in the field of 13 storage IDF (TKI) memorized only the most recent IDF (TKI). After overwriting the IDF (TKI) treatment, which is performed through operations S5 through S12, repeat for file GOITER No. z (AOW file#z). After this processing will be done reading all IDF (TKI) and failover (AOW files)corresponding to all UPFLUSH (DPL_TK_SRPs)contained in Informatsiejobrashchatsja (Default_Playlist_Iformation), the value of the variable z (#z) coincides with the total number UPFLUSH (DPL_TK_SRP), therefore, when the operation S12 decide "Yes" and complete the treatment according to this scheme, the sequence of operations.

{52-9_56_57_58} Processing for outputting QUADRAT (_FRA)

Simultaneously with the procedure of reading the file GOITER (AOW file), the CPU 10 executes the procedure output QUADRAT (AOB_FRAME) in accordance with the scheme of the sequence of operations shown in Fig, Fig, and Fig. In these diagrams, sequence variable "Vremena" (Play_time) indicates the playback time of the current soundtrack to the present point in time, that is, the time code playback. In accordance with the changes this time code playback, update time, which is displayed in the code window of time playing on the LCD panel 5. Meanwhile, the variable "vosproizvedennye" (play_data) displays the length of the data for the current recording playback which was made before the present point in time.

{52-9_56-1}

At operation S21, the CPU 10 performs a control of whether the double buffer 15 data storage cluster for file GOITER No. z (AOB file#z). This operation S21 is repeatedly performed until, until you made the accumulation of data in the cluster, and e is from the time when processing passes to operation S22, at which carry out the initialization of variables x and y (No. x←1, n we←1). After that, when the operation S23, the CPU 10 searches for clusters for file GOITER No. z (AOB file#z) and detection QUADRAT No. x (AOB_FRAME#x) in Elementet No. (AOB_ELEMENT#y), which in time is no earlier that Digan (Data 0ffset), which is set in TIB No. z (BIT#z)contained IDF No. z (TKI#z). In this example, assume that the ADTS header is seven bytes, starting with OBEDENNYH (SZ_DATA). By reference to the ADTS header data has indicated in the header of ADTS length, can be identified as sound data. Carry out a joint reading of the audio data and the header of ADTS and their output to the decoder 7 random sequences. The decoder 7 random sequences decrypts MADRYT (AOB_FRAMEs), which then decode by decoder 8 UCSI (AAS) and reproduce the sound.

{52-9_56-2}

After following this discovery, on the stage of the operation S24 discharge QUADRAT No. x (AOB_FRAME#x) in the decoder 7 random sequences, and at operation S25 shall increment the variable "Vremena" (Play_time) by an amount equal to the playback duration of QUADRAT No. x (AOB_FRAME#x), and increment the variable "vosproizvedennye" (play_data) on volume data corresponding Kadru what ABOUT No. x (_FRAME#x). Because in this case, the playback time QUADRAT (AOB_FRAME) is equal to 20 MS, then the variable "Vremena" (Play_time) add 20 MS.

Immediately after the conclusion of the first QUADRAT (AOB_FRAME) in the decoder 7 random sequences, the playback device performs the operation S26, in which it executes an appeal to the ADTS header QUADRAT No. x (AOB_FRAME#x) and determines the location of the next QUADRAT (AOB_FRAME). In operation S27, the playback device performs the increment of the variable x (#x←#x+1) and sets KADROV No. x (_FRAME#x) as the next QUADRAT (_FRAME). At operation S28 provides input QUADRAT No. x (AOB_FRAME#x) in the decoder 7 random sequences. After that, during operation S29 shall increment the variable “Vremena” (Play_time) by an amount equal to the playback duration of QUADRAT No. x (AOB_FRAME#x), and increment the variable “vosproizvedennye” (play_data) on volume data corresponding Katoob No. x (AOB_FRAME#x). After an increment KADROV No. x (AOB_FRAME#x) done, perform an operation S30, at which the CPU 10 determines as to whether the variable x (#x) the value specified in Kolkat (FNs_lst_TMSRTE).

If the variable x (#x) has not reached the value specified in Kolkat (FNs_lst_TMSRTE), then perform the OPE is the situation S31, when the playback device checks is also made whether the user pressing any keys other than key Play ("Play"), and then return to operation S26. After this, the playback device repeats the processing, performing operations with S26 through S31 until then, until the value of variable x (#x) reaches that specified in Kolkat (FNs_lst_TMSRTE), or up until the user presses any other key than the key Play ("Play").

In that case, when the user presses any other key than the key Play ("Play"), processing according to this scheme, the sequence of operations finish and perform appropriate processing in accordance with the pressed key. In that case, if the pressed key is the key "Stop" ("Stop"), the playback is stopped and if the pressed key is the Pause key ("Pause"), playback pause.

{52-9_57-1}

Otherwise, if the value of the variable x (#x) has reached Kolker (FNs_lst_TMSRTE), then at operation S30 decide "Yes", and processing continues by performing the operation S32 shown in Fig. Because when performing processing operations S26 in operation S30 in the decoder 7 random sequences party shall have entered all Madryt (AOB_FBAMEs), contained in the currently used Elementat (_ELEMENT), then at operation S32, the increment variable (#) exercise so as intended for data processing was specified following ELEMENTAL (AOB_ELEMENT), and initialization of a variable x (#x) perform the following way: (#y←#y+1, #x-1).

Then, when the operation 333, the playback device performs the conversion to TMVGPBR (TKTMSRT) and calculates the first address Elementat No. (AOB_ELEMENT#y).

Then, the playback Device performs the procedure, consisting of operations S34 in S42. In this procedure shall read one after the other Kudrovo (_FRAMEs)contained in Elementat (AOB_ELEMENT), that is, it is similar to the procedure consisting of operations S24 in S31. The difference of procedure, consisting of operations S24 in S31, is that the end state of a procedure, consisting of operations S24 in S31, is the achievement of a variable x (#x) the value specified by "Kolker" (FNs_lst_TMSRTE), and final state of the procedure, consisting of operations S34 in S42, is the achievement of a variable x (#x) the value specified by "Kolkasrags (FNs_Middle_TMSRTE)".

When a variable x (#x) reaches the value specified by "Kolkasrags (FNs_Middle_TMSRTE)", the procedure cycle, consisting of operations S34 in S42, the finish is, at operation S41 decide "Yes" and the processing is transferred to operation S43. In operation S43, the CPU 10 performs the increment variable (#) and the initialization of the variable x (#x): (#←#+1 #x←1). Then, at operation S44 analyze variable and make a decision as to whether the variable u (#) value per unit less than Alseep (TotalTMSRT_entry_Number) in Segalowitz (TMSRT_HEADER) in the IDF No. z (TKI#z).

If the variable y (#y) less than (Obstet TPWR - 1) (TotalTMSRT_entry_Number - 1), then ELEMENTAL NO. 1 (AOB_ELEMENT#y) is not the last Elementat (_ELEMENT), so the process is returned from the operation S44 to operation S32 and carry out the procedure cycle operation S32 to operation S42. When a variable (#) reaches (Obscener - 1) (TotalTMSRT_entry_Number - 1), then we can assume that the read has reached the penultimate Elementat (AOB_ELEMENT), therefore, when the operation S44 decides "Yes" in the processing of moving further to the operation S45 of Fig.

{52-9_57-2}

The similarity procedure, consisting of operations with S45 in S54, the procedure consisting of operations S33 in S42, is that it shall read each of Kudrovo (AOB_FRAMEs) end Elementat (AOB_ELEMENT).

The difference from the procedure, with the standing of operations S33 in S42, is that the procedure cycle, consisting of operations S33 to S42, finish when the operation S41 decided that the variable x (#x) has reached the value specified in the "Kolker" (FNs_Middle_TMSRTE), and the treatment cycle consisting of operations with S45 in S54 finish when the operation S53 decided that the variable x (#x) has reached the value specified in the "Cooler" (FNs_Last_ TMSRTE), and the variable "vosproizvedennye" (play_data) specifies that the volume is read up to this point in time the data has reached the value that is set as "OBEDENNYH" (SZ_DATA).

The procedure consists of operations on S49 S54, repeat until, until you are satisfied the conditions of operation S53, at this point in the operation S53 decide "Yes", and processing passes to operation S55. In the process, before you are returned to operation S21, at which the CPU 10 waits for the accumulation of the next File GOITER (AOW file) in the double buffer 15, perform an operation S55, at which the CPU 10 performs the increment of the variable z (#z): (#z←#z+1). Thereafter, the process passes to operation S22 and repeats the procedure, consisting of operations S22 in S54. This means that defined IDF (TKI)specified by NEFFU (DPL_TKIN) next UPFLUSH (DPL TK 3RP, and corresponding to these IDF (TKI) file GOITER (AOW file), that is, the file GOITER (AOW file)which has the same number as IDF (TKI).

After this, the playback device accesses the identification area and identifies key file (FileKey), located in the file storage of the encryption key, the file Key (FileKey), which has the same number as IDF (TKI), and then carries out the reading of this Key file (FileKey) and set its value in the decoder 7 random sequences. As a result of this exercise sequential reading and playing Kudrovo (AOB_FRAMEs)contained in the file GOITER (AOW file)which has the same number as IDF (TKI).

{52-9 57-3 59} Update time code playback

On Figa-59G shows how exercise increases the time code playback, which display in the display window time code playback on the LCD panel 5, in accordance with the updated variable "Vremena" (Play_time). On Figa the code value of the playback time is "00:00;00,000", but after playing QUADRAT NO. 1 (AOB_FRAME#1) to the time code playback add value to the playback duration of QUADRAT NO. 1 (AOB_FRAME#1)equal to 20 MS, updating it to the value "00:00:00,020"that is shown on Figb. Upon completion of the playback TO DRATB NO. 2 (AOB_FRAME#2) to the time code playback add duration QUADRAT NO. 2 (AOB_FRAME#2), equal to 20 MS, updating it to the value "00:00:00,040"that is shown on Figv. Similarly, upon completion of the playback QUADRAT NO. 6 (AOB_FRAME#6) to the time code playback add value to the playback duration of QUADRAT NO. 6 (_FRAME#6), is equal to 20 MS, updating it to the value "00:00:00,120"that is shown on Figg.

Here ends the description of the procedure output QUADRAT (AOB_FRAME).

If at operation S31 shown in the sequence diagram of operations of Fig, the user presses any other key than the key Play ("Play"), then the processing in this scheme, the sequence of operations to complete. Processing, which is done by pressing the Stop ("Stop") or Pause ("Pause"), has already been described previously, however, in the case when the user presses one of the keys, are provided for the implementation of device playback special playback mode, the processing in this scheme, the sequence or the sequence of operations shown in Fig, Fig. or Fig stop and perform appropriate processing in accordance with the pressed key.

Below is a description of the procedure performed by the CPU 10 (1) when performing a search function in the forward direction in response to the user presses ">>" and (2) in the exercise of options and time search in response to actuation by the user of the rotary disk with step switch after pressing Pause ("Pause"or "Stop" ("Stop").

{52-10_60} search Function in the forward direction

On Fig presents the precedence diagram showing a procedure performed by the CPU 10 when performing a search function in the forward direction. In that case, when the user pressed ">>", when performing the operation S31, the operation S42 or operation S54 of the schemes of the sequence of operations shown in Fig, Fig and Fig. decide "Yes" and the CPU 10 performs the processing according to the precedence diagram of Fig.

When the operation S61 enters Kudrovo (_frames) # x to # (x+f(t)-1) (#x÷#(x+f(t)-1)) in the decoder 7 random sequences. Here "t" is the duration of intermittent play, f(t) is a(displays) the number(quantity) of frames corresponding to the duration of the intermittent playback, and d(t) is the volume of data corresponding to the duration of the intermittent playback. At operation S62 perform the appropriate update variable "Vremena" (Play_time), indicating the time elapsed since the beginning of the play, and the variable "vosproizvedennye" (play_data)denoting the volume of the playback data, using the duration "t" choppy playback, the number f(t) frames matched with the appropriate duration intermittent playback, and volume d(t) of the data corresponding to the duration of the intermittent playback; (x←x+f(t), vremena←Vremya playback+t, vosproizvedennye←vosproizvedennye +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 the intermittent playback is usually equal to 240 MS (equivalent to the playback duration of twelve Kudrovo (AOB_FRAMEs)).

{52-10_60-A, B}

On Figa and B shows how to increment time code playback during a search operation in the forward direction. On Figa shows the initial value of the time code playback, the playhead is KADROV NO. 1 (AOB_FRAME#1) IN Elementet No. 51 (AOB_ELEMENT#51).

In this case, the code playback time is "00:00:01,000". When the decoder 7 random sequences as the duration of the intermittent playback entered Madryt (AOB_FRAMEs) from the first to the twelfth, to the time code playback add the duration of the twelve Kudrovo (_frames) (i.e., 240 MS), while the time code playback is set to "00:00:01,240"that is shown on Figb.

{52-10_60-2}

After this update, when the operation S63, the CPU 10 compares the value of the variable x (#x), obtained after the increment, the total number is the number of frames in Elementet No. (AOB_ELEMENT#y) and analyzes do not exceed the value of the variable x (#x), obtained after the increment, the total number of frames in Elementet No. (AOB_ELEMENT#y).

As mentioned above, the number of frames in Elementat (AOB_ELEMENT)at the beginning of GOITER (AOW), equal Kolker" (FNs_lst_TMSRTE), the number of frames in Elementat (AOB_ELEMENT), located in the middle part of GOITER (AOW), equal Kolker" (FNs_Middle_TMSRTE), a number of frames in Elementat (AOB_ELEMENT), which is located at the end of GOITER (AOW), equal Cooler" (FNs_Last_TMSRTE).

The above decision of the CPU 10 accepts by comparing the corresponding one of these values with the variable x (#x). When the value of the variable "x" is beyond the scope of this Elementat No. (AOB_ELEMENT#y), then in this case, when the operation S64, the CPU 10 analyzes whether there is any ELEMENTAL (AOB_ELEMENT)going after Elementat No. (AOB_ELEMENT#y).

In the case when ELEMENTAL No. (AOB_ELEMENT#y) is the latest Elementat (AOB_ELEMENT) in Blakeson (AOB_BLOCK), there is no Elementat (AOB_ELEMENT)located after Elementat No. (AOB_ELEMENT#y), therefore, when the operation S64 decides "No", and the processing in this scheme, the sequence of operations completes.

Otherwise, if ELEMENTAL (AOB_ELEMENT)following Elementat No. (AOB_ELEMENT#y)exists, the operation S65 carry out the reduction of C is achene variable "x" (#x) by the number Kudrovo (AOB_FRAMEs) in Elementet No. (AOB_ELEMENT#y), and when performing the operation S66 updates the variable y (#y): (y←+1) (#←#+1). As a result, the variable "x" (#x) now indicates the position of the frame to frame in the following Elementet No. (AOB_ELEMENT#y)specified by the updated variable "y" (#). Conversely, in the case where the variable "x" (#x) indicates KATZO (_FRAME), which is present in the current Elementat (AOB_ELEMENT) (that is, when the operation S63 decided "Yes"), the operation S64-S66 pass and pass to the operation S67 processing.

{52-10_60-3}

After that update the variables x (#x), "play Time" (Play_time) and "Vosproizvedennye" (play_data) in accordance with the duration of the skip choppy playback. Duration vremennaya (skip_time), which is equivalent to the duration of the skip choppy playback, equal to two seconds; the number of frames equivalent to this "vremennaya" (skip_time), defined as f(vremennaya) (f(skip_time)), and the amount of data equivalent to this time skip (skip_time), defined as d(vremennaya) (d(skip_time)). In operation S67 these values are used to update the variables x (#x), "Vremena" (Play_time), and "vosproizvedennye" (play_data): (x←x+f(vremennaya), Vremena←Vremena+vremap USCA, and vosproizvedennye←vosproizvedennye + d(vremennaya))

(#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 Figv, to the value of the variable "x" (#x), which specifies the position of the frame within Elementat No. 51 (AOB_ELEMENT#51) add the duration of the skip choppy playback. When the value of the updated variable "x" (#x) will exceed the number of frames in Elementet No. 51 (AOB_ELEMENT#51), then perform the update of the variable "u" (#) so that it points to the next ELEMENTAL (AOB_ELEMENT), and from the variable "x" (#x) subtract the number of frames contained in Elementet No. 51 (AOB_ELEMENT#51). As a result, the variable "x" (#x) will now indicate the position of the frame within Elementat No. 52 (AOB_ELEMENT#52), which is specified by the updated variable "y" (#), then the current value of "00:00:01,240" time code playback add value 2,000 (=2 seconds), while its value becomes equal to "00:00:03,240". Updating the variable "x" (#x) is carried out by the following calculations: (3240 MS - 2000 MS/20 MS, resulting in a gain value "62", and therefore, it indicates KADROV NO. 62 (AOB_FRAME#62) in Elementet No. 52 (AOB_ELEMENT#52).

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

After entering Quadrat No. 62 (AOB_FRAME#62) from Elementat No. 52 (_ELEMENT#52) in the decoder 7 random sequences performed the t update time code playback by adding to the current value of "00:00:03,240" value "0,240", in the result are set to "00:00:03,480"that is shown on Figg.

In operation S67 carry out the update of variables in accordance with the time skip choppy playback, and then perform processing S68 in S71. When performing these operations S68 in S71 produce the same processing as when performing processing operations with S63 through S66; therefore, before checking whether the variable "x" (#x) still indicates KATZO (AOB_FRAME) within the current Elementat No. (AOB_ELEMENT#y), update the variable "x" (#x) the number of frames, which is equivalent to the time skip when broken play, "Vremya" (skip_time). If this test gives a negative result, then perform the update of the variable "U" (#y) in such a way that as part of GOITER No. (AOB_ELEMENT#y) ask the following ELEMENTAL (AOB_ELEMENT), and the variable "x" (#x) transform so that it was pointing position of the frame in this next Elementat (AOB_ELEMENT).

After updating the variables "x" and "y" (#x, #y) in accordance with time intermittent playback, and time passes in a choppy playback in operation S72, the CPU 10 performs an appeal to TMVGPBR (TKTMSRT) and calculates the starting address for Elementat No. (AOB_ELEMENT#y). Then, when the operation S73 to OBN is to identify KADROV No. x (_FRAME#x), The CPU 10 starts the search of the ADTS header, starting with the start address Elementat No. (AOB_ELEMENT#y). When operation is set S74, the CPU 10 decides whether the user has pressed any key in addition to the key search in the forward direction. If not, the decoder 7 random sequences enters Kudrovo (AOB_FRAMEs) QUADRAT No. x (AOB_FRAME#x) KADROV No.(x+f(t)-1) (AOB_FRAME#x+f(t)-1), and the processing is repeated, performing operations with S62 in S73.

Through the above procedure, perform the increment variables "x" and "y" (#x, #y), which indicate KADROV No. x (AOB_FRAME#x) and ELEMENTAL No. (AOB_ELEMENT#y), and thus carry out the moving location of forward playback. If the user then presses the Play button ("Play"), then, as shown in Fig, decide "No" and complete the treatment according to this scheme, the sequence of operations.

{52-11} the Implementation of the search function of time

Below is a description of the processing when using the search function of time. First carry out the display on the screen of phonograms from Informatsiejobrashchatsja (Default_Playlist_Information), and the user indicates the desired soundtrack. After this soundtrack is specified and the user has powered rotary drive with manual switching, assests the ut code update play time. If the user then presses the Play button ("Play"), then the time code playback at this point is used to set the value of variable "Supised" ("Jmp_Entry"), expressed in seconds.

Then decide whether this soundtrack from many GOITER (AOW) or from one CROP (AOW). If the soundtrack consists of a single CROP (AOW), the calculation of the variables "y" and "x" (##x) implement so that they satisfy Equation 2. After this search QUADRAT No. x (AOB_FRAME#x)starting from the address (y+2)-th position TMVGPBR (TKTMSRT)corresponding to this GOITER (AOW). After this KADROV No. x (AOB_FRAME#x) is found, start playing with QUADRAT No. x (AOB_FRAM#x).

{52-12}

In that case, if the soundtrack consists of many GOITER (AOW), the calculation of the variable "n"(indicating GOITER (AOW)), "y" and "x" (#n,#y,#x) perform in such a way that they satisfy Equation 3. After this search QUADRAT No. x (AOB_FRAME#x)starting from the address (y+2)-th position TMVGPBR (TKTMSRT), corresponding GOITER No. n (AOB#n). After this KADROV No. x (AOB_FRAME#x) is found, start playing with QUADRAT No. x (AOB_FRAME#x).

Below is a description of the case where the playback starts from an arbitrary location GOITER (AOW), for which "Kolker" (FNs_lst_TMSRTE) TIB (BIT) has a value of "80 frames", "Kalkbrener" (FNs_Middle_TMSRTE) TIB (BIT) has a value of "94 frame, and "Cooler" (FNs_Last_TMSRTE) TIB (BIT) has a value of 50 frames".

{52-A, B}

Below is a description of one specific example of using the search function of time, which shows how to perform positioning Elementat (_ELEMENT) and the frame from which to start playback, in the case where the time code playback is specified by means of the swivel drive with manual switching.

As shown in Figa, the user holds the playback device in his/her hand and rotates the rotary disk with step switch thumb of his/her right hand and specifies the playback time is "00:04:40,000 (=280 seconds)". In the case when TIB (BIT) in the IDF (TKI) for this CROP (AOW) has the form shown in Figb, Equation 2 is used as follows:

280 seconds = (Kolker+(Kolker*y)+x)*20 MS=(80+(94*148)+8)*20 MS (280 sec=(FNs_lst_TMSRTE+(FNs_Middle_TMSRTE*y)+x)*20 msec= (80+(94*148)+8)*20 msec). Equation 2 satisfies the following values: y=148 and x=8.

Since y=148, obtained from TMVGPBR (TKTMSRT) element address corresponds Elementos No. 150 (AOB_ELEMENT#150) (=148+2). In this case, the playback at the point indicated by the time code playback 00:04:40,000 (=280,00 seconds), can be carried out by the playback starting from the eighth KUDRAT THE (_FRAME), counted from the address of this element.

{52-14_63_64_65}

This complete explanation of the processing performed by the CPU 10 in response to the user presses the Play button ("Play"). Below is a description of the edit control that is stored in the ROM 4. This program edit control performed when the user presses the "Edit" ("Edit"), and it contains the procedures shown in Fig, Fig, and Fig. Below is a description of processing in this program in accordance with the shown in these drawings, diagrams sequence of operations.

{52-14_63-1} the control Program editing

In that case, when the user pressed the "Edit" ("Edit"), perform an operation S101 of Fig where on the screen shall display a dialog box asking the user which of the three basic edit operations: "delete", "split" and "merge"should be performed. In operation S102, the CPU 10 makes a decision about what action has been taken by the user in response to displaying the dialog box. In this example, suppose that the keys "|<<" and ">>|"on the keypad is also used to specify operations move the cursor "Up" and "Down" (i.e., these keys are used as keys move the cursor Up" and "Down") In the case when the user specifies the operation "delete", the processing is transferred to the execution of an iterative process, consisting of operations S103 and S104.

In operation S103, the CPU 10 decides whether the user has pressed a key "|<<" or ">>|". In operation S104, the CPU 10 decides whether the user has pressed the button "Edit" ("Edit"). In that case, if the user pressed "|<<" or ">>|", processing make the transition from operation to operation S103 S105, at which the specified soundtrack is defined as the soundtrack you want to edit. But if the user pressed the button "Edit" ("Edit"), found on the soundtrack is defined as the soundtrack intended for removal. Shown in Fig processing performed thereby. in case of deletion of such phonogram is TREBLED (TKI_BLK_ATR) each IDF (TKI) of the said phonograms set as "Unused".

{52-14_63-2} the merge Process

In that case, when the user selects the merge process, processing is transferred from the operation S102 to cyclic procedure, consisting of operations S107 on 3109. In a cyclic process consisting of operations S107 through S109, the playback device receives information entered by the user by pressing "|<<" or "&g; >|" and "Edit" ("Edit"). When the user presses " | <<" or ">>|", processing is transferred from operation to operation S107 S110, at which carry out the allocation of the specified records on the display screen. If the user presses "Edit" ("Edit"), then at operation S108 decide "Yes", and processing is transferred to operation S111. At operation S111 noted in the moment phonogram set as the first soundtrack used in this editing process, and the process returns to the execution of an iterative process, consisting of operations S107 through S109.

In that case, when editing the selected second soundtrack, when performing the operation S108 decide "Yes", and processing passes to operation S112 (. At operation S112 (CPU 110 carries out an appeal to the TIB (BIT) in the IDF (TKI) of the first and second phonograms and decides what GOITER (AOW) (1-St type or 2nd type) are, respectively, the beginning and end of each of these phonograms and phonograms, which are located on both sides of these phonograms, if any.

After recognizing the type of each relevant CROP (AOW) in operation S113, the CPU 10 decides whether the location of GOITER (AOW) a specific pattern. In the case when aspolozhena GOITER (AOW) corresponds to one of the four templates, shown on the drawings with Figo on High, from which it is clear that after the merger will not happen a consistent three GOITER (AOW) 2nd type, the first and the second phonogram combined into a single soundtrack in operation S115.

In other words, shown in Fig operation is performed for IDF (TKI) and UPFLUSH (DPL_TK_SRP)that meet these GOITER (AOW). The Union of the set of phonograms, selected for editing, a single phonogram shall be implemented by overwriting TREBLED (TKI_BLK_ATRs) in the IDF (TKI). In that case, if the location GOITER (AOW) does not match any of the drawings with Figo on Figg templates, which means that after the merger there will be three or more GOITER (AOW) 2nd type, the CPU 10 decides that the United phonogram may cause a buffer underrun, and thus the merge process will be terminated.

{52-14_64-1} the process of dividing the phonogram

When the user indicates that the soundtrack should be separated, when the processing is transferred from the operation S102 to cyclic procedure, consisting of operations with S116 in S117. In a cyclic process consisting of operations with S116 in S117, the playback device receives information entered by the user by pressing "|<<" or ">>|" and "Edit" ("Edit").

In that case, it is when the user presses "|< <" or ">>|", processing is transferred from operation to operation S116 S118, in which the selected soundtrack set as intended for editing. If the user presses "Edit" ("Edit"), then at operation S117 decide "Yes", and processing is transferred to the operation S119.

When the operation S119 marked the soundtrack is defined as the soundtrack, which is designed for editing, and processing passes to operation S120, at which to start playback of the phonogram. In operation S121, the playback device receives information entered by the user through the key Label ("Mark").

When the user presses the "Mark", "Mark") the reproduction of a phonogram pause, and when the processing is transferred to the execution of an iterative process, consisting of operations S122 and S123. In operation S122, the playback device receives data about user actions performed through the rotary disk with manual switching. When the user rotates the rotary disc with manual switching, when the operation S124 update time code playback in accordance with the rotation angle of the rotary disk with manual switching.

After this cycle p is ocedure, consisting of operations S122 and S123, repeat. If the user presses "Edit" ("Edit"), then processing is transferred from the operation S123 to the operation S125, in which the boundary separating set the time code playback, which was displayed when the user presses the Edit ("Edit"). It should be noted that for this method of installation boundaries of separation can be provided by the function Cancel ("Undo"), allowing the user to cancel the selected split line.

Thereafter, in operation S126 perform processing, the explanation of which is given by reference to Fig at which updates SWFU (DPLI) and IDF (TKI), by dividing the selected tags.

{52-14_65-1} the Process of compiling the playlist

In that case, when the user selects the option of compiling the playlist, the process is transferred to the procedure shown in the diagram of the sequence of operations of Fig. Specified in this scheme, the sequence variable "k" is used in this scheme, the sequence of operations to indicate the position of the phonogram for the playback order specified by the edited playlist. Shown in the diagram of Fig sequence Opera is s start with before the process can proceed to the cyclic procedure, consisting of operations on S132 set s134, perform an operation S131, in which are set the initial value of the variable k is equal to "1".

In a cyclic process consisting of operations S132 on set s134, the playback device receives data about the user's actions performed by pressing "|<<", ">>1", "Edit" ("Edit") and Stop ("Stop"). In that case, when the user pressed "|<<" or ">>|", in the process moving from the operation S132 to the operation S135, in which in accordance with the pressing of button "|<<" or ">>|" specify a new soundtrack. If the user pressed "Edit" ("Edit"), then in operation S133 decide " Yes " and in the process move further to the operation S136.

When the operation S136 soundtrack specified at the time the user presses "Edit" ("Edit"), are chosen as k-phonogram in the order of playback. Then, when the operation S137 perform the increment variable k and the process returns to the execution of an iterative process, consisting of operations on S132 set s134. This procedure is repeated so that a consistent choice of the second, third and fourth tags. If, after whom rosedene specifying multiple phonograms, intended for playback in the order specified by a new playlist, the user pressed the "Stop" ("Stop"), then processing is transferred from operations to set s134 operation S138 in which carry out the generation of ISWF (PLI), consisting of UPPGIFT (PL_TK_SRPs), which identifies those phonograms Treaty IDF (TKI).

{66-1} recorder

Below is a description of one example of a recording device for card 31 flash memory. On Fig shows one of the following as examples of types of recording devices. This recorder can be connected to the Internet and is a standard personal computer, which can receive the encrypted directory ED (the original audio data) (SD_Audio), the transfer of which to the recording device through the communication channels implemented by the service music distribution electronically or transport stream audio data, in which the recording device through the communication channels implemented by the distribution service music electronically.

{67-1} hardware capture devices On Fig shows the hardware composition of a recording device.

As shown in Fig, the recorder contains a connector Board 21 for connection of the recording device with the card 31 flash memory, RAM is perative storage device 22, fixed disk device 23 that is designed for storing the program management account, which performs centralized control of the recorder, analog-to-digital Converter 24, which is designed to handle analog-to-digital conversion is entered through the microphone sound data that enables the creation of data PCM (pulse-code modulation), the encoder 25 UCSI (advanced audio coding information (AAS)), which encodes PCM data in units having a constant duration of time, and the assignment of ADTS headers to create Kudrovo (AOB_FRAMEs), device 26 encryption is designed to encrypt Kudrovo (_frames with the use of various Keys file (FileKey) for each Blocat (AOB_BLOCK), the modem 27 to implement receiving a transport stream of audio data in the case when the distribution service music electronically transferred to the recording device through the communication line encrypted directory ED (the original sound data (SD Audio), or when the distribution service music electronically transferred to the recording device via the communication line of the transport stream of audio data, the CPU 28 to perform centralized management of device entries, clavata is at 29 to receive user input and device 30 visual display.

{67-2} Input circuit RT1-RT4

In the case when the distribution service music electronically transferred to the recording device through the communication line encrypted directory ED (the original audio data) (SD_Audio), which must be recorded in the data area and in the area of identification, then immediately after the good reception of the encrypted directory ED (SD_Audio) the recorder can record the encrypted directory ED (SD_Audio) in the data area and the area of the identification card 31 flash memory.

However, in cases (1) when the distribution service music electronically in the device records the transport stream of audio data in a format that does not match the catalog ED (SD_Audio), (2) when the recorder was put data in the format PCM (PCM), or (3) when the recording device is carried out record analog audio data in the recording device to record a transport stream of audio data in the card 31 flash memory use the following four input channel.

{67-3} Input path RT1

The input path RT1 is used when the distribution service music electronically transferred to the recording device through the communication line encrypted directory ED (SD_Audio), or when the distribution service music electronically implemented per the cottage in the recording device through the communication line of the transport stream of audio data. In this case, contained in the transport stream Madryt (AOB_FRAMEs) is encrypted in such a way that for Kudrovo (AOB_FRAMEs) different GOITER (AOW) used different Keys file (FileKeys). As to perform the encryption or encoding the encrypted transport stream is not necessary, can be performed directly memorizing catalog ED (SD_Audio) or a transport stream of audio data in the RAM 22 in an encrypted state.

{67-4} Input path RT2

The input path RT2 used in the case where the input sound data is performed via the microphone. In this case, perform analog to digital conversion is entered through the microphone sound data through analog-to-digital Converter 24, creating a data PCM (PCM). Then, in order to create Madryt (AOB_FRAMEs), carry out the encoding of the PCM data by the coding device 25 UCSI (AAS) and the assignment of ADTS headers. After that, the device 26 encryption encrypts Kudrovo (AOB_FRAMEs) using different keys file (FileKey) for each of Kudrovo (AOB_FRAMEs) in various Pilot (AOB_FILEs), resulting in the create encrypted audio data. After this exercise memorizing the encrypted audio data in the RAM 22.

{67-5} Input path RT3

The input path RT3 used in the case when the device is recording who enters the data PCM data read from a compact disc (CD). Since the input data is carried out in the format of PCM (PCM), the data can be directly entered in the encoder 25 UCSI (AAS). To create Kudrovo (AOB_FRAMEs) coding these data, the PCM through the coding device 25 UCSI (AAS) and the assignment of ADTS headers.

After that, the device 26 encryption encrypts Kudrovo (AOB_FRAMEs) using different keys file (FileKey) for Kudrovo (AOB_FRAMEs) in various Pilot (AOB_FILEs), resulting in the create encrypted audio data. After this exercise memorizing the encrypted audio data in the RAM 22.

{67-6} Input path RT4

The input path RT4 used in the case when the card 31 flash memory record a transport stream, is introduced into the burner through one of the three input paths RT1, RT2, and RT3.

This remembering of the audio data accompanied by the creation of the IDF (TKI) and Informatsiejobrashchatsja (Default_Playlist_Information). As for the playback device, the ROM perform the memorization of the basic functions that provide the functionality of the recording device. That is, a fixed disk device 23 remember the write program, which contains characteristic for the recording device, procedure, namely, the implementation of the of the records GOITER (AOW), administrator of phonograms (TrackManager) and administrator of the playlist (PlaylistManager).

{67-7_68} Processing performed in the recording device

Description of the processing in the writing process, in which the circuit Board 31 of the flash memory are recording a transport stream received via the input paths RT1, RT2, RT3 and RT4 below with reference to the sequence diagram of operations of Fig showing this processing.

In this scheme, the sequence of operations used the following variables: "Nomercury" ("Frame_Number") and "Obyemnaya" ("Data_Size"). Variable Nomercury (Frame_Number) is used to control the total number of those Kudrovo (AOB_FRAMEs), which had already been recorded in FILTON (AOB_FILE). Variable Obyemnaya (Data_Size) is used to control the amount of data those Kudrovo (_frames), which had already been recorded in FILTON (AOB_FILE).

Processing in this scheme, the sequence of operations beginning with operation S200, in which the CPU 28 performs the generation of the playlist, the default (DefaultPlaylist) and administrator of phonograms (TrackManager). In operation S201, the CPU 28 initializes a variable z (#z): (z←1). In operation S202, the CPU 28 performs the generation of the FILE SAB No. z (_FILE#z) and stores it in the data area of the card 31 flash memory. At this point in the element SC is the dialogue from the Catalogue ED (SD_Audio), located in the data area, specify the file name, the file name extension and the number of the first cluster for Filtb No. z (AOB_FILE#z). Then, in operation S203, the CPU 28 performs the generation of the IDF No. z (TKI#z) and stores them in the administrator of phonograms (TrackManager). In operation S204, the CPU 28 performs the generation UPFLUSH No. w (DPL_TK_SRP#w) and stores it in Informatsiejobrashchatsja (Default_Playlist_Information). Then, in operation S205, the CPU 28 initializes a variable "I" (#): (#←1), and at operation S206, the CPU 28 initializes Nomercy (Frame_Number) and Abhimaan (Data_Size): (Nomercury←0, Obyemnaya←0).

In operation S207, the CPU 28 decides whether completed if the input transport stream of the audio data for recording in Filetab No.... (_FILE#). In the case when the input transport stream of audio data encoded by the coding device 25 UCSI (AAS) and encrypted by the device 26 encryption in the RAM 22, not finished and you want to continue recording data cluster, then at operation S207, the CPU 28 decides "No", and processing is transferred to operation S209.

In operation S209, the CPU decides whether the amount of audio data UCSI (AAS), which accumulated On The 22, equal to at least the size of the cluster. If this is true, then the CPU 28 decides "Yes" and the procedure passes to operation S210, when the card 31 flash memory write audio data, UCSI (AAS), is equal to the cluster size. Then processing passes to operation S211.

In that case, when the RAM 22 is not accumulated a sufficient amount of audio data UCSI (AAS), operation S210 miss and processing are transferred to the operation S211. In operation S211, the CPU performs the increment Nomercy (Frame_Number) (Nomercury←Nomercury+1) and increases the value of the variable Obyemnaya (Data_Size) on volume data QUADRAT (AOB_FRAME).

After the update, perform the operation S212, in which the CPU 28 decides as to whether the value of the variable Nomercury (Franie_Nuniber) the number of frames that is set in "Kolker" (FNs_Middle_TMSRTE), with the value "Kolker" (FNs_Middle_TMSRTE) installed in accordance with the sampling rate used when encoding the transport stream of audio data. In that case, if the value Nomercy (Frame_Number) has reached the number of frames specified in the "Kolker" (FNs_Middle_TMSRTE), at operation S212, the CPU 28 decides "Yes". If not, the CPU 28 decides "No",and the process returns to operation S207. Therefore, the processing procedure performed by operations S207 in S212, repeat until, while, when performing an operation S207, or operation S212, will not be decided "Yes."

When a variable Frame Number (Frame Number) reaches the value "Kolker" (FNs_Middle_TMSRTE), then at operation S212, the CPU 28 decides "Yes", and processing is transferred from the operation operation S212 S213, in which memorizes variable Obyemnaya (Data_Size) in TMVGPBR (TKTMSRT) IDF No. z (TKI#z) in the form Elementar No. y (TMSRT_entry#y) for Elementat No. (AOB_ELEMENT#y). Before you perform an operation S215, which produce a check as to whether the variable "I" (#) "252", perform an operation S214, in which the CPU 28 performs the increment variable "y" (#): (#←#+1).

Value "252" is used because it represents the maximum number Lamentoso (AOB_ELEMENTs), which may be stored in one GOITER (AOW). If the variable "Y" (#) has a value less than S52, the process passes to operation 3216, at which the CPU 28 decides whether the encoded audio data pause with a pre-set duration, that is, did the audio data between the phonograms. In the absence of such a long pause, perform a repetition of the treatment is otki, consisting of operations S206 in S215. In that case, if the variable "y" (#) reached values of 252, or encoded audio data there is a pause of predetermined duration, performing one of the operations S215 and S216 decide "Yes" and the procedure is transferred to the operation S217 at which carry out the increment of the variable z (#z): (#z←#z+1).

Then repeat the processing performed by operations S202 to S216, for increased per unit variable z (#z). By repeating such processing, the CPU 28 can perform sequential write in the card 31 flash memory GOITER (AOW), which contains the set of lamentoso (AOB_ELEMENTs).

When the transmission of the transport stream of audio data by the coding device 25 UCSI (AAS), device 26 encryption and modem 27 is completed, it also means that it is completed and the input transport stream of audio data intended for recording in Filetab No. z (AOB_FILE#z), therefore, when the operation S207 decide "Yes" and the procedure is transferred to the operation S208. In operation S208, the CPU 28 performs memorizing the value of a variable Obyemnaya (Data_Size) in TMVGPBR (TKTMSRT) IDF No. z (TKI#z) in the form Elementar No. (TMSRT_Entry#y) for Elementat No. (AOB_ELEMENT#y). After saving accumulated in the RAM 22 of the sound data in the file GOITER (_file, the corresponding GOITER No. z (AOB#z), the processing in this scheme, the sequence of operations completes.

As a result of said processing carried out by memorizing the encrypted transport stream audio data in the circuit Board 31 flash memory. Then use the following procedure provides the memorization in the field to identify Key file (FileKey), which is required for decrypting the encrypted transport stream of audio data.

After you have completed the input transport stream of audio data through the input path RT1, the service provider distribute music electronically transmits to the recording device file (s) GOITER (AOW file(s)), file storage ADFG (TKMG), the file storage ASWF (PLMG), and the file storing the encryption key, which is stored various keys file (FileKey), one for each CROP (AOW). The CPU 28 receives these files and writes files) GOITER (AOW file(s)), file storage ADFG (TKMG) and file storage ASWF (PLMG) in the region of the user in the circuit Board 31 flash memory. In the field of identification, the CPU 28 writes only the file storing the encryption key, which is stored various keys file (FileKey), one for each CROP (AOW).

In that case, if the input audio data is performed via the input path RT2 or RT3, whenever you begin coding a new CRAW (AOW), the CPU 28 Khujand who performs the generation of different keys file (FileKey) and sets the value derived from the key generation device 26 encryption. Besides the fact that this key file (FileKey) used in the device 26 encryption to encrypt the current CROP (AOW), it remembers in accordance with Sapolil (FileKey Entry in the storage file encryption key, which is located in the area of identification.

According to the above implementation of the present invention, encryption of files, in which zapomnienia (AOW), carried out using different encryption keys, so if the decrypted and secret encryption key used to encrypt a single file, declassified key encryption can be used for decryption of the file that stores one GOITER (AOW), which declassification of key is not to act in relation to other CROP (AOW), which are stored in other files. This minimizes the damage caused by the declassification of one of the encryption keys.

It should be noted that, although the above description refers to the example system, which is believed to be the most effective embodiment of the present invention, the invention is not limited to this system. There may be various modifications within the scope of the patent claims of the invention and examples of such modifications (a) through (e).

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

(b) In the above embodiment, described sound data had the AAC (advanced audio coding information - UKTI), but the present invention can also be applied to audio data having a different format, such as MDE (MPEG1 Audio Layer-3), Dolby-GCC or DTS (digital theater system).

(C) Although the description has been given that the file storage ADFG (TKMG), and the file storage ASWF (PLMG) receive from the service provider distribute music electronically completed, the transmission of basic information used to create ADFG (TKMG), ASWF (PLMG) can be carried out together with the storage file encryption key, which is stored various encryption keys, one for each CROP (AOW). After that, the recording device can perform the processing of this information to get ADFG (TKMG), ASWF (PLMG), which it then writes to flash memory card.

(g) 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 functions of recording devices, and the mustache is the unit of account in the form of a personal computer can be equipped with the functions of the playback device. In addition to the portable playback device and recording device on the basis of the personal computer, the functions of the playback device and recording device can also be equipped with communication devices capable of downloading content from the network.

As one example, the functions of the playback device and recording device described in the above embodiment may be equipped with a mobile telephone device capable of Internet access. As in the above-described embodiment, this mobile phone can memorize content, the download of which is carried out via the wireless communications network, in the circuit Board 31 flash memory. Also, although the above described embodiment, the recording device is equipped with a modem 27 to connect to the Internet, instead it can be used by any other device capable of connecting to the Internet, for example, the terminal adapter of the connection line (ISDN digital network integrated services - CSCW).

(d) Shown in the diagrams of the sequence of operations depicted in Fig-58, Fig, Fig-65 and Fig, procedures may be performed by executable programs, marketing and sales which can be made is recorded on the recording medium. This recording medium may be a charge integrated circuit (1C card), an optical disk, floppy disk, or similar device with the programs recorded on the recording medium, and the use of exercise after they are installed in standard computer equipment. By performing processing in accordance with such established programs standard computer equipment can perform the same functions as the playback device and the recording device described in the above embodiment.

(e) Although in the above embodiment, described variant, in which the circuit Board 31 flash memory remember many GOITER (AOW) and many keys file (FileKeys), a necessary condition is by memorizing only one CROP (AOW) and one Key file (FileKey). Also not a prerequisite encryption GOITER (AOW), so memorizing GOITER (AOW) in the circuit Board 31 of the flash memory can be carried out in the AAC (advanced audio coding information - UKSI).

The SECOND OPTION of carrying out the INVENTION

In the first embodiment contains only a brief mention of the various memory areas in the circuit Board 31 flash memory, and not the description of the internal arrangement of the used hardware. But is this second embodiment, the detailed description of the hardware Board 31 flash memory.

{69-1} Hardware device card 31 flash memory

On Fig shows a hardware device card 31 flash memory. As shown in Fig, fee 31 flash memory contains three integrated circuits (IC), namely, IP 302 control, the flash memory 303, and a ROM (read only memory) device 304.

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

IP 302 control is a control scheme consisting of active elements (logic elements), and contains the device 321 authorized access, the decoder 322 commands, the device 323 storage master key, device 324 control access to a specific area, the device 325 control access to the area identification device 326 to control access to areas not requiring identification and circuit 327 encryption/decryption.

Device 321 authorized access is a scheme which provides mutual authentication in the format of the request-confirmation device that tries to access the circuit Board 31 flash memory. This device is in 321 authorized access contains a random number generator, simovski etc. and authenticates the device and trying to access the circuit Board 31 of the flash memory, determining whether in this device the same simovski as the device 321 authorized access.

In this case, mutual authentication in the format of the request-confirmation means for authenticating the second device, the first device transmits to the second device data request. The second device performs the processing of the request data in predetermined ways than proves its authenticity, and transmits the resulting data to the first device as the response data. The first device compares the data request with response data and decides whether to admit the second device is authentic. Because this process is a mutual authentication, the processing then repeat, changing roles of devices in places.

The decoder 322 is a controller that contains a decoding scheme, a control circuit, etc. that interpret and execute the command (a command to the card 31 flash memory), an input of which is made through the contact TEAM of the connector. The decoder 322 commands manages devices 321-327 in IP 302 management in accordance with the type of the entered command.

Teams that p is given in charge 31 flash memory, contain the team responsible for reading, writing or erasing data in the flash memory 303. As examples of the related commands to read and write data can be given commands the Number of elements in the address of the protected read" ("SecureRead address count") and the Number of elements in the address is write protected" ("SecureWrite address count"), through which access to the field of identification, and with the Number of elements in the read address" ("Read address count") and the Number of elements in the address write ("Write address count") provide access to areas that do not require identification. In these commands, the term "address" refers to the number of the first sector in which the access, the read (or write), and the term "number of elements" means the total number to be read (or written) sectors. In this case, the sector represents a single element of reading and writing data in the circuit Board 31 flash memory equal in this example, 512 bytes.

In the device 323 storing the master key in advance remember the master key a in an encrypted state. The master key is an encryption key used to encrypt the identifier (ID) of the media. When the card 31 flash memory connected to the device, the master key a passed to the device in encrypted form. The master key a is encrypted in such a way the om, who allows his decoding by only the device that receives the master key by using a special key information (usually called the "key to the device ("device key")).

Device 324 control access to a special area is an electronic circuit that performs the reading of the identifier (ID) of the media stored in the ROM 304, which created a special area. Identifier (ID) of the medium read device 324 control access to a specific area, pass next to the device that is connected to plate 31 flash memory, which then encrypts the identifier (ID) of the medium using the master key obtained by decrypting the encrypted master key using the key.

Device 325 control access to the area identification device 326 to control access to areas not requiring identification, are electronic circuits which perform data reading and writing data in the flash memory 303 for, respectively, the identification area and the area that does not require identification. This device 325 control access to the area identification device 326 access control area, do not require the identification, transfer data to an external device (for example the EP, in the recording device and the playback device described in the first embodiment, and from him.

It should be noted that each of these devices 325 and 326 access control contains an internal buffer that can make memorizing one data block, and the input and output is performed through the connector contacts with symbols

Data1 has on DANNIE (DATA1 - 4). From the point of view of logical operations, the input and output carry out sector-wise, but if you overwrite the contents of the flash memory 303 input or output of data is carried out in blocks (each block has a volume of 32 sectors (16 KB)). In a more detailed manner, in the case when overwriting data produced in one sector, then the corresponding block is read from the flash memory 303 and remember in the buffer corresponding device access control, this unit is removed from flash memory, perform the rewriting of the corresponding sector in the buffer memory, and then a block from the buffer memory write back to the flash memory 303.

Scheme 327 encryption/decryption performs encryption or decryption using the master key a stored in the device 323 storage master key, which is administered device 325 control access to the area of identification or device 326 to control access to areas not requiring the th identification. In the case when it is necessary to write data in the flash memory 303, the scheme 327 encryption/decryption encrypts data and their recording in the flash memory 303. In the opposite case, when it is necessary to read data from the flash memory 303, the scheme 327 encrypt/decrypt decrypts data. This scheme 327 encryption/decryption need to prevent users from running unauthorized activity, for example, disassembly of the card 31 flash and direct analysis of the contents of the flash memory 303 with the aim of obtaining passwords stored in the identification area.

{69_70} a Sequence of information exchange when playing GOITER (AOW)

On Fig shows the sequence of information exchange that is executed when read by a playback device that is connected to plate 31 of the flash memory, the encryption key, the file Key (FileKey) and playing GOITER (AOW).

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

The playback device, receiving the protected identifier (ID) of the media uses to decrypt the protected identifier (ID) n is sites the key 211A device, which is stored therein (sc3). Used in the decryption process the decryption algorithm corresponds to the encryption algorithm that was used when generating the encrypted master key b stored in the circuit Board 31 flash memory, so if your playback device key 211A device is a need to use the key (that is the correct key), then by performing such decoding the playback device will be able to get the master key.

After receiving a master key, the playback device outputs in charge 31 flash memory a special command read out the identifier (ID) of the media (sc4). Device 324 control access to a special area receives the identifier (ID) of the media from the ROM 304 Board 31 flash memory and passes it to the playback device (s5). Then the scheme 327 encryption/decryption encrypts the identifier (ID) of the medium using the master key, which is obtained via the above decryption process (sc6). This encryption uses the same algorithm as the algorithm that was used when generating the protected identifier 343 (ID) of the media stored in the circuit Board 31 flash memory. The resulting protected identifier (ID) of the medium is exactly the same as for ewenny ID 343 (ID) of the media from the card 31 flash memory.

Then the playback device, which managed to get a protected identifier (ID) of the medium, performs mutual authentication with the device 321 authorized access of the card 31 flash memory (s7). This process leads to the fact that as the playback device, and the device 321 authorized access contain (a) information (YES/NO) (OK/NG), which indicates, whether there was a successful authentication of the other device, and (b) changing over time secure key, the contents of which depends on the result of authentication.

In case of a successful mutual authentication, the playback device performs the generation of the access command to the field of the identification card 31 flash memory. As one example may be cited the case in which when data is read from identifying the playback device encrypts the parameters (i.e., address representing an address, consisting of 24 bits, and "number of elements", the data length which is equal to eight bits) commands the Number of elements in the address of the protected read" ("Secure-Read address count") using a secure key (sc8), and links these with the characteristic parameters of this command (i.e., code of 6 bits, indicating that this command is the command "Protected read" ("SecureRead")), POPs the Lord encrypted command (sc9), which the playback device transmits at cost 31 flash memory (sc10).

After receiving this encrypted commands fee 31 flash memory identifies the type of command on the ground (sc11). In this example, the card 31 flash memory specifies that this command is the command "Protected read" ("Secure-Read") to read from the identification area.

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

The algorithm that was used to decrypt the parameters that correspond to the encryption algorithm that was used by the playback device when generating the encrypted command, so in the case of a successful mutual authentication, that is, when a secure key Board 31 flash memory corresponds to the protected key in the playback device, the parameters obtained by this decryption will be the settings used by the playback device.

When receiving a command containing a valid parameters, device 325 control access to identifying accesses to the sectors specified by reliable parameters, and reads the C identifying the encryption key Lucie (FiieKey), stored in these sectors. Through a scheme 327 encrypt/decrypt encrypt the encryption key Lucie (FileKey)stored in the file "AOBSA1.KEY" in the field of identification (sc15), using a secure key (s14)obtained by the mutual authentication. After that, the device 325 control access to the area identify transfers the encryption key Lucie (FileKey)stored in the file "AOBSA1.KEY" in the field of identification, in the playback device (s16).

The playback device decodes (s18) the encryption key Lucie (FileKey), which was carried out by using a secure key (sc17)obtained by the mutual authentication. Due to the fact that used here, the decryption algorithm corresponds to the algorithm that was used - 31 flash memory to encrypt the encryption key Lucie (FileKey), can be obtained, the original encryption key Lucie (FileKey). Then carry out the decoding of the received encryption key Lucie (FileKey) using the master key b and identifier (ID) of the medium and the result of the encryption key Lucie (FileKey) (sc20).

After the encryption key Lucie (FileKey) and from the area, do not require the identification read GOITER (AOW)corresponding to the encryption key Lucie (FileKey) (sc21), vistanaut RA the encryption GOITER (AOW) using this encryption key Lucie (FileKey) and simultaneously perform the music.

{69_70_71} Detailed sequence information exchange with mutual authentication

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

The authentication device playback device 321 authorized access of the card 31 flash memory carries out the generation of random numbers (s30) and transmits this random number in the playback device as a data request (sc50). In order to prove their own authenticity, the playback device encrypts the data request (sc31) and passes the result to the device 321 authorized access in the circuit Board 31 flash memory as the response data (sc32). Device 321 authorized access in the circuit Board 31 flash memory encrypts a random number, referred to them as query data (s33), and compares it to the encrypted random number with response data (sc34).

In that case, when the encrypted random number coincides with the data response, the playback device is found to be true ("YES"), and then charge 31 flash memory will perceive access command to the field of identification obtained from from the trojstva play. Otherwise, when the encrypted random number and the reply data do not match, the playback device will not be recognized as genuine, and then charge 31 flash memory will reject any command access to the field identification received from the playback device.

The same authentication procedure performs the playback device to confirm the authenticity of the card 31 flash memory.

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

The playback device encrypts a random number, referred to them as query data (sc43), and compares it to the encrypted random number with response data (sc44).

In that case, when the encrypted random number and the response data are the same, the card 31 flash memory ("YES") will be recognized as genuine, and then the playback device will attempt to access the field of the identification card 31 flash memory. Otherwise, when C is an encrypted random number and the reply data do not match, fee 31 flash memory will not be recognized as legitimate ("NO"), and the playback device will not attempt to access the field of the identification card 31 flash memory.

In that case, if the card 31 flash memory and the playback device are genuine, when mutual authentication both devices will use the same encryption algorithm. And the card 31 flash memory, and the playback device performs a logical EXCLUSIVE OR operation on the two encrypted random numbers (i.e., over an encrypted random number, which is transferred to another device as a data request over a random number that has been encrypted with the purpose of checking the received response data)used in the process of mutual authentication (sc45, sc46), and the result of the operation "EXCLUSIVE OR" set as trusted key, which is used in the access area identification card 31 flash memory. Thus, the same secure key Board 31 flash memory in the playback device will be installed only if successful mutual authentication. Because in this way can be made sharing changed over time (that is used only for this session) trusted key, then a necessary condition for access is as to the field of identification is successful, the procedure of mutual authentication.

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

In the above embodiments, the implementation of the existing data, which are remembered in the field of identification and for which it is necessary to ensure copyright protection, and other data that is remembered in the field that do not require identification. This allows cost semiconductor memory, in which you can store as works of art in digital form, requiring the protection of copyright and literary works in digital form, are 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 this field of technology is the obvious possibility of various modifications and modifications. Therefore, if such variations and modifications are within scope of patent claims of the present invention, they should be considered is the quality under him.

INDUSTRIAL APPLICATION

Fee semiconductor memory of the present invention is adapted for use mainly in the field of consumer electronics as the recording media for recording music or other material, the distribution of which shall by electronic means or otherwise. Device recording and playback of the present invention allow consumers to fully utilize the capabilities of such fees semiconductor memory.

1. Fee semiconductor memory that stores at least one audio soundtrack that contains the protected area, access to which can be carried out by a device that is physically connected to - semiconductor memory and having a means of reading the data stored in it, only if you have installed the authenticity of this device, and in the protected area stores a sequence of encryption keys, consisting of a set of encryption keys arranged in a predetermined order, and an unprotected area, access to which may be implemented by any device that is physically connected to - semiconductor memory and having a means of reading the data stored in it and in an unsecured area stores at least one audio Phono is the program and control information, at least one audio soundtrack contains a lot of encrypted audio objects, and the control information indicates which encryption key from a set of encryption keys corresponds to each audio object stored in an unsecured area.

2. Fee semiconductor memory according to claim 1, in which the control information indicates for each audio object, the location of the sound object in memory and the number indicating the position of the encryption key corresponding to a given audio object in the sequence of encryption keys.

3. Fee semiconductor memory according to claim 2, in which each audio soundtrack also contains (1) information about the attribute and

(2) layout information for each audio object in the audio soundtrack, and information about the attribute indicates which type of the following types : type (a)type (b), type (type) and (g) belongs to each audio object, and the type (a) represents the entire audio playback, type (b) represents the first part of the audio soundtracks, type (V) is the average of the sound tracks, and the type (g) represents the final part of the audio phonogram and information about the layout for each sound object that belongs to the type (b) or type (b), the decrees of the AET, what sound object should then sound object.

4. Fee semiconductor memory according to claim 3, in which a multitude of sound objects contains at least one audio object containing only reliable data for replay, and at least one audio object containing (1) reliable data and (2) unreliable data located before and/or after reliable data, and playback of false data to carry out is not required, with each sound the soundtrack also contains information about the blocks for each sound object from the sound of the phonogram, and this information blocks contains the offset measured relative to the location corresponding audio object in memory that is indicated in the control information, and length information, which indicates the length of reliable data, starting from the position specified by offset, and information about the attribute of the audio object indicates whether data specified by offset and length information (a) correspond to the entire audio track, (b) correspond to the first part of the audio soundtracks, and (C) correspond to the middle part of the sound of the phonogram, or (d) correspond to the end portion of an audio recording.

5. Fee semiconductor memory according to claim 4, in which the sound phonograms can be carried out in accordance with standard playback mode or intermittent playback mode and standard play mode is a mode in which the playback of reliable data in the audio objects constituting the sound of the phonogram, carried out without any omissions of data and intermittent playback mode is a mode in which repeatedly perform (1) skip reliable data equivalent to the first period, and (2) reproduction of reliable data equivalent to the second period, and each audio soundtrack further comprises many pieces of information about the entry points that indicate where the internal layout of reliable data inside the sound object at intervals equivalent to the first period, and information about the blocks for the sound object, which is set to the offset, which indicates the difference between (1) the internal location specified by the first piece of information about the entry points for the sound object, and (2) a location in memory for the sound object, specified in the control information, and the length of the valid data, the start position which is s specified by the offset.

6. The playback device Board for a semiconductor memory containing (1) a protected area, access to which can be carried out by a device that is physically connected to - semiconductor memory and having a means of reading the data stored in it, only if you have installed the authenticity of this device, and in the protected area stores a sequence of encryption keys, consisting of a set of encryption keys arranged in a predetermined order, and (2) unprotected area, access to which may be implemented by any device that is physically connected to - semiconductor memory and having the means to read the stored data, and in an unsecured area stores at least one audio recording, and control information, and at least one audio soundtrack contains a lot of encrypted audio objects, and the control information indicates which encryption key from a set of encryption keys corresponds to each audio object stored in an unsecured area, and referred to the playback device contains a means of reading for enjoyment reading from the Board of the semiconductor memory of one of the many sound objects contained in the about at least one sound recording, and reading from a sequence of encryption keys, which are stored in a secure area Board semiconductor memory, the encryption key that corresponds to the read out sound object, the decryption tool for the implementation of the decryption few of the sound object using the read encryption key, and a means to play back the decoded audio object, in which, after decoding a matter of the sound object by means of decryption tool reading is reading another sound object, contained in a sound recording, is reading from a sequence of encryption keys, the encryption key corresponding to another sound object, and transmits again a few key encryption decryption tool.

7. A recording device for recording in the cost of semiconductor memory sound works, consisting of multiple items of informational content, and the recording device contains encryption tool that assigns to each element of the information content contained in the audio piece, at least one of the multiple encryption keys and the encryption of each item of information content using keys sirova the Oia, assigned to the elements of the information content, thus creating a lot of sound objects, and writer, writes in the cost of semiconductor memory multiple encryption keys in a sequence of encryption keys and a multitude of audio objects in the form of at least one audio recording.

8. The recording device according to claim 7, in which after the implementation of recording a set of encryption keys and a multitude of audio objects, the writer also writes in the cost of semiconductor memory control information, and control information indicates for each audio object, the correspondence between the region on the Board of a semiconductor memory in which is stored the sound object, and the memory location of the encryption key corresponding to a given audio object.

9. The recording device of claim 8, in which for each audio object, the writer also writes in the cost of semiconductor memory information about the attribute and the layout information, and information about the attribute for each sound object indicates which type of the following types : type (a)type (b), type (type) and (g) he belongs, and the type (a) represents the entire audio playback, type (b) represents the first part of the audio soundtracks, type (in a middle part audio soundtracks, and type (g) represents the final part of the audio soundtracks, and information about the layout for each sound object that belongs to the type (b) or type (b), indicates the sound object should then sound object.

10. The recording device Board for a semiconductor memory that contains the first generation facility to consistently generate audio frames from the input signal, the reception of which is produced outside the recording device, and the audio frame represents the least amount of data for which can be performed independent decoding, the writer to create the file in the circuit Board of the semiconductor memory and writing to the file audio frames created during subsequent generation, the second generation facility to generate executed whenever the recorder made an entry in the file, a predetermined number of audio frames, pieces of information about the input data, which indicated the data length of the audio element, consisting of recorded sound file frames, in which, whenever the second generation device was generating a predetermined number of pieces of information about the input data, the recorder creates a new file and writes to a new file, the audio frames is using serial generation which is done after that.

11. Read through a computer storage medium storing a program which, when performed by a computer performs the playback through the computer information from the Board, a semiconductor memory, and the fee semiconductor memory includes (1) the protected area, access to which can be carried out by a device that is physically connected to - semiconductor memory and having a means of reading the data stored in it, only if you have installed the authenticity of this device, and in the protected area stores a sequence of encryption keys, consisting of a set of encryption keys arranged in a predetermined order, and (2) unprotected area to which may be implemented by any device that is physically connected to - semiconductor memory and having a means of reading the data stored in it, and in an unsecured area stores at least one audio recording, and control information, and at least one audio soundtrack contains a lot of encrypted audio objects, and the control information indicates which encryption key from a set of encryption keys corresponds to each audio object stored in the unprotected region is STI, moreover, the above program contains the following operations: a read operation in which carry out the reading of the Board of the semiconductor memory of one of the many sound objects contained in the at least one sound recording and reading of a sequence of encryption keys stored in the secure area Board semiconductor memory, the encryption key that corresponds to the read audio object, the operation of the decryption, which are deciphering a few of the sound object using the read encryption key, and the playback operation, at which reproduction of the decoded audio object, and after decryption operation is completed deciphering a few of the sound object, perform a read operation in which the reading of another sound object, contained in a sound recording, of a sequence of encryption keys read out the encryption key corresponding to another sound object, and transfer again read the encryption key in the decryption operation.

12. Read through a computer storage medium storing a program that when executed through the computer writes information through a computer is in charge of semiconductor memory, moreover, the program contains the following operations: operation of encryption in which each element of the information content contained in the musical piece, assign at least one of the multiple encryption keys, and each item of content encrypted using the assigned element content encryption keys, resulting in creating a lot of sound objects, the write operation, which cost semiconductor memory write multiple encryption keys in a sequence of encryption keys and a multitude of audio objects in the form of at least one audio recording.

13. Read through a computer data carrier according to item 12, in which, after recording a variety of encryption keys and a multitude of audio objects, when write operations also are recorded in cost of the semiconductor memory control information, and control information indicates for each audio object, the correspondence between the region on the Board of a semiconductor memory in which is stored the sound object, and the memory location of the encryption key corresponding to a given audio object.

14. Read through a computer data carrier according to item 13, in which for each sound object is when performing write operations also are recorded in cost of the semiconductor memory information about the attribute and information about the layout, moreover, the information about the attribute for each sound object indicates which type of the following types : type (a)type (b), type (type) and (g) he belongs, and the type (a) represents the entire audio playback, type (b) represents the first part of the audio soundtracks, type (V) is the average of the sound tracks, and the type (g) represents the final part of the audio soundtracks, and information about the layout for each sound object that belongs to a type (b) or type (b)specifies how the sound object should then sound object.

15. Read through a computer storage medium storing a program that when executed through the computer writes information through a computer in charge of semiconductor memory, and the program contains the following operations: the first operation of generating, at which carry out the sequential generation of audio frames from the input signal, the reception of which is produced outside the recording device, and the audio frame represents the least amount of data for which can be performed independent decoding; a write operation, when the circuit Board of the semiconductor memory create a file and write to file audio frames created in the process of placentas is positive generation; the second operation of generation, in which whenever the recorder made an entry in the file, a predetermined number of audio frames that are generated pieces of information about the input data, which indicates the data length of the audio element, consisting of recorded sound file frames, in which every time when the second operation of generation produced by the generation of a predetermined number of pieces of information about the input data, when performing a write operation creates a new file and write to a new file, the audio frames, sequential generation which is done after that.

16. How to play to implement the playback data from the Board of a semiconductor memory containing (1) a protected area, access to which can be carried out by a device that is physically connected to - semiconductor memory and having a means of reading the data stored in it, only if you have installed the authenticity of this device, and in the protected area stores a sequence of encryption keys, consisting of a set of encryption keys arranged in a predetermined order; and (2) unprotected area, access to which may be implemented by any device that is physically connected the go-semiconductor memory and having a means of reading the data stored in it, moreover, in an unsecured area stores at least one audio recording, and control information, and at least one audio soundtrack contains a lot of encrypted audio objects, and the control information indicates which encryption key from a set of encryption keys corresponds to each audio object stored in an unsecured area, and the above-mentioned method of play includes the following operations: a read operation in which carry out the reading of the Board of the semiconductor memory of one of the many sound objects contained in the at least one sound recording and reading of a sequence of encryption keys stored in a secure area Board semiconductor memory, the encryption key that corresponds to the read audio object, the operation of the decryption, which are deciphering a few of the sound object using the read encryption key, and the playback operation, at which reproduction of the decoded audio object, and after decryption operation is completed deciphering a few of the sound object, perform a read operation in which the reading of another sound object in C is okoboi the track, from the sequence of encryption keys read out the encryption key corresponding to another sound object, and transfer again read the encryption key in the decryption operation.

17. The way you write, to record in cost of the semiconductor memory sound works, consisting of multiple items of informational content, and the above-mentioned recording method includes the following operations: operation of encryption in which each element of the information content contained in the musical piece, assign at least one of the multiple encryption keys, and each item of content encrypted using the assigned element content encryption keys, resulting in creating a lot of sound objects, and the write operation, which cost semiconductor memory write multiple encryption keys in a sequence of encryption keys and a multitude of audio objects in the at least one audio recording.

18. The recording method according to 17, in which, after recording a variety of encryption keys and a multitude of audio objects when write operations also are recorded in cost of the semiconductor memory management information, and management information the Oia indicates for each audio object, the correspondence between the area on the Board, semiconductor memory, which stores the sound object, and the memory location of the encryption key corresponding to the sound object.

19. The way you write on p, in which for each sound object when performing write operations also are recorded in cost of the semiconductor memory information about the attribute and the layout information, and information about the attribute for each sound object indicates which type of the following types : type (a)type (b), type (type) and (g) he belongs, and the type (a) represents the entire audio playback, type (b) represents the first part of the audio soundtracks, type (V) is a middle portion of the audio tracks, and the type (g) represents the final part of the audio soundtracks, and information about the layout for each sound object that belongs to the type (b) or type (b), indicates the sound object should then sound object.

20. The recording method for writing in the cost of semiconductor memory that contains the following operations: the first operation of generating, at which carry out the sequential generation of audio frames from the input signal, the reception of which is produced outside the recording device, and the audio frame represents the least amount of data for which can be made independent, the second decoding; a write operation, when the circuit Board of the semiconductor memory create a file and write to file audio frames created during subsequent generation; the second generation operation, in which whenever the recorder made an entry in the file, a predetermined number of audio frames that are generated pieces of information about the input data, which indicates the data length of the audio element, consisting of recorded sound file frames, in which every time when the second operation of generation produced by the generation of a predetermined number of pieces of information about the input data, when performing a write operation creates a new file and write to a new file, the audio frames, sequential generation which is done after that.



 

Same patents:

FIELD: data carriers.

SUBSTANCE: device for reproduction of data from data carrier, program zone of which is used for recording a set of files, and control zone - for controlling copy protection data concerning the file, recorded in program zone, has computer for calculating copy protection information for each time file is reproduced, comparison means for comparing value, calculated on reproduction command, being prior to current one, to value, calculated on current reproduction command, and if these values coincide, the last value is stored as copy protection value, calculated on reproduction command , prior to current one and control means for allowing reproduction of file, appropriate for current command, if value, calculated as response to command, previous relatively to current command, coincides as a result of comparison to value, calculated as a response to current command.

EFFECT: higher reliability, higher efficiency.

4 cl, 46 dwg

FIELD: data carriers.

SUBSTANCE: device for reproduction of data from data carrier, program zone of which is used for recording a set of files, and control zone - for controlling copy protection data concerning the file, recorded in program zone, has computer for calculating copy protection information for each time file is reproduced, comparison means for comparing value, calculated on reproduction command, being prior to current one, to value, calculated on current reproduction command, and if these values coincide, the last value is stored as copy protection value, calculated on reproduction command , prior to current one and control means for allowing reproduction of file, appropriate for current command, if value, calculated as response to command, previous relatively to current command, coincides as a result of comparison to value, calculated as a response to current command.

EFFECT: higher reliability, higher efficiency.

4 cl, 46 dwg

FIELD: computer science.

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

EFFECT: broader functional capabilities.

4 cl, 5 dwg

FIELD: digital memory technologies.

SUBSTANCE: board has rewritable power-independent memory and control circuit, means for storing address, pointing at limit between authentication area and non-authentication area, circuit for changing size of said areas. Reading device contains estimation means, reading information, pointing at number of times, for which digital data can be read, and playback means. Second device variant additionally has means for digital output of contents.

EFFECT: higher efficiency.

3 cl, 23 dwg

The invention relates to a method of recording, the control method and device for recording

The invention relates to a recording medium for recording audio and video data to the device for editing the specified data to the device for recording these data

The invention relates to programmable memory elements, to a method and device for reading, writing, and programming

The invention relates to the field of computer engineering and can be used for recording and reproducing an analog signal using a non-volatile memory

The invention relates to a circuit device with a number of electronic circuit components, which can be translated to its original state

The invention relates to the field of electronics and electrical engineering, and is intended for accumulation of analog information

The invention relates to the accumulation of information

The invention relates to the accumulation of information
The invention relates to the accumulation of information

The invention relates to the accumulation of information

The invention relates to computer technology and can be used in storage devices, especially in portable devices that require a compact, high density and a large amount of information

The invention relates to electronic computing techniques and is intended for use in probe storage device of large capacity

The invention relates to the field of instrumentation and can be used in the equipment for reception and transmission, reception and processing of information

The invention relates to a light modulation ruletagratisonline methods, and more specifically to the field of deformable gel layers for use in teleportations recording devices, display and optical information processing

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

Up!