Начнём рассмотрение данного вопроса с очень распространённого примера. Приводить целиком лог программы риппера нецелесообразно ввиду его малой информативности в той части которая нас интересует, поэтому, совместим лог ЕАС с информацией которую предоставляет CUETools с "притензией" на получение идеального отчёта о проделанной работе, которого так не хватает программам рипперам. Имеем два рипа одного и того-же диска сделанных на приводах с разным смещением чтения:
Комментарии излишни. Эти два рипа не могут считаться одинаковыми по причине различия в подсчёте сумм CRC для последнего трека, и как минимум один из них не может считаться сколь-нибудь точным из-за потери информации в последнем треке, которая обусловлена большим смещением чтения привода с которого происходило рипование, и невозможностью этого привода считывать информацию из экстра зон CD дисков. Идентичность рипов по базе AccurateRip обусловлена её несовершенством, причём уже на момент создания. Никто не мешал автору уже тогда иметь в виду реальное положение дел в "приводостроении". Согласен с тем, что нельзя было принимать за точку отсчёта приводы умеющие работать с экстра зонами CD дисков, но не учитывать при подсчёте первые для первого трека и последние для последнего трека 5-ть фреймов - непозволительная роскошь. Надо было выбирать наименьшее существующее значение смещения чтения за точку отсчёта, на тот момент уже существовали приводы смещение чтения которых составляло всего 6-ть сэмплов, ну, или на "худой конец", "отчикивать" при подсчёте не более 1-го фрейма, это и так составляет аж - 588 сэмплов, благо таких приводов уже тогда было "пруд пруди", смещение чтения которых попадает в этот диапазон. Кстати, так для справки, создатель CUEToolsDB в этом вопросе пошёл ещё дальше и при подсчёте эта база "отчикивает" уже по 10-ть фреймов, да и полноценной базой-то её назвать нельзя, так как туда заносятся данные о проверке рипов, и при их присутствии в AccurateRip с количеством совпадений больших 2-ум, информация о них попадает в неё, т.е., своего рода фильтр с очень большой допустимой возможностью его прохождения, и не больше. С точки зрения качественной составляющей обе базы содержат информацию на не менее чем в 90%-х случаев являющуюся хламом, хоть в прямом хоть в переносном значении этого слова. Ещё не менее большим упущением автора AccurateRip являлось то, что изначально база предусматривалась под его коммерческий проект dBpoweramp Music Converter который не имел такого количества возможных вариантов настроек, которые в свою очередь могли бы влиять на качество снятия рипа как у EAC. В базе, никаким образом не осуществлена проверка приходящих в неё данных о настройках программы риппера, а самое главное о том, что никаким образом не учитывается в ней с каким смещением чтения производилось рипование, а зачем?, ведь она "откусывает" столько что этого хватит чтоб в неё попадали результаты рипов сделанные на приводах со смещением чтения по модулю равным 2940-ок сэмплов. Зато, дав возможность EAC отсылать информацию о рипах сделанных им - база начала наполняться в несколько раз быстрее в пику качеству находящейся в ней информации, так как, до сих пор рипы делаются чёрти с какими настройками этого риппера. Конечно, одиночная информация о рипах из базы наверное удаляется, хотя я могу констатировать совершенно противоположный факт: при подготовке одного из материалов по определению Upconvert-ов из кодеков сжимающих с потерями, а именно из MP3, мною был создан диск, т.е. такой диск в природе один. Диск я рипанул в ЕАС и случайно отправил информацию о его содержимом в базу. Рип сохранил и диск тоже. Диск начал работать в виде аттракциона на разных установках системы, показывая что информация о таком "фаршмаке" находит своё отражение в базе. На одной из установок системы, отличной от первой установки с которой посылалась информация в базу, опять забыл очистить пакет для отправки в неё и информация о этом рипе благополучно ушла ещё раз. Всё это было не менее трёх лет назад на момент написания этого материала 23.10.2010. Сейчас, 23.10. 2010, при проверке рипа и диска совпадения по базе для каждого из треков аудио материала составляют ХХ [ХХХХХХХХ] (2/2) Accurately ripped. Без комментариев.
AccurateRip + CUETools - инструмент для превращения хорошего рипа в "фаршмак"
Совершенно реальная ситуация которой изобилуют трекеры и выкладываемые через файлообменные ресурсы рипы. Рассмотрим самый щадящий из вариантов:
1. Допустим, что о том аудио материале, который пользователь превращает в рип, нет информации в базе AccurateRip, совершенно новый, недавно выпущенный диск. Рип сделан с ошибкой, одной единственной, как в случае описанном в главе "Возвращение приводом информации об ошибках C2", но выявлена она не была. Информация о совпадении этого рипа в логе EAC отсутствует. Но первоисточник отослал результаты рипования в базу. Прошло время, около месяца или чуть больше, где-то, около этого, неважно, факт тот что она туда попала. 2. Рип был выставлен на трекер, популярный трекер, для публичного скачивания. Кто-то его, естественно, скачал. После скачивания рип был проверен CUETools по базе AccurateRip и имел уже по ней совпадения в количестве одного. Рип был скачан не только для того что бы послушать, но и для того что бы переложить его на другой трекер. Но такой безликий лог, ещё и при том, что на трекере, куда предполагается выложить его, в правилах поощряются совпадения рипов по базе. Рип записывается на болванку CD-RW, а зачем портить не перезаписываемую, рипуется и информация о нём уходит опять в базу. Через некоторое время информация и о этом рипе находит своё отражение в ней. При этом совпадения по базе будут равны уже двум. При риповании EAC-ом в режиме Test & Copy и при совпадении сумм CRC теста и копии в базу добавляется с каждого рипа два совпадения. То по каким причинам ещё рип был записан и рипанут, после чего информация уходила в базу, можно напридумывать самим.
3. Рип с такого-же оригинального диска был сделан ещё одним пользователем в то-же приблизительно время, но был выложен для публичного скачивания на мало известный ресурс. Рип был сделан без ошибок. Информации в логе EAC о его присутствии в базе AccurateRip нет.
4. Теперь, о ещё одном пользователе, который скачивает и проверяет правильный рип, а CUETools руководствуясь информацией из базы AccurateRip сообщает ему о том, что на одном из треков имеются расхождения в экземпляре рипа находящемся у него и теми о которых есть информация в базе, допустим к моменту проверки этого рипа совпадения составляют уже с десяток. Раз так, то и информация в её родной базе CTDb о рипе присутствует.
5. Пользователь полностью уверен в том что скачал некачественный рип исправляет его в программе CUETools с применением функции "repair", которая воспользовавшись информацией из базы CUEToolsDB делает это безошибочно, приводя правильный рип к виду неправильного. По сообщениям на некоторых форумах такого характера, привожу без купюр: - "18 исправленных рипов для меня очень многообещающий показатель. Причём было исправлено несколько рипов, выполненных мной в "антисанитарных" условиях: без подключения к интернету, полу сдохший привод и очень сильно поцарапанные диски. Логи извлечения пестрели ошибками. Также, естественно, были расхождения с базой AR. Все рипы исправлены в CT". Эта связка может испортить что угодно.
|
