найти аудиоролик в эфире по слепку

По идее спектральный анализ. Окно по эфиру двигаешь, переводишь в частотную область (БПФ), там к амплитуде и матчиш по паттернам. То есть ищешь интересующий сигнал в шуме. Анонимус может ошибаться)

а насколько это ресурсоёмко может быть?

Надо как-то запись эфира заранее готовить, переводя его в частотную область?

Надо готовить патерны. Эфир в режиме реального времяни обрабатывается. Не ресурсоемко. Сигнал можно корреляцией искать для начала. Дальше смотреть на результат - фолсы там или еще что. Такие дела.

на хабре было несколько статей. в частности, поиск рекламного ролика в ФМ-вещании

принцип как у Шазам - БПФ, затем сравнение спектра с эталонными образцами

Да. Готовишь эталон, аппроксимированый до X кгц, Y bit, моно. Потом ищешь аналогичные значения в звуке эфира (ессно ухудшив его теми же значениями). Чем «тупее» такие слепки, тем быстрее будет итти поиск. Но сравнивать придется побайтно набирая кол-во совпадений. Я бы даже выпилил три куска (начало, середину и конец) и все три искал чтобы наверняка. Так можно будет узнать прозвучало ли оно полностью, и с начала ли.

Побайтно не ищут. Смотрят корреляцию. Выставляют порог и этим играют. То есть ищут «похожесть» шаблона с текущим. Малоли помехи итд. Хотя в случае с рекламой - да, можно и побайтно наверное попробовать.

В рекламных блоках отсутствует логотип канала, этого требует закон исключение составляет реклама программ самого канала, тут по политике вещания. Так вырезают рекламные блоки, в таком массиве уже проще искать нужный ролик

Если будет такая работа - есть шанс поучаствовать?

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

Job мониторить или контакт скинуть?

Про корреляционную функцию правильно сказали. В реальном времени можно хранить эфир в кольцевом буфере размером с искомый кусок+1 секунда, и раз в секунду считать корреляцию между буфером и образцом (существует алгоритм быстрой корреляции на основе БПФ). Ресурсов много не потребуется.

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

У тебя может и не совпасть. Предположим у нас эфир идет по сети с одной частотой дискретизации, шаблоны сделаны по сэмплам с такой же. Например на отсчете окна спектра [8] шаблона (не важно к какой частоте он будет относиться) имеем значение 23. В окне спектра на отсчете [8] имеем 22. Пропускаем и двигаем окно? Таким макаром можно пропустить детект. И что даст «ужимание»? Ты можешь потерять уникальность спектрального портрета. Но повторюсь, анонимус может ошибаться =)

Я не говорил что они должны 100% совпадать. Студия пускающая ролик в эфир может и пожать звук компрессией, или приглушить/поднять уровень или накрутить эквализацию. Это все повлияет и на спектр и на амплитуды. Я же говорю про анализ амплитуд а не спектра. Где после пожатия (децимации, которая до жопы проста) можно будет сравнивать не 44к, а например, 8к уровней в секундном куске, и значения уровней будут не +/-65к, а +/-255, и набирать «баллы» совпадений (с допустимыми отклонениями от оригинала как ты писал 22 и 23), и, например, при 75% совпадений считать что отпечаток найден.

UPD. Т.е. пожатие таки даже поможет в сравнении т.к. сгладит разницы промежуточных значений.

Хм... Я как раз говорил про амплитуду, когда говорил про [8] - это амплитуда на этой частоте грубо говоря, имел в виду АЧХ в общем. Метод детекта на правилах - не очень удачный. Чую могут костыли вылезти. Ладно, не суть. ТС мы думаю помогли)

мне бы понять, сколько это может занять трудозатрат

Нутк. Отдельная утилита? Консольная? ЯП? ОС? Пайпы? Сокеты? Реалтайм? Можт тупо либа? Я к тому что ты ничего не уточнил, а размах влияет на трудозатраты же.

я честно говоря полагал, что тут самое муторное — это именно алгоритм, а обвязка — процентов 10 работы. Не?

ТЗ запости (выжимку). Как сказали выше - мало инфы. А так с тестами месяца 3-4 для 2 человек. Если нормальный POC только, не продакшн решение.Но это максимум наверное.

да что ты, какое ТЗ =)

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

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

да что ты, какое ТЗ =)

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

Тут даже те кто петрит, и то не делали конкретно этого. У тебя три пути:

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

Стандартно поток нарезается на фреймы фиксированной длины, (длина зависит от конкретного применения), для каждого фрейма рассчитывается набор характеристик в различных доменах (частотной, временной, MFCC там, другие логарифмические), который сравнивается с образцом с помощью определённой(-ых) метрик(и). Конкретные параметры (метрика, набор характеристик и тд) зависят от конкретного случая. Если у вас ролик только один, то можно наверное работать с глобальными характеристиками (образец-фрейм = ролик, фреймы потока имеют длину ролика и перехлёстываются) и самой простой метрикой (тупо L1 норма посэмплово).