Friday, 24 April 2009

No wonder Seeqpod are in trouble

I'm really interested in music streaming on the web. There is no doubt in my mind that this is the future of how people discover music, due to the major ease of use.

In this post I'm gonna do a brief analysis of one of the major players, Seeqpod, who recently filed for bankruptcy protection, and suggest one or two reasons why.

Seeqpod's infrastructure is made up of a number of components.

Firstly, a web crawler. This must scour the web for uri's that contain the string ".mp3". Once it finds one, it must pull into it's server at least the first few kilobytes of that tune in order to read id3 tags. This is potentially dodgy from a legal position, as it means that they are "downloading"
the tune, even if it's just into RAM, in order to read it's ID3 tags, the parts of an mp3 that provide meta data such as bit rate, album, artist, track name etc. It then stores these in it’s
database, along with the URI that tells them where they got if from. They probably clean these results occasionally to ensure that the links are still good.Secondly Seeqpod has a music player, and this is where the cost analysis gets interesting.

Now, in order to play music, Seeqpod use a Flash application. This is still the only really sensible way of playing music and video on the web.

The audio playing part of the flash binary doesn’t really care where the audio lives on the web. Provided the file exists, it will play it. There are no cross domain issues unless you want to analyse the content of the file on the fly, to provide a spectrum analyser for example, in which case the audio must be served from your domain, or a domain which provides an appropriate cross domain policy file.

By playing an mp3 file from any random server, you are at the mercy of the domain that is streaming the audio to provide a reasonable throughput to your users. If the network connection that the hosting site provides is weak, or overloaded, than the tune will stutter, or not stream at
all. There are various ways this can be mitigated, and the approach Seeqpod has taken is to proxy all requests through their servers, and then download the track, in its entirety,
to the flash player, before it starts playing. Finding this out was the work of minutes, using firebug. You can check this yourself.

I was a bit shocked when I discovered this. I’d assumed that their player just pulled in the audio from wherever it was hosted, to prevent them facing the even more dubious position of having the entire tune, which of course may be copyrighted, pass through their server, even if they don't host/cache. Realistically, given the speed with which a tune downloads I suspect (but can’t prove) that they are caching tunes on their server/CDN. Committing them to hard disk. This is liable to cause them significant legal issues, even if it's a "cache".

Further all this proxying must cost them a lot of money!

Let's assume that the average size of a tune is 8Mb. This may be a high estimate, but it’s adequate for my calculations.

Seeqpod uses Level 3 for bandwidth, and I don't know how much they are getting charged, but using Amazons Web Services as an indicator of cheapest available bandwidth costs, 1GB of data transferred costs $0.10. To get an 8Mb tune to their customer, seeqpod must download it from the host, and then serve it to their user. This is two hops for each file, so they have to transfer 16Mb of data in total, at a cost of $0.001563. If they are caching, then there is realistically little difference between storage and data transfer costs per GB.

Seeqpod claim, on their landing page, to have about 120 million music related searches per month. If we assume that each search results in two tunes paid, which I have no evidence for, then each month Seeqpod are paying $375k per month in bandwidth costs alone, or $4.5 million per year. I'm astonished that they are prepared to pay this much money on proxying, though doubtless it makes the service a good bit better. I really hope I have these numbers wrong,
for their sake, as if I haven't it may well be the death of them.

Crunchbeat reports that they have received $7 million in Angel funding and have 25 employees, which, assuming average wages + overhead per employee costs of $150k, is another $3.75 million per annum they’re paying.

Apparently they have also received some private investment. And they are have some paid-for services (their Echo service). So may have some revenue growth. Which is nice for them.

But on the other hand, I’ve ignored a lot of costs. Servers. PR/Marketing. And they must be spending a lot on lawyers, what with Warner Bros, EMI etc chasing their tail, they apparently already owe not far off $500k in legal fees.

No wonder they’ve filed for bankruptcy protection. No wonder they are opening up their assets, maybe for the good of all" before it's too late.

Oh, and as to the "not facilitating downloading" argument they offer the record companies, they show you the originating URL of each file you're playing. A little bit of wget and I've downloaded it. This is an awkward one. Writing a basic app to search Seeqpod using their API, and then download the tunes would take all of half an hour. On the other hand, this is the same as Google displaying links to copyrighted newspaper sites.

Is my analysis wrong? Have I missed something? Your thoughts, as ever, are welcome.

Tim Stevens

Tim Stevens
Work
Consume
Obey
Be Silent
Die