How to Load 10,679 Songs Into Google Music in 2 Days Using AWS & Dropbox

Google-music

 

Don’t get too excited: unless your music collection’s already in the cloud somewhere, this isn’t going to help you (with one possible exception, discussed below). In my case, that was Dropbox. The majority of my music – audiobooks and not yet unlocked DRM’d iTunes content excepted – was up in the cloud already. 

But until Google acquires Dropbox, or at least builds Dropbox integration into Music, that doesn’t help much. There’s no simple way to sideload one directly from the other. There is, however, a relatively simple work around. The credit for which, to be clear, belongs entirely to my friend Corey Gilmore

The basic problem with Google Music, as Steve Jobs pointed out, is the upload speed. Using my home DSL, he’s correct: it would take weeks to load Google Music with my collection. The first afternoon I tried, in fact, I succeeded in transferring 123 songs in just under five hours. 

Here’s how I shortcut the process:

  1. Spun up a Windows image on Amazon. There are a great many options; I selected a small Server 2003 instance simply because it was what I was most familiar with. 

    Notes: do not reboot your instance before you retrieve the admin password.

  2. The small instance didn’t include enough disk space for my music, so I created an EBS volume and attached it to my running Windows instance. 

    Notes: make sure to create your EBS volume in the same region as your running instance.

  3. Installed the Terminal Server client from the Ubuntu Software Center, then connected to my Windows instance via RDP and the AWS supplied public DNS info.

    Notes: use the admin password obtained in step 1 to login.

  4. Once logged in, I installed the Dropbox client. Loading the music from Dropbox took around 18 hours.

    Notes: I did two things differently. First, I had Dropbox load to the extra drive created by my attached EBS volume. Second, I used selective sync to bring down the Music folder only.

  5. Once the music was loaded onto my Windows instance from Dropbox, I installed Google Music Manager. That done, I pointed it at my Dropbox folder and let it run.

    Notes: Music Manager can be obtained from Google Music itself; in my case I had the .exe loaded into Dropbox and manually pulled it down.

  6. After Google Music Manager finished loading the music from AWS, I killed the Windows instance using the Decaf Android application (thanks to Erik Dasque for the tip) because I was away from a machine at the time. With the bulk load done, my loading of Google Music these days is done through an existing Windows 7 virtual instance I have on hand.
The limitation to the above approach, obviously, is that you need to already have your music uploaded. You could presumably use AWS Import/Export to bypass this original load time, but that becomes expensive. If you have your music online somewhere already, however, it’s highly likely that AWS has better bandwidth – ~100Mbps – than you do. 

Unless you work for Stanford, that is.

Anyway, the AWS records show that I had my Windows instance running for approximately 42 hours at a total cost of $5.04. Your storage and bandwidth costs depend, obviously, on the data volumes you transfer. The EBS volume is $0.10/GB/mo and a dime per million I/O operations. Bandwidth, meanwhile, is $0.10/GB in and $0.15/GB out after the first gig. My total costs – instance, bandwidth and storage – were $22 and change, near as I can reconstruct. 

The question, then, is this: is it worth $22 dollars to load nearly eleven thousand tracks in less than two days? As long as the alternative is “weeks,” the answer is yes, at least for me. 

If you’d prefer to wait for iCloud, however, and its reimplementation of MP3.com‘s music locker, you can forget everything I just said. 

One thought on “How to Load 10,679 Songs Into Google Music in 2 Days Using AWS & Dropbox

  1. I uploaded about 500 songs per 12 hours at 900kbps upload. On and off again, 8,000 songs took two weeks. I like your method though. Slick.

Leave a reply to Mike D Cancel reply