Наверное, многие сталкивались с ситуацией, когда тот или иной раритет очень долго ищется в сети, и, когда наконец находится, оказывается хромым на обе ноги. У мну такое случилось с ранним альбомом Тори Амос "Y Kant Tori Read". Я его нашел только в потрековых SHN, нарезанных Аудиокаталистом, без какого-либо сопровождения в виде куй и лог файлов. Естественно, радость по поводу находки омрачалась ее форматом, и возникло желание сделать хоть что-то, приближающее ее к нормальному виду...

И тут я вспомнил, что когда-то где-то видел цитату, где упоминался CUE Master - программка, которая по DiscID ищет запись во FreeDB и экспортирует эту инфу в куй-файл. Решил поглядеть, что за зверь...

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

Исходя из предположения, что оригинальный релизер все-таки не совсем пропащий человек и гэпы прилеплены в конце каждого трека, я слепил их в единый образ и сэкспортил получившийся куй через ЕАС. После этого стал смотреть, какие из результатов поиска более-менее совпадают по длине альбома. Нашел всего лишь два, которые отличались на 2 секунды - остальные были куда дальше.

Втянул и сэкспортил инфу через CUE Master (записи относились к мп3-грабам альбома - ну и что? мне-то сам звук не нужен) - после этого сравнил получившиеся куй-файлы с тем, что слеплен в ЕАС. Тайминги Index 01 совпали до долей секунды, а двухсекундная разница, оказывается, возникла из-за прегэпа в начале альбома.

Получившийся в результате всего этого шаманства куй я выправил руками, проставил недостающие информационные тэги и вычистил очапатки в названиях. Теперь думаю в качестве завершающего штриха перекроить этот релиз в единый образ с помощью CueTools на основе рекомендаций топика с душевным названием "Как делать правильные релизы из педрятины", упаковать в контейнер wv.iso.wv и положить номером первым в готовящуюся дискографию Тори...

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

Caker, куй может быть ты востановил на 100%, но ведь логов не было. Тут важнее не правильный куй, а правильный рип! :drag:

Да я понимаю :) Но с качеством рипа ничего не поделаешь - что есть, то есть. Это редкое издание, и счастье, что он есть хоть какой-то.

Зато плохой рип с нормальным куем всё лучче чем плохой рип совсем без куя - если, конечно, куй нормальный :rolleyes: А явных огрехов на слух там нет, я его уже раза три прогнал на колонках и в наушниках...

Люди. Объясните плиз, какое тайное знание я не улавливаю, плюя на "подисково/потраково" методы? Я понимаю, image+cue это стандарт здесь. Но все же?
Вот, допустим, "хороший" рип, все одним куском. Я его в фубаре конверчу в flac потраково. Так и слушаю/храню. Заметим, что обратно (в один большой flac or wv) я спокойно могу тем же фубаром закатать 1:1.

Вы прожигаете болванки? Но и тогда можно паузу между треками нулевую ставить... Вобщем, я что-то пропустил.

Несмотря на неправильный граб самого аудио, я хочу получить куй с правильными таймингами. Поэтому генерация фубаром, ЕАС-ом или голыми руками не катит.

Да, лога нет, и граб останется хромым - но все же чуть-чуть менее хромым, чем был. Лично для меня это достаточная причина для экспериментирования :)

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

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

Повторюсь, речь сейчас не о том - а о степени достоверности куя, сымпортированного из данных FreeDB через CUE Master.

В частности, есть один момент, который меня смущает. Почему-то все полученные таким макаром куй-файлы у мну выходят с прегэпом. То ли мне везет на альбомы с прегэпом, то ли что-то не так работает... Надо будет позже вечером поэкспериментировать с живыми дисками и данными о них во FreeDB - если к ним найдутся совпадающие Disc ID...

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

куй из данных от фриидб можно нагенерить тут http://www.regeert.nl/cuesheet/

Сегодня наконец-то созрел проверить, к чему приводят описанные выше методы. Сделал три подхода к снаряду.

Подход 1. Живой диск, проверенный AccurateRip-ом на аутентичность. Dire Straits - Love Over Gold.

Контрольный (родной) куй сгенерен ЕАС-ом. Прегэп 0.32 секунды.
Восстановленный куй (импорт из freedb) лепит прегэп 2.32 сек. Реальная длина сграбленного аудиофайла 41:12:87. Восстановленный куй утверждает, что длина - 41:14:00.

Вывод: восстановленный куй врет?

Подход 2. Релиз единым образом с родным куем, Pink Floyd - Best Ballads (взято с торрентс.ру).

Контрольный куй утверждает, что прегэп - 0.30 секунды.
Восстановленный куй указывает, что прегэп 2.30 сек. При этом исходный аудиофайл имеет реальную длину 71:28:72. Восстановленный куй утверждает, что длина аудио 71:30:00. Если допустить, что Cue Master отсекает сотые доли секунды при выводе инфы о длине трека, опять получаем разницу в 2 секунды. Аудиоспектр первого трека не показывает прегэпа в теле записи.

Вывод: опять восстановленный куй врет?

Подход 3. Потрековый релиз с родным куем, Saltillo - Ganglion (изначальное происхождение - Oink).

Контрольный куй (полученный через Cue Tools из родного куя, приложенного к релизу) по таймингам совпал с восстановленным куем, все с тем же расхождением: восстановленный куй содержит прегэп на 2 секунды, которого нет в контрольной версии. Судя по аудиоспектру первого трека, прегэп в тело трека не вошел. С оглядкой на приведенные выше результаты, я бы решил, что восстановленный куй врет на привычные 2 секунды, но... меня смущает лог. Лог утверждает, что прегэп таки должен был быть? оригинальный релизер его потерял?

Цитата из лога:

а как куй может утверждать о длительности?

Втянутый из freedb-шной базы куй имеет следующую шапку:

TITLE "Love Over Gold - Remastered - SBM"
PERFORMER "Dire Straits"
REM ** Generated by CueMaster v1.6 **
REM Time : 41:14:00
REM Length: 2474 seconds
REM Year : 1996
REM Genre : Rock
REM DiscID: 4809a805

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

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

Я всё о своём :) Появилось свободное время, пошуршал в сети и нашел еще немного инфы по прегапу перед первым треком. Вроде бы картина начинает проясняться.

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

Пример 1:
Куй:

CODE

TRACK 01 AUDIO     TITLE "..."     PERFORMER "..."     INDEX 01 00:00:00

Лог:

CODE

Track  1     Filename ...     Pre-gap length  0:00:02.32

Пример 2:
Куй:

CODE

TRACK 01 AUDIO     TITLE "..."     PERFORMER "..."     PREGAP 00:00:32     INDEX 01 00:00:00

Лог:

CODE

Track  1     Filename ...     Pre-gap length  0:00:02.42

Теперь несколько найденных цитат:

1)
Orion25 (Нетлаб) пишет:

QUOTE

Проясню ситуацию с последними двумя цифрами в значениях прегапов из лог-файлов потрековых рипов. Там могут быть и сотые доли секунды и фреймы. Зависит от того, установлена ли была при рипе в настойках ЕАС галочка "Display times using frames". Если галочка стояла - последние две цифры - фреймы (1/75 сек.), если не стояла - сотые доли секунды (1/100 сек.) К сожалению, в логе нигде не указывается какой была эта настройка. Поэтому восстановление точной разметки диска с помощью потрекового лога осложняется именно из-за этой неопределённости. Если после точки в одном из значений прегапов присутствует число большее 75, то значит точно время в сотых секунды. Если нет - то точно узнать какой была настройка можно только у того, кто делал рип. Если есть потрековый лог, и точно известно, что в нём значения после точки в сотых секунды, то, чтобы создать правильный куе, эти значения надо перевести во фреймы. Делается это простым умножением этих чисел на 0,75. Результат округляется до целого числа и получается точное значение во фреймах (5 десятых округляется в большую сторону, т.е. например 27,5 округляется до 28). Специально для проверки этого рипал несколько разных дисков в 2 вариантах (потреково с логом с фреймами, потреково с логом с сотыми секунды) и вычислял из лога с сотыми значения прегапов во фреймах. Результаты на 100% совпали с тем, что было в логе с фреймами.

2)
yanosh (ГидрогенАудио) спрашивает:

QUOTE

I've read very old (and some newer) threads about the track1 pregap problem that appears when using the noncompliant mode. In the newest thread I found, Andre said it will be fixed in the next version. I believe that a new version came out since then but I'm not sure there has been any change. Can someone who's more informed update me about what's going on with the issue?

на что Mike_A отвечает:

QUOTE

EAC's default methods for dealing with pregaps when ripping is to "Append gaps to previous track." However, since there is no track before track 1, the track 1 pregap is not ripped using this method. Let me clarify, however, on exactly what the track 1 pregap is and what is lost. All audioCDs must have a 2.00 second gap before track 1. Therefore, EAC will always report a track 1 pregap of at least 2 seconds. This 2 second gap will always consist of silence and is reproduced when any audioCD is burned, whether you use EAC, Nero, CDex, etc. The information that is not ripped, then, is when the track 1 pregap exceeds exactly 2.00 seconds. Most commonly, in this scenerio, a track 1 pregap of 2.33 seconds is common. In this example, it is this .33 seconds that will not be ripped using EAC's default mode. However, all is not lost. In the newer beta versions of EAC, Andre ensured that a "PREGAP" entry would appear in the non-compliant cuesheet. What this does is recreate the full track 1 pregap (the two seconds is standard, and the PREGAP covers the time that exceeds two seconds). Therefore, using a newer version of EAC, you will have a perfect recreation of the original CD structure if you use the cuesheet. There remains a problem still though. EAC simply replaces that additional time with silence, as it was not ripped. About 99.9% of the time, this will be no problem as the original track 1 pregap was silence to begin with. There will be a problem if the original track 1 pregap contained some music data. The way to test this is to use EAC's "Test Gaps on Silence" feature to see if there is actually any musical data in the pregap. If so, another, more detailed method will be needed to reproduce a perfect 1:1 copy if you still wish to rip to several tracks. As a side note, if you use EAC to create an image and a cuesheet based off of that image, then the track 1 pregap issue will be of no concern to you, as it correctly rips this gap and includes it in the cuesheet. Let me know if you have any further questions.

3)
Martin H (ГидрогенАудио):

QUOTE

The PREGAP command can be set on any track wanted and not only the first track. The PREGAP command instructs that a pause are should be made on that specific track and that it should be filled with generated silence and not audio data from an audio file. When e.g. a PREGAP command is set for the first track and with e.g. 32 samples, then that means that after the normal 2 seconds pause area of track one(which always is generated no matter what), then there should additionally be added 32 null samples to the first track's pause area, so this means that track one's pause area is now 2 seconds and 32 samples long instead of only 2 seconds(as it would have been without any PREGAP command present). This is done because those 32 samples aren't ripped from the disc in standard track ripping mode and so to make the CDs length to be exactly the same as the original CD when burned to disc, so that the e.g. correct DISCID can be calculated from the copy, then EAC inserts a PREGAP command into the cuesheet. If ripping to an image instead, then all samples are extracted from the disc, except the first 2 seconds of track one's pause area, which is never ripped or played back, so this means that EAC dosen't need to add a PREGAP command, since those 32 samples have been ripped now and is located at the beginning of the Range rip file and then so instead of setting a PREGAP command for defining track one's pause area to be 2 seconds and 32 samples long, then instead an INDEX 00 of 32 samples of track one is defined of the Range file, and then afterwards INDEX 01 is set for the rest of track one's playing time from the Range file. When having a CD with e.g. 32 samples of INDEX 00 of track one, then it means that track one's pause area is 2 seconds and 32 samples long and not only 32 samples long. The Red Book defines track one's pause area to be between 2 and 3 seconds long. PS: i say pause area instead of pre-gap, because that is the correct terminology for audio CDs, as pre-gap and post-gap are actually meant for data CDs.

***

В принципе, цитаты многое объясняют, и для себя я намотал на ус следующее.

Ранняя версия ЕАС (какая именно, не знаю - но, как правило, в созданных ней куй-файлах не пробивается информационная часть шапки - REM GENRE/REM DATE/REM DISCID/REM COMMENT) при граблении диска в потрековом режиме с нонкомплиант куем (стандарт педры, оинка и иже с ними) прегап перед первым треком отсекала нафик, и если в логе он еще упоминался, то в куе им и не пахло. Поэтому, если диск имел стандартный первый прегап 00:02:00 (80-90% случаев), то все было нормально - INDEX1 00:00:00, и никаких гвоздей. Но если, не дай бог, перед первым треком случалась дополнительная пауза, то она в таком грабе попросту не рипалась и отбрасывалась (о скрытых треках говорить не будем, это другая грустная история :) ).

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

Отсюда мораль:

Пример 1 - куй неправильный. Учитывая лог, должен добавляться прегап. Чтоб определить, какой именно - смотрим остальные прегапы лог-файла (значений выше 0.75 нет - я не написал это в примере, но оно так и есть ;) ). Это раз. Потом: значение 00:00:32 фрейма - одно из самых распространенных для начальной паузы на таких дисках (по крайней мере, я встречал его чаще остальных). Это два. Предполагаем, что у нас не доли секунды, а фреймы. Пишем в потрековый куй прегап 00:00:32, слепливаем все это счастье в единый образ CueTools-ом, смотрим, что вышло с гэпом между 1 и 2 треками. А вышло вот что: INDEX 00 04:16:02 ; INDEX 01 04:18:52. Разница дает 00:02:50. Смотрим лог:

CODE

Track  2     Filename ...     Pre-gap length  0:00:02.50

Дык угадали. Прегап выставлен правильно.

Теперь пример 2. Однако, правильный куй-то ;) Смотрим остальные прегапы лог-файла - есть значения выше 0.75! Значит, сотые доли секунды. В показателе 0:00:02.42 умножаем 42 на 0,75, округляем и имеем наш многострадальный прегап 00:02.32, что и описано в куе строчками PREGAP 00:00:32 ; INDEX 01 00:00:00.

В общем, сейчас мне кажется, что в ситуации разобрался. Будем надеяться, что кто-нибудь из спецов снова все не запутает :)

а вот такой вопрос, если есть правильный потрекоый лог но нет куя, как проще всего его сгенерить?

yury_usa, не уверен, что это можно сделать просто :)

Навскидку - я бы, наверное шел по такому пути:

1) Найти этот диск во freedb (при наличии нескольких версий - определить правильную по составу и длине треков) и посмотреть его DiskID
2) Втянуть и преобразовать куй найденного диска из фриДБ через CueMaster
3) Попытаться определить, в чем указаны цифры после точки в логе (сотые доли секунды или фреймы)
4) Сверить втянутый куй и тайминги лога, при необходимости поправить индексы руками.

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

Кстати, если лога нет, но есть wav и cue, то можно проверить качество рипа с помощью arcue (скрипт на perl и на C - исходники и binary). Arcue проверяет рип, используя базу AccurateRip. Мне таким образом удалось удостовериться, что пара релизов сделанных кем-то в режиме burst, были сделаны без ошибок.

QUOTE (Caker @ 19-02-2008, 23:36)

...многие релизы в излюбленном буржуйскими трекерами потрековом грабе с non-compliant куем имеют противоречащие (или вроде бы противоречащие) друг другу лог и куй-файлы. Пример 2: Куй: CODE   TRACK 01 AUDIO     TITLE "..."     PERFORMER "..."     PREGAP 00:00:32     INDEX 01 00:00:00 Лог: CODE Track  1     Filename ...     Pre-gap length  0:00:02.42 ...

неа, все ОК. когда прегап перед первой песней стандартные две секунды, EAC их в куй не прописывает. когда больше, пишет насколько больше этих двух секунд.
тьфу ты блин, не дочитал. ты все и сам отлично объяснил. :)
чето сегодня все вкривь: смотрю на лог из первого примера, а куй из фторого. :lol: срочно спать.

Люди! Может кто объяснит, я наверно туплю или не так понял.. Как получить pre-gaps?
Для теста использовал диск, в котором есть пре-гапы, которые я в ручную удалил из CUE файла, сэмулировал CUE в Alcohol 120% и попытался определить пре-гапы, и EAC говорит что никаких пре-гапов нет. Как заставить определить эти пре-гапы? Или это невозможно?
Естественно, если пре-гапы из CUE не удалять, и так сэмулировать, то ЕАС все находит.

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