I'm confused. I needed to record sound from MIC in Android so I used the following code:
recorder = new AudioRecord(AudioSource.MIC, 44100,
AudioFormat.CHANNEL_IN_MONO,
AudioFormat.ENCODING_PCM_16BIT, N);
buffer = new byte[N];
//...
recorder.read(buffer, 0, N);
As we know, a byte array can store values between -128 to +128 while a 16Bit sound needs a lot more storage(e.g. short and int) but surprisingly Java and Android have a record method which saves recorded data to a byte array.
How that can be possible? What am I missing?
You are thinking of byte as a shot integer. It is just 8 bits. You need to store 1000111011100000 (16 bits)? First byte is 10001110, second byte is 11100000. That you can interpret these bits as numbers is not relevant here. In a more general way, byte[] is usually how you deal with binary "raw data" (let it be audio streams or encrypted content or anything else that you treat like a stream of bits).
If you have n "words" of 16 bits then you will need 2n bytes to store it. Byte 0 will be lower (or higher) part of word 0, byte 1 will be the rest of word 0, byte 0 will be lower (or higher) part of word 1...
Related
I have read that byte array in Java is used to represent a binary data. I am not able to understand this. How byte array can represent a binary data (and which can be transferred over the network and can be constructed back to original form).
Byte can have (integer) values from -128 to 127; so how does a byte array represent a binary data?
Byte can be (integer) values -128 to 127, so how does a byte
array represent a binary data?
Each byte (octet) is a sequence of eight bits, and having sequence of bytes lets us represent binary data of any length (though it's limited to per 8-bits increments).
Memory of most modern computers is addressed as a sequence of bytes, network interfaces send packets containing sequences of bytes, hard drives store sequences of bytes (but are addressable only in much larger blocks, say, 4096 bytes).
There is rarely need to access data bit-by-bit, and when needed it can be done with bitwise operators, so no data type for sequence of bits is provided by default.
So to conclude:
1 Byte == 8 bits, and Byte Array == stream of bits,
and hence represent binary data?
Yes. For example: A Byte Array of length 2 bytes is a stream of 16 bits of binary data.
I am dealing with a socket connection in which I send and then receive bytes. I have the socket code written and I can both send and receive bytes but there is a catch...
I am sending data within a language called Delphi and then receiving them in the android code. But I come into a bit of a problem.
In delphi a byte has a maximum value of 255 whereas in Android the maximum byte is 127. How would you get around this? Is there a way to use an unsigned byte? Should I use shorts instead of bytes?
Any help is appreciated.
To read a single byte you can cast it to a larger Java/Android primitive type to interpret it as an unsigned value by performing a bitwise & (AND) with an 8 bit mask. To write a value to the socket as an unsigned byte value use a larger primitive type to set the value, then cast this value to a byte to write to the socket. For example:
short shortVal = 255;
byte byteVal = (byte) shortVal;
System.out.println("signed value = " + byteVal);
shortVal = (short) (byteVal & 0xFF);
System.out.println("unsigned value = " + shortVal);
Java/Android interprets the byte as a signed value (in this case, -1), but the 8 bits in the byte (11111111) are still the same as the least significant 8 bits in the short 255 (0000000011111111).
The same technique can be used with larger types (use int with 16 bit mask to interpret short as unsigned, long with 32 bit mask to interpret int as unsigned), but with multibyte values be careful to take into account the endianness of the network protocol and convert byte order if needed.
I am playing around on how to manipulate bytes from an inputted Hex number. Data is a Hex:
0x022DA822 == 10001011011010100000100010. After I run the following code:
byte mask= (byte) data;
mask will = 100010, only those last bits. How come it only shows the last 6 bits or 22 in the hex?
Does it mask the first 20 bits by default?
Your cast is causing a loss of data. A byte can hold (you guessed it), one byte of data. Thus the range of a byte is [-128, 127]. Note that the most significant bit is reserved as the sign bit. So basically when you are saying: (byte)data, you are converting your hex data into a variable of type byte, which has a smaller range than your hex string. And thus only the last byte of your data can be stored in the byte.
This is part of a larger assignment that I've mostly got done except for this one part, which is a bit embarrassing because it sounds really simply on paper.
So basically, I've got a large amount of compressed data. I've been keeping track of the length using a CRC32
CRC32 checksum = new CRC32();
...
//read input into buffer
checksum.update(buff, 0, bytesRead);
So it updates everytime more info is read in. I've also kept track of the uncompress length using
uncompressedLength += manage.read(buff);
So it is an int value that has the number of bytes of the original file. This is a little Endian machine.
From what I can tell, what I need is four byte CRC, which I used
public byte[] longToBytes(long x) {
ByteBuffer buffer = ByteBuffer.allocate(8);
buffer.putLong(x);
return buffer.array();
}
byte[] c = longToBytes(checksum.getValue());
BUT this is 8 bytes. CRC32.getValue returns a long. Can I convert it to an int in this case without losing information I need?
And then the ISIZE is supposed to be...the four byte compressed length modulo 2^32. I've got the variable uncompresedLength which is an int. I think I just have to convert it to bytes and that's all?
I've been hexdumping the result from gzip and the result from my program and my header and data are right, I'm just missing my trailer.
As for why I'm doing this manually, it's because of an assignment. Trust me, I'd love to just use GZIPOoutputStream if I could.
CRC32 has 32 bits... the class returns long because of the super interface.
uncompressed length should be long, since nowadays files larger than 2G isn't uncommon.
so in both cases, you need to convert the lowest 32 bits of a long to 4 bytes.
static byte[] lower4bytes(long v)
{
return new byte[] {
(byte)(v ),
(byte)(v>> 8),
(byte)(v>>16),
(byte)(v>>24)
};
}
To write an integer in little-endian form, simply write the low byte of the integer (i.e. modulo 256 or anded with 0xff), then shift it down eight bits or divide by 256, then write the resulting low byte, and repeat that two more times. You'll write four bytes. Since you only write four, you will automatically be writing the length modulo 232.
my experiment is like this:
first, I use matlab to create a specified wave file with a rate of 44100, which means any fragment lasting 1s contains 44100 elements and these elements are presented as double.
then, I use smartphone's microphone to retrieve the wave. And the sampling rate is 44100, in order to restore the wave.
But, audioRecord store the data as byte, while what i want is double. Converting from byte to double sounds reasonable, I still confused that sampling rate 44100 means the audioRecord should record 44100 bytes in 1s or 44100*4 bytes, since double contains 4 bytes?
Other experiment i have committed:
using recording software to retrieve wave and store in .wav
read the .wav by matlab's wavread and by java respectively.
To 1s, we get 44100 elements, and list below:
-0.00164794921875
1.52587890625E-4
2.74658203125E-4
-0.003326416015625
0.001373291015625
-4.2724609375E-4
0.00445556640625
9.1552734375E-5
-9.1552734375E-4
7.62939453125E-4
-0.003997802734375
9.46044921875E-4
-0.00103759765625
0.002471923828125
0.001922607421875
-0.00250244140625
8.85009765625E-4
-0.0032958984375
8.23974609375E-4
8.23974609375E-4
anyone know how many elements the audioRecord will retrieve in 1s with the sampling rate of 44100?
The default for AudioRecord is to return 16-bits per channel for each sample (ENCODING_PCM_16BIT).
Now there are two read overloads that let you specify either a short[] (16 bits) or a byte[] (8 bits) buffer.
int read(short[] audioData, int offsetInShorts, int sizeInShorts)
int read(byte[] audioData, int offsetInBytes, int sizeInBytes)
So a 1 second mono buffer (1 channel) should have a short[] buffer of length 44100. Stereo (2 channels) would have 88200, etc...
I would avoid using the byte[] buffer unless you had set the AudioRecord format to ENCODING_PCM_8BIT for some reason (it is not guaranteed to be supported by all devices).
Now if you want to convert those short values to doubles you have to realize that the double values you record in matlab are double-precision normalized samples which are normalized from [-1 to 1] while the short values are going to be from [-32768 to 32767] so you would have to write a conversion function instead of just trying to cast the numbers from a short to a double.