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

**studio308** » 11.10.2008, 17:53

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

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

**gchudov** » 11.10.2008, 18:16

studio308:
gchudov:Скоро опубликую CUETools с поддержкой этой хрени, хотя там она не очень нужна - CUETools ищет оффсеты более правильно.
Насколько я понимаю, TripleFLAC находит оффсеты точно так же, как EAC, только с другой целью. Это не правильно?

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

**studio308** » 11.10.2008, 22:48

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

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

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

**gchudov** » 12.10.2008, 00:00

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

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

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

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

**studio308** » 12.10.2008, 00:39

gchudov:В идеале надо бы мистеру Спуну сделать чтобы его 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** » 12.10.2008, 05:05

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

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

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

**gchudov** » 12.10.2008, 11:22

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

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

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

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

**studio308** » 14.10.2008, 16:26

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

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

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

**gchudov** » 17.10.2008, 22:34

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

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

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

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

**baralgin** » 18.10.2008, 01:57

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

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

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

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

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

**gchudov** » 18.10.2008, 03:57

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

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

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

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

**Elixer** » 19.10.2008, 16:30

А можно получить какое нибудь пояснение по поводу вот такова сообщения 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** » 19.10.2008, 17:16

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 треков встявляет путь к файлу.

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

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

**Elixer** » 19.10.2008, 17:56

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

**studio308** » 19.10.2008, 21:15

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

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

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

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

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

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

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

**baralgin** » 19.10.2008, 21:28

studio308:foobar2000 не скажет ничего на эту проблему и не будет дописывать тишиной частичные фреймы. Cue Tools это делает, потому что он вроде как следует стандарту CDDA.

Так в итоге ни от того ни от того ничего хорошего не получится и такой рип нужно резать в корзину :) .

studio308:Ничего страшного думаю нет в брутфорсе, просто надо ограничить значения от 0 до 74 (хотя больше бывает).

Бывает и гораздо больше.. А ещё нужно ограничить время между попытками(к примеру не больше раза в секунду). В идеале конечно нужно параллелить, но это как раз то, что убъёт сервис...

studio308:Может стоит превести вывод fooAccRip и CueTools к одному стандарту?

Ну моя ещё выводов не делает, поэтому если "стандарт" от CueTools приживётся, то можно будет сделать также :) .

2gchudov Про пять фрэймов понятно - логично конечно. Хотя теоретически можно и вручную сдвинуть(по незнанию к примеру) куда-то далеко. В худшем случае не сойдутся первый/последний трек. Хотя эти варианты рассматривать не будем и ограничимся на 5*588.

**studio308** » 19.10.2008, 23:06

baralgin:Так в итоге ни от того ни от того ничего хорошего не получится и такой рип нужно резать в корзину.

Если честно, то рипов таких вроде не встречал. Как правило такие вещи происходят в самом деле после ручного вмешательства с помощью редактора. Любой рип, чем бы он не был сделан, будет иметь оригинальную длину. Даже не знаю, как надо рипать, чтобы добится такого результата.

baralgin:А ещё нужно ограничить время между попытками(к примеру не больше раза в секунду).

Что-то долго. Думаю скорость TripleFLAC вполне приемлимая. Не думаю, что вообще когда-либо будет так много народу брутфорсить оффсеты, тем более злоупотреблять этой функцией. Как минимум надо, чтобы было поле ручного ввода прегапа. Вообще можно несколько облегчить задачу и проходится по стандартным прегапам: 1, 32, 33, 37, 50. Какие там еще?

baralgin:Ну моя ещё выводов не делает, поэтому если "стандарт" от CueTools приживётся, то можно будет сделать также.

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

baralgin:В худшем случае не сойдутся первый/последний трек.

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

**studio308** » 19.10.2008, 23:19

Вот так надо сравнивать ;) :

Код: Выделить всё: [Disc ID: 00316908-0295bee6-0e120412] Track [ CRC ] Status 01 [49707268] (47/178) Accurately ripped as in pressing(s) #1 02 [ade8d320] (46/182) Accurately ripped as in pressing(s) #2 03 [171da212] (47/183) Accurately ripped as in pressing(s) #2 04 [0840826a] (47/181) Accurately ripped as in pressing(s) #2 05 [adaafbe1] (45/173) Accurately ripped as in pressing(s) #2 06 [4f600e7e] (47/182) Accurately ripped as in pressing(s) #2 07 [70e8dc1c] (45/175) Accurately ripped as in pressing(s) #2 08 [6014fd9a] (44/179) Accurately ripped as in pressing(s) #2 09 [1a5acb3f] (44/170) Accurately ripped as in pressing(s) #2 10 [eaf50dd5] (44/177) Accurately ripped as in pressing(s) #2 11 [cef1efc3] (45/177) Accurately ripped as in pressing(s) #2 12 [8da03732] (43/174) Accurately ripped as in pressing(s) #2 13 [68dd4b1c] (42/172) Accurately ripped as in pressing(s) #2 14 [ae2c6a4d] (44/169) Accurately ripped as in pressing(s) #2 15 [d58c03b2] (40/166) Accurately ripped as in pressing(s) #2 16 [f411901e] (40/159) Accurately ripped as in pressing(s) #2 17 [4aadc6f9] (40/156) Accurately ripped as in pressing(s) #2 18 [2509d441] (41/157) Accurately ripped as in pressing(s) #1 Offsetted by -837: 01 [5d38ee57] (00/178) No matches 02 [8385a3be] (02/182) Accurately ripped as in pressing(s) #6 03 [f85c9c7d] (00/183) No matches 04 [232ebb99] (00/181) No matches 05 [4af0c3a2] (00/173) No matches 06 [5517d421] (02/182) Accurately ripped as in pressing(s) #6 07 [d2642035] (00/175) No matches 08 [3d19d9fa] (00/179) No matches 09 [d5acacf2] (00/170) No matches 10 [99ce98ef] (02/177) Accurately ripped as in pressing(s) #6 11 [ebd0a3bb] (00/177) No matches 12 [1f1bcb40] (00/174) No matches 13 [977cb5ac] (00/172) No matches 14 [8cb2c467] (00/169) No matches 15 [0557bcf5] (00/166) No matches 16 [c51f87a5] (00/159) No matches 17 [71bcfbc8] (00/156) No matches 18 [46dac3bd] (00/157) No matches Offsetted by -99: 01 [e5ee0271] (28/178) Accurately ripped as in pressing(s) #3 02 [117f8072] (29/182) Accurately ripped as in pressing(s) #3 03 [05b6f97f] (29/183) Accurately ripped as in pressing(s) #3 04 [b61a9f33] (30/181) Accurately ripped as in pressing(s) #3 05 [8676ada8] (28/173) Accurately ripped as in pressing(s) #3 06 [c92b7873] (29/182) Accurately ripped as in pressing(s) #3 07 [13d6684b] (28/175) Accurately ripped as in pressing(s) #3 08 [2223543a] (30/179) Accurately ripped as in pressing(s) #3 09 [2840b1a4] (29/170) Accurately ripped as in pressing(s) #3 10 [8685268b] (29/177) Accurately ripped as in pressing(s) #3 11 [19edff8b] (29/177) Accurately ripped as in pressing(s) #3 12 [fc6cc494] (29/174) Accurately ripped as in pressing(s) #3 13 [190bad0c] (30/172) Accurately ripped as in pressing(s) #3 14 [99b2ac03] (29/169) Accurately ripped as in pressing(s) #3 15 [494ec707] (28/166) Accurately ripped as in pressing(s) #3 16 [4586cc2d] (26/159) Accurately ripped as in pressing(s) #3 17 [87656f84] (25/156) Accurately ripped as in pressing(s) #3 18 [0ac232a5] (28/157) Accurately ripped as in pressing(s) #3 Offsetted by 235: 01 [a4d733c7] (09/178) Accurately ripped as in pressing(s) #5 02 [e84cda9e] (09/182) Accurately ripped as in pressing(s) #4 03 [a7db03ad] (09/183) Accurately ripped as in pressing(s) #5 04 [68fcb509] (09/181) Accurately ripped as in pressing(s) #5 05 [2eee4132] (08/173) Accurately ripped as in pressing(s) #4 06 [f560c2d1] (08/182) Accurately ripped as in pressing(s) #4 07 [270ce745] (08/175) Accurately ripped as in pressing(s) #4 08 [50362ffa] (08/179) Accurately ripped as in pressing(s) #5 09 [e21774a2] (08/170) Accurately ripped as in pressing(s) #4 10 [2eb3b18f] (08/177) Accurately ripped as in pressing(s) #4 11 [74ded73b] (08/177) Accurately ripped as in pressing(s) #5 12 [71ee6120] (08/174) Accurately ripped as in pressing(s) #5 13 [35d936ac] (08/172) Accurately ripped as in pressing(s) #5 14 [b03b4d07] (08/169) Accurately ripped as in pressing(s) #5 15 [874955a5] (07/166) Accurately ripped as in pressing(s) #5 16 [9ed38aee] (04/159) Accurately ripped as in pressing(s) #5 17 [19ce2aff] (05/156) Accurately ripped as in pressing(s) #5 18 [636b757d] (07/157) Accurately ripped as in pressing(s) #5 Offsetted by 266: 01 [0c677b0a] (75/178) Accurately ripped as in pressing(s) #2 02 [35b8d2e4] (79/182) Accurately ripped as in pressing(s) #1 03 [79964fbc] (80/183) Accurately ripped as in pressing(s) #1 04 [b3d7708c] (79/181) Accurately ripped as in pressing(s) #1 05 [291b13df] (75/173) Accurately ripped as in pressing(s) #1 06 [ebaf49b8] (78/182) Accurately ripped as in pressing(s) #1 07 [d7968f6a] (76/175) Accurately ripped as in pressing(s) #1 08 [351014da] (78/179) Accurately ripped as in pressing(s) #1 09 [69604659] (73/170) Accurately ripped as in pressing(s) #1 10 [a37c3aa1] (76/177) Accurately ripped as in pressing(s) #1 11 [316e4bd3] (76/177) Accurately ripped as in pressing(s) #1 12 [59947816] (75/174) Accurately ripped as in pressing(s) #1 13 [4715adfc] (74/172) Accurately ripped as in pressing(s) #1 14 [cdea7919] (71/169) Accurately ripped as in pressing(s) #1 15 [00c687ac] (75/166) Accurately ripped as in pressing(s) #1 16 [e8fb1f04] (71/159) Accurately ripped as in pressing(s) #1 17 [49c5cac7] (70/156) Accurately ripped as in pressing(s) #1 18 [6ba61749] (65/157) Accurately ripped as in pressing(s) #2 Offsetted by 360: 01 [ca909530] (05/178) Accurately ripped as in pressing(s) #7 02 [e6ada2b0] (05/182) Accurately ripped as in pressing(s) #7 03 [b37ba9fa] (05/183) Accurately ripped as in pressing(s) #7 04 [a755eb32] (04/181) Accurately ripped as in pressing(s) #7 05 [f6692f99] (05/173) Accurately ripped as in pressing(s) #6 06 [947c5ea6] (05/182) Accurately ripped as in pressing(s) #7 07 [2071c714] (05/175) Accurately ripped as in pressing(s) #6 08 [fb83c29a] (05/179) Accurately ripped as in pressing(s) #7 09 [b94556e7] (05/170) Accurately ripped as in pressing(s) #6 10 [582ee285] (05/177) Accurately ripped as in pressing(s) #7 11 [a7004203] (05/177) Accurately ripped as in pressing(s) #7 12 [b4e6ef42] (05/174) Accurately ripped as in pressing(s) #7 13 [ff7a729c] (04/172) Accurately ripped as in pressing(s) #7 14 [9b8a06fd] (04/169) Accurately ripped as in pressing(s) #7 15 [47df0eda] (05/166) Accurately ripped as in pressing(s) #7 16 [e74318bf] (05/159) Accurately ripped as in pressing(s) #7 17 [3690db18] (05/156) Accurately ripped as in pressing(s) #6 18 [8499f161] (05/157) Accurately ripped as in pressing(s) #7 Offsetted by 414: 01 [5def00ce] (09/178) Accurately ripped as in pressing(s) #6 02 [3bfe5b6c] (08/182) Accurately ripped as in pressing(s) #5 03 [31569190] (08/183) Accurately ripped as in pressing(s) #6 04 [a5992150] (08/181) Accurately ripped as in pressing(s) #6 05 [f485b75b] (08/173) Accurately ripped as in pressing(s) #5 06 [520d6aac] (08/182) Accurately ripped as in pressing(s) #5 07 [c7931d86] (08/175) Accurately ripped as in pressing(s) #5 08 [0607935a] (08/179) Accurately ripped as in pressing(s) #6 09 [f7821f0d] (07/170) Accurately ripped as in pressing(s) #5 10 [8ef78f39] (08/177) Accurately ripped as in pressing(s) #5 11 [210267f3] (08/177) Accurately ripped as in pressing(s) #6 12 [61318ade] (08/174) Accurately ripped as in pressing(s) #6 13 [fc786bbc] (08/172) Accurately ripped as in pressing(s) #6 14 [325811b1] (07/169) Accurately ripped as in pressing(s) #6 15 [65d1ea20] (07/166) Accurately ripped as in pressing(s) #6 16 [d8718c91] (08/159) Accurately ripped as in pressing(s) #6 17 [b6395ab2] (07/156) Accurately ripped as in pressing(s) #7 18 [92ef8f59] (08/157) Accurately ripped as in pressing(s) #6 Offsetted by 2087: 01 [aee5c493] (05/178) Accurately ripped as in pressing(s) #4 02 [c813d336] (04/182) Accurately ripped as in pressing(s) #8 03 [aa2526a9] (05/183) Accurately ripped as in pressing(s) #4 04 [5cce66d5] (04/181) Accurately ripped as in pressing(s) #4 05 [db328426] (04/173) Accurately ripped as in pressing(s) #7 06 [80bc5f2d] (05/182) Accurately ripped as in pressing(s) #8 07 [cd5e5619] (05/175) Accurately ripped as in pressing(s) #7 08 [3417db7a] (06/179) Accurately ripped as in pressing(s) #4 09 [c6d3c03e] (04/170) Accurately ripped as in pressing(s) #7 10 [daeb6c57] (05/177) Accurately ripped as in pressing(s) #8 11 [a761679b] (06/177) Accurately ripped as in pressing(s) #4 12 [99da3078] (06/174) Accurately ripped as in pressing(s) #4 13 [1a8a37ec] (06/172) Accurately ripped as in pressing(s) #4 14 [00b953cf] (06/169) Accurately ripped as in pressing(s) #4 15 [2b998681] (04/166) Accurately ripped as in pressing(s) #4 16 [f23c6c17] (05/159) Accurately ripped as in pressing(s) #4 17 [252172ae] (04/156) Accurately ripped as in pressing(s) #4 18 [4f09bbad] (03/157) Accurately ripped as in pressing(s) #4

**acmodeu** » 23.10.2008, 22:49

2baralgin, во-первых, спасибо за такую классную примочку, пользуюсь при необходимости. Мне одно непонятно - чего такого она сует в лог, что он становится такого большого размера? Поясню на примере. Открываю виндовым блокнотом лог, полученный твоей проверялкой (размер файла у меня получился 1946 байт), выделяю все, копирую в буфер, закрываю файл. Создаю новый текстовой файл и опять открываю его блокнотом. Вставляю содержимое буфера, сохраняю, выхожу. В итоге получаю новый текстовой файл размером 973! байта. %)

**baralgin** » 23.10.2008, 23:04

2acmodeu В менюшках есть выбор кодировки ansi - тогда он будет такой же маленький. По умолчанию там utf8(в последней версии), хотя самым прожорливым тут есть utf16. Сохранение в utf8 или utf16 позволит открыть такой файл на любом компьютере. А ansi только там где системная локаль такая же как и язык в файле. К примеру если в логе будут имена файлов с русскими именами, то такой файл будет выглядеть "кракозябрами" на компьютетере американца(например). А так проблем не будет ни у кого. Так что рекомендуемый формат это utf8, но если размер критичен(неужели? :) ), то добавляем в параметры программы "--lenc 1" и получаем по умолчанию ansi.

Господа, а что за цифры после решётки в логе CueTools? Я заметил неприятную особенность что треки с одним смещением могут находится в разных "пакетах"(из даты скачанной с базы) - вот же там завернули %) .