Оценка lossless по анализу лога извлечения EAC

Для начала немного "лирики".
Сжатие данных без потерь (Lossless data compression) - метод сжатия данных: видео, аудио, графики, документов представленных в цифровом виде, при использовании которого закодированные данные могут быть восстановлены с точностью до бита. При этом оригинальные данные полностью восстанавливаются из сжатого состояния. Этот тип сжатия принципиально отличается от сжатия данных с потерями.

К чему это я?

Результатом появления lossless стала возможность при копировании аудио CD уменьшить в несколько раз (по сравнению с исходным размером диска) объём получающихся в результате данных, абсолютно при этом не ухудшив качества звука. Но самым главным преимуществом является возможность получить (при определённых условиях) точную копию исходного диска.
Конечно, многим эта "фишка" не нужна, но в среде аудиофилов принято делать именно так. И на подавляющем большинстве сетевых ресурсов копии аудио CD разрешается выкладывать только если они соответствуют условиям "точная копия". В противном случае материал может получить статус "сомнительно" (или подобный), и даже вообще удалён. Мало того - в "особо продвинутой" среде даже такие копии ещё делят на "подклассы":

Cкрытый текст -

 

Точный рип - рип сделанный с применением режима Test & Copy в любое представление (Image+CUE или Track+CUE) при однократном его риповании с совпадением результатов данного рипа (чем больше совпадений, тем лучше) с имеющимися в базе AccurateRip.

Максимально точный рип - рип сделанный без применения режима Test & Copy в любое представление (Image+CUE или Track+CUE) с обязательной проверкой рипом сделанным на этом-же приводе при неоднократном риповании, и при совпадении результатов всех сделанных рипов между собой и с результатами в базе AccurateRip, естественно, при наличие информации о данном аудио материале в ней.

Идеальный рип - рип сделанный без применения режима Test & Copy в любое представление (Image+Cue или Track+CUE) c обязательной проверкой рипом сделанным на другом приводе (на приводе с отличным от первого смещением чтения) при полном совпадении их результатов, или неоднократный рип на приводе с возможностью чтения в экстра областях CD-дисков (или приводом имеющим смещение чтения равное нулю - фантастика, но всё-же) и при полном совпадении результатов этих рипов. Для рипов Track+CUE дополнительно: с отсутствием в предзазоре первого трека какой либо информации отличной от "тишины" и с обязательной проверкой результатов определения программой идентичности распознаваемых зазоров для отдельно взятого диска, так-как, именно реализация этой операции в программе является её очень "тонким местом" и на некоторых дисках работает крайне нестабильно, раз за разом выдавая разные результаты.

Качество считываемого диапазона для всех видов рипа не менее 100%

Во всём мире де-факто стандартом для такого копирования "один в один" стала програма Exact Audio Copy (EAC), как наиболее корректно умеющая это делать. Но сделать точную копию диска она может только при определённых настройках . Вот для того-то, чтобы узнать, какими были настройки EAC во время извлечения файлов (снятия рипа) диска (а значит - соответствует ли имеющийся lossles материал понятию "точная копия"/"правильный рип"), и необходим анализ лог-файла, создаваемого ею в процессе копирования аудио CD. Стоит отметить, что на качество звука "правильность" или "неправильность" рипа влияния (за исключением извлечения в режимах "Быстрый" и "Скоростной") практически не оказывает. Речь идёт именно о копии диска "бит в бит".

Хочу сразу отметить, что нельзя путать лог EAC и лог (или инфо-отчёт) проверки качества собственно содержимого диска, создаваемый программой auCDtect (или другими её оболочками типа Audiochecker). Это абсолютно другая по цели и получаемому результату проверка. Логи Audiochecker и auCDtect выглядит вот так [spoiler]


в то время, как логи ЕАС:

для файла-образа


для потрекового рипа

Что по логу можно узнать?
Версию программы, которой производилось копирование, его дату, название диска и исполнителя. Если в этом поле отсутствуют имя/название, или вместо них проставлено "Unknown" - значит при снятии рипа автор не загрузил соответствующие данные из сетевой базы, или, если диска в базе нет - не потрудился вручную их ввести. Некритично, но можно идти смело смотреть CUE-файл этого альбома, в котором, очень вероятно, не будет ни названий треков, ни названия диска, ни исполнителя. А такие раздачи на нашем трекере запрещены. Хотя есть вероятность, что автор прописал их в CUE-файле вручную (молодец!), но проверить CUE стОит!

Далее.
Можно узнать модель привода, которой производился рип. И вот здесь сразу необходимо смотреть - выставлено ли смещение для него. Что это такое (если интересно) можно узнать здесь . Но нам важнее заглянуть по этой ссылке, узнать смещение для указанной модели привода и сравнить его с имеющимся в логе. Сразу хочу отметить - если смещение указано "0" - то это повод для больших сомнений, нулевое смещение в той таблице имеют всего пять-шесть моделей, причём не самых распространённых! Некоторые источники утверждают, что нулевого смещения не бывает в принципе. Если смещение в логе не соответствует табличному - рип "неправильный"!

Дальше идут настройки привода и ЕАС, которые обязательно должны быть следующими:

Режим чтения : Достоверность
Использование точного потока : Да
Отключение кэша аудио : Да
Использование указателей C2 : Нет
Способность читать области Lead-in и Lead-out : Нет
Заполнение пропущенных сэмплов тишиной : Да
Удаление блоков с тишиной в начале и конце : Нет
Read mode : Secure
Utilize accurate stream : Yes
Defeat audio cache : Yes
Make use of C2 pointers : No
Overread into Lead-In and Lead-Out : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks : No
Любое отклонение от этих значений - рип "неправильный"!

Далее.

Выходной формат : Внутренние WAV-операции - значит извлечение производилось в несжатый формат, перекодирование из wav делалось позже и в другой программе. Другой вариант - кодирование "на лету" в процессе снятия рипа. Не приветствуется, но и криминала нет. При этом записи в логе выглядят так:

Выходной формат : Пользовательский кодировщик
Выбранный битрейт : 128 kBit/s
Качество : Высокий
Добавление ID3-тэга : Нет
Утилита сжатия : C:Program FilesFLACflac.exe
Дополнительные параметры : -5 -V %s
Used output format : User Defined Encoder
Selected bitrate : 320 kBit/s
Quality : High
Add ID3 tag : No
Command line compressor : C:Program Files (x86)Exact Audio CopyFlacflac.exe
Additional command line options : -V -8 -T "Date=%year%" -T "Genre=%genre%" %source%

Отсюда следует - использовался кодек FLAC, на битрейт внимания в этом случае обращать нет смысла, т.к. кодирование производится с параметрами, указанными в строке "Дополнительные параметры" (в приведённых примерах - степень сжатия "5" и "8"). Для разных кодировщиков они имеют разный вид.

Идём дальше. Имя выходного файла. Тоже один из показателей, в какой формат производилось извлечение. Если выходной формат, указанный в этой строчке, не совпадает с указанным в полях "Выходной формат" (а если кодирование производилось "на лету" то и "Утилита сжатия") - может служить признаком подделки лога.
Одновременно даёт представление, в какой вид производилось извлечение треков - в файл-образ, или потрековый. И если рип был образом, а имеем потрековый - значит исходный файл был разрезан на треки. Обычно (если CUE-файл корректный) процедура безболезненная. Хуже, когда имеем файл-образ, а в логе - потрековый рип. Т.е. имеющийся образ был "склеен" из треков. И вот тут всё зависит от "прямоты" рук того, кто это делал. Опять же - критерием "неправильности" не является, но... на размышления наводит.

Очень важная часть отчёта:

Пиковый уровень 99.9 %
Качество диапазона 100.0 %
CRC теста 114C0D74
CRC копии 114C0D74
Копирование... OK

Ошибок не произошло
Peak level 100.0 %
Extraction speed 1.9 X
Range quality 99.9 %
Test CRC B0B9C106
Copy CRC B0B9C106
Copy OK

No errors occurred
Совпадение контрольных сумм CRC говоит о безошибочном чтении.

Несовпадение Test CRC и Copy CRC говорит о том, что в данном случае при первом чтении трека (Test) были получены одни данные, а при повторном (Copy) - другие. Хотя, если в случае несовпадения контрольных сумм, резюме ЕАС: "Копирование... OK", то это говорит о том, что фатальных ошибок не было, и ЕАС смогла их откорректировать, в чём, собственно, и заключается её главное достоинство. Однако считать такой трек безошибочным вряд ли уместно. Итак - несовпадение контрольных сумм Test CRC и Copy CRC однозначно говорит о "неправильности" рипа.

Нередко бывает лог без Test CRC. Тогда критерием оценки может быть "Качество диапазона". Если оно ниже 97%, то можно утверждать, что были ошибки чтения. Но браковочным показателем "Качество диапазона" при резюме "Копирование... OK" не является.

Верификация по AccurateRip. Может являться дополнительной характеристикой качества рипа (см. в "подклассах"), но при
этом несовпадение с сетевой базой данных криминалом не является. Может отсутствовать. Что такое AccurateRip?

Итог: несоответствие хотя бы одного параметра, являющегося критерием "правильного" рипа, рекомендуемым - имеющийся рип диска точной копией исходного не является!
В последней версии ЕАС в конце лога появилась контрольная сумма вида "==== Log checksum ...0D4E8E0C4 ====", позволяющая определить, не подвергался ли он "ручному" редактированию с целью подчистки определённых параметров. Подробнее об этой проверке здесь

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