Partager via

Lecteur HTKMLF BrainScript

  • Article

Avertissement

HTKMLFReader est obsolète et est remplacé par les MLF HTK et les désérialiseurs de fonctionnalités, cf. Présentation et extension des lecteurs. Utilisez-les pour vos réseaux.

HTKMLFReader est un lecteur de données qui lit les fichiers généralement associés aux tâches de reconnaissance vocale, et spécifiquement avec la suite d’outils Hidden Markov Model Toolkit (HTK). Le lecteur peut prendre comme entrée deux types de fichiers, une liste de fichiers de fonctionnalités connus dans l’analyseur HTK en tant que scp fichier (« script »), un fichier d’étiquette appelé mlf fichier (« fichier d’étiquette de modèle ») et un fichier d’archive.

HTKMLFReader s’appuie sur les formats définis par HTK des jeux de données. Nous vous recommandons donc de vous familiariser avec les concepts de base HTK à l’aide de la bibliothèque HTK.

Étant donné que CNTK pouvez être utilisé pour créer des réseaux avec une topologie arbitraire, y compris des réseaux avec plusieurs entrées et sorties, le HTKMLFReader peut traiter un ou plusieurs fichiers et MLF fichiersscp. Un exemple typique d’utilisation pour HTKMLFReader est le suivant :

    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"
        ]
    ]

Le HTKMLFReader a les paramètres de configuration suivants :

  • readMethod: méthode utilisée pour lire les fichiers de fonctionnalités en mémoire pour le traitement pendant l’entraînement réseau. Définir readMethod pour blockRandomize diviser les données en blocs volumineux, puis aléatoirer l’ordre des blocs, puis l’ordre des données dans le bloc. Les données de chaque bloc sont lues directement à partir des fichiers de fonctionnalités et libérées de LA RAM lorsqu’elles ne sont plus utilisées. L’option blockRandomize nécessite un fichier d’archive, décrit ci-dessous. En outre, comme décrit ci-dessous, lorsqu’elle est utilisée conjointement avec frameMode = "false" la blockRandomize méthode de lecture, aléatoire sur les énoncés, mais pas sur les images. Cela convient pour une utilisation avec des architectures récurrentes lors de la préservation de la nature séquentielle des exemples d’apprentissage souhaité. Une alternative est rollingWindow , qui lit dans tous les fichiers de fonctionnalités et les stocke sur le disque dans un fichier binaire temporaire volumineux. Les données sont ensuite aléatoires en exécutant une fenêtre propagée volumineuse sur les données de ce fichier et en randomisant les données dans la fenêtre. Cette méthode ne doit être utilisée que lorsqu’un fichier d’archive n’est pas disponible et fonctionne uniquement en mode frame. La méthode par défaut est blockRandomize.

  • pageFilePath: spécifiez l’emplacement où le fichier de page temporaire des fonctionnalités doit être stocké. Par défaut, il utilise le fichier temporaire fourni par le système.

  • randomize: spécifie la taille de la fenêtre de randomisation. CNTK utilise une fenêtre propagée de cette taille sur les données à partir de laquelle échantillonner. Seuls les exemples à l’intérieur de cette fenêtre propagée sont chargés à partir du disque et conservés en RAM uniquement tant que nécessaire. Le paramètre recommandé pour les corporax vocaux de taille de production est de 48 heures, c’est-à-dire spécifier 17280000. Le randomize paramètre comprend également deux valeurs spéciales : auto ou none. none désactive complètement la randomisation, utile pour l’évaluation ou l’écriture de données de sortie. auto lit l’intégralité du corpus en RAM, ce qui n’est généralement pas réalisable ou souhaitable pour les jeux de données de taille de production de plusieurs milliers d’heures de parole.

  • minibatchMode: partial ou full, cette option décide comment gérer le dernier minibatch s’il n’y a pas assez de cadres pour former un minibatch complet de la taille demandée. La valeur par défaut est partial, qui utilisera les images restantes dans un minibatch final plus petit de l’époque d’apprentissage. L’option full ne traite que les minibatches complets.

L’exemple ci-dessus contient deux sources de données traitées par le lecteur, des fonctionnalités, sous la forme d’une liste de fichiers de caractéristiques HTK et d’étiquettes, qui sont sous la forme d’un fichier MLF HTK. Les deux fonctionnalités et étiquettes correspondent aux nœuds du réseau de calcul, dans ce cas, les nœuds d’entrée et de sortie, respectivement. Notez que features et labels sont les noms par défaut utilisés par SimpleNetworkBuilder, mais si le réseau est conçu à l’aide du langage NDL (Network Description Language), tous les noms peuvent être utilisés, tant qu’ils ont chacun un nœud correspondant dans le réseau.

Pour spécifier des caractéristiques à valeur continue, par exemple les coefficients mfCC ou de filtre de fusion de journal, les paramètres suivants doivent être inclus dans le bloc de configuration :

  • scpFile: liste de fichiers à traiter. Les fichiers doivent être des fichiers compatibles HTK et peuvent être spécifiés au format standard ou « archive ». Les détails de l’utilisation d’une archive sont décrits ci-dessous.

  • dim: entier qui spécifie la dimension de vecteur de caractéristique complète avec la fenêtre de contexte souhaitée. Par exemple, si vous avez des caractéristiques de 72 dimensions (24 caractéristiques filterbank plus des coefficients delta et delta-delta) et que le réseau est conçu pour traiter une fenêtre de contexte de 11 images, la dimension spécifiée doit être 792. Notez que seules les fenêtres de contexte symétrique sont prises en charge.

Pour spécifier les étiquettes correspondantes, par exemple, les étiquettes phonème ou senone, un bloc de configuration doit être utilisé qui spécifie les paramètres suivants :

  • mlfFile: fichier de style mlf HTK qui contient les étiquettes de tous les énoncés spécifiés dans le scp fichier.

  • labelDim: cardinalité totale de l’ensemble d’étiquettes.

  • labelMappingFile: chemin d’accès à un fichier qui répertorie toutes les étiquettes affichées dans le mlf fichier, une par ligne.

Notez que plusieurs entrées et sorties peuvent être spécifiées à l’aide de blocs de lecteur supplémentaires pour les fonctionnalités lues à partir de fichiers répertoriés dans un scp fichier ou des étiquettes lues à partir d’un mlf fichier. Par exemple, dans un scénario d’apprentissage multi-tâche, où le réseau prédit à la fois l’identité de l’orateur et l’étiquette senone, l’utilisateur spécifie un bloc supplémentaire qui inclut un mlf fichier qui contient des étiquettes correspondant à l’identité de l’orateur. De même, pour un réseau avec plusieurs entrées, par exemple, les fonctionnalités MFCC et PLP, un bloc de fonctionnalités supplémentaire serait utilisé.

Pour les structures récurrentes, telles qu’un RNN ou un LSTM, il existe des options de configuration supplémentaires dans HTKMLFReader

  • frameMode: true ou false, si le lecteur doit aléatoirer les données au niveau de l’image ou au niveau de l’énoncé. true La valeur par défaut est la valeur frameMode par défaut et convient pour les réseaux d’entraînement sans aucune connexion temporelle. Pour les réseaux conçus pour apprendre des informations séquentielles, par exemple RNN, frameMode doivent être définis falsesur , ce qui signifie que les énoncés sont aléatoires, mais une séquence appropriée est conservée dans un énoncé. Notez que cela fonctionne uniquement avec la blockRandomize méthode de lecture.

  • nbruttsineachrecurrentiter: spécifie le nombre d’énoncés à traiter ensemble pour une formation efficace des réseaux avec des structures récurrentes. La valeur par défaut est 1, mais toute valeur inférieure à 20 à 30 entraîne des dégradations significatives de l’efficacité avec des GPU.

  • truncated : true ou false. Cela permet de tronquer BPTT.

Il est important de noter qu’il existe quelques petites différences entre les fichiers standard scp et mlf les fichiers utilisés dans HTK et ceux utilisés dans CNTK.

Plus particulièrement, le mlf fichier doit contenir les symboles réels utilisés pour la classification. Pour la reconnaissance vocale continue, cela signifie généralement des étiquettes correspondant aux snones (physicalHMMstates). Toutefois, HVite génère généralement un mlf pendant l’alignement forcé qui inclut uniquement les noms d’état HMM logiques. Par conséquent, pour l’utiliser mlf dans CNTK, il mlf doit être post-traité pour remplacer les noms d’état logique par les étiquettes sénone correspondantes, ou HVite doit être modifié afin qu’il écrit les étiquettes senone directement.

Les scp fichiers traités par HTKMLFReader peuvent être l’une des deux variétés : soit le format standard, où chaque ligne correspond à un fichier de caractéristiques physiques, soit au format alias, où chaque ligne contient un nom logique et fait référence à un segment d’un fichier physique éventuellement plus grand, défini par les images de début et de fin. Le nom logique est utilisé pour identifier les étiquettes correspondantes dans le mlf fichier. Même si les fichiers sont stockés individuellement, comme dans le premier cas, le format alias doit toujours être utilisé avec la blockRandomize méthode de lecture, car il utilise les informations sur les images de début et de fin dans le scp fichier pour déterminer les longueurs d’énoncé sans avoir à ouvrir les fichiers eux-mêmes. Dans ce cas, le cadre de début doit être égal à 0 et le cadre de fin doit être égal à la longueur de l’énoncé moins 1. En outre, pour plusieurs entrées et/ou sorties, le format alias doit également être utilisé afin que tous les scp fichiers et mlf fichiers aient leurs noms logiques en commun. Si la rollingWindow méthode de lecture est utilisée au lieu de , les informations d’image de début et de blockRandomizefin peuvent être omises.

Voici des exemples d’extraits de code et mlf de fichiers pour le corpus TIMIT approprié pour un réseau avec 2 entrées de scp fonctionnalité (dans ce cas, les fonctionnalités MFCC et PLP) et 1 sortie correspondant aux états phonèmes.

Le scp fichier répertorie tous les fichiers que vous devez traiter à l’aide de cette syntaxe :

id=pathname

Une extension propriétaire CNTK de ce format (introuvable dans le HTK d’origine) est que CNTK permet une syntaxe relative de nom de chemin plus pratique lorsque le scp fichier se trouve à côté des fonctionnalités :

id=.../filename

où ... fait référence au répertoire du scp fichier.

Le scp fichier des fonctionnalités MFCC contient des entrées telles que celles-ci.

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]

Le scp fichier des fonctionnalités PLP est similaire, mais pointe vers différents fichiers physiques. Notez que le nom racine logique dans les deux scp fichiers est le même.

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]

Un mlf fichier répertorie les étiquettes à l’aide de cette syntaxe :

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

...

.
"id"
labelBegin1 labelEnd1 label1
labelBegin2 labelEnd2 label1

...

.

...

Ici, nous avons une section terminée par . (point) par chaque fichier d’entrée, et une ligne par jeton dans chaque section. Les heures d’étiquette sont données dans une base temporelle 10e-7, et les trames vocales sont normalement 10e-2, de sorte que 5 zéros sont nécessaires pour être ajoutés à chaque index de temps.

Il est important de noter que CNTK lit uniquement trois premières colonnes* dans une section d’un mlp fichier et ignore le reste. Dans notre exemple mlf de fichier partage également le nom logique avec les deux fichiers « scp ». Voici l’extrait de code :

#!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

À présent, nous allons décrire les fichiers Archive , parfois également appelés chunk fichiers. CNTK utilise un concept de segment pour tous ses lecteurs, et cela signifie une chose absolument différente, afin d’éviter la confusion que nous n’utilisons pas le terme segment par rapport aux fichiers décrits ci-dessous, mais plutôt de les appeler Archives.

Les fichiers d’archive sont essentiellement des matrices principales de colonnes, float32avec un en-tête de 12 octets qui contient la taille de l’échantillon et le nombre d’échantillons. En règle générale, ils sont plus faciles à utiliser, en particulier en tant que début. L’en-tête attendu du fichier est défini par le biais de ce struct qui suit :

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

où :

  • sampsize est la taille d’un vecteur en octets (=4 * feature dimension);
  • sampkind est un identificateur numérique du type de fonctionnalité (MFCC, PLP, etc.). CNTK ignore cela. Si vos fichiers ne sont pas créés par HTK, vous pouvez simplement définir cette valeur sur 9 (USER). and
  • sampperioddoit être 100000 (CNTK ignore principalement cette valeur, sauf éventuellement pour les messages d’erreur).

Enfin, il est important de noter que dans la plupart des applications de reconnaissance vocale, les fonctionnalités à valeur continue sont utilisées comme entrées tandis que les étiquettes catégorielles discrètes sont utilisées comme sortie. Toutefois, htKMLFReader associe simplement les données aux noms de nœud et est indépendant de la façon dont ces données sont utilisées. Par exemple, un fichier approprié mlf d’étiquettes d’identité de l’orateur peut être utilisé pour générer un vecteur à chaud des fonctionnalités d’identité de l’orateur comme entrée sur le réseau.