[soundcloud] Use api-v2 to support AAC streams

[ArrEssJay]

Please follow the guide below

• You will be asked some questions, please read them carefully and answer honestly
• Put an x into all the boxes [ ] relevant to your pull request (like that [x])
• Use Preview tab to see how your pull request will actually look like

---

Before submitting a pull request make sure you have:

• At least skimmed through adding new extractor tutorial and youtube-dl coding conventions sections
• Searched the bugtracker for similar pull requests
• Checked the code with flake8

In order to be accepted and merged into youtube-dl each piece of code must be in public domain or released under Unlicense. Check one of the following options:

• I am the original author of this code and I am willing to release it under Unlicense
• I am not the original author of this code but it is in public domain or released under Unlicense (provide reliable evidence)

What is the purpose of your pull request?

• Bug fix
• Improvement
• New extractor
• New feature

---

Description of your pull request and other information

Soundcloud Go+ provides AAC streams at 256kbps. These are only available from the api-v2 endpoint as progressive https or hls. This change addresses adds support for these and retains support for existing https/hls mp3 from the same v2 endpoint, and downloads (when available) from the v1 endpoint.

The 256k streams are only available if a Go+ account is provided by way of an OAuth token:

--add-header "Authorization: OAuth <token>"

If an OAuth token is not supplied, only MP3 128kbps and Opus 64kbps streams are available. Incidentally, this change also adds support for downloading the low rate Opus streams.

The main downside to this change is a delay whilst all the of the stream URLs are retrieved and validated.

I have tested this with a Go+ account and 256kbps AAC streams are retrieved correctly. I did have to use ffmpeg on the HLS streams (--hls-prefer-ffmpeg) for a valid seek table to be present but I have not investigated the precise cause of this.

[ArrEssJay]

I should note, if a Go+ account isn't used, the links to the AAC streams will not even be sent by the api. There is a try/catch around getting the asset URL but this is to handle some of the test cases where secret track links for opus 64k assets give a 404 error.

[dstftw]

1. Read coding conventions and fix code.
2. Plain -u/-p authentication should be supported.
3. You must provide account credentials for testing.

[g-goessel]

I noticed that not all files were downloaded when I added my OAuth token. Tracks that are only available on low quality weren't recognized in the playlist (the playlist is shorter with the token). Were you aware on this ?

Anyway thank you very much for the PR ;-)

[ArrEssJay]

1. Read coding conventions and fix code.
2. Plain -u/-p authentication should be supported.
3. You must provide account credentials for testing.

1. 'Fix code' is rather ambiguous and doesn't get us any closer to fixing the code. It would be more helpful if you could tell me what you believe needs fixing. I have read the coding conventions, but it would appear there's something you think I have missed. Again, if you could be more forthcoming, perhaps I can contribute something more constructive.

2. Would the --cookies method be acceptable? Implementing a complete login workflow to acquire an oauth token is non-trivial.

3. If this is the last thing needed, then sure I can provide these.

[ArrEssJay]

I noticed that not all files were downloaded when I added my OAuth token. Tracks that are only available on low quality weren't recognized in the playlist (the playlist is shorter with the token). Were you aware on this ?

Anyway thank you very much for the PR ;-)

I've seen some different behaviours too, from file to file. I guess they've changed things around over time. The age of the file is something to do with it, as is the type of file that was originally uploaded. I tried to handle as many cases as I could find but there may be others I missed. If you can send me the link I can take a look.

[freextr]

Dont know if it is ok to ask here if not point me in the right direction please. So id like to test this but cant get my Oauth token without having the soundcloud aproved developer credentials as they temporarely disabled new accounts.

[g-goessel]

@ArrEssJay this link for example : https://soundcloud.com/wandw/the-chainsmokers-ft-daya-dont-let-me-down-ww-remix-1
I get a 403 wit the OAUTH token but it downloads fine without it.

@freextr I did the following to get my token :

1. go to the documentation
2. click on Try out the Client-side auth flow
3. copy the URL on the popup and open it in a real tab
4. click connect
5. the access_token should appear in the redirected page URL

[freextr]

Thank you @g-goessel it works :D

[freextr]

Is it possible to run a command and see what formats are available? As I'm only getting the 128bit streams or maybe doing something wrong. I'm using youtube-dl --add-header "Authorization: OAuth x-xxxxxx-xxxxxxx-xxxxxxxxx" https://soundcloud.com/xxxxxx/xxxxxxxx
Edit: I found the argument for the list -F
So looks like if the track is also in 256bit it gives a 403 error. The same error applies for the tracks that are GO+ only (like the Muse - Simulation Theory album) in case I don't use the OAuth token.