Decoding MP3 in Python

We all listen to them, but do you know how the compression for an MP3 file actually works? [Portalfire] wanted to find out, while honing his Python skills at the same time. He’s been working on an MP3 decoder in the Python language. So far he’s had some success, with the first working decoder clocking in at just 34 times slower than real-time. But since then a bit of optimization improved that to 10 times slower.

Sure, it’s not a usable module yet but his goal of learning the algorithms has been reached. A combination of reading about the standard and looking at code from other projects made that possible. In the future he plans to try the same thing with the H.264 codec.

Comments

  1. Ken says:

    It’s an interesting project. Most “real” decoders are heavily optimized which decreases code readability. This is a lot of educational value to this project.

  2. portalfire says:

    If anyone is interested the python H.264 decoder is also complete. It has a frame viewer to help visualize the codec. Its at: http://bitbucket.org/portalfire/pyh264

  3. TD-er says:

    Well, since useable speed isn’t an issue, I’d like to see the HDCP encryption in well-readable code :)

  4. charper says:

    Python is normally an interpreted language, and will suffer in performance compared to something like C.

    I am pretty surprised, even considering non-optimized and interpreted code, that it can’t play in real-time on modern hardware.

    Cool stuff. I agree w/ Ken as well – I’m sure you’ll learn a lot and teach all of us something along the way.

  5. th0mas says:

    There’s plenty of uses for an mp3 decoder not requiring realtime performance. Analysis, reconversion, etc.

  6. NatureTM says:

    Sounds like torture…
    I like it!

  7. ThorSummoner says:

    Glad to hear a python story every now and then; i’m working on a .obj to .vmf converter in python and enjoying the python language in general. Kepp up the good work.

  8. TJ says:

    There’s still a bit of scope in that code for optimization (without obfuscation), without resorting to psyco.

  9. mrwtf says:

    cumtime? really?

  10. bilbao bob says:

    You know, this is actually great work. I think the inverse operation would be -ahhh- illustrative. seriously, if you’re within 10x of real-time, you’re doing great.

    One problem (a big problem) with most scripting languages that try awfully hard not to be procedural is that they’re dog slow. I prefer fast development to fast languages, but I don’t like the tendency towards unnatural abstractions found in some of the newer languages.

    I do, however, like the languages. MP3 decoding is a pathological case, so it will do a lot to improve your ability to optimize code.

  11. M4CGYV3R says:

    Or you could just go look up the file specification and write a decoder that works the first time…

    A good place to start: http://en.wikipedia.org/wiki/MP3

  12. jklu says:

    Well, if it’s to slow you can always cast it in silicon using something like myhdl :-)

    http://www.myhdl.org/doku.php/start

  13. Thor says:

    Yes, it’s better to make an efficient decoder, but this can be an interesting way to learn how does that work.

  14. Anonymous says:

    Python is not “interpreted” — it’s compiled to byte code and then run. The same applies to Perl, Ruby — and, since very recently, Javascript is compiled or JIT’d in at least Gecko and WebKit browsers.

  15. therian says:

    so why he chose Phyton in the first place ? I don’t see how C or C++ code wold have less educational value

  16. Anonymous says:

    Am I the only one that lol’d at “cumtime” in the posted image? :P

  17. hmm says:

    cumtime *giggle*

  18. Alan says:

    I’d like to see small computationally heavy segments offloaded to a python method written in C. It may be possible to have code readability and 1x playback thanks to python’s extensibility.

  19. TTSDA says:

    Cumtime. LOL

  20. dkr says:

    At least in LuaJit, calls to C code are really expensive (because the JIT is getting disabled)

  21. awesome says:

    This is what I was gonna look for. Great! I have some MP3-encoded streams I’ve saved directly with wget, the song name changes throughout (in VLC/realtime) and I wanna get that metadata out of it so I don’t have to track down song names. This can allow me to split the stream when song name changed.
    I don’t know python but I could probably adapt it to what I do know
    Thanks a lot!

  22. portalfire says:

    The reason I choose python was implementation speed. Writing an algorithm without worrying about allocations or types really speeds things up. When I started I had no idea what the end speed would be. I thought a modern computer would have no issue decoding mp3s with python.
    Offloading the heavy lifting is a great idea. I ended up writing a c based “acceleration” module to my python H264 decode to make it bearable to work with. I hoped that the mp3 decoder could be relatively pure python.

  23. ColinB says:

    @Anonymous wrote: “Python is not “interpreted” — it’s compiled to byte code and then run.”

    Are you saying your computer has a CPU that executes Python bytecode? Amazing!

    The Python source code may be byte-compiled, but the bytecode is still executed by an interpreter. There is Psyco, which is a dynamic compiler for Python and it can bring significant performance improvements in some cases, but apparently still has some serious drawbacks.

  24. cantido says:

    @colinb

    If the vm has jit it is turninh the source/bytecode into native machine code for the host.

    Doesnt detract from the fact that people should just learn c/how these machines work.

  25. rallen71366 says:

    It looks like portalfire was doing this as a learning exercise. A VERY good exercise, by the way. Everybody saying,”why didn’t he do it in C/C++?” get F’s for being idiots. He already knows how to program in C (see his comments above). You don’t develop skill or creativity by having all the easy tools handed to you. You develop your “muscles” pushing against constraints. Portalfire is obviously pretty beefy…

  26. Check out this Python JIT written in Python I’m working on – http://pyable.org/ . This will be much more useful with my project (or pypy :).

  27. saint says:

    that would be an awesome addition to blender, mp3 audio makes it to easy reflect certain frequency’s in properties of any 3d object since it is already layered

  28. ovaries says:

    did somebody call python readable up there?

  29. Domo says:

    I like better the Java language, but doing it on Python must be interesting

  30. cknopp says:

    I wonder what the time would shrink to using the OpenCL Python interface.

    Offloading the python code to a decent GPU should speed things up.

    PS: I love the mp3 reflection layer/material for blender as well! Especially with Blender plugins like SLG from LuxRender!

  31. Rollyn01 says:

    I wonder how well it handle variable bit-rates… *snickers @ cumtime*

  32. ughg says:

    No, it has indeed great educationnal value:
    it show how python really suck. I mean I have seen many microcontroller project (<80Mhz cpu) doing software mp3 decoding. And yet most people still think 34 time less performance is ok??? there must be something wrong…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 96,376 other followers