Yet another beta release, this one has significant UI changes (we expect them to be improvements), support for MetaBrainz OAuth (along many fixes regarding login/auth), ISRC reading & submission, etc. See the full blog post:
Feedback welcome as usual.
Picard 3 seems to be coming along nicely! Looking forward to its eventual release 
When I first started using Picard (2) to tag my music library, I had to re-tag everything once I found out that use track relationships isn’t on by default. At the time, I had a dig into the code and looked at the git history for the user preference defaults, but couldn’t find a reason for this setting to be left off by default. Toggling this on of course gives much richer metadata about performers.
I figure with a major version change, now might be a good time to re-assess some of these defaults? Think of all the folks that don’t dive into the settings!
That’s a good question. I think the main reason for the setting being disabled is the additional server load it can cause. Not only does it mean the server has to gather more data and transfer it, but it can also require additional requests for large releases (above 100 tracks or so the server no longer gives back track relationships in the initial request and those have to be fetched in additional calls).
But I can’t really say how much of an impact this has. With the current high load issues MB is dealing with already, maybe this is not the best time to enable this option by default. Regardless, we can make this a default any time in a future release.
But @zas can say more about this and better judge the situation, as he is also server admin for MB.
Thanks for pointing it out, I was wondering why all track list credits weren’t being added to my files. I’m trying to essentially maximize as much metadata as I can into my library so this helps alot
PICARD-3396: Offer "Use track relationships" as an opt-in in the first-run setup wizard by zas · Pull Request #3364 · metabrainz/picard · GitHub (merged, it will be in next Picard3 release, opt-in)
@hwilkinson Just adding to this and your comment on the PR: This solution is admittedly a compromise. zas investigated the server side, and if suddenly every Picard user would switch on the option it would have an impact both on data bandwidth and server processing time. We don’t want to discourage anyone enabling this option, please do if you need it. But given the current load issues the servers are having it is probably not the right time to switch the default and we decided to play it safe and offer it in the first-run wizard. We also consider to show this dialog to users upgrading from version 2 to 3, so everyone can revisit their essential settings. Existing settings will be kept, but this would give everyone the chance to decide whether they want the option enabled or not.
However, from recent requests with Picard user agent with and without the track relationships enabled, not quite 10% of users have the option enabled. It will be interesting to see if this number goes up after the (hopefully soon) 3.0 release.
I am curious if that is the best approach for whatever the goal is here. I initially also wanted to do that but there are many questions to answer, like how deep to go, what to do with heavy artifacts (30MB cover art), how and when to update the data etc. Also, you lose structure that MB has as you need to convert all to text. Besides, only small subset of data is easily available in all the players.
I personally decided to keep locally the basics and keep everything else in MB database which you can download (or its JSON surogates), or, you can target MB API for small subset of data. With the data in a decent local database, you can query it and build it for whatever is needed.