Sorry for the delay in replying ... got stuck in work stuff.
I've just done a clean install of Windows 11 Pro, and my scripts (which normally run in a compiled scripting language) started making system beeping sounds.
So I tried manually running an rclone sync from a non-admin windows CMD prompt and the same system beeps can be heard. And, they exactly beep when the stats refresh and update the CMD window (every 15 seconds), so it's definitely something to do with the CMD window refreshing.
The terminal shouldn't be playing a BEL at all, it should be using that as the end of the title string for the terminal. So I'd say windows terminal doesn't understand that escape sequence so don't use --progress-terminal-title with it. (There may be Windows terminals which do understand it though).
According to this post on StackExchange there is an alternative to BEL for terminating the string; ESC\ (ST, String terminator), but for all I know BEL could still be the more compatible alternative...
Using BEL (\007) to end an escape sequence is an anomaly. It does not follow the standard (ECMA-48). Operating system controls should begin with either ESC ] or 0x9d, and end with ESC \ or 0x9c.
Long ago, the developer(s) of xterm added an escape sequence for setting the title. In X11R1 (1987), the program simply read the sequence until it got a nonprinting character. Later, in X11R4 (1989), someone improved this by terminating on a BEL character. The standard had been around longer than that, but the reason for choosing BEL rather than ST is not known. Ultimately that was addressed in the late 1990s, by recognizing either (but keeping BEL as an alternative since many users relied on hardcoded behavior with BEL).
From a PowerShell prompt both works:
"$([char]27)]0;This is my title with BEL`a"
"$([char]27)]0;This is my title with ESC\$([char]27)\"
@toby9999, you used Command Prompt originally? Does my examples (and your rclone command with --progress-terminal-title) work as expected if you use PowerShell?
conhost.exe does not support ANSI control sequences by default (see solution below);
When my .exe (which calls rclone) runs, conhost.exe is used automatically by Windows to execute it;
conhost.exe does not handle ANSI control sequences by default.
Aligning with the above notes, I can confirm:
running rclone.exe or my .exe (both with --progress-terminal-title) within Windows Terminal (I have tried both PowerShell and CMD): ANSI control sequences are handled correctly and therefore the BEL character doesn't cause a system beep;
running my .exe (with --progress-terminal-title) within conhost.exe does not handle the ANSI control sequences correctly, and does cause a system beep.
Microsoft provide a registry setting to enable conhost.exe to handle ANSI control sequences correctly.
Modify or Create: HKEY_CURRENT_USER\Console\VirtualTerminalLevel and set the value to DWORD:1
Hmm.. Actually we've been through this "swamp" not too long ago, with confusion as to whether VirtualTerminalLevel is default or not in different versions of Windows. What we ended up doing was ensuring console mode ENABLE_VIRTUAL_TERMINAL_PROCESSING is enabled on the rclone process, by using GetConsoleMode /SetConsoleMode functions from Windows API. This means it should work by default, without having to set the registry entry.