Le fichier WAV est signalé comme endommagé

Un WAV canonique commence par un prologue de 12 octets — l'étiquette ASCII RIFF, un nombre de 32 bits en little-endian censé être égal à la taille totale du fichier moins 8, et l'étiquette ASCII WAVE — suivi des fragments. Chaque fragment est un nom de 4 octets, une taille de 4 octets en little-endian, puis ce nombre d'octets de corps. Le fragment fmt porte un corps de 16 octets : une étiquette de format à l'offset 0 (1 = PCM, 3 = virgule flottante IEEE, 0xFFFE = WAVE_FORMAT_EXTENSIBLE, 0x11 = IMA ADPCM), puis les canaux (offset 2), la fréquence d'échantillonnage (offset 4), le débit d'octets (offset 8), l'alignement de bloc (offset 12) et les bits par échantillon (offset 14). Le fragment data n'est que son en-tête de 8 octets suivi des échantillons entrelacés. Toute la « carte » menant à des heures d'audio tient dans ces quelques dizaines d'octets.

Cette fragilité est tout le problème. Un enregistreur qui écrit sur le disque au fil de l'eau ne connaît pas la durée finale tant que vous n'avez pas appuyé sur stop, il écrit donc un marqueur de réservation dans la taille RIFF (offset 4) et dans la taille data — souvent 0 ou 0xFFFFFFFF — et réécrit les vraies valeurs en dernière étape, à la fermeture du fichier. Fermez l'application brutalement, coupez le courant, retirez la carte ou plantez le système avant cette correction finale, et le PCM est entièrement écrit mais les tailles disent toujours que le fichier est vide. Les lecteurs croient l'en-tête : Windows Media Player renvoie 0xC00D36C4, la libsndfile d'Audacity signale File contains data in an unknown format (« le fichier contient des données dans un format inconnu ») ou le rejette comme « pas un fichier WAV ou AIFF », et ffmpeg affiche Invalid data found when processing input (« données invalides trouvées lors du traitement de l'entrée »), parfois après avoir averti RIFF size ... bigger than resulting file size (« taille RIFF ... supérieure à la taille réelle du fichier »).

D'autres causes du quotidien aboutissent au même endroit. Une copie ou une synchronisation qui s'est arrêtée trop tôt tronque le corps data, de sorte que sa taille déclarée dépasse les octets présents. Un enregistrement qui a dépassé environ 4 Gio déborde les champs de taille RIFF/data sur 32 bits, si bien que les compteurs bouclent et que la fin paraît illisible. Un fragment de métadonnées égaré écrit avant fmt , ou un décalage dans l'ordre des octets, peut détourner un analyseur naïf des vrais fragments. Dans chacun de ces cas, les échantillons sont intacts — c'est la comptabilité qui ment.

La réparation est une reconstruction structurelle de l'en-tête et s'exécute comme du TypeScript pur dans votre onglet. Elle lit le fichier entier (un WAV valide a besoin d'au moins l'en-tête minimal de 44 octets), puis, au lieu de se fier à la taille RIFF de l'offset 4, elle recherche les octets ASCII littéraux fmt n'importe où dans le fichier. C'est le geste clé : une taille maîtresse à zéro, en marqueur de réservation ou débordée ne peut pas l'arrêter, car elle ne lit jamais ce champ pour se repérer. Du corps fmt , elle ne prend que les quatre valeurs dont elle a vraiment besoin — l'étiquette de format, le nombre de canaux (offset 2), la fréquence d'échantillonnage (offset 4) et les bits par échantillon (offset 14). Si les canaux, la fréquence d'échantillonnage ou la profondeur de bits valent zéro, elle s'arrête honnêtement avec un résultat bad-fmt-params au lieu d'émettre du bruit.

Elle recalcule ensuite elle-même les deux champs dérivés — l'alignement de bloc comme canaux × (bits par échantillon ÷ 8), et le débit d'octets comme fréquence d'échantillonnage × alignement de bloc — de sorte qu'un débit d'octets ou un alignement de bloc erronés dans l'en-tête d'origine sont tout simplement écartés et remplacés par l'arithmétique correcte. Elle recherche ensuite l'étiquette data. Si la taille data déclarée est supérieure aux octets réellement présents (le cas de la troncature), elle conserve tout ce qui reste et marque le résultat truncated-data ; s'il n'y a pas d'en-tête data du tout, elle traite les octets situés juste après le corps fmt de 16 octets comme du PCM et le marque no-data-header. Le PCM est alors rogné à un nombre entier de trames d'échantillon pour qu'une dernière trame écrite à moitié ne provoque pas de claquement.

Enfin, elle écrit un nouvel en-tête canonique de 44 octets : RIFF avec une taille corrigée de 36 + longueur du PCM, WAVE, un fragment fmt propre de 16 octets avec le format/canaux/fréquence/bits récupérés ainsi que le débit d'octets et l'alignement de bloc recalculés, puis data avec la vraie longueur du PCM, et vos échantillons copiés tels quels à partir de l'octet 44. Il n'y a ni rééchantillonnage ni réencodage — les octets audio sont exactement ceux que vous avez enregistrés, la réparation est donc sans perte. L'outil indique la fréquence d'échantillonnage, le nombre de canaux, la profondeur de bits et le nombre d'octets de PCM qu'il a récupérés, ainsi qu'une classe de dommage header (une réussite propre) ou truncated-data/no-data-header (un résultat partiel). Rien de tout cela ne touche le réseau — vous pouvez ouvrir l'onglet Réseau et confirmer que pas un octet du fichier n'est envoyé.

Cette réparation atteint ce qui survit ; elle ne peut pas inventer un format qu'elle ne peut plus lire. Elle dépend de la présence du fragment fmt : si fmt est absent ou écrasé, l'outil s'arrête avec un résultat no-fmt plutôt que de deviner, car la fréquence d'échantillonnage, le nombre de canaux et la profondeur de bits ne peuvent pas être déduits du PCM brut — une mauvaise supposition lirait l'audio à la mauvaise vitesse ou comme du bruit entrelacé. Contrairement à une vidéo sans atome moov, aucun fichier de référence sain n'est utilisé ici, donc si l'en-tête de format a disparu, le format a disparu. Un fichier de moins de 44 octets renvoie too-small, et si le rognage aux trames entières ne laisse rien, il renvoie no-pcm.

Comme elle émet un en-tête canonique de 44 octets, les fragments auxiliaires sont abandonnés : les métadonnées de radiodiffusion (bext/BWF avec code temporel et informations d'origine), les points de repère (cue ), les fragments de liste de lecture et d'étiquettes, les balises LIST/INFO (artiste, commentaire), le fragment fact et l'extension de WAVE_FORMAT_EXTENSIBLE (le cbSize, les bits valides, le masque de canaux et le GUID de sous-format). L'audio revient ; ces métadonnées non. La reconstruction suppose aussi des trames d'échantillon de taille constante, si bien qu'un WAV compressé dont l'alignement de bloc n'est pas simplement canaux × octets par échantillon — IMA/MS ADPCM, GSM 6.10 — sera mal décrit par l'alignement de bloc recalculé et risque de ne pas se décoder ; l'outil vise le PCM et la virgule flottante IEEE, où cette arithmétique est exacte.

Deux limites honnêtes de plus. La sortie est un RIFF standard sur 32 bits, donc un PCM de plus d'environ 4 Gio ne peut pas être exprimé dans le champ de taille — cette échelle nécessite RF64/BW64 ou Wave64 (.w64) de Sony, un conteneur différent. Et les échantillons qu'un disque ou une carte défaillants ont écrasés avec des zéros ou du silence ne sont plus sur le disque pour être récupérés ; récupérez d'abord les octets bruts au niveau du stockage, puis reconstruisez l'en-tête. Ce que vous récupérez de façon fiable, c'est le PCM intact, correctement décrit, dans un fichier qu'un lecteur ouvrira vraiment.