Bugzilla – Bug 1977
Using Spectrogram Settings in TCP or using Preferences causes Audacity to reset Project Rate to default rate in Quality Preferences
Last modified: 2018-09-11 09:58:55 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.
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
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
(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
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.
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).
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.
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! :-//
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 ...
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
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