Picard 2.9 alpha 1 available for testing

We have release an alpha version of Picard 2.9:

Please test this and give us feedback. A special shout-out to @skelly37 who implemented the main new feature in this release. Thanks a lot!

5 Likes

For more information about the new command line / batch file processing please see the following secions of the documentation:

The new configuration options are described in the following section:

The revised scripting commands to allow text-based comparisons are described in the following sections:

3 Likes

I’m super-excited to try the new single-instance mode and command support that @skelly37 added! One step closer to my dream of being able to use Picard to tag new music over an SSH connection. And the “Some personal thoughts” section in the GSoC summary spoke to me as a programmer who’s had to work on too many large Python codebases. :slight_smile:

Are there plans to add any more commands in the future that might make it possible to use Picard without interacting with the UI at all? To support my most-common workflows, I think I’d need to be able to do things like:

  • View the list of clusters in the left pane
  • View the list of files from the right pane with their current and new tags
  • Assign a cluster from the left pane to a release in the right pane
  • Manually set a specific text identification frame in a specific file’s tag (usually when I’m tagging a new album and notice that its existing MB data has typos or style issues, but my edits to correct them don’t get auto-applied so I need to replicate my changes locally before saving)
  • Run a plugin (e.g. Load as non-album track) on a specific file

The current commands look like they expose a lot of powerful functionality (cluster all files, save all files, etc.), but I think I’d be scared to do most of those things (including the examples from the Command and Batch Processing page) without being able to look at the UI to check that all the files were matched correctly before writing tags or submitting AcoustIds.

3 Likes

No, running Picard without UI is not one of the goals here. Picard is a GUI application and it is not possible to run Picard’s functionality without the GUI being available. Rather this was meant to allow instrumenting the UI to some degree. One use case would be for example to automatically add newly ripped files to Picard, cluster them and maybe do a lookup.

If you want to tag the files directly on your server maybe look into beets or if you want to access the Picard UI docker-picard could help.

2 Likes