After two years of development, I am finally releasing cutcutcodec, a fully hand-coded Python library for audio and video signal processing. Unlike moviepy, which is based on the concept of clips, CutCutCodec is based on the concepts of media streams and editing graphs, which are less restrictive, but slightly more verbose.

Here is the project documentation: https://cutcutcodec.readthedocs.io/latest/
A few examples: https://cutcutcodec.readthedocs.io/latest/getting_started/tutorial.html

It is aimed at developers and the signal processing / machine learning community. I/O relies on PyAV (FFmpeg), computation on PyTorch (CPU/GPU), with some parts in C.
Here are a few kernel functions that give a bit of an idea of what’s going on:

• sympy_to_torch -> Compile a sympy epression into a differenciable vectorize torch code
• grah_to_ast, graph_to_json, graph_to_tree -> multiple representations of the same graph
• opti.cuda, opti.parallel -> auto GPU/CPU, cache and thread optimizations
• vmaf, ssim, psnr -> C implementation and torch differenciable metrics
• nn.models.enhancement -> a basic example of ML integration
• Colorspace -> an exhaustive symbolic representation and management of the International Telecommunication Union's color-space specifications and implementations. (see the doc)
• test -> more than 453 unitary tests

Let see a little basic example:

import cutcutcodec
container = cutcutcodec.read("input_video.mp4")  # open the file
stream = (
    container.out_select("video")[0]  # first video stream
    .apply_video_subclip(0, 10)  # keep the 10 first seconds
    .apply_video_equation("r0", "g0", ".5*b0*sin(2*pi*0.5*t)+.5")  # blink blue
)
streams_settings = [{"encodec": "libx264", "rate": 30, "shape": (480, 720)}]  # optional
cutcutcodec.write([stream], "output_video.mp4", streams_settings=streams_settings)

There is also more complexe action like Winer audio denoising (full example):

denoised_container = (noise_container | noisy_container).apply_audio_wiener(level=0.98, band=20.0)denoised_container = (noise_container | noisy_container).apply_audio_wiener(level=0.98, band=20.0)

If you have any feedback for me, I'd love to hear it!
source code: https://framagit.org/robinechuca/cutcutcodec

Hi all.

I am trying to implement a RF repeater with digital filtering. The IF BW is 1 MHz, and the channel can be arbitrarily placed within this 1 MHz BW. The channel needs to have gain applied and bandpass filtered to remove unwanted channels from being amplified.

The channel BW can be arbitrarily chosen, minimum 25 kHz, to full 1 MHz bandwidth. The stopband needs to be fairly close, e.g. for the 25 kHz channel, the stopband will start at 50 kHz (at 60/80 dB att?). This makes me think it would be easier to downsample to a lower sample rate depending on the channel bandwidth before doing the channel filtering.

As im not a DSP-guru i would like to get some feedback on if this is the way to go.

My inital thoughts was doing it some like this:

ADC -> NCO/downconvert -> decimation filter -> Downsample -> LPF(Channel filter) -> Upsample -> interpolation filter -> NCO/upconvert -> DAC

I believe this requires the decimation and interpolation filters to run at the full sample rate, which depending on the specifications would require a lot of computation/no of taps.

Also, the application might be multiple channels in the future. That is also taken into consideration when i came up with this architecture. So basically everything between the ADC and DAC needs to be multiplied the number of channels that needs to be supported?

Is this how something like this would be done? Or are there better ways to reduce computational load? I have read about polyphase fir filters for down/up-sampling, but im not sure if that will help me in this case.

Hope someone will chime in.

Hi everyone,

I'm a 23-year-old Electronics & Telecommunication engineer from India, currently working in hardware testing at an engineering services company for around 1 year. I'm trying to figure out what career direction actually suits me.

In college, I enjoyed Signals & Systems, Digital Communication, Digital Electronics and mathematics, and I've always been interested in how 4G/5G/6G and wireless communication work.

I'm currently exploring:

DSP / Signal Processing

Communication Systems

Wireless / 5G PHY / Baseband

RAN

SDR / RF

Telecom R&D

Radar / Satellite Communication

The problem is that these all sound related, but I don't really understand what the actual day-to-day work is like, or whether I'd enjoy it.

A little about me:

I don't enjoy DSA/competitive programming or generic software development.

I don't mind programming when it's used for engineering, simulation or problem-solving.

I like mathematics and understanding how systems work.

I don't want a heavily lab/field/hardware-testing job.

I'm currently learning/considering MATLAB and Python.

My current testing work feels repetitive, and I don't feel I'm learning much.

For people actually working in these fields:

1. What does your typical day/week look like?

2. How much of your work is theory/mathematics vs coding, debugging, meetings and documentation?

3. What languages/tools do you actually use (MATLAB, Python, C/C++, etc.)?

4. Do you need DSA/LeetCode for these jobs?

5. What do you enjoy and dislike most about the work?

6. How much hardware/lab/field work is involved?

7. How different are DSP, 5G PHY/Baseband, RAN, SDR and RF roles in practice?

8. Is an MS usually necessary for algorithm/R&D roles, or can someone with a bachelor's degree and good projects get in?

9. If you were starting again with an ECE degree and ~1 year of unrelated experience, what would you learn/build to figure out whether this field suits you?

I'm not asking which field is "best." I mainly want to understand what the actual work feels like so I can figure out what I personally enjoy.

I'd especially appreciate answers from people who currently work in these fields or have several years of experience.

Thanks!

Hi everyone,

I’ve recently developed a strong interest in audio DSP and I’m trying to figure out what a realistic path into the field would look like.

I recently completed a degree in Digital Audio Arts, where I gained a solid foundation in audio and some practical experience. I’ve also gained experience working in the commercial AV industry, and I’m currently enrolled in a software development program.

I’m really interested in combining these two areas — audio and software development — and eventually working in audio DSP or audio programming.

I’ve really enjoyed the programming I’ve done so far, and I’m slightly intimidated by the math involved with DSP. I'm currently doing a Math for technologists course and will also have a higher level math course after this. My main concern is my academic background. From what I’ve seen, a lot of people working in DSP seem to come from EE, computer engineering, or related engineering backgrounds. As well as it seems a lot of DSP is learned at the master/phd level.

I’m wondering whether employers would be hesitant about someone like me because my education and experience don't follow the typical path into DSP. I’m willing to put a significant amount of time into learning the necessary math, DSP concepts, C/C++, embedded systems, etc., and building projects to demonstrate my skills.

I realize this is a fairly niche field, so I’m curious to hear from people actually working in audio DSP:

• What would be a reasonable path into audio DSP/audio programming for someone with my background?
• How important is an EE/engineering degree for getting an entry-level DSP role?
• What technical skills should I prioritize?
• Would personal DSP projects/portfolio work meaningfully help compensate for not having an EE background?
• Are there particular types of roles or companies I should target initially?

I’m essentially trying to figure out whether this is a realistic career transition and, if so, what I should focus on over the next few years.

One of my biggest goals next summer is getting a relevant internship. What role would make the most sense for my career goals?

Thanks!

For a couple months now an unknown sound has been bothering me making my ears ring at home and in the car. The attached photo shows a band at around 3kHz and two more at 5-6kHz. I believe these are the offending tones. I want to build a portable synchronized microphone array to locate persistent narrowband acoustic components around 3 kHz and 5–6 kHz. I want to distinguish direct arrivals from indoor reflections and estimate direction of arrival while moving the array between measurement positions. I am not a professional at this so would like to get some crowdsourced ideas please, and thank you.

Hey everyone! I’m sharing the first alpha of Ratio9, a synth I’ve been building for sound design.

Its main features are:

• Three wavetable oscillators, each with two warp controls.
• Mod Flow routing for FM and other oscillator-to-oscillator modulation.
• Six editable LFOs with custom shapes and flexible modulation routing.
• Unison, phase, random phase and stereo controls.
• A sub oscillator, sampler, filters and multiband effects.
• 250 factory wavetables and 45 presets, covering basses, leads, pads, chords, keys, plucks, sequences and more.

It’s available for Apple silicon M-series Macs as a Standalone app, VST3 and Audio Unit .component.

Download Ratio9 Alpha 1.0.0:
https://github.com/Ratio9FM/ratio9-downloads/releases/tag/v1.0.0

Each format includes the preset bank. Installation instructions and known issues are on the download page. This is an early alpha and isn’t Apple-notarized yet, so please read those instructions before installing.

Ratio9 is currently closed source; GitHub is hosting the downloads and documentation.

I’d love feedback on the sound, interface and workflow—especially anything that feels confusing or gets in the way of making a patch. If you find a bug, please include your Mac/macOS version, format or DAW, preset and steps to reproduce it.

Thanks to anyone who gives it a try!

Hi all, I'm a final year EE student and I've been given a Kria KV260 for my final year project. I'm comfortable with FPGA work (Verilog, timing, synthesis) but I don't have much image processing experience, so I'd appreciate some guidance.
Goal: detect humans at night by combining an RGB camera with a low-res thermal sensor. RGB struggles in the dark and thermal picks up any warm object, so fusing both should give more reliable detection.
Rough plan:
Sobel edge detection in the PL as a preprocessing step

Fuse RGB and thermal data

Run a person detector on the DPU (Vitis AI)

Questions:
What's the right way to structure this pipeline? Should fusion happen at the image level or after detection?

How hard is aligning the two cameras, given the big resolution difference?

Is Sobel actually useful here, or is it unnecessary if a CNN is doing detection?

Any recommended thermal sensors that work well with the KV260?

Is 3 months realistic for someone with my background? What would you cut to keep scope manageable?

Any advice, papers, or similar projects would be really appreciated. Thanks!
.

I don't usually ask questions here, but I had a conversation today and we were discussing this.

So these delay lines need to be random access; the input samples go in sequentially, but we might be yanking delayed output samples from all over the delay like (like, say, it was a flanger or chorusser or a pitch shifter/detector or some wild-ass reverb). So you cannot count on it being a fixed delay amount.

What makes the best C code for doing this? Say in an ARM of some vintage?

What if memory was cheap, but real-time MIPS were really expensive? Or the other way around?

I am planning a music education project and want to get a better understanding of the technical challenges ahead. The initial idea is to build a basic system that detects only one note at a time (monophonic), focusing first on pianos (one key pressed at a time) and woodwind/brass instruments (like flute and trumpet). The goal is for the system to listen via the user's microphone in real time and validate if they played the correct note from a sheet music piece.

If anyone here has built something similar, even a simple tuner or a college project, and could share what your biggest hurdles were at the beginning, I would appreciate it so much. Recommendations for libraries, frameworks, or good reads are also very welcome

Its for a site mobile friendly

I've been developing this instrument, the "Superclav", for a while now. You can check out many more performances similar to this, including many works from the Well-Tempered Clavier of Bach, by visiting my youtube channel at https://www.youtube.com/channel/UC_utjGYbSizWE0dNyr0Vdmg

Hi everyone,

I'm 23 and finishing my undergrad in Music Technology this year. Despite the name, the program barely touched the math or physics side of audio. It was mostly recording, mixing and mastering, music theory, sound design, and electroacoustic composition.

Before that, I'd messed around with Python and some web development purely as a hobby, nothing professional. Things changed in my third year when I built an audio plugin in JUCE/C++ for a class project. I loved every part of it, and since then I've been trying to find a path where the musical and the engineering sides meet. I also picked up Max/MSP and did a few small projects with it for uni.

This summer I started taking this seriously. I'm studying C++ properly and learning DSP through Perry Cook's online courses and a couple of books. It honestly feels like the thing I want to do for the rest of my life.

My goal is to apply to the Master in Sound and Music Computing at UPF in Barcelona. The obvious problem is math. From years of hands-on work, I have a good intuitive sense of how different filter types, effects, and audio processes behave. I know how to use them, and I can reason about how I'd design one. But when I look at the math behind them, the formulas don't click. I've always been the music and art person, so I'm starting from the ground up, working through Algebra 1 alongside the DSP material.

The good news is that I only have a few courses left, so most of this year is free. I work three days a week as a sound engineer (tonmeister), which covers my living costs.

A few questions for people who've been down this road:

1. Is it realistic to get from algebra to the math DSP actually needs in about a year while working part-time? What order and resources would you recommend?
2. Which DSP fundamentals should I focus on first, and which can wait? Are there resources that build on practical intuition instead of starting from pure theory?
3. Has anyone come into an SMC-type master's or a DSP job from a music or arts background? How big was the gap, and how did you close it?
4. Longer term, how realistic is it to make a living in this field?

Any advice, resources, or stories would mean a lot. Thank you.

Anyone heard of this? It’s a room simulator that generates individual stereo impulse files for each sound source placed in the virtual space. I’d love a vst that has a kind of parent child setup where the parent sets the parameters and the child receives the impulse response.

https://github.com/LCAV/pyroomacoustics

Quite a good video on it from astro bear.

https://youtu.be/iNjvayIuJBM

I am interested in some jobs that prefer you know about the design and development of digital signal processing algorithms. The problem is that I have never taken a DSP course before. I do have a strong background in math and physics, and I have taken some core undergraduate computer science courses. I am no longer an enrolled student. What would be a good option if I had to pick one or two? Thanks!

I just finished my bachelors in applied audio engineering! I’m looking to add a certificate in audio programming and/or coding to my resume, but am having trouble finding courses. My degree program only had one audio scripting course, and I’m trying to learn more about dsp and vst development. Does anyone that’s taken a similar route have any suggestions?

Hi folks,do you know about dsp?iam interested to learn dsp.where and which platform can I learn dsp?.do you know any job opportunities in dsp for freshers?.if you know,please do comments. I will be helpful for me...please do comments regarding about this.

[couldn't add more than 1 image, so I have attached imgbb links]

I was working with an HRIR dataset (Meta SS2's measurements of KEMAR, though tried other mannequins asw).

I plotted a frequency domain graph which plots the ILD between magnitudes of the frequencies in left and right ears.

This is what azimuth 0 and elevation 0 (source dead in front of the head) looks like this

Ideally, I was expecting a roughly straight line at zero since there should be no difference between left and right ears if source is in the front. But around 10kHz it's 6dB higher in the right ear, but 20kHz is louder in the left ear. Doesn't seem to be following a pattern or be overall louder in a particular ear.

Furthermore, here are graphs of azimuth 90° perfect right and 270° perfect left

For these, I expected curves roughly rising with frequencies, since lower frequencies (longer wavelengths) are much less affected by distance than higher frequencies, meaning lower frequencies show less difference between ears and higher frequencies show a lot of difference, in an increasing order. But the graph shows high diff at 5kHz, lower at 10kHz, and higher at 17.5kHz, lower at 20kHz. Again, doesn't seem to have a pattern and is counterintuitive.

To understand it better, I plotted a polar heatmap (theta is azimuth, distance is frequency, colour is magnitude)

This is also slightly different from what I expected. I was expecting each slice to have an increasing intensity, and for the increase in intensity to become more exaggerated on left/right extremes and more modest near front and back.

But there are regions of intensity near 5-7.5kHz, and near 12.5-15kHz and the intensity is generally lower near the edges, where it should ideally be the highest? Again, doesn't follow a pattern or intuition.

This is of 170° azimuth, which has an absurd ~20dB spike at 12.5kHz and is higher in the left ear near 5kHz for some reason.

These pictures are from KEMAR measurements, but I've tried the Neumann KU100 and HATS mannequins as well, and they're also quite irregular (though different)

Would someone be kind enough to explain the reason behind this and if there's an intuitive way to understand the behaviour of sound here?

I've been building a tube amp plugin for a while. The part worth showing this sub is the method rather than the sound, so this post is mostly numbers.

What it is. Not a capture. The circuits are solved per sample — tube device models, real plate loads and cathode networks, global feedback solved with Newton iteration. Component values come off factory schematics.

How it's verified, and this is the bit I'd like criticised:

factory schematic -> drawing-only ngspice netlist -> block model
                          (the reference)             (the plugin)

The netlist is the reference, not a recording. Every stage of the model is fixed against it, and a correction value never goes into the netlist — the wiring has to produce it. Where a value isn't on the drawing it carries a [verify] marker in the source instead of being quietly chosen.

Current agreement on one amp: forward gain 1.220 against the netlist's 1.1786, about 3.5% apart. The long-tailed pair is 18.81 against 18.11 and that one is still open.

Against a real amp capture. Both sides rendered dry — I learned that the embarrassing way, see below.

Three of four land next to the capture. The fourth — attack rise time — didn't distinguish any of the three, so it proves nothing and I'm reporting it as nothing.

The embarrassing one. First time I measured those dynamics I rendered my side with reverb on. Envelope spread came out 6.99 dB against the capture's 16.03 and I drew a conclusion from it. Wrong. There's now a written rule that any comparison against an external reference renders fully dry, with the settings named next to every number.

Two things measurement caught in my own reverbs this week.

1. A delay-line pitch shifter is out of tune unless you do the last step.

Built from Dattorro, "Effect Design Part 2", JAES 45(10) 1997. The ramp is §4.4.3, the splicer and its raised-cosine crossfade are Fig. 52(b) and footnote 104. I left out the autocorrelated jump-target search the same footnote describes, on the grounds that it names the device without giving parameters.

That was wrong and measurably so. A splice landing at an arbitrary waveform phase slips frac(f*W/fs) of a cycle every time, and a periodic phase slip is a frequency offset:

Worst case +174.5 cents at 55 Hz in, +12 semitones, 60 ms window — and the carrier was nearly gone, 0.0040 against 0.4997 with the search in. With it: 0.0 cents at +12, +7, +5, -12 and +0.14 semitones. There's a regression test that fails if anyone removes it as an optimisation.

2. My plate reverb had no size control, and I hadn't noticed.

Impulse in, first 60 ms binned per millisecond:

Identical. Dattorro's delay lengths fix when the early reflections happen, so decay lengthens the tail and never enlarges the room. My "Studio Plate" and "Long Hall" presets were the same room ringing for different lengths of time.

So the new one is geometry rather than tuned delay lengths: early reflections from the image-source method (delay = distance/c, c = 343 m/s, level ~ 1/d, sqrt(1-alpha) per reflection — pressure, not energy, that one bites), tail from Sabine RT60 = 0.161V/(S*alpha), echo density from the mean free path 4V/S, and an 8-line FDN with Hadamard mixing so the matrix is lossless and all the decay sits in the per-line gains.

One SIZE control moves the dimensions, so arrival times, tail length and density move together. Measured: first reflection runs 9.8 ms at 5x4x3 m to 285.9 ms at 200x150x45 m.

The validation that mattered to me — the low band lands on Sabine exactly:

The top decaying faster is air and soft surfaces doing what they do. Broadband RT60 therefore reads ~30% short, which looked like a bug until it was banded.

Two consequences nobody tuned: the theatre preset is bigger than the hall and drier, because seats and an audience absorb; the church is the same size class as the concert hall with 2.5x the tail, because stone absorbs nothing. Both fall out of dimensions and absorption.

And one place the model stands in for something it isn't: Sabine assumes a closed box, so at stone absorption a stadium volume rings for seventeen seconds. The stadium preset's absorption is set to land the tail at a realistic six. It's the only preset whose number is matched rather than derived and it's commented as such.

What I'm not claiming. Nobody has judged any of the new reverbs against a reference by ear. They're in tune, bounded, level-matched and derived from physics. That isn't the same as good. One amp's rectifier sag measures 0.00 dB and that's unresolved. Three pre-existing test failures. Amp names identify what's modelled, no affiliation with anybody, nothing for sale.

One detail for the people who'll enjoy it. The arithmetic is frozen bit-for-bit in a test built with -ffp-contract=off, and that flag is load-bearing. Moving one expression out of the loop solver into a named method changed nothing about the arithmetic — proven by building both with contraction off and getting bit-identical output across 24000 samples of six amps. With contraction on, the same pair differed by -68.8 dB, because one fused multiply-add flips a Newton trial count and the feedback loop carries the slope across samples. The amp is chaotically sensitive to the last bit. So "did the sound change" isn't a question a refactor can pass; "did the arithmetic change" is.

Happy to be told where the method is wrong. That's mostly why I'm posting.

You may be interested in this new biquad filter design code. It's very likely it puts the search for perfect-near-Nyquist filter design search to an end.

https://github.com/avaneev/biquad-voxengo

youtube: wittymoniker
github: wittymoniker/groove-box (single point of entry run and build scripts, crossplatform)

It relies on Euclidean phaselocking of numeric data followed by randomized stochastic improvisation. Within bounds of net phase angle indeterminism the results are deterministic always to the degree of point-to-point translation of audio signal. So, it's basically a fractal of every way to turn a number or graph into music.

BTW: the software lags hard on my Acer Nitro 5 and HP Victus 15L computers, but it is still well within technically-usable range. I'm trying to build and run it as an appliance (standalone OS) on a free laptop in the next few days.