Contents

A lattice file contains a set of lattices in FST format. It is an ASCII file that is in many respects similar to corpus and segmentation files. Lattices may contain information of all kind (word, phone, template, ... ).

Keys

DATA should be set to LATTICE
TYPE will standard be STRING
DIM1 shows the number of lines in the data section
DIM2 shows the number of lattices in the file

Data

A file may contain multiple lattices. Each lattice starts with an information line

File <fname> [btime] [etime] [extra_info ... ]

This initialization line is followed by lines describing the lattice in FST format. Each line may contain any of the following:

O <node_nr> <iframe> [extra_info ... ]
A <bnode> <enode> <isymbol> [score] [osymbol] [options .. ]
C <node_nr>

in which

'O' opens a node
'A' draws an arc
'C' closes a node
btime, etime are begin and endtime of the lattice (in frames)
iframe is the frame number wrt. the beginning of the lattice
bnode , enode are begin and endnode of an arc
isymbol, osymbol are the input and output symbols on the FST (represented by their index in a dictionary file)
extra_info, options: are optional arguments that are passed on to further processing.
When creating lattices (word or other) SPRAAK can add the underlying phone/state segmentation (as stored in the back-trace) as extra info to the lattice. The phone segmentation has the following format:
```
<cdphone>(<nfr>)...
```
The state segmentation has the following format:
```
<cdphone>#<istate>(<nfr>)...
```
with

<cdphone>

the name of the context dependent phone (as found in the .cd file)

<istate>

the state index (base0), cf. segmentation files

<nfr>

number of frames assigned to this phone/state

Examples:
```
s(12)t(4)A(15)r(7)t(5)

s#0(4)s#1(4)s#2(4)t#0(1)t#1(1)t#2(2)A#0(5)A#1(5)A#2(5)r#0(2)r#1(2)r#2(3)t#0(1)t#1(2)t#2(1)
```

Nodes have following properties:

They must be opened before usage and closed after.
The assigned node number is arbitrary, not necessarily sequential.
Negative numbers are terminal nodes with a special meaning
- '-1' is a normal end_node for both LM and the acoustic context (context-dependent phone that has silence as a right context)
- '-2' indicates an LM end state but without matching acoustic context (context-dependent phone that has no silence as a right context)
- '-3' indicates a non LM end state but with a matching acoustic context (context-dependent phone that has silence as a right context)
- '-4' is a very abnormal termination; neither LM nor AM expect an end at this point

More information on lattice files and processing is found in wlat_master.c

Example

.spr
DATA    LATTICE
TYPE    STRING
DIM1    1905
DIM2    1 
SYMBOLTYPE      LITERAL
#
File: /data/wsj/sam_16k/wsj0/si_dt_20/050/050c0301.wv1 0 810
O -1
O 0 0
O 33 71
A 0 33 0 76.2348
O 25 69
A 0 25 0 74.518
O 20 71
A 0 20 0 76.2348
O 16 72
A 0 16 0 75.8263
O 8 70
A 0 8 0 75.4815
O 6 70
A 0 6 0 75.4815
...
A 25 28 13 5.7582
O 26 77
A 25 26 13 5.04793
C 25
O 4 72
A 3 4 5 -7.97319
C 3
O 2 72
A 1 2 37 -13.2876
...

Tools

For lattice operations cfr. Lattice processing modules .

The SPRAAK lattices can be processed with external FST tools (eg. MIT toolbox); for conversion instructions see ...

Extensions

Due to demands from ongoing research projects, both the lattice tools and corresponding file formats have been used in a 'loose manner'; i.e. the above standards aren't strictly followed in all tools, especially w.r.t. to the A(rc) descriptions:

There should be no deviation from the standard format for the first 5 fields; i.e. if there are more than 5 fields used, then the first 5 should always have there assigned standard meaning.
The input/output symbols may be either encoded as indices are printed out in full form.
The output symbol field may not be present, making it's FST representation incomplete, which may cause failure on certain tools.
Some examples are given below:
- Template Lattices
  Template lattices contain template identity and corresponding DTW-score as extra information. The input symbol (typically a phone) is stored as a string instead of an index.
```
A <bnode> <enode> <phone> <HMM_score> <DTW_SCORE> <template_phone> <template_id> [extra_info]
```
  in which the template_phone may be a context-dependent variant and the template_id is a unique identifier in the template database.
- Flat Template Lattices
  The flat template lattices ignores the arcs context (each time frame corresponds with one node only) making the rescoring more efficient since each distinct arc only occurs once. Removing the 'context' creates lattices that encode far more paths (all possible combinations of phones) than what the decoder stored during recognition. These 'flat' template lattices have the following format:
```
A <bnode> <enode> <phone> <HMM_score> <btime> <etime> <template_phone>
```
  in which the template_phone may be a context-dependent variant and btime and etime are frame numbers (base0). The input symbol (typically a phone) is stored as a string instead of an index.

Bugs and Limitations

Standardization is lacking in many ways:

The header keys shown here are "recommended", but are not consistently used
There are no default extensions used for the various extensions
The nomeclatures 'lattice' and 'graph' are used along each other without clear difference in meaning
There are a lot more scripts around at ESAT' than the ones distributed with the standard release of SPRAAK. However, these must be considered 'work in progress'.