Forgot your password?
typodupeerror
Chrome Firefox Music The Internet Technology

JavaScript Decoder Plays MP3s Without Flash 250

Posted by Soulskill
from the race-to-easy dept.
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.
This discussion has been archived. No new comments can be posted.

JavaScript Decoder Plays MP3s Without Flash

Comments Filter:
  • It works! (Score:2, Funny)

    by drsmack1 (698392)

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

    Carry on.

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

      • by Kalriath (849904)

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

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

  • Now if only the pr0n industry would hurry up and get with the program.
  • mp3? Acrobat! (Score:5, Insightful)

    by Joce640k (829181) on Friday June 17, 2011 @02:48PM (#36478240) Homepage

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

    • Re:mp3? Acrobat! (Score:4, Interesting)

      by ByOhTek (1181381) on Friday June 17, 2011 @03:05PM (#36478456) Journal

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

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

    • by Xelios (822510)
      Apparently the Firefox team is working on this [physorg.com] right now.
  • by Nimey (114278) on Friday June 17, 2011 @02:51PM (#36478296) Homepage Journal

    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.

  • 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 (Score:4, Insightful)

      by Dishwasha (125561) on Friday June 17, 2011 @03:00PM (#36478404)

      Not having to have a native mp3 decoder codec on your machine. Also being javascript it is theoretically compatible across all platforms that the browser supports, particular those that may not have native mp3 decoder codecs. The HTML5 standard isn't attempting to establish a standard for codecs. Not saying it's worthwhile or anything, just pointing out potential benefits as you requested.

    • Re:Err (Score:4, Informative)

      by BZ (40346) on Friday June 17, 2011 @03:41PM (#36478872)

      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.

      • by iluvcapra (782887)

        Gecko does not support MP3 in HTML for exactly the same reason it doesn't support H.264 in : it's patent-encumbered and you have to pay licensing fees to use it.

        They could just divert and use the codecs that are included with the OS and already licensed by the OS vendor, be he Microsoft or Apple, and that would cover 90% of cases. However, they probably wouldn't do that because it would make the Linux version less competitive by comparison, because many Linuxes don't have codecs or they're an additional install, and Mozilla would rather have an equal less-functional playing field between the ports of Gecko/Firefox than have versions that competed with each other o

        • by BZ (40346)

          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.

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

    • What's cool about this is that at least for audio, it's actually efficient enough that we can stop caring about whether browsers support a given codec. Maybe use <audio> when supported, fall back to pure JS when it isn't.

      All that without relying on any plugins, which means the entire process can sit inside the same sandbox browsers have been building for years.

      What we had before this required users to download and install software, and give it full rights to the machine, in order to play back media. I

  • by TRRosen (720617)

    anyone?

  • It's coming (Score:4, Funny)

    by TRRosen (720617) on Friday June 17, 2011 @02:59PM (#36478390)

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

    • by idontgno (624372)

      Hotjava. [wikipedia.org] A browser which could run Java applets, written in Java.

      On all the Sun servers I ever administered, I ran that browser just long enough to download and install Mozilla. (Yeah, it was the IE of Unix browsers, for the simple reason that it was pretty limited.)

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

  • by Wrath0fb0b (302444) on Friday June 17, 2011 @02:59PM (#36478392)

    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!

    • by Shados (741919)

      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 would

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

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

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

      • by Nadaka (224565)

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

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

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

            • by Nadaka (224565)

              In the mid 1990's, more or less.

              • by GCsoftware (68281)
                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.
                • by Nadaka (224565)

                  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.

          • And this matters how exactly? Please be specific.

    • by djdanlib (732853)

      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

    • by julesh (229690)

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

      Really? [evo.co.uk]

  • by Dracos (107777)

    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.

  • by xded (1046894) on Friday June 17, 2011 @03:45PM (#36478914)

    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?

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

  • by JonySuede (1908576) on Friday June 17, 2011 @03:59PM (#36479064) Journal

    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

    • by adolf (21054)

      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.

  • by McBeer (714119) on Friday June 17, 2011 @04:03PM (#36479096) Homepage
    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.
    • by nschubach (922175)

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

    • by rabtech (223758)

      It's cool that somebody got this working. That said, looking at this sort of things further enforces my belief that we're all barking up the wrong tree by going with JS+html as client side development environment of the future. Compared to a Silverlight solution, the JS player is 3.5 times larger (535kb vs 154kb), uses about 3.6 times as much CPU power (25% vs 7%), and has to have significant modifications to work in multiple browsers. Not really progress.

      I certainly agree and if I were going to deploy a website or do a project for a customer today, I wouldn't even think about using this kind of stuff. However Moore's law combined with the compsci work on making dynamic languages fast will eventually make JS a valid contender. I'm glad to see people out there pushing the boundaries of what can be done in JS, which will certainly drive further performance improvements and perhaps even future extensions to the language.

      It's a bit funny... designing a UI in HTM

    • 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 C
    • by mad.frog (525085)

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

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

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

    • 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?

    • by MrSteveSD (801820)
      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 deve
  • 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.

  • 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?

    • by robmv (855035)

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

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

  • by Tolkien (664315)
    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.
  • by Anaerin (905998) on Friday June 17, 2011 @07:36PM (#36481314)
    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.

Adding manpower to a late software project makes it later. -- F. Brooks, "The Mythical Man-Month"

Working...