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: Monkey\'s Audio source code available ! (Read 9611 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Monkey\'s Audio source code available !

Reply #25 –
Quote
Originally posted by JohnV
A bit sad to say this, but when reading the monkeysaudio forum, you can certainly notice the large amount of people having problems ranging from small problems to MA just not being reliable in producing lossless results (crc problems etc.).


CRC problems are often a problem of system stability, an often underestimated problem.
My experiences are that ca. 20% of the systems
have such problems (RAM problems, IDE cable problems). With such systems you have always problems, with FLAC, MAC and also with MPC.
Sometimes also with kernel (bluescreen).
I had 3 such systems, all made problems
with FLAC, MAC and MPC. A stress test program
detected several bit errors per hour.

As long as there's no system call to force reading files from disk also "verify" options don't really help (on machines with enough RAM).

You only have no problems with programs which are
not often used. May be MAC is so often used and ...
--  Frank Klemm

Monkey\'s Audio source code available !

Reply #26 –
thanks for all your work, Matt.  It is appreciated.  And while some people may wish you had taken another course of action with this latest development, it would be nice if those criticisms would always be phrased constructively and not ever personalize the deal.  Best wishes to you.
God kills a kitten every time you encode with CBR 320

Monkey\'s Audio source code available !

Reply #27 –
so much bashing...so much...

when monkey's is able to:
1. compress/decompress
2. playback through plugins
3. be available to the public
4. become freely distributable [gpl, etc.] *well, this may be optional...
5. and still be superior to flac [compression ratio, speed performance, stability, etc.]

...for all operating systems who previously used flac, guess what?  they won't use flac anymore [probably].  until then, everyone will continue using flac...cause they can't use monkey's yet.  why is this such a complex rationale for some of you.  it isn't even close to being complicated.

Monkey\'s Audio source code available !

Reply #28 –
I tend to not like describing things like this as "open source," because it confuses the issue.  When I (and many other people) use the term "open source" we mean that the source is available under a license that meets the requirements of the Open Source Definition as stated by the Open Source Initiative (these are essentially identical to the Debian Free Software Guidelines).  To most people when you say "this is an open source project," it means that the source is available and you can modify it and distribute modified copies.  I.e. it's a community project, anybody can get the code, improve it, and distribute their improved versions.

This I'd called "source available."  Certainly that's a good thing, and better than closed-source, but it's not the same as "open source."  For example there are versions of Solaris for which the source code is available, but it's certainly not an open source project.

Note: this isn't meant to be an attack on the license; it's his code, he can license it however he wants, and I'm certainly glad that he's chosen to release the code for others to view.  But I'd like to avoid using confusing terminology, since to most people involved in the open source community the term "open source software" has a very specific meaning, and Monkey's Audio as currently licensed is not open source software.

Note2: This isn't directed in any sense at the Monkey's Audio author, since from what I can see he himself describes it as "the source code is available," and doesn't call it "open source"; but some other people are doing so, which is what I'm correcting.

Monkey\'s Audio source code available !

Reply #29 –
i'm not going to complain its not GPL, i'm going to complain that with a license like that it might as well have stayed closed

I don't really care what license they use, as long as its 'open' .. this isn't

I may be stupid, but I know the difference between "open so everyone can use freely and possibly use for themselves" and "open so people improve a closed project for nothing in return"

Monkey\'s Audio source code available !

Reply #30 –
Quote
Originally posted by darwyn
Oh I am SO sorry!

I thought this board was to support people not bash them.

Meff, I can disagree more with you. Its odd that you would tell me off for enjoying a lossless format that compressed 3% better and runs 30% faster.
Both are free and this is obvious intent for Matt, who has always come off as a good spirited person to me, to expand APE to everyone.
Can you tell me does FLAC support tagging? I have never bothered to use it since I read all over on websites and bulliten board how terrible it is.

The point of this thread is the APE is being tested for LINUX. Lets try to stay on this subject.

Darwyn


i'm not bashing anyone, I am stating my opinion.

I never told you off.

As far as tagging, I don't see a reason if you use good descriptions on your directories and maybe even CD-TEXT (like a bunch of my buddies are using) files. But, hey, it could be added, quite easily even. I'm sure if theres enough 'want' then it will be.

What would be really interesting is to see APE contribute optimizations to FLAC, and to create a open merger, being these are the two best lossless codec's with open-style licenses.

Monkey\'s Audio source code available !

Reply #31 –
Quote
Originally posted by 2Bdecided
Jon,

I was saying that everything else is inferior compared to Monkey!


Meff,

Well, it depends how strict Matt is in imposing what he asks. Point (2) isn't even propper English. But it'll be interesting to see if he intends

a) to prevent any one from making any money out of monkey
b) to prevent any one from wrecking monkey, or
c) to prevent any one from even using monkey at all!

Normally, when people say "ask permission to use" it means they'll probably give permission. Otherwise, there's no point to saying "look, here's the source code - but HA - you can't use it!"

And to be fair, Monkey is already the best - better than all the open and closed alternatives - what improvements do you think he's looking for "for free"?

Still, we'll see what happens.


Cheers,
David.
http://www.David.Robinson.org/


a) use the GPL or a variant.
b) trademark the name. let people branch it if they want to, maybe you'll learn something.

if its the best doesn't matter, a good example.. would you rather pay for Oracle which "is 'hack'proof" hehe, or a open SQL alternative? sure, MySQL doesn't have Larry's seal of approval, but it sure as hell does 'good enough', and its being improved all the time, with the sourcecode open.

anyways, I wasn't trying to come off as 'bashing' or flaming anyone, I am just throwing in some opinions into the mix, be constructive, and please don't turn this into a war and I won't

I am sure (though I've never used it) that MA *IS* a really good codec, but it'll get my full respect once a less restrictive license is placed on its codebase.

-r

Monkey\'s Audio source code available !

Reply #32 –
Quote
Originally posted by rjamorim
I agree completely with Matt.

As I posted some time ago, "These same people will now start complaining it isn't GPL. " Sure enough, these @$$holes (like meff - yes, I'm being personal and ballistic - I AM ballistic) saying it should stay closed. Weren't these same people whining it had no specs and no way to use it in other OSes? Well, now you've got all you wanted and keep whining like losers.

IMO, it's the kind of people that is completely obsessed and biased towards Open Source software. Now there is a program that is better than it's Open Source counterpart IN ALMOST EVERY ASPECT, but they don't want to admit that Open Source soft may sometimes be worse. Why don't you guys send a love letter to Stallman? It's the next logical step.

Farewell (And I hope noone edits this message)

Roberto.


Never said one was better or worse, just stating differences.
I may be an asshole, but not an egotistical groupie that calls everyone a stereotype.

No, I am not a GNU freak. No, I don't hump the GPL, I use soo many different types of programs and licenses, and I code many languages and use many operating systems, I know the hoops. You may think that every person using linux is a idiotic script kiddie, well, news for you. YOU are the one thats the idiotic.

I never started bashing nor a flamewar, but you just had to start calling names?
Very mature.

Both are good, use what you want. But don't come whining to me when your strapped by the limitations of non-open software, whilst I am using something MAYBE a *little* less effective, but it's licensing makes up for that. I never said FLAC was better, I said the trade-off is small.

As far as I am concerned with the project, I could care less if it stayed closed. I just know, that even if FLAC ever gets reverted to a closed license, we can branch the last open one -- by Matt's license he can reclaim it anytime he wants, and in fact control people using it to an extent.

Roberto, there are advantages and disadvantages. A closed-type license may suit your needs, but for me, an open-source developer contributing to the ever-growing HUGE pool of totally free and open software, open licenses benefit my efforts further and help me make my projects better for everyone else.

YMMV

I'd appreciate it if you wouldn't call me anymore names

Monkey\'s Audio source code available !

Reply #33 –
Quote
Originally posted by krsna77

Anyone who's payed attention to the whole OpenBSD vs. IPF debacle can surely attest to that. After much arguing and mailing list flamefests, and many very, very bruised egos, the OpenBSD team ended up completely removing IPF (as well as qmail and djbdns), and writing their own solution, simply because the author of IPF did not clearly state his intentions in the first place. It's a shame, because IPF was a well-designed, mature firewalling solution.


lol, that's mainly because Theo de-Raadt is a huge asshole (95% of people who use nix know this  )

But I agree with you..This forum has been really constructive actually, and I hope it continues to be.

Roberto; sorry about previous name-calling.. If you won't anymore I won't

I'm a reasonable person, just.. be reasonable with me.

Monkey\'s Audio source code available !

Reply #34 –
Actually, FLAC looks rather unattractive now. MAC has an unbelievable speed/compression ratio and now that it is (partially) open source, the disadvantages of FLAC look to be too much...for the moment.

The nice thing about lossless is that if you pick the "wrong" format you can reconvert without losing the source.

Monkey\'s Audio source code available !

Reply #35 –
First off: kudos to Matt.

Second: If I were Matt and you starting complaining after I just threw you a bone, I'd seriously consider taking the bone back. Matt will not do this because he's such a cool guy.

What I gather from his license is that he wants to know what you're doing and he doesn't want you to go make a profit on something that's 95% his code. I suspect he also doesn't want the great Monkey's Audio name being tainted... I can just picture all the clones now: .COW, .MOO, .BEAR, .GOAT (ack!)... hahaha

Monkey\'s Audio source code available !

Reply #36 –
Quote
Originally posted by Frank Klemm


CRC problems are often a problem of system stability, an often underestimated problem.
My experiences are that ca. 20% of the systems
have such problems (RAM problems, IDE cable problems).

I agree...  this is a relatively common problem often overlooked (or blamed on Windows  ).  Sometimes overclocking can cause it too, especially clocking RAM out of specs.  There are utils that can test for probs like this, but I'd guess 20% is probably the right number!
 

Monkey\'s Audio source code available !

Reply #37 –
Quote
Originally posted by JohnV
I wonder if FLAC can be tweaked using some of the ideas from MAC. I mean you can protect source with licences, but you can't protect ideas.
And FLAC is streamable, at least MAC 3.80 is not (I'm not sure about latest MAC bitstream). Not sure what other advantages there are in FLAC bitstream compared to MAC bitstream.


Well, now that I've looked through the code, let me post what I've found.

First, the license does not preclude a reimplementation.  In the US, probably no license could (yet).  From the FLAC point of view, for this option to make sense, all of these have to be true:

1. The algorithm should not be covered by any patents.

2. The algorithm should be faster in a cross-platform way, i.e. it should not be faster than the basic FLAC algo on one machine because of assembly, and slower on another when both are in C.

3. The resulting complexity should be worth the improvement for all situations the format is designed for.

First, take #1.  If a format had a patent on it and not backed by a huge conglomerate, it is dead.  From the companies I've talked to, even if your method looks complicated enough that it seems there's a chance of part already being patented, that's enough to make people nervous.  So either someone else has a patent (possible, see #3), Matt has/will have a patent (less likely), or it's scary (see #3) or it's free and clear.

2. Don't know too much about this one yet since I haven't tried to compile it yet (the binary he distributed wouldn't link at runtime for me).  The only thing we know is that without the inline assembly the higher modes are 2-3x slower (from his docs).

3. Let's compare FLAC vs. MAC this way:

FLAC:

- break audio into blocks
- simple interchannel decorrelation for stereo
- construct FIR filter via LPC analysis
- code the residual with static Rice coding

MAC:

- break audio into blocks
- simple interchannel decorrelation for stereo
- fixed first order linear filter
- low order adaptive linear filter
- 0-2 levels of small neural nets
- code the residual with a range coder

Now if you know about this stuff MAC is way more complex.  I'm actually pretty impressed.  But it tells us a few things.  One is, to get the high compression and good speed you have to code the neural net stuff in assembly.  Next, you'll have a hard time convincing someone there isn't a patent on anything in that already.  Last, with all that in mind, it is pretty hard to pop that sucker into an embedded device, which FLAC is intended to do.

So, there is a lot for study there.  I may be able to build off what he's done in a way that is consistent with FLAC goals.  It will be interesting to study his adaptive filter and neural net more.

Josh