Musicman,

For sample freq of 8 KHz, frequency range 300-3000 Hz (center is at
1650 Hz):

complex mix with freq of -1650 Hz

filter complex result with filter of bandwidth of 1650 Hz, transition
bandwidth of 300 Hz (I use linear phase FIR, odd length)

complex mix result again with freq of -1650 Hz (I usually offset the
index of the mixer by the filter delay to make everything line up nice
for debug)

take real part - that is the inverted spectrum signal.

last 2 steps could be combined to optimize computations.

If you have MATLAB, try it out.

Dirk Bell
DSP Consultant



bachbeethoven200 wrote:
> Thank you for all of your advice
>
> I am trying to preserve the audio bandwith to put the inverted audiio
> through a bandlimited channel. So simply invert the sign of sample doesn't
> work. The signal is needed to convert back to analog after scrambling and
> that's why I am not doing any digital encryption.
>
> Hey Dirk, would you mind further explain your approach ?
> <--- Process should be complex mix, lowpass filter, complex mix, take real
> part to get the audio inverted around 1650 Hz
>
> And Herman suggested
>
> 1. Double the effective sample frequency by inserting a zero between each
>
> sample.
> 2. Filter to remove frequencies above 3700 Hz.
> 3. Multiply by a sine wave at 4000 Hz. (Hetrodyne not complex hetrodyne)
> 4. Filter to eliminate to remove the everything above 3700 Hz which
> eliminates the sum frequency. The difference frequency inverts the
> spectrum.
>
> Upsampling and Downsampling would need decimation and interpolation
> filters which may increase the processing power =(

Thank you for all of your advice

I am trying to preserve the audio bandwith to put the inverted audiio
through a bandlimited channel. So simply invert the sign of sample doesn't
work. The signal is needed to convert back to analog after scrambling and
that's why I am not doing any digital encryption.

Hey Dirk, would you mind further explain your approach ?
<--- Process should be complex mix, lowpass filter, complex mix, take real
part to get the audio inverted around 1650 Hz

And Herman suggested

1. Double the effective sample frequency by inserting a zero between each

sample.
2. Filter to remove frequencies above 3700 Hz.
3. Multiply by a sine wave at 4000 Hz. (Hetrodyne not complex hetrodyne)
4. Filter to eliminate to remove the everything above 3700 Hz which 
eliminates the sum frequency. The difference frequency inverts the
spectrum.

Upsampling and Downsampling would need decimation and interpolation
filters which may increase the processing power =(

I think several people have started down the right path.  I think

1.  Double the effective sample frequency by inserting a zero between each 
sample.
2.  Filter to remove frequencies above 3700 Hz.
3.  Multiply by a sine wave at 4000 Hz.  (Hetrodyne not complex hetrodyne)
4.  Filter to eliminate to remove the everything above 3700 Hz which 
eliminates the sum frequency.  The difference frequency inverts the spectrum.

In article <1156814728.747324.14750@h48g2000cwc.googlegroups.com>, "dbell" 
<dbell@niitek.com> wrote:
>Vladimir,
>
>Reading a little into the original post I would guess that he is trying
>to preserve the audio bandwidth to put the inverted audio through a
>bandlimited channel.  If you have a spectrum from 300-3000 Hz (8Ksps)
>and flip every other sample as suggested, the inverted spectrum covers
>1000-3700 Hz.  Passing this through a channel that cuts off at 3000 Hz
>limits the inverted channel to 1000-3000 Hz.  When this is inverted,
>the original frequency content is limited to 1000-3000 Hz which makes
>for some really bad audio. So inverting the sign of every other sample
>is not the way to go.
>
>Dirk Bell
>DSP Consultant
>
>
>Vladimir Vassilevsky wrote:
>> bachbeethoven200 wrote:
>>
>> > I have an audial signal of sampling rate 8000Hz (16 bits per sample) so the
>> > frequency band that i can use is below 4000Hz (8000/2). I would like to
>> > have a frequency inversion of 300Hz to 3kHz that means (300Hz will go to
>> > 3kHz and 3kHz will go to 300Hz and the in-between are flip).
>> >
>> > I tried many methods to do it but fails.
>> >
>>
>> All you have to do is invert the sign of the every second sample.
>>
>>
>> > 1) Like a frequency shifting, I can shift the (-3k to 300) to (300 and 3k)
>> > that means multipy a cosine of 3300Hz, but due to the 8000 sampling rate,
>> > there's distortion.
>> >
>> > 2) Like a SSB modulation, to move the lower band in the (300 to 3k)
>> > region. But it requires a Hilbert transform. There are many approximations
>> > of Hilbert transform like using remez function in matlab and other FIR or
>> > IIR filters. But in SSB, if the phase response of those filters are not
>> > out-of-phase 90 degree difference, the upper band components cannot be
>> > cancelled and the result is not good.
>>
>> :))))
>> In many cases, extra knowledge is only harmfull.
>>
>>
>> > So can anyone help me to figure out those problem or have any other good
>> > scrambling methods or algorithms that are easy to implement in DSP.
>>
>> Take any voice compression algorithm (like G.723.1 for example) and
>> apply AES to the digital data. Keep in mind that the development of such
>> algorithms is a controlled issue in most of the countries.
>>
>>
>> Vladimir Vassilevsky
>> 
>> DSP and Mixed Signal Design Consultant
>> 
>> http://www.abvolt.com
>

Andor wrote:


> VLV mentioned AES, which would also be my algorithm of choice. There is
> source code out there, just look.

If the goal is having maximum security, then my preference is old good 
DES. The DES is the most proven algorithm so far and it does not seem to 
have any serious flaws. The only weakness of DES is the small key size, 
however you can cascade as many stages of DES encryption with the 
different keys as you like.

VLV

I don't know what the economic/other tradeoffs were at the the time it
was developed (pre 2002).  I don't know what they would be now. It
doesn't really matter since that was the way it was made.  For quick
easy coding debugging for the original poster, an SSB approach would
probabably be easier to code and debug.  Sounded like a student project
to me. Outside code might not be allowed.

Dirk

Andor wrote:
> dbell wrote:
> > Andor wrote:
> > > dbell wrote:
> > > > Andor,
> > > >
> > > > Even if the signal is digitized for processing (which may be required
> > > > for the scrambler implementation chosen) , the signal may have to be
> > > > converted back to analog to go through a low bandwidth analog channel
> > > > (analog telephone channel, analog radio channel).  I ran into this
> > > > general type of frequency inversion in production in 2002.
> > >
> > > The descrambling is done analogue? Otherwise, a processor can decrypt
> > > instead of descramble prior to DA conversion.
> >
> > Descrambing was also digital. I am guessing the method was selected for
> > its relatively low complexity, low manufacturing costs, and fitting
> > into analog bandwidth.
>
> Exactly for those reasons standard encryption should be chosen: It is
> low complexity, there exists tested and proven source code, and
> encryption does not change the data rate. This completely disregards
> question of security, where obviously encryption beats frequency
> inversion hands down. And finally, the encrypt / decrypt process is
> fully transparent, whereas this frequency inversion scheme is not
> likely to produce bit equal input / output pairs.
> 
> Regards,
> Andor

dbell wrote:
> Andor wrote:
> > dbell wrote:
> > > Andor,
> > >
> > > Even if the signal is digitized for processing (which may be required
> > > for the scrambler implementation chosen) , the signal may have to be
> > > converted back to analog to go through a low bandwidth analog channel
> > > (analog telephone channel, analog radio channel).  I ran into this
> > > general type of frequency inversion in production in 2002.
> >
> > The descrambling is done analogue? Otherwise, a processor can decrypt
> > instead of descramble prior to DA conversion.
>
> Descrambing was also digital. I am guessing the method was selected for
> its relatively low complexity, low manufacturing costs, and fitting
> into analog bandwidth.

Exactly for those reasons standard encryption should be chosen: It is
low complexity, there exists tested and proven source code, and
encryption does not change the data rate. This completely disregards
question of security, where obviously encryption beats frequency
inversion hands down. And finally, the encrypt / decrypt process is
fully transparent, whereas this frequency inversion scheme is not
likely to produce bit equal input / output pairs.

Regards,
Andor

Andor wrote:
> dbell wrote:
> > Andor,
> >
> > Even if the signal is digitized for processing (which may be required
> > for the scrambler implementation chosen) , the signal may have to be
> > converted back to analog to go through a low bandwidth analog channel
> > (analog telephone channel, analog radio channel).  I ran into this
> > general type of frequency inversion in production in 2002.
>
> The descrambling is done analogue? Otherwise, a processor can decrypt
> instead of descramble prior to DA conversion.

Descrambing was also digital. I am guessing the method was selected for
its relatively low complexity, low manufacturing costs, and fitting
into analog bandwidth.

Dirk.

dbell wrote:
> Andor,
>
> Even if the signal is digitized for processing (which may be required
> for the scrambler implementation chosen) , the signal may have to be
> converted back to analog to go through a low bandwidth analog channel
> (analog telephone channel, analog radio channel).  I ran into this
> general type of frequency inversion in production in 2002.

The descrambling is done analogue? Otherwise, a processor can decrypt
instead of descramble prior to DA conversion.

Andor,

Even if the signal is digitized for processing (which may be required
for the scrambler implementation chosen) , the signal may have to be
converted back to analog to go through a low bandwidth analog channel
(analog telephone channel, analog radio channel).  I ran into this
general type of frequency inversion in production in 2002.

Dirk Bell
DSP Consultant

Andor wrote:
> bachbeethoven200 wrote:
> > I have an audial signal of sampling rate 8000Hz (16 bits per sample) so the
> > frequency band that i can use is below 4000Hz (8000/2). I would like to
> > have a frequency inversion of 300Hz to 3kHz that means (300Hz will go to
> > 3kHz and 3kHz will go to 300Hz and the in-between are flip).
> ...
> > So can anyone help me to figure out those problem or have any other good
> > scrambling methods or algorithms that are easy to implement in DSP.
>
> I always thought that scrampling signals that way (frequency inversion)
> or by permuting frequency bands was only used for analog signals. For
> digital signals, it would seem that standard data encryption is a) much
> more secure and b) simpler to implement.
>
> VLV mentioned AES, which would also be my algorithm of choice. There is
> source code out there, just look.
> 
> Regards,
> Andor

bachbeethoven200 wrote:
> I have an audial signal of sampling rate 8000Hz (16 bits per sample) so the
> frequency band that i can use is below 4000Hz (8000/2). I would like to
> have a frequency inversion of 300Hz to 3kHz that means (300Hz will go to
> 3kHz and 3kHz will go to 300Hz and the in-between are flip).
...
> So can anyone help me to figure out those problem or have any other good
> scrambling methods or algorithms that are easy to implement in DSP.

I always thought that scrampling signals that way (frequency inversion)
or by permuting frequency bands was only used for analog signals. For
digital signals, it would seem that standard data encryption is a) much
more secure and b) simpler to implement.

VLV mentioned AES, which would also be my algorithm of choice. There is
source code out there, just look.

Regards,
Andor