AIFF stands for "Audio Interchange File Format". It uses "tags" or "chunks" of data within the file to store critical information. AIFF is versatile because there is no limit to how many chunks, and where you store them, within an AIFF - there are only a couple required data chunks.
Of course, it is up to the hardware platform to be able to interpret chunks correctly, and ignore the ones that are not applicable. One cannot blame the file format for that.
An interesting example is the way Sound Forge has elected to save AIFF files, and the way the ASR-X improperly tries to read them.
If you save a piece of audio data as an AIFF file within Sound Forge (SF calls it "Macintosh AIFF", probably only because Apple came up with the AIFF definition - in fact, AIFF is sometimes referred to as "Apple Interchange File Format"), it arranges the chunks in this manner (you have no option):
When the ASR-X saves an AIFF file, it stores the tags like this:
The problem is, the ASR-X doesn't like the INST and MARK tags that Sound Forge places AFTER the audio data - whenever you try to read one, you get "Disk read failed". As far as I know, there is no way on Sound Forge to disable the writing of these usually useless chunks. Even when you have not defined any loops, it still writes them. CoolEdit, on the other hand, being less sophisticated in the looping area, only writes the required chunks and thus does not have the same problem.
However, Sound Forge is properly following the AIFF spec - so this is really an ASR-X bug; since the OS should be tolerant of all chunks, and should even be able to read the INST and MARK chunks, since they are defined in the ASR-X anyway. It also shows how little Ensoniq beta-tests with PC's - this isn't the first time that they have missed an item that was PC-specific (re: SMDI) - this issue has existed since the ASR-X's release 18 months ago.
Contributed by Garth Hjelte
Back to ASR-X Knowledge Base Index