Wie ich am Ende des Artikels erwähnte, in dem die vorherige Verwendung der Google Speech API zusammengefasst wurde, stieß ich auf das Problem, dass die Genauigkeit der Zeichenerkennung geringer war als erwartet. Ich tat.
Es scheint, dass ungefähr 80% der Zeichen in rebild.fm transkribiert sind, aber in meinem Fall die Hälfte von ihnen wird durch Erfahrung nicht erkannt /001.txt) Impression. Es war nicht perfekt, aber es war ziemlich verheerend, obwohl ich erwartet hatte, das Gespräch zu verstehen, wenn ich den transkribierten Text las.
Basierend auf der Annahme, dass "Sprach-API nicht schlecht ist, meine Vorverarbeitung ist schlecht", habe ich verschiedene Kombinationen von Parametern und das Vorhandensein oder Fehlen einer Vorverarbeitung ausprobiert und die Genauigkeit verglichen. Der Zweck dieser Zeit besteht darin, die beste Vorverarbeitungsmethode in der Google Speech API zu finden.
Ich habe auf die erste Tonquelle des Podcasts "Platinum Mining.FM" abgezielt, den ich aufgenommen und verbreitet habe. Was hochgeladen wird, ist eine bearbeitete klare Tonquelle, aber da ich bei der Aufnahme, z. B. in einem ruhigen Raum, vorsichtig bin, ist die Tonqualität so klar, dass es selbst bei Rohdaten keinen großen Unterschied gibt.
Die Länge der Schallquelle beträgt nur 1h. Ich schneide es an der Position 1h von Anfang an durch Bearbeiten. Es macht nicht viel Sinn, 1 Stunde zu sein, aber ich wollte es nur an einer langen Tonquelle ausprobieren und machte es zu einem guten experimentellen Ziel.
Vorheriger Artikel Um die am Ende vorgenommene temporäre Konstruktion zu bestätigen, wird dieses Mal ** "Vorhandensein / Fehlen einer Rauschunterdrückungsverarbeitung" "Vorhandensein / Fehlen einer Volumenanpassung" "verwendet Wir werden die drei Punkte "Unterschied in der Rate Hertz" ** überprüfen.
** Rauschunterdrückungsverarbeitung ** ・ ・ ・ Verarbeitung von weißem Rauschen durch Audacity. Die Ausführungsmethode lautet hier.
** Lautstärkeregelung ** ・ ・ ・ Verarbeitung zur automatischen Lautstärkeregelung mit Leverator. Die Ausführungsmethode lautet hier.
** Abtastrate Hertz ** ・ ・ ・ Audio-Abtastrate. Die Abtastung mit 16 kHz wird in der Sprach-API empfohlen. Es wird jedoch darauf hingewiesen, dass die ursprünglich mit 16 kHz oder höher aufgenommene Tonquelle nicht mit 16 kHz erneut abgetastet wird und mit der Abtastrate in die Sprach-API eingegeben wird, während sie aufgezeichnet wird. Der Inhalt und die Ausführungsmethode sind hier. Da die Standardabtastrate des für die Aufnahme verwendeten Mikrofons 44 kHz beträgt, werde ich diesmal zwei Muster mit 16 kHz oder 44 kHz ausprobieren.
Ich habe eine Gesamtkombination von Parametern für die obigen drei Elemente erstellt. Wie in der folgenden Tabelle gezeigt, gibt es insgesamt 8 Typen.
No. | Dateiname | Rauschunterdrückungsverarbeitung | Lautstärkeregelung | sample rate hertz | Dateigröße |
---|---|---|---|---|---|
1 | 01_001_NoiRed-true_lev-true_samp16k.flac | True | True | 16k | 73.1MB |
2 | 02_001_NoiRed-true_lev-true_samp44k.flac | True | True | 44k | 169.8MB |
3 | 03_001_NoiRed-true_lev-false_samp16k.flac | True | False | 16k | 64.7KB |
4 | 04_001_NoiRed-true_lev-false_samp44k.flac | True | False | 44k | 147.4KB |
5 | 05_001_NiRed-false_lev-true_samp16k.flac | False | True | 16k | 75.8KB |
6 | 06_001_NiRed-false_lev-true_samp44k.flac | False | True | 44k | 180.9KB |
7 | 07_001_NiRed-false_lev-false_samp16k.flac | False | False | 16k | 68.1KB |
8 | 08_001_NiRed-false_lev-false_samp44k.flac | False | False | 44k | 160.2KB |
In Bezug auf die Dateigröße sinkt die Dateigröße stark, wenn "Sample Rate Hertz" auf 16 KB eingestellt ist. Das ist normal. Es war unklar, wie sich das Vorhandensein oder Fehlen von "Rauschunterdrückungsverarbeitung" und "Lautstärkeregelung" auf die Dateigröße auswirkt.
Übrigens, die Tonquelle wird jedes Mal auf Shirokane Mining.FM veröffentlicht
Es entspricht der gleichen Verarbeitung wie Nr. 1 von.
Die Ausführungsmethode der Google Speech API wurde gemäß Vorheriger Artikel durchgeführt.
Es ist wirklich langweilig zu überprüfen, ob die Transkription einzeln korrekt ist. Daher werden wir hier grob qualitativ prüfen, welcher Parameter die genaueste Transkription ist.
Es ist jedoch schwierig, es so zu bewerten, wie es ist, so dass es ein quantitatives Ergebnis zu sein scheint.
Ich werde als Bewertungsgegenstand ausgeben.
Die Werte der quantitativen Ergebnisse sind wie folgt.
No. | Dateiname | Rauschunterdrückungsverarbeitung | Lautstärkeregelung | sample rate hertz | Anzahl der Transkriptionszeichen | Gesamtzahl der duplizierten Wörter | Anzahl der Nomenklaturwörter mit Duplikaten | Gesamtzahl der Wörter ohne Vervielfältigung | Anzahl der edlen Wörter ohne Vervielfältigung |
---|---|---|---|---|---|---|---|---|---|
1 | 01_001_NoiRed-true_lev-true_samp16k.flac | True | True | 16k | 16849 | 9007 | 2723 | 1664 | 1034 |
2 | 02_001_NoiRed-true_lev-true_samp44k.flac | True | True | 44k | 16818 | 8991 | 2697 | 1666 | 1030 |
3 | 03_001_NoiRed-true_lev-false_samp16k.flac | True | False | 16k | 16537 | 8836 | 2662 | 1635 | 1026 |
4 | 04_001_NoiRed-true_lev-false_samp44k.flac | True | False | 44k | 16561 | 8880 | 2651 | 1659 | 1019 |
5 | 05_001_NiRed-false_lev-true_samp16k.flac | False | True | 16k | 17219 | 9191 | 2758 | 1706 | 1076 |
6 | 06_001_NiRed-false_lev-true_samp44k.flac | False | True | 44k | 17065 | 9118 | 2727 | 1675 | 1055 |
7 | 07_001_NiRed-false_lev-false_samp16k.flac | False | False | 16k | 16979 | 9045 | 2734 | 1679 | 1047 |
8 | 08_001_NiRed-false_lev-false_samp44k.flac | False | False | 44k | 17028 | 9120 | 2727 | 1664 | 1040 |
Es ist ein wenig schwer zu verstehen, ob es sich um eine Tabelle handelt, deshalb habe ich ein Diagramm erstellt.
Was aus den quantitativen Ergebnissen gesagt werden kann, ist
Keine Rauschunterdrückungsverarbeitung ** (False) ** ist besser
Der Lautstärkeregler sollte ** (True) ** sein
Da das Vorhandensein oder Fehlen von "Rauschunterdrückungsverarbeitung" und "Lautstärkeregelungsverarbeitung" einen größeren Einfluss auf die Abtastung hat, kann gesagt werden, dass es fast keinen Unterschied zwischen 16 kHz oder 44 kHz gibt, aber genau genommen "keine doppelten Nomenklaturwörter". Im Punkt "Nummer" ist 16 kHz immer ein etwas besseres Ergebnis, daher scheint 16 kHz besser zu sein.
Bestätigen Sie qualitativ die Transkriptionsergebnisse der besten Nr. 5 und der schlechtesten Nr. 3 (Nr. 4 war in Ordnung, aber vorerst).
Die Bilder sind nebeneinander angeordnet, um den Bereich eines Teils der gesamten Transkription leicht vergleichen zu können. Die linke ist Nr. 5 und die rechte ist Nr. 3.
Naja, ich bin mir nicht sicher.
Ich bin mir nicht sicher, also vergleichen wir die "Nomenklaturwörter ohne Duplizierung" und die "Anzahl der Zählungen", die von Nr. 5 bzw. Nr. 3 ausgegeben werden. Versuchen wir, die Wörter anzuzeigen, die 11 Mal oder öfter vorgekommen sind.
Häufig vorkommende Wörter sehen fast gleich aus.
Übrigens, obwohl die Informationen nicht besonders zunehmen, werde ich eine Wortwolke löschen und sie mir irgendwie ansehen. Nr. 5 links und Nr. 3 rechts.
"Shochu" ist übrigens ein Transkriptionsfehler von "resident".
Von den drei verifizierten Punkten war die Kombination, die die besten quantitativen Ergebnisse ergab
ist geworden. Wie im API-Beamten angegeben, scheint es besser, keine Rauschunterdrückungsverarbeitung zu haben. Auf der anderen Seite ist es besser, die Lautstärke anzupassen, daher scheint es für die API besser zu sein, dass die Lautstärke klar ist (nicht niedrig). Schließlich wurde gesagt, dass diejenigen, die mit 16 kHz oder höher aufgenommen wurden, nicht erneut abgetastet werden sollten, aber selbst wenn mit 44 kHz aufgenommen wird, scheint es besser, auf 16 kHz in Bezug auf die API abzutasten (dies scheint jedoch das Gesamtbild nicht zu beeinflussen). Aber.)
Beim qualitativen Vergleich der Ausgabe des Transkriptionsergebnisses durch die Kombination von Elementen mit den besten Ergebnissen (Nr. 5) und der Ausgabe des Transkriptionsergebnisses durch die Kombination von Elementen mit den schlechtesten Ergebnissen (Nr. 3) ergeben sich die Transkriptionsergebnisse Es schien, dass es fast keinen Unterschied in den häufig verwendeten Wörtern gab, die erfolgreich waren, und es wurde festgestellt, dass der Unterschied in den Parametern keinen großen Unterschied im Inhalt der Transkription selbst machte. Bei Wörtern, die selten vorkommen, ist die neue Transkription möglicherweise erfolgreich, aber ich habe sie nicht bestätigt, da sie nicht in den Rahmen dieser Überprüfung fällt (weil ich nicht die Energie habe, so viel zu bestätigen). ..
Das Rätsel, dass mit rebild.fm "etwa 80% der Transkription möglich sind", vertieft sich, aber ich denke, dass die Transkriptionsgenauigkeit der Google Speech API aufgrund der Qualität meiner beschreibbaren Tonquelle auf dieses Niveau beschränkt ist. Der Weg zur automatischen Transkription ist immer noch steil.
Future Work
Ich möchte das genaueste Transkriptionsergebnis der Google Speech API im Vergleich zu Amazon Transcribe versuchen, das dieses Mal erzielt wurde.
Viele der "verglichenen" Artikel, die ich gesehen habe, werden auf der Ebene mehrerer Zeilen (oder Minuten) transkribiert und geben gut / schlecht an. Oder es gibt viele Dinge, die für "zu klare Tonquellen" wie Nachrichtenvideos getan werden.
Über Transcribe Buzzing Blog spricht auch über hochpräzise Transkription in Englisch. Es ist bekannt, dass die Genauigkeit des Englischen im Bereich der Verarbeitung natürlicher Sprache hoch ist, aber der Punkt ist, ob es Japanisch ist.
Was ich wissen möchte, ist, wie weit ich gegen japanische Tonquellen, verrauschte Tonquellen, die von Amateuren wie Podcast aufgenommen wurden, lange Tonquellen von etwa 1 Stunde und Tonquellen, bei denen mehrere Personen nur mit der API sprechen, kämpfen kann. Also möchte ich es überprüfen.
Recommended Posts