Why Reverse Engineer WinISD Pro?
I’ve been using WinISD Pro for speaker design for years, but I constantly got frustrated with its bugs, unexpected crashes, and complete lack of updates. Written by Juha Hartikainen under Linearteam, the final version (v0.7.0.950) was released back in 2016—and then the project went silent.
Figure 1: WinISD Driver Editor Color-Mark Inspection |
Figure 2: Persistence & WDR File Serialization Probe |
Despite being an unmaintained 32-bit Windows binary with occasional stability issues, WinISD remains super popular in DIY audio because of its magical Driver Parameter Editor.
Type in a handful of specs—say, Fs, Qes, and Vas—and WinISD instantly calculates the remaining electro-mechanical parameters across 22 interconnected acoustic formulas. Entered parameters turn green (Entered E), derived parameters turn blue (Calculated C), and underdetermined or invalid combinations turn grey (Not Available N). It feels like magic, but under the hood, how does a 20-year-old closed-source Delphi app calculate interconnected state dependencies without running into infinite loops or calculation drift?
Since I work on Linux and ran it through Wine, I finally decided to have a go at reverse-engineering it: building a headless Wine test fixture to probe the binary, decode its exact constraint-propagation solver, and build OpenISD for the modern web—a free, open-source equivalent that fixes those legacy bugs while adding modern features.
Automated Reverse Engineering
The underlying acoustic equations governing speaker drivers are well known. What was far from obvious, however, was how WinISD applies them via its editor/solver screen—specifically how it handles multi-hop field interdependencies, equation priority cascades, and state propagation when parameters conflict.
Manually testing hundreds of parameter combinations by hand would have taken days of tedious effort and was completely unrealistic.
To automate discovery at scale, I developed a Python probing harness running alongside WinISD under headless Wine + Xvfb. By querying Win32 window handles directly, the harness fed controlled test values into input fields and read back calculated values and field background colors (Green/Blue/Grey) at ~50–80 Win32 field API calls per second without stealing desktop mouse or keyboard focus.
OpenISD Web Demo & Solver Re-implementation
Below is a live demonstration of OpenISD, the modern open-source web solver built from the reverse-engineered WinISD constraint rules:
Figure 3: OpenISD Modern Web Reactive Solver Demonstration
Using this approach, I was able to quickly run through a range of AI-driven test cases based on expectations of the underlying equations and initial manual experiments on how equations interact within the UI.
Scanning all possible combinations of the many inputs was unrealistic and unnecessary. By using informed sampling, I guided the AI to discover the core solver rules, narrowing down the search space for further investigation.
Acoustic Solver & Constraint Graph
Rather than operating as a simple one-way calculation pipeline, WinISD uses a reactive bi-directional fixpoint solver. Understanding how the UI resolves equations under real-world data entry requires looking at three core solver behaviors:
- Calculation Order & Topological Dependencies: When a user enters or edits a driver parameter, WinISD locks that field as a user-provided constraint and immediately executes a topological pass over its 22-equation dependency matrix. It continuously solves single-unknown equations, propagating calculated values in real time until the network reaches a stable fixpoint.
- Target Priority & Over-Constraint Handling: When multiple candidate formulas can populate the same parameter, WinISD resolves conflicts using a strict 4-Tier Priority Hierarchy:
- Tier 1 (Direct Geometry & Physical Limits): Dd, Hc, Hg, Pe, Re (Always preferred as primary anchors).
- Tier 2 (Electromechanical Drivers): Fs, Mms, Qes, Qms (Preferred over derived compliance).
- Tier 3 (Derived Acoustic Integrals): Sd, Vas, Cms, Xmax.
- Tier 4 (Secondary Metrics): Rme, γ, EBP, Qts, Vd, η₀, SPL (Lowest priority; calculated last).
Rule for Dual Calculation Options: WinISD prioritizes (1) formulas using direct component geometry over indirect acoustic integrals (e.g. populating Sd via geometric Dd over acoustic Vas & Cms), and (2) formulas requiring fewer input parameters to minimize roundoff error.
- Multi-Solution & Ambiguity Resolution: Equations involving squared or square-root terms (such as BL = √(2π · Fs · Mms · Re / Qes)) produce dual mathematical roots. WinISD resolves ambiguities by enforcing physical acoustic boundaries (rejecting negative roots, BL > 0, Cms > 0) and substituting standard atmospheric constants (ρ₀ = 1.1839 kg/m³, c = 344.7 m/s) to guarantee a unique physical solution.
The table below lists the 22 interconnected acoustic relationships mapped from WinISD’s internal solver:
| # | Acoustic Formula / Relationship |
|---|---|
| 1 | Rms = 2π · Fs · Mms / Qms |
| 2 | Qes = 2π · Fs · Mms · Re / BL² |
| 3 | Rme = BL² / Re |
| 4 | Rme = 2π · Fs · Mms / Qes |
| 5 | Qts = (Qms · Qes) / (Qms + Qes) |
| 6 | Sd = π · (Dd / 2)² |
| 7 | Mcost = f(Rme, Hc, Hg, Xmax) |
| 8 | Mpow = BL / √Re |
| 9 | Mpow = √Rme |
| 10 | Vas = ρ₀ · c² · Sd² · Cms |
| 11 | Fs = 1 / (2π · √(Mms · Cms)) |
| 12 | EBP = Fs / Qes |
| 13 | γ = BL / Mms |
| 14 | η₀ = (4π² / c³) · Fs³ · Vas / Qes |
| 15 | η₀ = (ρ₀ / 2π c) · BL² · Sd² / (Mms² · Re) |
| 16 | SPLmax = SPL + 10 · log₁₀(Pe) |
| 17 | USPL = SPL + 10 · log₁₀(8 / Re) |
| 18 | SPL = 10 · log₁₀(η₀) + 10 · log₁₀(ρ₀ · c² / 2π) + 109 |
| 19 | Xmax = |Hc - Hg| / 2 |
| 20 | Vd = Sd · Xmax |
| 21 | Gloss = f(Fs, Xmax) |
| 22 | SPLmaxLF = f(ρ₀, Vd) |