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 и повторить проверку.

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

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

или

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

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

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

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

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

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

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

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

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

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 — www.cuetools.net;
Форум официальной англоязычной поддержки CUETools расположен на hydrogenaudio.org;
Форум русской поддержки CUETools расположен на rutracker.org;
CUETools блог — blog.cuetools.net;
Сайт старого CUETools v1.9.1 расположен на Moitah.net;

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

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

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

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