Алгоритмы машинного слуха в контексте развития современной ИТ-инфраструктуры

3. Классификация решаемой задачи. Исходя из описания проблемы и бизнес-требований, а также с учетом их приоритизации, необходимо классифицировать решаемую задачу согласно таблице 1, сформированной в главе 1. При этом стоит отметить, что предлагаемое для описанной проблемы решение может быть декомпозировано на несколько типовых задач. Таким образом, третий этап становится заключительным в формировании бизнес-требований к системе.

4. Формирование логической архитектуры. Основываясь на полученных на предыдущих этапах требованиях к системе, необходимо составить логическую архитектуру ИС с использованием минимально необходимых групп архитектур (здесь и далее используется подход к построению архитектуры систем по SEBoK): функциональной, поведенческой и временной [37]. Этот шаг соотносит и таким образом транслирует бизнес-требования и требования пользователей на уровень функциональных требований, давая представление о том, какие функции должны быть реализованы в системе, как устроены информационные потоки и какие сценарии должны быть реализованы.

5. Выделение компонентов ИС. Этот этап призван сгруппировать определенные ранее требования к решению на всех уровнях и с учетом сформированной логической архитектуры выделить отдельные компоненты системы, а также специфические инструменты, необходимые для их реализации. Таким образом, будут извлечены системные требования к программному решению.

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

7. Оценка вариантов и выбор архитектуры информационной системы. Это заключительный этап, который предполагает выбор одного из сформированных на предыдущих шагах варианта построения архитектуры ИТ-инфраструктуры. Разработка информационной системы в современных реалиях требует наличия проектной команды и большого количества специалистов разной направленности, как то системный архитектор, разработчик, аналитик и другие. Построение архитектуры чего бы то ни было, в том числе информационной системы, процесс творческий, специфический и требует всестороннего подхода. По этой причине оценка разработанных вариантов архитектуры информационной системы и принятие окончательного решения в пользу того или иного варианта - действия неуниверсальные и должны приниматься экспертами в условиях конкретного проекта. В рамках же описываемого подхода имеет смысл лишь обозначить те способы и методы оценки предлагаемых архитектур, которые рекомендуется использовать с целью принятия решения о выборе того или иного разработанного варианта.

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

· Быстрота реагирования

· Время задержки

· Пропускная способность (производительность)

· Чувствительность к загрузке (зависимость времени отклика от загрузки)

· Эффективность

· Мощность

· Способность к масштабированию

Данные характеристики информационных систем выделены в соответствии с методологией, предлагаемой Фаулером. Подробно с терминологией выше представленных параметров можно ознакомиться в книге «Архитектура программных приложений» М. Фаулера [38]. Следует отметить, что большую часть параметров системы сложно оценить на этапе разработки архитектуры, так как измерить их можно только на практике. Тем не менее, на ранних этапах планирования разработки все же можно присвоить приоритеты тем или иным параметрам, вынести предположения в адрес части параметров, основываясь на опыте, использованном в других решениях, и, таким образом, определить весовые коэффициенты каждого из параметров оценки.

Второй момент, касающийся оценки вариантов для последующего принятия решения - это непосредственно методика выбора. Сфера ИТ-консалтинга предлагает большое разнообразие методов оценки для принятия решений при выборе программных продуктов, которые могут быть успешно применены и при оценке принятия решения в целом. В рамках данной научной работы предлагаются два широко используемых метода: балльная оценка и экспертно-балльная оценка.

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

3.2 Применение разработанного подхода для задачи построения архитектуры сервиса по подбору музыки под настроение

3.2.1 Описание концепции сервиса по подбору музыки под настроение

Рекомендательные системы давно заняли важное место в индустрии развлечений. Они используются для предложения пользователям контента в многочисленных сервисах, для удержания пользователя и предоставления ему наиболее подходящих материалов. Исследования, проводимые экспертами, показывают значимый прирост количества позитивных реакций от пользователей, которым предлагался контент, подобранный с помощью рекомендательной системы, по сравнению со случайным выбором [40].

Традиционно в рекомендательных системах рассматриваются два подхода:

· Content-based подход подразумевает формирование рекомендации пользователю объектов, похожих по некоторым структурным параметрам на те, которые этот пользователь уже использовал.

· Collaborative Filtering подход использует для рекомендации историю оценок как самого пользователя, так и других пользователей, тем самым строя рекомендацию на основе мнения выделенных категорий пользователей.

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

Если говорить о музыке как о предметной области, то большинство популярных сервисов по подбору песен основаны на втором методе. Тем не менее, в ходе практической части данной работы было найдено большое количество статей и других работ, целью которых также являлась попытка создания рекомендательного сервиса, который бы выдавал предсказания по предпочтениям пользователя, основываясь на структурных характеристиках трека, то есть с использованием content-based подхода [41-50].

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

Суть системы в том, чтобы подбирать пользователю композиции под его настроение. Основная гипотеза, как уже было сказано выше, опирается на желание человека слушать схожие по структуре композиции в условиях того или иного эмоционального состояния [51-52].

В рамках работы над сервисом рассматривается гипотеза, основанная на следующих предположениях:

· Люди склонны выбирать для прослушивания музыкальные композиции, схожие по своему звучанию с теми, которые им уже нравятся;

· Музыкальные предпочтения пользователя могут зависеть от настроения, которое в свою очередь может быть предсказано на основе того, что человек ведет себя схожим образом в том или ином состоянии;

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

3.2.2 Назначение и задачи сервиса

Исходя из описания концепта, очевидно, что назначение сервиса заключается в формировании плейлиста песен, хранящихся в памяти системы, за счет формирования предсказаний в режиме реального времени, основанных на том, в каком настроении находится пользователь. При этом с помощью сформированных предсказаний, система изучает пользователя и распознает его паттерны поведения. Это значит, что система должна осуществлять работу в режиме реального времени, хранить большой объем данных, быть доступной большому количеству пользователей.

3.2.3 Классификация решаемой задачи

Обращаясь к сформулированной ранее классификации задач машинного слуха (таблица 1), можно выявить типовые задачи, входящие в состав сервиса. В данном случае, речь идет о двух типовых задачах направления Music Recognition, которые можно выделить в результате декомпозиции назначения и задач сервиса: распознавание верхнеуровневых признаков трека и поиск аналогичного трека. Исходя из ограничений выявленных типов задач, а также концепции и назначения сервиса, необходимо учесть следующую совокупность бизнес-требований:

· система должна работать в режиме реального времени

· должно быть обеспечено хранение большого количества данных

· сервисом пользуется большое количество людей

· треки для сервиса должны содержать минимальное количество шума/не содержать его вообще

· система обрабатывает большой объем данных единовременно

· система должна выдерживать высокую нагрузку

· высокая надежность сервиса

· сервис использует алгоритмы машинного слуха (метода акустических отпечатков, обертонового ряда, машинное обучение)

3.2.4 Построение логической архитектуры

Согласно методологии, описанной SEBoK, выделим функциональную, поведенческую и временную архитектуру для разрабатываемого сервиса.

Функциональную и временную архитектуру удобно представить вместе в виде таблицы (таблица 3).

Таблица 3. Функциональная и временная архитектура сервиса

Функциональная архитектура	Временная архитектура
Выделение физических параметров трека	Каждый раз при загрузке новой композиции в систему
Классификация треков, содержащихся в базе данных сервиса	Ежемесячно при условии добавления новых композиций в базу данных в течение периода
Определение паттернов поведения пользователя и формирование кластеров его настроений	Регулярно при каждом использовании
Формирование плейлиста	Регулярно при каждом использовании
Идентификация пользователя	Регистрация - единожды, авторизация - регулярно

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

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

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

1. Кластеризация базы треков

2. Формирование профилей пользователей (информация о любимых/ не любимых композициях).

3. Выбор одного из кластеров для поиска наилучшей песни (песен).

4. Выбор следующей песни (песен) для рекомендации из кластера

3.2.5 Компоненты информационной системы

Исходя из задачи, поставленной перед проектируемой информационной системой, выделяется ряд компонентов, необходимых для ее решения (рис. 8).

Рисунок 8. Компоненты сервиса по подбору музыки под настроение

1. Компонент «клиент» (client) включает в себя пользовательский интерфейс (UI), посредством которого пользователь взаимодействует с системой;

2. Компонент «сервер» (server) включает в себя:

a. API, который выполняет роль связующего компонента-маршрутизатора клиентской и серверной части;

b. Хранилище данных, которое содержит информацию о пользователях системы, их предпочтениях, а также коллекции музыкальных композиций и различных их характеристик, составляющих огромный объем данных;

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

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

3.2.6 Соотнесение ограничений задач и групп требований к сервису с требованиями к ИТ-инфраструктуре

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

Таблица 4. Соотнесение ограничений и требований задачи с моделями клиент-серверного взаимодействия

	«Толстый» клиент	«Тонкий» клиент	Смешанный клиент
Система должна работать в режиме реального времени	Да, безотносительно других пользователей	Да	Да
Должно быть обеспечено хранение большого количества данных	Нет	Да, но не локально	Да
Сервисом пользуется большое количество людей	Нет	Да	Да
Треки для сервиса должны содержать минимальное количество шума/не содержать его вообще	Не имеет значения	Не имеет значения	Не имеет значения
Система обрабатывает большой объем данных единовременно	Только при условии высоких аппаратных возможностей	Да	Да
Система должна выдерживать высокую нагрузку	Только при условии высоких аппаратных возможностей	Да, нагрузка на стороне сервера	Да, часть вычислений распределяется между компонентами ИТ-инфраструктуры
Высокая надежность сервиса	Низкая, так как затруднены	Средняя	Высокая, так как часть данных и вычислений может храниться/ производиться на стороне клиента
Сервис использует алгоритмы машинного слуха	Только для мощных устройств конечных пользователей	Да, вычисления на сервере	Да, могут быть использованы распределенные вычисления

3.2.7 Оценка вариантов и выбор архитектуры системы

В рамках проекта разработки сервиса по подбору музыки под настроение было принято решение провести оценку с помощью балльного метода. Результаты оценки представлены в таблице 5: веса присваивались параметрам системы исходя из его значимости и приоритета в рамках решения поставленной задачи. Оценки выставлялись на основе степени соответствия типа модели параметру по шкале от 1 до 3.

Таблица 5. Оценка и сравнение вариантов архитектур

	Вес параметра	«Толстый» клиент	«Тонкий» клиент	Смешанный клиент
Быстрота реагирования	0,15	3	2	2
Время задержки	0,13	3	1	2
Пропускная способность	0,18	1	3	3
Чувствительность к загрузке	0,14	3	2	2
Эффективность	0,12	2	2	3
Мощность	0,2	1	3	3
Способность к масштабированию	0,08	1	3	2
		1,96	2,33	2,5

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

3.3 Разработка сервиса по подбору музыки под настроение на базе выбранного типа архитектуры ИТ-инфраструктуры

Работы по разработке программного приложения велись с учетом принятого решения о построении архитектуры его ИТ-инфраструктуры. В рамках реализации проекта были выполнены следующие этапы:

1. Получение необходимых данных для создания прототипа рекомендательной системы.

В качестве исходного датасета для анализа был выбран набор из 976 популярных композиций.

Для обработки треков была использована библиотека Essentia на C++ с оберткой Python. Для проекта были отобраны следующие признаки треков: bpm, centroid, danceability, dissonance, energy, loudness, strength, key, scale. Также из названия и мета-тегов выделялись name, artist, id.

Алгоритм обработки и преобразования треков выглядит следующим образом: задаются общие параметры для аудиозаписей (длительность 1 фрейма, шаг между началами фреймов, частота дискретизации), затем каждый трек преобразовывается в json-файл с заданными параметрами. Функция MetadataReader из Essentia выделяет мета-теги, привязанные к аудиокомпозиции. Функции MonoLoader и FrameCutter загружают сырые данные из аудиофайла и преобразуют их к моно-виду, а затем нарезают на фрагменты. Далее задаются функции с параметрами и результаты функций записываются в Pool, после чего PoolAggregator получает средние и дисперсию по фреймам. Полученные параметры треков были сохранены в базе данных на сервере.

2. Подготовка тестовых профилей пользователей для последующего анализа работы алгоритма.

Для базовых профилей пользователей были отобраны 100 композиций, которые в большинстве своём должны быть известны большинству. Затем был создан опрос с помощью инструмента Google Forms, включающий список песен, изображения обложек альбомов и исполнителей. Вопросы составлены так, чтобы полученные данные можно было использовать для продолжения исследований прототипа с учетом настроения пользователя. Для каждой композиции предложены несколько вариантов ответа на вопрос «В каком настроении Вы стали бы слушать эту композицию?». С помощью размещения опроса в социальной сети «ВКонтакте» удалось получить более 60 частично или полностью заполненных результатов опроса.

3. Первичная кластеризация треков

В качестве базового алгоритма кластеризации для создания и тестирования прототипа сервиса был выбран простейший алгоритм K-means. Ориентировочный размер кластера установлен в 200 треков (чтобы иметь возможность выдать достаточно большое число треков, но при этом не слишком сильно вырасти в размере), так что тестовый набор композиций разбит на 5 частей.

Выбор кластера следующей композиции в прототипе осуществляется с помощью простой вероятностной модели:

· Ответы пользователя о настроении по каждой песне записываются как значения -1 и +1 (грустное/веселое).

· Для каждого кластера для каждого пользователя рассчитывается сумма известных значений. Если итоговое значение по кластеру отрицательное, оно приравнивается к нулю.

· Пропорционально полученным значениям находится вероятность выбора кластеров. При этом, для каждого кластера существует минимальная вероятность, которая зависит от общего количества песен n, которые оценил пользователь (для количества кластеров m). На текущий момент для этого минимального значения используется формула 0.8/log₂(n+1))/m. Оставшаяся вероятность распределяется пропорционально. Для нового пользователя, про которого ничего не известно или же для пользователя, которому не нравилась большая часть песен кластера, кластер будет выбран полностью случайно.

· В рамках кластера в дальнейшем планируется совершать выбор с помощью формирования средней фиктивной композиции по всем признакам для положительно оцененных песен кластера. Затем от от этой «точки интереса» должны быть найдены ближайшие песни, которые пользователь еще не оценивал. Тем не менее, так как прототип пока не работает со значительным массивом данных, а используемые 976 треков достаточно разнообразны, надеяться на значительное улучшение качество на данном этапе не имеет смысла и внутри кластера применяется случайный выбор.

4. Разработка серверной части прототипа

Первым этапом создания серверной части стало создание базы данных. База данных была создана в СУБД MySQL с помощью сервиса Amazon Web Services (AWS) RDS. В ней хранятся данные опроса, а также все сведения, необходимые для функционирования мобильного API.

Для мобильного API был создан AWS EC2 инстанс на Ubuntu 16.04 LTS, выкуплено доменное имя и настроен веб-сервер Nginx. Также было выполнено пробное развертывание с использованием тестового приложения, по итогам которого также был настроено соединение с приложением с использованием uWSGI.

Мобильный API разработан на языке Python с использованием фреймворка Django с расширением Django REST Framework. Построенный API соответствует архитектуре REST. На данный момент методами API реализовано управление пользователями и подбор следующей песни, в том числе включая реакцию пользователя на предыдущую.

5. Разработка клиентской части тестового прототипа

Клиентское приложение построено на основе WPF с использованием языка C# и паттерна MVVM. Дорожная карта проекта предполагает дальнейшее построение интерфейса с использованием Unity. В последнем для разработки приложений используется язык C#, поэтому создание WPF-приложения является оптимальным: в дальнейшем мы сможем использовать наши наработки при создании полноценного клиента.

В клиенте реализован следующий функционал:

· управление пользователями (вход, выход, регистрация);

· подбор композиции в соответствии с имеющимися данными о пользователе;

· учет мнения пользователя относительно текущей композиции и подбор новой.

Заключение

В результате проведенного в рамках данной работы исследования были выполнены следующие задачи:

1. Изучена область машинного слуха, представлены основные существующие решения и подходы в области разработки алгоритмов машинного слуха, а также проанализированы сферы деятельности человека, в которых может быть использована данная технология. Результатом решения этой задачи стала сводная таблица с выделенными основными задачами машинного слуха и соответствующими ограничениями, которые эти задачи накладывают на автоматизированное решение;

2. Изучено и проанализировано понятие ИТ-инфраструктуры, а также существующие паттерны и подходы к разработке архитектуры программных решений с акцентом на клиент-серверном взаимодействии. В результате выделены сильные и слабые стороны каждой из модели и приведен практический пример взаимосвязи между развитием ИТ-инфраструктуры и технологией машинного слуха;

3. Наконец, сформирован и применен на практике подход к построению архитектуры информационной системы, использующей алгоритмы машинного слуха, с оглядкой на тип решаемой задачи.

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

Результаты исследования дают основания полагать, что использование алгоритмов машинного слуха действительно специфично влияет на построение архитектуры программных решений, в частности когда речь идет о выборе инструментов решения поставленной задачи. Это значит, что дальнейшее развитие данной темы дает возможность сформировать более четкое понимание о взаимосвязи новых технологий и ИТ-инфраструктуры, которая лежит в основе их поддержки.

Список литературы

1 Jamack P.J., Jamack P.J. Big Data business intelligence analytics //IBM developer Works Technical library. - 2012. -

2 Jacobson K. et al. Music personalization at spotify //Proceedings of the 10th ACM Conference on Recommender Systems. - ACM, 2016. - С. 373-373.

3 Nevatia R. Machine perception //Prentice-hall, inc., Englewood Cliffs, NJ 07632, 1982, 209. - 1982.

4 Turk M. Perceptive media: machine perception and human computer interaction //Chinese journal of computers-chinese edition-. - 2000. - Т. 23. - №. 12. - С. 1235-1244.

5 Panetta C.K. Top trends in the Gartner Hype Cycle for emerging technologies. 2017 //Enterprises should explain the business potential of blockchain, artificial intelligence and augmented reality. - 2017.

6 NeuroNet / Национальная Технологическая Инициатива.

7 Ясницкий Л.Н. Введение в искусственный интеллект. - Академия, 2008.

8 Artificial Intelligence: A Modern Approach / Berkeley, University of California.

9 Lyon R. F. Machine hearing: An emerging field [exploratory dsp] //Ieee signal processing magazine. - 2010. - Т. 27. - №. 5. - С. 131-139.

10 Государство инвестирует в технологию «машинного слуха» / Ведомости.

11 Wang A. et al. An Industrial Strength Audio Search Algorithm //Ismir. - 2003. - Т. 2003. - С. 7-13.

12 Архитектура и алгоритмы индексации аудиозаписей / Блог ВКонтакте.

13 Wang A. The Shazam music recognition service //Communications of the ACM. - 2006. - Т. 49. - №. 8. - С. 44-48.

14 Распознавание речи / Национальная библиотека им. Н.Э. Баумана.

15 Как устроена Алиса. Лекция Яндекса / Блог Яндекс.

16 Chachada S., Kuo C.C. J. Environmental sound recognition: A survey //APSIPA Transactions on Signal and Information Processing. - 2014. - Т. 3.

17 Piczak K.J. Environmental sound classification with convolutional neural networks //Machine Learning for Signal Processing (MLSP), 2015 IEEE 25th International Workshop on. - IEEE, 2015. - С. 1-6.

18 Aytar Y., Vondrick C., Torralba A. Soundnet: Learning sound representations from unlabeled video //Advances in Neural Information Processing Systems. - 2016. - С. 892-900.

19 Ma X., Fellbaum C., Cook P.R. SoundNet: investigating a language composed of environmental sounds //Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. - ACM, 2010. - С. 1945-1954.

20 Алиев Р.М. Автоматическое распознавание нот в музыкальном сигнале на основе преобразования Фурье и вейвлет-анализа. - 2011.

21 Howe M. Pandora's Music Recommender //A Case Study, I. - 2009. - С. 1-6.

22 Wang Y., Metze F. A transfer learning based feature extractor for polyphonic sound event detection using connectionist temporal classification //Proceedings of Interspeech, ISCA. - 2017. - С. 3097-3101.

23 Siegel J.E. et al. Air filter particulate loading detection using smartphone audio and optimized ensemble classification //Engineering Applications of Artificial Intelligence. - 2017. - Т. 66. - С. 104-112.

24 Zhou B. et al. Learning deep features for scene recognition using places database //Advances in neural information processing systems. - 2014. - С. 487-495.

25 Wang J.C. et al. Robust environmental sound recognition with fast noise suppression for home automation //IEEE Transactions on Automation Science and Engineering. - 2015. - Т. 12. - №. 4. - С. 1235-1242.

26 Sigtia S. et al. Automatic environmental sound recognition: Performance versus computational cost //IEEE/ACM Transactions on Audio, Speech, and Language Processing. - 2016. - Т. 24. - №. 11. - С. 2096-2107.

27 Voice biometrics for Intelligence Service / STC.

28 Laan S. IT Infrastructure Architecture-Infrastructure Building Blocks and Concepts Third Edition. - Lulu.com, 2017.

29 McAffer J., Lemieux J.M., Aniszczyk C. Eclipse rich client platform. - Addison-Wesley Professional, 2010.

30 Schmidt B.K., Lam M.S., Northcutt J.D. The interactive performance of SLIM: a stateless, thin-client architecture //ACM SIGOPS Operating Systems Review. - ACM, 1999. - Т. 33. - №. 5. - С. 32-47.

31 Stojmenovic I., Wen S. The fog computing paradigm: Scenarios and security issues //Computer Science and Information Systems (FedCSIS), 2014 Federated Conference on. - IEEE, 2014. - С. 1-8.

32 Pinola M. Speech recognition through the decades: How we ended up with siri //Web log post. TechHive. IDGTechNetwork. - 2011. - Т. 2.

33 Juang B.H., Rabiner L.R. Automatic speech recognition-a brief history of the technology development //Georgia Institute of Technology. Atlanta Rutgers University and the University of California. Santa Barbara. - 2005. - Т. 1. - С. 67.

34 Audrey: The First Speech RecognitionSystem // Asta Speaks.

35 Apple introduces us to Siri, the Killer Patent // Patently Apple.

36 Hey Siri: An On-device DNN-powered Voice Trigger for Apple's Personal Assistant / Machine Learning Journal.

37 Pyster A. et al. Guide to the systems engineering body of knowledge (SEBoK) v. 1.0. 1 //Guide to the Systems Engineering Body of Knowledge (SEBoK). - 2012.

38 Фаулер М. Архитектура корпоративных приложений: пер. с англ //М.: Издательский дом Вильямс. - 2006.

39 Карл В. Разработка требований к программному обеспечению/Пер. с англ //М.: Издательско-торговый дом «Русская редакция», 2004. -576 с. - 2004.

40 Bogdanov D. et al. Semantic audio content-based music recommendation and visualization based on user preference examples //Information Processing & Management. - 2013. - Т. 49. - №. 1. - С. 13-33

41 Pontikakis C.T. H.H.M. Waveform-Based Musical Genre Classification.

42 Kosina K. Music genre recognition. - 2002.

43 Creme M., Burlin C., Lenain R. Music Genre Classification. - 2016.

44 Cast J., Schulze C., Fauci A. Music Genre Classification.

45 Haggblade M., Hong Y., Kao K. Music genre classification //Department of Computer Science, Stanford University. - 2011.

46 Lee C.H. et al. Automatic music genre classification based on modulation spectral analysis of spectral and cepstral features //IEEE Transactions on Multimedia. - 2009. - Т. 11. - №. 4. - С. 670-682.

47 Mellon R., Spaeth D., Theis E. Genre Classification Using Graph Representations of Music. - 2014.

48 Francisco M., Kim D.M. Music genre classification and variance comparison on number of genres. / Stanford University, Tech. Rep., 2013.

49 Nagathil A., Gerkmann T., Martin R. Musical genre classification based on a highly-resolved cepstral modulation spectrum //Signal Processing Conference, 2010 18th European. - IEEE, 2010. - С. 462-466.

50 Tzanetakis G., Cook P. Musical genre classification of audio signals //IEEE Transactions on speech and audio processing. - 2002. - Т. 10. - №. 5. - С. 293-302.

51 Audio Music Mood Classification / Mirex Wiki -- 2010.

52 Nuzzolo М. Music Mood Classification // Michael Nuzzolo. -- Electrical and Computer Engineering Design Handbook, 2015.

Размещено на Allbest.ru

...