(In reply to Gale Andrews from comment #0)
The fix for bug 1275 prevents this from happening.

In your steps to reproduce, the lower and upper frequency bounds are 1060.66 Hz and 8485.28 Hz respectively. The high frequency bound is too high for the 8000 Hz sample rate track. The fixed version gives an error message:

"Error.
Frequency selection is too high for track sample rate.
For the current track, the high frequency setting cannot
be greater than 4000 Hz"

Spectral edit shelves still has it's earlier validation for "over Nyquist" frequencies, but I now see that it does not work properly. If you're happy with the "fixed" version of Spectral edit parametric EQ, I can apply a similar fix to Spectral edit shelves.

(In reply to Steve Daulton from comment #1)
On second thoughts, I think that a better way to fix Spectral edit shelves is to treat invalid frequencies as "undefined". However, I've noticed that there is another bug in the Audacity code that blocks doing this.

(In reply to Steve Daulton from comment #2)
New patch made for bug 1275.

The valid frequency range for shelf filters is between (excluding) 0 Hz and the Nyquist frequency. If frequencies are defined beyond the valid range, the "spectral edit shelf" effect treats them as "undefined".

(In reply to Steve Daulton from comment #3)
Is this supposed to be DEVEL - FIX MADE given there is some connection made to bug 1275? 

> The valid frequency range for shelf filters is between (excluding) 0 Hz and the 
> Nyquist frequency. If frequencies are defined beyond the valid range, the 
> "spectral edit shelf" effect treats them as "undefined"  

As of "r6663f40" there are apparent no-ops being processed in Spectral edit shelves e.g. 0 Hz to Nyquist Freq or 0 Hz to undefined produces a result that (by inversion) is identical to audio before processing.  The above two cases would show "Please select frequencies" in 2.1.2 RC1.

(In reply to Gale Andrews from comment #4)
> As of "r6663f40" there are apparent no-ops being processed in Spectral edit 
> shelves e.g. 0 Hz to Nyquist Freq or 0 Hz to undefined produces a result that 
> (by inversion) is identical to audio before processing.  The above two cases 
> would show "Please select frequencies" in 2.1.2 RC1.
I was deceived by their being in the Undo Stack. They are not processed, but should not be in the Undo Stack. Even if removed from the Undo Stack, it seems clearer to me to show an error as we used to. 

The Manual entries for spectral edit shelves are affected by whatever we decide.

I suppose someone will tell me that Change Pitch/Speed/Tempo can do nothing (0% change) but are still in the Undo Stack. 

So we are consistent, but I don't like that either. I think the current behaviour in Spectral edit effects is especially confusing for users who may not be clear whether the change was meant to do "something".

(In reply to Gale Andrews from comment #4)
> As of "r6663f40" there are apparent no-ops being processed in Spectral edit
> shelves e.g. 0 Hz to Nyquist Freq or 0 Hz to undefined produces a result
> that (by inversion) is identical to audio before processing.
> The above two cases would show "Please select frequencies" in 2.1.2 RC1.

The effect treats 0 Hz the same as "undefined" lower frequency and treats Nyquist or above as "undefined " high frequency. It is virtually impossible to set "0 Hz" by accident (the mouse snaps to "undefined", but the upper frequency could be "invalid" if one track has a low sample rate and the upper frequency is greater than the Nyquist frequency for that track.

If the user is doing batch processing, the low frequency could be vali for all tracks, but upper frequency may be defined and valid for all but one track (if the tracks have different sample rate). is it more useful to stop the batch processing with and error, or to treat that one track as a high shelf filter with no low shelf filter?

Moved to DEVEL - FIX MADE (steps to reproduce have been fixed).

(In reply to Steve Daulton from comment #7)
Selecting a track with low frequency undefined and high frequency above Nyquist (e.g. if you had tracks at different rates but selected the lower rate track by mistake) now appears to process (given the item is in the Undo Stack), but of course actually does nothing. In 2.1.2 RC1 there was a (not very good) error message, but the user would realise they selected the wrong track. As you suggest, this case is easy to do by accident.

We have been discussing on the Forum that actions that do not change the project state should not be in the Undo Stack. I think low frequency undefined, high above Nyquist should error if applied to a single track, as it used to, and so should 0 Hz to Nyquist Frequency or 0 Hz to undefined.  

You could argue these should not error if applied to multiple tracks, if some  change in state was made to justify being in the Undo Stack.   

> If the user is doing batch processing, the low frequency could be valid for all 
> tracks, but upper frequency may be defined and valid for all but one track (if 
> the tracks have different sample rate). is it more useful to stop the batch 
> processing with and error, or to treat that one track as a high shelf filter 
> with no low shelf filter?
That scenario does not error in 2.1.2 RC1, so (AFAIK) is not an improvement in "r6663f40"?

Testing on Mac El Capitan on 01a95c5-2.1.3-alpha-13-feb-16
and
Testing on W10 on audacity-win-r4d154c4-2.1.3-alpha-18-feb-16


On both platforms using the Steps to reproduce I can apply the parametric EQ effect to the tp track the 44,100 Hz one - but the bottom one the 8,000 Hz one gives an error:

Nyquist error: Frequency selection is too high for track sample rate.
For the current track, the high frequency setting 
cannot
be greater than 4000 Hz

(spacing/line-breaks as in the actual error message (could be tidier)

Sorry, that was the error message spacing on Mac El Capitan - on Windows 10 the message look better formed.

I still get the same error message at Step 5 on both W10 and macOS10.13.1


Which I presume makes Step 6 invalid.

Can someone please clarify?

As in comment 8, the bug as described is fixed (the incorrect result in step 6 does not occur).

Comment 9 seems to be discussion about possible enhancements (not directly about this bug), so closing this as resolved fixed.