Which is the best lossless codec?, Discussion thread Options

[kurtnoise]

WavPack
- Fits the Matroska container

Wavpack isn't support by Matroska container yet......but it's on todo list.

I noticed also a mistake for TTA (in the PROS & CONS part) :no streaming support. And TTA supports ID3v2 tags system.


Some notes about LPAC : http://www.nue.tu-berlin.de/wer/liebchen/lpac.html

lossless format developped by Tilman Liebchen. LPAC is derived to LTAC format (Lossless Transform Audio Codec). Liebchen has modified the algorithm scheme to increase performances of this one in order to create LPAC. The first versions are released at the end of 90's. Today, the last version available on official web site is dated from 2002. No updates since nowadays because LPAC has been retained as reference for the MPEG-4 ALS by the MPEG Comittee. So, Liebchen has stopped the development now. Once standardization will be operational, he'll create some tools for the conversions (LPAC files to MPEG-4 ALS files).

Features :
- OS supports : Windows, Linux and Solaris.
- mono and/or stereo Wav files compression with 8 to 24 bits depth.
- No limitation for the Sampling Rate.
- 6 different modes for the compression : fastest to most compressible.
- "Random Access" and Joint-Stereo options.
- Ratios Compression seem to be reasonable, but rather high in general.
- Speed Encoding : more slower than WavPack or TTA.
- Speed Decoding : fast.
- For the playback : only plugins for WA and fb2k.
- software support : good
- Tagging : ID3v2
- Replaygain : no
- Hardware support : no
- Error handling : no
- Flexibility : bad
- Seeking : yes but very bad
- Hybrid/Lossy : no
- Streaming : no
- OpenSource : no
- Multichannel : no
- High Resolution : yes



PS : i can translate some parts of my sticky concerning theses different lossless formats if someone it's interested...(yes, it's in french...)

[rjamorim]

Thank-you very much for all the new info. I'll update the table and the post again tomorrow.

PS : i can translate some parts of my sticky concerning theses different lossless formats if someone it's interested...(yes, it's in french...)

Merci beaucoup, mais je peut comprendre français

I get a 403 error on that link, BTW.

[kurtnoise]

I get a 403 error on that link, BTW.

Sorry...brazilians users cannot access to this forum. It's much more for security.

But I can send you the doc by mail or anything else as you want...

[rjamorim]

Sorry...brazilians users cannot access to this forum. It's much more for security. 

Awww, come on dude. We're a nice people :B

En tout cas, I managed to get to it through a proxy. Merci.

[evereux]

This spreadsheet is an excellent reference, thanks rjamorim!

[SebastianG]

LPAC

Features :
- <...>
- "Random Access" and Joint-Stereo options.
- <...>
- Seeking : yes but very bad

What's your definition of "seeking: very bad" ?
Since the format supports "random access" ... seeking should not be that bad.
You just have to enable the "random access" feature.


SebastianG

edit: shortened quotation

This post has been edited by SebastianG: Dec 10 2004, 15:39

[guruboolez]

very slow seeking could be highly irritating. I never achieved good seeking performances with lpac: it was always very long before the music started again, whatever the encoding options I choose.

[rjamorim]

Hello. I just added a new table design, and would like your opinions on it.

I personally preferred the old version, but it was becoming difficult to read on 1024x728, let alone 800x600.

I'll now start working on the post...

[rjamorim]

I just edited the main post. Here are some comments:

LA has both seeking and tagging functionality. I can't answer for multichannel/high resolution.

Thanks for the info. I just added it to the table.

Edit: I tried LA on my multichannel test stream, and it choked ("Warning: wav file contains more than 2 channels - only mono or stereo currently supported!"). So, no multichannel support for it...

Edit2: Tried LA on my 24bit test stream. "Error - La currently only supports 16-bit files!". Meh...

Monkey's Audio supoports 24bit/192KHz. No multichannel support.

What app can it mux?
mkvtoolnix (still) doesn't support WavPack.

Fixed both, thanks.

I noticed also a mistake for TTA (in the PROS & CONS part) :no streaming support. And TTA supports ID3v2 tags system.

Fixed, merci.

- 6 different modes for the compression : fastest to most compressible.
...
- Flexibility : bad

Indeed, it's funny. It features several compression modes, but all of them have nearly the same speed and output a similar compression ratio.

This post has been edited by rjamorim: Dec 10 2004, 16:45

[rjamorim]

Since I was already playing with my test streams, I decided to check other lossless formats.

RealPlayer hanged on both test streams.

iTunes and QuickTime didn't even bother importing them.

This post has been edited by rjamorim: Dec 10 2004, 21:33

[rjamorim]

As some of the comments here suggest, the point of this is for a given person to decide best not in some theoretical sense, but best for a specific use they have in mind.  So, for example, the best format for file sharing (like etree) is clearly flac.  But someone in search of the best format for archiving their CDs might decide that the absolute best file compression is the only criterion that matters.

So some intro / comment to that that effect - that best depends on how you weight the factors you've listed - will probably help the thousands of newbies who will read this thread.

Good point, I'll work on an introduction.

Also, the table might need a bit of a key or explanation of what some of the items mean, rather than expecting people to read the whole thread.

Well, I would expect people to know at least a little about lossless codecs before coming to this thread. And I think most features are pretty self-explaining: open source, multichannel, hardware support, streaming, seeking, tagging...

As for hardware support, it's much more about whether the codec lends itself to that application - which will matter much more over time than it does now.  Even with faster / cheaper hardware, the codecs with high complexity decoding don't look like good bets.

That would then becoming mostly speculation about wether a codec is probably going to become supported in hardware or not. I think the current format - where only codecs that already have hardware support are mentioned - is more clear.

Ease of use / interface is a little different than what you might have in mind for "software support" - but has always been a strong point of Monkey's and should be for ALAC.  And is a relative weakness of flac, for widespread (as opposed to "technology enthusiast") use.

"software support" means how many software apps are able to deal with that format -be them players, encoders, frontends, replaygain calculators, splitters... It's not supposed to mean ease of use.

But "software support" is a bit unclear - people would keep using shn forever for music sharing if someone was maintaining GUI tools for it on Windows. 

I disagree. People are leaving SHN because it's featureless, compresses bad and is overall badly designed. It's not because people aren't maintaining GUI tools, IMO.



Edit: Shit, 6000 posts and I didn't even notice it.

This post has been edited by rjamorim: Dec 10 2004, 22:53

[buzzy]

Sorry, the comment about hardware support was a response to comments in the thread and as discussion for anyone who might read the thread - not feedback on the table. Speculation about what might be done is of course not meaningful - it's about what can be done now.

"software support" means how many software apps are able to deal with that format -be them players, encoders, frontends, replaygain calculators, splitters... It's not supposed to mean ease of use.

There's something that might be worth a footnote of some sort in the table.

I disagree. People are leaving SHN because it's featureless, compresses bad and is overall badly designed. It's not because people aren't maintaining GUI tools, IMO.

Well ... whether this is on-topic or not depends on whether this thread is meant to be of use primarily to the HA/enthusiast group, or to compare codecs for broad use by mainstream users, too.

I only know what I see among thousands of actual users at various lossless live music sharing sites, and many of them have barely learned about shn, and never heard of flac. Go to any of the bittorrent sites, etree, etc. and the technical support forums, and you'll see. Partly it's the huge inertia factor. Partly it's the reality of all the shows already encoded into shn - they are still being circulated, partly due to inertia and partly as a way to verify the source of the recording (see db.etree.org).

But it's not just that - to the mainstream user, the benefit of a codec change really is not that compelling in the short term. It's a lot easier to buy a slightly bigger hard drive, or a few more discs, than find new tools, install them, and learn to use them. And shn is very fast, after all. Hardly anyone besides the core enthusiasts (like people here) used flac until Mike Wren wrote the installer to get all the codecs, runtimes and frontend installed on people's systems in a usable way.

A good interface did a lot for getting people to use Monkey's, too.

In fact - the big story in lossless right now is the way the Apple is rapidly gaining share among lossless codecs with ALAC for one simple reason - ease of use (despite the lack of customization and flexibility). iTunes is one solution for hardware (iPod as portable/car/DJ player; hard drive at home; lots of media server options developing) and software (multiple codecs, reasonably modern ones, and a way to manage a big music library).

A similar example of how to approach this is what Peter Clement did with par2. par2 is fairly brilliant, technically. But he also put together a good GUI, right away and steadily worked to improve it. The result was an amazingly rapid adoption of par2.

Maybe developing a great codec is enough for a developer, and it really doesn't matter to the developers whether people use it, or not. That's an entirely reasonable approach, if that's their goal. That's probably the fun part, and by the time it catches on they'll think of things they could improve (in ways that aren't backward compatible, no doubt ).

But if they also want more mainstream users to use the codec, it seems like a missed opportunity to just put a codec out there and assume that tools are someone else's problem.

And back to the point of the thread - whether any of that matters for this discussion depends on who this thread is for.

This post has been edited by buzzy: Dec 13 2004, 20:46

[roweezy]

WMAL / WMA Lossless 9.1

DOES support 24bit / 24-bit / 24 bit for 44khz , 48khz , 88.2khz / 882khz / 88khz , and 96khz ONLY

iTunes has option to convert / transcode by drag and drop from WMAL 9.1 to Apple Lossless AND preserve the metadata / tag info.

Apple Lossless / ALAC

does NOT support 24bit / 24-bit / 24 bit for ANY sample rate / resolution

[Zurman]

I think there's a mistak in the table : Monkey's Audio does have Replaygain support, I think

[rjamorim]

I think there's a mistak in the table : Monkey's Audio does have Replaygain support, I think

Only in foobar2000, AFAIK, which is hardly a format feature and more of a player feature.


I'm on a trip right now, and will reply to other posts when I return home, soon.

[Zurman]

I think there's a mistak in the table : Monkey's Audio does have Replaygain support, I think

Only in foobar2000, AFAIK, which is hardly a format feature and more of a player feature.


I'm on a trip right now, and will reply to other posts when I return home, soon.

That's right

[Erich w/ an h]

are the percentages in the original post based on comparisons of stereo files? LA offeres the best encoding of stereo files, but I dont think it offers encoding comparible to OFR, APE, PAC, and even RKA (rkau from http://www.msoftware.co.nz/) for mono files. Obviously I cant make that generalization based soley on compressing one mono file in 9 formats, but the difference between LA and OFR, both set for best, was a good 3%

[Skymmer]

Here is another suggestion and test... As you know WAV files can store not only audio data inside but also non-audio data like Standard RIFF text field names (Display Title, Original Artist, Name, Genre, Key Words, Digitization Source, Original Medium, Engineers, Digitizer, Source Supplier, Copyright, Software Package, Creation Date, Comments, Subject), Cue points and ranges, Loop infos, Sampler Infos, Bitmaps, EBU Extensions and some others.
Of course in most cases it's useless but in case of samples or some audio projects where you need to store for example CUE points or some notes it becomes usefull.
So lets see how compressors listed here friend with non-audio data. I just generated 10 seconds brown noise using Adobe Audition and puted cues, ranges, sampler info, bitmap and some text fields inside and resulting file is 1771654 bytes long. And now its time for the show...

ALAC
I have no software to test it.

FLAC
Surprise !

CODE

c:\Shifter\Software\MUSIC\Packers\Lossless\Flac v1.1.1>flac -8 Test.wav

flac 1.1.1, Copyright (C) 2000,2001,2002,2003,2004 Josh Coalson
flac comes with ABSOLUTELY NO WARRANTY.  This is free software, and you are
welcome to redistribute it under certain conditions.  Type `flac' for details.

options: -P 4096 -b 4608 -m -l 12 -e -q 0 -r 0,6
Test.wav: 85% complete, ratio=0,617Test.wav: WARNING: skipping unknown sub-chunk 'LIST'
Test.wav: WARNING: skipping unknown sub-chunk 'cue '
Test.wav: WARNING: skipping unknown sub-chunk 'LIST'
Test.wav: WARNING: skipping unknown sub-chunk 'DISP'
Test.wav: WARNING: skipping unknown sub-chunk 'DISP'
Test.wav: WARNING: skipping unknown sub-chunk 'smpl'
Test.wav: wrote 1087112 bytes, ratio=0,616

FLAC doesn't support. Resulting decompressed files is 7610 bytes smaller !

Monkey
GUI supports and those files (decompressed with GUI or CLI are identical to original). Good boy !
CLI doesn't support.

OptimFROG
Well done !

Real Lossless
No software to test with.

Shorten
Yes !

Wavpack
Perfect !

WMA Lossless
No, no and no. 7610 bytes smaller.

LA
Without problems !

TTA
Same problem. 7610 bytes smaller.

LPAC
Yeeeh !


Well maybe for most people its not important but somehow my two cents
P.S. There are import/export filters for Adobe Audition for FLAC, Monkey and Wavpack but only wonderful Wavpack's filter supports non-audio data. Super !

[jcoalson]

even better would be if a codec could store all AIFF metadata too since so much audio work is done on the mac.

Josh

[Skymmer]

Quite agree but I'm pretty sure that formats which handled non-audio data in WAV will do the same with AIFF just because they don't recognize this data as METADATA but some information appended to audio part and just copy it to the end of compressed file. I will do some interesting test bright now - take a clear WAV and append peace of absolute hexadecimal junk to end using WinHEX.

[Skymmer]

OK. Again 10 seconds brown noise but without any metadata. Original size is 1764044 bytes. Using WinHEX i've added 777 bytes of random bytes in range from 00 to FF. So lets see how compressors behave - dumb or smart.
The results are the same but with 2 exceptions:

OptimFROG
Seems that froggy realy recognize metadata and wipes out junk so decompressed file is identical to original without 777 bytes of dirt.

LPAC
Although LPAC indicated 'DECODING ERROR: CRC failed!' during decompression the output file is same as original without 777 bytes of junk.

Congratulations !

[jcoalson]

Quite agree but I'm pretty sure that formats which handled non-audio data in WAV will do the same with AIFF just because they don't recognize this data as METADATA but some information appended to audio part and just copy it to the end of compressed file. I will do some interesting test bright now - take a clear WAV and append peace of absolute hexadecimal junk to end using WinHEX.

no, it doesn't work like that. adding noise to the end of a wave file just creates an invalid wave file.

anyway, non-audio chunks can appear anywhere in the file, before audio chunks or in between two audio chunks. a wave file can have multiple audio chunks; how do wavpack/MAC/optimfrog handle that?

see also http://www.borg.com/~jglatt/tech/wave.htm

aiff is similar to riff wave in structure but differs enough to be a pain: numbers are big-endian, not little endian, chunk names are different, different chunk types, different ways of padding and aligning, etc.

Josh

[Skymmer]

anyway, non-audio chunks can appear anywhere in the file, before audio chunks or in between two audio chunks.  a wave file can have multiple audio chunks; how do wavpack/MAC/optimfrog handle that?

Interesting how FLAC handles it.

[rjamorim]

Thanks for that test you did. I am considering adding "RIFF data support" to the table and the summaries. It tends to be a sought-after feature among people dealing professionally with Audio.

P.S. There are import/export filters for Adobe Audition for FLAC, Monkey and Wavpack but only wonderful Wavpack's filter supports non-audio data. Super !

Indeed, David worked closely with some audio engineer that was after these features, so he managed to get it well supported inside WavPack.

[jcoalson]

anyway, non-audio chunks can appear anywhere in the file, before audio chunks or in between two audio chunks.  a wave file can have multiple audio chunks; how do wavpack/MAC/optimfrog handle that?

Interesting how FLAC handles it.

I think you are still not understanding the WAVE spec.

there is a difference between the questions "1. how will FLAC the format handle it?" and "2. how will flac the command-line encoder/decoder handle it?"

1. FLAC-the-format is not a WAVE file compressor on purpose. RIFF WAVE is a container format, and it is not practical for a general-purpose lossless audio codec to try and store and recreate a container format, especially when it can only compress one of the many types of contained sub-chunks.

my comment about AIFF was tongue-in-cheek to try and lead you to this conclusion but failed. if a format completely supports RIFF WAVE then it must be able to store and recreate any RIFF WAVE file regardless of what it contains. but then why not then also support AIFF? and matroska? and soundforge files with audio and cakewalk .bun files? they are all containers used for audio, and different enough that they have to be hard coded into the lossless format.

so what will FLAC-the-format do with multiple linear PCM 'data' sub-chunks? merge them into one audio stream or treat them as separate chained streams.

2. what will flac-the-commandline do with multiple linear PCM 'data' sub-chunks? currently it will only encode the first one and tell you so. I've never gotten any complaints about that.

so what will wavpack/mac/optimfrog do, both as codecs and as tools? you didn't answer that.

Josh