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

[gchudov]

Это видимо та же проблема что и fooaccrip - не учитывается нулевой прегап и диск банально не находится в базе, хотя CRC высчитаны верно. Я просто не мог его учитывать, в виду того что cue в общем случае не доступен, а тут можно поправить Smiley .

Вроде учитывается.
А не было ли там дата-трека?

[baralgin]

2gchudov Есть проблемы с cue-файлом, если в нём файл и тэги русские(наверное и не только ). При этом съел такой cue в utf8, но выходной cue опять же с кракозябрами("?")

[studio308]

А не было ли там дата-трека?

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

При том риппер видит Data-track как область, имеющую свою временную длительность, а фактически это данные имеющие какой-то вес. Я уж пытался довольно сомнительным способом подделать data-track, потому что у меня не было оригинальных файлов из него. Надо было как-то запихнуть файл-пустышку под видом data-track, чтобы он имел нужную временную длину и представлялся, как data-track. Создать такой файл не было проблемой. Я просто создал WAV нужной длины и поменял расширение на bin, он естественно имел размер соответствующий длительности. Я пытался его вставить как трек в потрековый CUE, ведь есть же определенный стандарт для BIN. В случае аудио пишется WAVE после задания файла. А у BIN пишется BINARY, а в треках вместо AUDIO - MODE1/2048 (или другие варианты). Но ничего у меня не вышло - Mixed CD наверное возможно хранить только в виде имиджа диска. Может я где-то в cue ошибся...

[gchudov]

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

Уже можно В новой версии усилиями Moitah можно добавить в .cue строчку формата "REM DATATRACKLENGTH mm:ss:ff", и всё будет путём. Загвоздка только в том, откуда взять эти mm:ss:ff, т.е. "длину" дата-трека. Но я сделал еще примочку, что если рядом лежит log от свежего EAC, в котором TOC of the extracted CD сохранён, то автоматом оттуда берётся.

[gchudov]

2gchudov Есть проблемы с cue-файлом, если в нём файл и тэги русские(наверное и не только ). При этом съел такой cue в utf8, но выходной cue опять же с кракозябрами("?")

Поподробнее можно? У меня вся музыка английская, так что даже потестировать сложно - придётся выдумвать CUE Sheet из пальца
Заранее скажу, судя по коду CUETools работает в кодировке 1252, так что проблемы наверняка есть.

[baralgin]

Поподробнее можно? У меня вся музыка английская, так что даже потестировать сложно - придётся выдумвать CUE Sheet из пальца

Выдумать не проблема. Достаточно поменять название любого wav/wv/flac/ape фйла на имя с русским названием, да подправить cue соответственно. С тегами аналогично.
Вообще странный подход - я думал что net-программы это что-то прогрессивное, а тут поведение как у какой-нибудь программки под win95 . С C# сам не игрался, но может быть там достаточно реплэйсом пройтись: "string"->"wstring" ? . Вообще по хорошему внутри нужно всё юникодно обрабатывать, а при сохранении уже либо автоматом либо на выбор пользователя давать вариант ansi или utf8. Оба варианта foobar2000 ест без проблем с любыми символами.

[gchudov]

С C# сам не игрался, но может быть там достаточно реплэйсом пройтись: "string"->"wstring" ? Smiley . Вообще по хорошему внутри нужно всё юникодно обрабатывать, а при сохранении уже либо автоматом либо на выбор пользователя давать вариант ansi или utf8.

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

[baralgin]

Вопрос как читать неюникодные файлы. В них же никакого признака кодировки нету.

Посмотрел я код и увидел те самые 1252. Ведь это будет работать с символами только из страницы 1252(что не правильно). Я попробовал немного переделать и вроде заработало:

	Код:

//main.cs, class CUESheet
public static Encoding Encoding {
get {
   //return Encoding.GetEncoding(1252);
           return Encoding.Default;
}
}

По идее Encoding.Default должен возвращать текущую кодовую страницу(может я ошибаюсь). Так с русским именем файла и тэгами порядок(и читает и пишет). Даже принял cue в utf8 (сохранил правда в ansi, но коректно).

ps: вообще нужно смотреть конструкторы StreamReader'а

[gchudov]

Я тут узнал доподлинно что это за поле unknown в базе данных AccurateRip, с ним плагин сможет ловить оффсеты как TripleFlac. Это CRC 450го фрейма в треке. Обрабатывается как отдельный трек, в том смысле что нумерация начинается с 1 а не с 450*588+1. Скоро опубликую CUETools с поддержкой этой хрени, хотя там она не очень нужна - CUETools ищет оффсеты более правильно. А вот в плагине в его текущей форме (при потрековой обработке) это дело очень пригодится.

[baralgin]

2gchudov спасибо. Я вот пытался осуществить подбор как в CUETools у себя, но не получается(точнее алгоритм витает в мозгу, но реализовать видимо будет трудоёмко очень) - хоть эту штуку можно будет применить. Хотя от неё пользы всё же гораздо меньше чем при прямом подборе...

[studio308]

Скоро опубликую CUETools с поддержкой этой хрени, хотя там она не очень нужна - CUETools ищет оффсеты более правильно.

Насколько я понимаю, TripleFLAC находит оффсеты точно так же, как EAC, только с другой целью. Это не правильно?

[gchudov]

Скоро опубликую CUETools с поддержкой этой хрени, хотя там она не очень нужна - CUETools ищет оффсеты более правильно.

Насколько я понимаю, TripleFLAC находит оффсеты точно так же, как EAC, только с другой целью. Это не правильно?

Они определяют оффсет по контрольной сумме одного сектора, т.е. считанных милисекунд трека. Это не даёт никакой гарантии, что после применения данного оффсета рип будет успешно верифицироваться в целом. А если CUETools пишет, что найден оффсет - значит контрольная сумма всего трека сойдётся после применения оффсета.

[studio308]

Они определяют оффсет по контрольной сумме одного сектора, т.е. считанных милисекунд трека. Это не даёт никакой гарантии, что после применения данного оффсета рип будет успешно верифицироваться в целом. А если CUETools пишет, что найден оффсет - значит контрольная сумма всего трека сойдётся после применения оффсета.

Это понятно, но для скорости конечно стоит и этот метод иметь. Все-таки по моему опыту случаи несхождения с базой минимальны, даже на рипах сомнительного происхождения.

Недавно сравнивал Jon Hassell - Power Spot. Так оба рипа не проходят по обоим смещениям (хотя сделаны корректно). Однако же один рип при корректировке проходит по одному оффсету (-1414 вроде), а по другому не проходит один из треков (+897). А другой рип сходится со вторым оффсетом. При том оба рипа сделаны с оригиналов. Я еще не узнал, наверное каждый из рипов имел свое смещение. То есть фактически 2 рипа с оригиналов не сходятся с базой, а в ней еще 2 пачки рипов с других оригиналов. При том реально существует только 2 издания. Тот что -1414 - confidence 2, +897 - confidence 7.

[gchudov]

Это понятно, но для скорости конечно стоит и этот метод иметь. Все-таки по моему опыту случаи несхождения с базой минимальны, даже на рипах сомнительного происхождения.

Недавно сравнивал Jon Hassell - Power Spot. Так оба рипа не проходят по обоим смещениям (хотя сделаны корректно). Однако же один рип при корректировке проходит по одному оффсету (-1414 вроде), а по другому не проходит один из треков (+897). А другой рип сходится со вторым оффсетом. При том оба рипа сделаны с оригиналов. Я еще не узнал, наверное каждый из рипов имел свое смещение. То есть фактически 2 рипа с оригиналов не сходятся с базой, а в ней еще 2 пачки рипов с других оригиналов. При том реально существует только 2 издания. Тот что -1414 - confidence 2, +897 - confidence 7.

Дело в том, что моему алгоритму пофиг - что просто проверить рип, что найти все оффсеты. Так что для скорости второй метод не нужен. Я его добавил только для полноты картины.

Что касается странных рипов в базе - это хватает, я сам мучаюсь совестью отсылая результаты оцифровки пачки дисков с "горбушки" - там такой коктейль из смещений...
В идеале надо бы мистеру Спуну сделать чтобы его accuraterip.dll, используемая тем же EACом, не захламляла базу данных разными смещенными копиями.

[studio308]

В идеале надо бы мистеру Спуну сделать чтобы его accuraterip.dll, используемая тем же EACом, не захламляла базу данных разными смещенными копиями.

Именно. Стоило сделать, чтобы все смещения приводились к одному. В принципе я уже встречал такое, что при одном и том же смещении было 2 варианта контрольных сумм и обе были правильные. Только первый трек у обоих штамповок был одинаковым. Поэтому получалось так:
Трек 1: confidence 25
Трек 2-X: confidence 2

Естественно я пошел сразу и нашел себе нормальную штамповку со всеми треками около 25.
Это кстати Pet Shop Boys - PopArt CD1.

	Код:

Checking AccurateRip database

Track   Ripping Status          [Disc ID: 002e39f7-ed114111]

 1      Accurately Ripped    (confidence 25)     [b09bf719]
 2      Accurately Ripped    (confidence 28)     [41386b93]
 3      Accurately Ripped    (confidence 26)     [4198ecc7]
 4      Accurately Ripped    (confidence 25)     [663c662c]
 5      Accurately Ripped    (confidence 25)     [4a3ed8af]
 6      Accurately Ripped    (confidence 26)     [ec3e0e8e]
 7      Accurately Ripped    (confidence 27)     [3371b8a0]
 8      Accurately Ripped    (confidence 25)     [21d0b4ed]
 9      Accurately Ripped    (confidence 26)     [fb1eb586]
 10     Accurately Ripped    (confidence 25)     [38fd3f0b]
 11     Accurately Ripped    (confidence 25)     [2409df23]
 12     Accurately Ripped    (confidence 26)     [90b7d783]
 13     Accurately Ripped    (confidence 26)     [0389cfdd]
 14     Accurately Ripped    (confidence 27)     [801fd6ac]
 15     Accurately Ripped    (confidence 25)     [1833a88e]
 16     Accurately Ripped    (confidence 26)     [d310d028]
 17     Accurately Ripped    (confidence 23)     [d734db50]

_______________________

All Tracks Accurately Ripped.

[studio308]

2gchudov
Было бы неплохо добавить Drag&Drop для файлов. Он ведь умеет генерировать cue. Чтобы по сброшенным файлам создавался временный cue (во временной системной папке к примеру) и можно было уже начать работу. Не удобно доходить до глубокой папки хождением по дереву папок.

И еще не хватает функции добавления прегапа первого трека, она есть только в WAV Tools. Ну скажем добавлять его по нужде, если в cue нету. Может быть добавлять в новый cue по нахождению брутфорсом.

И кстати насчет прегапа первого трека. У меня есть пара примеров дисков, когда существуют в базе варианты с прегапом и без, естественно с разными оффсетами.

[gchudov]

2gchudov
Было бы неплохо добавить Drag&Drop для файлов. Он ведь умеет генерировать cue. Чтобы по сброшенным файлам создавался временный cue (во временной системной папке к примеру) и можно было уже начать работу. Не удобно доходить до глубокой папки хождением по дереву папок.

И еще не хватает функции добавления прегапа первого трека, она есть только в WAV Tools. Ну скажем добавлять его по нужде, если в cue нету. Может быть добавлять в новый cue по нахождению брутфорсом.

И кстати насчет прегапа первого трека. У меня есть пара примеров дисков, когда существуют в базе варианты с прегапом и без, естественно с разными оффсетами.

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

[studio308]

А откуда его еще взять?

Ну можно хотя бы вручную вводить значение.

А ты ведь говорил, что сделаешь такой же метод, как в TripleFLAC. C ним же можно брутфорсить прегап. Или скажем так - найти прегап брутфорсом с методом TripleFLAC, а сравнить с базой твоим методом. Я просто поражен, что он такой скоростной.

[gchudov]

Ну можно хотя бы вручную вводить значение.
А ты ведь говорил, что сделаешь такой же метод, как в TripleFLAC. C ним же можно брутфорсить прегап. Или скажем так - найти прегап брутфорсом с методом TripleFLAC, а сравнить с базой твоим методом. Я просто поражен, что он такой скоростной.

Прегап не влияет на процесс поиска оффсетов, поэтому по фиг методом TripleFLAC или моим.
К сожалению, на что прегап влияет, так это на поиск диска в базе.
Т.е. не зная прегапа нельзя узнать, по какому урлу к базе обратиться.
А брутфорс базы - вещь не очень корректная, ибо чревата слишком большой нагрузкой на эту самую базу.
Так можно и лишиться одобрения её владельцев на использование, а это было бы не очень приятно.
Вручную и так можно - в нотепаде вставлять эту строчку в .cue

2gchudov Есть проблемы с cue-файлом, если в нём файл и тэги русские(наверное и не только ). При этом съел такой cue в utf8, но выходной cue опять же с кракозябрами("?")

Вроде новая версия должна работать корректно.

[baralgin]

Т.е. не зная прегапа нельзя узнать, по какому урлу к базе обратиться.

просто база так сделана... через известные места . Можно наверное со стороны сервера организовать автоматическое перенаправление на нужный url(брутфорс на сервере), но врядли кто-то будет этим заниматься.

Вроде новая версия должна работать корректно.

Пока пользуюсь старой версией(собрал в 8-ом экспрессе).

На своей(fooaccrip) придумал способ эффективного перебора оффсетов - как-то уже работает. Возникло несколько вопросов:
1) вот сдвигаем треки "влево" - по мне так это отрицательный офсет. Тоесть вопрос чисто эстетический: что значит знак перед офсетом или что он должен значить?
2) в каком виде визуализировать информацию. Может в виде дерева(TreeView) с ветками оффсетов, в которых будут треки?
3) сейчас в "движке" ширину подбора офсетов нужно задавать до компиляции. К примеру для 8 фрэймов(±4704)  процесс подбора будет занимать порядка 5-10 секунд для средьненького ПэКа(10 секунд уже неприятно долго..., естественно время на декодировние тоже нужно ). В смысле сколько оставить оптимально, чтобы было и быстро и достаточно?

[gchudov]

Пока пользуюсь старой версией(собрал в 8-ом экспрессе).

Исходники теперь лежат в SVN на sourceforge, так что можно всегда иметь самую свежую версию. А если зарегистрироваться, то еще и исправить там что-нибудь самостоятельно

На своей(fooaccrip) придумал способ эффективного перебора оффсетов - как-то уже работает. Возникло несколько вопросов:
1) вот сдвигаем треки "влево" - по мне так это отрицательный офсет. Тоесть вопрос чисто эстетический: что значит знак перед офсетом или что он должен значить?
2) в каком виде визуализировать информацию. Может в виде дерева(TreeView) с ветками оффсетов, в которых будут треки?
3) сейчас в "движке" ширину подбора офсетов нужно задавать до компиляции. К примеру для 8 фрэймов(±4704)  процесс подбора будет занимать порядка 5-10 секунд для средьненького ПэКа(10 секунд уже неприятно долго..., естественно время на декодировние тоже нужно ). В смысле сколько оставить оптимально, чтобы было и быстро и достаточно?

1) Вопрос действительно чисто эстетический. Я выбрал знак так, чтобы показываемое смещение соответствовало тому, что надо написать в CUETools в поле offset, чтобы рип "исправить". Предлагаю выбрать тот же знак Проверить легко на любом рипе.
2) Звучит неплохо.
3) Я исходил из того, что в базе выкидывается CRC первых пяти фреймов за вычетом одного сэмпла, т.е. 5 * 588 - 1. При наличии оффсета больше чем данный, CRC первого и последнего трека скорее всего не сойдётся (если там нет цифровой тишины в начале и в конце). Подавляющее большинство приводов в эти рамки укладываются. Собственно из этих соображений такое число в базе AccurateRip видимо и было выбрано. Я выбрал его же.

[Elixer]

А можно получить какое нибудь пояснение по поводу вот такова сообщения CUETools:
"One or more input file doesn't end on a CD frame boundary. The output has been padded where necessary to fix this. If your input files are from a CD source, this may indicate a problem with you files."

При конвертировании такова образа фубаром и куетулс crc у файлов различаются, при этом куетулс в title треков встявляет путь к файлу.

[gchudov]

А можно получить какое нибудь пояснение по поводу вот такова сообщения CUETools:
"One or more input file doesn't end on a CD frame boundary. The output has been padded where necessary to fix this. If your input files are from a CD source, this may indicate a problem with you files."

При конвертировании такова образа фубаром и куетулс crc у файлов различаются, при этом куетулс в title треков встявляет путь к файлу.

На компакт-диске аудио-данные хранятся "пачками" (фреймами) по 588 самплов. Если корректно отрипаный образ корректно резать/сшивать (тем же cuetools или на крайняк фубаром), то в файле всегда будет целое число фреймов. А если эти файлы рипали с кривыми настройками (вырезая тишину например, или просто с крупными ошибками чтения), или резали в аудио-редакторе, или вообще записывали не с компакт диска, то файл может содержать "два землекопа и две трети". Обычно это признак проблемы.

Что касается того, что cuetools вставляет в title треков: на самом деле он вставляет туда имена треков, прочитаные из тэгов в исходных файлах. Видимо, в данном случае в тэге title исходных файлов почему-то находились пути к файлам. Чтобы они эти тэги не копировал в .cue, в свежих версиях можно отключить опцию 'Fill up missing CUE data from tags' (Advanced settings->General).

[Elixer]

2gchudov
Спасибо за разьяснение.
А чем лучше такие кривые рипы конвертировать фубаром или куетулсом?

[studio308]

Вручную и так можно - в нотепаде вставлять эту строчку в .cue

Предлагаешь вручную вставлять значения от 1 до 74? А если имидж, предварительно дописывать по 1 фрейму?
Ничего страшного думаю нет в брутфорсе, просто надо ограничить значения от 0 до 74 (хотя больше бывает). Можно будет отказаться от TripleFLAC полностью. Я уже жизни не представляю без твоего CueTools...

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

Вероятно еще берется в расчет наличие разных штамповок, порой различия могут быть очень большие, встречались и по 2000 семплов. Самый большой оффсет у одного привода ASUS CD-S520/A - +1858. А вообще кто-нибудь знает, откуда берется оффсет? Почему он вообще существует?

А чем лучше такие кривые рипы конвертировать фубаром или куетулсом?

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

2gchudov и 2baralgin
Может стоит сделать вывод результатов fooAccRip и CueTools в файл в одном стандарте?