Project Plan
Content
1 Background
    1.1 Project related literature
    1.2 Project related hardware
2 Objective
3 Organization
    3.1 Project Members
    3.2 Project Support
4 Project-model
5 Comments on time plan and resource plan
6 Documentation
7 Risk analysis
8 Appendix
1 Background
Error concealment is used in switched networks as well as in mobile networks for speech communication. In mobile telephony, parts of the transmitted speech may be lost during the transmission. In packet based networks it may happen that packets arrive too late, not at all, or in the wrong order. Hence, at the receiver an artificial signal has to be constructed that minimizes the perceptual disturbance caused by the packet loss. This is referred to as error concealment.
 
In this project the focus is on error concealment in the Jerry Springer show. Every time someone in the show uses bad language this language is replaced by an "explicit word beep". These beeps could vary in length depending on the amount of bad language. The beeps can be a bit annoying and should be replaced by a sound that is as similar to the original sound as possible. This problem is much like error concealment.
 
The outline of the proposed solution is shown in the following flowchart:

     
  1. At first one block will be sampled from the Jerry Springer Show. This will probably be done with a sampling rate of about 16 kHz and a block size of 256 bytes.
  2. Each block will pass through a beep detector. The beep detector will estimate the energy in the block. If all, or nearly all, of the signal energy is in the pre-defined beep frequency the block is designated as a beep block.
  3. If there is no beep in the block, the block will be used to store AR-parameters for future needs. The AR-parameters will try to approximate the background sound.
  4. If there is a beep in the sampled block, it will be replaced with a sound similar to the background sound. This will be done using the AR-parameters stored from previous blocks without beeps.
  5. If the block didn’t contain any beep, the block will be sent to the speaker. If, on the other hand, the block did contain a beep, the synthetically generated sound is sent to the speaker.
Efforts will be made to accomplish a smooth sound even though a beep has been replaced. The delay in the process and the problems related to that will also be addressed.

1.1 Project related literature

 

1.2 Project related hardware

 
2 Objective
The goal of this project is to design a real-time error concealment system for censored American talk shows where the "explicit word beep" is frequently used. The error concealment system should detect the beeps and replace them with a comfortable sound e.g. a signal that sounds similar to the background sound in the talk show. It is of great importance that the error concealment system works in real-time so the sound in the show won’t get delayed compared to the picture.
 
The project will be finished 2000-05-30 when demonstration and oral presentation will be held. Also the final report and documentation will be available at this time.
 
The group is determined to follow the time plan of the project.
 
3 Organization
This section describes and identifies every one involved in the project.

3.1 Project Members

Name
Post
Contact
Mattias Hessel
(MH)

Project Manager 

The project manager has the over all responsibility of the project and the documents. The responsibility specifically includes keeping everyone going and call the group together. 
Tel: 08-375175
Cellular: 070-7950015 
e-mail: e96_mhe@e.kth.se
Henrik Lundin
(HL)

Theory Analyst - replacement 

The theory analyst keeps track of all the theory and the algorithms.
 
Tel: 08-352499
Cellular: 070-6461341 
e-mail: e95_hlu@e.kth.se
Magnus Flodman (MF)

DSP Programmer 

The DSP programmer is familiar with the C programming language and will implement the algorithms into the DSP. 
Tel: 08-6242134
Cellular: 070-3404860 
e-mail: e96_mfl@e.kth.se
Fassil Mehany
(FM)

Theory Analyst - detection 

The theory analyst keeps track of all the theory and the algorithms.
Tel: 08-6058234
Cellular: - 
e-mail: e92_mef@e.kth.se
Anders Kjellström
(AK)

DSP Technician 

The DSP technician is responsible for placing the DSP in its environment and for keeping it going.
Tel: 08-6416158
Cellular: 073-9154492 
e-mail: e96_akj@e.kth.se
Johan Abramson
(JA)

Matlab Expert 

The Matlab expert implements the algorithms in Matlab
Tel: 08-304683
Cellular: - 
e-mail: e95_jab@e.kth.se

 

3.2 Project Support

Name
Post
Contact
Peter Händel
 Examiner
Tel: 08-790 7595
ph@s3.kth.se
Martin Nilsson
 Project Assistant
Tel: 08-790 8462
mnn@s3.kth.se
Leck Leng Chye
Chan Wai
 DSP support
Tel: -
s3dsp@s3.kth.se
Svein Olsen
 Laboratory equipment boss
Tel: 08-790 8441
svein@s3.kth.se
Javier Andersson-Esteva
Love Hörnquist-Åstrand 
Jimmy Engelbrecht
 Computer support
Tel: - 
s3dator@s3.kth.se
Monica Ringheim
 Course registration
Tel: 08-790 7294
monica@s3.kth.se

 
4 Project-model
The project is divided into the following milestones:
 

 
Final date
Milestone
Responsible
Document
2000-03-24

Project planning

The project will be planned and the schedule will be determined. The tasks will be divided among the project members.
MH
Project plan
2000-03-31

Matlab simulation

Theories will be examined and tested thoroughly in Matlab
JA 
Algorithm report
2000-04-14

DSP-implementation I

In the first part of the DSP-implementation, the detection theory tested in Matlab will be implemented. The beep will be replaced by silence.
MF
Implementation code I 
2000-05-19

DSP-implementation II 

In the second part of the DSP-implementation, the beep will be replaced by an approximation of sound and the real-time performance will be taken care of.
MF
Implementation code II
2000-05-30

Presentation

Demonstration, oral presentation will be prepared. Also the final report and doc­ument­ations will be published.
MH
Final report
5 Comments on time plan and resource plan
The project is planned with man-hour as the least unit.
 
The time plan is supposed to show how the project milestones are spread with an even work effort. The time plan will be updated once every week so that the work progress can be monitored and delays can be detected.
 
The resource plan is supposed to show how much work that has been put down day by day. The calculated time is 1440 hours total since 6 credits × 40 hours × 6 persons = 1440 hours. The planned daily effort is roughly calculated with the same effort every day and 180 hours a week for 7 weeks.
 
Mondays, Wednesdays and Thursdays are the days that have the highest priority. Every Thursday, first thing in the morning, there is a project meeting.
Both time plan and resource plan are appendixes to this project plan.

 
 
6 Documentation
The paper documents in the project will be stored in a common folder. The folder is stored in the laboratory and are divided into following parts:
·Project plan
·Weekly reports
·Time plan
·Resource plan
·Outside material: Material produced outside the project
·MH: personal notes
·HL: personal notes
·MF: personal notes
·FM: personal notes
·AK: personal notes
·JA: personal notes

 
 

The computer documents will be stored on the local network at \\Buger\c\Project .

Once a day when a document has been modified will a copy of that document be stored on a diskette located in the project folder. Once a week a backup copy of all documents at \\Buger\c\Project will be made at /home/e96/e96_hlu/project/ at the elektro-kth student network. This backup copy will be made by HL.
 
 

7 Risk analysis
A risk analysis has been done to predict future problems so that measures can be taken in order to prevent the problems. The risk analysis has been done according to “The Minirisk Method”.
 
I = influence on the project
P= probability that the problem occur
F= risk factor
Responsible= the person who should try to prevent the problem
 
The leading question asked for the risk analyze was:
“What can stop us from finishing the project before 30th of May?”

 
Risk
Measure
Responsible
P
I
F
Technical problems related to the DSP.
Study the DSP as soon as possible both in practice and theory. 
AK
4
3
12
Real-time problem requires assembler coding.
Optimize the C-code and the algorithms with respect to speed.
MF
2
4
8
The chosen method doesn’t cope the real-time requirement no matter what. 
Choose method carefully and try to make it scaleable.
HL
2
4
8
C-implementation is trickier than suspected.
Try to refresh old knowledge with help from books and the web.
MF
3
2
6
Difficulties to find appropriate methods.
As soon as possible start to document different methods and ask for help if needed.
HL
1
4
4
8 Appendix
[Signaler, Sensorer & System] [KTH]