Android 4 is bringing new treats for html5 audio. A long broken HTML5 implementation now gets fixed with its own mp3 playback mechanism and GUI layer. While I can see some massive improvements, there's still some bugs. It's a bit unstable and audio steaming can freeze up the browser. The UI helpfully features two pause buttons (the one on the right is non functioning). Streeme users on android are in for a great new experience though. This implementation is right up there with chro......

 

Fuuuuuuuuuuuuu.....

You, too, can watch the progress of these bugs here:

http://code.google.com/p/android/issues/detail?id=21084

http://code.google.com/p/android/issues/detail?id=21085

 

Amazon's got serious moxy releasing a cloud based music client well ahead of their competitors, and I'm starting to see the other big boys, Apple and Google, gearing up to surprise us with long overdue music locker services. Almost immediately after launching Cloudplayer, however, the US record companies began to itch and wonder where Amazon's paperwork was. Today a memo from the Amazon PR was posted on Ars Technica and Apple Investor:

We do not need a license to store music in Cloud Drive. The functionality of saving MP3s to Cloud Drive is the same as if a customer were to save their music to an external hard drive or even iTunes.

Source

Strong language and the first shot across the bow of the music industry. Amazon is confident that their model is sound and likely air tight, but some music execs were caught off guard by the product launch and are incredulous Amazon would distribute without acquiring licensing agreements. I'm now keenly following this topic, because there's a real chance that Amazon may find themselves in a situation where they'll be making new case law that could directly affect Streeme. I'm still of the opinion a securely mounted data store (disk, flash or even network based), password protected and reasonably available only to the end user is going to be hard to make out as a sharing platform or require special licensing beyond the purchase of the original music. Let's just hope that Amazon did their homework and can at least pin down some boundaries for music locker services in the future.   

 

 

Mobile Safari (iOS4.2+) no longer supports HTML5.

While the dust settles on a final specification for HTML5, I'm noticing a very dangerous (and annoying) trend: broswer vendors that are implementing HTML5 into their product are modifying the functionality to suit their own needs. Nearly a year ago, the HTML5 API for audio and video was fairly agreeable. The limitations were obvious, but there were great degradable options for browsers that supported flash and some good workarounds in the community for puzzling or missing API pieces. You had firefox only supporting OGG format, so in comes flash/jplayer for mp3s (you can thank license/patent trolls) Source; Chrome breaking the video tag in version 10, so you can only use audio tags, which have a less desirable seek bar Source; ie9 beta being built without controls until recent release candidates. All in all, making audio and video work in HTML5 has been a big mess. Now there's a new layer of horror.

The most recent offender is a big annoyance: In iOS 4.2+, Apple has intentionally disabled the play() and autoplay commands in Mobile Safari on media elements:

In Safari on iOS (for all devices, including iPad), where the user may be on a cellular network and be charged per data unit, preload and autoplay are disabled. No data is loaded until the user initiates it. This means the JavaScript play() and load() methods are also inactive until the user initiates playback, unless the play() or load() method is triggered by user action. In other words, a user-initiated Play button works, but an onLoad="play()" event does not.

Source

In effect, Apple has decided to modify the HTML5 spec under Mobile Safari on the iPhone and iPad with the side effect of making a nice user experience with autoplaying media impossible. They believe their users are too inexperienced to understand that they're about to use the data network to listen to music or watch a movie (maybe even play html5 games). Not only does something smell funny about this justification, it weakens the HTML5 platform. Those in control of the browser now see it as optional to comply with the specs, because it suits their perception of the habits of their user base. 

Apple has forked the HTML5 specification and actually degraded its functionality from previous versions of iOS (4.0 and 4.1 both support the correct API). For example, how does an HTML5 game that uses sound work? Where would the first play button be? Simply turning off any response to autoload or play later in the chain of functions javascript functions violates encapsulation and cripples more advanced uses of audio and video tags. In my application, I want a smooth transition from one view state to another while the music plays - I can't just put an inline javascript play event in the button. I would like to see a solution to this issue that doesn't break html5 multimedia systems. Perhaps a setting or an long term opt in to specific site would be a better way to handle this issue.

This is a slippery slope though. If Apple is allowed to deviate from the standards set out in the HTML5 spec, what's stopping other browser vendors from fragmenting HTML5 even further? It seems that there's already enough conditionals in my code to handle codec support and streaming, I don't want another set of regressions to test if HTML5 tags still work. Is HTML5 at risk of being sabotaged here? Definitely.. how far will it slide - That's up to the W3C and browser vendors. I really hope that this isn't going to be a fight with each browser refresh.

Streeme, a free and open source HTML5 based music server, is getting some pretty serious polish these days. Thanks to some great contributors, the project has new locales and some helpful updates for usability.

What I'd like to talk about today is something that will set Streeme apart from a lot of the competition and that is resuming. Streeme now has the ability to pick up your music from wherever you left off. This is particulary helpful for mobile devices and clients that don't have the ability to seek through music quickly. If you're listening to a 4 hour mix, chances are you don't only want to hear the first 20 minutes every time you play it. Streeme uses FFMPEG and Javascript to easily begin playback from your last known position. Give it a try and see how far HTML5 has come in the last year.

 

So what changed in 0.4?

Added a feature to resume playback of the last played song - feature requires FFMPEG

Added translation for Danish and Khmer

Fixed Shuffle for SQLite and Postgres storage engines

Increased the contrast of the shuffle button

Strengthened security - denied all access to user config folders in case of a botched install

 

 

Try Streeme here:

http://www.streeme.com

I've been working on a web based music streaming server and I kept running into a common complaint, that the parsing the iTunes file with an off the shelf plist reader is a resource hog. Well it doesn't have to be! PHP has a fantastic built in tool for dealing with the iTunes plist serialization format that will once and for all parse your library in the most resource friendly way possible. 

Apple has a resonable demonstration of copying an itunes file directly to memory in Apple's PHP hints , but there are some major issues here. Most of the code is in PHP4 with a lot of outdated, procedural techniques that leaves much of the program on the global scope. The real gem here is the XPAT/SAX (Simple Api for XML) example, because of an important consideration - it can stream through an XML file instead of preloading it. So the goal here is to make a PHP5 compliant, OOP friendly, streaming iTunes Music Library.xml reader - so let's go!

This is what we want. It works a little like the fetch_row methods for mysql: while there are still records, keep on flushing them out to your database, application's output buffer or cache. Each loop destroys the previous array to conserve memory and work extremely quickly. This nice frontend has a fairly short and sweet class accompanying it:

So let's have a quick at the insides of this class. XML serialization and parsing is a job handled fairly easily by most programming languages nowadays, but PLIST ( Apple's property list definitions ) is a very strange duck. each key and value are surrounded in their own tags, so you end up having to make sens of pairs that aren't directly related except by adjacency <dict><key>Name</key><string>08 - Untitled 8</string>...</dict>. What this class does is it reads the XML line by line and fires off events when it thinks its found useful data. when these events occur, you can reorganize the output into a familiar associative array.

Here's what the output looks like for each song:

The events key to breaking up this file are <dict>, the elements that start and end the items; <key/><type/> the values that break up the key value pairs and <playlist>, which signifies the end of all of the tracks in the file. The SAX implementation in PHP isn't too bad - it gives the developer a line by line XML  parser with all the smarts of a generalized XML parser like simplexml, so you won't end up being left to handle string manipulation. I've actually gone through and tested Apple's example code and made quite a few changes to their original to handle UTF-8 characters and to make it fit into an object oriented project a little nicer. If you have questions about any of this stuff, just leave a comment below.

This code example is part of the Streeme music server project. If you're looking for a free and open source way to stream your music library over the web, check out Streeme on Google Code or on Github! 

 

 

Apple announced today that it's going to start putting their fist in the profit pie of the big subscription streaming services. 

 

Everyone pays 30%, you can’t charge more on the iPhone for the product than you do on other platforms, and you can’t link out from the app to the browser to handle subscriptions without Apple being in the middle.

- Michael Arrington @arrington - TechCrunch

 

Where's this money going to come from? You, the user, of course. With many of the big names in streaming claiming that the publisher charges are already high as is, Apple, and I'm sure other major app vendors, are just going to put a greater squeeze on the little money that's left. So what's a subscription service to do but raise the price a little here and there to make ends meet. This is an ongoing game in the paid apps industry. Seriously though, why even play the game in the first place. Just set up a server in your own home and do what you damn well please without the Apple and streaming audio subscription tithes. Chances are you own all of the music you're listening to on streaming radio services already. I'm really hoping this decision is reversed, but it's an easy money grab and this is probably just the start of a new revenue stream that tragically targets the very publishers that keep the app store afloat.

 

I'll just leave this here: http://streeme.googlecode.com 

 

Source of my rage: 

Apple Keelhauls Music Streaming Services

http://techcrunch.com/2011/02/15/apple-keelhauls-music-streaming-services/

Your Music. Secure. Anywhere.

Hey thanks for checking out Streeme. Have you ever wanted to listen to your home music library at work or on your mobile devices? Me too! I've made this web based music streaming software so you can set up a free and open source server at home that gives you private access to your music 24/7. You don't have to rely on centralized services like grooveshark and last fm anymore - instead you can just connect to your tunes directly and listen in with just about any major web browser. The best part of this project is, if you don't like how it looks/works/feels - hack on it, fix it change anything - it's yours to modify. Whoa.. it's like free, man!  

 

Background

For the last few years, I've been kicking the tires on a way to get music from your home computer to a mobile device. This project actually started out in 2004 as a public webserver that just played your music on a PSP in shuffle mode using the PSP's feed reader. That kind of solidified the idea that it's totally possible to have your music just about everywhere. I worked with a friend to build an initial mockup of the mobile interface and database funcitonality in a project called Streampod. Streampod suffered a bit from being too tied to iOS devices and it just lacked a decent player for the pc (at work etc), but the structure of the database and the basic navigation stuck. 

Fast forward to 2010 and I was kind of looking for a fun project to do on the side with the full intention of making it available to others. I come from a background in PHP, Apache and MySQL, and I didn't really know much else aside from the usual web/javascript stuff. I began in about May 2010, putting together a pretty complete version of the app and I released an early screenshot of the mobile version, playing on my Palm Pre, up on youtube  . Something cool happened in October that changed the project for the better. I adopted a framework called Symfony thanks to a decision at work to pursue an MVC framework. That made the app into something to share with the world.

Launch

I set a deadline of Christmas 2010 to get the first alpha out and it actually released a bit early! Streeme's a fully loaded, multi platform, HTML5 based music player / audio server and it's private, too. All of your music gets fed through a gateway that is protected by a faily well established security library for Symfony. On most webkit based mobile devices, you don't need apps either.. these are all itches I was trying to scratch - make a totally web based music library browser that could be hosted on cheap, easy to find hardware with limited system resources. Chances are if you can put php on it, Streeme will work just fine. 

I've already heard reports from Mac/OSX users using their mac minis as a perfect hosting platform. Another cool project was running streeme on an ARM based SheevaPlug - a sweet server that's the size of a DC adapter :). This thing is nerdy bliss for now, but once this project hits critical mass (fingers crossed) I hope to have all kinds of ways to install it. People got my gears going talking about stuff like getting it onto all in one media boxes and flashable routers etc. Since I started writing this project, I've seen a whole lot of competitors out there, which is awesome! The more solutions there are to this problem, the better - I'm surprised there aren't more.

 

Streeme's Manifesto

Streeme excites me because I'm always learning from it - everything you see in streeme is meant to say.. here - this is what can be done with the tools. Web technologies don't have the trappings of traditional pay-to-play apps that just drain the the steam from otherwise bright projects because of useless QA review by a disinterested third party, fundamental incompatibility and interoperability issues and the code practice simply being out of reach for most web developers. Why build 18 different apps to accomplish the same goal? Let's choose a free and open web where you can develop something and share it without the red tape and apologies. Earnestly, the web was made for sharing multimedia. For all of its inconsistency, feature fragmentation and spotty codec support (blahblahblah whine whine whine), HTML5 can do a hell of a lot and work on even the most basic computers you'd typically find at work, school or on travels. Heck, if you write something awesome for Streeme or want to help make the entire streeme project better, you can just join up on github and develop to your heart's content. With mobile computing bringing on cutting edge music players and up to date browsing engines, Streeme will be able to take advantage of up to the minute technologies so whether you're walking to work, sitting with friends in a coffee shop or walking in a town half a world away, you should always have access to your tunes.  

 

This is about making your music free! 

 

New to this project? Get going with Streeme here >>