Ken Webster wrote:

> Oh .. actually I just thought about it .. I suppose that XORing with a
> pseudorandom sequence would probably just add a lot of noise but still
> allow the voice to be heard if it was loud enough

  I don't think so.  XORing with a PR sequence should be pretty
effective - at scrambling.  You see, the PR sequence *fills* the
bandwidth with noise - the desired signal cannot be louder than this, in
effect the signal modulates the noise rather than the other way around,
and modulated noise is - still noise!

>  Unfortunately the window size would have to be substantial (enough
> for 1/100 second or so) to garble the lower frequencies in human voice

  The general problem with performing scrambling is that to mask the
cadence, or envelope, of the speech, you have to generate something
(noise) to fill in the gaps.  This results in much heavier use of the
bandwidth (in fact, it is completely occupied) than normal speech and
ipso facto, defeats compression.

  In fact, compression would tend to defeat the scrambling (by
preventing unscrambling).  Not the same situation as temporal
compression (as in a .WAV file) by the way, where the compressed version
can be effectively scrambled (if necessary - compression is already a
form of scrambling in itself).

> ... I guess a better way would be to group the samples into windows
> and shuffle the samples within each window by the pseudorandom
> function.

  The problem with scrambling in general, especially compression, is
that data loss (noise) in the transmission tends to "break" the
scrambled version so it can't be decoded at all.  Simply feeding the
encoded data into anohter DAC and vice versa at the other end is really
"asking" for corruption.

  In the case of the PRBNG sequences used to hash data, there is a trick
to resynchronise the register, but I haven't figured it out yet.  Anyone
seen a good explanation of this?
--
  Cheers,
        Paul B.