In his release notes to b46, James wrote:Shifted Quanta Detection is now self balancing. At its middle settings, it will automatically adjust the amount of shifted data analysis performed to maintain an even load on the CPU and disk I/O. At its highest setting, no balancing is done; every single byte is analyzed regardless of the performance cost.

This makes it sound as if Shifted Quanta Detection settings are user configurable, but I finding where this was done -- until, of course, I opened an archive.

I initially thought this would be a app-wide setting so looked in Preferences.

I've been thinking about this and decided that your choice of a per archive setting is much more logical and flexible. I'm just wondering if there couldn't be a mechanism to change the settings that wouldn't require an archive to actually be opened.

Perhaps the preferences window is not the most unlikely spot for this? I don't know how often I would change these settings, but it would be nice if I could do it without waiting for my, by now, very large archives to open.

Best wishes and thanks for the tremendous work on this update!

The benefits of performing shifted data detection is highly dependent on the kind of items being captured. Capturing iterations of a multi-media project benefit from this feature greatly, while backing up the operating system does not. In the latter, performing aggressive shifted data detection expends a lot of CPU time with very little benefit.

Allowing you to set this features on a per-archive basis makes it possible to efficiently capture that multi-media project while not slowing down the nightly backup.

If the setting was global, it would force you to choose a single set of compression settings for all of your archives, which would probably not be optimal. So the compression settings are stored in the archive itself. The consequence is that you must open each archive to change them.

I continue to toy with the idea of making some of these settings available on a per-action basis. In this scheme, a capture action could specify its own compression settings, overriding the settings stored in the archive.

(I have some great new features on the drawing board, one of which will dramatically decrease the time required to open and browse an archive. This should substantially reduce the pain involved in changing per-archive settings. Unfortunately, these features require substantial changes to the archive structure. These will take time to implement and test before they get rolled out.)