Which is the best lossless codec?, Discussion thread Options

[rjamorim]

I agree.
But it'll become Linux, a hundred different codec floating around ...

Linux is actually quite solid, and there's ongoing efforts to make interoperability among distros a reality.

If you want to talk about branching gone retarded, think eMule

Maybe I'm wrong about joint-force, my idea is someone take care of the interface, others the core, different platform's binary, and also optimization.

But that doesn't help the fact that a single codec would never be able to meet everyone's requirements.

I can see some of the codec creator keep doing their job well (all of them you talked about) but feel they're working alone, if each of them can have some help then they can concentrate on the codec core.

Some of them actually help each other a lot. Matt (Monkey's Audio) was inspired by David's paper on lossless compression to create his encoder. But he wanted very highest compression, David wanted efficiency, so they went their separate paths - but still sharing findings and ideas. Then Matt implemented joint stereo, and others (Malcoln Taylor, David) followed shortly...

It's not like they are completely uncommunicable, or they are too fond of their ideas not to share with anyone.

Many people STILL use WMA, I consider this is: we're losing the battle over M$, maybe we're not GOOD enough, easy to use, hardware support ...

The people has the final word. No matter how much the self-proclamied enlightened audiophiles at HA whine, if people choose WMA in the end, it'll be the winner. The codec might suck, but it's very tightly integrated to the, by far, most popular operating system. Maybe people are more concerned about usability than quality, hm?


Anyway, please let's not drag this thread into another WMA flamewar. First because we already had several of such flamewars recently, second because this topic is about lossless codecs only :B

[sidewalking]

Matt (Monkey's Audio) was inspired by David's paper on lossless compression to create his encoder.

Is this paper published anywhere online that we can read it? I am intrigued...

[rjamorim]

Matt (Monkey's Audio) was inspired by David's paper on lossless compression to create his encoder.

Is this paper published anywhere online that we can read it? I am intrigued...

http://www.wavpack.com/397/technical.htm

[sidewalking]

http://www.wavpack.com/397/technical.htm

Right on, thanks.

[rjamorim]

Erich w/ an h: Could you please post the results of the test you performed where LA had issues with mono streams?

Since Erich didn't post any proof to back his claims and Guruboolez' (limited) test shows no issues with LA on mono streams, I have removed that remark from the start post.

How about adding to the "Tagging" row the type of tags that given format supports (APE, ID3, etc.)?

Done, but as you can see, some formats are missing it. If someone knows the tagging schemes used by these formats, please shout.

Adding "PIPE support" to the table would make it complete 

Added, but I need info on some more formats..

Also, in the Pros for alac - by far what's driving the rapid growth of this otherwise somewhat lackluster format is the integration - iTunes/iPod provides a total solution for users:  ripping, database lookup, tagging, playback, portable / hardware, transcoding to lossy.  All in a pretty usable interface (as long as you don't need control or need to know what's going on).  So it might be worth adding "integration with software and hardware" or something.

Added, thanks.

Please keep suggestions coming, people. And thanks for the suggestions already submitted.

[rjamorim]

Mentioned hability to create self extracting files on WavPack's pros. I wonder how I didn't think about it earlier...

[smack]

Just want to add some details about LA to your great comparison table:

-tagging is possible (I'm using Tag.exe to add APE2 tags, the Winamp plugin can display them, the command line decoder ignores them)

-PIPE is supported (I'm using it in my small "la2mp3.bat" script - la.exe pipes decoded data to lame.exe)

[Mr_Rabid_Teddybe...]

Monkey's audio pipe support are only with special patched versions from here or here, isn't it? Didn't think offical build supported that.....

Great initiative, this thread, BTW.

[rjamorim]

Just want to add some details about LA to your great comparison table:

-tagging is possible  (I'm using Tag.exe to add APE2 tags, the Winamp plugin can display them, the command line decoder ignores them)

-PIPE is supported  (I'm using it in my small "la2mp3.bat" script - la.exe pipes decoded data to lame.exe)

Excellent. Thank-you very much for this contribution.

Monkey's audio pipe support are only with special patched versions from here or here, isn't it? Didn't think offical build supported that..... 

Indeed, it doesn't. But it is doable, and there's a readily available solution for that, so I considered it to be a good idea to mention as a feature.

It's different than, E.G, tagging or replaygain, IMO, because these features need to be supported everywhere that format is supported. No use if foobar supports replaygain with Monkey's Audio and Shorten. All other tools won't support it. With pipes, one implementation is enough.

Do you agree?

Great initiative, this thread, BTW. 

Thanks

[buzzy]

An example or two might help the users understand that, especially newer users.

I don't understand what exactly you want examplified. Could you give me one... example? :B

It might read something like:

For example, an individual making backup archival copies might emphasize compression. Another individual intending to play the audio with a portable, auto or network setup might look for hardware support or streamability. Other individuals might seek ease of use above all. And groups of individuals sharing live recordings might value broad OS support, free open source software and format robustness.

This post has been edited by buzzy: Feb 23 2005, 17:56

[rjamorim]

It might read something like:
[...]

Very good idea indeed. I added it to the post introduction.


Also, I changed the table and the ALAC entry to reflect the recently released reverse-engineered decoder.

This post has been edited by rjamorim: Mar 6 2005, 16:15

[guruboolez]

Roberto,
on your table, ALAC appears as stereo only (no multichannel) and not compatible with higher definition as CD.

But according to David Hammerton:

ALAC allows up to 8 channels. It should be trivial to finish the implementation once I find files that I can test it with. Likewise the decoder only supports 16bit sample sizes. Again, it should be trivial to fix.

source: http://craz.net/programs/itunes/alac.html

Apparently, ALAC supports both multichannel and high bit depth. But I don't now if the current ALAC encoder bundled with iTunes supports both features.

This post has been edited by guruboolez: Mar 6 2005, 16:15

[rjamorim]

Roberto,
on your table, ALAC appears as stereo only (no multichannel) and not compatible with higher definition as CD.

But according to David Hammerton:

ALAC allows up to 8 channels. It should be trivial to finish the implementation once I find files that I can test it with. Likewise the decoder only supports 16bit sample sizes. Again, it should be trivial to fix.

source: http://craz.net/programs/itunes/alac.html

Apparently, ALAC supports both multichannel and high bit depth. But I don't now if the current ALAC encoder bundled with iTunes supports both features.

Ah, very interesting. I tried feeding a multichannel stream to my iTunes and my QuickTime, as well as a high-frequency stream, and both programs choked on both streams.

I wonder if the MacOS versions of these programs don't show these limitations.

I just updated the table and the ALAC entry to mention these capabilities. Thanks for pointing them out.

[moozooh]

Seems like Wavpack and FLAC are the most “green” out there.
Too bad they're not very good at compression ratio…

[Mono]

Ah, very interesting. I tried feeding a multichannel stream to my iTunes and my QuickTime, as well as a high-frequency stream, and both programs choked on both streams.

I wonder if the MacOS versions of these programs don't show these limitations.

I've got samples on my Win desktop. I'll transfer them to my iBook tomorrow and test it out.

[Busemann]

Ah, very interesting. I tried feeding a multichannel stream to my iTunes and my QuickTime, as well as a high-frequency stream, and both programs choked on both streams.

I wonder if the MacOS versions of these programs don't show these limitations.

I just updated the table and the ALAC entry to mention these capabilities. Thanks for pointing them out.

I haven't tried it yet with QT 6.5.2, but it is an (still unimplemented) option to encode into ALAC multichannel & HF in the QT 7 betas.

[Radetzky]

Roberto,
on your table, ALAC appears as stereo only (no multichannel) and not compatible with higher definition as CD.

But according to David Hammerton:

ALAC allows up to 8 channels. It should be trivial to finish the implementation once I find files that I can test it with. Likewise the decoder only supports 16bit sample sizes. Again, it should be trivial to fix.

source: http://craz.net/programs/itunes/alac.html

Apparently, ALAC supports both multichannel and high bit depth. But I don't now if the current ALAC encoder bundled with iTunes supports both features.

Hmmm... the way it's written, ALAC CAN support multichannel (tha author says it should be trivial to implement) but CURRENTLY does NOT. Am I wrong?

If I am right, I believe the table should represent what the codec can do now, not what the codec could do.

Radetz

[rjamorim]

If I am right, I believe the table should represent what the codec can do now, not what the codec could do.

You are correct.

I'm waiting for input from the MacOS users. If the MacOS apps can encode to ALAC multichannel, then it's something the codec can do now (albeit in an OS-limited fashion). If it has the same limitations in Windows and MacOS, I'll set it back to no multichannel/no high resolution until a version with those features is released.

[music_man_mpc]

I think you should use either light green or white for the background of the cell for ALAC's opensourceness as it isn't "as opensource" as FLAC or WavPack, if you get my drift.

[Cygnus X1]

If I am right, I believe the table should represent what the codec can do now, not what the codec could do.

You are correct.

I'm waiting for input from the MacOS users. If the MacOS apps can encode to ALAC multichannel, then it's something the codec can do now (albeit in an OS-limited fashion). If it has the same limitations in Windows and MacOS, I'll set it back to no multichannel/no high resolution until a version with those features is released.

While I cannot comment on ALAC's multichannel capabilities (as I don't have any multichannel material to begin with), I can say with reasonable certainty that one is still limited to 16-bit encoding and decoding. Case in point: when attempting to squash down some 24-bit, 48kHz AIFF recordings I had made from my vinyl LP's, QT spit out 48kHz, 16-bit ALAC files.

I'm on 10.3.8 and using QT 6.5.2, BTW.

[spoon]

ALAC - Apple Lossless Audio Codec
...
PROS
- Open source

It is no more open source than WMA (which was reverse engineered and the decoder source released, I wouldn't call WMA open source). It will remain to be seen if Apple don't try to mess with the bit stream to 'upset the Apple cart' as was recently seen with m4p / real - in the long run iMS will perhaps move over to Apple Lossless.

[guruboolez]

Are WMA9 Lossless source available? IIRC, only WMA standard was reverse engineered. The table isn't wrong.
Open source could be considered as a simple fact (open source), or as something like an ideology (could be called Open Source). Fact is that ALAC's sources are now available to everyone. In other words, open.

This post has been edited by guruboolez: Mar 7 2005, 10:55

[rjamorim]

I think you should use either light green or white for the background of the cell for ALAC's opensourceness as it isn't "as opensource" as FLAC or WavPack, if you get my drift.

Good idea, I will change that later.

ALAC - Apple Lossless Audio Codec
...
PROS
- Open source

It is no more open source than WMA (which was reverse engineered and the decoder source released, I wouldn't call WMA open source).

Only WMA Standard has been reverse engineered, not WMA Lossless. The day WMA Lossless is reverse engineered, I'll comment on it.

It will remain to be seen if Apple don't try to mess with the bit stream to 'upset the Apple cart' as was recently seen with m4p / real

Indeed, remains to be seen. If they do that, it'll be mentioned at the comparision.

This post has been edited by rjamorim: Mar 7 2005, 10:57

[spoon]

That sort of proves my point - when the 'open source' wma decoder was released WMA Lossless / Pro / Voice did not exist, they have since been added to WMA - so wma was open source and has moved back to closed source? IMHO something is only open source if it is controlled by those who release the open source code - FLAC is.

In the context of this thread - Lossless decoders, it is a nit pick - I am sorry for that, but to many Open source is a religion.

PS Feel free to split this closed / open source discussion.

This post has been edited by spoon: Mar 7 2005, 11:01

[rjamorim]

Open source could be considered as a simple fact (open source), or as something like an ideology (could be called Open Source).

Oh, no ideologies please. That makes me sick like the discussion about whether Monkey's Audio is open source or not.