Спасибо за статью. Хочу добавить зачем вообще нужны MFCC.
Как многие знают, алгоритм распознавания — это черный ящик. Что-то на входе, что-то на выходе. На вход идет вектор свойств (feature vector), а на выходе мы получаем решение алгоритма. И в задачах распознавания сложность состоит не самом алгоритме (как было сказано, алгоритмов много и они хорошо изучены), а именно в формировании вектора свойств. Вектор свойств должен быть некоторой фиксированной длины, поэтому напрямую отсчеты сигнала отправить нельзя. К тому же понятно, что по отсчетам напрямую распознать речь очень сложно — варьируется амплитуда, длительность звуков и т.д. Можно было бы отправить в алгоритм спектр. Но тут тоже возникают сложности — частот очень много, по ним сложно отличать звуки, просто каша получается. Кстати, насколько я знаю, в настоящий момент в распознавании речи распространены методы, основанные на вейвлетах, которые характеризуют сигнал и по частоте и по времени.
В общем, теперь вы можете понять, почему были разработаны кепстральные коэффициенты, как некоторый вектор, способный качественно охарактеризовать речь. Кстати, MFCC это лишь один из многих других вариантов feature vector.
Замечания логичны, но прежде чем делать предположения о качестве теста можно было бы перейти по ссылке в посте и прочитать о нем. Что можно было узнать:
— 30 судей
— всего 300 5-минутных переписок
— каждые 5 минут судья общался одновременно с машиной и с человеком
— тест проводился при независимой экспертизе товарища Professor John Barnden, University of Birmingham, formerly head of British AI Society
Вообще про логику в моделях еще в Django Two Scoops (самая крутая книга по джанге на мой взгляд, ссыль) написали, но этож ад!
Приведу пример. Мы разрабатывали CRM, которое обеспечивало все рабочие процессы компании. В кратце, там был прием и обработка заявок со сложной финансовой калькуляцией, а также статистика. Было у нас все «хрестоматийно»: толстые модели с логикой, причем функции логики вызывались прямо из теплейта. Сначала все было ок. Но по мере нарастания функционала начались Содом и Гоморра =)
Во-первых, нельзя передавать параметры в функции в шаблоне (тэги не в счет, они для другого). Во-вторых, постоянный пересчет и вызов этих функций. В-третьих (что оказалось самым страшным), сложная модифицируемость кода — когда нужно было сделать серьезнейшее изменение в калькуляции и формате хранимых данных, дров было наломано неописуемо много!
В итоге, я соглашаюсь с тем, что всю сложную логику нужно выносить в отдельные службы. Ну а в модель выносить то, что касается непосредственно этой модели, вроде get_то, set_се.
Я ничего против автора не имею, но хабр тем и ценен, что статьи в нем отличаются от вопросов на stackoverflow. Формат хабра скорее: «Как я написал парсер», или «Используем requests + lxml для парсинга».
Да да, я полностью согласен. Не обобщал на всех. Java/C# и скриптовые языки — две разных культуры разработчиков.
Тут имеется в виду, неопытный человек использует ide, где все настроено и не требует дополнительных телодвижений. Затем он начинает понимать, что его раздражает, что неоптимально и чего не хватает. И тогда он переходит к текстовым редакторам, чтобы постичь дзен :)
Так как в итоге обстоит дело с профайлингом SQL запросов?
Дебаг тулбар мощный, но с ajax запросами не работает. Один мой товарищ написал специальную тулзу для дебаг-тулбара, чтобы через торнадо их перехватывать и выводить на отдельной странице, но это совсем жестко) к тому же дебаг тулбар использует свой jQuery что очень плохо.
Из альтернатив только Django-live-profiler? Он решает проблему ajax запросов?
У саблайма крутое комьюнити, много активно развивающихся плагинов.
А то, что он стремительно развивается, вполне естественно. Его парадигма — минимум ебли, максимум профита.
Как многие знают, алгоритм распознавания — это черный ящик. Что-то на входе, что-то на выходе. На вход идет вектор свойств (feature vector), а на выходе мы получаем решение алгоритма. И в задачах распознавания сложность состоит не самом алгоритме (как было сказано, алгоритмов много и они хорошо изучены), а именно в формировании вектора свойств. Вектор свойств должен быть некоторой фиксированной длины, поэтому напрямую отсчеты сигнала отправить нельзя. К тому же понятно, что по отсчетам напрямую распознать речь очень сложно — варьируется амплитуда, длительность звуков и т.д. Можно было бы отправить в алгоритм спектр. Но тут тоже возникают сложности — частот очень много, по ним сложно отличать звуки, просто каша получается. Кстати, насколько я знаю, в настоящий момент в распознавании речи распространены методы, основанные на вейвлетах, которые характеризуют сигнал и по частоте и по времени.
В общем, теперь вы можете понять, почему были разработаны кепстральные коэффициенты, как некоторый вектор, способный качественно охарактеризовать речь. Кстати, MFCC это лишь один из многих других вариантов feature vector.
— 30 судей
— всего 300 5-минутных переписок
— каждые 5 минут судья общался одновременно с машиной и с человеком
— тест проводился при независимой экспертизе товарища Professor John Barnden, University of Birmingham, formerly head of British AI Society
Приведу пример. Мы разрабатывали CRM, которое обеспечивало все рабочие процессы компании. В кратце, там был прием и обработка заявок со сложной финансовой калькуляцией, а также статистика. Было у нас все «хрестоматийно»: толстые модели с логикой, причем функции логики вызывались прямо из теплейта. Сначала все было ок. Но по мере нарастания функционала начались Содом и Гоморра =)
Во-первых, нельзя передавать параметры в функции в шаблоне (тэги не в счет, они для другого). Во-вторых, постоянный пересчет и вызов этих функций. В-третьих (что оказалось самым страшным), сложная модифицируемость кода — когда нужно было сделать серьезнейшее изменение в калькуляции и формате хранимых данных, дров было наломано неописуемо много!
В итоге, я соглашаюсь с тем, что всю сложную логику нужно выносить в отдельные службы. Ну а в модель выносить то, что касается непосредственно этой модели, вроде get_то, set_се.
Тут имеется в виду, неопытный человек использует ide, где все настроено и не требует дополнительных телодвижений. Затем он начинает понимать, что его раздражает, что неоптимально и чего не хватает. И тогда он переходит к текстовым редакторам, чтобы постичь дзен :)
github.com/DamnWidget/anaconda
мне кажется, что эволюция часто происходит так: IDE от JetBrains -> Sublime -> vim :)
Дебаг тулбар мощный, но с ajax запросами не работает. Один мой товарищ написал специальную тулзу для дебаг-тулбара, чтобы через торнадо их перехватывать и выводить на отдельной странице, но это совсем жестко) к тому же дебаг тулбар использует свой jQuery что очень плохо.
Из альтернатив только Django-live-profiler? Он решает проблему ajax запросов?
А то, что он стремительно развивается, вполне естественно. Его парадигма — минимум ебли, максимум профита.
А так, настроить под себя можно любой редактор.
А, вы об этом. Ну да, конечно, вероятность ошибки.