Yes, I understand that, that is why I'm thinking of this approach. My
idea was to use analog voice transforms and their inverse with
properties that would preserve most of the codec performance. But it
would be awfully difficult to sync up the inverse on the other end
without a data connection,
Crane, Matthew wrote:
Yes, I understand that, that is why I'm thinking of this approach. My
idea was to use analog voice transforms and their inverse with
properties that would preserve most of the codec performance. But it
would be awfully difficult to sync up the inverse on the other end
There are no simple voice transforms at all that will get through the codec,
and actually encrypt.
Voice changing is possible, but encryption is not.
You _cannot_ - for example - exepect frequency inversion - to get through
the codec chain.
What about correlating (multiplying) the input
Flemming Richter Mikkelsen wrote:
There are no simple voice transforms at all that will get through the codec,
and actually encrypt.
Voice changing is possible, but encryption is not.
You _cannot_ - for example - exepect frequency inversion - to get through
the codec chain.
What about
community discussion
Subject: Re: Newbee ..- encrypted calls/SMS
Crane, Matthew wrote:
Yes, I understand that, that is why I'm thinking of this approach. My
idea was to use analog voice transforms and their inverse with
properties that would preserve most of the codec performance. But it
would
On Fri, April 25, 2008 2:18 pm, Crane, Matthew wrote:
Yes, I understand that, that is why I'm thinking of this approach. My
idea was to use analog voice transforms and their inverse with
properties that would preserve most of the codec performance. But it
would be awfully difficult to sync
6 matches
Mail list logo
