CN101964914A - 信息记录装置以及信息记录方法 - Google Patents

Abstract

本发明所涉及的信息记录介质，记录以部分区间构成的作为AV内容的标题，所述部分区间是指数字流的一部分或全部，在该信息记录介质中记录有：播放列表，具有信息，该信息通过指定数字流中的部分区间的位置和再生顺序，从而确定标题；程序，通过调用播放列表来控制标题的再生；“Index”包括被对应起来用于识别菜单的“TopMenu”和用于识别程序的“ProgramIDRef”；以及“Extension”包含被对应起来的“TopMenu”和“PlayListID”。

Description

信息记录装置以及信息记录方法

本申请为申请号200680027152.4、国际申请号PCT/JP2006/314526、国际申请日为2006年7月21日、进入中国国家阶段日期为2008年1月24日、发明名称为“信息记录介质、记录装置、以及记录方法”的申请的分案申请。

技术领域

本发明涉及记录影像数据的信息记录介质、记录装置以及记录方法，且所述影像数据是以被附加了菜单的形式被记录的，所述菜单用于使用户指示再生记录的影像数据。

背景技术

作为记录了图像数据的信息记录介质的代表有DVD(以下称为“Standard Difinition(SD：标准清晰度)-DVD”)。以下，对以往的DVD进行说明。

图1是SD-DVD的结构图。如图1下侧所示，DVD盘从读入(read-in)区到读出(read-out)区之间存在逻辑地址空间。在逻辑地址空间中，开头记录有文件系统的容量信息，接着记录有图像或声音等的应用数据(application data)。

所谓文件系统是指，管理由ISO9660或通用光盘格式(Universal Disc Format：UDF)等标准所规定的数据的结构，是以被称为目录或文件的单位来表示的结构。

即使在日常所使用的个人电脑(PC)的情况下，也由被称为文件分配表(File Allocation Tables：FAT)或新技术文件系统(NT File System：NTFS)的文件系统，以目录或文件的结构使被记录在硬盘上的数据表示在计算机上，从而提高了可用性。

在SD-DVD的情况下，使用UDF及ISO9660这两个文件系统。将这两个文件系统称为“UDF网桥”。无论根据UDF及ISO9660的哪一文件系统驱动程序都能读出被记录的数据。并且，在此所使用的DVD是包介质使用的ROM盘，不能进行物理上的写入。

记录在DVD的数据通过UDF网桥，作为如图1左上部所示的目录或者文件而存在。根目录(图1的“ROOT”)的正下面被放置称为“VIDEO_TS”的目录，这里记录有DVD的应用数据。应用数据作为多个文件被记录，作为主要的文件有以下的种类。

VIDEO_TS.IFO盘再生控制信息文件

VTS_01_0.IFO视频标题集#1再生控制信息文件

VTS_01_0.VOB视频标题集#1流文件

.....

如以上的例子所示规定有两个扩展名。“IFO”是表示记录了再生控制信息的文件的扩展名，“VOB”是表示记录了作为AV数据的MPEG流的文件的扩展名。

再生控制信息是包含以下信息的信息，即为了实现在DVD所采用的交互性(按照用户操作使再生状态动态变化的技术)的信息，以及像元数据这样的附属在AV数据的信息等。并且，在DVD中再生控制信息一般被称为导航信息。

作为再生控制信息文件有：管理盘全体的“VIDEO_TS.IFO”和各个视频标题集的再生控制信息的“VTS_01_0.IFO”。并且，在DVD的一张盘上可记录多个标题，换句话说在DVD的一张盘上可记录内容不同的电影或乐曲。

在此，文件名中的“01”表示视频标题集的号码，例如，在视频标题集#2的情况下，则成为“VTS_02_0.IFO”。

图1右上部示出在DVD的应用软件层的DVD导航空间，即上述的再生控制信息被展开了的逻辑结构空间。“VIDEO_TS.IFO”中的信息作为“VIDEOManager Information(VMGI)：视频管理器信息”、“VTS_01_0.IFO”或其它的各个视频标题集中存在的再生控制信息作为“Video Title Set Information(VTSI)：视频标题组信息”被展开在DVD导航空间。

在VTSI中描述有被称为“Program Chain(PGC)：程序链”的再生序列的信息，即“Program Chain Information(PGCI)：程序链信息”。PGCI由单元(Cell)的集合和称为指令的一种编程信息所构成。

单元(Cell)本身是指定VOB(VOB是Video Object的略称，指向MPEG流)的一部分区间或全部区间的信息，单元(Cell)的再生是指，再生由该VOB的单元(Cell)指定的区间。

指令是由DVD的假想机器所处理的指令，例如与表示网页的浏览器上所执行的Java(注册商标)脚本语言(script)等相近。然而，Java(注册商标)脚本语言与DVD的指令不同之处是：Java(注册商标)脚本语言除了进行逻辑运算以外还可以进行窗口和浏览器的控制(例如，打开新的浏览器的窗口等)，而DVD的指令除进行逻辑运算以外还进行AV标题的再生控制，例如执行再生的区间(chapter)的指定等。

单元(Cell)具有内部信息，该内部信息是指盘上所记录的VOB的开始以及结束的地址(逻辑地址)，播放器使用单元(Cell)中所描述的VOB的开始以及结束的地址信息，读出数据并再生。

图2是用于说明被嵌入在AV数据即MPEG流中的导航信息的概略图。

在SD-DVD中具有特征性的交互性，不是只根据记录在上述“VIDEO_TS.IFO”或“VTS_01_0.IFO”等的导航信息才实现的，而是几个重要的信息利用被称为导航信息包(导航包或NV_PCK)的专用载体，在VOB内和影像、声音数据一起被多路复用。

在这里作为简单的交互性的例子，对菜单画面进行说明。在菜单画面上有几个按钮，每个按钮被定义有当选择并执行此按钮时的处理。

首先，在菜单画面上选择一个按钮(选择按钮上的半透明色表示该按钮以高亮(highlight)被变为半透明，并向用户表示该按钮为已被选择的状态)，用户可以使用遥控器的上下左右键来对按钮中的某一个进行上下左右的选择。

使用遥控器的上下左右键，使高亮移动到想要选择并打算执行的按钮，通过决定(按下决定键)，从而对应的指令的程序被执行。一般，标题和章节的再生是根据指令来执行的(例如，参照专利文献1)。

图2左上部示出在NV_PCK内所存储的信息的概要。NV_PCK内中包含高亮颜色信息和各个按钮信息等。高亮颜色信息中记录有调色板信息，指定被覆盖显示了的高亮的半透明颜色。

按钮信息内描述有以下信息：作为各个按钮位置信息的矩形区域信息，从某个按钮移至其他按钮的移动信息(通过用户选择遥控器的上下左右键，来指定想要移动到的按钮)，以及按钮指令信息(该按钮被选择时所执行的指令)。

如图2中央右上部所示，菜单画面上的高亮被制作成覆盖图像。覆盖图像是指按钮信息的长方形区域信息中附加了调色板信息。将覆盖图像覆盖在图2右侧示出的背景图像上，并一起显示在画面上。

如以上所述，在DVD上实现了菜单画面。并且，关于为何使用NV_PCK将导航数据的一部分嵌入到流中，其理由将在以下说明。

也就是说，与流同步动态地更新菜单信息，即容易成为问题点的同步定时的处理也将不会成为问题，例如，在电影再生过程中的5到10分钟之间表示菜单画面也将不会成为问题。

并且，还有一个主要理由是，提高了用户的操作性，即在NV_PCK中存储有用于支援特殊再生的信息，在DVD再生时的快速播放或倒回等非通常情况再生时也可以将AV数据解码并使其再生等。

图3是DVD中VOB的构成概要图。如图所示，影像、声音、字幕等数据(图3的(1))根据MPEG系统(ISO/IEC13818-1)标准被分组以及成为数据包(图3的(2))，并分别被多路复用从而成为一个MPEG程序流(图3的(3))。

并且，如上所述含有用于实现交互性的按钮指令的NV_PCK，也与一起被多路复用。

MPEG系统中多路复用的特征在于，被多路复用的各个数据是按解码顺序排列的位元串，而被多路复用的数据之间，即影像、声音、字幕数据之间，并不一定是按再生顺序排列的，换句话说不一定是按解码顺序排列的位元串。

这是因为，MPEG系统流的解码器模型(一般被称为“System TargetDecoder”或者“STD”(参照图3(D)))，具有与各个基本流相对应的解码缓存器(decoder buffer)，到解码定时为暂时存储数据，该各个基本流是解开多路复用的数据之后的基本流。

此解码缓存器因各个基本流而大小不同，对于影像而言具有232kB，对于声音而言具有4kB，对于字幕而言具有52kB。

为此，向各个解码缓存器输入数据的定时也因各个基本流而不同，因此，表示作为MPEG系统流而形成位元串的顺序(解码)的定时也发生偏差。

即，与影像数据并列被多路复用的字幕数据，并非与影像数据在相同定时被解码。

以上所述的有关DVD的记述在以下专利文献2中有记载。

专利文献1日本专利申请平8-83478号公报

专利文献2日本专利第2813245号公报

在此，现在，将拍摄的影像等数字内容(以下简称为“内容”)依次记录到作为信息介质的所述DVD等盘中的各种摄像机记录器(以下简称为“摄像机”)已由众多制造厂商生产并被广泛普及。

并且，这些摄像机具有可以生成独自的菜单画面并写入到盘中的功能。此菜单画面以下称为“盘菜单”。

用户利用摄像机将影像记录到信息记录介质，在使用播放器再生此信息记录介质的情况下，可以看到此摄像机所生成的盘菜单。并且，可以从所述菜单中选择作为再生等对象的标题。

然而，在各个制造厂商所生产的各种摄像机中，盘菜单所涉及的各种文件的描述内容和结构等是不统一的。

即，将某制造厂商的摄像机所生成的盘菜单在其它制造厂商的摄像机中解释实质上是不可能的。

为此，例如，记录有某制造厂商的摄像机所拍摄的影像的盘被装入到其它厂商的摄像机，并被执行新的标题的追加等情况下，在该其它厂商的摄像机中则需要删除有关记录完毕的盘菜单的文件，并需要制作新的盘菜单。

在这样的情况下，在装入了盘的摄像机中则需要通过解析控制记录完毕的盘菜单的再生的程序等，来找出与所述盘菜单相关的各种文件，这是一个非常高度的解析工作。

为此，存在的问题是：从盘被装入后直到可以开始影像的记录等工作为止要花费较长的时间，而且实质上是不能找出所述的各种文件。

并且，在记录新的盘菜单之时，在不删除与已经存在的而又不需要的盘菜单相关的文件的情况下，不要的文件则被存储到盘中。这样，盘的可记录容量不但会减少，而且在使用此盘的记录装置以及再生装置中，有关文件管理的处理负担也会增加。

发明内容

因此，本发明鉴于上述以往的问题，目的在于提供一种信息记录介质、记录装置以及记录方法，在某记录装置上生成的菜单被记录到信息记录介质后，且此信息记录介质被装入到其它的记录装置的情况下，可以不产生在所述其它的记录装置中本来不需要的处理负担以及处理时间。

为了达成上述目的，本发明为一种信息记录方法，在编码影像信息之时，同时编码影像信息的附属信息，将信息记录到信息记录介质中，其特征在于，上述附属信息被附加于影像信息的各个图片中，在上述附属信息包含相同种类且精度不同的多个信息的情况下，将精度低的信息以比精度高的信息先被记录的记录顺序，来记录到上述信息记录介质中。

另外，本发明为一种信息记录装置，在编码影像信息之时，同时编码影像信息的附属信息，将信息记录到信息记录介质中，其特征在于，上述附属信息被附加于影像信息的各个图片中，上述信息记录装置具有记录单元，在上述附属信息包含相同种类且精度不同的多个信息的情况下，该记录单元将精度低的信息以比精度高的信息先被记录的记录顺序，记录到上述信息记录介质中。

并且，本发明的信息记录介质记录以数字流的部分区间构成的作为音视频内容的标题，所述数字流的部分区间是指数字流的一部分或全部，在该信息记录介质中记录有：播放列表，具有信息，该信息通过指定数字流中的部分区间的位置和再生顺序，从而确定所述标题；程序，通过调用所述播放列表来控制所述标题的再生；索引信息，包含被对应起来的标题识别信息和程序识别信息，所述标题识别信息识别所述标题，所述程序识别信息识别所述程序；以及扩展信息，包含被对应起来的所述标题识别信息和播放列表识别信息，所述播放列表识别信息识别所述播放列表。

据此，使用本发明的信息记录介质的记录装置在删除菜单(所述菜单是记录在信息记录介质中的标题之一)时，不是解析控制所述菜单的再生的程序，而是可以容易地确定所述菜单所关联的播放列表。

因此，例如在作为记录装置的电视摄影机中，在删除由其它的电视摄影机生成的、被记录在盘中的盘菜单时，可以确定并删除盘菜单所关联的播放列表。

并且，在所述删除中所涉及的工作中，不需要进行程序的解析等，就可以容易地确定应该删除的播放列表。即，在使用本发明的信息记录介质的记录装置中，可以不发生本来就不需要的处理负荷以及处理时间。

并且，本发明的记录装置，将数字流记录到所述信息记录介质中，在所述信息记录介质中记录有多个标题；所述多个标题中的一个是用户选择除该标题自身以外的标题时所使用的菜单；所述记录装置包括：播放列表确定单元，利用所述扩展信息中所包含的、所述菜单的标题识别信息所对应的所述播放列表识别信息，来确定由控制所述菜单的再生的程序调用的播放列表；菜单生成单元，生成新的菜单并记录到所述信息记录介质，从而代替所述菜单；以及删除单元，在所述菜单生成单元生成了所述新的菜单的情况下，删除所述播放列表确定单元确定的播放列表。

据此，本发明的记录装置可以容易地确定与标题相关联的播放列表，并可以删除该播放列表。

因此，例如，作为电视摄影机而实现了本发明的记录装置的情况下，可以容易地从由其它制造厂商的电视摄影机记录了盘菜单的DVD或半导体存储器等信息记录介质中，删除该盘菜单所关联的播放列表。

即，可以在删除不要的文件的基础之上，生成新的盘菜单，并记录到该信息记录介质中。并且，像这样，通过删除不要的文件，从而可以不必浪费该信息记录介质中能够记录的容量，并且可以抑制文件管理所涉及的处理负荷的增加。

并且，本发明不仅可以作为这样的信息记录装置来实现，也可以作为具有这样的信息记录装置所具备的特征性单元的集成电路来实现。这些特征性单元可以被单独地制成一个芯片，也可以将这些特征性单元中的一部分或全部制成一个芯片。

并且，本发明可以作为使这样的信息记录装置所具备的特征性单元作为步骤的记录方法来实现，也可以作为使计算机执行这些步骤的程序来实现。并且，不言而喻，像这样的程序也可以通过CD-ROM等记录介质或互联网等传输介质来分发。

并且，本发明可以作为从本发明的信息记录介质中读取信息并再生的再生装置来实现，也可以作为将这些再生装置所具备的特征性单元作为的步骤的再生方法来实现，还可以作为使计算机执行这些步骤的程序来实现。并且，不言而喻，这些程序可以通过CD-ROM等记录介质或互联网等传输介质来分发。

本发明可以提供一种信息记录介质、记录装置以及记录方法，在某记录装置上生成的菜单被记录到信息记录介质后，且此信息记录介质被装入到其它的记录装置的情况下，可以不产生在所述其它的记录装置中本来不需要的处理负担以及处理时间。

附图说明

图1是SD-DVD的结构示例图。

图2是用于说明被嵌入在作为AV数据的MPEG流中的导航信息的概略图。

图3是DVD中的VOB的构成概要图。

图4示出了BD-ROM的数据分层。

图5是记录在BD-ROM中的逻辑数据的结构图。

图6是再生BD-ROM的BD-ROM播放器的基本构成概要图。

图7是将图6所示的播放器的结构详细化后的方框图。

图8示出了BD-ROM的应用程序空间。

图9是MPEG流(VOB)的构成图。

图10是MPEG流中包组件的构成图。

图11说明了AV数据和播放器构成的关系。

图12说明了使用轨道缓存的VOB数据的连续提供模型。

图13示出了VOB管理信息文件的内部结构。

图14说明了VOBU信息的详细细节。

图15说明了使用时间图(Time Map)的地址信息获得方法。

图16是播放列表信息的内部构成图。

图17示出了事件处理程序表。

图18是BD-ROM全体信息的构成图，即BD.INFO的构成图。

图19是全局事件处理程序表的构成图。

图20是时间事件的示例图。

图21示出了用户进行菜单操作时的用户事件的一个例子。

图22是全局事件的示例图。

图23是用于说明程序处理器的功能的构成图。

图24示出了系统参数(SPRM)的一览。

图25示出了控制具有2个选择按钮的菜单画面所涉及的事件处理中程序的一个例子。

图26示出了菜单选择的用户事件所涉及的事件处理中程序的一个例子。

图27是在BD-ROM播放器中AV数据再生的基本处理流程图。

图28是从在BD-ROM播放器的播放列表再生开始到VOB再生结束为止的处理流程图。

图29(A)是有关BD-ROM播放器的时间事件的处理流程图，(B)是有关BD-ROM播放器的用户事件的处理流程图。

图30是BD-ROM播放器的字幕数据的处理流程图。

图31是使用实施例2中的盘的记录器以及播放器所表示的菜单的示例图。

图32示出了实施例2中的BD.INFO的内容。

图33示出了实施例2中的BD.PROG的内容。

图34是有关菜单表示及标题再生的表示及工作的迁移的一个示例图。

图35(A)示出了在盘菜单的更新中怎样处理BD.INFO等各个文件，(B)说明了(A)所示出的号码的意思。

图36示出了BD.INFO的“Extension”中存储了用于指定播放列表的信息的状态。

图37示出了实施例2中盘菜单的更新前后的标题和播放列表(内容)的相关关系。

图38是实施例2的记录器的功能构成方框图。

图39是实施例2的记录器400的记录/编辑时更新标题构成时的工作流程图。

图40是实施例3中记录BD盘全体管理信息及Title信息的文件构成图。

图41是实施例3中记录存储程序的Object信息的文件构成图。

图42是实施例3中在BD-ROM的多路复用的示例图。

图43是实施例3中导航功能的页面数据结构图。

图44是实施例3中导航功能的按钮的数据结构图。

图45是实施例3中导航功能的示例图。

图46是实施例3中幻灯片模式(slideshow)功能的结构图。

图47(A)是实施例3中再生菜单的一个示例图，(B)是实施例3中的菜单画面迁移的示例图。

图48是实施例3中各Title所参照的播放列表以及存储对象信息的元数据的示例图。

图49是实施例4中将元数据存储到IndexExtensionData()的情况下的示例图。

图50是实施例4中Real PlayList(实际方案信息)以及VirtaulPlayList(虚拟方案信息)，和Shot(摄影或录像的影像单位)的关系的示例图。

图51是实施例4中表示Shot的开头的Mark和Shot的摄影顺序的关系的示例图。

图52(A)是实施例4中元数据的数据结构的一示例图，(B)是根据(A)所示出的元数据生成的Shot菜单的一个示例图。

图53是实施例5中将元数据的一部分存储到IndexExtensionData()的情况下的示例图。

图54是实施例5中将元数据的一部分存储到PlayListExtensionData()的情况下的示例图。

图55(A)是实施例5中元数据的数据结构的一示例图，(B)根据(A)所示出的元数据生成的Shot菜单的一个示例图。

图56是因影像的编辑而使摄影日期时间信息丢失的一个示例图。

图57示出了在实施例6中利用Mark编辑时保持摄影日期时间的方法。

图58是实施例7中元数据的存储位置的说明图。

图59是实施例7中元数据的数据结构的说明图。

图60是实施例7中元数据的识别信息(ID)和种类的说明图。

图61是实施例7中获得元数据的处理流程图。

图62是说明DV和EXIF持有同类信息的图。

图63是说明持有同类信息时的记录规则的图。

图64是BD-ROM盘中记录的流的数据结构的说明图。

图65是以往的幻灯片模式所涉及的数据结构的说明图。

图66是实施例8中幻灯片模式所涉及的数据结构的说明图。

图67是实施例8中Still Unit的数据结构的说明图。

图68是实施例8中利用了子图像(Subpicture)的静止图像幻灯片模式的说明图。

图69是实施例8中用于制作利用了子图像的静止图像幻灯片模式的处理流程图。

符号说明

1    BD-ROM播放器

2    音频专用播放器

104    BD-ROM

105    盘

202    光学拾波器

203    程序记录存储器

204    管理信息记录存储器

205    AV记录存储器

206    程序处理部

207    管理信息处理部

208    表示处理部

209    成像面(image plane)

210    视频面

211    合成处理部

302    程序处理器

303    UO管理器

305    方案处理器

306    表示控制器

307    时钟

308    图像存储器

309    轨道缓存

310    多路分配器

311    图像处理器

312    视频处理器

313    声音处理器

317    驱动控制器

400    记录器

401    播放列表指定部

402    删除部

403    菜单发生部

404    制造厂商判断部

405     接受部

406     编辑部

407     号码读出部

408     拍摄部

409     表示部

S801    记录/编辑开始步骤

S802    BD.INFO和BD.PROG读取步骤

S803    标题号码获得步骤

S804    关联文件更新步骤

S805    新标题号码附加步骤

S806    伪数据附加步骤

S807    更新完毕BD.INFO以及更新完毕BD.PROG写入步骤

具体实施方式

以下参照附图对本发明的实施例进行具体说明。

并且，与本申请的权利要求1所涉及的发明最接近的实施例为实施例2，为了便于理解，首先在实施例1对实施例2中的信息记录介质等基本构成加以说明。

(实施例1)

首先，利用图1到图30对再生BD(Blu-ray Disc：蓝光光碟)-ROM以及BD-ROM的BD-ROM播放器的基本构成以及工作进行说明。

(盘上的逻辑数据结构)

图4示出了BD-ROM的数据层。

如图4所示，在盘介质即BD-ROM104上记录有：AV数据103、有关AV数据的管理信息以及AV再生序列等的BD管理信息102、用于实现交互性的BD再生程序101。

并且，各个标题的实质数据为AV数据103，各个标题的方案控制描述数据(以下称为“方案”)为BD管理信息102。

并且，在本实施例中，是着眼于用于再生电影等AV内容的AV应用程序对BD-ROM进行说明的，当然，BD-ROM也可以像CD-ROM、DVD-ROM那样在可以用于计算机的记录介质上使用。

图5是所述BD-ROM104上记录的逻辑数据的结构图。BD-ROM104与其他的光盘一样，例如与DVD和CD等一样，从内圈到外圈具有螺旋状的记录区域，内圈的读入和外圈的读出之间具有能够记录逻辑数据的逻辑地址空间。

并且，在读入的内侧有一个被称为Burst Cutting Area(BCA)的只有驱动器才能够读出的特殊区域。由于这个区域不能由应用程序读出，因此，经常被用于著作权保护技术等。

在逻辑地址空间，记录有文件系统信息(容量)以及影像数据等的应用数据，且文件系统信息(容量)在开头。文件系统正如以往的技术中说明的那样，是由UDF或ISO9660等规格规定的管理数据的方法，可以利用目录、文件结构来读出与通常的个人电脑一样被记录的逻辑数据。

在本实施方式，在BD-ROM104上的目录及文件结构中，BDVIDEO目录被放置在根目录(ROOT)的正下面。此目录是记录有在BD-ROM上处理的AV数据或管理信息等数据(图4所示的BD再生程序101、BD管理信息102、AV数据103)的目录。

BDVIDEO目录下面记录有以下的7种文件。

BD.INFO(文件名固定)

“BD.INFO”文件是“BD管理信息”之一，是记录有与BD-ROM全体有关的信息的文件。BD-ROM播放器最先读出该文件。

BD.PROG(文件名固定)

“BD.PROG”文件是“BD再生程序”之一，是记录有与BD-ROM全体有关的程序的文件。

XXX.PL(“XXX”可变，扩展名“PL”固定)

XXX.PL是“BD管理信息”之一，是记录有播放列表(Play List)信息的文件，所述播放列表记录方案。每个播放列表持有一个文件。

XXX.PROG(“XXX”可变，扩展名“PROG”固定)

“XXX.PROG”文件是“BD再生程序”之一，是记录有所述每个播放列表的程序的文件。与播放列表的对应关系通过文件名(“XXX”一致)来识别。

YYY.VOB(“YYY”可变，扩展名“VOB”固定)

YYY.VOB文件是“AV数据”之一，是记录有VOB(与“背景技术”中说明的VOB相同)的文件。一个VOB与一个文件对应。

YYY.VOBI(“YYY”可变，扩展名“VOBI”固定)

“YYY.VOBI”文件是“BD管理信息”之一，是记录有与AV数据即VOB有关的管理信息的文件。与VOB的对应关系通过文件名(“YYY”一致)来识别。

ZZZ.PNG(“ZZZ”可变，扩展名“PNG”固定)

“ZZZ.PNG”文件是“AV数据”之一，是PNG(由World Wide Web Consortium(W3C)被标准化的图像格式，称为“png”)形式的图像文件，所述PNG是用于构成字幕和菜单画面的图像数据。一个PNG图像与一个文件对应。

(播放器的结构)

其次，利用图6及图7，对再生所述BD-ROM104的播放器的结构进行说明。

图6是再生BD-ROM104的BD-ROM播放器的基本结构的概略图。

在图6所示的BD-ROM播放器中，BD-ROM104上的数据是通过光学拾波器202被读出的。被读出的数据按照各自的数据种类被记录到专用的存储器。

BD再生程序(“BD.PROG”或“XXX.PROG”文件)被记录到程序记录存储器203，BD管理信息(“BD.INFO”、“XXX.PL”或“YYY.VOBI”文件)被记录到管理信息记录存储器204，AV数据(“YYY.VOB”或“ZZZ.PNG”文件)被记录到AV记录存储器205。

记录在程序记录存储器203的BD再生程序由程序处理部206来处理。记录在管理信息记录存储器204的BD管理信息由管理信息处理部207来处理。

并且，记录在AV记录存储器205的AV数据由表示处理部208来处理。

程序处理部206对程序进行处理，所述程序用于接收由管理信息处理部207再生的播放列表的信息或程序的执行定时等的事件信息。并且，可以动态地变更以程序再生的播放列表，在这种情况下，可以将变更后的播放列表的再生指令发送到管理信息处理部207。

程序处理部206还接受来自用户的事件，例如接受来自用户操作的遥控器的请求，当存在与该用户的事件对应的程序时，执行该程序。

管理信息处理部207接受程序处理部206的指示，并解析与该指示对应的播放列表以及与该播放列表对应的VOB管理信息。而且，指示表示处理部208使其再生作为再生对象的AV数据。

并且，管理信息处理部207从表示处理部208接受基准时刻信息，并根据时刻信息指示表示处理部208，使其停止AV数据的再生。并且，生成针对程序处理部206的事件，该事件示出程序执行的定时。

表示处理部208具有分别对应于影像、声音、字幕的解码器，按照来自管理信息处理部207的指示，进行AV数据的解码及输出。图像数据以及字幕数据被解码后被分别绘制在专用的平面。

具体而言，影像数据被绘制在视频面210，字幕数据等图像数据被绘制在成像面209。而且，被绘制在两个平面的影像的合成处理由合成处理部211来执行，并输出到TV等显示装置。

如图6所示，BD-ROM播放器的结构是根据图4所示的BD-ROM中所记录的数据结构而成的。

图7是将图6所示的播放器的结构详细化后的方框图。图6所示的各结构部和图7所示的各结构部的对应关系如以下所示。

AV记录存储器205与图像存储器308及轨道缓存309相对应。程序处理部206与程序处理器302及UO(User Operation)管理器303相对应。管理信息处理部207与方案处理器305及表示控制器306相对应。表示处理部208与时钟307、多路分配器310、图像处理器311、视频处理器312、及声音处理器313相对应。

从BD-ROM104所读出的VOB数据(MPEG流)被记录在轨道缓存309，图像数据(PNG)被记录在图像存储器308。

多路分配器310根据从时钟307得到的时刻，抽出轨道缓存309中记录的VOB数据。而且，将VOB数据中所包含的影像数据送入到视频处理器312，将声音数据送入到声音处理器313。

视频处理器312及声音处理器313按照MPEG系统标准的规定，分别以解码缓存器和解码器来构成。即从多路分配器310被发送来的影像及声音的数据，分别在解码缓存器被暂时记录，按照时钟307的时刻在对应的解码器进行解码处理。

记录在图像存储器308的PNG数据有以下两个处理方法。当PNG数据作为字幕用的数据的情况下，由表示控制器306指示解码定时。一旦方案处理器305接受了来自时钟307的时刻信息，当到了字幕表示时刻(开始及结束)时，就对表示控制器306发出字幕的表示或非表示的指示，从而进行适当地字幕表示。

从表示控制器306接受了解码/表示的指示的图像处理器311，从图像存储器308抽出对应的PNG数据进行解码，并绘制到成像面209。

并且，PNG数据用于菜单画面的情况下，由程序处理器302来指示解码定时。程序处理器302指示解码图像的时刻是不能一概而论的，要取决于程序处理器302处理的BD程序。

图像数据及影像数据如图6中的说明，分别被解码之后，被绘制到成像面209及视频面210，由合成处理部211进行合成之后输出。

从BD-ROM读出的管理信息(方案，AV管理信息)被记录到管理信息记录存储器204，方案信息(“BD.INFO”以及“XXX.PL”)由方案处理器305读出并被处理。并且，AV管理信息(“YYY.VOBI”)由表示控制器306读出并被处理。

方案处理器305解析播放列表的信息，将由播放列表参照的VOB及其再生位置指示给表示控制器306，表示控制器306解析成为对象的VOB的管理信息(“YYY.VOBI”)，并为了读出成为对象的VOB而向驱动控制器317发出指示。

驱动控制器317按照来自表示控制器306的指示，使光学拾波器移动，读出作为对象的AV数据。所读出的AV数据，如上所述被记录到图像存储器308或轨道缓存309。

并且，方案处理器305监视时钟307的时刻，在管理信息所设定的定时，向程序处理器302输出事件。

记录在程序记录存储器203的BD程序(“BD.PROG”或者“XXX.PROG”)，由程序处理器302来处理。程序处理器302在事件由方案处理器305发送来的情况下或者事件由UO管理器303发送来的情况下，处理BD程序。

UO管理器303，当用户通过遥控器键发来请求的情况下，生成与该请求相对应的事件并发送到程序处理器302。

通过这样的各结构部的工作而再生BD-ROM。

(应用程序空间)

图8是示出了BD-ROM的应用程序空间。

在BD-ROM的应用程序空间，播放列表(PlayList)是一个再生单位。播放列表具有：根据单元(Cell)的再生顺序而构成的静态方案，以及由程序所描述的动态方案。

在没有由程序描述的动态方案的情况下，播放列表只是按顺序再生各个单元，并且，在所有的单元再生结束时列表的再生也结束。

另外，程序可以按照超出播放列表的再生描述以及用户的选择或播放器的状态，来动态地改变再生对象。作为典型的例子可以举出通过菜单画面来进行再生对象的动态变更。在BD-ROM的情况下，菜单是指由用户选择的再生方案，即是用于动态选择播放列表的功能构成要素之一。

并且，在这里所说的程序，是根据时间事件或者用户事件所执行的事件处理程序。

时间事件是根据被嵌入到播放列表的时刻信息而生成的事件。从图7说明的方案处理器305发送到程序处理器302的事件相当于时间事件。当时间事件被发行时，程序处理器302根据ID执行所对应的事件处理程序。

如以上所述，被执行的程序可以指示其它的播放列表的再生，在这种情况下，目前被再生的播放列表的再生被中止，并迁移到被指定的播放列表的再生。

用户事件是由用户的遥控器键操作所生成的事件。用户事件分为两大类型。第一个是，根据遥控器所具有的光标键(“上”“下”“左”“右”键)或者“决定”键的操作而生成的菜单选择的事件。

菜单选择的事件所对应的事件处理程序仅在播放列表内的有限的期间内有效。即作为播放列表的信息设定了各个事件处理程序的有效期间。遥控器的“上”“下”“左”“右”键或者“决定”键被按下的情况下，程序处理器302检索有效的事件处理程序，当有效的事件处理程序存在时，则该事件处理程序被执行。在其它的情况下，菜单选择的事件被忽视。

第二个用户事件是根据“菜单”键的操作而生成的菜单画面呼叫的事件。当菜单画面呼叫的事件被生成时，则全局事件处理程序被呼出。

全局事件处理程序是不依存播放列表的、且总是有效的事件处理程序。通过使用此功能，可以安装DVD的菜单呼叫。通过安装菜单呼叫，从而呼出在标题再生中的声音、字幕菜单等，并可以执行在变更声音或字幕后的从中断处开始的标题再生。

作为在播放列表构成静态方案的单位即单元(Cell)，参照VOB(MPEG流)的全部或者一部分的再生区间。单元将VOB内的再生区间作为开始时刻及结束时刻的信息来保持。与各个VOB成为一组的VOB管理信息(VOBI)内部有时间图(Time Map或TM)，通过该时间图可以导出在VOB内(即成为对象的“YYY.VOB”内)的对所述VOB的再生及结束时刻的读出开始地址及结束地址。另外，有关时间图的详细细节以后将利用图14来说明。

(VOB的详细细节)

图9是在本实施例中使用MPEG流(VOB)的结构图。如图9所示，VOB由多个Video Object Unit(VOBU)构成。VOBU是以MPEG视频流的Group OfPictures(GOP)为基准的单位，且是也含有声音数据的多路复用流的一种再生单位。

VOBU持有0.4秒到1.0秒的再生时间，一般是持有0.5秒的再生时间。这是因为MPEG的GOP结构通常为15帧/秒(NTSC的情况)的缘故。

VOBU内部具有作为影像数据的视频包组件(V_PCK)和作为声音数据的音频包组件(A_PCK)。各包组件由1个扇区构成，在本实施例中是以2kB为单位构成的。

图10是MPEG流中包组件的构成示例图。

如图10所示，作为影像数据以及声音数据的基本数据被存入到被称为有效负载的数据包的数据存储区域中，且是从所述数据存储区域的开头开始按顺序被存入的。有效负载中被附加有数据包头，并构成一个数据包。

数据包中记录有：表示被存储在有效负载中的数据是哪个流的数据的信息；表示是影像数据还是声音数据的信息；当影像数据或声音数据分别具有多个流的情况下，用于识别是哪个流的数据的ID(stream_id)；以及作为该有效负载的解码和表示时刻信息的时间戳(即Decode Time Stamp(DTS)及Presentation Time Stamp(PTS))。

DTS以及PTS未必记录在所有的数据包头，而是由MPEG来制定记录规则。关于规则的详细细节，由于记述在MPEG系统(ISO/IEC13818-1)的规格书中，因此省略其说明。

再在数据包上附上头部(Pack Header：包组件头)，构成包组件(pack)。在该包组件头中记录有时间戳(即System Clock Reference(SCR：系统时钟基准))，该时间戳示出该包组件何时通过多路复用器，以及何时被输入到各个基本流的解码缓存器。

(VOB的交错记录)

其次，利用图11及图12，对VOB文件的交错记录进行说明。

图11是AV数据和BD-ROM播放器的结构的说明图。

图11上部是利用图7所述的播放器的结构图的一部分。如图所示，BD-ROM上的数据若是VOB即MPEG流，则通过光学拾波器被输入到轨道缓存309，若是PNG即图像数据则被输入到图像存储器308。

轨迹缓冲器309为First-In First-Out(FIFO)，被输入的VOB的数据按照输入的顺序被发送到多路分配器310。这个时候，各个包组件按照以上所述的SCR从轨道缓存309中被抽出，通过多路复用器310，被发送到视频处理器312或声音处理器313。

另一方面，在图像数据的情况下，对于要绘制哪个图像要由表示控制器306(参照图7)来指示。并且，对于在绘制中所使用的图像数据而言，在字幕用图像数据的情况下，同时从图像存储器308中删除，在菜单用图像数据的情况下，仍然保留在图像存储器内。

这是因为菜单的绘制要取决于用户的操作，因此，同一个图像可以绘制多次。

图11的下部是用于说明在BD-ROM上的VOB文件及PNG文件的交错记录的图。

一般来说ROM，例如CD-ROM和DVD-ROM中，作为一连串的连续再生单位的AV数据是连续被记录的。只要数据是连续记录的，驱动器就能依次读出数据，送到解码器里。

然而，应该连续再生的AV数据被割断并被分散地分配到盘上的情况下，在各个连续区间之间就会有查找操作介入，这样，在这之间数据的读出就会停止。即，数据的提供就会停止。

BD-ROM的情况也是同样，希望能够将VOB文件记录到连续的区域，例如像字幕数据那样，VOB中除有被记录的影像数据外同时还有被再生的数据，与VOB文件同样字幕数据也需要以某种方法从BD-ROM中读出。

作为字幕数据的读出方法之一，可在VOB的再生开始之前，一并读出字幕用的图像数据(PNG文件)。然而，在此情况下，在临时记录中需要使用大量的内存，在现实中是不可能的。

因此，本实施方式中将VOB文件分成几个块，采用了VOB文件与图像数据交错记录的方式。

图11下部就是用于说明该交错记录的图。通过对VOB文件和图像数据进行妥当地交错配置，从而不需要如上述的大容量的临时记录内存，可以在必要的时刻将图像数据存储到图像存储器。

然而，读出图像数据的时候，VOB数据的读取自然就会被停止。

图12是为了解决所述的交错记录中的问题，而利用轨道缓存309的VOB数据连续提供模式的说明图。

如上述说明，VOB的数据暂时先被存到轨道缓存309。将向轨道缓存309的数据输入速率设定为比来自轨道缓存309的数据输出速率高，只要继续从BD-ROM中读出数据，轨道缓存309的数据存储量就会增加。

在此，将向轨道缓存309的输入速率设为Va，将来自轨道缓存309的输出速率设为Vb。如图12的上部所示，设VOB的一连续记录区域从逻辑地址的“a1”持续到“a2”。并且，在逻辑地址“a2”到“a3”之间记录有图像数据，并将此区间作为不进行VOB数据的读出区间。

图12的下部示出了轨道缓存309的存储量。横轴示出时间，纵轴示出存储在轨道缓存309内部的数据量。时刻“t1”示出开始读出作为VOB的一连续记录区域的开始点的逻辑地址“a1”的时刻。

在此时刻以后，数据以(Va-Vb)的速率被存储到轨道缓存309。不言而喻，此速率为轨道缓存的输入速率与输出速率的差。时刻“t2”是读出作为一连续记录区域的结束点的逻辑地址“a2”的数据的时刻。

即时刻“t1”到“t2”之间轨道缓存内的数据量以速率Va-Vb来增加，时刻“t2”的数据存储量B(t2)可以通过以下的(公式1)来求出。

B(t2)＝(Va-Vb)×(t2-t1)    (公式1)

此后，由于到BD-ROM上的地址“a3”为止图像数据都会持续，向轨道缓存输入的数据是0，轨道缓存内的数据量以输出速率“-Vb”来减少。此数据量的减少将持续到读出位置“a3”，若从时刻上而言则是持续到“t3”。

在这里重要的是，时刻“t3”之前存储在轨道缓存的数据量一旦成为0，则向解码器提供的VOB的数据就没有了，可能会有VOB的再生停止。

然而，在时刻“t3”数据仍然存留在轨道缓存的情况下，VOB的再生就不会停止而继续进行。

此VOB的再生不停止而继续进行的条件可以用以下(公式2)来表示。

B(t2)≥-Vb×(t3-t2)    (公式2)

即，在满足(公式2)的条件下，只要决定图像数据的配置即可。

(导航数据结构)

利用图13至图19，来说明BD-ROM中所记录的导航数据(BD管理信息)的结构。

图13是示出VOB管理信息文件(“YYY.VOBI”)内部结构的图。

VOB管理信息具有，该VOB的流属性信息(Attribute)和时间图(TMAP)。流属性信息包含视频属性(Video)和音频属性(Audio#0～Audio#m)。特别对于音频流，由于VOB可以同时持有多个音频流，所以根据音频流的数(Number)，可以确定音频属性的数据域(data field)的数。

下列示出视频属性(Video)持有的多个域和各个域可持有的值。

压缩方式(Coding)：

MPEG1

MPEG2

MPEG4

分辨率(Resolution)：

1920x1080

1280x720

720x480

720x565

宽高比(Aspect)

4∶3

16∶9

帧速率(Framerate)

60

59.94

50

30

29.97

25

24

下列示出音频属性(Audio)持有的多个域和各个域的可持有的值。

压缩方式(Coding)：

AC3

MPEG1

MPEG2

LPCM

声道数(Ch)：

1～8

语言属性(Language)：

JPN、ENG、…

时间图(TMAP)是持有每个VOBU的信息的表，持有VOB所具有的VOBU的数(Number)和各VOBU信息(VOBU#1～VOBU#n)。

各个VOBU信息具有VOBU的再生时间长(Duration)和VOBU的数据大小(Size)。

图14是用于说明VOBU信息的详细细节的图。

正如普遍知道的那样，MPEG流具有关于两个物理量的侧面，这两个物理量的侧面是指时间上的侧面和数据大小的侧面。例如，作为声音的压缩标准的Audio Code number 3(AC3)是以固定的比特率来压缩的，因此时间和地址的关系可以根据一次公式来求出。

然而，在MPEG视频数据的情况下，各个帧持有固定的表示时间，例如在NTSC的情况下，1帧持有1/29.97秒的表示时间，而每个帧压缩后的数据大小根据画的特性或压缩中所使用的图片类型即I/P/B图片的类型，而数据大小发生相当大的变化。

因此，在MPEG视频的情况下，以一般公式的方式来表现时间和地址的关系是不可能的。

理所当然，对于多路复用MPEG视频数据而得到的MPEG流即VOB，同样以一般公式的方式来表现时间和数据大小的关系是不可能的。

取而代之的是以时间图(TMAP)来联结VOB内的时间和地址的关系。如图14所示，时间图(TMAP)是以VOBU为单位，将VOBU内的帧数和VOBU内的包组件数作为项目所持有的表。

用图15详细说明时间图(TMAP)的使用方法。

图15是用于说明使用了时间图的地址信息获得方法的图。

如图15所示，在给出时刻信息的情况下，首先检索该时刻属于哪个VOBU。具体而言，对时间图的各个VOBU的帧数进行相加，帧数的和超过将该时刻换算为帧数后的值或与该值一致的VOBU成为与该时刻所对应的VOBU。

其次，直至该VOBU之前的VOBU为止对时间图的各个VOBU的大小进行相加，相加后的值成为用于再生包含了给定时刻的帧而应该读出的包组件的先头的地址(Address)。

这样，在MPEG流中可以得到与给定的时刻信息相对应的地址。

其次用图16说明，播放列表(“XXX.PL”)的内部结构。

图16示出了播放列表的结构。

播放列表由单元列表(CellList)和事件列表(EventList)构成。

单元列表(CellList)是示出播放列表内的再生单元序列的信息，以单元列表的记述顺序再生单元。

单元列表(CellList)由单元的数(Number)和各单元信息(Cell#1～Cell#n)构成。

各单元信息(Cell#～Cell#n)持有：VOB文件名(VOBName)、在VOB内的有效区间开始时刻(In)及有效区间结束时刻(Out)、以及字幕表(SubtitleTable)。

有效区间开始时刻(In)及有效区间结束时刻(Out)，分别以在该VOB内的帧号码来表现，通过使用上述的时间图(TMAP)，从而能够得到再生所需的VOB数据的地址。

字幕表(SubtitleTable)是持有与该VOB同步再生的字幕信息的表。字幕与声音相同能持有多种语言，字幕表(SubtitleTable)由语言数(Number)和接着语言数的每个语言的表(Language#1～Language#k)构成。

各语言的表(Language#1～Language#k)包括：语言信息(Language)、被表示的字幕的字幕信息数(Number)、以及被表示的字幕的字幕信息(Speech#1～Speech#j)，各字幕信息(Speech#1～Speech#j)包括：对应的图像数据文件名(Name)、字幕表示开始时刻(In)及字幕表示结束时刻(Out)、以及字幕的表示位置(Position)。

事件列表(EventList)是定义了在该播放列表内发生的事件的表。事件列表由事件数(Number)之后所继续的各个的事件(Event#1～Event#m)构成，各个事件(Event#1～Event#m)包括：事件的种类(Type)、事件的标识符(ID)、事件发生时刻(Time)、以及有效期间(Duration)。

图17是持有各个播放列表的事件处理程序(时间事件和菜单选择用的用户事件)的事件处理程序表(“XXX.PROG”)的构成图。

事件处理程序表具有被定义的事件处理程序/程序的数(Number)，以及各个事件处理程序/程序(Program#1～Program#n)。

各个事件处理程序/程序(Program#1～Program#n)内的描述持有事件处理程序的ID(event_handler id)，该事件处理程序的ID中事件处理程序开始的定义(<event_handler>标签)和上述的事件的ID成为一对，之后该程序在“function”之后所继续的括弧“{”和“}”之间被描述。

其次，用图18说明与BD-ROM盘全体有关的信息(“BD.INFO”)的内部结构。

图18示出了作为BD-ROM全体信息的BD.INFO的结构。

BD-ROM全体信息由标题列表(TitleList)和全局事件用的事件列表(EventList)构成。

标题列表(TitleList)由盘内的标题数(Number)和接着标题数的各标题信息(Title#1～Title#n)构成。

各个标题信息(Title1～Title#n)包含：标题中所包含的播放列表的表(PLTable)和标题内的章节列表(ChapterList)。播放列表的表(PLTable)具有：标题内的播放列表的数(Number)和播放列表名(Name)即播放列表的文件名。

章节列表(ChapterList)包括该标题中所包含的章节数(Number)和各章节信息(Chapter#1～Chapter#n)，各章节信息(Chapter#1～Chapter#n)持有该章节所包含的单元的表(CellTable)，单元的表(CellTable)包括单元数(Number)和各单元的项目信息(CellEntry#1～CellEntry#k)。

单元的项目信息(CellEntry#)由包含该单元的播放列表名和在播放列表中的单元号码来描述。

事件列表(EventList)持有全局事件的数(Number)和各个全局事件的信息(Event#1～Event#m)。在此需要注意的是，最先被定义的全局事件被称为第一事件(FirstEvent)，是在BD-ROM被插入到播放器时，第一个被执行的事件。

各全局事件的信息(Event#1～Event#m)仅持有事件类型(Type)和事件的标识符(ID)。

图19示出了全局事件处理程序表(“BD.PROG”)。这个表与图17所说明的事件处理表的内容相同，在此省略其说明。

(事件发生的机理)

用图20至图22对事件发生的机理进行说明。

图20是示出时间事件的例子的图。

正如以上所述，时间事件由播放列表(“XXX.PL”)的事件列表(EventList)来定义。

作为时间事件被定义的事件，即事件类型(Type)为“TimeEvent”的情况下，当到了事件生成时刻(“t1”)，持有标识符“Ex1”的时间事件从方案处理器305被输出到程序处理器302。

程序处理器寻找持有事件标识符“Ex1”的事件处理程序，并执行成为对象的事件处理程序。例如，本实施例的情况下可以进行两个按钮图像的绘制等。

图21是用户进行菜单操作的用户事件的示例图。

如同上述，进行菜单操作的用户事件也是由播放列表(“XXX.PL”)的事件列表(EventList)来定义的。

作为用户事件被定义的事件，即事件类型(Type)为“UserEvent”的情况下，当到了事件生成时刻(“t1”)，该用户事件则成为准备状态。这个时候，事件本身还未被生成。

该事件处于以有效标准信息(Duration)来表示的期间(“T1”)准备状态。

如图21所示，用户按下遥控器键的“上”“下”“左”“右”键或者“决定”键的情况下，首先UO事件由UO管理器303来生成并被输出到程序处理器302。

程序处理器302将UO事件输出到方案处理器305，方案处理器305在接受了UO事件的时刻检索是否存在有效的用户事件。

方案处理器305在检索的结果为有成为对象的用户事件的情况下，生成用户事件并输出到程序处理器302。

在程序处理器302寻找事件ID，例如在图21的示例中是寻找持有“Ev1”的事件处理程序，执行成为对象的事件处理程序。在本实施例的情况下，开始再生播放列表#2。

在被生成的用户事件中不包含确定哪个遥控器键是被用户按下的键的信息。被选择的遥控器键的信息由UO事件被传到程序处理器302，并被记录保持到假想播放器所持有的寄存器中。

事件处理的程序调查此寄存器的值，可以执行分支处理。

图22是示出全局事件的例子的图。

如以上所述，全局事件由有关BD-ROM全体信息(“BD.INFO”)的事件列表(EventList)来定义。

作为全局事件所定义的事件，即事件类型(Type)为“GlobalEvent”的事件的情况下，仅当用户操作遥控器键的时候事件才被生成。

当用户按下菜单键时，首先UO事件由UO管理器303生成，并被输出到程序处理器302。程序处理器302向方案处理器305输出UO事件。

方案处理器305生成相对应的全局事件，并发送到程序处理器302。程序处理器302寻找持有事件ID“menu”的事件处理程序，并执行成为对象的事件处理程序。例如，在图22所示的例子的情况下，开始播放列表#3的再生。

在本实施例中仅称为菜单键，但也可以是再生DVD的播放器中的类似于遥控器的菜单键。通过对各菜单键所对应的ID分别进行定义，从而可以进行各菜单键所对应的适当的处理。

(假想播放器机器)

图23是用于说明程序处理器的功能的图。

利用图23对程序处理器302的功能构成进行说明。

程序处理器302是内部持有假想播放器机器的处理模块。假想播放器机器是以BD-ROM来定义的功能模型，不取决于各BD-ROM播放器的安装。即，可以保证在各种BD-ROM播放器中执行同样的功能。

假想播放器机器大致具有两个功能。即编程函数和播放器变数(寄存器)功能。

在编程函数以Java(注册商标)Script为基础，将以下三个功能作为BD-ROM固有函数来定义。

链接函数：停止现在的再生，开始从指定的播放列表、单元、或者时刻起的再生。

Link(PL#，Cell#，time)

PL#：播放列表名

Cell#：单元号码

time：单元内的再生开始时刻

PNG绘制函数：将指定PNG数据绘制到成像面

Draw(File，X，Y)

File：PNG文件名

X：X坐标位置

Y：Y坐标位置

成像面清除函数：清除成像面的指定区域

Clear(X，Y，W，H)

X：X坐标位置

Y：Y坐标位置

W：X方向宽度

H：Y方向宽度

并且，作为播放器变量可举出，示出播放器的状态的系统参数(SPRM)和可作为一般用途使用的通用参数(GPRM)。

图24是示出系统参数(SPRM)的一览的图。

SPRM(0)：语言代码

SPRM(1)：声音流号码

SPRM(2)：字幕流号码

SPRM(3)：角度号码

SPRM(4)：标题号码

SPRM(5)：章节号码

SPRM(6)：程序号码

SPRM(7)：单元号码

SPRM(8)：选择键信息

SPRM(9)：导航计时器

SPRM(10)：再生时刻信息

SPRM(11)：卡拉OK用混合模式

SPRM(12)：父母用国信息

SPRM(13)：父母级别

SPRM(14)：播放器设定值(视频)

SPRM(15)：播放器设定值(音频)

SPRM(16)：声音流用语言代码

SPRM(17)：声音流用语言代码(扩展)

SPRM(18)：字幕流用语言代码

SPRM(19)：字幕流用语言代码(扩展)

SPRM(20)：播放器地区代码

SPRM(21)：预备

SPRM(22)：预备

SPRM(23)：再生状态

SPRM(24)：预备

SPRM(25)：预备

SPRM(26)：预备

SPRM(27)：预备

SPRM(28)：预备

SPRM(29)：预备

SPRM(30)：预备

SPRM(31)：预备

并且，在本实施例，假想播放器的编程函数是作为Java(注册商标)Script基础被定义的，而编程函数也可以不是Java(注册商标)Script，也可以是UNIX(注册商标)OS等所使用的B-Shell或Perl Script等其它的编程函数。换而言之，本发明中所使用的程序语言并非限定于Java(注册商标)Script。

(程序的例子)

图25及图26示出了事件处理程序中的程序的例子。

图25是示出了有关具有2个选择按钮的菜单画面控制的事件处理程序中的程序的例子。

在单元(PlayList#1.Cell#1)开头利用时间事件，图25左侧的程序被执行。在此，首先将作为通用参数之一的GPRM(0)设定为“1”。GPRM(0)用于在程序中识别被选择的按钮。在最初的状态中，将配置在左侧的按钮1被选择的状态设为初期值。

其次，使用绘制函数Draw，分别针对按钮1和按钮2进行PNG的绘制。按钮1以坐标(10，200)为起点(左上端)，绘制PNG图像“1black.png”。按钮2以坐标(330，200)为起点(左上端)，绘制PNG图像“2white.png”。

并且，使用本单元的最后的时间事件来执行图25右侧的程序。在此，被指定为使用Link函数从该单元开头开始再次再生。

图26示出了有关菜单选择的用户事件的事件处理程序中的程序的例子。

当按下“左”键、“右”键、“决定”键的情况下，分别对应于上述各键的程序被写入事件处理程序。当用户按下遥控器键的情况下，如同用图21所说明的那样，生成用户事件，图26的事件处理程序被启动。

在本事件处理程序中，使用识别选择按钮的GPRM(0)的值和识别被选择的遥控器键的SPRM(8)，进行以下的分支处理。

条件1)按钮1被选择、且选择键为“右”键的情况

将GPRM(0)再设定为“2”，并且将处于选择状态的按钮变更为右按钮2。分别改写按钮1、按钮2的图像。

条件2)选择键是“决定(OK)”，按钮1被选择的情况

开始再生播放列表#2。

条件3)选择键是“决定(OK)”，按钮2被选择的情况

开始再生播放列表#3。

图26所示的程序像上述那样被解释并被执行。

(播放器处理流程)

其次，用图27至图30来说明播放器的处理流程。

图27是BD-ROM播放器中AV数据再生的基本处理的流程图。

插入BD-ROM时(S101)，BD-ROM播放器进行“BD.INFO”文件的读取和解析(S102)，并读取“BD.PROG”文件(S103)。“BD.INFO”文件及“BD.PROG”文件，先一同被存储到管理信息记录存储器204，并且由方案处理器305来解析。

其次，方案处理器按照“BD.INFO”文件内的第一事件(FirstEvent)信息，生成最初的事件(S104)。被生成的第一事件由程序处理器302所接收，并执行处理与该事件对应的事件处理程序(S105)。

值得注目的是，与第一事件相对应的事件处理程序中记录有指定应该最先再生的播放列表的信息。假设，播放列表的再生没被指示的情况下，播放器不进行任何再生，一直等待接受用户事件(S201)。

UO管理器303，当接受了用户通过遥控器键发来的请求的情况下(S201的“是”)，生成对程序处理器302的UO事件(S202)。

程序管理器302，判别UO事件是不是由菜单键发生的(S203)，当UO事件是由菜单键发生的情况下(S203的“是”)，向方案处理器305输出UO事件，并且方案处理器305生成用户事件(S204)。程序处理器302，执行处理与被生成的用户事件相对应的事件处理程序(S205)。

图28是从在BD-ROM播放器的播放列表再生开始到VOB再生结束为止的处理流程图。

如上所述，由第一事件处理程序或者全局事件处理程序，开始播放列表的再生(S301)。作为再生对象的播放列表所需的信息，方案处理器305进行播放列表“XXX.PL”的读取和分解析(S302)，以及读取与播放列表相对应的程序信息“XXX.PROG”(S303)。

接着，方案处理器305按照在播放列表中所登记的单元信息开始单元的再生(S304)。单元的再生，意味着从方案处理器对表示控制器306发出了请求，并且表示控制器306开始再生AV数据(S305)。

当开始再生AV数据时，表示控制器306读取并解析与再生的单元相对应的VOB的信息文件“XXX.VOBI”(S402)。表示控制器306使用时间图确定开始再生的VOBU以及确定其地址，并向驱动控制器317指示读出地址。驱动控制器317读出成为目标的VOB数据“YYY.VOB”(S403)。

被读出的VOB数据被送到解码器，且开始再生(S404)。VOB的再生持续到该VOB的再生区间结束为止(S405)，再生区间结束时，在存在有下一个单元的情况下(S406的“是”)，则转到单元的再生(S304)。并且，在没有下一个单元的情况下(S406的“否”)，则结束有关再生的处理。

图29是AV数据的再生开始后的事件处理流程图。

图29(A)是BD-ROM播放器中的时间事件所涉及的处理的流程图。

并且，BD-ROM播放器是事件驱动型的播放器模型。当播放列表的再生开始时，分别启动时间事件系列、用户事件系列、及字幕表示系列的事件处理程序，并同时执行这些事件处理。

BD-ROM播放器中的播放列表再生开始时(S501)，会确认到播放列表再生还没有结束(S502的“否”)，方案处理器305确认是否到了时间事件发生时刻。

在到了时间事件发生时刻的情况下(S503的“是”)，方案处理器305生成时间事件(S504)。程序处理器302接收时间事件并执行事件处理程序(S505)。

并且，在没有到时间事件发生时刻的情况下(S503的“否”)以及事件处理程序的执行结束的情况下，重复进行播放列表再生的结束确认(S502)之后的处理。

并且，在确认到播放列表的再生已结束时(S502的“是”)，时间事件系列的处理被强制结束。

图29(B)是BD-ROM播放器的用户事件所涉及的处理的流程图。

BD-ROM播放器1中的播放列表的再生开始的情况下(S601)，可以确认到播放列表再生还没有结束(S602的“否”)，UO管理器303确认是否有UO的接收。

在有UO的接收的情况下(S603的“是”)，UO管理器303生成UO事件(S604)。程序处理器302接受UO事件，并确认此UO事件是否为菜单呼叫。

在是菜单呼叫的情况下(S605的“是”)，程序处理器302使方案处理器305生成事件(S607)，并且程序处理器302执行事件处理程序(S608)。

并且，在判断为UO事件不是菜单呼叫的情况下(S605的“否”)，UO事件表示是由光标键或“决定”键发生的事件。在这种情况下，方案处理器305判断现在时刻是否在用户事件有效期间内，当在有效期间内的情况下(S606的“是”)，方案处理器305生成用户事件(S607)，程序处理器302执行成为对象的事件处理程序(S608)。

并且，在没有UO接收的情况下(S603的“否”)、现在时刻不在用户事件有效期间内的情况下(S606的“否”)、以及事件处理程序的执行处理结束的情况下，重复播放列表再生的结束确认(S602)以后的处理。

并且，在确认到播放列表的再生已经结束时(S602的“是”)，用户事件系列的处理被强制结束。

图30是BD-ROM播放器的字幕数据的处理流程图。

在BD-ROM播放器的播放列表的再生开始的情况下，可以确认到播放列表再生还没有结束(S702的“否”)，方案处理器305确认是否到了字幕表示开始时刻。在到了字幕表示开始时刻的情况下(S703的“是”)，方案处理器305向表示控制器306指示字幕的绘制，表示控制器306向图像处理器311指示字幕的绘制。图像处理器311按照所述指示在成像面209进行字幕的绘制(S704)。

并且，在没有到字幕表示开始时刻的情况下(S703的“否”)，确认是否为字幕表示结束时刻。在判断为是字幕表示结束时刻的情况下(S705的“是”)，表示控制器306向图像处理器311发出删除字幕的指示。

图像处理器311按照所述指示将被绘制的字幕从成像面209中删除(S706)。

并且，在图像处理器311所进行的字幕绘制(S704)结束的情况下、图像处理器311所进行的字幕删除(S706)结束的情况下、以及被判断为不是字幕表示结束时刻(S705的“否”)的情况下，重复播放列表的再生结束确认(S702)之后的处理。

并且，在确认到播放列表再生已经结束的情况下(S702的“是”)，字幕表示系列的处理被强制结束。

根据以上的工作，BD-ROM播放器根据用户的指示或BD-ROM中所记录的BD管理信息等，进行BD-ROM的再生所涉及的基本的处理。

(实施例2)

以下对本发明的实施例2进行说明。

实施例2基本上是基于实施例1的内容，以下，以扩展的部分或不同的部分为中心进行说明。

并且，在实施例2中利用具有与实施例1中所记载的数据结构为基本的数据结构的盘，以下对作为本发明的特征的、与盘菜单有关的数据结构进行说明。

并且，在此以电视摄影机为例，该电视摄影机为记录装置，将信息记录到盘中，并对记录的信息进行编辑，以下对电视摄影机的构成以及工作进行说明。

图31是实施例2中使用盘的记录器以及播放器中菜单表示的示例图。

图31所示的Recorder-A以及Recorder-B分别是A公司以及B公司的记录器。并且，在各记录器中安装有记录了多个内容的盘。

图31的上半部分示出了各个记录器所表示的装置菜单的例子。

装置菜单是一种简易的菜单，其目的是将被安装在记录器中的盘中所记录的标题名称等表示在自己的表示部或与自己相连接的显示装置上。

并且，“标题”是指在数字流的一部分或全部(即部分区间构成的AV内容)。并且，通过由与标题相关联的播放列表指定MPEG流等数字流中的部分区间的位置以及再生顺序，从而确定该标题。例如，用户拍摄的一个图像内容作为一个标题被记录在盘中。

如图所示Recorder-A所表示的装置菜单中示出了盘中所记录的标题的缩略图，且有多个缩略图排列在装置菜单中。

并且，Recorder-B所表示的装置菜单中示出了盘中所记录的内容的记录日期和时间，且这些日期和时间是以列表的形式来表示的。

这样，利用缩略图等显示装置独自生成的菜单具有以下的理由。即，记录/摄影的日期或缩略图(JPEG)的表示具有处理时间少用户应答好的特点，以及对于只装备了像电视摄像机这样比较小的显示装置的机器而言是比较适合的菜单表示。

这些记录器所具有的功能是除装置菜单以外还生成盘菜单，并可以记录到盘中。

图31的下半部分示出了各记录器所生成的、盘中记录的盘菜单的示例图。这些盘菜单不在各个记录器中被再生，由再生该盘的播放器来再生并提示给用户。

盘菜单是“标题”的一种，是使用户选择的除装置本身以外的标题。并且，像这样由记录器生成，并被记录到盘等信息记录介质中。

具体而言，盘菜单是由实施例1中说明的BD.INFO或BD.PROG等所提供的功能构成的菜单，可以假想为由连接在电视上的播放器再生的菜单。

为此，所述盘菜单可被设计为在大的画面上表示各种信息，与所述的装置菜单不同，可以利用动画效果或被层次化的理论构成等，看上去也比较好。

如图所示，由于不同的记录器盘菜单的设计也就不同，即使进行的是相同的记录或摄影，也会生成图的下半部所示出的不同表示方式(设计)的盘菜单。

这样，在A公司的记录器Recorder-A和B公司的记录器Recorder-B中盘菜单是不同的。这是因为盘菜单的安装可以因各个记录器制造厂商而不同的缘故。

为此，在记录器或电视摄影机等装置中使用以其它的制造厂商的装置记录盘菜单的盘的情况下，由于不能解释该盘菜单，因此，如以上所述，会发生在删除盘菜单的同时使处理时间增加等问题。有关这个问题将利用图34进行详细说明。

图32示出了实施例2中的BD.INFO中的内容。如图所示，在BD.INFO中存在“Index”这个区域，在该“Index”区域中存储有用于识别在盘中记录的标题的信息群。再生该盘的播放器根据在该“Index”中存储的信息进行标题的再生等。

并且，“Index”中存储的信息只是本发明的信息记录介质中的索引信息的一个例子。

并且，在“Index”中描述了程序的参考号(ProgramIDRef)，该程序控制“FirstPlayback”、“TopMenu”及“Title#1”等各自的标题的再生。

ProgramIDRef是本发明的信息记录介质中的程序识别信息的一个例子，且各个程序由ProgramIDRef来确定。并且，被确定的程序通过调用播放列表来控制标题的再生。

并且，“FirstPlayback”是指在插入盘时最初应该再生的标题等，在该“FirstPlayback”中存储有用于再生该标题的程序的参考号，并以此作为信息。

并且，“TopMenu”是指盘菜单，是用遥控器按下菜单键的情况下等所选择的标题，在该“TopMenu”中存储有用于再生盘菜单的程序的参考号，并以此作为信息。

并且，如图32所示，BD.INFO内的“Index”中所存储的“FirstPlayback”、“TopMenu”及“Title#1”等各自的名字只是本发明的信息记录介质中标题识别信息的一个例子。

并且，用户拍摄的影像内容等盘菜单以外的标题的标题识别信息以“Title”+“#标题号”的形式来表示。有关标题号待后述。

具体而言，在盘加载时，以“FirstPlayback”中所存储的ProgramIDRef表示的号码指定的程序被自动执行。并且，若用户按下遥控器的菜单键，则以“TopMenu”中登录的ProgramIDRef的号码指定的程序被执行。

作为播放器通常的工作是，在按照参照了“FirstPlayback”的程序，再生进行盘加载时的开头影像之后，或什么也不表示而跳过“TopMenu”，表示以“TopMenu”规定的盘菜单。

并且，在各个“Title#1”～“Title#n”中登录有“ProgramIDRef”，该“ProgramIDRef”指定用于控制用户所拍摄的以及记录的影像内容的再生的程序。

图33示出了实施例2中的BD.PROG的内容。在BD.INFO所参照的ProgramIDRef的号码是在BD.PROG中的Program的排列顺序。

如图所示，例如，Program#1中描述有：在进行了某些处理之后，进行GPRM0的值为0的条件判断，并按照这个值，在GPRM0＝0时，进行持有“111.PL”的PL的再生，在GPRM0与GPRM3相同时，进行持有一种号码的PL的再生，这种号码是在GPRM0上加上了2之后的值的号码，并进行后续的处理。

像这样在BD.PROG包含的程序中可以自由组合使用GPRM(通用参数)的运算处理以及播放列表的再生命令(PlayPlayList)等指令，所述GPRM(通用参数)是条件转移(if)和播放器变数的一种。

图34示出了菜单表示以及标题再生所涉及的表示以及工作的迁移的一示例图。

具体而言，该图从数据结构上说明了在播放器中由所述的BD.INFO以及BD.PROG再生菜单之后，通过用户的指示，再生用户所记录的影像内容即标题，并返回到菜单这一连串的处理。

在图34中，表示以及工作的迁移从作为TopMenu的左下的盘菜单被表示在TV上开始。

通过用户利用遥控器选择并决定最右侧的按钮(Button3)，在该TopMenu中，按钮程序(Button Program3)被执行，该按钮程序(Button Program3)是在100.PL所指定的流(100.VOB)中被多路复用的按钮程序，所述100.PL是与TopMenu相关的播放列表。

按钮程序(Button Program3)中写有想要再生Title3的指令(JumpTitle(3))，并通过执行该指令从而迁移到Title3的再生。

具体而言，由于BD.INFO中描述的“Title3”所示出的ProgramIDRef的字段的值为k，因此，BD.PROG的第k个程序(Program#k)被执行。

在程序(Program#k)中由于有播放列表(200.PL)的再生命令，因此进行200.PL的再生，在再生结束之后继续进行后续的指令处理。

在程序(Program#k)的最后，由于返回到TopMenu的指令(JumpTopMenu())被执行，因此，原来的TopMenu被再次表示出来。

以上就是从数据结构上看到的TopMenu和Title再生的构造。

以上所述的表示以及工作的迁移是通过播放器按照盘菜单所关联的播放列表等的描述进行处理来实现的，生成盘菜单不会因是哪家制造厂商而发生问题。

但是，在假想一个盘在不同的制造厂商的电视摄影机之间移动的情况下，对于盘菜单而言，在电视摄影机一侧，即生成盘菜单并记录到盘中的记录装置一侧出现没有互换性的问题。

即，在某张盘中仅进行Recorder-A的记录或编辑是没有问题的。但是，在将Recorder-A所记录的盘设置到其它的制造厂商的制品Recorder-B上，并在Recorder-B上进行记录或编辑的情况下，则在Recorder-B不能确定Recorder-A生成的盘菜单的设计策略。

为此，出现的问题是：在盘菜单中已经有的内容仍然存在的情况下，不能进行按照编辑内容的追加等。

这是因为如图3所示那样，BD.PROG的Program按照再生状态，进行使用了变化的播放器变数的条件转移的缘故。

也就是说，上述问题的起因是，只看规定的Program在实际安装上是不能确定的，这时因为怎样工作是与其它的要素相关联的，除此之外，在Recorder-A生成的盘菜单中使用的素材(背景或按钮影像的选择)的策略在Recorder-B也是不能得到确定的。

例如，在此假想的程序是，是否从最初到最后都再生Title1是以播放器变数的GPRM100的值来管理的，关于Title2的再生，若Title1的再生结束了就从中途进行，除此之外则从Title2的开头开始再生。

在这样的情况下，GPRM100是示出Title1的再生经历的信息，并被设计为能够对Title2的再生进行控制，为了验证不受除此之外的其它的要素的影响，则需要对以所有的能够再生的模式的再生进行模拟。

为此，就需要获得并解析所有的BD.PROG的程序(Program)以及流中被多路复用的所有按钮程序(Button Program)，这样就必需要确定播放器变数的设定的意思，并且数据的读取与解析也要花费大量的时间。

因此，实际上将盘菜单从Recorder-A继续延用到Recorder-B是不可能的。

因此，对于由Recorder-A生成的记录在盘中的盘菜单而言，为了获得盘全体的数据的相容性的最确实且简便的方法是：在Recorder-B对该盘进行记录以及编辑等情况下，删除所有与盘菜单相关的各种文件从头重做。

并且，还考虑到不删除与已经存在的盘菜单相关的各种文件而生成新的盘菜单，但这样的话不需要的文件就会被蓄积到盘中。据此，不仅盘中的可以记录的容量被浪费了，而且在加载盘的机器上也会增加文件管理所涉及的处理负担。

图35示出了在不同的制造厂商的记录器之间进行盘的移动的情况下，盘菜单的更新规则。

图35(A)示出了在盘菜单更新中怎样处理BD.INFO等各个文件，图35(B)说明了图35(A)中所示出的号码的意思。

例如，对于由Recorder-A记录内容的盘，进一步Recorder-B在该盘中进行记录以及编辑的情况下，必需要将因编辑而追加或删除了的内容反映到盘菜单上。

这样，Recorder-B对由Recorder-A记录了盘菜单的盘进行内容的记录以及编辑，在必需要更新盘菜单的情况下，变更与FirstPlayback以及TopMenu相关的所有部分(相当于BD.INFO的部分、相当于BD.PROG的部分、XXX.PL的全部、YYY.VOBI的全部、YYY.VOB的全部)。并且，“变更”是指包括删除该数据并生成新的。以下所述也是同样。

而且，由于要重新规定与新的FirstPlayback以及TopMenu具有相容性的Title和该Title所使用的Program，因此，有关Title的相关部分也要全部变更(相当于BD.INFO的部分、相当于BD.PROG的部分)。

反而言之，在盘菜单更新时原封不动保留的是以下所示的、存储用户拍摄的影像的各个Title的播放列表。

并且，正如仅进行以上所述的变更就可以实现菜单的更新那样，在Title所使用的流(YYY.VOB)中重要的是不含有对菜单工作有影响的Button Program。

若按照这样的规则，即使在不同的制造厂商之间使盘移动的情况下，也可以在维持盘全体的数据相容性的同时更新盘菜单。

然而，若根据该规则，就需要确定FirstPlayback以及TopMenu所使用的播放列表，像以上所述那样这在实质上是不可能的。为此，存在的问题仍然是：在盘菜单的更新时，不知道删除哪个XXX.PL为好。

因此，如图36所示，在BD.INFO的“Extension”中预先存储以下这样的信息是有效的。

图36示出了在BD.INFO的“Extension”中存储了用于确定播放列表的信息的状态。

“Extension”是在BD.INFO的末尾设置的扩展区域，这样，在这个区域中可以存储标准中没有规定的信息。并且，因为播放器没有从“Extension”中读出信息的义务，所以即使存储了标准中没有规定的信息也不会给播放器带来任何不好的影响。

并且，“Extension”中所存储的信息是本发明的信息记录介质中扩展信息的一个例子。

以下对“Extension”中所存储的信息进行说明。

(1)“MakerInfo”，是在本发明的信息记录介质中的生产者识别信息的一个例子，是包括用于识别制造厂商的标识符的“MakerID”，和用于确定记录了BD.INFO的装置的标识符的“ModelID”的信息。

(2)“DiscInfo”是用于确定在该盘上可以记录的、或已经被记录的影像的帧率的信息，包含以下的各信息。

“IsNTSC”是表示进行29.97/59.94Hz的帧率的影像编码，或者是这些帧率的影像是否已经被记录的信息。

“IsPAL”是表示是进行25/50Hz的帧率的影像编码，或者是这些帧率的影像是否已经被记录的信息。

“IsFILM”是表示是进行23.97/24Hz的帧率的影像编码，或者是这些帧率的影像是否已经被记录的信息。

并且，“IsNTSC”和“IsPAL”是不能在一个盘中混在的，原因是如果混在，则有可能会招致一部分的内容不能再生。

不过，“IsFILM”可以与“IsNTSC”或“IsPAL”共存。例如，在记录器进行29.97/59.94Hz的帧率的影像编码并记录的情况下，事先确认是否为“IsNTSC＝1”之后再记录。

若是“IsNTSC＝0”的情况，则确认是否为“IsPAL＝0”，并改写为“IsNTSC＝1”记录。或者，即使“IsNTSC＝0”且“IsPAL＝1”，在确认到盘上没有25/50Hz的帧率的影像的基础上，也可以改写为“IsNTSC＝1”以及“IsPAL＝0”记录。这样，就可以不必在所有的流的帧率中调查盘上的NTSC/PAL的混在，并可以容易地防止混在。

(3)“FirstPlayback”是包括“PlayListNumber”和“PlayListID”的信息，所述“PlayListNumber”表示由BD.INFO内的“Index”所指定的程序读出的播放列表的总数，所述“PlayListID”表示所述播放列表的号码。

并且，PlayListID是在本发明的信息记录介质中播放列表识别信息的一个例子。

(4)“TopMenu”是包括“PlayListNumber”和“PlayListID”的信息，所述“PlayListNumber”表示由BD.INFO内的“TopMenu”所指定的程序有可能读出的播放列表的总数，所述“PlayListID”表示所述播放列表的号码。

(5)“TitlePLPairNumber”是表示以下所示的″TitlePLPair″的总数的信息。

(6)“TitlePLPair”是包括“PlayListID”和“TitleID”的信息，所述“PlayListID”表示播放列表的号码，所述“TitleID”表示由所述播放列表确定的标题的标题号码(假想Title#n和XXX.PL被一对一地使用)。

标题号码是指，作为如上所述的标题识别信息的“Title#n”的“n”的部分的数字。即标题号码是与标题识别信息相对应的数字。

这样，根据作为BD.INFO的扩展区域的“Extension”所描述的“MakerInfo”表示的信息，电视摄像机等记录器可以获得确定记录器的制造厂商的信息和确定装置的信息，所述记录器是生成该盘中记录的菜单的记录器。

在装入了盘的记录器中，假设判明装入的盘是这台记录器记录的盘菜单的盘，这样就可以不必重新制作盘菜单(FirstPlayback/TopMenu)只要进行确定的差分信息的更新就可以，从而可以缩短菜单的更新时间。

并且，装入了盘的记录器通过参考“MakerInfo”所示出的信息，从而可以判断是否为以其它的制造厂商的记录器记录的盘菜单的盘，在判断为是以其它的制造厂商的记录器记录的盘菜单的盘的情况下，通过重新制作盘菜单从而得以更新。

并且，根据作为BD.INFO的扩展区域的“Extension”所描述的“FirstPlayback”表示的信息以及“TopMenu”表示的信息，就可以容易地确定盘菜单所使用的播放列表(XXX.PL)。为此，通过解析所述播放列表，就可以确定使用的YYY.VOBI、YYY.VOB。

即，可以容易地确定与盘菜单相关的XXX.PL、YYY.VOBI、YYY.VOB文件，并可以删除这些文件。

也就是说，可以删除与成为删除对象的标题相关的播放列表、该标题的管理信息、以及该播放列表中被指定的数字流的部分区间。

这样，通过将能够容易地确定与盘菜单相关的播放列表的信息事先记忆到盘中，从而可以容易地确定与盘菜单相关的各种文件，在删除了这些文件后就可以重新生成盘菜单。

据此，即使在互不相同的制造厂商的装置之间移动盘，在删除与盘菜单相关的各种文件之后，也可以生成新的盘菜单。

即，记录了以上所述的信息的信息记录介质，不论在哪个制造厂商的记录装置，也不会发生不必要的处理负担或处理时间，既可以保持盘全体的数据的相容性，又可以使盘菜单得以更新。

以下对在盘菜单更新时的标题号码的保持进行说明。

正如许多公开文献和实施例1中所示出的那样，在再生DVD-Video或BD-ROM这样的信息记录介质的播放器中，可以利用标题和章节这两个层次来向用户提供内容。

在一般的播放器中设置有标题搜索的功能。用户根据这以功能，可以不通过图形用户界面(Graphical User Interface：GUI)的盘菜单，而直接使用遥控器的数字键等来确定标题号码，从而可以从该标题开始再生。

并且，由于标题号码所指的是以BD.INFO的Index这一部分来表示的Title的循环顺序，因此，标题1就指的是循环顺序中的开头的Title。

在此，可以考虑到将来在盘的标记中列印能够表示标题号码及其内容的细节的信息(记录日期时间或广播站的频道、缩略影像等)。

像在收录了CD-DA(Compact Disc Digital Audio)这样的音频内容的盘的标记中列印曲目号码和曲目名称的组合，这对于利用本发明的记录装置的用户而言，在标题和该标题的内容之间的关联上能够利用标题搜索功能是非常重要的。

在此，关于某内容和附加在该内容上的标题号码之间的关系，即与某内容相关的播放列表和与该播放列表相关的标题号码的关系，由于不会在包介质(Read Only Media)中被变更因此不必考虑。

但是，在可以进行信息的记录以及编辑的信息记录介质中，以某制造厂商的记录器生成的盘菜单由其它的制造厂商的记录器更新时，不能维持上述的内容和标题号码之间的关系。

为此，例如在用户以上述的Recorder-A记录影像内容的盘中，识别标题号码为“1”的内容，之后由Recorder-B来更新盘菜单，就会突然出现标题号码被变更为“3”的情况。

当然，在盘菜单更新之前，若能够容易地知道哪个内容即标题与哪个播放列表相关，也就是说要参考哪个播放列表，则在那个时刻获得附加在内容上的标题号码，在更新时可以继续维持内容和标题号码的关系。

但是，为了获得哪个标题与哪个播放列表相关，就需要解析图32所示的Title#1…Title#n表示的BD.PROG中记录的各Program，像以前所述这是非常困难的。

因此，在本实施例中，图36所示的BD.INFO的“Extension”中，作为包含标题号码(TitleID)和该标题号码所对应的播放列表号码(PlayListID)的信息描述“TitlePLPair”。

并且，标题号码和播放列表号码被依次追加记录。即，TitlePLPair中的描述顺序是该播放列表(以PlayListID确定的播放列表)的记录日期和时间的顺序。

据此，可以在不破坏以前的标题号码和该标题的内容(即播放列表)之间的对应关系的情况下更新菜单，对于用户而言，可以防止突然发生的标题号码和内容的相关关系的变更。

并且，在某盘中记录的标题被删除的情况下，标题号码的顺序为BD.INFO的Index内的循环顺序，因此在删除的标题中即使附加伪播放列表也可以。

而且，作为所述标题所对应的内容，可以使用户识别到的影像等内容与被删除的标题相关的播放列表相关联，所述用户识别到的影像等内容是指“Deleted Title”等和已经与所述标题相关的内容。这样，可以不影响到其它的标题号码。

并且，表示上述被删除之事宜的内容只有在标题搜索的操作中才能再生，被设置成在盘菜单中不被选择。

图37是实施例2中的盘菜单更新前后的标题和播放列表(内容)之间的相关关系的示例图。

假想在某盘中，在某时刻如图37所示，盘上有三个标题，每个标题分别与101.PL、102.PL、103.PL的播放列表相关联。并且，假想各播放列表以上述的顺序与内容A、B、C相关联。

在这样的假想下，以记录器将Title2全部删除，在记录到新建立的内容D的情况下，如图37(B)所示，标题和播放列表(内容)的关系的一部分被变更。

具体而言，被删除的Title2不从BD.INFO的Index中被删除而被继续保留，Title2的播放列表102.PL所参考的AV流(YYY.VOB)被替换为表示Title2由用户的编辑操作被删除的影像或声音信息。

并且，关于Title1和Title3，标题号码和播放列表(内容)之间的关系是被维持的。即，被附加在这些标题的标题号码是不变更的。

并且，新被记录的内容D被追加在图36所示的TitlePLPair中的最后。

即，TitlePLPair中所描述的顺序示出了该播放列表(PlayListID)的记录日期和时间的顺序，因此，有用于以记录日期和时间的顺序进行的菜单表示。

其次，针对具有图32、图33、以及图36所示的数据结构的盘，对进行以上所述的菜单的更新和各种信息的操作的记录器的结构以及工作进行以下说明。

图38是实施例2的记录器的功能构成方框图。

图38中所示的记录器400是本发明的记录装置的一个例子，例如可以作为将影像作为数字流来记录的电视摄像机来实现。

并且，记录器400具有记录数字流的记录装置本来就有的、编码器等其它的构成部，但为了明确本发明的特征，省略这些其它的构成部的图示以及说明。

如图38所示，记录器400包括：播放列表确定部401、删除部402、菜单生成部403、制造厂商判断部404、接收部405、编辑部406、号码读出部407、拍摄部408、以及表示部409。

并且，作为信息记录介质，在此使用具有图32、图33、以及图36所示的数据结构的盘105。

播放列表确定部401是一处理部，使用图36所示的PlayListID，对从控制盘菜单等标题再生的程序中读出的播放列表，即与成为处理对象的标题相关的播放列表进行确定。

菜单生成部403是另一处理部，对盘105中所记录的菜单进行替换，生成新的菜单并记录到盘105中。

删除部402是另一处理部，在新的菜单由菜单生成部403生成的情况下，删除与盘105中记录的菜单相关的播放列表。而且，删除的播放列表由播放列表确定部401来确定。

制造厂商判断部404是另一处理部，对图36所示的Extension中包含的MakerInfo所表示的制造厂商是否与生产记录器400的制造厂商一致进行判断。

接收部405是另一处理部，接收来自用户或记录器400所接续的装置对记录器的指示等输入。

编辑部406是另一处理部，进行盘105中记录的标题的编辑。

号码读出部407是另一处理部，从盘105读出“Extension”中包含的标题号码，即TitleID。

拍摄部408是另一处理部，将影像作为数字流记录到盘105中。

表示部409是记录器400所具备的小型液晶装置等。在表示部409中表示图31的上半部分所示的简易装置菜单。

具有以上这种结构的记录器400的基本工作概要如以下所述。并且，在此假想这样一种情况，即：与生成记录器400的制造厂商不同的制造厂商的记录器所生成的盘菜单已被记录到盘105中。

在此盘105被装入到记录器400的情况下，播放列表确定部401使用“Extension”中包含的、与“TopMenu”对应的PlayListID，来确定与盘中记录的盘菜单相关的播放列表。

菜单生成部403生成新的盘菜单并记录到盘105中。并且，删除部402删除由播放列表确定部401确定的播放列表以及与由其它制造厂商的记录器生成的盘菜单相关的各种文件。

这样，记录器400可以删除由其它制造厂商的记录器生成的盘菜单，并将新的盘菜单记录到盘中。

以下，对记录器400在更新盘105上的标题结构时的工作流程进行说明。

图39是实施例2中的记录器400在更新记录/编辑标题构成时的工作流程的概要流程图。

在由用户的指示等开始新的标题的标题的记录或对已有的标题进行编辑的情况下(S801)，编辑部406从盘105中将BD.INFO以及BD.PROG读入(S802)。进一步，号码读出部407获得盘105中记录的标题号码的最后的号码。

具体而言，从BD.INFO的“Index”中包含的“Title#1”开始排列的存在的标题识别信息中获得最后的标题号码(Tn)(S803)。

例如，在“Index”中存在“Title#1”、“Title#2”、“Title#3”的情况下，获得“3”。

之后，编辑部406按照需要，更新XXX.PL、YYY.VOBI、以及YYY.VOB(S804)，在记录新建立的标题的情况下，在上述Tn以后的号码上分配新记录的标题，并在读出的BD.INFO上记录该号码和标题(S805)。

例如，在Tn＝“3”的情况下，新的标题被记录，并将标题号码“4”附加给该标题。

在这种情况下，通过编辑部406，“Title#4”被追加到BD.INFO的“Index”，而且，将TitleID的“4”和与Title4相关的播放列表的PlayListID对应起来追加到“Extension”。

并且，在上述Tn以前的标题号码的标题中曾经进行过删除的情况下，编辑部406不是删除所述被删除的标题的标题号码，而是将与该标题号码相关的播放列表所示的数字流的一部分区间替换为表示标题已被删除之内容的伪数字流。即，将伪数字流附加给被删除的标题(S806)。

伪数据流是指以前所述的“Deleted Title”等影像数据等。

具体而言，在进行删除时，播放列表确定部401从被删除的标题的标题号码中，即从与TitleID所对应的PlayListID中确定与被删除的标题相关的播放列表。

通过这样的工作，例如，在标题号码“2”的标题被删除的情况下，不是删除标题号码“2”，而是将被命名为“Deleted Title”的影像等数据与标题号码“2”相对应。

这样，被更新的BD.INFO以及BD.PROG等被写入到盘105(S807)。据以上所述，结束一连串的记录和编辑所涉及的工作。

如以上所述，通过在不破坏标题号码和该标题的内容的关系的基础上更新BD.INFO，从而即使在不是盘菜单，而是以标题搜索直接进行内容的再生的情况下，也可以防止在每次盘菜单的更新时，标题号码和内容的关系改变，从而提高了用户的便利性。

并且，在此时，盘菜单被设置为删除了的标题不能被选择(即根本不表示)，对于通过使用GUI的盘菜单来控制内容再生的用户而言，虚假地留下Title2也不会带来不好的影响。

而且，在本实施例中，作为具有图32所示的数据结构的信息记录介质采用了盘，但并非受此所限，只要是能够记录信息的介质，BD以及DVD等盘也可以。例如也可以是闪存等半导体存储器。

并且，在与“FirstPlayback”、“TopMenu”相关的内容(VOB文件)，也被“Title”参考的情况下，当删除盘菜单时，作为“FirstPlayback”和“TopMenu”而被登记的播放列表和由该播放列表参考的内容(VOB文件)被删除，从而导致妨碍标题的再生。因此，这种事情应该被禁止。

在本实施例中，对于在BD.INFO的“Extension”中描述的“FirstPlayback”及“TopMenu”的播放列表所参考的内容(XXX.VOB)，禁止在BD.INFO的“Extension”中描述的“Title”的播放列表中被参考。

盘菜单(FirstPlayback/TopMenu)和该盘中所记录的标题不参考相同的VOB，是为了满足迅速的盘菜单更新即盘菜单所涉及的文件的确定与删除的需要。

并且，即使在以BD.INFO的“Extension”说明的信息不存在的情况下，通过将“FirstPlayback”及“TopMenu”所参考的播放列表的文件号码和“Title”所参考的播放列表的文件号码分别放置，从而在盘菜单的更新中能够迅速地确定在更新中所必需的播放列表文件。

并且，在删除播放列表时，事先在图36所示的“FirstPlayback”中包含的“PlayListID”中检索该播放列表是否与其它的标题相关联，在无关联的情况下可以删除。

(实施例3)

以下对本发明的实施例3进行说明。

基本上是基于实施例1的内容，以下以扩充部分或不同部分为中心进行说明。

在本发明的实施例1中，利用图18以BD管理信息中的一个对管理盘全体的信息的“BD.INFO”的例子进行了说明，在本实施例中以图40的形式为例。

在盘中只存在一个BD.INFO，当该盘被插入时最先被解释。在图40中BD.INFO包括AppInfo、TitleList、以及ExtensionData，在AppInfo中存储了有关盘全体的信息。

并且，图40中所示的“TitleList”以及“ExtensionData”分别相当于图36所示的、实施例2中的“Index”以及“Extension”的信息区域。

TitleList中存储有该盘中所存储的Title的信息，TitleList中包括FirstPlayback和TopMenu这两个特殊的Title以及多个标准的Title。标准的Title的总数被存储在TitleList以下的Number中。FirstPlayback和TopMenu以及各Title持有在各自的标题被选择时向应该执行的后述的Object的链接信息(Object的ID)。FirstPlayback是在盘被插入时最先被选择的标题，TopMenu是以遥控器按下菜单按钮时等被选择的再生菜单用的标题。

以下利用图41对存储了与Object有关的信息的“BD.PROG”进行说明。Object是由多个导航指令组成的程序群，在执行Object时每个导航指令被依次执行。

如图41所示，“BD.PROG”包括表示存储的Object的总数的Number以及各Object的项目。图中的各Object的脚号(#1等)是Object的ID，各Object按照ID的顺序排列。

如以上所述，基于此ObjectID，在标题选择时被执行的Object由标题参考。各Object包括ObjectInfo区域和Program区域。ObjectInfo区域中存储有Object的设定信息。Program区域中存储有该Object在执行时依次执行的导航指令群。

并且，图41所示的“BD.PROG”基于在实施例1中利用图18说明的“BD.PROG”上发生了变化，且利用图17说明的“XXX.PROG”被废止。

并且，对于在实施例1中说明的事件由其它的功能来代替。例如，对于利用图20说明的时间事件以及利用图21说明的用户事件，由相当于嵌入流中的导航指令来代替，详细待后述。

并且，利用图22说明的全局事件则成为按照每次遥控器操作播放器的执行工作所规定的。

例如图22说明的那样，在遥控器的Menu键被按下时，以上述的BD.INFO规定的标题中的一个即TopMenu被自动选择，结果是由TopMenu所链接的Object被选择，BD.PROG中的该Object的Program区域中所存储的指令群被执行。

以下，对本实施例中的导航功能之一的按钮以及页面进行说明。

在本发明的实施例1中，利用图20～图21对以事件为契机的按钮描绘的例子进行了说明，在BD-ROM标准中与上述的DVD的NV_PCK相同，将导航指令作为页面及按钮(NV_DS)，可以和视频基本流(V_PES)及音频基本流(A_PES)一起被嵌入到MPEG-TS形式的流中。

在BD-ROM中，实现交互性的导航功能被变为流的形式，与影像、声音、字幕等AV数据一起在流中被多路复用，以下将对此进行说明。

并且，在本发明的实施例1中，对BD-ROM Disc中所记录的AV流以MPEG-PS为标准的形式进行了说明，在本实施例中以MPEG-TS的形式来实现AV流。

在本实施例中利用图42对AV流进行说明。

如图42所示，实现了影像、声音、字幕以及交互性的导航等基本流(图42的(1))分别被变为PES流的形式(图42的(2))，并且分别被一条MPEG-TS多路复用(图42的(3))。

并且，对于MPEG-TS中的多路复用，被多路复用的各个数据是按解码顺序排列的比特列，而被多路复用的数据之间，即影像数据、声音数据、字幕数据、导航数据之间，并不一定是按再生顺序排列的，换句话说不一定是按解码顺序排列的比特列。

MPEG-TS的解码器模型(图42的(4))持有解除多路复用后各个基本流所对应的解码缓冲，到进行解码为止临时蓄积数据。

以下，对BD-ROM中的页面和按钮进行具体说明。

在BD-ROM的导航功能中提供了页面和按钮这两个概念。

页面是将按钮分组并进行管理的单位，按钮是按照用户的操作进行实际工作的单位。

具体而言，作为显示器组(NV_DS)，对于页面是持有哪样的信息在MPEG-TS中被多路复用的，以下利用图43进行说明。

如图43所示，页面中的自身的“页面ID”、设定有页面迁移时的动画效果的“动画信息”、设定有页面内描绘调色板的“调色板信息”、设定有在页面打开(on)时成为选择状态的按钮ID的“默认选择按钮ID”、设定有在页面打开(on)时执行的按钮的按钮ID的“默认执行按钮ID”、以及设定有该页面所属的按钮群的信息的“所属按钮信息”被设定到NV_DS中，利用图42在上述的MPEG-TS中被多路复用。

作为显示器组，对于按钮是持有哪样的信息在MPEG-TS中被多路复用的，以下将利用图44对此进行说明。

如图44所示，按钮中的自身的“按钮ID”、表示作为自身的大小或按钮图像来绘制的内容等的“区域信息”、表示按钮被选择时，是否自动执行被设定为自身的导航指令的“自动执行可否标志”、在自身为被选择的状态，用户通过遥控器进行操作(上下左右)时，设定有迁移到哪个按钮的“按钮迁移信息”、设定有在按钮被选择或被按下等按钮的状态发生变化之时发出的效果音或执行的动画效果等的“状态信息”、以及设定有在按钮按下等按钮有效之时执行的导航指令群的“执行指令”被设定到NV_DS，据图42在上述的MPEG-TS中被多路复用。

以上，对BD-ROM中导航功能之一的页面和按钮进行了说明，上述的时间事件以及用户事件由此页面和按钮来实现。

例如，为了再生所希望的位置的流，时间事件将按钮嵌入，通过事先设定所述“自动执行可否标志”，从而在规定的时刻在流的再生中执行由所述按钮设定的“执行指令”。

并且，关于用户事件，为了进行所希望的工作，可以通过事先在流中对设定了“按钮迁移信息”以及“执行指令”的按钮进行多路复用来实现。

并且，通过活用页面以及按钮，可以实现再生拍摄的影像的再生菜单等具有交互性的用户界面。

例如在实现图45所示的被多层化的菜单的情况下，按照主菜单和两个子菜单，准备汇总想要在各个菜单中表示的按钮的页面。在主菜单中设置汇总按钮1和2的页面1，在子菜单1设置表示按钮3的页面2，在子菜单2设置汇总按钮4和5的页面3，并在上述的流中进行多路复用。

从主菜单迁移到子菜单准备像按钮1和2这样的菜单迁移用按钮，并设定为在按钮被按下时进行切换。例如，按钮1在进行将主菜单迁移到子菜单1的情况下，将在按下按钮时使页面1为关闭(off)使页面2为打开(on)的导航指令设定到所述执行指令区域。

并且，同样，按钮2在进行将主菜单迁移到子菜单2的情况下，将在按下按钮时使页面1为关闭(off)使页面2为打开(on)的导航指令设定到所述执行指令区域。

并且，可以在执行指令区域指定的导航指令除页面迁移以外还可以指定各种导航指令。例如，像按钮3可以设定在播放列表再生过程中设定切换章节的导航指令，像按钮5可以设定切换表示的字幕流的导航指令。

在此，在按钮的执行指令区域中，使播放列表的再生开始的导航指令被规定为不能指定，只有在上述的Object的Program区域能够指定。

因此，想在按下按钮4使播放列表XXX.PL再生的情况下，首先由该按钮向使播放列表XXX.PL再生的导航指令所描述的Object(图中的Object#N)迁移，并需要按照这个Object来执行希望再生的播放列表(图中为XXX.PL)的导航指令。

如以上说明，以页面以及按钮制作再生菜单的情况下，除页面以及按钮以外，需要用于执行由按钮来迁移且在按钮不能执行的导航指令的Object。利用图40和图41对Title和Object的关系进行了说明，不过，在Object中不仅存在由上述那样的Title参考的Object，而且还有可能存在由按钮参考的Object。

如以上说明，通过页面和按钮的组合可以容易地实现具有交互性的用户界面。

并且，在再生菜单等具有交互性的用户界面中，可以将BD-ROM的幻灯片模式功能活用到GUI绘制中。

首先，利用图46对V_PES中的幻灯片模式功能进行说明。首先对于该V_PES是否为幻灯片模式，是在例如该V_PES中所包含的AV数据的VOB管理信息文件VOBI中被设定的。

被设定是上述的幻灯片的V_PES，例如仅由所有的I帧(I画面)来构成，作为一张幻灯片来表示的画面的静止图像分别作为I帧被嵌入V_PES。同时，按照各I帧的开头在播放列表中设定了章节事件。

并且，各I帧的表示时间被设定为无限大或固定时间，被设定的时间经过或可以通过执行章节跳跃或后退进入前面的静止画面或返回到前面的静止画面。这样，可以通过I帧和章节来实现幻灯片模式功能。

在此，如利用图44所述的那样，在显示器组(NV_DS)中可以描述按钮的绘制内容，对于不设定绘制信息的按钮也可以实现。并且，运用按钮的执行指令区域也可以实现相当于章节跳跃和章节后退的按钮。

因此，将页面、按钮和幻灯片模式功能并用，将菜单的GUI绘制作为I帧影像设定到幻灯片模式，通过用户的操作可以在页面以及按钮上进行菜单的迁移或导航指令执行等菜单控制。

例如，若用图47来说明的话，首先将构成图47(A)所示的菜单的各个菜单画面影像作为I帧影像嵌入到V_PES来构成幻灯片模式。

其次，将图47(B)所示的菜单画面的迁移或按下时的工作由页面和按钮、以及从按钮迁移的Object来实现。具体而言，在选择缩略图F时，在按下遥控器的右按钮的情况下等，要想与切换菜单画面的情况相对应，只要将相当于章节变更的导航指令设定到按钮即可。

并且，在按下缩略图A时，在再生缩略图A所对应的动画的情况下，只要将按钮设定为在按钮按下时迁移到用于再生与缩略图A相对应的动画的Object即可。

如以上说明，在并用幻灯片模式、页面、以及按钮的情况下也可以实现菜单，这样的菜单在图42所示的一个MPEG-TS中被多路复用。

以下对在以BD-ROM形式记录了再生菜单的装置中的设定方法进行说明。如以上所述，在BD.INFO中，由于Topmenu是菜单专用的Title，因此，实现所述的菜单的MPEG-TS需要在Topmenu标题被选择之时被自动执行。

因此，制作由Topmenu参考的Object并注册到BD.PROG，在该Object的Program区域中，只要设定用于再生播放列表的导航指令即可，该播放列表用于再生实现所述菜单的MPEG-TS。

并且，对于在盘被插入时再生菜单被自动表示出来，只要进行以下工作即可，即：制作由FirstPlayback参考的Object并注册到BD.PROG，并在该Object的Program区域，将标题迁移的导航指令设定到TopMenu上。

在此，对于已经由其它的装置记录了影像的盘而言，设定为以自己的装置重新追记影像。此时在由Topmenu执行的再生菜单中，必然需要反映追记的影像的缩略图以及使该影像再生的导航信息。

然而，再生菜单的构成因各个公司而不同，对于由TopMenu参考的Object的Program区域是怎样组成的是不容易辨别的。

因此，则成为首先删除再生菜单之后，再以自己的装置生成。但是，在这种情况下，如实施例2所说明的那样，在删除再生菜单之时，虽然知道以BD.INFO规定的FirstPlayBack以及由TopMenu参考的Object是哪个，但是，要辨别从这里被再生的PlayList(再生构成图47说明的再生菜单的MPEG-TS的PlayList)是哪个的话，就需要逐次解析Object的Program区域。

并且，要想由以上所述的再生菜单的按钮再生PlayList，就需要从按钮迁移到PlayList再生用的Object，并由该Object再生PlayList。

要想辨别仅由这样的按钮参考的Object，就需要拆开构成再生菜单的MPEG-TS的多路复用，并逐次解析按钮的NV_DS，还需要逐次解析从按钮迁移的Object的ID，这是非常花费工夫的。

因此，在本实施例中，在再生包含FirstPlayback和TopMenu等NV_DS的流的Title，将从NV_DS迁移的Object的ID作为元数据来记录。

并且，该元数据被存储在图40的BD.INFO的ExtensionData中。

本实施例中的元数据的例子以图48来表示。

如图48所示，在BD.INFO的ExtensionData区域中存在：存储FirstPlayback的元数据的FirstPlaybackMeta()区域，和存储TopMenu的元数据的TopMenuMeta()区域。而且，还存在：按各个Title来表示各个Title的属性的Title Domain区域和存储各个Title的元数据的TitleMeta()区域。

Title Domain是表示Menu、Real、Virtaul、SlideShow这四个属性(Domain)中某一个的信息。

Menu Domain是再生菜单和Title所具有的属性，所述再生菜单是除FirstPlayback和TopMenu以外，使用户选择影像并再生影像的菜单，所述标题是实现在插入盘时自动再生序列控制等Title，且所述再生菜单和Title例如是从FirstPlayBack和TopMenu迁移的Title等。

Real Domain是顺序再生实际上拍摄或录制的影像的Title所具有的属性。

Virtual Domain是再生播放列表的Title所具有的属性，该播放列表是根据用户编辑拍摄或录制的影像的结果而制作的播放列表。

Slideshow Domain是再生幻灯片模式的Title所具有的属性。

FirstPlaybackMeta()和TopMenuMeta()以及TitleMeta()的结构相同。具体而言，包括：作为FirstPlayback和TopMenu以及各Title所参考的PlayList的文件名一览的PLNameList区域和作为参考的Object的ID一览的ObjectIDList区域。

并且，为了使各TitleMeta()具有PlayList的记录顺序信息，在PLNameList区域中记录的PlayList的文件名也可以是该PlayList的制作顺序。

以上对本实施例中的元数据的例子进行了说明，根据本实施例的元数据，不用解析各Title所参考的Object和从Object再生的流，就可以识别在各Title所使用的数据(PlayList以及由PlayList参考的数字流和作为程序群的Object)。

尤其是通过FirstPlaybackMeta()、TopMenuMeta()、以及所述Title DomainMenu解析作为Menu的Title的TitleMeta()，从而可以在该盘中构成再生菜单的数据(PlayList以及由PlayList参考的数字流和作为程序群的Object)。

为此，即使是其它装置制作的再生菜单也可以容易地删除。尤其是实现再生菜单的流中包含按钮(NV_DS)，即使Object被该按钮参考，也可以容易地识别，删除也容易。

并且，例如由TopMenu参考的Object和PlayList被任意的Title#A参考的情况下，若根据此元数据删除并编辑由TopMenu参考的Object和PlayList的话，就会妨碍Title#A的工作。

在这种情况下，作为标准，对于在Title作成的同时被作成的该Title所参考的Object和PlayList而言，可以禁止让以后作成的Title参考。

并且，在删除和编辑Object和PlayList之时，根据利用图48说明的元数据，事先检索该Object和PlayList是否由其它的Title参考，若没被参考就可以删除。

并且，可以使PLNameList区域以及ObjectIDList区域持有，参考该PlayList或Object的Title的逆参考信息等。

以上对本发明的实施例3进行了说明，本实施例的记录方法以及数据结构可以适用于实现记录各Title属下的PlayList以及Object元数据的信息记录介质、记录信息记录介质的记录装置、记录方法、记录程序、以及本实施例的记录方法的半导体。

(实施例4)

以往，在将由电视摄像机拍摄的影像等逐次记录到盘上的情况下，在以BD-ROM形式记录影像时不存在保持影像的记录顺序的方法，所述BD-ROM形式是指将影像以次世代光盘的商业用影像数据用的格式来表示的形式。

因此，作为实施例4对以下的记录方法进行说明，即：将BD-ROM的扩展区域中记录的元数据按照记录顺序来配置，且禁止因编辑而导致的顺序调换。

根据此记录方法，在以BD-ROM形式记录以电视摄像机拍摄的影像的情况下，可以保持拍摄的影像的拍摄顺序，在再生菜单中可以以用户所期待的顺序来排列拍摄的影像的缩略图。

而且，在本实施例中，记录拍摄的影像的AV流与实施例3相同，是MPEG-TS形式的流(参照图42)。

并且，在本实施例中对这样一种记录方法进行说明，即：在电视摄像机和放置型电视记录器等中，以BD-ROM形式来记录拍摄或录制的影像的方法。

首先对拍摄单位和BD管理信息的对应关系进行说明。

拍摄的影像以及声音分别作为V_PES以及A_PES被记录到上述的图42所示的MPEG-TS形式的流中。在此，按下开始拍摄按钮后再放开按钮，或将直到按下停止拍摄按钮为止的拍摄单位称为Shot，一个Shot可以作为一个流来记录，一个流中可以存储多个Shot。

在此，Shot以各个Shot或以拍摄日等分组为单位与所述的播放列表(PlayList)相关联。并且，最终以每一个PlayList或PlayList为单位与在作为上述的BD管理信息的BD.INFO所管理的Title相关联。

在图16中对播放列表“XXX.PL”进行了详细的说明，不过，在本实施例中所述的电视摄像机等所拍摄的流中，必定以作为拍摄单位的Shot为单位，附加由播放列表管理的EVENT(Mark)。

如以上所述，作为拍摄单位的Shot与播放列表中的Mark一一相对。因此，Shot的拍摄日期时间和Shot的缩略图等与Shot有关的数据的管理也以Mark为单位来进行，从而Shot和与Shot相关的数据的对应关系就会变得明确，使参考和管理变得容易。

以上，对作为拍摄单位的Shot和BD管理信息中的Mark的对应关系进行了说明，不过说到底BD-ROM形式是用于记录和分发预先编辑的电影等。

为此，例如上述的Shot的拍摄日期时间和相对应的缩略图等，在记录拍摄的影像时，在BD管理信息中存在有不能记录的信息。

因此，在本实施例中，将这些在BD管理信息中不能记录的信息作为元数据另行管理。

作为元数据的存储位置可以存储到与BD管理信息不同的其它的文件中，也可以存储到BD管理信息的各个扩展区域中。

BD管理信息的扩展区域相当于实施例2中说明的“Extension”区域。

例如，在图18中对以BD-ROM形式记录的盘被插入时，作为BD-Player最先读出的BD管理信息的BD.INFO进行了详细说明，加上利用图18说明的结构，在数据的末尾具有作为扩展区域的IndexExtensionData()。

因此，在本实施例中，对于以所述BD-ROM不能规定的信息，可以在IndexExtensionData()规定。并且，不言而喻的是，可以分开PlayList和VOB管理信息文件(ClipInformation)的扩展区域，并存储元数据。

在本实施例规定的IndexExtensionData()的例子以图49示出。

图49示出了将本实施例规定的元数据存储到作为BD.INFO的扩展区域的IndexExtensionData()的一个例子。

并且，在本实施例中并非受此所限，例如，可以使与BD.INFO不同的文件记录并持有具有图49所示的结构以及数据的元数据，也可以将图49所示的元数据分到BD管理信息的各文件，从而使BD管理信息的各文件持有图49所示的元数据。

首先，使所述的BD管理信息“BD.INFO”的末尾的IndexExtensionData()持有两个区域，即“DiscInfo”区域和“PLTable”区域。

“DiscInfo”区域是用于存储有关盘全体的元数据的区域，例如，“Disc标题”中存储有盘的标题信息，“Disc缩略图”中存储有与代表盘的缩略图像有关的信息。

“PLTable”区域是BD管理信息之一，是将有关PlayList的元数据以PlayList为单位来存储的区域，包括“PL_Number”区域和各PlayList的元数据区域(图中的“PL#1”～“PL#m”)。

“PL_Number”和播放列表“XXX.PL”的文件总数的数量相同，以后各PlayList(播放列表“XXX.PL”)的元数据从“PL#1”开始按顺序被存储。

各PlayList的元数据例如包括五个区域，即：“PL_FileName”区域、“PL_Type”区域、“PL作成日期时间”区域、“PL标题”区域、以及“MarkTable”区域。

“PL_FileName”区域是表示该元数据区域(“PL#1”～“PL#m”)将要存储哪个PlayList的元数据的信息，例如PlayList文件“XXX.PL”的文件名“XXX”被存储。

并且，“PL_Type”区域中存储有该PlayList的类别。由于在BD-ROM中影像全部被预先编辑，因此PlayList中没有设置类别的必要性，将拍摄或录制的影像以BD-ROM形式记录的情况大致可以分为两个。

首先，第一个是：从头开始再生拍摄或录制的原始影像的方案是被记录的PlayList，以后在本实施例中称为Real PlayList。

另一个是：用户对原始影像的再生顺序进行调整或再生位置的指定等进行编辑的方案是被记录的PlayList，以后在本实施例中称为Virtual PlayList。

在此，对于作为拍摄或录制的影像的单位的Shot和Real PlayList及Virtual PlayList的对应关系，以图50来示出。

如图50所示，Real Playkist将拍摄的Shot所存储的流按拍摄顺序再生，一般来说流在被记录之时与流信息一起被生成。

并且，Real PlayList例如在Shot的拍摄后被追加或被修正。

另外，Virtual PlayList用于以所希望的顺序再生用户进行影像编辑的结果，即记录的影像的一部分，是在用户进行编辑处理时被作成的。

这样，拍摄或录制的流有可能被多个PlayList所参考。为此，在删除PlayList之时，同时该PlayList所参考的流也被删除，这样就有可能出现参考不存在的流的PlayList。

因此，由于某个流必定要被一个Real PlayList所参考，所以，可以在删除Virtual PlayList时不删除参考的流及流信息，在删除Real PlayList时删除参考的流及流信息，并修正参照该流的Virtual PlayList。

以上，对Real PlayList和Virtual PlayList进行了说明，这些识别信息可以被存储到“PL_Type”。

并且，由于容易判断出菜单所用的流是哪个流，因此，可以使所述“PL_Type”持有参考菜单所用的流的PlayList，也可以使后述的Mark所用的元数据和流信息的元数据持有参考菜单所用的流的PlayList。

并且，在图34的说明中的程序可以使所述“PL_Type”持有参考被多路复用的流(Interactive Graphics(IG)Stream)的PlayList，也可以使后述的Mark所用的元数据和流信息的元数据持有。

例如，在为实现幻灯片模式的PlayList的情况下，也有在该流中包含用于将页面送往下一页和返回上一页的按钮以及按钮指令(IG Stream)的情况。

在这种情况下，例如以某装置作成幻灯片模式后，在以其它的装置变更该幻灯片的情况下，可以判断是进行单纯编辑为好，还是有必要将IGStream包含在其中一起进行编辑为好。

例如，由上述的PL_Type所指定的标识符判明了是包含有IG Stream的Real PlayList的情况下，该装置首先检测IG Stream，在删除检测出的所有IG Stream之后，才可以编辑幻灯片模式。

并且，虽然图中没有示出，例如可以使本实施例的元数据中的“DiscInfo”持有表示某盘是否为某个装置所记录的盘的信息。

据此，记录装置可以辨别包含所述IG Stream的流是否为该装置作成的。

例如，根据所述PL_Type辨别到是包含IG Stream的PlayList的情况下，在是该装置制作的情况下可以直接修正。

以下继续说明图49。

在“PL作成日期时间”区域中记录制作该PlayList的日期时间。

在“PL标题”区域中记录PlayList的标题名。

“MarkTable”区域是存储该PlayList元数据所参考的PlayList管理的各Mark的元数据的区域，包括“Mark_Number”区域和各Mark的元数据区域(图中的“Mark#1”～“Mark#n”)。

在图49所示的例子中，“Mark_Number”和该PlayList所管理的Mark的数量相同，以后按照该PlayList所管理的顺序，从“Mark#1”开始顺序存储每个Mark的元数据。

并且，在本实施例中虽然PlayList所管理的Mark和以元数据管理的Mark是被一一对应地描述的，但并非仅限于此。

例如，表示暂时停止再生的位置的Mark等BD管理信息中，对于不能规定的Mark可以以元数据来管理。

在这种情况下，例如图49所示的Mark的元数据区域中，表示是否参考以BD管理信息规定的Mark的信息，和(1)对于在参考的情况下存储该Mark的ID的区域，或(2)在不参考的情况下存储以元数据管理的Mark所指出的流的位置信息的区域要分别设置。

各Mark的元数据例如包括四个区域，即：“Mark_Type”区域、“缩略图”区域、“拍摄日期时间”区域、以及“PL参考信息”区域。

“Mark_Type”区域记录以该PlayList管理的Mark的类别，在本实施例中表示该Mark是否为表示Shot的开头的Mark(Shot-Mark)。

在这种情况下，在Mark的功能性质上，管理表示Shot的开头的Mark的则仅为上述的Real PlayList。

并且，在本实施例中，将相当于代表该PlayList的缩略图的流位置作为Mark来管理。

具体而言，使“Mark_Type”区域持有一种信息，该信息用于识别该Mark是否为表示PlayList的代表缩略图的Mark(PL-Mark)。另外，也可以规定是否为用户附加的BookMark等。

其次，“缩略图”区域将该Mark所指出的流位置中的图像作为缩略图来指定。

并且，该Mark是表示Shot的开头的Mark的情况下，基本上是将Shot开头的图像作为缩略图来设定。但是，为了参考代表Shot的缩略图，不是将该Mark所指出的流位置的图像作为代表缩略图，而是将根据用户的设定或自动辨别等而抽出的、与该Mark所指出的流位置不同的位置的图像作为缩略图。

“拍摄日期时间”区域在该Mark是表示Shot的开头的Mark的情况下，记录该Shot的拍摄日期时间。

“PL参考信息”区域是只有在该Mark是表示Shot的开头的Mark的情况下才设定的区域，存储参考该Shot的PlayList的参考信息。

如以上所述，此PL参考信息在该Shot或包含该Shot的流被删除之时，为了容易地检索参考该Shot且在删除时需要修正的PlayList而被附加的信息。

并且，如以上所述，Shot和管理该Shot的Real PlayList的关系是，在一方被删除的时候另一方也被自动删除。因此，“PL参考信息”区域中所存储的参考信息是针对Virtual PlayList的参考信息。

并且，在进行Real PlayList的编辑和删除时，为了效率良好地确定应该被更新的Virtual PlayList，事先分别对Real PlayList和Virtual PlayList的播放列表文件号码进行定义。这样，在进行Real PlayList的编辑时，可以瞬时确定应该确认内容的播放列表。在这种情况下，不需要BD.INFO的Extension这样的特殊信息。

以上，对本实施例中的元数据的种类和元数据的存储方法进行了说明，在将Shot作为一览菜单来表示时，通过按照拍摄和录制的顺序来表示缩略图，从而可以容易地抓住Shot的相关关系，提高用户的便利性。

在本实施例中为了容易排列拍摄和录制的顺序分类以及菜单的表示，因此将在如图49所示的元数据中存储PlayList的元数据(图中为“PL#1”～“PL#m”)的顺序作为记录顺序来存储。

基本上是PlayList的元数据的存储位置是不会因编辑等而变更的。并且，如图51所示，在Real PlayList中，表示Shot的开头的Mark、PlayList中的Mark的附加顺序以及该Mark的元数据的记录顺序也是按照拍摄顺序排列的，此顺序在除删除以外是不会因编辑等而被调换的。

这样，根据Real PlayList的元数据的存储顺序和该Real PlayList所管理的Mark中表示Shot的开头的Mark的元数据的存储顺序，从而可以识别在该盘中记录的Shot的拍摄及录制顺序。

据此，在生成按照Shot的拍摄顺序对缩略图和拍摄日期时间等进行一览表示的再生菜单的情况下，仅参照图49所示的元数据即可。

并且，“PL_Type”依次解析作为Real PlayList的PlayList的元数据，在该PlayList的元数据中，依次参照作为Mark_Type＝Shot-Mark(该Mark表示Shot的开头)的Mark的元数据菜单，并进行菜单表示即可。

例如，假想本实施例的元数据是图52(A)简单表示的状态。在这种情况下，PlayList#1、#2、#4是Real PlayList，PlayList#3是Virtual PlayList。

因此，PlayList的记录顺序为PlayList#1、#2、#4。

并且，在图中附加了“(Shot)”的Mark示出是表示Shot的开头的Mark。

因此，若在各PlayList中抽出表示Shot的开头的Mark的记录顺序，则可以知道Shot的记录顺序为PlayList#1的Mark#1、#3，PlayList#2的Mark#1，PlayList#4的Mark#1、#2。

这样，最终可以将Shot的一览菜单表示为图52(B)所示那样。

并且，Real PlayList以及Virtual PlayList的作成顺序也可以根据上述元数据的存储顺序来识别。

并且，在各PlayList所管理的Mark中，通过Mark_Type检索表示PlayList的代表缩略图的Mark(PL-Mark)，从而可以在必要时按照作成PlayList的缩略图的顺序来作成一览表示的菜单。

以上，对本实施例4进行了说明，实施例4的记录方法以及数据结构可以适用于一种半导体，该半导体可以实现在拍摄或录制的影像以BD-ROM形式被记录的情况下，为了保持影像的记录顺序而记录元数据的信息记录介质和记录该信息记录介质的记录装置、记录方法、记录程序、以及实施例4中的记录方法。

(实施例5)

以往，在逐次将电视摄像机拍摄的影像等记录到盘中的情况下，在以次世代盘的商业用影像数据所使用的格式记录影像时，即以BD-ROM形式记录影像时，没有保持影像的拍摄日期时间的方法。

因此，在实施例5将对一种记录方法进行说明，这种记录方法是：将按照每个拍摄的影像的拍摄日期时间信息作为元数据记录到BD-ROM的扩展区域中。

根据此记录方法，即使在以BD-ROM形式来记录电视摄像机拍摄的影像的情况下，也可以保持拍摄的影像的拍摄日期时间，并可以以适当的形式将拍摄的影像的拍摄日期时间提示给用户。

并且，在本实施例中，记录拍摄的影像的AV流与实施例3相同，为MPEG-TS形式的流(参照图42)。

并且，在本实施例中对这样一种记录的方法进行说明，这种记录的方法是指：在电视摄像机和放置型电视记录器等中，以BD-ROM形式将拍摄或录制的影像记录到信息记录介质中。

并且，在本实施例中作为信息记录介质的一个例子，以次世代盘即BD-ROM Disc为例进行说明，但本发明并非受此所限。

例如，在本实施例中，将应用程序及数据结构写入到DVD等光盘或其它的信息记录介质，即存储卡(SD存储卡或内存棒等)或硬盘等也可以得到同样的效果。

并且，不仅是信息记录介质，在通过网络分发本实施例中的应用程序及数据结构的情况下也可以得到同样的效果。

拍摄的单位和BD管理信息的对应关系与实施例4相同。

即，拍摄的影像以及声音分别作为V_PES以及A_PES被记录到以前所述的图42所示出的MPEG-TS形式的流中。

在此，将按下拍摄开始按钮之后再放开按钮、或直到按下停止拍摄按钮为止等，这些用户拍摄或录制的影像的单位(拍摄单位)称为Shot，一个Shot可以作为一个流来记录，一个流中也可以存储多个Shot。

以后将叙述详细内容，Shot是按照每个Shot或每个拍摄日期等分组为单位与所述的播放列表(PlayList)相关联来被管理的，在各Shot的开头设定有在该播放列表所管理的Event。

在本发明的实施例1中，对利用图18以BD管理信息中的一个来管理盘全体的信息的“BD.INFO”为例进行了说明，在本实施例中以图53的形式为例。

图53所示的BD.INFO在盘中仅存在一个，在该盘被插入时最先被解释。图53所示的BD.INFO包括：“AppInfo”、“TitleList”、以及“ExtensionData”，在“AppInfo”中存储有有关盘全体的信息。

在“TitleList”中存储有在该盘中所存储的标题的信息，该“TitleList”包括：“FirstPlayback”和“TopMenu”这两个特殊的标题以及多个通常的标题。

通常的标题的总数被存储在“TitleList”以下的“Number”中。“FirstPlayback”和“TopMenu”以及各“Title”分别持有向后述的Object链接的信息(Object的ID)，所述Object是在标题选择时应该执行的Object。

FirstPlayback是盘在插入时最先被选择的标题，TopMenu是在通过遥控器按下菜单按钮时等被选择的再生菜单所使用的标题。

并且，在本实施例中存储有关Object的信息的“BD.PROG”数据结构与在以前的实施例中以图3和图41说明的BD.PROG的数据结构相同。

并且，图41所示的“BD.PROG”在实施例1中利用图18所说明的“BD.PROG”之上有所改变，并且，废除利用图17所说明的“XXX.PROG”。

以上，对本实施例中的BD管理信息进行了说明，管理所述Shot的播放列表以各播放列表为单位，与所述的BD管理信息即BD.INFO所管理的Title相关联。

具体而言，在Title所参考的Object中描述有再生该Title所对应的播放列表的导航指令。

并且，在图16中对播放列表“XXX.PL”进行了详细的说明，对以播放列表管理的事件以后称为Mark。正如以上所述，Mark用来定义该播放列表内所生成的事件(Mark)，在播放列表以ID来管理多个Mark。

并且，各Mark包括：Mark的类别(Mark_Type)、Mark的ID(Mark_ID)，事件(Mark)的生成时刻(Time)、以及有效期间(Duration)。在此，在作为Mark的类别的Mark_Type中有两个类别，即：EntryMark和LinkPoint。

EntryMark作为Chapter，是用户可以识别的Mark，通过向用户提供是从播放列表的开头的第几个EntryMark，从而可以提示Chapter号码。

并且，可以将由遥控器操作所再生的章节切换为前后的章节。

LinkPoint是用户不能识别的Mark，作为上述这样的Chapter不被识别，主要用于来自程序的再生位置的指定等、作为以程序识别的再生时刻信息来使用。

以上对Mark进行了说明，在管理以在本实施例中所述的电视摄像机等拍摄或录制的影像的播放列表中，以各拍摄单位的Shot，对于在该Shot开头的再生时刻，必需设定以该播放列表所管理的EntryMark。

据此，作为拍摄单位的Shot与播放列表的EntryMark一一对应。这样，用户就可以将拍摄的Shot作为Chapter来识别，通过对Chapter的切换从而可以选择再生的Shot。

并且，在本实施例中，Shot的拍摄日期时间和Shot的缩略图等有关Shot的信息的管理也以EntryMark为单位来进行。据此，可以明确Shot和与Shot相关的数据的对应关系，使参考和管理变得容易。

以上，对作为拍摄单位的Shot和BD管理信息中的Mark的对应关系进行了说明，由于BD-ROM形式毕竟是用于记录和分发事先编辑的电影等的，例如所述的Shot的拍摄日期时间和缩略图等，在记录拍摄的影像的情况下，在BD管理信息中存在有若干个不能记录的信息。

因此，在本实施例中，将这些在BD管理信息中不能记录的信息作为元数据另行管理。作为元数据的存储位置，可以存储在与BD管理信息不同的文件中，也可以存储在BD管理信息的各个扩展区域中。

BD管理信息的扩展区域是相当于在实施例2中说明的“Extension”区域。

在本实施例中BD.INFO作为图53所示的数据的末尾的扩展区域，持有IndexExtensionData()。并且，对于存储各播放列表信息的XXX.PL的详细已利用图16进行了说明，不过，在播放列表XXX.PL中加上利用图16所说明的结构，就可以作为图54所示那样，作为数据末尾的扩展区域持有PlayListExtensionData()。

因此，在本实施例中，将不能以所述的BD-ROM规定的信息以IndexExtensionData()和PlayListExtensionData()来规定。

并且，不言而喻的是，以下将要叙述的元数据的存储方法只不过是一个例子，将以下将要叙述的信息作为元数据来存储是重要之处，可以存储到VOB管理信息文件(ClipInformation)的扩展区域，也可以采取其它的结构。

对于在本实施例所规定的IndexExtensionData()的例子将利用图53来说明。

首先，使所述的BD管理信息“BD.INFO”末尾的IndexExtensionData()持有两个区域，即：“DiscInfo”区域和“PLTable”区域。

“DiscInfo”区域是用于存储有关盘全体的元数据的区域。例如，在“Disc标题”中存储Disc的标题信息，在“Disc缩略图”中存储有关代表盘的缩略图像的信息。

“PLTable”区域是存储作为BD管理信息之一的PlayList的元数据的区域，该“PLTable”区域包括“PL_Number”区域和各PlayList的元数据区域(图中的“PL#1”～“PL#m”)。

“PL_Number”和播放列表“XXX.PL”的文件总数相同，以后每个PlayList(播放列表“XXX.PL”)的元数据从“PL#1”开始按顺序被存储。

各PlayList的元数据例如具有“PL_FileName”区域和“PL_Type”区域。

“PL_FileName”区域具有表示该元数据区域(“PL#1”～”PL#m”)存储哪个PlayList的元数据的信息。例如存储了PlayList文件“XXX.PL”的文件名“XXX”部分。

并且，在“PL_Type”区域存储该PlayList的类别。在BD-ROM由于影像全部是预先被制作的，因此在PlayList中设定类别是没有必要的，在以BD-ROM形式记录拍摄或录制的影像的情况下大致可以分为两大类。

首先，第一个是以后在本实施例中被称为Real PlayList的PlayList，其管理拍摄或录制的原始影像，并记录从开头开始依次再生的方案。

另一个是以后在本实施例中被称为Virtual PlayList的PlayList，其记录用户对原始影像所进行的再生顺序的调换或再生位置的指定等编辑的方案。

作为拍摄或录制的影像的单位的Shot和Real PlayList、VirtualPlayList的对应关系与在实施例4中利用图50说明的对应关系相同。

即，如图50所示，Real PlayList用于将拍摄的Shot中所存储的流按照拍摄顺序再生，基本上在流被记录之时与流信息一起被生成。例如Real PlayList在Shot的拍摄后被追加或被修正。

另外，Virtual PlayList作为用户所进行的影像编辑的结果，以所希望的顺序来再生记录的影像的一部分，Virtual PlayList在用户的编辑处理时被作成。

这样，拍摄或录制的流就有可能由多个PlayList来参考。为此，在删除某PlayList之时，当该PlayList所参考的流也同时被删除时，就有可能出现参考不存在的流的PlayList。

因此，由于必需要由一个Real PlayList来参考，所以可以在删除Virtual PlayList之时参考的流及流信息不被删除，而在删除RealPlayList之时参考的流及流信息被删除，并可以修正参考该流的VirtualPlayList。

以上对Real PlayList和Virtual PlayList进行了说明，可以将这些识别信息存储到所述“PL_Type”。并且作为其它的类别，还可以设定表示以该播放列表再生的流为菜单用的流的类别，或表示为幻灯片模式的类别。

并且，可以将参考图34所说明的程序被多路复用的流(Interactive Graphics(IG)Stream)的Playlist与所述“PL_Type”一起记录。

例如，当该播放列表的PL_Type为幻灯片模式的情况下，该流也有可能包含用于进入下一页和返回上一页的按钮以及按钮指令(IG Stream)。

在这种情况下，例如以某装置作成幻灯片模式后，在以其它的装置变更该幻灯片的情况下，可以判断是进行单纯编辑为好，还是有必要将IGStream包含在其中，一起进行编辑为好。

例如，由上述的PL_Type所指定的标识符判明了是包含有IG Stream的幻灯片模式的情况下，该装置首先检测IG Stream，在删除检测出的所有IG Stream之后，才可以编辑幻灯片模式。

并且，虽然图中没有示出，例如可以使本实施例的元数据中的“DiscInfo”持有表示某盘是否为某个装置所记录的盘的信息。

据此，记录装置可以辨别包含所述IG Stream的幻灯片模式是否为该装置作成的。

例如，根据所述PL_Type辨别到是包含IG Stream的幻灯片模式的情况下，在是该装置制作的情况下可以直接修正。

其次，在本实施例规定的PlayListExtensionData()的例子由图54示出。

PlayListExtensionData()包括四个区域，即：“PL作成日期时间”区域、“PL标题”区域、“PL缩略图”区域、以及“MarkTable”区域。

在“PL作成日期时间”区域中记录制作该PlayList的日期时间。

在“PL标题”区域中记录PlayList的标题名。

“PL缩略图”区域记录对于代表该PlayList的缩略图的参考信息。

“MarkTable”区域是存储该PlayList元数据所参考的PlayList管理的各Mark的元数据的区域，包括“Mark_Number”区域和各Mark的元数据区域(图中的“Mark#1”～“Mark#n”)。

在图54所示的例子中，“Mark_Number”和该PlayList所管理的Mark的数量相同，以后按照该PlayList所管理的顺序，从“Mark#1”开始顺序存储每个Mark的元数据。

并且，在本实施例中所描述的PlayList所管理的Mark和以元数据所管理Mark是一一对应的，但本发明并非受此所限。

例如，表示暂时停止再生的位置的Mark等BD管理信息中，对于不能规定的Mark可以以元数据来管理。

在这种情况下，例如图54所示的Mark的元数据区域中，表示是否参考以BD管理信息规定的Mark的信息，和(1)对于在参考的情况下存储该Mark的ID的区域，或(2)在不参考的情况下存储以元数据管理的Mark所指出的流的位置信息的区域要分别设置。

各Mark的元数据例如包括三个区域，即：“Mark_Type”区域、“缩略图”区域、以及“拍摄日期时间”区域。

“Mark_Type”区域记录以该PlayList所管理的Mark的类别。作为Mark_type之一，例如有Shot-Mark，该Shot-Mark是表示该Mark是Shot开头的Mark。管理这个Shot-Mark可以仅依据所述的Real PlayList。

作为其它的Mark_Type，除了后述的OldShotMark以外，还可以定义例如表示幻灯片模式中各静止图像的开始位置的SlideshowMark。

例如，Real PlayList所再生的流允许动画和幻灯片模式混在的情况下，可以根据该SlideshowMark和ShotMark，来辨别各Chapter是动画还是是静止图像。

并且，即使在菜单表示中仅表示动画Shot的缩略图，也可以使Mark为EntryMark，且Mark的元数据中的MarkType可以仅对ShotMark以缩略图的形式进行一览表示。

并且，可以事先定义被称为MakerPrivate的MarkType，从而可以实现制造厂商具有独自功能的Mark。

其次，“缩略图”区域将该Mark所指出的流位置中的图像作为缩略图来指定。并且，该Mark是表示Shot的开头的Mark的情况下，基本上是将Shot开头的图像作为缩略图来设定。

但是，为了参考代表Shot的缩略图，不是将该Mark所指出的流位置的图像作为代表缩略图，而是将根据用户的设定或自动辨别等而抽出的、与该Mark所指出的流位置不同的位置的图像作为缩略图。

“拍摄日期时间”区域在该Mark是表示Shot的开头的Mark的情况下，记录该Shot的拍摄日期时间。

并且，作为Mark的元数据被记录的信息不会受到上述内容的限定。例如，可以将以BD-ROM标准不能记录的、有关拍摄的信息的信息作为元数据使BD.INFO持有。

以上，对本实施例中的元数据的种类和存储方法进行了说明。在将Shot作为一览菜单来表示时，通过按照拍摄和录制的顺序来表示缩略图，从而可以容易地抓住Shot的相关关系，提高用户的便利性。

在本实施例中为了容易排列拍摄和录制的顺序以及菜单的表示，因此将在如图53和图54所示的元数据中，存储图53中的PlayList的元数据(图中为“PL#1”～“PL#m”)的顺序作为记录顺序来存储。

并且，基本上是PlayList的元数据的存储位置是不会因编辑等而变更的。并且如以上图51所示那样，在Real PlayList中，表示Shot的开头的Shot-Mark是按照该Shot的拍摄顺序排列的，当然作为播放列表所管理的Mark的附加顺序及图54说明的该Mark的元数据的记录顺序也是按照拍摄顺序排列的。

并且，除删除以外，该顺序是不会因编辑等被调换的。这样，根据Real PlayList的元数据的存储顺序和该Real PlayList所管理的Mark中表示Shot的开头的Mark的元数据的存储顺序，从而可以识别在该盘中记录的Shot的拍摄及录制顺序。

据此，在生成按照Shot的拍摄顺序对缩略图和拍摄日期时间等进行一览表示的再生菜单的情况下，可以仅参考图53和图54所示的元数据即可。

并且，“PL_Type”依次解析作为Real PlayList的PlayList的元数据，在该PlayList的元数据中，依次参照作为Mark_Type＝Shot-Mark(该Mark表示Shot的开头)的Mark的元数据菜单，并进行菜单表示即可。

例如，假想本实施例的元数据是图55(A)简单表示的状态。在这种情况下，PlayList#1、#2、#4是Real PlayList，PlayList#3是Virtual PlayList。

因此，PlayList的记录顺序为PlayList#1、#2、#4。

并且，在图中附加了“(Shot)”的Mark表示是表示Shot的开头的Mark。并且，在图中附加了“(OldShot)”的Mark表示后述的用于保持丢失的元数据的Mark。

因此，若在各PlayList中抽出表示Shot的开头的Mark的记录顺序，则可以知道Shot的记录顺序为PlayList#1的Mark#1、#3，PlayList#2的Mark#1，PlayList#4的Mark#1、#2。

这样，最终可以将Shot的一览菜单表示为图55(B)所示那样。

如以上说明，根据本实施例的记录方法以及数据结构，可以管理拍摄或录制的影像(Shot)的记录顺序，并且，可以将按照每个Shot拍摄或录制的影像的拍摄日期时间和缩略图的信息作为元数据来管理。

(实施例6)

以下对本发明的实施例6进行说明。

另外，在本实施例中作为信息记录介质的例子列举了作为次世代盘的BD-ROM Disc，这只不过是一个例子，将本实施例中的应用程序以及数据结构写入到DVD等光盘或其它的信息记录介质，即存储卡(SD存储卡或内存棒等)或硬盘等也可以得到同样的效果。

并且，不仅是信息记录介质，在通过网络分发本实施例中的应用程序及数据结构的情况下也可以得到同样的效果。

在实施例5中，对以Shot为单位将以拍摄或录制的影像的拍摄日期时间和缩略图这些在BD-ROM标准不能记录的信息记录到信息记录介质中的方法进行了说明。

在实施例6中，对由Shot的编辑工作来解决Shot的拍摄日期时间和缩略图这些信息丢失的问题的记录方法进行了说明。

上述问题的具体例子将利用图56来进行说明。

首先，作为初始状态，如图56(A)所示，假设一个播放列表(RealPlayList)管理拍摄时间为20分钟的三个Shot(Shot1～Shot3)。

在此，如图55(A)所示，将MarkType＝ShotMark的Mark附加到各Shot的开头，对于各Shot的拍摄日期时间和缩略图，在需要的情况下可以像实施例6所述那样，以Mark的元数据来管理所述的摄影时间等信息。

并且，ShotMark在本实施例中为用于让用户作为Chapter来判别的EntryMark。

由以上说明的初期状态，假想如图56(B)所示的将Shot1和Shot2结合并进行编辑。此时，Shot2接在Shot1的后边，Shot1和Shot2结合起来则成为一个Shot，即拍摄时间为40分钟的Shot1。而且，在Shot2的开头附加的ShotMark被删除。

以这种状态，假想这样一种情况，即如图56(C)所示，对Shot1进行分割编辑，此分割位置为比以前的Shot2的开头错开5分钟的时间位置，即在第25分钟的时间位置上进行分割。

将这样分割出来的新的Shot设为Shot4，在Shot4的开头也重新设定MarkType＝ShotMark的EntryMark，记录Mark的元数据。

此时，不能正确计算Shot4的拍摄日期时间。在此，例如，Shot1的拍摄日期时间为“9月1日12点0分”，可以考虑到加上所述的分割的时间位置即25分钟。但是，通过这个加法得到的“9月1日12点25分”这个日期时间不是正确的Shot4的拍摄日期时间。

这样，通过进行Shot的结合及分割处理，就会出现丢失Shot的拍摄日期时间的问题。

因此，在本实施例中，作为MarkType重新设定称为OldShotMark的这个MarkType。

此MarkType＝OldshotMark是用于保持因图56(B)所示的处理而丢失的元数据的Mark，不是用于让用户作为Chapter来识别的Mark。为此，在本实施例中MarkType＝OldShotMark只能设定在LinkPoint中。

根据编辑处理也可以保持Shot的拍摄日期时间等元数据，例如对于可以设定Shot的正确的拍摄日期时间的本实施例的具体内容，将利用图57进行说明。

首先，图57(A)表示初始状态。这与图56(A)所示的初始状态相同。并且，假想以后所要进行的编辑也与图56(B)所示的编辑内容相同。

即，从图57(A)所示的初始状态，如图57(B)所示的对Shot1和Shot2进行结合处理从而生成Shot4，并进行编辑。

此时，首先应该在Shot4的开头附加的EntryMark与Shot1相同，因此可以不进行特别的处理。

另一方面，由于Shot2消失，因此将附加在Shot2开头的MarkType＝ShotMark的EntryMark变更为LinkPoint。

之后，将利用图54说明的MarkType从ShotMark变更为OldShotMark。据此，表示Shot2的开头的Mark作为BD-ROM中的管理信息被保持在LinkPoint中。为此，与Mark一一对应管理的Mark的元数据也会被保持。

之后，如图57(C)所示，在从Shot4的开头到25分钟的位置上将Shot4分割为两个并进行编辑，从而生成Shot5和Shot6这两个Shot，并进行编辑。

此时，应该附加在Shot5的开头的EntryMark与Shot4的相同，因此不必进行特殊的处理。

另一方面，由于在Shot6的开头没有设定EntryMark，因此，需要在Shot6的开头重新设定MarkType＝ShotMark的EntryMark。并且，该EntryMark的元数据也重新记录。

以下说明这时的Shot6的拍摄日期时间的计算方法。首先，在分割前的Shot4，检索位于分割地点的、在Shot6的开头之前存在的Mark。

在此，在检测MarkType＝OldShotMark的LinkPoint之前，检测MarkType＝ShotMark的EntryMark，即在到达Shot4的开头的情况下，单纯地将分割的地点的时间加到Shot4的拍摄日期时间，从而成为Shot4的拍摄日期时间。

但是，在本实施例的情况下，如图57(C)所示，由于在比以前的Shot2的开头靠后的位置分割了Shot4，因此MarkType＝OldShotMark的LinkPoint先被检测。

此时，在以前的Shot2的开头参考MarkType＝OldShotMark的LinkPoint的元数据，就可以得到“9月5日9点30分”这个日期时间信息。

之后，从检测出的MarkType＝OldShotMark的LinkPoint位置(以前的Shot2的开头)到Shot6的开头的再生时间为5分钟，将这5分钟加到刚才得到的日期时间信息(9月5日9点30分)上。

这样算出来的“9月5日9点35分”这个正确的日期时间信息是Shot6的拍摄日期时间信息。

而且，虽然在此没有图示，在图57(B)所示的Shot4开头的位置是从开头开始20分钟的位置，即在以前的Shot2的开头的位置来分割的情况下，只是将表示以前的Shot2的开头的LinkPoint变更为EntryMark，将Mark的元数据中的MarkType变更为Shotmark即可。

而且，利用图56及图57说明的例子是说明Shot的结合和分割时发生的问题的例子，即由指定流的再生位置的Real PlayList的再生控制数据的变更造成在编辑作业中发生的问题的例子。

然而，适用于删除Shot中的某个区间，即适用于编辑AV流本身的情况。

例如可以是，在删除流的一部分的情况下，在紧接着删除部分的再生时刻设定Mark，采用与图57(C)所示的方法相同的方法计算拍摄日期时间，并将计算出的拍摄日期时间设定为该Mark的元数据。

并且，对于是设Mark为EntryMark、元数据中的MarkType为ShotMark，还是设Mark为LinkPoint、元数据中的MArkType为OldShotMark，进行以下的判断。

即，通过处理删除部分的前后的影像，将删除部分的前后的影像分别作为其它的Shot来处理的情况下设定前者，在结合删除部分的前后的影像并作为一个Shot来处理的情况下设定后者。

如以上所述，通过本实施例的记录方法以及数据结构，即使进行Shot的结合和分割这样的处理，也可以保持Shot的拍摄日期时间。

而且，除了将拍摄日期信息等拍摄以及录制的影像的信息作为元数据存储到BD-ROM的管理信息的扩展区域的方法以外，也可以嵌入到流中例如嵌入到SEI_MESSEGE中。

并且，即使在这种情况下进行分割等编辑处理，也可以在这个位置从流中检测出拍摄日期时间。

因此，可以不必进行以下的一连串的处理，即在进行如图56(B)所示的Shot的结合时，在使流中持有拍摄日期时间信息的情况下，如以上所述，将Shot2的EntryMark变更为LinkPoint，将MarkType＝ShotMark变更为OldShot。

并且可以是，在进行图56(C)所示的Shot的分割的情况下，首先调查流中的拍摄日期时间信息，在流中记录有拍摄日期时间信息的情况下，不进行利用图56(C)说明的拍摄日期时间计算处理，而从流中检测拍摄日期时间作为元数据来设定。

以上对本实施例5和6进行了说明，在这些实施例中所示的记录方法以及数据结构可以适用于一种半导体，这种半导体实现了在以BD-ROM形式记录拍摄或录制的影像的情况下，在保持影像的记录顺序的状态下记录元数据的信息记录介质、和记录信息记录介质的记录装置、记录方法、记录程序以及这些实施例的记录方法。

并且，根据实施例5和6的记录方法以及数据结构，可以记录拍摄影像的顺序，尤其在民用装置产业具有利用的可能性。

(实施例7)

以往，在流中记录元数据的情况下，其记录顺序是不明确的，若不对众多的元数据的所有数据进行检索并解析，就不会知道必要的元数据是否被记录了。

并且，在描述同一种类的元数据的不同元数据存在的情况下，出现的问题是读出装置的解析处理变得繁琐。

因此，在实施例7将对一种信息记录装置以及该信息记录装置中的记录方法进行说明，该信息记录装置在编码影像信息之时，同时编码影像信息的附属信息，该附属信息被附加于影像信息的各个图片中，一个附属信息包括识别信息(ID)和实际信息(数据)，在描述多个能够存储同一图片内的同一种类的信息的所述附属信息的情况下，记录具有规定的识别信息(ID)的附属信息。

通过此信息记录装置以及记录方法，可以提高元数据的检索性，即使同一种类的元数据以其它的方法被记录的情况下，可以按照装置的性能容易地进行解析。

而且，实施例7的内容是有关电影装置的元数据的内容。基本上是基于实施例1中的内容，以下以扩展部分和不同的部分为中心进行说明。

图58示出了PES数据包以下的数据结构。在使用BD或数字播放这样的MPEG-TS的情况下，一般为在一个PES数据包中存储一个图片。

以一个MPEG-4AVC编码的图片包括：表示访问单元的开头的AUDelimiter(Access Unit Delimiter)、表示定序属性的SPS(Sequence Parameter Set)、表示图片属性的PPS(Picture Parameter Set)、存储附属信息等的SEI(Supplemental Enhancement Information)、以及表示片符号信息的Slice等。

存储附属信息的SEI存储ClosedCaption信息和其它的信息。

在此，主要是将用于电视摄像机记录器的元数据作为HDM来管理并存储到SEI中。

在图59中示出了SEI的数据结构。如图中所示，可以根据识别信息(type_indicator)来确定被存储的数据种类，所述识别信息表示该SEI中有什么样的附属信息。

例如，若“type_indicator＝0x00000020”则可以知道HDM数据被存储。

HDM数据是包括HDM_pack_ID(8位)和HDM_pack_data(32位)的HDM_pack的集合。

根据此ID值表示是什么种类的附属信息被记录到后续的HDM_pack_data中。如在此所示，HDM_pack被连续地记录到HDM_meta()内。

并且，HDM_pack与DV(Digital Video)相机所使用的附属信息的DV包组件的数据结构(8位的ID+32位的数据)相同。

图60的表示出了HDM_pack的ID值和存储的信息之间的关系。

TIME列(高位的4位为0001b)的TIME CODE、BINARY GROUP，和CAMERA列(高位的4位为0111b)的全部的HDM_pack与DV包组件相同。

REC DATE和TIME是所述附属信息(图片)所拍摄的日期时间信息。

EXIF列(高位的4位为1010b)、GPS列(高位的4位为1011b、1100b)与数字静态相机所使用的Exif的信息相同。

但是，由于Exif所使用的32bit/32bit的RATIONAL表示法的大小比较大，因此以16bit/16bit的RATIONAL表示法。

EXIF OPTION和GPS OPTION是想要将表中没有记载的Exif/GPS的信息写入的情况下使用的包组件。

具体而言，在HDM_pack_data中描述有：将写Exif的Tag值的Exif_Tag(16位)、Exif中16位表示法的RATIONAL16、重新追加附有符号的SRATIONAL16的Exif_Type(8位)、以及表示后续的包组件的数的Pack_Length(8位)，并可以将Exif的元数据记录到后续的包组件中。

在MAKER列(高位的4位为1110b)中规定有：每16位描述的制造厂商代码和记录的模型代码的MAKER&MODEL包组件，和各制造厂商可独自使用的MAKER OPTION包组件。

这样，根据HDM_pack_ID值，可以马上确定记录了哪个数据的包组件。但是，若没有HDM_meta()中的记录规则，则需要经常检索到最后的包组件，这样不能进行高速的元数据的检索和抽出。

并且，SEI是以图片为单位与256字节的上限大小一起被写入的数据，因此，要求此元数据处理中要有即时性(高速性)。

并且，由于不必以各个图片为单位来记录所有的包组件，因此可以考虑到，即使检索到最后的包组件也不会找到存储了所希望的元数据的包组件。

因此，有关HDM_meta()内的HDM_pack()的记录顺序重要的是，要规定为HDM_pack()的HDM_pack_ID的由小到大的顺序。

据此，可以判断为了检索所希望的包组件是否要在HDM_meta()内进一步检索。并且，在超过所希望的包组件的ID值的情况下，则可以知道不存在所希望的包组件，从而可以尽早结束检索处理。

图61是上述处理的流程图。

在开始HDM元数据的获得时(S901)，获得HDM包组件数(S902)。获得HDM元数据，若是数据的最后(S903的是)，就结束有关获得HDM元数据的处理(S904)。

并且，若不是数据的最后(S903的否)，则判断是否要获得全部想要获得的信息。在全部获得的情况下(S905的是)，就结束有关获得HDM元数据的处理(S904)。并且，在没有全部获得的情况下(S905的否)，即使继续进行解析，也要判断是否能够获得想要获得的信息。

在不能获得的情况下(S906的是)，就结束有关获得HDM元数据的处理(S904)。并且，在能够获得的情况下(S906的否)，获得一个HDM_pack()，并返回到判断上述数据是否为最后的步骤(S903)。

如图61所示，HDM_meta()内的包组件由于是按照ID的顺序别描述的，因此可以以最低处理负荷对所希望的包组件进行检索和抽出。

图62对在DV定义的CAMERA列的包组件中存储的信息和在EXIF定义的EXIF列的包组件中存储的信息的同一性进行了比较。

从图62所示可以知道，在EXIF列的包组件中所存储的信息也可以在CAMERA列的包组件中被描述。即成为了被双重定义的状态。

这是因为HDM_meta()利用了DV和Exif的主要元数据的缘故，也表示焦距等光学参数等一部分出现重复。

例如，EXIF列的FOCAL LENGTH(焦距)可以分别在，CAMERA列的CONSUMERCAMERA1和CONSUMER CAMERA2来描述。

在较便宜的装置中，可以考虑这样一种情况，即不需要面向静止图像的高品味的EXIF列的信息，而以DV所使用的CAMERA列程度的精度信息就完全可以。

并且，由于持有双重像这种相同种类的信息，所以就会出现解析HDM_meta()的处理变的复杂的问题。

因此，在记录EXIF列的包组件的情况下，若该包组件存储的信息也可以在CAMERA列中被描述的话，记录该CAMERA列的包组件也是重要的。

若加上以刚才的ID顺序来记录的规则来考虑的话，廉价的装置以ID顺序来检索，解析自己所需要的信息的精度，即仅解析CAMERA列的包组件，以后即使有EXIF列的包组件，在仅获得CAMERA列的信息的时刻，停止解析处理，并可以将这个信息提供给用户。

并且，在能够与EXIF列对应的装置，即使是在CAMERA列获得所希望的数据，也能够容易地解析EXIF列，并获得更高精度的附属信息。

图63是使DV和EXIF持有相同种类的信息的情况下，记录规则的例子的说明图。在这个例子中，由于记录了EXIF列的EXPOSURE TIME、F NUMBER、EXPOSURE BIAS、MAX APERTURE、FLASH、以及FOCAL LENGTH的包组件，因此对应的CAMERA列的包组件也被记录。

并且，由于记录了F NUMBER和FOCAL LENGTH，并且CONSUMER CAMERA1被记录，同样EXPOSURE TIME也被记录，因此SHUTTER被记录。

这样，在记录精度不同的相同种类的信息的情况下，最重要的是必需以精度低的一方的信息先被记录的记录顺序来记录。

并且，对应的包组件的相关关系也变得复杂，为了追加EXIF列的数据而要追加EXIF列前边的CAMERA列的数据，为此，会造成存储器上的插入处理变的繁琐。

在这种情况下，在EXIF列中记录规定的包组件的情况下，设定这样一种规则是有效果的，即必需仅记录CAMERA列的CONSUMER CAMERA1。

根据图62，规定的包组件是指：F NUMBER、EXPOSURE PROG.、FOCALLENGTH、以及WHITE BALANCE。

当然，更简单地说，在EXIF列记录什么的情况下，也可以是必需记录CAMERA列的规定的包组件。

并且，也可以考虑到对于是使用CAMERA列还是使用EXIF列可以在该流的管理信息(YYY.VOBI)等中来表示。

DV是作为面向动态图像的元数据而被设定的，EXIF是作为面向静态图像的元数据而被设定的，因此可以将该VOB是动态图像还是静态图像的信息记录到VOBI，并按照这个值，这样，在动态图像的情况下使用CAMERA列，在静态图像的情况下使用EXIF列。

本实施例的信息记录装置以及记录方法可以在光盘等中记录元数据的信息重复的情况下，或元数据的种类繁多的情况下等，可以使元数据的检索处理简单化，并可以大幅度地减少再生(检索)处理时间。

为此，对于在硬盘或半导体存储器等记录介质上记录的情况也同样有用。

(实施例8)

近些年，想将以数字静态相机等拍摄的静态图像与动态图像一起管理这种用户要求越来越多。

然而数字静态相机的静态图像的像素一般是非常高的，即(1920x1080以上)的JPEG，这对于前提条件为对HDTV数据的民用AV装置而言，存在的课题是很难兼顾编解码和容量大小这两个方面。

并且，在次世代DVD标准(BD-ROM标准)中，可以处理作为幻灯片模式的静态图像，基本上是以包介质为对象的标准。为此，如调换幻灯片模式的静态图像的再生顺序，或删除其中的一张等编辑作业实际上是困难的。

因此，在实施例8中将对一种记录方法进行说明，即在将数字静态相机的静态图像读入到BD-ROM标准的幻灯片模式中时，可以以容易编辑的形式读入。

具体而言，对一种信息记录装置和记录方法进行说明，所述信息记录装置生成包含一个静态图像影像的系统流即静态图像单元，并与管理所述静态图像单元的再生的再生管理信息一起记录到信息记录介质，且静态图像单元为记录的信息记录介质的记录单位(扇区)的整数倍的数据大小。

在本实施例中，通过所述信息记录装置以及记录方法，可以利用静态图像幻灯片模式对动态图像和静态图像以同列来管理，并且可以以事件单位(例如在小孩的运动会上拍摄的动态图像和静态图像)等来管理内容。

并且，这时通过对静态图像幻灯片模式施加编辑耐性，从而可以使静态图像幻灯片模式的再生顺序的调换或删除这样的编辑作业变的容易且可以快速进行。

实施例8正如以上所述，是关于BD-ROM的静态图像幻灯片模式中的流结构的内容。基本上是基于实施例1的内容，以下以扩展和不同的部分为中心进行说明。

图64示出了BD流的结构。在BD处理的流是这样构成的，即：与记录的介质的扇区大小等无关，是以附加了ATS(Arrival Time Stamp，4字节)的、被称为Timed TS Packet的192字节的重复来构成的，所述ATS用于复原针对TS数据包和该TS数据包的解码器的输入时刻。

BD采用TS数据包(MPEG-2 Transport Stream)的理由是因为数字播放是利用MPEG2-TS来进行的，所以为了确保亲合性才这样做的。

由于192字节的Timed TS Packet不符合DVD或BD的2KB的扇区大小，因此将会集了32个的Timed TS Packet的单位(也称为Aligned Unit，6KB)作为最小记录单位。

因此，假设有编辑的情况下，以这个Aligned Unit(6KB)为单位进行追加或删除，在BD处理的流本身也以整数个的Aligned Unit来构成。

图65示出了一种格式，这种格式是将以数字静态相机等拍摄的静态图像作为以BD-ROM规定的幻灯片模式来读入时的格式。

如图所示，“XXX.PROG”是再生“XXX.PL”的程序(再生管理信息)，“XXX.PL”是由一个Cell组成的播放列表。

Cell#1是指“YYY.VOB”流的全体，此“YYY.VOB”包含三个Still Unit(包含一个静态图像影像的MPEG2-TS的区间)。并且，再生开始时刻(In#1)和再生结束时刻(Out#1)是指定这三个Still Unit的再生期间的信息。

各Still Unit内被附加了I-picture的PTS的值分别为PTS#1、PTS#2、以及PTS#3，用户的跳过指令等没有相互制约的情况下，根据此PTS定时被自动切换、再生。

因此，在用户什么操作也不做的情况下，PTS#2-PTS#1的时间成为StillUnit#1的静态图像的表示时间。

在用户进行了跳跃到下一个静态图像等操作的情况下，可以以这个操作的定时来开始下一个Still Unit。

这样，在利用BD-ROM的幻灯片模式，用户读入数字静态相机的静态图像时，由于有Cell内的STC时间轴(MPEG流的内部基准时间)不连续经过就不行等限制，因此，例如在进行仅删除Still Unit#2等编辑的情况下，在从流中进行部分删除时，需要修正被嵌入在PTS#3等流中的时刻信息等。

并且，由于till Unit#2没有被扇区校直，即数据长没有成为6KB的整数倍，因此抽出流中一部分进行编辑时，不能以扇区为单位进行删除处理从而变得复杂。

这是因为Still Unit#2的最初和最后的Timed TS Packet，和两端的Still Unit(Stiil Unit#1和#3)的Timed TS Packet被记录到相同的扇区的缘故。

这样，在幻灯片模式的编辑中就会搀杂扇区校直和时刻信息的变更这两个处理。以下，对解决这个课题的方法进行说明。

图66所示的“XXX.PROG”与图65所示的相同，并使构成“XXX.PL”的Cell与Still Unit一一相对。这样做的好处是，即使删除特定的StillUnit，也不需要修正流内部的时间戳(如图所示，各Cell分别被分配到独自的STC时间轴上。)。

并且，如图67的详细所示，为了使一个Still Unit的数据大小成为Aligned Unit(6kB)的整数倍，而可以追加虚拟的Timed TS Packet(也可以是NULL数据包)。

通过这样做，可以容易地对应以一张静态图像为单位(一个Still Unit单位)的删除或顺序的调换。

例如在利用MPEG2-Video的情况下，一个Still Unit包括主影像流和副影像流，所述主影像流表示由序列头、GOP头、I图片、序列结束符构成的一张静态图像，所述副影像流是在程序构成时所必需的PSI/SI数据包(PAT、PMT、以及SIT等)、传送生成基准时刻STC的时刻信息的PCR数据包、以及静态图像(主影像流)上重叠并表示的流。

由于加上了以前所述的限制，所以例如删除图66的Still Unit#2、或变更Still Unit#2和Still Unit#3的顺序的处理，就可以以单纯的播放列表的Cell信息的修正和流(Still Unit)的部分删除/部分调换来结束。

即，解析修正之处以后的流，变更PTS的值等处理是不需要的。

在图68中示出了，作为副影像信息，将数字静态相机等经常使用的Exif信息作为字幕流来读入的例子。

Exif信息是存储快门速度和ISO感度、拍摄日期时间等有关静态图像的附加信息的信息，是存储有关静态图像的各种信息的信息。

附带在这种静态图像上的信息没有必要经常表示出来，因此，可以将图68(C)所示的副影像信息作为BD-ROM中的字幕流这样的结构(用户可以有意识地进行表示/非表示的选择的结构)来进行多路复用。

此时，不仅是图68(B)所示的静态图像的静态图像幻灯片模式，若用户希望则可以以表示其附带的信息的、图68(A)所示的形式来欣赏静态图像幻灯片。

图69是根据数字静态相机的静态图像和Exif信息，来作成用于区别图68(A)～图68(C)所示的主影像和副影像的幻灯片模式的流程图。

在开始静态图像的读入时(S1001)，首先，读入变换的静态图像(S1002)。根据静态图像抽出Exif信息(S1003)，并作为副影像来编码(S1004)，所述副影像是将Exif信息的一部分重叠于主影像上的影像。

首先，将静态图像重设大小为1920×1080的像素数(S1005)。重设大小后，作为由一张I-picture构成的主影像(MPEG2-Video等)来编码(S1006)。

根据以上所述，主影像和副影像被生成，并生成将主影像和副影像合起来的Still Unit(S1007)。

Still Unit被进行扇区校准的情况下(S1008的是)，结束有关静态图像读入的处理(S1010)。

并且，在Still Unit没被进行扇区校准的情况下(S1008的否)，则追加虚拟数据包(NULL数据包)，并进行扇区校准(S1009)。之后，结束有关静态图像的读入处理(S1010)。

一般而言，由于数字静态相机的像素数超过完全(Full)HD的1920×1080的比较多，重设为HD大小后并作为I-picture来编码。并且，抽出规定的Exif信息，作为字幕流(PG流：Presentation Graphics流)来编码。

编码后进行多路复用，为了能够以Still Unit为单位进行扇区校准，而插入虚拟数据包并结束多路复用。

本实施例所涉及的光盘以及该光盘的记录/再生装置、记录再生方法，通过将光盘中记录的静态图像幻灯片模式的一个逻辑单位与记录介质的记录单位(扇区)相结合，从而可以使静态图像的幻灯片模式的编辑变得非常容易。

并且，不仅限于光盘，对于在硬盘或半导体存储器等记录介质上进行记录的情况也有用，并且也可以适用于在各种记录介质上记录的AV记录器或被记录的记录介质，以及再生这些记录介质的AV播放器。

根据本发明，可以提供一种信息记录介质，其可以在追记影像内容等时，容易地识别并删除与已经存在的盘菜单相关的文件。此信息记录介质不仅是盘介质也可以作为半导体存储器等其它的记录介质来实现。因此，尤其有用于影像内容的制作所涉及到的电影产业、民用装置产业中所使用的信息记录介质。

Claims (2)

1.一种信息记录方法，在编码影像信息之时，同时编码影像信息的附属信息，将信息记录到信息记录介质中，其特征在于，

上述附属信息被附加于影像信息的各个图片中，

在上述附属信息包含相同种类且精度不同的多个信息的情况下，

将精度低的信息以比精度高的信息先被记录的记录顺序，记录到上述信息记录介质中。

2.一种信息记录装置，在编码影像信息之时，同时编码影像信息的附属信息，将信息记录到信息记录介质中，其特征在于，

上述附属信息被附加于影像信息的各个图片中，

上述信息记录装置具有记录单元，在上述附属信息包含相同种类且精度不同的多个信息的情况下，该记录单元将精度低的信息以比精度高的信息先被记录的记录顺序，记录到上述信息记录介质中。

Images