Yes, you are absolutely right we don't have the access to the phone nor we have any information on the model. The case is that to be more precise..
" me and you are sitting in front of each other and there's a mobile phone recorder ON in my pocket. Its recording all our conversations and the dealings that we have made. Now i later on edit some part of that recording from in between and removed some portion of the conversation from the end resulting in what i actually want from you to say.. Now you have to prove that yes you said all that is there in the remaining portion but you also said something extra tht is not there in it, the file is tempered with. You have to prove it now..."
And this is where we are stuck, we thought to use any sound editor application like "sound forge" or "Diamond Cut Live" to see the pattern of the frequency and if we find any mismatch in that pattern we can say and prove the tempering. But frequency pattern seems to be ok . What you have said about AMR codecs we'll definitely see that and then only i can reply back.
Thanks alot for the information its sounds really helpful as we dont have any clue what to do. And atleast you replied.
Main Topics
Browse All Topics
by: MalleusMaleficarumPosted on 2009-02-12 at 20:05:33ID: 23629781
Wow.. that's a good one..
"is an audio format which is extensively used in mobile devices in various applications ranging from normal audio player/recorder to VoIP kind of applications."
(http://wiki
So the first question is, do you have access to the mobile device that was used to record the sound clip? My guess is no, otherwise you wouldn't be in this pickle, but it's worth asking. This would be the best option.
I'll need to understand more about the possible "editing" scenario. Because how it was edited could be the way to discover if the AMR file you have has been tampered with or not.
The best place to read ALL about this file format is here: http://www.ietf.org/rfc/rf
I
MODE
BIT RATES
0 - AMR 4.75 - Encodes at 4.75kbit/s
1 - AMR 5.15 - Encodes at 5.15kbit/s
2 - AMR 5.9 - Encodes at 5.9kbit/s
3 - AMR 6.7 - Encodes at 6.7kbit/s
4 - AMR 7.4 - Encodes at 7.4kbit/s
5 - AMR 7.95 - Encodes at 7.95kbit/s
6 - AMR 10.2 - Encodes at 10.2kbit/s
7 - AMR 12.2 - Encodes at 12.2kbit/s
But if I understand the IETF document correctly, there is actually an "eigth" bit-rate encoding when the phone detects "silence" on the line, and this should be a very very small frame, because it is going to try and save space and not record silence, but rather just show "empty" frames.
So the best "test" would be to find out what kind of mobile device was used to record the conversation, and record some similar conversations and analyze the AMR file. This will tell you how the AMR encoder on this particular phone works, and if it adheres to the AMR standard OR if it actually is sloppy/lazy and encodes all the audio using the same bit-rate because you had a sloppy coder who decided it would be easier to "hardcode" a bitrate into what is supposed to be a variable bit-rate audio format.
Think of it in terms of the TCP/IP specification. There is the IETF standard implementation of TCP/IP and how it should work, and then there is each vendor's interpretation/implementat
Analyzing how this specific mobile device encodes AMR files might help you figure out if the file was tampered with, or if it is more than likely the original file.
Another scenario is If you suspect that the AMR file was converted to something else, likea .WAV file, edited, then reconverted to an AMR file, it could bepossible to analyze the AMR file to see if the sampling rate acrosseach AMR frame is identical. It is possible that the WAV to AMR file conversion algorithm used was also sloppy and wouldn't match that of an AMR that was natively recorded on the device.
Alas, these are long shots, but this is the only way I can think of that you could attempt to get some kind of "fingerprint" of how the mobile device would encode an AMR file and be able to compare it to the sample you have now.