Developing music apps, OneMusicAPI announcements and more.
Over the past months we’ve been asked for multiple new features, which we’ve been shipping to prospective (and now current) clients. We thought it was about time we cut a new API version, imported the docs to the website and made an announcement!
Posted on 21 April 2022.onemusicapi.com uses S3 to cache images that are loaded from upstream data sources and sent to clients. The bucket used for these images allowed anonymous upload, but this was never a security issue because files were only uploaded from EC2 instances that had a suitable EC2 IAM role.
We created an EC2 instance that didn’t have any EC2 IAM roles, and used it to add some images to the cache. After the process was complete (which took several days), we found that the added images were not accessible, and found that it was due to permissions errors from S3. Further investigation in the AWS console confirmed this, and also showed that the object ACLs weren’t accessible.
Posted on 07 June 2021.We’ve recently been performing some memory optimisations on OneMusicAPI to improve the performance of the service.
One aspect we explored was the memory use of cached code. We use a lot of Scala in the codebase and were concerned that many classes were being generated, cached, and using up memory space.
So we broke out the tools and dived into some lesser-known Java tools to analyse how much memory is being consumed in the code cache.
Posted on 13 January 2021.Currently, OneMusicAPI only has a REST-style HTTP interface. We're now releasing an SDK for PHP which makes performing OneMusicAPI queries and lookups much easier.
How is it easier? Well, before we just exposed a HTTP interface, to which you could send query parameters and the like and receive JSON or images in response. Using the SDK you don't need to know worry about anything at the HTTP level and can just concentrate on using the service in your language of choice.
Posted on 14 October 2020.onemusicapi.com allows searching for releases by passing in track
positions and durations. The search allows the track durations to be off
by a couple of seconds, (TODO figure out the reasons for variation
), so
we need a fast method for performing fuzzy search on the track
durations.
Another requirement that makes things more complicated is that not all the input tracks need to match; a subset of the tracks matching (the actual fraction of tracks that need to match depended on other factors) need to be enough for the medium to match. However, this won’t be covered in detail here.
Posted on 08 October 2020.