This post is born out of a minor annoyance that I have occasionally been experiencing over the years being a contributor wanting to add more vinyl releases to the database. The idea behind this post is to highlight some shortcomings of the types of data that can currently be added to the database and to (hopefully) accelerate the process of getting these missing features implemented. I am fully aware that I’m not entitled to anything in regards to the development of MusicBrainz, but I hope this post at least gets considered when choosing what next to work on or when setting priorities. I would also be interested if I’m the only one who’s stumbled upon this, or if other people also have hit similar speed bumps when adding stuff to the database.
What is causing my annoyance?
I have a vinyl collection that I have slowly been trying to digitize in order to preserve the music as most of it never got an official digital release and the records will eventually degrade. I want to tag the resulting files using Picard, so the vinyl releases have to be in the database. In most cases, the quickest way for me is to import existing data from Discogs, but I’m always a little annoyed by the fact that some types of data pertaining to the physical format of the release don’t have a corresponding field in the MusicBrainz database, but I would definitely like to put in there. My current workaround is to copy this data into the annotation field, though as a data nerd, having to put structured data into free-form text fields always leaves me with an uneasy feeling. It also means that if we ever get fields that cover some of that data, I’d have to revisit previous releases I’ve added and move the data into the new fields. As a result, I’ve mostly been putting off adding my vinyl releases to MusicBrainz until the day I’ll be able to add all the data I want in one go.
What would I like to see added?
I’m mostly looking at Discogs for what I would be interested in entering into MusicBrainz. This includes (in order of importance to me):
- playing speed (16 / 33 / 45 rpm; also interesting for tape)
- runout numbers / matrix codes (this would also be interesting for CDs)
- number of channels (mono / stereo / quad)
- white label / test pressing / stickered label
- colour
- limited edition (if available, how limited)
It would be great if some of these can be tied to individual media in a release, because as a collector of dance music, I frequently have releases coming in both 33 and 45 rpm that are not labeled clearly on the disc. This would also be an improvement over Discogs where it looks like this data can only be attached to releases and not each medium separately.
What is the current state of development?
Before I start complaining and it turns out, that this has already been implemented and I just missed it, or someone is implementing this right as I type, I thought, I better try to dig a bit deeper into MusicBrainz development to get an overview of what’s currently being worked on.
I first started by searching the bug tracker and came across STYLE-781 Add “Matrix” and “Runout” for Releases/Mediums, which in turn refers to MBS-8393 Extend dynamic attributes to all entities. MBS-8393 looks pretty much like what I’m looking for. It actually describes a more general approach of adding data to various entities in the database which sounds awesome and includes the stuff I’ve suggested above! The ticket mentions that such a mechanism already exists for works, which I forgot, but it looks pretty much like what I had in mind for releases.
MBS-8393 has been marked as unresolved since 2015 and there is little indication of development activity other than potential inclusion for schema changes in 2016 (though the link doesn’t give much more context). Other than that, there is a comment by Michael Wiencek estimating the work required to implement the change:
Estimated time to complete (SQL only): 1-2 days.
Estimated time to complete (UI): 1-2 weeks. Code for work attributes should be reused; integration with the release editor might get messy, as usual…
To me this mostly indicates, that implementing the change doesn’t require rewriting half of MusicBrainz, which is a relief, but it still looks like not a lot has happened since this comment was made in 2017.
At this point, I’ve tried to dig a bit deeper. It looks like MusicBrainz development is organized in IRC in addition to the bug tracker. Chatlogs are online and searching through them I found out that @yvanzo tackled this issue back in 2017:
[21:09] <yvanzo> Then, I mainly worked on extending dynamic attributes for the next schema change.
[21:13] <yvanzo> This week, I polished new medium attributes (still MBS-8393) to allow filtering attributes (type/value) by medium format. […]
Their changes were merged in May 2017: Pull Request
So, why is MBS-8393 still unresolved? Turns out that the changes only cover the database schema, but the user interfaces is missing support for the new fields. A new annex to our beautiful data palace has been built, but it’s still missing the doors to actually enter the new rooms, let alone fill them with furniture.
The chat logs also indicate what’s been happening to the ticket since 2017:
[20:09] <CallerNo6> hi all, what’s the current thinking on [MBS-8393] ? back-burnered? rainy day project?
[…]
[20:52] <bitmap> CallerNo6: hey, pretty sure it’s been back-burnered until we finish the react conversion for edit pages. though I’m sure it’ll get done this year
[03:19] <SothoTalKer> yvanzo: what is the status of [MBS-8393] ?
[…]
[08:19] <yvanzo> SothoTalKer: development suspended for months, should get back to it after schema change 2019 Q2 features
[13:31] <ZaphodBeeblebrox> reosarevok/yvanzo: how do you feel with setting [MBS-8393] as “high” ? it’s something with A LOT of tickets depending on it
[13:50] <yvanzo> ZaphodBeeblebrox: It is indeed the other main schema change stuff lagging.
[13:52] <yvanzo> But development priorities are set as a whole, React is the current one, see Development / Priorities - MusicBrainz (at least the MB/CAA part)
[13:55] <yvanzo> Just like alt tracks, changes need to be reworked to fit with React.
It looks like the completion of the ticket has been severely held back by the React conversion (MBS-8609), but looking at the outstanding task list it appears as if this will soon be completed (for appropriate definitions of “soon”), so I’m hopeful that MBS-8393 can soon be finished.
Conclusion
For quite some time I have been missing some fields when adding vinyl releases to the database. In this post I first complain, then dive into the development history and find out that fixes for my complaints have already been identified and partially coded, but some parts to complete it have been waiting to get implemented since 2017.
