Slashdot Mirror


New MPC Decoding Library And Updated Homepage

Dcoder writes "The MPC codec has finally completed its transition to the open source world by making Musepack.net its new official home, featuring a complete collection of tools, plug-ins and codec binaries (Linux, Win32 and Mac OS X) and the sourcecode to the complete SV7-1.15r codec source. Additionally, Peter Pawlowski has recently completed his work on an LGPL-licensed portable mpcdec library, which comes with floating and fixed-point math modes and performs at around 10x realtime on a Intel XScale 400Mhz and is even fast enough to bring MPC decoding to slower ARM chips like the iPod's ARMv4. Musepack's outstanding quality has been proven only recently by a public listening test."

4 of 15 comments (clear)

  1. Re:Excellent. by NotoriousQ · · Score: 3, Informative

    Oh well... I guess I will answr my own question. Should have RTFA'd closely.

    From the site:
    It is based on the MPEG-1 Layer-2 / MP2 algorithms, but has rapidly developed and vastly improved and is now at an advanced stage in which it contains heavily optimized and patentless code.

    I am a bit worried about anything that is MPEG. It sounds like it is impossible to conform to mpeg and not be patent-free.

    Well. The only thing left is for mplayer to add support, if they have not done so already.

    --
    badness 10000
  2. What happens next is up to the vorbis folks. by mcgroarty · · Score: 2, Interesting
    If the bitrate-tuned branches get merged back into the main encoder library, there won't be much reason to go with MPC.

    If MPC default encoder remains superior to the Vorbis default encoder, this could be the beginning of the end.

    The UNIX culture tends to like a single authoritative library for this sort of thing. If you have to use a non-standard library for better Vorbis encoding, it's going to lose interest.

  3. Can this codec be used in an ogg container? by topynate · · Score: 2, Interesting

    So you can have Ogg Musepack files. Would this be useful?

  4. Re:autotools??? by sultanoslack · · Score: 2, Informative

    That's naive at best. Autotools solve a complex problem. They're not exactly elegant at all times (I'm not exactly an m4 cheerleader.), but they're robust enough to handle even very complex build environments and to present basically the same interface to anyone that's regularly building packages from source.

    I've yet to see a system that can compete with them in this regard and I have seen things that tried. The results have either been (a) even uglier and/or (b) not general purpose.

    Take for example the fact that this tarball requires nasm -- it doesn't tell you that until the build fails and then there's no opportunity to tell you what it is and where you can get it. This would be a relatively simple configure check.

    Or what about header and library installation locations? Cross platform library versioning?

    Bah, I'll stop there... This is pretty obviously just a troll...