adblocker VS audacity

No well-known content blocker "process about 90,000 regexps" to find out whether a resource needs to be blocked or not, that's just not how it works internally.

Last time I ran benchmarks of all well-known content blockers using Ghostery's benchmark tool[1], all of them could process a network request under 20µs on average.

Some do have performance concerns, but it has nothing to do with network filtering, it has to do with other stuff they do beyond network filtering (for example see [2]) and declarativeNetRequest does not help there, so they will still suffer these performance issues under MV3.

---

[1] https://github.com/ghostery/adblocker/tree/master/packages/a...

[2] https://www.extremetech.com/computing/182428-ironic-iframes-...

Only benchmarking can tell, we shouldn't make assumption about this. Currently the only comparative benchmark which I know of is ghostery/adblocker and running it with the latest static filtering engines shows uBO performing better:

With that in mind, uBO's blocking engine is currently the fastest as demonstrated by latest Cliqz's benchmarks, so the "quicker" claim does not hold either.

Author of RSS Guard here. After considering many approaches, I managed to dump old C++-based slow adblocking mechanism from RSS Guard and replaced it with this.

Thanks to the Wexond Shield powered by Cliqz

#5467 Fix 24-bit recording.

The time stretch algorithm is implemented in https://github.com/audacity/audacity/blob/master/libraries/l... particularly functions _time_stretch and _process_hop. It looks to me like a classic phase vocoder with vertical phase coherence (c.f. https://en.wikipedia.org/wiki/Phase_vocoder).

The basic idea is this. For a time-stretch factor of, say, 2x, the frequency spectrum of the stretched output at 2 sec should be the same as the frequency spectrum of the unstretched input at 1 sec. The naive algorithm therefore takes a short section of signal at 1s, translates it to 2s and adds it to the result. Unfortunately, this method generates all sorts of unwanted artifacts.

Imagine a pure sine wave. Now take 2 short sections of the wave from 2 random times, overlap them, and add them together. What happens? Well, it depends on the phase of each section. If the sections are out of phase, they cancel on the overlap; if in phase, they constructively interfere.

The phase vocoder is all about overlapping and adding sections together so that the phases of all the different sine waves in the sections line up. Thus, in any phase vocoder algorithm, you will see code that searches for peaks in the spectrum (see _time_stretch code). Each peak is an assumed sine wave, and corresponding peaks in adjacent frames should have their phases match.

https://github.com/audacity/audacity/releases

If you are able to build from source, you could download the latest source code, or the latest release version source code, and manually apply the patch.

FWIW: We'll be ditching the atlases for 3.4 most likely, in favor of having themes work like they do in source anyway: With individual PNGs for the icons and a Colors.txt containing all the color definitions. With that, custom themes would be much easier to author and also would stop breaking every time we introduce a new icon.

https://github.com/audacity/audacity/issues/4639 this bug mentions everything, I guess it's Audacity after all. To be fixed in 3.3.2

No there isn't. I searched in vain for a workaround, and then checked the Audacity issues and found this: https://github.com/audacity/audacity/issues/3385