Musical Instrument Acoustic Comparison

Bryan Aguiar, Trenton Fengel, Emerald Kunkle

California State University Monterey Bay

CST 499: Computer Science Capstone

Client: Jonathan Shu

Faculty Advisor: Bude Su

Summer Term B
 i

Executive Summary

The purpose of this project is to provide musicians, audiophiles, and audio engineers an

audio comparison application. The main goal for this project is to empower musicians to make

sound decisions when purchasing instruments/musical peripherals based on tonal preferences.

This will be achieved by the main objective–to build out side-by-side graph comparisons of the

frequency spectrums, amplitudes, and spectograms of two instruments.

Musicians. Audiophiles, and audio engineers are a wide group of people with varying

diversity. According to the American Federation of Musicians, they represent nearly 80,000

musicians in the United States and Canada. The count refers only to professional musicians that

are part of this union, but the amount may be greater due to the open availability of music. Using

the audiophile subreddit, we can see that there are at least 1.8 million users. Musicians and

people who appreciate music can be anywhere in the world, so it is important to develop a

solution that makes people with more specific requirements able to make decisions that suit their

tastes. We expect users to be able to take this app into music stores and be able to record while

shopping.
 ii

TABLE OF CONTENTS

PAGE

PART I

● INTRODUCTION .......................................................................................................................... 1

● FEASIBILITY ................................................................................................................................ 1

○ Environmental Scan ........................................................................................................... 1

○ Evidence of Need ............................................................................................................... 2

○ Ethical Considerations ....................................................................................................... 3

○ Legal Considerations ......................................................................................................... 3

○ Long Term Life of End Product ......................................................................................... 4

PART II

● DESIGN REQUIREMENTS ......................................................................................................... 4

○ Overview ............................................................................................................................ 4

○ Platform .............................................................................................................................. 5

○ Major Functions ................................................................................................................. 5

○ Usability Test Plan ............................................................................................................. 6

○ Usability Testing ................................................................................................................ 6

PART III

● FINAL DISCUSSION/REFLECTION ........................................................................................... 7

○ Timeline/Budget ................................................................................................................ 7

○ Final Implementation ......................................................................................................... 8

○ Discussion .......................................................................................................................... 9

REFERENCES ........................................................................................................................................... 11

APPENDIX ................................................................................................................................................ 12
 1

Part I

Introduction

Musical Instrument Acoustic Comparison

Our team plans on developing a mobile application that allows musicians to analyze and

compare the sonic characteristics of two different instruments. Once the user finds an instrument

they want to analyze, they will record themselves playing a chord or a few notes. Next, they will

record themselves on another instrument playing the same thing they did in the first recording.

This will allow the app to make a proper comparison of two instruments both playing the same

thing. The user will then be able to view side-by-side comparisons of the frequency spectrums,

the amplitudes, and the spectrograms of both instruments. The musician can then save the audio

information which can be used for later comparisons.

Feasibility

Environmental Scan

Upon completing an environmental scan, there exists many different sound analyzing

applications. Searching the google app store with the terms ‘Sound Spectrum Analysis’ or any

variation of those terms, leads users to the Spectroid App. At the time of writing, Spectroid has

4.6 stars based on 11 thousand reviews and sitting at over 1 million downloads. Other apps

recommended are as follows: Audizr - Spectrum Analyzer, Advanced Spectrum Analyzer PRO,

Sound Spectrum Analyzer and the list goes on, but none of the apps share the same success as
 2

Spectroid. On further review of all applications, a trend appears where only real-time analysis is

allowed for one instrument at a time. Spectroid, for example, analyzes real-time audio to

determine the frequency domain of the recording sound.

The Musical Instrument Acoustic Comparison app will differentiate from Spectroid and

other similar applications. The first difference is that our application will attempt to utilize four

different parameters for our sound analysis. Another difference, as you can see from our title, is

our application will provide a comparison between two similar instruments and return the results

of the comparison. The con to the approach we are taking is that it makes analyzing real-time

audio nigh impossible because we will be taking audio samples from two different instruments.

Our team believes this approach will allow users to record different samples while at a music

store, and make the best informed decision based on their needs.

Evidence of Need

The project is needed because it has the potential to optimize the decision making process

for musicians looking to purchase an instrument that meets certain criteria. This project will also

be useful to audiophiles trying to make informed decisions on audio peripherals. The range of

difference that two of the same instruments can have makes comparison paramount, lest the

consumer overpays for an instrument ill-suited for their needs. Music is a hobby loved by many

as made apparent by the 30 million users on the Music Subreddit and nearly 2 million users on

the Audiophile subreddit(About Community, reddit). With millions of dedicated music

appreciators in the world, there is a huge market for musical instruments and music-related

peripherals. Musical instruments have a myriad of nuances that even the most well-trained ear
 3

struggles to hear; those struggles can be alleviated via technology with only a few taps on their

phone.

Ethical Considerations

Mobile Applications have one obstacle to entry: Prospective users must have an

android-based phone with access to the internet. The necessity of owning a phone may impact

low-income individuals. However, programs such as the Federal Lifeline Assistance program can

distribute phones to the low-income population for free. Our specific application does have an

optional requirement of requiring instruments for sound analysis which may be difficult for

disadvantaged users, but the app would still be functional by using any saved recordings.

One ethical concern that comes to mind would be the accessibility for the blind. A lot of

smartphone applications that provide accessibility for the blind allows for text-to-speech

descriptions of many visual images or icons. As we will be comparing statistics between two

audio files, a lot of our comparisons will be heavily visual-based, and thus difficult to rely to

blind users. One possible work around would be to relay only the numerical differences between

the two files to the user through text-to-speech, if they require so.

Legal Considerations

One possible legal challenge may be the storage of a user’s audio and recordings. This

could potentially conflict with copyright laws if any of our users have a copyright to any audio

uploaded on the app. No other user will be able to hear or access another’s audio files, however

the storing them itself could potentially be an issue. One work around could possibly be a terms
 4

and conditions page that a user must accept in order to use our app, and through said terms and

conditions we can gain formal permission to store any copyrighted material they want to upload

onto the app.

Long-Term Life of End Product

Our final product will be an android application available as a free download online. We

will provide a link for our client to download this application onto their mobile device upon its

completion, however it is not an end goal for the project to be uploaded onto the Google Play

Store. After release, there is no intention to update or patch the application.

Part II

Design Requirements/Usability Testing

Overview

The expectations user’s should have of our solution are that of a complete audio analysis

program for recording and analyzing short audio samples between two different audio sources.

The end user can expect the ability to record their own audio samples, load and playback the

audio snippets, make calls to analyze the two chose audio samples, and view a display of the

chosen audio samples. What the user is required to do is enable permissions on their device that

allow the device to record and save files to a created folder. The user is assumed to know basic

functions of a mobile application and have some knowledge of audio statistics to be able to

understand what the analysis is showing the user.

 5

Platform

Our product will be created using several platforms, including SpringBoot for the

backend, and Ionic for the frontend. SpringBoot was chosen for the backend because of our prior

experience with it in another class, as it was a platform the team was all already familiar with.

Ionic was chosen because it is a cross platform toolkit that allows programmers to create mobile

applications using web technologies such as React and Node.js which our team members are

familiar with. Our app will most likely be used in music stores by musicians who wish to analyze

instruments before making a purchase, so it’s important that the app is mobile.

Major Functions

Functions User Requirements

Google Authentication Users will be able to store their sessions on

their google accounts. Pending the acceptance
of permissions.

Recording Audio Users will be able to record short snippets of

audio samples.

Loading Audio Users will be able to load and playback

previously recorded audio samples.

Analyzing Audio Users will be able to query our backend to

analyze the sent audio samples.

Graphing Audio Users will be able to graph the loaded samples

and view the attack and sustain times.

Selecting Graph Users will be able to block the information

from one graph to display the singular graph
without the overlay.
Figure 1. Major Functions
 6

Usability Test Plan

● Goals for usability test plan: Have target audience get hands-on experience and get

accustomed to our application; have users test the recording function, the loading audio

function to test audio selection and playback, the analyzing audio function to test sending

audio to our server, and the graphing audio function to test displaying the chosen samples

in a meaningful graph.

● Target Audience: Musicians, Audio Engineers and audiophiles

● Evaluation: Due to hands-on nature of the test plan, the test plan evaluation will be a

straightforward survey conducted by the team thats asks for feedback on the functional

features of the application.

● Procedure of actual project testing: One of our team members will physically go to a

music store to obtain real-life audio clips with the app. Using these clips, our app should

be able to compare the two. This form of testing can be repeated across different types of

instruments, as long as there’s two available to test.

Usability Testing/Evaluation

The app was tested by a team member and out client. Audio was able to be recorded and

played back. Two previously recorded audio files can be selected and played back. These two

files can be compared and graphed. Multiple trial runs have verified all these steps are

operational.

The results of the testing showed that all functionals were functioning and that navigating

between the screens was seamless. Issues arose with login functionality, but a workaround was
 7

implemented to allow testing to continue. Everything recorded fine and it was noted that

potential background noise may be affecting our graphs.

Part III

Final Discussion/Reflection

Timeline/Budget

Our milestones for this project in large part were able to be met in the timeline. One

element of the time allotted that took more resources and time than previously anticipated would

be the integration of the front and back end of our project. We had previously estimated that it

would be able to be accomplished in a week, perhaps two if need be. However, the integration of

the front and back end ended up being a multi-week process that went through many iterations to

accomplish the communications we were striving for.

Another time sink that caught us by surprise was the Google authentication process.

Originally, we sharply underestimated how long it would take to do the sign in process on our

login page, mainly because we were relying on the functionality of Google authentication to step

in and alleviate that effort. However, in trying to integrate Google authentication, we

encountered a myriad of problems that began consuming more and more of our time, to the point

where it was decided that we cut the Google authentication process and instead introduce our

own authentication and login to the application. While the extra time wasn’t something that we

had accounted for, the control over the sign in granted us the means to be able to finish this stage

of our project and progress forward.

 8

Finally, our budget for the project laid within a three hundred dollar budget. Originally,

no budget was anticipated, but one of our services we utilized was a paid one, but had a trial of

three months or three hundred dollars of their service, depending on which came first. We

managed to stay well under the three hundred dollar limit.

Final Implementation

The final product is a frontend/backend application-based solution that records audio

samples, analyzes those samples, and returns graphical information on two selected audio

samples. The application also stores the user’s save files on a database on the backend; the

solution allows for easy access across different devices.

 9

Figure 2. Final Implementation

As for the backend portion of the application, it is currently run on a Google Cloud

Platform (GCP) engine. This allows for many users to access the backend and get their audio

analyzed. Using GCP, also made it easier for us to store the user’s data on the backend, and made

it easier to request for the data as well.

Figure 3. Background Implementation

Discussion

Like previously mentioned in the timeline section, multiple problems have arisen during

our project. These issues hindered our progress, but at every hurdle we have either managed to

overcome it, or find an alternative solution that accomplishes the same feature seamlessly.

One of the issues we encountered was finding a way to send information back and forth

between the frontend and backend. Initially, we were going to host our backend on Heroku, and

use Google Drive API to store and retrieve files. After struggling to install the Google Cloud API
 10

without errors via Node.js we decided to run our Spring Boot backend on a Google Cloud virtual

machine. The files were stored on the virtual machine and retrieved using a python server script.

Another issue we faced was during deployment of the app. Our REST API was using the

HTTP protocol to send information; however, Google App Engine (the deployment service we

used) only permits the HTTPS protocol. We had to learn how to implement HTTPS requests last

minute, which still has some errors because we would have to store a digital certificate with a

certificate authority which is expensive. This made implementing our login system difficult.
 11

REFERENCES

About Community. reddit. (2008, September 15). Retrieved June 18, 2022, from

\https://www.reddit.com/r/audiophile/

Reinke, C. (2018, August 6). Spectroid. Google. Retrieved June 18, 2022, from

https://play.google.com/store/apps/details?id=org.intoorbit.spectrum&hl=en_US&gl=US
 12

Appendix

Team Members and Division of Work:

Bryan Aguiar: Purely backend work - Java/Python. Receiving Audio Files and working with the
GCP to allow our solution to run continuously in the backend.

Trenton Fengel: Mostly frontend work - Used React and D3.js to create the data visualization.
Helped setup communication between the frontend and backend.

Emerald Kunkle: Purely frontend work - React and Typescript work, login page layout,
frontend-only features.

Figure 1. Major Functions (Page 5)

Functions User Requirements

Google Authentication Users will be able to store their sessions on

their google accounts. Pending the acceptance
of permissions.

Recording Audio Users will be able to record short snippets of

audio samples.

Loading Audio Users will be able to load and playback

previously recorded audio samples.

Analyzing Audio Users will be able to query our backend to

analyze the sent audio samples.

Graphing Audio Users will be able to graph the loaded samples

and view the attack and sustain times.

Selecting Graph Users will be able to block the information

from one graph to display the singular graph
without the overlay.
 13

Figure 2. Final Implementation(Page 8)

Figure 3. Background Implementation (Page 9)