Why we should have another Monkey’s Audio decoder implementation

Why should I bother about Monkey’s Audio? Because many pirates good people offer classical music in this format (FLAC is quite rare and I’ve seen WavPack only once).

What I consider wrong in Monkey’s Audio design:

  • No verson compatibility – each version alters decoding process
  • Huge blocks – some megabytes is huge indeed (WavPack – 64k, FLAC – even less), hence inaccurate seeking and big memory requirements
  • “Insane” profile – if it does not decode in realtime on my CPU that is unusable

What I consider wrong in MA implementation:

  1. There is only one implementation (with two known ports)
  2. It is not endian-safe (both generated WAV headers and < 3.92 decoding)
  3. OO in that case means “Object-Obfuscated” (i.e. too many files where you can’t easily find required code)
  4. Custom license

Maybe during GSoC somebody will write easily understandable portable decoder in Lavc that will allow playback of .APE in FFplay,MPlayer,VLC,Xine,etc. Otherwise I’ll have to do it myself.

4 Responses to “Why we should have another Monkey’s Audio decoder implementation”

  1. Robert Swain says:

    There is a use for codecs which cannot decode in realtime – storage. But considering the alternatives that also have high levels of compression while maintaining decodability, I agree with you. You could always convert the Monkey’s Audio stuff to another format of your choosing.

  2. Kostya says:

    I usually do so (my format is Audio CD for this files).

    BTW, can you mail me where you stuck in AMR decoding so I may write you a spec.

  3. Robert Swain says:

    Cool. I’ll have a look and contact you about it. Thank you.

  4. Take a look here:

    http://www.rockbox.org/tracker/task/7256

    APE decoder written from scratch. Released under GPL.