I have seen this problem for years and I think I have finally tracked it down.

In the process of updating the metadata and saving/moving the tracks, it starts by reading the original file backwards in 16KB chunks (FLAC in my tests).

This causes very slow behavior in the following conditions:
1. Mechanical disk (e.g., slow seek times).
2. Files not cached.

Since it is reading the files backwards, the natural read ahead on the file systems does not help. Analyzing one file, it started by reading backwards and every 16KB chunk was taking ~8mSec. After it finished that read, it wrote the file extremely quickly (probably limited by disk speed).

If I manually copy the tracks (to force them in the cache), or I put them on an SSD, the rewrite speeds are good.

On a local disk, I am seeing ~3MB/sec read speeds when this is happening. I see the same behavior if the backward reading is done over a network connection (SMB) to mechanical disks without cache as well.

Can we update Picard to read the file forwards?