Я действительно не пробовал API AudioFileStream для этого (мы развернули наш собственный), но вот несколько вещей, о которых вы должны позаботиться.
Предполагая, что у вас нет проблем при случайном поиске потока байтов, вы должны отслеживать связь между номером кадра MP3 и абсолютным местоположением потока байтов, как говорит Пол. Я предполагаю, что вы можете сделать это в вашем AudioFileStream_PacketsProc, вызвав AudioFileStreamSeek по пути.
Вот самая сложная часть. Когда вы делаете случайный поиск, вы должны сбросить внутренние состояния AudioFileStream. Потому что он может находиться в некотором промежуточном состоянии, ожидая, что следующие входящие байты завершат текущий кадр. Я не уверен, что вы можете просто кормить нули, чтобы пропустить текущий кадр, и начать все сначала (что вы должны попробовать, так как я не вижу ничего похожего на AudioFileStreamReset в API; однако сама аудио-очередь делает есть функция сброса, что вы можете очистить уже в очереди кадра). В любом случае вы должны позаботиться и о AudioFileStream_PacketsProc, потому что вы собираетесь анализировать часть потока байтов, который вы уже отслеживали.
Обратите внимание, что вы не можете просто найти начало кадра MP3, полагаясь на второй и битрейт. Даже с MP3-потоком с нерегулируемой скоростью могут быть отступы через каждые несколько кадров. Таким образом, наиболее точная информация все еще поступает от парсера.
Я должен быстро добавить, что другим способом случайного поиска является просто "кэширование" (сохранение) проанализированных пакетов, если вы не воспроизводите действительно длинный и большой поток. Индекс кадра можно рассчитать из информации заголовка кадра. Для MP3 без VBR количество кадров в секунду является константой (например, 44100/1152 = 38,28125 кадров в секунду для стереофонического MP3 без 44 VBR 44,1 кГц; посмотрите, почему это так, в спецификации MP3).