Why there are so many lossless audio codecs? Mike, obviously, had his thoughts on that subject and I agree with my another friend who said: “it’s just too easy to create lossless audio codec, that’s why everybody creates his own”.
Well, theory is simple: you remove redundancy from samples by predicting their values and code the residue. Coding is usually done with Rice codes or some combination of Rice codes and an additional coder — for zero runs or for finer coding of Rice codes. Prediction may be done in two major ways: FIR filters (some fixed prediction filters or LPC) or IIR filters (personally I call those “CPU eaters” for certain property of codecs using it). And of course they always invent their own container (I think in most cases that’s because they are too stupid to implement even minimal support for some existing container or even to think how to fit it into one).
Let’s iterate through the list of better-known lossless audio codecs.
- ALAC (by Apple) — nothing remarkable, they just needed to fit something like FLAC into MOV so their players can handle it
- Bonk— one of the first lossless/lossy codecs, nobody cares about it anymore. Some FFmpeg developers had intent to enhance it but nothing substantial has been done. You can still find that “effort” as Sonic codec in
libavcodec. - DTS-HD MA — it may employ both FIR and IIR prediction and uses Rice codes but they totally screwed bitstream format. Not to mention there’s no openly available documentation for it.
- FLAC — the codec itself is good: it’s extremely fast and features good compression ratios. The only bad thing about it is that it’s too hard to seek properly in it since there’s no proper frame header and you can just hope that that combination of bits and CRC are not false positive.
- G.711.0 — have you ever heard about it? That’s its problem: nobody cares and nobody even tries to use it.
- MLP/Dolby True-HD — it seems to be rather simple and it exists solely because there was no standardised lossless audio codec for DVD.
- Monkey’s Audio — well, the only good thing about is that it does not seem to be actively developed anymore.
- MPEG-4 ALS — the same problem: it may be standardised but nobody cares about it.
- MPEG-4 SLS — even worse since you need bitexact AAC decoder to make it work.
- OggSquish — luckily, it’s buried for good but it also spawned one of the worst container formats possible which still lives. And looking at original source of it one should not wonder why.
- RealAudio Lossless Format — I always say it was named after its main developer Ralph Wiggum. This codec is very special — they had to modify RM container format specially for it. A quick look inside showed that they use more than 800 (yes, more than eighty hundred) Huffman tables, most of them with several hundreds of codes (about 400 in average). That reminds me of RealVideo 4 with its above-the-average number of tables for context-dependant coding.
- Shorten — one of the first lossless audio codecs. Hardly anyone remembers it nowadays.
- TAK — it was originally called YALAC (yet another lossless audio codec) for a reason. Since it’s closed-source and fortunately not widespread (though some idiots use it for CD rip releases), it just annoys me time from time but I don’t think someone will work on adding support for it in FFmpeg.
- TrueAudio (TTA) — I can say anything about it except it seems to be quite widespread and it works. Looks like they’re still alive and work on TTA2 but who cares?
- WavPack — that’s rather good codec with sane bitstream format too. Looks like its author invested some time in its design. Also he sent patches to implement some missing features in our decoder (thank you for that!).
- WMA Lossless — from what I know, it uses IIR filter based on least minimum squares method for finding its coefficients. It has two peculiarities: that filter is also used for inter-channel decorrelation and bitstream format follows WMA9 format, i.e. it has something like interframes and frame data starting at arbitrary point (hello, MP3!).
P.S. I still hope this post won’t encourage anybody to write yet another useless lossless audio decoder.
So, in short, wavpack wins. ;p
It’s interesting how quickly you dismiss SLS for being a hybrid coder with AAC. From a pure lossless standpoint that is a weakness but from a broader perspective it allows for a lossy layer that is widely compatible with existing hardware.
I think ALS has the most potential since it is a standard. Hopefully if we get a popular standardised codec that will put people off bothering making their own?
The biggest problem with ALS is lack of implementation. Give people an encoder and decoder and they will use it. Obviously I’m not saying piracy is good or anything, but if people started using ALS in their albums and stuff, people would soon become aware of it.
you forgot optimfrog…
Well, Tak ist highly fast and at the same time has a high compression ratio so it’s not that bad. Although it’s a pity, it is not open source which is probably why it lacks some features.
But in the end wavpack wins in general and flac in compatibility.
I recommend TAK. It’s good for both archiving and playing. Comparing with FLAC, it’s faster at seeking and usually compresses more; however, the decompression speed is not as fast as FLAC’s, but it’s faster than WavPack, at least. To compare it with Monkey’s Audio, TAK is much faster and better at error handling and can compress more. Though, I don’t see why I should even mention Monkey’s Audio when it really just sucks.
As for DTS-HD Master Audio, have you ever taken a look at the ETSI document “TS 102 114 V1.3.1 (2011-08)” ?
@JMK
Yes — that specification is known to be incomplete and sometimes wrong. You might be able to reconstruct lossless audio for channels that are pure lossless, but do you know how to reconstruct signal from lossy DTS core in order to combine it with lossless corrections and obtain lossless stream? What about reconstructing lossless audio with sampling rate above 96kHz?
Anyway, I’d like to see someone writing decoder for it just in spite.