GSoC 2019: Bringing back MusicBrainz for Android to life

Tags: #<Tag:0x00007f2a5ccf8ec8> #<Tag:0x00007f2a5ccf8d60> #<Tag:0x00007f2a5ccf8bd0>

Personal information

Nickname: amCap1712
IRC nick: amCap1712
I am a former Google Code-In participant. I was selected as a finalist by MetaBrainz in Google Code-In 2017.


Background and Overview

MusicBrainz for Android was first created in 2010-11 as a part of GSoC. Since 2015, no updates have been made to the project. The app is currently broken as the it does not adhere to android ecosystem. I feel a mobile app is a necessity for an organization like MusicBrainz. A mobile app will help increase user engagement and open up MusicBrainz to a plethora of new users.

Proposed Use Cases

  1. Search MB entities and view their details.

  2. View and search collections through text and barcodes.

  3. Add/Edit tags, ratings and collections. (for registered users)

  4. Tag music using MusicBrainz. (A basic implementation of Picard)

Technical Overview

Here is tentative list of tasks, I intend to undertake. I have also mentioned an estimate of the time required to do each of them.

Step 1: Migrating the existing codebase

The existing MusicBrainz app provides the facility to search for an artist/release in the database, to view collections if a user is authenticated and donate money to MetaBrainz foundation via PayPal. Sadly, many of these features are broken as the app is outdated.The first task will be to re-work the app so that the all features currently offered work again.

  • Currently, the project uses Maven as build automation tool. But Android has long moved to Gradle. All dev tools are only compatible with Gradle. So the first task is to port the project to Gradle. Android support libraries have now now migrated to AndroidX, our app will also do so.

The external dependencies of the app are Novoda ImageLoader, ViewPagerIndicator, Apache HttpComponents & Paypal. All of these need to be replaced due to one-another reason.

  • Novoda ImageLoader is no longer in development. It will replace with Glide.

  • Apache HttpComponents is obsolete and all its functionalities are offered by native OS APIs. The current networking API will be modified to use native OS support instead of this library.

  • Same goes for ViewPagerIndicator, a GUI library which be replace by Android Arch Components.

  • Paypal Android SDK (infact all Paypal libraries) are now deprecated. The recommended replacement is BrainTree but it requires to configure a custom server in conjunction with the app. For the time being, existing Paypal integration will be removed(currently it is not in working state) and the Donate page will redirect to MetaBrainz Website.

  • The residual and unneeded files will be removed. The existing files will be reorganized to ensure a clean architecture.

By this time, I believe I will have used up one and a half week.

  • With Android 23, the permissions API underwent a major change. To become compatible with newer Android versions (Marshallow and ahead), the way the app handles permissions needs to be changed.

  • Coming to the Login feature, I intend to add OAuth2 functionality. Users will be able to use MusicBrainz credentials to allow the app to access their data just like other MetaBrainz projects. The user will be prompted to Login in the browser and allow access. Irrespective of the user’s decision, the user will be redirected to the app and greeted with an appropriate message.

Another week will be required to finish the above two tasks.
With this Step 1 is over, we now have an app which on the outside resembles the existing version but possesses a remarkable different and cleaner core.

Step 2: Adding new features (Backend)

Now that our app is working, we will add new features to it except Tagging facility. This will be done in 2 steps. In the first one, we will add backend code for them and in the second one, the necessary GUI will be added.

  • The app uses a custom java api to access MusicBrainz database. Currently, the app only searches for artists/releases and not other entities available in the website search dialog. So the API needs to be extended to search/lookup all entities in MusicBrainz. Also, the parser will be migrated from XML to JSON. I will attempt to reduce bandwidth usage and number of requests.

  • Background tasks and Network request are currently handled with Async Tasks and Loaders but Loaders were deprecated the last year. To become, future-proof I will attempt to replace Loaders with Android Architecture Components. Therefore, the entire way concurrency is handled by the app will be modified. This will improve performance and stability.

  • Functionality to search releases through Barcodes will be added using Zxing Library and to allow logged in users to add/edit tags and ratings. This will be added on the top of login framework already set up earlier.

Now getting as to what will be available for end use as a result of the above modifications. The users will be able to search these entities Artist, Release, Recording, Release Group, Instrument & Event. The users will be able to navigate between entities. For example:- If a release is clicked on an artist’s page, it will open up. There will be recent search suggestions as well. All of these entities will have individual info pages. The users will be able to search releases using barcodes as well. Logged In users will be able to view their collections and add/edit tags & ratings.

With this, I will exhaust a month of GSoC.

Step 3: Add new features (Frontend)

We improved the framework of the back. Now, its time to repaint the app.

  • The GUI of the app will be reworked to match the current MusicBrainz theme. Extra buttons and screens where ever needed will be added. I will prepare GUI mock ups beforehand for getting feedback from the community.

  • I will add support for international languages in the app. As suggested I will use Transifex for translations. I intend to provide support for all languages currently supported by MusicBrainz. Transifex and Android provide out of the box support for i18n so the task will be not lengthy.

More GUI mockups to be added soon.

We thus come to end of another two weeks.

Step 4: Adding the tagging facility

Till now, we have done some minor upgrades to the app’s usability and brought substantial changes to its interface. Now its time do a major upgrade. Finally, we implement a basic Picard for our app. (Yay!! I’m really excited.)

To begin with, as per my understanding the feature will have 2 dependencies JAudioTagger & FpCalc-Android. JAudioTagger will be used to manipulate metadata of the audio file ie. reading and writing. FpCalc Android provides an Android compatible Java wrapper for Chromaprint. The implementation will match desktop Picard’s implementation. In case of doubts, I’ll consult Picard developers. But as of now, the decided version is as follows:

  • There will be 2 options to match metadata to tracks namely LookUp and AcoustID Fingerprinting. As part of the GSoC project, the final app will facilitate to tag only one track at a time.

  • Coming to LookUp, first the metadata of the track will be read. The metadata fields, namely, Title, Album, Artist, Track Number & Total Tracks will be included in the search query to MusicBrainz Webservice. Each item in the search result, will be processed to calculate a Similarity score using the Weighted Levenshtein Distance. The best match will be displayed to the user and there will be an option to view all results and select an alternative as well. Then, upon clicking the save button the metadata will be written to the audio file.

  • Now onto the Fingerprinting part, the AcoustID fingerprint will be calculated using the FpCalc Android wrapper through Chromaprint algorithm. The audio fingerprint will be sent to the AcoustID webservice. A lookup request will performed on MBIDs of the recordings returned by AcoustID. The result will be displayed to the user and the user can save the metadata.

I believe this is a time intensive feature and will require around a 30-40 to be finished. I plan to dedicate 14 days to each option. The remaining 10-12 days will be used to build the supporting UI and act as an internal buffer period.

Note:- The reason behind the internal buffer period is that the original libraries on which the feature depends are not completely compatible with Android. So, I might end up using unofficial forks of the libraries mentioned. I will experiment before to make sure if the selected libraries work fine but just in case, it dosen’t :wink:.

Step 5: Wrapping Up

Its time to wind up the work of 2 months. The app will be tested intensively by the community and bug fixes will be made. I will be documenting the code side by side but will review it during this period for clarity.

I estimate another one and half week to pass by.

Step 6: Stretch Goals (Optional)

Until now, all the listed tasks were a necessity, now we come to those ones which will be completed only if time permits.

  • To improve performance of the app, a local cache database using Room will be implemented to store latest query results.

  • Add functionality to search using voice.

  • To create an Google assistant action for the app. With this, the app’s features can be directly accessed using Google Assistant.

Current Progress

Since, I have been working on the app independently of GSoC, a part of the work is completed. The test version of the app is accessible at . A changelog for the same is available at MusicBrainz for Android Changelog .

  • The migration of the app to Gradle file system and AndroidX is complete.

  • The obsolete and deprecated dependencies are completely removed. They are being replaced as the app is being refactored.

  • Search results page is complete. Recent search suggestions are in place.

  • The details page of Artist is complete. For other entities, it is in the works.

  • Basic OAuth framework is set up. Although, a lot of work is to be done on it.

There are a few other community posts on specific topics relating to this proposal. They are linked below.

Weekly Schedule

An estimated schedule is provided alongside the detailed description of the tasks to be undertaken. Here I provide, a summary of it.

  • Week 1: Complete search pages.Start work on entity details info pages.

  • Week 2: Complete details pages and add robust navigation between them.

  • Week 3: Complete login flow with OAuth. Start adding option to view collections and ratings.

  • Week 4: Work on editing collections and ratings.

  • Week 5: Add barcode search and submission.

  • Week 6 : Implement new GUI.

  • Week 7 : Add additional languages support.

  • Week 7 - 9: Begin adding tagging facility. Implement tagging using lookup of existing metadata.

  • Week 10-11: Implement tagging using audio fingerprinting and AcoustID.

  • Week 12-13: Bug fixes, testing and completing documentation. Buffer Period.

I intend to begin coding right from start of community bonding period.

Detailed information about yourself

  • Tell us about the computer(s) you have available for working on your SoC project!
    I have a HP laptop with 8GB RAM, 1TB Hard disk and 2GB graphics card. The main tool required for the task is Android Studio which runs smoothly on this system.

  • When did you first start programming?
    I started programming when I was in Grade VI as a part of school curriculum.

  • What type of music do you listen to? (Please list a series of MBIDs as examples.)
    I love listening to Punjabi Music. Some of my favorite artists are Amrinder Gill, Sidhu Moose Wala & Guru Randhawa.

  • What aspects of the project you’re applying for (e.g., MusicBrainz, AcousticBrainz, etc.) interest you the most?
    The prospects of cleaning up my entire music library on my mobile automatically sounds just great. Also I prefer mobile apps to websites, so I am making work easier for me with project.

  • Have you ever used MusicBrainz to tag your files?
    Yes, I use it regularly say on a weekly basis or so.

  • Have you contributed to other Open Source projects? If so, which projects and can we see some of your code?
    I have contributed to a couple of other open source projects which can be seen at my Github Profile. I have been the co-moderator of an app built to raise awareness on women safety.

  • What sorts of programming projects have you done on your own time?
    I have done many programming projects. Many of them are personal ones. I usually do Android projects but I have worked on a few python projects as well. The apps I have built include a news app, a notice delivery app for my school and some fun personal projects.

  • How much time do you have available, and how would you plan to use it?
    I will be working full time on this project in GSoC.

  • Do you plan to have a job or study during the summer in conjunction with Summer of Code?
    No except for the last fortnight, I don’t have any such plans. In the last fortnight, I will attend orientation classes at my college.


Hi @Kartik_Ohri I have just posted an update about the MB app I was interested in. Please read this post and feel free to comment there what do you think about the technologies I propose.

Thank you!

Overall it looks like a good GSoC project :slight_smile: This app needs some love.

About app i18n, almost all MetaBrainz projects are using transifex to manage translations.


Looks very promising! Schedule should be much more concrete though.

Here are a few additional suggestions:

Along with migrating to JSON web service, you may also want to consider the following task:

The app should probably require less permissions, according to Google Play users feedback:

As you rewrite the app, you may want to avoid using proprietary dependencies:


I will take up the task to add OAuth 2 for logging in and avoid proprietary dependencies.

I have begun preliminary work on the app. The test version of the app is accessible at


I checked out why F-Droid had rejected MusicBrainz for Android. It was a dependency issue. I have planned to remove and replace it with an acceptable one. So, we are good to go. Also with MBS-9999 JIRA Ticket coming into shape, OAuth framework is almost ready.


@amCap1712 I have written some User Stories (As <persona>, I can <what?> so that <why?>) to illustrate some ideas I have in mind for mobile app. Maybe through sharing these visions we can narrow the scope of GSoC.

  1. As a person who has just listened a song on TV, I want to search the song title so that I know more about it, its lyrics, and what recordings have been made to listen to them in Spotify.
  2. As a person who has just known about an artist, I want to search it by name so that I know some bio facts, where to follow (social media) and most recommended/best rated releases to listen them in Spotify.
  3. As a fan of a famous violinist, I want to see a list/timeline of all the recordings he made along his life sorted by date so that I can see the evolution of his playing during his life. (This is a project I did myself)
  4. As a registered user, I want to create a collection of the CDs I’ve bought for years and to save them easily by scanning the barcode so that my collection is organized.
  5. As a registered user, I want to rate and tag releases and recordings I’ve searched so that I can know what releases/songs I’ve listened and sort them by rating.
  6. As a registered user, I want to find my friends and subscribe to their collections so that I’m updated with additions they make.
  7. As a registered user, I want to subscribe to an artist or a label so that I can be notified when a new release is available.
  8. [NEW] As a registered user, I want to search easily (by text or by barcode) so that I find matches either in my collections or in MB’s data.

I think them as real Use Cases that can help in designing an optimized UI/UX for them. Let me know your thoughts about it.

1 Like

If I’m at a garage sale, I’d like to be able to scan the barcode of CD and have the app tell me that I own the vinyl version. IOW, I want to know if I own any release in this release group.


This sounds similar to what e.g. nusic is doing.


There are things on “Steps” that are not scheduled. Let me share my time-estimations per feature:

  1. Step 1 - Login feature: users can login, but no feature has been planned. Either we should plan letting the user interact with its account (favourites, collections, tags, rating) or disable login and start with anonymous users.
  2. Step 2 - Search all entities: Implementing all would require two long weeks, as not only fetching the data but designing all pages.
  3. Step 2 - Barcode search: don’t know the status of this, but requires Camera access. Maybe one long week for this?
  4. Step 3 - GUI redesign: if we plan mockups before GSoC, we could implement all redesign quite quickly (2 weeks for all the app?
  5. Step 3 - Translations: don’t know the technical challenges of I18n the app (1 week?)
  6. Step 4 - Picard feature: I would schedule more than a month for this. It’s not just Android, but libraries and audio techical knowledge needed.
  7. Step 5 - Testing/Documenting: I would exclude tests for now. And I would document the code AS developing, NOT AFTER. That way you can save this time for other things.

Could you review the “Steps” and the “Schedule”, and share your thoughts on timing? I want to have plenty of time for each step because very often things don’t go as we expected (see the Artists feature)


Thanks for the comments.

  1. Step 1 - Login feature:- Logged in users will be able to view collections, tags and ratings.
  2. Step 2 - Search all entities: A large part of work is complete. The info pages is the major part left. I hope to reuse the process from Artist Info Pages to speed up work.
  3. Step 2 - Barcode Search - I will be using Zxing library which comes with out of box support for scanning barcodes. So, it will not take more than a couple of days.
  4. Step 3 - GUI redisgn - I agree with you on this part.
  5. Step 3 - Translations - This shall take 3-4 days.
  6. Step 4 - Picard - I agree with you on this. The more time the better. I’ll try to reschedule to add a week or so here.
  7. Step 5 - Testing/Documentation - I will document the code side by side and unit tests we’ll put aside for the moment. For now, only manual testing.
1 Like

I just downloaded the app and will test. Really looking forward to it. What I would really like, is to integrate it with some players, so when I rate a song it is written to the MB database. Keep up the good work!


Hi Richard,
Thats a good suggestion. We could implement that a later stage. The current priority and as a GSoC project is to ,as the name suggests, bring back the app to life. Looking forward to your feedback regarding the app.

As of now, the following work has been completed:

  1. Except the tagging feature, the work on other features is complete. The GUI of the app is still to be worked on.
  2. As for the tagging feature, here are the details:
    • The match finding algorithm is ready and works fine.
    • The user is able to select the desired audio file.
    • JAudioTagger and FpCalc Android ,the proposed libraries, work well.
    • As for the lookup feature, the app is able to read tags, calculate the similarity score and decide a best match.
    • For Acoust ID fingerprinting, the app is able to fingerprint an audio, and query AcoustID api for details.
    • The main part of the work that is left is writing the updated metadata to file tags and GUI for the whole process.

Thanks for sharing this update, this sounds very cool. It’s great JAudioTagger and fpcalc are working well.

1 Like

I saw this topic a while back and am excited to know that progress is coming along smoothly! Looking forward to testing a build with a completed GUI for tagging.