вот ещё задачка из серии "тут бы ИИ не помешал..":
Имеем звуковой файл (легатная нота одной известной струнной библиотеки) - нужно объяснить программе, как в рилтайме измерить время от начала миди ноты до условного пика получаемого аудио-звука. Сам звук непростой, с нарастающей атакой - поэтому за синхрометку его скорее следует принимать момент первого максимального пика громкости. При этом имеем в виду, что таких звуков измерить надо тонну, они могут быть разной громкости. Поэтому не хотелось бы сравнивать звуки с неким общим порогом - хочется мерить их внутри себя, сравнивая относительные точки огибающей, чтобы тихие звуки не нужно было нормализовать перед измерением. Поэтому, к примеру, берём за основу такой алгоритм: сравниваем в рилтайме поступающую громкость со звука, если она больше значения, записанного в буфер, тригерим таймер ("найден пик") и записываем новое значение в буфер. Т.е., пока громкость нарастает, мы каждый момент времени засекаем время "вот, сейчас достигнут пик, меряем время". А когда значения поступают такие же или меньше, то не тригерим. Таким образом мы имеем время, прошедшее с момента начала замера, до времени максимального пика сигнала любой громкости, пусть он даже - 55 дБ. По сути это алгоритм Peak-hold индикаторов уровня. Но вот тут задача усложняется тем, что разные звуки могут иметь разные огибающие, и первый пик может быть не максимальным в рамках всего звука. И тут программе надо отличить - какой пик считать начальным и таймстемпом, а какой уже является продолжением звука.. И вот тут следствие зашло в тупик) кроме как выставить гейт "пики возможны в течении только n-го количества первых миллисекунд" ничего не придумал. Но так можно ошибиться, если, например, если я этот гейт выставил на 200мс, а у сигнала пик прозойдёт на 230 мс..