Ripara una registrazione vocale corrotta

Un file WAV è un contenitore RIFF: inizia con i byte ASCII RIFF all'offset 0, una dimensione a 32 bit little-endian all'offset 4 e il tipo di form WAVE all'offset 8. Dopo vengono i chunk, ciascuno un tag da 4 byte più una dimensione a 32 bit. I due che contano sono fmt  (nota lo spazio finale — è un tag di quattro caratteri) e data. Il chunk fmt  è dove il registratore annota come interpretare i campioni: un codice di formato audio a 16 bit (1 = PCM lineare), il numero di canali, la frequenza di campionamento in Hz, il byte rate, il block align e i bit per campione. Leggili e sai esattamente come decodificare i byte; perdili e il PCM grezzo non è che una serie di numeri anonimi. Il chunk data è l'audio vero e proprio: il suo tag da 4 byte, una lunghezza a 32 bit e poi i campioni interlacciati.

La trappola sta nel fatto che sia la dimensione RIFF di livello superiore sia la lunghezza del chunk data vengono scritte per ultime. Mentre registra, l'apparecchio non sa ancora quanto durerà la ripresa, così invia i campioni alla scheda e riscrive a posteriori quei due campi di dimensione quando premi Stop. I registratori che salvano in MP3 scrivono invece un flusso di frame audio MPEG autonomi, ognuno annunciato da una sincronizzazione di frame a 11 bit — il byte 0xFF seguito da un byte i cui tre bit superiori sono a uno (0xFFE…) — spesso preceduti da un tag ID3v2. In ogni caso, il payload arriva sulla scheda frame dopo frame o campione dopo campione; solo la struttura che li tiene insieme viene completata alla fine di tutto.

Poiché i campi di dimensione vengono riscritti allo Stop, le interruzioni che corrompono una registrazione si concentrano tutte nel momento in cui il file dovrebbe chiudersi:

La batteria si è scaricata a metà registrazione. I campioni fino a quell'istante sono sulla scheda, ma la dimensione RIFF all'offset 4 e la lunghezza data restano al loro valore provvisorio — spesso 0, o un valore obsoleto di quando il file era stato pre-allocato. Il lettore si fida del campo di lunghezza, legge zero (o un numero del tutto sbagliato) byte di audio e segnala 0:00 o "danneggiato".

La scheda è stata rimossa o il registratore si è resettato durante la scrittura. Questo tronca il file: il chunk data dichiara ancora la lunghezza completa che il registratore intendeva, ma il file su disco è più corto, quindi la dimensione dichiarata è maggiore dei byte realmente presenti. I lettori multimediali o rifiutano il file oppure riproducono fino alla fine dei dati reali e poi vanno in errore.

Una ripresa in MP3 non è mai stata finalizzata. La catena di frame è intatta, ma un tag ID3 troncato o corrotto, o dei dati spuri all'inizio, fa perdere al decodificatore la prima sincronizzazione 0xFF 0xEx — così la registrazione è lì ma il lettore non trova dove inizia. Nei file a bitrate variabile, l'header Xing/Info che memorizza il conteggio totale dei frame può mancare, per cui la barra di avanzamento e la durata risultano sbagliate anche una volta che il file suona.

In ognuno di questi casi i campioni audio erano già stati salvati nella memoria. Ciò che non è sopravvissuto è una manciata di campi di dimensione e byte di struttura — che è esattamente il caso riparabile. Ciò che non può mai tornare è l'audio successivo all'interruzione: quei campioni non sono mai stati scritti.

Per un WAV, la riparazione è una ricostruzione dell'header che gira come TypeScript puro nella tua scheda. Prima cerca il tag fmt  e legge il formato direttamente da lì: il codice di formato audio, il numero di canali, la frequenza di campionamento e i bit per campione. Se questi parametri di base sono sensati (nessuno è zero), ricalcola i due campi derivati di cui l'header ha bisogno — blockAlign = canali × (bit_per_campione ÷ 8) e byteRate = frequenza_campionamento × blockAlign — così da non doversi fidare dei valori forse corrotti presenti sul disco. Poi individua il tag data e confronta la lunghezza che dichiara con quanti byte sono realmente presenti. Quando la dimensione dichiarata è maggiore di ciò che resta, contrassegna il file come troncato e conserva ogni byte sopravvissuto; quando non c'è alcun header data, tratta tutto ciò che segue fmt  come PCM. Infine ritaglia i dati dei campioni a un numero intero di frame (scartando gli eventuali byte di coda di pcm.length % blockAlign) e scrive un header WAV canonico e pulito di 44 byte — RIFF, dimensione corretta, WAVE, un chunk fmt  di 16 byte e poi data con la lunghezza reale — davanti ai campioni recuperati. Poiché il PCM viene copiato tale e quale, non c'è alcuna decodifica né ricodifica: l'audio è bit per bit quello che hai registrato.

Lo strumento ti dice cosa ha fatto tramite un breve rapporto: una damageClass di header (solo le dimensioni erano sbagliate — un successo pulito), truncated-data o no-data-header (un risultato parziale, in cui mancava la coda), e la frequenza di campionamento, il numero di canali, i bit per campione e il conteggio dei byte di PCM recuperati, così puoi verificare il risultato. Una registrazione in MP3 viene invece gestita dal percorso MP3 gemello: elimina un tag ID3 iniziale rotto e qualsiasi dato spurio, si risincronizza sul primo frame autentico — accettando un candidato solo quando la lunghezza di frame che calcola cade esattamente su un'altra sincronizzazione valida, il che scarta i falsi positivi dentro l'audio — e copia i frame sopravvissuti tali e quali, senza perdita. Nulla di tutto ciò tocca la rete: puoi aprire la scheda Network (Rete) del browser e confermare che non viene inviato nemmeno un byte della registrazione.

Una ricostruzione dell'header può raggiungere solo l'audio che è arrivato sulla scheda. Se il chunk fmt  stesso è sparito, lo strumento fallisce onestamente invece di indovinare — senza il codice di formato, il numero di canali, la frequenza di campionamento e la profondità di bit non c'è modo di sapere se i byte sono stereo a 16 bit a 48 kHz o mono a 24 bit a 96 kHz, e inventare quei numeri produrrebbe rumore. Un file di meno di 44 byte (più piccolo di un singolo header valido) o uno che, una volta ritagliato, resta con zero frame di campioni interi viene segnalato come irrecuperabile per lo stesso motivo: dentro non c'è nulla di decodificabile.

Non può nemmeno recuperare ciò che una scheda difettosa ha sovrascritto o restituito come zeri — se l'interruzione ha lasciato vuota la regione audio, quei campioni non sono sul disco e nessun header li sistema; recupera prima i byte grezzi a livello di memoria e poi ripara il file. Le registrazioni cifrate o protette da DRM (alcuni apparecchi per dettatura e riunioni aziendali avvolgono i file con una chiave) non sono PCM né audio MPEG in chiaro, quindi non c'è alcun header da ricostruire senza la chiave. E dove una regione di un MP3 ha dovuto essere scartata, può restare un breve vuoto o un clic in quel punto — la riparazione conserva i frame buoni ma non sintetizza i millisecondi mancanti. Ciò che riottieni in modo affidabile è ogni campione e ogni frame che era stato scritto, in un contenitore che un lettore aprirà.