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