Monkey's Audio speed improvements tested

Topic: Monkey's Audio speed improvements tested (Read 3618 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.

Monkey's Audio speed improvements tested

2022-01-15 20:49:55

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)}

CDDA	fast	65,13%	normal	64,07%	high	63,81%	extra h	63,37%	insane	63,17%
(3:25:05)	encode	dec.	encode	dec.	encode	dec.	encode	dec.	encode	dec.
7.23	66	83	92	106	98	110	140	153	291	300
7.00	67	83	94	107	99	111	141	153	292	301
6.61	70	83	95	112	101	119	144	160	302	326
5.71	71	85	96	112	108	122	186	194	493	501
unoff412	66	85	91	112	100	120	164	187	389	433
4.12	64	92	90	122	99	129	164	197	403	444
3.99	72	91	109	127	121	139	208	221	540	544

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/24	fast	69,47%	normal	67,35%	high	67,33%	extra high	66,97%	insane	68,14%
(210 sec)	encode	dec.	encode	dec.	encode	dec.	encode	dec.	encode	dec.
7.23	22	27	30	35	32	36	45	50	91	95
7.00	22	27	30	35	33	36	46	49	93	95
6.61	23	27	31	36	33	38	47	51	95	101
5.71	24	27	32	37	36	39	60	61	153	155

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.

Re: Monkey's Audio speed improvements tested

Reply #1 – 2022-01-15 22:45:51

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 – 2022-01-16 08:53:18

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

Re: Monkey's Audio speed improvements tested

Reply #3 – 2022-01-16 13:48:02

Quote from: Porcus on 2022-01-15 20:49:55

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 – 2022-01-16 16:58:40

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

Quote from: Rollin on 2022-01-16 13:48:02

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.

Re: Monkey's Audio speed improvements tested

Reply #5 – 2022-01-17 05:35:12

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.

CDDA	fast	65,13%	normal	64,07%	high	63,81%	extra h.	63,37%	insane	63,17%
(3:25:05)	encode	dec.	encode	dec.	encode	dec.	encode	dec.	encode	dec.
7.23-64bit	66	83	92	106	98	110	140	153	291	300
7.00-64bit	67	83	94	107	99	111	141	153	292	301
6.61-64bit	70	83	95	112	101	119	144	160	302	326
5.71-64bit	71	85	96	112	108	122	186	194	493	501
7.23-32bit	77	94	110	128	115	129	162	178	317	329
7.00-32bit	80	94	111	126	116	130	165	180	317	335
6.61-32bit	167	199	239	273	241	281	325	368	521	564
5.71-32bit	177	206	244	283	256	293	356	390	633	680
c-bld	66	85	91	112	100	120	164	187	389	433
4.12	64	92	90	122	99	129	164	197	403	444
3.99	72	91	109	127	121	139	208	221	540	544

.

And the stupid-resolution file:

768/24	fast	69,47%	normal	67,35%	high	67,33%	extra h.	66,97%	insane	68,14%
(210 sec)	encode	dec.	encode	dec.	encode	dec.	encode	dec.	encode	dec.
7.23-64bit	22	27	30	35	32	36	45	50	91	95
7.00-64bit	22	27	30	35	33	36	46	49	93	95
6.61-64bit	23	27	31	36	33	38	47	51	95	101
5.71-64bit	24	27	32	37	36	39	60	61	153	155
7.23-32bit	27	32	38	43	39	44	60	60	105	108
7.00-32bit	29	33	39	43	40	44	56	60	103	107
7.61-32bit	50	58	71	81	72	81	96	106	154	167
5.71-32bit	51	59	72	80	75	83	106	115	192	203

Re: Monkey's Audio speed improvements tested

Reply #6 – 2022-01-18 22:51:02

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.

Notice