Мой друг пытался экспортировать устройство cdrom по сети с помощью nbdсервера, но мы заметили, что хотя это работает для CD с данными, аудио CD ведут себя не так, как обычные диски с данными. И я говорю не о наличии или отсутствии файловой системы, а о доступе на уровне сырых блоков.
Хотя я понимаю, что аудио компакт-диски не могут быть интерпретированы на уровне файлов, поэтому не могут быть действительноустанавливать, я понимаю, что они содержат много дополнительной информации, которая действительно специфична для аудио, и я понимаю, что у них на самом деле нет CRC, как у дисков с данными, поэтому весь процесс чтения данных отличается, я все еще не совсем понимаю, почему их нельзя прочитать как обычное блочное устройство с /dev/sr0или /dev/cdrom. Что такого особенного в CDDA, что их нельзя просто прочитать на уровне блоков обычным программным обеспечением?
Я имею в виду, что в конечном итоге это просто поток байтов - если не как блочное устройство, то как любое символьное устройство, так почему бы dd/ cat/ nbdне использовать их как любое другое блочное/символьное устройство? Есть ли какая-то фактическая, техническая причина или это просто потому, что никто не нашел рационального варианта использования для реализации такого доступа к среде CDDA в Linux?
решение1
Аудио компакт-диски (также называемыеCD-DA, указанный в фирменномКрасная книга) являются старейшим форматом CD. Формат вдохновлен аудиозаписью, поэтому у вас есть спиральная дорожка с непрерывными данными, и чередующиеся с этими данными данные содержат временную информацию. Нет никаких надлежащих заголовков блоков. Наименьшая единица информации — один кадр, или 1/75 секунды, которая содержит 2352 байта данных (для 2 каналов, 2 выборки/байт, 44,1 кГц).
Обратите внимание, что это не степень двойки и даже не делится на 256 или 512. Поэтому обрабатывать аудиокадры как блоки данных немного неудобно. Вдобавок ко всему, ранние CD-приводы не всегда могли правильно позиционироваться, поэтому если вы скажете им «идти читать кадр в 12 минут 4 секунды и 5 1/75 секунды», они иногда начнут на несколько байт раньше или позже. Вот почему существует так много программ для «правильного» чтения аудио-CD (например, cdparanoia).
Теперь сравните это с CD с данными (также называемым CD-ROM, указанным в Yellow Book): они взяли 2352 байта аудиофрейма и использовали некоторые из них для информации заголовка, чтобы идентифицировать блок. Они также добавили еще один уровень исправления ошибок, поэтому 2352 байта аудиофрейма стали 2048 байтами в фрейме данных.
Теперь у нас есть блок размером в степень двойки, у нас есть правильные заголовки, мы можем выполнять точный поиск и можем действительно притвориться, что это просто блочное устройство.
Вот почему по умолчанию аудио-CD не рассматривается как блочное устройство, а CD с данными — как таковое.
Тем не менее, нет причин не сделать информацию на Audio CD доступной в файловой системе, скажем, в виде WAV-файла для каждого трека. И на самом деле, есть некоторые проекты с открытым исходным кодом, такие какCDFS, или другие, которые я сейчас не могу вспомнить, которые используют FUSE, которые представляют данные CD таким образом. Однако вы все еще застряли с проблемой отсутствия коррекции джиттера и т. д., поэтому вам лучше использовать что-то вроде cdparanoia.
И разработчики ядра тоже думали, что этоплохая идея.
решение2
CDDA для аудио CD был создан до того, как кто-либо создал файловую систему для CD-ROM (сначала High Sierra, а позже ISO 9660). До этого CD просто не мог вести себя как обычный диск с данными. И после этого аудио CD все еще должны были быть обратно совместимы со старыми CD-плеерами, поэтому они не могли изменить это.