Re: Inconsistencies with large WAV file
Re: Inconsistencies with large WAV file
- Subject: Re: Inconsistencies with large WAV file
- From: Doug Wyatt <email@hidden>
- Date: Tue, 1 Dec 2009 17:24:52 -0800
If you subtract the reported size (-60672553) from 0x100000000LL, is it correct? I bet it is, which would point to a bug in our WAVE parser (albeit one that should be fairly easily worked around).
On Nov 30, 2009, at 23:59 , tahome izwah wrote:
> Hi all,
>
> I am looking at a strange problem and don't know what I might be doing
> wrong. I am currently on 10.5.8 dealing with a 5 channel 16 bit signed
> int WAV file that is 3.52 GB in size, which was (successfully) created
> by our app using the ExtAudioFile API. The file plays fine in
> QuickTime and the Finder preview.
>
> Now if I do...
>
> SInt64 nf=0;
> propSize = sizeof(SInt64);
> err = ExtAudioFileGetProperty(xafref,
> kExtAudioFileProperty_FileLengthFrames, &propSize, &nf);
> if (err) {
> NSLog(@"error in ExtAudioFileGetProperty, %d", err);
> ExtAudioFileDispose(xafref);
> return err;
> }
>
> ...to get the number of available frames in that file I am getting
> back a value of -60672553 in nf, with no error. This causes my app to
> refuse playing the file because it has an invalid length.
>
> If I write the same content to a CAF file everything works fine.
>
> How come that QuickTime can play the file, ExtAudioFile can create and
> write to it but that property reports back an incorrect file size?
> That doesn't make any sense - is there another API call that I should
> be using instead??
>
> Thanks, I'm really pulling my hair out over this.
> --th
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden