[kim-aa]

Ещё насчёт скоростей. Если первая скорость самая правильная, то почему EAC не копирует диски на первой скорости? И значит дли это, что если мы самый "плохой" и дешёвый привод будем запускать с программным ограничением скорости до однократной, например, программой CDSlow, и будем использовать Audiograbber, то достоверное копирование нам обеспечено? »

EAC автоматически понижает скорость вращения при достижении определенной границы ошибок.
Очень плохие диски лучше считывать принудительно задав низкую скорость считывания (средствами EAC) 2x или 4х.
Сами диски я обычно граблю на ограничении в 8х.

В пример приведу собственный опыт. Около двенадцати лет назад я был счастливым обладателем первого пентиума-166, и пользовался программой Audio Catalyst с очень быстро работающим кодеком Xing для кодирования дисков в mp3. Audio Catalyst -- это брат-близнец программы Audiograbber. В обеих этих программах при копировании с диска показывается полоса синхронизации и ошибок. Помню, что ошибки в обычном режиме Buffered burst copy сыпались как их рога изобилия, их было несколько тысяч на каждый трек. Про Unbuffered burst copy вообще речи нет. Особых проблем, однако, в скопированных треках на слух заметно не было. Можно было включить режим синхронизации (их там штук десять разных, с неизвестными различиями), тогда копировалось гораздо медленнее, и ошибки практически отсутствовали. Прошло время, у меня появился мощнейший AMD Duron 766, и я опять поставил копироваться какой-то диск. В штатном буферизованном режиме ошибок не было, всё копировалось со свистом, небуферизованный давал пару ошибок, как раньше синхронизированный. Синхронизированный, понятно, ошибок не давал, и работал с большей скоростью. CD-ROM был тот же, что и в старом первом пентиуме. Теперь компьютер у меня вообще запредельной мощности (см. профиль), соответственно, даже в unbuffered режиме ни одной ошибки нет (теперь Audio Catalyst-ом я воспользоваться не могу, потому что на Windows XP он не работает: пользуюсь Audiograbber-ом, что по сути одно и то же), несмотря на дешёвый старый привод NEC. »

В данной теме я не обсуждаю потери синхронизации при передаче от драйва в память или на диск.
Данная проблема давно уже не актуальна для аудиоформатов.

Диски, на которых записаны, например, файлы mp3 или файлы Excel, разве свободен от этого недостатка? Почему там речь не идёт о первой скорости вращения, а неполноценные дешёвые приводы с копеечной механикой Data-CD читают без проблем? »

Что такое CDDA в оригинале? Грубо говоря это диск со спиральной структурой реализующий последовательный метод записи, т. е. по сути это лента в 74 минуты у которой отсутствует отдельная синхродорожка. На ленту пишутся треки. Причем трек/дорожка это не файл как логическая сущность (с кучей служебной информации), а непосредственно двухканальное 16-битный аудиопоток. Дорожки разделяются паузами (зазорами). Диск может состоять всего из одного трека. Это приводит к следующим проблемам:

1) Как у всякой системы с последовательной передачей возникают определенные трудности с "плаванием" синхронизации т. е. джиттером (это без учета вибраций, царапин и прочих аномалий).
Так же в данной системе важной операцией является определение зазоров между треками (мелодиями) (Если мне память не изменяет ,то зазоры (паузы) могут формироваться несколькими способами).

2) Имеющиеся средства коррекции в формате CDDA (CIRC, перемежение блоков (секторов) одной дорожки) рассчитаны на постоянную скорость воспроизведений 1х
(что единственно-возможный вариант для CDDA). При увеличении скорости чтения (битрейта) средств CDDA становится недостаточно.

(Приведу такой пример соответсвия средств коррекции ошибок, битрейту:
канальные и сетевые уровни протокола FibreChannel расчитаны на то, что физический и логический уровни реализации протокола будут допускать возникновение ошибок с вероятностью не более 10 в -12 степени. Что на прервый взгляд достаточно много. Однако для скорости передачи в 1 Гбит частота возникновения ошибки = раз в 16 минут, для 10 Гбит = раз в полторы минуты. При реализации стандарта 8Гбит, инженеры пошли на изменение метода кодирования, дабы не возникло проблем с масштабированием в дальнейшем).

3) По сути, нет возможности точного позиционирования головки внутри трека, т.к. в формате предполагалось позиционирование на 2х секундные зазоры, а большей точности и не требовалось.

--------------------------------------------------
Для решения вышеперечисленных проблем была разработана Желтая кника.
Если коротко, то она накладывает секторную структуру хранения данных на последовательную дорожку.
Это позволило:
- точно обращаться к той области диска к которой хочешь;
- ввести дополнительные уровни избыточности, причем с алгоритмами более подходящими для случайного доступа;
- "отвязаться" от скорости 1х, т. к. данные в одном секторе - есть данные в одном секторе и без разницы на какой скорости их читать.

--------------------------------------------------
Из проблемы непосредственной записи медиапотока, были сделаны определенные выводы.

Формат DVD был ориентирован уже на файловую структуру.
А в формате DVD+R была введена физическая синхродорожка.