Обработка и Анализ Аудио-сигнала в Скриптах

EUGEN27771

Well-Known Member
23 Апр 2010
2.293
2.799
113
Тема рассчитана на любые скрипты, касающиеся обработки и анализа аудио. Это самая интересная тема в сфере скриптов. Здесь есть действительно серьезные задачи и решения - все, что можно понять - выкладывайте . Что нельзя понять - тоже выкладывайте, потом поймем, все будет полезно.
Надеюсь, что это не зря, по крайней мере, свои мысли я здесь точно буду выкладывать - это может помочь кому-то в дальнейшем. Хочется, чтобы дело не пропало зря. Хотя мне пофиг - я в скриптах завис надолго.
 
Последнее редактирование:
Вот, что у меня есть, пока что, касательно обработки аудио:
Vox-Deess Enveloper.lua
SampleEditor.lua
WAVE Generator.lua
Drum trigger.lua
Create stretch-markers at transients.eel
Envelope-based Compressor.eel

Некоторые демо здесь.
++++++++++++++++
Это Михаила скрипты, что нашел, у него еще есть, добавлю:
mpl_Align takes
mpl_Generate MIDICC from audio take
++++++++++++++++
spk77
Manipulate take volume envelope
 
Последнее редактирование:
Вот штука хорошая, но недопиленная. И в Риапаке вроде бы её нет. Со стерео итемами никак не пашет. Идеал -- конечно же, комбайн, с возможностью тонкой настройки.

Ваш Vox-Dess ваш очень удобен.

А вообще да, обработка аудио скриптами - классная тема, есть у меня пара идей для приборов.
 

Вложения

  • Manipulate take vol env3.gif
    Manipulate take vol env3.gif
    1,6 MB · Просмотры: 200
  • Like
Реакции: Buyan
детектор темпа композиции с построением точного темпотрека )
думается полезнее сделать не с нуля, а с уже несколькими примерно подогнанными вчерне/вручную темпомаркерами и проставленными изменениями размера.
Этакий "fine tuning" )
т.к. в рипере и так можно в риалтайме темп проставлять, если быстро нажимать на кнопки. Иногда можно и скорости добавить)
 
@EUGEN27771, это я в качестве идеи реализации) а не в плане сиюминутного требования такого плага.
По мне, удобнее вручную) но "доделать" может и скрипт.

Кстати, ещё идеи плагов для рипера, можно и js:
1) счётчик клипинга (считать количество "клиппов" и их длительность в семплах, можно в строку через запятую выводить длительность каждого), такое бывает в некоторых DAW на уровне интерфейса.
2) в рипере появился отличный встроенный oscilloscope, но у него не хватает режима BPM-synced (пример), было бы очень удобно с ним.
3) интересная весчь Spectral Phase Correlation Meter.
4) ещё от той же компании Мulti-band Phase Correlation Meter.

спасибо за внимание
 
Вот штука хорошая, но недопиленная.
Точно, добавил.
Ваш Vox-Dess ваш очень удобен.
Когда доделаю это триггер - за него тоже возьмусь.
[DOUBLEPOST=1470061965][/DOUBLEPOST]
А вообще да, обработка аудио скриптами - классная тема, есть у меня пара идей для приборов.
Давайте идеи, на то и тема
детектор темпа композиции с построением точного темпотрека )
Это не так просто, как может показаться, особенно на разном материале, но нужно попробовать.
@Alx_g, пока не могу попробовать, нет времени. У меня есть полурабочий вариант beat detection - он находит точки более-менее, но их надо как-то отсортировать, проанализировать, выбросить промежуточные и т.п. Как один из вариантов - предоставить пользователю возможность удалять неверные точки
==========
Добавил в Drum trigg возможность коррекции velocity
Drum to MIDI(Move,Change velo)1.gif
Shift - коррекция позиции
Ctrl - коррекция velocity
Shift+Ctrl - одновременно позиции и velocity
==========
velocity scaling(min-max) скоро добавлю.
Также добавлю возможность выбора аудио-канала для анализа(левый-правый, сейчас только левый) - там пару минут дела.
==========
Возможно добавлю - сплит по маркерам, создание стретч-маркеров по маркерам - это путь к квантайзу аудио.
Возможно, но по опции и по настроению, добавлю сетку - но она загромождает вид.
 
Последнее редактирование:
@basЫl, так у меня есть тестовый, самый простой, правда, без зумов и т.п.:
это я к тому как BPM считать, но нужен графанализ насчет точности. На хабре вроде статейки пробегали. Причем как раз не нужно гигантских окон FFT.
А потом тупо делим на количество семплов, и на Fs, - вот и BPM
 
  • Like
Реакции: EUGEN27771
Причем как раз не нужно гигантских окон FFT.
Я говорю не о том, что есть здесь, а том, что у меня есть в виде экспериментов - поэтому, может быть путаница.
@basЫl, гигантских нет - каждой задаче - свои окна. У меня несколько научных статей лежит, с реально работающими алгоритмами, везде нужны свои окна.
В detection beat я вообще пока не трогал FFT - там обычный фильтр.
В любом случае, спасибо за мысли, и спасибо за проявленный интерес, мало кто в эту сторону смотрит.
 
Добавил вчера ручную коррекцию велосити.
Показал маме - она дала исчерпывающую характеристику - никому, говорит, твое пьяное изделие не нужно.
Хотя это самое крутое, что из скриптов существует вообще. По графике и внутри, в принципе.
То что оно свелось в несколько строк в итоге - это же месяц экспериментов.
============
Посмотрите на spk77 скрипт по огибающим - это даже не смешно, это печаль, и тп.
У меня бы это работало раз в 10 быстрее.
Мне нужна ручная корекция велосити + рандомность + выбор миди контрол каналов + гибкость
 
@EUGEN27771, очень нужно, огромное тебе спасибище за твой труд!
З.Ы. И совсем оно не пьяное))) В смысле, совершенно не важно, в каком состоянии ты его делал, результат - бомба.
 
Посмотрите на spk77 скрипт по огибающим - это даже не смешно, это печаль, и тп.
У меня бы это работало раз в 10 быстрее.

По факту у spk77 вполне рабочий скрипт, которым пользуются люди, а не абстрактные бета-тестеры с рмм. "Если бы да как бы" - это не рабочее решение.

Хотя это самое крутое, что из скриптов существует вообще. По графике и внутри, в принципе

На рмм тебе поверят, ага.
 
Парни, хорош кусаться, что за фигня??? Два самых продвинутых скрипртописателя - и на тебе, сцепились... На вас весь РММ смотрит, кочумайте.
P. S. Завтра почищу.
 
  • Like
Реакции: Aliko
Удаляю все, что не по делу.
Удалил, получилось теперь будто я не прав, ну да ладно.
Я нашел способ ответить проще и без всяких зацепок - мы продолжаем делать то, что делали.
Здесь выкладываем, а люди уже пусть дают оценку.
И по скорости, и по графике, и по всему остальному.
 
Последнее редактирование:
  • Like
Реакции: diggidon
Да я и не собирался кусаться (и что было под моим комментом тоже не видел, видимо, там что-то было).

Просто зачем начинать всю эту демагогию "могу сделать быстрее", "мы обо всём этом и так знали". Можешь - делай.

Форум превращается в утопическую песочницу. После нащупывания достаточно годной идеи для скрипта и её полной или частичной реализации мы, начиная что-то улучшать/дополнять, задаём вопросы вида "а кому-то это вообще нужно?". Скорость и графика - это так кого-то волнует? Бери gfx.blit() и зумь/скролль сколько влезет. Сэкономим аж целых n секунд. В призме того, что твой скрипт экономит минуты-часы, это ничтожное улучшение для конечного юзера. Про графику я вообще молчу. Сам рисую градиенты всякие чисто для себя, чтобы приятно было. Не думаю, что есть смысл кичиться этим и вообще акцентировать на это внимание.
 
Последнее редактирование:
и что было под моим комментом тоже не видел, видимо, там что-то было
Да не было там ничего плохого вообще, более того, было только хорошее. И Ваш скрипт по выравниванию тейков я упомянул в первую очередь, как наиболее сложный внутри. По скрипту spk77, возможно, слишком эмоционально высказался в целом... без него не было бы других. Я не сомневаюсь в его возможностях, видимо, просто оставил как есть и делает новое. В любом случае, прошу извинить. И еще пару лишних сообщений удалил и собрал по спойлеры более-менее важное.
Бери gfx.blit() и зумь/скролль сколько влезет
А это, может быть, интересно именно технически, и именно по текущей теме - в последних версиях не использовался gfx.blit() для зума и скролла, потому что простое растягивание на больших участках дает потерю точности на уровень зума при работе с аудио. Поэтому, не столько в визульном плане и по времени улучшение, а именно при использовании, для точности коррекции. Мне показалось это важным...
 
Последнее редактирование:
Странная дискуссия @@Michael......
Скорость работы и качество графики очень важны. Если скрипт тормозит, а по графике ни черта не разобрать - юзабильность скрипта снижается до пары интузиастов.
А "кичиться" в общем-то есть смысл всем, что сам считаешь важным достижением для самого себя. Только термин выбран не верный, тем более в отношении Евгения...
На сколько я могу судить со стороны, ни он ни ты ни чем не кичитесь, а безвозмездно делитесь..... А в такой вот ситуации, для многих, не знаю как для тебя Михаил, важна ответная реакция пользователей, понимание, что всё это хоть кому-то нужно. Мотивация всё же должна быть и внешняя, не только собственное желание что-то познавать новое.
 
Скорость работы и качество графики очень важны
В ReaScript графика - это бонус. Ни о какой скорости/юзабельности не может быть и речи, мы не в Си каком-нибудь шуруем интерфейс. Тормоза тут будут всегда, и с этим ничего не поделаешь, учитывая способ прорисовки, как не оптимизируй.
 
@@Michael, тем ни менее я вижу ОЧЕНЬ серьёзный прогресс скорости прорисовки и ее качества в скриптах Жени.
 
Мне лично пофиг сколько уходит на отрисовку у драммтриггера, он и так крут. Меня пока напрягает лишь ограничение в 47 сек.
 
@Oliver_Cray, добавил, сейчас 180 с, в принципе, теперь можно любое время сделать. Но ограничение оставил, потому что на 180 сек уже сильные тормоза. Попутно добавлен выбор канала.
 
Последнее редактирование:
  • Like
Реакции: Oliver_Cray
десь есть действительно серьезные задачи и решения - все, что можно понять - выкладывайте . Что нельзя понять - тоже выкладывайте, потом поймем, все будет полезно.
@EUGEN27771, Как говорится простите мой французский, но хотел бы спросить такие скрипты как например "MIDI-harmony from Audio" или "Audio items statistic compare" или "Spectro suggestion on Audio items analysis" вас не заинтересуют в плане создания?). Выполнить такое могу только выходя из Рипера, а вот внутри было бы супер. Так можно и дойти до полновесного Аудиоредактора (ну это я размечтался, но все же..). Интересно над чем работаете сейчас. Успехов и спасибо за все что уже сделано, дай вам Бог здоровья!
 
@RJ Baker,
"MIDI-harmony from Audio" - это очень сложно, для меня по крайней мере, и требует очень много времени, я же не программист - и не для скриптов это.
"Audio items statistic compare" - такое я видел на кокосовском форуме, то ли у Heda, то ли у spk77.
Спектро-анализатор можно сделать, но их и так валом.
Интересно над чем работаете сейчас
Пока времени не было вообще что-либо делать, немного освободится - надо доделать этот триггер, переделать диессер и разгрести хлам, там можно уже что-то подумать.
Успехов и спасибо за все что уже сделано, дай вам Бог здоровья!
Спасибо, Вам тоже удачи, здоровья!
 
Так, обновил скрипт, ссылка та же.
Мелкая инструкция:
В первую очередь нужно выбрать трек и установить выделение(time selection).
На треке, в области выделения, может находится несколько айтемов, но желательно, чтобы это все-таки был один айтем.
=============
Get Selection - это основная кнопка для захвата аудио с трека.
HP - LP - настройки фильтра, это понятно - hight Pass - low Pass. Для дальнейшего анализа используется то, что попало в диапазон между ними.
Input 1-2 - это используемый канал - левый-правый.
Out Gain - уровень выходного сигнала(с фильтра).
=============
Threshold - порог гейта, ниже которого аудио не анализируется.
Sensetive - разница между быстрой и медленной огибающей, в дБ, это немного неверно, но зато понятно.
Чем ниже значение - тем выше чувствительность, тем больше точек будет создано.
Retrig - время, которое гейт будет неактивен после срабатывания. Проше говоря, минимальное время между точками.
Reduce Points - удаляет "слабые" точки.
Detect Velo - время детектирования уровня для расчета велосити. По идее, большие значения дадут более точный результат.
Но это не всегда.
Все значения между собой очень сильно связаны и влияют друг на друга.
=============
RMS - Peak - определяет, как будут вычисляться значения велосити. Время расчета = Detect Velo.
Create MIDI - создает миди, в зависимости от настроек(нота, канал, длина ноты).
Velo Scale - масштабирует велосити в зависимости от настроек, интересная игрушка.
Самая интересная настройка - та, что под кнопкой миди - третья, Use selected item.
Все изменения на выделенном айтеме происходят автоматически, любые настройки учитывается и пересоздают выбранную ноту на выделенном айтеме.
При этом, воспроизведение можно не останавливать, то есть слушать, что получается, если на миди-треке висит инструмент.
=====================
По скорости. Что бы ни говорилось - мне это важно. Нет никакой возможности что-либо нормально настраивать, когда нет обратной связи.
Без обратной связи можно только предполжить, как все произойдет. И ждать.
До 10 - 15 секунд у меня все работает практически в режиме обратной связи, а на совр. компах будет еще раза в два быстрее.
На длинных участках - уже приходится ждать. Вообще, по-нормальному, можно просто брать участки друг за другом - настройки же остаются те же.
Далее говорю о 180 секундах - довольно большое время.
Попросили, я сделал неограничено по времени. Лимит можно установить в скрипте(time_limit)
И попытался расположить все по порядку - настройки из первой секции(фильтр) работают достаточно медленно.
Кроме гейна - гейн работает средне.
Из второй(гейт) средне, из третьей все - быстро, то есть по отпусканию мыши, моментально.

=====================
По графике.
Колесо мыши - зум по горизонтали.
Shift+Колесо - зум по вертикали.
Midle drag - "перетаскивание"
Shift+drag - на триг-линии - изменение позиции
Ctrl+drag - на триг-линии - изменение велосити
То же самое. Пять секунд наставить точек на нормальной графике, даже вручную.
=====================
== Я пьяный и злой ==
Вот по этому поводу я скажу еще раз, может не совсем корректно, но не могу, это все не так.
Бери gfx.blit() и зумь/скролль сколько влезет. Сэкономим аж целых n секунд.
Растягивать, сжимать буферы - это вообще никакой не вариант.
Ни на кокосе, ни на рмм, даже для абстрактных бета-тестеров не пройдет такой способ. Это не зум, а херня, точно говорю.
А если поставить зум в 1000 - легко же ставится - проверьте на моем варианте - ставьте self.max_Zoom = 1000.
При растягивании на 1000 весь Ваш буфер стал бы 1-2 пиксела. Вот и весь Ваш gfx.blit() - или не так я говорю?
Про скролл я тихонько промолчу - там еще посчитать надо, что куда и при каком зуме уйдет.
Я решил это довольно просто, а в этом и вся суть. Я не кичился, как Вы говорите.
++++++++++++++++
Мне просто это слово не понравилось - "кичился". Какая-то в нем мерзость есть. Если бы только Вы сказали иначе...
 
Может быть, это опять далековато от реально работающих скриптов, но пока было время сделал пару тестов.
Люблю тесты, ничего не поделать. Тесты на разном аудио, не барабаны.
Короче, при определенных настройках легко вылавливаются транзиенты на гитарах, басах, клавишах и т.п.
А если вынести настройки быстрой и медленной огибающих на поверхность(например, в доп. настройки), то вообще очень интересно становится.
Создавая на этой основе стретч-маркеры можно получить квантайз аудио. Для начала. Свинг, user groove и т.п.
Потом можно попытаться сделать выравнивание тейков по транзиентам(не вокальных). Я уверен, что это будет работать.
Просто попробуйте - триггер ищет все - ему пофиг, как это называется, главное, чтобы перепады были.
Легко гитары, басы, клавиши находятся - у меня нет материала разнопланового, но факт, что перечисленное - находится.
 
  • Like
Реакции: RJ Baker
При растягивании на 1000 весь Ваш буфер стал бы 1-2 пиксела. Вот и весь Ваш gfx.blit() - или не так я говорю?
Всё верно, blit загоняет в растр. Не сказал бы, что у тебя всё намного быстрее по сравнению с чем-либо существующим, но да, отрисовывается чётко без шакалов. Я к тому что в твоём сообщении изначальном был акцент на крутость/быстроту прорисовки графики и упрёк в сторону spk77, к слову достаточно умного чувака, хотя в таких вещах лучше сконцентрироваться на конечном результате (юзер ставит твой скрипт чтоб получить мидяху, а не любоваться маркерами на формоволне).

Из быстрого теста:
- трансиенты ищет хорошо, по техчасти вроде всё чисто на разном материале
- 1389: attempt to index a nil value (field '?') при зуме с неоригинальными w/h основного окна
- акцент на окне с формоволной вместо акцента на управлении параметрами, эргономика интерфейса немного страдает из-за этого
- интуитивно не всё ясно по параметрам, кнопка для описания параметров или ссылка на онлайн ресурс с описанием пригодилась б
- в перспективе нужны пресеты/загрузка последних параметров
- опять же если делать расчёт на простоту использования, я бы сделал упрощенный интерфейс с опциональными параметрами, что-то вроде такого
сжатый вид
1.jpg

расширенный
2.jpg
 
  • Like
Реакции: EUGEN27771

Сейчас просматривают