Project Structure

An Audiveris project gathers all OMR information related to a given Book, including the contained Sheet instances.

This project can be stored to disk as a project file and reloaded later. The project file is merely the result of the XML marshalling of a book and its sheets, so there is no logical difference in the project structure in memory and on disk.

The internal project structure is specific to Audiveris software, but it is not opaque and is meant for public access, either via Audiveris API or by direct extraction of project XML fragments.

Project structure will be further described below, following the concrete structure of a project file.

##Project file

An Audiveris project file (a file with a ".omr" extension), dedicated to one Book hierarchy, is nothing more than a Zip archive whose content can be easily browsed (and even modified -- at your own risk!...) via any Zip reader or editor.

Its structure is a sequence of 3 kinds of XML files as follows:

File Name	Content
book.xml	The skeleton of book hierarchy
sheet#N/	Specific folder for sheet #N
sheet#N/BINARY.xml	Run table of binarized image of sheet #N
sheet#N/HEAD_SPOTS.xml	Run table of head spots for sheet #N
sheet#N/sheet#N.xml	OMR details for sheet #N

The HEAD_SPOTS run table is a temporary information carried over from BEAMS step to HEADS step. It takes advantage of the image processing performed during the BEAMS step to provide the image areas (spots) where black heads are likely to be recognized. This data is discarded at end of HEADS step.

##Memory constraint

To be able to handle books with more than a few sheets, we keep book-related top data in memory, while sheet "details" are loaded only when they are really needed. In terms of Audiveris project file, this means that just the book.xml part is kept in memory, while the various sheet#N/BINARY.xml and sheet#N/sheet#N.xml are loaded on demand.

So, the physical and logical containments are implemented as follows: (see Containers)

• A Book does not directly contain Sheet's but only a sequence of SheetStub instances (or Stub for short) with a one-to-one relationship between SheetStub and Sheet.
• In a similar manner, a Score actually contains PageRef instances which refer to Page's.

In the following class diagram, physical entities are displayed in blue, and logical entities in yellow.

On the left side, the "book.xml" artifact represents the content of the book.xml part within an Audiveris project file, and is kept in memory. Note that the Score and PageRef instances can exist only when GRID step has been reached on (some sheets of) the book.

On the right side, the "sheet#N.xml" artifact represents one sheet (perhaps among others), pointed to from book.xml, and is not necessarily in memory.

[Just to avoid endless clashes with Java predefined System class, we have chosen SystemInfo as the class name to represent a music system]