hi, all, I have ported the Monkey's Audio Codec to linux(and fixed some problems),
the latest is 3.99 update 4. And I also make a native plugin for XMMS. They all work well in my Debian SID box.

here is the change log:


The homepage is http://supermmx.org/linux/mac, which is in Chinese. But due to the network problem, the site can only be connected from China, so if u are not in China, u need a proxy to visit it. Or i can just upload them in the Upload forum(Is it ok with this?)

Any suggestions and feedbacks is appreciated, thanks.

Uploading would be fine.

what kind of files are supported ? I tried with the tar.gz, but it said that "You cannot upload this type of file"... I am new to hydrogenaudio.

Is the source available? I would like to see if I could make it run on OS X.

hey, thanx!

(downloaded your source through chinese proxy and uploaded to your thread in Uploads)

built and tested on debian sid (i.e. packages are waiting for xmms plugin, below)
working good throug cli - no errors so far

the xmms plugin has some win32 specific build errors still
i'll look at it again tonight

...i'm in a hurry atm, but wanted to give you a heads up


later

yes, someone report the bug this morning.. It is my fault, i have
underfined the BUILD_CROSS_PLATFORM, and moved it into
configure.in CXXFLAGS in MAC 3.99 update 4, but the plugin is
still old without considering it.

I have released the XMMS plugin 0.2.1 which fixed this bug.

To avoid duplicated download, u can just uncomment the #define BUILD_CROSS_PLATFORM in Line 7 of /usr/include/mac/All.h,
that should be OK..

thanks for the uploading. I will upload the plugin 0.2.1.

http://www.monkeysaudio.com/cgi-bin/YaBB/Y...;num=1105939694

MAC non-win32 ports now hosted at Sourceforge
« on: Today at 11:28pm » Quote Modify Remove
I have created a project called mac-port in Sourceforge, and upload the package and the plugin for XMMS, which can be found here http://www.sourceforge.net/projects/mac-port/,
so this will be the final site for this project, and i will keep a mirror in my own homepage http://supermmx.org/linux/mac/ (which can't be visisted out of China mainland, what a pity).

The license is LGPL for the mac port itself(but i don't get the permission from Matt) and GPL for the XMMS plugin.

I wish more and more people can help this project to port to many other non-win32 platforms, such as *BSD, OSX etc,.and develop plugins for other media players. Now it only has Linux/i386 support and a XMMS plugin(it seems that there exits a plugin for GStreamer, but is kinda very old).

I talked about this with David a couple of months ago via email, now i make it. Wish everyone enjoy it. Thanks.

BTW, i am also confused about so much ports and plugins, ,
i have no time to review the source from other developers, so, make your own decision for yourself. (But it will be great that only one exists

don't know if you saw my reply on that thread, but how can you release under LGPL/GPL when they are incompatible with the Monkey's Audio license?

Josh

i'm not sure, but the authors concept of "do what you want with it, just don't bother me" approach might be the answer.

several linux projects have held up working code because the author of monkey's audio is unreachable


later

if that's the case then at his whim the author can go after whoever is distributing it for copyright infringement (at least in the US and several other countries). seems better to convince Matt to GPL it than to violate the license. he's not on the MAC forums much but go to the jriver forums (he works there on MJ) where it's more likely to get a response.

Josh

@jcoalson:

yes, i saw your post in Monkey's Audio forum. here is what i thought about the license.

first, it is my fault that apply the LGPL and GPL to the port for Monkey's Audio Code, that is not compatible with the original license. And as for this concern, i mentioned that in my post.

second, when i created the project at sourceforge, at first, i just copied the original license as the project license, but was *rejected* by the sourceforge administrators, which said, the license was not compatible with *open source* definiations. So i chose the closest license LGPL(maybe not the closest, cause i am not a native English speaker, fully understanding these licenses is out of my ability).

what i want to say is that license is not the very first consideration at this time for this port, but a stable and workable tool in other non-win32 platforms is.

I know your intentions are good but according to Matt's license you don't get to decide what the very first consideration at this time is. one email from him to sourceforge and they will take the project down, and he can still legally go after whoever distributes it.

infringing the copyright is probably not the best way to get things going with MAC again.

also, sourceforge is offering a free service to open-source projects. they are paying for it so it makes sense that they set the terms of use. faking the license just so they will host a non-free project is going against that.

Josh

I think people are making a huge deal about this. I simply can't imagine Matt going after people that are doing him the favour of improving and distributing his codec. What would he have to gain, anyway?

Bleh. This even looks like second intentions.

that's just speculation. he's heard many requests to relicense to gpl/lgpl in the past and specifically declined. if people repeatedly asked you to do something, you said no, then they went around you to do it anyway, what would your reaction be?

maybe he doesn't care, maybe he's changed his mind, at least follow his wishes and find out first. ask him on the jriver forum.

Josh

mac-port new release:

ChangeLog:





Enjoy it.

BTW: I accept all the comments about license, what I need is the comment from
the original author Matt. I need only *one* word, Yes and No.

excellent!

will be updated at RW/Debian tonight


later

then ask on the jriver forums where he appears every day:
http://yabb.jriver.com/interact/
Josh

Thanks, I will contact with him ASAP. )

supermmx - is there a reason the mac binary is built static in the Makefile{.am} and not by configure script ? (i.e. --enable-shared, etc.) ?


later

yes, some kinda. I have sent a message to Matt at JRiver forum,
waiting for the reply.

well, anyways...

i've updated RW/Debian to include the new MAC updates - thanx again SuperMMX.

i made a small change to enable the frontend to compile dynamically:
* it is 284k (static) versus 7k (dynamic) !

i removed the static LDFLAG from src/Console/Makefile.am and used --enable-shared with configure


i've tested it out and haven't found any oddities (although it takes forever to play 'Insane' files in xmms on my athlon 900 - but that is to be expected)


later

MAC plugin for Beep Media Player, anyone want it?

you can grab it at the same places, enjoy it.

thanx again

I know some people think Monkey's Audio are open source, and the sources are available, so what's the problem? Well, Matts homebrewn license says that as long as your project doesn't generate any money and you e-mail me for a thumbs up, you can do what you want. Well, when people who run projects on the BSD or some LGPL or GPL license e-mail him or ask on his forums; no reply! No answer.
Hes got a license depending on him and he got no manners to answer his mail...

Well, it's good for WavPack. I made my move.

Well, people tried convincing him several times to switch to another license. GPL, LGPL, BSD, PD... no avail.

Who knows if he is even working on it at all anymore? He doesn't even have time to visit his forums these days, let alone program.

well, the *nix community has support without his help - they will just always be a little shady in the license legality department...


later

new release, mac 3.99 update 4 build 3, this is a bug fix release.



enjoy it.

hi supermmx,

i needed to patch ./configure.in with the following before it would build with the system plugin dir:

and with the bmp plugin i get this error from beep-media-player (stderr/console) when loading a known-good *ape file



later

1) Thank you, will be fixed next release. I am sorry, I didn't test it with system dir and i didn't pay enough attention that BMP is different from XMMS. (

2) only with BMP? is XMMS all right with the same versionof MACLib.
there is a bug in Build 2 i metioned in the last post. when opening
ape files that have no write permission, the error 1002 will occur.

please update to Build 3 and try again.

1) no problem. i bumped EXTRA_VERSION up to 1 (so 0.1.0.1) while packaging

2) yes, only with BMP. the XMMS plugin works correctly. i also moved the test *ape file to my home directory, gave it full permissions, and it still displays this error.

i had packaged 3.99u4 build3 first, so this is correct.


later

hmmmmmm, No problem here..

could you test it with the mac command line ?
and if possible, make a little debug to find out the problem. ,

and what's your verion of GCC(including g++), GLIB?
I only test it under gcc 3.3 and 3.4, glib 2.3.2.

Thanks.

updated version of bmp-mac and xmms-mac





enjoy it.

thanx for this update, SuperMMX

i apologize, i thought i had replied to you last post - anyways, i have been testing gcc4.0-pre from debian experimental, but also tested gcc3.3 and gcc3.4 before posting the problems.


later

so the problem still there ?? it is really weird.....

what's the version BMP? I tested it with BMP in Debian SID, and
the latest CVS, seems no problem too.

does someone else meet the same problem ?

Dear SuperMMX,

just downloaded your lib+xmms plugin, but, as I expected, compilation has a few problems due to my machine architecture (AMD64, with gentoo linux)...

I get the usual warnings about pointer and int getting cast to one another (pointer is 64 bit, while int is 32 on my arch), and this usually leads to segfaults....

Do you know if anyone got the lib and plugin working on 64 bit machines ? In case no one has tried, do you agree if I "touch" your source code in order to get things working (unfortunately with super low priority since I have quite a few other things to do .... unfortunately) ?

thank you

gian

There are some comments in the Monkey's Audio forum about AMD 64 Support. http://www.monkeysaudio.com/smf/index.php?topic=1734.0

Actrually the segfaults are not from these castings, but comes from the assembly sources.

Feel free to modify the source, it is better to make a fine-working patch and
send back to me to be merged in the next release.

Hello, thanks for your efforts on this!
However, when loading the plugin with Beep Media Player version 0.9.7, I get this:



and BMP's window doesn't even show up before the program quits (error 127).

I am running Gentoo linux with gcc 3.4.3 and glibc 2.3.5. I compiled using the standard ./configure --prefix=/usr/local for both mad and bmp-mad.

Removing the plugin removes this problem of course. So there's definitely something wrong.

This is x86 btw, not AMD64.

what about removing the --prefix option?

I have no idea what the cause is...

First off, I'd like to thank you for your work on these plugins! It is greatly appreciated.

Second...I believe I may have found a bug in both the bmp and xmms plugins. They both seem to not be able to load files that have a path containing any Japanese characters. (possibly even all asian characters, but I have no way to test that) What makes me think it is the plugins is that if I copy the ape file to a path that dose not contain japanese characters, *poof* it works

The exact error it gives me in both Beep and XMMS is "Invalid MAC File: "/mnt/usbV/Incoming/Music/(album)(japanese albumname)/(Filename).ape"
where (album)(japanesealbumname) is the english album name followed by the japanese name in whatever kana it should be in, and (filename) is the actual name of the file. If I take that same file and copy it to "/mnt/usbV/Incoming/Music" though, it will play quite happily.

Any ideas? Maybe I'm just doing something wrong here, but it does seem rather odd that flac files contained in "/mnt/usbV/Incoming/Music/(album)(japanese albumname)/(Filename).flac" style will play just fine in XMMS (haven't tried them in Beep) where the ape files won't, unless it is a plugin issue.

Again, thanks for your contributions!

if you are in UTF-8 locale, it is the problem, please see the bug:
http://sourceforge.net/tracker/index.php?f...827&atid=699624

this but will be fixed in next release.

Ah, didn't even think of checking there. I do believe that is the same bug I'm referring to.

Thanks for the response!

trying to install xmms-mac but get this:

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for g++... g++
checking for C++ compiler default output file name... a.out
checking whether the C++ compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for style of include used by make... GNU
checking dependency style of g++... gcc3
checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking dependency style of gcc... gcc3
checking build system type... powerpc-apple-darwin8.1.0
checking host system type... powerpc-apple-darwin8.1.0
checking for a sed that does not truncate output... /usr/bin/sed
checking for egrep... grep -E
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... no
checking for /usr/bin/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -p
checking whether ln -s works... yes
checking how to recognise dependent libraries... pass_all
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking how to run the C++ preprocessor... g++ -E
checking for g77... no
checking for f77... no
checking for xlf... no
checking for frt... no
checking for pgf77... no
checking for fort77... no
checking for fl32... no
checking for af77... no
checking for f90... no
checking for xlf90... no
checking for pgf90... no
checking for epcf90... no
checking for f95... no
checking for fort... no
checking for xlf95... no
checking for ifc... no
checking for efc... no
checking for pgf95... no
checking for lf95... no
checking for gfortran... no
checking whether we are using the GNU Fortran 77 compiler... no
checking whether accepts -g... no
checking the maximum length of command line arguments... 65536
checking command to parse /usr/bin/nm -p output from gcc object... ok
checking for objdir... .libs
checking for ar... ar
checking for ranlib... ranlib
checking for strip... strip
checking if gcc static flag works... yes
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fno-common
checking if gcc PIC flag -fno-common works... yes
checking if gcc supports -c -o file.o... yes
checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... darwin8.1.0 dyld
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
configure: creating libtool
appending configuration tag "CXX" to libtool
checking for ld used by g++... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... no
checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes
checking for g++ option to produce PIC... -fno-common
checking if g++ PIC flag -fno-common works... yes
checking if g++ supports -c -o file.o... yes
checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... darwin8.1.0 dyld
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
appending configuration tag "F77" to libtool
checking whether make sets $(MAKE)... (cached) yes
checking for glib-config... /sw/bin/glib-config
checking for GLIB - version >= 1.2.2... yes
checking for xmms-config... /sw/bin/xmms-config
checking for gawk... (cached) gawk
checking for XMMS - version >= 1.2.4... yes
checking wchar.h usability... yes
checking wchar.h presence... yes
checking for wchar.h... yes
checking mac/config.h usability... no
checking mac/config.h presence... no
checking for mac/config.h... no
configure: error: *** MAC lib headers not installed - please install first ***


sorry if i'm screwing up, i'm new.

You need to compile & install MAC first. That will put the headers in the right place(s). I could be wrong of course, but give it a try

do you know where could i find "MAC"?

http://sourceforge.net/projects/mac-port/
or
http://supermmx.org/linux/mac/

currently the main site http://supermmx.org is unavailable, and will last a couple of months,
I am sorry about that. If possible, i will still update the SourceForge site.

mac-port update 4 build 4 released:



Since 3.99 update 4 build 4, mac-port has support for big endian platforms,
and has been tested in MAC OSX 10.4, Linux PowerPC and SunOS Sparc,
but need more tests in more OSes and more Platforms.

Please report your bug in SourceForge and add your comments here.

Enjoy it.

does this mean it no longer supports formats < 3.99? i.e. 3.97?


later

There is a backward compatibility macro definition in the source,

IIRC, it applies to 3.95, (i can't remember that.... sorry, and i am at work now, can't take a look at the source).

ok, just clairifying what you were referring to


later