Bugzilla – Bug 1208
Spectrogram vertical zoom-in is limited to ten bins
Last modified: 2018-08-20 11:51:41 UTC
Set a track to Spectrogram view with logarithmic scale. Make the track tall (to see the bug clearly). Zoom out vertically to see 1 Hz to 20000 Hz. Click and drag on the vertical ruler from 1000 Hz to 100 Hz. Expected behaviour: The track will zoom vertically to show 100 Hz to 1000 Hz Actual behaviour: The track zooms to show 1 Hz to 1000 Hz. Click and drag again from 100 Hz to 1000 Hz. Nothing happens.
Added steps to reproduce. Would have added release notes, but as I think this should go PX->P4 I didn't. Linux -> All platforms.
Assigned to Paul (for 2.1.3)
I get the correct, expected zooming behavior on Windows with the latest master. Are we sure this occurs on all platforms?
I get the behaviour that Steve describes, on Windows 7. The reason I do and you don't is, I think, that I have the default window size. I'm expecting to zoom in on the range 100 to 1000. In this code: min = std::max(spectrumLinear ? 0.0f : 1.0f, std::min(middleValue - minBand / 2, scale.PositionToValue(xmin) middleValue is 317.07 minBand is 1722.65 And we get 1 instead of 100 as the lower limit. It happens for linear too. I think the point is that when zooming we always try to show at least 5 bins above and below the middle frequency so that we don't zoom in too far. Possibly then for 2.1.3 we could address this by increasing the default window size, so that we have more bins, and reducing the minimum number of bins from 10 to 4, so that it is really obvious that you are zooming in too far. For 2.1.2 I think it's possibly worth a note in the manual that you won't be let zoom in 'too far' and that you will get more detail (more bins) to zoom in on if you use a bigger window size.
(In reply to James Crook from comment #4) Clarification: I am of course talking about the FFT 'window size' setting in Spectrogram settings, not the 'window size' of the application. That would need to be spelled out in clear in the manual!
Thank you James, I made a hasty foolish answer without considering spectrogram preferences. I know very well that the ten-bin limit on zooming in the spectrogram scale was in the code already and I did not change it. So that constraint may be overriding, for any vertical scale, not just logarithmic, and the problem (if it is a problem) is not new in 2.1.2. I retitled the bug.
Created attachment 635 [details] zoomed in to less than 10 bins I'm not sure that the new bug title accurately describes the problem (though perhaps that does not matter as long as the bug is fixed). As shown in the attachment, it is possible to be zoomed in closer than 10 bins. The problem is that the UI makes doing so difficult and non-intuitive.
(In reply to Steve Daulton from comment #7) How did you obtain that picture? Someone intentionally limited the zoom in to ten bins once (or, if there are fewer than ten bins, to all bins, when the window size is 8 or 16). If that is the "correct" thing to do, then I need to know how you got the picture so I can fix the inconsistent enforcement of the zoom-in limit. Then we need to decide what the zoom-in limit should be instead, and enforce that zoom limit consistently. So then, what should it be if not ten bins? One bin? Two bins? So many Hz? Or, some fraction of the track's Nyquist frequency?
(In reply to Paul L from comment #8) I can get a picture with one bin in it by zooming at 32768 window size and then switching back to 256 window size. I'm taking the unusual step of: a) Unilaterally making this PX bug P4, without input from Gale. b) Committing a fix (even though it is only P4 and we are in FREEZE). The reason is that discussion is taking too much of our time and attention. I think Steve thinks it's a P3. It is easier for me and better to fix it than write a sensible release note. Even arguing about whether it needs a release note or a note in the manual takes time. As RM I do not want an open PX bug during FREEZE. So rather than mark it as INVALID which would be disrespectful to Steve, I've made a fix that addresses the issue. I take personal responsibility for any possibly serious bug introduced by my 'fix', and for setting the priority as low as P4.
(In reply to James Crook from comment #9) I have reviewed your small change and have no complaint. Be it noted this problem was not a regression from 2.1.1.
(In reply to Paul L from comment #10) Perhaps not strictly a regression because it was looked bit strange in Audacity 2.1.1 (one reason that I did not assign an initial P rating) but from a user perspective it certainly looked worse in 2.1.2 alpha because in 2.1.1, the final step of zooming down to 100 Hz did allow zooming down to 100 Hz, whereas in 2.1.2 the final step failed silently. As James said, I would have been inclined to mark it P3 because it "looked" noticeably worse than before. It is important that Audacity provides users with the confidence of "production quality software". (In reply to James Crook from comment #9) Thanks for the fix. Zooming to 1 bin is perhaps a bit OTT in reality, but it certainly "looks" much better. There is a residual issue, but it can perhaps be logged as a new P4 issue: In Spectrogram view with non-linear scaling, zooming in very close at around (for example) 10 kHz, the zoom level can exceed the resolution of the vertical ruler ticks so that the ruler shows no numbers. It is a bit disconcerting if switching from linear scale to a non-linear scale and the numbers disappear. Should I log that as a new issue?
(In reply to Steve Daulton from comment #11) Yes please log it as a new P4.
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 of these platforms I get the proper vertical zoom from 1000 Hz to 100Hz Looks to be fixed
Tested at 396a6f0 from audacity/audacity on Linux. I get the proper vertical zoom from 1000 Hz to 100Hz, so flagging this as Test-OK-Lin.
Closing this bug that was tested an all three platforms a while back (and still works an alphas on Win and Mac
