Mozilla DeepSpeech 0.6 : de vastes gains de performances

Mozilla DeepSpeech 0.6 : de vastes gains de performances

Par Sébastien Gavois

Le 09 Décembre 2019 à 09h04
Sciences et espace
2 min 22

Mozilla DeepSpeech 0.6 : de vastes gains de performances

DeepSpeech est un ensemble de moteurs de type speech-to-text et text-to-speech, permettant donc la reconnaissance ou la synthèse vocale. La nouvelle mouture, sortie en fin de semaine dernière, apporte des gains très significatifs de performances.

L’un des plus gros changements est le passage à TensorFlow Lite, pour rappel une version réduite de TensorFlow dédiée aux appareils embarqués et mobiles. Cette transition et les optimisations apportées offrent des gains majeurs :

  • Le paquet DeepSpeech est passe de 98 à 3,7 Mo
  • Le modèle de traitement de l’anglais passe de 188 à 47 Mo
  • La consommation mémoire est divisée par 22
  • Le temps de démarrage est divisé par 500

Les performances du modèle sont telles que Mozilla n’hésite plus à dire qu’il fonctionne « plus vite qu’en temps réel », en ne se servant que d’un seul cœur sur un Raspberry Pi 4. Le taux d’erreur en reconnaissance vocale est actuellement de 7,5 %.

Les deux principaux sous-systèmes sont maintenant capables de streaming, annulant le besoin d’introduire des algorithmes de détection des silences.  Les transcriptions sont fournies en moyenne 260 ms après la fin de l’audio, 73 % plus rapidement qu’avant l’introduction du streaming.

Le passage à TensorFlow 1.14 fournit également son lot d’améliorations, par exemple une division par 2 (au maximum) du temps d’entrainement des modèles. Ces derniers peuvent être pleinement entrainés et déployés à des taux d’échantillonnage différents (8 kHz pour les données téléphoniques par exemple), le décodeur exposant des métadonnées pour chaque caractère dans la transcription.

DeepSpeech possède en outre ses propres paquets pour Windows, via .NET, Python, JavaScript ou C. Pour le premier, le paquet est disponible depuis la galerie NuGet, directement depuis Visual Studio. DeepSpeech reste compatible avec les plateformes précédentes, Android, Linux et macOS.

Commentaires (22)


dylem29 Abonné
Le 09/12/2019 à 09h25

Concrètement, ça apportera quoi? Je ne sais pas si l’outil de Mozilla est beaucoup utilisé.


Mihashi Abonné
Le 09/12/2019 à 10h51

Qu’il soit plus souvent utilisé ? <img data-src=" />



Mais c’est une question que je me suis posé, c’est utilisé quelque part déjà ou c’est juste en préparation ?


M'enfin !
Le 09/12/2019 à 11h36

Il paraît qu’Iron Man a décidé de migrer vers DeepSpeech pour son Jarvis.


rson
Le 09/12/2019 à 12h53

Si ça peut être une base pour un outil speech-to-text libre pour les dérivés d’Android qui n’ont pas d’outils Google pour ça… Ce serait formidable. Ca manque actuellement (en français en tout cas).


tazvld Abonné
Le 09/12/2019 à 13h57







dylem29 a écrit :



Concrètement, ça apportera quoi? Je ne sais pas si l’outil de Mozilla est beaucoup utilisé.







En gros, c’est un Speech-to-text libre. Il est entièrement entraînable sur n’importe quel base de donnée (tu peux même faire ta propre base de donnée de son pour qu’ils apprennent à reconnaître spécifiquement ta façon de parler). Je sais que la base de donnée de Modzilla contient du français, mais je ne sais pas si c’est utilisé (j’ai pas regardé cette partie du code). Cependant, je vois qu’ils ont un outils pour importer une BDD pour du mandarin.







rson a écrit :



Si ça peut être une base pour un outil speech-to-text libre pour les dérivés d’Android qui n’ont pas d’outils Google pour ça… Ce serait formidable. Ca manque actuellement (en français en tout cas).





En gros c’est ça.





Sinon, j’ai un peu lu le code. Petit détail, ça devrait pouvoir tourner avec Tensorflow 1.4, 1.5 mais ont fait un boulot pour le migrer vers Tensorflow 2.0 en mode Legacy.



L’autre difficulté pour lire ce code, c’est qu’ils ont fait mixer du tensorflow bas niveau, des partie de bibliothèque plus haut niveau (tf.nn) et je crois que j’ai vu du contrib passer aussi. Or, pour la partie réseau de neurone, la bibliothèque Keras simplifie grandement le taf surtout qu’une version spécialement adapté est directement intégré dans Tensorflow (tf.keras)

Enfin, la doc est un peu chiche, beaucoup de fonctions ne sont pas documenté, il faut un peu lire le code, les commentaire pour deviner ce qu’elle fait.



Bon, sinon, ce que fait le code :




  • input du réseau de neurone : le spectre du son en fonction du temps (il faut voir ça comme une séquence 1-D de vecteur)

  • 3 couches de convolution. En gros, c’est des truc qui travaille sur une fenêtre flottante, ici la fenêtre est selon l’axe du temps seulement.

  • un Long Short Term Memory (j’ai pas vu si c’était bidirectionnel cependant, j’imagine que oui). Ca, ça permet de travailler sur l’intégralité de la séquence, ça garde une mémoire de ce qui a déjà été lu (dans le cas du bidirectionnel, la séquence est aussi passé à l’envers, le futur devient le passé : on sais ce qui s’est passé avant, mais aussi ce qui va se passé).

  • 1 couche de convolution.

  • un softmax. Comme son nom l’indique, ça a tendance à fortement augmenter la valeur maximal d’un vecteur vis à vis du reste (et la somme des valeurs du vecteur vaut 1)

  • sortie : séquence 1-D de la même taille que l’input encodant le phonème

    De là, la séquence de sortie est ensuite convertie en une séquence de mots les plus probables.



    Selon moi, l’approche est simple et comme l’article de référence, date de 2014. Ils ont le mérite de proposer leur code, avec des programmes fonctionnels, et rien n’empêche (à part la doc) d’utiliser les outils à coté pour faire son propre modèle.





    Edit : aujourd’hui, on a tendance à utiliser du NN du début jusqu’à la fin, ici, la dernière partie serait plutôt remplacé par une autre NN. Je pense à un truc comme un mécanisme d’attention par exemple.



Okki Abonné
Le 09/12/2019 à 14h08

Tout le monde peut également contribuer à Common Voice, autre projet Mozilla qui permet de fournir un jeu de données dans les différentes langues pour entraîner DeepSpeech.


brazomyna
Le 09/12/2019 à 15h27

existe-t-il des benchs qui comparent objectivement le taux de réussite d’un google home vs alexa vs mozilla vs cortana par exemple ?



j’aimerais beaucoup migrer ma domotique vers de la reco vocale non cloudesque, mais si c’est pour avoir un taux d’erreur trop élevé, c’est mort d’avance.



ex: pour avoir testé il y a 2 ans environ, la reco vocale de cortana (via le projet S.A.R.A.H et les micros d’un kinect) arrivait à être moins bonne sur des phrases prédéfinies que mon google home avec des phrases non prédéfinies.


lissyx Abonné
Le 09/12/2019 à 16h50







tazvld a écrit :



En gros, c’est un Speech-to-text libre. Il est entièrement entraînable sur n’importe quel base de donnée (tu peux même faire ta propre base de donnée de son pour qu’ils apprennent à reconnaître spécifiquement ta façon de parler). Je sais que la base de donnée de Modzilla contient du français, mais je ne sais pas si c’est utilisé (j’ai pas regardé cette partie du code). Cependant, je vois qu’ils ont un outils pour importer une BDD pour du mandarin.





En gros c’est ça.





Sinon, j’ai un peu lu le code. Petit détail, ça devrait pouvoir tourner avec Tensorflow 1.4, 1.5 mais ont fait un boulot pour le migrer vers Tensorflow 2.0 en mode Legacy.



L’autre difficulté pour lire ce code, c’est qu’ils ont fait mixer du tensorflow bas niveau, des partie de bibliothèque plus haut niveau (tf.nn) et je crois que j’ai vu du contrib passer aussi. Or, pour la partie réseau de neurone, la bibliothèque Keras simplifie grandement le taf surtout qu’une version spécialement adapté est directement intégré dans Tensorflow (tf.keras)

Enfin, la doc est un peu chiche, beaucoup de fonctions ne sont pas documenté, il faut un peu lire le code, les commentaire pour deviner ce qu’elle fait.



Bon, sinon, ce que fait le code :




  • input du réseau de neurone : le spectre du son en fonction du temps (il faut voir ça comme une séquence 1-D de vecteur)

  • 3 couches de convolution. En gros, c’est des truc qui travaille sur une fenêtre flottante, ici la fenêtre est selon l’axe du temps seulement.

  • un Long Short Term Memory (j’ai pas vu si c’était bidirectionnel cependant, j’imagine que oui). Ca, ça permet de travailler sur l’intégralité de la séquence, ça garde une mémoire de ce qui a déjà été lu (dans le cas du bidirectionnel, la séquence est aussi passé à l’envers, le futur devient le passé : on sais ce qui s’est passé avant, mais aussi ce qui va se passé).

  • 1 couche de convolution.

  • un softmax. Comme son nom l’indique, ça a tendance à fortement augmenter la valeur maximal d’un vecteur vis à vis du reste (et la somme des valeurs du vecteur vaut 1)

  • sortie : séquence 1-D de la même taille que l’input encodant le phonème

    De là, la séquence de sortie est ensuite convertie en une séquence de mots les plus probables.



    Selon moi, l’approche est simple et comme l’article de référence, date de 2014. Ils ont le mérite de proposer leur code, avec des programmes fonctionnels, et rien n’empêche (à part la doc) d’utiliser les outils à coté pour faire son propre modèle.





    Edit : aujourd’hui, on a tendance à utiliser du NN du début jusqu’à la fin, ici, la dernière partie serait plutôt remplacé par une autre NN. Je pense à un truc comme un mécanisme d’attention par exemple.





    (Disclaimer : je bosse dessus)



    T’as plus ou moins raison. Pour le français, j’ai commencé à bosser sur un modèle français, mais Common Voice ne contient pas encore assez de données ni de variété pour être utilisable seul. Le modèle est encore très exéprimental.



    Côté TensorFlow, oui, c’est r1.14, faut qu’on passe sur r1.15 maintenant que v0.6.0 est sortie. On a préparé des trucs pour r2.0, mais ça va prendre du temps avant de migrer.



    Effectivement, on mélange des trucs hauts et bas niveau et contrib, parce que tout n’était pas forcément existant quand on a commencé, et/ou que Keras permet pas forcément tout ce qu’on veut.



    Côté doc, oui, on a commencé à sérieusement remanier qu’après la v0.5.1 notamment suite à des feedbacks pendant des workshops. La doc sur le réseau est plus complexe à faire, et idéalement oui pour le moment faut se plonger dans le code. Encore qu’on a normalement quand même les grandes lignes sur readthedocs. Après, des bugs / PRs sur Github avec des points d’incompréhensions qui soient bien explicités, on prends, pour améliorer la doc.



lissyx Abonné
Le 09/12/2019 à 16h53







brazomyna a écrit :



existe-t-il des benchs qui comparent objectivement le taux de réussite d’un google home vs alexa vs mozilla vs cortana par exemple ?



j’aimerais beaucoup migrer ma domotique vers de la reco vocale non cloudesque, mais si c’est pour avoir un taux d’erreur trop élevé, c’est mort d’avance.



ex: pour avoir testé il y a 2 ans environ, la reco vocale de cortana (via le projet S.A.R.A.H et les micros d’un kinect) arrivait à être moins bonne sur des phrases prédéfinies que mon google home avec des phrases non prédéfinies.





C’est difficile de donner une réponse, mais avec un peu de travail y’a pas de raison que ça ne marche pas. Un vocabulaire limité, on arrive assez facilement à avoir de bons résultats. J’avais expérimenté ça y’a un moment déjà, on a aussi des contributeurs qui nous ont fait des retours positifs (notamment un robot contrôlé à la voix).



Quant aux benchmarks, y’en a, mais faut faire attention, les jeux de données de tests peuvent être très biaisés et peu représentatifs d’une utilisation « finale » (avec du bruit, avec des micros pourris, etc). Ếtre plus robuste à du son dégradé on y travaille.



lissyx Abonné
Le 09/12/2019 à 16h58







Okki a écrit :



Tout le monde peut également contribuer à Common Voice, autre projet Mozilla qui permet de fournir un jeu de données dans les différentes langues pour entraîner DeepSpeech.





Absolument, et toutes les bonnes volontés sont les bienvenues, pas uniquement pour s’enregistrer, mais aussi pour :





  • étendre le jeu de texte (via Sentence Collector)

  • valider des enregistrements (dans toutes les langues que vous maîtrisez, pas uniquement le français)

  • s’enregistrer dans toutes les langues que vous maîtrisez, la diversité des accents c’est important



    Les statistiques sur la première release oficielle de Common Voice montrent aussi un gros déséquilibre dans les genres (72% masculin vs 7% féminin), donc il reste beaucoup de progrès à faire pour débiaiser les données et assurer une représentativité meilleure.



rmfx
Le 09/12/2019 à 21h55

Je suis surpris que Mozilla ne pousse pass ses nouvelles tech a etre codees en Rust..?


tazvld Abonné
Le 10/12/2019 à 10h03







lissyx a écrit :



(Disclaimer : je bosse dessus)



T’as plus ou moins raison. Pour le français, j’ai commencé à bosser sur un modèle français, mais Common Voice ne contient pas encore assez de données ni de variété pour être utilisable seul. Le modèle est encore très exéprimental.



Côté TensorFlow, oui, c’est r1.14, faut qu’on passe sur r1.15 maintenant que v0.6.0 est sortie. On a préparé des trucs pour r2.0, mais ça va prendre du temps avant de migrer.



Effectivement, on mélange des trucs hauts et bas niveau et contrib, parce que tout n’était pas forcément existant quand on a commencé, et/ou que Keras permet pas forcément tout ce qu’on veut.



Côté doc, oui, on a commencé à sérieusement remanier qu’après la v0.5.1 notamment suite à des feedbacks pendant des workshops. La doc sur le réseau est plus complexe à faire, et idéalement oui pour le moment faut se plonger dans le code. Encore qu’on a normalement quand même les grandes lignes sur readthedocs. Après, des bugs / PRs sur Github avec des points d’incompréhensions qui soient bien explicités, on prends, pour améliorer la doc.







Je n’ai pas regardé en détail le code de “DeepSpeech.py” (qui est la partie qui m’a intéressé), je n’ai pas très bien vu sur quelle sortie le réseau était entraîné. Main j’ai l’impression qu’une bonne partie du truc peut être fait avec tf.keras (autant utiliser la version de la bibliothèque intégré à TF). Par exemple, les couches dense (et le preprocessing create_overlapping_windows) se remplace très bien avec Conv1D, les LSTM par les LSTM de keras (dans TF, et je crois que c’est seulement depuis TF2, LSTM va utiliser la version cuDNN si c’est possible). Pour le dropout, tu as la couche Dropout, mais je pense que “SpacialDropout” serait peut être mieux. Tu peux utiliser les Callback pour faire des opérations régulièrement, comme les log (via tensorbord), enregistré régulièrement le réseau, earlystop… Le multi GPU est géré (à la base c’est keras.utils.multi_gpu_model , mais dans la doc de TF2, il conseille d’utiliser tf.distribute.MirroredStrategy ).



Dans les remarques, avez-vous essayer de remplacer les LSTM par des GRU ? Vous pourriez gagner en performance sans trop perdre en qualité.



Sinon, comme je l’ai dit, j’aurais tendance à faire du end-to-end, c’est a dire partir de la décomposition en fréquence pour arriver directement à la phrase. Est-ce que c’est prévu ?

L’idée est de pouvoir exploiter le contexte, c’est à dire la phrase en entier, pour deviner le mot prononcé. En effet, c’est ce que l’on fait nous naturellement, on n’entend pas forcément l’intégralité des mots, mais on arrive à le retrouver grâce aux quelques son que l’on a entendu et au contexte.

La façon dont je ferais s’approcherait des réseau de neurone utilisé pour faire de la traduction. On peut même potentiellement faire une version “à la volée”.







rmfx a écrit :



Je suis surpris que Mozilla ne pousse pass ses nouvelles tech a etre codees en Rust..?







Je dirais que la raison la plus évidentes c’est que les outils n’existe pas en Rust. Au contraire, python est Le Langage pour l’apprentissage automatique. Toutes les bibliothèques d’apprentissage automatique ont les version pour Python, tout particulièrement les bibliothèque pour l’apprentissage profond. Dans la réalité, ces bibliothèque sont généralement des wrappers pour du code compiler, les perf d’un code Python pure n’étant pas terribles.



L’autre raison, c’est que Rust n’est pas forcément fait pour ça. Rust est avant tout fait pour les systèmes critiques. Les code demandant une certaine sécurité d’exécution. Ce n’est pas le cas ici.



lissyx Abonné
Le 10/12/2019 à 11h15







tazvld a écrit :



Je n’ai pas regardé en détail le code de “DeepSpeech.py” (qui est la partie qui m’a intéressé), je n’ai pas très bien vu sur quelle sortie le réseau était entraîné. Main j’ai l’impression qu’une bonne partie du truc peut être fait avec tf.keras (autant utiliser la version de la bibliothèque intégré à TF). Par exemple, les couches dense (et le preprocessing create_overlapping_windows) se remplace très bien avec Conv1D, les LSTM par les LSTM de keras (dans TF, et je crois que c’est seulement depuis TF2, LSTM va utiliser la version cuDNN si c’est possible). Pour le dropout, tu as la couche Dropout, mais je pense que “SpacialDropout” serait peut être mieux. Tu peux utiliser les Callback pour faire des opérations régulièrement, comme les log (via tensorbord), enregistré régulièrement le réseau, earlystop… Le multi GPU est géré (à la base c’est keras.utils.multi_gpu_model , mais dans la doc de TF2, il conseille d’utiliser tf.distribute.MirroredStrategy ).



Dans les remarques, avez-vous essayer de remplacer les LSTM par des GRU ? Vous pourriez gagner en performance sans trop perdre en qualité.



Sinon, comme je l’ai dit, j’aurais tendance à faire du end-to-end, c’est a dire partir de la décomposition en fréquence pour arriver directement à la phrase. Est-ce que c’est prévu ?

L’idée est de pouvoir exploiter le contexte, c’est à dire la phrase en entier, pour deviner le mot prononcé. En effet, c’est ce que l’on fait nous naturellement, on n’entend pas forcément l’intégralité des mots, mais on arrive à le retrouver grâce aux quelques son que l’on a entendu et au contexte.

La façon dont je ferais s’approcherait des réseau de neurone utilisé pour faire de la traduction. On peut même potentiellement faire une version “à la volée”.







Je dirais que la raison la plus évidentes c’est que les outils n’existe pas en Rust. Au contraire, python est Le Langage pour l’apprentissage automatique. Toutes les bibliothèques d’apprentissage automatique ont les version pour Python, tout particulièrement les bibliothèque pour l’apprentissage profond. Dans la réalité, ces bibliothèque sont généralement des wrappers pour du code compiler, les perf d’un code Python pure n’étant pas terribles.



L’autre raison, c’est que Rust n’est pas forcément fait pour ça. Rust est avant tout fait pour les systèmes critiques. Les code demandant une certaine sécurité d’exécution. Ce n’est pas le cas ici.





Ouais, mais tous les trucs de Keras, ça n’existait pas quand on a commencé, comme j’ai dit. Et migrer ça c’est non trivial, faut s’assurer aucune régression dans la qualité, et dans les différentes instances d’inférences. Et l’équipe est pas grosse … On s’en est mangé un paquet de bugs et de comportements non attendus de la part de trucs pas si border-line que ça dans TensorFlow.



Je sais que reuben a essayé les convolutions dont tu parles, et ça marchait pas comme voulu. Bref tu le dis toi même, plein de trucs dans TF 2.0.



Sinon, GRU et end-to-end, c’est des bugs qui sont ouverts / fermés / documentés. GRU, pas ouf des tests qu’on avait fait. End-to-end, c’est pareil, on aimerait bien remplacer KenLM, mais pour le moment on a pas encore le temps.



lissyx Abonné
Le 10/12/2019 à 14h17

En vrai même, c’est ce que KenLM essaie de faire. Si tu regardes, il est utilisé dans la phase de décodage. KenLM apporte la connaissance de « la langue » pour amener justement du contexte et faire en sorte de le décodage CTC soit pondéré par cette connaissance de la langue. Ça pour le coup c’est encore moins documenté, mais c’est dans native_client/ctcdecode/ si tu veux voir.


tazvld Abonné
Le 10/12/2019 à 14h35

Je comprend bien.

Au vu du code, je vois bien que ça prendrait beaucoup trop de temps pour passer à un truc plus proche de Keras. Et j’imagine que le but est avant tout de faire quelque chose de fonctionnel, d’utilisable, donc ce n’est pas forcément une priorité.



Je connais bien les galères de TF. Potentiellement, de ce que j’ai vu de TF2, avec l’eager execution, ça devrait simplifier certaine chose pour débugger mais aussi créer des champs de mine pour débutants (donc à manipuler avec précaution).



De mon coté, je trouve la base intéressante et c’est vrai que j’ai bien envie d’essayer mes propres modèles. Parce bon, le plus chiant, ce n’est pas créer un modèle, c’est tout ce qui est autour : charger la BDD, la preprocesser…. une fois que tu as les datas d’input et les sorties, que tout est bien découpé en 3 dataset, écrire un modèle c’est la partie facile. Après plusieurs parcours de de DeepSpeech.py, je commence à voir comment ça fonctionne (c’est la partie qui m’interresse). Maintenant, il me faut trouver le temps.



lissyx Abonné
Le 10/12/2019 à 15h59

Absolument, c’est bien ça notre objectif. Si tu trouves du temps, tu es plus que le bienvenu :)


rmfx
Le 10/12/2019 à 19h20

Vu la dose de&nbsp;





tazvld a écrit :



Je dirais que la raison la plus évidentes c’est que les outils n’existe pas en Rust. Au contraire, python est Le Langage pour l’apprentissage automatique. Toutes les bibliothèques d’apprentissage automatique ont les version pour Python, tout particulièrement les bibliothèque pour l’apprentissage profond. Dans la réalité, ces bibliothèque sont généralement des wrappers pour du code compiler, les perf d’un code Python pure n’étant pas terribles. L’autre raison, c’est que Rust n’est pas forcément fait pour ça. Rust est avant tout fait pour les systèmes critiques. Les code demandant une certaine sécurité d’exécution. Ce n’est pas le cas ici.



&nbsp;Je disais ca parce que quand je regarde les sources github, 55.9 pourcent des sources du projet est cpp, qui est dans le meme domaine d’utilisation que Rust. Il ya a donc bien une large portion du code qui pourrait etre oxydee ? Apres, je me penche dessus de maniere assez simpliste.&nbsp;Le tooling est assez basique pour Rust mais si meme chez Mozilla, on ne prend pas le parti de promouvoir Rust, quit a etre moins confort, je me demande qui le fera.



BlueTemplar
Le 10/12/2019 à 19h45

Moi, je vais le faire.

(Oui, je sais, c’est extrêmement arrogant dit comme ça, mais je sens que je ne vais jamais m’y mettre si je ne prends pas ce genre d’engagement public !)


lissyx Abonné
Le 11/12/2019 à 07h07







rmfx a écrit :



Vu la dose de&nbsp; &nbsp;Je disais ca parce que quand je regarde les sources github, 55.9 pourcent des sources du projet est cpp, qui est dans le meme domaine d’utilisation que Rust. Il ya a donc bien une large portion du code qui pourrait etre oxydee ? Apres, je me penche dessus de maniere assez simpliste.&nbsp;Le tooling est assez basique pour Rust mais si meme chez Mozilla, on ne prend pas le parti de promouvoir Rust, quit a etre moins confort, je me demande qui le fera.





Oui mais regarde la répartition du C++, une grosse partie c’est native_client/ctcdecoder/, dont du code qui implémente l’opérateur TensorFlow augmenté du scoring avec le modèle de langage KenLM, plus openfst. Je sais pas trop ce que ça donnerait d’écrire un module python en C++ avec l’interfaçage nécessaire pour que ce soit appelé depuis CPython, mais très honnêtement, je pense que ça serait se rajouter une part non négligeable de boulot et de bugs.



La partie inférence pourrait être en Rust, sauf que comme ça dépend de bouts de TensorFlow, on se retrouve à dépendre de Bazel. Ça veut dire écrire une API en Rust, et exposée en C pour pouvoir faire des bindings de partout. Et que tout ça se marie correctement avec Bazel. C’était déjà assez galère de cross-compiler avec Bazel pour des cibles non supportées par TensorFlow (RPi3/RPi4) (les gens de Snips pourraient aussi en parler longtemps je crois :)).



Bref, à titre perso j’aime bien Rust mais j’en ai pas (encore) assez fait à mon goût. Dans l’optique de plus dépendre du runtime TensorFlow / TFLite, ça pourrait plus facilement s’envisager, par contre.



Sinon un contributeur propose des bindings Rust :-),https://crates.io/crates/deepspeech (et ça marche bien, je m’en sert sur un autre projet annexe).



tazvld Abonné
Le 11/12/2019 à 10h19

Déjà répondu, mais en effet, le code CPP semble majoritairement venir d’autres projets intégrés à DeepSpeech, mais ne sont pas spécifiquement développé à la base pour ça. J’ai l’impression que le seul code CPP original sert pour porter l’outil en tant que bilbiothèque dans d’autre langage.



Je rajouterais que Tensorflow peut être vu comme un langage à part entière. En effet, la bibliothèque sert avant tout à décrire un graph de calculs (computational graph : un graph ayant pour noeud des fonctions et pour arrêtes les sorties des fonctions) que tensorflow va compiler et exécuter. Python ici ne sert que de support pour décrire le graph et géré l’environnement de l’exécution. Du coup, ici, une partie du code python est en faite juste un support pour décrire un autre code.


secouss
Le 11/12/2019 à 10h51

J’arrive après la bataille mais vu que tu bosse dessus tu connais des outils qui utilisent cet api ?

Je cherche a convertir des discours en texte pour un projet, donc soit je créer moi même une appli ou tu lance un fichier son et il sort un texte (plus qu’a corriger) soit je trouve une appli qui le fait déjà.



En prime je balancerais les sons et textes libre dans la base par la suite (après correction)


lissyx Abonné
Le 11/12/2019 à 17h34







secouss a écrit :



J’arrive après la bataille mais vu que tu bosse dessus tu connais des outils qui utilisent cet api ?

Je cherche a convertir des discours en texte pour un projet, donc soit je créer moi même une appli ou tu lance un fichier son et il sort un texte (plus qu’a corriger) soit je trouve une appli qui le fait déjà.



En prime je balancerais les sons et textes libre dans la base par la suite (après correction)





Oui, on sait que des sociétés l’utilisent déjà, il y a un exemple dans le blog post hacks. Après, des fois c’est difficile de savoir que des gens s’en servent. La plateforme eSup Pod utilisée par plein d’université l’a intégré dans sa dernière release, en beta, par ex.



En vrai pour un besoin décrit basique comme celui-ci, nos binaires doivent pouvoir suffir.



Fermer