WO2004109697A1 - データ記録方法、データ記録装置、およびデータ記録媒体 - Google Patents

データ記録方法、データ記録装置、およびデータ記録媒体 Download PDF

Info

Publication number
WO2004109697A1
WO2004109697A1 PCT/JP2004/006970 JP2004006970W WO2004109697A1 WO 2004109697 A1 WO2004109697 A1 WO 2004109697A1 JP 2004006970 W JP2004006970 W JP 2004006970W WO 2004109697 A1 WO2004109697 A1 WO 2004109697A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
post
recording
file
management information
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.)
Ceased
Application number
PCT/JP2004/006970
Other languages
English (en)
French (fr)
Inventor
Ayumi Kida
Jiro Kiyama
Takayoshi Yamaguchi
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sharp Corp
Original Assignee
Sharp Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Sharp Corp filed Critical Sharp Corp
Priority to US10/559,695 priority Critical patent/US7835614B2/en
Publication of WO2004109697A1 publication Critical patent/WO2004109697A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • 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
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G11B20/12—Formatting, e.g. arrangement of data block or words on the record carriers
    • G11B20/1217—Formatting, e.g. arrangement of data block or words on the record carriers on discs

Definitions

  • Data recording method data recording device, and data recording medium
  • the present invention relates to a data recording method and a data recording apparatus for recording and reproducing video data and audio data on a randomly accessible recording medium such as a hard disk or an optical disk.
  • the audio dubbing function is a function to add information, especially audio and graphics, to already recorded audio and video.
  • a non-destructive editing function or a non-linear editing function which is a characteristic function of a disk medium not found in a tape medium.
  • any section of the AV stream recorded on the disc can be played back in any order without moving or copying.
  • this function it is possible to create multiple user programs using the same scene rather than simply changing the playback order, that is, to share the same scene with multiple user programs. At this time, the user's request is that the user dubbed each user program individually.
  • Patent Document 1 which is a Japanese published patent publication, provides information for managing the after-recording area allocation, so that when a plurality of user programs perform post-recording, they can be shared between different user programs. It is possible to prevent unintended overwriting of the dubbing of the same scene that is performed.
  • Fig. 27 shows a recording format of a disc in Patent Document 1 described above.
  • Disc The recording area is composed of a row of ECC (Error Correcting Code) blocks.
  • ECC Error Correcting Code
  • the ECC block is the minimum unit when performing coding, and is encoded with parity added for error correction in addition to data. When reading the data in the disk, correct the reading error in units of this ECC block, and then extract the necessary data.
  • Video (video) data and audio (audio) data are arranged in the ECC block in the following order: an after-recording data block, an original audio block, and an original video block.
  • Each block contains post-record data, original video data, and original video data corresponding to almost the same time.
  • the original audio block and the original video block are collectively referred to as an original block.
  • an original block When recording the original program (the image before recording the post-record data), write dummy data in the post-record data block.
  • the post-record data to be deleted is only referenced by the user program to be deleted, and is shared by other user programs. Not necessary.
  • Patent Document 1 Japanese Patent Application Laid-Open No. 2002-373480 (Published December 26, 2002)
  • the present invention has been made to solve the above problems, and an object of the present invention is to determine whether or not the post-record data referred to in the user program can be deleted when the user program is deleted.
  • An object of the present invention is to provide a data recording method and a data recording device that can make a judgment easily.
  • a data recording method is a data recording method for recording AV data and post-recording data synchronized with the AV data on a recording medium.
  • AV data AV data
  • post-record data contains multiple user programs.
  • the management information that can be referred to from the program and manages the relationship between the user program and the post-record data is recorded on the recording medium.
  • FIG. 1, showing an embodiment of the present invention, is a flowchart illustrating a flow of processing when recording post-recording data.
  • FIG. 2 is a block diagram showing a schematic configuration of a data recording device according to the present invention.
  • FIG. 3 (a) is a diagram showing a relationship between management information and an AV stream in the QuickTime file format.
  • FIG. 3 (b) is a diagram showing a relationship between management information and an AV stream in the QuickTime file format.
  • FIG. 3 (c) is a diagram showing a relationship between management information and an AV stream in the QuickTime file format.
  • FIG. 4 is a diagram showing an outline of a Movie atom in the QuickTime file format.
  • FIG. 5 is a diagram showing an outline of a track atom in the QuickTime file format.
  • FIG. 7 is a diagram showing the configuration of a Media atom in the QuickTime file format.
  • FIG. 8 is a diagram showing a configuration of a Media information atom in a QuickTime finale format.
  • FIG. 9 is a diagram showing an example of data management using a sample table atom.
  • FIG. l l (a) is a diagram showing the structure of a Sample description atom in the QuickTime file format.
  • FIG. 11 (b) A diagram showing the configuration of a Sound Sample description Table.
  • FIG. 12 is a diagram showing the structure of an Edit atom in the QuickTime file format.
  • FIG. 13 (a) is a diagram showing an example of a reproduction range specified by an Edit atom.
  • FIG. 13 (b) is a diagram illustrating an example of a reproduction range specified by an Edit atom.
  • FIG. 13 (c) is a diagram illustrating an example of a reproduction range specified by an Edit atom.
  • FIG. 14 is a diagram showing the configuration of a User data atom in the QuickTime file format
  • FIG. 15 is a diagram showing a configuration of an AV stream.
  • FIG. 16 (a) is a diagram showing a relationship of management information in a UDF.
  • FIG. 16 (b) is a diagram showing a relationship of management information in a UDF.
  • FIG. 17 is a diagram showing a configuration of a User data atom in a QuickTime file format according to the first embodiment of the present invention.
  • FIG. 18 is a diagram showing management information of an original program immediately after recording according to the first embodiment of the present invention.
  • FIG. 19 (a) is a diagram showing a change of an unallocated track when a user program is created in Embodiment 1 of the present invention.
  • FIG. 19 (b) is a diagram showing a change of an unallocated track when a user program is created in Embodiment 1 of the present invention.
  • FIG. 20 is a diagram showing a relationship between a data arrangement on a disk and a file according to the first embodiment of the present invention.
  • FIG. 21 is a diagram showing an example of editing a user program according to the first embodiment of the present invention.
  • FIG. 22 is a flowchart showing a flow of a process of deleting a user program according to the first embodiment of the present invention.
  • FIG. 23 is a diagram showing a reference relationship immediately before a user program is deleted in the first embodiment of the present invention.
  • FIG. 24 is a diagram showing a reference relationship immediately after a user program is deleted in the first embodiment of the present invention.
  • FIG. 25 is a diagram showing a relationship between data arrangement on a disk and files according to Embodiment 2 of the present invention.
  • FIG. 26 is a diagram showing a relationship between a user program reference relationship and an index file according to Embodiment 2 of the present invention.
  • FIG. 27 is a diagram showing a recording form on a disk according to a conventional technique.
  • FIG. 2 shows the configuration of a video disc recorder that can be dubbed and commonly used in the present embodiment.
  • the video disk recorder includes a bus 100, a host CPU (Central Processing Unit) 101, a RAM (Random Access Memory) 102, a ROM (Read Only Memory) 103, a user interface 104, a system clock 105, optical disk 106, pickup 107, ECC (Error Correcting Code) decoder 108, ECC encoder 109, playback buffer 110, recording / after-recording buffer 111, demultiplexer 112, multiplexer 113, multiplexing buffer 114, audio decoder 115, a video decoder 116, an audio encoder 117, a video encoder 118, and a camera, a microphone, a speaker, and a display (not shown).
  • a host CPU Central Processing Unit
  • RAM Random Access Memory
  • ROM Read Only Memory
  • the host CPU 101 communicates with the demultiplexer 112, the multiplexer 113, the pickup 107, and the audio decoder 115, the video decoder 116, the audio encoder 117, and the video encoder 118 (not shown) through the bus 100.
  • the demultiplexer 112 sorts the data in the reproduction buffer 110 to an appropriate decoder according to the type according to a data transmission request from the audio decoder 115 and the video decoder 116.
  • data compressed and encoded by the audio encoder 117 and the video encoder 118 is temporarily stored in the multiplexing buffer 114 via the multiplexer 113.
  • the data is further AV-multiplexed by the multiplexer 113 and sent to the multiplexing buffer 114 for recording / recording.
  • the data in the recording / after-recording buffer 111 is added with an error correction code by an ECC encoder 109 and is recorded on an optical disk 106 via a pickup 107.
  • MPEG-I Layer_II can be used for the encoding method of audio data
  • MPEG-2 can be used for the encoding method of video data.
  • the optical disc 106 is a recording medium on which recording and reproduction are performed spirally from the outer periphery to the inner periphery, and is a recording medium that is detachable from a video disc recorder.
  • 2048 bytes are defined as one sector, and an ECC block is composed of 16 sectors for error correction.
  • the optical disc 106 employs ZCAV (constant zone angular velocity) in order to increase the recording efficiency, and the recording area is composed of a plurality of zones having different rotation speeds.
  • a file system is used to manage various information on the optical disk 106, and this file system is recorded on the optical disk 106 together with data (after-record data, audio data, video data).
  • UDF Universal Disk Format
  • PC personal computer
  • various management information and AV streams are treated as files.
  • the user area of the file system is managed by a 2048-byte logical block (one-to-one correspondence with a sector).
  • Each file in the user area is composed of an integer number of extents (consecutive logical blocks), and may be recorded in a distributed manner in extent units.
  • the free space in the user area is managed in logical block units using the Space Bitmap.
  • QuickTime file format is used as the format for AV stream management.
  • the QuickTime file format is a multimedia developed by Apple Inc. A data management format that is widely used in the PC world.
  • the QuickTime file format includes video data, audio data, and the like (these are also collectively referred to as media data) and management information.
  • the media data and the management information are collectively referred to herein as a QuickTime movie (movie for short).
  • the media data and the management information may be in the same file or may be in separate files.
  • the file configuration is as shown in FIG. 3A.
  • Various types of information are stored in a common structure called an atom.
  • the management information is stored in a structure called Movie atom
  • the AV stream of the media data is stored in a structure called Movie data atom.
  • An Atom Header (AH) is placed at the beginning of the Movie data atom.
  • the management information in the Movie atom includes a table for deriving the relative position in the file of the AV stream corresponding to an arbitrary time in the media data, attribute information of the media data, and external reference described later. Information is included.
  • the management information and the media data are stored in separate files, a configuration as shown in FIG. 3B is adopted.
  • the management information is stored in the structure called Movie atom in the file 202, but the AV stream is stored in the file 203, which need not be stored in the atom.
  • the Movie atom "externally references" the file 203 storing the AV stream.
  • a plurality of AV stream files (files 205 and 206 in this figure) can be referenced by one file 204 storing management information. It is. With this mechanism, so-called “non-linear editing” and “non-destructive editing” can be performed, which make it appear as if the AV stream itself has been physically edited without physically moving it. Also, it is possible to create a plurality of user programs using the same scene of the AV stream recorded on the optical disc 106, and to refer to the same post-recording data by a plurality of user programs. Is also possible.
  • Atom size which is the size of the atom
  • Type which is the type information of the atom
  • Exists. Type is distinguished by 4 characters. For example, "moov” for Movie atom and "mdat” for Movie data atom.
  • each atom can include another atom.
  • Figure 4 shows the structure of the Movie atom.
  • the Movie header atom manages the overall attributes of the movie managed by that Movie atom.
  • the Track atom stores information about tracks such as video and audio included in the movie.
  • User data atom is an atom that can be defined by the user.
  • FIG. 5 shows the configuration of the Track atom.
  • the Track header atom manages the overall attributes of the track.
  • the Edit atom manages which section of the media data is played at which timing in the movie.
  • the Track reference atom manages the relationship with another track.
  • Media atom manages actual data such as video and audio.
  • Fig. 6 shows the configuration of the Track header atom.
  • Flags is a set of flags indicating attributes.
  • a typical example is the Track enabled flag. If the flag is set to 1 ', the track is played, and if the flag is set to' 0 ', the track is not played.
  • Track ID is a track-specific ID.
  • Layer indicates the spatial priority of the track. If there are multiple tracks that display an image, the image with the smaller Layer value is displayed in the foreground.
  • FIG. 7 shows the configuration of the Media atom.
  • the Media header atom manages the overall attributes of the media data managed by the Media atom.
  • the Handler reference atom stores information indicating which decoder decodes the media data.
  • the Media information atom manages attribute information unique to media such as video and audio.
  • FIG. 8 shows the configuration of the Media information atom.
  • the Media information header atom manages attribute information unique to media such as video audio.
  • the Handler reference atom is as described in the section on Media atom.
  • the Data information atom is
  • the sample table atom manages the data size and playback time.
  • the playback time length and data size of each sample are managed.
  • a region where samples belonging to the same track are continuously arranged in the file in the order of the reproduction time is called a chunk. Chunks are also numbered in order of playing time. That is, in the QuickTime format, one file 901 is formed by arranging chunks in this manner.
  • the address from the beginning of the file in each chunk and the number of sample points included in each chunk are managed. Based on this information, it is possible to determine the location of Sampnolle at any time.
  • FIG. 10 shows the configuration of the sample table atom.
  • the Sample description atom manages the data format (Data format) of each channel and the index of the chunk of the file in which the sample is stored.
  • Figure 11 (a) shows the structure of the sample description atom. number-of-entries represents the number of data formats used, and that number is the number of the sample description table.
  • Fig. 11 (b) is an example of the sample description table of Ortio.
  • the time-to-sample atom manages the reproduction time of each sample.
  • the Sync sample atom manages the samples that can start decoding among the individual samples.
  • the Sample-to-chunk atom manages the number of samples included in each chunk.
  • the Sample size atom manages the size of each sample.
  • the Chunk offset atom manages the address of each chunk from the beginning of the file.
  • the Edit atom includes one Edit list atom as shown in FIG. Edit list atom
  • Each entry corresponds to a section that is continuously reproduced on a track, and is arranged in the order of the reproduction time on that track.
  • Track duration is the playback time on the track of the section managed by the entry
  • Media time is the position on the media data corresponding to the beginning of the section managed by the entry
  • Media rate indicates the playback speed of the section managed by the entry. If Media time is, playback of the sample on that track is stopped for the Track duration of the entry. This section is called empty edit.
  • FIG. 13 shows an example of using the Edit list.
  • the content of the Edit list atom is the content shown in FIG. 13 (a)
  • the sample configuration is the configuration shown in FIG. 13 (b).
  • the track duration of the i-th entry is indicated as D (i)
  • the media time is indicated as T (i)
  • the media rate is indicated as R (i).
  • the entry # 1 since the entry # 1 has a track duration of 13000, a media time of 20000, and a media rate of 1, the section 13000 from the beginning of the track reproduces the section from time 20000 to 33000 during sampling.
  • the track duration is 5000 and the media time is -1, so the section of the track from time 13000 to 18000, no playback is performed.
  • the track duration is 10000, the media time is 0, and the media rate is 1, the section from time 18000 to 28000 in the track and the section from time 0 to 10,000 in the sample are played. .
  • FIG. 14 shows the configuration of the User data atom.
  • This atom can store any number of unique information that is not defined in QuickTime format.
  • One unique information is managed by one entry, and one entry is composed of Atom size, Type, and User data.
  • Atom size represents the size of the entry itself
  • Type represents identification information for distinguishing each unique information
  • User data represents actual data.
  • an index file is placed on the disc.
  • thumbnails and various attributes related to files in the disc are registered.
  • various attributes is a link count S that indicates the number of times the file has been externally referenced.
  • Fig. 15 shows the format of the AV stream.
  • An AV stream is composed of an integer number of Continuous Units (CU).
  • CU is a unit continuously recorded on the disk.
  • the stream is configured so that the CU boundary matches the ECC block boundary.
  • the CU is composed of one Post Record Unit (PRU) and an integral number of Video Units (VUs).
  • VU is an independently reproducible unit, and a set of VUs corresponds to the above-mentioned original block.
  • the PRU corresponds to the post-record data block described above.
  • the PRU area size is the CU playback time multiplied by the maximum audio bit rate.
  • UDF Universal Disk Format
  • FIG. 16B shows an example in which the directory / file structure shown in FIG. 16A is recorded in UDF.
  • AVDP602 in the figure is an abbreviation for Anchor Volume Descriptor Pointer, which corresponds to an entry point for searching UDF management information, and is usually 256th sector, Nth sector, or N-256th sector (N is the maximum logical sector). Number).
  • VDS 601 is an abbreviation for Volume Descriptor Sequence, and records management information on a volume that is an area managed by the UDF.
  • a volume generally resides on a single disk, and typically contains one partition.
  • FSD603 is an abbreviation of File Set Descriptor, and there is one in a partition. Position information in a partition is indicated by a logical block number corresponding to the sector number from the beginning of the partition. One logical block corresponds to one sector. In addition, each partition has a table (not shown) indicating whether each logical block called Space Bitmap is already assigned to a file or not.
  • the FSD 603 includes position information (consisting of a logical block number and a logical block number and called an extent) of the FE 604, which is a File Entry (FE) of the root directory.
  • the FE manages a set of extents, and by rewriting, adding, or deleting extents, it is possible to change the order of actual data that constitutes a file, or to insert or delete data. Possible is there.
  • the FE 604 manages an area 605 for storing a set of File Identifier Descriptors (FIDs) for storing names of files and directories immediately below the root directory.
  • FIDs File Identifier Descriptors
  • the FID 611 and the FID 612 in the area 605 include the position information of the FE 606 and the FE 608 that manage the set of the file name and the extent of the file 621 and the file 622, respectively.
  • the FE 606 manages an area 607 and an area 610 which are areas constituting actual data of the file 621 as an extent.
  • the FE 608 manages an area 609, which is an area constituting the actual data of the file 622, as an extent.
  • the concealment of the AVDP602, VDS601, FSD603, FE604, FID611, FE606, area 607, and area 610 may be performed.
  • Embodiment 1 of the present invention will be described with reference to FIG. 1, FIG. 17 to FIG.
  • the PRU is an area reserved for post-record data when recording an original program.
  • a post-record file is created when recording an AV stream, and this area is managed as dummy data.
  • an unallocated track for managing an area of the PRU area where the post-record data is not recorded is created, and at the time of initial recording, one sample of the PRU area in CU units Create a sample table that manages the position, size, and time information for all PRU areas. For this unassigned track, the Track Enabled flag of the Track header atom is set to 0, indicating that it is not a playback target.
  • the creation of the user program depends on the management information power of the original program and the AV stream. What is necessary is just to copy the sample table of the section specified by the rack user.
  • the QuickTime management information of the user program is read into the RAM 102. Also, the original program is specified from the file name described in the Data reference atom of the management information of the user program, and the QuickTime management information of the referenced original program is also read into the RAM 102 (S1501).
  • the position of the PRU in which the post-record data is to be recorded in the section specified by the user is determined by searching the sample table of the unallocated track of the original program for a portion temporally corresponding to the video to be post-recorded. Identify. If the audio dubbing to be recorded is audio, the amount of data is calculated from the bit rate, and it is determined whether or not the data can be managed within the unallocated tracks and fit within the size of the PRU (S1502).
  • the post-recording is a graphic
  • the post-record data is actually recorded in that area.
  • the reference management atom ('rfmg is defined', which is a unique Atom type, as shown in Fig. 17.
  • D Define the field 'ref_counter'.
  • a new track for reproducing the recorded after-recording data is also newly created on the user program side, and a sample table of the after-recording track is created similarly to the original program created earlier.
  • the host CPU 101 performs the processing of S1502 and S1506 on the QuickTime management information of the original program and the user program read into the RAM 102. Then, the QuickTime management information of the original program and the user program subjected to the processing of S1502-S1506 is read from the RAM 102 by the control of the host CPU 101 and written to the optical disk 106 via the bus 100 and the pickup 107.
  • the original program after recording the post-record data is as shown in FIG.
  • the PRU in the section where post-recording is recorded is composed of an area where post-recording data is recorded (already allocated area) and an unallocated area.
  • the Movie atom which is the management information of the original program, has four tracks: a Video track, a Main Audio track, a post-recording track (PR Audio in the figure), and an unallocated track. With information.
  • Fig. 19 (a) shows the state of the PRU before post-record data addition
  • Fig. 19 (b) shows the PRU state after post-record data addition.
  • Fig. 19 (b) after the already recorded post-record #A track, Create a new post-record #B track for post-record data, and manage it with one track for each post-record data.
  • the value of Chunk offset sets the start position of new post-record data in the PRU.
  • new post-recording data is recorded immediately after the existing post-recording data. Recording is possible at any position in the unallocated area.
  • the Chunk offset and Sample size of the harmless track are updated according to the remaining area.
  • the original block is treated as one file (stream file) and the post-record data block is treated as one external reference file (post-record file).
  • post-record file multiple post-record data are mixed in the post-record file.
  • the management information of the user programs 1 and 2 is read into the RAM 102 and combined as a new user program 3. Further, the original program is specified from the reference file name described in the Data reference atom of the user program 3, and management information on the original program is read into the RAM 102.
  • the user program 3 is searched from a plurality of post-record data. Identify the post-record data referred to by, and set the red_counter in the reference management atom i, rfmg ') of the udta atom in the track atom to be measured.
  • the processing when the user instructs to delete the user program will be described with reference to FIG. First, the management information of the user program instructed to be deleted is read into the RAM 102.
  • the track in the management information of the user program is checked, and the original program managing the post-record data referred to by the user program is listed (S2101). If there is no track for managing the after-recording data, the process ends.
  • the management information of the original program is read into the RAM 102.
  • the corresponding dubbing track in the original program is searched from the chunk offset information of the dubbing track in the user program, and the ref_counter of the searched track is decremented by 1 (S2102).
  • ref_counter is not 0 in S2103, it indicates that there is another user program referring to the post-recording data. That is, the flow shifts to S2107, without performing the post-recording date deletion process.
  • the retcounter number of B becomes 0.
  • the post-record data B is data that has been referenced only by the user program 3. Therefore, the post-record data B is also deleted at the same time as the user program 3.
  • the post-record data A is also deleted because it is referred to by other user programs (here, it is referred to from the user program 2). Nare,
  • the force S having the field indicating the number of times of reference in the udta atom is not limited to this.
  • Sample in the sample description atom information indicating the number of times of reference is referred to as Sample in the sample description atom.
  • information on the file name of the referencing user program may be provided by using only a ref-counter that does not reduce the number of illuminations.
  • the user instructs to delete the post-record data, in addition to the information on whether or not the post-record data is being referred to from another user program file, the user can also determine from which file the post-record data is referred. It is possible to present.
  • Embodiment 2 is similar to Embodiment 1 described above, and therefore only different points will be described.
  • FIG. 25 shows the relationship between the arrangement on the disk and the file when there are two types of post-record data.
  • a post-record data block and an original block that is, an original audio block and an original video block
  • the post-record data block is an area for recording the post-record data #A.
  • An area for recording post-record data #B and an unallocated area.
  • the data relating to the post-record data #A is managed in a post-record A file
  • the data relating to the post-record data #B is managed in a post-record B file
  • the unallocated area is managed in a dummy file.
  • the processing at the time of the initial recording in the second embodiment is the same as that in the first embodiment, and thus the description is omitted.
  • a process at the time of post-recording data recording in the second embodiment will be described.
  • the QuickTime management information of the user program to which after-recording data is added is read into the RAM 102, the original program is specified, and the QuickTime management information of the original program is read into the RAMI02. Further, the file system management information is read into the RAM 102.
  • the specification of the position of the PRU and the determination of the after-recording data recording area are the same as those in the first embodiment, and therefore will not be described.
  • the post-record data is recorded in the PRU area on the disk, and a new post-record file is created to update the file system management information.
  • the size of the dummy file composed of the unallocated area is reduced according to the size of the newly created post-record data, and the file system management information is updated.
  • the chunk offset and size of the sample table of the unallocated track of the original program are updated so as to correspond to the remaining area of the PRU after the post-recording data recording.
  • the QuickTime management information of the original program and the user program on the RAMI 02 and the file system management information are recorded on the optical disc 106.
  • the track of the post-record data referenced by the user program is specified from the original program having a plurality of post-record data, it is described in the Data reference atom of the post-record track of the user program.
  • the original program is searched for in the original program by referring to the same file name as the file name.
  • the original program is specified from the audio / video file referenced by the user program.
  • Other processes are the same as in the first embodiment.
  • the data reference atom when specifying which track of the post-recording data of the user program to be deleted is managed by the original program, the data reference atom is referred to in the same manner as described in the processing at the time of creating the user program. This is done using the file name.
  • the size and address of the post-record file do not always change. Therefore, after-recording data can be deleted only by rewriting the management information, and it is not necessary to rewrite the file system.However, when specifying the after-recording data, search for the specific data in the after-recording file from the chunk offset value of the sample. I had to do it.
  • post-record data can be specified from the reference file name of the data reference atom in one shot, and the data can be specified. It can be performed more easily and more quickly.
  • file system operations are required.
  • the management information of the original program tracks are divided for each type of post-record data, and the number of times of reference is managed therein.
  • an index file which is a management information file existing on one disk, is used. Even if the configuration is managed within, In this case, as shown in FIG. 26, information for specifying a post-record data file such as a file name is managed in association with reference count information.
  • the recording medium used is an optical disk.
  • the recording medium to which the present invention can be applied is not limited to an optical disk, but is a random accessible recording medium (for example, a hard disk). If so,
  • the data recording method of the present invention is a data recording method of recording AV data and post-record data synchronized with the AV data on a recording medium.
  • a plurality of user programs can be created using the same scene of data, and post-record data can be referred to from a plurality of user programs, and management information for managing the relationship between the user programs and post-record data is recorded on the recording medium. It is characterized in that it is recorded above.
  • the post-record data is a partial area in an area including a post-record data group referred to in a plurality of user programs, and the area is recorded as one post-record file
  • the above-mentioned management information can be configured to be recorded for each post-record data in a management information file that exists one for the original program.
  • the post-record data is recorded as a post-record file for each post-record data group referred to in the same user program. It can be configured to be recorded for each post-record file in the existing management information file.
  • the post-record data is recorded as a post-record file for each post-record data group referred to in the same user program, and one piece of the management information exists in the original program. It can be configured to be recorded for each post-record file in the management information file to be recorded.
  • the management information may include a reference count when the post-record data is referred to from a plurality of user programs.
  • the number of times the post-record data is referenced from the user program is reduced by one. Then, it is easy to confirm that the post-record data whose reference count becomes 0 by the process of reducing the reference count is referred to only by the user program to be deleted.
  • the management information may include a user program name referring to the post-record data.
  • the post-record data is stored in another user program file.
  • the management information may be configured to include information on a reference range of the post-record data referenced by the user program.
  • the post-record data itself can have a plurality of pieces by such reference range information. Can be used to delete only the parts that are no longer needed even if they are referenced from the user program, making it possible to use the recording area of the recording medium more effectively.
  • a data recording method and a data recording apparatus for recording and reproducing video data and audio data on a randomly accessible recording medium such as a hard disk or an optical disk
  • the user program refers to the user program. This makes it easy to determine whether or not the post-record data that has been deleted can be deleted.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Management Or Editing Of Information On Record Carriers (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)
  • Television Signal Processing For Recording (AREA)

Abstract

　オリジナルプログラムを外部参照したユーザプログラムを作成し、それにアフレコデータを記録するにあたって、アフレコデータのユーザプログラムからの参照回数を示すref_counterを設定する（Ｓ１５０５）。設定されたref_counterは、作成されたユーザプログラムと共に光ディスクに記録される（Ｓ１５０７）。

Description

明 細 書
データ記録方法、データ記録装置、およびデータ記録媒体
技術分野
[0001] 本発明は、映像データ、音声データをハードディスク、光ディスク等のランダムァク セス可能な記録媒体に対して記録'再生するデータ記録方法及びデータ記録装置 に関するものである。
^景技術
[0002] ディスクメディアや半導体媒体を用いたビデオや音声のディジタル記録再生装置が 普及しつつある。それらにおいて、テープメディアと同様アフターレコーディング（ァフ レコ）機能を安価に実現する技術が求められている。アフレコ機能は、既に記録した オーディオやビデオに対し、後から情報、特にオーディオやグラフィックを追記する機 能である。
[0003] ここで、テープメディアにはないディスクメディアにおける特徴機能である、非破壊 編集機能あるいはノンリニア編集機能と呼ばれる機能がある。すなわち、非破壊編集 機能あるいはノンリニア編集機能では、ディスク上に記録した AVストリームを移動あ るいはコピーすることなぐ AVストリームの任意の区間を任意の順番で再生できる。こ の機能においては、単に再生順番を変えるだけではなぐ同一のシーンを使って複 数のユーザプログラムを作る、つまり同一のシーンを複数のユーザプログラムで共有 すること力 S可能となる。このときのユーザの要望としては、それぞれのユーザプロダラ ムで個別にアフレコがしたレ、、というものがある。
[0004] 例えば、ユーザプログラム Aではあるシーンに対して BGMをアフレコし、同じシーン を共有するユーザプログラム Bではアナウンスをアフレコしたレ、、とレ、つた要望である 。そのような要望に対して、 日本国公開特許公報である特許文献 1では、アフレコ用 領域割り当てを管理する情報を備えることで、複数のユーザプログラムからアフレコし た場合に、異なるユーザプログラム間で共有される同一のシーンのアフレコに対して 、意図しない上書きをすることを防ぐことができる。
[0005] 上記特許文献 1におけるディスクの記録フォーマットを図 27に示す。ディスクにおけ る記録領域は、 ECC (Error Correcting Code)ブロックの列で構成される。 ECCブロ ックは符号ィヒを行う際の最小単位であり、データに加えエラー補正用のパリティが付 加され、符号化が行われている。ディスク内のデータを読み込む際は、この ECCプロ ックの単位で読み込み誤り訂正をしてから、必要なデータを取り出す。
[0006] 一方、ディスクに対してデータの書き換えを行う際は、まず ECCブロック単位で読み 込み、誤り訂正をしたデータに対して必要な部分を書き換え、再度誤り符号を付与し 、ディスクに記録を行う。
[0007] ビデオ（映像）データやオーディオ（音声）データは、 ECCブロック中で、アフレコデ 一タブロック、オリジナルオーディオブロック、オリジナルビデオブロックの順に配置さ れる。それぞれのブロックにはほぼ同じ時間に対応するアフレコデータ、オリジナルォ 一ディォデータ、オリジナルビデオデータが含まれてレ、る。
[0008] 尚、オリジナルオーディオブロックとオリジナルビデオブロックとを合わせてオリジナ ルブロックと呼ぶことにする。オリジナルプログラム（アフレコデータを記録する前の映 像）を記録する際は、アフレコデータブロックにダミーのデータを書き込んでおく。
[0009] アフレコデータの記録の際は、アフレコデータブロックへデータの書込みを行う。こ のとき、アフレコデータブロック中の記録を行った領域については既割り当て領域とし 、残りを未割り当て領域としてオリジナルプログラム中の管理情報内で別々に管理す る。この管理情報を参照することで、異なるユーザプログラム間でのアフレコデータの 上書きを防止することができる。新たなアフレコデータが記録された際には、それぞ れの領域における管理情報の書き換えを行う。
[0010] ところが、上記従来の構成では、ユーザプログラムを削除する場合を考えると、削除 されるユーザプログラムに対応して不要となったアフレコデータを削除して領域を開 放し、アフレコデータブロック領域を有効に再利用したいという要求に対しては、以下 のような問題が生じる。
[0011] すなわち、同一のシーンを複数のユーザプログラムで共有する場合、各アフレコデ ータは複数のユーザプログラムから参照されている可能性があり、これを安易に削除 することはできない。これを、より具体的に説明すると以下のとおりである。
[0012] つまり、あるユーザプログラムを削除するにあたって、この削除されるユーザプロダラ ムで参照されているアフレコデータを併せて削除しょうとする場合には、削除されるべ きアフレコデータは削除されるユーザプログラムのみで参照されるものであり、他のュ 一ザプログラムにおいて共有されていないことが必要である。
[0013] し力、しながら、従来では、ユーザプログラムの削除を行った場合、参照していたァフ レコデータが他のどのユーザプログラムからも参照されておらず削除可能であると判 断されるためには、すべてのユーザプログラムの管理情報をチェックする必要が生じ る。このようなチェック動作は、シーク時間の長い光ディスクにおいては処理時間の面 で問題となる。
特許文献 1：特開 2002—373480号公報 (公開日平成 14年 12月 26日）
発明の開示
[0014] 本発明は、上記の問題点を解決するためになされたもので、その目的は、ユーザプ ログラムの削除時、該ユーザプログラムにおいて参照していたアフレコデータが削除 可能であるか否かの判断を容易にすることができるデータ記録方法およびデータ記 録装置を提供することにある。
[0015] 上記の目的を達成するために、本発明に係るデータ記録方法は、記録媒体に、 A Vデータと、該 AVデータと同期するアフレコデータとを記録するデータ記録方法であ つて、記録媒体上に、 AVデータの同一のシーンを使って複数のユーザプログラムを 作成可能であり、かつ、アフレコデータが複数のユーザプ
ログラムから参照可能であり、ユーザプログラムとアフレコデータとの関係を管理する 管理情報を上記記録媒体上に記録することを特徴としている。
[0016] 上記の構成によれば、記録媒体に、 AVデータと、該 AVデータと同期するアフレコ データと記録するにあたって、記録媒体上に、 AVデータの同一のシーンを使って複 数のユーザプログラムを作成可能であり、かつ、アフレコデータが複数のユーザプロ グラムから参照可能となっている。
[0017] このため、例えば、あるユーザプログラムを削除するにあたって、この削除されるュ 一ザプログラムで参照されているアフレコデータを併せて削除しょうとする場合には、 削除されるべきアフレコデータは削除されるユーザプログラムのみで参照されるもの であることを確認することが必要となる力 S、このような確認が上記管理情報によって容 易に行える。
[0018] 本発明のさらに他の目的、特徴、および優れた点は、以下に示す記載によって十 分に理解されるであろう。また、本発明の利益は、添付図面を参照した次の説明で明 白になるであろう。
図面の簡単な説明
[0019] [図 1]本発明の一実施形態を示すものであり、アフレコデータ記録時の処理の流れを 示したフローチャートである。
[図 2]本発明に係るデータ記録装置の概略構成を示すブロック図である。
[図 3(a)]QuickTimeファイルフォーマットにおける管理情報と AVストリームとの関係を 示す図である。
[図 3(b)]QuickTimeファイルフォーマットにおける管理情報と AVストリームとの関係を 示す図である。
[図 3(c)]QuickTimeファイルフォーマットにおける管理情報と AVストリームとの関係を 示す図である。
[図 4]QuickTimeファイルフォーマットにおける Movie atomの概要を示す図である。
[図 5]QuickTimeファイルフォーマットにおける Track atomの概要を示す図である。
[図 6]QuickTimeファイルフォーマットにおける Track header atomの構成を示す図で める。
[図 7]QuickTimeファイルフォーマットにおける Media atomの構成を示す図である。
[図 8]QuickTimeフアイノレフォーマットにおける Media information atomの構成を示す 図である。
[図 9]Sample table atomによるデータ管理の例を示す図である。
[図 10]QuickTimeファイルフォーマットにおける Sample table atomの構成を示す図で める。
[図 l l(a)]QuickTimeファイルフォーマットにおける Sample description atomの構成を 示す図である。
[図 l l(b)]Sound Sample description Tableの構成を示す図である。
[図 12]QuickTimeファイルフォーマットにおける Edit atomの構成を示す図である。 [図 13(a)]Edit atomによる再生範囲指定の例を示す図である。
[図 13(b)]Edit atomによる再生範囲指定の例を示す図である。
[図 13(c)]Edit atomによる再生範囲指定の例を示す図である。
[図 14]QuickTimeファイルフォーマットにおける User data atomの構成を示す図である
[図 15]AVストリームの構成を示す図である。
[図 16(a)]UDFにおける管理情報の関係を示す図である。
[図 16(b)]UDFにおける管理情報の関係を示す図である。
[図 17]本発明の第 1の実施例における、 QuickTimeファイルフォーマットにおける User data atomの構成を示す図である。
[図 18]本発明の実施の形態 1における、記録直後のオリジナルプログラムの管理情 報を示す図である。
[図 19(a)]本発明の実施の形態 1における、ユーザプログラム作成時の未割り当てトラ ックの変更を示す図である。
[図 19(b)]本発明の実施の形態 1における、ユーザプログラム作成時の未割り当てトラ ックの変更を示す図である。
[図 20]本発明の実施の形態 1における、ディスク上でのデータ配置とファイルとの関 係を示した図である。
[図 21]本発明の実施の形態 1における、ユーザプログラムの編集の例を示した図であ る。
[図 22]本発明の実施の形態 1における、ユーザプログラム削除の処理の流れを示し たフローチャートである。
[図 23]本発明の実施の形態 1における、ユーザプログラムの削除直前の参照関係を 示した図である。
[図 24]本発明の実施の形態 1における、ユーザプログラムの削除直後の参照関係を 示した図である。
[図 25]本発明の実施の形態 2における、ディスク上でのデータの配置とファイルの関 係を示す図である。 [図 26]本発明の実施の形態 2における、ユーザプログラムの参照関係とインデックス フアイルとの関係を示した図である。
[図 27]従来技術におけるディスク上での記録形態を示す図である。
発明を実施するための最良の形態
[0020] 以下、本発明の実施形態について、図面を参照しながら詳細に説明する。ここでの 説明は、本発明において共通に用いる構成、個々の実施形態に固有の内容という順 に行っていく。
[0021] くシステム構成 >
図 2は、本実施の形態において共通に用いる、アフレコ可能なビデオディスクレコー ダの構成である。
[0022] このビデオディスクレコーダは、図 2に示すように、バス 100、ホスト CPU (Central Processing Unit) 101、 RAM (Random Access Memory) 102、 ROM (Read Only Memory) 103、ユーザインタフェース 104、システムクロック 105、光ディスク 106、ピ ックアップ 107、 ECC (Error Correcting Code)デコーダ 108、 ECCエンコーダ 109、 再生用バッファ 110、記録/アフレコ用バッファ 111、デマルチプレクサ 112、マルチ プレクサ 113、多重化用バッファ 114、オーディオデコーダ 115、ビデオデコーダ 11 6、オーディオエンコーダ 117、ビデオエンコーダ 118および図示されないカメラ、マ イク、スピーカ、ディスプレイ等で構成される。
[0023] ホスト CPU101は、バス 100を通じてデマルチプレクサ 112、マルチプレクサ 113、 ピックアップ 107、また図示していないが、オーディオデコーダ 115、ビデオデコーダ 116、オーディオエンコーダ 117、ビデオエンコーダ 118との通信を行う。
[0024] 再生時には、ピックアップ 107を通じて光ディスク 106から読み出されたデータは、 ECCデコーダ 108によって誤り訂正され、再生用バッファ 110にー且蓄えられる。デ マルチプレクサ 112は、オーディオデコーダ 115、ビデオデコーダ 116からのデータ 送信要求に従って、再生用バッファ 110中のデータをその種別によって適切なデコ ーダに振り分ける。
[0025] 一方、記録時には、オーディオエンコーダ 117とビデオエンコーダ 1 18によって圧 縮符号化されたデータは、マルチプレクサ 113を介して多重化用バッファ 1 14に一旦 送られ、さらに、マルチプレクサ 113によって AV多重化されて多重化用バッファ 114 力 記録/アフレコ用バッファ 111に送られる。記録/アフレコ用バッファ 111中のデ ータは、 ECCエンコーダ 109によって誤り訂正符号を付加され、ピックアップ 107を 通じて光ディスク 106に記録される。
[0026] オーディオデータの符号化方式には MPEG-I Layer_IIを、ビデオデータの符号ィ匕 方式には MPEG-2をそれぞれ用いることができる。
[0027] 光ディスク 106は、外周から内周に向かって螺旋状に記録再生の行われるものであ り、ビデオディスクレコーダに対して脱着可能な記録媒体とする。また、光ディスク 10 6は、 2048byteを 1セクタとし、誤り訂正のため 16セクタで ECCブロックを構成する。
ECCブロック中のデータを書き換える場合には、そのデータが含まれる ECCブロック 全体を読み込み、誤り訂正を行い、対象のデータを書き換え、再び誤り訂正符号を 付加し、 ECCブロックを構成して光ディスク 106に記録する必要がある。また、光ディ スク 106では、記録効率を上げるため ZCAV (ゾーン角速度一定）を採用しており、 記録領域は回転数の異なる複数のゾーンで構成される。
[0028]
本実施の形態に係るビデオディスクレコーダでは、光ディスク 106上の各種情報を 管理するためにファイルシステムを用い、このファイルシステムをデータ（アフレコデー タ、オーディオデータ、ビデオデータ）と共に光ディスク 106に記録する。ファイルシス テムには、パーソナルコンピュータ（以下、 PCと略称する）との相互運用を考慮して U DF (Universal Disk Format)を使用することができる。ファイルシステム上では、各種 管理情報や AVストリームはファイルとして扱われる。
[0029] ファイルシステムのユーザエリアは、 2048byteの論理ブロック (セクタと一対一に対 応)で管理される。ユーザエリア上の各ファイルは、整数個のエクステント (連続した論 理ブロック)で構成され、エクステント単位で分散して記録してもよい。ユーザエリア内 の空き領域は、 Space Bitmapを用いて論理ブロック単位で管理される。
[0030] <フアイノレフォーマット >
AVストリーム管理のためのフォーマットとして、ここでは QuickTimeファイルフォーマ ットを用レ、る。 QuickTimeファイルフォーマットとは、 Apple社が開発したマルチメディア データ管理用フォーマットであり、 PCの世界では広く用いられている。
[0031] QuickTimeファイルフォーマットは、ビデオデータやオーディオデータ等 (これらを総 称してメディアデータとも呼ぶ)と管理情報とで構成される。メディアデータと管理情報 とを合わせてここでは、 QuickTimeムービー (略してムービー)と呼ぶ。メディアデータと 管理情報とは、同じファイル中に存在しても、別々のファイルに存在してもよい。
[0032] メディアデータと管理情報とが同じファイル中に存在する場合は、図 3 (a)に示すよ うなファイル構成をとる。各種情報は atomという共通の構造に格納される。ファイル 20 1において、管理情報は Movie atomという構造に格納され、メディアデータの AVスト リームは Movie data atomとレ、う構造に格納される。また、 Movie data atomの最初には 、 Atom Header (AH)が配置される。尚、 Movie atom中の管理情報には、メディアデ ータ中の任意の時間に対応する AVストリームのファイル中での相対位置を導くため のテーブルや、メディアデータの属性情報や、後述する外部参照情報等が含まれて いる。
[0033] 一方、管理情報とメディアデータとを別々のファイルに格納した場合は、図 3 (b)に 示すような構成をとる。この場合、管理情報はファイル 202において Movie atomという 構造に格納されるが、 AVストリームは atomには格納される必要はなぐファイル 203 に格納される。このとき、 Movie atomは AVストリームを格納したファイル 203を「外部 参照」している、という。
[0034] 外部参照では、図 3 (c)に示すように、管理情報を格納する一つのファイル 204によ つて複数の AVストリームファイル（この図ではファイル 205 · 206)を参照することが可 能である。この仕組みにより、 AVストリーム自体を物理的に移動することなぐ見かけ 上編集を行ったように見せる、いわゆる「ノンリニア編集」「非破壊編集」が可能になる 。また、光ディスク 106上に記録した AVストリームの同一のシーンを使って複数のュ 一ザプログラムを作成することが可能であり、かつ、同一のアフレコデータを複数のュ 一ザプログラムにて参照することも可能である。
[0035] 次に、図 4ないし図 14を用いて、 QuickTimeの管理情報のフォーマットについて説 明する。まず、共通の情報格納フォーマットである atomについて説明する。 atomの先 頭には、その atomのサイズである Atom size,その atomの種別情報である Typeが必ず 存在する。 Typeは 4文字で区別され、例えば Movie atomでは' moov'、 Movie data atomでは mdat となってレヽる。
[0036] atom間には階層構造があり、各 atomは別の atomを含むことができる。 Movie atomの 構成を図 4に示す。 Movie header atomは、その Movie atomが管理するムービーの 全体的な属性を管理する。 Track atomは、そのムービーに含まれるビデオやオーデ ィォ等のトラックに関する情報を格納する。 User data atomは、ユーザが独自に定義 可能な atomである。
[0037] Track atomの構成を図 5に示す。 Track header atomはそのトラックの全体的な属性 を管理する。 Edit atomは、メディアデータのどの区間をムービーのどのタイミングで再 生するかを管理する。 Track reference atomは、別のトラックとの関係を管理する。
Media atomは、実際のビデオやオーディオといったデータを管理する。
[0038] Track header atomの構成を図 6に示す。ここでは、後での説明に必要なもののみ説 明する。 Flagsは属性を示すフラグの集合である。代表的なものとして、 Track enabled フラグがあり、このフラグ力 1 'であればそのトラックは再生され、 ' 0 'であれば再生さ れない。 Track IDはトラック固有の IDである。 Layerはそのトラックの空間的な優先度を 表しており、画像を表示するトラックが複数あれば、 Layerの値が小さいトラックほど画 像が前面に表示される。
[0039] Media atomの構成を図 7に示す。 Media header atomは、その Media atomの管理す るメディアデータに関する全体的な属性等を管理する。 Handler reference atomは、メ ディアデータをどのデコーダでデコードするかを示す情報を格納する。 Media information atomは、ビデオやオーディオ等のメディア固有の属性情報を管理する。
[0040] Media information atomの構成を図 8に示す。 Media information header atomは、ビ デォゃオーディオ等のメディア固有の属性情報を管理する。 Handler reference atom は、 Media atomの項で説明した通りである。 Data information atomは、その
QuickTimeムービーが参照するメディアデータを含むファイルの名前を管理する atom である Data reference atomを含む。 Sample table atomは、データのサイズや再生時 間等を管理している。
[0041] 次に Sample table atomにつレ、て説明する力 S、その前に、 QuickTimeにおけるデータ の管理方法について、図 9を用いて説明する。 QuickTimeでは、データの最小単位（ 例えばビデオフレーム)をサンプル（sample)と呼ぶ。個々のトラック毎に、サンプルに は再生時間順に 1から番号 (サンプル番号)がついている。
[0042] また、 QuickTimeフォーマットでは、個々のサンプルの再生時間長およびデータサ ィズを管理している。また、同一トラックに属するサンプルが再生時間順にファイル中 で連続的に配置された領域をチャンク（chunk)と呼ぶ。チャンクにも再生時間順に、 1 力、ら番号がついている。すなわち、 QuickTimeフォーマットでは、このようにチャンクが 連続して配置されることにより一つのファイル 901が形成される。
[0043] さらに、 QuickTimeフォーマットでは、個々のチャンクにおけるファイル先頭からのァ ドレスおよび個々のチャンクが含むサンプノレ数を管理している。これらの情報に基づ き、任意の時間に対応するサンプノレの位置を求めることが可能となっている。
[0044] Sample table atomの構成を図 10に示す。 Sample description atomは、個々のチヤ ンクのデータフォーマット (Data format)やサンプルが格納されてレ、るファイルのチャン クのインデックス等を管理する。さらに、 Sample description atomの構成を図 11 (a)に 示す。 number-of-entriesは使用されているデータフォーマットの数を表し、その数だ け Sample description table力ィ子 す 。図 11 (b)はォーティォの Sample description tableの例である。
[0045] 図 10の Sample table atomにおいて、 Time-to-sample atomは、個々のサンプルの 再生時間を管理する。 Sync sample atomは、個々のサンプルのうち、デコード開始可 能なサンプルを管理する。 Sample-to-chunk atomは、個々のチャンクに含まれるサン プル数を管理する。 Sample size atomは、個々のサンプルのサイズを管理する。
Chunk offset atomは、個々のチャンクのファイル先頭からのアドレスを管理する。
[0046] Edit atomは、図 12に示すように 1個の Edit list atomを含む。 Edit list atomは
Number of entriesで指定される個数分の、 Track duration, Media time, Media rateの 値の組 (エントリ)を持つ。各エントリは、トラック上で連続的に再生される区間に対応し 、そのトラック上での再生時間順に並んでレ、る。
[0047] Track durationは、そのエントリが管理する区間のトラック上での再生時間、 Media timeは、そのエントリが管理する区間の先頭に対応するメディアデータ上での位置、 Media rateは、そのエントリが管理する区間の再生スピードを表す。尚、 Media timeが の場合は、そのエントリの Track duration分、そのトラックでのサンプルの再生を 停止する。この区間のことを empty editと呼ぶ。
[0048] 図 13に Edit listの使用例を示す。ここでは、 Edit list atomの内容が図 13 (a)に示す 内容であり、さらにサンプルの構成が図 13 (b)に示す構成であるとする。尚、ここでは i番目のエントリの Track durationを D(i)、 Media timeを T(i)、 Media rateを R(i)として示し ている。このとき、実際のサンプルの再生は、図 13 (c)に示す順に行われる。このこと について簡単に説明する。
[0049] まず、エントリ #1は、 Track durationが 13000、 Media timeが 20000、 Media rateが 1で あるため、そのトラックの先頭から 13000の区間はサンプル中の時刻 20000から 33000 の区間を再生する。次に、エントリ #2は、 Track durationが 5000、 Media timeが— 1であ るため、トラック中の時刻 13000から 18000の区間、何も再生を行わなレ、。そして、ェン トリ #3は、 Track durationが 10000、 Media timeが 0、 Media rateが 1であるため、トラック 中の時刻 18000から 28000の区間において、サンプル中の時刻 0から 10000の区間を 再生する。
[0050] 図 14に、 User data atomの構成を示す。この atomには、 QuickTimeフォーマットで定 義されてなレ、独自の情報を任意個数格納することができる。 1個の独自情報は 1個の エントリで管理され、 1個のエントリは Atom sizeと Typeと User dataとで構成される。
Atom sizeはそのエントリ自体のサイズを表し、 Typeは独自情報をそれぞれ区別する ための識別情報、 User dataは実際のデータを表す。
[0051]
ディスク内に含まれる QuickTimeムービーを管理するため、インデックスファイルとい う特別な QuickTimeムービーファイルをディスク内に 1個置く。
[0052] インデックスファイルには、ディスク内のファイル (QuickTimeムービーや QuickTimeム 一ビーから参照されている静止画等)に関するサムネイルや各種属性が登録されて いる。各種属性の中には、そのファイルが外部参照されている回数を示す link count 力 Sある。
[0053] link countを参照することで、そのファイルを参照しているファイルがあるかどうかを 容易に知ることができ、他から参照されているファイルを不用意に削除してしまうこと を防ぐことができる。
[0054] く AVストリームの形態 >
AVストリームの形態を図 15に示す。 AVストリームは整数個の Continuous Unit (C U)で構成される。 CUはディスク上で連続的に記録される単位である。 CUの境界は ECCブロック境界と一致するようにストリームが構成されている。また CUは、一つの Post Record Unit (PRU)と整数個の Video Unit (VU)とで構成される。 VUは独立に 再生可能な単位であり、 VUの集合が前述のオリジナルブロックに対応する。 PRUは 前述のアフレコデータブロックに対応する。 PRUの領域サイズは、 CUの再生時間に オーディオの最大ビットレートをかけたものである。
[0055] くファイルシステムフォーマット〉
本発明の説明において用いるファイルシステムのフォーマットである、 UDF ( Universal Disk Format)について図 16を用いて説明する。図 16(a)に示すディレクトリ /ファイル構成を UDFで記録した例を図 16(b)に示す。図中の AVDP602は Anchor Volume Descriptor Pointerの略であり、 UDFの管理情報を探すためのエントリポイン トに相当し、通常 256セクタ目、 Nセクタ目、あるいは N— 256セクタ目（Nは最大論理 セクタ番号）に記録される。 VDS601は Volume Descriptor Sequenceの略であり、 UD Fが管理する領域であるボリュームに関する管理情報を記録する。ボリュームは一般 に一枚のディスクに 1個存在し、その中にパーティションを一般に 1個含む。 FSD60 3は File Set Descriptorの略であり、パーティションに 1個存在する。パーティションの 中での位置情報はパーティションの先頭からのセクタ番号に相当する論理ブロック番 号で示される。なお、 1個の論理ブロックは 1セクタに対応する。また、各パーティショ ンには図示しないが Space Bitmapと呼ばれる各論理ブロックがファイルにすでに割り 当てられているかそうでないかを示すテーブルが存在する。
[0056] FSD603は、ルートディレクトリの File Entry (FE)である FE604の位置情報（論理 ブロック番号と論理ブロック数で構成され extentと呼ばれる）を含む。 FEは、 extentの 集合を管理しており、 extentを書き換えたり、追加したり、削除することで、ファイルを 構成する実データの順番を変えたり、データを揷入したり削除したりすることが可能で ある。 FE604はルートディレクトリの直下のファイルやディレクトリの名称等を格納する File Identifier Descriptor (FID)の集合を格納する領域 605を管理する。領域 605中 の FID611、 FID612は、それぞれフアイノレ 621、ファイル 622のファイル名や extent の集合を管理する FE606、 FE608の位置情報を含む。 FE606はファイル 621の実 データを構成する領域である領域 607、領域 610を extentとして管理する。 FE608 はファイル 622の実データを構成する領域である領域 609を extentとして管理する。 このときファイル 621の実データにアクセスするためには、 AVDP602、 VDS601、 F SD603、 FE604、 FID611、 FE606、領域 607、領域 610の匿 (こリンクを迪つてレヽ けばよい。
[0057] 〔実施の形態 1〕
本発明の実施の形態 1について、図 1、図 17ないし図 24を用いて説明する。
[0058] ここでは、アフレコに関する処理を中心に説明し、オリジナルプログラムの AVストリ ームの処理については特に説明しない。
[0059] <初期記録時の処理 >
PRUはオリジナルプログラムの記録の際にアフレコデータ用として確保される領域 であり、 AVストリームの記録時にアフレコファイルが作成されて、この領域はダミーデ ータとして管理される。
[0060] オリジナルプログラムの管理情報内には、 PRU領域内のアフレコデータが記録され ていない領域を管理するための未割り当てトラックを作成し、初期記録の際は、 CU 単位の PRU領域を 1サンプルとしてすベての PRU領域についての位置、サイズ、時 間情報を管理する sample tableを作成する。この未割り当てトラックについては、 Track header atomの Track Enabledフラグを 0にセットし、再生対象ではないことを示 す。
[0061] <アフレコデータ記録時の処理 >
次に、オリジナルプログラムを外部参照したユーザプログラムを作成し、それにァフ レコデータを記録する際の手順を説明する。ここでは、作成するユーザプログラムが、 オリジナルプログラムの一部を抜き出して再生するというものである場合を考える。
[0062] ユーザプログラムの作成は、オリジナルプログラムの管理情報力、ら AVストリームのト ラックのユーザが指定した区間の sample tableをコピーすればよい。
[0063] このユーザプログラムにアフレコデータを追加するときの処理について図 1に基づ いて説明する。まず、ユーザプログラムの QuickTime管理情報を RAM102に読み込 む。また、ユーザプログラムの管理情報の Data reference atomに記述されたファイル 名からオリジナルプログラムを特定し、参照先のオリジナルプログラムの QuickTime管 理情報も RAM102に読み込む（S1501)。
[0064] 次に、ユーザが指定した区間におけるアフレコデータを記録すべき PRUの位置を 、オリジナルプログラムの未割り当てトラックの sample tableから、アフレコ対象のビデ ォと時間的に対応する部分を探すことで特定する。そして、これから記録しょうとする アフレコがオーディオの場合、ビットレートからデータ量を計算し、未割り当てトラック で管理してレ、る PRUの size内に収まるかどうかを判定する（S 1502)。
[0065] また、アフレコがグラフィックの場合は、記録するグラフィックデータのサイズが PRU の size内に収まるかどうかを判定する。具体的には、アフレコデータは、 CU単位のス トリーム再生時間分ずつ、ディスク上に均等に配置されている PRU領域に分けて記 録されるため、ユーザが指定したアフレコ区間全ての PRU未割り当て領域の sizeを 調べて判定を行う。
[0066] アフレコデータを記録する領域が決定すれば、実際にその領域にアフレコデータを 記録する。
[0067] アフレコデータの記録が終了すると、次に、オリジナルプログラム側にアフレコした データを管理するトラックを新規に作成し (S 1503)、記録したアフレコデータを管理 する sample tableを作成する（S I 504)。
[0068] ここで、データの参照回数を管理するため、 Track atom中の User data atom( 'udta'
)内に、図 17に示すような、独自の Atom typeである reference management atom( ' rfmg を定 " 。この reference management atomの中に、丁' ~タ； 0、参照、されている 回数を示すフィールド 'ref_counter'を定義する。
[0069] すなわち、 Sample tableを作成した後、 User data atom内に上記 reference
management atomを作成し、 ref_counterフィーノレドに参照、回数 3 1回であること 表 1
' 1，をセットする（S1505)。 [0070] 次に、オリジナルプログラムの未割り当てトラックの sample tableの chunk offsetと size を、アフレコデータ記録後の PRUの残り領域に対応するよう更新する（S1506)。
[0071] 次に、記録したアフレコデータを再生するためのトラックをユーザプログラム側にも 新規に作成し、先程作成したオリジナルプログラムと同様、アフレコトラックの sample tableを作成する。
[0072] 最後に、 RAMI 02上のオリジナルプログラムおよびユーザプログラムの QuickTime 管理情報を光ディスク 106に記録する（S 1507)。
[0073] 上記フローにおいて、 S1502 S1506の処理は、図 2に示す構成のビデオデイス クレコーダでは、ホスト CPU101が、 RAM102内に読み込まれたオリジナルプログラ ムおよびユーザプログラムの QuickTime管理情報に対して行う。そして、 S1502—S1 506の処理が施されたオリジナルプログラムおよびユーザプログラムの QuickTime管 理情報が、ホスト CPU101に制御によって RAM102から読み出されバス 100および ピックアップ 107を介して光ディスク 106に書き込まれる。
[0074] 一方、 S 1502で未割り当て領域がな力 た場合、アフレコ用のビットレートを下げる ことで割り当てる領域のサイズを小さくし、割り当て領域があるかどうかを再度調べるよ うにすることができる。それでも未割り当て領域がなければ、 AVストリームの PRU領 域とは別の領域に記録を行うことも可能である。アフレコする区間について、部分的 に記録する領域がない場合、その区間のみ PRU領域とは別の領域に記録するよう にしても良い。
[0075] アフレコデータ記録後のオリジナルプログラムは図 18のようになる。アフレコが記録 された区間の PRUは、アフレコデータが記録された領域 (既割り当て領域)と未割り当 て領域で構成される。オリジナルプログラムの管理情報である Movie atomには Videoト ラック、 Main Audioトラック、アフレコトラック (図中 PR Audio),未割り当てトラックの 4つ のトラックがあり、それぞれのデータのアドレスやサイズ、再生時間等の情報を持つ。
[0076] 既にアフレコデータが記録されている後に別の種類のアフレコデータを追加すると きの処理も、新規にファイルを作成しないこと以外は同様である。図 19 (a)はアフレコ データ追加前の PRUの状態であり、図 19 (b)はアフレコデータ追加後の PRUの状 態を示す。図 19 (b)では、既に記録されているアフレコ #Aトラックの後ろに、追加され るアフレコデータ用に新規にアフレコ #Bトラックを作成し、アフレコデータ毎に 1トラッ クで管理を行う。 Chunk offsetの値は PRU中の新規アフレコデータ開始位置をセット する。図では既にあったアフレコデータのすぐ後に新しいアフレコデータを記録して いる力 未割り当て領域のどの位置でも記録を行って良レ、。新規データが追加される 度に、残り領域に応じて未害 ijり当てトラックの Chunk offsetおよび Sample sizeの更新を 行う。
[0077] また、ファイルシステム上では図 20に示すように、オリジナルブロックで 1ファイル（ス トリームファイル）、アフレコデータブロックで 1ファイル（アフレコファイル）の外部参照 フアイノレとして扱う。すなわち、アフレコファイル中に複数のアフレコデータが混在する 形になる。
[0078] アフレコファイル中に複数のアフレコデータが存在している場合でも、アフレコデー タの種類毎にトラックを分け、トラック毎に retcounterを持つことで、容易に参照回数 を管理すること力 Sできる。
[0079] <ユーザプログラム作成時の処理 >
次に、アフレコデータを持つユーザプログラムをさらに非破壊編集する場合の処理 を説明する。例えば図 21のようにユーザプログラム 1とユーザプログラム 2をつなぎ合 わせたユーザプログラム 3を作成するときを考える。
[0080] まず、ユーザプログラム 1および 2の管理情報を RAM102に読み込み、新たなユー ザプログラム 3として結合する。また、このユーザプログラム 3の Data reference atomに 記述された参照ファイル名からオリジナルプログラムを特定し、オリジナルプログラム に関する管理情報を RAM 102上に読み込む。
[0081] 次に、オリジナルプログラムの管理情報に関して、ユーザプログラム 3のアフレコトラ ックの chunk offset情報から、 offsetが同一のアフレコ済みサンプルをサーチすること で、複数あるアフレコデータの中からユーザプログラム 3が参照しているアフレコデー タを特定し、それにメ寸 J心する track atom内の udta atomの reference management atom i, rfmg' )にある red_counterを li曾やす。
[0082] 最後に、 RAMI 02上のオリジナルプログラムおよびユーザプログラム 3の管理情報 を光ディスク 106に記録する。 [0083] <ユーザプログラム削除時の処理 >
ユーザから、ユーザプログラムの削除が指示された場合の処理について図 22に沿 つて説明する。尚、はじめに削除指示されたユーザプログラムの管理情報を RAM10 2上に読み込んでおく。
[0084] まず、ユーザプログラムの管理情報中のトラックを調べ、そのユーザプログラムが参 照しているアフレコデータを管理しているオリジナルプログラムをリストアップする（S2 101)。アフレコデータを管理するトラックがない場合は処理を終了する。
[0085] 次に、リストアップした各オリジナルプログラムに関して、以下の処理を行う。まず、 オリジナルプログラムの管理情報を RAM102に読み込む。そして、ユーザプログラム のアフレコトラックの chunk offset情報からオリジナルプログラム内の対応するアフレコ トラックを検索し、検索されたトラックの ref_counterを 1減らす（S2102)。
[0086] ここで ref_counterが 0かどうかの判定を行い（S2103)、 0であれば、削除を行ってこ の部分の領域を開放し (S2104)、開放した領域を未割り当て領域に返却するように 、未割り当てトラックのサンプル管理情報の更新を行う（S2105)。また、オリジナルプ ログラムの管理情報から削除を行ったアフレコデータに対応する Track atomを削除 する（S2106)。この処理はアフレコデータ記録時の処理の逆に相当する。
[0087] 最後に、ユーザプログラムを格納しているファイルを光ディスク 106から削除し（S21 07)、オリジナルプログラムの管理情報を光ディスク 106に記録する（S2108)。
[0088] また、 S2103におレヽて、 ref_counterが 0でない場合には、上記アフレコデータを参 照している他のユーザプログラムを存在していることを示しているので、 S2104— 21 06の処理、すなわちアフレコデートの削除処理を行わずに S2107に移行する。
[0089] 例えば、図 23に示すような参照関係を持つファイルがあり、このうちユーザプロダラ ム 3を削除する場合を考える。ここでユーザプログラム 3においては、アフレコデータ A とアフレコデータ Bとが参照されている。ユーザプログラム 3を削除するにあたって、ァ フレコデータ Aおよびアフレコデータ Bの retcounter数を 1減らすと、図 24に示すよう に、アフレコデータ Aの retcounter数は 1になり、アフレコデータ
Bの retcounter数は 0になる。
[0090] すなわち、アフレコデータ Bはユーザプログラム 3にのみ参照されていたデータであ るため、ユーザプログラム 3と同時にアフレコデータ Bも削除される力 アフレコデータ Aは他のユーザプログラム力らも参照されている（ここでは、ユーザプログラム 2から参 照されてレ、る）ため削除されなレ、。
[0091] <実施の形態 1における変形例 >
本実施の形態 1では、 udta atom中に参照回数を示すフィールドを設けた力 S、本発 明はそれに限定されるものではない。
[0092] 例えば、この参照回数を示す情報を Sample description atom中の Sample
description table内に設けても良レ、。すなわち、アフレコデータ毎に Sample descriptionを作成するという方法である。これにより、アフレコデータ毎にトラックを分 割することを前提としなくても、 Sample description atomで管理可能であるため、管理 ファイルのデータ量の節約に繋がる。ただし、 QuickTimeでは、一つのトラックに再生 時間の重なるサンプノレを同時に置くことはできないため、その場合はトラックを分割す る必要がある。そうした場合でも、 Sample description table内に参照回数を示す情報 を持たせることで、より詳細にアフレコデータを管理することが可能になる。
[0093] 例えば、 1つのアフレコデータの前半と後半とで異なるコーデックが使われており、 Sample descriptionが分かれている場合などで、アフレコデータを記録したユーザプロ グラムを削除する場合、たとえ他のユーザプログラムからこのアフレコデータが参照さ れていたとしても、その参照範囲が前半部分のみであれば、後半部分のアフレコデ ータのみを削除して、そのデータが記録されていた領域を開放することができる。
[0094] ま 7こ、 reference management atom内におレヽて、 照回数の†青芊艮を不す ref— counter だけでなぐ参照しているユーザプログラムのファイル名の情報を持たせてもよい。こ れによって、ユーザによってアフレコデータの削除が指示された場合に、該アフレコ データが他のユーザプログラムファイルから参照されているか否かの情報の他に、ど のファイルから参照されているかをユーザに提示することが可能になる。
[0095] さらに、各ユーザプログラムからアフレコデータのどの部分が参照されているかを示 す参照範囲の情報を持たせることもできる。このような参照範囲情報により、アフレコ データ自体は複数のユーザプログラムから参照されてレ、ても要らなくなった部分のみ を削除できるため、より有効に PRU領域を活用することができる。 [0096] 〔実施の形態 2〕
次に、本発明の実施の形態 2について説明する。実施の形態 1と異なり、 たデータ毎にファイルを分けて管理する。尚、本実施の形態 2は上述の実施の形態 1 と類似するため、相違点に絞って説明する。
[0097] 先ず、アフレコデータが 2種類あるときのディスク上の配置とファイルの関係を図 25 に示す。光ディスク 106上の物理的な記録では、 CU毎にアフレコ—データブロックお よびオリジナルブロック（すなわちオリジナルオーディオブロックおよびオリジナルビデ ォブロック）が配置されており、アフレコデータブロックはアフレコデータ # Aを記録す る領域、アフレコデータ # Bを記録する領域、未割り当て領域からなっている。そして 、アフレコデータ # Aに係る各データはアフレコ Aファイルに、アフレコデータ # Bに 係る各データはアフレコ Bファイルに、未割り当て領域はダミーファイルにて管理され ている。
[0098] <初期記録時の処理 >
実施の形態 2における初期記録時の処理は、実施の形態 1と共通であるので、説明 を省略する。
[0099] <アフレコデータ記録時の処理 >
実施の形態 2におけるアフレコデータ記録時の処理を説明する。まず、アフレコデ ータを追加するユーザプログラムの QuickTime管理情報を RAM102に読み込み、ォ リジナルプログラムを特定してオリジナルプログラムの QuickTime管理情報を RAMI 02に読み込む。さらに、ファイルシステム管理情報を RAM102に読み込む。 PRUの 位置の特定とアフレコデータ記録領域判定は実施の形態 1と同じであるので説明を 省く。
[0100] 次に、アフレコデータをディスク上の PRU領域に記録し、新規にアフレコ用のフアイ ルを作成してファイルシステム管理情報を更新する。このとき、新規に作成したァフレ コデータのサイズに応じて未割り当て領域で構成されるダミーファイルのサイズを小さ くし、ファイルシステム管理情報を更新する。
[0101] 次に、オリジナルプログラムの QuickTime管理情報に関して、アフレコデータ用のト ラックを新規に作成し、ユーザが指定した区間の sample tableを作成し、 ref_counterフ ィールドに' 1，をセットする。また、 data reference atomには先程作成したアフレコファ ィル名をセットする。
[0102] 次に、オリジナルプログラムの未割り当てトラックの sample tableの chunk offsetと size を、アフレコデータ記録後の PRUの残り領域に対応するよう更新する。
[0103] 次に、ユーザプログラム側の管理情報に、先程作成したオリジナルプログラムのァ フレコトラックの sample tableをコピーする。
[0104] 最後に、 RAMI 02上のオリジナルプログラムおよびユーザプログラムの QuickTime 管理情報、及びファイルシステム管理情報を光ディスク 106に記録する。
[0105] 別の種類のアフレコデータを追加するときの処理も上記と同様である。すなわちァ フレコデータの種類の数だけファイルが作成される。
[0106] <ユーザプログラム作成時の処理 >
実施の形態 2では、複数のアフレコデータを持つオリジナルプログラムの中からュ 一ザプログラムが参照しているアフレコデータのトラックを特定する際、ユーザプログ ラムのアフレコトラックの Data reference atomに書かれているファイル名と同じファイル 名を参照してレ、るトラックをオリジナルプログラムの中からサーチする。オリジナルプロ グラムは、ユーザプログラムで参照するオーディオビデオファイルから特定する。それ 以外の処理は実施の形態 1と共通である。
[0107] <ユーザプログラム削除時の処理 >
実施の形態 2では、削除するユーザプログラムのアフレコデータ力 オリジナルプロ グラムのどのトラックで管理されているかを特定する際、上記ユーザプログラム作成時 の処理で説明したのと同様に、 data reference atomの参照ファイル名を用いて行う。
[0108] また、ユーザプログラムを削除することによって、 retcounterが 0になった場合、この アフレコデータを PRU領域から削除し、開放した領域を未割り当て領域に返却する が、 QuickTime管理情報の書き換えに加え、該アフレコデータのファイルも削除し、未 割り当て領域で構成されるダミーファイルのサイズを削除したファイルサイズに応じて 大きくし、ファイルシステム管理情報の更新をする。それ以外の処理は実施の形態 1 と共通である。
[0109] このように、実施の形態 1では、アフレコファイルのサイズとアドレスは常に変わらな いため、アフレコデータの削除が管理情報の書き換えのみで行うことができ、ファイル システムの書き換えを必要としないものの、アフレコデータを特定する際に、サンプル の chunk offset値からアフレコファイル中の特定データを探索せねばならなかった。
[0110] これに対し、本実施の形態 2によると、アフレコデータ毎にファイルが分かれている ため、 data reference atomの参照ファイル名から一発でアフレコデータを特定すること ができ、データの特定がより簡便に、より迅速に行うことができる。ただし、管理情報の 操作の他、ファイルシステムの操作も必要になる。
[0111]
<実施の形態 2における変形例 >
実施の形態 2では、オリジナルプログラムの管理情報内で、アフレコデータの種類 毎にトラックを分け、その中で参照回数を管理していたが、ディスク上に 1個存在する 管理情報ファイルであるインデックスファイル内にて管理する構成であっても良レ、。こ の場合、図 26に示すように、ファイル名などのアフレコデータファイルを特定するため の情報と参照回数情報を関連つけて管理する。
[0112] 尚、上記実施の形態 1および 2において、用いられる記録媒体は光ディスクとしたが 、本発明を適用できる記録媒体は光ディスクに限定されるものではなぐランダムァク セス可能な記録媒体 (例えばハードディスク）であればょレ、。
[0113] 以上のように、本発明のデータ記録方法は、記録媒体に、 AVデータと、該 AVデー タと同期するアフレコデータとを記録するデータ記録方法であって、記録媒体上に、 AVデータの同一のシーンを使って複数のユーザプログラムを作成可能であり、かつ 、アフレコデータが複数のユーザプ ログラムから参照可能であり、ユーザプログラムとアフレコデータとの関係を管理する 管理情報を上記記録媒体上に記録することを特徴としている。
[0114] 上記の構成によれば、記録媒体に、 AVデータと、該 AVデータと同期するアフレコ データと記録するにあたって、記録媒体上に、 AVデータの同一のシーンを使って複 数のユーザプログラムを作成可能であり、かつ、アフレコデータが複数のユーザプロ グラムから参照可能となっている。
[0115] このため、例えば、あるユーザプログラムを削除するにあたって、この削除されるュ 一ザプログラムで参照されているアフレコデータを併せて削除しょうとする場合には、 削除されるべきアフレコデータは削除されるユーザプログラムのみで参照されるもの であることを確認することが必要となる力 S、このような確認が上記管理情報によって容 易に行える。
[0116] また、上記データ記録方法では、上記アフレコデータは、複数のユーザプログラム において参照されるアフレコデータ群を含む領域中の部分領域であり、前記領域は ひとつのアフレコファイルとして記録されており、上記管理情報は、オリジナルプログ ラムに対して 1つ存在する管理情報ファイル中にアフレコデータ毎に記録される構成 とすることができる。
[0117] また、上記データ記録方法では、上記アフレコデータは、同一のユーザプログラム において参照されるアフレコデータ群ごとにアフレコファイルとして記録されており、 上記管理情報は、複数のオリジナルプログラムに対して 1つ存在する管理情報フアイ ル中にアフレコファイル毎に記録される構成とすることができる。
[0118] 上記の構成によれば、アフレコファイルのサイズとアドレスとが常に変わらないような 管理が可能であり、アフレコデータの削除が管理情報の書き換えのみで行うことがで きるため、ファイルシステムの書き換えを必要としない。
[0119] また、上記データ記録方法では、上記アフレコデータは、同一のユーザプログラム において参照されるアフレコデータ群ごとにアフレコファイルとして記録されており、 上記管理情報は、オリジナルプログラムに対して 1つ存在する管理情報ファイル中に アフレコファイル毎に記録される構成とすることができる。
[0120] 上記の構成によれば、アフレコデータ毎にアフレコファイルが分かれているため、ァ フレコデータを特定する際、データのオフセットなどから検索しなくとも、各アフレコフ アイルの参照ファイル名から即座に特定できるため、データの特定がより簡便に、より 迅速に行うことができる。
[0121] また、上記データ記録方法では、上記管理情報は、アフレコデータが複数のユー ザプログラムから参照されている場合における参照回数を含む構成とすることができ る。
[0122] 上記の構成によれば、例えば、あるユーザプログラムを削除するにあたって、この削 除されるユーザプログラムで参照されているアフレコデータにおいて、該アフレコデ ータがユーザプログラムから参照されている参照回数が 1減らされる。そして、この参 照回数を減らす処理によって参照回数が 0となったアフレコデータは、削除されるュ 一ザプログラムのみで参照されるものであることが容易に確認できる。
[0123] また、上記データ記録方法では、上記管理情報は、アフレコデータを参照している ユーザプログラム名を含む構成とすることができる。
[0124] 上記の構成によれば、あるユーザプログラムを削除するにあたって、この削除される ユーザプログラムで参照されているアフレコデータの削除が指示された場合に、該ァ フレコデータが他のユーザプログラムファイル力、ら参照されているか否かの情報の他 に、どのファイルから参照されているかをユーザに提示することができる。
[0125] また、上記データ記録方法では、上記管理情報は、ユーザプログラムによって参照 されているアフレコデータの参照範囲の情報を含む構成とすることができる。
[0126] 上記の構成によれば、各ユーザプログラムからアフレコデータのどの部分が参照さ れているかを示す参照範囲の情報を持たせることで、このような参照範囲情報により 、アフレコデータ自体は複数のユーザプログラムから参照されてレ、ても要らなくなった 部分のみを削除できるため、より有効に記録媒体の記録領域を活用することができる
産業上の利用の可能性
[0127] 映像データ、音声データをハードディスク、光ディスク等のランダムアクセス可能な 記録媒体に対して記録 ·再生するデータ記録方法及びデータ記録装置において、ュ 一ザプログラムの削除時、該ユーザプログラムにおいて参照していたアフレコデータ が削除可能であるか否かの判断を容易にすることができる。

Claims

請求の範囲
[1] 記録媒体に、 AVデータと、該 AVデータと同期するアフレコデータとを記録するデ ータ記録方法であって、
記録媒体上に、 AVデータの同一のシーンを使って複数のユーザプログラムを作成 可能であり、かつ、アフレコデータが複数のユーザプ
ログラムから参照可能であり、
ユーザプログラムとアフレコデータとの関係を管理する管理情報を上記記録媒体上 に記録するデータ記録方法。
[2] 上記アフレコデータは、複数のユーザプログラムにおいて参照されるアフレコデー タ群を含む領域中の部分領域であり、前記領域はひとつのアフレコファイルとして記 録されており、
上記管理情報は、オリジナルプログラムに対して 1つ存在する管理情報ファイル中 にアフレコデータ毎に記録される請求の範囲第 1項に記載のデータ記録方法。
[3] 上記アフレコデータは、同一のユーザプログラムにおいて参照されるアフレコデー タ群ごとにアフレコファイルとして記録されており、
上記管理情報は、複数の
オリジナルプログラムに対して 1つ存在する管理情報ファイル中にアフレコファイル毎 に記録される請求の範囲第 1項に記載のデータ記録方法。
[4] 上記アフレコデータは、同一のユーザプログラムにおいて参照されるアフレコデー タ群ごとにアフレコファイルとして記録されており、
上記管理情報は、オリジナルプログラムに対して 1つ存在する
管理情報ファイル中にアフレコファイル毎に記録される請求の範囲第 1項に記載のデ ータ記録方法。
[5] 上記管理情報は、アフレコデータが複数のユーザプログラムから参照されている場 合における参照回数を含む請求の範囲第 1項に記載のデータ記録方法。
[6] 上記管理情報は、アフレコデータを参照しているユーザプログラム名を含む請求の 範囲第 1項に記載のデータ記録方法。
[7] 上記管理情報は、ユーザプログラムによって参照されているアフレコデータの参照 範囲の情報を含む請求の範囲第 1項に記載のデータ記録方法。
[8] 記録媒体に、 AVデータと、該 AVデータと同期するアフレコデータとを記録するデ ータ記録装置であって、
記録媒体上に、 AVデータの同一のシーンを使って複数のユーザプログラムを作成 可能であり、かつ、アフレコデータが複数のユーザプログラムから参照可能であり、 ユーザプログラムとアフレコデータとの参照関係を管理する管理情報を上記記録媒 体上に記録するデータ記録装置。
[9] AVデータと、該 AVデータと同期するアフレコデータとが記録されたデータ記録媒 体であって、
記録媒体上に記録した AVデータの同一のシーンを使って作成された複数のユー ザプログラム力 複数のユーザプログラムによって同一のアフレコデータを参照可能 とするように記録されており、
さらに、ユーザプログラムとアフレコデータとの参照関係を管理する管理情報が記 録されてレ、るデータ記録媒体。
PCT/JP2004/006970 2003-06-06 2004-05-21 データ記録方法、データ記録装置、およびデータ記録媒体 Ceased WO2004109697A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US10/559,695 US7835614B2 (en) 2003-06-06 2004-05-21 Data recording method, data recording apparatus, and data recording medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2003162928A JP3895305B2 (ja) 2003-06-06 2003-06-06 データ記録方法、データ記録装置、およびデータ記録媒体
JP2003-162928 2003-06-06

Publications (1)

Publication Number Publication Date
WO2004109697A1 true WO2004109697A1 (ja) 2004-12-16

Family

ID=33508683

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2004/006970 Ceased WO2004109697A1 (ja) 2003-06-06 2004-05-21 データ記録方法、データ記録装置、およびデータ記録媒体

Country Status (3)

Country Link
US (1) US7835614B2 (ja)
JP (1) JP3895305B2 (ja)
WO (1) WO2004109697A1 (ja)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005347787A (ja) * 2004-05-31 2005-12-15 Toshiba Corp 情報記録装置及び情報記録方法
JP4081772B2 (ja) * 2005-08-25 2008-04-30 ソニー株式会社 再生装置および再生方法、プログラム、並びにプログラム格納媒体
JP4991034B2 (ja) * 2005-11-04 2012-08-01 エルジー エレクトロニクス インコーポレイティド モバイル通信ターミナル及びモバイル通信ターミナルのメディア再生時間を計算する方法
JP2010503266A (ja) * 2006-08-29 2010-01-28 トムソン ライセンシング 喪失パケットを有するコンテナファイルに含まれるサンプルを修復するための方法及び装置
US8331448B2 (en) * 2006-12-22 2012-12-11 Qualcomm Incorporated Systems and methods for efficient spatial intra predictabilty determination (or assessment)
US9098370B2 (en) * 2010-11-08 2015-08-04 Cbs Interactive, Inc. Apparatus and methods for improving uninstall process

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11134233A (ja) * 1997-10-31 1999-05-21 Nippon Steel Corp フォルダ共有化装置及びフォルダ共有化方法
WO1999040586A1 (fr) * 1998-02-03 1999-08-12 Sanyo Electric Co., Ltd. Dispositif d'enregistrement d'informations, procede d'enregistrement et supports d'enregistrement
JP2002373480A (ja) * 2001-06-14 2002-12-26 Sharp Corp データ記録方法及びデータ記録装置ならびに記録媒体
JP2003169292A (ja) * 2001-11-30 2003-06-13 Victor Co Of Japan Ltd アフレコ装置、コンピュータプログラム、記録媒体、伝送方法及び再生装置
JP2004120099A (ja) * 2002-09-24 2004-04-15 Sony Corp 情報処理装置および方法、プログラム、並びに記録媒体

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ES2372593T3 (es) * 1999-07-29 2012-01-24 Sharp Kabushiki Kaisha Método de determinación de una posición de acceso sobre un medio de grabación y método de gestión del medio de grabación.
JP4250328B2 (ja) 2000-12-06 2009-04-08 キヤノン株式会社 記録装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11134233A (ja) * 1997-10-31 1999-05-21 Nippon Steel Corp フォルダ共有化装置及びフォルダ共有化方法
WO1999040586A1 (fr) * 1998-02-03 1999-08-12 Sanyo Electric Co., Ltd. Dispositif d'enregistrement d'informations, procede d'enregistrement et supports d'enregistrement
JP2002373480A (ja) * 2001-06-14 2002-12-26 Sharp Corp データ記録方法及びデータ記録装置ならびに記録媒体
JP2003169292A (ja) * 2001-11-30 2003-06-13 Victor Co Of Japan Ltd アフレコ装置、コンピュータプログラム、記録媒体、伝送方法及び再生装置
JP2004120099A (ja) * 2002-09-24 2004-04-15 Sony Corp 情報処理装置および方法、プログラム、並びに記録媒体

Also Published As

Publication number Publication date
JP2004362719A (ja) 2004-12-24
US7835614B2 (en) 2010-11-16
JP3895305B2 (ja) 2007-03-22
US20060120687A1 (en) 2006-06-08

Similar Documents

Publication Publication Date Title
JP5079757B2 (ja) データ記録方法、データ削除方法、記録装置、記録媒体およびプログラム
JP3847751B2 (ja) データ記録方法、データ記録装置、データ記録媒体、データ再生方法及びデータ再生装置
US20060110111A1 (en) Editing of real time information on a record carrier
US20010043805A1 (en) Optical disc recording apparatus, computer-readable recording medium recording a file management program, and optical disc
JP3895305B2 (ja) データ記録方法、データ記録装置、およびデータ記録媒体
JPWO2002104016A1 (ja) データ記録方法、データ編集方法およびデータ復号方法、並びにその装置
JP3986973B2 (ja) Ａｖデータ記録方法、ａｖデータ記録装置、データ記録媒体、及びプログラム
JP4549855B2 (ja) データ記録方法、データ再生方法、データ記録装置、データ再生装置、データ構造、プログラム、およびそのプログラムを格納した記録媒体
JP2002373480A (ja) データ記録方法及びデータ記録装置ならびに記録媒体
KR100625406B1 (ko) 데이터 처리 장치
WO2003044798A1 (en) Information recording apparatus, method, information reproduction apparatus, and method
JP4255796B2 (ja) データ記録装置、データ記録方法、データ記録プログラム、および該プログラムを記録した記録媒体
JP4409588B2 (ja) データ記録方法、データ削除方法、記録装置、記録媒体およびプログラム
JP2003168283A (ja) データ編集方法およびデータ記録媒体
JP4312783B2 (ja) Ａｖデータ再生方法、ａｖデータ再生装置、プログラム、並びに記録媒体
JP2003168284A (ja) データ記録方法およびデータ編集方法

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
ENP Entry into the national phase

Ref document number: 2006120687

Country of ref document: US

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 10559695

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 10559695

Country of ref document: US

122 Ep: pct application non-entry in european phase