En la versión beta de Telegram para Android 13.0.3 (compilación 7179) era posible enviar un mensaje de voz como texto: el botón «Aa» junto a la pausa transcribía la grabación antes de enviarla, y el usuario elegía qué enviar al interlocutor: el texto o el audio original. La función fue señalada como disponible solo para usuarios Premium. Posteriormente, la transcripción fue eliminada de la beta, considerándola un experimento temporal de uno de los desarrolladores; sin embargo, la segunda novedad de esa misma compilación se mantuvo: la grabación experimental de mensajes de voz con supresión de ruido mediante la red neuronal RNNoise. Esto afecta a quienes instalan la beta: la versión estable 13.0.2 no incluye ninguna de las dos funciones.
Cómo se veía en la beta
El botón «Aa» aparecía en el modo de grabación bloqueada (cuando se desliza el dedo hacia arriba desde el icono del micrófono durante la grabación y esta continúa sin necesidad de mantener pulsado). Al pulsar «Aa» se mostraba la transcripción, y luego solo quedaba elegir qué enviar. Si el mensaje de voz se completaba o se recortaba, la beta ofrecía transcribirlo de nuevo.
La grabación con supresión de ruido se activa en los ajustes experimentales de la beta. El ruido se elimina del audio antes de que se comprima en Opus, el formato en el que Telegram almacena y envía los mensajes de voz. Una advertencia de la misma compilación: la supresión de ruido puede estropear la grabación de música y de voz muy baja. Cantar una melodía en un mensaje de voz con este modo es una mala idea: para la red, la música se percibe como ruido, y la razón se explica más adelante.
Por qué la transcripción antes de enviar es una mecánica nueva
La transcripción de mensajes de voz en Telegram existe desde hace tiempo, pero solo para mensajes que ya están en el chat. La realiza el servidor: el cliente llama al método messages.transcribeAudio, y este método tiene dos parámetros: el chat y el número de mensaje dentro de él. La respuesta llega con un identificador de transcripción y el texto; una grabación larga puede regresar con la etiqueta «en proceso», y entonces el texto se completa con actualizaciones separadas updateTranscribedAudio.
Una grabación no enviada no tiene número de mensaje, por lo que este método no es aplicable. No existe un método que acepte el archivo en sí, ni en el esquema API público (TDLib al 8 de octubre), ni en los archivos fuente de Android 13.0.2 con la capa 231. El reconocedor de voz del sistema Android (android.speech) tampoco se utiliza en el código de la versión 13.0.2.
No es posible ver cómo la beta sorteaba esta limitación a partir de los artefactos públicos: los archivos fuente de la compilación 13.0.3 no se han publicado, y el repositorio termina en la 13.0.2 (7175), lanzada el 13 de octubre. Las cadenas de texto del nuevo botón tampoco aparecen en la plataforma de traducciones, lo que concuerda con la versión de que fue un experimento personal que no llegó a la localización. Una hipótesis, no un hecho extraído del código: el reconocimiento se realizaba a través de un método de servidor que aún no está en el esquema público, o directamente en el dispositivo.
Quién tiene acceso a la transcripción ahora
Para los mensajes de voz recibidos, las reglas son visibles en el código del cliente. La transcripción sin restricciones está incluida en Premium; en la descripción de la suscripción, esta línea se refiere a la transcripción de cualquier mensaje de voz entrante. Sin Premium, el servidor ofrece transcripciones de prueba: el cliente lee el número de pruebas semanales y la duración máxima de la grabación de la configuración del servidor, a través de las claves transcribe_audio_trial_weekly_number y transcribe_audio_trial_duration_max. El límite de duración en las instantáneas de configuración de octubre era de 300 segundos, y el número de pruebas semanales variaba entre 0 y 2. Cuando se agotan las pruebas, el cliente muestra la fecha hasta la que hay que esperar o sugiere Premium.
Cómo funciona RNNoise
RNNoise es una biblioteca de supresión de ruido de código abierto de Xiph.Org bajo licencia BSD. Su autor es Jean-Marc Valin, uno de los creadores del códec Opus; su funcionamiento se describe en su artículo de 2017.
El enfoque es híbrido. El procesamiento de señal clásico divide el sonido en tramas de 10 ms (480 muestras a 48 kHz) y descompone el espectro de cada trama en 22 bandas, con anchos cercanos a cómo el oído humano distingue las frecuencias. Una pequeña red neuronal recurrente —que recuerda las tramas anteriores— examina las características de las bandas y para cada una emite un coeficiente de 0 a 1: cuánta energía dejar en esa banda. Un filtro de tono separado limpia el ruido entre los armónicos de la voz. Al mismo tiempo, la red emite la probabilidad de que haya voz en la trama.
La red controla 22 coeficientes, no cientos de muestras de frecuencia, por lo que es pequeña y funciona en tiempo real en el procesador del teléfono. La desventaja es que fue entrenada para separar la voz del ruido, y todo lo que no se parece a la voz lo considera ruido. De ahí la advertencia sobre la música; la voz baja se pierde por la misma razón: sus características en las bandas son similares al fondo.
RNNoise ya estaba en la aplicación
No fue necesario añadir la biblioteca. Los archivos fuente se encuentran en el repositorio del cliente Android en jni/voip/rnnoise, se compilan en una biblioteca estática y se incrustan en la biblioteca nativa principal de la aplicación. Hasta ahora, funcionaba en los videollamadas: el módulo de llamadas pasa cada trama del micrófono a través de RNNoise, toma la estimación de voz para el indicador de hablante y reemplaza el sonido por el limpio cuando la «Supresión de ruido» está activada en los ajustes de la videollamada.
El cliente graba los mensajes de voz desde el micrófono en mono a 48 kHz y los comprime con el códec Opus en modo de voz. La frecuencia de grabación coincide con la que utiliza RNNoise, por lo que el experimento de la beta se reduce a un único eslabón entre el micrófono y el códec, el mismo que ya existe en las videollamadas.
