Adventures of developing an MP3 decoder in Python

http://portalfire.wordpress.com/

by IgorPartola • 16 years ago

56 28 16 years ago

portalfire.wordpress.com

sqrt172• 16 years ago

It's probably a stupid question, but: what's the advantage to coding everything in Python? If you're targeting the N900, Psyco likely won't help you, and there's probably some existing MP3 library that one can wrap (libmpg123)?

Also: you might want to try Cython, it compiles a Python-like language to (reasonably platform-independent) C or C++ code, with very good Python interoperability.

masklinn3• 16 years ago

You'd have known if you had but simply scrolled to the introductory post:

> I’m going to write a python based MP3 decoder. Yeah, its a bad idea from a performance standpoint, but from a learning/documenting perspective, it is quick and easy.

sqrt172• 16 years ago

Ok. But then I don't understand the squirmyness about using numpy (and possibly scipy). Not using numpy in such cases will always give you less-than-decent performance.

extension• 16 years ago

If I had to implement something as sophisticated and novel (to me) as an mp3 decoder, I would first prototype it in my favorite dynamic language and then port it to something fast.

acdha• 16 years ago

It's great for learning and playing with algorithms, particularly since you would save so much time which would otherwise be consumed with low-level details that you'd have a much better understanding of the overall program function when the time came to optimize. There's a real forest-for-the-trees problem optimizing something like C first.

acqq7• 16 years ago

I don't know why trying to reach real-time speeds with Python. At the moment it's really a slow language. According to my measurements is JavaScript at the moment the fastest "typeless" scripting language: the engine in Firefox can be up to 200 times faster than Python. There's also a command-line version.

judofyr• 16 years ago

Well, the fastest scripting language must be LuaJIT?

acqq7• 16 years ago

If you refer to http://shootout.alioth.debian.org/u32/luajit.php my answer is: maybe. As far as I understand the JavaScript benchmarks there were made before the most recent speed improvements (JaegerMonkey, present in Firefox 4 beta). In my simple tests, the speed in some loops can reach the speed of C, with the times better than LuaJIT.

Still, LuaJIT is easier to obtain and run, as far as I know.

cdavid2• 16 years ago

But javascript does not have something like numpy. You can easily get one to two orders of magnitude faster using numpy when applicable, and a MP3 decode certainly falls in that category.

pcwalton• 16 years ago

Flusspferd (http://flusspferd.org/) has GMP bindings, and there's no reason that node.js (for example) couldn't be hooked up to GMP as well.

acqq7• 16 years ago

It's true that Numpy is much faster. I believe there's a lot of native code in Numpy and once we consider the libraries encoded in C, any language can be as fast as any other, as soon as we can offload enough to the libraries (for example, Perl has also some official C extension mechanisms: http://perldoc.perl.org/h2xs.html and even old Visual Basic was able to call DLL's written in C).

However, I'd really like if at least something that's now a part of Numpy (which I believe is now even more a language extension than a library) would become the part of the Python language.

banditaras• 16 years ago

A long, long time ago I coded an MP3 implementation for a TI Fixed Point 16bit DSP@100MHz (family 5XXX IIRC).

I initially wrote it in floating point C (compiler translated float to fixed point) and it was damn slow. I then rewrote everything to use fixed point arithmetic only and dropped down to about half a second of decoding for a second of data. That wasn't still good enough because the DSP had to take care some other stuff like ide drives, dma, fat, dac, usb , display drivers etc, so I rewrote all critical parts in assembly taking advantage of the chip's build in dsp functionality and dropped to 100ms of decoding for 1s of data.

So it might be helpful to start from a pure python implementation then move your way down, you'll still learn a lot.

StavrosK3• 16 years ago

Since you've done it, can you tell me a bit about the caveats of converting from floating point to fixed point arithmetic? It would seem that the only thing you'd need to do is multiply by whatever doesn't make you run out of space, so, as someone who hasn't actually tried it, I'm wondering what the hard part is (apart from the obvious loss of accuracy when transitioning from floats to ints).

mryall• 16 years ago

The bit that cracked me up:

> I finished the decoder and it can produce wav file output from an mp3. The good news is that is works, the bad news is that its 34 times to slow to play the audio runtime.

I think it's great to try learning something in a language that makes experimentation easy. Looking forward to see how he goes with the optimisation.

noonespecial2• 16 years ago

My first attempt to write a decoder was done on a "Cyrix" 586 processor at 90 Mhz. (The kind that fit in a 486 motherboard and let you pretend you had a pentium.) I wrote it in pascal. It did just a little better than 1.5 weeks per minute of audio. I was thrilled to no end that I'd made it work at all.

My hats off to him.

StavrosK3• 16 years ago

Wait, if it took a day per second, how did you even know it worked? :P

Adventures of developing an MP3 decoder in Python

Related Stories