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.
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.
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
Well, since useable speed isn’t an issue, I’d like to see the HDCP encryption in well-readable code :)
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.
There’s plenty of uses for an mp3 decoder not requiring realtime performance. Analysis, reconversion, etc.
Sounds like torture…
I like it!
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.
There’s still a bit of scope in that code for optimization (without obfuscation), without resorting to psyco.
cumtime? really?
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.
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
Well, if it’s to slow you can always cast it in silicon using something like myhdl :-)
http://www.myhdl.org/doku.php/start
Yes, it’s better to make an efficient decoder, but this can be an interesting way to learn how does that work.
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.
so why he chose Phyton in the first place ? I don’t see how C or C++ code wold have less educational value
Am I the only one that lol’d at “cumtime” in the posted image? :P
cumtime *giggle*
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.
Cumtime. LOL
At least in LuaJit, calls to C code are really expensive (because the JIT is getting disabled)
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!
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.
@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.
@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.
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…
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 :).
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
did somebody call python readable up there?
I like better the Java language, but doing it on Python must be interesting
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!
I wonder how well it handle variable bit-rates… *snickers @ cumtime*
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…