Audio decisions.
Measured, recoverable.
A local audio workspace with inspectable estimates, worker-based measurements, WAV export and recoverable session decisions.
M1–M6 implementation is public. Synthetic browser fixtures are distinguished from original-media and physical-device acceptance.
The context
An artist needs several answers before a session: a useful tempo and key estimate, a view of the signal, a place to mark a sample, and a way to compare a mix against a reference. JonaAudio brings those tasks into a local browser workspace while keeping estimates open to correction.
The M1–M6 scope combines library/decode, waveform and spectrum views, sampling regions and candidates, scale/reference-note planning, on-demand Engineer and Compare measurements, cancellable jobs and recoverable session metadata.
My contribution
Application engineering and release consolidation through Prince Jona / Intervised in the public Universe repository. The implementation connects the browser audio pipeline, workers, measurement views, export paths and session recovery into one usable workflow.
A concrete failure, corrected
A level request failed because the worker treated computeQuality().channels, a numeric channel count, as an array and called .map(). The transfer selection now checks Array.isArray(result.channels). A focused regression covers that failure alongside stereo RMS, saturation and provenance cases.
Recovery is part of the product
Session exports store decisions and metadata, not source audio. After a reload, missing originals are visible and can be relinked. The relink check uses a bounded edge fingerprint; unchanged edges do not establish full-file identity. Browser persistence remains best-effort, so exporting session JSON provides a separate recovery path.
What was actually observed
| Check | Observed result |
|---|---|
| Regression suite | 39/39 focused Node checks at M6, including the corrected transfer path, anti-polarity stereo RMS, mono/silence/correlation, PCM16 saturation, restore validation and sanitized report provenance. |
| Browser input | Chromium imported two synthetic 44.1 kHz stereo WAVs, 5 and 6 seconds long, through the app. Progressive tempo/key results appeared. |
| Engineer & Compare | On-demand level scans ran; both references were measured and the A/B path exercised attenuation-only level matching. |
| Export & restore | A WAV was prepared in the actual export worker and downloaded. Session JSON was exported, reloaded as source-missing metadata and relinked to matching source audio. |
| Responsive layout | No horizontal overflow was observed at 320, 390, 430 and 1200 px in the recorded M6 browser run. |
These are implementation and automated browser outcomes. They do not establish subjective listening quality, musical accuracy or universal codec/device support.
Boundaries still visible
- Physical iPhone/Safari and long original MP3/M4A imports inside the app remain pending. Independent offline decoding is not browser-import evidence.
- Ground-truth BPM/key accuracy, long-duration mobile memory behavior and subjective export/listening fidelity remain unmeasured.
- True peak, integrated LUFS, stem separation and real-time pitch correction are unavailable in this scope. Tuning setup means scale and reference-note planning.
- PCM16 export can saturate out-of-range samples. The source-review and acknowledgement path remains relevant.
- A downloaded WAV does not prove successful receiving-app import or native operating-system Share support.
Inspect the public artifacts
- Open the quick tempo/key workspace →
- Open Engineer → or Compare →
- Read the M6 evidence ledger ↗
- Inspect the application source ↗
No private song files, project filenames or source recordings are included in this case. Audio rights and artist credits remain with the respective owners.
Start with the problem.
Tell me what should work and what you have to build from.