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 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.
With two simple steps, we now need to gather our set of ingredients to set it up.
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.
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.
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.
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.
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.