Я редко делаю релизы, поэтому не заморачивался. Спасибо за скрипт, возьму на вооружение! На мой взгляд, PARы не следует закатывать в архив, так как мне представляется более логичным PARить на уровне DVD перед прожигом, и хранить PARы отдельно (или даже на том же DVD, но отдельными файлами), тем более что битые музыкальные релизы мне из ослосети не приходили, по-моему, ни разу :D

и я попробую, но предупреждаю - будут вопросы :laugh:

1. А смысл? WAV — это полуфабрикат, а WV/APE/FLAC — готовый релиз.
2. Так автоматом делает EAC. Для WA есть плагин CUE Reader (кажется), который позволяет открывать CUE напрямую.

Там в той ветке (или в другой) как раз и говорилось, что это для того если, скажем, у тебя есть оригинал, но он испорчен (поцарапан, например), а релиз не сохранен. Тогда грабится в WAV с какого есть оригинала, а PAR2 поможет его восстановить.

я поставил от себя дополнительно опцию "-n1", чтоб был один большой PAr-файл, а не 8. Ну не нравится мне когда их много :)

взято из

дело в том, что в твоем Post Link: Софт для создания Релизов ничего о SVF не сказано 8\

SFV это типа CRC32, MD5 и тп - т.е. контрольные суммы считать...

внутри типа

; Generated by WIN-SFV32 v1.0
; (Compatible: Total Commander 6.53)
Who Do We Think We Are (Gold CD).log 536E3979

Всё, что можно было сказать по этому вопросу, уже сказано и оформлено в виде тезисов (июньских, кажется?). Доп.файлы - это хэши и PAR2? Если да, то было бы неплохо на маны по их использованию кинуть, если таковые есть доступно и на русском.. :help:

Спасибо, для себя в основном стараюсь, но и людям помочь не прочь, если, конечно, они того стоят. :)

- svf || md5 меня лично не интересовали. я лишь заметил, что в файле присутствует, а не используется; кроме того, самого экзешника под нее нет и энибади будет смцщен, но об это далее.
- кредиты - это святое, я на них не посягал, только после замены пачей обнаружилось, что и кредиты нужно менять - в твоем посте не отмечено.
- скрипт AS IS - правда, лучше чем нафинг, но на фиг он энибади нужен, если нет полных инструкций как ту ю? я не наезжаю, но подумай о практической стороне своих действий, или цель была найти братьев по командной строке? ;)
- дот.ком или как - каждый точит как хочет, но согласись, что на текущий момент одним движением не сделаешь, а жаль.

передо мной лежит сундук на 200 блинов - дали на две недели. сколько времени у меня займет его заточить? вот практическая проблема:
если начинаешь грабить новый диск в процессе создания md5, то иногда куи запаковываются в чужой рар. это потому, что они берутся не по точному названию, а по маске? ты не можешь подсказать где исправить чтобы в архив шли только свои куи, а не все *.cue?

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

Исходя из расчёт примерно 15-20 минут на диск рассчитай своё время :) Проблема в том, что в скрипт полуавтоматический и в некоторых местах требует участия.

Да, есть такая недоработка. В идеале скрипт должен работать в папке назначения, но пока всё происходит на папку выше. Связано с передаваемыми скрипту параметрами, где путь уже прописан.
Можно попробовать вот так:

В моём случае цель стояла выпускать идеальные во всех отношениях релизы с минимальными усилиями и максимальной автоматизацией процесса. :)

вот о чем я про "одно касание" и говорил :rolleyes: пока я вижу мотивированым только одно место - ожидание кнопки \ок\ в EAC.

кстати, есть такая полезняшка: nnCron homepage - это могучий пускатель по расписанию, а заодно - интерпретатор Форта (язык такой). в общем, сделать на нем "уно батоно" представляется реальным. ;)

*
Помимо традиционной для планировщика способности запускать в указанное время программы, "напоминалки" и открывать документы, nnCron умеет:

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

Второе место - это добавление ReplayGain: пока вообще не поддаётся автоматизации. Третье - визуальная проверка хэшей, тут по идее можно поставить ERRORLEVEL, если декодер их поддерживает.

Ещё одна программа в довесок не катит. Ищу программу для написания макросов с возможностью компиляции макроса в .ехе.

Я не знаю, поддерживает ли EAC Unicode.. Если нет, то существуют 2 решения: поменять локаль для non-Unicode или воспользоваться утилитой от MS (тут где-то обсуждалась).

Фубаргом.. Есть небольшой шанс автоматизировать и это с помощью Automation компонента, но это куча R&D для такой маленькой фичи. Убирать RG не буду, потому что для себя делаю :)

Обновил свои скрипты (и перезалил).
Changelog:

1. Убрал все ненужные паузы, и единственную оставшуюся тоже можно при желании закомментировать.
2. Исправлены ошибки при незаполненной дате в EAC.
3. Добавлены переменные для имени релизера, комментария и URL.
4. Все самые интересные действия в EAC-POST теперь происходят сразу в папке назначения, исключение - лог самого скрипта.
5. Реорганизован порядок и логика EAC-POST.
6. Звуковое оповещение для стадии ожидания и в случае ошибки проверки файла.

LF_ дело ясное, что дело темное..
djet я так понимаю (но это сугубо мое имхо) - если хочется гарантий от ядерного взрыва избыточность надо подбирпть по объему файла + месту на диске (DVD), типа: хочу 20 релизов на одну болванку, есть полгига под пары... _НО_ у этого есть обратная сторона: когда мы храним одну копию, то ... а если две, нужны ли пары вообще?

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

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

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

В lossy пережимать неохота. Кодек подбирать, устраивать себе ABX, сжимать десятки и сотни Гб на конвеере, потом при прослушивании жатого матерьяла мнительно выискивать артефакты.. Нафикк!

Если ты о постпроцессинге в смысле post-enc.cmd, то в новой версии уже не пройдёт: я маппинги многих переменных поменял, и скрипт потерял самостоятельность.
Ещё в той же папке лежит скрипт-прошиватель CUE и LOG: может, пригодится, если нужно будет пакетно серию tagged within релизов наштамповать.

Не хватит. В качестве workaround можно запускать eac-enc со старыми параметрами (пишутся в лог eac-enc.log): кодировщик ругнётся на недоступность файла, но дальше всё должно пойти как обычно. А лучше заранее это проверить на паре дисков.

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

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

в названии директории не соответствует реальности. пары там и ни каких других...

REM: *.jpg конечно хорошо в архивчике иметь, но стоит об этой фиче хотя бы упомянуть.

BTW попробовал я флак - скрипт закончился путем (а должен был как на вавпаке ругнуться на путь к хэшеру, да и лог о верификации бредовый), только файл нормально не читался фубаром. в него новая версия еак пишет кучу REMов, так с первого раза фубар вообще не понял этот куй (из тэга), когда я убрал первые ремы (в начале) и примянил появились последние три-пять имен треков, но остальное все так же безымянное. у меня такая м-мм впервые с флаком, придется искать в архивах старый еак. да, разница по размеру - 13Мб (флак больше на 2.8% чем вавпак) - имхо слезы.

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

Я как раз сейчас думаю, как вынести конфигурируемые настройки в отдельный файл, тогда можно будет ещё много чего добавить: схемы наименования файлов, папок и т.д. Это либо будет ещё один батник, либо .ini, но в последнем с извлечением данных придётся повозиться. Готовых решений никто не встречал?

Я и сам в поисках удобной схемы хранения барахла, не говоря уже о скриптах..

Недоделанная фича и тоже пока в разработке. В раздумьях, куда лучше подкладывать JPG и какая у них должна быть маска имён.

С FLAC он практически не тестировался. Изначально скрипты работали на APE, потом я начал их под себя переделывать. C выбором WV я на данный момент окончательно определился, и если на моём пути не возникнет своенравная железка, с него не сверну :)

а) и какой смысл в такой RG: то, что один альбом будет звучать среднеквадратически одинаково с другим? Мне нужен полноценный RG, т.е. потрековый в т.ч.
б) незначительное преимущество, а с учётом автоматизации в скрипте - вообще никакое. У меня проверка осуществляется в стратегически важном месте - после всех пертурбаций с файлом. (Для WV у меня есть комбинированный скрипт - см. мою тему про WV).
в) постараюсь, когда доведу до ума единый файл настроек для скриптов.