Sonic visualiser time instants12/16/2023 The main novelty in version 3.1 is an option to deactivate R3’s multi-window processing system, dropping down to a single shorter processing window and potentially running much faster, while retaining its more advanced signal analysis and some of its output characteristics. This option ensures that the resampler used for the pitch-shift part of the operation is always engaged, so that there are no discontinuities when changing ratio (particularly to or from the 1x ratio). The last point happens because we are using OptionPitchHighConsistency. Both stretchers use increasingly more CPU when pitch-shifting further upward, but not when shifting down.R3 is very predictable in this area by comparison. This may be because it continues to perform transient detection and adjust its input and output steps accordingly, and at those rates our test file contains a lot of transients. R2’s processing time becomes very variable, and relatively high, when speeding up the audio by a large factor (above about 3x).It’s still faster because it does so much less work for each increment. R2 has less widely-spaced distinct “modes”, because it uses smaller increments.R3’s long internal processing buffers and step size mean that it hops between “modes” depending on how many processing increments (1, 2, 3, 4 or occasionally 0) are required for each output block.R2 is usually faster, sometimes much faster, especially for modest stretch factors.The plots for R2 (orange) and R3 (purple) reveal significant differences in behaviour: In the first quadrant, the pitch rises smoothly and then falls again, reaching a peak at two octaves up in the second it falls smoothly and then rises again, reaching a trough at two octaves down in the third the pitch is unchanged but the tempo slows to just under a third of the original speed and then returns to normal and in the fourth quadrant the tempo gradually speeds up to 8x the original speed and then returns to normal. The test runs in four consecutive phases with different pitch and time modifications, and so the x-axis is divided into four (uneven) quadrants: raising pitch, lowering pitch, slowing down, and speeding up. Obviously the relative heights may also vary from system to system, so this is still quite tentative. No units are shown because they are totally system-dependent - this is purely a comparative visualisation, we’re only interested in the relative heights. The y-axis is linear in time with zero at the bottom, so lower is better. The results for R2 and R3, as of the 3.0 release, look like this: This is a graph of processing cycle count (x-axis) against time taken per 512-frame cycle (y-axis). The stretcher is initialised with typical parameters for this activity (in code terms, OptionProcessRealTime | OptionPitchHighConsistency | OptionFormantPreserved) and it is primed with an initial pad before entering the cycle loop, as otherwise the first call would dominate results. To measure this, I set up a test case that simulates a typical sound processing callback, passing a music recording through a stretcher and emitting a fixed 512 sample frames from each processing cycle, while varying the time and pitch ratios and measuring how long each cycle takes to return. Rubber Band is often used in real-time situations where the worst-case time per processed block is what matters most. Sustained throughput is not the only measure. Still, as it turns out, there are a few things we can do. It would be nice to do better, but the R3 code was already quite heavily optimised before release - it is simply a fairly CPU-intensive method. Both are eminently usable in real-time on hardware from the last decade, but the headroom available for R2 can make a big difference. Measuring sustained throughput in frames-per-second for common fixed stretch factors, we find R2 to be typically about three times as fast as R3. The older one is still included, and I’ll call that R2.Īlthough the output of R3 typically sounds much better than R2, it uses a lot more CPU power to run. In version 3.0 we introduced a totally new, higher-quality processing engine, which I’ll refer to as the R3 engine. This release focuses primarily on performance improvements. Today marks version 3.1 of the audio time-stretching and pitch-shifting library Rubber Band.
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |