Resumen

  • RFC 2422 convirtió la disposición de los bytes en parte del contrato de audio/32KADPCM: la palabra de código anterior va en el nibble bajo y la siguiente en el alto.
  • Si hay un número impar de palabras, se prefiere completar la muestra con silencio; de lo contrario, se descarta la última. La regla fija la interpretación, no demuestra que un mensaje llegara o se escuchara.

El códec ya había resuelto el trabajo matemático. La Recomendación G.726 de la UIT-T describía la modulación por impulsos codificados diferencial adaptativa y la conversión entre PCM de ley A o ley μ a 64 kbit/s, muestreado 8.000 veces por segundo, y canales de menor velocidad, entre ellos el de 32 kbit/s. A esa velocidad, cada muestra se representa con cuatro bits. Eso explica cómo se produce una palabra de código; por sí solo no indica qué mitad de un byte de ocho bits contiene la palabra anterior.

La distinción es lo bastante pequeña para perderse dentro de la descripción de un códec y lo bastante importante para impedir el intercambio. Dos implementaciones pueden acordar la misma secuencia de valores de cuatro bits y colocar cada pareja en mitades opuestas del byte. Los octetos son datos válidos bajo ambas convenciones locales; el lector que usa la otra reconstruye una secuencia distinta. No hace falta que el archivo esté dañado ni que falle una transacción de correo. La ambigüedad está un nivel más abajo: el subtipo MIME, por sí solo, no revela qué convención local pretendía el emisor.

RFC 1911 ya había incluido Audio/32KADPCM entre los formatos de audio comunes obligatorios de su Voice Profile for Internet Mail experimental. Le asignó un lugar a la codificación dentro de un perfil de mensajería restringido, pero no decidió el orden de los cuatro bits. RFC 2422, publicado en septiembre de 1998 como estándar y descrito expresamente como una precisión de aquel registro, cerró esa brecha. Registró audio/32KADPCM para datos G.726 e incorporó una única convención de serialización al significado del subtipo.

La correspondencia es exacta. En cada octeto, la primera palabra de código, A, ocupa los bits 0 a 3: su bit menos significativo, A0, queda en el bit menos significativo del octeto. La siguiente palabra, B, ocupa los bits 4 a 7, con B3 en el extremo más significativo. Las parejas posteriores repiten esa distribución. No se invierte toda la señal de audio ni se modifica el predictor adaptativo de G.726. Se fija el orden de dos nibbles dentro de un byte.

Esa precisión también asigna trabajo. RFC 2422 señala que los códecs G.726 existentes pueden emplear órdenes distintos para las palabras de código. Como este tipo MIME solo admite el orden little-endian, un códec con la convención contraria debe reordenarlas antes de guardar los datos en este tipo o después de recuperarlos. Un nombre común no habría bastado para volver interoperables esos códecs. La norma hace visible y comprobable el punto de conversión en el límite, en vez de dejar que cada pareja de implementaciones negocie por su cuenta.

La pareja final incompleta muestra otro límite. RFC 2422 prefiere extender la muestra de voz con silencio para que el valor codificado tenga un número par de palabras. Si el número sigue siendo impar, se descarta la última palabra. No es una preferencia estética por un final silencioso: el texto le indica al analizador qué significa la mitad de byte sobrante. Sin esa regla, el contenedor acabaría en una frontera de bytes, mientras la secuencia del códec terminaría entre nibbles; cada lector tendría que inventar una convención para decidir si cuenta la media unidad final.

El subtipo no tiene parámetros obligatorios ni opcionales. Su cuerpo contiene el audio binario G.726 sin información de cabecera de audio; la codificación de transferencia MIME puede ser binaria o, generalmente, Base64. Son decisiones distintas. Base64 cambia cómo viajan los octetos por un sistema de correo, pero no cuál nibble contiene A o B una vez decodificado el cuerpo. Confundir la transferencia con el orden de las palabras equivale a confundir la envoltura de los bytes con el significado que reciben.

RFC 2422 cuenta así una historia breve pero decisiva sobre la normalización. Definir una transformación no siempre alcanza para definir un objeto interoperable. Cuando la salida cruza un límite, el orden, el relleno y la responsabilidad también pasan a formar parte del contrato. El documento no muestra cuán extendida fue la implementación de la regla, qué códec concreto estaba equivocado ni si el destinatario oyó un mensaje. Sí muestra dónde debe decidirlo explícitamente una implementación y dónde el subtipo MIME deja de permitir que la elección sea local.