> We will create a Python script which will allow us to download even those songs which are not enabled for downloading.
and then he goes on downloading the 128kbit/s web-player mp3... that was very disappointing.
It's like saying "How to download music from Spotify," where I'd expect you to use libspotify or the web API before reading the article, but suddenly I find myself reading about how I can record Spotify music with the "voice memo" app of my phone and a lot of time.
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!
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.
Stack Overflow is full of questions regarding app registration and rate limiting. If writing audio service integrations, steer well clear of SoundCloud.
What is the possible reason for making this achievable? For his next trick, will he post how to download any app from the Apple App Store for free too?
Do programmers only consider their own code sacrosanct, but anyone else's creative output free game?
Note: I make most of my content on SC downloadable anyway because I don't make money from my music, but the principle is still the same - I want the right to control whether my creative output can or cannot be downloaded.
> I want the right to control whether my creative output can or cannot be downloaded.
Then you can't ever upload it online to a place where it can be streamed, ever. Or if you do you have to put audio "watermarks" over the track, and make sure you always have certain sections watermarked so no one can ever play a full "pure" version of your song. (Otherwise someone will just cut together 2 recordings with different spots watermarked).
This method doesn't download the high quality original file. Only the 128kbps compressed file that is used for streaming audio. No matter how much you lock down the website, browser, file format, even the OS.... A $2 pair of cables plugged into a recorder can accomplish the exact same thing and is impossible to counter.
So you want X and !X at the same time, enforced by the client?
First rule: don't trust the client.
Second rule: if you release something online, you lose control of it.
As a corollary of rule 2: accept that scarcity doesn't apply online with regards to digitized content.
Third rule: DRM doesn't work. Giving encrypted files along with the key to decrypt is pointless.
Fourth rule: Obfuscation only buys you time. It buys you even less time against a dedicated attacker.
But, it does take time to understand and wrap your head around these rules. And I know not everyone accepts them up front. Many try to think of ways around these things, using 'creative' ways (aka: logical fallacies).
128kbit/s MP3 vs FLAC is why I buy stuff on Bandcamp instead of ripping it off Youtube (though I still have about 1.6k youtube videos from promotional music channels archived as mp3)
I don't, and I share as much as I can after losing things a couple times.
It's important to keep in mind though that software is really fundamentally different than art: software is a liability and has to be maintained whereas a work of art is (usually) more or less created once. The models that support software development probably don't work well with art.
Then, your only solution is not to release it.
youtube-dl can download content from just about everywhere, including SoundCloud.
Turns out, if you view the source on one of those embeds the full URL is right there. It's even called "permalink_url" and has the secret_token for the track as well, which is what lets you listen to private tracks directly on Soundcloud.com. The url structure is:
If I recall correctly, the API also lets you look up some info on private tracks with that secret_token. Not sure if all of this was intentional, but I reported it back in 2016 via their "whitehat" channel and didn't receive any type of response back.
 - https://rg3.github.com/youtube-dl/
A good tutorial for beginners but I’m quite disappointed, I was expecting more complex things like actually reverse-engineering a DRM scheme.
Fair enough, I guess it violates TOS but a bit annoying since public API is basically abandoned and lacks a lot of features.
Can't remember why, I think some fields needed to stream in the same way as the app, or read some metadata, were only present on v2.