Réparer un enregistrement vocal corrompu

Un fichier WAV est un conteneur RIFF : il commence par les octets ASCII RIFF à l'offset 0, une taille sur 32 bits en little-endian à l'offset 4 et le type de forme WAVE à l'offset 8. Viennent ensuite les fragments (chunks), chacun composé d'une étiquette de 4 octets suivie d'une taille sur 32 bits. Les deux qui comptent sont fmt  (avec l'espace final — c'est une étiquette de quatre caractères) et data. Le fragment fmt  est l'endroit où l'enregistreur note comment interpréter les échantillons : un code de format audio sur 16 bits (1 = PCM linéaire), le nombre de canaux, la fréquence d'échantillonnage en Hz, le débit d'octets, l'alignement de bloc et les bits par échantillon. Lisez-les et vous savez exactement comment décoder les octets ; perdez-les et le PCM brut n'est plus qu'une suite de nombres anonymes. Le fragment data est l'audio lui-même : son étiquette de 4 octets, une longueur sur 32 bits, puis les échantillons entrelacés.

Le piège, c'est que la taille de niveau supérieur RIFF comme la longueur du fragment data sont écrites en dernier. Pendant l'enregistrement, l'appareil ne sait pas encore combien de temps durera la prise ; il envoie donc les échantillons sur la carte et réécrit ces deux champs de taille lorsque vous appuyez sur Stop. Les enregistreurs qui sauvegardent en MP3 écrivent à la place un flux de trames audio MPEG autonomes, chacune annoncée par une synchronisation de trame de 11 bits — l'octet 0xFF suivi d'un octet dont les trois bits de poids fort sont à un (0xFFE…) —, souvent précédées d'une étiquette ID3v2. Dans tous les cas, la charge utile atteint la carte trame par trame ou échantillon par échantillon ; seule la structure qui relie le tout est terminée tout à la fin.

Comme les champs de taille sont réécrits au moment où l'on appuie sur Stop, les interruptions qui corrompent un enregistrement se concentrent toutes à l'instant où le fichier devrait se refermer :

La batterie s'est vidée en pleine capture. Les échantillons jusqu'à cet instant sont sur la carte, mais la taille RIFF de l'offset 4 et la longueur data restent à leur valeur provisoire — souvent 0, ou une valeur périmée datant de la préallocation du fichier. Le lecteur se fie au champ de longueur, lit zéro (ou un nombre aberrant) octet d'audio et signale 0:00 ou « corrompu ».

La carte a été retirée ou l'enregistreur a redémarré pendant l'écriture. Cela tronque le fichier : le fragment data déclare encore la longueur complète que l'enregistreur visait, mais le fichier sur le disque est plus court, si bien que la taille déclarée est supérieure aux octets réellement présents. Les lecteurs multimédias soit refusent le fichier, soit lisent jusqu'à la fin des données réelles puis renvoient une erreur.

Une prise en MP3 n'a jamais été finalisée. La chaîne de trames est intacte, mais une étiquette ID3 tronquée ou corrompue, ou des déchets en tête de fichier, font que le décodeur perd la première synchronisation 0xFF 0xEx — l'enregistrement est donc là, mais le lecteur ne trouve pas où il commence. Dans les fichiers à débit binaire variable, l'en-tête Xing/Info qui stocke le nombre total de trames peut manquer, si bien que la barre de progression et la durée sont fausses même quand le son finit par sortir.

Dans chacun de ces cas, les échantillons audio avaient déjà été écrits sur le support. Ce qui n'a pas survécu, c'est une poignée de champs de taille et d'octets de structure — soit précisément le cas réparable. Ce qui ne reviendra jamais, c'est l'audio postérieur à l'interruption : ces échantillons n'ont jamais été écrits.

Pour un WAV, la réparation est une reconstruction d'en-tête qui s'exécute en TypeScript pur dans votre onglet. Elle cherche d'abord l'étiquette fmt  et y lit le format directement : le code de format audio, le nombre de canaux, la fréquence d'échantillonnage et les bits par échantillon. Si ces paramètres de base sont cohérents (aucun n'est à zéro), elle recalcule les deux champs dérivés dont l'en-tête a besoin — blockAlign = canaux × (bits_par_échantillon ÷ 8) et byteRate = fréquence_échantillonnage × blockAlign — pour ne pas avoir à se fier aux valeurs peut-être corrompues du disque. Elle localise ensuite l'étiquette data et compare la longueur qu'elle déclare au nombre d'octets réellement présents. Quand la taille déclarée dépasse ce qu'il reste, elle marque le fichier comme tronqué et conserve chaque octet qui a survécu ; quand il n'y a aucun en-tête data, elle traite tout ce qui suit fmt  comme du PCM. Enfin, elle rogne les données d'échantillon à un nombre entier de trames (en écartant les octets de queue de pcm.length % blockAlign) et écrit un en-tête WAV canonique et propre de 44 octets — RIFF, taille correcte, WAVE, un fragment fmt  de 16 octets, puis data avec la longueur véritable — devant les échantillons récupérés. Comme le PCM est copié tel quel, il n'y a ni décodage ni réencodage : l'audio est bit pour bit celui que vous avez enregistré.

L'outil vous indique ce qu'il a fait au moyen d'un bref rapport : une damageClass de type header (seules les tailles étaient fausses — une réussite nette), truncated-data ou no-data-header (un résultat partiel, où la queue manquait), ainsi que la fréquence d'échantillonnage, le nombre de canaux, les bits par échantillon et le nombre d'octets de PCM récupérés, pour que vous puissiez vérifier le résultat. Un enregistrement en MP3 est pris en charge à la place par le chemin MP3 jumeau : il supprime une étiquette ID3 initiale cassée et tout déchet, se resynchronise sur la première trame authentique — n'acceptant un candidat que lorsque la longueur de trame qu'il calcule tombe exactement sur une autre synchronisation valide, ce qui écarte les faux positifs à l'intérieur de l'audio — et recopie les trames survivantes telles quelles, sans perte. Rien de tout cela ne touche au réseau : vous pouvez ouvrir l'onglet Réseau du navigateur et confirmer qu'aucun octet de l'enregistrement n'est envoyé.

Une reconstruction d'en-tête ne peut atteindre que l'audio qui est arrivé jusqu'à la carte. Si le fragment fmt  lui-même a disparu, l'outil échoue honnêtement plutôt que de deviner — sans le code de format, le nombre de canaux, la fréquence d'échantillonnage et la profondeur de bits, il n'y a aucun moyen de savoir si les octets sont du stéréo 16 bits à 48 kHz ou du mono 24 bits à 96 kHz, et inventer ces nombres produirait du bruit. Un fichier de moins de 44 octets (plus petit qu'un seul en-tête valide) ou un fichier qui, une fois rogné, ne contient plus aucune trame d'échantillon entière est signalé comme irrécupérable pour la même raison : il n'y a rien de décodable à l'intérieur.

Il ne peut pas non plus récupérer ce qu'une carte défaillante a écrasé ou renvoyé sous forme de zéros — si l'interruption a laissé la région audio à blanc, ces échantillons ne sont pas sur le disque et aucun en-tête ne les répare ; récupérez d'abord les octets bruts au niveau du stockage, puis réparez le fichier. Les enregistrements chiffrés ou protégés par DRM (certains appareils de dictée et de réunion d'entreprise enveloppent les fichiers avec une clé) ne sont ni du PCM ni de l'audio MPEG en clair : il n'y a donc pas d'en-tête à reconstruire sans la clé. Et là où il a fallu écarter une région d'un MP3, un bref silence ou un clic peut subsister à cet endroit — la réparation conserve les bonnes trames mais ne synthétise pas les millisecondes manquantes. Ce que vous récupérez de façon fiable, c'est chaque échantillon et chaque trame qui ont été écrits, dans un conteneur qu'un lecteur ouvrira.