Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Whats your make-or-break feature for a codec? (Read 21166 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Whats your make-or-break feature for a codec?

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?

Whats your make-or-break feature for a codec?

Reply #1 –
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.

Whats your make-or-break feature for a codec?

Reply #2 –
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.

Whats your make-or-break feature for a codec?

Reply #4 –
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.

Whats your make-or-break feature for a codec?

Reply #5 –
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.

Whats your make-or-break feature for a codec?

Reply #6 –
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.

Whats your make-or-break feature for a codec?

Reply #7 –
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 the panties fault! The panties made me a pervert!"

Whats your make-or-break feature for a codec?

Reply #8 –
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.

Whats your make-or-break feature for a codec?

Reply #9 –
Quote
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... blink.gif 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.
budding I.T professional

Whats your make-or-break feature for a codec?

Reply #10 –
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.

Whats your make-or-break feature for a codec?

Reply #11 –
Quote from: HotshotGG on
What are you talking about? Have you seen Rubyripper and Amarok? take a look in the wiki they are the equivalent of window applications.
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.

Whats your make-or-break feature for a codec?

Reply #12 –
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.

Whats your make-or-break feature for a codec?

Reply #13 –
Quote from: HotshotGG on
Have you seen Rubyripper and Amarok?


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.

Whats your make-or-break feature for a codec?

Reply #14 –
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).

Whats your make-or-break feature for a codec?

Reply #15 –
Quote
The leading multimedia developers still use Windows, as long as this does not change the Linux desktop will always be one step behind


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.

Quote
Its tagger is also excellent, as well as the playlist manager, two parts that are less-than-optimal on Amarok.


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.
budding I.T professional

Whats your make-or-break feature for a codec?

Reply #16 –
Quote from: Fandango on
@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.

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!

Whats your make-or-break feature for a codec?

Reply #17 –
Quote from: HotshotGG on
Quote
The leading multimedia developers still use Windows, as long as this does not change the Linux desktop will always be one step behind


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 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.

Quote from: HotshotGG on
Quote
Its tagger is also excellent, as well as the playlist manager, two parts that are less-than-optimal on Amarok.


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.
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.

Whats your make-or-break feature for a codec?

Reply #19 –
Quote from: Zergen on
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.....
"ONLY THOSE WHO ATTEMPT THE IMPOSSIBLE WILL ACHIEVE THE ABSURD"
        - Oceania Association of Autonomous Astronauts

Whats your make-or-break feature for a codec?

Reply #20 –
Quote from: Zergen on
Mattew Ashland hasn't released any Linux binaries - but binaries is there (http://sourceforge.net/projects/mac-port), working and usable.


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...)

Whats your make-or-break feature for a codec?

Reply #21 –
Quote from: rjamorim on
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.

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...(???)
"ONLY THOSE WHO ATTEMPT THE IMPOSSIBLE WILL ACHIEVE THE ABSURD"
        - Oceania Association of Autonomous Astronauts
 

Whats your make-or-break feature for a codec?

Reply #22 –
Quote from: mikefarinha on
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?


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! 

Whats your make-or-break feature for a codec?

Reply #23 –
@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 

Whats your make-or-break feature for a codec?

Reply #24 –
Quote from: Mr_Rabid_Teddybear on
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.
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.
Quote
1. The Monkey's Audio SDK and source code can be freely used to add APE format playback, encoding, or tagging support to any product, free or commercial.  Use of the code for proprietary efforts that don't support the official APE format require written consent of the author.
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.
Quote
2. Monkey's Audio source can be included in GPL and open-source software, although Monkey's Audio itself will not be subjected to external licensing requirements or other viral source restrictions.
This clause is redundant.
Quote
4. Any source code, ideas, or libraries used must be plainly acknowledged in the software using the code.
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.
Quote
5. Although the software has been tested thoroughly, the author is in no way responsible for damages due to bugs or misuse.
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.