On Jan 27, 2009, at 7:16 PM, William Stewart wrote:
what if framesRead > frames?
Honestly haven't tried that, but I'm assuming it would cause some serious weirdness:
1. i'd be seeking past the end of the file ("frames" is set to the number of frames in the file via the appropriate ExtAudioFile property), I would probably get an error right there...
2. r would always be 65536, it would try to read frames past the end of the file
3. after the first pass, whether or not it got all the frames within 65536, it would fall out of the do/while loop
...it would function as a sort of "bulk read" of 65536 frames in one shot, but the initial seek position would be wrong just by nature.
This code snippet intended the "framesRead" to function as an "initial start frame position" in the file, then reading through to the end of the file. It might be better labeled as "framesThatHaveBeenRead", if that makes sense.
---
further investigation into this is leaning me towards this unexpected behavior having something to do with "leading frames" in the converter, but I'm not sure how to fix/address that with the API, or even if that's really the real problem.
On Jan 26, 2009, at 1:51 PM, Evan Olcott wrote:
I've noticed something strange about ExtAudioFileRead:
using this code segment on an alac compressed CAF file:
(which is essentially a read-through of a file from a given frame)
====
unsigned int framesRead = 0;
ExtAudioFileSeek(extAudioFile, framesRead);
do
{
UInt32 r = MIN(65536, frames - framesRead);
err = ExtAudioFileRead(extAudioFile, &r, buffer); // <-- buffer is allocated to 65536 frames
if (r == 0) break;
framesRead += r;
}
while (framesRead < frames);
NSLog(@"preread leftover: %d", frames - framesRead);
====
When framesRead is 0, the leftover I have is 0, looks like everything read fine.
When framesRead is non-zero (1024, 2112, 10240), the leftover is also not zero. I can never fully read the file - I get premature EOFs.
Is this an issue in usage on my part, is it a bug I can file, or do I have to roll my own?