Bugzilla – Bug 617
Change Tempo: Wrong amount of data sent for preview
Last modified: 2018-08-20 11:45:41 UTC
Preview Change Tempo with a positive % change (say about +100%) and the preview plays a short preview followed by silence. The attached patch is derived from the patch by Clayton Otey for bug 271
Created attachment 346 [details] Change Tempo Preview fix
I note there is a comparable issue in Change Speed with positive changes. Should that have a bug opened for it? What should happen in both effects if you select the last x seconds in a track (where x is the preview length in Preferences), then apply a positive change?
(In reply to comment #2) > I note there is a comparable issue in Change Speed with positive changes. That is partially 'fixed' with this patch in that it does not play silence at the end. To complete the fix and make the previewed length (play duration) match that set in preferences; yes that should have a bug report, but the precise description will change after this patch is implemented. If this patch is OK then I think it will be simple to update the Change Speed issue in similar fashion. The fix for "Sliding Time Scale..." is a bit more complex but I thought it would be easiest to split this down to one issue at a time and then apply it to the other affected effects when we know that the method works correctly. > What should happen in both effects if you select the last x seconds in a track > (where x is the preview length in Preferences), then apply a positive change? The last x seconds should play with the affect applied, which will of course be shorter because it is playing faster.
(In reply to comment #3) Thanks for the patch, Steve. "Input" and "Output" are not clearly about Preview, and GetInputLengthForOutputLength likewise (and quite a mouthful), so I changed the name. Also "Get" usually indicates an "accessor" method, i.e., that accesses a member var. I also made the parameter name consistent. Also removed the fprintf() line. We generally use wxLogDebug() instead, plus describe what the printed value is. Also added a little documentation of why it's necessary. Committed at r12216.
(In reply to comment #3) Steve wrote: > [comparable issue in Change Speed with positive changes] is partially 'fixed' with > this patch in that it does not play silence at the end. > > To complete the fix and make the previewed length (play duration) match that > set in preferences; yes that should have a bug report, but the precise > description will change after this patch is implemented. Having checked on all three platforms I am not able to identify a remaining issue with speeded up preview in Change Tempo and Change Speed. I hear the preview length set in Preferences, unless the result of the effect is to reduce the length below the Preferences length (in which case I hear the result length). The only problem I see is that the Windows progress bars don't travel the whole length of the dialogue, but the correct length of audio is played, and that problem with the progress bars seems to affect other effects too. The problem I do still see on all platforms (not noted in this report) is with slowed down preview in Change Tempo and Change Speed. At % changes of about -50% or leftwards on the slider, the preview played is less than the length set in Preferences (even if there is more audio to play). The progress bars do still appear to complete (or almost so on Windows). Is this what you are describing? If so that issue (for Change Tempo) is within the scope of this bug title.
> The problem I do still see on all platforms (not noted in this report) is with slowed > down preview in Change Tempo... Added the steps to reproduce it on Windows and reopened the bug as it cannot be resolved with its current title (unless some degree of incorrectness is acceptable at extreme slowdowns). This issue with slowed down preview does not now occur in Change Speed for me (at comparable settings) - see bug 620.
(In reply to comment #6) > Added the steps to reproduce it on Windows and reopened the bug as it cannot > be resolved with its current title (unless some degree of incorrectness is > acceptable at extreme slowdowns). I think this is a different bug: Try these steps: 1) Generate a click track, tempo 121 bpm, other settings at default. There should be 2 bars + 1 beat in the first 4 seconds. 2) Set Preview length to 4 seconds. 3) Preview with any non-time stretching effect. The last beat in the 4 second period does not sound. Testing on Linux, the preview duration appears to be about 50 milliseconds too short for all effects, which I'm not sure is worth worrying about, but if it is, then it is a different bug.
(In reply to comment #7) I confirmed the steps to reproduce on Mac and Linux. > I think this is a different bug: > > Try these steps: > > 1) Generate a click track, tempo 121 bpm, other settings at default. > There should be 2 bars + 1 beat in the first 4 seconds. I'm not sure what BPM you meant, but 138 BPM achieves that for me and makes the final beat lie just inside a selection of 4 seconds. > 2) Set Preview length to 4 seconds. > 3) Preview with any non-time stretching effect. The last beat in the 4 second > period does not sound. > Testing on Linux, the preview duration appears to be about 50 milliseconds > too short for all effects, which I'm not sure is worth worrying about, > but if it is, then it is a different bug. That is unreproducible on Windows or Mac for me, or on Linux with the hw device. So I am guessing this is the known problem with pulse truncating all playback i.e. if you generate a 138 BPM Click Track, change Selection Format to seconds, Snap To on, click at 4s and drag back to time zero, Play using pulse, can you hear the beat just before 4s? I can't.
(In reply to comment #8) > I'm not sure what BPM you meant, 121 beats per minute will generate 9 clicks within the first 4 seconds. i.e. two complete bars and the first tick of the third bar. Regardless of whether these steps reproduce a problem, the original bug 617 was not about the last few milliseconds sounded or not but was about the fact that the preview length was being miscalculated. Preview no longer plays a short preview followed by silence, this has been fixed.
(In reply to comment #9) > 121 beats per minute will generate 9 clicks within the first 4 seconds. Yes that is unambiguous, the extra BPM (121 instead of 120) brings the 9th click just inside 4 seconds. But you said two bars and one beat. Musically, two complete bars is 9 beats in my book (if you were looking at a score) so I understood you meant 10 clicks. > Regardless of whether these steps reproduce a problem Do you disagree they reproduce a problem? Do you agree the bug you described with shortened preview in all effects http://bugzilla.audacityteam.org/show_bug.cgi?id=617#c7 is a pulseaudio problem and not an Audacity problem, so we don't need to pursue that? > the original bug 617 was not about the last few milliseconds sounded or not but > was about the fact that the preview length was being miscalculated. Preview no > longer plays a short preview followed by silence, this has been fixed. Agreed, but the bug title was too generic, so will have to be changed. The current title "Incorrect Preview in Change Tempo" also describes the problem noted in the steps to reproduce. Do you think that degree of incorrectness in the steps to repro is acceptable for that degree of slow down and should or cannot be fixed? I think it is probably a P5, if it should be fixed. Change Speed does not have this "problem". Preview plays a click that lies right at the end of the preview length.
> Musically, two complete bars is 9 beats in my book.. I'd rather go with the RSM definition if that's OK ;) > Do you agree the bug you described with shortened preview in all effects > http://bugzilla.audacityteam.org/show_bug.cgi?id=617#c7 is a pulseaudio problem > and not an Audacity problem, so we don't need to pursue that? On my computer with Debian Squeeze, this "problem" is reproducible whether I select Pulse or directly with the hw device. On the same hardware it is not reproducible with Vista. I put "problem" in quotes because I don't see it as an important issue that will cause difficulty for anyone but the most obsessively fussy. Really this was just an "observation". The current "steps to reproduce" are repeatable on my Debian system, but the amount of "error" is not much greater than the above "problem" that applies to all other effects. I assume that the "steps to reproduce" apply equally to Windows, so I would guess that the fact that there is a little extra inaccuracy in the case of slowing down the tempo is due to limitations in the SoundTouch library. To support this theory: 1 New 44100 Hz project. 2 Set Playback Preferences to a preview length of 4s. 3 Generate default Click Track. 4 Trim the track from 0.0 to 0.51 seconds. 5 Effect > Change Tempo, enter -88 and apply effect to show that the second click is not output from the effect.
(In reply to comment #11) > I'd rather go with the RSM definition if that's OK ;) It's the usual story of where something ends and begins and how to describe it. Two bars in 4/4 have eight beats, but unless a selection at least abuts the ninth click, the second bar can't be called "complete". In performance, I think musicians naturally err to include the first beat of the next bar to avoid it sounding "incomplete" where that bar is the end of the note. > I assume that the "steps to reproduce" apply equally to Windows Yes. > I would guess that the fact that there is a little extra inaccuracy in the case of > slowing down the tempo is due to limitations in the SoundTouch library. > > > 1 New 44100 Hz project. > 2 Set Playback Preferences to a preview length of 4s. > 3 Generate default Click Track. > 4 Trim the track from 0.0 to 0.51 seconds. > 5 Effect > Change Tempo, enter -88 and apply effect to show that the second > click is not output from the effect. Yes, that is part of the problem, but not all of it as the steps to repro show.
(In reply to comment #12) > Yes, that is part of the problem, but not all of it as > the steps to repro show. Perhaps my choice of bug summary (title) was not sufficiently precise The bug that I was referring to when I raised bug 617 was that Change Tempo was sending the wrong amount of data for preview. I thought that this would be clear from the bug Description. This is still a bug for Sliding Time Stretch / Pitch Shift. The "Steps to Reproduce" were added later by someone else and do not describe the bug that I was reporting when I raised bug 617. The way that I'm looking at it, in order to play 4 seconds of audio after slowing down to -88%, the plug-in must process: 4x(100-88)/100 = 0.48 seconds of audio. If you select exactly 0.48 seconds of 120 bmp click track and apply Change Tempo -88%, the second tick does not play (because it is not selected). The fact that Change Tempo plays the second tick at 3.5 seconds when the whole track is selected is because Change Tempo is playing that second beat too early, which I strongly suspect is due to a limitation in SoundTouch. Incidentally, testing "Steps to Reproduce" with unpatched Audacity 2.0.3 on Windows XP in Virtual Box, the second tick _is_ heard.
(In reply to comment #13) In order to proceed, RESOLVED - FIXED this bug with title changed from "Incorrect Preview in Change Tempo" to "Change Tempo: Wrong amount of data sent for preview" to (possibly) distinguish it from the (now removed) steps to repro which (I think might) describe an "incorrect preview" of a Change Tempo limitation. Taking that "incorrect preview" off bugzilla to discuss with Steve, alongside some possible accuracy improvements to Change Tempo/Change Pitch.
