Hello,
The answer seems no but was wondering if there is any plug in to do that or script to help.
Asking as I noticed some huge gains on size (see below) relying on the latest FLAC release from June.
Thanks fr the help.
Tests:
24 bit classical music file:
with FLAC 1.3.4 level 8 → 59.9 mb
with FLAC 1.4.3 level 8 → 48 mb
Then tested some other classical files and size reduction was again impressive.
On the contrary tried some pop/rap/rock music then the gain was minimal (1mb).
Picard is NOT a transcoder.
Personally I use MediaMonkey to transcode (from FLAC to mp3 320kbps) but you would have to check whether MediaMonkey uses FLAC 1.4.3 yet.
Surely recompression is the kind of thing that can be done via a command line batch file?
-=-=-
Worth adding a note in here for others who want to keep up with latest FLAC.
I use EAC and swap it to use the latest FLAC from here: : https://xiph.org/flac/download.html
Nice to see the compression is improving. There are also a few other bug fixes from the one that is default packed with EAC.
According to the changelog for FLAC:
https://xiph.org/flac/changelog.html
the last officially noted change regarding compression and classical music was for v1.3.2:
Changed the LPC order guess for a slight compression improvement, particularly for classical music
Defintly could as it’s a one off operation. Was asking as for now I m relying on Fre:ac which makes the workflow long as need to compress each files then re tagged them with Picard to remove some useless tags.
Do you already ahve one written? 
From what I tried this improve came with last major 1.4.0 : Compression of preset -3 through -8 was slightly improved at the cost of a small decrease in encoding speed by increasing the precision with which autocorrelation was calculated (Martijn van Beurden)
No, nothing written. But I always see Rip\Compress and Tag as two separate stages. I use EAC which Rips to WAV and compresses to FLAC. It is pointed at the latest FLAC.exe to do this.
When EAC tags it is using a MusicBrainz plugin to find the release via discID, but tags are not perfect.
This is why step two is always to go to Picard to do my perfect tagging and artwork. I see it like a finishing step as I have more control over the final output.
The ripper rips, the tagger tags. I like specialist tools for the job and not a jack of all trades.
Especially as ripping takes time. While one album is ripping, I’ll be tagging others, or firing up the scanner. I heavily multi-task. 
Scanner running, ripper ripping, while I am tagging a previous album, or adding the next one into MusicBrainz. I have quite a production line running some days 
As to your main puzzle - would I bother recompressing files? Not with the current cost of storage. The time and energy used up just to save a few GB would not be an efficient use of my time. But that is just me.
Does Fre:ac let you see the command line it uses to compress with?
It’s not totally clear to me, but I think you have a set of tagged flacs and two separate things you are trying to achieve:
Is this correct?
What do your flacs look like?
Agree and relying on the same Workflow for the past decades
I even removed the initial tagging from EAC: I just launch the rip with basic filenames (TrackXX) then look directly for my specific release in MBz and Verify/Add it then load it in Picard.
Ended up to same conclusion why I never bothered before but seeing some real gains on latest version I m tempted to try.
Command line exists but not really documented out of " freaccmd --help".
Actually only the second option, files are already tagged properly with Picard. The problem being that reencode tools add some new tags that force me to retag after with Picard to remove them.
Yes to the three!
Then tried more my tests, gains are really only on Classical 24 bit files: On normal CD quality size remain similar (slightly smaller or even bigger in some cases ex: Carmina Burana).
Guess I will only reencode manually the few 24 bit files I got
Here’s a link to a script to handle the re-encoding while preserving tags
https://hydrogenaud.io/index.php/topic,18729.msg184782.html#msg184782
I Have not tried it, but it gets good reviews in the thread.
You might also want to look at the metaflac utility [Metaflac]
(https://xiph.org/flac/documentation_tools_metaflac.html)
Two options of interest:
–export-tags-to=file
Export tags to a file. Use ‘-‘ for stdout. Each line will be of the form NAME=VALUE. Specify --no-utf8-convert if necessary.
And
–import-tags-from=file
Import tags from a file. Use ‘-‘ for stdin. Each line should be of the form NAME=VALUE. Multi-line comments are currently not supported. Specify --remove-all-tags and/or --no-utf8-convert before --import-tags-from if necessary. If FILE is ‘-‘ (stdin), only one FLAC file may be specified.
That will let you export the tags from your existing flac and then set them on the new re-encoded flac.
Other options let you edit the tags in various way…
Used it for 20 years
Switched to Linux now so I try avoiding to rely on Wine but it’s indeed a quick solution for a one off.
And thanks to @dpr and @chungy chungy for the scripts.
Do they verify the files before reencoding? (avoiding to recompress a potential corrupted file without warning)
My program depends on the official flac binary. It should fail for a corrupted audio stream, though I don’t think I’ve ever encountered the scenario in my years of using it (I have encountered malformed tags, and it’ll halt on those).
FLAC files have an embedded MD5 hash that the reference codec uses to verify the audio stream. Even if the stream is valid, the decoder throws an error if the MD5 hashes don’t match. It does the check automatically during the decode phase of re-encoding a FLAC file (along with verifying the 16-bit CRC hash of every frame). It’s the same as running flac -t.
Having re-encoded thousands of FLAC files, I can say that my experience is the same as @chungy’s: FLAC errors are rare. In my collection, I think they numbered about 1 in 5000. ALAC (Apple Lossless) errors seemed to be more frequent. I think that’s to be expected since ALAC doesn’t store any hashes.