Lector de BrainScript HTKMLF

Advertencia

HTKMLFReader está obsoleto y se está reemplazando por HTK MLF y deserializadores de características, cf. Descripción y extensión de lectores. Por favor, úselos para sus redes.

HTKMLFReader es un lector de datos que lee archivos asociados normalmente con tareas de reconocimiento de voz y, específicamente, con el conjunto de herramientas hidden markov Model Toolkit (HTK). El lector puede tomar como entrada dos tipos de archivos, una lista de archivos de características conocidos en el análisis de HTK como un scp archivo (archivo "script"), un archivo de etiqueta conocido como mlf archivo ("archivo de etiqueta de modelo") y un archivo de archivo.

HTKMLFReader se basa en formatos definidos por HTK de conjuntos de datos, por lo que se recomienda familiarizarse con los conceptos básicos de HTK mediante, por ejemplo, HTK Book.

Dado que CNTK se pueden usar para crear redes con topología arbitraria, incluidas las redes con varias entradas y salidas, HTKMLFReader puede procesar uno o varios scp archivos y MLF . Un ejemplo típico de uso para HTKMLFReader es el siguiente:

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

HTKMLFReader tiene los siguientes parámetros de configuración:

• readMethod: el método utilizado para leer los archivos de características en la memoria para su procesamiento durante el entrenamiento de red. blockRandomize Si se establece readMethod en , los datos se dividirán en bloques grandes y, a continuación, se aleatoriará el orden de los bloques y, a continuación, el orden de los datos dentro del bloque. Los datos de cada bloque se leen directamente desde los archivos de características y se liberan desde la RAM cuando ya no se usan. La blockRandomize opción requiere un archivo de archivo, que se describe a continuación. Además, como se describe a continuación, cuando se usa junto con frameMode = "false" el blockRandomize método read, se aleatorizará sobre expresiones, pero no los fotogramas. Esto es adecuado para su uso con arquitecturas recurrentes al conservar la naturaleza secuencial de los ejemplos de entrenamiento. Una alternativa es rollingWindow , que lee todos los archivos de características y los almacena en el disco en un archivo binario temporal grande. A continuación, los datos se aleatorizan mediante la ejecución de una ventana gradual grande sobre los datos de este archivo y la selección aleatoria de los datos dentro de la ventana. Este método solo debe usarse cuando un archivo de archivo no está disponible y solo funciona en modo de marco. El método predeterminado es blockRandomize.

• pageFilePath: especifique dónde se debe almacenar el archivo de página temporal de las características. De forma predeterminada, usará el archivo temporal proporcionado por el sistema.

• randomize: especifica el tamaño de la ventana de selección aleatoria. CNTK usa una ventana gradual de este tamaño sobre los datos desde los que se va a muestrear. Solo las muestras dentro de esta ventana gradual se cargan desde el disco y se mantienen en RAM solo mientras sea necesario. La configuración recomendada para speech corpora de tamaño de producción es de 48 horas, es decir, especifique 17280000. El randomize parámetro también entiende dos valores especiales: auto o none. none deshabilita la selección aleatoria por completo, útil para la evaluación o la escritura de datos de salida. auto leerá todo el corpus en RAM, que normalmente no es factible o deseable para los conjuntos de datos de tamaño de producción de varias miles de horas de voz.

• minibatchMode: partial o full, esta opción decide cómo controlar el último minibatch si no hay suficientes marcos para formar un minibatch completo del tamaño solicitado. El valor predeterminado es partial, que usará los fotogramas restantes en un minibatch final más pequeño de la época de entrenamiento. La full opción solo procesará minibatches completos.

El ejemplo anterior tiene dos orígenes de datos que el lector procesa, características, en forma de una lista de archivos de características HTK y etiquetas, que están en forma de un archivo MLF de HTK. Tanto las características como las etiquetas corresponden a los nodos de la red computacional, en este caso, los nodos de entrada y salida, respectivamente. Tenga en cuenta que features y labels son los nombres predeterminados usados por SimpleNetworkBuilder, pero si la red está diseñada mediante el lenguaje de descripción de red (NDL), se pueden usar nombres, siempre y cuando cada uno tenga un nodo correspondiente en la red.

Para especificar características con valores continuos, por ejemplo, los coeficientes de filtro de mel de registro o MFCC, los parámetros siguientes deben incluirse en un bloque de configuración:

• scpFile: una lista de archivos que se van a procesar. Los archivos deben ser archivos compatibles con HTK y se pueden especificar en formato estándar o en formato "archivo". A continuación se describen los detalles del uso de un archivo.

• dim: entero que especifica la dimensión de vector de característica completa con la ventana de contexto deseada. Por ejemplo, si tenía 72 características dimensionales (características de filtro de 24 dimensiones más coeficientes delta y delta-delta) y la red está diseñada para procesar una ventana de contexto de 11 fotogramas, la dimensión especificada debe ser 792. Tenga en cuenta que solo se admiten ventanas de contexto simétricas.

Para especificar las etiquetas correspondientes, por ejemplo, las etiquetas phoneme o senone, se debe usar un bloque de configuración que especifique los parámetros siguientes:

• mlfFile: un archivo de estilo mlf HTK que contiene las etiquetas de todas las expresiones especificadas en el scp archivo.

• labelDim: cardinalidad total del conjunto de etiquetas.

• labelMappingFile: la ruta de acceso a un archivo que enumera todas las etiquetas que se ven en el mlf archivo, una por línea.

Tenga en cuenta que se pueden especificar varias entradas y salidas mediante bloques de lector adicionales para las características leídas de los archivos enumerados en un scp archivo o etiquetas leídos de un mlf archivo. Por ejemplo, en un escenario de aprendizaje de varias tareas, donde la red predice la identidad del hablante y la etiqueta senone, el usuario especificaría un bloque adicional que incluye un mlf archivo que contiene etiquetas correspondientes sobre la identidad del hablante. De forma similar, para una red con varias entradas, por ejemplo, características MFCC y PLP, se usaría un bloque de características adicional.

En el caso de las estructuras recurrentes, como un RNN o un LSTM, hay opciones de configuración adicionales en HTKMLFReader.

• frameMode: true o false, si el lector debe aleatorizar los datos en el nivel de fotograma o en el nivel de expresión. Establecer frameMode en true es el valor predeterminado y es adecuado para las redes de entrenamiento sin ninguna conexión temporal. En el caso de las redes diseñadas para aprender información secuencial, por ejemplo, RNN, frameMode debe establecerse falseen , lo que significa que las expresiones se aleatorizarán, pero la secuencia adecuada se mantiene dentro de una expresión. Tenga en cuenta que esto solo funciona con el blockRandomize método read.

• nbruttsineachrecurrentiter: especifica el número de expresiones que se van a procesar conjuntamente para un entrenamiento eficaz de redes con estructuras recurrentes. El valor predeterminado es 1, pero cualquier valor inferior a 20 a 30 provocará importantes degradaciones de eficiencia con GPU.

• truncated: true o false. Esto habilita BPTT truncado.

Es importante tener en cuenta que hay algunas pequeñas diferencias entre los archivos estándar scp y mlf usados en HTK y los usados en CNTK.

En particular, el mlf archivo debe contener los símbolos reales usados para la clasificación. Para el reconocimiento continuo de voz, normalmente significa etiquetas correspondientes a las senones (physicalHMMstates). Sin embargo, HVite normalmente genera una mlf durante la alineación forzada que incluye solo los nombres de estado de HMM lógicos. Por lo tanto, para usarlo mlf en CNTK, debe mlf procesarse después de procesarse para reemplazar los nombres de estado lógicos por las etiquetas senone correspondientes, o HVite debe modificarse para que escriba directamente las etiquetas senone.

Los scp archivos procesados por HTKMLFReader pueden ser una de las dos variedades: el formato estándar, donde cada línea corresponde a un archivo de características físicos o al formato con alias, donde cada línea contiene un nombre lógico y hace referencia a un segmento de un archivo físico posiblemente mayor, definido por marcos inicial y final. El nombre lógico se usa para identificar las etiquetas correspondientes en el mlf archivo. Incluso si los archivos se almacenan individualmente, como en el primer caso, el formato con alias siempre debe usarse con el blockRandomize método read, ya que usa la información sobre los marcos iniciales y finales del scp archivo para determinar las longitudes de expresión sin tener que abrir los propios archivos. En este caso, el marco inicial debe ser 0 y el marco final debe ser igual a la longitud de la expresión menos 1. Además, para varias entradas o salidas, también se debe usar el formato con alias para que todos los scp archivos y mlf archivos tengan sus nombres lógicos en común. Si se usa el rollingWindow método read en lugar de blockRandomize, se puede omitir la información del marco inicial y final.

Estos son fragmentos de código de ejemplo de scp y mlf archivos para el corpus de TIMIT para que sea adecuado para una red con 2 entradas de características (en este caso, características MFCC y PLP) y 1 salida correspondiente a estados de phoneme.

El scp archivo enumera todos los archivos que se van a procesar con esta sintaxis:

id=pathname

Una extensión de propiedad CNTK de este formato (que no se encuentra en el HTK original) es que CNTK permite una sintaxis pathname relativa más cómoda cuando el scp archivo se encuentra junto a las características:

id=.../filename

donde ... hace referencia al directorio del scp archivo.

El scp archivo de las características MFCC contiene entradas como estas.

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]

El scp archivo de las características de PLP es similar, pero apunta a archivos físicos diferentes. Tenga en cuenta que el nombre raíz lógico en ambos scp archivos es el mismo.

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 archivo enumera las etiquetas con esta sintaxis:

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

...

.
"id"
labelBegin1 labelEnd1 label1
labelBegin2 labelEnd2 label1

...

.

...

Aquí tenemos una sección terminada con . (punto) por cada archivo de entrada y una línea por token dentro de cada sección. Los tiempos de etiqueta se proporcionan en una base temporal de y los fotogramas de 10e-7voz son normalmente 10e-2, por lo que se necesitan 5 ceros para anexarse a cada índice de tiempo.

Es importante tener en cuenta que CNTK lee solo las tres primeras columnas* dentro de una sección de un mlp archivo y omite el resto. En nuestro archivo de ejemplo mlf también se comparte el nombre lógico con los archivos """scp". Este es el fragmento de código:

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

Ahora describiremos archivos de archivo , que a veces también se conocen como chunk archivos. CNTK usa un concepto de fragmento para todos sus lectores y significa una cosa absolutamente diferente, por lo que para evitar la confusión que no usamos el término fragmento en relación con los archivos descritos a continuación, sino llamarlos Archives.

Los archivos de archivo son básicamente matrices principales de columna de , con un encabezado de float3212 bytes que contiene el tamaño de la muestra y el número de muestras. Por lo general, son más fáciles de usar, especialmente como inicio. El encabezado esperado del archivo se define a través de lo struct siguiente:

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

donde:

• sampsize es el tamaño de un vector en bytes (=4 * feature dimension);
• sampkind es un identificador numérico del tipo de característica (MFCC, PLP, etc.). CNTK omite esto. Si HTK no crea los archivos, puede establecerlo en 9 (USUARIO). And
• sampperioddebe ser 100000 (CNTK omite principalmente este valor, excepto posiblemente para los mensajes de error).

Por último, es importante tener en cuenta que en la mayoría de las aplicaciones de reconocimiento de voz, las características con valores continuos se usan como entradas mientras se usan etiquetas de categorías discretas como salida. Sin embargo, el HTKMLFReader simplemente asocia los datos con los nombres de nodo y es independiente de cómo se usan estos datos. Por ejemplo, se podría usar un archivo adecuado mlf de etiquetas de identidad del hablante para generar un vector activo de características de identidad del hablante como entrada a la red.