转存同一张光盘时CD-ROM子通道不同？

Question

我正在我的带有三星 SH-S223L 驱动器的 Windows 10 x64 计算机上使用 CloneCD 5.3.3.0 制作旧视频游戏的备份副本。

其中之一是 PC 版的地狱火（暗黑破坏神 1 资料片）：

• 光盘有一个COMPACT disc DATA STORAGE标志
• 序列号： S0011770
• 工厂 SID 代码： IFPI 1218
• CD-Master SID-代码： IFPI L032
• ISO 9660 PVD ​​创建日期： 1997-11-18 16:30:00.00

我使用redump.org CloneCD 配置文件推荐：

[CloneCD ReadPrefs]
ReadSubData=1
RegenerateData=0
ReadSubAudio=1
AbortOnReadError=0
FastErrorSkip=0
ReadSpeedData=8
ReadSpeedAudio=8
IntelligentBadSectorScan=1
SectorSkip=1
NoErrorReport=0
FirstSessionOnly=0
AudioQuality=3

据我所知，游戏没有保护，但是当我转储光盘两次时，我最终得到了不同的子频道文件 ( .sub)。在.ccd和.img文件是相同的，只有.sub不同，我用SHA1校验和十六进制编辑器来验证这一点。
我在这里上传了两个.sub文件转储。 我不得不提一下，我拥有这张光盘的两份副本，并且两张光盘的行为都相同。

我还转储了其他几个 CD-ROM 媒体，有时我会得到这种行为，有时子频道在转储中是一致的。

这种行为的解释是什么？

---

编辑：

我用 Lite-On iH124-14 驱动器再次转储了同一张 CD-ROM，我看到了相同的行为（不同的.sub文件）。
我还使用 KProbe 2 检查了介质中的错误，并得到以下结果：

---

编辑：

似乎磁盘状况和/或驱动器精度不足加上子通道没有错误控制机制（Q 通道除外）这一事实解释了为什么我.sub在多次转储同一介质时得到不同的文件。

我不得不提一下，我还有一个 Plextor PX-712A 驱动器，并.sub通过使用Disc Image Creator设法在转储中获得一致的文件。该软件利用0xD8指令而不是0xBE指令来读取光盘，从而产生更准确的图像。只有少数驱动器（主要是 Plextor）支持此指令。

此外，我实际上拥有我要倾销的这张 CD-ROM 的两个物理副本（相同的序列号、相同的 IFPI 代码和相同的激光雕刻信息）。如果我使用 Disc Image Creator 多次转储同一张光盘，我会得到一致的.sub文件，但如果我转储第一张光盘，然后转储第二张光盘，则不会。
我想这与媒体条件有关，因为其中一个有一些划痕和更多的 C1/C2 错误。

Answer 1

各种CD格式都有点涉及，官方规范（音频CD的“红皮书”，数据CD的“黄皮书”）不是免费的。但是您可以在 Ecma-130 等可用标准中找到一些详细信息。

原始音频 CD（也称为 CD-DA）以黑胶唱片为模型，这意味着它也使用连续音频数据的螺旋轨道（DVD 后来使用圆形轨道）。以非常复杂的方式在此音频数据中交错的是 8 个子通道（P 到 W），其中 Q 子通道包含计时信息（字面意思是分/秒/秒的分数）和当前轨道编号。对于最初的目的，这已经足够了：为了连续播放，只需稍微调整镜头以跟随轨道。为了寻找，镜头会在解码 Q 子通道的同时移动，直到找到正确的轨道。这个定位有点粗糙，但听音乐完全够用。

直到今天，许多计算机 CD 驱动器仍不能完全准确地定位镜头和同步解码电路，以便从准确位置开始读取音频样本。这就是为什么许多 CD 翻录程序具有“偏执”模式的原因，在这种模式下，它们会重叠读取并比较结果以针对这种“抖动”进行调整。作为音频流的一部分，子通道也会受到抖动的影响，这就是为什么在无法准确定位的 CD 驱动器上翻录时会得到不同子通道文件的原因。

当数据 CD（CD-ROM）规范被开发以扩展 CD-DA 规范时，人们认识到准确寻址和读取数据的重要性，因此将 2352 字节的音频帧细分为 12 个同步字节和 4 个标头字节（用于扇区地址），剩下的 2336 字节用于数据和额外的纠错级别。使用这种方案，扇区可以准确寻址，而不必仅依赖 Q 信道信息。因此抖动效应不适用，当您转储 CD-ROM 时您总是得到相同的数据，并且不需要额外的转储技巧。

编辑更多细节：

根据Ecma-130，数据是分阶段加扰的：24 个字节组成一个F1-Frame，这些帧中的 106 个字节被分配到 106 个F2-Frames 中，得到 8 个额外字节的纠错。这些帧依次获得一个额外的字节（“控制字节”），使它们成为F3-Frames。额外字节包含子通道信息（每个位位置一个子通道）。一组 98 个 F3-Frames 称为段，98 个相关的控制字节包含两个同步字节和 96 个字节的真实子通道数据。Q子信道另外在这96位中有16位CRC纠错。

这背后的想法是以划痕、污垢等不会影响大量连续位的方式将数据分布在磁盘表面上，因此只要没有划痕，纠错就可以恢复丢失的数据太大。

因此，在重新定位镜头后，CD 驱动器硬件需要读取一个完整的部分，以找出它在数据流中的位置。各个阶段的解扰由硬件完成，硬件需要将自身同步到控制字节流中的 2 个同步字节。与其他型号相比，所有 CD 驱动器型号需要不同的同步时间（您可以通过从两个不同的驱动器读取数据进行测试，如果有的话），这取决于硬件的实现方式。此外，许多模型并不总是需要完全相同的时间来同步，因此它们可以早一点或晚一点开始，并且输出解扰数据并不总是在相同的字节上。

因此，当翻录程序发出READ CD(0xBE) 命令时，它会提供传输长度和起始地址（或者更确切地说，Q 通道时间）。驱动器定位镜头、解扰帧、提取 Q 通道、比较时间，当它找到正确的时间时，它开始传输。如上所述，此传输并不总是从同一字节开始，因此多个READ CD命令的结果可能会相互移位。这就是为什么您会从开膛手看到不同的子频道文件。

根据硬件和镜头调整时的情况，如果传输早几个样本或晚几个样本，它或多或少是随机的。因此，您将在结果中看到的唯一模式是偏移是传输长度的倍数。

某些驱动器型号实际上具有准确的硬件，它们将始终同时开始传输。该标准在模式页面 0x2a（“CD/DVD 功能和机械状态页面”）中定义了一个位，指示是否是这种情况，但实际经验表明，一些声称准确的驱动器实际上并非如此。（Linux下可以sg_modes从sg3-utiles包中读取模式页，Windows下不知道用什么工具）。

Answer 2

根据这篇维基百科文章

一帧包含33个字节，其中24个字节为音频或用户数据，8个字节为纠错（CIRC生成），1个字节为子码。

这表明子信道没有纠错。

我还在别处发现了另一个问题。这是关于音频 CD，但我认为它解决了正确的问题：

我只能说，从同一个 CD-DA/CD-TEXT 读取时，我从未设法获得两个相同的子通道读数（*.SUB 文件）。在 RAW 模式下读取时是否正常，因为 CD-DA/CD-TEXT 格式在所有子通道中都没有携带 EDC/ECC，因此数据没有得到纠正？

那里的答案：

只有音频数据经过 Reed-Solomon 编码（C1 和 C2）。子码通道数据（通道 P...W）不受交织或错误保护。

虽然dirkt在您可能不需要文件的问题的另一个答案中可能是正确的.sub，但答案并未明确解决您的问题：

这种行为的解释是什么？

我的回答是：您会得到不同的.sub文件，因为子频道没有纠错功能。在读取音频或用户数据时纠正（或至少检测到）读取错误，但读取错误在子通道位发生时可以按原样通过。由于划痕或灰尘导致的特定错误可能会在一次阅读期间出现，而在另一次阅读期间不会出现，因此.sub文件会有所不同。

答案扩展以解决评论：

我有该磁盘的两份副本，其中一份状况良好（无明显划痕），行为仍然相同。我还有其他状况最差的旧游戏 CD-ROM，它们.sub在多个转储中具有一致的文件。

我怀疑（不幸的是没有确凿的证据）不同的 CD 可能以不同的质量制造。在子通道无关紧要的情况下，较低质量的磁盘仍可能通过旨在仅检测数据不一致的质量测试。或者它可能只是概率问题：一个磁盘有它的弱点（有点导致读数不一致），纠错可以修复它；另一个恰好在子通道区域。

一个这样的子信道位足以为您提供不同的校验和，而即使用户数据区域中的数千个“未确定”位也可以在需要时静默纠正，只要它们分布得足够多，因此纠错算法处理不太-一次。

答案扩展为对 KProbe 2 结果的反应。

据我所知，C1 错误是允许的（在一定数量上），因为它们会被悄悄地纠正（更多在这里）。由于纠错位的存在，这种纠正有效。正如我之前所说，子通道一般没有这样的冗余（dirkt提到了 Q 子通道 CRC 纠错，但在我的结论中并没有太大变化）。此外，如果错误发生在那里，则无法知道它，除非您事先知道正确的子通道数据是什么。

因此，您总共知道了 1855 个错误。重复测试（认真地做！），您可能会遇到例如 1790 错误；或 1892。然而，每次阅读时校正后的输出都是相同的。

如果每 32 个数据位有一个子通道位，那么我说您可能有大约 1855/32 个子通道位在未检测到错误的情况下被读取。那大约是 58 位。嗯，差不多，因为多亏了 Q 子信道 CRC，至少可以检测到其中一些错误。由于 Q 是八个子通道之一，我估计您在其他子通道中剩下大约 50 个错误位。下次您阅读时，您可能会得到一些没有错误的位，并且在其他地方很少有新的子通道错误。所以你会得到不同的.sub文件。而且您仍然无法确定第一次或第二次正确读取了哪些位。