CTDB Logo

Давайте разберем что из себя представляет отчёт CUETools.
Обычно он имеет расширение файла *.accurip например “Grace Jones – Hurricane.accurip”, представляет из себя по сути обычный текстовой файл и может быть открыт в любом текстовом редакторе.

Для удобства я разбил его на 4 раздела и по сути отчёт теперь является Оглавлением.
Для того чтобы перейти к описанию нужного раздела кликнете по его заголовку.

##### Отчёт CUETools && Оглавление #####

1. CT Version, Data, Pregap

[CUETools log; Date: 11.08.2010 5:18:50 PM; Version: 2.0.9]
Pregap length 00:00:33.
CD-Extra data track length 09:16:26.

2. Раздел с отчётом по родной базе CTDB

[CTDB TOCID: vmNXKv93y95g9dAHwZLPIDqZBQc-] found.

[ CTDBID ]  Status  
[d20e5e00] (72/72) Accurately ripped

3. Раздел с отчётами по базе AccurateRip

[AccurateRip ID: 00048478-00153a01-30053e05] found.

Track [ CRC ] Status
01 [1f413828] (58/72) Accurately ripped
02 [215c81fe] (58/72) Accurately ripped
03 [a375ac96] (58/72) Accurately ripped

Offsetted by 12:

Track [ CRC ] Status
01 [32dfb9e4] (14/72) Accurately ripped
02 [9237105a] (14/72) Accurately ripped
03 [41330e52] (14/72) Accurately ripped

4. Раздел с отчётом по рипу, сверка контрольных сумм аудио данных с логом EAC

Track Peak [ CRC32 ] [W/O NULL] [ LOG ]
— 97,7 [0D0E0AE7] [9D5DCABB] CRC32
01 97,7 [05720F14] [3E3EDE49]
02 97,7 [F48E6ACF] [7568A11B]
03 89,5 [F035A64E] [883658F6]

##### End #####

5. Ссылки

1. CT Version, Data, Pregap

[CUETools log; Date: 11.08.2010 5:18:50 PM; Version: 2.0.9]

Думаю понятно, указана версия CUETools и дата проверки.

Pregap length 00:00:33.

Строка указывает на наличие нестандартного Pregap первого трека в рипе, ёё может и не быть, если Pregap стандартный [2ms].

CD-Extra data track length 09:16:26.

Строка указывает на наличие data-трека на диске, её может и не быть, если data-трек отсутствовал на диске.

перейти к Оглавлению

2. Отчёт по родной базе CTDB

[CTDB TOCID: vmNXKv93y95g9dAHwZLPIDqZBQc-] found.

[ CTDBID ]  Status  
[d20e5e00] (72/72) Accurately ripped

CTDB по сути аналог AccurateRip, автор базы AR зажал доступ к своей базе для рипера CUERipper [программа идёт в комплекте с CUETools, кстати отличный заменитель устаревшего EAC] в плане отправки данных о новых рипах, поэтому разработчик CUETools недолго думая сделал свою.

В данном случае TOCID в базе CTDB найдет “found”, имеется 72 рипа в базе и наш рип совпадает с ними, т.е. “Accurately ripped”.
Вывод отчета по родной базе пишется в режиме проверки с включёной CTDB, при обычном конвертировании этой информации в отчёте нету.

Кстати, вы можете помочь пополнить родную базу CT, надо всего лишь проверить свои рипы в режиме “submit” отметив чекбокс “Use CUETools database”, если достоверность в AR больше 2 рипов, то информация из AR автоматом переходит в базу CTDB.

Пример добавления диска в CTDB -> #cкриншот #1
и при последующих проверках этот диск уже будет в базе CTDB -> cкриншот #2.

перейти к Оглавлению

3. Отчёт по базе AccurateRip [далее просто AR]

[AccurateRip ID: 00048478-00153a01-30053e05] found.

Рип найден в базе AR, 3 часть AR ID , т.е. “30053e05” не что иное как DISC ID из FreeDB.
Может быть и такой вариант:

Disk not present in database.

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

Штамповка A , собственно с которой и имеем рип, она идёт всегда первой в списке.

Track [ CRC ] Status
01 [1f413828] (58/72) Accurately ripped
02 [215c81fe] (58/72) Accurately ripped
03 [a375ac96] (58/72) Accurately ripped

Штамповка B, отличается от нашей штамповки A смещением на 12 сэмплов.

Offsetted by 12:

Track [ CRC ] Status
01 [32dfb9e4] (14/72) Accurately ripped
02 [9237105a] (14/72) Accurately ripped
03 [41330e52] (14/72) Accurately ripped

Возникают два вопроса: “Что это за штамповки такие?” и “Чем они отличаются?”
Ответ под спойлером -> show


Штамповок в это примере всего две, но может быть гораздо больше. Вторая от нашей отличается на 12 сэмплов “Offsetted by 12”, значение это может варьироваться как в плюс так и минус, например -800 тоже нормальное значение.

Результаты самой первой в списке, т.е. нашей, нам и важны, если нашей штамповки нету в базе смотрим на результаты других, в поисках штамповки с Accurately ripped для всех треков.

Track – номер трека;
CRC – контрольная сумма трека;
Status – сюда в принципе попадают две колонки:
“58/72” – первая цифра 58 это кол-во рипов данной штамповки этого диска в базе, вторая цифра 72 это кол-во рипов этого диска в базе;

Следует так же понимать, что база AR заполняется обычными пользователями, со всеми вытекающими.
Чем больше рипов диска в базе AR, тем больше достоверность.

I. Accurately ripped

Accurately ripped – значит что трек прошёл проверку по базе, всё хорошо.
но могут быть и другие варианты:

II. No matches

[AccurateRip ID: 00048478-00153a01-30053e05] found.

Track [ CRC ] Status
01 [1f413828] (0/72) No matches
02 [215c81fe] (0/72) No matches
03 [a375ac96] (0/72) No matches

Offsetted by 12:

Track [ CRC ] Status
01 [32dfb9e4] (72/72) Accurately ripped
02 [9237105a] (72/72) Accurately ripped
03 [41330e52] (72/72) Accurately ripped

No matches – нет совпадений.
Как видим сам диск в базе есть, 72 рипа, но нашей штамповки A нет в базе, что значит?
по сути диск Accurately ripped, возможно наш вариант штамповки просто пока не успел попасть в базу или.. при рипе не выставили верное смещение дисковода, повод проверить лог или это хорошая копия оригинала.
В любом случае беспокоиться не стоит, так как имеем другую штамповку по соседству где все треки Accurately ripped.

III. Другой вариант No matches

[AccurateRip ID: 00048478-00153a01-30053e05] found.

Track [ CRC ] Status
01 [1f413828] (0/72) No matches
02 [215c81fe] (0/72) No matches
03 [a375ac96] (0/72) No matches

####конец отчета по AR###

Чем отличается от предыдущего? тем что рип в базе есть, 72 отчёта, наша штамповка с ним не совпадает,
НО при этом не выводится инфа о других штамповках [как в предыдущем варианте], а они есть.
Что значит? Самый вероятный вариант, что в настройках EAC была включена нормализация при рипе.
Лучше поискать другой рип, как минимум для сравнения.

IV. Вариант “Partial match”
Track [ CRC ] Status
01 [1f413828] (58/72) Accurately ripped
02 [215c81fe] (58/72) Partial match
03 [a375ac96] (58/72) Accurately ripped

т.е. один или несколько треков “Partial match” – частичное совпадение, тут возможно что:
Если достоверность большая [т.е. рипов в базе минимум больше одного], то ошибка с “вашей” стороны, если достоверность 1-2 рипа, то есть шанс что рип с ошибкой у того пользователя, который отправил результат в базу, т.е. результат в базе не верен.

  • a. Этот трек рипнулся с ошибкой, проверте лог на наличие ошибок в отчёте.
  • б. Производственный какой-нить брак, хоть диск и мог срипатся без ошибок.
  • в. Также как вариант образ разрезали на треки например в CUESplitter-ом [программа это делает некорректно].
    Как правило это сопровождается фразой “Padded some input files to a frame boundary.” – которая означает, что некоторые фрэймы были заполнены нулевыми сэмплами чтобы соответствовать стандарту: 1 фрэйм = 588 сэмплов.

Вообщем, если рипов этого диска больше 1-2 в базе, то имеет место быть ошибка в треке, это уже приговор.

Та же история если большинство треков прошли проверку, а несколько “No matches” или “No match but offset”.
Также обращаю внимание на то, что речь ведётся о результатах проверки нашей штамповки, результаты других нам не интересны в данном случае, так как наша есть в базе – 58 рипов.

перейти к Оглавлению

4. Отчёт по рипу, сверка контрольных сумм аудио данных с логом EAC
Track Peak [ CRC32 ] [W/O NULL] [ LOG ]
— 97,7 [0D0E0AE7] [9D5DCABB] CRC32
01 97,7 [05720F14] [3E3EDE49]
02 97,7 [F48E6ACF] [7568A11B]
03 89,5 [F035A64E] [883658F6]

Track – номер трека. Строка перед первым треком, где стоит прочерк “–“:

— 97,7 [0D0E0AE7] [9D5DCABB] CRC32

это строка с данными для всего образа, а далее уже инфо по каждому треку идёт.

Peak – он же Peak Level, т.е. максимальная громкость зарегистрированная в треке, это просто информация для статистики, к качеству рипа она отношения не имеет, однако можно сделать вывод о профессионализме мастеринга на студии, хорошо когда значение меньше 100.

CRC32 – контрольная сумма с учётом нулевых сэмлов

W/O NULL – контрольная сумма без учёта нулевых сэмплов, т.е. абсолютной тишины

LOG – колонка, в которой выводится информация совпали ли контрольные суммы проверяемых аудио данных с теми значениями, которые сохранены в EAC логе.

Вердикт пишется напротив образа, если рип снимался образом или напротив каждого трека, если рип потрековый, например так: открыть спойлер -> show

Если колонка LOG пуста, то лог не обрабатывался вообще, скорее всего лог либо отсутствуетт в папке с рипом, либо имеет название отличное от CUE, соответственно надо сделать одинаковые названия у CUE и LOG и повторить проверку.

➡ Когда контрольные суммы совпадают с логом EAC пишется CRC32 или W/O NULL.

— 97,7 [0D0E0AE7] [9D5DCABB] CRC32

или

— 97,7 [0D0E0AE7] [9D5DCABB] W/O NULL

Значит аудио данные полностью совпадают с логом и всё ok в этом плане.

➡ Если в этой колонке пишется другая контрольная сумма , значит с логом EAC не совпали аудио данные, например:

— 97,7 [0D0E0AE7] [9D5DCABB] 4352MFD6

Следовательно, либо лог EAC от совершенно другого рипа, либо с аудио данным произошли какие-то изменения после рипа, прежде чем они попали к вам, возможно, опять же, криво разрезали образ.

➡ Другой вариант:

— 97,7 [0D0E0AE7] [9D5DCABB] CRC32 : offset -667

CUETools нам говорит что данные совпадают с логом, но имеют смещение +667.
Скорее всего это получилось из-за того, что кто-то хотел подогнать результаты под определённую штамповку в базе AR и сместил данные намеренно.
В принципе тот же эффект будет если сами аудио данные взять от одной штамповки диска, а лог от другой.
Можно попытаться сдвинуть обратно на -667 сэмплов, если в начале и конце диска достаточно нулевых сэмплов, то все станет на нужные места. Если нет, то ничего не поделаешь, да и не критично это, считайте что у вас просто другая штамповка диска.
Как уже говорилось выше, разницы между штамповками одного и того же диска в звуке нету.

➡ Ещё такой вариант событий:

Track Peak [ CRC32 ] [W/O NULL] [ LOG ]
— 97,7 [0D0E0AE7] [9D5DCABB]
01 97,7 [05720F14] [3E3EDE49] [F48E6ACF]: CRC32 for track 2
02 97,7 [F48E6ACF] [7568A11B] [F035A64E]: CRC32 for track 3
03 89,5 [F035A64E] [883658F6]

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

перейти к Оглавлению

Наверно у вас может появиться вопрос, вот есть контрольные суммы в отчёте по базе AR и контрольные суммы в разделе сверки с логом EAC, но они разные, как так?
Дело в том, что используются разные методы [да и алгоритмы], например при подсчёте контрольной суммы трека для базы AR не учитываются 5 первых секторов/фрэймов первого трека и 5 последних последнего трека, т.е. по 2940 сэмплов.

На этом всё, дополнения и поправки по теме приветствуются (=

5. Ссылки

База CUETools – CTDB;
Официальный сайт CUETools – cue.tools;
Форум официальной англоязычной поддержки CUETools расположен на hydrogenaudio.org;
Форум русской поддержки CUETools расположен на rutracker.org;
CUETools блог – blog.cuetools.net;
Сайт старого CUETools v1.9.1 расположен на Moitah.net;

Нарезка “лосося” или обзор CUETools

Прямые ссылки на скачивание последних версий CUETools вы можете найти на этой станице релизов – CUETools Releases.

перейти к Оглавлению

—-
Публикация данной статьи на других ресурсах допускается только при указании автора статьи – Children of koRn и ссылки на оригинал.