Le format WAVE

Auteur Message
Le format WAVE est plus intéressant que certaines gens le croient. Non‑seulement il est assez simple mais aussi, on peut y ajouter des données intéressantes en plus du son. Dans l’avenir, un sujet sur le format AIFF aussi, apparaîtra sur le forum. Parce que l’AIFF est au moins autant important que le WAVE. Les deux ont une origine commune, les mêmes finalités et qualités, mais sont différents. WAVE est plus fréquent avec Windows ou les PC même sans Windows, AIFF est plus fréquent avec les Macintosh. Tous les deux ont l’avantage de préserver le son, car il ne sont pas compressés, même si ça n’est entièrement vrai qu’avec l’encodage LPCM, certains encodages PCM utilisant une échelle logarithmique au lieu de linéaire (le L de LPCM). L’échelle logarithmique est justifiée parce que c’est ainsi qu’on entend les sons, mais elle perd en précision dans les plus hautes amplitudes, ce qui peut être un problème si on décide de revoir le volume sonore d’une piste pour l’utiliser ailleurs.

Les quatre premiers messages suivants, concernant le format WAVE, avaient été initialement postés à propos du format RIFF dans ce sujet plus général : Site d’informations sur les formats numériques.
À la suite du message sur les fichiers RIFF : Re: Site d’informations sur les formats numériques.

Plus tard encore, en 1999, est arrivée une nouvelle révision, mais qui ne concerne que les fichiers WAVE. Elle n’a pas de nom de document, comme elle n’a jamais été communiquée comme un fichier autonome mais seulement en ligne. On peut s’y référer quand‑même comme à multichaud.htm ou multichaud.mspx et son propos étaient principalement l’audio multicanaux, mais introduisait une nouvelle structure pour décrire les données WAVE. Les versions actuellement consultables, par ordre temporel :


Un document qui fait une très bonne synthèse des documents définissant les fichiers WAVE : Wave File Format (wavefilegem.com). Il contient aussi des détails intéressants sur le format RIFF en général, comme le fait que les sections doivent toujours avoir un octet de padding les amenant à un nombre d’octets paire, si cet octet est nécessaire et il n’est pas compté dans le taille de la section concernée. Je crois me souvenir de ça pendant une mise en œuvre il y a longtemps, et si c’est dans le document d’origine, alors c’est très peu souligné (à vérifier plus tard). Le seul bémol de cette page est qu’elle se réfère à RIFFMCI.PDF plutôt qu’à RIFFMCI.RTF.

RIFFMCI mentionne en effet cette question du nombre d’octets paire, pour avoir un alignement sur 16 bits en mémoire :
Citation : 
If the chunk size is an odd number of bytes, a pad byte with value zero is written after ckData. Word aligning improves access speed (for chunks resident in memory) and maintains compatibility with EA IFF. The ckSize value does not include the pad byte.

Il faut bien noter la dernière phrase : “ the ckSize value does not include the pad byte ”.
Les références pour le format WAVE, mentionne l’encodage PCM, tandis que partout ailleurs, les préférences pour l’encodage, mentionne LPCM, alors qu’il n’est pas possible de trouver un standard parlant explicitement de ce LPCM.

PCM est une catégorie d’encodage simple sans compression, dont fait partie LPCM, et sans autre précision, PCM fait implicitement référence à LPCM. La page Wikipédia en Anglais pour LPCM, redirige vers la page pour PCM, qui dit bien que PCM, est par défaut LPCM : Linear pulse-code modulation (en.wikipedia.org).

Si c’est PCM tout‑court, alors c’est LPCM, et si c’est PCM autre que LPCM, alors c’est PCM avec une distinction mise en évidence, comme par exemple ADPCM (wFormatTag = 0x0002). Seul le PCM simple, c’est à dire LPCM est vraiment sans perte, les autres représente le différences d’un échantillon à l’autre, en utilisant une échelle logarithmique par exemple. La représentation DPCM tout‑court représente la différence entre les échantillon, avec une échelle linéaire, mais comme la différence peut facilement être égale à l’amplitude maximale, ça ne présenterait pas d’avantage en terme d’espace de données et explique peut‑être pourquoi il n’existe aucun format DPCM défini pour les fichiers WAVE.
Les codes que l’ont retrouve dans le champs wFormatTag des fichiers WAVE, sont répertoriés par l’IANA, qui fait autorité dans ces domaines (*) : WAVE and AVI Codec Registries (Historic Registry) (iana.org). Même si le titre mentionne que c’est historique, ça signifie seulement qu’il peut y avoir eu des ajouts ailleurs non‑répertoriés là, parce que ce qui est indiqué dans les registres de l’IANA, est là pour durer et être suivi, pour des raisons d’interopérabilité.

(*) IANA = Internet Assigned Numbers Authority.
Il est difficile de trouver des fichiers WAVE de test qui soient assez intéressants, dans le sens de techniquement variés. Il faudrait des fichiers incluant des métadonnées LIST INFO, qui portent les données de base comme le nom d’album, le nom de la composition, l’auteur, le numéro de piste, etc. Des données cue, qui sont des marqueurs de positions temporelles sur une piste audio, avec de préférence les données LIST adtl qui devraient normalement les accompagner, parce que sinon les cue points n’ont qu’un nom numérique sans titre ou étiquette textuelle correspondante. Des données DISP qui permettent par exemple d’ajouter l’image de la pochette d’un album sur le fichier *.wav d’un morceau ou toutes autres représentations textuelles ou graphiques (peut‑être même animées, à vérifier) représentant le fichier.

On peut générer soit‑même de tels fichiers en suivants les spécifications, mais il est plus difficile d’avoir assez confiance en ce qu’on a fait sans pouvoir tester en lecture, des fichiers autres que ceux qu’on a fait soi‑même. Ceci dit, comme soi‑même est toujours l’autre que quelqu’un‑e, certains examples réalisés personnellement seront postée ici en téléchargement, en espérant ne pas y avoir fait d’erreur (ça prendra un peu de temps).

En attendant, voici la seule source que je connaisse qui présente quelques exemples intéressantes : ruuda /hound / testsamples (github.com).

Ce site propose des échantillons sonores, sans vraiment penser aux tests, mais ça peut être intéressant : freewavesamples.com.

Pour d’autres sources plus généralistes, moins spécifiquement intéressantes (à moins que), voir ce message : Re: Site d’informations sur les formats numériques.

— Édit du 2026-01-01 —

Des fichiers audios présentant des particularités : A-codecs/sf/ (samples.ffmpeg.org). Il n’y a pas que des fichiers WAVE, mais il y en aussi, de même que des fichiers AIFF. Voir ce document pour une description des fichiers de ce répertoire : A-codecs/sf/README (samples.ffmpeg.org). Les répertoires parents contiennent des échantillons intéressants aussi, même si certains concernent des codecs audio dans des fichiers vidéo (c’est le site de FFmeg), mais ces répertoires ne contiennent pas de fichier README pour y décrire leur contenu ; il faut donc y aller à tâtons.

Aussi cette page, qu’il avait été oublié de mentionner en la connaissant pourtant : WAVE Sample Files (mmsp.ece.mcgill.ca). Là aussi, une description du contenu des fichiers et des éventuelles erreurs qu’ils contiennent.

Des fichiers qui sont pour des tests de qualité de restitution sonores, pour des lieux de spectacles par exemple, mais qui peuvent présenter des contenus intéressants et peut‑être des métadonnées (non‑vérifiés) : SAQAS – Spatial Audio Quality Assessment Scenes (bbc.co.uk)
On peut ajouter des tags ID3 à un fichier WAVE, de manière standard, un standard de fait, même si non‑documenté dans les spécifications RIFF : Re: Site d’informations sur les formats numériques. Ça n’invite pas à ignorer non‑plus les méta‑données d’origine pour les WAVE, puisque ça équivaudrait à les ignorer en générale et les méta‑données native du format, sont plus sûrement reconnues.
Si dans un fichier wave, apparaît une chunk "afsp", qui ne semble pas inconnue mais pas documentée pour autant, voici quelques indications.

AFsp est un ensemble de programmes utilitaires de Peter Kabal, professeur universitaire. Cette collection existe depuis au moins vingt ans ou plus. Elle est disponible ici : AFsp Package (mcgill.ca). Une recherche dans le contenu de l’archive suggère que le fichier en parlant le plus, est “ html/libtsp/AFprintInfoRecs.html ”, mais il en dit peu. Il dit au moins que les informations enregistrées dans cette section, peuvent parfois être enregistrées ailleurs, ce qui est confirmé par le fichier “ html/libtsp/AFsetInfo.html ”. Après un test, il apparaît que c’est une liste de chaînes de caractères terminées par un octet à zéro, et il peut y avoir plusieurs de ces chaînes, jusqu’à selon la place indiquée par ckSize. Chaque chaîne de caractères est de la forme “nom: valeur”. Le séparateur est bien “: ” avec un espace, pas “:” tout‑court. Le nom semble pouvoir être préfixé de “AFsp” autant que ne pas l’être. Par exemple “AFspdate” ou “loudspeakers”. Ces entrées peuvent être en doublon de celles dans LIST/INFO. Par exemple, afsp/AFspdate est un doublon de LIST/INFO/ICRD, afsp/program est un doublon de LIST/INFO/ISFT, tandis que afsp/loudspeakers n’est pas textuellement ailleurs, parce qu’il n’y rien dans LIST/INFO qui pourrait correspondre, même si ça doit normalement être en doublon de fmt/channelMask qui est un champ binaire, pas texte. Remarque : afsp n’est une form comme l’est LIST, c’est une simple chunk avec les textes mis l’un après l’autre.

Voilà, en résumé, ces champs ne sont pas tout à fait rares, comme cette collection d’utilitaires semble connue par certaines gens, et il peuvent facilement être en doublon. En tous les cas, ils ne sont pas difficiles à lire ni à interpréter.