UPDATE: source posted here is outdated now, newer version is hosted on musepack.net (http://www.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.
sweet, Peter!
Should make it easier for (potential future) adoption and incorporation into devices, etc.
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.
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.
Ah! Thx, Peter!
Someone should show this to the iPod Linux guys.
Already happened apparently:
http://ipodlinux.sourceforge.net/forums/vi...c.php?p=660#660 (http://ipodlinux.sourceforge.net/forums/viewtopic.php?p=660#660)
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
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 (http://cvs.sourceforge.net/viewcvs.py/*checkout*/mingw/utils/scripts/dsw2mak.in?rev=1.8)
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.
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
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 (http://www.pocket-tunes.com/) player developers for plug-in support. Check the details here (http://www.math.columbia.edu/~atici/pocketmpc.txt). Maybe we can get it work on PalmOS soon too.
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?
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).
[deleted]
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.
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.
Thank you zZzZzZz.
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
Doesn't work on Alpha.
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.
thank zZzZzZz!
i added this library to BetaPlayer (PocketPC media player). in the next version it will support mpc files too.
bye, Picard
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!
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:
#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!
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
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.
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.
Hello!
Is there any way to get the bits per sample (BPS) from the MusePack file?
Regards,
Sebastian Andersson
Why would you want to know the BPS of the source file?
Hello!
Is there any way to get the bits per sample (BPS) from the MusePack file?
Regards,
Sebastian Andersson
[a href="index.php?act=findpost&pid=237698"][{POST_SNAPBACK}][/a]
In this case, I need it for a function used by a BASS add-on (www.un4seen.com). But other reasons could be, to fill up the WAVEFORMAT structure with the proper information or whatever.
Why would the decoder care at all what the input resolution is, it doesn't matter at all for it?
It can choose freely whatever resolution or format it wants to decode to, there is no relation needed to whatever the input was.
This quote was related to AAC decoding but the same is true for MPC.
OK
So, is it possible or not?
Great news, thanks Mr Peter!
I wonder there is no matter if I send a link to this thread to Rockbox team? Cause it could interest their iriverport project...
Best regards,
Tang
PS: thanks also for foobar, even if it's a little off topic: i like your player
EDIT: i've just understood how the Rockbox WiKi was working... So i added directly the useful links/info in the Wiki: http://www.rockbox.org/twiki/bin/view/Main...Writing_CODEC_s (http://www.rockbox.org/twiki/bin/view/Main/IriverPort#Writing_CODEC_s)
feel free to correct if there is something wrong (will need registering thought)
Pre edited post:
Just to say i've submited a link to this thread and the library itself on the rockbox board (for iriverport)...
here is the link:
http://forums.rockbox.org/index.php?topic=103.0 (http://forums.rockbox.org/index.php?topic=103.0)
Let's see if the Rockbox team will consider this...
Best regards
I've just finished a first rough port of this library to pure C, instead of C++, since a lot of people refuse to include C++ code in their apps.
It's currently available in a darcs repository at http://www.caddr.com/code/libmusepack/ (http://www.caddr.com/code/libmusepack/)
I've started adding some documentation too, which can be found here:
http://www.caddr.com/code/libmusepack/docs/html/ (http://www.caddr.com/code/libmusepack/docs/html/)
I'd welcome any comments or suggestions. If you know of any project devs that would be interested in supporting musepack but have held off because of the C++ issue please let me know.
Thanks for the original work of putting this library together.
I updated the old library in BetaPlayer's MPC plugin to libmusepack 1.03. But I had to put back SeekTable[] for faster seeking. Was there a reason why this was removed from libmusepack?
I updated the old library in BetaPlayer's MPC plugin to libmusepack 1.03. But I had to put back SeekTable[] for faster seeking. Was there a reason why this was removed from libmusepack?
[a href="index.php?act=findpost&pid=259689"][{POST_SNAPBACK}][/a]
You're talking about the C++ version, right? I don't think there was such a thing in the 1.0.3 version I started with.
I updated the old library in BetaPlayer's MPC plugin to libmusepack 1.03. But I had to put back SeekTable[] for faster seeking. Was there a reason why this was removed from libmusepack?
[a href="index.php?act=findpost&pid=259689"][{POST_SNAPBACK}][/a]
It was removed because it was broken and could produce artifacts.
Yes, I'am using the C++ version and the SeekTable was in the old version (before it was renamed to libmusepack I think).
Any more info in which case does it cause artifacts? More states should be saved not just frame length to be able to properly seek? Because for a mediaplayer the current non SeekTable solution is not really acceptable.
I've just finished a first rough port of this library to pure C, instead of C++, since a lot of people refuse to include C++ code in their apps.
It's currently available in a darcs repository at http://www.caddr.com/code/libmusepack/ (http://www.caddr.com/code/libmusepack/)
I've started adding some documentation too, which can be found here:
http://www.caddr.com/code/libmusepack/docs/html/ (http://www.caddr.com/code/libmusepack/docs/html/)
I'd welcome any comments or suggestions. If you know of any project devs that would be interested in supporting musepack but have held off because of the C++ issue please let me know.
Thanks for the original work of putting this library together.
[a href="index.php?act=findpost&pid=259256"][{POST_SNAPBACK}][/a]
Hi Kuniklo,
Very nice indeed... I do know the Rockbox firmware is written in C... I guess they would be interested for their iRiverport...
I'm gonna notify the team and give them your link... Maybe editing the WIki over there with your link too...
Regards,
Tanguy
Some files have huge frame dependencies. There's no way to know how much, so the fast seeking can break on any file randomly. So although it can be made to seek correctly on most of the files, it's not error-proof.
The codec section of the Rockbox iRiverport wiki is updated:
http://www.rockbox.org/twiki/bin/view/Main/SoundCodecs (http://www.rockbox.org/twiki/bin/view/Main/SoundCodecs)
You can subscrbe to help in the API section:
http://www.rockbox.org/twiki/bin/view/Main...posal#CODEC_API (http://www.rockbox.org/twiki/bin/view/Main/RockboxAudioAPIProposal#CODEC_API)
Cheers!
Tang
someone on teh MDT should submit info for the "Encoder" table section...
someone on teh MDT should submit info for the "Encoder" table section...
[a href="index.php?act=findpost&pid=273499"][{POST_SNAPBACK}][/a]
??? Sorry what's MDT?
Thanks
someone on teh MDT should submit info for the "Encoder" table section...
[a href="index.php?act=findpost&pid=273499"][{POST_SNAPBACK}][/a]
??? Sorry what's MDT?
Thanks
[a href="index.php?act=findpost&pid=273502"][{POST_SNAPBACK}][/a]
It's the
Musepack
Development
Team
Thanks Ganymed...