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

[snatch]

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

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

Да, согласен, теперь это очевидно...
И потому что твой эксперимент это подтвердил - tripleflac насчитал нулевые CRC,
и ещё потому что на скриншоте колонки называются L.Ofs.CRC/R.Ofs.CRC, что расшифровывается не иначе, как Local Offset CRC/Remote Offset CRC
Остаётся вопрос, с какой позиции и сколько семплов входит в эти CRC.
Тут мои предположения банальны - это, видимо, начало трека - я понаблюдал за tripleflac-ом, он читает из каждого флака первые 500-900 кил. Точнее, это libFLAC читает, но сути это не меняет - выходит, что сравнивается начало трека (вряд ли все 500к, поменьше кусок, скорее всего).
Для выяснения деталей, видимо остаётся только хачить tripleflac.
Кстати, можешь свой эксперимент с обнулением попробовать для этого - обнулять с начала трека по семплу/по десятку семплов - и наблюдать за CRC.

[studio308]

2snatch
Очень хорошо продвинул дело, получай очко.

2baralgin
Спасибы уходят Pete Namlook и Richie Hawtin за такой странный трек...

[studio308]

Сколько семплов не учитывается в конце? А то вот есть такой вариант:
кривой рип:


нормальный рип:

[baralgin]

2studio308 В последнем треке не учитываются 5 фрэймов(по 588 сэмплов каждый). Итого получится 1/15 секунды.

зы: пока у меня мало времени, поэтому мало чем могу обрадовать .

[studio308]

Тут 20ms - 1/50 - так что с этим треком - кстати он длится аж 73 минуты - был бы пролёт. Он вдобавок как первый так и последний на диске.

[baralgin]

Он вдобавок как первый так и последний на диске.

Ситуация интересная - я даже не знаю считать ли этот трек первым или последним, т.к. CRC будут разные..

[studio308]

CRC будут разные..

А имеет ли это значение? Совпадение с базой ведь происходит по своим признакам, а уж ARCS можно выводить все 3 штуки.
Можно и проверить этот факт по проверкам TripleFlac и EAC.

[studio308]

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

Проверка неверного рипа:

Последний трек в логе неверного рипа:

Track  8
     Filename D:\Flac Rips\Robert Rich - Calling Down The Sky 2003\08 - Recognition.wav
     Peak level 84.0 %
     Track quality 99.8 %
     Test CRC EB01D22C
     Copy CRC EB01D22C
     Copy OK

Последний трек в логе верного рипа:

Track  8
    Filename C:\Users\Brandon\Music\Robert Rich - Calling Down The Sky (2003)\08 - Recognition.wav
    Pre-gap length  0:00:00.06
    Peak level 84.0 %
    Track quality 99.9 %
    Test CRC 46A1B203
    Copy CRC 46A1B203
    Accurately ripped (confidence 4)  [A5A242D8]
    Copy OK

PS: у меня целая телега таких рипов (всего их тот человек сделал более 300, может и больше 1000 - мне это неведомо). Сейчас они раскиданы повсюду, источник я предпочту не упоминать лишний раз, но точно скажу, что эти рипы происходят от приводов Philips с такой вот меткой:

IDE-DVD DROM6216

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

[studio308]

Выделенный трек взят из кривого рипа. Тут видно, что различиются подсчеты для первого и среднего треков, но одинаковые как раз для последнего.


И у меня возник вопрос, а возможно ли не игнорировать первые и последние семплы? Какова вообще цель их игнорирования?

[baralgin]

studio308
Игнорировать или нет зависит только от создателя базы. Цель можно предположить: чтобы можно было проверить контрольные суммы даже даже при неправильном смещении рипанья(всегда можно сместить в любую сторону). Плюс возможно о существовании таких вот "неправильных" приводов известно... В любом случае для конечного пользователя я не вижу проблемы. Последний трек чаще всего заканчивается "нулями"(собственно как и первый начинается) и/или фэйд аутом(ином) поэтому на слух ничего плохого не будет. Ведь рипают диски всё же в первую очередь для прослушивания .

Есть новая версия fooCDtect: брать тут или с зеркала .
Много мелких доработок, из основного:
- есть возможность выбирать кодировку для лога. Для utf8 и utf16 в начало файла добавляются соответсвующие метки. По умолчанию выбирается utf8
- добавился третий тип лога: простой. В нём предполагался простой вариант отчёта вида: <track> - <result> . Но по просьбе одного товарищи с HA трэки выводятся с полными путями.
- есть возможность задать путь для временных файлов(если не задать то всё работает по старому). От файлов-пустышек это не избавляет(это архитектурно невозможно), но может быть полезно если есть более быстрое устройство для записи больших временных файлов(я с рам диском играюсь)
- если проверяется много файлов, то есть возможность посмотреть сколько каких треков напроверялось(file->stats)
- теперь можно на лету менять приоритет процесса проверки, а также задавать количество ограничивающих потоков(в начале статусной строки жать ПКМ)
- в расширенном логе из stdout информации aucdtect.exe иногда появлялись длинные "некрасивые" временные имена файлов, для красоты я их меняю на настоящие.
- при создании окна foocdtect указывается хэндл окна плэйера(foobar2000) как родительское окно. Что даёт некую илюзию нативности foocdtect как плагина . Если этот вариант будет не по душе, то могу вернуть по старому, хотя по мне так лучше. В связи с этим я удалил возможность смены свойства окна "поверх всех окон".

Есть ещё идея формировать сонограммы по трекам(аля tau-analyzer), но это в будущем...

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

[gchudov]

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

Добрый день. Я тут на коленке доработал arcue на предмет поиска смещения, для рипов сделанных без его коррекции.
Удалось добиться того, что смещение находится за один проход по файлу, т.е. без необходимости держать весь имидж в памяти, хотя эта процедура и занимает на моём компе около 3х минут.
Использовался следующий трюк: для всех потенциальных смещений (от -1000 до +1000 в данном случае) параллельно высчитывалась CRC.
Потом эти 2001 контрольные суммы сравнивались со списком CRC, присланных их базы AccurateRip.
На приведённом примере обнаружилось в базе данных целых два "варианта" данного диска с разными смещениями, мой оказался третьим

	Код:

E:\Music\New>"C:\Program Files (x86)\EAC\CUETools\arcue.exe" --auto-offset 1000 "Dalis Car - The Waking Hour.cue"
Dalis Car - The Waking Hour.cue:

Checking AccurateRip database

Track   Ripping Status          [Disc ID: 0009b322-5b083807]

 1      ** Rip offset:  659 **   (confidence 3)     [b605b00c]
 1      ** Rip offset: -700 **   (confidence 2)     [58be0384]
 2      ** Rip offset:  659 **   (confidence 3)     [e61c0b68]
 2      ** Rip offset: -700 **   (confidence 2)     [222b14dd]
 3      ** Rip offset:  659 **   (confidence 3)     [bf2447a8]
 3      ** Rip offset: -700 **   (confidence 2)     [f435ffb8]
 4      ** Rip offset:  659 **   (confidence 3)     [7f1f190f]
 4      ** Rip offset: -700 **   (confidence 2)     [ad24af7b]
 5      ** Rip offset:  659 **   (confidence 3)     [4889e394]
 5      ** Rip offset: -700 **   (confidence 2)     [51dd6ddb]
 6      ** Rip offset:  659 **   (confidence 3)     [fdf1b2f7]
 6      ** Rip offset: -700 **   (confidence 2)     [d990e73a]
 7      ** Rip offset:  659 **   (confidence 3)     [d648ea71]
 7      ** Rip offset: -700 **   (confidence 2)     [a20c646a]

_______________________

Track(s) Accurately Ripped: 0
**** Track(s) Not Ripped Accurately: 0 ****
Track(s) Not in Database: 0

Если вас интересует, могу попробовать вставить эту функциональность в ваш fooaccrip . Есть какой-нибудь CVS/SVN?

[baralgin]

2gchudov cvs/svn нет. Но исходник можно взять тут . На нём можно проводить разные эксперименты. Если будут какие-то неясности с кодом, то помогу. Я всё же подумываю писать настоящий плагин, когда все неясности будут уточнены. Пока я хочу ещё добавить некоторый функционал в foocdtect, чтобы окончательно закрыть вопрос .

[gchudov]

2gchudov cvs/svn нет. Но исходник можно взять тут . На нём можно проводить разные эксперименты. Если будут какие-то неясности с кодом, то помогу. Я всё же подумываю писать настоящий плагин, когда все неясности будут уточнены. Пока я хочу ещё добавить некоторый функционал в foocdtect, чтобы окончательно закрыть вопрос .

Спасибо, посмотрел. Проблема в том, что поиск offsetа затруднителен при потрековой обработке - для вычисления контрольной суммы трека мне нужны последние пять фреймов предыдущего и первые пять фреймов следующего. Поэтому органично это можно было бы сделать только при обработке альбома одним куском. Была мысль пользоваться кнопкой конверсии в "album images with cue sheets and chapters" вместо потрековой. Но к сожалению фубар генерит .cue файл только после того, как конвертер завершит работу, а хранить 700мб распакованого альбома во временном файле не хотелось бы. Вдобавок этот .cue файл вычищен от нулевых индексов и pregap. Остаётся одно - как-то в начале обработки вытащить оригинальный .cue файл, а не полагаться на создаваемый. Ну или убедить разработчиков фубара передавать его конвертеру.

Заодно с грустью для себя узнал что даже при конверсии из одного losless формата в другой с помощью опции "album images with cue sheets and chapters" теряется важная информация о структуре диска - как минимум эти самые гапы, а скорее всего и всякая прочая полезная информация навроде replaygain. Придётся отказаться от использования этой опции, если её функциональность не изменят

[studio308]

Я всё же подумываю писать настоящий плагин, когда все неясности будут уточнены.

Может это будет общий плагин для анализов всех видов?

[studio308]

2gchudov
Брутфорс конечно годится везде, но времени уйдёт немеряно на него. Я лично видел альтернативное смещение около +3900 - это ж в 8 раз больше времени уйдет на подсчет +/- 4000.

[baralgin]

для вычисления контрольной суммы трека мне нужны последние пять фреймов предыдущего и первые пять фреймов следующего. Поэтому органично это можно было бы сделать только при обработке альбома одним куском.

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

а хранить 700мб распакованого альбома во временном файле не хотелось бы.

Я в таком случае скорее всего задействовал бы память. Всё таки слова Билла про "640Кб за глаза" были сказаны очень давно и пора смириться (имхо конечно) в неизбежности обладания комфортным количеством памяти.

Придётся отказаться от использования этой опции, если её функциональность не изменят

Просто эта опция создана для склеивания порезанных треков(где и так уже всё утеряно, если было что терять). А перекодировать образ лучше просто одним файлом с сохранением оригинального cue'я .

Может это будет общий плагин для анализов всех видов?

Мне видится более рациональным позже просто перенести foocdtect "на новые колёса". Всё же типы проверок слишком разные. Хотя в любом случае медведь ещё не убит .

[studio308]

Мне видится более рациональным позже просто перенести foocdtect "на новые колёса". Всё же типы проверок слишком разные. Хотя в любом случае медведь ещё не убит  .

Так я же не говорю прям на всё сразу проверять. Просто будет пункт в меню работы с файлами (по соседству с Integrity Verifier) fooCDCheck files...
А уж он должен вызывать окно с кучей разных проверок (целых 2).
Я бы еще попросил. Ты мог бы сделать простую вещицу: считалку CRC наподобие WavCRC для foobar2000? Просто раскодировать файлы, при чем не в имидж, а по трекам в WAV, чтобы посмотреть CRC - ужас. И это уже стало бы тестером №3.

[baralgin]

Брутфорс конечно годится везде, но времени уйдёт немеряно на него.

Если правильно организовать, то времени будет уходить не много. Главное правильно понимать принципы подсчёта этих самых крк.

Просто раскодировать файлы, при чем не в имидж, а по трекам в WAV, чтобы посмотреть CRC

А какая там формула? Можно конечно и такое.

[studio308]

А какая там формула?

Это не ко мне вопрос. WavCRC сделал dmvn.
Вот тут есть исходник в консольной версии: http://torrents.ru/forum/viewtopic.php?t=357895

[studio308]

Я провел тесты, сделал рипы одного и того же диска, который заканчивается логическими семплами, а не тишиной. На всех приводах конец разный и он зависит от величины оффсета. Самый большой кусок отрезан у привода Benq с оффсетом +691, самый маленький у Sony - +6. Так что скорей всего логика по выкидыванию последних 5 фреймов при расчете ARCS верна.

Ничего ужасней еще не говорил, но надо искать привод (для покупки) с наименьшим оффсетом или с обязательной поддержкой чтения в Lead-In/-Out.

Рип на Plextor с включенным чтением в выводе дал тот же результат, что и рип на Sony CRX-210E1 - за счет маленького оффсета в конце обнулились только нулевые семплы. Еще я сделал вывод, что выкидывание первых семплов начального трека излишне, так как он читается от самого первого реального семпла при правильном оффсете (есть рипы дисков, которые начинаются не с тишины, там нет пробелов). Вероятно чтение в Lead-In может каким-то образом прочитать семплы до 0 сектора (диск ведь начинается с -150 сектора). Интересно было бы поэкспериментировать.

[baralgin]

2studio308 наверное так. Главное чтобы "серединка" была целая.

Ни у кого нет проблем с последней версией foocdtect при проверке "русских" треков(или с другими "неанглийскими" символами в тегах)?

[gchudov]

2gchudov
Брутфорс конечно годится везде, но времени уйдёт немеряно на него. Я лично видел альтернативное смещение около +3900 - это ж в 8 раз больше времени уйдет на подсчет +/- 4000.

Максимальное смещение, при котором сохраняются контрольные суммы accurateRip - 2939. При поиске от -2939 до +2939 на моём Core 2 Duo 3Ghz уходит примерно 1-3 минуты на диск.

[AlexCom]

Вот сейчас проверил один альбомчик с русскими тегами, (WIN XP, acelpad-notepad нету), сохронял с разными кодировками в режиме "normal", а так же попробывал режим "verbose"-UTF8, все теги были читабельны.

[baralgin]

2AlexCom проблема не в сохраняемых логах, а в окне программы. Нужно чтобы не оставалось темповых имён в окне(они после проверки меняются на нормальные). Я уловить не могу ничего противоестественного...

[AlexCom]

Понял, с этим тоже было нормально. Повторюсь ещё раз проверял на WIN XP SP3. В окне программы появлялись темповые файлы, но после конвертирования преоброзовывались в нормальные название треков.