Вот тут ищут специалиста

[Jury Gerasimov]

Всем привет,

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

Начало переадресованного сообщения:

 Определения:

Сообщение – некоторая информация, будь то речь, файлы, отдельные цифры или буквы

Источник – отправитель сообщения

Получатель – пункт назначения сообщения, получатель сообщения

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

Кодирование – преобразование сообщения из аналоговой формы в цифровую или из цифровой в аналоговую. Алгоритм кодирования определяет качество кодирования, а также определяет алгоритм декодирования

Декодирование – преобразование, обратное кодированию

Транскодирование – замена одного алгоритма  кодирования на другой в пределах одной формы (то есть сообщение было кодировано из аналоговой формы в цифровую с применением алгоритма aLaw, например, затем сообщение было транскодировано (преобразовано) в цифровое же, но с применением алгоритма uLaw, например)

 

Условия: Источник речевого сообщения в сети связи №1 и Получатель речевого сообщения в сети связи №2

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

В нашем случае необходимо передать (внедрить) в речь не более 64 байт информации. И гарантировать, что на стороне Получателя эта информация будет извлечена без ошибок в 100 случаях из 100.

Еще один пример – DTMF-коды («нажмите ноль или дождитесь ответа оператора» - всем известный пример передачи DTMF-команд). Но длительность DTMF-команды велика – около 300 мсек на команду. Передача 64 команд займет значительное время и что самое неприятное, не гарантирует совпадение переданной здесь и там принятой команды. Гарантии нет из-за того, что в современных комбинированных сетях в процессе передачи речи (а DTMF передается в речевом потоке) выполняется многократное транскодирование, которое вносит погрешность и иногда приводит к невосстановимым ошибкам на стороне получателя.

 

Особенность цифровых сетей связи в том, что речь, воспринимаемая телефонной трубкой, сначала выглядит как напряжение, модулированное звуковой волной. АЦП измеряет амплитуды этого сигнала с частотой 8000 Гц. Каждая секунда речи разбивается на 50 фрагментов (фреймов). Каждый фрейм содержит в себе 160 измерений амплитуды. Эти данные – набор чисел – кодируются, например, алгоритмом aLaw или более современным Speex. Фактически при кодировании 160 чисел с плавающей точкой «сжимаются» до 160 байт. Фреймы по 160 байт передаются от Источника к Получателю через комбинированную сеть, где в процессе транспортировки через сеть могут неоднократно подвергаться декодированию/кодированию, а также транскодированию. При этом на слух возникшие в процессе передачи искажения на стороне Получателя не воспринимаются нами и мы слышим собеседника как будто он рядом.

Однако, есть 2 неприятные вещи:

- при передаче фреймов через сеть сама сеть вносит ошибку в содержимое фрейма (например, из-за транскодирования)

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

 

Учитывая все эти обстоятельства, мы хотим реализовать такой механизм (программный код), который позволил бы на стороне Источника внедрить в каждый фрейм (или не каждый) некий «кусок» информации, которую мы хотим передать Получателю (64 байта) и при этом гарантировать, что на стороне Получателя информация будет восстановлена из фреймов в первозданном виде. При этом мы не должны затратить на это времени более 2,5 сек (то есть использовать 120-125 фреймов). Мы также можем (но это не желательно) позволить себе использовать первые 120 фреймов сообщения только для передачи нужной нам информации (64 байт).

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

И еще одно важное обстоятельство: возможен обмен (диалог) между Источником и Получателем в процессе передачи 64 байт (например, для коррекции ошибок или получения подтверждений о доставке). Однако и тут нужно учитывать, что очень часто время передачи одного фрейма от Источника к Получателю может достигать 400 мсек. Что накладывает ограничения на возможность использования диалога. Но исключает ее.

 

 

Юр, если какие идеи будут напиши пожста, проект в Иркутске и работа срочная )))

 

[Boris Bliznioukov]

так по ходу, люди похоже слабо понимают задачу. Все современные кодеки Speex в том числе (G.729, GSM) используют CELP в основе алгоритма лежит моделирование голосового аппарата человека (как серия труб и голосовых связок). Поэтому то что там про 160 байт написано просто весилит.

сэкономлю ребятам время
http://www.petitcolas.net/fabien/steganography/mp3stego/index.html

[victor butry]

4 декабря 2011 г. 17:00 пользователь Jury Gerasimov <ju...@softshape.com> написал:

  Похоже, у ребят трудности не только с математикой.
  "Особенность цифровых сетей связи..." состоит в том, что от абонента к абоненту всё передаётся в том виде, в каком запрошено.  В частности, если передающий аппарат (ISDN) затребует 64kbit unrestricted до принимающего (такого же ISDN), то именно они передадутся без всяких преобразований.
   То что подвергается преобразованию, может преобразовываться на том основании, что запрашивается соответствующая среда передачи, которая по определению может транслироваться.
   На счёт 50 фреймов со 160 измерениями вместе с aLaw не совсем понятно о чём речь. Если о сотовой связи, то aLaw там ни к чему, максимум - на МСС, но там уже никаких 50*160, а только TDM - на канале 8 бит каждые 1/8000 секунд...

   PS. Кажется ещё где-то в 92-93 годах попадался на глаза модем, который позволял одновременно и данные передавать, и голосом общаться. Стеганографии там, конечно, не было а по телефонной сети передавалось что-то типа v.21. Голос в той железке немного жали (всяко лушче чем в a-law), и передача данных подстраивалась под необходимости голоса. А вот что за железо было - не вспомню.

  PPS. Обрисованная картина напоминает задачу на скрытный обмен информацией между вирусами-ботами, сидящими в мобильных телефонах. :)

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

Начало переадресованного сообщения:

Особенность цифровых сетей связи в том, что речь, воспринимаемая телефонной трубкой, сначала выглядит как напряжение, модулированное звуковой волной. АЦП измеряет амплитуды этого сигнала с частотой 8000 Гц. Каждая секунда речи разбивается на 50 фрагментов (фреймов). Каждый фрейм содержит в себе 160 измерений амплитуды. Эти данные – набор чисел – кодируются, например, алгоритмом aLaw или более современным Speex. Фактически при кодировании 160 чисел с плавающей точкой «сжимаются» до 160 байт. Фреймы по 160 байт передаются от Источника к Получателю через комбинированную сеть, где в процессе транспортировки через сеть могут неоднократно подвергаться декодированию/кодированию, а также транскодированию. При этом на слух возникшие в процессе передачи искажения на стороне Получателя не воспринимаются нами и мы слышим собеседника как будто он рядом.

Однако, есть 2 неприятные вещи:

- при передаче фреймов через сеть сама сеть вносит ошибку в содержимое фрейма (например, из-за транскодирования)

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

 

Учитывая все эти обстоятельства, мы хотим реализовать такой механизм (программный код), который позволил бы на стороне Источника внедрить в каждый фрейм (или не каждый) некий «кусок» информации, которую мы хотим передать Получателю (64 байта) и при этом гарантировать, что на стороне Получателя информация будет восстановлена из фреймов в первозданном виде. При этом мы не должны затратить на это времени более 2,5 сек (то есть использовать 120-125 фреймов). Мы также можем (но это не желательно) позволить себе использовать первые 120 фреймов сообщения только для передачи нужной нам информации (64 байт).

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

И еще одно важное обстоятельство: возможен обмен (диалог) между Источником и Получателем в процессе передачи 64 байт (например, для коррекции ошибок или получения подтверждений о доставке). Однако и тут нужно учитывать, что очень часто время передачи одного фрейма от Источника к Получателю может достигать 400 мсек. Что накладывает ограничения на возможность использования диалога. Но исключает ее.

 

 

Юр, если какие идеи будут напиши пожста, проект в Иркутске и работа срочная )))

 

--
Irkutsk Webdev
http://groups.google.com/group/webdev-irk

--
wbr, victor (crower)