rel40.me

speech signal process tools

.lo
.he 'ESPS Version 4.0c Release Notes''page %'
.ce 3
.b
ESPS Version 4.0c Release Notes
.sp
Document version: 1.17 2/25/91
.sh 1 "INTRODUCTION"
.lp
This document provides notes relevant to release 4.0c of ESPS.  Please
read this document and the Installation Instructions completely before
installing this release.  These release notes document changes to ESPS
since the revision 3.3b.  The last section documents known  problems.
.lp
Note that there's an option (\fB-u\fP) on the new program
\fIeversion\fP (1\-\s-1ESPS\s+1) that will display an on-line copy of
these release notes to any ESPS user.  This provides a convenient way for 
ESPS users to find out about the changes. 
.sh 1 "CHANGES SINCE 4.0a AND 4.0b RELEASE"
.lp
This release (4.0c) is a maintenance release
that includes bug fixes and a few new programs.   
Major changes described were introduced
in Version 4.0a and 4.0b. (See Sections 3 - 6).   
.sh 2 "CHANGES SPECIFIC TO 4.0c"
.lp
The following are specific changes since 4.0b:
.np
The X Window based
programs (\fIxtext\fR (1\-\s-1ESPS\s+1), \fIxprompt\fR
(1\-\s-1ESPS\s+1), \fIplot3d\fR (1\-\s-1ESPS\s+1), and \fIimage\fR
(1\-\s-1ESPS\s+1)) were compiled under Version 2.0 of Sun`s OpenWindows.
.np
\fIPlot3d\fR (1\-\s-1ESPS\s+1) has been completed and documented (see
Section 3.7).
.np
\fIinit_feaspec_hd\fR (3\-\s-1ESPS\s+1): Bug fixed: when handling ARB_FIXED files, it would
put the frequencies in the "num_freqs" header item.
.np
\fIprint_feaspec_rec\fR (3\-\s-1ESPS\s+1): Bug fixed: reference to incorrect structure in code for
ARB_FIXED.  Also improved output formantting.
.np
\fIput_feaspec_rec\fR (3\-\s-1ESPS\s+1) and \fIget_feaspec_rec\fR
(3\-\s-1ESPS\s+1): Bug fixed: Fixed criterion
for overflow.
.np
General FEA_SPEC support: Fixed memory leakage problem.
.np
\fIimage\fR (1\-\s-1ESPS\s+1): Now allows FEA_SPEC files in ARB_FIXED format.
.np
\fIils_esps\fR (1\-\s-1ESPS\s+1):   There was a bug that caused it to
dump core if the input file header indicated 0 for the number of channels.  
This has been fixed.  An indicated value of 0 now implies 1 (single-channel
data), as intended.   Two other bugs were fixed that prevented the
\fB-h\fR and the \fB-d\fR options from working correctly.
.np
\fIfft_filter\fR (1\-\s-1ESPS\s+1): A bug was fixed that caused incorrect results for
filters larger than 1024 taps.
.np
\fIbtosps\fR (1\-\s-1ESPS\s+1): A bug has been fixed that caused
 the \fB-S\fR option to fail.
.np
The new program \fIxtext\fR (1\-\s-1ESPS\s+1) has been added.  This program runs a Unix
command line and displays the standard output in a new X window.  It is
particular useful to attach ESPS commands to the Sun OpenWindow file
manager.
.lp
The remainder of this release note describes changes since version
3.3b.
.sh 1 "SUMMARY OF MAJOR CHANGES"
.lp
Major changes include the following:
.ip \ \ \ \(bu
FEA files now support complex data
.ip \ \ \ \(bu
new FEA file for sampled data (including multi-channel and complex data)
.ip \ \ \ \(bu
machine-independent I/O
.ip \ \ \ \(bu
new programs  (including X Windows 3D plot program)
.ip \ \ \ \(bu
X Windows support for all platforms (including Sun) 
.ip "\ \ \ \(bu" 5
interactive parameter prompting via pop-up windows (under X)
.ip \ \ \ \(bu
ESPS now available for Silicon Graphics
.ip \ \ \ \(bu
HP LaserJet support
.ip \ \ \ \(bu
revised source and library structure
.ip \ \ \ \(bu
floating license servers
.ip \ \ \ \(bu
support for SPARCStation and Silicon Graphics codecs
.ip \ \ \ \(bu
additional documentation
.sh 2 "Machine Types Supported" 
.lp
ESPS Version 4.0 is available for the following machines:
.nf

	Convex
	Concurrent (Masscomp)
	DecStation 3100
	Hewlett Packard 300
	Hewlett Packard 800
	Silicon Graphics
	Solborne
	Sun 3
	Sun 386i
	Sun 4/SPARC
	Apollo (Domain 10.3)

.nf
.sh 2 "Complex Data Support Added to FEA Files"
.lp
In previous ESPS releases, the data types of fields in feature file
(FEA) records were restricted to the fundamental types BYTE, SHORT,
LONG, FLOAT, and DOUBLE.  In Version 4.0, support has been added for
corresponding complex types BYTE_CPLX, SHORT_CPLX, LONG_CPLX,
FLOAT_CPLX, and DOUBLE_CPLX.  Each complex type has a real and an
imaginary part of the corresponding integer or floating type.  
For details see the FEA man page FEA (5\-\s-1ESPS\s+1). 
.lp
At the programming level, utility library functions like \fIadd_fea_fld\fP,
\fIallo_fea_rec\fP, \fIget_fea_ptr\fP, \fIput_fea_rec\fP, and
\fIget_fea_rec\fP have been extended so that the new types are handled
in exactly the same manner as the old ones.
.lp
All user-level programs that process FEA files have been modified so
that, when presented with complex data, they either deal correctly
with it (examples include \fIpsps\fP and \fIaddfeahd\fP), or they exit
with a message indicating that the current version does not support
complex data (examples include \fIvqdes\fP and \fIdistort\fP).  Many
of the user-level programs that currently do not support complex data
will do so in later versions.  Section 3.4 contains a list of the
FEA programs that currently operate in general on complex data.
.sh 2 "Feature File for Sampled Data (FEA_SD)" 
.lp
In Version 4.0 ESPS, the built-in file type for sampled data (SD) has
been replaced by a feature file subtype (FEA_SD).  All of the
user-level programs that deal with sampled data have been changed to
support FEA_SD files.  This has been done in a backward-compatible
manor \- i.e., the current programs will all read the old-style SD
files in addition to the new FEA_SD files.  We have also included
conversion programs between the old and new file types (\fIsdtofea\fP
(1\-\s-1ESPS\s+1) and \fIfeatosd\fP (1\-\s-1ESPS\s+1)).  For details
about FEA_SD see the man page FEA_SD (5\-\s-1ESPS\s+1).
.lp
The new FEA_SD file type supports complex, multi-channel sampled data,
and there are new user-level programs to support multiplexing
(\fImux\fP) and demultiplexing (\fIdemux\fP).  Some of the existing
user-level programs for sampled data have been modified to process
complex data (e.g., \fIfft\fP, \fIcopysd\fP, \fIaddsd\fP).  Others
will be modified in later versions.  Section 3.4 contains a list of
the sampled-data programs that currently operate in general on complex
data.  In many cases, users can deal with multi-channel and complex
FEA_SD files by writing scripts that make use of \fImux\fP and
\fIdemux\fP together with programs that operate on single-channel real
data.
.lp
At the programming level, FEA_SD is supported by a set of access
routines that are analogous to those that support the old-style SD
files, including I/O of overlapping frames and the independent
determination of the data type stored in memory and the data type
stored in files \- for example, see \fIallo_feasd_recs\fP
(3\-\s-1ESPS\s+1u).
.lp
With the addition of FEA_SD, the current list of supported feature
files is as follows:
.nf
.ta .5i 2i

	FEA_SD \-	sampled data
	FEA_SPEC \-	spectra
	FEA_STAT \-	statistical information 
	FEA_ANA \-	speech analysis
 	FEA_VQ \-	vector quantization codebooks
	FEA \-	 "bare" feature files

.fi	
.lp
The introduction of FEA_SD is a major step in our program to replace
all of the built-in file types with feature files (only filter files
and scalar codebook files remain).
.lp
For details about FEA_SD (including guidelines for converting
programs), see "FEA_SD Files \- Feature Files for Sampled Data in
ESPS".
.sh 2 "Machine-Independent I/O"
.lp
In previous versions, ESPS files written on one machine could be read
by ESPS programs running on another machine only if the two machines
happened to have identical numerical data formats and byte order.
This meant, for example, that ESPS files from a Sun 4 could be read by
a Sun 3 but not by a Sun 386i or a DECStation 3100.  A goal for ESPS
Version 4.0 was that differences in numeric formats and byte-order
among machines on the network be hidden from ESPS user programs.
.lp
To meet the goal of machine independence, we defined an external ESPS
format that permits ESPS programs running on different machine
architectures to work cooperatively on the same files, and we revised
the ESPS file system accordingly to provide general support for
machine independent I/O (MIIO).
.sh 3 "NATIVE vs. EDR Format"
.lp
ESPS files in Version 4.0 can be in one of two format: NATIVE or EDR.
Data in NATIVE format files are written using the native numeric
formats for a particular machine.  Data in EDR (ESPS Data
Representation) format files are written in a standard representation:
floats and doubles are stored using IEEE standard 32 bit and 64 bit
floating point.  Integers and long integers are stored respectively as
16 and 32 bit twos-complement integers.  The byte type is stored as an
8 bit byte.  Character data is stored in ASCII with one character per
byte.  The byte order is that of the Motorola 680X0 processors.  The
ESPS external format essentially is the same as the Sun Microsystems
external data representation (XDR) format.
.sh 3 "I/O of ESPS Files"
.lp
ESPS programs will read files in either NATIVE or EDR format (and also
files from older versions of ESPS).  By default, ESPS programs write
files in the NATIVE format for the machine on which the programs are
run.  EDR format output files can be obtained in general for all
programs by creating the UNIX environment variable ESPS_EDR and giving
it the value "on".  The conversion program \fIaddfeahd\fP (add an ESPS
header to an existing headerless, binary file) has an option to
specify whether the data are in NATIVE or EDR format.  At the
programming level, the output format can also be controlled by setting
the \fIedr\fP flag in the ESPS header before calling
\fIwrite_header\fP (3\-\s-1ESPS\s+1).  (Note that the header is also
an argument passed to the data output routines.)
.lp
The ESPS input routines can not in general handle files written in
native mode by other architectures \- files to be exchanged should be
written in EDR format unless the native modes happen to match.  This
lack of generality is a compromise that supports file sharing but only
requires a single machine-dependent conversion module for each
architecture (the module converts between native mode and ESPS
external format).  Some exceptions to the foregoing have been allowed
for.  In particular, the ESPS input routines will recognize cases
where NATIVE modes differ only with respect to byte order.  Thus, for
example, NATIVE format files from a DECStation 3100 or Sun 386i can be
read by ESPS programs running on a Sun 4 or Concurrent (and \fIvice\fP
\fIversa\fP).
.lp
Using the ESPS external format can result in increased file I/O times,
but the feature can be turned off (so that native formats are always
used) when it isn't needed.  As mentioned, the default is to use
native formats.
.sh 3 "Typical Usage of ESPS_EDR" 
.lp
If you have a homogeneous network (all machines of the same type),
then it is usually appropriate to have all programs write files in
NAIVE format.  Since this is the default, nothing special has to be
done.  For heterogeneous networks (mixed machine types), it is
currently the case that the only difference between NATIVE and EDR
format is in byte order (this will change as ESPS is ported to more
machines).  Since the input routines will read NATIVE format files
from a foreign machine in cases where the only difference in the local
NATIVE format is byte order, it follows that NATIVE format ESPS files
from any machine on a heterogeneous network can be read by ESPS
programs on any other machine.  Of course, EDR format files from any
machine can also be read by ESPS programs on any other machine.  Thus,
the choice of whether to write ESPS files in NATIVE or EDR format on a
particular machine should be based on efficiency, which in turn is
determined by access patterns.
.lp
For example, if a set of files are produced originally on a DECStation
3100 but used primarly by programs running on a Sun 4, it probably
makes sense to write the files in EDR format.  Since the EDR format
happens also to be NATIVE format for the Sun 4, the overhead of byte
swapping will be avoided each time the files are read on the Sun 4.
.sh 2 "X Window Support for Suns"
.lp
X Window support for ESPS graphics programs (\fIplotsd, plotspec,
aplot, scatplot, genplot, mlplot, image\fP) has been extended to
include Sun Microsystems computers.  If the programs are built for
both X and Suntools, the programs default to X but can be run under
Suntools by using \fB-T\fPsuntools.  (Analogous behavior occurs with
Concurrent in the case of X vs MC Windows.)  In addition, the an
environment variable can be set to cause the ESPS plotting programs to
use Suntools, rather than X Windows.   See the man pages for the plot
programs (\fIe.g. plotsd\fR).
.sh 2 "Use of Sun XView Toolkit"
.lp
A number of our graphics programs, including \fIxwaves+\fR,
\fIxprompt\fR, \fIxtext\fR, and \fIplot3d\fR are built using the XView
toolkit.  In order to run these programs with a particular X server you
may have to install the XView fonts that we supply and make certain
changes to some of your X related configuration files.
.lp
XView programs will run on Sun  CPUs with Sun OpenWindows 1.0.1 or
greater, on HP 300 systems with OS 7.0, and on Masscomp systems with