Adaptive Filter | ADPCM | ADSP | ADSP-2181 | Aliasing | AMR | Anti-Aliasing | ARMA | Autocorrelation | AutoCovariance | Beamforming | Bessel | Blackfin | Butterworth | C6713 | CCS | Chebyshev | CIC Filter | Circular Convolution | Code Composer Studio | Comb Filter | Compression | Convolution | Cross Correlation | DCT | Decimation | Deconvolution | Demodulation | DM642 | DSP Boards | DSP/BIOS | DTMF | Echo Cancellation | Equalization | Equalizer | ETSI | EZLITE (Ez-kit Lite) | FFT | FFTW | FIR Filter | Fixed Point | FSK | G.711 | G.723 | G.729 | Gaussian Noise | Goertzel | GPIO | Hilbert Transform | IFFT | IIR Filter | Interpolation | Invariance | JTAG | Kalman | Laplace Transform | Levinson | LPC | McBSP | MIPS | Modulation | MPEG | Multirate | Notch Filter | Nyquist | OFDM | Oversampling | Pink Noise | Pitch | PLL | Polyphase | QAM | QDMA | Quantization | Quantizer | Radar | Random Noise | Reed Solomon | Remez | Resampling | RTDX | Sampling | Sharc | TI C6711 | Undersampling | Viterbi | Wavelets | White Noise | Wiener Filter | Windowing | XDS510PP | Z Transform

Hi,

 I am doing project named Implementation of Mu-law Speech companding on
TMS320vc5510 using DSK5510 board.

I need help regarding algorithm for mu-law My data is 16-bit samples that
i am getting from reading .WAVE file.
I want to write in C language.I am implementing it offline and real time
both ways.

I neeed help on look-up table, What look-up table i will be required and
How can i map 16 to 8 and 8 to 16 bit ?
 
pls send me required material on that or source code of mu-law compression
and expansion. or pls give me help on real time implementation of it


Vikas Patil
IIIT, Pune
v...@embed.isquareit.ac.in

______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

On Sun, 05 Feb 2006 09:00:37 -0600, "vikaspatil123"
<v...@yahoo.co.in> wrote:

>Hi,
>
> I am doing project named Implementation of Mu-law Speech companding on
>TMS320vc5510 using DSK5510 board.
>
>I need help regarding algorithm for mu-law My data is 16-bit samples that
>i am getting from reading .WAVE file.
>I want to write in C language.I am implementing it offline and real time
>both ways.
>
>I neeed help on look-up table, What look-up table i will be required and
>How can i map 16 to 8 and 8 to 16 bit ?
> 
>pls send me required material on that or source code of mu-law compression
>and expansion. or pls give me help on real time implementation of it

Mu Law is specified in the ITU-T Recommendation G.711.

You could try googling for G.711.  You will find several implementions
that might be useful to you.  Some will be free, some will be
commercial.  Some may even work well.

G.711 also specifies A-law, so make sure you don't mix them up.

Here is the wikipedia entry:
http://en.wikipedia.org/wiki/G.711
Here is the ITU-T Recommendation, which should be regarded as the
canonical source of information about mu-law:
http://www.itu.int/rec/T-REC-G.711/en

Note that the ITU-T have a reference implemention of G.711 written in
ANSI C.  This page:
http://www.itu.int/rec/recommendation.asp?type=products&lang=e&parent=T-REC-G
contains this note:
"Corresponding ANSI-C code is available in the G.711 module of the
ITU-T G.191 Software Tools Library."

Regards,
Allan

______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

vikaspatil123 wrote:

> Hi,
> 
>  I am doing project named Implementation of Mu-law Speech companding on
> TMS320vc5510 using DSK5510 board.
> 
> I need help regarding algorithm for mu-law My data is 16-bit samples that
> i am getting from reading .WAVE file.
> I want to write in C language.I am implementing it offline and real time
> both ways.
> 
> I neeed help on look-up table, What look-up table i will be required and
> How can i map 16 to 8 and 8 to 16 bit ?
>  
> pls send me required material on that or source code of mu-law compression
> and expansion. or pls give me help on real time implementation of it
> 
> 
> Vikas Patil
> IIIT, Pune
> v...@embed.isquareit.ac.in
> 
> 
> 
> 
Mu law maps a 12 (or 13) bit number to 8 bits, so it is, perforce, a 
4096 to 256 mapping (or 4096 to 255, or 8192 to 256 -- look at the 
standard).  As such it is lossy, and when you go back to 12 (or 13) bits 
there will be gaps -- they'll just be gaps that don't affect speech 
quality too much.

In addition to being lossy, mu law compandors don't have much dynamic 
range -- the 12 bits that you start from should be pretty well filled 
with data.  That means that you should apply some AVC (automatic volume 
control) to the data before it hits your compandor.  If you don't you'll 
either be clipping or sending data that's too quiet.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

From my notes: -Clark

-----------------------------------------------------------------------

TWIMC,

Below are two routines I wrote for converting between ulaw and linear.
I use them with the SparcStation and they seem to work fine.
I am pretty sure (99.9%) that they implement the standard as specified
in the references.

Note that the standard deals with converting between 12 bit linear
and 8 bit ulaw.  These routines assume 16 bit linear.  Thus, some
bit shifting may be necessary.

craig

------------------------------------------------------------------
/**
 ** Signal conversion routines for use with the Sun4/60 audio chip
 **/

/*
 * This routine converts from linear to ulaw
 * 29 September 1989
 *
 * Craig Reese: IDA/Supercomputing Research Center
 * Joe Campbell: Department of Defense
 *
 * References:
 * 1) CCITT Recommendation G.711  (very difficult to follow)
 * 2) "A New Digital Technique for Implementation of Any
 *     Continuous PCM Companding Law," Villeret, Michel,
 *     et al. 1973 IEEE Int. Conf. on Communications, Vol 1,
 *     1973, pg. 11.12-11.17
 * 3) MIL-STD-188-113,"Interoperability and Performance Standards
 *     for Analog-to_Digital Conversion Techniques,"
 *     17 February 1987
 *
 * Input: Signed 16 bit linear sample
 * Output: 8 bit ulaw sample
 */

#define ZEROTRAP    /* turn on the trap as per the MIL-STD */
#define BIAS 0x84   /* define the add-in bias for 16 bit samples */
#define CLIP 32635

unsigned char
linear2ulaw(sample)
int sample;
{
    static int exp_lut[256] = {0,0,1,1,2,2,2,2,3,3,3,3,3,3,3,3,
                               4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,
                               5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,
                               5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,
                               6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,
                               6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,
                               6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,
                               6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,
                               7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,
                               7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,
                               7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,
                               7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,
                               7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,
                               7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,
                               7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,
                               7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7};
    int sign, exponent, mantissa;
    unsigned char ulawbyte;

    /** get the sample into sign-magnitude **/
    sign = (sample >> 8) & 0x80;        /* set aside the sign */
    if (sign != 0) sample = -sample;    /* get magnitude */
    if (sample > CLIP) sample = CLIP;   /* clip the magnitude */
    /** convert from 16 bit linear to ulaw **/
    sample = sample + BIAS;
    exponent = exp_lut[(sample>>7) & 0xFF];
    mantissa = (sample >> (exponent+3)) & 0x0F;
    ulawbyte = ~(sign | (exponent << 4) | mantissa);
#ifdef ZEROTRAP
    if (ulawbyte == 0 ) ulawbyte = 0x02;  /* optional CCITT trap */
#endif
    /** return the result **/
    return(ulawbyte);
    }

/*
 * This routine converts from ulaw to 16 bit linear
 * 29 September 1989
 *
 * Craig Reese: IDA/Supercomputing Research Center
 *
 * References:
 * 1) CCITT Recommendation G.711  (very difficult to follow)
 * 2) MIL-STD-188-113,"Interoperability and Performance Standards
 *     for Analog-to_Digital Conversion Techniques,"
 *     17 February 1987
 *
 * Input: 8 bit ulaw sample
 * Output: signed 16 bit linear sample
 */

int
ulaw2linear(ulawbyte)
unsigned char ulawbyte;
{
    static int exp_lut[8]={0,132,396,924,1980,4092,8316,16764};
    int sign, exponent, mantissa, sample;

    ulawbyte = ~ulawbyte;
    sign = (ulawbyte & 0x80);
    exponent = (ulawbyte >> 4) & 0x07;
    mantissa = ulawbyte & 0x0F;
    sample = exp_lut[exponent] + (mantissa << (exponent+3));
    if (sign != 0) sample = -sample;
    return(sample);
}

-----------------
Craig F. Reese                           Email: c...@super.org
Institute for Defense Analyses/
Supercomputing Research Center
17100 Science Dr.
Bowie, MD  20715-4300


"vikaspatil123" <v...@yahoo.co.in> wrote in message
news:7...@giganews.com...
> Hi,
>
>  I am doing project named Implementation of Mu-law Speech companding on
> TMS320vc5510 using DSK5510 board.
>
> I need help regarding algorithm for mu-law My data is 16-bit samples that
> i am getting from reading .WAVE file.
> I want to write in C language.I am implementing it offline and real time
> both ways.
>
> I neeed help on look-up table, What look-up table i will be required and
> How can i map 16 to 8 and 8 to 16 bit ?
>
> pls send me required material on that or source code of mu-law compression
> and expansion. or pls give me help on real time implementation of it
>
>
> Vikas Patil
> IIIT, Pune
> v...@embed.isquareit.ac.in
>
>
>
>

______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

Tim Wescott wrote:


> Mu law maps a 12 (or 13) bit number to 8 bits, so it is, perforce, a 
> 4096 to 256 mapping (or 4096 to 255, or 8192 to 256 -- look at the 
> standard).  As such it is lossy, and when you go back to 12 (or 13) bits 
> there will be gaps -- they'll just be gaps that don't affect speech 
> quality too much.
> 
> In addition to being lossy, mu law compandors don't have much dynamic 
> range -- the 12 bits that you start from should be pretty well filled 
> with data.   That means that you should apply some AVC (automatic volume
> control) to the data before it hits your compandor.  If you don't you'll 
> either be clipping or sending data that's too quiet.
> 

The A-law and u-Law are *not* the optimal quantizers for the speech 
signal statistics. The design point of the u-law and A-law was to have 
the signal/quantization noise ratio relatively independent of the rms 
value of the signal. With the addition of the AVC, the simple linear 8 
bit quantizer will perform considerably better.
What I don't understand is why didn't they apply the fixed preemphasis 
before quantization. For the voice band signals, they could probably 
gain another 10dB in SNR.

Vladimir Vassilevsky

DSP and Mixed-Up Signal Design Consultant

http://www.abvolt.com

______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

Vladimir Vassilevsky wrote:

> 
> 
> Tim Wescott wrote:
> 
> 
>> Mu law maps a 12 (or 13) bit number to 8 bits, so it is, perforce, a 
>> 4096 to 256 mapping (or 4096 to 255, or 8192 to 256 -- look at the 
>> standard).  As such it is lossy, and when you go back to 12 (or 13) 
>> bits there will be gaps -- they'll just be gaps that don't affect 
>> speech quality too much.
>>
>> In addition to being lossy, mu law compandors don't have much dynamic 
>> range -- the 12 bits that you start from should be pretty well filled 
>> with data.   That means that you should apply some AVC (automatic volume
>> control) to the data before it hits your compandor.  If you don't 
>> you'll either be clipping or sending data that's too quiet.
>>
> 
> The A-law and u-Law are *not* the optimal quantizers for the speech 
> signal statistics. The design point of the u-law and A-law was to have 
> the signal/quantization noise ratio relatively independent of the rms 
> value of the signal. With the addition of the AVC, the simple linear 8 
> bit quantizer will perform considerably better.
> What I don't understand is why didn't they apply the fixed preemphasis 
> before quantization. For the voice band signals, they could probably 
> gain another 10dB in SNR.
> 
> Vladimir Vassilevsky
> 
> DSP and Mixed-Up Signal Design Consultant
> 
> http://www.abvolt.com

Given that one runs smack into a host of human factors issues when you 
try to define a cost function I doubt that an 'optimal' quantizer for 
speech signal statistics will ever be known (or at least never agreed 
upon).  For the state of the art at the time the mu-law and a-law 
compandors are pretty good.  I also couldn't say why they have no 
preemphasis -- the phone companies were certainly technically astute 
enough at the time, and willing to invest it some pretty heavy duty 
hardware.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

Vladimir Vassilevsky wrote:
>
>
> Tim Wescott wrote:
>
>
>> Mu law maps a 12 (or 13) bit number to 8 bits, so it is, perforce, a 
>> 4096 to 256 mapping (or 4096 to 255, or 8192 to 256 -- look at the 
>> standard).  As such it is lossy, and when you go back to 12 (or 13) 
>> bits there will be gaps -- they'll just be gaps that don't affect 
>> speech quality too much.
>>
>> In addition to being lossy, mu law compandors don't have much dynamic 
>> range -- the 12 bits that you start from should be pretty well filled 
>> with data.   That means that you should apply some AVC (automatic volume
>> control) to the data before it hits your compandor.  If you don't 
>> you'll either be clipping or sending data that's too quiet.
>>
>
> The A-law and u-Law are *not* the optimal quantizers for the speech 
> signal statistics. The design point of the u-law and A-law was to have 
> the signal/quantization noise ratio relatively independent of the rms 
> value of the signal. With the addition of the AVC, the simple linear 8 
> bit quantizer will perform considerably better.
> What I don't understand is why didn't they apply the fixed preemphasis 
> before quantization. For the voice band signals, they could probably 
> gain another 10dB in SNR.
You get a fairly constant 30dB or so of SNR, which is good enough for 
most telephony purposes. There isn't a strong advantage is getting that 
extra 10dB, and the 72dB of overall dynamic range uLaw offers is also 
perfectly adequate for most telephony purposes. However, considering the 
original T1 systems were implemented in the very early days of discrete 
transistors, it is a little surprising they did nothing like you 
suggest. A small filtering circuit might have eased the complexity of 
the digital stuff a bit, and every little bit cost serious money back then.

Maybe it was foresight - emphasis and deemphasis would have made voice 
band modems much tougher :-)


Regards,
Steve

______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

Vladimir Vassilevsky wrote:

> What I don't understand is why didn't they apply the fixed preemphasis 
> before quantization. For the voice band signals, they could probably 
> gain another 10dB in SNR.

Vladimir, that what happens when a hardware engineer like you is trying 
to pretend he's a DSP or speech processing expert...

The quantization is indeed not optimal to speech since it was not aimed 
to be so....  ITU-T designed it to encode various signals such as DTMF, 
fax, music, speech and perhaps other audio signals that may be 
transmitted on telephony network...

Logarithmic quantization does all that pretty well, and hence mu-law, 
A-law are used in telephony!

______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

in article d7zFf.12452$H43.6390@trnddc08, DFG at D...@JustNoSpam.com wrote on
02/05/2006 22:11:

> Vladimir Vassilevsky wrote:
> 
>> What I don't understand is why didn't they apply the fixed preemphasis
>> before quantization. For the voice band signals, they could probably
>> gain another 10dB in SNR.
> 
> Vladimir, that what happens when a hardware engineer like you is trying
> to pretend he's a DSP or speech processing expert...

dunno what you mean.  i thought he hit it correctly with:

>> The design point of the u-law and A-law was to have the signal/quantization
>> noise ratio relatively independent of the rms value of the signal.

but i don't understand what "fixed pre-emphasis" he means.  like a fixed
boost of the high frequencies similar to the RIAA for vinyl records?

-- 

r b-j                  r...@audioimagination.com

"Imagination is more important than knowledge."

______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

robert bristow-johnson wrote:

>>>What I don't understand is why didn't they apply the fixed preemphasis
>>>before quantization. For the voice band signals, they could probably
>>>gain another 10dB in SNR.
>>

Robert, there is no point to argue with the offended individual. It only 
makes difficult to the other folks to distinguish you and him.

> 
> but i don't understand what "fixed pre-emphasis" he means.  like a fixed
> boost of the high frequencies similar to the RIAA for vinyl records?

Precisely. The differentiation of the signal to compensate for the 
spectral tilt before quantization makes noticeable improvement in the 
quality. This is basically the same idea as the DPCM or RIAA or FM 
biasing. However AT&T probably decided that 30dB is good enough, 
especially for that old days.

Vladimir Vassilevsky

DSP and Mixed-Up Signal Design Consultant

http://www.abvolt.com

______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.