Jump to content
Brian Enos's Forums... Maku mozo!

Open Source Shot Timer


adweisbe

Recommended Posts

Well, when I try to install the version posted there, it tells me that it's version b1, not b2, and it FC's as soon as I start it...

Hats is odd..

Edit :

It seems like my source code is broken even when i undo the changes it still doesn't work.

I have tried this ones before and I had to start all over again.

So will take a look at it later.

Edited by MichaelGj
Link to comment
Share on other sites

  • Replies 220
  • Created
  • Last Reply

Top Posters In This Topic

Well, when I try to install the version posted there, it tells me that it's version b1, not b2, and it FC's as soon as I start it...

Back in business, please try this one (1.2.2.2b4) it might start registering shot as soon as you press "buzz" (it does on mine phone)

but its just for testing :)

Michael.

file removed

Edited by MichaelGj
Link to comment
Share on other sites

Well, I've never actually compiled any of this code, I may have to wait for MichaelGj to do that for me. I'm not sure what/how he's doing it. I'm used to Python ( and ASE, wewt) and have yet to attempt to write an APK...

I did notice htough that on the versions before 1.1.0.0, the endian lines didn't exist, and when 'little' endian was added is when it went from having streams of .12 second splits to no output at all.

Edited by CiDirkona
Link to comment
Share on other sites

Well, I've never actually compiled any of this code, I may have to wait for MichaelGj to do that for me. I'm not sure what/how he's doing it. I'm used to Python ( and ASE, wewt) and have yet to attempt to write an APK...

I did notice htough that on the versions before 1.1.0.0, the endian lines didn't exist, and when 'little' endian was added is when it went from having streams of .12 second splits to no output at all.

Ok, i have added the sensitivity code again and changed to ByteOrder.BIG_ENDIAN.

Let us know how it works

File is removed

Edited by MichaelGj
Link to comment
Share on other sites

Very odd. I'm still having the same issue at all sensitivity settings but now the split times are anywhere from .17 to .84. Maybe the same issue, but longer time between them due to the larger data type?

Another thing I just noticed -- when there's alot of noise, the time delay between the constantly updating splits goes up. When it's quiet, it goes back down to .17 - .20. When it's loud, it goes up to 1.17, 1.28, 1.20, etc.

Edited by CiDirkona
Link to comment
Share on other sites

Very odd. I'm still having the same issue at all sensitivity settings but now the split times are anywhere from .17 to .84. Maybe the same issue, but longer time between them due to the larger data type?

Another thing I just noticed -- when there's alot of noise, the time delay between the constantly updating splits goes up. When it's quiet, it goes back down to .17 - .20. When it's loud, it goes up to 1.17, 1.28, 1.20, etc.

It sounds like the microphone in your DI is very good :)

Maybe some kind of a peak meter would work better ?

Michael.

Link to comment
Share on other sites

Hey, I think you're on to something there. Do you think you could try using the big endian file type and setting the sensitivity up to 100 or 150 or so? When I have the sensitivity at 50, I can make a continual noise (rubbing my thumb on the mic in ciricles, and as soon as STOP, it'll recognize it as a shot. With no noise at all, it picks up just about anything, or nothing, and makes continual repeated shots out of that...

Link to comment
Share on other sites

Endianness has to do with byte order and not the size of the samples. The behavior your describing sounds like big endian is wrong.

Can you use the Hertz audio recording app to record an 8khz 16-bit file where you flick the mic and speak into it. If we could look at that we could get an idea of what kind of audio is coming out of the mic. I could run it through the unit tests and see if the shot detector does the right thing with it.

Link to comment
Share on other sites

Hey, I think you're on to something there. Do you think you could try using the big endian file type and setting the sensitivity up to 100 or 150 or so? When I have the sensitivity at 50, I can make a continual noise (rubbing my thumb on the mic in ciricles, and as soon as STOP, it'll recognize it as a shot. With no noise at all, it picks up just about anything, or nothing, and makes continual repeated shots out of that...

Max value is now 150 :)

Michael.

Link to comment
Share on other sites

Ok, this might sound weird, BUT I think the way it's working now is the shot counter is counting the times between the silences, not the peaks... if that makes sense. I'll try that other program as well.

Right around 65-70 it starts to meausre the time between silence periods. I can clap over and over again and it doesn't register a 'shot' until I stop clapping...

Link to comment
Share on other sites

That audio is definitely little endian so that setting needs to go back to what it was. That is why it detects shots during silence.

Here is a screenshot comparing audio I recorded of gun shots and the audio you sent me

e6fb31e0.png

You can see that the shots are much louder and go square for a while. This is what the shot detector looks for. It counts the number of audio samples that are square in a row.

In the audio you sent me there isn't enough of a volume difference between your voice and flicking the mic which is a concern.

This is what it looks like when I flick and blow my mic:

0db9f26b.png

You can see that it also maxes out for a little while.

When you flick the mic you need to hit the mic directly with your nail to get the right sound. It should smart a little ;-)

The sensitivity adjustment you see doesn't control how sensitive it is to volume.

http://code.google.com/p/openshottimer/source/browse/trunk/src/org/ost/AmplitudeSpikeShotDetector.java#31

That value determines how loud something has to be in order to be considered part of a shot.

If you set it too low then it will start to detect other things as shots. However shots (and flicks, and blowing on the mic) should be loud enough that the value that is there works with just about any mic. Gun shots are really really loud! Well beyond the capacity of a normal microphone to discern exactly how loud they are (hence the square sound waves). That is what is puzzling about your situation.

Edited by adweisbe
Link to comment
Share on other sites

The sensitivity adjustment you see doesn't control how sensitive it is to volume.

http://code.google.com/p/openshottimer/source/browse/trunk/src/org/ost/AmplitudeSpikeShotDetector.java#31

That value determines how loud something has to be in order to be considered part of a shot.

Do we need to lower that value or ??

Michael.

Link to comment
Share on other sites

Also, please note that I haven't tried this with actual gunfire either -- only clapping and flicking the mic. It kinda seems that the 'max' volume window needs to be moved down, and then the sensitivity can be adjusted up towards that...?

Edited by CiDirkona
Link to comment
Share on other sites

The sensitivity adjustment you see doesn't control how sensitive it is to volume.

http://code.google.com/p/openshottimer/source/browse/trunk/src/org/ost/AmplitudeSpikeShotDetector.java#31

That value determines how loud something has to be in order to be considered part of a shot.

Do we need to lower that value or ??

Michael.

My thinking is that if you need to then there is something else wrong. That is why I didn't bother making it adjustable. The pictures show what a loud noise should looks like. The amplitude is off the charts so it looks square because the microphone can't tell how loud it is.

I think using one of the original versions that works for someone else and busting an actual cap might tell us something. Michael does it work for you?

CiDirkona, you could also use Hertz to record a clip containing an actual gunshot and we could see what that looks like on your phone.

Link to comment
Share on other sites

I think using one of the original versions that works for someone else and busting an actual cap might tell us something. Michael does it work for you?

I have only used it with my airsoft not with my SPS, but its a bit to sensitive even for airsoft on my HTC.

Maybe there is a need for a calibrate function, like enter calibrate mode then fire a shot and adjust after to that.

Michael.

Link to comment
Share on other sites

The maximum is is 32768. So 10-15k would be reasonable to try and detect the stuff that showed up in the recording.

I have only used it with my airsoft not with my SPS, but its a bit to sensitive even for airsoft on my HTC.

Maybe there is a need for a calibrate function, like enter calibrate mode then fire a shot and adjust after to that.

Michael.

Interesting. This is why the value is set to 32k. Android doesn't provide any way to adjust the levels. You get the digital data and that is it. It would be nice to be able to adjust it before the digital to analog conversion so the app could get a relative sense of how loud things are, but I don't think that is possible.

I submitted an issue for this http://code.google.com/p/android/issues/detail?id=6554&can=4&colspec=ID%20Type%20Status%20Owner%20Summary%20Stars but it is hasn't been looked at yet and no one has voted for it.

Edited by adweisbe
Link to comment
Share on other sites

Interesting. This is why the value is set to 32k. Android doesn't provide any way to adjust the levels. You get the digital data and that is it. It would be nice to be able to adjust it before the digital to analog conversion so the app could get a relative sense of how loud things are, but I don't think that is possible.

What about the getMaxAmplitude() in MediaRecorder ?

Michael.

Link to comment
Share on other sites

What about the getMaxAmplitude() in MediaRecorder ?

Michael.

getMaxAmplitude() is doing the same thing. The MediaRecorder is reading in the samples and keeping track of the max sample. The disadvantage of that approach is that it doesn't differentiate between a short loud sound and a long loud sound. You also can't accurately place things in time because you can't control when getMaxAmplitude() will be invoked (although realistically it will be regular). By reading the samples directly you can count samples to determine exactly when something happened.

EDIT

Ok maybe I'm wrong. I tried to look up the implementation of GET_MAX_AMPLITUDE and it looks like it is implementation specific. There is none defined as part of Android.

http://www.google.co.in/codesearch/p?hl=en#MDtG1cTEFDc/android/author/authordriver.cpp&q=getMaxAmplitude%20package:git://android.git.kernel.org&d=2

There is no real description about what the value return is either

http://developer.android.com/reference/android/media/MediaRecorder.html#getMaxAmplitude()

Edited by adweisbe
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...