Thank you so much for reporting bugs in our Picard 2.0.0beta2 release. We fixed most of the critical bugs that you guys and gals reported. You can find the beta3 release with the fixes here – Picard 2.0.0.beta3
If you have been following our Picard related blogs, you will know that we decided to release a new stable version of Picard before the beginning of the summer.
To help us, advanced users, translators and developers are encouraged to:
Note – If any of you are seasoned Windows/macOS devs and have experience with PyInstaller, we need some help with PICARD-1216 and PICARD-1217. We also need some help with code signing Picard for OSX. Hit us up on #metabrainz on freenode for more information. We will be very grateful for any help that you may offer!
A simplified list of changes made since 1.4 can be read here.
Be aware that downgrading from 2.0 to 1.4 may lead to configuration compatibility issues – ensure that you have saved your Picard configuration before using 2.0 if you intend to go back to 1.4.
Rob, Suyash, Param and I met in the bustling city of Delhi where “horns are applied very liberally” (it is a very noisy city!) for a mini summit. Some may even call it elaborate break-out sessions on ListenBrainz and CrtiqueBrainz. We had discussions over a span of two days over laptops and notebooks, riding on bumpy roads in tuk-tuks and over spicy chicken biryanis. Here is a summary of all that we discussed:
ListenBrainz Data Visualizations We started Day 1 with graphs for ListenBrainz. After a long marathon of heavy development weightlifting tasks by Param and Rob (how do we work with BigQuery correctlty?), we are finally at a stage, where we can have some really cool amazing visualizations out of our dataset. What will they be? Where will they be? How will we implement them? Can our community pitch in with requests and maybe even play around with code?
After scrounging through a lot of other websites which do music-y data visualizations, and the few responses on our user survey, we started listing various ideas, and went through ideas on our community forum. We ended up dividing the data visualizations (from now on, called graphs) into two categories:
User specific graphs: showcasing a user’s listening history and taste Site-wide graphs: showcasing the overall listening patterns on ListenBrainz
We had to make some tricky calls based on technical constraints, but overall, for starters, we decided some cool user graphs. We have detailed 6 of them over the summit:
Listening history of a user: how much have you listen-ed, what you have you listened too, listen counts, etc
Your top artitsts
Your tracklist (listen history)
How much music did you explore
Which artists are trending in what parts of the worlds
Listener count across the world
All these graphs will be available over different time durations (last week, month, year) and will also have handles to manipulate them. They will also have tools to easily share them on social media networks. We think, our community will really enjoy tracking their listening history with these. We also discussed a few ideas of how we can create a sandbox so our community can pitch in with ideas, vote on ideas and send pull requests for new graphs. More on that later, as we get there!
Rating System If you are listening to a tracklist while working over something, how possible it is that you will rate a track saying “This is 3.5? This is 4.2? That is 5 stars!” So you see, ratings on ListenBrainz are tricky. It is very dynamic and interactive in real time, unlike other dear *Brainz projects, so we think that a Last.fm-like rating i.e like and dislike makes sense for ListenBrainz. There was also some discussion about where the ratings should reside — is CritiqueBrainz the correct place?
Home Page We worked on redesigning the “My Listens” page as well the home page. We now plan to include, apart from the graphs, an infographic explaining how ListenBrainz works and things you can do with it! I will further detail out the mockup later this week.
Potential Roadmap After almost two days of discussions, we could chalk up a rough roadmap for ListenBrainz, which include data visualizations, ability to rate/like tracks, create collections, follow users, and more. This also includes encouraging cross brainz pollination!
CritiqueBrainz With Suyash around (he worked on Critique Brainz as part of GSoC last year, and has been actively involved since), there were obviously a lot of discussions on reinvigorating the project. We discussed quite a few ideas, which included innovating ways of writing and sharing reviews, sharing it on social media, cross *brainz interactions, a few UI changes, etc. We’re considering allowing Quick Reviews that, like Twitter, are limited to 280 characters. What do you think? Suyash has written down his ideas for the same and would love some feedback from the community!
And of course! We couldn’t let Rob’s first visit to India be all about work. After the sunset, we went exploring the city of Delhi. That included rides in tuk-tuks, spicy chicken biryanis, shopping for some colorful clothes and definetly, the Indian chaat 🙂
All in all, it was a very productive mini summit and definitely made us all, more excited to start working on the ideas we discussed. We will keep you updated and post more soon!
Some A lot of Indian food!The troope at India GateParam is really into (a lot of) selfies.
Thank you so much for reporting bugs in our Picard 2.0.0beta1 release. We fixed most of the critical bugs that you guys and gals reported. You can find the beta2 release with the fixes here – Picard 2.0.0.beta2
If you have been following our Picard related blogs, you will know that we decided to release a new stable version of Picard before the beginning of the summer.
To help us, advanced users, translators and developers are encouraged to:
Note – If any of you are seasoned Windows/macOS devs and have experience with PyInstaller, we need some help with PICARD-1216 and PICARD-1217. We also need some help with code signing Picard for OSX. Hit us up on #metabrainz on freenode for more information. We will be very grateful for any help that you may offer!
A simplified list of changes made since 1.4 can be read here.
Be aware that downgrading from 2.0 to 1.4 may lead to configuration compatibility issues – ensure that you have saved your Picard configuration before using 2.0 if you intend to go back to 1.4.
We received so few bug reports on the beta release of the ListenBrainz web site, that we decided to push those changes live and start working on new features. This release is substantially unchanged from our beta release.
The user facing changes that were released include:
Statistic infrastructure: We’ve created an infrastructure for creating graphs of user’s listening behaviour. So far we’ve only got an all-time top-artists graph to illustrate our setup, but soon we will work to create more graphs. Currently graphs will be generated every Monday starting at 0:00 UTC, if you logged in into your LB account during the last 30 days. If you haven’t logged in recently, you can request the calculation of your stats from your profile page.
Automatic data dumps: Now the ListenBrainz data will be dumped and synced to our FTP site twice a month. Currently this is scheduled for the 1st and the 15th of every month. The dumps will start being generated at 04:00 UTC and then copied to our FTP site and it will take a number of hours for the data dumps to appear on the FTP sites. Our documentation details how this data dump can be consumed.
Documentation improvements: Quite a few documentation bits have been improved since our last release, including better documentation on the Last.fm compatible API that ListenBrainz exposes.
Static page improvements: We’ve done some rearranging of our static pages and navigation bar to reflect the latest changes, including updating the data page and our roadmap page.
Listen count on home page: The home page now shows the current listen count.
We also made some internal/hosting changes that you can read about in our beta release blog post. The release from Friday has been tagged with v-2018-03-18.
Thanks to all those people who helped us put the beta site through its paces.
Back in 1998 when I started playing with Perl and wrote the CD Index (the pre-cursor to MusicBrainz). I was learning web development and had little understanding of web design. The tools I was using were primitive at the time and the results were cringeworthy and have not withstood the test of time.
Fast forward some 18 years and we’ve arrived at the current MusicBrainz site design — there have been minor facelifts over time and a bigger one once we released NGS back in 2011. But really, the site design hasn’t changed much and we’ve kept gluing features and new bits of data onto the crappy design, leaving us with the current mess of a UX experience we know as the modern MusicBrainz.
Our community has been asking us to improve UX for a long time — we need to:
• Empower our community with better tools for developing, editing, viewing the magnificent data that we have.
• Build a stronger foundation for further development, interaction, and extension of our projects in future
• Make our projects more welcoming to newcomers, by lowering the learning curve as well as keeps the workflow of an advanced editor intact.
Fortunately for us, Chhavi [a design student from IIT, India] has become an active contributor to the MetaBrainz projects. She has been studying our sites and how we work as a team and has volunteered to drive the process to fix the UI and the user experience issues on the MusicBrainz site. She has proposed a part of this work as her Google Summer of Code project.
Our overall goal as a team is to create a design system which will help the designers and developers stay in sync, give a more unified theme to our projects, and make it easier for new contributors to join our projects. This will also make it much easier for our developers to address your requests for features/bug fixes faster in the future.
We are not barging into your online lives and trying to make our sites pretty — instead, we are focusing on the real experiences you have with them. We held long detailed conversations during our last summit in Barcelona, where Chhavi was also present and discussed a lot of concerns that might be running in your head while you read this. As part of this initiative, we have been interviewing a number of key members of our project to understand what we and our users really need from this revamp. We have also kept track of community discussions around this topic. From this we decided that our users fall into three broad categories:
There are those who contribute to code and understand database tech.
Experienced/advanced MusicBrainz editors who don’t understand database tech.
New users, who feel hopelessly lost in the current scenario.
When you look at these pages, please keep in mind that we’re trying to clean up the clutter and to make things simple and clean. Easier to understand for an experienced editor or a new one. The data that we have should be presented in a way that makes sense. The data should present the gaps and holes that it presently has, for people to be able to improve the data gaps. Data should also be our binding link to exploit the full potential of the projects that we have, such as ListenBrainz or CritiqueBrainz.
We are not trying to fluff things up and make them look pretty. Prettiness might come with the simplicity that we are chasing. Having user flows that do not hamper the speed and makes our life easier, is our utmost goal.
That said, we are happy to receive feedback on the upcoming designs as well as the process– if you have any, please post your comments to the appropriate tickets in Jira that we linked above. We’re currently getting some pressing dev tasks out of the way before we start the actual implementation of the redesigned project. Once our team is ready to work on this, we will public more blog posts about how this project will unfold and how it will impact our users.
After many more months of hacking on core infrastructure and improving our codebase, we’re finally ready to have more people come and help us test the latest beta version of ListenBrainz. Also, we’ve recently reached a milestone of the 100th million listen in our database!
We’ve made a some internal changes to the project (that took quite a bit of effort):
Improve hosting setup that allows us to run both the production and beta version of the site at the same time. This means that any data submitted to the beta site will be submitted to the master listens database and will be available in the BigQuery data set as well. We are mimicking the setup that MusicBrainz has — the beta site use a live database so that testing the service can work with live data.
Improve internal container setup to allow for both dumping the listen data and private data for complete backups.
Improve the speed with which we process incoming listens.
These internal changes will allows us to move to more frequent updates of ListenBrainz in the future! More important are the changes to the site that are user visible:
Statistic infrastructure: We’ve created an infrastructure for creating graphs of user’s listening behaviour. So far we’ve only got an all-time top-artists graph to illustrate our setup, but soon we will work to create more graphs. Currently graphs will be generated every Monday starting at 0:00 UTC, if you logged in into your LB account during the last 30 days. If you haven’t logged in recently, you can request the calculation of your stats from your profile page.
Automatic data dumps: Now the ListenBrainz data will be dumped and synced to our FTP site twice a month. Currently this is scheduled for the 1st and the 15th of every month. The dumps will start being generated at 04:00 UTC and then copied to our FTP site and it will take a number of hours for the data dumps to appear on the FTP sites. Our documentation details how this data dump can be consumed.
Documentation improvements: Quite a few documentation bits have been improved since our last release, including better documentation on the Last.fm compatible API that ListenBrainz exposes.
Static page improvements: We’ve done some rearranging of our static pages and navigation bar to reflect the latest changes, including updating the data page and our roadmap page.
Listen count on home page: The home page now shows the current listen count.
If you’re interested in helping us test, please use the beta site and test everything you can see. See if anything misbehaves and if you do spot any problems, please report them to our bug tracker! Hopefully we can push this live next week.
NB: The beta site is connected to the live database, so any listens you submit to it, will be part of your official ListenBrainz listen history!
We saw a flurry of updates to Picard these last few months and I am happy to announce that Picard 2.0 is finally in beta. You can find it here – Picard 2.0.0beta1
If you have been following our Picard related blogs, you will know that we switched up our dependencies a bit. What this means is that Picard should look better and in general feel more responsive.
We also decided to release a new stable version of Picard before the beginning of the summer.
To help us, advanced users, translators and developers are encouraged to:
A simplified list of changes made since 1.4 can be read here.
Be aware that downgrading from 2.0 to 1.4 may lead to configuration compatibility issues – ensure that you have saved your Picard configuration before using 2.0 if you intend to go back to 1.4.
We recently decided not to have a spring 2018 schema change release. As usual, we still have some bits left over to finish up from the last spring schema change. More importantly, we’re making a concerted effort to improve the user experience (UX) of the MusicBrainz site — more on that in a blog post later.
We may decide to do an autumn 2018 schema change, but this depends on how well our UX efforts progress over the course of winter and spring.
This server release mainly introduces a confirmation request when adding a new release (or a new medium to a release) without setting a format, because entering this information is often skipped, yet the editor usually knows it. It also contains URL cleanup updates and localization bugfixes, and the instrument list template has been rewritten in React. The git tag is v-2018-02-09. Thanks to naiveaiguy and spellew for their contributions!
Sub-task
[MBS-9590] – Rewrite the instrument list in React/JSX
Bug
[MBS-9599] – Translations are not applied on the 404 page
[MBS-9600] – Work attribute type and value names are not translated on the work edit form
[MBS-9603] – Series ordering type descriptions are not translated on the series edit form
New Feature
[MBS-9368] – Ask for confirmation when leaving format empty
Task
[MBS-9587] – Add a few Japanese lyrics sites to the whitelist
We almost got Dvořák fully cleaned, with only a page and a half of hard-to-fix recordings from compilations left. Which honestly is a great result (especially since most people won’t care that much about those compilations).
That said, I thought we could do something different this time, and hopefully avoid albums with no info available at all 🙂 The best way of doing that is to focus on a label instead of a composer: ideally, a label that offers (almost) all of their booklets for free so that everything can be checked without needing to have a copy of the release. One of the best examples of this is hyperion (official site), a British label that puts out all sorts of interesting stuff from medieval music to contemporary classical. So this February we’ll clean up hyperion (Hyperion? the logo is lowercase, anyway!) releases 🙂
Tools
Our user loujin has made a nice dashboard that shows our current hyperion (and related label) releases, and the ones from their complete catalog list that we seem to be missing. It matches by barcode, so if we’re missing the barcode, the release will still appear on the “we’re missing this” list – make sure we really are missing it before adding a new one! 🙂
My own Classical Editor’s Toolbox, especially if you’re a relatively new editor. You’ll definitely want to install most of the userscripts mentioned there.
Discogs pages for hyperion and helios. Usually, the label page will be better than these, but some old releases (especially vinyls) might be on Discogs and not in the official catalog.
How to use the Hyperion website
The website has a lot of info! Here’s an introduction, I’m sure I’m missing some stuff.
Choose the right label! In general, you can look at the catalog number: CDA = hyperion, CDH = helios (other sublabels and distributed labels are more obviously different).
For full booklets, click “Digital booklet (PDF)” under the cover art. It might not be always there but I can remember almost no cases where it wasn’t 🙂 All the booklets include a request not to upload them elsewhere, so let’s respect that: please do not upload the full booklets to the Cover Art Archive. Keep in mind when something has been re-released on Helios, the Helios booklet will also be linked from the old Hyperion version. It’s generally safe to follow this booklet, but of course if you know something was printed differently on the old tracklist you should keep it like it actually was 🙂
For a big cover image, click on the cover and then right-click + open image in new tab. These are ok to add to the Cover Art Archive: please do upload them! 🙂
For the release date (up to the month) see the box on the top right side of the page.
Barcodes are often not available on the release page itself for some reason, but you can get them from loujin’s list, from the full catalogue itself or by searching Amazon for the catalog number and looking at the back cover.
Hyperion often re-releases stuff on the budget sublabel Helios, or as part of collections. If you see “Superseded by CDH12345” (or whatever the catalog number) to the right of the cover under the title area, you’re in luck! You can fix two releases instead of one with just a bit more effort 😉 (if one of the two is missing, just fix the existing one, then create the missing one based on the now-fixed version). Remember, CDA = hyperion, CDH = helios.
Other hints
Remember you have the full liner notes. This is very helpful when trying to identify works! If in doubt, check what the liner notes say. If that still doesn’t help (say, you have one of Dowland’s “A Fancy” and no idea which one that is) just leave it unlinked, don’t guess the work.
The website will sometimes be more specific than the booklet about which performers perform on which works or work parts. If the booklet is not too clear, see if specific performers are printed under the track title on the website’s tracklist.
Recording dates are usually more exact on the booklet than the right-side box. Even if you see “Recording details” there, check the booklet first 🙂 Old booklets might have only recording dates but no locations – recent ones seem to include both pieces of info almost always.
When choosing release artists, I’d suggest following the cover, not the website (if the website says Johannes Brahms and the cover Brahms, use just “Brahms”).
The hyperion website entries can be linked either with “purchase for X” or “discography page” relationships. I’d suggest at least “discography page” (with the purchase ones on top if desired), but just linking it is already good – that’s the quickest route to booklets, after all! 🙂
What to work on
Take either loujin’s dashboard or the actual label pages in MusicBrainz, look at releases and see what seems to need work. An easy start is releases that still have the performers on the title rather than the artist field 🙂 You can also look at the data quality column: anything with “unset”, “low” or “normal” should be missing stuff (if not, go and change data quality to high!).
Add missing releases: in loujin’s dashboard you can see releases that haven’t matched to MB by barcode or catalog number. Make a quick check in case they’re in MusicBrainz but missing the info, but most of them are simply missing and need to be added!
If you’ve added all the info from the booklet (including engineers, copyright info and whatnot) and added the covers please set the release data quality to high from the sidebar. That way, other people can see that and not check the data again 🙂 If something is terribly entered and you don’t have time to fix it, feel free to set it to low quality to point the mess to others!
As always, if you have any doubts or questions or you just want to ask the community to help with something, you can post under this 🙂