NIFF 6b

Notation Interchange File Format

June 11, 2002

Contents

Acknowledgements
Chapter 1 - General Discussion
Introduction
Bibliography
Logical Structures
Physical Structures
Measurement Units and Coordinate System
Timing Representation
Chunks , Lists , Forms and Tags
The Setup Section
Miscellaneous
Chapter 2 - Symbol Relationships
Dependent Symbols and Their Anchors
Multi-Node Symbols
Symbol Placement
Reference Points
Chapter 3 - Elements and Values
Lists
Chunks
- Setup Section Chunks
- Data Section Chunks
- - Header Chunks
- - Symbol Chunks
Tags
Appendix A - C Header File (this is a separate file).

Acknowledgements

The NIFF project began in February 1994 with a meeting between technical people representing three major music notation programs and three music scanning programs. The group's goal was to define a new standard format for exchange of music notation data, which everyone agreed was long overdue in the industry. With the publication of this document, the goal is now on the verge of fruition.

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

Addendum

For the work on NIFF 6b, I would first like to thank Alan Belkin, NIFF coordinator, for keeping NIFF alive by maintaining the official NIFF web site at University of Montreal, and for being available as work began on this revision.

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

Chapter 1 - General Discussion

Introduction

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.

Background.

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:

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.

Extensibility, Flexibility, and Compactness

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.

Logical, Graphical and Performance (MIDI) Data

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.

Illegal Notation Elements

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.

RIFF

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].

Platform Independence

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.

More on Flexibility

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.

Bibliography

1. Read, Gardner, "Music Notation - A Manual of Modern Practice," Second Edition, New York: Taplinger Publishing Company, 1969 (1979).

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.

Logical Structures

There are some terms commonly found in discussions of music notation which most musicians intuitively understand. This section defines the specific usage of these terms in NIFF. There are two types of time-slice: measure start and event. The measure-start time-slice identifies the start time of a measure with respect to the start of the score. The event time-slice identifes the start time of an event such as a note or rest with respect to the start of the measure.

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.

Physical Structures

A NIFF file is divided into two sections - the Setup Section, containing general information that applies to the whole score, and the Data Section, containing the music symbols and layout information. The Data Section is discussed in some detail here. The structures in the Setup Section are described later under Setup Section Structures. The topic of the relationships between individual music symbols in the Data Section is treated in Chapter 2, Symbol Relationships.

Hierarchy

The music symbols in the Data Section are stored in page-ordered format. The format has a hierarchical structure, where pages contain systems, systems contain staves, and staves contain time-slices and individual music symbols. Within each level, data are supplied generally in a left to right, top to bottom order, except as discussed in Chapter 2, Symbol Relationships. Text and graphics can be included at any level of the hierarchy, according to the type of object to which they logically belong.

Lists and Chunks

Pages, systems, and staves are all represented by lists composed of a header chunk followed by other component chunks that belong at the same hierarchical level. To save space, the time-slice has not been defined as a list chunk with a header and component chunks. Instead, the Time-Slice chunk functions as a sort of header to the group of symbol chunks which follow it. Every symbol within a Staff list, except for text or graphics immediately following the Staff Header chunk, is logically associated with the Time-Slice chunk that most closely precedes it.

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.

Simulated Part Ordering, and Spacing By Part

A special case of the page-ordered data structure is known as "simulated part ordering." In this structure, there is only one system on one "very wide" page that extends from the start to the end of the score, with each part appearing on its own staff or staves. This special type of file contains a single Page list whose Page Header chunk has zero Width and Height tags.

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.

Notes and Stems

A musical note is normally composed of at least two chunks - a Stem chunk and a Notehead chunk. It can be viewed as a degenerate case of a chord. A full chord is represented by a Stem chunk and several Notehead chunks, each of which represents a single notehead. There is no requirement that a Stem be followed by any Noteheads.

Measurement Units and Coordinate System.

Goals

NIFF's measurement system is designed:

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 and Staff Steps

NIFF uses two different measurement systems - absolute units and staff steps.

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.

Page Coordinate System

The size of a page is given as its height and width in absolute units. The origin of the page's coordinate system is the top left corner of the page (as in the lower right quadrant of a Cartesian coordinate system). Measurements are increasingly positive to the right and towards the bottom of the page.

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.

Font size

The size of text fonts is given in twips. (One twip = 1/20 of a point, or 1/1440 of an inch.) This allows for scaling of fonts between point sizes, for those who can use this feature (e.g. a 210 twip font = a 10 1/2 point font).

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.

Timing Representation

Goals

Two goals in NIFF's timing representation are 1) to describe the time values in a semantically useful way, and 2) to provide enough information for the reading program to produce a MIDI playback of the score.

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.

Duration

Durations in music notation are inherently rational numbers (fractions) which describe the relationship between a specific unit of time (the note value) and a standard unit of time (traditionally the whole note). A half note is 1/2 of a whole note; a quarter note is 1/4 of a whole note. Infinitely smaller note types can be invented by increasing the denominator to any power of 2.

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.

Tuplets

The duration field in a Notehead chunk is the same whether or not the note is included in a tuplet. Additional information (a series of tuplet chunks) is to be stored in the file for each tuplet. The first tuplet chunk contains a transformation ratio to be applied to each note in the tuplet, and graphical information about the appearance of the tuplet such as the presence of numbers and/or brackets.

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.

Logical Start Time

An explicit start time is required because simultaneous events are not always vertically aligned - for example, a chord with seconds. Ambiguity can result for a variety of other reasons as well.

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/4
The 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

An additional reason start time is required is that voices are not always logically complete from start to finish. If a voice were logically complete, the start time of each event within the voice would always be the exact time that the previous event in that voice finished. Logical incompleteness (gaps) can occur, however, for various reasons: 1) Piano music often allows temporary voices to appear and disappear with no rests to fill the time gaps. 2) A non-metrical cadenza-like section can appear in one voice or part, leaving all other voices or parts with a logical gap during that time. 3) Scanning programs can easily miss one or more notes in the middle of a sequence. 4) Inactive parts might be hidden for large sections of a score.

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.

Performance Information

For performance playback, both start time and duration are measured in MIDI ticks, which denote some fixed amount of time using an integer. MIDI ticks are well suited to performance information because of their high resolution. The relationship between the performance and logical values is described by the field MIDI ticks per quarter note, stored in the NIFF Information chunk in the Setup Section.

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).

Additional Comments

The Notehead and Stem chunks and associated chunks and tags contain graphical features such as notehead shape, number of dots and number of flags that in printed music describe a note's duration. However, the reading program need not concern itself with the timing implications of these details. The duration field stored on the Notehead chunk should be used for the timing value, regardless of the graphical features. For example, a note with duration of 3/16 could appear visually as a dotted eighth note with either a flag or a beam. In practice, any combination of a note's graphical features, or even an invisible note on a zero length stem, could be used to represent any time value.

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.

Barlines, Clefs, Time Signatures, Key Signatures

A barline signals the end of a measure rather than the start of a measure. On the last measure of a system it is necessary to store the Barline chunk before the measure-start time-slice, which belongs in a new Staff list and a new System list. So, for consistency and logical rigor, the Barline graphical symbol chunk is to be stored between the last event in the measure and the measure-start time-slice of the next measure. A special event time-slice chunk should be stored for this purpose, to uniquely identify the sequential position of the barline. Its start time can be the same, in essence, as the start time of the next measure-start time-slice, except given in relation to the start of its measure rather than the start of the score. The only time non-unique time-slices are allowed within a Staff list are when an event time-slice duplicates a measure-start time-slice in this way.

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.

Grace Notes

A grace note is a note whose time value is not counted in the general rhythm; its time value must be subtracted from that of the preceding or following normal note during performance. A grace note is always associated with the event time-slice of the normal note following it. It is indicated by the addition of a Grace Note tag to a Notehead or Stem chunk. The Grace Note tag gives the note's logical start time as an offset from thestart time of its time-slice (negative, zero or positive, depending on the chosen interpretation of grace notes and the note's position within a series of grace notes).

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.

See diagram 1.

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

Chunks, Lists, Forms and Tags

RIFF chunks, lists and forms

The basic building block of a RIFF file is called a chunk. A chunk is composed of a four character ASCII code indicating what type of chunk it is, followed by a length field, followed by the chunk's data. Defined in the C programming language, a chunk looks like this:
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.

NIFF chunks and tags

Each NIFF file chunk has a fixed-length part and a variable length part. The fixed-length part is composed of a set of required elements described by its chunk definition in Chapter 3. The variable length part is composed of a series of optional tags which may be used occasionally or only by certain programs.

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.

NIFF data types

The same data types are used in both chunk and tag definitions. Currently defined data types are described below.

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

N.B. NIFF versions before 6b defined STROFFSET as a 2 byte signed integer. However, the associated niff.h header file always defined it as 4 bytes and most implementations write a 4-byte STROFFSET. An implementation that wishes to read output from applications which write a 2-byte STROFFSET can check the entry in the Chunk Length Table for a chunk containing a STROFFSET. If the chunk size is 2 bytes shorter than expected, the implementation may assume that the chunk is using a 2-byte as opposed to 4-byte STROFFSET.

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.

Unicode Strings

The RIFF ZSTR which is pointed to by a STROFFSET contains a series of ASCII characters. But these cannot represent other languages such as Chinese. Therefore, NIFF allows for an alternative Unicode representation of any RIFF ZSTR. Unicode provides a unique number for every character in many languages, and is the standard for International language support in web browsers, Java and many other computer languages and operating systems. For full details, see the Unicode web site at http://www.unicode.org .

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 and Tags

NIFF users such as commercial software vendors and academic researchers can define their own NIFF chunks and tags, to provide for features of their software that are not present in the NIFF specification. NIFF users who want to define their own chunks and tags must formally register a unique two byte NIFF User ID, using a protocol yet to be developed.

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 Setup Section

The only required items in the Setup Section are the NIFF Information chunk, the Chunk Length Table, and the Parts list. Optional items in the Setup Section are the standard RIFF INFO list, the String Table, the Staff Groupings list, the Default Values chunk, the Font Descriptions list, and the Custom Graphics list. The required and optional components of each list must appear when present in the order described in Chapter 3, unless "in any order" is specified in the list's definition.

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.

Fonts and Custom Graphics

This section discusses the Font Descriptions list, the Custom Graphics list, and the related structures that allow the writing program to store and use special fonts and graphics in a NIFF file.

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.

Miscellaneous

MIDI Integration

This section describes how a complete MIDI file can be integrated into a NIFF file.

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.

Guitar Tablature

Guitar Tablature is encoded as a separate Staff list within a System list in the Data Section. It is normally the second staff of a part with two staves, and should be counted in the maximum number of staves in the Setup Section Part Description chunk. The Guitar Tablature tag, the Number of Staff Lines tag (with a value of 6), and the Part ID tag are added to the Staff Header chunk.

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.

Guitar slashes

There are two types of guitar slashes. Those with rhythm indicators such as stems, flags and beams are encoded using standard Stem and Notehead chunks, with a special slash notehead shape. For a guitar slash indicating a simple repetition of a chord symbol, the Repeat Sign chunk should be used, most likely with a Chord Symbol chunk.

Part and Staff Names

The Part Description chunk has fields for part name and part abbreviation. These can be used by the reading program as the names to be placed to the left of the system identifying the parts. This would be easiest in simple scores, where there is a clear correspondence between parts and staves and each Staff Header chunk has a Part ID tag to identify it. The part name font in the Default Values chunk can be used by the reading program for these simple part names and abbreviations.

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.

Ossias

An ossia is to be stored as one or more additional Staff chunks within a System list, each labelled with an Ossia tag applied to the Staff Header chunk. The presence of the Ossia tag indicates that this is an alternate performance of the symbols in one or more other staves. The part and voice of the ossia staves' symbols must be marked (individually, or by a shorthand method), to indicate which parts and voices it represents an alternative to.

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..

Measure Numbering and Rehearsal Marks

The Measure Numbering chunk is used to assign a measure numbering scheme. It allows for choice of the numbering frequency, starting number, and logical placement of the measure numbers. The measure numbering scheme can be changed at the start of any measure in the score, by storing this chunk after the appropriate measure-start Time-Slice chunk in the first Staff list of a System list.

For precise placement of individual numbers, or to use letters instead of numbers, use the Rehearsal Mark chunk instead.

Repeats and Alternate Endings

A repeated section of a score appears in the NIFF file only once. A Repeat Sign symbol contains information about both the graphical repeat sign and its function. It follows a Time-slice chunk (either measure-start or event type) at either the beginning or the end of the section to be repeated. The Repeat Sign chunk can be used for many kinds of repetition. It can indicate the appearance of symbols, printed words, or abbreviations, and the repetition of a beat, measure or whole section.

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.

Tag Activate/Tag Inactivate

When one or more tags is to be applied to a sequence of symbols in a Staff list, the Tag Activate chunk can be used to identify the start of the sequence, and the Tag Inactivate chunk to identify the end of the sequence. Each tag is activated independently of the others, but they can be grouped together on the Tag Activate/Inactivate chunks. For example, the Tag Activate may include the Font ID, Small Size and Grace Note tags, while one Tag Inactivate chunk ends the Grace Note tag long before the other two tags are ended with another Tag Inactivate chunk.

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)  Notehead
Notehead (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.

Tag Activate restricted by Part ID, Voice ID

Part ID and Voice ID have a special meaning on the Tag Activate chunk. When Part ID and/or Voice ID appear on the Tag Activate chunk, their purpose is to restrict the action of the Tag Activate to the subset of the intervening chunks which have matching Part ID and/or Voice ID's. If any intervening chunks have a different Part ID or Voice ID from that specified on the Tag Activate chunk, those chunks are not affected by the Tag Activate.

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 Size
Only 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.

Chapter 2 - Symbol Relationships

The meaning of a music notation symbol often depends on its relationships with other music symbols. Storing enough information in the NIFF file to relate music symbols to one another introduces complex programming issues. NIFF has been carefully designed in an attempt to allow programs to indicate symbol relationships with logical rigor, flexibility and efficiency. A balance has been sought between the sometimes conflicting efficiency goals of minimizing processing time, programming effort, memory usage and disk space.

Dependent Symbols and Their Anchors

In NIFF, a music symbol whose placement depends on one or more other symbols is called a "dependent" symbol, and the symbol or other chunk type on which its placement depends is called its "anchor." For each symbol chunk type, a default anchor chunk type is defined. For example, for the Fingering chunk, the Notehead is the default anchor, and for the Articulation chunk, the Stem is the default anchor.

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.

File Syntax

Syntax Rules.

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.

Stems and Notes

The relationship between the Stem chunk and Notehead chunk is a little different from other symbol relationships. In terms of syntax, the Notehead is dependent on the Stem (i.e. Noteheads appear in the file after their associated Stem). However, for symbol placement, both the Notehead and Stem are dependent on the Time-Slice. This is discussed below in "Reference points on Noteheads and Stems."

Noteheads and Stems bypass syntax rule 2. Notehead chunks always follow the Stem chunk in order from highest to lowest pitch.

Complex Dependencies - some examples

The file syntax and use of the Anchor Override tag allow complex dependencies to be represented in NIFF. For example, consider a slur between two fingering numbers related to a single notehead, parentheses surrounding the staccatos over a series of notes, or a small sharp sign above a trill ornament over a note. The anchor of each symbol is the chunk of the appropriate type (either default or explicit) which most closely precedes the dependent symbol in the file.

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.

See 1a, 1b in diagram 2.

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

Multi-Node Symbols

Beams, Slurs, Ties and Hairpins are examples of symbols which are normally dependent on more than one anchor. The interpretation of syntax rule 1 would be ambiguous in the case of a dependent symbol with a one-to-many relationship with its anchors. For example, consider a beam connecting three stems. Should the beam appear after the first, second or third stem? To allow syntax rule 1 to be applied consistently, one-to-many relationships have been decomposed in NIFF into one-to-one relationships by subdividing the "one" dependent symbol into several node chunks of a "multi-node symbol", each one corresponding to one of the "many" anchor chunks. Syntax rule 1 can then be followed: each dependent symbol node chunk physically appears in the file immediately after its corresponding anchor chunk.

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.

See diagram 3, left.

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

Multi-Staff Chords

When a stem contains notes on more than one staff, the stem is represented by a multi-node symbol. Each staff on which a portion of the stem appears has its own Stem node chunk. The first node contains the tags which affect all the nodes, such as Number of Flags.

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:

See diagram 3, right.

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

Multi-System Multi-Node Symbols

When a multi-node symbol crosses a system boundary, two special tags are used: the Multi-node End Of System tag, and the Multi-node Start Of System tag. These are required because the reading program might not have a system break in the same location as the writing program, and thus might not require these extra nodes. It can ignore all nodes with these tags if desired.

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

Symbol Placement

NIFF allows a variety of choices in describing the placement of symbols. The placement of a symbol is always described in terms of its relationship to its anchor. The choices include default placement, logical placement and absolute placement. A reference point for each symbol, defined by default, or explicitly by use of the Reference Point Override tag, is used in the interpretation of both absolute and logical placement values.

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.

Default, Logical and Absolute Placement

Default placement: This is the case when no indication of symbol placement is present for a symbol other than that implied by the file syntax. The reading program must use its own defaults for intelligent placement of the symbol.

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.

Choice of Placement Technique by the Writing Program

Absolute placement allows for the most precise rendering of the original notation. However, there are many situations where logical or default placement is more appropriate: Combinations of the various techniques can be included in a NIFF file. One possibility might be for a writing program to record page layout information such as the vertical location of each system and staff, and the horizontal position of each measure. Finer detail might be stored only when the user has specified non-default placement of some object, such as when a slur has been reshaped to avoid another symbol. In this case the writing program might store the absolute placement of a particular slur's endpoints in relation to its stem anchors.

The use of the three placement options will likely evolve during the trial implementation of NIFF.

Interpretation of Placement Values by the Reading Program

When encountering only absolute placement values in a NIFF file, a reading program could ignore them completely (strictly using its own defaults), or it could observe them without question. More intelligently, it could use them as a clue to determine logical placement of the symbols, avoiding collisions or incorrect alignment when necessary.

Reference Points

Every symbol has a default reference point used in interpreting the logical and absolute placement values. For a symbol such as an accidental or clef sign which has a natural "hot spot," the chunk definition specifies the hot spot as the default reference point. The default reference point of a Time-slice is the intersection of the time-slice at the staff's top line. If not otherwise specified, the default reference point of a symbol is the center of its bounding box.

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.

Reference Points on Noteheads and Stems

As stated earlier, the Notehead and Stem chunks both use the Time-slice as their anchor in terms of symbol placement. This means that the offsets of the Notehead and Stem chunks are both given in relation to the time-slice.

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.

See diagram 5

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.

Advanced Feature: using time-slice start time as a placement clue

There are some cases when the start times on an event time-slice might be used as a clue to the proper positioning of symbols. This is an advanced feature that is not required in either reading or writing programs for successful implementation of NIFF.

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).

Chapter 3 - Elements and Values

Contents

Lists - in order of file appearance

Chunks - in alphabetical order
- Setup Section Chunks
- Data Section Chunks
- - Header Chunks
- - Symbol Chunks

Tags - in alphabetical order

Note - Use of Tags

The "Tags" item listed under each chunk description contains a few suggestions for tags to be used in that context. It is not intended to restrict the the creative use of tags. Any tag is allowed to be placed on any chunk.

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.

Lists

in order of file appearance

Setup Section LIST

List ID: "setp"
Location: NIFF form
Required: Optional:

Parts LIST

List ID: "prts"
Location: Setup Section list
Required: Any number of Part Description chunks.

RIFF INFO LIST

List ID: "INFO"
Location: Setup Section list
Required: One or more of a series of structured comment chunks, as described in the RIFF documentation in the Microsoft Multimedia Programmer's Reference Manual (see References). Some of the chunks which might be included in an INFO list, and their meaning in a NIFF file are listed below. These are strictly for documentation purposes, and do not affect the interpretation of the values in the file.

Staff Groupings LIST

List ID: "grup"
Location: Setup Section list or Data Section list
Required: Any number of Staff Grouping Description chunks

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.

Font Descriptions LIST

List ID: "fnts"
Location: Setup Section list
Required: Any number of Font Description chunks.

Comment: The FONTIDX data type is an index into this list. A value of 0 indicates the first Font Description chunk in the list.

Custom Graphics LIST

List ID: "grph"
Location: Setup Section list
Required: Any number of the following, in any order:

Data Section LIST

List ID: "data"
Location: NIFF form
Required: nothing
Optional: Any number of Page lists

Page LIST

List ID: "page"
Location: Data Section list
Required: Optional: Any number of the following, in any order:

System LIST

List ID: "syst"
Location: Page list
Required: Optional:

Staff LIST

List ID: "staf"
Location: System list
Required: Optional: Any number of the following, in order as appropriate:

Chunks

Setup Section Chunks

in alphabetical order

Chunk Length Table CHUNK

Chunk ID: "clt "
Location: Setup Section 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.

chunk name FOURCC
offset of first tag LONG
A 4 byte pointer to the first tag field to be found in chunks of this type. The pointer value is always the same as the length of the required part of the chunk. If the chunk has no required structure, the pointer value is zero. If no tags are allowed in the chunk, the pointer value is -1.

Default Values CHUNK

Chunk ID: "dflt"
Location: Setup Section list
music font FONTIDX
part name font FONTIDX
Used as the default font for part name and abbreviation. See General Discussion of Part and Staff Names for details.
lyric font FONTIDX
chord symbol font FONTIDX
measure number font FONTIDX
rehearsal mark font FONTIDX
tuplet grouping symbol BYTE
See Tuplet Description tag for values.
tuplet number style BYTE
See Number Style tag for values.

EPS Graphic CHUNK

Chunk ID: "epsg"
Location: Setup Section, Custom Graphics list

One of the valid chunks appearing in the Custom Graphics list. A PostScript description of a graphic, in EPS (encapsulated PostScript) format.

Font Description CHUNK

Chunk ID: "fntd"
Location: Setup Section, Fonts list
font name STROFFSET
Offset into the string table of the font name.
size SHORT
Font size, in twips
space height SHORT
Used only for music fonts. Font size, given as the vertical distance, in absolute units, between two adjacent staff lines of a staff on which the music font symbols would normally appear.
where SHORT
Where this font can be found.
-1 = This font or a substitute is assumed to be known and available to the reading program.
0-32767. The index into the Custom Graphic list where the actual PostScript font can be found. This must point to a fnt1 or fnt3 chunk.
style BYTE
The following values are additive:
0 = plain
1 = bold
2 = italic
4 = underscored

NIFF Information CHUNK

Chunk ID: "nnfo"
Location: Setup Section list

General information required to interpret values in the file.

NIFF Version char[8]
6b
writing program type SIGNEDBYTE
-1 = no value/other
1 = engraving program
2 = scanning program
3 = MIDI interpreter
4 = sequencer
5 = research program
6 = educational program
standard units SIGNEDBYTE
-1 = no absolute measurements in file
1 = inches
2 = centimeters
3 = points
absolute units SHORT
Number of absolute units per standard unit.
-1 = no absolute measurements in file
MIDI ticks per quarter SHORT
MIDI ticks per quarter note, to be used in interpreting MIDI time values. Must be a positive number if MIDI time values are present in file. -1 indicates no MIDI timing information is present.

Part Description CHUNK

Chunk ID: "part"
Location: Setup Section, Parts list
Tags: Lyric Verse Offset (one for each lyric line), Chord Symbols Offset, Guitar Grid Offset, Rehearsal Mark Offset, Figured Bass Offset.
Part ID SHORT
The Part ID, referred to on Data Section chunks associated with this part. Should be assigned sequentially starting with zero.
name STROFFSET
Name to be associated with the staff or staves displaying this part on the first page of the score. See General Discussion of Part and Staff Names for details about its use.
abbreviation STROFFSET
Name to be associated with the staff or staves displaying this part on all pages after the first page of the score. See General Discussion of Part and Staff Names for details about its use.
number of staves BYTE
Maximum number of simultaneous staves for this part. Used to calculate staff ID's referred to in the Setup Section Staff Groupings list. A value of zero is allowed only if the Staff Groupings list is omitted from the Setup Section.
MIDI channel SIGNEDBYTE
Use -1 to specify none.
MIDI cable SIGNEDBYTE
Use -1 to specify none.
transpose SIGNEDBYTE
Number of halfsteps to transpose this part during playback.

PostScript Type 1 Font CHUNK

Chunk ID: "pst1"
Location: Setup Section, Custom Graphics list

One of the valid chunks appearing in the Custom Graphics list. Contains a complete PostScript type 1 font.

PostScript Type 3 Font CHUNK

Chunk ID: "pst3"
Location: Setup Section, Custom Graphics list

One of the valid chunks appearing in the Custom Graphics list. Contains a complete PostScript type 3 font.

Staff Grouping CHUNK

Chunk ID: "stfg"
Location: Setup Section Staff Groupings list, or Data Section Staff Groupings list.

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.

grouping type BYTE
1 = vertical line at start of system
2 = brace at start of system
3 = bracket at start of system
first staff SHORT
0-32767. Staff ID of first staff in grouping. See note below.
last staff SHORT
0-32767. System Staff ID of last staff in grouping. See note below.
N.B.: In a Data Section override Staff Grouping chunk, use the Staff ID's of the staves in the system to which the grouping applies, starting with zero for the first staff and increasing sequentially. In the Setup Section default Staff Groupings, Staff ID's of the default system are assigned as follows:

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

String Table CHUNK

Chunk ID: "stbl"
Location: Setup Section list
char[]
Contains one or more character strings in RIFF ZSTR format. Each ZSTR is composed of a series of ASCII characters followed by a one byte NULL (0x00) terminator. The character strings are referenced throughout the file by STROFFSET values which represent the offset into the tabl. 0 offset points to the first character after the chunk length.

Data Section Chunks

Header Chunks

in alphabetical order

Page Header CHUNK

EMPTY

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.

Staff Header CHUNK

EMPTY

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)

System Header CHUNK

EMPTY

Chunk ID: "syhd"
Default anchor: Page origin
Reference point/ System Origin: Staff origin of first (top) staff
Tags: Placement tags, Width, Height.

Time-Slice CHUNK

time slice type BYTE
1 = measure-start
2 = event
start time RATIONAL
depends on time-slice type
type 1: measure start time, relative to start of score
type 2: event start time, relative to previous measure-start time-slice
Chunk ID: "tmsl"
Default anchor: Previous measure-start time-slice, or staff origin (for first time-slice in a staff)
Reference point: Top staff line at its intersection with the time-slice.

Symbol Chunks

in alphabetical order

Accidental CHUNK

shape BYTE
1 = double flat
2 = flat
3 = natural
4 = sharp
5 = double sharp
6 = quarter tone flat
7 = three quarter tones flat
8 = quarter tone sharp
9 = three quarter tones sharp
Chunk ID: "acdl"
Default anchor: Notehead
Reference point: Hot-spot of symbol.
Tags: Small Size, Parenthesis

(Note: for triple sharps or triple flats, or for the combinations natural+sharp and natural+flat, simply use two accidental chunks.)

Alternate Ending Graphic CHUNK

Graphical symbols used on alternate endings. Used together with the Repeat Sign chunk and Alternate Ending tag. See General Discussion on Repeats and Alternate Endings for example.
bracket shape BYTE
0 = no down-jog
1 = down-jog at beginning
2 = down-jog at end
3 = down-jog at beginning and end
text string STROFFSET
Number to appear at start of bracket. Normally "1." or "2." but any text string is allowed.
Comments: Normally an alternate ending would have two nodes.

Chunk ID: "altg"
Default anchor: Time-slice
Tags: multi-node symbol tags

Arpeggio CHUNK

The symbol in front of a chord indicating that the notes of the chord are to be played successively from lowest to highest pitch, rather than simultaneously. This is a multi-node symbol, with node chunks anchored to the first and last Notehead chunks of the chord. It has both a logical and graphical function.
shape BYTE
1 = wavy line
2 = vertical slur mark
Chunk ID: "arpg"
Default anchor: Notehead chunk
Reference point: end points of the wavy line

Articulation CHUNK

shape SHORT
1 = strong accent (vertical wedge)
2 = medium accent (>)
3 = light accent ( tenuto)
4 = staccato
5 = down bow
6 = up bow
7 = harmonic (small circle)
8 = fermata
9 = arsis sign (unstressed)
10 = thesis sign (stressed)
11= plus sign
12 = vertical filled wedge (staccatissimo)
13 = double tonguing (two dots)
14 = triple tonguing (3 dots)
15 = "snap" pizzicato
For some symbols, such as the strong accent and fermata, the shape depends on the context of the symbol - a strong wedge with the point at the top is used above up-stem notes, while the point is at the bottom when it is below down-stem notes. The non-default version of the symbol can be specified with the Articulation Direction tag.

Chunk ID: "artc"
Default anchor: Stem
Reference point: Center of symbol
Tags: Articulation Direction

Augmentation Dot CHUNK

EMPTY

For more than one dot, store additional Augmentation Dot chunks.

When the dot is on a note or rest on a staff line, the vertical component of the Logical Placement tag can be used as follows:
1= above staff line
2 = below staff line
Chunk ID: "augd"
Default anchor: Notehead
Tags: Logical Placement,

Barline CHUNK

type BYTE
1 = thin line
2 = thick line
extends to BYTE
1 = to bottom line of bottom staff indicated by number of staves.
2 = currently unused. (This option is a holdover from a previous version of NIFF, where the barline chunk wording was quite different. The numbering is being retained so as not to conflict with the NIFF SDK or header file.)
3 = only in spaces between staves (not through staves)
number of staves SHORT
Any number of these chunks can appear together (normally following a measure-start time-slice), with their order of appearance in the file indicating their graphical placement from left to right. The Barline chunk has only graphical significance. Use the Barline chunk together with the Repeat Sign chunk for repeat barlines. The Repeat Sign chunk would be stored by itself in all but the first staff of the barline's number of staves.

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.

Beam CHUNK

Normally a multi-node symbol. See Discussion Section, Multi-node Symbols for more details.
beam parts to left BYTE
beam parts to right BYTE
Chunk ID: "beam"
Default anchor: Stem
Reference point: Reference point of anchor.
Tags: multi-node symbol tags

Chord Symbol CHUNK

The chord symbols placed above a staff. The chord symbol offset value in the Setup Section Part Description, if any, applies to this Chord Symbol. These chunks are interspersed with the music symbols of the part in the Staff list.
text description STROFFSET
A case-sensitive ASCII text string that represents the chord symbol to be printed.
Special characters and their meanings are as follows:

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"
Default anchor: Stem
Reference point: The baseline of the chord symbol text. (If more than one baseline, as in hybrid chord or poly chord, use lowest baseline.
Tags: Font ID

Clef CHUNK

Indicates that the following musical symbols are to be interpreted in the specified clef. When two clefs are active on the same staff, one or more Voice ID tags can be applied to the Clef chunk to associate it with a subset of the following symbols. It is active until the end of the Staff list, unless terminated by a new Clef (perhaps with an Invisible tag), which applies to the same voice or voices.
shape BYTE
1 = G clef
2 = F clef
3 = C clef
4 = percussion
5 = Double G clef
6 = TAB for guitar tablature
staff step SIGNEDBYTE
Staff step of clef sign hot spot.
treble clef: shape = G clef, staff step = 2
bass clef: shape = F clef, staff step = 6
alto clef: shape = C clef, staff step = 4
tenor clef: shape = C clef, staff step = 6
guitar tablature: shape = TAB, staff step = 8 (on a 6 line staff).
octave number BYTE
Used to modify the shape by attaching a little "8" above or below the clef symbol. The presence of the 8 above or below transposes the staff an octave up or down.
0 = no number
1 = 8 above
2 = 8 below
3 = 15 above
4 = 15 below
Chunk ID: "clef"
Default anchor: Time-slice
Reference point: Vertical: clef hot spot. When dependent, use left of symbol for horizontal reference. When an anchor, use center for horizontal reference.
Tags: placement tags, Voice ID

Custom Graphic Symbol CHUNK

Used when a custom graphic is to be placed on the page, with no musical function or sound.
value SHORT
The index into the Custom Graphic list of an EPS Graphic chunk containing a description of the graphic symbol. Used only within a page or system context. This chunk has no musical sound or function.
Chunk ID: "cstg"
Default anchor: In System list: system origin. In Page list, page origin.

Dynamic CHUNK

code BYTE
1 = pppp
2 = ppp
3 = pp
4 = p
5 = mp
6 = mf
7 = f
8 = ff
9 = fff
10 = ffff
11 = sp
12 = sf
13 = sfz
14 = fz
15 = fp
16 = cresc.
17 = crescendo
18 = dim.
19 = diminuendo
When a change in dynamic is to occur over a range (such as with values 16 - 19), the Dynamic chunk can be a multi-node symbol, indicating the start and end of the range. The Line Quality tag can be included on the start node, normally with a value of dashes.

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

Figured Bass CHUNK

text description STROFFSET
Used to describe the numerals and accidentals of a basso continuo. These chunks are interspersed with the other music symbols of the staff to which it belongs (such as in a harspichord part).
Each chunk is composed of an ASCII character string with the following interpretation:

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

Fingering CHUNK

shape BYTE
0 = finger 0
1 = finger 1
2 = finger 2
3 = finger 3
4 = finger 4
5 = finger 5
Chunk ID: "fing"
Default anchor: Notehead chunk
Reference point: Bottom left of text character

Glissando CHUNK

EMPTY

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

Guitar Grid CHUNK

The guitar grid symbols placed above a staff. The guitar grid offset in the Setup Section Part Description, if any, specifies the default vertical placement for this guitar grid symbol. Guitar Grid chunks are interspersed with the music symbols of the part in the Data Section Staff list. To display a prepared PostScript graphic, use the Custom Graphic Symbol chunk instead of the Guitar Grid chunk.
number of frets BYTE
The number of frets of the guitar fingerboard represented by the grid.
number of strings BYTE
6, for guitar. Could be another value, such as 4, for ukele. The length of the text description is the same as the number of strings (i.e., for guitar, the text description is 6 digits, ABCDEF).
text description STROFFSET
A number represented as an ASCII character string ABCD..., where A refers to the lowest string, B the next, and so on. The numbers in the text description indicate on which fret the dot is to be placed. The number 9 will create an open circle above the grid indicating a higher fret. The number 0 represents an open string.
Examples: (See table to be added)

Chunk ID: "gtgr"
Default anchor: Event Time-Slice
Reference point: The bottom left of the grid symbol

Guitar TAB Number CHUNK

Used to indicate numbers to be placed on a guitar tablature staff.
number BYTE
The ASCII representation for the number, normally 0-6.
staff step SIGNEDBYTE
Indicates the string line on which the number is to be placed, specified in staff steps. For traditional guitar tablature notation, even numbers should always be used.
Chunk ID: "gttb"
Default anchor: Notehead
Reference point: The center of the bounding box of the number.
Tags: Voice ID

Hairpin CHUNK

direction BYTE
1 = open to left
2 = open to right
Normally a hairpin would be a multi-node symbol. The direction field should have a value of 0 for all nodes but the first. The Height tag can be used to specify the vertical distance between the end points on the open node.

Chunk ID: "hrpn"
Default anchor: Time-slice
Reference point: See Discussion Section, Reference Points, Multi-node Symbols, for details.
Tags: Hairpin Direction, Thickness, Height

Harp Pedal Symbol CHUNK

pedal positions STROFFSET
A 7 digit ASCII character string ABCDEFG representing a Salzedo diagram, where each letter represents one of the seven harp pedals, A, B, and C on the left, and D, E, F and G on the right. Each digit can have a valueof 1, 2, or 3, depending on whether the pedal is in the bottom (sharp) position, the middle (natural) position, or the top (flat) position.
Examples:
1222121

3332123

1111111
Chunk ID: "harp"
Default anchor: Time-slice
Reference point: Vertical center, horizontal left of diagram.

Key Signature CHUNK

standard code SIGNEDBYTE
0 = no sharps or flats
1-7 =1-7 sharps
8-14 = 1-7 flats
-1 - -7 = 1-7 naturals in the sharp positions
-8 - -14 = 1-7 naturals in the flat positions
Explicit cancellation of the previous key signature is indicated with a Key Signature chunk containing a negative value, preceding the new Key Signature chunk. The key signature affects the pitch of the notes for MIDI playback.

Chunk ID: "keys"
Default anchor: Time-slice
Reference point: Vertical: staff origin. Horizontal: left of leftmost symbol.

Key Signature - Nonstandard CHUNK

number of chunks BYTE
Indicates the start of a nonstandard key signature. This chunk is followed by a series of graphical chunks such as NIFF Font Symbol chunks, Custom Graphic Symbol chunks, or Text chunks, each one representing a character to be printed. The number of chunks following this one is given in the number of chunks field. The referenced chunks are to be considered only in the context of the key signature, and are otherwise devoid of function. Each referenced chunk contains its own placement information. If placement information is absent, the symbols are to be placed from left to right. The Width tag indicates the width of the entire key signature, from the left of the leftmost symbol to the right of the rightmost one.
Example: To place a sharp sign on the top line, store this chunk with a number of chunks of 1. Following it, store an Accidental chunk with a shape of sharp sign and a Staff Step tag of 8.

Chunk ID: "keyn"
Default anchor: Time-slice
Reference point: Vertical: staff origin. Horizontal: Left of leftmost symbol's bounding box.

Line CHUNK

shape BYTE
Used on each node, to describe the characteristics of the line at that node.
0 = no unusual feature
1 = arrowhead at node
2 = down-jog at node
3= up-jog at node
Normally a multi-node symbol. The Line Quality tag is used to indicate such features as dashed, dotted or wavy. For glissando or portamento functions, use Glissando or Portamento chunks.

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

Lyric CHUNK

text STROFFSET
A text string representing a word or syllable. For a lyric which extends beyond one time-slice, a multi-node lyric should be constructed. On each node but the first, the text pointer should be given the value -1. The Line Quality tag should be used on the first node, to indicate the graphical technique used to extend the word. If the word is split into two syllables, each in a separate time-slice, the text of the first syllable can be followed by a backslash "\" and then a hyphen. This indicates that a hyphen is to be horizontally centered between the two syllables.
When a lyric is to be left justified rather than centered, the Reference Point Override tag can be used.
Lyric Verse ID BYTE
Associates this Lyric chunk with a particular Lyric Verse Offset tag on the Setup Section Part Description. If there is more than one Lyric within a Time-Slice, the Lyric Verse ID must be different on each.
An Anchor Override = stem can be used to relate a lyric to a chord.

Chunk ID: "lyrc"
Default anchor: Notehead
Reference point: Center of text string
Tags: Font ID, Line Quality, Reference Point Override

Measure Numbering CHUNK

Used to set or change the measure numbering scheme anywhere in the score. Stored after a measure-start Time-Slice chunk in the first Staff list of a System list. The instructions given in this chunk are in effect until the end of the score, or until the next Measure Numbering chunk, whichever comes first.

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.

number which measures BYTE
0 = no measure numbering
1 = use number frequency field
2 = number start of each system
3 = number start of each page
number frequency BYTE
How frequently measure numbers are to appear. 1 means every measure, 2 means every other measure, etc.
starting number SHORT
The number to be used for the measure starting with the current measure-start Time-Slice.
font ID FONTIDX
The font, size and style to be used for measure numbers.
above or below BYTE
0 = above top staff of system
1 = below bottom staff of system
horizontal centering BYTE
0 = centered at barline
1 = to left of barline
2 = to right of barline
3 = to left of start of system (number which measures = 2 or 3 only)
enclosure BYTE
0 = none
1 = box
2 = circle
Chunk ID: "meas"

MIDI Data Stream CHUNK

Used to record a free-form stream of MIDI events. When its sound is associated with more than one notational symbol, it is a multi-node symbol, with each node anchored to a symbol chunk. In this case, its first node contains the full MIDI data stream in the value field, and all other nodes contain a null value field. Otherwise it contains only one node. It replaces any explicit or implied MIDI Performance of the chunks to which it is anchored. If anchored to a Time-Slice, it is independent of any notational element. See General Discussion of MIDI Integration for more details.
start time BYTE
Start time of the stream, given in MIDI ticks, as an offset from the logical start time of its anchor.
value char[]
The MIDI data stream. Its length is equal to the chunk size minus 1.
Chunk ID: "midi"
Default anchor: preceding chunk
Tags: Multi-node symbol tags

NIFF Font Symbol CHUNK

A standard music font character that is to be placed on page or system outside of a staff, without its normal sound or function. Any of the music symbols normally indicated with a music symbol chunk can be represented this way. This chunk can be used within a Page list or a System list but not in a Staff list. One example of its use is withiin the list of characters following a Tempo Marking Nonstandard chunk.

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 type FOURCC
The four character chunk type of the music symbol, such as STEM, NOTE, ORNM, or ARTC.
space height SHORT
The size of the character, given as the height in absolute units of a space on a staff on which the character would appear of normal size.
shape BYTE
The value of the shape field in the chunk of type chunk type. For example, for a filled notehead, the value of shape would be 4. If there is no shape field on the referenced music symbol, leave shape 0 on this chunk.
Chunk ID: "font"
Default anchor: In system list: system origin. In page list, page origin.
Reference point: The middle of the symbol's bounding box.

Notehead CHUNK

shape BYTE
1 = breve (double whole)
2 = whole
3 = half (open)
4 = filled (solid)
5 = open diamond
6 = solid diamond
7 = x notehead
8 = open x notehead
9 = filled guitar slash
10 = open guitar slash
11 = filled square
12 = open square
13 = filled triangle
14 = open triangle
staff step SIGNEDBYTE
See Discussion Section - Measurement Units
duration RATIONAL
See Discussion Section - Timing Representation
Chunk ID: "note"
Default anchor: Time-slice
Reference point: The center of the bounding box of the notehead.
Tags: Part ID, Voice ID, placement tags, MIDI Performance, Grace Note, Cue Note, Small Size, Large Size, Invisible, Split Stem, Silent

Octave Sign CHUNK

Normally a multi-node symbol indicating that all symbols in the Staff list between the first and last nodes are to be performed one or two octaves higher or lower than as written, or, in the case of coll' ottava, are to be doubled at the octave above or below. Only a starting and ending node are required, unless the octave marking extends beyond a system boundary (see multi-node symbols). One or more Voice ID or Part ID tags can be appended to the first node, indicating that only the specified voices or parts are affected. The function is active until its final node is encountered in the file. On all nodes but the first, the meaning of the fields can be ignored, and should be stored as null. Placement tags are used to indicate where the symbol appears in relation to the staff. The Line Quality tag should be used if anything besides a dashed line is desired.
number of octaves BYTE
Normally 1 or 2.
above or below BYTE
To be performed above or below the notated symbols.
1 = above
2 = below
type BYTE
1 = notated symbols to be transposed one or more octaves
2 = notated symbols to be doubled (coll' ottava)
text string STROFFSET
The text string appearing at its start, such as "8va" or 8 or "8a alta"
Chunk ID: "octv"
Tags: Line Quality

Ornament CHUNK

shape SHORT
1 = mordent
2 = inverted mordent
3 = double "long" mordent
4 = inverted double "long" mordent
5 = turn
6 = inverted turn
7 = trill (spelled "tr")
8 = trill (short symbol - 2 bumps)
9 = trill (short symbol - 3 bumps)
10 = trill (long wavy line)
11 = long trill with up-hook at start
12 = long trill with down-hook at start
Accidental chunks may be anchored to an ornament, with placement tags indicating above or below, usually with a Small Size tag. The long trill symbols (shapes 10, 11, 12) are multi-node, anchored to the start and end anchors of the trill.

Chunk ID: "ornm"
Default anchor: Stem
Reference point: Center of symbol

Parenthesis CHUNK

shape BYTE
1 = left parenthesis '('
2 = right parenthesis ')'
3 = left brace - '{'
4 = right brace '}'
5 = left bracket '['
6 = right bracket ']'
7 = left and right parentheses surround anchor
8 = left and right braces surround anchor
9 = left and right bracket surround anchor
The default size of the symbol(s) is the reading program's default for the given context. By default symbols 1, 3 and 5 should be placed to the left of the anchor, and symbols 2, 4, and 6 to the right of the anchor.

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

Pedal (Piano) CHUNK

Normally a multi-node symbol with two nodes, the starting node indicating where to depress the pedal, and the ending node indicating where to release it. Each node should use the appropriate shape byte. For half-pedal markings, a node should be stored at each time-slice where the line has a notch.
shape BYTE
0 = no graphic (for last node, when no graphical symbol appears there)
1 = "Ped." (graphic)
2 = Asterisk (*) indicating end of damper pedal
3 = alternate end of damper pedal symbol (circle with cross-hairs)
4 = horizontal line with up-jog at this node
5 = horizontal line with down-jog at this node
6 = upslanted line with up-jog at this node
7 = upslanted line with down-jog at this node
8 = notch in line at this node
9 = "una corda" text
10 = "tre corde" text
11 = "S.P. " text (sostenuto pedal)
Chunk ID: "pdlp"

Pedal (Organ) CHUNK

shape BYTE
1 = heel (u shape)
2 = heel (o shape)
3 = toe ( up-pointed wedge)
4 = toe (down-pointed wedge)
This chunk is interspersed with the music symbols on the organ pedal staff. The Logical Placement tag is used to place these symbols above or below the staff, to indicate right foot or left foot. The line or slur sometimes connecting two organ pedal symbols is represented by multi-node Line or Slur chunks anchored to the organ Pedal chunks.

Chunk ID: "pdlo"
Default anchor: Stem

Portamento CHUNK

EMPTY

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

Rehearsal Mark CHUNK

The rehearsal letters or numbers placed above a staff . The rehearsal mark offset in the Setup Section Part Description, if any, specifies the default vertical placement for this rehearsal mark. Rehearsal Mark chunks are interspersed with the music symbols of the part in the Data Section Staff list.
text string STROFFSET
The letter(s) or number(s).
enclosure BYTE
0 = none
1 = box
2 = circle
Chunk ID: "rhrs"
Default anchor: Time-slice
Reference point: top left of bounding box
Tags: Font ID, placement tags

Repeat Sign CHUNK

Logical and graphical components of a repeat sign. Indicates the start or end of a section to be repeated, or the repetition of a previous beat, measure or measures.
graphical code SHORT
0 = no graphical symbol - this is only a logical chunk
1 = Segno symbol :S:
2 = Coda symbol (circle with crosshairs)
3 = one slash (such as with logical code 3 or 7)
4 = 2 slashes (such as with logical code 3)
5 = 3 slashes (such as with logical code 3)
6 = 2 slashes with dot on either side (such as with logical code 3)
7 = 1 slash with dot on either side (such as with logical code 4)
8 = 1 slash with dot on either side, and barline through it (such as with logical code 5)
9 = 2 slashes with dot on either side, and barline through it (such as with logical code 5)
10 = Repeat dots - use Barline chunk(s) with this
11 = "D.C."
12 = "D.C. al Fine"
13 = "D.C. al Segno"
14 = "D.C. al Segno e poi la Coda"
15 = "D.S."
16 = "D.S. al Fine"
17 = "Fine"
18 = "Coda"
logical code BYTE
0 = no repeat function - this is only a graphical chunk
1 = beginning of section to be repeated
2 = end of section to be repeated
3 = repeat the previous beat
4 = repeat the previous measure
5 = repeat the previous two measures
6 = function as described by words (graphical codes 11 - 18)
7 = repeat chord indicated by associated Chord Symbol for one beat
A text chunk should be anchored to this chunk if a number over a slash repeat sign is to appear here.

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

Rest CHUNK

shape BYTE
1 = breve (double whole)
2 = whole
3 = half
4 = quarter
5 = eighth
6 = sixteenth
7 = 32nd
8 = 64th
9 = 128th
10 = 256th
11 = multiple rest symbol - 4 measures
12 = multiple-measure rest - thick horizontal bar (normally used with dependent text chunk containing a number, and possibly with Width and Thickness tags)
13 = multiple-measure rest - thick slanted bar (same options as shape 12)
14 = vocal breath mark (comma)
15 = vocal breath mark (2 small slashes)
staff step SIGNEDBYTE
See Discussion Section - Measurement Units
duration RATIONAL
See Discussion Section - Timing Representation

 
Chunk ID: "rest"
Default anchor: Time-slice (event type)
Reference point: Hot spot of rest:
Horizontal hot spot: the center of the rest.
Vertical hot spot: When the staff step is 4, then the rest has its usual vertical placement. That is, the "whole" rest is hanging from the fourth line from the bottom, the "half" rest is sitting on the middle line, the "quarter" rest is centered on the middle line, etc.

Slur CHUNK

EMPTY

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

Stem CHUNK

EMPTY

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

System Separation Mark CHUNK

Used in ensemble scores to vertically separate systems. Should be stored immediately following the System Header chunk.
where BYTE
1 = placed at left margin
2 = placed at right margin
Chunk ID: "ssep"
Default anchor: System origin
Reference point: Center of symbol's bounding box

Tag Activate CHUNK

EMPTY

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"

Tag Inactivate CHUNK

EMPTY

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"

Tempo Marking CHUNK

A standard tempo marking either in the form [note] = [metronome setting], or text tempo instructions.
text string STROFFSET
Used for text instructions such as "Allegretto". If ia special font or italics are required, append the Font ID tag.
note value RATIONAL
The note value representing one beat. See discussion of Timing Representation for values. If only text is desired, leave this 0/0.
beats per minute SHORT
The metronome setting, where one beat is equal to a note with duration of note value. If only text is desired, leave this 0.
Example: [dotted quarter] = 72
    text string -1
    note value  3/8
    beats per minute  72
Chunk ID: "tmpo"
Default anchor: Time-slice (most recent one of any type)
Reference point: Bottom left of bounding box.
Tags: Font ID

Tempo Marking Nonstandard CHUNK

number of chunks BYTE
Indicates the start of a tempo marking. This chunk is followed by a series of graphical chunks such as NIFF Font Symbol chunks or Text chunks, each one representing a symbol or word to be printed. The number of chunks following this one is given in the number of chunks field.
The referenced chunks are to be considered in the context of the tempo marking, and are otherwise devoid of function. Each referenced chunk contains its own placement information. If placement information is absent, the symbols are to be placed from left to right. The Width tag indicates the width of the entire tempo marking, from the left of the leftmost symbol to the right of the rightmost one.

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"
Default anchor: Time-slice (most recent one of either type)
Reference point: Bottom left of bounding box.
Tags: placement tags, Width

Text CHUNK

value STROFFSET
A text string.
By default, the bottom left of the text string is placed at the anchor's reference point. The Font ID tag can be used to specify the font. Text can be centered or justified by use of the Reference Point Override tag.

Chunk ID: "text"
Default anchor: Time-slice
Reference point: bottom left
Tags: Font ID

Tie CHUNK

EMPTY

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

Time Signature CHUNK

top number SIGNEDBYTE
bottom number SIGNEDBYTE
The common non-numeric time signatures are represented as follows:
"common time" symbol: top number = -1, bottom number = -1
"cut time" symbol: top number = -2, bottom number = -1

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

Time Signature - Nonstandard CHUNK

number of chunks BYTE
Indicates the start of a nonstandard time signature. This chunk is followed by a series of graphical chunks such as NIFF Font Symbol chunks, Custom Graphic Symbol chunks, or Text chunks, each one representing a character to be printed. The number of chunks following this one is given in the number of chunks field. The referenced chunks are to be considered only in the context of the time signature, and are otherwise devoid of function. Each referenced chunk contains its own placement information. If placement information is absent, the symbols are to be placed from left to right. The Width tag indicates the width of the entire key signature, from the left of the leftmost symbol to the right of the rightmost one.

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/8
Chunk ID: "timn"
Default anchor: Time-slice
Reference point: Vertical: staff origin. Horizontal: Left of leftmost symbol's bounding box.

Tremolo CHUNK

Normally multi-node with two nodes. For a single stem tremolo with slashes through the stem, there will be a single node, with attached beam parts containing the number of slashes, and unattached beam parts zero. For whole note tremolos, set attached beam parts to zero, and use unattached beam parts. The presence of a Tremolo chunk affects the playback of the related Notehead chunk. The duration on each Notehead should be assigned such that the total duration of all Noteheads belonging to the tremolo equals the total duration of the notes on playback.
attached beam parts BYTE
The number of beams attached to the stem (primary beams).
unattached beam parts BYTE
The number of beams not attached to the stem (secondary beams).
Chunk ID: "tmlo"
Default anchor: Stem
Reference point: Reference point of anchor.
Tags: multi-node symbol tags

Tuplet CHUNK

EMPTY

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

User-Defined CHUNK

[structure not defined]

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"

Tags

in alphabetical order

Absolute Placement STRUCTURE

Tag ID: 0x01

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.

Alternate Ending BYTE

Tag ID: 0x02

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.

Anchor Override FOURCC

Tag ID: 0x03

Contains the chunk typeof the non-default anchor symbol.

Articulation Direction BYTE

Tag ID: 0x04

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

Bezier Incoming STRUCT

Tag ID: 0x05

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)

Bezier Outgoing STRUCT

Tag ID: 0x06

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.

Chord Symbols Offset SHORT

Tag ID: 0x07

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.

Custom Font Character STRUCT

Tag ID: 0x08

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]

Custom Graphic SHORT

Tag ID: 0x09

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.

End Of System EMPTY

Tag ID: 0x0A

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.

Fanned Beam SHORT

Tag ID: 0x0B

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

Figured Bass Offset SHORT

Tag ID: 0x0C

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.

Font ID FONTIDX

Tag ID: 0x0D

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.

Grace Note RATIONAL

Tag ID: 0x0E

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.

Guitar Grid Offset SHORT

Tag ID: 0x0F

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.

Guitar Tablature EMPTY

Tag ID: 0x10

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).

Height SHORT

Tag ID: 0x11

Vertical height, in absolute units.

ID SHORT

Tag ID: 0x12

Identification number. Used to uniquely identify multi-node symbols. Should be assigned sequentially within a chunk type, starting with zero.

Invisible EMPTY

Tag ID: 0x13

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.

Large Size EMPTY

Tag ID: 0x14

Indicates that the symbol is larger than default size. For more precise control of size, use the Font ID tag instead.

Line Quality BYTE

Tag ID: 0x15

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

Logical Placement STRUCTURE

Tag ID: 0x16

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.

horizontal BYTE
0=default
1=left
2=right
3 = stem side
4= note side
5 = centered
Values 3 and 4 are only to be used on a symbol dependent on a note or stem. "Stem side" and "note side" have the same meaning as "left" and "right" respectively for down stems, and the opposite for up stems.
vertical BYTE
0=default
1=above
2=below
3 = stem side
4= note side
5 = centered
Values 3 and 4 are only to be used on a symbol dependent on a note or stem. "Stem side" and "note side" have the same meaning as "above" and"below" respectively for up stems, and the opposite for down stems.
proximity BYTE
0= not applicable, or default
1 = touching, or exactly aligned
2 = offset slightly
Used to refine the meaning ofNon-default logical placement of the symbol's bounding box relative to the anchor's bounding box. For instance, a note slightly offset from a stem would be given the value 2.

Lyric Verse Offset STRUCT

Tag ID: 0x17

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.

lyric line offset SHORT
Default vertical placement of a line of lyrics with respect to the bottom staff of the part, in absolute units. A null value (-1) is allowed, even when Lyric chunks are present in the Data Section. In the Data Section, Lyric chunks are interspersed with the music symbols of the part in the Staff lists.
Lyric Verse ID BYTE
Used to associate the Lyric Verse ID field on Lyric chunks in the Data Section with the default vertical offset supplied here.

MIDI Performance STRUCT

Tag ID: 0x18

Used on note chunks. See Timing Representation in the Discussion Section, for a description of its use.

start time LONG
Start time, given in MIDI ticks, as an offset from the time-slice
duration LONG
Duration, given in MIDI ticks
pitch BYTE
MIDI pitch (0-127)
velocity BYTE
MIDI velocity (0-127)

Multi-node End Of System EMPTY

Tag ID: 0x19

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.

Multi-node Start Of System EMPTY

Tag ID: 0x1A

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 BYTE

Tag ID: 0x1B

Number of flags on stemmed note.

Number Of Nodes SHORT

Tag ID: 0x1C

Total number of nodes in file for this multi-node symbol. Always present on the first node chunk of any multi-node symbol.

Number of Staff Lines BYTE

Tag ID: 0x1D

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.

Ossia BYTE

Tag ID: 0x1E

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

Part Description Override STRUCT

Tag ID: 0x1F

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.

MIDI channel SIGNEDBYTE
Use -1 to specify none.
MIDI cable SIGNEDBYTE
Use -1 to specify none.
transpose SIGNEDBYTE
Number of halfsteps to transpose this part during playback.

Part ID SHORT

Tag ID: 0x20

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.

Reference Point Override STRUCTURE

Tag ID: 0x21

Description of non-default reference points on the anchor and dependent symbols. Always used in combination with either Absolute Placement or Logical Placement tags.

anchor h BYTE
dependent h BYTE
0 = the symbol's default horizontal reference
1 = left of symbol's bounding box
2 = right of the symbol's bounding box
3 = horizontal center of the symbol's bounding box
anchor v BYTE
dependent v BYTE
0 = the symbol's default vertical reference
1 = top of symbol's bounding box
2 = bottom of the symbol's bounding box
3 = vertical center of the symbol's bounding box

Rehearsal Mark Offset SHORT

Tag ID: 0x22

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.

Rest Numeral SHORT

Tag ID: 0x23

Number that is to appear centered over multiple-measure rest symbol

Silent EMPTY

Tag ID: 0x24

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.

Slashed Stem EMPTY

Tag ID: 0x25

Indicates the presence of a slash on a stem, as in a grace note. For Tremolo slashes, use Tremolo chunk.

Small Size EMPTY

Tag ID: 0x26

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.

Spacing By Part EMPTY

Tag ID: 0x27

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.

Split Stem EMPTY

Tag ID: 0x28

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.

Staff Name EMPTY

Tag ID: 0x29

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).

Staff Step SIGNEDBYTE

Tag ID: 0x2A

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.

Thickness SHORT

Tag ID: 0x2B

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).

Tie Direction BYTE

Tag ID: 0x2C

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

Tuplet Description STRUCT

Tag ID: 0x2D
transformation ratio a b RATIONAL
transformation ratio c d RATIONAL
The four integers in the transformation are applied to the events at each node of the tuplet, as described in Chapter 1, Timing Representation.
grouping symbol BYTE
0 = default
1 = number only
2 = number with broken slur
3 = number outside slur
4 = number inside slur
5 = number with broken bracket
6 = number outside bracket
7 = number inside bracket
8 = bracket only
9 = slur only
10 = no symbol

Number Style BYTE

Tag ID: 0x2E

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

Voice ID SHORT

Tag ID: 0x2F

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.

Width SHORT

Tag ID: 0x30

Horizontal width, in absolute units.

User-Defined

Tag ID: 0xFF

[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."