Picard 2.6 Beta 3

The Picard team is happy to announce that Picard 2.6 Beta 3 is now available. We decided to do a third beta after the recent Beta 2 release as there have been additional changes that required updates to packaging and translations.

Thanks a lot to everybody who contributed to this release with code, translations, bug reports and general feedback.

Download

Picard 2.6 Beta 3 can be downloaded from Picard website Downloads section.

For macOS users there are now two separate builds available. If you are using macOS Mojave 10.14 or later, including macOS 11.0 Big Sure, please use the download for macOS 10.14+. If you are still on macOS Sierra 10.12 or macOS High Sierra 10.13 you should use the download for 10.12+ instead.

Only the 10.14+ builds support the macOS dark mode. This build also uses newer versions of Qt5 and Python and is hence recommended, but won’t run on macOS before 10.14.

Linux users might want to install the beta version using Snap. If your Linux distribution supports Snap you can install Picard from the beta channel using:

snap install --beta picard

Please report any issue through our bug tracker and give us feedback on this beta release on the Community Forums.

What’s new?

Apart of some bug fixes this release improves handling of dark UI on Windows and macOS. This is the first official release of Picard which supports the dark mode in macOS Mojave 10.14 and later. Please note that you need to use the Picard app build for macOS 10.14 or later for this feature to work (see above).

On both macOS and Windows it is now possible to switch to dark or light UI independent of the system setting. By default Picard will follow your system settings. Special thanks to Gabriel Ferreira for his work to enable this.

Below is a complete list of changes since Picard 2.5.6.

Bugfixes

  • [PICARD-2135] – Tags “license” and “website” cannot be deleted and get duplicated on update for ID3
  • [PICARD-2136] – macOS: File browser does not use user’s home folder by default
  • [PICARD-2138] – macOS: After saving options the toolbar style changes

Improvements

  • [PICARD-1357] – Support dark mode on macOS Mojave 10.14 and later
  • [PICARD-2095] – Allow the user to choose between light or dark theme on Windows and macOS

Helping out

The easiest way to help us getting a great Picard 2.6 release is using and testing this beta release. Please report bugs on the Picard issue tracker and provide feedback in the community forums.

Please also help translate Picard. There have been changes to the user interface and inline scripting documentation and existing translations need to be updated for the final 2.6 release. Translating is easy and can be done online: Head over to MusicBrainz’s translation page on Transifex and click on “Help Translate MusicBrainz”.
Once you have registered an account on Transifex you can start translating. For Picard the primary resource to translate is “picard“, but there is also the “picard_appstream” resource, which is used for providing descriptions for various Linux software-center applications, and “picard_installer”, which contains the translations for Picard’s Windows installer.

If you are a software developer you are very welcomed to provide fixes and features. Picard is free software and the source code is available on GitHub. See Developing on the Picard website to get started.

Schema change release: May 17, 2021

We’re having a schema change release on May 17, mostly to make small changes that will make our queries more efficient, ensure better constraints, and make some hardcoded options editable without schema changes in the future. We are also upping the required versions of both Perl and Node.js to 5.30 and 16.0 respectively (see the “Minimum version requirements” section below.)

Here’s our list of tickets for the Spring 2021 schema change, with descriptions of what’s being changed:

Schema changes

  • MBS-1424: Add a “first release date” field to recordings. A very popular request for years, this allows requesting the date of the first ever release a recording appeared on. This adds materialized tables recording_first_release_date and release_first_release_date which are updated via triggers whenever the earliest date changes. The change was released as an optional extension to the main MusicBrainz server schema on Dec 16, 2020, but it will be added to the main schema during this schema change.
  • MBS-10208: Allow merging collections. Users who decide two of their collections should be joined into a larger one should be able to do so without having to move all the entities in the collection manually. This requires adding a editor_collection_gid_redirect table (equivalent to other existing x_gid_redirect tables) to ensure the old collection links redirect to the one they have been merged into.
  • MBS-10566: Convert allowed_series_entity_type and allowed_collection_entity_type to tables to allow for additions without schema changes. The constraints allowed_series_entity_type and allowed_collection_entity_type specify which types of entity can be used in series and collections, respectively. As such, if we want to add the possibility to create series of artists, we need to modify the constraint during a schema change. For ease of use, we are moving the constraints to be their own tables instead, allowing us to update them as needed in the future outside of a schema change release.
  • MBS-10647: Add [no label] to b_del_label_special trigger for labels. The b_del_label_special trigger ensures that any attempt to remove a special purpose label fails. Currently it only checks the special case “Deleted label”, but since “[no label]” is also a special purpose label that should never be deleted, we will add its ID to the trigger check.
  • MBS-10821: Remove orphaned recordings from collections for deletion. Replaces a single function, delete_orphaned_recordings(), to add a new clause that makes it so that recordings referenced only in collections (but not linked to anything else in the database) can be deleted as orphans. This was released on the main MusicBrainz servers on June 15, 2020, but it will be added to the main schema during this schema change.
  • MBS-10962 / MBS-11460Add materialized tables and indexes to fetch releases and release groups by artist or track artist. These tickets will address performance issues on our current artist pages. They do not modify any existing tables, but as mentioned, add some new tables (to be updated via triggers) and indexes.
  • MBS-11097: Support PKCE (Proof Key for Code Exchange) by OAuth clients. Adds two new columns to the editor_oauth_token table. This feature is opt-in, but allows public OAuth2 clients to mitigate auth code interception attacks. The change was released as an optional extension to the main MusicBrainz server schema on Sep 21, 2020, but it will be added to the main schema during this schema change.
  • MBS-11431: Speed up /ws/js/check_duplicates. Adds new indexes only (on the artist, label, place, and series tables, plus their respective alias tables). Improves some slow queries in the editing interface related to duplicate checking, i.e. finding other entities with the same name. Since this is a non-breaking change, it was released on the main MusicBrainz servers on Mar 15, 2021, but it will be added to the main schema during this schema change.
  • MBS-11451: Support ratings for places. Places can be reviewed in CritiqueBrainz yet cannot be rated in MusicBrainz. This is a strange state of affairs: clearly, if they are worth reviewing in depth, they also deserve the option to rate them. As such, we will add place_rating_raw and place_meta tables, in the same way we have for other ratable entities.
  • MBS-11453: Change entity0_cardinality, entity1_cardinality to SMALLINT. The cardinality columns of the link_type table are used to indicate whether the entity on each side of the relationship is expected to have only a few uses of the relationship type in question, or many (too many to comfortably display/edit). This is what stops every single recording of a work showing up in an edit work page, for example. At the moment we allow only two values for cardinality, 0/1. While it is possible that we will want to allow a few other values in between what is effectively “do not show anywhere ever” and “show all the time”, it is clear we will not need more than 32.000 values. As such, we are moving these columns from INTEGER to SMALLINT to reduce table size.
  • MBS-11456: Add MBIDs and redirect tables for artist credits. Adds a gid column to the artist_credit table, and a new artist_credit_gid_redirect table. The MBIDs will allow public identification of artist credits outside of MusicBrainz, and open the door to useful features in the future.
  • MBS-11457: Drop series ordering_attribute. This column was added back when we were expecting to have different types of ordering attributes for series, but we have never used it. We are planning to just drop the column.
  • MBS-11459: Add a script to create edit_data_type_info. edit_data_type_info is a function used for development that we added in 2020 and we will now add to mirrors as well, both for consistency and for anyone who uses their mirror for development and just wants to use it.
  • MBS-11463: Add view to easily access medium track lengths. Our current way of finding the length of a medium is to either load all its tracks, then sum the durations, or to use the duration of its disc ID when present. The first of these requires a lot more processing than just getting the durations straight from the database, while the second ignores any data tracks not on the CD TOC. This adds a medium_track_durations view that allows easy access to the duration of the track lengths for any medium.
  • MBS-11464: Drop statistics.log_statistic. We added the statistics.log_statistic table for a Google Summer of Code project back during a 2012 schema change, but the work never got finished and implemented. We are not planning to implement it anymore, so this table is useless and we will be dropping it.
  • MBS-11466: Change language.frequency and script.frequency to SMALLINT. The frequency column of a language or script indicates how often it’s used and lets us sort the most frequently used entries at the top of our lists. But we don’t store an exact count, just a number from 0-4 indicating “frequently used,” “hidden,” or “other.” Like MBS-11453 above, we don’t expect to need a full INTEGER type to store these columns at any point in the future, so can safely move them to SMALLINT.

Minimum version requirements

We’re raising the minimum required version for Node.js to v16 (which is the next LTS release coming in April 2021). Our current required version, v10, is hitting the end of its life cycle in April, and given there shouldn’t be a particular difficulty installing the current Node.js LTS on any system, it makes sense to just upgrade to the most recent LTS by the time of the schema change day.

We’re also raising the minimum required version for Perl to 5.30. The latest version is 5.32, but the current Ubuntu LTS (20.04), which is likely to be the next base image for our Docker containers, only provides 5.30. Our current required version, 5.18, was released all the way back in 2013, so moving to 5.30 is already a fairly significant improvement.

We’ll post final details about this release just prior to the release and shortly after we complete it, including instructions on how you can update your own copy. If you have any questions, please do leave a comment below or on the linked JIRA tickets!

Picard 2.6 Beta 2

The Picard team is happy to announce that Picard 2.6 Beta 2 is now available. This is a pre-release to gather feedback on the changes before the final 2.6 release.

Thanks a lot to everybody who contributed to this release with code, translations, bug reports and general feedback.

If you wonder why this is beta 2 and there was no announcement of beta 1: We had prepared beta 1 for release last week. But then AcoustID got into serious technical trouble. Asking for wider testing of a new Picard release when such an important service was unavailable seemed not a good option, so we decided to delay the announcement. But since AcoustID has now recovered we are now ready for testing the beta version, and we even could get some improvements in over last week’s beta.

Download

Picard 2.6 Beta 2 can be downloaded from Picard website Downloads section.

For macOS users there are now two separate builds available. If you are using macOS Mojave 10.14 or later, including macOS 11.0 Big Sure, please use the download for macOS 10.14+. If you are still on macOS Sierra 10.12 or macOS High Sierra 10.13 you should use the download for 10.12+ instead.

Functionality wise both are the same, but the 10.14+ build uses newer versions of Qt5 and Python and is hence recommended, but won’t run on macOS before 10.14.

Linux users might want to install the beta version using Snap. If your Linux distribution supports Snap you can install Picard from the beta channel using:

snap install --beta picard

Please report any issue through our bug tracker and give us feedback on this beta release on the Community Forums.

What’s new?

This release fixes Picard becoming unresponsive on some systems, especially when editing or adding tags to multiple selected items. This issue has been around since Picard 2.0 and we are happy to have it now fixed.

Apart of that there are also several new features and improvements, such as support for original release date per track, support for a new “director” tag, WebP support for cover art images, improvements to the script editor and the script documentation and more.

Below is a complete list of changes since Picard 2.5.6.

Bugfixes

  • [PICARD-1528] – “Search for similar albums” causes crashes if the selection includes clusters and files
  • [PICARD-1689] – Freezes when adding tags to large album
  • [PICARD-1747] – macOS: Tearing when scrolling list of plugins
  • [PICARD-1926] – “Show changes first” in tag preview window leads to freeze
  • [PICARD-2088] – Picard hangs when adding new tag to multiple tracks in an album
  • [PICARD-2091] – Loading images from cover art via drag and drop from browser only loads PNG and JPEG images
  • [PICARD-2097] – Crash with zh_CN locale
  • [PICARD-2113] – Script can change title of “Unclustered files” special cluster
  • [PICARD-2127] – “Lookup in browser” in metadata box does not pass tagger port
  • [PICARD-2131] – Tagger button reacts slow in Firefox

New Features

  • [PICARD-204] – Support for track-level original release date
  • [PICARD-1998] – Add “director” (for videos) tag
  • [PICARD-2089] – Support WebP images for cover art
  • [PICARD-2124] – Add MB release annotation field as %_releaseannotation% variable

Tasks

  • [PICARD-715] – Chrome to block browser access to localhost
  • [PICARD-1950] – Fix macOS builds with PyQt > 5.13.2

Improvements

  • [PICARD-2084] – Use TLS for AcoustID web service requests
  • [PICARD-2090] – Reenable TIFF support for cover art images
  • [PICARD-2092] – Improve script editor function/variable auto completion
  • [PICARD-2105] – Improve script function popup descriptions
  • [PICARD-2110] – Add %originaldate% and %originalyear% to file naming examples
  • [PICARD-2114] – Show disambiguation comment in CD Lookup popup window
  • [PICARD-2125] – Enable CAA Release Group cover art provider by default
  • [PICARD-2126] – Allow cross origin access to browser integration
  • [PICARD-2130] – Restructure cover art options to make them easier to understand

Helping out

The easiest way to help us getting a great Picard 2.6 release is using and testing this beta release. Please report bugs on the Picard issue tracker and provide feedback in the community forums.

Please also help translate Picard. There have been changes to the user interface and inline scripting documentation and existing translations need to be updated for the final 2.6 release. Translating is easy and can be done online: Head over to MusicBrainz’s translation page on Transifex and click on “Help Translate MusicBrainz”.
Once you have registered an account on Transifex you can start translating. For Picard the primary resource to translate is “picard“, but there is also the “picard_appstream” resource, which is used for providing descriptions for various Linux software-center applications, and “picard_installer”, which contains the translations for Picard’s Windows installer.

If you are a software developer you are very welcomed to provide fixes and features. Picard is free software and the source code is available on GitHub. See Developing on the Picard website to get started.

Picard 2.5.6 released

Picard 2.5.6 is a maintenance release. This fixes issues with the context menu of the metadata view and long standing problems with the app signature on macOS Sierra and High Sierra.

The latest release is available for download on the Picard download page.

Bugfixes

  • [PICARD-1943] – App does not start on macOS 10.12 / 10.13, Gatekeeper reports it as damaged
  • [PICARD-2074] – Crash when trying to add new tags
  • [PICARD-2083] – Snap version: path to fpcalc gets invalid after update
  • [PICARD-2087] – Adding new tags crashes Picard with Qt < 5.10

Playlists and personalised recommendations in ListenBrainz

Just in time for Christmas we are pleased to announce a new feature in our most recent release of ListenBrainz, the ability to create and share your own playlists! We created two playlists for each user who used ListenBrainz containing music that you listened to in 2020. Check out your lists at https://listenbrainz.org/my/recommendations. Read on for more details…

With our continuing work on using data in ListenBrainz to generate recommendations, we realised that we needed a place to store lists of music. That sounded like playlists to us, so we added them to ListenBrainz. As always, we did this work in the public ListenBrainz repository. You can now create your own playlists with the web interface or by using the API. Recordings in playlists map to MusicBrainz identifiers. If you’re trying to add something and can’t find it, make sure that it’s in MusicBrainz first.

Once you have a playlist, you can listen to it using our built-in BrainzPlayer, or export it to Spotify if you have an account there. If you have already linked your Spotify account to ListenBrainz you may have to re-authenticate and give us permission to create playlists on your behalf. Playlists can also be exported in the open JSPF format using the ListenBrainz API.

Over the last year we’ve started thinking about how to use data in MetaBrainz projects to generate recommendations of new music for people to listen to. For this reason, we started the Troi recommendation framework. This python package allows developers to build pipelines that take data from different sources and combine it in order to generate recommendations of music to listen to. We have already developed data sources using MusicBrainz, ListenBrainz, and AcousticBrainz. If you are a developer interested in working on recommendations in the context of ListenBrainz we encourage you to check it out.

Now that we can store playlists we needed some content to fill them with. Luckily we have some great projects worked on by students over the last few years as part of MetaBrainz’ participation in the Google Summer of Code project, including this year’s work on statistics and summary information by Ishaan. Using Troi and ListenBrainz statistics, we got to work. Every user who has been contributing data to ListenBrainz recently now has two brand new 2020 playlists based on the top recordings that you listened to in 2020 and the recordings that you first listened to in 2020. If you’re interested in the code behind these playlists, you can see the code for each (top tracks, first tracks) in the troi repository.

If you’re a long-time user of ListenBrainz you may be familiar with the problem of matching your listens to content in MusicBrainz to be able to do things with it. We’ve been working hard on a solution to this problem and have built a new tool using typesense to provide a quick and easy way to search for items in the MusicBrainz database. You are using this tool when you create a playlists using the web interface and search for a recording to add. This is still a tech preview, but in our experience it works really well. Thanks to the team at typesense for helping us with our questions over the last few weeks!

This work is still in its early days. We thought that this was such a great feature that we wanted to get it out in front of you now. We’re happy to take your feedback, or hear if you are having any problems. Open a ticket on our bug tracker, come and talk to us on IRC, or @ us. Did we give you a bad jam? Sorry about that! We’d love to have a conversation about what went well and what didn’t in order to improve our systems. In 2021 we will start generating weekly and daily playlists for users based on your recent listens using our collaborative filtering recommendations system.

Merry Christmas from the whole MetaBrainz team!

Picard 2.5.4 hotfix for Windows startup issues

We had many reports of Windows users not being able to launch the just released Picard 2.5.3. This is a hotfix release to address this issue. There are no changes for other platforms.

The updated version is available from the Picard download page.

Thanks a lot to everyone reporting on this issue and helping to get this resolved quickly and sorry for the trouble.

Changes

Picard 2.5.3 released

The Picard team is happy to announce the release of Picard 2.5.3. This release fixes a performance regression introduced in Picard 2.5.2 and brings many more bug fixes and improvements to existing functionality.

The latest release is available for download on the Picard download page.

What’s new?

Bugfixes

  • [PICARD-2016] – AcoustID API Key is not stripped
  • [PICARD-2017] – Picard crashes when removing entries on the right side while loading
  • [PICARD-2019] – Saving tracks to SMB share on Windows 10 results in ever more nested folders
  • [PICARD-2020] – Multi-value album or recording ID tags prevent Picard from loading the proper albums
  • [PICARD-2021] – SameFileError when moving files between network path and local path on Windows
  • [PICARD-2022] – Crash accessing network share without access rights on Windows
  • [PICARD-2023] – Appdata file not generated on non-Linux platforms
  • [PICARD-2028] – Deleting albums and saving files is extremely slow
  • [PICARD-2031] – Scripting documentation link 404
  • [PICARD-2036] – MultiMetadataProxy::pop is not flagged as a WRITE_METHOD; this breaks the “keep” plugin
  • [PICARD-2037] – Improve Info/Error tab readability
  • [PICARD-2045] – After fingerprint, unsaved tracks have green tick
  • [PICARD-2050] – File selector pane jumps around horizontally instead of expanding / collapsing the folder
  • [PICARD-2056] – Interface color changes are not saved
  • [PICARD-2058] – Add File dialog does not show files with uppercase extension on case-sensitive file systems
  • [PICARD-2059] – Scripting Documentation shows extra line for each function
  • [PICARD-2062] – Searching for similar tracks can remove current album even if there are unmatched tracks
  • [PICARD-2064] – Cluster shows empty album column

Improvements

  • [PICARD-2034] – Add context menu entry for copy and paste to metadata view
  • [PICARD-2035] – More verbose tooltip for album error icon
  • [PICARD-2038] – Integrate metadata box clipboard with system clipboard
  • [PICARD-2039] – Unify error handling for albums, non-album tracks and files, show errors in info dialog
  • [PICARD-2044] – Add date and originaldate fields to the choice of columns in the list views
  • [PICARD-2046] – AcoustID submission can fail due to body size limit of AcoustID server
  • [PICARD-2047] – Improve contrast for console text in dark mode
  • [PICARD-2057] – Allow showing all files in Add Files dialog
  • [PICARD-2063] – Add an option to disable automatic horizontal scrolling in file browser

The complete list of changes of this and previous releases is available in the changelog. You can also discuss new features or usage on our forums.

Acknowledgements

This release contains code contributions by Sophist, mineo, BSDKaffee, zas, and outsidecontext. Many thanks also to all translators and everybody who suggested features and reported bugs in our community forums or on the issue tracker.

Leaked email address incident: 2020-11-23

We’re saddened to write that we’ve let some of our users down by accidentally leaking their email addresses and birth dates via a bug in the web pages of musicbrainz.org. This caused some users to receive unwanted spam emails.

However, we would like to emphasize that no passwords, passwords hashes or any other bits of private user information other than email addresses and birth dates were leaked.

If you have never added or edited an annotation on MusicBrainz, then your email address and birth date were never leaked and you can ignore this — your data has not leaked.

What happened

About two weeks ago a MusicBrainz editor contacted us to say that their email address that was in use only at MusicBrainz had received spam. The user changed the email address to a very distinct email address in order to rule out a spammer guessing the updated email address. But it happened again, and the user received email to the unguessable email address. 

At this point we began an audit of the MusicBrainz server codebase in an attempt to find out where the leak was, patch it as soon as possible, and discover who was affected by it.

What we found

On 2019-04-26 we released a new version of the MusicBrainz server and in this version we added email addresses to the list of editor data we pass to our server to build MusicBrainz pages. The goal of this was to display them in admin-facing pages to, ironically, be able to fight spammers who were using MusicBrainz as a spamming tool. We also added the editor’s birth date, to be able to congratulate them on their birthday. Neither of these cases should have ever been a problem, since the private data should only be used on pages built and sent from our own server (where the data cannot be seen by anyone else), and any editor info sent to the users’ browser goes through a “sanitizing” process eliminating all this private information.

After some digging, we discovered that due to a bug we had overlooked in the code that stripped this data, the addresses and dates had started being sent to the browser whenever an entity page with an annotation was requested. The email address and birth date of the last person to have edited an annotation in MusicBrainz (any annotations, attached to any of our entities) was leaked on the page for the entities in question. This data was contained in a massive block of JSON data in the page source and was never shown on the web page for humans to see, which is why this issue went undetected for so long.

Who was affected

We looked at all editors who wrote any annotations that were displayed between the date the problematic code was released and the date the bug was fixed. This can mean either the annotation was written during this time period, or it was written before that but (being the latest version of the annotation for the entity) it was still displayed during this time period. This gave us a total of 17,644 editors whose data was at some point visible from the JSON block in at least one entity’s source code. We sadly do not have a way to know for sure how many of the affected were actually ever found and stored by spammers, since we attempt to block botnets as much as possible. As such, we simply have no way of knowing who was really affected by this leak — only who might have been.

What we’ve done

Once we detected the issue on November 22, we immediately put out a hotfix to all production (and beta) servers plugging the leak. The hotfix acted to sanitize the editor data by removing email addresses and birth dates from the JSON. We also deployed two additional changes that should help prevent similar issues from occurring, by avoiding sending sensitive editor data to our template renderer altogether. See all changes from the git tag v-2020-11-22-hotfix.

We are planning to improve our testing infrastructure to detect exposure of editor data — this will become a routine part of our continuous integration process. We are also going to ensure that any pull request dealing with editor data goes through a strict testing checklist.

How did spammers get these email addresses?

You might be wondering how such an obscure leak in a web page can end up in spammers finding and using your email — you’re not alone. 

Our sites are under near constant traffic from seemingly random internet bots fetching thousands of our pages in a day, with no apparent goal. All of our metadata is available for download, so why would someone download pages from us at random?

Well, we now know — web pages can contain a whole host of random data that shouldn’t be there. Email addresses, birth dates and such are just the starting point — there have been websites that have leaked credit card numbers and even login passwords, possibly compromising the integrity of user accounts.

In this case it appears that a botnet kept downloading pages from musicbrainz.org and driving the load on our servers up. We’ve been trying to block botnets ever since they’ve come into existence, but this is a laborious task that is never complete.

It appears that spammers used the botnet to scour the internet for private data such as emails to then send out lovely spam emails to all compromised users.

Summary

We would like to wholeheartedly apologize for this data leak. We take data privacy seriously and we aim to have high standards about privacy and data security. We find ourselves frustrated by the endless data leaks that happen on the Internet on a seemingly continuous basis and work hard to avoid committing these mistakes in our domain. However, we’re also human and we do make mistakes periodically. As explained above, we’re working to improve our systems and processes in order to prevent this from happening again.

We hope that you accept our most sincere apologies for this leak.

Robert Kaye, Michael Wiencek, Nicolás Tamargo and Yvan Rivierre

Picard 2.5.2 released

Picard 2.5.2 is a maintenance release, fixing some bugs and providing minor improvements to the recent 2.5.1 release. Thanks a lot to everyone who gave feedback and reported issues.

The latest release is available for download on the Picard download page.

What’s new?

Bug

  • [PICARD-1948] – ScaleFactorRoundPolicy breaks text rendering on Linux
  • [PICARD-1991] – Case-only changes to file names are not applied on case insensitive file systems on Linux
  • [PICARD-1992] – Case-only changes to file names are not applied on FAT32 and exFAT file systems on Windows 10
  • [PICARD-2001] – Directory drag & drop from file browser to cluster area broken
  • [PICARD-2004] – Metadata changes loaded asynchronously by plugins are reset if file gets matched to track
  • [PICARD-2005] – Modified fields are sometimes not correctly marked as changed when multiple files are selected
  • [PICARD-2006] – “Local files” cover provider does not detect cover files for files already present at release loading time
  • [PICARD-2012] – Loaded files not shown in UI if release MBID is a redirect
  • [PICARD-2014] – Config upgrade from Picard < 1.3.0 to version 2.4 or later fails

Improvement

  • [PICARD-1828] – Allow assigning cover art to multiple selected files
  • [PICARD-1999] – Provide binary distributions for Windows and macOS on PyPI
  • [PICARD-2007] – Disable analyze / audio fingerprinting for MIDI files

The complete list of changes of this and previous releases is available in the changelog. You can also discuss new features or usage on our forums.