Howdy everyone,

I'm new to the audio archiving world and have done a little research into which encoder to choose. So far I have been using flac since I like the fact that it's an open format and decodes fast. I realize that lossless is lossless so I can convert to another format without worry... I've just started to see that WavPack may have also been a good choice for me, perhapses better?

Since you can't choose a lossless encoder based on sound quality the choice has to be based on something more superfluous. So my question to this form is what is the one make-or-break feature of your audio encoder of choice? Also, is there a close runnerup feature?

Desired features, or efficiency.
Some people are mainly interested by the compression ratio, some others by the decoding speed, others by the hardware/software support, by the licence, by the popularity, etc...

You can find a nice table in the wiki:
http://wiki.hydrogenaudio.org/index.php?ti...less_comparison

EDIT: I personaly focused on decoding speed (which limits the choice to WavPack -f and FLAC). Other criterions: good seeking & tagging, hard. & soft. support, and the best available ratio for a given decoding speed.

Software and hardware support. I use FLAC as my lossless codec as it fulfills my software and hardware playback requirements. Those two requirements are above encoding and/or decoding efficiency for me.

I switched from WavPack to FLAC because most (all?) Linux distros have FLAC support out-of-the-box and because FLAC is supported by several hardware players I use.

I switched from APE to WavPack because strong APE compression modes gave me an audible delay when seeking and because WavPack's decoding speed is generally faster (good for transcoding to lossy). For me WavPack was a good compromise between FLAC's fast decoding and APE's high compression.

I don't need lossless hardware playback, since lame at reasonable high settings is transparent to me and I only own players without FLAC playback anyway. Plus, avoiding lossless saves space for more music, which is much more important to me.

Software support would be my first criterion.
Wavpack is quite popular and there are many softwares that support this format.
Also, I find Wavpack has well balance between encoding/decoding speed and compression ratio. It encodes faster than FLAC yet produces smaller output.
I've only used MP3 for portable player, so hardware support is not important for me.

FLAC, because it is supported by all the hardware and software I use, is well documented and works well on a number of platforms. Really, though, it's not worth getting excited about lossless formats - considering that you can convert losslessly, choosing the wrong one is an easy mistake to fix.

Software support for me, that's why I picked Flac. Wavpack is nice, but support for it in Linux Distros and playback software is still in it's infancy.

It's a bit offtopic, but I constantly get the impression that codec support under Linux is still an issue. That would bug me a lot if I used Linux as my desktop OS... I also don't get it why there's no music player/manager like foobar2000 or a secure ripper.

Well, maybe it's because Linux lacks a common multimedia API... although there are finally efforts to put one through. I hope this will attract more developers to Linux or KDE/Gnome repectively.

What are you talking about? Have you seen Rubyripper and Amarok? take a look in the wiki they are the equivalent of window applications. ALSA is up and coming and there still needs to be a lot of bug fixes. Core Audio for Mac OS/X should probably be the best considering it was designed with multimedia API's in mind. The problem is only about 5-10% use Linux on a constant basis too.

I have heard of Rubyripper, but I've never read beyond the thread's title on HA.org's main page and thus it slipped my mind (I hope you forgive me). Amarok tho is based on KIO, which I doubt is secure.

ALSA is nothing more than a sound output API. Codec support still has to be implemented seperately. I meant something like GStreamer, it seems to be the most promising of them all.

And I have to add that I don't like the "application packed with all needed codec filters" approach at all. As a windows user I like DirectShow a lot (tho I think not all Windows users would agree), and in case I'd switch to a Linux Desktop I would naturally use applications with GStreamer (or similar) support. I like to update the codecs seperately, be it via updating DirectShow filters or CLI encoders/decoders.

I guess they must be using C2 pointers then, otherwise they are not the equivalent of what can be done in Windows in terms of secure ripping, sorry.

My choice of a lossless codec is Monkey's Audio set to High (-c3000) based on the following three things in or order of their importance to me:

1. Compression
2. Encoding Speed
3. Decoding Speed

I have no trouble with seeking while playing ape files on my system. Like Fandango, I use lossy configured for transparency with my DAP.

Oh, I see you meant Amarok as a substitute for foobar2000. Well, in that case I guess you might be right, but I've never used Amarok, so I can't tell.

PS: In order to put this thread on top again, here's a list of all GStreaner plugins (including the supported lossless audio codecs):

http://gstreamer.freedesktop.org/modules/g...lugins-bad.html

@greynol: it depends on the APE version. I don't remember well anymore at which compression modes I experienced delays but 3.97 required one compression mode "less" in order for the delay to go away. I think, 3.99 was even ok for Extra High... whereas 3.97 even got me a delay at High. But as I said I'm not sure at what compression this exactly happens, since it's been so long since I've used APE. I gave up hope for a faster Monkey's Audio version 4.xx and switched to WavPack, screw the extra bytes.

Come on, I'm no fan of foobar (still use Winamp to this day), but you can't compare Amarok to it. foobar is the only player I know of that is focused on playing audio (and audio only), with highest quality in mind, and no bullshit. Its tagger is also excellent, as well as the playlist manager, two parts that are less-than-optimal on Amarok.

Oh, and the scoring system blows.

rjamorim, that's exactly my objective against Linux multimedia support... even the most popular or let's say the most mature applications have some features that are sub-optimal compared to similar software for Windows. And then codec support for Windows is also better. It's just a feeling I have (since I don't use Linux on the desktop at all I can't verify it), but this feeling is so strong that it prevents me from switching back to Linux...

IMHO, it mainly depends on the developers. The leading multimedia developers still use Windows, as long as this does not change the Linux desktop will always be one step behind. If you look at HA.org and Doom9.org then most of the software are being released as Windows binaries (first or at all).

The bottom line is Linux is not mature enough yet and Mac OS/X Core Audio API is clearly superior to that of Windows. Windows developers are just lazy and they don't want to make their code cross-platform compatible like Linux or Mac OS/X developer would do. Any other excuse is pure BS as far as I am concerned.



I personally don't do that much tagging to be honest with you and I saw just a few inherient problems with Amarok. It is coming along though quite nicely. I guess it just depends on your taste.

Thanks for the clarification.

The improvements in 4.01 are nice but the encoding/decoding is the same. I actually use the version of MAC.exe that's available in the Ogg Vorbis section at RareWares, thanks Roberto!

I wish I could agree with you! It would be so simple, blame the developers.

But I think it's much more complicated. Making multimedia software cross-platform compatible is a big problem because every OS uses incompatible multimedia APIs, and hands down the most popular APIs used on the specific OSs are incompatible to each other! For example references to cross-platform multimedia APIs (like Simple DirectMedia Layer) is a bit illusive, since the majority of developers use the most common or advanced multimedia API for their current OS. And you can't just port a DirectShow codec filter to Linux or Max OS X, the only thing you can do (and it is indeed usually done a lot of times) is to keep the actual code that deals with the codec seperate and platform independent from the rest of your OS-dependent implementation, i.e. the link to the API, in the hope that someone acquianted with another OS will have an easier time porting your code to another platform and/or API. A good example is ffmpeg or the OSS lossless codecs this thread should rather deal with. But these are just codecs!

This only works very well for a limited set of multimedia software... a GUI based program like foobar2000 must have been been written for an entirely different widget toolkit in order to be easily portable to another OS. And re-writing even small programs so they work with another GUI toolkit is very complicated. Also there are only two real alternatives which are platform independent: GTK+ and Qt, both are high-level toolkits... coming from a low-level widget toolkit like the Windows API and/or various Windows based high level widget toolkits MFC, .NET, etc means a lot of work. Plus, not everyone likes GTK+ or Qt...

I guess the DirectX/OpenGL-games issue is another good example. One reason why there are so few games for Linux is that most recent high-end graphics games are DirectX9 (and soon 10) based, DirectX gives game developers much greater possibilities than OpenGL in relation to time (and time is most crucial in game development!). id Software is one exception tho, since they use OpenGL, but to what cost? I think they have to write many things from scratch and break new ground, and the actual reason why they prefer OpenGL is because they can do things faster when they write and use their own implementations. But they can allow themselves to spent this time on developing their game engine, they have the money, they live from the license fees they get through their game engines, they're an exception among the game development companies.

But the main issue remains that cross-platform applications are nothing but a wet dream as long as the preferred APIs of the software developers are the OS dependent ones. Developers are lazy, but can you blame them? They don't want circumvent the limitations of an API just in order to be cross-platform, they want to write things they are good at, and not deal with stuff they have little knowledge about. That's why it is understandable why a developer rather chooses the native API of his OS than a cross-platform API, it has the most advanced features and is documented very well.

I say that it is not the duty of the codec and player developers to write cross-platform applications but of the cross-platform multimedia API developers to further improve their software, so the multimedia developer among others have an easier choice with going cross-platform.

And don't get me wrong... even if Linux will get a superior multimedia backend this doesn't mean all Windows applications will be ported to GNU/Linux. They still need to re-write those applications, because the problem remains that the most promising multimedia backends, APIs and tollkits on the two most popular operation system will remain incompatible. But I'm sure over time the "free" multimedia software for Linux will get "better than" or at least "even to" that on Windows, once Vista is everywhere.

Not "taste" is the key word here but "needs".

To get on topic...
Since so many people in this thread stated they choose FLAC over any other lossless audio codec because its support is so widespread on Linux, I like to point out two basic problems with lossless codecs:

There's a specific problem with Monkey's Audio. It's not open source and Matthew Ashland hasn't released any Linux binaries. There are a few other lossless codecs with this problem, they're closed source and it's up to the developers to release Linux binaries.

As for codecs like WavPack, it's up to the folks on the OSS frontier to get their ports ready in time, which has been achieved now for a lot of software. The more popular a lossless codec becomes the higher the demand for proper implementations on other OSs increases, namely inclusion into the various Linux distros. That's why I think it's so important that codecs remain free from patents and copyright restrictions...

So choosing an OSS codec over an CS codec makes sense if you want people who are on another platform different from yours to also enjoy your files.

I'm tired to say everywhere, that Monkey's Audio IS open-source (at least year or more). See http://www.monkeysaudio.com/developers.html for source code and license. Mattew Ashland hasn't released any Linux binaries - but binaries is there (http://sourceforge.net/projects/mac-port), working and usable.

Even if you can call it open source or maybe better available source, M. T. Ashlands homebrewn license are still not GPL compatible - which will forever prevent it from being implemented in freenix distros, whether one agree or disagree, like it or not, that's how it stands and probably where it will remain. Everybody can ofcourse download and use Supermmxs implementation, but it's legal status are in the greyzone..... so most distros most likely won't touch it.

Personally I've fallen down on WavPack due to considerations regarding features and compression vs. encoding/decoding speeds, and also the very free (and GPL compatible) BSD license. My only portable (Rockboxed iRiver H340) plays it well, and even if freenix support are still a little limited compared to FLAC it's coming along and I belive this is only a matter of time.....

I wonder how can they host that project on Sourceforge, considering Monkey's Audio sources are not OSI-approved, and that's a requirement for project hosting.

Maybe I should report it to SF (I'm joking...)

I think Supermmx just went ahead and relicensed it as GPL - without asking Ashlands consent. So as far as SF is concerned this is then GPL code.... which it clearly isn't. I don't think this is a really big issue in China....(???) And Ashland himself don't care at all it seems...(???)

I chose Wavpack because of good encoding/decoding speeds and nice compression ratios (I realized Monkey's better, though it's not so important).
Besides, the nice option to hybrid mode is a killer!

@fandango

I think you have a very old vision of the Linux world, and what you say about the troubles in writing cross-platform applications can be easily contradicted.

Most Linux applications are cross-platform, even multimedia ones, like VLC, Audacity, Wired, mplayer, Xine, and soon will be Amarok. When all kde apps will be ported, it will be very hard to find a non cross-platform app for linux. Even Jack, a high-tech, low latency, Linux based audio service is moving its first steps on windows.

Also most pro-audio applications but cakewalk are cross platform, (like Pro Tools, Cubase and all its plugins).

At first, I missed a multimedia api like DirectShow in Linux too, but now I prefer to use in Windows only foobar and VLC, without touching DirectShow at all , and so I don't care about centralized codec (and gstreamer) anymore

p.s. for much time foobar was a windows killer app for me... but a day I tried to give a chance to amarok. I didn't like its interface&fell, but after tuning the interface and installing a couple of scripts for transcoding and abx I must say it is not bad at all

Not only is Ashland's license not GPL compatible, it's really awful - the kind of thing that happens when programmers (even clearly talented ones, like Matthew Ashland) dabble in writing licenses.
You are not entitled to experiment with the code in any way that will change the binary output format. This makes the code more or less useless for people interested in tweaking or improving Monkey's Audio.
This clause is redundant.
This is similar to the BSD advertising clause, and can not be practically implemented in some places. Sure, the author requires due credit, but there are problems with this clause which make the software much less free. Richard Stallman has written about what makes this clause so nefarious in the past. Also, the software license cannot protect the "ideas" in the code - only the expression of those ideas.
This is a very weak disclaimer, which would not protect the author against any real-world claims. Of course, a disclaimer is always of limited use, but this one is terrible.

The problem here is that Monkey's Audio is really nice, and it would be great to have the code available under a free (if restrictive) license. While Mr Ashland is free to release his code under any license he sees fit, this one isn't good for him or the community. It would be really nice if Matthew Ashland would pick a license which protects his rights to the extent he desires, and more clearly sets out the rights of others.

My make-or-break feature for a lossless codec?

Compression ratio.

That's it.

This all could become relevant for me too if i a will release the source code of TAK:


I really understand that he wants to prevent incompatible codecs floating around.

Would something like this be acceptable:

1) Modify the code as much as you like.
2) But if you make it incompatible to the standard, clearly state this in your software.


Do you know a source for a better one? (I am aware, that it may depend on the country).

At least announce is on Monkeysaudio.com forum. Moreover - it's first in Google results for "monkeys audio linux" query: http://www.google.com/search?q=monkeys%20a...-8&oe=utf-8

And does anyone know, why Mattew Ashland dislikes GPL?

P.S. As for me, Monkeys Audio is ideal codec now (may be, TAK will replace it later, hovever). I don't recompress, play files from computer and dont think that audio codec should handle bad files at all (except clear message that file is broken). I'll better save some space and use it to increase my PAR files.

IMO this is different from Original BSD License advertising clause. The Original BSD License explicitly says All advertising materials.... Point #4 only says that it must be plainly acknowledged in the software. To me a simple scrollable Help/About box is enough.

Yes. But Ashland have been made aware of these points numerous times these last years in his forums. He's also been begged numerous times to choose any OSI-approved license over his own homebrewn, compatible-with-nada one. The few times he's bothered to answer he's very clearly refused to budge. So I think we can be pretty sure the man won't change his position. Anyways. I've switched to WavPack so this doesn't bother me much.....




Yes. But this only means that he's made Ashland aware of this and that Ashland don't care. I't still not GPL compatible and for Supermmx to relicense the code under the (L)GPL is probably not legal at all. And if the SF moderators where aware of this they would probably have kicked the project out....

I'm from Ukraine, and all that legal thing isn't so popular there. As for me, it would be strange (yes, but legal) to close this project withous Matt's request. If owner don't cares - who else must?

By the way, is it possible to contact Mattew Ashland? There is some chance that he can think about changing the license... I really like APE, and don't want to let it die.

Efficency and seekability as I'm mainly interested in PC playback, also WavPack's brilliant hybrid mode makes it even more flexible.

I chose FLAC back in 2001:

- Very cool name
- Open source
- Command line based
- Works under linux
- The developer was active on this forum

Later tagging with vorbiscomments were added to the format in a clever way that fully supports streaming. Brilliantly done!

But the format means very little. Can convert all my music to another format without much trouble.

I suppose that's his choice, I only brought it up because license is one of the make-or-break issues for me. I don't mind proprietary software and closed-source, but I like to know where I stand.
Wavpack hybrid is extremely clever technology, but is it particularly useful without wide hardware support? It's a nice feature, but not one that I would ever use, so it's not on my list of requirements for a codec.

WavPack hybrid can be useful even if you only use it on your PC. You can use it for storage of music for future transcoding, and have it be pretty high quality but lower bitrate than typical lossless files.
Or keep the lossy on your PC for playback and backup the correction files somewhere.

And well, the hardware support is pretty limited, but fortunately the players that can be Rockboxed to support it are fairly popular players.

If it works in Linux it's fine. I barely ever compress stuff myself so I'll take what I can get.

Actually, it's pretty simple to enforce that. Just write down: if you break compatibility, you can't call it TAK. While it isn't particularly easy to do that if you don't own a trademark on TAK (and that's indeed a problem in the realm of trademarking, not copyrights), at least you warned in advance.

Contact me if you want more tips regarding licensing.




Use the BSD disclaimer. Works great and looks good, even though doesn't really protect you from litigation

"THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE."



The only way for that to be legal would be a written permission by Ashland, since he is the owner of the copyright, and therefore it's up to him to decide how it will be licensed.

There can be a loophole, in the aspect that it was once reported (when the sources were first released) that Monkey's used some GPLd code in its core. That would pretty automatically make everything else GPL. But I wouldn't want to go that way, because it sounds just puerile to go against Ashland's wishes based on a minor fuckup by him. And I strongly hate those <censored> that take the GPL as gospel (ingluding the author of a famous sampling rate converter).

this thread's gone pretty far off-topic; I was hoping to see more answers to the original question. do polls support ranking? that might work better.

Josh

I'll be on topic I use FLAC because it easily goes to OGG using Oggdrop, that's pretty much the only reason. In my tests APE encodes better, but FLAC is much more compatible going to Ogg, my preferred lossy codec.

Compatibility. I chose Apple Lossless because, well, it works with iTunes, my iPod, foobar, and WMP after you mess with it enough.

Wow, yeah jcoalson it has gone way off topic.
I was debating between flac and wavpack, I was originally going to go with flac but have decided to go with WavPack.

My make-or-break feature is Licensing, I prefer open-source and open standards (makes me feel all warm and happy inside!).

My close runner-up features are:
fast decoding
compression
meta data capabilities

flac and wavpack both seem to tie on the above points, however after testing both of them wavpack encodes crazy fast compared to flac (both on highest compression setting) and also saves me 5-20MB per CD.

Also, from flac's web site it states that it tries to be a general-purpose lossless format. Since I'm solely using this for archiving my CD collection it makes me feel like flac may have too much overhead and/or missing capabilities trying to be generic enough for everything.

I've looked to try to split out the off-topic posts, but they are so merged with relevant responses that if I did so neither thread would make sense!

I don't think you can do polls with ranking, but the OP could possibly create a multi-question poll, with the same answers for each question, and the questions being "Pick the first priority", "Pick the second priority", etc. Not sure how well you could extrapolate the data though.

Maybe a better way would be to pick 5 (?) points that you think are relevant (e.g.: encode speed; decode speed; compression; license; error tollerance), have questions like "On a scale from 1 (priority) to 5 (don't care), how important is encoding speed?", and ask the posters to answer from 1-5.

This thread is fubar'd tho... please stay on track chaps.

I'll take part of the responsibility for that
Now back to our regular programming...

Important factors, I need all of these to consider a format:

• Licensing (open source is better)
• Software Support (on Linux and Windows)
• Seeking (this one dates back to the Shorten days)
• Metadata (and software support for it)

Unimportant factors (things I don't care about):

• Hardware Support (I don't have, or want, a DAP)
• Encoding speed (I don't bulk rip - just rip new discs when I buy them)
• Decoding Speed (unless obscenely slow)
• Compression Ratio (withing reasonable limits)

Of course, everybody has different requirements. If you have a DAP, then hardware support and compression ratio might be important, although many people encode to lossy for their DAP anyways. Hard drive space is so cheap these days that I find it hard to get excited about a couple of percent in compression ratio.

Important for me, from highest to lowest:

- Compression ratio
- Ability to adjust priority of encoding/decoding process
- Encoding speed
- Decoding speed

Given the first 2 priorities and the fact that I use lossless audio for archiving only and not for playback, Monkey's Audio -Extra High via the official frontend does the job for me.

Make or break is hard to say.
Compression ratio, encoding and decoding speeds are on a scale and often have tradeoffs.
So my order.
- robustness (can still decode most with a small error)
- decoding speed
- compression ratio
- encoding speed
- tagging (foobar2000 tags them all)

On my current system Wavpack 4.40 and FLAC 1.13 are great contenders, Monkey is too slow for me (so's Optimfrog). I'll consider Yalac, by these criteria, in the future.

edit: spelling

note that hardware support is not just for portables (where the only real advantage is not having to transcode). there is a lot of very cool home stereo equipment that makes use of lossless, e.g. squeezebox, sonos, etc.

BTW there is now a proper poll here.