Lap*_*sio 5 audio linux storage dd compact-disc
我的朋友尝试使用nbd服务器通过网络导出 cdrom 设备，但我们注意到虽然它适用于数据 CD，但音频 CD 的行为并不像普通数据磁盘那样。我不是在谈论文件系统的存在或缺乏，而是谈论原始块级访问。
虽然我知道音频 CD 不能真正在文件级别进行解释，因此不能真正挂载，但我知道它们包含许多真正特定于音频的附加信息，我知道它们并没有CRC的方式与数据盘一样，所以整个数据读取过程是不同的，我还是不太明白为什么不能像普通块设备那样从/dev/sr0或读取它们/dev/cdrom。CDDA 有什么特别之处，以至于它们不能被普通软件在块级读取？
我的意思是，到底它只是流的字节-如果不是像块设备，然后像任何字符设备为什么dd/ cat/nbd不能像任何其他块/字符设备使用它们？是否有一些实际的技术原因，或者仅仅是因为没有人找到在 Linux 中实现对 CDDA 介质的这种访问的合理用例？
音频 CD（也称为CD-DA，在专有红皮书中指定）是最古老的 CD 格式。这种格式的灵感来自于音频记录，所以你有一个带有连续数据的螺旋轨道，与这些数据交错的是时间信息。没有合适的区块头。信息的最小单位是一帧或 1/75 秒，其中包含 2352 个数据字节（对于 2 个通道，2 个样本/字节，44.1 kHz）。
请注意，这不是 2 的幂，甚至不能除以 256 或 512。因此将音频帧视为数据块有点尴尬。最重要的是，早期的 CD 驱动器不能总是正确定位，所以如果你告诉它“在 12 分 4 秒和 5 1/75 秒时读取帧”，它有时会提前或推迟几个字节。这就是为什么有这么多程序可以“正确”读取音频 CD（例如cdparanoia）。
现在将其与数据 CD（也称为 CD-ROM，在黄皮书中指定）进行对比：他们获取音频帧的 2352 字节，并使用其中一些作为标头信息来识别块。他们还添加了另一个级别的纠错，因此音频帧的 2352 字节变为数据帧中的 2048 字节。
现在我们有一个 2 的幂作为块大小，我们有合适的头并且可以进行精确的查找，我们真的可以假装这只是一个块设备。
所以这就是默认情况下音频 CD 不被视为块设备而数据 CD 被视为的原因。
也就是说，没有理由不在文件系统中提供音频 CD 上的信息，例如，作为每个轨道的 WAV 文件。事实上，有一些像CDfs这样的开源项目，或者其他我现在不记得使用 FUSE的开源项目，它们以这种方式表示 CD 数据。但是，您仍然遇到没有抖动校正等问题，因此最好使用类似cdparanoia.
内核人员也认为这是一个坏主意。