Previously, we have discussed our search for a cloud-based music synchronization system. We looked at the offerings of Google, Amazon, and Apple, and found them all seriously wanting.

So much so, in fact, that we despaired that such a service might not exist. And what do you do if something doesn’t exist?

Build it yourself.

The Criteria

The first thing that we had to do was lay out some pared down success criteria — what are we trying to accomplish, no frills? We can always tinker and add things later.

The first thing we do is throw out “automatic”. Automation can happen later after proof of concept.

What we need is:
1. A way to copy a set of songs to my phone, without having them connected by a cord, or on the same WiFi network.
2. A way to copy metadata back to my computer, to update information on what songs have been played on my phone.

The Ingredients

With two simple steps, we now need to gather our set of ingredients to set it up.

Cloud space

We cannot simply load data directly to the phone, unfortunately — an intermediary is needed. Options here are endless, but for a proof of concept, I chose to use Dropbox.

The Big Bad Blog has had issues with Dropbox in the past, and didn’t feel entirely comfortable about this. But as the most popular service of its type, it means that there’s a plethora of tools out there to use.

If things work, goes the logic, either utility will trump ideology, or alternative cloud storage can be found.

The clients

With storage space figured out, the next question is how to upload from the computer, and download from to the phone.

On the PC side of things, I went with Dropbox’s own client. Easy to use, with the benefit of being pre-installed from a brief past flirtation with the service.

For my phone, I downloaded Syncness from the Android Market.

Metadata sync

Which left us with sending the metadata back to my computer. Here I chose to use last.fm.

Last.fm is not just an internet radio — it will also listen (or “scrobble”) to everything you play on your computer, phone, or iPod, and keep track of it. Information on what is played can then be imported back into MediaMonkey, to update the play counts and dates on my computer.

The Test

So how did it all work?

Initial, small scale tests of all three systems worked like a dream. The upload, download, and metadata sync all went smoothly. And we were ready to roll.

And that’s when the shit hit the fan.

I tried to make a larger scale synchronization — not my entire playlist, or a multiple gigabyte load, or anything of that sort. One hundred songs; something that might be typical of a weekly scheduled sync.

It took three hours to upload the songs to Dropbox. And another hour and a half to download them — over WiFi, no less.

This was simply too long. The entire point of this was to create a process that did not require manual intervention. And while all the individual pieces can be automated, making sure that the individual pieces weren’t interrupted mid-sync would require that the synchronization was always kept in mind.

The Verdict

We can see why nobody seems to be offering the service that I’m after — it would just run too slowly to be viable. Hence the concentration on “cloud players” that don’t bother to try to move music onto your own device.

It goes without saying that having music on your device is better — it can hold better quality files than can be managed by streaming services, it can play that music anywhere. Underground, on an airplane, in a foreign country without internet access. The music is just there.

Our bafflement at the lack of a cloud synchronization service has been morphed into an understanding through this process. The companies in the cloud player market are actually building their problem — an inability to provide proper synchronization — into their services as a central, “positive” aspect.

In a couple of years, after everybody has been convinced to stop synchronizing, the technology will have finally arrived and all the same companies will start to convince you to sync your music again.

And so it goes.

(Previously: Volume I and Volume II)

A couple of weeks ago, we posted An Android music adventure, volume I, in which we ditched iTunes in favour of MediaMonkey, and went in search of a brave new world in which devices synchronize with little interference beyond the initial setup.

In this week’s episode, we search for the most likely default …

In search of the Big Cloud

Having decided already that our answer almost certainly lies in that recent buzzword, cloud computing, our first task is to identify the appropriate default cloud configuration for us. While there are certainly hundreds of enterprises out there of various sizes, all trying to ride the cloud computing wave, we decided to start by looking at three options: Amazon, Apple and Google.

Why these three?

The decision to limit our initial investigation in this way was a rather simple one — these are three companies that are big. None of them will just disappear tomorrow, and all seem likely to offer some sort of solution. The solution found here might not be our ultimate solution, but it will hopefully provide an interim solution and a fallback point if things go wrong elsewhere.

Amazon is a huge online retailer, with hugely successful MP3 and Android App stores. On top of this, they’re a big player in the cloud space, providing hosting services for a large number of extremely popular websites. My Kindle experience has been positive, with a pretty slick book-delivery system.

And Amazon launched their “Cloud Player” some months ago to much fanfare.

In short, Amazon looks like a solid bet to have a solution.

Apple announced their iCloud service recently. And while we fear that it might require iTunes (a non-starter) or an i-Device (rather than an Android), Apple also has a couple of things going for it. As the proprietors of the world’s biggest online music store, they are in as good a position as anybody to work something out with music publishers.

And for all their faults, Apple has a history of redefining markets they enter. They did not make the first, or (arguably) the best, PC, MP3 player, smart phone or tablet. But they completely changed the landscape for each of these. Apple could well have done something that (once again) has left their competitors scrambling to catch up.

Google has had betas other than Google+ running in recent months. One of these is Google Music. Google are the craftspeople behind my phone, and I am quite impressed with their operating system, and the easy cloud synchronization of my contacts and photos.

Step one: Google

My first stop, I decided, would be Google.

That stop looked like this:

Which is a shame, because the service itself sounded alright — sure, it’s a streaming service (rather than an outright synchronization), but at least it streams your own music collection (rather than random songs Google has decided you might like). And it caches playlists to your phone, reputedly, allowing for them to be played when your connection fails.

Are those playlists “smart”? How is metadata synchronized?

Well, these are questions we cannot answer, because we could not test the service. Alas.

Step two: Amazon

With Google unavailable, our sights are turned to Apple and Amazon.

Our well-documented dislike of the former combines with a strong desire to never download iTunes again to make us jump towards Amazon as our next-best-bet. Amazon is a service on which we can pin high hopes. Their service is not in Beta, and they have an associated MP3 store.

If Google ticks some boxes and isn’t even available, surely Amazon will be better!

Alas, no.

Amazon does not do smart playlists — their create and manage playlists instructions clearly do not mention managing playlists in any way other than manually. And all mention of actually downloading music to a device (rather than streaming) is by song, meaning that even if smart playlists could be maintained, they could not be synchronized.

And here at the Big Bad Blog, we tend to organize our music via smart playlists.

But more importantly, Amazon (like Google) is available only to customers in the United States, leaving us here in Britain out in the cold again. They also only support a couple of music formats, although with the two formats being MP3 and M4A, they do reflect the majority of my current music collection.

Finally, music cannot be uploaded from a phone — that Amazon-bought MP3s are automatically on their cloud drive does provide a bit of a workaround there, but it’s still pretty poor. I want music delivery to be independent of the purchasing mechanism.

In the end, Amazon doesn’t seem to be able to tick any of my boxes. As they say, it’s a cloud player, rather than a cloud service. Amazon streams and sells, they don’t sync.

Oh, and they won’t even stream to me.

Step three: Apple

With the two best options of “fallback option” off the table, we turned to the evil empire.

Check #1: Will iCloud work on an Android phone? No.
Check #2: Will iCloud work with music for customers outside the United States? No.

We did not bother to look at the remaining features of the service. By this point we had a headache.

Conclusions

Our initial investigations have left us without a synchronization mechanism.

Indeed, it seems that jurisdictional legal issues – to whit, the music industry being firmly set in the 1990s, and insisting on geography-dependent distribution over geography-independent distribution systems. In the end, all I want is music on my computer synchronized with music on my phone.

This seems perfectly reasonable, and is doubtlessly legal. However, the recording industry’s zeal in pushing for unintuitive copy protection laws and tendency to sue their customers (or those offering services to their customers) for daring to find alternative distribution technologies clearly has even those corporations with a similarly large stable of lawyers acting cautiously.

Here at the Big Bad Blog, we suspect that any solution we find will be expensive — due either to having to pay the record companies (but probably not the musicians) big bucks to avoid lawsuits, or having to pay lawyers to fight those lawsuits.

What a pity.

What’s next?

Next week, we attempt to circumvent the local nature of global services with a DIY solution …