We have released the first beta version for Picard 2.7. There have been many changes and new features added and we would like to give this broader testing before we release the final version. Please see the blog post for details:
Some specific topics include:
- Option Profiles (English, Français)
- File Naming Script Editor (English, Français)
- Submitting Features to AcousticBrainz (English, Français)
- Submitting Cluster as a Release (English, Français)
- Configuration File Maintenance (English, Français)
- Artist Name Translations (English, Français)
While you’re testing, suggestions for improving the documentation would be appreciated as well. Please see the page on contributing to the documentation for more information. Thanks.
Preamble: If there’s a better spot for this testing feedback, feel free to redirect me
Two things I noticed related to UI on macOS (10.15.7):
On launch, I had “User interface color theme” set to
Default. In 2.6.4, System-Wide Dark Mode was respected with this setting, but 2.7 presents white unless one specifically selects
This second seems sporadic (it started behaving when I toggled back to the window to screenshot, of course lol) - While in dark mark, the cursor seemed to disappear. No flashing bar, but I could navigate about with my keyboard and make edits by feeling.
Neither were showstoppers, just small quirks.
Yes, this is a known issue, please see the blog post. We’ll see to get this fixed for the final 2.7 release. In the meantime you can switch to dark UI in Picard’s preferences.
I’ll try to reproduce this, but so far I have not experienced this. Might be related to updated Python or Qt5 versions. I assume you use the build for macOS 10.14+, right? Just for testing and narrowing down the issue, could you download and run the build for 10.12+ and see if it also has this cursor issue?
Correct, but I’m happy to give the 10.12+ version a shot and see if it comes up there as well! It’s been about an hour of use and it hasn’t come up again in the 10.14+ build, so maybe it was just a fluke.
Is the Beta a “separate install”, so you don’t have to mess with your current install, or does it replace your current install?
The installer would replace your existing installation. But you can also use the portable release, which will run separately and also place the config and plugins in the same folder as the exe
Is it possible to make internal Acousticbrainz extractor understand/respect my tag mapping?
For years I’ve mapped the legacy (so, outdated and confusing) tag “MUSICBRAINZ_TRACKID” to more realistic internal “MUSICBRAINZ_RECORDINGID” for all my files. And this has always prevented me from running the standalone extractor, which is a shame because I have copious amounts of genuine and properly matched & tagged lossless files.
Picard doesn’t have an issue with mapping in scripts when it comes to AcoustID and thus I submit these on the constant. Would it be feasible to make it work with Essentia?
I also remap MBID tags so that foobar2000 sees MP3 and M4A fields the same as FLAC/Vorbis fields. (This causes Picard to see them as different fields, but Picard isn’t my music library.)
Yes, I think that should be possible. The essentia extractor already extracts the recording ID from the tags, and it uses the “official” mapping. Currently Picard checks this and compares the value extracted with what it has for the mapped track, bit it submits what the extractor read. That’s mainly to ensure we only submit properly tagged files. So currently it basically does the same as the othet AcousticBrainz submission tools.
But Picard could also check this internally and always set the submitted recording ID based on its internal data of the mapped recording, hence there would be no issue how the data is saved to the tags.
I’ve started to get the following error when an album is matched:
Traceback (most recent call last): File "album.py", line 239, in _parse_release File "metadata.py", line 624, in run_album_metadata_processors File "plugin.py", line 257, in run File "coverart/__init__.py", line 244, in _retrieve_coverart File "coverart/__init__.py", line 67, in retrieve File "coverart/__init__.py", line 151, in next_in_queue File "coverart/providers/local.py", line 101, in queue_images IndexError: no such group
It was happening in the macOS 10.14+ version so I tried the 10.12+ and seem to get the same error.
2.6.4 on the same machine works without issue though.
(I’m very open to the possibility that it’s user error) .
Did you modify local cover art regular expression in Options > Cover Art > Local Files ?
Can you show the content of
local_cover_regex option as set in config file?
Ah, good catch! I cleared the string when I was trying to troubleshoot another issue, which was that every time an album was matched, it applied an unrelated cover (seemingly from a cache) for an album I tagged months ago.
I saved a copy of the regex string before I cleared it - I just pasted it back in and Picard doesn’t seem to be pulling the bad cover anymore.
BTW, the issue is now handled, regex without group will not raise an exception, cover art file will have its type set to ‘front’.
Thanks for the report
Hey there, just a smal suggestion
submit cluster as release is only for the not found Albums possible and it should be available on the right side (found and complete Albums) too. Because its not possible to add Pseudo Releases with another Language (from Japanese to Engish) this way.
Good idea. I’d call it “Submit as new release” then
I have to say im not a fan of the new scripting menu, its too comlicated and feels like an extra outsourced program, it was not easy to find the option for a new naming script because its not inside musicbrainz picard but inside that extra scripting window menu.^^ I would say it wohl be better to bring in an extra menu on the place where “Open file naming script editor…” is like now. It could have something like: Script Editor, Add Script, Import Script and Export Script as extras for now. And ya… it would be good to fully integrate that script editor into music brainz without an extra window over the next versions.
We originally wanted to add the new features into the existing dialog. But with the new preview and additional buttons there is simply not enough room in the options dialog. It also made this view very busy.
One option would have been to have the general file naming options (rename files, move files, destination folder, Windows compatibity etc.) and the scripting in separate views on the options page. But since we had users requesting to be able to have the script editing open in parallel to the main window we went with a separate dialog instead. This gives us also more space to show preview and documentation.
Seems fine to me if the new window is over the old settings, so it could be possible to add these old settings into the new menu that the window now has, just without an extra window popping up
Maybe the best way would be how Foobar 2000 does it? With Tabs?
One for Settings, one for Folders and one for Scripting or so?