EAC или Alcohol 120%
 

При извлечении файлов из audioCD и дальнейшей записи на диск, как правило рекомендуют программу - Exact Audio Copy сипользованием lossless-форматов. Но ведь Alcohol 120% создает точную копию диска. Всвязи с этим вопрос:
1. Как все же правильно это делать?
2. Как это влияет на качесво копируемого диска?

Проблема в том, что словосочетание "точная копия диска" допустимо только для CD c данными.
Для CDDA это не так.

EAC обычно используется для преобразования треков на CD-Audio в более удобоваримые и переносимые форматы, такие как wav, mp3, flac, ape и т. п.
Если этого не требуется, а нужно просто скопировать диск, то можно пользоваться любой программой для копирования, в том числе и "Алкоголем".
Я так всегда думал.
Почему? Ведь копировщики дисков делают побитовую копию без преобразования информации. Грубо говоря, прожигаются дырки в дорожках диска в точности как в оригинале. Чтение с оригинала идёт "сырое" (RAW), безо всякой коррекции. Разве нет?

Значит Alcohol 120% с задачей не справится? Нужно использовать только EAC?

SixthPriest, Alcohol - справиться.

CDDA формат использует все 800 МБ raw емкости CD под аудиоданные. Избыточность не используется.
Физической синхродорожки как в DVD+R - нет.
Как средство компенсации ошибок используется только перемежение секторов.
Т. е. в случае серьезных ошибок востанавливать просто не с чего.
Сам формат разработан в 1980 г.

Основной проблемой является потеря синхронизации на максимальных радиусах от центра (Jitter / Джиттер).


Data форматы используют 700 МБ под данные. 100 МБ используются под информацию для востановления.
Сам формат разработан в 1990 г.
==============================================================================
Большое значение имеет используемый MP3 кодер. EAC хорошо работает с Lame.

2) Если диск новый и необходимо снять WAV, то можно практически чем угодно.

3) Лично я пользую только EAC уже лет 7.

4) В последних версиях EAC Norton Antivirus находит какое-то AdWare, что не страшно, но не приятно.

Избыточность используется (ссылка). Это код Рида-Соломона (CIRC). Добавляется байт чётности каждые три байта (ссылка).

Что касается джиттера — он автоматически корректируется всеми программами и аппаратами, работающими с аудио. Джиттер воспринимается на слух как неприятные "цыканья" и заедания во время воспроизведения (ссылка).

Джиттер в моей практике возникал лишь тогда, когда диск был повреждён, то есть, когда ошибка настолько велика, что не поддаётся коррекции (и EAC в таких случаях тоже бессилен). Если диск нормальный, то всё было в порядке не только в хвалёном EAC, но и в CDex, и в Аудиограббере.

В формате чтения RAW, в котором работают все программы копирования дисков, диск копируется побитово. Проблем тут я не вижу. "Алкоголю" всё равно что копировать, он просто "срисовывает" нули и единички.

В общем,
1. Как вам больше нравится, разницы никакой. Просто скопировать диск "Алкоголем" — быстрее.
2. Не влияет никак.

Никого не хочу переубеждать. Может быть, я неправ.

DJ Mogarych, kim-aa, спасибо за информацию.

...EFM, CIRC, L2 ECC, and so on, is added, but these are not typically exposed to the application reading the disc.
Т.е. , попросту говоря, каждая "читалка" имеет право читать AudioCD по-своему. И при воспроизведении AudioCD именно так и происходит. Поэтому, IMHO, AudioCD не подходит для хранения, и желательно скопировать его как можно раньше.

Я несколько раз пробовал делать образ одного и того же AudioCD с помощью Alcohol - и образы не были идентичными, если были сделаны на разных приводах или даже на одном и том же приводе но с разными скростями.

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

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

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

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)

Это, кстати, к достоверности информации отношения не имеет. Считал два раза неверную информацию, сравнил, получил один и тот же результат (неверный) -- посчитал, что всё правильно. Поехал дальше.
Другое дело, если бы читалась информация и оригинальная контрольная сумма, потом вычислялась контрольная сумма считанной информации и сравнивалась бы с оригинальной. Как в цифровой подписи.
Надо бы ознакомиться с авторским описанием EAC.
У меня вопрос. Если функции коррекции аппаратные, то есть зашиты в привод, то привод использует их автоматически сам, и ему всё равно, какой софт сейчас к нему обращается. Софт получает уже готовые результаты. Как же софт может влиять на аппаратные функции? Какая разница, EAC тянет данные с привода, который использует свои аппаратные возможности, или какая-либо другая программа?
Тоже не понял. Коррекция ошибок вроде бы всегда была цифровой. Как механикой можно ошибки исправлять? И к чему мы тогда говорим о мощи EAC, если "правильная" коррекция ошибок -- механическая?
Странно. ASPI -- это интерфейс Windows 9x, то есть, интерфейс десятилетней давности для отживших своё операционных систем. Почему же он работает лучше, чем современный SPTI?

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

С какого перепугу 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.


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

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

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

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

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

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

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

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

Источник.

Диски, на которых записаны, например, файлы mp3 или файлы Excel, разве свободен от этого недостатка? Почему там речь не идёт о первой скорости вращения, а неполноценные дешёвые приводы с копеечной механикой Data-CD читают без проблем?
"Жёлтая книга", то есть, формат 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 неактуальны уже давным-давно, следовательно, проблемы достоверного копирования дисков не существует. Любой самый дешёвый привод так же точно копирует и считывает, а также обладает всеми возможными в этом старом стандарте механизмами коррекции ошибок, как и такой же дешёвый привод во чреве хай-энд проигрывателей, освящённый кадилом рекламщиков.
Хай-энд, по моему скромному мнению, тема больше религиозная, живой пример переоценки человеком своих возможностей восприятия и дань тщеславию.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нет, в данном случае не может.

-------------------------
Проблема не в файловой структуре. Файловым операциям, как раз таки все равно.
Я имел в виду размер транзакции при чтении минимальной дискреты (порции) данных.
Для Data CD это сектор.
Для CDDA это трек.
Вероятность возникновения ошибки при чтении, при грубом подсчете как минимум в 10000 раз.

Для секторной ситемы значение каждого сектора абсолютно не зависит от остальных секторов.
Более того, сбой чтения одного сектора, может быть компенсирован на уровне файловой системы, или даже на уровне файла (скажем RAR).

В CDDA трек это поток данных. Данные зависят друг от друга. Более того сбой чтения нескольких "секторов" подряд (в кавычках, т.к. это низкоуровневые сектора CDDA, а не сектора файловой системы) ведет к сбою синхронизации.

====================================================================================
Теперь касаемо

Информация не искажается, просто при заданной вероятности возникновения ошибок на переданный объем данных, рост битовой скорости передачи, автоматически ведет к увеличению числа ошибок в единицу времени (частота возникновения).

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

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

Однако с ростом числа транзисторов на кристалле, и увеличением частоты, выяснилось что данная тема уже актуальна:
- для авиации и горной местности;
- длительных вычислительных транзаций (недели, месяцы)