I am pleased to announce that long time contributor and complainer about our UI/UX, Simon Hartman, AKA aerozol has joined our team as a part time designer!
While we are starting with a very modest 3 hours of his time per week, we feel that this marks a rather important step forward for our team. While we now have two team members who have UX/design skills (Monkey and Akshat), they also carry a significant load of engineering tasks working on their respective projects.
Having Simon as part of our team will allow us to carve out concrete design tasks for him to focus on. Simon and Akshat will also revive our long dormant design system, which lets us create UI components that are intuitive and consistent. Our engineering team will be able to re-use these components across our sites, simplifying the future development of new pages. We hope that this shared design system will improve the user interface across all of our sites, with a strong focus on bringing the MusicBrainz UI into the modern age.
Having concrete help on the design front has been needed badly for a long time, which makes me very excited to welcome Simon to our team. Welcome!
This was one of the initial Ensembling-version/family/ensemble instrument-type inspiring tickets.
Initially added on September 2017, it was delayed because it required all the sub-tickets for each instrument being created (and I’m lazy!).
Eventually GCI student mathure, with help from GCI finalist TheFaR8, researched and added a lot of the missing sub-ticket instruments. Many, many thanks to both of them!
There are still however many more gamelan instruments not yet added – if you want a particular one, please add a sub-ticket under INST-556!
Likewise there were a couple instruments that we couldn’t add, since they need to wait for MBS-9642 to be implemented and voice types becoming “instruments”, those being:
There’s also at least one more vocal “instrument” that has no ticket yet, but also can’t be added for the same reason: the kecak (a type of chanting). Additionally, alok and senggakan seem like they might also need adding, but I actually have no idea what these are since they only have Wikipedia page in Javanese ︎😅︎
Remember what I said previously about getting rid of metallophone? :D
hahaha, what a difference in opinion research will bring… ♪;︎
Since the gamelan included so many percussion idiophones (especially metal/tuned ones) it became a natural continuation fix of our previous (clapper tree mini-version).
That meant that we could finally fix up the metallophone/xylophone/lithophone mess under percussion idiophone!
This also included merging tuned percussion into percussion idiophone (“tuned percussion” as an instrument terminology on Wikipedia was deprecated anyway) and sorting out chimes and other related suches.
Stay tuned for कुछ वीणा सम्बन्धित चीजें!
¹ suuper thanks to ’19 GCI student Antara for additional research on this ticket.
I also decided to close the tambouras (strings) version, as after much delay there wasn’t really much progress on it. I had started work on these way back in January, adding the Tamburica instruments (see Instruments part two).
However, by the time ASP came to an end it had became clear to me that I had to move on from dwelling on this, to feel like there was progress and avoid burning out.
It’s time for Instruments again!
Now that I was allowed to create fix versions I set about creating such fix versions! (And also, retroactively (re)creating previous batches where these seemed logical.) This also meant creating JIRA Tickets for instruments I had already added without tickets, like the Taonga pūoro instruments.
By now, I was also starting to see the limits of the relationships between instruments we already had, so I was already thinking about what relationships could be added to improve the way we link things. As such, I created a topic to discuss some ideas I had (Reader beware! This is an early and now outdated idea-thread! (More on this in a later post!))
In the past couple years, we’ve steadily reduced the amount of standardisation we do, instead preferring to stick closer to the original release information (except for obvious errors) and let the end users do any standardisation as desired. The main rationale for this is that it’s generally easy to standardise automatically, but impossible to get the original information back: as such, standardisation is best done on demand over the original data. The last big step of this process is to simplify and soften the very restrictive featured artist guideline.
The guideline was originally written when we could only store one artist per track/release, as “add (feat. X, Y & Z) to the track title”. This allowed us to enter the featured artist information on the track title in a standard way in order to deal with it better in the future. And that worked fantastically: in fact, it allowed us to write a series of reports (for release groups, releases and recordings) that make it easier to find entities where the artists need to be moved to their rightful place in the artist field, now that we can!
When we started migrating the info to artist credits, we decided to basically keep the guideline as-is, but start adding the artists to the artist field. So we’d have “Song”, by “Artist feat. X, Y & Z”. This was a huge improvement, since the artists were now properly linked, but such strong standardisation was always a bit heavy handed, and at the same time quite restricted (since it only applied to variations on the word “featuring”, but not to any other linking phrase).
As such, we’ve decided to stop standardising credits using variations of “featuring” as well. The new version of the guideline can be found as part of the artist credit guidelines, and reads:
Featured artists should always be entered in the artist credit, not in the titles. You should generally enter the credit as it appears on the release, omitting any separators (like parentheses) that are intended to separate it from the track title. For example, if the tracklist has “Artist 1 – Song Name (featuring Artist 2)”, enter “Song Name”, by “Artist 1 featuring Artist 2”.
This decision was taken a few weeks ago, but to avoid disruption we waited until we had a Picard plugin available for anyone who still wants to standardise “featuring” in their own tags. That’s now available (thanks to Sambhav Kothari), so we feel it’s the time to make the change official. If you want to keep all variations of “featuring” as “feat.”, go ahead and install that plugin, and things should remain basically as they were!
One last note: I strongly encourage people not to vote against any edit moving featured artist information from the titles to the artist field, even if it doesn’t exactly follow the wording used on the cover. As always, any clear improvements like this one should be accepted, even if they’re not perfect, and the data can be improved further afterwards.
Jeez. This has been overdue! So a lot of things happened, and this Community Recap series kind of got put on the back burner, which obviously means a lot of things have piled up, so if I forgot something you thought should have been mentioned, please share it in the comments below. 🙂 I will be doing a few months at a time until I’ve caught up to the now().
A couple of weeks ago (Oct. 30th through Nov. 1st), the MusicBrainz Summit 15 took place in Barcelona, at Rob “ruaok”‘s place. We had all of the MetaBrainz employees there, Rob/ruaok (local), Michael/bitmap (US), Nicolás/reosarevok (Spain/Estonia), Roman/Gentlecat (recently local), Laurent/zas (France), and myself, Freso (Denmark) – in addition to a bunch of other people from the community: Sean/Leftmost (US) and Ben/LordSputnik (UK), the two lead developers of BookBrainz; chirlu (Germany), long-time volunteer developer on MusicBrainz; and Alastair/alastairp (local), lead of AcousticBrainz. Between us, we represented 7 countries, 8 nationalities, and 9 languages.
We managed to cover a lot of ground on the serious topics, discussing how to avoid data/MBID loss and how to version data, how to deal with labels (the entities, not the corporations…) and other unresolved style issues, how to integrate all the various *Brainz projects more and better, and a bunch of other things. The official notes for the summit is stored in a public Google Docs document. Feel free to read through and it jot down your own comments!
One of the big things was the we decided again-again-again (for the third or fourth year in a row?) to release the translations of MusicBrainz.org. But this time we actually did it! So MusicBrainz.org is now available in German, Dutch, and French (in addition to English) – go check that out if you have not done so already. 😉 At some point in the not-too-distant future™ we will also enable translating all of our documentation. Sean/Leftmost volunteered to look into options for this. Expect to hear more on that later!
We had some talk about how and why MBIDs get lost and what we can do to prevent this. As part of this discussion, we decided to make more edits autoedits for everybody. This was partly due to a wish of having a shorter queue of open edits (and there’s been a significant drop in open edits since Nov. 16!), but also very much to avoid losing MBIDs once they have been generated. More in depth discussion of the reasoning (and some of the community’s response) can be seen in the server release blog post and its comments.
We talked about a few other things like genres, reviewing the work of the style BDFL and the community manager, the future direction of the MetaBrainz Foundation, and a couple of other topics. The summit notes should contain more information on what we talked about and decided on these points.
Obviously it was not all talk and talk and talk. There was also plenty(!!) of chocolate. yeeeargh helped us by getting a lot of Ritter Sport as he apparently lives right next to their factory, and sending it along with chirlu to Barcelona. Thank you, yeeeargh! We also managed to take in a vast amount of gelato (Italian ice cream), as there was an amazing gelato place close by Rob’s apartment. And got to walk a bit around the city of Barcelona. And have various social hanging out that only most of the time was Meta-/MusicBrainz related… but not all of it. 😉 Our system administrator, Laurent/zas, also took a bunch of pictures capturing the summit. A few of them are shown here, but you can peruse them all in the slideshow at the bottom.
Finally, a big thank you to Google and Spotify for helping to fund this meeting. It would have been a lot harder to bring all these people together from around the world without their (continued, no less!) support. Here’s to 2016 and summit 16!
Hi everyone! Here we are with another very, very late style update for the last couple months.
Apart from quite a few smaller changes (full list below), we split the translator relationship so that it’s its own relationship rather than lyricist + attribute (so if any of you were using translator data at all you’ll want to change the way you query for it). Similarly, we got rid of the “transliterated” vs. “translated” difference for alternate tracklists: it often wasn’t clearly one or the other, and the information wasn’t particularly useful in any case without checking the language and script of the release, so now there’s only one relationship type without attributes.
We also demoted the “Do Not Cluster” guideline – while it’s a good thing to keep in mind when creating relationship types, it’s not really something users should be worrying about (and the cases where they might have to are already covered in the specific relationship documentation).
If anyone has any question about these or any other changes, feel free to ask in the comments! And if you want to propose other changes or additions, remember you can always do it from the STYLE section of our bug tracker.
[STYLE-315] – Remove the option to add publisher relationships to recordings
[STYLE-474] – Introduce the option to add phono rights relationships to recordings
[STYLE-481] – Add artist-release group “has dedication” relationship
[STYLE-505] – Add “written at” relationship between work and place/area
Ok, so the “have a report every two weeks” thing didn’t work out very well lately. But things have been happening anyway, so here’s all that has happened in the last few months!
Guidelines for artists have been updated for what is and is not a different artist (since now relationships can also have credits) and for areas (main artist area is still somewhat fuzzy because it is a fuzzy concept, but at least there’s something now).
Also new (although most parts were just moved into it from existing guidelines where they didn’t really fit) are the guidelines for artist credits.
The English guidelines got cleaned up a bit, but without major changes (only the addition of a section on “O’Clock”).
The alias guidelines got updated to take into consideration the “primary for locale” option, and got a section for sort names (based on the old guidelines for label sort names, which were removed since labels themselves no longer have sort names).
The ability for work-work relationships (like “part of” and “version of”) to have dates was removed. Dates should be on the appropriate artist-work relationships, in most cases (like “arranger” and “translator”), and works which get new parts added / removed should be counted as different parent works to begin with.
The guidelines mandating expanding abbreviations like “Vol.” and “Pt.” have been removed (the special exception of “feat.” has not changed). Titles should, in general, follow the release/track title. The only standardisation left is for series: see the series numbering guidelines.
Some basic work guidelines have been added, both for when to set a type and for when (and when not) to add a disambiguation comment.
Apart from that, a fair amount of relationships and release formats have been added and some sites whitelisted. See the full list below for details.
[STYLE-427] – Style/Artist hasn’t been updated for areas
[STYLE-524] – "Personal label" has the wrong cardinality
[STYLE-149] – Update "Artists with multiple names"
[STYLE-203] – Add a "In homage to" relationship to works
[STYLE-228] – Allow grouping of multiple "identical" bootlegs w/ different titles
Version 1.3 of Picard has been released today, with some notable features and bug fixes.
This release has few visible changes, but overall performance and stability were much improved. A lot of minor annoying issues were fixed. Cover art code was reworked, and notably one can now enable fallback on release group cover art if no cover art exists for a specific release.
Logging was improved, user can now enable debug mode from About →View Error/Debug Log, it may help to see what is going on if needed, passwords and sensible information were hidden from the log, so user can now safely post his log to get help.
To report any issue concerning this release, please use our bug tracker. As usual you can also get help on forum or on IRC (freenode, #musicbrainz).
Special thanks to Sophist, Wieland Hoffmann, Michael Wiencek, Johannes Dewender, Lukáš Lalinský, Frederik “Freso” S. Olesen, and the whole MusicBrainz Team.
Many thanks to all users, developers, bug reporters and translators. Code contributions since 1.2 are visible on Github Contributors graph.
Unfortunately the OAuth support patch (PICARD-305) didn’t make it in this release.
Be aware that downgrading from 1.3 to 1.2 may lead to configuration compatibility issues, better save your configuration before installing 1.3 if you intent to go back to 1.2.
Among changes since 1.2:
The “About” window now displays the versions of libraries used by Picard
Picard now correctly handles matching of MP3 files saved in ID3v2.3 tags (which is the version that Microsoft Windows and iTunes both use).
Note: You may need to re-save your tags once to get them to match in future.
A sort tags plugin is now provided as tag data is no longer displayed sorted by default.
A new tag, musicbrainz_releasetrackid, containing the MusicBrainz Track MBID introduced in the May 2013 schema change release, is now written to files.
A new advanced option is available to permanently set the starting directory for the file browser and “Add files/folder” buttons.
Requests to Musicbrainz against your own account e.g. for collections are now handled through SSL (PICARD-337)
Refresh of Albums using Ctrl-R and selection of Other Releases are now more responsive during batch lookups.
Main window is now emitting a “selection_updated” signal, plugin api version bumps to 1.3.0
Append system information to user-agent string
Compilation tag/variable functionality (for tagging & file naming) has been split into two:
– %compilation% is now aligned with iTunes, and set only for Various Artists type compilations
– %_multiartist% variable now indicates whether this release has tracks by multiple artists
(in order to prepend the artist name to the filename as shown in the default file naming script)
Ignore directories and files while indexing when show_hidden_files option is set to False (PICARD-528)
Add ignore_regex option which allows one to ignore matching paths, can be set in Options → Advanced (PICARD-528)
Added an “artists” multi-value tag to track metadata, based on the one in Jaikoz, which contains the individual artist names from the artist credit. Also useful in scripts (joining phrases like ‘feat:’ are omitted) and plugins.
Added “_artists_sort“, “_albumartists“, “_albumartists_sort” variables for scripts and plugins.
Made Picard use the country names also used on the MusicBrainz website (PICARD-205)
New setup.py command `get_po_files` (Retrieve po files from transifex)
New setup.py command `regen_pot_file` (Regenerate po/picard.pot)
New Work tag (which for Classical music is often different from the track title) saved as ID3 TOAL tag.
New Composer Sort Order tag (variable %composersort%).
Improve the Other Releases list to prioritise and separate releases which match the correct number of tracks and your Options → Metadata → Prefered Releases settings for Country and Format.
New %_absolutetracknumber% variable numbering tracks sequentially regardless of disc structure (so you can numbers tracks on multi-disc releases without a disc number)
Support dropping image directly from Google image results to cover art box
Add %_musicbrainz_tracknumber% to hold track # as shown on MusicBrainz release web-page e.g. vinyl/cassette style A1, A2, B1, B2
Show the ID3 version of the file in the Info… dialog (Ctrl-I) (PICARD-218)
Fixed a bug where Picard crashed if a MP3 file had malformed TRCK or TPOS tags (PICARD-112)
Add –files option to setup.py build_ui, used to force .ui to .py regeneration (PICARD-566)
New setup.py command `update_constants` (Regenerate countries.py and attributes.py)
Made Picard use release groups, medium formats and cover art types also used on the MusicBrainz website
Use MusicBrainz Server translations for release groups, medium formats and cover art types
Add checkbox to toggle debug at runtime in log/debug view dialog
Add a plugin to add Artist Official Homepage relationships to the website tag (ID3 WOAR tag)
Add integrated functions $eq_any, $ne_all, $eq_all, $ne_any, $swapprefix and $delprefix.
Add %_performance_attributes%, containing performance attributes for the work e.g. live, cover, medley etc.
Use $inmulti in file naming scripts i.e. …$if($inmulti(%_performance_attributes%,medley), (Medley),)
Add optional `priority` parameter to `register_album_metadata_processor()` and `register_track_metadata_processor()`
Default priority is `PluginPriority.NORMAL`, plugins registered with `PluginPriority.HIGH` will be run first, plugins registered with `PluginPriority.LOW` will run last
Add Standardise Performers plugin to convert e.g. Performer [piano and guitar] into
Performer [piano] and Performer [guitar].