Picard 2.2.2 is available, better performance for Windows and macOS

Thanks. Great to see new versions.

Also nice to see my translation corrections in place

YAY!!! Colours are now spelt proper like wot they should be.

Missed from the change list is:

  • English (UK) updated
  • English (Canadian) updated
  • English (Australian) now available

BUT… bad news… a new bug spotted.:bug:

When I start Picard, if User Interface Language is set to “System Default” it picks English (US) instead of my OS System Default which should be English (UK).

Is this just an English bug selecting the wrong English?

Or what happens on a French OS - does System Default give the correct French?


@outsidecontext it will not open on the latest version of OSX for me any help would be good


I managed to get it to open by going into the Security & Privacy section of the System Preferences app and clicking “Open anyway.”


thanks did not think of that :slight_smile: it worked. some times im just dum

1 Like

I’ve had to do this with previous versions of Picard. This was supposed to have been alleviated with version 2.0.2, but Apple just added several new layers of security with Catalina. It’ll probably take a while for Picard to be brought up to code (if it ever is).


Is this Catalina already? If so, yes, they now require additional verification. Previously it was enough to digitally sign applications, now they also need to run through Apple’s “notarization” process. We will look into this, hopefully we can handle this in the next release.


yep Catalina is out for public release (providing the mac is new enough) it slipped my mined that there was a way to get around it. thankfully Hibiscus reminded me


That’s the usual software release cycle. You put out a new version and think “This is the best version we ever released”, and 2 hours later a user comes along and finds some nasty issue :smiley:

My guess is that getting the proper country specific locale is broken on Windows. The Windows language / region selection is a bit special, and we probably don’t have enough country specific translations for this issue to be spotted earlier.

I will test and open an issue.


just so you know @outsidecontext i just checked it on my mac it does the same thing as well so it is not limited to windows. only difference is it the language it should pick


This is working for me. How exactly have you configured the language settings in Windows? If I set the Windows display language o “English (United Kingdom)” and keep the language setting to “System default” in Picard I get the proper UK version loaded automatically:

I haven’t tested on macOS yet, will do so later.


Great work, thanks @outsidecontext and the team!

I was wondering, there was/is an issue with @MetaTunes Classical Extras plugin:

It was not clear to me if something needed fixing at Picard or at the plugin.
Has something been fixed so all is hunky-dory again?

The plugin needs fixing. It is on my to-do list, but I’ve been rather busy and may not get round to it until next month. It is not straightforward as quite a lot of the undocumented API changed in 2.2, which requires extensive plugin changes and re-testing.
See the edit at Picard 2.2 is available - #22 by MetaTunes


In our macOS packages this is broken, automatic detection of the system language does not work, at least not in the official app package. This will be fixed in the next release:

But AFAIK @IvanDobsky was using Windows, and there everything looks ok for me. Or did you defect to macOS, Ivan?

1 Like

I could sue for those kinds of accusations - migrate to MacOS? Yeurk :exploding_head: I don’t like over paying for out of date kit. :wink: Have worked on them for decades, so no problem. Just means when a client asks me to fix a Mac I can bump the price up - “Special Pricing for Apple users”

I’ll go check again on a different Windoze PC that hasn’t seen the upgrade yet. It was only a quick install yesterday between tasks on this Win7 PC in front of me.

This PC is certainly 100% UK. It is all English UK, no English US. The SYSTEM Locale is UK, the FORMAT is UK, the Display Language is UK, the keyboard is UK. There is no US.

I have specifically deleted the US from my systems. Have been doing that since the days of Win95, even if it means diving in and out of settings in half a dozen places.

I’ll go test on Win10 PC. There is a freshly setup one sitting behind me - ideal victim for a test.

Not sure why you were talking about the keyboard language, it is the System Locale that you should be setting the language to. I’ll be back later with some results.


Just putting this screen shot together of the Win7 box I am on. And noticing a change is clearly happening between Win7 and Win10 as to the language preferences.


That clearly only says “English” on the Win7 Display Language, whereas that Win10 box says English (United Kingdom). (I just checked)

Notice it does NOT say English (United States).

In the old days, “Locale” was the more important part. Been a few decades since I was dealing with the Win32 APIs, but I know English(UK) used to be simple to spot. This isn’t the first time I have setup English(UK) translation files in an application. I will poke more.

Win7 will be gone at the end of the year, so this isn’t a major issue… but I’ll check some other Win7 boxes and see what is visible.

The main point though - colour is spelt correctly as colour throughout this Win7 OS that I am working on. So the OS is correctly using the UK language, and so do all other Applications.


Okay -Win10 test.

First up, we get the Win10 version of the “I ain’t seen that app before” dialog box just like you Apple lot. That is normal as the application is on a small distribution initially and Microsoft will learn to trust it within a week or so.

Now I dive into the languages… this time the Display Language in the OS is showing as English (United Kingdom) and therefore the first start-up of Picard, and it spells colour correctly from the start.

That means the bug is limited only to Win7, and only when a specific English has not been selected in the Display Language.

Poking more and Display Language is only on a Win7 Ultimate as something changeable. Win7 Pro seems to stick to one language. And LOCALE is what defines language settings usually.

I think you need a “If windows 7, then use System Locale for the language selection.”

1 Like

That’s basically the issue here. Picard asks Windows for the display language (using GetUserDefaultUILanguage of the win32 API). And if this is just English the en_UK translation is not used but the default. But Windows before 10 never had any sane language configuration anyway. You are probably able to set the display language to “English (United Kingdom)”, but the old version of Win7 I have here won’t even allow me to install any other display language.

Having said this: This issue is definitely a “won’t fix”. Broken language settings in Win 7 have been fixed by MS in current iterations of their OS.


Only Windows 7 Ultimate allowed changing of display languages like that. The first win7 PC I tested from is an Win7 Ultimate and has a a Change Display Language button

That now doesn’t work as it takes the user to Windows Update, and the old long list of languages that used to be on here has now gone.

When I look on a different Win7 Pro PC there is no option for Display language at all. That section of the settings page is just missing.

These are both fully legit OS from MS Action Pack as part of the MS Partner Network.

Doesn’t the API allow access to the Locale anymore? It certainly used to be able to give a proper answer out and works for other applications on my PC.

Though, as Win7 is on life support now and abandoned in Jan 2020, I understand that this will be kicked into touch. At least we can manually correct the language in the list so it is not a major issue. And Win10 Users will be fine.

On a side note, it sounds like the API has just changed. There has been plenty of language options ever since the days of Win NT 3.x. I used to have to write multi-lingual software in Windows. Ah the fun of debugging a Japanese system without having any clue as to the words on screen. :smiley:


No hurries on my account.
Now that @outsidecontext has constructed a portable (Windows) version of Picard and made it available for testing, I can run Picard 2.1.3 as the installed version including a perfectly well working Classical Extras, and have additional portable installations of Picard 2.2.2 for my non-classical library.


I am certain this has come up before.
But I couldn’t find, nor remember what was said last about this, so I am taking the liberty to raise it again here today.
(And no, I am not very savvy with github, tickets etc.)
My apologies if this bothers anyone.

Picard writes tags to a tag name that is ‘set in stone’ internally.
This works well most of the time, but depending on other software you are using it will sometimes present problems.

To keep this request/suggestion simple to understand, let’s take one specific example, narrowing it down to one tag in the Vorbis format:

There is something called ‘disc subtitle’

Picard will write ‘DISCSUBTITLE’ for it.
But some other software will be using ‘SETSUBTITLE’ for it.
And other software perhaps uses ‘SET SUBTITLE’, or ‘DISC SUBTITLE’.

For situations like this, it would be very useful if it was possible to set some customised tag mapping in Picard.
Not just for this specific Vorbis example, but also for e.g. id3v2 TXXX tags. Some software will have specific non-TXXX tags for a tag, others will need TXXX for them.

Is this something that is considered, or even feasible for upcoming versions of Picard?