The names of label files in HTK are invariably reconstructed from an existing data file name and this means that the file names used to access label files can be partial or full path names in which the path has been constructed either from the path of the corresponding data file or by direct specification via the -L option. These path names are retained in the MLF search which proceeds as follows. The given label file specification ../d3/d2/d1/name is matched against each pattern in the MLF. If a pattern matches, then either the named subdirectory is searched or an immediate definition is loaded. Pattern matching continues in this way until a definition is found. If no pattern matches then an attempt is made to open ../d3/d2/d1/name directly. If this fails an error is reported.
The search of a sub-directory proceeds as follows. In simple search mode indicated by ->, the file name must occur directly in the sub-directory. In full search mode indicated by =>, the files name, d1/name, d2/d1/name, etc. are searched for in that order. This full search allows a hierarchy of label files to be constructed which mirrors a hierarchy of data files (see Example 4 below).
Hashing is performed when the label file specification is either a full path name or in the form */file so in these cases the search is very fast. Any other use of metacharacters invokes a linear search with a full and relatively slow pattern match at each step. Note that all tools which generate label files have a -l option which is used to define the output directory in which to store individual label files. When outputting master label files, the -l option can be used to define the path in the output label file specifications. In particular, setting the option -l '*' causes the form */file to be generated.