NIFF 6a.2
Notation Interchange File Format
8/20/98


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

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


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 date of 
publication of this specification, a European Community music library project 
currently underway will result in a bridge between SMDL and NIFF.]

A general strategy was chosen as follows: model NIFF's feature set on Score's, 
organize the data as systematically as possible, and use the most current file 
format conventions.  During the development of the format, additional more 
specific goals have been established.  Some useful functional features of DARMS 
have been incorporated as well.

The NIFF structure can accommodate full music publishing systems, simpler music 
display systems, logical definition languages like DARMS, and music scanning 
programs.  Even sequencers can be writers of NIFF files, since the most 
rudimentary NIFF file has little more notation information than a MIDI file.

NIFF allows representation of the most common situations occurring in 
conventional music notation, while making provision for software developers to 
define their own extensions to handle the more unusual situations.  It allows 
inclusion of Encapsulated PostScript (EPS) files and fonts to allow interchange 
of features not otherwise defined in the format. 


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

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.

  Score.  Each NIFF file contains one score.  A score could hold anything from 
a one bar music example, to a song, a piano sonata movement, or a movement of a 
symphony in full score.  A work in more than one movement would normally be 
stored with each movement in its own NIFF file.

  Part.  A stream of musical events and associated symbols, text and graphics 
which can be extracted and printed on a part score for an individual performer.  
A part may contain music to be played sequentially on different related 
instruments by the same performer (e.g. oboe/English horn).  The maximum number 
of staves used for display is defined for each part. 

  Voice.  A rhythmically independent stream of musical events within a part, 
and its associated symbols, text and graphics.  Voices can appear and disappear 
at any time within a part.  

  System.  The visual framework on a page, where symbols representing 
simultaneous events in the various parts are more or less vertically aligned.  
All parts of the score are logically present in every system although some may 
be "hidden."

  Staff.  An arrangement of parallel horizontal lines serving as the locale for 
displaying musical symbols.  It is a sort of vessel within a system into which 
musical symbols can be "poured."  Displayed on it are music symbols, text and 
graphics belonging to one or more parts.  

  Time-Slice.  The mechanism by which a specific point in time is identified in 
the score.  Musical symbols representing simultaneous events.are logically 
grouped within the same time-slice.  The music symbols in a NIFF file are 
physically grouped by page and staff, so symbols belonging to a common logical 
time-slice may be physically separated in the file.  Horizontal placement can 
optionally be supplied for a time-slice.

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

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 
clocks, which denote some fixed amount of time using an integer.  MIDI clocks 
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 clocks 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 clocks from the grace note's logical start time.  Other tags that 
might be found on a grace note's Notehead or Stem chunk include the Slash tag, 
Small Size tag, and the Absolute Placement tag (with a negative value) 
indicating a negative horizontal offset from the time-slice.

In the following example, the grace note's time value is subtracted from the 
preceding note during performance, as in Chopin or Liszt.  However, the duration 
field on the preceding Notehead chunk is not modified to compensate for the 
grace note.  The start time on the Grace Note tag gives a negative offset of 
1/32 from its time slice, which can be used by the reading program during 
playback.



Time-slice, type=event,start-time=0/4
Stem
Notehead, shape=filled, staff step=0, duration=1/4
Time-slice, type=event, start-time=1/4
Stem, Number of Flags=1, Slashed Stem, Small Size, Grace Note=-1/32
Notehead, shape=filled, staff step=2, duration=1/32
Stem
Notehead, shape=filled, staff step=1, duration=1/4

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			

BYTE 	a 1 byte unsigned integer
SIGNEDBYTE	a 1 byte signed integer
CHAR	a 1 byte character value
SHORT	a 2 byte signed integer
LONG	a 4 byte signed integer
FOURCC	a 4 byte ASCII character value. 
RATIONAL 	2 2 byte signed integers (numerator and denominator)
STROFFSET	a 2 byte signed integer pointing to a RIFF ZSTR in the String Table 
chunk in the Setup Section.  A RIFF ZSTR is a series of ASCII characters 
followed by a terminating null.  -1 means a null pointer. Embedded zero bytes 
are not allowed within a ZSTR.
FONTPTR	a 2 byte pointer to a Font Description chunk in the Font 
Descriptions list.
EMPTY	0 bytes.  This is used for chunk types for which there are no required 
elements, and tags whose full meaning is conveyed by the tag ID.


N.B.	Time did not permit full development of an International String Table in 
time for NIFF 6a.  This would be a Setup Section chunk that would allow 
character strings to be stored for fonts that require two bytes for each 
character code, such as Chinese, Japanese, or Korean.   An associated data type 
would be required to reference strings in this table, as well as an 
International Text chunk containing a field with this data type. Other 
enhancements to the format to make use of this feature have not been fully 
investigated.  It is possible that this feature could be developed in the 
future.

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 clocks 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 FONTPTR data type.  

The FONTPTR 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.  FONTPTR 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, FONTPTR 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 
clocks.  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 clocks, 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.

					
		Diagram A1				Diagram A2

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.


Diagram B


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:


Diagram C

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.

        
Diagram D [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:

 When the reading program does not have access to the music font specified by 
the writing program, use of absolute measurements could result in overlapping or 
incorrect alignment of symbols.  

 When the reading program has no concept of page layout, absolute positioning 
would either be discarded or used only for its logical placement implications.  

 In some cases, the user may simply not care to retain the details of the 
writing program's symbol placement, preferring a default layout by the reading 
program instead.

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.
		 
		Diagram D
	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
	Data Section
		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

	Location:	NIFF form
	Required:	NIFF Information chunk
		Chunk Length Table chunk
		Parts list
	Optional:	RIFF INFO list (RIFF standard "INFO" list)
		String Table chunk
		Staff Groupings list
		Default Values chunk
		Font Descriptions list
		Custom Graphics list


Parts	LIST

	Location:	Setup Section list
	Required:	Any number of Part Description chunks.

RIFF INFO	LIST

	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.

	IART 	artist - the composer of the score
	ICOP 	copyright
	ICRD 	creation date of the file
	IDIM 	dimensions of each page
	IDPI 	dots per inch
	ENG 	engineer - editor, or person responsible for the notation's 
appearance
	IGNR 	genre - orchestral, jazz, pop song, classical piano, string quartet, 
theory example, etc.
	INAM 	name - name of score
	ISFT	software - name of writing program
	ISRF 	source form - previous data format, such as paper, MIDI file, 
synthesizer keyboard entry, etc.
	ITCH 	technician - person operating software at time of output to NIFF 
file


Staff Groupings	LIST

	Location:	Setup Section list

		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.  

	Location:	Setup Section list or Data Section list
	Required:	Any number of Staff Grouping Description chunks

		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

	Location:	Setup Section list
	Required:	Any number of Font Description chunks.

	Comment:	The FONTPTR data type is a pointer into this list. A value of 
0 points to the first Font Description chunk in the list.

Custom Graphics	LIST

	Location:	Setup Section list
	Required:	Any number of the following, in any order:

		PostScript Type 1 Font chunk
		PostScript Type 3 Font chunk
		EPS Graphic chunk


Data Section	LIST

	Location:	NIFF form
	Required:	nothing
	Optional:	Any number of Page lists


Page	LIST

	Location:	Data Section list
	Required:	Page Header list
	Optional:	Any number of the following, in any order:
		System list
		NIFF Font Symbol chunk
		Custom Graphic Symbol chunk
		Text chunk
		Line chunk

System	LIST

	Location:	Page list
	Required:	System Header chunk
	Optional:	Staff Grouping list
		Any number of the following, in any order:
		Staff list
		NIFF Font Symbol chunk
		Custom Graphic Symbol chunk
		Text chunk
		Line chunk

Staff	LIST

		
	Location:	System list
	Required:	Staff Header chunk
	Optional:	Any number of the following, in order as appropriate:
		Time-Slice chunk
		Any music symbol chunk
		NIFF Font Symbol chunk
		Custom Shape Graphic chunk
		Text chunk
		Line chunk


Chunks
in alphabetical order

Setup Section

Chunk Length Table	CHUNK

	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

	Location:	Setup Section list

	music font	FONTPTR

	part name font	FONTPTR

		Used as the default font for part name and abbreviation.   See 
General Discussion of Part and Staff Names for details.

	lyric font	FONTPTR

	chord symbol font	FONTPTR

	measure number font	FONTPTR
	
	rehearsal mark font	FONTPTR

	tuplet grouping symbol
		BYTE

		See Tuplet Description tag for values.  

	tuplet number style	BYTE

		See Tuplet Description tag for values. 

EPS Graphic

	Location:	Setup Section, Custom Graphics list

		CHUNK

		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

	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

	Location:	Setup Section list

		General information required to interpret values in the file.

	NIF Version	char[8]

		6a

	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 clocks per quarter
		SHORT

		MIDI clocks 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

	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

	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

	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

	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

		1-32767.  Staff ID of first staff in grouping. See note below.

	last staff	SHORT

		1-32767.  System Staff ID of last staff in grouping.  See now 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

	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

Header Chunks

Page Header	CHUNK

		EMPTY

	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.

	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

	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

	Default anchor: 	Previous measure-start time-slice, or staff origin (for 
first time-slice in a staff)
	Reference point:	Bottom staff line at its intersection with the time-
slice.

Symbol Chunks


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

	Default anchor:	Notehead
	Reference point:	Hot-spot of symbol.  See Diagram XX.
	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.
	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

	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.

	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

		For the reference point when the anchor is a  rest symbol, see table 
(Diagram XX from Read pg. 96)

	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.

	Default anchor:	Time-slice
	Reference point:	Vertical: staff origin.  Horizontal: center of barline.
	Tags:	Thickness, 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

	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)



	Default anchor:	Stem
	Reference pt:	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

	Default anchor:	Time-slice
	Reference point:	Vertical:  clef hot spot (See Diagram XX).  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.

	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.

	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

	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

	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.

	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)

	Default anchor:	Event Time-Slice
	Reference pt:	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.

	Default anchor:	Notehead
	Reference pt:	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.

	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
			

	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.

	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.

	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. 

	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. 

	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	FONTPTR

		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

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

	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.

	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

	Default anchor:	Time-slice
	Default reference pt:	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"

	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 9, 10, 11) are multi-node, anchored to the start and end anchors 
of the trill. 
	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.

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

	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.

	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

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

	Default Anchor:	Time-slice
	Reference pt:	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 11)
		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


	Default anchor:	Time-slice (event type)
	Reference point:	Hot spot of rest - see Diagram XX.

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.

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

	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.

		BYTE

		1 = placed at left margin
		2 = placed at right margin

	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.

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.

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

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

	Default anchor:	Time-slice (most recent one of either type)
	Default 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.
 
	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. 

	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.


	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


	Default anchor:	Time-slice
	Default 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).

	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.  TheTuplet Description tag is 
required on the first node.

	Default anchor:	Stem
	Tags:	Tuplet Description, multi-node symbol tags


Tags
in alphabetical order


Absolute Placement	STRUCTURE

	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 Offset Placement are mutually exclusive.


Alternate Ending	BYTE

		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

		Contains the chunk typeof the non-default anchor symbol.


Articulation Direction	BYTE

		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

		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, ID=2, Absolute Placement = (H6, V6), Bezier Incoming = 
(H7, V7)

Bezier Outgoing	STRUCT

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

		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

		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	FONTPTR

	character code	char[2]

Custom Graphic	SHORT

		Used when a custom graphic is to be used in place of the standard 
appearance of the music symbol. 

	value	SHORT

		The index into the Custom Graphic list of an EPS Graphic chunk 
containing a description of the graphic symbol.


End Of System	EMPTY

		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

		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

		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	FONTPTR

		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

		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

		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

		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

		Vertical height, in absolute units.

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

Invisible	EMPTY

		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

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

Line Quality	BYTE

		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

		Non-default horizontal and vertical logical placement of the 
dependent symbol's reference point relative to the anchor's reference point.  

		Logical Placement and Offset 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

		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

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

	start time	RATIONAL

		Start time, given in MIDI clocks, as an offset from the time-slice


	duration	RATIONAL

		Duration, given in MIDI clocks

	pitch	BYTE

		MIDI pitch (0-127)

	velocity	BYTE

		MIDI velocity (0-127)

	
Multi-node End Of System
		EMPTY

		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

		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

		Number of flags on stemmed note.


Number Of Nodes	SHORT

		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

		Non-default number of lines in a staff, used on the Staff Header.  
The default number is 5. This should be used for guitar tablature, with a value 
of 6, and for percussion parts, with a value of 1.

Ossia	BYTE

		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

		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

		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

		Description of non-default reference points on the anchor and 
dependent symbols.  Always used in combination with either Offset 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

		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

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

Silent	EMPTY

		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

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


Small Size	EMPTY

		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

		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

		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

		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

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

		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

		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

	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

Voice ID	SHORT

		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

		Horizontal width, in absolute units.





1
NIFF 6a.1   Chapter 1 - General Discussion

47
NIFF 6a   Chapter 3   Elements and Values

68
NIFF 6a   Chapter 3 - Elements and Values


