[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [HLL] Discussion

Status: RO
X-Status: A
Content-Length: 1805
Lines: 35

On Thu, 15 Jan 1998, Volker Ernst wrote:
>   So our preferred solution to the bandwidth-problem is:
>   - We use 14.4-modems (minimum), std-gsm-codec, async-protokoll.
>   - To reduce data-output we either reduce audio sample-rate
>     (still running gsm-codec the same way) or we 'drop frames'
>     from time to time. The first method is preferred, because
>     is provides continuous audio. The second method might have
>     to be supported anyway when dealing with internet-frames.

There are several reasons why I feel that you really don't want to reduce
the sampling  rate:

o The frequencies most important to understanding voice go up to 4 kHz. As
the Nyquest theorem shows, you must sample signals at least at twice the
frequency you want to record. Which is why so many vocoders sample at 8
o GSM is a predictive vocoder. Which works on the assumption that the
changes between each sample are small.  When the sample rate  is
decreased, the differences between subsequent samples increase. Which
vastly complicates life for the prediction algorithm.

The result will be extremely low quality voice. [The second sugestion of
dropping frames would be just as bad for similar reasons].

If you need lower bit rates, you need a /different/ vocoder.

I suggest you look at some of the freely available CELP codecs. They are
very forgiving and work at  low bit rates. [No doubt that both  properties
relate to the fact that these codecs have been developed by the US
Department  of Defense :-] The major drawback of the CELP codecs  is  that
they require more  CPU power. But the HLB should have enough.

Have fun,
-- Lucky Green <shamrock@cypherpunks.to> PGP v5 encrypted email preferred.
   "Tonga? Where the hell is Tonga? They have Cypherpunks there?"