Whats your make-or-break feature for a codec?, Since lossless is lossless, why did you choose your encoder? Options

[pepoluan]

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

Compression ratio.

That's it.

[TBeck]

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

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.

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.

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.

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

[Zergen]

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

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.

[pepoluan]

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.

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.

[Mr_Rabid_Teddybe...]

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.

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

At least announce is on Monkeysaudio.com forum. Moreover - it's first in Google results for "monkeys audio linux" query:

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

[Zergen]

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.

[DARcode]

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

[sshd]

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.

[cabbagerat]

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.

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.

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.

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

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.

This post has been edited by cabbagerat: Dec 18 2006, 18:07

[Firon]

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.

This post has been edited by Firon: Dec 18 2006, 18:58

[tgoose]

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

[rjamorim]

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.

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.

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

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

and for Supermmx to relicense the code under the (L)GPL is probably not legal at all.

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 post has been edited by rjamorim: Dec 19 2006, 19:56

[jcoalson]

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

[hushypushy]

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.

[sheik124]

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

[mikefarinha]

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.

[Synthetic Soul]

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.

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.

[cabbagerat]

This thread is fubar'd tho... please stay on track chaps.[/color]

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.

[LANjackal]

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.

[GeSomeone]

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

This post has been edited by GeSomeone: Dec 19 2006, 15:28

[jcoalson]

I've only used MP3 for portable player, so hardware support is not important for me.

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

[*]Hardware Support (I don't have, or want, a DAP)

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.