问题描述
我正在构建一个相当简单的Android应用(sdk修订版14:ICS)，该应用允许用户一次选择两个音频片段(所有音频片段均为RIFF/WAV格式，little-endian，带符号的PCM-16位编码)，并且以各种方式将它们组合在一起以创建新的声音.我用于此组合的最基本方法如下:
I'm building a fairly simple Android app (sdk revision 14: ICS) which allows users to pick two audio clips at a time (all are RIFF/WAV format, little-endian, signed PCM-16 bit encoding) and combine them in various ways to create new sounds. The most basic method I'm using for this combination is as follows:
//...sound samples are read in to memory as raw byte arrays elsewhere
//...offset is currently set to 45 so as to skip the 44 byte header of basic
//RIFF/WAV files
...
//Actual combination method
public byte[] makeChimeraAll(int offset){
for(int i=offset;i<bigData.length;i++){
if(i < littleData.length){
bigData[i] = (byte) (bigData[i] + littleData[i]);
}
else{
//leave bigData alone
}
}
return bigData;
}
然后可以通过AudioTrack类播放返回的字节数组:
the returned byte array can then be played via the AudioTrack class thusly:
....
hMain.setBigData(hMain.getAudioTransmutation().getBigData()); //set the shared bigData
// to the bigData in AudioTransmutation object
hMain.getAudioProc().playWavFromByteArray(hMain.getBigData(), 22050 + (22050*
(freqSeekSB.getProgress()/100)), 1024); //a SeekBar allows the user to adjust the freq
//ranging from 22050 hz to 44100 hz
....
public void playWavFromByteArray(byte[] audio,int sampleRate, int bufferSize){
int minBufferSize = AudioTrack.getMinBufferSize(sampleRate,
AudioFormat.CHANNEL_CONFIGURATION_MONO, AudioFormat.ENCODING_PCM_16BIT);
AudioTrack at = new AudioTrack(AudioManager.STREAM_MUSIC, sampleRate,
AudioFormat.CHANNEL_CONFIGURATION_MONO, AudioFormat.ENCODING_PCM_16BIT,
minBufferSize, AudioTrack.MODE_STREAM);
int i = 0;
at.play();
at.write(audio, 0, audio.length);
at.stop();
at.release();
for(i=0;i<audio.length;i++){
Log.d("me","the byte value at audio index " + i + " is " + audio[i]);
}
}
使用上面的代码进行组合和播放的结果与我想要的接近(两个样本在混合后的声音中仍然可以辨认)，但是也有很多裂纹，爆裂声和其他噪音.
The result of a combination and playback using the code above is close to what I want (both samples are still discernible in the resulting hybridized sound) but there are also a lot of cracks, pops, and other noise.
那么，有三个问题:首先，我是否正确使用了AudioTrack?第二，在AudioTrack配置中，字节顺序在哪里计算?声音本身可以很好地播放，并且听起来几乎像我期望的那样，所以RIFF/WAV格式的小端风格似乎可以在某个地方传达，但是我不确定在哪里.最后，对于带符号的16位PCM编码，我应该看到的字节值范围是多少?我希望从上面的Log.d(...)调用中看到logcat的值介于-32768到32767之间，但是结果往往是在-100到100的范围内(超出此范围还有一些异常值).超出16位范围的组合字节值是否可以解决噪音问题?
So, three questions: First, am I using AudioTrack correctly? Second, where is endianness accounted for in the AudioTrack configuration? The sounds play fine by themselves and sound almost like what I would expect when combined so the little-endian nature of the RIFF/WAV format seems to be communicated somewhere, but I'm not sure where. Finally, what is the byte value range I should expect to see for signed 16-bit PCM encoding? I would expect to see values ranging from −32768 to 32767 in logcat from the Log.d(...) invocation above, but instead the results tend to be within the range of -100 to 100 (with some outliers beyond that). Could combined byte values beyond the 16-bit range account for the noise, perhaps?
谢谢，CCJ
更新:非常感谢Bjorne Roche和编码员William！现在，我将音频数据读入short []结构，使用William的EndianInputStream(http://stackoverflow.com/questions/8028094/java-datainputstream-replacement-for-endianness)来解析DataInputStream的字节序.组合方法已更改为:
UPDATE: major thanks to Bjorne Roche and William the Coderer! I now read in the audio data to short[] structures, endianness of the DataInputStream is accounted for using the EndianInputStream from William (http://stackoverflow.com/questions/8028094/java-datainputstream-replacement-for-endianness) and the combination method has been changed to this:
//Audio Chimera methods!
public short[] makeChimeraAll(int offset){
//bigData and littleData are each short arrays, populated elsewhere
int intBucket = 0;
for(int i=offset;i<bigData.length;i++){
if(i < littleData.length){
intBucket = bigData[i] + littleData[i];
if(intBucket > SIGNED_SHORT_MAX){
intBucket = SIGNED_SHORT_MAX;
}
else if (intBucket < SIGNED_SHORT_MIN){
intBucket = SIGNED_SHORT_MIN;
}
bigData[i] = (short) intBucket;
}
else{
//leave bigData alone
}
}
return bigData;
}
这些改进的混合音频输出质量很棒！
the hybrid audio output quality with these improvements is awesome!
推荐答案
我对android音频不熟悉，所以我无法回答所有问题，但是我可以告诉您根本的问题是:添加音频数据字节-按字节操作不起作用.由于它可以正常工作，并且通过查看您的代码以及最常见的事实，我将假设您具有16位PCM数据.然而，无处不在，您正在处理字节.字节不适用于处理音频(除非音频恰好是8位)
I am not familiar with android audio, so I can't answer all your questions, but I can tell you what the fundamental problem is: adding audio data byte-by-byte won't work. Since it sort-of works, and from looking at your code, and the fact that it's most common, I'm going to assume you have 16-bit PCM data. Yet everywhere, you are dealing with bytes. Bytes are not appropriate for processing audio (unless the audio happens to be 8-bit)
字节约为aprox +/-128.您说:我希望从上面的Log.d(...)调用中看到logcat的值介于-32768到32767之间，但是结果往往在-100到100的范围内(超出此范围外还有一些异常值)那么，当您从字节数组中打印值时，如何才能达到该范围?16位带符号数据的正确数据类型是短字节，而不是字节.如果要打印短值，则会看到期望的范围.
Bytes are aprox +/- 128. You say "I would expect to see values ranging from −32768 to 32767 in logcat from the Log.d(...) invocation above, but instead the results tend to be within the range of -100 to 100 (with some outliers beyond that)" Well, how could you possibly go to that range when you are printing values from a byte array? The correct datatype for 16 bit signed data is short, not byte. If you were printing short values, you'd see the range you expected.
您必须将字节转换为短裤并对短裤求和.这样可以解决您听到的大部分杂音.但是，既然您正在阅读文件，为什么还要麻烦转换呢?为什么不像这样用简短的方式从文件中读取它 http://docs.oracle.com/javase/1.4.2/docs/api/java/io/DataInputStream.html#readShort ()
You must convert your bytes to shorts and sum the shorts. This will take care of much of the misc noise you are hearing. Since you are reading right off the file, though, why bother converting? why not read it off the file as a short using something like thishttp://docs.oracle.com/javase/1.4.2/docs/api/java/io/DataInputStream.html#readShort()
下一个问题是，您必须处理超出范围的值，而不是让它们包装".最简单的解决方案是简单地将整数求和，然后裁剪"到短范围内，然后存储裁剪后的输出.这将消除您的点击和弹出.
The next issue is that you must deal with out-of-range values, rather than letting them "wrap around". The simplest solution is simply to do the summing as integers, "clip" into the short range, and then store the clipped output. This will get rid of your clicks and pops.
在伪代码中，整个过程如下所示:
In psuedo-code, the entire process will look something like this:
file1 = Open file 1
file2 = Open file 2
output = Open output for writing
numSampleFrames1 = file1.readHeader()
numSampleFrames2 = file2.readHeader()
numSampleFrames = min( numSampleFrames1, numSampleFrames2 )
output.createHeader( numSampleFrames )
for( int i=0; i<numSampleFrames * channels; ++i ) {
//read data from file 1
int a = file1.readShort();
//read data from file 2, and add it to data we read from file 1
a += file2.readShort();
//clip into range
if( a > Short.MAX_VALUE )
a = Short.MAX_VALUE;
if( a < Short.MIN_VALUE )
a = Short.MIN_VALUE;
//write it to the output
output.writeShort( (Short) a );
}
剪切"步骤会给您带来一些失真，但是没有简单的方法可以解决，剪切比环绕效果要好得多.(也就是说，除非您的音轨非常热"并且在低频中很重，否则失真应该不太明显.如果有问题，您可以执行其他操作:将a乘以.5并跳过剪辑，但随后您的输出将安静得多，在电话上可能不是您想要的).
You will get a little distortion from the "clipping" step, but there's no simple way around that, and clipping is MUCH better than wrap-around. (that said, unless your tracks are extremely "hot", and heavy in the low frequencies, the distortion shouldn't be too noticeable. If it is a problem, you can do other things: multiply a by .5 for example and skip the clipping, but then your output will be much quieter, which, on a phone, is probably not what you want).
这篇关于使用Android的AudioTrack合并字节的声音样本会产生噪音的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！