im wondering which lossless codec people use the most.

i know this is a place for lossy coding stuff, but i know of no other place like this for lossless coding technology questions.

thanks!

I think the "Best lossless codec" question isn't very appropiate.

It all depends on each person's needs.

Monkey's Audio compresses the most* and is the fastest. Besides, it's source is open.

Flac is good if you want to play it on every platform. (Or if you are a GNU freak)

WavPack has this great hybrid mode.

And Shorten is the most used for sharing.

I, for instance, would be in doubt between Monkey (For it's superior encoding engine) and Wavpack (For the hybrid feature)

Regards;

Roberto.

*Although sometimes RKau and Frog compress better. They're too slow, unfortunately.

I use LPAC... for no other reason except it's the codec I downloaded & started using first. It gets the job done.

I use Monkey's Audio - easy to use, compresses a lot, and it's the first one I started using .I may one day give OptimFrog a try, though

To Lossless Compress Audio Losslessly or otherwise so that more will fit and play on a standard cd player? Thanks Jeff

I made a performance comparison of the most popular lossless compressors: http://home.wanadoo.nl/~w.speek/comparison.htm

optimFrog for storing.
Anything else: FLAC...I think it's supose to get replaygain feature in the future.

I've tried FLAC and LPAC and settled on LPAC because it has a nice frontend. My only niggle with it is that it seems to hog a far share of CPU time so if I'm LPACing a lot of files I stick the process on Below Normal in taskman. I know there is an Idle/Normal/High slider but it dont seem to have much effect for me.

Nope, no can do. You got 80-minute CD's, but maybe try using a 99-minute CD as well. After that, you're at the limits of CD-DA.

In fact there is one hardware platform at the moment that supports flac compressed files: The PhatNoise Phatbox:
http://phatbox.sixpak.org/phatbox/flac.phtml

Phatnoise homepage

Tried Monkey had to many errors. Could not get it to work, whether it was hardware or software does matter at this point. Lpac did the job just fine.

Why do you need a frontend, just use it with EAC

Fastest at encoding... I would say that if you plan to ever listen to them on something else than a PC that you also investigate decoding times. Several other codecs are faster when it comes to decoding than the adaptive ones (MAC, FROG, etc) where the encoding and decoding times are symmetric.

Josh

I would no errors in Monkey's Audio. Code
is very easy to read (I would say it's one of the
best readble software I saw in the last 5 years).

May be I will add some code for hardware checks
in it and stop the program if the hardware is
defect.

Definately FLAC for portability, decompression speed and small CPU useage when playing the FLAC files through for example Winamp... (I use it all the time... FLAC that is...)

Flac's compression ratio is very poor (imho Monkey's the best lossless).


Bye, dB

This is certainly true. My hardware was found to be inept when using Monkey's. The only way I solved CRC errors was lowering FSB and increasing CPU multiplier. People with problems might want seriously consider the FSB/multiplier solution, it seems there's a lot of glitchy RAM sticks out there which Monkey's will reveal as deficient.

Monkeys audio is good, but seems you pushed that overclock a little too much...

Not at all.

System is supposed to be 3.5x100.

North bridge introduced errors until underclocked to 4.0x83.3

Monkey's errors ceased at 4.5x75.0

Very poor? ~2-3% better compression than FLAC... That unfortunatly doesn't justify using it when it's not 100% cross-platform... Also, APE requires too much processing power for playback so we'll likely never see a hardware player with support for it...

Too much power for playback of Monkey's Audio files? Granted I'm running a 1.3Ghz Athlon, but playback of Monkey's Audio files in winamp consumes as much or less CPU than playback of MP3 and Musepack files. Doing one right now and Winamp peaks at 2-4% CPU about every four seconds or so then drops back down to 0%.

At least with the winamp plugin I'm seeing no performance issues whatsoever with APE files.

CPU usage in Windows, in a Winamp plugin, on a 1.3GHz Athlon is not a good indicator of codec complexity when you're talking about embedded hardware. MAC is less demanding than MP3 to decode, but most embedded MP3 implementations use custom hardware for decoding, a luxury not afforded to any but the most popular codecs.

You really need to analyze the actual format. In MAC's case you can reverse-engineer it from the source. For FLAC you can just read the spec.

Josh

1. Nice that the file format is documented. But it is not proven that it can be used
to write an independent encoder/decoder. Therefore standardization commitee
often requires a 2nd independent implementation. And even this do not
guarantees that you will be able to write an decoder in 2002 when you found
some files and the file format documenation.

2. With my knowledge it was very easy to port Monkey's Audio to Linux/gcc.
Time effort was something around 2...4 hours. It is really nice structured
and easy to read (Note: I have little skills with C++ and Windows).

3. Current there 2 projects which I can't translate: Flac and Ogg/Vorbis.
I have no idea what happens in the autoconf/automake/libtool ...
stuff around. It terminates with a syntax error.

I prefer reading and fixing some well written C code (even when not portable)
over a huge bunch of recursively called scripts where version 1.4 is incompatible
to 1.4.3a

4. I know that the MPC source in the current state is also a big heap of
shit. Adding features and morphing code without redesign.

Archiving software (10++ years usability) must be written that you can compile it
on a 12 year old computer and on a computer in 2014. A lot of special tools
is not the right method.

Often I have more trouble to port Linux programs to Linux than Windows console
programs to Linux. This sounds like a joke, but it isn't one.

Even if it was true that APE requires too much processing power for portable use (its not), its a moot point whether APE support appears in portables for most of us... Lossless files are simply too large to be in major demand for the portable market, and thus development will likely not bother implementing them, outside of niche products.

For the real purpose of lossless (archival, and/or lossless playback on pc), MAC is by far the most robust. Other codecs are still having problems with tagging, seeking, compression, encoding speed, where MAC leads in each category. I will be interested to see where development in MAC heads, as there aren't any major weaknesses. While we can always hope for more compression, I've read the MAC dev say he is running short of new ideas in that direction. Maybe with the source available he can get some help with that.

Some question about FLAC:

- I was not able to compress files with more than 8 channels.
Nonsense? At the IFA 2001 there was a 64 channel demonstration.
That other programs only support 1 and 2 channels is not an excuse.

- I was not able to compress a 8 bit 1 channel 70 GByte PCM file.
It looks like there is a limitation to save some bits in the FLAC header

This is simply not true. MAC is not more robust than any of the other major lossless codecs. The MAC GUI is good, compression is very good, but it has drawbacks, namely higher decode complexity than FLAC (1.5x - 4x), portability, license encumberance. However, if all you ever use or will use is Windows, MAC is the clear codec of choice right now.



FLAC supports 1 to 8 channels. There are some reserved bits left for special channel assignments but that would break forward compatibility (i.e. current decoders could not play some future streams).



There is a sample/frame number in the frame header. For fixed-blocksize streams it is a frame number; for variable-blocksize streams it is a sample number. In the common fixed-blocksize case, with a blocksize of 4608 samples, the limit is 4608 * 2^31 ~= 1e13 samples.

At the stream level the frame numbers are irrelevant; they can roll over without any problem. In seekable files it matters.

The current command-line encoder "flac" is still subject to 2G file limits in many places. It is probably that limitation that is keeping you from compressing large files.

Josh

Decode speed: as has been stated before, MAC uses basically the same resources to decode as mp3. If FLAC is indeed lower than this, great, but even ancient computers are enough to run mp3's fine, and thus .ape files. Decode speed is somewhat like comparing 2d winmarks in with today's computers; irrelevant benchmark.

Portability: apparently MacOS and Linux versions are on the way, maybe already out. Licence: Doesn't look like you can sell MAC; I don't see how this affects an end-user.

The nice thing about lossless codecs is the subjectivity of lossy codecs is absent. The "ogg just *sounds* better", or "aac has more well-defined bass" kind of comments aren't valid, and it all boils down to numbers, and features. MAC has the best *relevant* numbers, and the best features (seeking, tagging, gui).

True, but nobody cares about playback on desktops, there's more than enough processing power for that. This is for those that want to get lossless decoders in hardware. Pretty much every mp3 player has a dedicated, specialized decoder chip (some of which don't support the full mp3 spec, which is why some portables puke on things like VBR files) that can decode much more quickly than a general purpose chip. It might be possible to program a DSP to decode ape files, but you'd need a more powerful chip, which means more power, which means less battery life.

Look at vorbis as an example: I don't know what kind of processing power is required for Xiph's integerized codec, but most of the other "portable vorbis" projects seem to have hit a wall somewhere around 75 MHz for processor speeds. I'll admit to not watching these projects extremely closely, so if I'm completely off my rocker, let me know. Vorbis's complexity is comparable to mp3 though -- so if it got a handy decoder chip like mp3 does, it too could have all those cool advantages.

flac's low decoding complexity makes it more attractive for people trying to get it into hardware. In fact, it's already been done. You can find more info from flac's homepage.

Completely wrong. APE is Integer only (like all lossless packers), MP3
is a mixture of 80% Floating point and 20% integer.

Computational complexity of APE decoding depends heavily on compression level,
for MP3 it's nearly constant.

Going back to topic, and as said million times, for lossless you should get the one that switches you best.

Decisions to switch one over another vary like vary the requierements each person expects from it.

Best compression : optimFrog
Best overall (compression/speed) : MAC
Best format design (seeking, streaming...) : FLAC
Most known (till recently): Shorten
Most curious : Wavpack with hybrid mode


Even when 3% of 700MB is 21MB, It is not really that big of a difference to choose just because it is the one it compresses the most, and since all them sound equal (lossless), it's up to the people to find "the standard".