Chapter
3 Software Implementation
Introduction
The
various signal processing modules discussed in chapter 2 were assembled
and implemented in the Java programming environment (the software is
available at http://eamusic.dartmouth.edu/~taehong). The system uses
various GUI (Graphical User Interface) capabilities for easy visualization
of extracted features. The following sections describe the software and
the motive behind using Java.
Why
Java?
The Java
programming environment was used for the following reasons.
Platform
independence
Non-real
time requirement for this thesis
Good GUI
design capabilities
Java Sound
Syntax similarity
to C/C++
Java has
been designed for the purpose of neutrality towards architecture. This
can be achieved if pure Java code is written. For this reason, the program
I have developed has no native coding methods (system dependent code) and
runs on pure Java alone. Although native coding methods improve efficiency,
this program does not require real-time processing or time-critical computation.
One of the goals of this thesis was to write an intuitive GUI (graphical
user interface) - easy control of parameters, coefficients and visual representation
of extracted features. This was done with the Java Swing GUI environment.
Another reason for choosing Java lies in sound playback and recording.
The ability to play and record sounds, without developing interrupt service
routines and memory accessing procedures pertinent to each platform was
a major plus. Finally, the syntax similarity of Java to C/C++ greatly facilitated
the move from C/C++ to Java without having to learn a completely new "language".
Main
Software Structure
The software's
main modules are the GUI, command center and
sound object.
The GUI is responsible for responding to requests performed by the user
via button clicks, data entry, menu selections etc. . The command center
takes the job of directing the commands requested by the user and notifying
the appropriate sound object. The sound object which is "instantiated"
whenever a new sound file is loaded into memory, supervises and keeps track
of all its child frames (internal frames - each corresponds to a DSP process)
for updates and unnecessary re-computation using linked lists. Hence, unused
objects and commands are removed or added to linked lists making command
processing efficient both in memory management and data management.
|
|
Figure 3.1 Main software architecture
|
|
|
Figure 3.2 Snapshot of software
|
Software
Features
This section
lists features of the program.
| File
IO Features |
|
Features
|
Description
|
|
File Open
|
saves aiff, wav, au
|
|
File save
|
writes aiff, wav, au, raw data (float)
|
| |
|
|
DSP Command Features
|
|
DC Offset Removal
|
removes DC Frequency
|
|
AM Analysis
|
amplitude modulation analysis
|
|
Attack Time
|
attack time computation
|
|
Amplitude Envelope
|
amplitude envelope rendering
|
|
FFT
|
discrete Fourier transform
|
|
Spectrogram
|
display of peaks vs. frame/time
|
|
Pitch Detection
|
detection of pitch (vs. time)
|
|
Pitch Modulation
|
detection of low freq. pitch modulation
|
|
Spectral Centroid
|
spectral centroid computation (vs.
time)
|
|
Spectral Smoothness
|
spectral smoothness computation
(vs. time)
|
|
Noise Content Analysis
|
noise content analysis (forward
LPC, inverse LPC)
|
| |
|
|
Sound Features
|
|
Play
|
plays loaded waveform and residue
signal if selected
|
|
Stop
|
stops play and record
|
|
Rec
|
records signal from mic/line
|
|
Pause
|
pauses record and play
|
| |
|
|
Plot Commands
|
|
Zoom in/out
|
|
|
Scroll x,y
|
|
|
Quick view
|
"summarized" view of signal, improves
screen update latency
|
|
Log view/Linear view
|
log view of magnitude component
in FFT
|
Table 3.1 Software features
Table
of Contents
next
previous