IPB

Welcome Guest ( Log In | Register )

2 Pages V   1 2 >  
Reply to this topicStart new topic
New portable Musepack decoder library, including fixed-point mode
Peter
post May 19 2004, 16:40
Post #1


foobar2000 developer


Group: Admin
Posts: 3275
Joined: 30-September 01
Member No.: 84



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)
Attached File  mpcdec.zip ( 45.56K ) Number of downloads: 1880
 
Go to the top of the page
+Quote Post
jarsonic
post May 19 2004, 17:08
Post #2





Group: Members
Posts: 199
Joined: 30-September 01
From: C-ville, VA
Member No.: 83



sweet, Peter!

Should make it easier for (potential future) adoption and incorporation into devices, etc.
Go to the top of the page
+Quote Post
caligae
post May 19 2004, 18:11
Post #3





Group: Members
Posts: 186
Joined: 23-January 02
Member No.: 1132



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.
Go to the top of the page
+Quote Post
Peter
post May 19 2004, 18:24
Post #4


foobar2000 developer


Group: Admin
Posts: 3275
Joined: 30-September 01
Member No.: 84



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.
Go to the top of the page
+Quote Post
Gecko
post May 19 2004, 18:29
Post #5





Group: Members
Posts: 937
Joined: 15-December 01
From: Germany
Member No.: 662



Ah! Thx, Peter!

Someone should show this to the iPod Linux guys.
Go to the top of the page
+Quote Post
dev0
post May 19 2004, 18:33
Post #6





Group: Developer
Posts: 1679
Joined: 23-December 01
From: Germany
Member No.: 731



Already happened apparently:

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


--------------------
"To understand me, you'll have to swallow a world." Or maybe your words.
Go to the top of the page
+Quote Post
xmixahlx
post May 19 2004, 19:44
Post #7





Group: Members
Posts: 1394
Joined: 20-December 01
From: seattle
Member No.: 693



QUOTE (caligae @ May 19 2004, 09:11 AM)
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 smile.gif )

thanx for the effort, peter.


later

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


--------------------
RareWares/Debian :: http://www.rarewares.org/debian.html
Go to the top of the page
+Quote Post
ak
post May 19 2004, 20:53
Post #8


Musepack Developer


Group: Members
Posts: 359
Joined: 17-October 01
Member No.: 309



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
Go to the top of the page
+Quote Post
soellman
post May 19 2004, 22:45
Post #9





Group: Members
Posts: 1
Joined: 19-May 04
Member No.: 14194



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

thanks guys.. looking forward to seeing mpc on my ipod, this is the first big step.
Go to the top of the page
+Quote Post
Tec9SD
post May 19 2004, 23:07
Post #10





Group: Members
Posts: 188
Joined: 21-June 03
From: S. East, U.S.
Member No.: 7317



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
Go to the top of the page
+Quote Post
atici
post May 19 2004, 23:45
Post #11





Group: Members (Donating)
Posts: 1180
Joined: 21-February 02
From: Chicago
Member No.: 1367



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.


--------------------
The object of mankind lies in its highest individuals.
One must have chaos in oneself to be able to give birth to a dancing star.
Go to the top of the page
+Quote Post
rjamorim
post May 20 2004, 00:11
Post #12


Rarewares admin


Group: Members
Posts: 7515
Joined: 30-September 01
From: Brazil
Member No.: 81



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?


--------------------
Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:
http://www.rarewares.org
Go to the top of the page
+Quote Post
Peter
post May 20 2004, 00:23
Post #13


foobar2000 developer


Group: Admin
Posts: 3275
Joined: 30-September 01
Member No.: 84



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).
Go to the top of the page
+Quote Post
TrNSZ
post May 20 2004, 00:39
Post #14





Group: Developer
Posts: 717
Joined: 25-September 01
From: ... The Studio
Member No.: 20



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.
Go to the top of the page
+Quote Post
BetaBoy
post May 20 2004, 01:39
Post #15


Founder CoreCodec


Group: Developer
Posts: 32
Joined: 2-January 02
From: New Jersey
Member No.: 887



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.


--------------------
Dan "BetaBoy" Marlin
Founder CoreCodec
The Future of Audio/Video Development and Technology
Go to the top of the page
+Quote Post
caligae
post May 20 2004, 08:56
Post #16





Group: Members
Posts: 186
Joined: 23-January 02
Member No.: 1132



QUOTE (TrNSZ @ May 20 2004, 01:39 AM)
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.
Go to the top of the page
+Quote Post
Althalus
post May 20 2004, 09:31
Post #17





Group: Members
Posts: 147
Joined: 14-December 01
Member No.: 647



Thank you zZzZzZz.
Go to the top of the page
+Quote Post
Slo Mo Snail
post May 20 2004, 09:58
Post #18





Group: Members
Posts: 111
Joined: 2-July 02
From: Germany
Member No.: 2450



QUOTE (TrNSZ @ May 20 2004, 01:39 AM)
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?! wink.gif )
Maybe it's a good idea to rename the makefile to Makefile rolleyes.gif

Other than that it works perfectly on Linux x86 and Linux x86-64
Go to the top of the page
+Quote Post
caligae
post May 20 2004, 10:30
Post #19





Group: Members
Posts: 186
Joined: 23-January 02
Member No.: 1132



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
Go to the top of the page
+Quote Post
picard
post Jun 30 2004, 10:08
Post #20





Group: Members
Posts: 8
Joined: 30-June 04
From: Budapest
Member No.: 14987



thank zZzZzZz!

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

bye, Picard
Go to the top of the page
+Quote Post
Atlantis
post Jun 30 2004, 10:16
Post #21





Group: Members
Posts: 250
Joined: 27-December 02
From: ROMA, Italy
Member No.: 4269



QUOTE (picard @ Jun 30 2004, 11:08 AM)
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!!
smile.gif

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

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


--------------------
Vital papers will demonstrate their vitality by spontaneously moving from where you left them to where you can't find them.
Go to the top of the page
+Quote Post
harad
post Aug 23 2004, 18:06
Post #22





Group: Members
Posts: 2
Joined: 23-August 04
Member No.: 16471



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)

smile.gif

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! smile.gif
Go to the top of the page
+Quote Post
Axon
post Aug 23 2004, 18:23
Post #23





Group: Members (Donating)
Posts: 1984
Joined: 4-January 04
From: Austin, TX
Member No.: 10933



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 smile.gif
Go to the top of the page
+Quote Post
Peter
post Aug 23 2004, 18:48
Post #24


foobar2000 developer


Group: Admin
Posts: 3275
Joined: 30-September 01
Member No.: 84



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.
Go to the top of the page
+Quote Post
harad
post Aug 24 2004, 16:41
Post #25





Group: Members
Posts: 2
Joined: 23-August 04
Member No.: 16471



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.
Go to the top of the page
+Quote Post

2 Pages V   1 2 >
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 28th August 2014 - 01:05