Вопрос по audio, android, audiotrack, wav – использование AudioTrack в Android для объединения байтов звуковых образцов производит шум

4

Я создаю довольно простое приложение для Android (редакция SDK 14: ICS), которое позволяет пользователям выбирать два аудиоклипа за раз (все в формате 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]);
       }

}

Результат комбинирования и воспроизведения с использованием приведенного выше кода близок к тому, что я хочу (оба сэмпла все еще различимы в результирующем гибридном звуке), но также есть много трещин, треск и других шумов.

Итак, три вопроса: во-первых, правильно ли я использую AudioTrack? Во-вторых, где в конфигурации AudioTrack учитывается порядок байтов? Звуки сами по себе прекрасно воспроизводятся и звучат почти так, как я ожидаю, когда объединены, поэтому кажется, что где-то сообщается о порядке байтов в формате RIFF / WAV, но я не уверен, где. Наконец, какой диапазон значений байтов мне следует ожидать для 16-битной кодировки PCM со знаком? Я ожидаю увидеть значения в диапазоне от & # x2212; 32768 до 32767 в logcat из приведенного выше вызова Log.d (...), но вместо этого результаты, как правило, находятся в диапазоне от -100 до 100 (с некоторыми выбросами за пределами тот). Может ли объединенные значения байтов за пределами 16-битного диапазона учитывать шум?

Спасибо, CCJ

ОБНОВЛЕНИЕ: большое спасибо Бьорну Роше и Уильяму Кодереру! Теперь я читаю аудиоданные в структурах short []. Порядковый номер DataInputStream учитывается с помощью EndianInputStream от William (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;
}

Качество гибридного аудио с этими улучшениями просто потрясающее!

Ваш Ответ

1   ответ
4

поэтому не могу ответить на все ваши вопросы, но могу сказать вам, в чем заключается основная проблема: побайтное добавление аудиоданных не работает. Так как он работает, исходя из вашего кода и того факта, что он наиболее распространенный, я предполагаю, что у вас есть 16-битные данные PCM. И все же везде вы имеете дело с байтами. Байты не подходят для обработки аудио (если звук не 8-битный)

Байты приблизительно равны +/- 128. Вы говорите "Я бы ожидал увидеть значения в диапазоне от & # x2212; 32768 до 32767 в logcat из вызова Log.d (...) выше, но вместо этого результаты, как правило, находятся в пределах диапазон от -100 до 100 (с некоторыми выбросами за пределами этого) & quot; Ну, как вы могли бы перейти к этому диапазону, когда вы печатаете значения из байтового массива? Правильный тип данных для 16-битных данных со знаком является коротким, а не байтовым. Если вы печатаете короткие значения, вы увидите ожидаемый диапазон.

Вы должны конвертировать свои байты в шорты и суммировать шорты. Это позаботится о большей части разного шума, который вы слышите. Так как вы читаете прямо из файла, зачем конвертировать? почему бы не прочитать его как короткий файл, используя что-то вроде этого http://docs.oracle.com/javase/1.4.2/docs/api/java/io/DataInputStream.html#readShort()

Следующая проблема заключается в том, что вы должны иметь дело со значениями, выходящими за пределы допустимого диапазона, а не позволять им «оборачиваться». Самое простое решение - просто сделать суммирование в виде целых чисел, & quot; клип & quot; в короткий диапазон, а затем сохраните вырезанный вывод. Это избавит от ваших кликов и треск.

В псевдо-коде весь процесс будет выглядеть примерно так:

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

Вы получите небольшое искажение от & quot; отсечения & quot; шаг, но нет простого способа обойти это, и отсечение НАМНОГО лучше, чем циклический переход. (при этом, если ваши треки не очень «горячие» и тяжелые на низких частотах, искажения не должны быть слишком заметными. Если это проблема, вы можете сделать другие вещи: например, умножить на .5 и пропустите отсечение, но тогда ваш вывод будет намного тише, что, на телефоне, вероятно, не то, что вы хотите).

Да, вам также нужно иметь дело с порядком байтов. Вы можете рассмотреть аналогичную оболочку для RandomAccessFIle. Для справок, вы можете начать здесь:blog.bjornroche.com/2011/11/… Есть также книга под названием «Цифровое аудио» с Java, которая сейчас устарела и имеет некоторые неточности, но в ней есть рабочий код, который вы не найдете во многих местах. Больше ссылок в моей первой ссылке.
упс ... спасибо, что указали на необходимость использования коротких, а не байтовых массивов; на самом деле это 16-битный PCM, поэтому я не знаю, почему я думал, что побайтовое хранение и обработка будут работать. Возможно, из-за того, что я не смог найти хорошего объяснения того, как внутриимпульсная модуляция кода работает ... у вас есть какие-либо рекомендации по изучению низкоуровневых деталей кодирования / обработки цифрового звука? CCJ
Также следует отметить, что поскольку мои аудиофайлы в формате RIFF / WAV кодируются с использованием порядка байтов с прямым порядком байтов, мне нужно было использовать модифицированную версию DataInputStream для правильного считывания коротких значений (стандартная версия Java предполагает большой порядок байтов). К счастью, я нашел хорошую реализацию необходимых побитовых операций для выполнения этой задачи здесь:stackoverflow.com/questions/8028094/… CCJ

Похожие вопросы