Речевой кодек для задачи, поставленной GeGel, Приводятся примеры исходного и сжатого речевым кодеком сигнала Опции

[Милливольт]

Примерно год назад на этом форуме обсуждалась тема разработки "криптофона". Тема называлась "Проброс канала..." Предполагалась возможность создания ЗАС для обычного сотового.
У меня появилось (увы) свободное время, и эта задача не оставляла в покое. Через какое-то время стало понятно, что для ее решения необходим кодек совершенно необычного типа. Я попытался его изготовить на базе собственной гипотезы о формировании акустического сигнала в речевом аппарате.
Результаты первых (весьма несовершенных проб) представлены:
Исходный сигнал 128Кбит/сек - http://exfile.ru/482652
Сигнал после кодирования/декодирования с потоком 0.25 Кбит/сек, (приведенный к 128Кбит/сек после декодирования) здесь: http://exfile.ru/482653 (слышны погрешности интерполяции, но это уже в процессе устранения)
В данном случае поток- динамический, задержка не более 20 мсек, корреляция кластера и посылаемого фрагмента не хуже 0,975 (Пирсон).
Основное отличие от существующих кодеков заключается в том, что индивидуальные характеристики речи абонента изначально (один раз) отправляются в цифровом виде реципиенту. А дальше идет нормальный обмен с низкой скоростью. Это существенный недостаток, т.к. без этих данных на приемном конце будет голос без индивидуальных особенностей, либо чужой.
К достоинствам, как мне кажется, можно отнести работу исключительно во временной области, т.е. тестовая речь "нарезается" на куски-кластеры, они классифицируются, и получается новый "алфавит", который и передается. Приемник собирает сигнал, интерполирует что нужно, и подает на акустический тракт.
А для базовой задачи (криптофона) можно предложить передавать не цифру, а просто перепутанные кластеры. Т.к. в криптографии я понимаю мало, то предполагаю, что тов. Вернам здесь может быть уместен.
Я писал на почту ув. GeGel, но ответа не было. А форум я немножко захламляю в надежде неформальной экспертизы: нужен ли такой кодек, и для чего он может быть применен. Это важно, т.к. из меня программист как из говна пуля, и до реализации в реалтайме, да еще на смартфоновских процессорах, я это дело точно не доведу. А вкладываться фирмой в неоднозначные перспективы - неразумно.

Сообщение отредактировал Милливольт - Sep 21 2016, 11:27

[GeGeL]

Не получал от Вас ничего в последнее время, возможно, спам-бот резал.

Свой проект я более-менее довел до ума:
web: http://torfone.org/pairphone/indexru.html
github: https://github.com/gegel/pairphone
paper (EN): http://torfone.org/download/pp1a_doc.pdf

По наличию времени портирую код в отладку NUCLEO-STM32F446R с цифровой аудио-шиной к GSM-модулю Quectel M66, а пока код собирается gcc (Linux)/mingw(Windows) для PC с двумя аналоговыми аудио-интерфейсами (необходимо дополнительное USB- или Bluetooth- аудио).
Результаты тестирования на реальных GSM-каналах переменчивые. Например, в одном регионе между абонентами Life baseband-сигнал модема проходит отлично (BER=0.2%), а в другом - даже нет синхронизации (на линии включается дополнительное транскодирование, похоже, NB AMR, не смотря на то, что на обоих сторонах определяются GSM FR кодеки). Так что не все так просто, как рисуют китайцы.

Что касается упомянутого выше проекта, я с ним знаком (первая ссылка в моем paper, есть еще похожие работы, в том числе отечественные), но даный подход не может считаться криптографически надежным и по сути является шифрованием "от младшей сестры". Любые престановки имеют весьма малую фактическую длину ключа и позволяют легко восстановить исходный сигнал, имеющий очень четкую статистику для голоса.

Так что проблема надежного модема, пригодного для реальных GSM сжатых каналов, является теоретически сложной и пока открыта. Лично я считаю, что теоретическая оценка дата-емкости сжатого канала по ссылке 15 неверна, и вряд-ли удастся гарантированно надежно передать поток свыше 600bps. Так что вопрос упирается в исходник MELPE-600 или аналогичных по качеству кодеков.