Source-linked AI summary
Beyond .WAV: Design and Software Verification of VocalCap, a Traceable Browser-Based Audio Capture System for Vocal Biomarker Research
Augusto Camargo
TL;DR
Remote voice studies often retain limited evidence about how recordings were captured, transferred, processed, and accepted. VocalCap addresses this gap with a versioned, browser-based acquisition record linking complementary artifacts and verification evidence. Under the tested browser-engine conditions, the system preserved traceability and passed software-contract checks, while acoustic, usability, clinical, and biomarker evaluations remain outside this study.
Problem
Remote voice studies may retain a final audio file without sufficient evidence of capture, transfer, processing, or acceptance, despite acquisition conditions being methodologically important.
Method
VocalCap combines self-guided browser capture with paired browser artifacts, server canonicalization, integrity and provenance evidence, durable recovery, and task-level acceptance.
Results
14 of 39 pilot files had signal confined to the left channel; topology-aware active-channel selection kept canonical RMS differences below 0.001 dB, whereas equal-weight averaging would attenuate them by approximately 6.02 dB.
Takeaways & Limitations
The tested implementation provides a software-verification baseline for a traceable acquisition record linking canonical WAV files to browser-origin artifacts and process evidence.
Takeaways & Limitations
The evidence does not establish device-level acoustic agreement, target-population usability, clinical validity, or biomarker performance.
Abstract
from arXiv · showhide
Remote voice studies often retain a final audio file with limited evidence about how it was captured, transferred, processed, and accepted. This paper presents VocalCap, an institution-controlled, browser-based system for self-guided capture of voice and related acoustic signals by participants without technical training. A versioned protocol drives the workflow. Each accepted recording retains a browser-native object, a client-lossless Float32 WAV derived from the same MediaStream, and a server-canonical mono PCM16 WAV, linked to evidence of capture execution, technical quality, byte-level integrity, recovery, and transformation provenance. IndexedDB preserves accepted browser artifacts until server confirmation, while session completion requires successful verification of every task and artifact. Software tests challenged the acquisition contracts with malformed or altered objects, exact-zero interruptions, channel-topology variants, and interrupted or repeated operations. A post hoc technical audit of 39 consented pilot recordings found 25 sample-identical stereo files and 14 files with signal confined to the left channel. Topology-aware active-channel selection limited the canonical root-mean-square level difference to less than 0.001 dB in all 14 affected files; equal-weight stereo averaging would have introduced approximately 6.02 dB of attenuation. Production end-to-end verification completed two five-task profiles in Chromium and WebKit, yielding 10 accepted recordings and 30 retained artifacts that passed server-side integrity and format checks. The results verify VocalCap's software behavior under the tested browser-engine conditions. Device-level acoustic agreement, target-population usability, clinical validity, and biomarker performance remain subjects for separate studies.
1 Introduction
VocalCap addresses the difficulty of making remote, self-guided voice acquisition technically reconstructable and verifiable. It links capture, processing, integrity, recovery, and acceptance evidence while separating software verification from downstream biomarker validation.
- Motivation: Remote self-guided acquisition can produce navigation errors, failed attempts, inconsistent settings, duplicated collections, and identity ambiguity.These problems can affect missingness, attribution, comparability, participant burden, and signal usability.
- Motivation: Prior deployment of more than 6,000 remote voice donors exposed blank recordings and device-dependent popping and crackling that were difficult to reconstruct from received audio alone.These observations motivated the present system’s validation, provenance, and recovery mechanisms.
- System objective: VocalCap links each requested task to browser capture, subsequent processing, final acceptance, observed failures, and client–server byte integrity.The system is independent of a single disease, fixed task battery, or downstream biomarker model.
- Verification strategy: The study verifies four software boundaries: browser capture, cross-boundary byte identity, canonical transformation, and session recovery and completion.Deterministic challenges, a retrospective audit of 39 consented pilot recordings, and production end-to-end execution were used.
- System objective: The acquisition record integrates complementary audio artifacts with evidence of capture, integrity, technical quality, recovery, and transformation provenance.This design makes the complete acquisition record, rather than only the received file, available for verification.
2 Background and Related Systems
The section positions VocalCap within an acquisition lifecycle that extends beyond recording to validation, persistence, transfer, canonicalization, and evidence. It distinguishes software verification from downstream clinical, analytical, and device-level evaluation while comparing VocalCap with related browser, survey, experiment, and phenotyping systems.
- A vocal biomarker is an acoustic or linguistic characteristic associated with a biological, pathological, or treatment-related process, while acquisition software operates upstream of diagnostic inference.
- Audio capture is one task attempt and its initial artifacts within a lifecycle that continues through validation, local persistence, transfer, canonicalization, and authoritative completion.
- VocalCap executes research protocols, retains audio and evidence, and produces technically characterized records without itself performing disease inference, care recommendation, or biomarker qualification.
- Software verification tests whether browser–server acquisition contracts preserve declared formats, integrity across software boundaries, and reproducible transformations, distinct from sensing-technology and analytical validation.
- Paradata, provenance models, and adjacent acquisition guidance motivate treating data flow, metadata, durability, transfer, auditability, and significant events as part of the acquisition record.
- Prior systems establish mechanisms such as browser capture, prompted tasks, WAV output, quality checks, retries, hashes, and provenance, but differ in emphasis across integration, stimulus flexibility, scale, and digital phenotyping.
3 System Design
VocalCap combines a protocol-driven participant interface with a traceable browser-to-server acquisition path. It retains complementary artifacts, validates evidence at multiple boundaries, and requires verified task and artifact completion before acceptance.
- Intended use and protocol execution: The protocol runner minimizes participant decisions while distinguishing local acceptance, pending transfer, server confirmation, and final session completion.The application is protocol-generic; the versioned protocol defines task sequence, stimuli, duration policy, and canonical sample rate.
- Traceable acquisition record: Each accepted recording links browser-origin artifacts with integrity, quality, acquisition, transfer, recovery, and transformation-provenance evidence.The record contains N, L, C, M, E, Q, and P, with the three audio files retained alongside linked non-audio components.
- Traceable acquisition record: A single MediaStream feeds complementary native and client-lossless paths, while the server derives canonical C from validated L through versioned canonicalization.N preserves the browser-emitted object; L stores Float32 samples in a strict WAV representation.
- Canonical transformation: Canonicalization selects a channel-aware mono representation: mono passes through, identical stereo selects one channel, one-active-channel stereo selects that channel, and two-active-channel stereo is averaged.The canonical output is a mono, 16-bit linear PCM WAV at the protocol-declared sample rate.
- Browser acquisition evidence: Browser acquisition evidence combines execution probes with post-capture validation of lifecycle state, artifacts, topology, continuity, finiteness, nonzero content, RMS, peak, duration, and transfer integrity.The evidence set is intended to expose divergent execution and detect malformed, empty, discontinuous, substituted, or mismatched artifacts.
- Post-capture acceptance and recovery: All 11 stable checks must pass before acceptance, and session completion requires the required task set, retained-artifact recheck, and atomic completion state.The exact-all-zero rule rejects one blank-recording class, while semantic task compliance and acoustic quality require separate assessment.
4 Software Verification Methods
VocalCap’s verification program tested frozen browser–server acquisition contracts across deterministic challenges, persistence and recovery checks, pilot-recording audit, and deployed end-to-end workflows. The design evaluated capture, artifact integrity, canonicalization, and completion under specified browser-engine conditions.
- Verification scope: The verification program covered deterministic browser, server, persistence, WAV-integrity, topology, pilot-audit, and deployed end-to-end checks.The tested implementation was version 0.3.0 at a frozen source state, with challenge-specific oracles and success criteria.
- Browser and persistence contracts: Browser tests challenged malformed, all-zero, non-finite, and prematurely terminated recordings while checking manifests, SHA-256 metadata, bounded execution, persistence, recovery, and wake-lock behavior.
- Server and transformation contracts: Server tests exercised corrupt or mismatched artifacts, invalid manifests, task binding, authorization, retries, canonical conversion, channel limits, persistence, and tamper detection.
- Boundary and topology challenges: Controlled fixtures tested 39-, 40-, and 41-ms exact-zero runs at multiple sample rates and challenged the −50 dBFS local-level boundary.Additional fixtures tested leading or trailing zero runs and channel-topology behavior.
- Boundary and topology challenges: Topology fixtures covered mono, sample-identical stereo, single-active-channel stereo, and unequal two-active-channel stereo, with topology-specific canonicalization oracles and sample-level PCM16 comparison.
- Production end-to-end procedure: Production end-to-end execution used headless Chromium and WebKit simulations with synthetic audio, five-task profiles, retained artifact checks, completion verification, and one intentionally aborted-transfer retry.These profiles represented browser-engine simulations rather than physical mobile-device tests.
5 Results
The tested VocalCap release passed its targeted software-verification checks, including negative fixtures, canonicalization boundaries, integrity checks, and repeated-operation behavior. Production execution completed both simulated browser-engine workflows with accepted recordings, retained artifacts, and verified canonical outputs.
- Software-verification results: All 134 required repository paths, six browser JavaScript suites, and 43 repository-level Python tests passed; 125 of 126 application tests passed, with one SoXR-dependent test skipped.The production environment independently confirmed FFmpeg support for libsoxr.
- Software-verification results: All negative fixtures produced expected rejections, while canonicalization, numerical boundaries, non-finite rejection, and repeated confirmation or completion behaved as specified.Repeated requests returned original results without duplicate accepted objects.
- WAV integrity and canonicalization findings: Browser-side and server-side classifications agreed for unaltered fixtures, while deliberate manifest disagreement prevented canonical creation.
- WAV integrity and canonicalization findings: For 14 single-active-channel files, topology-aware selection avoided the approximately −6.02 dB attenuation introduced by unconditional equal-weight stereo averaging.The reported sub-millidecibel residuals reflected quantization rather than systematic attenuation.
- Production workflow: Chromium and WebKit each completed all five protocol tasks, and the server marked both sessions complete while retaining five accepted recordings and 15 audio artifacts per profile.
- Production workflow: All 10 recordings were accepted with matching native and client-lossless manifest hashes and nonempty mono PCM16 canonical WAVs at 48 kHz.Canonical objects also agreed with server-generated provenance records, and capture and artifact integrity both passed.
- Production workflow: An intentionally interrupted WebKit evaluation request entered retry state and subsequently completed, testing one recovery path.Repeated trials would be required to estimate recovery reliability.
6 Discussion
Under the tested software conditions, VocalCap preserved linked artifacts, integrity evidence, transformation provenance, and session state, while topology-aware canonicalization avoided substantial level distortion. The discussion also identifies boundaries requiring controlled replay, usability studies, broader device testing, and independent deployment.
- Operational implications: The participant-to-WAV path preserved connections among canonical files, browser-origin artifacts, integrity evidence, transformation provenance, and authoritative session state.Browser retry state and authoritative server state remained distinguishable through successful completion.
- Scope and validation: The 40-ms and −50-dBFS boundaries are engineering boundaries rather than validated speech-quality thresholds.These values therefore require further empirical validation before being treated as quality standards.
- Technical findings: 14/39 pilot files contained signal only in the left channel despite declaring two channels; active-channel selection preserved RMS within 0.001 dB.Equal-weight averaging would have attenuated these files by approximately 6.02 dB.
- Technical findings: A duration-only rule would have rejected 15 candidate recordings, whereas the added local-level condition retained seven and rejected eight.The authors caution that these classifications are not clinical or perceptual defect labels.
- Scope and validation: Controlled replay on supported devices is required to quantify acoustic agreement, browser variability, warning performance, and participant burden.Human studies should measure completion, abandonment, rerecording, assistance, confidence, and completion time in representative populations.
- Scope and validation: The pilot archive was a post hoc convenience set created by project team members and cannot support generalization across participants, devices, browsers, or studies.Verification by the development team and the three-artifact design also leave independent reproducibility and storage-cost questions.
- Scope and validation: The tested Chromium and WebKit profiles used synthetic microphones and mobile presentation parameters, so they establish software-contract behavior rather than physical-device acoustics or usability.Controlled testing across the declared support envelope and head-to-head comparisons remain necessary.
7 Conclusion
VocalCap defines “Beyond .WAV” as a traceable acquisition record connecting browser capture, transfer, canonicalization, and authoritative completion. Deterministic tests, pilot-recording verification, and production end-to-end execution provide a software-verification baseline, while broader acoustic, usability, and biomarker studies remain necessary.
- Conclusion: “Beyond .WAV” denotes VocalCap’s traceable acquisition record spanning browser capture, transfer, canonicalization, and authoritative server completion.Each accepted analysis file is connected to artifacts and process evidence describing how it was acquired.
- Conclusion: Deterministic tests, 39 consented pilot recordings, and production execution of version 0.3.0 provide a software-verification baseline.Further controlled studies must quantify acoustic agreement, participant burden, recovery reliability, and the value of retained acquisition evidence.
Ethics statement
The technical audit used 39 pilot recordings created by project team members after consent through VocalCap.
- Ethics statement: The technical audit used 39 pilot recordings created by project team members after each contributor accepted VocalCap’s study consent form.The recordings supported verification of the remote voice-acquisition method used for the dysphonia study.
Declaration of generative AI use
The authors used generative AI for writing assistance and software development, with all incorporated suggestions reviewed and approved by the authors.
- Declaration of generative AI use: Generative AI assisted with paraphrasing, language refinement, and software development; the authors reviewed and approved all incorporated suggestions.The authors take responsibility for the manuscript and reported software.
Competing interests
Augusto Camargo designed and developed VocalCap and has an intellectual interest in its evaluation. No other competing interests are declared.
- Augusto Camargo designed and developed VocalCap.
- Camargo therefore has an intellectual interest in evaluating VocalCap.
- No other competing interests are declared.