Hubbry Logo
search
logo
Interchange File Format avatar
Interchange File Format
Interchange File Format
current hub
I

Interchange File Format

logo
Community Hub0 Subscribers
Read side by side
Interchange File Format
View on Wikipedia
from Wikipedia
Interchange File Format
Internet media typeapplication/x-iff
Developed byElectronic Arts, Commodore
Initial release1985; 40 years ago (1985)
Type of formatDigital container format

Interchange File Format (IFF) is a generic digital container file format originally introduced by Electronic Arts (in cooperation with Commodore) in 1985 to facilitate transfer of data between software produced by different companies.

IFF files do not have any standard filename extension. On many systems that generate IFF files, file extensions are not important because the operating system stores file format metadata separately from the file name. The .iff filename extension is commonly used for the ILBM image file format, which uses the IFF container format.

Resource Interchange File Format is a format developed by Microsoft and IBM in 1991 that is based on IFF, except the byte order has been changed to little-endian to match the x86 microprocessor architecture. Apple's Audio Interchange File Format (AIFF) is a big-endian audio file format developed from IFF. The TIFF image file format is not related to IFF.

Structure

[edit]

An IFF file is built up from chunks. Each chunk begins with what the specification calls a "Type ID" (what the Macintosh called an OSType, and Windows developers might call a FourCC). This is followed by a 32-bit signed integer (all integers in IFF file structure are big-endian) specifying the size of the following data (the chunk content) in bytes.[1] Because the specification includes explicit lengths for each chunk, it is possible for a parser to skip over chunks that it either can't or doesn't care to process.

This structure is closely related to the type–length–value (TLV) representation.

There are predefined group chunks, with type IDs FORM, LIST and CAT .[NB 1] A FORM chunk is like a record structure, containing a type ID (indicating the record type) followed by nested chunks specifying the record fields. A LIST is a factoring structure containing a series of PROP (property) chunks plus nested group chunks to which those properties apply. A CAT  is just a collection of nested chunks with no special semantics. Group chunks can contain other group chunks, depending on the needs of the application. Group chunks, like their simpler counterparts, contain a length element. Skipping over a group can thus be done with a simple relative seek operation.

Chunks must begin on even file offsets, as befits the origins of IFF on the Motorola 68000 processor, which couldn't address quantities larger than a byte on odd addresses. Thus chunks with odd lengths will be "padded" to an even byte boundary by adding a so-called "pad byte" after their regular end.

The top-level structure of an IFF file consists of exactly one of the group chunks: FORM, LIST or CAT , where FORM is by far the most common one.

Each type of chunk typically has a different internal structure, which could be numerical data, text, or raw data. It is also possible to include other IFF files as if they are chunks (note that they have the same structure: four letters followed with length), and some formats use this. There are standard chunks that could be present in any IFF file, such as AUTH (containing text with information about author of the file), ANNO (containing text with annotation, usually name of the program that created the file), NAME (containing text with name of the work in the file), VERS (containing file version), (c)  (containing text with copyright information). There are also chunks that are common among a number of formats, such as CMAP, which holds color palette in ILBM, ANIM and DR2D files (pictures, animations and vector pictures). There are chunks that have a common name but hold different data such as BODY, which could store an image in an ILBM file and sound in an 8SVX file. And finally, there are chunks unique to their file type. Some programs that create IFF files add chunks to them with their internal data; these same files can later be read by other programs without any disruption (because their parsers could skip uninteresting chunks), which is a great advantage of IFF and similar formats.

See also

[edit]
  • AIFF (a big-endian compatible derivative of IFF, originally from Apple)
  • FourCC (the chunk identification approach used by many TLV formats, including IFF, as verbose Magic number)
  • Interleaved Bitmap (ILBM) (a very popular IFF-based image file format)
  • PNG (a modern graphics file format with a chunk structure inspired by IFF)
  • RIFF (a little-endian incompatible derivative of IFF, originally from Microsoft)
  • TLV (the generic format that IFF is an example of)

Notes

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Interchange File Format

View on Grokipedia
from Grokipedia
The Interchange File Format (IFF), formally designated as EA IFF 85, is a generic binary container format developed by Electronic Arts in 1985 to enable standardized data interchange between diverse applications and platforms, initially targeted at the Commodore Amiga computer system.[1] It organizes content into a hierarchical structure of self-describing "chunks," each prefixed with a four-character ASCII identifier (e.g., FORM for complete data objects, LIST for grouped elements, and CAT for untyped collections), followed by a 32-bit size field and the data payload, ensuring even-byte alignment and extensibility for new data types without breaking compatibility.[1] Released into the public domain by author Jerry Morrison on January 14, 1985, and later updated in October 1988 by Commodore-Amiga, Inc., the format was designed to address the fragmentation of proprietary file structures in multimedia development, promoting interoperability for assets like images (e.g., ILBM), audio (e.g., 8SVX), and text (e.g., FTXT).[1][2] IFF's core architecture supports nested groupings via FORM (a single typed object), LIST (a collection with shared properties defined by PROP chunks), and CAT (a flat catalog of subgroups), all adhering to big-endian byte order compatible with Motorola processors like the Amiga's MC68000.[1] This chunk-based approach allows parsers to skip unknown sections, facilitating forward compatibility and making IFF suitable for complex, multi-part files in creative workflows.[1] Widely adopted in the 1980s and 1990s for Amiga software—such as Deluxe Paint for graphics and various sound editors—the format influenced subsequent standards, including Microsoft's RIFF (used in WAV and AVI) and Apple's AIFF for audio interchange.[2] Despite its age, IFF remains relevant in legacy preservation and niche applications, with tools like IFFCheck and IFFJoin provided in the original specification to validate and manipulate files.[1] Its open documentation and lack of licensing restrictions have ensured long-term sustainability, though modern usage is limited by the shift to more specialized formats.[2]

History and Development

Origins

The Interchange File Format (IFF), also known as EA IFF 85, was developed by Electronic Arts (EA) in 1985 in close cooperation with Commodore International to serve as a standardized container for the Amiga platform.[3][2] This collaboration involved contributions from EA engineers and Commodore-Amiga staff, including technical support and documentation to ensure compatibility with Amiga hardware.[3][4] The format was released to the public domain on January 14, 1985, and later updated in October 1988 by Commodore-Amiga, Inc., with the explicit aim of fostering interoperability in an era of rapidly evolving personal computing.[3][4] The primary goal of IFF was to create a generic, extensible container format that enabled seamless data interchange between software applications developed by different creators, countering the fragmentation caused by proprietary file formats in early personal computing.[3][2] As data development became more resource-intensive—requiring specialized expertise, advanced tools, and cross-project sharing—EA recognized the need for a unified standard to reduce costs and enhance portability across programs and even different computers.[3] This approach emphasized longevity and flexibility, allowing multimedia content like images, audio, and text to be exchanged without vendor lock-in.[3] Key designers at EA, led by Jerry Morrison and including Steve Shaw, along with contributors such as Bob Burns, R.J. Mical, Greg Riker, Dan Silva, Barry Walsh, and Steve Hayes, documented the format in the "EA IFF 85" specification, which outlined conventions for file structure and provided public-domain source code examples to promote widespread adoption.[3][4] Commodore-Amiga contributed additional resources, such as a registry for chunk identifiers, to support ongoing development.[3] IFF emerged during the Amiga's launch in 1985, a period when the platform's advanced multimedia capabilities—such as high-resolution graphics and sampled audio—demanded robust formats for games and creative software applications.[2][3] Tailored for floppy disk-based media projects on Amiga systems, it addressed the challenges of sharing complex data in a nascent home computing ecosystem dominated by proprietary tools.[3] The chunk-based design facilitated modular organization of diverse content types, laying the groundwork for its use in early Amiga titles and utilities.[3]

Adoption and Influence

The Interchange File Format (IFF) saw rapid adoption within the AmigaOS ecosystem by 1986, becoming the native standard for storing system and application files across various data types, including graphics, audio, and text. This integration was facilitated by Commodore's developer tools, such as the iffparse.library and graphics routines like ReadPicture and PutPict, along with example code like Display.c, which embedded IFF support directly into the operating system's libraries and utilities.[5][3] By early 1986, specific IFF-based formats like ILBM for raster images were released and in active use, with source code examples dated January 1986 demonstrating seamless incorporation into AmigaOS workflows.[3] Early Electronic Arts titles played a key role in promoting IFF adoption, particularly Deluxe Paint, which utilized the format for image storage and editing, enabling interoperability with other Amiga applications. This usage extended to games like Defender of the Crown, where IFF served as a container for graphics assets created with tools such as GraphiCraft, fostering its spread among third-party Amiga software developers.[3] By leveraging IFF's modular structure, these programs encouraged a shift toward standardized data interchange, reducing reliance on proprietary formats and promoting compatibility across the growing Amiga software library.[6] IFF's design as an extensible container format influenced broader computing standards, serving as a model for modular data storage that prioritized forward and backward compatibility. Its chunk-based approach inspired subsequent formats, including Microsoft's RIFF, which adapted IFF's tagged structure for little-endian systems, and the Standard MIDI File (SMF), both crediting IFF for foundational ideas in handling diverse data types within a single file.[2][6] This legacy contributed to an industry trend in the early 1990s toward flexible, self-describing file formats that could evolve without breaking existing applications.[2] Despite its strengths, IFF faced challenges due to its strict big-endian byte order, which aligned with the Amiga's Motorola 68000 architecture but complicated cross-platform portability to little-endian systems like Intel-based PCs. Poor implementations exacerbating these endianness issues led to compatibility problems, limiting widespread adoption outside Amiga environments until endian-agnostic variants and converters emerged.[6][7][8]

Technical Specifications

Chunk Structure

The Interchange File Format (IFF) employs a chunk as its atomic unit of data encapsulation, enabling modular organization of file contents. Each chunk begins with a 4-byte Type ID, known as a FourCC, which consists of four ASCII characters serving as a unique identifier for the chunk's content type and purpose; for example, the identifier 'BODY' denotes the primary data payload in certain IFF variants.[9] This ID is stored as a 32-bit value in big-endian byte order.[10] Immediately following the Type ID is a 4-byte length field, represented as a 32-bit big-endian unsigned integer, that specifies the exact size in bytes of the subsequent data payload, excluding the ID and length fields themselves.[8] The data payload then occupies the variable-length space indicated by this field, comprising the actual content tailored to the chunk's type, such as binary image data or metadata.[9] In layout terms, a complete chunk comprises the 4-byte ID, the 4-byte length, and the payload of precisely that length, resulting in a total size of 8 bytes plus the payload length; if the payload length is odd, it is typically padded with a single zero byte to ensure even-byte alignment, though this padding is not counted in the length field.[10] This structure promotes efficient parsing and extensibility, as applications can skip unrecognized chunks by advancing based on the length value.[9]

File Organization and Groups

The Interchange File Format (IFF) organizes data hierarchically through chunks, where individual chunks are aggregated into larger structures known as groups to form complete files. At the top level, an IFF file consists of a single enclosing chunk of type FORM, LIST, or CAT, which encapsulates all subsequent data and ensures the file's integrity by defining its boundaries.[10] The FORM chunk serves as the primary group for a single coherent record, such as an image or sound file, and is identified by the chunk ID "FORM" followed by a four-character FormType identifier that specifies the overall data type. It contains nested sub-chunks, which can include local chunks specific to the FormType or further groups like FORM, LIST, or CAT, allowing for modular composition of related data elements. The chunk size field in FORM encompasses the FormType and all nested contents, with padding added if necessary to maintain even byte alignment.[11] In contrast, the LIST chunk provides a mechanism for grouping collections of properties or related items, denoted by the chunk ID "LIST" and a ContentsType identifier that describes the nature of the enclosed data. It may include optional property (PROP) chunks for shared metadata, followed by nested FORM, LIST, or CAT groups, enabling extensible structures like lists of annotations or modular extensions without altering the core format. The LIST's size field similarly accounts for all sub-elements, promoting flexibility in file organization.[12] The CAT chunk, identified by "CAT ", facilitates the categorization of multiple unrelated forms within a single file, such as in archives or multi-part documents, and includes a ContentsType to indicate the overarching category. It directly nests FORM, LIST, or CAT sub-groups, allowing concatenation of disparate data sets while maintaining the IFF's chunk-based integrity. Like other groups, its size field spans the ContentsType and all nested components.[12] Nesting in IFF follows recursive rules where groups can contain other groups or local chunks, with the enclosing group's ID (FormType or ContentsType) signaling its semantic purpose and guiding parsers on how to interpret the hierarchy. The size of the first sub-chunk is effectively adjusted within the parent's size calculation to include the full extent of all nested elements, ensuring seamless traversal without fixed offsets. This design supports arbitrary depth while preserving extensibility.[13] IFF files terminate implicitly at the end of the top-level group's data, including any required padding byte for odd-length contents, with no explicit end marker; any extraneous data beyond this boundary is to be ignored to accommodate potential file transfer artifacts. This organization relies on the basic chunk structure—where each chunk begins with a four-character ID and a 32-bit length field—for reliable parsing of the hierarchy.[13]

Data Representation and Padding

In the Interchange File Format (IFF), data within chunks is encoded using big-endian byte order for all multi-byte values, such as 16-bit words and 32-bit longs, to align with the Motorola 68000 processor's native format prevalent in Amiga systems.[3] This ensures that higher-order bytes precede lower-order ones, facilitating consistent interpretation across compatible hardware. Chunk data itself varies by type and may encompass binary representations like signed or unsigned integers, 8-bit ASCII text for character streams, or structured sub-data such as interleaved bitplanes in image chunks or raw audio samples in sound chunks, allowing flexibility for diverse multimedia content while maintaining a uniform overarching structure.[3] To preserve alignment and processing efficiency, IFF employs a padding mechanism where any chunk whose data length—as specified by the 32-bit ckSize field—is odd has a single zero byte (0x00) appended at the end.[3] This padding makes the total physical size of the chunk even, ensuring that subsequent chunks begin on even byte boundaries and supporting 2-byte word alignment critical for the Amiga's 68000 processor, which operates more efficiently with aligned memory access.[3] The padding byte is not included in the ckSize value, which reports only the logical length of the actual data payload, requiring parsers to skip it explicitly during file traversal to avoid misinterpreting the extraneous zero as valid content.[3] This design choice underscores IFF's emphasis on hardware-optimized interchange, where even alignment minimizes overhead in block I/O operations and prevents errors from unaligned reads on big-endian architectures.[3] For instance, in audio or image chunks, this ensures that sample or pixel data streams seamlessly without fragmentation, promoting reliable cross-application compatibility in early multimedia environments.[3]

Applications

In AmigaOS and Early Computing

The Interchange File Format (IFF) was natively integrated into AmigaOS starting with version 1.0, released in 1985, as a foundational element for data interchange on the platform. Developed by Electronic Arts in collaboration with Commodore, IFF provided a structured, extensible container for various data types, aligning closely with AmigaOS's emphasis on multimedia capabilities. Early system libraries, such as intuition.library for graphical user interface elements and graphics.library for rendering, supported the display and playback of content parsed from IFF files by applications, enabling seamless integration without requiring third-party tools.[10][6][14] IFF became ubiquitous in AmigaOS system files, serving as a de facto standard for developers due to its chunk-based extensibility. Fonts were stored using the FNTR (raster) or FNTV (vector) FORM types, allowing scalable typography in applications and the Workbench interface. Preferences files employed the PREF FORM for user configurations, such as display settings and input devices, while icon data in .info files utilized the INFO FORM to embed small ILBM bitmaps and metadata for the desktop environment. Project files, like those from development tools such as ToolMaker, adopted specialized IFF variants (e.g., TMUI FORM) to encapsulate scripts, resources, and metadata, promoting modular development workflows. This widespread adoption made IFF essential for Amiga software ecosystems, with developers leveraging its structure to ensure compatibility across tools.[15][2][16] In the resource-constrained environment of 1980s and early 1990s computing, IFF's design enabled efficient cross-application data sharing on the Amiga, where memory and processing limits demanded lightweight formats. For instance, ILBM graphics chunks could be directly loaded from one editor into another without conversion, while 8SVX audio chunks allowed sounds to be imported into sequencers or players, fostering collaborative workflows in demoscene productions and game development. This interoperability reduced development overhead and accelerated content creation, positioning IFF as a key enabler of Amiga's creative computing niche. Later libraries like iffparse.library (introduced in AmigaOS 2.0) and datatypes.library (from AmigaOS 3.0) further streamlined IFF handling, building on the format's early foundations.[17][18][6] IFF usage in AmigaOS declined in the post-1990s era following Commodore's bankruptcy in 1994 and the platform's commercial obsolescence, as developers shifted to more dominant systems like Windows and Macintosh. Subsequent AmigaOS iterations, such as version 3.1 (1994) and the modern AmigaOS 4.x by Hyperion Entertainment, retained backward compatibility for legacy IFF files but prioritized newer formats for multimedia. Nonetheless, support persists in emulators like WinUAE and FS-UAE, allowing archival access to historical Amiga content and preserving IFF's role in retro computing communities.[2][19]

In Multimedia and Software

The Interchange File Format (IFF) has been extensively applied in multimedia contexts, particularly on the Amiga platform, where it serves as a container for various media types including images, audio, and animations. One prominent example is the ILBM (InterLeaved BitMap) format, which encapsulates raster graphics data within a FORM group. The ILBM structure includes essential chunks such as 'BMHD' for the bitmap header, which specifies image dimensions (width and height), the number of bitplanes, masking options, compression method (typically none or ByteRun1), and aspect ratios; 'CMAP' for the color map, storing RGB values for up to 256 colors in 3-byte triplets; and 'BODY' for the pixel data, organized in interleaved bitplanes to support the Amiga's hardware rendering capabilities. This design allows ILBM files to handle planar pixel storage efficiently, making them suitable for high-color-depth images like those using Hold-And-Modify (HAM) modes.[3] In audio applications, the 8SVX (8-bit Sampled Voice) format utilizes IFF to store digitized sound samples, primarily for one-shot effects or musical instruments. It employs a FORM container with chunks including 'VHDR' for the voice header, which defines parameters such as sample rate (samples per second), the number of octaves, playback volume, and compression type (none or Fibonacci-delta encoding); 'CHNL' for channel information, supporting mono (left or right) or stereo playback with panning options; and 'BODY' for the actual audio data, consisting of 8-bit signed pulse-code modulation (PCM) samples grouped by octave for efficient looping. This structure enables compact storage of raw audio waveforms, optimized for the Amiga's 8-bit Paula sound chip.[3] For animations, the ANIM format leverages IFF to sequence multiple ILBM frames into a cohesive video stream, facilitating cel-based animation workflows. It organizes content within a FORM group, where the first frame typically embeds a full ILBM structure, and subsequent frames use 'ANHD' chunks for animation headers that include frame numbering, operation codes (e.g., for delta compression), timing information (jiffies per frame), viewport parameters, and interleave settings to control playback speed and positioning. Additional 'BODY' chunks or 'DLTA' (delta) chunks store frame differences, such as byte-vertical or sprite-based updates, reducing file size while maintaining compatibility with ILBM pixel data. This approach supports hardware-accelerated rendering on Amiga systems.[3] IFF's multimedia role extends to third-party software integrations, where it provides a standardized medium for asset handling. Similarly, Sculpt 3D utilizes ILBM for texture mapping on 3D models and ANIM for exporting rendered sequences, enabling seamless integration of raster graphics into polygonal scenes.[20] Electronic Arts games, such as those developed with their proprietary tools, frequently employ IFF for storing multimedia assets like sprites (via ILBM) and sound effects (via 8SVX), leveraging the format's chunk-based extensibility for game data interchange.[3] Filename conventions for IFF multimedia files are informal but commonly follow patterns tied to their content types, lacking strict standardization. Image files in ILBM format are often saved with .iff or .lbm extensions, the latter aiding cross-platform compatibility with IBM PCs; audio in 8SVX typically uses .8svx, while ANIM sequences may employ .anim, though many tools default to the generic .iff for mixed-content files.[3]

Related Formats and Variants

RIFF and Microsoft Derivatives

The Resource Interchange File Format (RIFF) was developed by Microsoft and IBM in August 1991 as an extensible structure for multimedia data exchange on personal computers, directly adapting the chunk-based model of the earlier Interchange File Format (IFF) while optimizing for x86 architecture compatibility.[21][22] Unlike IFF's big-endian byte order, RIFF defaults to little-endian ordering to align with Intel processors, with an optional RIFX variant for big-endian systems.[21] A key structural difference from IFF lies in RIFF's use of a top-level 'RIFF' form identifier followed by a four-character code (FOURCC) specifying the form type, such as 'WAVE' for audio or 'AVI ' for video, which then contains nested chunks and lists of sub-chunks.[21] This maintains IFF's hierarchical chunk organization—where each chunk has a FOURCC identifier, a 32-bit size field, and data—but encapsulates the entire file within the 'RIFF' form for streamlined parsing in Windows environments.[21] Prominent RIFF derivatives include the WAVE format for uncompressed pulse-code modulation (PCM) audio, which employs a 'WAVE' form type containing essential chunks like 'fmt ' to describe audio parameters (e.g., sample rate, bit depth, and channel count) and 'data' to store the raw waveform samples.[21] Similarly, the Audio Video Interleave (AVI) format uses an 'AVI ' form type, organizing content into a 'hdrl' list for header information (including stream formats and timings) and a 'movi' list for interleaved audio and video stream data, enabling synchronized playback.[23][21] RIFF became the foundational standard for multimedia handling in Microsoft Windows, integrated into APIs such as the Windows Multimedia (WinMM) library for file I/O, playback, and recording of RIFF-based formats like WAVE and AVI.[24] This adoption extended to later frameworks, including DirectShow, which leverages RIFF structures for parsing and rendering video streams, thereby influencing codec development and multimedia application design in Windows ecosystems.[23][22]

AIFF and Other Extensions

The Audio Interchange File Format (AIFF) was developed by Apple Computer, Inc., in 1988 as a specialized extension of the Interchange File Format (IFF) for storing uncompressed audio data, retaining IFF's big-endian byte order and modular chunk structure while focusing on sampled sound applications.[25] The format organizes audio files within a top-level FORM chunk identified by the type 'AIFF', which encapsulates sub-chunks such as the Common chunk ('COMM') and the Sound Data chunk ('SSND').[25] The 'COMM' chunk specifies essential audio parameters, including the number of channels (e.g., 1 for mono or 2 for stereo), the total number of sample frames, the sample size in bits (ranging from 1 to 32), and the sample rate as an 80-bit extended IEEE floating-point value.[25] The 'SSND' chunk contains the actual audio samples, preceded by an offset (typically 0) and a block size value (typically 0 for no special alignment needs), with samples stored in interleaved channels for multi-channel audio.[25] AIFF supports variable sample precisions to accommodate professional audio needs, storing 1- to 8-bit samples in one byte, 9- to 16-bit samples in two bytes, 17- to 24-bit samples in three bytes, and 25- to 32-bit samples in four bytes, with higher-bit samples left-justified and padded with zeros.[25] It includes optional chunks for enhanced functionality, such as the Marker chunk ('MARK'), which defines cue points by marker ID, position in sample frames, and name, and the Instrument chunk ('INST'), which supports loop markers for sustain and release loops with modes like forward looping or forward-backward looping.[25] These features extended IFF's grouping mechanism for audio-specific uses, enabling applications like SoundJam MP, a professional audio player and encoder released in the late 1990s, to handle AIFF files for playback, conversion, and editing of high-fidelity tracks alongside formats like WAV and MP3.[26] An extension to AIFF is the Audio Interchange File Format Compressed (AIFF-C), introduced by Apple in 1991, which allows for compressed audio data using algorithms such as μ-law and IMA ADPCM within the same IFF-based structure, providing a balance between file size and quality for audio interchange.[27] Beyond AIFF, other IFF-derived extensions emerged to address platform-specific or cross-platform needs, notably the Resource Interchange File Format eXtended (RIFX), a big-endian variant of the little-endian RIFF designed for compatibility in mixed-endian environments.[28] RIFX uses the identifier 'RIFX' instead of 'RIFF' and maintains the same chunk-based structure but with Motorola (big-endian) byte ordering, facilitating use in Macintosh software for multimedia files like those in Adobe Director, where it ensured seamless audio and animation handling across Mac and other systems.[29] In contemporary contexts, AIFF's usage has diminished with the rise of compressed formats, but it persists as a legacy standard in audio workflows, supported for import and export in tools like Audacity, where it enables uncompressed editing of legacy files up to 4 GB in size without quality loss.[30] This ongoing compatibility in open-source editors underscores AIFF's enduring role in preserving high-resolution audio archives, particularly for professional and archival applications requiring IFF's extensible framework.[31]

References

  1. EA IFF 85 Standard for Interchange Format Files
  2. IFF (EA Interchange File Format 1985) - Library of Congress
  3. [PDF] COMPUTERS - Amiga Users Group of Victoria
  4. Appendix A / EA IFF 85: Standard for Interchange Format Files
  5. A Quick Introduction to IFF - AmigaOS Documentation Wiki
  6. IFF: Summary from the Encyclopedia of Graphics File Formats
  7. IFF file format experiments - Sander van der Burg's blog
  8. Interchange File Format (IFF) - ModdingWiki
  9. "EA IFF 85" Standard for Interchange Format Files - Martin Reddy
  10. EA IFF 85 Standard for Interchange Format Files
  11. https://wiki.amigaos.net/wiki/EA_IFF_85_Standard_for_Interchange_Format_Files#Data_Sections
  12. https://wiki.amigaos.net/wiki/EA_IFF_85_Standard_for_Interchange_Format_Files#LISTs.2C_CATs.2C_and_Shared_Properties
  13. https://wiki.amigaos.net/wiki/EA_IFF_85_Standard_for_Interchange_Format_Files#Standard_File_Structure
  14. Amiga® RKM Devices: Appendix A - IFF: Interchange File Format
  15. IFF FORM and Chunk Registry - AmigaOS Documentation Wiki
  16. 13 / / Preference File Format in Release 2 / The Data Chunk
  17. 33 IFFParse Library - Amiga Developer Docs
  18. Datatypes Library - AmigaOS Documentation Wiki
  19. IFFParse Library - AmigaOS Documentation Wiki
  20. [PDF] understanding music on the Amiga
  21. ANIM - Just Solve the File Format Problem
  22. [PDF] Multimedia Programming Interface and Data Specifications 1.0
  23. RIFF (Resource Interchange File Format) - Library of Congress
  24. AVI RIFF File Reference - Win32 apps - Microsoft Learn
  25. Resource Interchange File Format Services - Win32 - Microsoft Learn
  26. [PDF] Audio Interchange File Format: "AIFF"
  27. Casady & Greene Soundjam MP1.6 - Sound On Sound
  28. RIFX - Just Solve the File Format Problem - Archiveteam
  29. A Tour of the Adobe Director File Format | by nosamu - Medium
  30. IFF - MultimediaWiki - Multimedia.cx
  31. Export Formats supported by Audacity
  32. Importing Audio - Audacity Manual
User Avatar
No comments yet.