The SetLeftSelection command produces a popup window. Is it possible to run this as silent with a parameter?
The Paste command appears to work. But when the script completes (as revealed in Debug mode) the operation reverts, leaving the audio track unaltered.
To overcome these, I believe I can:
possibly create a clip of my original selection and use their boundaries? But I think I’ll still be limited in my ability to alter the selection endpoints.
use Steve’s PunchCopyPaste, though it is overkill for my use case
I’ve implemented both versions of the script. I notice that both versions will copy and paste a portion of audio different lengths than the original.
For example,
Original = 52,474 samples
Preceding = 52,320 samples
Following = 52,800 samples
Would this be a rounding error associated with working in seconds instead of working in samples? Can the code be forced to operate in samples to increase precision?
That’s my blog
Mostly it’s about using Nyquist in Audacity, but there’s not (yet) much about using Audacity’s macro scripting commands with Nyquist on that site - I may add some stuff as and when I have time.
It could be. Could you provide exact steps for a test case that I can try?
Unfortunately no. “AUD-DO” (and “AUD-DO-COMMAND”) calls Audacity’s “macro scripting” commands (Scripting Reference - Audacity Manual) and they always use seconds for time, with precision limited to 5 decimal places.
Nyquist itself is sample accurate, but cannot access audio outside of the selection at the time that the effect is launched.
Testing the script that I posted with a 48kHz sample rate track, and a selection that is 52,474 samples long, the result is sample accurate.
You mean that before applying the effect there is only 1.09 seconds of audio before the selection? In that case it will be impossible to copy more that 1.09 seconds of audio from before the selection
Hmm. Unfortunately your code as posted produces a different effect on my end. Ahh… the joys of isolating all the variables.
Both codes (yours and mine, which should be equiv to yours) produce a selection that is not sample accurate (smaller on the preceding side and larger on the following side). Could there be something in my configuration at work here? I am using the latest Audactiy v3.2.2, 64 bit.
The original WAV data was extracted from an MP4 file. This WAV data produces the behavior which is not sample accurate, as noted previously.
I extracted a subset of this data (for testing) and saved as 32-bit float WAV (current format selection) using Audacity. When I load this data into another instance of Audacity, I can produce sample accurate selections using our code. I suspect that my WAV data (when originally extracted by Audacity) was not saved in 32-bit float WAV format, which feeds my hypothesis of rounding error. Does this track? Is there a way I can confirm my suspicion that my WAV data is not 32-bit float on disk?
Thinking about the rounding error, I exported a section of my test data to work with a smaller size. After saving it in a 32-bit float WAV format, I see our code works as nearly sample accurate. (+/- 1, which is good enough for this use case)
So, I went back to my original MP4 and performed an export as 32-bit float WAV format. The scripts work as expected. I’m now able to edit my data in a fraction of the time!
Thanks Steve for the guidance. It’s always difficult to find the root cause, eh?