CS 4500 Assignment #5. Assigned: Wednesday, 22 October 2014 Due: Friday, 31 October 2014 Revised: Friday, 24 October 2014 (to add examples at end) Working in an instructor-approved team of four students (except for a few smaller teams approved by the instructor), develop a slightly more general prototype of the greatly simplified version 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 audio recordings of different lengths reporting non-matches for recordings that don't sound alike reporting matches for audio recordings that sound alike 5. 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 -f ./dan -d -d ./dan -f -d ./dan -d -f where is a Linux path name. If a is preceded by "-f", then the must end in ".wav" or ".mp3" and must name a file that already exists on the CCIS shared file system. If a 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 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 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 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 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 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 is correct, then the dan program should compare the audio recordings to see whether they are of exactly the same length and sound alike. 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 newline. If not, 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 is incorrect, or one of the files specified by a or within a directory specified by a 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. ---------------------------------------------------------------- Examples. ./dan -d /course/cs4500f14/Assignments/A5/D1 \ -d /course/cs4500f14/Assignments/A5/D2 should produce some permutation of the following output: MATCH curieuse2.wav curieuse.wav MATCH curieuse.mp3 curieuse.wav MATCH janacek.mp3 janacek2.wav MATCH maynard.wav maynard2.wav MATCH rimsky.mp3 rimsky2.wav MATCH sons2.wav sons.wav MATCH z03.wav z04.wav MATCH z07.wav z08.wav ---- ./dan -f /course/cs4500f14/Assignments/A5/D2/curieuse.wav \ -d /course/cs4500f14/Assignments/A5/D1 should produce some permutation of the following output: MATCH curieuse.wav curieuse2.wav MATCH curieuse.wav curieuse.mp3 ----------------------------------------------------------------