Bugzilla – Bug 1617
Clipfix very slow
Last modified: 2018-08-20 11:45:48 UTC
Clipfix is significantly slower than it should be due to repeated passes over the same data. Assigned to myself.
https://github.com/audacity/audacity/commit/a9879bddf Tested on Linux. Clipfix is still a slow effect, which is unavoidable, but the duplicate pass has been eliminated, giving about a 30% increase in speed on my machine.
First, a general "thank you" to Steve for all the Clipfix improvements. Testing with individual tracks up to 2 hours long (44100 Hz) on the different platforms, and then with multiple tracks, I found Sierra Mac mini and Win 10 laptop about 75% to sometimes 100% faster than before, and the slow Ubuntu 14.04 netbook about one-third faster. The improvement was also seen with low (8000 Hz) and high (192000 Hz) tracks, and when track and project rate differed. I left a query open on the Test OK flags because the speed improvement tails off rapidly when threshold is below about 50% (only tested with 44100 Hz tracks but I see it on all platforms. At 20% threshold, 2.1.3 and 2.2.0 run at about the same slow speed. I don't know why anyone would want such a low threshold - it seems to give poor results to me.
(In reply to Gale Andrews from comment #2) > the speed improvement tails off rapidly when threshold is below about 50% That's not surprising because, with a very low threshold settings a high proportion of the waveform will be marked as 'clipped' in the first pass, so the peak reconstruction pass will dominate the processing time.
(In reply to Steve Daulton from comment #3) >> (In reply to Gale Andrews from comment #2) >> the speed improvement tails off rapidly when threshold is below about 50% > That's not surprising because, with a very low threshold settings a high proportion > of the waveform will be marked as 'clipped' in the first pass, so the peak > reconstruction pass will dominate the processing time. OK so on that basis it sounds as if we can just resolve this now.
