What’s Next in Apollo?

I’ve deployed the first pre-alpha build of Project: Apollo and you can check it out. So what’s next?

Technology Sidetrack

For a little while, I’m going to sidetrack from new features in Apollo to work on the audio/video rendering system. While I’ve got JW Player working decently now, it adds a lot of overhead and if Apollo is going to run on iOS devices, it will need to have an HTML5 implementation. So the next phase of development will be focused on improving the support for multiple rendering engines.

Visual Playlist

Right now the playlist is just a hard-coded demo. Logically, I’ll need to expose it to the user so you have some idea of what’s next in the list. Simple enough.

The Library

Probably the biggest function area is the library. This is where you can store and browse all the media in your library and make playlists and so forth. Details are vague but it will be cool. I promise.

HTML5 Audio: Format Wars

I had originally planned to use HTML5’s new <audio> tag to actually render the audio in Project: Apollo. That went south, however, when I discovered a few critical problems with current implementations that disqualify the <audio> tag from contention.

Different Browsers, Different Formats

Both Mozilla and WebKit have already adopted at least some support for the <audio> tag. Unfortunately, Mozilla has decided to avoid potential licensing issues by omitting support for any audio codec that isn’t freely open source. This means no MP3, MP4 or AAC support, as those are proprietary codecs.

On the other side of the fence, WebKit (driven by Apple) has a substantial interest in seeing both MP3 and MP4 thrive on the web (maybe you’ve heard of iTunes?). Citing “simplicity”, Apple isn’t budging on adding support for the open standards Mozilla supports, such as Ogg Vorbis.

Google Web Toolkit

Unfortunately, there isn’t much support (yet) in Google Web Toolkit for HTML5, but it is coming. This makes it difficult to take advantage of HTML5 right now since my GWT is the main framework at play in Apollo. Specifically, I’m not sure how to go about listening for DOM events that are specific to HTML5, such as the ones fired by the <audio> element. This isn’t a huge hurdle, because I can always bridge to GWT with native JavaScript (ick). But it does add another hurdle to overcome.

The Solution, Sadly, is Flash

I have used Longtail’s JW Player for Flash in the past on other projects. Despite my reluctance to do so*, I have decided to implement JW Player 5 for Flash as the audio rendering engine. JW Player 5 has the best support of formats I called for in my key features, and it is relatively simple to use.

* Okay, I just have some minor gripes with JW. Namely, they documentation is always a sore spot as it’s often conflicting or missing. I also feel like I’m being nickel and dimed to death by their licensing terms.

The Audacity of Music

For a number of reasons, I find my collection of music to be a generally complicated topic.

It’s Enormous

First of all, I have a ton of it. Gigs of it. Thousands of tracks. I own a 60GB 5th-gen iPod. It’s full. Needless to say, I seem to fancy myself a collector of audio. I refuse to let go of old tracks I would never even admit to owning. Managing such a large library is tough and most would-be music libraries out there I have tried tend to choke on large databases.

It’s Amorphous

My music collection isn’t just large, it’s also fragmented by duplicate tracks, multiple formats, and duplicate tracks in different formats.

It’s On My PC, At Home

Up until recently, I used my MacBook Pro at work and a Gateway desktop at home. All of my music resided on my Gateway with its 1TB internal disk drive. Then I decided to retire the desktop. It’s not old or broken (Intel quad-core 2.4GHz with 6GB RAM and 1TB RAID disk setup). I just grew tired of switching platforms night and day. It’s like getting into your car every morning to drive to work and finding that the seats and mirrors are never where you left them.

My desktop doesn’t travel with me, either. And since I have more music than my iPod can store, much of my music stays locked up at home (yes, I realize that millions of people have dealt with this problem since the dawn of recorded audio).

It’s Not All Physical Audio, or Even Virtual Audio

Not all the music I listen to exists in a physical incarnation. Some of it came from CD’s, some of it I bought on iTunes. Some of it exists only through streaming radio stations such as Pandora.

So What to Do About It?

Unfortunately, I can’t just throw everything onto my MacBook and be off. I don’t have the disk space for it. And I have no interest in carrying a USB drive everywhere I go to store all my music.

I tinkered with a Network Attached Storage device, but many of the same problems remain. Namely, the device is still constrained to my home and to get decent performance out of it would require a total upgrade of my home network to Gigabit.

Helium Music Manager

I did try and thoroughly enjoyed using Helium Music Manager. It’s a fantastic audio database and has some pretty nifty features for audiophiles. However, it is missing one critical, deal-breaker feature for me: it’s Windows-only.

Enter the MKLabs

Since I’m a developer, I think it ought to be possible to build a solution to suit my needs and wants. So that’s what I’m going to do. Part of MethodKnowledgy is to explore and learn about code, so this makes perfect sense. I think I’ll call my little “code shed” of tinkering MKLabs.

I won’t go into all the details of features here and now, but basically I intend to build a web-based audio database application and leverage some of the coolest new platforms and technology out there to make it happen.

I’ll use cloud-based hosting systems like Google AppEngine to host my application and give it a scalable, high performance back end. The AppEngine DataStore also looks like a good candidate for storing massive amounts of data on my music.

I’ll use Amazon S3 to store and backup my music and distribute it through Amazon CloudFront.

I’ll use Google Web Toolkit to build super-fast, engaging user interfaces so my application feels (and works) like a proper desktop application.

And I’ll use new features like HTML5 Audio tags to render the audio, removing the need for special plugins or browsers (albeit I make a rather large assumption about the capabilities of average Joe’s browser).

I’m not trying to reinvent the wheel, though. Products like iTunes, Helium, and Grooveshark have proved what features do and don’t work. Now I just want something that works the way I want it to.

I aim to make regular updates here about the progress of my new music jukebox, codename Apollo. I’ll discuss major successes or failures along the way and try to document things that work well or don’t work well, and how to overcome certain challenges.

Should be fun.