New portable Musepack decoder library, including fixed-point mode Options

[Peter]

UPDATE: source posted here is outdated now, newer version is hosted on musepack.net.

Full C++ source in post attachement.

License: LGPL.

Features:
- Switchable fixed-point and floating-point modes - enable/disable "#define MPC_FIXED_POINT" in mpc_math.h
- Endian-safe, verified running correctly on big-endian machines
- Multiinstance and multithread safe
- File access callbacks
- No assembly code used, for full portability

Verified correctly compiling/running under:
- win32 / x86 / MSVC6 + SP5 + processor pack - very fast floating-point mode (goes above 200x on ~2GHz machines), fixed-point mode is significantly slower (~60x)
- win32 / x86 / MSVC7.1 - slightly faster than MSVC6, fixed-point mode still relatively slow
- win32 / x86 / DMCPP - fixed-point mode faster than MSVC, floating-point mode slower than expected with strange slowdowns when compiled with speed optimizations enabled
- wince / ARM (32bit) / eVC4 + SP3 - fixed-point decoding speed on 400MHz XScale CPU is about 10x realtime
- Darwin 7.3.0, MacOS X 10.3.3 / PowerPC970/G5 / GCC 3.3 - about 80x-100x decoding speed in both modes on 2GHz G5, thanks to TrNSZ for testing/feedback

I'm planning to put this in official MPC CVS, unfortunately I can't do that right now because corecodec server has been down for serveral days.

Attached File(s)

 mpcdec.zip ( 45.56K ) Number of downloads: 1804

 

[jarsonic]

sweet, Peter!

Should make it easier for (potential future) adoption and incorporation into devices, etc.

[caligae]

Not very portable at the moment though.

No Makefile provided and the filenames are inconsistent (regarding upper/lowercase) which makes it fail on pretty much every platform except Windows.

[Peter]

Package updated with stdafx.cpp/.h names changed to lowercase.
I don't know how this "problem" relates to portability as someone not smart enough to solve this "problem" shouldn't be trying to compile it first as they won't be able to do anything useful with it anyway.

[Gecko]

Ah! Thx, Peter!

Someone should show this to the iPod Linux guys.

[dev0]

Already happened apparently:

http://ipodlinux.sourceforge.net/forums/vi...c.php?p=660#660

[xmixahlx]

Not very portable at the moment though.

No Makefile provided and the filenames are inconsistent (regarding upper/lowercase) which makes it fail on pretty much every platform except Windows.

what would be wrong with "ls *.cpp > Makefile" as a start? that wouldn't require much additional editing...
(or even no Makefile, and "CFLAGS='-02' g++ `ls *cpp` -o mpcdec"


ANYWAYS, verified to be working on gnu/linux using g++-3.3 on debian sid... so i'm sure you could expand that...

(just needed to "dos2unix *" the source - and rm mpcdec* to get rid of the pesky windows stuf )

thanx for the effort, peter.


later

This post has been edited by xmixahlx: May 19 2004, 20:22

[ak]

Well, dsw2mak can be utilized for converting .dsw/.dsp to Makefile, here fi: http://cvs.sourceforge.net/viewcvs.py/*che...2mak.in?rev=1.8

[soellman]

i can verify that it works on mac osx 10.3.3.. now how about the xmms plugin?

thanks guys.. looking forward to seeing mpc on my ipod, this is the first big step.

[Tec9SD]

Wow, Peter!
I'm thoroughly impressed!
I know this will make many people happy.
I was just looking to see if VLC supported MPC decoding (for Mac) to help Cerebus get his efforts finalised and attain official SlimServer support.
I'm sure this will help.

Thanks for your work, tec

[atici]

That's great news indeed. We've had enough of "MPC has slim chance of portable support" argument already. This demonstrates once again that if it doesn't have support it's because the platforms are not open enough to let us code support which is not MPC developers' fault.

I was recently in contact with the pocket-tunes player developers for plug-in support. Check the details here. Maybe we can get it work on PalmOS soon too.

[rjamorim]

Is the integer part based on c.b.2000's integer code, that is hosted on RW and the corecodec server?

In this case, have compliancy tests and accuracy tests been run on it?

[Peter]

Fixed-point mode has been added from scratch and is not based on c.b.2000's code - I saw his code, was not impressed by the nonportable mess he made and pointless GPL code ripoff; that's why I ended making my own fixed-point decoder instead - I originally used a C++ class with operator overloads to wrap math operations, but later it turned out that MSVC compiler's inlining seriously underperforms so I changed it to macros for almost 2x speedup.
As far as I tested, 16bit output from fixed/float modes differs only by last bit (different rounding).

[TrNSZ]

I have now tested this code on PPC970, SPARC64, MIPS, and VAX with complete success, in case anyone cares, and was also able do a DOS compile which was tested on REAL/32.

To whomever said the code was non-portable really needs to look into things, I had zero problems with this code on the myriad of CPU and OS combinations I tested. Most modern compilers will ignore the PC-style new lines, but on a Un*x system that doesn't you can use dos2unix(1), sed 's/^M$//', awk '{sub(/\r$/,"");print}', tr -d '\r', or any of the hundreds of other ways to convert line ends (perl, egrep, ex, etc.) If you don't have this most basic of basic knowledge, you have no business looking at porting code anyway.

The code compiles easily on GCC and also IBM, SGI, and Sun compilers without any Makefile necessary and that would only serve to add unnecessary complexity. I had no problems with the case on any architecture I tried and never had any failures so I have no idea what that guy is even talking about. I did not test any PC/Windows environment as I don't have access to those systems.

The good news is that the code only takes a couple minutes to compile, even with optimizations enabled on a slow VAX that can not dream of decoding in real-time.

[BetaBoy]

zZzZzZz.... On CoreCodec.org.... we were in the middle of our new GForge upgrade when it looks like we had a system failure on our dedicated server.... all of the info seems to fine at this point but it will be a few days more before it will be backup. We are gonna work on a redundent (2PS, raid1+5) 2U rack to go live soon at our ISP.

If all goes well CoreCodec.org should be up by Friday.

[caligae]

To whomever said the code was non-portable really needs to look into things, I had zero problems with this code on the myriad of CPU and OS combinations I tested.  Most modern compilers will ignore the PC-style new lines, but on a Un*x system that doesn't you can use dos2unix(1), sed 's/^M$//', awk '{sub(/\r$/,"");print}', tr -d '\r', or any of the hundreds of other ways to convert line ends (perl, egrep, ex, etc.)  If you don't have this most basic of basic knowledge, you have no business looking at porting code anyway.

I did not say that I'm not able to fix it - this is pretty trivial.

It isn't that bad for a small project like this but imagine a project with hundreds or thousands of includes that are all inconsistent. Of course it's no problem to use sed to repair this but you probably have to adopt your scripts/patches with every release.

It's similar with the Makefile. It's a trivial case here. But in larger projects it would take quite some time to make it.

Now imagine that people actually want to use the library. There would be quite some different packages whose maintainers all have to do the things above seperately which would be quite a waste of time.

I hope you can now understand why I wanted this fixed in the original source instead of everyone applying their fixes.

[Althalus]

Thank you zZzZzZz.

[Slo Mo Snail]

The code compiles easily on GCC and also IBM, SGI, and Sun compilers without any Makefile necessary and that would only serve to add unnecessary complexity.

Hm... if it's not too early in the morning and I'm dreaming there IS a Makefile... it's just named makefile (i.e. with all letters underscore) which isn't recognized by make... make -f makefile for example does work and one has one floating point binary and one other (fixed point I think?! )
Maybe it's a good idea to rename the makefile to Makefile

Other than that it works perfectly on Linux x86 and Linux x86-64

[caligae]

Doesn't work on Alpha.

CODE

Program received signal SIGSEGV, Segmentation fault.
0x1200042e0 in MPC_decoder::decode_internal(float*) (this=0x11fcc5b8, buffer=0x11ffa3c8) at mpc_dec.cpp:53
53              SeekTable [DecodedFrames] = 20 + FwdJumpInfo;       // ...
(gdb) bt
#0  0x1200042e0 in MPC_decoder::decode_internal(float*) (this=0x11fcc5b8, buffer=0x11ffa3c8) at mpc_dec.cpp:53
#1  0x1200042b4 in MPC_decoder::decode_internal(float*) (this=0x8, buffer=0x11fcc5b8) at mpc_dec.cpp:52
#2  0x1200042b4 in MPC_decoder::decode_internal(float*) (this=0x8, buffer=0x11fcc5b8) at mpc_dec.cpp:52
#3  0x1200042b4 in MPC_decoder::decode_internal(float*) (this=0x11ffa3c8, buffer=0x11fcc5b8) at mpc_dec.cpp:52
#4  0x1200042b4 in MPC_decoder::decode_internal(float*) (this=0x11ffa3c8, buffer=0x11ffec18) at mpc_dec.cpp:52
#5  0x1200042b4 in MPC_decoder::decode_internal(float*) (this=0x0, buffer=0x0) at mpc_dec.cpp:52
#6  0x1200042b4 in MPC_decoder::decode_internal(float*) (this=0x34b00, buffer=0x0) at mpc_dec.cpp:52
#7  0x1200042b4 in MPC_decoder::decode_internal(float*) (this=0x5ca06107, buffer=0x100000001) at mpc_dec.cpp:52
#8  0x1200042b4 in MPC_decoder::decode_internal(float*) (this=0x4000a94602d7200, buffer=0x2e31206e6e616d68) at mpc_dec.cpp:52
#9  0x1200042b4 in MPC_decoder::decode_internal(float*) (this=0x2e312e2e2e30392e, buffer=0x0) at mpc_dec.cpp:52
#10 0x1200042b4 in MPC_decoder::decode_internal(float*) (this=0x0, buffer=0x0) at mpc_dec.cpp:52
#11 0x1200042b4 in MPC_decoder::decode_internal(float*) (this=0x0, buffer=0x0) at mpc_dec.cpp:52
#12 0x1200042b4 in MPC_decoder::decode_internal(float*) (this=0x0, buffer=0x0) at mpc_dec.cpp:52
#13 0x1200042b4 in MPC_decoder::decode_internal(float*) (this=0x0, buffer=0x0) at mpc_dec.cpp:52
#14 0x1200042b4 in MPC_decoder::decode_internal(float*) (this=0x34b00, buffer=0x11fcc418) at mpc_dec.cpp:52
#15 0x1200042b4 in MPC_decoder::decode_internal(float*) (this=0xffffffff, buffer=0xffffff00) at mpc_dec.cpp:52
...

This goes on for a while.

edit: The use of (u)int_32t fixes this as expected.

This post has been edited by caligae: May 20 2004, 11:03

[picard]

thank zZzZzZz!

i added this library to BetaPlayer (PocketPC media player). in the next version it will support mpc files too.

bye, Picard

[Atlantis]

thank zZzZzZz!

i added this library to BetaPlayer (PocketPC media player). in the next version it will support mpc files too.

bye, Picard

Now that's good!!


edit:... and, obviously, many thanks to zZzZzZz for providing the library!

This post has been edited by Atlantis: Jun 30 2004, 10:19

[harad]

Using VC++ 3.0 [LOG]:

--------------------Configuration: mpcdec - Win32 (WCE x86) Release--------------------
Compiling...
bitstream.cpp
huffsv46.cpp
huffsv7.cpp
idtag.cpp
mpc_dec.cpp
requant.cpp
StdAfx.cpp
streaminfo.cpp
synth_filter.cpp
Creating library...

mpcdec.lib - 0 error(s), 0 warning(s)



You need to add:

CODE

#ifdef _WIN32_WCE
   # include <windows.h>
   #define assert ASSERT
#else
   # include <assert.h>
#endif

to mpc_dec.h, because PocketPC SDK 2002 doesn't have assert header.

GrEeTz!

[Axon]

Excellent work! But I have a licensing nitpick: the LGPL would require hardware vendors to open up their build systems for their firmware, because users would need to be able to rebuild you library from source themselves and link to the vendors's object modules. This is asking a lot for the vendors to expose, and having some sort of BSD license would lower the bar considerably.

Of course, this is your code and your decision on what to do with it. And of course it's the first release

[Peter]

I personally don't care whatever you do with this code. The license is LGPL because it would violate original MPC decoder license if it was BSD; you can try contacting Frank Klemm about possible license change.

[harad]

i think that someone should merge the mpc decoder code into GSPlayer, because it's the best free player for PocketPC. I don't know this much cpp to do it, but GSPlayer is OpenSource and it's coded simply.

anyway great library.