4

Мой друг пытался экспортировать устройство cdrom по сети, используя nbd сервер, но мы заметили, что, хотя оно работает для компакт-дисков с данными, аудио-CD на самом деле не ведут себя так, как обычные диски с данными. И я говорю не о наличии или отсутствии файловой системы, а о доступе на уровне блоков.

Хотя я понимаю, что аудио компакт-диски не могут быть действительно интерпретированы на уровне файлов, и поэтому не могут быть действительно смонтированы, я понимаю, что они содержат много дополнительной информации, которая действительно специфична для аудио, и я понимаю, что они на самом деле не имеют CRC точно так же, как диски данных, поэтому весь процесс чтения данных отличается, я до сих пор не совсем понимаю, почему их нельзя прочитать как обычное блочное устройство из /dev/sr0 или /dev/cdrom . Что такого особенного в CDDA, что они не могут быть просто прочитаны на уровне блоков обычным программным обеспечением?

Я имею в виду, в конце концов, это просто поток байтов - если не как блочное устройство, то как любое символьное устройство, так почему dd/cat/nbd не может использовать их как любое другое блочное /символьное устройство? Есть ли какая-то реальная, техническая причина или это просто потому, что никто не нашел рационального варианта использования такого доступа к среде CDDA в Linux?

2 ответа2

4

Аудио компакт-диски (также называемые CD-DA, указанные в Красной книге) являются самым старым форматом компакт-диска. Формат основан на аудиозаписи, поэтому у вас есть спиральная дорожка с непрерывными данными, и эти данные чередуются с информацией о синхронизации. Нет правильных заголовков блоков. Наименьшей единицей информации является один кадр, или 1/75 секунды, который содержит 2352 байта данных (для 2 каналов, 2 выборки / байт, 44,1 кГц).

Обратите внимание, что это не степень двойки и даже не делится на 256 или 512. Поэтому обрабатывать аудио кадры как блоки данных немного неудобно. Кроме того, ранние приводы компакт-дисков не всегда могут располагаться должным образом, поэтому, если вы скажете, что «читайте кадр через 12 минут 4 секунды и 5 1/75 секунд», он иногда запускается на несколько байтов раньше или позже. Вот почему существует так много программ для "правильного" чтения аудио компакт-дисков (например, cdparanoia).

Теперь сопоставьте это с диском данных (также называемым CD-ROM, указанным в «Желтой книге»): они взяли 2352 байта аудиокадров и использовали некоторые из них для информации заголовка, чтобы идентифицировать блок. Они также добавили еще один уровень исправления ошибок, так что 2352 байта аудиокадра становятся 2048 байтами в кадре данных.

Теперь у нас есть степень двойки как размер блока, у нас есть правильные заголовки и мы можем выполнять точный поиск, и мы действительно можем притвориться, что это просто блочное устройство.

Так вот почему по умолчанию аудио-CD не рассматривается как блочное устройство, а диск с данными -.

Тем не менее, нет никаких причин не делать информацию о Audio CD доступной в файловой системе, скажем, как WAV-файл для каждой дорожки. И на самом деле, есть некоторые проекты с открытым исходным кодом, такие как CDfs или другие, которые я не могу вспомнить сейчас, которые используют FUSE, которые представляют данные CD таким образом. Однако вы все еще сталкиваетесь с проблемой отсутствия коррекции джиттера и т.д., Поэтому вам лучше использовать что-то вроде cdparanoia .

И люди из ядра также думали, что это плохая идея.

1

CDDA для аудио CD был создан до того, как кто-либо создал файловую систему для CD-ROM (сначала High Sierra, а затем ISO 9660). До этого компакт-диск просто не вел себя как обычный диск с данными. И после этого аудио-CD все равно должны были быть обратно совместимы со старыми CD-плеерами, поэтому они не могли это изменить.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .