Documente Academic
Documente Profesional
Documente Cultură
Recent Entries:
Mu-Law and A-Law Compression Tutorial
My Dev Setup Lately
Three Ways To
Randomize on the
iPhone
How to Remove .svn
Directories On a Mac
How To Detect The Overview: What are A-Law and Mu-Law compression? In the simplest terms, they
iPhone Simulator are standard forms of audio compression for 16 bit sounds. Like most audio
iPhoneMom Likes compression techniques, they are lossy, which means that when you expand them
Doodle Games! back from their compressed state, they will not be exactly the same as when you
Updates To the compressed them. The compression is always 2:1, meaning that audio compressed
Doodle Games Line with either of these algorithms will always be exactly half of their original size.
Three Jacks Now Mu-Law and A-Law compression are both logarithmic forms of data compression,
Tweets and are extremely similar, as you will see in a minute. One definition of Mu-Law is
Second iPhone App
Submitted For "...a form of logarithmic data compression
Approval!
for audio data. Due to the fact that we hear logarithmically,
Pinch Media sound recorded at higher levels does not require the same
Analytics for iPhone
resolution as low-level sound. This allows us to disregard
New iPhone Game
Coming Soon! the least significant bits in high-level data. This turns
out to resemble a logarithmic transformation. The resulting
compression forces a 16-bit number to be represented as an 8-bit
number." (www-s.ti.com/sc/psheets/spra267/spra267.pdf)
Archive: And from the comp.dsp newsgroup FAQ we also get this definition:
January - 2010 Mu-law (also "u-law") encoding is a form of logarithmic
November - 2009 quantization or companding. It's based on the observation that
October - 2009 many signals are statistically more likely to be near a low
September - 2009 signal level than a high signal level. Therefore, it makes
August - 2009 more sense to have more quantization points near a low level
July - 2009 than a high level. In a typical mu-law system, linear samples
June - 2009 of 14 to 16 bits are companded to 8 bits. Most telephone
April - 2009 quality codecs (including the Sparcstation's audio codec) use
March - 2009 mu-law encoded samples.
January - 2009
May - 2008 In simpler terms, this means that sound is represented as a wave, and humans can
April - 2008 only hear audio in the middle of the wave. We can remove data from the upper and
March - 2008 lower frequencies of a sound, and humans will not be able to hear a significant
October - 2007 difference. Both Mu-Law and A-Law take advantage of this, and are able to compress
August - 2007 16-bit audio in an manner acceptable to human ears. A-Law and Mu-Law
July - 2007 compression appear to have been developed at around the same time, and basically
June - 2007 only differ by the particular logarithmic function used to determine the translation.
May - 2007 When we get to the work of implementing the algorithms, you will see that the
April - 2007 differences are nominal. The main difference is that Mu-Law attempts to keep the top
December - 2006 five bits of precision, and uses a logarithmic function to determine the bottom three
November - 2006 bits, while A-Law compression keeps the top four bits and uses the logarithmic
September - 2006 function to figure out the bottom four. Both of these algorithms are used as
http://hazelware.luggle.com/tutorials/mulawcompression.html 11/2/2010
Hazelware Page 2 of 5
August - 2006
July - 2006 telecommunication standards, A-Law being used mainly in Europe, and Mu-Law
March - 2006 being used in the United States.
February - 2006
January - 2006 DISCLAIMER:
December - 2005 Please understand that I am glossing over several of the details, but recognize that the
November - 2005 entire purpose of this document is to make two extremely useful algorithms much
October - 2005 more accessable to "average" programmers, like myself.
September - 2005
August - 2005
July - 2005 Mu-Law Compression:
June - 2005 As you read this explanation, remember that the purpose of the algorithm is to
May - 2005 compress a 16-bit source sample down to an 8-bit sample. The crux of Mu-Law
April - 2005 functionality is deciding which of the samples need to keep the most of their
February - 2005 precision. Even the "most-important" sample will still lose precision. It simply
January - 2005 becomes a matter of determining how much each sample loses, and minimizing the
December - 2004 loss on samples deemed "more important".
November - 2004 To generate a compressed Mu-Law sample from an uncompressed sample, the
October - 2004 following algorithm is applied to the 16-bit source sample.
September - 2004 (Please refer to the code listing for Mu-Law compression.)
August - 2004
July - 2004 First, the algorithm first stores off the sign. It then adds in a bias value which (due to
June - 2004 wrapping) will cause high valued samples to lose precision. The top five most
May - 2004 significant bits are pulled out of the sample (which has been previously biased).
April - 2004 Then, the bottom three bits of the compressed byte are generated using a small look-
March - 2004 up table, based on the biased value of the source sample. The 8-bit compressed
sample is then finally created by logically OR'ing together the 5 most important bits,
the 3 lower bits, and the sign when applicable. The bits are the logically NOT'ed,
which I assume is for transmission reasons (although you might not transmit your
sample.)
return (unsigned char)compressedByte;
}
http://hazelware.luggle.com/tutorials/mulawcompression.html 11/2/2010
Hazelware Page 3 of 5
A-Law Compression:
sign = ((~sample) >> 8) & 0x80;
if (!sign)
sample = (short)-sample;
if (sample > cClip)
sample = cClip;
if (sample >= 256)
{
exponent = (int)ALawCompressTable[(sample >> 8) & 0x7F];
mantissa = (sample >> (exponent + 3) ) & 0x0F;
compressedByte = ((exponent << 4) | mantissa);
}
else
{
compressedByte = (unsigned char)(sample >> 4);
}
compressedByte ^= (sign ^ 0x55);
return compressedByte;
}
Decompression:
Now, the most obvious way to decompress a compressed Mu-Law or A-Law sample
would be to reverse the algorithm. But a more efficient method exists. Consider for a
moment the fact that A-Law and Mu-Law both take a 16-bit value and crunch it down
to an 8-bit value. The reverse of that is to take an 8-bit value and turn it into a sixteen
http://hazelware.luggle.com/tutorials/mulawcompression.html 11/2/2010
Hazelware Page 4 of 5
bit value. In the graphics world, it is extremely common to represent 32 and 24 bit
values with an eight bit index into a palette table. So, why not take a page from the
world of graphics and use palettes for the Mu-Law and A-Law compression look up?
Sounds good to me. In fact, these palettes will be smaller than their 24 and 32 bit
cousins because we only need to represent 16 bit values, not 24 and 32. In a nutshell,
we will create static lookup tables to do the reverse conversion from A-Law and Mu-
Law. The two differing tables are presented below. To convert from your compressed
sample back to the raw 16-bit sample, just use your compressed sample as the index
into the table, and the corresponding value in the table is your decompressed 16-bit
sample. Obviously, the downside is that this method requires the memory overhead
for the tables, but each table is only 512 bytes. In this day and age, that's downright
cheap for the absolute fastest decompression!
Decompression Code:
static short MuLawDecompressTable[256] =
{
-32124,-31100,-30076,-29052,-28028,-27004,-25980,-24956,
-23932,-22908,-21884,-20860,-19836,-18812,-17788,-16764,
-15996,-15484,-14972,-14460,-13948,-13436,-12924,-12412,
-11900,-11388,-10876,-10364, -9852, -9340, -8828, -8316,
-7932, -7676, -7420, -7164, -6908, -6652, -6396, -6140,
-5884, -5628, -5372, -5116, -4860, -4604, -4348, -4092,
-3900, -3772, -3644, -3516, -3388, -3260, -3132, -3004,
-2876, -2748, -2620, -2492, -2364, -2236, -2108, -1980,
-1884, -1820, -1756, -1692, -1628, -1564, -1500, -1436,
-1372, -1308, -1244, -1180, -1116, -1052, -988, -924,
-876, -844, -812, -780, -748, -716, -684, -652,
-620, -588, -556, -524, -492, -460, -428, -396,
-372, -356, -340, -324, -308, -292, -276, -260,
-244, -228, -212, -196, -180, -164, -148, -132,
-120, -112, -104, -96, -88, -80, -72, -64,
-56, -48, -40, -32, -24, -16, -8, 0,
32124, 31100, 30076, 29052, 28028, 27004, 25980, 24956,
23932, 22908, 21884, 20860, 19836, 18812, 17788, 16764,
15996, 15484, 14972, 14460, 13948, 13436, 12924, 12412,
11900, 11388, 10876, 10364, 9852, 9340, 8828, 8316,
7932, 7676, 7420, 7164, 6908, 6652, 6396, 6140,
5884, 5628, 5372, 5116, 4860, 4604, 4348, 4092,
3900, 3772, 3644, 3516, 3388, 3260, 3132, 3004,
2876, 2748, 2620, 2492, 2364, 2236, 2108, 1980,
1884, 1820, 1756, 1692, 1628, 1564, 1500, 1436,
1372, 1308, 1244, 1180, 1116, 1052, 988, 924,
876, 844, 812, 780, 748, 716, 684, 652,
620, 588, 556, 524, 492, 460, 428, 396,
372, 356, 340, 324, 308, 292, 276, 260,
244, 228, 212, 196, 180, 164, 148, 132,
120, 112, 104, 96, 88, 80, 72, 64,
56, 48, 40, 32, 24, 16, 8, 0
};
http://hazelware.luggle.com/tutorials/mulawcompression.html 11/2/2010
Hazelware Page 5 of 5
472, 456, 504, 488, 408, 392, 440, 424,
88, 72, 120, 104, 24, 8, 56, 40,
216, 200, 248, 232, 152, 136, 184, 168,
1376, 1312, 1504, 1440, 1120, 1056, 1248, 1184,
1888, 1824, 2016, 1952, 1632, 1568, 1760, 1696,
688, 656, 752, 720, 560, 528, 624, 592,
944, 912, 1008, 976, 816, 784, 880, 848
};
http://hazelware.luggle.com/tutorials/mulawcompression.html 11/2/2010