CS 4500 Assignment #6.
Assigned: Friday, 31 October 2014
Due: Friday, 14 November 2014
Revised: Wednesday, 12 November 2014 (to correct grading criteria)

Working in an instructor-approved team of four students
(except for a few smaller teams approved by the instructor),
develop a first full prototype of the semester project
specified below.

Your prototype's source code must be written entirely by
your team.  Your team must not use source code written by
other students, must not use source code obtained from the
World-Wide Web or other sources, and must not use software
packages that are not already installed on the CCIS Linux
machines.

In exceptional circumstances, you may ask the instructor
for permission to use third party source code.  You should
not assume permission will be granted.

Your prototype must include a README file (which *must* be
in UTF-8 plain text, must be named README, and must not
contain any lines longer than 80 characters) that

1.  lists all members of your team,
2.  gives the preferred email address(es) for contacting
    your team,
3.  tells the grader(s) how your team's rapid prototype
    can be compiled and run on any CCIS Linux machine in
    the main lab,
4.  acknowledges any third party software used (by permission!)
    in your submitted software.

All of the files necessary to construct and to run your
prototype must be combined into a gzip'ed tar file whose
name ends in tar.gz.  Submit that gzip'ed tar file before
10pm on the date it is due using the submit script that's
described at the course assignments page:

    http://www.ccs.neu.edu/course/cs4500f14/assignments.html

Your prototype will be graded on these criteria:

1.  the quality of the instructions and documentation
    in your README file,
2.  the ease of constructing and running your prototype
    on CCIS Linux machines,
3.  your prototype's correctness with respect to
        parsing correct command lines
        recognizing and allowing the supported file formats
        reporting errors for unsupported file formats
        producing correct error messages
        not producing extraneous output
        not attempting to create files outside of /tmp
        deleting files inside /tmp that were created by the program
4.  your prototype's reliability with respect to
        reporting non-matches for recordings that don't sound alike
        reporting matches for audio recordings containing fragments
            of five seconds or more that sound alike
5.  your prototype's efficiency (mainly run time)
6.  and the readability of your source code.

Your prototype's build process must result in software that
can be invoked by cd'ing to the directory containing your
software's executable and executing a command of any of the
following forms:

    ./dan -f <pathname> -f <pathname>
    ./dan -d <pathname> -d <pathname>
    ./dan -f <pathname> -d <pathname>
    ./dan -d <pathname> -f <pathname>

where <pathname> is a Linux path name.  If a <pathname> is
preceded by "-f", then the <pathname> must end in ".wav" or
".mp3" and must name a file that already exists on the CCIS
shared file system.  If a <pathname> is preceded by "-d", it
must name a directory that already exists on the CCIS shared
file system and contains nothing but files whose pathnames
would be legal following a "-f" option.

If a <pathname> preceded by the "-f" option ends in ".wav",
that file must be in little-endian (RIFF) WAVE format with
PCM encoding (AudioFormat 1), stereo or mono, 8- or 16-bit
samples, with a sampling rate of 11.025, 22.05, 44.1, or
48 kHz.

If the <pathname> ends in ".mp3", that file must be in the
MPEG-1 Audio Layer III format (MP3).

Your software should not assume that every file whose name
ends in ".wav" or ".mp3" is in the correct format.

If both <pathname>s supplied to the dan program are directories,
then the software should compare every recording in the first
directory against every recording in the second directory.  If
one <pathname> is a file and the other a directory, then the
single file should be compared against every recording in the
directory.  Each comparison should behave as specified below
for the case where both <pathname>s are files.  When more than
one comparison is made, the software may perform comparisons
and print results in any order.

If the command line is correct and each <pathname> is correct,
then the dan program should compare the audio recordings to see
whether one of them contains a segment of five seconds or more
that sounds like a segment of the same length within the other
recording.  If so, then the dan program should print "MATCH" to
standard output, followed by a space, followed by the short name
of the first file, followed by a space, followed by the short
name of the second file, followed by a space, followed by the
offset in seconds of the beginning of the matching segment
within the first file, followed by a space, followed by the
offset in seconds of the beginning of the matching segment
within the second file, followed by a newline.  Only one such
line should be produced for each pair of audio recordings.
If there are no segments within the first recording that match
a segment within the second, then the dan program should print
nothing.  In either case, the dan program should terminate with
an exit status of 0.

If the command line is incorrect, or a <pathname> is incorrect,
or one of the files specified by a <pathname> or within a
directory specified by a <pathname> is not in a supported
format, then the dan program should write one or more error
messages to standard error, each beginning with "ERROR" and
terminating with a newline.  After writing these error messages
to standard error, dan should terminate with an exit status
other than 0.

----------------------------------------------------------------