El archivo WAV aparece dañado

Un WAV canónico empieza con un prólogo de 12 bytes — la etiqueta ASCII RIFF, un número de 32 bits en little-endian que debería ser igual al tamaño total del archivo menos 8, y la etiqueta ASCII WAVE — seguido de los fragmentos. Cada fragmento es un nombre de 4 bytes, un tamaño de 4 bytes en little-endian y luego esa cantidad de bytes de cuerpo. El fragmento fmt lleva un cuerpo de 16 bytes: una etiqueta de formato en el offset 0 (1 = PCM, 3 = coma flotante IEEE, 0xFFFE = WAVE_FORMAT_EXTENSIBLE, 0x11 = IMA ADPCM), luego los canales (offset 2), la frecuencia de muestreo (offset 4), la tasa de bytes (offset 8), la alineación de bloque (offset 12) y los bits por muestra (offset 14). El fragmento data es solo su cabecera de 8 bytes seguida de las muestras intercaladas. Todo el "mapa" hacia horas de audio son esas pocas docenas de bytes.

Esa fragilidad es el problema entero. Un grabador que vuelca al disco no conoce la duración final hasta que pulsas detener, así que escribe un marcador de posición en el tamaño RIFF (offset 4) y en el tamaño data — a menudo 0 o 0xFFFFFFFF — y reescribe los valores reales como último paso al cerrar el archivo. Cierra la aplicación de golpe, corta la corriente, extrae la tarjeta o cuelga el sistema antes de ese ajuste final, y el PCM queda escrito por completo pero los tamaños siguen diciendo que el archivo está vacío. Los reproductores creen a la cabecera: Windows Media Player lanza 0xC00D36C4, la libsndfile de Audacity informa File contains data in an unknown format o lo rechaza como que "no es un archivo WAV o AIFF", y ffmpeg imprime Invalid data found when processing input, a veces tras avisar RIFF size ... bigger than resulting file size.

Otras causas cotidianas acaban en el mismo sitio. Una copia o sincronización que se detuvo pronto trunca el cuerpo data de modo que su tamaño declarado supera los bytes presentes. Una grabación que pasó de unos 4 GiB desborda los campos de tamaño RIFF/data de 32 bits, así que los contadores dan la vuelta y la cola parece ilegible. Un fragmento de metadatos suelto escrito antes de fmt , o un desliz en el orden de bytes, puede desviar a un analizador ingenuo de los fragmentos reales. En cada uno de estos casos las muestras están intactas — lo que miente es la contabilidad.

La reparación es una reconstrucción estructural de la cabecera y se ejecuta como TypeScript puro en tu pestaña. Lee el archivo completo (un WAV válido necesita al menos la cabecera mínima de 44 bytes) y luego, en lugar de fiarse del tamaño RIFF del offset 4, busca los bytes ASCII literales fmt en cualquier punto del archivo. Ese es el movimiento clave: un tamaño maestro a cero, con marcador de posición o desbordado no puede detenerla, porque nunca lee ese campo para orientarse. Del cuerpo fmt toma solo los cuatro valores que de verdad necesita — la etiqueta de formato, el número de canales (offset 2), la frecuencia de muestreo (offset 4) y los bits por muestra (offset 14). Si los canales, la frecuencia de muestreo o la profundidad de bits son cero, se detiene con honestidad con un resultado bad-fmt-params en lugar de emitir ruido.

Después recalcula por su cuenta los dos campos derivados — la alineación de bloque como canales × (bits por muestra ÷ 8), y la tasa de bytes como frecuencia de muestreo × alineación de bloque — de modo que una tasa de bytes o una alineación de bloque incorrectas en la cabecera original simplemente se descartan y se sustituyen por la aritmética correcta. A continuación busca la etiqueta data. Si el tamaño data declarado es mayor que los bytes realmente presentes (el caso de truncamiento), conserva todo lo que queda y marca el resultado como truncated-data; si no hay cabecera data en absoluto, trata los bytes inmediatamente posteriores al cuerpo fmt de 16 bytes como PCM y lo marca como no-data-header. Luego el PCM se recorta a un número entero de tramas de muestra para que una última trama escrita a medias no provoque un chasquido.

Por último escribe una cabecera canónica de 44 bytes nueva: RIFF con un tamaño corregido de 36 + longitud del PCM, WAVE, un fragmento fmt limpio de 16 bytes con el formato/canales/frecuencia/bits recuperados y la tasa de bytes y la alineación de bloque recalculadas, luego data con la longitud real del PCM, y tus muestras copiadas tal cual a partir del byte 44. No hay remuestreo ni recodificación — los bytes de audio son exactamente los que grabaste, así que la reparación es sin pérdida. La herramienta informa de la frecuencia de muestreo, el número de canales, la profundidad de bits y la cantidad de bytes de PCM que recuperó, y una clase de daño de header (un éxito limpio) o truncated-data/no-data-header (un resultado parcial). Nada de esto toca la red — puedes abrir la pestaña Red y confirmar que no se envía ni un byte del archivo.

Esta reparación alcanza lo que sobrevive; no puede inventar un formato que ya no puede leer. Depende de que el fragmento fmt esté presente: si fmt falta o está sobrescrito, la herramienta se detiene con un resultado no-fmt en lugar de adivinar, porque la frecuencia de muestreo, el número de canales y la profundidad de bits no pueden deducirse del PCM en bruto — una conjetura errónea reproduciría el audio a la velocidad equivocada o como basura intercalada. A diferencia de un vídeo sin átomo moov, aquí no se usa ningún archivo de referencia sano, así que si la cabecera de formato desapareció, el formato desapareció. Un archivo de menos de 44 bytes devuelve too-small, y si al recortar a tramas enteras no queda nada, devuelve no-pcm.

Como emite una cabecera canónica de 44 bytes, los fragmentos auxiliares se descartan: los metadatos de radiodifusión (bext/BWF con código de tiempo e información de origen), los puntos de referencia (cue ), los fragmentos de lista de reproducción y de etiquetas, las etiquetas LIST/INFO (artista, comentario), el fragmento fact y la extensión de WAVE_FORMAT_EXTENSIBLE (el cbSize, los bits válidos, la máscara de canales y el GUID de subformato). El audio vuelve; esos metadatos no. La reconstrucción también supone tramas de muestra de tamaño constante, así que un WAV comprimido cuya alineación de bloque no sea simplemente canales × bytes por muestra — IMA/MS ADPCM, GSM 6.10 — quedará mal descrito por la alineación de bloque recalculada y puede no descodificarse; la herramienta apunta a PCM y coma flotante IEEE, donde esa aritmética es exacta.

Dos límites honestos más. La salida es un RIFF estándar de 32 bits, así que un PCM de más de unos 4 GiB no cabe en el campo de tamaño — esa escala necesita RF64/BW64 o Wave64 (.w64) de Sony, un contenedor distinto. Y las muestras que un disco o una tarjeta defectuosos sobrescribieron con ceros o silencio no están en el disco para recuperarse; recupera primero los bytes en bruto a nivel de almacenamiento y luego reconstruye la cabecera. Lo que recuperas de forma fiable es el PCM intacto, descrito correctamente, en un archivo que un reproductor abrirá de verdad.