Lettore BRAINScript HTKMLF

HTKMLFReader è un lettore di dati che legge i file in genere associati alle attività di riconoscimento vocale e in particolare con la suite di strumenti di Toolkit (HTK) Hidden Markov Model. Il lettore può accettare come input due tipi di file, un elenco di file di funzionalità noti nella parlance DI HTK come file ("script"), un file di etichetta noto come scpmlf file ("file etichetta modello") e un file di archivio.

HTKMLFReader si basa su formati definiti HTK dei set di dati, quindi è consigliabile acquisire familiarità con le nozioni di base di HTK usando, ad esempio HTK Book.

Poiché CNTK può essere usato per creare reti con topologia arbitraria, incluse le reti con più input e output, htKMLFReader può elaborare uno o più scp file eMLF. Un esempio tipico di utilizzo per HTKMLFReader è il seguente:

    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 ha i parametri di configurazione seguenti:

• readMethod: metodo usato per leggere i file di funzionalità in memoria per l'elaborazione durante il training di rete. L'impostazione readMethod per blockRandomize suddividere i dati in blocchi di grandi dimensioni e quindi casualizzare l'ordine dei blocchi e quindi l'ordine dei dati all'interno del blocco. I dati in ogni blocco vengono letti direttamente dai file di funzionalità e rilasciati dalla RAM quando non vengono più usati. L'opzione blockRandomize richiede un file di archivio, descritto di seguito. Inoltre, come descritto di seguito, quando usato insieme al frameMode = "false"blockRandomize metodo di lettura genererà casualmente le espressioni, ma non i fotogrammi. Ciò è appropriato per l'uso con architetture ricorrenti quando si conserva la natura sequenziale degli esempi di training è desiderato. Un'alternativa è rollingWindow , che legge in tutti i file di funzionalità e li archivia su disco in un file binario temporaneo di grandi dimensioni. I dati vengono quindi casualizzati eseguendo una finestra di rollback di grandi dimensioni sui dati di questo file e ridimensionando casualmente i dati all'interno della finestra. Questo metodo deve essere usato solo quando un file di archivio non è disponibile e funziona solo in modalità frame. Il metodo predefinito è blockRandomize.

• pageFilePath: specificare dove deve essere archiviato il file di pagina temporaneo delle funzionalità. Per impostazione predefinita, userà il file temp fornito dal sistema.

• randomize: specifica le dimensioni della finestra di casualizzazione. CNTK usa una finestra in sequenza di queste dimensioni rispetto ai dati da cui eseguire l'esempio. Solo gli esempi all'interno di questa finestra in sequenza vengono caricati dal disco e mantenuti in RAM solo se necessario. L'impostazione consigliata per il corpo vocale di dimensioni di produzione è di 48 ore, ad esempio specificare 17280000. Il randomize parametro comprende anche due valori speciali: auto o none. none disabilita completamente la casualizzazione, utile per la valutazione o la scrittura di dati di output. auto leggerà l'intero corpus in RAM, che in genere non è fattibile o auspicabile per set di dati di dimensioni di produzione di diverse migliaia di ore di riconoscimento vocale.

• minibatchMode: partial o full, questa opzione decide come gestire l'ultimo minibatch se non sono presenti fotogrammi sufficienti per formare un minibatch completo delle dimensioni richieste. Il valore predefinito è partial, che userà i fotogrammi rimanenti in un minibatch finale più piccolo dell'epoca di training. L'opzione full elabora solo minibatches complete.

L'esempio precedente include due origini di dati elaborate dal lettore, le funzionalità, sotto forma di un elenco di file di funzionalità HTK e etichette, che sono sotto forma di un file MLF HTK. Entrambe le funzionalità e le etichette corrispondono ai nodi nella rete di calcolo, in questo caso, rispettivamente i nodi di input e output. Si noti che features e labels sono i nomi predefiniti usati dal SimpleNetworkBuilder, ma se la rete è progettata usando il linguaggio NDL (Network Description Language), tutti i nomi possono essere usati, purché ognuno disponga di un nodo corrispondente nella rete.

Per specificare le funzionalità con valori continui, ad esempio i coefficienti di filtro melbank di MFCC o log, i parametri seguenti devono essere inclusi in un blocco di configurazione:

• scpFile: elenco di file da elaborare. I file devono essere compatibili con HTK e possono essere specificati in formato standard o "archivio". Di seguito sono descritti i dettagli dell'uso di un archivio.

• dim: intero che specifica la dimensione vettore di funzionalità completa con la finestra di contesto desiderata. Ad esempio, se si dispone di 72 caratteristiche dimensionali (24-dimensional filterbank caratteristiche più coefficienti delta e delta-delta) e la rete è progettata per elaborare una finestra di contesto di 11 fotogrammi, la dimensione specificata deve essere 792. Si noti che sono supportate solo finestre di contesto simmetriche.

Per specificare le etichette corrispondenti, ad esempio le etichette phoneme o senone, è necessario usare un blocco di configurazione che specifica i parametri seguenti:

• mlfFile: un file in stile mlf HTK che contiene le etichette per tutte le espressioni specificate nel scp file.

• labelDim: la cardinalità totale del set di etichette.

• labelMappingFile: percorso di un file che elenca tutte le etichette visualizzate nel mlf file, una per riga.

Si noti che è possibile specificare più input e output usando blocchi di lettura aggiuntivi per le funzionalità letti dai file elencati in un file o etichette letti da un scpmlf file. Ad esempio, in uno scenario di apprendimento multi-attività, in cui la rete stimava sia l'identità dell'altoparlante che l'etichetta senone, l'utente specifica un blocco aggiuntivo che include un mlf file che contiene etichette corrispondenti all'identità dell'altoparlante. Analogamente, per una rete con più input, ad esempio le funzionalità MFCC e PLP, verrà usato un blocco di funzionalità aggiuntivo.

Per le strutture ricorrenti, ad esempio un RNN o un LSTM, sono disponibili opzioni di configurazione aggiuntive in HTKMLFReader

• frameMode: true o false, se il lettore deve casualizzare i dati a livello di frame o il livello di espressione. L'impostazione su true è l'impostazione frameMode predefinita ed è appropriata per le reti di training senza connessioni temporali. Per le reti progettate per apprendere informazioni sequenziali, ad esempio RNN, deve essere impostata su false, frameMode il che significa che le espressioni vengono casualizzate ma la sequenza appropriata viene mantenuta all'interno di un'espressione. Si noti che questo funziona solo con il blockRandomize metodo di lettura.

• nbruttsineachrecurrentiter: specifica il numero di espressioni da elaborare insieme per la formazione efficiente delle reti con strutture ricorrenti. Il valore predefinito è 1, ma qualsiasi valore inferiore a 20-30 causerà una riduzione significativa dell'efficienza con GPU.

• truncated: true o false. Ciò consente di troncare BPTT.

È importante notare che esistono alcune piccole differenze tra lo standard scp e mlf i file usati in HTK e quelli usati in CNTK.

In particolare, il mlf file deve contenere i simboli effettivi usati per la classificazione. Per il riconoscimento vocale continuo, questo significa in genere etichette corrispondenti ai senoni (fisiciHMMstates). Tuttavia, HVite genera in genere un mlf oggetto durante l'allineamento forzato che include solo i nomi di stato HMM logici. Pertanto, per usarlo mlf in CNTK, è mlf necessario eseguire la post-elaborazione per sostituire i nomi di stato logici con le etichette senone corrispondenti o HVite deve essere modificato in modo da scrivere direttamente le etichette senone.

I scp file elaborati da HTKMLFReader possono essere una delle due varietà: il formato standard, in cui ogni riga corrisponde a un file di funzionalità fisico o al formato aliased, in cui ogni riga contiene un nome logico e fa riferimento a un segmento di un file fisico probabilmente più grande, definito da fotogrammi iniziali e finali. Il nome logico viene usato per identificare le etichette corrispondenti nel mlf file. Anche se i file vengono archiviati singolarmente, come nel primo caso, il formato aliased deve essere sempre usato con il blockRandomize metodo di lettura, poiché usa le informazioni relative ai fotogrammi iniziali e finali nel scp file per determinare le lunghezze delle espressioni senza dover aprire i file stessi. In questo caso, la cornice iniziale deve essere 0 e il frame finale deve essere uguale alla lunghezza dell'espressione meno 1. Inoltre, per più input e/o output, il formato aliasto deve essere usato anche in modo che tutti i file e mlf i scp file abbiano i nomi logici in comune. Se il rollingWindow metodo di blockRandomizelettura viene usato anziché , le informazioni sul frame iniziale e finale possono essere omesse.

Di seguito sono riportati frammenti di esempio di file e per il corpus TIMIT per una rete con 2 input di scp funzionalità (in questo caso, funzionalità MFCC e mlf PLP) e 1 output corrispondente agli stati fonemi.

Il scp file elenca tutti i file da elaborare usando questa sintassi:

id=pathname

Un'estensione proprietaria di CNTK di questo formato (non trovata nell'originale HTK) è che CNTK consente una sintassi del nome percorso più conveniente quando il scp file si trova accanto alle funzionalità:

id=.../filename

dove ... fa riferimento alla directory del scp file.

Il scp file per le funzionalità MFCC contiene voci come queste.

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]

Il scp file per le funzionalità PLP è simile ma punta a file fisici diversi. Si noti che il nome radice logico in entrambi scp i file è lo stesso.

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 file elenca le etichette usando questa sintassi:

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

...

.
"id"
labelBegin1 labelEnd1 label1
labelBegin2 labelEnd2 label1

...

.

...

In questa sezione è stata terminata una sezione con . (punto) per ogni file di input e una riga per ogni token all'interno di ogni sezione. I tempi di etichetta vengono assegnati in base temporale di 10e-7e i fotogrammi vocali sono normalmente 10e-2, quindi sono necessari 5 zero per accodare a ogni indice.

È importante notare che CNTK legge solo le prime tre colonne* all'interno di una sezione di un mlp file e ignora il resto. Nel file di esempio mlf viene condiviso anche il nome logico con entrambi i file ''scp'. Ecco il frammento di codice:

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

Ora verranno descritti i file di archiviazione , a volte noti anche come chunk file. CNTK usa un concetto di blocchi per tutti i suoi lettori e significa una cosa assolutamente diversa, quindi per evitare la confusione che non usiamo il termine blocchi in relazione ai file descritti di seguito, ma piuttosto chiamarli Archivi.

I file di archiviazione sono fondamentalmente matrici principali di colonna di float32, con un'intestazione di 12 byte che contiene le dimensioni di esempio e il numero di esempi. In genere sono più facili da usare, soprattutto come inizio. L'intestazione prevista del file viene definita tramite la struct seguente:

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

dove:

• sampsize è la dimensione di un vettore in byte (=4 * feature dimension);
• sampkind è un identificatore numerico del tipo di funzionalità (MFCC, PLP e così via). CNTK ignora questa operazione. Se i file non vengono creati da HTK, è possibile impostarlo su 9 (USER). e
• sampperioddeve essere 100000 (CNTK ignora principalmente questo valore, tranne eventualmente per i messaggi di errore).

Infine, è importante notare che nella maggior parte delle applicazioni di riconoscimento vocale, le funzionalità con valori continui vengono usate come input mentre le etichette categoriche discrete vengono usate come output. Tuttavia, HTKMLFReader associa solo i dati ai nomi dei nodi ed è agnostico in base alla modalità di utilizzo dei dati. Ad esempio, un file appropriato mlf di etichette di identità del parlante può essere usato per generare un vettore one-hot delle funzionalità di identità dell'altoparlante come input alla rete.