Bugzilla – Bug 1574
Built-in generators may generate wrong length
Last modified: 2018-08-20 11:45:37 UTC
This is repeatable on Debian stable with Tone, Chirp, Noise, and DTMF generators, but not Silence or Nyquist generators. See Steps to reproduce.
I've only tested on Linux.
Assigned to myself.
Is then what happens with generating 10 samples correct? There are 10 sample dots on Linux. The selection generated extends a whole sample period beyond the end of the track, but that selection is also the same if you double-click in the track. The selection only needs to extend half a sample period to include the last sample, AFAICT. Regardless is the issue that there are only 123455 samples of audio? What is a good way to measure the number of sample dots?
(In reply to Gale Andrews from comment #3) The Selection Toolbar shows the correct length of the selection. Double click on a clip selects all samples in the clip. Put the two together and you get the exact number of samples in the clip. The bug is due to a rounding error when the Effect code converts from time in seconds to time in samples. Currently the number of samples is calculated as: round-down(duration * sample-rate) rather than round-to-nearest(duration * sample-rate) which, in the "steps to reproduce" case, gives "genLength" (the number of samples to generate) of 123455 samples.
(In reply to Steve Daulton from comment #4) > The Selection Toolbar shows the correct length of the selection. > Double click on a clip selects all samples in the clip. > Put the two together and you get the exact number of samples in the clip. I see. In that case I can reproduce it on Ubuntu 14.04 but not Win 10 or Sierra.
DEVEL-FIXMADE https://github.com/audacity/audacity/commit/a80556df2fdc481a11385d04ec3bea9e28a274a0
Testing on w10 Home audacity-win-4a0fbf8-2.2.0-beta-26Sep17 and on macOS 10.13 High Sierra with Paul's latest Mac build of 10Oct17 I still only get 123,455 samples rather than the requested 123,456 - but the end position of the tracks hows as 123,456 with some blank space between the 123,455th sample and the cursor when moved to track end. Accordingly I shal mark this REOPENED
(In reply to Peter Sampson from comment #7) Testing on Sierra (and Linux) with a2a08e8 (10th Oct), I'm getting the correct 123456 samples.
Testing on W10 with 2.2.2 JC008 25Jan18 I get the full set of samples - so on the additional basis of Steve's tests I shall mark this as resolved
