Linux version: Ubuntu 18.04LTS
Audacity version: 3.0.2, and the HEAD of master as of Jul 2 2021.
Installation: 3.0.2 from Ubuntu package audacity-3.0.2-0built1-ubuntu18.04, HEAD from https://github.com/audacity/audacity, configured with -Daudacity_lib_preference=local, compiled with gcc 7.5.0-3ubuntu1-18.04
Symptom: If you open an .aup file created by 2.2.1 and save it as aup3, it can get a bogus value in the SelectedRegion selLow and selHigh. It causes issues running Nyquist effects, for example, Limiter. Here’s the dialog shown after running the effect:
Steps to reproduce:
- Create an .aup file in Audacity 2.x
- Open it in Audacity 3
- Select the track and run Effects > Limiter
But the appearance of symptom depends on the value of uninitialized memory. In my environment it is consistently reproducible, but it may differ on different configuration.
In src/import/ImportAUP.cpp, AUPImportFileHandle.mProjectAttrs.have* fields are not initialized. AUPImportFileHandle::HandleProject sets the flag to true if appropriate field value is found in input, but does nothing if the field isn’t provided in the input, which is the case of “selLow” and “selHigh”. If the haveselLow and/or haveselHigh flags happens to be true when constructed, uninitialized value in the corresponding selLow and selHigh are written to .aup3 file.
Initialize mProjectAttrs.have* flags to false in the AUPImportFileHandle constructor or AUPImportFileHandle::HandleProject.
Thanks for the report.
It looks like it may be a bit more complex than your description (“Limiter” does not use “selLow” or “selHigh”), but I can see the potential problem.
There’s an expectation:
// project tag values that will be set in the actual project if the
// import is successful
but in the case of “selLow” and “selHigh”, that may not be true.
If the AUP project file does not have a “spectral selection”, then “selLow” and “selHigh” are not set. (All the other tag values must be set for a valid AUP project).
Although the Limiter plug-in does not use “selLow” or “selHigh”, the initialisation of the Nyquist interpreter initialises several global variables from the values of “selLow” and “selHigh”. I suspect that the error message is issued from that faulty initialisation.
That’s not happening for me at the moment, but as you say: “the appearance of symptom depends on the value of uninitialized memory”.
I’ll play around with this to find a repeatable way to show the error. Unless this has been fixed since the release of 3.0.2 it shouldn’t be difficult to prove.
By the way, a simple workaround:
- Enable the “Spectral Selection Toolbar”.
- Set any value in that toolbar.
“selLow” and “selHigh” will then have valid values.
I’ve posted a pull request with a fix and linked the pull request to this topic.
Thanks again shirok.
Indeed, how that illegal f0/f1 value affects Nyquist return value needs some more explanation. I first noticed the symptom with ACX Check Nyquist plugin, and it does show extra error message saying “unbound variable - INF” in the debug window.
Here’s the excerpt of S-expressions sent to nyx_eval_expression, when uninitialized f0/f1 are used:
(putprop 'SELECTION (float 13705906871238715135212900482658607177629656078212008955247170467558203650687539889413687584194858949518954192327811810181027846021207392338788355533885669376000.0) 'LOW-HZ)
(putprop 'SELECTION (float inf) 'CENTER-HZ)
(putprop 'SELECTION (float 49693564577469401498559526934606374210880501847917698131564249964155147029108264590744059451381891785714352525928445023031230332157587935531517415184545843173583905001115176126531614773956686185846769556222734082383137472512.0) 'HIGH-HZ)
The “INF” thing may be caused by the (float inf) literal. I’m not knowledgeable enough to see why this causes the Nyquist code to return a double value.