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 21150 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

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

Reply #25
My make-or-break feature for a lossless codec?

Compression ratio.

That's it.

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

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

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.

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.

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.

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

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

Reply #27
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.

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

Reply #28
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.
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.

 

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

Reply #29
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....
"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 #30
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.

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

Reply #31
Efficency and seekability as I'm mainly interested in PC playback, also WavPack's brilliant hybrid mode makes it even more flexible.
WavPack 5.6.0 -b384hx6cmv / qaac64 2.80 -V 100

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

Reply #32
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.

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

Reply #33

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.

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

Reply #34
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.

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

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

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

Reply #36
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."

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

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

Reply #37
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

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

Reply #38
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.

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

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

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

Reply #40
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.

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

Reply #41
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.
I'm on a horse.

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

Reply #42
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.

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

Reply #43
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.
EAC>1)fb2k>LAME3.99 -V 0 --vbr-new>WMP12 2)MAC-Extra High

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

Reply #44
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
In theory, there is no difference between theory and practice. In practice there is.

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

Reply #45
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.