5

私はかなりシンプルなAndroidアプリ（sdkリビジョン14：ICS）を構築しています。これにより、ユーザーは一度に2つのオーディオクリップ（すべてRIFF / WAV形式、リトルエンディアン、署名付き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]);
       }

}

上記のコードを使用した組み合わせと再生の結果は、私が望むものに近いです（両方のサンプルは、結果として得られるハイブリッドサウンドでまだ識別可能です）が、クラック、ポップ、およびその他のノイズもたくさんあります。

それで、3つの質問：最初に、私はAudioTrackを正しく使用していますか？次に、AudioTrack構成のエンディアンはどこで考慮されますか？音はそれ自体でうまく再生され、組み合わせたときに期待するものとほぼ同じように聞こえるので、RIFF / WAV形式のリトルエンディアンの性質はどこかで伝えられているようですが、どこにあるのかわかりません。最後に、符号付き16ビットPCMエンコーディングで期待できるバイト値の範囲はどれくらいですか？上記のLog.d（...）呼び出しからlogcatに-32768から32767の範囲の値が表示されると予想されますが、代わりに結果は-100から100の範囲内になる傾向があります（それを超える外れ値もあります）。16ビット範囲を超える結合バイト値がノイズの原因になる可能性がありますか？

ありがとう、CCJ

更新：BjorneRocheとWilliamthe Codererに大いに感謝します！オーディオデータをshort[]構造に読み込みました。データ入力ストリームのエンディアンは、William（http://stackoverflow.com/questions/8028094/java-datainputstream-replacement-for-endianness）のEndianInputStreamを使用して説明されています。組み合わせ方法が次のように変更されました。

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

これらの改善によるハイブリッドオーディオ出力品質は素晴らしいです！

4

1 に答える 1

5

私はAndroidオーディオに精通していないため、すべての質問に答えることはできませんが、基本的な問題は何であるかをお伝えできます。バイトごとにオーディオデータを追加しても機能しません。それは一種の動作であり、コードを見て、それが最も一般的であるという事実から、16ビットPCMデータを持っていると仮定します。しかし、どこでも、あなたはバイトを扱っています。バイトはオーディオの処理には適していません（オーディオがたまたま8ビットでない限り）

バイトは約+/-128です。「上記のLog.d（...）呼び出しからlogcatに-32768から32767の範囲の値が表示されると予想されますが、代わりに結果は-の範囲内になる傾向があります。 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に0.5を掛けてスキップします。クリッピングが発生しますが、出力ははるかに静かになります。これは、電話ではおそらく希望どおりではありません）。

于 2012-06-13T15:32:26.870 に答える