JP4469125B2 - Semiconductor memory card, editing apparatus, editing method, and computer-readable recording medium - Google Patents

Description

[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a semiconductor memory card for storing audio data, still image data, and control data, an editing apparatus, a playback method, an editing method, and a computer-readable recording medium, and in particular, in content distribution services such as electronic music distribution, The present invention relates to an improvement in storing audio data, image data, and control data distributed as.
[0002]
[Prior art]
Electronic music distribution, which enables the purchase of music content on the Internet, can be a trigger for the activation of the music market, and the infrastructure for its realization is being steadily improved. The semiconductor memory card described above is a portable recording medium suitable for storing and carrying music content purchased from electronic music distribution, and it is expected that the demand will increase dramatically in the future.
[0003]
The music content includes not only music playback but also “media mix” type music content that can display music-related images as well as music playback. “Karaoke Software” is a typical “media mix” type that records the lyrics and the background image together with karaoke music on a recording medium and displays the lyrics when the karaoke music is played. In order to consider further development of electronic music distribution in the future, it is necessary to consider the distribution and sale of media-mix type music content. Along with this, the storage method for storing “media mix” type music content on a semiconductor memory card will also need to be examined more specifically.
[0004]
Now, how a “media mix” type music content is stored in a recording medium such as a CD, that is, a conventional audio data-image data storage method in the recording medium will be described.
In order to perform music playback and image display, conventional “media mix” type music content is a recording medium in which multiplexed data obtained by multiplexing audio data about music and image data indicating lyrics and background images is recorded. Thus, the audio data is reproduced and the image data is displayed together. A recording medium which has realized image display for audio data reproduction by multiplexing includes a so-called CD-Graphics (subcode Graphics). One unit of multiplexing in this CD-Graphics consists of a 16-bit main code and a subcode. Audio data is assigned to the 16-bit main code, and image data such as lyrics and background images are assigned to the subcode. ing. When playback of any of the music content recorded on the CD-Graphics is started, the audio data assigned to the 16-bit main code is played back sequentially, and the image data assigned to the subcode is displayed sequentially. .
[0005]
[Problems to be solved by the invention]
By the way, when an attempt is made to produce a music album made up of a plurality of music contents in accordance with the above-described audio data-image data multiplexing method, images are uniformly provided for each music content. That is, since the conventional audio data-image data multiplexing method requires that at least one image be assigned to each music content, there is a problem in that the producer is troubled by the production of such an image. .
[0006]
However, for music albums of high-profile artists, consumers will welcome people who have different images for each music content, and it is expected that the sales of music albums will be enormous. And the cost is likely to be rewarded. On the other hand, with respect to music albums of artists that are not popular, even if different images are provided for each music content, the consumer's reaction will be sluggish, and it is not expected that the sales of music albums will be significant. It is likely that the cost will not be paid off.
[0007]
It is clear that the labor and expense required for image production are rewarded, but the gap between high-profile music albums and low-quality music albums is obvious, but conventional audio data-image data multiplexing methods Regardless of the name of the artist and the expected number of sales, at least one image is required to be assigned to each music content.
[0008]
An object of the present invention is to provide a semiconductor memory card that can reduce the labor of producing an image to be assigned to each music content when producing a music album composed of a plurality of music contents.
[0009]
[Means for Solving the Problems]
Here, considering the music content and the image to be displayed, it is indispensable to provide different music content lyrics for each music content, but for background images, when playing multiple music content In some cases, the background image to be displayed may be shared. For example, when multiple music contents are written, composed, or sung by the same person, the common photograph of the person is displayed as a background image when playing the multiple music contents. A method of storing audio data (audio object) and image data (still image object) to be omitted can be considered.
[0010]
In order to achieve the above object by sharing image data (still image objects) among a plurality of music contents, a semiconductor memory card according to the present invention includes a plurality of audio objects, still image objects, reproduction path information, and a first pointer. A semiconductor memory card storing information, second pointer information, and a symbolic counter, wherein the playback path information indicates the playback order of the audio objects, and the first pointer information corresponds to the playback path information, The playback order of the still picture object during the entire playback time of the audio object according to the playback path information is indicated, and the second pointer information corresponds to a specific audio object, and the playback time of the audio object during the entire playback time Indicates the playback order of still image objects and is symbolic The counter is associated with each still image object, and indicates whether or not the corresponding still image object is designated by the first pointer information or the second pointer information. The number of designations as to whether or not it is designated by the first pointer information and the second pointer information.
[0011]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, embodiments of a semiconductor memory card (flash memory card) will be described with reference to the drawings.
In addition, each subsequent sentence is given a classification number having the following system at the beginning of the sentence.
[0012]
{x1-x2_x3-x4}
The number of digits in the classification number means the hierarchical depth of the item. Specifically, x1 is a figure number cited in the description. Since the figures attached to this specification are numbered according to the order cited in the specification, the order of the figure numbers is almost the same as the order of description. x2 indicates the order of the description in the case of quoting the figure shown in x1. x3 indicates the figure number of the explanatory diagram when quoting the explanatory diagram in order to explain the constituent elements of x2 in more detail, and x4 indicates the order of description when quoting the explanatory diagram shown in x3 Indicates.
[0013]
(First embodiment)
{1-1_2} Appearance of flash memory card 31
First, the external shape of the flash memory card 31 will be described. FIG. 1 is a diagram showing a shape when the flash memory card 31 is viewed from above, and FIG. 2 is a diagram showing a structure when the flash memory card 31 is viewed from below. As shown in FIG. 1 and FIG. 2, the flash memory card 31 has a length of about 32.0 mm, a width of about 24.0 mm, and a thickness of about 2.0 mm. Size). Nine connectors for connecting to the equipment are provided on the bottom surface, and a protect switch 32 is provided on the side surface that allows the operator to set whether to overwrite or prohibit the overwriting of stored contents. It has been.
[0014]
{3-1} Physical structure of flash memory card 31
FIG. 3 is a diagram showing a hierarchical structure of a semiconductor memory card (hereinafter referred to as a flash memory card 31) according to the present embodiment. As shown in the figure, the hierarchical structure of the flash memory card 31 is the same as that of a DVD (Digital Video Disc) in that it includes a physical layer, a file system layer, and an application layer. The physical structure is very different.
[0015]
{3-2} Physical structure of flash memory card 31
First, the physical layer of the flash memory card 31 will be described. The flash memory is composed of a plurality of sectors, and each sector stores 512-byte digital data. For example, in the case of a 64 MByte type flash memory card 31, the memory capacity is 67108864 (= 64 × 1024 × 1024) bytes, and the number of valid sectors at this time is 131072 (= 67108864/512). Further, if the number of error alternative sectors is subtracted from this effective sector, the remaining effective sector number becomes 128,000, and various data are recorded here.
[0016]
{3-2_4A-1} Three regions in the physical layer
In the area composed of these effective sectors, three areas shown in FIG. 4A are provided. FIG. 4A is a diagram showing a “system area”, a “protect area”, and a “user data area” provided in the physical layer of the flash memory card 31. Hereinafter, these three areas will be described.
[0017]
The “user data area” is an area in which a device connected to the flash memory card 31 can freely write various data and can read data freely. The internal area is managed by the file system. Yes.
The “system area” is an area in which a media ID having a unique value for each flash memory card 31 is stored. While the user data area is writable, the system area is read-only, and the media ID stored here cannot be rewritten.
[0018]
The “protect area” is an area in which data can be written in the same manner as the user data area. The difference from the user data area is that data can be freely read and written in the user data area, whereas in the protected area, the device connected to the flash memory card 31 and the flash memory card 31 are mutually valid. It is possible to read / write only when the data is confirmed, that is, only when mutual authentication between the flash memory card 31 and the device connected to the flash memory card 31 is successful.
[0019]
{3-2_4A-2} Use of three areas in the physical layer
When a device connected to the flash memory card 31 writes data to the flash memory card 31, these three areas are used depending on whether or not the copyright protection of the data is necessary. Here, when data requiring copyright protection is written to the flash memory card 31, the data is encrypted using a predetermined encryption key (called FileKey) and then stored in the user data area. This FileKey can be freely set by the copyright holder, and this alone protects the copyright of the data, but for the sake of completeness, the FileKey itself used for this encryption is also encrypted. When encrypting FileKey itself, what is used as a key is an arbitrary value obtained by applying the media ID stored in the system area to a predetermined arithmetic expression, and the protected area is an arbitrary value Stores FileKey encrypted using. Data that requires copyright protection is encrypted using a predetermined FileKey, and this FileKey itself is also encrypted using a value based on the media ID. Infringement becomes extremely difficult.
[0020]
{3-2_4B-1} File system overview
The configuration of the physical layer of the flash memory card 31 is as described above, and it can be seen that the copyright protection has been improved. Next, the configuration of the file system layer existing on the physical layer will be described.
The file system layer of DVD is a UDF (universal disk format) type file system, whereas the file system layer of flash memory card 31 is a FAT type file system (FAT: File Allocation Table, ISO / IEC 9293). And this is different from DVD.
[0021]
FIG. 4B is a diagram showing the configuration of the protect area and user data area in the file system layer. In FIG. 4B, the protected area and user data area in the file system include “partition boot sector”, “file allocation table (FAT)”, “root directory entry”, and “data area”. It is also clear from this figure that both the protect area and the user data area have the same configuration. FIG. 5 shows the details of these file system configurations. Hereinafter, the configuration of the user data area will be described with reference to FIGS.
[0022]
{3-2_4B-2} Partition boot sector
The “partition boot sector” is a content that the general-purpose personal computer should refer to when the flash memory card 31 is loaded in the general-purpose personal computer and the flash memory card 31 is assigned to the boot disk of the operating system of the general-purpose personal computer. Is a sector that is described.
[0023]
{3-2_4B-3_5} Data area
The “data area” is an area accessed by a device connected to the flash memory card 31 with a cluster as a minimum unit. Since the sector size of the flash memory card 31 is 512 bytes, the cluster size is 16 Kbytes, so data is read and written using 32 sectors as a unit in the file system layer. The reason for setting the cluster size to 16 Kbytes is as follows. In other words, when data is written to the flash memory card 31, the data stored in the flash memory card 31 must be erased once and then written. In the flash memory card 31, the size at which data can be erased is 16 Kbytes. Therefore, by setting the cluster size to this erasable size, data writing is preferably performed. A dashed lead line ff2 in FIG. 5 indicates a plurality of clusters 002, 003, 004, 005... Included in the data area. In the figure, numbers 002, 003, 004, 005, 006, 007, 008,... Indicate cluster numbers in three-digit hexadecimal notation assigned to identify each cluster. Since access to the data area is performed with a cluster as a minimum unit, the internal position of the data area is designated using these cluster numbers.
[0024]
{3-2_4B-4_5} File allocation table
The “file allocation table” has a file system structure conforming to ISO / IEC 9293, and includes a plurality of FAT values. Each FAT value is associated with each cluster, and when a corresponding cluster is read, it indicates which cluster should be read next. 5 indicates a plurality of FAT values 002, 003, 004, 005,... Included in the file allocation table. The numerical value “002, 003, 004, 005...” Assigned to the FAT value indicates to which cluster each FAT value is associated, that is, the cluster number of the cluster to which each FAT value is associated.
[0025]
{3-2_4B-5_5-1} Root directory entry
The “root directory entry” is information indicating what kind of file exists in the root directory. Specifically, the root directory entry contains the “file name” of the existing file, the “extension” of the file, the “file attribute”, the “update time and date” of the file, and the file “First cluster number of file” in which the head part of the file is stored is described.
[0026]
{3-2_4B-5_5-2} Subdirectory directory entry
Information about files in the root directory is described in the root directory entry, but information about subdirectories is not described in the root directory entry. Directory entries for subdirectories are created in the data area. The SD_Audio directory entry described in the data area of FIG. 5 is an example of a directory entry for a subdirectory. Like the root directory entry, this SD_Audio directory entry is the “file name” of a file existing in the subdirectory. The “extension” of the file, “file attribute”, “update time and date” of the file, and “first cluster number of file” in which the head of the file is stored are described.
[0027]
{3-2_4B-5_6-1} AOB file storage method
Here, when a file AOB001.SA1 is stored in the SD_Audio directory, how AOB001.SA1 is stored, that is, an example of a file storage method will be described with reference to FIG. Since the minimum access unit of the data area is a cluster as described above, AOB001.SA1 must be stored in the data area with the cluster size as the minimum unit. AOB001.SA1 is first divided into cluster sizes and written to each cluster. FIG. 6 is a diagram assuming that AOB001.SA1 is divided into five according to the cluster size and each divided portion is stored in clusters 003, 004, 005, 00A, and 00C.
[0028]
{3-2_4B-5_7-1} AOB file storage method
When AOB001.SA1 is divided and stored, the directory entry and the file allocation table must be set as shown in FIG.
FIG. 7 is a diagram illustrating a setting example of the directory entry and the file allocation table when AOB001.SA1 is recorded in a plurality of clusters. In this figure, when the head part of AOB001.SA1 is recorded in the cluster 003, the “first cluster number” in the SD_Audio directory entry describes the cluster number 003 for the cluster in which the head part is stored. . Thereafter, it can be seen that the subsequent portion of AOB001.SA1 is stored in cluster 004 and cluster 005. The cluster 003 that stores the first part of AOB001.SA1 corresponds to the FAT value 003 (004). This FAT value indicates the cluster 004 that stores the subsequent part of the AOB file. It is. In addition, the FAT 004 (005) and FAT value 005 (00A) correspond to the clusters 004 and 005 that store the subsequent part. The FAT value is the next succeeding part of the AOB file. The cluster 005, 00A storing the portion to be processed is shown.
[0029]
If the cluster numbers described in these FAT values are sequentially read as indicated by arrows fk1, fk2, fk3, fk4, fk5,..., All the divided parts of AOB001.SA1 can be read. From the above description, it can be seen that the data area of the flash memory card 31 is accessed with a cluster as a minimum unit, and that each cluster is associated with a FAT value. The FAT value associated with the cluster that stores the last part of the AOB file (cluster 00C in the example of FIG. 7) has a cluster number indicating that the cluster stores the last part of the file. “FFF” is described.
[0030]
The description of the file system of the flash memory card 31 of the present invention has been completed, and then the configuration of the application layer existing on the file system described above will be described.
{3-3} Overview of application layers in flash memory card 31
The outline of the application layer in the flash memory card 31 is as described in FIG. As shown by a broken lead line PN1 in FIG. 3, the application layer in the flash memory card 31 includes presentation data and navigation data for controlling the reproduction of the presentation data.
[0031]
As indicated by the dashed lead line PN2 in the figure, the presentation data includes an audio object group (AOB group) obtained by encoding audio data such as music, and the navigation data includes a playlist manager (PlaylistManager ( PLMG)) and a track manager (TKMG).
{3-3_8A, B-1} Directory structure
FIGS. 8A and 8B show that when these two data are stored in the application layer, what directory is configured in the user data area and the protect area in the file system layer, and what file is related to It is a figure which shows whether it is created under the directory. In this figure, “SD_AUDIO.PLM” and “SD_AUDIO.TKM” are files containing navigation data such as playlist manager (PlaylistManager (PLMG)) and track manager (Track Manager (TKMG)), and “AOB001.SA1” “AOB002.SA1”, “AOB003.SA1”, “AOB004.SA1”,... Are files (hereinafter referred to as AOB files) that store audio objects that are presentation data.
[0032]
The extension “SA” in “AOB0xx.SA1” is an abbreviation for “Secure Audio”, and these stored contents indicate that there is a need for copyright protection (in FIG. 8A, AOB (Only 8 files are described, but this is just an example, and the SD_Audio directory can store up to 999 AOB files.) Thus, when there is a need to protect the copyright of the presentation data, a subdirectory named SD_Audio directory is provided in the protected area, and an encryption key storage file AOBSA1.KEY is created under the SD_Audio directory. FIG. 8B shows an encryption key storage file AOBSA1.KEY stored under SD_Audio. The encryption key storage file AOBSA1.KEY stores FileKeys # 1 to # 8, which are encryption key strings in which a plurality of encryption keys FileKey are arranged in a predetermined order.
[0033]
In electronic music distribution, the music company's server computer holds the SD_Audio directory shown in FIGS. 8A and 8B, and compresses the SD_Audio directory if a purchase request for the music content is issued from the consumer. After the encryption, the SD_Audio directory owned by the consumer who issued the purchase request is transmitted via the public network. When the computer owned by the consumer receives this SD_Audio directory, it decrypts this directory and decompresses it to obtain the SD_Audio directory (note that the public network here is a wired communication network such as an ISDN line, (Including all networks that are open to the public, such as wireless communication networks such as mobile phones). Note that the AOB file may be downloaded from the server computer of the music company, and the computer owned by the consumer may create the SD_Audio directory shown in FIGS. 8A and 8B in the flash memory card 31.
[0034]
{3-3_9-1} Correspondence between AOBSA1.KEY and AOB file
FIG. 9 is a diagram illustrating the correspondence between AOBSA1.KEY under SD_Audio and the AOB file. In this figure, the FileKey used when encrypting the encrypted file in the user data area is stored in the encryption key storage file corresponding to the protected area.
[0035]
The encrypted AOB file and the encryption key storage file have a correspondence relationship based on the following certain rules (1), (2), and (3).
(1) The encryption key storage file is placed in the same directory name as the directory in which the encrypted file is stored. Since the AOB file is arranged in the SD_Audio directory in the user data area of FIG. 9 and the encryption key storage file is also arranged in the SD_Audio directory, it is understood that the file arrangement is performed according to this rule. .
[0036]
(2) The encryption key storage file is given a file name combining the first three characters of the file name of the AOB file in the data area and a predetermined extension “.key”. When the file name of the AOB file is “AOB001.SA1,” the first three characters “AOB”, “SA1”, and the extension “.key” are included in the encryption key storage file as shown by arrows nk1 and nk2. It can be seen that the file name “AOBSA1.KEY” is added.
[0037]
(3) The file name of the AOB file is given a serial number that indicates the position of the Filekey corresponding to the audio object in the encryption key string in the encryption key storage file, that is, the order of the corresponding FileKey. Is done.
“File Key Entry # 1, # 2, # 3... # 8” in the encryption key storage file in FIG. 9 indicates the start position of the area where each FileKey is stored in the encryption key storage file. . On the other hand, serial numbers such as “001”, “002”, “003”, and “004” are given to the file name of the AOB file. Since the serial numbers in these AOB files mean the position of the corresponding FileKey in the encryption key string, the FileKey used to encrypt each AOB file has the same serial number. File Key Entry ”. Arrows AK1, AK2, and AK3 in FIG. 9 indicate the correspondence between the AOB file and FileKey. That is, AOB001.SA1 in the user data area corresponds to the FileKey stored in `` File Key Entry # 1 '', and AOB002.SA1 is the FileKey, AOB003. SA1 indicates that it corresponds to the FileKey stored after “File Key Entry # 3”. As can be seen from (3) above, the FileKey used to encrypt the AOB file is different for each file, and they are "001", "002", "embedded in the file name. It is stored in “File Key Entry” having the same serial number as 003 ”and“ 004 ”. Since each AOB file is encrypted using a different FileKey, even if the encryption key of a specific AOB file is exposed, other AOB files can be decrypted using the exposed FileKey. I can't do it. This minimizes the damage if the FileKey is exposed when the AOB file is encrypted.
[0038]
{3-3_10-1} AOB file internal structure
Next, the internal structure of the AOB file will be described. FIG. 10 is a diagram hierarchically showing the data structure of the AOB file. The first level in the figure shows an AOB file, and the second level shows an AOB. The third level indicates AOB_BLOCK, the fourth level indicates AOB_ELEMENT, and the fifth level indicates AOB_FRAME.
[0039]
“AOB_FRAME” in the fifth row in FIG. 10 is a minimum unit constituting the AOB, and includes an ADTS header and audio data in an ADTS (Audio Data Transport Stream) format. Audio data in ADTS format is stream data that is encoded with MPEG2-AAC [Low Complexity Profile] and played back at a transmission speed of 16 Kbps to 144 Kbps (in addition, transmission of PCM data recorded on an existing compact disc) Since the speed is 1.5Mbps, it can be seen that it is much lower than the PCM data.) The data structure of these AOB_FRAME sequences is the same as the audio frame sequence included in the audio data transport distributed by electronic music distribution. That is, an audio data transport stream to be stored as an AOB_FRAME sequence is encoded by MPEG2-ACC, and further encrypted, transmitted through a public network and transmitted to a consumer. The AOB file stores the audio data transport stream thus transmitted divided as an AOB_FRAME sequence.
[0040]
{3-3_10-1_11} About MPEG2-AAC
For details on MPEG2-AAC, refer to ISO / IEC 13818-7: 1997 (E) Information technology-Generic coding of moving pictures and associated audio information-Part 7 Advanced Audio Coding (AAC). It should be noted here that AOB is compressed by the MPEG2-AAC method applied by limiting the parameter table described in ISO / IEC13818-7 as shown in FIG. . FIG. 11A is a diagram showing a parameter table described in ISO / IEC13818-7, and includes a Parameter column, a Value column, and a comment column indicating the contents of the Comment column.
[0041]
The parameter column “profile” indicates that the restriction of LC-profile specified in ISO / IEC 13838-7 is applied.
The parameter column “sampling_frequency # index” indicates that sampling frequencies such as “48 kHz, 44.1 kHz, 32 kHz, 24 kHz, 22.05 kHz, 16 kHz” are applied. The parameter column “number_of_data_block_in_frame” indicates that 1header / 1raw_data_block is set.
[0042]
Although AOB_FRAME has been described as being encoded in the MPEG-AAC format, AOB_FRAME is in MPEG-Layer3 (MP3) format, Windows (registered trademark) Media Audio (in other encoding formats such as WMA format). In this case, the parameter tables shown in FIGS. 11B and 11C must be used instead of the parameters shown in FIG.
[0043]
{3-3_10-2_12} Configuration of AOB_FRAME
“AOB_FRAME” includes audio data encoded under the above restrictions, but the data length of the audio data included in AOB_FRAME is only data whose reproduction time is 20 milliseconds. However, since the MPEG2-AAC system is a variable length encoding system, the data length of audio data included in each AOB_FRAME is different for each AOB_FRAME. Hereinafter, the details of the configuration of AOB_FRAME will be described with reference to FIG. The first level of the figure shows the overall configuration of AOB_FRAME, and the second level shows how each part of AOB_FRAME is encrypted. Referring to the second row, it can be seen that the ADTS header is not encrypted, that is, not encrypted. The audio data includes both an encrypted part and an unencrypted part. The encrypted part is a plurality of 8-byte encrypted data. The 8-byte encrypted data is generated by encrypting 64-bit original data using a 56-bit FileKey. The non-encrypted part is left unencrypted because it is less than 64 bits when encrypted in 64-bit units.
[0044]
The third level shows the contents of the ADTS header which is a non-encrypted part. The ADTS header is 7 bytes, and describes the 12-bit synchronization word (set as FFF), the data length of the audio data contained in the same AOB_FRAME, and the sampling frequency when encoding the audio data Yes.
{3-3_10-3_13} AOB_FRAME byte length setting
FIG. 13 is a diagram illustrating how the byte length of audio data in each AOB_FRAME is set in three AOB_FRAMEs. In this figure, the data length of audio data # 1 included in AOB_FRAME # 1 is x1, the data length of audio data # 2 included in AOB_FRAME # 2 is x2, and the data length of audio data # 3 included in AOB_FRAME # 3 is When the data lengths are different from each other, such as x1, x2, and x3, the ADTS header included in AOB_FRAME # 1 describes the data length x1, and the ADTS header included in AOB_FRAME # 2 The data length x3 is described in the ADTS header included in the data length x2 and AOB_FRAME # 3. The audio data itself is encrypted, but the ADTS header itself is not encrypted, so if you read the data length of the audio data from the ADTS header in each AOB_FRAME, you can see where the following AOB_FRAME exists. You can know. This completes the description of AOB_FRAME.
[0045]
About {3-3_10-4} AOB_ELEMENT
Next, AOB_ELEMENT located at the fourth level in FIG. 10 will be described.
“AOB_ELEMENT” is a set of a plurality of continuous AOB_FRAMEs. Here, how many AOB_FRAMEs are included in AOB_ELEMENT changes according to the setting of sampling_frequency_index shown in FIG. 11A and the encoding method. That is, the number of AOB_FRAME included in AOB_ELEMENT is determined so that the playback time of AOB_FRAME included in the AOB_ELEMENT is approximately 2 seconds, and is different depending on the sampling frequency and the encoding method.
[0046]
{3-3_10-5_14} AOB_FRAME included in AOB_ELEMENT
FIG. 14 is a diagram illustrating a correspondence between sampling_frequency and the number of AOB_FRAME included in AOB_ELEMENT. In this figure, N indicates the playback period of AOB_ELEMENT in seconds, and is “2” if the encoding method is MPEG-AAC. When sampling_frequency is 48 kHz, the number of frames included in AOB_ELEMENT is 94 (= 47 × 2), and when sampling_frequency is 44.1 kHz, the number of frames included in AOB_ELEMENT is 86 (= 43 × 2), When sampling_frequency is 32 kHz, the number of frames included in AOB_ELEMENT is 64 (= 32 × 2), when sampling_frequency is 24 kHz, when the number of frames is 48 (= 24 × 2), and when sampling_frequency is 22.05 kHz, When the number of frames included in AOB_ELEMENT is 44 (= 22 × 2) and sampling_frequency is 16 kHz, the number of frames included in AOB_ELEMENT is 32 (= 16 × 2). However, when editing such as dividing the AOB, the number of AOB_FRAMEs at the beginning and end of the AOB_ELEMENT may be smaller than the number in FIG.
[0047]
AOB_ELEMENT is not given special information such as a header, but its data length is shown in the time search table instead.
{3-3_10-6_15} AOB_ELEMENT and AOB_FRAME time length example
FIG. 15 is a diagram illustrating an example of the time length of AOB_ELEMENT and the time length of AOB_FRAME. The first level of the figure shows an arrangement of a plurality of AOB_BLOCKs, and the second level shows an arrangement of a plurality of AOB_ELEMENTs. The third level shows the arrangement of multiple AOB_FRAMEs.
[0048]
Referring to this figure, it can be seen that AOB_ELEMENT corresponds to a playback time length of about 2.0 seconds, and AOB_FRAME in this figure corresponds to a playback time length of 20 msec. The character string “TMSRT_entry” attached to each AOB_ELEMENT indicates that the data length of each AOB_ELEMENT is described in the time search table. By performing forward search playback and reverse search playback with reference to such TMSRT_entry, for example, intermittent playback of skipping 2.0 seconds and playing only 240 milliseconds can be realized. .
[0049]
About {3-3_10-7} AOB_BLOCK
This is the end of the description of AOB_ELEMENT. Next, AOB_BLOCK located at the third level in the diagram showing the data structure of the AOB file in FIG. 10 will be described.
“AOB_BLOCK” is an area composed of valid AOB_ELEMENT, and one area exists in the AOB file. AOB_ELEMENT corresponds to a playback time of 2 seconds, whereas AOB_BLOCK corresponds to a playback time with an upper limit of 8.4 minutes. The reason why each AOB is limited to the playback time of 8.4 minutes is to limit the size of the time search table to 504 bytes or less by limiting the number of AOB_ELEMENT included in AOB_BLOCK.
[0050]
{3-3_10-8} Time search table suppression
Hereinafter, the reason why the time search table can be suppressed by limiting the reproduction time will be described in detail.
When performing forward search playback and reverse search playback, “2 second skip 240 ms playback” is performed in which reading is skipped for 2 seconds and only 240 ms is played back. In this way, when skipping a time length of 2 seconds, in principle, it is sufficient to refer to the data length indicated in the ADTS header of AOB_FRAME sequentially, but in that case, to skip the time interval of 2 seconds 100 (= 2 seconds / 20 milliseconds) of AOB_FRAME must be sequentially detected, and an extra processing load is applied to the playback apparatus. In order to reduce such processing load, the reading destination address at intervals of 2 seconds is described in the time search table, and when the forward search reproduction and backward search reproduction are ordered, the reproduction apparatus refers to this. That's fine. That is, in the time search table, information for calculating the read destination address 2 seconds ahead and 4 seconds ahead, specifically, the data length for each AOB_ELEMENT is described, and the playback device refers to this. Thus, forward search reproduction-reverse search reproduction may be performed. Consider how much data length is equivalent to 2 seconds. Since the bit rate at the time of reproduction of audio data is in the range of 16 Kbps to 144 Kbps as described above, the data length reproduced every 2 seconds is 4 Kbytes (= 16 Kbps × 2/8) to 36 Kbytes (= 144 Kbps × 2 / 8).
[0051]
If the data length per 2 seconds is 4 to 36 Kbytes, the data length of the entry in the time search table for describing the data length of the audio data needs 2 bytes (16 bits). This is because if a 16-bit length is assigned to an entry, a numerical value of 0 to 64 KByte can be described. On the other hand, considering that the total data size of the time search table is limited to, for example, 504 bytes (this is the data size of TKTMSRT described later), entries to be provided in this time search table are 252 (= 504 / 2) Must be limited to pieces. As described above, since entries are provided every 2 seconds, the playback time corresponding to 252 entries is 504 seconds (= 2 seconds × 252), and 8 minutes 24 seconds (= 8.4 minutes). Thus, by limiting the playback time in AOB_BLOCK to 8.4 minutes or less, the data size of the time search table can be made 504 bytes or less.
[0052]
{3-3_10-9} About AOB
This is the end of the description of AOB_BLOCK. Next, AOB will be described.
The AOB located at the second level in FIG. 10 is an area to which an invalid area is assigned before and after AOB_BLOCK, and there is one AOB file.
This invalid area is an area that is stored in the same cluster as the AOB_BLOCK and is read / written together with the AOB_BLOCK. In AOB, where to where corresponds to AOB_BLOCK is specified by BIT included in the navigation data (details will be described later).
[0053]
From the above, it has become clear what data is stored in each AOB file. Next, what kind of content is reproduced by continuously reading AOB and AOB_BLOCK included in the eight AOB files shown in FIG.
{3-3_10-10_16}
FIG. 16 shows what playback content is played back by successively playing back each AOB and AOB_BLOCK recorded in the AOB file. The first row shows eight AOB files in the user data area, and the second row shows eight AOBs recorded in each AOB file. The third level shows eight AOB_BLOCKs included in each AOB.
[0054]
The fifth row shows a title composed of five content parts. The five content sections indicate five songs, SongA, SongB, SongC, SongD, and SongE, respectively, and the title indicates a music album composed of these five songs (contents). The broken lines AS1, AS2, AS3, ... AS7, AS8 show the correspondence between the music album division and AOB_BLOCK. The fourth row is the division of the fifth album in what unit Indicates what will be done.
[0055]
Referring to these broken lines, AOB_Block included in each AOB # 1 is a song (SongA) played in a time of 6.1 minutes, and AOB_Block included in each AOB # 2 is played in a time of 3.3 minutes AOB_Block included in each AOB # 3 is a song (SongC) that is played back in a time of 5.5 minutes. As described above, it can be seen that AOB001.SA1 to AOB003.SA1 correspond to independent songs. The sixth row shows a track sequence composed of Tracks A to E. These Track A to E correspond to each of the five songs, SongA, SongB, SongC, SongD, and SongE, on a one-to-one basis and are treated as one independent playback unit.
[0056]
On the other hand, AOB # 4 is the beginning of a song (SongD) that is played back at a time of 30.6 minutes and is played back at a playback time of 8.4 minutes. AOB_BLOCK included in AOB # 5 and AOB # 6 is the middle part of SongD, and the playback time is 8.4 minutes. AOB_BLOCK included in AOB # 7 is the end part of SongD and played back with a playback time of 5.4 minutes. The Thus, it can be seen that a song having a playback time of 30.6 minutes is divided in units of (8.4 minutes + 8.4 minutes + 8.4 minutes + 5.4 minutes) and included in each AOB. As can be understood from this figure, it can be seen that all the songs included in the AOB file are contained within a playback time length of 8.4 minutes.
[0057]
From the above description, it has been clarified that the data size of the time search table associated with each AOB is limited by limiting the playback time length of the AOB. Next, navigation data including this time search table will be described.
{3-3_8A, B-2}
As described above, the navigation data consists of two files “SD_Audio.PLM” and “SD_Audio.TKM”. The file “SD_Audio.PLM” includes a playlist manager (Playlistmanager), and the file “SD_Audio.TKM” includes a track manager (TrackManager).
[0058]
As described in the presentation data explanation, multiple AOB files contain encoded AOBs. How long these AOBs play, and what each AOB is It is the name of the song, and it does not describe who the composer is. On the other hand, since a plurality of AOBs are only recorded in a plurality of AOB files, it is not described at all what order to reproduce them. The track manager and the playlist manager are provided to notify the playback apparatus of such information.
[0059]
Here, the track manager shows the correspondence between the AOB recorded in the AOB file and the track, how long the playback time of these AOBs, and what each AOB is, It includes a plurality of track management information indicating various information such as who the composer is. A track is a reproduction unit that is meaningful to the user. When a musical work is to be stored in the flash memory card 31, the track corresponds to a song and a reading book is to be stored in the flash memory card 31 ( A reading book is not a book but a document work expressed by reading sound), and if it is a book genre, a track corresponds to a chapter / section of a sentence. The track manager is provided to manage a plurality of AOBs recorded in a plurality of AOB files as a set of tracks.
[0060]
A playlist defines a plurality of playback orders of tracks, and the playlist manager includes a plurality of such playlists.
Hereinafter, the track manager will be described with reference to the drawings.
{17-1_18} Detailed configuration of Playlistmanager and TrackManager
FIG. 17 is a diagram in which the configurations of Playlistmanager and TrackManager in the embodiment are detailed in stages, and FIG. 18 is a diagram illustrating the sizes of PlayListManager and TrackManager. That is, in the figure, the logical format located on the right stage is a detailed version of the logical format located on the left stage, and the lead line shown by the broken line indicates that the right logical format is within the left logical form. It clarifies which part of is detailed.
[0061]
Referring to the configuration of TrackManager in FIG. 17 in accordance with such a notation, TrackManager is shown as Track Information (abbreviated as TKI) # 1, # 2, # 3, # 4,.・ It consists of #n. These TKIs are information for managing the AOB recorded in the AOB file as a track, and correspond to each AOB file.
[0062]
Referring to FIG. 17, each TKI has a Track_General_Informatin (TKGI), a Track_Text_Infomation_Data_Area (TKTXTI_DA) in which text information unique to the TKI is described, and a Track_Time_Serch_Table (TKTMSRT) having a role of a time search table, as indicated by a dashed lead line h2. You can see that Referring to FIG. 18, it can be seen that TKI itself has a fixed size (1024 bytes), and TKGI and TKTXTI_DA have a total length of 512 bytes. TKTMSRT also has a fixed length of 512 bytes. In TrackManager, up to 999 TKIs can be set.
[0063]
It can be seen that this TKTMSRT is composed of TMSRT_Header and TMSRT_etry # 1, # 2, # 3.
{17-2_19} Interaction between TKI, AOB file and AOB
FIG. 19 is a diagram showing the interrelationship between the TKI shown in FIG. 17 and the AOB file and AOB shown in FIG. The square frame in the first row in FIG. 19 is a track sequence composed of Tracks A to E, the square frame in the second row in FIG. 19 is TrackManager, and the third and fourth rows are the eight shown in FIG. Indicates an AOB file. Eight frames in the fifth row indicate eight AOBs. These eight AOB files are recorded from the eight AOBs shown in FIG. 16, and form a music album including TrackA, TrackB, TrackC, TrackD, and TrackE. The second row shows 8 TKIs. The numerical values "1", "2", "3", "4" given to these TKIs are serial numbers for identifying each TKI, and each TKI has the same serial number 001,002,003,004,005 ... It is associated with the assigned AOB file. With this in mind, referring to FIG. 19, TKI # 1 corresponds to AOB001.SA1, TKI # 2 is AOB002.SA1, TKI # 3 is AOB003.SA1, and TKI # 4 is AOB004.SA1. (Arrows TA1, TA2, TA3, TA4... In this figure indicate which AOB file each TKI corresponds to.) In this way, each TKI has a one-to-one correspondence with the AOB recorded in each AOB file, so that information specific to the AOB can be described in detail in each TKI.
[0064]
{17-3_20} TKTMSRT data structure
First, TKTMSRT will be described as information specific to AOB recorded in an AOB file. FIG. 20 is a diagram showing a detailed data structure of TKTMSRT shown in FIG. The detailed data structure of the time search table header (TMSRT_Header) is shown on the right side of the figure. In FIG. 20, the data size of the time search table header is 8 bytes, TMSRT_ID (from 0th byte to 1st byte), reserved (from 2nd byte to 3rd byte), Total TMSRT_entry_Number (from 4th byte to 7th byte) It has three fields (up to eyes). In “TMSRT_ID”, an ID for uniquely identifying TMSRT is described. “Total TMSRT_entry Number” describes the total number of TMSRT_entry in the TMSRT.
[0065]
{17-3_21-1} Specific examples of TKTMSRT
Next, TKTMSRT will be described in more detail. FIG. 21 is a diagram illustrating an example of TKTMSRT. The left side of the figure shows AOB, and the right side shows TKTMSRT. The AOB on the left side of the figure consists of multiple AOB_ELEMENT # 1, # 2, # 3 ... # n, and occupies multiple areas AR1, AR2, AR3 ... ARn on the right side. ing. Also, the numbers such as “0”, “32000”, “64200”, “97000”, “1203400”, and “1240000” in the figure are the occupied areas AR1, AR2, AR3, ARn-1, ARn of each AOB_ELEMENT from the beginning of AOB_BLOCK included in AOB Indicates the relative address up to. AOB_ELEMENT # 2 indicates that recording is performed at a position separated by “32000” from the head of AOB_BLOCK. AOB_ELEMENT # 3 is recorded at a position separated by “64200” from the head of AOB_BLOCK, and AOB_ELEMENT # n-1 is recorded at a position separated by “1203400” from the head of AOB_BLOCK.
[0066]
It should be noted that the interval between the start addresses of the occupied areas is not a constant value, that is, the occupied areas of each AOB_ELEMENT occupy a plurality of clusters of different sizes. The size of each occupied area is different because the code allocation in each AOB_FRAME is variable.
Since the occupancy size of each AOB_ELEMENT is different, when jumping to the head of each AOB_ELEMENT, it is necessary to instruct the playback device in advance where each AOB_ELEMENT exists in the AOB. For this purpose, a plurality of TMSRT_entry are described. The arrows RT1, RT2, RT3 ... RTn-1, RTn are the occupied areas AR1, AR2, AR3 ... ARn-1, ARn of these AOB_ELEMENTs, TMSRT_entry # 1, TMSRT_entry # 2 , TMSRT_entry # 3... TMSRT_entry # n-1, TMSRT_entry # n. That is, the size of the occupied area AR1 of AOB_ELEMENT # 1 is described in TMSRT_entry # 1, and the size of occupied areas AR2 and AR3 of AOB_ELEMENT # 2 and AOB_ELEMENT # 3 Are described in TMSRT_entry # 2 and TMSRT_entry # 3.
[0067]
Here, since the occupied area AR1 occupies from the beginning of AOB to the beginning "32000" of AOB_ELEMENT # 2, TMSRT_entry # 1 is described as 32000 (= 32000-0), and the occupied area AR2 is AOB_ELEMENT TMSRT_entry # 2 is described as “32200 (= 64200-32000)” from the first “32000” of # 1 to the first “64200” of AOB_ELEMENT # 2, and the occupied area AR3 is AOB_ELEMENT # 3 TMSRT_entry # 3 is “32800 (= 97000-64200)”, and the occupied area ARn-1 is the head of AOB_ELEMENT # n-1 because it occupies from the beginning “64200” to the beginning “97000” of AOB_ELEMENT # 4 TMSRT_entry # n-1 is described as “36600 (= 1240000-1203400)” because it occupies from “1203400” to the beginning “1240000” of AOB_ELEMENT # n.
[0068]
{17-3_21-2} TKTMSRT readout method
Thus, it can be seen that the data size of AOB_ELEMENT is described in the time search table. On the other hand, as described in the explanation of AOB_ELEMENT, since the data length of each AOB_BLOCK is determined so that the reproduction time is within 8.4 minutes, the total number of AOB_ELEMENT included in one AOB is a predetermined number (FIG. 20). 252) shown below. Since the number of AOB_ELEMENT is suppressed to a predetermined number or less, the total number of TMSRT_entry corresponding to AOB_ELEMENT is also equal to or smaller than the predetermined number, and the data size of TKTMSRT including these is also equal to or smaller than the predetermined size. Since the size of TKTMSRT is suppressed, the playback device can read and use the TKI as follows.
[0069]
When a certain AOB is read and its reproduction is started, the corresponding TKI is read and stored in the memory. Thereafter, this TKI is stored in the memory during the period when the reproduction of the AOB continues. When the playback of the AOB is completed, the subsequent AOB is read, and when the playback is started, the corresponding TKI is read, and the TKI that has been stored in the memory is read anew. Overwrite using issued TKI. Thereafter, this TKI is stored in the memory during the period when the reproduction of the AOB continues.
[0070]
By reading TKI and storing it in memory in this way, even if the amount of memory installed in the playback device is small, special search such as forward search playback and reverse search playback can be performed simply by reading the required TKI. Playback can be performed. In this embodiment, the data length from the start address of a certain AOB_ELEMENT to the start address of the next AOB_ELEMENT is described as TMSRT_entry. However, a relative address from the start of AOB_BLOCK to the start of each AOB_ELEMENT may be described.
[0071]
{17-3_21-3} Identifying the cluster containing AOB_ELEMENT
Finally, referring to TKTMSRT, how to read an arbitrary AOB_ELEMENT is explained. When reading the AOB_ELEMENT # y located at the yth position from the top in the AOB with reference to the TKTMSRT in which the size of each AOB_ELEMENT is described, the cluster u satisfying the following {Formula 1} is obtained, and from the top of the cluster u It is only necessary to read after the offset v.
{Formula 1}
Cluster u = (total of TMSRT_entry from AOB_ELEMENT # 1 to AOB_ELEMENT # y-1 + DATA_Offset) / cluster size
Offset v = (sum of TMSRT_entry from AOB_ELEMENT # 1 to AOB_ELEMENT # y-1 + DATA_Offset) mod cluster size
When c = a mod b, c indicates a remainder when a is divided by b, and DATA_Offset is information described in the BIT, which will be described later.
[0072]
{17-4} About TKTXTI_DA
This is the end of the description of the time search map (TKTMSRT). Next, the Track Text Information Data Area (TKTXTI_DA) described in the upper part of TKTMSRT in FIG. 17 will be described.
In the Track Text Information Data Area (TKTXTI_DA), text information indicating an artist name, album name, arranger name, producer name, and the like is described. Even if there is no text data, this area is secured.
[0073]
{17-5} About TKGI
Next, TKGI at the top of TKTXTI_DA will be described. In FIG. 17, TKGI of TKI is TKI identifier “TKI_ID”, TKI number “TKIN”, TKI size “TKI_SZ”, link pointer “TKI_LNK_PTR” to the next TKI, block, as indicated by a broken lead line h4 It can be seen that a series of information such as attribute “TKI_BLK_ATR”, playback time “TKI_PB_TM”, TKI audio attribute “TKI_AOB_ATR”, “ISRC”, and block information “BIT” is recorded (this figure is simplified) For the sake of simplicity, some fields are omitted.)
[0074]
About {17-5_22-1} TKGI
Hereinafter, the detailed configuration of TKGI will be described with reference to FIG. The difference between this figure and FIG. 17 is that the data structure of TKGI shown in FIG. 17 is arranged on the left side of the figure, and “TKI_BLK_ATR”, “TKI_AOB_ATR”, “ISRC” that were not clarified in FIG. This bit configuration is arranged on the right side in the figure.
[0075]
{17-5_22-2} About TKI_ID
In “TKI_ID”, an ID that uniquely identifies the TKI (in this embodiment, a 2-byte code “A4”) is described.
{17-5_22-3} About TKIN
In “TKIN”, a TKI number ranging from 1 to 999 is described. This TKI number must not overlap with the TKI number described in TKIN of another TKI. As such TKIN, the order of TKI in TrackManager, that is, the position of TKI in TrackManager is described. In the case of TKI # 1, the TKI number is described as “1”, in the case of TKI # 2, the TKI number is described as “2”, and in the case of TKI # 3, the TKI number is described as “3”.
[0076]
{17-5_22-4} About TKI_SZ
In “TKI_SZ”, the data size of TKI is described in units of bytes. In FIG. 22, since the data size of TKI is defined as 1024 bytes, it is described as 1024 bytes in this embodiment.
{17-5_22-5} About TKI_LNK_PTR
In “TKI_LNK_PTR”, TKIN about the TKI linked to the TKI is described. Here, the correspondence between TKIs will be described.
[0077]
When a track is composed of a plurality of AOBs and these are recorded in a plurality of AOB files, a plurality of TKIs associated with the plurality of AOB files are integrated to manage the track. . When a plurality of TKIs are integrated as described above, it is necessary to indicate which AKI file corresponding to which TKI follows the AOB file corresponding to these TKIs. TKI_LNK_PTR is used for the purpose of describing TKIN for TKI that follows each TKI.
[0078]
{17-5_22-6_19} About TKI_LNK_PTR
Hereinafter, how TKI_LNK_PTR is set in the eight TKIs shown in FIG. 19 will be described. TKI_LNK_PTR is not set in TKI # 1 to TKI # 3 and TKI # 8 that make up one track, but TKI # 4, TKI # 5, TKI # 6, and TKI # that correspond to the four AOB files that make up TrackD 7 is set such that each TKI_LNK_PTR indicates the next TKI_LNK_PTR. That is, as indicated by arrows TL4, TL5, and TL6, TKI_LNK_PTR of TKI # 4 indicates TKI # 5, TKI_LNK_PTR of TKI # 5 indicates TKI # 6, and TKI_LNK_PTR of TKI # 6 indicates TKI # 7 is doing. These all constitute TrackD. By referring to these TKI_LNK_PTRs in the TKI associated with the four AOB files, the four TKIs TKI # 4 to TKI # 7 and the four AOB files AOB004.SA1 to AOB007.SA1 are integrated. You can see that TrackD is configured.
[0079]
{17-5_22-7} About TKI_BLK_ATR
In “TKI_BLK_ATR”, attributes about TKI are described. In FIG. 22, the bit structure of TKI_BLK_ATR is shown in a frame drawn from the TKI_BLK_ATR by a broken line. In this figure, TKI_BLK_ATR is 16 bits, and bits b3 to b15 are reserved for future expansion. The attribute about TKI is described using 3 bits from bit number b2 to b0.
[0080]
When TKI is used and one TKI is included in one track, a value of “000b” is described in TKI_BLK_ATR (hereinafter, this setting is referred to as “Track”). When TKI is used and one track includes a plurality of TKIs and the TKI is the head, the value of “001b” is described in TKI_BLK_ATR (hereinafter, this setting is referred to as “Head_of_Track”). . If TKI is used and one track consists of multiple TKIs, and the TKI is in the middle, the value of “010b” is described in TKI_BLK_ATR (this setting is hereinafter referred to as “Midpoint_of_Track”) . When TKI is used and one track is composed of a plurality of TKIs, and the TKI is the terminal, the value of “011b” is described in TKI_BLK_ATR (hereinafter, this setting is referred to as “End_of_Track”). . When the TKI is unused and there is a TKI area, that is, when the TKI is deleted, a value of “100b” is described (hereinafter, this setting is referred to as “Unused”). When the TKI is unused and there is no TKI area, that is, when the TKI is in the initial state, the value “101b” is described.
[0081]
{17-5_22-8_19} TKI_BLK_ATR setting example
In the example of FIG. 19, how TKI_BLK_ATR for each TKI is set will be described.
Referring to TKI_BLK_ATR in each TKI, the four sets of TKI # 1 (AOB001.SA1), TKI # 2 (AOB002.SA1), TKI # 3 (AOB003.SA1), and TKI # 8 (AOB008.SA1) Since each corresponds to an independent track, TKI_BLK_ATR of TKI # 1, TKI # 2, TKI # 3, and TKI # 8 is set to “Track”.
[0082]
It can be seen that TKI_BLK_ATR in TKI # 4 is set to “Head_of_Track”, TKI_BLK_ATR in TKI # 7 is set to “End_of_Track”, and TKI # 5 and TKI # 6 are set to “Midpoint_of_Track”. This means that TKI # 4 (AOB004.SA1), which has a corresponding relationship with TKI # 4, is the beginning of the track, and TKI # 5 (AOB005.SA1) and TKI #, which have a corresponding relationship with TKI # 5 and TKI # 6. 6 (AOB006.SA1) means the middle part of the track and TKI # 7 (AOB007.SA1) having a corresponding relationship with TKI # 7 means the end part of the track.
[0083]
As described above, if TKI (AOB file) pairs are classified according to the description of TKI_BLK_ATR in each TKI, it can be seen that TKI # 1 (AOB001.SA1) constitutes the first track (TrackA). It can be seen that TKI # 2 (AOB002.SA1) constitutes the second track (TrackB) and TKI # 3 (AOB003.SA1) constitutes the third track (TrackC).
TKI # 4 (AOB004.SA1) forms the beginning of the fourth track (TrackD), and TKI # 5 (AOB005.SA1) and TKI # 6 (AOB006.SA1) form the middle part of TrackD It can be seen that TKI # 7 (AOB007.SA1) constitutes the end of TrackD. It can be seen that TKI # 8 (AOB008.SA1) independently forms the end of the fifth TrackE.
[0084]
{17-5_22-9} About TKI_PB_TM
In “TKI_PB_TM”, the playback time of a track (song) composed of AOBs recorded in an AOB file corresponding to TKI is described.
When a track is composed of a plurality of TKIs, the playback time of the entire track is described in TKI_PB_TM for the first TKI. In the second and subsequent TKIs, the playback time of the AOB corresponding to each TKI is described.
[0085]
{17-5_22-10} About TKI_AOB_ATR
In "TKI_AOB_ATR", what sampling frequency the AOB recorded in the AOB file corresponding to TKI is sampled, what bit rate is transferred, how many channels, etc. , Encoding conditions for generating an AOB are described. A frame drawn with a broken line from “TKI_AOB_ATR” indicates a bit configuration of TKI_AOB_ATR. In this figure, TKI_AOB_ATR is 20 bits, and the coding mode is described in the fields from bit number b16 to bit number b19. When encoded with MPEG-2 AAC (with ADTS header), the value of "0000b" is set to Windows (registered) when encoded with MPEG-layer3 (MP3). "Trademark) When encoded with Media Audio (WMA)," 0010b "is described.
[0086]
In the fields from bit number b15 to bit number b8, the bit rate is described. When encoded with MPEG-2 AAC (with ADTS header), the value of "16" to "72" is "16" to "96" when encoded with MPEG1-layer3 (MP3). When the value of "16" to "80" is encoded with MPEG2-layer3 (MP3) LSF, the value of "8" is encoded with Windows (registered trademark) Media Audio (WMA). Each value of ~ 16 is described.
[0087]
The sampling frequency is described in bit number b7 to bit number b4. "0000b" for 48kHz, "0001b" for 44.1kHz, "0010b" for 32kHz, "0011b" for 24kHz, "0100b" for 22.05kHz, "0101b" for 16kHz A value is described.
In the field from bit number b3 to bit number b1, the number of channels is described. In the case of 1ch (mono), “000b” is described. In the case of 2ch (stereo), “001b” is described.
[0088]
The areas from bit number b31 to bit number b20 and bit number b0 are reserved for future expansion.
{17-5_22-11} About ISRC
“ISRC” describes ISRC (International Standard Recording Code) in TKGI. A frame drawn with a broken line from “ISRC” in FIG. 22 indicates the contents of ISRC. As shown in this frame, ISRC consists of 10 bytes, and the Recording-item code (# 12) is described in the field from bit number b4 to bit number b7, and from bit number b8 to bit number b11. Recording code / Recording-item code (# 11) is described in the field.
[0089]
Recording code (ISRC # 10, # 9, # 8) is described in the field from bit number b12 to bit number b23. Year-of-Recording code (ISRC # 6, # 7) is described in the field from bit number b24 to bit number b31.
Hereinafter, the first owner code (ISRC # 3, # 4, # 5) is used for the field from bit number b32 to bit number b37, the field from bit number b40 to bit number b45, and the field from bit number b48 to bit number b53. ) Is described. Country code (ISRC # 1, # 2, # 3) is described in the field from bit number b56 to bit number b61 and the field from bit number b64 to bit number b69. A 1-bit validity flag is described in the field of bit number b79. For details of ISRC, refer to ISO3901: 1986 “Documentation-International Standard Recording Code (ISRC)”.
[0090]
{17-5_22-12_23A-1} About BIT
The “block information table (BIT)” is a table for managing AOB_BLOCK. FIGS. 23A and 23B are diagrams illustrating a detailed configuration of the BIT. As shown in FIG. 23 (a), the BIT consists of a DATA_OFFSET field that occupies the 60th to 63rd bytes, an SZ_DATA field that occupies the 64th to 67th bytes, and the 68th to 71st bytes. The occupying TMSRTE_Ns field, the FNs_1st_TMSRTE field occupying the 72nd to 73rd bytes, the FNs_Last_TMSRTE field occupying the 74th to 75th bytes, the FNs_Middle_TMSRTE field occupying the 76th to 77th bytes, and the 78th byte TIME_LENGTH field that occupies the first to 79th bytes. Hereinafter, each component will be described.
[0091]
{17-5_22-12_23A-2} About DATA_Offset
In “DATA_OFFSET”, the relative address from the cluster boundary to the beginning of each AOB_BLOCK is described in bytes. This expresses how many invalid areas exist between AOB and AOB_BLOCK. If the music stored in the flash memory card 31 as AOB is air-checked and recorded, and the music intro is mixed with disc jockey's voice, set DATA_Offset in the BIT. This unnecessary sound can be excluded from AOB_BLOCK and not reproduced.
[0092]
{17-5_22-12_23A-3} About SZ_DATA
In “SZ_DATA”, the data length of each AOB_BLOCK is described in bytes. If the value obtained by adding SZ_DATA and DATA_Offset is subtracted from the file size (integer multiple of the cluster size) containing the AOB, it is possible to determine the size of the invalid area following AOB_BLOCK.
[0093]
{17-5_22-12_23A-4} About TMSRTE_Ns
In “TMSRTE_Ns”, the total number of TMSRT_entry included in each AOB_BLOCK is described.
{17-5_22-12_23A-5} About "FNs_1st_TMSRTE", "FNs_Last_TMSRTE", "FNs_Middle_TMSRTE"
In “FNs_1st_TMSRTE”, the number of AOB_FRAMEs included in the AOB_ELEMENT located at the head of the AOB_BLOCK is described.
[0094]
In “FNs_Last_TMSRTE”, the number of AOB_FRAMEs included in the last AOB_ELEMENT of AOB_BLOCK is described.
In “FNs_Middle_TMSRTE”, the number of AOB_FRAMEs included in AOB_ELEMENT excluding the first and last AOB_ELEMENT, that is, AOB_ELEMENT located in the middle part of AOB_BLOCK is described.
[0095]
“TIME_LENGTH” is a field that describes the playback period of AOB_ELEMENT with the time accuracy of millisecond order in the format shown in FIG. As shown in FIG. 23C, the TIME_LENGTH field is 16 bits long, and if the encoding method is MPEG-AAC method or MPEG-Layer3 method, the playback period of AOB_ELEMENT is 2 seconds. The value of 2000 is described.
[0096]
{17-5_22-13_23B}
FIG. 23B shows how many AOB_FRAMEs are stored in FNs_Middle_TMSRTE. This figure shows the correspondence between sampling_frequency and the number of AOB_FRAMEs included in the AOB_ELEMENT in the middle part, as in FIG. The correspondence between sampling_frequency in this figure and the number of frames included in AOB_ELEMENT is exactly the same as in FIG. 14, and it can be seen that the number is different depending on the sampling frequency. The number of frames in “FNs_1st_TMSRTE” and “FNs_Last_TMSRTE” is set to the same number of frames as in principle in “FNs_Middle_TMSRTE”. Also, “FNs_Last_TMSRTE” is different from “FNs_Middle_TMSRTE”.
[0097]
{17-5_22-14_24} AOB_ELEMENT storage example
FIG. 24 is a diagram illustrating clusters 007 to 00E in which AOBs including AOB_ELEMENT # 1 to # 4 are stored. How the BIT is set when the AOB is stored as shown in FIG. 24 will be described. Each of AOB_ELEMENT # 1 to AOB_ELEMENT # 4 stored in cluster 007 to cluster 00E is given a triangular flag symbol, but these are assigned to each of AOB_ELEMENT # 1 to AOB_ELEMENT # 4 as TKI. Indicates that TMSRT_entry included in is set.
[0098]
At this time, the end portion of AOB_ELEMENT # 1 at the end of AOB is stored in cluster 007, and the end portion of AOB_ELEMENT # 4 at the end of AOB is stored in cluster 00E. AOB_ELEMENT # 1 to # 4 occupy from md0 in the middle of cluster 007 to md4 in the middle of cluster 00E. SZ_DATA in BIT indicates from AOB_ELEMENT # 1 to the end of AOB_ELEMENT # 4 as indicated by arrow sd1, and is an area in cluster 007,00E, and parts ud0 and ud1 that are not occupied by AOB_ELEMENT. Not directed.
[0099]
On the other hand, the AOB includes areas ud0 and ud1 which are areas in the cluster 007 and the cluster 00E and are not occupied by AOB_ELEMENT # 1 and AOB_ELEMENT # 4. DATA_Offset in BIT indicates the data length of the unoccupied portion ud0, that is, the relative value from the beginning of cluster 007 to the beginning of AOB_ELEMENT # 1.
In this figure, AOB_ELEMENT # 1 occupies from md0 in the middle of cluster 007 to md1 in the middle of cluster 008. This AOB_ELEMENT # 1 does not occupy the entire cluster 008 but is occupied by AOB_ELEMENT # 2 after the end portion. AOB_ELEMENT # 4 occupies the middle part md3 of the cluster 00C to the middle part md4 of the cluster 00E. Thus, it can be seen that there are recorded AOB_ELEMENTs across the cluster boundaries. That is, AOB_ELEMENT is recorded regardless of the cluster boundary. “FNs_1st_TMSRTE” in the BIT indicates the number of frames of AOB_ELEMENT # 1 in the cluster 007 to cluster 008, and “FNs_Last_TMSRTE” in the BIT indicates the number of frames of AOB_ELEMENT # 4 in the cluster 00C to cluster 00E.
[0100]
Thus, it can be seen that each AOB_ELEMENT is freely arranged regardless of the boundary of the cluster, and the offset from the cluster boundary to the AOB_ELEMENT and the number of frames for each AOB_ELEMENT are managed by the BIT.
{17-5_22-14_25} How to use the number of frames for each AOB_ELEMENT 1
The following explains how the number of frames for each AOB_ELEMENT described in BIT is used. The number of frames described in the BIT is first used when performing forward search reproduction and backward search reproduction in which reproduction elapsed time is skipped by 2 seconds and reproduction is performed for 240 milliseconds.
[0101]
FIG. 25 is a diagram showing how AOB_FRAME # x + 1 to be reproduced next is set when performing forward search reproduction from AOB_FRAME # x in an arbitrary AOB_ELEMENT # y in the AOB.
This figure is a diagram assuming that forward search reproduction is instructed when AOB_FRAME # x included in AOB_ELEMENT # y is being reproduced. In this figure, t is a predetermined intermittent playback time (= 240 milliseconds), f (t) is the number of frames corresponding to the intermittent playback time, and intermittent skip time skip_time is the time to be skipped when performing intermittent playback It is long (in this case, 2 seconds), and the number of frames corresponding to this intermittent skip time skip_time is f (skip_time). Here, the intermittent reproduction is performed by repeating the following procedures (1), (2), and (3).
[0102]
(1) Jump to the head of the flag (AOB_ELEMENT) with reference to TMSRT_entry described in TKTMSRT.
(2) Play for 240 milliseconds
(3) Jump to the top of the next flag (AOB_ELEMENT).
In the present embodiment, a method for realizing more accurate intermittent playback, in which playback is performed for 240 milliseconds, jumped to a position after 2 seconds, and playback is performed for 240 milliseconds, will be described.
[0103]
AOB_FRAME # x + 1 after 2 seconds + 240 milliseconds from AOB_FRAME # x included in AOB_ELEMENT # y should exist in AOB_ELEMENT # y + 1. When specifying AOB_FRAME # x + 1 after 2 seconds + 240 milliseconds, the start address for the next AOB_ELEMENT # y + 1 can be calculated immediately by reading TMSRT_entry in TKTMSRT, but the AOB_ELEMENT # The number of AOB_FRAMEs intervening from the start address of y + 1 to AOB_FRAME # x + 1 cannot be known only by TMSRT_entry. In order to calculate such AOB_FRAME number, AOB_ELEMENT #x is calculated from the sum of #x indicating the position of AOB_FRAME # x from the beginning of AOB_ELEMENT # y, f (t), and f (skip_time). It must be obtained by subtracting the total number of frames included in #y. In this way, in order to easily calculate the relative frame position of AOB_FRAME # x + 1 in the next AOB_ELEMENT # y + 1, “FNs_1st_TMSRTE”, “FNs_Middle_TMSRTE”, and “FNs_Last_TMSRTE” for each AOB_ELEMENT are described in the BIT. It is.
[0104]
{17-5_22-15_26A} How to use the number of frames for each AOB_ELEMENT 2
Secondly, the number of frames described in the BIT is used when executing a function (time search function) of starting playback from an arbitrary playback time. FIG. 26A is a diagram showing how to specify AOB_ELEMENT and AOB_FRAME corresponding to the designated time when an arbitrary reproduction start time is designated.
[0105]
When playback is instructed with an arbitrary time specified, if playback specified time is Jmp_Entry (seconds), playback may be started from AOB_ELEMENT # y and AOB_FRAME position x satisfying the following expressions.
{Formula 2}
Jmp_Entry (seconds) = (FNs_1st_TMSRTE + FNs_middle_TMSRTE x y + x) x 20msec
Since these “FNs_1st_TMSRTE” and “FNs_Middle_TMSRTE” are described in BIT, if AOB_ELEMENT # y and AOB_FRAME # x are calculated by applying these to {Formula 2}, refer to TKTMSRT corresponding to this AOB. Then, the head address of AOB_ELEMENT # y + 2 located at y + 2 in AOB is obtained, and from this head address, search for AOB_FRAME # x is started, and if xth AOB_FRAME is searched, this xth Start playback from AOB_FRAME. Thereby, the reproduction can be started from the time designated by Jmp_Entry (seconds).
[0106]
At this time, the ADTS header portion of the AOB file is not searched, and the search is performed in units of AOB_ELEMENT in which TMSRT_entry is described in TKTMSRT, so that the playback position corresponding to the playback specified time can be searched at high speed.
Similarly, when a time search function is executed for a track composed of a plurality of AOBs and Jmp_Entry (seconds) is specified, AOB_ELEMENT # y and AOB_FRAME # x satisfying {Formula 3} below are calculated. That's fine.
{Formula 3}
Jmp_Entry (seconds) = total playback time from AOB # 1 to AOB # n
+ (FNs_1st_TMSRTE (# n + 1) + FNs_middle_TMSRTE (# n + 1) ・ y + x) ・ 20msec
Here, the sum of the playback times of AOB from AOB # 1 to AOB # n is as follows.
Total playback time from AOB # 1 to AOB # n =
('FNs_1st_TMSRTE'(# 1) + 'FNs_Middle_TMSRTE'(# 1) ・ (TMSRT_entry number # 1-2) + 'FNs_Last_TMSRTE'(# 1)
+ "FNs_1st_TMSRTE"(# 2) + "FNs_Middle_TMSRTE"(# 2)-TMSRT_entry number # 2-2) + "FNs_Last_TMSRTE"(# 2)
+ "FNs_1st_TMSRTE"(# 3) + "FNs_Middle_TMSRTE"(# 3)-TMSRT_entry number # 3-2) + "FNs_Last_TMSRTE"(# 3)
...
+ "FNs_1st_TMSRTE"(#n) + "FNs_Middle_TMSRTE"(#n)-TMSRT_entry number # n-2) + "FNs_Last_TMSRTE"(#n))-20msec
If AOB # n, AOB_ELEMENT # y, and AOB_FRAME # x satisfying {Equation 3} are calculated, refer to TKTMSRT corresponding to this AOB # n + 1, and position at y + 2th AOB_ELEMENT # y + 2 From this address, the search for AOB_FRAME # x is started, and if the xth AOB_FRAME is searched, playback starts from this xth AOB_FRAME.
[0107]
{17-5_22-16_27A, B} Delete AOB file and TKI
Now that all the information included in the TKI has been explained, if some tracks are deleted (case 1), some tracks are deleted and then new tracks are recorded (case 2), A description will be given of how the TKI is updated when any two are integrated into one track (case 3) and when one track is divided to obtain two tracks (case 4).
[0108]
First, a case where a part of tracks is deleted (case 1) will be described.
FIGS. 27A and 27B are diagrams assuming a case where a track is deleted. This figure shows the TrackManager shown in FIG. 19, and it is assumed that the operator desires to delete TrackB in this figure. The AOB corresponding to this TrackB is recorded in AOB002.SA1, and it is associated with TKI # 2, so AOB002.SA1 is deleted and TKI_BLK_ATR of TKI # 2 is set to “Unused” Is done. FIG. 27B shows a state where AOB002.SA1 is deleted and TKI_BLK_ATR of TKI # 2 is set to “Unused”. Since AOB002.SA1 is deleted, the area occupied by AOB002.SA1 in the data area is released to a free area. In addition, in TrackManager, it can be seen that TKI_BLK_ATR of TKI # 2 is set to “Unused”.
[0109]
{17-5_22-17_28A, B} TKI assignment for new AOB file recording
Next, a case (case 2) in which a new track is recorded after a part of tracks is deleted will be described.
FIG. 28A is a diagram showing the TrackManager after a track has been deleted a plurality of times. In this figure, if a plurality of tracks are deleted and these are associated with TKI # 2, TKI # 4, TKI # 5, TKI # 7, and TKI # 8, the TKI_BLK_ATR of these TKIs is “Unused” Is set. The deletion of the AOB file is performed in the same way as a normal file, but the track manager completes the deletion process only by setting the TKI_BLK_ATR of the corresponding TKI to “Unused”. Then, as shown in this figure, the “Unused” TKI appears on TrackManager like a worm.
[0110]
FIG. 28B shows how an “Unused” TKI exists, and when a new TKI or AOB file is written here, the writing is performed.
Here, it is assumed that a track composed of four AOBs is to be written. Here, which free TKI is assigned to the AOB recording is determined by DPL_TK_SRP, which will be described later, or an arbitrary TKI is assigned. The four AOBs are assigned TKI # 2, TKI # 4, TKI # 7, and TKI # 8 that are set to “Unused” in TrackManager.
[0111]
Since these four AOBs constitute one track, TKI_BLK_ATR for TKI # 2 is `` Head_of_Track '', TKI # 4, TKI_BLK_ATR for TKI # 7 is `` Midpoint_of_Track '', and TKI_BLK_ATR for TKI # 8 is Set to “End_of_Track”. The four TKI # 2, TKI # 4, TKI # 7, and TKI # 8 constituting the track TrackD are set such that each TKI_LNK_PTR indicates the next TKI_LNK_PTR constituting the track TrackD. That is, as indicated by arrows TL2, TL4, TL7, TKI_LNK_PTR of TKI # 2 indicates TKI # 4, TKI_LNK_PTR of TKI # 4 indicates TKI # 7, and TKI_LNK_PTR of TKI # 7 indicates TKI # 8 is doing.
[0112]
After that, four files AOB002.SA1, AOB004.SA1, AOB007.SA1, AOB008.SA1 having the same numbers as TKI # 2, TKI # 4, TKI # 7, and TKI # 8 are created. The file contains four AOBs that make up TrackD.
With the setting of TKI_BLK_ATR and TKI_LNK_PTR, the fourth track TrackD is managed using TKI # 2, TKI # 4, TKI # 7, and TKI # 8.
[0113]
As described above, when a new track is written to the flash memory card 31, it can be seen that the TKI that has been set to “Unused” in the TrackManager so far is assigned to the TKI for the track to be newly recorded.
{17-5_22-18_29A, B} TKI setting when integrating two tracks
Next, we will explain how to update TKI when integrating tracks (case 3).
[0114]
FIGS. 29A and 29B are diagrams showing how the TKI is set when two tracks are integrated into one. FIG. 29 (a) is the same as TrackManager shown in FIG. 19, and it is assumed that the operator desires an editing operation of integrating TrackC and TrackE into one track in FIG. 29 (a). . AOBs corresponding to these TrackC and TrackE are recorded in AOB003.SA1 and AOB008.SA1, and they are associated with TKI # 3 and TKI # 8, so these TKI # 3 and TKI # 8 TKI_BLK_ATR Rewriting is performed. FIG. 29B is a diagram showing the TKI after rewriting of TKI_BLK_ATR. In this figure, TKI_BLK_ATR of TKI # 3 and TKI # 8 is described as Track, but in FIG. 29B, TKI_BLK_ATR of TKI # 3 is rewritten to “Head_of_Track” and TKI_BLK_ATR of TKI # 8 is “End_of_Track” Has been rewritten. Thus, by rewriting TKI_BLK_ATR, TKI # 3, TKI # 8, and AOB003.SA1 and AOB008.SA1 corresponding to these are handled as one track called TrackC. In addition to this, the TKI_LNK_PTR of TKI # 3 is rewritten to indicate TKI # 8 as a link destination.
[0115]
It should be noted that TKI_BLK_ATR of TKI has been rewritten, but the process of integrating AOB003.SA1 and AOB008.SA1 has not been performed. Because these AOB files are encrypted with different FileKeys, decryption-encryption that decrypts the encrypted AOB file and encrypts it again when they are combined into one This is because these two processes need to be performed for each AOB file, and a large processing load is required. In addition, since the AOB file after integration is encrypted with one FileKey, copyright protection is weakened compared with that before integration.
[0116]
In addition, TKI is originally set so that the size of TKTMSRT does not increase, but if this is integrated into one in editing operations, the size of TKI after integration may become too large. .
As described above, it can be understood that the integrated editing of the track in this embodiment is realized only by changing the attribute of TKI_BLK_ATR while maintaining the encryption of the AOB file.
[0117]
{17-5_22-18_29A, B-1_30,31} Conditions to be met when integrating tracks
As described above, track integration is realized by changing the attribute of TKI_BLK_ATR. However, when integrating tracks, it is required that the AOBs included in the integrated tracks satisfy the following conditions: .
The first condition is that the audio attributes (audio coding mode, bit rate, sampling frequency, number of channels) of the AOB included in the following track and the AOB included in the preceding track are the same. . This is because if the audio attributes of the AOB differ between the preceding and following AOBs, the playback device needs to reset the decoder operation once, making it difficult to play back two consecutive AOBs seamlessly (without interruption). That is why.
[0118]
The second condition is that three or more AOBs consisting only of AOB_ELEMENTs whose AOB_FRAME number is less than “FNs_Middle_TMSRTE” are not consecutive in the tracks obtained after integration.
The AOB is classified into two types depending on whether at least one of the AOB_ELEMENTs has the same number of AOB_FRAMEs as the number of frames specified in “FNs_Middle_TMSRTE”. The first type of AOB is an AOB having at least one AOB_ELEMENT having the same number of AOB_FRAMEs as the number of frames specified in “FNs_Middle_TMSRTE”, and the second type of AOB is “FNs_Middle_TMSRTE”. The AOB does not have any AOB_ELEMENT having the same number of AOB_FRAMEs as the number of frames specified in. In other words, the AOB_ELEMENT in the second type AOB is less than the number of frames specified in “FNs_Middle_TMSRTE”, and the second condition described above is that three or more Type2 AOBs continue. It is forbidden. The reasons for the prohibition are as follows. That is, when sequentially reading out AOBs, it is desirable that the buffer in the playback device is filled with a sufficient number of AOB_FRAMEs. However, if Type 2 AOBs are consecutive, the buffer in the playback device is replaced with AOB_FRAME. Cannot be satisfied. Then, the buffer in the playback device causes an underflow, and the AOB playback continuity cannot be maintained. In order to avoid such an underflow, the second condition prohibits three or more Type2 AOBs from continuing.
[0119]
FIG. 30A shows a Type 1 AOB, and FIG. 30B shows a Type 2 AOB. In FIG. 30B, the AOB consists of only two or less AOB_ELEMENTs, and these two or less AOB_ELEMENTs do not have the AOB_FRAME shown in “FNs_Middle_TMSRTE” (in this case, only FNs_1st_TMSRTE is described in the BIT) .)
Since it is a requirement of Type 2 AOB that it does not have AOB_FRAME shown in “FNs_Middle_TMSRTE”, even an AOB composed of only one AOB_FRAME is classified as an AOB of this Type 2.
[0120]
FIG. 31A is a diagram showing a case where a plurality of tracks are integrated into one by a combination of Type1 + Type2 + Type2 + Type1. In this case, three consecutive Type 2 AOBs are avoided, so they are integrated into one track.
FIG. 31B is a diagram showing a case where a plurality of tracks are integrated into one by a combination of Type1 + Type2 + Type2 + Type2 + Type1. In this case, since three Type 2 AOBs are consecutive, it is prohibited to integrate them into one track.
[0121]
{17-5_22-18_29A, B-1_32} Track integration considering the combination of Type1 and Type2 According to the integration of tracks shown in FIG. 31 (a), if the preceding track ends at Type1, this track is It can be integrated with a track having Type 2 AOB at the beginning or a track having Type 1 AOB at the beginning. FIG. 32A is a diagram showing an arrangement pattern in which a Type 1 AOB is arranged at the end of the preceding track, and a Type 1 AOB is arranged at the head of the following track. FIG. 32B is a diagram showing an arrangement pattern in which a Type 1 AOB is arranged at the end of the preceding track, and a Type 2 AOB is arranged at the beginning of the following track. Since both of these satisfy the condition 2, they can be integrated into one track.
[0122]
If the end of the preceding track is Type2, and a Type1 AOB is placed immediately before Type2, this track has a Type1 track at the beginning, or a Type2 AOB at the beginning, followed immediately by Type1. AOB can be integrated with the placed track.
FIG. 32C is a diagram showing an arrangement pattern in which AOBs are arranged in the order of Type 1 and Type 2 at the end of the preceding track, and Type 1 AOBs are arranged at the beginning of the following track. FIG. 32D is a diagram showing an arrangement pattern in which AOBs are arranged in the order of Type 1 and Type 2 at the end of the preceding track, and Type 2 and Type 1 AOBs are arranged at the head of the following track. Since these also satisfy condition 2, they can be integrated into one track.
[0123]
When the end of the preceding track is Type 2 and a Type 2 AOB is placed immediately before Type 2, this track can be integrated with a track having a Type 1 AOB at the beginning. FIG. 32E is a diagram showing an arrangement pattern in which Type 2 and Type 2 AOBs are arranged at the end of the preceding track, and Type 1 AOB is arranged at the beginning of the following track. Since this also satisfies condition 2, it can be integrated into one track. As described above, when integrating tracks, it is determined in advance whether the two tracks to be integrated satisfy the above two conditions, and only when it is determined that these two conditions are satisfied, Integrate into one.
[0124]
Next, the TKI update when the track is divided (case 4) will be described.
{17-5_22-19_33A, B} TKI setting for dividing tracks
FIGS. 33A and 33B are diagrams assuming a case where one track is divided into two tracks. The TrackManager in this figure is the same as the TrackManager shown in FIG. 27. In this figure, it is assumed that the operator desires to edit TrackC into two tracks called TrackC-TrackF. When trying to divide TrackC into TrackC-TrackF, AOB002.SA1 corresponding to TrackF is generated. In FIG. 33 (a), TKI # 2 is set to “Unused”. As a result of the division, TKI # 2 set to “Unused” is newly generated as shown in FIG. 33 (b). Assigned to AOB002.SA1.
[0125]
{17-5_22-19_33A, B-1_34A, B}
Update directory entries and FAT values
Here, when AOB003.SA1 is divided and AOB002.SA1 is generated, the directory entry and the FAT value must be updated. The following describes how to update these directory entries and FAT values. FIG. 34A shows how the SD_Audio directory entry for the SD_Audio directory to which AOB003.SA1 belongs is described before division. AOB003.SA1 is divided into a plurality of pieces and stored in clusters 007, 008, 009, 00A,... 00D, 00E. In this case, for AOB003.SA1 in the directory entry, “first cluster number of file” is described as “007”, and FAT values 007,008,009,00A,... 00D corresponding to clusters 007,008,009,00A,. They are described as (008), (009), (00A),... (00D), (00E), respectively.
[0126]
In this state, when the second half of AOB003.SA1 is divided to obtain AOB002.SA1, the SD_Audio directory entry contains the “file name”, “file extension”, and “file first cluster number” for AOB002.SA1. Added. FIG. 34B shows how the SD_Audio directory entry is described for the SD_Audio directory to which AOB003.SA1 belongs after division.
[0127]
Cluster 00F in this figure stores a copy of the contents of cluster 00B including the division boundary designated by the operator. The divided parts subsequent to the divided part of AOB002.SA1 stored in the cluster 00B are stored after the clusters 00C, 00D, 00E. Since the first part of AOB002.SA1 is stored in cluster 00F and the remaining part is stored after cluster 00C, 00D, 00E, the cluster number 00F is used for the “first cluster number of file” for AOB002.SA1. (00C), (00D), and (00E) are described in the FAT values 00F, 00C, 00D, and 00E associated with the clusters 00F, 00C, 00D, and 00E.
[0128]
{17-5_22-19_33A, B-2_35A, B} Setting of information elements in TKI
After obtaining AOB002.SA1 by updating the directory entry and FAT value as described above, how to set information elements in the TKI for AOB002.SA1 will be described. When generating a TKI for a divided track, the TKI information element must be copied and inherited from the original TKI (1), and updated based on the original TKI. There are two types of things (2) that must not be. The former corresponds to TKTXTI_DA and ISRC, and the latter corresponds to the remaining components including BIT and TKTMSRT. Since both of these exist, in this embodiment, when generating a TKI for a divided track, a TKI of the division source is copied to create a new TKI template, and TTKMSRT, BIT included in the TKI are included. Is divided and updated, and the remaining information elements are updated.
[0129]
FIG. 35A is a diagram assuming a case where AOB is divided by arbitrary AOB_FRAME. In the figure, the first row shows four AOB_ELEMENTs, AOB_ELEMENT # 1, AOB_ELEMENT # 2, AOB_ELEMENT # 3, and AOB_ELEMENT # 4. The data lengths of these four AOB_ELEMENTs are set in TKTMSRT as four TMSRT_entry # k-1, #k, # k + 1, # k + 2 (here k = 2). In this figure, assuming that a division boundary bd1 is set in AOB_ELEMENT # 2, AOB_ELEMENT # 2 includes a region {circle around (1)} consisting of a frame ahead of the division boundary bd1 and a region {circle around (2)} consisting of a frame behind the division boundary bd1. And divided. FIG. 35B is a diagram illustrating a state where the AOB is divided in the middle of AOB_ELEMENT # 2 and two AOBs AOB # 1 and AOB # 2 are obtained.
[0130]
{17-5_22-19_33A, B-3_36} BIT setting
FIG. 36 is a diagram showing how the BIT is set when the AOB is divided as shown in FIG. The AOB shown in FIG. 35 is divided at the division boundary bd1, and AOB # 1 obtained by the division includes two AOB_ELEMENTs, AOB_ELEMENT # 1 and AOB_ELEMENT # 2, and AOB # 2 is AOB_ELEMENT. It can be seen that it contains three AOB_ELEMENTs, # 1, AOB_ELEMENT # 2, and AOB_ELEMENT # 3.
[0131]
Each of these AOB_ELEMENTs is also assigned a triangular flag symbol, which indicates that TMSRT_entry included in the TKI corresponding to the AOB is set. First, AOB # 1 obtained by division will be described. Since AOB_ELEMENT # 1 and AOB_ELEMENT # 2 included in AOB # 1 occupy cluster 007 to cluster 00A, AOB # 1 is handled with cluster 007 to cluster 00A as one unit. Here, AOB_ELEMENT # 2 in AOB # 1 does not occupy the end of cluster 00A, but occupies the partition boundary bd1 where cluster 00A exists, so SZ_DATA for AOB # 1 is the area md0 To the data length up to the division boundary bd1 in the cluster 00A. AFN # 1's "FNs_1st_TMSRTE" is the same as before the division, but AOB # 1's "FNs_Last_TMSRTE" is the point that indicates the number of frames from the beginning before the division of AOB_ELEMENT # 2 to the division boundary bd1. And different.
[0132]
Next, AOB # 2 obtained by the division will be described. AOB_ELEMENT # 1, AOB_ELEMENT # 2, and AOB_ELEMENT # 3 included in AOB # 2 occupy cluster 00B to cluster 00F. Cluster 00F is a cluster that stores a copy of the contents of cluster 00A (the reason cluster 00A stores a copy of cluster 00A is that cluster 00A is occupied by AOB_ELEMENT # 2 of AOB # 1 This is because it is necessary to assign a cluster different from this cluster to AOB_ELEMENT # 1 included in AOB # 2.)
[0133]
AOB_ELEMENT # 1 in AOB # 2 is not occupied from the tip of cluster 00F, but occupies the boundary after bd1 where cluster 00F exists, so SZ_DATA for AOB # 2 is from the beginning of cluster 00B Therefore, the sum of the data length up to the middle part in cluster 00E and the data length occupied by AOB_ELEMENT # 1 in cluster 00F is instructed.
[0134]
The copy of cluster 00A stored in cluster 00F contains AOB_ELEMENT # 2 of AOB # 1, and the portion occupied by AOB_ELEMENT # 2 of AOB # 1 must be excluded from AOB # 2. Therefore, the DATA_Offset for the BIT of AOB # 2 is set to the size occupied by AOB_ELEMENT # 2 of AOB # 1 in cluster 00F.
[0135]
As can be seen from this figure, in the AOB division, only the AOB_ELEMENT including the division boundary is divided into two, and the AOB_ELEMENT before and after the division boundary is not changed from the one before the division. Therefore, `` FNs_Last_TMSRTE '' of AOB # 2 is set to the same value as `` FNs_Last_TMSRTE '' of AOB_ELEMENT # 4 before splitting, and `` FNs_1st_TMSRTE '' of AOB # 2 is set to AOB_ELEMENT # 1 of AOB # 2, that is, before splitting The number of frames included in the end part after the division boundary in AOB_ELEMENT # 2 is set.
[0136]
{17-5_22-19_33A, B-4_37} BIT setting
FIG. 37 is a diagram more specifically showing how the BIT changes before and after the division. The BIT on the left side of FIG. 37 shows an example of setting the BIT before division. In the BIT before dividing the track, Data_Offset is set to X, SZ_DATA is set to “52428”, and TMSRTE_Ns is set to “n”. It can be seen that FNs_1st_TMSRTE is set to “80 frames”, FNs_Middle_TMSRTE is set to “94 frames”, and FNs_Last_TMSRTE is set to “50 frames”.
[0137]
The right side of FIG. 37 shows the BIT settings for the two tracks after division. When the AOB corresponding to this BIT is divided as shown in FIG. 35A, Data_Offset is set to the same value “x” as before the division in the BIT of the first track, but up to the division point bd1 in SZ_DATA. The data length is updated to “Q”, and TMSRTE_Ns is updated to “k” which is the number of TMSRT_entry from the first TMSRT_entry to the kth TMSRT_entry. FNs_1st_TMSRTE and FNs_Middle_TMSRTE are set to 80,94 frames as before division, but the last AOB_ELEMENT of the AOB of the first track after division includes p AOB_FRAMEs in FIG. 35 (a). , FNs_Last_TMSRTE is set to “p frame”.
[0138]
For the BIT of the second track, Data_Offset is set to R, SZ_DATA is set to the original SZ # DATA52428−data length “Q” up to the dividing point bd1, and TMSRTE_Ns is set to n−k + 1 (kth TMSRT_entry Nk which is the number of TMSRT_entry from the first to the nth TMSRT_entry and one which is the number of the kth TMSRT_entry newly added for division. FNs_Middle_TMSRTE and FNs_Last_TMSRTE are set to 94,50 frames as before division, but since the first AOB_ELEMENT of the AOB of the second track after division contains 94-p AOB_FRAMEs, FNs_1st_TMSRTE is 94-p frame ”.
[0139]
{17-5_22-19_33A, B-5_38} BIT setting
FIG. 38 is a diagram illustrating the TKTMSRT after division. First, TMSRT is as follows. The TMSRT of the first track includes from the beginning of the TMSRT of the AOB before the division to the kth entry (TMSRT_entry # 1 to TMSRT_entry # k). It should be noted here that AOB_ELEMENT # k including the division boundary only includes the area (1), and therefore, the kth entry includes only the data size of the portion corresponding to the area (1). . The TMSRT of the second track includes (kMSRT_entry # k to TMSRT_entry # n) from the kth entry to the nth entry before division. It should be noted here that AOB_ELEMENT # k including the division boundary only includes the area (2) in the second track, so the kth entry before the division is the data size of the portion corresponding to this area (2) Only included.
[0140]
If TKI is copied, TKTMSRT and BIT are divided and updated, and the remaining information elements are updated, the TKI for the new track obtained by the division can be obtained. As in the case of integration, the track corresponding to the AOB file can be divided into two without decrypting the encrypted AOB file. Since the decryption / re-encryption is not accompanied when the AOB file is divided, it can be seen that the processing load when the track is divided is reduced. Thereby, even when the processing performance of the playback device is low, the track can be edited.
[0141]
Although it has become a long sentence above, the explanation about TKI is finished. Next, the playlist will be described.
{17-6} Playlistmanager
The playlist manager shown in FIG. 17 manages PlaylistManager_Information (PLMGI) for managing the playlist stored in the flash memory card 31 and all the tracks stored in the flash memory card 31, as indicated by the dashed lead line h5. Default_Playlist_Information (DPLI) and PlaylistInformation (PLI) # 1, # 2, # 3, # 4, # 5 ... # n, Default_Playlist information is as shown by a dashed lead line h6, It can be seen that Default_Playlist_General_Information (DPLGI), Default_Playlist_Track_Serch_Pointer (DPL_TK_SRP) # 1, # 2, # 3, # 4,. Each PLI is composed of Playlist_General_Information (PLGI), Playlist_Track_Serch_Pointer (PL_TK_SRP) # 1, # 2, # 3, # 4,... #M, as indicated by a dashed lead line h7.
[0142]
Here, the difference between Default_Playlist information and PlayList information will be described. The Default_Playlist information is obliged to specify all tracks, whereas the PlayList information does not have such an obligation, and an arbitrary track may be specified. Therefore, the user generates PlayList information specifying only his / her favorite track and stores it in the flash memory card 31, or among a plurality of tracks stored in the flash memory card 31 This is suitable for the use in which the playback device automatically generates PlayList information specifying only the genre track and stores it in the flash memory card 31.
[0143]
{17-7_18} Number of playlists, data size
Referring to FIG. 18, the maximum number of playlists is 99. Further, Playlist Manager Information (PLMGI) and Default Playlist Information (DPLI) have a fixed length of 2560 bytes in total. Playlist Information (PLI) is also a fixed length of 512 bytes. DPL_TK_SRP included in Default_Playlist information includes DPL_TK_ATR and DPL_TKIN. On the other hand, PL_TK_SRP included in the PlayList information includes only PL_TKIN. These DPL_TK_ATR, DPL_TKIN, and PL_TKIN have the format shown in FIG.
[0144]
{17-8_39-1} DPL_TK_SRP format
FIG. 39A shows the format of DPL_TK_SRP. In FIG. 39A, DPL_TK_SRP describes DPL_TKIN from the 0th bit to the 9th bit, DPL_TK_ATR from the 13th bit to the 15th bit, and reserves the 10th to 12th bits for reservation. Reserved.
[0145]
Next, a TKI number is described in DPL_TKIN occupying fields from the 0th bit to the 9th bit. By describing the TKI number here, it becomes possible to specify the TKI.
{17-9_39B} PL_TK_SRP format
FIG. 39B is a diagram illustrating a format of PL_TK_SRP. PL_TK_SRP has fields from the 0th bit to the 9th bit, and PL_TKIN, that is, a TKI number is described here.
[0146]
{17-8_39A-2} Configuration of DPL_TK_ATR
An example of setting DPL_TK_ATR is shown in a frame drawn from “DPL_TK_ATR” in FIG. 39A by dashed arrows h51 and h52. As can be understood from the description in this frame, the setting of DPL_TK_ATR for DPL_TK_SRP is the same as the setting of TKI_BLK_ATR for TKI, and any of “Track”, “Head_of_Track”, “Midpoint_of_Track”, “End_of_Track” Is set.
[0147]
Specifically, when the TKI specified by TKIN is in use and an audio object corresponding to one track is recorded in the AOB file corresponding to the TKI (“Track” in TKI_BLK_ATR of TKI) DPL_TK_ATR is set to a value of “000b”.
If the TKI specified in TKIN is in use and the audio object corresponding to only the head of the track is recorded in the AOB file corresponding to the TKI ("Head_of_Track" in TKI's TKI_BLK_ATR), DPL_TK_ATR is " The value of 001b "is set.
[0148]
If the TKI specified in TKIN is in use and the audio object corresponding to only the middle part of the track is recorded in the AOB file corresponding to the TKI (“Midpoint_of_Track” in TKI_BLK_ATR of TKI), DPL_TK_ATR The value of “010b” is set.
If the TKI specified in TKIN is in use and the AOB file corresponding to the TKI contains an audio object corresponding to only the end of the track ("End_of_Track" in TKI_BLK_ATR of TKI), DPL_TK_ATR , "011b" is set.
[0149]
If the TKI specified in TKIN is unused and only the TKI area is secured, that is, if it is a deleted TKI ("Unused" in TKI_BLK_ATR of TKI), the value of "100b" is set The
When the TKI specified by TKIN is unused and the TKI area is not secured, that is, when the TKI is in the initial state, the value “101b” is set.
[0150]
“DPL_TK_SRP” has a correspondence relationship with any one of a plurality of TKIs by describing a TKI number in DPL_TKIN. Further, the order of DPL_TK_SRP in the Default_Playlist information indicates what number an AOB (AOB file) corresponding to TKI having a correspondence relationship with DPL_TK_SRP is played back. As a result, the order of DPL_TK_SRP in the Default_Playlist information defines in what order a plurality of tracks are to be played back, that is, the playback order of the tracks.
[0151]
{17-9_40-1} Correlation between Default_Playlist information, TKI, and AOB files
FIG. 40 is a diagram showing the interrelationship between Default_Playlist information, TKI, and AOB files. The second, third, and fourth levels in this figure are the same as the first, second, and third levels in FIG. 19, and show TrackManager including 8 TKIs and 8 AOB files. . A difference from FIG. 19 is that a square frame indicating Default_Playlist information is described in the first row. Eight small frames included in the first frame indicate eight DPL_TK_SRP included in the Default_Playlist information. The upper part of these small frames indicates DPL_TK_ATR, and the lower part indicates DPL_TKIN.
[0152]
Referring to the arrows DT1, DT2, DT3, DT4 ... in this figure, a correspondence relationship is established between DPL_TK_SRP # 1 and TKI # 1, and DPL_TK_SRP # 2 and TKI # 2 It can be seen that correspondence relationships are also established between DPL_TK_SRP # 3 and TKI # 3 and between DPL_TK_SRP # 4 and TKI # 4.
Furthermore, referring to DPL_TK_ATR in each DPL_TK_SRP, DPL_TK_SRP # 1, DPL_TK_SRP # 2, DPL_TK_SRP # 3, and DPL_TK_SRP # 8 are all set to Track. That is, DPL_TK_SRP # 1 → TKI # 1 (AOB001.SA1), DPL_TK_SRP # 2 → TKI # 2 (AOB002.SA1), DPL_TK_SRP # 3 → TKI # 3 (AOB003.SA1), DPL_TK_SRP # 8 → TKI # 8 (AOB008 The four sets of .SA1) correspond to independent tracks.
[0153]
DPL_TK_SRP # 4, DPL_TK_SRP # 5, DPL_TK_SRP # 6, DPL_TK_SRP # 7's DPL_TK_ATR is not set to Track, DPL_TK_SRP # 4 is set to `` Head_of_Track '', DPL_TK_SRP # A_ is TRPL__ It can be seen that DPL_TK_SRP # 5 and DPL_TK_SRP # 6 are set to “Midpoint_of_Track”. This means that TKI # 4 (AOB004.SA1) corresponding to DPL_TK_SRP # 4 is the head of the track, and TKI # 5 (AOB005.SA1) and TKI having a corresponding relationship to DPL_TK_SRP # 5 and # 6 # 6 (AOB006.SA1) means that the middle part of the track and TKI # 7 (AOB007.SA1) corresponding to DPL_TK_SRP # 7 are the end part of the track.
[0154]
The order of DPL_TK_SRP in the DefaultPlaylist indicates in what order the AOB associated with each TKI is played back. DPL_TK_SRP # 1, # 2, # 3, # 4 in the DefaultPlaylist in this figure ... DPL_TKIN of # 8 is TKI # 1, # 2, # 3, # 4 ... # 8 As shown in arrows (1), (2), (3), (4), (8), AOB001.SA1 corresponding to TKI # 1 is played back first, and TKI # 2 AOB002.SA1 corresponding to the second, AOB003.SA1 corresponding to TKI # 3 is reproduced third, and AOB004.SA1 corresponding to TKI # 4 is reproduced fourth.
[0155]
{17-10_41} DefaultPlaylist, PlayList information setting example
FIG. 41 is a diagram showing a setting example of DefaultPlaylist and PlayList information in the same notation as FIG. In the figure, a square frame in the first row indicates Default_Playlist information, and three square frames in the second row indicate PlayList information. The small frames included in the DefaultPlaylist indicate eight DPL_TK_SRP included in the DefaultPlaylist, and the small frames included in the PlayList information indicate three or four PL_TK_SRPs. The setting of TKIN of each DPL_TK_SRP included in the Default_Playlist information in this figure is the same as that in FIG. However, it can be seen that the TKIN setting of PL_TK_SRP included in the PlayList information is completely different from that of DPL_TK_SRP.
[0156]
{17-10_42} Correspondence between DPL_TK_SRP and TKI
FIG. 42 is a diagram illustrating the correspondence between DPL_TK_SRP and TKI using the same notation as FIG. In FIG. 42, Playlist # 1 includes PL_TK_SRP # 1, # 2, and # 3. Among them, PL_TKIN of PL_TK_SRP # 1 is described as # 3, PL_TKIN of PL_TK_SRP # 2 is described as # 1, and PL_TKIN of PL_TK_SRP # 3 is described as # 2, so the track is recorded using PlayList information # 1. When reproducing, a plurality of AOBs are reproduced in the order of AOB # 3, # 1, and # 2, as indicated by arrows (11), (12), and (13).
[0157]
Playlist # 2 consists of PL_TK_SRP # 1, # 2, and # 3. Of these, PL_TKIN of PL_TK_SRP # 1 is described as # 8, and PL_TKIN of PL_TK_SRP # 2, # 3 is described as # 3, # 1, so when playing a track using PlayList information # 2, As indicated by arrows (21), (22), and (23), a plurality of AOBs are reproduced in the order of AOB # 8, # 3, and # 1, that is, in an order completely different from Playlist # 1.
[0158]
Playlist # 3 includes PL_TK_SRP # 1, # 2, # 3, and # 4. Of these, PL_TKIN of PL_TK_SRP # 1, # 2, # 3, and # 4 is described as # 8, # 4, # 3, and # 1, so the following is shown when playing a track using PlayList information # 3 AOB is played in the playback order. First, AOB # 8 that composes TrackE is played as shown by arrow (31), and AOB # 4, AOB # 5, AOB # 6, and AOB # 7 that make up TrackD as shown by arrow (32). Then it is played. Subsequently, playback is performed in the order of AOB # 3 and AOB # 1 constituting TrackC and TrackA as indicated by arrows (33) and (34). It should be noted here that when a track is composed of a plurality of TKIs, only the first TKI number of the plurality of TKIs is described in the PL_TK_SRP entry. Specifically, DPL_TK_SRP in Default_Playlist information specified TKI # 4, TKI # 5, TKI # 6, and TKI # 7 for TrackD, but PL_TK_SRP in PlayList information There is no need to specify two TKIs. This means that PL_TK_SRP # 2 of Playlist # 3 designates only TKI # 4 among TKI # 4 to TKI # 7.
[0159]
On the other hand, the DPLI including a plurality of DPL_TK_SRPs has a data size that can be accommodated in one sector, and is resident in the RAM. Therefore, when playing back each track based on the Playlist, it is possible to search each TKI at high speed by referring to DPL_TK_SRP resident in the RAM. That is, in order to play back TKI (AOB) using PL_TK_SRP in which only the first TKI number is described among multiple TKIs, DPL_TK_SRP resident in RAM based on TKI described in PL_TK_SRP is used. Search to determine whether the track is composed of multiple TKIs. In the case of being composed of a plurality of TKIs, a procedure of reproducing all corresponding TKIs (AOBs) is performed.
[0160]
As described above, DefaultPlaylist and a plurality of PlayList information are described in PlayListManager, and if different playback orders are described in DPL_TKIN and PL_TKIN of DPL_TK_SRP and PL_TK_SRP constituting these, multiple AOBs are played back differently. It will be played in order. If playback is performed in a completely different playback order, the operator can use the flash memory card 31 as if a plurality of music albums are stored.
[0161]
Also, it should be noted that the data size of DPL_TK_SRP is small (only 2 bytes) and the data size of TKI is large (there is 1024 bytes) among DPL_TK_SRP and TKI associated with the AOB file. Is a point. Changing the order of TKI in TrackManager causes many accesses to flash memory card 31, but even if the order of DPL_TK_SRP in Default_Playlist information and PlayList information is changed, access to flash memory card 31 does not increase so much. In view of this point, the navigation data actively changes the order of DPL_TK_SRP in DefaultPlaylist according to the editing operation, while maintaining the order of TKI in TrackManager constant regardless of the editing operation. I have to.
[0162]
{17-9_40-2_43A, B} Change the order of DPL_TK_SRP
Next, how the editing operation of changing the playback order of tracks by changing the order of DPL_TK_SRP in Default_Playlist information will be described. FIGS. 43A and 43B are diagrams assuming a case where the order of the tracks is changed. The settings of DPL_TK_SRP and TKI in FIG. 43A are the same as those in FIG. In FIG. 40A, DPL_TKIN in DPL_TK_SRP # 3 is set to TKI # 3 and DPL_TKIN in DPL_TK_SRP # 8 is set to TKI # 8. In this state, DPL_TK_SRP # 3 and DPL_TK_SRP # 8 surrounded by a thick frame Change the order. (1) (2) (3) (4) (5) (6) (7) (8) in FIG. 43 (b) show the playback order of the tracks after the order is changed. With this in mind, the playback order in FIG. 43 (a) is TrackA, TrackB, TrackC, TrackD, and TrackE. However, in the Default_Playlist information in FIG. 43 (b), the DPL_TKIN of DPL_TK_SRP # 3 and DPL_TK_SRP # 8 Since the order has been changed, playback is performed in the order of Track A, Track B, Track E, Track D, and Track C. In this way, by changing the order of DPL_TK_SRP in the Default_Playlist information, the playback order of tracks can be easily changed.
[0163]
Now that the editing operation called track change has been explained, as in the case of TKI, when some tracks are deleted (case 1), after some tracks are deleted, new tracks are recorded (case 2). ), How to use DPL_TK_SRP and TKI in the case of combining any two of multiple tracks into one track (case 3), and dividing one track to obtain two tracks (case 4) It will be described whether it is updated.
[0164]
{17-9_40-3_44A, B} Deleting a track
First, a case where a part of tracks is deleted (case 1) will be described.
44 (a) and 44 (b) are diagrams showing how the DefaultPlaylist, TrackManager, and AOB files are updated when DPL_TK_SRP # 2 and TKI # 2 are deleted from the DefaultPlaylist shown in FIG. is there. 44 has the same part as FIG. 27 cited in the description of TKI deletion. That is, the second, third, and fourth stages in FIG. 44 are the same as those in FIG. The difference is that, as in FIG. 40, Default_Playlist information including a plurality of DPL_TK_SRPs is described in the first row. In FIG. 44A, it is assumed that the user has deleted TrackB consisting of DPL_TK_SRP # 2 → TKI # 2 (AOB002.SA1) surrounded by a thick frame. In this case, DPL_TK_SRP # 2 is deleted in the Default_Playlist information, and the order of DPL_TK_SRP # 3 to DPL_TK_SRP # 8 is incremented by one so as to pack the fields occupied by DPL_TK_SRP # 2. In this way, the order of each DPL_TK_SRP is advanced, and the last DPL_TK_SRP # 8 is set to “Unused”. On the other hand, the TKI is only set to “Unused” as described with reference to FIGS. 27A and 27B, and no movement is performed to pack TKI # 2. It can also be seen that AOB002.SA1 has been deleted. Although the order has been raised for DPL_TK_SRP, the order has not been raised for TKI. Therefore, in FIG. 44B, DPL_TKIN in DPL_TK_SRP is updated. That is, DPL_TKIN of the new DPL_TK_SRP # 2 indicates TKI # 3 as indicated by arrow DT11, DPL_TKIN of DPL_TK_SRP # 3 indicates TKI # 4 as indicated by arrow DT12, and DPL_TKIN of DPL_TK_SRP # 4 is TKI DPL_TKIN of # 5 and DPL_TK_SRP # 5 indicates TKI # 6, respectively. Furthermore, it can be seen that DPL_TKIN of DPL_TK_SRP # 8 set to “Unused” sets TKI # 2 set to “Unused” as indicated by an arrow DT13.
[0165]
When the track is deleted, the DPL_TK_SRP that is in use is moved up to the head, but it can be seen that the corresponding TKI is set to unused while maintaining the original arrangement. As described above, since the TKI arrangement is fixed before and after editing, the processing load associated with the editing process can be reduced.
{17-9_40-4_45A, B} TKI assignment for recording tracks
Next, a case (case 2) in which a new track is recorded after a part of tracks is deleted will be described. 45 (a) and 45 (b) are diagrams showing how the “Unused” TKI and DPL_TK_SRP exist, and when the new TKI and DPL_TK_SRP are written here, the writing is performed. is there. In FIGS. 45A and 45B, when the case of assigning a new TKI to the “Unused” TKI is described, it has the same portions as those of FIGS. 28A to 28B cited. That is, the second, third, and fourth stages in FIGS. 45A and 45B are the same as the first, second, and third stages in FIGS. 28A and 28B. The difference is that Default_Playlist information including a plurality of DPL_TK_SRPs is described in the first row of FIG. In FIG. 45 (a), DPL_TK_SRP # 4 to DPL_TK_SRP # 8 are “Unused”, while TKI # 2, TKI # 4, TKI # 5, TKI # 7, TKI as shown in FIG. You can see that # 8 is “Unused”. In TrackManager, “Unused” TKI exists in a worm-eating state, but in the Default_Playlist information, “Unused” DPL_TK_SRP is summarized as described above. DPL_TK_SRP is DPL_TK_SRP other than “Unused”. This is because TKI does not perform such advance.
[0166]
Here, it is assumed that TrackD consisting of four AOBs is to be written. The TKI for each of the four AOBs is written in each of TKI # 2, TKI # 4, TKI # 7, and TKI # 8 set to “Unused” in TrackManager.
On the other hand, DPL_TK_SRP for these four AOBs is written in DPL_TK_SRP # 4 to DPL_TK_SRP # 7 in Default_Playlist information. Since these four AOBs constitute one track, DPL_TK_ATR for DPL_TK_SRP # 4 is "Head_of_Track", DPL_TK_SRP # 5, DPL_TK_SRP # 6 is DPL_TK_ATR is "Midpoint_of_Track", and DPL_TK_SRP # 7 is DPL_TK_SRP # TK End_of_Track ”is set.
[0167]
Also, DPL_TKIN for DPL_TK_SRP # 4 is set to TKI # 2, DPL_TKIN for DPL_TK_SRP # 5 is set to TKI # 4, DPL_TKIN for DPL_TK_SRP # 6 is set to TKI # 7, DPL_TKIN for DPL_TK_SRP # 7 is set to TKI # 8 Has been.
By setting DPL_TKIN and DPL_TK_ATR as described above, TKI # 2, TKI # 4, TKI # 7, and TKI # 8 are managed as the fourth track TrackD.
[0168]
In the above processing, “Unused” was written to the TKI, but TKI # 1, TKI # 2, TKI # 3, and TKI # 4 were not changed as in the case of FIG. It is the same.
{17-9_40-5_46A, B} For track integration (case 3)
Next, updating of Default_Playlist information when performing track integration (case 3) will be described. FIGS. 46A and 46B are diagrams assuming a case where tracks are integrated. This figure has the same part as FIG. 29 (a), (b) quoted when explaining the integration process of TKI. That is, the second, third, and fourth stages in FIGS. 46A and 46B are the same as the first and second stages in FIGS. 29A and 29B. 46 (a) and 46 (b), the difference is that Default_Playlist information is described, and DPL_TK_SRP # 8 included therein is set to “Unused”, and TKI # that is also set to “Unused”. It has a corresponding relationship with 2. In this figure, when the track integration processing as shown in FIG. 29 is performed on the AOB file and TKI, the contents of DPL_TK_SRP # 3 to DPL_TK_SRP # 6 are shifted one by one, and DPL_TK_SRP surrounded by a thick frame Copy the description content of # 7 to DPL_TK_SRP # 3. For TKI, update processing similar to that shown in FIG. 29 is performed.
[0169]
{17-9_40-6_47A, B} When dividing a track (case 4)
Next, update of Default_Playlist information when dividing a track (case 4) will be described.
47 (a) and 47 (b) are diagrams assuming a case where tracks are divided. This figure has the same parts as FIGS. 33A and 33B quoted when the division process for TKI is described. That is, the second level and the third level in the figure are the same as the first level and the second level in FIGS. 33 (a) and 33 (b). The difference is that in FIGS. 47A and 47B, Default_Playlist information is described, and DPL_TK_SRP # 8 included therein is set to “Unused”, and TKI # is also set to “Unused”. It has a corresponding relationship with 2. In this state, as in the case of FIG. 33, when TKI # 3 and AOB003.SA1 surrounded by a thick frame are divided into two, the order of DPL_TK_SRP # 3 to DPL_TK_SRP # 7 is lowered one by one, and Default_Playlist Move “Unused” DPL_TK_SRP in the information to DPL_TK_SRP # 3. DKI_TK_SRP # 3 after movement is associated with TKI # 2 obtained by the division. AOB002.SA1 associated with TKI # 2 originally stores the second half of AOB003.SA1, but DPL_TK_SRP # 2 exists before DPL_TK_SRP # 3 associated with TKI # 2. This DPL_TK_SRP # 2 is associated with TKI # 2-AOB002.SA1. That is, AOB002.SA1 and AOB003.SA1 store the latter half and the first half of the original AOB003.SA1, but DPL_TK_SRP # 2 and DPL_TK_SRP # 3 that specify them are AOB003.SA1, AOB002. Since the playback order is specified so that these AOB files are played back in the order of SA1, the second half and the first half of the original AOB003.SA1 are ordered in the order of the first half and the second half by specifying the playback order of DPL_TK_SRP. Will be played.
[0170]
{17-9_40-8} Application of editing process
By combining the above four editing operations, the operator can perform various editing operations. In other words, if there is a disc jockey announcement at the beginning of a track and you want to delete it, you can divide the announcement as a single track in the above track division process, and then delete that track. For example, only the disc jockey announcement can be partially deleted.
[0171]
The description of the navigation data has been described above, and then a playback device configured to play back such navigation data and presentation data will be described.
{48-1} Appearance of playback device
FIG. 48 is a diagram showing a portable playback device for the flash memory card 31 according to the present embodiment. In this figure, the playback apparatus includes an insertion slot into which the flash memory card 31 is inserted, a key panel for receiving key operations such as playback, forward search playback, reverse search playback, fast forward, rewind, and stop from the operator. And a liquid crystal display, and have the same appearance as a normal portable acoustic device. The key panel has a playlist key that accepts playlist / track selection and a skip to the beginning of the track [| <<Key>,“>> | key” to accept skip to the beginning of the next track, “>> key” to accept fast forward, rewind, forward search playback, reverse search playback, <<Key> When the still image is stored in the flash memory card 31, the Display key that accepts the operation to display the still image, the Rec key that accepts the recording operation from the operator, the Stereo / Monoral selection, and the sampling frequency selection Audio key to be received from the user, Mark key to receive the bookmark specification, Edit key to receive track editing and title input.
[0172]
{48-2} Improvements in portable playback device for flash memory card 31
The portable player of the flash memory card 31 is different from ordinary portable audio equipment in the following improvements (1) to (4). That is, in order to accept the Default_Playlist information, PlayList information, and track designation from the operator, a list of playlists and tracks is displayed on the liquid crystal display (1), and the playlists displayed in such a list are displayed. Or, a key assignment is made to designate an arbitrary track as a playback target or an editing target (2), and the track playback progress time is displayed on the liquid crystal display as the track playback progresses. (3) A jog dial used for setting a playback start time when performing a time search function or divisional editing is provided (4).
[0173]
{48-2_49_50} Details of improvement (2)
Details of the improvement (2) are as follows. FIG. 49 is a diagram showing an example of the display content of the liquid crystal display when the playlist is selected, and FIG. 50 is a diagram showing an example of the display content of the liquid crystal display when the track is selected. .
49, “DEFAULTPLAYLIST”, “PLAYLIST # 1”, “PLAYLIST # 2”, “PLAYLIST # 3” and “PLAYLIST # 4” are the default playlist stored in the flash memory card 31 and ASCII characters indicating the four playlists. Is a column. Further, “TRACK # 1”, “TRACK # 2”, “TRACK # 3”, “TRACK # 4”, and “TRACK # 5” in FIG. 50A are the default playlists stored in the flash memory card 31. An ASCII character string indicating the five tracks for which the playback order is specified. 49 and 50A, it is shown that these playlists and tracks with hatching are designated as playback targets or editing targets. When a track whose playback order is specified in the playlist is displayed in a list on the liquid crystal display and TRACK # 1 is designated as a playback target, the >> | key is pressed, as shown in FIG. Among the plurality of tracks displayed as a list, TRACK # 2 below is designated as a playback target. When TRACK # 2 is designated as a playback target and the >> | key is pressed, TRACK # 3 at the lower level of the multiple tracks displayed as a list is played back as shown in FIG. Specified as a target. With TRACK # 3 specified as the playback target | < When the <key is pressed, TRACK # 2, which is one level higher than the plurality of tracks displayed in a list, is designated as a reproduction target as shown in FIG. Like this >> | key, | <<Since one of the tracks is selected as a playback target in response to pressing of the key, when one of the tracks is selected as a playback target, the playback key is pressed as shown in FIG. For example, playback of the track is started, and when the Edit key is pressed, the track is designated as an editing target.
[0174]
{48-3_51} Details of improvement (4)
Next, the details of the improvement (4) will be described. FIG. 51 is a diagram showing an operation example of the jog dial. The jog dial accepts a rotation operation by the operator, and increases or decreases the playback elapsed time displayed on the liquid crystal display according to the rotation amount. For example, as shown in FIG. 51A, it is assumed that the reproduction start time is displayed as “00:00:20” on the liquid crystal display. In this case, as shown in FIG. 51 (b), if the jog dial is rotated counterclockwise, the reproduction start time decreases according to the amount of rotation and becomes “00:00:10”. As shown in FIG. 51C, if the jog dial is rotated clockwise, the reproduction start time increases according to the amount of rotation and becomes “00:00:30”.
[0175]
The reason why the playback time is increased or decreased is to specify an arbitrary playback time on the track. When the playback key is pressed by rotating the jog dial, the above {Formula 2 } Play AOB from the specified position according to {Formula 3}.
Further, in the division editing, the jog dial is used to finely adjust the division boundary when specifying an arbitrary reproduction start time as the division boundary.
[0176]
{52-1} Internal structure of playback device
Next, the internal configuration of the playback device will be described. FIG. 52 shows the internal structure of the playback device. In this figure, the playback apparatus includes a card connector 1 for connecting a flash memory card 31, a user interface unit 2 connected to a key panel and a jog dial, a RAM 3, a ROM 4, a playlist, and a list for displaying a list of tracks. AOB_FRAME is decrypted using a display frame, a liquid crystal display 5 having a playback elapsed time frame in which the playback elapsed time is displayed, an LCD driver 6 for driving the liquid crystal display, and a different FileKey for each AOB file. If descrambling of AOB_FRAME is performed by descrambler 7 and descrambler 7, AAC decoder 8 that obtains PCM data by decoding AOB_FRAME with reference to the ADTS header of AOB_FRAME, and AAC D / A conversion of PCM data obtained by decoding of decoder 8 and output to speaker via headphone terminal An A converter 9 and a CPU 10 that performs integration processing in the playback apparatus are provided. As can be seen from this hardware configuration, this playback device does not have a new configuration for processing TrackManager and Default_Playlist information. The TrackManager and Default_Playlist information are provided in the DPLI resident area 11, the PLI storage area 12, the TKI storage area 13, the FileKey storage area 14, the double buffer 15, and the ROM 4 that are secured in the RAM 3. A reproduction control program and an edit control program stored therein.
[0177]
{52-2} DPLI Resident Area 11
The DPLI resident area 11 is an area secured to make the Default_Playlist information connected to the card connector 1 and read from the flash memory card 31 resident.
{52_12} PLI storage area 12
The PLI storage area 12 is an area reserved for storing PlayList information selected by the operator and to be played back.
[0178]
{52-3} TKI storage area 13
The TKI storage area 13 is an area reserved for storing only the TKI corresponding to the AOB file to be reproduced among the plurality of TKIs included in the TrackManager, and has a data size for one TKI. Have
{52-4} FileKey storage area 14
The FileKey storage area 14 is an area reserved for storing only the FileKey corresponding to the AOB file to be reproduced among the plurality of FileKeys included in AOBSA1.KEY in the protect area.
[0179]
{52-5} Double buffer 15
The double buffer 15 sequentially inputs and stores cluster data (data stored per cluster) read from the flash memory card 31, and reads the encrypted AOB_FRAME from the stored cluster data. This is an input / output buffer used when an output process of sequentially outputting to the descrambler 7 is performed in parallel. The double buffer 15 sequentially releases the area occupied by the cluster that has been output as AOB_FRAME to a free area, and uses this free area for storing the newly read cluster, that is, the ring A recursive area is secured using a pointer.
[0180]
{52-5_53_54A, B} Input / output in the double buffer 15
FIG. 53 is a diagram showing how data input / output is performed in the double buffer 15. FIGS. 54A and 54B are diagrams showing how a cyclic area reservation using a ring pointer is performed.
In these figures, the arrow pointing to the lower left indicates a pointer for the write destination address of the cluster data, that is, the write destination pointer. A left-pointing arrow indicates a pointer for a read destination address of cluster data, that is, a read destination pointer. These pointers are used as ring pointers.
[0181]
{54-6_53} When the flash memory card 31 is connected to the card connector 1, the cluster data in the user data area of the flash memory card 31 is read from the flash memory card 31 as indicated by arrows w1 and w2. The read cluster data is sequentially stored in the double buffer 15 at the positions indicated by the write destination pointers WP1 and WP2.
[0182]
{52-7_54A} Of the AOB_FRAMEs included in the cluster data stored in this way, the read destination pointers (1) (2) (3) (4) (5) (6) (7) (8) (9) AOB_FRAME existing at the position indicated by is sequentially output to the descrambler 7 as indicated by arrows r1, r2, r3, r4, r5. Here, the cluster data 002 and 003 are stored in the double buffer 15, and the reading destination indicated by the reading destination pointer moves as shown in (1), (2), (3), and (4) in FIG. When 5 ▼ is reached, all the AOB_FRAMEs included in the cluster 002 have been read out, so the cluster 004 is newly read out and occupied by the cluster 002 as indicated by the arrow w6 in FIG. 54 (a). Overwrite existing area.
[0183]
{52-8_54B} When the reading destination indicated by the reading destination pointer moves as shown in (6) and (7) and reaches (9), all AOB_FRAMEs included in the cluster 003 are read out. Therefore, the cluster 005 is newly read out and overwritten on the area occupied by the cluster 003 as indicated by the arrow w7 in FIG. 54 (b). As described above, the output of AOB_FRAME and the overwriting of cluster data are repeated many times, and AOB_FRAME included in the AOB file is sequentially output to the descrambler 7 and the AAC decoder 8.
[0184]
{52-9_55 to 58} Reproduction control program stored in ROM4
Next, the reproduction control program stored in the ROM 4 will be described.
FIG. 55 is a flowchart showing a processing procedure of AOB file reading processing, and FIGS. 56, 57, and 58 are flowcharts showing a processing procedure of AOB_FRAME output processing.
[0185]
{52-9_55-1} In these flowcharts, the variable w is a variable that indicates each of a plurality of DPL_TK_SRPs, and the variable z is a respective AOB file, a corresponding TKI, and an AOB included therein. Is a variable for uniquely indicating. The variable y is a variable for designating each AOB_ELEMENT included in the AOB # z indicated by the variable z. The variable x is each of the AOB_ELEMENT # y indicated by the variable y. This variable indicates AOB_FRAME. First, the procedure of the AOB file reading process will be described with reference to FIG.
[0186]
{52-9_55-2} In step S1, the CPU 10 reads PlayListManager and displays a list of Default_Playlist information and PlayList information. In step S <b> 2, the CPU 10 waits for designation of whether to play the AOB according to either Default_Playlist information or PlayList information. Here, when Default_Playlist information is specified, the process proceeds from Step S2 to Step S3, and variable w is initialized (# w ← 1). In Step S4, DPL_TKIN associated with DPL_TK_SRP # w in Default_Playlist information is used. The designated TKI # z is specified, and only the TKI # z is read out to the TKI storage area 13. In step S5, an AOB file #z having the same number as TKI # z is specified. By the procedure so far, the AOB file to be played is finally specified. Since the identified AOB file is encrypted, the processes of step S6 and step S7 are subsequently performed to release the encryption of the AOB file. That is, in step S6, the protected area is accessed, and FileKey # z stored in File Key Entry # z having the same number as AOB file #z in the encryption key storage file is read. In step S <b> 7, the CPU 10 sets FileKey # z to the descrambler 7. With this setting, the FileKey is set to the descrambler 7, and thereafter, if AOB_FRAME included in the AOB file is sequentially input to the descrambler 7, the AOB_FRAME will be reproduced sequentially.
[0187]
{52-9_55-3} Thereafter, each cluster storing AOB files is read sequentially. In step S8, the “file first cluster number” for the AOB file #z in the directory entry is specified. In step S9, the CPU 10 reads the data stored in the cluster from the flash memory card 31. In step S10, it is determined whether or not the cluster number is described as FFF in the FAT value. If the FAT value is a value other than FFF, it is stored in the cluster designated by the FAT value in step S11. Read data. After such reading, the process proceeds to step S10. Here, when reading the data stored in any cluster and referring to the FAT value associated with that cluster, as long as any cluster number other than FFF is described in the FAT value, Steps S10 to S11 are repeated. As a result, the clusters designated by the FAT value are sequentially read out. If the cluster number is described as FFF in the FAT value, all the clusters constituting the AOB file #z have been read out, and the process proceeds from step S10 to step S12.
[0188]
{52-9_55-4} In step S12, the CPU 10 determines whether or not the variable #w matches the total number of DPL_TK_SRP. If they do not match, the process proceeds to step S13, and after incrementing the variable #w (# w ← # w + 1), the process proceeds to step S4. In step S4, TKI # z specified by DPL_TKIN # w of DPL_TK_SRP # w in Default_Playlist information is specified, and only that TKI # z is read out to TKI storage area 13. At this time, the TKI storage area 13 stores the TKI used so far, but the CPU 10 overwrites the TKI already stored in the TKI storage area 13 with the newly read TKI. By such overwriting, only the latest TKI is stored in the TKI storage area 13. If the TKI is overwritten in this way, the processing from step S5 to step S12 is repeated for the AOB file #z. If the processing of Step S5 to Step S12 is repeated and TKI and AOB files corresponding to all DPL_TK_SRP included in the Default_Playlist information are read, the variable #w and the total number of DPL_TK_SRP match, and Step S12 becomes Yes. This flowchart is terminated.
[0189]
{52-9_56_57_58} AOB_FRAME output processing
In parallel with the AOB file reading process, the CPU 10 performs an AOB_FRAME output process according to the flowcharts of FIGS. 56, 57, and 58. In this flowchart, “play_time” is a variable indicating the elapsed playback time, that is, the elapsed playback time, and the time in the time display frame of the liquid crystal display 5 is rewritten according to the update of this play_time. It is done. Also, play_data is the data length reproduced so far.
[0190]
{52-9_56-1} In step S21, the CPU 10 monitors whether the cluster data for the AOB file #z has been accumulated in the double buffer 15. This step S21 is repeated unless cluster data is accumulated, but if cluster data is accumulated, in step S22, #x and #y are initialized (# x ← 1, # y ← 1), and thereafter In step S23, AOB_FRAME # x in AOB_ELEMENT # y is detected from Data_Offset of BIT # z included in TKI # z in the cluster for AOB file #z. Here, 7 bytes from SZ_DATA are assumed to be occupied by the ADTS header, refer to the ADTS header, analyze that the data length indicated in the ADTS header is the audio data of the main unit, and And the audio data of the main body are read out and output to the descrambler 7. If the AOB_FRAME is decrypted by the descrambler 7 and decrypted by the AAC decoder 8, it will be reproduced as sound.
[0191]
{52-9_56-2} After detection, AOB_FRAME # x is output to the descrambler 7 in step S24. In step S25, the playback elapsed time play_time is incremented by the playback time corresponding to AOB_FRAME # x, and playback has been completed. The number of data play_data is incremented by the number of data corresponding to AOB_FRAME # x. Here, since the reproduction time length of AOB_FRAME is 20 msec, 20 msec is added to the reproduction elapsed time play_time.
[0192]
If the first AOB_FRAME is output to the descrambler 7, the ADTS header of AOB_FRAME # x is referred to in step S26 to identify where the next AOB_FRAME exists. In step S27, the variable #x is incremented (# x ← # x + 1), and the next AOB_FRAME is set to AOB_FRAME # x. In step S28, AOB_FRAME # x is input to the descrambler 7. Thereafter, in step S29, play_time is incremented by the reproduction time corresponding to AOB_FRAME # x, and play_data is incremented by the number of data corresponding to AOB_FRAME # x. After incrementing AOB_FRAME # x, in step S30, the CPU 10 determines whether #x has reached “FNs_1st_TMSRTE”. If #x does not reach “FNs_1st_TMSRTE”, it is checked in step S31 whether any key other than the Play key has been pressed, and then the process proceeds to step S26. Thereafter, the processes in steps S26 to S31 are repeated until #x reaches “FNs_1st_TMSRTE” or a key other than the Play key is pressed. If a key other than the Play key is pressed here, this flowchart is ended, and processing corresponding to the pressed key is performed. If the pressed key is a stop key, the playback process is stopped. If the pressed key is a pause key, the playback process is paused.
[0193]
{52-9_57-1} On the other hand, if #x reaches “FNs_1st_TMSRTE”, step S30 becomes Yes and the process proceeds to step S32 in FIG. In step S26 to step S30, all AOB_FRAMEs included in AOB_ELEMENT are input to descrambler 7. Therefore, in order to shift the processing target to the next AOB_ELEMENT, #y is incremented in step S32. , #X is initialized (# y ← # y + 1, # x ← 1).
[0194]
Thereafter, in step S33, the head address for AOB_ELEMENT # y is calculated with reference to TKTMSRT. Thereafter, the process consisting of step S34 to step S42 is performed. It can be said that the process of step S34-step S42 is the same as the process which consists of step S24-step S31 by the point which is the process which reads AOB_FRAME contained in AOB_ELEMENT one after another. Unlike the processing in steps S24 to S31, the loop processing end condition in the latter is that #x reaches “FNs_1st_TMSRTE”, whereas the loop processing end condition in the former is #x is “FNs_Middle_TMSRTE”. To reach. When #x reaches “FNs_Middle_TMSRTE” and the loop process including Step S34 to Step S42 is completed, Step S41 becomes Yes and the process proceeds to Step S43. In step S43, the CPU 10 increments #y and initializes #x (# y ← # y + 1, # x ← 1). Thereafter, in step S44, it is determined whether or not the variable y has reached a value equal to (TotalTMSRT_entry_Number-1) in TMS # _Header of TKI # z. If #y is smaller than (TotalTMSRT_entry_Number-1), AOB_ELEMENT # y has not yet reached the last AOB_ELEMENT, so the processing from step S32 to step S42 is continued by moving from step S44 to step S32. Do it. When #y reaches (TotalTMSRT_entry_Number-1), it is considered that the AOB_FRAME read processing has been completed up to the AOB_ELEMENT one before the last AOB_ELEMENT, so step S44 becomes Yes and the process proceeds to step S45 in FIG. .
[0195]
{52-9_57-2} The processes in steps S45 to S54 are the same as the processes in steps S33 to S42 described above in that each of the plurality of AOB_FRAMEs included in the last AOB_ELEMENT is read. The difference is that in the loop processing in steps S33 to S42, #x reaches “FNs_Middle_TMSRTE” in step S41, whereas the end condition of the loop processing is #x. In step S53, #x is “FNs_Last_TMSRTE”. In addition, the fact that Play_data indicating the data size read so far reaches SZ_DATA is the end condition of the loop processing.
[0196]
Until the condition of step S53 is satisfied, the processing of step S49 to step S54 is repeatedly performed. If this condition is satisfied, step S53 becomes Yes and the process proceeds to step S55. In step S55, the CPU 10 increments #z, then proceeds to step S21 (# z ← # z + 1), and waits for the next AOB file to be accumulated in the double buffer 15. If accumulated, the process proceeds from step S21 to step S22, and the process from step S22 to step S54 is repeated for the next AOB file. That is, the TKI specified by DPL_TKIN of the next DPL_TK_SRP is specified, and the AOB file corresponding to the TKI, that is, the AOB file having the same number as the TKI is specified. Then, access the protected area, identify the FileKey that has the same number as the TKI in the encryption key storage file, read the FileKey, set the FileKey to the descrambler, and then the same number as the TKI AOB_FRAME contained in the AOB file having the above is sequentially read and reproduced.
[0197]
{52-9_57-3_59} Update elapsed playback time
FIG. 59 is a diagram illustrating a state in which the elapsed playback time displayed in the time display frame of the liquid crystal display 5 increases as the variable Play_Time is updated. In this figure (a), the playback elapsed time is 00: 00: 00.000, but when the playback of AOB_FRAME # 1 ends, the time length of 20 msec of AOB_FRAME is added to the playback elapsed time to 00: 00: 00.020 Has been updated. When playback of AOB_FRAME # 2 is finished, the playback time is 00: 00: 040 when AOB_FRAME # 6 finishes playback at 00: 00: 00.040 by adding 20msec of AOB_FRAME to the playback elapsed time. It turns out that it is 00.120.
[0198]
The above is the whole picture of AOB_FRAME output processing. In step S31 of this flowchart, the processing of this flowchart is interrupted when a key other than the Play key is pressed, as described above, and there is a pause key or a stop key as such a key other than the Play key. However, the processing of the flowcharts of FIGS. 56, 57, and 58 is interrupted when a key other than the pause key or stop key is pressed to cause the playback device to perform special playback. Then, processing corresponding to the pressed key is executed. Thereafter, the time search function is executed by operating the jog dial after the processing procedure of the CPU 10 when the >> key is pressed and the forward search reproduction is executed and the pause key or stop key is pressed. The processing procedure of the CPU 10 in this case will be described.
[0199]
{52-10_60} Forward search playback
FIG. 60 is a flowchart showing the processing procedure of the CPU 10 when performing forward search reproduction. This flowchart is executed by the CPU 10 when the key is pressed by the operator and Steps S31, S42, and S54 in FIGS. 56, 57, and 58 are Yes.
[0200]
In step S <b> 61, the CPU 10 inputs from AOB_FRAME # x of AOB_ELEMENT # y to x + f (t) −1 to the descrambler 7. Here, “t” is the intermittent playback time, and f (t) is the number of frames corresponding to the intermittent playback time, and d (t) is the number of data corresponding to the intermittent playback time. Play_time indicating the elapsed playback time and play_data indicating the number of played data are t: intermittent playback time, f (t): number of frames corresponding to intermittent playback time, d (t): number of data corresponding to intermittent playback time Updated based on (x ← x + f (t), play_time ← play_time + t, play_data ← play_data + d (t) In general, intermittent playback time is equivalent to 240 milliseconds (playback time length of 12 AOB_FRAMEs) To do.)
[0201]
{52-10_60-1_61A, B} FIGS. 61 (a) and 61 (b) are diagrams showing how the playback elapsed time is incremented during forward search playback. FIG. 61A shows an initial state of the elapsed playback time, and indicates that the playback time is AOB_FRAME # 1 of AOB_ELEMENT # 51. It can be seen that the playback elapsed time in this case is 00: 00: 01.000. Here, as intermittent playback times, the first to twelfth AOB_FRAMEs are input to the descrambler 7 and 240 ms, which is the time length of 1AOB_FRAME, is added to the playback elapsed time. ), The elapsed playback time is 00: 00: 01.240.
[0202]
{52-10_60-2} After updating these, in step S63, the CPU 10 compares AOB_FRAME # x after increment with the total number of frames of AOB_ELEMENT # y, and AOB_FRAME # x after increment is AOB_ELEMENT # Determine if it exists in y. Specifically, the number of AOB_ELEMENT frames at the beginning of the AOB is “FNs_1st_TMSRTE”, the number of intermediate frames is “FNs_Middle_TMSRTE”, and the number of last frames is “FNs_Last_TMSRTE”. Judgment is made by comparing with #x. If the updated AOB_FRAME # x does not exist in the AOB_ELEMENT, it is determined in step S64 whether an AOB_ELEMENT subsequent to the AOB_ELEMENT # y exists. If AOB_ELEMENT # y is the last AOB_ELEMENT and there is no subsequent AOB_ELEMENT, step S64 is No and the processing of this flowchart is terminated. If there is a subsequent AOB_ELEMENT, AOB_FRAME # x in step S65 The number of frames in AOB_ELEMENT # y is decremented and #y is updated in step S66 (y ← y + 1), thereby converting AOB_FRAME # x to the frame position of AOB_FRAME in the subsequent AOB_ELEMENT # y. If the updated AOB_FRAME # x exists in the AOB_ELEMENT, step S65 to step S66 are skipped and the process proceeds to step S67.
[0203]
{52-10_60-3} Subsequently, AOB_FRAME # x, reproduction elapsed time play_time, and number of reproduced data play_data are updated according to the intermittent skip interval. Here, assuming that the time corresponding to the intermittent skip interval is skip_time (2 seconds), the number of frames corresponding to the intermittent skip interval skip_time is f (skip_time), and the number of data corresponding to the intermittent skip interval skip_time is d (skip_time). In S67, AOB_FRAME # x, playback elapsed time play_time, and number of played data play_data are updated using these (x ← x + f (skip_time), play_time ← play_time + skip_time, play_data ← play_data + d (skip_time)).
[0204]
{52-10_60-4_61C} As shown in FIG. 61 (c), it is assumed that an intermittent skip interval is added to AOB_FRAME # x indicating the frame position in AOB_ELEMENT # 51. If #x after this addition exceeds the number of frames of AOB_ELEMENT # 51, AOB_ELEMENT is updated to the next AOB_ELEMENT, and by subtracting the number of frames of AOB_ELEMENT # 51 from #x after addition, AOB_FRAME # x is Convert to frame position in AOB_ELEMENT # 52. In this case, AOB_ELEMENT # y becomes AOB_ELEMENT # 52, and the playback elapsed time becomes 00: 00: 03.240 by adding 2.000 to 00: 00: 01.240. AOB_FRAME # x is AOB_FRAME # 62 (= (3240 msec-2000 msec) / 20 msec) in AOB_ELEMENT # 52.
[0205]
{52-10_60-5_61 (d)} Thereafter, if AOB_FRAME # 62 in AOB_ELEMENT # 52 is input to the descrambler 7, the playback elapsed time is 00: 00: 03.240 as shown in FIG. 61 (d). Adding 0.240 to 00: 00: 03.480.
If the update according to the intermittent skip time is performed in step S67, the processing of step S68 to step S71 is performed. The processing from step S68 to step S71 is the same as the processing from step S63 to step S66, and it is determined whether AOB_FRAME after addition of the number of frames corresponding to the intermittent skip interval skip_time is present in AOB_ELEMENT # y. If it exists, the next AOB_ELEMENT is set to AOB_ELEMENT # y, and AOB_FRAME # x is converted to the frame position in the new AOB_ELEMENT # y.
[0206]
If AOB_FRAME # x and AOB_ELEMENT # y are incremented in accordance with the intermittent playback time and intermittent skip time, in step S72, the CPU 10 refers to TKTMSRT to calculate the head address for AOB_ELEMENT # y, and in step S73. AOB_FRAME # x is detected by starting the search for the ADTS header from the head address in AOB_ELEMENT # y. In step S74, it is determined whether or not a key other than the forward skip key has been pressed. In step S61, the AOB_ELEMENT # y from AOB_FRAME # x to x + f (t) -1 is descrambled. And repeat the process from step S62 to step S73 again.
[0207]
Through the above processing, AOB_FRAME # x and AOB_ELEMENT # y are incremented and the playback position advances. Thereafter, when the reproduction key is pressed by the operator, step S74 becomes No and the processing of this flowchart is terminated.
{52-11} Executing time search function
Processing when the time search function is performed will be described. A list of tracks in the Default_Playlist information is displayed, and designation of an arbitrary track is accepted. When a track is specified and the jog dial is operated, the playback start time is updated. When the playback key is pressed after the playback start time has increased or decreased, the playback specified time is specified as Jmp_Entry (seconds). On the other hand, it is determined whether the designated track consists of a plurality of AOBs or a single AOB. In the case of a single AOB, AOB_ELEMENT # y and AOB_FRAME # x satisfying {Formula 2} are calculated. If AOB_ELEMENT # y and AOB_FRAME # x satisfying {Formula 2} are calculated, a search for AOB_FRAME # x is started from the y + 2th address in the TKTMSRT corresponding to this AOB, and the xth AOB_FRAME is If searched, playback starts from this xth AOB_FRAME.
[0208]
{52-12}
In the case of a plurality of AOBs, AOB # n, AOB_ELEMENT # y and AOB_FRAME # x satisfying {Formula 3} are calculated. If AOB # n, AOB_ELEMENT # y, and AOB_FRAME # x satisfying {Formula 3} are calculated, the search for AOB_FRAME # x is started from the y + 2th position in the TKTMSRT corresponding to this AOB # n. If the xth AOB_FRAME is searched, playback starts from this xth AOB_FRAME.
[0209]
Next, a case will be described in which playback is started from an arbitrary playback time in an AOB in which FNs_1st_TMSRTE in BIT is 80 frames, FNs_Last_TMSRTE is 50 frames, and FNs_Middle_TMSRTE is 94 frames.
{52-13_62A, B}
Here, as a specific example when the time search function is performed, a description will be given of how to specify the AOB_ELEMENT to start playback and the frame position to start playback when the playback start time is specified by the jog dial. To do. FIG. 62 is a diagram showing a specific example when the time search function is performed. Here, as shown in FIG. 62 (a), with the playback device held and a certain AOB designated as a playback target, the jog dial is rotated by the thumb of its right hand, and playback start time = 00: 04: 40.000 (= 280.00sec) is specified. When the BIT in the TKI for this AOB has the contents shown in FIG. 62B, applying playback start time = 00: 04: 40.000 (= 280.00 sec) to {Equation 2}
280sec = (FNs_1st_TMSRTE + FNs_middle_TMSRTE · y + x) × 20msec
= (80 + 94 ・ 148 + 8) x 20msec
Therefore, AOB_FRAME with y = 148 and x = 8 is obtained as AOB_ELEMENT # y and AOB_FRAME # x satisfying {Formula 2}.
[0210]
Since y = 148 was identified in this way, if you get the entry address of y + 2nd AOB_ELEMENT # 150 (= 148 + 2) from TKTMSRT and start playback from the 8th AOB_FRAME from here, Playback can be started from playback elapsed time = 00: 04: 40.000 (= 280.00 sec).
{52-14_63_64_65}
This is the end of the description of the processing content of the CPU 10 when the Play key is pressed. Next, the edit control program stored in the ROM will be described. This editing control program is executed when the Edit key is pressed, and FIG. 63, FIG. 64, and FIG. 65 show the processing procedure. Hereinafter, the processing content of the editing control program will be described with reference to these flowcharts.
[0211]
{52-14_63-1} Edit control program
If the Edit key is pressed, in step S101 in FIG. 63, a dialog screen is displayed that presents the operator with typical editing operations such as deletion, division, and integration, and then in step S102, the dialog screen is displayed. It is determined whether the process for is specified. Here, in the operation of the dialog screen, the >> | <<The keys are used as keys for accepting up / down cursor operations, that is, as up / down cursor keys. When the deletion process is designated, the process proceeds to a loop process including steps S103 and S104. In step S103, the >> | <<It is determined whether or not the key has been pressed. In step S104, it is determined whether or not the edit key has been pressed. >> | < If the <key is pressed, the process moves from step S103 to step S105, and the designated track is designated as an editing target. On the other hand, if the edit key is pressed, it is determined that the track to be deleted is specified, and the process shown in FIG. 44 is performed, and TKI_BLK_ATR of TKI for the specified track is set to “Unused”. Delete the track.
[0212]
{52-14_63-2} Integrated editing process
When integrated editing is designated, the process proceeds from step S102 to a loop process including steps S107 to S109. In the loop process consisting of steps S107 to S109, the >> | <<Key presses and edit key presses are accepted. >> ||, | < If the <key is pressed, the process moves from step S107 to step S110, and a highlighted display is performed for the designated track. If the edit key is pressed, step S108 becomes Yes and the process proceeds to step S111. In step S111, the track designated by the cursor key is designated as an editing target, and the process again proceeds to a loop process consisting of steps S107 to S109.
[0213]
If the editing target of the second track is specified, step S109 becomes Yes and the process proceeds to step S112. In step S112, by referring to the TKI BIT for the preceding track and the succeeding track, the AOBs arranged at the end and the head of both tracks (if AOBs are also arranged before and after them, before and after them) It is determined whether the type of AOB) is Type1 or Type2.
[0214]
If the type of each AOB is found, it is determined in step S113 which of the arrangement patterns shown in the arrangement image of each type of AOB corresponds. If it corresponds to any one of the arrangement patterns of FIGS. 32A to 32D and it is clear that three Type 2 AOBs are not continuous even after integration, the preceding track and the subsequent track are set as one track in step S115. To integrate. That is, the operations shown in FIG. 46 are performed on the TKI and DPL_TK_SRP associated with these, and the TKI_BLK_ATR of the TKI is rewritten to integrate a plurality of tracks selected as operation targets into one track. If none of the arrangement patterns shown in FIGS. 32A to 32D corresponds to three Type 2 AOBs after integration, underflow may occur in the integrated track in step S114. A message is displayed and the integration process is interrupted.
[0215]
{52-14_64-1} Track division processing
When the division of the track is designated, the process proceeds from step S102 to a loop process including steps S116 to S117. In the loop processing consisting of step S116 to step S117, the >> | key, <<Key presses and edit key presses are accepted. >> ||, | < If the <key is pressed, the process moves from step S116 to step S118, and the designated track is designated as an editing target. If the edit key is pressed, step S117 becomes Yes and the process proceeds to step S119. In step S119, the track designated by the cursor key is designated as an editing target. Thereafter, in step S120, reproduction of the track designated for division is started, and depression of the Mark key is accepted in step S121. When the Mark key is pressed, the reproduction of the track is paused, and the process proceeds to a loop process consisting of steps S122 to S123. In step S122, a rotation operation for the jog dial is accepted, and when the rotation operation is performed for the jog dial, the reproduction start time is increased or decreased in accordance with the rotation operation in step S124. Thereafter, the process proceeds again to the loop process including Steps S122 to S123. If the edit key is pressed while the reproduction start time is increased or decreased by the rotation operation, the process proceeds from step S123 to step S125, and in step S125, the reproduction time when the edit key is pressed is designated as a division boundary (note that When specifying the dividing boundary, an undo function (cancellation of editing) is possible.) Thereafter, the process described with reference to FIG. 47 is performed in step S126, and DPLI and TKI are updated to divide the track.
[0216]
{52-14_65-1} Playlist setting editing process
When playlist setting editing is designated, the process proceeds to the flowchart of FIG. In this flowchart, the variable k is a variable for designating each track whose playback order is defined by the playlist to be set. In the flowchart of FIG. 65, first, in step S131, 1 is set to this variable k. After the setting, the process proceeds to a loop process consisting of step S132 to step S134. In the loop process consisting of step S132 to step S134, the >> | <<Pressing the key, pressing the edit key, and pressing the stop key are accepted. >> | key, | < If the <key is pressed, the process proceeds from step S132 to step S135, and the >> | < Specifies the track indicated by the <key. If the edit key is pressed, step S133 becomes Yes and the process proceeds to step S136. In step S136, the track designated by the editing key is specified as the track to be reproduced k-th. Thereafter, in step S137, the variable k is incremented, and the process proceeds to the loop process of steps S132 to S134. By repeating such processing, the second track, the third track, and the fourth track are sequentially identified. In this way, when the stop key is pressed in a state where a plurality of tracks to be reproduced are specified in the newly created playlist, the process proceeds from step S134 to step S138, and is associated with these. PlayList information including PL_TK_SRP that identifies the TKI is generated.
[0217]
(Recording device)
{66-1} Recording device
Next, an example of the recording device of the flash memory card 31 will be described. FIG. 66 is a diagram showing an example of a recording device of the flash memory card 31. As shown in FIG. The recording device in this figure is capable of communication via the Internet, and when the SD_Audio directory is encrypted through electronic music distribution and transmitted via a communication line, or audio data through electronic music distribution. This is a general-purpose personal computer that can receive transport streams when they are distributed.
[0218]
{67-1} Recording device hardware configuration
FIG. 67 is a diagram illustrating a hardware configuration of the recording apparatus. In this figure, the recording device is input from a microphone, a card connector 21 for connecting a flash memory card 31, a RAM 22, a fixed disk device 23 storing a recording control program for performing integrated control of the recording device, and a microphone. A / D converter 24 for A / D converting voice to obtain PCM data, ACC encoder 25 for obtaining AOB_FRAME by encoding PCM data per unit time and adding ADTS header, and each AOB file The scramble unit 26 that encrypts AOB_FRAME using each FileKey, and the SD_Audio directory is encrypted through electronic music distribution and transmitted via a communication line, or audio data through electronic music distribution When the transport stream is transmitted via a communication line, the audio data transport stream is It has a modem device 27 for receiving, a CPU 28 for performing integrated control in the recording device, a keyboard 29 for receiving operations from an operator, and a display 30.
[0219]
{67-2} Input route RT1 to RT4
When the SD_Audio directory to be written to the data area and the protected area is transmitted through the communication line in an electronic music distribution, when the recording apparatus receives these properly, the recording device of the flash memory card 31 What is necessary is just to write in a data area and a protection area. However, if the audio data transport stream itself is transmitted by electronic music distribution instead of the SD_Audio directory, or if it is input to the recording device in the PCM data state, it is input to the recording device in the original sound state. In this case, the recording device writes the audio data transport stream to the flash memory card 31 through the following four input paths.
[0220]
When the recording apparatus in the figure stores the audio data transport stream in the flash memory card 31, the input path of the audio data transport stream is the input path RT1, the input path RT2, the input path RT3, and the input shown in FIG. There is route RT4.
{67-3} Input path RT1
The input path RT1 is an input when the SD_Audio directory is encrypted through electronic music distribution and transmitted via a communication line, or when an audio data transport stream is transmitted via a communication line. In this case, the AOB_FRAME included in the transport stream is encrypted by using different FileKeys for each belonging to one AOB. Since there is no need to re-encrypt and encode the encrypted transport stream, the SD_Audio directory or the audio data transport stream is stored in the RAM 22 in an encrypted state.
[0221]
{67-4} Input path RT2
The input path RT2 is an input path when sound is input from the microphone. In this case, the A / D converter 24 is caused to perform A / D conversion on the voice input from the microphone to obtain PCM data. Then, AOB_FRAME is obtained by causing the AAC encoder 25 to encode the PCM data and adding an ADTS header. Thereafter, the AOB_FRAME is encrypted by using the FileKey for each AOB file in the scramble unit 26, thereby obtaining encrypted audio data. Thereafter, the audio data is stored in the RAM 22.
[0222]
{67-5} Input path RT3
The input path RT3 is an input path when PCM data read from the CD is input to the apparatus. Since the PCM data is input in the state, the PCM data is input to the AAC encoder 25 as it is. AOB_FRAME is obtained by causing the AAC encoder 25 to encode the PCM data input in this manner and adding an ADTS header. Thereafter, the AOB_FRAME is encrypted using the FileKey for each AOB_FRAME by the scramble unit 26, thereby obtaining the encrypted audio data. Thereafter, the audio data is stored in the RAM 22.
[0223]
{67-6} Input path RT4
The input path RT4 is an input path for writing the transport stream input through the three input paths RT1, RT2, RT3 to the flash memory card 31.
With the storage of the audio data, TKI and Default_Playlist information are generated. As in the case of the playback device, the functional entity of the recording device is also a recording program recorded in the ROM. That is, the processing unique to this embodiment, such as AOB recording, TrackManager, and PlayListManager recording, is realized by a recording program recorded in the fixed disk device.
[0224]
{67-7_68} Recording process procedure
Hereinafter, the processing procedure of the recording process when the transport stream is written to the flash memory card 31 in the input paths RT1, RT2, RT3, RT4 will be described with reference to the flowchart. FIG. 68 is a flowchart showing the processing procedure of the recording processing. Variables cited in this flowchart include Frame_Number and Data_Size. Frame_Number is a variable for managing the total number of AOB_FRAMEs recorded in the AOB file so far, and Data_Size is a variable for managing the data size of AOB_FRAME recorded so far in the AOB file.
[0225]
When this flowchart is executed, the CPU 28 creates DefaultPlaylist and TrackManager in step S200, and initializes variables #z and #w in step S201 (z ← 1, w ← 1). In step S202, an AOB file #z is created and stored in the data area in the flash memory card 31. In this state, the file name, file extension, and first cluster number of the AOB file #z are set in the directory entry of the SD_Audio directory in the data area. In subsequent step S203, CPU 28 creates TKI # z and stores it in TrackManager. In step S204, CPU 28 creates DPL_TK_SRP # w and stores it in DefaultPlaylist information. Thereafter, in step S205, the variable #y is initialized (y ← 1), and in step S206, each of Frame_Number and Data_Size is initialized (Frame_Number ← 0, Data_Size ← 0).
[0226]
In step S207, the CPU 28 determines whether or not the input of the audio data transport stream to be written to the AOB file #z has been completed. If the audio data transport stream encoded by the AAC encoder 25 and encrypted by the scramble unit 26 is stored in the RAM 22 one after another, and it is necessary to continue writing the cluster data, step S207 is No and step S209 is performed. Migrate to In step S209, the CPU 28 determines whether or not the AAC audio data for the cluster size has been accumulated in the RAM 22. If cluster data is stored in the RAM 22, step S209 is Yes, the process proceeds to step S210, the AAC audio data having the cluster size stored in the RAM 22 is written in the flash memory card 31, and then the process proceeds to step S211. If the accumulation of cluster data has not been completed, step S210 is skipped and the process proceeds to step S211. In step S211, the CPU 28 increments Frame_Number (Frame_Number ← Frame_Number + 1), and increments Data_Size by the data size of the AOB_FRAME. After such an update, it is determined in step S212 whether or not Frame_Number has reached the number of frames defined as “FNs_Middle_TMSRTE”. Here, since “FNs_Middle_TMSRTE” is a value corresponding to the sampling frequency when the audio data transport stream is encoded, when Frame_Number reaches “FNs_Middle_TMSRTE”, step S212 is Yes, but so If not, step S212 is No and the process proceeds to step S207. Thereafter, step S207 to step S212 are repeated until step S207 and step S212 become Yes.
[0227]
When Frame_Number reaches “FNs_Middle_TMSRTE” and Step S212 becomes Yes, the process proceeds from Step S212 to Step S213, Data_Size is stored in TTK # RT of TKI # z as TMSRT_entry # y for AOB_ELEMENT # y, and ## in Step S214 After incrementing y (y ← y + 1), it is determined in step S215 whether the variable y has reached 252 or not. Here, the value 252 is a value indicating the total number of AOB_ELEMENTs that can be stored in one AOB. If the variable y does not reach 252, the process proceeds to step S216. In step S216, it is determined whether or not the silent state has continued for a predetermined time or more and the audio data has reached the boundary between tracks. If there is no silent state, the processing from step S206 to step S215 is repeated. When the variable y reaches 252 or when the silent state continues for a predetermined time or longer, one of Step S215 and Step S216 becomes Yes, and the process proceeds to Step S217 to increment the variables #z and #w. (Z ← z + 1, w ← w + 1). Thereafter, the process from step S202 to step S216 is repeated for incremented #z. As a result of such repetition, AOBs including a plurality of AOB_ELEMENTs are written to the flash memory card 31 one after another.
[0228]
Here, when the transmission of the audio data transport stream from the AAC encoder 25, the scrambler 26, and the modem device 27 is completed, the input of the audio data transport stream to be written to the AOB file #z is completed. Step S207 results in Yes, and the process proceeds to Step S208. In step S208, the CPU 28 stores Data_Size in TTK # RT of TKI # z as TMSRT_entry # y for AOB_ELEMENT # y, and stores the audio data accumulated in the RAM 22 in the AOB file corresponding to AOB # z. The process ends.
[0229]
The audio data transport stream encrypted by the above processing is stored in the flash memory card 31, and the FileKey for releasing this encryption is stored in the protected area by the following processing. The
In the case of the input paths RT2 and RT3, every time encoding of one AOB is started, the CPU 28 generates a different FileKey, sets it in the scrambler 26, and causes the scrambler 26 to perform encryption with the FileKey. At the same time, these FileKeys are stored after FileKey Entry of the encryption key storage file existing in the protected area.
[0230]
On the other hand, in the case of the input path RT1, an AOB file, a file storing TKMG, a file storing PLMG, and an encryption key storage file storing a different FileKey for each AOB are transmitted from an electronic music distribution provider. The CPU 28 receives them, writes the AOB file, the file storing the TKMG, and the file storing the PLMG in the user data area, and writes the encryption key storage file storing a different FileKey for each AOB in the protected area.
[0231]
As described above, according to the present embodiment, since the files storing the AOB are encrypted with different encryption keys, the encryption key used for encrypting one file was decrypted and exposed. However, the AOB that can be decrypted by the decryption is only the AOB stored in one file, and does not affect the AOB stored in the other file. Loss when the encryption key is exposed can be minimized.
[0232]
In addition, the said embodiment was only demonstrated as an example of a system which can anticipate the best effect in the present condition. The present invention can be implemented and modified without departing from the gist thereof. Specifically, the following modifications (a) to (f) are possible.
(A) In the present embodiment, the recording medium has been described as a semiconductor memory (flash memory card). However, the present invention is not limited to this, and can be replaced with an optical disk such as a DVD-RAM or a hard disk.
[0233]
(B) In the present embodiment, AAC is used as music data, but the present invention is not limited to this, and even MP3 (MPEG 1 Audio Layer 3), Dolby-AC3, DTS (Digital Theater System), etc. Good.
(C) TKMG and PLMG files are not distributed via electronic music distribution, but TKMG and PLMG information is stored as AOB files and different encryption keys for each AOB. It may be distributed together with the encryption key storage file, and the TKMG and PLMG may be obtained by processing the information that is the source of the TKMG and PLMG in the recording device, and recorded on the flash memory card.
[0234]
(D) For convenience of explanation, the recording device and the playback device are separate devices, but the portable playback device may have the function of the recording device, or the personal computer type recording device may have the function of the playback device. May be. In addition to these portable playback devices and personal computer recording devices, communication devices that can download content from a network may have the functions of these playback devices and recording devices. For example, a mobile phone that can be accessed via the Internet is provided with the functions of the playback device and recording device described in the first embodiment, and contents downloaded by the mobile phone via a wireless network are added to the first embodiment. As shown, it may be stored in the flash memory card 31. Further, in the present embodiment, the recording device has the modem device 27 for connection to the Internet. However, instead of this, the recording device may have a terminal adapter or the like for connecting to the ISDN line. Good.
[0235]
(E) The procedure described with reference to the flowcharts of FIGS. 55 to 58, 60, 63 to 65, and 68 is realized by an execution format program, and this is recorded on a recording medium for distribution and sales. You may make it a target. Such a recording medium includes an IC card, an optical disk, a flexible disk, and the like, and the machine language program recorded on these is used by being installed in a general-purpose computer. The general-purpose computer sequentially executes the installed execution format program to realize the functions of the playback device and the recording device shown in the present embodiment.
[0236]
(F) In the present embodiment, a plurality of AOBs and a plurality of FileKeys are stored in the flash memory card 31, but one AOB and one FileKey may be stored in the flash memory card 31. Alternatively, the AOB AOB may be stored in the flash memory card 31 without encrypting the AOB.
(Second Embodiment)
The second embodiment relates to an improvement of how to store a still image to be displayed together with the AOB file shown in the first embodiment.
[0237]
{69-1} The hierarchical structure of the flash memory card in the second embodiment
FIG. 69 is a diagram showing a hierarchical structure of the flash memory card 31 according to the present embodiment. The difference from the hierarchical structure of the first embodiment is that, in the second embodiment, a POB group is newly added to presentation data, and a POBManager is newly added to navigation data. These POB groups are still image data in JPEG (Joint Photographic Experts Group) format and are referred to by PlayListManager and TrackManager. POBManager is management information describing how these POBs are referred to by PlayListManager and TrackManager.
[0238]
{69-1_70A-1} Configuration of user data area in the file system layer
Since new information elements have been added to the presentation data and navigation data, the internal structures of the user data area and the protect area in the file system layer have been modified as shown in FIGS. The difference between this figure and the user data area of the first embodiment shown in FIG. 8A is that files such as POBXXX.JPG and POBXXX.SP1 are added, and a file called POB000.POM is added. It is a point.
[0239]
POBXXX.JPG and POBXXX.SP1 correspond to the POB group shown in FIG. 69, and POB000.POM corresponds to POBManager. The difference between POBXXX.JPG and POBXXX.SP1 is the presence or absence of copyright. The former is simply a file containing JPEG still image data, while the latter is a file that is encrypted to protect the copyright of the still image. It is an abbreviation for “Secure Picture” and it is clear that there is a need for copyright protection.) Still image data such as family photos and souvenir photos taken by the user is recorded on the flash memory card exclusively for personal enjoyment, and there is no need to be sensitive to copyright protection. Therefore, it is sufficient to store it in the flash memory card in the former form, but the artist's photos and illustrations distributed by electronic music distribution are creations created by the artist as well as music contents, and the user copies it. Therefore, the copyright may be infringed, so that the latter form is stored in the flash memory card. Numerical values such as 001, 002, and 003 attached to POBXXX.SP1 and POBXXX.JPG in the figure are POB numbers assigned to the respective POBs, and a plurality of POBs are uniquely specified by these POB numbers.
[0240]
{69-2_70B-1} Configuration of user data area in the file system layer
FIG. 70B is a diagram showing the configuration of the protect area in the second embodiment. Compared to the configuration of the protection area shown in FIG. 8B, a new encryption key storage file POBSP1.key is added to the protection area. This is a file storing Filekey for decrypting POBXXX.SP1 in FIG. 70A. When reading POBXXX.SP1, Filekey must be extracted from this file.
[0241]
In electronic music distribution, a music company's server computer holds the SD_Audio directory shown in FIGS. 70A and 70B, and compresses the SD_Audio directory when a purchase request for the music content is issued by a consumer. After encryption, the SD_Audio directory is transmitted to the consumer who has issued the purchase request. When the computer owned by the consumer receives this SD_Audio directory, the directory is decrypted and decompressed to obtain the SD_Audio directory. The track (AOB) and the still image (POB) corresponding to this track are downloaded from the server computer of the music company, and the computer owned by the consumer uses the flash memory card 31 in FIG. The SD_Audio directory shown in b) may be created.
[0242]
{69-3_71A, B, C-1} POBXXX.JPG, POBXXX.SP1 internal configuration
Next, the internal structure of POBXXX.JPG and POBXXX.SP1 will be described. FIG. 71A shows the internal structure of POBXXX.JPG. In this figure, POBXXX.JPG includes unencrypted still image data and has the same file structure as a normal JPEG file.
[0243]
FIG. 71 (b) shows the internal structure of POBXXX.SP1. As shown in the figure, POBXXX.SP1 is composed of POB_Header (POB_H) and encrypted JPEG still image data.
A broken lead line hp1 shows the internal configuration of POB_H. As shown in this figure, POB_H indicates the identification number of the POB file, POB_ID set to the 2-byte length value “FFE0”, a 1-byte reserved area, and the entity encrypted in POBXXX.SP1 It consists of a 1-byte length POB_ATR indicating whether or not a portion exists and a 4-byte length POB_SZ indicating the data length of the POB.
[0244]
Since there is an encrypted entity part in this POBXXX.SP1, POB_ATR is set to "0" indicating "entity exists", but there is no encrypted entity part in POBXXX.SP1, Some of them store file paths for files that store still image data. FIG. 71 (c) is a diagram showing an example of a POB file that stores a file path instead of an encrypted entity part. “Photo001.JPG” of “\ DCIM \ Ctg_001 \ photo001.JPG” is a file containing still image data taken by a digital still camera, and indicates a file path for the file. When such a directory path and file name are specified in the POB file, it is recorded in “photo001.JPG” of “\ DCIM \ Ctg_001 \ photo001.JPG” according to the description in the POB file. Still image data is indirectly referenced. In POBXXX.SP1, POB_ATR in POBManager is set to “1” indicating “no entity”.
[0245]
For example, a device driver dedicated to a digital still camera requires a flash memory card to record still image data shot by a digital still camera in a specific file and store the file in a specific directory. Even so (in the example of FIG. 71 (c), the device driver dedicated to the digital still camera requests to store in \ DCIM \ Ctg_001 \ photo001.JPG), the POB file in FIG. 71 (c) Specifies a JPG file containing still image data via the reference file path, so that still image data captured by a digital still camera is stored in a specific file or a specific directory. Still images can be displayed together with the playback of music content.
[0246]
This is the end of the description of the presentation data in the second embodiment.
{72-1} About PlayListManager and TrackManager
POBXXX.JPG and POBXXX.SP1 in the presentation data are displayed in synchronization with the reproduction of the track shown in the first embodiment. In order to realize the synchronized display with the track, the PlayListManager and the TrackManager in the second embodiment have the configuration shown in FIG. FIG. 72 is a diagram showing a detailed configuration of PlayListManager and TrackManager in the second embodiment. The difference between the configuration of the PlayListManager and TrackManager of the first embodiment shown in FIG. 17 and FIG. 17 is the internal configuration of Default Playlist General Infomation (DPLGI) and Playlist General Infomation (PLGI) that have not been clarified in FIG. It is clear that TKI_POB_ATR and 20 TKI_POB_SRP are newly provided in the internal structure of TKGI.
[0247]
{72-2} About DPLGI
The default playlist overall information (DPLGI) includes a DPLI_ID field in which an ID for uniquely identifying the DPLI is described, a DPLI_TK_Ns field in which the number of tracks referred to from the DPLI is described, as indicated by a dashed lead line h61, The DPLI_PB_TM field, the DPLI_POB_ATR field, and 60 DPLI_POB_SRP fields in which the total playback time of all tracks referred to from the default playlist is described in milliseconds.
[0248]
{72-3} About PLGI
The entire playlist information (PLGI) can describe the PLI_ID field in which an ID that uniquely identifies the PLI is described, and the number of tracks referenced from the PLI, as shown by the broken lead line h62, and a maximum of 99 tracks. The PLI_TK_Ns field can be referred to, the PLI_PB_TM field in which the sum of the playback times of all the tracks referenced from the playlist in milliseconds is described, the PLI_POB_ATR field, and 20 PLI_POB_SRP fields.
[0249]
{72-4_73} Summary of additional improvements in the second embodiment
As can be seen from the above description, in this embodiment, two information called TKI_POB_ATR and TKI_POB_SRP are added to TKGI. You can see that two pieces of information have been added. TKI_POB_SRP, PLI_POB_SRP, and DPLI_POB_SRP all have a common configuration and can specify a POB. FIG. 73 is a diagram showing a state in which the POB file shown in FIG. 70 is specified by TKI_POB_SRP, PLI_POB_SRP, and DPLI_POB_SRP. Hereinafter, the data structure of TKI_POB_ATR (DPLI_POB_ATR, PLI_POB_ATR) and TKI_POB_SRP (DPLI_POB_SRP, PLI_POB_SRP) will be described.
[0250]
{74-1} TKI_POB_SRP
TKI_POB_SRP is a field that specifies a POB to be displayed during a playback period in which a specific AOB is played out of a time zone in which playback is performed in the playback order specified by Default_Playlist information and PlayList information. In other words, TrackManager can designate a POB to be displayed for each track by setting TKI_POB_SRP.
[0251]
FIG. 74 shows a data structure of TKI_POB_SRP and TKI_POB_ATR.
In this figure, TKI_POB_SRP is a `` POB designation field '' from bit number b25 to bit number b16, a `` number of pixel '' field from bit number b11 to bit number b8, and a `` Huffman '' from bit number b7 to bit number b6 table ”field,“ Chominance sampling ”field from bit number b5 to bit number b4,“ Picture Coding Mode ”field occupying bit number b3 to bit number b0, bit number b12 to bit number b15, bit number b26 To reserved bit number b31.
[0252]
The “POB designation field” is a field in which the POB number to be displayed (POB number to be referred to) is described in the range of 1 to 999 during the period when the AOB file corresponding to this TKI is being reproduced. In the period when the AOB file corresponding to the TKI is being reproduced, “0” is described when no still image is displayed.
The “Picture Coding Mode” field is a field for notifying the playback apparatus of how the still image is encoded when displaying the still image specified in the POB specification field. In the case of JPEG (Joint Photograph Expert Group), a value of “0000b” is described.
[0253]
The “Chominance sampling” field is a field indicating the ratio at which the luminance component and the two color difference components are sampled when the still image specified in the POB specification field is encoded. When the ratio between the luminance component and the two color difference components is a ratio of 4: 2: 2, it is set to 00 bits, and when it is a ratio of 4: 2: 0, it is set to 01 bits.
[0254]
The “Huffman table” field is a field indicating whether or not a typical Huffman table is used when displaying the still image specified in the POB specification field. When using a Huffman table, it is set to 00bit.
The “number of Pixel” field is a field in which the image size of still image data designated in the POB designation field is described. When the image size of the still image data is 96 × 96, a value of “0000b” is described. In the case of 640 × 480, the image size is “0001b” and 160 × 120 to 1800 × 1200, and if the image size is other than 640 × 480, the value “0010b” is described.
[0255]
Since TKGI has 20 TKI_POB_SRPs configured as described above, a maximum of 20 still images can be played back during track playback. When one track is composed of a plurality of TKIs, TKI_POB_SRP is valid only for the first TKI.
{74-2} TKI_POB_ATR
“TKI_POB_ATR” is provided to specify in what form the POB specified by 20 TKI_POB_SRPs in TKGI is displayed. TKI_POB_ATR includes a Display order mode field that occupies bit number b0 to bit number b1, and a Display Timing mode field that occupies bit number b2 to bit number b3.
[0256]
In the “Display order mode” field, the order in which POBs specified by 20 TKI_POB_SRPs in TKGI are displayed is set. There are three modes of how the POB is played back during the AOB playback time. The first mode is a case where a maximum of 20 POBs specified in TKI_POB_SRP in TKGI are displayed in the order of TKI_POB_SRP in TKGI, which is called a sequential mode. The second mode is a mode in which POBs specified by 20 TKI_POB_SRPs in TKGI are randomly selected and played, and this is called random mode. The third mode is a mode in which POBs specified by 20 TKI_POB_SRPs in TKGI are randomly selected and reproduced so as to avoid duplication, which is called a shuffle mode. The Display order mode field is set to a value of “00b” when the sequential mode is set. On the other hand, “01b” is set when the random mode is set, and “10b” is set when the shuffle mode is set.
[0257]
The "Display Timing mode" field is a field for setting whether or not to synchronize the display of the POB specified by up to 20 TKI_POB_SRP in TKGI and the playback of the AOB file associated with the TKI. It is. A mode in which video and audio are synchronized is called a slide show mode, and only video display cannot be skipped. On the other hand, a mode in which video and audio are not synchronized is called a browserable mode, and only video display can be skipped.
[0258]
As described above, TKGI associates POB display with TKI, which POB is displayed in the period when the AOB file corresponding to itself is displayed, and in what order the POB is displayed. Whether or not to synchronize playback of the AOB file being set is set.
{74-3_75} Setting example of TKI_POB_SRP included in TKI # 1 to TKI # 3
FIG. 75 is a diagram illustrating a setting example of TKI_POB_SRP for TKI # 1 to TKI # 3 included in TrackManager. The first level shows TrackManager, and the second level shows nine POB files. The TrackManager in the first level includes eight TKIs, and the arrows indicate which POB files are referenced by TKI_POB_SRP in those TKIs. According to the reference relationship indicated by the arrow, TKI # 1 includes three TKI_POB_SRPs, and these three TKI_POB_SRPs specify POB001 to POB003. It can also be seen that TKI # 2 includes three TKI_POB_SRPs, these three TKI_POB_SRPs include POB004 to POB006, TKI # 3 includes three TKI_POB_SRPs, and these three TKI_POB_SRPs specify POB007 to POB009.
[0259]
In this embodiment, POB001 to 009 use JPEG image data in which a character string indicating lyrics is arranged on a plain background. Here, the character string used for the description of the lyrics is drawn in a font that more closely matches the image of the lyrics, and is subjected to outline emphasis, decoration, and the like.
The bottom row in FIG. 75 shows the contents of each POB. The contents of POB001 to POB003 are TrackA lyrics cards, the contents of POB004 to POB006 are TrackB lyrics cards, and the contents of POB007 to POB009 are TrackC lyrics cards. Since these are meaningless unless they are reproduced during the period in which each track is being reproduced, the TKI_POB_SRP included in the TKI is set to be reproduced during the period in which each track is being reproduced.
[0260]
The period during which each track is played is as shown in FIG. 16 in the first embodiment. That is, the playback time of AOB001.SA1 corresponding to TKI # 1 is 6.1 minutes, the playback time of AOB002.SA1 corresponding to TKI # 2 is 3.3 minutes, and the playback time of AOB003.SA1 corresponding to TKI # 3 is 5.5 minutes In these periods, the setting of TKI_POB_SRP set in TKI is valid, and the playback device can display POB in accordance with the valid TKI_POB_SRP.
[0261]
The playback time of AOB001.SA1 corresponding to TKI # 1 is 6.1 minutes. If POB001 to POB003 are displayed evenly during this period, the display time per sheet is 2.03 minutes = (6.1 minutes / 3) Become. The playback time of AOB002.SA1 corresponding to TKI # 2 is 3.3 minutes, and the playback device is POB004 to POB006, the display time per sheet is 1.1 minutes = (3.3 minutes / 3), AOB003.3 corresponding to TKI # 3. The playback time of SA1 is 5.5 minutes, and the display time per sheet of POB007 to POB009 is 1.83 minutes = (5.5 minutes / 3).
[0262]
{74-4_76} Setting example of TKI_POB_SRP included in TKI # 4 to TKI # 8
FIG. 76 is a diagram illustrating a setting example of TKI_POB_SRP included in TKI # 4 to TKI # 8 included in TrackManager. The first level shows TrackManager, and the second level shows 10 POB files. According to the reference relationship indicated by the arrows, TKI # 4 includes seven TKI_POB_SRPs indicated by the seven arrows in FIG. 76, and these seven TKI_POB_SRPs specify POB010 to POB016, respectively. It can also be seen that TKI # 8 includes three TKI_POB_SRPs, and these TKI_POB_SRPs specify POB017 to POB019. In this embodiment, POB010 to 019 also use JPEG image data in which a character string indicating lyrics is arranged on a plain background, like POB001 to 009. Note that TKI_POB_SRP is set only for TKI # 4 and TKI_POB_SRP is not set for TKI # 5 to # 7. If one track is composed of multiple TKIs as described above, TKI_POB_SRP is the first TKI. This is because it becomes effective only.
[0263]
The contents of POB010 to POB016 are TrackD lyrics cards shown in FIG. 16 of the first embodiment, and the contents of POB017 to POB019 are TrackE lyrics cards. The playback time of AOB004.SA1 to AOB007.SA1 corresponding to TKI # 4 to TKI # 7 is 30.6 minutes, and the display time per piece of POB010 to POB016 is 4.37 minutes (= 30.6 minutes / 7). Each POB can be displayed evenly during the period. The playback time of AOB008.SA1 corresponding to TKI # 8 is 7.0 minutes, and the display time per sheet of POB017 to POB019 is 2.33 minutes (= 7.0 minutes / 3).
[0264]
{77-1} DPLI_POB_SRP and DPLI_POB_ATR included in DPLGI
While TKI_POB_SRP can specify the POB to be displayed for each track, DPLI_POB_SRP in DPLGI specifies the POB to be displayed in the time zone in which multiple AOBs are played according to the order specified by the Default_Playlist information To do. FIG. 77 is a diagram showing DPLI_POB_SRP and DPLI_POB_ATR included in DPLGI. It is clear from FIG. 77 that DPLI_POB_SRP and DPLI_POB_ATR included in DPLGI also have the same data structure as TKI_POB_SRP and TKI_POB_ATR. Since Default_Playlist information defines the playback order of multiple AOB files, DPLI_POB_SRP and DPLI_POB_ATR in FIG. 77 display which POB is being played during the period in which multiple AOB files whose playback order is defined by Default_Playlist information are being played. It is possible to set the display order of the POBs and whether to synchronize the POB display and the playback of the AOB file associated with the TKI.
[0265]
{77-2_78} Setting example of 20 DPLI_POB_SRP
FIG. 78 is a diagram illustrating a setting example of 20 DPLI_POB_SRP included in the Default_Playlist information. The first level shows Default_Playlist information, and the frame included in it shows DPLGI and 20 DPLI_POB_SRP. The second row shows 20 POB files composed of POB020 to POB039. According to the reference relationship indicated by the arrows, 20 DPLI_POB_SRPs specify POB020 to POB039, respectively.
[0266]
POB020 is an illustration used in the jacket of the package software that recorded the music album consisting of TrackA ~ TrackE, POB021 is the logo of the production company that produced the music album, POB022 ~ POB025 is the portrait of the artist, POB026 to POB031 are one scenes of a promotion video, and POB032 to POB039 are photographs taken when TrackA to TrackE are performed at a concert. Since DPLI_POB_SRP in the Default_Playlist information is defined by the creation of the music content, it is specified to display the POB that matches the image of the track of the music content or the talent image of the artist.
[0267]
The POB file specified by DPLI_POB_SRP included in this DPLGI is displayed during the period when the AOB file whose playback order is specified by Default_Playlist information is being played. For example, in the example of FIG. 40, the playback order of five tracks, TrackA to TrackE, is specified via the eight TKIs by the Default_Playlist information. On the other hand, if 20 POB files are specified by DPLI_POB_SRP included in the Default_Playlist information in the example of FIG. 78, the specification of DPLI_POB_SRP by the Default_Playlist information is valid during the playback time of 52.5 minutes. Furthermore, if the reproduction time of 52.5 minutes is equally allocated to POB020 to POB039, the display time per sheet is 2.625 minutes = (52.5 minutes / 20).
[0268]
{77-3_79} Transition between foreground and background images over time
FIG. 79 shows how these are combined when the POB specified in DPLI_POB_SRP included in Default_Playlist information is used as a background image and the POB specified in TKI_POB_SRP included in TrackManager is used as a foreground image. It is a timing chart. 79 shows the same POB as the second stage of FIG. 78, and the second stage of FIG. 79 shows the same POB as the second stage of FIGS. It is shown. The horizontal direction in this figure is a time axis with 1 minute as a unit time. Also, the horizontal width of the POB in this figure indicates how long the reproduction of each POB continues in minutes.
[0269]
Referring to the time axis in this figure, during the period from playback start to 6.1 minutes, POB001 to POB003 (TrackA lyrics card) are foreground pictures, POB020, POB021 (jacket illustration and logo of the production company), POB022 (artist Will be displayed as a background image.
POB004 to POB009 (TrackB and TrackC lyrics cards) are used as foreground images and POB022 to POB025 (artist portraits) are displayed in the period from 6.1 minutes after the start of playback until 14.9 (= 6.1 + 3.3 + 5.5) minutes have passed. It will be displayed as a background image.
[0270]
After 14.9 minutes from the start of playback, POB010 to POB011 (TrackD lyrics card) are displayed as foreground pictures, and POB025 (artist portrait) and POB026 to POB028 (promotion video one scene) are displayed as background pictures.
{77-4_80} According to this timing chart, a composite video with POB004 as the foreground image (TrackB lyrics) and POB022 (artist photo) as the background image is displayed 6.1 minutes after the start of playback of the Default_Playlist information. Will be. FIG. 80 is a diagram illustrating how the foreground image and the background image are combined after 6 minutes have elapsed from the start of playback of the Default_Playlist information.
[0271]
{77-5_81} After 16 minutes from the start of playback of the Default_Playlist information, a composite video with POB010 (TrackD lyrics) as the foreground picture and POB026 (one scene of the promotion video) as the background picture will be displayed. Become. FIG. 81 is a diagram illustrating how the foreground image and the background image are combined after 16 minutes have elapsed from the start of playback of the Default_Playlist information.
[0272]
As described above, if the POB file specified by DPLI_POB_SRP in the Default_Playlist information and the POB file specified by TKI_POB_SRP in TrackManager are respectively combined and displayed as a foreground image and a background image, they are displayed. Along with the lyrics, you can display the portrait of the artist who wrote and composed the track, a promotional video, a concert scene, etc. as a background image. In addition, which POB file is displayed at which time zone can be easily changed by rewriting TKI_POB_SRP and DPLI_POB_SRP in TrackManager and Default_Playlist information.
{82-1} PLI_POB_SRP and PLI_POB_ATR included in PLGI
PLI_POB_SRP and PLI_POB_ATR included in PLGI also have the same data structure as DPLI_POB_SRP and DPLI_POB_ATR included in DPLGI and TKI_POB_SRP and TKI_POB_ATR included in TKI. FIG. 82 is a diagram showing PLI_POB_SRP and PLI_POB_ATR included in PLGI. Unlike the Default_Playlist information, the PlayList information prescribes the playback order uniquely defined by the user, so the PLI_POB_SRP and PLI_POB_ATR are in a period during which a plurality of AOB files whose playback order is specified by the PlayList information are being played back. The user decides which POB is displayed, in what order the POB is displayed, and whether the POB display is synchronized with the playback of the AOB file associated with the TKI. (Note that the music company has set DPLI_POB_SRP in the Default_Playlist information is merely an example, and the user can also freely set DPLI_POB_SRP in the Default_Playlist information.)
[0273]
{82-2_83} Setting example of PLI_POB_SRP included in PlayList information
Next, a setting example of PLI_POB_SRP included in PlayList information will be described.
FIG. 83 is a diagram illustrating a setting example of 20 PLI_POB_SRPs included in the PlayList information. The first level shows PlayList information, and the frame included in the PlayList information shows PLGI and 20 PLI_POB_SRPs. The second row shows 20 POB files composed of POB040 to POB059. According to the reference relationship indicated by the arrows, 20 PLI_POB_SRPs specify POB040 to POB059, respectively.
[0274]
POB020 to POB039 are all still image data created by the producer of music content, whereas POB040 to POB059 are all personal photos of the user. That is, POB040 is a photograph of the user's family, POB041 is a graduation photograph of the user, POB042 to POB045 are photographs of the user's pets, POB046 to POB051 are commemorative photographs when traveling in Europe, and POB052 to POB059 This is a commemorative photo when traveling to the United States. To simplify the description, the total playback time of the AOB file whose playback order is specified by this PlayList information and the number of POBs specified to be displayed by this PlayList information are the same as the Default_Playlist information. To do. Then, the total playback time of TrackA to TrackE specified by this PlayList information is 52.5 minutes, and when displaying POB040 to POB059 evenly during this playback time, the display time per frame is 2.625 minutes = (52.5 minutes / 20).
[0275]
{82-3_84} Transition between foreground and background images over time
FIG. 84 shows how these are combined when the POB specified by PLI_POB_SRP included in the Playlist information is a background image and the POB specified by TKI_POB_SRP included in TrackManager is a foreground image. It is a timing chart. 84 shows the same POB as the second stage of FIG. 83, and the second stage of FIG. 84 shows the same POB as the second stage of FIGS. 75 and 76. It is shown. The horizontal direction in this figure is a time axis with 1 minute as a unit time. Also, the horizontal width of the POB in this figure indicates how long the reproduction of each POB continues in minutes.
[0276]
In this figure, POB001 to POB003 (TrackA lyrics card) are displayed as foreground images, POB040, POB041 (family photos and graduation photos), and POB042 as background images during the period from playback start to 6.1 minutes It will be.
In the period from 6.1 minutes to 14.9 minutes, POB004 to POB009 (TrackB, TrackC lyrics card) are displayed as foreground images and POB042 to POB045 (pet photos) as background images. After 14.9 minutes, POB010 to POB011 (TrackD lyrics card) will be displayed as foreground images, and POB045 and POB046 to POB048 (commemorative photos when traveling in Europe) will be displayed as background images.
[0277]
The POB specified in the Default_Playlist information was considered by the music content production company. While the POB specified in the music content track image and the artist's talent image is specified, the PlayList information The POB specified in the item is personally selected by the user, and the user's personal consideration is strong.
[0278]
{82-4_85} According to Fig. 84, after 6.1 minutes have elapsed from the start of playback of Playlist information, a composite video with POB004 as foreground image (TrackB lyrics) and POB042 (pet photo) as background image is displayed. become. FIG. 85 is a diagram illustrating how the foreground image and the background image are combined after 6.1 minutes have elapsed from the start of playback of the playlist information.
{82-5_86} After 16 minutes from the start of playback of the Playlist information, a composite video with POB010 (TrackD lyrics) as the foreground picture and POB046 (Europe travel photo) as the background picture will be displayed. FIG. 86 is a diagram illustrating how the foreground image and the background image are combined after 16 minutes from the start of playback of the playlist information. The lyrics contents in these composite images are the same as those in FIGS. 80 and 81, but the background images are different, so that the impression seen is greatly different from the composite images shown in FIGS.
[0279]
As described above, by causing the PLI_POB_SRP in the PlayList information defined by the user to specify a POB file that is different from the POB file specified in the Default_Playlist information, the user can You can display photos related to the memories.
{82-6_87} Example of setting a common POB in DPLI_POB_SRP of Default_Playlist information
In the example of FIGS. 78, 79, 82, and 83, all the DPLI_POB_SRPs included in the Default_Playlist information are specified with different POB files, but they overlap with any one of the DPLI_POB_SRPs included in the Default_Playlist information. If a POB file is specified, the number of POB files can be reduced by reducing the number of POB files by displaying a common POB file during a period in which a plurality of tracks are being played. FIG. 87 is an example in which the number of POB files is reduced by causing DPLI_POB_SRP to designate a common POB file among a plurality of DPLI_POB_SRPs in the Default_Playlist information. In the figure, it can be seen that DPLI_POB_SRP # 1 and DPLI_POB_SRP # 4 specify POB020, and DPLI_POB_SRP # 2 and DPLI_POB_SRP # 5 specify POB021.
[0280]
{82-7_88} Transition between foreground and background images over time
FIG. 88 shows how these are synthesized when the POB specified by DPLI_POB_SRP included in Default_Playlist information is used as a background image and the POB specified by TKI_POB_SRP included in TrackManager is used as a foreground image. It is a timing chart. In this timing chart, it can be seen that POB020 showing the jacket illustration of the package software is repeatedly displayed three times immediately after the start of reproduction, after 7.875 minutes and after 15.75 minutes. It can also be seen that POB021 showing the logo of the production company is displayed three times repeatedly after 2.625 minutes, 10.5 minutes, and 18.375 minutes from the start of playback. When DPLI_POB_SRP is specified as shown in FIG. 87, the same POB is repeatedly displayed, which is suitable when there is something to be repeatedly displayed in the POB, such as a jacket illustration or a logo mark.
[0281]
Although it has become a long sentence above, the explanation about TKGI, DPLGI, and PLGI is finished.
{69-4_89} About POBMG
In the second embodiment, a POBManager that is a new information element added to navigation data will be described. FIG. 89 shows the internal structure of POBMG. As shown in the figure, the POBMG includes POB management information (POBMGI) and POB Count Information (POBCI) # 1... #N.
[0282]
{69-4_89-1} About POBMGI
POB management information (POBMGI) includes POBMGI identification information occupying the 0th byte to the 1st byte, a reserved field (reserved) occupying the 2nd byte to the 3rd byte, as shown by the dashed lead line, 4 It consists of a POB_Ns field that occupies bytes 5 to 5 and a reserved field (reserved) that occupies bytes 6 to 7.
[0283]
In the POBMGI identification information field, an ID that uniquely identifies the POBMGI is described (ISO646 character set code “A6”). The POB_Ns field describes the number of POBs from “0” to “999”. Is done. This is the end of the description of POB management information (POBMGI).
{69-4_89-2} About POBCI
Next, POB Count Information (POBCI) will be described. POB Count Information (POBCI) is management information provided in association with each POB. The bit configuration is as shown by a broken lead line. That is, the POB_RCN field occupying bit number b0 to bit number b9, the reserved area field occupying bit number b10 to bit number b13, and the data existence field occupying bit number b14 to bit number b15 It consists of.
[0284]
About {69-4_89-3} POB_RCN
The “POB_RCN” field indicates whether the display of the POB associated with POBCI is specified by DPLGI, PLGI, or TKGI. If specified, the specified number of times, that is, the display is specified. The number of times is described in the range of 1 to 999. As described in the first embodiment, the TKI can be deleted, and the specification of the playback order in the Default_Playlist information and the PlayList information can be freely deleted. The number of POBs specified in POB_refernce_count is decremented by the number of deleted TKIs when the TKI specifying the corresponding POB is deleted. Also, when Default_Playlist information and PlayList information are deleted, the number of deleted TKIs is decremented. POB_refernce_count is 0 when display is not specified by DPLGI, PLGI, or TKGI. Since the POB whose POB_refernce_count is 0 is a POB that is not referenced from any TKI or PlayList information, the playback device detects the POB whose refernce_count_number is 0 each time the TKI and PlayList information is deleted. By deleting the POB file containing the POB whose refernce_count_number is 0, the number of still image data stored in the flash memory card can be reduced. Among multiple POBs, a specific POB has a close relationship with only a specific track, and if it is not played back in synchronization with that track, it means that the POB is stored in the flash memory card. If it does not exist (for example, a case where a still image indicating the lyrics of a track stored in a flash memory card is stored as still image data), by deleting based on the refernce_count_number And there is no waste of storing extra POB in the flash memory card. In addition to the case where the TKI is deleted, the same refernce_count_number may be decremented when the POB specified by DPLI_POB_SRP, PLI_POB_SRP, and TKI_POB_SRP is deleted by editing work.
[0285]
{69-4_89-4} About data existence
In the data existence field occupying bit number b14 to bit number b15, it is specified whether or not a POB corresponding to this POB number exists. If there is a POB corresponding to the POB number, it is set to 01b. If there is no POB, 00b is set. If the POB is specified to exist, even if the TKI and PlayList information is deleted and POB_refernce_count becomes 0, the POB corresponding to the POB_refernce_count is considered to be worth storing in the flash memory card. The POB is not deleted. Regardless of whether or not it is referenced by TKI and PlayList information, if the POB alone has storage value, set the data existance corresponding to that POB to 1, and if it is not referenced by TKI and PlayList information, the storage value A POB that does not have a value can be stored in a flash memory card by setting the data existance corresponding to the POB to 0. On the other hand, a POB that has storage value only when it is integrated with a track can be effectively used for the storage capacity of the flash memory card by being deleted together with the deletion of the track.
[0286]
This completes the explanation of POBManager (POBMG).
{69-5} Update when editing TKI
The four editing cases described in the first embodiment, when some of the tracks are deleted (case 1), when combining any two of the multiple tracks into one track (case 3), one track Will be described how TKI_POB_SRP and DPLI_POB_SRP are updated when two tracks are obtained (case 4) and when the order of the tracks is changed (case 5).
[0287]
When the track is deleted (case 1), as shown in the first embodiment, TKI_BLK_ATR for the TKI is set to “Unused”, and TKI_POB_SRP in the TKI is deleted. At the same time, the POB_refernce_count in the POBManager corresponding to the POB specified by the TKI_POB_SRP is decremented. There is no change even if the POB specified in PLI_POB_SRP and DPLI_POB_SRP in DPLGI and PLGI is deleted.
[0288]
When the order of the tracks specified by DPL_TK_SRP is changed (case 5), the order of the tracks is changed, so the display order of the POB specified by TKI_POB_SRP is the order after replacement.
For track integration (case 3), it is desirable to integrate TKI_POB_SRP in TKI. This is because, as described above, when one track is composed of multiple TKIs, TKI_POB_SRP is valid only for the first TKI, so the POB specified in TKI_POB_SRP of the latter TKI by the track integration operation, This is because it is necessary to have TKI_POB_SRP of the first half TKI specify.
[0289]
Also, in the track division (case 4), it is necessary to change TKI_BLK_ATR of TKI and divide TKTMSRT and BIT into two as described in the first embodiment. A plurality of TKI_POB_SRP specified by TKGI may be divided into two and distributed to the original TKI and the TKI obtained by the division.
{69-6} Application examples of TKI_POB_SRP and DPLI_POB_SRP settings
With the TrackManager and PlayListManager data structures described above, the association between AOB files and POBs can be freely changed by setting TKI_POB_SRP, DPLI_POB_SRP, and PLI_POB_SRP, so the music content provider has no lyrics A plurality of music contents with different prices can be sold to consumers according to the amount of still image data attached, such as a type with lyrics and a type with lyrics and a background image.
[0290]
When a consumer wishes to purchase a type without lyrics, TrackManager in which eight AOB files shown in the first embodiment and POB020 to POB039 shown in FIG. 78 are designated as TKI_POB_SRP in TKI # 1 to TKI # 8. Are created, compressed, and sent to a general-purpose personal computer owned by the consumer. The track (AOB) and the still image (POB) corresponding to this track are downloaded from the server computer of the music company, and the computer owned by the consumer uses the flash memory card 31 in FIG. The SD_Audio directory shown in b) may be created.
[0291]
When the consumer wishes to purchase a certain type of lyrics, the eight AOB files shown in the first embodiment and POB001 to POB019 corresponding to the lyrics shown in FIGS. 75 and 76 are converted into TKI # 1 to TKI # 8. The SD_Audio directory including the TrackManager specified in TKI_POB_SRP is created, compressed, and transmitted to a general-purpose personal computer owned by the consumer.
[0292]
If the consumer wishes to purchase a type with lyrics and background images, the eight AOB files shown in the first embodiment and POB001 to POB019 corresponding to the lyrics are designated as TKI_POB_SRP in TKI # 1 to TKI # 8 The SD_Audio directory including the TrackManager and the PlayListManager in which the POB020 to POB039 shown in FIG. 78 are specified in DPLI_POB_SRP is created, compressed, and then transmitted to the general-purpose personal computer owned by the consumer.
[0293]
In this embodiment, any still image data can be attached to the audio data by setting TKI_POB_SRP, DPLI_POB_SRP, and PLI_POB_SRP, so music contents with different price ranges can be easily created depending on the amount of accompanying still image data. can do.
{90-1_91} About the playback apparatus according to the second embodiment
Next, a playback apparatus according to the second embodiment will be described. The playback device according to the second embodiment is largely different from that of the first embodiment in three ways. Of these, the first difference is that the playback device in the first embodiment is portable, whereas the playback device in the second embodiment is in-vehicle. FIG. 90 is a diagram showing how the playback device according to the second embodiment is used, and FIG. 91 is a diagram showing the appearance of only the playback device main body according to the second embodiment. In this figure, the playback device according to the second embodiment is different from the playback device according to the first embodiment. The playback device according to the second embodiment is installed in a car as shown in FIG. It is connected to a large liquid crystal display 5 and a vehicle-mounted speaker. Since the liquid crystal display 5 connected to the playback device is large, the playback device in the second embodiment can suitably display the various still image data described above.
[0294]
The second difference is that the descrambler 7 in the second embodiment releases the POB encryption in addition to the audio data encryption. That is, when the POB file is POBXXX.SP1 and the recorded POB is encrypted, the descrambler 7 stores it in the Key Entry of the encryption key storage file POBSP1.KEY in the protected area. Filekey is set and encryption in POBXXX.SP1 is released. Finally, the third difference is that the ROM 4 in the second embodiment stores a program that describes the processing contents for displaying the POB as a foreground image or a background image. Based on this, the CPU 10 displays the screen. It is a point to do.
[0295]
{90-2_92_93_94}
Next, the internal configuration of the playback apparatus according to the second embodiment will be described. The internal configuration of the playback apparatus shown in FIG. 92 is different from that of the first embodiment in that a plurality of VRAMs 61 are provided.
The plurality of VRAMs 61 are VRAMs each corresponding to one graphics plane 0. In the VRAM of each graphics plane, a transmittance α of 0% to 100% is set for each pixel, and the pixel value of an image to be displayed on the liquid crystal display 5 is calculated by the following equation. FIG. 93A shows how still images stored in a plurality of VRAMs 61 are superimposed.
Pixel value of each pixel = Pixel value of graphics plane 0 x (1-α) + Pixel value of graphics plane 1 x α
The transmissivity is set to 0% for the character portion representing the lyrics on the foreground side. Accordingly, the background image stored in the graphics plane 1 does not appear on the screen at all. In the foreground picture, the transparency of the plain background part is set to 100%. Accordingly, the background image stored in the graphics plane 1 is inserted into the plain portion of the still image in the graphics plane 0. If the transmittance α is set in this way, it is possible to obtain a composite image obtained by covering a background image with a transparent sheet on which lyrics are described, that is, a composite image as shown in FIGS.
[0296]
In addition to the composite image shown in FIG. 93 (a), for example, as shown in FIG. 93 (b), the lyrics are arranged in the lower half, and the composite image arranged in the upper half is displayed on the background image. May be.
{94-1} Flow chart for foreground image display processing
FIG. 94 is a flowchart showing a processing procedure for foreground image display processing. When Default_Playlist information is specified and playback based on TKI # z is started, in step S402, the CPU 10 determines whether or not TKI_POB_SRP included in TKGI included in the TKI specifies a POB file. When TKI_POB_SRP designates a POB file, in step S403, the CPU 10 counts how many POB files are designated by TKI_POB_SRP included in TKGI. In step S404, the display time POB_time per POB file is determined based on the number of POB files. Subsequently, in step S405, the CPU 10 refers to TKI_POB_ATR in TKGI and determines in what display mode each POB file is displayed. If TKI_POB_ATR is described as sequential mode, the process proceeds from step S405 to step S406 to initialize the variable i, and in step S407, the POB file specified by the i-th TKI_POB_SRP is displayed for the display time POB_time. At this time, if the extension of the POB file specified by TKI_POB_SRP is JPG, the POB is displayed as it is. If the extension of the POB specified in TKI_POB_SRP is SP1 and it is encrypted, read the corresponding Filekey from the protected area, decrypt the POB encryption, and display the POB To do. Thereafter, in step S408, it is determined whether the variable i has reached POB_Ns. If not, the variable i is incremented in step S409, and the process proceeds to step S407. Thereafter, steps S406 to S409 are repeated until the variable i reaches POB_Ns. As a result, POBs specified in TKI_POB_SRP of TKGI are sequentially displayed. When the variable i reaches POB_Ns, the process of this flowchart is terminated.
[0297]
If TKI_POB_ATR is described as a random mode, a variable i is initialized in step S410, then a random number r in the range from 1 to POB_Ns is generated in step S411, and an r-th corresponding to the random number r is generated in step S412. The POB file specified by TKI_POB_SRP is displayed for the display time POB_time determined in step S404. Thereafter, in step S413, it is determined whether the variable i has reached POB_Ns. If not, the variable i is incremented in step S414, and the process proceeds to step S411. When the display is finished, a random number r in the range from 1 to POB_Ns is generated again in step S411, and the POB file designated by the r-th TKI_POB_SRP corresponding to the random number r is read in step S412. Only the display time POB_time determined in is displayed. At this time, as in the case of the sequential mode, if the extension of the POB file specified by TKI_POB_SRP is JPG, the POB is displayed as it is. If the extension of the POB specified in TKI_POB_SRP is SP1 and it is encrypted, read the corresponding Filekey from the protected area, decrypt the POB encryption, and display the POB To do.
[0298]
Thereafter, steps S411 to S414 are repeated until the variable i reaches POB_Ns. As a result, POBs specified in TKI_POB_SRP of TKGI are displayed in random order. When the variable i reaches POB_Ns, the process of this flowchart is terminated.
If TKI_POB_ATR is described as the shuffle mode, the process proceeds from step S405 to step S415, and after initializing the variable i in step S415, a random number r in the range from 1 to POB_Ns is generated in step S416, and then In step S418, it is determined whether or not the generated random number r matches the displayed POB number. If they match, the process proceeds to step S416 to generate a random number again. If they do not match, the process moves from step S418 to step S419, and the POB file designated by the r-th TKI_POB_SRP corresponding to the random number r is displayed for the display time POB_time determined in step S404. At this time, if the extension of the POB file specified by TKI_POB_SRP is JPG, as in the sequential mode and random mode, the POB is displayed as it is. If the extension of the POB specified in TKI_POB_SRP is SP1 and it is encrypted, read the corresponding Filekey from the protected area, decrypt the POB encryption, and display the POB To do. When the display is finished, the variable r is stored as the displayed POB number in step S417. Thereafter, in step S420, it is determined whether the variable i has reached POB_Ns. If not, the variable i is incremented in step S421, and the process proceeds to step S416. Thereafter, Step S416 to Step S421 are repeated until the variable i reaches POB_Ns. As a result, POBs specified in TKI_POB_SRP of TKGI are sequentially displayed. When the variable i reaches POB_Ns, the process of this flowchart is terminated.
[0299]
{95-1} Flow chart for background image display processing
The description of the foreground image display processing is completed, and the background image display processing procedure will be described. FIG. 95 is a flowchart showing the processing procedure of the background image display processing. In this flowchart, the processing performed based on “TKGI TKI_POB_SRP, TKI_POB_ATR” in FIG. 94 is replaced with “DPLGI DPLI_POB_SRP, DPLI_POB_ATR”, and the basic processing procedure is the same as the flowchart in FIG. 94. It is.
[0300]
When Default_Playlist information is selected, as in steps S402 to S405, in steps S502 to S505, the CPU 10 determines whether or not DPLI_POB_SRP included in the DPLGI specifies a POB file. The number of POB files designated is counted to determine the display time POB_time per POB file, and in which display mode to display according to DPLI_POB_ATR. If DPLI_POB_ATR is described as the sequential mode, the POB file is sequentially displayed in accordance with DPLI_POB_SRP included in DPLGI in step S506 to step S509 in accordance with variable i in the same manner as in steps S406 to S409.
[0301]
If DPLI_POB_ATR is described as the random mode, the POB file is sequentially displayed in accordance with DPLI_POB_SRP included in DPLGI according to variable r in steps S510 to S514 in the same manner as in steps S410 to S414.
If DPLI_POB_ATR is described as the shuffle mode, the POB file is sequentially displayed in accordance with DPLI_POB_SRP included in DPLGI in step S515 to step S521, in accordance with variable r, in the same manner as in steps S415 to S421.
[0302]
{96-1} Flow chart for background image display processing
The description of the foreground image display processing when referring to DPLGI's DPLI_POB_SRP is now completed, and the processing procedure of the background image display processing when referring to PLGI's PLI_POB_SRP will be described. FIG. 96 is a flowchart showing the processing procedure of the background image display processing. In this flowchart, the processing performed based on “DPLGI's DPLI_POB_SRP, DPLI_POB_ATR” in FIG. 95 is replaced with “PLGI's PLI_POB_SRP, DPLI_POB_ATR”. The foreground image and the basic processing procedure are as shown in FIG. Since this is the same as the flowchart, the same reference numerals are given and detailed description is omitted.
[0303]
{94-2_95-2_97A, B, C} Display example on liquid crystal display 5
94 and 95, what composite image is displayed on the liquid crystal display 5 when the foreground image specified by TKI_POB_SRP and the background image specified by DPLGI are synthesized by the processing procedure shown in FIGS. Are shown in FIGS. 97 (a) to 97 (c).
[0304]
As shown in FIG. 97 (a), it is assumed that Default_Playlist information is designated and POB display is started in accordance with the reproduction order described therein. In this case, the foreground image display process shown in the flowchart of FIG. 94 and the background image display process shown in the flowchart of FIG. 95 are performed, and are included in the POB and DPLGI whose display is specified by a plurality of TKI_POB_SRP included in TKGI. POBs whose display is specified from multiple DPLI_POB_SRPs are displayed in sequence. Therefore, the image composition shown in FIG. 80 is performed after 6 minutes from the start of reproduction, and the composite image shown in FIG. 97B is displayed on the liquid crystal display 5.
[0305]
Further, the image composition shown in FIG. 81 is performed after 16 minutes from the start of reproduction, and the composite image shown in FIG. 97 (c) is displayed on the liquid crystal display 5.
{94-2_96-1_98A, B, C} Display example on the liquid crystal display 5
94 and 96, when the foreground image specified by TKI_POB_SRP and the background image specified by PLI_POB_SRP are combined, what kind of combined image is displayed on the liquid crystal display 5. These are shown in FIGS. 98 (a) to (c).
[0306]
As shown in FIG. 98 (a), it is assumed that PlayList information is designated and POB display is started in accordance with the reproduction order described therein. In this case, the foreground image display process shown in the flowchart of FIG. 94 and the background image display process shown in the flowchart of FIG. 96 are performed, and are included in the POB and PLGI whose display is specified by a plurality of TKI_POB_SRP included in TKGI. POBs for which display is specified from multiple PLI_POB_SRPs are displayed sequentially. Therefore, the image composition shown in FIG. 85 is performed after 6 minutes from the start of reproduction, and the composite image shown in FIG. 98B is displayed on the liquid crystal display 5. Also, image composition shown in FIG. 86 is performed 16 minutes after the start of reproduction, and a composite image shown in FIG. 98 (c) is displayed on the liquid crystal display 5.
[0307]
{99_1} Recording apparatus according to the second embodiment
Subsequently, a recording apparatus according to the second embodiment will be described. The recording apparatus according to the second embodiment is novel in that a plurality of POBs are recorded on the flash memory card 31, TKI_POB_SRP, DPLI_POB_SRP, and PLI_POB_SRP are set, and TKI_POB_ATR, DPLI_POB_ATR, and PLI_POB_ATR are set. Such a series of processes is performed by the CPU 10 according to the second embodiment through the procedure described in the flowchart of FIG. Hereinafter, the recording process of the recording apparatus according to the second embodiment will be described with reference to the flowchart of FIG.
[0308]
In step S601, the CPU 10 initializes each variable used in this flowchart. Variables used in this flowchart include variables #x, #y, #z, #u, #vy, and #w. #x is a variable that identifies the POB to be processed among multiple POBs, #y is a variable that identifies the track sequence (PLI) to be processed among multiple track sequences, and #z is a multiple track Is a variable for specifying a track (TKI) to be processed.
[0309]
#u is a variable that identifies the DPLI_POB_SRP to be processed among multiple DPLI_POB_SRPs, and #vy is the processing target among the multiple PLI_POB_SRPs included in the PLI (PLI # y) indicated by #y This variable specifies PLI_POB_SRP. #w is a variable for specifying TKI_POB_SRP to be processed among a plurality of TKI_POB_SRP included in TKI # y) indicated by #z.
[0310]
When these variables are initialized, POB # x is displayed in step S602. Thereby, the operator can visually confirm what kind of photograph, illustration, and lyrics the POB is. In step S603, POB # x is a selection of whether still image data to be displayed throughout the entire time period during which the track sequence is reproduced or still image data to be displayed only during the time period during which a specific track is reproduced. Is received from the operator, and any selection is accepted.
[0311]
When the operator determines that “POB # x should be assigned to the track sequence”, the operator waits for selection of a track sequence for displaying POB # x in step S604. It is determined whether the playlist specifying #y is DPLI or PLI. If the playlist is DPLI, POB # x is set in DPLI_POB_SRP # u in DPLI in step S606, and DPLI_POB_ATR # u in DPLI is set based on POB # x in step S607. If both DPLI_POB_SRP and DPLI_POB_ATR are set in this way, #u is incremented in step S608 (# u ← # u + 1), and then #x is incremented in step S609 (# x ← # x + 1) ).
[0312]
When PLI is selected in step S605, POB # x is set to PLI_POB_SRP # vy in PLI # y in step S610, and PLI_POB_ATR # vy in PLI is set based on POB # x in step S611. In step S612, after #vy is incremented (# vy ← # vy + 1), the process proceeds to step S609 to increment #x.
[0313]
If it is determined in step S603 that POB # x should be assigned to the track, the designation of the track is accepted in step S613, and POB # is set in TKI_POB_SRP # w set in TKI # z for the track #z designated in step S614. Set x. Thereafter, TKI_POB_ATR # w in TKI # z is set based on POB # x in step S615, and after incrementing #w in step S616 (# w ← # w + 1), in step S617, #x is the last POB. It is determined whether or not number #n has been reached. If not, the process proceeds to step S609 and increments #x. If #x reaches the POB last number #n, PMGGTKI including POB # 1 to #n, DPLI and PLI is selected in step S618. The TKMG including it is recorded on the flash memory card, and the process is terminated.
[0314]
As described above, according to the present embodiment, when there is still image data to be displayed as a background image in a time zone in which a plurality of tracks are being reproduced, such as artist photos and company logo marks, Default_Playlist Information, DPLGI in PlayList information, DPLI_POB_SRP in PLGI, PLI_POB_SRP, by specifying the still image data, in the time zone in which a plurality of tracks whose playback order is specified by the playlist information is being played, Common still image data can be displayed. Also, if there is still image data that you want to be displayed only during the period when a specific track is played apart from the background image, such as lyrics, specify such still image data with TKI_POB_SRP in TKI. Can do.
[0315]
In addition, the said embodiment was only demonstrated as a system example which can anticipate the best effect in the present condition. The present invention can be implemented and modified without departing from the gist thereof. Specifically, modifications as shown in the following (a), (b), and (c) are possible.
(A) The procedure described with reference to the flowcharts of FIGS. 94, 95, 96, and 99 may be realized by an execution format program and recorded on a recording medium for distribution / sales.
[0316]
(B) The case where the presentation data and the navigation data according to the present embodiment are applied to the music content has been described as an example. However, the presentation data and the navigation data according to the present embodiment are configured by a voice that an announcer or a voice actor reads a book. Needless to say, it may be applied to the reading book. In this case, it is desirable that a still image including a character string of a sentence included in the book is designated as a foreground image by TKI_POB_SRP, while an illustration of the document is designated as a background image by DPLI_POB_SRP and PLI_POB_SRP.
[0317]
(C) In this embodiment, the POB specified by DPLI_POB_SRP-PLI_POB_SRP is used as the background image, and the POB specified by TKI_POB_SRP is used as the foreground image. However, the relationship between the two may be exchanged. Furthermore, only one of the POB specified by DPLI_POB_SRP-PLI_POB_SRP and the POB specified by TKI_POB_SRP may be displayed. In addition, the POB may be displayed without being distinguished from the foreground picture and the background picture. For example, it goes without saying that the POB specified by DPLI_POB_SRP (PLI_POB_SRP) may be displayed, and then the POB specified by TKI_POB_SRP may be displayed.
[0318]
(Third embodiment)
In the second embodiment, each POB is displayed at an equal ratio during the period in which the PlayList information and TKI are valid. However, in the third embodiment, the phrase period table and the highlight coordinate table are stored in the flash memory card 31. This is an embodiment in which the audio reproduction and the lyrics display are precisely synchronized by storing.
[0319]
The former phrase period table is a table in which TKI_POB_SRP for specifying a POB indicating each lyrics and information indicating the start / end of the phrase period are associated with each other. FIG. 100A shows an example of the phrase period table. Here, the phrase period represents the period in which the phrase described in the lyrics appears when the AOB is played back, with a time accuracy of millisecond units, and the playback device performs playback progress as shown in the first embodiment. As the time is updated, it is monitored which of the phrase periods described in the table corresponds to the updated playback elapsed period. Through such monitoring, it is possible to know which POB has the lyrics of AOB, AOB_ELEMENT, and AOB_FRAME that are currently being played back. By using a table in which the POB phrase period is described with time accuracy in milliseconds, AOB playback and lyrics display can be synchronized with the above-described time accuracy in milliseconds.
[0320]
In addition, when the playback start time is specified using the jog dial as shown in the first embodiment and cueing is performed, Formulas 1 to 3 shown in the first embodiment are used for AOB and AOB_ELEMENT. By this, it is determined which AOB_FRAME of which AOB_ELEMENT of which AOB the specified reproduction start time corresponds to. On the other hand, for a still image, it is determined which phrase period corresponds to the designated reproduction start time. Then, the POB corresponding to the designated phrase period is displayed. Thus, even when performing cueing using a jog dial, the corresponding POB can be displayed as appropriate. In this embodiment, the time is described in the phrase period table, but the AOB number, AOB_ELEMENT number, and AOB_FRAME number indicating AOB, AOB_ELEMENT, and AOB_FRAME to be synchronized with the lyrics may be described in the phrase period table.
[0321]
On the other hand, the latter highlight coordinate table is a table in which display coordinates for characters included in lyrics are associated with periods in which AOB_ELEMENT and AOB_FRAME corresponding to the characters are reproduced in AOB. FIG. 100B shows an example of the highlight coordinate table. Such a highlight coordinate table is provided, and the playback device displays only the characters corresponding to the currently reproduced AOB_ELEMENT and AOB_FRAME in different colors among the lyrics displayed corresponding to the phrase period. Let me do it.
[0322]
For example, if the lyrics include the phrase “Access to you from a small window”, the highlight coordinate table will contain “small”, “sa”, “na”, “u”, “i”, “n”, “do”, “u” ] And the display period of the character AOB_ELEMENT and AOB_FRAME corresponding to the character are associated with each other. Then, as the AOB playback progresses as shown in the first embodiment, the playback device changes the color of the location indicated by the character display coordinates in the highlight coordinate table.
[0323]
As a result, the playback device can display at a glance which part of the lyrics is being played by the AOB, and can reproduce the current karaoke software. It becomes possible.
As described above, according to the present embodiment, by using the two tables, the phrase period table and the highlight coordinate table, it is possible to precisely synchronize the sound reproduction and the lyrics display as in the current karaoke software. Is possible.
[0324]
【The invention's effect】
A semiconductor memory card according to the present invention is a semiconductor memory card that stores a plurality of audio objects, still picture objects, reproduction path information, first pointer information, second pointer information, and symbolic counters. The object playback order is indicated, and the first pointer information corresponds to the playback path information, and indicates the playback order of the still picture object during the entire playback time of the audio object according to the playback path information. The pointer information corresponds to a specific audio object, indicates the playback order of the still image objects during the entire playback time of the audio object, and the symbolic counter is associated with each still image object. Still image object to be the first pointer Information or the second pointer information, and for the specified still image object, the number of designated first pointer information and second pointer information indicates the number of designations. When there are still image objects to be displayed in common as a background image in a time zone in which a plurality of audio objects included in the audio sequence are reproduced according to the reproduction order indicated by the reproduction path information, the first pointer In the information, the still image object is designated in association with the reproduction path information. Thus, a common still image object can be displayed in a time zone in which a plurality of audio objects included in the audio sequence are being reproduced.
[0325]
Since a common still image can be assigned to a plurality of audio objects, an audio sequence corresponding to a low-profile music album can be shared with a still image object or the like during a period in which the plurality of audio objects are played. By displaying, it is possible to save labor and cost required for image production.
[0326]
Conversely, for an audio sequence corresponding to a high-profile music album, a plurality of still images are assigned to each audio object and a plurality of still images are assigned to each audio object during the period in which each audio object is played. By displaying a picture object, reproduction of each audio object can be produced gorgeously. By grasping the psychology of artists' fans with such still image display, sales of audio sequences (music albums) can be increased.
[0327]
In addition, when there is a still image object to be displayed only during a period when a specific audio object is being played apart from the background image, such as lyrics, such a still image object is designated by the second pointer information. Can be assigned to a specific audio object.
Further, the symbolic counter indicates whether the corresponding still image object is designated by the first pointer information or the second pointer information. Since this symbolic counter expresses even the specified number of the first pointer information and the second pointer information, the recording device of the semiconductor memory card deleted the audio object or audio sequence. At this time, the second pointer information about the deleted audio object or the first pointer information about the deleted audio sequence is specified, and the display of the still image object whose display is designated by the first pointer information and the second pointer information is specified. Decrement the quota. If the allocated number for any one of the still image objects reaches 0, the still image object is deleted as it is not referred to by any first pointer information or second pointer information. Can end up. Thus, by deleting the still image object in conjunction with the deletion of the audio object, the storage efficiency in the semiconductor memory card can be improved.
[Brief description of the drawings]
FIG. 1 is a diagram showing a shape of a flash memory card 31 when viewed from the top.
FIG. 2 is a diagram showing a shape of a flash memory card 31 when viewed from the lower surface thereof.
FIG. 3 is a diagram showing a hierarchical structure of a flash memory card 31 according to the present embodiment.
4A is a diagram showing a configuration of a system area, a protect area, and a user data area provided in the physical layer of the flash memory card 31. FIG.
(B) It is a figure which shows the structure of the protection area | region and user data area | region in a file system layer.
FIG. 5 is a diagram showing details of a configuration in a file system layer.
FIG. 6 is a diagram assuming that AOB001.SA1 is divided into five according to the cluster size and each divided portion is stored in clusters 003, 004, 005, 00A, and 00C.
FIG. 7 is a diagram illustrating a setting example of a directory entry and a file allocation table when AOB001.SA1 is recorded in a plurality of clusters.
8A and 8B, when storing these two data in the application layer, what directory is configured in the user data area and the protect area in the file system layer, and what file is in the directory It is a figure which shows whether it is created under no.
FIG. 9 is a diagram illustrating a correspondence between AOBSA1.KEY under an SD_Audio directory and an AOB file.
FIG. 10 is a diagram hierarchically showing the data structure of an AOB file.
FIG. 11A is a diagram showing parameters described in ISO / IEC13818-7 in a tabular format.
(B) It is a figure which shows the parameter which should be used when encoding by MPEG-Layer3 (MP3) system in a table format.
(C) It is a figure which shows the parameter which should be used at the time of encoding by Windows (trademark) Media Audio (WMA) system in a table format.
FIG. 12 is a diagram showing details of the configuration of AOB_FRAME.
FIG. 13 is a diagram illustrating how the byte length of audio data in each AOB_FRAME is set in three AOB_FRAMEs.
FIG. 14 is a diagram illustrating a correspondence between sampling_frequency and the number of AOB_FRAME included in AOB_ELEMENT.
FIG. 15 is a diagram illustrating an example of a time length of AOB_ELEMENT and a time length of AOB_FRAME;
FIG. 16 is a diagram showing what playback content is played back by continuously playing back each AOB and AOB_BLOCK recorded in an AOB file.
FIG. 17 is a diagram detailing the configuration of Playlistmanager and TrackManager in the first embodiment in stages.
FIG. 18 is a diagram illustrating the sizes of PlayListManager and TrackManager.
19 is a diagram showing the interrelationship between the TKI shown in FIG. 17 and the AOB file and AOB shown in FIG.
20 is a diagram showing a detailed data structure of TKTMSRT shown in FIG.
FIG. 21 is a diagram illustrating an example of TKTMSRT.
FIG. 22 is a diagram showing a detailed configuration of TKGI.
FIGS. 23A and 23B are diagrams illustrating a detailed configuration of a BIT.
(C) It is a figure which shows the data format of a TIME_LENGTH field.
FIG. 24 is a diagram illustrating clusters 007 to 00E in which AOBs including AOB_ELEMENT # 1 to # 4 are stored.
FIG. 25 is a diagram illustrating how AOB_FRAME # x + 1 to be reproduced next is set when performing forward search reproduction from AOB_FRAME # x in an arbitrary AOB_ELEMENT # y within an AOB.
FIGS. 26A and 26B are diagrams showing how AOB, AOB_ELEMENT, and AOB_FRAME corresponding to the designated time are specified when an arbitrary reproduction start time is designated.
FIGS. 27A and 27B are diagrams assuming a case where a track is deleted. FIGS.
FIG. 28A is a diagram showing the TrackManager after track deletion has been performed a plurality of times.
(B) “Unused” TKI exists, and when a new TKI or AOB file is written here, this is how the writing is performed.
FIGS. 29A and 29B are diagrams showing how TKI is set when two tracks are integrated; FIGS.
FIG. 30A is a diagram illustrating a Type 1 AOB;
(B) It is a figure which shows AOB of Type2.
FIG. 31 is a diagram showing a case where a plurality of tracks are integrated into one by a combination of (a) Type 1 + Type 2 + Type 2 + Type 1;
(B) It is a figure which shows the case where several tracks are integrated into one by the combination of Type1 + Type2 + Type2 + Type2 + Type1.
FIG. 32A is a diagram showing an arrangement pattern in which a Type 1 AOB is arranged at the end of the preceding track and a Type 1 AOB is arranged at the beginning of the following track.
(B) A diagram showing an arrangement pattern in which a Type 1 AOB is arranged at the end of a preceding track and a Type 2 AOB is arranged at the head of a following track.
(C) A diagram showing an arrangement pattern in which AOBs are arranged in the order of Type 1 and Type 2 at the end of the preceding track, and Type 1 AOBs are arranged at the head of the following track.
(D) A diagram showing an arrangement pattern in which AOBs are arranged in the order of Type 1 and Type 2 at the end of the preceding track, and Type 2 and Type 1 AOBs are arranged at the head of the following track.
(E) A diagram showing an arrangement pattern in which Type 2 and Type 2 AOBs are arranged at the end of the preceding track, and Type 1 AOB is arranged at the beginning of the following track.
FIGS. 33A and 33B are diagrams assuming a case where one track is divided into two tracks.
FIGS. 34A and 34B are diagrams showing how SD_Audio directory entries are described for the SD_Audio directory to which AOB003.SA1 belongs before and after division.
FIG. 35 is a diagram assuming that (a) AOB is divided in the middle of AOB_ELEMENT # 2.
(B) AOB is divided in the middle of AOB_ELEMENT # 2, and two AOBs AOB # 1 and AOB # 2 are obtained.
36 is a diagram illustrating how the BIT is set when the AOB is divided as illustrated in FIG. 35. FIG.
FIG. 37 is a diagram specifically showing how the BIT changes before and after the division.
FIG. 38 is a diagram specifically illustrating how TKTMSRT changes before and after division.
FIG. 39 is a diagram illustrating a format of (a) DPL_TK_SRP.
(B) It is a figure which shows the format of PL_TK_SRP.
FIG. 40 is a diagram illustrating the interrelationship between Default_Playlist information, TKI, and AOB files.
FIG. 41 is a diagram illustrating a setting example of DefaultPlaylist and PlayList information in the same notation as FIG.
FIG. 42 is a diagram illustrating a correspondence between DPL_TK_SRP and TKI using the same notation as FIG.
FIGS. 43A and 43B are diagrams assuming a case where the order of tracks is changed.
44 (a) and 44 (b) are diagrams illustrating how DefaultPlaylist, TrackManager, and AOB files are updated when DPL_TK_SRP # 2 and TKI # 2 are deleted from the DefaultPlaylist illustrated in FIG. .
FIGS. 45A and 45B are diagrams showing how the “Unused” TKI and DPL_TK_SRP exist, and when the new TKI and DPL_TK_SRP are written here, the writing is performed. .
FIGS. 46A and 46B are diagrams assuming a case where tracks are integrated.
47 (a) and 47 (b) are diagrams assuming a case where track division is performed.
FIG. 48 is a diagram showing a portable playback device for the flash memory card 31 according to the present embodiment.
FIG. 49 is a diagram illustrating an example of display contents of a liquid crystal display when a playlist is selected.
50A to 50E are diagrams showing examples of display contents of a liquid crystal display when a track is selected.
FIGS. 51A to 51C are diagrams showing an operation example of a jog dial. FIGS.
FIG. 52 is a diagram illustrating an internal configuration of a playback device.
FIG. 53 is a diagram showing how data input / output is performed in the double buffer 15;
54 (a) and 54 (b) are diagrams showing how a cyclic area reservation using a ring pointer is performed.
FIG. 55 is a flowchart showing a processing procedure for AOB file read processing;
FIG. 56 is a flowchart showing the processing procedure of AOB_FRAME output processing.
FIG. 57 is a flowchart showing a processing procedure for AOB_FRAME output processing;
FIG. 58 is a flowchart showing a processing procedure for AOB_FRAME output processing.
FIGS. 59A to 59D are diagrams showing how the playback elapsed time displayed in the time display frame of the liquid crystal display 5 increases as the variable Play_Time is updated.
FIG. 60 is a flowchart showing a processing procedure of the CPU 10 during forward search reproduction processing.
FIGS. 61A to 61D are diagrams showing how the playback elapsed time is incremented during forward search playback.
FIGS. 62A and 62B are diagrams showing a specific example when the time search function is performed.
FIG. 63 is a flowchart showing a processing procedure of an editing control program.
FIG. 64 is a flowchart showing a processing procedure of an editing control program.
FIG. 65 is a flowchart showing a processing procedure of an editing control program.
66 is a diagram showing an example of a recording device of the flash memory card 31. FIG.
Fig. 67 is a diagram illustrating a hardware configuration of a recording apparatus.
FIG. 68 is a flowchart illustrating a processing procedure for recording processing;
FIG. 69 is a diagram showing a hierarchical structure of a flash memory card in the second embodiment.
FIGS. 70A and 70B are diagrams showing internal configurations of a user data area and a protect area in the file system layer.
FIG. 71A is a diagram showing an internal configuration of POBXXX.JPG.
(B) It is a figure which shows the internal structure of the POB file containing the encrypted still image data.
(C) It is a figure which shows an example of the POB file which stored the file path instead of the encrypted entity part.
FIG. 72 is a diagram showing a detailed configuration of PlayListManager and TrackManager in the second embodiment.
73 is a diagram showing a state in which the POB file shown in FIG. 70 is specified by TKI_POB_SRP, PLI_POB_SRP, and DPLI_POB_SRP.
Fig. 74 is a diagram illustrating a data structure of TKI_POB_SRP and TKI_POB_ATR.
FIG. 75 is a diagram illustrating a setting example of TKI_POB_SRP for TKI # 1 to TKI # 3 included in TrackManager.
FIG. 76 is a diagram illustrating a setting example of TKI_POB_SRP included in TKI # 4 to TKI # 8 included in TrackManager.
FIG. 77 is a diagram illustrating DPLI_POB_SRP and DPLI_POB_ATR included in DPLGI.
[Fig. 78] Fig. 78 is a diagram illustrating a setting example of 20 DPLI_POB_SRP included in Default_Playlist information.
FIG. 79 shows how these are combined when the POB specified by DPLI_POB_SRP included in Default_Playlist information is used as a background image and the POB specified by TKI_POB_SRP included in TrackManager is used as a foreground image. It is a timing chart.
[Fig. 80] Fig. 80 is a diagram illustrating how a foreground image and a background image are combined after 6 minutes from the start of playback of Default_Playlist information.
Fig. 81 is a diagram illustrating how a foreground image and a background image are combined after 16 minutes from the start of playback of Default_Playlist information.
FIG. 82 is a diagram showing PLI_POB_SRP and PLI_POB_ATR included in PLGI.
Fig. 83 is a diagram illustrating a setting example of 20 PLI_POB_SRP included in PlayList information.
FIG. 84 shows how these are combined when the POB specified by PLI_POB_SRP included in Playlist information is used as a background image and the POB specified by TKI_POB_SRP included in TrackManager is used as a foreground image. It is a timing chart.
[Fig. 85] Fig. 85 is a diagram illustrating how the foreground image and the background image are combined after 6 minutes from the start of playback of Playlist information.
[Fig. 86] Fig. 86 is a diagram illustrating how a foreground image and a background image are combined after 16 minutes from the start of playback of Default_Playlist information.
FIG. 87 is an example in which the number of POB files is reduced by causing DPLI_POB_SRP to designate a common POB file among a plurality of DPLI_POB_SRPs in the Default_Playlist information.
FIG. 88 shows how these are combined when the POB specified by DPLI_POB_SRP included in Default_Playlist information is used as a background image and the POB specified by TKI_POB_SRP included in TrackManager is used as a foreground image. It is a timing chart.
FIG. 89 is a diagram showing an internal configuration of POBMG.
FIG. 90 is a diagram illustrating how the playback device according to the second embodiment is used;
FIG. 91 is a diagram showing an appearance of only a playback apparatus main body according to the second embodiment.
FIG. 92 is a diagram showing an internal structure of a playback apparatus according to the second embodiment.
93A is a diagram showing how still images stored in a plurality of VRAMs 61 are superimposed. FIG.
(B) It is a figure which shows how the still image stored in several VRAM61 is overlaid.
FIG. 94 is a flowchart showing a processing procedure for foreground image display processing;
FIG. 95 is a flowchart showing a processing procedure for background image display processing;
FIG. 96 is a flowchart showing a processing procedure for background image display processing;
97 (a) to (c) What happens when the foreground image specified by TKI_POB_SRP and the background image specified by DPLGI are combined by the processing procedures shown in the flowcharts of FIGS. 94 and 95? It is a figure which shows whether a synthesized image is displayed on the liquid crystal display 5. FIG.
98 (a) to (c) What happens when the foreground image specified by TKI_POB_SRP and the background image specified by PLI_POB_SRP are combined by the processing procedures shown in the flowcharts of FIGS. 94 and 96? It is a figure which shows whether a synthesized image is displayed on the liquid crystal display 5. FIG.
FIG. 99 is a flowchart showing a processing procedure of the recording apparatus according to the second embodiment.
FIG. 100A is a diagram showing an example of a phrase period table.
(B) It is a figure which shows an example of a highlight coordinate table.
[Explanation of symbols]
1 Card connector
2 User interface
3 RAM
4 ROM
5 Liquid crystal display
6 LCD driver
7 De Scrambler
8 AAC decoder
9 A / D converter
11 DPLI resident area
12 PLI storage area
13 TKI storage area
14 FileKey storage area
15 Double buffer
21 Card connector
22 RAM
23 Fixed disk unit
24 Converter
24 A / D step S
25 AAC encoder
26 Scramble
27 Modem device
28 CPU
29 keyboard
30 display
31 Flash memory card
32 Protect switch
61 VRAM

Claims (4)

A semiconductor memory card storing a plurality of audio objects, still image objects, reproduction path information, first pointer information, second pointer information, and a symbolic counter,
The playback path information indicates the playback order of audio objects,
The first pointer information corresponds to the playback path information, and indicates the playback order of the still image objects during the entire playback time of the audio object according to the playback path information,
The second pointer information corresponds to a specific audio object, and indicates the playback order of the still image objects during the entire playback time of the audio object,
The symbolic counter is associated with each still image object and indicates whether or not the corresponding still image object is designated by the first pointer information or the second pointer information. For the designated still image object, A semiconductor memory card that indicates the number of designated first pointer information and second pointer information. An editing apparatus for a semiconductor memory card according to claim 1,
Input receiving means for receiving from the user a request to delete the audio object recorded in the semiconductor memory card;
An audio object deletion means for deleting the audio object requested to be deleted from the semiconductor memory card;
A playback path information editing means for updating the playback path information defining the playback order of the audio objects to a playback order excluding the audio object requested to be deleted;
Second pointer information editing means for deleting second pointer information associated with the audio object requested to be deleted;
Symbolic counter editing means for decrementing the symbolic counter corresponding to the still image object designated by the second pointer information;
As a result of decrementing the symbolic counter of the specific still image object by the symbolic counter editing means, when the symbolic counter becomes 0, the still image object deleting means for deleting the still image object from the semiconductor memory card;
An editing device comprising: A recording medium storing a program for causing a computer to edit the semiconductor memory card according to claim 1,
An input receiving step for receiving a request to delete an audio object recorded in the semiconductor memory card from a user;
An audio object deletion step of deleting the audio object requested to be deleted from the semiconductor memory card;
A playback path information editing step for updating the playback path information defining the playback order of the audio objects to a playback order excluding the audio object requested to be deleted;
A second pointer information editing step of deleting second pointer information associated with the audio object requested to be deleted;
A symbolic counter editing step for decrementing a symbolic counter corresponding to the still image object designated by the second pointer information;
When the symbolic counter becomes 0 as a result of decrementing the symbolic counter of the specific still image object by the symbolic counter editing step, the still image object deleting step of deleting the still image object from the semiconductor memory card;
A recording medium on which a program including the program is recorded. A method of editing a semiconductor memory card according to claim 1,
An input receiving step for receiving a request to delete an audio object recorded in the semiconductor memory card from a user;
An audio object deletion step of deleting the audio object requested to be deleted from the semiconductor memory card;
A playback path information editing step for updating the playback path information defining the playback order of the audio objects to a playback order excluding the audio object requested to be deleted;
A second pointer information editing step of deleting second pointer information associated with the audio object requested to be deleted;
A symbolic counter editing step for decrementing the symbolic counter corresponding to the still image object designated by the second pointer information;
As a result of decrementing the symbolic counter of the specific still image object by the symbolic counter editing step, when the symbolic counter becomes 0, the still image object deleting step of deleting the still image object from the semiconductor memory card;
For editing a semiconductor memory card including

Images