Slashdot Mirror
JavaScript Decoder Plays MP3s Without Flash
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.
Actually, my subject makes me seem more excited than I am. I regret any misunderstanding.
Carry on.
Humor from a Genetically Molested Mind
Now if only the pr0n industry would hurry up and get with the program.
Fuck Ajit Pai
I'd say that getting rid of the Acrobat plugin is far more interesting.
No sig today...
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.
Hail Eris, full of mischief...
E pluribus sanguinem
MP3 is patented so I'm guessing Mozilla and Opera won't pay the license fees for it..
I'm writing a browser in JavaScript that will run on itself !!!
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!
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.
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.
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.
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.
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.
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?
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 W3C. I mean, the first update since *1999* was in 2009, and that was a very, very, very watered down update (based on the few things the committee could agree on) intended to show everyone they'd made progress, but seemed more like the Bring Out Your Dead sketch. More or less, the ECMAScript committee is the software version of the UN. Now they're planning for another update, but they've already said they won't be adding classes or the things that would pull it out of the software dark ages, and there's no release date.
After that internal meltdown, Adobe pulled a Cartman and continued on with Actionscript development. And who can blame them? ECMAScript/Javascript is a disaster. There's many JS apologists out there who think that Javascript is like some kind of totally expressive free jazz ensemble, and that everyone else *just doesn't get it*, man. The real fact is, most of these Javascript developers have only ever worked in Javascript (or PHP...tomato, tomato) and don't see the performance/efficiency gains of moving to a language with modern features. It doesn't help that browsers are putting nitrous and rocket packs on what is effectively a '78 Pinto; it tends to mask the fact that the language is a hurtling fireball of death. Hey, I sympathize with JS developers. They've been working with the same screwdriver for 12 years. You get used to the tool. Actionscript developers went through the same thing with the intro of AS 3.0, when it moved to a strictly-typed environment with many new language features. But you know, Adobe had the cojones to do that and risked pissing off its developers. Unlike the ECMAScript standards committee.
And so here we are sadly, with a language that has becoming the de facto web language, that hasn't changed much at all in 12 years. A language mostly unsuitable for OOP development. A language that's a pain to debug. A language lacking basic, basic features. It's a '78 Pinto with some racing stripes and a jet engine strapped to the top. But it's totally paid off!
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
Jehovah be praised, Oracle was not selected
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.
Hikery.net - The best hiking site ever. Made by yours truly.
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 plow through it in real time. This thing would probably take 2 weeks to play the 1st minute of a song on a p200.
Yep, we can write an mp3 decoder in javascript. But, should that really be our goal?
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.
Maybe, but that doesn't mean the GP is wrong. The design of JavaScript borders on absurdity. It's a terrible language.
And so on.
As someone who programs regularly in half a dozen languages and knows way more than that, in my opinion, JavaScript is the absolute worst of the non-esoteric modern scripting languages. I would much rather code in Perl, and I've grown to really despise Perl over the years, so that's saying something.
Heck, I'd just about pick BF or whitespace over JS. That said, as an output target for LLVM, I'm okay with it.
Check out my sci-fi/humor trilogy at PatriotsBooks.
Listen to something with an opening speech over silence, like "Eve of the War" (Track 1, Disc 1) from "Jeff Wayne's Musical Version of War of the Worlds", or the bass-heavy opening to "Angel" from Massive Attack's "Mezzanine". You can hear some odd ringing/distortion type effects. Chances are this can be corrected, but I also noticed in the code a fair amount of loop unrolling and table flattening to increase speed. A nice touch, but it does tend to bloat the download a little. Admittedly, it's only text (Which, of course, is highly compressible), but still.
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 boilerplate code becomes necessary to achieve them. You can't have everything,.
It uses the same symbol for addition and string concatenation, leading to the necessity of ugly hacks like parseInt() that could just as easily be done transparently if the two (conceptually dissimilar) operations had separate symbols.
Turning a string into a number is an information-losing transformation. In my book, such transformations should never occur automatically, so parseInt() is IMO better than automatic conversion.
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.
This is an issue with the design of the web browser object model, not javascript itself. To be frank, allowing multithreaded web pages would be a nightmare for browser developers, and is not something I would have expected in any reasonable timeframe. The fact that it is supported (sort-of) by HTML5 came as quite a shock to me.
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 design makes the use of those functions very, very cumbersome, to say the least.
This is only an issue because you're doing it wrong. JS supports closures, which means you do not need a parameter to pass context data to your callback. You do it like this:
function setCallbacks(object, context) // code that uses context
{
object.callback = function () {
};
}
Or like this:
function bindMethod (fn, object)
{
var boundFn = fn;
var boundObject = object;
var outerargs = arguments;
return function () {
var newargs = Array (outerargs.length - 2 + arguments.length);
for (var i = 0; i < outerargs.length - 2; i ++)
newargs[i] = outerargs[i + 2];
for (var i = 0; i < arguments.length; i ++)
newargs[i + outerargs.length - 2] = arguments[i];
return boundFn.apply (object, newargs);
}
}
object.callback = bindMethod(context.method, context, "additional parameters go here");
This turns the object callback into an invocation like context.method(context, "additional parameters go here", [parameters that would normally be passed to the callback).
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.
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 design makes the use of those functions very, very cumbersome, to say the least.
Yep, as I thought: complaining over the lack of pet paradigms and refusing to learn new ones. You in particular also seem to prefer syntactic handholding to dynamism: an odd case since the arguments you make sound like those of someone who favors PHP. Rather than learn prototype-based OO and closures, you prefer more rigid, static techniques.
It uses the same symbol for addition and string concatenation, leading to the necessity of ugly hacks like parseInt() that could just as easily be done transparently if the two (conceptually dissimilar) operations had separate symbols.
Here you mostly have a point, though I'm not sure how much benefit changing to a dot really gains.