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 Codec non-win32 problem (Read 9214 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Monkey's Audio Codec non-win32 problem

As precompiled RareWares are not available for Linux ppc I download mac-port 3.99-u4-b4 sources. The first issue is that after running .configure I get the following warning although nasm is installed:
Code: [Select]
1: No NASM found, you need NASM to compile the asm source in *x86* arch.

Anyway I compile and install and get no errors. However I downloaded from P2P some music in APE+CUE format. I suppose that having Nero and Monkey's Audio on Windows it will be posible to create an audio CD directly. Running Linux I try to convert the bundled CDImage.ape into a WAV file.
Code: [Select]
$ mac CDImage.ape CDImage.wav -d

I get no errors. But the resulting CDImage.wav is not usable by cdrecord and not usable by shnsplit either. And if I try to process it using sox I get:
Code: [Select]
$ sox test.wav -r 44100 -c 2 -s -w CDImage.wav
sox: Failed reading test.wav: WAV file has unknown format type of 100

I suspected an endianess problem but adding -x to sox doesn't change anything.

Googling I've not found a convincing answer, any ideas? Will I need to forget my lovely Apple G3 and get a PC only to be able to play APE files?

Monkey's Audio Codec non-win32 problem

Reply #1 –
It would certainly appear to be an endian issue.  I have no idea what the port consists of, but the standard code does not appear to be endian safe. Have you tried compressing and decompressing a wave file of your own?

Monkey's Audio Codec non-win32 problem

Reply #2 –
Quote
It would certainly appear to be an endian issue.  I have no idea what the port consists of, but the standard code does not appear to be endian safe. Have you tried compressing and decompressing a wave file of your own?
[a href="index.php?act=findpost&pid=373393"][{POST_SNAPBACK}][/a]


Code: [Select]
ismael@donkee ~ $ mac Test.wav Test.ape -c2000
--- Monkey's Audio Console Front End (v 3.99) (c) Matthew T. Ashland ---
Compressing (normal)...
Progress: 100.0% (0.0 seconds remaining, 2.6 seconds total)          
Success...
ismael@donkee ~ $ mac Test.ape Test_deco.wav -d
--- Monkey's Audio Console Front End (v 3.99) (c) Matthew T. Ashland ---
Decompressing...
Progress: 100.0% (0.0 seconds remaining, 2.5 seconds total)          
Success...
ismael@donkee ~ $ aplay Test_deco.wav 
Playing WAVE 'Test_deco.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo

ismael@donkee ~ $ sox Test_deco.wav -r 44100 -c 2 -s -w Test_deco2.wav
ismael@donkee ~ $ aplay Test_deco2.wav 
Playing WAVE 'Test_deco2.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo


So this test is OK. Does this confirm the endian issue? Should I assume that I will be unable to decompress properly APE files compressed on win32?

Monkey's Audio Codec non-win32 problem

Reply #3 –
Quote
So this test is OK. Does this confirm the endian issue? Should I assume that I will be unable to decompress properly APE files compressed on win32?
[a href="index.php?act=findpost&pid=373398"][{POST_SNAPBACK}][/a]

It would seem to confirm it, yes. Where did you obtain the port from? It looks like it should be simple enough to correct.

Monkey's Audio Codec non-win32 problem

Reply #4 –
Quote
It would seem to confirm it, yes. Where did you obtain the port from? It looks like it should be simple enough to correct.
[{POST_SNAPBACK}][/a]

Taking a guess I guess he got it from [a href="http://sourceforge.net/projects/mac-port/]here[/url].
"ONLY THOSE WHO ATTEMPT THE IMPOSSIBLE WILL ACHIEVE THE ABSURD"
        - Oceania Association of Autonomous Astronauts

Monkey's Audio Codec non-win32 problem

Reply #5 –
Quote
Quote
It would seem to confirm it, yes. Where did you obtain the port from? It looks like it should be simple enough to correct.
[{POST_SNAPBACK}][/a]

Taking a guess I guess he got it from [a href="http://sourceforge.net/projects/mac-port/]here[/url].
[a href="index.php?act=findpost&pid=373423"][{POST_SNAPBACK}][/a]


Yes! Any suggestion on how to debug the problem?

Monkey's Audio Codec non-win32 problem

Reply #6 –
In 'config.h' in the src/Shared folder, find the following:
Code: [Select]
/* Define to 1 if your processor stores words with the most significant byte
   first (like Motorola and SPARC, unlike Intel and VAX). */
/* #undef WORDS_BIGENDIAN */

add:
Code: [Select]
#define WORDS_BIGENDIAN 1
, recompile and you should be OK, I think!!

Monkey's Audio Codec non-win32 problem

Reply #7 –
Quote
Quote
It would seem to confirm it, yes. Where did you obtain the port from? It looks like it should be simple enough to correct.
[{POST_SNAPBACK}][/a]

Taking a guess I guess he got it from [a href="http://sourceforge.net/projects/mac-port/]here[/url].
[a href="index.php?act=findpost&pid=373423"][{POST_SNAPBACK}][/a]

Thanks.

Monkey's Audio Codec non-win32 problem

Reply #8 –
I also initially ran across similar problems to those you are describing- the MAC APIs expect little-endian format data (versus what most other encoders expect, which is host-endian) which gave me headaches at first.  To really "fix" the problem for OS X, config.h should say:

Code: [Select]
#if __BIG_ENDIAN__
#define WORDS_BIGENDIAN 1
#else
#undef WORDS_BIGENDIAN
#endif


because this will let MAC compile correctly on Intel Macs as well.  FWIW...

If you prefer GUIs to command-line, the svn version of Max (http://sbooth.org/Max/) supports ripping and converting to/from Monkey's Audio on OS X.  I'm planning to release a version with this support in the next week or so, but before that if you can't compile Max yourself I could send out a beta with this functionality. E-mail me if interested!

Monkey's Audio Codec non-win32 problem

Reply #9 –
Quote
I also initially ran across similar problems to those you are describing- the MAC APIs expect little-endian format data (versus what most other encoders expect, which is host-endian) which gave me headaches at first.  To really "fix" the problem for OS X, config.h should say:

Code: [Select]
#if __BIG_ENDIAN__
#define WORDS_BIGENDIAN 1
#else
#undef WORDS_BIGENDIAN
#endif


because this will let MAC compile correctly on Intel Macs as well.  FWIW...

If you prefer GUIs to command-line, the svn version of Max (http://sbooth.org/Max/) supports ripping and converting to/from Monkey's Audio on OS X.  I'm planning to release a version with this support in the next week or so, but before that if you can't compile Max yourself I could send out a beta with this functionality. E-mail me if interested!
[a href="index.php?act=findpost&pid=373587"][{POST_SNAPBACK}][/a]

Thanks.  A much better fix. I plead (Apple)MAC ignorance in defence.

Monkey's Audio Codec non-win32 problem

Reply #10 –
Quote
If you prefer GUIs to command-line, the svn version of Max (http://sbooth.org/Max/) supports ripping and converting to/from Monkey's Audio on OS X.  I'm planning to release a version with this support in the next week or so, but before that if you can't compile Max yourself I could send out a beta with this functionality. E-mail me if interested!
[a href="index.php?act=findpost&pid=373587"][{POST_SNAPBACK}][/a]


(Un)fortunately I am not using OS X but Debian sid instead, so I can't give a try to Max unless installing maconlinux (a different headache

As endianness is not operating system dependant I'll give a try to your suggested patch nevertheless.

Monkey's Audio Codec non-win32 problem

Reply #11 –
Quote
Code: [Select]
#define WORDS_BIGENDIAN 1

[a href="index.php?act=findpost&pid=373439"][{POST_SNAPBACK}][/a]


It's defined like this... This file is created by ./configure and gets endianness according to the machine configure script is running in.

I tend to discard an endianness problem right now...

Monkey's Audio Codec non-win32 problem

Reply #12 –
Quote
It's defined like this... This file is created by ./configure and gets endianness according to the machine configure script is running in.

I tend to discard an endianness problem right now...
[a href="index.php?act=findpost&pid=373915"][{POST_SNAPBACK}][/a]

Sorry, in that case I'm out of ideas. The format indicated in your first post of '100' is an endian issue as it should be '1'.

Monkey's Audio Codec non-win32 problem

Reply #13 –
Using qemu I'm using Debian x86 as a guest in my Debian ppc host. From there I've added RareWares to the guest repository and installed monkeys-audio, cuetools and shntool. Then simply:

Code: [Select]
$ cuebreakpoints CDImage.cue | shntool split CDImage.ape


Splits the cuefile into usable wav files. Low as hell of course. Sure I could then simply mac the .ape file into a big .wav one and burn a CD in DAO mode.

So it's time to file a bug report to mac-port I guess.
 

Monkey's Audio Codec non-win32 problem

Reply #15 –
Quote
Everything's working now, thanks everybody!
[a href="index.php?act=findpost&pid=374225"][{POST_SNAPBACK}][/a]

Glad you got a result.

Monkey's Audio Codec non-win32 problem

Reply #16 –
Quote from: Mr_Rabid_Teddybear on
Taking a guess I guess he got it from here.


Maybe...
Anyways, just a quick note to let you all know that those pages were gone for a couple of months, but they are back at the exact same location(s):

http://sourceforge.net/projects/mac-port/
http://mac-port.sourceforge.net/

I re-uploaded everything, all the last versions, and re-created a website. I tried to reach any of the previous developers and maintainers, but without success. If you have any questions or comments, feel free to get back to me via [ wegmethaat@yahoo.com ]. I've been using (GNU/)Linux for over 10 years and know how to apply patches, code C/C++, and so on, so if you have any code you want added or changed, do not be fearful and let me know about it. ;-)