The issue is not adding an image but rather that there is insufficient space to add the image without re-writing the entire file. Metadata in FLAC files is stored at the front of the file. While you might have some free space available after the tagging information, more than likely it is not sufficient to store a 1kx1k image. Where the files reside, can definitely make it worse. For example a NAS or external drive.

Here's the process:

- Yate loads the metadata when first reading the file. The large amount of data which comprises the audio is not read.
- You add an image
- You save the file.
- At this point, Yate realizes that it has insufficient file space to contain the image so it has to go out and read the audio data.
- It then has to rewrite the entire file. This is a worse case scenario.
- due to the fact that there may be a disparity between the data in the UI and how it gets stored it to the file, Yate always has to re-load the metadata after a Save. You might have manually create a lower case UDTI. When it gets written out to a FLAC file it has to be converted to upper case. If the application did not do a reload, you'd never know about inadvertent changes. There are lots of other cases such as this one.

Typically every step above is pretty quick except for the audio read and the full write.

So its access and volume. If you're leaving a small amount of free space such as the default of 2k, you're insulated against small changes. If you change a few small text based tags, the application fills the free space and does not have to read the audio or write the entire file.

Saving in the Batch Processor is slightly faster if you do not have a Save statement in your action but use the Batch Processor's Auto-Save option. When saving this way the last step of re-reading the metadata is not performed as there is no user interaction with the data. But, as I said that's typically not the 'time eater.

The answer is unfortunately "it just takes awhile". 🙁