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

Abstract

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

Description

FIELD OF THE INVENTION

The present invention relates to a semiconductor memory board in which sound data, still image data and control data are stored, and to a reproducing device, a recording device, a reproducing method, a recording method, and a recording medium having the capability of recording a semiconductor memory board reading by computer. In particular, the present invention relates to improved storing of audio data, image data, and control data distributed as information content by an information distribution service, such as an electronic music distribution service.

BACKGROUND

Electronic distribution of music provides users with the ability to buy and receive music information (such as songs and albums) via the Internet. In the future, such technology can greatly change the market for music recordings and gradually becomes available as the necessary infrastructure is introduced. One of the ways to store musical information received from the electronic music distribution service is to store it in semiconductor memory cards, which, due to their portability, are an ideal means for this. Therefore, it is believed that the demand for such boards will increase significantly.

Musical information may contain not only sound data. One example is "multimedia" audio information, which may include related images intended to be displayed when playing music. Such multimedia sound information can be used for "karaoke programs", which consist of an accompanying soundtrack and images that serve to display the words of songs and background. It is believed that the distribution of such multimedia sound information content will also be carried out by means of electronic music distribution, therefore, it is necessary to consider how to store such information content in a semiconductor memory board.

The following is a description of how multimedia music information is stored in a recording medium, for example, in a CD (CD), that is, a generally accepted method for storing audio data and image data in a recording medium.

In order for the playback device to be able to play music and render images, the recording of the usual multimedia music content on the recording medium is carried out in the form of multiplexed data created by multiplexing the music audio data with image data for displaying song words and / or background images. When reproducing multiplexed data, image data can be displayed simultaneously with the reproduction of audio data.

One example of a medium that allows image data to be displayed on a screen during reproduction of audio data by multiplexing these data among themselves is a CD-Graphics disc. When creating a CD of a disk with graphic data, data multiplexing is performed element by element, each of which consists of 16-bit main codes and subcodes. Sound data is set by means of 16-bit base codes, and image data containing song words, background images, and the like are set by means of subcodes. When you start playing any music content recorded on a CD with graphics data (CD-Graphics disc), sequential playback of audio data is assigned to which 16-bit basic codes are assigned, while simultaneously performing sequential display of image data that is assigned subcodes.

With this multiplexing of audio and image data among themselves, it becomes necessary to create separate images for each piece of music from a music album. This means that with this conventional multiplexing method, the disc manufacturer would have had to deal with the difficulty of creating at least one image for each component of the musical content.

It is believed that fans of the records of famous artists will positively appreciate the presence of different images for each song (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 rely on a large sales volume of their works, even if different images are created for each song, so the cost of creating such material cannot be covered by sales.

Thus, the money and labor spent on creating images will give a different commercial result, which largely depends on the popularity of the artist. However, in regular discs, at least one image must be associated with each component of the musical content, regardless of the popularity of the artist being recorded or the expected sales volume. As a result, manufacturers express dissatisfaction with conventional carriers.

SUMMARY OF THE INVENTION

The aim of the present invention is to provide a semiconductor memory board, through which it is possible to reduce the necessary amount of labor when creating images for many components of the audio content that make up the album.

If images are displayed on the screen during playback of audio content, images representing the words of a song should be displayed on the screen only during the corresponding song. However, the same background images can be used when playing any number of songs. As one example, we can consider the case in which the same person is the author of the songs or the performer, then the same image of the songwriter or artist can be used as a background image for several songs. It is believed that for disk manufacturers, this will facilitate the joint storage of music information (sound objects) and image data (objects representing images).

In a preferred embodiment, the sharing of image data (objects representing still images) by a plurality of audio objects can be carried out by means of a semiconductor memory board, in which are stored: an audio sequence containing a plurality of audio objects; many objects that are still images; at least one piece of information about the playback route, indicating the order in which you want to play sound objects from many sound objects in an audio sequence; at least one piece of information about the first pointer, each of which corresponds to a piece of information about the playback route and by means of which at least one object is set, which is a still image, which should be displayed on the screen when playing audio objects in order, indicated by the corresponding piece of information about the playback route; and at least one piece of information about the second index, each of which corresponds to a sound object in an audio sequence and by means of which at least one object is set, which is a still image, which should be displayed on the screen when playing only the corresponding sound object.

Reproduction of a plurality of sound objects from the audio sequence is carried out in accordance with the playback order that is specified in the piece of information about the playback path. By the information about the first pointer, which corresponds to the information about the playback route, indicate those objects that are still images that should be displayed on the screen as background images when playing audio objects. As a result, display of shared objects representing still images on the screen can be carried out during the reproduction time of a plurality of audio objects contained in an audio sequence.

Since the same images can be used for multiple phonograms, when reproducing multiple audio objects from a sound sequence that corresponds to an album of a secondary artist in popularity, the same image or images can be displayed on the screen. This reduces the amount of labor involved in creating images for such an album and its cost.

Conversely, when playing each sound object from a sound sequence that corresponds to an album of a popular artist, it may be possible to display many different images on the screen. Displaying several different images for each phonogram makes the album more attractive to consumers, which, therefore, can lead to an increase in sales.

In the presence of objects that are still images, for example, words of songs that should be displayed on the screen separately from background images only when playing a specific phonogram, such objects that are still images can be specified using information about the second pointer, whereby objects that are still images are assigned only to a particular phonogram.

At the same time, a plurality of symbol counters can be additionally stored in the semiconductor memory board, each of which corresponds to an object representing a still image, and indicates whether this object representing a still image is set by means of at least one fragment information about the first pointer and at least one piece of information about the second pointer, and if so, in how many pieces of information about the first pointer and information about the second pointer is an object representing a still image.

When deleting sound objects and sound sequences, the recording device for the semiconductor memory board sets the second pointer information for remote sound objects and sound sequences and the first pointer information for any remote sound sequence. Then, the recording device performs a negative increment of numbers assigned to objects representing a still image, which indicate how many pieces of information about the first pointer and information about the second pointer indicate each object. In the case when the number assigned to any object representing a still image reaches zero, the recording device assumes that the object representing a still image is not indicated in any of the pieces of information about the first pointer or information about the second pointer, and therefore removes the object, which is a still image. By such removal of unused objects, which are still images, more efficient use of the memory capacity of the semiconductor memory board can be made.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other objectives, advantages and features of the invention will become apparent from the description below with reference to the accompanying drawings, in which a specific embodiment of the invention is shown. In the drawings:

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

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

Figure 3 - hierarchical structure of the card 31 flash memory in the variants of implementation;

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

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

5 is a detailed file system level structure;

6 is a variant in which the sound object (AOB) file "AOB001.SA1" is divided into five parts, which are stored in clusters 003, 004, 005, 00A and 00C;

Fig. 7 is one example of specifying directory elements and a file allocation table when a sound object (AOB) file "AOB001.SA1" is recorded in a plurality of clusters;

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

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

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

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

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

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

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

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

Fig. 14 shows the correspondence between the sampling frequency and the number of GOITERS (AOB_FRAMES) contained in the GOITER (AOB_ELEMENT);

Fig - examples of the duration of the playback of ITEMS_THE (AOB_ELEMENTS) and the duration of the playback FRAME_THE (AOB_FRAMES);

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

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

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

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

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

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

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

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

Fig - clusters from 007 to 00E, in which the memory was recorded GOITER (AOW), consisting of ELEMENT_ GOITER from the 1st ELEMENT_ GOITER (AOB_ELEMENT # 1) to the 4th ELEMENT_ GOITER (AOB_ELEMENT # 4);

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

Figa and Figb - definition of GOITER (AOW), ELEMENT GOITER (AOB_ELEMENT), and FRAME (AOB_FRAME), which correspond to an arbitrary value of the code playback time;

Figa and Figb - operation to erase the phonogram;

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

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

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

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

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

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

Fig.31B - the combination of multiple phonograms into one phonogram for a set of goiter (AOB) of the 1st type + 2nd type + 2nd type + 2nd type + 1st type (Type1 + Ture2 + Ture2 + Ture2 + Type1 );

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

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

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

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

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

Figa and Fig.33B - the separation of the phonogram to create two phonograms;

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

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

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

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

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

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

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

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

Fig - the relationship between Information_list_playable_files (Default_Playlist_Information), IDF (TKI), and goiter files (AOW files);

Fig. 41 is an example of setting values for the Default_Playlist and several ISVFs (information about the list of reproducible files) (PLIs);

Fig. 42 - correspondence of UP_FG_SVFU (phonogram search indexes from the list of playable files by default) (DPL_TK_SRP), IDF (TKI), the same notation being used as in FIG. 40;

Figa and Fig 43B - the implementation of a change in the sequence of phonograms;

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

Figa and Fig.45B - recording new IDF (TKI) and UP_FG_SVFU (DPL_TK_SRP) in the case when there are "unused" IDF (TKI) and UP_FG_SVFU (DPL_TK_SRP);

Figa and Figb - implementation of the combination of phonograms;

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

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

Fig. 49 is one example of an image that is displayed on a liquid crystal panel when a list of playable files is selected;

Figa - Figa - examples of images that are displayed on the liquid crystal panel when selecting a phonogram;

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

Fig - internal structure of the playback device;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Fig - composition of the hardware recording device;

Fig. 68 is a flowchart showing processing during recording;

FIG. 69 is an illustration of an internal structure of a flash memory card according to a second embodiment of the present invention; FIG.

Figa and Figb - the internal structure of the user data area and the protected area at the file system level;

Figa - internal structure of the file "ROVXXX.JPG";

Fig. 71B is the internal structure of the OBI file (object representing an image) (DOM file), which contains encrypted data about a still image;

Fig. 71B is an example of an OBI file (DOM file) in which, instead of an encrypted data volume, a file access path is stored;

Fig - detailed structure of the administrator of the list of playable files (PlaylistManager) and the administrator of the phonograms (TrackManager) of the second embodiment;

Fig - implementation of the job files IOB (DOM), shown in Fig.70, UP_IOB_IDF (search pointers for objects representing images in phonogram information data) (TKI_POB_SRPs), UP_IOB_ISVF (search pointers for objects representing images in information about the list of playable files) (PLI_POB_SRPs), and UP_IOB_ISVFU (search pointers for objects representing images in the information about the list of playable files by default) (DPLI_POB_SRPs);

Fig - data structure ATR_OBI_IDF (attributes of the object representing the image in the information about the phonogram) (TKI_POB_ATR) and UP_IOB_IDF (TKI_ROV_ SRP);

Fig. 75 is an example of setting UP_IOB_IDF (TKI_POB_TKIs) parameters for IDF No. 1 through No. 3 (TKI # 1-TKI # 3) in the phonogram manager (TrackManager);

Fig. 76 is an example of setting UP_IOB_IDF (TKI_POB_TKIs) parameters for IDF No. 4 through No. 8 (TKI # 4-TKI # 8) in the phonogram manager (TrackManager);

Fig - UP_IOB_ISVFU (DPLI_POB_SRPs) and ATR_IOB_ISVFU (attributes of objects representing images in the information about the list of playable files by default) (DPLI_POB_ATR) contained in OISVFU (DPLGI);

Fig. 78 is an example of setting the parameters of twenty UP_IOB_ISVFU (DPLI_POB_SRPs) contained in the Information_of the list of reproducible_files of the default_ (Default_Playlist_Information);

Fig. 79 is a timing chart showing a method for generating an aggregate image in the case where the OBI (DOM) indicated by the UP_ISOBFU (DPLI_POB_SRP) contained in the default image_playlist information (Default_Playlist_Information) is used as the background image, and in the foreground, use the OBI (DOM) specified by UP_IOB_IDF (TKI_POB_SRP) contained in the phonogram manager (TrackManager);

Fig. 80 shows a combination of a background image and an image located in the foreground at a point six minutes after the start of playback according to Default_Playlist_Information information on the list of playable files;

Fig - the implementation of combining the background image and the image located in the foreground, at a point located sixteen minutes after the start of playback according to the Information_of the list of reproducible_files_of the default (Default_Playlist_Information);

Fig - UP_IOB_ISVF (PLI_POB_SRPs) and ATR_IOB_ISVF (attributes of objects representing images in the information on the list of playable files) (PLI_ROV_PLI), which are contained in OISVF (general information about the list of playable files) (PLGI);

Fig - an example of setting the parameters of twenty UP_IOB_ISVF (PLI_POB_SRPs) contained in the ISWF (PLI);

Fig. 84 is a timing chart showing a method for generating an aggregate image when using the OBI indicated by the UPI_ISVF (PLI_POB_SRP) contained in the ISVF (PLI) as the background image, and as the image located on in the foreground, use the OBI (DOM) specified by UP_IOB_IDF (TKI_POB_SRP) contained in the phonogram manager (TrackManager);

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

Fig - combining the background image and the image located in the foreground, at a point located sixteen minutes after the start of playback according to the ISVF (PLI);

Fig. 87 is an example in which the number of OBI files (DOM files) is reduced when there are several Default_Playlist_Information (DPLI_POB_SRPs) in the Information_op_list_of reproducible_files (Default) to indicate the same OBD files (DOM files);

Fig. 88 is a timing chart showing a method for generating an aggregate image when using the OBI indicated by the UP_ISOBFU (DPLI_POB_SRP) contained in the default image_playlist information (Default_Playlist_Information) as the background image, and in the foreground, use the OBI (DOM) indicated by UP_IOB_IDF (TKI_POB_SRP) contained in the phonogram manager (TrackManager);

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

Fig - use of the playback device from the second variant implementation;

Fig - external view of the playback device from the second embodiment;

Fig - internal structure of the playback device of the second embodiment;

Figa - the implementation of the imposition of one on top of the still images stored in a variety of RAM 61 for video images (VRAMs);

Figb - the implementation of the imposition of one on top of the still images stored in a variety of RAM 61 for video images (VRAMs);

Fig. 94 is a flowchart showing a procedure for displaying an image located in the foreground;

Fig. 95 is a flowchart showing a procedure for displaying a background image;

Fig. 96 is a flowchart showing a procedure for displaying a background image;

Figa - Fig.97B is an aggregate image that will be displayed on the screen of the LCD panel 5 during processing according to the flowcharts of Fig.94 and Fig.95, in which as the image located in the foreground, the OBI is displayed on the screen (DOM) indicated by UP_IOB_IDF (TKI_POB_SRP), and as a background image the OBI (DOM) indicated by UP_IOB_ISVFU (DPLI_POB_SRP) is displayed;

Figa - Fig.98B is an aggregate image that will be displayed on the LCD panel 5 during processing according to the flowcharts of Fig and Fig, in which as the image located in the foreground, the OBI is displayed on the screen (DOM) indicated by UP_IOB_IDF (TKI_POB_SRP), and as a background image, an IOB (DOM) indicated by UP_IOB_IDP (PLI_POB_SRP) is displayed;

99 is a flowchart showing a procedure that is used in the recording apparatus of the second embodiment;

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

100B is an example of a table of coordinates allocated on a screen.

BEST MODE FOR CARRYING OUT THE INVENTION

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

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

{x1-x2_x3-x4}

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

FIRST OPTION FOR CARRYING OUT THE INVENTION

{1-1_2} Appearance of the flash card 31

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

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

{3-1} Physical structure of flash card 31

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

{3-2} Physical layer 31 flash memory card

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

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

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

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

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

{3-2_4A-2} Using three areas in the physical layer

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

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

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

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

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

{3-2_4B-2} Partition boot sectors

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

{3-2_4B-3_5} Data Area

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

This completes the description of KADRA_ZOB (AOB_FRAME).

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

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

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

{3-3_10-5_14} The number of GOALS (AOB_FRAMEs) in the GOITER (AOB_ELEMENT)

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

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

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

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

On Fig shows one example of the duration of the playback ELEMENTS_CHAW (AOB_ELEMENTS) and FRAMES_CHAW (AOW_FRAMEs). On Fig at the first level shows a lot of BLOCKS_ goiter (AOB_BLOCKs), and at the second level shows a lot of ELEMENTS_ goitre (AOB_ELEMENTs). The third level shows a lot of FRAMES_THEAD (AOB_FRAMEs).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

{3-3_10-10_16}

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

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

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

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

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

{3-3_8A, B-2}

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

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

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

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

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

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

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

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

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

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

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

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

On Fig shows how the IDF (TKI) shown in Fig correspond to the files GOITER (AOW files) and GOITER (AOW), which are shown in Fig.16. In Fig. 19, the rectangles on the first level indicate the sequence of phonograms, which consists of phonograms from Phonogram A to Phonogram D (TrackA - TrackE), the large frame on the second level indicates the phonogram administrator (TrackManager), and on the third and fourth levels those eight files are shown GOITER (AOW files), which are shown in Fig.16. These eight GOITER files (AOW files) are recorded in eight GOITER (AOW) shown in Fig. 16, and they form a music album containing phonograms: "Phonogram A" (TrackA), "Phonogram B" (TrackB), " Phonogram B "(TrackC)," Phonogram G "(TrackD), and" Phonogram D "(TrackE). The second level shows eight IDFs (TKI). The numbers "1", "2", "3", "4" assigned by each IDF (TKI) are serial numbers that are used to identify each IDF (TKI), and each IDF (TKI) corresponds to that file GOITER ( AOW file), which is assigned the same serial number 001, 002, 003, 004, 005 ....

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

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

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

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

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

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

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

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

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

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

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

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

{17-3_21-2} How to read TPFGPVR (TKTMSRT)

Thus, in the time search table, a record of the volumes of data of GOALS (AOB_ELEMENTs) was recorded. However, since the data length of each GOITER (AOB_BLOCK) is limited to a maximum value of 8.4 minutes, the total number of GOITER ELEMENTS (AOB_ELEMENTs) contained in one GOITER (AOB) is limited to a predetermined number (“252”, as shown in FIG. 20) or less of it. Since the number of GOITER ELEMENTS (AOB_ELEMENTS) is limited, the number of GOITER_TEMP Elements (TMSRT_entries) corresponding to GOITER_ELEMENTS ELEMENTS (AOB_ELEMENTS) is also limited, which limits the amount of TPFGVR (TKTMSRT) containing these TPMSTent_Res (TMSR_set) in advance. Since the scope of TPSFMR (TKTMSRT) is limited, the playback device can read and use IDFs (TKIs) as follows.

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

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

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

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

Equation 1

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

Shift v = ((The total number of Elements_TPPVR from ELEMENT_ GOITER No. 1 to ELEMENT_ GOITER No. (y-1) mod Cluster size

(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" is the residue obtained by dividing "a" by "b".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

In the field "PR_VP_IDF" (TKI_РВ_ТМ) IDF (TKI) record the duration of the playback of a phonogram (song) consisting of GOITER (AOW) recorded in the corresponding IDF (TKI) file GOITER (AOV file).

When a phonogram consists of a set of IDFs (TKI), in PR_VP_IDF (TKI_РВ_ТМ) of the first IDFs (TKI) corresponding to the phonogram, the full duration of the phonogram is recorded, and the duration of the corresponding GOITER (AOW) is recorded in the second and subsequent IDF (TKI) phonograms.

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

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

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

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

The sampling frequency that was used when encoding GOITER (AOW) is recorded in a field of four bits between bit b7 and bit b4. When the sampling frequency is 48 kHz, the value "0000b" is written in this field. When the sampling frequency is 44.1 kHz, then this value is “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 sampling frequency is 22 , 05 kHz, this value is “0100b”, and when the sampling frequency is 16 kHz, this value is “0101b”.

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

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

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

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

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

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

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

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

As shown in FIG. 23A, a TIB (BIT) consists of a DATA_DIFFERENT (DATA_OFFSET) field, which occupies an area from 60th byte to 63rd byte, an OBDATA (“data volume”) field (SZ_DATA), which occupies an area of 64 -th byte by 67th byte, field KOL_ETPPVR ("the number of elements in the time search table (TPRVR)") (TMSRTE_NS), which occupies the area from 68th byte to 71th byte, field KOLK_1go_ETPPVR ("number of frames in to the first LCCI element ") (FNs_1st_TMSRTE), which occupies the area from the 72nd byte to the 73rd byte, the field KOLK_Last_ETPVR (" the number of frames in the last LCCI element ") (FNs_Last_TMSRTE), which animates the area from 74th byte to 75th byte, the field QTY_Medium_ETPVR ("the number of frames in the middle elements of the CCTV") (FNs_Middle_TMSRTE), which occupies the area from 76th byte to the 77th byte, and the field CONTINUOUS_TIME ("duration by time ") (TIME_LENGTH), which occupies the area from the 78th byte to the 79th byte.

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

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

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

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

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

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

In the field "COLL_ETPVR" (TMSRTE_Ns) write the total number of Elements_CAT_VR (TMSRT_Entries) contained in the BLOCK_ZOB (AOB_BLOCK).

{17-5_22-12_23A-5} "KOLK_1go_ETPPVR" (FNs_1_st_TMSRTE), "KOLK_Sost_ETPPVR" (FNs_Last_TMSRTE), "KOLK_Medium_ETPPVR" (FNs_Middle_TMSTE)

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

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

In the field "FIRS_Medium_ETPVR" (FNs_Middle_TMSRTE) write the number of GOITERS (AOB_FRAMEs) contained in each GOITER (AOB_ELEMENT), with the exception of the BLOCK_OBID (AOBOELOB, AOBENT_ELECTOR (i.e. AOB_ELENT, i.e. in the middle of AOB_BLOCK.

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

{17-5_22-13_23B}

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

The relationship between the sampling rate and the number of frames contained in the GOITER (AOB_ELEMENT) shown in Fig.23B is the same as that shown in Fig.14, namely, the number of frames in the GOITER (AOB_ELEMENT) depends on the sampling frequency used. The number of frames recorded in "KOLK_1go_ETPPVR" (FNs_1st_TMSRTE) and in "KOLK_Post_ETPPVR" (FNs_Last_TMSRTE) will be essentially equal to their number recorded in "KOLK_MED_ETPPVR" (however, ATTENT_ELIMENT and / or at the end of BLOCK_CRAFT (AOB_BLOCK) there is a section of invalid data, then the values specified in "KOLK_1go_ETPPVR" (FNs_1st_TMSRTE) and / or in KOLK_Post_ETPPPVR (FNs_Last_TMSRTE) "differ from the value of ТДЛТНТР_ТП_ТТРТТР_ТЛТНТЛ_ТЛТНТН_ТЛ_ТПЛТЛТЛ_ТПЛТЛ_ТЛ.

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

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

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

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

In Fig.24, ITEM_ GOITER # 1 (AOB_ELEMENT # 1) occupies the region from md0 in cluster 007 to md1 in cluster 008.

This GOITER ITEM # 1 (AOB_ELEMENT # 1) does not occupy the entire cluster 008, while the rest of the cluster is occupied by GOITER ITEM # 2 (AOB_ELEMENT # 2). GOAL ELEMENT No. 4 (AOB_ELEMENT # 4) occupies the area from md3 located in the middle of the 00C cluster to md4 located in the middle of the 00E cluster. In this way, the storage of GOITERS (AOB_ELEMENTs) through the boundaries of the clusters can be made, or, in other words, the recording of GOALS (AOB_ELEMENTs) can be carried out without taking into account the boundaries between the clusters. "FIRS_1st_ETPVR" (FNs _1t_TMSRTE) in TIB (BIT) indicates the number of frames in GOITER_ITIT # 1 (AOB_ELEMENT # 1), which is located in clusters 007 and 008, and "FIR__POST_ETPVR" (FNs_TEBITRIT) indicates the number of frames in ELEMENT_ZOB No. 4 (AOB_ELEMENT # 4), which is located in clusters from 00C to 00E.

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

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

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

On Fig shows how to set the parameters of the next reproduced frame NO_CHAIN (x + 1) (AOB_FRAME # x + 1) when performing a search in the forward direction, which begins with the frame NO_CHAIR No. (AOB_FRAME # x) in the element_CHAIN No. ( AOB_ELEMENT # y) GOITER (AOW).

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

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

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

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

GOAL_ZOB No. (x + 1) (AOB_FRAME # x + 1), which is 2 seconds later + 240 milliseconds from GOAL_ZOB NOx (AOB_FRAME # x), contained in GOAL_ZOB NO. (AOB_ELEMENT # y), will most likely be located in GOAL_ZOB NO. (y + 1) (AOB_ELEMENT # y + 1). When determining GOAL_CHAW No (x + 1) (AOB_FRAME # x + 1) located after 2 seconds + 240 milliseconds from FRAME_CHAW Nox (AOB_FRAME # x), despite the fact that the playback device cannot recognize from the TTPVR Element (TMSRT_Entry) about the number of GOALS (AOB_FRAMEs) located between the starting address of GOITER_CHANGE No. (y + 1) (AOB_ELEMENT # y + 1) and GOAL_ZOB NO. (x + 1) (AOB_FRAME # x + 1), the first address of the next GOAL_ZOLE No. (y + 1) ) (AOB_ELEMENT # y + 1) can be directly computed by reading the TMPR_Entry Element (TMSRT_Entry) from the TFGPVR (TKTMSRT).

To calculate this number of GOITERS (AOB_FRAMEs), it is necessary to subtract the total number of frames contained in GOITER_ZOB NO. relative to the start of GOITTEN ITEM # (AOB_ELEMENT # y), (2) f (t) and (3) f (skip_time) ("f (skip_time)"). In order to simplify the calculation of the relative position of the frame KADRA_ZOB No. (x + 1) (AOB_FRAME # x + 1) in ITEM_CRAFT No. (y + 1) (AOB_ELEMENT # y + 1), in TIB (BIT) for each ITEM_CRAFT (AOB_ELEMENT) write "RING_1 "(FNs_1st_TMSRTE)," QTY_Medium_TMSRTE "(FNs_Middle_TMSRTE) and" QTY_ Last_ETPWR "(FNs_Last_TMSRTE) as described above.

{17-5_22-15_26A) Using the number of frames specified

in each GOAL_ELECTOR (AOB_ELEMENT) (part 2)

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

Equation 2

Transition_ record_ (in seconds) = (KOLK_1go_ETPPVR + KOLK_Sredn_ETPPVR * y + x) * 20 ms

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

Since KOLK_1go_ETPPVR (FNs_1st_TMSRTE) and KOLK_Med_ETPPVR (FNs_Middle_TMSRTE) are contained in the TIB (BIT), they can be substituted into Equation 2 for calculating GOITER #OBID # AOB_ELAME # AOB_ELAME # AOB_ELECT. After that, the playback device can perform a call to the Crawler (TKTMSRT) GOITER (AOW) to calculate the first address of ITEM_THEAD No. (y + 2) (AOB_ELEMENT # y + 2) (which is the (y + 2) th ITEM_THE Goiter (AOB_ELEMENT) in this GOITER (AOW)) and, starting from this first address, start the search for FRAME_CHAW Nox (AOB_FRAME # x). When the x-th FRAME (AOB_FRAME) is detected, the playback device starts playback from this frame. Thus, the playback device can start playing data from the point in time specified in the Transition_Region (Jmp_Entry) (in seconds).

Thus, for the playback device, it is not necessary to search for parts of the ADTS header in FRAMEs (AOB_FRAMEs), but simply search in AOB_ELEMENTS ELEMENTS, which are indicated in TMSRT_Entries Elements from TFRPVR (TKTMSRT). This means that the playback device can quickly find the playback location corresponding to the specified playback time.

Similarly, when the value of Transition_On_Junction (Jmp_Entry) is set, and the time search function is used for a phonogram consisting of a set of GOITERS (AOB), the playback device only needs to calculate the GOITER_NAME (AOB_ELEMENT # y) and GOAL_FRAME #x (АОВ_FRAME # x) that satisfy the Equation 3 below.

Equation 3

Transition_Record (in seconds) =

Duration of playback from GOITER No. 1 to GOITER No.n + (KOLK_1go_ETPPVR (No. (n + 1)) + KOLK_Sredn_ETPPVR (No. (n + 1)) * y + x) * 20 ms

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

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

["KOLK_1go_ETPPVR" (No. 1) + "KOLK_Medium_ETPPVR" (No. 1) * (Number of Elements_TPPVR (No. 1) -2) + "KOLK_Post_ETPPVR" (No. 1) + "KOLK_1go_ETPPVR" (No. 2) + ("KOLK_1go_ETPPVR" (No. 2) + ( 2) * Number of Elements_TPPVR (No. 2) -2) + "KOLK_Post_ETPPVR" (No. 2) + "KOLK_1go_ETPPVR" (No. 3) + ("KOLK_Medium_ETPPVR" (No. 3) * Number of Elements_TPPPVR (No. 3) -2) + KOLK_ "(No. 3) ... +" KOLK_1go_ETPPVR "(No. n) + (" KOLK_Medium_ETPPVR "(No. n) * Number of Elements_TPPVR (No. n) -2) +" KOLK_Sent_ETPPVR "(No. n)] * 20 ms

After calculating GOITER #n (AOB # n), GOITTER ITEM # (АОВ_ELEMENT # y) and GOITER_CHADER Nox (AOB_FRAME # x) satisfying Equation 3, the playback device accesses TPFGVR (TKTMSRT) corresponding to GOITER No. (n + 1 ) (AOW # n + 1), searches for the x-th Cadre (AOB_ERAME) from the address where the (y + 2) th ELEMENT_ goiter (AOB_ELEMENT) is located (that is, ELEMENT_ goiter No. (y + 2) (AOB_ELEMENT # y + 2 )), and starts playback from this x-th FRAME_ZOB (AOB_FRAME).

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

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

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

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

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

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

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

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

On Figb a new recordable phonogram consists of four GOITERS (AOW). Unused IDFs (TKIs) for recording these GOITERS (AOW) are determined according to UP_FG_SVFU (phonogram search pointers from the default playlist) (DPL_TK_SRPs) or they can be selected arbitrarily. In this example, to record an IDF (TKI) of a new phonogram, unused IDFs (TKI) are used, having numbers IDF No. 2, IDF No. 4, IDF No. 7 and IDF No. 8 (TKI # 2, TKI # 4, TKI # 7, TKI # 8).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The second condition is that in a phonogram created by combining, three or more GOITERS (AOB), which consist only of those GOITER_OBEELEMENTs (AOB_ELEMENTs), the number of GOITER_FRAMES (AOB_Frames) in which is less than the required quantity for "FIR_Med_Enterprotection," cannot be implemented. (FNs_Middle_TMSRTE) ".

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

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

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

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

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

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

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

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

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

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

In the case when the first phonogram ends with a GOITER of the 2nd type (Toure 2 AOV), and the immediately preceding GOITER (AOW) is also a goiter of the 2nd type (Toure2 AOV), this first phonogram can be combined with the next phonogram starting with GOITER type 1 (Type1 AOB). Fig. 32D shows the case in which the first phonogram ends with two GOITERS of the 2nd type (Toure 2 AOB), and the second phonogram starts with GOITER of the 1st type (Type1 AOB). Since this case satisfies the second condition, the displayed phonograms can be combined into a single phonogram. Thus, when combining two phonograms, an analysis is made of whether these two phonograms satisfy the first and second conditions, and the combination of these two phonograms is carried out only if it is decided that they satisfy these conditions.

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

{17-5_22-19_33A, B} Setting parameters for IDF (TKI), in

case of phonogram separation

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

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

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

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

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

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

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

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

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

{17-5_22-19_33A, B-3_36} Installation of TIB parameters (BIT)

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

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

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

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

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

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

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

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

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

In the TIB (BIT) of the second phonogram created by splitting, “Data_Offset” (Data_0ffset) is set to “R”, “DATA_DATA” (SZ_DATA) is set to: (the original OBDATA “52428” is the data length to the split point Q), and NUMBER_TOLES (TMSRTE_Ns) is set to the value "n-k + 1", which is obtained by adding a unit (for the k-th TMSRT_entry Element (which is newly added as a result of the separation) to the number of TMSRT_entries Elements from the k-th TMPRT_entries) TMSRT_entry) to the nth TPMS_ Element (TMSRT_entry).

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

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

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

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

Here it should be noted that GOAL ELEMENT No.k (АОВ_ELEMENT # k), which contains the separation boundary, contains only region (1), therefore the k-th TMSRT_entry Element_ contains only the data that corresponds to this area (1). The second soundtrack (TMSRT) of the second phonogram contains Elements_TPSVR (TMSRT_entries) from the k-th Element_TVPVR (TMSRT_entry) GOITER (AOW) to the separation to the n-th Element_TVPVR (TMSRT_entry), that is, Elements_ТППВР (TMSRT_entry) with # k no_n (T. .. # n). It should be noted here that the TP_TVR Element #k (AOB_ELEMENT # k), which contains the separation boundary, contains only the region (2), therefore the k-th TPMS_ Element (TMSRT_entry) contains the volume of only those data that correspond to this region ( 2).

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

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

{17-6} Playlist Manager (PlaylistManager)

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

The HMIS (DPLI) referred to here differs from each HMIS (PLI) as follows. While the DPMI must contain all the phonograms stored in the flash memory card 52, the PLM does not have such a restriction and any number of phonograms can be indicated in it. This opens up various possibilities for the user. Typical examples of this are the ability for the user to create Information_of_list_of_playable_files (Playlist_Inforniation), in which only his or her favorite phonograms are indicated, and to save this Information_of_list of playable_files (Playlist_Information) in the board 31 flash memory, or the ability to automatically create playlist of Playback_file_information in which only phonograms of a certain genre are selected, selected from the set of phonograms stored in the flash card 31 memory, and save the resulting information about the list of playable files in the card 31 flash memory.

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

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

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

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

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

{17-9_39B} Format UP_FG_SVF (PL_TK_SRP)

On Figb shows the format UP_FG_SVF (PL_TK_SRP). It represents a field of ten bits into which NIDF_SVF (PL_TKIN) is written, that is, the IDF number (TKI).

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

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

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

In the case when using IDF (TKI) indicated by NIDF (TKIN), and in the file GOITER (AOW file) corresponding to the specified IDF (TKI), record a sound object (GOITER) (AOW), which corresponds only to the beginning of the phonogram (that is, when ATR_BLK_IDF (TKI_BLK_ATR) IDF (TKI) has the value “Begin Phonogram” (“Head_of_Track”), set “ATR_FG_SVFU” (DPL_TK_ATR) to “001b". In the case when TI is used, the ID is used (TI). specified by NIDF (TKIN), and in the file GOITER (AOW file) corresponding to the specified IDF (TKI), record a sound object (GOITER) (AOW), to which corresponds to the middle part of the phonogram, that is, when ATR_BLK_IDF (TKI_BLK_ATR) IDF (TKI) has the value "Midpoint_of_Track", in "ATR_FG_SVFU" (DPL_TK_ATR) set the value when "0 is used, when 0 is used. IDF (TKI) specified by NIDF (TKIN), and in the file GOITER (AOW file) corresponding to the specified IDF (TKI), record a sound object (GOITER) (AOW), which corresponds to the final part of the phonogram (that is, when ATR_BLK_IDF (TKI_BLK_ATR) IDF (TKI) has the value "End_phonogram" (End_of_Track "), then in" ATR_FG_SVFU "(DPL_TK_ATR) set to Achen equal to "011b".

In the opposite case, when the IDF (TKI) indicated by the NIDF (TKIN) is not used, and the area for the IDF (TKI) is simply set corresponding to the state when the removal of the IDF (TKI) was performed (that is, when ATR_BLK_IDF (TKI_BLK_ATR) IDF (TKI) has the value "Unused"), in "ATR_FG_SVFU" (DPL_TK_ATR) set the value to "100b".

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

Since the IDF number (TKI) is recorded in NIDF_SVFU (DPL_TKIN), it is clear which of the many IDFs (TKI) correspond to each UP_FG_SVFU (DPL_TK_SRP). The position of UP_FG_SVFU (DPL_TK_SRP) in the Information_of the list of reproducible_files_of the default (Default_Playlist_Information) indicates when the GOITER (AOW) corresponding to those IDF (TKI) will be played back, which in turn correspond to the UP_FV_FLOW (DP_LOG_FUL (DP) of ) As a result, the order of the elements UP_FG_SVFU (DPL_TK_SRP) in the List of reproducible_files_of_default (Default_Playlist) denotes the order in which the reproduction of many phonograms will be performed, or, in other words, determines the playback order of the phonograms.

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

Fig. 40 shows the relationship between Default_Playlist_Information, Default Playlist_Information, IDF (TKI), and Goiter files (AOB files). The second third and fourth levels in this drawing are similar to the first, second, and third levels in Fig. 19, and they show a phonogram manager (TrackManager) containing eight IDFs (TKI) and eight GOITER files. Fig. 40 differs from Fig. 19 in that the rectangle denoting

The default_playlist_information_list_ information_of_playable_files is shown at the first level. This rectangle shows eight small sections representing the eight UP_FG_SVFU (DPL_TK_SRP) contained in the Default_laylist_Information_playable_list_information (Default_Playlist_Information). ATR_FG_SVFU (DPL_TK_ATR) is shown at the top of each section, and NIDF_SVFU (DPL_TKIN) is shown at the bottom.

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

When considering fields ATR_FG_SVFU (DPL_TK_ATR) in UP_FG_SVFU (DPL_TK_SRP) shows that for each of UP_FG_SVFU №1, UP_FG_SVFU №2, and №3 UP_FG_SVFU UP_FG_SVFU №8 (DPL_TK_SRP # 1, DPL_TK_SRP # 2, DPL_TK_SRP # 3, DPL_TK_SRP # 8) the value was set to "Phonogram" ("Track"). In other words, the four following sets: UP_FG_SVFU No. 1 → IDF No. 1 (DPL_TK_SRP # 1 → TKI # 1) ("AOB001.SA1"), UP_FG_SVFU No. 2 → IDF No. 2 (DPL_TK_SRP # 2 → TKI # 2) ("AOB002 .SA1 "), UP_FG_SVFU No. 3 → IDF No. 3 (DPL_TK_SRP # 3 → TKI # 3) (" AOB003.SA1 "), UP_FG_SVFU No. 8 → IDF No. 8 (DPL_TK_SRP # 8 → TKI # 8) (" AOB008A1 ") correspond to four separate phonograms.

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

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

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

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

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

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

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

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

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

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

It should be especially noted that if a phonogram consists of a set of IDF (TKI), then only the IDF number (TKI) of the beginning of the phonogram is recorded in the element UP_FG_SVF (PL_TK_SRP). In more detail, in spite of the fact that the values UP_FG_SVFU (DPL_TK_SRP), shown in Information_ _o_spiske_vosproizvodimyh_faylov_po_umolchaniyu (Default_Playlist_Information), determine the four IDF (TKI) (IDF №4, IDF №5, IDF №6, IDF №7) (TKI # 4, TKI # 5, TKI # 6, TKI # 7), which form Phonogram G (TrackD), in UP_FG_SVF (PL_TK_SRP) listed in the Information_of_List_of Playback_files (Playlist_Information) all four IDFs (TKI) do not have to be indicated. For this reason, UP_FG_SVF No. 2 (PL_TK_SRP # 2) in the List of reproducible_files No. 3 (Playlist # 3) of all IDFs No. 4 to No. 7 (TKI # 4- # 7) indicates only IDF No. 4 (TKI # 4).

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

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

It should be noted here that UP_FG_SVFU (DPL_TK_SRP), corresponding to the GOITER (AOW) file, has a small amount of data (no more than two bytes), and IDFs (TKI) corresponding to the GOITTLE (AOW file), have a large data volume (up to 1024 bytes ) When reordering IDFs (TKIs) in the phonogram manager (TrackManager), a large number of access operations to the 31 flash memory card must be performed, however reordering UP_FG_SVFU (DPL_TK_SRPs) in the List_ Information_of the playable_files by default (Default_PlayI can have less to the board 31 flash memory.

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

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

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

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

The numbers (1), (2), (3), (4), (5), (6), (7), (8) in Fig. 43B indicate the order of playback of the phonograms after this editing operation. It should be noted that Fig. 43A shows the following playback order: Phonogram A, Phonogram B, Phonogram B, Phonogram D, Phonogram D (TrackA, TrackB, TrackC, TrackD, TrackE), and Fig. 43B in the Information_of_list_of the playable_files_of_default (Default_Playlist_Information) NIDF_SVFU (DPL_TKINs) UP_FG_SVFU No. 3 and UP_FG_SVFU No. 8 (DPL_TK_SRP # 3, DPL_TK_SRP # 8) were rearranged among themselves, therefore, the playback of phonograms is performed in the following order: Phonogram A, Phonogram B, Phonogram D, Phonogram D, Phonogram D, Phonogram D, Phonogram D, Phonogram D, Phonogram D, Phonogram D, Phonogram D, Phonogram D, Phonogram D, Phonogram D, Phonogram D, Phonogram D, Phonogram D, TrackB, TrackE, TrackD, TrackC). In this way, the order of playing back phonograms can be easily implemented by changing the order UP_FG_SVFU (DPL_TK_SRPs) in the Default_laylist_Information_playlist_file_information (Default_Playlist_Information).

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

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

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

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

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

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

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

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

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

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

These drawings are largely similar to Fig. 28A and Fig. 28B, which were used to explain the assignment of new IDFs (TKIs) to IDFs (TKIs) having a value of "Unused". The second, third and fourth levels in Fig. 45A and Fig. 45B are identical to the first three levels in Fig. 28A and Fig. 28B. The difference between these drawings is that in Fig. 45A and Fig. 45B, the first levels show Default_ Playlist_Information list_ information_list, consisting of a plurality of DPL_TK_SRPs UP_FG_SRFU. On Figa in UP_FG_SVFU from No. 4 to No. 8 (DPL_TK_SRP # 4 - DPL_TK_SRP # 8) set to "Unused". However, in Fig. 28, 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) are set to "Unused "

Despite the fact that IDFs (TKIs) with "Unused" values are located in different places of the phonograms administrator (TrackManager), the Default_laylist_Information and Default_laylist_information (Unused) UPFG_SVFU (DPL_TK_SRPs) are located in different places of the phonograms administrator (TrackManager). This is due to the fact that, as described above, in the Default_list_Information playlist_ information (Default Playlist_Information), the used DPL_TK_SRPs (UPLs) advance forward, and for IDFs (TKIs) do not perform this advancement.

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

UP_FG_SVFU (DPL_TK_SRPs) for these four GOITERS (AOW) are recorded in UP_FG_SVFU from No. 4 to No. 7 (DPL_TK_SRP # 4 - DPL_TK_SRP # 7) in the Default_play_playlist_information Default_file information (Default_list). Since these four SCA (AOB) form a single soundtrack, the value ATR_FG_SVFU (DPL_TK_ATR) UP_FG_SVFU №4 (DPL_TK_SRP # 4) is set as "Nachalo_Fonogrammy" ( "Head_of_Track"), the value ATR_FG_SVFU (DPL_TK_ATRs) UP_FG_SVFU №4 (DPL_TK_SRP # 4) and UP_FG_SVFU No. 6 (DPL_TK_SRP # 5) are set as "Middle_Fonograms" ("Middle_of_Track"), and the value ATR_FG_SVFU (DPL_TK_ATR) UP_FG_SVFU No. 7 (DPL_TK_SRP "K_fon" End "is set to End).

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

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

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

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

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

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

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

Below is a description of updating the Information_of_list_of_playable_files_of_default (Default_Playlist_Information) when splitting a phonogram (Example 4).

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

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

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

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

{17-9_40-8} Applying Editing Processing

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

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

{48-1} Appearance of the playback device

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

The keypad contains:

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

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

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

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

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

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

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

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

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

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

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

(1) A table of the list of playable files and a list of phonograms are displayed on the LCD panel (liquid crystal panel), which allows the user to display Default_laylist_Information list information_, _INVF (PLI), or individual phonograms.

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

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

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

{48-2_49_50} Improvement (2)

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

On Fig lines through the characters ASCII (American standard code for the exchange of information) "list_playable_files_of_default" ("DEFAULT PLAYLIST"), "list of playable_files # 1" ("PLAYLIST # 1"), "list of playable_files # 2" ("PLAYLIST ), "playlist_3 # 3" ("PLAYLIST # 3") and "playlist_4 # 4" ("PLAYLIST # 4") display the default playlist and four playlist lists stored in the flash card 31 .

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

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

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

{48-3_51} Improvement (4)

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

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

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

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

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

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

As shown in Fig. 52, the playback device includes a board connector 1 for connecting the playback device to a flash memory card 31, a user interface unit 2, which is connected to a keypad and to a rotary disk with step switching, RAM (random access memory ) 3, ROM (“read-only memory”) 4, LCD panel 5 having a list box for displaying a list of phonograms or lists of playable files and a window for a playback time code for displaying a playback time code, Property 6 of the LCD control for controlling the first LCD panel 5, a decoder of 7 random sequences for decryption AOB_FRAMEs using different file keys (FileKey) for each GOITER file (AOW file), decoder 8 of an ultrasound scan (advanced audio information encoding) (AAC ) to access ADTS KADR_ZOB (AOB_FRAME), which was decrypted by means of a decoder of 7 random sequences, and to decode KADR_ZOB (AOB_FRAME) to obtain PCM (PCM) data, a digital-to-analog converter (TsA) O) 9 for digital-to-analog conversion of PCM data and outputting the resulting analog signals to a loudspeaker or headphone jack, and a central processing unit (CPU) 10 for centralized control of the playback device.

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

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

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

{52_12} ISVF Storage Area 12 (PLI)

The ISVF storage area 12 (PLI) is an area that is reserved for storing Information __ on the Playlist_Information list selected by the user for playback.

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

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

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

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

{52-5} Double buffer 15

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

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

{52-5_53_54A_B} Input and output via double buffer 15

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

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

{54-6_53}

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

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

{52-7_54A}

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

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

последовательно указывают посредством указателя считывания. Когда указатель считывания доходит до позиции считывания

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

sequentially indicated by a read pointer. When the read pointer reaches the read position

, all GOITER_FRAMEs contained in cluster 002 turn out to be read, while reading cluster 004 and, as shown by arrow w6 in Fig. 54A, overwriting it to the area that was previously occupied by cluster 002.

{52-8_54B}

и

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

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

and

, and ultimately reaches the reading position

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

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

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

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

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

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

{52-9_55-1}

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

{52-9_55-2}

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

In step S2, the CPU 10 waits for instructions to play the GOITER (AOW) according to either Default_laylist_Information Information_O_List_Play_Files (Default_Playlist_Information), or one of the IFMS (PLIs).

In the case when the Default_Playlist_Information is specified, the processing goes from operation S2 to operation S3, in which initialization (No. (w-1)) (# w-1) of the variable w is performed, and then to operation 34, in which determine IDF No. z (TKI # z), indicated by NIDF_SVFU (DPL_TKIN), corresponding UP_FG_SVFU No. w (DPL_TK_3RP # w) in the Information_of_the_playable_files_of_the_default (Default_Playlist_Information), and TI # read only memory and their storage in the field 13 of the storage IDF (TKI).

In step S5, a GOK No. z file (AOB file #z) is determined, which has the same number as IDF No. z (TKI # z). In this way, the final goiter file (AOB file) that is intended for playback is finally determined.

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

{52-9_55-3}

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

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

{52-9_55-4}

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

Such a rewrite leads to the fact that in the storage area 13 IDF (TKI) will be remembered, only the most recent IDF (TKI). After overwriting the IDF (TKI), the processing performed by operations S5 to S12 is repeated for the GOITER No. z file (AOB file # z). After all the IDFs (TKI) and GOIT files (AOW files) corresponding to all UP_FG_SVFU (DPL_TK_SRPs) contained in the Default_laylist_Information) information_of_list (Default_Playlist_Information) are read by all values, the value of the variable z will be the same as (total_Under_Folder), the value of the variable z (#z) will be the same as (DPL_TK_SRP), therefore, when performing operation S12, the decision is “Yes” and the processing is completed according to this flowchart.

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

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

{52-9_56-1}

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

{52-9 _ 56-2}

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

Immediately after the first random AOB_FRAME is output to the decoder 7 random sequences, the playback device performs an operation S26, in which it accesses the ADTS header NO_FRAME # x (AOB_FRAME # x) and determines the location of the next NO_FRAME (AOB_FRAME). In step S27, the reproducing apparatus increments the variable x (# x ← # x + 1) and sets the GOAL_CHAIR # x (AOB_FRAME # x) as the next GOAL_CHAIN (AOB_FRAME). When performing operation S28, KADR_ZOB No.x (AOB_FRAME # x) is input into the decoder 7 random sequences. After that, at the step of performing operation S29, the variable "Play_time" (Play_time) is incremented by an amount equal to the duration of the playback FRAME_CHAP # x (AOB_FRAME # x), and the increment of the variable "play_data" (play_data) is the amount of data corresponding to the RAM_ZOB Nox ( AOB_FRAME # x). After the increment on KADR_ GOITER #x (AOB_FRAME # x) is performed, operation S30 is performed, in which CPU 10 determines whether the variable x (# x) has reached the value set in KOLK_1go_ETPPVR (FNs_1st_TMSRTE).

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

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

{52-9_57-1}

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

After that, when performing operation S33, the reproducing apparatus calls the TPKHPVR (TKTMSRT) and calculates the first address of GOAL ELEMENT # (AOB_ELEMENT # y).

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

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

If the variable y (# y) is less than (Total_number_ of elements_ТППВР-1) (TotalTMSRT_entry_Number-1), then GOITER_CRAFT ITEM # 1 (AOB_ELEMENT # y) is not the last GOITER_ ITEM (AOB_ELEMENT), therefore, during processing, they return from operation S44 to operation S44 carry out the cycle procedure from operation S32 to operation S42. When the variable y (# y) reaches the value (Total_number_ of elements_ТППВР-1) (Total-TMSRT_entry_Number-1), then we can assume that the reading procedure has reached the penultimate AOB_ELEMENT ELEMENT, therefore, when performing operation S44, the decision is “Yes” and during processing proceeding to step S45 of FIG.

{52-9_57-2}

The similarity of the procedure consisting of operations S45 to S54 with the procedure consisting of operations S33 to S42 consists in the fact that each of the FRAME_ZOB (AOB_FRAMEs) is read in it in the final element_OBIT (AOB_ELEMENT).

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

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

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

{52-9_57-3_59} Updating the play time code

The drawings of FIG. 59A to FIG. 59G show how to increase the playback time code, which is displayed in the display window of the playback time code on the LCD panel 5, in accordance with the update of the variable "Play_time" (Play_time). In Fig. 59A, the value of the playback time code is "00: 00: 00,000", however, upon completion of the playback, GOITER No. 1 (AOB_FRAME # 1), the value of the playing time NO. 1 (AOB_FRAME # 1) equal to 20 ms is added to the playback time code, updating it to the value "00: 00: 00,020", as shown in Fig.59B. Upon completion of the playback, CADA_CHAW No.2 (AOB_FRAME # 2), the playback time code CADA_CHAW No.2 (AOB_FRAME # 2) equal to 20 ms is added to the playback time code, updating it to the value “00: 00: 00.040”, as shown in Fig. 59B. Likewise, upon completion of playback of KADRA-GOITTER No. 6 (AOB_FRAME # 6), the value of the duration of playback KADRA-GOITER No. 6 (AOB_FRAME # 6), equal to 20 ms, is updated to the value “00: 00: 00,120”, as shown on Fig.

This completes the description of the output procedure KADR_ZOB (AOB_FRAME).

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

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

{52-10_60} Forward Search Function

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

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

{52-10_60-1_61A, B}

61A and 61B show a procedure for incrementing a play time code in a forward search operation. On Figa shows the initial value of the code of the playback time, while the playback point is FRAME_CHAWER No. 1 (AOB_FRAME # 1) in the element_CHAIN No. 51 (AOB_ELEMENT # 51).

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

{52-10_60-2}

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

As indicated above, the number of frames in GOITER (AOW_ELEMENT) located at the beginning of GOITER (AOW) is equal to "FIR__st_TMSRTE" (FNs_1st_TMSRTE), the number of frames in GOITER (AOB_ELEMENT) located in the middle part of GOITER (AOB_ELEMENT) is equal to GOITER (ARE_ELEMENT) " FNs_Middle_TMSRTE), and the number of frames in the GOITER (AOB_ELEMENT), which is located at the end of the GOITER (AOW), is equal to "FIRST_LAST_TMSRTE" (FNs_Last_TMSRTE).

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

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

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

{52-10_60-3}

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

(x ← x + f (skip_time), Playback_time ← Playback_time + skip_time, and playable_data ← playable_data + d (skip_time))

(# x ← # x + f (skip_time), play_time ← play_time + skip_time, play _ data ← play _ data + d (skip_time)).

{52-10_60-4_61B}

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

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

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

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

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

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

{52-11} Implementation of the time search function

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

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

{52-12}

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

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

{52-13_62A, B}

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

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

280 seconds = (KOLK_1go_ETPPVR + (KOLK_Sredn_ETPPVR * 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, the following values satisfy Equation 2: y = 148 and x = 8.

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

{52-14_63_64_65}

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

{52-14_63-1} Editing control program

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

{66-1} Recorder

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

{67-1} Hardware composition of the recorder

On Fig shows the hardware composition of the recording device.

As shown in Fig. 67, the recorder comprises a board connector 21 for connecting the recorder to a flash memory card 31, RAM 22, a non-removable disk device 23 for storing a recording control program that centrally controls the recorder, analogously a digital converter 24, designed to perform analog-to-digital conversion of audio data inputted through a microphone, which ensures the creation of PCM data (with pulse-code modulation) encoding a device Property 25 of the ultrasound inspection (Advanced Audio Information Encoding - (AAS)), which encodes PCM data in units of constant time duration and assigns ADTS headers to create AOB_FRAMEs, 26 encryption device used to encrypt AOB_FRAMEs (AOB_FRAMEs) using different File Keys for each AOB_BLOCK, modem 27 for receiving a transport stream of audio data when the electronic music distribution service is carried out before downloading to the recording device through the communication lines of the encrypted directory of the EDI (source audio data) (SD_Audio), or when the music distribution service electronically transferred the audio stream to the recording device through the communication lines, the CPU 28 controls the centralized control of the recording device, the keyboard 29 for receiving user input and a screen display device 30.

{67-2} Input circuits from RT1 to RT4

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

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

{67-3} Input path RT1

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

{67-4} Input path RT2

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

{67-5} Input path RT3

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

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

{67-6} Input path RT4

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

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

{67-7_68} Processing performed on the recorder

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SECOND EMBODIMENT FOR CARRYING OUT THE INVENTION

A second embodiment of the present invention relates to improved storing of still images in conjunction with the GOITER files (AOW files) described in the first embodiment of the invention. These still images are displayed when playing back GOITER files.

{69-1} The hierarchical structure of the flash memory card of the second embodiment of the invention

On Fig shows the hierarchical structure of the card 31 flash memory for this second variant implementation. The difference between the hierarchical structure of the flash memory card 31 described in this embodiment and the hierarchical structure of the first embodiment is that the OBI (objects in the form of images) are added to the reproduced data, and the OBI administrators are added to the navigation data ( POBManagers). OBI (DOM) are fragments of data on still images in JPEG format (a format proposed by the Joint Group of Experts on Computer-Aided Image Processing), accessed through the administrator of the list of playable files (PlaylistManager) and the administrator of phonograms (TrackManager). The OBI administrator (POBManager) is the control information that describes how to access the OBI (DOM) through the administrator of the list of playable files (PlaylistManager) and the administrator of phonograms (TrackManager).

{69-1_70A-1} Structure of the user data area at the file system level

Since additional information is added to the reproduced data and navigation data in this embodiment, the internal structure of the user data area and the protected area at the file system level is changed as shown in FIG. 70A and FIG. 70B. The user data area shown in FIG. 70A differs from that shown in FIG. 8A in that in addition to the POBManager administrator file “POBOOO.POM”, files with the names “POBXXX.JPG” and “POBXXX.SP1” are added to it.

Files "POBXXX.JPG" and "POBXXX.SP1" correspond to the OBI (DOM) shown in Fig. 69, and the file "POBOOO.POM" corresponds to the administrator of the OBI (POBManager). The difference between the "POBXXX.JPG" and "POBXXX.SP1" files is due to the need to ensure copyright protection. Files with the file name extension “JPG” are simply files containing data on still images in JPEG format, and files with the file name extension “SP1” have been encrypted to protect copyrights that apply to still images. Here, the abbreviation "SP" means "protected image" and indicates the need to ensure copyright protection.

In order to enable users to create their own memorized information content, still images created by users can be recorded on a flash memory card, such as family photographs or memorable images. Since copyright protection is usually not necessary for such images, they can be recorded in a flash memory card in JPEG format without encryption. On the other hand, the artist’s photographs and album art are usually the property of the artist or record company. Since there is a risk of unauthorized copying by users of images transmitted by the electronic music distribution service, these images are recorded on a flash memory card in the form of “Secure Picture” files.

The numbers "001", "002", "003", ..., assigned to the files with the names "POBXXX.SP1" and "РОВХХХ.JPG", represent the OBI (DOM) numbers that are assigned to the individual objects (OBI) (DOB) ) representing images. This means that the displayed objects (OBI) (DOM), which are images, can be set using the number of the OBI (DOM).

{69-2_70B-1} Structure of the user data area at the file system level

On Figb shows the structure of the protected area in this second embodiment of the invention. Compared to the secure area shown in FIG. 8B, the secure area in this second embodiment further comprises an encryption key storage file called “POBSP1.key”. The file keys (FileKeys) that are used to decrypt (encrypted) "POBXXX.SP1" files are stored in this file. After reading the file "POBXXX.SP1", you must extract the file key (FileKey) from this encryption key storage file "POBSP1.key".

The IED directories (SD_Audio) shown in Figs. 70A and 70B are stored in a server computer, which is managed by a recording company that distributes music electronically. When a user makes an order to purchase musical information content, the server computer compresses the corresponding CDM directory (SD_Audio), encrypts it, and then transfers it to the user who made this order.

The user's computer accepts the IAD directory (SD_Audio), decrypts it, unpacks it, and thus obtains the original IAD directory (SD_Audio). It should be noted that, instead, the computer can download phonograms (GOITRES) (AOB) with the accompanying still images (OBI) (DOM) from the server computer, and then independently generate the CD catalogs (SD_Audio) shown in Fig. 70A and Fig. 70B, in the board 31 flash memory.

{69-3_71A, B, C-1} Internal structure of the files "POBXXX.JPG" and "POBXXX.SP1"

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

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

The internal structure of Z_IOB (POV_H) is shown by the dashed lines hP1 shown in FIG. As shown in the drawing, Z_IOB (POV_N) consists of a double-byte ID_ID (IOB identifier) (POB_ID), the value of which is set to "FFE0" to indicate that the current file is an IOB (POB file), a reserved area occupying one byte, a single-byte ATR_OB (attribute IOB) (POB_ATR), by means of which it indicates whether there is encrypted data in "POBXXX.SP1", and from a four-byte OB_OB (volume of OBI) (POB_SZ), by which indicate the amount of data of the OBI.

In the case when encrypted data is present in the file "POBXXX.SP1", the value ATR_OB (POB_ATR) is set to "0" to indicate that the "data body exists" (that is, when the file "POBXXX.SP1" is not carried out indirect link to another file). Otherwise, when there is no encrypted data in the "POBXXX.SP1" file, instead, the access path to the file containing the data on the still image is stored in the file (that is, when the "POBXXX.SP1" file provides an indirect link to another file). On Figv shows an example of the file OBI (DOM), in which instead of the encrypted data body is stored the path to the file.

The file name "photo001.JPG" specified in the access path "\ DCIM \ Ctg_001 \ photo001.JPG" denotes a file in which data on a still image for a digital photograph obtained using a digital photographic camera is stored. In the event that the path to the directory and the file name are indicated in the OBI (DOM) file in the above way, this indirectly refers to the data on images stored in the file "photo001.JPG", the access path to which has the form "\ DCIM \ Ctg_001 \ photo001.JPG. " In this "POBXXX.SP1" the value of ATR_OB (POB_ATR) in the manager of the OBI (POBMANAGER) is set to "1" to indicate that it is "missing data body".

As one example, a case is given in which a prerequisite for the operation of the device driver for a digital photographic camera is to store data on a still image obtained by the camera in a specific file in a specific directory, while specifying a JPG file in which data on a still image is stored, in the OBI file (DOM), similar to that shown in Fig. 71B, can be implemented using an indirect link to the file access path (in Fig. 71B, the device driver for digital photographic Measures stipulates the mandatory storage of the file in the location that is specified by the access path "\ DCIM \ Ctg_001 \ photo001.JPG", etc.). As a result, the output of such still image data to the screen during playback of music content can be carried out even when the still image data recorded by the digital camera is recorded in a specific file and in a specific directory in accordance with the requirements, due to the device driver.

This completes the description of reproducible data for this second embodiment of the present invention.

{72-1} Administrator of the list of playable files (PlaylistManager) and administrator of the phonograms (TrackManager)

The display of the files "POBXXX.JPG" and "POBXXX.SP1" of the reproduced data is performed in synchronization with the reproduction of the phonograms described in the first embodiment of the invention. For such synchronous output of images to the screen along with the phonograms, the administrator of the list of playable files (PlaylistManager) and the administrator of the phonograms (TrackManager) of the second embodiment have the structure shown in Fig. 72. On Fig shows a detailed structure of the administrator of the list of playable files (PlaylistManager) and the administrator of the phonograms (TrackManager) in this second embodiment. In this embodiment, the administrator of the list of playable files (PlaylistManager) and the administrator of the phonograms (TrackManager) differ from those shown in Fig. 17 from the first embodiment in that, in contrast to the previous embodiment, the contents of the General_information_of_playlist_of_default (OISVFU) (Default_Playlist_General_Information_information (Information) of OISVF) (Playlist_General_Information (PLGI)) is shown explicitly, and that ATR_IOB_IDF (TKI_POB_ATR) and twenty new UP_IOB_IDF (TKI_POB_TKIs) are created in the UIFG (TKGI).

{72-2} OISWPU (DPLGI)

As shown by the dashed lines h61, the General_information_of_the_list of_playable_files_of_default (OISVFU) (Default_Playlist_General_Information (DPLGI)) contains the field ID_ISVFU (DPMSI ID) (DPLI_ID), in which there is a unique ID number for phonograms referenced in the ISVFU (DPLI), field PR_VP_ISVFU (DPLI_PB_TM), in which, in units of milliseconds, the total duration of the playback of all phonograms referenced in the list of playable files is specified m by default, the ATR_IOB_ISVFU field (DPLI_ROV_ATR) and sixty fields UP_IOB_ISVFU (DPLI_POB_SRP).

{72-3} OISWF (PLGI)

As shown by the dashed lines h62, each fragment of the General_information_of the playlist_of_play_files (OISVF) (Playlist_General_Information (PLGI)) consists of the field ID_ISVF (PLI_ID), in which a unique identifier for ISVF (PLI) is written, the field KOL_FGN_IS, the number of which the number of which is equal to "99"), referred to in the ISWF (PLI), field PR_VP_ISVF (PLI_PB_TM), in which the units of milliseconds record the total playback time of all phonograms to which there is a link in the list of playable files, by for ATR_OBI_ISVF (PLI_POB_PLI) and twenty fields UP_IOB_ISVF (PLI_POB_SRP).

{72-4_73} Summary of Supplements and Improvements Implemented in the Second Embodiment

From the above explanation, it is understood that the TIFG (TKGI) in this second embodiment further comprises two kinds of information: ATR_IOB_IDF (TKI_POB_ATR) and UP_IOB_IDF (TKI_POB_TKIs). Likewise, the OISVFU (DPLGI) additionally contains two types of information: ATR_IOB_ISVFU (DPLI_ROV_ATR) and DPLI_ROV_SRPS, and each OISVF (PLGI) also additionally contains two types of information: ATR_IOB_ISVF (PLI_POB_IBIPLI) and.

Each of UP_IOB_IDF (TKI_POB_TKIs), UP_IOB_ISVF (PLI_POB_SRPs) and UP_IOB_ISVFU (DPLI_POB_SRPs) has the same structure and they are used to accurately determine the OBI (DOM). On Fig shows how through UP_IOB_IDF (TKI_ROV_TKIs), UP_IOB_ISVF (PLI_POB_SRPs) and UP_IOB_ISVFU (DPLI_POB_SRPs) define the files OBI (DOM), which, for example, are shown in Fig.70A. The following is a description of the data structure ATR_IOB_IDF (ATR_IOB_ISVFU, ATR_IOB_ISVF) (TKI_POB_ATR (DPLI_POB_ATR, PLI_POB_ATR)) and UP_IOB_IDF (UP_IOB_ISVFU, UP_IPSPISPI_IBRISPISPI_PROBISPI_PROBISPI_SPBI_OPPI_OPPI_OPPI_OPPI_OPPI_OPPI_OPPI_OPPI_OPPI_OPPI_OPPI_OPPI_OPPI_OPPI_OPPI_OPPI_OPPI_OPPI_OPPI_OPPI_OPPI_OPPI_OPPI_OPPI_OPPI_OPPI_OPPI_OPPI_OPPI_OPPI_OPPI_OPPI_PROB.

{74-1} UP_IOB_IDF (TKI_POB_SRPs)

UP_IOB_IDF (TKI_POB_SRP) is a field that indicates an OBI (DOM), intended to be displayed on the screen during the playback period of a specific GOITER (AOW) from the total duration of the playback of phonograms, the playback order of which is indicated by Information_o_list_ of playable_files_of Default_Playlist_Information or. In other words, the OBI (DOM), intended to be displayed on the screen during the playback of a phonogram, can be set by setting the UP_IOB_IDF (TKI_POB_SRP) parameters in the phonogram manager (TrackManager).

On Fig shows the data structure UP_IOB_IDF (TKI__POB_SRPs) and ATR_IOB_IDF (TKI_POB_ATR).

As shown in the drawing, UP_IOB_IDF (TKI_POB_SRP) consists of a "Job Specification Field (POB)" (POB Specifying Field) (indicated in the drawing as "IOB_Number" ("POB_No.")), Which is located between bit number b25 and bit number b16 , the field "Number of Pixels", which is located between bit number b11 and bit number b8, the field "Huffman Table", which is located between bit number b7 and bit number b6, the field "color sampling" (Chrominance Sampling), which is located between bit number b5 and bit number b4, and the field "Picture Coding Mode", which It is between bit number b3 and bit number b0. Fields that are located between bit number b12 and bit number b15, as well as between bit number b26 and bit number b31, are reserved areas.

The "OBD (DOM) job field" is used to store a number accepting a value between "1" and "999", which is the OBI (DOM) number that is intended to be displayed on the screen during playback of the GOITER (AOW file), which corresponds to this IDF (TKI). In the case when during playback of the GOITER (AOW file) corresponding to these IDF (TKI) files, it is not necessary to display any still image on the screen, the value "0" is set in the "OBI (DOM) job field".

The "image encoding mode" field is used to notify the playback device of which encoding method was used for the still image, which is indicated by the "OBI (DOM) job field".

The field "color sampling" is used to indicate the ratio that was used to sample the brightness and color sampling of the two colors when encoding a still image specified in the "OBI (DOM) job field". To indicate that the ratio is "4: 2: 2", set the binary value "00" in this field, and to indicate that the ratio is "4: 2: 0", set the value to "01".

In the "Huffman table" field indicate whether to display a still image indicated by the "OBI (DOM) job field" on the screen, use a typical Huffman table. If you need to use the Huffman table, the value of this field is set to "00".

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

If there is such a structure, the OIFG (TKGI) contains twenty UP_IOB_IDF (TKI_POB_SRPs), therefore, during playback of the phonogram, a maximum of twenty still images can be displayed on the screen. In the case when the phonogram consists of several IDFs (TKI), only UP_IOB_IDF (TKI_POB_SRPs) in the first IDFs (TKI) are valid.

{74-2} ATR_OBIIDF (TKI_POB_ATR)

"ATR_IOB_IDF" (TKI_POB_ATR) is created in order to indicate how to display the OBI (DOM) indicated by twenty UP_IOB_IDF (TKI_POB_SRPs) in UIFG (TKGI). "ATR_IOB_IDF" (TKI_POB_ATR) contains the field "mode taking into account the display order on the screen" (Display Order Mode), located between the bit having the number b0 and the bit having the number b1, and the field "mode taking into account the display time on the screen "(Display Timing Mode), located between the bit number b2 and the bit number b3.

The "mode taking into account the display order on the screen" field is used to indicate the order of displaying the OBI (DOM) specified by twenty UP_IOB_IDF (TKI_POB_SRPs) in the UIF (TKGI). In this embodiment, the output of the OBI (DOM) on the screen during the playback period of the GOITER (AOW) is performed in one of three modes.

The first mode is called the "sequential mode" and it is such a mode in which the display of the OBI (DOM) indicated by at most twenty UP_IOB_IDF (TKI_POB_SRPs) in the UIFG (TKGI) is carried out in the order in which the UP_IOB_IDF (TKI_POB_SRPs ) are specified in the OIFG (TKGI).

The second mode is called "random mode" and it is such a mode in which the display of the OBI (DOM) indicated by a maximum of twenty UP IDB IDF (TKI_POB_SRPs) in the UIF (TKGI) is carried out in random order.

The third mode is called the "permutation mode" and it is such a mode in which the display of the OBI (DOM) indicated by at most twenty UP_IOB_IDF (TKI_POB_SRPs) in the UIF (TKGI) is carried out in arbitrary order without repetition.

In order to set the sequential mode, in the field "mode, taking into account the display order on the screen" set the binary value equal to "00". Otherwise, to set the random mode, set the binary value equal to "01", and to set the mode of permutation set the binary value equal to "10".

The "mode taking into account the time of display on the screen" field is used to indicate whether, when playing back the GOITTER file (AOW file), which corresponds to the IDF (TKI), to synchronously display the GOI (DOM) indicated by at most twenty UP_IOB_IDF ( TKI_POB_SRPs) from the UIFG (TKGI). A mode in which images are synchronized with audio data is called a "slide show mode". In the "slide show" mode, the user cannot skip the images displayed on the screen without skipping the reproduced audio data.

Another mode in which images and audio data are not synchronized is called a “viewing mode”. In viewing mode, the user can skip images without skipping audio data.

Thus, in TIFG (TKGI) specify information that indicates which OBI should be displayed on the screen during playback of the corresponding GOIT file (AOW file), in which order these OBI (DOM) should be displayed, and whether the output of the OBI (DOM) on the screen should be carried out synchronously with the playback of the corresponding GOITER (AOW file).

{74-3_75} Example of setting UP_IOB_IDF (TKI_POB_SRPs) values contained in IDF No. 1 through No. 3 (TKI # 1-TKI # 3)

On Fig shows an example of the option to set the values UP_IOB_IDF (TKI_POB_SRPs) for IDF with IDF No. 1 to IDF No. 3 (TKI # 1-TKI # 3) contained in the phonogram manager (TrackManager).

At the first level, Fig. 75 shows the phonograms administrator (TrackManager), and at the second level, nine OBI files (POW files) are shown. The phonogram manager (TrackManager) shown at the first level contains eight IDFs (TKI), and the arrows indicate which OBI files (DOM files) are accessed by UP_IOB_IDF (TKI_OP_SRPs) in these eight IDFs (TKI).

As indicated by the arrows, IDF No. 1 (TKI # 1) contain three UP_IOB_IDF (TKI_POB_SRPs), by means of which IOB (POW) with IOB001 (POB001) to IOB003 (POB003), IDF No. 2 (TKI # 2) contain three UP_IOB_IDF (TKI_POB_SRPs), by means of which IOB (DOM) with IOB004 (POB004) to IOB006 (POB006), and IDF No. 3 (TKI # 3) contain three UP_IOB_IDF (TKI_POB_SRPs) with which IOV are specified IOB007 (POB007) according to IOB009 (POB009).

In this embodiment, it is believed that the OBI (OVO) IOB001 (POB001) to IOB009 (POB009) are image data in JPEG format, consisting of song words superimposed on a normal background. The words that make up the lyrics are displayed using a font that matches the nature of the song, and they can be made more expressive, for example, by additionally highlighting them in bold.

At the lower level of Fig.75 shows the contents of each OBI (DOM). The contents of the OBI (ROV) from IOB001 to IOB003 (ROV001-ROV003) are the words of the song for Phonogram A (TrackA), the contents of the IOB (POV) from IOB004 to IOB006 (POV004-POV006) are the words of the song for Phonogram B (TrackB), and the contents of the OBI (ROV) from IOB007 to IOB009 (ROV007-ROV009) are the lyrics for Phonogram B (TrackC). Since the display of these images on the screen makes sense only during playback of the corresponding phonograms, the values UP_IOB_IDF (TKI_POB_SRPs) contained in the IDF (TKI) are set so that these images are displayed on the screen during such playback.

Each phonogram has the same playback duration as shown in FIG. 16, the reference to which was given in the first embodiment. This means that the duration of the playback "AOB001.SA1" corresponding to IDF No. 1 (TKI # 1) is 6.1 minutes, the duration of the playback "AOB002.SA1" corresponding to IDF No. 2 (TKI # 2) is 3.3 minutes, and the duration of the playback "AOB003.SA1" corresponding to IDF No. 3 (TKI # 3) is 5.5 minutes. During all this playing time, the TKI_POB_SRPs set in the IDFs (TKIs) become valid, and thus the playback device can display the POBs on the screen in accordance with these valid TIDI_IDFs (TKI_POB_SRPs).

The duration of playback of "AOBSA1.001" corresponding to IDF No. 1 (TKI # 1) is 6.1 minutes, therefore, if during this time period the display of the OBI from IOB001 to IOB003 (POB001-POB003) on the screen needs to be carried out for the same amount of time, then each image will be displayed for 2.03 (= 6.1 / 3) minutes. The duration of playback of "AOBSA2.001" corresponding to IDF No. 2 (TKI # 2) is 3.3 minutes, therefore, the display of each of the OBIs from IOB004 to IOB006 (POB004-POB006) will be carried out for 1.1 (= 3 , 3/3) minutes. The duration of the playback of "AOBSA3.001" corresponding to IDF No. 3 (TKI # 3) is 5.5 minutes, therefore, the display of each of the OBI from IOB007 to IOB009 (POB007-POB009) will be carried out for 1.83 (= 5 5/3) minutes.

{74-4_76} Example of setting UP_IOB_IDF (TKI_POB_SRPs) values contained in IDF No. 4 through No. 8 (TKI # 4-TKI # 8)

On Fig shows one example of setting the values UP_IOB_IDF (TKI_POB_SRPs) in the IDF from IDF No. 4 to IDF No. 8 (TKI # 4-TKI # 8) contained in the phonogram manager (TrackManager).

At the first level, the administrator of phonograms (TrackManager) is shown, and at the second level ten files of OBI (POM files) are shown. As shown by the arrows in the drawing, IDF No. 4 (TKI # 4) comprise seven UP_IOB_IDF (TKI_POB_SRPs), by means of which, respectively, IOB010-IOB016 (POB010-POB016) are set.

Similarly, IDF No. 8 (TKI # 8) contains three UP_IOB_IDF (TKI_POB_SRPs), by means of which respectively IOB017 - IOB019 (POB017-POB019) are set. In the present embodiment, the OBI from IOB010 to IOB019 (POB010-POV019), like the IOB from IOB001 to IOB009 (POB001-POB009), are image data in JPEG format, consisting of song words superimposed on a normal background. The reason that UP_IOB_IDF (TKI_ROV_SRPs) is set only for IDF No. 4 (TKI # 4), and not for any IDF No. 5 through No. 7 (TKI # 5-TKI # 7), is because indicated earlier, in the case where a single phonogram consists of a set of IDFs (TKI), only UP_IOB_IDF (TKI_POB_SRPs) in the first IDF (TKI) are valid.

The contents of the OBI from IOB010 to IOB016 - (POB010-POV016) are the lyrics for Phonogram G (TrackD), as shown in Fig. 16 from the first embodiment, and the contents of the IOB with IOB017 to IOB019 (POV016-POV019) are the words of the song for Phonogram D (TrackE). The total duration of the playback of files from “AOB004.SA1” to “AOB007.SA1” corresponding to IDFs No. 4 to No. 7 (TKI # 4-TKI # 7) is 30.6 minutes, therefore, the duration of displaying each of the OBIs with IOB010 by IOB016 (POB010-POB016) is 4.37 (= 30.6 / 7) minutes. As a result, during the playback of Phonogram D (TrackD), each OBI (DOM) can be displayed on the screen during this time. Since the duration of the playback of "AOBSA8.SA1" corresponding to IDF No. 8 (TKI # 8) is 7.0 minutes, the duration of the display of each of the OBI from No. 17 to No. 19 (РОВ017-РОВ019) is 2.33 (= 7.0 / 3) minutes.

{77-1} UP_IOB_ISVFU (DPLI_POB_SRP) and ATR_IOB_ISVFU (DPLI_POB_ATR), which are contained in OISVFU (DPLGI)

Whereas by means of UP_IOB_IDF (TKI_POB_SRPs) it is possible to indicate which IOBs (POBs) should be displayed on the screen when playing each soundtrack, by means of UP_IOB_ISVFU (DPLI_POB_SRPs) specified in OISVFU (DPLGI), the indication of those OBIs which on the screen during playback of multiple GOITT (AOW) should be performed in accordance with the order that is specified in the Information_of_list of reproducible_files_of_default (Default_Playlist_Information).

On Fig shown UP_IOB_ISVFU (DPLI_POB_SRPs) and ATR_IOB_ISVFU (DPLI_POB_ATRs) contained in OISVFU (DPLGI). It can be seen from this drawing that UP_IOB_ISVFU (DPLI_POB_SRPs) and ATR_IOB_ISVFU (DPLI_POB_ATRs) contained in OISVFU (DPLGI) have exactly the same data structure as UP_IOB_IDF (TKI_POB_SRPs) and ATROB_ATF_AT_ATF_AT_BAT_AT.

Since the reproduction order of a variety of GOITER files (AOW files) is specified by Default_Playlist_Information information_On the list of reproducible_files (Default_Playlist_Information), the DPLI_POB_SRPs and ATR_IOB_ISVFU shown in FIG. POBs) should be displayed on the screen during playback of a variety of GOITER files (AOW files), the playback order of which is specified in the Default_laylist_Information information_of_list_of_playable_files (Default), (2) in what order should suschestvlyat derivation of these OBI (POBs) on the screen, and (3) whether the output OBI (POBs) on the screen to be performed synchronously with reproduction of SCA (AOB) corresponding IDF (TKI).

{77-2_78} Example of setting the values of twenty UP_IOB_ISVFU (DPLI_POB_SRPs)

On Fig shows an example of setting the values of twenty UP_IOB_ISVFU (DPLI_POB_SRPs) contained in the Information_of the list of reproducible_files_of the default (Default_Playlist_Information). In the drawing, the first level shows Default_laylist_Information information_list_of_playable_files (Default_Playlist_Information), and within its framework, OISVFU (DPLGI) and twenty UP_IOB_ISVFU (DPLI_ROV_SRPs) are shown. At the second level, twenty IOB files (POB files) from IOB020 to IOB039 (POB020-POB039) are shown. As shown by the arrows, by means of twenty UP_IOB_ISVFU (DPLI_POB_SRPs), respectively, twenty OBI files (POB files) from IOB020 to IOB039 (POB020-POB039) are defined.

The IOB020 (POB020) file is an image that is used as the image on the packaging cover of a music album consisting of phonograms from Phonogram A (TrackA) to Phonogram D (TrackE), the IOB021 (POB021) file is the logo of the manufacturer that issued this music album. Files from IOB022 to IOB025 (POB022-POB025) are photos of the artist, files from IOB026 to IOB031 (POB026-POV031) are images taken from an advertising video, and files from IOB032 to IOB039 (POB032-POV039) are photos of an artist performing phonograms from Phonogram A (TrackA) to Phonogram D (TrackE) at a concert. UP_IOB_ISVFU (DPLI_POB_SRPs) in the Information_of_list of reproducible_files_of_default (Default_Playlist_Information) is set by the manufacturer of musical information content and, therefore, can be set so that during playback it is possible to display images corresponding to the phonograms of the image representing the contents of musical works, etc.

During the playback of GOITER files (AOW files), the playback order of which is specified in the Information_of_list_of the playable_files_of_default (Default_Playlist_Information), the screen will display those OBF files (DOM) that are specified by the UP_IOB_ISVFU (DPLI_POB_SRPLs) contained in the OIBFGIS. In the example shown in Fig. 40, in the Default_laylist_Information information on the list of reproducible_ files (Default_Playlist_Information), the playback order of five phonograms: from Phonogram A (TrackA) to Phonogram D (TrackE), is specified by eight IDFs (TKI) that form these phonograms. Meanwhile, in the example shown in Fig. 78, by means of the UP_IOB_ISVFU (DPLI_POB_SRPs) contained in this Information_of the list of reproducible_files_of the default (Default_Playlist_Information), twenty files of the OBI (DOM) are set, and such a task has the duration of playing back the background, equal to the duration of the background (TrackA) by Phonogram D (TrackE), which is 52.5 minutes. In the case when this playback time, equal to 52.5 minutes, needs to be divided equally between the files from OBI020 to IOB039 (POB020-POB039), each image will be displayed on the screen for 2.625 (= 52.5 / 20) minutes.

{77-3_79} Replacing foreground images and background images during playback

Fig. 79 is a timing chart showing which images are combined when POBs specified as the background images are indicated by the DP_IOB_SRPU (DPLI_POB_SRP) contained in the Default_playlist_file_information (Default_Playlist asInformation) in the foreground, use the OBI (POBs) specified by UP_IOB_IDF (TKI_POB_SRPs) contained in the phonogram manager (TrackManager).

In the drawing, the first level shows the same OBIs (POBs) as the second level of Fig. 78, and the second level shows the same OBIs (POBs) as the second level of Fig. 75 and Fig. 76 . A scale bar extending horizontally at the top of FIG. 79 indicates the duration of playback in units of minutes. Therefore, the horizontal size of each OBI (DOM) in Fig.79 indicates the time of continuous display on the screen of each OBI (DOM).

From the timeline of FIG. 79, it can be seen that during the time interval from the start of playback to the point corresponding to 6.1 minutes, files IOB001 to IOB003 (POB001-POB003) (representing the lyrics for Phonogram A) are sequentially displayed on the screen (TrackA)) as the images located in the foreground, and at the same time, the files IOB020 (POB020) (album cover image), IOB021 (POB021) (logo of the manufacturer), and IOB022 (POB022) ( picture artist a) serving as background images.

During the playback time, between the point corresponding to 6.1 minutes after the start of playback and the point corresponding to 14.9 (= 6.1 + 3.3 + 5.5) minutes after the start of playback, on the screen as images located on in the foreground, sequentially display files from IOB004 to IOB009 (POB004-POV009) (which are the words of songs for Phonogram B (TrackB) and Phonogram B (TrackC)), and at the same time, files from IOB022 to IOB025 (POV022 -ROV025) (artist's photos) serving as background images.

For a period of time after a point located 14.9 minutes from the start of playback, the files IOB010 to IOB011 (POB010-POB011) (representing the words of a song for Phonogram G (TrackD )), and at the same time, files from IOB026 to IOB028 (POB026-POB028) (representing images taken from an advertising video film) serving as background images are sequentially displayed on the screen.

{77-4_80}

In the time diagram of Fig. 79, the display of the cumulative image consisting of IOB004 (POB004) (song lyrics for Phonogram B (TrackB)) located in the foreground and IOB022 (POB022) (artist photo) located in the background carried out starting from a point located 6.1 minutes after the start of playback according to the Information_o_list_ of playable_files_of default (Default_Playlist_Information). On Fig shows how at this point, which is 6.1 minutes after the start of playback according to the Information_of the list of reproducible_files_of_default (Default_Playlist_Information), the combination of the image located in the foreground and the background image is performed.

{77-5_81}

In the same exact way, the display on the screen of an aggregate image consisting of IOB010 (POB010) (song words for Phonogram G (TrackD)) located in the foreground and IOB026 (POB026) (frame from an advertising video) located in the background starting from the point located 16 minutes after the start of playback according to the Information_of_list_of playable_files_of_default (Default_Playlist_Information). On Fig shows how at this point, located 16 minutes after the start of playback according to the Information_of the list of reproducible_files_of_default (Default_Playlist_Information), combine the image located in the foreground and the background image.

As described above, if the cumulative image is created by combining the OBI file (DOM) specified by UP_IOB_ISVFU (DPLI_POB_SRP) in the Information_of the playlist_of_default files (Default_Playlist_Information) as the image located in the foreground and the OBDI_ID (IDBI_ID file specified by in the Information_of_list_of_playable_files_of_default (Default_Playlist_Information) as the background image, the display of the song words on the screen for the reproduced phonogram can be carried out together with the photo fiey artist from the advertising video image for a soundtrack, concert photos, etc. The OBI (DOM) files set for display on the screen and the time for their display can also be easily changed by overwriting UP_IOB_IDF (TKI_POB_SRPs) and UP_IOB_ISVFU (DPLI_POB_SRPs) in the phonogram manager (TrackManager) and in the Playlist_Information_list in the Default_playlist.

{82-1} UP_IOB_ISVF (PLI_POB_SRPs) and АТР_ИОБ_ИСВФ (PLI_POB_ATR) in ОИСВФ (PLGI)

Contained in OISVF (PLGI) UP_IOB__ISVF (PLI_POB_SRPs) and ATR_IOB_ISVF (PLI_POB_ATR) have the same data structure as contained in OISVFU (DPLGI) UP_IOB_ISVFU (DPLI_POB_SRPs) and ATR_IOB_ISVFU (DPLI_POB_ATR), and how UP_IOB_IDF (TKI_POB_SRPs) and ATR_IOB_IDF (TKI_POB_ATR) at IDF (TKI). On Fig shown UP_IOB_ISVF (PLI_POB_SRPs) and ATR_OBI_ISVF (PLI_POB_ATRs) contained in OISVF (PLGI). As in the first embodiment, the ISVF (PLI) differs from the Default_laylist_Information information on the list of reproducible_ files (Default_Playlist_Information) in that it indicates the playback order specified by the user, while the UP_IOB_ISVF (PLI_POB_SRPs) and the ATR_IOB_IsVF (should be) (IOPSBRs (BEI), (should indicate on the screen during playback of a set of GOITER files (AOW files) specified in this user-defined playback order, in what order should these OBIs (POBs) be displayed on the screen and whether the OBIs (POBs) should be displayed on the screen with synchronously with the playback of the corresponding GOITER files (AOW files). It should be noted that despite the fact that, according to the above description, the setting of the default values of DP_IOB_ISVFU (DPLI_POB_SRPs) in the Information_of the list of reproducible_files_of_default (Default_Playlist_Information) is carried out by the producer of the musical information content, the values of these UP_IOB_ISVFF can be easily set by the users PLI_P themselves.

{82-2_83} Example of setting the values of UP_IOB_ISVF (PLI_POB_SRPs) contained in the ISWF (PLI)

The following is a description of an example of setting the values of UP_IOB_ISVF (PLI_POB_SRPs) contained in the ISVF (PLI).

On Fig shows one example of setting the values of twenty UP_IOB_ISVF (PLI_POB_SRPs) in ISVF (PLI). In the drawing, the first level shows the ISVF (PLI), and within the framework within it, the OISVF (PLGI) and twenty UP_IOB_ISVF (PLI_POB_SRPs) are depicted. At the second level, twenty IOB files (POB files) from IOB040 to IOB059 (POB040-POB059) are shown. As shown by the arrows, by means of twenty UP_IOB_ISVF (PLI_POB_SRPs), respectively, twenty OBI files (POB files) from IOB040 to IOB059 (POB040-POB059) are defined.

While the files IOB020 to IOB039 (POB020-POB039) are data on still images created by the music content producer, the files from IOB040 to IOB059 (POB040-POV059) are data on still images that are user-created personal photos. As an example, IOB040 (POB040) is a photograph of a user's family, and IOB041 (POB041) is a photograph of a graduation ceremony by a user of an educational institution, files from IOB042 to IOB045 (POB042-POB045) are photographs of a user's pet, files from IOB046 to IOB051 (ROB046-ROB051) are photographs taken by the user during a vacation spent in Europe, and files from OBI052 to OBB059 (ROB052-ROB059) are photographs taken by a user during a vacation spent in the USA. For ease of explanation, the total playing time of GOIT files (AOW files) specified by this ISVF (PLI) and the number of OBIs (POBs) set to be displayed on the screen by this ISVF (PLI) are the same as in the Default_playlist_file_information ( Default_Playlist_Information). This means that the total duration of the playback of phonograms from Phonogram A (TrackA) to Phonogram D (TrackE) indicated by this IFI (PLI) is 52.5 minutes, and that the display time of each file from ИОБ040 to ИОБ059 (РОВ040-РОВ059) on the screen is 2.625 (= 52.5 / 20) minutes in the event that during playback having this duration, each image should be displayed for the same time.

{82-3_84} Replacing foreground images and background images during playback

Fig. 84 is a timing chart showing which images are combined when the POBs indicated by the PLI_POB_SRP UP_IOB contained in the above Playlist_Information Information_Objects described above are used as background images, and in as the images located in the foreground, use the OBI (POBs) specified by UP_IOB_IDF (TKI_POB_SRPs) contained in the phonogram manager (TrackManager).

In the drawing, the first level shows the same OBIs (POBs) as the second level of Fig. 83, and the second level shows the same OBIs (POBs) as the second level of Fig. 75 and Fig. 76 . A scale bar extending horizontally at the top of FIG. 84 indicates the duration of playback in units of minutes. Therefore, the horizontal size of each OBI (DOM) in Fig. 84 indicates the time of continuous display on the screen of each OBI (DOM).

From the time scale of FIG. 79, it can be seen that during the time interval from the start of playback to the point corresponding to 6.1 minutes, files IOB001 to IOB003 (POB001-POB003) (representing the lyrics for Phonogram A ( TrackA)) as images located in the foreground, and at the same time, the files IOB040 (POB040) (family photos), IOB041 (POB041) (photographs of the graduation ceremony) and IOB042 (POB042) (photos of the house) are displayed on the screen sequentially his animal) that serve as background images.

During the playback time, between the point corresponding to 6.1 minutes after the start of playback and the point corresponding to 14.9 (= 6.1 + 3.3 + 5.5) minutes after the start of playback, on the screen as images located on in the foreground, sequentially display files from IOB004 to IOB009 (POB004-POV009) (which are the words of songs for Phonogram B (TrackB) and Phonogram B (TrackC)), and at the same time, files from IOB042 to IOB045 (POB042) are sequentially displayed on the screen -RO045) (photographs of a pet) serving as TBE background images.

For a period of time after a point located 14.9 minutes from the start of playback, the files IOB010 to IOB011 (POB010-POB011) (representing the words of a song for Phonogram G (TrackD )), and at the same time, the file IOB045 and files from IOB046 to IOB048 (POB045, POB046-POB048) (photographs taken during a vacation spent in Europe) are used as background images on a screen.

Thus, despite the fact that the selection of OBIs (POBs) specified by Default_playlist_Information is performed by a record company that creates musical information content, and they usually represent artist’s images and images associated with musical content, the user can make arbitrary choices OBIs (POBs) defined by IFI (PLI), and therefore, they can be highly personalized.

{82-4_85}

In the time diagram of FIG. 84, the cumulative image consisting of IOB004 (POB004) (song words for Phonogram B (TrackB)) located in the foreground and IOB042 (POB042) (photograph of a pet) located in the background is displayed in a screen starting from a point located 6.1 minutes after the start of the above-described playback according to the information of the Playlist_Information file. On Fig shows how to combine the image located in the foreground, and the background image at this point, located 6.1 minutes after the start of playback according to this Information_of the list of playable files (Playlist_Information).

{82-5_86}

In the same way, the aggregate image consisting of IOB010 (POB010) (song words for Phonogram G (TrackD)) located in the foreground and IOB046 (POB046) (photograph taken during a vacation spent in Europe) is displayed on the screen. located in the background, starting from the point located 16 minutes after the start of playback according to this Information_of the list of playable files (Playlist_Information). On Fig shows how to combine the image located in the foreground, and the background image at this point, located 16 minutes after the start of playback according to this Information_of_list_of the playable files (Playlist_Information). Song words that form part of these aggregate images are the same as in Fig. 80 and Fig. 81, but since the background images are different, the aggregate images in Fig. 85 and Fig. 86 have a completely different look compared with images in Fig. 80 and Fig. 81.

As described above, by means of user-defined UP_IOB_ISVF (PLI_POB_SRPs) in the ISVF (PLI), it is possible to specify IOB files (POW files), which differ from those specified by the Default_laylist_Information_playable_list_ information (Default_Playlist_Information), and therefore, the user can display it on any screen images when playing his / her favorite phonograms.

{82-6_87} Example of setting the same OBIs (POBs) in UP_IOB_ISVFU (DPLI_POB_SRPs) from the Information_of_list of reproducible_files_of_default (Default_Playlist_Information)

In the examples shown in Fig. 78, Fig. 79, Fig. 82 and Fig. 83, all UP_IOB_ISVFU (DPLI_POB_SRPs) contained in the Default_playlist_Information information_of_list_of_play_files (Default_Playlist_Information) indicate various OBI files (POB files), although it is possible to two or more UP_IOB_ISVFU (DPLI_POB_SRPs) from the Information_of_list of reproducible_files_of_default (Default_Playlist_Information) one and the same file of OBI (DOM file) is specified. By means of this, the same OBI file (DOM file) can be displayed on the screen for the duration of the reproduction of many phonograms, which reduces the number of OBI files (DOM files) that the producer of the recording of a musical work must create. This reduces the time and cost required to create a record of a piece of music.

On Fig shows one example in which the number of OBI files (DOM files) is reduced due to the fact that one and the same OBD file (DOM file) is indicated by the UP_IOB_ISVFU part (DPLI_POB_SRPs) from the Default_laylist_Information information_of_list (Default_Playlist_Information). In this drawing, IOB020 (POB020) is indicated by both UP_IOB_ISVFU No. 1 (DPLI_POB_SRP # 1) and UP_IOB_ISVFU No. 4 (DPLI_POB_SRP # 4), and IOB021 (POV021) is indicated by UP_IOB_ISVFU 2 and (UP_IOB_ISVFU 2 and (IOFB_ISVFU2 and (IOFF_ISVFU2 and No. 5 (DPLI_POB_SRP # 5).

{82-7_88} Replacing front-facing images and background images during playback

Fig. 88 is a timing chart showing which images are combined when POBs are used as background images as described above by the DPLI_POB_SRP UP_ID contained in the Default_playlist_file_information (Default_Playlist) images located in the foreground, use the OBI (POBs) specified by UP_IOB_IDF (TKI_POB_SRPs) contained in the phonogram manager (TrackManager).

And this time chart shows that the display on the screen of IOB020 (POB020), which is an image on the cover of the product’s packaging, is carried out only three times, namely at the beginning of playback, 7.875 minutes after the start of playback and 15.75 minutes after the start of playback. Similarly, the display on the screen of IOB021 (POB021), which is the logo of the record company, is carried out only three times, namely after 2.625 minutes, after 10.5 minutes and after 18.375 minutes after the start of playback. In the case when the values UP_IOB_ISVFU (DPLI_ROV_SRPs) are set as shown in Fig. 87, then the same OBI (DOM) is repeatedly displayed on the screen, therefore, it is possible to repeatedly display images intended for repeated use, for example , cover art for a music album or record company logo.

This completes the description of the UIFG, OISVFU and OISVF (TKGI, DPLGI, PLGI).

(69-4_89) ADIOB (POBMG)

The following is a description of the administrator OBI (ADIOB) (POBManager (POBMG)), which is a new element that is created in the navigation information in the second embodiment. On Fig shows the structure of ADIOB (POBMG).

As shown in the drawing, the ADIOB (POBMG) consists of information about the management of the OBI (IIOB) (POBMGI) and information about the countdown of the OBI (IOBI) No. 1, No. 2, ... No. n ((РОВСI) # 1, # 2. .. #n).

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

As shown by dashed lines in FIG. 89, the OBI control information (IIOBI) (POBMGI) contains information about the IUIID identifier (POBMGI) that occupies from the 0th and 1st bytes, a reserved field that occupies the 2nd and 3 fields, the field NUMBER (number of OBIs) (ROW_Ns), which occupies the 4th and 5th fields, and the reserved field, which occupies the 6th and 7th fields.

The identifier (character set code "A6" according to the IS0646 standard), which uniquely identifies the IIOBI (POBMGI), is recorded in the information field of the IISSI identifier (POBMGI). In the field POB_Ns (POB_Ns) write the number of OBI (POBS), which takes a value in the range from "0" to "999". This completes the description of the IIOBI (POBMGI).

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

The following is a description of the information on the OBI counting (IOBI) (POBCI). Information about the OBI counting is the control information that is created separately for each OBI (DOM). The bitwise structure of the information on the OBI count (DOM) is shown in FIG. 89 in dashed lines. That is, the information on the OBI count contains the field "KS_IOV" (the number of links to the OBI) (POB_RCN), which occupies the area from the bit having the number b0 to the bit having the number b9, a reserved field that occupies the area from the bit having the number b0 to b13, and a data existence field that spans from a bit having a number b14 to a bit having a number b15.

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

Field "KS_OBI" (number of links_to_OBI) (POB_RCN) indicates whether specified by OISVFU (DPLGI), OISVF (PLGI), or UIFG (TKGI) designed to display on the screen IOB (DOM), which corresponds to the IOIB (POBCI). In the case when the corresponding OBI (DOM) is specified, the number of links in which it is specified, that is, the number of IDFs (TKI) in which the OBI (DOM) is set to be displayed on the screen, is written as a number taking values in range from "1" to "999".

As in the first embodiment of the invention, IDF (TKI) can be deleted and, therefore, the set parameters in the Default_Playlist_Information and List_Playlist Information (Playlist_Information) can be easily changed by users. In case of removal of one or more IDFs (TKIs) in which a specific OBI (DOM) is indicated, for this OBI (DOM) it is necessary to reduce the number of links to the OBI (DOM reference count) in accordance with the number of removed IDFs (TKI), in which he was indicated. Also, when deleting Information_of_list_of_playable_files_of_default (Default_Playlist_Information) or ISVF (PLI), the value of КС_ИОБ (РОВ_RCN) should be reduced by the number of deleted IDFs (TKI) in which this IOB is indicated.

In the case when the OBI (DOM) is not specified in the OISVFU (DPLGI), OISVF (PLGI), or OIFG (TKGI), the value of the Number of references to the IOB (POV_reference_count) is set to "0". Since the call to the OBI (DOM), the Number of links to the OBI (DOB_reference_count) of which is "0", is not carried out by means of an IDF (TKI) or a list of playable files, when deleting an IDF (TKI) or a list of playable files, the playback device can detect those IOBs (POBs) , The number of POB_reference_count links which become equal to zero, and delete the POB files in which such POBs are stored, which reduces the amount of data on still images recorded in the flash memory board.

In the event that some POBs relate only to certain phonograms and displaying such POBs on the screen makes sense only when playing the corresponding phonograms, then, in order to avoid the uneconomical use of the memory capacity of the flash memory card, such IOBs can be deleted (POBs) in the case when the number of_references to them (reference_count_number) becomes equal to zero. This may also apply to POBs, which are song words for phonograms recorded on a flash memory card.

In addition to the case in which one or more IDFs (TKIs) are deleted, a decrease in the number of links (reference_count_number) can be performed in the same way when deleting the OBI (DOM) specified in DP_IOB _ISVFU (DPLI_POB_SRP), UP_IOB_ISVF (PLI_POB_SRP) and or in UP_IOB_IDF (TKI_POB_SRP), through an editing operation.

{69-4_89-4} Data Existence Field

The value of the "data existence" field, which occupies the area from bit number b14 to bit number b15, is set to indicate whether there is indeed an OBI (DOM) that corresponds to this number of the OBI (DOM). In the case when the corresponding OBI (DOM) exists, in this field set the binary value equal to "01", and in the case when such an OBI (DOM) does not exist, set the value to "00". Here, data is considered “existing” if there is data that is of value in itself.

When this field indicates that the OBI (DOM) exists, and the deletion of the IDF (TKI) or ISVF (PLI) has led to the value of the Number_link_to_OBI (POB_reference_count) reached "0", the playback device decides that the OBI (DOM) ), corresponding to the zero value of the Number of links_to_IOB (POB_reference_count), must be saved and, therefore, the OBI (DOM) will not be deleted.

If the OBI (DOM), which is of value in itself, regardless of whether there is a link to it in the IDF (TKI) or ISWF (PLI), then in the data existence field corresponding to this OBI (DOM), a value equal to " 1". By setting the value to "0" in the data existence field corresponding to the OBI (POBs), which are valuable only if there is a link to them in the IDF (TKI) or in the list of playable files, it becomes possible to selectively save to the flash memory board only those OBIs (POBs) that are of value in themselves. Those OBIs (POBs), the display of which on the screen makes sense only when it is carried out together with the playback of the phonogram (that is, those OBIs (POBs) that do not represent value in themselves), can be deleted by deleting the corresponding phonogram, which allows make good use of the memory capacity of the flash memory card.

This concludes the description of the administrator of the OBI (ADIOB) (POBManager (POBMG)).

{69-5} Update related to IDF editing (TKIs)

The following is a description of how UP_IOB_IDF (TKI_POB_SRPs) and UP_IOB_ISVFU (DPLI_POB_SRPs) are updated in the following five cases. The first four cases are the same as in the first embodiment, so that in the first case (Example 1), the phonogram is deleted. In the second case (Example 2), a phonogram is deleted and a new phonogram is recorded. In the third case (Example 3), two of the many phonograms are selected and combined into one phonogram. In the fourth case (Example 4), one phonogram is separated and two phonograms are created. In the fifth case (Example 5), the playback order of the phonograms is changed.

In Example 1, in which the phonogram is deleted, the value of each IDF (TKI) corresponding to the phonogram is set to "Unused" and the UP_IOB_IDF (TKI_POB_SRPs) in each IDF (TKI) is deleted. At the same time, the value of the Number of references_to_OBI (POB_reference_count) in the administrator of the IOB (POBManager) of those IOBs (POBs) that are indicated by these UP_IOB_IDF (TKI_ROV_SRPs) is reduced. This deletion does not affect those OBIs (POBs) that are specified by UP_IOB_ISVF (PLI_POB_SRPs) and / or UP_IOB_ISVFU (DPLI_POB_SRPs) in OISVFU (DPLGI) or OISVF (PLGI).

In the case when the UP_FG_SVFU (DPL_TK_SRPs) is changed in such a way that they indicate a different order of phonograms (Example 5), then the playback order of the phonograms will change, and the display order of the POBs indicated by UP_IOB _IDF will also be changed (TKI_POB_SRPs).

In Example 3, a preferred embodiment is one in which the UP_IOB_IDF (TKI_OP_SRPs) are also combined into an IDF (TKI). This is due to the fact that for a phonogram consisting of a set of IDFs (TKI), only UP_IOB_IDF (TKI_POB_SRPs) in the first IDFs (TKI) are valid. After performing the operation of combining phonograms, it is necessary to indicate from the first IDFs (TKI) from the first IDFs (TKI) those IOBs (POBs) that are specified by UP_IOB_IDF (TKI_OP_SRPs) of the second IDFs (TKI).

When dividing a phonogram (Example 4), it is necessary to change the ATR_BLK_IDF (TKI_BLK_ATR) phonograms and to separate TPFGPVR (TKTMSRT) and TIB (BIT) as described in the first embodiment. In addition, it is also necessary to divide UP_IOB_IDF (TKI_POB_SRPs) specified in the UIFG (TKGI) into two groups, which are assigned, respectively, to the old IDF (TKI) and the new additional IDF (TKI), which were created by splitting.

{69-6} An example of practical use of UP_IOB_IDF (TKI_POB_SRPs) and UP_IOB_ISVFU (DPLI_POB_SRPs)

As described above, the data structure of the administrator of phonograms (TrackManager) and administrator of the list of playable files (PlaylistManager) allow the user to arbitrarily change the relationship between the files GOITER (AOW files) and OBI (POBS) by changing the set values UP_IOB_IDF (TKI_POB_SRPs) UP_IOB_ISVFU (DPLI_POB_IFFOBsSRIBS (PLI_ROV_SRPs). This means that the producer of musical information content can supply consumers with musical information content with various amounts of data about still images, for example, phonograms with song words, phonograms without song words and phonograms with song words and background images. It goes without saying that a producer can charge different prices for these different types of information content.

In the case where the consumer wants to purchase phonograms without the words of the songs, the manufacturer can create a catalog of IZD (SD_Audio), which contains eight GOITERS (AOB) described in the first embodiment, and the administrator of the phonograms (TrackManager), in which, as shown on Fig, through UP_IOB_IDF (TKI_POB_SRPs) in IDF No. 1 through No. 8 (TKI # 1-TKI # 8), the IOB from IOB020 to IOB039 (POB020-POB039) are set. Then the manufacturer compresses this directory, encrypts it and transfers it to the consumer’s personal computer. It should be noted that instead of this, the consumer’s personal computer can download phonograms (GOITTs) (AOB) and still images (OBIs) (POBs) corresponding to phonograms from a computer server managed by a recording company and generate a CD catalog (SD-Audio ) shown in FIG. 70A and FIG. 70B in the flash memory board 31.

In the case when the consumer wants to purchase phonograms with the words of songs, the manufacturer can create a catalog of EDI (SD_Audio), which contains eight GOITERS (AOB) described in the first embodiment, and the administrator of phonograms (TrackManager), in which, as shown on Fig and Fig, through UP_IOB_IDF (TKI_POB_SRPs) in IDF from No. 1 to No. 8 (TKI # 1-TKI # 8) are set IOB IOB001 to IOB019 (POB001-POB019), which correspond to the words of the songs. Then the manufacturer compresses this directory, encrypts it and transfers it to the consumer’s personal computer.

In the case when the consumer wants to purchase phonograms with both song words and background images, the manufacturer can create a catalog of IZD (SD_Audio), which contains eight GOITERS (AOW) described in the first embodiment, the administrator of phonograms (TrackManager) in which, as shown in Fig. 75 and Fig. 76, by UP_IOB_IDF (TKI_POB_SRPs) in the IDF No. 1 through No. 8 (TKI # 1-TKI # 8), the OBIs IOB001 through IOB019 (POB001-POB019) are set corresponding to words of songs, and the administrator of the list of playable files, in which by means of UP_IOB_ISVFU (DPLI_POB_SRPs) are set IO B with IOB020 to IOB039 (POB020-POB039) shown in Fig. 78. Then the manufacturer compresses this directory, encrypts it and transfers it to the consumer’s personal computer. Since in the present embodiment, still image data can easily be mapped to sound data by setting the values of UP_IOB _IDF (TKI_POB_SRPs), UP_IOB_ISVFU (DPLI_POB_SRPs) and UP_IOB_ISVF (PLI_POB_SRPs), music information content can be easily created to match the content with the number of still image data attached to it.

{90-1_91} Playback device for a second embodiment of the invention

The following is a description of a reproducing apparatus for the second embodiment. This reproduction apparatus differs from the reproduction apparatus described in the first embodiment in that while the reproduction apparatus in the first embodiment is portable, the reproduction apparatus of the second embodiment is intended to be installed in a car 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 itself.

The reproducing apparatus of this second embodiment differs from the reproducing apparatus of the first embodiment in that it is mounted in a car as shown in FIG. 90 in that it comprises a large LCD panel 5 and in that it is connected to the speakers a car. Due to the presence of a large LCD panel 5, the reproducing apparatus of this second embodiment is well suited for displaying on the screen the various types of still image data mentioned above.

The second difference from the playback device according to the first embodiment is that the playback device according to the second embodiment has a random sequence decoder 7 that can decrypt both encrypted audio data and encrypted IOBs (POBs). In the event that the OBI (DOM) was encrypted and stored in the form of an OBI file (DOM file) with the file name "ROVXXX.SP1", the file key (FileKey) stored in the Record on access to the file key in the encrypted key storage file "POBSP1.KEY", set in the decoder 7 random sequences, through which then decrypt the file "ROVXXX.SP1".

The third difference from the playback device according to the first embodiment is that in the playback device according to the second embodiment, a program is stored that contains the processing necessary to display the OBIs (POBs) in the form of foreground images or background images images. The execution of this program for displaying images on the screen is carried out by the CPU 10 of this playback device.

{90-2_92_93_94}

The following is a description of the structure of the reproducing apparatus of this second embodiment. The structure of the reproducing apparatus shown in FIG. 92 differs from the structure of the reproducing apparatus of the first embodiment in that it comprises a plurality of video RAM 61 (VRAMs).

Many RAM 61 for video images (VRAMs) aligned with the corresponding single graphic planes (layers). Video RAM (VRAM) for the graphics plane has transparency α, the value of which for each image element (pixel) is set in the range from 0 to 100%. The image intended to be displayed on the screen of the first LCD panel 5 is calculated according to the equation below. On Figa shows how to combine the still images stored in the set of RAM 61 for video images (VRAMs).

THE EQUATION

Pixel value for each pixel =

Graphics pixel value 0 * (1-α)

+ Pixel value in the graphic plane 1 * a

For those parts of the foreground image that correspond to the letters representing the words of the song, the transparency α is set to 0%. As a result, those parts of the background image, the location of which corresponds to the lines of letters representing the words of the song, are completely hidden. And vice versa, for those parts of the image located in the foreground that correspond to the usual background of song words, the transparency α is set to 100%. This means that the display on the screen of the lines of letters contained in the total image representing the words of the song, which are located in the graphic plane 0, is carried out on top of the background image located in the graphic plane 1.

By setting transparency in this way, you can create an aggregate image in which a page with the words of the song is overlaid on top of the background image, as shown in Fig. 80 and Fig. 81. It should be noted that the aggregate image can also be created by methods different from that shown in Fig. 93A. As one example, which is shown in Fig. 93B, the words of the song can be located at the bottom of the screen, and the output of the background image is carried out at the top.

{94-1} Flowchart of a procedure for displaying an image located in the foreground

Fig. 94 is a flowchart showing a procedure for displaying an image in the foreground. At the beginning of the reproduction, which is carried out according to IDF No. z (TKI # z) indicated by Default_Playlist_Information, information on the list of reproducible_files, in step S402, the CPU 10 makes a decision on whether it is indicated by the ID_IOB_IDF (TKI_POB_SRPs) contained in the IF IDI (GI IDF) No. z (TKI # z), any OBI (POBs). In the case when one or more OBI files (POB files) are indicated by UP_IOB_IDF (TKI_POB_SRPs), then the processing procedure proceeds to operation S403, in which CPU 10 counts the number of OBI files (POB files), which is indicated by UP_IOB_IDF (TKI_POB_SRPs ) contained in OIFG (TKGI). In step S404, the CPU 10 calculates a display time on the "POB_time" screen indicating a used display time of each OBI file (POB file) on the screen. After that, in step S405, he calls ATR_IOB_IDF (TKI_ROV_ATR) in OIFG (TKGI) and determines the display mode on the screen used to display the OBI files (POV files) on the screen. In the case when the sequential mode is specified in ATR_OBI_IDF (TKI_POB_ATR), the processing procedure proceeds from operation S405 to operation S406, in which the variable i is initialized, and to operation S407, in which the OBI file (POM file) is displayed on the screen specified by the i-th UP IOB_IDF (TKI_ROV_SRP), during the display time on the screen Time_OB (IDB_time).

If at this point the OBI file (DOM file) specified by UP_IOB_IDF (TKI_POB_SRP) has the extension "JPG", then the OBI (DOM) is displayed directly on the screen. Otherwise, if the OBI file (DOM file) specified by UP_IOB_IDF (TKI_POB_SRP) has the extension "SP1", this means that the OBI file (DOM file) is in an encrypted state, so CPU 10 reads the file key (FileKey ), corresponding to the OBI file (DOM file), from the protected area, decryption of the OBI file (DOM file) using the encryption key and the display of the OBI (DOM) on the screen.

After that, in step S408, the CPU 10 makes a decision on whether the variable i has reached the value specified in POB_Ns. If this is not so, then the processing procedure proceeds to step S409, in which the variable i is incremented, and then returns to step S407. Then, the processing by operations S406 to S409 is repeated until the variable i reaches the value specified in POB_Ns. As a result, sequential display on the screen of those OBIs (POBs) that are indicated by UP_IOB_IDF (TKI_ROV_SRPs) in UIFG (TKGI). When the variable i reaches the value specified in POB_Ns, the processing in this flowchart ends.

In the case when a random mode is specified in ATR_IOB_IDF (TKI_POB_ATR), the processing procedure proceeds from operation S405 to operation S410, in which the variable i is initialized, and to operation S411, in which the CPU 10 generates a random number r in the range from 1 to NUMBER_OB (POB_Ns). In step S412, the OBI file (POB file) indicated by the rth UP_IOB_IDF (TKI_POB_SRP) corresponding to the random number r is displayed on the screen during the display time on the POB_time screen that was determined in step S404.

After that, in step S413, the CPU 10 makes a decision on whether the variable i has reached the value set in POB_Ns. If not, then the processing procedure proceeds to operation S414, in which the variable i is incremented, and then returns to operation S411. In step S411, the CPU 10 generates another random number r in the range from 1 to POB_Ns, and in the processing procedure, they again proceed to step S412, in which the CPU 10 reads the OBI file (POB file), which is indicated by r- th UP_IOB_IDF (TKI_POB_SRP) corresponding to a random number r, and displays it on the screen during the display time on the screen Time_IOB (POV_time), which was determined in step S404.

As described above, if the OBI file (DOM file) specified by UP_IOB_IDF (TKI_POB_SRP) has the extension "JPG", then the OBI (DOM) is displayed directly on the screen. Otherwise, if the OBI file (DOM file) specified by UP_IOB_IDF (TKI_POB_SRP) has the extension "SP1", this means that the OBI file (DOM file) is in an encrypted state, so CPU 10 reads the file key (FileKey ), corresponding to the OBI file (DOM file), from the protected area, decryption of the OBI file (DOM file) using the encryption key and the display of the OBI (DOM) on the screen.

After that, the processing by operations S411 to S414 is repeated until the variable i reaches the value specified in POB_Ns. As a result, sequential display on the screen in random order of those OBIs (POBs), which are indicated by UP_IOB_IDF (TKI_POB_SRPs) in UIFG (TKGI). When the variable i reaches the value specified in POB_Ns, the processing in this flowchart ends.

In the case where the permutation mode is specified in ATR_IOF_IDF (TKI_POB_ATR), the processing procedure proceeds from operation S405 to operation S415, in which the variable i is initialized, and to operation S416, in which the CPU 10 generates a random number r in the range from 1 to NUMBER_OB (POB_Ns).

In step S418, the CPU 10 checks whether the new random number r obtained as a result of the generation coincides with one of the used OBI numbers (DOM) that were previously stored. If it matches, then the processing procedure returns to operation S416, in which the random number r is regenerated. If it does not match, then the processing procedure proceeds from operation S418 to operation S419, in which the screen displays the OBI file (POB file) indicated by the rth UP_IDB_IDF (TKI_POB_SRP) corresponding to a random number r during the display time on the OBI Time (POB_time) screen that was determined in step S404. After that, in step S417, the CPU 10 stores the random number r as the used OBI (DOM) number.

As in random mode, if the OBI file (DOM file) specified by UP_IOB_IDF (TKI_POB_SRP) has the extension "JPG", then the OBI (DOM) is displayed directly on the screen. Otherwise, if the OBI file (DOM file) specified by UP_IOB_IDF (TKI_POB_SRP) has the extension "SP1", this means that the OBI file (DOM file) is in an encrypted state, so CPU 10 reads the file key (FileKey ), corresponding to the OBI file (DOM file), from the protected area, decryption of the OBI file (DOM file) using the encryption key and the display of the OBI (DOM) on the screen. At the end of this output, the operation S420 is performed, in which the CPU 10 makes a decision on whether the variable i has reached the value set in POB_Ns. If this is not so, then the processing procedure proceeds to operation S421, in which the variable i is incremented, and then return to operation S416. After that, the processing performed by operations S416 to S421 is repeated until the variable i reaches the value specified in POB_Ns. When the variable i reaches the value specified in POB_Ns, the processing in this flowchart ends.

{95-1} Flow chart of background image display procedure

Above was a description of the procedure for displaying an image located in the foreground, and below is a description of a procedure for displaying a background image on a screen. A flow diagram for a procedure for displaying a background image is shown in FIG. 95. This flowchart contains essentially the same processing procedure as the flowchart of FIG. 94, and instead of UP_IOB_IDF (TKI_POB_SRPs) and ATR_IOB_IDF (TKI_POB_ATRs) in UIFG (TKGI) processing is carried out according to UP_IOB_ISVFU (DPI) (DPI) and ATR_IOB_ISVFU (DPLI_POB_ATR) in OISVFU (DPLGI).

In the case that the Default_Playlist_Information information is selected, the CPU 10 performs processing by performing operations S502 through S505. As in operations S402 through S405, the CPU 10 decides whether any IOBs (POBs) are indicated by the DPLI_POB_SRPs contained in the DPLGI. In the event that one or more OBI files (POB files) are specified, the CPU 10 counts the number of specified OBI files (POB files), calculates the display time on the "POB_time" screen, indicating the duration used to display each file on the screen OBI (DOM file), and then determines the display mode on the screen used to display the OBI files (DOM files) on the screen.

When sequential mode is specified in ATR_IOB_ISVFU (DPLI_POB_ATR), the CPU 10 performs operations S506 through S509. As with operations S406 to S409, the display of the OBI files (DOM files) on the screen is carried out sequentially in the order corresponding to the UP_IOB_ISVFU (DPLI_POB_SRPU) contained in the OISVFU (DPLGI), which is indicated by the variable i.

In the case when a random mode is specified in ATR_IOB_ISVFU (DPLI_POB_ATR), the CPU 10 performs operations S510 through S514. As with operations S410 to S414, the display of the OBI files (DOM files) on the screen is carried out in random order in accordance with the UP_IOB_ISVFU (DPLI_POB_SRPU) (DPLI_POB_SRPs) contained in the OISVFU (DPLGI), which is indicated by a random number r .

In the case when the ATR_IOB_ISVFU (DPLI_POB_ATR) indicates the permutation mode, the CPU 10 performs operations S515 through S521. As with operations S415 to S421, the display of the OBI files (DOM files) on the screen is carried out in random order without repeating in accordance with the UP_IOB_ISVFU (DPLI_POB_SRP) from UP_IOB_ISVFU (DPLI_POB_SRPs) contained in the OISVFU (DPLGI), which is indicated by random numbers r.

{96-1} Flow chart of the procedure for displaying a background image

This completes the description of the procedure for displaying the background image, which is performed using UP_IOB_ISVFU (DPLI_POB_SRPs) in OISVFU (DPLGI). The following is a description of the procedure for displaying a background image, which is performed using UP_IOB_ISVF (PLI_ROV_SRPs) in OISVF (PLGI). Fig. 96 is a flowchart showing a procedure for displaying a background image using UP_IOB_ISVF (PLI_ROV_SRPs). With the exception of procedures based on the use of UP_IOB_ISVFU (DPLI_POB_SRPs), which are performed using the UP_IOB_ISVFU (PLI_POB_SRPs), this flowchart is exactly the same as the flowchart of FIG. 95, therefore, the same reference numbers are assigned to the operations . Explanation Fig. 96 will not be given.

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

The drawings of FIG. indicated by OISVFU (DPLGI), is carried out according to the display procedures shown in the flowcharts of Fig.94 and Fig.95.

In the example of FIG. 97A, it is assumed that the user specifies Default_Playlist_Information_list_of_playable_files (Default_Playlist_Information) and that the display of the OBIs (POBs) on the screen starts in accordance with the playback order specified in this list of playable files. By performing the procedure for displaying the image located in the foreground, which is shown in Fig. 94, and the procedure for displaying the background image, which is shown in Fig. 95, the screen displays one after the other OBIs (POBs) indicated by UP_IOB_IDF (TKI_POB_SRPs) in OIFG (TKGI) as intended for display on the screen, and OBI (POBs) indicated by UP_IOB_ISVFU (DPLI_POB_SRPs) in OISVFU (DPLGI) as intended for display on the screen. At a point located six minutes after the start of playback, the images are combined as shown in Fig. 80, and the combined image shown in Fig. 97B is displayed on the LCD panel 5.

At a point located sixteen minutes after the start of playback, the images are combined as shown in Fig. 81, and the combined image shown in Fig. 97B is displayed on the LCD panel.

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

The drawings of Fig. 98A to Fig. 98B show which combined images are displayed on the LCD panel 5 in the case where the display of the image located in the foreground, which is indicated by UP_IOB_IDF (TKI_OP_SRP), and the background image, indicated by UP_IOB_ISVF (PLI_POB_SRP), carried out according to the display procedures shown in the flowcharts of Fig.94 and Fig.96.

In the example of FIG. 97A, it is assumed that the user has indicated the IFI (PLI) and that the display of the OBIs (POBs) on the screen is started in accordance with the playback order that is specified in this playlist. By performing the procedure for displaying the image located in the foreground, which is shown in Fig. 94, and the procedure for displaying the background image, which is shown in Fig. 96, the screen displays one after the other OBI (POBs) indicated by UP_IOB_IDF (TKI_POB_SRPs) in OIFG (TKGI) as intended for display on the screen, and OBI (POBs) indicated by UP_IOB_ISVF (PLI_POB_SRPs) in OISVF (PLGI) as intended for display on the screen. At a point six minutes after the start of playback, the images are combined as shown in Fig. 85, and the combined image shown in Fig. 89B is displayed on the LCD panel 5. At a point located sixteen minutes after the start of playback, the images are combined as shown in Fig. 86, and the combined image shown in Fig. 98B is displayed on the LCD panel 5.

{99_1} Recording device of the second embodiment of the invention

The following is a description of the recording apparatus of this second embodiment. This recording device differs from the recording device of the first embodiment in that it can write to the flash memory card a plurality of OBIs (POBs) and perform parameter setting in UP_IOB_IDF, UP_IOB_ISVFU and UP_IOB_ISVF (TKI_POB_SRPs, DPLI_POB_SRPs, PLI_POB_SRPs, and also setting, in ATR_IOB_IDF, ATR_IOB_ISVFU and ATR_IOB_ISVFU (TKI_POB_ATR, DPLI_POB_ATR, PLI_POB_ATR).

To implement these operations, the CPU 10 in the recording device of this second embodiment performs the procedure shown in FIG. The following is a description of the recording procedure performed by the recording apparatus of this second embodiment, with reference to the flowchart shown in FIG.

In step 3601, the CPU 10 initializes the various variables used in this procedure. These variables are: "x", "y", "z", "u", "vy" and "w" (# x, # y, #z, #u, #vy, #w). Of these, the variable "x" (# x) is used to indicate the currently processed OBI (DOM), the variable "y" (# y) is used to indicate the currently processed phonogram sequence (ISWF) (PLI), and the variable " z "(#z) is used to indicate the currently processing phonogram (IDF) (TKI). The variable "u" (#u) determines which of the UP_IOB_ISVFU (DPLI_ROV_SRPs) are currently processing, and the variable "vy" (#vy) determines which of the UP_IOB_ISVFU (PLI_POB_SRPs) in the ISVF No. (PLI # y) specified by the variable "Y" (# y) is processed at the current time. The variable "w" (#w) determines which UP_IOB_IDF (TKI_POB_SRPs) in the IDF No. z (TKI # z) indicated by the variable "z" (#z) are being processed at a given time.

After the initialization of these variables, the CPU 10 proceeds to operation S602, in which it performs the display on the screen of the OBI No. x (ROV # x). This allows the user to visually confirm the photo, picture or page with the words of the song from this OBI (DOM). In step S603, the CPU 10 asks the user to indicate whether data on still images from the OBI No. x (DOM # x) should be displayed on the screen during the entire sequence of phonograms or only during the duration of the playback of a particular phonogram, and then receives data on the user produced choosing.

In the case when the user decides that the OBI No. x (DOM # x) should be assigned a sequence of phonograms, then perform operation S604, in which the CPU 10 expects data about the user indicating the sequence of phonograms for which the OBI No. x should be displayed (DOM # x) on the screen. When the user enters data on his / her choice, the processing procedure proceeds to operation S605, in which the CPU 10 decides whether the indicated sequence belongs to the ISVFU (DPLI) or ISVF phonograms (PLI). In the case when the sequence No. (phonogram #y) of the phonograms is an ISVFU (DPLI), then the processing procedure proceeds to step S606, in which the IOB No.x (DPLI_POB_SRP # u) is set to the IOB No.x (POB # x ), and then - to perform operation S607, in which, on the basis of this OBI No.x (DOM # x), the value ATR_IOB_ISVFU No. u (DPLI_POB_ATR # u) is set in the ISVFU (DPLI).

After the values UP_IOB_ISVFU (DPLI_POB_SRP) and ATR_IOB_ISVFU (DPLI_POB_ATR) are set in this way, the CPU 10 increments the variable "and" (# u ← # u + 1), and when performing operation S609, the variable "x" (# x ← # x + 1).

In the case when the ISWF (PLI) was selected in step S605, the processing procedure proceeds to step S610, in which the OBI No. (PLI # y) is set in the IWF ISVF No.vy (PLI # yy) (PLI # y) No. х (РОВ # х), and to perform operation S611, in which the value АТР_ИОБ_ИСВФ No.vy (PLI_POB_ATR # vy) is set for this ISWF (PLI) on the basis of ИОБ No.х (РОВ # х). After that, before proceeding to operation S609, in which the variable # x (# x ← # x + 1) is incremented, operation S612 is performed in which the CPU 10 increments the variable "vy" (# vy ← # vy + 1 )

In the event that, in step S603, the user decides that the OBI No. x (POB # x) should be assigned to a particular phonogram, then the processing procedure proceeds to step S613, in which the CPU 10 receives the user's instructions regarding this particular phonograms. Then, in step S614, the CPU 10 sets the OBI No.x (POB # x) in UP_IOB_IDF No. w (TKI_POB_SRP # w), the values of which are set for IDF No. z (TKI # z) of the specified phonogram (phonogram No. z) (track # z )

Then, the processing procedure proceeds to operation S615, in which the CPU 10, on the basis of the OBI No. x (ROV # x) sets the value ATR_IOB_IDF No. w (TKI_POB_ATR # w) IDF No. z (TKI # z), to perform operation S616, in which The CPU 10 increments the variable "w" (# w ← # w + 1), and to perform operation S617, in which the CPU 10 decides whether the variable "x" has reached the last number No. n (#n) in the OBI ( DOM). If this is not the case, then the processing routine proceeds to operation S609, in which the CPU 10 increments the variable "x". If the value of the variable "x" has reached the last number No.n (#n) in the OBI (DOM), then in the processing procedure, they proceed to step S618, in which the OBI from No. 1 to No. n is recorded on the semiconductor memory board (POB # 1 -POB # n), ADPG (TKMG), which contains IDFs (TKIs), and ADSF (PLMG), which contains ISVFU (DPLI) and ISVF (PLI), and this completes the processing.

In these embodiments of the invention, it is possible to display the same still image data on the screen as a background image, for example, a photograph of an artist or a logo of a record company, during the reproduction of multiple phonograms. This is achieved simply by setting the data on a still image in the corresponding phonograms UP_IOB_ISVFU (DPLI_POB_SRPs) or UP_IOB_ISVF (PLI_POB_SRPs) in the Information_of_list_of the playable_files_of the default (Default_Playlist_Information) or in PLF (Default).

Those data on a still image, for example, a page with the words of a song, which should be displayed on the screen together with the background image only during the playback of a particular phonogram, can be indicated by UP_IOB_IDF (TKI_POB_SRP) in the IDF (TKI) of the phonogram.

The focus of the above explanation is on the option that is currently thought to be an ideal system for implementing the idea of the present invention, although it is obvious that several modifications may be made within the scope of the patent claims of the invention. Below are three examples of such modifications, indicated by (a), (b) and (c).

(a) Procedures, the explanation of which is carried out using the flowcharts of FIG. 94, FIG. 95, FIG. 96 and FIG. 99, can be implemented by programs, the distribution and sale of which can be carried out in the form recorded on the recording medium.

(b) In the embodiments described herein, a case is described in which reproduced data and navigation data are used for musical information content, although it should be obvious that such data can also be used for a voiced book, which is an actor or speaker reading a book. . The best option for this case can be one in which, as the foreground images, by means of UP_IOB_IDF (TKI_POB_SRPs) data on still images representing the text of the book is set, and illustrations from the book are set by UP_IOB_ISVFU (DPLI_POB_SRPs) or UP_IOB_ISPVF )

(c) Despite the fact that in this second embodiment of the invention, those IOBs (POBs) that are indicated by UP_IOB_ISVFU (DPLI_POB_SRPs) and UP_IOB_ISVF (PLI_POB_SRPs) are used as background images, and those IOBs are used as images located in the foreground (POBs), which are indicated by UP_IOB__IDF (TKI_ROV_SRPs), the reverse configuration may also be used. Alternatively, in the case when, by means of UP_IOB_ISVFU (DPLI_POB_SRP) or UP_IOB_ISVF (PLI_POB_SRP) and UP_IOB_IDF (TKI_POB_SRP), different OBIs (POBs) are specified at the same time, only one of these OBIs can be displayed on the screen (POBIOB). Another alternative is one in which there is no need to introduce any differences between the “background image” and the “foreground image”. One example of this is one in which first the display of the OBI (DOM) indicated by UP_IOB_ISVFU (DPLI_POB_SRP) or UP_IOB_ISVF (PLI_POB_SRP) can then be performed, and then the display of the OBI (DOM) indicated by UP_IOB_IDF ( TKI_POB_SRP).

THIRD OPTION FOR CARRYING OUT THE INVENTION

While the second embodiment describes the case in which the display on the screen of each OBI (DOM) is performed with the same duration during the validity period of the IDF (TKI) and ISVF (PLI), this third embodiment describes the case in which the flash memory board 31 also remembers a table of the distribution of phrases over time and a table of coordinates allocated on the screen, which makes it possible to properly synchronize the procedure for displaying song words on a screen with song playback.

The table of distribution of phrases in time provides a correspondence between UP_IOB_IDF (TKI_POB_SRPs), by means of which IOBs (POBs), which are each of the fragments of the text of the song, are set, and information that indicates the start and end times of the corresponding phrase in the song. On figa shows one example of a table of the distribution of phrases over time. In this example, the "distribution of phrases in time" refers to the length of time during which the phrase is indicated, indicated in the words of the phonogram song and representing a fragment of the reproduction of GOITER (AOB). This time interval is set to the nearest millisecond. In addition to updating the playback time code, which is described in the first embodiment, the playback device further controls the distribution of phrases in time specified in this table, which corresponds to the current value of the playback time code. By means of such control over the distribution of phrases in time, the playback device can know in which IOB (DOM) the words of the song are stored for those GOITER (AOB), ELEMENT_ZOB (AOB_ELEMENT) and KADRA_ZOB (AOB_FRAME), which are currently being played. The use of such a table, in which the synchronization of the phrase IOB (DOM) in milliseconds is set, allows the playback device to synchronize the playback of GOITER (AOW) and display on the screen the words of songs with an accuracy of milliseconds.

In the case where the user indicates the desired start time for playback using the jog dial as described in the first embodiment of the invention, the playback device using the equations of Equation 1 to Equation 3 given in the first embodiment can find which GOITER (AOB_FRAME) in which GOITER (AOB_ELEMENT) which GOITER (AOB) corresponds to the specified playback start time. The playback device also decides on the time interval of which phrase contains the specified start time of the playback, and displays on the screen that IOB (DOM), 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 indicated by the rotary dial with step switching, the OBI corresponding to this desired location can also be displayed on the screen. It should be noted that despite the fact that in this version it is indicated that the values of time are specified in the table of distribution of phrases in time, instead of them in the table of distribution of phrases in time can be specified the number of GOITER (AOW), the number of ELEMENT_ZOB (AOB_ELEMENT) and the number of FRAME_ZOB (AOB_FRAME) of the GOITER (AOB), GOITER_ELEMENT (AOB_ELEMENT) and GOITER_FRAME (AOB_FRAME) with which the phrase should be synchronized.

On the other hand, the table of coordinates allocated on the screen provides a correspondence between the coordinates of the letters displayed on the screen used for the lyrics of the song, and the moment in time at which the REPEAT_ZOB (AOB_ELEMENT) and FRAME_ZOB (AOB_FRAMEs) corresponding to these characters are reproduced. On Figb shows one example of a table highlighted on the screen coordinates. The compilation of such a table of coordinates allocated on the screen allows the playback device to display on the screen a different color of the letters corresponding to the song words in the currently playing ELEMENT_ZOB (AOB_ELEMENT) and KADRE_ZOB (AOB_FRAME), from those song words that are displayed on the screen in accordance with the distribution of phrases in time.

As one example, one can be given in which the text of the song contains the phrase "Hey hey boy don't take it slow", and the table of coordinates highlighted on the screen contains the display coordinates for the letters "H", " e "," y "," h "," e "," y ", ..., which are associated with the playing time of the GOITER (AOB_ELEMENT) and GOITER (AOB_FRAME) corresponding to these characters. When playing GOITER (AOW), the playback device changes color in the place indicated by the display coordinates on the screen for the letters specified in the table highlighted on the screen coordinates.

Therefore, the playback device can display on the screen the words of the song in such a way that allows the user to instantly recognize the currently playing part of the GOITER (AOW). This means that playback of music recorded on the flash memory board can be performed with highlighting the words of songs in the same way as when playing ordinary karaoke tracks.

In this third embodiment of the invention, a table of the distribution of phrases in time and a table of coordinates allocated on the screen are created to enable accurate synchronization between the reproduction of sound data and the display on the screen of the words of songs, the same as in conventional karaoke tracks. Despite the fact that the entire description of the present invention has been made with reference to the accompanying drawings, it should be noted that for specialists in the art it is obvious the possibility of various modifications and modifications. Therefore, in the event that such modifications and modifications are not beyond the scope of the patent claims of the present invention, they should be considered as falling under it.

INDUSTRIAL APPLICABILITY

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

Claims (15)

1. A semiconductor memory board containing a protected area that can be accessed by a playback device connected to said semiconductor memory board only if the authenticity of the device is established, and an unprotected area that can be accessed by any a reproducing device connected to the semiconductor memory board, the semiconductor memory board storing an audio sequence containing a plurality of sounds uk objects, a plurality of objects, which are still images, at least one piece of information about the playback route, indicating the order in which you want to play sound objects from many sound objects in an audio sequence, at least one piece of information about the first pointer , each of which corresponds to a piece of information about the playback route and by means of which at least one object is set, which is a fixed and the reflection that should be displayed when playing sound objects in the order indicated by the corresponding piece of information about the playback path, and at least one piece of information about the second pointer, each of which corresponds to the sound object in the audio sequence and by which at least one object, which is a still image, which should be displayed when playing only the corresponding sound object. 2. The semiconductor memory board according to claim 1, in which at least one audio object is music information, wherein the plurality of objects representing still images comprises at least one object representing a still image, in which the words of the song displayed by the musical information in the sound object are shown, and at least one piece of information about the second pointer defines each object, which is a still image showing words of a song represented by musical information in a sound object that corresponds to a piece of information about the second pointer. 3. The semiconductor memory board according to claim 1, which further stores a plurality of symbol counters, each of which corresponds to an object representing a still image, and shows whether this object, which is a still image, is set by at least one piece of information about the first pointer and at least one piece of information about the second pointer, and if this is the case, it shows how many pieces of information about the first pointer and information about T rum specified index object representing a still image. 4. The semiconductor memory board according to claim 1, wherein the plurality of objects representing still images contains at least one encrypted object representing a still image, wherein the semiconductor memory board further stores control information containing identifier information for each of an object representing a still image, additional information showing whether each of the objects representing a still image has been encrypted, and the location in the memory of each object, which is a still image, and at least one decryption key used to decrypt at least one encrypted object, which is a still image, and the device connected to the semiconductor memory board gets access to, at least one decryption key only if the device is authenticated, fragments of information about the first pointer and information about the second pointer, through which objects that are still images using identifier information that is specified in the control information. 5. The semiconductor memory board according to claim 4, storing at least one decryption key — in a protected area, a sound sequence, a plurality of objects that are still images, each piece of information about the playback route, each piece of information about the first pointer, each a piece of information about the second pointer and control information in an unprotected area, and at least one encrypted object, which is a still image that has been encrypted using at least one decryption key, - in the protected area. 6. The semiconductor memory board according to claim 5, in which at least two objects representing a still image from a plurality of objects representing a still image are encrypted, at least two keys are stored in a protected area in a predetermined order decryption in the form of a sequence of decryption keys, and the identifier information for each encrypted object, which is a still image, contains a key number indicating the position of that key encryption in the sequence of decryption keys, which corresponds to the encrypted object, which is a still image. 7. A playback device for a semiconductor memory card storing (1) an audio sequence containing a plurality of audio objects, (2) a plurality of objects representing still images, (3) information about a first pointer by which at least one object is defined representing a still image that must be displayed when playing back a plurality of sound objects from a sound sequence, and (4) at least one piece of information about the second pointer, each of which is given at least one object, which is a still image, which should be displayed only when playing a specific sound object from the sound sequence, and the said playback device contains a playback tool for reproducing sound objects from the sound sequence one by one in a predetermined order , a visual display means that displays at least one object, which is a stationary image the expression, which is determined by the information about the first pointer, when playing sound objects from the sound sequence, and the control tool that provides the means for visual display of at least one object, which is a still image, which is defined by a piece of information about the second pointer, when playing a specific a sound object corresponding to a piece of information about the second pointer. 8. The playback device according to claim 7, in which the control means provides a means for visual display of the total image created by combining at least one object, which is a still image, defined by a piece of information about the second pointer, with at least one object, which is a still image, certain information about the first pointer. 9. A recording device for a semiconductor memory board storing a plurality of objects constituting a still image and a sound sequence comprising a plurality of sound objects, said recording device comprising an assignment means for assigning a sound sequence of at least one object constituting a fixed the image to be displayed when playing a plurality of sound objects, and assigning to a specific sound object, at least to it of at least one object, which is a still image that must be displayed when playing a particular sound object, and a recording means for recording on a semiconductor memory board: (1) information about the first pointer showing at least one object representing is a still image that is assigned to a sound sequence, and (2) information about a second pointer showing at least one object representing a still image that is assigned to a particular sound object. 10. A computer-readable storage medium storing a program enabling the computer to perform a reproduction procedure for a semiconductor memory card, the semiconductor memory card storing: (1) an audio sequence containing a plurality of audio objects, (2) a plurality of objects representing still images, ( 3) information about the first pointer, through which at least one object is set, which is a still image, which should be displayed when reproducing a plurality of sound objects from a sound sequence, and (4) at least one piece of information about the second pointer, through each of which at least one object is set, which is a still image, which should be displayed only when playing a specific sound an object from a sound sequence, wherein said program contains the following operations: a playback operation in which sound objects from a sound message are played back one sequence in a given order, a visual display operation in which at least one object representing a still image, which is determined by information about the first pointer, is displayed when playing audio objects from a sound sequence, and a control operation providing visual display of at least one object, which is a still image, defined by a piece of information about the second pointer, when playing to nkretnogo audio object corresponding to the piece of information about the second index. 11. The computer-readable storage medium of claim 10, wherein the control operation provides a visual display of the cumulative image created by combining at least one object that is a still image defined by a piece of information about the second pointer, with at least , one object, which is a still image, certain information about the first pointer. 12. A computer-readable storage medium storing a program enabling the computer to execute a recording procedure for a semiconductor memory card, the semiconductor memory card storing a plurality of objects representing still images and an audio sequence containing a plurality of audio objects, wherein said program comprises the following operations: an assignment operation in which the assignment of a sound sequence of at least one volume cta, which is a still image that must be displayed when playing a plurality of sound objects, and assigning at least one object to a particular sound object, which is a still image that must be displayed when playing a specific sound object, and a recording operation, when which write to the board of the semiconductor memory (1) information about the first pointer, showing at least one object, which is a still image the property that is assigned to the audio sequence, and (2) information about the second pointer showing at least one object that is a still image that is assigned to a particular audio object. 13. A reproducing method for reproducing data from a semiconductor memory board storing (1) an audio sequence containing a plurality of audio objects, (2) a plurality of objects representing still images, (3) information about a first pointer by which at least , one object, which is a still image, which must be displayed when playing back a plurality of sound objects from an audio sequence, and (4) at least one piece of information about the second a pointer, through each of which at least one object is set, which is a still image, which should be displayed only when playing a specific sound object from an audio sequence, said playback method comprising the following operations: a playback operation in which audio is reproduced objects from the sound sequence one by one in a given order, the visual display operation, in which the display on the screen of at least one object, which is a still image, which is determined by the information about the first pointer, when playing sound objects from the audio sequence, and a control operation that provides, during the operation of visual display, at least one object, which is a still image , which is defined by the piece of information about the second pointer, when playing a specific sound object corresponding to the piece of information about the second pointer. 14. The playback method according to item 13, in which the control operation provides for the operation of visual display of the total image created by combining at least one object that is a still image defined by a piece of information about the second pointer, with at least one object, which is a still image, certain information about the first pointer. 15. A recording method for a semiconductor memory board storing a plurality of objects representing still images and an audio sequence comprising a plurality of audio objects, said recording method comprising the following operations: an assignment operation in which at least one audio sequence is assigned object, which is a still image that must be displayed when playing multiple sound objects, and assignment to a specific sound the object, at least one object, which is a still image that must be displayed when playing a specific sound object, and a recording operation in which write to the semiconductor memory card (1) information about the first pointer, showing at least , one object representing a still image that is assigned to a sound sequence, and (2) information about a second pointer showing at least one object representing a still An image that is assigned to a specific sound object.

Images