Conclusion/Finished Product

After making the final amendments to the product, it is now felt that the application is capable of carrying out its primary objective which is to monitor the user’s exposure levels to sound and produce personal analysis and access the user’s risk of developing noise induced hearing loss. It is also believed that the addition of the real time spectrum analyser will be a beneficial feature for the user.

Future Work and Limitations

In terms of future work there are a number of improvements which are planned. One such improvement includes saving the graphs shown during the monitoring process for viewing at a later stage. This will be possible as the information used to generate the graphs is being saved in an array and is set to record up to 500 hours of data at a time, subject to the memory available on the user’s device. This graph will then be included for the user to show their exposure levels over time, at the end of their session.

Another planned improvement is to allow the user to view their frequency spectrum analysis whilst the monitoring process is happening. Information will also be extracted from the spectrum analyser to show the user their exposure levels to various frequencies over the course of their session.

Furthermore it is felt that the option of saving the user’s personal assessment at the end of the session would be beneficial. There are a number of ways in which this could be achieved. One such method would include giving the user the opportunity to email the assessment to his/her self, or alternatively the information could be saved within the application for comparison to other sessions.

In addition to these changes, it is also felt that the application would benefit from a frequently asked questions page. While this information will be displayed on the companion website, it could present a problem to the user if they wish to use the application without an internet connection. It is felt that this change can be easily incorporated in to the application and would be another beneficial feature for the user. While only two responses from the alpha testing focus group has received at this stage, one respondent mentioned that a frequently asked questions page would probably be better placed within the application as opposed to on the companion website alone.

It is also felt that the application has potential to become a franchise, and multiple versions of the application could be made available for different purposes. For example an application could be created for the live music industry resulting in a product which could be called Ear Bud live. Accordingly other uses for the franchised products have been considered with a view to exploring these opportunities in the future. Two of these ideas include:

1. Ear Bud Construction – An application specifically aimed at the building trade to ensure the health and safety of the hearing of building trade workers. While ear muffs are commonly worn on building sites, this information would be incorporated in to the assessment.
2. Ear Bud Home – An application targeted at the landlords of student accommodation. Allowing landlords to monitor the dB level of their accommodation, they would then be able to work out an agreement relating to volume levels in the contract with the tenant(s). As students can be noisy tenants and complaints are sometimes made to the landlords, this application would aim to work towards reducing these complaints.

Above are the bases of ideas which have been considered for the future. Whilst they require a lot more research and work, it was felt appropriate to mention such ideas to demonstrateawareness of the potential franchising opportunities of Ear Bud in the future.

One limitation of the project has been the lack of experience of the developer. In the early stages of development this meant a lot of time was spent learning how to code and operate the relevant software. Such exercises may not have been required had experience been present, and as a result more time could have been spent on the development of the application.

Another limitation of the project has been the amount of relevant variables to consider while trying to ensure the accuracy of the results picked up by the microphone. Given the time constraints of the project, it was felt that the best way to deal with this would be to insert a gain slider on the home page to allow the user to calibrate their microphone for best results. Whilst this offers a temporary solution, work will be undertaken in the future to find a better solution and incorporate this in to an update.

 

Summary

As the developer has had no previous experience in coding, apart from some basic HTML, the project has been a significant challenge and a huge learning experience. Skills have been obtained in action script 3.0 and in coding as a direct result of the major project process. Given the current state of the application it is felt that the project has been a successful effort, and particularly so as no previous experience was present.

It is felt that resourcefulness has been demonstrated in areas of weakness. One such example of this would be the recognition of poor skills in the area of graphic design. As a result of this, a graphic designer was hired and a new logo was produced giving the application a much more professional appearance. It is felt that the awareness of issues such as these throughout the project has supported the developer’s efforts to produce the product to the highest possible standard.

It is felt that good time management skills have been implemented in order to achieve the desired outcomes, despite the time constraints of the project. It is also felt that good project management skills have been implemented by regularly checking the progress of the project. A product development process such as the one undertaken in this project may normally have a team of experienced individuals to develop the product. Similarly such a process may also have a large budget. Ear Bud has been developed with a low budget from the beginningand without a team of experienced individuals. Despite this, it is now felt that the application is functioning as desired at this stage.

Upon completing the development of the product and implementing the final amendments, it is felt that the application is now ready to be used as a useful resource for the target audience. It is also felt that the application is presented well in terms of the overall aesthetics. Fundamentally, given the implementation of the planned future updates mentioned in this report, it is believed that the application will serve as a professional and useful product that is fit for purpose.

Final Product Ammendments

Implementing frequency spectrum analyser

At this stage the spectrum analyser was implemented in to the application and placed on the same page as the sound pressure level monitors. A problem was then encountered as both the spectrum analyser and the sound pressure level monitors could not function simultaneously on the same page. It was suspected that this was due to both elements trying to access the information from the audio buffer and as the buffer was regularly emptied, the second element which tried to retrieve the information was unsuccessful as the buffer was always emptied by the first element.

A new class was created to independently handle the microphone and microphone settings. This new microphone was set up to read the information from a copy of the audio buffer which meant that in theory, both elements should have been able to access the information. Despite this attempt, the effort was unsuccessful. It was then anticipated that the problem may lie in the FFT and/or spectrum analyser code.  As this code was outsourced and an API reference was sought after but not available (see appendix eight), it was decided that the spectrum analyser would have to be placed on a separate page. The user will still be able to see real time spectrum analysis within the application (see appendix eleven). However this will be a feature within the application that will be separate to the user’s assessment. It is anticipated that this issue can be resolved and incorporated in to an update shortly after the completion of the final product.

Calibrating the dB level within the application

Upon discovery of inaccurate dB readings from the application, it was found that the microphone needed to be calibrated in order to achieve accurate results. For comparison purposes two separate established sound level meter applications were downloaded. White noise was played through speakers on an iMac and recorded on the ear bud application via an iMac, the dB Volume application on the iPhone 6, and the Sound Meter application also on the iPhone 6. The position of each microphone was taken in to consideration and all of which were placed beside each other during the recording process in an effort to achieve the most accurate results possible.

An average of both the dB Volume and Sound Meter applications was calculated. The average intensity level recorded from the Ear Bud application was then divided by 100 and multiplied by the average calculated from the other two applications to find the figure which is equal to 1dB in the Ear Bud application. This was then incorporated in to the code of the application in to a dB scaler in an effort to achieve more accurate results (see appendix nine). It was felt that this exercise was beneficial to take advantage of the research and work completed from the developers of the established applications.

It has been recognised that there are a number of variables whichaffect the accuracy of the results. One such variable includes the microphone on the user’s device. While it is not possible to calibrate all of the compatible microphones at this stage due to time constraints, a temporary solution was found. It was felt that it would be beneficial to include an option for the user to calibrate their microphone to achieve best results. A gain slider was inserted on to the home page of the application which allows the user to set the gain level of the microphone from 0 to 100%. This change allows the user the opportunity to calibrate their own microphone using a variety of methods such as referencing any reliable dB meter or tone generator. Instructions on this process will be made available on the companion website. However this is seen as a short term solution and a permanent solution will be implemented shortly after the final product is complete.

Other Amendments

While only one alpha tester has provided feedback so far, an interesting comment was made. The tester pointed out that the ‘purpose should have been more clearly explained within the app’. As a result the homepage was redefined and it is felt that the purpose of the application isnow explained more clearly (see appendix ten).

In addition the page which monitors the user’s assessment was also tweaked. At the alpha stage the two waveform graphs were overlapping. This issue has been resolved (see appendix twelve). On both this page, and the frequency spectrum analysis page, the text has been made smaller and moved outside of the grey box. This allows for a cleaner look and a larger view of the waveforms.

The personal assessment page at the end of the session has also been edited (see appendix thirteen). It now clearly states whether the user is at risk of developing noise induced hearing loss, thus reinforcing the purpose of the application. The text displaying the peak sound pressure level (SPL), mean SPL, and recording duration has also been placed closer together and has been reduced in size. Additionally a message has been placed on the page which informs the user that they can take a screen shot of the page to view their results at a later stage.

App Sent for Alpha Testing

Today the alpha version of the application has been published and sent for alpha testing. Feedback is expected in the coming days. Last minute bugs and problems are also being worked through in order to improve the final version of the product. One such problem includes the spectrum analyser not functioning on the same page as the waveform and sound pressure level graphs.

App and Questionnaire Prepared for Alpha Testing

Recently, the final adjustments have been made to the application to prepare for alpha testing. Of these changes, the two most recent ones include:

• An advisory note on the homepage regarding the placement of the user’s device for more accurate results.
• The inclusion of the elapsed time and mean dB data in the user’s assessment.

The above images show the 3 steps of the application at the alpha testing stage.

The images below show the questionnaire which will be used to receive feedback from the alpha testing focus group.

Spectrum Analyser Functioning Within Application

Today, I spent time working on inserting the spectrum analyser to my application. It was decided that the best way to achieve this at this time was to insert the analyser in to a movie file and place it on the stage. This allowed for the analyser to function on the 2nd page of the application as was intended, and did not require it to be functioning on the other pages of the application.

(Spectrum Analyser functioning within the application)

The microphone code written in to the application earlier, has the ability to record the SPL in real time. It was decided at this stage, that this information alone will be used to determine the user’s assessment at the end of their session. This means that whilst the user will be able to see the frequency spectrum analysis in real time, their assessment will be based on SPL level alone.

This decision was made in order to ensure enough time for alpha testing, and also because at that stage the application will still be closer to a minimum viable product. However, beyond that point work will begin to base their assessment on additional parameters, the most important of which being frequency.

It should also be mentioned that the new logo has now been inserted. As well as this the colour scheme and the font has been changed in order to give the application a more modern look. I feel that this has worked very well so far and it greatly improves the aesthetics of the application.

Frequency Analysis

Today I performed a frequency analysis of the recordings which were made during the white noise experiment, previously mentioned in this blog. One of the most interesting findings of the analysis revealed that the iPhone captured frequencies beyond 11 kHz approximately 33 dB lower than a Shure SM58 dynamic microphone, and 29 dB lower than that of an AKG 414 B condenser microphone with a cardioid pattern.

(Image above: Yellow = iPhone 6, Light Blue = Shure SM58, Pink = AKG 414 B)

A Samsung Galaxy S6 phone was also used for the recording process. However it was found that the recordings produced with this device has a set sample rate of 8,000 Hz meaning analysis was only possible up to 4 kHz. Although this limited the range of the spectrum analysis, it was still found that this microphone performed similarly to the iPhone 6 on the frequencies that could be seen (see below).

(Image above: Red = Samsung Galaxy S6, Yellow = iPhone 6)

This exercise has made me aware that it may be beneficial to produce customised E.Q settings for certain devices. However, more research would be needed before making this decision. Additionally, the focus at the moment is on producing a minimum viable product for alpha testings, and beyond that point I will be enabled to explore the finer details of the application.

Studio/Viva Prep/New Logo/Website

The past few days I have been very busy working on my application and preparing for my viva presentation this coming Monday 23rd March. Last Friday I spent a few hours in the studio conducting an experiment which involved playing white noise through the speakers and recording this using a variety of microphones. The microphones used were:

AKG 414-B.

Shure SM58.

iPhone 6.

Samsung Galaxy S6.

(Recording white noise in the studio)

I am currently performing a frequency analysis on each of the recordings captured and will compare these to the source file. I am also taking in to consideration the specification of the speakers used in the studio. If needs be following the analysis. It may prove useful to build personalised EQ settings for certain devices.

(Performing frequency analysis on white noise recordings)

Approximately one week ago, I hired the services of a graphic designer to produce a new logo for the application. I also commissioned the designer to producer a separate logo to act as the icon on the user’s device. Having imported the new logo to the application, I feel that it greatly improves the aesthetics of the overall application and allows for a more professional brand image. I have also decided to changed the colour scheme within the app to black, white, grey and purple. I am aiming to achieve a clean and uncluttered look. For this reason, if I was to visually compare the ear bud application to another brand at present, it would be Apple. Both of the new logos can be seen below.

Additionally. I have also been considering the possibility of developing a companion website for the application, so I have purchased the following domain name: http://www.ear-bud-app.com. As I have just purchased the domain, the website has not yet been developed and a result the site is not live.

FFT/Spectrum Analyser Functioning

Using the code from Gerry Beauregard who is mentioned in an earlier post, we can see below the spectrum analyser is functioning.

However, I felt that a number of changes were necessary to make the analyser suitable for my application. One such change was to provide a broader real time spectrum analysis to allow for the range of human hearing, which is 20Hz – 20KHz. To achieve this I began by increasing the maximum frequency number on the horizontal axis to 20KHz (20,000 Hz). However the box was too small to fit all of the numbers in, and I did not wish to increase it as I was conscious of the limited screen size that may be available on the users device. I then decided to increase the frequency steps/intervals from 500 to 1,500 Hz. I also changed the colour of the lines in the graph to blue, using hexadecimal colour codes. Photoshop proved useful here as I was able to choose the exact colour I wanted, and instantly retrieve the hexadecimal code for that number. The adjustments I made to the code can be seen below.

And after making these changes, the spectrum analyser looked as shown below.

It then became apparent that the spectrum analyser was not reading any frequencies just above the 11 KHz mark. I looked back through the code and quickly discovered why. The sample rate was set to 22,050 Hz. With reference to the Nyquist rate, it is understood that the sample rate should be at least twice the maximum frequency responses. I then increased the sample rate to 44.1 KHz and the analyser was now capable of reading the entire 20 Hz – 20 KHz range, as desired (see image below).

Focus Group Established/Code Implementation

I have contacted 7 music studio producers to ask for their participation in alpha testing. Of the 7 contacted, 5 replied and have agreed to take part. They are:

Patrick Wall – DFEi

Colm Quearney – BIMM/Q Studios

Paul Woodward – Paul Woodward Studios

Dan Thomas – London based music producer

Richard Duckworth – Trinity College Dublin

Also, today I began to implement the packages obtained from Gerry Beauregard who is mentioned previously in this blog. These packages offered an FFT and a Real Time Spectrum Analyser. In order to ensure I implement these packages correctly, I have contacted Gerry and asked if there is an API reference available for the packages. I await his reply.

Semester Two Timetable

I have created a timetable for semester two which has been used to keep me on track with my project. The timetable can be seen below.