Close Topic Options

k-dmitriy
Да это понятно, что сошлось или нет (кстати, с кем-то начали на эту тему спорить, да так и не закончили, лениво, если честно...). Я просто хочу найти способ проверки файла(ов), которые во множестве сейчас раздаются, то бишь APE или FLAC с прошитыми куями, логами и т.д. Бывает, что битый приходит. Вот распаковать обратно и сравнить - сразу ясно, качать заново или он изначально такой. Однако, задача... CRC имеется, а как его вычислить на ваве?

Сергей Иванович Не прочитал твое сообщение. В общем, нет решения, как явствует...

Я в соседнем топике уже интересовался близким вопросом:
Есть два релиза - в логе EAC суммы разные.
Значит ли это, что один из них хуже качеством? Если да - как сравнивать?

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

имхо тут речь не о худшем качестве, а об отличиях от оригинала.

• выставлен/не выставлен оффсет
• при подсчете CRC не учитываются нулевые семплы
• выставлен неверный оффсет

по CRC качество не проверишь, слушать надо, если только третьем рипом сравнить а может там брак партии
посмотри на оффсеты, присутсвуют ли они в обоих логах.

как прелестен рар архив хотя если это осел/торент там же хеши должны сойтись. другое дело если в файлообменник такое заливать или напрямую с хттп лить

А чем большне "отличий от оригинала", тем хуже "качество релиза" - поэтому и говорю, что вопрос близкий
В обоих логах оффсеты присутствуют. Я догадался распаковать оба файла и сравнить в EAC. Получил different samples в тысячных долях последней секунды.

Есть предположение, что это как раз влияние оффсета, т.е. релизы снимались с одного диска и "качество" одинаковое.
Правильно?

P.S. Еще раз сорри за ламерские вопросы, только начинаю разбираться с lossless audio.

This post has been edited by Arvur on 25-01-2007, 13:51

"Получил different samples в тысячных долях последней секунды" - это ты про имедж? Там по идее должна быть глубокая тишина, в зависимости от оффсетов - могут быть различное кол-во этой самой тишины.

Что касается вопроса про CRC - мы как-то пытались понять, чтож за CRC считает ЕАС - к единому мнению не пришли, тема была Post Link: Как сделать копию audio CD и ниже

Хорошо. EAC считает свой CRC, который, увы, привязан к офсетам. Нет проблем. Очевидно тогда, что должен быть ЕАС'о-калькулятор для проверки?
А галку надо снимать. Уже точно.

Блиииииин, да что ж там сложного-то? EAC считает CRC32 извлекаемых (или обрабатываемых в при открытии в редакторе) аудиоданных. Именно самих аудиоданных. И только их. И при том считается стандартный CRC32, такой же, что и программами вроде QuickSFV. Естественно, что CRC которое он подсчитывает и CRC WAV'а никогда не совпадут, ибо WAV содержит кроме аудиоданных ещё и хедер. Но это то, что касается случая, когда треклятая галочка "No use..." убрана. Когда же она стоит, то CRC чего EAC считает - известно только автору программы, да и то я в этом сильно сомневаюсь. CRC подсчитываемый и при извлечении и при открытии в редакторе не соответствуют как друг другу, так и CRC аудиоданных, если из подсчёта исключить начальные и конечные нулевые сэмплы. А ведь из подсказки на галочку при известной доле воображения можно понять, что по идее в подсчёте не участвуют именно начальные и конечные нулевые сэмплы. Но, допустим, что при подсчёте CRC не участвуют вообще все нулевые сэмплы (хотя на скорую руку проведённый эксперимент показывает, что и это не так). Тогда смысл в таком CRC от меня решительно ускользает... Вот почему я когда-то давным-давно в своём... как там его... RFC порекомендовал эту галочку не ставить. Чтобы в случае чего легко можно было сделанный кем-то релиз хоть в чём-то перепроверить...

Нет. CRC, как само понятие, явление и т.д. - относится к файлу. К целому файлу, со всеми потрохами. Никогда не слышал такого выражения, как CRC аудио-данных или графических, или еще каких-то. Это не CRC.

Да.

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

Ну как это никогда? Я в своём процитированном тобой же сообщении говорил о CRC аудиоданных. Именно CRC аудиоданных EAC и считает, вне всякой зависимости от того, слышал ли ты подобные выражения или нет...

Нет. CRC, как само понятие, явление и т.д. - относится к файлу. К целому файлу, со всеми потрохами. Никогда не слышал такого выражения, как CRC аудио-данных или графических, или еще каких-то. Это не CRC.

Кто ж тебе такую глупость сказал? И я тебе легко приведу пример, когда так делается. Почти все протоколы передачи данных (ну хоть тот же TCP) и многие форматы файлов (например RAR) устроены именно так -- там есть понятие CRC блока данных. Пакет устроен так: заголовок+данные. В заголовке есть поле: CRC данных. Когда пакет приходит, даннные выковыриваются оттуда, их чексумма пересчитывается заново и сверяется с тем, что написано в заголовке. У РАРа фактически то же самое происходит.

Да что там говорить, вон открой любой файл фубаром и погляди свойства. Там есть такой пункт: AudioData MD5: это хеш-сумма именно аудиоданных, посчитанная по алгоритму md5.

А ты просто наверное так думал, потому что работал с данными исключительно в виде файлов, и никогда не возился с ними "живьём".

С.И. абсолютно прав. Кстати, поясню, почему именно так сделано в случае аудиофайлов. Потому что WAV-файл по стандарту RIFF может иметь чёртову пропасть дополнительных информационных секций, на которые можно смело наплевать --- с точки зрения самого звука это не играет роли. Если бы в файл прошивалась КС всего целиком (ну например, в хвост файла дописывалась бы его md5), то при изменении этой информации было бы такое впечатление, что файл изменился. А данные-то те же. То есть в данном случае чексумма аудиоданных гарантирует нам именно то, что сами данные в целости и сохранности.

dmvn
Это вообще разные вещи, хотя и с одним названием. Тот же TCP оперирует пакетами, и нечем более, и там к каждому пакету добавляется контрольная сумма (длиной 8, 16 или 32 бита), которая включает в себя информацию обо всех информационных битах пакета. Поэтомы он и называется "циклическим контролем по избыточности" (Cyclic Redundancy Check).
И в чем его смысл - а в том, что весь пакет рассматривается как N-разрядное двоичное число, где N - количество бит в пакете. Для вычисления контрольной суммы это число делится на некоторое постоянное число, частное от этого деления отбрасывается, а остаток используется в качестве контрольной суммы. TCP не знает, что он передает, но он знает, что оно порублено на кусочки и на другом конце из этих кусочков соберут то, что передавали... Предполагается, что если все пакеты правильные, то и файл (группа файлов, и т.д.), состоящие из этих пакетов тоже правильны.
Возьми аудио диск или трек и сделай с него CRC, есть калькуляторы всех мастей.

А, вот теперь мы и подошли к самому важному: "что считать полезными данными". Но в любом случае CRC считается именно для некоторой битовой строки, как ты сам, собсно, и сказал. Алгоритм --- тот же, весь вопрос ИМЕННО в том, к чему его применять.

Да, согласен, про спецификацию TCP я немного наврал (лень было в man глянуть). Но суть-то та же самая, кстати, ещё вопрос, что было бы правильнее называть пакетом --- собсно пакет или пакет+CRC32(пакет) --- то есть тот блок данных, который скармливается протоколу следующего уровня. Не будем однако спорить, это терминология, не более того.

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

Формально говоря, я всегда под КС понимал именно выход алгоритма, применённого к строке (входу). А уж куда его пихать, и как проверять правильность --- дело десятое. Важно одно: для WAV применять чекеры типа md5sum -c не всегда правильно. Вернее так. Если чекер говорит OK, то и правда всё хорошо. Но если он сказал "Не ОК", то ещё надо выяснять, а правда ли эта разница кроется именно в аудиоданных.

Засим считаю вопрос о CRC WAV-ов исчерпанным (по крайней мере все поняли, как его надо считать и откуда оно берётся).

я... я... я не понял как его считать точнее чем, монтировать образ каждый раз и грабить его в ЕАС достаточно муторно, можно ли во что-нибудь (прогу) этот вав, а лучше лосслесс пихнуть, а оно высчитает CRC32 аудиоданных и сравнить уже получившееся значение с логом, шедшим с релизом, вдруг они его из воздуха придумали