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 - Observations and the need to update some statements on the net? (Read 9681 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Monkey's Audio - Observations and the need to update some statements on the net?

Hi folks.

Concerning MAC, I'd like to lay some observations:

From this page
VLC plays (.APE) YES, seek bar is unresponsive when playing. ( Windows / Linux ? )

I have tested VLC tvOS version, VLC Windows, VLC Linux with some Extra High Files and Insane Files.

VLC (latest version) tvOS:
APE/Extra High plays fine, seek bar is not totally unresponsive when playing, however it lags a lot and timing is inaccurate. It will get going after 3 or 5 seconds the song starts playing. Song plays fine. It will have a lag if you jump throughout the track.

APE/Insane plays fine. Seek bar is halted when playing for the first time. It will move and go if you jump throughout the track. Lag is longer than Extra High and timing is more inaccurate.

VLC (latest version) Windows 10: 
APE/Extra High - It behaves the same as tvOS.
APE/Insane - It behaves the same as tvOS.

VLC (latest version) Ubuntu 21.10:
APE/Extra High - It behaves the same as tvOS.
APE/Insane - It behaves the same as tvOS.

So, more or less, it is clear to me that it is a VLC problem, not the operating systems'.

foobar2000

In my system, foobar2000 does lag a bit when you try to position the seek bar somewhere in the song, for "Extra High". In "Insane" mode, is really unpractical: foobar2000 strives a lot, with a 3 second silence due to halt/seek. Extra High is acceptable, less than half a second.

Rhythmbox in Ubuntu

My surprise was that Rhythmbox in Ubuntu does not have one single lag in "Extra High" , and, "Insane" behaves  as "Extra High" would in foobar2000. "Extra High" not only plays totally fine, but it also displays correct timing all the way. It even feels like it's playing a FLAC file... I guess this has something to do with GStreamer, but this impressed me. I hadn't tried APE in Rhythmbox.

System is AMD FX-8230E (4 cores, 8 threads), 16 GB DDR3, HDD 7200 rpm SATA 6Gbps, GA-990XA-UD3.

Poweramp in Android

"Extra High" does very well: gapless and and seeking are fine (some files don't go totally gapless though). Phone is Motorola One Macro. Battery seems to hold fine - I tested 1 hour playing "Extra High" and it costed 1% of battery.

Music is read from a SAMSUNG 64 GB SD card.

I am wondering whether in 2022, some of the statements in Wikipedia and the page above mentioned are still relevant... a long time has come and mid-end hardware caught up with MAC shortcomings, at least when it comes to more software support and more CPU power available these days.

Statements like this one: "While Monkey's Audio can achieve high compression ratios,[4] the cost is a dramatic increase in requirements on the decoding end. Many dedicated portable media players, and even flagship model smartphones have difficulty handling this" feels no longer true. My phone is not even flagship -- it's a low to mid range price phone. I see no dramatic thing playing APE files fine and using very very little power.

I do want to know why Rhythmbox is so fast with "Extra High" and very acceptable with "Insane" modes, beating even foobar2000 by a considerable amount.

Even the mobile Poweramp app beats foobar2000 mobile when playing "Extra High", by a little margin - foobar2000 mobile is better with gapless feature -- Poweramp sometimes is not able to produce gapless in all APE files.

Reading the Wiki for HA, some things apply to WavPack as well -- I can play WV files on a ATV4K box + VLC and it's very fast. Same for Poweramp with WV files.

So what do you guys think?

-- krafty

Re: Monkey's Audio - Observations and the need to update some statements on the net?

Reply #1 –
I started some discussion on updating lossless codecs' HA wiki pages, and I might be a few years late for anyone to care.  I have a couple of unfinished drafts at some other computer somewhere else; not Monkey's though, but I posted a couple of tests (including one you have seen ... oh eff now I see that the table's last "7.61-32bit" should have been 6.61-32bit) and have a couple more to be written up.

Certainly we get much more of both CPU juice and storage than in the age when iPods struggled to play Monkey's Normal at realtime speeds, so both the reasons to avoid the ape and the reasons to choose the ape are less significant. So 2010 blanket statements that were acceptable blanket statements with 2010 hardware ... sure, fix. And it is good to see someone actually trying to test battery impact, although an hour wasn't much.
But I would certainly show a bit of patience when it comes to the more recent changes.  Monkey's was released in two hundred new versions over 2019 through 2021, and you cannot expect developers to come running aligning everything to whatever Mr. Ashland will revert the next week.

Now VLC ... argh, VLC. Problem is, even if it is VLC to blame (I don't know, but given how VLC didn't support gapless I wouldn't be surprised if ...) then the codec's problem is, end users need something to play the thing on and if it doesn't play properly one of the more common players ... "doesn't play well on VLC" is quite a handicap, like it or not. (I don't.)

As for WavPack, the developer has kept an old warning against -hh on portables and so I kept it in in the draft WavPack wiki page even if it is only double load of WavPack fast. One could discuss whether even another doubling into Monkey's Extra High isn't worrysome anymore either. (Yes, a doubling of decoding load compared to WavPack -hh; then I have taken figure 1.2 in ktf's survey and factored in a twenty-five percent speed-up from my figures!)
 

So ...  obviously outdated figures are obviously outdated, but still think twice for everything else? 

Re: Monkey's Audio - Observations and the need to update some statements on the net?

Reply #2 –
But, can your various Monkey-supporting players handle these files?

Created with version 7.23, which was the last one of last year.

Re: Monkey's Audio - Observations and the need to update some statements on the net?

Reply #3 –
PS. I tested Monkey's Audio with FFmpeg ages ago. It required me to add things to my decoder. Basically, the seeking function is inaccurate, I have to read the timestamp/sample of the first decoded packet after seeking, then discard samples.

Recently, I added more code to my FFmpeg handling input, this time, disabling avcodec's start of stream discard feature with (codecCtx->flags2 |= AV_CODEC_FLAG2_SKIP_MANUAL;), then discarding stream->start_time worth of samples at the start, and setting all seek operations to discard that many more samples than the target position. This seems to fix gapless decoding and seeking.

(The built-in skipping only supports skipping up to a single packet worth of audio, and often discards more than that, returning EAGAIN errors, making you think you lost a whole packet. Also, it doesn't adjust the stream/packet PTS according to the skip, so seeking is again inaccurate if you don't skip manually.)

Re: Monkey's Audio - Observations and the need to update some statements on the net?

Reply #4 –
I only tested VLC and ffmpeg on Windows.

Those two tracks I attached above, are multichannel and don't play.  Monkey's started doing multichannel at version 4.86. 
I suspected that the 3rd party support is based on the code from those ports that were done around 3.99 (from seventeen years ago!), which could be pretty much outdated then?

So considering obsolete statements around the 'net ...
Are statements promising 3rd party support outdated? (And with that, support outside Windows?)




As for VLC, it surely misbehaves: Pause takes seconds to respond, and resume by a another click on the pause button will give you a second or two of music and then it can even mute the rest of the track (this also on "Extra High"). That is unnecessary given that it seeks instantly.
It is only "cosmetic" that the time progress does only update every 7th second on Extra High and every 26th second on Insane.  (Wonder if that is the block size? I intentionally corrupted an .ape to check if ffmpeg could recover the rest of the file, and I have seen losses > 20 seconds.)

Re: Monkey's Audio - Observations and the need to update some statements on the net?

Reply #5 –
Nope, they don't play here, either. Thanks, FFmpeg, for only supporting Monkey's Audio from ages ago.

Re: Monkey's Audio - Observations and the need to update some statements on the net?

Reply #6 –
Well looking closer at version history, 4.86 is as recent as August 2019. Since then, Ashland has adopted the brilliant idea of new release every time he changes a character in the installer or so, and all releases on equal footing with no "alpha" or "beta" or "stable".
Meaning, new features are introduced without warning that they are experimental and compatibility can be broken next week.  There are warnings when the next version has broken compatibility and the old version is removed with no link to how you can retrieve it to decode your files if you installed the new atop the old.
(Not sure of the damage done. Did any end-user ever encode a multi-channel .ape ... until yesterday ...?)

So I wouldn't knock ffmpeg devs too hard ... and speaking of which:

Quote from: kode54 on
only supporting Monkey's Audio from ages ago.

https://cogx.org/ lists Monkey support. https://cog.losno.co/features does not.
Not sure if that warrants any knocking either.

Re: Monkey's Audio - Observations and the need to update some statements on the net?

Reply #7 –
It does support Monkey's Audio. But the features list needs to be updated to note as such.

It also needs to be updated to mention TAK, since I also support that via FFmpeg.

TagLib is utilized for tag reading for both. Or at least, it should be utilized. I think I added those formats to the generic APE footer tag handler.

Re: Monkey's Audio - Observations and the need to update some statements on the net?

Reply #8 –
Quote from: Porcus on
Well looking closer at version history, 4.86 is as recent as August 2019. Since then, Ashland has adopted the brilliant idea of new release every time he changes a character in the installer or so, and all releases on equal footing with no "alpha" or "beta" or "stable".
Meaning, new features are introduced without warning that they are experimental and compatibility can be broken next week.  There are warnings when the next version has broken compatibility and the old version is removed with no link to how you can retrieve it to decode your files if you installed the new atop the old.
(Not sure of the damage done. Did any end-user ever encode a multi-channel .ape ... until yesterday ...?)

I'm glad I switched my library over in late 2015-early 2016 to FLAC + Wavpack and dumped Monkey's Audio.

Re: Monkey's Audio - Observations and the need to update some statements on the net?

Reply #9 –
Well to be fair, compatibility issues were for a few days with multi-channel or 32-bit. Apparently.
... although there is a mention of compatibility issues at the release of 5.24. (I haven't tested it. Those curious can find old versions at https://www.videohelp.com/software/Monkeys-Audio/old-versions .)

But quickly ape'ing a CDDA track (from a tagless .wav) with 3.99/4.12/5.71/6.61/7.00/7.23, they all generate bit by bit the very same files. sha-1'ing the files yes.

Re: Monkey's Audio - Observations and the need to update some statements on the net?

Reply #10 –
Off-topic, page description for Cog updated to include the two extra codecs that were long supported, but not actually listed in the features page. Namely, Monkey's Audio and TAK. I don't support either one via their official libraries, but by FFmpeg, so features may be missing. I did test general support, though. Wavpack is also supported, including floating point and DSD. I do the DSD decimation and downsampling myself, though.

Re: Monkey's Audio - Observations and the need to update some statements on the net?

Reply #11 –
Edit: Wait, test this please. Things sound different here and there.


Observation made:
24-bit .ape does not work with VLC (on Windows) nor with foobar2000 mobile for Android. Listen to what happens to the attachment at the end.

Not surprising, when I tried to compress the .wav with Monkey's 3.99 (which the independent implementations are based on, apparently) - it refuses.
But that is surprising: searching the changelog, 24-bit files should have been supported at that stage?! There is some mention of an overflow bug though.

But, good thing (and another surprise): ffmpeg decodes the .ape.

Re: Monkey's Audio - Observations and the need to update some statements on the net?

Reply #13 –
Surely somewhere inbetween Monkey's Audio release schedule and FLAC's release schedule there is release schedule nirvana.

Re: Monkey's Audio - Observations and the need to update some statements on the net?

Reply #14 –
Quote from: Porcus on
Not surprising, when I tried to compress the .wav with Monkey's 3.99 (which the independent implementations are based on, apparently) - it refuses.
You can't give it a WaveFormatExtensible file, like to most other tools of this time period. Change the codec ID from FE FF to 01 00 and it will compress.

The author should have released an "APE2" format with new features instead of silently breaking compatibility. I can't have a collection of music where some files play and some don't, and I can't easily sort out ones that don't and transcode them.

Re: Monkey's Audio - Observations and the need to update some statements on the net?

Reply #15 –
Quote from: j7n on
You can't give it a WaveFormatExtensible file

Argh, so I fell for this again. .wav ain't .wav in this way or that way.

Thank you.
I am still confused over this third party monkeybusiness though.



Quote from: j7n on
like to most other tools of this time period

"of this time period", insulting TTA and all their eleven users, are we?  O:)

No, as a matter of fact: there is a certain video game music fan remix repository (I think it is?), that swears by TTA over FLAC due to TTA's alleged absence of metadata support (!)

Re: Monkey's Audio - Observations and the need to update some statements on the net?

Reply #16 –
I mean, back when I used to collect unofficial live recordings, I remember one taper who was using shn well into the 2010s because of a bad experience with a corrupted FLAC.

Despite the fact that IIRC shn files are gonna do worse if corrupted and probably are marginally more likely to experience corruption due to larger file size.

EDIT: TL;DR: People are dumb and make decisions based on stupid reasons...

Re: Monkey's Audio - Observations and the need to update some statements on the net?

Reply #17 –
I would not bet on Shorten being more prone to corruption. Botched tag updates have ruined lots of files throughout the history of IDE and SATA, and Shorten possesses a, what shall we call it, kind of naturally immunity against that kind of thing.

(TTA does not, but those who chose TTA over not realizing it has tag support, might have saved themselves some corruption still.)

Re: Monkey's Audio - Observations and the need to update some statements on the net?

Reply #18 –
Quote from: Porcus on
there is a certain video game music fan remix repository (I think it is?), that swears by TTA over FLAC due to TTA's alleged absence of metadata support (!)
If I'm interpreting the curator's statements correctly, it's not the outright absence of metadata but the way metadata is supported: FLAC is a whole container format with headers that need to be adjusted for metadata, whereas TTA glues ID3 onto the end.

The curator also mentions a second reason for preferring TTA over FLAC: the absence of configuration options. I'm sure managing such a large collection of files is easier when you don't have to worry about whether they've all been compressed with the same settings.

Re: Monkey's Audio - Observations and the need to update some statements on the net?

Reply #19 –
Quote from: Porcus on
insulting TTA
No, here is the insult: I forgot TTA existed. It was discovered relatively recently that 24-bit WAV files "should" be written differently, including by ffmpeg, and tools, including big name software products, usually have a simple check for whether the file contains uncompressed PCM.

Why is it important for files to be compressed with the same settings? If I load FLAC files into a player, I do not see the encoding parameters and am not disturbed by them, and the decoding speed doesn't change. As long as the FLAC format doesn't change, any version or setting is as good as another. Monkey's Audio is different obviously.

Re: Monkey's Audio - Observations and the need to update some statements on the net?

Reply #20 –
Quote from: Octocontrabass on
Quote from: Porcus on
there is a certain video game music fan remix repository (I think it is?), that swears by TTA over FLAC due to TTA's alleged absence of metadata support (!)
If I'm interpreting the curator's statements correctly, it's not the outright absence of metadata but the way metadata is supported: FLAC is a whole container format with headers that need to be adjusted for metadata, whereas TTA glues ID3 onto the end.
Hm, *googles* ... well, "no embedded metadata support" can mean "metadata at the end" if you are loose enough about the tech. Though I am not convinced. The other part, on the other hand:

Quote from: Octocontrabass on
The curator also mentions a second reason for preferring TTA over FLAC: the absence of configuration options. I'm sure managing such a large collection of files is easier when you don't have to worry about whether they've all been compressed with the same settings.
Yes indeed! And it is absolutely a valid point for files that are torrented around: with TTA, "bright" users won't run flac --force --best *.flac through their D:\shared

Re: Monkey's Audio - Observations and the need to update some statements on the net?

Reply #21 –
Quote from: Porcus on
I would not bet on Shorten being more prone to corruption. Botched tag updates have ruined lots of files throughout the history of IDE and SATA, and Shorten possesses a, what shall we call it, kind of naturally immunity against that kind of thing.


My thought was that larger files are more vulnerable to random bits flipping or sectors becoming unreadable because there's more of them, and shn has a lower compression ratio than FLAC unless you do something stupid like the "uncompressed FLAC" command line that audiophools seem to love

Re: Monkey's Audio - Observations and the need to update some statements on the net?

Reply #22 –
In other news from the monkeys' den, the help file is now removed. That's about time. From the most recent 2022 version of the now-obsoleted .chm:

... four compression modes. I don't know when Monkey's got the fifth, the changelog doesn't even mention "Insane".
But Rkau was removed in April 2004.

Not only that, it includes Ogg Vorbis, which has the following great properties:

(To HA readers unfamiliar with the Monkey licensing issue, which is so bad that even the maintainer of the *n*x port blames the license for why the decoder should only be used to convert your lossless files away from .ape:
The license advocates GPL violations, and lays claim to even "ideas" you might have gotten from the source code - a patent application would at least have been through a prior art check as to whether those ideas were already from somewhere else.)

Re: Monkey's Audio - Observations and the need to update some statements on the net?

Reply #24 –
The .CHM removal trend is bad.  What for ?  This website redirect  is ugly.
Instead, the .chm file should have been updated. CHM is in itself HTML .