MP3 CD Player

ECE 251
Final Project Report
Professor Hielscher
December 7, 2000
Andrew Mall
Dan Goldshlack

Table of Contents

Design Considerations
Block Diagram & Expected Behavior
Description and Discussion of the Design
Appendix A – Original Proposal
Appendix B – Schematics


This report contains the details of our senior project from the first idea through the design and implementation phases.  It discusses component choices and design decisions along with problems that were encountered and the results of the changes that were made along the way.


For our senior project, we decided to make an mp3-cd player.  While there are many players that are similar to this design commercially available today, we wanted to see what was involved with the design and production of such a device.  We found many different types of schematics on the Internet to use as starting points to decide the components we wanted to purchase for our device.  In this paper, we will be discussing the design considerations and actual specifications of our device along with details of our process and the results obtained.


Audio files on CDs are in the Redbook format, which is comparable to Microsoft’s WAV (Windows Audio Volume) format.  With this straight encoding scheme, data files occupy about 11MB/minute of audio data, which is fine for a compact disc with a capacity of 640MB.   However, when storing audio onto computer media or transferring data over a network, 11 megs per minute is just way too large.  In the last decade various compression schemes have been standardized, but it was mpeg3, or mpeg1, layer-3 audio, that has become the de facto encoding standard for audio in the modern computing world.

What it sacrifices in quality, it more than makes up for in compactness.  At a minimal encoding bitrate of 128bps, what most enthusiasts claim to be the absolute minimum for acceptable sound quality, a file can be encoded to 1/11 of its normal WAV bit length, or about 1MB/minute.  The growing popularity of CD-R drives, mass storage on the compact disc scale has become commonplace, and with the use of mpeg3 encoding over 250 songs can be recorded onto one disc.  This rise in disc media has been matched with the growing popularity of DVDs, and has made feasible players that play CDs, MP3-CDs, and DVDs.

There are many players on the market today that are simply portable CD players that read mp3s, and making such a player was the original intent of our project.  We wanted to take a commercially available portable CD player and just add-in the capability to decode MP3s.  While trying to research the necessary information to modify a player in such a way, we realized that it would be infeasible for the time we had to complete the project, and decided instead to make a stand-alone player using a standard ATAPI CD-ROM drive.

Design Considerations

Mpeg3 Decoder Chip

To perform the MP3 decoding, we chose the MAS3507D from Micronas Corporation.  This chip is used in many of the freely available designs, and it seems to be very well suited to this type of application.  According to Micronas’ data sheet on the processor:

The MAS 3507D is a single-chip MPEG layer 2/3 audio decoder for use in audio broadcast or memory-based playback applications. Due to embedded memories, the embedded DC/DC up-converter, and the very low power consumption, the MAS 3507D is ideally suited for portable electronics.

This MAS chip has various inputs, outputs, and control features; it can accept a serial asynchronous MPEG bit stream input (SDI) and parallel (PIO-DMA) input.  The chip can also request data via a demand signal while in multimedia mode.  The audio output is delivered via an I2S bus (SDO), while an I2C interface provides ancillary data and status information. Ths chip also provides digital volume, bass and treble controls.

Digital-to-Analog Converter Chip

The output from the MP3 chip, in digital format, has to be converted to analog data to be heard at the audio out port, and the DAC3550A chip, also from Micronas, is ideally suited fir this job. There are many more commercially available DAC chips than MP3 chips on the market because of the preponderance of digital audio devices, but the MAS and DAC ships from Micronas were designed to work together with no integration issues. From the data sheet:

The DAC 3550A is designed for all kinds of applications in the audio and multimedia field, such as: MPEG players, CD players, DVD players, CD-ROM players, etc. The DAC 3550A ideally complements the MPEG 1/2 layer 2/3 audio decoder MAS 3507D.

Digital audio input data is received via the I2S bus, while two separate analog inputs are available for amplification as well. The chip provides line-out and headphone / speaker (amplified) analog outputs with volume control.

Microprocessor / Control

Originally, we intended to use a PIC type chip for the controlling microprocessor, but instead opted for the Motorola M68ICS05P project kit, on the advice that it already had a board and would thus be less work.  What we didn’t realize at that time were the limitations of the M68IC chip in comparison to the PIC16C65A.  The biggest problem is the fact that the Motorola doesn’t have enough ports for dataflow, and the other concern is that it doesn’t support subroutines.  These two factors meant that we’d have to make the IDE controller separately, adding even more complexity and room for error.  We came to realize that this chip was good for small projects, but not for ours, which requires high throughput across the chip along with the control.

Circuit Board / PCB

The circuit board is the one part of the project that has actually gone as planned, although it took far longer than we originally anticipated.  After we had the circuit diagram for the board, we had to figure out how to use the layout program on the computer, how to represent the chips that we had purchased so they would fit in the design, and finally how to actually connect the components and have the auto-router create a design suitable for etching.

Liquid Crystal Display

For the display we chose a Seiko 2x16 LCD that hopefully has a standard implementation, as it didn’t come with any documentation.

Block Diagram & Expected Behavior

The device is expected to behave as follows:

The control is turned on with the device, and awaits user input.  If a song is to be played, it requests data from the ATAPI controller.  The bitstream from the mp3 file in use is sent to the MAS/DAC board where the MAS chip demands data at its own rate, preventing incorrectly decoded sound data.  If the data on the CD is standard Redbook audio and doesn’t need to be decoded, it will instead be sent directly to the DAC chip.  Information on the current session is sent to the LCD as it is updated, and the sound data is reproduced as audio data at the output jack.

Description and Discussion of the Design

The design is made to be modular, so the circuitry from the decoding area is on its own board, separate from the control and ATAPI circuitry.  This makes it easier to implement each part, and for this project we chose to begin with the decoder board.  The microprocessor already had its own board, so we thought we’d only have to implement the assembly code of the control.  After completing the board for the decoder, we realized that the Motorola chip and board package was inadequate for our needs, and did not have enough time to obtain a PIC and construct a second board as we had originally intended.

The ATAPI controller circuitry itself is more than the Motorola board can handle, so we focused on finishing up our decoder board and having at least something that worked.  As mentioned in previous sections, we spent much longer on this portion of the project than we had originally anticipated.  We had a design that we had chosen from those available, and had to figure out how to make the board from that design.  First, we had to figure out how to use the PCBoards program from MicroSim.  Included in that was learning how to make a symbol for the two chips; a very complex process involving padstacks, libraries, and footprints, among other things.

After ascertaining how to represent our chips in the design, we then had to layout all of the resistors, capacitors, and other standard elements we were going to need.  Finally, we had to connect all of the pieces in the correct fashion and then have the program produce a board layout with the auto-router that we could hand-make.

Upon finally having a design that was suitable to produce, we printed the layout onto a sheet of normal paper and photocopied a positive transparency.  A negative was made on photosensitive paper from the transparency, and that negative was used to develop the copper on the board that we wanted to keep.

The copper that was unnecessary was bubble etched away (along with a little that was needed) and we had the basis for our printed circuit board.  Next we spent many hours drilling the holes necessary for the thrus and all the component connections.  We also had to solder wires to the part of the board that was mis-etched.  Next, we identified the components’ positions in our layout and marked the values we would have to connect and the arduous process of soldering every component and thru on the board began.

Since this process seemed to be the most difficult portion of the project, we spent the majority of our time on it. Only after the board was completed did we realize the problems inherent with our selection of the Motorola chip for our control and expected ATAPI controller; by this time it was too late to design and produce the components necessary to ensure compatibility with the Motorola chip or obtain the PIC that we had originally intended to use.


Throughout our senior project, we had to deal with considerations and problems that anyone designing and implementing a digital system would deal with.  We originally had an idea for what we wanted to do and realized that a new design would have to be instantiated to achieve our original goals.  After finalizing the core design of our project, we opted to utilize an alternate microprocessor.  Assuming this processor would be an adequate substitution, we commenced with the rest of the design.

We weathered through the production of our PCB and finally began the rest of our project, only to realize that the Motorola board was inadequate for its desired functionality.  Designing the necessary components for functionality would have been prohibitively time-consuming and complicated, considering we were out of time already.

Although we didn’t complete the project as we intended, we learned a great deal from the production of the circuit board and examining our options for completing the rest of the project.  If we attempt another project, or even a completion of this project, we will know how to proceed to avoid the same pitfalls we encountered this time around.