Spring Quarter 2002

Course Objectives Addressed

• Understand the rationale for object-oriented design and programming.
• Understand data abstraction and abstract data types.
• Be familiar with UML class notation and use cases.
• Be able to design and implement simple C++ classes and class libraries.
• Be able to design small software systems using classification and use cases.
• Be able to document the design and implementation of small software systems.

Overview

The purpose of this lab is develop an MP3 player software application.

Acknowledgement

This lab was developed by Dr. Chris Taylor and relies on the Xaudio SDK.

Problem Statement

You are to develop an MP3 player application that will play albums (specified by .tag files) and play lists (specified by .ply files). Your application must meet the following minimum requirements:

• Load a .tag file and play all of the MP3 tracks listed.
• Load a play list (.ply) and play all of the the MP3 tracks listed.
• The play list should have the following format:

         # Lines that begin with a # should be ignored
         3   3.mp3
         9 532.mp3
         222.mp3
            
         3 Disk 8.tag
         1 17.mp3
  

  where:
  • Blank lines and lines beginning with a # symbol should be ignored.
  • Each line contains the filename of one MP3 or .tag file.
  • A number may or may not appear before a filename. If no number is present, your program should use a default value (value=5, unless you have a reason to do something else).
• If a .tag file is specified, all of the the MP3 files listed in .tag file should be added to the play list. All of the files should be assigned the value that appeared before the .tag file (or the default value if no number was present).
• The user should be able to select any of the following ways of playing all of the songs in the play list:
  • The order of the play list file.
  • A random order where any unplayed track is equally likely to be played next.
  • A random order where the likelihood of playing any unplayed track next is directly related to the number preceeding the filename in the play list.
• The filename of the track should be displayed before each track is played. Other information about the track should be displayed as well; however, this may be displayed before, after, or while the track is playing.
• You may provide a graphical user interface using MFC or a command line interface.
  Command line interface details:
  • Your program should accept a .tag or .ply file and optional arguments from the command line.
  • mp3play list.ply should play the files in list.ply in order.
  • mp3play -r list.ply or mp3play list.ply -r should play the files in list.ply in a random order.
  • mp3play -w list.ply or mp3play list.ply -w should play the files in list.ply in a weighted random order.
MFC GUI details:
• You should design a user interface that is easy to use.
• If you would like a quick review/introduction to MFC, please take a look at a CS182 lab assignment that I have previously assigned.

Notes:

• A line in the play list file with only whitespace on it is considered a blank line.
• The .tag format was specified in lab2.
• The numbers preceeding the MP3 filenames should range from 1 to 10. If the number is larger than 10, it should be set to 10 (most likely to be played next). If the number is less than 1, the file should never be played.
• You may modify the MP3 and album classes if you desire. (Be sure to include the modified source code in your report if you choose to modify them.)
• This is supposed to be a fun lab, and I expect that many of you will choose to add a number of additional features. You may wish to look at other MP3 players like dBpowerAMP Audio Player or Winamp for additional ideas. You may also find it useful to look at the samples directory of the Xaudio distribution for ideas on how to actually implement some of these features.
• The MP3 class used in the first two labs makes use of the synchronous library; however, you may find (particularly if you choose to create a GUI) that you would prefer to use XAudio's asynchronous MP3 library instead. That is fine with me; however, you will need to study the documentation provided with the XAudio library in order to figure out how to use it.

Demonstrations

Intermediate

Your program should be able to read .tag and .ply files and play the tracks in order.

Complete

Your program should be fully functional.

Lab report

The lab report should consist of the following:

• A screen capture of your GUI (if you did one).
• At least one use case.
• Your design documentation. (One or two paragraphs describing your approach to solving the problem. This section should convince me that you were thinking when you made the decisions that you did about how to design your program.)
• A brief description of any problems you encountered or questions you have regarding the lab.
• Any suggestions you have for how the lab could be improved.
• A summary of your activity log indicating how much time you spent on the assignment. Please follow the new time log format given in the template file. In particular, you should record the date and time for each block of time you work on the project. Dr. Taylor's students: You should email an updated time log to him each week. The time log must be emailed between Thursday, 6:30pm and Friday, 11pm of each week. Please report the time in the following categories:
  • Designing
  • Coding
  • Debugging (before you think it's working)
  • Testing (after you think it's working)
  • Writing report
  • Other
• The documented source code for your program. Include only the source files that you modified.

Project report template

As with any report you submit, correct spelling and grammar are required. In addition, your report should be submitted electronically following the Electronic submission guidelines. (You may wish to consult the sample report before submitting your report.) Be sure to keep copies of all your files, in case something gets lost. It may be wise to keep a diskette backup as well.

Your lab grade will be determined by the following factors:

• Meeting specifications
• Technical quality
• Design documentation
• Internal documentation (comments)
• Program clarity (formatting, etc.)
• Narrative report
• Activity log (similar to the last lab)
• Correct program output
• Spelling and grammar
• Timeliness of submission

If you have any questions, consult your instructor.