Close Topic Options

В том-то и дело, что "ЕАС дает добро" , т.е. завершает рип, а потом этот вав беззастенчиво врет и квакает. Вот и все. Я подозреваю, что sastre этот трек после ЕАС не слушал.

sastre Я еще вчера об этом думал и сделал все в точности, как описал LF_. Но для собственного успокоения я готов использовать твой config.
Пришли его или запость здесь, а я сделаю с ним. И если дело было в этом - конечно же, об этом сообщу. Полагаю, ни у кого сомнений в этом нет?

Неужели неинтересно самому убедиться? А вдруг все не так просто?
Или из принципа?

Нет, я просто не вижу, что мне это даст, если исходить из того, что критерием правильности рипа я считаю полную его повторяемость. Т.е. побитное (именно побитное) совпадение разных рипов. Я это принимаю за аксиому и за отправную точку.

Слушать же или смотреть на неправильные рипы - ну можно... Но что это даёт?

Это дает иной угол зрения на всесильность ЕАС, на царапины, которые можно ликвидировать все до одной, если грабить не 15 часов, а, скажем, 30...
"Пилите, Шура, пилите..." (с)

В том-то и дело, что "ЕАС дает добро" , т.е. завершает рип, а потом этот вав беззастенчиво врет и квакает. Вот и все. Я подозреваю, что sastre этот трек после ЕАС не слушал.

Даже если EAC и "дал добро", в то время, когда в рипе безобразие нарушено, это рип не будет повторяемым. Другой рип этого же диска этим же самым EAC'ом скорее всего даст побитно не совпадающий с первым результат. Ведь тут есть ещё и такой, к примеру, фактор - может глючить железо. Т.е., допустим, просто допустим, EAC считал одно с диска, причём правильно считал, а при записи в WAV из-за глюка с памятью, жестким диском или ещё чёрт знает с чем, туда попало что-то иное - можно ли винить за это EAC? Вот поэтому я ещё раз напомню о том, что я считаю критерием правильности рипа его повторяемость.

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

Sergey Overkill
И более того, кто заставляет тебя смотреть или слушать? Проверь, как считаешь нужным, разве речь об этом? Сам факт - жидкость > преломление > отражение > и все... ничего не надо царапать или маркером уродовать. И при этом ты получишь лог, что все ОК.

Sergey Overkill Подожди, не пиши ничего. Я понял, что ты не понял.
Снова. Берется диск, с которого делается рип определенного трека тремя прогами. Все треки совпадают, ну это и мулу понятно. Далее этот же трек мажется жидкостью, я когда-то делал с капелькой масла, но трудно оттирать, а сопли/слюни запросто. Повторяем рип. Наврут ВСЕ. При этом xарактер ошибок не будет одинаковым по одной простой причине - жидкость микроскопически растекается, высыхает, меняет форму и т.д., а стало быть, отражение - это не маркер и не царапина. Т.е. все наврут по разному, но наврут 100%. Более того поведение разных прог при этом вранье разное и интересное, но это не столь важно. А о чем речь? EAС не дал идентичного результата, хотя и сообщает, что все нормально. Ну как еще доказать??!! Подожду config от sastre, посмотрим, может быть что-то я неправильно поставил в настройках, хотя не думаю. Но в любом случае, даже из принципа воспользуюсь 100% config'ом, для самого себя.

Я уеду и вернусь через часа полтора.

This post has been edited by retro on 19-05-2004, 16:50

retro
Значит ты ведёшь к тому, что даже если EAC прочитал неправильно (т.е. результат грабленья из-за порчи диска не совпадёт с предыдущими побитно совпадающими друг с другом рипами), он никогда ничего об этом не напишет? В подавляющем большинстве случаев он всё же такие ситуации отлавливает и пишет об этом. Это просто опыт использования этой программы в течение... В общем, с того времени, как вышла его версия 0.85.

Ведь надо понимать, что EAC никаких волшебных методов чтения не использует. Он лишь читает каждый кусок точно так же, как это делают и все остальные грабберы, но только он этот кусок читает дважды и при полном побитном совпадении этих двух попыток он считает, что данные считались правильно и записывает их в WAV. Если привод выдал два раза подряд одинаковые результаты, но эти результаты были неверными (такое маловероятно, но тем не менее случается), то EAC не может никаким образом определить, что была ошибка и запишет считанное в WAV. И ничего разумеется не напишет в логе. То же самое сделает и любой другой граббер. Зато если эти две попытки дали разные результаты, EAC попытается считать этот кусок многократно и те аудиоданные, которые считались одинаково в более чем 50% попыток, он и запишет в WAV. Если же такой повторяемости не было, то он отпишет в логе об ошибке чтения и что-то всё же в WAV поместит (вот что именно я не знаю, и знать не желаю, ибо никогда не сохраняю и не слушаю такие рипы). Никакой другой граббер ничего из этого вообще не сделает. Так что хотя EAC и не панацея, он КАК МИНИМУМ НЕ ХУЖЕ любого другого граббера. Разумеется речь идёт об EAC'е, настроенном на работу в secure mode. При работе же в burst mode ОН ВО ВСЁМ ЭКВИВАЛЕНЕН, а значит опять не хуже всех остальных грабберов в части извлечения аудиоданных.

Ну а если в результате грабленья EAC'ом получается чёрт знает что, а он никогда не сообщает об ошибках, то... Не знаю. Я такого не встречал. Просто-напросто не встречал. Были лишь единичные случаи (ну с десяток, за всё время), когда EAC ничего не сообщил, но рип тем не менее оказался слегка (пара-тройка сэмплов) отличающимся от последующих контрольных (и 100% повторяющихся) рипов. Вот именно этими контрольными рипами такие случаи и отлавливаются... А постоянные безобразия без сообщений об ошибках... Не видел такого.

P.S. Ну вот, опять ввязался в обсуждение, мне совершенно не нужное. Всё же я завязываю...

P.P.S. Сказанное насчёт EAC'а о том, что он почти всегда сообщает об ошибках, справедливо лишь в случае использования secure mode разумеется. И плюс к тому выключения использования сообщений привода об ошибках C2 для обнаружения проблемных участков (попросту при всех убранных галочках в настройках, связанных с C2). Ну и плюс к тому, при включении сброса кэша привода, если привод кэширует аудиоданные. Но так как достоверно выяснить, кэширует ли привод аудиоданные, не всегда просто, можно для всех приводов включать сброс кэша. Галочка "Drive caches audio data".

Я пользовался мануалом на настройку ЕАСа Sergey Overkillа
Единственное подбирал сам "детекшн метод" и ставил АСПИ...... Всё.

Я обычно корифеям Нетлаба доверяю, но, видя упорство retro, решил повторить эксперимент sastre(смачивание диска IMHO неудачное предложение, т.к. проконтролировать схожесть условий эксперимента трудно, а собирать статистику долго), изменив лишь процедуру обработки результатов.
Поцарапав диск, я рассудил, что нанесенная от руки царапина портит часть битов безвозвратно, но создает не меньше мест, где биты прочесть теоретически можно. Следовательно, две программы должны дать одинаковые ошибки в испорченных местах, но общее количество ошибок будет меньше у той, которая лучше читает участки поврежденные, но подлежащие восстановлению.
Поэтому, сграбив музыку с помощью EAC и Cool, я сравнил ее с оригиналом (оригиналы до царапания у обеих программ совпали) и посчитал, сколько битов разнится. Предварительные результаты (EAC все еще бежит) по первым пяти мега вот:

File 1 (Cool): 4144 bytes (8498 bits) in 5242880 bytes differ from original
File 2 (EAC): 1570 bytes (3088 bits) in 5242880 bytes differ from original


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


This post has been edited by mau on 19-05-2004, 19:03

Дорогой retro, я делаю последнюю попытку объяснить:

1) В начале беседы ты сказал - покажите мне рип кула и рипа як где у кула проблемы, а у як их нет - что и было проделано sastre - имеем график с дырами после кула, графки без дыр после як, вав заикания после кула, вам без оного с як - вывод, которые можно тут сделать только один - як может прочесть это место, а кул не может. Насколько правильно оно прочитывается зависит от повреждения, поэтому переходим к 2

2) Были места, которые ни як ни кул прочесть не смогли - придумать правильные данные ни одна прога не может, поэтому вывод тут такой - sastre переусердстовал и поцарапал диск до невозможности, те места, которые можно прочесть если очень постараться - як прочел, кул нет см пункт 1

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

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

4) Человек, который хочет что-то нам доказать должен привести доказательства, кои он так настоячиво требовал и при появолении коих начинаются рассказы о Адоба крутая фирма или я педант и поэтому - не смешите мои тапочки.

5) Хочешь сделать тест - давай, предлагаю следующее
Берешь где угодно вав файлы, без глюков, режешь их по 30 секунд - получаешь треки по 30 секунд. 2-3 трека думаю хватит. Объявляешь эти вавы как эталон и делаешь CRC вав файлов, график в куле. Записываешь эти треки на ЦДР- получаем эталонный диск для тестирования. С этого диска делаем рип як, кулом - два раза каждым, желательно на разных привадах, но это не важно - рипы сравниваем с оригинальными вавами и друг с другом, делаем CRC и в куле картиники. Если в этот момент CRC як и CRC оригинальных файлов совпадет, а кул выдаст разный - дальше ничего не делаем, говорим кул ацтой. Если на данном этапе все CRC одинаковые - слегка портим диск - не протыкаем гвоздем и радостно сообщаем, что не читает, а аккуратно портим - как скажем говорил Оверкил. Далеем 2 рипа як, 2 рипа кула - сравниваем CRC, графики и тп
Настройки кула - сам выбирай, а як - настрой как было указано у мазахистов.

После этого мы можем продолжить разговор...

Чёрт, пора mau забанить - пока я тут писал, он уже все проделал - может и не так наглядно, но зато понятно

A в Куле есть принудительное позиционирование (это как же оно работает-то, где маркеры на диске, а? Может надо читать линки, которые дают?), фокусировка лазера и ваще ты хоть примерно представляешь, как работает DAC? Расскажи нам своими словами, как работает процес чтения диска, а ? Может можешь рассказать, какие два типа царапин бывают и почему один тип достаточно просто DAC хавает, а второй нет?

Ты на самом деле не понимаешь, почему як читает лучше? Надо рассказать?

Рассказываю

На одном берегу реки в туманную погоду стоит парень с биноклем, а на другой стороне книга. Задача - прочесть книгу. Парень с биноклем - это прога с устройством чтения, которое для простоты изложения мы не будем разбирать на части), а книга - наш диск. Туман на реке - дефекты физической поврехности, устройства чтения и прочие баги прошивок. Первый парень у нас кул - он берет биноколь и быстро записывает - т.к. туман и еще и книга не простая, а принятая по факсу - видно хреново, кул торопится и на выходе получает фразу

Д. ...шит. м.. ..почкр

где точки - места которые не удалось прочесть. Прочтение данной фразы дело не простое или говоря проще - мы имеем дырки и неправильные байты

Приходит як - смотрит - нихрена не видно, но туман он такой - то ветер подует, то молния ударит - будем пробовать. И начинает читать - каждую букву по 84 раза. Некоторые из них удается прочесть всегда - факс этой буквы был удачен, а некоторые - как первая буква - 50 раз удалось прочитать это место как Н, 20 - как Д, 10 как Х и еще 4 раза Р - вероятно, что первая буква таки Н, а не Д - так и записываем. В результате упорного труда, мы получаем фразу

Не смешитю мои тапочки

Как и следовало ожидать кривой факс + туман сыграли своё дело - мы считали не совсем то, что было в оригинале, но куда более понятно. Насколько близко нам удалось прочесть - зависит от плотности тумана, оптики бинколя и прочих факторов - единственное, что мы можем сказать - мы сделали все возможное, чтобы получить эту фразу как можно точнее

Народ, мне это напоминает спор глухого со слепым...