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: APE command line tool (mac.exe) decoding error since version 7.78 (Read 7582 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

APE command line tool (mac.exe) decoding error since version 7.78

I have quite a number of APE files can only be correctly decoded by mac.exe version 7.76 or earlier. When decoded by newer versions of mac.exe, the decoded .wav files cannot be opened by every software I have (Audacity, Audition, foobar2000...)

Old versions of mac.exe can be downloaded in
https://www.videohelp.com/software/Monkeys-Audio/old-versions

Since I cannot generate these APE files myself and the shortest one I have is in 36 seconds, I am thinking about sending this file to the HA admins/staffs/developers for analysis, and of course @MonkeysAudio

If you are one of them, please PM me.

Re: APE command line tool (mac.exe) decoding error since version 7.78

Reply #1
Maybe this helps: @MonkeysAudio
Music: sounds arranged such that they construct feelings.

Re: APE command line tool (mac.exe) decoding error since version 7.78

Reply #2
Can you mail me one of the files?  I'm mail at monkeysaudio dot com.

I'm sorry about the problem!

Re: APE command line tool (mac.exe) decoding error since version 7.78

Reply #3
PM sent.


Re: APE command line tool (mac.exe) decoding error since version 7.78

Reply #5
Issue fixed, including other files I have.
Thanks!

Re: APE command line tool (mac.exe) decoding error since version 7.78

Reply #6
I'm really sorry for the fumble.  I was removing warnings and for some reason switched the wave format define to a field that was wrong.  It's been kind of a blur lately, but hopefully all good now :)

Re: APE command line tool (mac.exe) decoding error since version 7.78

Reply #7
@MonkeysAudio :
New computer, new executables in (Monkey's 8.92 now, the 64 bit version) - and I have no idea whether this has ever worked different, I don't use .caf, I just got curious about a different endianness issue and found something that is either a Monkey's issue or a fb2k issue, I don't know which.

* Generated (by way of wvunpack) a bigendian.caf and a littleendian.caf
* mac.exe bigendian.caf bigendian.caf.ape -c4000 and mac.exe littleendian.caf littleendian.caf.ape -c4000
* The bigendian.caf.ape is compressed to half size. The littleendian.caf.ape is bigger than the .caf
* The former also plays in foobar2000 v2. The latter plays static. Didn't bother to try old foo_input_monkey as it is older than Monkey's .caf support.
* But: foo_bitcompare against the .wv I generated the .caf from, yields a sample off. So either you or Peter need to fix something. I am not sure who, but you can check better than me what Monkey's does.

* Also, mac.exe bigendian.caf.ape bigendian.caf.ape.caf -d and mac.exe littleendian.caf.ape littleendian.caf.ape.caf -d both yield "Error: 1003". But the GUI does output .caf files.

Re: APE command line tool (mac.exe) decoding error since version 7.78

Reply #8
Thanks for turning me onto that.  Easy to reproduce so I'll try to fix in the coming days.  Thanks again.

Re: APE command line tool (mac.exe) decoding error since version 7.78

Reply #9
Should be fixed here:
https://monkeysaudio.com/download.html

I now compressed a big endian and little endian CAF.  Both got the same compression.  Both played fine.  Both decompressed to be bit-perfect with the original.

If you find anything else still astray, just let me know.

Thanks again.

Re: APE command line tool (mac.exe) decoding error since version 7.78

Reply #10
[Oops, my bad in typing file extensions, disregard.]

Re: APE command line tool (mac.exe) decoding error since version 7.78

Reply #11
will there be mac.exe support stdin?



Re: APE command line tool (mac.exe) decoding error since version 7.78

Reply #14
Seems to work okay in CUETools to me but I only ran a short test. CUEtools will often throw an error the first run (or until slide bar {Mode} setting is written to settings file) after adding a new encoder.



Quote
--- Monkey's Audio Console Front End (v 8.98) (c) Matthew T. Ashland ---
Proper Usage: [EXE] [Input File] [Output File] [Mode]

Modes:
    Compress (fast): '-c1000'
    Compress (normal): '-c2000'
    Compress (high): '-c3000'
    Compress (extra high): '-c4000'
    Compress (insane): '-c5000'

http://cue.tools/wiki/CUETools_Advanced_Settings:_Encoders
Quote
Parameters {textbox}
    Arguments for external encoder executable (Encoding parameters only. Please refer to the encoder's documentation for more info about usage parameters.). The required placeholder arguments used by CUETools for external encoders are:

        "-" : (without the quotes) = stdin (standard input).
        %O : will be replaced by the output file name

    Optional:
        %M : will be replaced by the value from Modes (selected via slider on main screen).
korth

Re: APE command line tool (mac.exe) decoding error since version 7.78

Reply #15
Seems to work okay in CUETools to me but I only ran a short test. CUEtools will often throw an error the first run (or until slide bar
Thanks! It didn't work with older versions. I checked it now. Everything is OK

Re: APE command line tool (mac.exe) decoding error since version 7.78

Reply #16
@MonkeysAudio :
Not that I need this - they were tested (with Monkey's 8.98 and 8.99) just for the sake of testing - but signed 8-bit files aren't treated right. You may want to have a look at the files attached:
* The two AU files: Monkey's processes them, they sound wrong.
* The AIFF & CAF files generated by wvunpack: Monkey's processes them, they sound wrong.
* The other AIFFs are created by AFsp CopyAudio except one by ffmpeg (with -codec copy from .au). Monkey's refuses them all. For the "old AIFF" by CopyAudio it even scream I/O error.

No files "destroyed", the bad sounding are restored bitwise by decompression. Still it would be better to do them right or to reject them all. I can hardly imagine 8-bit audio being The Next Big Thing, and it is telling that you probably haven't gotten any bug report from anyone who actually plays 8-bit files except for testing.
But still, please don't scare potential users with I/O warnings :-o


("sound wrong": played with foobar2000 v2 beta, and with VUPlayer. Not attached: anything related to testing 8-bit .wav and 8-bit .w64 files, they sound just right.)

Re: APE command line tool (mac.exe) decoding error since version 7.78

Reply #17
Thanks for the files!

I definitely don't handle 8-bit signed files.

I'm thinking I should just reject the files.

But I could try converting to and from signed if you think that would be better?

Thanks again.

Re: APE command line tool (mac.exe) decoding error since version 7.78

Reply #18
I started coding conversion and it's pretty easy.  So I'll release that in the next build.

It's version 9 and I almost feel like I should do something clever!  But I'm running out of clever ideas!

Thanks again.

Re: APE command line tool (mac.exe) decoding error since version 7.78

Reply #19
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  https://hydrogenaud.io/index.php/topic,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"
?

Re: APE command line tool (mac.exe) decoding error since version 7.78

Reply #20
Well I released:
https://monkeysaudio.com/download.html

I compressed all your files, decompressed them all, and all of them matched binary identical.  Playback should work fine in everything since the data is converted.

Thanks a lot for your help.

Re: APE command line tool (mac.exe) decoding error since version 7.78

Reply #21
The decode will try to power through errors.  You'll just get a frame of silence.

I quick verify all my files all the time.  I really love that feature of Monkey's Audio.  Change one bit and it knows!

Re: APE command line tool (mac.exe) decoding error since version 7.78

Reply #22
I compressed all your files, decompressed them all, and all of them matched binary identical.  Playback should work fine in everything since the data is converted.
Confirmed in fb2k v2 beta 14 (brand new), VLC 2.2.2 (2016) and a couple of players in between.

Re: APE command line tool (mac.exe) decoding error since version 7.78

Reply #23
@MonkeysAudio :
AIFF trouble still, sowt files are encoded wrong. Try the file https://www.mmsp.ece.mcgill.ca/Documents/AudioFormats/AIFF/Samples/AFsp/M1F1-int16s-AFsp.aif (bottom of first section at https://www.mmsp.ece.mcgill.ca/Documents/AudioFormats/AIFF/Samples.html ).

Because the file size is nearly uncompressed (while the big-endian AIFF & AIFC files compress to about half), I take it that it "must" be Monkey's encoding and not players decoding. (Players tried: updated VLC and fb2k.)

Re: APE command line tool (mac.exe) decoding error since version 7.78

Reply #24
@MonkeysAudio :
AIFF trouble still, sowt files are encoded wrong. Try the file https://www.mmsp.ece.mcgill.ca/Documents/AudioFormats/AIFF/Samples/AFsp/M1F1-int16s-AFsp.aif (bottom of first section at https://www.mmsp.ece.mcgill.ca/Documents/AudioFormats/AIFF/Samples.html ).

Because the file size is nearly uncompressed (while the big-endian AIFF & AIFC files compress to about half), I take it that it "must" be Monkey's encoding and not players decoding. (Players tried: updated VLC and fb2k.)


Thanks for the file.  It looks like it's little endian, and I only handle big endian AIFF.

Do you know are all AIFC files little endian?

Or is there some other way to detect this?

Thanks.