Semiconductor memory board, reproduction device, recording device, reproduction method, recording method and computer-readable data carrier

FIELD: electric engineering.

SUBSTANCE: semiconductor memory board has protected area, unprotected area, while board stores sound sequence, multiple objects in form of fixed images, at least one fragment of information about reproduction route, and at least one fragment of information about first and second pointers. Reproduction device has reproduction means, visual display means, control means. Recording device has assignment means and recording means. Methods describe operation of said devices. Data carrier has recorded software, providing reproduction procedure for said board.

EFFECT: broader functional capabilities.

7 cl, 148 dwg

 

The technical FIELD TO WHICH the INVENTION RELATES.

The present invention relates to a circuit Board of a semiconductor memory in which memorization of audio data, data of a still image and control data, and the playback device, recording device, method of reproduction, the recording method and for related to this motherboard semiconductor memory to the recording medium, capable as it is being read by a computer. In particular, the present invention relates to an improved storing audio data, data about the image and control data that are distributed in the form of informational content distribution service information such as service music distribution electronically.

The LEVEL of TECHNOLOGY

Distributing music electronically provides users with the ability to buy and get music information (e.g., songs and albums through the Internet. This technology has the potential to dramatically change the market for music recordings and gradually becoming available as the implementation of the necessary infrastructure. One way to save the music information from the music distribution service electronically, it is memorizing cards in this semiconductor memory, is that because of their portability are the perfect tool for this. Therefore, assume that the demand for such payment will be greatly enhanced.

The music information may contain not only the audio data. One example is the "multimedia" audio information, which may contain related images intended for display when playing music. This multimedia audio information can be used to "karaoke programs, which consist of accompanying audio soundtracks and images that are used to display lyrics and background. I believe that the proliferation of such multimedia audio content will also be implemented by means of music distribution electronically, so you need to consider how you should memorize this information content in the semiconductor memory.

The following is a description of how the exercise memorizing multimedia music information recording media, such as CD (compact disk), that is, the conventional way of storing audio data and data about the images in the recording media.

In order for the playback device can play music and visualization of images, using a standard multimedia music is a high content on the recording medium is carried out in the form of multiplexed data, created by multiplexing audio data of the music data images that serve to display lyrics and/or background images. When playing multiplexed data display data about the images can be carried out simultaneously with the playback of audio data.

One example of media that enables the display of data about the image during playback of the sound data by multiplexing these data among themselves, is a CD ROM with graphic data (CD Graphics disc). When creating a CD ROM with graphic data multiplexing data carried out element by element, each of which consists of a 16-bit key codes and subcodes. Audio data is set by a 16-bit key codes, and the data about the images that contain the lyrics, background images, etc., set by the subcodes. When you start playing any music content recorded on CD ROM with graphic data (CD Graphics disc), carry out sequential playback of audio data, which have been assigned a 16-bit key codes, when executed simultaneously, the sequential display image data, which is assigned to the subcodes.

In this multiplexing audio Yes the data and data about the images between them arises the need to create separate images for each music from a music album. This means that when such a conventional method of multiplexing the manufacturer of the disk had to face difficulties due to the need to create at least one image for each component of the musical content.

I think that fans of the records of well-known artists will positively assess the presence of different images for each song (integral part of the musical content in the album. Since it is expected that these artists will be able to sell a large number of copies of their albums, the cost of creating such additional material will be covered by sales.

However, less popular artists cannot count on a large amount of sales of the products, even if each song will be created different images, so the cost of creating such material will not be covered by sales.

Thus taken to create the images, money and effort will give various commercial results, which strongly depends on the popularity of the artist. However, in the normal disks of each component of the music content must be mapped to at least one image regardless of the popularity of recordable artist or expected sales. As a result,manufacturers have expressed dissatisfaction with conventional carriers.

The INVENTION

The aim of the present invention is to provide a circuit Board of a semiconductor memory by which you can reduce the amount of effort required when creating images for a variety of component parts of the audio content, forming an album.

In the case of displaying the image on the screen while playing audio content, display images, which represent the words of the song should be performed only within the corresponding song. However, the same background image can be used to play any number of songs. As an example we can consider the case in which the songwriter or performer is one and the same person, then as a background image for a few songs can be used the same image of the songwriter or artist. Suppose that for manufacturers this will facilitate joint preservation of musical information (sound objects) and data about the images (objects representing image).

In a preferred embodiment, the joint use of data about images (objects representing a still image) many sound objects can be achieved by payment of a semiconductor memory, which saved: sound sequence, contains many sound objects; the set of objects representing a still image; at least one piece of information about the route playback, indicating the order in which to make the reproduction of sound objects from a multitude of audio objects in the audio sequence; at least one piece of information about the first pointer, each of which corresponds to a piece of information about the route playback and through which specify at least one object representing a still image which should be displayed on the screen during the playback of sound objects in the order specified by the respective pieces of information about the route playback; and at least one piece of information about the second pointer, each of which corresponds to the audio object in the audio sequence and by means of which it is set, at least one object representing a still image which should be displayed on the screen during playback, only the corresponding audio object.

Playback of many audio features from the audio sequence is carried out in accordance with the order of play, which is set in the fragment information about mA is the route playback. Through information about the first pointer that matches the information about the route playback, indicate those objects representing a still image that should be displayed as a background image during the playback of sound objects. As a result, the display of the shared objects representing a still image can be performed within time playback of multiple audio objects in the audio sequence.

Because the same image can be used for a variety of phonograms, when playing many audio features from an audio sequence that matches the album is secondary to the popularity of the artist, can be done display the same image or images. This reduces the amount of work to create images for this album and its value.

Conversely, when playing each sound object from the sound sequence that matches the album selling artist, may be provided for displaying various images. Display several different images for each phonogram makes the album more attractive to consumers that followed the Sabbath.) can lead to increased sales.

If there are objects representing a still image, such as lyrics, a conclusion which should be carried out separately from the background image only when playing a specific sound, such objects representing a still image can be set using the information about the second pointer, whereby the objects representing a still image, assign only specific tracks.

In Board of the semiconductor memory can be optionally implemented memorizing many counters characters, each of which corresponds to the object that represents a still image, and indicates whether this object represents a still image, by any of the at least one piece of information about the first pointer and at least one piece of information about the second pointer, and if so, how many pieces of information about the first pointer information and the second index set object representing a still image.

If you removed a sound objects and sound sequences recorder Board for a semiconductor memory specifies information about the second pointer in Alannah sound objects and sound sequences and information about the first pointer for any remote audio sequence. Then, the recording device performs a negative increment numbers assigned to the objects representing a still image, which indicate how many pieces of information about the first pointer information and the second index indicates each object. In the case where the number assigned to any object representing a still image reaches zero, the recorder assumes that an object representing a still image is not specified in any of the pieces of information about the first pointer or the second pointer, and therefore removes an object representing a still image. By removing unused objects representing a still image can be made more efficient use of capacity memory card is a semiconductor memory.

BRIEF DESCRIPTION of DRAWINGS

These and other objectives, advantages and features of the invention will become apparent from the following description 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 circuit Board design 31 flash memory;

Figure 3 - hierarchical structure of the circuit Board 31 of the flash memory versions of the westline;

Figa a special area, the region 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 in which the file of the sound object (AOW) "AOB001.SA1" is divided into five parts, which remember in clusters, 003, 004, 005, E and 00C;

Fig.7 is an example of the job elements of the 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, and the types of files stored in the 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 - structure of the data 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 the audio in the MPEG 3rd level (MPEG Layer 3) (MP3) presented in the form of a table;

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

Fig - detailed structure QUADRAT (frame sound object) (AOB_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 ELEMENTAT (AOB_ELEMENT);

Fig examples of playing time LAMENTOSO (AOB_ELEMENTS) 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 the variants of implementation;

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

Fig - conformity between the information data phonograms (IDF) (TKIs), shown in Fig, and GOITER (AOBs) and files GOITER (AOW files), which are shown in Fig;

Fig - detailed data structure TMVGPBR (table search is 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 Figv shows the area Prodolzhitelnost (Time_Length);

Fig clusters with 007 on E, 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 (_ELEMENT#y) GOITER (AOW);

Figa and PIGB - determination of GOITER (AOW), ELEMENTAL (AOB_ELEMENT), and KATZO (AOB_FRAME), which correspond to the arbitrary value of the time code playback;

Figa and PIGB - erase operation of the phonogram;

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

Figb - 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 - setting the value of IDF (TKI) in the case when to create a new phonogram carry out the merger of the two phonograms;

Figa - GOITER (THE S) 1 type (Type1);

Figb - GOITER (AOW) 2nd type (Ture);

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

Figb - Union of the set of phonograms in one soundtrack for the total GOITER (AOW) 1st + 2nd + 2nd + 2nd + 1-th type (Type1 + Ture + Ture + Ture + 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 at the end of the first soundtracks are 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 at the end of the first soundtracks are GOITER (AOW) 1 type and 2-type, and in the beginning of the following soundtracks are GOITER (AOW) 2-type 1-type;

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

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

Figa and Figb content items in the catalog of the original audio data (SD_Audio) in the same directory as the source is Vukovich data (SD_Audio), contains the file GOITER (AOW file) "003.SA1 before and after 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 (AOB_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 Informatiespecialist (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 Fig 43B - implementation of change order the ka repetition of phonograms;

Figa and PIGB - update 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 of the embodiments of the present invention;

Fig is one example of the image display on the LCD panel when you select the playlist;

Figa - Figd are examples of images that display on the LCD panel when selecting a phonogram;

Figa - Figv 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 - sh the mA sequence, showing a procedure of reading the 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);

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

Figa - Figg - 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 showing processing performed by a 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 is one of the approximate variants of a recording device for recording data in the card 31 flash memory;

Fig - hardware capture devices;

Fig - precedence diagram showing processing when recording;

Fig internal structure of the flash memory card according to the second variant of implementation of the present invention;

Figa and PIGB - the internal structure of the user data area and the protected area on the file system level;

Figa - internal file structure ".JPG";

Figb - internal file structure of the OBI (the object representing the image) (PIT file), which contains the encrypted data of a still image;

Figw - example file OBI (PIT file), in which instead of the encrypted volume data memorized the path to the file;

Fig - detailed structure of the administrator of the playlist (PlaylistManager) and administrator of phonograms (TrackManager) of the second variant of implementation;

Fig - implementation of job files OBI (ROS), shown in Fig through OPIOID (pointers search of objects representing the image information data track) (TKI_POB_SRPs), OPIOIF (pointers search of objects representing the image information list reproduced ilow) (PLI_POB_SRPs), and OPHIOLITE (pointers search of objects representing the image information of the playlist by default) (DPLI_POB_SRPs);

Fig - data structure TRIOBET (object attribute representing the image information data track) (TKI_POB_ATR) and OPIOID (TRU SRP);

Fig - example settings OPIOID (TKI_POB_TKIs) for IDF # 1 to # 3 (TKI#1-TKI#3) the administrator of phonograms (TrackManager);

Fig - example settings OPIOID (TKI_POB_TKIs) for IDF from No. 4 to No. 8 (TKI#4-TKI#8) the administrator of phonograms (TrackManager);

Fig - OPHIOLITE (DPLI_POB_SRPs) and ATTRIBITE (attributes of objects representing the image information of the playlist by default) (DPLI_POB_ATR)contained in AISURU (DPLGI);

Fig is an example of the parameter setting twenty OPHIOLITE (DPLI_POB_SRPs)contained in Informatsiejobrashchatsja (Default_Playlist_Information);

Fig is a timing chart showing the method of forming the combined image in the case when the background image using the OBI (ROS), indicated by OPHIOLITE (DPLI_POB_SRP)contained in Informatsiejobrashchatsja (Default_Playlist_Information), and the image on the foreground, use the OBI (the MOAT), specified group is a rotary OPIOID (TKI_POB_SRP), contained in the administrator of phonograms (TrackManager);

Fig - implementation combining the background image and the image on the foreground, to a point located six minutes after the start of playback according Informatsiejobrashchatsja (Default_Playlist_Information);

Fig - implementation combining the background image and the image on the foreground, in the point across sixteen minutes after the start of playback according Informatsiejobrashchatsja (Default_Playlist_Information);

Fig - OPIOIF (PLI_POB_SRPs) and TRIOBET (attributes of objects representing the image information of the playlist) (PLI__PLI), which are contained in OSWF (General information about the playlist) (PLGI);

Fig is an example of the parameter setting twenty OPIOIF (PLI_POB_SRPs)contained in ISWF (PLI);

Fig is a timing chart showing the method of forming the combined image in the case when the background image using the OBI (ROS), indicated by OPIOIF (PLI_POB_SRP)contained in ISWF (PLI), and the image on the foreground, use the OBI (ROS), indicated by OPIOID (TKI_POB_SRP)contained in the administrator Phono the PAMM TrackManager);

Fig - implementation combining the background image and the image on the foreground, to a point located six minutes after the start of playback according to ISWF (PLI);

Fig - implementation combining the background image and the image on the foreground, in the point across sixteen minutes after the start of playback according to ISWF (PLI);

Fig - example, in which the reduction of the number of files OBI (ROS files) in the presence of Informatsiejobrashchatsja (Default_Playlist_Information) several OPHIOLITE (DPLI_POB_SRPs), through which indicated the same files OBI (ROS files);

Fig is a timing chart showing the method of forming the combined image in the case when the background image using the OBI (ROS), indicated by OPHIOLITE (DPLI_POB_SRP)contained in Informatsiejobrashchatsja (Default_Playlist_Information), and the image on the foreground, use the OBI (ROS), indicated by OPIOID (TKI_POB_SRP)contained in the administrator of phonograms (TrackManager);

Fig - internal structure ADIB (administrator OBI) (POBMG);

Fig - use playback device from the second variant implementation;

Fig - EXT is šnē view the playback device from the second variant of implementation;

Fig - the internal structure of the playback device from the second variant implementation;

Figa - implementation of imposing one to another still image stored in multiple RAM 61 for video (VRAMs);

Figb - implementation of imposing one to another still image stored in multiple RAM 61 for video (VRAMs);

Fig - precedence diagram showing a procedure of displaying an image on the foreground;

Fig - precedence diagram showing a procedure of displaying a background image;

Fig - precedence diagram showing a procedure of displaying a background image;

Figa - FIGU - total image to be displayed on the screen of the LCD panel 5 when the processing according to the flow chart of the operations Fig and Fig, where as the image on the foreground screen display OBI (ROS), indicated by OPIOID (TKI_POB_SRP), and as a background image on the screen display of the OBI (ROS), indicated by OPHIOLITE (DPLI_POB_SRP);

Figa - FIGU - total image to be displayed on the screen of the LCD panel 5 when the processing according to the flow chart of the operations of Fig and Phi is .96, where as the image on the foreground screen display OBI (ROS), indicated by OPIOID (TKI_POB_SRP), and as a background image on the screen display of the OBI (ROS), indicated by OPIOIF (PLI_POB_SRP);

Fig - precedence diagram showing the procedure used in the recording device of the second variant of implementation;

Figa - example of a table of the distribution of phrases in time; and

Figb - example of a table allocated to the screen coordinates.

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 accompanying drawings, is attached to this description, numbered in the order in which they are mentioned in the description, so the order of the drawings corresponds roughly to the order of presentation. About is the explanation for some of the drawings are divided into paragraphs, moreover, the number x2 of the links indicates 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 VARIANT embodiment of the INVENTION

{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, thus, 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 structure of the card 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 the structures on the digital video disc (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

Three shows on Figa area create in memory, consisting of these existing sectors. These areas are "special region", "region identification" and "the user", as described in more detail below. The user differs in that the device with which are connected the card 31 flash memory is, may 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 intended 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 completed the mutual identification card 31 flash memory and the device connected to the card 31 flash memory.

{3-A-2} Use the three regions in physically the m 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 using 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.

Because the data for which you want to protect the copyright, is subjected to the process Duhs openstage encryption when data encryption is carried out using the 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 structure 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. Although 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 "the partition boot sector, file allocation table (TRF)" (FAT), the "root directory" and "data area"and this means that the region identification and the user have the same structure. Figure 5 depicts the different parts of these files is x 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". Since 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), then 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 (kilobytes), 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 16 KB, so the lowest possible volume stir the protected data equal to the size of the cluster means, the data recording 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 inside the field data indicate through 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..., which contains the file allocation table. Numbers 002, 003, 004, 005 ...assigned to each value of TRF (FAT), indicate which cluster corresponds to each value of TRF (FAT), and, therefore, represent the number of clusters for clusters, the relevant knowledge is eniam 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 audio 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 that specifies where stored 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 by showing you how do 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, which is 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 sound 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 I 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, although the values 004 (005) and 005 (A) TRF (FAT) correspond to clusters 004 and 005, which saved the following part of the file 001.SA1", these values are, respectively, indicate that the cluster 005 and cluster A are clusters in which memorized the following part of the file 001.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 "001.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 00C 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 completes the description of the file system in the card 31 flash memory of the present invention. the alley describes the application level, which exists in the file system.

{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) (Playlist Manager (PLMG), and administrator of phonograms" (ADFG) (Track Manager (TKMG).

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

On Figa and Figb 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") and "3D AUDIO.TKM" ("Ichthyosauridae", where the extension ".TKM" means "adminis the combined phonograms") Figa indicate all files in which carry out remembering the administrator of the playlist (ADSVR) (PlaylistManager) (PLMG) and administrator of phonograms (ADFG) (TrackManager) (TKMG), which form a navigation information. Here the file name "001.SA1", "AOB002.SA1", "AOB003.SA1", "004.SA1", ... denote those files (the files "GOITER" ("AOW" files)), which made remembering the sound of objects representing reproducible data. The characters "SA" 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 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 that remembers under the symbol "original sound data (SD Audio)" (i.e. inside the "directory shodnenskaya data (SD Audio)"). In this file AOBSA1.KEY" storage encryption key to memorize 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 communications 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, managed by the record company who, 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)that are in scope Yes the data with a pre-defined extension ".key" ("key"). When the file GOITER (AOW file has the file name "001.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 access to 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 "Record access to 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 itimate specified as Record No. 1 on the access to the key file" ("FileKey Entry#1"), file "AOB002.SA1" corresponds to the key file (FileKey), the location of which in the memory is listed as "Entry # 2-access to the 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 access to 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 access to the keys file ("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 (File-Key)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 in which the PR level shown himself sound 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 (_FRAME)code according to standard MPEG2-AAC, encrypt and transmit to the consumer over the network General polzovaniaya GOITER (AOW file) is generated by the separation of transmitted transport stream audio data in sequence KUDROVO (AOB_FRAMEs) and memorizing these KUDROVO (_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".

Legend kolichestvennihyj" ("number_of_data_block_in_frame") in the column "Parameter" indicates that a use ratio: one title for one blokada (raw_data_bock).

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 carry out the encryption of each part QUADRAT (AOB_FRAME). From the drawing it is seen that the ADTS header corresponds to the unencrypted part. Sound Yes the data contain both encrypted part, and the unencrypted part. 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 KUDROVO (_FRAMEs) implement the installation length of audio data in bytes. On Fig audio data No. 1 (audio data#1)contained in CADRES NO. 1 (AOB_FRAME#1)have a data length equal to x1, audio data No. 2 (audio data#2)contained in CADRES NO. 2 (AOB_FRAME#2)has a data length equal to x2, and the audio data No. 3 (audio dta#3), contained in CADRES NO. 3 (_FRAME#3)has a data length equal to X3. In the case when all the data have different lengths x1, x2 and X3 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 (AOB_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_FRAME) 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 KUDROVO (AOB_FRAMEs) was approximately equal to two seconds, and this number depends on the frequency of disks is the dimension 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 KUDROVO (AOB_FRAMEs)contained in ELEMENTAT (_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 the sampling frequency (sampling_frequency) is equal to 32 kHz, the number KUDROVO (AOB_FRAMEs) set equal to 64 (=32*2), when the sampling frequency (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, when you have performed an editing operation, such as division GOITER (AOW), the number KUDROVO (AOB_FRAMEs)contained in ELEMENTAT (AOB_ELEMENT) n is the beginning or at the end of GOITER (AOW), may be less than the amount which is obtained by similar calculations.

Until each ELEMENTAT (AOB_ELEMENT) does not have a header or not provided other specific information, instead, the data length of each ELEMENTAT (AOB_ELEMENT) are listed in table time search.

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

On Fig shows one example of the playback duration of LAMENTOSO (AOB_ELEMENTS) and KUDROVO (_FRAMEs). On Fig on the first level shows many BLACKOUT (AOB_BLOCKs), and the second level shows many LAMENTOSO (AOB_ELEMENTs). 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 reverse direction, in which, for example, carry out intermittent playback of short segments through mnogokrat the th audio 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 (AOB_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 milliseconds, performs skip reading 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), the ven though it's meant to be, for 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 (AOB_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 for audio 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 from 16 KBI is/s (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 × 2/8) to 36 Kbps (=144 Kbps × 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 setting 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 (sound volume is tov) (AOBs).

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

Lots of false data represent the areas that are read and written together with BLOOMIT (AV BLOCKs) and stored in the same cluster, and that BLOCKIT (AOB_BLOCKs). The initial and final position Blockout (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 (_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 (_BLOCKs)contained in these GOITER (AOW).

On the fifth level shows the headlines of the five parts of the content of education the data in 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 (AOB_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 (AOB_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" AOB003.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 And" (SongA), "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 GOITER 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 (AOB_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 above limit playback of the audio objects (GOITER) (AOW) limits the amount of data table search time associated with each CROP (AOW). Below is a description of the navigation data contained in each of tabletservice time.

{3-A, B-2}

Navigation data consist of two previously mentioned files "SD_Audio.PLM" and "SD_Audio.". 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, such as 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 data, such as 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 "voiced books" (that is 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 playlist (PlaylistManager) and administrator of phonograms (TrackManager) in this embodiment. On Fig shows the volume administrator with the claim playback (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 - 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 (TKMSRT) consists of SEGALOWITZ (TMSRT_HEADER) and Elementor No. 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), "the Soundtrack of" G " (TrackD), and the Soundtrack D" (TrackE). The second level shows eight IDF (TKI). Rooms"1", "2", "3", "4", assigned to each IDF (TKI), represent the sequence numbers are 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 (TKI#1) correspond to the file "001.SA1"that the IDF No. 2 (TC#2) correspond to the file "002.SA1", IDF No. 3 (TKI#3) correspond to the file "AV. SA1"and IDF No. 4 (TKI#4) correspond to the file "AOB00.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 Kolichestvoparkov (Total TMSRT_entry_Number).

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

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

Below are under the one 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 LAMENTOSO№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 (AOB_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 of Kudrovo (AOB_FRAME).

Since the size of the area occupied by each Elementat (AOB_ELEMENT) according to the Chen, before you skip to the beginning of Elementat (AOB_ELEMENT) need to inform the playback device about the location of each Elementat (_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 (AOB_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 №p (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 Elementp No. 3 (TMSRT_entry#3) record size "32800" (=97000-64200). Similarly, the 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} How do reading TMVGPBR (TKTMSRT)

Thus, in the table, time search is carried out record amounts of data Lamentoso (AOB_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 (_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 play this GOITER (AOW). When playing GOITER (AOW) ends, carry out the reading of the next CROP (AOW), and when the play is the development of this CROP (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 (_ELEMENT) using TMVGPBR (TKTMSRT). TMVGPBR (TKTMSRT) contains the volume of each Elementat (AOB_ELEMENT), so if you want to read Elementat No. (AOB_ELEMENT#y), representing the initial ELEMENTAL (AOB_ELEMENT) from the beginning GOITER (AOW), then calculate the cluster and satisfied moreuse the following Equation 1, and carry out the reading of 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 Size cluster

(Cluster u = (Total of the TMSRT_entries from AOB_ELEMENT#1 to AOB_ELEMENT#y-1 + DATA_Offset) / Cluster size

Offset v = (Total of the TMSRT_entries from AOB_ELEMENT#1 to AOB ELEMENT#y-1 + DATA Offset) 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 on the soundtrack) (TKGI)

The lower is the description OFG (TKGI), which is recordable 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_AOB_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 the location of each IDF (TKI) in Administrat the re 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 (TC#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 GOITER (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 (TKI#5), WKSSVC (TKI_LNK_PTR) IDF No. 5 (TKI#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 (TKI#4) IDF No. 7 (TKI#7) and these four files GOITER (AOW files) with "AOB004.SA1" AOB007.SA1" form one of the phonogram, the Phonogram 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) have shown is representative of 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 "Nachname" ("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), which correspond GOITER (AOW) at the end of the phonogram, write the value "011b" (this set is hereinafter referred to as "Concompany" ("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 ("AOV. SA1"), IDF No. 2 ("AOB002.SA1"), IDF No. 3 ("003.SA1") and IDF No. 8 ("AOB008.SA1") [TKI#1 ("AOB001.SA1"), TC#2 ("AOB002.SA1"), TC#3 ("003.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#1, TKI#2, TKI#3, TKI#8) is set as "Soundtrack".

TREBLED (TKI_BLK_ATR) IDF No. 4 (TKI#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 (TKI#4), is the beginning of a phonogram, the files GOITER (AOW files) ("AOB005. SA1") and ("AOV. SA1")corresponding IDF # 5 and IDF No. 6 (TKI#5, TKI#6)is the average parts of the soundtrack, and the file GOITER (AOW file) ("AOB007.SA1")corresponding to the IDF No. 7 (TKI#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#1) and "AOB001.SA1" forms the first soundtrack (the Soundtrack A) (TrackA). Similarly, the IDF set No. 2 (TKI#2) and "AOB002.SA1" forms the second soundtrack (Soundtrack B) (TrackB), and the totality of the IDF No. 3 (TI#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 (TKI#5) "AOB005. SA1" and IDF No. 6 (TKI#6) "AOB006.SA1 form the middle part of the Phonogram G (TrackD), and the totality 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 "008.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_AOB_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_ATR), the azan structure ATRTED (TKI_AOB_ATR) in bits.

On Fig ATRTED (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) (MP3), then it writes the value "0001b". When the encoding GOITER (AOW) implemented in the format of a sound environment for the Windows operating system (Windows Media Audio (WMA), 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 (MPEG1-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) (FRN), this field is write the value from "16" to "80", and when the encoding GOITER (AOW) implemented in the format of a sound environment for the Windows operating system (Windows Media Audio (WMA), this field records the value of "8" is about the "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, then this value is "0001b", 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 to bits b31 b20, as well as 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 the Code of the recorded item (Recordingitem code (No. 12) write in the box the C four bits between bit bit b4 and b7. Entryid/Code item being recorded (Recording code/Recordingitem 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 b12 and a bit 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 ISO3901:1986 Technical documentation International standard registration code (ISCO)" ("Documentation-International Standard Recording Code (ISRC)").

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

"Table of information about blocks" (TIB) (BIT) is a table for managing Blockout (_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 ("volume 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 ("number of frames secondary elements TPWR") (FNs_Middle_TMSRTE), which occupies an area of 76-th byte in the 77-th byte, and field PRODOLZHEN ("duration time") (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 area of false data between GOITER (AOW) and Blockout (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 set so that the playback is of the phonogram carried 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 area of false data, after Blocat (_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 OBEDENNYH (SZ_DATA) and Digan (DATA_OFFSET).

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

In the field "KOLHAPUR" (TMSRTE_Ns) record the total number Elementor (TMSRT_Entries)contained in Blakeson (AOB_BLOCK).

{17-5_22-A-5} "Kolker" (FNs_1_st_TMSRTE), "Cooler" (FNs_Last_TMSRTE), "Kolker" (FNs_Middle_TMSRTE)

In the field "Kolker" (FNs_1st_TMSRTE) record the amount Kudrovo (AOB_FRAMEs)contained in the Element GOITER (AOB_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 (_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 (AOB_FRAMEs)contained in each Elementat (AOB_ELEMENT), except for those at the beginning and end of the currently used Blocat (AOB_BLOCK), that is, Vtech Elementat (AOB_ELEMENTs), located in the middle of Blocat (AOB_BLOCK).

In the field "PRODOLZHEN" (TIME_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 "PRODOTTI" (TIME_LENGTH) write the value of "2000".

{17-5_22-B}

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

The relationship between castoroides 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 (_ELEMENT) depends on the sampling frequency. The number of frames recorded in "Kolker" (FNs_1st_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 (_BLOCK) there is a plot of false data, then the values set in "Kolker" (FNs_1st_TMSRTE) 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 (AOB_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 (AOB_ELEMENT#4), remembering which implemented in clusters with cluster 007-th cluster, OOE 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 (AOB_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 sd1, OBEDENNYH (SZ_DATA) TIB (BIT) indicates that ELEMENTIT THE (AOB_ELEMENTS) # 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, there are lots of false data 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 Elementat No. 1 (AOB_ELEMENT#1) or Elementat No. 4 (AOB_ELEMENT#4). Specified in TIB (BIT) Sdvigne (DATA_Offset) specifies the length of the unoccupied area ud0, namely, the value of the location of the beginning of Elementat No. 1 (AOB_ELEMENT#1) relative to the beginning of the cluster 007.

On 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. "CALC-goatpower" (FNs _1t_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 (_ELEMENT#4), which is located in clusters with 00C th E th.

This act shall abom can be made 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 (AOB_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 (_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 carry out the setting of the next playback Quadrat No.(x+1) (_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 (AOW).

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 the same length choppy playback, "Vremya" ("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 (_FRAME#x), despite the fact that from the very Elementat (TMSRT_Entry) the playback device may not know about the number Kudrovo (AOB_FRAMEs), located between the start address Elementat No.(y+1) (AOB_ELEMENT#y+1) and Quadrato No.(x+1) (AOB_FRAME#x+1), the first address of the next Elementat the(y+1) (AOB_ELEMENT#y+1) can be directly calculated by reading Elementat (TMSRT_Entry) from TMVGPBR (TKTMSRT).

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

{17-5_22-A) using the number of frames specified

each Elementat (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 positions is about to be launched with Elementat No. (AOB_ELEMENT#y), and x Quadrat (AOB_FRAME), satisfying the following Equation 2.

Equation 2

Supised (in seconds) = (Kolker + Kolker*y + x) *20 MS

(Jmp_Entry (sec)=(FNs_1st_TMSRTE + FNs_middle_TMSRTE*y + x)*20msec)

Because "Kolker" (FNs_1st_TMSRTE) and "Kolker" (FNs_Middle_TMSRTE) contained in TIB (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 ELEMENTAL (AOB_ELEMENT) GOITER (AOW)) and, based on this first address, start the search Quadrat No. x (AOB_FRAME#x). Upon detection of the x-th Quadrat (_FRAME) the playback device starts playing from that frame. Thus, the playback device can play back data since the time specified in Supised (Jmp_Entry) (in seconds).

Thus, for playback devices there is no need to search parts of the ADTS header in Catracho (_FRAMEs), and just needs to search in Elementat (AOB_ELEMENTS)specified in Elementat (TMSRT_Entries) from TMVGPBR (TKTMSRT). This means that the playback device can high speed to find the playing position corresponding to the specified times of the playback.

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. (_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 CAGR IS ABOUT (AOB_ERAME) from address, where is (y+2)-th ELEMENTAL (AOB_ELEMENT) (i.e 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 GOITER (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 Figb 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 "002.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" who was b deleted and TREBLED (TKI_BLK_ATR) IDF No. 2 (TKI#2) is set to "Unused", shown in Figb. Because "AV. 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 (Track Manager) 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, TKI#7, TKI#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 the implementation is given in the entry of new IDF (TKI) and file GOITER (AOW file) in case when the administrator 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, D#8) from Figb set to "Unused".

On 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) (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, TKI#7, TKI#8).

As one soundtrack consists of these four GOITER (AOW), TREBLED (TKI_BLK_ATR) IDF No. 2 (TKI#2) set the value "Nacharam" ("Head_of_Track"), TREBLED (TKI_BLK_ATR) IDF # 4 IDF No. 7 (TKI#4, TKI#7) set the value "Sredinom" ("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 TL7, in WKSSVC (TKI_LNK_PTR) IDF No. 2 (TKI#2) establish the value of the IDF No. 4 (TKI#4), WKSSVC (TKI_LNK_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 (TKI#7) set the value of the IDF No. 8 (TKI#8).

Then create the file "002.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 (TKI#2, TKI#4, TKI#7, TKI#8), and in these four files provide memorizing four GOITER (AOW), forming a Phonogram G (TrackD).

Through appropriate setting WKSSVC (TKI_LNK_PTRs) and TREBLED (TKI_BLK_ATRs), you can control this fourth phonogram, the Phonogram G (TrackD)using the IDF No. 2, IDF No. 4, IDF # 7 and IDF No. 8 (TKI#2, TKI#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 set 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 is on Fig, and it shows the case when the Association of the Phonogram (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 "008.SA1", which correspond to the IDF No. 3 (TKI#3) and IDF No. 8 (TKI#8), perform the overwrite TREBLED (TKI_BLK_ATRs) in IDF # 3 and IDF No. 8 (TKI#3, TKI#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 (TKI#3) overwrite so that it receives the value "Nacharam" ("Head_of_Track"), and TREBLED (TKI_BLK_ATR) IDF No. 8 (TKI#8) overwrite so that it receives the value "Conectarme" ("End_of_Track"). Through this rewriting TKI_BLK_ATRS, handling files GOITER (AOW files) "AOB003.SA1" and "008.SA1", which correspond to the IDF No. 3 (TKI#3) and IDF No. 8 (TKI#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 (TKI#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) ID, is (TKI), do not perform any processing on the physical merging files GOITER (AOW files) "AOB003.SA1" and "008.SA1". This is because each file GOITER (AOW file) encrypted using different keys file (FileKeys), so when you merge 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) through 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 in overworry at Association of phonograms

As described above, the Association of phonograms is carried out by changing the attributes TREBLED (TKI_BLK_ATR), but GOITER (AOW)contained in the United phonograms, must satisfy 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 ELEMENTAL (AOB_ELEMENT) number Kudrovo (AOB_FRAMEs), is equal to the number of frames, due to "Kolker" (FNs_Middle_TMSRTE). GOITER 1st type (Type1 AOW) contains at least one ELEMENTAL (AOB_ELEMENT), with this number Kudrovo (AOB_FRAMEs), and GOITER 2nd type (More AOW) does not contain ELEMENTAL (AOB_ELEMENT), which has this number Kudrovo (AOW 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 (AOB_FRAMEs), however this cannot be performed if the following one after the other CRAW of the 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 configured VM is the sty.

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 (_ELEMENTs) does not contain the number Kudrovo (AOB_FRAMEs), which is set to "Kolkasrags (FNs_Middle_TMSRTE)". Because no Elementat (AOB_ELEMENT), with the number Kudrovo (_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 + Type2 + Type2 + Type1 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 shown merging into a single soundtrack GOITER 1st + 2nd + 2nd + 2nd + 1-th type (Type1 + Type2 + Type2 + Type2 + Type1 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) in a single phonogr the MMU, as shown 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) or GOITER 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 Figb 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 (More 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 (Typel AOW) or Goiter 2nd type (More AOW).

On FIGU shows the case in which the first soundtrack Zakan the scarfing Goiter 1st type (Type1 AOW) and Goiter 2nd type (More AOW) in that order, and the second 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 soundtrack begins with GOITER 2nd type (More AOW) and the CRAW of the 1st type (Typel 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, shown 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 is 4, in which carry out the separation of the recording.

{17-5_22-A,B} set options for IDF (TKI), in

separation of phonograms

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 on 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 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-A,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) ".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) "003.SA1", what about the separation of the file.

File GOITER (AOW file) "003.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) ".SA1" written as "007". Also as values TRF (FAT) 007, 008, 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) "00.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) "AOB002.SA1". On Figa shown as made the 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".

On Figb in the cluster 00F 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, and the rest of the parts stored in clusters, 00C, 00D, E, then the field 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-A,B-A,B} Set of 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 (AOB 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 (AOB). On Figa on the first level depicts four Elementat (AOB_ELEMENTs), namely cell battery (included) IS TSOB No. 1, ELEMENTAL NO. 2, ELEMENTAL No. 3 and ELEMENTAL NO. 4 (AOB_ELEMENT#1, AOB_ELEMENT#2, AOB_ELEMENT#3, AOB_ELEMENT#4). The length of these Lamentoso (AOB_ELEMENTs) installed in TMVGPBR (TKTMSRT) through four Elementor №1, №2, №3 and №4 (TMSRT_Entries#1, #2, #3, #4). If, as shown in Figa, the boundary separating gr (bd1) is Elementet No. 2 (AOB_ELEMENT#2), the ELEMENT GOITER No. 2 (AOB ELEMENT#2) is divided into the first area (1), consisting of a frame located to the border gr (bd1), and the second area (2), consisting of the frames located after the border gr (bd1). 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 (AOB_ELEMENT#2).

{17-5_22-A,B-3_36} Set parametrov 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 (bd1). GOITER No. 1 (AOB#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 flags on what I 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 (AOW#1), which is obtained by this separation. ELEMENTAL NO. 1 (AOB_ELEMENT#1) and ELEMENTAL NO. 2 (AOB_ELEMENT#2)contained in the CRAW No. 1 (AOW#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 No. 1 (AOW#1) has a data length that they do not end at the end of the cluster A, and on the border gr (bd1), which is located within a cluster A, so OBEDENNYH (SZ_DATA) for GOITER No. 1 (AOW#1) is set as the amount of data from the field md0 to the border gr (bd1) in the cluster A. "Kolker" (FNs_1st_TMSRTE) for GOITER No. 1 (AOW#1) is the same as before the split, and "Cooler" (FNs_Last_TMSRTE) for GOITER No. 1 (AOB#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 (bd1).

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 reason of mors is anemia in the cluster 00F copy cluster A is the cluster A busy Elementat No. 2 (AOB_ELEMENT#2) from GOITER No. 1 (AOB#1), so for Elementat No. 1 (AOB_ELEMENT#1) from GOITER No. 2 (AOW#2) you must select a different cluster.

ELEMENTAL NO. 1 (AOB_ELEMENT#1) from GOITER No. 2 (AOW#2) has a data length at which they start is not at the beginning of the cluster 00F, and on the border gr (bd1), 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 (AOW#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 (_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_1stTMSRTE) GOITER No. 2 (AOW#2) establish 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. 2 (AOB_ELEMENT#2).

{17-5_22-A,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_0ffset) is set to "X", OBEDENNYH (SZ_DATA) is set to "52428"and KOLHAPUR (TMSRTE_Ns) is set to "n". Kolker (FNs_1st_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 the separation of the recording. In the case when the GOITER (AOW), the corresponding TIB (BIT) from the left side Fig share as shown in Figa, Sdvigne (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 e is metopr (TMSRT_entries) from the first Elementat (TMSRT_entry) to k-Elementp (TMSRT_entry). Kolker (FNs_1st_TMSRTE) and Kolkasrags (FNs_Middle_TMSRTE) is set to "80" and "94" frames, the same 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 phonogram created through separation, "Sdvigne" (Data_0ffset) is set to "R", "OBEDENNYH" (SZ_DATA) set equal to a 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-Elementp (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 (AOBJELEMENT) GOITER (AOW) this second soundtrack contains "94-R Kudrovo (AOB_FRAMEs), so Kolker (FNs_1st_TMSRTE) the TIB (BIT), which corresponds to the soundtrack, set the value of ' 94-R".

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

On is shown TMVGPBR (TKTMSRT) after separation. Below in the first place, there is an explanation of the set values TPVR (TMSRT). TPVR (TMSRT) first soundtrack contains Elementimpl (TMSRT_entries) from the first Elementat (TMSRT_entry) GOITER (AOW) before separation on a k-th Elementp (TMSRT_entry), i.e. Elementimpl # 1 to # k (TMSRT_entries#1...#k).

Here we should pay attention to the fact that ELEMENTAL # k (_ELEMENT#k), which contains the boundary separation, contains only the area (1), so k-th Elementp (TMSRT_entry) contains a volume of only those data that correspond to this region (1). TPVR (TMSRT) the second phonogram contains Elementimpl (TMSRT_entries) from k-Elementp (TMSRT_entry) GOITER (AOW) to split up the n-th Elementat (TMSRT_entry), i.e. Elementimpl with no k no no n (TMSRT_entries#k...#n). Here it should be noted that Elementp # k (AOB_ELEMENT#k), which contains the boundary separation, contains only the area (2), so k-th Elementp (TMSRT_entry) contains a volume of 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 (AOW files) do not exercise, so two of sound records. what Amma can be created by separating the file GOITER (AOW file in its encrypted state. Since the division of the file GOITER (AOW file) does not include decryption and re-encryption, the computational load at the division of the phonogram can be reduced. This means that the editing of 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 (HEADSUP) (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 Ordainedtothenations the Yu (AISURU) (Default_Playlist_General_Information (DPLGI)) and Castellamonte vosproizvedeniya (UPFLUSH) No. 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 circuit Board 52 flash memory, 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 Informatsiya (Playlist_Inforniation), showing only his (her) favorite soundtracks, and save this Informatsiya (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 Informatsiia intracordal (HEADSUP) (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" (attributes soundtracks from the playlist, the default) (DPL_TK_ATR) and "NEFFU" (number of data on the track in the playlist, the default) (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 (DPL_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__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), i.e. 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 the 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 (TKI_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 TREBLED (TKI_BLK_ATR) 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 to the medium is part of a phonogram, that is, when TREBLED (TKI_BLK_ATR) IDF (TKI) is set to "Sredinom" ("Midpoint_of_Track"), "ATRUGGLE" (DPL_TK_ATR) set the value equal to "010b". 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".

In the opposite case, when the 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 when will be the implementation of the Leno playing GOITER (AOW), corresponding to the IDF (TKI), which in turn correspond UPFLUSH (DPL_TK_SRP), that is the ordinal position of GOITER (AOW) in Speckien (Default_Playlist). As a result, the order of the elements UPFLUSH (DPL_TK_SRP) in Speckien (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 Informatsioon (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 on Pig 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 the upper part of each of the first 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 (TKI#1) are connected as the same as UPFLUSH NO. 2 (DPL_TK_SRP#2) with IDF No. 2 (TKI#2), UPFLUSH NO. 3 (DPL_TK_SRP#3) with IDF No. 3 (TKI#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 → TKI#3) ("AOB003.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 "Nacharam" ("Head_of_Track"), ATRUGGLE (DPL_TK_ATR) for UPFLUSH NO. 7 (DPL_TK_SRP#7) is set to "Conectarme" ("End_of_Track"), and in 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 means, what the 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_SRP #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 Speckien (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 IDF No. 1 (TKI#1),; the second will be played "AOB002.SA1"corresponding to the IDF No. 2 (TKI#2); the third will be played "003.SA1"corresponding to the IDF No. 3 (TKI#3); and the fourth will be reproduced "004.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 Informatsiya (Playlist_Information) using the same notations, as Fig. On Fig rectangle on the ground level indicated Spookie (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), and 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 Informacijos files (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__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, #2, #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#2) recorded No. 1 (#1), and as NEFF (PL_TKIN) in UPPGIFT NO. 3 (PL_TK_SRP#3) - No. 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, AOW#1, AOW#2), as shown by the arrows(11), (12), (13).

Spyzooka 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 (AOB#8, AOW#3, AOW#1), as shown by the arrows(21), (22), (23), that is in order, which is completely different from that specified in Spissky No. 1 (Playlist#1).

Spyzooka No. 3 (Playlist#3) consists of UPPGIFT№1, №2, №3, №4 (PL_TK_SRP#1, #2, #3, #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 is the 8 (AOW#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, AOW#7), which form a Phonogram G (TrackD), as shown by the arrow (32). Then perform the play GOITER No. 3 and GOITER No. 1 (AOB#3, AOW#1), which is formed of, respectively, the 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 Informatsii hospicepharmacy (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 Spissky 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) device vos is proizvedeniya. In that case, when the reproduction of phonograms carried out according to the playlist (Playlist), the playback device performs the conversion to UPFLUSH (DPL_TK_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 UPPGIFT (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 administratorship (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, in which the user can create the impression that that Board 31 flash memory memorized several music albums.

It is worth noting here, 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) 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 Speckien (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 reordering UPFLUSH (DPL_TK_SRPs) in Informatsiejobrashchatsja (Default_Playlist_Informtion). On Figa and Figb shows one example of reordering of phonograms. UPFLUSH (DPL_TKS_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. 3 (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 is, s (Default_Playlist_Information).

In the above description discussed the editing operation, which 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 I have are the same, as Fig. Unlike Fig is that on the first level shows the same as on 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) ("002.SA1"), which Figa highlighted by a thick contour. In this example of Informatsiejobrashchatsja (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__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 carry out promotion is UPFLUSH (DPL__SRP s) forward in the playback order, without moving IDF (TKI), so 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 (TKI #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 (TKI4), as shown by the arrow DT12, NIDWU (DPL_TKIN) in UPFLUSH NO. 4 (DPL__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#), 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 is provided to 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 drawings are 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 Informatsiyaonnaya (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 (TKI#2, TKI#4, TKI#5, TKI#7, TKI#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), Informatsiejobrashchatsja (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 (AOW). And the f (TKI) for these four GOITER (AOW) writes, accordingly, 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 "Nacharam" ("Head_of_Track"), values ATRUGGLE (DPL_TK_ATRs) UPFLUSH NO. 4 (DPL_TK_SRP#4) and UPFLUSH NO. 6 (DPL_TK_SRP#5) 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 (TKI#2), NIDWU (DPL_TKIN) UPFLUSH NO. 5 (DPL_TK_SRP#5) establish appropriate IDF No. 4 (TKI#4), NIDWU (DPL_TKIN) UPFLUSH NO. 6 (DPL_TK_SRP#6) corresponding IDF No. 7 (TKI#7), and NEFFU (DPL_TKIN) UPFLUSH NO. 7 (DPL_TK_SRP#7) corresponding IDF No. 8 (TKI#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 track. The Soundtrack G (TrackD).

When the above processing, the recording is carried out in a "Wasted" IDF (TKI), it does not have any impact on the other IDF (TKI), IDF No. 1, IDF No. 2 IDF # 3 and IDF No. 4 (TKI#1, 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 (Example 3). On Figa and Figb shows one example of the Association of phonograms.

These drawings are 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 Informatsiyaonnaya (Default_Playlist_Information), in which UPFLUSH NO. 8 (DPL__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 Informatises vosproizvedeniya (Default_Playlist_Information) 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 Informatsiyaonnaya (Default_Playlist_Information), in which UPFLUSH NO. 8 (DPL__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 (TKI#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__SRP#7) move down in order in one position, and UPFLUSH (DPL__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 NO. 3 (DPL__SRP#3) correspond to the new IDF (TKI), created by separation, namely IDF No. 2 (TKI#2). In file GOITER (AOW file) "AOB002.SA1"corresponding to the IDF No. 2 (TKI#2), preserve what was originally the last part of the file GOITER (AOW file) "003.SA1". UPFLUSH NO. 2 (DPL_TK_SRP#2)corresponding to the IDF No. 2 (TKI#2) and "AOB002.SA1", located in front of UPFLUSH NO. 3 (DPL_TK_SRP#3), which correspond to the IDF No. 2 (TKI#2).

In AOB002.SA1" and "003.SA1" memorize respectively the second and first portions of the original "003.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: "003.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 of the master is a music transmission. 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 border crossing, at which place play CME shall indicate 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 "≫"by which respectively perform 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 music player is LEM for music composed in the following four enhancements (1)th to (4)-E.

(1) On the LCD panel (LCD panel) display a table of the playlist and the list of phonograms, which allows to display to the user Informations vosproizvedeniya (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 contents in the case when p is lovatelli selects tags.

On Fig line by ASCII (American standard code for information interchange) "spookie" ("DEFAULT PLAYLIST"), "spyzooka 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 "≫" at that moment, when as intended for playback in the playback order specified in displayed on the LCD panel the playlist specified by is the, 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 "≫", as shown in Figv, in the list of phonograms as intended for playback will be indicated Soundtrack №3 (Track#3).

If the user presses """ at the moment, when 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 improvements (4). In the drawings, with Figo on FIGU shows an example of the operation of the rotary drive with manual switching. When the user turns the turning parts, all specifications is limited disc 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) operate from the position that ahadiat 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 (operational storage device) 3, a ROM ("persistent storage device) 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 to decrypt Kudrovo (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 Obraniak ADTS Quadrat (AOB_FRAME), the transcript of which is carried out by a decoder 7 random sequences and performing decoding Quadrat (AOB_FRAME to retrieve data PCM (PCM), digital to analog Converter (DAC) 9 for digital to analog conversion PCM data 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 Informatsioonisusteemidesse (Default_Playlist_Information). To implement processing administrator of phonograms (TrackManager) and Informatsiejobrashchatsja (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 In ormation (Default_Playlist_Information), which was read from the card 31 flash memory connected to 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 Informatsiya (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 the parallel execution of the process input in to the m carry out serial data input cluster (data, stored in the same cluster)read from the card 31 flash memory, and inference process, in which the reading frame GOITER (AOW 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, i.e. 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}

When 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, as 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 (AOB_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 your cluster 002 and 003, and the position of the readsequentially indicated by the read pointer. When the read pointer reaches the position readingall 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 that was previously occupied by the cluster 002.

{52-B}

Then the read pointer reaches the position reading andand 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 Figb, 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 Quadrat (AOB_FRAMEs)contained in the file GOITER (AOW file), the decoder 7 random sequences 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 diagrams the sequence of operations used variables w, z, y and X. the Variable w is denoted by one of the many UPFLUSH (DPL_TK_SRPs). The variable z is denoted by F. the file GOITER (AOW file), recorded in the user area, IDF (TKI)corresponding to this file GOITER (AOW file), and GOITER (AOW)contained in this file GOITER (AOW file). 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. (_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).

In operation S2, the CPU 10 waits for instructions on playback GOITER (AOW) according to any Informatsiejobrashchatsja (Default_Playlist_Information), or one of ISWF (PLIs).

In that case, when you specify Informatsiyaonnaya (Default_Playlist_Information), processing is transferred from the operations S2 to operation S3, in which initialize (No.(w-1)) (#w-1) variable w, and then to operation 34, in which the IDF No. z (TKI#z)specified by NEFFU (DPL_TKIN), corresponding UPFLUSH No. w (DPL_TK_3RP#w) in Informacijos osvedomitelley (Default_Playlist_Information), and carry out reading 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).

At operation S5) define file GOITER No. z (AOB file #z), which has the same number as IDF No. z (TKI#z). In this way, finally determine the file GOITER (AOB file)that is used for playback.

The determined file GOITER (AOB 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. z (FileKey_Entry#z) has the same number as the above-defined file GOITER (AOB file). At operation S7, the CPU 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 7 random sequences Kudrovo (_FRAMEs)contained in the file GOITER (AOB file).

{52-9_55-3}

After that the playback device is edenia performs sequential read those clusters, in which you saved the file GOITER (AOB file). At operation S8 in the directory entry indicates the number of the first cluster in the file" for Filtb 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), and in the process 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 bsim number UPFLUSH (DPL_TK_SRPs). If there is no mentioned the coincidence, before to return the processing to operation S4, the process passes to operation S13, at 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) will be stored, 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). Once through this processing will be done reading all IDF (TKI) and files GOITER (AOW files)corresponding to all UPFLUSH (DPL_TK_SRPs)contained in Informatsiejobrashchatsja (Default_Playlist_Information), the value of the variable z (#z) coincides with the total number UPFLUSH (DPL_TK_SRP), so the WMD in 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 (AOB_FRAME)

Simultaneously with the procedure of reading the file GOITER (AOW file), the CPU 10 executes the procedure output Quadrat (_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, i.e. 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 (AOW file#z). This operation S21 is repeatedly performed until, until you made the accumulation of data in the cluster, and at this point in the 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 of Glafira GOITER No. z (AOW file#z) and detection Quadrat No. x (_FRAME#x) in Elementet No. (AOB_ELEMENT#y), that time is not earlier than that Digan (Data_Offset), which is set in TIB No. z (BIT#z)contained in the 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 Katoob No. x (_FRAME#x). Because in this case, the playback time Quadrat (AOB_FRAME) is equal to 20 MS, then the variable "play Time" (Play_time) add 20 MS.

Immediately after the conclusion of the first Quadrat (AOB_FRAME) in the decoder 7 random p is sledovatelnot, 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 (_FRAME). In operation S27, the playback device performs the increment of the variable x (#x←#x+1) and sets KADROV No. x (AOB_FRAME#x) as the next Quadrat (_FRAME). At operation S28 enters Quadrat No. x (AOB_FRAME#x) in the decoder 7 random sequences. After this phase of the 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_1st_TMSRTE).

If the variable x (#x) has not reached the value specified in Kolkat (FNs_1st_TMSRTE), then perform an operation S31, at which 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 that, the device is in playback repeats the processing, performing operations with S26 through S31 up until the value of the variable x (#x) reaches that specified in Kolkat (FNs_1st_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}

On the other hand, if the value of the variable x (#x) has reached Kolker (FNs_1st_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 necessarily have entered all Madryt (AOB_FRAMEs)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 (AB_ELEMENT), and initialization of a variable x (#x) perform the following way: (#←#+1 #x-1).

After that, when the operation S33, 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), i.e. it is similar to a 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_1st_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, complete, in 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): (#y←#y+1 #x←1). If vypolneniyasvoey S44 analyze variable and decide, reached if a variable y (#y) values, per unit smaller than Alseep (TotalTMSRT_entry_Number) in Segalowitz (TMSRT_HEADER) in the IDF No. z (TKI#z).

If the variable u (#) less than (Obscener-1) (TotalTMSRT_entry_Number-1), then ELEMENTAL NO. 1 (AOB_ELEMENT#y) is not the last Elementat (AOB_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) (Total-TMSRT_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, consisting 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 S5 finish then 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) indicates 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). After that, the process passes to operation S22 and repeats the procedure, consisting of operations S22 in S54. This means that defined IDF (TKI)specified by NIDF NEFU (DPL_TKIN) next UPFLUSH (DPL_TK_SRP), and corresponding to these IDF (TKI) file GOITER (AOW file), it is determined that 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 is Finance, the Key file (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

In the drawings, with Figo on Figg 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 playback Quadrat 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 reproduced what I add is the playback duration of Quadrat No. 6 (AOB_FRAME#6), equal to 20 MS, updating it to the value "00:00:00,120"that is shown on Figg.

This complete procedure output Quadrat (AOB_FRAME).

If at operation S31 shown in the sequence diagram operations 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) when performing the search function of time 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

Fig is a diagram of the placenta the successive operations, 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 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 (AOB_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) represents 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 of the variable "Time vosproizvedeniya" (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 corresponding to the duration of the intermittent playback, and volume d(t) data corresponding duration presribes the CSOs play: (x← x+f(t), vremena←vremena+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 Figb 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 increments, with the total number of frames in Elementet No. (AOB_ELEMENT#y) and analyses is not larger than the value of the variable is y x (#x), received after the increment, the total number of frames in Elementet No. (_ELEMENT#).

As mentioned above, the number of frames in Elementat (_ELEMENT)at the beginning of GOITER (AOW), equal Kolker" (FNs_1st_TMSRTE), the number of frames in Elementat (AOB_ELEMENT), located in the middle part of GOITER (AOW), equal Kolker" (FNs_Middle_TMSRTE), and the 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 shall reduce the value of the variable "x" (#x) on the share is in Kudrovo (__FRAMEs) in Elementet No. (AOB_ELEMENT#y), and when performing the operation S66 produce variable is updated (#): (I←+1) (#y←#y+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" (#y). Conversely, in the case where the variable "x" (#x) indicates KATZO (AOB_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), "Vremena" (Play_time) and "Vosproizvedennye" (play_data) in accordance with the duration of the skip choppy playback. The length of time passes (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 vremennaya (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" (pla_data):

(x←x+f(vremennaya), Vremena←Vremena+remap the start, 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 (_ELEMENT#51), then perform the update of the variable "u" (#) so that it points to the next ELEMENT GOITER (AOB_ELEMENT), and from the variable "x" (#x) subtract the number of frames contained in Elementet No. 51 (AOB_ELEMENT#51). In 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 to 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 realized by means of 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 (AOB_ELEMENT#52) in the decoder 7 a casual follower of the spines 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" (#) so that as Elementat 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 about aruite FRAME SAB No. x (AOB_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 this had not taken place, then 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 speed switched the eat, perform the update time code playback. 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" (#y, #x) perform in such a way 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_FRAME#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, ##x) implement so 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_1st_TMSRTE) TIB (BIT) has a value of "80 frames", "Kolker" (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).

Thus, 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), m which can be realized through the playback starting from the eighth Quadrat (AOB_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 on 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" (that is, these keys are used as keys move the cursor Up" and "Down". In that 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 is performed in such a way that in the case of the 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 through S109. In a cyclic process consisting of operations S107 through S109, the playback device receives information entered by the user through Klah is ish "|≪ ", "≫|" 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 that case, to the GDS location 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 "|≪", "≫|" and "Edit" ("Edit").

In the case when the and 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 about is eduru, 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 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 "|≪", "≫|", "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 would be the made about 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 to the tee, RAM 22, a 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 (AOB_FRAMEs) using different 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 audio 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, keypad is the atur 29 for receiving user input and device 30 display on the screen.

{67-2} Input schema on 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 is transferring to the recording device via the communication line of the transport stream of audio data. In this case, contained in the transport stream Madryt (_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 (_FRAMEs) using different keys file (FileKey) for each of Kudrovo (AOB_FRAMEs) in various Pilot (_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 exercise data input 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, in a fixed disk device 23 remember the write program, which contains characteristic for the recording device, procedure, namely the implementation of the giving account 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 operations 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 Filtb No. z (AOB_FILE#z) and stores it in the data area of the card 31 flash memory. At this point in the element cat is the log 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 Informationprovision (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.... (AOB_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 have accumulated in the RAM 2, equal to at least the size of the cluster. If this takes place, 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 (Frame_Number) 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 Nomercury (Frame_Number) reaches "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. (TMSRT_entry#y) for Elementat No. (AOB_ELEMENT#y). Before performing the 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 252, the process passes to operation S216, in which the CPU 28 decides whether the encoded audio data pause with a pre-set duration, that is reached whether the sound 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. 2 (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 (AOW 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 ADSVR (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 ADSVR (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 ASU is actulay 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, the encryption of files stored GOITER (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) In preveden the m 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 ADSVR (PLMG) receive from the service provider distribute music electronically completed, the transmission of basic information used to create ADFG (TKMG), ADSVR (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), ADSVR (PLMG), which it then writes to flash memory card.

(g) For ease of explanation the description of the recording device and the playback device was made as if they are separate devices, however, the portable playback device may be is provided with the functions of the recording device, and the recording device 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 a communication device 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 phone that has access to the Internet. In the same way 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, such as a terminal adapter connection lines (ISDN digital network integrated services - CSCW).

(d) Shown in the flow chart of the operations (procedures), shown on the drawings sfig on Fig, Fig, with Fig on Fig and Pig may be performed by executable programs, marketing and sales which can be implemented in recorded on the recording medium. This recording medium may be a charge integrated circuit (IC 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. Through the implementation of processing in accordance with these 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 the way in which in 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

The second variant implementation of altoadige invention relates to an improved memory still images together with the files GOITER (AOW files) described in the first embodiment of the invention. These still image display playback CRAW.

{69-1} Hierarchical structure of the flash memory card of the second variant embodiment of the invention

On Fig shows the hierarchical structure of the circuit Board 31 flash memory for this second variant implementation. The difference between the hierarchical structure of the circuit Board 31 flash memory described in this embodiment, from the hierarchical structure according to the first variant implementation is that it reproducible data added OBI (ROS) (objects in the form of images), and to the navigation data added to the administrators of the OBI (POBManagers). OBI (ROS) represent fragments of data of a still image in JPEG format (the format proposed by the joint group of experts on machine processing of images), access to which shall be implemented by the administrator of the playlist (PlaylistManager) and administrator of phonograms (TrackManager). The administrator of the OBI (POBManager) represents control information that describes how it should be accessed at the OBI (ROS) by the administrator of the playlist (PlaylistManager) and administrator of phonograms (TrackManager).

{69-A-1} the structure of the data area of the user-level file system

Since in this embodiment, to reproducible data and navigation data, add additional information, the internal structure of the user data area and the protected area on the file system level change as shown in Figa and Figb. Depicted on Figa the data area of the user differs from that shown in Figa the fact that in addition to the file administrator OBI (POBManager) "POBOOO.POM" add files with names "POBXXX.JPG and POBXXX.SP1".

Files POBXXX.JPG and POBXXX.SP1" correspond to the OBI (the MOAT), shown in Fig and file POBOOO.POM" corresponds to the administrator of the OBI (POBManager). The difference between files "POBXXX.JPG and POBXXX.SP1" is due to the need to protect copyright. Files with the file name extension is "JPG" are simply files containing data of a still image in JPEG format and the file extension of the file name "SP1" were encrypted to ensure copyright protection applicable to still images. Here the abbreviation "SP" stands for "secure image and indicates the need to protect copyright.

In order to allow users to create their own stored content in the flash memory card can be written created by users fixed the images for example, family photos or memorabilia. Because such images usually do not need to protect copyright, their record in the Board flash memory can be carried out in JPEG format without encryption. On the other hand, pictures of the artist and the artwork of the album are usually the property of the artist or the record company. Since there is a risk of unauthorized users copy the images received by the distribution service music electronically recording these images in Board flash memory is carried out in the form of files protected images" ("Secure Picture").

Rooms"001", "002", "003",..., assigned to files with names "POBXXX.SP1" and ".JPG"represent non OBI (ROS), which are assigned to the individual objects (OBI) (ROS), which are images. This means that the depicted objects (OBI) (ROS), which are images that can be specified by using non OBI (ROS).

{69-B-1} the structure of the data area of the user-level file system

On Figb shows the structure of a protected area in this second embodiment of the invention. In comparison with the protected area shown on Figb protected area in this second embodiment additionally contains the file storage the encryption keys, referred to as "POBSP1.key". In this file memorized the keys files (FileKeys), which is used to decrypt (encrypted) file "POBXXX.SP1". After reading the file "POBXXX.SP1" it is necessary to perform the extraction of the key file (FileKey) from this file storing encryption keys POBSP1.key".

Catalogs ED (SD_Audio), shown in Figa and Figb, stored in the server computer, which is administered by the record company that distribute music electronically. When the user places an order on the acquisition of musical content, the server computer compresses the appropriate directory ED (SD_Audio), encrypts it, and then performs transmission to the user who made the order.

The user's computer receives the catalog ED (SD_Audio), decrypts it, unpacks it and, thus, receives the source directory ED (SD_Audio). It should be noted that instead, the computer can boot phonograms (GOITER) (AOW) with accompanying still images (OBI) (MOAT) from the server computer, and then to independently generate catalogs ED (SD_Audio), shown in Figa and Figb, in the circuit Board 31 flash memory.

{69-A,B,C-1} Internal file structure "POBXXX.JPG and POBXXX.SP1"

The following is a description of the internal structure of files "POBXXX.JPG and POBXXX.SP1". On Figa shows the internal art is ucture file "POBXXX.JPG". This file contains unencrypted data of a still image, and therefore, has the same structure as that of the standard file of the JPEG format.

On Figb shows the internal structure of the file "POBXXX.SP1". As shown in the drawing, these files contain Zagolovok (SIOB) (POB_Header (POB_H)) and the encrypted data of a still image in JPEG format.

The internal structure SIOB (ROWN) shown by dotted lines hP1 depicted on Figb. As shown in the drawing, SIOB (ROWN) consists of double-byte IDIOM (ID OBI) (_ID), which is set to "FFE0" to indicate that the current file is the OBI (PIT file), reserved area, occupying one byte, single-byte ATRIB (attribute OBI) (POB_ATR), through which indicate whether "POBXXX.SP1" encrypted data, and a four-byte ABIB (volume OBI) (_SZ), through which indicate the amount of data OBI.

In the case when the file POBXXX.SP1" you have encrypted data is ATRIB (POB_ATR) is set to "0" to indicate that "the body of data exists (i.e., when through the file "POBXXX.SP1 do not make indirect reference to another file). Otherwise, when the file POBXXX.SP1" no encrypted data, instead, remember the file path of f the Lu, contains data of a still image (i.e., when through the file "POBXXX.SP1 carry out an indirect reference to another file). On FIGU shows an example of a file OBI (ROS), in which instead of the encrypted body of data memorized the path to the file.

Name the file "photo001.JPG"specified path "DCIMCtg_001photo001.JPG"marked file in which stored data of a still image for digital pictures taken using a digital photographic camera. In that case, if the file OBI (ROS) as described above specified access path to the directory and file name, it made indirect reference to the image data stored in the file "photo001.JPG"the path which has the form "DCIMCtg_001photo001.JPG". In this "POBXXX.SP1" value ATRIB (POB_ATR) in administratorjob (POBMANAGER) is set to "1" to indicate that there is "no body data.

As one of the examples shows a case in which a necessary condition of a driver device for a digital photographic camera is storing data of a still image obtained by the camera, in particular the specific file directory and specify a JPG file in which stored data of a still image file OBI (ROS), such as that shown in Figv, can be carried out with the use of what Finance indirect references to the path to the file (Figv the device driver for the digital photographic camera determines the required memorization of the files in the wrong place, which is specified by the access path "DCIMCtg_001photo001.JPG" and so on). As a result, the output of such data of a still image on the screen during playback of the music content can be performed even in the case where data of a still image, the recording is performed by a digital camera, recorded in a specific file in a specific directory in accordance with the requirements caused by the device driver.

This completes the description of the playback data for this second variant implementation of the present invention.

{72-1} Administrator of the playlist (PlaylistManager) and the administrator of phonograms (TrackManager)

Displaying files "POBXXX.JPG and POBXXX.SP1" reproduced data is carried out synchronously with the reproduction of phonograms, the description of which was given in the first embodiment of the invention. For such simultaneous display of images together with phonograms administrator of the playlist (PlaylistManager) and the administrator of phonograms (TrackManager) of the second variant of implementation have the structure shown in Fig. On Fig shows the detailed structure of the administrator of the playlist (PlaylistManager) and administrator of phonograms (TrackManager) in this second embodiment. In this embodiment, the wasp is estline administrator of the playlist (PlaylistManager) and the administrator of phonograms (TrackManager) differ from those shown in Fig from the first to the exercise of the option, unlike earlier version of the content Ordainedtothenations (AISURU) (Default_Playlist_General_Information (DPLGI)) and Ordainedtothenations (OSVF) (Playlist_General_Information (PLGI)) is shown explicitly, and that OFG (TKGI) created TRIOBET (TKI_POB_ATR) and twenty new OPIOID (TKI_POB_TKIs).

{72-2} AISURU (DPLGI)

As shown by the dotted lines h61, Alshaya (AISURU) (Default_Playlist_General_Information (DPLGI)) contains field IDOWU (ID SWFU) (DPLI_ID)that contains a unique identifier for SWFU (DPLI), field KOLTHOFF (DPLI_TK_Ns), which recorded the number of phonograms, referenced in SWFU (DPLI), field PRITISH (DPLI_PB_TM), which is in units of milliseconds recorded the total duration of the playlist of all soundtracks, referenced in the playlist, the default field ATTRIBITE (DPLI__ATR) and sixty fields OPHIOLITE (DPLI_POB_SRP).

{72-3} OSWF (PLGI)

As shown by the dotted lines h62, each fragment Ordainedtothenations (OSVF) (Playlist_General_Information (PLGI)) consists of a field IDISP (PLI_ID)that contains a unique identifier for IVF (PLI), field KOLTHOFF (PLI_TK_Ns), which recorded the number of phonograms (the maximum amount to is that equal to "99"), referenced in ISWF (PLI), field PRITISH (PLI_PB_TM), which is in units of milliseconds recorded the total duration of the playlist of all soundtracks, referenced in the playlist, field TRIOBET (PLI_POB_PLI) and twenty fields OPIOIF (PLI_POB_SRP).

{72-4_73} a Brief overview of the additions and improvements implemented in the second embodiment of the invention

From the above explanation it is clear that OFG (TKGI) in this second embodiment additionally contains two types of information: TRIOBET (TKI_POB_ATR) and OPIOID (TKI_POB_TKIs). Similarly, AISURU (DPLGI) additionally contains two types of information: ATTRIBITE (DPLI__ATR) and DPLI__SRPS, and each OSWF (PLGI) also contains two types of information: TRIOBET (PLI_POB_PLI) and OPIOIF (PLI_POB_SRPs).

Each of OPIOID (TKI_POB_TKIs), OPIOIF (PLI_POB_SRPs) and OPHIOLITE (DPLI_POB_SRPs) has the same structure and they are used for the precise determination of the OBI (the MOAT). On Fig shows how through OPIOID (TKI__TKIs), OPIOIF (PLI_POB_SRPs) and OPHIOLITE (DPLI_POB_SRPs) carry out the job files OBI (ROS), which, for example, shown in Figa. Below is a description of the data structure TRIOBET (ATTRIBITE, TRIOBET) (TKI_POB_ATR (DPLI_POB_ATR, PLI_POB_ATR)) and OPIOID (OPHIOLITE, OPIOIF) (TKI_POB_SRPs (DPLI_POB_SRPs, PLI_POB_SRPs).

{74-1} OPIOID (TKI_POB_SRPs)

OPIOID (TKI_POB_SRP) is a field that specifies the OBI (PIT)for displaying on the screen during playback of a specific CROP (AOW) from the total duration of the reproduction of phonograms, the playback order specified by Informatsiejobrashchatsja Default_Playlist_Information or IVF (PLI). In other words, OBI (PIT)for displaying on the screen during playback can be specified by setting the parameters OPIOID (TKI_POB_SRP) the administrator of phonograms (TrackManager).

On Fig shows the data structure OPIOID (TKI__POB_SRPs) and TRIOBET (TKI_POB_ATR).

As shown in the drawing, OPIOID (TKI_POB_SRP) consists of fields specify the OBI (DEN) (DEN Specifying Field (indicated in the drawing as "Numerial" ("POB_No.")), which is located between the bit number b25 and a bit of room b16, the field "number of elements of the image (Number of Pixels), which is located between the bit number b11 and bit number b8, the Huffman table" (Huffman Table), which is located between the bit number b7 and a bit of room b6, field sampling of the color (Chrominance Sampling), which is located between the bit number bit b5 and room b4, and field coding mode of the image (Picture Coding Mode), which is located between the bit number b3 and bit number b0. Fields that are located between the b is that the number b12 and a bit of room b15, and between the bit number b26 and a bit of room b31, are reserved areas.

"Field job OBI (ROS)is used to store numbers with values between "1" and "999", which represents the number of the OBI (ROS)is used to output to the screen during playback of the file GOITER (AOW file)that corresponds to this IDF (TKI). In the case when, during the playback of the file GOITER (AOW file)corresponding to this IDF (TKI), it is not necessary to carry out displaying any stationary images "field specify the OBI (the PIT)" set the value "0".

Field coding mode of the image" is used to notify the playback device about which encoding was used for a still image, which is indicated by "fields specify the OBI (the PIT)".

The "quantization of color" is used to indicate the ratio that was used to discretize the brightness and chroma sampling of two colors for encoding a still image specified in "field, specify the OBI (the PIT)". To indicate that the ratio is "4:2:2"in this field, set the binary value "00"to indicate that the ratio is "4:2:0", - set the value "01".

In the Huffman table indicate whether the display of the still image pointed to by the th through "fields specify the OBI (the PIT)", to use a typical Huffman table. If you want to use the Huffman table the value of this field is set to "00".

The field "number of elements in the picture represents a field which record the size in pixels (picture elements) still image specified in "field, specify the OBI (the PIT)". In the case when the size of the still image specified by "fields specify the OBI (the PIT)", 96*96 pixels, in this field, write the binary value "0000"; in the case when the size of the image specified by "fields specify the OBI (the PIT)"equal to 640*480 pixels, then write the value "0001"; and in the case when the image has a different size in the range from 160*120 pixels up to 1800*1200 pixels, then write the value of "0010".

With this structure OFG (TKGI) contains twenty OPIOID (TKI_POB_SRPs), so during playback on the screen may be displayed a maximum of twenty still images. In that case, when the soundtrack consists of several IDF (TKI), are effective only OPIOID (TKI_POB_SRPs) in the first IDF (TKI)).

{74-2} TRIOBET (TKI_POB_ATR)

"TRIOBET" (TKI_POB_ATR) create in order to specify how to display the OBI (ROS), indicated by twenty OPIOID (TKI_POB_SRPs), OFG (TKGI). "TRIOBET" (TKI_POB_ATR) contains the field "the tunes with regard to the display screen (Display Order Mode), located between the bit with the number b0, and a bit having a room b1, and the "mode with a time-sensitive display screen (Display Timing Mode), located between the bit with the room b2, and a bit having the room b3.

The "mode with regard to the display order on the screen is used to specify the order of display of the OBI (ROS), defined through the twenty-OPIOID (TKI_POB_SRPs) in AIFG (TKGI). In this embodiment, the output of the OBI (the DITCH) on the screen during playback GOITER (AOW) is performed in one of three modes.

The first mode is called the "serial mode" and it represents the mode in which the display of the OBI (ROS), indicated by a maximum of twenty OPIOID (TKI_POB_SRPs) in AIFG (TKGI), carried out in the order in which OPIOID (TKI_POB_SRPs) specified in AIFG (TKGI).

The second mode is called "random mode" and it represents the mode in which the display of the OBI (ROS), indicated by a maximum of twenty-pack OBI IDF (TKI_POB_SRPs) in AIFG (TKGI) is carried out in an arbitrary order.

The third mode is called "permutation mode" and it represents the mode in which the display of the OBI (ROS), indicated by a maximum of twenty OPIOID (TKI_POB_SRPs) in AIFG (TKGI), carried out in random order without repetition.

To set the serial mode, in the "re is them taking into account display order on the screen, set the binary value, equal to "00". Otherwise, to set random mode, set the binary value of "01", and to set the permutation set a binary value of "10".

The "mode with a time-sensitive display screen is used to specify whether the playback of the file GOITER (AOW file), which corresponds to the IDF (TKI), to provide simultaneous display of the OBI (ROS), indicated by a maximum of twenty OPIOID (TKI_POB_SRPs) from OFG (TKGI). The mode in which images are synchronized with audio data, referred to as "mode slide show". In "slide show", the user cannot make the pass displayed in the images, except for the omission of reproduced audio data.

Another mode in which image and sound data are not synchronized, called "view". In playback mode, the user can pass images without skipping audio data.

Thus, in AIFG (TKGI) specify the information that specifies which of the OBI (the DITCH) should be displayed on the screen during playback of the corresponding file GOITER (AOW file), the order in which these OBI (ROS) should be displayed, and whether the conclusion of the OBI (the DITCH) on the screen to carry out synchronously with the playback of the corresponding file ZO is (AOW file).

{74-3_75} Example setting OPIOID (TKI_POB_SRPs)contained in IDF # 1 to # 3 (TKI#1-TKI#3)

On Fig shows as an example the installation option values OPIOID (TKI_POB_SRPs) for IDF with IDF # 1 IDF No. 3 (TKI#1-TKI#3)contained in the administrator of phonograms (TrackManager).

On the first level Fig depicts the administrator of phonograms (TrackManager), and on the second level depicts nine files OBI (ROS files). Shown at the first level, the administrator of phonograms (TrackManager) contains eight IDF (TKI), and arrows indicate which files OBI (ROS files) shall appeal through OPIOID (TKI__SRPs) in these eight IDF (TKI).

As indicated by the arrows, IDF No. 1 (TKI#1) contain three OPIOID (TKI_POB_SRPs), through which set the OBI (the MOAT) with JOB (ROW) JOB (ROW), IDF No. 2 (TKI#2) contain three OPIOID (TKI_POB_SRPs), through which set the OBI (the MOAT) with JOB (ROW) JOB (ROW), and IDF No. 3 (TKI#3) contain three OPIOID (TKI_POB_SRPs), through which set the OBI (the MOAT) JOB (ROW) JOB (ROW).

In this embodiment, suppose that the OBI (the MOAT) with JOB (ROW) JOB (ROW) represent image data in JPEG format, consisting of the words superimposed on the normal background. Words that form a lyrics display with the font corresponding to the character of the song, and they can be is made more expressive, for example, by an additional highlight them in bold font.

On the lower level Fig shows the contents of each of the OBI (the MOAT). The contents of the OBI (the MOAT) with JOB on JOB (ROW-ROW) represents the words of the song to Soundtrack A (TrackA), the contents of the OBI (the MOAT) with JOB on JOB (ROW-ROW) represents the words of the song for the sound track B (TrackB), and the contents of the OBI (the MOAT) with JOB on JOB (ROW-ROW) - the words of the song for the Soundtrack (TrackC). Because the display of these images are meaningful only during playback of the respective phonograms, the values OPIOID (TKI_POB_SRPs)contained in the IDF (TKI), set so that the output of these images on the screen to perform during such playback.

Each soundtrack has the same duration as shown in Fig, to which reference was given in the first embodiment. This means that the duration of the play "001.SA1 corresponding IDF No. 1 (TKI#1), equal to 6.1 minutes duration "002.SA1 corresponding IDF No. 2 (TKI#2), 3,3 minutes, and the duration of the play "AOB003.SA1 corresponding IDF No. 3 (TC#3), is equal to 5.5 minutes. During this play time specified in the IDF (TKIs) OPIOID (TKI_POB_SRPs) become active, and thus the device is in the works may withdraw the OBI (POBs) on the screen in accordance with these operating OPIOID (TKI_POB_SRPs).

Duration "AOBSA1.001 corresponding IDF No. 1 (TKI#1), equal to 6.1 minutes, so if during this period of time the display of the OBI with JOB on JOB (ROW-ROW) on the screen need to be carried out during the same time, then each image will be displayed within 2,03 (=6,1/3) minutes. Duration "AOBSA2.001 corresponding IDF No. 2 (TKI#2), 3,3 minutes, so the output of each of the OBI with JOB on JOB (ROW-ROW) will be carried out during 1,1 (=3,3/3) minutes. Duration "AOBSA3.001 corresponding IDF No. 3 (TKI#3), is equal to 5.5 minutes, so the output of each of the OBI with JOB on JOB (ROW-ROW) will be carried out during 1,83 (=5,5/3) minutes.

{74-4_76} Example setting OPIOID (TKI_POB_SRPs)contained in the IDF from No. 4 to No. 8 (TKI#4-TKI#8)

On Fig shows one example of setting OPIOID (TKI_POB_SRPs) in the IDF with IDF # 4 IDF No. 8 (TKI#4-TKI#8)contained in the administrator of phonograms (TrackManager).

On the first level shows the administrator of phonograms (TrackManager), and the second level shows the ten files OBI (ROS files). As shown by the arrows in the drawing, the IDF No. 4 (TKI#4) contain seven OPIOID (TKI_POB_SRPs), through which, respectively, set JOB-JOB (ROW-ROW).

Similarly, IDF No. 8 (CC#8) contains three OPIOID (TI_POB_SRPs), through which, respectively, set JOB - JOB (ROW-ROW). In the present embodiment, the OBI with JOB on JOB (ROW-ROW), as well as the OBI with JOB on JOB (ROW-ROW)represent the image data in JPEG format, consisting of the words superimposed on the normal background. The reason that OPIOID (TKI__SRPs) ask only for the IDF No. 4 (TKI#4), but not for any IDF from No. 5 to No. 7 (TKI#5-TKI#7), is that, as indicated previously, in the case when a single soundtrack consists of many IDF (TKI), are valid only OPIOID (TKI_POB_SRPs) in the first IDF (TKI).

The contents of the OBI with JOB on JOB - (ROW-ROW) represents the words of the song for the Soundtrack G (TrackD), as shown in Fig of the first variant of implementation, and the contents of the OBI with JOB on JOB (ROW-ROW) represents the words of the song for the Soundtrack D. (TrackE). The total duration of playback of files with "AOB004.SA1" 007.SA1 corresponding to the IDF from No. 4 to No. 7 (TKI#4-TKI#7), equal 30,6 minutes, so the duration of display of each of the OBI with JOB on JOB (ROW-ROW) equal 4,37 (=30,6/7) minutes. As a result, during playback G (TrackD) each of the OBI (ROS) can be displayed on the screen during this time. Since the duration of the play "AOBSA8.SA1 corresponding IDF No. 8 (CC#8), is equal to 7.0 minutes, the duration is displayed for each of the OBI from No. 17 to No. 19 (ROW-ROW) equal 2,33 (=7,0/3) minutes.

{77-1} OPHIOLITE (DPLI_POB_SRP) and ATTRIBITE (DPLI_POB_ATR)contained in AISURU (DPLGI)

While through OPIOID (TKI_POB_SRPs) you can specify exactly what OBI (POBs) to display on the screen when playing each phonograms through the same OPHIOLITE (DPLI_POB_SRPs)specified in AISURU (DPLGI), provide an indication of those OBI (POBs), display them on the screen during playback of many GOITER (AOW) must be performed in accordance with the procedure specified in Informatsiejobrashchatsja (Default_Playlist_Information).

On Fig shown OPHIOLITE (DPLI_POB_SRPs) and ATTRIBITE (DPLI_POB_ATRs)contained in AISURU (DPLGI). From this drawing it is seen that the data contained in AISURU (DPLGI) OPHIOLITE (DPLI_POB_SRPs) and ATTRIBITE (DPLI_POB_ATRs) have exactly the same data structure as OPIOID (TKI_POB_SRPs) and TRIOBET (TKI_POB_ATRs).

Since the order of playback of multiple files, GOITER (AOW files) specified by Informatsiejobrashchatsja (Default_Playlist_Information), shown in Fig OPHIOLITE (DPLI_POB_SRPs) and ATTRIBITE (DPLI_POB_ATRs) can be set so that through them it was stated: (1) what OBI (POBs) should be displayed on the screen during playback multiple files GOITER (AOW files), the playback order specified in Informacijos hpylori (Default_Playlist_Information), (2) in what order should withdraw these OBI (POBs) on the screen, and (3) whether the output of the OBI (POBs) on the screen to be carried out synchronously with the playback of GOITER (AOW), the corresponding IDF (TKI).

{77-2_78} Example setting twenty OPHIOLITE (DPLI_POB_SRPs)

On Fig shows an example of a set of twenty OPHIOLITE (DPLI_POB_SRPs)contained in Informatsiejobrashchatsja (Default_Playlist_Information). The drawing on the first level shown Informatsiyaonnaya (Default_Playlist_Information), and are inside of the framework shown AISURU (DPLGI) and twenty OPHIOLITE (DPLI__SRPs). The second level shows the twenty-files OBI (ROS files) with JOB on JOB (ROW-ROW). As shown by the arrows, through the twenty-OPHIOLITE (DPLI_POB_SRPs) respectively set to twenty files OBI (ROS files) with JOB on JOB (ROW-ROW).

File JOB (ROW) represents the image that is used as the image on the cover of the packaging music album consisting of phonograms from A Phonogram (TrackA) Soundtrack D. (TrackE), file JOB (ROW) represents the logo of the manufacturer, which released this album. Files with JOB on JOB (ROW-ROW) are pictures of the artist, files with JOB on JOB (ROW-ROW) represent images taken srclang video, and files with JOB on JOB (ROW-ROW) are pictures of the actor playing the soundtrack from A Phonogram (TrackA) Soundtrack D. (TrackE) at the concert. OPHIOLITE (DPLI_POB_SRPs) in Informatsiejobrashchatsja (Default_Playlist_Information) specified by the manufacturer of musical content and can therefore be installed so that during playback to provide a display corresponding to the phonograms of images representing the content of musical works, pictures, artist, etc.

During playback GOITER (AOW files), the playback order specified in Informatsiejobrashchatsja (Default_Playlist_Information), the screen will display those files OBI (ROS), which are indicated by OPHIOLITE (DPLI_POB_SRPs)contained in AISURU (DPLGI). In the example shown in Fig, Informatsiejobrashchatsja (Default_Playlist_Information) the playback order of five phonograms: Phonogram And (TrackA) Soundtrack D. (TrackE), is specified by eight IDF (TKI)that form the soundtrack. Meanwhile, in the example shown in Fig through OPHIOLITE (DPLI_POB_SRPs)contained in this Informatsiejobrashchatsja (Default_Playlist_Information), set twenty files OBI (ROS), moreover, is such a task has power over time, equal to the duration of reproduction of phonograms with Phonogram And (TrackA) Soundtrack D. (TrackE), which represents 52.5 minutes. In the case where the playback time equal to 52.5 minutes, should be divided equally between files with JOB on JOB (ROW-ROW), each image will be displayed on the screen during 2,625 (=52,5/20) minutes.

{77-3_79} Replace the image located in the foreground and background images during playback

Fig represents a timing diagram that shows which images are combined in the case when the background images use the OBI (POBs)specified by OPHIOLITE (DPLI_POB_SRP)contained in Informatsiejobrashchatsja (Default_Playlist_Information), and as images are located in the foreground, use the OBI (POBs)specified by OPIOID (TKI_POB_SRPs)contained in the administrator of phonograms (TrackManager).

The drawing on the first level shows the same OBI (POBs), and on the second level of Fig, and the second level shows the same OBI (POBs), and on the second level of Fig and Fig. The scale, passing horizontally in the upper part Fig, specifies the duration, in units of minutes. Consequently, the horizontal size of each of the OBI (the MOAT) on Fig decree which provides a continuous display on the screen of each of the OBI (the MOAT).

From the time of the massive scale on Fig shows that during the period of time from the beginning of the play to the point, corresponding to 6.1 minutes, carry out the sequential display of files with JOB on JOB (ROW-ROW) (representing the words of the song to Soundtrack A (TrackA)) as images are located in the foreground, and at the same time provide a consistent display of files JOB (ROW) (album cover art), IOB (ROW) (the logo of the company-manufacturer), and JOB (ROW) (photo of artist), serving as background images.

During play time between the point corresponding to 6.1 minutes after the beginning of the play, and the point corresponding to 14.9 (=6,1+3.3V+5,5) minutes after the beginning of the play, on the screen as images are located in the foreground, consistently display files with JOB on JOB (ROW-ROW) (representing the words of the songs for the sound track B (TrackB) and Phonograms (TrackC)), and at the same time provide a consistent display of files with JOB on JOB (ROW-ROW) (photos of the artist), employees in as background images.

During the period of time after the point across 14.9 minutes from start playback on the screen as images, located on srednem plan, consistently display files with JOB on JOB (ROW-ROW) (representing the words of the song for the Soundtrack G (TrackD)), and at the same time provide a consistent display of files with JOB on JOB (ROW-ROW) (which are images taken from a promotional film)serving as background images.

{77-4_80}

On the time diagram of Fig display the combined image consisting of JOB (ROW) (lyrics for Phonogram B (TrackB)), located in the foreground, and JOB (ROW) (photo of artist), located on the rear of the plan, carried out starting from the point across of 6.1 minutes after the beginning of playback according Informatsiejobrashchatsja (Default_Playlist_Information). On Fig shows how at this point across to 6.1 minutes after the beginning of playback according Informatsiejobrashchatsja (Default_Playlist_Information), combine an image on the foreground and background images.

{77-5_81}

In the same way that display the combined image consisting of JOB (ROW) (lyrics for Phonogram G (TrackD)), located in the foreground, and JOB (ROW) (frame promotional video), located on the rear of the plan, carried out starting with the glasses, located after 16 minutes after the start of playback according Informatsiejobrashchatsja (Default_Playlist_Information). On Fig shows how at this point, which is after 16 minutes after the start of playback according Informatsiejobrashchatsja (Default_Playlist_Information), carry out the unification of the image on the foreground and background images.

As described above, if the combined image generated by combining the file OBI (ROS), indicated by OPHIOLITE (DPLI_POB_SRP) in Informacijos failover (Default_Playlist_Information) as an image on the foreground, and file the OBI (ROS), indicated by OPIOID (TKI__SRP) in Informatsiejobrashchatsja (Default_Playlist_Information) as a background image, the display on screen lyrics for the currently playing soundtracks can be carried out together with a photograph of the artist, the image of the promotional video for soundtracks, photo, concert, etc. are Specified for display files OBI (ROS) and time their display can also be easily changed by rewriting OPIOID (TKI_POB_SRPs) and OPHIOLITE (DPLI_POB_SRPs) the administrator of phonograms (TrackManager) and Informacijos failover (Default_Playlist_Information).

{82-1} OPIOIF (PLI_POB_SRPs) and TRIOBET (PLI_POB_ATR) in OSWF (PLGI)

Contained in OSWF (PLGI) OPIOIF (PLI_POB_SRPs) and TRIOBET (PLI_POB_ATR) have the same data structure as contained in AISURU (DPLGI) OPHIOLITE (DPLI_POB_SRPs) and ATTRIBITE (DPLI_POB_ATR), and as OPIOID (TKI_POB_SRPs) and TRIOBET (TKI_POB_ATR) in the IDF (TKI). On Fig shown OPIOIF (PLI_POB_SRPs) and TRIOBET (PLI_POB_ATRs)contained in OSWF (PLGI). As in the first embodiment, ISWF (PLI) differs from Informatsiejobrashchatsja (Default_Playlist_Information) the fact that it shows the playback order specified by the user, while OPIOIF (PLI_POB_SRPs) and TRIOBET (PLI_POB_ATR) indicate which of the OBI (POBs) must be displayed on the screen during playback multiple files GOITER (AOW files)specified in a user-specified playback order, the order in which you want to display these OBI (POBs) on the screen and whether the conclusion of the OBI (POBs) on the screen to be carried out synchronously with the playback of the corresponding files GOITER (AOW files). It should be noted that although according to the above description setting values OPHIOLITE (DPLI_POB_SRPs) in Informatsiejobrashchatsja (Default_Playlist_Information) is carried out by the manufacturer of musical content, the values of these OPIOIF (PLI_POB_SRPs) can easily be the Adana by the users themselves.

{82-2_83} Example setting OPIOIF (PLI_POB_SRPs)contained in ISWF (PLI)

Below is a description of the example set OPIOIF (PLI_POB_SRPs)contained in ISWF (PLI).

On Fig shows one example of a set of twenty OPIOIF (PLI_POB_SRPs) in IVF (PLI). The drawing on the first level shows ISWF (PLI)and located inside the framework depicts OSWF (PLGI) and twenty OPIOIF (PLI_POB_SRPs). The second level shows the twenty-files OBI (ROS files) with JOB on JOB (ROW-ROW). As shown by the arrows, through the twenty-OPIOIF (PLI_POB_SRPs) respectively set to twenty files OBI (ROS files) with JOB on JOB (ROW-ROW).

While files with JOB on JOB (ROW-ROW) represent data of a still image created by the manufacturer of musical content, files with JOB on JOB (ROW-ROW) represent data on the still images that are created by the user's personal photos. As an example, JOB (ROW) is a family photo of the user, and JOB (ROW) is a photograph of the ceremony, the end user educational institutions, files with JOB on JOB (ROW-ROW) are pictures of a pet user, files with JOB on JOB (ROW-ROW) represent pictures taken floor is a user during a vacation, conducted in Europe, and files with JOB on JOB (ROW-ROW) are photographs taken by a user during a vacation spent in the United States. For ease of explanation, the total duration of playback GOITER (AOW files)specified by this ISWF (PLI), and the number of the OBI (POBs), configured for display on the screen through this IVF (PLI)are the same as in Informatsiejobrashchatsja (Default_Playlist_Information). This means that specified by this ISWF (PLI) the total duration of playback of phonograms with Phonogram And (TrackA) Soundtrack D. (TrackE) equal to 52.5 minutes, and the display time of each of the files with JOB on JOB (ROW-ROW) on the screen is 2,625 (=52,5/20) minutes in if while playing with this duration, each image should be displayed within the same time.

{82-3_84} Replace the image located in the foreground and background images during playback

Fig represents a timing diagram that shows which images are combined in the case when the background images use the OBI (POBs)specified by OPIAL ISWF (PLI_POB_SRP), contained in the above-described Informacijos files (Playlist_Information), and in the quality of the images, located in the foreground, use the OBI (POBs)specified by OPIOID (TKI_POB_SRPs)contained in the administrator of phonograms (TrackManager).

The drawing on the first level shows the same OBI (POBs), and on the second level of Fig, and the second level shows the same OBI (POBs), and on the second level Fig and Fig. The scale, passing horizontally in the upper part Fig, specifies the duration, in units of minutes. Consequently, the horizontal size of each of the OBI (the MOAT) on Fig specifies the time continuous display of each of the OBI (the MOAT).

From the time scale Fig shows that during the period of time from the beginning of the play to the point, corresponding to 6.1 minutes, carry out the sequential display of files with JOB on JOB (ROW-ROW) (representing the words of the song to Soundtrack A (TrackA)) as images are located in the foreground, and at the same time provide a consistent display of files JOB (ROW) (pictures of the family), IOB (ROW) (pictures of the ceremony of graduation) and IOB (ROW) (pictures pet), employees as background images.

During play time between the point corresponding to 6.1 minutes after the beginning of the play, and the point is Oh, corresponding to 14.9 (=6,1+3.3V+5,5) minutes after the beginning of the play, on the screen as images are located in the foreground, consistently display files with JOB on JOB (ROW-ROW) (representing the words of the songs for the sound track B (TrackB) and Phonograms (TrackC)), and at the same time provide a consistent display of files with JOB on JOB (ROW-ROW) (photos pet), serving as background images.

During the period of time after the point across 14.9 minutes from start playback on the screen as images are located in the foreground, consistently display files with JOB on JOB (ROW-ROW) (representing the words of the song for the Soundtrack G (TrackD)), and simultaneously carry out a sequential display of a file JOB and files with JOB on JOB (ROW,ROW-ROW) (photos taken during a holiday spent in Europe), serving as background images.

Thus, despite the fact that the choice of the OBI (POBs), defined by Informatsiejobrashchatsja (Default_Playlist_Information), carries out the record company that creates music content, and they usually represent an image of the artist and images associated with musikalisasi, the user can make an arbitrary choice of the OBI (POBs), defined by IVF (PLI), and therefore, they can be highly personalized.

{82-4_85}

On the time diagram for Fig combined image consisting of JOB (ROW) (lyrics for Phonogram B (TrackB)), located in the foreground, and JOB (ROW) (photo pet), located in the background, display, starting with the point across of 6.1 minutes after the start of the above-described playback according Informatsiya (Playlist_Information). On Fig shows how to carry out the unification of the image on the foreground, and the background image at this point across to 6.1 minutes after the beginning of playback according to this Informatsiya (Playlist_Information).

{82-5_86}

Similarly, the carry output to the screen and the combined image consisting of JOB (ROW) (words of the song for the Soundtrack G (TrackD)), located in the foreground, and JOB (ROW) (pictures taken during a vacation spent in Europe), located on the rear of the plan, starting from the point located after 16 minutes after the start of playback according to this Informatsiya (Playlist_Information). On Fig shows how the implementation is given in Association images located in the foreground, and the background image at this point, which is after 16 minutes after the start of playback according to this Informacijos files (Playlist_Information). The words of the song, which form a part of this total images are the same as in Fig and Fig, but because the background images are different, the cumulative image on Fig and Pig have a completely different view compared to the images on Fig and Fig.

As described above, by means specified by the user OPIOIF (PLI_POB_SRPs) in IVF (PLI), you can specify files OBI (ROS files), which differ from those indicated by Informatsiejobrashchatsja (Default_Playlist_Information), and therefore, the user can display his/her favorite image while playing his/her favorite soundtracks.

{82-6_87} for an Example of setting the same OBI (POBs) in OPHIOLITE (DPLI_POB_SRPs) from Informatsiejobrashchatsja (Default_Playlist_Information)

The examples on Fig, Fig, Fig and Fig, all OPHIOLITE (DPLI_POB_SRPs)contained in Informatsiejobrashchatsja (Default_Playlist_Information)indicate different files OBI (ROS files), although possible in which two or more OPHIOLITE (DPLI_POB_SRPs) from Informazione evalprovision (Default_Playlist_Information) have the same file OBI (PIT file). Through this can be done displaying the same file OBI (PIT file) for the duration of playback of multiple phonograms, which reduces the number of files OBI (ROS files)that need to create a manufacturer of recording of musical works. This reduces the time and cost required to create a record of a musical work.

On Fig shows one example in which the number of files OBI (ROS files) reduce due to the fact that by part OPHIOLITE (DPLI_POB_SRPs) from Informatsiejobrashchatsja (Default_Playlist_Information) specified the same file OBI (PIT file). In this drawing JOB (ROW) specified by as OPHIOLITE NO. 1 (DPLI_POB_SRP#1)and OPHIOLITE NO. 4 (DPLI_POB_SRP#4), and JOB (ROW) specified by as OPHIOLITE NO. 2 (DPLI_POB_SRP#2), and OPHIOLITE NO. 5 (DPLI_POB_SRP#5).

{82-7_88} Replace images on the front and background images during playback

Fig represents a timing diagram showing how images are combined in the case when the background images use the OBI (POBs)specified by the above-described OPHIOLITE (DPLI_POB_SRP)contained in Informatsiejobrashchatsja (Default_Playlist_Information), as well as images, whic is its in the foreground, use the OBI (POBs)specified by OPIOID (TKI_POB_SRPs)contained in the administrator of phonograms (TrackManager).

And this timing diagram shows that the output on the screen IOB (ROW)representing the image on the cover of the packaging, carry out a total of three times, namely at the beginning of the play, through 7,875 minutes after the beginning of the play through of 15.75 minutes after the beginning of playback. Similarly, the output on the screen IOB (ROW), representing the logo of the record company, carried out a total of three times, namely through 2,625 minutes after 10.5 minutes and through 18,375 minutes after the beginning of playback. In the case when the values OPHIOLITE (DPLI__SRPs) is installed as shown in Fig, then the screen repeatedly output the same OBI (ROS), consequently, it is possible to repeatedly display images intended for repeated use, for example, photo album, music album or logo of the record company.

This complete description OIFG, AISURU, OSWF (TKGI, DPLGI, PLGI).

(69-4_89) ADIB (POBMG)

Below is a description of the administrator of the OBI (ADIB) (POBManager (POBMG)), which is a new item which is created in the navigation information in the second embodiment. On Fig shows the structure ADIB (POBMG).

As p is shown in the drawing, ADIB (POBMG) consists of information about the management of the OBI (IFOB) (POBMGI) and information about the reference OBI (IOOB) №1, №2,... # n ((ROWS)#1, #2 ... #n).

{69-4_89-1} IFOB (POBMGI)

As shown in Fig dashed lines, the control information of the OBI (IFOB) (POBMGI) contains information about the ID IFOB (POBMGI), which is the 0-th and 1-th byte reserved field, which occupies the 2nd and 3rd fields, field CALIB (quantity OBI) (_Ns), which occupies the 4th and 5th field, and a reserved field, which occupies the 6th and 7th fields.

In the information field ID IFOB (POBMGI) record identifier (code character set "A6" according to the standard IS0646)that uniquely identifies IFOB (POBMGI). In the field CALIB (POB_Ns) record the amount of the OBI (POBS), which takes a value in the range from "0" to "999". This completes the description IFOB (POBMGI).

{69-4_89-2} IOOB (POBCI)

Below is a description of the information about the reference OBI (IOOB) (POBCI). Information about the reference OBI represents control information, which is created separately for each of the OBI (the MOAT). Bitwise structure information about the reference OBI (ROS) are shown in Fig dashed lines. That is, information about the reference OBI contains the field "XIV" (the number of links on the OBI) (POB_RCN), which occupies the area from the bits having the room to bits b0, with room b9, reserved field, which is imeet region from bits, having the number b0 to b13, and the existence of data that occupies a region from the bit with the room b14 to bits with room b15.

{69-4_89-3} XIB (POB_RCN)

Field XIB" (kolichestvennaia) (POB_RCN) indicates whether through AISURU (DPLGI), OSWF (PLGI), or OFG (TKGI) for displaying on the screen of the OBI (ROS), which corresponds to IOOB (POBCI). In the case when the corresponding OBI (ROS) is specified, the number of links, in which he specified, that is, the number of IDF (TKI)that specify the OBI (PIT)for displaying on the screen, write down the numbers taking values in the range from "1" to "999".

As in the first embodiment, the invention may be carried out destruction of IDF (TKI) and, therefore, set the parameters in Informatsiejobrashchatsja (Default_Playlist_Information) and Informatsiya (Playlist_Information) can be easily modified by users. In the case of a deletion of one or more IDF (TKI), which indicated specific OBI (ROS)by OBI (ROS) must perform the reduction of the number of links on the OBI (the MOAT reference count) in accordance with the number of remote IDF (TKI), in which it was specified. Also when removing Informatsiejobrashchatsja (Default_Playlist_Information) or IVF (PLI) Zachanassian (_RCN) must be reduced by the number of remote IDF (TKI), which indicated that the OBI.

In the case when the OBI (ROS) is not specified in AISURU (DPLGI), OSWF (PLGI), or OFG (TKGI), is Kolichestvennaia (_reference_count) is set to "0". Since the appeal to the OBI (the MOAT), Kolichestvennaia (_reference_count) is equal to "0," not implemented by IDF (TKI) or playlist, deleting IDF (TKI) or playlist playback device can detect the OBI (POBs), Kolichestvennaia (POB_reference_count) which are set to zero, and implement deleting files OBI (ROS files), in which it is remembered such OBI (POBs), which reduces the amount of data of a still image recorded in the flash memory.

In that case, if some of the OBI (POBs) only apply to certain phonograms and display on the screen such OBI (POBs) makes sense only when playback of the respective phonograms, in order to avoid wasteful use of the memory capacity of memory cards, such OBI can be removed (POBs) in the case when Kolichestvennye (reference_count_number) becomes zero. This can be applied to the OBI (POBs), representing the words of the songs for the soundtracks recorded in the Board flash memory.

In addition to the case in which the removal of one or more IDF (TKI), the decrease in value if estatsticas (reference_count_number) can be performed in the same way, and when you remove the OBI (the MOAT), specified in UPOB SWFU (DPLI_POB_SRP), OPIOIF (PLI_POB_SRP) and/or OPIOID (TKI_POB_SRP), by editing operations.

{69-4_89-4} Field "exist"

The value of the field "the existence of data, which occupies the area from bit number b14 to bits with the number b15 set to indicate whether or not there is the OBI (ROS), which corresponds to the present number of the OBI (the MOAT). In the case when the corresponding OBI (ROS) exists, this field sets the binary value of "01", and in that case, when such an OBI (the MOAT) does not exist, set the value equal to "00". Here, the data is considered "existing" in that case, if there is data, which are valuable in themselves.

When this field indicates that the OBI (the MOAT) exists, and remove IDF (TKI) or IVF (PLI) has led to the fact that the value Kolichestvennaia (POB_reference_count) has reached "0", the playback device decides that the OBI (the MOAT), corresponding to the zero value Kolichestvennaia (POB_reference_count), must be saved and, therefore, the OBI (ROS) will not be deleted.

If the OBI (ROS), which is valuable in itself, regardless of the presence of links to it in the IDF (TKI) or IVF (PLI), then the existence of the data corresponding to this OBI (ROS)may be set equal to "1". Through the your setting values, "0"in the field of existence of the data corresponding to the OBI (POBs), which have value only if there are references to them in the IDF (TKI) or in the playlist, it becomes possible to carry out selective preservation Board flash memory only those OBI (POBs), which are valuable in themselves. The OBI (POBs), display them on the screen makes sense only when it is carried out together with the reproduction of the phonogram (i.e. the OBI (POBs), which are of no value in themselves), can be removed by deleting the corresponding phonogram, which allows efficient use of the memory capacity of memory cards.

This completes the description of the administrator of the OBI (ADIB) (POBManager (POBMG)).

{69-5} Update, co-editing IDF (TKIs)

The following is a description of how to perform the update OPIOID (TKI_POB_SRPs) and OPHIOLITE (DPLI_POB_SRPs) in the following five cases. The first four cases are the same as in the first embodiment, so that 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) choose two from a variety of phonograms and their unification into one soundtrack. In the fourth case (case 4) carry out the separation of one Phono the programmes and the creation of two phonograms. In the fifth case (Example 5) change the playback order of phonograms.

In Example 1, in which the removal of a phonogram, the value of each IDF (TKI), corresponding to the soundtrack, set as "Unused" and make a removal OPIOID (TKI_POB_SRPs) in each IDF (TKI). Simultaneously, reduce the value Kolichestvennaia (_reference_count) in administratorjob (POBManager) OBI (POBs), which are indicated by these OPIOID (TKI__SRPs). This deletion does not affect the OBI (POBs), which is indicated by OPIOIF (PLI_POB_SRPs) and/or OPHIOLITE (DPLI_POB_SRPs) in AISURU (DPLGI) or OSWF (PLGI).

In the case when UPFLUSH (DPL_TK_SRPs) change in such a way that through them to specify a different order of phonograms (Example 5), the order of reproduction of phonograms will change, this will also change the display order on the screen of the OBI (POBs)specified by OPIAL IDF (TKI_POB_SRPs).

In Example 3, the preferred option is the one that also provide the Association OPIOID (TKI__SRPs) in the IDF (TKI). This is because for the soundtrack, consisting of many IDF (TKI), are valid only OPIOID (TKI_POB_SRPs) in the first IDF (TKI). After performing the merge operation of phonograms required by OPIOID (TKI_POB_SRPs) of the first IDF (TKI) to specify the OBI (POBs), which is set through the om OPIOID (TKI__SRPs) second IDF (TKI).

When the separation of the phonogram (Example 4) you need to change TREBLED (TKI_BLK_ATR) phonograms and sharing TMVGPBR (TKTMSRT) and TIB (BIT) as described in the first embodiment. In addition, it is also necessary to divide OPIOID (TKI_POB_SRPs)specified in AIFG (TKGI), into two groups, which are assigned, respectively, the former IDF (TKI) and a new IDF (TKI)that are created by partitioning.

{69-6} Example of practical use OPIOID (TKI_POB_SRPs) and OPHIOLITE (DPLI_POB_SRPs)

As described above, the structure of the data administrator of phonograms (TrackManager) and administrator of the playlist (PlaylistManager) allow the user to arbitrarily change the relationship between files GOITER (AOW files) and OBI (POBS) by changing the set values OPIOID (TKI_POB_SRPs) OPHIOLITE (DPLI_POB_SRPs) and OPIOIF (PLI__SRPs). This means that the manufacturer of musical content can deliver to consumers musical content with different amount of data of a still image, such as a phonogram with the words of the songs, soundtracks without words songs and soundtracks from the words of the songs and background images. Needless to say, the manufacturer may assign a different price for these different types of content.

In the case when the consumer desire is t to buy the soundtrack without words songs the manufacturer can create a catalog ED (SD_Audio), which contains eight GOITER (AOW)described in the first embodiment, and the administrator of phonograms (TrackManager), in which, as shown in Fig through OPIOID (TKI_POB_SRPs) in IDF # 1 to # 8 (TKI#1-TKI#8) set the OBI with JOB on JOB (ROW-ROW). Then the manufacturer compresses this directory, encrypts it and transmits it to the personal computer of the consumer. It should be noted that instead of a personal computer user can load phonograms (GOITER) (AOW) and still images (OBI) (POBs), corresponding to the phonograms, computer server, which is administered by the record company, and the generation of directory PUBLISHERS (SD Audio), shown in Figa and Figb, in the circuit Board 31 flash memory.

In the case when the consumer wishes to purchase the soundtrack with the lyrics, the manufacturer may create a catalog ED (SD_Audio), which contains eight GOITER (AOW)described in the first embodiment, and the administrator of phonograms (TrackManager), in which, as shown in Fig and Pig through OPIOID (TKI_POB_SRPs) in IDF # 1 to # 8 (TKI#1-TKI#8) set the OBI with JOB on JOB (ROW-ROW), which correspond to the words of the songs. Then the manufacturer compresses this directory, encrypts it and transmits it to the personal computer of the consumer.

In tomslake, when the consumer wishes to purchase the soundtrack with lyrics and background images, the manufacturer may create a catalog ED (SD_Audio), which contains eight GOITER (AOW)described in the first embodiment, the administrator of phonograms (TrackManager), in which, as shown in Fig and Pig through OPIOID (TKI_POB_SRPs) in IDF # 1 to # 8 (TKI#1-TKI#8) set the OBI with JOB on JOB (ROW-ROW), corresponding to words of the songs, and the administrator of the playlist where by OPHIOLITE (DPLI_POB_SRPs) set the OBI with JOB on JOB (ROW-ROW), shown in Fig. Then the manufacturer compresses this directory, encrypts it and transmits it to the personal computer of the consumer. Since in the present embodiment, data of a still image can be easily set in accordance with the sound data by setting the values OPION IDF (TKI_POB_SRPs), OPHIOLITE (DPLI_POB_SRPs) and OPIOIF (PLI_POB_SRPs), can be easily created a music content having a different value in accordance with the number of attached data of a still image.

{90-1_91} the playback Device to the second variant embodiment of the invention

Below is a description of the playback device for the second variant implementation. This device is in playback differs from the playback device, described in the first embodiment, so that as the playback device in the first embodiment is a portable playback device according to the second variant implementation is designed to be installed in the vehicle as a stereo system.

On Fig shows how to use the playback device according to the second variant implementation, and on Fig shows the appearance of the playback device.

The playback device according to this second variant of implementation differs from the playback device according to the first variant of realization of the fact that it is installed in the vehicle as shown in Fig, the fact that it contains a large LCD panel 5, and the fact that it is connected with the speakers of the car. Due to the large LCD panel 5, the playback device according to this second variant implementation is well adapted for display on the screen the above-mentioned various types of data on the still images.

The second difference from the playback device according to the first variant implementation is that the playback device according to the second variant of implementation has the decoder 7 random sequences, which can decrypt both the encrypted audio data, and encrypted OBI (POs). In the case when the OBI (ROS) has been encrypted and saved in a file OBI (PIT file)with the file name ".SP1"key file (FileKey)stored in the Write access to the key file in the file storing the encrypted key POBSP1.KEY", set in the decoder 7 random sequences, through which then carry out the decryption of the file ".SP1".

The third difference from the playback device according to the first variant implementation is that in the playback device according to the second variant of realization remember the program that contains the processing necessary for displaying the OBI (POBs) in the form of images, located in the foreground or background images. This program output images on the screen provides the CPU 10 of the playback device.

{90-2_92_93_94}

Below is a description of the structure of the playback device according to this second variant implementation. The structure of the playback device shown in Fig, differs from the structure of the playback device of the first variant of realization of the fact that it contains a lot of RAM 61 for video (VRAMs).

Many RAM 61 for video (VRAMs) agreed with the relevant single graphic planes (layers). RAM video (VRAM) graphics PLO the bone has transparency α whose value for each picture element (pixel) is set in the range from 0 to 100%. The image intended for display on a screen of the first LCD panel 5, is calculated according to the equation below. On Figa shows how to perform combining still images stored in multiple RAM 61 for video (VRAMs).

The EQUATION

The pixel value for each pixel =

The value of the pixel in the graphics plane 0* (1-α)

+ The value of the pixel in the graphics plane 1*

For those parts of the image on the foreground, which correspond to the letters that represent the words of the song, transparency α set to 0%. As a result, those parts of the background image, the location of which corresponds to a string of letters represent words of the song are completely hidden. Conversely, for those parts of the image on the foreground, which represent typical background lyrics, transparency α set equal to 100%. This means that the display on the screen is contained in the total image of rows of letters that represent words that are in the graphics plane 0, carried out over the background image in the graphics plane 1.

Setting prozracnost is this way, you can create a combined image, in which the page with the lyrics superimposed over the background image as shown in Fig and Fig. It should be noted that the combined image may be created by methods other than that shown in Figa. As an example, which is shown in Figb, the lyrics can be found at the bottom of the screen and the background image is carried out in the upper part.

{94-1} the precedence Diagram of a procedure of displaying an image on the foreground

Fig is a precedence diagram showing a procedure of displaying an image on the foreground. At the beginning of the play, which is carried out according to the IDF No. z (TKI#z)specified by Informatsiejobrashchatsja (Default_Playlist_Information), at operation S402, the CPU 10 decide whether through OPIOID (TKI_POB_SRPs)contained in AIFG (TKGI) of the IDF No. z (TKI#z), any of the OBI (POBs). In the case when, through OPIOID (TKI_POB_SRPs) specify one or more files of the OBI (the MOAT files), then processing passes to operation S403, at which the CPU 10 counts the number of files OBI (ROS files)specified by OPIOID (TKI_POB_SRPs), with eradica in AIFG (TKGI). In operation S404, the CPU 10 calculates the display time on the screen Vremia" ("POB_time")that specifies the duration of display of each file OBI (PIT file). Then, in operation S405 he does appeal to TRIOBET (TKI__ATR) in AIFG (TKGI) and determines the display mode on the screen, used for output files OBI (ROS files) on the screen. In the case when TRIOBET (TKI_POB_ATR) specify the serial mode, then processing is transferred from operation to operation S405 S406, in which initialize the variable i, and for the operation S407, in which the display file OBI (PIT file)specified by the i-th UE JOBID (TKI__SRP), during the time display on the screen Vremain (_time).

If at this point the file OBI (PIT file)specified by OPIOID (TKI_POB_SRP), has the extension "JPG", OBI (ROS) output directly to the screen. Otherwise, if the file OBI (PIT file)specified by OPIOID (TKI_POB_SRP), has the extension "SP1", it means that the file OBI (PIT file) is in an encrypted state, so the CPU 10 performs the read key file (FileKey)corresponding to the file OBI (PIT file)from a protected area, the transcript file OBI (PIT file) using the encryption key and the output of the OBI (the DITCH) on the screen.

After that, when executed the operation S408, the CPU 10 makes a decision about did the variable i to the value specified in CALIB (POB_Ns). If not, then processing is transferred to the operation S409, in which the increment of the variable i, and then return to the operation S407. Then processing through operations S406 in S409 is repeated up until the variable i reaches the value specified in CALIB (POB_Ns). As a result, provide a consistent display of those OBI (POBs), which is indicated by OPIOID (TKI__SRPs) in AIFG (TKGI). When the variable i reaches the value specified in CALIB (POB_Ns), then the processing in this scheme, the sequence of operations completes.

In the case when TRIOBET (TKI_POB_ATR) specified random mode, processing is transferred from operation to operation S405 S410, in which initialize the variable i, and for the operation S411, in which the CPU 10 performs the generation of a random number r in the range from 1 to KOLOB (POB_Ns). In operation S412 carry out display of a file of the OBI (PIT file)specified by the r-th OPIOID (TKI_POB_SRP)corresponding to the random number r, the time display on the screen Vremain (POB_time), which was determined at operation S404.

After that, when the operation S413, the CPU 10 decides as to whether the variable i value, the backside of the frame in CALIB (POB_Ns). If not, then processing is transferred to the operation S414, which increments the variable i, and then return to the operation S411. In operation S411, the CPU 10 carries out the generation of different random numbers r in the range from 1 to KOLOB (POB_Ns), and the processing procedure is again transferred to the operation S412, in which the CPU 10 reads the file OBI (PIT file)that is specified by the r-th OPIOID (TKI_POB_SRP)corresponding to the random number r, and provides its output to the screen during the display time on the screen Vremain (_time), which was determined at operation S404.

As described above, if the file OBI (PIT file)specified by OPIOID (TKI_POB_SRP), has the extension "JPG", OBI (ROS) output directly to the screen. Otherwise, if the file OBI (PIT file)specified by OPIOID (TKI_POB_SRP), has the extension "SP1", it means that the file OBI (PIT file) is in an encrypted state, so the CPU 10 performs the read key file (FileKey)corresponding to the file OBI (PIT file)from a protected area, the transcript file OBI (PIT file) using the encryption key and the output of the OBI (the DITCH) on the screen.

After this processing by operations S411 on S414 to repeat until the variable i reaches the value specified in CALIB (POB_Ns). In R is the result, carried out sequentially displaying on the screen in a random order, those of the OBI (POBs), which is indicated by OPIOID (TKI_POB_SRPs) in AIFG (TKGI). When the variable i reaches the value specified in CALIB (POB_Ns), then the processing in this scheme, the sequence of operations completes.

In the case when TRIOBET (TKI_POB_ATR) is specified, the mode changes in the procedure of moving from operation to operation S405 S415 in which initialize the variable i, and for the operation S416 in which the CPU 10 performs the generation of random numbers in the range from 1 to KOLOB (POB_Ns).

In operation S418, the CPU 10 checks whether the resulting generation of a new random number r with one of the used room in the OBI (ROS), which have been previously memorized. If it matches, then the procedure returns to operation S416 in which re-generate a random number r. If it does not match, then processing is transferred from the operation S418 to the operation S419, which is displayed on the screen of the file OBI (PIT file)specified by the r-th OPIOID (TKI_POB_SRP)corresponding to the random number r, the time display time on the screen of the OBI (POB_time), which was determined at operation S404. Then, when the operation S417, the CPU 10 Zap minuet random number r as used rooms of the OBI (the MOAT).

As in the random mode, if the file OBI (PIT file)specified by OPIOID (TKI_POB_SRP), has the extension "JPG", OBI (ROS) output directly to the screen. Otherwise, if the file OBI (PIT file)specified by OPIOID (TKI_POB_SRP), has the extension "SP1", it means that the file OBI (PIT file) is in an encrypted state, so the CPU 10 performs the read key file (FileKey)corresponding to the file OBI (PIT file)from a protected area, the transcript file OBI (PIT file) using the encryption key and the output of the OBI (the DITCH) on the screen. At the end of this display perform an operation S420, when the CPU 10 decides as to whether the variable i is the value specified in CALIB (POB_Ns). If not, then processing is transferred to the operation S421, which increments the variable i, and then return to the operation S416. After this processing, which is performed through operations S416 in S421, repeat until, until the variable i reaches the value specified in CALIB (POB_Ns). When the variable i reaches the value specified in CALIB (POB_Ns), then the processing in this scheme, the sequence of operations completes.

{95-1} the precedence Diagram of a procedure of displaying a background image

Above was the description of the procedure output to the screen image is Azania, located in the foreground, and the following is the procedure to display the background image. The precedence diagram for the procedure of displaying the background image shown in Fig. The sequence diagram of operations contains essentially the same procedure as the diagram of the sequence of operations Fig, and instead OPIOID (TKI_POB_SRPs) and TRIOBET (TKI_POB_ATRs) in AIFG (TKGI) treatment is carried out according OPHIOLITE (DPLI_POB_SRPs) and ATTRIBITE (DPLI_POB_ATR) in AISURU (DPLGI).

In the case when the selection Informatsiejobrashchatsja (Default_Playlist_Information), the CPU 10 carries out the processing by operations S502 in S505. As operations S402 through S405, the CPU 10 decides whether through OPHIOLITE (DPLI_POB_SRPs)contained in AISURU (DPLGI), any of the OBI (POBs). In that case, when you specify one or more files of the OBI (the MOAT files), the CPU 10 counts the number of these files OBI (ROS files), and calculates the display time on the screen Vremia" ("POB_time")that specifies the duration of display of each file OBI (PIT file), and then determines the display mode on the screen, used for output files OBI (ROS files) on the screen.

In the case when ATTRIBITE (DPLI_POB_ATR) specified serial mode, C is 10 performs operation S506 in S509. As and when performing operations with S406 in S409, the image files of the OBI (the MOAT files) on the screen carried out sequentially in the order corresponding to OPHIOLITE (DPLI_POB_SRP) from OPHIOLITE (DPLI_POB_SRPs)contained in AISURU (DPLGI), which is specified by the variable i.

In the case when ATTRIBITE (DPLI_POB_ATR) specified random mode, the CPU 10 performs operations S510 in S514. As and when performing operations S410 through S414, displaying files OBI (ROS files) on the screen is carried out in a random order in accordance with OPHIOLITE (DPLI_POB_SRP) from OPHIOLITE (DPLI_POB_SRPs)contained in AISURU (DPLGI), which is specified by a random number r.

In the case when ATTRIBITE (DPLI_POB_ATR) is specified permutation, the CPU 10 performs the operation S515 on S521. As and when performing operations with S415 at S421, displaying files OBI (ROS files) on the screen is carried out in a random order without repetition in accordance with OPHIOLITE (DPLI_POB_SRP) from OPHIOLITE (DPLI_POB_SRPs)contained in AISURU (DPLGI), which is specified by a random number r.

{96-1} the precedence Diagram of a procedure of displaying a background image

This completes the description of the procedure of displaying a background image, which is done using OPHIOLITE (DPLI_POB_SRPs) in AISURU (DPLGI). Below is the procedure to display the background image is of, which is done using OPIOIF (PLI__SRPs) in OSWF (PLGI). Fig is a precedence diagram showing a procedure of displaying a background image using OPIOIF (PLI__SRPs). Except for the procedures based on the use of OPHIOLITE (DPLI_POB_SRPs), compliance shall be performed by using OPIOIF (PLI_POB_SRPs), this sequence of operations is exactly the same as the precedence diagram of Fig, so the operations are assigned the same reference numbers. Explanation Pig will not be given.

{94-2_95-A,B,C} Examples of images displayed on the screen of the LCD panel 5

In the drawings, with Figo on FIGU shows what the cumulative image display on the LCD panel 5 in the case where the display of the image on the foreground, which is specified by OPIOID (I__SRP), and background image specified by AISURU (DPLGI), carried out according to the procedures displayed on the screen shown in the flow chart of the operations of Fig and Fig.

In the example on Figa assume that the user specified Informatsiyaonnaya (Default_Playlist_Information) and that the display of the OBI (POBs) on the start screen in accordance with the order of play, which is Adam in this playlist. By performing a procedure of displaying an image on the foreground, which is shown in Fig, and procedures of displaying the background image, which is shown in Fig, perform displaying on the screen one after the other OBI (POBs)specified by OPIOID (TKI_POB_SRPs) in AIFG (TKGI) as intended for display on the screen, and the OBI (POBs)specified by OPHIOLITE (DPLI_POB_SRPs) in AISURU (DPLGI) as intended for display on the screen. To a point located six minutes after the start of playback, combine images as shown in Fig, and on the screen of the LCD panel 5 display the combined image shown in Figb.

In the point across sixteen minutes after the start of playback, combine images as shown in Fig, and on the screen of the LCD panel 5 display the combined image shown in Figv.

{94-2_96-A,B,C} Examples of images displayed on the screen of the LCD panel 5

In the drawings, with Figo on FIGU shows what the cumulative image display on the LCD panel 5 in the case where the display of the image on the foreground, which is specified by OPIOID (TKI__SRP), and background image specified by OPIOIF (PLI_POB_SRP), carried out according to the procedures of the output is to the screen, shown in the flow chart of the operations Fig and Fig.

In the example on Figa assume that the user specified ISWF (PLI) and that the display of the OBI (POBs) on the start screen in accordance with the order of play, which is set in the playlist. By performing a procedure of displaying an image on the foreground, which is shown in Fig, and procedures of displaying the background image, which is shown in Fig, perform displaying on the screen one after the other OBI (POBs)specified by OPIOID (TKI_POB_SRPs) in AIFG (TKGI) as intended for display on the screen, and the OBI (POBs)specified by OPIOIF (PLI_POB_SRPs) in OSWF (PLGI) as intended for display on the screen. To a point located six minutes after the start of playback, combine images as shown in Fig, and on the screen of the LCD panel 5 display the combined image shown in Figb. In the point across sixteen minutes after the start of playback, combine images as shown in Fig, and on the screen of the LCD panel 5 display the combined image shown in Figv.

{99_1} recording Device of the second variant embodiment of the invention

Below is a description of the recording device of this second in the approaches of implementation. This recording device is different from the recording device of the first variant of realization of the fact that it can write to the flash memory card set the OBI (POBs) and use the settings in OPIOID, OPHIOLITE and OPIOIF (TKI_POB_SRPs, DPLI_POB_SRPs, PLI_POB_SRPs), and perform the setting in TRIOBET, ATTRIBITE and TRIOBET (TKI_POB_ATR, DPLI_POB_ATR, PLI_POB_ATR).

To implement these operations, the CPU 10 in the recording device of this second variant implementation performs the procedure shown in Fig. Below is a description of the procedures for recording performed by the recording device of this second variant of implementation, with reference to the sequence diagram of the operations depicted in Fig.

When the operation 3601 the CPU 10 performs initialization of various variables used in this procedure. These variables are: "x", "y", "z", "u", "vy" and "w" (#x, #y, #z, #u, #vy, #w). Variable "x" (#x) is used to indicate currently being processed OBI (ROS), the variable "y" (#) is used to specify the current time sequence of phonograms (IVF) (PLI), and the variable z (#z) is used to specify the currently phonogram (IDF) (TKI). The variable "u" (#u) determines which of OPHIOLITE (DPLI__SRPs) process at the current time, and the variable "vy" (#vy), is the aka of OPIOIF (PLI_POB_SRPs) in IVF No. (PLI#y), specified by the variable "Y" (#) are processed in the current time. The variable w (#w) determines what OPIOID (TKI_POB_SRPs) in the IDF No. z (TKI#z)specified by the variable z (#z)are processed in a given time.

After initializing these variables, the CPU 10 proceeds to operation S602, in which he performs display on the screen OBI No. x (PIT#x). This allows the user to perform a visual confirmation of pictures, drawings or pages with the words of the song from the OBI (the MOAT). In operation S603, the CPU 10 prompts the user to specify whether data of a still image of OBI No. x (PIT#x) to display on the screen during the whole sequence of phonograms or only during the playback duration of a particular phonogram, and then receives data produced by the user selection.

In the case when the user decides that the OBI No. x (PIT#x) you must assign a sequence of phonograms, then perform an operation S604, in which the CPU 10 waits for the data about the user specifies the sequence of phonograms, which should be displaying the OBI No. x (PIT#x) on the screen. When the user enters data about his/her choice, the procedure is transferred to the operation S605, when the CPU 10 decides whether a member of the whether the specified sequence No. (#) phonograms SWFU (DPLI) or IVF (PLI). In the case when the sequence No. (#) phonograms is SWFU (DPLI), then processing is transferred to the next operation S606, in which OPHIOLITE No. u (DPLI_POB_SRP#u) set the OBI No. x (POB#x), and then to operation S607, in which on the basis of this OBI No. x (PIT#x) set the value ATTRIBITE No. u (DPLI_POB_ATR#u) in SWFU (DPLI).

After this method is set to OPHIOLITE (DPLI_POB_SRP) and ATTRIBITE (DPLI_POB_ATR), the CPU 10 when the operation S608 shall increment the variable "I" (#u←#u+1), and when performing the operation S609 - variable "x" (#x←#x+1).

In that case, when the operation S605 was selected ISWF (PLI), processing passes to operation S610, in which the UE OBI, IVF No. vy (PLI__SRP#vy) from IVF No. (PLI#y) set the OBI No. x (PIT#x), and the operation S611, in which the set value TRIOBET No. vy (PLI_POB_ATR#vy) for this ISWF (PLI) on the basis of the OBI No. x (PIT#x). Then, before you go for an operation S609, which increments the variable #x (#x←#x+1), perform an operation S612, in which the CPU 10 performs the increment variable "vy" (#vy←#vy+1).

In that case, if the operation S603, the user decides that the OBI No. x (POB#x) must be assigned to a particular phonogram, the treatment procedure is transferred to the operation S613, when the CPU 10 receives the user's directions in regards to this specific tags. Then, when the operation S614, the CPU 10 sets the OBI No. x (POB#x) in OPIOID No. w (TKI_POB_SRP#w)whose values are set for IDF No. z (TKI#z) of the said phonograms (phonograms # z) (track#z).

Then processing passes to operation S615, at which the CPU 10 on the basis of the OBI No. x (PIT#x) sets the value of TRIOBET No. w (TKI_POB_ATR#w) IDF No. z (TKI#z), for operation S616, at which the CPU 10 performs the increment of the variable w (#w←#w+1), and the operation S617, at which the CPU 10 decides as to whether the variable "x" last number # n (#n) in the OBI (the MOAT). If this is not the case, processing passes to operation S609, in which the CPU 10 performs the increment of the variable "x". If the value of the variable "x" has reached the last number # n (#n) in the OBI (the DITCH), then processing is transferred to the operation S618, when in charge of a semiconductor memory write OBI # 1 to # n (POB#1-POB#n), ADFG (TKMG), which contains IDF (TKIs), and ADSVR (PLMG), which contains SWFU (DPLI), IVF (PLI), and this completes the processing.

In these embodiments of the invention there is the possibility to display on the screen as a background image, the same data of a still image, in the example, a photograph of the artist or the logo of the record company, while playing a variety of phonograms. This is achieved simply by setting the data of a still image corresponding to these phonograms OPHIOLITE (DPLI_POB_SRPs) or OPIOIF (PLI_POB_SRPs) in Informatsiejobrashchatsja (Default_Playlist_Information) or in ISWF (PLI).

The data of a still image, for example, a page with the lyrics, the output of which is on the screen together with the background image should only be performed during playback of a particular phonogram, may be specified by OPIOID (TKI_POB_SRP) in the IDF (TKI) tags.

The focus in the above explanation focuses on the version that is believed at the present time, is an ideal system for the realization of the idea of the present invention, although it is obvious that within the scope of the patent claims of the present invention may be made several changes. Below are three examples of such modifications, marked (a), (b) and (C).

(a) the Procedures which explanation is made using a flow chart of operations Fig, Fig, Fig and Fig can be implemented through programs, distribution and sale which can be implemented in recorded on the recording media.

(b) In the who's here variants perform the described case, in which reproducible data and navigation data used for musical content, although it should be obvious that such data can be used for the sounding of the book, which is a recording of the reading of the book the actor or speaker. The best option for this case can serve as one in which the quality of the images located in the foreground, through OPIOID (TKI_POB_SRPs) set the data of a still image that represents the book's text and illustrations from the book are specified by OPHIOLITE (DPLI_POB_SRPs) or OPIOIF (PLI_POB_SRPs).

(C) Although in this second embodiment of the invention as background images using the OBI (POBs), which is indicated by OPHIOLITE (DPLI_POB_SRPs) and OPIOIF (PLI_POB_SRPs), and as images are located in the foreground, use the OBI (POBs), which is indicated by OPIOID (TKI__SRPs), may be used or reverse configuration. Alternatively, in the case when, through UPOV (DPLI_POB_SRP) or OPIOIF (PLI_POB_SRP) and OPIOID (TKI_POB_SRP) simultaneously set to different OBI (POBs), the screen can only be displayed one of those OBI (POBs). Another alternative is one in which there is no need to enter any differences m is waiting for "background image" and "image, located in the foreground". One example of this is the one that first can be displayed on the screen of the OBI (ROS), indicated by OPHIOLITE (DPLI_POB_SRP) or OPIOIF (PLI_POB_SRP), and then can be displayed on the screen of the OBI (ROS), indicated by OPIOID (TKI_POB_SRP).

The THIRD VARIANT embodiment of the INVENTION

While in the second embodiment described a case in which the display screen of each of the OBI (the MOAT) perform with the same duration in the period IDF (TKI), IVF (PLI), in this third embodiment describes the case where in the circuit Board 31 flash memory memorizes a table of the distribution of phrases in time and the table is allocated to the screen coordinates, which allows to properly synchronize the output on screen lyrics with the song.

Table distribution of phrases in time ensures consistency between OPIOID (TKI_POB_SRPs), through which set the OBI (POBs), representing each of the fragments of the lyrics, and information indicating the start time and end time of the corresponding phrase in the song. On Figa shows one example of a table of the distribution of phrases in time. In this example, the distribution of phrases in time" refers to the period of time during which p is for the phrase, found in the lyrics of the phonogram and represents a fragment of the play GOITER (AOW). This period of time set with precision up to milliseconds. In addition to updating the time code playback as described in the first embodiment, the playback device additionally performs control over the distribution of phrases at a time specified in the table that corresponds to the current value of the time code playback. Through such control of the distribution of phrases in time to the playback device may be known, in which the OBI (ROS) memorized the words to the song for those GOITER (AOW), Elementat (AOB_ELEMENT) and Quadrat (AOB_FRAME)whose playback is carried out in real time. The use of such tables, in which you set the sync phrase OBI (ROS) in milliseconds, allows the playback device to synchronize the playback GOITER (AOW) and display on screen lyrics with millisecond accuracy.

In that case, when the user specifies the desired time to start playback using a rotary disk with step switch as described in the first embodiment of the invention, the playback device using the equations from Equation 1 to Equation 3 described in the first embodiment, may N. is come, what KATZO (AOB_FRAME) in which Elementat (AOB_ELEMENT) a GOITER (AOW) corresponds to the specified start time of playback. The playback device can also decide that the time interval which phrase contains the specified playback start time, and displays the OBI (ROS), which corresponds to the time of this phrase. This means that in the case when the user starts playback from the desired location, which is specified by means of the swivel drive with manual switching, the screen can also be displayed and OBI (ROS)corresponding to this desired place. It should be noted that although in this embodiment, it is indicated that the table of distribution of phrases in time set time values, instead of them in the table of distribution of phrases in time can be specified room GOITER (AOW), the number Elementat (AOB_ELEMENT) and number Quadrat (AOB_FRAME) GOITER (AOW), Elementat (AOB_ELEMENT) and Quadrat (AOB_FRAME), which must be synchronized phrase.

On the other hand, the table is allocated to the screen coordinates provides the correspondence between the coordinates displayed on the screen of the letters used for the song and the moment in time at which carry out the playback Elementat (AOB_ELEMENT) and Kudrovo (AOB_FRAMEs)corresponding to these characters. On Figb pok is Zan is one of the examples of tables allocated to the screen coordinates. The compilation of such a table is allocated to the screen coordinates allows the playback device to display on the screen in a different color letters corresponding to the words of the song being played at the moment Elementat (AOB_ELEMENT) and Cadres (_FRAME), of the words of the song, which are displayed on the screen in accordance with the distribution of phrases in time.

As one of the examples can be shown that where the text of the song contains the phrase "Hey Hey boy don't take it slow", and the table is allocated to the screen coordinate contains the coordinates displayed on the screen for the letters "N", "e", "y", "h", "e", "u", ..., which are associated with the duration of the playback Elementat (AOB_ELEMENT) and Quadrat (AOB_FRAME)corresponding to these characters. When playing GOITER (AOW) the playback device changes the color at that location, which is specified by the coordinates displayed on the screen for letters specified in the table allocated to the screen coordinates.

Therefore, the playback device can display the lyrics in a way that allows the user to instantly recognize sounds in the moment part GOITER (AOW). This means that the playback of recorded in the Board flash music can be made with the selection of the words of the songs are exactly the same as when playing normal phonogra the m karaoke.

In this third embodiment of the invention a table of the distribution of phrases in time and the table is allocated to the screen coordinates of create to enable accurate synchronization between the reproduction of the audio data and displaying on screen lyrics, the same as in the usual karaoke soundtracks. Although the description of the present invention was made 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 as falling under it.

INDUSTRIAL APPLICABILITY

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 exploit the potential of this card is a semiconductor memory.

1. Fee semiconductor memory containing protected areas is th the access may be via a playback device connected with the said card, a semiconductor memory, only if you have installed the authenticity of the said device, and an unprotected area, access to which may be implemented by any playback device connected to the card, a semiconductor memory, and the fee semiconductor memory stores the audio sequence containing many sound objects, many objects representing a still image, at least one piece of information about the route playback, indicating the order in which to make the reproduction of sound objects from a multitude of audio objects in the audio sequence, at least one piece of information about the first pointer, each of which corresponds to a piece of information about the route playback and through which specify at least one object representing a still image which should be displayed during the playback of sound objects in the order specified by the respective pieces of information about the route playback, and at least one piece of information about the second pointer, each of which corresponds to the sound is the first object in the audio sequence, and whereby specified, at least one object representing a still image which should be displayed during playback corresponds only to the sound object.

2. Fee semiconductor memory according to claim 1, in which at least one audio object represents the musical information, and the set of objects representing a still image contains at least one object representing a still image, which shows the lyrics displayed by the musical information in the audio object, and at least one piece of information about the second pointer identifies each object representing a still image showing the words to the song, represented by music information in the audio object that corresponds to the fragment information of the second pointer.

3. Fee semiconductor memory according to claim 1, which additionally stores a set of counters characters, each of which corresponds to the object that represents a still image, and indicates whether this object represents a still image, by any of the at least one piece of information about the first pointer and at least one piece of information about the second pointer, and the EU and it is it shows how many pieces of information about the first pointer information and the second index set object representing a still image.

4. Fee semiconductor memory according to claim 1, in which a set of objects representing a still image contains at least one encrypted object representing a still image, and the fee semiconductor memory also stores control information containing the ID information for each object representing a still image, the additional information indicating whether each of the encrypted objects representing a still image, and the memory location of each object representing a still image, and at least one decryption key used for decrypting the at least one encrypted object representing a still image, and the device is connected to the plate of semiconductor memory accesses, at least one decryption key only if you have installed the authenticity of the device, the pieces of information of the first index information and the second pointer through which the set is fixed and what the considerations applying using the information about the ID, which is specified in the control information.

5. Fee semiconductor memory according to claim 4, storing at least one decryption key in a secure area, an audio sequence, a set of objects representing a still image, each piece of information about the route of the play, every piece of information about the first pointer, every piece of information about the second pointer and the control information in an unsecured area, and at least one encrypted object representing a still image, which has been encrypted using at least one decryption key in a protected area.

6. Fee semiconductor memory according to claim 5, in which the encrypted are at least two object representing a still image from a set of objects representing a still image in a secure area in a predetermined order are stored, at least two of the decryption key in a sequence of decryption keys, and the ID information for each encrypted object representing a still image contains the key number that specifies the position of the decryption key in the sequence of decryption keys, the cat is which corresponds to the encrypted object, representing a still image.

7. The playback device Board for a semiconductor memory that stores (1) a sound sequence that contains many sound objects, (2) a set of objects representing a still image, (3) information about the first pointer through which it is set, at least one object representing a still image which should be displayed during playback of many audio features from the audio sequence, and (4) at least one piece of information about the second pointer through each of which is specified, at least one object representing a still image, which should only be displayed during playback of a particular audio object from the audio sequence, and referred to the playback device includes a tool to play back sounds from the sound sequence one by one in a predetermined order, means visual, performing displaying at least one object representing a still image, which is determined by the details of the first pointer, during the playback of sound objects from sound sequences, and management tool, ensure the display it means the visual display, at least one object representing a still image, which is defined by a slice of information about the second pointer when the playback of a particular audio object corresponding to a fragment of information about the second pointer.

8. The playback device according to claim 7, in which the management tool provides a mapping tool to visually display the combined image generated by combining at least one object representing a still image of a particular piece of information about the second pointer, with at least one object representing a still image, certain information about the first pointer.

9. The recording device Board for a semiconductor memory that stores a set of objects representing a still image, and audio sequence containing many sound objects, and the above-mentioned recording device includes a tool assignment that assigns the audio sequence, at least one object representing a still image that should be displayed during playback of multiple audio objects, and assign a specific sound to the object, at least one object representing a bit of vignae image which should be displayed during playback of a particular audio object, and a recorder, for recording in the cost of semiconductor memory: (1) information on the first pointer indicating at least one object representing a still image, which is assigned to the audio sequence, and (2) the information about the second pointer indicating at least one object representing a still image, which is assigned to a particular sound object.

10. Read through a computer storage medium that stores a program for execution by a computer procedures playback card semiconductor memory, and the fee semiconductor memory stores: (1) tone sequence that contains many sound objects, (2) a set of objects representing a still image, (3) information about the first pointer through which it is set, at least one object representing a still image which should be displayed during playback of many audio features from the audio sequence, and (4) at least one piece of information about the second pointer by each of which is specified, at least one object representing a still image, which is it should only be displayed during playback of a particular audio object from the sound sequence, in fact the program that contains the following operations: a playback operation, at which playback of audio features from the audio sequence one by one in the given order, the operation of the visual display, which display at least one object representing a still image, which is determined by the details of the first pointer, when the playback of the audio objects from the audio sequence, and the operation control that provides a visual display of at least one object representing a still image of a particular piece of information about the second pointer when the playback of a particular audio object corresponding to a piece of information about the second pointer.

11. Read through the computer storage medium of claim 10, in which the operation control provides a visual display of the combined image generated by combining at least one object representing a still image of a particular piece of information about the second pointer, with at least one object representing a still image, certain information about the first pointer.

12. Read by the computer is the eh information storing the program, ensure the implementation of computer procedures account for payment of the semiconductor memory, and the fee semiconductor memory stores a set of objects representing a still image, and audio sequence containing many sound objects, while this program contains the following operations: operation assignment, which assignment of a sound sequence, at least one object representing a still image that should be displayed during playback of multiple audio objects, and assign a specific sound to the object, at least one object representing a still image that should be displayed when the playback of a particular audio object, and a write operation, which are recorded in cost of the semiconductor memory (1) information on the first pointer indicating at least one object representing a still image, which is assigned to the audio sequence, and (2) the information about the second pointer indicating at least one object representing a still image, which is assigned to a particular sound object.

13. How to play for vosproizvedeniya of the Board, a semiconductor memory, storing (1) a sound sequence that contains many sound objects, (2) a set of objects representing a still image, (3) information about the first pointer through which it is set, at least one object representing a still image which should be displayed during playback of many audio features from the audio sequence, and (4)at least one piece of information about the second pointer through each of which is specified, at least one object representing a still image that should be displayed only when the playback of a particular audio object from the audio sequence, and the above-mentioned method of play includes the following operations: a playback operation, at which playback of audio features from the audio sequence one by one in the given order, the operation of the visual display, which is displayed on the screen, at least one object representing a still image, which is determined by the details of the first pointer, when the playback of the audio objects from the audio sequence, and the operation control that provides with the operation of the visual display, at least, one of the second object, representing a still image, which is defined by a slice of information about the second pointer when the playback of a particular audio object corresponding to a fragment of information about the second pointer.

14. How to play in item 13, in which the management operation provides for the operation of the visual display of the combined image generated by combining at least one object representing a still image of a particular piece of information about the second pointer, with at least one object representing a still image, certain information about the first pointer.

15. The method accounts for payment semiconductor memory that stores a set of objects representing a still image, and audio sequence containing many sound objects, and the above-mentioned recording method includes the following operations: operation assignment, which assignment of a sound sequence, at least one object representing a still image that should be displayed during playback of multiple audio objects, and assign a specific sound to the object, at least one object representing a still image, to which that should be displayed during playback of a particular audio object, and write operation, which are recorded in cost of the semiconductor memory (1) information on the first pointer indicating at least one object representing a still image, which is assigned to the audio sequence, and (2) the information about the second pointer indicating at least one object representing a still image, which is assigned to a particular sound object.



 

Same patents:

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

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

FIELD: computer science.

SUBSTANCE: method includes affecting carrier with heat flow and changing of its physical-chemical and molecular properties and following reading of applied encoded information. During recording data carrier is affected with modulated heat flow, and during reproduction data carrier is electrified and portions with different surface density of applied charge are detected, which density depends on type of modulating signal. Electrization can be performed using corona charge for whole data carrier once prior to reading. As data carrier polymer films can be used, in particular, made of polyamide.

EFFECT: higher efficiency.

6 cl, 3 dwg

FIELD: computer science.

SUBSTANCE: method includes affecting carrier with heat flow and changing of its physical-chemical and molecular properties and following reading of applied encoded information. During recording data carrier is affected with modulated heat flow, and during reproduction data carrier is electrified and portions with different surface density of applied charge are detected, which density depends on type of modulating signal. Electrization can be performed using corona charge for whole data carrier once prior to reading. As data carrier polymer films can be used, in particular, made of polyamide.

EFFECT: higher efficiency.

6 cl, 3 dwg

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 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

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!