ExtAudioFileConvert вопросы

Question

Я добился определенного прогресса в получении сжатого (mp3) звука и сохранении его в формате PCM. Кроме того, я хотел разделить исходный файл на куски длиной 2 секунды в рамках одного и того же процесса. Кажется, я успешен, но меня немного смущает, почему.

Когда я читаю блоки аудио и записываю файлы, я проверяю, собираюсь ли я написать чанк, который заставил бы мой файл превысить мой 2-секундный лимит. Если это так, я пишу достаточно, чтобы получить до 2 секунд, закрыть файл, а затем открыть новый файл и записать остаток в новый файл, а затем прочитать дополнительные данные. Что-то вроде этого:

framesInTimedSegment += numFrames;
if ((framesInTimedSegment  > (2.0 * sampleRate)) && (j < 5)) {
    UInt32 newNumFrames = numFrames;
    numFrames = framesInTimedSegment - (2.0 * sampleRate);
    newNumFrames -= numFrames;
// Question A
    UInt32 segmentOffset = newNumFrames * numChannels * 2;
    error = ExtAudioFileWrite(segmentFile, newNumFrames, &fillBufList);
// Question B
       // handle this error!  We might have an interruption
    if (segmentFile) ExtAudioFileDispose(segmentFile);
    XThrowIfError(ExtAudioFileCreateWithURL(urlArray[++j], kAudioFileCAFType, &dstFormat, NULL, kAudioFileFlags_EraseFile, &breakoutFile), "ExtAudioFileCreateWithURL failed! - segmentFile");
    size = sizeof(clientFormat);
    XThrowIfError(ExtAudioFileSetProperty(segmentFile, kExtAudioFileProperty_ClientDataFormat, size, &clientFormat), "couldn't set destination client format"); 
    fillBufList.mBuffers[0].mData = srcBuffer + segmentOffset;
    fillBufList.mBuffers[0].mDataByteSize = numFrames * fillBufList.mBuffers[0].mNumberChannels * 2;
    framesInTimedSegment = numFrames;
}
error = ExtAudioFileWrite(segmentFile, numFrames, &fillBufList);

Вот мои вопросы (я попытался обозначить соответствующую строку):

A: Есть ли лучший способ найти смещение в моем буфере, чтобы я не ошибочно жестко запрограммировал какое-то значение там? Например, есть ли благословенный способ получить смещение данных от номера кадра?

B: Если ExtAudioFileWrite выполняет преобразование из сжатого в распакованный, то данные, которые я пишу, еще не были распакованы (верно?), Поэтому мне не нужно беспокоиться о том, чтобы играть с номерами кадров и смещениями, когда я имею дело с сжатые данные? Должен ли я вместо этого сначала преобразовать файл, либо в файл PCM, либо в память, а затем разделить этот PCM?

Спасибо!

-mahboud

пс.

ClientFormat определяется следующим образом:

        clientFormat = dstFormat;

и dstFormat:

        dstFormat.mFormatID = outputFormat;
        dstFormat.mChannelsPerFrame = srcFormat.NumberChannels();
        dstFormat.mBitsPerChannel = 16;
        dstFormat.mBytesPerPacket = dstFormat.mBytesPerFrame = 2 * dstFormat.mChannelsPerFrame;
        dstFormat.mFramesPerPacket = 1;
        dstFormat.mFormatFlags = kLinearPCMFormatFlagIsPacked | kLinearPCMFormatFlagIsSignedInteger; // little-endian

Answer 1

Трудно ответить правильно, не увидев немного больше кода. Но, предполагая, что clientFormat является чередованным форматом PCM:

B) ExtAudioFileWrite не выполняет преобразование из сжатого в распакованный, а ExtAudioFileRead - в зависимости от того, какой формат клиента вы установили. Предполагая исходный файл MP3 и "стандартный" 16-битный формат PCM-клиента с частотой 44,1 кГц, вызовы ExtAudioFileRead преобразуют байты MP3 в данные PCM. Это делается с помощью API AudioFile и AudioConverter.

A) Это немного сложно ответить, не видя, как определяется srcBuffer (я предполагаю массив int16_t). Если вы работаете с данными PCM, то, что вы делаете, выглядит нормально. Вы также можете использовать newNumFrames * clientFormat.mBytesPerFrame * clientFormat.mChannelsPerFrame, но предполагая 16-битные данные PCM, mBytesPerFrame == mBytesPerPacket == 2. Если вы работаете с данными не-CBR, вам нужно позаботиться о описаниях пакетов, но похоже, это не так.