http://www.monkeysaudio.com/index.html (http://www.monkeysaudio.com/index.html)
Version 4.02 (January 19, 2009)
1. NEW: Includes Directshow filter for decoding APE files in any DirectShow compatible player like Windows Media Player, Zoom, etc.
2. Fixed: Corrupt APE files could cause decoder crashes in rare cases.
3. Changed: Updated builder that gets better compression, making for a smaller download.
Still no comments
So Monkey's audio isn't dead. Is v4.02 the last convulsion?
Still no comments
apparently there is not much interest (http://www.hydrogenaudio.org/forums/index.php?showtopic=68338&hl=) in ape
Four major factors:
- Extremely slow seek (very very painful).
- Speed compression is slow.
- Source code release delayed eternally. Just sometime ago I heard it was released.
- Extremely good competitors: WavPack, FLAC and TAK. (The latter achieving basically same APE compression).
Note to TAK: learn from APE's failure for not releasing the decoder source in time.
I don't mind TAK being closed source, but it's essential for its life that it can be decoded anywhere, by anything, anytime.
That's great news!
In my personal opinion I don't see any reason why I shoud use FLAC instead of Monkeys Audio when looking at these figures from synthetic soul's lossless comparioson:
Encoder Setting Original Compressed Duration Compression Time Rate Time Rate
Monkey's Audio Extra High 2030.59 MiB 1280.54 MiB 03:18:21.240 63.062% 00:09:18 21x 00:09:30 21x
TAK -p4m 2030.59 MiB 1290.33 MiB 03:18:21.240 63.544% 00:14:01 14x 00:01:54 104x
FLAC -8 -Ax2 2030.59 MiB 1328.08 MiB 03:18:21.240 65.404% 00:16:39 12x 00:01:35 125x
Monkeys has the highest compression amongst these three codecs with the highest compression speed of the three. The application works flawlessly - I'm compressing using 4 threads so the compression is very fast. I use Monkeys for backup and also use it for playback on my Media Center PC - MediaPortal software plays back Monkeys audio natively without the need to install any codec. On mobile devices I use mp3 anyway. I can always verify the integity of the files because Monkeys stores the md5 checksum.
Well TAK would be an alternative (only 0,5% less compression) but due the closed source and the limited support in different playback software it is not an option for the moment.
Decompression speed does not matter for me nor do I have problems with seeking. So for me personally it's my lossless codec of choise. I do not understand all the hype about FLAC.
- Extremely slow seek (very very painful).
Depends on the compression level.
- Speed compression is slow.
Compared to what? As an example, MAC -c1000 typically provides better compression than flac -8 and encodes nearly three times more quickly. Without establishing some type of basis for comparison by taking compression level into account, your statement is meaningless.
- Source code release delayed eternally. Just sometime ago I heard it was released.
The source has been available for a few years now, just not in a way that complies with general public licensing. Matt wants his code to be
completely free.
Hype about FLAC?
- Open Source since its birth.
- Until here the predominat lossless format with more hardware support.
- Cross-platform since day 0.
- MD5 Calculations.
- You name it!
@greynol:
1) High & Insane
2) Compared to TAK
3) I think it's too late for Matt to make the way he wants (competitors will storm APE away).
Let's refrain from starting the usual petty flame war over lossless codecs.
Nice, a new release from an old lossless mainstay, Monkey's Audio. Going to test it out and probably use it here or there like I do other lossless codecs.
Is it right that the codec itself is still ver 3.99? foobar tells me so.
If not, please tell me that I'm the dummiest person ever (Greynol you have permission ;-) )
I compressed a file and yes, Foobar shows 3.99.
The codec is still very good at what it does so I never understood that "war".
4.02 is just the GUI. The codec is still the same.
4.02 is just the GUI. The codec is still the same.
decoders have small update which change version number from 3.9.9.0 to 3.9.9.1.
Welcome back to the king It's nice to see that the project is still breathing... albeit with slow and shallow gasps.
My one question: The 4.01 release included a CoolEdit/Adobe plugin that just crashed and completely failed to work. Has this been fixed?
EDIT: Never mind, I couldn't resist checking myself, haha. The plugin remains as useless as it was before. As soon as you try to access the options for saving an APE file, it crashes the whole application (both CoolEdit and Audition). Since this has been acknowledged but hasn't been addressed for 2 years, I am now content to move on from Monkey's Audio sadly. It was once a great application but it doesn't seem to care about supporting its user-base.
The source has been available for a few years now, just not in a way that complies with general public licensing. Matt wants his code to be completely free.
public domain would be completely free. bsd is the next closest as a license. the ape license (http://www.monkeysaudio.com/license.html) is somewhere between that and lgpl/mpl
Note to TAK: learn from APE's failure for not releasing the decoder source in time.
I don't mind TAK being closed source, but it's essential for its life that it can be decoded anywhere, by anything, anytime.
too late I think. once open source, anything good in tak can be put into flac easier than flac can be replaced with tak.
the sequence of events with tak and ape is practically identical, right down to the timeline. my experience with ape is why I suggested yalac techniques merge with flac in the beginning (2.5yrs ago).
too late I think. once open source, anything good in tak can be put into flac easier than flac can be replaced with tak.
the sequence of events with tak and ape is practically identical, right down to the timeline. my experience with ape is why I suggested yalac techniques merge with flac in the beginning (2.5yrs ago).
Is there no room for support of more than one codec? I totally agree that any other codec has an impossible task to usurp FLAC as the most popular lossless codec; however the thought that it is too late for TAK to gain any hardware support solely because FLAC is already available is a little daunting. Open source or not, it's nice to have a little competition. Wavpack seems to be increasing its hardware support all the time.
This may need to be moved to a new thread.
And we're talking about lossless codecs: converting to an other format is very easy and fast and no information is lost. If tomorrow a new lossless codec shows up with similar features as FLAC, Wavpack or TAK but for example with a compression of more than 50% and easy to implement in hardware then the market share distribution can change very fast.
ape is already the #2 codec with hardware support (some modes) due to chinese portables, way ahead of wavpack. tak could also achieve the same thing in a niche or eat into ape's niche; that's fine. and on PCs there is a lot more room for alternatives.
but we have to be careful what we wish for. due to inherent features of physical, breakable, brickable, returnable electronic products with short design cycles, the mainstream market has I think room for at most one non-proprietary lossless codec. rally behind one and we'll probably get it. fraction into ape/tak/shn/wtflolbbq and we'll get nothing; we'll be stuck with wmal or something. we're not going to get another chance at this. flac has the momentum and is still the only codec that is suitable for mainstream use (archival+playback+distribution) for many reasons which I've written about before. the best the alternatives can offer is a few percent compression, hardly a reason to try and jump ship.
If tomorrow a new lossless codec shows up with similar features as FLAC, Wavpack or TAK but for example with a compression of more than 50% and easy to implement in hardware then the market share distribution can change very fast.
if you mean 2x the compression of the current state of the art, no such codec is possible, and even then it would not be a fast transition. mp3 was around many years before it became ubiquitous in devices.
That's great news!
In my personal opinion I don't see any reason why I shoud use FLAC instead of Monkeys Audio when looking at these figures from synthetic soul's lossless comparioson:
Wow. I don't see a reason to use Monkeys audio! It's about as proprietary as you can get. Even Microsoft invented formats have more support. I can play FLAC files on my iPod with Rockbox and it's supported natively on my Sage HD extender. Any hardware support outside of PC's = Good.
Low CPU usage for decompression is worth the few extra points lost of compression.
It's about as proprietary as you can get.
http://www.hydrogenaudio.org/forums/index....st&p=545782 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=21858&view=findpost&p=545782)
http://etree.org/shnutils/shntool/ (http://etree.org/shnutils/shntool/)
...and even though it sucks when it comes to hardware decoding because it's a symmetric codec:
http://www.rockbox.org/twiki/bin/view/Main...decMonkeysAudio (http://www.rockbox.org/twiki/bin/view/Main/SoundCodecMonkeysAudio)
Well, I still beg to differ. MP3 support is widespread because it works on more than PC's. If it weren't for MP3's, the portable music player revolution may not have happened. Playing WAV and VOC files didn't do it - it was MP3.
FLAC is gaining the same kind of respect, along with AAC. I'm glad Rockbox supports it sort-of, but it still is very CPU intensive.
http://www.ciao.com/Cowon_iAUDIO_F2__10061549 (http://www.ciao.com/Cowon_iAUDIO_F2__10061549)
http://www.macupdate.com/info.php/id/14246/xact (http://www.macupdate.com/info.php/id/14246/xact)
http://tmkk.hp.infoseek.co.jp/xld/index_e.html (http://tmkk.hp.infoseek.co.jp/xld/index_e.html)
http://sbooth.org/Max/ (http://sbooth.org/Max/)
http://sbooth.org/Play/ (http://sbooth.org/Play/)
http://www.voxapp.net/ (http://www.voxapp.net/)
I still use MAC for several reasons:
1) None of my primary software/devices support FLAC natively, but their features outweigh that deficiency IMO
2) Given 1 above, I use lossless for archive purposes and not for playback. MAC wins the compression contest hands down
3) Unlike the FLAC developer, MAC's developer actually took the time to build a usable GUI to go with the codec. I like being able to set the priority of the encoding process and to pause it if I want
Good release
Monkey's is the open source lossless codec with the highest compression ratios. A new release is welcome!
Flac is convenient, Wavpack is flexible, TAK is promising... they all have their place -- even though I do agree with Josh that "market fragmentation" is disadvantageous in the interests of hardware support. But I'll gladly convert my one lossless format to any [decent] open-source one if hardware support becomes commonplace. It would make sense to rally behind one format; what we actually use on our computers isn't too relevant.
EDIT: MPEG-4 ALS is already an ISO/IEC standard, with reference encoders, decoders, and specs available.
...
If tomorrow a new lossless codec shows up with similar features as FLAC, Wavpack or TAK but for example with a compression of more than 50% and easy to implement in hardware then the market share distribution can change very fast.
if you mean 2x the compression of the current state of the art, no such codec is possible, and even then it would not be a fast transition. mp3 was around many years before it became ubiquitous in devices.
Yes, I meant the compressed result is less than half the original wav size. Though I only meant it just as a possible motive to switch codec, I wonder why such isn't possible. I haven't seen any study determining the limit and I've seen so many "impossible" evolutions which are now part of our daily life
But then, in industry and market only survive the easy and cheap producible solutions (includes hardware and non-hardware costs), allthough their quality may not be the best.
the best the alternatives can offer is a few percent compression, hardly a reason to try and jump ship.
Many people are not jumping ship: they boarded a different ship at the dock.
I do see your point about fragmentation.
I still use MAC for several reasons:
1) None of my primary software/devices support FLAC natively, but their features outweigh that deficiency IMO
makes sense
2) Given 1 above, I use lossless for archive purposes and not for playback. MAC wins the compression contest hands down
does not follow... there are codecs that compress more, codecs that compress faster, codecs that compress more at the same speed, and codecs much better at recovering from errors (
very important for archival). we've all seen the comparisons and there is no "hands down" winner.
3) Unlike the FLAC developer, MAC's developer actually took the time to build a usable GUI to go with the codec. I like being able to set the priority of the encoding process and to pause it if I want
usable
windows GUI. and you can use his gui to create flac files. and I'm not sure I could make a better gui than all (http://flac.sourceforge.net/download.html#extras) these (http://flac.sourceforge.net/links.html#software) already existing ones.
If tomorrow a new lossless codec shows up with similar features as FLAC, Wavpack or TAK but for example with a compression of more than 50% and easy to implement in hardware then the market share distribution can change very fast.
if you mean 2x the compression of the current state of the art, no such codec is possible, and even then it would not be a fast transition. mp3 was around many years before it became ubiquitous in devices.
Yes, I meant the compressed result is less than half the original wav size. Though I only meant it just as a possible motive to switch codec, I wonder why such isn't possible.
white noise cannot be compressed at all losslessly. you can make an audio file that cannot be compressed to even half size by any compressor simply by mixing a loud track with half-scale noise. what you describe is not a usable metric for evaluating compression because it is too dependent on the input.
state of the art lossless compression is close enough to the noise level of the input already. a theoretically perfect compressor is not going to deliver enough of a compression advantage to make people abandon a perfectly good, widespread format. for proof of that look at competitors to mp3 which can deliver a greater such compression advantage but have not become dominant.
It's about as proprietary as you can get.
I wouldn't call ape proprietary... from the source code we can completely figure out the format even though it is not documented any other way. what would make it proprietary is if Matt patented aspects of it and/or required licensing the format and I doubt he would ever do that.
contrast that with alac... parts have been reversed engineer, parts have not, it has changed a few times and almost certain that parts are patented, otherwise they would have just used flac instead of starting with flac and tweaking it into something proprietary.
...codecs much better at recovering from errors (very important for archival).
A corrupt flac is no more useful to me than a corrupt ape. If you're afraid of archival corruption, include redundancy.
white noise cannot be compressed at all losslessly. you can make an audio file that cannot be compressed to even half size by any compressor simply by mixing a loud track with half-scale noise. what you describe is not a usable metric for evaluating compression because it is too dependent on the input.
state of the art lossless compression is close enough to the noise level of the input already. a theoretically perfect compressor is not going to deliver enough of a compression advantage to make people abandon a perfectly good, widespread format. for proof of that look at competitors to mp3 which can deliver a greater such compression advantage but have not become dominant.
Compressing white noise is an extreme, as is compressing a Sine tone I suppose (flac is 80% smaller than wav). Obviously I was referring to averages.
But this was not my point, compression level was just an example of an argument that could make somebody to switch codec. Personally I have a strong wish: play lossless in my car through USB or some SDHC mem (just drag&drop and go). I can't play FLAC in my car this way, and judging from the FLAC website or the absence of positive answers at this post (http://www.hydrogenaudio.org/forums/index.php?showtopic=66595) or this one (http://www.hydrogenaudio.org/forums/index.php?showtopic=67200) there won't be FLAC support in car equipment any time soon (or even maybe never). Now I have my rips in FLAC but if for example Wavpack will be the first lossless codec to be implemented in some major car stereo brand I won't hesitate to convert my complete collection. The point is: everyone has their arguments or motives to use one or an other.
Widespreadness is no garantee to being ever dominant. If I remember well years ago Shorten was dominant in lossless audio compression, then APE and now FLAC. Nobody knows which will be next, maybe mp4 als or even mp4 sls, or maybe lossless compression formats just dissapear as source material won't be wav/pcm anymore but a format without redundant information.
This post got too long and is not really ape4.02 related, maybe this part should be split.
Version 4.03 (January 21, 2009)
1. Changed: Added a help link to the help menu to show the included help file.
However.
Four major factors:
- Extremely slow seek (very very painful).
...
Isn't it possible to be implemented a similar approach as in the new Musepack decoder for searching in old files without seek tables? Or the problem is not related to (missing) seek tables?
what about native decoding support in foobar2000 now?
The source has been available for a few years now, just not in a way that complies with general public licensing. Matt wants his code to be completely free.
I think the problem is slightly different.
several Linux distribution maintainers have found the license to be contradictory. It does not permit redistribution or modification, and thus is not considered open source or free software.
Your comment would have made sense if Monkey Audio used the BSD license, assuming you don't like the "viral" nature of the GPL, but a BSD style license, (which won't stop anyone in using the code in closed projects) is still considered GPL compatible and falls into the Free Software category as defined by the FSF.
The Freedom in Free software means the freedom to
Run (any purpose), to
Study (access to code), to
Redistribute (to anyone), and to
Improve (modify and redistribute modified). This does not necessarily imply the GPL, even though it is the recommended license to maintain freedom.
In the case of Monkey Audio, restrictions to Redistribution and Modification are unacceptable and this renders the software Non-free. It has nothing to do with not using the GPL, and there are various licenses which allow complete Freedom.
(http://www.gnu.org/philosophy/category.jpg) Here Monkey Audio stands at the right, on top of Shareware.
Here is a list of licenses which are free: http://www.gnu.org/licenses/license-list.html (http://www.gnu.org/licenses/license-list.html)
This is the offending statement as Matt put it (from http://www.monkeysaudio.com/license.html (http://"http://www.monkeysaudio.com/license.html)):
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.
Make of it what you will.
Version 4.05 now available
History:
Version 4.05 (February 3, 2009)
1. Fixed: Directshow filter would fail to register on some systems.
2. Changed: Added CompressFileW2, DecompressFileW2, etc. functions that take a C++ interface as a callback for easier usage in multi-threaded environments. (as opposed to the old static function callback)
Version 4.04 (February 2, 2009)
1. Fixed: Directshow filter had an unnecessary dependence on a MSVC system dll.
Still no comments
apparently there is not much interest (http://www.hydrogenaudio.org/forums/index.php?showtopic=68338&hl=) in ape
Yes, the interest for Monkey's Audio has been very high at the beginning of the decade, but since then it has done nothing but epically plummet. (http://img206.imageshack.us/img206/3774/ha1fg1.png) (The graphs are from that very same poll.)
I recall that I, myself, have been very interested in Monkey's Audio around 2002/2003, but ended up using FLAC and almost completely forgot about Monkey's Audio, because FLAC doesn't suffer from awfully slow seek times and is supported by a far greater amount of hardware. What is a couple of megabytes more compared to that, especially when, to bring out the best of the codec, you need to wait a dozen seconds to seek through the song?
What's with the word "share" in the title of your graphs? Those polls have nothing to do with sharing.
What's with the word "share" in the title of your graphs? Those polls have nothing to do with sharing.
How am I supposed to know, I didn't make those graphs - they're available from the first post in the poll (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=68338&view=findpost&p=607138).
What's with the word "share" in the title of your graphs? Those polls have nothing to do with sharing.
As the total of all entries adds up quite close to 100, I always
assumed it was the "market share" of each format.
So it wasn't a conspiracy?
EDIT: Though I would call it a hydrogenaudio share of each format. In other parts, things might be very different, though I'm inclined to agree with everyone else, MAC is dying. That said, I've never had a problem seeking with the format except possibly when using the insane preset, but even then I don't think I've ever had to wait for a dozen seconds.
That said, I've never had a problem seeking with the format except possibly when using the insane preset, but even then I don't think I've ever had to wait for a dozen seconds.
Yes, I exaggerated a bit, I apologise.
But still, I want it to seek nearly instantly, I don't want to be able to
measure the time it takes it to seek in seconds, which you can do with Monkey's Audio on highest compression settings.
Agreed, but there's a reason the highest compression setting has the name that it does. Seek time with Extra High is a fraction of a second.
It's really a silly argument when you realize that you still get excellent compression without having to use extreme settings.
Agreed, but there's a reason the highest compression setting has the name that it does. Seek time with Extra High is a fraction of a second.
It's really a silly argument when you realize that you still get excellent compression without having to use extreme settings.
Well still, it's certainly a bad design when the seek/decode time depends on the level of compression. I like using the very highest compression setting that I can and FLAC's seek/decode time doesn't at all depend on the level of compression.
Even if you don't think that's important, there's still the fact that FLAC is supported by much greater amount of hardware.
And also, on a less important note, Monkey's Audio doesn't achieve as good results combined with lossyWAV as FLAC does.
Before YALAC/TAK there was no asynchronous lossless codec that could deliver comparable compression levels, nor encode as quickly at similar compression levels. This was without having to make the dumb choice of choosing the insane preset.
Things are clearly different now and as I said I agree that MAC is not the greatest choice for a myriad of reasons, none of which really require any exaggeration. There's no reason to rehash them, IMO; they've been done to death. I really don't see the point in resurrecting this topic after four months just to put forth stale arguments. IOW, been there, done that.
I really don't see the point in resurrecting this topic after four months just to put forth stale arguments. IOW, been there, done that.
Actually I Googled for Monkey's Audio to see if anything revolutionary has happened to it and the search returned, among other things, this topic. I read through it and decided to point to that interesting graph I've found without realising I'm resurrecting the thread. I apologise for that.
Actually, I didn't know MAC was bad with lossyWAV. I'll make a note of that, thanks.
My apologies for being a complete idiot about Guru's image and for giving you such a hard time in general.
My apologies for being a complete idiot about Guru's image and for giving you such a hard time in general.
No problem, that's what we all love to hate about the lack of facial contact in the on-line conversations.