On Oct 19, 2012, at 8:54 AM, Heinrich Fink wrote:
- I can also confirm the results from your example project, 64 bit builds report 0 on both priming/remainder numbers. Note that you pass 441000 instead of supposedly 44100 to your PCM ASBD, but that doesn’t seem to influence the point you are making.
Whoops! Yeah, that code is whittled drawn from a more generalized case, so that's just a typo.
- I tried to reconstruct your approach of retrieving priming/remainder samples using the AudioConverter services:
- I construct the AudioConverter using the compressed format as the source format, and my desired linear PCM format as the target format
- If I have a magic cookie from a file, I pass it to the converter’s property kAudioConverterDecompressionMagicCookie
- I retrieve the prime info using the property kAudioConverterPrimeInfo
- As expected, under 64 bit this of course also reports zero for both priming and remainder figures
- Under 32-bit, I get 2112 for my test AAC-compressed file. However, even 32-bit mode doesn’t seem to be perfectly working, as I would also expect a remainder of 134 samples for my file but was given zero (134 was reported by the afinfo command line utility).
- Also, this approach using AudioConverter doesn’t report any priming/remainder figures for mp3 files.
Yes, I noticed this as well with the remainder versus what afinfo reports. I don't care so much about the trailing frames for what I'm doing, so I didn't really look into it. I'm seeing the same thing with mp3s as you've reported. That's a shame--I was hoping this method was close, but it appears to not be viable.
- Using AVFoundation I can use the sample buffer attachment keys TrimDurationAtStart and TrimDurationAtEnd, both under 32 and 64 bit, to correctly retrieve priming/remainder figures from AAC-compressed files. This approach, however, would require me to parse the complete file, as the TrimDurationAtEnd is only report in one of the last few sample buffers. Therefore this is not a desirable approach. These attachments are also not given for mp3 files, only for AAC compressed files.
That's strange… the AVFoundation-based method seems to work for the mp3s I tried it on, at least under 10.7.4. As for getting TrimDurationAtEnd, you can set up the reader right at the end of the asset so you don't have to read the whole thing in using -[AVAssetReader setTimeRange:(CMTimeRange)].
One other approach that I could think of, and that might also work for you, is to use the AudioFile services using AudioFileInitializeWithCallbacks. I would draw data using AVFoundation from the movie/sound file, and pass it to AudioFile services when the callbacks notify me of doing so. I would then hope to get proper priming/remainder figures using the AudioFile API.
Interesting if it works, though I feel somewhat doubtful. Seems excessively complicated! I wonder what AudioFile and ExtAudioFile are doing that they use their own heuristics instead of the AudioCodec's prime info...
Thanks for digging into this, Heinrech! Hopefully we'll come up with something workable. For now, I've got the AVFoundation stuff working on my end and it seems to be working with all the files I've tried.
Michael Miller