Hi!
When I’m saving albums in Picard, the save time could be up to maybe 10-15 minutes per album. The files are FLAC, the hard drive is an internal NTFS and OS is Win10. I’m saving tags but not album art, nor am I moving or renaming files. I can’t find anything in particular in Task Manager. It doesn’t happen on all albums, sometimes (rarely) it takes only a few seconds.
Is there any other information that I could provide to make this question easier?
You can enable debug mode (see Help > View log) to see what’s happening. It is possible that your FLAC files are rewritten (it depends if there’s enough space reserved in headers for new tags or not). Though it seems to me that’s rather slow.
Hard to tell if it’s a bug or not, it depends on your underlying filesystem and the size of original FLAC files.
You can open a ticket, providing full debug log, we’ll investigate.
Thanks @Zas for getting back to me! Fact is, after the comment it worked fine for some time, and now slow again. This makes me think that maybe it’s because of ongoing processes locally on my computer and not Picard.
Ok, so I’m back 
Some albums right now are taking almost 20 seconds per song to save.
D: 09:10:30,244 webservice.ratecontrol._out_of_backoff:226: ('api.acoustid.org', 80): oobackoff; delay: 333ms -> 333ms; slow start; window size 1518.000 -> 1519.000
D: 09:11:13,693 formats.vorbis._save:191: Saving file 'D:\\1. Osorterat\\DANCE & RNG\\Bedrock Series (Bedrock Records, Pioneer)\\Live In Montreal - Finale (Mixed by John Digweed) [2016]\\01. What You Need.flac'
D: 09:11:19,655 file._save_and_rename:289: Not removing empty directory: D:\1. Osorterat\DANCE & RNG\Bedrock Series (Bedrock Records, Pioneer)\Live In Montreal - Finale (Mixed by John Digweed) [2016] is not empty
D: 09:11:19,655 formats.vorbis._save:191: Saving file 'D:\\1. Osorterat\\DANCE & RNG\\Bedrock Series (Bedrock Records, Pioneer)\\Live In Montreal - Finale (Mixed by John Digweed) [2016]\\02. Black on Black (Len Faki Goes Black Remix).flac'
D: 09:11:19,671 file.update:572: Updating file <FLACFile '01. What You Need.flac'>
D: 09:11:32,519 file._save_and_rename:289: Not removing empty directory: D:\1. Osorterat\DANCE & RNG\Bedrock Series (Bedrock Records, Pioneer)\Live In Montreal - Finale (Mixed by John Digweed) [2016] is not empty
D: 09:11:32,519 formats.vorbis._save:191
This is just a short excerpt from the log file, is there anything interesting here?
How are your FLAC files created? I’ve been ripping with EAC for years and not noticed anything specifically slow.
When a FLAC file is slow to write, what happens the second time Picard writes to it? It is still slow or has it now gone back to normal speed?
The above questions are thoughts about a possibly corrupt FLAC file.
Does this speed up when you move albums that take a long time to another disk?
How large are the files and how fast is the disk they are getting saved to? How long does it take to copy such a FLAC to this disk?
20 seconds per file still sounds too slow, but if we have some numbers how fast it is supposed to be we can better compare.
One thing to understand is that in the worst case a file has to be completely rewritten, as @zas pointed out above. In the best case only the headers are written new, and this is definitely the case were it is also fast for you.
Thank you all for trying to help! The files are indeed fast to save if I save them one more time, just like you were into @IvanDobsky. Most are created in EAC, but not by me. To answer your questions @outsidecontext, an average file is around 30 megs and copying between discs doesn’t seem to take particularly long time. The harddrive I’m using for them is an WD 3Gb but I can’t remember if it’s a Green or a Black.
I’m leaning into believing that it might be corrupt files that are being rewritten, and nothing being wrong with Picard.
Thanks again all of you for helping out so kindly!
If the second save is always fast, then you may that Picard is “fixing” the files for you.
As you didn’t rip them, where did they come from? Could they be incomplete torrent downloads with errors in the files?
I assume they sound okay when played?
It seems to me that the files may well be corrupted. Something that is upsetting Picard. Would be interesting to see some example for “testing purposes”.
Most are from soulseek, and ripped with EAC. Yes, they sound okay when played. They are saved to a pool of discs (pooled through Drivepool), but when I use a single WD disc instead of this as a test, the problem is still there. I’d gladly help with your “testing purposes”
Isn’t Soulseek what happened to eDonkey file sharing network? Sounds like you are probably dealing with corrupted source files. I think there are cuetools you can use with the EAC .logs and .cue files to check the source is good or not.
Some tagging tools can be instructed not to include any padding into FLAC blocks (e.g. metaflac with the --dont-use-padding option), and since this saves (a small amount of) space some people tag their libraries like this. This causes the worst case mentioned above (rewriting the entire file) when you change any of the tags.
I actually don’t think this is the case. As @elomatreb pointed out correctly it is just so that in many cases files need to be rewritten completely. And that’s also why a second save is always fast. Picard is not really “fixing” a broken file, it is just that the first write creates enough room for the tags again. So any additional saving with about the same amount of data written to the tags will be fast again. This can turn around again if you save even more data later. E.g. the file is saving fast, but as soon as you add cover art (which easily can be very large) there is not enough space again for all metadata and the entire file needs to be rewritten.
The second part of the story is that Picard’s IO really is not that good when writing large files, there are a couple of tickets about this. In most cases users reporting this are using large lossless files (e.g. FLAC), saving to slow filesystems (e.g. over the network), or in the worst case both.
Very interesting read! I’m totally fine with this then, nothing much to do. Thanks all for your time!