spike(rust): port AudioSyncer FFT correlation to Rust to validate agent-driven dev loop

[natashaannn]

User story

As a team member evaluating the RFC 0001 rewrite, I want a low-risk, self-contained Rust spike, so that we can validate the agent-driven Rust development loop and cross-hardware output parity before committing to the full rewrite.

Background

In response to Saloni's review comment on #90 — "LGTMT, Thank you for the detailed RFC! But I would think we should do a quick spike with Rust to see if we are ok with the dev of it" — Claude suggested porting the AudioSyncer FFT cross-correlation function as the ideal candidate:

• Self-contained with well-defined I/O (two audio buffers in → offset seconds out)
• No GPU, no ML models, no subprocess dependencies — isolates the pure Rust + cargo dev loop
• We already have deterministic ground truth from scripts/sync/AudioSyncer.js to diff against
• The algorithm is tuned team-owned logic (cross-correlation, deterministic tie-break, SNR reliability check — documented in RFC 0001 §Decision table) — worth preserving exactly before any future GPU offload

This spike gates confidence in three things the RFC assumes but has not validated:

1. Coding agents can write correct, reviewable Rust (compiler-as-safety-net hypothesis)
2. The same Rust binary produces byte-identical offsets on Mac M2, Mac M3, and Windows/NVIDIA
3. Cargo toolchain + cross-compile story is workable for our team in practice

Acceptance criteria

Happy path

Given synced episode fixture files (two audio tracks from any shipped episode)
When the Rust binary is run with the same inputs as AudioSyncer.js
Then the computed offset matches the JS output to within ±1 sample (≤ 0.02 ms at 48 kHz), on Mac M2, Mac M3, and the Windows/NVIDIA machine

Given the Rust implementation compiled and run on all three target machines
When each machine processes the same fixture
Then all three produce identical offsets (bit-for-bit, since FFT is deterministic)

Error path / edge case

Given audio tracks with very low SNR (below the existing SNR reliability check threshold in AudioSyncer.js)
When the Rust binary processes them
Then it returns the same tie-break result or a clearly flagged "low confidence" output — not a silent wrong offset

Out of scope

• GPU offload for the FFT (explicitly deferred in RFC 0001 §Decision table)
• Any other pipeline stage (transcription, rendering, diarization)
• A GUI or interactive preview
• Integration into the existing Node pipeline — this is a standalone binary only
• Replacing the current scripts/sync/AudioSyncer.js — the JS version keeps running in production

Technical context

Source to port: scripts/sync/AudioSyncer.js — FFT cross-correlation, deterministic tie-break, SNR reliability check. The algorithm is documented in RFC 0001 §Decision table ("Port the algorithm from scripts/sync/AudioSyncer.js … faithfully into Rust; it is tuned, team-owned logic worth preserving exactly").

Target machines per RFC 0001 §Verification approach: Mac M2, Mac M3, Windows with NVIDIA GPU.

Fixture source: any shipped episode's synced-output files in public/sync/output/ — export two audio tracks and use them as test fixtures.

Relevant RFC section: docs/rfcs/0001-native-desktop-rewrite.md §Decision table (AudioSyncer row) and §Verification approach.

Repository location: recommend a separate throw-away repo or a top-level spike/ directory (not wired into the existing Next.js monorepo build) — aligns with RFC 0001 open question on new repo vs subdirectory.

Implementation details

1. Extract two representative audio fixture files from a shipped episode (48 kHz, mono WAV or raw PCM); commit them as test fixtures alongside the spike code.
2. Create a minimal Cargo workspace (spike/audio-sync/) with a binary crate. No workspace-level config that bleeds into the existing repo.
3. Port the FFT cross-correlation loop from AudioSyncer.js faithfully: same windowing, same tie-break logic, same SNR threshold. Use the rustfft crate (pure Rust, no native deps, deterministic across platforms).
4. Write a CLI entry point: audio-sync <ref.wav> <target.wav> → prints offset in seconds.
5. Write a unit test in the same crate that runs the fixture pair and asserts the offset matches the JS baseline (computed once and committed as a constant).
6. Run the binary and test suite on Mac M2 — record output.
7. Run on Mac M3 — confirm identical output.
8. Run on Windows/NVIDIA — confirm identical output. Document the exact cargo build + cargo test commands used on each machine.
9. Write a short retro note (≤ 1 page, can be a comment on this issue or a spike/RETRO.md) covering: what the agent-driven Rust loop felt like, what the compiler caught vs. what needed human review, and a go/no-go recommendation for proceeding with RFC 0001 Phase 1.

Additional test scenarios

• Fixture with a known positive offset (target starts later than reference) — assert sign is correct
• Fixture with a known negative offset — assert sign is correct
• Zero-offset fixture (same file as both inputs) — assert offset ≈ 0
• Low-SNR fixture (silence or near-silence) — assert the SNR reliability path triggers

Hard constraints

• Must use rustfft or another pure-Rust FFT (no C FFmpeg/FFTW binding for this spike — the point is to validate the pure Rust dev loop)
• Output offset must match AudioSyncer.js to within ±1 sample on all three machines — not "close enough"
• No changes to any file outside spike/ — this must not touch the existing pipeline
• Spike code does not need to meet Phase 4 test-coverage thresholds; it is throwaway validation, not production code
• Retro note is required before this issue can be closed — the go/no-go recommendation is the primary deliverable

Dependency issues

Depends on #90 being reviewed/approved (RFC 0001 — this spike is a direct response to the review).
Independent of all existing refactor phase branches (refactor/p0-*, refactor/p1-*, etc.).

[natashaannn]

Decomposed into sub-issues. Dependency order:

• spike(rust/fixtures): extract audio fixtures and compute JS baseline offset #94 — Extract fixtures and compute JS baseline (prerequisite for spike(rust/cli): wire CLI binary and fixture round-trip test #99)
• spike(rust/scaffold): create spike/audio-sync Cargo binary crate #95 — Scaffold Cargo crate (prerequisite for spike(rust/fft): port compute_cross_correlation to Rust #96, spike(rust/lag): port find_best_lag to Rust #97, spike(rust/snr): port validate_peak to Rust #98)
• spike(rust/fft): port compute_cross_correlation to Rust #96 — Port compute_cross_correlation (depends on spike(rust/scaffold): create spike/audio-sync Cargo binary crate #95; parallel with spike(rust/lag): port find_best_lag to Rust #97, spike(rust/snr): port validate_peak to Rust #98)
• spike(rust/lag): port find_best_lag to Rust #97 — Port find_best_lag (depends on spike(rust/scaffold): create spike/audio-sync Cargo binary crate #95; parallel with spike(rust/fft): port compute_cross_correlation to Rust #96, spike(rust/snr): port validate_peak to Rust #98)
• spike(rust/snr): port validate_peak to Rust #98 — Port validate_peak (depends on spike(rust/scaffold): create spike/audio-sync Cargo binary crate #95; parallel with spike(rust/fft): port compute_cross_correlation to Rust #96, spike(rust/lag): port find_best_lag to Rust #97)
• spike(rust/cli): wire CLI binary and fixture round-trip test #99 — Wire CLI binary + fixture round-trip test (depends on spike(rust/fixtures): extract audio fixtures and compute JS baseline offset #94, spike(rust/fft): port compute_cross_correlation to Rust #96, spike(rust/lag): port find_best_lag to Rust #97, spike(rust/snr): port validate_peak to Rust #98)
• spike(rust/verify): cross-machine verification and retro note #100 — Cross-machine verification + retro note (depends on spike(rust/cli): wire CLI binary and fixture round-trip test #99)

Each sub-issue has full context for a coding agent to work on independently.