Павел Дмитриев - Dmitriev_Esche_ne_pozdno_3_Razbeg_Pandoryi

Неделю мы с Катей изучали "область данных" в затребованный мощный микроскоп с пристроенным фотоаппаратом. Записывали, стирали, снова записывали разные куски всякими замысловатыми способами. Определенный прогресс был, в пакетном режиме количество появляющихся за сессию данных уменьшалось почти на порядок. Но при этом все равно оставалось невообразимо большим для ручной обработки. Дошло до того, что мне вместо успокаивающей эротики начали сниться черточки, точки, и целые поля, заполненные этими проклятыми символами прогресса! И это притом, что последнее время секс у нас в семье был исключительно с диском и микроскопом!

\\\В этом случае перед пакетом должен идти один связующий (link) сектор и 4 вводных (run-in). После должны быть записаны 2 выводных сектора (run-out). Всего на сессию получится чуть менее полумиллиона "питов".\\\

Наконец терпение супруги подошло к концу, я уже предвкушал заслуженные выходные. Но удача явно была на стороне Кати, когда она добралась до режима "Format CD". Ранее я уже пробовал этот вариант, и отбросил его как непригодный, когда после нескольких минут работы "Nero" диск практический весь покрылся записанными кусками. Моя жена пошла немного дальше - она выяснила, что с обработанным таким образом CD-RW можно работать как с обычным жестким диском, то есть записывать на него файлы быстро и без всяких сессий. Очевидное на первый взгляд знание - но в будущем мне ни разу не приходилось использовать CD подобным образом.

\\\Предварительным форматированием можно организовать CD-RW как устройство прямого доступа. При этом вспомогательные сектора занимают около 120MB. Nero - популярная программа для записи CD.\\\

Дальше было мое самобичевание собственной тупости, снисходительно-победная улыбка супруги, и отупляющие поиски куска, который изменился в результате записи. Нельзя сказать, что найти его было просто, скорее, нам наконец-то повезло... Если, конечно, это можно так назвать, ведь файл в несколько сотен байт при записи каким-то загадочным образом умудрился превратиться в много десятков тысяч "питов"!

\\\Длина "сырой" емкости сектора CD - ровно 2352 байта, не больше и не меньше. Однако в силу раскрытых ниже по тексту особенностей он "вырастает" после записи почти в три раза.\\\

Отступать было поздно, пришлось вспомнить времена "Аватара". По моему техзаданию на базе микроскопа и кинокамеры был собран специальный "комбайн", обеспечивающий покадровую съемку. Отдельной задачей был плавный механизм поворота диска на несколько десятых миллиметра за раз, если смотреть на край. Так, чтоб в захват объектива влезала каждый раз новая порция из двух-трех десятков "питов". С помощью этой техники за пару недель удалось превратить физические дорожки в слое пластика во вполне разборчивые кадры.

Впрочем, на все терпения не хватило. Справедливо рассудив, что чудес не бывает, я предположил, что нужное для расшифровки хранится в начале или конце найденного куска, поэтому мы ограничились пятьюстами кадрами или десятком тысяч бит с обоих сторон. Результатом работы стала здоровенная катушка пленки, которая поехала к шифровальщикам КГБ вместе с распечаткой эталонного файла и моими смутными догадками о способах и особенностях записи.

Последние за какие-то полтора месяца блестяще справились с предложенным квестом. Более того, комитетчики были в восторге от продуманной сложности метода записи данных на неизвестный носитель. Хорошо хоть, лишние вопросы не задавали, наверняка считали, что остальные части секретного устройства исследуют их же коллеги.

В общем, корректирующий код оказался новейшим, но уже вполне известным, носил имя Рида-Соломона и имел в основании число 256. Однако в технике не использовался, и мне быстро объяснили причину. Сам по себе процесс кодирования очень прост. Порцию данных в 2 килобайта нужно всего-то "пропустить" через полином, порожденный правилам арифметики Галуа. Тут лучше не вдумываться в непонятные термины, а верить специалистам на слово. Плохо другое, алгоритм исправления ошибок минимум на порядок сложнее, следовательно на скорости в 300 бод с ним не справится даже целая БЭСМ-4.

\\\Код Рида-Соломона был изобретён в 1960 году Ирвином Ридом и Густавом Соломоном. Для записи CD-дисков он был применен в 1982 году. В данном случае алгоритм позволяет исправлять до 392 байт на блок данных из 2048 байт.\\\

Стала понятной и наша с Катей неспособность что-то понять в записи. Оказывается, каждый байт из потока уже закодированных данных подвергался преобразованию в четырнадцать бит, а между этими словами вставлялись как разделители 3-х битные куски так, чтобы на носителе было не более 10 нулей или единиц подряд. Дополнительно к этому добавлялись синхробайты, контрольная сумма и байт служебной информация непонятного назначения.

\\\Для физической "читабельности" применяется 14-битное EFM-слово (от английского Eight to Fourteen Modulation - модуляция восемь в четырнадцать).\\\

Уж не знаю, сколько седых волос нажили специалисты-криптографы, разбираясь в этом "взрыве мозга". А применить корректирующее кодирование на практике все равно нельзя, невообразимо сложно для 1966 года. Причем не только алгоритм Рида-Соломона, а любые известные науке варианты. Их, кстати, хватает - у капиталистов отличился Хемминг, в СССР зав. кафедрой Ленинградской академии связи, товарищ Финк предлагал комитетчикам сверточный код еще в конце 50-х...

Разумеется, никто не запрещает сперва создавать образ диска на ЭВМ, а уже потом "кидать" его на резец. Но для этого надо сперва подготовить блок данных в ОЗУ или на магнитном барабане, а лишь потом перенести его на "виниловую дискету". В теории вполне реально, но практика 60-х сразу ставит крест на затее. Нет тут подходящих объемов памяти, и процессорное время стоит совсем не копейки. Потратить несколько часов ЭВМ ради удобства хранения данных? Спецы только пальцем у виска покрутят, да вежливо пошлют... В сад, ага.

\\\Первое применение в серийном изделии код Рида-Соломона получил в контроллере жесткого диска IBM 3370 емкостью 571 Мбайт в 1979 году.\\\

Пришлось откатиться на позорный примитив. Федор с расстройства задействовал триады, например вместо "1" - "111". Безусловно, надежность резко выросла, зато емкость упала катастрофически. Двадцать килобайт на мой взгляд попросту не стоили возни, так как влезали на полсотни метров широко распространенной перфоленты.

Поэтому опробовали более экономный вариант - навесили на блоки записываемых данных биты четности для проверки контрольной суммы, и начал записывать на пластинку сразу две копии, разнеся их на пару килогерц. Соответственно, при считывании использовался только "целый" блок. Но ничего хорошего из этого не получилось. Надежность обнаружения дефекта по одному биту оказалась недостаточной, требовалось серьезное усложнение. Вроде бы ничего страшного, задача вполне посильная технике 66-го года... Но уж слишком часто при механическом повреждении дорожки погибали сразу обе копии. В принципе, решение было и тут, достаточно один из каналов "резать" с задержкой по времени...