使用Android的AudioTrack组合字节的声音样本会产生噪音

Question

我正在构建一个相当简单的Android应用程序（sdk修订版14:ICS），它允许用户一次选择两个音频片段（都是RIFF/WAV格式、little endian、签名PCM-16位编码），并以各种方式组合它们以创建新的声音。我对这种组合使用的最基本方法如下：

//...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类播放返回的字节数组：

....
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]);
       }

}

使用上面代码的组合和回放的结果接近我想要的（两个样本在产生的杂交声音中仍然可以辨别），但是也有很多裂缝、爆裂声和其他噪音。

因此，有三个问题：首先，我使用AudioTrack的方式正确吗？其次，在AudioTrack配置中，endianness占了什么位置？声音本身播放得很好，听起来几乎和我组合时的预期一样，所以RIFF/WAV格式的小端特性似乎在某个地方得到了传达，但我不确定在哪里。最后，对于有符号的16位PCM编码，我应该期望看到的字节值范围是多少？我希望在上面的Log. d（...）调用中的logcat中看到的值从−32768到32767不等，但结果往往在-100到100之间（还有一些异常值）。超过16位范围的组合字节值可能是噪声的原因吗？

谢谢CCJ

更新：主要感谢比约恩·罗奇和编码者威廉！现在我将音频数据读入short[]结构，使用William的EndianInputStream解释DataInputStream的endianness(http://stackoverflow.com/questions/8028094/java-datainputstream-replacement-for-endianness)组合方式改为：

//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;
}

这些改进带来的混合音频输出质量太棒了！

Answer 1

我不熟悉android的音频，所以我不能回答你所有的问题，但是我可以告诉你根本的问题是什么：逐个字节地添加音频数据是行不通的。因为它可以工作，而且通过查看你的代码，以及它最常见的事实，我假设你有16位的PCM数据。然而，在任何地方，你都在处理字节。字节不适合处理音频（除非音频碰巧是8位的）

字节数约为ox/-128。你说“我希望看到从−日志中的32768到32767。d（…）调用，但结果往往在-100到100的范围内（有些异常值超出了这个范围）“那么，当你从字节数组打印值时，怎么可能会进入这个范围呢？16位有符号数据的正确数据类型是短的，而不是字节。如果你打印的是短值，你会看到你期望的范围。

必须将字节转换为短字节，并对短字节求和。这将解决你听到的大部分杂音。既然你正在阅读文件，为什么还要费心转换呢？为什么不用这样的方式把它作为一个短片来读呢http://docs.oracle.com/javase/1.4.2/docs/api/java/io/DataInputStream.html#readShort()

下一个问题是你必须处理范围外的值，而不是让它们“环绕”。最简单的解决方案是简单地将求和作为整数，“剪辑”到短范围内，然后存储剪辑后的输出。这将摆脱你的点击和弹出。

在psuedo-code中，整个过程看起来像这样：

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，跳过剪辑，但这样你的输出会安静得多，在手机上，这可能不是你想要的）。