NIFF is a file format designed to allow the interchange of music notation data between and among music notation editing and publishing programs and music scanning programs. Its design is a result of combined input from many commercial music software developers, music publishers, and experienced music software users.
The lack of an accepted standard format for music notation has for years been a source of great frustration for computer musicians, engravers and publishers. Numerous attempts have been made in the past to create a standard format. The effort resulting in NIFF is different for several reasons:
Music notation is a complex language. Like a natural language, it is always changing, it is at times ambiguous and/or redundant, and can be used in many different ways by different people for different purposes. Because of these qualities, it is impossible to create a perfect computer model for music notation.
The original sponsors of the NIFF project recognized these limitations, and set a more reasonable goal: to create a practical, useable format in a short time frame. NIFF project participants have agreed that a solid, workable solution, even if it excludes some unusual situations, is preferable to no solution.
The NIFF planners considered adopting as the standard an existing published format such as DARMS or Score, but decided against it. The designers of DARMS had somewhat different goals from NIFF's. Score, although extremely comprehensive and appropriate in scope, was somewhat unwieldy due to its age and development history. Another possibility considered was the ISO/ANSI standard HyTime and its associated music standard known as SMDL, but SMDL was not yet complete at the time the NIFF project got underway. [As of the date of publication of this specification, a European Community music library project currently underway will result in a bridge between SMDL and NIFF.]
A general strategy was chosen as follows: model NIFF's feature set on Score's, organize the data as systematically as possible, and use the most current file format conventions. During the development of the format, additional more specific goals have been established. Some useful functional features of DARMS have been incorporated as well.
The NIFF structure can accommodate full music publishing systems, simpler music display systems, logical definition languages like DARMS, and music scanning programs. Even sequencers can be writers of NIFF files, since the most rudimentary NIFF file has little more notation information than a MIDI file.
NIFF allows representation of the most common situations occurring in conventional music notation, while making provision for software developers to define their own extensions to handle the more unusual situations. It allows inclusion of Encapsulated PostScript (EPS) files and fonts to allow interchange of features not otherwise defined in the format.
Extensibility is an important goal. Even the complete NIFF specification cannot be an exhaustive catalog of music notation features. A high priority has thus been given to structuring the data in ways that minimize the pain of future enhancements.
NIFF is also designed be flexible, to accommodate the differences between the programs and users it will serve.
An effort has been made to keep files as compact as possible, since NIFF files will likely be transmitted electronically over low-bandwidth lines.
Researchers Severo Ornstein and John Maxwell found that the computer representation of music notation has three distinct components only partially related to each other: logical, graphical, and performance (MIDI) information[5]. NIFF designers have found it useful to further subdivide the graphical information into page layout and non-page layout information.
The only information that NIFF absolutely requires is the logical kind. NIFF is structured as a page-ordered format, but can accomodate writing programs without access to page layout information and systems like DARMS, which allows even non-page-layout graphical information such as stem direction to be absent.
When complete graphical information is present in a NIFF file, the reading program can decide between 1) observing the page layout and other positioning information, 2) ignoring graphical information in favor of its own defaults, or 3) some intelligent combination. When any graphical information is absent from a NIFF file, the reading program is expected to provide its own intelligent defaults.
It is recommended that the user of the NIFF writing and reading programs be given as much control as possible. The user should decide the level of detail stored in the file by the writing program, and the degree of freedom used in interpretation by the reading program.
NIFF allows thorough linking of MIDI data and notation.
There is no such thing as an "illegal notation element" in NIFF. That is, there is no requirement for the data in a NIFF file to "make sense." A reading program should expect occasionally to find data that is not compatible with its own range of acceptable usage. When an unknown or unacceptable element is encountered, the program should either ignore it or do the best it can with it, in order to create a valid file in its own internal format.
The NIFF format follows the design rules of the Resource Interchange File Format (RIFF) structure from Microsoft. In RIFF files, related data items are grouped into "chunks", and related chunks can be combined into "lists." Chunks and lists include their own length within their structure. RIFF files are designed to be upwardly compatible, that is, amenable to future enhancements.
A RIFF file and each of its lists and chunks can be variable in length. A logical definition is required for each RIFF format, to identify which elements are required or optional at each level and the order in which the elements may appear
In NIFF, an additional type of data item known as a "tag" has been defined as an integral part of the format. Tags are used for adding optional elements to the required part of a chunk. Although not part of the standard RIFF design, tags can be described within RIFF's logical definition language.
RIFF is a binary format, but it is possible to describe a complete RIFF file with an ASCII representation. A structured notation system for representing RIFF files in ASCII is presented in the Microsoft Windows Multimedia Programmer's Reference[4].
More details on the format of chunks, lists and tags is presented later in Chapter 1. Detailed rules on reading and writing RIFF files are published in the RIFF documentation[4].
The same NIFF format definition can be used by software running on any type of machine. RIFF rules allow for separate formats for Intel (IBM compatible) and Motorola (Macintosh) machines, with different integer byte orders for the two machines. However, to make file translations across platforms easier for users, only the Motorola format will be used for NIFF, regardless of the machine used. The byte order is always from most significant to least significant, for both 16-bit and 32-bit integers, on all machines.
The first 4 bytes of a RIFF file indicate the byte ordering. 'R' 'I' 'F' 'X' means Motorola byte ordering, so all NIFF files will begin with these four characters. NIFF programs might therefore be required to translate integers from and to the correct byte order for their machine before reading and writing NIFF files.
NIFF is highly structured at its highest levels according to the rules of RIFF. However, writing programs have extremely wide latitude in their choice of what to include in any particular file, and how exactly to organize the data. A minimal NIFF file has little more information than a MIDI file. On the other end of the spectrum, an immense amount of detail can be recorded about the graphical arrangement of complex orchestral scores with custom shapes.
NIFF software developers will need to be creative when facing this range of possibilities. As with the TIFF (Tagged Image File Format) format, there will probably not be any two programs that make use of NIFF in exactly the same way.