Monkey's Audio 4.11 available, released January 20, 2013 Options

[madoka@ex-sounds]

Monkey's Audio 4.11 available
URL: http://www.monkeysaudio.com/

Changes:

Version 4.11 (January 20, 2013)
NEW: Switched from MMX to SSE assembly, making compression and decompression faster.
NEW: Switched to latest Microsoft compiler, making everything around 5% faster.
Changed: Removed support for old Monkey's Audio 3.92 and earlier files (it hasn't been possible to make these files for over ten years -- use an old copy of Monkey's Audio to convert these files to the latest format if you have any).
Changed: Fixed a few compiler warnings.
Changed: Removed dependence on third-party NASM assembly compiler in favor of intrinsics (which compile nicely with all major compilers).
Changed: Put all Monkey's Audio source code into a namespace APE so that linking into third-party projects should never have name collisions.v
Changed: Switched from #ifndef/endif to #pragma once (now supported by any reasonable compiler).

[romor]

Congratulations to developers.

Maybe they should have updated their lossless comparison table in provided help file
HA has plenty lossless tests made correctly which can be used for this purpose I guess

[db1989]

Moved to Validated News.

It’s nice to see APE back after almost two years. Some might think that these are minor changes, but I find them encouraging: it looks like they’re aimed towards future development. Given how competitive Monkey’s Audio still is (compressing better than TAK, and almost as well as OptimFrog and [the long-dead and glacially slow] La), it would be great to see improvements; in this spirit, a free 5% boost in speed is a great sign!

[themanintheshado...]

I'm amazed at what I didn't see from this version of Monkey's Audio:

No support for pipe encoding
Error robustness past -c3000? Nothing about that at all.
No blocksize control? Still? (Can't compress high rez audio without it)

Also noticed that this version of APE doesn't play well with the current version of foobar2000 at all. MD5 hashes for APE files can't be seen within the program. Encoding? In three transcoding tests from FLAC to APE, I had problems with 1 to 3 files encoding properly depending on what test I did. Realistically, IMO, you don't know what to expect. I had more success transcoding via command line using Multi-frontend.

Not surprised about the poor support in foobar2000, though. The foobar2000 devs love giving Monkey's Audio the finger, and haven't given them any respect for a long time. With the crap the devs at Monkey's Audio have pulled over the years, though, it's understandable.

[Heliologue]

Not surprised about the poor support in foobar2000, though. The foobar2000 devs love giving Monkey's Audio the finger, and haven't given them any respect for a long time. With the crap the devs at Monkey's Audio have pulled over the years, though, it's understandable.

.APE support is handled by a third-party plugin in foobar2000 (not sure why--licensing problems, perhaps?), so it's a little unfair to blame foobar2000 developers themselves. What about the MA plugin is sub-par, in your opinion?

[db1989]

Yes, theman, please either explain the meaning of your statements and back them up, or stop inviting an argument about APE vs. foobar2000, a battle that I’m not sure has ever happened in reality. At the very least, you may find it more productive to move your concerns to the sub-forum for fb2k, rather than here.

.APE support is handled by a third-party plugin in foobar2000 (not sure why--licensing problems, perhaps?)

Nope. Note the name of the author. Anyway, it was updated as recently as the middle of last year, which, again, does not seem to support the allegation that “the foobar2000 devs love giving Monkey's Audio the finger […] for a long time”.

[Heliologue]

I stand corrected; for some strange reason, I thought kode54 maintained the MA plugin.

That being said, if a component is written by Peter, but exogenous to the program proper, is it still considered "third-party"?

[eahm]

First of all, thanks for the update. I don't use Monkey's but I love competition.

Little OCD annoyance, could you change Foobar to foobar2000 from the homepage? And Media Center, which media center?

Thanks.

edit:
Also in the Links page: 'Easy CD-DA Extractor' is now known as 'EZ CD Audio Converter'

This post has been edited by eahm: Jan 21 2013, 08:55

[shadowking]

Nice update. Most of the negative claims against MAC (as with MPC) are false. Don't believe them.

This is a top performing high compression, actively developed for 13yrs codec with nice GUI.

[dhromed]

Perhaps ktf is interested in this development.

[themanintheshado...]

Not surprised about the poor support in foobar2000, though. The foobar2000 devs love giving Monkey's Audio the finger, and haven't given them any respect for a long time. With the crap the devs at Monkey's Audio have pulled over the years, though, it's understandable.

.APE support is handled by a third-party plugin in foobar2000 (not sure why--licensing problems, perhaps?), so it's a little unfair to blame foobar2000 developers themselves. What about the MA plugin is sub-par, in your opinion?

What about it is subpar? The fact that I can't do a simple transcode of one format to APE (with the current version) without having problems with files not transcoding correctly. This is the first time I've had a a problem with APE transcoding in foobar2000. But, again, what's most troubling to me is simply not being able to see the md5 hash of any APE file in fb2k...which is a first. The other issues are in my original post.

But let's be clear. I'm not favoring fb2k or the bunch over at MA. I think both are at fault in this matter. One side (the MA devs) have such stupid licensing rules that no real progress can be made without coming from them (Ask the people over at Rarewares who came up with a version of APE that used pipe encoding that never went anywhere because of that), and the other (fb2k) is like "We'll improve that plugin when we feel like getting around to it!" The lines of communication need to be opened up. Maybe then we wouldn't have to wait around for 2 years of more for a 5% improvement in speed. Lots of these issues could've, and should've, been addressed years ago.

[Case]

I just converted three albums (50 files) from FLAC to APE with foobar2000 and had zero problems. The files have their md5 checksums visible in the Properties view and Integrity Verifier also reports all files to be fine. Monkey's Audio decoder doesn't need changes since nothing in the file format has changed.

[db1989]

[…] if a component is written by Peter, but exogenous to the program proper, is it still considered "third-party"?

Of course not, since Peter is, by definition, the first party.

The distinction you are talking about is simply one of bundled vs. non-bundled.

[skamp]

On linux, Monkey's Audio 4.11 (with Wine) is actually very slightly slower than my native linux binary (3.99-u4-b5-s7) when encoding a 746 MiB WAV file (16/44.1, stereo): 39.41 seconds vs. 38.26 seconds.

Edit: with a mobile Core i7, so it should benefit from SSE assembly.

This post has been edited by skamp: Jan 21 2013, 14:11

[no404error]

4.10 > 4.11 = +12-15% on Intel i7-3770 w/o TurboBoost.

This post has been edited by no404error: Jan 21 2013, 18:53

[larryfine]

Thanks for the update. I just convert some albums of classical music and no errors reported. There was a slight improvement in speed but the compression ratio remain the same. Anyway, it's good news, MAC has always been a highly reliable format for storing audio files.

[Wombat]

I got used to ape my few Hires files to store them away. I decided to use it over flac for this a while ago and never looked back. Funny how it becomes more and more usable over time with the processing power increasing. I also like the simple but perfectly working frontend coming with it.

The very most important improvement in 4.11 to me is of course the new icon logo

Thanks!

[Rollin]

Doesn't work on CPU without SSE2?

[adamjk]

Doesn't work on CPU without SSE2?

"Switched from MMX to SSE assembly" it's pure nonsense, as my Pentium III is SSE capable, but the Monkey's Audio 4.11 returns error!

[db1989]

Newsflash: SSE does not necessarily equal SSE2

[Rollin]

Newsflash: SSE does not necessarily equal SSE2

Yes, thanks, Captain Obvious
But on my AthlonXP, which doesn't support SSE2, Monkey's Audio 4.11 doesn't work.
So I guess, that Monkey's Audio 4.11 doesn't work on CPU without SSE2. Am I wrong?

[adamjk]

Newsflash: SSE does not necessarily equal SSE2

"Lovell: Houston, we've had a problem." with understanding the problem.

[PQR]

So I guess, that Monkey's Audio 4.11 doesn't work on CPU without SSE2. Am I wrong?

You're right, new Monkey's Audio have SSE2 as well as SSE.

[db1989]

"Lovell: Houston, we've had a problem." with understanding the problem.

Haha, so I did. Thanks to everyone for clarifying the details.

[Destroid]

Changed: Removed support for old Monkey's Audio 3.92 and earlier files (it hasn't been possible to make these files for over ten years -- use an old copy of Monkey's Audio to convert these files to the latest format if you have any).

This is significant for my own person- and possibly others- but 3.97 and later has been prevalent for long enough that (I suppose) it was inevitable.

{rant} I can not upgrade to this install/release for the reason that the remnants of my APE archives are affected, but- no matter!.. lossless is lossless. Although it is unlikely older versions of MAC will puke on newer OS's, only time will tell. Yet, I have to mention- so much for backwards compatibility. :/ (This has nothing to do with "open source" and licensing, so those who want to argue can peddle off to another thread for that ongoing philosophy). {/rant}