MXPA01000997A - Semiconductor memory card, playback apparatus, recording apparatus, playback method, recording method, and computer-readable recording medium - Google Patents

Abstract

A semiconductor memory card stores a plurality of audio objects (AOBs) that compose a plurality of tracks and playlist information showing a reproduction order for the tracks. The semiconductor memory card also stores, as resume information (PLMG_RSM_PL), (1) a Playlist_Number showing which playlist information was used the last time playback was performed for the semiconductor memory card, (2) a Track_Number showing the last track to be played back, and (3) a Playback_Time showing a position where playback was stopped as a time expressed in relation to the start of the track.

Description

SEMICONDUCTOR MEMORY CARD, REPRODUCTION APPARATUS.

RECORDING DEVICE. METHOD OF REPRODUCTION, METHOD OF RECORDING AND LEGIBLE RECORDING SYSTEM IN COMPUTER TECHNICAL FIELD The present invention relates to a semiconductor memory card which stores audio data and control data and to a playback apparatus, recording apparatus, reproduction method, recording method and computer-readable recording medium in relation to such a card. of semiconductor memory. In particular, the present invention relates to the improved storage of audio data and control data distributed as content by a content distribution service, such as an electronic music distribution service.

ANTECEDENTS OF THE TECHNIQUE The distribution of electronic music allows the user to acquire and receive music content (eg songs and groups of songs or albums) via the internet. Such technology has the potential to greatly increase the recorded music market and it gradually becomes possible for the necessary hardware structure to be justified. A way REF: 126828 to store the music content that is obtained from an electronic music distribution service is in semiconductor memory cards whose portable capacity makes them ideal. As a result, a large increase in demand for such cards is expected. Various kinds of semiconductor memory cards are available, such as Flash ATA and Compact Flash cards. Music content can also be stored on a disc medium, such as a CD-R (compact disc-rewritable) or MiniDisc (MD). Although there is a wide variety of recording media that can be used to record music content, there are only a limited number of methods to indicate when music content (track) should start playing. Esca operation is usually carried out according to one of the following patterns. When a music album is made up of a plurality of musical contents (tracks), there are two main methods to indicate where the playback should start. The first method has the start of playback from the first track in the album. In the second method the user must indicate the track number and then the playback starts from the beginning of the indicated track. In the first of these methods, playback always starts with the same track and continues through all the tracks in the album in the same order. If the user stops playback in the middle part of the development of an album, a restart of the playback according to this method will result in the device returning to the first track. The user, therefore, should have to listen to all the tracks that he has just played. In the second method, playback starts from the track indicated by the user. When the user stops playback at a given point in the album and then presses once more to play, the user can have the playback restart from any track, such as the track after the track where the playback stopped. This certifies that the user does not need to listen to the tracks from the beginning one more time. However, in the latter case, the user must still perform several operations, such as entering the track number. This can be problematic, especially if the user does not want to know which track corresponds to which track number. In such cases, the user may indicate a wrong track, which will then be played by the player. As described above, when playback is stopped and then restarted, the two methods currently used force the user to listen to all the tracks in order from the start or enter a track number for the track from which playback must start. This is far from ideal. The following two methods are also sometimes used to indicate a position at which playback should begin. A third method is one in which the user indicates the movement of the reproduction position to the desired start time within the desired track using a forward or reverse search drive that is provided by a reproducing apparatus. A fourth method is one in which the user indicates the desired track and the desired position within that track using a rocker knob (or similar) and then starts playback from this position. Since in both methods the user must indicate how far the previous reproduction has advanced, have the same disadvantage as the second method described above. The current MiniDisc (MD) reproduction devices use a reproduction method that indicates the reproduction position in a more simple way compared to the first to the fourth methods indicated above. When the user stops playback on an MD, the resume information that shows the position at which the playback was stopped is recorded in a non-volatile memory in the MD player. When the user indicates the playback of the same MD, the playback of the tracks recorded on the MD starts at the position indicated in the resume information. The resume information is recorded in the MD player in a non-volatile manner so that the interruption of the power supply does not result in the loss of the information. This means that the user can listen to a part of a music album, turn off the player and still have the resumption of playback in the position where playback was stopped. In this case, the user does not have to repeatedly listen to the tracks at the beginning of the album as in the first method, or have to enter a number of tracks, as in the second method, which makes it an ideal way to listen to the entire the tracks included in an album. However, with an MD, the information shows how much of an album's playback has been stored within the MD player's hardware. Consequently, there is the problem that when the MD of a player is ejected and unleashed on another player, the second player will play the MD tracks from the first track on the album, in the same way as in the first method. . As a specific example, when a user listens to some of the tracks in an album using a playback device first, defines playback and then transfers the disc to another playback device, this second playback apparatus will not store the resume information that shows the position reached by the reproduction of this disc. As a result, playback will start from the beginning of the album and will make the user listen to the same tracks again. Since discs are rarely transferred from one player to another while playing an album, playback that returns to the beginning of the album can not be a very important problem. When the album is submitted to electronic music distribution before being recorded on a recording medium, however, it is considered that there will be many cases in which the album is partially reproduced on one player and then transferred to another. Electronic music distribution is obtained by having a user-owned computer where a music album is downloaded from a server computer operated by a brand of recordings. The user can then have a downloaded album and play it on his computer. Since modern personal computers are capable of playing music content, the user can listen to albums that have been purchased on his or her computer. Assuming that the user listens to the album on a portable playback device after listening on his computer.

In this case, the portable playback device can not know how much playback has advanced on the computer, so the album will play once more from the beginning. As the user submits to the same songs that were played by the computer, it is likely that the user will advance the album faster than if all the tracks were played. As the recording media becomes smaller and lighter, but with greater capacity, it becomes increasingly possible to record albums containing large numbers of tracks on a single recording medium. It is considered that such a recording medium will often be transferred between reproduction apparatuses. If the playback returns to the beginning after a large number of tracks have been played, this will be very uncomfortable for the listeners.

DESCRIPTION OF THE INVENTION A first object of the present invention is to provide a semiconductor memory card that allows the reproduction of the reproduction from a previously stopped position without reproducing the same recorded material and the user having the indication of the posi ci Playback, even when the semiconductor memory card has been transferred between playback devices. A second objective of the present invention is to provide a semiconductor memory card which allows the reproducing apparatus to begin again the reproduction of an album that has started on a different reproduction apparatus without the same recorded material being reproduced. The first objective can be obtained by a semiconductor memory card that stores: an audio sequence in which a plurality of audio objects are placed; and resume information that shows a resume position for use when there is a playback of the audio sequence and resumes in the middle part through the audio sequence. Assuming that an audio sequence corresponds to the music album and that the user listens to a first part of the album on a playback device. If the user then transfers the semiconductor memory card to another playback apparatus, this playback apparatus will be able to start playback of the album in the position where it was stopped again by referencing the resume reproduction value shown by the playback information. resumption. The resumption of reproduction based on the resume information does not require the user to perform any particular operation. This means that the user does not need to get into the problem of indicating a track (audio object) when transferring the semiconductor memory card to another playback device. The resume information may include at least one type 1 position information and type 2 position uniformation, the type 1 position information shows a type 1 resume position which is established according to the user's operation, and the position type 2 shows a type 2 resume position that is automatically set when playback of the last audio sequence has stopped. Here, each audio object in the audio sequence can be provided with unique identification information, the position information of type 1 shows the position of resumption type 1 using the identification information of one of the audio objects and the information of position type 2 shows the type 2 resume position using the identification information of one of the audio objects and the time information showing a deviation from the start of one of the audio objects to the type 2 resume position. The second objective is obtained by the previous construction. The position information of type 2 includes a deviation from the start of an audio object. When the semiconductor memory card is transferred between playback devices, the second player may begin playback in a position immediately following a point where playback was stopped on the first reproducing apparatus. This means that the user can begin to listen to an album on a first player, stop playback, transfer the semiconductor memory card to another player, and then continue playback just after the stop position. Unlike conventional technologies, the user does not need to have to listen to the same tracks as long as the semiconductor memory card is transferred between playback devices. Albums that are obtained from an electronic music distribution service will often be transferred between different playback devices. In such a case, however, the user will not have to listen to the same tracks as long as the album is transferred to another player.

BRIEF DESCRIPTION OF THE DRAWINGS This and other objects, advantages and features of the invention will be more apparent from the following detailed description thereof taken together with the accompanying drawings which illustrate a specific embodiment of the invention. In the drawings: Figure 1 shows the appearance of a flash card 31 when viewed from the top; Figure 2 shows the construction of the instant memory card 31 when viewed from the bottom; Figure 3 shows the hierarchical composition of the instant memory card 31 in the modes; Figure 4A shows the special region, the authentication region and the user region that is provided in the physical layer of the instant memory card 31; Figure 4B shows the composition of the authentication region of the user region in the file system layer; Figure 5 shows the detailed composition of the file system layer; Figure 6 is a representation of the moment in which the AOB file "AOB001.SA1" is divided into five parts that are stored in groups 003, 004, 005, 00A, and 00C. Figure 7 shows an example of the settings of the directory entries and the file allocation table when the AOB file "AOB001.SA1" is registered in a plurality of groups; Figures 8A and 8B show that directories are provided in the user's region and that the authentication region in the file system layer when the two previous types of data are recorded in the application layer, as well as what kind of files are recorded. record and what directories; Figure 9 shows the correspondence between the file "AOBSAl.KEY" and the AOB files in the SD_AudiO directories; Figure 10 shows the hierarchical composition of the data in an AOB file; Figure HA shows the parameters stipulated by the ISO / IEC 13818-7 standard in tabular form; Figure 11B shows the parameters that could be used when encoding a file in the MPEG-layer 3 (MP3) format in tabular form; Figure 11C shows the parameters that would be used when encoding a file in the Windows Media Audio (WMA) format in tabular form; Figure 12 shows the detailed construction of an A0B_FRAME; Figure 13 shows the manner in which the octet length of the audio data is set in each of the three AOB_FRAME; Figure 14 shows the correspondence between sampling_frequency and the number of AOB_FRAME included in an AOB_ELEMENT; Figure 15 shows examples of the playback periods of the AOB_ELEMENTS and the playback periods of the AOB_FRAME; Figure 16 shows what is played when the AOB and AOB_BLOCK recorded in an AOB file are played consecutively; Figure 17 shows the hierarchical composition of the PlaylistManager and Trac Manager used in the detailed modes; Figure 18 shows the sizes of PlaylistManager and TrackManager; Figure 19 shows the correspondence between the TKI and shown in Figure 17 and the AOB and the AOB files shown in Figure 16; Figure 20 shows the detailed data composition of TKTMSRT shown in Figure 17; Figure 21 shows an example of the TKTMSRT; Figure 22 shows the detailed composition of the TKGI, figures 23A and 23B show the composition of the BIT; Figure 23C shows the Time_Length field; Figure 24 shows the groups 007 to OOE within which are stored the AOB constituted from AOB_ELEMENT # l to AOB_ELEMENTO # 4; Figure 25 shows how playback is set after AOB_FRAME # x + l when a forward search is performed from AOB_FRAME # x on an AOB_ELEMENT # and arbitrary on an AOB; Figures 26A and 26B show the manner in which an AOB, an AOB_ELEMENT and an AOB_FRAME corresponding to an arbitrary time code of reproduction are specified; Figures 27A and 27B show the deletion of a track; Figure 28A shows the TrackManager after a deletion has been made several times; Figure 28B shows a new TKI and AOB file which is written when the "unused" TKIs are present in the TrackManager; Figures 29A and 29B show the TKIs that fit when two tracks are combined to produce a new track; Figure 30A shows an AOB type 1; Figure 30B shows the AOB type 2; FIGURE 3 ALIGNMENT OF A MULTIPLE TRACKS IN A SINGLE PATH FOR A COMBINATION OF AOB TYPE 1 + TYPE 2 + TYPE 2 + TYPE 1 AOB; Figure 31B shows the combination of a plurality of tracks in a single track for a combination of AOB type 1 + type 2 + type 2 + type 2+ type 1 AOB; Figure 32A shows a pattern wherein an AOB type 1 is present at the end of the preceding track and an AOB type 1 is present at the start of the next track; Figure 32B shows a pattern wherein an AOB type 1 is present at the end of a first track and an AOB type 2 is present at the beginning of the next track; Figure 32C shows a pattern in which two AOB type 1 and type 2 are present at the end of a first track and an AOB type 1 is present at the start of the next track; Figure 32D shows a pattern in which two AOB type 1 and type 2 are present at the end of a first track and a type 2 and a type 1 are present at the beginning of the next track; Figure 32E shows a pattern in which two AOB type 2 are present at the end of a first track and one type 1 is present at the beginning of the next track; Figures 33A and 33B show the division of a track to produce two tracks, - Figures 34A and 34B show the contents of the SD_Audio directory entries in the SD_Audio directory that include the AOB file "AOB003.SA1" before and after the division of the track; Figure 35A shows the division of a middle part of AOB through AOB_ELEMENT # 2; Figure 35B shows the two AOB, A0B # 1 and A0B # 2, obtained by dividing an AOB by half through AOB_ELEMENT # 2; Figure 36 shows how BITs are established when an AOB is divided, as shown in Figure 35; Figure 37 shows a specific example of changes in the BIT before and after the division; Figure 38 shows a specific example of changes in TKTMSRT before and after division; Figure 39A shows the format of a DPL_TK_SRP; Fig. 39B shows the format of a PL_TK_SRP; l a ff 40 symbolize the int errel ac tion between Def ault_Playlist_Inf ormation, the TKIs and the AOB files; Figure 41 shows the example settings for Default_Playlist and several PLIs; Figure 42 shows how the DPL_TK_SRP corresponds to the TKI using the same annotation as in Figure 40; Figures 43A and 43B show the manner in which the order of tracks is rearranged; Figures 44A and 44B show how Def aul t_Pl ayl i s t, TrackManager and the AOB files s and update when DPL_TK_SRP # 2 and TKI # 2 are deleted from the Default_Playlist shown in Figure 40; Figures 45A and 45B show the manner in which a new TKI and DPL_TK_SRP is written when a "unused" TKI and DPL_TK_SRP are present; Figures 46A and 46B show the manner in which the tracks are combined; Figures 47A and 47B show how the tracks are divided; Figure 48 shows the appearance of a portable reproduction apparatus for the instant memory card 31 of the present embodiments; Figure 49 shows an example of the screen on an LCD panel when a Playlist is selected; Figures 50A to 50E show examples of the screen on the LCD panel when a track is selected, - Figures 51A to 51C show example operations of the flag j or g; Figure 52 shows the internal construction of the reproduction apparatus; Figure 53 shows how the data is transferred into and out of the double memory; Fig. 54A and 54B show how the areas in the double buffer are allocated cyclically using ring pointers, Fig. 55 is a flow diagram showing the procedure of reading the AOB file; Fig. 56 is a flow diagram showing the procedure of outputting the AOB file; Fig. 57 is a flow chart showing the procedure of outputting the AOB file; Fig. 58 is a flow diagram showing the procedure of outputting the AOB file; Figures 59A to 59D show how the playback time code displayed in the playback time code frame in the LCD panel 5 is updated according to the update of the Play_time variable; Fig. 60 is a flow chart showing the processing of the CPU 10 when the forward search function is used; Figures 61A to 61B show how the playback time code is increased when the forward search function is used; Figures 62A and 62B show the specific examples of how the time search function is used; Fig. 63 is a flow diagram showing the processing in an editing control program; Fig. 64 is a flow chart showing the processing in the editing control program; Fig. 65 is a flow chart showing the processing in the editing control program; Fig. 66 shows an example of a recording apparatus for recording data on the instant memory card 31; Figure 67 shows the hardware configuration of the recording apparatus; Fig. 68 is a flow diagram showing the processing during recording; Figure 69 shows the internal composition of the PlaylistManager and TrackManager in the second mode; Figure 70 shows the detailed composition of the PlaylistManager__Information; Figure 71 shows how PLMG_AP_PL and PLMG_RSM_PL are set when the instant memory card of the second mode is transferred between a plurality of reproduction apparatuses; Figure 72 shows the menu screen used to receive a PLMG_AP_PL user setting and the activation setting; Fig. 73 is a flow chart showing the reproduction position determination procedure performed based on the PLMG_AP_PL and the PLMG_RSM_PL; Figure 74 shows the data construction used when storing 6 upper bytes of the PLI_RSM_PL (DPLI_RSM_PL) in the DPLGI for the DPLI and in the PLGI for a PLI; Figure 75 shows how PLI_RSM_PL (DPLI_RSM_PL) is set for the Default_Playlist_Information and each PLI; Figure 76 shows the track sequences made up of the playback commands indicated by the Playlist shown in Figure 41 to which reference is made in the first mode; Fig. 77 shows an example of a menu screen showing each Playlist together with the establishment of the PLI_RSM_PL for a case in which the reproduction tracks (1) to (3) have already been reproduced in Fig. 76; and Figure 78 shows the data format of DPLGI, PLGI, TKGI in the fourth embodiment of the present invention.

Best mode for carrying out the invention The following describes a semiconductor memory card (instant memory card) which is an embodiment of the present invention, with reference to the accompanying figures.

The following paragraphs are placed in a hierarchy using reference numbers with the notation indicated below. . { xl-x2_x3-x4 } The length of a reference number shows the level of the topic in the hierarchy. As a specific example, the number xl is the drawing number that is referenced in the explanation. The drawings attached to this specification have been numbered in the order in which they are mentioned in the specification, so that the order of the drawings generally coincides with the order of the explanation. The explanation of certain drawings has been divided into sections, with the reference number x2 provided to the section number of a section in the explanation of a drawing indicated by the reference number xl. The reference number x3 shows the number of an additional drawing that is provided to show the details of the section indicated by the section number x2. Finally, the reference number x4 shows the number of a section in the explanation of this additional drawing.

FIRST MODALITY . { l-l_2 } External appearance of the instant memory card 31 The present explanation begins with the external appearance of the instant memory card 31. Figure 1 shows the appearance of the instant memory card 31 when viewed from the top, while figure 2 shows the construction of the instant memory card 31 when viewed from the bottom. As shown in FIGS. 1 and 2, the instant memory card 31 is approximately the same size as a postal stamp, and is therefore large enough to hold in the hand. Its approximate dimensions are 32.0 mm long, 24.0 mm wide and 2.0 mm thick. It can be seen that the instant memory card 31 has nine connectors at its lower edge for connecting the card to a compatible device and with protection switch 32 on one side to allow the user to establish whether overwriting of the content of the card is allowed or prohibited. instant memory card 31 . { 3-1} Physical construction of the instant memory card 31 Figure 3 shows the hierarchical structure of the semiconductor memory card (hereinafter referred to as the "instant memory card 31") of the present embodiment. As shown in Figure 3, the flash memory card 31 is constructed with a physical layer, a file system layer and an application layer in the same way as a DVD (digital video disc), although the logical and physical constructions of these layers are very different from those of a DVD. . { 3-2} Physical layer of the instant memory card 31 The following describes the physical layer of the instant memory card 31. The flash memory is constituted by a plurality of sectors, each of which stores 512 bytes of digital data. As an example, a 64MB flash memory card 31 will have a capacity of 67,108,864 (= 64 * 1,024 * 1,024) octets, so that this card will include 131, 072 (= 67108864/512) valid sectors. Once the number of substitution sectors, which are provided for use in case of errors, is subtracted, the remaining number of valid sectors in which the various kinds of data can be written is approximately 128,000. . { 3-2_4A-l} Three regions in the physical layer The three regions shown in Figure 4A are provided in the storage area composed of these valid sectors. These regions are the "special region", the "authentication region" and the "user region" if they are described in detail in the following. The user region is characterized in that a device for which the instant memory card 131 of various kinds of data is connected to or within this region can be freely read or written. The areas within the user region are managed by a file system. The special region stores a means ID which is a value assigned uniquely to each instant memory card 31. Unlike the user region, this region is read-only, so the ID of the medium stored in the special region can not be changed. The authentication region is a writable region, such as the user region. This region differs from the user region in that a device connected to the instant memory card 31 can access (i.e., read or write data in) the authentication region only if the instant memory card 31 and the first device is They have confirmed each other as an authentic device. In other words, the data can only be read or written in the authentication region if a mutual authentication has been successfully performed by the instant memory card 31 and the device connected to the instant memory card 31. . { 3-2_4A-2} Uses of the three regions in the physical layer When the device connected to the flash memory card 31 writes data inside the flash memory card 31, the region used to store this data will depend on whether copyright protection is necessary for the data to be written. When the data that requires registered property protection is written to the card 31 in flash memory, the data is encoded using a finished coding key (called a "FileKey"), before it is written in the user area. This FileKey can be freely established by the copyright holder and, although the use of this FileKey provides a certain level of copyright protection, the FileKey used to encode the data written in itself is encoded for further protection. Secure the copyright. Any value obtained by submitting the ID medium stored in the special region in a given pre-calculation can be used to encode the FileKey. The encoded FileKey produced in this way is stored in an authentication region. Since the data that requires copyright protection undergoes a two-stage coding process, when the data is encoded using a FileKey that itself is encoded based on the media ID, it will be extremely difficult to produce the data. unauthorized copies of this data. . { 3 ~ 2_4B-l} General aspects of the filing system As can be understood, the construction of the physical layer of the instant memory card 31 increases the copyright protection of the data written on the instant memory card 31. The following describes the file system layer present in this physical layer. Although the file system layer of a DVD uses a file system of type UVF (universal disk format), the file system layer of the instant memory card 31 uses a FAT (File allocation table), as it is described in ISO / IEC 9293. Figure 4B shows the construction of the authentication region and the user region in the file system layer. As shown in Figure 4B, the authentication region and the user region in the file system each include "division start sectors", a "file allocation table (FAT)", a "root directory" and a "data region", which means that the authentication region and the user region have the same construction. Figure 5 shows the various parts of these filing systems in greater detail. The following describes the construction of the user region with reference to Figures 4A, 4B and 5. . { 3-2_4B-2} Sectors of division start The division initiation sectors are sectors that store the data that will be referenced by a standard personal computer that is connected to the instant memory card 31 when the instant memory card 31 is established as the startup disk for the system operative (OS) of the personal computer. . { 3-2_4B-3_5} Region of data The data region can be accessed by the device connected to the instant memory card 31 in units no smaller than a "group", although each sector in the instant memory card 31 has a size of 512 bytes, the size group is 16KB, so the file system layer reads and writes data in units of 32 sectors. The reason that the group size is established in 16 kB is that when data is written to the instant memory card 31, part of the data stored in the instant memory card 31 must first be erased before writing can be carried out. The smallest amount of data that can be erased on the instant memory card 31 is 16 kB, so that setting a size that can be erased smaller as a group size means that data writing can be performed favorably. The arrow ff2 drawn using a dashed line in Figure 5 shows the plurality of groups 002,003,004,005. . . included in the data region. The numbers 002,003,004,005,006,007,008. . . used in figure 5 are numbers of hexadecimal groups of three digits that are assigned exclusively to identify each group. Since the smallest unit through which access can be made is a group, the storage locations within the data region are indicated using group numbers. . { 3-2_4B-4_5} File allocation system The file allocation system has a file system construction according to the ISO / IEC 9293 standard, and is thus constituted of a plurality of FAT values. Each FAT value corresponds to a group and shows which group can be read after the group corresponding to each FAT value. The arrow ffl shown by a dashed line in figure 5 shows the plurality of FAT values 002,003,004,005. . . that are included in the file allocation table. The numbers 002,003,004,005. . . assigned to each FAT value show which group corresponds to each FAT value and therefore are the group numbers of the groups corresponding to the FAT values. . { 3 -2_4B-5_5-l} Entries of the root directory The "root directory entries" are information that shows what kind of files are present in the root directory. As specific examples, you can write as the root directory entry of a file the "filename" (file name) of an existing file, its "filename extension" (file name extension), the "revision / time / date" (time) / date of revision) and "number of first cluster in file" (number of the first group in the file) that shows the moment in which the beginning of the file that is stored as the root directory entry of a file can be written. . { 3 -2_4B-5_5-2} Directory entries for subdirectories The information in relation to the files in the root directory is written as root directory entries, although the information in relation to the subdirectories is not written as the entries to the root directory. The directory entries for the subdirectories instead occur in the data region. In Figure 5, the SD-Audio directory entry provided in the data region is an example of a directory entry for a subdirectory. Like an entry in the root directory, an SD-Audio directory entry includes the "filename" of a file present in this subdirectory, its "filename extension", the "time / date revision" and the "number or first cluster in" file ", showing the place where the file start is stored. . { 3-2_4B-5_6-l} Storage format for AOB files The following describes the file storage method by showing how a file named "AOB001.SA1" is stored in the SD-Audio directory, with reference to Figure 6. Since the smallest unit through which you can access a data region is from a group, the file "AOB001.SA1" needs to be stored in the data region in parts that are not smaller than a group. Therefore, the file "AOB001.SA1" is stored when you first have to divide it into groups. In figure 6, the file "AOB001.SA1" is divided into five parts and is maintained with the group size, and the resulting parts are stored within groups numbered 003, 004, 005, 00A and 00C . { 3-2_4B-5_7-l} Storage format for AOB files When the file "AOB001.SA1" is divided into parts and stored, a directory entry and file allocation table need to be established, as shown in figure 7. Figure 7 shows an example of how the input of The directory and file allocation table need to be set when the file "AOB001.SA1" is stored and has been divided into parts and stored. In figure 7, the start of the file "AOB001.SA1" is stored in the group 003, so that the group number 003 is written inside the "the number of the first group in file" in the directory entry of SD- Audio to indicate the group that stores the first part of the file. As shown in Figure 7, the following parts of the file "AOB001.SA1" are stored in groups 004 and 005. As a result, although the value FAT 003 (004) corresponds to group 003 that stores the first part of the file "AOB001. SAI", this value indicates to group 004 as the group that stores the next part of the file "AOB001. SAI". In the same way, although the values of FAT 004 (005) and 005 (00A) correspond respectively to the groups 004 and 005 that store the following parts of the file "AOB001. SAI", these values respectively indicate the group 005 and the group 00A as the groups that store the following parts of the file "AOB001.SAI". When reading the groups with the group numbers written in these FAT values in the order as shown by the arrows fkl, fk2, fk3, fk4, fk5. . . In figure 7, all the parts produced by dividing the file "AOB001. SAI", can be read. As explained above, the data region of the instant memory card 31 is accessed in units of groups, each of which is associated with a FAT value. Note that the FAT value that corresponds to the group that stores the final part of an AOB file (the OOC group in the example shown in Figure 7) is set with the group number FFF to show that the corresponding group stores the final part of a file. This completes the explanation of the file system on the instant memory card 31 of the present invention. The following describes the application layer that exists in this file system. . { 3-3} General aspects of the application layer on the instant memory card 31 In Figure 3 a general scheme of the application layer on the flash memory card 31 is shown. As shown by the arrow PN2 drawn with a dashed line in figure 3, the application layer on the instant memory card 31 is constituted by presentation data and navigation data which are used to control the reproduction of the presentation data. . As shown by the arrow PN2, the presentation data includes sets of audio objects (AOB sets) that are produced when encoding audio data representing music, for example. The navigation data includes a "PlaylistManager" (PLMG) (playlist manager) and a "TrackManager" (TKMG) (track manager). . { 3--3_8A, B-l} Composition of the directory Figures 8A and 8B show what kind of directories are present in the region of the user and the authentication region in the file system layer when these two types of data are stored in the application layer, as well as show which files are placed within these directories. The filenames "SD_AUDIO.PLM" and "SD_AUDIO .TKM" in Figure 8A indicate the files in which the PlaylistManager (PLMG) and TrackManager (TKMG) that compose the navigation information are stored. Meanwhile, the filenames "AOB001.SA1", "AOB002.SA1", "AOB003. SAI", "AOB004. SAI",. . . indicate the files ("AOB" files) that store the audio subjects that are the presentation data. The names "SA" in the filename extension of "AOBOxx-SAl" are the abbreviation for "Secure Audio" and show that the stored content of this file requires copyright protection. Note that although only eight AOB files are shown in the Example in Figure 8A, a maximum of 999 AOB files can be stored in an SD-Audio directory. When copyright protection is required for presentation data, a subdirectory called an "SD-Audio directory" (SD-Audio directory) is provided in the authentication region and an encryption key storage file is produced "AOBSAl .KEY "in this SD-Audio directory. Figure 8B shows the encryption key storage file "AOBSAl.KEY" which is stored under the heading "SD-Audio" (ie, within the "SD-Audio directory"). This encoding key storage file "AOBSAl.KEY" stores a sequence of encoding key that occurs when placing a plurality of encoding keys in a predetermined order. The SD-Audio directory shown in Figures 8A and 8B are stored on a server computer managed by a brand of recordings that uses electronic music distribution. When a consumer orders a music content, the corresponding SD-Audio directory is compressed, encoded and transmitted to the consumer via a public network. The consumer's computer receives this SD-Audio directory, decrypts it, decompresses it and in this way obtains the original SD-Audio directory. Note that the term "public network" here refers to any kind of network that can be used by the public, such as a wired communication network, for example an ISDN network, or a wireless communication network, for example a system of mobile phone. It is possible for a consumer's computer to download or download an AOB file from a server computer operated by a brand of recordings and thus produce an SD-Audio directory, such as that shown in Figures 8A and 8B on the card 31 of instant memory. . { 3-3_9-l} Correspondence between the file "A0BSA1. KEY" and the AOB files Figure 9 shows the correspondence between the "AOBSAl.KEY" file in the SD-Audio directory and the AOB files. The FileKeys (file keys) used when encoding files in the user region shown in Figure 9 are stored in the corresponding encryption key storage file in the authentication region. The encoded AOB files and the modification key storage file correspond according to the predetermined rules (1), (2) and (3) described in the following. (1) The encoding key storage file is placed inside a directory with the same directory name as the directory in which the encoded file is stored. In Figure 9, the AOB files are placed within the SD-Audio directory in the user region and the storage file of the encryption key is placed in a directory called the SD-Audio directory in the authentication region, according to this rule. (2) The encoding key storage file is provided with a filename produced by combining the first three letters of the filename of the AOB files in the data region with a default extension of ".key". When the filename of an AOB file is "AOB001. SAI", the encryption key storage file is given the filename "AOBSAl.KEY" produced by adding the first three characters "AOB", "SAI" and the extension " .key ", as shown by the arrows nkl and nk2 in figure 9. (3) The filename of an AOB file is given a serial number that shows the position of the FileKey that corresponds to this audio object in the sequence of encoding keys that are provided in the encoding key storage file. The "File Key Entries" # 1, # 2, # 3, ... # 8"shows the first positions of the regions in which the respective FileKeys are stored in the key storage file. coding. Meanwhile, the filenames of the AOB files are assigned the serial numbers "001", "002", "003", "004" .... These serial numbers show the positions of the corresponding FileKeys in the sequence of coding key, so that the FileKey is used to encode each AOB file will be present in the "FileKey Entry" (file key entry) with the same serial number. In figure 9, the arrows Akl, Ak2, Ak3,. . . show the correspondence between the AOB files and the FileKeys. In other words, the file "AOB001.SA1" corresponds to the FileKey whose storage position is indicated by "FileKey Entry # l" (file key entry # 1), the file "AOB002.SA1" corresponds to the FileKey whose position of storage is indicated by the "FileKey Entry # 2", and the file "AOB003.SA1" corresponds to the FileKey whose storage position is indicated by the "FileKey Entry # 3". As you can understand from rule (3), different FileKeys are used to encode different AOB files, where these FileKeys are stored in "FileKeys Entries" (file key entries) with the serial numbers "001", "002"," 003"," 004"etc., given in the filenames of the corresponding AOB files. Since each AOB file is encoded using a different FileKey, exposing the encoding key used for an AOB file will not allow users to decode other AOB files. This means that when the AOB files are stored in a coded form on an instant memory card 31, the damage caused by the exposure of a FileKey can be minimized. . { 3-3_10-l} Internal composition of an AOB file The following describes the internal composition of an AOB file. Figure 10 shows the hierarchical data structure of an AOB file. The first level in Figure 10 shows the AOB file, while the second level shows the audio object (AOB) itself. The third level shows the AOB_BLOCK, the fourth level an AOB_ELEMENT, and the fifth level an A0B_FRAME. The A0B_FRAME in the fifth level in Figure 10 is the smallest unit that composes the AOB, and is made up of audio data in ADTS format (stream of audio data transport) and an ADTS header. The audio data in the ADTS format is encoded according to the MPEG2-AAC format (low complexity profile) and is a data stream that can be reproduced at a transfer speed of 16 Kbps to 144 Kbps. Note that the speed Transfer rate for PCM (pulse code modulation) that is recorded on a conventional compact disc is 1.5 Mbps, so data in the ADTS format generally uses a lower transfer rate than PCM. The data construction of a sequence of the AOB_FRAME is the same as the sequence of audio frames included in an audio data transport stream distributed by an electronic music distribution service. This means that the stream of audio data transport to be stored as a sequence A0B_FRAME is encoded according to the MPEG2-ACC standard, encoded and transmitted to a public network to the consumer. AOB files are produced by splitting the audio data transport stream transmitted in a sequence of the AOB_FRAME and storing these AOB_FRAME. . { 3-3_10-l_ll} MPEG2-AAC MPEG2-AAC is described in detail in ISO / IEC 13818-7: 1997 (E) "Information Technology - Generic Coding of Moving Pictures and Associated Audio Information - Part7 Advanced Audio Coding (AAC)" (Information Technology - generic film coding and associated audio information - part 7 advanced audio coding (AAC)). It should be noted that audio objects can only be compressed according to MPEG2-AAC using the parameters in the Table of parameters shown in Figure HA which is defined in ISO / IEC13818-7. This parameter table is constituted in the "Parameter" column, a "Value" column and a "Comment" column. The legend "profile" in the parameter column shows that only the LC profile can be used, as stipulated under ISO / IEC 13838-7. The legend "sampling_frequency # index" (sample rate # index) in the parameter column shows that sampling frequencies of "48kHz, 44.1kHz, 32kHz, 24kHz, 22.05kHz, and 16kHz" can be used. The legend "number_of_data_block_in_frarae" (number of data blocks in frame) in the parameter column shows that a relation of a header is used with respect to a raw_data_block (untreated data block). Note that although this explanation describes the case in which the A0B_FRAME are encoded according to the MPEG-AAC format, the A0B_FRAME can actually be encoded according to another format, such as the MPEG-Layer3 (MP3) or Windows media format Audio (WMA). When this happens, the parameters shown in the parameter tables of Figures 11B or Figure 11C should be used. . { 3 -3_10-2_12} Composition of an AOB_FRAME Although each A0B_FRAME includes audio data that is encoded in accordance with the restrictions described above, the data length of the audio data in each A0B_FRAME is restricted to a playback time of only 20 ms. However, since MPEG2-AAC is a method of variable vibration coding (VBR), the data length, of the audio data in each AOB_FRAME will vary. The following describes the composition of an AOB_FRAME with reference to figure 12. The first level in figure 12 shows the general composition, while the second level shows how each part of an AOB_FRAME is coded. As you can see from the drawing, the ADTS header corresponds to an uncoded part. The audio data includes both an encoded part and an uncoded part. The encoded part of the audio data is constituted by a plurality of pieces of eight octets of encoded data, each of which is produced by encoding a piece of eight octets of audio data using a 56-bit Filekey. When coding is performed on 64-bit audio data pieces, the uncoded part of the audio data is simply a final part of the data that can not be encoded because it is shorter than 64 bits. The third level in Figure 12 shows the content of the ADTS header which is the non-coding part of the AOB_FRAME. The ADTS header has a length of seven octets, and includes a 12-bit synchronization word (which is set to FFF), the data length of the audio data in this A0B_FRAME, and the sampling frequency used when the data is encoded of audio . { 3-3_10-3_13} Setting the octet length of an AOB_FRAME Figure 13 shows the way in which the octet length of the audio data is set in each of the three AOB_FRAME. In Figure 13, the audio data length data # 1 included in A0B_FRAME # 1 is xl, the data length of the audio data # 1 included in A0B_FRAME # 2 is x2, and the data data length is # 1 of audio included in AOB_FRAME # 3 is x3. When the data lengths xl, x2 and x3 are all different, the data length xl will be written in the ADTS header of A0B_FRAME # 1, the data length x2 will be written in the ADTS header of A0B_FRAME # 2, and the length of Data x3 will be written in the ADTS header of AOB_FRAME # 3. Although the audio data is encoded, the ADTS header does not, so that the playback device can know the length of the data of the audio data in an AOB_FRAME by reading the data length provided in the ADTS header of the AOB_FRAME. This completes the explanation of an A0B_FRAME. . { 3 -3_10-4} AOB ELEMENT The following describes the AOB_ELEMENT shown in the fourth level in Figure 10.

An "AOBJELEMENT" is a group of AOB_FRAME. The number of AOB_FRAME in an AOB_ELEMENT depends on the value set in the sampling_f requency_index shown in Figure HA and the coding method used. The number of A0B_FRAME in an AOB_ELEMENT is set so that the total playing time of the included A0B_FRAME is approximately two seconds and, this number depends on the sampling frequency and the encoding method used. . { 3 ~ 3_10-5_14} Number of AOB_FRAME in an AOB_ELEMENT Figure 14 shows the correspondence between the sampling frequency and the number of the A0B_FRAME included in an AOB_ELEMENT. The number N that is provided in Figure 14 represents the reproduction period of an AOB_ELEMENT in seconds. When MPEG-ACC is used as the coding method, the value of N is "2". When sampling_frequency is 48 kHz, the number of the AOB_FRAME included in an AOB_ELEMENT is given as 94 (= 47 * 2), whereas when the sampling_frequency is 44.1 kHz, the number of the A0B_FRAME included in an AOB_ELEMENT is given as 86 (= 43 * 2). When the sampling_frequency is 32 kHz, the number of AOB_FRAME is given as 64 (= 32 * 2), when the sampling_frequency is 24 kHz, the number of the AOB_FRAME is given as 48 (= 24 * 2), it is 22.05 kHz, the number of AOB_FRAME is given as 44 (= 2 * 2), and when sampling_frequency is 16 kHz, the number of AOB_FRAME included in an AOB_ELEMENT is given as 32 (= 16 * 2). However, when you are in an edit operation, such as splitting an AOB, it has been done, the number of AOB_FRAME included in an AOB_ELEMENT at the start or end of an AOB may be less than the number calculated in this way . Although a header or other special information is not provided for each AOB_ELEMENT, the data length of each AOB_ELEMENT is instead displayed by a time search table. . { 3 ™ 3_10-6_15} An example of the playback periods of AOB_ELEMENT and AOB FRAME Figure 15 shows an example of the playback period of AOB_ELEMENT and AOB_FRAME. The first level in Figure 15 shows a plurality of AOB_BLOCK, while the second level shows a plurality of AOB_ELEMENT. The third level shows a plurality of AOB_FRAME. As shown in Figure 15, an AOB_ELEMENT has a playback period of approximately 2.0 seconds, while an AOB_FRAME has a playback period of 20 milliseconds. The "TMSRT_entry" provided to each AOB_ELEMENT shows that the data length of each AOB_ELEMENT is provided in a time search table. When referring to TMSRT_entries, a playback device can perform a forward or backward search when, for example, intermittent music downloads are played by repeatedly playing 240 milliseconds of audio data and then skipping two seconds of audio data in the direction desired. . { 3-3_10-7} AOB BLOCK This completes the explanation of an AOB_ELEMENT. The following describes the concept of AOB_BLOCK shown in the third level of data construction of an AOB file provided in figure 10. Each "AOB_BLOCK" is constituted of valid AOB_ELEMENT. There is only one AOB_BLOCK in each AOB_FILE. Although an AOB_ELEMENT has a playing time of approximately two seconds, an AOB_BLOCK has a maximum playing time of 8.4 minutes. The 8.4 minute limitation is imposed to restrict the size of the time search table to 504 octets or less. . { 3-3_10-8} Restriction of the Time Search Table The following describes in detail the reason why the size of the time search table is restricted by limiting the period of reproduction. When a playback apparatus performs a forward or backward search, the playback apparatus skips reading two seconds of audio data before playing 240 milliseconds. When two seconds of data are skipped, the reproduction apparatus can theoretically refer to the data lengths shown in the ADS headers of AOB_FRAME, although this may mean that the playback apparatus may have to detect consecutively 100 AOB_FRAME (2 seconds / 20 milliseconds) just to skip two seconds of audio data. This may constitute an excessive processing load for a reproduction apparatus. To reduce the processing load of a reproduction apparatus, the read addresses for data at two second intervals can be written into a time search table which is referenced by the reproduction apparatus when a search is performed forward or backward When writing information that allows the reading addresses to be two to four seconds ahead or behind so that they are quickly found in the time search table (such information is AOB_ELEMENT data sizes), a reproduction device only needs to be referenced to this information when you perform a forward or backward search. The data size of audio data with a playback time of two seconds will depend on the bit rate used when playing the audio data. As stated above, a bit rate in the range of 16 Kbps to 144 Kbps is the one used, so that the amount of data reproduced in two seconds will be in the range of 4 KB (= 16 Kbps x 2/8). ) to 36 KB (= 144 Kbps x 2/8). Since the amount of data played in two seconds will be in a range of 4 KB to 36 KB, the data length of each entry in the time search table to write the data length of audio data needs to be two octets (= 16 bits) long. This is because a 16-bit value is capable of expressing a number in the range of 0-64 KB. On the other hand, if the total data size of the time search table needs to be restricted to 504 bytes (This is the data size of the TKTMSRT described below), for example, the maximum number of entries in the time search table can be calculated as 504/2 = 252.

Since an entry is provided every two seconds, the playing time corresponding to this maximum of 252 entries is 504 seconds (= 2s * 252), or in other words, 8 minutes and 24 seconds (= 8.4 minutes). This means that setting the maximum replay period for an AOB_BLOCK of 8.4 minutes limits the data size of the time search table to 504 octets. . { 3-3_10-9} Regarding the AOB This concludes the description of the A0B_BL0CK. The following describes the AOB. The AOBs shown in the second level of Figure 10 are regions that have non-valid areas at both ends. Only one AOB is presented in each AOB file. Invalid areas they are regions that are read and written together with the A0B_BL0CK and stored in the same groups as the AOB_BLOCK. The start and end position of the AOB_BLOCK within the AOBs is shown by the BITs included in the navigation data. These BITs are described in detail later in this specification. This completes the explanation of which ones are stored in an AOB file. The following describes what kind of content is played when eight AOB and AOB_BLOCK shown in the AOB file in Figure 9 are read successively. . { 3-3_10-10_16} Figure 16 shows the playback content when the AOB and the AOB_BLOCK in this AOB file are read successively. The first level in Figure 16 shows the eight AOB files in the user's region, while the second level shows the eight AOBs recorded in these AOB files. The third level shows the eight AOB_BLOCK included in these AOB. The fifth level shows the titles of five contents constituted by these AOB files. In this example, the "content" is five songs SongA, SongB, SongC, SongD and SongE, while the "title" is a music album consisting of these five songs. Dashed lines ASI, ASI, AS3,. . . AS7, and AS8 show the correspondence between the A0B_BL0CK and the parts within which the album is divided, so that the fourth level in figure 16 shows the units used to divide the music album shown in the fifth level. With reference to dashed lines, you can see that AOB_BLOCK is included in A0B # 1, it is a song (SongA) with a playback time of 6.1 minutes. He AOB_BLOCK including AOB # 2 is a song (SongB) with a playback time of 3.3 minutes. The AOB_BLOCK included in A0B # 3 is a song (SongC) with a playback time of 5.5 minutes. In this way, "AOB001. SAI" to "AOB003.SA1" correspond each to a different song. The sixth level of Figure 16 is a sequence of tracks consisting of tracks TrackA to TrackE. These TrackA-TrackE tracks correspond to the five songs SongA, SongB, SongC, SongD and SongE and each is treated as a separate playback unit. On the other hand, A0B # 4 has a playback time of 8.4 minutes and is the first part (or "header") of Song Song that has a playback time of 30.6 minutes. The A0B_BL0CK included in A0B # 5 and AOB # 6 are the middle parts of the song SongD and also have playback periods of 8.4 minutes. The A0B_BL0CK included in A0B # 7 is the final part of the SongD song and has a playback time of 5.4 minutes. In this way, a song that has a total playing time of 30.6 minutes is divided into (8.4 + 8.4 + 8.4 + 5.4-minutes) parts each included in a different AOB. As you can see from figure 16, each song included in an AOB file is subjected to a maximum playing time of 8.4 minutes. This explanation clearly shows that limiting the ABO reproduction periods as described above restricts the data size of the time search table that corresponds to each AOB. The following describes the navigation data included in each time search table. . { 3-3_8A, B-2} The navigation data consists of the two files "SD_Audio.PLM" and "SD_Audio .TKM" mentioned above. The file "SD_Audio .PLM" includes the PlaylistManager, while the file "SD_Audio.TKM" includes the TrackManager. As mentioned as part of the explanation of the presentation data, a plurality of AOB files store the encoded AOBs, although not other information, such as the reproduction period of the ABOs, the names of the songs represented by the AOBs or the credits for the song writer that are provided. Although a plurality of AOBs are recorded in a plurality of AOB files, no indication is given regarding the playback order of the AOBs. To inform a reproduction apparatus of such information, the TrackManager and PlaylistManager are provided. The TrackManager shows the correspondence between the AOB recorded in the AOB files and the tracks, and includes a plurality of pieces of the track management information so that each provides a variety of information, so that the reproduction period of the AOB and the names of the songs as well as the song writers of the various AOB. In this specification, the term "track" refers to a reproduction unit with meaning for users, so that when copyright music is stored on a flash memory card 31, each song is a separate track. Conversely, when an "audio book" (ie, copyrighted literature stored as an audio recording) is recorded on an instant memory card 31, each chapter or paragraph can be set as a separate track. The TrackManager is provided to handle a plurality of the AOB recorded in a plurality of AOB files as a group of tracks. A Playlist establishes the order of reproduction of a plurality of tracks. A plurality of Playlist can be included in the PlaylistManager. The following describes the TrackManager with reference to the drawings. . { 17-1_18} Detailed composition of the PlaylistManager and TrackManager Figure 17 shows the detailed composition of PlaylistManager and TrackManager in this mode, as a hierarchy. Figure 18 shows the sizes of PlaylistManager and TrackManager. The right side of Figure 17 shows the incised ones on the left side in more detail, with dashed lines indicating which paragraphs are shown in greater detail.

As shown in Figure 17, TrackManager is made up of track information (TKI) # 1, # 2, # 3, # 4. . . #n, as shown by dashed line hl. These TKIs are information for managing the AOB recorded in AOB files as tracks, and each one corresponds to a different AOB file. From figure 17, it can be seen that each TKI is made up of Track_General_Inf orma ti on (TKGI), Track_Text_Information (TKTXTI_DA) in which the unique text information for each track can be written and a Track_Time_Search_Table (TKTMSRT) that serves as a time search table. From Figure 18, it can be seen that each TKI has a fixed size of 1,024 octets, which means that the total TKGI size in the TKTXTI_DA is set at 512 octets due to the size of TKTMSRT which is fixed at 512 octets . In the TrackManager, a total of 999 TKI can be set. As shown by broken line h.3, the TKTMSRT is made up of TMSRT_Header and TMSRT_entries # 1, # 2, # 3. . . #n. . { 17-2_19} Correspondence of TKI with the AOB and ABO files Figure 19 shows the manner in which the TKIs shown in Figure 17 correspond to the AOB files and the AOBs shown in Figure 16. The boxes in the first level in Figure 19 show a sequence of tracks made up of the tracks TrackA to TrackE, the large box in the second level shows the TrackManager while the third and fourth levels show the eight AOB files that are provided in figure 16. The eight AOB files are recorded in the eight AOBs shown in figure 16, and they constitute an album of music that include tracks TrackA, TrackB, TrackC, TrackD and TrackE. The second level shows the eight TKI. The numbers "1", "2", "3", "4" assigned to each TKI are the serial numbers used to identify each TKI, where each TKI corresponds to the AOB file that has been provided with the same number. series 001,002,003,004,005. . . . With this in mind, it can be seen from Figure 19 that TKI # 1 corresponds to the file "AOB001.SAI", that TKI # 2 corresponds to the file "AOB002. SAI", TKI # 3 corresponds to the file " AOB003.SA1"and TKI # 4 corresponds to the file" AOB004.SA1". The correspondence between the TKI and AOB_FRAME is shown by the arrows TAI, TA2, TA3, TA4. . . in Figure 19. In this way, each TKI corresponds to a different AOB recorded in an AOB file that provides detailed information that applies only to the corresponding AOB. . { l7-3_20} Data composition of a TKTMSRT The following describes the information that applies to only one of the AOB recorded in the AOB files, beginning with TKTMSRT. Figure 20 shows the composition of TKTMSRT data in detail. The right side of Figure 20 shows the detailed data composition of the header of the time search table (TMSRT_Header). In Figure 20, the TMSRT_Header has a data size of eight octets, and consists of three fields. The first of two octets is a TMSRT_ID, the next two Octets are reserved and the final four octets are the total TMSRT_entry_Number. A unique ID to identify the TMSRT is registered in "TMSRT__ID". The total number of TMSRT_entries in the TMSRT is recorded in "TotalTMSRT_entry Number". . { 17-3_21-1} Specific example of TKTMSRT The following describes in detail TKTMSRT. The figure 21 shows an example of a TKTMSRT. The left side of Figure 21 shows an AOB, while the right side shows the corresponding TKTMSRT. The AOB on the left side of Figure 21 is comprised of a plurality of AOB ELEMENT numbered # 1, #2. 3 . . . #n occupying the regions numbered AR1, AR2, AR3. . . ARn to the right. Numbers such as "0", "32000", "64200", "97000", "1203400" and "1240000" show the relative directions of the areas AR1, AR2, AR3, ARn-1, ARn occupied by the AOB_ELEMENT with regarding the start of A0B_BL0CK. As examples, AOB_ELEMENT # 2 is recorded in a position that is at a distance "32000" from the start of AOB_BLOCK, while "AOB_ELEMENT # 3 is recorded at a position that is at a distance" 64200"from the start of A0B_BL0CK and AOB_ELEMENT # n-1 is recorded in a position that is at a distance "1203400" from the start of AOB_BLOCK It should be noted that the distance between each region occupied at the start of AOB_BLOCK is not a multiple of a certain value, which means that the regions occupied by AOB_ELEMENT are not the same size. The reason that the occupied regions have different sizes is that variable amounts of data are used to encode each A0B_FRAME. Since the size of the region occupied by each AOB_ELEMENT differs, it is necessary to inform the player in advance of the position of each AOB_ELEMENT in an AOB when a jump is made at the start of an AOB_ELEMENT. For this purpose, a plurality of TMSRT entries are provided in TKTMSRT. The arrows RT1, RT2, RT3. . . RTn-1, RTn show the correspondence between regions AR1, AR2, AR3. . . ARn-1, ARn occupied by each AOB_ELEMENT and TMSRT_entry # l, TMSRT_entry # 2, TMSRT_entry # 3. . . TMSRT_entry # n-l, TMSRT_entry # n. In other words, the size of the ARl region occupied by A0B_ELEMENT # 1 is written in TMSRT_entry # l, while the sizes of the AR2 and AR3 regions occupied by A0B_ELEMENT # 2 and A0B_ELEMENT # 3 are written in TMSRT_entries # 2 and # 3 . Since the occupied area ARl takes the region from the beginning of the ABO to the start of A0B_ELEMENT # 2"32000", the size "32000" (= 32000-0) is written in TMSRT_entry # l. The occupied area AR2 captures the region from the start of A0B_ELEMENT # 2"32000" at the start of A0B_ELEMENT # 3"64200", so that the size "32200" (= 64200-32000) is written in TMSRT_entry # 2. The occupied area AR3 takes the region from the start of AOB_ELEMENT # 3"64200" to the start of A0B_ELEMENT # 4"97000", so that the size "32800" (= 97000-64200) is written in TMSRT_entry # 3. In the same way, the occupied area ARl captures the region from the beginning of AOB_ELEMENT # n-l "1203400" at the start of AOB_ELEMENT # n "1240000", the size "36600" (= 1240000-1203400) is written in TMSRT_entry # n-l. . { l7-3_21-2} As you read TKTMSRT In this way, the data sizes of AOB_ELEMENT are written in a time search table. However, since the data length of each AOB_BLOCK is restricted to a maximum of 8.4 minutes, the total number of AOB_ELEMENT included in a single AOB is limited to a predetermined number ("252" as shown in Figure 20) or less. Since the number of AOB_ELEMENT is restricted, the number of TMSRT_entries corresponding to AOB_ELEMENT is also restricted, which restricts the size of TKTMSRT including these TMSRT_entries within a predetermined size. Since the size of TKTMSRT is restricted, a reproduction apparatus can read and use the TKIs in the following manner. The reproduction apparatus reads a certain AOB and upon starting the reproduction of the AOB, reads the corresponding TKI and stores it in a memory. This corresponding TKI is kept in memory while the reproduction of this AOB continues. Once the AOB playback is finished, the next AOB is read and when playback of this AOB begins, the playback apparatus overwrites the TKI corresponding to this next AOB within the memory instead of the previous TKI. This subsequent TKI is kept in memory while the reproduction of that next AOB continues.

By reading and storing the TKIs in this manner, the necessary capacity of the memory in the reproduction apparatus can be minimized while still allowing special reproduction functions such as advancement and retraction to be carried out. Although the present modality describes the case in which the data length from the first address of an AOB_ELEMENT to the first address of the next AOB_ELEMENT is written in the TMSRT_entry, in relation to the addresses from the start of AOB_BLOCK to the first address of AOB_ELEMENT can be written to it instead of this one. . { l7-3_21-3} Specifying a group that includes an AOB ELEMENT The following describes the way in which an AOB_ELEMENT can be read using TKTMSRT. The TKTMSRT included the size of each AOB_ELEMENT, so that when AOB_ELEMENT # y, which is the very first AOB_ELEMENT from the beginning of an AOB, to be read, the group u that satisfies Equation 1 that is provided in the above calculate, and read the data placed with the deviation v from the beginning of the group u.

Equation 1 Group u = (Total of TMSRT_entries from A0B_ELEMENT # 1 for AOB_ELEMENT # y-l + DATA_Offset) / Group size Deviation v = (Total of TMSRT_entries from AOB_ELEMENT # l to AOB_ELEMENT # y- 1 + DATA_Offset) size of group mod where c = a mod b indicates that c is the reproduced when a is divided by b The DATA_Offset is written to the BIT and is described later in this specification. . { 17-4} TKTXI_DA This completes the explanation of the time search table (TKTMSRT). The following describes the Track_Text_Information Data Area (TKTXI_DA) registered at the top of TKTMSRT. Track_Text_Inf ormation Data Area is used (TKTXTI_DA) to store text information that shows the name of the artist, album name, mixer, producer and other similar information. This area is provided even when such text information does not exist. . { 17-5} TKGI The following describes the TKGI registered at the top of TKTXI_DA. In Figure 17, several sets of information displayed as the identifier "TKI_ID" of the TKI, the TKI number "TKIN", the size of TKI "TKI_SZ", a link pointer for the following TKI "TKI_LNK_PTR", block attributes "TKI_BLK_ATR", a reproduction period "TKI_PB_TM", the audio attributes "TKI_AOB__ATR", an "ISRC", and block information "BIT". Note that only part of this information has been shown in Figure 17 to simplify the representation. . { l7-5_22-l} TKGI The following describes the composition of a TKGI text in detail, with reference to Fig. 22. The difference between Fig. 17 and Fig. 22 is that the TKGI data composition shown in Fig. 17 is placed on the left side. of this drawing and that the bit compositions of "TKI BLK ATR", "TKI AOB ATR" and "ISRC" are clearly displayed. . { l7-5_22-2} TKI_ID A unique ID for TKI is written in "TKI_ID". In this modality, the two-octet code "A4" is used. . { l7-5_22-3} TKIN A TKI number in the range of 1 to 999 is written in "TKIN". Note that the TKIN of each TKI is unique. In the present embodiment, the position of each TKI in the TrackManager is used as the TKIN. This means that "1" is written as the TKI number of TKI # 1, "2" is written as the TKI number of TKI # 2 and "3" is written as the TKI number of TKI # 3. . { l7-5_22-4} TKI_SZ The TKI data size in octet units is written to "TKI_SZ". In Figure 22, 1024 octets are provided as the data size of the TKI, such that each TKI in the present embodiment has a length of 1.024 octets. . { 17-5_22_5} TKI_LNK_PTR The TKIN of the TKI to which the present TKI is attached is written in "TKIN_LNK-PTR". The following describes such signals between TKI. When a track is constituted by a plurality of AOB which are recorded in a plurality of AOB files, these AOB files will be managed as a single track by linking the plurality of the TKIs corresponding to these AOB files. To link a plurality of TKIs, it is necessary to show the TKI of the AOB file that follows after the AOB file of the present TKI. Accordingly, the TKIn of the TKIs exhibiting the present TKI are written in TKI_LNK_PTR. . { l7-5_22-6_19} TKI_LNK_PTR The following describes the adjustments made to the TKI_LNK_PTR and the eight TKIs shown in Figure 19. The track information numbered # 1 through # 3 and # 8 each correspond to separate tracks, so it does not set information on which TKI_LNK_PTR. The track information TKI # 4, TKI # 5, TKI # 6, TKI # 7 correspond to the four AOB files that constitute TrackD, so that the following track information is indicated in the TKI_LNK_PTR for these TKI. As shown by arrows TL4, TL5 and TL6 in Figure 19, "TKI # 5" is set in TKI_LNK_PTR of TKI # 4, "TKI # 6" is set in TKI_LNK_PTR of TKI # 5 and "TKI" is set # 7"TKI_LNK_PTR OF TKI # 6. As a result, a reproduction apparatus can refer to the TKI_LNK_PTR provided in the TKI corresponding to these four files to AOB and thus find the four TKI, TKI # 4 to TKI # 7 and the four AOB files "AOB004. SA1"to" AOB007.SA1"that make up a single track, trackD. . { 17-5_22-7} TKI_BLK_ATR The attributes of the present TKI are written in "TKI_BLK_ATR". In Fig. 22, the information shown within dashed lines extends from the TKI_BLK_ATR showing the bit composition of TKI_BLK_ATR. In Figure 22, the TKI_BLK_ATR consisting of 16 bits long is shown, with the bits from b3 to bl5 reserved for future use. The three bits of the b2 to bO bit are used to show the attributes of the TKI. When a TKI corresponds to a complete track, the value "00b" is written, it writes the value TKI_BLK-ATR (this setting is later called "Track"). When several TKIs correspond to the same track, the value "001b" is written in the TKI_BLK_ATR of the first TKI (this setting is subsequently called "Head_of_Track" (start of the track), the value "010b" is written in the TKI_BLK_ATR of the TKI corresponding to the AOB in the middle part of the track (this setting is later called "Midpoint_of: _Track"), and the value "011b" is written in TKI_BLK_ATR of the TKI and corresponding to the AOB at the end of the track (This setting is referred to later as "End__of_Track.") When TKI is not used but there is a TKI region, which is equivalent to saying when there is a deleted TKI, the value "100b" is written in the TKI_BLK_ATR (this is set to called "Unused" in the following.) When there is an unused TKI and there is no TKI region, the value "101b" is written in a TKI BLK ATR. . { l7-5_22-8_19} TKI_BLK_ATR setting example The following describes the TKI_BLK_ATR settings for each TKI in the example shown in Figure 19. By referring to the TKI_BLK_ATR of each TKI, you can see that the four TKI # 1 pairs ("AOB001. SAI"), TKI # 2 ("AOB002.SAI"), TKI # 3 ("AOB003. SAI"), and TKI # 8 ("AOB008. SAI") each correspond to separate tracks since the TKI_BLK_ATR of each TKI # 1, TKI # 2 , TKI # 3 and TKI # 8 is established as a "Track".

The TLK_BLK_ATR of TKI # 4 is set to "Head_of_Track", the TLK_BLK_ATR of TKI # 7 is set to "End_of_Track", and the TLK_BLK_ATR of TKI # 5 and TKI # 6 are set to "Midpoint_of_Track". This means that the AOB file ("AOB004.SAI") corresponds to the TKI # 4 is the start of a track, the AOB files ("AOB005. SAI") and ("AOB006. SAI") correspond to TKI # 5 and TKI # 6 are the midpoints of the track in the AOB file ("AOB007, SAI") corresponds to TKI # 7 is the end of the track. When classifying the combinations of TKI and the file Corresponding AOB according to the settings of TKI_BLK_ATR in TKI, it can be seen that the combination of TKI # 1 and "AOB001.SA1" constitutes the first track (TrackA). In the same way, the combination of TKI # 2 and "AOB002.SA1" constitutes a second track (TrackB) and the combination of TKI # 3 and "AOB003.SA1" constitutes a third track (TrackC). The combination of TKI # 4 and "AOB004.SA1" constitutes the first part of a fourth track (TrackD), the combination of TKI # 5 with "AOB005.SA1" and TKI # 6 with "AOB006.SA1" constitute the central parts of TrackD and the combination of TKI # 7 and "AOB007.SA1" constitutes the final part of TrackD. Finally, the combination of TKI # 8 and "AOB008.SA1" constitutes a fifth track (TrackE). . { l7-5_22-9} TKI_PB_TM The playing period of the track (song) consisting of AOB registered in the AOB file corresponding to a TKI is written in "TKI_PB_TM". When a track is constituted of a plurality of TKI, the entire playing period of the track that writes in TKI_PB__TM of the first TKI corresponding to the track, while the corresponding AOB playback period is written within the second and the following TKI for the track. . { 17 -5_22-10} TKI_AOB_ATR The coding conditions used when an AOB is produced which is information such as (1), the sampling frequency at which the AOB is recorded in the corresponding AOB file, (2) the bit rate of the transfer and (3) the number of channels, it is written in the "TKI_AOB_ATR" in a TKI. The bit composition of TKI-AOB_ATR is shown within dashed lines extending from "TKI-AOB_ATR" in Figure 22. In Figure 22, the TKI-AOB_ATR is comprised of 32 bits, with the coding mode written in the four-bit field from the bl6 bit to the bl9 bit. When the AOB is encoded according to the MPEG-2 AAC (with an ADTS header), the value "0000b" is written within this field, whereas when AOB is encoded according to MPEG-layer 3 (MP3), it is write the value "0001b". When the AOB is encoded in accordance with Windows Media Audio (WMA), the value "0010b" is written in this field. The bit rate used when encoding the AOB that is written in the eight-bit field between bit bl5 and bit b8. When the AOB encodes according to MPEG-2 AAC (with the ADTS header), a value between "16" and "72" is written in this field, then while the AOB is encoded according to MPEG-1 layer 3, it is write a value between "16" and "96". When the AOB is encoded according to MPEG-1 layer 3 (MP3) LSF, a value between "16" and "80" is written in this field, whereas when an AOB is encoded according to Windows Media Audio (WMA), a value between "8" and "16" is written. The sampling frequency used when encoding the AOB is written in the four-bit field between bits b7 and b4. When the sampling frequency 48 kHz, the value "000b" is written in this field. When the sampling frequency is 44.1 kHz, the value is "0001b", when the sampling frequency is 32 kHz, the value is "0010b", when the frequency is 24 kHz, the value is "0011b", when the Sampling frequency is 22.05 kHz, the value is "0100b", and when the sampling frequency is 16 kHz, the value is "0101b". The number of channels is written in the three-bit field of bit b3 to bit bl. When a channel is used (ie, monaural), in this field "000b" is written, whereas when two channels are used (ie stereophony), the value "001b" is written in this field. The twelve bit field of bit b31 to bit b20 is reserved for future use, as is the bit bO. . { l7-5_22-ll} ISRC An ISRC (International Standard Recording Code) is written in the TKGI. In Figure 22, dashed lines extending from the "ISRC" box show the contents of the ISRC. As shown in the drawing, the ISRC is composed of ten octets, with a recording article code (# 12) written within the four-bit field between bit b4 and bit b7. A recording code / recording item code (# 11) is written in the four-bit field between bit b8 and bit bll. A recording code (ISRC # 10, # 9, # 8) is written in the twelve bit field between bit bl2 and bit b23. A Year-of-Recording code (ISRC # 6, # 7) is written in the eight-bit b24 field and the b31 bit.

A First Owner Code (ISR # 3, # 4, # 5) is written in the six-bit field between bit b32 and bit b37, the six bit field between bit b40 and the bit b45, and the six-bit field between bit b48 and bit b53. A country code (ISRC # 1, # 2, # 3) is written in the six-bit field between bit b56 and bit b61 and the six-bit field between bit b64 and bit b69. A one-bit validity flag is written in a one-bit field consisting of bit b79. A detailed description of ISRC can be found in ISO3901: 1986"Documentation-International Standard Recording Code (ISRC)". . { l7-5_22-12_23A-l} BIT The "Block Information Table (BIT)" is a table for the administration of an AOB_BLOCK and has the detailed composition shown in Figures 23A and 23B. As shown in Figure 23A, a BIT is constituted of a DATA_OFFSET field that occupies a region from the 60th octet to the 63rd octet and a SZ_DATA field that occupies a region from the 64th octet to the 67th byte, a TMSRTE_Ns field that occupies a region from the 68th octet to the 71st byte, a FNs_lst_TMSRTE field that occupies a region from the 72nd byte to the 73rd byte, a FNs_Last_TMSRTE that occupies a region from the 74th octet to the 75th byte, a FNs_Middle_TMSRTE field that occupies a region from the 76th octet to the 77th octet, and a TIME_LENGTH field that occupies a region from 78th octet to 79th octet. Each of these fields is described in detail in the following. . { l7-5_22-12_23A-2} DATA Offset The relative addresses of the start of an AOB_BLOCK from the boundary between the groups are written to "DATA_OFFSET" as a given value in octet units. This expresses the size of an invalid area between an AOB and in AOB_BLOCK. As an example, when a user records a radio broadcast on an instant memory card 31 as AOB and wishes to suppress the introduction part of a track on which a DJ has spoken, the DATA_OFFSET in the BIT can be adjusted to have the track played without the part that includes the voice of the DJ. . { l7-5_22-12_23A-3} SZ DATA The data length of an AOB_BLOCK expressed in octet units is written to "SZ_DATA". By subtracting a value produced by adding SZ_DATA to DATA_Offset of the file size (an integer multiple of the group size), one can find the size of the invalid area that follows AOB_BLOCK. . { l7-5_22-12_23A-4} TMSRTE NS The total number of TMSRT_Entries included in an AOB_BLOCK is written to "TMSRTE_Ns". . { l7-5_22-12_23A-5} "FNs_ls t_TMSRTE", "FNs_Las t_TMSRTE", "FNs Middle TMSRTE" The number of A0B_FRAME included in AOB_ELEMENT placed at the beginning of a present AOB_BLOCK is written to "FNs_lst_TMSRTE". The AOB_FRAME number included in AOB_ELEMENT placed at the end of the AOB_BLOCK is written to "FN_Last_TMSRTE". The number of the AOB_FRAME included in each AOB_ELEMENT separated from the start and end of the AOB_BLOCK present, which are the AOB_ELEMENT in the middle part of AOB_BLOCK, are written in "FNsJMiddleJTMSRTE". The reproduction period of an AOB_ELEMENT is written in the format shown in Figure 23C in the "TIME_LENGTH" field to an accuracy in the order of milliseconds. As shown in Figure 23C, the "TIME_LENGHT" field is 16 bits long. When the encoding method used in MPEG-ACC or MPEG-Capa3, the reproduction period of an AOB_ELEMENT is two seconds, so that the value "2000" is written in the "TIME_LENGTH" field. . { l7-5_22-13__23B} Figure 23B shows the number of A0B_FRAME indicated by "FNs_Middle_TMRTE". In the same manner as in Figure 14, Figure 23B shows the relationship between sampling_frequency and the number of A0B_FRAME included in an AOB_ELEMENT in the middle part of A0B_BL0CK. The relationship between sampling_frequency and the number of frames included in AOB_ELEMENT shown in Figure 23B is the same as that shown in Figure 14, which is to say that the number of frames in an AOB_ELEMENT depends on the sampling frequency used. The number of frames written in "FNs_lst_TMSRTE" and "FNs_Last_TMSRTE" will fundamentally be the same as the number written in "FNs_Middle_TMSRTE", although when an invalid area is present in the AOB_ELEMENTS at the start or end of an AOB_BLOCK, the values given in "FNs_lst_TMSRTE" or "FNs_Last_TMSRTE" will differ from the value in "FNS Middle TMSRTE". . { l7-5_22-14_24} Example of a stored AOB_ELEMENT Figure 24 shows the groups 007 to OOE that store the AOB constituted from AOB_ELEMENT # l to A0B_ELEMENT # 4. The following describes the settings in the BIT when AOB is stored as shown in Figure 24. The AOB_ELEMENT # the A0B_ELEMENT # 4 that are stored in group 007 to the OOE group are indicated in Figure 24 by the triangular flags with adjusted TMSRT_entries in the TKI for each AOB_ELEMENT # 1 to A0B_ELEMENT # 4. In this example, the first part of A0B_ELEMENT # 1 at the start of AOB is stored in group 007, while the last part of A0B_ELEMENT # 4 at the end of AOB is stored in the OOE group. The AOB_ELEMENT # l to # 4 occupy the region between mdO in group 007 to md4 in the OOE group. As shown by the sdl arrow in Figure 24, the SZ_DATA in the BIT indicates the AOB_ELEMENT # 1 to # 4 that occupy a region from the start_ of group 007 to the end of the OOE group, and thus does not indicate that there are areas invalid udO and udl in groups 007 and OOE that are not occupied by an AOB_ELEMENT. On the other hand, the AOB also includes the udO and udl parts that are present in groups 007 and OOE but that are not occupied by AOB_ELEMENT # l or AOB_ELEMENT # 4. The DATA_0ffset provided in the BIT provides the length of the unoccupied region udO, that is, from the beginning of A0B_ELEMENT # 1 in relation to the start of group 007. In Figure 24, AOB_ELEMENT # l occupies a region of mdO in group 007 to mdl in group 008. This AOB_ELEMENT # l does not occupy the whole group 008, with the remaining part of the group occupied by A0B_ELEMENT # 2. A0B_ELEMENT # 4 occupies a region of md3 in the middle part through the group OOC to md4 in the middle part through the OOE group. In this way, AOB_ELEMENT can be stored across group boundaries, or in other words; AOB_ELEMENT can be recorded without considering the boundaries between groups. The "FNs__lst_TMSRTE" in the BIT shows the number of frames in AOB_ELEMENT # l that are located in groups 007 and 008, while "FNs_Last__TMSRTE" in the BIT shows the number of frames in AOB_ELEMENT # 4 that are located in the OOC groups to OOE. In this way, the AOB_ELEMENT can be placed freely without considering the boundaries between the groups. The BIT provides information that shows the deviation from a group limit to an AOB_ELEMENT and the number of frames in each AOB ELEMENT. . { l7-5_22-14_25} Use of the number of tables provided in each AOB ELEMENT (part 1) The following describes how the number of frames in each AOB_ELEMENT provided in the BIT is used. This number of frames provided in the BIT is used when performing a forward or backward search. As mentioned above, such operations reproduce 240 milliseconds of data after the first data jump with a playback time of two seconds. Figure 25 shows how AOB_FRAME # x + l, which can be played later, is set when a forward search is made starting from an AOB_FRAME # x in an AOB_ELEMENT # and in an AOB. Figure 25 shows the case when a user selects a forward search during the playback of "AOB_FRAME # x included in AOB_ELEMENT # y In Figure 25" t "represents the intermittent playback period (here, 240 milliseconds), "f (t)" shows the number of frames corresponding to this intermittent playback period, "skip_time" shows the length of the period that must be skipped between the intermittent playback periods (here, two seconds), "f (skip_time)" shows the number of frames corresponding to the skipped time. Intermittent reproduction is obtained by repeating the three procedures (1), (2) and (3) described in the following. (1) The playback device referenced by the TMSRT_entry in TKTMSRT and skips to the start of the flag symbol (AOB_ELEMENT). (2) The reproduction apparatus performs playback for 240 milliseconds. (3) The playback device jumps to the start of the next flag symbol (AOB_ELEMENT). The AOB_FRAME # x + l that exists 2s + 240ms from AOB_FRAME # x included in AOB_ELEMENT # and will definitely be present in AOB_ELEMENT # y + l. When you specify the AOB_FRAME # x + l which is 2s + 240ms from AOB_FRAME # x, the first address of the following AOB_ELEMENT # and + l can be calculated immediately upon reading a TMSRT_entry from TKTMSRT, through a playback device which can not know the number of AOB_ELEMENT # and + starting from the start address of AOB_FRAME # x + starting from TMSRT_entry only. To calculate this AOB_FRAME number, it is necessary to subtract the total number of tables included in AOB_ELEMENT # and from the total of (1) the number #x that shows the position of AOB_FRAME # x in relation to the start of AOB_ELEMENT # y, (2) f (t) and (3) f (skip_time). To simplify the calculation of the relative table position of AOB_FRAME # x + l in AOB_ELEMENT # and + l, the "Fns_lst_TMSRTE", for each "FNs_Middl e_TMSRTE", and "FNs_Last_TMSRTE" for each AOB_ELEMENT is written in the BIT as mentioned before . { l7-5_22-15_26A} Use of the number of frames provided in each AOB_ELEMENT (part 2) The number of frames written in BIT is also used when a playback apparatus performs a time search function when playback starts at a specified point using a time code. In figure 26A, it is shown how a reproduction apparatus can specify an AOB_ELEMENT and an AOB_FRAME corresponding to the moment of start of reproduction indicated by the user. When playback will begin for a time indicated by the user, the indicated time (in seconds) is set in the Jmp_Entry field, and a playback must start with an AOB_ELEMENT # y and an AOB_FRAME in a position x that satisfies Equation 2 that it is provided later.

Equation 2 Jmp_Entry (sec) = (FNs_lst_TMSRTE + FNs_middle_TMSRTE * and + x) * 20 msec Since "FNs_lst_TMSRTE" and "FNs_Middle_TMSRTE" are provided in the BIT, these can be substituted in Equation 2 to calculate the AOB_ELEMENT # y and AOB_FRAME # x. By doing this, a playback device can reference TKTMSRT of the AOB, calculate the first address of A0B_ELEMENT # and + 2 (which is the (and + 2) this AOB_ELEMENT in this AOB), and start the search by AOB_FRAME # x from this first address. When finding the AOB_FRAME? the reproduction apparatus starts production from this box. In this way, the reproduction apparatus can start the reproduction of data from the moment indicated by Jmp_Entry (in seconds). In this way, a reproduction apparatus does not need to search for the ADTS header parts of the A0B_FRAME and only needs to perform the search in the TMSRT_entries that are provided in the TKTMSRT. This means that the reproduction apparatus can find a reproduction position corresponding to a playback time indicated at high speed. In the same way, when Jmp_Entry is set and the time search function is used in a track that is constituted by a plurality of AOBs, the reproduction apparatus need only calculate an AOB_ELEMENT # yy AOB_FRAME # x satisfying equation 3 a continuation.

Equation 3 Jmp_Entry (in seconds) = Playback period from A0B # 1 to AOB # n + (FNs_lst_TMSRTE (# n + l) + FNs_middle_TMSRTE (# n + l) * and + x) * 20m sec The total playing time of the AOBs from A0B # 1 to A0B # 2 is as follows.

Total reproduction period from A0B # 1 to AOB # n = ["FNs_lst_TMSRTE" (# 1) + "FNs_Middle_TMSRTE" (# 1) * (Number of TMSRT_entries (# 1) -2) + "FNs_Last_TMSRTE" (# 1) + "FNs_lst_TMSRTE" (# 2) + ("FNs_Middle_TMSRTE" (# 2) * Number of TMSRT_entries (# 2) -2) + "FN s_L a s t _TMS TE" (# 2) + "FNs_lst_TMSRTE" (# 3) + ("FNs_Middle_TMSRTE" (# 3) * Number of TMSRT_entries (# 3) -2) + "FNs_Middle_TMSRTE" (# 3). . . + "FNs_lst_TMSRTE" (#n) + ("FNs_Middle_TMSRTE" (#n) * Number of TMSRT_entries (#n) -2) + "FNs_Last_TMSRTE" (#n)] * 20 ms Having calculated an AOB # n, an AOB_ELEMENT # y and an AOB_FRAME # x satisfying Equation 3, the playback device refers to the TKTMSRT that corresponds to the AOB # n + l, and searches for the AOB_FRAME? Ési or from the address in which the element AOB_ELEMENT (y + 2) th is placed (ie, AOB_ELEMENT # and + 2), and playback starts from this AOB FRAME? th. . { l7-5_22-16_27A, B} Deleting an AOB file and a TKI This completes the explanation of all the information included in the TKI. The following describes how the TKI is updated in the following four cases. In the first case (case 1), a track is deleted. In the second case (case 2) a track is deleted and a new track is recorded. In the third case (case 3), two of a plurality of tracks are selected and combined into a single track. Finally, in the fourth case (case 4), a track is divided to produce two tracks. The following describes case 1, where a track is deleted. Figures 27A and 27B show the partial deletion of a track. The example in Figures 27A and 27B corresponds to the TrackManager shown in Figure 19 and assumes that the user has indicated the partial deletion of Track B. The AOB that corresponds to Track B is recorded in "AOB002.SA1" which is associated with TKI # 2. This means that the deletion of "AOB002.SA1" is accompanied by the setting of "not used" in TKI_BLK_ATR of TKI # 2. This state where "AOB002.SA1" has been deleted and has been set "not used" in the TKI_BLK_ATR of TKI # 2, is shown in Figure 27B. Since "AOB002.SAI" has been deleted, the region that was previously occupied by "AOB002.SA1" is released to become an unused region. As mentioned before, the other change is when "not used" is set in TKI_BLK_ATR of TKI # 2. . { l7-5_22-17_28A, B} Assignment of the TKIs when registering a new AOB The following describes case 2, where a new track is recorded after the deletion of a track. Figure 28A shows the TrackManager after the deletion of tracks has been checked several times. As shown in Figure 28A, if the clues corresponding to TKI # 2, TKI # 4, TKI # 7, and TKI # 8 have been deleted, then "not used" is set in the TKI_BLK_ATR of these TKI. Although the AOB files are deleted in the same way as conventional data files, the TrackManager is updated only by setting "not used" in the TKI_BLK_ATR of the corresponding TKI. This means that the TKI, whose TKI_BLK_ATR is set to "not used", can appear in different places in the TrackManager. Figure 28B shows how to write a new TKI and an AOB file when a TKI is present whose TKI_BLK_ATR is "not used" in the TrackManager. As in Figure 28A, the TKI # 2, TKI # 4, TKI # 5, TKI # 7 and TKI # 8 in Figure 28B is set to "unused".

In Figure 28B, the new track to be written consists of four AOBs. Unused TKIs used to record these AOBs are determined according to the DPL_TK_SRP or can be freely chosen. In the present example, unused TKIs numbered TKI # 2, TKI # 4, TKI # 7 and TKI # 8 are used to record the TKIs for the new track. Since these four AOB constitute a track, "Head_of_Track" is set in the TKI_BLK_ATR of TKI # 2, "Middle_of_Track" is set in the TKI_BLK_ATR of TKI # 4 and TKI # 7 and "End_of_Track" is set in TKI_BLK_ATR of TKI # 8 . The TKI_LNK_PTR in each of the four TKI, TKI # 2, TKI # 4, TKI # 7 and TKI # 8, used to constitute the new TrackD are set so that they show the TKI that forms the next part of TrackD in the manner As shown by the arrows TL2, TL4 and TL7, TKI # 4 is set to TKI_LNK_PTR of TKI # 2, TK1 # 7 is set to TKI_LNK_PTR of TKI # 4 and TKI # 8 is set to TKI_LNK_PTR of TKI # 7. After this, the files "AOB002. SAI", "AOB004.SA1", "AOB007.SA1" and "AOB008.SA1" have the same numbers as TKI # 2, TKI # 4, TKI # 7, TKI # 8 that have been produced, and the four AOBs that make up the TrackD they are stored in these four files. By properly setting the TKI_LNK_PTR and the TKI_BLK_ATR, this fourth TrackD track can be managed using TKI # 2, TKI # 4, TKI # 7 and TKI # 8.

As described above, when a new track is written to the instant memory card 31, the TKIs in the TrackManager that are set to "not used" are assigned as the TKIs to be used for the tracks to be recorded. Recent . { l7-5_22-18_29A, B} Establishment of TKI when two tracks are combined What follows describes the updating of the TKIs when tracks are combined (case 3). Figures 29A and 29B show the manner in which the TKIs are established when two tracks are combined to produce a new track. The example in Figure 29A uses the same TrackManager as Figure 19 and shows the case when the user performs an edit operation to combine TrackC and TrackE into a single track. In this case, the AOB corresponding to TrackC and TrackE are recorded in the AOB files "AOB003.SA1" and "AOB008.SA1" which correspond to TKI # 3 and TKI # 8, so that the TKI_BLK_ATR of TKI # 3 and TKI # 8 are rewritten. Fig. 29B shows the TKI_BLK_ATR of these TKI after rewriting. In Figure 29A, the TKI_BLK_ATR of TKI # 3 and TKI # 8 are written as "Track", but in Figure 29B, the TKI_BLK_ATR of TKI # 3 is rewritten for "Head_of_Track" and the TKI_BLK_ATR of TKI # 8 is rewritten as "End_of_Track". When rewriting the TKI_BLK_ATR in this way, the AOB files "AOB003.SA1" and "AOB008.SA1" which correspond to TKI # 3 and TKI # 8 end up being treated as part of a single track, the new TrackC. This operation is accompanied by the TKI # 3 TKI_LNK_PTR that is rewritten to indicate TKI # 8. It should be noted particularly here that although the TKI_BLK_ATR in the TKIs are rewritten, processing is not performed to physically combine the AOB files "AOB003.SA1" and "AOB008. SAI". This is because the AOB files are each encoded using different FileKeys, so that when combining AOB files, it would be necessary to perform two processes for each AOB file to first decode the encoded AOB file and then re-encode the result, which implies an excessive processing load. In addition, an AOB file combined in this way can be encoded using a unique FileKey which can make the combined track less secure than the tracks used to produce it. The TKI is originally designed to suppress the size of the TKTMSRT, so that the physical combination of the AOB files by an editing operation also carries the risk of the TKI becoming too large. For the reasons indicated above, the editing operations that combine tracks that leave the AOB files in their encoded state and that are carried out simply by changing the attributes provided by the TKI_BLK_ATR. . { l7-5_22-18_29A, B-l_30, 31.}. Conditions that must be met when combining tracks The track combination is carried out by changing the attributes of TKI_BLK_ATR as described above, but the AOBs that are included in the combined tracks must satisfy the conditions that will be provided below. A first condition is that the AOB that is going to compose the final part of a new track needs to have the same audio attributes (audio coding mode, bit rate, sampling frequency, number of channels, etc.) as the AOB of which the first part of the new track is composed. If an AOB has audio attributes other than the preceding or succeeding AOB, the playback apparatus will have to reset the operation of the decoder, which makes a seamless (ie, uninterrupted) playback of the consecutive AOBs difficult. The second condition is that the track produced by the combination, three or more of the AOB constituted of only the AOB_ELEMENT whose AOB_FRAME number is below the number required for a "FNs_Middle_TMSRTE" can not be linked.

AOBs are classified into two types depending on whether at least one AOB_ELEMENT includes the same number of AOB_FRAME as the number of tables stipulated for an "FNs_Middle_TMSRTE". The AOB type 1 includes at least one AOB_ELEMENT that has this number of AOB_FRAME, while the AOB type 2 does not include an AOB_ELEMENT that has this number of AOB_FRAME. In other words, AOB_ELEMENT in an AOB type 2 has less AOB_FRAME than "FNs_Middle_TMSRTE", and the second condition stipulates that three AOBs of type 2 can not be joined together. The reason for the second condition is as follows. When a reproduction apparatus reads the AOBs successively, it is preferable for a sufficient number of AOB_FRAME to accumulate in the buffer of the reproduction apparatus, although this can not be obtained when there are consecutive AOB type 2. In such a case, there is likely to be insufficient flow in the buffer of the reproduction apparatus, so that the uninterrupted reproduction of the reproductive apparatus can no longer be guaranteed. Therefore, in order to avoid such insufficient flows, the second condition stipulating that three or more AOB type 2 can be continuously linked is not used. Figure 30A shows an AOB type 1 while figure 30B shows two examples of the AOB type 2. In Figure 30B, both AOBs consist of less than two AOB_ELEMENT, with none of the AOB_ELEMENT including an AOB_FRAME number that is set to an "FNs_Middle_TMSRTE". Since the absence of an AOB_ELEMENT with the number of A0B_FRAME is set to "FNs_Middle_TMSRTE" it is the condition by which an AOB is classified as AOB type 2, this means that all of the AOBs shown in this drawing are classified as AOB type 2. In Figure 31A, a combination of the AOB type 1 + type 2 + type 2 + type 1 is shown on a single track. Since this combination does not involve the binding of three AOB type 2s, these AOBs can be joined to form a single track. Figure 3IB shows the linkage of the AOB type 1 + type 2 + type 2 + type 2 + type 1. This combination would result in three consecutive AOB type 2 and therefore is prohibited. . { l7-5_22-18_29A / B-l_32} Combination of tracks with respect to combinations of AOB type 1 and type 2 In the combination of AOB in a single track as shown in Figure 31A, if the last AOB in the first track is an AOB type 1, the combination can be carried out regardless of whether the first part of this track is an AOB type 1 or an AOB type 2.

Figure 32A shows the case in which the last AOB in the first track is an AOB type 1 and the first AOB in the next track is also an AOB type 1. Figure 32 shows the case in which the last AOB in the first track is an AOB type 1 and the first AOB in the next track is an AOB type 2. Since in both cases the second condition is satisfied, the illustrated tracks can be combined in a single track. When the last AOB on the first track is an AOB type 2 and the preceding AOB on the first track is an AOB type 1, the first track can be combined with a subsequent track that starts with an AOB type 1, regardless of whether the first AOB in the first track is an AOB type 1 or an AOB type 2. Figure 32C shows the case in which the first track ends with an AOB type 1 and an AOB type 2 in that order, and the second track begins with a AOB type 1. Figure 32D shows the case in which the first track ends with an AOB type 1 and an AOB type 2 in that order and the second track starts with the AOB type 2 and the AOB type 1 in that order. Since the second condition is satisfied in both cases, the illustrated tracks can be combined in a single track. When the first track ends with an AOB type 2 and the immediately preceding AOB is also an AOB type 2, this first track can be combined with a subsequent track that begins with an AOB type 1. Figure 32E shows the case in which the The first track ends with the AOB type 2, and the second track begins with an AOB type 1. Since in this case the second condition is satisfied, the illustrated tracks can be combined into a single track. In this way, when two tracks are going to be combined, an investigation is made to see if the two tracks satisfy the first and second conditions and the two tracks are combined only if they are considered to satisfy these conditions. The following describes the update of the TKI for case 4 where the track is divided. . { 17-5_22-19_33A, B} Establishment for the TKI when a track is divided Figures 33A and 33B show examples of when a single track is to be divided to produce two new tracks. For these examples, the content of the TrackManager is the same as in Figure 27, and it is assumed that the user has performed an editing operation that divides the TrackC into two new tracks, TrackC and TrackF. When TrackC is to be divided into a new TrackC and TrackF, an AOB file "AOB002.SA1" is generated corresponding to TrackF. Fig. 33A shows that TKI # 2 is set as "not used", with this TKI # 2 that is assigned to the newly generated AOB "AOB002. SAI" file. . { l7-5_22-19_33A, B-l_34A, B} Updating directory entries and FAT values When the AOB file "AOB003.SA1" is split to produce "AOB002.SAI", the directory entries and the FAT values must be updated. This update is explained in the following. Figure 34A shows how the SD-Audio directory entry in the SD-Audio Directory to which the AOB file "AOB003.SA1" belongs is written before the file is split. The AOB file "AOB003.SA1" is divided into a plurality of parts that are stored in groups 007, 008, 009, 00A. . . 00D, OOE. In this case, the first group number for the AOB file "AOB003.SA1" provided in the directory entry is written as "007". The values (008), (009), (00A). . . (00D), (OOE) are also written in the FAT values 007, 008, 009, 00A. . . 00D corresponding to groups 007, 008, 009, 00A. . . 00D. When the AOB file "AOB003.SA1" is split so that its last part belongs to a new AOB file "AOB002.SAI", a "filename", a "filename extension" (file name extension) and a "number of first clusters in file" (number of the first groups in file) are added for a new AOB file " AOB002.SA1"that is added to the SD-AUDIO directory entry. Figure 34B shows how the SD-Audio directory entry in the SD-Audio directory to which the AOB file "AOB003.SA1" belongs is written after the AOB file "AOB003. SAI" has been split. In Figure 34B, the group 00F stores a copy of the OOB group that includes the limit indicated by the user when the file is divided. The parts of the file "AOB002.SA1" that follow the part included in the OOB group are stored in the OOC, OOD and OOE groups, as in the above. Since the first part of the AOB file "AOB002.SA1" is stored in the 00F group and the remaining parts are stored in the OOC, OOD, OOE groups, "00F" is written in the "number of the first group in file" for the new AOB file, "AOB002. SAI", while (OOC), (OOD), (OOE) are written in the values of FAT 00F, OOC, OOD, OOE corresponding to the groups 00F, OOC, OOD and OOE . . { l7-5_22-19_33A, B-2_35A, B} Establishment of information fields in the TKI The following describes how the information fields are set in the TKI for the AOB file "AOB002.SA1" once this file has been obtained by updating the directory entries and the FAT values. When a TKI is generated for a split track, there are two kinds of information fields the TKI. These are (1) information that can be copied from the original TKI and (2) information obtained by updating the original TKI information. The TKTXTI_DA in the ISRC is of the first type, while BIT, the TKTMSRT and other information fields are of the last type. Since both types of information exist, this mody generates a TKI for a split track by copying the original TKI to produce a template for the new TKI, and then dividing / updating the TKTMSRT and the BIT in this template and updating the templates. remaining information fields. Figure 35A shows the case in which AOB_FRAME is split into an AOB. The first level in Figure 35A shows the four AOB_ELEMENT, A0B_ELEMENT # 1, A0B_ELEMENT # 2, AOB_ELEMENT # 3, and A0B_ELEMENT # 4. The data lengths of these AOB_ELEMENT are set in the TKTMSRT as the four TMSRT_entries # 1, # 2, # 3 and # 4. If the limit bdl for the division is set to AOB_ELEMENT # 2 in Figure 35A, A0B_ELEMENT # 2 is divided into a first region (1) consisting of the tables located before the limit bdl, and a second region (2) consisting of the tables located after the bdl limit. Figure 35 shows the two AOB, AOB # l and AOB # 2 that are obtained by dividing the AOB in the middle through AOB_ELEMENT # 2. . { l7-5_22-19_33A, B-3_36} Establishment of the BIT Figure 36 shows how the BIT is established when an AOB is divided, as shown in Figure 35. The AOB shown in Figure 35 is divided into the bdl limit. The A0B # 1 produced by this division includes the two AOB_ELEMENT, A0B_ELEMENT # 1 and A0B_ELEMENT # 2, while the other A0B # 2 produced by this division includes the three AOB_ELEMENT, A0B_ELEMENT # 1, A0B_ELEMENT # 2 and A0B_ELEMENT # 3. In Figure 36, these AOB_ELEMENT have also been provided with triangular flags to show the TMSRT_entries settings in the TKIs corresponding to these AOBs. The explanation will first focus on the AOB # l which is obtained by this division. The A0B_ELEMENT # 1 and AOB_ELEMENT # 2 that are included in A0B # 1 occupy group 007 to group 00A, so that AOB # l is handled as constituted from the compound of groups 007 to group 00A. A0B_ELEMENT # 2 in AOB # l has a data length that ends not at the end of group 00A, but at the limit of bdl that is present within group 00A, so that SZ_DATA is provided for AOB # l as the amount of data from the MDO region to the bdl limit in group 00A. The "FNs_lst_TMSRTE" for A0B # 1 is the same as before the division, while the "FNs_Last_TMSRTE" for A0B # 1 differs from the value used before the division in which it now indicates the number of frames since the start of A0B_ELEMENT # 2 before the division to the bdl limit. The following describes A0B # 2, which is obtained by this division. AOB_ELEMENT # 1, AOB_ELEMENT # 2, and A0B_ELEMENT # 3 that are included in A0B # 2 occupy group OOB in group 007. The OOF group includes a copy of the contents of group 00A. The reason why the OOF group stores a copy of group 00A is that group 00A is occupied by AOB_ELEMENT # 2 in AOB # l, so it is necessary to assign a different group to AOB_ELEMENT # l in AOB # 2. AOB_ELEMENT # l in AOB # 2 has a length of data that begins not at the beginning of the OOF group, at the bdl limit that is present within the OOF group, so that SZ_DATA for AOB # 2 is provided as the same amount of data from the beginning of the OOB group to a midpoint through the OOE group plus the data length of the part of the OOF group occupied by AOB_ELEMENT # l. The part of AOB_ELEMENT # 2 in AOB # l is included in the copy of group 00A stored in the group OOF does not need to be excluded from AOB # 2, so that the field DATA_Offset in the BIT field of AOB # 2 is set in the size of the part of AOB_ELEMENT # 2 in AOB # l included in the OOF group. As you can see from figure 36, the division of the AOB results in that only the AOB_ELEMENT that includes the limit for the division is divided into two, and in other AOB_ELEMENT placed before and after the split AOB_ELEMENT remain unchanged. As a result, an "FN_Last_TMSRTE" of A0B # 2 is set to the same value for "A0B_ELEMENT # 4" before the division, and an "FNs_lst_TMSRTE" of A0B # 2 is established as set in AOB_ELEMENT # 1 of A0B # 2, which is the number of frames included in the part that follows the limit once AOB ELEMENT # 2 has been divided. . { l7-5_22-19_33A, B-4_37} Establishment of the BIT Figure 37 shows a more specific example of changes in BITs as a result of dividing a track. The left side of Figure 37 shows an example of the BIT settings before division. In this BIT, the Data_Offset is set to "X", SZ_DATA is set to "52428" and TMSRTE_Ns is set to "n". FNs_lst_TMSRTE is set to "80 frames", FNs_Middle_TMSRTE is set to "94 frames", and FNs_Last_TMSRTE is set to "50 frames". The right side of Figure 37 shows the settings of two BITs produced by dividing a track. When the AOB corresponding to the BIT on the left side of Figure 37 is divided as shown in Figure 35A, the Data_Offset in the BIT of the first track produced by the division is set to "X", as the track before the division "," SZ_DATA "is updated to the data length" Q "from the beginning of the division point Q, and TMSRTE_Ns is set to" k ", which shows the number of TMSRT_entries from the first TMSRT_entry to the kth TMSRT_entry The FNs_lst_-TMSRTE and FNs_Middle_TMSRTE are respectively set to "80" and "94" frames in the same way as the BIT before the division, but since the final AOB_ELEMENT in the AOB of the first track produced by the division includes "p" AOB_FRAMES, FNs_Last_TMSRTE is set to "p frames." In the BIT of the second track produced by the division, "Data_Offset" is set to "R", "SZ_DATA" is set to (SZ # DATA original "52428" data length to the division point Q) and TMSR is established TE_Ns in "n-k + 1" produced by adding one (for the kth TMSRT_entry that is newly added as a result of the division) to the TMSRT_entries number from the kth TMSRT_entry to the nth TMSRT_entry. The FNs_Middle_TMSRTE and FNs_Last_TMSRTE are set to the same values as the BIT before the division, ie "94 frames" and "50 frames" respectively. The first AOB_ELEMENT in the AOB of this second track includes "94-p" AOB_FRAME, so "94-p" is set to the FNs_lst_TMSRTE of the BIT corresponding to this track. . { l7-5_22-19_33A, B-5_38} Establishment of the BIT Figure 38 shows the TKTMSRT after division. The following explains the TMSRT establishments first. The TMSRT of the first track includes the TMSRT_entries of the first TMSRT_entry of AOB before the division by the kth tMSRT_entry, that is, the TMSRT_entries # 1 to #k. It should be noted here that AOB_ELEMENT # k includes the limit for the division only including region (1), so that the kth TMSRT_entry only includes a data size corresponding to this region (1). The TMSRT of the second track includes the TMSRT-entries of the kth TMSRT_entry of the AOB before the division by the nth TMSRT_entry, that is, the TMSRT_entries #k to #n. It should be noted here that AOB_ELEMENT # k that includes the limit for the division, only includes the region (2), so the ké3ima only includes a data size corresponding to this region (2). The copying of the TKI is accompanied by the division and updating of the TKTMSRT and the BIT, and once the remaining information has been updated, the TKIs for the new tracks produced by the division will be completed. In the same way as when combining tracks, AOB files are not decoded, so the two tracks can be produced by splitting an AOB file into its encoded state. Since splitting an AOB file does not involve decoding and recoding, the processing load of dividing a track can be suppressed. This means that tracks can be edited even by a playback device with limited processing power. This completes the explanation of the TKI. The following describes the Playlists. . { 17-6} PlaylistManager As shown by dashed lines h5 in Figure 17, the PlaylistManager shown is comprised of PlaylistManager_Inf ormation (PLMGI) to manage the Playlist stored on the instant memory card 31, Def ault_Playlist_Inf ormation (DPLI) to manage all of the tracks stored in the instant memory card 31 and Playlistlnformation (PLI), # 1, # 2, # 3, # 4. . . #m. Each PLI is information for a Playlist defined by the user. As shown by broken lines h.6, the DPLI is made up of Defult_Playlist_General_Inf ormation (DPLGI) and Default_Playlist_Track_Search_Pointers (DPL_TK_SRP) 9 # 1, # 2, # 3, # 4. . . #m. As shown by broken lines h7, each PLI is made up of Playl i s t_General__Inf ormat ion (PLGI), and Playlist_Trac_Search_Pointers (PL_TK_SRP) # 1, # 2, # 3, # 4. . . #m. The DPLI referenced here differs from each PLI in the following manner. Although the DPLI must indicate all of the tracks stored in the instant memory card 52, a PLI does not have this restriction and can indicate any number of tracks. This opens several possibilities for the user. As representative examples, the user can generate Playlist_Inf ormation by indicating only his favorite tracks and store this Playlist_Inf ormation on the instant memory card 31, or he can have a reproduction apparatus that automatically generates a Playlist_Information that only indicates the tracks of a certain genre, the plurality of tracks stored in the instant memory card 31 and storing the playlist information in the instant memory card 31. . { 17-7_18} Number of Playlist and its data sizes As shown in Figure 18, a maximum of 99 Playlist can be stored on a flash card 31. The combined data size of the PlaylistManager_Inf ormation (PLMGI) and the implicit playlist information (DPLI) is also set at 2,560 bytes. Each PLI has a fixed length of 512 octets. The "DPL_TK_SRP" included in the implicit playlist information includes a "DPL_TK_ATR" and a "DPL_TKIN". On the other hand, the field "PL_TK_SRP" included in a PLI includes only a "PL_TK_SRP". The format of the fields DPL_TK_ATR, DPL_TKIN and PL_TKIN is shown in Figure 39. . { 17-8_39-l} Format of DPL_TK_SRP Figure 3 A shows the format of DPL_TK_SRP. In Fig. 39A, the DPL_TKIN is written in the bits Oavo to 9avo in the DPL_TK_SRP, while DPL_TK_ATR is written in the 13th to 15th bits. The 12th through 12th bits of the DPL_TK_SRP are reserved for future use. The TKI number is written in the DPL_TKIN that occupies the bits Oavo to 9avo in the DPL_TK_SRP. This allows a TKI to be specified. . { l7-9_39b} Format of PL TK SRP Figure 39B shows the format of PL_TK_SRP. This is a ten-bit field in which PL_TKIN escr-Lbe is written, that is, a TKI number. . { l7-8_39A-2} Composition of DPL_TK_ATR Dashed lines h.51 and h52 extending from DPL_TK_ATR in Fig. 39A show an example of adjustment of DPL_TK_ATR. As you can see from this drawing, it is established for DPL_TK_ATR that DPL_TK_SRP is set for a TKI_BLK_ATR in the same way that TKI_BLK_ATR is set for a TKI, that is, the DPL_TK_ATR is set to one of "Track", "Head_of_Track" " Midpoint_of_Track ", and" End_of_Track ". When the TKI indicated by the TKIN is used, an Audio object (AOB) corresponding to a complete track is recorded in the AOB file corresponding to the indicated TKI (ie, when the TKI_BLK_ATR of the TKI is "Track"), it is set a value of "00b" in the "DPL_TK_ATR". When the TKI indicated by the TKIN is used and an audio object (AOB) is recorded that corresponds only to the beginning of a track in the AOB file corresponding to the indicated TKI (ie, when TKI_BLK_ATR of the TKI is "Head_of_Track"), the value "001b" is set in the "DPL_TK_ATR". When the TKI indicated by the TKIN is used in an audio object (AOB) that corresponds to the middle part of a track that is recorded in the AOB file corresponding to the indicated TKI (that is, when the TKI_BLK_ATR of the TKI is "Midpoint_of_Track" ), the value "010b" is set in the "DPL_TK_ATR". When the TKI indicated by the TKIN is used and - 1Ó4 - an audio object (AOB) is recorded that corresponds to the end part of a track in the file (AOB) corresponding to the indicated TKI (ie, when the TKI_BLK_ATR of the TKI is "End_of_Track"), the value "001b" is set in the "DPL_TK_ATR". Conversely, when the TKI indicated by the TKIN is not used and the TKI region is only established, which corresponds for example when a TKI has been suppressed (ie, when the TKI_BLK_ATR of the TKI is "not used"), it is established a value of "100b" in the DPL_TK_ATR. When the TKI indicated by the TKIN is not used and a TKI region has not been established, ie when the TKI is in an initial state, a value "101b" is set in the "DPL_TK_ATR". Since the number of a TKI is written in the DPL_TKIN, it is clear which of the plurality of TKI corresponds to each DPL_TK_SRP. The position of DPL_TK_SRP in the Default_Playlist_Information shows that when the AOB corresponding to the TKI corresponds to the DPL_TK_SRP it is the one that will be reproduced, that is, the ordinal position of the AOB in the Default_Playlist. As a result, the order of the DPL_TK_SRP items in the Default_Playlist indicates the order in which the plurality of tracks will be played or, in other words, determines the playback order of the tracks. . { l7-9_40-l} Interrelation between Default_Playlist_Infromation, TKI and the AOB files Figure 40 shows the interrelation between Default_Playlist_Information, the TKI and the AOB files. The second, third and fourth levels in this drawing are the same as the first, second and third levels in Figure 19, and thus show a TrackManager that includes eight TKI and eight AOB files. Figure 40 differs from Figure 19 in that a box showing the Default_Playlist_Information is provided in the first level. The eight small divisions shown in this table show the eight Default_Playlist_Information included in Default_Playlist_Information. The upper part of each division shows the DPL_TK_ATR, while the lower part shows the DPL_TKIN. As shown by the arrows DT1, DT2, DT3, DT4. . . in Figure 40, DPL_TK_SRP # 1 and TKI # 1 are related, as are DPL_TK_SRP # 2 and TKI # 2, DPL_TK_SRP # 3 and TKI # 3 and DPL_TK_SRP # 4. When looking in the DPL_TK_ATR fields in the DPL_TK_SRP, you can see that a "Track" has been set for each DPL_TK_SRP # 1, DPL_TK_SRP # 2, DPL__TK_SRP # 3 and DPL_TK_SRP # 8. In other words, the four combinations DPL TK SRP # 1? TKI # 1 ("AOB001. UPS"), DPL_TK_SRP # 2 - TKI # 2 ("OBO 02. UPS"), DPL_TK_SRP # 3 ("AOB003. UPS"), DPL_TK_SRP # 8? TKI # 8 ("AOBO 08.SAI") corresponds to the four separate tracks. Meanwhile, none of DPL_TK_S RP # 4, DPL_TK_SRP # 5, DPL_TK_SRP # 6, and DPL_TK_SRP # 7 have a DPL_TK_ATR set to "Track". Instead, the DPL_TK_SRP # 4 of DPL_TK_ATR is set to "Head_of_Track", the DPL_TK_ATR of DPL_TK_SRP # 7 is set to "End_of_Track" and the DPL_TK_ATR of DPL_TK_SRP # 5 and DPL_TK_SRP # 6 are set to "Midpoint_of_Track". This means that TKI # 4 ("AOB004. SAI"), which is related to DPL_TK_SRP # 4, is the start of a track, TKI # 5 ("AOBO 05. UPS") and TKI # 6 ("AOB006. "), which are respectively related to DPL_TK_SRP # 5 and DPL_TK_SRP # 6, are the middle parts of a track, and TKI # 7 (" AOB007. SAI "), which is related to DPL_TK_SRP # 7, is the end of a track. The DPL_TK_SRP entries in the Def aultPlaylist show in which order the AOB corresponding to each TKI will be played. The DPL_TKIN of DPL_TK_SRP1, # 2, # 3, # 4. . . # 8 in the Def aultPlaylist of Figure 40 indicate TKI # 1, # 2, # 3, # 4. . . # 8 As shown by the arrows (1) (2) (3) (4). . . (8), the AOB file "AOB001. SAI" corresponds to TKI # 1 will be reproduced first, "AOB002.SA1" which corresponds to TKI # 2 will be reproduced in second place, "AOB003.SA1" which corresponds to TKI # 3 will will play in third place and "AOB004.SAI", which corresponds to TKI # 4 will be played at the end, in fourth place. . { 17-10_41} Examples of settings for DefaultPlayslist and Playlist_Information Figure 41 shows the example settings for the Default_Playlist and the Playlist_Information using the same notation as in Figure 40. In Figure 41, the box on the first level shows the Default_Playlist, while the three boxes on the second level show the PLI. The small divisions in the box that the Default_Playlist displays show the eight values of DPL_TK_SRP included in Default_Playlist, while the small divisions in the boxes that illustrate each PLI show three or four values of PL_TK_SRP. This TKIN setting of each DPL_TK_SRP included in Default_Playlist_Information is the same as in Figure 40. However, the TKIN settings in PL__TK_SRP included in each PLI are completely different from those in DPL TK SRP. . { 17-10_42} Correspondence between DPL_TK_SRP and the TKI Figure 42 shows the correspondence between DPL_TK_SRP and TKI using the same notation as in Figure 40. In Figure 42, Playlist # l is constituted of PL_TK_SRP # 1, # 2, # 3. Of these, # 3 is written as PL_TKIN of PL_TKI_SRP # 1, while # 1 is written as the PL_TKIN of PL_TK_SRP # 2 and # 2 as the PL_TKIN of PL_TK_SRP # 3. This means that when the tracks are played according to Playlist # l, a plurality of AOB will be played, as shown by the arrows (11) (12) (13) in the order AOB # 3, AOB # l, AOB # 2. Playlist # 2 is composed of PL_TK_SRP # 1, # 2, # 3. Of these # 8, it is written as the PL_TKIN of PL_TK_SRP # 1, while the # 3 is written as the PL_TKIN of PL_TK_SRP # 2 and # 1 as the PL_TKIN of PL_TK_SRP # 3. This means that when the tracks are played according to Playlist # 2, a plurality of AOB will be played, as shown by the arrows (21) (22) (23) in the order AOB # 8, A0B # 3, A0B # 1, that is, in a completely different order than Playlist # l. Playlist # 3 is made up of PL_TK_SRP # 1, # 2, # 3, # 4. The PL_TKIN of these PL_TK_SRP # 1 to # 4 are respectively set as # 8, # 4, # 3, and # 1. This means that when the tracks are played according to Playlist # 3, a plurality of AOB will be played, as follows. First, AOB # 8 that constitutes TrackE is played as shown by the arrow (31). Then, A0B # 4, AOB # 5, AOB # 6 and AOB # 7 that TrackD component, are reproduced as shown by the arrow (32). After this, AOB # 3 and AOB # l, which respectively TrackC and TrackA component are reproduced as shown by the arrows (33) and (34). Of special note is that when a track is constituted by a plurality of TKI, only the TKI number of the start of the track is written inside the input PL_TK_SRP. In more detail, although the Default_Playlist_Information values specify the four TKIs (TKI # 4, TKI # 5, TKI # 6, TKI # 7) that constitute TrackD, the PL_TK_SRP provided in a Playlist_Information set does not need to indicate all of the four TKI. For this reason, PL_TK_SRP # 2 in Playlist # 3 only indicates TKI # 4 from TKI # 4 to TKI # 7. On the other hand, a DPLI that includes a plurality of DK_TK_SRP has a data size that is no larger than a sector that is always loaded into the RAM of a reproduction apparatus. When the tracks are played according to a Playlist, the player refers to the DK_TK_SRP that is loaded into its RAM and can thus search for high-speed TKIs. To reproduce the TKI (AOB) using a PL_TK_SRP that only indicates the TKI number of the first TKI, a playback apparatus looks for the TPL_TK_SRP loaded in its RAM based on the TKI indicated by the PL_TK_SRP and judges whether the current track consists of a plurality of TKI. If this is the case, the reproductive apparatus executes the appropriate procedure to reproduce all the corresponding TKI (AOB). As described in the above, the Default_Playlist and a plurality of PLI is written in the Playlist_Manager. If different playback commands are written in the DPL_TKIN and the PL_TKIN of the DPL_TK_SRP and the PL_TK_SRP that make up such Playlist, it becomes possible to reproduce the AOB in different orders. By providing a variety of different reproduction layouts for the user in this way, the user may have the impression that he has many music albums stored in the instant memory card 31. It is a special note here that the size of the DPL_TK_SRP data corresponding to an AOB file is small (no larger than two octets), although the TKI data size corresponding to an AOB file is large (up to 1,024 bytes). When the TKI is reordered in the TrackManager, a large number of accesses to the card need to be made 31 instantaneous memory, but when you reorder the DPL_TK_SRP in Default_Playlist_Information or a PLI, this can be done with less access to the instant memory card 31. In view of this, when editing the navigation data, the order of the DPL_TK_SRP in Default_Playlist is actively changed according to the editing operation, while the order of the TKX in the TrackManager is left unchanged despite the editing operation . . { l7-9_40-2_43A, B} Reordering the DPL_TK_SRP The following describes an edit operation that changes the playback order of the tracks when reordering the TPL_TK_SRP in the Default_Playlist_Information. Figures 43A and 43B show an example of reordering of tracks. The settings of the DPL_TK_SRP and the TKI in Figure 43A are the same as in Figure 40. In Figure 40A, the DPL_TKIN in DPL_TK_SRP # 3 is set to TKI # 3, while the DPL_TKIN in DPL_TK_SRP # 8 is set to TKI # 8. The following describes the case in which these DPL_TK_SRP with the gross contours in Figure 40A are exchanged. The numbers (1) (2) (3) (4) (5) (6) (7) (8) in Figure 43B show the order of playing the tracks after this editing operation. It should be noted here that although the order of reproduction shown in Figure 43A is TrackA, TrackB, TrackC, TrackD, TrackE, in Figure 43B the DPL_TKIN of DPL_TK_SRP # 3 and DPL_TK_SRP # 8 are exchanged in the Default_Playlist_Information in a way that the tracks will be played in the order TrackA, TrackB, TrackC. In this way, the playback order of the tracks can be easily changed by changing the order of the DPL_TK_SRP in the Default_Playlist_Information. Although the above explanation makes mention of the editing operation that changes the order of the tracks, the following will describe the following four operations that are explained with respect to the changes in the TKI. These operations are a first case (case 1), where a track is deleted, a second case (case 2) where a new track is recorded, a third case (case 3) where two freely selected tracks are combined to produce a new track and a fourth case (case 4), where a track is divided to produce two new tracks. . { l7-9_40-3_44A, B} Deletion of a track The following describes case 1 where a track is deleted. Figures 44A and 44B show how Default_Playlist, TrackManager and AOB files are updated when, in addition to the DefaultPlaylist shown in Figure 40, DPL_TK_SRP # 2 and TKI # 2 are deleted. In these drawings, the same part of an AOB as in Figure 27 which is used to describe the deletion of a TKI is deleted. As a result, the second, third and fourth levels in Figure 44A and 44B are the same as in Figure 27. The difference with Figure 27 is that Default_Playlist_Information includes a plurality of DPL_TK_SRP that are provided in the first level in the same way that in figure 40. This example works with the case when the user deletes TrackB constituted of DPL_TK_SRP # 2? TKI # 2 ("AOB002.SAI") shown with the thick outline in Figure 44A. In this case, DPL_TK_SRP # 2 of Default_Playlist_Information and DPL_TK_SRP # 3 to DPL_TK_SRP # 8 where each moves in a place in the order of reproduction so that they fill the space in the order released by the deletion of DPL_TK_SRP # 2. When the DPL_TK_SRP is moved in this manner, the final DPL__TK_SRP # 8 is set to "not used". On the other hand, the TKI corresponding to the suppressed part is set as "not used" as shown in Figures 27A and 27B without other TKI moving to fill the space created by the deletion. The deletion of the TKI is also accompanied by the deletion of the AOB file "AOB002. SAI". In this way, the DPL_TK_SRP are moved in the playback order but the TKIs are not moved, so that in Figure 44B, only the DPL_TKINs in the DPL_TK_SRPs have been updated. For this example, the DPL_TKIN in the DPL_TK_SRP # 2 is set to indicate the TKI # 3 as shown by the arrow DT11, the DPL_TKIN in the DPL_TK_SRP # 3 is set to indicate the TKI # 4, as shown by arrow DT12, DPL_TKIN in DPL_TK_SRP # 4 is set to indicate TKI # 5 and DPL_TKIN in DPL_TK_SRP # 5 is set to indicate TKI # 6. The DPL_TKIN in DPL_TK_SRP # 8 that has been set to "not used" is set to indicate TKI # 2, as shown by the arrow DT13. When a track is deleted, the DPL_TK_SRP used to track the tracks in the playback order is moved, while the TKI corresponding to the deleted track is set to "unused", while the rest is in its present position. In this way, an editing operation is not accompanied by movements of the TKI, which suppresses the processing load when editing tracks. . { l7-9_40-4_A, B} Assignment of IT when tracks are recorded The following describes case 2 when recording a new track after the partial deletion of a track. Figures A and 45B show how an operation writing a new TKI and DPL_TK_SRP is performed when an "unused" TKI and DPL_TK_SRP are present. These drawings are largely the same as those in Figures 28A and 28B which are used to explain the assignment of a new TKI to a set of TKI as "unused". The second, third and fourth levels in Figures 45A and 45B are the same as the first three levels in Figures 28A and 28B. The difference between the drawings is that the first levels in Figures 45A and 45B show the Default_Playlist_Information constituted of a plurality of DPL_TK_SRP. In Figure 45A, DPL_TK_SRP # 4 for DPL_TK_SRP # 8 is set to "not used". On the other hand, in Figure 28, the TKI # 2, TKI # 4, TKI # 5, TKI # 7, TKI # 8 are set as "not used". While the TKIs set as "unused" are present here and also in the TrackManager, the DPL_TK_SRP "are not included as close as they are in Def aul t_Playlis t_Inf ormation. This results from the fact that the DPL_TK_SRPs used move up in the Def_ult_Playlist_Inf ormation as described above, as long as no movement is made for the TKIs. The following explanation describes the case when writing a TrackD consisting of four AOBs. The TKIs for these four AOBs are written respectively within the following "unused" TKIs in the TrackManager: TKI # 2, TKI # 4; TKI # 7; and TKI # 8. The DPL_TK_SRP for these four AOBs are written in DPL_TK_SRP # 4 to DPL_TK_SRP # 7 in Def aul t_Playlist_Inf ormation. Since these four AOBs constitute a single track, the DPL_TK_ATR of DPL_TK_SRP # 4 are set to "Head_of_Track", the DPL_TK_ATR of DPL_TK_SRP # 5 and DPL_TK_SRP # 6 are set to "Middle_of_Track", and the DPL_TK_ATR of DPL_TK_SRP # 7 are set to "End_of_Track". DPL_TKIN of DPL_TK_SRP # 4 is set to TKI # 2, DPL_TKIN of DPL_TK_SRP # 5 in TKI # 4, DPL_TKIN of DPL_TK_SRP # 6 in TKI # 7 and DPLJTKIN of DPL_TK_SRP # 7 in TKI # 8. By setting the DPL_TKIN and DPL_TK_ATR in this way, TKI # 2, TKI # 4, TKI # 7 and TKI # 8 are handled as the fourth TrackD track. In the previous processing, a write is made for the "unused" TKIs. Although this has no effect on the other TKI, TKI # 1, TKI # 2, TKI # 3 and TKI # 4, as is also the case in Figures 28A and 28B. . { l7-9_40-5_46A, B} Case 3: Combination of Tracks The following describes the update of the Default_Playlist_Information when the tracks are combined (that is, in case 3). Figures 46A and 46B show an example of the combination of tracks. These drawings are largely the same as Figures 29A and 29B that were used to explain the combination of TKI. The second, third and fourth levels in Figures 46A and 46B are the same as the first two levels in Figures 29A and 29B. The difference between these figures is that the first levels in Figures 46A and 46B show l | Default_Playlist_Information, in which DPL_TK_SRP # 8 is set to "not used" and is related to TKI # 2 which is also set to "not used" . When an editing operation is performed combining the tracks for the AOB and TKI files as shown in Figures 29A and 29B, each of the contents of DPL_TK_SRP # 3 to DPL_TK_SRP # 6 is moved down by one and the content of DPL_TK_SRP # 7 shown with a thick outline within DPL_TK_SRP # 3 as shown in Figures 46A and 46B. The TKIs are also updated, as shown in Figures 29A and 29B. . { l7-9_40-6_47A, B} Case 4: Division of a Track The next step is to define the definition of the Def_Playl ist_Inf ormation when a track "case 4" is divided, Figures 47A and 47B show an example of the division of a track. Same as Figures 33A and 33B that were used to explain the division of the TKI The second and third levels in Figures 47A and 47B are the same as the first two levels in Figures 33A and 33B.The difference between these figures is that the first level in Figures 47A and 47B shows Def ault_Playlist_Inf ormation, in which DPL TK SRP # 8 is set to "not used" and is related to TKI # 2 which is also set to "not used". If, as in Figures 33A and 33B, the user indicates that the division of TKI # 3 ("AOB003, UPS") shown with the thick outline within two, the positions of DPL_TK_SRP # 3 to DPL_TK_SRP # 7 move each one down in one in order, and set to DPL_TK_SRP as "not used" and move inside Default_Playlist_Information to the previous position of DPL_TK_SRP # 3. This new DPL_TK_SRP # 3 is associated with the TKI, TKI # 2, newly produced by the division. The AOB file "AOB002.SA1" associated with TKI # 2 stores what was originally the last part of the AOB file "AOB003. SAI". DPL_TK_SRP # 2 is present before DPL_TK_SRP # 3 that is associated with TKI # 2 and is associated with TKI # 2 and "AOB002.SA1". That is, "AOB002.SA1" and "AOB003.SA1" respectively store the last and previous parts of the original "AOB003.SA1", with the DPL_TK_SRP # 2 and DPL_TK_SRP # 3 corresponding to these files indicating that these AOBs should be reproduced in the order "AOB003.SA1" and "AOB002. SAI". As a result, the final and previous parts of the original "AOB003.SA1" will be reproduced in the order of the previous part, back and in accordance with the reproduction order provided in the DPL_TK_SRP. . { 17-9_40-8} Editing Processing Application By combining the four previous editing processes, a user can perform a wide variety of editing operations. When, for example, a recorded track has an introduction cover in which a disc jockey has spoken, the user can first divide the track to separate the part that includes the voice of the jockey. The user can then delete this track to leave the part of the track that does not include the disc jockey. This completes the explanation of the navigation data. The following describes a reproduction apparatus with a composition suitable for reproducing the navigation data and presentation data described above. . { 48-1} External Appearance of the Reproducing Apparatus Figure 48 shows a portable reproduction apparatus for the flash memory card 31 of the present invention. The reproduction apparatus shown in Fig. 48 has an insertion slot for inserting the instant memory card 31, a key panel for receiving user prompts for operations such as playback, forward search, backward search, forward, rewind, high, etc., and an LCD panel (liquid crystal display). In terms of appearance, this reproductive device resembles other kinds of portable music players. The key panel includes: a "Playlist" key (playlist) that receives the selection of a playlist or a track; a "| <<" key that receives a scroll operation that moves the playback position to the beginning of the current track; one key "> > |" that receives a scrolling operation that moves the playback position to the beginning of the next track; a "< <" key and a ">>" key that respectively receive a backward search operation and a forward search operation that allow the user to have a playback that moves more quickly across the track current; a "Display" key that receives an operation to have still images stored in the instant memory card 31 displayed; a "Rec" key (recording) that receives the recording operation; an "Audio" key to receive user selections of the sampling frequency or if stereo or monaural sound is to be used; a "Mark" key (mark) that receives the user's indications of the mark positions in the tracks; and an "Edit" key that receives the user's instructions for editing the tracks or for entering track titles. . { 48-2} Improvements Made in This Portable Playback Device for Instant Memory Card 31 The differences between this portable reproduction apparatus of the instant memory card 31 and a conventional portable music player is found in the following four improvements (1) to (4). (1) A list of playlists and tracks is displayed on the LCD panel to allow the user to indicate the Default_Playlist_Information, a PLI or separate tracks. (2) The buttons on the button panel are assigned to the playlists or tracks, or both, displayed on the LCD panel to allow the user to select a track or playlist to be played or edited. (3) A time code showing a position on a track is displayed on the LCD panel 5 when the track is played. (4) A jog indicator is provided to allow the user to set a time code for use as a playback start time when using the time search function or as a division limit when dividing a track. . { 48-2_49_50} Improvement (2) The following describes the improvement (2) in detail. Figure 49 shows an example of the display screen shown on the LCD panel when the user selects a playlist, while figures 50A to 50E show examples of the content displayed when the user selects a track. In figure 49, the ordered sequences of ASCII characters "DEFAULTPLAYLIST", "PLAYLIST # 1", PLAYLIST # 2"," PLAYLIST # 3"and PLAYLIST # 4" represent the implicit playlist and the four playlists stored in the instant memory card 31 . Meanwhile, the sequences of ASCII character arrays "Trackl", "Track # 2", Track # 3", Track # 4", Track # 5"represent the five tracks indicated in the playback order provided by the playlist implicit stored in the instant memory card 31. In figures 49 and 50A, the illuminated playlist and the list show the track or playlist that is currently indicated for playback or editing.

If the user presses the ">" button when track # 1 is indicated for playback within the playback order provided by the implied playlist displayed on the LCD panel, track # 2 will be indicated for playback within the list of tracks, as shown in Figure 50B. If the user presses the ">" button again, track # 3 will be indicated for playback within the track list, as shown in Figure 50C. If the user presses the "< <" button then track # 3 is indicated for playback within the playback order provided by the implied playlist displayed on the LCD panel, track # 2 will be indicated for playback within the list of tracks, as shown in Figure 50D. As shown in Figure 50E, if the user presses the "Play" button when any of the tracks is indicated, playback of the indicated track will begin, and if the user presses the "Edit" button, the indicated track will be selected for editing. . { 48-3_5l} Improvement (4) The following describes the improvement (4) in detail. Figures 51A to 51C show an exemplary operation of the selection switch. When the user rotates the selection switch by a certain amount, the playback time code displayed on the LCD panel will increase or decrease according to this certain amount. The example in Figure 51A shows the case in which the playback time code that is initially displayed on the LCD panel is "00:00:20". When the user rotates the selection switch counterclockwise, as shown in Figure 5IB, the playback time code is reduced to "0:00:10" by maintaining the amount which is has rotated the selection switch. Conversely, when the user rotates the selection switch clockwise, as shown in Figure 51C, the playback time code is increased to "0:00:30" by keeping the amount by which the selection switch was rotated. By allowing the user to change the playback time code in this manner, the playback apparatus allows the user to indicate any playback time code on a track only by rotating the selection switch. If the user then presses the "Play" button, the AOBs will be played from a position that is in accordance with equation 2 and equation 3. By using the selection switch during a track division operation, the The user can make fine adjustments to the playback time code used as the division limit. . { 52-1} Internal Construction of the Reproduction Apparatus The following describes the internal construction of the reproduction apparatus. In figure 52 this internal construction is shown. As shown in Fig. 52, the playback apparatus includes a card connector 1 for connecting the playback apparatus to the instant memory card 31, an interface unit 2 with the user which is connected to the button panel and the switch of selection, a RAM 3, a ROM 4, an LCD panel 5 having a list frame to display a list of tracks or playback tracks and a time code frame to display a playback time code, an LCD driver 6 for driving the LCD panel 5 first, a decoder 7 for decoding the AOB_FRAME using a different FileKey for each AOB file. An AAC decoder 8 for referring to the ADTS of an A0B_FRAME decoded by the decoder 7 and decoding AOB_FRAME to obtain the PCM data, a 9 D / A (digital-analog) converter for D / A conversion of the data of PCM and transmitting the resulting analog signals to a loudspeaker or a hearing aid, and a CPU 10 to perform full control over the reproduction apparatus. As you can understand from this hardware construction, the present reproduction apparatus does not have special hardware elements to process the TrackManager and the Default_Playlist_Information. To process the TrackManager and Default_Playlist_Information, the RAM 3 is provided with a DPLI retention area 11, a PLI storage area 12, a TKI storage area 13, a FileKey storage area 14 and a double buffer 15, while the playback control program and the add control program are stored in ROM 4. . { 52-2} DPLI Retention Area 11 The DPLI hold area 11 is an area for continuously holding the Default_Playlist_Information that has been read from the instant memory card 31 connected to the card connector 1. . { 52_12} PLI Storage Area 12 The PLI storage area 12 is an area that is reserved for storing Playlist_Information that has been selected for playback by the user. . { 52-3} TKI Storage Area 13 The TKI storage area 13 is an area that is reserved for storage only of the TKI corresponding to the AOB file currently indicated for reproduction, outside of the plurality of the TKIs included in the TrackManager. For this reason, the capacity of the TKI storage area 13 is equal to the data size of a TKI. . { 52-4} FileKey Storage Area 14 The FileKey storage area 14 is an area that is reserved for storage only of the FileKey that corresponds to the AOB file currently indicated for playback, outside of the plurality of FileKey included in "AOBSAl.KEY" in the authentication region. . { 52-5} 15 Double Intermediate Memory The double buffer 15 is an input / output buffer that is used when an input process, which successively inputs group data (data that is stored in a group) is read from the instant memory card 31, and a output process, which reads the A0B_FRAME of the group data and successively transmits the A0B_FRAME to the decoder 7, which is done in parallel. The double buffer 15 successively releases the regions that were occupied by the group data that has been transmitted as A0B_FRAME and thus secures the regions for storage of the following groups that are read. That is, the regions in the double buffer 15 are cyclically secured for the storage group data using ring pointers. . { 52-5_53_54A, B} Entry and Exit for Intermediate Memory 15 Double Figure 53 shows how the input and output for the double buffer 15 are carried out. Figures 54A and 54B show how the regions in the double buffer 15 are cyclically fixed for the storage group data using the ring pointers. The arrows point down and to the left are the pointers to write addresses for group data, which means, the write pointers. The arrows pointing up and to the left are pointers for read addresses for group data, that is, read pointers. These pointers are used as the ring pointer. . { 54-6_53} When an instantaneous memory card 31 is connected to the card connector 1, the group data in the user region of the flash memory card 31 is read and stored in the double memory 15, as shown by the arrows wl and w2 . The data of the reading group is stored successively in the positions in the double buffer 15 which is shown by the write pointers wpl and wp2. . { 52-7_54A} Of the AOB_Frames included in the group data stored in this way, the AOB_Frames present in the positions 1 2 3 4 5 6 7 8 9 that are indicated successively by the reading pointer are transmitted, one at a time, to the decoder 7, as shown by the arrows rl, r2, r3, r4, r5 In the present case, the group data 002 and 003 are stored in a double buffer 15 and the read positions 1 2 3 4 are indicated successively by the pointer of reading, as shown in Figure 53. When the reading pointer reaches reading position 5, all of the AOB_FRAME included in group 002 have been read, so that group 004 is read and, as shown by arrow w6 in figure 54A, it is overwritten within the region that was previously occupied by group 002. . { 52-8_54B} The reading pointer then advances to reading positions 6 and 7, and finally reaches reading position 9, at which point all of the A0B_FRAME included in group 003 have been read, so that group 005 reads and, as shown by the arrow w7 in Figure 54B, it is overwritten in the region that has previously been occupied by the group 003. The output of an A0B_FRAME and the overwriting of the group data are performed repeatedly as described in the above, so that the A0B_FRAME included in an AOB file are all transmitted successively to the decoder 7 and the AAC decoder 8. . { 52-9_55-58} Reproduction Control Program Stored in ROM 4 The following describes the stored reproduction control program and the ROM 4 Figure 55 is a flow diagram showing the processing in the AOB file reading procedure. Figures 56, 57 and 58 are flow diagrams showing processing in the AOB_FRAME output procedure. . { 52-9_55-l} These flow diagrams use the variables w, z, y and x. The variable w u indicates one of the plurality of DPL__TL_SRP. The variable z indicates an AOB file recorded in the user's region, the TKI corresponding to this AOB file, and the AOB included in this AOB file. The variable y indicates an AOB_ELEMENT included in the AOB # z indicated by the variable z. The variable x indicates an A0B_FRAME included in the AOB_ELEMENT # and indicated by the variable y. The following will first explain the processing in the AOB file read procedure, with reference to Figure 55. . { 59-9_55-2} In the SI stage, the CPU 10 reads the PlaylistManager and displays a list that includes the Default_Playlist_Information and the PLIs.

In step S2, the CPU 10 waits for an indication to play the AOBs according to either the Default_Playlist_Information or one of the PLIs. When the Default_Playlist_Information is indicated, the processing moves from step S2 to step S3 where the variable w (#wl) starts and then to step S4 where TKI # z is specified indicated by the DPL_TKIN corresponding to DPL_TK_SRP #w in the Default_Playlist_Information, and only this TKI # z is read from the instant memory card 31 and stored in the TKI storage area 13. In step S5, an AOB file #z with the same number as TKI # z is specified. In this way, the AOB file to be played is finally specified. The specified AOB file is in a coded state and needs to be decoded, so steps S6 and S7 are carried out. In step S6, the playback apparatus has access to the authentication region and reads the FileKey # z that is stored in FileKey_Entry # z in the encoding key storage file, the FileKey_Entry # z has the same number as the file AOB specified. In step S7, the CPU 10 sets FileKey # z in decoder 7. This operation results in FileKey being set in decoder 7, so that by successively entering the FRAME AOBs included in the AOB file within the decoder 7, the AOB_FRAME can be played successively. . { 52 -9_55 -3} After this, the playback apparatus reads successively the groups that store the AOB file. In step S8, the "first group number in the file" is specified for the AOB_File # z in the directory entry. In step S9, the CPU 10 reads the data stored in this group from the instant memory card 31. In step S10, the CPU 10 makes a judgment as to whether the group number in the FAT value is "FFF". If not, in the Sil stage, the CPU reads the data stored in the group indicated by the FAT value, before returning to step S10. When the reproduction apparatus reads the data stored in any of the groups and refers to the corresponding FAT value for this group, the processing in steps S10 and Sil will be repeated to the extent that the FAT value is not set to "FFF" . This results in a reproduction apparatus that reads successively the groups indicated by the FAT values. When the group number given by the FAT value is "FFF", this means that all of the groups constituting AOB file #z are read, so that the processing proceeds from step S10 to step S12. . { 52-9_55-4} In step S12, the CPU 10 makes a judgment as to whether the variable #w matches the total number of the DPL_TK_SRP. If this is not the case, the processing proceeds to step S13, where the variable #w (# w-w + l) is incremented before the processing returns to step S4. In step S4, the reproduction apparatus specifies the TKI # z which is indicated by the DPL_TKIN # w of the DPL_TK_SRP # w in the Default_Playlist_Information, and writes only the TKI # z within the storage area of TKI. The TKI that is used up to this point will be stored in the TKI storage area 13, although this current TKI will be overwritten by the TKI # z that is read again by the CPU 10. This overwriting results in only the last TKI being stored. in the TKI storage area 13. Once the TKI has been overwritten, the processing in steps S5 to S12 is repeated for the AOB file #z. Once this processing has read all of the TKI and AOB files corresponding to all of the DPL_TK_SRP included in the Default_Playlist_Information, variable #z will match the total number of DPL_TK_SRP so that a "Yes" judgment is provided in Step S12 and the processing in this flow chart ends. . { 52-9_56_57_58} Output processing for an AOB_FRAME In parallel with an AOB file read procedure, the CPU 10 performs an AOB_FRAME output procedure according to the flow diagrams shown in Figures 56, 57 and 58. In these flow diagrams, the variable "play_time" shows how much playback has been done for a current track, that is, the playback time code. The time displayed in the playback time code frame in LTD panel 5 is updated according to the changes with this playback time code. Meanwhile, the variable "play_data" represents the length of the data that has been played for the current track. . { 52-9_56-l} In step S21, the CPU 10 monitors whether the group data for AOB file #z has been accumulated in the double buffer 15. This step S21 will be performed repeatedly until the group data is accumulated, at which point the processing proceeds to step S22 where the variables x and y (# x-l, # and -l) are initialized. After this, in step S23 the CPU 10 searches the groups for AOB file #z and detects the AOB_FRAME # x in the AOB_ELEMENT # and that is placed not before the Data_0ffset that are provided in BIT # z included in TKI # z. In this example, it is assumed that the seven octets starting from SZ_DATA are occupied by the ATDS header. When referring to the ADTS header, the data length indicated by the ADTS header can be recognized as audio data. The audio data and the ADTS header are read together and transmitted to the decoder 7. The decoder 7 decodes the AOB_FRAME which is then decoded by the decoder 8 AAC and played back as audio. . { 52-9_56-2} After this detection, in step S24, the AOB_FRAME # x is transmitted to the decoder 7 and in step S25 the variable play_time is increased by the reproduction period of the AOB_FRAME # x and the variable play_data is increased by the amount of data that correspond to AOB_FRAME # x. Since the playback time of AOB_FRAME is 20 msec in the present case, 20 msec is added to the variable "play_time". Once the first A0B_FRAME is transmitted to decoder 7, in step S26, the reproduction apparatus refers to the ADTS header of A0B_FRAME # x and specifies at what time the next A0B_FRAME is. In step S27, the reproduction apparatus increments the variable "x (# x- # x + l) and sets AOB_FRAME # x as the next AOB_FRAME." In step S28, AOB_FRAME # x is introduced into the decoder 7. After this, in step S29, the variable play_time is increased by the reproduction period of AOB_FRAME # x and the variable play_data is increased by the amount of data corresponding to AOB_FRAME # x After increasing the AOB_FRAME # x, in step S30, the CPU 10 makes a judgment to determine whether the variable #x has reached the value provided in FNs_lst_TMSRTE. If the variable #x has not reached the value in FNs_lst_TMSRTE, in step S31, the reproduction apparatus verifies if the user has pressed any button in addition to the "play" button and then returns to step S26. The reproduction apparatus then repeats the processing in steps S26 to S31 until the variable #x reaches the value in FNs_lst_TMSRTE or until the user presses any button in addition to the "PLay" button. When the user presses a button in addition to the "Play" button, the processing in this flowchart terminates and any suitable processing is performed for the pressed button. When the button pressed is the "Stop" button, the playback procedure stops, while if the button pressed is the "Pause" button, a pause in playback is established. . { 52-9_57-l} On the other hand, when the variable #x reaches the value in FNs_lst_TMSRTE a "Yes" judgment is made in step S30, and the processing proceeds to step S32 in figure 57. Since all of the AOB_FRAME included in the present AOB_ELEMENT will have been introduced into the decoder 7 in the processing between the steps S26 to S30, in the step S32 the variable #y is increased to establish the next AOB_ELEMENT as the data to be processed and the variable #x is initialized ( # y- # y + l, #xl). After this, in step S33, the reproduction apparatus refers to TKTMSRT and calculates the first address of the AOB_ELEMENT # y. The reproduction apparatus then performs the procedure consisting of steps S34 to S42. This procedure reads the AOB_FRAME included in an AOB_ELEMENT one after another, and in this way it can be said that it recalls the procedure constituted of steps S24 to S31. The difference with the method constituted from steps S24 to S31 is the condition by which the procedure constituted from steps S24 to S31 ends if the variable #x has reached the value shown by "FNs_lst_TMSRTE" while the condition by which the The procedure consisting of steps S34 to S42 ends if the variable #x has reached the value shown by "FNs_Middle_TMSRTE". When the variable #x reaches the value shown by "FNs_Middle_TMSRTE", the looping method consisting of steps S34 to S42 ends, a "Yes" judgment is provided in step S41 and the processing proceeds to step S43. In step S43, the CPU increments the variable #y and initializes the variable #x (# and ^ # y + l, # x ^ l). After this, in step S44, the variable considers whether the variable #y has reached a value equal to one less than that of TotalTMSRT_entry_Number in the TMSRT_Header in the TKI # z. When the variable #y is less than (TotalTMSRT_entry_Number_l), the AOB_ELEMENT # and it is not the Final AOB_ELEMENT, so that the processing returns from step S44 to step S32 and the looping procedure of step S32 to step S42 is performed. When variable #y reaches (TotalTMSRT_entry_Number_l), it can be assumed that the reading procedure has advanced as far as the penultimate one, so that a "Yes" judgment is provided in step S44 and processing progresses to step S45 in Figure 58 . { 52-9_57-2} The procedure constituted of steps S45 to S54 resembles the procedure constituted of steps S33 to S42 where each of the AOB_FRAME in the final AOB_ELEMENT are read. The difference with the procedure constituted from steps S33 to S42 is that although the looping method constituted of steps S33 to S42 ends when a judgment is established in step S41 that variable #x has reached a value in "FNs_Middle_TMSRTE" , the looping method consisting of steps S45 to S54 ends when a judgment is established in step S53 that the variable #x has reached a value in "Fns_Last_TMSRTE" and the variable play_data shows the size of the data that has hitherto been have read and have reached the value provided as "SZ_DATA". The method consisting of steps S49 to S54 is repeated until the conditions in step S53 are met, at which point a "Yes" judgment is provided in step S53 and the processing proceeds to step S55. In step S55, the CPU 10 increments the variable #z (# z- # z + l) before the processing returns to the step S21 where the CPU 10 waits for the next AOB file to accumulate it in the buffer 15 double. Once this happens, the processing proceeds to step S22 and the procedure consisting of steps S22 to step S54 is repeated. This means that the TKI indicated by the DPL_TKIN of the following DPL_TK_SRP is specified and that the AOB file corresponding to this TKI, that is, the AOB file with the same number as the TKI, is the one specified. After this, the playback device accesses the authentication region and specifies the FileKey, in addition to the FileKeys in the encoding key storage file having the same number as the TKI, before reading this FileKey and setting it in the decoder 7. As a result, the A0B_FRAME included in the AOB file that have the same number as the TKI are read and played successively. . { 52 - 9_57 - 3_59} Update of the Time Code of Reproduction Figures 59A to 59D show the playback time code displayed in the playback time code display box of the LCD panel 5 which is incremented according to the update of the play_time variable. In Fig. 59A, the playback time code is "00: 00: 00,000", then, when the playback of AOB_FRAME # l ends, a playback period of 20 msec is added to A0B_FRAME # 1 to the playback time code to update it to "00: 00: 00.020", as shown in Figure 59B. When playback of A0B_FRAME # 2 is finished, a playback period of 20 msec from AOB_FRAME # 2 is added to the playtime code to update it to "00: 00: 00.040", as shown in Figure 59C. In the same way, when AOB_FRAME # 6 is finished playing, a playback time of 20 msec from AOB_FRAME # 6 is added to the playtime code to update it to "00: 00: 00.120" as shown in Figure 59D . This completes the description of the exit procedure of A0B_FRAME. In step S31 of the flowchart in figure 56, if the user presses a button in addition to the "Play" button, the processing in this flowchart ends. The processing that accompanies the pressure of the "Stop" or "Pause" buttons has been described beforehand, although when the user presses one of the buttons provided to have a playback device that performs a special reproduction, the processing in this flow diagram, or in the flow diagrams shown in figures 56, 57 or 58 is completed and the appropriate processing is performed for the pressed button. The following describes the procedure performed by the CPU 10 (1) when performing the forward search function in response to the action where the user presses the "> >" button and (2) when performing a search function of time in response to a user action of the selection switch after pressing the "Pause" or "Stop" button. . { 52-10_60} Search Function Forward Figure 60 is a flow diagram showing the procedure that is carried out by the CPU when performing the forward search function. When the user presses the ">" button, a "Yes" judgment is provided in step S31, step S42 or step S54 in the flowcharts in figures 56, 57 and 58, and CPU 10 performs the processing in the flowchart of Fig. 60. In step S61, the AOB_FRAME #x for # (x + f (t) -l) are input into decoder 7. Here, "t" represents the reproduction period intermittent, f (t) represents the number of frames corresponding to the intermittent reproduction period and d (t) represents the amount of data corresponding to the intermittent reproduction period. In step S62, the variable play_time shows the elapsed playing time, and the variable play_data shows the amount of playback data that is respectively updated using an intermittent playback period "t", the number of frames f (t) that corresponds to the period of intermittent reproduction, and the amount of data d (t) that corresponds to the period of intermittent reproduction (x-x + f (t), play_time-play_time + t, play_data-play_data + d (t)). Note that the intermittent reproduction period will generally be 240 msec (equivalent to the reproduction period of twelve A0B_FRAME). . { 52-10_60-l_61A, B} Figures 61A and 61B show the increase of the playback time code during a forward search operation. Figure 61A shows the initial value of the playback time code, with a playback point that is AOB_FRAME # l in AOB_ELEMENT # 51. The playback time code in this case is "00: 00: 01.000". When the first to the twelfth AOB_FRAME within the decoder 7 have been input as the intermittent playback period, the reproduction period of twelve A0B_FRAME (ie 240 msec) is added to the playback time code so that the time code Playback becomes "00: 00: 01.240" as shown in Figure 61B. . { 52-10_60-2} After this update, in step S63, the CPU 10 compares the variable #x incremented with the total number of frames in AOB_ELEMENT # y and establishes a judgment of whether the variable #x incremented is within the total number of frames in AOB_ELEMENT # and . As mentioned above, the number of frames in an AOB_ELEMENT placed at the start of an AOB is "FNs_lst_TMSRTE", the number of frames in an AOB_ELEMENT placed in a central part of an AOB is "FNs_Middle_TMSRTE", and the number of frames in a AOB_ELEMENT placed at the end of an AOB is "FNs_Last_TMSRTE". The CPU 10 performs the previous judgment by comparing one of these values, appropriate, with the variable #x. When the variable x is not within the present AOB_ELEMENT # y, the CPU 10 then makes a judgment in step S64 of whether there is an AOB_ELEMENT that follows the AOB_ELEMENT # y. When AOB_ELEMENT # and end in an AOB_ELEMENT, then there will be no A0B_BL0CK, which follows the AOB_ELEMENT so that the "No" judgment is provided in step S64 and the processing in the present flow chart ends. Conversely, when there is an AOB_ELEMENT, the AOB_ELEMENT # is followed and, in step S65, the variable #x is reduced in the number of A0B_FRAME in the AOB_ELEMENT # and in the step S66 the variable #y (# and ^ # y + is updated) i). As a result, the variable #x will now indicate the frame position of a frame in the next AOB_ELEMENT # and indicated by the variable #y updated. Conversely, when the variable "x" indicates an AOB_FRAME that is present in the current AOB_ELEMENT (S63_FRAME), the processing in steps S64-S66 is skipped and the processing proceeds to step S67. . { 52-10_60-3} After this, the variables #x, play_time and play_data are updated according to the intermittent jump period. The "skip_time" period that is equivalent to the intermittent jump period is two seconds, the number of frames that are equivalent to this skip_time is given as f (skip_time) and the amount of data that is equivalent to this skip_time is provided as d (skip-time). In step S67. these values are used to update the variables #x, play_time and play_data (# x - # x + f (s k i p_ t i me), play_time-play_time + skip_time and play_data - ^ - play_data + d- (skip_time)). . { 52-10_60_4-61C] As shown in Figure 61C, the intermittent jump period is added to the variable "x that shows a box position within A0B_ELEMENT # 51. When the updated #x variable exceeds the number of frames in AOB_ELEMENT # 51 the variable #y to indicate the following AOB_ELEMENT and the number of frames in AOB_ELEMENT # 51 is subtracted from variable #x.As a result, variable #x will now indicate a box position within AOB_ELEMENT # 52 indicated by variable # and then added the value 2,000 (= 2 sec) to the current value "00: 00: 01.240" of the playback time code so that it becomes "00: 00: 03.240." The variable #x is updated to the calculate (3240 msec - 2000 msec) / 20 msec) to provide the value "62" and thus indicate the AOB_FRAME # 62 in the AOB ELEMENT # 52. . { 52-10_60-5_61 (d)} Once AOB_FRAME # 62 in AOB_ELEMENT # 52 has been entered in decoder 7, the playback time code is updated as shown in Figure 61D by adding "0.240" to the current value of "00: 00: 03.240"to provide" 00: 00: 03.480". In step S67, the variables are updated according to the intermittent jump time and then the processing is performed in steps S68 to S71. This processing in steps S68 to S71 is the same as the processing in steps S63 to S66 and thus updates the variable #x by a number of frames which is equivalent to the skip time time "skip_time" before verifying whether the variable #x still indicates an AOB_FRAME within the present AOB_ELEMENT # y. Otherwise, variable #y is updated so that the following AOB_ELEMENT is set as AOB_ELEMENT # y and variable #x is converted to indicate a frame position in this next AOB_ELEMENT. Once the variables #x and #y are in accordance with the intermittent playback time and the intermittent jump time, in step S72 the CPU 10 refers to TKTMSRT and calculates the start address for the AOB_ELEMENT # y. Then, in step S73, the CPU 10 begins the search by an ADTS header from the start addresses of the AOB_ELEMENT # and to detect the AOB_FRAME # x. In step S74, the CPU 10 judges whether the user has pressed a button in addition to the forward search button. If this is not the case, the AOB_FRAME of the AOB_FRAME # x for the AOB_FRAME # x + f (t) -1 is entered into the decoder 7, and the processing is repeated in steps S62 to S73. The above procedure increases the variables #x and #y that indicate the AOB_FRAME # x and the AOB_ELEMENT # y and in this way advances the playback position. After this, if the user presses the "Play" button, a "No" judgment is provided in Figure 74 and processing ends in the present flowchart. . { 52-11} Execution of the Time Search Function The following describes the processing that takes place when the time search function is used. First, the tracks in the Default_Playlist_Information are displayed and the user indicates the desired track. When this track has been indicated and the user has operated the selection switch, the playback time code is updated. If the user then presses the "Play" button, the playback time code is used at this point to set a value in the variable "Jmp_Entry" in seconds. A judgment is then made as to whether the indicated track is constituted of a plurality of AOB or a single AOB. When the track is made up of a single AOB, the variables tty and #x are calculated so that they satisfy equation 2. After this, a search by the AOB_FRAME # x starts from the address in the position (y + 2) thirtieth in the TKTMSRT corresponding to this AOB. Once this AOB_FRAME # x has been found, playback of the AOB_FRAME # x starts. . { 52-12} When the track is constituted by a plurality of AOB, the variables #n (indicative of an AOB), #y and #x are calculated so as to satisfy equation 3. After this, a search is initiated by the AOB_FRAME # x to start of the address in the position (y + 2) th in the TKTMSRT corresponding to the AOB # n. Once this AOB_FRAME # x has been found, playback starts from AOB_FRAME # x. The following describes the case in which playback is started from an arbitrary position with an AOB where the "FNs_lst_TMSRTE" in the BIT is "80 frames", "FNs_Middl e_TMSRTE" in the BIT is "94 frames", and " FNs Last TMSRTE "in the BIT is" 50 frames ". . { 52-13_62A, B} As a specific example of the time when a time search function is used, the following describes the way in which AOB_ELEMENT and the frame position from which the start of playback is specified when the time code is indicated. of reproduction using the selection knob. As shown in Fig. 62A, the user holds the playback apparatus in his hand and rotates the selection knob with his right thumb to indicate the playback time code "00: 04: 40,000 (= 280 sec)". When the BIT in the TKI for this AOB is as shown in Figure 62B, Equation 2 is used as follows 280 sec = (FNs_lst_TMSRTE + (FNs_Middle_TMSRTE * y) + x) * 20 msec = (80+ (94 * 148) +8) * 20 msec so that equation 2 is satisfied by the values y = 148 and x = 8. Since y = 148, the input address of AOB_ELEMENT # 150 (= 148 + 2) is obtained from TKTMSRT. Playback from the indicated playing time code 00: 04: 40,000 (= 280.00 sec) can then be carried out at the start of playback in the eighth AOB_FRAME from this input address. . { 52-14_63_64_65} This completes the explanation of the processing of the CPU 10 in response to the pressure that the user makes of the "Play" button. The following describes the editing control program stored in ROM 4. This editing control program is executed when the user presses the "Edit" button and contains the procedures shown in Figures 63, 64 and 65. The following describes the processing in this program with the flow diagrams shown in these drawings. . { 52-14_61-l} Editing Control Program When the user presses the "Edit" button, an interactive screen is displayed in stage SlOl in figure 63 to ask the user which of the three fundamental editing operations is going to be done: deletion "," division "and" combination " In the step S102, the CPU 10 judges that operation has been performed by the user in response to the interactive screen In the present example, it is assumed that the buttons "| < < "and" > > | "on the button panel, as indicated by the cursor operations" Up "(up) and" Down "(down) (ie, these buttons are used as cursor buttons" Up "and" Down "). When the user indicates a "delete" operation, he proceeds to the looping method consisting of steps S103 and S104.In step S103, the CPU 10 judges whether a user has pressed the "| <" buttons.; < "and" > > In the step S104, the CPU 10 judges whether the user has pressed the "Edit" button, when the user has pressed the "| < < "and" > > | ", the processing progresses from step S103 to S105, where the track indicated as the track to be edited is established.On the other hand, when the user has pressed the" Edit "button, the track indicated as the track to be deleted The processing shown in Figure 44 is executed, so that TKI_BLK_ATR of each TKI for the indicated track is set to "not used" to delete the indicated track. . { 52-14_63-2} Combination processes When the user selects the combination process, the processing progresses from step S102 to the looping method constituted of steps S107 to S109. In the looping method constituted of steps S107 to S109, the reproduction apparatus receives the user's inputs via the "| <<", "> >", and "Edit" buttons. When the user presses the "| < <" or "> >" processing proceeds from step S107 to step S110 where the indicated track is highlighted on the screen. When the user presses the "Edit" button, a "Yes" judgment is provided in step S108 and the processing proceeds in step Slll. In step Slll, the currently indicated track is established as the first track to be used in this editing process and the processing returns to the looping method consisting of steps S107 to S109. When the second track for editing is selected, a "Yes" judgment is provided in step S109, and the processing proceeds to step S112. In step S112, the CPU 110 refers to the BITs in the TKIs of the previous and last tracks and makes a judgment of what kind of AOB (type 1 or type 2) are present at the respective start and end of each of these tracks and the tracks on both sides of these tracks, in case they are present. After identifying the type of each relevant AOB, in step S103 the CPU 10 makes a judgment as to whether the arrangement of the AOB matches a certain pattern. When the arrangement of the AOB matches one of the four patterns shown in Figure 32A to 32D where it is clear that three AOB type 2 will not be present consecutively after the combination, the previous and last tracks are combined in a single track in stage S115. In other words, the operation shown in Figure 46 is performed for the TKI and DPL_TK_SRP corresponding to these AOBs. When rewriting the TKI_BLK_ATRs in the TKIs, the plurality of tracks selected for editing are combined into a single track. When the arrangement of the AOB does not match any of the patterns in Figures 32A to 32D, a message that there will be three or more AOB type 2 after the combination, the CPU 10 judges that the combined track may cause a memory subflow. intermediate and in this way the combination process ends. . { 52-14_64-l} Track Splitting Process When the user indicates that a track is to be divided, the processing proceeds from step S102 to the looping method consisting of steps S116 to S117. In the looping method consisting of steps S116 to S117, the reproduction apparatus receives the user's entries via the "| <<", "> >" and "Edit". When the user presses the "| <<" or ">" button, the processing proceeds from step S116 to step S118 where the indicated track is set as the track to be avoided. When the user presses the "Edit" button, a "Yes" judgment is provided in step S117 and the processing proceeds to step S119. In step S119, the indicated track is determined as the track to be edited and the processing advances to step S120 where playback of this track begins.

In step S121, the reproduction apparatus receives a user input by means of the "Mark" button. When the user presses the "Mark" button, a pause of the playback of the track is established and the processing proceeds to the looping method constituted of steps S122 and S123. In step S122, the reproduction apparatus receives user instructions made by the selection switch. When the user rotates the selection switch, the reproduction time code in step S124 is updated according to the rotation of the selection switch. After this, the looping method consisting of steps S122 and S123 is repeated. If the user presses the "Edit" button, processing proceeds from step S123 of step S125, where the playback time code displayed when the user presses the "Edit" button as the division limit is set. Note that an "undo" function can be provided for this split limit setting to allow the user to override the selected split limit. After this, the processing explained with reference to FIG. 47 is executed in step S126 to update the DPLI and TKI so that the selected track is divided. . { 52-14_65-l} Process of Establishing a Playlist When the user chooses to establish a Playlist, the processing switches to the procedure shown in the flow diagram in Figure 65. In this flowchart, the variable k provided in this flowchart is used to indicate the position of a track in the order of reproduction provided by the Playlist that is edited at that moment. The flow chart in Figure 65 starts with this variable k which is initialized to "1" in step S131, before the processing proceeds to the procedure loop constituted of steps S132 to S134. In the looping method consisting of steps S132 to S134, the reproduction apparatus receives the user's operations by means of the buttons "| < <", "> > |", "Edit" and "Stop" . When the user presses the "| <<" or ">" button, the processing proceeds from step S132 to step S135 where a new track is indicated according to the "| <" button pressed.; < "or" > > ". If the user presses the "Edit" button, a "Yes" judgment is provided in step S133 and the processing proceeds to step S136. In step S136, the track indicated when the user presses the "Edit" button is selected as the kth track in the order of playback. After this, step S137, the variable k increases and the processing returns to the looping method constituted of steps S132 to S134. This procedure is repeated so that the second, third and fourth tracks are successively selected. If the user presses the "Stop" button that has specified several tracks that are to be played in the order specified as a new Playlist, the processing proceeds from step S134 to step S138 where a PLI consisting of PL_TK_SRP is generated. specifies the TKIs corresponding to these tracks. . { 66-1} Recording device The following describes an example of a recording apparatus for the instant memory card 31. Figure 66 shows an example of a recording apparatus. This recording device can be connected to the Internet, and it is a standard personal computer that can perform the reception when an SD-Audio directory encoded via the communication lines to the recording device is sent by an electronic music distribution service, or when a stream of audio data transport is sent via communication lines to the recording apparatus by an electronic music distribution service. . { 67-1} Hardware Composition of the Recording Apparatus Figure 67 shows the hardware composition of the present recording apparatus. As shown in Fig. 67, the recording apparatus includes a card connector 21 for connecting the recording apparatus to the instant memory card 31, a RAM 22, a non-removable disk apparatus 23 for storing a control program of recording that performs full control over the recording apparatus, an A / D converter 24 that converts A / D audio input via a microphone to produce PCM data, an ACC encoder 25 for encoding the PCM data into units of a fixed time and assigning ADTS headers to produce A0B_FRAME, a code unit 26 for encoding the A0B_FRAME using a different FileKey for each A0B_BL0CK, a modem apparatus 27 for receiving an audio data transport stream when an encoded SD-Audio directory is sent via the lines of communication to the recording apparatus by an electronic music distribution service, or when an audio data transport stream is sent io via the communication lines to the recording apparatus by an electronic search distribution service, a CPU 28 to perform full control over the recording apparatus, a keyboard 29 to receive the inputs made by the user, and a screen 30. . { 67-2} Input Circuits RT1 to RT4 When an encoded SD-Audio directory, which is to be written to the data region and the authentication region, is sent via the communication lines to the recording apparatus by an electronic music distribution service, the recording apparatus you can write the SD-Audio directory encoded in the data region and the authentication region of the instant memory card 31 as soon as the encoded SD-Audio directory has been properly received. However, (1) when the stream of audio data transport that is not in the form of an SD-Audio directory is sent to the recording apparatus by an electronic music distribution service, (2) when the data is input into of the recording apparatus in the PCM format, or (3) when analog audio is recorded by the recording apparatus, the recording apparatus uses the following four input paths to write a stream of audio data transport on a card 31 of instant memory. As shown in Figure 67, the four input paths RT1, RT2, RT3 and RT4 are used to input an audio data transport stream when an audio data transport stream is stored in the instant memory card 31 . . { 67-3} Route of Entry RT1 The RT1 input channel is used when an encoded SD-Audio directory is sent via the communication lines to the recording device by an electronic music distribution service, or when a stream of audio data transport is sent by means of communication lines to the recording apparatus by an electronic music distribution service. In this case, the AOB_FRAME included in the transport stream are coded so that a different FileKey is used for the AOB_FRAME in the different AOB- Since there is no need to encrypt or encrypt a coded transport stream, the SD- directory Audio or audio data transport stream can be stored directly in RAM 22 in its encoded state. . { 67-} Route of Entry RT2 The RT2 input channel is used when audio is input via a microphone. In this case, the audio introduced through the microphone is subjected to an A / D conversion by the 24 A / D converter to produce PCM data. The PCM data is then encoded by the AAC encoder 25 and ADTS headers assigned to produce the AOB_FRAME. After this, the encoding unit 26 encodes the A0B_FRAME using a different FileKey for each A0B_FRAME in different AOB_FILE to produce encoded audio data. After this, the encoded audio data is stored in RAM 22. . { 67-5} Route of Entry RT3 The RT3 input channel is used when the PCM data read from a CD is input to the recording device. Since the data is entered in PCM format, the data can be entered as it is inside the AAC encoder 25. This PCM data is encoded by the ACC encoder 25 and the ADTS headers are assigned to produce the A0B_FRAME. After this, the encoding unit 26 encodes the A0B_FRAME using a different FileKey for the AOB_FRAME in different AOBs to produce encoded audio data. After this, the encoded audio data is stored in RAM 22. . { 67-6} Route of Entry RT4 The input path RT4 is used when a transport current is input via one of the three input channels RT1, RT2 and RT3 which is written into the instant memory card 31. This storage of audio data is carried out by the generation of the TKI and Default_Playlist_Information.

In the same manner as a reproduction apparatus, the main operation of the recording apparatus is stored in the ROM. That is, a recording program is stored which includes the processing of features of the recording apparatus, that is, the recording of the AOBs, the TrackManager and the PlayListManager in the non-removable disk apparatus 23. . { 67-7_68} Processing of the Recording Apparatus The following describes the processing in the recording procedure that writes a transport stream in the flash card 31 by means of the input paths RT1, RT2, RT3 and RT4, with reference to the flow chart in figure 68 which shows this processing. The variables "Frame_Number" and "Data_Size" used in the flowchart are as follows. The variable "Frame_Number" is used to handle the total number of A0B_FRAME that have already been registered in an A0B_FILE. The Data_Size variable is used to handle the data size of the AOB_FRAME that has already been registered in the AOB_FILE. Processing in this flowchart begins at step S200 with CPU 28 generating the DefaultPlaylist and the TrackManager. In step S201, the CPU 28 initializes the variable #z (z-1). In step S202, the CPU 28 generates the A0B_FILE # z and stores it in the data region of the instant memory card 31. At this point, the filename, extension filename or file name and the first group number for the AOB_FILE # z will be set to a directory entry in the SD-Audio directory in the data region. After this, in step S203, the CPU 28 generates TKI # z and stores it in the TrackManager. In step S204, the CPU 28 generates DPL_TK_SRP # w and stores it in Default_Playlist_Information. After this, in step S205, CPU 28 initializes variable #y (# and -l) and in step S206, CPU 28 initializes Frame_Number and Data_Size (FRame_Number * -0, Data_Size <-0). In step S207, the CPU 28 judges whether the input of the audio data transport stream to be written to the A0B_FILE # has ended. When the input of an audio data transport stream that has been encoded by the AAC encoder 25 has been encrypted or encoded by the encoder unit 26 in RAM 22 continues and it is necessary to continue writing group data, the CPU 28 provides the "No" judgment in step S207 and the processing proceeds to step S209. In step S209, the CPU judges whether the amount of AAC audio data accumulated in the RAM 22 is at least equal to the group size. If so, the CPU 28 provides the "Yes" judgment and the processing proceeds to step S210 wherein an amount of AAC audio data equal to the group size is written into the instant memory card 31. The processing then proceeds to step S211. When sufficient AAC audio data has not been accumulated in RAM 22, step S210 is skipped and the. processing proceeds to step S211. In step S211, the CPU increments the Frame_Number (Frame_Number <-Frame_Number + l) and increments the value of the Data_Size variable by the data size of AOB_FRAME. After this update, in step S212 the CPU 28 judges whether the value of Frame_Number has reached the number of frames that is set in "FNs_MIddle_TMSRTE", the value of "FNs_Middle__TMSRTE" is set according to the sampling frequency used when encodes the audio data transport stream. When the Frame_Number value has reached the number of frames set in "FNs_Middle TMSRTE", the CPU 28 provides the "Yes" judgment in step S212. Otherwise, the CPU 28 provides the "No" judgment, and the processing returns to step S207. The processing in steps S207 to S212 is therefore repeated until a "Yes" judgment is provided in either step S207 or step S212. When the variable Frame_Number reaches the value of "FNs_Middle_TMSRTE", the CPU 28 provides the "Yes" judgment in step S212 and the processing proceeds from step S212 to step S213 where Data_Size is stored in the TKTMSRT of TKI # z as TMSRT_entry # and for AOB_ELEMENT # y. In step S214, the CPU 28 increments the variable #y (#y < - # and + l) before verification in step S215 of whether the variable #y has reached "252". The value "252" is used, since this is the maximum number of AOB_ELEMENT that can be stored in a single AOB. If the variable #y is below 252, processing proceeds to step S216, where the CPU 28 judges whether a silence of a predetermined length is present in the encoded audio, which means that the audio data has reached a present separation between tracks. When such continuous silence is not present, the processing constituted of steps S206 to S215 is repeated. When the variable tty has reached the value 252, or a silence of a predetermined length is present in the encoded audio, the judgment of "Yes" is provided in one of the steps S215 and S216 and the processing advances to the step S217 where the variable #z (# z- # z + l) is increased. After this, the processing is repeated in steps S202 to S216 for the variable #z increased. By repeating this processing, the CPU 28 may have AOBs that include a plurality of AOB_ELEMENTS registered one after the other within the instant memory card 31. When the transfer of an audio data transport stream by an AAC encoder, the coding unit, and the modem apparatus 27 are complete, this means that the input of the audio data transport stream is to be written in the AOB_FILE # z which will also be complete, so that a "Yes" judgment is provided in step S207 and the processing proceeds to step S208. In step S208, the CPU 28 stores the value of the Data_Size variable in TKTMSRT of TKI # z as TMSRT_Entry # and for the AOB_ELEMENT # y. After storing the accumulated audio data in RAM 22 in the AOB file corresponding to A0B # z, the processing in this flowchart terminates. The above processing results in the coded addition data transport stream being stored in the instant memory card 31. The following procedure is then used to store the FileKey necessary to decode the stream of audio data encoded in the authentication region. When the audio data transport stream has been entered via the RT1 path, the AOB file (s), the file that stores the TKMG, the file that stores the PLMG, and the file that stores the encryption key are stored in a different FileKey for each AOB and sent to the recording device by an electronic music distribution service provider. The CPU 28 receives these files and writes the AOB file (s), the file stores the TKMG and the file stores the PLMG in the user region of the instant memory card 31. On the other hand, the CPU 28 writes only the encoding key storage file that stores a different FileKey for each AOB within the authentication region. When audio is input via the RT2 or RT3 input channel, the CPU 28 generates a different FileKey each time the coding of a new AOB starts and sets the key generated in the encoding unit 26. In addition to being used by the encoding unit 26 to encode the present AOB, this FileKey is stored after the input FileKey in the file that stores the encoding key present in the authentication region. With the present embodiment described above, the files storing the AOBs are encoded using different encoding keys so that if the encoding key used to encode a file is decoded and exposed, the exposed encoding key can only be used to decode a file. file that stores an AOB, with such exposure without effect on other AOBs that are stored in other files. This minimizes the damage caused when a coding key is exposed. Note that although the above description focuses on an example system that is considered to be the most effective mode of the present invention, the present invention is not limited to this system. Various modifications are possible within the scope of the invention, with examples of such being provided as subsections (a) to (e) below. (a) The above embodiment describes a semiconductor memory (instant memory card) as a recording medium used, although the present invention can be applied to other media including optical discs, such as DVD-RAM, or a hard disk. (b) In the above embodiment, the audio data is described as consisting of an AAC format, although the present invention can also be applied to audio data in another format such as MP3 (MPEG1 audio layer 3), Dolby-AC3 or DTS (digital theater system). (c) While the file that stores TKMG and the file that stores PLMG is described as received from the electronic music distribution service provider in a complete form, the main information used to create TKMG and PLMG can be transmitted along with the encoding key of the storage file that stores a different encoding key for each AOB. The recording apparatus can then process this information to obtain the TKMG and PLMG which is then recorded on the instant memory card. (d) For an easy explanation, the recording apparatus and the reproduction apparatus are described as separate devices, although a portable reproduction apparatus can be equipped with the operation of a recording apparatus and a recording apparatus in the form of a computer personnel can be equipped with the functions of the reproduction apparatus. In addition to the portable reproduction apparatus and the personal computer recording apparatus, the functions of the reproduction apparatus and the recording apparatus may also be provided to a communication device that is capable of downloading the contents of a network. As an example, a mobile telephone capable of accessing the Internet can be provided with the functions of the reproduction apparatus and the recording apparatus described in the above embodiment. This mobile phone can store the downloaded content via a wireless network on the instant memory card 31 in the same manner as in the previous mode. Further, although the recording apparatus described in the above embodiment is provided with the modem apparatus 27 for connection to the Internet, any other device capable of connection to the Internet such as a terminal adapter for a line can be provided instead. ISDN. (e) The procedure shown in the flow diagrams shown in figures 55 to 58, figure 60, figure 63 to figure 65 and figure 68 can be carried out by executable programs that can be distributed on having been recorded in a recording medium. This recording medium can be an IC card, an optical disc, a floppy disk or the like, with the programs recorded in the recording medium being used that have been installed for the first time within standard computer hardware. When performing the processing in accordance with such installed programs, the standard computer hardware can perform the same operation as a reproducing apparatus and the recording apparatus described in the above embodiment. (f) Aungue the above embodiment describes the case in which a plurality of AOB and a plurality of FileKeys are stored in the instant memory card 31, only an AOB and a FileKey need to be stored. In addition, it is not essential for the AOB to be encoded, so that the AOB can be stored in the instant memory card 31 in ACC format.

SECOND MODALITY . { 69-1} Total Composition of the PlaylistManager in the Second Modality This second modality is related to an improvement in the semiconductor memory card of the first mode in which it allows a reproduction apparatus to assume the reproduction without repeating tracks that were previously reproduced. Figure 69 shows the internal composition of the PlaylistManager and TrackManager in this second mode. The PlaylistManager and TrackManager in this second mode differ from those shown in Figure 17 in that the composition of the PlaylistManager_Inf ormation (PLMGI) is clearly shown in Figure 69, unlike Figure 17. It is of particular importance in the PLMGI the PLMG_RSM_PL . This shows the playback resume position, and is stored in a semiconductor memory card to allow a playback apparatus to restart the playback of the content without having to repeatedly play the same data. . { 70-1} Detailed Composition of PlaylistManager information Figure 70 shows the detailed composition of the PlaylistManager_Inf ormation. As shown in the drawing, the PLMGI has a PLM_ID field that occupies the tenth and first objects, a reserved field that occupies the second and third octets an SDA_ID field that occupies the fourth to the eleventh octets, a VERN field that occupies the tenth second and thirteenth octets, a PLMG_PL_Ns field that occupies the fourteenth and fifteenth octets, a PLMG_AP_PL field that occupies the sixteenth to nineteen octets, a PLMG_RSM_PL field that occupies the twentieth to twenty-seventh octets, and a PLMG_APP_ATR field that occupies the twenty-eighth and twenty-ninth octets, a PLMG_FCA field occupying the thirty-first and thirty-first octets, a field TKI_Ns that occupies the thirty-second and thirty-third bytes and a reserved field occupying the thirty-fourth and thirty-fifth bytes. Of these fields in the PlaylistManager, the most important in this second mode are PLMG_AP_PL and PLMG_RSM_PL. . { 70-2} Information in addition to PLMG_AP_PL and PLMG_RSM_PL The following describes the fields in the PlaylistManager in addition to PLMG_AP_PL and PLMG_RSM_PL first. The PLMG_ID is set to "Al" (an ordered sequence of characters that is set according to the IS0646 standard) to display the present information as a PLMGI. The SDA_ID is set to "SD_AUDIO" (an ordered sequence of characters that is set according to the IS0646 standard) to show that the present PlaylistManager is data, according to the SD-UDIO specification. A version number for the SDS-AUDIO specification used is set in the VERN field. Dashed line h.71 in Figure 70 shows the bit composition of the version number. The field consisting of bits b7 to bO is used to store the version number.

When, for example, the version number of the present PlaylistManager is "version 0.9", it is written "09h" in this field, and when the version number is "version 1.0", in this field "lOh" is written. The field composed of bits bl5 to b8 is reserved for future use. The number of playlists managed by the PLMG, which is the number of playlists registered in this instant memory card, is written in the field PLMG_PL_Ns. The application category ID, which shows the category of the application registered on the instant memory card present, is written to the PLMG_APP_ATR field. When, as in the first mode, the application stored in this instant memory card is music, the value "Olh" is written in this field. When the application recorded on this instant memory card is karaoke software, the value "02h" is written in this field, when the application is presentation data, the value "03h" is written in this field, and when the application is an audiobook, in this field the value "04h" is written. When the application category ID is "02h", the audio data is recorded in this instant memory card as karaoke data, so that the right channel is used for playing the tracks and the left channel is used for the voices. When the audio data is recorded in this manner, a playback apparatus can play a karaoke support track by playing the audio data for the right channel on both the left and right channels. The PLMG_FCA field is reserved for future use. An integer that shows the number of the TKIs, like that of the first modality, is written in the TKN_Ns field. This value is provided with a range of "1" to "999". This completes the explanation of the fields in the PlayManager in addition to PLMG_AP_PL and PLMG_RSM_PL. . { 70-3} PLMG_AP_PL The PLMG_AP_PL shows the playlist number that is automatically read and the number of the first track which is automatically played in that playlist when the instant memory card is loaded in a playback device and the playback apparatus is activated. Dashed line h.72 in Figure 70 shows the composition of bits of the four octets of the PLMG_AP_PL. The field between bit b31 and b26 and the field between bl5 and b8 are reserved for future use. Bits b7 to bO form a field of Playlist Number in which the number of the Playlist is read automatically and is provided in a range of "1" to "99" (in decimal). The number written in this field is the Playlist_Information (PLI) number as described in the first modality. To indicate the Def aul t_Playlist_Inf ormation, write the number "0". Bits b25 to bl6 form a Track_Number field (track number) in which the track number of the plurality of tracks specified by the playlist that is provided can be automatically played. The number written in this field is the Track_Number as described in the first modality. The values in the PLMG_AP_PL fields can be set freely by the user, and must be set to "0" when PLMG AP PL is not used. . { 70-4} PLMG_RSM_PL When the playback has already been made for one or more AOB files registered in the instant memory card, the PLMG_RSM_PL will include a Playlist Number that shows the playlist that is used for the previous reproduction of data in the instant memory card. A Track Number that shows the number of the last track to be played according to this playlist, and PlaybackTime shows where playback stopped on the track indicated by Track Number.

In Figure 70, dashed line h.73 shows the bit composition of the PLMG_RSM_PL. The bit composition of bit number b31 to bit number bO is the same as PLMG_AP_PL. The playlist number that is used for the previous playback is written as a value in the range from "0" to "99" in the Playlist Number field that occupies the region from bit number b7 to bit bO. The number of the last track that is played from the various tracks specified in this playlist is written in the Track Number field that occupies the region from bit number b25 to bit number bl6. Unlike the bit composition of PLMG_AP_PL, the region of bit number b32 to bit number b63 of PLMG_RSM_PL forms a Playback_Time field. The moment at which the previous playback of the track indicated by Track Number stops is written in this field with millisecond precision. Note that when PLMG_RSM_PL is not used by the user, a value of "0" must be set in all fields of the PLMG_RSM_PL. . { 70-4_7l} Establishment of the PLMG_RSM_PL when the Instant Memory Card is Transfers between Playback Devices The following describes how they are established PLMG_AP_PL and PLMG_RSM_PL when the instant memory card of this second mode is transferred between playback devices. Figure 71 shows the manner in which PLMG_AP_PL and PLMG_RSM_PL are established when the instant memory card of this second mode is transferred between reproduction apparatuses. In FIG. 71, the instant memory card is transferred between a plurality of reproduction apparatuses that are constituted of a standard personal computer, a portable reproduction apparatus and a reproduction apparatus in a vehicle. Note that each of these reproduction apparatuses is equipped with the functions of the reproduction apparatus and recording apparatus described in the first embodiment. The present disclosure describes an instantaneous memory card that stores the AOB files that make up TrackA to TrackE in the same manner as in Figure 16. Assuming that the instant memory card of this second mode is first loaded into the personal computer 200. which registers the presentation data and the navigation data described in the first modality. Suppose after this, that the personal computer 200 establishes the PLMG_AP_PL with the Playlist_Number "0", indicating that Def ault_Playlist_Inf ormation and Track_Number "3" indicating TrackC. In this example, the user has the AOB files on the instant memory card played in the order TrackA, TrackB and TrackC and the playback stops at a point 3 min 31 sec within the playback of TrackC whose playback period is 5.5 minutes In this case, the personal computer 200 writes the Playlist_Number "0" indicating that Def aul t_Playlist_Inf ormation and Track_Number "3" indicating the TrackC within the field PLMG_RSM_PL. In addition, the personal computer 200 also writes the value "00: 03: 31: 000" which shows the point at which playback was stopped for the TrackC within the Playback_Time field in PLMG_RSM_PL. After this, the user removes the instant memory card from the personal computer 200 and, as shown by the arrow my71, loads it into the portable playback apparatus 100. In the first modality, the reproduction apparatus (the portable playback apparatus 100) starts playback with the first A0B_FRAME in TrackA which is specified by Def aul t_Playlist_Inf ormation. In this second embodiment, however, the PLMG_AP_PL and PLMG_RSM_PL are provided so that the reproduction apparatus can start playback from any AOB_FRAME according to the content of this information. Since the personal computer 200 sets the value of "0" in Playlist_Number to indicate the Default_Playlist_Information value of "3" in Track_Number to indicate TrackC and "00: 03: 31,000" in Playback_Time, the portable playback apparatus 100 now knows that the reproduction has been made up to the point of 3 min 31 secs in TrackC in Default_Playlist_Information and that the reproduction can be done from a point 3 minutes and 31,001 seconds in TrackC. Assuming that the user places his headphones attached to the portable player apparatus 100 and leaves the house after TrackC playback has begun. In the present example, the user listens to the end of the TrackC part and then a first part of TrackD, stopping playback at a point 10 minutes and 30 seconds in TrackD playback. In this case, the portable playback apparatus 100 updates the content of PLMG_RMS_PL by writing "0" in the Playl is t_Number to indicate the Default_Playlist_Information "4" in Track_Number to indicate TrackD and "00: 10: 30,000" in Playback_Time to indicate that playback has stopped at a point 10 minutes and 30 seconds within TrackD playback. On the other hand, the content of PLMG_AP_PL has not been rewritten, so Playlist_Number is set to "O" to indicate the Default_Playlist_Information and Track_Number remains at "3" to indicate TrackC. After this, suppose that the user removes the flash memory card from the portable playback apparatus 100 and, as shown by the arrow my72 in Figure 71, places it in a player 300 in a vehicle. Since the portable reproduction apparatus 100 sets the value "0" in Playlist_Number to indicate the Default_Playlist_Information, the value "4" in TrackJSTumber to indicate TrackD and "00: 10: 30,000" in Playback__Time in the player 300 in the vehicle now knows that playback has already been made to the point of 10 min and 30 sec in the TrackD in Default_Playlist_Information and that playback can be started at the 10 minute and 30,001 seconds point in TrackD. TrackD playback starts from this point and continues for 9 minutes and 30 seconds before the user stops playing once more. Since part of the TrackD remains, the Playlist_Number and Track_Number in the PLMG_RSM_PL are left unchanged, and only Playback_Time is updated using the value "00: 20: 00,000". As described above, when the instant memory card is removed from the personal computer 200 and loaded into a portable playback apparatus 100, playback starts from a point immediately after the point where playback was stopped by the personal computer 200 In the same way, when the instant memory card is removed from the portable playback apparatus 100 and loaded into a player 300 in a vehicle, playback starts from a point immediately after the point where playback was stopped by the device. 100 of portable reproduction. This means that the instant memory card can be transferred from the personal computer 200 to the portable playback apparatus 100 and then to a 300 player in a vehicle without having to reproduce the same data twice. . { 70-5} Updating PLMG_AP_PL and PLMG_RSM_PL When Editing TKI No additional explanation of PLMG_AP_PL and PLMG_RSM_PL is provided. Instead, the following will describe how the contents of PLMG_AP_PL and PLMG_RSM_PL are updated for four editing operations described in the first mode. These are case 1 where a track is deleted, case 3 where two tracks are combined, case 4 where a track is divided into 2 and case 5 where the playing order of the tracks is rearranged.

When in case 1, the track specified by PLMG_AP_PL and PLMG_RSM_PL is deleted, the Track_Number given in PLMG_AP_PL and PLMG_RSM_PL in the PlaylistManager is set to indicate that the track that follows is a track deleted in the indicated playlist. The Playback_Time in PLMG_RSM_PL is also set to "00: 00: 00,000" to indicate the start of this next track. When in case 3, the track specified by the PLMG_AP_PL and PLMG_RSM_PL is combined with another track, the Track_Number given in the PLMG_AP_PL and PLMG_RSM_PL in the PlaylistManager is set to indicate the position of the combined track in Playlist indicated. When it is in case 4, the track specified by PLMG_AP_PL and PLMG_RSM_PL is split, the Track_Number provided in PLMG_AP_PL and PLMG_RSM_PL and in the PlaylistManager is set to indicate the position of the front or back of the track divided into the indicated playlist. The Playback_Time is compared to the division limit and when the Playback_Time is before the division limit, the Track_Number of the track that corresponds to the previous part of the split track is set to PLMG_PL. When Playback Time is after the division limit, the Track_Number of the track that corresponds to the back of the split track is set to PLMG RMS PL.

When in case 5, the position of the track indicated by PLMG_AP_PL and PLMG_RSM_PL in the indicated Playlist is changed, the Track_Number given in the PLMG_AP_PL and PLMG_RSM_PL is set so as to indicate the new position of the track in the indicated Playlist. Although the above explanation states that PLMG_AP_PL and PLMG_RSM_PL are updated when the tracks are edited, the PLMG_AP_PL and PLMG_RSM_PL settings can be cleared only when a track edit is performed. . { 72-1} Establishment of how PLMG_RSM_PL and PLMG AP PL are used The following describes the reproduction apparatus of this second embodiment. This reproduction apparatus has three main differences with the reproduction apparatus described in the first embodiment. A first difference is that the reproduction apparatus receives the PLMG_AP_PL setting and the initial user settings. Figure 2 shows the menu screen used to receive a user input from the PLMG_AP_PL and the initial settings. As shown in Figure 72, by selecting one of the sequenced sequences of character "resume from previous position" (resume playback from the previous position) or "start with favorite track", the user can have a playback device that gains reference to either the PLMG_AP_PL or PLMG_RSM_PL when the instant memory card is loaded. In this example, the "favorite track" of the user is the track specified by the Playlist_Number and Track_Number that are provided in the PLMG_AP_PL. When the user selects one of these ordered sequences of characters, the reproduction apparatus establishes an appropriate flag. This flag (called the "activation flag") shows whether the player should start from Playlist_Number and Track_Number in the PLMG_AP_PL or from the Playlist_Number, Track_Number and Playback_Time provided in the PLMG_RSM_PL. When the user selects "resume playback from previous position", the activation flag is set to "on" (activated) so that when the instant memory card is loaded, the playback device will be activated. refers to the PLMG_RSM_PL and begins the reproduction of the data from the point where playback was previously stopped. When the user selects "star with favorite track", the activation flag is set to "off" (inactivated) so that when an instant memory card is loaded, the playback device starts playing. with the track indicated in the PLMG_AP_PL. The menu screen shown in figure 72 also allows the user to set their favorite track. When the user performs an introduction operation using a keyboard panel, the PLMG_AP_PL on the instant memory card is written so that it shows the indicated playlist and track. Note that the trigger flag can be set in other ways, for example by deep switching or a push button switch that is provided in the player apparatus. . { 56_57_58-l} Update of the PLMG_RSM_PL.

A second difference with the first mode is that when the user presses the "Stop" button, the reproduction apparatus of the second mode updates the establishment of the PLMG_RSM_PL. In the first embodiment, a "Stop" button pressure in any of the flowcharts in Figures 56, 57 and 58 results in a "Yes" judgment being provided in Step S31, Step S42 or Step S54 and the processing in the following flowchart finishes. In the second mode, however, the playback apparatus will then set values in the PLMG_RSM_PL. In more detail, the playback device specifies the Playlist_Number of the playlist that is currently used for playback and the Track_Number that corresponds to the AOB that is currently playing and writes this in the PLMG_RSM_PL. The playback apparatus also refers to the value of the Play_Time variable (which was described in the first mode) at the point where the production stopped and sets this value in the PLMG_RSM_PL as the Playback_Time. In addition, when the "Stop" button is pressed, the playback device can also update the settings in the PLMG_RSM_PL when the user presses the "Pause" button. The playback device can also update the settings of Playlist_Number, Track_Number and Playback_Time in the PLMG_RSM_PL when the remaining power in the batteries is low. As a result, valid information can be established in the PLMG_RSM_PL for the case in which the playback is stopped not because the user has pressed the "Stop" button, but because the batteries of the playback device have run out. . { 73-1} Procedure to Specify Play Position The following describes the third difference with the first modality. In the first mode, AOB files are played in the order in which they were specified by a playlist. In this second embodiment, however, a reproduction is made from the reproduction position determined in accordance with the procedure shown in Figure 73. The following describes the reproduction position determination procedure based on the PLMG_AP_PL and PLMG_RSM_PL. This description refers to the flowchart in Figure 73. Once the processing in this flowchart is activated, in Step S301 the CPU refers to the activation flag that is established using the menu screen in the figure 72 and determines which of the PLMG_AP_PL and PLMG_RSM_PL should be referenced when the instant memory card is loaded. When the activation flag indicates PLMG_AP_PL, processing proceeds from step S301 to step S302. In step S302, the CPU 10 refers to the PLMG_AP_PL and specifies the TKI of the track specified by the Track_Number in the Playlist specified by the Playlist_Number as the TKI # z that was described in the first mode. CPU 10 then starts playing the #x AOB file corresponding to TKI #z. When the activation flag indicates that PLMG_RSM_PL should be prioritized, processing proceeds from step S301 to step S303. In step S303, the CPU 10 reads the PLMG_RSM_PL from the PlaylistManager_Inf ormation and in step S304, the CPU 10 judges whether the Playlist_Number, Track_Number and Playback_Time written in the PLMG_RSM_PL are valid. When the PLMG_RSM_PL has not been properly established, the last playing time is stopped, or when there is an error during group reading indicated by the PLMG_RSM_PL, the CPU 10 will judge that the PLMG_RSM_PL is not valid. The processing will then proceed from step S304 to step S302 where the CPU 10 starts playback based on the PLMG_AP_PL. When the Playl is t_Number is valid, Track_Number and Playback_Time in PLMG_RSM_PL processing proceeds from step S304 to step S305 where CPU 10 judges whether the value of Playback_Time provided in PLMG_RSM_PL is the same as the playback period (TKI_PB_TM) of the track indicated by Track_Number written in the PLMG_RSM_PL. If these two values are not equal, part of the track indicated by the Track_Number has not yet been reproduced, so that in the step S306 the CPU specifies the TKI indicated by the Track_Number in the PLMG_RSM_PL as the TKI # z, and in the step S307, the CPU 10 specifies the AOB_FRAME # x and AOB_ELEMENT # and from where the reproduction should begin within the AOB file corresponding to this TKI, based on the Playback_Time given in the PLMG_RSM_PL. The procedure for specifying the AOB_ELEMENT # y and AOB_FRAME # x that correspond to any particular playback start time within a track is described in the first mode using equations 1 to 3. CPU 10 uses these equations to calculate the AOB_ELEMENT # yy AOB_FRAME # x and then in step S308 start playback from the AOB_FRAME # x in the AOB_ELEMENT # and in the AOB file #z. When the Playback_Time value is equal to the value of TKI_PB_TM, a "Yes" judgment is provided in step S305 and the processing proceeds to step S309. The CPU 10 then judges whether the Track_Number in the PLMG_RSM_PL is equal to the TKI_Ns provided in the PlaylistManager. Otherwise, this means that at least one track must still be reproduced in the playlist specified by the Playlist_Number, so that processing proceeds from step S309 to step S311. In step S311, the TKI subsequent to the TKI specified by the Track_Number in the PLMG_RSM_PL is specified as the TKI # zy, in the step S312, the CPU 10 starts playing the AOB from the start of the #z AOB file corresponding to the TKI #z. When the TKI_PB_TM is equal to the Playback_Time and the Track_Number provided in the PLMG_RSM_PL is equal to the TKI_Ns, it can be assumed that the playlist indicated by the Playlist_Number in the PLMG_RSM_PL will have been reproduced in its entirety, so that the playback device will then receive an entry of the next playlist to be played.

With the present embodiment, PLMG_RSM_PL is recorded in the semiconductor memory card as the reproduction resume position. This information shows how much it has come from the previous reproduction of the semiconductor memory card, so that when the semiconductor memory card is removed from the reproduction apparatus and loaded into another reproduction apparatus, this second reproduction apparatus can begin playback at a point immediately following the point where playback ended by the first reproduction apparatus As a result, when a user listens to a part of a music album made up of TrackA to TrackE on the first playback device, it stops the playback. After the playback and then the album is played on a different playback device, this second playback device can reference the PLMG_RSM_PL which shows the point where the previous playback was stopped and in this way knows that part of the album has already been reproduced with a millisecond precision. Therefore, the reproduction apparatus can resume playback from a point immediately after the point where playback was stopped. This means that the user does not need to hear the same tracks, even when the semiconductor memory card is transferred from one player to another.

THIRD MODALITY { 74-1} DPLI_RMS_PL, PLI_RSM_PL In this third mode, the DPLI in each PLI is each provided with its own reproduction resume information, DPLI_RMS_PL or PLI_RSM_PL, to show where the previous reproduction in the playlist ended. Figure 74 shows the Default_Playlist_Information that has a DPLI_RMS_PL in the DPLGI and a PLI that has a DPLI_RMS_PL in the PLGI. The DPLI_RMS_PL (PLI_RSM_PL) include only a Track_Number and Playback_Time, and thus differ from the PLMG_RMS_PL in that the Playlist_Number is not necessary. As another difference, when the totality of tracks in the order of reproduction indicated by the DPLI or a PLI have been fully reproduced, an "FF" value is set in the Track_Number in the DPLI_RMS_PL (PLI_RSM_PL) to show that the playlist has been reproduced completely. The following describes the reproduction apparatus of the third mode. When the reproduction of the specified tracks in the order of reproduction of a PLI halts, the playback apparatus writes the Playlist_Number of the PLI, the Track_Number of the current track and the Playback_Time within the PLMG_RMS_PL in the same way as in the second mode.

However, as a difference, the player also writes the Track_Number and the Playback_Time within the PLI_RMS_PL that corresponds to that Playlist_Number. In the same way as in the first mode, the user can indicate a Playlist to be reproduced. However, in this third embodiment, the reproduction apparatus will reference the PLI_RMS_PL of the PLI by the indicated Playlist. When values are not provided in the Track_Number or Playback__Time in the PLI_RMS_PL of the playlist, the player starts playback from the beginning of the first track in the playback order provided in the PLI. Conversely, when values are provided in the Track_Number and in the Plackback_Time in that PLI_RMS_PL, the playback apparatus plays the tracks in the playback order that is provided in that PLI from the position indicated by the TrackJSTumber and the Playback_Time. . { 74-2_75_76} Figure 75 shows how the DPLI_RSM_PL of the DPLI and the PLI_RMS_PL of several PLIs are set. Figure 76 shows a track sequence consisting of the reproduction order specified by the playlist shown in Figure 41 to which reference is made in the first mode.

The track sequences are specified separately by the DPLI, PLI # 1 and PLI # 2, with the reproduction intervals (1) to (3) in Figure 76 showing the parts of these track sequences that have already been reproduced before. The following describes the time when playback will begin when one of the DPLI, PLI # 1 or PLI # 2 is indicated for playback with the playback intervals (1) to (3) that have already been played. . { 74-3_75_76} The playback of the sequence of tracks indicated by the DPLI is done previously until a midpoint through TrackC, so that the DPLI_RMS_PL in the DPLI, "TrackC" and "00: 03: 31.00004" are set in the Track_Number and Playback_Time to show the playback resume position (4) at the end of the playback interval (1). The playback of the track sequence indicated by PLI # 1 is previously made to the end, so that the PLI_RMS_PL of PLI # 1, "FF" is set to Track_Number. The playback of the track sequence indicated by PLI # 2 is previously made up to a midpoint through TrackA, so that in the PLI_RMS_PL of PLI # 2, "TrackA" and "00: 01: 11.00000" are set in the Track_Number and Playback Time to show the playback resume position (5) at the end of the playback interval (2). Since PLI # 3 has yet to be indicated and its track sequence has not yet been reproduced, a value of "00" is set in Track_Number in PLI_RMS_PL of PLI # 3. Since the PLI_RMS_PL (DPLI_RSM_PL) of each PLI (and the DPLI) are set as shown in Figure 75, if the user indicates the DPLI after indicating PLI # 1, the track sequence indicated by the DPLI from the position (4) of resumption of reproduction immediately after the interval (1) of reproduction. If the user indicates PLI # 2 once the track sequence indicated by the DPI has been fully reproduced, the playback of the track sequence indicated by PLI # 2 will resume from position (5) of resume playback immediately after the reproduction interval (2). With this mode, when a playlist is indicated for playback by a user operation, the playback apparatus will reference the PLI_RMS_PL (DPLI_RMS_PL) for the indicated playlist and resume the playback of the track sequence specified by that playlist according to the Track_Number and Playback_Time provided in that PLI_RMS_PL (DPLI_RSM_PL). This means that you can resume playback for any of the playlists without repeating tracks that have already been played previously. Note that since the resumption of playback for each playlist is performed in this mode according to the Track_Number and Playback_Time in the PLI_RMS_PL (DPLI_RSM_PL), it is preferable for the user to indicate the playlist to be made through a menu such as shown in figure 77 instead of by means of a menu of the first mode as shown in figure 49 which only provides a list of the playlists. Figure 77 shows an example of a menu that displays the playlist along with the PLI_RMS_PL settings for each playlist, for the case in which the reproduction intervals (1) to (3) shown in figure 76 have already been reproduced. PLIs that do not yet have their track sequences reproduced in full are displayed with a track number that shows the Track_Number in the PLI_RMS_PL and a playing time based on the Playback_Time value in the PLI_RMS_PL. Conversely, the PLIs that have their track sequences reproduced in their entirety have the value "FF" set in the Track_Number in the PLI_RMS_PL and thus are displayed with an indication that their reproduction is complete. As a result, this menu notifies the user how much of a playlist has been reproduced, so that the user can now know which playlists have been reproduced completely and which playlists have been reproduced only partially.

FOURTH MODALITY Although music applications are stored in the instant memory card 31 in the first to third modes, the present embodiment relates to an improvement in the storage of short-term applications. Here, a "short-term application" refers to any application such as news, some audio magazines, the speech record, etc., that only needs to be listened to once, and in this way differs from the music applications that are listened to repeatedly. As conventional examples of short-term applications, journals tend to be published weekly or monthly while newspapers tend to be published every day. When a recording device downloads a short-term application via a network, the recording apparatus records the audio data constituting the short-term application on the instant memory card 31 as AOB, generates a plurality of TKI for the AOBs, and stores these TKIs in the instant memory card 31. The recording apparatus also generates Playlist_Information which specifies the TKI (s) for this short duration application and registers the PLI on the instant memory card 31. The following describes the improvements in the DPLI, the PLI and the TKI made in this fourth mode. In the second mode, the PLI_APP_ATR is provided in the PlaylistManager as information that shows the attributes of an application. In the fourth mode, PLI_APP_ATR and TKI_APP_ATR are also provided as the application attributes in the DPLGI, PLGI and TKGI. Figure 78 shows the data format of DPLGI, PLGI and TKGI in this fourth mode. Like "PLMG_APP_ATR" in the second mode, the PLI_APP_ATR in a PLGI includes an application category ID that shows the category to which the PLI belongs. When the genre of an application corresponds to a PLI is music as in the first modality, in this field an "Olh" value is set. In the same way, a value of "02h" is established in this field when the application corresponds to a PLI that is karaoke software, the value "03h" when the application is presentation data and the value "04h" when the application It is an audiobook. You can also use other values to indicate other types of application. In the PLI for a short-term application, the PLI_APP_ATR in the PLGI is set to "04h" to indicate an audiobook.

A recording device generates a PLI for a fourth-term application in this manner and stores this PLI on a flash memory card 31 so that it can be associated with the short-term application. The following describes the problems that occur when short-term applications are stored on a flash memory card 31. When a short news application is used for news, only the most recent application is sent to the recording device every day. If the recording apparatus cumulatively stores the news of each day on an instant memory card 31, the limited storage capacity of the instant memory card 31 will soon be occupied by such short-lived applications. To prevent short-term applications from taking up too much space on the instant memory card 31, the recording apparatus must reference the PLI_RSM_PL and PLI_APP_ATR and perform the operations described below. Since the short-term applications are stored in the flash memory card 31 together with the PLIs where the PLI_APP_ATR is set to indicate an audiobook, a recording apparatus can determine which PLI, TKI and AOB correspond to the short-term applications when referring to the PLA APP ATR.

In the PLI for a short-term application, a value of "FF" is set in the PLI_RSM_PL if all the tracks in the indicated playback order have been fully played or if a different value has not been completed in the playback of the tracks in the indicated playback order. As a result, a recording device can now know if a short-term application has been reproduced in its entirety simply by referring to the Track srumber in the PLI_RSM_PL. After checking the TrackJTumber in this manner, the recording device can suppress the TKI, OAOB and PLI for short-term applications that have been reproduced in their entirety. This stops the storage capacity of the instant memory card 31 from being overloaded by the accumulation of a large number of applications of short duration. Note that although the above example refers to the case in which the recording apparatus refers to the PLI_RMS_PL and PLI_APP_ATR, ase can perform the same control for the DPLI_RMS_PL and DPLI_APP_ATR. With this modality, short-term applications such as news can be downloaded and stored on an instant memory card 31. Such short-term applications can be suppressed when starting with applications that have been fully reproduced, so that even when short-term applications such as news occur every day, such short-term applications can be prevented from occupying the entire of the storage capacity of the instant memory card 31. Although the present invention has been fully described by way of example with reference to the accompanying drawings, it should be noted that various changes and modifications will be apparent to those skilled in the art. Therefore, unless such changes and modifications depart from the scope of the present invention, they should be considered as included herein.

INDUSTRIAL APPLICABILITY The semiconductor memory card of the present invention is especially suitable for use in the consumer electronics field as a recording medium for recording music or other material distributed electronically or in some other way. The recording and reproducing apparatus of the present invention allows consumers to make full use of this semiconductor memory card. It is noted that in relation to this date, the best method known to the applicant to carry out the aforementioned invention, is the one that is clear from the present invention of the invention.

Claims (23)

CLAIMS Having described the invention as above, the content of the following claims is claimed as property:

1. A semiconductor memory card, which stores: an audio sequence in which a plurality of audio objects are placed, and • resume information showing a resume position for use when the reproduction of the audio sequence is resumed in the middle part through the audio sequence.

2. A semiconductor memory card, according to claim 1, characterized in that the resume information includes at least one of position information type 1 and position information type 2, the position information type 1 shows a resumption position type 1 set according to a user operation, and position information type 2 shows a type 2 resume position which is set automatically when the reproduction of the last audio sequences has stopped.

3. A semiconductor memory card, according to claim 2, characterized in that each audio object in the audio sequence has been provided with unique identification information, the position information type 1 shows the position of resumption type 1 using the information of identification of one of the audio objects, and the position information type 2 shows the position of resumption type 2 using the identification information of one of the audio objects and the time information showing a deviation from the start of one of the audio objects. the audio objects to the resume position type 2.

4. A semiconductor memory card, according to claim 3, further characterized in that it stores: at least one piece of reproduction path information, each of which defines a reproduction path by including identification information of at least an audio object and a reproduction position of each of at least one audio object in the reproduction path; the resume information further includes specifying information that specifies a piece of playback path information, position information type 1 and position information type 2 respectively show the resume position type 1 and the resume position type 2 for the sequence audio using the identification information of an audio object in the specified piece of playback path information.

5. A semiconductor memory card, according to claim 4, characterized in that it also stores a piece of supplementary resume information corresponding to each piece of playback path information, each piece of supplementary resume information includes position information showing a position in an audio object from which playback should start when the audio objects are to be reproduced according to the corresponding piece of playback path information, the position information in the resume information shows, as the resume position, a position and an audio object that is indicated on one of the pieces of supplementary resume information.

6. A semiconductor memory card, according to claim 5, characterized in that a first value is established on each piece of supplementary resumption information when the reproduction is complete for all the audio objects whose identification information is indicated by the corresponding piece of information. the reproduction path information, and a second value is set on each piece of the supplementary resume information when the reproduction is not complete for all the audio objects whose identification information is indicated by the corresponding piece of reproduction path information .

7. A reproduction apparatus for a semiconductor memory card that stores (1) an audio sequence in which a plurality of audio objects are placed, and (2) resume information showing a resume position for use when the reproduction of the audio sequence is resumed in half through the audio sequence, the reproduction apparatus is characterized in that it comprises: a receiving means capable of receiving, from the user, a first reproduction operation specifying one of the audio objects, and a second reproduction operation that does not specify any of the audio objects; and a reproduction means for reproducing the specified audio object when the receiving means has received the first playback operation, and for reading the resume information from the semiconductor memory card and reproducing the audio sequence from the position of resumption shown by the resume information when the receiving means has received the second playback operation.

8. The reproduction apparatus, according to claim 7, characterized in that the resume information shows the resume position using identification information for one of the audio objects in the audio sequence and time information showing a deviation from the start from one of the audio objects to the resume position, and when the receiving means has received the second playback operation, the playback medium begins to reproduce the audio sequence from a mid-point, which is indicated by the time, in the audio object indicated by the identification information that is provided in the resume information.

9. The reproduction apparatus for a semiconductor memory card that stores (1) an audio sequence that includes a plurality of audio objects, and (2) resume information showing a resume position that has been specified by a user operation , the reproduction apparatus is characterized in that it comprises: a charging means for charging the semiconductor memory card; a means of judgment for judging whether the second resume information has been correctly written to the semiconductor memory card loaded by the loading medium, the second resume information shows a resume position and is automatically set when playback is stopped; and a reproduction means for reproducing the audio sequence according to the second resume information when the second resume information has been correctly written on the semiconductor memory card, and for reading the first resume information from the second card. semiconductor memory and reproduce the audio sequence according to the first resume information, when the second resume information has not been written correctly on the semiconductor memory card.

10. The reproduction apparatus, according to claim 9, further comprising a storage means for storing a flag indicating which of the first resume information and the second resume information should be used for reproduction, where, when the flag indicates the first resume information, the playback means plays the audio sequence according to the first resume information regardless of whether the second resume information has been written correctly on the semiconductor memory card.

11. The reproduction apparatus according to claim 10, characterized in that it further comprises: a receiving means for receiving, from a user, an operation indicating which of the first resume information and the second resume information should be used; and a means of establishing the flag in the storage medium according to the operation received by the receiving means.

12. A recording device for a semiconductor memory card, characterized in that it comprises: a receiving means for receiving an operation performed by a user; a reproduction means for reproducing audio objects included in an audio sequence when the operation received is a reproduction operation, and a recording means for specifying, when the operation received is a stopping operation, a resumption position starting from from a playback position when the user performs the stop operation, the resume position shows the point at which the audio sequence should be resumed, and to record resume information showing the resume position on the card of semiconductor memory.

13. A computer readable storage medium that stores a program that has a computer that executes a reproduction procedure for a semiconductor memory card, the semiconductor memory card stores (1) an audio sequence in which a plurality of objects are placed. of audio, and (2) resume information showing a resume position for use when the reproduction of the audio sequence resumes from the middle part through the audio sequence, the program is characterized in that it comprises: a reception stage capable of receiving, from a user, a first reproduction operation specifying one of the audio objects, and a second reproduction operation that does not specify any of the audio objects; and a reproduction step for reproducing the specified audio object when the receiving stage has received the first playback operation, and for reading the resume information of the semiconductor memory card and playing the audio sequence from the resume position shown by the resume information when the receiving stage has received the second playback operation.

14. The computer readable storage medium, according to claim 13, characterized in that the resume information shows the resume position using identification information for one of the audio objects in the audio sequence and time information showing a deviation from the start of one of the audio objects to the resume position, and when the receiving stage has received the second playback operation, the playback stage begins playback of the audio sequence from the mid-point, which is indicated by the time information, in the audio object indicated by the identification information that is provided in the resume information.

15. A computer readable storage medium that stores a program that has a computer that executes a reproduction procedure for a semiconductor memory card, the semiconductor memory card stores (1) an audio sequence in which a plurality of objects are placed. of audio, and (2) resume information showing a resume position for use when the reproduction of the audio sequence resumes from the middle part through the audio sequence, the program is characterized in that it comprises: a loading step to load the semiconductor memory card; a judgment step for judging whether the second resume information has been correctly written on the semiconductor memory card loaded by the loading stage, the second resume information shows a resume position and is automatically set when playback is stopped; and a reproduction step for reproducing the audio sequence according to the second resume information when the second resume information has been correctly written on the semiconductor memory card, and for reading the first resume information from the second card. semiconductor memory and play the audio sequence according to the first resume information when the second resume information has not been written correctly on the semiconductor memory card.

16. The computer readable storage medium, according to claim 15, characterized in that the computer includes a storage means for storing a flag indicating which of the first resume information and the second resume information can be used for reproduction, in that the flag indicates the first resume information, the playback stage plays the audio sequence according to the first resume information regardless of whether the second resume information has been correctly written on the semiconductor memory card.

17. The computer readable storage medium, according to claim 16, characterized in that the program further comprises: a receiving step for receiving, from a user, an operation indicating which of the first resume information and the second resume information it must be used; and an establishment step for setting the flag on the storage medium according to the operation received by the reception stage.

18. A computer readable storage medium that stores a program that has a computer that executes a recording procedure for a semiconductor memory card, the program is characterized in that it comprises: a receiving stage for receiving an operation performed by a user; a reproduction stage for reproducing audio objects included in an audio sequence when the operation received is a reproduction operation; and a recording step for specifying, when the received operation is a stopping operation, a resumption position from a reproduction poem where the user performs the detecting operation, the resumption position shows the time at which it is detected. you must resume playback of the audio stream, and to record resume information that shows the resume position on the semiconductor memory card.

19. A reproduction method for a semiconductor memory card that stores (1) an audio sequence in which a plurality of audio objects are placed, and (2) resume information showing a resume position for use when the reproduction of the audio sequence is resumed in the middle part through the audio sequence, the reproduction method is characterized in that it comprises - a receiving stage capable of receiving, from a user, a first reproduction operation specifying one of the objects of audio, and a second reproduction operation that does not specify any of the audio objects, - and a reproduction step for reproducing the specified audio object when the receiving means has received the first reproduction operation, and for reading the information of resumption from the semiconductor memory card and playing the audio sequence from the resume position shows gives the resume information when the receiving means has received the second reproduction operation.

20. The method of reproduction, according to claim 19, characterized in that the resume information shows the resume position using identification information for one of the audio objects in the audio sequence, and time information showing a deviation from the start of one of the audio objects to the resume position, and when the receiving stage has received the second playback operation, the reproduction stage begins to reproduce the audio sequence from a mid-point, which is indicated by the information time, in the audio object indicated by the identification information that is provided in the resume information.

21. A reproduction method for a reproduction apparatus using a semiconductor memory card that stores (1) an audio sequence that includes a plurality of audio objects, and (2) resume information showing a resumption position that has been specified by a user operation, the reproduction method is characterized in that it comprises: a charging step for charging the memory card eemicondutora, - a stage of judgment to judge whether the second resume information has been correctly written to the semiconductor memory card loaded by the loading stage, the second resume information shows a resume position and is automatically set when playback is stopped; and a reproduction step for reproducing the audio sequence according to the second resume information when the second resume information has been correctly written on the semiconductor memory card, and for reading the first resume information from the second card. semiconductor memory and play the audio sequence according to the first resume information when the second resume information has not been written correctly on the semiconductor memory card.

22. The method of reproduction, according to claim 21, characterized in that the reproduction apparatus includes a storage unit for storing a flag indicating which of the first resume information and the second resume information should be used for reproduction, wherein , when the flag indicates the first resume information, the playback stage plays the audio sequence according to the first resume information regardless of whether the second resume information has been correctly written on the semiconductor memory card.

23. A recording method for a semiconductor memory card, characterized in that it comprises: a receiving stage for receiving an operation performed by a user; a reproduction stage for reproducing audio objects included in an audio sequence when the operation received is a reproduction operation; and a recording step for specifying, when the received operation is a stopping operation, a resumption position from the reproducing position when the user performs the stopping operation, the resumption position shows the time at which it is due. resume playback of the audio stream, and to record resume information showing the resume position on the semiconductor memory card.