Il file WAV risulta danneggiato

Un WAV canonico inizia con un prologo di 12 byte — il tag ASCII RIFF, un numero a 32 bit in little-endian che dovrebbe essere pari alla dimensione totale del file meno 8, e il tag ASCII WAVE — seguito dai blocchi. Ogni blocco è un nome di 4 byte, una dimensione di 4 byte in little-endian e poi quella quantità di byte di corpo. Il blocco fmt porta un corpo di 16 byte: un tag di formato all'offset 0 (1 = PCM, 3 = float IEEE, 0xFFFE = WAVE_FORMAT_EXTENSIBLE, 0x11 = IMA ADPCM), poi i canali (offset 2), la frequenza di campionamento (offset 4), il byte rate (offset 8), il block align (offset 12) e i bit per campione (offset 14). Il blocco data è solo il suo header di 8 byte seguito dai campioni interlacciati. Tutta la "mappa" verso ore di audio sono quelle poche decine di byte.

Quella fragilità è tutto il problema. Un registratore che riversa sul disco non conosce la durata finale finché non premi stop, quindi scrive un segnaposto nella dimensione RIFF (offset 4) e nella dimensione data — spesso 0 o 0xFFFFFFFF — e riscrive i valori reali come ultimo passaggio alla chiusura del file. Chiudi di colpo l'app, stacca la corrente, estrai la scheda o manda in crash il sistema operativo prima di quel ritocco finale, e il PCM resta scritto per intero ma le dimensioni continuano a dire che il file è vuoto. I lettori credono all'header: Windows Media Player lancia 0xC00D36C4, la libsndfile di Audacity segnala File contains data in an unknown format oppure lo rifiuta perché "non è un file WAV o AIFF", e ffmpeg stampa Invalid data found when processing input, a volte dopo aver avvisato RIFF size ... bigger than resulting file size.

Altre cause quotidiane finiscono nello stesso punto. Una copia o una sincronizzazione interrotta troppo presto tronca il corpo data in modo che la sua dimensione dichiarata superi i byte presenti. Una registrazione che ha superato circa 4 GiB fa traboccare i campi di dimensione RIFF/data a 32 bit, così i contatori vanno in overflow e la coda sembra illeggibile. Un blocco di metadati vagante scritto prima di fmt , o uno scivolone nell'ordine dei byte, può sviare un parser ingenuo dai blocchi reali. In ognuno di questi casi i campioni sono intatti — è la contabilità a mentire.

La riparazione è una ricostruzione strutturale dell'header e viene eseguita come TypeScript puro nella tua scheda. Legge l'intero file (un WAV valido necessita almeno dell'header minimo di 44 byte) e poi, invece di fidarsi della dimensione RIFF all'offset 4, cerca i byte ASCII letterali fmt in qualsiasi punto del file. Questa è la mossa chiave: una dimensione principale azzerata, segnaposto o traboccata non può fermarlo, perché non legge mai quel campo per orientarsi. Dal corpo fmt prende solo i quattro valori di cui ha davvero bisogno — il tag di formato, il numero di canali (offset 2), la frequenza di campionamento (offset 4) e i bit per campione (offset 14). Se i canali, la frequenza di campionamento o la profondità di bit sono zero, si ferma con onestà restituendo un risultato bad-fmt-params invece di produrre rumore.

Poi ricalcola da sé i due campi derivati — il block align come canali × (bit per campione ÷ 8), e il byte rate come frequenza di campionamento × block align — così un byte rate o un block align errati nell'header originale vengono semplicemente scartati e sostituiti con l'aritmetica corretta. Successivamente cerca in avanti il tag data. Se la dimensione data dichiarata è maggiore dei byte effettivamente presenti (il caso del troncamento), conserva tutto ciò che rimane e contrassegna il risultato come truncated-data; se non c'è alcun header data, tratta i byte immediatamente successivi al corpo fmt di 16 byte come PCM e lo contrassegna come no-data-header. Il PCM viene poi ritagliato a un numero intero di frame di campioni, così che un ultimo frame scritto a metà non provochi un clic.

Infine scrive un header canonico di 44 byte nuovo: RIFF con una dimensione corretta di 36 + lunghezza del PCM, WAVE, un blocco fmt pulito di 16 byte con il formato/canali/frequenza/bit recuperati e il byte rate e il block align ricalcolati, poi data con la lunghezza reale del PCM, e i tuoi campioni copiati tali e quali a partire dal byte 44. Non c'è alcun ricampionamento né alcuna ricodifica — i byte audio sono esattamente quelli che hai registrato, quindi la riparazione è senza perdita. Lo strumento riporta la frequenza di campionamento, il numero di canali, la profondità di bit e la quantità di byte PCM che ha recuperato, e una classe di danno pari a header (un successo pulito) oppure truncated-data/no-data-header (un risultato parziale). Niente di tutto questo tocca la rete — puoi aprire la scheda Rete e verificare che non venga inviato nemmeno un byte del file.

Questa riparazione raggiunge ciò che sopravvive; non può inventare un formato che non è più in grado di leggere. Dipende dalla presenza del blocco fmt : se fmt manca o è sovrascritto, lo strumento si ferma con un risultato no-fmt invece di tirare a indovinare, perché la frequenza di campionamento, il numero di canali e la profondità di bit non possono essere dedotti dal PCM grezzo — un'ipotesi sbagliata riprodurrebbe l'audio alla velocità errata o come spazzatura interlacciata. A differenza di un video privo dell'atomo moov, qui non si usa alcun file di riferimento sano, quindi se l'header di formato è sparito, il formato è sparito. Un file di meno di 44 byte restituisce too-small, e se il ritaglio a frame interi non lascia nulla, restituisce no-pcm.

Poiché emette un header canonico di 44 byte, i blocchi accessori vengono scartati: i metadati di trasmissione (bext/BWF con timecode e informazioni di origine), i punti cue (cue ), i blocchi di playlist e di etichette, i tag LIST/INFO (artista, commento), il blocco fact e l'estensione WAVE_FORMAT_EXTENSIBLE (il cbSize, i bit validi, la maschera dei canali e il GUID di sottoformato). L'audio torna; quei metadati no. La ricostruzione presuppone inoltre frame di campioni di dimensione costante, quindi un WAV compresso il cui block align non sia semplicemente canali × byte per campione — IMA/MS ADPCM, GSM 6.10 — verrà descritto in modo errato dal block align ricalcolato e potrebbe non decodificarsi; lo strumento punta a PCM e float IEEE, dove quell'aritmetica è esatta.

Altri due limiti onesti. L'output è un RIFF standard a 32 bit, quindi un PCM oltre i circa 4 GiB non può essere espresso nel campo di dimensione — quella scala richiede RF64/BW64 o Wave64 (.w64) di Sony, un contenitore diverso. E i campioni che un disco o una scheda difettosi hanno fisicamente sovrascritto con zeri o silenzio non sono sul disco per essere recuperati; recupera prima i byte grezzi a livello di archiviazione, poi ricostruisci l'header. Ciò che riottieni in modo affidabile è il PCM intatto, descritto correttamente, in un file che un lettore aprirà davvero.