Bugzilla – Bug 1241
Change Speed effect is not sample accurate
Last modified: 2018-08-20 11:46:14 UTC
The speed change ratio is being rounded to 3 decimal places, so when an exact "New length" is specified in samples, the actual new length rarely the exact length specified. The problem occurs in bool EffectChangeSpeed::TransferDataFromWindow() mUIParent->TransferDataFromWindow() causes m_PercentChange to be rounded. This is a regression against 2.1.0
So will we be storing an unrounded percent change value in pluginsettings.cfg (as opposed to audacity.cfg where the accurate value was stored in 2.1.0)? In 2.1.0, incrementing length by even by as much as 30 ms (let alone 30 samples) might not change percent change, so it doesn't inspire confidence that it is sample accurate, even though it is.
(In reply to Gale Andrews from comment #1) > So will we be storing an unrounded percent change value in pluginsettings.cfg Yes. Assuming the value is a float we can't guarantee sample accuracy for very long tracks at very high sample rates, but we are good for more than an hour at 44100 Hz and within 1 millisecond even for extremely long recordings (days). > In 2.1.0, incrementing length by even by as much as 30 ms (let alone 30 > samples) might not change percent change, so it doesn't inspire confidence > that it is sample accurate, even though it is. The alternative is that we have 10 decimal places or more in the text boxes, but that is not very user friendly either. If we always update the text boxes to the 'exact' amount, then using the slider or "New Length" will almost always generate lots of digits in each box. Even the presets could display numbers like 1.73333333333333339254522798000834882259368896484375 In use cases where an exact output length is required, the easiest, best and in my opinion most obvious way to do that is to use the "New Length" input (which is precisely why I added it).
(In reply to Gale Andrews from comment #1) > In 2.1.0, incrementing length by even by as much as 30 ms (let alone 30 > samples) might not change percent change, so it doesn't inspire confidence > that it is sample accurate, even though it is. Conversely, it does indicate that to achieve an exact output length you 'should' use the "New Length" input (because the text input boxes are clearly limited to 3 decimal places).
(In reply to Steve Daulton from comment #3) >> In 2.1.0, incrementing length by even by as much as 30 ms (let alone 30 >> samples) might not change percent change, so it doesn't inspire confidence >> that it is sample accurate, even though it is. > Conversely, it does indicate that to achieve an exact output length you > 'should' use the "New Length" input (because the text input boxes are clearly > limited to 3 decimal places). Having tested 2.1.2 and 2.1.1 and observed this bug, but before finding this report, the behaviour I note made me assume that 2.1.0 had the same issue. We've probably had the same discussion before, but I am still not convinced this is optimal in the absence of any indication that the rounded text box values will be applied at greater accuracy than they display. I agree displaying "1.73333333333333339254522798000834882259368896484375" in the text boxes is not practical. Adding some character after the decimal place to indicate if the value is rounded would not help indicate that the text boxes were responding to changes in the length box if the displayed values were already rounded on opening the effect. So I don't have any real answer, beyond perhaps indicating the unrounded (or less rounded) percent change as text below the length box. That would clearly indicate that length changes were affecting the percent change. Naive users may not find it obvious that the length box always updates percent change in a short selection but not in a long track.
(In reply to Gale Andrews from comment #4) I think that the best we can do is to give the exact result based on user input: If the user enters a speed multiplier, they get the exact multiplier. If the user enters a Percent Change multiplier, they get the exact percent change. If the user enters a Vinyl rmp, they get the exact rpm ratio. If the user enter a New Length, they get the exact new length.
(In reply to Gale Andrews from comment #4) > I agree displaying "1.73333333333333339254522798000834882259368896484375" in > the text boxes is not practical. To guarantee sample accuracy for a 1 hour selection at 96 kHz sample rate, we would need 9 decimal places for the "Speed Multiplier". I think that 11 characters (including the integer part and decimal point) is too much. (for very long or high sample rates we would need even more digits) If we accept that rounding to less than the decimal equivalent of single precision (about 12 decimal places) is a necessary evil, then it's a question of how many decimal places is reasonable. Provided that sample accuracy is provided by the "New Length" control, I think that 3 decimal places is reasonable for the numeric text controls. If we don't accept such rounding, then the only answer that I can think of is that we display 12 decimal places / 14 characters (we can trim trailing zeros).
Should now be fixed as described in comment 5 by https://github.com/audacity/audacity/commit/4a5e188a0 Marked Devel Fix Made
Testing this on W10 audacity-win-r376fc0e-2.1.3-alpha-22-jan-16 it appears to be fixed. The greatest accuracy I can input is to three decimal places. If I input fewer decimal places then on next use I get zero-filling to three decimal places.
Testing on Mac El Capitan on 01a95c5-2.1.3-alpha-13-feb-16 Tests ok on Mac too
Seems OK to me. Tested different steps on Windows 10 x64 and Ubuntu 14.04 32-bit. * Generate 1 hour silence at 384000 Hz shows as 382,400,000 samples in TimeText Controls (it's really 1,382,400,000). If I reduce displayed length in Change Speed by one sample to 382,399,999 samples, Selection Toolbar shows that number of samples after running the effect. So it "looks" correct. Then I tested sample rate changes as there was a discussion on feedback@ around that. * If there are two tracks at different rates, Change Speed produces the correct number of samples in Selection Toolbar if either or both tracks are selected, with the proviso that the number of samples displayed in Selection Toolbar, given it calculates according to the project rate, is actually incorrect for the track that does not match the sample rate. * If I generate 10 samples at 44100 Hz then change "Rate" in the Track Dropdown Menu to 22050 Hz, Selection Toolbar and Change Speed think there are 20 samples instead of 10 (same reason as above), and reducing length in Change Speed to 18 samples reduces the number of actual samples to 9 as expected.
