This page comparing various lossless audio compression algorithms and programs hasn’t changed much since January 2003. I am no longer maintaining it and I suggest that the best place to maintain an up-to-date account of this subject is in the Wikipedia at:

http://en.wikipedia.org/wiki/Audio_data_compression#Lossless_compression

Some short updates

• http://www.lossless-audio.com Windows, Linux, plug-ins etc.
• Windows Media Player 9 supports lossless audio compression. See: Windows Media Audio 9 Lossless at http://www.microsoft.com/windows/windowsmedia/9series/encoder/quality.aspx . I also understand that Apple’s Itunes software has a lossless algorithm.
• http://web.inter.nl.net/users/hvdh/lossless/lossless.htm Martin Lange compares various algorithms.
• http://www.true-audio.com Free (as in free and open source) algorithm with impressive documentation, various implementations, including a Cool-Edit plug-in. Comparison of various algorithms at: http://www.true-audio.com/codec.comparison .
• Francois Charlton wrote to me with some thoughtful theoretical material which I reproduce here: fc-lossless.html .

If you want the test samples . . .

Update 2010-04-16:

I apologise for the test files not being available for some time. I have not been able to find my December 2000 CDRs of these files. This was the basis of what I used to have in a separate directory, which I described in this way:

I have a set of audio samples which I think give a good range of material to try compression algorithms on. I can send this to you on two CD-Rs if you like, or if you have broadband Internet and are happy to download a bunch of stuff (674 Megabytes) you can get Zipped (ordinary Zip format) compressed versions of the 11 music tracks I used for these tests. Please see ../../0-big/ and give the username lossless and the password audio. There is also a bunch of compression programs there and the batch files etc. I used for testing. The files on these CD-Rs, and in the above-mentioned directory, are from December 2000.

I have found most of the test files - 00 HI to 10SI - and these are avialable: Please see ../../0-big/ and give the username lossless and the password audio. The test files are stereo 44.1kHz 16 bit .WAV files, compressed with PKZIP - so they can be decompressed by WinZip and many other programs. The Unix/Linux "unzip" program can also decompress them.

Why I am no longer pursuing this field

The question of compressing audio without any loss of quality (including especially without having to even think about how lossy a lossy algorithm is, because the binary bits are fully restored) is obviously important. I partially developed my own algorithm and found it was not as good, at least initially, as existing approaches.

I have a very strong sense - and I think it is shared by many people with experience in this field - that existing algorithms come within a few percent of theoretical limits in terms of compression efficiency. No-one knows exactly the maximum compression which could be achieved on a given file, but the way the various algorithms all approach a particular percentage for a particular piece of music, and how those percentages vary widely according to the nature of the music, seems to indicate the best of the algorithms is getting close to some unknown theoretical limit.

Therefore, in my view, straight-out improvements in compression ratio are likely to be limited to a few percent. Since the cost of storage is falling precipitously (RAM, hard disks, FLASH memory, writeable DVDs etc.) and since the costs of transmission (Internet in general and broadband access to the Net in particular) are falling while transmission speeds are generally improving, I don’t feel like doing a lot of work to achieve minor improvements in file size. However, I salute those who are pursuing this!

There are improvements to be made beyond compression ratio:

• The efficiency (CPU cycles required) of the compression algorithm. In most cases, apart from portable audio recorders, I don’t think this matters as much as efficiency of decompression.
• Efficiency of decompression. On a modern PC, most of these algorithms are going to place very modest demands on the CPU. Decompression efficiency is more important for hand-held devices with smaller, slower, CPUs and restricted battery life.
• Portability - the code being written in C or C++ in an elegant, modular and very well commented fashion.
• Copyright of the code - open-source software.
• Ultimately, by hook or by crook, one or perhaps a few algorithms gaining sufficient support to be effectively, or formally, standardised and therefore very widely used.
• Ease of use of the software.

Before I sign off, here is a mini rant about sampling rate and bit-depth for audio recording.

When recording raw audio, I think its good to use a 20 bit converter and run at a higher than normal (44.1kHz) sampling rate if possible. This makes it easier to avoid clipping with unexpected high peaks.

With the following exceptions, I think that for mixed, finished, music, there is no point in going beyond 44.1kHz 16 bit stereo:

• If you want to reproduce frequencies you can’t hear (on their own) for the purposes of multiple such tones distorting and therefore inter-modulating in your ear so you can hear the differences between their frequencies (which do fall within audible frequency limits) then by all means use higher sampling rates.
• If you want to be able to reproduce sound levels which are painful or damaging, whilst preserving a signal-to-noise level which makes noise and distortion inaudible when you place your ear right up to the speaker, then by all means use more than 16 bits.
• If you want to feel superior to people using lesser bit depths and sampling rates - or want to make potential customers feel inadequate unless they buy your product and run at your exalted bit depths and sample rates - then by all means denigrate 44.1kHz 16 bit and make quasi-religious claims about fancier schemes. (These work a treat with the "if I don’t understand it, it must be profound" crowd.) When thinking about edited, ready-to-listen-to, audio, as far as I know, in any realistic listening situation, with proper care and the best techniques, there is no audible degradation in using 16 bit 44.1kHz stereo. By this I mean that if the physical sound level is such that the highest peaks won’t cause serious discomfort, then you won’t be able to hear the noise and distortion which is inherent in properly done 16 bit audio. There should be no distortion - because the dither should linearise it and the result becomes part of the 1 step noise floor. With care, it is not hard to get the frequency response flat from 30 Hz to 18 kHz, and for there to be no "phase distortion" - no shifting of signals according to their frequency. So all that is left is the dither and the way the dither interacts with the signals to linearise them, perceptibly several bits below the limits of a 16 bit system without dither.

Many people attest that they can hear the difference between 16 bit 44.1kHz audio and some higher sampling rate and/or bit depth. My response to this is that they are not necessarily listening to 16 bit 44.1kHz done properly - or alternatively that the difference they hear is actually that the other format does change the sound.

The only real test is to switch between a live (analogue microphone) signal and its digitised and regenerated version.

Most physical audio situations (rooms, outdoors etc. with a microphone) have a signal-to-noise ratio well below the ~96db inherent in a properly engineered 16 bit system. Good Delta-Sigma ADCs, as far as I know, are capable of remarkably good conversion of any waveform (apart perhaps from rail-to-rail square-waves and the like), and properly constructed oversampling DACs can work fine too. These can both work without any significant distortion, noise or phase problems.

Audio recorded at 96kHz with a 24 bit sample rate will be very hard to compress losslessly. Firstly, the sampling rate is over twice what I think it really needs to be. Secondly, of the 24 bits, only 14 to 16 are going to be of a musical signal and the rest will be random noise from:

• Noise in the environment picked up by the microphone.
• Brownian motion (random impact of air molecules) on the microphone diaphragm - which is reduced in proportion to the signal with a larger microphone.
• Electrical noise in the microphone amplifier and subsequent stages before the ADC. (Brownian motion is usually much higher then the electrical noise.)
• Noise from the ADC. Just because an ADC puts out 20 or 24 bits doesn’t mean that they are all signal. I think that even if you clamp the input to ground, the bits beyond 16, 17 or 18 will be random noise in most cases.

Below this, apart from a few fixes to typos and other things (which were important - thanks!) the page is basically as it was in January 2003.

---

• Tests of Shorten, MUSICompress/WaveZIP , WaveArc, Pegasus SPS (ELS-Ultra), Sonarc, LPAC , WavPack, AudioZip, **Monkey **and RKAU audio compression software.
• Links to material concerning the lossless compression (data reduction) of digital audio signals, including some other programs which I did not test.
• A detailed look at Rice coding and other techniques for compressing integers of varying lengths - particularly Elias coding and the work of Peter Fenwick. My particular interest is in delivery of music via the Net - with compression which does not affect the sound quality at all. I am primarily interested in compression ratios, not speed of the programs. This is the first web site devoted to listing all known lossless audio compression algorithms and software - please email your suggestions and I will try to keep it up-to-date.

Copyright Robin Whittle 1998 - 2000 rw@firstpr.com.au Originally written 8 December 1998. Complete new test series and update 24 November to 11 December 2000.

Latest update 13 January 2003. The update history is at the bottom of this page.

Back to the First Principles main page - for material on telecommunications, music marketing via Internet delivery, the Devil Fish TB-303 modification, the world’s longest Sliiiiiiinky and many and other show-and-tell items.

To the /audiocomp/ directory, which leads to material on lossy audio compression, in particular, comparing AAC, MP3 and TwinVQ.

This new series of tests was performed as a project paid for by the Centre for Signal Processing, Nanyang Technological University, Singapore. Dr Lin Xiao, of the Centre, whose program AudioZip is one of the ten programs I tested, was keen that my tests be independent. To this end, I used exactly the same test tracks I used in 1998, adding only two pink noise tracks which do not count towards the averages for file-size and compression ratio . Thanks to Lin Xiao and his colleagues for enabling me to do a proper job of this!

Let me know if you would like me to send you a dual CD-R set with all the test files so you can reproduce these tests yourself.

---

Tests: what can be achieved with lossless compression?

Short answer: 60 to 70% of original file-size with pop, rock, techno and other loud, noisy music; 35% to 60% for quieter choral and orchestral pieces.

My primary interest is in compression of 16 bit 44.1 kHz stereo audio files - as used in CDs. There are lossless compression systems for 24 bit and surround-sound systems. While I have a few links to these, they are not tested here. My tests are for programs which run on a Windows machine, though I have Linux machines as well, and some of these programs run under Linux too. I only found one Mac-only lossless compressor (ZAP) and have not tested it.

In my 1998 tests I was not interested in speed, but in November 2000, in view of the fact that the compression ratios of the leading programs were fairly similar, I decided to test their speed as well, since this varies enormously.

Five programs distinguished themselves with high compression ratios:

• Dennis Lee’s Waveform Archiver (WavArc).
• Tilman Liebchen’s LPAC.
• Lin Xiao’s AudioZip.
• Matthew T. Ashland’s Monkeys Audio.
• Malcolm Taylor’s RKAU. Since each program performed differently on different types of music, and since the choice of music in these tests is arbitrary, I cannot say with confidence that any of these programs will produce generally higher rates of compression than the others. With my particular test material, all five produce significantly higher rates of compression than the other programs I tested.

Since the difference between the best three programs and the next best three is only a few percent, many other factors are likely to influence your choice of which program is most useful to you.

A full description of the test tracks follows the test results themselves. All tracks were 44.1 kHz 16 bit stereo .WAV files read directly from audio CD and are either electronic productions or microphone based recordings - except for my Spare Luxury piece which was generated entirely with software. The music constituted 775 Megabytes of data - 73 minutes of music. The tabulation of these figures was done by MS-DOS directory listings and pasting the file-sizes as a block into a spreadsheet. (See notes below on exactly how I did it.) Those files are here: sizes9.txtand lossless-analysis.xls . I am pretty confident there are no clerical or other errors, but these intermediate documents enable you to check.

Audio files contain a certain amount of information - "entropy" - so they cannot be compressed losslessly to any size smaller than that. So it is not realistic to expect an ever-increasing improvement in lossless compression algorithm performance. The performance can only approach more closely whatever the basic entropy of the file is. No-one quite knows what that entropy is of course . . . I think that would require understanding the datastream in a way which is exactly in tune with it’s true nature. For instance a .jpg image of handwriting would appear to contain a lot of data, unless you could see and recognise the handwriting and record its characters in a suitably compressed format. The true nature of sound varies with its source, physical environment and recording method, and a lossless compression program cannot adapt itself entirely to the "true" nature of the sound in each piece of music. Therefore it is not surprising that different algorithms work best on different kinds of music.

Here are the test results, with the figures in the main body of the table showing the compressed file size as a function of the original size. Those instances which are the smallest are in bold-face, larger characters and with a green background. The average file sizes are the average of the file sizes of the test tracks 00 to 10. The average compression ratio is simply 100 divided by the average file size percentage. Except where noted (WaveArc -4 and with RKAU -l2 and -l3) I have selected the highest compression option for all programs tested.

The two test files 11PS and 12PM are pink-noise files with a -12dB signal level. 11PS is independent stereo channels and 12PM is the same signal on both channels - the left channel of 11PS. These are not realistic tests of compression of music, but they show something about the internal functioning of the programs. The compression ratios for these pink noise files do not contribute to the averages at the bottom of the table. It is unavoidably wide, so scroll sideways and print in landscape. The table alone, for those who want to print it, is available as an HTML file here: table.html.

	Shorten Tony Robinson	Wave Zip Gadget labs MUSI- Compress	Wav- Arc -4 Dennis Lee	Wav- Arc -5 Dennis Lee	Pegasus SPS jpg.com	Sonarc ***2.1i *** Richard ***P. *** Sprague	LPAC ***Tilman *** Liebchen	Wav- ***Pack *** ***3.6B *** David Bryant	Audio Zip Lin Xiao	Monkey 3.81B Matthew ***T. *** Ashland	RKAU 1.07 Malcolm Taylor
00HIChoral	37.23	44.81	36.49	34.73	36.69	40.91	39.57	41.77	40.28	38.98	33.28
01CESolo Cello	42.01	44.71	41.98	40.44	41.14	41.53	40.33	41.38	40.52	39.61	39.18
02BEOrchestra	55.68	57.99	42.00	40.72	42.43	53.15	40.55	43.89	43.48	39.86	39.01
03CCBallet	58.28	60.29	57.32	54.58	56.52	55.97	54.31	56.51	55.20	53.82	52.80
04SLSoftw. Synth.	42.54	45.23	42.02	39.64	40.70	40.99	39.61	41.88	40.65	38.32	33.06
05BMClub Techno	74.07	75.43	69.51	68.45	70.70	72.91	68.45	69.75	69.34	66.81	66.60
06EBRampant Techno	68.50	69.56	66.95	66.23	67.67	68.97	67.02	66.48	65.80	66.30	65.88
07BIRock	65.04	66.54	62.07	58.79	62.48	59.50	57.59	61.78	58.36	57.15	56.95
08KYPop	74.36	75.28	71.39	70.41	72.08	71.13	69.55	71.76	69.47	68.09	68.07
09SRIndian Classical 1	53.54	56.11	46.70	44.63	52.39	51.99	44.45	46.58	47.76	43.41	43.89
10SIIndian Classical 2	58.60	61.50	56.12	50.99	53.46	50.99	49.73	54.34	50.70	49.24	49.23
11PSPink noise	86.70	89.06	86.25	86.21	86.42	87.13	86.15	86.54	85.87	86.45	85.49
12PMPink noise mono	86.71	89.06	43.15	43.14	43.27	87.14	43.09	46.29	78.32	46.24	42.75
Average size Tracks 00 - 10	57.26	59.77	53.87	51.78	54.20	55.28	51.92	54.19	52.87	51.05	49.81
Average ratio Tracks 00 - 10	1.746	1.673	1.856	1.931	1.845	1.809	1.926	1.845	1.891	1.959	2.008
	Shorten	WaveZip	WaveArc -4	WaveArc *-5 *	Pegasus SPS	Sonarc	LPAC	Wave *Pack *	Audio Zip	Monkey	RKAU
Time to compress 3min 20sec Kylie pop track (500 MHz Celeron)	0:17	0:22	0:30	4:37	1:42	66:00	1:18	0:21	6:26	0:28	3:14

The compress time tests were performed with a 500MHz Celeron with 128MB of RAM and a 13Gig IDE hard disc. It took 7 seconds to copy the test file (00ky.wav 35.9 MB) from and to the disc. These figures should be regarded as accurate to only +/- 20%.

The test files are described below. 6 second 1 Megabyte sample waveforms are provided. The .wav files are stored in a directory which is not linked to exactly here, to stop search engines downloading them. The directory is /audiocomp/lossless/wav/ . Type this into your browser if you wish to download .wav files. Compression of these 6 second samples will no-doubt produce different ratios then compressing the entire file, due to variations in the sound signal from moment to moment.

After I did these tests, I discovered some non-ideal aspects of two files:

• The Orchestra track was in fact mono - both channels were almost identical. I think it was an old analogue recording.
• The Ballet file (Can Can) had 12 seconds of silence at the end. I have not changed them, since they are the same files as I used in 1998.

***Description of audio track *** (Size Megabytes)	***Average *** level dB	***Smallest *** ***file size *** ***as ratio *** of original	Length min:sec	Comments	Source
**Choral **- Gothic Voices: Hildegard von Bingen: Columbia aspexit (00HI.wav 55.9MB)	-29.5	34.7%	5:17		*A Feather on the Breath of God *Hyperion CDA66039
Solo cello - Janos Starker J.S. Bach: *Suite 1 in G Major *(01CE.wav 173.2MB)	-20.4	40.3%	16.45		Sefel SE-CD 300A (Out of print in 2005.)
Orchestra - Beethoven *3rd Symphony *(02BE.wav 43.6MB)	-21.1	40.6%	4.07	Mono	Berlin Philharmonic Music and Arts CD520, from a Classic CD magazine issue 54 cover disc.
**Ballet **- Offenbach, *Can Can *(03CC.wav 24.4MB)	-14.6	54.3%	2.18	12 sec silence	Unknown orchestra, Tek (Innovatek S.A. Bruxelles) 93-006-2
Software synthesis: my "Spare Luxury" Csound binaural piece (04SL.wav 85.0MB)	-20.5	39.6%	8.02		I made this in 1996. It has not been released on CD.
Club techno - Bubbleman (Andy Van): *Theme from Bubbleman *(05BM.wav 59.1MB)	-11.7	68.5%	5.35		Vicious Vinyl Vol 3 VVLP004CD
Rampant trance techno - ElBeano (Greg Bean): Ventilator(06EB.wav 44.0MB)	-14.3	65.8%	4.09		Earthcore EARTH 001
Rock - Billy Idol, White Wedding (07BI.wav 88.9MB)	-17.3	57.6%	8.23		Chrysalis CD 53254
Pop - Kylie Minogue, *I Should be so Lucky *(08KY.wav 35.9MB)	-14.9	69.5%	3.23		Mushroom TVD93366
Indian classical (mandolin and mridangam) - U. Srinivas:Sri Ganapathi (09SR.wav 71.7MB)	-12.1	44.4%	6.45		Academy of Indian Music (Sandstock) Aust.SSM054 CD
Indian classical (sitar and tabla) PT. Kartick Kumar & Niladri Kumar,: *Misra Piloo *(10SI.wav 89.4MB)	-19.4	49.7%	8.27		OMI music D4HI0627
**Pink noise stereo **(11PS.wav)	-12.2	85.8%	1.00
Pink noise mono (12PM.wav)	-12.2	43.1%	1.00

The 10 programs I tested

Shorten Tony Robinson

WaveZip Gadget labs (MUSI-Compress)

WavArc Dennis Lee

Pegasus SPS jpg.com

Sonarc 2.1i Richard P. Sprague

LPAC Tilman Liebchen

WavPack 3.1 David Bryant

AudioZip Lin Xiao Centre for Signal Processing, Nanyang Technological University, Singapore

Monkeys Audio 3.7 Matthew T. Ashland

RKAU Malcolm Taylor

FLAC Josh Coalson (Not tested yet.)

Any program listed as running under Windows 95 or 98 will presumably run under Windows ME, NT, 2000, XP etc.

Shorten Tony Robinson

Homepage	http://www.softsound.com/Shorten.html
email	info@softsound.com
Operating systems	MS-DOS, Win9x.
Versions and price	Win9x and demos free. More functional MS-DOS and Win9x version available for USD$29.95.
Source code available?	(In the past.)
GUI / command line	GUI & Command line.
Notable features	High speed.
Real-time decoder	In paid-for version.
Other features	+ Near-lossless compression available. + Shorten "supports compression of Microsoft Wave format files (PCM, ALaw and mu-Law variants) as well as many raw binary formats". + Paid-for version includes:

• Batch encoding and decoding.

• Creation of self-extracting encoded files.

• MS-DOS Command line encoder/decoder. | | Theory of operation | A 1994 paper by Tony Robinson is available at from this Cambridge University site. | | Options used for tests | GUI program: "lossless". |

Technical background to the program is at: http://svr-www.eng.cam.ac.uk/reports/abstracts/robinson_tr156.html . I tested version "2.3a1 (32 bit)" as reported in the GUI executable. This was from the shortn23a32e.exe installation file.

Seek information in Shorten files, and other programs which compress to the Shorten file format

There is another version of Shorten, "shortn32.exe" V3.1 at: http://etree.org/shncom.html. etree.org is concerned with lossless compression for swapping DAT recordings of bands who permit such recordings. This is an MS-DOS executable which reports itself (with the -h option) as:

shorten: version 3.1: (c) 1992-1997 Tony Robinson and SoftSound Ltd Seek extensions by Wayne Stielau - 9-25-2000

This adds extra data to the file, or as a separate file, to enable quick seeking within a file for real-time playback. It compresses and decompresses. I was unable to get it to compress without including the seek data, so I did not test it. I assume its performance is the same as the program I obtained from Tony Robinson’s site.

Another program based on Tony Robinson’s Shorten is by Michael K. Weise - a Win98/NT/2000 GUI program called "mkw Audio Compression Tool - mkwACT" http://etree.org/mkw.html . This generates compressed Shorten files with seek information. It can also compress to MP3 using the Blade codec. I tried installing the "version 0.97 beta 1" of this program, but there was an error.

Real-time players for Shorten files

In addition to the real-time player included in the full (paid-for) version of Shorten, there is a free plugin for the ubiquitous Windows MP3 (etc. & etc.) audio player Winamp http://www.winamp.com . The plug-in - ShnAmp v2.0 - http://etree.org/shnamp.html. This uses the special files with seek information produced by the programs mentioned above.

There is a functionally similar real-time player program for **Xmms **the X MultiMedia System (Linux: and other Unix-compatible operating systems):xmms-shnwhich is freely available, with source code, from: http://freeshell.org/~jason/shn-utils/xmms-shn/ .

---

WaveZip Gadget labs (MUSICompress)

Homepage	WaveZip http://www.gadgetlabs.com but see note below on availability. MUSICompress http://hometown.aol.com/sndspace
email	None.
Operating systems	Win9x. (MUSICompress command line demo program runs in DOS box under any version of Windows.)
Versions and price	Win9x evaluation version is free. A paid-for 24 bit upgrade was available, but Gadget Labs has now gone out of business. (MUSICompress command line demo program is free to use.)
Source code available?	No, but see the Al Al Wegener’s Soundspace site (below) for information and source code regarding the MUSI-Compress algorithm.
GUI / command line	GUI.
Notable features	High speed. Handles 8 and 16 bit .WAV files in stereo and mono. Also supports ACD (Sonic Foundry’s ACID) and BUN (Cakewalk Pro).
Real-time decoder	No.
Other features	Very handy file selection system
Theory of operation	Soundspace Audio’s page for their MUSICompress algorithm: http://hometown.aol.com/sndspace See notes below.
Options used for tests	There are no options. (But see note below on commandline version of MUSICompress.)

On 1 December 2000, Gadget Labs ceased trading and put some of its software in the public domain, with the announcement:

"We regret to announce that Gadget Labs is no longer in business. We sincerely appreciate the support from customers during the last 3 years, and we regret that we didn’t meet with enough success to be able to continue to deliver our products and service. This web site includes technical information and software drivers that are being placed in the public domain. Please note that usage of the information and drivers contained here is at the user’s sole discretion, responsibility, and risk."

Gadget Labs was primarily known for its digital audio interface cards. A Yahoo Groups discussion group regarding Gadget Labs is here. The WaveZip page at their site (wavezip.htm) has disappeared. There is no mention of WaveZip at their site at present. For now, I have placed the evaluation version 2.01 of WaveZip in a directory here: WaveZip/ . It is 2.7 megabytes.

In October 2001, Al Wegener wrote to me to point out the command line demo version of MUSICompress which is available for free (subject to non-disclosure and no-dissassembly) at his site. He wrote:

Even though the console interface is not nearly as nice as WaveZIP was, people can still submit WAV-format files to this PC app and both compress and decompress their files. This version also supports lossy compression, where users can play with a decrease in quality (one LSB at a time), vs. an increase in compression ratio.

By the way, I’ve gotten several new customers recently that use MUSICompress specifically because it’s fast. On many of these customers’ files, an extra 10% compression ratio just isn’t worth a 20x wait.

MUSI-Compress Theory

The information sheet at: http://members.aol.com/sndspace/download/musi_txt.txt indicates that MUSI-Compress is capable of reducing rock recordings to between 60 and 70% of their original size. An informative paper from the developer, Al Wegener, is available in Word 6 format from the Soundspace site. MUSICompress is written in ANSI C using integer math only. It has been ported to at least two DSPs and is used in the WaveZIP program (see below).

There is also a Matlab version, and the documentation which comes with this indicates that MUSICompress typically uses:

Compression requires between 35 and 45 instructions per sample. Expansion requires between 25 and 35 instructions per sample

According to Al Wegener, like other commercial lossless audio compression algorithms, MUSICompress uses a predictor to approximate the audio signal - encoding the prediction data in the output stream - and then computes a set of difference values between the prediction and the actual signal. These difference values are relatively small integers (in general) and these are compressed using Huffman coding and sent to the output stream. The compress and decompress functions can apparently be implemented in hardware with 4,700 gates and 20,500 bits of RAM (compress) and 3,800 gates and 1,500 bits of RAM (decompress) - which sounds pretty snappy to me.

The diagram to the left, from the abovementioned paper, depicts the approach taken by all the compression algorithms reviewed on this page. The raw signal is approximated by some kind of "prediction" algorithm, the parameters of which are selected to produce a wave quite similar to the input waveform. Those parameters are different for each frame (say 256 samples) of audio and are packed into a minimum number of bits in the output file (or stream, in a real-time application). Meanwhile, the difference between the "predicted" waveform and the real signal is packed into as small a number of bits as possible. Often, the "Rice" coding (AKA Rice packing) algorithm is used, but MUSI-Compress uses Huffman packing instead. Some of the material mentioned below contains more detailed theoretical descriptions of Rice packing and other algorithms - and I have my own explanation below. This diagram is relevant to all the lossless algorithms I know of. (I worked on my own algorithm which worked on different principles for a while - but it did not work out well. A good "prediction" system is crucial.) The predictor is replicated in the decoder - and it must work from prediction parameters and the previously decoded samples. The predicted value is added to the "error" value to create the final exactly correct value for that sample. Then the prediction algorithm is run again, based on the newly decoded sample and some previous ones, to predict the next sample.

---

WavArcDennis Lee

Homepage	Unknown - but the program is available here: wavarc/..
email	Unknown.
Operating systems	MS-DOS. (ie, in an MS-DOS window in Win9.x.)
Versions and price	Free.
Source code available?	No.
GUI / command line	Command line.
Notable features	Potentially very high compression. Multiple files stored in one archive.
Real-time decoder	No.
Other features	High compression ratio. Selectable speed/compression trade-off. Compresses WAV files and stores all other files without compression in the archive.
Theory of operation	?
Options used for tests	"a -c4" and "a -c5".

Dennis Lee’s Waveform Archiver is a freeware command-line program to run under MS-DOS or in a Windows command line mode. It can store multiple .WAV files in a single archive.

Dennis Lee’s web page: http://www.ecf.utoronto.ca/~denlee/wavarc.htm disappeared sometime in 1999. Emails to that site (University of Toronto) enquiring about him have not resulted in any replies.

No source code was available, and there was no mention of what algorithms are used. This program was made available on a low-key basis - but its performance in "compression level 5" mode significantly exceeds the alternatives that I was aware of when I did my first rounds of tests in late 1998. When compressing, I found that the report it gives on screen about the percentage file size is sometimes completely wrong. I tested version 1.1 of 1 August 1997.

Dennis told me by email on 4 December 1998 that he had done a lot of work on version 2.0 of Waveform Archiver - but is not sure when it will be finished:

Shortly before completing WA v2.0 I became involved with another project full-time, and haven’t been able to work on WA since. WA v2.0 has some significant improvements including:

1) Faster at all compression settings.

2) -c6 codec (slightly more optimal than v1.1’s -c5).

3) A new -c5 that’s much faster (about half the speed of -c4). This new codec is both backward and forward compatible with v1.1’s -c5.

4) Lossless compression for non-audio files (provided by zlib).

5) Several bug fixes including the incorrect compression status on large files.

I hope to continue work on WA when I find the time.

WavArc began life in 1994, as explained in wavarc/WA.TXT . I would be very glad to hear of Dennis Lee. I did an extensive web search in November 2000, but found no leads.

---

Pegasus SPSjpg.com

Homepage	http://www.jpg.com/products/sound.html
email	sales@jpg.com
Operating systems	Win9x.
Versions and price	Full version USD$39.95. Evaluation version limited to 10 compressions.
Source code available?	No.
GUI / command line	GUI.
Notable features	WAV files, 8 and 16 bit, stereo and mono.
Real-time decoder	No.
Other features	Batch compression in paid-for version.
Theory of operation	http://www.jpg.com/imagetech_els.htm for generalised ELS algorithm.
Options used for tests	There are no options.

In 1997 Krishna Software Inc. http://www.krishnasoft.com. wrote a lossless audio compression program for Windows. The program has some limited audio editing capabilities and several compression modes, but the most significant lossless compression algorithm - ELS - comes from Pegasus Imaging, http://www.jpg.com who seem to have developed it initially for JPG image compression. The SPS program is available from both companies.

Pegasus-SPS provides four lossless compression modes and has the ability to truncate a specified number of bits for lossy compression. I used the default and highest performance "ELS-Ultra" algorithm for my tests. This was reasonably fast and produced results a fraction of a percent better than the next two best performing algorithms. When the compression function is working, this program seems to use virtually all the CPU cycles - at least under Windows 98 - so don’t plan on doing much else with your computer!

Some information on ELS - Entropy Logarithmic Scale - encoding is at: http://www.pegasusimaging.com/imagetech_els.htm this leads to a .PDF file which has a scanned version of a 47 page 1996 paper explaining the algorithm: "A Rapid Entropy-Coding Algorithm" by Wm. Douglas Withers.

I tested version 1.00 of Pegasus-SPS.

---

Sonarc 2.1i Richard P. Sprague

Homepage	None.
email	None.
Operating systems	MS-DOS.
Versions and price	Was shareware, but author is uncontactable.
Source code available?	No.
GUI / command line	Command line.
Notable features
Real-time decoder	No.
Other features
Theory of operation	?
Options used for tests	"-x -o0" = use floating point and for each frame, search for the best order or predictor.

Sonarc, by Richard P. Sprague was developed up until 1994. His email address was "76635.652@compuserve.com" but in December 1998, this address was no longer valid. Sonarc has quite good compression rates, but it is very slow indeed.

There is an entry for it in the speech compression FAQ http://www.speech.cs.cmu.edu/comp.speech/Section3/Software/sonarc.html . Sonarc is also listed in Jeff Gilchrist’s magnificent MS-DOS/Windows "Archive Comparison Test" site http://compression.ca/act/act-index.html which gives an FTP site for the program: ftp://ftp.elf.stuba.sk/pub/pc/pack/snrc21i.zip . This is the program I tested: version 2.1i. You can get a copy of it here: sonarc/ . The programs are MS-DOS executables, dated 27 June 1994. The documentation file, with the shareware arrangements and author’s contact details is here: sonarc/sonarc.txt . (A page of links regarding speech coding and the like: http://www.answerconnect.com/articles/speech-resources .)

---

LPAC Tilman Liebchen

Homepage	http://www.nue.tu-berlin.de/wer/liebchen/lpac.html
email
Operating systems	Win9x/ME/NT/2000, Linux, Solaris.
Versions and price	Free.
Source code available?	Tilman Liebchen writes that he is contemplating some form of availability, and that "the LPAC codec DLL can be used by anyone for their own programs. I do not supply a special documention for the DLL, but any potential user can contact me.".
GUI / command line	GUI and command line. In the future (Dec 2000) the LPAC codec DLL will operate as part of the Exact Audio Copy CD ripper.
Notable features	8, 16, 20 and 24 bit support.
Real-time decoder	Yes, and a WinAmp plug-in.
Other features	High compression ratio. CRC (Cyclic Redundancy Check) for verifying proper decompression.
Theory of operation	Tilman Liebchen writes "adaptive prediction followed by entropy coding".
Options used for tests	Extra High Compression, Joint Stereo and no Random Access.

Tilman Liebchen is continuing to actively develop LPAC, the successor to LTAC which I tested in 1998. The results shown here are for the "Extra High Compression" option with "Joint Stereo" and no "Random Access". The Random Access is to aid seeking in a real-time player, and adds around 1% to the file size. But see the sizes9.txt for the actual file sizes. In all cases not using the "Joint Stereo" option produced files of the same size or larger.

On 17 January, Tilman wrote:

The new LPAC Codec 3.0 has just been released. It offers significantly improved compression ("medium" compression is now better than "extra high" compression was before) together with increased speed (approx. factor 1.5 - 2). I would be lucky if you could test the new codec and put the results on your page.

I haven’t tested it yet.

---

WavPack 3.1 David Bryant

Homepage	http://www.wavpack.com
email	david@wavpack.com
Operating systems	MS-DOS
Versions and price	Free. Version 3.1 and 3.6 Beta.
Source code available?	No.
GUI / command line	Command line.
Notable features	High speed.
Real-time decoder	WinAmp plugin currently being developed.
Other features	Compresses non .WAV files, including Adaptec .CIF files for an entire CD. Nice small distribution file < 82 kbytes.
Theory of operation	http://www.wavpack.com/technical.htm
Options used for tests	No options affected the lossless mode.

I tested version 3.6 Beta of WavPack, using the -h option for the high compression mode which Dave Bryant added in 3.6. WavPack is freely available, without source code but with a good explanation of the compression algorithm. It is intended as a fast compressor with good compression ratios for .wav files. Compression and decompression rates of 8 times faster than audio are achieved on a Pentium 300 MHz machine. The algorithm makes use of the typical correlation which exists between left and right channels in a stereo file. Two additional features are lossless compression of any file, with high compression for those containing audio (such as CD-R image files) and selectably lossy compression.

---

AudioZip Lin Xiao Centre for Signal Processing, Nanyang Technological University, Singapore

Homepage	Was: http://www.csp.ntu.edu.sg:8000/MMS/MMCProjects.htm This is now defunct. Lin Xiao will let me know of a new site soon. (17 July 2002)
email	Lin Xiao (Dr) Previously at EXLIN@ntu.edu.sg He is now longer with the University. Please contact me if you want his email address.
Operating systems	Win9x.
Versions and price	Free.
Source code available?	No.
GUI / command line	GUI.
Notable features	High compression ratio.
Real-time decoder	No.
Other features
Theory of operation	"LPC with Rice encoding."
Options used for tests	Maximum.

The current version of AudioZip is rather slow - at least at the Maximum compression mode, which I used in these tests. Its user interface is quite primitive, for instance it is necessary to manually enter the name of each compressed file. However Lin Xiao writes that he and his team are working to make AudioZip faster and more user friendly. See the note below in the RKAU section on how AudioZip and RKAU achieved the highest compression ratios for the pink noise file.

---

Monkey’s Audio 3.7 - 3.81 Matthew T. Ashland

Homepage	http://www.monkeysaudio.com
email	email@monkeysaudio.com
Operating systems	Win9x.
Versions and price	Free.
Source code available?	"Freely available source code, simple SDK and non-restrictive licensing - other developers can easily use Monkey’s Audio in their own programs – and there are no evil restrictive licensing agreements."
GUI / command line	GUI and command line. Encoder can be used by Exact Audio Copy CD ripper.
Notable features	High speed and high compression.
Real-time decoder	Standalone program and plugins for Winampand Media Jukebox. Also, apparently available as a plugin for Windows Media Player: http://www.mediaxw.org .
Other features	CRC checking. Includes ID3 tags as used in MP3 to convey information about the track. Can be used as front end for other compressors, including WavPack, Shorten and RKAU. Compresses WAV files, mono or stereo, 8, 16 or 24 bits.
Theory of operation	Adaptive predictor followed by Rice coding. http://www.monkeysaudio.com/theory.html
Options used for tests	Command line version -c4000.

I tested the command line 3.81 Beta 1 commandline-only version of Monkey’s Audio, using the -c4000 option for highest compression. A separate renamer program is handy for changing the extension of file names - it can recurse into sub-directories. Monkey’s Audio is actively being developed - in April 2002, the version was 3.96.

---

RKAU Malcolm Taylor

Homepage	http://rksoft.virtualave.net/rkau.html
email	mtaylor@clear.net.nz
Operating systems	Win9x.
Versions and price	Free.
Source code available?	No.
GUI / command line	Command line. (But Monkeys Audio can be a GUI front end.)
Notable features	High compression.
Real-time decoder	Winamp plugin.
Other features	Selectable lossy compression modes. Can include real-time seek information for use with realtime players.
Theory of operation	?
Options used for tests	-t- -l2 -t- -l2 -s- -t- -l3 -t- -l3 -s-

I tested the v1.07 version, with options -t-" to not include real-time tags. Malcolm told me that the highest compression option "-l3" sometimes produced compression lower than "-l2", so I tried both options. Likewise the program’s default behaviour of assuming there is something in common with both stereo channels does not always lead to the best compression. I tried RKAU with and without the -s- option, giving me four sets of file sizes. See ( oops - this file has gone missing: analysis-rkau-107.html ) for these results and the "best-of" set chosen from the four options. The best-of set is reproduced below. These are the figures I have used in the main comparison table.

	***With or without -s- *** to disable separate stereo channels	Either -L2 or -L3	Best of RKAU 1.07 -t- with or without -s- and at either -l2 or -l3	%
00HI	-s-	L2	18,610,940	33.28
01CE		L3	69,471,291	39.18
02BE		L3	17,001,008	39.01
03CC		L3	12,879,953	52.80
04SL	-s-	L3	28,109,211	33.06
05BM		L3	39,382,534	66.60
06EB		L2	28,985,245	65.88
07BI		L3	50,598,306	56.95
08KY		L3	24,435,044	68.07
09SR		L2	31,464,353	43.89
10SI	-s-	L2	44,015,255	49.23
11PS	-s-	L3	9,048,056	8