Комментарии 9
Как говорится, добавлю свои 5 копеек к теме CD записи.
Зачем использовать кодирование 8-to-14? Всё очень просто. Для гаранритованного чтения записанных данных.
Действительно на поверхности диска могут возникнуть ошибки в данных как при записи, так и при чтении. Собственно, этих ошибок в какой-то мере позволяет избежать таблица значений. Не буду приводить громоздких примеров, ограничусь лишь общей фразой: "Узнать искажённую знакомую последовательность проще, чем гадать где же была ошибка в байте". Достаточно хороший метод исправления ошибок, а так же, для улучшения синхронизации с дорожкой в потоке нулей.
В этом плане технология похожа на Ethernet с кодированием 4-to-5 и на некоторые другие. Как пример могу ткнуть в E1-фреймы (телефония), но там код всё же другой (HDB3, работающий с отрицательными и положительными импульсами), но и в нём так же используется занятный метод кодирования информации, добавляющий дополнительные импульсы по определённой функции к потоку для гарантии устойчивой синхронизации кадров.
Зачем использовать кодирование 8-to-14? Всё очень просто. Для гаранритованного чтения записанных данных.
Действительно на поверхности диска могут возникнуть ошибки в данных как при записи, так и при чтении. Собственно, этих ошибок в какой-то мере позволяет избежать таблица значений. Не буду приводить громоздких примеров, ограничусь лишь общей фразой: "Узнать искажённую знакомую последовательность проще, чем гадать где же была ошибка в байте". Достаточно хороший метод исправления ошибок, а так же, для улучшения синхронизации с дорожкой в потоке нулей.
В этом плане технология похожа на Ethernet с кодированием 4-to-5 и на некоторые другие. Как пример могу ткнуть в E1-фреймы (телефония), но там код всё же другой (HDB3, работающий с отрицательными и положительными импульсами), но и в нём так же используется занятный метод кодирования информации, добавляющий дополнительные импульсы по определённой функции к потоку для гарантии устойчивой синхронизации кадров.
О назначении 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:
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.
Гм… да… стандарт на выходных разобрал а в вики посмотреть забыл… ^__^
Кстати, спасибо за ссылку на Кееса Схаухамера Имминка.
Наяндексил его книгу "Codes for Mass Data Storage Systems".
На досуге почитаю.
Кстати, спасибо за ссылку на Кееса Схаухамера Имминка.
Наяндексил его книгу "Codes for Mass Data Storage Systems".
На досуге почитаю.
Была где-то статья что из-за алгоритма скремблирования кодирование определённого набора байт в итоге на диск пишется участок данных точь в точь совпадающий с старым маркером начала дорожки(кажется, 56 байт подряд идущих нулей или что-то вроде того), на которых реагировали приводы со старой пошивкой в которой был код который поддерживал такие маркеры.
В итоге долго не могли понять почему при записи определённого фильма на компакт многие приводы просто не могли прочитать это место на диске, спотыкаясь. Маркер-то есть, привод реагирует но дальше данные не валидны для начала дорожки и привод честно рапортует об ошибке чтения… Потом уже выделили эту магическую последовательность байт и с каким смещением она должна находится в пользовательских данных чтобы привести к проблеме и успешно воспроизвели. Так что, в принципе применённое скремблирование не способно на 100% размазать спектр сигнала, вероятно поэтому дополнительно используют еще и 8-в-14 кодирование.
По сложности, это наверно как найти данные, для которых хеш даёт много нулей подряд.
В итоге долго не могли понять почему при записи определённого фильма на компакт многие приводы просто не могли прочитать это место на диске, спотыкаясь. Маркер-то есть, привод реагирует но дальше данные не валидны для начала дорожки и привод честно рапортует об ошибке чтения… Потом уже выделили эту магическую последовательность байт и с каким смещением она должна находится в пользовательских данных чтобы привести к проблеме и успешно воспроизвели. Так что, в принципе применённое скремблирование не способно на 100% размазать спектр сигнала, вероятно поэтому дополнительно используют еще и 8-в-14 кодирование.
По сложности, это наверно как найти данные, для которых хеш даёт много нулей подряд.
Предположу (основываясь на некотором изучении MD устройств) одно из назначений EFM (помимо спектра, и постоянной составляющей) — восстановление тактовых импульсов для дальнейших преобразований. Ведь на диске нет отдельного тактового сигнала (как в i2s, например). Жестко привязать вращение диска к частоте тактового генератора тоже не получится. Следовательно на нижнем уровне нам нужно некоторое кодирование которое позволит выделить тактовый сигнал и поток данных не смотря на возможные ошибки "аналоговой природы" (проскальзывание, ошибки слежения, неидеальность установления скорости вращения диска и т.д.) в сигнале прочитанном фотодиодом.
Про манипуляции с данными на компакт-дисках и срыв синхронизации на некоторых приводах на IXBT была классная детективная история (спойлер: убийца — скремблер).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ECMA-130 (Compact Disc) на пальцах