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:
And the updated documentation explaining all the new features and changes is available in English and French.
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 selectsDark
. -
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?
Ticket: PICARD-2294
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?