Resumo

  • A RFC 2422 incorporou a disposição dos bytes ao contrato de audio/32KADPCM: a palavra de código anterior ocupa o nibble baixo e a seguinte, o alto.
  • Com uma quantidade ímpar de palavras, a RFC prefere completar a amostra com silêncio; caso contrário, descarta a última palavra. A regra elimina a ambiguidade de leitura, mas não prova que uma mensagem foi entregue ou ouvida.

O codec já havia resolvido a parte matemática. A Recomendação G.726 da ITU-T descrevia a modulação por código de pulsos diferencial adaptativa e a conversão entre PCM de lei A ou μ a 64 kbit/s, amostrado 8.000 vezes por segundo, e canais de taxas menores, inclusive 32 kbit/s. Nessa taxa, cada amostra é representada por quatro bits. Isso explica como se produz uma palavra de código, mas não determina, por si só, qual metade de um byte de oito bits contém a palavra anterior.

A distinção é pequena o bastante para se perder na descrição de um codec e grande o bastante para impedir a interoperabilidade. Duas implementações podem concordar sobre a sequência de valores de quatro bits e ainda colocar cada par em metades opostas do byte. Os octetos são válidos nas duas convenções locais; quem lê usando a outra reconstrói uma sequência diferente. Não é preciso haver um arquivo corrompido nem uma transação de e-mail malsucedida. A ambiguidade está uma camada abaixo: o subtipo MIME sozinho não revela qual convenção local o remetente pretendia.

A RFC 1911 já incluía Audio/32KADPCM entre os formatos de áudio comuns obrigatórios de seu Voice Profile for Internet Mail experimental. Ela estabeleceu um papel para a codificação num perfil restrito de mensagens, mas não resolveu a ordem dos quatro bits. Publicada em setembro de 1998 como Standards Track e identificada como refinamento daquele registro anterior, a RFC 2422 fechou a lacuna. Registrou audio/32KADPCM para dados G.726 e incorporou uma única convenção de serialização ao significado do próprio subtipo.

O mapeamento é preciso. Em cada octeto, a primeira palavra de código, A, ocupa os bits 0 a 3: seu bit menos significativo, A0, vai para o bit menos significativo do octeto. A palavra seguinte, B, ocupa os bits 4 a 7, com B3 na extremidade mais significativa. Os pares seguintes repetem essa disposição. Não se trata de inverter todo o fluxo de áudio nem de alterar o preditor adaptativo do G.726. A regra define a ordem de dois nibbles dentro de um byte.

Essa precisão também distribui o trabalho. A RFC 2422 observa que codecs G.726 existentes podem usar ordens diferentes para as palavras de código. Como esse tipo MIME aceita somente a disposição little-endian, um codec que use a ordem oposta precisa reorganizar as palavras antes de gravar dados nesse tipo ou depois de lê-los. Um nome comum não bastaria para tornar esses codecs interoperáveis. O padrão deixa o ponto de conversão visível e verificável na fronteira, em vez de exigir um acordo privado entre cada par de implementações.

O último par incompleto revela outra fronteira. A RFC prefere estender a amostra de voz com silêncio para que o valor codificado contenha um número par de palavras de código. Se a quantidade continuar ímpar, a última palavra é descartada. Não é uma preferência estética por um final silencioso: o texto informa ao analisador o que significa a metade de byte restante. Sem a regra, o contêiner terminaria numa fronteira de bytes, mas a sequência do codec acabaria entre nibbles; cada leitor teria de inventar um critério para decidir se a última metade conta.

O subtipo não tem parâmetros obrigatórios nem opcionais. Seu corpo contém áudio binário G.726 sem informações de cabeçalho de áudio; a codificação de transferência MIME pode ser binária ou, em geral, Base64. São decisões distintas. Base64 muda como os octetos atravessam um sistema de e-mail, mas não muda qual nibble contém A ou B depois que o corpo é decodificado. Confundir a codificação de transferência com a ordem das palavras é misturar o invólucro dos bytes com o significado atribuído a eles.

A RFC 2422 conta, assim, uma história curta e importante sobre padronização. Definir uma transformação nem sempre basta para definir um objeto interoperável. Quando a saída cruza uma fronteira, ordem, preenchimento e responsabilidade também passam a integrar o contrato. O documento não mostra até que ponto a regra foi implementada, qual codec estaria errado nem se um destinatário ouviu uma mensagem. Mostra, porém, onde uma implementação precisa decidir explicitamente e onde o subtipo MIME deixa de permitir que a escolha seja local.