BrainScript HTKMLF Reader

Warnung

HTKMLFReader ist veraltet und wird durch HTK MLF und Feature deserializers ersetzt, vgl. Grundlegendes und Erweitern von Lesern. Verwenden Sie diese für Ihre Netzwerke.

HTKMLFReader ist ein Datenleser, der Dateien liest, die in der Regel mit Spracherkennungsaufgaben verknüpft sind, und insbesondere mit der Hidden Markov Model Toolkit (HTK) -Suite von Tools. Der Leser kann als Eingabe zwei Arten von Dateien verwenden, eine Liste der Featuredateien, die in der HTK-Parität als scp Datei ("Skriptdatei" bezeichnet werden), eine Bezeichnungsdatei mlf ("Modellbezeichnungsdatei") und eine Archivdatei.

HTKMLFReader basiert auf HTK-definierten Datasetformaten, daher empfehlen wir, sich mit HTK-Grundlagen vertraut zu machen, z. B. HTK Book.

Da CNTK verwendet werden können, um Netzwerke mit beliebiger Topologie zu erstellen, einschließlich Netzwerken mit mehreren Eingaben und Ausgaben, kann der HTKMLFReader eine oder mehrere scp Dateien MLF verarbeiten. Ein typisches Beispiel für die Verwendung des HTKMLFReader ist wie folgt:

    reader = [
        readerType = "HTKMLFReader"
        readMethod = "blockRandomize"
        miniBatchMode = "partial"
        randomize = "17280000"
        features = [
            dim = 792
            scpFile = "$ScpDir$\TIMIT.train.scp.fbank.fullpath"
        ]
        labels = [
            mlfFile = "$MlfDir$\TIMIT.train.align_cistate.mlf.cntk"
            labelDim = 183
            labelMappingFile = "$MlfDir$\TIMIT.statelist"
        ]
    ]

Der HTKMLFReader verfügt über die folgenden Konfigurationsparameter:

• readMethod: Die Methode zum Lesen der Features in den Arbeitsspeicher für die Verarbeitung während der Netzwerkschulung. Die Einstellung readMethod , um blockRandomize die Daten in große Blöcke zu dividieren und dann die Reihenfolge der Blöcke und die Reihenfolge der Daten innerhalb des Blocks zu zufälligisieren. Die Daten in jedem Block werden direkt aus den Featuredateien gelesen und von RAM freigegeben, wenn sie nicht mehr verwendet wird. Die blockRandomize Option erfordert eine Archivdatei, die unten beschrieben wird. Wie unten beschrieben, werden bei Verwendung in Verbindung mit frameMode = "false" der blockRandomize Lesemethode auch über Utterancen, aber nicht Frames zufällig verteilt. Dies ist für die Verwendung mit wiederkehrenden Architekturen geeignet, wenn die sequenzielle Art der Schulungsbeispiele beibehalten wird. Eine Alternative ist rollingWindow , die in allen Featuredateien liest und sie auf dem Datenträger in einer großen temporären Binärdatei speichert. Die Daten werden dann zufällig durch Ausführen eines großen Rollfensters über die Daten in dieser Datei ausgeführt und die Daten im Fenster zufälligisiert. Diese Methode sollte nur verwendet werden, wenn eine Archivdatei nicht verfügbar ist und nur im Framemodus funktioniert. Die Standardmethode ist blockRandomize.

• pageFilePath: Geben Sie an, wo die temporäre Seitendatei der Features gespeichert werden soll. Standardmäßig wird die bereitgestellte temp-Datei vom System verwendet.

• randomize: Dies gibt die Größe des Zufallsfensters an. CNTK verwendet ein rollierendes Fenster dieser Größe über die Daten, aus der sie beispielen können. Nur die Beispiele in diesem Rollfenster werden von Datenträgern geladen und nur so lange in RAM gespeichert. Die empfohlene Einstellung für die Sprachkorporora der Produktionsgröße beträgt 48 Stunden, d. h. geben Sie an 17280000. Der randomize Parameter versteht auch zwei spezielle Werte: auto oder none. none deaktiviert die Zufälligisierung vollständig, nützlich für die Auswertung oder das Schreiben von Ausgabedaten. auto wird den gesamten Korpus in RAM lesen, der in der Regel für Produktionsgrößendatensätze von mehreren Tausend Stunden Sprachausgabe nicht machbar oder wünschenswert ist.

• minibatchMode: partial oder full, diese Option entscheidet, wie der letzte Minibatch behandelt werden kann, wenn nicht genügend Frames vorhanden sind, um einen vollständigen Minibatch der angeforderten Größe zu bilden. Der Standardwert ist partial, der die verbleibenden Frames in einem kleineren endgültigen Minibatch der Schulungszeit verwendet. Die full Option verarbeitet nur vollständige Minibatches.

Das obige Beispiel enthält zwei Datenquellen, die vom Leser verarbeitet werden, Features in Form einer Liste von HTK-Featuredateien und Bezeichnungen, die sich in Form einer HTK-MLF-Datei befinden. Sowohl Features als auch Bezeichnungen entsprechen Knoten im Rechennetzwerk, in diesem Fall die Eingabe- und Ausgabeknoten. Beachten Sie, dass featureslabels die standardnamen, die vom SimpleNetworkBuilder verwendet werden, aber wenn das Netzwerk mit der Netzwerkbeschreibungssprache (Network Description Language, NDL) entworfen wird, können alle Namen verwendet werden, solange sie jeweils über einen entsprechenden Knoten im Netzwerk verfügen.

Um fortlaufende Features anzugeben, z. B. mfCCs oder Log mel Filterbank-Koeffizienten, sollten die folgenden Parameter in den Konfigurationsblock einbezogen werden:

• scpFile: eine Liste der zu verarbeitenden Dateien. Die Dateien sollten HTK-kompatible Dateien sein und können im Standardformat oder im "Archivformat" angegeben werden. Die Details zur Verwendung eines Archivs werden unten beschrieben.

• dim: eine ganze Zahl, die die vollständige Featurevektordimension mit dem gewünschten Kontextfenster angibt. Wenn Beispielsweise 72-dimensionale Features (24dimensionale Filterbankfeatures plus Delta- und Delta-Delta-Koeffizienten) vorhanden sind und das Netzwerk so konzipiert ist, dass ein Kontextfenster von 11 Frames verarbeitet wird, sollte die angegebene Dimension 792 sein. Beachten Sie, dass nur symmetrische Kontextfenster unterstützt werden.

Um die entsprechenden Bezeichnungen anzugeben, z. B. Phoneme- oder Senonebeschriftungen, sollte ein Konfigurationsblock verwendet werden, der die folgenden Parameter angibt:

• mlfFile: eine HTK-Formatdatei mlf , die die Bezeichnungen für alle in der scp Datei angegebenen Ausdrücke enthält.

• labelDim: Die gesamte Kardinalität des Bezeichnungssatzes.

• labelMappingFile: Der Pfad zu einer Datei, in der alle in der mlf Datei angezeigten Bezeichnungen aufgeführt sind, eine pro Zeile.

Beachten Sie, dass mehrere Eingaben und Ausgaben mithilfe zusätzlicher Leseblöcke für Features angegeben werden können, die aus Dateien gelesen werden, die in einer Datei aufgeführt sind, oder Bezeichnungen, die aus einer scpmlf Datei gelesen werden. Beispielsweise würde der Benutzer in einem Szenario mit mehreren Aufgaben lernen, in dem das Netzwerk sowohl die Sprecheridentität als auch die Bezeichnung senone vorhersagt, einen zusätzlichen Block angeben, der eine mlf Datei enthält, die Bezeichnungen enthält, die über die Sprecheridentität verfügen. Ebenso würde für ein Netzwerk mit mehreren Eingaben, z. B. MFCC- und PLP-Features, ein zusätzlicher Featureblock verwendet werden.

Für wiederkehrende Strukturen, z. B. eine RNN oder ein LSTM, gibt es zusätzliche Konfigurationsoptionen im HTKMLFReader

• frameMode: true oder false, ob der Leser die Daten auf Frameebene oder auf Utteranceebene zufälligisieren soll. true Die Einstellung ist die Standardeinstellung frameMode und eignet sich für Schulungsnetzwerke ohne zeitliche Verbindungen. Für Netzwerke, die für sequenzielle Informationen konzipiert sind, z. B. RNN, sollte festgelegt falsewerden, was bedeutet, frameMode dass DieUtterancen zufällig sind, aber die richtige Sequenz innerhalb einer Besprechung beibehalten wird. Beachten Sie, dass dies nur mit der blockRandomize Lesemethode funktioniert.

• nbruttsineachrecurrentiter: gibt die Anzahl der Zusätze an, die zusammen zur effizienten Schulung von Netzwerken mit wiederkehrenden Strukturen verarbeitet werden sollen. Der Standardwert ist 1, aber jeder Wert unter 20 bis 30 führt zu erheblichen Effizienzeinbußen mit GPUs.

• truncated: true oder false. Dies ermöglicht abgeschnittene BPTT.

Es ist wichtig zu beachten, dass es einige kleine Unterschiede zwischen dem Standard scp und dateien gibt, die in HTK und mlf den in CNTK verwendeten Dateien verwendet werden.

Insbesondere muss die mlf Datei die tatsächlichen Symbole enthalten, die für die Klassifizierung verwendet werden. Für die kontinuierliche Spracherkennung bedeutet dies in der Regel Bezeichnungen, die den Senone (physicalHMMstates) entsprechen. HVite generiert jedoch in der Regel eine mlf während der erzwungenen Ausrichtung, die nur die logischen HMM-Statusnamen enthält. Damit dies mlf in CNTK verwendet werden kann, muss entweder die mlf Nachbearbeitung erfolgen, um die logischen Zustandsnamen durch die entsprechenden Senonebeschriftungen zu ersetzen, oder HVite muss so geändert werden, dass sie die Senone-Bezeichnungen direkt schreibt.

Die scp vom HTKMLFReader verarbeiteten Dateien können eine von zwei Varianten sein: entweder das Standardformat, bei dem jede Zeile einer physischen Featuredatei entspricht, oder das aliasierte Format, wobei jede Zeile einen logischen Namen enthält und auf ein Segment einer möglicherweise größeren physischen Datei verweist, definiert durch Start- und Endframes. Der logische Name wird verwendet, um die entsprechenden Bezeichnungen in der mlf Datei zu identifizieren. Selbst wenn die Dateien einzeln gespeichert werden, wie im ersten Fall, muss das aliasierte Format immer mit der blockRandomize Lesemethode verwendet werden, da es die Informationen über die Start- und Endframes in der scp Datei verwendet, um die Längen der Ausdrücke zu bestimmen, ohne die Dateien selbst öffnen zu müssen. In diesem Fall sollte der Startrahmen 0 sein, und der Endrahmen sollte der Länge des Ausdrucks minus 1 entsprechen. Darüber hinaus sollten für mehrere Eingaben und/oder Ausgaben das aliasierte Format auch verwendet werden, damit alle scp Dateien und mlf Dateien ihre logischen Namen gemeinsam haben. Wenn die rollingWindow Lesemethode anstelle der blockRandomizeLesemethode verwendet wird, werden möglicherweise die Start- und Endframeinformationen weggelassen.

Hier sind Beispielausschnitte und mlf Dateien für das TIMIT-Korpus für ein Netzwerk mit 2 Featureeingaben scp (in diesem Fall MFCC- und PLP-Features) und 1 Ausgabe, die phoneme Zuständen entspricht.

Die scp Datei listet alle zu verarbeitenden Dateien mit dieser Syntax auf:

id=pathname

Eine CNTK proprietäre Erweiterung dieses Formats (die im ursprünglichen HTK nicht gefunden wird) besteht darin, dass CNTK eine bequemere relative Pfadnamesyntax ermöglicht, wenn sich die scp Datei neben den Features befindet:

id=.../filename

dabei ... wird auf das Verzeichnis der scp Datei verwiesen.

Die scp Datei für die MFCC-Features enthält Einträge wie diese.

train-dr1-fcjf0-si1027.mfc=//hostname/data/TIMIT/mfc/train/dr1/fcjf0/train-dr1-fcjf0-si1027.mfc[0,306]

train-dr1-fcjf0-si1657.mfc=//hostname/data/TIMIT/mfc/train/dr1/fcjf0/train-dr1-fcjf0-si1657.mfc[0,281]

train-dr1-fcjf0-si648.mfc=//hostname/data/TIMIT/mfc/train/dr1/fcjf0/train-dr1-fcjf0-si648.mfc[0,359]

Die scp Datei für die PLP-Features ähnelt jedoch unterschiedlichen physischen Dateien. Beachten Sie, dass der logische Stammname in beiden scp Dateien identisch ist.

train-dr1-fcjf0-si1027.plp=//hostname/data/TIMIT/plp/train/dr1/fcjf0/train-dr1-fcjf0-si1027. plp[0,306]

train-dr1-fcjf0-si1657.plp=//hostname/data/TIMIT/plp/train/dr1/fcjf0/train-dr1-fcjf0-si1657. plp[0,281]

train-dr1-fcjf0-si648.plp=//hostname/data/TIMIT/plp/train/dr1/fcjf0/train-dr1-fcjf0-si648.plp [0,359]

Eine mlf Datei listet die Bezeichnungen mit dieser Syntax auf:

#!MLF!#
"id"
labelBegin1 labelEnd1 label1
labelBegin2 labelEnd2 label1

...

.
"id"
labelBegin1 labelEnd1 label1
labelBegin2 labelEnd2 label1

...

.

...

Hier haben wir einen Abschnitt mit . (Punkt) pro Eingabedatei und eine Zeile pro Token innerhalb jedes Abschnitts beendet. Die Bezeichnungszeiten werden in einer Zeitbasis von 10e-7, und Sprachframes werden normalerweise 10e-2angegeben, sodass 5 Nullen benötigt werden, um an jeden Zeitindex angefügt zu werden.

Es ist wichtig zu beachten, dass CNTK nur die ersten drei Spalten* innerhalb eines Abschnitts einer mlp Datei liest und den Rest ignoriert. In unserer Beispieldatei mlf wird auch der logische Name für beide "scp"-Dateien freigegeben. Hier ist der Codeausschnitt:

#!MLF!#
"train-dr1-fcjf0-si1027.rec"
0 200000 h#_s2 -136.655975 h# -589.680481 h#
200000 400000 h#_s3 -145.780716
400000 800000 h#_s4 -307.243774
800000 1200000 q_s2 -349.529327 q -897.429504 q
1200000 1500000 q_s3 -280.568817
1500000 1800000 q_s4 -267.331390
1800000 1900000 iy_s2 -76.825096 iy -673.892883 iy
1900000 2400000 iy_s3 -305.832458
2400000 2800000 iy_s4 -291.235352

Jetzt werden Archivdateien beschrieben, die manchmal auch als chunk Dateien bezeichnet werden. CNTK verwendet ein Konzept von Blöcken für alle leser, und es bedeutet eine absolut andere Sache, so dass wir die Verwirrung vermeiden, die wir nichtin Bezug auf die unten beschriebenen Dateien verwenden, sondern sie Archive aufrufen.

Archivdateien sind im Grunde Spalten-Hauptmatrizen von float32, mit einer 12-Byte-Kopfzeile, die die Beispielgröße und die Anzahl der Beispiele enthält. Im Allgemeinen sind sie einfacher zu verwenden, insbesondere als Start. Der erwartete Header der Datei wird über die struct nachstehende Datei definiert:

struct fileheader
{
    int nsamples;
    int sampperiod;
    short sampsize;
    short sampkind;
}

Dabei gilt:

• sampsize ist die Größe eines Vektors in Bytes (=4 * feature dimension);
• sampkind ist ein numerischer Bezeichner des Featuretyps (MFCC, PLP usw.). CNTK ignoriert dies. Wenn Ihre Dateien nicht von HTK erstellt werden, können Sie dies einfach auf 9 (USER) festlegen. And
• sampperiod100000 sollte sein (CNTK diesen Wert hauptsächlich ignoriert, außer für Fehlermeldungen).

Schließlich ist es wichtig zu beachten, dass in den meisten Spracherkennungsanwendungen die fortlaufenden Features als Eingaben verwendet werden, während diskrete kategorisierte Bezeichnungen als Ausgabe verwendet werden. Der HTKMLFReader ordnet jedoch nur die Daten den Knotennamen zu und ist agnostisch, wie diese Daten verwendet werden. Eine entsprechende mlf Datei der Sprecheridentitätsbezeichnungen kann beispielsweise verwendet werden, um einen 1-heißen Vektor von Sprecheridentitätsfeatures als Eingabe für das Netzwerk zu generieren.