[dascon]

"...EAC способна гарантировать качество, недостижимое для прочих программ. В отличие от них, EAC читает каждый аудиосектор дважды и сравнивает полученные данные между собой. Если они идентичны - EAC знает, что ошибки чтения нет. Если же они различаются, тогда EAC знает, что по крайней мере один сектор был считан неверно. В этом случае EAC считывает ошибочный сектор снова, пока не получит верных данных, и делает это, если нужно, до 82 раз. Таким образом, аудиоданные могут быть восстановлены чаще, чем при использовании других программ (если те вообще заметят ошибку)..."

http://www.music4jesus.ru/article/EACtuning.htm

[kim-aa]

EAC ориентирован только на формат CDDA, соответственно все алгоритмы коррекции и распознавания работают точнее, чем алгоритмы более "общего" назначения.

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

2) Средствами EAC возможна запись собственного калибровочного диска (да и CDDA в целом),
по которому EAC калибрует смещение головок, оценивает точность процедуры определения начала/конца трека.
Так же можно протестировать аппартные функции коррекции ошибок при чтении:
- C2
- Accurate Streaming
- Алгоритм определения начала/конца трека.

3) Наилучшие результаты обработки CDDA получаются на старых CD или CD-R/DVD-ROM комбайнах со скоростями 24-32.
Сам до сих пор держу 24x TEACK комбайн для считывания CD.

4) Так же не подводит Plextor.

5) Современные же CD и DVD с высокими скоростями чтения, читают диски крайне отвратительно, т.к. на механике там явно экономят, а коррекцию ошибок осуществляют цифровыми методами (достаточно взвесить старый девайс и новый)

6) Да кстати, EAC не плохо работает из под VMWare, т.е. на Windows host-машине.
У меня под SUSE такая связка год жила.

7) Наилучшей функциональности EAC добивается при установке ASPI драйвера
(EAC может работать c драйвами в двух режимах:
- ASPI
- win32 native)

[DJ Mogarych]

EAC читает каждый аудиосектор дважды и сравнивает полученные данные между собой. Если они идентичны - EAC знает, что ошибки чтения нет »

Это, кстати, к достоверности информации отношения не имеет. Считал два раза неверную информацию, сравнил, получил один и тот же результат (неверный) -- посчитал, что всё правильно. Поехал дальше.
Другое дело, если бы читалась информация и оригинальная контрольная сумма, потом вычислялась контрольная сумма считанной информации и сравнивалась бы с оригинальной. Как в цифровой подписи.
Надо бы ознакомиться с авторским описанием EAC.

можно протестировать аппартные функции коррекции ошибок при чтении: - C2 - Accurate Streaming - Алгоритм определения начала/конца трека. »

У меня вопрос. Если функции коррекции аппаратные, то есть зашиты в привод, то привод использует их автоматически сам, и ему всё равно, какой софт сейчас к нему обращается. Софт получает уже готовые результаты. Как же софт может влиять на аппаратные функции? Какая разница, EAC тянет данные с привода, который использует свои аппаратные возможности, или какая-либо другая программа?

на механике там явно экономят, а коррекцию ошибок осуществляют цифровыми методами »

Тоже не понял. Коррекция ошибок вроде бы всегда была цифровой. Как механикой можно ошибки исправлять? И к чему мы тогда говорим о мощи EAC, если "правильная" коррекция ошибок -- механическая?

Наилучшей функциональности EAC добивается при установке ASPI драйвера »

Странно. ASPI -- это интерфейс Windows 9x, то есть, интерфейс десятилетней давности для отживших своё операционных систем. Почему же он работает лучше, чем современный SPTI?

Объявление: мои вопросы не содержат скрытых намёков к личностям авторов сообщений, как это принято у сетевых троллей. Просто у меня есть некоторые вопросы, которые хотелось бы выяснить насколько возможно объективно, по причине моего незнания предмета и нежелания просто поверить общественному мнению и заверениям автора EAC, что он написал самую лучшую программу. И вопросы я задаю именно по существу предмета на основании моих собственных скромных знаний и логики.

[kim-aa]

Странно. ASPI -- это интерфейс Windows 9x, то есть, интерфейс десятилетней давности для отживших своё операционных систем. Почему же он работает лучше, чем современный SPTI? »

С какого перепугу ASPI относится к Win98?

ASPI - Advanced SCSI Programming Interface.

Adaptec просто первая реализовала подмножество команд SCSI-3 относящихся к CD - DVD на Win-98.
SPTI это реализация подмножества SCSI-3 для CD(DVD) уже от Microsoft.

Так же есть реализация ASAPI - от VOB Computersysteme GmbH (собственность Pinnacle Systems ), ее я тоже пользовал и нареканий не имею.

Я всего лишь озвучил рекомендации EAC.

У меня вопрос. Если функции коррекции аппаратные, то есть зашиты в привод, то привод использует их автоматически сам, и ему всё равно, какой софт сейчас к нему обращается. Софт получает уже готовые результаты. Как же софт может влиять на аппаратные функции? Какая разница, EAC тянет данные с привода, который использует свои аппаратные возможности, или какая-либо другая программа? »

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

Тоже не понял. Коррекция ошибок вроде бы всегда была цифровой. Как механикой можно ошибки исправлять? И к чему мы тогда говорим о мощи EAC, если "правильная" коррекция ошибок -- механическая? »

Это не так. Hi-End лазерные проигрыватели очень много внимания уделяют равномерному "кручению" CD.
Кстати скорость 1х и значит чтение CD с его натуральной скоростью воспроизведения, при данной операции и "добывается" естественная синхронизация для воспроизведения битового потока.

Что касаемо джиттера.
Любая дисковая система имеет бОльшую линейную скорость движения точек наиболее удаленных от центра.
Структура материала диска неравномерна и имеет дисбаланс.
Соответствено края диска имеют свойство "трепыхаться", причем чем сильне скорость вращения тем больше колебания.
Это можно назвать механическим джиттером.

Для борьбы с этим явлением, например в CD Проигрывателях Pioner 7хх и выше класса применялась ситема когда CD укладывался дорожками к верху на массивную металлическую болванку которая уже вращалась. Т. е. из-за разницы весов, дисбаланс диска не оказывал ни какого влияния на скорость вращения и синхронизацию вращения.

1) Старые CD обладают заведомо меньшей максимальной скоростью вращения, соответсвенно механический джиттер у них меньше.

2) С потерями синхронизаци при чтении можно бороться двумя способами:
2.1 - потратится на дорогой синхронизированный двигатель и массивную систему фиксации диска на шпинделе.
2.2. - не тратится на синхронизированный двигатель и пытаться корректирвать ошибки чтения многократным упреждающим чтением и выбором среднего (наиболее часто повторяющего варианта).
Это очень не плохо работает на файловых системах с большой избыточностью, однако для CDDAпрактически не работает и вот почему:
--Вариант 2.2. требует заранее повышенную скорость чтения, что в свою очередь ведет к росту механического джиттера.
Более того "рванный" (старт-стопный) режим еще более ухудшает ситуацию с вибрациями диска.
-- Как я уже говорил CDDA обладает относительно не большой избыточностью информации, что связано со старостью формата и расчетом на воспроизведение его на скорости 1х.
Скорость чтения в 52х в 80м году как-то не представлялась.

И к чему мы тогда говорим о мощи EAC, если "правильная" коррекция ошибок -- механическая? »

Я озвучил собственный опыт грабления CD (может быть несколько коряво).
Я хотел сказать что на хреновом драйве результат EAC будет чуть лучше чем у остального ПО, т. е. не "хреново", а "так себе".
И стоит обратить внимание на драйв на котором собираешься читать.

[DJ Mogarych]

С какого перепугу ASPI относится к Win98? »

Без драйвера ASPI в линейке Win9x не работали функции записи дисков и их копирования. Я не о том, что ASPI являлся частью Windows 98, а о том, что этот драйвер был необходим. Такие программы, как Nero, ставили свой ASPI-драйвер.
SPTI, насколько я помню, появился только в Windows 2000.
И разве SPTI хуже, чем ASPI?

Это не функции автоматической коррекции ошибок, как таковые. »

Обнаружил интересную вещь. Перевод мой.

Что такое ошибки С2? У CD-ROM-а есть различные уровни распознавания и коррекции ошибок. Одним из уровней коррекции ошибок является коррекция ошибок С2. ошибки С2 обычно поддаются коррекции, то есть CD-ROM самостоятельно способен исправить некоторое количество ошибок С2. Если ошибок С2 встречается много, CD-ROM интерполирует потерянную информацию (то есть, "угадывает" повреждённые данные). Обычно о поддающихся коррекции ошибках С2 не сообщается (потому что они обычно бывают исправлены). Если ошибок С2 много (то есть, исправить их не представляется возможным), большинство CD-ROM-ов рапортуют об ошибке. (Некоторые приводы интерполируют молча, и сообщают только о больших нечитаемых областях). Существуют приводы, сообщающие дополнительную информацию -- где попадались ошибки С2 и были ли они исправлены приводом самостоятельно.

Источник.

Вопрос: Было бы неплохо, если бы после ошибки С2 программа автоматически пыталась прочитать сектор ещё раз или уменьшала бы скорость чтения, а? Ответ: НЕТ -- это было бы контрпродуктивно. Как описано в статье об ошибках С2 (первый источник), эти ошибки МОГУТ БЫТЬ ИСПРАВЛЕНЫ. Подразумевается, что данные читаются, как правило, корректно: ошибки С2 видятся больше как предупреждение. Если вы немедленно попытаетесь повторно прочитать сектор с ошибкой или уменьшить скорость чтения, CD-ROM начнёт перезапуск. Риск получить ошибку при перезапуске больше, чем риск от ошибок С2, не скорректированных системой их обнаружения. Таким образом, подобные настройки приведут в среднем к ХУДШЕМУ результату.

Источник.

края диска имеют свойство "трепыхаться", причем чем сильне скорость вращения тем больше колебания. Это можно назвать механическим джиттером. »

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

Скорость чтения в 52х в 80м году как-то не представлялась. »

"Жёлтая книга", то есть, формат Data-CD, сделан в 1985 году. Сомневаюсь, что тогда тоже шла речь о каких-либо скоростях.

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

В пример приведу собственный опыт. Около двенадцати лет назад я был счастливым обладателем первого пентиума-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.

Эта ситуация показывает, что для копирования CD-Audio важен не привод, а быстродействие компьютера. Прежде всего -- способность жёсткого диска обеспечивать нужную пропускную способность в реальном времени без задержек, а также количество памяти, в случае чего служащей буфером для поступающей информации. Очень схоже с видеозахватом: чтобы не было пропущенных кадров, нужен компромисс по загрузке процессора и жёсткого диска. Так как сейчас для компьютеров какие-либо проблемы с быстродействием в свете работы с AudioCD неактуальны уже давным-давно, следовательно, проблемы достоверного копирования дисков не существует. Любой самый дешёвый привод так же точно копирует и считывает, а также обладает всеми возможными в этом старом стандарте механизмами коррекции ошибок, как и такой же дешёвый привод во чреве хай-энд проигрывателей, освящённый кадилом рекламщиков.
Хай-энд, по моему скромному мнению, тема больше религиозная, живой пример переоценки человеком своих возможностей восприятия и дань тщеславию.

[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 была введена физическая синхродорожка.

[kim-aa]

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

Это и так и не так. Маркетинговые потуги и словословия безусловно есть "от диавола".

Однако существуют определенная группа технических инженерных решений, относящихся к точной механике или аналоговой электронике, которые в следствии дороговизны не применяются в массовых решениях.

Прелесть цифровых решений заключается в их дешевизне при массовом производстве.
С механикой или аналоговой электроникой это частенько не так.

[DJ Mogarych]

Спасибо, понятно.

Единственное:

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

Хорошо; то есть, если ошибок нет, то копировать можно и с восьмикратной скоростью, как настроен ЕАС у вас, или с 52-кратной -- с тем же успехом, просто такое скоростное копирование кушает больше ресурсов.
А привод снижает скорость и сам, если натыкается на нечитаемый сектор.

Всё равно мне не совсем понятно, каким образом формат коррекции может зависеть от пропускной способности. Вот обработка и коррекция поступающих данных -- это как раз понятно, потому что поток большой, больше и ресурсов нужно для обработки в единицу времени. А вот тип формата при чём, непонятно.
Если я зашифрую письмо с помощью S/MIME, или поток данных с помощью RC4, или архив zip, и пошлю их сначала по dial-up, а потом по экзабитному каналу, разве что-то исказится от изменения скорости?
Я вполне допускаю, что форматы контроля и избыточности меняются оттого, что более высокие скорости более требовательны к качеству физического уровня коммуникаций; они более чувствительны к наводкам и так далее. В общем, чем больше скорости, тем больше возни с прокладыванием проводов и обеспечения им комфортных условий залегания. Соответственно, потоки данных нуждаются в более жёстком контроле очерёдности и целостности. Мало ли что там по пути с ними может быть (хотя уж с dial-up в плане отсутствия контроля и потерь данных ничего не сравнится).
Но только из-за увеличения скорости?

С механикой или аналоговой электроникой это частенько не так. »

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

[kim-aa]

Хорошо; то есть, если ошибок нет, то копировать можно и с восьмикратной скоростью, как настроен ЕАС у вас, или с 52-кратной -- с тем же успехом, просто такое скоростное копирование кушает больше ресурсов. А привод снижает скорость и сам, если натыкается на нечитаемый сектор. »

Теоретически да.
Более того, на новых дисках так и есть практически всегда

А вот на старых..
Практически, все в этом мире имеет погрешность исполнения.
Простейший пример: головка драйва смещена влево от нормы, дорожка изготовленного диска - в право.
При низкой и постоянной скорости чтения - все нормально. При больших скоростях и стартопных режимах добавляется вибрация, да еще царапина попадет - и все - "нэ попадает".
Причем это часто даже не зависит от производителя.
У меня в практике реально были случаи когда фирменные CD не читались на одних драйвах, и прекрасно читались на других.

Если я зашифрую письмо с помощью S/MIME, или поток данных с помощью RC4, или архив zip, и пошлю их сначала по dial-up, а потом по экзабитному каналу, разве что-то исказится от изменения скорости? »

Все зависит от размера файла.
Видео по dial-up давно качали?

А если серьезно, то все решает продолжительность операции, или иначе говоря размер данных в одну транзакцию.

В Data-CD единицей операции является сектор. Я честно говоря не помню размер сектора, но возьмем ходовой в 512 байт.
Трек же в виде файла займет 5-10 МБайт.
Итого разница в 10 000 раз.

Как показывает жизненный опыт, при dial-up закачке скачать файлик в 512 байт можно практически по бельевой веревке, а вот 5 МБ да по плохому каналу это уже эгеге.

[DJ Mogarych]

это часто даже не зависит от производителя. У меня в практике реально были случаи когда фирменные CD не читались на одних драйвах, и прекрасно читались на других. »

Да, я слышал об этом. Подобные разговоры были лет этак десять назад, когда качество приводов было отвратительным, за маленьким исключением в виде Плексторов и Пионеров, которые потом и закрепились в мозгах компьютерщиков как "рулёз". Равно как и качество болванок. Тогда ещё денег не было, поэтому покупали болванки самые дешёвые, которые просвечивались насквозь.

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

Да, и, если вспомнить первоначальную тему — разве в этой ситуации EAC способен чем-то помочь?

Все зависит от размера файла. Видео по dial-up давно качали? А если серьезно, то все решает продолжительность операции, или иначе говоря размер данных в одну транзакцию. »

Модемом я пользовался до марта этого года, про видео не вспомню, но бывало, что скачивал мегабайт по сто. А при чём здесь размер файла? Размер кадра, если говорить о коммуникациях, у разных стандартов разный. Какая разница, сколько кадров будет передано — десять тысяч для маленького файлика или сто миллионов для большого? И как это соотносится со скоростью, при увеличении которой информация искажается?