US8175441B2 - Playback program - Google Patents
Playback program Download PDFInfo
- Publication number
- US8175441B2 US8175441B2 US12/271,125 US27112508A US8175441B2 US 8175441 B2 US8175441 B2 US 8175441B2 US 27112508 A US27112508 A US 27112508A US 8175441 B2 US8175441 B2 US 8175441B2
- Authority
- US
- United States
- Prior art keywords
- aob
- tki
- pob
- playback
- track
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related, expires
Links
Images
Classifications
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11C—STATIC STORES
- G11C7/00—Arrangements for writing information into, or reading information out from, a digital store
- G11C7/16—Storage of analogue signals in digital stores using an arrangement comprising analogue/digital [A/D] converters, digital memories and digital/analogue [D/A] converters
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/16—Sound input; Sound output
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
- G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
- G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
- G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
- G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
- G11B20/0021—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
- G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
- G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
- G11B20/0021—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier
- G11B20/00217—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier the cryptographic key used for encryption and/or decryption of contents recorded on or reproduced from the record carrier being read from a specific source
- G11B20/00253—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier the cryptographic key used for encryption and/or decryption of contents recorded on or reproduced from the record carrier being read from a specific source wherein the key is stored on the record carrier
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
- G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
- G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
- G11B20/0021—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier
- G11B20/00485—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier characterised by a specific kind of data which is encrypted and recorded on and/or reproduced from the record carrier
- G11B20/00492—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier characterised by a specific kind of data which is encrypted and recorded on and/or reproduced from the record carrier wherein content or user data is encrypted
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
- G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
- G11B27/005—Reproducing at a different information rate from the information rate of recording
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
- G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
- G11B27/02—Editing, e.g. varying the order of information signals recorded on, or reproduced from, record carriers
- G11B27/031—Electronic editing of digitised analogue information signals, e.g. audio or video signals
- G11B27/034—Electronic editing of digitised analogue information signals, e.g. audio or video signals on discs
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
- G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
- G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
- G11B27/102—Programmed access in sequence to addressed parts of tracks of operating record carriers
- G11B27/105—Programmed access in sequence to addressed parts of tracks of operating record carriers of operating discs
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N1/00—Scanning, transmission or reproduction of documents or the like, e.g. facsimile transmission; Details thereof
- H04N1/00127—Connection or combination of a still picture apparatus with another apparatus, e.g. for storage, processing or transmission of still picture signals or of information associated with a still picture
- H04N1/00132—Connection or combination of a still picture apparatus with another apparatus, e.g. for storage, processing or transmission of still picture signals or of information associated with a still picture in a digital photofinishing system, i.e. a system where digital photographic images undergo typical photofinishing processing, e.g. printing ordering
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N1/00—Scanning, transmission or reproduction of documents or the like, e.g. facsimile transmission; Details thereof
- H04N1/00127—Connection or combination of a still picture apparatus with another apparatus, e.g. for storage, processing or transmission of still picture signals or of information associated with a still picture
- H04N1/00132—Connection or combination of a still picture apparatus with another apparatus, e.g. for storage, processing or transmission of still picture signals or of information associated with a still picture in a digital photofinishing system, i.e. a system where digital photographic images undergo typical photofinishing processing, e.g. printing ordering
- H04N1/00185—Image output
- H04N1/00198—Creation of a soft photo presentation, e.g. digital slide-show
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N1/00—Scanning, transmission or reproduction of documents or the like, e.g. facsimile transmission; Details thereof
- H04N1/32—Circuits or arrangements for control or supervision between transmitter and receiver or between image input and image output device, e.g. between a still-image camera and its memory or between a still-image camera and a printer device
- H04N1/32101—Display, printing, storage or transmission of additional information, e.g. ID code, date and time or title
- H04N1/32106—Display, printing, storage or transmission of additional information, e.g. ID code, date and time or title separate from the image data, e.g. in a different computer file
- H04N1/32112—Display, printing, storage or transmission of additional information, e.g. ID code, date and time or title separate from the image data, e.g. in a different computer file in a separate computer file, document page or paper sheet, e.g. a fax cover sheet
-
- G—PHYSICS
- G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
- G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
- G09G2340/00—Aspects of display data processing
- G09G2340/12—Overlay of images, i.e. displayed pixel being the result of switching between the corresponding input pixels
-
- G—PHYSICS
- G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
- G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
- G09G3/00—Control arrangements or circuits, of interest only in connection with visual indicators other than cathode-ray tubes
- G09G3/20—Control arrangements or circuits, of interest only in connection with visual indicators other than cathode-ray tubes for presentation of an assembly of a number of characters, e.g. a page, by composing the assembly by combination of individual elements arranged in a matrix no fixed position being assigned to or needed to be assigned to the individual characters or partial characters
- G09G3/2092—Details of a display terminals using a flat panel, the details relating to the control arrangement of the display terminal and to the interfaces thereto
-
- G—PHYSICS
- G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
- G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
- G09G5/00—Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators
- G09G5/36—Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators characterised by the display of a graphic pattern, e.g. using an all-points-addressable [APA] memory
- G09G5/39—Control of the bit-mapped memory
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
- G11B2220/00—Record carriers by type
- G11B2220/60—Solid state media
- G11B2220/61—Solid state media wherein solid state memory is used for storing A/V content
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
- G11B2220/00—Record carriers by type
- G11B2220/60—Solid state media
- G11B2220/65—Solid state media wherein solid state memory is used for storing indexing information or metadata
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N2201/00—Indexing scheme relating to scanning, transmission or reproduction of documents or the like, and to details thereof
- H04N2201/32—Circuits or arrangements for control or supervision between transmitter and receiver or between image input and image output device, e.g. between a still-image camera and its memory or between a still-image camera and a printer device
- H04N2201/3201—Display, printing, storage or transmission of additional information, e.g. ID code, date and time or title
- H04N2201/3261—Display, printing, storage or transmission of additional information, e.g. ID code, date and time or title of multimedia information, e.g. a sound signal
- H04N2201/3264—Display, printing, storage or transmission of additional information, e.g. ID code, date and time or title of multimedia information, e.g. a sound signal of sound signals
Definitions
- the present invention relates to a semiconductor memory card that stores audio data, still image data and control data, and to a playback apparatus, recording apparatus, playback method, recording method, and computer-readable recording medium relating to such a semiconductor memory card.
- the present invention relates to improved storage of audio data, image data and control data distributed as contents by a content distribution service, such as an electronic music distribution service.
- Electronic music distribution enables users to purchase and receive music contents (e.g., songs and albums) via the Internet.
- music contents e.g., songs and albums
- Such technology has the potential to greatly change the market for recorded music and is gradually becoming possible as the necessary infrastructure is introduced.
- One way to store music contents that are obtained from an electronic music distribution service is on semiconductor memory cards whose portability makes them ideal. Accordingly, a great increase is expected in the demand for such cards.
- Music contents are not restricted to merely containing audio data.
- “mixed-media” audio contents can include related images that are to be displayed when music is played back.
- Such mixed-media audio contents can be used for “karaoke software” that is composed of a backing audio track and images for the lyrics of a song and a background. It is believed such mixed-media audio contents will also be subject to electronic music distribution, so that it is necessary to consider how such contents should be stored in a semiconductor memory card.
- a recording medium such as a CD (Compact Disc), which is to say, how audio data and image data are conventionally stored on a recording medium.
- CD Compact Disc
- a conventional mixed-media music content is recorded onto a recording medium as multiplexed data produced by multiplexing audio data for the music with image data for the lyrics and/or background images.
- the image data can be displayed while the audio data is being played back.
- a CD-Graphics disc is one example of a medium that enables image data to be displayed while audio data is being played backed by having such data multiplexed together.
- data is multiplexed in units composed of 16-bit main codes and subcodes. Audio data is assigned to the 16-bit main codes, while image data for lyrics, background images and the like is assigned to the subcodes.
- playback commences for any of the music contents recorded on a CD-Graphics disc, the audio data assigned to the 16-bit main codes is successively played back while the image data assigned to the subcodes is successively displayed.
- the sharing of image data (still image objects) between a plurality of audio objects can be preferably achieved by a semiconductor memory card storing: an audio sequence including a plurality of audio objects; a plurality of still image objects; at least one piece of playback route information showing an order in which audio objects, out of the plurality of audio objects in the audio sequence, are to be played back; at least one piece of first pointer information, each of which corresponds to a piece of playback route information and specifies at least one still image object that should be displayed when the audio objects in the order indicated by the corresponding piece of playback route information are played back; and at least one piece of second pointer information, each of which corresponds to an audio object in the audio sequence and specifies at least one still image object that should be displayed only during playback of the corresponding audio object.
- a plurality of audio objects in an audio sequence are played back in accordance with a playback order given in a piece of playback route information.
- Still image objects that are to be displayed as background images during the playback of the audio objects are indicated by the first pointer information corresponding to the playback route information.
- shared still image objects can be displayed during the playback period of the plurality of audio objects included in the audio sequence.
- the same image or images can be displayed during the playback of a plurality of audio objects in an audio sequence that corresponds to an album by a minor recording artist. This reduces the cost and effort of producing images for such an album.
- a plurality of different images can be provided for display during the playback of each audio object in an audio sequence that corresponds to an album by a major recording artist. Displaying a number of different images for each track makes the album more appealing to customers, and so can improve sales.
- still image objects such as for song lyrics
- still image objects can be specified using second pointer information to assign the still image objects to only the particular track.
- the semiconductor memory card may further store a plurality of symbolic counters, each of which corresponds to a still image object and shows whether the still image object is specified by any of the at least one piece of first pointer information and the at least one piece of second pointer information and, if so, how many pieces of first pointer information and second pointer information specify the still image object.
- the recording apparatus for a semiconductor memory card specifies the second pointer information for the deleted audio objects and audio sequences and the first pointer information for any deleted audio sequence.
- the recording apparatus then decrements the numbers assigned to still image objects to show how many pieces of first pointer information and second pointer information specify each object.
- the recording apparatus assumes that no piece of first pointer information or second pointer information specifies the still image object and so deletes the still image object.
- FIG. 1 shows the appearance of a flash memory card 31 when viewed from above
- FIG. 2 shows the construction of the flash memory card 31 when viewed from below
- FIG. 3 shows the hierarchical composition of the flash memory card 31 in the embodiments
- FIG. 4A shows the special region, the authentication region and the user region provided in the physical layer of the flash memory card 31 ;
- FIG. 4B shows the composition of the authentication region and the user region in the file system layer
- FIG. 5 shows the detailed composition of the file system layer
- FIG. 6 is a representation of when the AOB file “AOB001.SA1” is divided into five parts that are stored in clusters 003, 004, 005, 00A, and 00C;
- FIG. 7 shows one example of the settings of the directory entries and file allocation table when the AOB file “AOB001.SA1” is recorded in a plurality of clusters;
- FIGS. 8A and 8B show what directories are provided in the user region and the authentication region in the file system layer when the above two types of data are recorded in the application layer, as well as what kind of files are recorded in which directories;
- FIG. 9 shows the correspondence between the file “AOBSA1.KEY” and the AOB files in the SD_Audio directories
- FIG. 10 shows the hierarchical composition of the data in an AOB file
- FIG. 11A shows the parameters stipulated by ISO/IEC 13818-7 standard in tabular form
- FIG. 11B shows the parameters that should be used when encoding a file in MPEG-Layer 3 (MP3) format in tabular form
- FIG. 11C shows the parameters that should be used when encoding a file in Windows Media Audio (WMA) format in tabular form
- FIG. 12 shows the detailed construction of an AOB_FRAME
- FIG. 13 shows how the byte length of the audio data in each of three AOB_FRAMEs is set
- FIG. 14 shows the correspondence between the sampling_frequency and the number of AOB_FRAMEs included in an AOB_ELEMENT
- FIG. 15 shows examples of the playback periods of AOB_ELEMENTs and the playback periods of AOB_FRAMEs
- FIG. 16 shows what is reproduced when the AOBs and AOB_BLOCKs recorded in an AOB file are consecutively played back
- FIG. 17 shows the hierarchical composition of the PlaylistManager and TrackManager used in the embodiments in detail
- FIG. 18 shows the sizes of the PlaylistManager and the TrackManager
- FIG. 19 shows the correspondence between the TKIs shown in FIG. 17 and the AOBs and AOB files shown in FIG. 16 ;
- FIG. 20 shows the detailed data composition of the TKTMSRT shown in FIG. 17 ;
- FIG. 21 shows one example of the TKTMSRT
- FIG. 22 shows the detailed composition of the TKGI
- FIGS. 23A and 23B show the composition of the BIT
- FIG. 23C shows the Time_Length field
- FIG. 24 shows cluster 007 to 00E into which the AOB composed of AOB_ELEMENT# 1 to AOB_ELEMENT# 4 are stored;
- FIG. 25 shows how the next AOB_FRAME#x+1 to be played back is set when forward search is performed starting from the AOB_FRAME#x in an arbitrary AOB_ELEMENT#y in an AOB;
- FIGS. 26A and 26B shows how an AOB, an AOB_ELEMENT, and an AOB_FRAME that correspond to an arbitrary playback time code are specified
- FIGS. 27A and 27B show the deletion of a track
- FIG. 28A shows the TrackManager after the deletion of a track has been performed several times
- FIG. 28B shows how a new TKI and AOB file are written when “Unused” TKIs are present in the TrackManager;
- FIGS. 29A and 29B show the TKIs are set when two tracks are combined to produce a new track
- FIG. 30A shows a Type1 AOB
- FIG. 30B shows Type2 AOBs
- FIG. 31A shows the combining of a plurality of tracks into a single track for a combination of a Type1+Type2+Type2+Type1 AOB;
- FIG. 31B shows the combining of a plurality of tracks into a single track for a combination of a Type1+Type2+Type2+Type2+Type1 AOB;
- FIG. 32A shows a pattern where a Type1 AOB is present at the end of a preceding track and a Type1 AOB is present at the start of a next track;
- FIG. 32B shows a pattern where a Type1 AOB is present at the end of a first track and a Type2 AOB is present at the start of a next track;
- FIG. 32C shows a pattern where a Type1 and Type2 AOB are present at the end of a first track and a Type1 AOB is present at the start of a next track;
- FIG. 32D shows a pattern where a Type1 and Type2 AOB are present at the end of a first track and a Type2 and a Type1 AOB is present at the start of a next track;
- FIG. 32E shows a pattern where two Type2 AOBs are present at the end of a first track and a Type1 is present at the start of a next track;
- FIGS. 33A and 33B show the division of a track to produce two tracks
- FIGS. 34A and 34B show the content of the SD_Audio directory entries in the SD_Audio directory including the AOB file “AOB003.SA1” before and after the division of the track;
- FIG. 35A shows the division of an AOB midway through AOB_ELEMENT# 2 ;
- FIG. 35B shows the two AOBs, AOB# 1 and AOB# 2 , obtained by dividing an AOB midway through AOB_ELEMENT# 2 ;
- FIG. 36 shows how the BIT is set when an AOB is divided as shown in FIG. 35 ;
- FIG. 37 shows a specific example of changes in the BIT before and after division
- FIG. 38 shows a specific example of changes in the TKTMSRT before and after division
- FIG. 39A shows the format of a DPL_TK_SRP
- FIG. 39B shows the format of a PL_TK_SRP
- FIG. 40 shows the interrelation between the Default_Playlist_Information, the TKIs, and the AOB files
- FIG. 41 shows example settings for the Default_Playlist and several PLIs
- FIG. 42 shows how the DPL_TK_SRPs correspond to TKIs using the same notation as FIG. 40 ;
- FIGS. 43A and 43B show how the order of tracks is rearranged
- FIGS. 44A and 44B show how the Default_Playlist, TrackManager, and AOB files will be updated when DPL_TK_SRP# 2 and TKI# 2 are deleted from the Default_Playlist shown in FIG. 40 ;
- FIGS. 45A and 45B show how a new TKI and DPL_TK_SRP are written when an “Unused” TKI and DPL_TK_SRP are present;
- FIGS. 46A and 46B show how tracks are combined
- FIGS. 47A and 47B show how a track is divided
- FIG. 48 shows the appearance of a portable playback apparatus for the flash memory card 31 of the present embodiments
- FIG. 49 shows one example of the display on the LCD panel when a playlist is selected
- FIGS. 50A to 50E show examples of the display on the LCD panel when a track is selected
- FIGS. 51A to 51C show example operations of the jog dial
- FIG. 52 shows the internal construction of the reproduction apparatus
- FIG. 53 shows how data is transferred in and out of the double buffer 15 ;
- FIGS. 54A and 54B show how areas in the double buffer 15 are cyclically allocated using ring pointers
- FIG. 55 is a flowchart showing the AOB file read procedure
- FIG. 56 is a flowchart showing the AOB file output procedure
- FIG. 57 is a flowchart showing the AOB file output procedure
- FIG. 58 is a flowchart showing the AOB file output procedure
- FIGS. 59A to 59D show how the playback time code displayed in the playback time code frame on the LCD panel 5 is updated in accordance with the updating of the variable Play_time;
- FIG. 60 is a flowchart showing the processing of the CPU 10 when the forward search function is used.
- FIGS. 61A to 61D show how the playback time code is incremented when the forward search function is used
- FIGS. 62A and 62B show specific examples of how the time search function is used
- FIG. 63 is a flowchart showing the processing in the editing control program
- FIG. 64 is a flowchart showing the processing in the editing control program
- FIG. 65 is a flowchart showing the processing in the editing control program
- FIG. 66 shows one example of a recording apparatus for recording data onto the flash memory card 31 ;
- FIG. 67 shows the hardware configuration of the recording apparatus
- FIG. 68 is a flowchart showing the processing during recording
- FIG. 69 shows the internal construction of a flash memory card according to the second embodiment of the present invention.
- FIGS. 70A and 70B show the internal composition of the user data area and the protected area in the file system layer
- FIG. 71A shows the internal composition of a “POBXXX.JPG” file
- FIG. 71B shows the internal composition of a POB file that includes encrypted still image data
- FIG. 71C shows an example of a POB file that stores a file path in place of an encrypted data body
- FIG. 72 shows the detailed compositions of the PlaylistManager and TrackManager in the second embodiment
- FIG. 73 shows how the POB files shown in FIG. 70 are specified by TKI_POB_SRPs, PLI_POB_SRPs, and DPLI_POB_SRPs;
- FIG. 74 shows the data compositions of the TKI_POB_ATR and a TKI_POB_SRP;
- FIG. 75 shows example settings of the TKI_POB_SRPs for TKI# 1 to TKI# 3 in the TrackManager;
- FIG. 76 shows example settings of the TKI_POB_SRPs for TKI# 4 to TKI# 8 in the TrackManager;
- FIG. 77 shows the DPLI_POB_SRPs and DPLI_POB_ATR included in the DPLGI;
- FIG. 78 shows an example setting of twenty DPLI_POB_SRPs included in the Default_Playlist_Information
- FIG. 79 is a timing chart showing how a combined image is formed when a POB specified by a DPLI_POB_SRP included in the Default_Playlist_Information is used as a background image and a POB specified by a TKI_POB_SRP included in the TrackManager is used as a foreground image;
- FIG. 80 shows how a background image and foreground image are combined at a point six minutes after the start of playback according to the Default_Playlist_Information
- FIG. 81 shows how a background image and foreground image are combined at a point sixteen minutes after the start of playback according to the Default_Playlist_Information
- FIG. 82 shows the PLI_POB_SRPs and PLI_POB_ATR included in a PLGI
- FIG. 83 shows an example setting of twenty PLI_POB_SRPs included in a PLI
- FIG. 84 is a timing chart showing how a combined image is formed when a POB specified by a PLI_POB_SRP included in a PLI is used as a background image and a POB specified by a TKI_POB_SRP included in the TrackManager is used as a foreground image;
- FIG. 85 shows how a background image and foreground image are combined at a point six minutes after the start of playback according to a PLI
- FIG. 86 shows how a background image and foreground image are combined at a point sixteen minutes after the start of playback according to a PLI
- FIG. 87 shows an example where the number of POB files is reduced by having a number of DPLI_POB_SRPs in the Default_Playlist_Information specify the same POB files;
- FIG. 88 is a timing chart showing how a combined image is formed when a POB specified by a DPLI_POB_SRP included in the Default_Playlist_Information is used as a background image and a POB specified by a TKI_POB_SRP included in the TrackManager is used as a foreground image;
- FIG. 89 shows the internal composition of the POBMG
- FIG. 90 shows how the playback apparatus of the second embodiment is used
- FIG. 91 shows the external appearance of only the playback apparatus of the second embodiment
- FIG. 92 shows the internal construction of the playback apparatus of the second embodiment
- FIG. 93A shows how the still images stored in the plurality of VRAMs 61 can be laid on top of one another
- FIG. 93B also shows how the still images stored in the plurality of VRAMs 61 can be laid on top of one another;
- FIG. 94 is a flowchart showing the foreground image display procedure
- FIG. 95 is a flowchart showing the background image display procedure
- FIG. 96 is a flowchart showing the background image display procedure
- FIGS. 97A to 97C show what kind of combined image is displayed on the LCD panel 5 due to the processing in the flowcharts in FIGS. 94 and 95 that has a POB specified by a TKI_POB_SRP displayed as a foreground image and a POB specified by a DPLI_POB_SRP displayed as a background image;
- FIGS. 98A to 98C show what kind of combined image is displayed on the LCD panel 5 due to the processing in the flowcharts in FIGS. 94 and 96 that has a POB specified by a TKI_POB_SRP displayed as a foreground image and a POB specified by a PLI_POB_SRP displayed as a background image;
- FIG. 99 is a flowchart showing the procedure used by the recording apparatus of the second embodiment.
- FIG. 100A shows an example of the phrase timing table
- FIG. 100B shows an example of the highlight coordinate table.
- flash memory card flash memory card
- the length of a reference number shows the level of the topic in the hierarchy.
- the number x 1 is the number of drawing that is being referred to in the explanation.
- the drawings attached to this specification have been numbered in the order in which they are referred to in the specification, so that the order of the drawings roughly matches the order of the explanation.
- the explanation of certain drawings has been divided into sections, with the reference number x 2 giving the section number of a section in the explanation of a drawing indicated by the reference number x 1 .
- the reference number x 3 shows the number of an additional drawing that is provided to show the details of the section indicated by the section number x 2 .
- the reference number x 4 shows the number of a section in the explanation of this additional drawing.
- FIG. 1 shows the appearance of the flash memory card 31 when viewed from above
- FIG. 2 shows the construction of the flash memory card 31 when viewed from below.
- the flash memory card 31 is around the same size as a postage stamp, and so is large enough to be held by hand. Its approximate dimensions are 32.0 mm long, 24.0 mm wide, and 2.0 mm thick.
- the flash memory card 31 can be seen to have nine connectors on its bottom edge for connecting the card to a compatible device and a protect switch 32 on one side to enable the user to set whether overwriting of the stored content of the flash memory card 31 is permitted or prohibited.
- FIG. 3 shows the hierarchical structure of the semiconductor memory card (hereafter referred to as the “flash memory card 31 ”) of the present embodiment.
- the flash memory card 31 is constructed with a physical layer, a file system layer and an application layer in the same way as a DVD (Digital Video Disc), though the logical and physical constructions of these layers are very different to those on a DVD.
- DVD Digital Video Disc
- the flash memory is composed of a plurality of sectors, each of which stores 512 bytes of digital data.
- the three regions shown in FIG. 4A are provided in the storage area composed of these valid sectors. These regions are the “special region”, the “authentication region” and the “user region”, and are described in detail below.
- the user region is characterized in that a device to which the flash memory card 31 is connected can freely read or write various kinds of data from or into this region. Areas within the user region are managed by a file system.
- the special region stores a media ID that is a value uniquely assigned to each flash memory card 31 . Unlike the user region, this region is read-only, so that the media ID stored in the special region cannot be changed.
- the authentication region is a writeable region, like the user region. This region differs from the user region in that a device connected to the flash memory card 31 can access (i.e., read or write data in) the authentication region only if the flash memory card 31 and the device have first confirmed that each other is an authentic device. In other words, data can only be read from or written into the authentication region if mutual authentication has been successfully performed by the flash memory card 31 and the device connected to the flash memory card 31 .
- the region used to store this data will depend on whether copyright protection is necessary for the data being written.
- the data is encrypted using a predetermined encryption key (called a “FileKey”) before being written into the user area.
- This FileKey can be freely set by the copyright holder and, while the use of this FileKey provides some level of copyright protection, the FileKey used for encrypting the written data is itself encrypted to make the copyright protection more secure. Any value obtained by subjecting the media ID stored in the special region into a predetermined calculation can be used to encrypt the FileKey.
- the encrypted FileKey produced in this way is stored in the authentication region.
- the construction of the physical layer of the flash memory card 31 strengthens the copyright protection of the data written in the flash memory card 31 .
- UDF Universal Disk Format
- FAT File Allocation Table
- the partition boot sectors are sectors that store the data that will be referred to by a standard personal computer that is connected to the flash memory card 31 when the flash memory card 31 is set as the boot disk for the operating system (OS) of the personal computer.
- OS operating system
- the data region can be accessed by a device connected to the flash memory card 31 in units no smaller than a “cluster”. While each sector in the flash memory card 31 is 512 bytes in size, the cluster size is 16 KB, so that the file system layer reads and writes data in units of 32 sectors.
- the reason the cluster size is set at 16 KB is that when data is written onto the flash memory card 31 , part of the data stored in the flash memory card 31 first has to be erased before the write can be performed.
- the smallest amount of data that can be erased in the flash memory card 31 is 16 KB, so that setting the smallest erasable size as the cluster size means that data writes can be favorably performed.
- the arrow ff 2 drawn using a broken line in FIG. 5 shows the plurality of clusters 002, 003, 004, 005 . . . included in the data region.
- the numbers 002, 003, 004, 005, 006, 007, 008 . . . used in FIG. 55 are the three-digit hexadecimal cluster numbers that are exclusively assigned to identify each cluster. Since the smallest unit by which access can be performed is one cluster, storage positions within the data region are indicated using cluster numbers.
- the file allocation system has a file system construction in accordance with ISO/IEC 9293 standard, and so is made up of a plurality of FAT values.
- Each FAT value corresponds to a cluster and shows which cluster should be read after the cluster corresponding to the FAT value.
- the arrow ff 1 shown by a broken line in FIG. 5 shows the plurality of FAT values 002, 003, 004, 005 . . . that are included in the file allocation table.
- the numbers 002, 003, 004, 005 . . . assigned to each FAT value show which cluster corresponds to each FAT value and therefore are the cluster numbers of the clusters corresponding to the FAT values.
- the “root directory entries” are information showing what kinds of files are present in the root directory.
- the “filename” of an existing file, its “filename extension”, the “revision time/date” and “number of first cluster in file” showing where the start of the file is stored can be written as the root directory entry of a file.
- Information relating to files in the root directory is written as root directory entries, though information relating to subdirectories is not written as the root directory entries.
- Directory entries for subdirectories are instead produced in the data region.
- the SD-Audio directory entry given in the data region is one example of a directory entry for a subdirectory.
- an SD-Audio directory entry includes the “filename” of a file present in this subdirectory, its “filename extension”, the “revision time/date” and “number of first cluster in file” showing where the start of the file is stored.
- the following describes the file storage method by showing how a file named “AOB001.SA1” is stored in the SD-Audio directory, with reference to FIG. 6 . Since the smallest unit by which the data region can be accessed is one cluster, the file “AOB001.SA1” needs to be stored in the data region in parts that are no smaller than one cluster. The file “AOB001.SA1” is therefore stored having first been divided into clusters. In FIG. 6 , the file “AOB001.SA1” is divided into five parts in keeping with the cluster size, and the resulting parts are stored into the clusters numbered 003, 004, 005, 00A, and 00C.
- the application layer in the flash memory card 31 is composed of presentation data and navigation data that is used to control the playback of the presentation data.
- the presentation data includes sets of audio objects (AOB sets) that are produced by encoding audio data that represents music, for example.
- the navigation data includes a “PlaylistManager” (PLMG) and a “TrackManager” (TKMG).
- FIGS. 8A and 8B show what kind of directories are present in the user region and the authentication region in the file system layer when these two types of data are stored in the application layer, as well as showing what files are arranged into these directories.
- the filenames “SD_AUDIO.PLM” and “SD_AUDIO.TKM” in FIG. 8A indicate the files in which the PlaylistManager (PLMG) and TrackManager (TKMG) composing the navigation information are stored. Meanwhile, the filenames, “AOB001.SA1”, “AOB002.SA1”, “AOB003.SA1”, “AOB004.SA1”, . . . indicate the files (“AOB” files) storing the audio objects that are the presentation data.
- the letters “SA” in the filename extension of the filename “AOB0xx.SA1” are an abbreviation for “Secure Audio”, and show that the stored content of this file requires copyright protection. Note that while only eight AOB files are shown in the example in FIG. 8A , a maximum of 999 AOB files can be stored in an SD-Audio directory.
- SD-Audio directory When copyright protection is required for presentation data, a subdirectory called an “SD-Audio directory” is provided in the authentication region and an encryption key storing file “AOBSA1.KEY” is produced in this SD-Audio directory.
- FIG. 8B shows the encryption key storing file I“AOBSA1.KEY” that is stored under the “SD-Audio” legend (i.e., within the “SD-Audio directory”).
- This encryption key storing file “AOBSA1.KEY” stores a sequence of encryption keys that is produced by arranging a plurality of encryption keys into a predetermined order.
- the SD-Audio directory shown in FIGS. 8A and 8B is stored in a server computer managed by a record label that uses electronic music distribution.
- the corresponding SD-Audio directory is compressed, encrypted and transmitted to the consumer via a public network.
- the consumer's computer receives this SD-Audio directory, decrypts it, decompresses it and so obtains the original SD-Audio directory.
- public network here refers to any kind of network that can be used by the public, such as a wired communication network, e.g., an ISDN network, or a wireless communication network, e.g., a mobile telephone system. It is also possible for a consumer's computer to download an AOB file from a server computer operated by a record label and then produce an SD-Audio directory, such as that shown in FIGS. 8A and 8B , in the flash memory card 31 .
- FIG. 9 shows the correspondence between the “AOBSA1.KEY” file in the SD-Audio directory and the AOB files.
- the File Keys used when encrypting files in the user region shown in FIG. 9 are stored in the corresponding encryption key storing file in the authentication region.
- the encrypted AOB files and the encryption key storing file correspond according to the predetermined rules (1), (2), and (3) described below.
- the encryption key storing file is arranged into a directory with the same directory name as the directory in which the encrypted file is stored.
- AOB files are arranged into the SD-Audio directory in the user region and the encryption key storing file is arranged into a directory called the SD-Audio directory in the authentication region, in accordance with this rule.
- the encryption key storing file is given a filename produced by combining the first three letters of the filename of the AOB files in the data region with the predetermined “.key” extension.
- the encryption key storing file is given the filename “AOBSA1.KEY” produced by adding the first three characters “AOB”, “SA1”, and the extension “.key”, as shown by the arrows nk 1 and nk 2 in FIG. 9 .
- the “File Key Entries # 1 , # 2 , # 3 . . . # 8 ” show the first positions of the regions in which the respective FileKeys in the encryption key storing file are stored. Meanwhile, the filenames of AOB files are assigned the serial numbers “001”, “002”, “003”, “004” . . . . These serial numbers show the positions of the corresponding FileKeys in the encryption key sequence, so that the FileKey that was used to encrypt each AOB file will be present in the “FileKey Entry” with the same serial number.
- the arrows Ak 1 , Ak 2 , Ak 3 , . . . show the correspondence between AOB files and FileKeys.
- the file “AOB001.SA1” corresponds to the FileKey whose storage position is indicated by the “FileKey Entry# 1 ”
- the file “AOB002.SA1” corresponds to the FileKey whose storage position is indicated by the “FileKey Entry# 2 ”
- the file “AOB003.SA1” corresponds to the FileKey whose storage position is indicated by the “FileKey Entry# 3 ”.
- different FileKeys are used to encrypt different AOB files, with these FileKeys being stored in “FileKey Entries” with the serial numbers “001”, “002”, “003”, “004” etc., given in the filenames of the corresponding AOB files.
- each AOB file is encrypted using a different FileKey, the exposure of the encryption key used for one AOB file will not enable users to decrypt other AOB files. This means that when AOB files are stored in an encrypted form on a flash memory card 31 , the damage caused by the exposure of one FileKey can be minimized.
- FIG. 10 shows the hierarchical data structure of an AOB file.
- the first level in FIG. 10 shows the AOB file, while the second level shows the audio object (AOB) itself.
- the third level shows the AOB_BLOCKs, the fourth level an AOB_ELEMENT, and the fifth level an AOB_FRAME.
- the AOB_FRAME on the fifth level in FIG. 10 is the smallest unit composing the AOB, and is composed of audio data in ADTS (Audio Data Transport Stream) format and an ADTS header. Audio data in ADTS format is encrypted according to MPEG2-AAC (Low Complexity Profile) format and is stream data that can be played back at a transfer rate of 16 Kbps to 144 Kbps. Note that the transfer rate for PCM (Pulse Code Modulation) that is recorded on a conventional compact disc is 1.5 Mbps, so that data in ADTS format generally uses a lower transfer rate than PCM.
- the data construction of a sequence of AOB_FRAMEs is the same as the sequence of audio frames included in an audio data transport stream distributed by an electronic music distribution service.
- AOB_FRAME sequence is encoded according to MPEG2-ACC standard, encrypted, and transmitted on a public network to the consumer.
- AOB files are produced by dividing the transmitted audio data transport stream into a sequence of AOB_FRAMEs and storing these AOB_FRAMEs.
- MPEG2-AAC is described in detail in ISO/IEC 13818-7:1997(E) “Information Technology—Generic Coding of Moving Pictures and Associated Audio Information—Part7 Advanced Audio Coding (AAC)”.
- audio objects can only be compressed according to MPEG2-AAC using the parameters in the parameter table shown in FIG. 11A that is defined in ISO/IEC13818-7.
- This parameter table is composed of
- the legend “profile” in the Parameter column shows the only LC-profile which can be used, as stipulated under ISO/IEC 13838-7.
- the legend “sampling_frequency#index” in the Parameter column shows that the sampling frequencies “48 kHz, 44.1 kHz, 32 kHz, 24 kHz, 22.05 kHZ, and 16 kHz” can be used.
- AOB_FRAMEs are encoded according to MPEG-AAC format
- AOB_FRAMEs may instead be encoded according to another format, such as MPEG-Layer3 (MP3) format or Windows Media Audio (WMA).
- MP3 MPEG-Layer3
- WMA Windows Media Audio
- each AOB_FRAME includes audio data that is encoded according to the restrictions described above, the data length of the audio data in each AOB_FRAME is restricted to a playback time of only 20 ms.
- MPEG2-AAC is a variable bitrate (VBR) encoding method
- VBR variable bitrate
- the first level in FIG. 12 shows the overall composition, while the second level shows how each part of an AOB_FRAME is encrypted.
- the ADTS header corresponds to a non-encrypted part.
- the audio data includes both an encrypted part and a non-encrypted part.
- the encrypted part of the audio data is composed of a plurality of eight-byte pieces of encrypted data, each of which is produced by encrypting an eight-byte piece of audio data using a 56-bit FileKey.
- the non-encrypted part of the audio data is simply a final part of the data that cannot be encrypted due to it being shorter than 64 bits.
- the third level in FIG. 12 shows the content of the ADTS header that is in the non-encrypted part of the AOB_FRAME.
- the ADTS header is seven bytes long, and includes a 12-bit synch word (set at FFF), the data length of the audio data in this AOB_FRAME, and the sampling frequency used when the audio data was encoded.
- FIG. 13 shows how the byte length of the audio data in each of three AOB_FRAMEs is set.
- the data length of audio data# 1 included in AOB_FRAME# 1 is x 1
- the data length of audio data# 1 included in AOB_FRAME# 2 is x 2
- the data length of audio data# 1 included in AOB_FRAME# 3 is x 3 .
- the data length x 1 will be written in the ADTS header of AOB_FRAME# 1
- the data length x 2 will be written in the ADTS header of AOB_FRAME# 2
- the data length x 3 will be written in the ADTS header of AOB_FRAME# 3 .
- the ADTS header is not, so that a playback device can determine the data length of the audio data in an AOB_FRAME by reading the data length given in the ADTS header of the AOB_FRAME.
- An “AOB_ELEMENT” is a group of consecutive AOB_FRAMEs.
- the number of AOB_FRAMEs in an AOB_ELEMENT depends on the value set as the sampling_frequency_index shown in FIG. 11A and the encoding method used.
- the number of AOB_FRAMEs in an AOB_ELEMENT is set so that the total playback time of the included AOB_FRAMEs will be around two seconds, with this number depending on the sampling frequency and encoding method used.
- FIG. 14 shows the correspondence between the sampling frequency and the number of AOB_FRAMEs included in an AOB_ELEMENT.
- the number N given in FIG. 14 represents the playback period of an AOB_ELEMENT in seconds.
- MPEG-ACC is used as the encoding method, the value of N is “2”.
- the number of AOB_FRAMEs included in an AOB_ELEMENT at the start or end of an AOB may be less than a number calculated in this way.
- each AOB_ELEMENT While no header or other special information is provided for each AOB_ELEMENT, the data length of each AOB_ELEMENT is instead shown by a time search table.
- FIG. 15 shows one example of the playback periods of AOB_ELEMENTs and AOB_FRAMEs.
- the first level in FIG. 15 shows a plurality of AOB_BLOCKs, while the second level shows a plurality of AOB_ELEMENTs.
- the third level shows a plurality of AOB_FRAMEs.
- an AOB_ELEMENT has a playback period of around 2.0 seconds, while an AOB_FRAME has a playback period of 20 milliseconds.
- the “TMSRT_entry” given to each AOB_ELEMENT shows that the data length of each AOB_ELEMENT is given in the time search table.
- a playback apparatus can perform a forward or backward search where, for example, intermittent bursts of music are played back by repeatedly playing back 240 milliseconds of audio data and then skipping two seconds of audio data in the desired direction.
- Each “AOB_BLOCK” is composed of valid AOB_ELEMENTs. Only one AOB_BLOCK exists in each AOB_FILE. While an AOB_ELEMENT has a playback period of around two seconds, an AOB_BLOCK has a maximum playback period of 8.4 minutes. The 8.4 minute limitation is imposed to restrict the size of the time search table to 504 bytes or less.
- the playback apparatus When a playback apparatus performs a forward or backward search, the playback apparatus skips the reading of two seconds of audio data before playing back 240 milliseconds. When skipping two seconds of data, the playback apparatus could in theory refer to the data lengths shown in the ADTS headers of AOB_FRAMEs, though this would mean that the playback apparatus would have to consecutively detect 100 (2 seconds/20 milliseconds) AOB_FRAMEs just to skip two seconds of audio data. This would amount to an excessive processing load for the playback apparatus.
- the read addresses for data at two-second intervals can be written into a time search table that is then referred to by the playback apparatus when performing a forward or backward search.
- a playback apparatus By writing information that enables read addresses that are two or four seconds ahead or behind to be found quickly into the time search table (such information being the data sizes of AOB_ELEMENTs), a playback apparatus will only need to refer to this information when performing a forward or backward search.
- the data size of audio data with a playback period of two seconds will depend on the bitrate used when playing back the audio data.
- the AOBs shown on the second level of FIG. 10 are regions that have invalid areas at either end. Only one AOB is present in each AOB file.
- the invalid areas are regions that are read and written along with the AOB_BLOCKs and are stored in the same clusters as the AOB_BLOCKS.
- the start and end position of the AOB_BLOCKs within an AOB are shown by BITs included in the navigation data. These BITs are described in detail later in this specification.
- FIG. 16 shows the playback content when the AOBs and AOB_BLOCKs in this AOB file are successively read.
- the first level in FIG. 16 shows the eight AOB files in the user region, while the second level shows the eight AOBs recorded in these AOB files.
- the third level shows the eight AOB_BLOCKs included in these AOBs.
- the fifth level shows the titles of five contents composed by these AOB files.
- the “contents” are the five songs SongA, SongB, SongC, SongD, and SongE, while the “title” is a music album composed of these five songs.
- the broken lines AS 1 , AS 1 , AS 3 , . . . AS 7 , and AS 8 show the correspondence between the AOB_BLOCKs and the parts into which the album is divided, so that the fourth level in FIG. 16 shows the units used to divide the music album shown on the fifth level.
- the AOB_BLOCK included in AOB# 1 is a song (SongA) with a playback period of 6.1 minutes.
- the AOB_BLOCK included in AOB# 2 is a song (SongB) with a playback period of 3.3 minutes.
- the AOB_BLOCK included in AOB# 3 is a song (SongC) with a playback period of 5.5 minutes.
- “AOB001.SA1” to “AOB003.SA1” each correspond to a different song.
- the sixth level of FIG. 16 is a track sequence composed of tracks TrackA to TrackE. These tracks TrackA-TrackE correspond to the five songs SongA, SongB, SongC, SongD, and SongE, and are each treated as a separate playback unit.
- AOB# 4 has a playback period of 8.4 minutes and is the first (or “head”) part of the song SongD that has a playback period of 30.6 minutes.
- the AOB_BLOCKs included in AOB# 5 and AOB# 6 are middle parts of the song SongD and also have playback periods of 8.4 minutes.
- the AOB_BLOCK included in AOB# 7 is the end part of the song SongD and has a playback period of 5.4 minutes. In this way, a song that has a total playback period of 30.6 minutes is divided into (8.4+8.4+8.4+5.4-minute) parts that are each included in a different AOB. As can be seen from FIG. 16 , every song included in an AOB file is subjected to a maximum playback period of 8.4 minutes.
- the navigation data is composed of the two files “SD_Audio.PLM” and “SD_Audio.TKM” mentioned earlier.
- the file “SD_Audio.PLM” includes the PlaylistManager, while the file “SD_Audio.TKM” includes the TrackManager.
- a plurality of AOB files store encoded AOBs, though no other information, such as the playback period of the AOBs, the names of the songs represented by the AOBs, or credits for the composer(s), is given. While a plurality of AOBs are recorded in a plurality of AOB files, no indication as to the playback order of the AOBs is provided. To inform a playback apparatus of such information, the TrackManager and PlaylistManager are provided.
- the TrackManager shows the correspondence between the AOBs recorded in AOB files and tracks, and includes a plurality of pieces of track management information that each give a variety of information, such as the playback period of AOBs and the song names and composers of the various AOBs.
- the term “track” refers to a meaningful playback unit for users, so that when copyrighted music is stored on a flash memory card 31 , each song is a separate track. Conversely, when an “audio book” (i.e., copyrighted literature stored as recorded audio) is recorded on a flash memory card 31 , each chapter or paragraph can be set as a separate track.
- the TrackManager is provided to manage a plurality of AOBs recorded in a plurality of AOB files as a group of tracks.
- a Playlist sets the playback order of a plurality of tracks.
- a plurality of Playlists can be included in the PlaylistManager.
- FIG. 17 shows the detailed composition of the PlaylistManager and TrackManager in this embodiment as a hierarchy.
- FIG. 18 shows the sizes of the PlaylistManager and the TrackManager.
- the right side of FIG. 17 shows the items on the left side in more detail, with the broken lines indicating which items are being shown in more detail.
- the TrackManager is composed of the Track Information (TKI) # 1 , # 2 , # 3 , # 4 . . . #n, as shown by the broken line h 1 .
- TKIs are information for managing the AOBs recorded in AOB files as tracks, and each correspond to a different AOB file. From FIG. 17 , it can be seen that each TKI is composed of Track_General_Information (TKGI), Track_Text Information (TKTXTI_DA) in which text information exclusive to a track can be written, and a Track_Time_Search_Table (TKTMSRT) that serves as a time search table.
- TKGI Track_General_Information
- TKTXTI_DA Track_Text Information
- TKTMSRT Track_Time_Search_Table
- each TKI has a fixed size of 1,024 bytes, which means that a total size of the TKGI and the TKTXTI_DA is fixed at 512 bytes due to the size of the TKTMSRT being fixed at 512 bytes.
- a total of 999 TKIs can be set.
- the TKTMSRT is composed of a TMSRT_Header and TMSRT_entries # 1 , # 2 , # 3 . . . #n.
- FIG. 19 shows how the TKIs shown in FIG. 17 correspond to the AOB files and AOBs shown in FIG. 16 .
- the boxes on the first level in FIG. 19 show a sequence of tracks composed of tracks TrackA to TrackE, the large frame on the second level shows the TrackManager, while the third and fourth levels show the eight AOB files given in FIG. 16 .
- the eight AOB files are recorded in the eight AOBs shown in FIG. 16 , and compose a music album including tracks TrackA, TrackB, TrackC, TrackD, and TrackE.
- the second level shows the eight TKIs.
- the numbers “1”, “2”, “3”, “4” assigned to each TKI are the serial numbers used to identify each TKI, with each TKI corresponding to the AOB file that has been given the same serial number 001, 002, 003, 004, 005 . . . .
- TKI# 1 corresponds to the file “AOB001.SA1”
- TKI# 2 corresponds to the file “AOB002.SA1”
- TKI# 3 corresponds to the file “AOB003.SA1”
- TKI# 4 corresponds to the file “AOB004.SA1”.
- the correspondence between TKIs and AOB_FRAMEs is shown by the arrows TA 1 , TA 2 , TA 3 , TA 4 . . . in FIG. 19 .
- each TKI corresponds to a different AOB recorded in an AOB file and gives detailed information that applies only to the corresponding AOB.
- FIG. 20 shows the data composition of the TKTMSRT in detail.
- the right side of FIG. 20 shows the detailed data composition of the time search table header (TMSRT_Header).
- TMSRT_Header has a data size of eight bytes, and is made up of three fields. The first two bytes are a TMSRT_ID, the next two bytes are reserved, and the final four bytes are a Total TMSRT_entry_Number.
- TMSRT_ID A unique ID for identifying the TMSRT is recorded in the “TMSRT_ID”.
- Total TMSRT_entry Number The total number of TMSRT_entries in the present TMSRT is recorded in the “Total TMSRT_entry Number”.
- FIG. 21 shows one example of a TKTMSRT.
- the left side of FIG. 21 shows an AOB, while the right side shows the corresponding TKTMSRT.
- the AOB on the left side of FIG. 21 is composed of a plurality of AOB_ELEMENTs numbered # 1 , # 2 , # 3 . . . #n that occupy the regions numbered AR 1 , AR 2 , AR 3 . . . ARn to the right.
- the numbers such as “0”, “32000”, “64200”, “97000”, “1203400”, and “1240000” show the relative addresses of areas AR 1 , AR 2 , AR 3 , ARn ⁇ 1, ARn occupied by the AOB_ELEMENTs with respect to the start of the AOB_BLOCK.
- AOB_ELEMENT# 2 is recorded at a position that is at a distance “32000” from the start of the AOB_BLOCK
- AOB_ELEMENT# 3 is recorded at a position that is at a distance “64200” from the start of the AOB_BLOCK
- AOB_ELEMENT#n ⁇ 1 is recorded at a position that is at a distance “1203400” from the start of the AOB_BLOCK.
- each occupied region is not a multiple of a certain value, meaning that the regions occupied by AOB_ELEMENTs are not of the same size.
- the reason the occupied regions have different sizes is that varying amounts of data are used to encode each AOB_FRAME.
- each AOB_ELEMENT Since the size of the region occupied by each AOB_ELEMENT differs, it is necessary to inform a playback apparatus in advance of the position of each AOB_ELEMENT in an AOB when performing a jump to the start of an AOB_ELEMENT.
- a plurality of TMSRT_entries are given in the TKTMSRT.
- the arrows RT 1 , RT 2 , RT 3 . . . RTn ⁇ 1, RTn show the correspondence between the regions AR 1 , AR 2 , AR 3 . . . ARn ⁇ 1, ARn occupied by each AOB_ELEMENT and TMSRT_entry# 1 , TMSRT_entry# 2 , TMSRT_entry# 3 . . . .
- TMSRT_entry#n TMSRT_entry#n ⁇ 1, TMSRT_entry#n.
- the size of the region AR 1 occupied by AOB_ELEMENT# 1 is written in the TMSRT_entry# 1
- the sizes of the regions AR 2 and AR 3 occupied by AOB_ELEMENT# 2 and AOB_ELEMENT# 3 are written in the TMSRT_entries # 2 and # 3 .
- the data sizes of AOB_ELEMENTs are written in a time search table.
- the total number of AOB_ELEMENTs included in a single AOB is limited to a predetermined number (“252” as shown in FIG. 20 ) or less. Since the number of AOB_ELEMENTs is restricted, the number of TMSRT_entries corresponding to AOB_ELEMENTs is also restricted, which restricts the size of the TKTMSRT including these TMSRT_entries to within a predetermined size. Since the size of the TKTMSRT is restricted, a playback apparatus can read and use TKIs in the following way.
- the playback apparatus reads a certain AOB and on commencing playback of the AOB, reads the corresponding TKI and stores it in a memory. This corresponding TKI is kept in the memory while the playback of this AOB continues. Once the playback of the AOB ends, the following AOB is read, and when the playback of this AOB commences, the playback apparatus overwrites the TKI corresponding to this following AOB into the memory in place of the old TKI. This next TKI is kept in the memory while the playback of this following AOB continues.
- the TKTMSRT includes the size of each AOB_ELEMENT, so that when AOB_ELEMENT#y, which is the y th AOB_ELEMENT from the start of an AOB, is to be read, the cluster u that satisfies Equation 1 given below is calculated, and data positioned with the offset v from the start of the cluster u is read.
- the DATA_Offset is written in the BIT and is described later in this specification.
- TKTMSRT time search table
- TKTXI_DA Track_Text_Information Data Area
- the Track_Text_Information Data Area (TKTXTI_DA) is used to store text information showing the artist name, album name, mixer, producer, and other such information. This area is provided even when such text information does not exist.
- TKGI recorded in the upper part of the TKTXI_DA.
- FIG. 17 several sets of information shown as the identifier “TKI_ID” of the TKI, the TKI number “TKIN”, the TKI size “TKI_SZ”, a link pointer to the next TKI “TKI_LNK_PTR”, block attributes “TKI_BLK_ATR”, a playback period “TKI_PB_TM”, the audio attributes “TKI_AOB_ATR”, an “ISRC”, and block information “BIT”. Note that only some of this information has been shown in FIG. 17 to simplify the representation.
- the following describes the composition of a TKGI in detail, with reference to FIG. 22 .
- the difference between FIG. 17 and FIG. 22 is that the data composition of the TKGI that was shown in FIG. 17 is arranged on the left side of this drawing, and that the bit compositions of “TKI_BLK_ATR”, “TKI_AOB_ATR” and “ISRC” are clearly shown.
- a unique ID for a TKI is written in the “TKI_ID”.
- TKI_ID A unique ID for a TKI is written in the “TKI_ID”.
- A4 a two-byte “A4” code is used.
- a TKI number in the range of 1 to 999 is written in the “TKIN”. Note that the TKIN of each TKI is unique. In the present embodiment, the position of each TKI in the TrackManager is used as the TKIN. This means that “1” is written as the TKI number of TKI# 1 , “2” is written as the TKI number of TKI# 2 , and “3” is written as the TKI number of TKI# 3 .
- the data size of the TKI in byte units is written in the “TKI_SZ”.
- 1,024 bytes is given as the data size of the TKI so that each TKI in the present embodiment is 1,024 bytes long.
- the TKIN of the TKI to which the present TKI is linked is written in the “TKI_LNK_PTR”. The following describes such links between TKIs.
- the track information numbered # 1 to # 3 and # 8 each correspond to separate tracks, so no information is set in their TKI_LNK_PTR.
- the track information TKI# 4 , TKI# 5 , TKI# 6 , TKI# 7 correspond to the four AOB files that compose TrackD, so that the next track information is indicated in the TKI_LNK_PTR of these TKIs. As shown by the arrows TL 4 , TL 5 , and TL 6 in FIG.
- TKI# 5 is set in the TKI_LNK_PTR of TKI# 4
- TKI# 6 is set in the TKI_LNK_PTR of TKI# 5
- TKI# 7 is set in the TKI_LNK_PTR of TKI# 6 .
- a playback apparatus can refer to the TKI_LNK_PTRs given in the TKIs corresponding to these four AOB files and thereby find out that the four TKIs TKI# 4 to TKI# 7 and the four AOB files “AOB004.SA1” to “AOB007.SA1” compose a single track, TrackD.
- the attributes of present TKI are written in the “TKI_BLK_ATR”.
- the information shown within the broken lines extending form the TKI_BLK_ATR shows the bit composition of the TKI_BLK_ATR.
- the TKI_BLK_ATR is shown as being 16 bits long, with the bits from b 3 to b 15 being reserved for future use. The three bits from bit b 2 to b 0 are used to show the attributes of the TKI.
- the value “00b” is written in the TKI_BLK_ATR (this setting is hereafter referred to as “Track”).
- the value “001b” is written in the TKI_BLK_ATR of the first TKI (this setting is hereafter referred to as “Head_of_Track”)
- the value “010b” is written in the TKI_BLK_ATRs of the TKIs that correspond to AOBs in the middle of the track (this setting is hereafter referred to as “Midpoint_of_Track”)
- the value “011b” is written in the TKI_BLK_ATR of the TKI that corresponds to the AOB at the end of the track (this setting is hereafter referred to as “End_of_Track”).
- the following describes the settings of the TKI_BLK_ATR for each TKI in the example shown in FIG. 19 .
- TKI_BLK_ATR of each TKI, it can be seen that the four pairs TKI# 1 (“AOB001.SA1”), TKI# 2 (“AOB002.SA1”), TKI# 3 (“AOB003.SA1”), and TKI# 8 (“AOB008.SA1”) each correspond to separate tracks since the TKI_BLK_ATR of each of TKI# 1 , TKI# 2 , TKI# 3 , and TKI# 8 is set as “Track”.
- the TLK_BLK_ATR of TKI# 4 is set at “Head_of_Track”
- the TLK_BLK_ATR of TKI# 7 is set at “End_of_Track”
- the TLK_BLK_ATR of TKI# 5 and TKI# 6 is set at “Midpoint_of_Track”.
- AOB file (“AOB004.SA1”) corresponding to TKI# 4 is the start of a track
- the AOB files (“AOB005.SA1”) and (“AOB006.SA1”) corresponding to TKI# 5 and TKI# 6 are midpoints of the track
- the AOB file (“AOB007.SA1”) corresponding to TKI# 7 is the end of a track.
- TKI# 4 and “AOB004.SA1” composes the first part of the fourth track (TrackD)
- the combinations of TKI# 5 with “AOB005.SA1” and TKI# 6 with “AOB006.SA1” compose central parts of TrackD
- the combination of TKI# 7 and “AOB007.SA1” composes the end part of TrackD.
- the combination of TKI# 8 and “AOB008.SA1” composes a fifth track (TrackE).
- the playback period of the track (song) composed of the AOB recorded in the AOB file corresponding to a TKI is written in the “TKI_PB_TM” in the TKI.
- the entire playback period of the track is written in the TKI_PB_TM of the first TKI corresponding to the track, while the playback period of the corresponding AOB is written into the second and following TKIs for the track.
- the encoding conditions used when producing an AOB which is to say information such as (1) the sampling frequency at which the AOB recorded in the corresponding AOB file was sampled, (2) the transfer bitrate, and (3) the number of channels, is written in the “TKI_AOB_ATR” in a TKI.
- the bit composition of the TKI_AOB_ATR is shown within the broken lines that extend from the “TKI_AOB_ATR” in FIG. 22 .
- the TKI_AOB_ATR is composed of 32 bits, with the coding mode being written in the four-bit field from bit b 16 to bit b 19 .
- the AOB is encoded according to MPEG-2 AAC (with ADTS header)
- MP3 MPEG-layer 3
- the value “001b” is written.
- WMA Windows Media Audio
- the bitrate used when encoding the AOB is written in the eight-bit field between bit b 15 and bit b 8 .
- MPEG-2 AAC with ADTS header
- MP3 MPEG1-layer 3
- a value between “16” and “96” is written.
- MP3 LSF MPEG1-layer 3
- WMA Windows Media Audio
- the sampling frequency used when encoding the AOB is written in the four-bit field between bit b 7 and bit b 4 .
- the sampling frequency is 48 kHz
- the value “0000b” is written in this field.
- the sampling frequency is 44.1 kHz
- the value is “001b”
- the sampling frequency is 32 kHz
- the value “0010b” when the sampling frequency is 24 kHz
- the value “0011b” when the sampling frequency is 22.05 kHz, the value “0100b”
- the sampling frequency is 16 kHz, the value “0101b”.
- the number of channels is written in the three-bit field from bit b 3 to bit b 1 .
- one channel i.e., monaural
- the value “000b” is written in this field
- two channels i.e., stereo
- bit b 31 to bit 20 The twelve-bit field from bit b 31 to bit 20 is reserved for future use, as is the bit b 0 .
- ISRC International Standard Recording Code
- FIG. 22 the broken lines extending from the “ISRC” box show the content of the ISRC.
- the ISRC is composed of ten bytes, with a Recording-item code (# 12 ) being written into the four-bit field between bit b 4 and bit b 7 .
- a Recording code/Recording-item code (# 11 ) is written in the four-bit field between bit b 8 and bit b 11 .
- a Recording Code (ISRC# 10 , # 9 , # 8 ) is written in the twelve-bit field between bit b 12 and bit b 23 .
- a Year-of-Recording code (ISRC# 6 , # 7 ) is written in the eight-bit field b 24 and bit b 31 .
- the First Owner Code (ISRC # 3 , # 4 , # 5 ) is written in the six-bit field between bit b 32 and bit b 37 , the six-bit field between bit b 40 and bit b 45 , and the six-bit field between bit b 48 and bit b 53 .
- the Country Code (ISRC # 1 , # 2 , # 3 ) is written in the six-bit field between bit b 56 and bit b 61 and the six-bit field between bit b 64 and bit b 69 .
- a one-bit Validity flag is written in a one-bit field composed of bit b 79 .
- a detailed description of ISRC can be found in ISO3901:1986 “Documentation-International Standard Recording Code (ISRC)”.
- the “Block Information Table (BIT),” is a table for managing an AOB_BLOCK, and has the detailed composition shown in FIGS. 23A and 23B .
- a BIT is composed of a DATA_OFFSET field that occupies a region from the 60th byte to the 63rd byte, an SZ_DATA field that occupies a region from the 64th byte to the 67th byte, a TMSRTE_Ns field that occupies a region from the 68th byte to the 71st byte, an FNs — 1st_TMSRTE field that occupies a region from the 72nd byte to the 73rd byte, an FNs_Last_TMSRTE that occupies a region from the 74th byte to the 75th byte, an FNs_Middle_TMSRTE field that occupies a region from the 76th byte to the 77th byte, and a TIME_LENGTH field that occupies a region from the 78th byte to the 79th byte.
- the relative address of the start of an AOB_BLOCK from the boundary between clusters is written in the “DATA_OFFSET” as a value given in byte units. This expresses the size of an invalid area between an AOB and the AOB_BLOCK.
- the DATA_OFFSET in the BIT can be set to have the track played back without the part including the DJ's voice.
- the data length of an AOB_BLOCK expressed in byte units is written in “SZ_DATA”.
- SZ_DATA The data length of an AOB_BLOCK expressed in byte units.
- TMSRT_Entries included in an AOB_BLOCK is written in “TMSRTE_Ns”.
- the number of AOB_FRAMEs included in the AOB_ELEMENT positioned at the start of a present AOB_BLOCK is written in “FNs — 1st_TMSRTE”.
- the number of AOB_FRAMEs included in the AOB_ELEMENT positioned at the end of the present AOB_BLOCK is written in “FNs_Last_TMSRTE”.
- the playback period of an AOB_ELEMENT is written in the format shown in FIG. 23C in the “TIME_LENGTH” field to an accuracy in the order of milliseconds.
- the “TIME_LENGTH” field is 16-bits long.
- the playback period of an AOB_ELEMENT is two seconds, so that the value “2000” is written in the “TIME_LENGTH” field.
- FIG. 23B shows the number of AOB_FRAMEs indicated by “FNs_Middle_TMRTE”. In the same way as FIG. 14 , FIG. 23B shows the relationship between the sampling_frequency and the number of AOB_FRAMEs included in an AOB_ELEMENT in the middle of an AOB_BLOCK.
- the relationship between the sampling_frequency and the number of frames included in the AOB_ELEMENT shown in FIG. 23B is the same as that shown in FIG. 14 , which is to say, the number of frames in an AOB_ELEMENT depends on the sampling frequency used.
- the number of frames written in “FNs — 1st_TMSRTE” and “FNs_Last_TMSRTE” will fundamentally be the same as the number written in “FNs_Middle_TMSRTE”, though when an invalid area is present in the AOB_ELEMENTs at the start and/or end of an AOB_BLOCK, the values given in “FNs — 1st_TMSRTE” and/or “FNs_Last_TMSRTE” will differ from the value in “FNs_Middle_TMSRTE”.
- FIG. 24 shows the clusters 007 to 00E that store the AOB composed of AOB_ELEMENT# 1 to AOB_ELEMENT# 4 .
- the following describes the settings in the BIT when an AOB is stored as shown in FIG. 24 .
- AOB_ELEMENT# 1 to AOB_ELEMENT# 4 that are stored in cluster 007 to cluster 00E are indicated in FIG. 24 by the triangular flags, with TMSRT_entries being set in the TKI for each of AOB_ELEMENT# 1 to AOB_ELEMENT# 4 .
- the first part of AOB_ELEMENT# 1 at the start of the AOB is stored in cluster 007, while the last part of AOB_ELEMENT# 4 at the end of the AOB is stored in cluster 00E.
- the AOB_ELEMENTs # 1 to # 4 occupy the region between md 0 in cluster 007 to md 4 in cluster 00E. As shown by arrow sd 1 in FIG.
- the SZ_DATA in the BIT indicates that AOB_ELEMENTs # 1 to # 4 occupy a region from the start of cluster 007 to the end of cluster 00E, and so does not indicate that there are the invalid areas ud 0 and ud 1 in clusters 007 and 00E that are not occupied by an AOB_ELEMENT.
- the AOB also includes the parts ud 0 and ud 1 that are present in clusters 007 and 00E but are not occupied by AOB_ELEMENT# 1 or AOB_ELEMENT# 4 .
- the DATA_Offset given in the BIT gives the length of the unoccupied region ud 0 , which is to say, a position value for the start of the AOB_ELEMENT# 1 relative to the start of cluster 007.
- the AOB_ELEMENT# 1 occupies a region from md 0 in cluster 007 to md 1 in cluster 008.
- AOB_ELEMENT# 1 does not occupy all of cluster 008, with the remaining part of the cluster being occupied by AOB_ELEMENT# 2 .
- AOB_ELEMENT# 4 occupies a region from md 3 midway through cluster 00C to md 4 midway through cluster 00E. In this way, AOB_ELEMENTs may be stored across cluster boundaries, or in other words, AOB_ELEMENTs can be recorded without regard for the boundaries between clusters.
- the “FNs — 1st_TMSRTE” in the BIT shows the number of frames in AOB_ELEMENT# 1 that is located in clusters 007 and 008, while the “FNs_Last_TMSRTE” in the BIT shows the number of frames in AOB_ELEMENT# 4 that is located in clusters 00C to 00E.
- AOB_ELEMENTs can be freely positioned without regard for the boundaries between clusters.
- the BIT provides information showing the offset from a cluster boundary to an AOB_ELEMENT and the number of frames in each AOB_ELEMENT.
- the following describes how the number of frames in each AOB_ELEMENT given in the BIT is used. This number of frames given in the BIT is used when forward or backward search is performed. As mentioned earlier, such operations play back 240 milliseconds of data after first skipping data with a playback period of two seconds.
- FIG. 25 shows how AOB_FRAME#x+1, which should be played back next, is set when performing forward search starting from an AOB_FRAME#x in an AOB_ELEMENT#y in an AOB.
- FIG. 25 shows the case when a user selects forward search during the playback of AOB_FRAME#x included in AOB_ELEMENT#y.
- “t” represents the intermittent playback period (here, 240 milliseconds)
- “f(t)” shows the number of frames that correspond to this intermittent playback period
- “skip_time” shows the length of the period that should be skipped between intermittent playback periods (here, two seconds)
- “f(skip_time)” shows the number of frames that correspond to this skip time. Intermittent playback is achieved by repeating the three procedures (1), (2), and (3) described below.
- the playback apparatus refers to the TMSRT_entry in the TKTMSRT and jumps to the start of the flag symbol (AOB_ELEMENT).
- the playback apparatus performs playback for 240 milliseconds.
- the AOB_FRAME#x+1 that exists 2 s+240 ms from the AOB_FRAME#x included in the AOB_ELEMENT#y will definitely be present in the AOB_ELEMENT#y+1.
- the first address of the next AOB_ELEMENT#y+1 can be immediately calculated by reading a TMSRT_entry from the TKTMSRT, though a playback apparatus cannot know the number of AOB_FRAMEs from the start address of the AOB_ELEMENT#y+1 to the AOB_FRAME#x+1 from the TMSRT_entry alone.
- FIG. 26A shows how a playback apparatus can specify the AOB_ELEMENT and AOB_FRAME corresponding to the playback start time indicated by the user.
- the indicated time in seconds
- playback should begin from an AOB_ELEMENT#y and an AOB_FRAME position x that satisfy Equation 2 given below.
- Jmp_Entry(sec) (FNs — 1 st _TMSRTE+FNs_middle_TMSRTE* y+x )*20msec Equation 2
- a playback apparatus can refer to the TKTMSRT of the AOB, calculate the first address of the AOB_ELEMENT#y+2 (which is the (y+2) th AOB_ELEMENT in this AOB), and start the search for AOB_FRAME#x from this first address. On finding the x th AOB_FRAME, the playback apparatus starts the playback from this frame. In this way, the playback apparatus can start the playback of data from the time indicated by Jmp_Entry (in seconds).
- a playback apparatus does not have to search for the ADTS header parts of AOB_FRAMEs, and only needs to perform the search in AOB_ELEMENTs that are given in the TMSRT_entries in the TKTMSRT. This means that the playback apparatus can find a playback position corresponding to an indicated playback time at high speed.
- Jmp_Entry(in seconds) Playback period from AOB#1 to AOB# n +(FNs — 1 st _TMSRTE(# n+ 1)+FNs_middle_TMSRTE(# n+ 1)* y+x )*20msec Equation 3
- Total Playback Period of the AOBs from AOB# 1 to AOB#n is as follows.
- Total Playback Period from AOB#1 to AOB# n [“FNs — 1 st _TMSRTE”(#1)+“FNs_Middle_TMSRTE”(#1)*(Number of TMSRT_entries(#1) ⁇ 2)+“FNs_Last_TMSRTE”(#1)+ “FNs — 1 st _TMSRTE”(#2)+(“FNs_Middle_TMSRTE”(#2)*Number of TMSRT_entries(#2) ⁇ 2)+“FNs_Last_TMSRTE”(#2)+ “FNs — 1 st _TMSRTE”(#3)+(“FNs_Middle_TMSRTE”(#3)*Number of TMSRT_entries(#3) ⁇ 2)+“FNs_Last_TMSRTE”(#3) .
- the playback apparatus Having calculated an AOB#n, an AOB_ELEMENT#y, and AOB_FRAME#x that satisfy Equation 3, the playback apparatus refers to the TKTMSRT corresponding to the AOB#n+1, searches for the x th AOB_FRAME from the address at which the (y+ 2 ) th AOB_ELEMENT (i.e., AOB_ELEMENT#y+2) is positioned, and starts the playback from this x th AOB_FRAME.
- FIGS. 27A and 27B show the partial deletion of a track.
- the example in FIGS. 27A and 27B corresponds to the TrackManager shown in FIG. 19 , and assumes that the user has indicated the partial deletion of Track B.
- the AOB corresponding to TrackB is recorded in “AOB002.SA1”, which is associated with TKI# 2 .
- This means that the deletion of “AOB002.SA1” is accompanied by the setting of “Unused” into the TKI_BLK_ATR of TKI# 2 .
- This state where “AOB002.SA1” has been deleted and “Unused” has been set into the TKI_BLK_ATR of TKI# 2 is shown in FIG. 27B .
- FIG. 28A shows the TrackManager after the deletion of tracks has been performed several times.
- “Unused” is set in the TKI_BLK_ATR of these TKI.
- AOB files are deleted in the same way as conventional data files, the TrackManager is updated by merely setting “Unused” in the TKI_BLK_ATR of the corresponding TKI.
- FIG. 28B shows how a new TKI and AOB file are written when a TKI whose TKI_BLK_ATR is “Unused” is present in the TrackManager.
- the TKI# 2 , TKI# 4 , TKI# 5 , TKI# 7 , and TKI# 8 in FIG. 28B are set as “Unused”.
- the new track to be written is composed of four AOBs.
- the unused TKIs used to record these AOBs are determined according to the DPL_TK_SRPs or can be freely chosen.
- the unused TKIs numbered TKI# 2 , TKI# 4 , TKI# 7 , and TKI# 8 are used to record the TKIs for the new track.
- “Head_of_Track” is set in the TKI_BLK_ATR of TKI# 2
- “Middle_of_Track” is set in the TKI_BLK_ATR of TKI# 4 and TKI# 7
- “End_of_Track” is set in the TKI_BLK_ATR of TKI# 8 .
- TKI_LNK_PTR in each of the four TKIs, TKI# 2 , TKI# 4 , TKI# 7 , and TKI# 8 , used to compose the new TrackD is set so as to show the TKI forming the next part of TrackD, so that as shown by the arrows TL 2 , TL 4 , and TL 7 , TKI# 4 is set in the TKI_LNK_PTR of TKI# 2 , TKI# 7 is set in the TKI_LNK_PTR of TKI# 4 , and TKI# 8 is set in the TKI_LNK_PTR of TKI# 7 .
- this fourth track TrackD can be managed using TKI# 2 , TKI# 4 , TKI# 7 , and TKI# 8 .
- TKIs in the TrackManager that are set as “Unused” are assigned as the TKIs to be used for tracks that are to be newly recorded.
- FIGS. 29A and 29B show how the TKIs are set when two tracks are combined to produce a new track.
- the example in FIG. 29A uses the same TrackManager as FIG. 19 and shows the case when the user performs an editing operation to combine TrackC and TrackE into a single track.
- FIG. 29B shows the TKI_BLK_ATR of these TKIs after rewriting.
- the TKI_BLK_ATRs of TKI# 3 and TKI# 8 is written as “Track”, but in FIG.
- the TKI_BLK_ATR of TKI# 3 is rewritten to “Head_of_Track” and the TKI_BLK_ATR of TKI# 8 is rewritten as “End_of_Track”.
- the AOB files “AOB003.SA1” and “AOB008.SA1” which correspond to TKI# 3 and TKI# 8 end up being treated as parts of a single track, the new TrackC. This operation is accompanied by the TKI_LNK_PTR of TKI# 3 being rewritten to indicate TKI# 8 .
- the TKI is originally designed so as to suppress the size of the TKTMSRT, so that the physical combining of AOB files by an editing operation would also carry the risk of the TKI becoming too large.
- the combining of tracks is performed by changing the TKI_BLK_ATR attributes as described above, but the AOBs that are included in the combined tracks should satisfy the conditions given below.
- a first condition is that the AOB that is to compose a latter part of a new track needs to have the same audio attributes (audio coding mode, bitrate, sampling frequency, number of channels, etc.) as the AOB that is to compose the first part of the new track. If an AOB has different audio attributes to the preceding or succeeding AOB, the playback apparatus will have to reset the operation of the decoder, which makes seamless (i.e., uninterrupted) playback of consecutive AOBs difficult.
- audio attributes audio coding mode, bitrate, sampling frequency, number of channels, etc.
- the second condition is that in the track produced by the combining, three or more AOBs made up of only AOB_ELEMENTs whose number of AOB_FRAMEs is below the required number for an “FNs_Middle_TMSRTE” cannot be linked.
- AOBs are classified into two types depending on whether at least one AOB_ELEMENT includes a same number of AOB_FRAMEs as the number of frames stipulated for an “FNs_Middle_TMSRTE”.
- the Type1 AOB includes at least one AOB_ELEMENT having this number of AOB_FRAMEs, while the Type2 AOB includes no AOB_ELEMENT having this number of AOB_FRAMEs.
- AOB_ELEMENTs in a Type2 AOB have fewer AOB_FRAMEs than “FNs_Middle_TMSRTE”, and the second condition stipulates that three Type2 AOBs cannot be linked together.
- the reason for the second condition is as follows.
- the playback apparatus reads AOBs successively, it is preferable for a sufficient number of AOB_FRAMEs to accumulate in the buffer of the playback apparatus, though this cannot be achieved when there are consecutive Type2 AOBs.
- an underflow is likely to occur in the buffer of the playback apparatus, so that uninterrupted playback by the playback apparatus can no longer be guaranteed. Therefore, in order to avoid such underflows, the second condition stipulating that three or more Type2 AOBs cannot be linked continuously is used.
- FIG. 30A shows a Type1 AOB
- FIG. 30B shows two examples of Type2 AOBs.
- both AOBs are composed of less than two AOB_ELEMENTs, with none of the AOB_ELEMENTs including a number of AOB_FRAMEs that is set for an “FNs_Middle_TMSRTE”. Since the absence of an AOB_ELEMENT with the number of AOB_FRAMEs set for an “FNs_Middle_TMSRTE” is the condition by which an AOB is classified as a Type2 AOB, this means that all of the AOBs shown in this drawing are classified as Type2 AOBs.
- FIG. 31A a combining of Type1+Type2+Type2+Type1 AOBs into a single track is shown. As this combining does not involve the linking of three Type2 AOBs, these AOBs may be linked to form a single track.
- FIG. 31B shows the linking of Type1+Type2+Type2+Type2+Type1 AOBs into a single track. This combining would result in there being three consecutive Type2 AOBs, and so is prohibited.
- FIG. 31A shows the case where the last AOB in the first track is a Type1 AOB and the first AOB in the next track is also a Type1 AOB.
- FIG. 32B shows the case where the last AOB in the first track is a Type1 AOB and the first AOB in the next track is a Type2 AOB. As the second condition is satisfied in both of these cases, the illustrated tracks can be combined into a single track.
- this first track can be combined with a following track that starts with a Type1 AOB regardless of whether the first AOB in the first track is a Type1 AOB or a Type2 AOB.
- FIG. 32C shows the case where the first track ends with a Type1 AOB and a Type2 AOB in that order and the second track starts with a Type1 AOB.
- FIG. 32D shows the case where the first track ends with a Type1 AOB and a Type2 AOB in that order and the second track starts with a Type2 AOB and a Type1 AOB in that order.
- the illustrated tracks can be combined into a single track.
- FIG. 32E shows the case where the first track ends with two Type2 AOBs and the second track starts with a Type1 AOB.
- the illustrated tracks can be combined into a single track. In this way, when two tracks are to be combined, an investigation is performed to see whether the two tracks satisfy the first and second conditions and the two tracks are only combined if they are judged to satisfy these conditions.
- FIGS. 33A and 33B show examples of when a single track is to be divided to produce two new tracks.
- the content of the TrackManager is the same as in FIG. 27 , with the user being assumed to have performed an editing operation that divides TrackC into two new tracks, TrackC and TrackF.
- TrackC is to be divided into a new TrackC and TrackF
- the AOB file “AOB002.SA1” is generated corresponding to TrackF.
- FIG. 33A shows that TKI# 2 is set as “Unused”, with this TKI# 2 being assigned to the newly generated AOB file “AOB002.SA1”.
- FIG. 34A shows how the SD-Audio Directory Entry in the SD-Audio Directory to which the AOB file “AOB003.SA1” belongs is written before the file is divided.
- the AOB file “AOB003.SA1” is divided into a plurality of parts that are stored in clusters 007, 008, 009, 00A . . . 00D, 00E.
- the first cluster number for the AOB file “AOB003.SA1” given in the directory entry is written as “007”.
- the values (008), (009), (00A) . . . (00D), (00E) are also written in the FAT values 007, 008, 009, 00A . . . 00D corresponding to the clusters 007, 008, 009, 00A . . . 00D.
- FIG. 34B shows how the SD-Audio Directory Entry in the SD-Audio Directory to which the AOB file “AOB003.SA1” belongs is written after the AOB file “AOB003.SA1” has been divided.
- the cluster 00F stores a copy of cluster 00B that includes the boundary indicated by the user when dividing the file.
- the parts of the AOB file “AOB002.SA1” that follow the part included in the cluster 00B are stored in the clusters 00C, 00D, 00E as before.
- the following describes how the information fields in the TKI are set for the AOB file “AOB002.SA1” once this file has been obtained by updating the directory entries and the FAT values.
- SA1 information fields in the TKI. These are (1) information that can be copied from the original TKI and (2) information obtained by updating the information in the original TKI.
- the TKTXTI_DA and ISRC are the former type, while the BIT, the TKTMSRT and other information fields are the latter type.
- the present embodiment Since both types of information exist, the present embodiment generates a TKI for a divided track by copying the original TKI to produce a template for the new TKI, and then dividing/updating the TKTMSRT and BIT in this template and updating the remaining information fields.
- FIG. 35A shows the case where an AOB_FRAME in an AOB is divided.
- the first level in FIG. 35A shows the four AOB_ELEMENTs, AOB_ELEMENT# 1 , AOB_ELEMENT# 2 , AOB_ELEMENT# 3 , and AOB_ELEMENT# 4 .
- the data lengths of these AOB_ELEMENTs are set in the TKTMSRT as the four TMSRT_entries #1, #2, #3, and # 4 .
- AOB_ELEMENT# 2 is divided into a first region (1) made up of the frames located before the boundary bd 1 and a second region (2) composed of the frames located after the boundary bd 1 .
- FIG. 35B shows the two AOBs AOB# 1 and AOB# 2 obtained by dividing the AOB midway though AOB_ELEMENT# 2 .
- FIG. 36 shows how the BIT is set when an AOB is divided as shown in FIG. 35 .
- the AOB shown in FIG. 35 is divided at the boundary bd 1 .
- the AOB# 1 produced by this division includes the two AOB_ELEMENTs AOB_ELEMENT# 1 and AOB_ELEMENT# 2
- the other AOB# 2 produced by this division includes the three AOB_ELEMENTs, AOB_ELEMENT# 1 , AOB_ELEMENT# 2 , and AOB_ELEMENT# 3 .
- AOB_ELEMENTs have also been given the triangular flags to shows the settings of the TMSRT_entries included in the TKIs corresponding to these AOBs.
- the explanation will first focus on AOB# 1 which is obtained by this division.
- AOB_ELEMENT# 1 and AOB_ELEMENT# 2 that are included in AOB# 1 occupy cluster 007 to cluster 00A, so that AOB# 1 is handled as being the composite of cluster 007 to cluster 00A.
- AOB_ELEMENT# 2 in AOB# 1 has a data length that ends not at the end of cluster 00A, but at the boundary bd 1 that is present within cluster 00A, so that the SZ_DATA for AOB# 1 is given as the amount of data from the region md 0 to the boundary bd 1 in cluster 00A.
- the “FNs — 1st_TMSRTE” for AOB# 1 is the same as before division, while the “FNs_Last_TMSRTE” for AOB# 1 differs from the value used before division in that it now indicates the number of frames from the start of AOB_ELEMENT# 2 before division to the boundary bd 1 .
- AOB# 2 which is obtained by this division.
- AOB_ELEMENT# 1 , AOB_ELEMENT# 2 , and AOB_ELEMENT# 3 that are included in AOB# 2 occupy cluster 00B to cluster 007.
- Cluster 00F includes a copy of the content of cluster 00A.
- the reason cluster 00F stores a copy of cluster 00A is that cluster 00A is occupied by AOB_ELEMENT# 2 in AOB# 1 , so that it is necessary to assign a different cluster to AOB_ELEMENT# 1 in AOB# 2 .
- AOB_ELEMENT# 1 in AOB# 2 has a data length that starts not at the beginning of cluster 00F, but at the boundary bd 1 that is present within cluster 00F, so that the SZ_DATA for AOB# 2 is given as the amount of data from the start of cluster 00B to a point midway through cluster 00E plus the data length of the part of cluster 00F occupied by AOB_ELEMENT# 1 .
- the part of AOB_ELEMENT# 2 in AOB# 1 that is included in the copy of cluster 00A stored in cluster 00F needs to be excluded from AOB# 2 , so that the DATA_Offset field in the BIT of AOB# 2 is set at the size of the part of AOB_ELEMENT# 2 in AOB# 1 included in cluster 00F.
- the division of the AOB result in only the AOB_ELEMENT that includes the boundary for the division being divided into two and in the other AOB_ELEMENTs positioned before and after the divided AOB_ELEMENT remaining unchanged.
- the “FN_Last_TMSRTE” of AOB# 2 is set at the same value for the “AOB_ELEMENT# 4 ”, before the division, and the “FNs — 1st_TMSRTE” of AOB# 2 is set at AOB_ELEMENT# 1 of AOB# 2 , which is to say, the number of frames included in the part that follows the boundary once AOB_ELEMENT# 2 has been divided.
- FIG. 37 shows a more specific example of changes in the BITs as a result of the division of a track.
- the left side of FIG. 37 shows an example of the settings of the BIT before division.
- the Data_Offset is set as “X”
- the SZ_DATA is set at “52428”
- the TMSRTE_Ns is set at “n”.
- the FNs — 1st_TMSRTE is set at “80 frames”
- the FNs_Middle_TMSRTE is set at “94 frames”
- the FNs_Last_TMSRTE is set at “50 frames”.
- the right side of FIG. 37 shows the settings of two BITs produced by the division of a track.
- the Data_Offset in the BIT of the first track produced by the division is set at “X” like the track before division”
- the “SZ_DATA” is updated to the data length “Q” from the start to the division point Q
- the TMSRTE_Ns is set at “k” which shows the number of TMSRT_entries from the first TMSRT_entry to the k th TMSRT_entry.
- the FNs — 1st_TMSRTE and FNs_Middle_TMSRTE are respectively set at “80” and “94” frames in the same way as the BIT before division, but since the final AOB_ELEMENT in the AOB of the first track produced by the division includes “p” AOB_FRAMES, the FNs_Last_TMSRTE is set at “p frames.”
- the “Data_Offset” issetat “R”
- the “SZ_DATA” issetat (original SZ#DATA “52428”-data length up to division point Q)
- the TMSRTE_Ns is set at “n ⁇ k+1” produced by adding one (for the kth TMSRT_entry that is newly added as a result of the division) to the number of TMSRT_entries from the k th TMSRT_entry to the n th TMSRT_entry.
- the FNs_Middle_TMSRTE and FNs_Last_TMSRTE are set at the same values as the BIT before division, which is to say, “94 frames” and “50 frames”, respectively.
- the first AOB_ELEMENT in the AOB of this second track includes “94-p” AOB_FRAMEs, so that “94-p” is set in the FNs — 1st_TMSRTE of the BIT corresponding to this track.
- FIG. 38 shows the TKTMSRT after division. The following explains the settings of the TMSRT first.
- the TMSRT of the first track includes the TMSRT_entries from the first TMSRT_entry of the AOB before division to the kth TMSRT_entry, which is to say, the TMSRT_entries # 1 to #k.
- the AOB_ELEMENT#k that includes the boundary for the division only includes region (1), so that the k th TMSRT_entry only includes a data size corresponding to this region (1).
- the TMSRT of the second track includes the TMSRT_entries from the k th TMSRT_entry of the AOB before division to the n th TMSRT_entry, which is to say, the TMSRT_entries #k to #n.
- the AOB_ELEMENT#k that includes the boundary for the division only includes region (2), so that the k th TMSRT_entry only includes a data size corresponding to this region (2).
- the copying of the TKI is accompanied by the division and updating of the TKTMSRT and the BIT, and once the remaining information has been updated, the TKIs for the new tracks produced by the division will be complete.
- the AOB files are not decrypted, so that two tracks can be produced by dividing an AOB file in its encrypted state. Since the division of an AOB file does not involve decryption and re-encryption, the processing load of dividing a track can be suppressed. This means that tracks can be edited even by a playback apparatus with limited processing power.
- the PlaylistManager shown is made up of PlaylistManager_Information (PLMGI) for managing the Playlists stored in the flash memory card 31 , Default_Playlist_Information (DPLI) for managing all of the track stored in the flash memory card 31 , and PlaylistInformation (PLI) #1, #2, #3, #4 . . . #m.
- PLI PlaylistManager_Information
- DPLI Default_Playlist_Information
- each PLI is composed of Playlist_General_Information (PLGI), and Playlist_Track_Search_Pointers (PL_TK_SRP) # 1 , # 2 , # 3 , # 4 . . . #m.
- PLGI Playlist_General_Information
- PL_TK_SRP Playlist_Track_Search_Pointers
- the DPLI referred to here differs from each PLI in the following way. While the DPLI has to indicate all of the tracks stored in the flash memory card 52 , a PLI does not have this restriction and can indicate any number of the tracks. This opens up various possibilities for the user. As representative examples, the user can generate Playlist_Information indicating only his (her) favorite tracks and store this Playlist_Information in the flash memory card 31 , or can have a playback apparatus automatically generate Playlist_Information that only indicates tracks of a certain genre, out of a plurality of tracks stored in the flash memory card 31 , and store the resulting Playlist Information in the flash memory card 31 .
- a maximum of 99 Playlists can be stored on one flash memory card 31 .
- the combined data size of the PlaylistManager_Information (PLMGI) and the Default Playlist Information (DPLI) is also fixed at 2,560 bytes. Each PLI has a fixed length of 512 bytes.
- the “DPL_TK_SRP” included in the Default Playlist Information includes a “DPL_TK_ATR” and a “DPL_TKIN”.
- the “PL_TK_SRP” field included in a PLI includes only a “PL_TK_SRP”.
- the format of the DPL_TK_ATR, DPL_TKIN, and PL_TKIN fields is shown in FIG. 39 .
- FIG. 39A shows the format of the DPL_TK_SRP.
- the DPL_TKIN is written in the 0th to 9th bits in the DPL_TK_SRP, while the DPL_TK_ATR is written in the 13th to 15th bits.
- the 10th to 12th bits in the DPL_TK_SRP are reserved for future use.
- the TKI number is written in the DPL_TKIN that occupies the 0th to 9th bits in the DPL_TK_SRP. This enables a TKI to be specified.
- FIG. 39B shows the format of the PL_TK_SRP. This is a ten-bit field in which PL_TKIN, which is to say, a TKI number, is written.
- the broken lines h 51 and h 52 that extend from the DPL_TK_ATR in FIG. 39A show an example setting of the DPL_TK_ATR.
- the DPL_TK_ATR is set for a DPL_TK_SRP in the same way as TKI_BLK_ATR is set for a TKI, which is to say, the DPL_TK_ATR is set at one of “Track”, “Head_of_Track” “Midpoint_of_Track”, and “End_of_Track”.
- the TKI indicated by the TKIN is used and an Audio Object (AOB) corresponding to one complete track is recorded in the AOB file corresponding to the indicated TKI (i.e., when the TKI_BLK_ATR of the TKI is “Track”), the value “00b” is set in the “DPL_TK_ATR”.
- AOB Audio Object
- the TKI indicated by the TKIN is used and an Audio Object (AOB) corresponding to only the start of a track is recorded in the AOB file corresponding to the indicated TKI (i.e., when the TKI_BLK_ATR of the TKI is “Head_of_Track”), the value “001b” is set in the “DPL_TK_ATR”.
- AOB Audio Object
- the value “010b” is set in the “DPL_TK_ATR”.
- the TKI indicated by the TKIN is used and an Audio Object (AOB) corresponding to an end part of a track is recorded in the AOB file corresponding to the indicated TKI (i.e., when the TKI_BLK_ATR of the TKI is “End_of_Track”), thevalue “111b” is set in the “DPL_TK_ATR”.
- the TKI indicated by the TKIN is unused and the TKI region is merely established, which corresponds to when a TKI has been deleted (i.e., when the TKI_BLK_ATR of the TKI is “Unused”), the value “100b” is set in the DPL_TK_ATR.
- the order of the DPL_TK_SRP items in the Default_Playlist denotes the order in which a plurality of tracks will be played, or in other words, determines the playback order of tracks.
- FIG. 40 shows the interrelationship between the Default_Playlist_Information, the TKI, and the AOB files.
- the second, third, and fourth levels in this drawing are the same as the first, second, and third levels in FIG. 19 , and also show a TrackManager including eight TKI and eight AOB files.
- FIG. 40 differs from FIG. 19 in that a box showing the Default_Playlist_Information is given on the first level.
- the eight small divisions shown in this box show the eight DPL_TK_SRP included in the Default_Playlist_Information.
- the upper part of each division shows the DPL_TK_ATR, while the lower part shows the DPL_TKIN.
- DPL_TK_SRP# 1 and TKI# 1 are related, as are DPL_TK_SRP# 2 and TKI# 2 , DPL_TK_SRP# 3 and TKI# 3 , and DPL_TK_SRP# 4 and TKI# 4 .
- DPL_TK_ATR TKI# 8
- DPL_TK_SRP# 4 DPL_TK_SRP# 5 , DPL_TK_SRP# 6 , and DPL_TK_SRP# 7 has a DPL_TK_ATR set as “Track”.
- the DPL_TK_SRP# 4 of DPL_TK_ATR is set at “Head_of_Track”
- the DPL_TK_ATR of DPL_TK_SRP# 7 is set at “End_of_Track”
- the DPL_TK_ATRs of DPL_TK_SRP# 5 and DPL_TK_SRP# 6 are set at “Midpoint_of_Track”.
- TKI# 4 (“AOB004.SA1”), which is related to DPL_TK_SRP# 4 , is the start of a track
- TKI# 5 (“AOB005.SA1”)
- TKI# 6 (“AOB006.SA1”), which are respectively related to DPL_TK_SRP# 5 and DPL_TK_SRP# 6
- TKI# 7 (“AOB007.SA1”), which is related to DPL_TK_SRP# 7 , is the end of a track.
- the DPL_TK_SRP entries in the DefaultPlaylist show in what order the AOBs corresponding to each TKI are to be played back.
- the DPL_TKINs of DPL_TK_SRP#1, #2, #3, #4 . . . #8 in the DefaultPlaylist of FIG. 40 indicate TKI#1, #2, #3, #4 . . . # 8 .
- FIG. 41 shows example settings for the Default_Playlist and the Playlist_Information using the same notation as FIG. 40 .
- the box on the first level shows the Default_Playlist, while the three boxes on the second level show the PLIs.
- the small divisions in the box showing the Default_Playlist shows the eight DPL_TK_SRP values included in the Default_Playlist, while the small divisions in the boxes illustrating each PLI show three or four PL_TK_SRP values.
- the setting of the TKIN of each DPL_TK_SRP included in the Default_Playlist_Information is the same as in FIG. 40 . However, the settings of the TKIN of the PL_TK_SRP included in each PLI are completely different to those in the DPL_TK_SRP.
- FIG. 42 shows the correspondence between the DPL_TK_SRP and the TKI using the same notation as in FIG. 40 .
- Playlist# 1 is composed of PL_TK_SRP#1, #2, #3. Of these, # 3 is written as the PL_TKIN of PL_TK_SRP# 1 , while # 1 is written as the PL_TKIN of PL_TK_SRP# 2 and # 2 as the PL_TKIN of PL_TK_SRP# 3 .
- Playlist# 2 is composed of PL_TK_SRP#1, #2, #3. Of these, # 8 is written as the PL_TKIN of PL_TK_SRP# 1 , while # 3 is written as the PL_TKIN of PL_TK_SRP# 2 and # 1 as the PL_TKIN of PL_TK_SRP# 3 .
- Playlist# 3 is composed of PL_TK_SRP#1, #2, #3, #4. the PL_TKIN of these PL_TK_SRP#1 to #4 are respectively set as #8, #4, #3, and #1.
- AOB# 8 that composes TrackE is played back as shown by the arrow ( 31 ).
- AOB# 4 , AOB# 5 , AOB# 6 , and AOB# 7 that compose TrackD are played back as shown by the arrow ( 32 ).
- AOB# 3 and AOB# 1 that respectively compose TrackC and TrackA are played back as shown by the arrows ( 33 ) and ( 34 ).
- a DPLI including a plurality of DK_TK_SRP has a data size that is no greater than one sector and is always loaded into the RAM of a playback apparatus.
- the playback apparatus refers to the DK_TK_SRPs that are loaded into its RAM and so can search for TKIs at high speed.
- a playback apparatus searches the DPL_TK_SRP loaded in its RAM based on the TKI indicated by the PL_TK_SRP and judges whether the current track is composed of a plurality of TKI. If so, the playback apparatus executes the appropriate procedure for playing back all of the corresponding TKIs (AOBs).
- the Default_Playlist and a plurality of PLIs are written in the Playlist_Manager. If different playback orders are written in the DPL_TKINs and PL_TKINs of the DPL_TK_SRPs and PL_TK_SRPs composing such playlists, it becomes possible to play back AOBs in different orders. By offering a variety of playback orders to the user in this way, the user can be given the impression of there being a number of music albums stored in the flash memory card 31 .
- the data size of the DPL_TK_SRP corresponding to an AOB file is small (at no more than two bytes), while the data size of the TKI corresponding to an AOB file is large (at up to 1,024 bytes).
- the DPL_TK_SRPs are reordered in the Default_Playlist_Information or a PLI, this can be performed with fewer accesses to the flash memory card 31 .
- FIGS. 43A and 43B show one example of the reordering of tracks.
- the settings of the DPL_TK_SRPs and TKIs in FIG. 43A are the same as in FIG. 40 .
- the DPL_TKIN in DPL_TK_SRP# 3 is set at TKI# 3
- the DPL_TKIN in DPL_TK_SRP# 8 is set at TKI# 8 .
- the numbers ( 1 ) ( 2 ) ( 3 ) ( 4 ) ( 5 ) ( 6 ) ( 7 ) ( 8 ) in FIG. 43B show the playback order of tracks after this editing operation. It should be noted here that while the playback order shown in FIG. 43A is TrackA, TrackB, TrackC, TrackD, TrackE, in FIG. 43B the DPL_TKINs of DPL_TK_SRP# 3 and DPL_TK_SRP# 8 are interchanged in the Default_Playlist_Information, so that the tracks will be played back in the order TrackA, TrackB, TrackE, TrackD, TrackC. In this way, the playback order of tracks can be easily changed by changing the order of the DPL_TK_SRPs in the Default_Playlist_Information.
- FIGS. 44A and 44B show how the Default_Playlist, TrackManager, and AOB files are updated when, out of the DefaultPlaylist shown in FIG. 40 , DPL_TK_SRP# 2 and TKI# 2 are deleted.
- the same part of an AOB is deleted as in FIG. 27 that was used to describe the deletion of a TKI.
- the second, third, and fourth levels in FIGS. 44A and 44B are the same as in FIG. 27 .
- the difference with FIG. 27 is that Default_Playlist_Information including a plurality of DPL_TK_SRPs is given on the first level, in the same way as FIG. 40 .
- the present example deals with the case when the user deletes TrackB composed of DPL_TK_SRP# 2 ⁇ TKI# 2 (“AOB002.SA1”) that is shown with the thick outline in FIG. 44A .
- DPL_TK_SRP# 2 is deleted from Default_Playlist_Information and DPL_TK_SRP# 3 to DPL_TK_SRP# 8 are each moved up by one place in the playback order so as to fill the place in the order freed by the deletion of DPL_TK_SRP# 2 .
- the final DPL_TK_SRP# 8 is set as “Unused”.
- the TKI corresponding to the deleted part is set as “Unused” as shown in FIGS. 27A and 27B without other TKIs being moved to fill the gap created by the deletion. Deletion of the TKI is also accompanied by the deletion of the AOB file “AOB002.SA1”.
- DPL_TK_SRPs are moved up in the playback order but TKIs are not moved, so that in FIG. 44B only the DPL_TKINs in the DPL_TK_SRPs are updated.
- the DPL_TKIN in DPL_TK_SRP# 2 is set so as to indicate TKI# 3 as shown by the arrow DT 11
- the DPL_TKIN in DPL_TK_SRP# 3 is set so as to indicate TKI# 4 as shown by the arrow DT 12
- the DPL_TKIN in DPL_TK_SRP# 4 is set so as to indicate TKI# 5
- the DPL_TKIN in DPL_TK_SRP# 5 is set so as to indicate TKI# 6 .
- the DPL_TKIN in DPL_TK_SRP# 8 that has been set at “Unused” is set so as to indicate TKI# 2 , as shown by the arrow DT 13 .
- the DPL_TK_SRP used for following tracks in the playback order are moved up, while the TKI corresponding to the deleted track is set at “Unused” while remaining in its present position. In this way, an editing operation is not accompanied by movement of TKIs, which suppresses the processing load when editing tracks.
- FIGS. 45A and 45B show how an operation that writes a new TKI and DPL_TK_SRP is performed when an “Unused” TKI and DPL_TK_SRP are present.
- FIGS. 45A and 45B show the first three levels in FIGS. 28A and 28B .
- the difference between these drawings is that the first levels in FIGS. 45A and 45B show the Default_Playlist_Information composed of a plurality of DPL_TK_SRP.
- the DPL_TK_SRP# 4 to DPL_TK_SRP# 8 are set as “Unused”.
- the TKI# 2 , TKI# 4 , TKI# 5 , TKI# 7 , TKI# 8 are set as “Unused”.
- TKIs for these four AOBs are respectively written into the following “Unused” TKIs in the TrackManager: TKI# 2 ; TKI# 4 ; TKI# 7 ; and TKI# 8 .
- the DPL_TK_SRPs for these four AOBs are written in DPL_TK_SRP# 4 to DPL_TK_SRP# 7 in the Default_Playlist_Information. Since these four AOBs compose a single track, the DPL_TK_ATR of DPL_TK_SRP# 4 is set at “Head_of_Track”, the DPL_TK_ATRs of DPL_TK_SRP# 5 and DPL_TIKSRP# 6 are set at “Middle_of_Track”, and the DPL_TKI_ATR of DPL_TK_SRP# 7 is set at “End_of_Track”.
- the DPL_TKIN of DPL_TK_SRP# 4 is set at TKI# 2 , the DPL_TKIN of DPL_TK_SRP# 5 at TKI# 4 , the DPL_TKIN of DPL_TK_SRP# 6 at TKI# 7 , and the DPL_TKIN of DPL_TK_SRP# 7 at TKI# 8 .
- TKI# 2 , TKI# 4 , TKI# 7 and TKI# 8 are managed as the fourth track TrackD.
- FIGS. 46A and 46B show one example of the combining of tracks.
- FIGS. 29A and 29B These drawings are largely the same as FIGS. 29A and 29B that were used to explain the combining of TKIs.
- the second, third, and fourth levels in FIGS. 46A and 46B are the same as the first two levels in FIGS. 29A and 29B .
- the difference between these figures is that the first levels in FIGS. 46A and 46B show Default_Playlist_Information, in which DPL_TK_SRP# 8 is set at “Unused” and is related to TKI# 2 that is also set at “Unused”.
- FIGS. 47A and 47B show one example of the division of a track. These drawings are largely the same as FIGS. 33A and 33B that were used to explain the division of TKIs.
- the second and third levels in FIGS. 47A and 47B are the same as the first two levels in FIGS. 33A and 33B .
- the difference between these figures is that the first level in FIGS. 47A and 47B shows Default_Playlist_Information, in which DPL_TK_SRP# 8 is set at “Unused” and is related to TKI# 2 that is also set at “Unused”.
- the user indicates the division of TKI# 3 (“AOB003.SA1”) shown with the thick outline into two, the positions of DPL_TK_SRP# 3 to DPL_TK_SRP# 7 are each moved down by one in the order, and a DPL_TK_SRP set at “Unused” is moved within the Default_Playlist_Information to the former position of DPL_TK_SRP# 3 .
- This new DPL_TK_SRP# 3 is associated with the TKI, TKI# 2 , newly produced by the division.
- the AOB file “AOB002.SA1” associated with TKI# 2 stores what was originally the latter part of the AOB file “AOB003.SA1”.
- DPL_TK_SRP# 2 is present before the DPL_TK_SRP# 3 that is associated with TKI# 2 and is associated with TKI# 2 and “AOB002.SA1”.
- AOB002.SA1 and “AOB003.SA1” respectively store the latter and former parts of the original “AOB03.SA1”, with the DPL_TK_SRP# 2 and DPL_TK_SRP# 3 corresponding to these files indicating that these AOBs are to be played back in the order “AOB003.SA1” and “AOB002.SA1”.
- the latter and former parts of the original “AOB003.SA1” will be played back in the order former part, latter part in accordance with the playback order given in the DPL_TK_SRP.
- a user can perform a great variety of editing operations.
- a recorded track has an intro over which a disc jockey has talked
- the user can first divide the track to separate the part including the disc jockey's voice. The user can then delete this track to leave the part of the track that does not include the disc jockey.
- FIG. 48 shows a portable playback apparatus for the flash memory card 31 of the present invention.
- the playback apparatus shown in FIG. 48 has an insertion slot for inserting the flash memory card 31 , a key panel for receiving user indications for operations such as playback, forward search, backward search, fast forward, rewind, stop etc., and an LCD (liquid crystal display) panel.
- this playback apparatus resembles other kinds of portable music players.
- the key panel includes:
- FIG. 49 shows one example of a display screen shown on the LCD panel when the user selects a playlist
- FIGS. 50A to 50E show examples of the displayed content when the user selects a track.
- the ASCII character strings “DEFAULTPLAYLIST”, “PLAYLIST# 1 ”, “PLAYLIST# 2 ”, “PLAYLIST# 3 ”, and “PLAYLIST# 4 ” represent the default playlist and the four playlists stored in the flash memory card 31 .
- the ASCII character strings “Track# 1 ”, “Track# 2 ”, “Track# 3 ”, “Track# 4 ”, “Track# 5 ” represent the five tracks that are indicated in the playback order given by the default playlist stored in the flash memory card 31 .
- the highlighted Playlist and track show the track or playlist that is currently indicated for playback or editing.
- Track# 2 will be indicated for playback within the list of tracks, as shown in FIG. 50B . If the user presses the “>>” key again, Track# 3 will be indicated for playback within the list of tracks, as shown in FIG. 50C .
- Track# 2 will be indicated for playback within the list of tracks, as shown in FIG. 50D .
- FIG. 50E if the user presses the “Play” key when any of the tracks is indicated, the playback of the indicated track will begin, while if the user presses the “Edit” key, the indicated track will be selected for editing.
- FIGS. 51A to 51C show an example operation of the jog dial.
- the playback time code displayed on the LCD panel will be increased or decreased in accordance with this certain amount.
- the example in FIG. 51A shows the case where the playback time code that is initially displayed on the LCD panel is “00:00:20”.
- the playback time code is reduced to “0:00:10” in keeping with the amount by which the jog dial was rotated.
- the playback time code is increased to “0:00:30” in keeping with the amount by which the jog dial was rotated.
- the playback apparatus enables the user to indicate any playback time code in a track by merely rotating the jog dial. If the user then presses the “Play” key, AOBs will be played back starting from a position found according to Equation 2 and Equation 3.
- the user can make fine adjustments to the playback time code used as the division boundary.
- This internal construction is shown in FIG. 52 .
- the playback apparatus includes a card connector 1 for connecting the playback apparatus to the flash memory card 31 , a user interface unit 2 that is connected to the key panel and the jog dial, a RAM 3 , a ROM 4 , a LCD panel 5 having a list frame for displaying a list of tracks or playlists and a playback time code frame for displaying a playback time code, an LCD driver 6 for driving the first LCD panel 5 , a descrambler 7 for decrypting AOB_FRAMEs using a different FileKey for each AOB file, an AAC decoder 8 for referring to the ADTS of an AOB_FRAME descrambled by the descrambler 7 and decoding the AOB_FRAME to obtain PCM data, a D/A converter 9 for D/A converting the PCM data and outputting the resulting analog signals to a speaker or headphone jack, and a CPU 10 for performing overall control over the playback apparatus.
- a card connector 1 for connecting the playback apparatus to the flash
- the present playback apparatus has no special hardware elements for processing the TrackManager and Default_Playlist_Information.
- a DPLI holding area 11 a PLI storing area 12 , a TKI storing area 13 , a FileKey storing area 14 , and a double buffer 15 are provided in the RAM 3 , while a playback control program and an editing control program are stored in the ROM 4 .
- the DPLI holding area 11 is an area for continuously holding Default_Playlist_Information that has been read from a flash memory card 31 connected to the card connector 1 .
- the PLI storing area 12 is an area that is reserved for storing Playlist_Information that has been selected for playback by the user.
- the TKI storing area 13 is an area that is reserved for storing only the TKI corresponding to the AOB file that is currently indicated for playback, out of the plurality of TKI included in the TrackManager. For this reason, the capacity of the TKI storing area 13 is equal to the data size of one TKI.
- the FileKey storing area 14 is an area that is reserved for storing only the FileKey corresponding to the AOB file that is currently indicated for playback, out of the plurality of FileKeys included in “AOBSA1.KEY” in the authentication region.
- the double buffer 15 is an input/output buffer that is used when an input process, which successively inputs cluster data (data that is stored in one cluster) read from the flash memory card 31 , and an output process, which reads AOB_FRAMEs from cluster data and successively outputs the AOB_FRAMEs to the descrambler 7 , are performed in parallel.
- the double buffer 15 successively frees the regions that were occupied by cluster data that has been outputted as AOB_FRAMEs and so secures regions for storing the next clusters to be read. This is to say, regions in the double buffer 15 are cyclically secured for storing cluster data using ring pointers.
- FIG. 53 shows how input and output are performed for the double buffer 15 .
- FIGS. 54A and 54B show how regions in the double buffer 15 are cyclically secured for storing cluster data using ring pointers.
- the arrows pointing downward and to the left are pointers to write addresses for cluster data, which is to say, the write pointer.
- the arrows pointing upward and to the left are pointers to read addresses for cluster data, which is to say, the read pointer. These pointers are used as the ring pointer.
- cluster data in the user region of the flash memory card 31 is read out and stored in the double buffer 15 as shown by the arrows w 1 and w 2 .
- the read cluster data is successively stored into the positions in the double buffer 15 shown by the write pointers wp 1 and wp 2 .
- the AOB_Frames included in the cluster data stored in this way present at the positions ⁇ circle around ( 1 ) ⁇ ⁇ circle around ( 2 ) ⁇ ⁇ circle around ( 4 ) ⁇ ⁇ circle around ( 5 ) ⁇ ⁇ circle around ( 6 ) ⁇ ⁇ circle around ( 7 ) ⁇ ⁇ circle around ( 8 ) ⁇ ⁇ circle around ( 9 ) ⁇ that are successively indicated by the read pointer are outputted one at a time to the descrambler 7 as shown by the arrows r 1 , r 2 , r 3 , r 4 , r 5 . . . .
- the cluster data 002 and 003 is stored in the double buffer 15 and the read positions ⁇ circle around ( 1 ) ⁇ ⁇ circle around ( 2 ) ⁇ ⁇ circle around ( 3 ) ⁇ ⁇ circle around ( 4 ) ⁇ are successively indicated by the read pointer, as shown in FIG. 53 .
- the read pointer reaches the read position ⁇ circle around ( 5 ) ⁇ , all of the AOB_FRAMEs included in cluster 002 will have been read, so that cluster 004 is read and, as shown by the arrow w 6 in FIG. 54A , is overwritten into the region that was previously occupied by cluster 002.
- the read pointer then advances to the read positions ⁇ circle around ( 6 ) ⁇ and ⁇ circle around ( 7 ) ⁇ , and eventually reaches the read position ⁇ circle around ( 9 ) ⁇ , at which point all of the AOB_FRAMEs included in cluster 003 will have been read, so that cluster 005 is read and, as shown by the arrow w 7 in FIG. 54B , is overwritten into the region that was previously occupied by cluster 003.
- the following describes the playback control program stored in the ROM 4 .
- FIG. 55 is a flowchart showing the processing in the AOB file reading procedure.
- FIGS. 56 , 57 , and 58 are flowcharts showing the processing in the AOB_FRAME output procedure.
- the variable w indicates one of the plurality of DPL_TL_SRPs.
- the variable z indicates an AOB file recorded in the user region, the TKI corresponding to this AOB file, and the AOB included in this AOB file.
- the variable y indicates an AOB_ELEMENT included in the AOB#z indicated by the variable z.
- the variable x indicates an AOB_FRAME included in the AOB_ELEMENT#y indicated by the variable y.
- step S 1 the CPU 10 reads the PlaylistManager and displays a list including the Default_Playlist_Information and the PLIs.
- step S 2 the CPU 10 waits for an indication to play back AOBs in accordance with either the Default_Playlist_Information or one of the PLIs.
- step S 2 When the Default_Playlist_Information is indicated, the processing moves from step S 2 to step S 3 where the variable w is initialized (#w ⁇ 1) and then to step S 4 where the TKI#z indicated by the DPL_TKIN corresponding to DPL_TK_SRP#w in the Default_Playlist Information is specified and only this TKI#z is read from the flash memory card 31 and stored into the TKI storing area 13 .
- step S 5 an AOB file#z with the same number as TKI#z is specified. In this way, the AOB file that is to be played back is finally specified.
- the specified AOB file is in an encrypted state and needs to be decrypted, so that steps S 6 and S 7 are performed.
- step S 6 the playback apparatus accesses the authentication region and reads the FileKey#z that is stored in a FileKey_Entry#z in the encryption key storing file, the FileKey_Entry#z having the same number as the specified AOB file.
- step S 7 the CPU 10 sets the FileKey#z in the descrambler 7 . This operation results in the FileKey being set in the descrambler 7 , so that by successively inputting AOB_FRAMEs included in the AOB file into the descrambler 7 , the AOB_FRAMEs can be successively played back.
- step S 8 the “first cluster number in the file” is specified for the AOB_file#z in the directory entry.
- step S 9 the CPU 10 reads the data stored in this cluster from the flash memory card 31 .
- step S 10 the CPU 10 judges whether the cluster number in the FAT value is “FFF”. If not, in step S 11 the CPU reads the data stored in the cluster indicated by the FAT value, before returning to step S 10 .
- step S 10 and S 11 When the playback apparatus reads the data stored in any of the clusters and refers to the FAT value corresponding to this cluster, the processing in steps S 10 and S 11 will be repeated so long as the FAT value is not set at “FFF”. This results in the playback apparatus successively reading clusters indicated by the FAT values.
- the cluster number given by a FAT value is “FFF”, this means that all of the clusters composing the AOB file#z have been read, so that the processing advances from step S 10 to step S 12 .
- step S 12 the CPU 10 judges whether the variable#w matches the total number of DPL_TK_SRPs. If not, the processing advances to step S 13 , where the variable#w is incremented (#w ⁇ #w+1) before the processing returns to step S 4 .
- step S 4 the playback apparatus specifies TKI#z which is indicated by the DPL_TKIN#w of DPL_TK_SRP#w in the Default_Playlist_Information, and writes only TKI#z into the TKI storing area 13 . The TKI that was used up to this point will still be stored in the TKI storing area 13 , though this current TKI will be overwritten by TKI#z that is newly read by the CPU 10 .
- the CPU 10 performs the AOB_FRAME output procedure in accordance with the flowcharts shown in FIGS. 56 , 57 , and 58 .
- the variable “play_time” shows how long playback has been performed for a current track, which is to say, the playback time code.
- the time displayed in the playback time code frame on the LCD panel 5 is updated in accordance with changes to this playback time code.
- the variable “play_data” represents the length of the data has been played back for the current track.
- step S 21 the CPU 10 monitors whether cluster data for the AOB file#z has accumulated in the double buffer 15 . This step S 21 will be repeatedly performed until cluster data has accumulated, at which point the processing advances to step S 22 where the variables x and y are initialized (#x ⁇ 1, #y ⁇ 1).
- step S 23 the CPU 10 searches the clusters for AOB file #z and detects the AOB_FRAME#x in the AOB_ELEMENT#y that is positioned no earlier than the Data_Offset given in the BIT#z included in TKI#z. In this example, it is assumed that the seven bytes starting from the SZ_DATA are occupied by the ADTS header.
- the data length indicated by the ADTS header can be recognized as audio data.
- the audio data and ADTS header are read together and are outputted to the descrambler 7 .
- the descrambler 7 decrypts the AOB_FRAMEs, which are then decoded by the AAC decoder 8 and reproduced as audio.
- step S 24 the AOB_FRAME#x is outputted to the descrambler 7 , and in step S 25 the variable play_time is incremented by the playback period of the AOB_FRAME#x and the variable play_data is incremented the amount of data corresponding the AOB_FRAME#x. Since the playback time of AOB_FRAME is 20 msec in the present case, 20 msec is added to the variable “play_time”.
- step S 26 the playback apparatus refers to the ADTS header of AOB_FRAME#x and specifies where the next AOB_FRAME is.
- step S 27 the playback apparatus increments the variable#x (#x ⁇ #x+1) and sets AOB_FRAME#x as the next AOB_FRAME.
- step S 28 AOB_FRAME#x is inputted into the descrambler 7 .
- step S 29 the variable play_time is incremented by the playback period of the AOB_FRAME#x and the variable play_data is incremented the amount of data corresponding the AOB_FRAME#x.
- step S 30 the CPU 10 judges whether the variable #x has reached the value given in FNs — 1st_TMSRTE.
- step S 31 the playback apparatus checks whether the user has pressed any key aside from the “Play” key, and then returns to step S 26 .
- the playback apparatus hereafter repeats the processing in steps S 26 to S 31 until the variable #x reaches the value in FNs — 1st_TMSRTE or until the user presses any key aside from the “Play” key.
- step S 30 the judgement “Yes” is made in step S 30 , and the processing proceeds to step S 32 in FIG. 57 . Since all of the AOB_FRAMEs included in the present AOB_ELEMENT will have been inputted into the descrambler 7 in the processing between step S 26 to S 30 , in step S 32 the variable #y is incremented to set the next AOB_ELEMENT as the data to be processed and the variable #x is initialized (#y ⁇ y+1, #x ⁇ 1).
- step S 33 the playback apparatus refers to the TKTMSRT and calculates the first address of the AOB_ELEMENT#y.
- the playback apparatus then performs the procedure made up of steps S 34 to S 42 .
- This procedure reads the AOB_FRAMEs included in an AOB_ELEMENT one after another, and so can be said to resemble the procedure made up of steps S 24 to S 31 .
- the difference with the procedure made up of steps S 24 to S 31 is the condition by which the procedure made up of steps S 24 to S 31 ends is whether the variable #x has reached the value shown by “FNs — 1st_TMSRTE”, while the condition by which procedure made up of steps S 34 to S 42 ends is whether the variable #x has reached the value shown by “FNs_Middle_TMSRTE”.
- step S 43 the CPU 10 increments the variable #y and initializes the variable #x (#y ⁇ #y+1, #x ⁇ 1). After this, in step S 44 the variable y judges whether the variable #y has reached a value that is equal to one less than the TotalTMSRT_entry_Number in the TMSRT_Header in the TKI#z.
- step S 44 When the variable #y is lower than (TotalTMSRT_entry_Number ⁇ 1), the AOB_ELEMENT#y is not the final AOB_ELEMENT, so that the processing returns from step S 44 to step S 32 and the loop procedure of step S 32 to step S 42 is performed.
- the variable #y reaches (TotalTMSRT_entry_Number ⁇ 1) the read procedure can be assumed to have proceeded as far as the penultimate AOB_ELEMENT, so that the judgement “Yes” is given in step S 44 and the processing advances to step S 45 in FIG. 58 .
- steps S 45 to S 54 resembles the procedure composed of steps S 33 to S 42 in that each of the AOB_FRAMEs in the final AOB_ELEMENT are read.
- step S 54 The procedure composed of steps S 49 to S 54 is repeated until the conditions in step S 53 are satisfied, at which point the judgement “Yes” is given in step S 53 and the processing advances to step S 55 .
- step S 55 the CPU 10 increments the variable #z (#z ⁇ #z+1) before the processing returns to step S 21 where the CPU 10 waits for the next AOB file to accumulate in the double buffer 15 .
- step S 22 the procedure composed of steps S 22 to step S 54 is repeated. This means that the TKI indicated by the DPL_TKIN of the next DPL_TK_SRP is specified and the AOB file corresponding to this TKI, which is to say, the AOB file with the same number as the TKI, is specified.
- the playback apparatus accesses the authentication region and specifies the FileKey, out of the FileKeys in the encryption key storing file, that has the same number as the TKI, before reading this FileKey and setting it in the descrambler 7 .
- the AOB_FRAMEs included in the AOB file having the same number as the TKI are successively read and played back.
- FIGS. 59A to 59D show how the playback time code displayed in the playback time code display frame of the LCD panel 5 is increased in accordance with the updating of the variable play_time.
- the playback time code is “00:00:00.000”, though when the playback of AOB_FRAME# 1 ends, the playback period 20 msec of AOB_FRAME# 1 is added to the playback time code to update it to “00:00:00.020”, as shown in FIG. 59B .
- the playback period 20 msec of AOB_FRAME# 2 is added to the playback time code to update it to “00:00:00.040”, as shown in FIG. 59C .
- step S 31 of the flowchart in FIG. 56 if the user presses a key aside from the “Play” key, the processing in this flowchart is terminated.
- the processing that accompanies a pressing of “Stop” or “Pause” key has already been described, though when the user presses one of the keys provided to have the playback apparatus perform special playback, the processing in this flowchart, or in the flowcharts shown in FIG. 56 , 57 , or 58 is terminated and suitable processing for the pressed key is performed.
- the following describes the procedure executed by the CPU 10 (1) when performing the forward search function in response to the user pressing the “>>” key and (2) when performing the time search function in response to the user operating the jog dial after pressing the “Pause” or “Stop” key.
- FIG. 60 is a flowchart showing the procedure executed by the CPU 10 when performing the forward search function.
- the judgement “Yes” is given in step S 31 , step S 42 or step S 54 in the flowcharts in FIGS. 56 , 57 and 58 and the CPU 10 performs the processing in the flowchart of FIG. 60 .
- step S 61 the AOB_FRAMEs #x to #(x+f(t) ⁇ 1) are inputted into the descrambler 7 .
- “t” represents the intermittent playback period
- f(t) represents the number of frames corresponding to the intermittent playback period
- d(t) represents the amount of data corresponding to the intermittent playback period.
- step S 62 the variable play_time showing the playback elapsed time, and the variable play_data showing the playback data amount are respectively updated using intermittent playback period “t”, the number of frames f(t) corresponding to intermittent playback period, and the amount of data d(t) corresponding to the intermittent playback period (x ⁇ x+f (t), play_time_play_time+t, play_data_play_data+d(t)).
- the intermittent playback period will generally be 240 msec (equivalent to the playback period of twelve AOB_FRAMEs).
- FIGS. 61A and 61B show the incrementing of the playback time code during a forward search operation.
- FIG. 61A shows the initial value of the playback time code, with the playback point being the AOB_FRAME# 1 in AOB_ELEMENT# 51 .
- the playback time code in this case is “00:00:01.000”.
- the playback period of twelve AOB_FRAMEs i.e., 240 msec
- the playback time code becomes “00:00:01.240”, as shown in FIG. 61B .
- step S 63 the CPU 10 compares the incremented variable #x with the total number of frames in AOB_ELEMENT#y and judges whether the incremented variable #x is within the total number of frames in AOB_ELEMENT#y.
- the number of frames in an AOB_ELEMENT positioned at the start of an AOB is “FNs — 1st_TMSRTE”
- the number of frames in an AOB_ELEMENT positioned in a central part of an AOB is “FNs_Middle_TMSRTE”
- the number of frames in an AOB_ELEMENT positioned at the end of an AOB is “FNs_Last_TMSRTE”.
- the CPU 10 performs the above judgement by comparing an appropriate one of these values with the variable #x. When the variable x is not within the present AOB_ELEMENT#y, the CPU 10 then judges in step S 64 whether there is an AOB_ELEMENT that follows the AOB_ELEMENT#y.
- step S 64 the variable #x is reduced by the number of AOB_FRAMEs in the AOB_ELEMENT#y and in step S 66 the variable#y is updated (#y#y+1). As a result, the variable#x will now indicate the frame position of a frame in the next AOB_ELEMENT#y indicated by the updated variable #y. Conversely, when the variable #x indicates an AOB_FRAME that is present in the current AOB_ELEMENT (S 63 : Yes), the processing in steps S 64 -S 66 is skipped and the processing advances to step S 67 .
- the variables #x, play_time, and play_data are updated in accordance with the intermittent skip period.
- the period “skip_time” that is equivalent to the intermittent skip period is two seconds, the number of frames that are equivalent to this skip_time is given as f(skip_time) and the amount of data that is equivalent to this skip_time is given as d(skip_time).
- these values are used to update the variables #x, play_time, and play_data (#x ⁇ #x+f(skip_time), play_time ⁇ play_time+skip_time, and play_data ⁇ play_data+d(skip_time)).
- the intermittent skip period is added to the variable#x showing a frame position within the AOB_ELEMENT# 51 .
- the variable #y is updated to indicate the next AOB_ELEMENT and the number of frames in the AOB_ELEMENT# 51 is subtracted from the variable #x.
- the variable#x will now indicate a frame position within the AOB_ELEMENT# 52 indicated by the updated variable #y.
- the variable #x is updated by calculating (3240 msec-2000 msec)/20 msec) to give the value “62”, and so indicates the AOB_FRAME# 62 in the AOB_ELEMENT# 52 .
- the playback time code is updated as shown in FIG. 61D by adding “0.240” to the present value of “00:00:03.240” to give “00:00:03.480”.
- step S 67 the variables are updated in accordance with the intermittent skip time and then the processing in steps S 68 to S 71 are performed.
- This processing in steps S 68 to S 71 is the same as the processing in steps S 63 to S 66 and so updates the variable#x by a number of frames that is equivalent to the intermittent skip_time “skip_time”, before checking whether the variable#x still indicates an AOB_FRAME within the present AOB_ELEMENT#y. If not, the variable #y is updated so that the next AOB_ELEMENT is set as the AOB_ELEMENT#y and the variable#x is converted so as to indicate a frame position in this next AOB_ELEMENT.
- step S 72 the CPU 10 refers to the TKTMSRT and calculates the start address for the AOB_ELEMENT#y. Then, in step S 73 , the CPU 10 starts to search for an ADTS header starting from the start address of the AOB_ELEMENT#y to detect the AOB_FRAME#x. In step S 74 , the CPU 10 judges whether the user has pressed any key aside from the forward search key. If not, the AOB_FRAMEs from the AOB_FRAME#x to the AOB_FRAME#x+f(t) ⁇ 1 are inputted into the descrambler 7 , and the processing in steps S 62 to S 73 is repeated.
- the following describes the processing performed when the time search function is used.
- the tracks in the Default_Playlist_Information are displayed and the user indicates a desired track.
- the playback time code is updated. If the user then presses the “Play” key, the playback time code at that point is used to set a value in the variable “Jmp_Entry” in seconds.
- the variables #y and #x are calculated so as to satisfy Equation 2.
- a search for the AOB_FRAME#x is started from the address in the (y+2) th position in the TKTMSRT corresponding to this AOB. Once this AOB_FRAME#x has been found, playback starts from AOB_FRAME#x.
- the following describes how the AOB_ELEMENT and frame position from which playback should start are specified when a playback time code is indicated using the jog dial.
- Equation 2 is used as follows
- This editing control program is executed when the user presses the “Edit” key, and contains the procedures shown in FIGS. 63 , 64 , and 65 .
- step S 101 When the user presses the “Edit” key, an interactive screen is displayed in step S 101 in FIG. 63 to ask the user which of the three fundamental editing operations “deletion”, “division” and “combining” is to be performed.
- step S 102 the CPU 10 judges what operation has been made by the user in response to the interactive screen.
- ” keys on the key panel are also used as indicating “Up” and “Down” cursor operations, (i.e., these keys are used as “Up” and “Down” cursor keys).
- the processing proceeds to the loop procedure composed of steps S 103 and S 104 .
- step S 103 the CPU 10 judges whether the user has pressed the “
- step S 104 the CPU 10 judges whether the user has pressed the “Edit” key.
- the processing advances from step S 103 to S 105 , where the indicated track is set as the track to be edited.
- step S 105 the indicated track is set as the track to be edited.
- step S 105 the indicated track is set as a track to be deleted.
- the processing shown in FIG. 44 is executed, so that the TKI_BLK_ATR of each TKI for the indicated track is set at “Unused” to delete the indicated track.
- step S 102 When the user selects the combining process, the processing proceeds from step S 102 to the loop procedure composed of steps S 107 to S 109 .
- the playback apparatus receives user inputs via the “
- the processing advances from step S 107 to step S 110 where the indicated track is highlighted on the display.
- step S 111 the currently indicated track is set as the first track to be used in this editing process and the processing returns to the loop procedure composed of steps S 107 to S 109 .
- step S 112 the CPU 110 refers to the BITs in the TKIs of the former and the latter tracks and judges what kind of AOBs (Type1 or Type2) are present at the respective start and end of each of these tracks and tracks on either side of these tracks, if present.
- step S 113 the CPU 10 judges whether the arrangement of AOBs matches a certain pattern.
- the arrangement of AOBs matches one of the four patterns shown in FIG. 32A to 32D where it is clear that three Type2 AOBs will not be present consecutively after the combining, the former and latter tracks are combined into a single track in step S 115 .
- the operation shown in FIG. 46 is performed for the TKI and DPL_TK_SRP corresponding to these AOBs.
- the plurality of tracks selected for editing are combined into a single track.
- the arrangement of AOBs does not match any of the patterns in FIGS. 32A to 32D , meansing that there will be three or more Type2 AOBs after the combining, the CPU 10 judges that the combined track may cause a buffer underflow and so terminates the combining process.
- step S 102 When the user indicates that a track is to be divided, the processing advances from step S 102 to the loop procedure composed of steps S 116 to S 117 .
- the playback apparatus receives user inputs via the “
- step S 116 When the user presses the “
- step S 118 When the user presses the “Edit” key, the judgement “Yes” is given in step S 117 and the processing advances to step S 119 .
- step S 119 the indicated track is determined as the track to be edited and the processing advances to step S 120 where the playback of this track is commenced.
- step S 121 the playback apparatus receives a user input via the “Mark” key.
- step S 122 the playback apparatus receives user operations made via the jog dial.
- step S 124 the playback time code is updated in step S 124 in accordance with the rotation of the jog dial.
- step S 123 the playback time code displayed when the user pressed the “Edit” key is set as the division boundary.
- step S 125 the playback time code displayed when the user pressed the “Edit” key is set as the division boundary. Note that an “Undo” function may be provided for this setting of the division boundary to allow the user to invalidate the selected division boundary.
- step S 126 the processing explained with reference to FIG. 47 is executed in step S 126 to update the DPLI and TKI so as to divide the selected track.
- the processing switches to the procedure shown by the flowchart in FIG. 65 .
- the variable k given in this flowchart is used to indicate the position of a track in the playback order given by the Playlist that is being edited.
- the flowchart in FIG. 65 starts with this variable k being initialized to “1” in step S 131 , before the processing advances to the loop procedure composed of steps S 132 to S 134 .
- the playback apparatus receives user operations made via the c ⁇ , “>>
- the processing advances from step S 132 to step S 135 where a new track is indicated in accordance with the pressing of the “
- step S 136 the track indicated when the user presses the “Edit” key is selected as the kth track in the playback order.
- step S 137 the variable k is incremented and the processing returns to the loop procedure composed of steps S 132 to S 134 . This procedure is repeated so that the second, third and fourth tracks are successively selected. If the user presses the “Stop” key after having specified several tracks that are to be played back in the specified order as a new Playlist, the processing advances from step S 134 to step S 138 where a PLI composed of PL_TK_SRPs that specify the TKIs corresponding to these tracks is generated.
- FIG. 66 shows one example of a recording apparatus.
- This recording apparatus can be connected to the Internet, and is a standard personal computer that can perform reception when an encrypted SD-Audio directory is sent via communication lines to the recording apparatus by an electronic music distribution service, or when an audio data transport stream is sent via communication lines to the recording apparatus by an electronic music distribution service.
- FIG. 67 shows the hardware composition of the present recording apparatus.
- the recording apparatus includes a card connector 21 for connecting the recording apparatus to the flash memory card 31 , a RAM 22 , anon-removable disk apparatus 23 for storing a recording control program that performs overall control over the recording apparatus, an A/D converter 24 that A/D converts audio inputted via a microphone to produce PCM data, an ACC encoder 25 for encoding the PCM data in units of a fixed time and assigning ADTS headers to produce AOB_FRAMEs, a scrambling unit 26 for encrypting the AOB_FRAMEs using a different FileKey for each AOB_BLOCK, a modem apparatus 27 for receiving an audio data transport stream when an encrypted SD-Audio directory is sent via communication lines to the recording apparatus by an electronic music distribution service, or when an audio data transport stream is sent via communication lines to the recording apparatus by an electronic music distribution service, a CPU 28 for performing overall control over the recording apparatus, a keyboard 29 for receiving inputs made by the user, and a display 30 .
- a card connector 21 for connecting
- the recording apparatus can write the encrypted SD-Audio directory into the data region and authentication region of the flash memory card 31 as soon as the encrypted SD-Audio directory has been properly received.
- the recording apparatus uses the following four input routes to write an audio data transport stream onto the flash memory card 31 .
- the four input routes RT 1 , RT 2 , RT 3 , and RT 4 are used to input an audio data transport stream when an audio data transport stream is stored in the flash memory card 31 .
- the input route RT 1 is used when an encrypted SD-Audio directory is sent via communication lines to the recording apparatus by an electronic music distribution service, or when an audio data transport stream is sent via communication lines to the recording apparatus by an electronic music distribution service.
- the AOB_FRAMEs included in the transport stream are encrypted so that a different FileKey is used for the AOB_FRAMEs in different AOBs. Since there is no need to encrypt or encode an encrypted transport stream, the SD-Audio directory or audio data transport stream can be stored directly into the RAM 22 in its encrypted state.
- Input route RT 2 is used when audio is inputted via a microphone.
- the audio inputted via the microphone is subjected to A/D conversion by the A/D converter 24 to produce PCM Data.
- the PCM data is then encoded by the AAC encoder 25 and assigned ADTS headers to produce AOB_FRAMEs.
- the scrambling unit 26 encrypts the AOB_FRAMEs using a different FileKey for each AOB_FRAMEs in different AOB_FILEs to produce encrypted audio data.
- the encrypted audio data is stored in the RAM 22 .
- Input route RT 3 is used when PCM data read from a CD is inputted into the recording apparatus. Since data is inputted in PCM format, the data can be inputted as it is into the AAC encoder 25 . This PCM data is encoded by the ACC encoder 25 and assigned ADTS headers to produce AOB_FRAMEs.
- the scrambling unit 26 encrypts the AOB_FRAMEs using a different FileKey for the AOB_FRAMEs in different AOBs to produce encrypted audio data. After this, the encrypted audio data is stored in the RAM 22 .
- the input route RT 4 is used when a transport stream inputted via one of the three input routes RT 1 , RT 2 , and RT 3 is written into the flash memory card 31 .
- This storing of audio data is accompanied by the generation of TKIs and Default_Playlist_Information.
- the main functioning of the recording apparatus is stored in the ROM.
- a recording program that includes the characteristic processing of the recording apparatus which is to say, the recording of AOBs, the TrackManager, and the PlaylistManager, is stored in the non-removable disk apparatus 23 .
- the variables “Frame_Number” and “Data_Size” used in this flowchart are as follows.
- the variable Frame_Number is used to manage the total number of AOB_FRAMEs that have already been recorded in an AOB_FILE.
- the variable Data_Size is used to manage the data size of the AOB_FRAMEs that have already been recorded in the AOB_FILE.
- step S 200 The processing in this flowchart starts in step S 200 with the CPU 28 generating the DefaultPlaylist and the TrackManager.
- step S 201 the CPU 28 initializes the variable #z (z ⁇ 1)
- step S 202 the CPU 28 generates the AOB_FILE#z and stores it in the data region of the flash memory card 31 .
- the filename, filename extension, and first cluster number for the AOB_FILE#z will be set in a directory entry in the SD_Audio Directory in the data region.
- step S 203 the CPU 28 generates TKI#z and stores it in the TrackManager.
- step S 204 the CPU 28 generates the DPL_TK_SRP#w and stores it in the Default_Playlist_Information.
- step S 205 the CPU 28 initializes the variable#y (#y ⁇ 1) and in step S 206 , the CPU 28 initializes the Frame_Number and Data_Size (Frame_Number ⁇ 0, Data_Size ⁇ 0).
- step S 207 the CPU 28 judges whether the input of the audio data transport stream that should be written in the AOB_FILE# has ended.
- the CPU 28 gives the judgement “No” in step S 207 and the processing advances to step S 209 .
- step S 209 the CPU judges whether the amount of AAC audio data that has accumulated in the RAM 22 is at least equal to the cluster size. If so, the CPU 28 gives the judgement “Yes” and the processing advances to step S 210 where an amount of AAC audio data equal to the cluster size is written into the flash memory card 31 . The processing then advances to step S 211 .
- step S 210 When sufficient AAC audio data has not accumulated in the RAM 22 , step S 210 is skipped and the processing advances to step S 211 .
- step S 211 the CPU increments the Frame_Number (Frame_Number ⁇ Frame_Number+1) and increases the value of the variable Data_Size by the data size of the AOB_FRAME.
- step S 212 the CPU 28 judges whether the value of Frame_Number has reached the number of frames that is set in “FNs_Middle_TMSRTE”, the value of “FNs_Middle_TMSRTE” is set in accordance with the sampling frequency used when encoding the audio data transport stream.
- the CPU 28 gives the judgement “Yes” in step S 212 . If not, the CPU 28 gives the judgement “No” and the processing returns to step S 207 .
- the processing in steps S 207 to S 212 is therefore repeated until the judgement “Yes” is given in either step S 207 or in step S 212 .
- step S 212 the CPU 28 gives the judgement “Yes” in step S 212 and the processing advances from step S 212 to step S 213 where Data_Size is stored in the TKTMSRT of TKI#z as the TMSRT_entry#y for the AOB_ELEMENT#y.
- step S 214 the CPU 28 increments the variable#y (#y ⁇ #y+1) before checking in step S 215 whether the variable#y has reached “252”.
- step S 216 the CPU 28 judges whether a silence of a predetermined length is present in the encoded audio, which is to say that the audio data has reached a gap present between tracks. When no such continuous silence is present, the processing composed of steps S 206 to S 215 is repeated. When the variable#y has reached the value 252 , or a silence of a predetermined length is present in the encoded audio, the judgement “Yes” is given in one of steps S 215 and S 216 and the processing advances to step S 217 where the variable#z is incremented (#z ⁇ #z+1).
- steps S 202 to S 216 is repeated for the incremented variable #z.
- the CPU 28 can have AOBs including a plurality of AOB_ELEMENTs recorded one after the other into the flash memory card 31 .
- step S 208 the CPU 28 stores the value of the variable Data_Size in the TKTMSRT of the TKI#z as the TMSRT_Entry#y for the AOB_ELEMENT#y.
- the above processing results in an encrypted audio data transport stream being stored in the flash memory card 31 .
- the following procedure is then used to store the FileKey required for decrypting this encrypted audio data transport stream in the authentication region.
- the AOB file(s), the file storing the TKMG, the file storing the PLMG, and the encryption key storing file storing a different FileKey for each AOB are sent to the recording apparatus by a provider of the electronic music distribution service.
- the CPU 28 receives these files and writes the AOB file(s), the file storing the TKMG, and the file storing the PLMG into the user region of the flash memory card 31 .
- the CPU 28 writes only the encryption key storing file storing a different FileKey for each AOB into the authentication region.
- the CPU 28 When the audio is inputted via the input route RT 2 or RT 3 , the CPU 28 generates a different FileKey every time the encoding of a new AOB commences and sets the generated key in the scrambling unit 26 . In addition to being used by the scrambling unit 26 to encrypt the present AOB, this FileKey is stored following the FileKey Entry in the encryption key storing file present in the authentication region.
- the files storing AOBs are encrypted using different encryption keys, so that if the encryption key used to encrypt one file is decoded and exposed, the exposed encryption key can only be used to decrypt a file storing one AOB, with such exposure having no effect on other AOBs that are stored in other files. This minimizes the damage caused when one encryption key is exposed.
- the audio data was described as being in AAC format, though the present invention can also be applied to audio data in another format such as MP3 (MPEG 1 Audio Layer 3), Dolby-AC3, or DTS (Digital Theater System).
- MP3 MPEG 1 Audio Layer 3
- Dolby-AC3, or DTS Digital Theater System
- the recording apparatus and playback apparatus were described as being separate devices, though a portable playback apparatus can be equipped with the functioning of the recording apparatus and a recording apparatus in the form of a personal computer can be equipped with the functions of the playback apparatus. Aside from the portable playback apparatus and personal computer recording apparatus, the functions of the playback apparatus and recording apparatus can also be provided to a communication device that is capable of downloading content from a network.
- a mobile telephone capable of Internet access may be provided with the functions of the playback apparatus and recording apparatus described in the above embodiment.
- This mobile telephone may store contents downloaded via a wireless network in the flash memory card 31 in the same way as in the above embodiment.
- the recording apparatus described in the above embodiment is provided with the modem apparatus 27 for connecting to the Internet, any other device capable of connecting to the Internet, such as a terminal adapter for an ISDN line, may be provided instead.
- the procedures shown in the flowcharts shown in FIGS. 55 to 58 , FIG. 60 , FIG. 63 to FIG. 65 , and FIG. 68 can be achieved by executable programs that may be distributed and sold having been recorded on a recording medium.
- This recording medium may be an IC card, an optical disc, a floppy disk, or the like, with the programs recorded on the recording medium being used having first been installed into standard computer hardware.
- standard computer hardware can perform the same functioning as the playback apparatus and recording apparatus described in the above embodiment.
- the second embodiment of the present invention relates to an improvement in the storage of still images together with the AOB files described in the first embodiment. These still images are to be displayed when the AOB files are played back.
- FIG. 69 shows the hierarchical construction of the flash memory card 31 of this second embodiment.
- the hierarchical construction for the flash memory card 31 described in this embodiment differs from that of the first embodiment in that POBs (picture objects) have been added to the presentation data and a POBManagers has been added to the navigation data.
- POBs are pieces of still image data in JPEG (Joint Photographic Experts Group) format and are referred to by the PlaylistManager and the TrackManager.
- the POBManager is management information that describes how the POBs should be referred to by the PlaylistManager and the TrackManager.
- the internal compositions of the user data area and the protected area in the file system layer are modified to those shown in FIGS. 70 A and 70 B.
- the user data area shown in FIG. 70A differs from that shown in FIG. 8A in that files named “POBXXX.JPG” and “POBXXX.SP1” have been added, in addition to the POBManager file “POB000.POM”.
- the files “POBXXX.JPG” and “POBXXX.SP1” correspond to the POBs shown in FIG. 69 , while the file “POB000.POM” corresponds to the POBManager.
- the difference between the files “POBXXX.JPG” and “POBXXX.SP1” lies in whether copyright protection is necessary.
- Files with a “JPG” filename extension are merely files containing still image data in JPEG format, while files with an “SP1” filename extension have been encrypted to protect the copyrights over the still images.
- SP is an abbreviation for “Secure Picture” and shows that copyright protection is necessary.
- Still images such as family photographs or memorial pictures taken by users can be recorded onto a flash memory card to allow users to personalize the stored content. Since copyright protection is generally unnecessary for such images, they can be recorded on a flash memory card in JPEG format without encryption. On the other hand, artist photographs and album artwork are generally the property of the artist or record label. Since there is the risk of users illegally copying images that have been provided by an electronic music distribution service, these images are recorded on a flash memory card as “Secure Picture” files.
- the numbers “001”, “002”, “003”, . . . assigned to the filenames “POBXXX.SP1” and “POBXXX.JPG” are the POB numbers that are assigned to individual picture objects (POBs). This means that picture objects (POBs) can be specified using POB numbers.
- FIG. 70B shows the composition of the protected area in this second embodiment.
- the protected area in this second embodiment further includes an encryption key storing file named “POBSP1.key”.
- This file stores the FileKeys used for decrypting the (encrypted) files “POBXXX.SP1”.
- a FileKey needs to be extracted from this encryption key storing file “POBSP1.key”.
- a server computer operated by a record label that uses electronic music distribution stores the SD_Audio directories shown in FIGS. 70A and 70B .
- the server computer compresses the appropriate SD_Audio directory, encrypts it, and then sends it to the user who issued the order.
- the user's computer receives the SD_Audio directory, decrypts it, decompresses it, and so obtains the original SD_Audio directory.
- the computer may instead download tracks (AOBs) with the accompanying still images (POBs) from the server computer, and then generate the SD-Audio directories shown in FIGS. 70A and 70B by itself on the flash memory card 31 .
- FIG. 71A shows the internal composition of a “POBXXX.JPG” file. This file includes still image data that has not been encrypted, and so has the same composition as a standard JPEG file.
- FIG. 71B shows the internal composition of a “POBXXX.SP1” file.
- such files include a POB_Header (POB_H) and encrypted still image data in JPEG format.
- the broken lines hP 1 shown in FIG. 71B show the internal composition of the POB_H.
- the POB_H is composed of a two-byte POB_ID set at the value “FFE0” to show the present file is a POB file, a one-byte reserved region, a one-byte POB_ATR that shows whether encrypted data is present in the “POBXXX.SP1”, and a four-byte POB_SZ showing the data size of the POB.
- FIG. 71 C shows an example of a POB file that stores a file path instead of an encrypted data body.
- the filename “photo001.JPG” given in the path “ ⁇ DCIM ⁇ Ctg — 001 ⁇ photo001.JPG” indicates a file storing still image data for a digital photograph taken using a digital still camera.
- a directory path and filename are indicated in a POB file in this way, indirect reference is made to image data stored in the file “photo001.JPG” with the path “ ⁇ DCIM ⁇ Ctg — 001 ⁇ photo001.JPG”.
- the POB_ATR in the POBManager is set at the value “1” to show that there is “no data body”.
- a POB file such as that shown in FIG. 71C can specify a JPG file storing still image data using an indirect reference file path (in FIG. 71C the device driver for the digital still camera requires files to be stored with the path “ ⁇ DCIM ⁇ Ctg — 001 ⁇ photo001.JPG” etc.).
- FIG. 71C the device driver for the digital still camera requires files to be stored with the path “ ⁇ DCIM ⁇ Ctg — 001 ⁇ photo001.JPG” etc.).
- the files “POBXXX.JPG” and “POBXXX.SP1” in the presentation data are displayed in synchronization with the playback of tracks that was described in the first embodiment.
- the PlaylistManager and TrackManager of the second embodiment have the compositions shown in FIG. 72 .
- FIG. 72 shows the detailed compositions of the PlaylistManager and the TrackManager in this second embodiment.
- the PlaylistManager and the TrackManager in this embodiment differ from those of the first embodiment that were shown in FIG.
- the Default_Playlist_General_Information includes a DPLI_ID field in which a unique identifier for the DPLI is written, a DPLI_TK_Ns field in which the number of tracks referred to by the DPLI is written, a DPLI_PB_TM field in which the total playback time of all of the tracks referred to by the default playlist is written in millisecond units, a DPLI_POB_ATR field, and sixty DPLI_POB_SRP fields.
- DPLGI DPLI_ID field in which a unique identifier for the DPLI is written
- a DPLI_TK_Ns field in which the number of tracks referred to by the DPLI is written
- a DPLI_PB_TM field in which the total playback time of all of the tracks referred to by the default playlist is written in millisecond units
- a DPLI_POB_ATR field a DPLI_POB_ATR field
- each piece of Playlist_General_Information is composed of a PLI_ID field in which a unique identifier for the PLI is written, a PLI_TK_Ns field in which the number of tracks (where the maximum is “99”) referred to by the PLI is written, a PLI_PB_TM field in which the total playback time of all of the tracks referred to by the playlist is written in millisecond units, a PLI_POB_ATR field, and twenty PLI_POB_SRP fields.
- the TKGI in this second embodiment further includes two kinds of information, the TKI_POB_ATR and TKI_POB_SRPs.
- the DPLGI further includes two kinds of information, the DPLI_POB_ATR and DPLI_POB_SRPs, and each PLGI further includes two kinds of information, the PLI_POB_ATR and PLI_POB_SRPs.
- the TKI_POB_SRPs, PLI_POB_SRPs, and DPLI_POB_SRPs each have the same composition and are used to specify a POB.
- FIG. 73 shows how POB files, such as those shown in FIG. 70A , are specified by the TKI_POB_SRPs, PLI_POB_SRPs, and DPLI_POB_SRPs.
- the following describes the data construction of the TKI_POB_ATR (DPLI_POB_ATR, PLI_POB_ATR) and the TKI_POB_SRPs (DPLI_POB_SRPs, PLI_POB_SRPs).
- a TKI_POB_SRP is a field that specifies a POB to be displayed during the playback period of a specific AOB, out of the entire playback period of the tracks indicated in order for playback by the Default_Playlist_Information or a PLI.
- a POB to be displayed during a track can be specified.
- FIG. 74 shows the data construction of the TKI_POB_SRPs and TKI_POB_ATR.
- a TKI_POB_SRP is composed of a “POB specifying field” (shown as the “POB_No.” in the drawing) between the bit number b 25 and the bit number b 16 , a “Number Of Pixels” field between the bit number b 11 and the bit number b 8 , a “Huffman Table” field between the bit number b 7 and the bit number b 6 , a “Chrominance Sampling” field between the bit number b 5 and the bit number b 4 , and a “Picture Coding Mode” field between the bit number b 3 and the bit number b 0 .
- the fields between the bit number b 12 and the bit number b 15 and between the bit number b 26 and the bit number b 31 are reserved regions.
- the “POB specifying field” is used for storing a number between “1” and “999” as the number of the POB to be displayed during the playback period of the AOB file corresponding to this TKI.
- the “POB specifying field” is set at “0”.
- the “Picture Coding Mode” is a field that is used to inform a playback apparatus of the encoding method used for the still image specified by the “POB Specifying Field”.
- the “Chrominance Sampling” field is used to show the ratio used for the luminance sampling and the chrominance sampling of two colors when the still image specified by the “POB Specifying Field” was encoded.
- the binary value “00” is set in this field to indicate the ratio is “4:2:2”, while the value “01” is set to indicate the ratio is “4:2:0”.
- the “Huffman Table” field shows whether a typical Huffman table should be used when displaying the still image specified by the “POB Specifying Field”. This field is set at “00” when a Huffman table should be used.
- the “Number Of Pixels” field is a field in which the size of the still image specified by the “POB specifying field” is written in pixels.
- the binary value “0000” is written in this field when the still image specified by the “POB Specifying Field” is 96*96 pixels, the “0001” is written when the image is 640*480 pixels, and the value “0010” is written when the image is another size that is in a range of 160*120 pixels to 1800*1200 pixels.
- the TKGI includes twenty TKI_POB_SRPs with this construction, so that a maximum of twenty still images can be displayed during the playback of a track.
- a track is composed of several TKIs, only the TKI_POB_SRPs in the first TKI are valid.
- the “TKI_POB_ATR” is provided to specify how the POBs specified by the twenty TKI_POB_SRPs in a TKGI should be displayed.
- the “TKI_POB_ATR” includes a “Display Order Mode” between bit number b 0 and bit number b 1 and a “Display Timing Mode” between bit number b 2 and bit number b 3 .
- the “Display Order Mode” field is set to show the order in which the POBs specified by the twenty TKI_POB_SRPs in a TKGI are to be displayed.
- POBs are displayed in one of three modes during the playback period of an AOB.
- the first mode is called “Sequential Mode” and is where the POBs specified by a maximum of twenty TKI_POB_SRPs in a TKGI are displayed in the order in which the TKI_POB_SRPs are given in the TKGI.
- the second mode is called “Random Mode” and is where the POBs specified by a maximum of twenty TKI_POB_SRPs in a TKGI are displayed in a random order.
- the third mode is called “Shuffle Mode” and is where the POBs specified by a maximum of twenty TKI_POB_SRPs in a TKGI are displayed in a random order without repetition.
- the binary value “00” is set in the “Display Order Mode” field. Conversely, the binary value “01” is set to indicate random mode and the binary value “10” is set to indicate shuffle mode.
- the “Display Timing Mode” field is set to show whether the display of POBs specified by a maximum of twenty TKI_POB_SRPs in a TKGI should be synchronized with the playback of the AOB file corresponding to the TKI.
- the mode where images are synchronized with audio is called “Slideshow Mode”. During “Slideshow Mode”, the user is unable to skip through the images being displayed without skipping through the audio being played back.
- the mode where images and audio are not synchronized is called “Browser Mode”.
- Browser Mode the user can skip through images without skipping through the audio.
- FIG. 75 shows an example setting of the TKI_POB_SRPs for TKI# 1 to TKI# 3 included in the TrackManager.
- the first level in FIG. 75 shows the TrackManager, while the second level shows nine POB files.
- the TrackManager on the first level includes eight TKIs, with the arrows showing which POB files are referred to by the TKI_POB_SRPs in these eight TKIs.
- TKI# 1 includes three TKI_POB_SRPs that specify POB 001 to POB 003
- TKI# 2 includes three TKI_POB_SRPs that specify POB 004 to POB 006
- TKI# 3 includes three TKI_POB_SRPs that specify POB 007 to POB 009 .
- POB 001 to POB 009 are assumed to JPEG image data composed of song lyrics arranged onto a plain background.
- the words composing the lyrics are shown using a suitable font for the mood of the song and can be subject to embellishments, such as the addition of bold outlines.
- the lowest level in FIG. 75 shows the content of each POB.
- the content of POB 001 to POB 003 is the lyrics for TrackA
- the content of POB 004 to POB 006 is the lyrics for TrackB
- the content of POB 007 to POB 009 is the lyrics for TrackC. Since these images will be meaningless unless they are displayed during the playback of the corresponding tracks, the TKI_POB_SRPs included in the TKIs are set so that these images are displayed during such playback.
- the playback period of each track is the same as in FIG. 16 that was referred to in the first embodiment. This means that the playback period of “AOB001.SA1” corresponding to TKI# 1 is 6.1 minutes, the playback period of “AOB002.SA1” corresponding to TKI# 2 is 3.3 minutes, and the playback period of “AOB03.SA1” corresponding to TKI# 3 is 5.5 minutes.
- the TKI_POB_SRPs given in the TKIs will become valid, so that a playback apparatus can display POBs in accordance with these valid TKI_POB_SRPs.
- FIG. 76 shows one example of the setting of the TKI_POB_SRPs in TKI# 4 to TKI# 8 included in the TrackManager.
- the first level shows the TrackManager, while the second level shows ten POB files.
- TKI# 4 includes seven TKI_POB_SRPs that respectively specify POB 010 to POB 016 .
- TKI# 8 includes three TKI_POB_SRPs that specify POB 017 to POB 019 .
- POB 010 to POB 019 like POB 001 to POB 009 , are JPEG image data composed of song lyrics arranged onto a plain background.
- TKI_POB_SRPs are only set for TKI# 4 and not for any of TKI# 5 to TKI# 7 is that when a single track is composed of a plurality of TKIS, only the TKI_POB_SRPs in the first TKI are valid, as stated earlier.
- the content of POB 010 to POB 016 is the lyrics for TrackD that is shown in FIG. 16 of the first embodiment, while the content of POB 017 to POB 019 is the lyrics for TrackE.
- the DPLI_POB SRPs given in the DPLGI specify the POBs that should be displayed during the playback period of a plurality of AOBs in accordance with the order specified by the Default_Playlist_Information.
- FIG. 77 shows the DPLI_POB_SRPs and DPLI_POB_ATRs included in the DPLGI.
- the DPLI_POB_SRPs and DPLI_POB_ATRs included in the DPLGI have the same data constructions as the TKI_POB_SRPs and TKI_POB_ATRs.
- the DPLI_POB_SRPs and DPLI_POB_ATRs given in FIG. 77 can be set to show (1) which POBs should be displayed during the playback period of the plurality of AOB files indicated by the playback order in the Default_Playback_Information, (2) in what order such POBs should be displayed, and (3) whether the display of POBs is to be synchronized with the playback of the AOB corresponding to the TKIs.
- FIG. 78 shows an example setting of twenty DPLI_POB_SRPs included in the Default_Playlist_Information.
- the first level in the drawing shows the Default_Playlist_Information, with the inner frames showing the DPLGI and twenty DPLI_POB_SRPs.
- the second level shows the twenty POB files POB 020 to POB 039 .
- the twenty DPLI_POB_SRPs respectively specify the twenty POB files POB 020 to POB 039 .
- POB 020 is an image used as the jacket image for the packaged version of the music album composed of TrackA to TrackE
- POB 021 is a logo of the production company that produced this music album.
- POB 022 to POB 025 are artist photos
- POB 026 to POB 031 are images taken from a promotional (promo) video
- POB 032 to POB 039 are photos of the artist performing TrackA to TrackE during a concert.
- the DPLI_POB_SRPs in the Default_Playlist_Information are defined by the producer of the music contents, and so can be set so as to have images for the tracks represented by the music contents, artist photos, etc. displayed during playback.
- the POB files specified by the DPLI_POB_SRPs included in the DPLGI will be displayed.
- the Default_Playlist_Information specifies a playback order for the five tracks TrackA to TrackE via the eight TKIs composing these tracks.
- FIG. 79 is a timing chart showing what images are combined when the POBs specified by the DPLI_POB_SRPs included in the Default_Playlist_Information are used as background images and the POBs indicated by the TKI_POB_SRPs included in the TrackManager are used as foreground images.
- the first level in the drawing shows the same POBs as the second level in FIG. 78
- the second level shows the same POBs as the second level in FIGS. 75 and 76
- the scale that extends horizontally across the top of FIG. 79 shows the playback time in units of one minute.
- the horizontal width of each POB in FIG. 79 therefore shows the continuous display time for each POB.
- POB 010 to POB 011 are successively displayed as foreground images while POB 026 to POB 028 (images taken from a promo video) are successively displayed as the background image.
- FIG. 79 a combined image composed of POB 004 (the lyrics to TrackB) in the foreground and POB 022 (an artist photo) in the background will be displayed starting from the point 6.1 minutes after the start of playback according to the Default_Playlist_Information.
- FIG. 80 shows how the foreground image and background image are combined at this point 6.1 minutes after the start of playback according to the Default_Playlist_Information.
- FIG. 81 shows how the foreground image and background image are combined at this point 16 minutes after the start of playback according to the Default_Playlist_Information.
- the lyrics to the track being played back can be displayed with an artist photo, an image from the promo video of the track, a concert photo, or the like.
- the settings of what POB files should be displayed at what time can also be easily changed by rewriting the TKI_POB_SRPs and DPLI_POB_SRPs in the TrackManager and Default_Playlist_Information.
- the PLI_POB_SRPs and PLI_POB_ATR included in a PLGI have the same data constructions as the DFLI_POB_SRPs and DPLI_POB ATR included in the DPLGI, and as the TKI_POB_SRPs and TKI_POB_ATR in a TKI.
- FIG. 82 shows the PLI_POB_SRPs and PLI_POB_ATRs included in a PLGI.
- a PLI differs from the Default_Playlist_Information in that it shows a user-defined playback order, so that the PLI_POB_SRPs and PLI_POB_ATR show which POBs should be displayed during the playback of the plurality of AOB files specified in this user-defined playback order, in what order such POBs should be displayed, and whether display of POBs should be synchronized with the playback of the corresponding AOB files.
- the PLI_POB_SRPs in the Default_Playlist_Information were described as being set by the producer of the music contents, these DPLI_POB_SRPs may be freely set by users. ⁇ 82-2 — 83 ⁇ Example Settings of the PLI_POB_SRPs Included in a PLI
- FIG. 83 shows one example of the settings of twenty PLI_POB_SRPs in a PLI.
- the first level in the drawing shows a PLI, with the inner frames showing the PLGI and twenty PLI_POB_SRPs.
- the second level shows the twenty POB files POB 040 to POB 059 .
- the twenty PLI_POB_SRPs respectively specify the twenty POB files POB 040 to POB 059 .
- While POB 020 to POB 039 are still image data that is provided by the producer of the music contents, POB 040 to POB 059 are still image data for personal photos provided by the user.
- POB 040 is a photo of the user's family
- POB 041 is a photo of the user's graduation ceremony
- POB 042 to POB 051 are photos of the user's pet
- POB 046 to POB 051 are holiday snaps from the user's trip to Europe
- POB 052 to POB 059 are holiday snaps from the user's trip to the USA.
- the total playback period of the AOB files specified by this PLI and the number of POBs specified for display by this PLI are the same as the Default_Playlist_Information.
- This means that the total playback period of TrackA to TrackE specified by this PLI is 52.5 minutes, and that the display period for each of POB 040 to POB 059 will be 2.625 ( 52.5/20) minutes if each image is to be displayed for the same time during this playback period.
- FIG. 84 is a timing chart showing what images are combined when the POBs specified by the PLI_POB_SRPs included in the Playlist_Information described above are used as background images and the POBs indicated by the TKI_POB_SRPs included in the TrackManager are used as foreground images.
- the first level in the drawing shows the same POBs as the second level in FIG. 83
- the second level shows the same POBs as the second level in FIGS. 75 and 76 .
- the scale that extends horizontally across the top of FIG. 84 shows the playback time in units of one minute.
- the horizontal width of each POB in FIG. 84 therefore shows the continuous display time for each POB.
- POB 010 to POB 011 are successively displayed as foreground images while POB 045 , and POB 046 to POB 048 (holiday snaps of European holiday) are successively displayed as the background image.
- the POBs specified by the Default_Playlist_Information are chosen by the record label that produces the music contents and so generally correspond to artist images and images related to the music contents, the POBs specified by a PLI can be freely selected by the user and so can have a high personal value.
- FIG. 85 shows how the foreground image and background image are combined at this point 6.1 minutes after the start of playback according to this Playlist_Information.
- FIG. 86 show show the foreground image and background image are combined at this point 16 minutes after the start of playback according to this Playlist_Information.
- the song lyrics that form part of these combined images are the same as in FIGS. 80 and 81 , though since the background images are different, the combined images in FIGS. 85 and 86 give a completely different impression to those in FIGS. 80 and 81 .
- the PLI_POB_SRPs in a PLI defined by the user himself/herself can specify POB files that differ from those specified by the Default_Playlist_Information, so that the user can have his/her favorite images displayed during the playback of his/her favorite tracks.
- all of the DPLI_POB_SRPs included in the Default_Playlist_Information specify different POB files, though it is possible for two or more DPLI_POB_SRPs in the Default_Playlist_Information to specify the same POB file.
- the same POB file can be displayed during the playback period of a plurality of tracks, making it possible to reduce the number of POB files that need to be provided by the title producer. This reduces the time and cost required to produce a title.
- FIG. 87 shows one example where the number of POB files is reduced by having some of the DFLI_POB_SRPs in the Default_Playlist_Information specify the same POB file.
- both DPLI_POB_SRP# 1 and DFLI_POB_SRP# 4 specify POB 020
- both DFLI_POB_SRP# 2 and DFLI_POB_SRP# 5 specify POB 021 .
- FIG. 88 is a timing chart showing what images are combined when the POBs specified by the DPLI_POB_SRPs included in the Default_Playlist_Information described above are used as background images and the POBs indicated by the TKI_POB_SRPs included in the TrackManager are used as foreground images.
- POB 020 that shows the jacket image of the packaged product is displayed a total of three times that are at the start of playback, 7.875 minutes after the start of playback, and 15.75 minutes after the start of playback.
- POB 021 that shows the logo of the record label is displayed a total of three times that are 2.625 minutes, 10.5 minutes, and 18.375 minutes after the start of playback.
- the DFLI_POB_SRPs are set as shown in FIG. 87 , the same POB is repeatedly displayed, so that reusable images such as the jacket image or record label logo can be repeatedly displayed.
- FIG. 89 shows the composition of the POBMG.
- a POBMG is composed of POB Management Information (POBMGI) and POB Count Information (POBCI) # 1 , # 2 . . . #n.
- POBMGI POB Management Information
- POBCI POB Count Information
- the POB management information includes POBMGI identification information that occupies the 0th and 1st bytes, a reserved field that occupies the 2nd and 3rd fields, a POB_Ns field that occupies the 4th and 5th fields, and a reserved field that occupies the 6th and 7th fields.
- An ID (a character set code “A6” according to ISO646) that identifies the POBMGI is written in the POBMGI identification information field.
- a number of POBs in a range from “0” to “999” is written in the POB_Ns field. This completes the explanation of the POBMGI.
- the POB Count Information is management information that is provided separately for each POB.
- the bit construction of the POB Count Information is as shown by the broken lines in FIG. 89 . That is, the POB Count Information includes a POB_RCN field that occupies the region from bit number b 0 to bit number b 9 , a reserved field that occupies the regions from bit number b 10 to b 13 , and a data existence field that occupies the region from bit number b 14 to bit number b 15 .
- the “POB_RCN” field shows whether the display of a POB corresponding to a POBCI is specified by the DPLGI, a PLGI, or a TKGI.
- the number of specifications that is, the number of TKIs specifying the POB for display, is written as a number in the range “1” to “999”.
- TKIs can be deleted so that the settings in the Default_Playlist_Information and the Playlist_Information can be freely changed by users.
- the POB reference count for that POB has to be decremented in accordance with the number of specifying TKIs that have been deleted.
- the POB_RCN has to be decremented by the number of specifying TKIs that have been deleted.
- the POB_reference_count is set at “0”.
- a POB whose POB_reference_count is “0” is not referred to by a TKI or a playlist, on deleting a TKI or playlist, a playback apparatus can detect POBs whose reference_count_number becomes zero and delete the POB files storing such POBs to reduce the amount of still image data recorded in the flash memory card.
- the reference_count_number may be decremented in the same way.
- the data existence field that occupies bit number b 14 and bit number b 15 is set to indicate whether a POB that corresponds to the present POB number exists.
- the binary value “01” is set in this field when a corresponding POB exists, while the value “00” is set when there is no such POB.
- data is said to “exist” when data with intrinsic value is present.
- the data existence field corresponding to this POB can be set at “1”.
- the data existence field corresponding to POBs that are only of value if they are referred to by a TKI or a playlist at “0”, it becomes possible to selectively keep only POBs with intrinsic value on the flash memory card.
- POBs that are only meaningful when displayed together with the playback of a track i.e., POBs that have no intrinsic value
- the first four cases are the same as in the first embodiment, so that in the first case (case1), a track is deleted. In the second case (case2), a track is deleted and a new track is recorded. In the third case (case3), two out of a plurality of tracks are selected and combined into a single track. In the fourth case (case4), one track is divided to produce two tracks. In the fifth case (case5), the playback order of tracks is changed.
- each TKI corresponding to the track is set at “Unused” and the TKI_POB_SRPs in each TKI are deleted.
- the POB_reference_count in the POBManager of the POBs specified by these TKI_POB_SRPs are decremented.
- POBs that are specified by PLI_POB_SRPs and/or DPLI_POB_SRPs in the DPLGI or a PLGI are unaffected by this deletion.
- TKI_POB_SRPs in the TKIs it is preferable for the TKI_POB_SRPs in the TKIs to also be combined. This is because only the TKI_POB_SRPs in a first TKI are valid for a track composed of a plurality of TKIs.
- the POBs specified by the TKI_POB_SRPs of the latter TKI will need to be specified by TKI_POB_SRPs in the former TKI.
- the data constructions of the TrackManager and PlaylistManager allow the user to freely change the relationship between AOB files and POBs by changing the settings of the TKI_POB_SRPs, DPLI_POB_SRPs, and PLI_POB_SRPs.
- This means that a producer of music contents can provide music contents with differing amounts of still image data to consumers, such as tracks with lyrics, tracks with no lyrics, and tracks with lyrics and background images.
- the producer may charge different amounts for these different types of contents.
- the producer may produce an SD_Audio directory that includes the eight AOBs shown in the first embodiment and a TrackManager where the TKI_POB_SRPs in TKI# 1 to TKI# 8 specify POB 020 to POB 039 as shown in FIG. 78 .
- the producer then compresses this directory, encrypts it, and transmits it to the consumer's personal computer.
- the consumer's personal computer can instead download tracks (AOBs) and still images (POBs) corresponding to the tracks from a server computer operated by the record label and generate the SD-Audio directory shown in FIGS. 70A and 70B on the flash memory card 31 .
- the producer may produce an SD_Audio directory that includes the eight AOBs shown in the first embodiment and a TrackManager where the TKI_POB_SRPs in TKI# 1 to TKI# 8 specify POB 001 to POB 019 shown in FIGS. 75 and 76 corresponding to the lyrics.
- the producer then compresses this directory, encrypts it, and transmits it to the consumer's personal computer.
- the producer may produce an SD_Audio directory that includes the eight AOBs shown in the first embodiment, a TrackManager where the TKI_POB_SRPs in TKI# 1 to TKI# 8 specify POB 001 to POB 019 shown in FIGS. 75 and 76 corresponding to the lyrics, and a Playlist Manager where the DPLI_POB_SRPs specify POB 020 to POB 039 shown in FIG. 78 .
- the producer then compresses this directory, encrypts it, and transmits it to the consumer's personal computer.
- still image data can be freely associated with audio data by setting the TKI_POB_SRPs, DPLI_POB_SRPs, and PLI_POB_SRPs in the present embodiment, music contents can be easily produced with different prices in accordance with the amount of associated still image data.
- the following describes a playback apparatus for the second embodiment.
- This playback apparatus differs from the playback apparatus described in the first embodiment in that while the playback apparatus in the first embodiment is portable, the playback apparatus in the second embodiment is designed for installation as a car stereo.
- FIG. 90 shows how the playback apparatus of the second embodiment is used, while FIG. 91 shows the external appearance of just the playback apparatus.
- the playback apparatus of this second embodiment differs from the playback apparatus of the first embodiment in that it is installed in an automobile as shown in FIG. 90 , in that it includes a large LCD panel 5 , and in that it is connected to car speakers. Due to the provision of the large LCD panel 5 , the playback apparatus of this second embodiment is well suited to the display of the various types of still image data mentioned above.
- a second difference with the playback apparatus of the first embodiment is that the playback apparatus of the second embodiment has a descrambler 7 that is capable of decrypting encrypted POBs as well as encrypted audio data.
- a POB has been encrypted and is stored as a POB file with a “POBXXX.SP1” filename
- a FileKey stored in a Key Entry in the encrypted key storing file “POBSP1.KEY” is set in the descrambler 7 which then decrypts the file “POBXXX.SP1”.
- a third difference with the playback apparatus of the first embodiment is that the playback apparatus of the second embodiment stores a program including the processing required to display POBs as foreground or background images.
- the CPU 10 in this playback apparatus executes this program to display images.
- composition of the playback apparatus shown in FIG. 92 differs from the composition of the playback apparatus of the first embodiment in that it includes a plurality of VRAMs 61 .
- the plurality of VRAMs 61 respectively correspond to the single graphics planes (layers).
- the VRAM for a graphics plan has transparency ⁇ set in the range 0 to 100% for each pixel.
- the image that is to be displayed on the first LCD panel 5 is calculated according to the equation given below.
- the transparency ⁇ is set at 0% for the parts of the foreground image corresponding to the characters showing the lyrics. As a result, parts of the background image that positionally correspond to the character strings showing the lyrics are completely hidden. Conversely, the transparency ⁇ is set at 100% for the parts of the foreground image corresponding to plain background of the lyrics. This means that the combined image has the character strings showing the lyrics in graphics plane 0 displayed on top of the background image in graphics plane 1.
- a combined image where a lyrics sheet is laid on top of a background image, as shown in FIGS. 80 and 81 .
- a combined image can be produced in other ways aside from that shown in FIG. 93A .
- the lyrics may be arranged into the lower part of the screen, with the background image being shown in the upper part, as shown in FIG. 93B .
- FIG. 94 is a flowchart showing the foreground image display procedure.
- step S 402 the CPU 10 judges whether the TKI_POB_SRPs included in the TKGIs in TKI#z specify any POBs.
- the processing advances to step S 403 where the CPU 10 counts the number of POB files that are specified by the TKI_POB_SRPs included in the TKGI.
- step S 404 the CPU 10 calculates the display time “POB_time” showing the display period to be used for each POB file.
- step S 405 refers to the TKI_POB_ATR in the TKGI and determines the display mode to be used for displaying the POB files.
- the processing advances from step S 405 to step S 406 , where the variable i is initialized, and to step S 407 , where the POB file specified by the i th TKI_POB_SRP is displayed for the display time POB_time.
- the POB_file specified by the TKI_POB_SRP is “JPG”
- the POB is displayed as it is.
- the extension of the POB file specified by the TKI_POB_SRP is “SP1”
- the POB file will be in an encrypted state, so that the CPU 10 reads the FileKey corresponding to the POB file from the protected area, decrypts the POB file using the encryption key, and displays the POB.
- step S 408 the CPU 10 judges whether the variable i has reached the value given in POB_Ns. If not, the processing proceeds to step S 409 , where the variable i is incremented, and then returns to step S 407 .
- steps S 406 to S 409 is hereafter repeated until the variable i reaches the value given in POB_Ns.
- the POBs specified by the TKI_POB_SRPs in the TKGI are sequentially displayed.
- the processing in this flowchart ends.
- step S 405 When the TKI_POB_ATR shows random mode, the processing advances from step S 405 to step S 410 , where the variable i is initialized, and to step S 411 , where the CPU 10 generates a random number r in a range from 1 to POB_Ns.
- step S 412 the POB file specified by the r th TKI_POB_SRP corresponding to the random number r is displayed for the display time POB_time determined in step S 404 .
- step S 413 the CPU 10 judges whether the variable i has reached the value given in POB_Ns. If not, the processing proceeds to step S 414 , where the variable i is incremented, and then returns to step S 411 .
- step S 411 the CPU 10 generates another random number r in a range from 1 to POB_Ns, and the processing proceeds again to step S 412 , where the CPU 10 reads the POB file specified by the r th TKI_POB_SRP corresponding to the random number r and displays it for the display time POB_time determined in step S 404 .
- the POB file specified by the TKI_POB_SRP is “JPG”
- the POB is displayed as it is.
- the extension of the POB file specified by the TKI_POB_SRP is “SP1”
- the POB file will be in an encrypted state, so that the CPU 10 reads the FileKey corresponding to the POB file from the protected area, decrypts the POB file using the encryption key, and displays the POB.
- steps S 411 to S 414 is hereafter repeated until the variable i reaches the value given in POB_Ns.
- POBs specified by the TKI_POB_SRPs in the TKGI are displayed one after another in a random order.
- the processing in this flowchart ends.
- step S 405 When the TKI_POB_ATR shows shuffle mode, the processing advances from step S 405 to step S 415 , where the variable i is initialized, and to step S 416 , where the CPU 10 generates a random number r in a range from 1 to POB_Ns.
- step S 418 the CPU 10 checks whether the newly generated random number r matches one of the used POB numbers that has been previously stored. If so, the processing returns to step S 416 where the random number r is regenerated. If not, the processing advances from step S 418 to S 419 where the POB file specified by the r th TKI_POB_SRP corresponding to the random number r is displayed for the display time POB_time determined in step S 404 . After this, in step S 417 the CPU 10 stores the random number r as a used POB number.
- step S 420 the CPU 10 judges whether the variable i has reached the value given in POB_Ns. If not, the processing proceeds to step S 421 , where the variable i is incremented, and then returns to step S 416 . The processing in steps S 416 to S 421 is hereafter repeated until the variable i reaches the value given in POB_Ns. When the variable i reaches the value given in POB_Ns, the processing in this flowchart ends.
- FIG. 95 is a flowchart for the background image display procedure. This flowchart contains fundamentally the same processing as the flowchart in FIG. 94 , with the processing being performed according to the DPLI_POB_SRPs and DPLI_POB_ATR in the DPLGI instead of the TKI_POB_SRPs and TKI_POB_ATRs in the TKGI.
- the CPU 10 When the Default_Playlist_Information is selected, the CPU 10 performs the processing in steps S 502 to S 505 . As in steps S 402 to S 405 , the CPU 10 judges whether the DPLI_POB_SRPs included in the DPLGI specify any POBs. When one or more POB files are specified, the CPU 10 counts the number of POB files that are specified, calculates the display time POB_time showing the display period to be used for each POB file, and then determines the display mode to be used for displaying the POB files.
- step S 506 When the DPLI_POB_ATR shows sequential mode, the CPU 10 performs step S 506 to step S 509 .
- step S 406 to S 409 POB files are sequentially displayed in order in accordance with a DPLI_POB_SRP, out of the DPLI_POB_SRPs included in the DPLGI, indicated by the variable i.
- step S 510 When the DPLI_POB_ATR shows random mode, the CPU 10 performs step S 510 to step S 514 .
- step S 410 to S 414 POB files are displayed in a random order in accordance with a DPLI_POB_SRP, out of the DPLI_POB_SRPs included in the DPLGI, indicated by the random number r.
- step S 515 to step S 521 the CPU 10 performs step S 515 to step S 521 .
- step S 415 to S 421 POB files are displayed in a random order with no repetition in accordance with a DPLI_POB_SRP, out of the DPLI_POB_SRPs included in the DPLGI, indicated by the random number r.
- FIG. 96 is a flowchart showing the background image display procedure based on the PLI_POB_SRPs. With the exception of the processes based on DPLI_POB_SRPs being performed based on PLI_POB_SRPs, this flowchart is exactly the same as the flowchart in FIG. 95 , so that the processes have been given the same reference numerals. No explanation of FIG. 96 will be given.
- FIGS. 97A to 97C show what kind of combined images are displayed on the LCD panel 5 when a foreground image specified by a TKI_POB_SRP and a background image specified by the DPLGI are displayed according to the display procedures shown in the flowcharts in FIGS. 94 and 95 .
- FIGS. 98A to 98C show what kind of combined images are displayed on the LCD panel 5 when a foreground image specified by a TKI_POB_SRP and a background image specified by a PLI_POB_SRP are displayed according to the display procedures shown in the flowcharts in FIGS. 94 and 96 .
- This recording apparatus differs from that of the first embodiment in that it is capable of recording a plurality of POBs onto a flash memory card, of setting values in the TKI_POB_SRPs, DPLI_POB_SRPs, and PLI_POB_SRPs, and setting values in the TKI_POB_ATR, DPLI_POB_ATR, and PLI_POB_ATR.
- the CPU 10 in the recording apparatus of this second embodiment executes the procedure shown in FIG. 99 .
- the following describes the recording procedure executed by the recording apparatus of this second embodiment with reference to the flowchart shown in FIG. 99 .
- step S 601 the CPU 10 initializes the various variables used in this procedure. These are the variables #x, #y, #z, #u, #vy, and #w. Of these, the variable #x is used to specify which POB is presently being processed, the variable #y is used to specify which track sequence (PLI) is presently being processed, and the variable #z is used to specify which track (TKI) is presently being processed.
- the variable #u specifies which of the DPLI_POB_SRPs is being processed, while the variable #vy specifies which of the PLI_POB_SRPs in the PLI (PLI#y) specified by the variable #y is being processed.
- the variable #w specifies which TKI_POB_SRPs in the TKI (TKI#z) specified by the variable #z is presently being processed.
- step S 602 the CPU 10 advances to step S 602 where it displays POB#x. This allows the user to visually confirm the photo, illustration, or lyric sheet in this POB.
- step S 603 the CPU 10 asks the user to indicate whether the still image data in POB#x is to be displayed throughout the entire track sequence or just during the playback period of a specific track, and then receives a user selection.
- step S 604 the CPU 10 waits for the user to indicate the track sequence for which POB#x should be displayed.
- the processing proceeds to step S 605 when the CPU 10 judges whether the indicated track sequence #y is the DPLI or a PLI.
- the processing proceeds to S 606 where POB#x is set in the DPLI_POB_SRP#u, and then to S 607 where the DPLI_POB_ATR#u of the DPLI is set based on this POB#x.
- the CPU 10 increments the variable #u (#u ⁇ #u+1) in step S 608 and the variable #x (#x ⁇ #x+1) in step S 609 .
- step S 605 When a PLI is selected in step S 605 , the processing proceeds to step S 610 where POB#x is set in the PLI_POB_SRP#vy in PLI#y, and to step S 611 where the PLI_POB_ATR#vy for this PLI is set based on POB#x. After this, in step S 612 the CPU 10 increments the variable #vy (#vy ⁇ #vy+1), before advancing to step S 609 to increment the variable #x (#x ⁇ #x+1).
- step S 603 When, in step S 603 , the user judges that POB#x should be assigned to a specific track, the processing advances to step S 613 where the CPU 10 receives a user indication of this specific track.
- step S 614 the CPU 10 sets POB#x in a TKI_POB_SRP#w set for the TKI#z of the indicated track (track#z).
- step S 615 the CPU 10 sets the TKI_POB_ATR#w of TKI#z based on the POB#x
- step S 616 the CPU 10 increments the variable #w (#w ⁇ #w+1)
- step S 617 the CPU 10 determines whether the variable #x has reached the final number #n in a POB. If not, the processing proceeds to step S 609 where the CPU 10 increments the variable #x. If the variable #x has reached the final number #n in a POB, the processing proceeds to step S 618 where POB# 1 to POB#n, the TKMG including the TKIs, and the PLMG including the DPLI and PLIs are recorded on the semiconductor memory card to end the processing.
- Still image data such as a lyrics sheet, that is to be displayed with a background image only during the playback of a particular track can be specified by a TKI_POB_SRP in the TKI of the track.
- the present embodiments describe the case where the presentation data and navigation data are used for music contents, although it should be obvious that such data can be used for an audiobook that is a recording of an actor or announcer reading from a book.
- still image data that shows text from the book can be ideally specified by the TKI_POB_SRPs as the foreground images while the illustrations from the book are specified by the DPLI_POB_SRPs or PLI_POB_SRPs.
- the POBs specified by DPLI_POB_SRPs and PLI_POB_SRPs are used as background images while the POBs specified by TKI_POB_SRPs are used as foreground images, though the opposite setup may be used.
- a POB specified by a DPLI_POB_SRP or PLI_POB_SRP may be displayed first, and a POB specified by a TKI_POB_SRP may be displayed next.
- this third embodiment describes the case where a phrase timing table and a highlight coordinate table are also stored on the flash memory card 31 so that the display of lyrics can be properly synchronized to the playback of a song.
- the phrase timing table associates the TKI_POB_SRPs specifying the POBs showing each section of the lyrics with information showing at what time the corresponding phrase begins and ends in a song.
- FIG. 100A shows one example of the phrase timing table.
- phrase timing refers to the period during which a phrase given in the lyrics of a track is being sung as part of the playback of the AOB. This period is expressed to an accuracy of milliseconds.
- a playback apparatus monitors the phrase timing given in this table that corresponds to the current value of the playback time code.
- the playback apparatus can know which POB stores the lyrics for the AOB, AOB_ELEMENT, and AOB_FRAME currently being played back.
- Using a table that gives the phrase timing of a POB in milliseconds in this way allows the playback apparatus to synchronize the playback of AOBs and the display of lyrics to millisecond accuracy.
- the playback apparatus can find which AOB_FRAME in which AOB_ELEMENT in which AOB corresponds to the indicated playback start time using Equations 1 to 3 given in the first embodiment.
- the playback apparatus also judges which phrase timing includes the indicated playback start time and has the POB corresponding to this phrase timing displayed. This means that when the user has playback start from a desired position indicated using the jog dial, the appropriate POB for this desired position can also be displayed.
- phrase timing table the AOB number, AOB_ELEMENT number and AOB_FRAME number of the AOB, AOB_ELEMENT, and AOB_FRAME to which a phrase should be synchronized may be given in the phrase timing table instead.
- the highlight coordinate table associates the display coordinates of characters used in the lyrics and the timing at which the AOB_ELEMENT and AOB_FRAMEs corresponding to these characters will be played back.
- FIG. 100B shows one example of the highlight coordinate table. Preparing this kind of highlight coordinate table enables a playback apparatus to display the characters corresponding to the lyrics, out of the lyrics displayed according to the phrase timing, in the AOB_ELEMENT and AOB_FRAME currently being played back in a different color.
- the highlight coordinate table will include display coordinates for the characters “H”, “e”, “y”, “h”, “e”, “y”, . . . that are associated with the playback period of the AOB_ELEMENT and AOB_FRAME corresponding to these characters.
- the playback apparatus changes the color of the position shown by the display coordinates of the characters given in the highlight coordinate table.
- the playback apparatus can therefore display the lyrics in a manner that allows the user to instantly recognize what part of the AOB is currently being played back. This means that music recorded on a flash memory card can be played back with highlighted lyrics in the same way as conventional karaoke tracks.
- the phrase timing table and highlight coordinate table are provided to enable precise synchronization between audio playback and the displayed lyrics, in the same way as conventional karaoke tracks.
Abstract
Description
-
- {x1-x2_x3-x4}
Cluster u=(Total of the TMSRT_entries from
Offset v=(Total of the TMSRT_entries from
Jmp_Entry(sec)=(FNs—1st_TMSRTE+FNs_middle_TMSRTE*y+x)*
Jmp_Entry(in seconds)=
Playback period from
Total Playback Period from
[“FNs—1st_TMSRTE”(#1)+“FNs_Middle_TMSRTE”(#1)*(Number of TMSRT_entries(#1)−2)+“FNs_Last_TMSRTE”(#1)+
“FNs—1st_TMSRTE”(#2)+(“FNs_Middle_TMSRTE”(#2)*Number of TMSRT_entries(#2)−2)+“FNs_Last_TMSRTE”(#2)+
“FNs—1st_TMSRTE”(#3)+(“FNs_Middle_TMSRTE”(#3)*Number of TMSRT_entries(#3)−2)+“FNs_Last_TMSRTE”(#3) . . .
+“FNs—1st_TMSRTE”(#n)+(“FNs_Middle_TMSRTE”(#n)*Number of TMSRT_entries(#n)−2)+“FNs_Last_TMSRTE”(#n)]*20msec
-
- a “Playlist” key that receives the selection of a playlist or a track;
- a “|<<” key that receives a skip operation that moves the playback position to a start of the current track;
- a “>>|” key that receives a skip operation that moves the playback position to a start of the next track;
- a “<<” key and a “>>” key that respectively receive a backward search operation and a forward search operation to enable the user to have the playback move quickly through the current track;
- a “Display” key that receives an operation to have still images stored on the
flash memory card 31 displayed; - a “Rec” key that receives a recording operation;
- an “Audio” key for receiving user selections of the sampling frequency or user selection of whether stereo or monaural is to be used;
- a “Mark” key that receives user indications that mark positions in tracks; and
- an “Edit” key that receives user indications for the editing of tracks or for the input of track titles.
{48-2} Improvements made in this Portable Playback Apparatus for theFlash Memory Card 31
-
- (1) A list of playlist and tracks is shown on the LCD panel to allow the user to indicate the Default_Playlist_Information, a PLI, or separate tracks.
- (2) Keys on the key panel are assigned to the playlists and/or tracks displayed on the LCD panel to allow the user to select a track or playlist that is to be played back or edited.
- (3) A time code showing a position in a track is displayed on the
LCD panel 5 when a track is played back. - (4) A jog dial is provided to enable the user to set a time code for use as a playback start time when using the time search function or as a division boundary when dividing a track.
{48-2—49—50} Improvement (2)
{82-2—83} Example Settings of the PLI_POB_SRPs Included in a PLI
Pixel Value of Each Pixel=Pixel Value in
(c) In this second embodiment, the POBs specified by DPLI_POB_SRPs and PLI_POB_SRPs are used as background images while the POBs specified by TKI_POB_SRPs are used as foreground images, though the opposite setup may be used. Alternatively, when different POBs are simultaneously specified by a DPLI_POB_SRP or PLI_POB_SRP and a TKI_POB_SRP, only one of such POBs may be displayed. As another alternative, no distinction into “background image” and “foreground image” need be used. As one example, a POB specified by a DPLI_POB_SRP or PLI_POB_SRP may be displayed first, and a POB specified by a TKI_POB_SRP may be displayed next.
Claims (2)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/271,125 US8175441B2 (en) | 1999-05-28 | 2008-11-14 | Playback program |
Applications Claiming Priority (10)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP14989399 | 1999-05-28 | ||
JP11-149893 | 1999-05-28 | ||
JP11-236724 | 1999-08-24 | ||
JP23672499 | 1999-08-24 | ||
JP37260499 | 1999-12-28 | ||
JP11-372604 | 1999-12-28 | ||
US09/580,581 US6647496B1 (en) | 1999-05-28 | 2000-05-26 | Semiconductor memory card |
US10/446,655 US6779116B2 (en) | 1999-05-28 | 2003-05-29 | Playback apparatus and playback method |
US10/832,434 US7471878B2 (en) | 1999-05-28 | 2004-04-27 | Playback program |
US12/271,125 US8175441B2 (en) | 1999-05-28 | 2008-11-14 | Playback program |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/832,434 Division US7471878B2 (en) | 1999-05-28 | 2004-04-27 | Playback program |
Publications (2)
Publication Number | Publication Date |
---|---|
US20090105859A1 US20090105859A1 (en) | 2009-04-23 |
US8175441B2 true US8175441B2 (en) | 2012-05-08 |
Family
ID=27319841
Family Applications (4)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/580,581 Expired - Lifetime US6647496B1 (en) | 1999-05-28 | 2000-05-26 | Semiconductor memory card |
US10/446,655 Expired - Lifetime US6779116B2 (en) | 1999-05-28 | 2003-05-29 | Playback apparatus and playback method |
US10/832,434 Expired - Fee Related US7471878B2 (en) | 1999-05-28 | 2004-04-27 | Playback program |
US12/271,125 Expired - Fee Related US8175441B2 (en) | 1999-05-28 | 2008-11-14 | Playback program |
Family Applications Before (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/580,581 Expired - Lifetime US6647496B1 (en) | 1999-05-28 | 2000-05-26 | Semiconductor memory card |
US10/446,655 Expired - Lifetime US6779116B2 (en) | 1999-05-28 | 2003-05-29 | Playback apparatus and playback method |
US10/832,434 Expired - Fee Related US7471878B2 (en) | 1999-05-28 | 2004-04-27 | Playback program |
Country Status (8)
Country | Link |
---|---|
US (4) | US6647496B1 (en) |
EP (1) | EP1056094B1 (en) |
CN (1) | CN1196130C (en) |
BR (2) | BR0006168A (en) |
CA (1) | CA2338725C (en) |
DE (1) | DE60035827T2 (en) |
MY (1) | MY130770A (en) |
WO (1) | WO2000074061A1 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9182940B1 (en) * | 2013-12-10 | 2015-11-10 | Amazon Technologies, Inc. | Systems and methods for determining playback locations in media files |
Families Citing this family (160)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8352400B2 (en) | 1991-12-23 | 2013-01-08 | Hoffberg Steven M | Adaptive pattern recognition based controller apparatus and method and human-factored interface therefore |
US8574074B2 (en) | 2005-09-30 | 2013-11-05 | Sony Computer Entertainment America Llc | Advertising impression determination |
US7966078B2 (en) | 1999-02-01 | 2011-06-21 | Steven Hoffberg | Network media appliance system and method |
JP3389186B2 (en) * | 1999-04-27 | 2003-03-24 | 松下電器産業株式会社 | Semiconductor memory card and reading device |
CN1187756C (en) * | 1999-05-28 | 2005-02-02 | 松下电器产业株式会社 | Semiconductor memory card, playback appts. recording appts. playback method, recording method, and computer-readable recording medium |
CA2338695C (en) * | 1999-05-28 | 2009-07-07 | Matsushita Electric Industrial Co., Ltd. | Semiconductor memory card, playback apparatus, recording apparatus, playback method, recording method, and computer-readable recording medium |
JP2001155466A (en) * | 1999-11-24 | 2001-06-08 | Toshiba Corp | System for recording voice information having picture |
US8645137B2 (en) | 2000-03-16 | 2014-02-04 | Apple Inc. | Fast, language-independent method for user authentication by voice |
US7245719B2 (en) * | 2000-06-30 | 2007-07-17 | Matsushita Electric Industrial Co., Ltd. | Recording method and apparatus, optical disk, and computer-readable storage medium |
US6901396B1 (en) * | 2000-09-27 | 2005-05-31 | Intel Corporation | Packed radix search tree implementation |
US8751310B2 (en) | 2005-09-30 | 2014-06-10 | Sony Computer Entertainment America Llc | Monitoring advertisement impressions |
JP2003006992A (en) * | 2001-06-26 | 2003-01-10 | Pioneer Electronic Corp | Information reproducing method and information reproducing device |
WO2003034227A2 (en) * | 2001-10-12 | 2003-04-24 | Koninklijke Philips Electronics N.V. | Apparatus and method for reading or writing user data |
WO2003044712A1 (en) * | 2001-10-18 | 2003-05-30 | 360 Degree Web, Inc. | Smart card enabled secure computing environment system |
AU2002350120A1 (en) * | 2001-11-01 | 2003-05-12 | Mattel, Inc. | Digital audio device |
US7174017B2 (en) * | 2002-03-04 | 2007-02-06 | Lenovo Singapore Pte, Ltd | Decryption system for encrypted audio |
CN1204489C (en) * | 2002-04-03 | 2005-06-01 | 英华达(南京)科技有限公司 | Electronic installation and method for synchronous play of associated voices and words |
GB2388242A (en) * | 2002-04-30 | 2003-11-05 | Hewlett Packard Co | Associating audio data and image data |
KR20030087193A (en) | 2002-05-07 | 2003-11-14 | 엘지전자 주식회사 | Method for managing a multi-channel broadcast stream record |
JP2003337596A (en) * | 2002-05-20 | 2003-11-28 | Teac Corp | Method and device for processing audio data |
CN1656562B (en) * | 2002-05-24 | 2010-05-12 | 松下电器产业株式会社 | Information recording medium, recorder, recording method, editing device and method, and reproducing device and method |
CA2486671C (en) * | 2002-05-31 | 2011-11-15 | Onkyo Corporation | Network type content reproducing system |
MXPA04002365A (en) | 2002-06-21 | 2004-11-22 | Lg Electronics Inc | Recording medium having data structure for managing reproduction of video data recorded thereon. |
JP4299779B2 (en) | 2002-06-21 | 2009-07-22 | エルジー エレクトロニクス インコーポレーテッド | Recording medium having data structure for managing reproduction of video data |
KR20040000290A (en) | 2002-06-24 | 2004-01-03 | 엘지전자 주식회사 | Method for managing multi-path data stream of high density optical disc |
CN101350215B (en) | 2002-06-24 | 2012-08-29 | Lg电子株式会社 | Method and device for recording and reproducing data structure of reproduction for video data |
WO2004001752A1 (en) | 2002-06-24 | 2003-12-31 | Lg Electronics Inc. | Recording medium having data structure for managing reproduction of multiple title video data recorded thereon and recording and reproducing methods and apparatuses |
US20040001704A1 (en) * | 2002-06-27 | 2004-01-01 | Chan Ming Hong | Slide show with audio |
EP1550121A4 (en) | 2002-09-05 | 2009-06-03 | Lg Electronics Inc | Recording medium having data structure of playlist marks for managing reproduction of still images recorded thereon and recording and reproducing methods and apparatuses |
CN100495558C (en) | 2002-09-06 | 2009-06-03 | Lg电子株式会社 | Methdo and device for recording and reproducing data structure for managing still images |
RU2355048C2 (en) | 2002-09-07 | 2009-05-10 | Эл Джи Электроникс Инк. | Carrier of recordings with data structure for controlling of reproduction of static images from clip file recorded in it and method and writer-reader system |
RU2347284C2 (en) | 2002-10-14 | 2009-02-20 | Эл Джи Электроникс Инк. | Carrier of record with structure of data for guidance of reproduction of set of audio streams written down on it and methods and record and reproduction devices |
JP4903998B2 (en) | 2002-10-15 | 2012-03-28 | エルジー エレクトロニクス インコーポレイティド | RECORDING MEDIUM HAVING DATA STRUCTURE FOR MANAGING REPRODUCTION OF RECORDED MULTIPLE GRAPHIC STREAMS, RECORDING AND REPRODUCING METHOD AND APPARATUS THEREFOR |
CA2474231C (en) | 2002-11-20 | 2012-10-23 | Lg Electronics Inc. | Recording medium having data structure for managing reproduction of data recorded thereon and recording and reproducing methods and apparatuses |
US20040102860A1 (en) * | 2002-11-27 | 2004-05-27 | Invectec Appliances Corp. | Device of playing songs and displaying lyrics thereof and method therefor |
CN1726546B (en) * | 2002-12-17 | 2012-01-18 | 皇家飞利浦电子股份有限公司 | Mobile device that uses removable medium for playback of content |
EP1595253A4 (en) | 2003-01-20 | 2009-09-30 | Lg Electronics Inc | Recording medium having data structure for managing reproduction of still pictures recorded thereon and recording and reproducing methods and apparatuses |
US8145033B2 (en) | 2003-02-05 | 2012-03-27 | Lg Electronics Inc. | Recording medium having data structure for managing reproducton duration of still pictures recorded thereon and recording and reproducing methods and apparatuses |
US7734154B2 (en) | 2003-02-14 | 2010-06-08 | Lg Electronics Inc. | Recording medium having data structure for managing reproduction duration of still pictures recorded thereon and recording and reproducing methods and apparatuses |
US7606463B2 (en) | 2003-02-24 | 2009-10-20 | Lg Electronics, Inc. | Recording medium having data structure for managing playback control and recording and reproducing methods and apparatuses |
US7693394B2 (en) * | 2003-02-26 | 2010-04-06 | Lg Electronics Inc. | Recording medium having data structure for managing reproduction of data streams recorded thereon and recording and reproducing methods and apparatuses |
US7809775B2 (en) | 2003-02-27 | 2010-10-05 | Lg Electronics, Inc. | Recording medium having data structure for managing playback control recorded thereon and recording and reproducing methods and apparatuses |
CN100397882C (en) | 2003-02-28 | 2008-06-25 | Lg电子株式会社 | Recording medium having data structure for managing random/shuffle reproduction of video data recorded thereon and recording and reproducing methods and apparatuses |
US7620301B2 (en) | 2003-04-04 | 2009-11-17 | Lg Electronics Inc. | System and method for resuming playback |
US20060156355A1 (en) * | 2003-06-11 | 2006-07-13 | Masahiro Kawasaki | Reproduction apparatus, program, integrated circuit |
US7743329B2 (en) * | 2003-06-27 | 2010-06-22 | Microsoft Corporation | Incorporating interactive media into a playlist |
CN100380367C (en) * | 2003-09-28 | 2008-04-09 | 诺基亚公司 | Electronic appliance having music database and method of forming such music database |
JP2005128596A (en) * | 2003-10-21 | 2005-05-19 | Sony Corp | Information processor and method, recording medium, program, and content related data |
FI20035235A0 (en) * | 2003-12-12 | 2003-12-12 | Nokia Corp | Arrangement for processing files at a terminal |
JP2005197913A (en) * | 2004-01-06 | 2005-07-21 | Canon Inc | Apparatus and method for image processing |
EP1596396A1 (en) * | 2004-05-15 | 2005-11-16 | Deutsche Thomson-Brandt Gmbh | Method for splitting a data stream |
JP2006023957A (en) * | 2004-07-07 | 2006-01-26 | Sony Corp | Semiconductor integrated circuit and information processor |
US8763157B2 (en) | 2004-08-23 | 2014-06-24 | Sony Computer Entertainment America Llc | Statutory license restricted digital media playback on portable devices |
US8745132B2 (en) | 2004-09-10 | 2014-06-03 | Silver State Intellectual Technologies, Inc. | System and method for audio and video portable publishing system |
PL1851943T3 (en) | 2005-02-02 | 2018-07-31 | Audiobrax Indústria E Comércio De Produtos Eletrônicos S.A. | Mobile communication device with music instrumental functions |
US7818350B2 (en) | 2005-02-28 | 2010-10-19 | Yahoo! Inc. | System and method for creating a collaborative playlist |
WO2006098693A1 (en) * | 2005-03-18 | 2006-09-21 | Tonium Ab | Hand-held computing device with built-in disc-jockey functionality |
US8108693B2 (en) * | 2005-04-01 | 2012-01-31 | Ged-I Ltd. | Method for data storage protection and encryption |
US20060235551A1 (en) * | 2005-04-13 | 2006-10-19 | Creative Technology Ltd. | Data storage device with audio capability |
US7634494B2 (en) * | 2005-05-03 | 2009-12-15 | Intel Corporation | Flash memory directory virtualization |
JP2006318585A (en) * | 2005-05-13 | 2006-11-24 | Sony Corp | Electronic apparatus, data processing method and program |
JP3974624B2 (en) * | 2005-05-27 | 2007-09-12 | 松下電器産業株式会社 | Display device |
JP2007011786A (en) * | 2005-06-30 | 2007-01-18 | Toshiba Corp | Cooling device and electronic device |
US7571015B2 (en) * | 2005-07-14 | 2009-08-04 | Perception Digital Limited | Personal audio player |
KR20070010589A (en) * | 2005-07-19 | 2007-01-24 | 엘지전자 주식회사 | Mobile communication terminal with turn-table and its operating method |
US8677377B2 (en) | 2005-09-08 | 2014-03-18 | Apple Inc. | Method and apparatus for building an intelligent automated assistant |
US8626584B2 (en) | 2005-09-30 | 2014-01-07 | Sony Computer Entertainment America Llc | Population of an advertisement reference list |
US11004089B2 (en) | 2005-10-25 | 2021-05-11 | Sony Interactive Entertainment LLC | Associating media content files with advertisements |
US20070118425A1 (en) | 2005-10-25 | 2007-05-24 | Podbridge, Inc. | User device agent for asynchronous advertising in time and space shifted media network |
US8676900B2 (en) | 2005-10-25 | 2014-03-18 | Sony Computer Entertainment America Llc | Asynchronous advertising placement based on metadata |
US10657538B2 (en) | 2005-10-25 | 2020-05-19 | Sony Interactive Entertainment LLC | Resolution of advertising rules |
EP1953671A4 (en) * | 2005-10-31 | 2010-12-29 | Panasonic Corp | Content data structure and memory card |
US20070162839A1 (en) * | 2006-01-09 | 2007-07-12 | John Danty | Syndicated audio authoring |
JP4234724B2 (en) * | 2006-03-13 | 2009-03-04 | 株式会社東芝 | Content recording apparatus, content recording method, and content recording program |
CN101436414B (en) * | 2006-04-28 | 2011-03-23 | 夏普株式会社 | Recording parameter setting device, method and program thereof, computer-readable recording medium containing the program, information recording medium, recording/reproducing device |
JP5313882B2 (en) | 2006-05-05 | 2013-10-09 | ソニー コンピュータ エンタテインメント アメリカ リミテッド ライアビリテイ カンパニー | Device for displaying main content and auxiliary content |
JP4513780B2 (en) * | 2006-05-10 | 2010-07-28 | ソニー株式会社 | Information processing apparatus, information processing method, and computer program |
US20070298840A1 (en) * | 2006-06-02 | 2007-12-27 | Findaway World, Inc. | Personal media player apparatus and method |
US8180738B2 (en) * | 2006-06-15 | 2012-05-15 | Panasonic Corporation | Memory controller, nonvolatile storage device, and nonvolatile storage device system |
US20080066192A1 (en) * | 2006-09-07 | 2008-03-13 | International Business Machines Corporation | Keyless copy of encrypted data |
US9318108B2 (en) | 2010-01-18 | 2016-04-19 | Apple Inc. | Intelligent automated assistant |
WO2008038290A2 (en) * | 2006-09-28 | 2008-04-03 | Musicpump Ltd. | A digital media player circuit device and method |
US8392726B2 (en) * | 2006-12-20 | 2013-03-05 | Stmicroelectronics S.A. | Protection of memory areas |
US8256005B2 (en) | 2007-01-08 | 2012-08-28 | Apple Inc. | Protection of audio or video data in a playback device |
KR100835210B1 (en) * | 2007-03-12 | 2008-06-05 | 삼성전자주식회사 | Display method of file and apparatus for portable device using the same |
US8656506B2 (en) * | 2007-06-28 | 2014-02-18 | Microsoft Corporation | Rights enforcement of unencrypted content |
US20090089420A1 (en) * | 2007-10-01 | 2009-04-02 | Michael Caruso | Flash tracking system and method |
US8769558B2 (en) | 2008-02-12 | 2014-07-01 | Sony Computer Entertainment America Llc | Discovery and analytics for episodic downloaded media |
US20090251607A1 (en) * | 2008-04-03 | 2009-10-08 | Slideshow Technologies, Inc. | Displaying presentations |
US8996376B2 (en) * | 2008-04-05 | 2015-03-31 | Apple Inc. | Intelligent text-to-speech conversion |
JP4539750B2 (en) * | 2008-04-08 | 2010-09-08 | ソニー株式会社 | recoding media |
US8005856B2 (en) * | 2008-06-25 | 2011-08-23 | Microsoft Corporation | Dynamic selection of media for playback |
US8143508B2 (en) * | 2008-08-29 | 2012-03-27 | At&T Intellectual Property I, L.P. | System for providing lyrics with streaming music |
JP2010087872A (en) * | 2008-09-30 | 2010-04-15 | Toshiba Corp | Playback control apparatus and playback control method |
JP5104709B2 (en) | 2008-10-10 | 2012-12-19 | ソニー株式会社 | Information processing apparatus, program, and information processing method |
US20100146496A1 (en) * | 2008-12-02 | 2010-06-10 | Slideshow Technologies, Llc | Displaying Presentations |
US10241644B2 (en) | 2011-06-03 | 2019-03-26 | Apple Inc. | Actionable reminder entries |
US10241752B2 (en) | 2011-09-30 | 2019-03-26 | Apple Inc. | Interface for a virtual digital assistant |
US9431006B2 (en) | 2009-07-02 | 2016-08-30 | Apple Inc. | Methods and apparatuses for automatic speech recognition |
US8763090B2 (en) | 2009-08-11 | 2014-06-24 | Sony Computer Entertainment America Llc | Management of ancillary content delivery and presentation |
US8682667B2 (en) | 2010-02-25 | 2014-03-25 | Apple Inc. | User profiling for selecting user specific voice input processing information |
US9323438B2 (en) | 2010-07-15 | 2016-04-26 | Apple Inc. | Media-editing application with live dragging and live editing capabilities |
US8775480B2 (en) * | 2011-01-28 | 2014-07-08 | Apple Inc. | Media clip management |
US9997196B2 (en) | 2011-02-16 | 2018-06-12 | Apple Inc. | Retiming media presentations |
US11747972B2 (en) | 2011-02-16 | 2023-09-05 | Apple Inc. | Media-editing application with novel editing tools |
US9262612B2 (en) | 2011-03-21 | 2016-02-16 | Apple Inc. | Device access using voice authentication |
JP2012252240A (en) * | 2011-06-06 | 2012-12-20 | Sony Corp | Replay apparatus, signal processing apparatus, and signal processing method |
JP6077007B2 (en) * | 2012-01-09 | 2017-02-08 | トムソン ライセンシングThomson Licensing | Create and manage sub-recordings |
US9280610B2 (en) | 2012-05-14 | 2016-03-08 | Apple Inc. | Crowd sourcing information to fulfill user requests |
US9721563B2 (en) | 2012-06-08 | 2017-08-01 | Apple Inc. | Name recognition system |
US9547647B2 (en) | 2012-09-19 | 2017-01-17 | Apple Inc. | Voice-based media searching |
US20140142955A1 (en) * | 2012-11-19 | 2014-05-22 | Apple Inc. | Encoding Digital Media for Fast Start on Digital Media Players |
WO2014197334A2 (en) | 2013-06-07 | 2014-12-11 | Apple Inc. | System and method for user-specified pronunciation of words for speech synthesis and recognition |
WO2014197336A1 (en) | 2013-06-07 | 2014-12-11 | Apple Inc. | System and method for detecting errors in interactions with a voice-based digital assistant |
US9582608B2 (en) | 2013-06-07 | 2017-02-28 | Apple Inc. | Unified ranking with entropy-weighted information for phrase-based semantic auto-completion |
WO2014197335A1 (en) | 2013-06-08 | 2014-12-11 | Apple Inc. | Interpreting and acting upon commands that involve sharing information with remote devices |
CN110442699A (en) | 2013-06-09 | 2019-11-12 | 苹果公司 | Operate method, computer-readable medium, electronic equipment and the system of digital assistants |
US10176167B2 (en) | 2013-06-09 | 2019-01-08 | Apple Inc. | System and method for inferring user intent from speech inputs |
US20150003812A1 (en) * | 2013-06-27 | 2015-01-01 | Little Engines Group, Inc. | Method for collaborative creation of shareable secondary digital media programs |
US9430463B2 (en) | 2014-05-30 | 2016-08-30 | Apple Inc. | Exemplar-based natural language processing |
US9338493B2 (en) | 2014-06-30 | 2016-05-10 | Apple Inc. | Intelligent automated assistant for TV user interactions |
US9668121B2 (en) | 2014-09-30 | 2017-05-30 | Apple Inc. | Social reminders |
US10567477B2 (en) | 2015-03-08 | 2020-02-18 | Apple Inc. | Virtual assistant continuity |
US9578173B2 (en) | 2015-06-05 | 2017-02-21 | Apple Inc. | Virtual assistant aided communication with 3rd party service in a communication session |
US10671428B2 (en) | 2015-09-08 | 2020-06-02 | Apple Inc. | Distributed personal assistant |
US10747498B2 (en) | 2015-09-08 | 2020-08-18 | Apple Inc. | Zero latency digital assistant |
US9697820B2 (en) | 2015-09-24 | 2017-07-04 | Apple Inc. | Unit-selection text-to-speech synthesis using concatenation-sensitive neural networks |
US11010550B2 (en) | 2015-09-29 | 2021-05-18 | Apple Inc. | Unified language modeling framework for word prediction, auto-completion and auto-correction |
US10366158B2 (en) | 2015-09-29 | 2019-07-30 | Apple Inc. | Efficient word encoding for recurrent neural network language models |
US11587559B2 (en) | 2015-09-30 | 2023-02-21 | Apple Inc. | Intelligent device identification |
US10691473B2 (en) | 2015-11-06 | 2020-06-23 | Apple Inc. | Intelligent automated assistant in a messaging environment |
CN106815230B (en) * | 2015-11-27 | 2019-05-14 | 腾讯科技(深圳)有限公司 | Lyrics page generation method and device |
US10049668B2 (en) | 2015-12-02 | 2018-08-14 | Apple Inc. | Applying neural network language models to weighted finite state transducers for automatic speech recognition |
US10223066B2 (en) | 2015-12-23 | 2019-03-05 | Apple Inc. | Proactive assistance based on dialog communication between devices |
US10446143B2 (en) | 2016-03-14 | 2019-10-15 | Apple Inc. | Identification of voice inputs providing credentials |
RU2657168C2 (en) * | 2016-04-29 | 2018-06-08 | Общество с ограниченной ответственностью "Общество Сферического Кино" | Software and hardware complex for automatic calibration of multiprojector systems with possibility to play content in high-permission using encryption facilities and digital distribution, method of content encryption for use in the method of content reproducing |
US9934775B2 (en) | 2016-05-26 | 2018-04-03 | Apple Inc. | Unit-selection text-to-speech synthesis based on predicted concatenation parameters |
US9972304B2 (en) | 2016-06-03 | 2018-05-15 | Apple Inc. | Privacy preserving distributed evaluation framework for embedded personalized systems |
US10249300B2 (en) | 2016-06-06 | 2019-04-02 | Apple Inc. | Intelligent list reading |
US10049663B2 (en) | 2016-06-08 | 2018-08-14 | Apple, Inc. | Intelligent automated assistant for media exploration |
DK179309B1 (en) | 2016-06-09 | 2018-04-23 | Apple Inc | Intelligent automated assistant in a home environment |
US10490187B2 (en) | 2016-06-10 | 2019-11-26 | Apple Inc. | Digital assistant providing automated status report |
US10586535B2 (en) | 2016-06-10 | 2020-03-10 | Apple Inc. | Intelligent digital assistant in a multi-tasking environment |
US10067938B2 (en) | 2016-06-10 | 2018-09-04 | Apple Inc. | Multilingual word prediction |
US10509862B2 (en) | 2016-06-10 | 2019-12-17 | Apple Inc. | Dynamic phrase expansion of language input |
US10192552B2 (en) | 2016-06-10 | 2019-01-29 | Apple Inc. | Digital assistant providing whispered speech |
DK179343B1 (en) | 2016-06-11 | 2018-05-14 | Apple Inc | Intelligent task discovery |
DK179049B1 (en) | 2016-06-11 | 2017-09-18 | Apple Inc | Data driven natural language event detection and classification |
DK201670540A1 (en) | 2016-06-11 | 2018-01-08 | Apple Inc | Application integration with a digital assistant |
DK179415B1 (en) | 2016-06-11 | 2018-06-14 | Apple Inc | Intelligent device arbitration and control |
US10043516B2 (en) | 2016-09-23 | 2018-08-07 | Apple Inc. | Intelligent automated assistant |
US10593346B2 (en) | 2016-12-22 | 2020-03-17 | Apple Inc. | Rank-reduced token representation for automatic speech recognition |
JP6978028B2 (en) * | 2017-02-07 | 2021-12-08 | 株式会社Cotodama | Display control system, display control method, and program |
DK201770439A1 (en) | 2017-05-11 | 2018-12-13 | Apple Inc. | Offline personal assistant |
DK179496B1 (en) | 2017-05-12 | 2019-01-15 | Apple Inc. | USER-SPECIFIC Acoustic Models |
DK179745B1 (en) | 2017-05-12 | 2019-05-01 | Apple Inc. | SYNCHRONIZATION AND TASK DELEGATION OF A DIGITAL ASSISTANT |
DK201770431A1 (en) | 2017-05-15 | 2018-12-20 | Apple Inc. | Optimizing dialogue policy decisions for digital assistants using implicit feedback |
DK201770432A1 (en) | 2017-05-15 | 2018-12-21 | Apple Inc. | Hierarchical belief states for digital assistants |
DK179549B1 (en) | 2017-05-16 | 2019-02-12 | Apple Inc. | Far-field extension for digital assistant services |
CN116700660A (en) * | 2022-11-15 | 2023-09-05 | 荣耀终端有限公司 | Audio playing method and electronic equipment |
Citations (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5244705A (en) | 1990-08-24 | 1993-09-14 | Sony Corporation | Disc-shaped recording medium |
CN1084108A (en) | 1992-09-18 | 1994-03-23 | 马永怀 | A kind of electrical liquid hammer system driven by feed liquid |
US5301172A (en) | 1991-11-15 | 1994-04-05 | U.S. Philips Corporation | Method of storing user information items and apparatus for reproducing stored items |
US5300233A (en) | 1993-02-09 | 1994-04-05 | Dorr-Oliver Incorporated | Process of displacement washing in a centrifuge filter |
US5499316A (en) | 1991-07-19 | 1996-03-12 | Sharp Kabushiki Kaisha | Recording and reproducing system for selectively reproducing portions of recorded sound using an index |
GB2300286A (en) | 1995-04-27 | 1996-10-30 | Samsung Electronics Co Ltd | IC card memory arrangement for recording and reproducing audio and/or video data concurrently and separately |
EP0802688A2 (en) | 1996-04-17 | 1997-10-22 | Hitachi, Ltd. | Apparatus for recording and reproducing digital image and speech |
JPH1063286A (en) | 1997-04-28 | 1998-03-06 | Sony Corp | Music selector |
EP0840506A2 (en) | 1996-10-30 | 1998-05-06 | Sony Corporation | Picture data reading and writing method and apparatus |
US5815201A (en) | 1995-02-21 | 1998-09-29 | Ricoh Company, Ltd. | Method and system for reading and assembling audio and image information for transfer out of a digital camera |
RU2121164C1 (en) | 1992-02-19 | 1998-10-27 | Филипс Электроникс Н.В. | Device for data transmission, transmitter, receiver and method for storage of information signal on information recording medium |
US5887193A (en) | 1993-07-30 | 1999-03-23 | Canon Kabushiki Kaisha | System for loading control information from peripheral devices which are represented as objects to a controller in a predetermined format in response to connection operation |
US5892975A (en) | 1995-05-31 | 1999-04-06 | Intel Corporation | System for wake-up module on PC card detecting switches had actuated and causing image to display to appear that was displayed when turned off |
US5920477A (en) | 1991-12-23 | 1999-07-06 | Hoffberg; Steven M. | Human factored interface incorporating adaptive pattern recognition based controller apparatus |
US6606707B1 (en) | 1999-04-27 | 2003-08-12 | Matsushita Electric Industrial Co., Ltd. | Semiconductor memory card |
US6636773B1 (en) | 1999-05-28 | 2003-10-21 | Matsushita Electric Industrial Co., Ltd. | Semiconductor memory card, apparatus for recording data onto the semiconductor memory card, and apparatus for reproducing data of the semiconductor memory card |
US6832293B1 (en) | 1999-05-28 | 2004-12-14 | Matsushita Electric Industrial Co., Ltd. | Audio playback apparatus and method for resuming interrupted playback recording |
US6865431B1 (en) | 1999-05-28 | 2005-03-08 | Matsushita Electric Industrial Co., Ltd. | Semiconductor memory card, playback apparatus, recording apparatus, playback method, recording method, and computer-readable recording medium |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3241372B2 (en) * | 1990-11-27 | 2001-12-25 | パイオニア株式会社 | Karaoke performance method |
US5646866A (en) * | 1995-02-15 | 1997-07-08 | Intel Corporation | Preloading files for subsequent processing |
KR0176496B1 (en) * | 1994-12-28 | 1999-04-15 | 윤종용 | Compcat disk ok with video background reproduction apparatus and control method |
JPH1063274A (en) * | 1996-08-21 | 1998-03-06 | Aqueous Res:Kk | Karaoke machine |
JP4013281B2 (en) * | 1997-04-18 | 2007-11-28 | ヤマハ株式会社 | Karaoke data transmission method, karaoke apparatus, and karaoke data recording medium |
-
2000
- 2000-05-24 WO PCT/JP2000/003300 patent/WO2000074061A1/en active Application Filing
- 2000-05-24 CN CNB008014930A patent/CN1196130C/en not_active Expired - Lifetime
- 2000-05-24 BR BR0006168-9A patent/BR0006168A/en not_active IP Right Cessation
- 2000-05-24 BR BRPI0006168-9A patent/BRPI0006168B1/en unknown
- 2000-05-24 CA CA002338725A patent/CA2338725C/en not_active Expired - Lifetime
- 2000-05-26 US US09/580,581 patent/US6647496B1/en not_active Expired - Lifetime
- 2000-05-26 DE DE60035827T patent/DE60035827T2/en not_active Expired - Lifetime
- 2000-05-26 EP EP00111471A patent/EP1056094B1/en not_active Expired - Lifetime
- 2000-05-27 MY MYPI20002377A patent/MY130770A/en unknown
-
2003
- 2003-05-29 US US10/446,655 patent/US6779116B2/en not_active Expired - Lifetime
-
2004
- 2004-04-27 US US10/832,434 patent/US7471878B2/en not_active Expired - Fee Related
-
2008
- 2008-11-14 US US12/271,125 patent/US8175441B2/en not_active Expired - Fee Related
Patent Citations (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
RU2032233C1 (en) | 1990-08-24 | 1995-03-27 | Сони Корпорейшн | Disk-shaped record medium |
US5244705A (en) | 1990-08-24 | 1993-09-14 | Sony Corporation | Disc-shaped recording medium |
US5499316A (en) | 1991-07-19 | 1996-03-12 | Sharp Kabushiki Kaisha | Recording and reproducing system for selectively reproducing portions of recorded sound using an index |
US5301172A (en) | 1991-11-15 | 1994-04-05 | U.S. Philips Corporation | Method of storing user information items and apparatus for reproducing stored items |
US5920477A (en) | 1991-12-23 | 1999-07-06 | Hoffberg; Steven M. | Human factored interface incorporating adaptive pattern recognition based controller apparatus |
US6693636B2 (en) | 1992-02-19 | 2004-02-17 | Koninklijke Philips Electronics N.V. | Information transfer system, a transmitter, a receiver and a record carrier for use in the system |
US20030043136A1 (en) | 1992-02-19 | 2003-03-06 | Koninklijke Philips Electronics N.V. | Information transfer system, a transmitter, a receiver and a record carrier for use in the system |
US6480197B1 (en) | 1992-02-19 | 2002-11-12 | Koninklijke Philips Electronics N.V. | Transmitter, receiver and/or record carrier for use with an information signal including a coded text line having character codes and control codes for controlling display of characters defined by the character codes |
RU2121164C1 (en) | 1992-02-19 | 1998-10-27 | Филипс Электроникс Н.В. | Device for data transmission, transmitter, receiver and method for storage of information signal on information recording medium |
CN1084108A (en) | 1992-09-18 | 1994-03-23 | 马永怀 | A kind of electrical liquid hammer system driven by feed liquid |
US5300233A (en) | 1993-02-09 | 1994-04-05 | Dorr-Oliver Incorporated | Process of displacement washing in a centrifuge filter |
US5887193A (en) | 1993-07-30 | 1999-03-23 | Canon Kabushiki Kaisha | System for loading control information from peripheral devices which are represented as objects to a controller in a predetermined format in response to connection operation |
US5815201A (en) | 1995-02-21 | 1998-09-29 | Ricoh Company, Ltd. | Method and system for reading and assembling audio and image information for transfer out of a digital camera |
GB2300286A (en) | 1995-04-27 | 1996-10-30 | Samsung Electronics Co Ltd | IC card memory arrangement for recording and reproducing audio and/or video data concurrently and separately |
US5911031A (en) | 1995-04-27 | 1999-06-08 | Samsung Electronics Co., Ltd. | IC card memory for recording and reproducing audio and/or video data concurrently or separately and a control method thereof |
US5892975A (en) | 1995-05-31 | 1999-04-06 | Intel Corporation | System for wake-up module on PC card detecting switches had actuated and causing image to display to appear that was displayed when turned off |
EP0802688A2 (en) | 1996-04-17 | 1997-10-22 | Hitachi, Ltd. | Apparatus for recording and reproducing digital image and speech |
EP0840506A2 (en) | 1996-10-30 | 1998-05-06 | Sony Corporation | Picture data reading and writing method and apparatus |
JPH1063286A (en) | 1997-04-28 | 1998-03-06 | Sony Corp | Music selector |
US6606707B1 (en) | 1999-04-27 | 2003-08-12 | Matsushita Electric Industrial Co., Ltd. | Semiconductor memory card |
US6636773B1 (en) | 1999-05-28 | 2003-10-21 | Matsushita Electric Industrial Co., Ltd. | Semiconductor memory card, apparatus for recording data onto the semiconductor memory card, and apparatus for reproducing data of the semiconductor memory card |
US6832293B1 (en) | 1999-05-28 | 2004-12-14 | Matsushita Electric Industrial Co., Ltd. | Audio playback apparatus and method for resuming interrupted playback recording |
US6865431B1 (en) | 1999-05-28 | 2005-03-08 | Matsushita Electric Industrial Co., Ltd. | Semiconductor memory card, playback apparatus, recording apparatus, playback method, recording method, and computer-readable recording medium |
Non-Patent Citations (4)
Title |
---|
Chinese Office Action mailed Dec. 26, 2003 for Chinese Application No. 00801493.0 w/English translation. |
Chinese Office Action mailed Jul. 16, 2004 for Chinese Application No. 00801493.0 w/English translation. |
Russian Office Action mailed Sep. 29, 2004 for Russian Application No. 2001105543 w/English translation. |
U.S. Patent Office Notice of Allowance mailed Sep. 30, 2008 for U.S. Appl. No. 10/832,434. |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9182940B1 (en) * | 2013-12-10 | 2015-11-10 | Amazon Technologies, Inc. | Systems and methods for determining playback locations in media files |
Also Published As
Publication number | Publication date |
---|---|
CA2338725C (en) | 2008-01-08 |
CN1318197A (en) | 2001-10-17 |
US20090105859A1 (en) | 2009-04-23 |
BRPI0006168B1 (en) | 2017-11-28 |
DE60035827D1 (en) | 2007-09-20 |
EP1056094A1 (en) | 2000-11-29 |
US20030200452A1 (en) | 2003-10-23 |
EP1056094B1 (en) | 2007-08-08 |
CA2338725A1 (en) | 2000-12-07 |
MY130770A (en) | 2007-07-31 |
US6647496B1 (en) | 2003-11-11 |
US7471878B2 (en) | 2008-12-30 |
DE60035827T2 (en) | 2007-12-06 |
US6779116B2 (en) | 2004-08-17 |
US20040197084A1 (en) | 2004-10-07 |
CN1196130C (en) | 2005-04-06 |
WO2000074061A1 (en) | 2000-12-07 |
BR0006168A (en) | 2001-04-17 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8175441B2 (en) | Playback program | |
US7930478B2 (en) | Semiconductor memory card, playback apparatus, recording apparatus, playback method, recording method and a computer-readable storage medium | |
US7596698B2 (en) | Semiconductor memory card, playback apparatus, recording apparatus, playback method, recording method, and computer-readable recording medium | |
WO2000074054A2 (en) | Semiconductor memory card, apparatus for recording data onto the semiconductor memory card, and apparatus for reproducing data of the semiconductor memory card | |
US6072936A (en) | Picture synthesizing apparatus and recording medium | |
US20060251398A1 (en) | Medium for storing audio/image information and management system thereof | |
JP3366896B2 (en) | Semiconductor memory card, recording / reproducing apparatus, recording / reproducing method, and computer-readable recording medium | |
RU2259604C2 (en) | Semiconductor memory board, reproduction device, recording device, reproduction method, recording method and computer-readable data carrier | |
JP4469125B2 (en) | Semiconductor memory card, editing apparatus, editing method, and computer-readable recording medium | |
JP3327898B2 (en) | Semiconductor memory card, playback device, playback method, and computer-readable recording medium | |
RU2255382C2 (en) | Semiconductor memory board, reproduction device, recording device, reproduction method, recording method and data carrier read by a computer | |
JP2003162300A (en) | Device for reproducing semiconductor memory card, computer-readable recording medium, and reproducing method therefor |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
FEPP | Fee payment procedure |
Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
FPAY | Fee payment |
Year of fee payment: 4 |
|
FEPP | Fee payment procedure |
Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
LAPS | Lapse for failure to pay maintenance fees |
Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STCH | Information on status: patent discontinuation |
Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362 |
|
FP | Lapsed due to failure to pay maintenance fee |
Effective date: 20200508 |