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 speed improvements tested (Read 1069 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Monkey's Audio speed improvements tested

TL;DR: Monkey's Audio has become faster than a few years ago, with file sizes being unchanged (at the byte). Hi-rez support is improved, some of it possibly undocumented, but insane is arguably insane on high-rez

Monkey's Audio had as much as 74 new builds last year, and some promise better performance. AFAIUnderstand, any build outside Windows is community-maintained, and I have found no such build since the 3.99 version. So by 2022, some 250 builds later, those users (*cough* there must be a couple?) are left with their feet in the old cold molasses.

I never used Monkey's audio for anything but testing, but having seen the promises of (IMHO much-needed) speed-up, I got a few versions from various sources and put them to work:
* 7.23 x64-bit. Current version, 30. December. Measures slightly better than 7.00.
* 7.00 x64 Promises "Drastically increased the performance (especially of 32-bit compiles)" and did improve a bit on some modes even if I did not try the 32 bit versions to compare.
* 6.61 x64 released 2021-08-25, chosen because it is the highest 6.x and thus the version before 7.00. Takes most of the improvement in extra high and insane modes.
* 5.71 x64 released 2021-01-21, chosen because it is the highest 5.x. Much slower than the apparently 32-bit 4.x.
* 4.12 apparently 32-bit. Unofficial build, allegedly optimized, retrieved from a HA thread. Slightly different from 4.12 official.
* 4.12 retrieved from Archive.org. Would install to Program Files (x86), I found no other. I wanted this because it was used in the most recent edition of @ktf's eminent lossless comparison.
* 3.99 from oldversion.com, because that is what *n*x users get. Much slower than anything new.

All encode to the same size (except when they refuse the hi-rez.)

CDDA: percent of .wav filesize, and seconds rounded to integer - current insane decodes three and a half hours in five minutes on a not-too-modern CPU (but hell I never before realized the ape is that much slower decoding than encoding)
CDDAfast65,13%normal64,07%high63,81%extra h63,37%insane63,17%
(3:25:05)encodedec.encodedec.encodedec.encodedec.encodedec.
7.2366839210698110140153291300
7.0067839410799111141153292301
6.61708395112101119144160302326
5.71718596112108122186194493501
unoff412668591112100120164187389433
4.1264929012299129164197403444
3.997291109127121139208221540544
CD test corpus: Part of what I used here; then selected pseudo-randomly by consecutive MD5 sums. This time cut down to 2 GB .wav size by starting at one end of the alphabet, and concatenated to one tagless file.
 
HiRez, one file. Yes insane creates bigger files than normal and decodes at 2.2x realtime
768/24fast69,47%normal67,35%high67,33%extra high66,97%insane68,14%
(210 sec)encodedec.encodedec.encodedec.encodedec.encodedec.
7.2322273035323645509195
7.0022273035333646499395
6.61232731363338475195101
5.712427323736396061153155
Corpus: this completely bonkers file which the label recorded at DXD, transfered to analog tape, and then re-digitized to 768 kHz/24 bit. Has earned its fifteen minutes fame at the public pillory. Stripped of tags before encoding.
It turned out that 4.12 couldn't handle the hirez file which is why the table stops short of it. I see nothing in the changelog indicating when the support was introduced.

Timing was done with timer64.exe from the 7-zip benchmark suite. All were done three times (because I bugged up the code reading file sizes and had to re-run it, and only on third run I could verify that file sizes are the same) and the smallest figure chosen, presuming that deviations are due to interrupt(ions) blah blah; exception is 3.99 where I also wrote the exe's name wrong, that was run once afterwards.
Used a SSD. I made no attempt at ramdisk'ing - I am lazy, and a promise of "Drastically increased performance" shouldn't need that exact science.
Last two months' worth of foobar2000.org ad revenue has been donated to support war refugees from Ukraine: https://www.foobar2000.org/

Re: Monkey's Audio speed improvements tested

Reply #1
Great. This is the best lossless format in terms of compression. It has everything to beat all others. I think this might be because of that license. "Get your 38 minute albums on an average 193 - 240 MB", perfect motto for this format.

Re: Monkey's Audio speed improvements tested

Reply #2
Only in it for compression? In the silence between tracks you can hear a little OptimFROG ribbiting your name.

Just to get a perspective:
* Monkey's Extra High beats TAK -p4m by .3, but decodes at 5x the CPU load of TAK.
Those 5x worth it? If so:
* Monkey's Insane: beats Extra High by .2 points. Now down to 2x the decoding CPU load.
* OFR at not quite max: beats Extra High by nearly .9 points. At 4.5x the decoding CPU load. Takes effing long to encode, but you only do that once?

(This was the CDDA corpus. For the hirez signal, the monkey just isn't up there:  WavPack outcompresses all apes, and ALAC beats Monkey's High. So if Monkeys' gets *checks notes* 133 updates over the next two years also, then maybe maybe just for sport it gets competitive at totally stupid resolution as well.)
Last two months' worth of foobar2000.org ad revenue has been donated to support war refugees from Ukraine: https://www.foobar2000.org/

Re: Monkey's Audio speed improvements tested

Reply #3
7.00 x64 Promises "Drastically increased the performance (especially of 32-bit compiles)" and did improve a bit on some modes
For 32 bit compiles it was "drastically increased" in version 7.00 after it was drastically decreased somewhere along versions 5.xx - https://hydrogenaud.io/index.php?topic=118944.msg980973#msg980973 Also, from these thread you can notice that developer of Monkey's Audio partially (partially, because for hi-res only) broke backward compatibility without any actual warning.

Re: Monkey's Audio speed improvements tested

Reply #4
Aha, right. I had even stumbled upon it without it sticking to memory. And this shows that some time during 5.x, the 64-bit version took a major performance hit as well. But all in all, a 20-30 percent drop in decoding load since the popular 3.99 isn't bad. (That's high and extra high, which I guess are the reasons to touch the ape at all.)


partially (partially, because for hi-res only) broke backward compatibility without any actual warning.

Terrible practice of course - but it was actually changelogged, immediately, that is at least some kind of warning. (immediately ... I checked web.archive.org snapshots of the same day)

Still, after twenty years the developer should know better than publishing every build on equal footing without any "stable" / "preview" / "alpha" / "beta" status indicated. And, maintain no repository of previous versions nor link to any.
Last two months' worth of foobar2000.org ad revenue has been donated to support war refugees from Ukraine: https://www.foobar2000.org/

Re: Monkey's Audio speed improvements tested

Reply #5
Phew, that 32-bit ... anyone feels playback at a mighty 1.03x realtime?

The extra rows are marked "-32bit", have not been run three times The others - "-64bit" and others - are from the previous table.

CDDAfast65,13%normal64,07%high63,81%extra h.63,37%insane63,17%
(3:25:05)encodedec.encodedec.encodedec.encodedec.encodedec.
7.23-64bit66839210698110140153291300
7.00-64bit67839410799111141153292301
6.61-64bit708395112101119144160302326
5.71-64bit718596112108122186194493501
7.23-32bit7794110128115129162178317329
7.00-32bit8094111126116130165180317335
6.61-32bit167199239273241281325368521564
5.71-32bit177206244283256293356390633680
c-bld668591112100120164187389433
4.1264929012299129164197403444
3.997291109127121139208221540544
.
 
And the stupid-resolution file:

768/24fast69,47%normal67,35%high67,33%extra h.66,97%insane68,14%
(210 sec)encodedec.encodedec.encodedec.encodedec.encodedec.
7.23-64bit22273035323645509195
7.00-64bit22273035333646499395
6.61-64bit232731363338475195101
5.71-64bit2427323736396061153155
7.23-32bit2732384339446060105108
7.00-32bit2933394340445660103107
7.61-32bit50587181728196106154167
5.71-32bit515972807583106115192203
Last two months' worth of foobar2000.org ad revenue has been donated to support war refugees from Ukraine: https://www.foobar2000.org/

Re: Monkey's Audio speed improvements tested

Reply #6
Just a big thank you to Robert Kausch for his help speeding Monkey's Audio back up.  When I added 32-bit and multi-channel I unintentionally slowed it down.  Robert came to the rescue with templates so it uses int instead of int64 when possible.  The current release should be as fast as it has ever been and decode files all the way back to when they were named .MAC instead of .APE.  If anyone has any issues, you can email me at mail at monkeysaudio dot com.  Thanks.