Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: One updated and one new audio processing DSP library (Read 2998 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

One updated and one new audio processing DSP library

I have made some significant improvements to the audio-stretch library and have created a sort-of complimentary library for audio resampling. Both are available on my GitHub account and both include pre-built Windows executables intended for demo purposes (although they’re perfectly usable as command-line applications):

Audio-stretch library on GitHub

Audio-resampler library on GitHub

The audio-stretch library has been up for years, but someone recently suggested a couple improvements and I also made some small performance enhancements and edge-case bug fixes. It implements time domain harmonic scaling (TDHS) to stretch (or squeeze) audio data in the time domain (i.e., it changes the duration of audio clips without changing their pitch). This is useful for slowing audio to make it more intelligible or speeding it up to more quickly digest audio books or podcasts.

Previously the stretch ratio was limited to just 0.5X - 2.0X, but by cascading two instances internally I doubled that range to 0.25X - 4.0X. The other new feature is the ability to detect silence gaps in the audio and use a different ratio for those portions. This is useful for further speeding up speech and keeping it intelligible.

The audio resampling code is a new repository, but I actually wrote it over 15 years ago for the project described in this post where it's used to oversample audio 256X. I’ve used it in several places and made improvements over the years since and thought it might be useful to others. So I wrote a command-line demo for it with an option for including a biquad lowpass if desired.

It’s a relatively simple implementation intended for real time or embedded applications while not necessarily offering the best offline quality (there are several great examples of that around). It’s all one C module (except for the biquad) and should be trivial to build and integrate with applications, and it can easily be fine-tuned for the environment with respect to CPU and memory usage (and at the higher quality settings is quite respectable). Most recently I put it in a real time ASRC used for synchronization in a wireless speaker (it includes the functionality to query the current phase used in the feedback loop).

I say that these libraries are complementary because while they are certainly useful independently, together they can provide the tempo/pitch/playback controls that media players often have. And although it’s subjective, I believe that they offer somewhat higher quality than the other free implementations I’ve tried (especially for playing slower).

Hope someone might find something useful here...   :)

Re: One updated and one new audio processing DSP library

Reply #1
Thank you very much for sharing these libraries.

I have been looking for something similar to Audio-Stretch for a long time, then had it on my todo list since I saw your post.
Today, I finally implemented a foobar2000 DSP based on it: https://www.foobar2000.org/components/view/foo_dsp_audiostretch
Microsoft Windows: We can't script here, this is bat country.

Re: One updated and one new audio processing DSP library

Reply #2
Thanks Peter, glad they were useful.

I tried the component and it sounds the same as when I run it offline (a good sign).


Re: One updated and one new audio processing DSP library

Reply #3
The resampler is now included in the Infinite Wave SRC Comparisons.

These are useful for investigating SRC implementations, although one obviously has to take the computational complexity into account when comparing SRCs for a given application (and this is not shown).

Re: One updated and one new audio processing DSP library

Reply #4
Weird thought:

How do you reckon vectorization would go? Thought of SSE4/NEON?

Re: One updated and one new audio processing DSP library

Reply #5
Weird thought:

How do you reckon vectorization would go? Thought of SSE4/NEON?
Not a weird thought at all. I assume that modern C compilers will vectorize the correlation loop (of which there are several versions to choose from).

I use -Ofast with gcc and choose the fastest version of the loop when I make a build, and I assume I'm getting vectorization but have never really looked any further than that.

Re: One updated and one new audio processing DSP library

Reply #6
Reason I asked is I reckon these are pretty cool, a resampler DSP for FB2K based on this new resampler would be nice to have.

Plus I think DEATH got the tempo DSP working on FB2K mobile (and I tested and it works great on Android), so maybe indeed clang and others are smart enough to properly vectorize those loops.

Re: One updated and one new audio processing DSP library

Reply #7
I use -Ofast with gcc
Be careful with that. GCC will insert code to change the CPU's floating-point behavior, and that might affect the program using your library in unexpected ways.

Re: One updated and one new audio processing DSP library

Reply #8
I use -Ofast with gcc
Be careful with that. GCC will insert code to change the CPU's floating-point behavior, and that might affect the program using your library in unexpected ways.
Ah, thanks, that's good to be aware of! So it doesn't restore the behavior on function exit? That's not very nice.

In any event, I'm not distributing a library. This is just a single C file with header, so it would normally be included and built within a larger application (whose developer is hopefully aware of these issues).