Slashdot Mirror

← Back to Stories (view on slashdot.org)

New MPC Decoding Library And Updated Homepage

Posted by timothy on from the can-you-hear-me-all-compressed dept.

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."

15 comments

  1. Excellent. by NotoriousQ · · Score: 1, Interesting

    But is it patent encumbered?

    --
    badness 10000
    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. No way! by Gadzinka · · Score: 0, Troll

    There's no way I'm gona recode my music again! ;)

    First time I did it in mp3, later in vorbis. So there's no way I'm gonna do it again. Besides, there are vorbis hardware players on the market, which can't be said about MPC.

    Robert

    --
    Bastard Operator From 193.219.28.162
    1. Re:No way! by nathanh · · Score: 1
      First time I did it in mp3, later in vorbis. So there's no way I'm gonna do it again. Besides, there are vorbis hardware players on the market, which can't be said about MPC.

      "First time I did it in MP3. So there's no way I'm gonna do it again. Besides, there are MP3 hardware players on the market, which can't be said about Ogg Vorbis." -- Robert, 3 years ago.

      If it's good, and free, the hardware decoders will come. But yeah, I'm dreading recoding for the THIRD time.

    2. Re:No way! by Anonymous Coward · · Score: 1, Interesting

      If you've got a fast enough computer, you really should have all your audio stored in a lossless format like FLAC and just recode to mp3/aac/vorbis/mpc/lossy format of the day on the fly as you copy the music to your portable player.

  4. MPC by doofusclam · · Score: 1, Informative

    Musepack is a wonderful format. Not only is it quicker to decode than other formats, it's also got the best psycho acoustic model and outperforms pretty much any other codec in bitrates from 128kbit/s above.

    Now that the encoder is completely open-sourced and patent free, i'd like to see it adopted more. Foobar2000, the best Windows audio player available, supports MPC natively and there are plugins for everything else.

  5. What about patents? by motown · · Score: 1

    It's great that we have another high-quality codec has become available under an open-source license right now (the more the better, I'd say), but does anybody here know if this codec is completely free of patents, just like Ogg Vorbis?

    --
    "Oooh, does that mean we get to kick some puffy white mad zionist butt?"
  6. 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?

    1. Re:Can this codec be used in an ogg container? by shfted! · · Score: 1

      Absolutely. I use Ogg containers for movies... It would be nice to have even better than vorbis sound quality.

      --
      He who laughs last is stuck in a time dilation bubble.
  7. This is a non-story. by sultanoslack · · Score: 1

    This is the same code that they've had on their download page (I forget which one, but when I went to download it I noticed that I had already had the file for a few weeks.).

    The sources are in terrible shape at the moment. The developers really need to stuff them into a real autotools setup, pay attention to compiler warnings (there are hundreds), and well, on my system it doesn't even build.

    If MPC is ever going to become a successful OSS project it's going to have to code and build tools in shape. Nobody wants to package or develop for something that is a PITA to even build.

  8. autotools??? by r00t · · Score: 1

    If that's the solution, then I can't image what
    the problem was. Were you trying to increase the
    download size, make cross-compiles difficult, or
    add a build-dependancy on the latest-and-greatest
    illegible crap spewed from the FSF?

    Well-written packages don't need autotools.
    At most, they might require GNU make.

    Would you jump off a bridge if all the cool
    people did it? That's GNU auto* for you.

    1. 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...

  9. Is this a good thing ?? by Qwavel · · Score: 1

    Is there a good reason for this? I mean, is it distinct or better than Vorbis in some meaningful way?

    Cause otherwise it isn't really helping. The issue for many of us is whether a good, free codec catches on. I want to use something that will be widely supported.

    There is an opportunity now for a free codec to do quite well, since the commercial players are still fighting with each other. But fragmentation within the open-source world will not help. If a device manufacturer decides to include a free codec, but then discovers that there are multiple, competing, free codecs, then they just won't bother. Eventually, if history is any indication, MS and Apple will make peace and start supporting each other's technologies.

    I think the MPC website should contain a FAQ that explains how it is significantly distinct from Vorbis. Does MPC fill a different need? Is Vorbis not free? Is MPC significantly better at the core task? Did the Vorbis people refuse to cooperate with you?

    Tom.

    1. Re:Is this a good thing ?? by Compholio · · Score: 1

      It seems to me like it produces much smaller files for the same level of quality - but don't use the defaults if you're working with MP3 files. I've found that the "best" option for my current re-encoding progress is "mppenc --radio --quality 3" - my current extreme example reduced a 5.2 MB MP3 (128kbps) to a 3.9 MB MPC and I can't hear any difference. For reference, the default is "--standard --quality 5", which makes some files smaller and some bigger - my settings produce consistently smaller files with the same quality as the original (as far as I can tell).