Résumé

  • La RFC 2422 fait de l’agencement des octets un élément du contrat audio/32KADPCM : le mot de code antérieur occupe le demi-octet de poids faible, puis vient celui de poids fort.
  • Pour un nombre impair de mots de code, la RFC préfère compléter l’échantillon avec du silence ; à défaut, le dernier mot est éliminé. Cette règle tranche l’interprétation, pas la livraison ni l’écoute du message.

Le codec avait déjà accompli son travail mathématique. La recommandation G.726 de l’UIT-T décrivait la modulation par impulsions et codage différentiel adaptative, ainsi que la conversion d’un canal PCM à 64 kbit/s en loi A ou μ, échantillonné 8 000 fois par seconde, vers des canaux moins rapides, notamment à 32 kbit/s. À ce débit, chaque échantillon est représenté par quatre bits. Cela indique comment produire un mot de code ; cela ne dit pas, à lui seul, quelle moitié d’un octet de huit bits contient le mot le plus ancien.

La distinction est assez discrète pour disparaître dans une description de codec, mais assez importante pour empêcher l’échange. Deux implémentations peuvent convenir de la même suite de valeurs sur quatre bits et placer chaque paire dans des moitiés opposées de l’octet. Les octets sont valides dans les deux conventions locales ; le lecteur qui applique l’autre convention reconstitue une suite différente. Il n’est pas nécessaire qu’un fichier soit endommagé ni qu’une transaction de messagerie échoue. L’ambiguïté se trouve une couche plus bas : le seul sous-type MIME ne révèle pas la convention locale choisie par l’expéditeur.

La RFC 1911 avait déjà inscrit Audio/32KADPCM parmi les formats audio communs obligatoires de son profil expérimental Voice Profile for Internet Mail. Elle donnait un rôle à cet encodage dans un profil de messagerie restreint, mais ne décidait pas de l’ordre des quatre bits. Publiée en septembre 1998 sur la voie des normes et explicitement présentée comme une précision de l’enregistrement précédent, la RFC 2422 ferme cette brèche. Elle enregistre audio/32KADPCM pour les données G.726 et fait d’une convention de sérialisation le sens même du sous-type.

Le mappage ne prête pas à discussion. Dans chaque octet, le premier mot de code, A, occupe les bits 0 à 3 : son bit de poids faible, A0, se place au bit de poids faible de l’octet. Le mot suivant, B, occupe les bits 4 à 7, B3 se trouvant à l’extrémité de poids fort. Chaque paire suivante reprend le même arrangement. Il ne s’agit ni d’inverser tout le flux audio ni de modifier le prédicteur adaptatif de G.726. La règle porte sur l’ordre de deux demi-octets dans un seul octet.

Cette précision répartit aussi le travail. La RFC 2422 indique que les codecs G.726 existants peuvent ordonner les mots de code différemment. Comme ce type MIME n’autorise que l’ordre petit-boutiste, un codec qui utilise la convention inverse doit réordonner les mots avant d’enregistrer les données dans ce type ou après les avoir lues. Un nom partagé n’aurait pas suffi à rendre ces codecs interopérables. La norme rend le point de conversion visible et vérifiable, au lieu de laisser chaque paire d’implémentations s’entendre en privé.

La dernière paire incomplète révèle une autre frontière. La RFC préfère prolonger l’échantillon vocal par du silence afin d’obtenir un nombre pair de mots de code. Si le compte reste impair, le dernier mot est éliminé. Ce n’est pas une préférence esthétique pour les fins silencieuses : le texte indique à l’analyseur ce que signifie la moitié d’octet restante. Sans règle, le conteneur s’arrêterait à une frontière d’octet alors que la suite du codec se terminerait entre deux demi-octets ; les lecteurs devraient inventer une convention pour décider si le dernier demi-octet compte.

Le sous-type ne comporte aucun paramètre obligatoire ou facultatif. Son corps contient les données audio binaires G.726 sans en-tête audio ; l’encodage de transfert MIME peut être binaire ou, généralement, Base64. Ce sont deux décisions différentes. Base64 modifie la manière dont les octets circulent dans un système de messagerie ; après décodage du corps, il ne modifie pas le demi-octet contenant A ou B. Confondre l’encodage de transfert et l’ordre des mots de code revient à confondre l’enveloppe des octets avec leur signification.

La RFC 2422 raconte ainsi une histoire courte, mais déterminante, du travail de normalisation. Définir une transformation ne suffit pas toujours à définir un objet interopérable. Dès que le résultat franchit une frontière, l’ordre, le complément et la responsabilité deviennent eux aussi contractuels. Le document ne montre pas dans quelle mesure la règle a été implémentée, quel codec aurait été incorrect ou si un destinataire a entendu un message. Il montre en revanche où une implémentation doit trancher explicitement, et où le sous-type MIME cesse de laisser ce choix local.