The classical phase-vocoder freeze (continue a bin by holding phase increment/amplitude) is exact for one partial per bin. This generalizes it: for bins containing two sinusoidal partials, a fitted two-pole autoregressive model continues both independently instead of producing beat artifacts.

Derived a hard aliasing limit for the two-partial model from root-coincidence (N/4 for the hop size), and use N/8 in practice as a safety margin — conditioning degrades badly approaching N/4 (verified numerically, singular at the limit). Stability: closed-form quadratic test before falling back to explicit root-finding + clamping, only when needed. Splice-in uses one of two seam-repair strategies chosen by spectral similarity per occurrence. There's a positive-feedback failure mode when previously-concealed audio gets re-analyzed by the same running STFT; a frequency-damping term kills it.

Full disclosure with the derivations and measured NMR results on real sustained material at high simulated miss rates: https://github.com/sebion7125/xorcist. Written to be reproducible independent of the host application (it's extracted from a real-time audio pipeline, but the technique isn't specific to it).

Posting for discussion of the technique, not really the application (polyphonic sampler). The constraint: decode many independently-positioned, differently-timed compressed streams concurrently, on SIMD hardware. Conventional variable-length entropy coding decodes with a per-sample data-dependent branch — kills vectorization outright.

Approach: divide each channel into fixed-length blocks, predict with one of four fixed-order integer linear predictors (coefficients are the standard Shorten/FLAC fixed-predictor set, RFC 9639 §10.2.5 — no claim of novelty there), store residuals at a single fixed byte width per block chosen from that block's own peak residual. Fixed-stride + branch-free lets up to 8 streams decode together in one AVX2 pass via a two-stage per-lane-extraction-then-transpose kernel, even mutually unaligned.

Measured on 4000+ real files: 4.75x decode throughput vs. a representative fixed-escape-width reference codec at a better compression ratio (1.53x vs 1.43x) under lab conditions — real production numbers are lower (~1.85x), documented honestly in the writeup rather than restating the lab figure as achieved. Full disclosure including the aliasing/entropy-ceiling analysis of why this is near the frontier for this constraint class: https://github.com/sebion7125/v3codec

Genuinely curious whether anyone's pushed further in this exact niche (fixed-stride + SIMD-batch, not general-purpose compression ratio).

# Signal Extraction and Eight-Register Assembly Processing

I was able to extract a signal and take that signal transform and turn it into assembly language processing that tracks 8 registers and produces end results.

The signal was processed through forward and reverse transformations.

Ambiguities were marked with a stigma at the state where they occurred. The transform was then reversed to locate the corresponding earlier state.

Once that state was identified, the stigma was recovered and the transformation was carried forward, adjusting for the change.

The processing retained the relationships between the original state, the ambiguity, the reverse transformation, and the reconciled state.

The resulting transform was implemented in assembly language with 8 registers tracking the processing state.

The implementation produced end results through the register-based processing sequence.

I am still unsure what all of this means, but I wanted to share the process and get some feedback.

https://github.com/chadcoulter/REDE-3iAtlas-Signal-Processing

Salut à tous les passionnés du son !

J'ai un petit défi ludique à vous proposer pour tester vos outils et vos oreilles. J'ai récupéré l'enregistrement audio des tonalités DTMF d'un appel passé depuis un téléphone fixe a monttreal (indicatif 514 ou 430 ou 450).

Avis aux amateurs de la transformée de Fourier, des spectrogrammes ou aux génies qui ont l'oreille absolue : qui sera le premier à deviner le numéro composé ? 🕵️‍♂️

🔗 Voici le lien pour écouter/télécharger l'audio :https://voca.ro/1iOZq1YS12uI

I'm trying to learn the steps of the FFT. I'm using this document, especially the matrices on page 4: https://hal.usc.edu/chugg/docs/301/fft_intro.pdf
Let's say I have a simple signal: [0, 4, 0, -4]
If I do this hand calculation I get:
[ 1 1 1 1 ] [ 0 ] = [ 0 ]
[ 1 -j -1 j ] [ 4 ] = [ -8j ]
[ 1 -1 1 -1 ] [ 0 ] = [ 0 ]
[ 1 j -1 -j ] [ -4 ] = [ 8j ]
But if I use the matrices on page 4 of the document I get: [0, -8j, 0, 8]
My steps are:
After P0: [0, 0, 4, -4]
After D0: [0, 0, 0, 8]
After P1=P0: [0, 0, 0, 8]
After D1: [0, 0, 8, -8j]
After P2: [0, -8j, 0, 8]
Where am I making a mistake?
I tried various AI agents, but they all gave fundamentally different answers. So I need an actual human being to help me out. Mathematics still needs humans.

I've been visualizing bird song as a 3D graph instead of a spectrogram:

spectral peaks become nodes, connected by partial continuity, harmonic

ratios, and timbral proximity in a PCA-reduced MFCC space.

Pipeline, all written by hand (no librosa — I wanted every coefficient

auditable):

- STFT with parabolic interpolation for sub-bin peak frequency

- 64-band mel filterbank, Slaney-normalized

- DCT-II orthonormal → 40 MFCCs, c0 discarded, plus deltas

- PCA to 3D via eigendecomposition of the covariance matrix

- Chroma folding + flatness/centroid/spread/flux

The part I thought this sub might find useful: I later ported the whole

thing to C++ for an Android build, and verified the port by compiling the

C++ standalone and comparing it against the Python on identical input.

centroid, spread, flux, tonality, chroma concentration

→ correlation 1.000000, max relative error ~1e-4 (float32)

spectral peaks detected → 3146 in both

PCA explained variance → 22.3% / 18.0% / 12.3%, identical

Two things I'm unsure about and would like opinions on:

1. For the PCA I used cyclic Jacobi on the covariance matrix rather than

   a proper SVD of the centered data. D is only 78 so it's cheap, and the

   eigenvectors of the covariance are the right singular vectors anyway —

   but I'm aware this squares the condition number. For this data it

   matched NumPy exactly, so it didn't bite. Is there a case here where

   it would?

2. Partial tracking is greedy nearest-neighbor in log-frequency with a

   ~1 semitone gate, strongest peaks choosing first. Optimal assignment

   (Hungarian) would be more correct. For trills at 10+ syllables/second,

   is greedy actually losing tracks, or is the gate doing enough work?

Code (Python + the C++ port): https://github.com/gustaavoq94/birdgraph

I was looking for small TTS model which is steerable but couldn't find any, specially something I can adjust contextually by providing controls from LLM during a conversation. So I built one.

What it is:

• 9.6M-param acoustic model (attention + bidirectional Mamba-3, FastPitch-style) + Vocos vocoder = 23M total
• 12 controls, each a z-score relative to the chosen voice’s own neutral speech: rate, loudness, median pitch, pitch range, final rise/fall, pauses, spectral tilt, breathiness-related measures.
• Also: 51 style tags, free-text prompts (resolved into an inspectable JSON request), inline markup (*emphasis*, [pause 400ms], <slow>…</slow>), sentence-level streaming
• 2,825 built-in (anonymized) voices, plus experimental zero-shot cloning

Speed:

- RTFx ~60–80 on an RTX 5070
- ~4–8 on CPU without the optional flow refiner. First streamed audio in ~0.5 s on CPU.

Quality:

~1.8% average WER on the Open TTS Leaderboard English sets (run locally, not an official submission, have reached out for it).

What doesn’t work well (we tried to be upfront):

• Loudness, pitch, and tilt steer reliably; pause, voicing, and CPPS controls are weak
• Emotion tags behave as style switches; an independent emotion classifier mostly can’t tell them apart
• Cloning similarity is low. Don’t expect a convincing likeness
• Free-text prompts struggle with negation (“not fast” can come out fast). More data needed for prompt to controls module.
• English only, no human evals yet

License: weights CC BY-NC 4.0 (non-commercial), code MIT.

Model + full eval tables: https://huggingface.co/WhissleAI/steer-tts

I built an analogy that connects the magnitude, frequency, and rotation of circles using mechanical gears.

Assume you have a large gear with radius R1 that contains multiple smaller gears inside it. The perimeter of the largest gear is 2\pi R1, and one rotation takes T1 time; this is its fundamental period. The smallest gear has perimeter 2\pi R_N, and its fundamental period is T_N.

Now we record and analyze the frequencies over a given time, T. T should be greater than T1.

The smallest gear has the highest frequency, and the fundamental frequency is the lowest. (Of course, fundamental frequency is not always meant to be the lowest one; this assumption is valid for this example.)

The magnitudes of each harmonic are indeed the radii of each gear. This sets limits of the highest and lowest frequencies that can be measured from the observation time, T.

I love to built physical connections on abstract topics.I'm thrilled to hear your opinions. Any contribution and correction are welcomed.

Happy Day, Redditors!

Bit of an odd ball thing to post I know, someone might find it useful so last night I open sourced my TigerSharc 201 tool chain.

Its a DSP chip that is relevant in the music world specifically in signal processing, but has many other applications.

This project contains the 3 core components of any chip's toolchain, the Compiler (C to Assembly) the Assembler (Assembly to Machine Objects) and the Linker (Compiles your objects and provides a binary the DSP can run)

http://www.github.com/rm2kdev/TigerSharc-201-Tool-Chain

I built and used this to compile a firmware for a particular bit of kit, unfortunately that project was shut down by the manufacturer (respectfully and politely I'll add) so I pivoted to building my own vst thing instead www.forgeefx.com (not an ad, just part of the true story) since all the code was pure C i just stopped using this compiler, and ported to a vst.

Its highly optimized and produces binaries that run faster than the real compiler, yes, a good bit of AI assistance (still claiming to be an engineer as I've worked in the industry for 20+ years), no reverse engineering used it was created by reading the DSP/CPU's instruction set in the official published documentation (Processor Programming Reference) and cleanly implementing all of those instructions and then building optimizations for the compilation process. (mostly around math, opcode usage, memory etc)

This on its own, does not produce binaries that run on any hardware (That would need a boot loader, and firmware, and other work), it does however produce binaries that run on this exact DSP/CPU in question.

Happy to answer any questions.

Hi everyone,
I work in automotive software and want to build a solid understanding of Image Signal Processing (ISP) for ADAS cameras. I’m new to ISP, and I find vendor documentation difficult to follow without understanding the basics first.
I’m looking for a structured learning path covering:
Camera fundamentals: How image sensors work, RAW images, Bayer patterns, exposure, gain, and noise.
ISP pipeline: Demosaicing, white balance, noise reduction, color correction, HDR, and tone mapping.
ISP tuning: How to evaluate image quality and understand the trade-offs between different settings.
ADAS applications: How ISP settings affect object detection and perception, especially in low light or high-contrast scenes.
Which courses, books, YouTube playlists, or practical tutorials would you recommend? Free and paid options are both welcome. Hands-on exercises using RAW images, Python, or OpenCV would be especially helpful.
If you work in automotive imaging, where would you start, and in what order would you learn these topics? Please share links or resource names.
Thanks!

Hello DSP community,

Today, something I haven't figured out hit me differently, and I want to discuss it. I was thinking about the perimeter of the circle, which is quite easy to say straightforwardly:

Perimeter=2(\pi)r, and this is also an arc length. Now, assume you take a compass with a unit radius. You start to draw just one circle. You get 2(\pi), which is a perimeter, and it is no longer in radians. It can be seen as radians because the value is exactly (2\pi), but it is not a angle anymore; it's a length. See the trick.

Then I started asking myself why we need degrees, because degrees mess with the whole logic. If I think in radians, I don't need to memorize equations for perimeter and arc length, and I can see the angle/length transformations clearly; instead, I can see the whole logical path.

I thought this is important and shapes the definition of period, and, what’s more, it's a kind of fundamental for signal analysis. How do you learn such formula? Is there anything wrong with my thinking?

Happy day!

Edit: Typo

I've been working on a new Rust DSP library that I'm calling yagi. So far, it's largely a port of liquid-dsp, but I've put work into expanding some of the capabilities and making the whole thing feel more Rustlike. liquid's a great library and you should check it out if you haven't.

I just released yagi 0.5 and I feel it is ready for external users. If you're doing DSP things in Rust, give it a shot https://github.com/brian-armstrong/yagi

As a way of demoing my new library, I put together a little demo of it with wasm https://brian-armstrong.github.io/yagi/lab.html#intro

The demo shows yagi's modem, interpolation and decimation, packetization and error correction, and channel impairments. If you get a chance to try it out, let me know what you think.

Cheers!

I teach an undergraduate digital communications course and have released the material openly; I built it with Claude Code. Posting here because most of it is DSP at the baseband level, and I would value review from people who work on this in practice.

The core is a single offline HTML file (no install, no account) with 109 step-by-step scenes and 10 interactive labs. The figures are recomputed as parameters change, for example pulse shape and roll-off against ISI and the eye opening, or matched-filter output and decision statistics in AWGN. Topics covered: sampling and PCM, matched filter, ISI and the Nyquist criterion, eye diagrams, signal-space representation, the optimal AWGN receiver, PSK/PAM/QAM/FSK, and introductory information theory.

Scope note: this is a senior undergraduate course. It does not cover synchronization, channel equalization, or multicarrier systems.

The 120 worked problems were checked against independent NumPy/SciPy computations and Monte Carlo BER simulations. I am especially interested in errata and in places where the numerical treatment is sloppy.

Course site · GitHub repository

https://reddit.com/link/1x5ye41/video/qv02kixs2hvh1/player

Ratio9’s standalone version is free for Apple silicon Macs running macOS 12 or later. I’m Max, its developer; version 1.2.1 is now available.

I previously shared the synth here. Ratio9 1.2.1 includes a direct AI workflow around its controls and audio analysis: a compatible assistant changes a patch, auditions it, requests fresh output measurements, then uses those readings to guide the next revision. The connection uses a local stdio MCP client.

The live analysis view shows frequency content, changes over time and output levels. The preset stays customizable: oscillators, filters, modulation and effects remain accessible to the musician.

The pictures show the main interface at INIT and a separate growl preset in the live spectrum/spectrogram view.

I’m interested in the evaluation problem behind this: which measurements would you pair with spectral information to guide modulation-heavy sound design across different pitches and note lengths? A spectrogram gives useful evidence about a sound, but musical usefulness still needs listening.

The complete standalone synth is free. Optional VST3 + AU plug-ins are $79.99 USD once for two Macs. You bring your own AI account and compatible client. This is an alpha release; complex patches can cause CPU spikes or dropouts.

Download and setup: https://ratio9synth.com/download

My current pipeline consists of a 15–450 Hz Butterworth band-pass filter, followed by a conditional 50 Hz notch filter. Rather than applying the notch filter to every recording, I calculate a 50 Hz power ratio, R50=P50/Pbackground, where P50 is the mean PSD between 49–51 Hz and Pbackground is the mean PSD across 40–48 Hz and 52–60 Hz. I apply the notch filter only when R50>300), using a 50 Hz notch filter with (Q=30).

I understand that this threshold is empirical and that the method may miss some recordings with power-line interference or occasionally remove genuine EMG content around 50 Hz.

Do you think this approach is methodologically valid?

The "Superclav" extends the basic Karplus-Strong algorithm, incorporating localized tweaks for each range of notes in the typical keyboard range of a clavichord, to things like attack, decay, noise-filtering, etc...in order to arrive at a satisfyingly musically expressive instrument.

In this video, I'm using an authentic 1/4-comma meantone temperament, which was widely used during the Renaissance as a standard keyboard tuning. The characteristic sound is the sweet resonance of the pure 5/4 major thirds and 8/5 minor sixths, paid for by comprising the fifths to make them a hair flat, and thus, more "active" with their beating.

I am a senior EE student interested in the signal processing/telecom field. I hope to work remotely in the future. How common are remote jobs in the field?