Файл accurip что это
Для удобства я разбил его на 4 раздела и по сути отчёт теперь является Оглавлением.
Для того чтобы перейти к описанию нужного раздела кликнете по его заголовку.
[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.
[CTDB TOCID: vmNXKv93y95g9dAHwZLPIDqZBQc-] found.
| [ CTDBID ] | Status | |
|---|---|---|
| [d20e5e00] | (72/72) | Accurately ripped |
| 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 |
| 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 недолго думая сделал свою.
| 3. Отчёт по базе AccurateRip [далее просто AR] |
|---|
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 |
Наверно все знают про смещение дисководов при записи и чтении, тоже самое и у производителей, производя один и тот же диск на разном оборудовании, они получают разное смещение данных, так и получаются разные штамповки.
Следовательно отличаются они друг от другом смещением данных, что же оно из себя представляет?
это смещение на N-Сэмплов, т.е. вначале диска допустим 12 сэмплов прибавилось и в конце диска 12 сэмплов убавилось, или наоборот, а все остальные данные между началом и концом диска остаются совершенно идентичные.
Критично ли это? в начале и конце диска находится как правило достаточно абсолютной тишины, либо цифрового шума [насколько помню
около 3000 сэмплов], поэтому их потеря вообще не страшна, есть некоторые диски где в конце диска нет не тишины ни шума, диск сразу заканчивается после последней песни.
Следовательно мы могли потерять немного данных, но как много?
1 сектор = 1 фрэйм = 1/75 секунды = 588 сэмплов = 2352 байта данных
Собственно это и есть отличие всех штамповок, какая-нить 1 милисекунда тишины в начале и конце диска.
Я не случайно подробно расписал, многие обходят рипы где не был выставлен оффсет при рипе, думают что это соверешенно неверный рип, будет звучать по другому и т.п., так вот ситуациия при невыставленном оффсете при рипе полностью идентична ситуации с разными штамповками, рипы абсолютно одинаковые, просто отличаются смещением данных.
Вот такой вот каламбур ©
Результаты самой первой в списке, т.е. нашей, нам и важны, если нашей штамповки нету в базе смотрим на результаты других, в поисках штамповки с Accurately ripped для всех треков.
Следует так же понимать, что база AR заполняется обычными пользователями, со всеми вытекающими.
Чем больше рипов диска в базе AR, тем больше достоверность.
| II. No matches |
|---|
| 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 |
| III. Другой вариант No matches |
|---|
| Track | [ CRC ] | Status | |
|---|---|---|---|
| 01 | [1f413828] | (0/72) | No matches |
| 02 | [215c81fe] | (0/72) | No matches |
| 03 | [a375ac96] | (0/72) | No matches |
Чем отличается от предыдущего? тем что рип в базе есть, 72 отчёта, наша штамповка с ним не совпадает,
НО при этом не выводится инфа о других штамповках [как в предыдущем варианте], а они есть.
Что значит? Самый вероятный вариант, что в настройках EAC была включена нормализация при рипе.
Лучше поискать другой рип, как минимум для сравнения.
Вообщем, если рипов этого диска больше 1-2 в базе, то имеет место быть ошибка в треке, это уже приговор.
это строка с данными для всего образа, а далее уже инфо по каждому треку идёт.
Вердикт пишется напротив образа, если рип снимался образом или напротив каждого трека, если рип потрековый, например так: открыть спойлер -> show
Если колонка LOG пуста, то лог не обрабатывался вообще, скорее всего лог либо отсутствуетт в папке с рипом, либо имеет название отличное от CUE, соответственно надо сделать одинаковые названия у CUE и LOG и повторить проверку.
Когда контрольные суммы совпадают с логом EAC пишется CRC32 или W/O NULL.
Значит аудио данные полностью совпадают с логом и всё ok в этом плане.
Если в этой колонке пишется другая контрольная сумма , значит с логом EAC не совпали аудио данные, например:
Следовательно, либо лог EAC от совершенно другого рипа, либо с аудио данным произошли какие-то изменения после рипа, прежде чем они попали к вам, возможно, опять же, криво разрезали образ.
CUETools нам говорит что данные совпадают с логом, но имеют смещение +667.
Скорее всего это получилось из-за того, что кто-то хотел подогнать результаты под определённую штамповку в базе AR и сместил данные намеренно.
В принципе тот же эффект будет если сами аудио данные взять от одной штамповки диска, а лог от другой.
Можно попытаться сдвинуть обратно на -667 сэмплов, если в начале и конце диска достаточно нулевых сэмплов, то все станет на нужные места. Если нет, то ничего не поделаешь, да и не критично это, считайте что у вас просто другая штамповка диска.
Как уже говорилось выше, разницы между штамповками одного и того же диска в звуке нету.
Ещё такой вариант событий:
Тут CUETools нам говорит, что неправильно пронумерованы треки, поэтому следует их нормально пронумеровать и повторить проверку.
Наверно у вас может появиться вопрос, вот есть контрольные суммы в отчёте по базе AR и контрольные суммы в разделе сверки с логом EAC, но они разные, как так?
Дело в том, что используются разные методы [да и алгоритмы], например при подсчёте контрольной суммы трека для базы AR не учитываются 5 первых секторов/фрэймов первого трека и 5 последних последнего трека, т.е. по 2940 сэмплов.
На этом всё, дополнения и поправки по теме приветствуются (=
You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
2. Хороший вопрос, может по каким-то причинам в базу AR попали не все результаты с каки-то рипов.
3. Потому, что сдвигаются ВСЕ треки на определённое число сэмплов, т.е. если штамповка была сдвинута на +12 сэмплов, то все треки сдвинулись на +12 сэмплов, у всех в начале появились +12 сэмплов, а в конце треков станет -12 сэмплов [они убежали в следующий трек и т.д.]
4. >>почему это может быть «хорошая копия оригинала».
потому, что кроме +/- N сэмплов в начале и в конце она ничем не отличается, Всё что между ними тоже самое до бита.
Справка и так вышла целой простынёй, это уже вопросы, в большинстве случаев, по работе самой базы AR. Я согласен, что тут не всё по сабжу, если и писать, то в отдельную статью про саму AR тогда.
Сейчас я за это не возьмусь, нужно лучше знать принципы работы базы, смотреть код и т.д.
Совпадёт ещё и как! Потому что чтение в этих областях не принципиально, а принципиально правильно установить луч лазера на то место, где начинается звук.
Это оно для нас может быть не принципиально [потому, что в подовляющем большинстве случаев там "мусор"], а вот когда считается CRC очень даже (:
@Children of koRn
Спасибо за ответы.
Ещё вопрос назрел. Из статьи я не сделал однозначного вывода, как интерпретировать, когда в колонке Log есть CRC для всего диска, но отсутствует для треков.
Пожалуйста,
это про 4. Отчёт по рипу, сверка контрольных сумм аудио данных с логом EAC?
так про колонку LOG:
Вердикт пишется напротив образа, если рип снимался образом или напротив каждого трека, если рип потрековый
т.е. зависит от того какой лог EAC прилагается к рипу, т.е. от типа рипа треки/образ.
@Children of koRn
Извиняюсь, в спешке задав вопрос я упустил важные детали.
Когда я через CUItools сравниваю образ, в логе выдаётся CRC только для образа, но после того, как я, опять же при помощи CUItools, образ разрезаю и провожу сравнение, выдаются CRC как для образа, так и для треков.
Так вот, тот альбом, который я имел ввиду, у меня находится потреково. Наверное, логично было бы предположить, что рип сняли с образа, а потом разрезали. Но дело в том, что в базе AC имеется 240 данных об этом альбоме. Что-то не совсем верится, что все до единого человека снимали рип именно образом, и никто из них не снимал треками.
Но дело в том, что в базе AC имеется 240 данных об этом альбоме. Что-то не совсем верится, что все до единого человека снимали рип именно образом, и никто из них не снимал треками.
Как я понимаю, речь о базе AR [AccurateRip], так вот там результаты для треков выдаются.
@Children of koRn
Чёй-то напутал . После разрезания образа и после проверки CRC для треков не появляется.
По поводу штамповок есть предположение: вероятно на завод не всегда отправляют физическую матрицу, а например некий образ на носителе, а саму физическую матрицу делает уже на самом заводе, в результате за счёт разного оборудования и получется погрешность в виде смещения, но это чисто ИМХО, хотя помойму вполне логично выходит.
+ предполагаю, что физическая матрица тоже не вечная и через N-ое кол-во циклов свой ресурс отрабатывает.
Добрый день!
Помогите новичку. Имеется несколько образов *.VW.
При конвертировании во FLAC CUETools сообщает, что диск не найден в базе данных, конвертирования не происходит. Что нужно сделать, чтобы все конвертировать эти образы?
Добрый, наверно речь о формате wavepack
Скажите версию CUETools и ссылку на раздачу.
Не нахождение в базе, не причина отказа в конвертировании, наверно там какая-то ошибка ещё показывается.
Причем только некоторые образы оттуда конвертируются. Ошибка возникла, например, с альбомом Машинально.
Нету на этом трекере, давайте тогда скриншот окна cuetools, когда происходит это.
Читайте также: