Étude de la relation entre le prétraitement de la voix et la précision de la transcription dans l'API Google Cloud Speech

La précision de la transcription est inférieure à ce à quoi je m'attendais

Comme je l'ai mentionné à la fin de l'article qui résumait le précédent Comment utiliser l'API Google Speech, j'ai rencontré un problème en raison du fait que la précision de la reconnaissance des caractères était inférieure à ce à quoi je m'attendais. J'ai fait.

Il semble qu'environ 80% des caractères sont transcrits dans rebuild.fm, mais dans mon cas, [la moitié d'entre eux ne sont pas reconnus par l'expérience](https://github.com/ysdyt/podcast_app/blob/master/text/google_speech_api /001.txt) Impression. Ce n'était pas parfait, mais c'était assez dévastateur, même si je m'attendais à comprendre la conversation en lisant le texte transcrit.

Partant du principe que "Speech API n'est pas mauvais, mon prétraitement est mauvais", j'ai essayé différentes combinaisons de paramètres et la présence ou l'absence de prétraitement et j'ai comparé la précision. Le but de cette fois est de trouver la meilleure méthode de prétraitement dans l'API Google Speech.

Données de la source sonore à vérifier

J'ai ciblé la première source sonore du podcast "Platinum Mining.FM" que j'ai enregistré et distribué. Ce qui est téléchargé est une source sonore claire éditée, mais comme je fais attention à l'enregistrement, tel que l'enregistrement dans une pièce calme, la qualité sonore est si claire qu'il n'y a pas beaucoup de différence même avec les données brutes.

La longueur de la source sonore n'est que de 1h. Je l'ai coupé à la position 1h depuis le début par l'édition. Cela n'a pas beaucoup de sens d'être 1h, mais je voulais juste l'essayer sur une longue source sonore et en faire une bonne cible expérimentale.

Éléments de vérification

Article précédent Afin de confirmer la construction provisoire faite à la fin, cette fois ** "Présence / absence de traitement de réduction de bruit" "Présence / absence de réglage du volume" "échantillon Nous vérifierons les trois items de «différence de taux hertz» **.

• ** Traitement de la réduction du bruit ** ・ ・ ・ Traitement du bruit blanc effectué par Audacity. La méthode d'exécution est ici

• ** Traitement du contrôle du volume ** ・ ・ ・ Traitement pour effectuer un contrôle automatique du volume avec Leverator. La méthode d'exécution est ici

• ** fréquence d'échantillonnage hertz ** ・ ・ ・ Taux d'échantillonnage audio. L'échantillonnage à 16kHZ est recommandé dans l'API Speech, mais il est à noter que la source sonore enregistrée à l'origine à 16kHZ ou plus n'est pas rééchantillonnée à 16kHZ et est entrée dans l'API Speech à la fréquence d'échantillonnage telle qu'elle est enregistrée. Le contenu et la méthode d'exécution sont ici. Étant donné que le taux d'échantillonnage par défaut du microphone utilisé pour l'enregistrement est de 44 kHz, j'essaierai cette fois deux modèles de 16 kHz ou 44 kHz.

J'ai fait une combinaison totale de paramètres pour les trois éléments ci-dessus. Comme indiqué dans le tableau ci-dessous, il existe 8 types au total.

En ce qui concerne la taille du fichier, si la "fréquence d'échantillonnage hertz" est réglée sur 16k, la taille du fichier diminuera fortement. C'est normal. On ne sait pas comment la présence ou l'absence de «traitement de réduction du bruit» et de «contrôle du volume» affecte la taille du fichier.

À propos, la source sonore est diffusée à chaque fois sur Shirokane Mining.

--Traitement de la réduction du bruit → Vrai,

• Contrôle du volume → Vrai
• sampling rate → 16k

Il correspond au même traitement que le n ° 1 de.

Méthode de vérification

Méthode d'exécution

La méthode d'exécution de l'API Google Speech a été réalisée selon Article précédent.

Méthode d'évaluation

Il est vraiment ennuyeux de vérifier si la transcription est exacte une par une, nous allons donc ici vérifier approximativement de manière qualitative quel paramètre est la transcription la plus précise.

Cependant, il est difficile de l'évaluer tel quel, il semble donc être un résultat quantitatif.

--Nombre total de caractères de transcription --Nombre total de mots extraits par mecab (avec doublons) --Nombre de nomenclature extraite par mecab (avec duplication) --Nombre total de mots extraits par mecab (pas de duplication) --Nombre de nomenclature extraite par mecab (pas de duplication)

Je vais publier comme élément d'évaluation.

résultat

Résultats quantitatifs

Les valeurs des résultats quantitatifs sont les suivantes.

C'est un peu difficile de comprendre s'il s'agit d'un tableau, alors j'ai fait un graphique.

• En tenant compte de tous les éléments ** Le meilleur résultat était le n ° 5 ** (sans traitement de réduction du bruit, avec réglage du volume, échantillonnage à 16 kHz)
• ** C'était mauvais n ° 3 ou n ° 4 ** (les deux sont mauvais car ils sont identiques)

Ce que l'on peut dire des résultats quantitatifs est

• Aucun traitement de réduction du bruit ** (Faux) ** est meilleur

• Le processus de réglage du volume doit être ** (Vrai) **

• Étant donné que la présence ou l'absence de "traitement de réduction de bruit" et de "traitement de réglage du volume" a un effet plus important sur l'échantillonnage, on peut dire qu'il n'y a presque pas de différence entre 16 kHz ou 44 kHz, mais à proprement parler, "les mots de nomenclature sans doublon" Dans l'élément «nombre», 16 kHz est toujours un résultat légèrement meilleur, donc ** 16 kHz semble être meilleur **.

Résultat qualitatif

Confirmer qualitativement les résultats de transcription du meilleur n ° 5 et du pire n ° 3 (le n ° 4 allait bien, mais pour le moment).

Résultat de la transcription

Les images sont disposées côte à côte pour une comparaison facile de la plage d'une partie de la transcription entière. La gauche est le n ° 5 et la droite est le n ° 3.

Eh bien, je ne suis pas sûr.

Nomenclature fréquente

Je ne suis pas sûr, alors comparons les "mots nominaux sans doublon" et "le nombre de comptes" sortant respectivement des numéros 5 et 3. Essayons d'afficher les mots qui sont apparus 11 fois ou plus.

Les mots fréquents se ressemblent presque.

Mot nuage

Soit dit en passant, bien que l'information n'augmente pas en particulier, je vais créer un nuage de mots et y jeter un œil d'une manière ou d'une autre. N ° 5 à gauche et N ° 3 à droite.

À propos, "shochu" est une erreur de transcription de "résident".

Résumé

Parmi les trois éléments vérifiés, la combinaison qui a donné les meilleurs résultats quantitatifs était

• Traitement de réduction du bruit → Aucun --Traitement de l'ajustement du volume → Oui
• sample rate hertz → 16kHz

est devenu. Comme indiqué dans le responsable de l'API, il semble préférable de ne pas avoir de traitement de réduction du bruit. Par contre, il est préférable d'avoir un traitement de réglage du volume, il semble donc qu'il vaut mieux pour l'API que le volume soit clair (pas faible). Enfin, il a été dit que ceux enregistrés au-dessus de 16 kHz ne devraient pas être rééchantillonnés, mais même lors d'un enregistrement à 44 kHz, il semble préférable de rééchantillonner à 16 kHz en termes d'API (cependant, cela ne semble pas affecter la vue d'ensemble Mais.)

En comparant qualitativement le résultat de la transcription par la combinaison d'éléments avec les meilleurs résultats (n ° 5) et le résultat de la transcription par la combinaison d'éléments avec les pires résultats (n ° 3), les résultats de la transcription Il semblait qu'il n'y avait presque aucune différence dans les mots fréquemment utilisés qui réussissaient, et il a été constaté que la différence de paramètres ne faisait pas une grande différence dans le contenu de la transcription lui-même. Pour les mots aux apparences rares, il peut y avoir des cas où la nouvelle transcription est réussie, mais je ne l'ai pas confirmée car elle sort du cadre de cette vérification (car je n'ai pas l'énergie de confirmer autant) ..

Le mystère «environ 80% de la transcription est possible avec rebuild.fm» s'approfondit, mais je pense que la précision de transcription de l'API Google Speech est limitée à ce niveau avec la qualité de ma source sonore enregistrable. La route vers la transcription automatique est encore raide.

Future Work

Je voudrais essayer le meilleur résultat de transcription précis de l'API Google Speech par rapport à Amazon Transcribe obtenu cette fois.

Beaucoup d'articles "comparés" que j'ai vus sont transcrits au niveau de plusieurs lignes (ou minutes) et indiquent bon / mauvais. Ou, il y a beaucoup de choses qui sont faites pour les «sources sonores trop claires» telles que les vidéos d'actualités.

À propos de Transcribe Buzzing Blog parle également de transcription de haute précision en anglais. On sait que la précision de l'anglais est élevée dans le domaine du traitement du langage naturel, mais il s'agit de savoir s'il s'agit du japonais.

Ce que je veux savoir, c'est jusqu'où je peux me battre contre les sources sonores japonaises, les sources sonores bruyantes enregistrées par des amateurs comme le podcast, les sources sonores longues d'environ 1h et les sources sonores où plusieurs personnes se croisent avec juste l'API. Je voudrais donc le vérifier.