intro.vrme

来自「speech signal process tools」· VRME 代码 · 共 1,038 行 · 第 1/3 页

	%plotspec data.spec 

.ft LR
.fi
.lp
The first command causes the reflection coefficients computed from
data frames in the SD file data.sd to be placed in the FEA_ANA file
data.fana.  The second command computes spectra for each set of
reflection coefficients and puts the results in the SPEC file
data.spec.  The third command plots all the spectra on the screen
using a single set of axes.  If there is no need to retain the
intermediate FEA_ANA and FEA_SPEC files, one could do the following
instead:
.nf
.ft CW

	%refcof data.sd \- | me_spec \- \- | plotspec \-
 
.ft LR
.fi
.lp
Similarly, if only the FEA_SPEC file is wanted, the first two commands 
could be replaced by:
.nf
.ft CW

	%refcof data.sd \- | me_spec \- data.spec

.ft LR
.fi
.lp
An important consideration in using pipes with ESPS programs is that
record keeping is not compromised.  Thus, the file header for
data.spec in the command above will include the header of the 
file produced by \fIrefcof\fP (i.e., the header of data.fana in 
the first version of this sequence of operations, above).  
For a more detailed example, see.
.[
ESPS record keeping
.]
.sh 1 "PARAMETERS FOR ESPS PROGRAMS"
.lp
Signal processing programs often are affected by a large set of input
parameters.  Rather than requiring that all parameters be specified
on the command line, which is not only error-prone but leads to
ridiculously-long command lines, ESPS provides a mechanism that uses
a distinguished ASCII file called the parameter file.  Parameters are
specified in this file using a C-like syntax that allows the user
either to provide specific values for the parameters within the
parameter file or to have the program prompt the user for their
values at run time.  The default convention for the parameter file
name is "params" in the current directory, but for all programs this
can be changed using the \fB\-P\fP command-line option.
.lp
For example, \fIrefcof\fP (1\-\s-1ESPS\s+1) computes reflection
coefficients for fixed-length segments of sampled-data.  To do so it
requires parameters that specify the starting point, the number of points
to analyze, the frame length, and the order of the analysis.  The call
.nf
.ft CW

    %refcof \-P params.3 john.sd john.fana

.ft LR
.fi
indicates that reflection coefficients are to be computed for data in
the file john.sd using parameter values in the file params.3 (the
nuser may be prompted for some of the values), and that the results
are to be written to the file john.fana.  
.lp
The ESPS distribution contains a "default" parameter file for 
every ESPS program that processes a parameter file.  Easy access
to these parameter files is provided by \fIeparam\fP (1\-\s-1ESPS\s+1), 
which invokes any given ESPS program with its default parameter file.  
The default parameter files are written to prompt for all values so 
you can override each default.  Here is an example of running
\fIvqdes\fP (1\-\s-1ESPS\s+1) by means of \fIeparam\fP:
.nf
.ft CW

    %eparam vqdes rc.fana rc.cbk
    max_iter [100]: 
    fea_dim [10]: 
    vq_size [32]: 16
    fea_field [spec_param]: 
    cbk_type [MISC]: 
    cbk_struct [FULL_SEARCH]: 
    conv_ratio [0.050000]: .01
    dist_type [MSE]: 
    %

.ft LR
.fi
.lp
Here, the defaults were taken for all parameters but 
.ft CW
vq_size
.ft LR
and
.ft CW
conv_ratio.
.ft LR
.lp
The ESPS parameter file provides a convenient means for users to
communicate parameter values to signal processing programs.  In many
signal processing applications, however, there is also a need for one
program to communicate parameter values to another program that is run
subsequently.  In ESPS, this need is met by the ESPS common file.  
If the common file exists and was written more recently than the 
parameter file, then parameter values in the common file may supersede 
those in the parameter file (for a detailed discussion of 
the conditions, see.
.]]
ESPS parameters
.]])
Thus, a program can write a value into the common file and have that value
be used by a subsequent program.  For example, suppose that
.i plotsd
(1\-\s-1ESPS\s+1) is used to plot the first 10,000 points of an SD
file in a graphics window:
.nf
.ft CW
 
	%plotsd \-p1:10000 file.sd

.ft LR 
.fi
After this plot is made, the user can run \fIrange\fP
(1\-\s-1ESPS\s+1) to select a portion of the displayed data (using the
mouse).  When \fIrange\fP exits, it writes the selected range and the
filename "file.sd" into the ESPS common file.  If the user then runs
.nf
.ft CW
 
	%plotsd

.ft LR
.fi
(i.e., without any command line options), the selected range of the same
file will be displayed.  Similarly, if the user runs 
.nf
.ft CW

	%play

.ft LR
.fi
(again, without options), the selected range of the same file will be 
played out over the system D/A converter.  
.lp
The default ESPS common file is ".espscom " in the user's home
directory, but this default can be changed by using the \s-1UNIX\s+1
shell environment variable ESPSCOM.  Thus, for csh users, 
.nf
.ft CW
 
	%setenv ESPSCOM /u/shore/common.3

.ft LR
.fi
resets the common file to /u/shore/common.3.  This facility for changing
the common file is needed so that users can prepare and run several shell
scripts without having them interfere with each other.  Common processing
can also be turned off entirely by setting the \s-1UNIX\s+1 environment
variable USE_ESPS_COMMON to "off".  By default, ESPS provides detailed
user-feedback about the parameter values taken from the parameter and
common files.  The verbosity of the resulting messages is controlled
by the \s-1UNIX\s+1 environment variable ESPS_VERBOSE.  The default 
value is 3; a value of 0 inhibits all messages.  
.lp
To summarize, ESPS programs get their parameters from three sources:
.SM .5i
.ip \(bu 3
the ESPS parameter file
.ip \(bu 3
the ESPS common file
.ip \(bu 3
command line options
.RM
.lp
In general, if a command-line option is available to set a parameter
value, its use overrides any of the other mechanisms by which programs
get parameter values.  For details about ESPS parameter and 
common file processing see.
.[
ESPS parameters
.]
.sh 1 "CONVERSIONS TO OR FROM ESPS FILES"
.lp
Most ESPS users have occasion to import non-ESPS data into ESPS files,
and also to export data from ESPS files for use by non-ESPS programs.
Here is a list of the ESPS programs that are the main utilities for
converting back and forth between ESPS files and ASCII or headerless
binary data:
.sp .5
.nf
.ta 1.25i

  \fIaddfea\fP \-	adds a new FEA file field based  on ASCII data

  \fIaddfeahd\fP \-	adds an ESPS feature file header to non-ESPS binary or ASCII data

  \fIaddgen\fP \-	adds a generic header item to an existing  nor new ESPS file header

  \fIbhd\fP \-	behead an ESPS file

  \fIbtosps\fP \-	convert binary sampled data file to an ESPS FEA_SD file

  \fIcomment\fP \-	displays or appends to comment field in ESPS file headers

  \fIdemux\fP \-	(demultiplex) extract real or complex channels from a FEA_SD file

  \fIeman\fP \-	displays or prints ESPS manual pages

  \fIeparam\fP \-	run an ESPS program with parameter prompts

  \fIesps2mu\fP \-	convert an ESPS sampled data file to a headerless mu-encoded file

  \fIfea2mat\fP \-	converts FEA to MATLAB .mat 

  \fIfea_edit\fP \-	feature file editor

  \fIfea_element\fP \-	prints binary format table for ESPS FEA files

  \fIfea_print\fP \-	 print data from FEA records with user-controlled formatting

  \fIfeafunc\fP \-	apply function, gain factor, additive constant, and type change to FEA fields

  \fIfea_deriv\fP \-	derive a new FEA file containing elements from an existing one

  \fIhditem\fP \-	print an item from an ESPS header

  \fIils_esps\fP \-	convert an ILS sampled data file to an ESPS file

  \fImat2fea\fP \-	converts from MATLAB .mat to FEA

  \fImergefea\fP \-	merge two FEA files so that output records contain fields from both

  \fImux\fP \-	multiplex sampled-data files into a single multichannel or complex file

  \fImu2esps\fP \-	converts mu-encoded data to ESPS FEA_SD file

  \fIpplain\fP \-	print values from ESPS file in "plain format"

  \fIepsps\fP \-	print headers and data from ESPS file in "pretty format"

  \fIselect\fP \-	applies arbitrary queries to select records from FEA files

  \fItestsd\fP \-	make test signal (sine wave, square wave, noise, pulses, ASCII input, etc.)

  \fIxeparam\fP \-	run an ESPS program with X Window parameter prompts

  \fIexprompt\fP \-	interactive ESPS parameter entry in a pop-up window

  \fIexpromptrun\fP \-	interactive ESPS parameter entry and program run
.sp .5
.fi
.lp
ESPS also includes facilities for dealing directly with headerless
files as well as with files that have foreign (non-ESPS) headers.  One
type of foreign header \- NIST (Sphere) sampled data headers \- are
read directly by ESPS programs.  For a detailed discussion discussion
of file conversion and foreign data, see the ESPS applications note
"Converting Data to and from ESPS FEA Files".
.sh 1 "PROGRAMMING WITH ESPS FILES"
.lp
This section contains a brief introduction to the C structures used
for ESPS headers and records, as well as to some of the ESPS library
routines that facilitate ESPS file processing.  If you are not
interested in ESPS programming, skip to Section 7.  For an 
introduction to ESPS file headers see.
.[
ESPS record keeping
.]
.sh 2 "ESPS File Headers"
.lp
The standard ESPS file header consists of two primary parts, the
universal section and the type-specific section.  All header
items (including generics) are referred to by name in programs.
This makes it easier to write, read, and maintain programs.
Also, when headers are output in ASCII form using
.i psps
(1\-\s-1ESPS\s+1), all of the items (including generics) are 
identified by name.  
.sh 3 "The Universal Section of the Header"
.lp
As the name implies, the universal section of the ESPS header has the
same definition for all ESPS file types.  This section of the header
is divided into a fixed-length portion called the \fIcommon\fP
section, and a variable-length portion called the \fIvariable\fP
section.
.lp
The universal section of an ESPS header contains information about the
type of data in the file, the program that created the file, the user
who created the file, the creation date, version information,
housekeeping information required by the header access routines,
history data, etc.  When user programs need to refer directly to
these items, they do so by name.  For example, consider the items
"tag" in the common portion and "refer" in the variable portion.
"Tag" determines whether or not the records in the file each contain
a tag pointing to a particular record in some pre-existing source
file; if they do, then "refer" is the name of the source file to
which they refer.  Here is an example of how these header items are
referred to in source code:
.vS
.nf

    #include <esps/sps.h>
    struct header *h;
    . . .
    if (h->common.tag) printf("source file for tags is %s\n", h->variable.refer);

.fi
.vE
In most cases, ESPS programs do not refer directly to items in the
universal section of the header because these items are maintained 
directly or indirectly by utility routines in the ESPS library.  For 
example, the universal section of the header contains a
variable-length comment field that is used to record arbitrary
ASCII comments.  Programs add comments to an existing header though 
use of \fIadd_comment\fP (3\-\s-1ESPS\s+1), as in
.vS
.nf

    add_comment(h, "This file contains clipped values.\n");

.fi
.vE
The user-level program \fIcomment\fP (1\-\s-1ESPS\s+1), mentioned in 
Section 3 above, is implemented by means of calls to
\fIadd_comment\fP.  
.sh 3 "The Type-Specific Section of the Header"
.lp
As the name implies, this section of the header is used to record 
information relevant to the specific file type.  The items defined 
for a particular file type are described in the manual page for
that file type in Section 5 of the ESPS Manual.  For example, see
SD (5\-\s-1ESPS\s+1) for the type-specific header definition for 
sampled data files.  For FEA files, the type-specfic section 
contains the field definitions.  
.sh 3 "Generic Header Items" 
.lp 
The pre-defined items in the universal and type-specific header
sections are intended to be useful in a broad range of typical
applications.  However, they cannot anticipate every application.
For example, the SD file type does not make provision for storing in