Audacity Bug Summary
••• Introduction •••
••• Keywords •••
    Audacity 3.0.3 development began 19th April 2021

Audacity Bugzilla



Bug 1977 - Using Spectrogram Settings in TCP or using Preferences causes Audacity to reset Project Rate to default rate in Quality Preferences
Using Spectrogram Settings in TCP or using Preferences causes Audacity to re...
Status: RESOLVED FIXED
Product: Audacity
Classification: Unclassified
Component: Application Core
2.3.0
Per OS All
: P2 RepeatableAll
Assigned To: Default Assignee for New Bugs
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-09-10 08:03 UTC by Peter Sampson
Modified: 2018-09-11 09:58 UTC (History)
7 users (show)

See Also:
Steps To Reproduce:
1) set Project rate to any non-default setting 2) record a short bit of audio 3) Open the track dropdown context menu of the track 4) Click "Spectrogram" 5) Open the track context menu again 6) Click "Spectrogram Settings..." 7) In the window that appears, click OK 8) Observe: audacity resets the Project Rate to default 44100 Hz Also occurs if you open and OK any Preferences pane (even without changing the default rate)
Release Note:
Using Spectrogram Settings in Track Control Panel of a track will cause Audacity to reset Project Rate to default rate of 44100 Hz.
First Git SHA:
Group: Spectrogram
Workaround:
Reset the Project rate to your previously chosen rate.
Closed:
petersampsonaudacity: Regression-
petersampsonaudacity: Test‑OK‑Win?


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Sampson 2018-09-10 08:03:01 UTC
Using Spectrogram Settings in TCP causes Audacity to reset Project Rate to default 44100 Hz - this is not a regression as this behavior onbtains in 2.2.2 and back at least to 2.1.3 - and is still the case in latest 2.3.0 alpha  audacity-2.3.0-alpha-120-b881b06b5347fabe0903bea447a313e077be4512

There is no warning of this change.

Tested on W10, but assume all 3 platforms.

We should not be changing a user's carefully made settings - especially without warning.  Accordingly I have set this as P2.
Comment 1 Peter Sampson 2018-09-10 08:04:51 UTC
And many thanks to user jpr on the Forum for catching this long-standing bug - see:  https://forum.audacityteam.org/viewtopic.php?f=48&t=101315
Comment 2 James Crook 2018-09-10 15:34:15 UTC
Same thing happened if opening and closing preferences.  The project rate was reset from the default sample rate in quality.

They are now the same thing.  If that is what we want, then we should update the text in the manual, because the behaviour has changed and is now simpler. 
 https://alphamanual.audacityteam.org/man/Quality_Preferences

If it is not what we want, then we need to decide what we do want.  One possibility is for Project rate to be unaffected by the Default Sample Rate IF a project is open.  

This problem comes from storing the project rate both in the project and in the preferences.

For now, I made the two rates the same thing.
DEVEL - FIX MADE
https://github.com/audacity/audacity/commit/a66d7442a3a4480af2a98d2253e7503b65cb6912
Comment 3 David Bailes 2018-09-11 06:06:00 UTC
(In reply to James Crook from comment #2)
> Same thing happened if opening and closing preferences.  The project rate
> was reset from the default sample rate in quality.
> 
> They are now the same thing.  If that is what we want, then we should update
> the text in the manual, because the behaviour has changed and is now
> simpler. 
>  https://alphamanual.audacityteam.org/man/Quality_Preferences
> 
> If it is not what we want, then we need to decide what we do want.

I don't think that we want this. If a user opens a project, they do not expect the sample rate of that project to change the default sample rate in preferences.
(If you open a document in Word, you don't expect it to overwrite the default template.)

  One
> possibility is for Project rate to be unaffected by the Default Sample Rate
> IF a project is open.

Yes, I think that:
1. Changing the default sample rate should not change the project rate of any open projects. (or closed for that matter!)

2. Changing the the project rate of a project should not change the default sample rate.


(Incidentally, there is a bug in the current implementation: If you change the default sample rate in preferences, close preferences, then the project sample rate is unchanged, and if you reopen preferences, the default sample rate has been reset.)

  
> 
> This problem comes from storing the project rate both in the project and in
> the preferences.
> 
> For now, I made the two rates the same thing.
> DEVEL - FIX MADE
> https://github.com/audacity/audacity/commit/
> a66d7442a3a4480af2a98d2253e7503b65cb6912
Comment 4 Peter Sampson 2018-09-11 06:21:59 UTC
Clearly there should be one unified rate and not two different ones set in different places (Quality prefs and Selection toolbar).

And I agree with David that opening a project that has a different rate should not change the setting in Quality prefs/Selection toolbar - just as importing a different rate file should not alter the user's Project Rate.


We would seem to have a disparity in the the Quality prefs still allows arbitrary user-settable rates via the "Other" - but the Selection toolbar just has the fixed list.  And the arbitrary setting in Quality Prefs appears to be ignored.overruled by the selection toolbar.
Comment 5 Peter Sampson 2018-09-11 06:33:28 UTC
And we now appear to have lost the ability to achieve arbitrary user-defined Rate settings.

Setting an "Other..." rate of say 40001 (or anything else) in Quality Prefs is ignored by the Selection toolbar - which ignores the "Other..." setting and retains it's previous setting in Selection toolbar.


If we are going to remove the ability to have arbitrary user-defined Rate settings then 
a) we should have a clear reason for doing so - as it would be a regression
b) we need to remove the "Other..." option from the Quality prefs dropdown for Project rate.

==========================================================

What this does highlight is the risks attached to having multiple ways to do the same thing (or what looks like the same thing).
Comment 6 Peter Sampson 2018-09-11 06:39:15 UTC
And further I note that if they are unified as James suggests in Comment #2 we have different nomenclature in the two places

a) Qulaity prefs:  "Default Sample Rate"

b) Selection toolbar:  "Project Rate"


If they are the same thing, then surely they should be called the same thing.
Comment 7 Peter Sampson 2018-09-11 06:53:27 UTC
And be aware that in 2.2.2 withe the "Other..." in Quality prefs there is the ability to set silly ultra low values of 1 or 2 Hz (which, sort, of, work) and even negative Hz (which don't work) - so some range checking could be useful if we retain arbitrary settings.

Though I do note a recent post on the Forum which asks:
>How can I put a song in 2 hz ? Thank You, please help!

:-//
Comment 8 Peter Sampson 2018-09-11 07:03:15 UTC
Testing on EW10 with: audacity-2.3.0-alpha-123-1b6cd725e6e1f450b761db0f17bff37f592597de

1) virgin factory settings
2) Set a non 44100 rate say 96000 in Quality Prefs and click OK
3) Observe Project Rate in Selction Toolbar does not change
4) return to Quality prefs
5) observe "Default Sample rate" has  been returned to 44100

6) Set a rate of say 48000 in Selection toolbar
7) Quality Prefs
8) observe that this is now set to 48000

So we keep in step one way but not the other ...
Comment 9 Peter Sampson 2018-09-11 07:16:34 UTC
By (In reply to Peter Sampson from comment #5)
>And we now appear to have lost the ability to achieve arbitrary 
>user-defined Rate settings.

Not so - as I discovered after careful reading of the Manual ...

In the Selection toolbar in 2,2,2 and in the latest 2.3.0 alpha one can simply
over-type the value with your arbitrary value - this than gets propgated to the setting in Qulaity Prefs.

But doesn't work the other way around as I explained in Comment #5
Comment 10 Peter Sampson 2018-09-11 09:46:51 UTC
Testing on W10 with audacity-2.3.0-alpha-124-abd473747ea29eda34137591615ba1815b857521

The bug as listed in the title and the "Steps ..." is fixed by this Build #124

==============================================

Furthermore - with regards to the other related discussions on this bug thrad which could have been residual bugs, I am satisfied that James has now created clear coherent behaviors,

Accordingly I am going to close this bug off as RESOLVED