Détection d'événements audio en dictée : des sons porteurs de sens au-delà des mots

Ce billet est délibérément plus prudent que nos autres notes d'ingénierie. Les sons porteurs de sens, ce n'est pas une fonctionnalité livrée. C'est une direction de recherche précoce : la dictée vocale par compréhension sonore peut-elle capturer des signaux non verbaux utiles tout en préservant le flow calme de la dictée ?

Le manque sur l'audio non verbal

Les systèmes de dictée vocale jettent habituellement tout ce qui n'est pas un mot. C'est raisonnable pour une transcription propre, mais ça fait perdre de l'information. Dans une réunion, un rire peut marquer un accord ou une tension. Dans un journal, une longue pause peut avoir de l'importance. Dans les workflows d'accessibilité, une sonnette, un minuteur ou un bébé qui pleure peut être un contexte utile.

Pense à ce à quoi ressemble une transcription de dictée typique après une réunion d'une heure. Les mots sont là, mais le rythme est aplati : la longue pause avant que quelqu'un ne soit en désaccord, le petit rire qui a adouci un retour difficile, le moment de silence après une question difficile. Un humain qui relit la transcription remplit ces blancs de mémoire. Un coéquipier qui n'a pas pu assister n'a aucun signal. La détection d'événements audio en dictée est une manière de remettre une petite quantité de cette texture dans le compte-rendu écrit, sans demander à l'utilisateur de la narrer.

Le risque est évident : tous les sons ne devraient pas devenir du texte. La plupart de l'audio d'arrière-plan est non pertinent. Une partie est privée. Une partie est ambiguë. La détection d'événements audio en dictée n'a de sens que si elle est optionnelle, local-first et conservatrice sur le moment où un son change la sortie écrite.

AED vs audio captioning

La détection d'événements audio (AED) répond à une question compacte : quel événement s'est produit, et à peu près quand ? L'audio captioning écrit une description en langage naturel d'une scène sonore. Pour la dictée, l'AED suffit souvent. Une étiquette comme « laughter » ou « doorbell » peut être un marqueur ; un caption complet peut être trop verbeux.

Pourquoi on penche d'abord vers l'AED

Une étiquette AED échoue discrètement. Si le modèle étiquette quelque chose comme « applause » et que ce n'en était pas, l'utilisateur voit un seul marqueur entre crochets facile à supprimer. Une mauvaise audio caption est plus difficile à défaire : elle façonne le paragraphe environnant, biaise un lecteur et persiste dans les résumés. Pour un produit de dictée où la confiance se construit une phrase à la fois, le coût d'une petite mauvaise étiquette est bien plus bas que le coût d'une phrase erronée affirmée avec assurance. Notre biais précoce va vers de petits marqueurs structurés, pas vers de la prose automatique. Un marqueur est plus facile à revisiter, supprimer ou ignorer.

Ce que cela pourrait signifier pour la dictée

Dans les réunions, l'audio non verbal pourrait créer des marqueurs optionnels : « [laughter] » après une blague, « [long pause] » avant une décision, ou « [doorbell] » quand le locuteur est interrompu. Dans le journaling, cela pourrait aider à préserver la texture émotionnelle sans forcer l'utilisateur à la narrer. Dans les workflows d'accessibilité, cela pourrait transformer un son environnemental en une courte note ou un rappel.

Un schéma concret. Imagine une note de réunion où l'utilisateur a opté pour les marqueurs de réunion. La transcription se lirait comme de la prose ordinaire avec des étiquettes compactes rares : « We agreed to ship the migration this week. [laughter] Then we walked through the rollback plan. [long pause] Someone asked whether we should defer the index changes. » Le lecteur a un sens plus riche de ce qui s'est passé sans un paragraphe de didascalies.

Un schéma de journaling est encore plus étroit. L'utilisateur dicte une note rapide de fin de journée ; une longue pause audible pourrait apparaître comme une étiquette « [reflection] » que l'utilisateur peut garder, modifier ou supprimer à la relecture. Rien n'est validé automatiquement dans le corps du journal sans une chance d'y regarder.

On n'essaie pas de rendre la dictée théâtrale. L'objectif n'est pas d'écrire chaque toux ou clic de clavier. L'objectif est de détecter un ensemble étroit d'événements à fort signal et de laisser l'utilisateur décider si ces événements deviennent du texte, des étiquettes ou rien.

Fondations de recherche

Plusieurs lignes de recherche publiques sont pertinentes. CLAP explore le pré-entraînement contrastif langage-audio. BEATs étudie le pré-entraînement audio pour la compréhension acoustique. AudioSet est un dataset à grande échelle pour les événements audio, et AudioCaps est une référence pour l'audio captioning.

Ce sont des fondations de recherche, pas une déclaration de dépendance produit. Le travail prototype de Loqua se concentre sur la question de la dictée Mac : quels indices sonores sont utiles au curseur, lesquels devraient rester invisibles, et comment l'utilisateur peut-il contrôler la frontière ?

Ce qu'on prototype

On prototype trois comportements étroits. Premièrement, les marqueurs de réunion : étiquettes optionnelles pour les rires, le silence, les applaudissements et les interruptions. Deuxièmement, les indices de journaling : étiquettes approuvées par l'utilisateur pour les longues pauses ou les soupirs audibles. Troisièmement, les alertes d'accessibilité : un indice sonore local qui peut devenir un rappel ou une note quand l'utilisateur le demande.

L'expérience utilisateur qu'on esquisse en interne est délibérément discrète. Les événements détectés apparaissent comme des chips dans une petite surface de revue à côté du texte dicté, pas dans le texte lui-même. L'utilisateur peut glisser un chip dans le document, le rejeter, ou le convertir en étiquette spécifique à la destination. Le comportement par défaut est « ne jamais insérer sans consentement ». Le mode par défaut est désactivé jusqu'à ce que l'utilisateur opte in pour un workflow donné.

Le prototype est local-first et opt-in. Rien dans cette direction ne devrait annoter silencieusement un son d'arrière-plan privé. On teste aussi un mode « marqueur uniquement » où les sons détectés n'entrent jamais automatiquement dans la prose ; ils apparaissent comme des chips revisitables avant insertion.

Les problèmes durs qu'on n'a pas résolus

Le problème le plus dur est le sens. Le rire peut signifier l'accord, l'inconfort, le sarcasme, ou rien. Un soupir peut signifier la fatigue, le soulagement, ou du bruit de micro. On ne veut pas qu'un modèle invente une interprétation émotionnelle à partir d'indices faibles. Le deuxième problème dur est la confidentialité : le son environnemental peut révéler plus que les utilisateurs ne le prévoient.

Le troisième problème dur, ce sont les espaces partagés. Même avec un opt-in strict, un microphone dans une salle de réunion entend des gens qui n'ont rien accepté. Une fonctionnalité d'audio non verbal qui capture les rires dans cette salle capture toujours des informations sur des personnes qui ne sont pas l'utilisateur. On ne pense pas que ce soit insoluble, mais ça pèse lourd sur les contraintes : le détecteur devrait tourner localement sur l'appareil de l'utilisateur, les marqueurs ne devraient jamais être partagés sans action explicite, et le défaut pour les classes ambiantes devrait pencher vers le silence plutôt que l'inférence.

Le standard actuel est donc conservateur. L'audio captioning en dictée devrait demander un contrôle utilisateur clair, des marqueurs visibles et une suppression facile. La barre pour faire passer la détection d'événements audio en dictée du prototype au livré est concrète : un flux d'opt-in qu'un utilisateur attentif décrirait comme honnête, un comportement par défaut désactivé dans tout environnement qu'on n'a pas explicitement testé, et une UX qui fait qu'une mauvaise étiquette s'écarte d'une seule touche. Tant que ces pièces ne sont pas au point, ça reste du travail à la frontière de la recherche, pas une promesse livrée centrale.