Thanks for the tip, I’m not sure I was aware of the implicit fading… you have triggered a thought, though, which is that the problem lies not in file conversion or my buffer processing, but in my seeks… re-reading the Apple docs on ExtAudioFileSeek I see that:
"Seek position is specified in the sample rate and frame count of the file’s audio data format—not your application’s audio data format” …which would certainly explain why only very specific source formats are failing, despite everything being converted to LPCM on the fly. It still doesn’t add up (to me) why file seeks would work seamlessly in one direction and not in another, though - perhaps something to do with the way packets are laid out for MP3? (and even then, why does MP3 320 work fine?) Anyone have experience with this aspect of ExtAudioFileSeek when reading moderately-to-highly compressed MP3s..? Best, Abel > On Jun 13, 2015, at 3:26 PM, Oneill707 <[email protected]> wrote: > > One issue I've run into is the implicit fading that extaudiofile does when a > seek has taken place when there is a format conversion. I have a silly > workaround where I seek back further than I need by X frames, then discard > the first X frames to get back to where I originally wanted. So if I wanted > frames 32000 -> 36096. I would seek to 31488, read 512 samples, then discard > them. Then I read my 4096 frames that I originally wanted and everything is > beautiful. I suppose the right way to do this would be to just use an > AudioFileRef and an AudioConverterRef directly instead of hacking > ExtAudioFile, but I'm just too lazy (or dumb) to figure it all out. > > > > On Jun 13, 2015, at 8:49 AM, Abel Domingues <[email protected] > <mailto:[email protected]>> wrote: > >> I’ve been knocking around lately with toggling bi-directional playback on >> streamed iPod Library tracks - successfully - using Extended Audio File >> Services. But I’ve run into a vexing issue with certain MP3 files and I >> wonder if anyone here has insight into what might be going on. >> >> What happens is certain files - specifically, any MP3 with a bit rate of >> less than 320kpbs - sound garbled and distorted when streamed in reverse >> (they sound fine when streamed normally, i.e. forward playback). The >> ‘garbled’ quality is definitely reminiscent of a flawed ASBD, but I’m fairly >> certain that isn’t the case here as all other files - AAC, WAV, etc *and* >> MP3s with a bit rate of 320 - stream in both directions beautifully. >> >> Here’s what I’m doing: >> >> - iPod Library Access: MediaPicker -> AssetURL -> ExtAudioFileOpenURL; >> >> - File Reading: Render Callback (on a MultiChannelMixer AU) calls a delegate >> method which in turn calls ExtAudioFileRead to fill the callback’s buffers… >> the delegate also maintains a frame index to know where its next read >> begins… client format is LPCM stereo interleaved float 32; >> >> - Reverse Playback: after the read - if reverse playback is selected - I run >> a short while loop to reverse the order of sample frames in the filled >> buffer, before handing it back to the callback… I then decrement the frame >> index (rather than increment it), check if we’ve reached start of file, etc… >> here’s my code for the while loop: >> >> Float32* revBuff = audioBufferList->mBuffers[0].mData; >> >> int i = 0; >> int j = *bufferSize - 1; >> Float32 tmp; >> >> while (j > i) { // works great! >> @autoreleasepool { >> tmp = revBuff[j]; >> revBuff[j] = revBuff[i]; >> revBuff[i] = tmp; >> j--; >> i++; >> } // end autoreleasepool >> } >> >> And here are the suspects I’ve tried to rule out: >> >> Suspect #1: my while loop is taking too long OR conversion takes longer on >> lower quality files, thereby leaving less time for the loop. >> >> However, I get similar mach_absolute_time numbers for both ‘good’ files and >> ‘bad’ ones… here's an approximate, but representative, sampling of those >> numbers: >> >> - ExtAudioFileRead (just the read, not the seek or anything else): 30000 >> (forward) / 90000 (reverse). >> >> This in itself is something of a mystery: since ExtAudioFileRead always >> performs synchronous sequential reads in the same (forward) direction - that >> is, it’s doing the same work regardless of my playback direction - I would >> expect to see NO significant difference in timings between forward and >> reverse playback… but again, I’m getting these same numbers for both ‘good’ >> and ‘bad’ files; >> >> - Seek times for each read: 30 or so for forward reads, 700 or so for >> reverse (all files); >> >> - Callback Execution (from entry to exit): 60000 (forward) / 100000-140000 >> (reverse) (all files); >> >> - Reverse Loop: 2400 (all files). >> >> Suspect #2: Because lower bit rate MP3s contain a greater number of >> artifacts, perhaps these appear more prominently when the file is played in >> reverse (I’m grabbing at straws here but I dunno, I’m not a codec guy, maybe >> some Fraunhofer psychoacoustic hootchycoo is coming into play.) >> >> OR: >> >> Suspect #3: ExtAudioFileRead has more difficulty converting lower rate MP3s >> and the conversion it produces is flawed in ways that are not fully evident >> until you play the file in reverse (more straw grabbing). >> >> However, I’ve tried (a) loading the original low bit MP3 into Audacity and >> reversing it; and (b) directly recording (within the app, using normal >> playback) the output of my ExtAudio-converted stream, saving it to file, >> then opening *that* file and streaming it in reverse: in both cases the >> files sound perfectly fine played backwards. >> >> I’m getting the same playback results, btw, with the same files, on both my >> 64bit iPhone 6 and my 32bit iPhone 5. >> >> The other mystery is: during reverse playback of ‘good’ files there is a CPU >> jump of about 14%… with bad files it is *lower* and it does a slow climb - >> 6-8-10%, like that - but never going higher. I might have expected the >> opposite. >> >> This is really starting to dog me as I feel I must be missing something >> obvious… Anyone? >> >> Best, >> Abel >> >> www.mojolama.com >> <http://www.mojolama.com/>_______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Coreaudio-api mailing list ([email protected] >> <mailto:[email protected]>) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/coreaudio-api/oneill707%40gmail.com >> <https://lists.apple.com/mailman/options/coreaudio-api/oneill707%40gmail.com> >> >> This email sent to [email protected] <mailto:[email protected]>
_______________________________________________ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to [email protected]
