I am working with the Spotify API and I found a strange behavior. Some tracks have tow different IDs even the track is within the same album.
Example:
https://api.spotify.com/v1/tracks/0YGzsfUBgNkcfw46TvYbxj
https://api.spotify.com/v1/tracks/3B7qxL6lZWWONOXNmEKADY (less information)
Does anybody know why?
Albums may be released several times, and tracks may be released several times but on different albums (e.g. the original and a Best Of). Even though they're in essence the same album or track, they will always have different Album URIs and Track URIs.
In your example, these two tracks are in a lot of ways the exact same track - but released on different versions of the same album. (The album may have been released in two different years, or by different companies.)
As a side-note, there's a concept of linked tracks in Spotify, that will equate a track that's released on several albums as the same tracks. If you attempt to play a certain track URI but it's not available in your market, Spotify will look for the same track on a different album that's available. The Web API also exposes this functionality, read more about it the Track Relinking Guide.
Related
I am reading the Google Photos API documentation. I can't find out what mediaItemId is, see for example here:
https://developers.google.com/photos/library/guides/access-media-items#get-media-item
There are some other questions that might be related, but they have no answers:
How to get mediaItemId of a Google photo using its shared URL?
I've not used the API but I'm familiar with other Google services and am a Photos user.
If you consider you're experience with photos.google.com, you browse a somewhat unstructured list of all your photos. The Photos (phone|browser) apps do categorize photos by date but you have to search to filter by other metadata to find the specific photo(s) that you're seeking. Or you happy-scroll through years of photos of your cat.
This contrasts with another common metaphor for arranging files in which a hierarchy of folders is used to categorize the content e.g. /photos/cats/2022 but this mechanism is limited because you can only really navigate through one dimension (the folders).
Considerable metadata (type, width|height, creation date etc.) is associated with each photo and it is customary in schemas like this to construct a unique ID for each object. The unique ID is sometimes exposed to the end-user but not necessarily. Identifiers are generally for the system's own purposes.
With Photos, there are public, unique identifiers in the form of URLs for each photos but evidently the id and the URL although probably related (perhaps via a hash) aren't obviously related.
So, since it's not always possible to specific a photo uniquely by e.g. "The one of my dog where he's wearing sunglasses because of the eclipse" and the absence of folders, a really powerful alternative (which you'll need to employ) is to search for some subset of the photos and then iterate over the results.
It appears that the Photos service has such a search to which you provide Filters and each of the items in the results will be a MediaItem (uniquely identified by id).
Unlike the file system example above, because Photos does not use a fixed hierarchy, we can view our Photos by filtering them using an extensive set of metadata: photos of cats, taken in 2022, using my phone.
I'm trying to get a large list of songs released in year X, together with their number of plays/streams.
I've been using Spotify API, and I have a number of highly popular songs. Now, for my purposes, I also need a list of non-popular songs (low play counts). I am wondering if there is any strategy to get a list of songs (maybe last played ones?), and extract their release year and number of total plays?
I've been going through the API documentation and I can only find 'popularity', which seems different from total number of plays. Secondly, I haven't found a way to get a list of last played songs yet. Should I be considering another type of strategy?
I know that you can get a list of recently played songs of all users in certain user groups in last.fm. Perhaps there is something similar in Spotify API?
Unfortunately, there is no way to get play counts through the Spotify API, only the Popularity metric.
Title says almost everything.
I found that the music "Boom - 2006 Remastered Version" has two different IDs that can be found in the App:
3EKjTDAEIdyQqsA9qtb5P2
0zlAqnRv07p9ezzFf3k2ky
But when using the API to get information about each one, it returns the same ID:
3EKjTDAEIdyQqsA9qtb5P2
Is this a bug?
It is unfortunately not a bug, but it is indeed very annoying, and your code needs to be able to handle it.
"Give me info for track A! Ok, here is info for track B, just like you asked".
It is a legacy thing still left in the Spotify metadata model called track redirects (the some concept exist on albums and artist too, but are less of a problem there). It was made so that we could quickly merge duplicate albums. It means that once upon time, there were two "different" tracks on different albums that were identical. We had lots of them on artists pages for popular artists. Labels would very often upload one album for one country and another identical one for another country instead of just saying that one album was available in two countries. Sometimes by mistake, most often because of cross licensing issues between labels and countries.
Track redirects are quite rare though if you look at the entire catalog. Most of these redirect tracks are only surfaced in old playlists and are for instance never returned in search results or artist pages. These days we never merge duplicates like this, but instead make sure only one is shown on artist pages, etc. and link to the other in case one is unavailable in your country. That is the concept called Track relinking in the docs. https://developer.spotify.com/web-api/track-relinking-guide/
I work at Spotify and bump into this problem every now and then. I want to change this so the tracks and album become just regular duplicates, because it is much easier to reason about, but it will take a while to fix. I guess I can update my answer here in a few years when it is done.
The original plan was to write this as a blog post, entitled "Inefficiencies in the Spotify Metadata API : Or, How the Jackson 5 killed my Browser", but changed my mind at the last minute as I have a habit of missing the obvious in documentation,perhaps an undocumented feature might exist which I have missed, or someone else has solved the issue - so hence this question has a certain blog-post tone about it!
I am developing a small web-app, mostly for a small group of people, which will allow anyone to update a Spotify playlist. As not everyone has Spotify (though I don't know why!), the page will update a database with songs, as App running in Spotify on my laptop polls the database for updates, then using the Spotify Apps API, the playlist is updated, and anyone subscribing to the playlist gets the update. This is ok, though I would like to use push rather than poll, but that's a topic for another day.
I searched around for a Javascript library to use with the Spotify Metadata API, and found one (https://github.com/palmerj3/SpotifyJS) though it was basically a wrapper and still required you to parse the JSON yourself. Thinking I could go one better and put some basic parsing in for the most common fields (title, artist, album, Spotify URI) I started working on my own library/JQuery plugin.
Search by track is not a problem, it's a single call to the spotify metadata API, the results are easily parsed, matching the returned artist with the requested artist (if present) makes for an easy search by title/artist.
Search by Artist (obtain a list of all songs by a particular artist) though, appears to be a pain-in-the-**! As best as I can tell from the docs, this is the process.
Search for the artist: this will return a list of artists which match the query
For each artist, lookup their albums: this will return a list albums
Lookup each album and retrieve a track list
Compare the artist for each track with the search artist, if it matches output
The first step will return a small list of artist matches, Foo Fighters has 2, Silverchair 1, and The Jackson 5 has 4. This small list turns into a larger number of album matches - from memory Foo Fighters returned 112, which then turns into even larger number of track lists. From a Javascript/JQuery perspective, this leads to daisy-chained AJAX request, for each step, and at each step massive numbers of, nearly concurrent GET requests against the Spotify servers.
The initial version I wrote cheated and used synchronous AJAX, and worked ok, as each request must complete before the next would start, though, this would lock the browser up for some time, and removed the possibility of using feedback to the user that the system was running. I then switched to asynchronous requests and all hell broke loose! You immediately hit issues with rate limiting on the Spotify end, which returns resoponses with 502 bad gateway (not listed in the spotify docs as a status by the way), or 503 - both of which JQuery interpreted as status code 0 - which was interesting, requiring debugging in Firebug. I throttled the requests down on the client side, I found that 1 every second was about right, to avoid rate limiting and ensure I got a response containing data each time, however, this then causes massive lock ups in the browser as it had upwards of 30 or 40 GET requests in parallel, all returning pretty much at the same time (though some requests responded after 15+ seconds!) and then parsing all the JSON responses.
I looked into alleviating the load by using a server-side approach, though this has downsides as well:
1. you don't avoid the basic issue in that the API can not handle the task in an efficient manner
2. for a busy site, the bandwidth usage will be against the server, which will also present a single IP, for multiple users you will soon hit the rate limit due to parallel users
The server side does offer caching though which could be beneficial, to this end I found a PHP Library - metatune (https://github.com/mikaelbr/metatune) advertised as the "The ultimate PHP Wrapper for the Spotify Metadata API", but unfortunately only offers the same basic lookup/search as the Spotify Metadata API - i.e.: no listing of all songs by an artist.
Thus, I have now disabled searching by artist, until I find a suitable solution.
Assuming I have not missed anything, it seems, to me at least, to not be an efficient API design, as it encourages you to make large numbers of requests to the Spotify servers, which is not good for me as a client, and not good for Spotify as a server. I can't help but think that if there was a request such as:
ws.spotify.com/search/1/artist.json?q=foo+fighters&extras=tracks
then the issues discussed here would be alleviated, a single request would cover what requires 3 sets of multiple requests currently; rate limiting wouldn't be as big an issue; the overheads to process the data on the client are greatly reduced; the overheads for Spotify to handle would be reduced and the entire service would be more efficient. The fact that the request would return a very large data set is not an issue, as the API already splits data into "pages".
So, my questions to the crowd:
1. Have I missed something obvious in the documentation, or is there a secret request?
2. In the absence of an API request, does anyone have a suggestion on how to make my system more efficient?
3. Has anyone solved this issue before?
Thanks for reading! Took a long time to get to the questions, but I felt it necessary to provide as much reasoning to find the best solution, and also, it illustrates the deficiency in the API, which I hope someone from Spotify will notice!
Finally as an aside, projects like this make me feel like we've swapped Flash for Javascript but the performance is still as bad! Anyone else feel the same?
Cheers!
sockThief
Unless I'm missing something, does this do what you want?
http://ws.spotify.com/search/1/track.json?q=artist:foo+fighters
The artist: prefix tells the search service to only match on artist. You can read more about the advanced search syntax (which also works in the client) here.
I'm looking for methods that work in practise for determining some kind of acoustical similarity between different songs.
Most of the methods I've seen so far (MFCC etc.) seem actually to aim at finding identical songs only (i.e. fingerprinting, for music recognition not recommendation). While most recommendation systems seem to work on network data (co-listened songs) and tags.
Most Mpeg-7 audio descriptors also seem to be along this line. Plus, most of them are defined on the level of "extract this and that" level, but nobody seems to actually make any use of these features and use them for computing some song similarity. Yet even an efficient search of similar items...
Tools such as http://gjay.sourceforge.net/ and http://imms.luminal.org/ seem to use some simple spectral analysis, file system location, tags, plus user input such as the "color" and rating manually assigned by the user or how often the song was listened and skipped.
So: which audio features are reasonably fast to compute for a common music collection, and can be used to generate interesting playlists and find similar songs? Ideally, I'd like to feed in an existing playlist, and get out a number of songs that would match this playlist.
So I'm really interested in accoustic similarity, not so much identification / fingerprinting. Actually, I'd just want to remove identical songs from the result, because I don't want them twice.
And I'm also not looking for query by humming. I don't even have a microphone attached.
Oh, and I'm not looking for an online service. First of all, I don't want to send all my data to Apple etc., secondly I want to get only recommendations from the songs I own (I don't want to buy additional music right now, while I havn't explored all of my music. I havn't even converted all my CDs into mp3 yet ...) and secondly my music taste is not mainstream; I don't want the system to recommend Maria Carey all the time.
Plus of course, I'm really interested in what techniques work well, and which don't... Thank you for any recommendations of relevant literature and methods.
Only one application has ever done this really well. MusicIP mixer.
http://www.spicefly.com/article.php?page=musicip-software
It hasn't been updated for about ten years (and even then the interface was a bit clunky), it requires a very old version of Java, and doesn't work with all file formats - but it was and still is cross-platform and free. It does everything you're asking : generates acoustic fingerprints for every mp3/ogg/flac/m3u in your collection, saves them to a tag on the song, and given one or more songs, generates a playlist similar to those songs. It only uses the acoustics of the songs, so it's just as likely to add an unreleased track which only you have on your own hard drive as a famous song.
I love it, but every time I update my operating system / buy a new computer it takes forever to get it working again.