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.

Comments

It works!

[drsmack1]

Actually, my subject makes me seem more excited than I am. I regret any misunderstanding.

Carry on.

Re:It works!

[ottothecow]

Why doesn't have a volume control though?

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:It works!

[drsmack1]

Would you possible be classified as "neurologically atypical" by the teams of specialists that you were paraded in front of as a young child?

March for a cure, dude.

Re:It works!

[Kalriath]

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:It works!

[RobbieThe1st]

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.

Re:It works!

[jesser]

Perhaps browsers should let you modify the volume per hostname or per tab, since they are also application platforms.

another reason to not have to use flash

[Nick]

Now if only the pr0n industry would hurry up and get with the program.

Re:another reason to not have to use flash

[Anonymous Coward]

It already did: "iPad-optimized" porn sites.

Re:another reason to not have to use flash

[Anonymous Coward]

Any site worth visiting already has html5 video tag support.

mp3? Acrobat!

[Joce640k]

I'd say that getting rid of the Acrobat plugin is far more interesting.

Re:mp3? Acrobat!

[Anonymous Coward]

That's why I use Chrome for my regular, everyday browsing. No Adobe Reader plugin required!

Re:mp3? Acrobat!

[ByOhTek]

I use foxit. There's also Okular. I probably shouldn't forget [g|k|x]pdf... Plenty of alternatives to acrobat.

Re:mp3? Acrobat!

[TerranFury]

On Windows, Sumatra is the fastest, and by far the best for use with pdflatex. Its printing is poor, so on those occasions when you actually want to print a PDF you probably want Foxit.

Re:mp3? Acrobat!

[Anonymous Coward]

Foxit and Okular are alternatives to Adobe Reader, neither is an alternative to Adobe Acrobat, which ultimately doesn't really have any legitimate alternatives.

Re:mp3? Acrobat!

[Anonymous Coward]

But a Javascript API means PDFs be much more optimized, because you don't need a software plugin loading and running in the background. And maybe now we can PDF's into a page without iframes, I imagine we will also find a way to serve the text to search engines... this is a pretty useful tool for designers

Re:mp3? Acrobat!

[Anonymous Coward]

And an office suite in the browser would be nice too.

Re:mp3? Acrobat!

[tikram]

It actually exists: PDF JS is a Javascript-based PDF decoder in development.

Re:mp3? Acrobat!

[Anonymous Coward]

Easiest way would be just integrate evince into firefox, though that increases bloat some..... there's a windows version of evince now if you want to throw acrobat away once and for all.

Re:mp3? Acrobat!

[Lunix Nutcase]

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:mp3? Acrobat!

[Anonymous Coward]

Check out pdf.js which aims to build an ISO-complaint PDF reader using JS.

Re:mp3? Acrobat!

[Anonymous Coward]

you mean something like this? https://github.com/andreasgal/pdf.js#readme

Re:mp3? Acrobat!

[Anonymous Coward]

Actually there is a project doing exactly this: Rendering pdf using Javascript! Take a looky here and at the demo.

Re:mp3? Acrobat!

[Xelios]

Apparently the Firefox team is working on this right now.

Re:mp3? Acrobat!

[layer3switch]

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 extra layer of the onion just to serve uniform data stream.

Re:mp3? Acrobat!

[Anonymous Coward]

just leaving this here... https://github.com/andreasgal/pdf.js

Re:mp3? Acrobat!

[Anonymous Coward]

<a href="yourfile.pdf">your document</a>

And then disable the pdf plugin in your browser.

It's really not that difficult.

Re:mp3? Acrobat!

[RobbieThe1st]

No, but I *will* say that JS is a lot more stable(and faster to load) than trying to run a third party plugin, mainly because the JS engine has been tweaked to work right with that version of FF/Chrome/Opera; The plugin hasn't.

Re:mp3? Acrobat!

[Anonymous Coward]

Are you talking about this: http://andreasgal.com/2011/06/15/pdf-js/ ? :-D

Re:mp3? Acrobat!

[Anonymous Coward]

http://code.google.com/p/jspdf/

Can't HTML5-compatible browsers play MP3s natively

[Anonymous Coward]

Can't they?

No Exploits

[Anonymous Coward]

The nice thing about a JS based flash / reader replacement is that it would have no obviously exploitable bugs that aren't already exposed via the JS VM anyways.
I'm still skeptical about the performance, though.

The rise of Javascript.

[Timmmm]

All this ultra-fast javascript stuff is cool.... I just wish javascript didn't suck quite so much. It's seems like writing CAD software using bash...

Re:The rise of Javascript.

[Anonymous Coward]

I used to hate JavaScript too, but now that I've learned how to actually code with it, I like it a lot. The only scripting language I prefer of JavaScript is Python.

Re:The rise of Javascript.

[fuzzyfuzzyfungus]

Arguably, with the existence of tools like the "Google web toolkit" and its analogs, which let you do the writing in some other language and then convert it to javascript for deployment in-browser, I suspect that javascript's sins against developers will become somewhat less relevant. Admittedly, it almost certainly isn't what you would design if you were asked to design a platform-independent intermediate representation for complex programs; but it is pretty much the only platform-independent intermediate representation for complex programs that you can be fairly sure that any idiot can "install" just by typing something into a browser bar...

It would have been nice if something better had been standardized; but your options pretty much break down into "javascript" or "assorted architecturally superior; but single-platform and/or deeply fucked in the code quality plugins".

Re:The rise of Javascript.

[nschubach]

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:The rise of Javascript.

[TerranFury]

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:The rise of Javascript.

[Millennium]

My guess: yet another person complaining about how JavaScript doesn't use their specific pet paradigms.

Re:The rise of Javascript.

[Nadaka]

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.

[Anonymous Coward]

I fully agree with all the issues you mentioned... but none of those would have been fixed by selecting another language back then.

Re:The rise of Javascript.

[Anonymous Coward]

It's not JavaScript that sucks, it's the dependence DOM that sucks.

JavaScript itself is a very flexible yet powerful language. I love languages such as Clojure (LISPs) and JavaScript. To me they are like LEGOs, they provide you with a small subset of basic powerful building blocks that build on one another. Although JavaScript isn't a LISP, I do appreciate it's simplicity and elegance.
When you deduce the instruction set to a small subset (lamda calc), it makes learning yet another language/environment very easy for an experienced programmer. You can spend the rest of your time designing concepts you know/want to design. The alternate is to spend an eternity learning the quirks, exceptions, short-comings and ways of a language with a verbose syntax.

JavaScript features:
first-class functions meaning functions are treated like primitive objects meaning you can pass functions around as args/params...
closures
functional
anonymous functions
prototype
object oriented (not as powerful as Java but still enough bang for most tasks)
dynamic type (some folks just don't like weakly typed, but I do)

If you are looking for a language with tons of libraries to do x, y and z, JavaScript is probably not it. If you are looking to prototype, design custom creative patterns and work on the Web, JavaScript is a solid choice. NodeJS is a beast that gives you a credible server-side JavaScript environment, however, it's still in development.

As far as the client-side JavaScript is concerned, I don't think people understand the complexities of UI philosophy. JavaScript gets a bad rep because it is the de facto language for the Web and is tied closely to the limitations of the UI advancement in the field of software development.

Some would argue UI should be a black screen with a ticker, but the truth is most folks who use computers are retarded technologically and need guidance. And achieving this is f*** hard. It exposes our lack of understanding of time and space (relativity, events, synchronization, state ...) Anyways, I don't want to diverge into a philosophical rant.

Re:The rise of Javascript.

[petsounds]

It would have been nice if something better had been standardized

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!

Re:The rise of Javascript.

[nschubach]

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, but that doesn't mean it can't do it.

Also, I'm not sure that's what he meant.

Re:The rise of Javascript.

[dgatwood]

Maybe, but that doesn't mean the GP is wrong. The design of JavaScript borders on absurdity. It's a terrible language.

• The closest thing it has to actual classes feels like a crudely bolted on hack (like Perl, but with even less syntax support).
• 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.
• 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.

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.

Re:The rise of Javascript.

[DoomHamster]

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.

IMHO, using the same symbol for string concatenation and addition is actually a fairly logical choice that many modern languages implement. The problem is that it allows you to concatenate a string and a number by just converting the number to a string. So 'blah' + 11 gives you 'blah11'. The problem, of course is that if you have input that you expect to be a number but is actually a string representation of a number you may not get what you are expecting ('1' + 1 = '11').

It forces you to pay attention to your data. I hate that. :)

Re:The rise of Javascript.

[DoomHamster]

Oh...I forgot to add that I agree with the rest of your post. JavaScript just feels annoyingly hacked together. Working with it is getting better all the time, though, and if we continue to see it used for so many things that were not envisioned when it was created, I expect we will see it modernized...at least I hope so.

Re:The rise of Javascript.

[julesh]

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)
{
    object.callback = function () { // code that uses context
    };
}

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).

Re:The rise of Javascript.

[zzyzyx]

JavaScript is actually a very fine language. It is a fully object language (unlike Java), it allows class prototypes (like Ruby), it has first-class functions, closures, exceptions, etc ... many features you'd find in modern dynamic weakly typed languages.

The actual issues with JavaScript are the lack of tools (modern IDE with completion, debugger, testing) and the browser environment you usually have to work with. But you can't really blame the language itself for that.

Re:The rise of Javascript.

[Timmmm]

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.

[Millennium]

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.

Re:The rise of Javascript.

[dgatwood]

Rather than learn prototype-based OO and closures, you prefer more rigid, static techniques.

Real closures are great. What passes for closures in JavaScript (defining a function by gluing strings together or using global variables to work around the fact that there is no good way to store any arbitrary data in the constructed function so that it will be available when the function calls it) is not.

Contrast blocks in Objective-C with the disaster that is constructed functions in JavaScript, and there's just no comparison. Don't get me wrong, blocks aren't perfect, either—I wish I could trivially make static (permanent function-local) variables into block variables—but it's a lot better than the clumsy hack that JavaScript programmers are forced to use to approximate a proper closure.

Re:The rise of Javascript.

[dgatwood]

var outerargs = arguments;
return function () {
var newargs = Array (outerargs.length - 2 + arguments.length);

Does this actually work? Every time I've tried to access a variable in the enclosing context, I've had problems with it being undefined. That said, it has been a few years since I tried it. Maybe the browsers were just buggy as all **** back then.

Re:The rise of Javascript.

[dgatwood]

I retract that comment. I've just been informed that something that I thought didn't work actually does. Not sure why it wasn't working for me in certain cases, but since I can't actually find any of my code where closures didn't make local variables available to the enclosing function, I'm going to assume that either I was doing something else wrong or it was a browser bug. *shrugs*

Re:The rise of Javascript.

[Lennie]

No the language hasn't changed much. People just didn't know what was possible.

Most of the programmers thought it was just a simple language with a lot of bad parts.

Turns out, it is actually a very flexible and effective language and you can avoid the bad parts.

Read a book like "JavaScript the good parts" or watch a video [0][1] Douglas Crockford in it, he wrote that book and the JSON-specification.

[0] http://developer.yahoo.com/yui/theater/
[1] http://www.livestream.com/etsy/video?clipId=pla_1463e546-47ed-4a93-b59a-bd52b236e8b8

Re:The rise of Javascript.

[Lennie]

I think Microsoft, Adobe and other vendors are really busy trying to change that.

Re:The rise of Javascript.

[Lennie]

I wouldn't call the solutions to 6. crazy hacks, it is just closures.

Re:The rise of Javascript.

[Millennium]

it sounds more to me like you were talking about the create_function() function in PHP, which actually does work pretty much like you described. PHP recently got closures (with some warts, like having to explicitly specify which variables are made available to the function being specified), but for a long time create_function() was the closest thing it had.

Re:The rise of Javascript.

[nschubach]

I'm not sure what you mean by #8.

JavaScript is run in order of inclusion. If I create two JS files and in the first I type:
function test() {
      this.value = 'hello';
}

In the second I type:
var tester = new test();
alert(tester.value);

It will alert 'hello.' I do not have to have that code in the same file.

Re:The rise of Javascript.

[Anonymous Coward]

The actual issues with JavaScript are the lack of tools (modern IDE with completion, debugger, testing)

I've tried a few over the past few years, and I think IntelliJ IDEA is the best of the bunch at the moment.
The completion features are comprehensive. There also seem to be enhancements to JS support each release.
For debugging, I think Chrome/Webkit tools are the best right now; I've stopped using Firebug.

audio

[Anonymous Coward]

How to play mp3s in your browser using HTML5:

<audio src="song.mp3">

What, me worry?

Re:audio

[PwnzerDragoon]

...Unless your browser doesn't support MP3. Firefox, and (I think) Opera for example.

Re:audio

[kiddygrinder]

that doesn't work in firefox or opera

Re:audio

[DaVince21]

That's "How to play mp3s in Chrome and Safari using HTML5". I'm pretty sure this script was created so Firefox/Opera/whatever else that doesn't natively support MP3 isn't left out.

Old News is old

[228e2]

Sound Manager has been doing this for years

Re:Old News is old

[Anonymous Coward]

Huh, no. Not at all. Not even close.

Re:Old News is old

[madprof]

No it hasn't. We're talking about a pure JavaScript decoder.

Re:Old News is old

[Anonymous Coward]

SoundManager:jsmad::apples:oranges

Re:Old News is old

[Anonymous Coward]

Good to see that you can't even bother reading the first FOUR words of that page (under the heading):

"Using HTML5 and Flash..."

I hope Subsonic adds a version of this

[Nimey]

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.

Re:I hope Subsonic adds a version of this

[Anonymous Coward]

Your kindle (assuming 3) can play mp3 already. Check under experimental.

Re:I hope Subsonic adds a version of this

[Anonymous Coward]

Only MP3s that happen to be on its flash storage, and only MP3s.

Re:I hope Subsonic adds a version of this

[Anonymous Coward]

But it's retarded! What do you all think the <audio> tag is for??
If your browser uses any of ffmpeg, mplayer, vlc, xine, direct show, core audio/video, etc, to implement that tag, you could even play a flac album in a rar.

PROTIP: http://en.wikipedia.org/wiki/Inner-platform_effect

Err

[The MAZZTer]

Chrome (and I'm pretty sure Firefox too) already supports MP3s without plugins, that's the purpose of the audio HTML5 tag. What is the benefit of this that the audio tag doesn't offer?

Re:Err

[Anonymous Coward]

FF does not support MP3. MP3 is a proprietary format; in order to support MP3, the Mozilla Foundation would need to purchase a license from Fraunhofer to do so.

Re:Err

[Dishwasha]

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

[amliebsch]

Great! So now instead of the browser user (or OS user) needing to purchase a license, every website does!

Re:Err

[Anonymous Coward]

When does that crap expire, anyway? GIF's patents expired and now we don't need to worry about that crap anymore; how much longer for MP3 decoding?

Re:Err

[BZ]

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:Err

[Em Adespoton]

In theory it's great... in practice, can you name a single environment that supports an HTML5 compliant browser that doesn't already bundle an MP3 codec? And what happens if the available audio is AAC, PCM or FLAC? Also, what does this do to the security model? Could someone write an "MP3" that exploits the javascript decoder?

Re:Err

[iluvcapra]

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 on features. They also have an ideological commitment to give patented formats no quarter or support, unless they meet some definition of "open" they're comfortable with, like WebM.

Re:Err

[BZ]

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:Err

[Anonymous Coward]

> Not having to have a native mp3 decoder codec on your machine

Are there platforms without native mp3 decoders? Hell, people still running on 1980's vintage Amigas have mp3 decoders coming with their OS. An Apple-II will be too slow, but I think that some point we can just cut it off and say, "for all practical purposes, everything supports mp3".

Re:Err

[Anonymous Coward]

We both know that patent is never going to expire. It'll be extended another decade or so.

Re:Err

[julesh]

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).

Re:Err

[Lennie]

It also does not solve the problem of others repacking Mozilla products. Like let's say Linux distributions.

Re:Err

[DaVince21]

It will run in Firefox, which doesn't do MP3 natively. The audio tag works arbitrarily with some formats (but most certainly with Ogg) because in the end they decided not to put in the spec what format is accepted.

Re:Err

[hitmark]

One funny thing is that Ogg audio is big in computer games. Easy to implement and no license issues.

Jerky sound

[Ricarus]

It does work indeed, but the sound is pretty jerky while the browser is loading other websites... Maybe a bug (or feature?) in the FF4 JS scheduler.

Interesting, BUT

[vga_init]

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.

Re:Interesting, BUT

[Anonymous Coward]

So you're saying that the only difference is that it's different? Brilliant! :)

Re:Can't HTML5-compatible browsers play MP3s nativ

[emj]

MP3 is patented so I'm guessing Mozilla and Opera won't pay the license fees for it..

why?

[TRRosen]

anyone?

5...4...3...2...1...Slashdotted!

[ckthorp]

And we're there.

Re:5...4...3...2...1...Slashdotted!

[Anonymous Coward]

502 Bad Gateway (nginx)

Re:5...4...3...2...1...Slashdotted!

[Anonymous Coward]

The fix is coming: https://twitter.com/#!/nddrylliog/status/81798532717228032

HTML5 and Javascript (The Emperor's New Clothes)

[Anonymous Coward]

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...

It's coming

[TRRosen]

I'm writing a browser in JavaScript that will run on itself !!!

Re:It's coming

[idontgno]

Hotjava. 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.

Re:It's coming

[maxume]

Much of the interface of Firefox is written in javascript and XUL.

It's part of the reason the extension ecosystem is so robust.

Re:It's coming

[Em Adespoton]

Ever used Cyberdog? You could run HotJava in Cyberdog in HotJava in Cyberdog....

Re:It's coming

[Anonymous Coward]

Yo Dawg, we saw that you like browsing the internet so much that we put a web browser inside your browser.

Re:It's coming

[Anonymous Coward]

Sorry, I've already written an OS inside the browser anno 2004. Which, of course, had a browser, a media player, a file browser, but it also had a real "kernel", network and storage drives, with networkfs (via JSON through a OBJECT tag [remember, the word "AJAX" didâ(TM)t even exist back then]), cookiefs, a complete GUI library, etc.

I have to admit though, that the "browser" was just an IFRAME, and the media player used the browser's media player plug-in in a very smart way.)

It even ran in IE 6! (Ok, actually, I had to go to psychotherapy for 3 years after I was done. Because of IE's ability to simulate unpredictable irrationality better than any AI ever. [Adding a dot at a semantically illegal place in the code solved a bug I worked on for 10 full 8-hour days!!] I'm serious. I wish I was kidding. :/ )

I moved on to game development in Haskell. WebDev just didn't pose a challenge anymore.

Re:It's coming

[Junior J. Junior III]

Please name your project xibit.

Re:It's coming

[Anonymous Coward]

This cries out for a "'Yo Dawg" joke which I am not going to stoop to make.

Especially since it's "sup dawg".

Re:It's coming

[psema4]

I'm writing a browser in JavaScript that will run on itself !!!

Use jsdom with node.js. Still need decent GUI bindings (Gtk is in the works IIRC), but other than that it's ridiculously easy.

Super-fast is a bit of a misnomer

[Wrath0fb0b]

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:Super-fast is a bit of a misnomer

[Shados]

Even the fastest javascript engines don't even remotely compete with modern interpreted languages (Java, C#)

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 wouldn't expect differences to be THAT large. DOM operations would be the majority of the bottleneck.

Re:Super-fast is a bit of a misnomer

[Lunix Nutcase]

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:Super-fast is a bit of a misnomer

[Lunix Nutcase]

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:Super-fast is a bit of a misnomer

[djdanlib]

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 CPU, low system load, enough RAM, no other websites open contending for the browser's JS engine's time) there are far better ways to do such a thing that can guarantee the CPU time you need. You know, like all those other audio plugins and standalone apps, which have more direct access to the audio hardware.

I do agree though that it's pretty cool to see someone actually try something so brain-wrecking as to implement mp3 decoding in Javascript. I wonder what the licensing situation is when that happens?

Re:Super-fast is a bit of a misnomer

[Nadaka]

Same for Java, but the JVM happens to be a lot more mature than the CLR and generally runs faster.

Re:Super-fast is a bit of a misnomer

[shutdown -p now]

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:Super-fast is a bit of a misnomer

[Lunix Nutcase]

Sure, Java does now. But originally Java was purely interpreted. C# has NEVER been interpreted.

Re:Super-fast is a bit of a misnomer

[amRadioHed]

Are you sure about that? When was Java ever an interpreted language?

Re:Super-fast is a bit of a misnomer

[Nadaka]

In the mid 1990's, more or less.

Re:Super-fast is a bit of a misnomer

[GCsoftware]

What? Java has ALWAYS been compiled down to bytecode, even Oak was like this - the virtual machine that runs said bytecode is a core feature of the platform. Java was NEVER an interpreted language.

Re:Super-fast is a bit of a misnomer

[Nadaka]

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:Super-fast is a bit of a misnomer

[FranTaylor]

And this matters how exactly? Please be specific.

Re:Super-fast is a bit of a misnomer

[julesh]

people that prioritize speed don't buy hybrids and people that buy hybrids obviously didn't consider speed to be a priority.

Really?

Re:Super-fast is a bit of a misnomer

[Anonymous Coward]

I would think any program can be called "interpreted" for which the binary does not contain machine language of the machine on which it is running

Just because it's not HUMAN-READABLE code doesn't mean that it's a native executable. It still has to be translated into instructions that run on your processor / operating system. Yes, it can be more efficient as a binary blob, but the overhead view looks exactly the same whether the file contains JVM bytecode, CLI bytecode, BASIC script or Perl script. A program reads the file, translates the instructions within into native machine language for the processor on which it is running, and executes them.

I understand the intermediate language is an efficient way to store the code, especially as a pre-processor ("compiler") can execute optimizations ahead of time with static analysis the way that a real compiler would. But does it matter that what comes out is in the IL bytecode? What if the IL were written in a human-readable quasi-ASM form, the way that old C compilers would write assembler files before turning them into machine code? Would you call the human-readable IL a "compiled program"?

No, of course not. That's silly. You would say "it's finished compiling when it becomes object code. This is an intermediate step." How is the CLI bytecode or the JVM bytecode any different? It still needs to be run by an interpreter. Doesn't that make it "interpreted"?

Re:Super-fast is a bit of a misnomer

[Wrath0fb0b]

For between £700,000 and £900,000, sure. I suppose you could also buy a supercomputer to run your website solely in Visual Basic.

For the rest of us with limited means, we have to chose between competing priorities.

Re:Super-fast is a bit of a misnomer

[hitmark]

Iirc, ARM chips can do java bytecode in hardware.

Re:Super-fast is a bit of a misnomer

[Anonymous Coward]

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).

I dunno, maybe it would be better to look at the code V8 spits out, rather than going with your hunches.

Yes

[Anonymous Coward]

Looks like finnaly grooveshark guys will be able to depoy iphones and ipads web apps.

Re:Yes

[GNUALMAFUERTE]

Grooveshark has already been rewritten in HTML5 ages ago. It doesn't work on Android/iPhone because they want to profit from app sales.

I predict...

[cruff]

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.

Slashdotted!

[Anonymous Coward]

That was quick.

Re:Wow!!

[haystor]

I think this was posted due to /.'s obsession with everything mp3.

LulzSecuritys' website example?

[Anonymous Coward]

Is this the java mp3 player that is in the LulzSec website?

Re:LulzSecuritys' website example?

[DaVince21]

JS != Java, so...

tag?

[Anonymous Coward]

wait, isn't that what the HTML5 tag is for?

Just because you can, doesn't mean you should.

[Alex Belits]

Now, if AutoCAD was ported to Javascript and worked on non-Microsoft systems...

To think of it, it probably would run faster and had better UI that way.

Re:Just because you can, doesn't mean you should.

[Pope]

AutoCad runs on OS X!

Re:Just because you can, doesn't mean you should.

[Alex Belits]

Only a tiny fraction of AutoCAD does, their most basic configuration. All those packages that AutoCAD is actually bought for, are Windows-only.

Is this news?

[NeoXon]

We have already have html5 h.264 video players for more than a year. Why is it news that from now on we can not only play videos (with sound, probably in mp3 format), but even sound without video?

Re:Is this news?

[NeoXon]

Sorry, I got the point. html5 video players use h.264 decoders that are most probably written in assembly or C, whilst this is a pure javascript based mp3 decoder.

Answer to "Why"

[Anonymous Coward]

I've seen a few threads started to ask: why?

Here are some ideas:

1. Convert MP3 files to another format (WAV, OGG, etc)
2. Load MP3s as sound resources (for creating sound editors, or DAWs, for example)
3. Server-side JavaScript is becoming popular (Node.js), and this provides servers with a way for decoding MP3 files (perhaps from user upload)
4. Games that use MP3s as part of the experience (analyzing beats, synching events in games to beats, etc)

Perhaps other stuff... this was off the top of my head.

Are there other ways to do these things? Of course! But now we can also do them on the web :-).

This is not the fix you're looking for...

[DoomHamster]

The fix is coming: https://twitter.com/#!/nddrylliog/status/81798532717228032

err...that tweet says:

Stuck in my hotel with no SSH access, cannot bring http://jsmad.org/ back up. Going to Starbucks.

Wrong kind of fix.

Re:This is not the fix you're looking for...

[maxume]

Now imagine a world where Starbucks provided internet access.

grooveshark

[Anonymous Coward]

Grooveshark need to get this and make ipad and iphone webapps. No more jailbreak. uhuu.

Re:Can't HTML5-compatible browsers play MP3s nativ

[Anonymous Coward]

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.

Great... if it worked.

[Anonymous Coward]

Time to debug Javascript!!!

Webpage error details

User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2; .NET4.0C; .NET4.0E)
Timestamp: Fri, 17 Jun 2011 19:17:10 UTC

Message: 'Mad' is undefined
Line: 14
Char: 1
Code: 0
URI: http://assets.jsmad.org/src/rq_table.js

Message: 'Mad' is undefined
Line: 1
Char: 1
Code: 0
URI: http://assets.jsmad.org/src/imdct_s.js

Message: 'OfficialFM' is undefined
Line: 18
Char: 1
Code: 0
URI: http://assets.jsmad.org/mhd.js

Message: 'ofm' is null or not an object
Line: 34
Char: 3
Code: 0
URI: http://assets.jsmad.org/mhd.js

Re:Great... if it worked.

[Anaerin]

Oh, that's easy. You're using IE8. Try getting a proper browser.

Re:Can't HTML5-compatible browsers play MP3s nativ

[Haedrian]

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:HTML5 and Javascript (The Emperor's New Clothes

[Intron]

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

Wrong.

[Anonymous Coward]

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.

Re:Wrong.

[Wrath0fb0b]

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 that check and still be compliant Java. So in the end, the algorithm cannot really run as fast on Java because the are simply more operations to be done (to wit, checking that (i > 0 && i absolutely immutable, it has to create a new int for 'sum' whose reference is then assigned to 'sum'. This causes the old object to be dereffed and garbage collected.

So by the time you are done adding up your numbers in Python, the interpreter has done a massive amount of work that the C version didn't, through no fault of the algorithm and only because of language design choices.

Re:Wrong.

[Wrath0fb0b]

Oh for fuck sake slashcode. Less-than isn't meant to close tags.

Re:Wrong.

[SanityInAnarchy]

That's what <ecode> is for.

HTML5 can already do this

[OverTheGeicoE]

HTML5 browsers already have support for audio file playback, depending on the browser. For example, Chrome can play MP3 and Ogg Vorbis files. Firefox 4 can play Ogg Vorbis but not MP3 due to licensing issues. Safari can do MP3 natively; Ogg Vorbis requires extensions from Xiph.org that are easily installable.

Re:HTML5 can already do this

[Anonymous Coward]

I think you answered your own question. Besides missing the point entirely. Oh and also, please read this: http://news.ycombinator.com/item?id=2665607

Ugh.

[Dracos]

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.

Power efficiency???

[goombah99]

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:Power efficiency???

[Pieroxy]

But the more you do in JavaScript, the less attack vectors you have.

The rise of javascript based malware

[Anonymous Coward]

Came along for the ride, & guess what gents: It's about to get WORSE!

Case-in-point/e.g. is "MASS MESH ATTACKS":

http://www.esecurityplanet.com/trends/article.php/3935941/New-Injection-Attack-30000-Websites.htm

* Very nasty...

APK

P.S.=> Now - SQLInjection's fairly easy to stop (via Stored Procedures usage, BIND variables usage, & removal of business logic out of front ends in general (if not blocking out redirects as I do to over 1, 444, 444++ known bad sites/servers/domains-hosts as I do via a HOSTS file, or a firewall (or even a TPL for IE, Opera's URLFILTER.INI or FireFox's methods etc.))...

This type though? Quite a bit worse

So - I sort of hate to say "I told you so", but... it furthers the case for my stating to people to LIMIT THEIR USE OF JAVASCRIPT, or be judicious in its usage @ least, as I have said for YEARS here:

http://www.bing.com/search?q=%22HOW+TO+SECURE+Windows+2000%2FXP%22&go=&form=QBRE [bing.com]

nd a decade before it here:

http://www.neowin.net/news/apk-a-to-z-internet-speedup--security-text [neowin.net]

Man - yes, I know: You NEED javascript for some sites (think e-commerce) but... the second I saw scriptable documents in say, Word & Excel docs + their macros being taken advantage of in VB-Script/VBA? I knew that scripting web HTML documents was going to be the same!

So, do take a read of the 1st URL I posted on Mass Mesh attack & its mechanics, be enlightened folks, & prepare yourselves!

... apk

Re:The rise of javascript based malware

[JonySuede]

go away host file troll

Re:Wow!!

[Anonymous Coward]

It's cool because a ubiquitous scripting language that ran slowly has been optimized (probably with JIT) so that it runs quickly enough to do things traditionally done with C or C++.

Java, anyone?

[xded]

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:Java, anyone?

[shutdown -p now]

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.

Re:Java, anyone?

[Anonymous Coward]

Because Java is bureaucratic and complex, weakly typed languages have a shorter learning curve because "you don't have to worry about types", and interpreted languages are easier to cut-and-paste your way to results.

At least superficially, these things make JS more appealing in the short run, and because people are largely allergic to learning new tricks they want to stick to the one they already know if they can possibly help it.

Re:Java, anyone?

[Anonymous Coward]

I think it's probably exactly because of the two things you mentioned. Considering Oracle's current attitude to Java implementation or patents, the last thing you or Oracle wants is Java being properly integrated in other people's software. The obvious alternative of 'plugins' are annoying and place too much development power with companies like Oracle, who don't tend to use their power in any interests besides their own.

Re:Java, anyone?

[Eskarel]

They were also a fairly huge pain in the ass to code.

That said, using Javascript for this is a fairly stupid idea.

Re:Can't HTML5-compatible browsers play MP3s nativ

[iluvcapra]

There is this thing called conditional compilation, ya know. Let alone environment-aware code paths.

Re:Wow!!

[Tarlus]

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.

tag?

[Anonymous Coward]

Eh... why not use the tag? it's in HTML5 ...

Re:Wow!!

[the linux geek]

It's always been enough to "do" things traditionally done with C/C++. The problem is that it does it one or two orders of magnitude slower.

Re:Wow!!

[Lunix Nutcase]

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:Wow!!

[Lunix Nutcase]

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.

bettter than I tought

[JonySuede]

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:bettter than I tought

[adolf]

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

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:bettter than I tought

[Anonymous Coward]

I was playing an MP3 yesterday and it took about 13% of a Pentium II 300MHz running Linux 2.4.28.

Re:bettter than I tought

[UBfusion]

That's too much.. on my Q6700 @ 2.66 and FF4.01 it was less than 5%. Something must be wrong with FF7

Re:bettter than I tought

[JonySuede]

or somethings in another tabs did something while I was pseudo-benching.

Re:bettter than I tought

[owlstead]

Turn Amish then. With a quad core processor 7-13% isn't a lot. I admit, even with Java this would normally take 1%. But honestly, who cares? As long as it trash my HDD and doesn't consume oodles of power, most users would be quite alright with that. Hell, most users even put up with trash like McAfee.

Besides that, the 486 was *just* able to play MP3 if I'm not mistaken. And you had to spring for an expensive 16 bit sound card, or you might as well skip it altogether. Of course, C/C++ decoders and sound capabilities have matured quite a lot within that time.

Re:bettter than I tought

[Anonymous Coward]

Can't you do a useful benchmark, for example usage on a netbook or mobile phone, you know the sort of devices which have far more limited processing capabilities and might actually be impacted.

For the record with FF4 on my Ubuntu 11.04 netbook (N270 Atom), it uses ~70-80% CPU. That's a bit too high IMO.

Cool hack

[McBeer]

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.

Re:Cool hack

[nschubach]

You forgot to include the 20MB+ of Silverlight libraries that need to be installed on the PC to make that 154kb file work.

Re:Cool hack

[Anonymous Coward]

(lead developer here) I agree with you only one point: currently, it's not a practical solution: it's a proof-of-concept.

However, as history as shown: 1) jsmad will be optimized 2) browsers will continue optimizing their JS engines 3) JavaScript the language will continue to improve, and maybe provide an integer type? That would make jsmad almost as performant as libmad, if not better (=I can foresee JIT optimizations trump AOT optimizations for this usecase).

It's "progress" in the sense that it pushes the boundaries of what has been done with JavaScript. Your point about plug-in (and, let's admit it, Silverlight propaganda) is completely off: you can decode MP3s with 0% CPU if you have an external chipset that does exactly that... but who would go the trouble of buying+installing the chipset? No one. This is exactly the same for coding pretty much anything with JS: I'm not particularly a fan of the language (I pretty much hate it actually) - but it's the largest thing EVER deployed ANYWHERE. Soon, FF4 will be the new IE6 - and jsmad will run on that, acceptably fast (hardware continues to get better).

You need to see the big picture and forget your commercial interests.

Re:Cool hack

[Anonymous Coward]

And a Windows machine. After all this is Microsoft's solution for open web :-)

Re:Cool hack

[rabtech]

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 HTML+CSS+JS is definitely a huge step backwards compared to almost any GUI library, but it turns out that the only way to get a bunch of humans with competing priorities to agree on a cross-platform widely supported project like this is to start really small and simple, solve a huge need, then ramp the project up as it reaches wide deployment. When you think about it, getting various vendors, open source projects, working committees, standards organizations, developers (paid, hobbyist, etc), and end-users to all agree to adopt one single piece of technology is almost impossible by definition (image trying to get everyone to agree on CSS+JS+AJAX in HTML v2). The fact that HTML+CSS+JS is so widely adopted is an amazing feat of technological and social engineering. I can only think of a handful of human endeavors that have ever come close to this eg: cell phones, electricity, fire, the wheel, etc.

It also amuses me that one private company's embrace-extend (Microsoft with the first AJAX implementation to make a more Outlook-style interface for Exchange web on IE) led open-source groups to turn embrace-extend around and create a new web standard. I think that must say something about accidental innovation being necessary for any standard to do something revolutionary, as well as the pent-up demand for a true cross-platform UI standard with backwards-compatibility and built-in abilities to run across the network.

Re:Cool hack

[HalWasRight]

I agree that this is a cool hack. But I just don't understand the fetish for JS as a language for writing software beyond the fact that it is integrated inside the browser. Ok, sure, look at the cool hacks (I liked the Google Guitar). But please please please, people, remember that statically typed languages greatly reduce the incidence of bugs. JS is a fine tool for integrating pieces of interactive code in browsers, and yes people have written some amazing large systems with it too. But just because you CAN doesn't mean you SHOULD. Frankly I value having a compiler tell me about bugs BEFORE someone manages to run a test case that breaks my code.

This is a cool hack, not a justification of using JS for being a primary development and deployment language for applications.

Re:Cool hack

[Anonymous Coward]

What file is 535kb? The only one I saw that might be that big was the *-all.js. Normally a script like that would be minimized, which would bring the size down some, but maybe not to the level of compiled .NET IL.

Re:Cool hack

[Anonymous Coward]

The JS solution will work in many places where Silverlight won't. End of discussion.

Re:Cool hack

[mad.frog]

> 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. ...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).

Re:Cool hack

[FranTaylor]

". 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:Cool hack

[FranTaylor]

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:Cool hack

[MrSteveSD]

Obviously it's very important that browsers be able to run code, and increasingly large web applications are being developed. Given that is the case, it has to be asked whether a scripting language like Javascript is the right tool for the job. Clearly the interpreters have been improved greatly, but even so, speed is a real issue. It's not the only issue though. Writing a full application (like Microsoft Word for example) with Javascript would be a pain to say the least. Static typing is important for developing large applications. It helps you catch bugs early and greatly aids analysis of the code/auto-completion etc.

One way around this issue has been to develop plugins, e.g. Unity3D for games, but many users are put-off by the need to install a plugin and if everyone embraced this approach, we would be overwhelmed by endless plugins. Google's Native Code project seems quite promising. Perhaps the future lies there.

Re:Cool hack

[McBeer]

The big picture is we're all getting on board with a language that, like you, most everybody hates and hates for a good reason :p My post wasn't intended to be Silverlight propaganda (though I do like Silverlight). I'm sure Java or Flash would have also beat the pants off a JS implementation. I just happened to find a Silverlight player to test quickly.

Re:Cool hack

[McBeer]

". 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.

No modification needed, just install it: http://www.mono-project.com/Moonlight. If Silverlight isn't your thing, Flash or Java would also be better solutions. The point wasn't that Silverlight is great; it was that JS is terrible.

Re:Cool hack

[McBeer]

In this case, maybe not a big deal. Say, however, you'd like to take an app that would normally consume 30% of your CPU and convert it to JS: Then it would require 105% of your CPU and you'll be screwed. (It's actually worse than that: I have a dual core processor, so a JS app couldn't use more than 50%, An app that would normally consume 15% would not work in JS)

I'm the first to admit that premature optimization is the root of all evil, Javascript has severe performance and functionality limitations. The language itself is arguably worse than languages that don't. This isn't like c#/java vs C. Javascript isn't easier or faster to develop in for most situations.

Re:Cool hack

[Anonymous Coward]

listening to mp3s in the browser is a definite must on a system like that.

Re:Cool hack

[Anonymous Coward]

Silverlight has been worked on for a while by a team of engineers, jsmad was thrown together by a few dudes. It will undoubtedly be unrefined. Bad comparison.

Re:Cool hack

[UBfusion]

Where did you get that 25% CPU? On my Q6700 @ 2.66 and FF4.01 it was less than 5%.

Re:Cool hack

[Anonymous Coward]

At least the js can be made to work crossplatform. Whereas silverlight is
Basically windows point. Moonlight is fairly useless at the moment. Not sure
About the osx offering. Heck even flash is more cross platform than silver light.

I basically disagree with your comment!

Re:Cool hack

[Anonymous Coward]

The fetish is partly due to its universal acceptableness and that it isn't restricted to running on the browser.

You can have:

JS on the server.
JS on the client.
JSON as a data type to exchange information between the server and client.
JSON to send/receive data from a persistent data store (couchdb for instance).

Now your entire stack is running JS. This is pretty huge for developers. Instead of learning some other server side language, some other flash scripting language, and JS you can just concentrate on just JS.

Which developer do you think is going to be more productive? The dude having to know 3-4 different technologies, or the dude who just needs to know JS?

Re:Cool hack

[Jack Greenbaum]

Which developer do you think is going to be more productive? The dude having to know 3-4 different technologies, or the dude who just needs to know JS?

The developer that uses the right tool for the job will be more productive.

That means using a language with static type checking and a productive debug environment. Learning a new system infrastructure takes time, but only finding out about easily preventable failures during testing instead of compile time costs more.

Re:Cool hack

[Anonymous Coward]

<sarcasm>Because no-one uses anything slower than a Q6700</sarcasm>

The obvious answer is he has a slower processor than you. For example, it uses 70-80% CPU on my netbook.

Fail

[yourlord]

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?

Re:Fail

[Anonymous Coward]

On my PC workstation i7 @ 3.2ghz, it was using 2-5% of a single core (8 cores here). Memory usage didn't increase at all.

Sucks to have a shitty setup I guess.

I honestly thought it would use much more CPU and was ready to trash it, but it actually uses LESS cpu than iTunes!

More XSS Fun

[Anonymous Coward]

Oh the fun that will be had with this in pen tests and porn sites alike.

Simple question to you, 7-digit NEW user (right)

[Anonymous Coward]

Troll, & the question is: What's your problem with HOSTS files?

Answer it.

Then, I'll just "blow your objections away", with ease, on a technical level (as I always do to "hosts files trolls" around here).

* My post you trolled me on has some decent information others in the field of computing ought to be made aware of, & you trolled me over it? Time to EMBARASS you... in return!

APK

P.S.=> I'll be waiting...

... apk

Re:Wow!!

[Anonymous Coward]

If it does it two orders of magnitude slower, than it doesn't really do it. This is particularly true for something like an audio decoder.

Of course you could "do it" in Ruby or Brainfuck if you define "do it" as duplicate the output regardless of how long it takes. In the real though, performance matters.

Re:Wow!!

[Anonymous Coward]

1. combine this with Amazon Cloud Drive or Google Music and no, you won't need a system player or local MP3s.
2. MP3 playback requirement is prevalent all over the web, though thankfully it's becoming less common.

How incredible

[loufoque]

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.

Re:How incredible

[Anonymous Coward]

You had a computer in 1980 that could play mp3s?

Re:Can't HTML5-compatible browsers play MP3s nativ

[westlake]

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, AVC/H.264 Licensees

Re:Wow!!

[Lunix Nutcase]

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:Can't HTML5-compatible browsers play MP3s nativ

[Lunix Nutcase]

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.

What Output API Does it Use?

[jubei]

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:What Output API Does it Use?

[robmv]

I think they are using Mozill Audio Data API and that must be the reason it only work currently with Firefox, until the API advance from experimental to something more standard

Re:Wow!!

[unrtst]

Um... pandora isn't exactly unpopular, and uses flash to play music to many many people.

IMHO, the roadblock to moving away from flash isn't that local media players were hard to work with or something like that... it's because pandora can lock down the stream more using flash. If it were javascript delivered to the client to play the stream, it'd make it easier to hack, and come at a performance hit compared to flash, and would lack all the other goodies flash gives them.

For any service were I can get access to the mp3's (cloud drive included), I'd much rather use my local media player and have it support that as a data provider.

I agree with where you ended up ("Except that this does absolutely jack and shit to phase out flash for almost anyone"), but not with how you arrived at that conclusion. There are loads of good uses for a web based media player (or media player controller), but this is unlikely to have a substantial impact on any of those for many other reasons.

Re:Can't HTML5-compatible browsers play MP3s nativ

[BitZtream]

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 browser to work. How do you intend to draw to the screen? You realize that Firefox uses OS specific APIs for doing its IO right? Its not like it uses kpoll for sockets on Windows or OSX. The browsers job is to provide a common interface between the OS and the web so that the web can be experienced on the OS.

Your app won't be doing any graphics or sound without being tightly coupled to the OS, even if you're using some API like OGL and OAL, they are still tightly coupled with the OS, you're just ignoring that fact for the sake of your point of view.

Awesome

[GrumpySteen]

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.

Re:Awesome

[RobbieThe1st]

Same with flash... But I don't see it thanks to NoScript blocking Flash and Media tags. I'm sure whatever output API is used can be similarly controlled, solving the problem.

Re:Can't HTML5-compatible browsers play MP3s nativ

[SanityInAnarchy]

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 back to hacks like this when they aren't supported.

Oh, by the way? LEARN TO SPELL & WRITE

[Anonymous Coward]

The CORRECT spelling & phrase is not what you wrote:

http://slashdot.org/comments.pl?sid=2234578&cid=36429134

"Gotos have there place" - by JonySuede (1908576) on Monday June 13, @05:10PM (#36429134)

It's THEIR, indicating possessive, not THERE, you blatantly obvious illiterate dolt!

(LOL, If that's how you write english? I'd HATE to see your code you write (that is, IF you even do)).

APK

P.S.=> Payback's a BITCH, yea? See here, and I am waiting on your trolling behind to show up there:

http://tech.slashdot.org/comments.pl?sid=2248218&cid=36479278

Just so I can publicly make you look more stupid than you already have clearly evidenced yourself to be!

... apk

Learn to SPELL & WRITE, properly, illiterate d

[Anonymous Coward]

The CORRECT spelling & phrase is not what you wrote:

http://slashdot.org/comments.pl?sid=2234578&cid=36429134

"Gotos have there place" - by JonySuede (1908576) on Monday June 13, @05:10PM (#36429134)

It's THEIR, indicating possessive, not THERE, you blatantly obvious illiterate dolt!

(LOL, If that's how you write english? I'd HATE to see your code you write (that is, IF you even do)).

APK

P.S.=> Payback's a BITCH, yea? See here, and I am waiting on your trolling behind to show up there:

http://tech.slashdot.org/comments.pl?sid=2248218&cid=36479278

Just so I can publicly make you look more stupid than you already have clearly evidenced yourself to be!

... apk

Re:Wow!!

[JavaBear]

I can only assume you are either full of it, or running it on a very old system with an outdated browser.

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.

Incredible!

[Anonymous Coward]

And it only uses up as much CPU time as playing a 720p video!

The "druggie" JonySuede keeps misspelling

[Anonymous Coward]

LMAO - please: We're NOT here to "decipher your 'hieroglyphic'" troll-speak, ok?

LEARN TO WRITE & SPELL PROPERLY!

---

Your 2nd example of "murdering the english language" is here:

http://slashdot.org/comments.pl?sid=2230314&cid=36415174

---

Your first was here & where I pointed it out in this thread:

http://slashdot.org/comments.pl?sid=2248218&cid=36480036

---

(So - Keep doing those drugs & drinking fool - they're clearly doing "WONDERS" for you!)

APK

P.S.=> And, meet my challenge & question of what your problem is on HOSTS file also, troll... I'll just blow away your objections w/ ease, & further embarass the "trolling likes of YOU" (garbage online = trolls like yourself, especially clearly illiterate ones).

... apk

Repost.

[Anonymous Coward]

Please try reposting the algorithm.

Re:Repost.

[Wrath0fb0b]

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 \LessThan N; ++i)
        sum += 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 that check and still be compliant Java. So in the end, the algorithm cannot really run as fast on Java because the are simply more operations to be done (to wit, checking that (i > 0 && i \LessThan N) must be done once per iteration.

Now that's not much a slowdown but let's suppose we go a further level up and write it in python (trick question, python already has a 'sum' builtin, also that builtin effectively uses the C version) then it becomes even slower. Each time through the loop, the interpreter must check the types on both sides of the '+=' to make sure they are still ints. Why? Because I can override the int::operator-left-addition to return a string. Now we look up int::operator-left-addition(int) and call that function, passing the two references. That function 'unboxes' the ints (copies them from the heap onto the stack), performs the addition and then creates a new int object on the heap to store the result. Why a new object, because ints in Python are absolutely immutable -- in python, A += B is actually semantic sugar for A = A + B. After we are done with this reference, the old 'sum' object has its reference count decremented and is garbage collected, releasing the memory it held on the heap.

So by the time you are done adding up your numbers in Python, the interpreter has done a massive amount of work that the C version didn't, through no fault of the algorithm and only because of language design choices. Optimizing around those choices is a lot harder than writing a language optimizing for speed in the first instance. On the other hand, I love Python and use it extensively where I think it's appropriate, which is for many non-performance intensive tasks.

I played MP3's without flash in 1997.

[Kaz Kylheku]

Snore ...

Re:Simple question to you, 7-digit NEW user (right

[Vegemeister]

I don't know what his objection to hosts files is, but mine is this:

O(n)

More than slightly different.

[SanityInAnarchy]

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. It's similar superficially, I suppose, but it has massive practical differences.

Fallback for .

[SanityInAnarchy]

Try <audio>, if they don't have MP3 support, fall back to this.

Before this, the fallback would've been Flash, which sucks.

Bytecode

[Anonymous Coward]

Remember when writing a raytracer in JavaScript was a joke? Why is it being taken seriously now? I still think the scripting "language" of the web should be a bytecode like Java's or .NET's. It'd have exactly the same functionality as JavaScript, but you can write it in any language you can compile to it (including JavaScript), instead of trying to hack JavaScript into more than it was designed for, or compiling a different language into "human-readable" code before the JS engine JITs it back. Now I know some people will get upset that you can't read the compiled code any more, but honestly, how often do you do that with JavaScript, and anyone who's ever used .NET Reflector can tell you that most bytecode is basically an open book anyway.

Wow.

[Tolkien]

I remember my 486 DX4 100MHz only barely being able to play MP3s. My entire computer would freeze up for the duration of the song though it played flawlessly. I'm not 30 yet and I feel old. Damnit.

Re:Learn to SPELL & WRITE, properly, illiterat

[Tolkien]

If you're going to bother signing your posts AC "apk" why don't you just create an account? Honestly, it baffles me.

Great, but has some audio artifacts

[Anaerin]

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.

Re:Great, but has some audio artifacts

[Anonymous Coward]

(lead jsmad dev:) the player doesn't do any dithering, so the artifacts you're hearing are probably are probably because of quantization errors. Read http://en.wikipedia.org/wiki/Dither for more information.

Re:Wow!!

[Anonymous Coward]

Every one I've seen incl. Amazon. Which browsers support MP3? Chrome only? FF can't. Chromium can't. IE doesn't. Few sites embed players anymore because it's horrible practice -- it doesn't work across browsers, it's tied to the operating system, and it's more insecure than even Flash (because it exposes untested codecs to the web).

Explain & DEFINE that, with specifics

[Anonymous Coward]

See subject-line above, & relate it to HOSTS files, please, & thanks (could be interesting)...

APK

P.S.=> So you know - My HOSTS file? It's CONSTANTLY "automagically" updating from roughly 15 known & reputable sources online (such as Norton SafeWeb for example), & I don't have to raise a finger to do it either... FULLY AUTOMATED by a program in Python & doing so constantly!

(I moved from my Delphi model, because python is write once run anywhere runtime driven - made more sense in the long haul)...

1,444,444++ known bad sites/servers/domains-hosts blocked out along with adbanners, & growing automagically, for both added SPEED & SECURITY online ("layered security", best thing we have going in fact currently)

...apk

Re:Stupid

[thegarbz]

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:Wow!!

[GNUALMAFUERTE]

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:Wow!!

[GNUALMAFUERTE]

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.

No IE or Safari? What's the point?

[Anonymous Coward]

Firefox and Chrome can already play ogg without a plugin. Javascript hacks are only needed for older browsers like IE. If this only works in Firefox and Chrome, then what's the point?

Big fan of JS

[Boxtracod]

It is good that we can now play MP3 in FF. I remember being stunned when I found FF could only play WAV!

already can play mp3s without flash

[Anonymous Coward]

Debian can play mp3s without flash using xfmedia. Not sure why you need flash to play mp3s. Codex, needed. Flash, not so much.

No answer? I thought not - always 10 steps

[Anonymous Coward]

ahead here is why, lol (read your mind maybe? Perhaps!)... I waited on your reply, none came so... here I am!

APK

P.S.=> So, that "all said & aside" here? I'll be straight with you on YOUR point in fact:

Your "objection" in fact, USED TO BE 1 OF MINE! I couldn't keep up with the entries manually, & I was concerned there weren't enough entries because I didn't HAVE the data, or all of it that was possible, & I knew it!

(What's possible that is, like any security measure - it's "reactive", in defensive security).

BUT, the speed part, blocking adbanners & such? A lot more 'finite'...

Now - The "bad guys who make malware?? They're @ it, faster than ever, & IF you multiply the 1.5 million entries I have by the cost of domain/hostname registrations? They're spending monies to do it (but, they must be "hauling in" a LOT more than they're putting out, else, why be in the business of it, right??)

Anyhow/anyways:

However & then again, THAT is what computers are BEST @ imo: AUTOMATION which is why I co-built (w/ my nephew - I just improved the hell out of it a lot more lately) the Delphi system for it around 2002-2006, & last yr. the superior PyThon one.

Computers are great as you know, for automation of manual drudgery + laborious tasks (hence why they were used in things like code breaking), & catching up to the "uncatchable"...

(Nicest part here, is that the more VALID + REPUTABLE sources I find (such as DNSBL & router filters too I have converted as well as my own researches + hosts files of others?), the stronger the HOSTS file & firewalls rules tables I build, get - which is all the time... & that's happening all the time, moreso lately than ever!)

I.E.-> Big "O" problems? They get a lot smaller for me, all the time & so far, it's been working out well over the years!

... apk

A shame ...

[Anonymous Coward]

It's a shame they haven't chosen to implement a decoder for OGG or FLAC instead.

someone please enlighten me

[Tooke]

Why is this paired with the chrome image? It's not about chrome, and chrome isn't even mentioned until the second half of the last sentence. If there isn't a suitable image, the firefox one would make more sense as it's the browser that the decoder actually works in.

Re:someone please enlighten me

[caspy7]

Mod parent up for truthiness.

http://www.candoprinting.com

[Anonymous Coward]

Folder Printing.

Addendum: You're against antivirus/antimalware

[Anonymous Coward]

as well, based on what I *think* is what you're saying.

Simply because trying to stay "ontop" of them is as 'asymptotic of an approach' (lacking a better expression here) as what you're stating HOSTS files update maintenance is (this is what I drew from you, correct me IF I am off/wrong here & I am mistaken)...

However: AntiVirus/AntiSpyware technology? They're both LARGELY REACTIVE as well as far as keeping abreast of all threats possible via "mugshots of known offenders" so-to-speak, which is much like my efforts for decades now, in populating HOSTS files &/or Firewall rules tables are...

(In the end, much computer security, is - the truly only "proactive" (note the quotes, I lack a better expression here) types I know of for a local machine are system hardening guides -> http://www.bing.com/search?q=%22HOW+TO+SECURE+Windows+2000%2FXP%22&go=&form=QBRE such as those & following them + their tips/tricks/techniques points, to the letter really)

APK

P.S.=> Anyways/anyhow - I wish you showed back up, you may have points I could or should think about... provided I did not cover them in my 1st reply to you (but, I think I did, via automation & updates constantly here to my HOSTS file from MANY reputable & reliable sources)

... apk

UGH: Tiny ADDENDUM to my addendum

[Anonymous Coward]

I forgot to note HEURISTICS (it's a "sort of" exception to the rule I am noting & you too about O(n) Big "O" weaknesses of HOSTS entries to block bad sites, & antivirus/antispyware mugshots via signatures of KNOWN malwares)!

(Except, that has HEURISTICS also has its OWN "problems", see below... & I am correcting for this statement of mine now with what's in my p.s. below):

"However: AntiVirus/AntiSpyware technology? They're both LARGELY REACTIVE as well as far as keeping abreast of all threats possible via "mugshots of known offenders" so-to-speak, which is much like my efforts for decades now, in populating HOSTS files &/or Firewall rules tables are..." - by Anonymous Coward on Saturday June 18, @12:18PM (#36485684)

* There - All done, & it's "all good" now... addendum/correction's below!

APK

P.S.=> Funniest part is? I didn't omit that in another post of mine here today in fact & that was earlier than my exchange with yourself here (especially in my reply about you being against antivirus/antimalware in fact, which I am adding to now):

PERTINENT QUOTE/EXCERPT:

"it's REACTIVE TECHNOLOGY (mostly, unless you consider heuristics "best guess" tech (ala "smells like a duck, tastes like a duck - it must be a duck") but, that opens up the possibility of FALSE POSITIVES)." - by Anonymous Coward on Saturday June 18, @12:18PM (#36485684)

FROM -> http://it.slashdot.org/comments.pl?sid=2249022&cid=36485684

I don't like leaving any stones unturned/unaccounted for, OR being inaccurate is all!

... apk

TRUTH ABOUT JEWS FROM THEIR TALMUD

[Anonymous Coward]

http://www.waylanderskeep.com/2009/12/jewish-talmud-quotes/

Goyims, Gentiles, and Akum are anyone non-jewish.

===

1. Sanhedrin 59a: "Murdering Goyim is like killing a wild animal."

2. Abodah Zara 26b: "Even the best of the Gentiles should be killed."

3. Sanhedrin 59a: "A goy (Gentile) who pries into The Law (Talmud) is guilty of death."

4. Libbre David 37: "To communicate anything to a Goy about our religious relations would be equal to the killing of all Jews, for if the Goyim knew what we teach about them, they would kill us openly."

5. Libbre David 37: "If a Jew be called upon to explain any part of the rabbinic books, he ought to give only a false explanation. Who ever will violate this order shall be put to death."

6. Yebhamoth 11b: "Sexual intercourse with a little girl is permitted if she is three years of age."

7. Schabouth Hag. 6d: "Jews may swear falsely by use of subterfuge wording."

8. Hilkkoth Akum X1: "Do not save Goyim in danger of death."

9. Hilkkoth Akum X1: "Show no mercy to the Goyim."

10. Choschen Hamm 388, 15: "If it can be proven that someone has given the money of Israelites to the Goyim, a way must be found after prudent consideration to wipe him off the face of the earth."

11. Choschen Hamm 266,1: "A Jew may keep anything he finds which belongs to the Akum (Gentile). For he who returns lost property (to Gentiles) sins against the Law by increasing the power of the transgressors of the Law. It is praiseworthy, however, to return lost property if it is done to honor the name of God, namely, if by so doing, Christians will praise the Jews and look upon them as honorable people."

12. Szaaloth-Utszabot, The Book of Jore Dia 17: "A Jew should and must make a false oath when the Goyim asks if our books contain anything against them."

13. Baba Necia 114, 6: "The Jews are human beings, but the nations of the world are not human beings but beasts."

14. Simeon Haddarsen, fol. 56-D: "When the Messiah comes every Jew will have 2800 slaves."

15. Nidrasch Talpioth, p. 225-L: "Jehovah created the non-Jew in human form so that the Jew would not have to be served by beasts. The non-Jew is consequently an animal in human form, and condemned to serve the Jew day and night."

16. Aboda Sarah 37a: "A Gentile girl who is three years old can be violated."

17. Gad. Shas. 2:2: "A Jew may violate but not marry a non-Jewish girl."

18. Tosefta. Aboda Zara B, 5: "If a goy kills a goy or a Jew, he is responsible; but if a Jew kills a goy, he is NOT responsible."

19. Schulchan Aruch, Choszen Hamiszpat 388: "It is permitted to kill a Jewish denunciator everywhere. It is permitted to kill him even before he denounces."

20. Schulchan Aruch, Choszen Hamiszpat 348: "All property of other nations belongs to the Jewish nation, which, consequently, is entitled to seize upon it without any scruples."

21. Tosefta, Abda Zara VIII, 5: "How to interpret the word 'robbery.' A goy is forbidden to steal, rob, or take women slaves, etc., from a goy or from a Jew. But a Jew is NOT forbidden to do all this to a goy."

22. Seph. Jp., 92, 1: "God has given the Jews power over the possessions and blood of all nations."

23. Schulchan Aruch, Choszen Hamiszpat 156: "When a Jew has a Gentile in his clutches, another Jew may go to the same Gentile, lend him money and in turn deceive him, so that the Gentile shall be ruined. For the property of a Gentile, according to our law, belongs to no one, and the first Jew that passes has full right to seize it."

24. Schulchan Aruch, Johre Deah, 122: "A Jew is forbidden to drink from a glass of wine which a Gentile has touched, because the touch has made the wine unclean."

25. Nedarim 23b: "He who desires that none of his vows made during the year be valid, let him stand at the beginning of the year and declare, 'Every vow which I may make in the future shall be null'. His vows are then invalid."

Not So New

[Anonymous Coward]

Yahoo already has a javascript mp3 player, its called Yahoo Media Player

prescription glasses

[Anonymous Coward]

Thanks for posting, definitely going to subscribe! See you on my reader.

prescription glasses