
Abstract
—Though people often have their cell phones with them at all times, there are many situations where it is not appropriate for a cell phone to ring or the ringing of a cell phone may not be noticeable due to the surrounding environment.
Through research, we have implemented an application and accompanying modifications to the Android Operating System source code to implement a system which intelligently chooses a ringtone for the phone based on the characteristics of the surrounding environment. This is done through the manipulation of both the volume of the ringtone and by changing which ringtone is actually played.
Index Terms
—Signal Processing, Android, Smartphones,
Source Code Modification, Frequency Analysis, Audio Encoding,
Ringtone, Audio Sampling
I.
I NTRODUCTION
T HE purpose of the research which has been conducted is to create a system which intelligently chooses a ringer volume and ringtone for a cell phone which is consistent with the environment that surrounds the phone. This is necessary for several reasons. When in an environment where it would not be appropriate for a cell phone to start ringing, there are usually several prominent characteristics. Most importantly, the surrounding environment is usually very quiet. Because of this, our system monitors the intensity of the sounds in the surrounding environment and chooses a volume for the ringtone accordingly. If the intensity of the sounds in the surrounding environment is below a certain threshold, the phone will only vibrate instead of ringing. At the other end of the spectrum, there are many situations when the intensity and spectral content of the sounds in the surrounding environment of a phone cause the ringing of the phone to go unnoticed. In these cases, our system samples both the spectral content of the surrounding environment and the intensity of the sound and chooses a ringtone which is an appropriate volume so that it will be heard and also an appropriate ringtone so that the spectral content of the ringtone creates contrast with the ambient sounds.
Christopher Daffron is an undergraduate student in the Department of
Electrical Engineering and Computer Science at The University of Tennessee,
Knoxville, TN 37996 (e-mail: cdaffron@utk.edu).
Alex Hoppe is an undergraduate student in the Department of Electrical
Engineering and Computer Science at The University of Tennessee,
Knoxville, TN 37996 (e-mail: ahoppe@utk.edu).
This research was performed under the supervision of Dr. Wei Gao,
Department of Electrical Engineering and Computer Science, The University of Tennessee, Knoxville, TN 37996 USA (e-mail: weigao@utk.edu).
II.
O VERVIEW
In the Android Mobile Operating System, there are several layers in the architecture. The lowest layer in the operating system is the Linux Kernel, which is where the drivers for all of the hardware are stored and controlled. Above that, there are many libraries which are used by various other parts of the operating system. The Android runtime is a subset of these libraries and provides the core libraries of the operating system and Dalvik Virtual Machine, which is the Java virtual machine in which all of the applications on the device run.
Above that layer is the Application Framework. This layer of the architecture provides the key frameworks which are used by many of the applications on the device, including the location manager, notification manager, and the telephony manager. The top layer of the Android architecture is the application layer. This layer contains all of the included applications for Android and also the applications that the user installs on the device. For this research project, the work that has been done lies in the application layer but required the operating system to be recompiled from source. There are two reasons that the project had to be recompiled from source to fit the necessary purposes of this project. The first is that there is no way to prevent the phone from ringing when the incoming call is detected without having access to the source code of the
Phone application. An early work-around for this was to silence the phone’s ringer when it started ringing and then set the parameters of the ringtone accordingly once the analysis of the surrounding environment was complete, but this led to the second reason that the modification of the source code was necessary. After the phone has started to ring, it is impossible to change the content of the ringtone. It is possible to change the volume of the ringtone while it is ringing, but not which ringtone is actually playing.
1

2
Fig. 1. Hierarchical architecture of the Android operating system
III.
M ETHODS
A.
Sampling
Once the problem to be solved had been well defined, the first issue that needed to be resolved was what sampling method would be used. Three sampling methods were proposed. These options were continuous sampling, periodic sampling, and on-demand sampling. Continuous sampling is the easiest of all the sampling methods to implement because it is always listening to the surrounding environment and is constantly running calculations on the sampled data to continuously update the volume of the ringtone and which ringtone is selected. This method of sampling has an extremely negative effect on battery life because the processor of the phone is always active both sampling the surrounding environment and running calculations on the collected data to determine the best parameters for the ringtone. Because of the impact on battery life, this method was not chosen for sampling. The second method, periodic sampling, mitigates some of the negative effects on the battery by periodically sampling the surrounding environment and running calculations on that collected data. This method has two important advantages over the other methods, it improves the impact on the battery life as mentioned above and it also gets around the need to modify the android kernel to be able to change the volume of the ringtone. For this reason, this sampling method was utilized in a previous version of the application which only changed the volume of the ringtone and not the type of ringtone played. This sampling method does have a significant disadvantage, though. Depending on the amount of time between samples, the current conditions that the phone finds itself in could be dramatically different than those that surrounded it when the sample was taken.
Because of this, the volume of the ringtone that the phone plays could be inappropriate for the surrounding environment, thereby reducing the effectiveness of the application. The third sampling method which was considered and which was utilized in the final solution provided by this research was ondemand sampling. This sampling method provides the best of all the solutions because it allows for the optimal impact on battery life by only sampling when it is absolutely necessary.
It also eliminates the problems with stale data caused by the periodic sampling by taking the sample of ambient sound at the time that the phone needs to start ringing. The main drawback of this method is that it requires modification of the source code for the operating system because the phone application is included with the operating system and cannot be modified without changing the source code. It is also not possible to delay the start of the phone ringing without modifying the phone application. Before the modification of the phone application began, a method for sampling and processing the surrounding environmental sounds needed to be developed.
B.
Audio Recording
The first step in developing a sampling methodology was to write a sample application that recorded audio on an Android smartphone and provided the testing platform on which to implement the various sampling and processing methodologies. It was important to use data which was actually recorded using the smartphone and using the same process as would be implemented in the final solution because noise and other factors vary amongst different microphones and this particular solution was being designed to run on an
Android smartphone. It was also important to use samples of a uniform length because the startup of the recording process and microphone actually starting to record can introduce some noise into the very beginning of the recording, which has an effect on the overall characteristics of the recording which diminishes as the recording gets longer due to the stabilization period making up a smaller percentage of the overall recording. For this application, a recording time of half a second was chosen because it provides an adequate number of samples while not introducing a large amount of delay into the phone call process due to recording time and processing time.
The smartphone samples the audio at 44,100 Hz, so even only half a second of recording provides approximately 22,000 samples and frequencies between 0 and 20 kHz can be detected in the recorded audio. Through extensive online research and the Android developer resources, it was determined that the AudioRecord library which is built into
Android was the best to use. The AudioRecord library was chosen over the MediaRecorder because the AudioRecord library outputs raw audio data while the MediaRecorder library encodes data into one of several compressed audio formats before it is accessible to the application. For use in the debugging process, the raw AudioRecord data is encoded into a Waveform Audio File Format (WAV) file. This file is created using simple Java code, which is possible because the
WAV audio format is simply a 44 byte header followed by uncompressed raw data values. Outputting the raw data to a
WAV file was important for two reasons. First, having the
WAV file helps with the debugging process greatly because the raw audio data can be taken off the phone and used in a signal processing program such as MATLAB for use in developing signal processing algorithms. It is also important

3 because all of the raw audio data is not stored in the phone’s
RAM while it is being recorded. It is required to be written to a file in a separate thread at the same time as it is being recorded so that the one application does not dominate the
RAM usage of the phone while it is recording. Because the
WAV file format is used, retrieving the recording from memory and removing the header data to get to the raw audio values is trivial.
C.
Fourier Transform Calculation
Once the process for obtaining raw audio data values was complete, a Fast Fourier Transform (FFT) algorithm needed to be implemented in Java on the smartphone. Upon conducting internet research, a freely available algorithm written in Java was found from the Princeton University Computer Science
Department. The department also provided a supporting Java file that implemented a complex number class that was used when computing the FFT. The FFT algorithm that is utilized by the library is the Cooley-Tukey FFT algorithm. This algorithm emphasizes simplicity over speed, but still provides adequate speed to thoroughly process the data that is collected without taking an unacceptable amount of time. This is also partially due to the small amount of data that is collected over the half second of recording. If a longer recording time was to be used in the future or if the sampling rate was increased, a different, more speed optimized algorithm would be necessary.
D.
Calculating Intensity and Frequency
The first parameter which needs to be extracted from the recorded audio is the average intensity. This parameter is used to decide if a ringtone should be played or if the phone should only vibrate to alert the user of an incoming call. This decision is made based upon several preset categories into which the intensity value will only fit into one. If the intensity value is below a certain threshold, the phone decides to only vibrate to alert the user to the incoming call. Conversely, if the intensity value is above a certain threshold, the output value is then scaled into a number which is suitable for setting the volume of the ringtone to be played. Because of variances in different phones, the preset threshold and the mathematical function which is used to determine what level the volume should be set at are unique to each model of smartphone. For the purposes of this application, the values are all customized to work well on a Nexus 4 smartphone. There are two reasons why the threshold and scaling factor have to be customized to each phone. The first is because the range of values which are outputted in the WAV file can vary based upon the microphone which is used in the particular smartphone which is being used. The values which result from the Nexus 4 microphone can be found in the results section of this paper.
Second, the range of values which can be assigned to the ringtone volume varies based upon the model of smartphone being utilized. For some phones, there may be as few as seven different possible settings, while other phones may have fifteen to twenty unique volume levels. To find the average intensity, a basic understanding of how data is encoded in a
WAV file is necessary. In a basic WAV file, there is first a 44 byte header which tells basic information about the audio samples that follow it, such as the bit rate and the number of channels. Following that information are the samples. For the way that the recording is configured in the application, each sample is comprised of two bytes of data. Those two bytes are then interpreted as a double which is between negative one and one. The average intensity is then computed by taking the average value of the absolute value of all of the samples, as is shown in the java code below. for ( int i = 0; i < channel1Data.length; i++) {
sum = sum + Math.
abs (channel1Data[i]);
counter++;
}
avIntensity = sum / counter;
(1)
Once the average intensity of the audio samples has been calculated, the more advanced and computationally intensive task of finding the parameter defining the spectral content of the sample, which was then used to determine which ringtone should be played. To determine a measure of the frequency makeup of the sample, a method involving taking a weighted average was devised. While this method does not give a true representation of the spectral content of the recording and could also have the same number represent multiple different types of recordings, it does do a good job of giving a general idea of the content of a recording, which is enough to make the determinations that are necessary for this application. The method of finding the weighted average of the spectral content was to take the summation of the intensity at each frequency multiplied by the frequency and then divide that by the summation of all the frequency intensity values. This was accomplished using the java code below. for ( int i = 0; i < transformData.length/2; i++) {
numVals++;
rawSum = rawSum
+ transformData[i].abs();
sum = sum + transformData[i].abs()*I;
}
avgVal = sum / rawSum;
(2)
This code yields an average value which tells what the weighted average frequency of the recording is in units of samples, so it tells which index of the array of values in the
Fourier Transform contains the weighted average of the recording. To convert this value from units of samples to units of Hertz, the following code is used: avgVal = avgVal / numVals * (Fs / 2);
(3)
After running this code, the variable avgVal contains the weighted average value of the spectrum of the recording in units of Hertz. As noted above, this method of determining the characteristics of the recording does not give a true representation, but does describe the spectral content of the recording. This is because the weighted average is affected by the sampling rate of the recording. It is also because the weighted average of Gaussian white noise would be exactly

4 one quarter of the sampling rate. This happens because the weighted average of a uniform signal would simply be half way between the beginning and the end and, for the purposes of this algorithm, the end of the spectral content is at 22,050
Hertz, which is half of the sampling rate of 44,100 Hertz. This is because the Fourier Transform yields a spectrum which is mirrored around half of the sampling rate. From the results of this code, the dominant frequencies can be learned because various dominant frequencies will pull the weighted average towards them. For example, dominant low frequencies would have a weighted average less than 10,025 Hertz, and dominant high frequencies would have a weighted average higher than
10,025 Hertz. The stronger the dominant frequencies are, the more they will pull the weighted average towards them. Using this calculated parameter and predefined categories, the recording is matched to a certain category which determines which ringtone is played.
E.
Source Code Integration
Now that the algorithms had been developed, they needed to be incorporated into the source code. This is where several issues came up. There is an issue with trying to adjust the volume of an Android phone’s ringtone after a call has been placed. Due to what appears to be a limit in functionality, we were unable to reliably adjust the volume after the call had been placed. To get around this, we went into the kernel to interact with the phone application directly. To make our adjustments, we modified the Ringer.java file which handles the phone’s state following the broadcast receive from the
Radio Interface Layer, which is the abstraction layer between the Android Telephony service (phone application) and the radio hardware. However, all processes that we have need to be handled in a short amount of time due to a time limit on how long a caller will wait before a timeout is triggered on the caller’s end which will force them to go to voicemail thus missing the call. Some testing has been done regarding times that are able to be pushed to continually complete phone calls without noticeable delay by users.
TABLE I
D ELAY VERSUS S UCCESS
Delay(s) Phone(low) Phone(med) Phone(strong) Android
0.5
1.0
1.5
2.0
2.5
3.0
3.5
4.0
4.5
5.0
5.5
6.0
6.5
7.0
7.5
8.0
100.00% 100.00%
100.00% 100.00%
100.00% 100.00%
100.00% 100.00%
100.00% 100.00%
100.00% 100.00%
100.00% 100.00%
100.00% 100.00%
100.00% 100.00%
100.00% 100.00%
98.00%
88.00%
60.00%
42.00%
10.00%
0.00%
100.00%
90.00%
70.00%
50.00%
30.00%
10.00%
100.00% 100.00%
100.00% 100.00%
100.00% 100.00%
100.00% 100.00%
100.00% 100.00%
100.00% 100.00%
100.00% 100.00%
100.00% 100.00%
100.00% 100.00%
100.00% 100.00%
100.00%
100.00%
100.00%
82.00%
70.00%
50.00%
100.00%
90.00%
40.00%
20.00%
0.00%
0.00%
Google
100.00%
100.00%
100.00%
100.00%
100.00%
100.00%
100.00%
100.00%
100.00%
100.00%
100.00%
100.00%
100.00%
100.00%
90.00%
82.00%
Number of tests per type: 50
Key:
Phone(signal strength): Android HTC Evo 3d on the Virgin Mobile
Network (Sprint)
Android: A phone call app used from a Google Nexus 10 tablet
Google: Google Talk phone call from gmail used on desktop computer
So by that data, we could push upwards of five seconds to run all of the processing that we need to, but that much time would be noticeable by the caller due to taking longer to have someone answer the phone. As such by that data, we have determined that a good time to record would be 0.5 seconds, which is enough time to gather data that is meaningful and then enough time to process that data on the slowest available processors. Testing data about how much processing time is required can be found in the results section of this report.
To implement the functionality of the project, we injected our code inside the Ringer.java class before the ringtone starts playing. The changes are placed inside a function that checks if the volume of the ringtone is zero. This was a functionality decision due to it being a complex build to force the phone to not sample its own sound to adjust the volume erroneously to full volume. From there, the program simply runs the algorithms which had already been developed. A comparison of the functionality of the phone before and after our modifications is shown below.

Fig. 2. Original operating procedure for the phone
5 is to be played). This also brought up an interesting issue.
How will the user recognize that it is their phone ringing instead of somebody else’s phone if the ringtone changes every time the phone rings? As the solution to this, the ringtones are divided up into one of five categories and the user then selects one ringtone to be played for each category.
The ringtones that the user has to choose from for each category are only the ringtones that have been scanned and found to fit into that category. By doing this, the user only has to remember that their phone could be one of five ringtones, not one of hundreds of ringtones. The reason that the automatic scan of ringtones is phrased as theoretical is because, due to the built in software libraries of Android and their ability to decode compressed Ogg Vorbis files into raw data, the current version of the application has the weighted average frequencies of the built in ringtones precalculated and they are not dynamically placed into categories. Once that issue with the core functionality was resolved, the user interface of the application needed to be created. To go along with the look and feel of native Android applications, a sliding navigation drawer was chosen to navigate amongst the various pages of the application. This part of the interface is shown below.
Fig. 3. Modified operating procedure for the phone
F.
User Interface
Once the various algorithms were incorporated in the source code, a separate application needed to be produced to provide a user interface to the end user. While there should not be any user experience when the algorithms are in use and the phone is intelligently deciding the parameters of the ringtone, there does need to be a separate application to provide the user an interface to change settings regarding various parameters of the application and to test the sampling features of the application to ensure they are working as intended. The application also provides the interface which is used to initialize the list of ringtones on the phone. Theoretically, the first time the application is run, it will automatically scan all of the available ringtones on the phone and run them through the weighted average frequency algorithm so that it can automatically assign them into categories so that a contrasting ringtone is always played when the phone rings (if a ringtone
Fig. 4. Sliding Drawer Navigator Menu
As is shown in the screenshot, there are four different views within the application, the home view, the tone selection view, the sampling view, and the about view. The home view is shown below and provides several important features. The home view includes a ringtone sampler that allows the user to listen to any ringtone currently available on their phone. This is useful when choosing which ringtones the user wants for each category and prevents the user from having to go into a separate application to preview their ringtones. The view also includes buttons for the user to see what their current ringtone is and to set a new current ringtone.

6
Fig. 5. Home View
The next view listed in the navigation drawer is the tone selection page. This page provides a drop-down menu for each of the five categories of ringtones and allows the user to select which ringtone they want for that specific category. The dropdown menus are only populated with the ringtones that fit into that specific category, so the user is guaranteed to select an appropriate ringtone regardless of which one they actually select.
Fig. 7. Sampling View
The final view listed in the navigation drawer is the about page. This page simply provides some basic information about the research which produced the application, The University of Tennessee, and the names of the developers.
Fig. 8. About View
Fig. 6. Selection View
The third view listed in the navigation drawer is the sampling page. This page provides the user with a view of the currently selected ringtone and a button to manually trigger sampling of the surrounding environment and setting the appropriate parameters on their phone without having to actually receive a phone call. This page is important because it allows the user to test their selections on the previous page and also shows them some of the calculated parameters so that they can better understand what the application is actually doing.
Having completed the programming of the application, it was now time to thoroughly test all of the features which had been implemented.
IV.
R ESULTS
To begin testing of the application, 47 samples were collected. These samples were chosen to try to include a wide range of sounds and environments with various parameters changed slightly in the different environments while keeping the other parameters the same. Examples of this include the samples taken in a vehicle, where the speed of the vehicle and the presence of the radio were varied independently of each other. It can also be found in the samples taken walking down

a street, where some of them include traffic noise and others do not. A full list of the samples collected and a short description of them can be found in Appendix A.
Once the samples were collected, they were all run through the code shown in the previous section to obtain their weighted average frequency. This was necessary so that the frequency response of different environments could be obtained to see how well the application reacted. The list of weighted average frequencies of the samples can be found in
Appendix B.
The spectrums of several of these waveforms were then graphed to look for noticeable trends. Some of the spectrums are shown below.
Fig. 12. walk_pocket_hall1
Fig. 9. holding_store1
Fig. 10. ambient_0.5
Fig. 11. street_quiet2
7
Fig. 13. tvShow_1_0.5
Using these samples, the application was then tested in various environments and found to produce contrasting ringtones based on the settings the user has selected and the samples of the surrounding environment that are collected.
The last remaining step was to measure the performance of the algorithm and how long it takes to do all of the processing that is necessary to calculate the parameters. Ten tests were performed with a timer inserted into the code to record the amount of time taken recording in milliseconds. The results of these tests are shown below.
Trial Number
TABLE II
P ROCESSING T IME
Recording Time (s) Processing Time (ms)
1
2
3
4
5
6
7
8
9
10
0.5
0.5
0.5
0.5
0.5
0.5
0.5
0.5
0.5
0.5
3124
3101
3045
3127
3115
3136
3153
3089
3096
3034
Using these samples, the average processing time was determined to be 3102 ms, or 3.1 s. While this amount of time is not ideal and should be optimized in future revisions of the application, it is within the bounds necessary to still have the phone function as expected and should not add a noticeable amount of time for the caller. From the perspective of the person being called, their phone will not alert them to the presence of a phone call until the processing time is done, so there is no noticeable difference in their user experience.

8
V.
C ONCLUSION
This research has shown that an effective system to dynamically and intelligently determine several characteristics about the ringtone of a smartphone can be created through development of several algorithms and modification of the source code of the operating system. Because of the requirements regarding editing the source code of the operating system, this method is currently limited to the
Android operating system for smartphones because both
Apple’s iOS and Microsoft’s Windows Phone are both proprietary, closed source ecosystems which do not allow developers to create applications which have the necessary authority and resources to effectively recreate our system. We believe that, throughout the course of this research, it has become evident that this system is simply a starting point which can be improved upon greatly by optimization of the code which has been created and the addition of additional code and algorithms to add new and improved features. These features could include algorithms to take the identification of the weighted average frequency of the environmental audio samples one step further to actually determine what environment the phone is in. This presents a significant challenge due to the similarities between different environments in the frequency domain. Many additional samples would have to be collected and manually analyzed to identify unique characteristics of each environment. Because of this, the phone would not be able to work in every possible environment because that would require every possible environment’s characteristics to be coded into the application.
Additional work could also be done to better incorporate the user interface application with the source code modification part of the application. While they are currently used together, they could be more tightly integrated. Additionally, an important feature to be added in the future is the decoding of compressed audio files such as Ogg Vorbis and MPEG-3 into raw data that can then have the weighted average frequency algorithm run on them. Overall, the application that has been created represents an important step forward in better aligning the sounds which emanate from standard smartphones with their surrounding environment and we are proud of the product that we have created.
R EFERENCES
[1] http://developer.android.com/images/system-architecture.jpg
[2] http://introcs.cs.princeton.edu/java/97data/FFT.java
[3] http://introcs.cs.princeton.edu/java/97data/Complex.java.html
[4] http://www.devlper.com/2010/12/android-audio-recording-part-2/
[5] http://www.androidhive.info/2013/11/android-sliding-menu-usingnavigation-drawer/
[6] http://developer.android.com
[7] http://computermusicblog.com/blog/2008/08/29/reading-and-writingwav-files-in-java

File Name ambient_0.5.wav background_music_3.0.wav bass_music_0.5.wav club_music_0.5.wav dubstep_1_0.5.wav dubstep_2_0.5.wav instrumental_0.5.wav longTest4_5.0.wav music_0.25.wav music_1.5.wav music_snapping_8.5.wav popMusic_loud_0.5.wav popMusic_quiet_0.5.wav silence_5.0.wav silence_desk_0.5.wav silence_pad_0.5.wav talking_0.25.wav tv_talking_0.5.wav tvShow_1_0.5.wav tvShow_2_0.5.wav walk_pocket_hall1.wav walk_pocket_hall2.wav walk_pocket_hall3.wav elevator1.wav elevator2.wav street_traffic1.wav street_traffic2.wav street_traffic3.wav street_traffic4.wav street_quiet1.wav street_quiet2.wav street_quiet3.wav car_stop_quiet1.wav car_stop_quiet2.wav car_stop_radio1.wav car_stop_radio2.wav car_go_quiet1.wav car_go_quiet2.wav car_go_radio1.wav car_go_radio2.wav car_fast_quiet1.wav car_fast_quiet2.wav car_fast_radio1.wav walking_store1.wav walking_store2.wav holding_store1.wav holding_store2.wav
Length Description
0.5283 s Ambient noise in an otherwise silent room
2.9663 s Longer recording of background music playing
0.5283 s Music with strong bass playing
0.5283 s Dance / Electronic music playing
0.5283 s Dubstep music playing
0.5283 s Dubstep music playing
0.5283 s Instrumental music playing
5.0387 s Longer recording of background music
0.4063 s Very short recording of music
1.5441 s Medium length recording of music
8.4521 s Long recording of music and snapping
0.5283 s Loud pop / upbeat music
0.5283 s Quiet pop / upbeat music
5.0387 s Long recording of silence /ambient noise
0.5283 s Ambient sounds while sitting on hard surface
0.5283 s Ambient sounds while sitting on padded surface
0.4063 s Short recording of people talking
0.5283 s Talk show sound from a television
0.5283 s Sitcom sounds from a television
0.5283 s Sitcom sounds from a television
0.5283 s Walking down a quiet hallway with phone in pocket
0.5283 s Walking down a quiet hallway with phone in pocket
0.5283 s Walking down a quiet hallway with phone in pocket
0.5283 s Beeping noises and fans in an elevator
0.5283 s Beeping noises and fans in an elevator
0.5283 s Traffic noises while walking down a street with phone in pocket
0.5283 s Traffic noises while walking down a street with phone in pocket
0.5283 s Traffic noises while walking down a street with phone in pocket
0.5283 s Traffic noises while walking down a street with phone in pocket
0.5283 s Walking down a street in pocket, no traffic
0.5283 s Walking down a street in pocket, no traffic
0.5283 s Walking down a street in pocket, no traffic
0.5283 s Stopped car with engine running, no radio
0.5283 s Stopped car with engine running, no radio
0.5283 s Stopped car with engine running, radio playing
0.5283 s Stopped car with engine running, radio playing
0.5283 s Moving car, neighborhood speeds, no radio
0.5283 s Moving car, neighborhood speeds, no radio
0.5283 s Moving car, neighborhood speeds, radio playing
0.5283 s Moving car, neighborhood speeds, radio playing
0.5283 s Moving car, highway speeds, no radio
0.5283 s Moving car, highway speeds, no radio
0.5283 s Moving car, highway speeds, radio playing
0.5283 s Walking through a store in pocket
0.5283 s Walking through a store in pocket
0.5283 s Holding phone in a store
0.5283 s Holding phone in a store

File Name ambient_0.5.wav background_music_3.0.wav bass_music_0.5.wav club_music_0.5.wav dubstep_1_0.5.wav dubstep_2_0.5.wav instrumental_0.5.wav longTest4_5.0.wav music_0.25.wav music_1.5.wav music_snapping_8.5.wav popMusic_loud_0.5.wav popMusic_quiet_0.5.wav silence_5.0.wav silence_desk_0.5.wav silence_pad_0.5.wav talking_0.25.wav tv_talking_0.5.wav tvShow_1_0.5.wav tvShow_2_0.5.wav walk_pocket_hall1.wav walk_pocket_hall2.wav walk_pocket_hall3.wav elevator1.wav elevator2.wav street_traffic1.wav street_traffic2.wav street_traffic3.wav street_traffic4.wav street_quiet1.wav street_quiet2.wav street_quiet3.wav car_stop_quiet1.wav car_stop_quiet2.wav car_stop_radio1.wav car_stop_radio2.wav car_go_quiet1.wav car_go_quiet2.wav car_go_radio1.wav car_go_radio2.wav car_fast_quiet1.wav car_fast_quiet2.wav car_fast_radio1.wav walking_store1.wav walking_store2.wav holding_store1.wav holding_store2.wav
5403.0
3329.6
3747.3
3051.0
2637.1
4226.4
2208.6
2322.2
2636.1
1375.8
1687.1
1312.2
5539.1
4814.4
6340.0
6319.5
7361.6
5420.2
5354.1
6968.7
7447.9
6615.5
5875.7
5011.7
3310.2
3007.9
2666.8
3158.4
4582.0
4210.4
4069.6
6263.0
Average frequency (Hz)
6736.6
3818.6
3858.5
3763.5
5511.7
5224.6
3954.5
3469.0
4232.0
3645.8
7219.7
5284.5
5236.2
8030.7
6353.1