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: Wed, 2 Dec 2009 11:16:50 -0800
Yeah, I thought about this last night and should have posted this then...
AudioFile seems to be doing this with the file Tahome described:
num_channels = 5;
bytes_per_sample = 2; // 16-bit
bytes_per_frame = num_channels * bytes_per_sample; // 10
num_bytes_in_file = SInt64( UInt32( chunk.size ) );
// I think this type conversion is being sign-extended incorrectly, accounting for the bug
num_packets_in_file = num_bytes_in_file / bytes_per_frame;
>>> (0x100000000 - 60672553*10) / 10
368824176
which still isn't exactly what he said the correct value is but is much closer.
Doug
On Dec 2, 2009, at 7:52 , Howard Moon wrote:
>
> In his most recent post, he stated that the expected value was 368,404,342 (commas added). Subtracting 60,672,553 (the reported size, negative) from 4,294,967,296 (0x100000000) gives you 4,234,294,743, far greater than the expected value. I don't see any obvious relation between the expected value and the reported value.
>
>
>> 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
>
> _______________________________________________
> 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
_______________________________________________
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