通常のデータCDのようにCDオーディオを単に「dd」できないのはなぜですか。
私の友人はnbdサーバーを使用してネットワーク経由でcdromデバイスをエクスポートしようとしましたが、データCDで機能しますが、オーディオCDは通常のデータディスクのように動作しないことに気付きました。そして、私はファイルシステムの存在または欠如について話しているのではなく、生のブロックレベルのアクセスについて話している。
オーディオCDはファイルレベルで実際に解釈できないため、実際には解釈できないことを理解していますが、実際にはmountですが、オーディオに固有の追加情報がたくさん含まれていることを理解しています。データディスクと同じようにCRCが実際にはないため、データ読み取りプロセス全体が異なりますが、/dev/sr0または/dev/cdromから通常のブロックデバイスのように読み取れない理由はまだよくわかりません。 CDDAの何が特別なので、通常のソフトウェアではブロックレベルで読み取ることができませんか？
つまり、最終的にはバイトのストリームにすぎません。ブロックデバイスが好きではない場合は、任意の文字デバイスが好きなので、なぜdd/cat/nbdはそれらを他のように使用できないのですか？他のブロック/キャラクターデバイス？実際の技術的な理由はありますか、それともLinuxでCDDAメディアへのそのようなアクセスを実装するための合理的なユースケースを誰も見つけられなかったからですか？
オーディオCD（ CD-DA とも呼ばれ、独自仕様の Red Book で指定）は、CDの最も古い形式です。このフォーマットはオーディオレコードに触発されているため、連続データを含むスパイラルトラックがあり、このデータとインターリーブされているのがタイミング情報です。適切なブロックヘッダーはありません。情報の最小単位は1フレーム、つまり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 のようなオープンソースプロジェクトや、CDデータをこのように表すFuseを使用している今のところ思い出せないプロジェクトがいくつかあります。ただし、ジッター補正などがないという問題がまだ残っているので、cdparanoiaのようなものを使用することをお勧めします。
そしてカーネルの人々もそれが 悪い考え だと思った。
オーディオCD用のCDDAは、CD-ROM用のファイルシステムを作成する前に作成されました（最初はHigh Sierra、その後はISO 9660）。それ以前は、CDは通常のデータディスクとしては動作しませんでした。その後、オーディオCDは古いCDプレーヤーとの下位互換性が必要だったため、変更できませんでした。