On a related note, the soundcloud API is horrible. Their solution to rate limiting is to require a client_id and then stop giving them out. So those few client_ids out there get abused by everyone (since they are simple to grab from locally running apps) and nobody can stream anything past a certain point in the day. Such a hack. But hell, at least they have something!
To use the APIs properly, you need to register an app to authenticate, whereas with this approach it's jacking a client ID generated for the Web-based client, it appears.
This approach is necessary because SoundCloud shut down its API app registration form about 9 months ago (around the time they made big layoffs) with no sign it'll open again. Even when registration was open it was just a Google form and people got rejected after waiting weeks for a response - https://twitter.com/JamesPaulDuncan/status/86719870256109158... - so I'm not surprised people are hacking around it.
I haven't seen SC respond to any of the numerous requests about this on Twitter either, so I suspect anything that doesn't directly make money at SoundCloud doesn't get attention anymore.
Reverse engineering the client ID generation would be more useful (maybe their web clients just grab from a pool, I have no idea).
Stack Overflow is full of questions regarding app registration and rate limiting. If writing audio service integrations, steer well clear of SoundCloud.
On a related note, the soundcloud API is horrible. Their solution to rate limiting is to require a client_id and then stop giving them out. So those few client_ids out there get abused by everyone (since they are simple to grab from locally running apps) and nobody can stream anything past a certain point in the day. Such a hack. But hell, at least they have something!