Skip to content

Conversation

@Lioncat6
Copy link

@Lioncat6 Lioncat6 commented Oct 13, 2025

Closes #35

SoundCloud currently implements the following:

  • Looking up releases as a set/playlist or track
    • Unlike Bandcamp, there is no way to determine if a track has a parent playlist/album with the v1 API
  • Getting track ISRC, duration, author, and region information (Though, I haven't found a track, yet that has a set region restriction)
  • Track/Playlist publish date, falling back to the creation date if not present
  • Track and album artwork
  • Getting playlist type
  • Determining playlist label from tracks

@Lioncat6
Copy link
Author

Lioncat6 commented Oct 13, 2025

Looking at #35, and I should see about adding CC license detection

As for GTINs, those are only available when using the v2 API, which requires a user oath and client ID, as opposed to an application auth. At the moment, this implementation only uses the public v1 API, lacking support for proper label, copyright, and barcode information.

@Lioncat6
Copy link
Author

I also still need to add tests to SoundCloud, it seems.

image

@Lioncat6
Copy link
Author

I have also determined that some releases simply can not be fetched with the v1 API, for example: https://soundcloud.com/stevie-wonder-official/sets/so-what-the-fuss-3

@kellnerd kellnerd added feature New feature or request provider Metadata provider labels Oct 14, 2025
Copy link
Owner

@kellnerd kellnerd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for looking into SoundCloud!
Although this is still a draft and I haven't made an account to obtain API credentials yet, I couldn't resist to review the code once.
I have left a few comments but I guess there will be more once I get to play with the v1 (and maybe v2) API.

P.S. CI is complaining about code formatting, see here how to reproduce that locally.

};

override readonly features: FeatureQualityMap = {
'cover size': 500,
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was able to obtain bigger images (about 1500px) with Image Max URL, so we should check that again.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

500x500 is the highest we can get for sure. Using original in the url instead of t500x500, we can get the original file, which I've personally seen up to 3000x3000, the ending of the url changes depending on what the artist uploaded the file as: either .jpg or .png

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Update, just found one at 3071x3071.

Copy link
Author

@Lioncat6 Lioncat6 Oct 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Further update: After messing around with my own images, there is no image resolution limit, but compression is applied to whatever you upload

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since there is no way to determine the url extension for the -original urls, I think it should stay with the t500x500 URL and let the image importer userscript handle it.

Otherwise, a request could be made here to determine the extension

getArtwork(release: SoundcloudPlaylist | SoundcloudTrack): Artwork[] | undefined {
const artworks: Artwork[] = [];
const artworkUrl = release.artwork_url;
if (artworkUrl) {
artworks.push({
thumbUrl: artworkUrl.replace(/-(large|medium|small)\./, '-t300x300.'),
url: artworkUrl.replace(/-(large|medium|small)\./, '-t500x500.'),
types: ['front' as ArtworkType],
provider: this.provider.name,
});
return artworks;
}
return undefined;
}

@Lioncat6 Lioncat6 marked this pull request as ready for review October 23, 2025 06:58
Copy link
Owner

@kellnerd kellnerd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for adding a few provider tests! For today I have a couple of questions and a few refactorings which went wrong.

if (url?.hostname.endsWith('.bandcamp.com')) {
return typeIds.bandcamp;
}
if (url?.hostname.replace('www.', '') == 'soundcloud.com') {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do the URLs ever have a www subdomain? The provider implementation doesn't accept it at least.

@kellnerd
Copy link
Owner

kellnerd commented Nov 23, 2025

I have taken the liberty to finally push my changes to your branch.
The commit messages should speak for themselves, but please ask if you have any question or doubts.

Sorry that it took me so long, these changes are already 2-3 weeks old, lol.
I though that I would be able to quickly fix the following issues as well, but I didn't:

  • Link types are sometimes incorrect
    • Not all tracks of all releases are streamable for example
    • There is a property streamable at playlist and track level which probably helps
    • I would rather ship an initial version which doesn't set link types than a version which results in inaccurate data
  • Release type handling has to be safeguarded (PLAYLIST is not a valid type on MB for example)
  • Cover size
    • Feature value doesn't matter too much (it is only used to rank providers), but the average should be higher than 500 (1500? 3000?)
    • I would still return "-original.*" URLs (unless "-original.jpg" is invalid when the original is PNG)
  • Most importantly: The API returns empty track lists for all major artists that I've tried!
    • This is unrelated to the Go+ premium subscription
    • Not even the specific /playlists/$ID/tracks endpoint helps

@Lioncat6
Copy link
Author

@kellnerd

Cover size
Feature value doesn't matter too much (it is only used to rank providers), but the average should be higher than 500 (1500? 3000?)
I would still return "-original.*" URLs (unless "-original.jpg" is invalid when the original is PNG)

The file extension (.png or .jpg) of the -original. cannot be determined from the URL the API returns. Sometimes it matches, and other times it does not. I have yet to find a correlation between the two, and the only way to definitely know would be to make a request to both and see which one returns a 200.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

feature New feature or request provider Metadata provider

Projects

None yet

Development

Successfully merging this pull request may close these issues.

SoundCloud

3 participants