友人がnbdサーバーを使用してネットワーク経由で CD-ROM デバイスをエクスポートしようとしましたが、データ CD では機能する一方で、オーディオ CD は通常のデータ ディスクのようには動作しないことがわかりました。また、ファイルシステムの有無についてではなく、生のブロック レベルのアクセスについて話しているのです。
オーディオCDはファイルレベルでは解釈できないので、マウント、オーディオに特有の多くの追加情報が含まれていること、データ ディスクのように CRC がないため、データの読み取りプロセス全体が異なることは理解していますが、通常のブロック デバイスのように または から読み取れない理由がまだよくわかりません/dev/sr0。CDDA/dev/cdromの何がそんなに特別なので、通常のソフトウェアでブロック レベルで読み取れないのでしょうか。
つまり、結局のところ、それは単なるバイト ストリームです。ブロック デバイスでなくても、任意の文字デバイスと同じであれば、他のブロック/文字デバイスと同じように使用できないのはなぜでしょうddか。実際の技術的な理由があるのでしょうか。それとも、Linux で CDDA メディアへのこのようなアクセスを実装するための合理的な使用例を誰も見つけられなかっただけなのでしょうか。catnbd
答え1
オーディオCD（CD-DA、独自の赤い本) は CD の最も古い形式です。この形式はオーディオ レコードにヒントを得たもので、連続したデータを含むスパイラル トラックがあり、このデータにタイミング情報がインターリーブされています。適切なブロック ヘッダーはありません。情報の最小単位は 1 フレーム、つまり 1/75 秒で、2352 のデータ バイト (2 チャネル、2 サンプル/バイト、44.1 kHz) が含まれます。
これは 2 の累乗ではなく、256 や 512 で割ることもできないことに注意してください。したがって、オーディオ フレームをデータ ブロックとして扱うのは少々不便です。さらに、初期の CD ドライブは必ずしも適切に位置付けられるわけではないため、「12 分 4 秒 5 1/75 秒のフレームを読み取ってください」と指示すると、数バイト早くまたは遅く開始することがあります。そのため、オーディオ CD を「適切に」読み取るプログラムが数多くあります (などcdparanoia)。
これをデータ CD (イエロー ブックで CD-ROM とも呼ばれる) と比較してみましょう。データ CD では、オーディオ フレームの 2352 バイトが取得され、その一部をブロックを識別するためのヘッダー情報として使用しています。また、別のレベルのエラー訂正も追加されたため、オーディオ フレームの 2352 バイトはデータ フレームでは 2048 バイトになります。
これで、ブロック サイズが 2 の累乗になり、適切なヘッダーが確保され、正確なシークを実行できるようになり、これが単なるブロック デバイスであると見なすことができます。
そのため、デフォルトでは、オーディオ CD はブロック デバイスとして扱われず、データ CD はブロック デバイスとして扱われます。
そうは言っても、オーディオCDの情報を、例えば各トラックのWAVファイルとしてファイルシステムで利用できるようにしない理由はありません。実際、次のようなオープンソースプロジェクトがあります。CDfs、または今は思い出せないが、FUSE を使用する他のものなど、CD データをこのように表現するものがあります。ただし、ジッター補正などがないという問題は依然として残るので、 のようなものを使用する方がよいでしょうcdparanoia。
そしてカーネルの人たちも、悪いアイデア。
答え2
オーディオ CD 用の CDDA は、CD-ROM 用のファイルシステム (最初は High Sierra、その後 ISO 9660) が作成される前までに作成されました。それ以前は、CD は通常のデータ ディスクとして動作できませんでした。その後も、オーディオ CD は古い CD プレーヤーとの下位互換性を維持する必要があったため、変更できませんでした。