Talk:Interchange File Format

List of common IFF-based file formats

Certain formats in the list are not actually IFF or RIFF based formats, and at least one (GIFF, which I have never encountered or even heard of before today) may not even exist. Mainly, the file formats used by Microsoft Office products are not IFF based (although they may have been in the past). Instead, these files have been, since at least Office 97, been based on the OLE DocFile format, which is very similar to the FAT file system. --coldacid 23:00, 2005 Apr 4 (UTC)

I've looked at the structure of word 6, and word 95 .doc files, and they are certainly not IFF files. Given the stickyness of file formats and the fact that word predates the IFF85 document, I doubt it ever was in IFF format. --210.23.136.187 00:02, 22 August 2005 (UTC)

The link to the SMUS file system is definitifly not the correct one. SMUS is/was a Amiga music format and not a university school --80.129.144.169 18:22, 27 October 2005 (UTC) Linne

The SMUS link is now fixed. // Liftarn

open file format

I wish this article answered this question: Was the IFF an open file format from the beginning, a proprietary format that is now open, or is it still a closed format? --68.0.124.33 (talk) 23:15, 6 November 2010 (UTC)

It is a proprietary but open format. The IFF was completely open from the beginning but was maintained by Commodore Amiga Technical Support (known as CATS). Xorxos (talk) 23:33, 6 November 2010 (UTC)

Broken link

In section External links the link "Article on IFF", http://www-128.ibm.com/developerworks/power/library/pa-spec16/?ca=dgr-lnxw07IFF, seems to be (effectively) broken. --Mortense (talk) 19:40, 17 February 2015 (UTC)

compatible/incompatible?

Why are the words "compatible" and "incompatible" used for the AIFF and RIFF links respectively? Is this just anti-Microsoft hostility? If not, they need some justification.

Chunk length: Signed or unsigned?

The article currently states that the length indicator of each IFF chunk is a signed integer. I believe this is an implementation mistake that happens easily in C and C++ style languages. It's far less likely to happen in Motorola 680x0 assembler, which was quite common on the Amiga platform. Also, a negative size does not make sense, and it limits the maximum file size from 4 to 2 GB, which I believe is also not correct. Sadly the official documentation on the IFF standard is difficult to locate, but the corresponding documentation on the RIFF format clearly states that the chunk length field is "a 32-bit unsigned value identifying the size of ckData. This size value does not include the size of the ckID or ckSize fields or the pad byte at the end of ckData." See also [This page] which does a quick summary of the IFF format.

 — Preceding unsigned comment added by Joachim Michaelis (talk • contribs) 18:11, 16 October 2023 (UTC)