JavaScript Decoder Plays MP3s Without Flash 250
An anonymous reader writes "The introduction of HTML5 and super-fast JavaScript engines to the latest web browsers has brought with it a wealth of new functionality. The focus seems to have been put on the ability to play video in a browser without Flash, or making games. But a project born out of a Music Hackday in Berlin is just as exciting. It's called jsmad and is a pure JavaScript decoder that allows you to play MP3s in a browser without Flash. So, for example, a music artist could create a website and upload songs for visitors to listen to without need of any plug-ins. Alternatively, why not have an MP3 jukebox that can play songs off your hard drive or Dropbox folder just by loading a website? You can try out the decoder by visiting the jsmad.org website where there is a sample song, on the same site you can browse for your own local file to play. Be warned, it only works in Firefox 4+ at the moment, but Chrome support is coming and already works in some cases."
Another reader tips news of a JavaScript PDF viewer.
It works! (Score:2, Funny)
Actually, my subject makes me seem more excited than I am. I regret any misunderstanding.
Carry on.
Re: (Score:3)
I have noticed a lot of the new "trendy" streaming sites have decided to do away with or hide the volume control...
Sometimes I like to adjust the sound of one application vs another and on my work computer, the headphone volume is too loud at the lowest click unless I turn down the application volume (but dropping wave volume all the way down messes with the speaker sound which application volume seems to behave well with)
Re: (Score:2)
Any modern OS allows you to modify the volume per application (Windows Vista and Windows 7 do, I'm told Linux does as well with a particular mixer installed. Mac OS doesn't though).
Re: (Score:2)
I too agree. Now, I don't often need to mess with the application volume if it's all I'm doing, but if I'm trying to, say, listen to music in addition to Teamspeak, then yes, I need to be able to adjust it.
another reason to not have to use flash (Score:2)
mp3? Acrobat! (Score:5, Insightful)
I'd say that getting rid of the Acrobat plugin is far more interesting.
Re:mp3? Acrobat! (Score:4, Interesting)
I use foxit. There's also Okular. I probably shouldn't forget [g|k|x]pdf... Plenty of alternatives to acrobat.
Re: (Score:2)
Re: (Score:2)
But a Javascript API means PDFs be much more optimized, because you don't need a software plugin loading and running in the background.
Because Javascript just executes itself through magic and requires no background processes running to compile and run it, right?
Re: (Score:2)
Actually that would be correct (except it being magic) because they are all single thread anyhow and every page view these days has to utilize jvm in one form or the other, because any ECMAScript engine with framework libraries supporting swfobject and pdfobject, pdf/swf wrapper api to external execution stack is necessary. hence having ECMAScript engine able to support full pdf data stream without extra execution stack does make sense. As for developer's sake, I can see some value in not dealing with ext
Power efficiency??? (Score:2)
My guess would be that native plug-ins will always be more efficient on power than java script interpreted code. Not sure where exactly flash lies in that spectrum. It's a power hog compared to most apps but but my guess is flash has a lot of high level functionality running natively (audio and video) with just the command and control being in the flash language.
Re: (Score:2)
I hope Subsonic adds a version of this (Score:3)
it'd be kind of nice to be able to stream music to my Kindle, which for obvious reasons doesn't have Flash, but does have a rudimentary web browser that's based on WebKit.
Err (Score:2)
Re:Err (Score:4, Insightful)
Not having to have a native mp3 decoder codec on your machine. Also being javascript it is theoretically compatible across all platforms that the browser supports, particular those that may not have native mp3 decoder codecs. The HTML5 standard isn't attempting to establish a standard for codecs. Not saying it's worthwhile or anything, just pointing out potential benefits as you requested.
Re:Err (Score:4, Informative)
Gecko does not support MP3 in HTML for exactly the same reason it doesn't support H.264 in : it's patent-encumbered and you have to pay licensing fees to use it.
In 6 years, when the MP3 patents expire, we'll see.
Re: (Score:2)
Gecko does not support MP3 in HTML for exactly the same reason it doesn't support H.264 in : it's patent-encumbered and you have to pay licensing fees to use it.
They could just divert and use the codecs that are included with the OS and already licensed by the OS vendor, be he Microsoft or Apple, and that would cover 90% of cases. However, they probably wouldn't do that because it would make the Linux version less competitive by comparison, because many Linuxes don't have codecs or they're an additional install, and Mozilla would rather have an equal less-functional playing field between the ports of Gecko/Firefox than have versions that competed with each other o
Re: (Score:3)
Actually, Mozilla could just license the MP3 patents or the H.264 patents if all they cared about was their own exposure.
But that wouldn't help the patent restrictions on authors and such.
So the stance against patent-encumbered codecs is less about a level playing field for Linux than about a level playing field for all who would like to put content on the web. And that last part is in fact one of the core aspects of Mozilla's reason for existence.
Re: (Score:2)
The MP3 format was first published in 1993. Other than changes and improvements made since then, any patent on the basics *should* therefore have been filed by 1994, and expire by 2014 (unless it was delayed for longer than 3 years before the patent was granted).
Interesting, BUT (Score:2)
We've had this kind of functionality for a long time. I don't mean through flash, but there has always been some client-side software that decodes and plays back audio files, usually by one plugin or another. A javascript player basically follows the same model of loading some code on the client machine that does the playing. The only difference here is that it's being done using slightly different facilities.
More than slightly different. (Score:2)
What's cool about this is that at least for audio, it's actually efficient enough that we can stop caring about whether browsers support a given codec. Maybe use <audio> when supported, fall back to pure JS when it isn't.
All that without relying on any plugins, which means the entire process can sit inside the same sandbox browsers have been building for years.
What we had before this required users to download and install software, and give it full rights to the machine, in order to play back media. I
why? (Score:2)
anyone?
Fallback for . (Score:2)
Try <audio>, if they don't have MP3 support, fall back to this.
Before this, the fallback would've been Flash, which sucks.
5...4...3...2...1...Slashdotted! (Score:2)
It's coming (Score:4, Funny)
I'm writing a browser in JavaScript that will run on itself !!!
Re: (Score:2)
Hotjava. [wikipedia.org] A browser which could run Java applets, written in Java.
On all the Sun servers I ever administered, I ran that browser just long enough to download and install Mozilla. (Yeah, it was the IE of Unix browsers, for the simple reason that it was pretty limited.)
This cries out for a "'Yo Dawg" joke which I am not going to stoop to make.
Super-fast is a bit of a misnomer (Score:3)
It's more like "no longer agonizingly slow" due to herculean (and well-appreciated) efforts to optimize a language that was just not written for speed. You might as well say you upped the voltage to your Prius and say now it's a "super-fast hybrid" -- people that prioritize speed don't buy hybrids and people that buy hybrids obviously didn't consider speed to be a priority.
This is not a criticism, it's just a statement of fact. Even the fastest javascript engines don't even remotely compete with modern interpreted languages (Java, C#), let alone actual bare-metal code (C and friends). Both have their place depending on what you are doing. Having a natively written plugin handle MP3 decoding with a well-defined API seems to me far more logical than expending effort to write it in javascript, especially when it doesn't even run across all browsers yet.
Then again, that's just my $0.02, and as much as I don't think it's a great use of effort, it's damn cool!
Re: (Score:2)
I'd think it would depend which part you're considering. Overall, yeah, you're right. But in parts, at the end modern Javascript engines, just like Java or C#, have just in time compiler and they execute native code. Javascript preemptively has to auto-detect the types, but recent progress allowed engines to do that ahead of time as much as possible. So after that, native code is native code. I would
Re: (Score:2)
Javascript preemptively has to auto-detect the types, but recent progress allowed engines to do that ahead of time as much as possible.
That's where the catch it. Semantically, JavaScript is dynamically typed. Optimizers have to jump through a lot of hoops to infer types, and even then they often end up with "it's either X or Y here, not sure which", necessitating a runtime check before one of the two optimized versions is chosen. The problem is that it's very easy to write such JavaScript without realizing that, whereas in something like Java or C#, this is explicit in the code of your program in form of "instanceof" and casts.
Re: (Score:2)
Even the fastest javascript engines don't even remotely compete with modern interpreted languages (Java, C#)
*facepalm* C# is not an interpreted language. The IL is either AOT compiled or JIT compiled to native code at runtime.
Re: (Score:2)
Now you could write a C# interpreter if you want but that is not how C# code is executed. It is always compiled whether it be AOT or through a JIT compiler.
Re: (Score:2)
Same for Java, but the JVM happens to be a lot more mature than the CLR and generally runs faster.
Re: (Score:2)
Sure, Java does now. But originally Java was purely interpreted. C# has NEVER been interpreted.
Re: (Score:2)
Are you sure about that? When was Java ever an interpreted language?
Re: (Score:2)
In the mid 1990's, more or less.
Re: (Score:2)
Re: (Score:2)
A lot of people will argue that the byte code was then interpreted rather than compiled. Some people still insist that even JIT isn't really compiling.
Re: (Score:2)
And this matters how exactly? Please be specific.
Re: (Score:2)
New $engine: Now with more jiggawatts! Hey, I have an idea. Let's also re-invent the multithreading wheel by putting a totally new code you guise scheduler into our awesome for real browser. That ought to run nice and smooth... wait, the OS and that other site that pings the twittlers is pre-empting it, so now my mp3 is all skippy.
My point is: Software that needs to keep a buffer filled in real-time should probably not be written in Javascript. While you CAN do it under ideal circumstances (powerful enough
Re: (Score:2)
people that prioritize speed don't buy hybrids and people that buy hybrids obviously didn't consider speed to be a priority.
Really? [evo.co.uk]
Re: (Score:2)
Languages are not slow. Algorithms are slow. Execution environments are slow. There is nothing fundamental about JavaScript that makes it slow. Until recently, browsers executed it inefficiently and with few optimizations.
Languages impose constraints that require the execution environment to do more work for a given algorithm written in one language rather than another. Consider the following algorithm in C:
const int N = 1000000;
int someNumbers[N] = GetArrayOfIntsWithLength(N);
int sum = 0;
for(int i = 0; i
If you implement this in Java instead of C, it turns out that the call to operator[] must, according to the language constraints, check to see if the value is within the range [0,size) for that array. The JVM may not skip t
Re: (Score:2)
Oh for fuck sake slashcode. Less-than isn't meant to close tags.
Re: (Score:2)
That's what <ecode> is for.
Re: (Score:2)
Languages are not slow. Algorithms are slow. Execution environments are slow. There is nothing fundamental about JavaScript that makes it slow. Until recently, browsers executed it inefficiently and with few optimizations.
Languages impose constraints that require the execution environment to do more work for a given algorithm written in one language rather than another. Consider the following algorithm in C:
const int N = 1000000;
int someNumbers[N] = GetArrayOfIntsWithLength(N);
int sum = 0;
for(int i = 0; i \
Ugh. (Score:2)
This will allow unthinking people another way to implement one of the things listed in every bad practices top ten list for the past decade: websites that make noise.
Java, anyone? (Score:3)
Can somebody please remind me why we moved from Java applets to Javascript applets?
It can't be just a matter of tight browser-VM integration or GPLiness.
Why are we coding the whole thing all over again?
Re: (Score:3)
Java applets took several seconds to load, but more importantly, that was visible to the user (remember those ugly gray rectangles)?
That, and they have their own sandbox, not particularly well integrated with HTML DOM.
bettter than I tought (Score:4, Interesting)
I was worried about the cpu consumption of this and it only took between 7 and 13 % of one q6600 core on firefox 7.0a1 nightly
Re: (Score:2)
Wow. It only takes between 7 and 13 percent of a 2.4GHz Core 2 core with a couple of megabytes of cache to do what I was doing on a not-so-special 486 (15 years ago)?
If this is the future of computing, then I'm turning Amish.
Re: (Score:2)
Cool hack (Score:3)
Re: (Score:3)
You forgot to include the 20MB+ of Silverlight libraries that need to be installed on the PC to make that 154kb file work.
Re: (Score:2)
It's cool that somebody got this working. That said, looking at this sort of things further enforces my belief that we're all barking up the wrong tree by going with JS+html as client side development environment of the future. Compared to a Silverlight solution, the JS player is 3.5 times larger (535kb vs 154kb), uses about 3.6 times as much CPU power (25% vs 7%), and has to have significant modifications to work in multiple browsers. Not really progress.
I certainly agree and if I were going to deploy a website or do a project for a customer today, I wouldn't even think about using this kind of stuff. However Moore's law combined with the compsci work on making dynamic languages fast will eventually make JS a valid contender. I'm glad to see people out there pushing the boundaries of what can be done in JS, which will certainly drive further performance improvements and perhaps even future extensions to the language.
It's a bit funny... designing a UI in HTM
Re: (Score:2)
Re: (Score:2)
> Compared to a Silverlight solution, the JS player is 3.5 times larger (535kb vs 154kb), uses about 3.6 times as ...compared to a Flash solution, the JS player is >100 times larger (a Flash version could be under, say, 4k, including UI, since the MP3 decoder is built in).
> much CPU power (25% vs 7%), and has to have significant modifications to work in multiple browsers. Not really progress.
Re: (Score:2)
". Compared to a Silverlight solution, the JS player is 3.5 times larger (535kb vs 154kb), uses about 3.6 times as much CPU power (25% vs 7%), and has to have significant modifications to work in multiple browsers."
Can you please tell me what modifications are necessary to use the silverlight plugin on my Solaris SPARC system? You say it works in multiple browsers so I would like to test your assertion.
Re: (Score:2)
25% vs 7%
Yes because lord only knows that you can't get by without that extra 17% of CPU
Personally I key in all my text from the front panel in ASCII because I don't like the overhead from the keyboard driver.
Re:Stupid (Score:2)
How about compared to having a client side CODEC library in the browser and just adding a one liner to your HTML code?
Seriously my first thought was after all this effort to standardise video CODECs in browsers so HTML could natively display video was WTF! Playing music in a webpage was something that worked fine in the early 90s and now suddenly we're talking about Silverlight, or writing a native coder in Javascript?
Re: (Score:2)
Re: (Score:2)
How incredible (Score:2)
Bleeding edge Javascript "compilers" are now fast enough to run some elementary code.
Great, how about they move to real programming languages and compilers instead?
I don't want to need a supercomputer to run Javascript code that would run as fine with a proper programming language on a computer from 1980.
What Output API Does it Use? (Score:2)
Normal MP3 decoders result in some uncompressed samples that can be sent to the sound hardware through an API provided by the OS?
What API is the Javascript using to output the sound?
I know HTML 5 has a canvas tag that can be used to draw on a surface. Is there something analogous provided for sound?
Re: (Score:2)
I think they are using Mozill Audio Data API [mozilla.org] and that must be the reason it only work currently with Firefox, until the API advance from experimental to something more standard
Awesome (Score:2)
Now javascript based popup ads can run an MP3 of a woman loudly faking an orgasm or a guy screaming "PUNCH THE MONKEY". Maybe we'll even get the fake cell phone ringing sounds like radio commercials just to really make life wonderful.
Wow. (Score:2)
Great, but has some audio artifacts (Score:3)
Re: (Score:3)
MP3 is patented so I'm guessing Mozilla and Opera won't pay the license fees for it..
Re:Can't HTML5-compatible browsers play MP3s nativ (Score:5, Insightful)
And once agan, just like with H.264, they wouldn't have to pay any license fees if they just used the OS's own media API instead of trying to support specific codecs themselves.
Modern OSs provide such an API for playing audio and video, and some (ie. Mac OS and Windows) even provide licensed proprietary codecs... not to mention that OS-provided codecs often work with things like video drivers to provide hardware acceleration that is transparent to applications. For example, VLC, while awesome, uses a huge amount of my CPU to play 1080p H.264 video, since it's software decoding (possibly with some generic "hardware assist"). On the other hand, Windows Media Player, which uses Microsoft's DirectShow codec which takes advantage of my GeForce card's full H.264 decoding, uses 1% of my CPU to play the same video.
Browsers already make use of other OS-specific features, and this would make the whole codec licensing thing a non-issue for the browser makers, and for the vast majority of users. They need to stop trying to reinvent the wheel. The OS provides services to applications... browsers should use them.
Re: (Score:3)
A multi-platform browser tightly coupling itself so that a certain subset of the users can't use some of the features. What a good idea.
Re: (Score:2)
There is this thing called conditional compilation, ya know. Let alone environment-aware code paths.
Re: (Score:2)
That subset of users you mention encompass less than 1% of these browser users. Windows, OS X and iOS, Android, Windows Phone 7, even most major Linux distros all come with either build in software decoders or in the case of portable devices come with either software decoders or built-in ASICs for decoding. You would have to be using some obscure Linux distro or willfully choose to not install the codecs needed to make this possible. Such a group of people are statistically irrelevant.
Re: (Score:2)
More frustrating than that, to me, is that while I would love to find a solution that works for those less-than-1% group, I don't think I own any machines that don't come with hardware decoders for all of these things.
Still, it is nice to have another option. This works surprisingly well -- Firefox uses ~40% of an 800 mhz CPU. Chrome used ~20%, but didn't actually play, so it's not quite the same. What we need now is better detection/negotiation, so I can use native HTML5 audio on sane browsers and fall bac
Re: (Score:2)
Yea, because the browser doesn't already do that in hundreds of places in order to perform as fast as possible.
If you're using a firefox backed by Cairo, you're most certainly using OS specific extensions or using an OS with no features worth talking too.
The browser is the shim between the presentation layer of the native OS and the web. Its very job is to provide the native hooks in uniform way so that web pages are rendered.
You have to be tightly coupled with the OSes native features if you want your web
Re: (Score:2)
Modern OSs provide such an API for playing audio and video, and some (ie. Mac OS and Windows) even provide licensed proprietary codecs... not to mention that OS-provided codecs often work with things like video drivers to provide hardware acceleration that is transparent to applications.
Canonical licenses both MP3 audio and H.264 video for its OEM partners: which may help to explain why the Ubuntu Linux PC has some presence and visibility on retail shelves.
Licensed Companies [mp3licensing.com], AVC/H.264 Licensees [mpegla.com]
Re: (Score:2)
No it hasn't. We're talking about a pure JavaScript decoder.
I predict... (Score:2)
In the future there will be a slashdot posting about a Javascript script being able to post comments to stories on slashdot from a browser without needing a human to be present at the keyboard. When this happens, there will be remarks made about the change in the quality of comments. Some one will welcome the new Javascript comment posting overlords, etc.
Re: (Score:2)
Anything that can phase out the necessity for Flash is welcome news in the web dev community.
So, yeah. Posting snooty Slashdot criticisms as AC is pretty cool too.
Re: (Score:2)
Except that this does absolutely jack and shit to phase out flash for almost anyone. How many people are saying to themselves "Well I'd only get rid of flash but I need a flash-based mp3 decoder!!". Anyone who is going to want to play mp3s on their computer are ether going to use a media player installed on the system rather than using a browser player to play mp3 files off of their hard drive.
Re: (Score:2)
Considering for comparison that this decoder barely registers more than a few % above idle on my CPU monitor apart an occasional singe spike on one of the cores, and definitely does not stutter. This is on my three year old PC.
Re: (Score:2)
1. combine this with Amazon Cloud Drive or Google Music and no, you won't need a system player or local MP3s.
Or you could use the already present music player in Google Music that will probably be far better performing than this Javascript turd that stutters to high hell.
2. MP3 playback requirement is prevalent all over the web, though thankfully it's becoming less common.
But how many of them are actually using a flash mp3 player over an embedded player using the system codecs? Seriously, almost no one is sticking to flash for mp3 playback so this will do fuck all to eliminate the flash plugin.
Re: (Score:2)
hello? We are in 2011. All browsers support the audio tag. All you need is to dual-encode your files in MP3 and OGG to support Chrome, Firefox, Opera, Safari and Explorer. If you are like me, You'll only encode in ogg, which will work in Chrome, Opera and Firefox. Explorer/Safari represents Mac/Windows, so fuck them.
Re: (Score:2)
Exactly my thoughts.
Also, since Chrome supports all browsers, Safari only MP3, Opera and Firefox only ogg, all you need to support all browsers is MP3, and the audio tag.
That means, the entirety of this functionality is already in the browser, and all you need is 2 file formats, and there's automatic failover with multiple source tags in the audio tag.
Of course, it's still a nice hack and POC of what can be acomplished in JS, but pretending it has real life uses as the article does is just plain stupid.
Re: (Score:2)
Re: (Score:2)
Great. But do we really need a story for each and every piece of software written? Secondly, having used this decoder it is no where near as performant as a traditional decoder written in C and assembly optimization. It stutters quite badly.
Re: (Score:2)
Re: (Score:2)
javascript's sins against developers will become somewhat less relevant.
Or do you mean: "developer's sins against javascript"?
Just because there is a history of poor programers does not make the language any less interesting/powerful.
Re: (Score:2)
My guess: yet another person complaining about how JavaScript doesn't use their specific pet paradigms.
Re: (Score:2)
I would almost go out on a limb and say it does do whatever paradigm they are looking for if they actually tried... but I don't consider myself an expert so I won't go that far. Sure, things like multiprocessing aren't there unless you consider that a feature of individual browser/sandboxes. The only limitations I can think of right now involve said sandboxes, but most core programming strategies that I'm aware of can be done in JavaScript. Some of the syntactical sugar and performance may not be there,
Re: (Score:3)
Maybe, but that doesn't mean the GP is wrong. The design of JavaScript borders on absurdity. It's a terrible language.
Re: (Score:3)
The closest thing it has to actual classes feels like a crudely bolted on hack (like Perl, but with even less syntax support).
In some senses, this is a good thing. The fact that you don't need specific syntax to declare a new kind of object is quite liberating. I can define new object kinds by manipulating old ones, or by the more traditional ruote of declaring a constructor function. You're quite able to set up functions that produce new object kinds when you call them. All this makes the environment very flexible. Yes, there is the down side that certain simple tasks become a little harder, and a certain amount of boilerpla
Re: (Score:3)
The closest thing it has to actual classes feels like a crudely bolted on hack (like Perl, but with even less syntax support).
Most of the commonly built-in JavaScript APIs abuse developers by forcing them to use callbacks because JavaScript has no notion of blocking calls and doing work in other threads at the same time.
Worse, most JS APIs (e.g. XHR) don't provide any extra parameters for passing context data through them to your callback. This forces you to do such awful hacks as hiding program data in the DOM tree and building generated helper functions on the fly for every freaking call. Such de
Re: (Score:2)
I am an expert with javascript at this point, and I can do amazing things with it. But that does not mean that it does not suck. No good IDE's, debugging and validation are a pain. The worst part of all is that its GUI is tied the crapfest that is the modern web browser running any one of a number of almost but not quite entirely unalike implementations of the HTML DOM.
Re:The rise of Javascript. (Score:5, Informative)
No, there are many things wrong with Javascript. Just a sample:
1. The == operator. What. The. Hell. (Yes I know about ===; that's beside the point).
2. No true arrays. They are actually maps/associative arrays. (And that's the only thing you get.)
3. No typing. E.g. you can't have a 16 bit int, or an array of bytes.
4. No real integers. Bitwise operations are done by converting from doubles to int, and then back again.
5. Way too much implicit conversion (the stupid '1'+'1' -> '11', but '1'-'1' -> 0 thing).
6. No data hiding of any kind. Everything is public (unless you use crazy hacks). You can't even be sure third party code hasn't modified your classes.
7. Implicit semicolon. It's just a bad error-prone idea. (And I have *no* idea why Go made the same mistake.)
8. No support for proper modules. You basically have to put everything in one file, which wouldn't be so bad if the IDEs didn't all suck.
9. It's basically impossible to reason about performance, partly because of the new-fangled tracing/JIT engines, and partly because the spec doesn' make any
guarantees about complexity.
I'm not saying it doesn't have nice features, it just has a lot of ugly "let's make this easy for noobs" mis-features that actually fuck everything up, which is a shame.
Re:The rise of Javascript. (Score:4, Insightful)
your options pretty much break down into "javascript" or "assorted architecturally superior; but single-platform and/or deeply fucked in the code quality plugins".
You'd think Java would be filling this role, but it isn't.
Re: (Score:3)
No, the problem is that the "standard" has barely changed since Javascript was introduced many years ago. The base language, ECMAScript, is shared with Actionscript (Flash's coding language). Except JS still looks like Actionscript from ten years ago. This comes down to the intractability of the standards committee to move forward with any large design changes due to various corporate dissenters, as well as between the ECMAScript committee and
Re: (Score:2)
go away host file troll
Re: (Score:2)
O(n)
Re: (Score:2)
This nonsense may inexplicably result in feverish night terrors among those in Redmond, but the rest of us - the best of the best?
Not impressed. Not interested. Don't care. Never will...
Redmond? ITYM San Jose
Fail (Score:3)
It's useless on my work laptop running FF4.
The sound is so choppy it's essentially noise, and it causes my FF4 memory footprint to triple. This is on a 1.6GHz Pentium M with 1GB of RAM..
Just another example of our wonderful ability to come up with ways to waste immense amounts of computational power. It's completely ludicrous to write a decoder in such a high level interpreted language.. I was playing mp3's on p200's, and whoever did this managed to waste so much time executing bloat that a 1.6GHz cpu can't
Re: (Score:2)