Управляем Linux-десктопом с помощью голосовых команд
Вчера я рассказывал о том, как научить свой Linux-десктоп проговаривать различную информацию, сегодня я хочу несколько расширить начатую тему и рассказать о системах распознования речи, с помощью которых можно научить машину понимать простые голосовые команды.
Чтобы научить Linux понимать проговариваемые слова, применяются системы распознавания речи (CMU), наиболее известная и работоспособная из которых носит имя Sphinx. Разработкой этого движка занимается университет Карнеги-Меллона, хотя отдельные доработки также производили сотрудники Массачусетского технологического института и корпорация Sun Microsystems. Качество распознавания «Сфинкса» еще далеко от идеала, он постоянно дает сбои и совершенно не способен разобрать слитную речь. Однако его возможностей вполне достаточно для организации системы исполнения простых голосовых команд, что и демонстрируют такие проекты, как Gnome Voice Control и PerlBox.
Альтернатива Sphinx — движок Julius японского происхождения. По качеству распознавания Julius не уступает Sphinx, однако имеет два изъяна: а) отсутствие хорошей акустической модели для английского языка (для русского более-менее нормальной нет и для Sphinx), что означает гораздо более низкое качество распознавания (в конце статьи я расскажу, как обойти эту проблему), и б) он использует внешний движок генерации акустической модели (обучения) HTK, разрабатываемый под руководством Microsoft в Кэмбридже (а это значит, что движок хоть и открыт, но использовать его можно только в личных целях).
Для систем синтеза существует масса различных оберток, упрощающих использование. Для Sphinx это уже не развиваемый PerlBox и созданный в рамках Google Summer Of Code апплет для среды Gnome под названием Gnome Voice Control. Отличная графическая оболочка для Julius — программа Simon, написанная с использованием библиотеки Qt4.
Пингвин! Лежать!
Перед тем, как перейти к установке и настройке системы распознавания речи следует уяснить, что ни один из открытых движков, будь то Sphinx, Julius или какой-то менее известный проект, не способен на 100% верно разобрать речь, даже если она будет принадлежать актеру с хорошо поставленным голосом. Однако при правильной тренировке программы (которая также включает в себя и подгонку под особенности произношения конкретного человека) ее вполне можно научить корректно распознавать простые двух-словные команды почти в 100% случаев.
И вот здесь нас ждет очень неприятный сюрприз: наиболее известная и распространенная CMU Sphinx (которая, кстати, имеет целых четыре параллельно развиваемых версии, одна из которых написана на Java) до сих пор находится в стадии «вечной альфы», пользоваться которой (не говоря уже о тренировке) обычному пользователю довольно затруднительно. Существует, конечно, утилита Gnome Voice Control, существенно упрощающая процесс общения с программой, но работает она только в Gnome. Поэтому мы воспользуемся Julius, который хоть и имеет некоторые проблемы, но очень прост в использовании.
Julius есть в репозиториях многих дистрибутивов, поэтому его не придется собирать из исходников. В Ubuntu для установки достаточно выполнить команду:
Чтобы научить Julius понимать английский язык, понадобятся файлы акустической модели, содержащие статистическое представление звуков, которые может воспринимать движок. Акустическая модель строится путем обработки звуковых файлов (с начитанными человеком фрагментами текстов) специальными программами (например, из пакета HTK). Наиболее правильно самому наговорить эти фрагменты и, таким образом, научить движок распознавать свой голос (в том числе, интонацию и ошибки произношения) и словосочетания, которые нужны именно вам. Тогда процент правильного распознавания будет стремиться к значению 100. Однако все это сложно, требует определенной подготовки и времени, поэтому пока мы ограничимся акустической моделью, распространяемой с сайта www.voxforge.org. Для этого надо установить пакет julius-voxforge:
Теперь можно приступить к настройке, которая фактически включает в себя только процесс создания словаря: списка слов, который должен уметь распознавать движок, и объяснение того, как эти слова могут между собой сопоставляться. Нужно это для двух целей: во-первых, движок должен знать произношение слов и понимать их, а во-вторых, сократив словарь всего до нескольких фраз, мы значительно повысим качество распознавания. Для простоты возьмем стандартные словари, распространяемые вместе с пакетом julius-voxforge:
Просмотрев файл sample.voca, вы заметите, что он содержит совсем небольшой список слов, таких как call, get, dial и т.д., а также их фонетическое представление (что-то вроде транскрипции), файл sample.grammar содержит правила, в каких комбинациях эти слова могут быть использованы. Не беспокойтесь, если он кажется непонятным, это нормально :).
Попробуем изменить файлы так, чтобы подогнать их под нашу задачу, которой будет… допустим, управление аудиоплеером. Итак, откройте файл sample.voca и добавьте в него следующее (удалив прежнее содержимое):
В файл sample.grammar поместите строку:
Все это значит, что движок должен понимать словосочетания, которые состоят из: тишина (NS_B), слов «do» (ID), «play», «next», «prev» или «silence» (COMMAND), тишина (NS_E). Говоря проще, вы можешь сказать «Do play», и машина вас поймет, в то время как слова «Hello World» будут для него инопланетным языком. Хорошая особенность короткого словаря в том, что, даже если вы скажете что-то вроде «Du pray», движок, скорее всего, распознает это как «Do play», а не как-нибудь иначе (в английском десятки и сотни слов звучат почти одинаково).
Теперь, не выходя из каталога, выполните команду для генерации файлов sample.dfa sample.term и sample.dict:
Это все. Можете протестировать julius с помощью команды:
После появления строки » >>» начинайте говорить определенные выше фразы. Чтобы движок правильно их понял, говорите слитно, как это делают англоговорящие (голоса которых и были использованы для создания акустической модели voxforge), без перерыва между словами. При таком способе произношения движок работает на удивление хорошо, лично у меня ни одного сбоя на 10 фраз. Если вы полуте худшие результаты, стоит поработать над произношением и купить хороший микрофон.
Конечно, пока от программы мало толку, поэтому мы должны создать Dialog manager, то есть, программу (скрипт), которая будет отвечать за перевод голосовых команд в команды на исполнение. К счастью, сделать это просто, достаточно прицепить на выход Julius стандартный ввод скрипта, который будет обрабатывать печатаемые программой фразы. Например, скрипт для управления audacious на языке python может выглядеть так:
Сохраните его под именем command.py и запускайте julius следующим образом:
Интернет телефония — это выгодный и современный способ общения без использования традиционных телефонных линий. SIP-телефония позволит вам увеличить число исходящих линий, расширить количество внутренних номеров, пользоваться конференцсвязью, а также записывать телефонные разговоры.
Источник
Pocketsphinx. Распознавание речи и голосовое управление в Linux
— Всё в порядке, Лёня?
Динамики отрегулированы на максимум, я морщусь, отвечаю:
— Да. Тише звук.
— Звук — тише, — соглашается «Виндоус-Хоум», — тише, тише…
— Хватит, Вика
С.Лукьяненко, «Лабиринт отражений»
Введение
В данной статье я не буду касаться Julius, поскольку гайдов по его использованию (в том числе и в Рунете) хватает. Речь будет идти о CMU Sphinx.
Описание и установка
Не забудьте после установки выполнить:
Для работы с /dev/dsp установим согласно FAQ пакет oss-compat.
Базовое использование
/sphinx.
Синтаксис нашей команды таков:
-argflie: имя файла в текущей директории, содержащего все аргументы.
stderr для удобства перенаправим в файл.
Содержимое argfile:
-hmm: путь к каталогу, содержащему файлы акустической модели (шаблоны отдельных звуков).
-lm: путь к файлу триграммной языковой модели (можете почитать здесь).
-dict: путь к файлу словаря произношения.
-cepdir: путь к каталогу со звуковыми файлами. Будьте внимательны: если вы вносите -cepdir в файл аргументов, то сокращенный путь
/sphinx обрабатывается неправильно: приходится писать полный путь. Если вы будете прописывать аргумент после команды, то можете использовать сокращенный путь.
-ctl: файл с именами обрабатываемых файлов. Файл goforward.raw мы возьмем из комплекта исходников pocketsphinx (там есть еще пару файлов *.raw — можете распознать и их).
-cepext: расширение обрабатываемых файлов
-adcin: указатель принадлежности обрабатываемого файла к raw.
-hyp: имя файла, в который будет выведен распознанный текст.
Аргументы с путями к файлам моделей указывать обязательно. Помните, что многие параметры заданы по умолчанию (смотрите stderr). Поэтому для работы с файлом *.raw необходимо принудительно указать расширение, иначе будет использован параметр по умолчанию — расширение .mfc (а таких файлов у нас в базовом примере, естественно, нету — будут сыпаться ошибки).
В результате исполнения у нас в файле outname будет следующее содержимое:
Параллельно можете посмотреть, откомпилировать и запустить в каталоге с файлом goforward.raw программку аналогичного назначения на C (пример от разработчиков).
Для проверки на своих примерах я решил не мудрствовать и воспользовался sox (проверьте, установлен ли этот пакет у вас).
Писать звук будем следующим образом (можете почитать man sox ):
— для raw
Окончание записи по Ctrl+C .
У меня sox при этом ругался на невозможность использования частоты дискретизации: can’t set sample rate 16000; using 48000 . Учтите: нагло лжет — на самом деле все в порядке.
Я писал и распознавал raw и wav на различных примерах из подключенных словарей — все распознавалось вполне приемлимо.
Адаптация звуковой модели
Скачиваем по первой ссылке предлагаемые файлы в отдельную директорию, в которой и будем работать.
Теперь надиктуем предложения из файла arctic20.txt по образцу: у вас должно получиться двадцать файлов, названных по порядку согласно схеме arctic_0001.wav . arctic_0020.wav .
Чтобы упростить запись, воспользуемся предложенным скриптом:
Соответственно, чтобы прослушать полученное, выполним:
Скопируем акустическую модель (с которой мы и работали) из /usr/local/share/pocketsphinx/model/hmm/en_US/hub4wsj_sc_8k в нашу рабочую директорию.
Теперь создадим файлы акустических особенностей (напоминаю: работаем в директории с файлами *.wav).
В результате получаем файлы *.mfc.
Скачиваем экстра-пак (89,0 МБ); файл под названием mixture_weights из него, расположенный в pocketsphinx-extra/model/hmm/en_US/hub4_wsj_sc_3s_8k.cd_semi_5000 помещаем в каталог с акустической моделью.
Также необходимо конвертировать mdef-файл акустической модели в текстовый формат:
Теперь, согласно терминологии гайда по адаптации, соберем накопленные данные. Скопируем утилиту bw из /usr/local/libexec/sphinxtrain/bw в рабочий каталог (перед этим не забудьте установить sphinxtrain!).
Запускаем и видим:
SYSTEM_ERROR: «corpus.c», line 339: Unable to open arctic20.fileids for reading: No such file or directory
Очевидно, правая рука у разработчиков не ведает, что творит левая (про неактуальность части документации я уже не говорю).
Переименовываем в рабочем каталоге файл arctic20.listoffiles в arctic20.fileids
Теперь все работает.
Произведем MLLR-адаптацию (эффективна для ограниченного объема данных в модели):
Эта команда создаст файл адаптационных данных mllr_matrix .
Теперь при распознавании с адаптированной моделью можно добавлять параметр -mllr /path/to/mllr_matrix .
Параллельно произведем другой метод адаптации: MAP.
Сделаем копию модели:
И произведем MAP-адаптацию:
Теперь создадим sendump файл, отличающийся меньшим размером:
Тестирование адаптации
Проверяем (помните, что адаптация не приведет к стопроцентно верному результату: адаптированные модели будут точно так же ошибаться; плюс в том, что они будут делать это реже. Мои вполне наглядные записи были сделаны далеко не с первой попытки: было достаточно записей, где ошибались все модели):
1. Распознавание с помощью базовой модели:
2. Распознавание с помощью модели с MLLR-адаптацией: при указании параметром -mllr пути к моей матрице происходила ошибка сегментирования (копаться я не стал). При распознавании без этой опции результат полностью идентичен результату оригинальной модели.
Впрочем, в мануале заявлено, что MLLR-адаптация лучше всего подходит для непрерывной модели (т.е. для Sphinx4).
3. Распознавание с помощью модели с MAP-адаптацией:
Как можно убедиться, результат полностью идентичен записи. Адаптация реально работает!
Русский язык в Pocketsphinx
Скачаем отсюда русские модели, созданные на voxforge. На разнообразие моделей можно посмотреть здесь и просто в интернетах.
Реализовывать пример голосового управления компьютером мы будем на русском, а значит нам нужны собственная языковая модель и собственный словарь (вероятнее всего, части наших слов в распространенных примерах не будет).
Создание собственной статической языковой модели
Далее создаем словарный файл:
Создаем языковую модель в arpa-формате:
И создаем DMP-модель.
Создание собственного словаря
Тащим с гитхаба утилиты:
Переходим в каталог ./yourdir/text2dict и создаем там текстовый файл my_dictionary с вашим списком слов (каждое новое слово — с нового абзаца).
И вот ваш словарь создан.
Теперь пробуем распознавать слова, присутствующие в словаре (благо, в нашем примере их немного). Не забудьте указать в аргументах собственную языковую модель и словарь — все должно работать. При желании можно произвести адаптацию акустической модели (сразу предупреждаю: при использовании утилиты bw в процессе адаптации для большинства акустических моделей опция -svspec не нужна ).
Использование JavaScript Grammar File вместо статической языковой модели
«|» обозначает условие выбора. Т.е. мы можем сказать «тише» или «закрыть окно». Правда, по сравнению с использованием языковой модели есть один минус: говорить нужно гораздо членораздельнее.
Созданный jsgf-файл указываем с параметром -jsgf (параметр -lm в таком случае не нужен).
Реализация голосового управления
Моей целью не было реализовать крутой интерфейс управления: здесь все будет очень примитивно (если есть желание и возможность, можете посмотреть на заброшенный проект Gnome Voice Control).
Действовать будем следующим образом:
1. Пишем команду, распознаем её.
2. Передаем распознанный текст в файл, в соответствии с ним выполняем команду.
В качестве тестовых команд будем использовать уменьшение и увеличение громкости звука.
Внимательно почитав мануал к sox, я решил оканчивать запись по истечении секунды тишины с порогом тишины в 3.8% (порог явно является сугубо индивидуальным значением и зависит от вашего микрофона и окружающей обстановки).
К сожалению, я не нашел в pocketsphinx_batch параметр вывода только для распознанных слов, поэтому я воспользуюсь инструментом sed :
Эта конструкция удалит из строки вида «наша команда (audio -4023)» пробел перед открывающей скобкой, её саму и все последующее содержимое. В результате мы получим строку вида «наша команда», что нам и нужно.
Вот сам скрипт:
Скрипт в ответ на команды «тише» или «громче» выполняет соответствующие действия с сигнализацией через notify-send.
К сожалению, работать он будет только при запуске из терминала (иначе звук не пишется). Впрочем, представление о голосовом управлении он дает (возможно, вы предложите лучший метод).
Источник
