Литмир - Электронная Библиотека
Содержание  
A
A

Поскольку две соседние единицы всегда оказываются разделены, по меньшей мере, тремя нулями, приходится прибегать к сложной системе перекодировки, преобразующей всякий 8-битный символ исходных данных в 14- битное слово EFM (Eight to Fourteen Modulation). При этом слова EFM не могут следовать вплотную друг за другом (задумайтесь, что произойдет, если за одним словом EFM, оканчивающимся на единицу, попробовать записать другое слово EFM, которое тоже начинается с единицы). Таким образом, слова EFM должны разделяться тремя объединительными битами (merging bits). Соответственно, на каждые 8 бит исходных данных приходится 9 избыточных данных. Очевидно, что стандартная схема модуляции не является идеальной и оставляет достаточный запас для ее усовершенствования. Более подробно этот вопрос будет рассмотрен далее в этой главе.

Минимальной порцией данных, непосредственно адресуемой на программном уровне, является сектор (или в терминологии Audio CD — блок). Один блок состоит из 98 фреймов, каждый из которых, в свою очередь, содержит:

□ 24 байта полезных данных;

□ 8 байт кодов Рида-Соломона, часто называемых перекрестно-перемежающимися кодами Рида-Соломона (cross-inerleaved Reed-Solomon codes, CIRC codes), хотя с технической точки зрения это и не совсем верно;

□ 3 синхробайта;

□ 8 бит каналов подкода — по одному биту на каждый из восьми каналов, условно обозначаемых латинскими буквами P, Q, R, S, T, U, V и W соответственно. Q-канал хранит служебную информацию о разметке диска, P-канал служит для быстрого поиска пауз, остальные каналы — свободны.

Таким образом, эффективная емкость одного блока составляет 2352 байта, или даже 2400 байт, с учетом каналов подкода (из 98 байт субканальных данных — 34 байта отданы под служебные нужды). Корректирующие коды Рида-Соломона позволяют исправлять до 4 разрушенных байт на каждый фрейм, что составляет 392 байта на целый блок.

Диски с данными (Data CD), ведущие свою родословную от Audio-дисков, поддерживают два основных режима обработки данных: MODE 1 и MODE 2.

В режиме MODE 1 из 2352 байт сырой емкости сектора лишь 2048 байт отданы непосредственно под пользовательские данные. Остальные распределены между заголовком сектора (16 байт), контрольной суммой сектора (4 байта) и дополнительными корректирующими кодами, увеличивающими стойкость диска к физическим повреждениям (276 байт). Оставшиеся 8 байт никак не задействованы и обычно проинициализированы нулями.

В режиме MODE 2 из 2352 байт сырой емкости сектора только 16 байт отданы под служебные структуры (заголовок), а остальные 2336 байт содержат пользовательские данные. Легко видеть, что при записи диска в MODE 2 его эффективная емкость становится на -15% больше, но и надежность хранения данных при этом становится приблизительно на треть ниже. Однако при использовании качественных носителей информации (LG, TDK, Verbatim) и бережном обращении с ними риск невосстановимого разрушения данных достаточно невелик. К тому же, многие форматы данных безболезненно переносят даже множественные искажения средней и высокой степени тяжести. К этой категории относятся DivX, MP3, JPEG и другие типы файлов. С некоторой долей риска можно записывать архивы и исполняемые файлы, потерей которых вы не сильно огорчитесь, или которые возможно восстановить из основного хранилища (например, при переносе файлов между компьютерами, дублировании дисков, взятых напрокат, и т.д.).

Чистый MODE 2 встречается крайне редко, однако с его производными нам приходится сталкиваться буквально на каждом шагу. Это и CD-ROM XA MODE 2 (применяющийся в многосессионных дисках), и Video CD/Super Video CD, и CD-I, и многое многое другое.

Формат CD-ROM XA, возникший на фундаменте MODE 2, выгодно отличается от своего предшественника возможностью динамической смены типа трека на всем его протяжении. Часть трека может быть записана в режиме FORM 1, практически идентичном режиму MODE 1, но задействующем восемь ранее пустующих байт под нужды специального заголовка. Другая часть трека может быть записана в FORM 2 — усовершенствованном MODE 2: 2324 байта пользовательских данных, 16 байт основного и 8 байт вспомогательного заголовков плюс 4 байта контрольной суммы для контроля целостности (но не восстановления!) содержимого сектора.

Режим FORM 1 предполагалось использовать для критических к разрушению данных (исполняемых файлов, архивов и т.д.), a FORM 2 — для аудио/видеоданных. Увы, этим замыслам было не суждено сбыться, и широкого распространения режим FORM 2 так и не получил. Единственным популярным форматом, опирающимся на режим XA MODE 2 FORM 2, стал Video CD/Super Video CD, позволяющий записать на обычном 700-мегабайтном диске до 800 Мбайт информации и 900 Мбайт — на 90-минутном (плюс overburn). Это приблизительно на четыре мегабайта меньше, чем в чистом MODE 2, но такими потерями можно и пренебречь. Зато, в отличие от чистого MODE 2, формат Video CD/Super Video CD поддерживается операционными системами семейств Windows и Linux!

Проблемы

Сам по себе MODE 2 никаких сложностей не вызывает. Это — стандартный режим, штатно поддерживаемый всеми приводами, носителями и драйверами. Проблема состоит в том, что ISO 9660 и все файловые системы на ее основе налагают на размер сектора жесткие ограничения, требуя, чтобы он представлял собой степень двойки (т.е. составлял 512, 1024, 2048, 4096… байт). Размер пользовательской области данных сектора, записанного в MODE 1, удовлетворяет этому требованию (211=2048). О MODE 2 этого сказать нельзя, и в конце сектора остается "хвост" из 288 неиспользуемых байт (211+288=2336).

Программы профессионального "прожига" позволяют записывать диск как в XA MODE 2 FORM 1, так и в XA MODE 2 FORM 2. Однако это ни на йоту не увеличивает его объема, поскольку хвостовая часть секторов, записанных в FORM 2, вынуждена пустовать, что снижает надежность хранения данных, ничего не давая взамен.

Теоретически возможно создать драйвер, транслирующий n секторов MODE 2 в k*n секторов MODE 1, и мне действительно удалось его создать. Однако целесообразность его использования весьма сомнительна, поскольку далеко не каждый пользователь согласится устанавливать в свою систему "кустарный" драйвер. Ошибки драйверов зачастую обходятся непомерно дорого — вплоть до потери всех данных, хранившихся на жестком диске, а программисты, как и все люди в этом мире, склонны ошибаться. Так или иначе, от идеи использования драйвера я отказался, поскольку ею тестирование выглядело слишком масштабным проектом.

Немногим лучше обстоят дела и с Video CD/Super Video CD. На первый взгляд кажется: ну какие тут могут быть проблемы? Берем Ahead Nero Burning ROM, в меню диалогового окна New Compilation выбираем опцию Video CD, а затем записываем диск. Диск действительно записывается, но только в формате MPEG1. Формат Super Video CD, в свою очередь, соответствует MPEG2. Никакого обмана здесь нет — вы получаете 800/900 Мбайт настоящего MPEG1/MPEG2, что на 100 Мбайт превосходит емкость стандартного CD-R (рис. 10.17).

Восстановление данных. Практическое руководство - img_98.jpeg

Рис. 10.17. Запись Video CD/Super Video CD средствами Ahead Nero Burning ROM. Емкость одного такого диска составляет порядка 800 Мбайт (900 Мбайт на 90-минутных CD-R), однако исходные данные должны быть представлены в формате MPEG1/MPEG2.

В то же время использование DivX (MPEG4) дает значительно больший выигрыш в емкости, сжимая два Video CD в один CD-ROM. Но что нам мешает записать в формате Video CD тот же самый MPEG4 или MP3? Увы, не все так просто! Большинство программ записи, включая Ahead Nero Burning ROM, осуществляют тщательную проверку всех данных, записываемых на диск. Столкнувшись с MPEG-4, они либо принудительно перекодируют данные в MPEG1/MPEG2, либо вообще отказываются от записи. Мотивация этого поведения такова — Video CD должен соответствовать Стандарту, иначе это не Video CD. Действительно, автономные Video-проигрыватели поддерживают диски строго определенных типов, и на декодирование MPEG4 у них не хватит аппаратной мощности. Персональный компьютер — другое дело. При наличии соответствующих кодеков он воспроизведет любой мультимедийный формат, независимо от того каким способом тот будет записан.

84
{"b":"837815","o":1}