Без всякого абсолютизма с претензией на "последнюю инстанцию", здесь, просто, изложено мнение и наблюдения человека который очень давно занимается рипованием, и не больше. В роли основных приводов в тестах будут выступать HL-DT-STDVDRAM GH22NS50 и Plextor PX-880SA. Почему именно они: - как минимум, потому что, среди имеющихся в распоряжении автора на момент написания данного материала, именно эти приводы показывали наилучшие результаты при считывании информации с дисков, и для Plextor PX-880SA, единственного, в программе тестирования можно выставить предел скорости чтения меньший 10Х, то есть, ни для одного другого привода (из имеющихся в наличие у автора) их производителями даже не рассматривается целесообразность чтения на скоростях меньших упомянутой. На этом статью можно было-бы и закончить, зная на каких скоростях происходит рипование дисков в режиме "Secure (Достоверный)", при любых установках в опции "Выбор скорости (Speed Selection)", самого "наилучшего" риппера - EAC, у которого при риповании скорость считывания редко даже доходит до 10Х, и 3/4-ти процесса, в лучшем случае, происходит на скоростях около 8Х. Это можно бы было сделать если-бы статья называлась, например так: "Влияние скорости считывания на его качество" ................ На этом, действительно, можно было бы и закончить, так как, несолидно "тянуть кота за хвост" когда при написании текстом всё что можно сказать по теме укладывается в пару предложений. Но, в то-же время, было-бы, даже в этом случае, не правильным не написать эту пару предложений, и не подкрепить их несколькими примерами в виде скриншотов. Рассматривать качество считывания дисков на скоростях с возможностью ограничения верхнего их предела будем программой Nero CD DVD Speed version 4.7.7.16. Никакое тестирование не может происходить без учёта того, каким образом полученные результаты могут повлиять на отношение тестирующего на конечный, в нашем случае этот конечный результат - качественный рип, и без рассмотрения этого вопроса в отрыве от Exact Audio Copy, из-за значимости программы в получении рипов Audio-CD. Для некоторых примеров, что-бы увеличить "полноту ощущений", расширим задачу, и сравним разницу в ходе процесса рипования и его результатах, между Exact Audio Copy 0.99pb5 и 1.0 beta1 - на момент проведения тестов предпоследней и последней версиями программы. Для того чтобы исключить всякого рода случайности каждая из версий программы устанавливалась на чистую от стороннего программного обеспечения систему Microsoft Windows XP SP3 (исключение составила программа с помощью которой мы имеем возможность наблюдать приведённые ниже скриншоты - FastStone Capture version 5.5), в свою очередь установленную на одно и тоже "железо" в обоих случаях применения той или иной версии EAC. При тестировании в системе установленной была только одна из версий программы. Рипование для каждой версии программы повторялось четыре раза с предварительной перезагрузкой системы и интервалом между рипами не менее часа для каждого последующего. Разница в результатах хода рипования укладывалась: для времени рипования от 12 до 25 секунд, и для максимальной скорости рипования по его завершении 0.1Х - 0.3Х при полной идентичности в его ходе для отдельно взятой версии программы. Обе версии EAC были настроены:
"Read offset correction" : - в зависимости от конкретной модели привода.
В первую очередь, рассмотрим самый распространённый случай, который будет встречаться пользователю в тестах при принудительном занижении скорости считывания даже на приводах имеющих "по паспорту" возможность качественного чтения на таких низких скоростях доставшуюся им в наследство от предидущих моделей.
Как мы видим, при считывании с ограничением верхнего предела скорости, который равен 8Х, постоянно происходит ошибка, которой на дисках не существует, что показывают нам дополнительные скриншоты графиков чтения с ограничением в 16Х и сам вид ошибки на графиках с ограничением в 8Х, так как связка привод-программа не могут работать совместно в таком "изуверском" для привода режиме принуждения. Программа классифицирует данный сбой как ошибку С2. Эта ошибка будет появлятся при считывании на всех приводах в устройстве которых не заложена возможность нормального проведения процесса на таких низких скоростях, то есть, на современных приводах, технологии и внутреннее устройство которых ушли далеко вперёд по отношению к программам, которые считают такие заниженные скорости оптимальными для качественного считывания. То-же самое делает и Exact Audio Copy, не давая приводу при чтении привысить определённый порог которого мы не знаем. В случае с программой тестирования мы имеем возможность увидить то что может происходить в момент считывания, а вот в случае с EAC можно только догадываться, что происходит внутри зтого процесса при качественной болванке и логике привода старающейся повысить скорость чтения последующего участка с данными при нормально считанном предидущем. Как мы видим из графиков тестов, приводу это удаётся, но только до определённого значения, в данном конкретном случае для программы тестирования это значение равно удвоенной установленной предельной скорости заданной программой. То, что происходит дальше хорошо видно на приведённых скриншотах. Зная на каких скоростях рипует EAC, и не зная то как реализован механизм "сдерживания" скорости считывания в данной программе, нельзя быть уверенным в том, что те рипы которые выходят из под него "правильные" не только в его логе. Естественно, из всего выше изложенного могут быть исключения, и они есть, но как это и бывает, исключения только подтверждают определённые правила. В рассмотрении такого рода исключений нам поможет CDP 7 46042 2 EMI Records 1981 Duran Duran - Duran Duran, тест которого и рассмотрим дальше. Рассматривать будем на сравнении хода считывания этого диска на двух приводах: Plextor PX-880SA (интерфейс SATA, дата выпуска девайса июль 2010), HL-DT-STDVDRAM GH22NS50 (интерфейс SATA, дата выпуска девайса март 2010):
Plextor PX-880SA
HL-DT-STDVDRAM GH22NS50
Завершить работу ПК по окончании операции - Exact Audio Copy 0.99pb5; Перевести ПК в спящий режим по окончании операции - Exact Audio Copy 1.0 beta1
Следуя тому как назван этот обзор - всё представлено на картинках, единственное, никак не укладывается в понимание и не поддаётся никакому обоснованию - работа EAC при риповании, видя поведение приводов при считывании данного диска которое показывает программа тестирования. Так-же, нельзя не отметить, полное неумение программы обеих версий работать с приводом HL-DT-STDVDRAM GH22NS50, так как, эта ситуация со скоростью рипования характерна для любых рипов с любых дисков данной программой на этом приводе. Как, чётко видно из приведённых скриншотов, обе версии EAC имеют только "одинаковый интерфейс", а, как минимум, управление скоростью привода - разные, что хорошо видно при рассмотрении хода рипования этого диска приводом Plextor PX-880SA. Конечно, дико даже предполагать, но на этом приводе и на определённых дисках (выпущенных в конце 80-х и начале 90-х прошлого века) версию EAC 0,99pb5 как будто "переклинивает" и она по своей воле перескакивает с одного режима снятия рипа на другой, так как такие скорости рипования характерны для этой программы в режиме "Burst". Что ещё разное у этих двух версий EAC рассмотрим на следующем примере, можно без сомнения назвать его - "классика жанра". И, так, диск 22072 4607147893456 Depeche Mode - "Sound Of The Universe, выпущенный 2009 Venusnote Ltd. under exclusive licence to Mute Records. На скриншотах приведённых ниже, относящихся к данному диску и приводу на котором происходит его считывание, отчётлливо видно, что на данном приводе (Plextor PX-880SA) этот диск считывается безукоризненно только на скоростях близких к максимально заявленным производителем данного устройства для этого типа носителей информации.
Как видно из скриншотов теста, уверенное считывание участка, который становится проблемным, происходит при прохождении его на скорости привода при считывании в районе 32Х. Все рипы обеими версиями программы делались в представление Image+CUE. Теперь, после всего сказанного, можно перейти к рассмотрению скриншотов хода рипования обеими версиями Exact Audio Copy 0.99pb5 и 1.0beta1.
Результаты в логах программы совершенно одинаковые, если не считать одного "но", которое заключается в разности качества извлекаемого диапазона: не трудно догадаться что для версии EAC 0.99pb5 оно равно 100%, а вот для версии EAC 1.0 beta1 оно равно 99.9%. Самое интересное нас ждёт дальше: при записи рипа сделанного EAC версией 1.0 beta1 на болванку и последующего рипа записанной болванки качество диапазона остаётся тем-же, при ходе рипования без каких либо "шероховатостей". Проблема давным давно известна, даже имеет своё название - "Проблема конца трека". Можно констатировать факт, что это действительно она, так как полностью подтверждается данными из TOC тестируемого диска: конец девятого трека приходится на временную отметку 37:53.01. По утверждению более компетентных людей в данном вопросе, и не только в нём, но и во всём что касается работы этой программы, нежели чем Ваш покорный слуга, она, чаще всего встречается на по-трековых рипах: - simple.i :-"При по-трековых рипах большинство дисков подобные фокусы показывают, причина, я думаю, общая. Может когда-нибудь устранят. .... "Проблема конца трека" существует давно, а Андрэ только сейчас собрался её "посмотреть". Глядишь, к версии 2.0b1 устранит. ..... Этот глюк характерен только для ЕАС. Другие программы-риперы, ошибок при по-трековом снятии на этих же дисках в данных местах не наблюдают". То, как решается эта проблема "на лицо", там где её не было на предидущей версии, она появилась в новой, причём, на более безпроблемном виде рипования нежели чем Tracks+CUE. Но это, если посмотреть на проблему только с одной стороны. В моём понимании, результаты тестирования очень не однозначны, как это может показаться на первый взгляд, так как не понятно, что лучше: когда программа сигнализирует о проблемном месте при считывании информации с диска, или когда этого не происходит, ведь диск и привод одни и те-же, и независимая программа тестирования безошибочно сигнализирует о присутствии проблемного участка на диске при считывании его на пониженных скоростях которые применяет EAC. Может быть другие рипперы потому и не наблюдают данную проблему так как изначально находятся на более низкой стадии своего развития, и просто напросто, не совершенны в отличие от EAC, а мы наблюдаем эволюцию этой программы в лучшую сторону? Ответ на данный вопрос даст "время".
Конечно-же, приведённый выше пример с такими извращенческими последствиями нужно относить к исключениям, и не иначе, но только "отловив" такого рода исключения можно увидеть некоторые закономерности.
|
