Skip to main content


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.
Recent Posts
Lossless / Other Codecs / Re: APE command line tool (mac.exe) decoding error since version 7.78
Last post by Porcus -
It's version 9 and I almost feel like I should do something clever!  But I'm running out of clever ideas!

The L word? Oops, what did I say ...

But, what about better support for decoding through errors? Monkey's didn't come out on top when I tested this January at,122094 , and especially not the official tool. (At reply #18 I discovered the fast-verify feature.)
For decoding through errors there are two needs which would probably warrant separate options:
1) For playback, where user likely wants damaging signals to be muted and the playback to pick up again. IDK how long block sizes you use in every mode - Insane could apparently employ > 20 seconds, and I guess a user may want playback to resume fast, like the needle jumping on a vinyl record and past a few seconds; but for short block sizes (like a tenth of a second) the least disturbing is probably to keep the timing and interpolate.
2) For salvaging as much audio as possible first and inspect manually afterwards, where the user probably is willing to accept static bursts and even have several seconds unlistenable as long as it picks up ASAP and at the right playback time. I have no idea how the Monkey's algorithm works - if "broken mid-block" means half the block will appear OK if you try to force playback, or how easy it is to parse the bit stream after an error and pin down where the next block starts.

Then on the other hand ... let's be frank, most "a few bytes wrong" files are likely incomplete py-r8ed downloads, and those are maybe not every dev's top priority.

Another is that, likely due to being developed on CDDA like everything else: Monkey's is sometimes fooled especially by high resolution into making bigger files in higher modes. And there is not much extra effort in trying the preceding mode as well, so a checkbox to try that and keeping the smaller file may be worth it.
Alternatively that could be an option only when the user tries to recompress an .ape. Presumably, if the user tries to convert a Normal into a High, that is for the sake of size, so why not keep any smaller Normal? You can put checkboxes in the GUI like
"[_] Require 0.x % size improvement to accept higher mode compression." [arrow to bump x up/down 0 to 9]
"[_] Always try lower mode"