2008/8/6 Richard Dobson <email@hidden>:
> Stephen Davis wrote:
>>
>> The FLLR chunk is added by the AudioFile code to align the data chunk on a
>> 4K page boundary for optimized I/O during playback.
>>
>> The AIFF specification says to ignore chunks you don't recognize and skip
>> over them. This is such a chunk. :-)
>>
>> As for the NONE chunk, it is not a separate chunk but is found in the
>> "compressionType" field of the COMM chunk.
>>
>
> Only in AIFC files (the COMM chunk is larger there with extra fields). AIFF
> does not support compression (or 32bit floats). But the recommendation is
> that AIFC supercedes AIFF, so should be used for everything, these days.
>
> Richard Dobson
>
> _______________________________________________
> 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
>
Ok, thanks. As I'm the recorder of the sound and then there is only me
to analyse it (then the sound file is deleted), I thing I can use
uncompressed AIFF, no?
Please correct me if I go wrong, but if I move to the SSND chunk, I
should find very closed to it the "sound data", shouldn't I?
And these data must be of type float, from -1.000 to 1.000, right? If
it's true, then I don't understand why I'm getting stange numbers
(xxx.xx E-41 for example).
Here is a screenshot of my file opened with some hexadecimal editor.
My app is reading from 00 22 00 00 until the end of file.
http://cpcstats.free.fr/upload/files/1218044603_Image_1.png
May be it's not float? May be the offset isn't good? I tried many
combinations but I can't get one "good" float value...
--
François Baronnet
_______________________________________________
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
