Wouldn't it make more sense to implement a lossless codec in the frequency domain? It seems as though there would be much more redundancy in audio when it is perceived as frequencies rather than when it is perceived as pulses in time, although the two are equivalent.

I'm assuming that this is not done because it is difficult to implement and doesn't give real-time decoding or anything. Am I correct here? Or are there fundamental problems bigger than these to contend with?

As there seems to be a shift in the lossless codecs to allow for a lossy mode, it seems like it would make more sense to use a frequency-centred basis for that lossy mode, to better implement basic psychoacoustics.

Or am I completely off-base here? Comments? Ideas?

This might be interesting for you: http://www.nue.tu-berlin.de/wer/liebchen/ltac.html

And the paper: http://www.nue.tu-berlin.de/wer/liebchen/d...ocs/ltac161.pdf

Those are based around the DCT transform. I believe at the Fraunhofer institute people are researching lossless compression based around the intMDCT transform.

Ooh! Yummy, shiny PDFs! The Society for the Advancement of Canar's Audio Knowledge thanks you greatly.

I remember Naoki was once working on something like this as a "secret project", but haven't heard about it ever since.

The thing is, the technique of transforming the audio signal, quantizing/encoding the transform signal (probably LPC) and then encoding the quantisation error (probably Huffman/RLE) seems like a simple and obvious enough method of lossless audio compression that if it worked as well or better than current methods (LPC mainly, iirc), someone would already have released an encoder based on this technique.

*shrug*

I'm just thinking that even if the pure lossless mode is mostly unimpressive, it will be the high-bitrate lossy areas where this sort of codec would really shine, if you threw a little psychoacoustics into the mix.

you are right canar. MPEG are currently developing a scalable lossless coding standard which is building around a transform structure, and embedded an AAC bit-stream in the lossless bit-stream. Interestingly the compression performance of this scalable lossless codec is very, very close to a non-scalable one.
Check this paper (http://www.icme2003.com/Papers/viewpapers.asp?papernum=1276) if you want a sneak preview ...

Oooh! Who called it?

I'll check that out this afternoon.

I would assume that there are few (or no) transform based lossless encoders is the difficulty of keeping them lossless. Basically it would be rather difficult to write a transform->compress->synthesis program which kept it's input and output bit-identical while not wasting any bits.

I would assume their are approaches for doing this, but it's likely to be more difficult (cpu intensive and design intensive) to compress this way rather than in the time domain. It would also be a pretty difficult job to test that it is indeed lossless even for waves that are very difficult to transform (waveforms with discontinuities, mostly).

In audio compression, there's no such thing as a discontinuity. At maximum, there's a frequency at half the sampling rate. There's no signal at any frequency higher than that, thanks to our good buddy Nyquist.

Edit: Furthermore, there is already a lossless transform audio encoder, ltac, at a previous link. It isn't quite as efficient as FLAC (which is saying something), and isn't being actively developed, but there's gotta be more efficient ways to do the job. Wavelets, maybe?

Yeah - I didn't remember that the wave had been sampled at 44100Hz before being fed to the transform. I hadn't remembered that the signal gets completely band limited by the sampling process long before an encoder can touch it.

I read the LTAC paper and was very impressed by it. I wish I knew enough German to make sense of his thesis.

I am busy in the process of writing a quick piece of Python to take an audio sample, DCT it and feed the quantized coefficients to bzip2. Based on my preliminary results it looks like even this very simple approach can bring better compression than just bzipping the wav, how much I am not sure yet. I will post final results when I have verified that I can retrieve the original signal bit-perfectly and have tested it with a couple of samples.

This piece of code will go along with my JPEG sound encoder into the "Usless Audio Encoders" hall of fame.

A discrete wavelet transform would probably even work better, although it'd likely be a little (lot?) harder to code.

I've tried using a lifting integer wavelet transform to split the signal into different subbands and then applying simple linear predictors to the subbands (coding the residual signal using a Rice-like encoding based on an average over the last x samples) together with a friend of mine. This gave me compression that was quite good for a home-brewn project but not as good as FLAC's or Monkey's (ours: 59%, FLAC: 55%, Monkey's: 52%, maximum settings, four music files).
If anyone is interested the source code can be found on:
http://sourceforge.net/projects/pws-sces/
I also still have all the config files we used for our tests (as well as a comprehensive manual in Dutch, test results, histograms of the residual signal, etc.).

I'd hardly think a linear predictive compression mechanism would be optimal for a wavelet...

Did you try some common lossless compressors, ie. RAR/7z on the signal? I'd try it, but I understand neither c++ nor its compilers.

In fact it's very sensible to use linear predictors on the subbands (a separate one for each subband mind you), as the subbands are essentially audio signals too, only hopefully more predictable. I haven't tried compressing them with RAR or 7zip, but I wouldn't expect better results, as they are usually not that good on normal audio signals. RAR might be interesting because of it's multimedia compression, but then using a normal lossless audio compressor would probably make more sense. I think I'll try that.

Here are some quick results:
Rainforest Magic:
Original: 3,783,234 (3.60 MB)
LA: 1,589,169 (1.51 MB)
FLAC: 1,922,108 (1.83 MB)
MAC: 1,659,264 (1.58 MB)
LA, 2 subbands: 1,760,872 (1.67 MB)
FLAC, 2 subbands: 1,848,179 (1.76 MB)
MAC, 2 subbands: 1,823,968 (1.73 MB)
LA, semi stereo: 1,699,652 (1.62 MB)
FLAC, semi stereo: 1,842,135 (1.75 MB)
MAC, semi stereo: 1,855,924 (1.76 MB)

Ausente:
Original: 20,676,476 (19.7 MB)
LA: 10,246,817 (9.77 MB)
FLAC: 11,108,314 (10.5 MB)
MAC: 10,612,728 (10.1 MB)
LA, 2 subbands: 10,326,052 (9.84 MB)
FLAC, 2 subbands: 10,871,151 (10.3 MB)
MAC, 2 subbands: 10,639,592 (10.1 MB)
LA, semi stereo: 10,320,026 (9.84 MB)
FLAC, semi stereo: 10,856,286 (10.3 MB)
MAC, semi stereo: 10,712,704 (10.2 MB)

Chains:
Original: 23,161,364 (22.0 MB)
LA: 13,634,434 (13.0 MB)
FLAC: 14,539,195 (13.8 MB)
MAC: 13,986,996 (13.3 MB)
LA, 2 subbands: 13,782,001 (13.1 MB)
FLAC, 2 subbands: 14,382,005 (13.7 MB)
MAC, 2 subbands: 14,127,728 (13.4 MB)
LA, semi stereo: 13,775,452 (13.1 MB)
FLAC, semi stereo: 14,365,873 (13.7 MB)
MAC, semi stereo: 14,286,844 (13.6 MB)

I converted each file to mono, compressed that file with La (-high), FLAC (-8) and Monkey's Audio (High), split the file into two subbands (each half the size of the original) and compressed those with La (-high), FLAC (-8) and Monkey's Audio (High). For the "semi stereo" results I combined the two subbands into one stereo file (each subband got its own channel).
I used the Bspline coefficients from my program (came from 'Factoring Wavelet Transforms Into Lifting Steps', http://cm.bell-labs.com/who/wim/papers/factor/).
If anyone else would like to test some files, I have a prebuilt Windows binary lying around, as well as the config file used to split the file into subbands (which can be modified to split the signal into as many subbands as you'd like).

Judging from the above results (and tests I performed earlier) I'd say there is a chance to improve FLAC's compression somewhat, but probably not passed the performance of Monkey's or La. And even if someone would be able to tweak the algorithms in such a way that Monkey's (or perhaps La) responded better to the subbanding I think it would still be a marginal difference, but I'd be delighted if someone would prove me wrong.

BTW, I also tried compressing with 7zip and RAR, but they both performed quite bad (16 and 15 MB respectively, I used "Ultra" and solid archive with 7zip and solid archive with RAR, forcing audio compression actually resulted in a worse ratio).

EDIT: Added LA and semi stereo results and added the original file size as a reference.

replying to the first 2 posts on this thread:

the LTAC compression tool is SOOO outdated. Even the original author saw daylight and moved back to time domain prediction with LPAC.

In an email he wrote me, he said that he has worked on an LPAC successor which will probably selected as lossless codec for MPEG4. (or something like that).

It's hard for audio transform codecs to be lossless AND efficient. Time domain approaches are most promising although there are lossless transforms like integer wavelet and such.

As for the lossless integer wavelet subband decomposition:
- it introduces alias (like any subband decomposition)
- the gain of one subband is increased (doubled amplitude)
These 2 effects negativly affect "compressability".

bye,
Sebastian

It has already been selected as lossless MPEG4 audio codec.

Wow!
Well, the contact was some time ago :-)

Is there some kind of specification draft available online anywhere ?

edit:
If someoe besides me cares about this:
MPEG4 ALS
Oups... I'm just realizing it's a bit off topic now