[ksv198 0]

Добрый день!

Есть проблема с реализацией VAD (Voice Activity Detection).

Пытаюсь реализовать на stm32f4xx; входной поток имеет умеренные параметры: 8000 Гц частота дискретизации/ 16 бит /моно (обычный не сжатый PCM).

Сам сигнал имеет ограничение по полосе 0 - 4000 Гц (речь), спектр реального сигнала смотрел в Audacity.

При применении наиболее распространённых критериев ZCD (zero crossing detector) и STE (short time energy) получается много (недопустимо) ложных

срабатываний. Сработку вызывает, например, дыхание в микрофон, шум ветра. Кроме того, критерий ZCD довольно слабо отражает наличие/отсутствие речи.

Как обрабатываю: поток принимается в буфер на 512 сэмплов (буферов несколько), режется на фреймы по 8 мс (64 сэмпла, впрочем пробовал и по 16 мс -128 сэмплов,

результаты очень мало отличаются), затем считаю количество пересечений нуля и энергию. Пробовал с прямоугольным окном и окном Хэммминга, разница не очень ощутима.

Вопрос собственно в чём - какой ещё способ (критерий) применить для VAD, для улучшения распознаваемости речи/паузы?

Сигнал сам по себе не зашумлён, SNR больше 20 дБ.

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

перекрывающиеся на полфрейма, что лучше? Вычислительных ресурсов вроде бы хватает, могу безболезненно выделить до 15% процессорного времени контроллера (168 МГц).

[FatRobot 0]

Может взять готовый? Например из G.729 annex B. Там, я помню, был какой-то навороченный перечень условий для срабатывания. Слабо себе представляю, как его построить самостоятельно.

[ksv198 0]

Может взять готовый? Например из G.729 annex B. Там, я помню, был какой-то навороченный перечень условий для срабатывания. Слабо себе представляю, как его построить самостоятельно.

 

Да уже подумывал об этом. А насколько он прожорлив, сколько процессорного времени ему надо, памяти, есть информация?

[FatRobot 0]

Стандарту 20 лет как-никак. Так что особой прожорливости ожидать не стоит. Я думаю, что в 4-6 mips вы уложитесь при аккуратной реализации.

 

Референсные исходники и тестовые векторы есть на сайте ITU. Ваша задача:

- выбросить из кодера все, что не относится к VAD.

- заменить компилируемую библиотеку операций с фикс. точкой на "родные" операции и функции вашего целевого процессора.

 

Да уже подумывал об этом. А насколько он прожорлив, сколько процессорного времени ему надо, памяти, есть информация?

[ksv198 0]

Стандарту 20 лет как-никак. Так что особой прожорливости ожидать не стоит. Я думаю, что в 4-6 mips вы уложитесь при аккуратной реализации.

 

Референсные исходники и тестовые векторы есть на сайте ITU. Ваша задача:

- выбросить из кодера все, что не относится к VAD.

- заменить компилируемую библиотеку операций с фикс. точкой на "родные" операции и функции вашего целевого процессора.

Спасибо, исходники смотрю уже, попробую, что получится.

[FatRobot 0]

Тогда уж посмотрите еще VAD из кодека gsm amr-2:

 

When deployed on a custom DSP running at a clock speed of 1.28 MHz and consuming less than 1 milliWatt of power, the low-resource VAD uses less than 30% of the available system resources. Т.е. совсем копейки по ресурсам.

 

Для AMR будет еще проще отцепить VAD от кодека. Исходники (flp, fxp) для 2х вариантов VAD, а также векторы есть на сайте 3gpp

 

При таких ресурсах можно использовать все 3 варианта VAD одновременно с мажорированием решений.

 

Успехов.

 

Спасибо, исходники смотрю уже, попробую, что получится.