Currently the progress bars (for saving or loading quick-mode) jump a lot - it looks like the only updates happen where cut markers are placed.

It would be nice if it was more continuous. Not in the sense, that it denotes overall time progress, but progress in replay processing. So that on e.g. a recording of 100 minutes each minute equates to 1% (scaled for shorter/longer replays).

That's already exactly how it works: https://github.com/ReplayMod/ReplayStudio/blob/c9de2f5d4fe3085d2ea3e836ef6b41cc9cf732fa/src/main/java/com/replaymod/replaystudio/rar/analyse/ReplayAnalyzer.java#L84
I'm guessing the user who submitted this had cut out a huge amount of time (by pausing the recording), leaving lots of packets at the specific point where they were cut, and that's why comparatively everything else seemed instant.

Mmm, I see - that might be it then 🤔

What do you think about adding another status state just saying "Packing Replay..."? I know that progress is near impossible here, because it's a library function. Would still help to communicate what is happening.

What you linked seems to be only for building the cache - is it similar with cuts while saving?

Wdym?
Saving of the cache? That happens on the fly while it is being analyzed, e.g. when an entity is despawed, all its movement is written to disk; when a chunk unload packet is received, all the block changes for that chunk are written to disk; when a dimension change happens, all the time packet references are written to disk (the packets themselves are immediately written as they are being received, only an index into the cache is kept in memory, same applies for entity spawn and new chunk packets); etc.
As for loading from cache, progress there is linear with the amount of bytes read from the file into memory. There's no progress for reading the initial index but that's in the milliseconds range, most other indices are read on demand from the aforementioned bytes.

I mean saving of a replay just after recording with start/stop/pause markers.

There progress is also linear with the time in the input replay: https://github.com/ReplayMod/ReplayMod/blob/develop/src/main/java/com/replaymod/editor/gui/MarkerProcessor.java#L226
Whenever a cut ends, that may cause it to freeze for a bit cause all the accumulated (non-redundant) data needs to be written out, not a whole lot that could be done about that.

I though about it for a while and opened #688 which explicitly lists all the things that can be improved for that progress bar.