Diarisation des locuteurs — SpeakerDiarizationBlock¶

SpeakerDiarizationBlock est un Media Block audio uniquement qui réside dans l'espace de noms VisioForge.Core.MediaBlocks.AI (assembly VisioForge.Core.AI, package NuGet VisioForge.DotNet.Core.AI). Il répond à « qui a parlé et quand » : il intercepte le flux audio, détecte les tours de parole avec un modèle ONNX de segmentation pyannote, transforme chaque tour en empreinte vocale avec un modèle ONNX d'embeddings WeSpeaker/3D-Speaker et — une fois l'enregistrement terminé — regroupe les empreintes vocales en locuteurs et publie la chronologie. L'audio traverse le bloc : l'interception force un format d'échantillon en virgule flottante 32 bits entrelacé, mais la fréquence d'échantillonnage et le nombre de canaux restent inchangés. Le bloc implémente IAudioProcessingBlock, il peut donc être inséré dans un pipeline manuel ou enregistré directement sur VideoCaptureCoreX/MediaPlayerCoreX.

L'implémentation suit le pipeline de diarisation des locuteurs hors ligne de référence sherpa-onnx, qui utilise ces deux mêmes modèles.

using VisioForge.Core.MediaBlocks.AI;
using VisioForge.Core.Types.X.AI;

La diarisation est hors ligne — la réponse arrive en fin de flux¶

Le bloc ne rapporte rien tant que l'audio est encore en cours de lecture. Ce n'est pas une limitation de l'implémentation, c'est ce que le problème autorise :

• Le modèle de segmentation sépare les voix à l'intérieur d'une seule fenêtre de 10 secondes et les numérote localement. Le « locuteur 1 » de la fenêtre 5 et le « locuteur 1 » de la fenêtre 6 n'ont aucun rapport — le modèle ne prétend jamais le contraire.
• La seule chose qui puisse relier une voix entendue à la minute 1 à la même voix à la minute 40, c'est de regrouper ensemble toutes les empreintes vocales de l'enregistrement, et cela ne peut pas être fait tant que toutes les empreintes vocales n'existent pas.

Le bloc analyse donc en continu à mesure que l'audio s'écoule (ce travail est réel, et c'est pourquoi la réponse apparaît presque immédiatement après le dernier échantillon), mais il ne déclenche OnSpeakerSegment — une fois par tour, dans l'ordre des temps de début — qu'après la fin de flux. Il convient aux fichiers et aux flux finis. Une source en direct sans fin n'atteint jamais le moment où une réponse existe.

Configuration de base du bloc¶

var settings = new SpeakerDiarizationSettings(segmentationModelPath, embeddingModelPath)
{
    Provider = OnnxExecutionProvider.CPU,
};

var diarization = new SpeakerDiarizationBlock(settings);

// Déclenché pour chaque tour, dans l'ordre, après la fin du flux.
diarization.OnSpeakerSegment += (sender, e) =>
{
    var turn = e.Segment;
    Console.WriteLine($"speaker_{turn.SpeakerId:D2}: {turn.Start:c} - {turn.End:c} (conf {turn.Confidence:F2})");
};

La même chronologie est disponible d'un seul tenant via GetTimeline(). Vérifiez d'abord IsTimelineComplete — une chronologie vide signifie « nous n'avons jamais pu déterminer qui a parlé », et non « personne n'a parlé » :

if (!diarization.IsTimelineComplete)
{
    // L'exécution n'a jamais atteint l'étape de regroupement : le pipeline a été arrêté avant la fin de flux,
    // ou le worker d'analyse a échoué. La chronologie est vide, et ce vide n'est pas une réponse.
    Console.WriteLine("Aucun résultat de diarisation — l'enregistrement n'a pas été entendu jusqu'au bout.");
    return;
}

Console.WriteLine($"{diarization.SpeakerCount} locuteur(s).");

if (diarization.UnattributedTurns > 0)
{
    // De la parole que les modèles ont trouvée mais n'ont pas pu transformer en empreinte vocale : ces tours
    // ne portent aucun identifiant de locuteur et n'atteignent jamais la chronologie, bien que leur audio AIT été analysé.
    Console.WriteLine($"{diarization.UnattributedTurns} tour(s) n'ont pas pu être attribués à un locuteur.");
}

foreach (var turn in diarization.GetTimeline())
{
    Console.WriteLine(turn); // speaker_00 [00:00:01.583 --> 00:00:03.405] (conf=0.98)
}

Modèles — téléchargement à l'exécution¶

Deux modèles ONNX sont requis, tous deux téléchargés à l'exécution (aucun n'est fourni dans les paquets NuGet du SDK). Les deux sont exportés par le projet sherpa-onnx :

Le modèle de segmentation est indépendant de la langue — seul le modèle d'embeddings doit correspondre à votre langue. Les valeurs par défaut SegmentationModelUrl / EmbeddingModelUrl de SpeakerDiarizationSettings pointent vers les ressources de version pyannote et WeSpeaker anglais. Elles sont informatives — le SDK ne télécharge jamais rien de lui-même ; les fichiers réellement chargés sont SegmentationModelPath et EmbeddingModelPath. Tout modèle d'embeddings WeSpeaker ou 3D-Speaker à fbank de 80 bandes dont les poids sont utilisables commercialement peut être substitué ; le front-end de caractéristiques fbank se configure lui-même (mise à l'échelle des échantillons et normalisation des caractéristiques) à partir des métadonnées ONNX du modèle, donc aucun réglage manuel n'est nécessaire lors du changement.

Diarisation multilingue¶

L'embedding WeSpeaker par défaut est entraîné en anglais (VoxCeleb) et sous-détecte les locuteurs dans les autres langues. Pour un contenu non anglophone ou multilingue, utilisez le modèle d'embeddings 3D-Speaker ERes2NetV2 multilingue (Apache-2.0) : faites pointer EmbeddingModelPath vers son fichier ONNX et définissez EmbeddingModel = SpeakerEmbeddingModel.ERes2NetV2Multilingual. Le modèle de segmentation ne change pas.

var settings = new SpeakerDiarizationSettings(segmentationModelPath, eres2netv2ModelPath)
{
    EmbeddingModel = SpeakerEmbeddingModel.ERes2NetV2Multilingual,

    // Réajustez le seuil pour cet embedding — voir ci-dessous. La valeur par défaut (0.5) le sursegmente.
    ClusterThreshold = 0.8f,
    Provider = OnnxExecutionProvider.CPU,
};

var diarization = new SpeakerDiarizationBlock(settings);

EmbeddingModel est une indication déclarative : elle sélectionne l'URL de téléchargement recommandée, tandis que le fichier réellement chargé est toujours EmbeddingModelPath. Comme le front-end lit la configuration des caractéristiques depuis les métadonnées ONNX du modèle, passer d'un modèle à l'autre ne nécessite aucune autre modification de code.

Les URL de téléchargement sont aussi exposées comme constantes : SpeakerDiarizationSettings.WeSpeakerEnglishModelUrl et SpeakerDiarizationSettings.ERes2NetV2MultilingualModelUrl.

Paramètres clés¶

SpeakerDiarizationSettings(segmentationModelPath, embeddingModelPath). Contrairement aux paramètres d'IA de vision, ce type ne dérive pas de OnnxInferenceSettings — ceux-ci décrivent le prétraitement des images vidéo, ce qui ne s'applique pas à une paire de modèles audio.

Les valeurs par défaut sont celles de l'implémentation de référence et constituent un bon point de départ pour un contenu quelconque.

Tours de locuteur¶

Chaque SpeakerSegment (issu de SpeakerSegmentEventArgs.Segment et de GetTimeline()) :

Les identifiants de locuteur sont stables au sein d'une exécution, pas d'une exécution de pipeline à l'autre (cette version ne réidentifie pas un locuteur entre exécutions).

Transcription diarisée — « qui a dit quoi »¶

DiarizedTranscriptBuilder fusionne une transcription de reconnaissance vocale avec la chronologie de diarisation, en étiquetant chaque segment de transcription avec le locuteur qui le recouvre le plus (les égalités reviennent à l'identifiant de locuteur le plus bas). C'est du traitement de données pur — sans dépendance de modèle ni de média — il associe donc un SpeechToTextBlock à un SpeakerDiarizationBlock. Construisez-la après la fin de flux, lorsque la chronologie de diarisation existe.

using VisioForge.Core.Types.X.AI;

// transcript : tuples (start, end, text) issus de SpeechToTextBlock.OnSpeechRecognized
// timeline : diarization.GetTimeline()
var labeled = DiarizedTranscriptBuilder.Build(transcript, timeline);
foreach (DiarizedTranscriptSegment seg in labeled)
{
    // "[00:00:01.000 --> 00:00:03.000] speaker_00: A pencil with black lead writes best."
    Console.WriteLine(seg);
}

Chaque DiarizedTranscriptSegment porte Start, End, Text et le SpeakerId attribué (-1 lorsqu'aucun tour de diarisation ne recouvre le segment — par exemple un silence).

Pipeline manuel Media Blocks¶

Placez SpeakerDiarizationBlock dans la chaîne audio avant le rendu ou la sortie audio :

var diarization = new SpeakerDiarizationBlock(settings);
diarization.OnSpeakerSegment += Diarization_OnSpeakerSegment;

pipeline.Connect(audioSource.Output, diarization.Input);
pipeline.Connect(diarization.Output, audioRenderer.Input);

Diarisation de fichier avec MediaPlayerCoreX¶

Pour la lecture, Audio_Play doit valoir true pour que la chaîne audio soit construite :

player.Audio_Play = true;

var diarization = new SpeakerDiarizationBlock(settings);
diarization.OnSpeakerSegment += Diarization_OnSpeakerSegment;

player.Audio_Processing_AddBlock(diarization); // avant OpenAsync / PlayAsync
await player.OpenAsync(source);
await player.PlayAsync();

Laissez le fichier se lire jusqu'à sa fin : arrêter la lecture prématurément saute l'étape de regroupement et laisse la chronologie vide. La diarisation ne lit que l'audio, donc pour indexer un fichier aussi vite que le matériel le permet plutôt qu'en temps réel, donnez au lecteur un puits audio non synchronisé — player.Audio_OutputBlock = new NullRendererBlock(MediaBlockPadMediaType.Audio) { IsSync = false }; — afin que l'audio ne soit pas cadencé par l'horloge. (Video_Renderer_IsSync = false ne désynchronise qu'un rendu vidéo, il n'a donc aucun effet sur un fichier uniquement audio.)

Voir Utilisation des blocs d'IA avec VideoCaptureCoreX et MediaPlayerCoreX pour l'API Audio_Processing_* complète et les règles de cycle de vie. Le moteur possède le bloc câblé après le démarrage et le libère à l'arrêt de la session — créez un nouveau bloc pour la session suivante.

Fonctionnement¶

Comprendre ces trois étapes explique chacun des paramètres ci-dessus, et pourquoi le résultat ne peut pas arriver plus tôt.

1. Segmentation, à mesure que l'audio s'écoule. L'audio est rééchantillonné en mono 16 kHz et découpé en fenêtres de 10 secondes qui avancent d'une seconde à la fois — les fenêtres se recouvrent donc à 90 %, et chaque instant d'audio est vu par une dizaine d'entre elles. Le modèle pyannote indique, pour chacune de ses ~59 trames de sortie par seconde, lesquels des trois locuteurs locaux à la fenêtre au maximum sont en train de parler.
2. Empreintes vocales, à mesure que l'audio s'écoule. Pour chaque fenêtre et chaque locuteur qui y est actif, l'audio de ce locuteur est collecté — moins chaque trame où quelqu'un d'autre parle aussi — et transformé en empreinte vocale. La parole superposée est exclue délibérément : une empreinte vocale prise sur deux voix à la fois se situe entre les deux et ressemble aux deux, ce qui soude deux locuteurs en un seul. Les tours comptant moins de ~0,17 s de parole propre sont écartés pour la même raison.
3. Locuteurs et chronologie, en fin de flux. Toutes les empreintes vocales de l'enregistrement sont regroupées ensemble (regroupement agglomératif, saut complet, distance cosinus — ClusterThreshold / NumSpeakers). Les numéros de locuteur locaux aux fenêtres sont réécrits en numéros globaux, toutes les fenêtres qui se recouvrent sont posées sur une même grille de trames, et chaque trame est décidée par un vote entre les ~10 fenêtres qui la couvrent : combien de personnes parlent est la moyenne de ce que ces fenêtres rapportent, et qui elles sont est le plus voté. Une fenêtre qui étiquette mal un instant est mise en minorité par ses voisines. Enfin, les trames deviennent des tours, les courtes pauses sont comblées (MinDurationOff) et les fragments sont écartés (MinDurationOn).

Threads, performances et cycle de vie¶

L'analyse s'exécute sur un worker d'arrière-plan dédié, pas sur le thread de streaming : l'interception rééchantillonne l'audio en mono 16 kHz et le pousse dans une file non bornée, et le worker le consomme par fenêtres qui se recouvrent. Comme l'analyse est hors du thread de streaming, l'audio n'est jamais cadencé sur les modèles : une source qui va plus vite qu'eux (un fichier décodé à pleine vitesse, ou une source en direct sur un fournisseur d'exécution lent) fait simplement prendre du retard au worker.

Un arriéré n'est jamais abandonné. La file grandit à la place — en mono 16 kHz cela coûte 64 Ko par seconde mise en tampon — et elle se vide dès que le worker rattrape son retard. Si une machine est durablement plus lente que sa source, l'arriéré ne cesse de croître, et c'est le signal honnête : la réponse est un matériel plus rapide ou un fournisseur d'exécution GPU, jamais l'analyse d'une fraction de l'audio. En fin de flux, le pipeline attend que le worker vide l'arriéré et publie la chronologie avant de se démonter.

OnSpeakerSegment est déclenché sur le thread du worker — ne touchez jamais l'interface utilisateur directement depuis le gestionnaire ; déléguez au dispatcher de l'interface ou au thread principal.

La mémoire croît avec l'enregistrement : les empreintes vocales sont conservées jusqu'à la fin (elles sont l'entrée du regroupement), et le regroupement construit une matrice de distances deux à deux sur celles-ci.

Complétude du résultat¶

Une chronologie n'est pleinement digne de confiance que lorsque IsTimelineComplete vaut true ET que UnattributedTurns vaut 0.

Cas d'usage¶

• Transcription de réunions et d'entretiens — étiquetez une transcription diarisée avec les tours par locuteur.
• Analytique de centres d'appels — séparez la parole de l'agent et du client pour des métriques de temps de parole et d'alternance.
• Indexation de médias — indexez la vidéo/l'audio enregistrés par locuteur pour la recherche et la navigation.
• Outils de podcast et de diffusion — générez des notes d'émission étiquetées par locuteur avec la reconnaissance vocale.

Dépannage¶

Foire aux questions¶

Pourquoi n'obtenez-vous aucun tour de locuteur avant la fin du fichier ?¶

Parce que jusque-là, il n'existe pas de « locuteur 2 » à rapporter. Le modèle de segmentation ne sépare les voix qu'à l'intérieur d'une seule fenêtre de 10 secondes et les numérote localement ; relier une voix à la minute 1 à la même voix à la minute 40 exige de regrouper d'un coup toutes les empreintes vocales de l'enregistrement. Le bloc fait tout le travail qu'il peut à mesure que l'audio s'écoule, et publie dès que le dernier échantillon est arrivé.

Puis-je diariser un flux en direct sans fin ?¶

Non. Un flux en direct n'a pas de fin de flux, donc l'étape de regroupement ne s'exécute jamais. Diarisez des enregistrements finis — ou découpez un flux en direct en morceaux finis et diarisez chacun d'eux (les identifiants de locuteur ne sont pas comparables d'un morceau à l'autre).

SpeakerDiarizationBlock nécessite-t-il une connexion Internet ?¶

Non — la diarisation s'exécute entièrement sur l'appareil via ONNX Runtime. Votre application télécharge les deux fichiers de modèle une seule fois (ou les intègre) ; rien n'est appelé par requête sur le réseau.

Puis-je le combiner avec la reconnaissance vocale pour obtenir une transcription étiquetée par locuteur ?¶

Oui — exécutez un SpeechToTextBlock et un SpeakerDiarizationBlock sur le même audio, puis fusionnez la transcription avec diarization.GetTimeline() à l'aide de DiarizedTranscriptBuilder.Build après la fin de flux.

Les identifiants de locuteur sont-ils les mêmes d'une exécution à l'autre ?¶

Non — les identifiants ne sont stables qu'au sein d'une seule exécution. Cette version ne réidentifie pas un locuteur entre exécutions.

Avec quelles langues fonctionne-t-il ?¶

Le modèle de segmentation est indépendant de la langue, il fonctionne donc d'emblée avec n'importe quelle langue. Le modèle d'embeddings WeSpeaker par défaut est entraîné en anglais (VoxCeleb) et sous-détecte les locuteurs dans les autres langues ; pour de l'audio non anglophone ou multilingue, changez EmbeddingModelPath pour le modèle multilingue 3D-Speaker ERes2NetV2 (Apache-2.0) et définissez EmbeddingModel = SpeakerEmbeddingModel.ERes2NetV2Multilingual (voir Diarisation multilingue). Le front-end adapte automatiquement son extraction de caractéristiques au modèle choisi à partir des métadonnées ONNX.