The people at the first meeting included Lowell Levinger, Steve Keller and Mike Ost of Passport Designs, publisher of Encore; Leland Smith of San Andreas Press, publisher of Score; Randy Stokes of Coda Music Technology, publisher of Finale; Chris Newell and Wladek Homenda of Musitek, publisher of MidiScan; Nick Carter, author of SightReader, an unpublished music scanning program licensed to Coda, and myself, author of NoteScan, which is licensed to and published by TAP Music Systems/MusicWare.
Passport and Coda agreed to provide funding, Musitek to supply a PC for the project and San Andreas Press a copy of Score for reference. We agreed that I would research and develop the format as Technical Coordinator, and Chris Newell of Musitek would provide support as Administrative Coordinator. A contract was signed to this effect in June of 1994.
I got approval from the original participants to widen the scope of the project by asking for input from other individuals experienced in music notation software. The list of advisors has continued to grow over time, so that by now contributions to the design of the format have been made by many people representing a broad spectrum of interests including music software companies, music publishers, composers, engravers, and researchers in computer science and musicology.
In January of 1995 Coda decided to withdraw from the process. Shortly thereafter, Mark of the Unicorn, Twelve Tone Systems, Opcode Systems, and TAP Music Systems/MusicWare agreed to replace Coda as financial sponsors. I'd like to thank Dave Kusek of Passport Designs, Robert Nathaniel of Mark of the Unicorn, Greg Henderschott of Twelve Tone systems, Chris Halaby of Opcode Systems, and Roger McRae of TAP Music Systems/MusicWare for their financial contributions.
Alan Belkin, Professor of Music at the University of Montreal, has provided extremely useful technical and musical advice throughout the project; he is known as Special Advisor to the project. Dave Abrahams of Mark of the Unicorn has given very generously of his time and has made many essential contibutions to the format's design. Other major contributors have included all of the individuals at the original project launch meeting, and Norman Reid (whose experience with DARMS has proven invaluable), Mark Walsen (especially helpful on symbol relationships), Severo Ornstein, Don Byrd, Phil Sours of Twelve Tone Systems, Tom Hall of A-R Editions (who provided me with a DARMS manual), Eleanor Selfridge Field of the Center for Computer Assisted Research in the Humanities (CCARH), Don Williams and Dave Scoggin of Opcode Systems, Raymond Bily of Midisoft, Bill Holab of G. Schirmer (who provided some complex published scores which have been useful as a reference), Daniel Dorff of Theodore Presser, John Cerullo and Tom Johns of Hal Leonard Corporation, John Forbes of Boosey & Hawkes, Robert Schuneman of E.C. Schirmer, Bill McCann of Dancing Dots Braille Music Technology, and Steven Newcomb of Techno-Teacher (who has cooperated in planning a linkage between NIFF and SMDL, the upcoming ANSI standard music description language). A number of other individuals also contributed useful ideas.
Richard Karpen of the University of Washington Center for Advanced Research Technology in the Arts and Humanities (CARTAH) has provided an Internet ftp site to make the specification, technical discussions and test files available electronically. Thanks are due to Mike Brockman of TAP Music Systems/MusicWare for putting me in touch with him.
In addition to the sources listed in the Bibliography, I relied heavily on the reference manuals for San Andreas Press' Score, Mark of the Unicorn's Mosaic, TAP Music Systems' Nightingale and Coda's Finale, while designing NIFF's features. In particular, the Chord Symbols chunk was taken almost directly from Mosaic, and the Guitar Grid and Harp Pedal Symbols almost directly from Score.
I would also like to give special thanks to Chris Newell, who has been an amiable and useful colleague on this project.
Cindy Grande, Grande Software, Inc.
NIFF Technical Coordinator
August 31, 1995
I would like to thank Lippold Haken of Cerl Sound Group, co-author of the Lime Music Notation Software, for the method of shoehorning Unicode into NIFF and for other valuable technical advice, not to mention a fine implementation of NIFF to which I have often referred.
Thanks also to Stephen Braich who originally got the ball rolling when he brought up the need for International language support in NIFF (specifically for getting Niffty to handle Serbian lyrics).
And finally, thanks to Graham Jones, author of the SharpEye Music Reader for many insightful comments and examples and to David Cottle of Cerl Sound Group for participation in the NIFF email group.
Jeff Thompson
NIFF 6b Editor
September 25, 2001
1) Many of the major forces in the commercial music software industry - and several of the largest music publishers - have shown a remarkable willingness to cooperate in the design of NIFF.
2) Commercial music scanning programs are a recent addition to the software market. They require a common language with notation programs to avoid the enormous loss of detail that occurs when translating through MIDI files.
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 first date of publication of this specification, a European Community music library project 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.
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.
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.
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 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 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.
2. Ross, Ted, "The Art of Music Engraving and Processing," Miami Beach: Hansen Books, 1970.
3. Byrd, Donald, "Music Notation by Computer" , PhD dissertation , Indiana University, 1984. Available from UMI, 300 N. Zeeb Road, Ann Arbor, MI 48106. Telephone 1-800-521-3042. Order number DA8506091.
4. Microsoft Press, "Microsoft Windows Multimedia Programmer's Reference," Redmond, WA, 1991. Telephone: 1-800-MSPRESS, ISBN#1-55615-389-9. Contains the full description of Microsoft's RIFF standard.
5. Ornstein, Severo M. and Maxwell, John Turner Maxwell III, "Mockingbird: A Composer's Amanuensis," Xerox Palo Alto Research Center, 3333 Coyote Hill Road, Palo Alto, CA, 94304. CSL-83-2. January, 1983. [P83-00002].
6. Apel, Willi and Daniel, Ralph, "The Harvard Brief Dictionary of Music", New York: Amsco Music Publishing Company, 1960.
7. Heussenstamm, George, "The Norton Manual of Music Notation," New York: The Norton Company.
8. Roemer, Clinton, "The Art of Music Copying", Sherman Oaks, CA: Roerick Music Co, 1985. (out of print)
9. Vinci, Albert C., "Fundamentals of Traditional Music Notation," Kent State University Press, 1989.
10. G. Schirmer, Inc. "The G. Schirmer Manual of Style and Usage," New York: The G. Schirmer Publications Department, 1990.
11. Yergeau, Francois, "UTF-8, a transformation format of ISO 10646," RFC 2279, Internet Engineering Task Force, January 1998.
Examples.
The NIFF logical structures were designed to handle situations like the following:
Example 1. In a Mahler symphony score there are three trumpet parts. In one system the trumpets appear on three separate staves (labelled "Tpt. 1", "Tpt. 2", Tpt. 3"), because they are playing a complex canon. In another system they appear all together on one staff, called "Tpts. 1,2,3," because they are playing homophonic music. They are written as chords, with 3 notes on one stem.
In the logical view, the notes played by the trumpets belong to three separate parts.
In the physical view of the canonic system, each trumpet part is assigned its own staff. Each staff is labelled with its own name.
In the physical view of the homophonic system, the three parts are combined together onto a single staff, labelled "Tpts. 1, 2, 3." The simultaneous notes of each chord played by the three trumpet parts appear together with a single stem within each time-slice. Each note indicates the part to which it belongs.
Example 2. Consider a score with divisi writing where the first violin part is temporarily divided into groups. The first violin part is split onto two separate staves in one system, and three separate staves in another system. There are a variety of ways this could be represented in NIFF. The choice depends on the desired result when the parts are to be extracted and printed for individual players:
a) If the first violin part score is to show all the divisi parts, the first violin should be defined as a single part with three voices and a maximum number of staves of three. The notes of this part would be distributed among the one, two or three active voices, each voice presented on its own staff.
b) If separate part scores are to be printed for different first violin players, more than one first violin part should be defined in the NIFF file. All the musical symbols that are to be printed on a particular part score would have that part number indicated. If the same passage is to be printed on two different part scores, both part numbers should be indicated for each symbol within the passage.
A Staff list may contain music symbols belonging to more than one part. When more than one part is present on the staff, the part must be uniquely identified for every symbol. When only one part is present in a particular Staff list, its Part ID is identified in the Staff Header chunk instead of on the individual symbols.
The simulated part ordering structure is designed to accommodate non-page-oriented programs and programs which offer the user the option to strip page layout data when writing NIFF files. The music symbols of a one-staff part would all be stored contiguously in a single Staff list. Multiple-staff parts such as piano or organ would be split apart into two or more Staff lists.
Another special type of file structure is "spacing by part." In this scheme used by some notation programs, the symbols of each part are assigned horizontal placement values independently of the other parts, as though the file contained a set of part scores instead of one ensemble score. This could be used in a file with page ordering or simulated part ordering. A file recorded with this scheme is identified by the presence of the Spacing By Part tag on the NIFF Information chunk in the Setup Section. Reading programs unable to make use of this spacing should ignore all horizontal placement values, using its own spacing defaults instead.
1) to allow enough flexibility to accommodate page-oriented notation programs, non-page-oriented notation programs and scanning programs,
2) to allow a fine enough resolution to describe high-quality printed music,
3) to use integers rather than floating point numbers, for the purpose of avoiding rounding errors and incompatibility among platforms, and
4) to describe each size and position measurement in a way that is semantically useful.
In addition, an attempt has been made to limit rounding errors during translation between the reading and writing programs' measurement units. For this reason, each writing program has its choice of units for absolute measurements.
Absolute units are the writing program's own choice of units, declared in the Setup Section NIFF Information chunk. The unit choice is expressed in two field values: the standard unit (inches, centimeters, or points), and the number of absolute units per standard unit. For example, if the resolution used by the writing program were 4000 dots per inch, the writing program would choose a standard unit of "inches" and the number of absolute units per standard unit would be 4000.
The placement of a symbol whose meaning depends on its vertical position on a staff line or space is given as a staff step. The origin of the staff step system is the bottom line, which is given the value zero. Step numbers increase by one for each successive line or space in an upward direction from the origin. Negative numbers are used for the spaces and ledger lines below the origin.
Measurements and symbol placement are discussed in detail in the Symbol Relationships section below.
The origin of a staff is the left end of its top line. The origin of a system is the staff origin of its top staff.
The size of music fonts is described in two different ways: font size (in twips) and space height (in absolute units). Since there is no agreement on the meaning of font size between different music fonts, the space height is intended to provide a clue about the intended size of the symbols on a standardized scale. It is equal to the vertical distance in absolute units between two adjacent staff lines of a staff on which the music font symbols would appear of normal size.
Two kinds of playback are: 1) logically precise playback derived from the notation, and 2) nuanced rubato of a recorded performance.
For each playback event, there are two pieces of information to be described: 1) start time, when the event is to occur, and 2) duration, how long it lasts.
More interestingly, the duration of each note in a tuplet sometimes can be precisely represented only by a fraction, such as half note triplets, where each note's duration can be accurately represented as 1/3. When three half notes occur in the time normally allotted for 2, each note takes up 2/3 the time of a normal half note (1/3 = 2/3 * 1/2). Similarly, when 3 quarter notes are stretched out to the time of 4 (notated as 3:4 over a bracket, in tuplet notation), this duration can also be represented as 1/3: each note takes up 4/3 of the time of a normal quarter note (1/3 = 4/3 * 1/4).
A fraction consisting of two integers (a numerator and a denominator) is therefore a natural way to describe durations.
The tuplet transformation ratio is in the form of 4 integers: a, b, c, and d, where a b-type notes occur in the time of c d-type notes. In conventional usage of tuplets, b and d will be the same, but many musicians use tuplets in an "unconventional" way, and may choose to represent a tuplet as, for example, three half notes in the time of four quarter notes (a, b, c, d = 3, 2, 4, 4).
For example, in the case of half note triplets the transformation ratio in the tuplet chunk is 3:2. When applied to the half note duration on the note chunk (1/2), this would result in an effective duration of 1/3 (1/3= 2/3 * 1/2). The effective duration need not be stored in the file, since it can be calculated by the reading program from values in the note and tuplet chunks.
A tuplet is normally a multi-node symbol, represented by a series of Tuplet node chunks, each one associated with one Stem chunk. All notes on a tupletized stem must contain the same duration. See Chapter 2 for information about multi-node symbols.
Nested tuplets are represented by an additional tuplet associated with a subset of notes already included in a tuplet. The transformation ratios are applied cumulatively to each affected note.
More than one voice or part can be included in a tuplet. For example, when all horns shown on the same staff are playing in rhythmic unison, a whole collection of chords may be tupletized. However, within each voice (or part, if there is one voice per part), the sum of the durations of the notes must equal a b-type notes.
The start time of a note or rest is stored on the event Time-slice chunk associated with (most recently preceding) the note or rest symbol. The start time is represented by a fraction which is the sum of the durations of all events that have occurred within the voice since the previous measure-start time-slice.
Here is an example, showing the start times and durations for 4 quarter notes in the first measure of a score in 4/4 time.
Time-slice, type=event, start-time=0/4 Stem Notehead, duration=1/4 Time-slice, type=event, start-time=1/4 Stem Notehead, duration=1/4 Time-slice, type=event, start-time=2/4 Stem Notehead, duration=1/4 Time-slice, type=event, start-time=3/4 Stem Notehead, duration=1/4The start time of a measure is stored on a measure-start Time-slice chunk. It is given as the cumulative duration of all events since the start of the piece. The effective start time of each event in a measure is therefore the sum of the measure start time (from the measure-start Time-slice chunk) and the event start time (from the event Time-slice chunk). In the example above, the start time on the measure-start Time-slices of the first and second measures, respectively, would be 0/4 and 4/4.
The reference back to the start of the piece permits the correspondence between events in different parts to be determined even when the parts are in different meters.
Note concerning pickup bars: NIFF has no standard "correct" way to represent such (incomplete preliminary) bars. In particular, scanning programs may not have the intelligence to distinguish a genuinely incomplete bar from a pickup measure. Therefore the writing program has the choice of representing the pickup either as simply a "normal" incomplete bar, or else of representing it "correctly" (in musical terms) as the final portion of a preceding bar. As long as the barline time slice and the following measure time slice contain the same time, it should make little difference on which beats the two pickups are placed. Implementations should be prepared to deal with either of these possible representations of time in a pickup measure.
Logical gaps can be filled in with invisible rests and placeholding measure-start time-slices. Or, logical gaps can be handled by adding extra value to the start time of the event following the gap to compensate for the missing time. Either technique ensures that the event following a logical gap in one voice will not occur until its proper time among the events in all other voices and parts.
The performance start time and duration are given as offsets (+/-) from the logical start time and duration of the event.
Lengthy or complex MIDI information that cannot be represented with the simple MIDI Performance tag can be supplied with the MIDI Data Stream chunk (see below under MIDI Integration).
The performance playback values may be affected by other chunks and tags associated with the Notehead or Stem chunks, however. For example, an Accidental chunk will affect the pitch, an Articulation chunk or Silent tag might affect the performance duration, and a Grace Note tag would likely affect the start time.
An event's start time and duration are always present (each composed of a numerator and denominator component); the performance start time and duration are optional values that can be supplied on the MIDI Performance tag. If not present, it is assumed that the performance values are equivalent to the logical values.
NIFF does not require logical adherence to time signatures.
Chunks representing changes in clef, key signature and time-signature, when present at a measure boundary, should be stored in the same way, following the Barline chunk. Horizontal placement can be supplied to identify the individual placement of each symbol within this special time-slice, though most reading programs would have spacing algorithms to handle them adequately without it. When changes in clef, key signature or time signature occur in the middle of a measure, they should be stored with the time-slice which represents the following event. The horizontal placement of a symbol chunk in this situation, if specified, should have a negative value.
Chunks representing the clefs, key signatures and time signatures that appear at the start of the staff do not need to be preceded by an event-time-slice. They are stored immediately after the new measure-start time-slice. In the case where the new system starts in the middle of a measure, these chunks should be stored with the time-slice which represents the following event. The horizontal placement of a symbol chunk in this situation, if specified, should have a negative value.
For small notes that break the meter but whose time is not subtracted from that of the preceding or following normal note, do not use the Grace Note tag.
The performance start time (in the note's MIDI Performance tag) is given as an offset in MIDI ticks from the grace note's logical start time. Other tags that might be found on a grace note's Notehead or Stem chunk include the Slash tag, Small Size tag, and the Absolute Placement tag (with a negative value) indicating a negative horizontal offset from the time-slice.
In the following example, the grace note's time value is subtracted from the preceding note during performance, as in Chopin or Liszt. However, the duration field on the preceding Notehead chunk is not modified to compensate for the grace note. The start time on the Grace Note tag gives a negative offset of 1/32 from its time slice, which can be used by the reading program during playback.
Time-slice, type=event,start-time=0/4 Stem Notehead, shape=filled, staff step=0, duration=1/4 Time-slice, type=event, start-time=1/4 Stem, Number of Flags=1, Slashed Stem, Small Size, Grace Note=-1/32 Notehead, shape=filled, staff step=2, duration=1/32 Stem Notehead, shape=filled, staff step=1, duration=1/4
typedef unsigned long DWORD; typedef unsigned char BYTE; typedef DWORD FOURCC; /* Four-character code */ typedef struct { FOURCC chunkID; DWORD chunkSize; /* the size of field <chunkData> */ BYTE chunkData[chunkSize]; /* the actual data of the chunk */ } chunk;A list is a type of chunk which can contain nested chunks, or subchunks. Its four character code is "LIST". The type of list it is is supplied in a four character code following the size field, which is followed by a series of chunks or other lists.
typedef struct { FOURCC chunkID; /* always "LIST" */ DWORD chunkSize; /* the size of field <listData> + 4 */ FOURCC listID; /* the type of list it is */ BYTE listData[chunkSize-4]; /* zero or more chunks and lists */ } list;A form is a special type of chunk which always appears first in a RIFF file, and contains all the other chunks and lists in the file. Its four character code is "RIFF", or in the case of the Motorola format which NIFF always uses, "RIFX". The form type, which is always "NIFF" for NIFF files, is supplied in a four character code following its length field. This is followed by a series of lists and chunks:
typedef struct { FOURCC chunkID; /* always "RIFX" */ DWORD chunkSize; /* the size of field <formData> + 4 */ FOURCC formID; /* always "NIFF" */ BYTE formData[chunkSize-4]; /* zero or more chunks and lists */ } form;The presence of the chunkSize allows programs to ignore the rest of a chunk, list or form which is not recognized. The chunkData, listData and formData fields always have an even number of bytes. A pad byte with value zero is added to the end, if necessary for the data to end on a word boundary. The value of chunkSize does not include the pad byte.
A tag is a self-contained set of variable-length information composed of a one byte code indicating what type of tag it is, followed by a one byte length field, followed by the tag's data.
Defined in the C programming language, a tag looks like this:
typedef { BYTE tagID; BYTE tagSize; /* the size of field <tagData> */ BYTE tagData[tagSize]; /* the actual data of the tag */ } tag;The presence of the tags' size allows programs to ignore the rest of a tag which is not recognized. The tagData field always has an even number of bytes. A pad byte with value zero is added to the end, if necessary for the data to end on a word boundary. The value of tagSize does not include the pad byte.
The tagData field must conform to the documented tag definition as shown in Chapter 3, unless it is a user-defined tag, discussed below.
Any number of tags may be appended to the required part of a chunk. NIFF-defined options, user-defined options, and future extensions can all be represented in the form of tags.
Any defined tag may be added to any chunk type; however, some combinations might be meaningless. When used on an anchor symbol chunk (see Chapter 2, Symbol Relationships), a tag applies to all symbol chunks dependent on the anchor, where meaningful. When used on a Stem chunk, a tag applies to all associated Notehead chunks.
Typedefs can be found in the NIFF.h C header file (Appendix A) for the following data types. Additional types used in the chunk and tag definitions are STRUCT, which refers to a set of data elements in a documented structure format, and char[x], an x byte character value.
Type Description
Also, NIFF does not specify the character set in the RIFF ZSTR for character values in the "extended ASCII" range of 128 to 255. These may be used between programs that agree on their meaning, and many NIFF implementations use the ISO-8859-1 (Latin-1) encoding.
Some people refer to Unicode as a 16-bit character set, but this is a misconception because there are over 65,536 Unicode characters, and more to come. Rather, there are schemes for taking the (possibly large) Unicode character values and encoding them into a byte stream. NIFF uses the UTF-8 encoding which encodes each Unicode character as a sequence of one or more 8-bit bytes. UTF-8 means "Universal Transformation Format 8-bit" and is designed so that certain values of an 8-bit byte indicate that more bytes follow which are part of the same Unicode character. Many computer languages and operating systems provide utilities for encoding and decoding Unicode using UTF-8. For more details, see RFC2279 (available at http://www.ietf.org/rfc/rfc2279.txt) or unicode.org's UTF web page at http://www.unicode.org/unicode/faq/utf_bom.html .
To provide a Unicode version of a string, place a byte of value 1 following the terminating null of the RIFF ZSTR. (A 1 is not a printable ASCII character, so it cannot be the beginning of another RIFF ZSTR.) After the 1, place the UTF-8 encoding of the Unicode string, followed by a terminating null. (Note that a UTF-8 encoding itself never contains a zero byte.) A NIFF reading application can inspect the byte following the RIFF ZSTR null terminator. If it is a 1, then a UTF-8 encoding follows. (However, an application should be careful that it is not inspecting a byte past the end of the entire String Table chunk.)
A Unicode string only contains values for the different characters. It does not contain information on the fonts that will display the characters. Many programming libraries provide utilities that map Unicode characters onto the fonts that the operating system uses to display them. Note that the FONTIDX type only refers to fonts used for the ASCII string in the RIFF ZSTR. NIFF does not currently provide for specifying fonts for Unicode strings.
If possible, an application should supply an ASCII version of a string (in the RIFF ZSTR) as well as the Unicode version. This is so that if an application reading the NIFF data can display the simpler ASCII version if it cannot display the Unicode characters. However, if there is no ASCII representation, then the RIFF ZSTR may be empty. In this case, the STROFFSET points to the null terminator of the RIFF ZSTR, followed by a byte of value 1, followed by the UTF-8 encoding of the Unicode string, followed by the null terminator.
When the string can be fully represented in ASCII, such as English text or strings of numbers, the application should not include a Unicode representation, since it would be redundant.
User-defined chunks are identified by the four character code "user". The two byte NIFF User ID is stored in the first two bytes of the chunkData field. User-defined tags are identified by a tag ID of 255 (x'FF'). The NIFF User ID is stored in the first two bytes of the tagData field. The user defines the structure and value of the remainder of the data portion of the chunk tag. The presence of the size field allows reading programs to ignore unrecognized user-defined chunks and tags.
The Chunk Length Table in the Setup Section must include an entry for each user-defined chunk type as well as for each standard NIFF chunk type used in the file.
NIFF users should clearly document the structure and function of each user-defined chunk and tag. The details of administering a documentation library have yet to be determined.
The NIFF Information chunk. This includes the following information: NIFF version, writing program type, measurement units and MIDI ticks per quarter. Of these fields, all but the NIFF version can have a value of -1 to indicate "no value".
The Chunk Length Table. The purpose of this is to allow for future changes in the fixed length part of the chunk structures, without disturbing existing programs. It is a series of 8 byte table entries, each one composed of a 4 byte chunk name followed by a 4 byte pointer to the first tag field to be found in chunks of that type. The pointer value is always the same as the length of the chunk's required structure. If the required structure for the chunk type is the EMPTY data type, the pointer value is zero. If no tags are allowed in that chunk, the pointer value is -1. There must be a table entry for each chunk type present in the file, including user-defined chunks. Table entries appear in alphabetical order.
The Parts list. This list is composed of a series of Part Description chunks, each of which defines the Part ID, part name and part abbreviation, maximum number of staves in that part, MIDI channel and cable numbers, and the number of steps to transpose this part on playback. All fields except Part ID can be set to null values. Part ID's should be assigned sequentially starting with zero. The vertical offset of such optional items as lyrics, guitar grid symbols, and figured bass can optionally be specified by appending tags to the Part Description chunk.
The maximum number of staves field in each Part Description must have a nonzero value. This information is used in interpreting staff number values in the Setup Section Staff Groupings list.
The String Table is a chunk containing all strings referred to elsewhere in the file. It is a series of null terminated ASCII strings (known in RIFF terminology as ZSTRs). In any NIFF chunk where a string value is needed, the data type STROFFSET is used. This contains the offset of the string in the String Table.
The Staff Groupings list is a series of Staff Grouping chunks, each of which describes some type of grouping symbol at the left end of a series of sequential staves in the score, such as an initial vertical line, a brace or a bracket. A default Staff Groupings list can optionally be supplied in the Setup Section. In the Data Section, Staff Groupings lists can be supplied in some System lists as overrides to the default Staff Grouping. Alternatively, the Setup Section Staff Grouping list can be eliminated entirely, with Staff Groupings supplied only in Data Section System lists. Storing a default Staff Groupings list in the Setup Section makes the most sense when there is little variety among the score's staff groupings.
The Defaults chunk specifies default fonts for various text categories, vertical offsets of chord symbols, guitar grids, and rehearsal marks, and a default tuplet appearance description.
The Font Descriptions list is an optional table in the Setup Section that is composed of a series of Font Description chunks, each of which defines a particular combination of font name, font size, and font style. Font Description chunks in the Font Descriptions list are referred to elsewhere in the file by means of the FONTIDX data type.
The FONTIDX data type is used in the optional Default Values chunk in the Setup Section for specifying default fonts for music symbols, lyrics, figured bass and chord symbols. FONTIDX is also used in the Font ID tag, which is applied to any music symbol or text-type chunk to specify that the same character(s) but a different font, size or style is to be used. Finally, FONTIDX is used in the Custom Font Character tag, which allows a non-default font and character to be used on a music symbol chunk.
Each Font Description chunk gives the font name, size (in both twips and absolute units), style (plain, bold, italic, underscored, or a combination), and the location where the font itself can be found, if it is stored in the file. The location is given as a pointer to the PostScript font in the Custom Graphics list, a separate Setup Section structure.
The Custom Graphics list is an optional table in the Setup Section that is used to store fonts and custom graphics. Fonts are stored as PostScript Type 1 or Type 3 font, and graphics are stored in EPS (encapsulated PostScript) format. EPS graphics in the Custom Graphics list table are referred to by means of the Custom Graphic Symbol chunk, which represents a symbol with no musical function, or the Custom Graphic tag, which is applied to a music symbol chunk to override the default appearance of the symbol.
The NIFF Font Symbol chunk is a font-independent method of indicating the appearance of a music symbol without its musical function. An alternative to the Custom Graphic Symbol chunk, it can be used to indicate that an ornament or clef sign, for example, is to appear in a particular place on a page such as a footnote, without specifying any particular font. The generic "NIFF Font" is composed of the four character code for the music symbol chunk normally used to display the symbol, and the shape, if any, for the desired symbol in that chunk's definition.
In the Setup Section, each part can globally be assigned a MIDI channel number and cable number in the Part Description chunk. The part can be given a new set of channel and cable numbers at any point during the score by applying the Part Description Override tag. This might be used to switch to a new instrument sound, such as in a part for oboe and English horn.
In the Data Section, the MIDI Data Stream chunk and MIDI Performance tag are used. There are four possible relationships between the notation symbols and MIDI data:
1) One to one correlation - notes. In the case of the pairing of a Notehead chunk and a Note On message, the MIDI Performance tag is appended to the Notehead chunk. The MIDI Performance tag includes the pitch and velocity of a MIDI Note On message, plus the performance start time and duration in MIDI ticks. The start time is given as an offset from the current time-slice.
2) One symbol, one or more MIDI messages. For example, a dynamic associated with a control change message, a hairpin associated with a controller 7 sweep or a turn or a trill symbol associated with a series of Note On and Note Off messages. This is represented by a MIDI Data Stream chunk anchored to a music symbol chunk. The MIDI Data Stream chunk indicates the start time of the beginning of the stream, in MIDI ticks, as an offset from the current time-slice. It includes any number of MIDI events, stored as in a MIDI file, starting at time zero.
3) Many to many correlation, where the number of symbol chunks is different from the number of MIDI messages. For example, a pitch bend might be associated with portamento notation composed of two Notehead chunks and the diagonal line Portamento chunk between them. In this case, the MIDI Data Stream is made into a multi-node symbol, with each node corresponding to one of the notation symbols. Only the first node contains the actual series of MIDI Pitch Bend Change messages.
4) No correlation. Either the notation has no clear MIDI meaning (for example a text string like "espressivo"), or the MIDI data has no standard notational equivalent (like panning information). The latter case is represented by a MIDI Data Stream chunk anchored to a Time-Slice. It may or may not be associated with a particular part.
The standard Clef chunk is used, with its value indicating TAB. Guitar TAB Number chunks are used to place the numbers on the string lines, and standard Barline chunks are used for barlines.The tablature symbols are stored with time-slice chunks that correspond to those of the music symbols displayed on the standard notated staff above.
In more complex cases, the writing program can use more precision in describing the function and placement of text to appear to the left of the system. An individual label can be specified for either a staff or a staff grouping. For instance, it is possible to give the label "Horns" to a brace connecting a pair of horn staves, one labeled "1-3" and the other "4-6." To create a label for a staff or staff grouping, the writing program should use the Staff Name tag on Text chunks stored in the appropriate context. The placement tag and Font ID tag may also be used.
For a staff name, a Text chunk with the Staff Name tag should be stored following a Staff Header chunk. Its placement, if specified, would be given relative to the staff's origin. For a grouping name, a Text chunk with the Staff Name tag should be stored following a Staff Grouping chunk in a Staff Groupings list (in either the Setup Section or the Data Section). Its placement, if specified, would then be given relative to the staff origin of the top staff of the grouping.
The value of the ossia tag indicates whether the ossia or the non-ossia alternative is to sound during playback. (The choice may be given to the user, or may depend on the capabilities of the notation software.)
Additional tags which might be added to the Staff Header for an ossia are the placement tags and the Width tag, indicating a shorted staff that starts partway into the measure..
For precise placement of individual numbers, or to use letters instead of numbers, use the Rehearsal Mark chunk instead.
Alternate endings introduce an apparent timing inconsistency: the start times in the measures of later endings duplicate the start times of measures in the first ending. To allow the reading program to make sense of this inconsistency, each measure-start Time-slice chunk of each ending is to have an Alternate Ending tag attached. When calculating the start time of the time-slice following a series of alternate endings, only the longest of the alternate endings should be considered.
There would normally also be an Alternate Ending Graphic chunk which indicates the appearance of the alternate ending, at least on the topmost staff. But it is the Alternate Ending tag which definitively resolves the timing conflict.
A tag on a Tag Activate chunk remains in effect until a Tag Inactivate chunk appears with the same tag, or the end of the current Staff list is found, whichever occurs first. Tag Activate chunks can also be nested.
The Tag Activate chunk is useful for saving space, but another purpose is to allow for additive applications of a particular tag - such as when a very small grace note is present within a cadenza-like passage of small notes. This example is shown below:
Time-Slice, type=event Stem a) Notehead Tag Activate, Small Size Time-Slice, type=event Stem Notehead Time-Slice, type=event Stem, Grace Note, Small Size b) Notehead Stem c) Notehead Time-Slice, type=event Stem Notehead Tag Inactivate, Small Size Time-Slice, type=event Stem d) NoteheadNotehead (a) before the Tag Activate chunk and Notehead (d) after the Tag Inactivate chunk are normal sized. Notehead (c) is a small note, affected by the Small Size tag on the Tag Activate chunk. Notehead (b) is a very small note, affected cumulatively by the Small Size tag on its Stem and by the Small Size tag on the Tag Activate chunk.
The following example shows use of the Voice ID to restrict the mode to one voice only:
Tag Activate, Voice ID=2, Small Size Time-slice Stem, Voice ID = 1 a) Notehead Stem, Voice ID = 2 b) Notehead Tag Inactivate, Voice ID=2, Small SizeOnly Notehead (b) is affected by the Small Size tag on the Tag Activate chunk.
N.B. For some chunks within the Tag Activate scope, the tags would be meaningless and should be ignored by the reading program. An example is the Small Size tag as applied to a Time-Slice chunk.
The Anchor Override tag can be used on a dependent symbol chunk to indicate a non-default anchor type. For example, a Slur's default anchor type is a Stem, but an anchor override could be applied to a particular slur endpoint to anchor it to a Notehead or Fingering chunk instead. The Time-Slice is the default anchor for some symbols, and is a valid override anchor as well.
The dependent/anchor relationship between symbols plays a major role in both file syntax and symbol placement.
There are two rules defined for the syntactic order of dependent and anchor symbols:
1) The dependent symbol physically appears in the file as soon as possible after its anchor.
"As soon as possible" means that the only symbols that can be stored between a dependent symbol and its anchor are other symbols dependent on the same anchor, and nested symbols dependent on those.
2) When more than one symbol is dependent on the same anchor, the dependent symbols should be placed in the file in order of graphical proximity to the anchor, from nearest to farthest. For symbols that are the same distance from the anchor, or when distance doesn't matter, any order will do.
A detailed example demonstrating these rules is given below.
Noteheads and Stems bypass syntax rule 2. Notehead chunks always follow the Stem chunk in order from highest to lowest pitch.
Here are two examples in NIFF pseudo-code. In Example A1 there is a small sharp sign over a trill ornament anchored to one note of a chord; a fingering number is anchored to another note of the chord. In Example A2 parentheses surround the staccatos over three notes.
Example A1:
Stem Notehead, staff step=3, duration=1/4 Fingering, shape=1 Notehead, staff step=7, duration=1/4 Ornament, shape=short trill Accidental, shape=sharp, Small Size, Anchor Override=Ornament, Logical Placement=above [discussed later]Example A2:
Time-Slice, type=event,start time=0/4 Stem Notehead, staff step=5, duration=1/4 Articulation, shape=staccato Parenthesis, shape = "(", Anchor Override=Articulation,Logical Placement = left, ID=1, Number of Nodes=2 [multi-node, discussed below] Time-slice, type=event, start-time=1/4 Stem Notehead, staff step=5, duration=1/4 Articulation, shape=staccato Time-slice, type=event, start-time=2/4 Stem Note, staff step=5, duration=1/4 Articulation, shape=staccato Parenthesis, shape = ")", Anchor Override=Articulation,Logical Placement = right, ID=1
For example, the beam is decomposed into nodes, each one corresponding to a stem. Each node supplies information about the beam at that point, i.e. the number of beam parts to the left and to the right of that stem, including partial (fractional) beams.
Every node of a multi-node symbol must contain an ID tag. The same ID is used on all nodes of a multi-node symbol, so the nodes can be recognized as belonging to the same symbol. As a convention, ID numbers should be assigned sequentially within a chunk type starting with zero.
The first node of a multi-node symbol (the one appearing physically first in the file) has some special properties. Any information which applies to the symbol as a whole appears here, such as the Fanned Beam tag on Beams. Tags which are independently associated with each node, such as Bezier Incoming/Outgoing and the Anchor Override tag can appear on any node.
The first node also contains the Number of Nodes tag indicating how many nodes are present in the file for the multi-node symbol with this ID. This allows the reading program if desired to allocate the appropriate amount of storage when it finds the first beam node, and to release the storage when it has found and handled the last beam node. The Number of Nodes tag and ID tag together identify a symbol as multi-node. In the rare case of a one-node symbol of a type which is normally multi-node, such as a beam when it is anchored to only one stem, the one beam chunk need not contain the Number of Nodes or ID tags.
In a cross-staff beam which starts on a stem in the lower staff and ends on a stem in the upper staff of a piano grand staff, the first beam node to appear in the file may be the one corresponding to the rightmost stem in the beam structure (the last one in time-slice order), or perhaps even to a stem in the middle of the beam structure. The reading program may not be able to reconstruct the complete beam until the last beam node has been read.
Here is an example in NIFF pseudo-code, showing a cross-staff beam connecting three eighth notes in ascending order.
Example:
(Staff 1) Time-slice, type=event, start time=1/8 Stem Beam, ID=1, Number of Nodes=3,parts to left=1, parts to right=1 Notehead, staff step= 2, duration=1/8 Time-slice, type=event, start time=2/8 Stem Beam, ID=1, part to left=1, parts to right=0 Notehead, staff step=5, duration=1/8 (Staff 2) Time-slice, type=event, start-time=0/8 Stem Beam, ID=1,parts to left=0, parts to right=1 Notehead, staff step= 6, duration=1/8
Because the ID tag is unique within the chunk type for the entire score, the ID tag is sufficient to identify the related stem nodes in the different staves.
Here is an example:
Example:
(Staff 1) Time-slice. type=event, start-time=0/8 Rest, duration=1/8 Time-slice. type=event, start-time=1/8 Rest, duration=1/8 Time-slice. type=event, start-time=2/8 Stem, ID=1, Number of nodes=2 Notehead, staff step=2, duration=1/4 Notehead, staff step=-1, duration=1/4 (staff 2) Time-slice. type=event, start-time=0/8 Stem Notehead, staff step=6, duration=1/8 Time-slice. type=event, start-time=1/8 Stem Notehead, staff step=6, duration=1/8 Time-slice. type=event, start-time=2/8 Stem, ID=1 Notehead, staff step=7, duration=1/4
An example of the use of these tags is when a tie extends from the last note on one system to the first note in the following system. In this case the tie symbol will contain an extra pair of nodes, one at the end of the first system and one at the start of the next. All four nodes are assigned the same ID.
In the following example, the tie's Multi-node End Of System node is anchored to the Barline chunk at the end of the first system. The tie's Multi-node Start Of System node is anchored to the current time-slice, optionally with a negative horizontal placement.
See diagram 4. [the end of system barline was accidentally omitted from this diagram]
Example:
(System 1) Time-slice, type=event, start-time=3/4 Stem Notehead, staff step=5, duration=1/4 Tie, ID=1, Number of Nodes=4 Time-Slice,type=event, start-time=4/4 Barline Tie, ID=1, Anchor Override=Barline, Multi-node End Of System (System 2) Time-slice, type=measure-start, start-time=16/4 Clef, shape=F clef, staff step=6 Time-slice, type=event, start-time=0/4 Tie, ID=1, Anchor Override=Time-Slice, Multi-node Start Of System Stem Notehead, staff step=5, duration=1/4 Tie, ID=1
It is suggested that the writing program allow the user as much control as possible in the choice of the symbol placement technique or combination of techniques used in a particular NIFF file.
When non-default placement information is present for a symbol, it should not contradict the placement relationship implied by the file syntax, but should complement it.
Logical placement: This supplies the logical relationship between a dependent symbol and its anchor. It is implemented by the use of the Logical Placement tag, which indicates direction such as left, right, above, below or centered, and proximity such as touching or offset; and the Staff Step tag, which gives the position of the symbol's hot spot as a particular staff line or space.
Absolute placement: This gives the exact location of the symbol, as an offset in absolute measurement units relative to its anchor. This is useful when an exact reproduction of the original image is desirable. It is implemented by the use of the Absolute Placement tag, which supplies the exact horizontal and vertical offsets of symbols from one another.
The use of the three placement options will likely evolve during the trial implementation of NIFF.
When an absolute placement value is supplied for a dependent symbol, the meaning of its value is "the offset of the dependent symbol's reference point from the anchor symbol's reference point." Note that the NIFF reference point is not the same as the default placement. In other words, an absolute offset of (0,0) on a symbol does not mean "place the symbol exactly at its default horizontal and vertical position." Instead, it means "place the reference point of the symbol (often its center) exactly on top of the reference point of its anchor (often the anchor's center)."
The Reference Point Override tag can be used to temporarily change the reference point of either the anchor or the dependent symbol, or both. Descriptions of non-default reference points include codes such as "left of symbol's bounding box", "top of symbol's bounding box", or "vertical center of symbol's bounding box." When present, this tag is always specified on the dependent symbol for a particular dependent/anchor relationship.
Reference points on the anchor and dependent symbols are only to be considered when explicit placement information is supplied. Otherwise, the reading program should use its own defaults to determine the placement of a dependent symbol relative to its anchor.
The default reference point of a Notehead is its center. A horizontal offset of zero on a note chunk thus means it is horizontally centered over the time-slice. This would also be the default position, on an individual note or on a chord without seconds. When a chord contains a second, the notes on the "correct" side of the stem are by default to be centered over the time-slice. This allows for the correct alignment of simultaneous up-stem and down-stem chords which both contain seconds.
When both a normal size notehead and a small size notehead are both present on the same stem, it is the normal size notehead that is centered over the time-slice.
The time-slice is centered under the two notes to the left of the up-stem, and the two notes to the right of the down-stem.
A stem's default reference point is its end where the flag or beam would be attached, and its horizontal center. On a stem, a horizontal offset of zero would indicate that the stem is centered over the time-slice - obviously not the stem's default position. If a horizontal offset were supplied on a normal up-stem just touching the right side of an individual note (not required, since this would be the stem's default placement relative to the note), the stem's offset would be one half of the note width minus a half stem width. A larger stem offset would be used if the stem were to appear slightly separated from the note.
There are situations in music where the proportional placement of symbols is meaningful: for example, a crescendo hairpin ending somewhere between the start and end of a whole note. When the spacing of symbols is later adjusted, the hairpin should expand or shrink proportionally to its surroundings.
When the writing program has used either logical or default placement of symbols rather than absolute, the proportion cannot be described in graphical terms. An event time-slice could be used as an anchor for the hairpin end, to precisely indicate the implied temporal relationship between it and the whole note's start and end. The program should calculate for the anchor time-slice's start time a value with the proper proportion to the start and end times of the whole note. The reading program could then use the temporal proportion of the hairpin end relative to the start and end times of the whole note to calculate the symbols' proportional placement.
In mathematical terms:
P0 = position of previous timeslice T0 = time of previous timeslice P1 = position of next timeslice T1 = time of next timeslice P = position of hairpin end T = start time on anchor time-slice of hairpin end P = P0 + (T - T0) * (P1 - P0) / (T1 - T0).
Chunks - in alphabetical order
- Setup Section Chunks
- Data Section Chunks
- - Header Chunks
- - Symbol Chunks
Tags - in alphabetical order
When the meaning of a particular tag is not specified for a particular chunk, it is the responsibility of the the writing program to use the tag in a meaningful way, and the reading program must do its best to interpret it.
A series of Staff Grouping chunks. A Staff Grouping chunk indicates some type of connection at the left end of a series of sequential staves in the score, such as vertical lines, braces or brackets.
The Staff Groupings list in the Setup Section, if present, is the default for the score. The default can be overridden in the Data Section for an individual system by storing a Staff Groupings list immediately following the System Header chunkin the System list in the Data Section. If a system has any hidden parts or is different from the default system in any way, an override Staff Groupings list is required immediately following the System Header chunk. It completely replaces the default Staff Groupings list in the Setup Section.
Comment: The FONTIDX data type is an index into this list. A value of 0 indicates the first Font Description chunk in the list.
The purpose of the chunk length table is to give programs a tool for adapting to changes in the fixed length part of the NIFF chunk structures. The chunk length table is a series of 8 byte Chunk Length Table Entries, each table entry composed of a chunk name and the offset of the first tag field for chunks of that type. There must be a table entry for each chunk type present in the file. Chunks appear in the table in alphabetical order.
One of the valid chunks appearing in the Custom Graphics list. A PostScript description of a graphic, in EPS (encapsulated PostScript) format.
General information required to interpret values in the file.
One of the valid chunks appearing in the Custom Graphics list. Contains a complete PostScript type 1 font.
One of the valid chunks appearing in the Custom Graphics list. Contains a complete PostScript type 3 font.
Indicates some type of connection at the left end of a series of sequential staves in the score, such as vertical lines, braces or brackets. Staff groupings can be nested. When the same staff is included in more than one grouping, the grouping symbols are stored in the file in the order they are to be applied to the staff, from right to left, starting at the staff origin.
A Staff ID is assigned to every staff of every part, using the maximum number of staves for each part. The ID numbers are assigned in increasing order starting with Part 0, Staff 0. Here is an example:
Part 0 has maximum number of staves = 3 Part 1 has maximum number of staves = 3 Part 2 has maximum number of staves = 1 Default System Staff ID Description 0 Part 0, Staff 0 1 Part 0, Staff 1 2 Part 0, Staff 2 3 Part 1, Staff 0 4 Part 1, Staff 1 5 Part 1, Staff 2 6 Part 2, Staff 0
Chunk ID: "pghd"
Default anchor: None
Reference point/ Page Origin: Top left corner of page
Tags: Width, Height. For a file with simulated part ordering,
use values of zero for Width and Height.
Comments: The staff size is described by the Height tag, which contains the vertical distance between the top and bottom staff lines. The default number of staff lines is 5. If only one part is present on this staff, the Part ID tag should be appended here, so it won't have to be appended individually to each symbol in the Staff list.
Chunk ID: "sthd"
Default anchor: System origin
Reference point/ Staff Origin: Top line of staff
Tags: Part ID, Placement tags, Width, Height, Number of Staff
Lines, Silent (eg. for ossias)
Chunk ID: "syhd"
Default anchor: Page origin
Reference point/ System Origin: Staff origin of first (top)
staff
Tags: Placement tags, Width, Height.
(Note: for triple sharps or triple flats, or for the combinations natural+sharp and natural+flat, simply use two accidental chunks.)
Chunk ID: "altg"
Default anchor: Time-slice
Tags: multi-node symbol tags
Chunk ID: "artc"
Default anchor: Stem
Reference point: Center of symbol
Tags: Articulation Direction
For more than one dot, store additional Augmentation Dot chunks.
The Barline chunk should be stored only in the topmost staff of each part. It represents a graphic line extending from the current staff to the part's bottom staff. The Width tag can be used with either value of the type field to specify line width. However, for writing programs not concerned with exact measurements, the type field should be used to to distinguish between thick and thin barlines.
The Line Quality tag can be used to indicate a dotted or dashed line.
Chunk ID: "barl"
Default anchor: Time-slice
Reference point: Vertical: staff origin. Horizontal: center
of barline.
Tags: Width, Line Quality.
What to type
Description
@ (at sign)
a flat sign
# (pound sign)
a sharp sign
- (dash)
a minor sign
* (asterisk)
a diminished symbol
% (percent)
a half-diminished symbol
& (ampersand)
a major 7 triangle
6/9
the 6/9 chord suffix
/ (forward slash)
A diagonal slash for a hybrid chord, inversion or altered bass
\ (backward slash)
escape character. the next character typed appears "as is" in the chord
symbol, instead of being interpreted as a functional operator (for example,
type "\&" to place an ampersand in the chord symbol
_ (underline)
a horizontal slash for a poly chord
the text itself
any other text
type the suffixes and enclose them in parenthese, i.e. (#9@13)
stacked suffixes within braces
type the suffixes and enclose them in brackets, i.e. [#9@13]
stacked suffixes within brackets
type the suffixes and enclose them in < and > (left and right angle
brackets).
stacked suffixes with no braces or brackets
Examples:
What to type Chord C7(#9@13) C7#9@13 C7<#9@13> A/B F_C Cmin7@5/B@7(#9@13)Chunk ID: "chrd"
Note: NIFF represents only the most common subset of music words and symbols with special chunks and tags. Words and symbols not in the NIFF standard - like for example "fffff" - should be represented as generic text or graphics chunks. Note that single words implying simultaneous change in both dynamics and tempo (calando, slentando, incalzando, morendo, smorzando) can be encoded as text with attached midi.
Chunk ID: "dynm"
Default anchor: Part/Time-slice
Reference point: Bottom left of text string.
Tags: multi-node symbol tags, Line Quality
What to type
Description
digits 0-9
the numerals themselves
@ (at sign)
a flat sign
# (pound sign)
a sharp sign
- (dash)
a natural sign
\ (backwards slash)
the previous numeral is altered with a slash (for chromatic alteration)
/ (forward slash)
the following characters appear at the next stacking level below
Chunk ID: "figb"
Default anchor: Stem
Reference point: bottom left of first symbol
Used to describe a line that functions as a glissando, a rapid swoop from a lower to a higher note passing all half-steps in between. Normally a multi-node symbol anchored to two Notehead chunks. Use the Line Quality tag to specify anything other than a wavy line.
Chunk ID: "glis"
Default anchor: Notehead chunk
Reference point: endpoint of line
Tags: Line Quality, Thickness
Chunk ID: "gtgr"
Default anchor: Event Time-Slice
Reference point: The bottom left of the grid symbol
Chunk ID: "hrpn"
Default anchor: Time-slice
Reference point: See Discussion Section, Reference Points, Multi-node
Symbols, for details.
Tags: Hairpin Direction, Thickness, Height
1222121 3332123 1111111Chunk ID: "harp"
Chunk ID: "keys"
Default anchor: Time-slice
Reference point: Vertical: staff origin. Horizontal: left of
leftmost symbol.
Chunk ID: "keyn"
Default anchor: Time-slice
Reference point: Vertical: staff origin. Horizontal: Left of
leftmost symbol's bounding box.
Chunk ID: "line"
Default anchor: Time-slice
Reference point: Endpoint of line at each node
Tags: multi-node symbol tags, Glissando, Portamento, Anchor
Override, Thickness, Line Quality
Chunk ID: "lyrc"
Default anchor: Notehead
Reference point: Center of text string
Tags: Font ID, Line Quality, Reference Point Override
The numbering of alternate endings is left to the default of the reading program, unless explicitly indicated by the writing program with Measure Numbering chunks.
Only logical placement options can be specified for this chunk. If precise placement of numbers is desired, use the Rehearsal Mark chunk instead.
For notes and stems, use the normal syntax of a stem followed by one or more notes, with the Height tag optionally added to the stem to indicate its precise length. The same tags can be added to the NIFF Font Symbol chunk as to the ordinary music symbol chunks, such as Number of Flags, and Small Size.
Chunk ID: "ornm"
Default anchor: Stem
Reference point: Center of symbol
A Parenthesis can be a multi-node symbol, for instance when parentheses surround a series of staccatos over a series of notes. This would allow the sequence of staccatos to be understood as logically grouped by the parentheses.
Chunk ID: "pren"
Default anchor: Preceding symbol chunk.
Reference point: bottom left of text character
Tags: multi-node symbol tags
Chunk ID: "pdlo"
Default anchor: Stem
Used to describe a line that functions as a portamento, a rapid swoop from a lower to a higher note smoothly over all intervening frequencies. Normally a multi-node symbol anchored to two Notehead chunks. Use the Line Quality tag to specify anything other than a straight line.
Chunk ID: "port"
Default anchor: Notehead chunk
Reference point: endpoint of line
Tags: Line Quality, Thickness
For "bis" surrounded by brackets, logical codes 1 and 2 should be used at the start and end of the section, respectively, with graphical code zero. The graphical elements (brackets and the word "bis") should be constructed with Line and Text chunks.
See also Alternate Ending Graphic chunk and Alternate Ending tag, and General Discussion of Repeats and Alternate Endings, which gives an example.
Chunk ID: "rept"
Default anchor: Time-slice
Reference point: top center of symbol
A simple slur is a multi-node symbol with start and end nodes. The Tie Direction tag can be used on the first node of the slur to indicate whether the slur is bowed up or down. The standard placement tags when used on each slur node, indicate the placement of the slur endpoint relative to its anchor. Bezier Incoming and Bezier Outgoing tags can be used to specify Bezier control points for each node. A complex slur can be built by storing any number of slur nodes, each with its own Bezier Incoming and Outgoing control points.
Chunk ID: "slur"
Default anchor: Stem
Reference point: The slur end point. If a dependent symbol is
centered relative to a 2 node slur, the slur's horizontal reference is
the center, and the vertical reference is the lowest or highest point of
the arc, for slurs bowed downward or upward, respectively. Centering of
dependent symbol is undefined for cross-system slurs (which have more than
two nodes).
Tags: multi-node symbol tags, Tie Direction, Bezier Incoming, Bezier Outgoing
The end point of the stem is the end to which a flag or beam would be attached. When its position is known, it is indicated using one of the vertical placement tags. For whole notes and stemless rhythm slashes, a Height tag of zero should always be used. The Split Stem tag, when required for altered unisons, should be applied directly to the affected Notehead chunks rather than to the Stem chunk. Use the LogicalPlacement tag to represent stem direction. (This tag is optional, since not all notation programs store stem direction.)
Chunk ID: "stem"
Default anchor: Time-slice
Reference point: End point of stem (where the flag or beam would
be attached).
Tags: Placement tags, Voice ID, Part ID, multi-node symbol tags,
Height, Small Size, Large Size, Cue Note, Grace Note, Silent
This chunk can be stored at the start of a series of chunks to indicate that each of its tags are to be applied to all of the chunks appearing between it and a matching Tag Inactivate chunk. If a Part ID or Voice ID tag appears on it, this restricts its scope to chunks of that part or voice. See General Discussion for details and examples.
Chunk ID: "taga"
This chunk is used to end the application of tags started with a Tag Activate chunk. Each tag can be ended independently of the others with its own Tag Inactivate chunk, or they can be grouped together. See General Discussion for details and examples.
Chunk ID: "tagi"
text string -1 note value 3/8 beats per minute 72Chunk ID: "tmpo"
Example: Allegro moderato (M.M. [dotted eighth note] = 72)
Tempo Marking Nonstandard, number of chunks = 5 Text, string="Allegro moderato (M.M." NIFF Font [Stem] NIFF Font [Notehead, shape=4], number of flags=1 NIFF Font [Augmentation Dot] Text, string = "= 72)"Chunk ID: "tmpn"
Chunk ID: "text"
Default anchor: Time-slice
Reference point: bottom left
Tags: Font ID
Normally a tie would have two nodes. The Tie Direction tag is used on the first tie node to indicate which direction the tie is bowed. The standard placement tags when used on each tie node, indicate the placement of the tie endpoint relative to its anchor symbol reference point.
Chunk ID: "tie "
Default anchor: Notehead
Reference point: The tie end point. If a dependent symbol is
horizontally centered relative to the tie, the tie's horizontal reference
is the center, and the vertical reference is the lowest or highest point
of the arc, for ties bowed downward or upward, respectively.
Tags: multi-node symbol tags, Tie Direction, Bezier Incoming
& Outgoing
For a single number time-signature, use the top number, and set the bottom number to -1. To place an ordinary time-signature above the staff, use the Logical Placement tag, vertical component = above. To place it between the staves, use the Logical Placement tag, vertical component = below, and omit the Time Signature chunk in the lower staff.
Chunk ID: "time"
Default anchor: Time-slice
Reference point: Vertical: staff origin. Horizontal: center
of bounding box.
Tags: Placement tags, Large Size, Small Size
A special case of the Time-Signature - Nonstandard chunk is when it has a single text chunk starting with the backslash character "\". In this case, the ASCII string following the backslash is a string of numbers and '+', '/' and ' ', interpreted as follows:
'+' represents the literal plus sign
'/' means place the previous number(s) above the following number(s)
' ' means leave space between the previous and following number(s).
Examples of special case:
\2+4/8 \2/8 4/8Chunk ID: "timn"
A tuplet node chunk is placed with each stem or rest belonging to the tuplet. Normally a multi-node symbol. The Tuplet Description tag is required on the first node.
Chunk ID: "tupl"
Default anchor: Stem
Tags: Tuplet Description, Numer Style, multi-node symbol tags
A User-Defined chunk has a two-byte NIFF user ID stored in the first two bytes of the chunk, as described in the section above on "User-Defined Chunks and Tags." The rest of the structure is defined outside of this specification.
Chunk ID: "user"
horizontal SHORT
vertical SHORT
Non-default horizontal and vertical placement, in absolute units, of the dependent symbol's reference point relative to the anchor's reference point.
Logical Placement and Absolute Placement are mutually exclusive.
The sequence number of the ending. Used on the first measure-start Time-Slice chunk of each alternate ending to validate the duplicate start time values. See also Alternate Ending Graphic chunk and Repeat Sign chunk, and the General Discussion section of Repeats and Alternate Endings, which includes an example.
Contains the chunk typeof the non-default anchor symbol.
Used on the Articulation chunk to specifically indicate a particular version of the articulation symbol, such as fermata or strong accent.
1 = pointed up
2 = pointed down
Used on a slur node to specify an incoming Bezier control point. Gives the horizontal and vertical placement of the incoming Bezier control point relative to the slur endpoint. Can also be used on a tie node. See also Bezier Outoing tag.
horizontal SHORT
vertical SHORT
Example 1 - slur anchored to two notes:
Stem Notehead Slur, ID=1, Number of Nodes=2, Absolute Placement= (H1, V1), Bezier Outgoing = (H2, V2) Stem Notehead Slur, ID=1, Absolute Placement= (H3, V3), Bezier Incoming = (H4, V4)Example 2 - slur anchored to three notes (such as when it starts below an upstem note, swings up over the top of a down stem note, and then back down below another upstem note):
Stem Notehead Slur, ID=2, Number of Nodes=3, Absolute Placement = (H1, V1), Bezier Outgoing = (H2, V2) Stem Notehead Slur, ID=2, Absolute Placement = (H3, V3), Bezier Incoming = (H4, V4), Bezier Outgoing = (H5, V5) Stem Notehead Slur, ID=2, Absolute Placement = (H6, V6), Bezier Incoming = (H7, V7)
Used on a slur node to specify an outgoing Bezier control point. Gives the horizontal and vertical placement of the outgoing Bezier control point relative to the slur endpoint. Can also be used on a tie node See Bezier Incoming tag for examples.
horizontal SHORT
vertical SHORT
Horizontal and vertical placement of the outgoing Bezier control point relative to the slur endpoint.
Used on the Part Description chunk, to specify the default vertical placement of chord symbols with respect to the top staff of the part, in absolute units. In the Data Section, Chord Symbol chunks are interspersed with the music symbols of the first (top) staff of the part.
Used on a music symbol chunk to indicate that a nonstandard character and font is to be used. The function of the music symbol chunk is otherwise unchanged.
font ID FONTIDX
character code char[2]
Used when a custom graphic is to be used in place of the standard appearance of the music symbol.
The index into the Custom Graphic list of an EPS Graphic chunk containing a description of the graphic symbol.
Used to indicate that the chunk is located at the rightmost end of a system. This could be used at the end of a system on a Barline symbol in place of a horizontal offset, to avoid the undesirable results of rounding errors or font-width errors. It could be used at the end of a system where no barline is present, on an event Time-Slice chunk used as an anchor for a dependent symbol. To indicate the continuation of a multi-node chunk onto another system, use the Multi-node End Of System and Multi-node Start Of System tags instead.
Used on the first node of a Beam to indicate an accelerando or ritard.
On first beam node only.
1 = fanned beam expanding toward right
2 = fanned beam shrinking toward right
Used on the Part Description chunk, to specify the default vertical placement of the top numeral of figured bass symbols with respect to the bottom staff of the part, in absolute units. In the Data Section, Figured Bass chunks are interspersed with the music symbols of the last (bottom) staff of the part.
Used to indicate that a nondefault font is to be used for the chunk on which this tag occurs. Can be used on any music symbol or text-type chunk. Gives the index into the Font list, of the font to be used.
Used on a Stem, Notehead, or Rest. Indicates the logical start time as an offset from the time-slice start time. Negative values indicate that the grace note starts before the time slice, so during playback it should sound before the note. Zero and positive values indicate that the grace note's time value is stolen from the following note in the same voice.
Used on the Part Description chunk, to specify the default vertical placement of guitar grid symbols with respect to the top staff of the part, in absolute units. In the Data Section, Guitar Grid chunks are interspersed with the music symbols of the first (top) staff of the part.
Used on a Staff Header chunk to indicate that the staff is guitar tablature, and its symbols should be interpreted accordingly (not used for playback).
Vertical height, in absolute units.
Identification number. Used to uniquely identify multi-node symbols. Should be assigned sequentially within a chunk type, starting with zero.
When this tag is used on a symbol, the symbol's function and/or sound is unchanged, but the symbol does not appear visibly in the score.
Indicates that the symbol is larger than default size. For more precise control of size, use the Font ID tag instead.
Used on symbol chunks such as Barline, Line, or Slur to indicate that the line is not solid.
0 = no line
1 = dotted line
2 = dashed line
3 = wavy line
Non-default horizontal and vertical logical placement of the dependent symbol's reference point relative to the anchor's reference point.
Logical Placement and Absolute Placement are mutually exclusive.
This tag is appended to the Part Description chunk in the Setup Section, to define the vertical offset and Lyric Verse ID of one line of lyrics. Any number of them can be present.
Used on note chunks. See Timing Representation in the Discussion Section, for a description of its use.
Used on a node of a multi-node symbol to indicate that the symbol continues on the following system. The node containing this tag will always be paired with a node with the Multi-node Start Of System tag, located at the beginning of the following system. A reading program that does not have a system break at the same measure can ignore both nodes and use just the logical start and end nodes of the multi-node symbol.
Used on a node of a multi-node symbol to indicate that this is the continuation of a symbol which started on the previous system. See Multi-node End Of System tag for more details.
Number of flags on stemmed note.
Total number of nodes in file for this multi-node symbol. Always present on the first node chunk of any multi-node symbol.
Non-default number of lines in a staff, used on the Staff Header. (The default number is 5.) For example, a value of 6 would be used for guitar tablature, or a value of 1 for some percussion parts.
Used on one or more Staff Header chunks in a system to indicate an alternate performance of another staff or staves. The Part ID and/or Voice ID of the symbols in the ossia staff or staves duplicate those in the staff or staves to which the ossia is an alternative. See General Discussion on ossias for more details.
0 = do not playback the ossia - for display only
1 = playback the ossia instead of the staff to which it is an alternative
Used with Part ID on any chunk where Part ID can be specified, such as a Tag Activate/Inactivate, Staff Header or a music symbol chunk. It overrides the default characteristics of the part given in the Setup Section Part Description chunk. Its scope depends on the chunk type on which it appears.
0-32767. Used to associate chunks in the Data Section with a particular Part Description chunk in the Setup Section When used on a Staff Header chunk, it indicates that all symbols within the Staff list belong to the part. It can also be used on a Tag Activate or Tag Inactivate chunk to restrict the scope of those chunks (see general discussion of Tag Activate/Inactivate).
When this tag is applied to an anchor, its scope includes all symbols dependent on the anchor.
Description of non-default reference points on the anchor and dependent symbols. Always used in combination with either Absolute Placement or Logical Placement tags.
Used on the Part Description chunk, to specify the default vertical placement of the rehearsal mark with respect to the top staff of the part, in absolute units. In the Data Section, Rehearsal Mark chunks are interspersed with the music symbols of the first (top) staff of the part.
Number that is to appear centered over multiple-measure rest symbol
When this tag is used, the sound is suppressed for the symbol. The function of the symbol is other wise unchanged: it appears visibly in the score, and its duration is set as normal for use by a spacing algorithm. A cue note is one example of its use.
Indicates the presence of a slash on a stem, as in a grace note. For Tremolo slashes, use Tremolo chunk.
Indicates that the symbol is smaller than default size. Examples of its use are on a Clef chunk for clef changes, on a Stem, Notehead or Rest chunk with the Grace Note tag for small grace notes, and on a Stem, Notehead or Rest with the Silent tag, to indicate a cue note or rest. For more precise control of size, use the Font ID tag instead.
This tag is added to the NIFF Information chunk to indicate that a special horizontal spacing scheme is used. In this scheme, the symbols of each part are assigned horizontal placement values independently of the other parts, as though the file contained a set of part scores instead of or in addition to one ensemble score.
Each part's symbols are stored with the minimum size requirement for displaying those symbols when only that part is present. To produce correct spacing of an ensemble score recorded with this scheme, a reading program would calculate for each time-slice the greatest required width among any of the parts, and use that width for the whole ensemble at that time-slice.
A reading program that does not handle this type of spacing scheme should ignore horizontal placement completely, using its own spacing defaults instead.
Used on each Notehead chunk of an altered unison, when a single stem connects two or more notes, usually at the same staff step but different horizontal placements that are more than one notewidth apart. The exact visual appearance depends on the reading program's defaults.
Used on a Text chunk to indicate its function as a name for a staff or staff grouping. This allows the reading program to use intelligent defaults for placement of the text, when no placement tag is supplied. For a staff name, this tag should appear on a Text chunk following a Staff Header chunk. For a grouping name, it should appear on a Text chunk following a Staff Grouping chunk in a Staff Groupings list (in either the Setup Section or the Data Section).
Used to indicate vertical placement using the "staff step" units of measurement. Places the symbol's vertical hot spot on the specified staff line or space. If used with Logical Placement or Absolute Placement, it overrides the vertical component of those tags. When used on a chunk that has staff step as a required field, such as Notehead or Clef, it overrides the graphical placement of the symbol but not the musical function of the staff step field.
Used on symbol chunks such as Barline, Line, Hairpin, or Slur, to indicate the thickness of the line, in absolute units. When used on a Rehearsal Mark symbol, it refers to the thickness of the enclosure (box or circle).
Used on Tie chunks and simple Slur chunks, to indicating the bow direction of the curve.
1 = endpoints below, rounded above
2 = endpoints above, rounded below
A Number Style tag is used along with a Tuplet Description Tag in a Tuplet chunk.
0 = default
1 = first number only
2 = two numbers with colon
3 = number string
4 = no number
0-32767. Used on music symbols in the Data Section to uniquely identify a voice within the part. As a convention, should be assigned sequentially starting with zero, although voices can appear and disappear at random within a part. Always used in conjunction with Part ID. It can also be used on a Tag Activate or Tag Inactivate chunk to restrict the scope of those chunks (see general discussion of Tag Activate/Inactivate).
When this tag is applied to an anchor, its scope includes all symbols dependent on the anchor.
Horizontal width, in absolute units.
[structure not defined]
The structure of a User-Defined tag is defined outside of this specification, as explained in the section above on "User-Defined Chunks and Tags."