Bugzilla – Bug 172
Sliding Time Scale effect: reversed pitch change and broken > 44100 Hz
Last modified: 2018-08-20 11:45:46 UTC
Tested on Windows and Linux. After http://code.google.com/p/audacity/source/detail?r=10470 to fix crashes: On both OS'es, a negative pitch change is interpreted as positive and vice versa. Significant problems on Windows (but not Ubuntu): *A tempo change (only) now affects the pitch - you can verify that with any constant tone. *The pitch change moves too far too fast at the start if there is no initial pitch change but a final change. If I generate a steady 2 minute tone at 440 Hz (A above middle C), select from 5s to the end and ask only for a final reduction of -12 semitones, as soon as 5s is reached there is an abrupt jolt upwards to (something like) B above middle C. On Ubuntu the start of the changed area clearly still sounds like A. *There is always silence at the end of the result if I apply the effect to the entire track, although no audio is apparently truncated. This silence is at the end of the track even if I only apply a +12 to -12 pitch change (the number of samples remains correct).
Windows XP behaves like Linux (only has the reversal of pitch change direction). Just to be sure, I rebuilt SVN HEAD from clean checkout and Windows 7 problems are the same as before.
Looked at the code in audacity/src/effects/ and si.pitch0 is being set properly in TimeScale.cpp/SBSMSEffect.cpp. The problem is in the sms code in lib-src. Since this is a branch I don't think I should touch it. I think we should make advanced effects like this modules/plugins because the functionality itself is modular. Also this way don't have to deal with as many bugs 'in' audacity.
Further investigation proved that the problems found on Windows 7 occurred on all OS'es, the trigger being any project rate > 44100 Hz. Clayton has fixed that and the pitch change reversal and is testing before committing. Current situation is in the Forum thread: http://forum.audacityteam.org/viewtopic.php?f=17&t=30747&start=20#p90857
(In reply to comment #3) It's been almost 4 months, so I just sent Clayton an email asking when he might be ready to submit a patch.
It's now been many months of waiting for a checkin that will happen 'soon, and since we're closing a lot of p2s and getting near stable release, I'm proposing to wait till december 15 on hopes that clayton will fix this and then if no one else objects I will patch the current source. The bug fix is just a few lines and is relatively easy to find and fix, so even if clayton's next update kills the patch he or I can just redo it if the new code still has the bug.
(In reply to comment #5) +1, Michael. And btw, I pinged him about this off list a few days ago and haven't heard back. He previously wrote that he'd finish it by end of October, so I agree it's likely not to happen.
(In reply to comment #6) I'd also reminded him in the Forum topic on Nov 30th but there was no response. I've told him in that thread we're having a deadline of Dec 15th. If he said on the 14th "I can have it done on the 16th" and that happened, I think that would be fine and preferable (but not wait further if it didn't happen).
I've commited a hack that just inverts our code (not touching sbsms src.) If there are remaining issues maybe we should just disable this effect as it is pretty glitchy anyways and I don't think users would find it very useful until it has an envelope gui. Attaching the patch so we can revert it if a fixed version is checked in.
Created attachment 61 [details] hack for sbsms bugs revert when sbsms code is fixed.
(In reply to comment #8) > If there are remaining issues maybe we should just disable this effect as > it is pretty glitchy anyways and I don't think users would find it very > useful until it has an envelope gui. According to Clayton, the remaining issues he was trying to fix in his updated library were "occasional audible transient artifacts or undesired amplitude modulation in closely spaced tones when samples are timestretched. I could just tweak some parameters so that the frequency is better resolved and these artifacts go away, but then the time representation is annoyingly smeared out." My take is that the glitches with SoundTouch are significantly worse than with sbsms so we often have to recommend sbsms in preference: http://wiki.audacityteam.org/w/index.php?title=SoundTouch&oldid=16415 An envelope GUI would be a nice addition though.
(In reply to comment #10) >My take is that the glitches with SoundTouch are significantly worse than with >sbsms... I haven't done much comparison, but I trust your evaluation, so agree it should be in. Can the bug be closed?
(In reply to comment #11) > Can the bug be closed? Sorry not yet, the pitch and tempo change seems broken now. First things I tried on Ubuntu and Win 7 were: 1 New (project 32-bit float,44100 Hz) 2 Generate 440 Hz tone default length, amplitude 0.8 3 Effect > Time Scale, set Initial and Final Pitch Shift (semitones) to 5 > OK 4 Tone does not change pitch at all, but its amplitude is increased from -1.9 dB to -1.6 dB 5 Edit > Undo 6 Effect > Time Scale, set Initial and Final Tempo Change to 50, try to change Initial Pitch Shift from 5 to 0, and OK button greys out Changed quality prefs to 96000 Hz, started new project, did steps 2 and 3, and the result is no change of pitch, amplitude increased to -1.1 dB. Have posted to the Forum topic again: http://forum.audacityteam.org/viewtopic.php?f=17&t=30747&start=40#p117369 Perhaps Clayton has a quick fix we could use if he still can't commit?
Created attachment 68 [details] apply/revert in sequence with previous patch Sorry, I only tested with percent change (not semitones,) which was working. followup fix applied in r10836 for working with semitones. patch also attached for completeness - revert in sequence with original patch when sbsms bug is fixed.
I've tested on Win 7 and Ubuntu 10.10 with a 441000 Hz music WAV and 44100 Hz, 96000 Hz and 192000 Hz tones. No differences between one sample rate and another but we still have two problems pertinent to this bug. 1) Tempo change is reversed (entering a negative speed change now speeds up and vice versa) 2) If you enter the pitch change in a % box the value that appears in the corresponding semitones box has the wrong sign e.g. enter 33.484 in a pitch % box and the pitch semitones box shows -5 (and is ignored because +5 is applied). So it works as entered, but it's really confusing. I've also added a comment in the Forum thread: http://forum.audacityteam.org/viewtopic.php?f=17&t=30747&p=125112#p125112
Gale, I checked in a fix for your issues in r10887
Created attachment 70 [details] Michael's final patch to fix bug - revert in sequence with previous patches
(In reply to comment #15) > I checked in a fix for your issues in r10887I checked in a fix for your issues > in r10887 Thanks, tested and resolving fixed now.
