Pull to refresh

Comments 9

Как говорится, добавлю свои 5 копеек к теме CD записи.
Зачем использовать кодирование 8-to-14? Всё очень просто. Для гаранритованного чтения записанных данных.
Действительно на поверхности диска могут возникнуть ошибки в данных как при записи, так и при чтении. Собственно, этих ошибок в какой-то мере позволяет избежать таблица значений. Не буду приводить громоздких примеров, ограничусь лишь общей фразой: "Узнать искажённую знакомую последовательность проще, чем гадать где же была ошибка в байте". Достаточно хороший метод исправления ошибок, а так же, для улучшения синхронизации с дорожкой в потоке нулей.
В этом плане технология похожа на Ethernet с кодированием 4-to-5 и на некоторые другие. Как пример могу ткнуть в E1-фреймы (телефония), но там код всё же другой (HDB3, работающий с отрицательными и положительными импульсами), но и в нём так же используется занятный метод кодирования информации, добавляющий дополнительные импульсы по определённой функции к потоку для гарантии устойчивой синхронизации кадров.
То есть это еще один код, помимо RSPC и CIRC кодирования?
Неужели нужна ТАКАЯ избыточность 0_о...
Диски делаются из мягкого дешёвого пластика, хранятся хрен пойми как, в процессе покрываются царапинами, и после всего этого их ещё можно прочитать. Так что да, такая избыточность совсем не лишняя.
Я тут подумал…
Может быть 8-to-14 кодирование используется для обнаружения ошибок, а RSPC и CIRC уже для исправления?..

Хабр, тут есть спецы по данному вопросу?
О назначении 8-to-14 кодирования: https://en.wikipedia.org/wiki/Eight-to-fourteen_modulation
EFM belongs to the class of DC-free run length limited (RLL) codes; these have the following two properties:

  • the spectrum (power density function) of the encoded sequence vanishes at the low-frequency end and
  • both the minimum and maximum number of consecutive bits of the same kind are within specified bounds.
Была где-то статья что из-за алгоритма скремблирования кодирование определённого набора байт в итоге на диск пишется участок данных точь в точь совпадающий с старым маркером начала дорожки(кажется, 56 байт подряд идущих нулей или что-то вроде того), на которых реагировали приводы со старой пошивкой в которой был код который поддерживал такие маркеры.
В итоге долго не могли понять почему при записи определённого фильма на компакт многие приводы просто не могли прочитать это место на диске, спотыкаясь. Маркер-то есть, привод реагирует но дальше данные не валидны для начала дорожки и привод честно рапортует об ошибке чтения… Потом уже выделили эту магическую последовательность байт и с каким смещением она должна находится в пользовательских данных чтобы привести к проблеме и успешно воспроизвели. Так что, в принципе применённое скремблирование не способно на 100% размазать спектр сигнала, вероятно поэтому дополнительно используют еще и 8-в-14 кодирование.
По сложности, это наверно как найти данные, для которых хеш даёт много нулей подряд.
Предположу (основываясь на некотором изучении MD устройств) одно из назначений EFM (помимо спектра, и постоянной составляющей) — восстановление тактовых импульсов для дальнейших преобразований. Ведь на диске нет отдельного тактового сигнала (как в i2s, например). Жестко привязать вращение диска к частоте тактового генератора тоже не получится. Следовательно на нижнем уровне нам нужно некоторое кодирование которое позволит выделить тактовый сигнал и поток данных не смотря на возможные ошибки "аналоговой природы" (проскальзывание, ошибки слежения, неидеальность установления скорости вращения диска и т.д.) в сигнале прочитанном фотодиодом.
Sign up to leave a comment.

Articles