проверяем лосслесс на качество из под foobar2000

[baralgin]

2studio308 хороший пример. На нём потренируемся.
Мои соображения: прегап наверное клеится к первому треку сверху, тем самым изменяется длительность этого трека(но не меняется количество самих треков), что влечёт за собой другой диск id и другой CRC для первого трека. Если ARCue может использовать эту информацию, то мой способ врядли(пока foobar не станет декодировать таким образом), но есть возможность отбрутфорсить это значение(подсказки EAC не всегда доступны...).
Что делает значение Leadin в TripleFlac ? Из декомпилированного исходника сложно разобрать, функция проверки слишком огромна.

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

[studio308]

Ни в коем случае не должен клеиться! Висит независимо и вообще не проверяется по базе.

Ведь TripleFLAC вообще не брутфорсит значения, а как-то их берет у базы. То же самое умеет делать EAC, когда достаточно быстро вычисляет схожесть с базой, даже не производя снятия.

[studio308]

А каким образом сравнивается информация у тебя? Ты ведь наверное запрашиваешь информацию по каким-то данным и получаешь что-то в ответ от базы. Надо просто ввести поле для ввода прегапа - исключительно вручную вводить его из cue. Может быть загрузка значения из cue может быть использована.

Вот насчет функции LeadIn в TripleFLAC точно ничего не знаю - это может оказаться и прегап, но значение там вроде бы integer - как туда время внести?

[baralgin]

Ни в коем случае не должен клеиться! Висит независимо и вообще не проверяется по базе.

Я имел в виду несколько другое, но это не столь важно(как оно работает разберёмся), а вот невозможность иметь значение прегапа для fooaccrip остаётся всё равно проблемой. Да, ввод с руки точно известного значения выход конечно, хоть и не совсем удобно. А также брутфорс . Какие максимальные значения прегапа встречаются?(информация для возможного брутфорса).

Ты ведь наверное запрашиваешь информацию по каким-то данным и получаешь что-то в ответ от базы.

Запрос в базу идёт по длинам треков и по их количеству(сами треки естественно не используются). На основе длин строятся три числа: discId1, discId2, cddbDiscId . Эти числа и определяют диск в базе. diskid1 это длинна имиджа, вероятно(скоро проверю) достаточно её увеличить на величину прегапа для нахождения диска в базе.

Вот насчет функции LeadIn в TripleFLAC точно ничего не знаю - это может оказаться и прегап, но значение там вроде бы integer - как туда время внести?

У меня есть предположение что это и есть прегап. Вводится он не во временных единицах а во фреймах. 75 соответствует 1с . Но это только предположение. Вообще значение прегапа из примера огромное просто(0:35.22 - 2647 фрэймов)...

[baralgin]

Проверил в tripleFlac этот leadin точно работает как прегап. И задаётся в виде фрэймов. Вот пример:


Как оно расчитывается я разобрался. Сделаю поле для ввода + поиск из лога если лежит в той же папке.

[studio308]

Какие максимальные значения прегапа встречаются?(информация для возможного брутфорса).

Ну если это именно прегап, то он максимально секунд 10 (Wolfsheim - Casting Shadows). Если это скрытый трек, то он может быть любого размера (обычно не более 2 минут, в Camouflage - Sensor и Relocated: 35 и 60 секунд соотв.). Если тебе хочется мучать базу брутфорсом, то можно и сделать. Ты подумал о том, что все будут это использовать даже на дисках где нет никакого прегапа первого трека?
Поэтому я думаю ручной ввод и загрузка из cue или log это максимум требуемого по этому вопросу.

Запрос в базу идёт по длинам треков и по их количеству(сами треки естественно не используются). На основе длин строятся три числа: discId1, discId2, cddbDiscId . Эти числа и определяют диск в базе. diskid1 это длинна имиджа, вероятно(скоро проверю) достаточно её увеличить на величину прегапа для нахождения диска в базе.

Ясно. Немного прояснило картину.

У меня есть предположение что это и есть прегап. Вводится он не во временных единицах а во фреймах. 75 соответствует 1с . Но это только предположение. Вообще значение прегапа из примера огромное просто(0:35.22 - 2647 фрэймов)...

Попробую...

[studio308]

2647 фрэймов

Поздравляю - со знанием математики у тебя всё чудесно. И со знанием TripleFLAC - это на самом деле прегап - и он именно 2647.
Кстати в TripleFLAC 2 поля для LeadIn и кнопочка со сканером между ними - думаю ты понял зачем это нужно...

[baralgin]

Если это скрытый трек, то он может быть любого размера (обычно не более 2 минут, в Camouflage - Sensor и Relocated: 35 и 60 секунд соотв.).

Хм, так какя разница как оно называется("прегап" или "скрытый трек") если смысл при проверке один? . В "Camouflage - Sensor" Это 35 секунд или почти 3 тысячи фрэймов. Такое взять брутфорсом можно конечно, но нагрузка на базу будет конечно непомерная, если все начнут увлекаться этим делом. Разве что можно ограничить несколькими секундами.

Кстати в TripleFLAC 2 поля для Lead In и кнопочка со сканером между ними - думаю ты понял зачем это нужно...

Да конечно. Интересно кто-то пользуется этим?!...

[studio308]

Да конечно. Интересно кто-то пользуется этим?!...

Я думаю что так не далеко и до запрета TripleFLAC. На самом деле брутфорс работает очень медленно, перебирал от 1 до 3000 наверное минут 5, дошел до 1500 и прибил - не вытерпел...

[baralgin]

На самом деле брутфорс работает очень медленно, перебирал от 1 до 3000 наверное минут 5, дошел до 1500 и прибил - не вытерпел...

Ну это он просто так сделан. Поднять скорость в раз 20 не проблема , но уложить на лопатки сервер будет как раз плюнуть, если каждый будет это юзать.

[studio308]

А ты сможешь сделать такую же скоростную систему определения диска по базе и нахождения смещений? Просто в логе у тебя и так выводятся все возможные штамповки, это я уже заметил. Так же показывается сколько приходится рипов на каждую и в главном окне через слеш показано со сколькими из полного количества рипов всех штамповок совпадает конкретный рип. Вот не хватает только смещений...

[baralgin]

Если честно, то я так и не разобрался, каким образом tripleflac находит смещения у "штамповок". Я вроде как всю структуру bin-файла разобрал и там нет места ещё и для смещений . Да и вообще принцип формирования этой информации не совсем ясен. Что подразумевается под термином "штамповка" и почему к каждой такой штамповке привязывается некий офсет?

Вообще подогнать (не)правильное смещение не проблема. Нужно, имея весь образ в памяти, прогнать от -X до X в надежде попасть. Времени это будет занимать мало. Такого нет в tripleFlac'е , но это потребует создания отдельной утилиты(которая будет есть много памяти).

[studio308]

Вот тебе еще загадка...




Со штамповками всё просто: это у нас есть оффсеты, а на производстве всё хорошо - взял матричную болванку и наклепал с неё дисков. И вот так каждый наклепал с этой болванки (или копии) дисков на своем оборудовании и получились разные штамповки. Отличаются они только оффсетом. Вот для примера: возьми и запиши с помощью Неро WAV файл на одном приводе и на другом (если у них конечно оффсеты разные) и получится 2 разных штамповки. Думаю ясно...

Я думаю, что значение оффсета просто вычисляется. Точнее не просто, но как-то вычисляется довольно быстро как EAC, так и TripleFLAC - так что стоит тебе рыться может быть в AccurateRip.dll. А использовать брутфорс не годится, тем более если можно найти значение с помощью TripleFLAC. Так что надо обязательно выяснить, как это делается.

[baralgin]

2studio308 по картинкам загадок нет. Просто в процессе подсчёта контрольной суммы трэка я не знаю положение трека в альбоме(первый, не первый, последний), поэтому для каждого трека расчитываю три разные контрольные суммы. но во время проверки(после сортировки) я уже беру из этих трёх сум именно ту что нужно. Это и обьясняет то что совпадения всё же есть. Все три суммы трэка можно увидеть если два раза щёлкнуть по нему мышкой.

каждый наклепал с этой болванки (или копии) дисков на своем оборудовании и получились разные штамповки.

Сдаётся мне что "клёпка" дисков в промышленном масштабе это не то же самое что писать на разных приводах. Если с офсетами приводов всё понятно(некое множество офсетов типа [..., 30, ..., 48, ..., 667, ...]) , то какие офсеты у производителей? . Ну да ладно, смысл примерно понятен.

А использовать брутфорс не годится, тем более если можно найти значение с помощью TripleFLAC

Как он всё же узнаёт я выясню. Но вариант брутфорса никуда не исчезает. Мне уже не интересно после раскодирования треков в fooaccrip узнать что офсет не правильный, т.к. пересчитать заново CRC я уже не могу. Есть у меня идея считать сразу диапозон CRC, но тут есть нюансы... Иначе выбрасывание в память всего образа и прямой брутфорс по словарю(список распрстранённых приводов) или по диапозону . Если всё правильно сделать, то занимать это будет времени очень мало(никакх дисковых операций не будет). Но я всё же пока обмозговываю первый вариант.

[studio308]

Уж не знаю чей это глюк, базы или TripleFLAC. Обычно там написано N.F. - Not Found (даже если оффсет существует в базе).
Но тут идут оффсеты -5880 - -5853 (видимо дальше не лезут) и у всех в скобках указано совпадение 0 - то есть, чтобы совпало с confidence 0 надо сместить на столько-то семплов...

Вообще TripleFLAC хорошенько подвисает на 20 секунд при проверке этого рипа. Я думаю он перебирает все оффсеты с -5880 до 5880 - почему именно такое число..?

Между прочим я заметил, что иногда он сам догадывается до прегапа, даже если его не написать.

[studio308]

Что это за CRC такие?

[baralgin]

Вообще TripleFLAC хорошенько подвисает на 20 секунд при проверке этого рипа. Я думаю он перебирает все оффсеты с -5880 до 5880 - почему именно такое число..?

А можно ссылочку?

Между прочим я заметил, что иногда он сам догадывается до прегапа, даже если его не написать.

Может в тегах находит?

Начёт тех неизвестных CRC: я не представляю что это такое. Возможно остатки некой старой системы подсчёта CRC, а может и ещё что то... Эти неизвестные байты - единственное что я не использую из скачиваемой информации с сервера.

[studio308]

Начёт тех неизвестных CRC: я не представляю что это такое. Возможно остатки некой старой системы подсчёта CRC, а может и ещё что то... Эти неизвестные байты - единственное что я не использую из скачиваемой информации с сервера.

Вообще я где-то читал, что CRC считается отдельно для двух каналов. Может это CRC левого и правого каналов... Почему они одинаковые тогда...
Тебе по крайней мере стоит изменить Unknown на то, что написано в TripleFLAC - для создания впечатления, что все же знаешь.

Вероятно это объяснение:

It has been brought to my attention that the CRC used in AccurateRip is not doing its job propperly, in laymans terms the Right Channel rolls out of the CRC Calculation every 1.5 seconds (that is 1st sample right channel is used 100%, by the 65535 sample it is not used, 65536 sample it is used 100% again, this repeats over and over). It is estimated that effectively 3% of the data is not getting into the CRC (at a 97% coverage, I stand behind AccurateRip @ 97% is better than most (? all) c2 implementations). Going back over the early AccurateRip code it seems the design of the CRC is fine, just the implementation (L and R channels were supposed to go in seperately, but were optimized to both go in without bringing down the upper 32 bits).

Может в тегах находит?

В тегах чего?

А можно ссылочку?

Можно. А на что?

[studio308]

2baralgin
Я хотел бы уточнить. CRC считается для двух каналов?

Вот еще кстати:

Fix the algorithm so all the data is used, both new and old CRC are calculated, new checked first, old second (with less Accuracy). New submissions would effectively appear as different pressings in the database.

Так что не надо удивляться, почему расходятся рипы. В базе просто только старые ARCS.
Надо тебе тоже вместо CRC писать ARCS - потому что это в самом деле не CRC.

Почитай кстати:
http://www.hydrogenaudio.org/forums/index.php?showtopic=61468

[baralgin]

Я хотел бы уточнить. CRC считается для двух каналов?

Да. В подсчёте CRC разделения на каналы нет вообще, тоесть они считаються вообще без какой-либо CDAUDIO-специфики.

Ссылку я имел в виду на тот рип, где tripleflac подвисает на 20 секунд.

В тегах чего?

Я имел в виду тэги flac'a , но скорее всего нет...

За ссылку спасибо - почитаем на досуге.

[studio308]

Это From Within - From Within III (Pete Namlook & Richie Hawtin). Кстати интересно еще то, что эти рипы сделаны с оригинальных дисков и прошли проверку по логам с confidence 2. Теперь на все диски AR показывает +66, второй диск вообще стал confidence 1. Собственно последний трек 3 диска и в оригинальном рипе не проходил проверку. Трек довольно странный, он длится 18 минут и звук там есть только на последних секундах, всё остальное время уровень -Inf.
Вот собственно раздача:
http://torrents.ru/forum/viewtopic.php?t=868504

Хоть послушаешь заодно...

[snatch]

Что это за CRC такие?

Я полагаю, что это:
1) либо куски аудиоданных по определённому (фиксированному?) адресу в треке (чтобы было по чему настраивать смещения),
2) либо CRC небольшого куска данных (менее вероятно)
Если знать, какое место следует сверять с этими данными - то проверка смещений сводится к сканированию небольшой области в поисках данного фрагмента, что не занимает много времени (что мы и наблюдаем в акк.рипе и трипл.флаке).

[studio308]

Нет, там ведь написано, что это CRC. Так что это точно 1 вариант.
Создатели базы не решились бы хранить даже маленькие части данных. Я не думаю, что такой короткий отрезок на самом деле мог бы содержать в себе хоть какую-то звуковую информацию.

[snatch]

Нет, там ведь написано, что это CRC. Так что это точно 1 вариант.
Создатели базы не решились бы хранить даже маленькие части данных. Я не думаю, что такой короткий отрезок на самом деле мог бы содержать в себе хоть какую-то звуковую информацию.

Во-первых, там написано, что это нечто под названием "unknown"
Во-вторых вот сам baralgin писал на эту тему:

Начёт тех неизвестных CRC: я не представляю что это такое. Возможно остатки некой старой системы подсчёта CRC, а может и ещё что то... Эти неизвестные байты - единственное что я не использую из скачиваемой информации с сервера.

В-третьих, если рассуждать логически, то для определения оффсетов необходимо привязываться к каким-то кускам данных/контрольным суммам данных в определенной точке. Чем бы ни была эта информация (unknown), она явно помогает быстро определить смещение анализируемых треков относительно ключевого диска/дисков (т.е. вернувшегося/вернувшихся в запросе). Осталось только понять, что может в этом радикально помочь (либо провести реверс-инжиниринг AccurateRip.dll или TripleFlac). На эту тему и были два моих предположения.

Почему я так уверен, что это помощь для поиска оффсетов? Да потому что, когда вставляешь диск, найденный в базе АР, штатные действия AccurateRip.dll на неоткалиброванном приводе - поиск оффсета, причём делает он это весьма быстро. То есть, анализирует небольшой объём данных, и при этом опирается на полученные из базы данные. То же можно сказать и про TripleFlac, просто её автор уже сделал реверс-ижиниринг ...или выведал у spoon-а алгоритм.
Какие ещё варианты?

[baralgin]

Значит так. Провёл эксперимент один. Обнулил треки и скормил их tripleflac'у :

В общем получается действительно что эти дополнительные CRC высчитываються по некоторому начальному куску трека и смещения подбираются. Осталось выяснить как. Тот глюк с подвисанием на "From Within III" связан с тем(скорее всего), что в связи со специфичностью трека(оооочень много нулей в начале) слишком много совпадений и забить всё это в интерфейс оказывается .net'у тяжко. В целом направление движения прояснилось - надо рыть tripleflac.

Я полагаю, что это:
1) либо куски аудиоданных по определённому (фиксированному?) адресу в треке (чтобы было по чему настраивать смещения),
2) либо CRC небольшого куска данных (менее вероятно)

Мне кажется логичным именно второй вариант. Т.к. искать совпадение всего лишь по одному сэмплу не очень надёжно.