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

信息记录装置以及信息记录方法
     本申请为申请号 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 DiscFormat ： 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 SetInformation(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 等盘中的各种摄像机记录器 ( 以下简称为 “摄像机” ) 已由众多制造厂商生 产并被广泛普及。
     并且， 这些摄像机具有可以生成独自的菜单画面并写入到盘中的功能。此菜单画 面以下称为 “盘菜单” 。
     用户利用摄像机将影像记录到信息记录介质， 在使用播放器再生此信息记录介质 的情况下， 可以看到此摄像机所生成的盘菜单。 并且， 可以从所述菜单中选择作为再生等对 象的标题。
     然而， 在各个制造厂商所生产的各种摄像机中， 盘菜单所涉及的各种文件的描述内容和结构等是不统一的。
     即， 将某制造厂商的摄像机所生成的盘菜单在其它制造厂商的摄像机中解释实质 上是不可能的。
     为此， 例如， 记录有某制造厂商的摄像机所拍摄的影像的盘被装入到其它厂商的 摄像机， 并被执行新的标题的追加等情况下， 在该其它厂商的摄像机中则需要删除有关记 录完毕的盘菜单的文件， 并需要制作新的盘菜单。
     在这样的情况下， 在装入了盘的摄像机中则需要通过解析控制记录完毕的盘菜单 的再生的程序等， 来找出与所述盘菜单相关的各种文件， 这是一个非常高度的解析工作。
     为此， 存在的问题是 ： 从盘被装入后直到可以开始影像的记录等工作为止要花费 较长的时间， 而且实质上是不能找出所述的各种文件。
     并且， 在记录新的盘菜单之时， 在不删除与已经存在的而又不需要的盘菜单相关 的文件的情况下， 不要的文件则被存储到盘中。这样， 盘的可记录容量不但会减少， 而且在 使用此盘的记录装置以及再生装置中， 有关文件管理的处理负担也会增加。 发明内容 因此， 本发明鉴于上述以往的问题， 目的在于提供一种信息记录介质、 记录装置以 及记录方法， 在某记录装置上生成的菜单被记录到信息记录介质后， 且此信息记录介质被 装入到其它的记录装置的情况下， 可以不产生在所述其它的记录装置中本来不需要的处理 负担以及处理时间。
     为了达成上述目的， 本发明为一种信息记录方法， 在编码影像信息之时， 同时编码 影像信息的附属信息， 将信息记录到信息记录介质中， 其特征在于， 上述附属信息被附加于 影像信息的各个图片中， 一个上述附属信息包括识别信息 (ID) 和实际信息 ( 数据 )， 将上述 附属信息以识别信息 (ID) 的顺序记录到上述信息记录介质中。
     另外， 本发明为一种信息记录装置， 在编码影像信息之时， 同时编码影像信息的附 属信息， 将信息记录到信息记录介质中， 其特征在于， 上述附属信息被附加于影像信息的各 个图片中， 一个上述附属信息包括识别信息 (ID) 和实际信息 ( 数据 )， 上述信息记录装置具 有记录单元， 该记录单元将上述附属信息以识别信息 (ID) 的顺序记录到上述信息记录介 质中。
     并且， 本发明的信息记录介质记录以数字流的部分区间构成的作为音视频内容的 标题， 所述数字流的部分区间是指数字流的一部分或全部， 在该信息记录介质中记录有 ： 播 放列表， 具有信息， 该信息通过指定数字流中的部分区间的位置和再生顺序， 从而确定所述 标题 ； 程序， 通过调用所述播放列表来控制所述标题的再生 ； 索引信息， 包含被对应起来的 标题识别信息和程序识别信息， 所述标题识别信息识别所述标题， 所述程序识别信息识别 所述程序 ； 以及扩展信息， 包含被对应起来的所述标题识别信息和播放列表识别信息， 所述 播放列表识别信息识别所述播放列表。
     据此， 使用本发明的信息记录介质的记录装置在删除菜单 ( 所述菜单是记录在信 息记录介质中的标题之一 ) 时， 不是解析控制所述菜单的再生的程序， 而是可以容易地确 定所述菜单所关联的播放列表。
     因此， 例如在作为记录装置的电视摄影机中， 在删除由其它的电视摄影机生成的、
     被记录在盘中的盘菜单时， 可以确定并删除盘菜单所关联的播放列表。
     并且， 在所述删除中所涉及的工作中， 不需要进行程序的解析等， 就可以容易地确 定应该删除的播放列表。 即， 在使用本发明的信息记录介质的记录装置中， 可以不发生本来 就不需要的处理负荷以及处理时间。
     并且， 本发明的记录装置， 将数字流记录到所述信息记录介质中， 在所述信息记录 介质中记录有多个标题 ； 所述多个标题中的一个是用户选择除该标题自身以外的标题时所 使用的菜单 ； 所述记录装置包括 ： 播放列表确定单元， 利用所述扩展信息中所包含的、 所述 菜单的标题识别信息所对应的所述播放列表识别信息， 来确定由控制所述菜单的再生的程 序调用的播放列表 ； 菜单生成单元， 生成新的菜单并记录到所述信息记录介质， 从而代替所 述菜单 ； 以及删除单元， 在所述菜单生成单元生成了所述新的菜单的情况下， 删除所述播放 列表确定单元确定的播放列表。
     据此， 本发明的记录装置可以容易地确定与标题相关联的播放列表， 并可以删除 该播放列表。
     因此， 例如， 作为电视摄影机而实现了本发明的记录装置的情况下， 可以容易地从 由其它制造厂商的电视摄影机记录了盘菜单的 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 中用于制作利用了子图像的静止图像幻灯片模式的处理流程图。
     符号说明9101996664 A CN 101996669
     说BD-ROM 播放器 音频专用播放器 BD-ROM 盘 光学拾波器 程序记录存储器 管理信息记录存储器 AV 记录存储器 程序处理部 管理信息处理部 表示处理部 成像面 (image plane) 视频面 合成处理部 程序处理器明书8/56 页1 2 104 105 202 203 204 205 206 207 208 209 210 211 302 303 305 306 307 308 309 310 311 312 313 317 400 401 402 403 404 405 406 407 408 409 S801 S802 S803UO 管理器 方案处理器 表示控制器 时钟 图像存储器 轨道缓存 多路分配器 图像处理器 视频处理器 声音处理器 驱动控制器 记录器 播放列表指定部 删除部 菜单发生部 制造厂商判断部 接受部 编辑部 号码读出部 拍摄部 表示部 记录 / 编辑开始步骤 BD.INFO 和 BD.PROG 读取步骤 标题号码获得步骤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 WebConsortium(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) ：
     AC3MPEG1
     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 中事件处理程序开始的定义 ( 标签 ) 和上述的事件的 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) 被执行， 该按钮程序 (ButtonProgram3) 是在 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) 中重要的是不含有对菜单工作有影响的 ButtonProgram。
     若按照这样的规则， 即使在不同的制造厂商之间使盘移动的情况下， 也可以在维 持盘全体的数据相容性的同时更新盘菜单。
     然而， 若根据该规则， 就需要确定 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 由用户的编辑 操作被删除的影像或声音信息。 并且， 关于 Titlel 和 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()、 以及所述 TitleDomainMenu 解 析 作 为 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， 以后在本实施例中称为 VirtualPlayList。
     在此， 对于作为拍摄或录制的影像的单位的 Shot 和 Real PlayList 及 Virtual PlayList 的对应关系， 以图 50 来示出。
     如图 50 所示， Real PlayList 将拍摄的 Shot 所存储的流按拍摄顺序再生， 一般来 说流在被记录之时与流信息一起被生成。
     并且， Real PlayList 例如在 Shot 的拍摄后被追加或被修正。
     另外， Virtual PlayList 用于以所希望的顺序再生用户进行影像编辑的结果， 即 记录的影像的一部分， 是在用户进行编辑处理时被作成的。
     这样， 拍摄或录制的流有可能被多个 PlayList 所参考。为此， 在删除 PlayList 之 时， 同 时 该 PlayList 所 参 考 的 流 也 被 删 除， 这样就有可能出现参考不存在的流的 PlayList。
     因此， 由于某个流必定要被一个 Real PlayList 所参考， 所以， 可以在删除 Virtual PlayList 时不删除参考的流及流信息， 在删除 RealPlayList 时删除参考的流及流信息， 并 修正参照该流的 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 和 VirtualPlayList 的播放列表文件号码 进行定义。 这样， 在进行 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 中所存储的流按照拍摄顺序 再生， 基本上在流被记录之时与流信息一起被生成。例如 RealPlayList 在 Shot 的拍摄后 被追加或被修正。
     另外， Virtual PlayList 作为用户所进行的影像编辑的结果， 以所希望的顺序来 再生记录的影像的一部分， Virtual PlayList 在用户的编辑处理时被作成。
     这 样， 拍 摄 或 录 制 的 流 就 有 可 能 由 多 个 PlayList 来 参 考。 为 此， 在删除某 PlayList 之时， 当该 PlayList 所参考的流也同时被删除时， 就有可能出现参考不存在的流 的 PlayList。
     因 此， 由 于 必 需 要 由 一 个 Real PlayList 来 参 考， 所 以 可 以 在 删 除 Virtual PlayList 之时参考的流及流信息不被删除， 而在删除 RealPlayList 之时参考的流及流信 息被删除， 并可以修正参考该流的 VirtualPlayList。
     以上对 Real PlayList 和 Virtual PlayList 进行了说明， 可以将这些识别信息存 储到所述 “PL_Type” 。 并且作为其它的类别， 还可以设定表示以该播放列表再生的流为菜单 用的流的类别， 或表示为幻灯片模式的类别。
     并 且， 可 以 将 参 考 图 34 所 说 明 的 程 序 被 多 路 复 用 的 流 (InteractiveGraphics(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 的 元数据的记录顺序也是按照拍摄顺序排列的。
     并且， 除删除以外， 该顺序是不会因编辑等被调换的。这样， 根据 RealPlayList 的 元数据的存储顺序和该 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(SequenceParameter 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 的内容， 以下以扩展和不同的部分为中心进行说明。

    [1000] 图 64 示出了 BD 流的结构。在 BD 处理的流是这样构成的， 即： 与记录的介质的扇 区大小等无关， 是以附加了 ATS(Arrival Time Stamp， 4 字节 ) 的、 被称为 Timed TS Packet 的 192 字节的重复来构成的， 所述 ATS 用于复原针对 TS 数据包和该 TS 数据包的解码器的 输入时刻。

    [1001] BD 采用 TS 数据包 (MPEG-2 Transport Stream) 的理由是因为数字播放是利用 MPEG2-TS 来进行的， 所以为了确保亲合性才这样做的。由于 192 字节的 Timed TS Packet 不符合 DVD 或 BD 的 2KB 的扇区大小， 因此将会 集了 32 个的 Timed TS Packet 的单位 ( 也称为 Aligned Unit， 6KB) 作为最小记录单位。

    [1003] 因此， 假设有编辑的情况下， 以这个 Aligned Unit(6KB) 为单位进行追加或删除， 在 BD 处理的流本身也以整数个的 Aligned Unit 来构成。

    [1004] 图 65 示出了一种格式， 这种格式是将以数字静态相机等拍摄的静态图像作为以 BD-ROM 规定的幻灯片模式来读入时的格式。

    [1005] 如图所示， “XXX.PROG” 是再生 “XXX.PL” 的程序 ( 再生管理信息 )， “XXX.PL” 是由 一个 Cell 组成的播放列表。

    [1006] Cell#1 是指 “YYY.VOB” 流的全体， 此 “YYY.VOB” 包含三个 Still Unit( 包含一个 静态图像影像的 MPEG2-TS 的区间 )。并且， 再生开始时刻 (In#1) 和再生结束时刻 (Out#1) 是指定这三个 Still Unit 的再生期间的信息。

    [1007] 各 Still Unit 内 被 附 加 了 I-picture 的 PTS 的 值 分 别 为 PTS#1、 PTS#2、 以及 PTS#3， 用户的跳过指令等没有相互制约的情况下， 根据此 PTS 定时被自动切换、 再生。

    [1008] 因此， 在用户什么操作也不做的情况下， PTS#2-PTS#1 的时间成为 StillUnit#1 的 静态图像的表示时间。

    [1009] 在用户进行了跳跃到下一个静态图像等操作的情况下， 可以以这个操作的定时来 开始下一个 Still Unit。

    [1010] 这样， 在利用 BD-ROM 的幻灯片模式， 用户读入数字静态相机的静态图像时， 由于 有 Cell 内的 STC 时间轴 (MPEG 流的内部基准时间 ) 不连续经过就不行等限制， 因此， 例如 在进行仅删除 Still Unit#2 等编辑的情况下， 在从流中进行部分删除时， 需要修正被嵌入 在 PTS#3 等流中的时刻信息等。

    [1011] 并且， 由于 till Unit#2 没有被扇区校直， 即数据长没有成为 6KB 的整数倍， 因此 抽出流中一部分进行编辑时， 不能以扇区为单位进行删除处理从而变得复杂。

    [1012] 这 是 因 为 Still Unit#2 的 最 初 和 最 后 的 Timed TS Packet， 和 两 端 的 Still Unit(Stiil Unit#1 和 #3) 的 Timed TS Packet 被记录到相同的扇区的缘故。

    [1013] 这样， 在幻灯片模式的编辑中就会搀杂扇区校直和时刻信息的变更这两个处理。 以下， 对解决这个课题的方法进行说明。

    [1014] 图 66 所示的 “XXX.PROG” 与图 65 所示的相同， 并使构成 “XXX.PL” 的 Cell 与 Still Unit 一一相对。这样做的好处是， 即使删除特定的 StillUnit， 也不需要修正流内部的时间 戳 ( 如图所示， 各 Cell 分别被分配到独自的 STC 时间轴上。)。

    [1015] 并且， 如图 67 的详细所示， 为了使一个 Still Unit 的数据大小成为 Aligned Unit(6kB) 的整数倍， 而可以追加虚拟的 Timed TS Packet( 也可以是 NULL 数据包 )。

    [1016] 通过这样做， 可以容易地对应以一张静态图像为单位 ( 一个 Still Unit 单位 ) 的 删除或顺序的调换。

    [1017] 例如在利用 MPEG2-Video 的情况下， 一个 Still Unit 包括主影像流和副影像流， 所述主影像流表示由序列头、 GOP 头、 I 图片、 序列结束符构成的一张静态图像， 所述副影像 流是在程序构成时所必需的 PSI/SI 数据包 (PAT、 PMT、 以及 SIT 等 )、 传送生成基准时刻 STC 的时刻信息的 PCR 数据包、 以及静态图像 ( 主影像流 ) 上重叠并表示的流。

    [1018] 由于加上了以前所述的限制， 所以例如删除图 66 的 Still Unit#2、 或变更 StillUnit#2 和 Still Unit#3 的顺序的处理， 就可以以单纯的播放列表的 Cell 信息的修正和流 (Still Unit) 的部分删除 / 部分调换来结束。

    [1019] 即， 解析修正之处以后的流， 变更 PTS 的值等处理是不需要的。

    [1020] 在图 68 中示出了， 作为副影像信息， 将数字静态相机等经常使用的 Exif 信息作为 字幕流来读入的例子。

    [1021] Exif 信息是存储快门速度和 ISO 感度、 拍摄日期时间等有关静态图像的附加信息 的信息， 是存储有关静态图像的各种信息的信息。

    [1022] 附带在这种静态图像上的信息没有必要经常表示出来， 因此， 可以将图 68(C) 所 示的副影像信息作为 BD-ROM 中的字幕流这样的结构 ( 用户可以有意识地进行表示 / 非表 示的选择的结构 ) 来进行多路复用。

    [1023] 此时， 不仅是图 68(B) 所示的静态图像的静态图像幻灯片模式， 若用户希望则可 以以表示其附带的信息的、 图 68(A) 所示的形式来欣赏静态图像幻灯片。

    [1024] 图 69 是根据数字静态相机的静态图像和 Exif 信息， 来作成用于区别图 68(A) ～ 图 68(C) 所示的主影像和副影像的幻灯片模式的流程图。

    [1025] 在开始静态图像的读入时 (S1001)， 首先， 读入变换的静态图像 (S1002)。根据静 态图像抽出 Exif 信息 (S1003)， 并作为副影像来编码 (S1004)， 所述副影像是将 Exif 信息 的一部分重叠于主影像上的影像。

    [1026] 首先， 将静态图像重设大小为 1920×1080 的像素数 (S1005)。 重设大小后， 作为由 一张 I-picture 构成的主影像 (MPEG2-Video 等 ) 来编码 (S1006)。

    [1027] 根据以上所述， 主影像和副影像被生成， 并生成将主影像和副影像合起来的 Still Unit(S1007)。

    [1028] Still Unit 被进行扇区校准的情况下 (S1008 的是 )， 结束有关静态图像读入的处 理 (S1010)。

    [1029] 并且， 在 Still Unit 没被进行扇区校准的情况下 (S1008 的否 )， 则追加虚拟数据 包 (NULL 数据包 )， 并进行扇区校准 (S1009)。 之后， 结束有关静态图像的读入处理 (S1010)。

    [1030] 一般而言， 由于数字静态相机的像素数超过完全 (Full)HD 的 1920×1080 的比较 多， 重设为 HD 大小后并作为 I-picture 来编码。并且， 抽出规定的 Exif 信息， 作为字幕流 (PG 流 ： Presentation Graphics 流 ) 来编码。

    [1031] 编码后进行多路复用， 为了能够以 Still Unit 为单位进行扇区校准， 而插入虚拟 数据包并结束多路复用。

    [1032] 本实施例所涉及的光盘以及该光盘的记录 / 再生装置、 记录再生方法， 通过将光 盘中记录的静态图像幻灯片模式的一个逻辑单位与记录介质的记录单位 ( 扇区 ) 相结合， 从而可以使静态图像的幻灯片模式的编辑变得非常容易。

    [1033] 并且， 不仅限于光盘， 对于在硬盘或半导体存储器等记录介质上进行记录的情况 也有用， 并且也可以适用于在各种记录介质上记录的 AV 记录器或被记录的记录介质， 以及 再生这些记录介质的 AV 播放器。

    [1034] 根据本发明， 可以提供一种信息记录介质， 其可以在追记影像内容等时， 容易地识 别并删除与已经存在的盘菜单相关的文件。 此信息记录介质不仅是盘介质也可以作为半导 体存储器等其它的记录介质来实现。因此， 尤其有用于影像内容的制作所涉及到的电影产业、 民用装置产业中所使用的信息记录介质。