Lancer Mozik

_____ ______   ________  ________  ___  ___  __
|\   _ \  _   \|\   __  \|\_____  \|\  \|\  \|\  \
\ \  \\\__\ \  \ \  \|\  \\|___/  /\ \  \ \  \/  /|_
 \ \  \\|__| \  \ \  \\\  \   /  / /\ \  \ \   ___  \
  \ \  \    \ \  \ \  \\\  \ /  /_/__\ \  \ \  \\ \  \
   \ \__\    \ \__\ \_______\\________\ \__\ \__\\ \__\
    \|__|     \|__|\|_______|\|_______|\|__|\|__| \|__|

┌┬┐┬ ┬┌─┐  ╔═╗┬─┐┌─┐┬ ┬┌─┐┌─┐┌┬┐┬─┐┌─┐┌┬┐┌─┐┬─┐  ┌─┐┌─┐  ╦ ╦╔╦╗╦╔═
 │ ├─┤├┤   ║ ║├┬┘│  ├─┤├┤ └─┐ │ ├┬┘├─┤ │ │ │├┬┘  │ │├┤   ╠═╣ ║ ╠╩╗
 ┴ ┴ ┴└─┘  ╚═╝┴└─└─┘┴ ┴└─┘└─┘ ┴ ┴└─┴ ┴ ┴ └─┘┴└─  └─┘└    ╩ ╩ ╩ ╩ ╩

notes: README presque sans image, car github est vraiment nul pour les gérer nativement... Mozik est le script de ce projet. C'est lui qui rassemble tous les instruments bash et python en une seule symphonie afin de créer et évaluer des modèles basés sur HTK.

Flags de mozik.sh

• -i pour initier la symphonie de HTK (utilisera -wlr avec razcli.sh)
• -t pour entraîner la symphonie de HTK (utilisera -z avec razcli.sh)
• -e pour évaluer la symphonie de HTK (utilisera -qe avec razcli.sh)
• -s pour obtenir le statut actuel de la symphonie du chef-d'œuvre HTK (sortie dans status.log)

Developement

Entrainement avec HTK


1. HCopy => premiere etape pour obtenir la trainlist

#train.sh

../HTK/HTKTools/HCopy -C config  -S  ../output/train.scp

2. HCompV => génère les MFCC

#init_model.sh

../HTK/HTKTools/HCompV -T 1 -C config -f 0.01 -m -S "$OUTPUT_PATH"trainlist -M "$OUTPUT_PATH"hmm_init proto.txt

3. HERest => Initialise le modele

#train_model.sh

../HTK/HTKTools/HERest -C config -S "$OUTPUT_PATH"trainlist -I "$OUTPUT_PATH"labFile -H "$SRC"/macros -H "$SRC"/hmmdefs -M "$DST" ./hmmList.txt

4. HResult => donne un score du modèle en utilisant les resultats de Hvites

#eval.sh

	../HTK/HTKTools/HResults -I "$OUTPUT_PATH"labFile hmmList.txt "$HviteRes" > "$OUTPUT_PATH"result.log

Config

# La fréquence d'échantillonnage de la source
SOURCERATE = 208.33
# Le format du fichier source audio. "NOHEAD" indique qu'il n'y a pas d'entete
SOURCEFORMAT = NOHEAD
# Le type de caractéristiques à extraire du signal audio en tant que cibles pour le modèle ici MFCC(coefficien cepstraux).
TARGETKIND = MFCC_0
# La fréquence d'échantillonnage des caractéristiques cibles
TARGETRATE = 100000.0
# La taille de la fenêtre utilisée pour extraire les caractéristiques
WINDOWSIZE = 250000.0
# Indique si une fenêtre de Hamming doit être appliquée à chaque trame d'analyse.
USEHAMMING = T
# Le coefficient de préaccentuation. Il est utilisé pour éliminer ou atténuer les composantes basses fréquences du signal.
PREEMCOEF = 0.97
# Le nombre de filtres de mel à utiliser lors de l'extraction des coefficients MFCC.
NUMCHANS = 26
# Le coefficient de liftering cepstral. Il est utilisé pour appliquer une pondération supplémentaire aux coefficients cepstraux.
CEPLIFTER = 22
# Le nombre de coefficients cepstraux à extraire.
NUMCEPS = 12
# Indique si les caractéristiques cibles doivent être normalisées.
ENORMALISE = F
# Indique si les fichiers de sortie doivent être sauvegardés de manière compressée.
SAVECOMPRESSED = F
# Indique si un code de redondance cyclique (CRC) doit être sauvegardé avec les fichiers de sortie.
SAVEWITHCRC = F
# Indique si les fichiers de sortie doivent être écrits dans un ordre naturel.
NATURALWRITEORDER = T
# Indique si les fichiers d'entrée doivent être lus dans un ordre naturel.
NATURALREADORDER = T

CI/CD

L'une des différences, et force, de notre groupe comparait au autre et sans doute notre travaille important sur l'intégration continue, en effet pour rendre le développement le plus portable et de s'assurer qu'aucun nouveau script ne brise le travaille précédant un pipeline d’intégration continue fut déployer sur Github. De plus chaque exécution réussi, uploader un modèle testable afin de rendre nos expérimentions plus facile et reproductible.

Aussi nous sommes très fière d'avoir profité un maximum de Microsoft et donc, a notre porte, d'avoir rendu cette entreprise un peut moins profitable.

Models

Premiers resultats

accuracy per epoch Longtemps après le début du projet, nous avons obtenu les résultats de la figure

Ces résultats sont assez prévisibles, en effet comme aucun changement n'a lieu aux niveaux des gaussiens il est cohérent d'avoir une accuracy stagnante, on omet bien sur les variation normale de ce type de mesure.

Dataset

L'un des éléments important du travaille de notre équipe fut le changement de dataset. En effet l'un des problèmes soulevait au debut du projet était le problème d’équilibrage, plus généralement, on remarque une surreprésentation des francais et une très forte sous-representation des belge et suisse, uniquement 80 pour les seconds.

A cette fin, une fois notre système fonctionnelle, l'une nos priorités fut de recréer un dataset de zéro, avec cette fois-ci un split plus raisonnable afin d'avoir des résultats utile (80/10/10).

#code du dataset balanced
for e in data_set(french_quota=1300,
                  belgium_quota=1300,
                  switzerland_quota=1300,
                  offset=0):
    continue

Les data viennent de la même source que précédemment common voice, mais on passe par huggingface pour rendre l'automatisation plus simple.

Nous aurons au final 3 dataset, mais nous vous expliquont leur raison d’être plus tard.

Variation étudier

Etats :

1. belgium
2. france
3. switzerland variation :

• no_change aucun changement de gaussine, baseline
• large_last multiplie par quatre les gaussiennes du dernier état
• double_all multiplie par deux la gaussienne de tous les états
• incr_per_states ajout incrémental de gaussienne par état (bl=1,fr=2,sw=3)
• double_last multiplie par deux les gaussiennedu dernier etat
• double_first multiplie par deux les gaussienne du premier états

Résultat du dataset original

Ce graphique représente les différentes variations du modèle réalisé. À travers lui, on peut voir l'importance des gaussiens. La meilleure courbe est donc le meilleur modèle et le large last avec une progression stables dans les itération et un score final de 63%.

Une limite importante de ces graphiques à soulever est l'inexactitude de l'exactitude. En effet, l'un des premiers résultats donnés par notre ligne de base est à 67%, un score qui pourrait sembler surprenant si on oubliait le nombre extrêmement important de Français dans le jeu de données. Ainsi, un modèle qui donne très souvent "Français" sans réelle logique sera très précis, mais sans raison réelle, comme on peut le voir sur la précision par classe (accuracy par classe).

Ce graphique explique bien le phénomène et on voit que l'accuracy du modèle est en réaliser l'accuracy de la france. Le seul point surprenant est le score impressionnant de la Suisse. Après analyse, on comprend facilement l'origine du problème : le faible nombre de Suisses, seulement 80 dans le jeu de données complet et 2 dans le jeu de test. Ainsi, cette précision (accuracy) est simplement une anomalie statistique cohérente avec le faible nombre d'échantillons, la même chose est vraie avec la Belgique.

Baseline, 10 iteration

Résultat du dataset equilibre

Afin de résoudre ces problèmes de metrics est obtenir de meilleurs résultats, nous passons sur le modèle équilibré. Les résultats sont similaires, mais beaucoup plus fiable grâce a la diversité de sample. Cependant, ces matrices de confusion font se soulever un nouveaux problème .

Graph d'accurary par classe balanced dataset baseline, 10 iteration Increased_state, 10 iteration

On voit sur ces deux matrices et surtout sur le graph un phenomene d'agregation, tout ou presque est écraser par la suprématie belge.

Notre hypothese est que l'accent si caractéristique des belges le rend hautement discernable au contraire de l'accent français et suisse qui ont meme pour des native sont parfois similaire. Ce sont pour nous ces deux point qui défavorise le dataset equilibre pour la reconaissance d'accent.

Résultat du dataset non-equilibre

Face au résultat du dataset précédant, une hypothèse proposée fut qu'un dataset avec un net avantage pour les français aiderait, paradoxalement, à rééquilibrer nos résultats.

![[Pasted image 20240111134608.png|450]] Les résultats sont malheureusement décevants, si l'accuracy par classe est plus équilibrée l'accuracy globale est globalement inférieure au modèle équilibré.

Conclusion

Le projet Mozik, orchestré par notre script éponyme, fusionne habilement des outils bash et Python pour créer et évaluer des modèles basés sur HTK. Nous avons rencontré des défis liés à l'équilibre des datasets, soulignant l'importance du choix des données pour la reconnaissance d'accent, avec des perspectives d'amélioration suggérées pour des résultats plus précis et équitables. Et nous proposons donc au final le modèle incr_per_stable avec le dataset balanced.