Journal NoComprendo, le retour

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
37
6
jan.
2025

Sommaire

Rappel des faits

Il y a déjà 5 ans, quelques semaines avant le début du grand enfermement, je vous présentais NoComprendo, un programme de commande vocale pour Linux.
Il permet d'associer des énoncés (mot ou groupe de mots précédés et suivis d'un silence) à des actions pré-programmée.
Les actions disponibles sont : séquences de touches (raccourcis claviers), saisie de texte, déplacement de souris, lancement de programme plus quelques métas commandes de pilotage de l'application.

Première présentation
Dépêche de l'époque

Les premières versions utilisaient les bibliothèques PocketSphinx pour la reconnaissance vocale, et libxdo pour la simulation du clavier et de la souris.
PocketSphinx n'avait plus le développement actif, et le nombre de langues disponibles était assez limité.
La libxdo s'appuyant sur X11, le destin de NoComprendo était déjà scellé.
Depuis la reconnaissance vocale a beaucoup progressé, et de nouveaux outils sont apparus pour piloter le clavier et la souris.

En me promenant sur les forums Mageia (ma distibution habituelle) j'ai découvert elograf, développé par Papoteur, qui réalise la dictée vocale.
Un petit tour dans le code pour découvrir les bibliothèques utilisées, et voilà de quoi faire renaître le moribond.

Quoi de neuf ?

De simple outil de commande vocale, NoComprendo est devenu une application complète d'accessibilité en intégrant la dictée et la synthèse vocale.

Fenêtre principale

Nouveaux composants

Une bibliothèque de reconnaissance et de dictée vocale : Vosk avec une vingtaine de langues disponibles.
Un outil de simulation de clavier et de souris compatible X11/Wayland : dotool. N'ayant pas de wayland opérationnel sur une machine, je n'ai pas encore pu vérifier si la compatibilité est réelle. Je m'en tiens donc aux promesses du site.
Un programme de synthèse vocale : svox-pico.

Reconnaissance et synthèse vocales sont effectuées hors-ligne, comme dans la version précédente. Les Gafam ne vous enregistreront pas.

Interface remaniée

La principale différence avec les versions 1.x, c'est qu'il n'y a plus besoin de définir de vocabulaire spécifique. PocketSphinx cherchait à reconnaître des groupes de mots dans un ensemble de mots qu'il fallait déclarer au préalable.

La nouvelle bibliothèque connaît l'ensemble de la langue française, rien à déclarer. On clique sur l'icône du micro et on articule bien devant le micro. Par contre on ne peut pas dire n'importe quoi, on en reparlera plus loin.

Edition d'une commande

Les groupes de commande sont affichés dans les onglets de la fenêtre principale.
Le premier onglet contient la liste des groupes de commandes. Les onglets suivants sont les groupes actifs.
Il y a moins de fenêtres à ouvrir pour ajouter/modifier des groupes ou des commandes. Si une commande ne convient pas, on double clique dessus et on ré-enregistre.

Tout le monde n'a pas besoin de commandes vocales, on peut n'être intéressé que par la dictée. Si c'est votre cas, il suffit de désactiver les groupes de commandes et commencer la dictée en cliquant sur le bouton prévu pour cet usage. Mais c'est plus marrant de commencer en disant "Je commence à dicter".
Les commandes vocales permettent de gérer facilement les "point", "point à la ligne" ou "virgule".

Le principe de la synthèse vocale (TTS : Text to speech) consiste comme d'habitude, à copier du texte dans le presse-papier, et de faire vocaliser le contenu du presse-papier.
Il n'y a que six langues disponibles pour la synthèse vocale.

Premier démarrage

Modèle de langage

Pour fonctionner, NoComprendo a besoin d'un modèle de langage. Celui-ci n'est pas intégré à l'application, il faut en télécharger un avant de commencer.
NoComprendo se connecte sur le site alphacephei.com et vous propose la liste des modèles de langues disponibles.

Pour le français, il y a un modèle 'fr' (1.4G) et un 'small-fr' (41M). Le choix du modèle n'est pas anodin, la reconnaissance vocale donnera des résultats différents d'un modèle à l'autre. Les groupes de commandes sont associées au modèle choisi.
Je conseille l'utilisation du modèle 'fr'.

Peut nécessiter un redémarrage

Si dotool a été installé avec NoComprendo, il a besoin d'un redémarrage système pour prendre en compte de nouveaux droits d'écriture (simulation du clavier et de la souris).
NoComprendo devrait détecter cette situation et suggérer un redémarrage, sinon seulement le lancement de programme et les métas commandes fonctionneront.

Formulation des énoncés

L'ancienne bibliothèque PocketSphinx reconnaissait des mots individuellement. Les énoncés étaient faits de deux ou trois mots : fermer fenêtre pour émettre Ctrl+W, par exemple.

Vosk est un modèle entrainé sur des exemples de langage, imprégné de statistiques et de probabilités que certains mots se retrouvent ensembles. Il va chercher à faire une phrase syntaxiquement correcte. Il vaudra mieux dire Fermer la fenêtre, la reconnaissance sera plus facile.
Mais suivant le modèle utilisé ('fr' ou 'small-fr'), il peut écrire plutôt Fermez la fenêtre ou Fermé la fenêtre. La solution que j'ai retenu pour la plupart des exemples est Ferme la fenêtre.

Il y a parfois des singuliers avec un modèle qui sont reconnus comme des pluriels avec l'autre.
Tout ça pour justifier que le choix du modèle est important, et que les commandes vocales ne sont pas toujours interchangeables.

La langue française est accompagnée d'un jeu d'exemples de commandes.
Il n'y a presque rien en anglais, car mon terrible accent n'est pas reconnu. Je suis prêt à intégrer des exemples de commandes qui me seraient fournies par d'authentiques anglophones.

Empaquetage

Pour les versions 1.X, j'avais fourni des paquets pour différentes distributions Linux via Open Build Service.
La mise à jour des paquets demande un suivi annuel fastidieux, à chaque sortie de nouvelle version d'une distribution.
Je n'ai plus le temps ni l'envie de m'en occuper.
Dorénavant, seuls les sources en .tar.gz et un paquet Mageia seront disponibles sur mon site.
Ça se compile avec Qt.

Je ne sais pas si Vosk et dotool sont bien intégrés dans les autres distributions Linux. En cas de difficulté, les empaqueteurs peuvent me contacter.

Où trouver ça ?

NoComprendo

L'aide intégrée est aussi disponible sur le site.

  • # 'fr' (41M) et un 'small-fr' (1.4G)

    Posté par  . Évalué à 4 (+2/-0).

    Plus logiquement, 'fr' fait 1.4G et 'small-fr' 41M. ;-)

    Bravo pour la persévérance ! :-)

  • # Dépêche !

    Posté par  . Évalué à 4 (+3/-0). Dernière modification le 06 janvier 2025 à 21:17.

    Merci pour ce journal très intéressant, @modo : à promouvoir en dépêche ?

  • # VOSK

    Posté par  (Mastodon) . Évalué à 3 (+0/-0).

    Crois-tu que VOSK serait performant pour du sous-titrage automatisé?

    J'ai récemment tenté d'utiliser la fonction de reconnaissance vocale de subtitle composer basée sur pocketsphinx pour sous-titrer La Grande Vadrouille [1]. Le résultat était tout bonnement catastrophique. Tout sous-titrer manuellement va me prendre un temps fou et m'ôter le plaisir de revoir le film.

    Du coup je suis en train de regarder du côté de whisper de openai en espérant obtenir quelque chose.

    [1] Il existe des sous-titre en français mais tous ceux que j'ai pu trouver, tant chez opensubtitle.org que sur un rip du blueray de la version remasterisée semblent incomplets. Il y a de longues sections du film sans aucun sous-titre.

    • [^] # Re: VOSK

      Posté par  (site web personnel) . Évalué à 2 (+1/-0).

      Pocket-sphinx cherche à reconnaître les mots sans le contexte de la phrase. J'imagine la catastrophe.

      J'avais fait quelques essais en mettant le micro devant le haut-parleur sur une chaîne d'infos.
      Le problème est que Vosk attend un silence pour finaliser la traduction. Le débit de paroles et l'absence presque totale de silence donne de mauvais résultats.

      Je viens d'essayer avec un documentaire sur Arte, au débit de parole raisonnable.
      Ça marchouille.
      NoComprendo pourrait faire l'affaire, mais il faudrait mettre une option qui rajoute un saut de ligne à la fin de chaque phrase dictée, sinon les phrases sont toutes collées les unes aux autres.
      J'ai déjà eu une demande dans ce sens sur le git. J'avais refusé en pensant à la simple dictée, mais ce cas de figure est intéressant et les sauts de ligne automatiques seraient indispensables.

      De toute façon, tu n'échapperas pas à une relecture attentive pour corriger les fautes.
      Vosk fonctionne bien si on parle lentement en articulant bien chaque syllabe, comme si on parlait à un petit enfant.
      Si le locuteur parle trop vite en avalant des syllabes, c'est vite la catastrophe.

      C'est un usage auquel je n'avais pas pensé, mais qui m'intéresse.

      • [^] # Re: VOSK

        Posté par  (Mastodon) . Évalué à 3 (+0/-0).

        Si le locuteur parle trop vite en avalant des syllabes, c'est vite la catastrophe.

        ça va être vite compliqué avec Louis de Funès :D

        Autre problème, il y a des parties en anglais et en allemand dans le film.

        • [^] # Re: VOSK

          Posté par  (site web personnel) . Évalué à 2 (+0/-0).

          Alors c'est pas automatique mais ça reste efficace : il est possible de faire la transcription en doublant le film avec une voix qui passe bien la reconnaissance vocale.

          Pour avoir fait joujou quelques fois avec Vosk je pense qu'il en est capable.

          Adhérer à l'April, ça vous tente ?

  • # paquets

    Posté par  (site web personnel) . Évalué à 2 (+0/-0). Dernière modification le 07 janvier 2025 à 14:59.

    La mise à jour des paquets demande un suivi annuel fastidieux, à chaque sortie de nouvelle version d'une distribution.
    Je n'ai plus le temps ni l'envie de m'en occuper.

    L'Open Build Services c'est pas mal, mais pas idéal en terme d'intégration :/

    Côté Mageia, tu peux soumettre une demande de mise à jour via https://bugs.mageia.org

    Par exemple, https://bugs.mageia.org/show_bug.cgi?id=30710 si tu fournis le .spec actualisé, c'est généralement plus rapide :-) pour libaacs ça a bien fonctionné

    Bon, ça ne garantit pas que tu trouveras un nouvel empaqueteur ;-)
    https://bugs.mageia.org/show_bug.cgi?id=32652 pour printrun : nouveau paquet… ça n'a pas (encore) motivé grand' monde :/ (bon ya 2 paquets avec les dépendances)

    La procédure est similaire côté Debian (ça finira par se retrouver dans les dérivés) et Fedora (le compte est chez Redhat mais bon…).

    • [^] # Re: paquets

      Posté par  (site web personnel) . Évalué à 1 (+0/-0).

      Je sais bien faire les paquets pour Mageia. Il y en a un disponible sur le site et le fichier .spec est présent dans l'archive.

      Le problème des multiples distributions est de trouver les noms de chaque bibliothèque pour chaque distribution.
      Pour la première version, j'avais autant de machines virtuelles que de distributions Linux. Chacune à mettre à jour à chaque version, vérifier que ça compile toujours. Ça prend beaucoup de temps et c'est vraiment pénible.

      • [^] # Re: paquets

        Posté par  (site web personnel) . Évalué à 3 (+1/-0).

        Je sais bien faire les paquets pour Mageia. Il y en a un disponible sur le site et le fichier .spec est présent dans l'archive.

        oui, j'ai récupéré ton .spec

        il ne passe qu'en x86_64 je pense

        j'ai le spec de la 1.2 disponible en cauldron

        Il y a un peu d'adaptation à faire pour mettre le tien aux normes (c'est le boulot de l'empaqueteur).

        Le problème des multiples distributions est de trouver les noms de chaque bibliothèque pour chaque distribution.

        déjà lister l'intégralité de tes dépendances dans le README ou un fichier INSTALL aiderait… quitte à ce que tu n'indiques que celles que tu connais : ça évite d'avoir à fouiller dans un install.sh ou un Makefile ou…

        Pour Fedora, ils avaient fait le choix d'avoir le même nom en i586 et x86_64(libnom_de_la_lib), pas chez Mandriva ni chez Mageia (préfixe lib ou lib64, et il n'y a pas forcément non plus le même découpage entre Qt5 et Qt6…)

        Pour la première version, j'avais autant de machines virtuelles que de distributions Linux. Chacune à mettre à jour à chaque version, vérifier que ça compile toujours. Ça prend beaucoup de temps et c'est vraiment pénible.

        ah mais ce n'est pas moi qui te demanderait cela ;-) et, pour moi, ce n'est pas à toi de le faire.

        Un empaqueteur bénéficie d'un système de construction des paquets (build-system) avec déclinaison selon les versions (et je te confirme que ça peut vite devenir lourdingue à maintenir).

        L'avantage d'un fablab c'est que j'ai déjà plusieurs machines avec plusieurs distributions, donc bon ça permet déjà de fournir une première version adaptée du .spec ou du .DSC, après à l'empaqueteur de le remettre en forme aux normes de chaque distro (et selon le découpage des dépendances).

        Avec OBS, je ne sais jamais où récupérer ce qui a permis de construire un paquet… sur https://software.opensuse.org/download.html?project=home:be-root:nocomprendo&package=nocomprendo il n'y a pas le .spec ni le .DSC…

  • # Compilation sur Debian

    Posté par  . Évalué à 1 (+0/-0).

    J'ai l'erreur suivante en essayant de compiler sur Debian 12 :

    In file included from blink.h:17,
    from blink.cpp:21:
    config.h:80:28: error: field ‘speechesList’ has incomplete type ‘QMap’
    80 | QMap speechesList;
    | ~~~~~~~~~~~
    In file included from /usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h:1301,
    from /usr/include/x86_64-linux-gnu/qt5/QtGui/qtguiglobal.h:43,
    from /usr/include/x86_64-linux-gnu/qt5/QtGui/qpalette.h:43,
    from /usr/include/x86_64-linux-gnu/qt5/QtGui/QPalette:1,
    from blink.cpp:19:
    /usr/include/x86_64-linux-gnu/qt5/QtCore/qtypeinfo.h:240:29: note: declaration of ‘class QMap’
    240 | Q_DECLARE_MOVABLE_CONTAINER(QMap);
    | ~~~
    /usr/include/x86_64-linux-gnu/qt5/QtCore/qtypeinfo.h:222:41: note: in definition of macro ‘Q_DECLARE_MOVABLE_CONTAINER’
    222 | template class CONTAINER; \
    | ~~~~~~~~
    make[1]: *** [Makefile:810 : blink.o] Erreur 1

    S'il y a d'autres debianeux par ici qui auraient trouvé une solution :)

    aussi sur le salon xmpp:linuxfr@chat.jabberfr.org?join

    • [^] # Re: Compilation sur Debian

      Posté par  (site web personnel) . Évalué à 1 (+0/-0). Dernière modification le 07 janvier 2025 à 21:26.

      Yaka rajouter #include <QMap> au début de config.h.
      Ça devrait suffire.
      Je le rajoute aussi de mon côté.

      Je viens de penser que si on compile à la main sans passer par un paquet, il va manquer la création du répertoire pour les fichiers Vosk.

      Pour créer le répertoire, faire en tant que root :
      mkdir -p /opt/vosk-models/
      chmod 777 /opt/vosk-models/

      Je pense qu'on peut déplacer la création de ce répertoire du script du paquet vers le make install. Ce serait plus malin.
      Pour la prochaine version…

      • [^] # Re: Compilation sur Debian

        Posté par  (site web personnel) . Évalué à 2 (+0/-0).

        Je pense qu'on peut déplacer la création de ce répertoire du script du paquet vers le make install. Ce serait plus malin.

        oui, ce serait la bonne pratique : ou en tout cas, apporté par le bon paquet => pourquoi n'est ce pas apporté par vosk ?
        En outre, /opt/vosk-models c'est pour un programme externe au système. Pour vosk, ce serait plutôt /usr/share/vosk/models/ et si c'est spécifique à nocomprendo : /usr/share/nocomprendo/vosk-models/ via un paquet nocomprendo-vosk-models (ou 2 pour choisir entre le fr ou le small-fr)

        • [^] # Re: Compilation sur Debian

          Posté par  (site web personnel) . Évalué à 1 (+0/-0).

          J'ai mis ce répertoire à cet endroit parce qu'il est déjà là dans l'installation de elograf chez Mageia.
          Ça évite d'avoir des doublons sur ces gros fichiers.
          elograf propose une installation soit au niveau du système, soit juste pour un utilisateur.
          J'ai préféré n'avoir qu'une installation système pour tous les utilisateurs. C'est un choix arbitraire et discutable.

          • [^] # Re: Compilation sur Debian

            Posté par  (site web personnel) . Évalué à 2 (+0/-0).

            J'ai préféré n'avoir qu'une installation système pour tous les utilisateurs.

            moui, je pense aussi que c'est plus mieux, à voir comment c'est géré du côté des jeux pour les cartes de FPS par utilisateur… (bon c'est dans /usr/games ya des fichiers en drwxr-sr-xr-x appartenant à root groupe games)
            Ce serait donc au paquet vosk d'avoir un répertoire /usr/share/vosk/vosk-models qui appartiendrait ou aurait un sticky-bit au groupe vosk (avoir un répertoire en 777 sous /usr/share/ c'est pas top… après faut penser à rajouter tous les utilisateurs légitimes au groupe vosk et modifier les paquets elograf et nocomprendo pour le faire automatiquement). Bah ça attendra sans doute une version ultérieure le temps de se mettre d'accord :D

  • # paquet pour Mageia Cauldron

    Posté par  (site web personnel) . Évalué à 2 (+0/-0). Dernière modification le 07 janvier 2025 à 23:48.

    lorsque j'essaie de reconstruire le paquet en Cauldron à jour, par un rpmbuild -ba nocomprendo.spec j'ai eu quelques soucis

    TLDR :

    • rajouter un BuildRequires: pkgconfig(Qt6Multimedia) pour éviter Project ERROR: Unknown module(s) in QT: multimedia
    • trouver pourquoi à la compil' il ne prend pas /usr/lib64/libvosk.so plutôt que /usr/lib/python3.10/site-packages/vosk/libvosk.so ou alors faire en sorte que le paquet python3-vosk-0.3.46-4.mga10 fasse un lien vers /usr/lib64/libvosk.so.0

    Donc bon, ça fonctionne bien sous Gnome :

    • je réussis à lancer VLC
    • la dictée est correctement prise en compte (ce que je dis s'affiche) mais dans gedit il n'a l'air de prendre que 4 caractères (alors qu'il prend tout pour la formule de politesse o_O) => je vais creuser
    • même avec le modèle small-fr cela fonctionne correctement, le modèle fr faisant plutôt 1,7 Go une fois décompressé…

    Je n'ai pas eu la même erreur que sous Debian 12 Bookworm ;-)

    Reste à le proposer pour inclusion : en se basant sur Qt6 pour Cauldon, Qt5 peut-être pour Mageia 9.

    Détail des erreurs :

    + /usr/lib64/qt6/bin/qmake libsuff=64 'QMAKE_CFLAGS=-O2 -g -pipe -Wformat -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3  -fstack-protector-strong -m64 -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection=full' 'QMAKE_CXXFLAGS=-O2 -g -pipe -Wformat -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3  -fstack-protector-strong -m64 -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection=full' 'QMAKE_LFLAGS=-Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -Wl,-z,now -Wl,-O1 -Wl,--build-id=sha1 -Wl,--enable-new-dtags' QMAKE_STRIP=
Detected locale "C" with character encoding "ANSI_X3.4-1968", which is not UTF-8.
Qt depends on a UTF-8 locale, and has switched to "C.UTF-8" instead.
If this causes problems, reconfigure your locale. See the locale(1) manual
for more information.
Info: creating stash file /home/baud/rpmbuild/BUILD/nocomprendo-2.0-build/nocomprendo-2.0/.qmake.stash
Project ERROR: Unknown module(s) in QT: multimedia
erreur : Mauvais statut de sortie pour /home/baud/rpmbuild/tmp/rpm-tmp.23yNA3 (%build)

    et je ne vois pas pourquoi il y a dans le .spec :

    BuildRequires: lib64qt5widgets-devel
BuildRequires: lib64pulseaudio-devel
BuildRequires: qtbase5-common-devel

    et non : 

    BuildRequires: lib64qt6widgets-devel
BuildRequires: lib64pulseaudio-devel
BuildRequires: qtbase6-common-devel

    j'ai essayé avec 

    BuildRequires:  pkgconfig(Qt6Gui)
BuildRequires:  pkgconfig(Qt6Core)
BuildRequires:  pkgconfig(Qt6Widgets)

    bon avec compil' à partir du tar.gz :

    qmake && make
Info: creating stash file /home/baud/rpmbuild/SOURCES/nocomprendo-2.0/.qmake.stash
Project ERROR: Unknown module(s) in QT: multimedia

    ok j'installe lib64qt6multimedia-devel => là, la compil' se lance (oui, je suis sous Gnome par défaut mais j'ai task-plasma-minimal-6.2.5-1.mga10 et task-plasma-6.2.5-1.mga10 d'installés, mais pas l'env' de dév de KDE…)

    => donc rajouter un BuildRequires: pkgconfig(Qt6Multimedia)

    g++ -Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -Wl,-z,now -Wl,-O1 -Wl,--build-id=sha1 -Wl,--enable-new-dtags -Wl,-O1 -Wl,-rpath-link,/usr/lib64 -o nocomprendo about.o blink.o command.o commandset.o comprendo.o config.o dotoolpipe.o editcommand.o editutterance.o filedownloader.o main.o mainwindow.o misc.o modelchooser.o modelloader.o osd.o osdeditor.o reminder.o runguard.o settab.o settings.o speech.o trayicon.o zoombutton.o qrc_nocomprendo.o qrc_qmake_qmake_qm_files.o moc_about.o moc_blink.o moc_commandset.o moc_comprendo.o moc_dotoolpipe.o moc_editcommand.o moc_editutterance.o moc_filedownloader.o moc_mainwindow.o moc_modelchooser.o moc_modelloader.o moc_osd.o moc_osdeditor.o moc_reminder.o moc_settab.o moc_settings.o moc_speech.o moc_trayicon.o moc_zoombutton.o /usr/lib/python3.10/site-packages/vosk/libvosk.so /usr/lib64/libQt6Widgets.so /usr/lib64/libQt6Multimedia.so /usr/lib64/libQt6Gui.so /usr/lib64/libGLX.so /usr/lib64/libOpenGL.so /usr/lib64/libQt6Network.so /usr/lib64/libQt6Core.so -lpthread -lGLX -lOpenGL

    /usr/bin/ld: cannot find /usr/lib/python3.10/site-packages/vosk/libvosk.so: No such file or directory
    collect2: error: ld returned 1 exit status
    make: *** [Makefile:328: nocomprendo] Error 1
    erreur : Mauvais statut de sortie pour /home/baud/rpmbuild/tmp/rpm-tmp.RkPamP (%build)

    pourtant, j'ai :

    rpm -qa|grep -i vosk|sort
lib64kaldi-vosk5-git20231220-3.mga10
lib64kaldi-vosk-devel-git20231220-3.mga10
lib64vosk0-0.3.46-4.mga10
lib64vosk-devel-0.3.46-4.mga10 # fournit /usr/lib64/libvosk.so
python3-vosk-0.3.46-4.mga10 # ne fournit pas /usr/lib/python3.10/site-packages/vosk/libvosk.so

    donc bon, j'ai été au plus court :

    cd /usr/lib/python3.10/site-packages/
[root@localhost site-packages]# mkdir vosk
[root@localhost site-packages]# cd vosk
[root@localhost vosk]# ln -s /usr/lib64/libvosk.so

    donc => voir pourquoi ne pas se baser sur fichier dans /usr/lib64/ ?

    voilà, vous pouvez reprendre une activité normale ;-)

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.