转储同一张光盘时，CD-ROM子通道是否不同？

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

其中之一是PC的Hellfire（Diablo 1扩展）：

• 光盘上有COMPACT disc DATA STORAGE徽标
• 序列号： S0011770
• 工厂SID代码： IFPI 1218
• CD主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错误。

涉及各种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-Frame中，这会额外获得8个纠错字节。这些帧依次获得一个额外的字节（“控制字节”），以使其成为F3帧。额外的字节包含子通道信息（每个位位置一个子通道）。一组98个F3-Frame称为section，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下使用哪种工具）。

根据这篇维基百科文章

一帧包括33个字节，其中24个字节是音频或用户数据，八个字节是纠错（CIRC生成），一个字节用于子代码。

这表明没有针对子信道的纠错。

我在其他地方也发现了另一个问题。它与音频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，这些CD-ROM在.sub多个转储中的文件均一致。

我怀疑（不幸的是，尽管没有确凿的证据）不同的CD可能以不同的质量生产。在子通道无关紧要的情况下，较低质量的磁盘可能仍会通过旨在仅检测数据不一致的质量测试。或者，它可能仅仅是概率问题：一个磁盘有其薄弱点（有些地方读数不一致），可以通过纠错来修复它。另一个恰好在子通道区域中具有它。

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

对KProbe 2结果的反应扩大了答案。

据我所知，C1错误是允许的（一定程度），因为它们已被静默纠正（更多信息在此）。由于有纠错位，因此此纠正有效。正如我之前说过的，子通道通常没有这样的冗余（dirkt提到了Q子通道CRC纠错，但是我的结论并没有太大改变）。此外，如果在那里发生错误，则没有办法知道它，除非您事先知道正确的子通道数据是什么。

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

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