Prevent macro from creating sequenced duplicates in macro-output

Is there any way to prevent a macro Export from creating multiple versions of a file in macro-output folder with embedded sequence numbers in the filename, i.e., Mysong001.mp3, Mysong002.mp3, etc. The legacy behavior in Chains would simply replace the file if it was already in the “cleaned” folder, which was a huge time-saver and workflow-friendly. Now when performing repeated macro Exports (sometimes a lot of them), it appears that when you arrive at a satisfactory-sounding file you have to manually delete the unwanted versions and rename the highest-sequenced files to remove the sequence number… is there any way to prevent this and retain the simple file replacement option in macro-output?

If you are only working on one file at a time, then you can use the “Export2” command.

Sometimes it’s one file, many times it’s several files, so I’m not seeing how using Export2 would solve this issue, if it wants one hard-coded path/filename entered at macro definition time. And having to enter the matching filename into the macro definition each time before running it wouldn’t work well. Maybe I’m missing something about how that works… I’m just trying to find that easier and quicker workflow from 2.2.2. that appears is now lost in v2.3.x.

It doesn’t help when there are several files. It only helps when you are working with one file.
When you are working with multiple files, exporting requires one of the other Export commands, and they don’t let you blindly overwrite existing files.


You could just export as (for example) “output.wav”. Export and overwrite as many times as you like, and only when you are satisfied do you manually rename the file to the actual file name.


“Friendly”, so long as you don’t accidentally overwrite the only copy of your source file, which would then be gone and lost forever with no chance of recovery.


Rather than saving multiple copies of the file, why not set up the parameters of your Macro without saving (apply the macro to the current project rather than to “files”). When you get the result that you need, you can either manually export, or if you have multiple files that will use the same settings, add the Export command and run the macro on the files. There really should be no need to overwrite files with a Macro.

“Friendly”, so long as you don’t accidentally overwrite the only copy of your source file, which would then be gone and lost forever with no chance of recovery.

It won’t overlay the original, that’s why it writes to the macro-output folder, away from the original… it already prevents that by design.

Rather than saving multiple copies of the file, why not set up the parameters of your Macro without saving (apply the macro to the current project rather than to “files”). When you get the result that you need, you can either manually export, or if you have multiple files that will use the same settings, add the Export command and run the macro on the files.

This won’t work well, I usually run the exported file(s) through other non-Audacity utilities as part of checking it out, which can’t happen if it’s still sitting in the Audacity workspace. I simply want to apply the macro to several files at once without importing them all manually first, which is already a basic and very workable option. Having to manually import them all into the workspace first kind of defeats the purpose of what a batch macro can do, doesn’t it? Or at least what is used to do.

There really should be no need to overwrite files with a Macro.

I see no reason why supporting the legacy behavior via a config or macro Export option is out of the question. Since the new behavior has actually made things much harder for repeated macro executions on several files at once, this is really a regression from v2.2.2.
Yes the conversion to macros in 2.3.x has made some things easier, but I think we lost something very basic and usable here.

I guess it’s back to v2.2.2 for me, bummer.