Design and implementation of embedded MIDI file format parsing

1 Introduction

With the development of computer and electronic science, the traditional way of reading is undergoing earth-shaking changes. In the field of music, due to the disadvantages of paper music scores, such as being difficult to store, find and carry, and inconvenient to turn pages, many composers use composition software to create music and score-writing software to generate music scores; however, although there are many software for making music and generating music scores, there are few corresponding software and hardware devices for reading music scores. Since there is no feasible way to display the music scores, performers must print the digitized music scores on paper, which shows that the digitization work in the field of music is not thorough.

In order to expand the existing music digitization work to the reading of music scores and overcome the shortcomings of paper music scores themselves, it is undoubtedly a good choice to design a cross-platform, portable, user-friendly electronic music score reader and use an embedded reading system to replace the traditional combination of paper music scores and music stands.

The electronic music scores available at present can be divided into two types, one is based on the image format, and the other is based on the digital music format. The former mainly includes image formats such as jpg and gif, as well as document formats such as pdf and chm that are mainly composed of images, which are not the focus of this article; the latter mainly includes MIDI file formats and special formats used by some music notation software. There are many commonly used music notation software, but they belong to different companies and use different and non-public formats. This article will focus on how to support the display of public and standardized MIDI file formats.

2 System Analysis

Figure 1 is a part of a simple five-line staff, which has two voices, each voice corresponds to a set of five lines. There are various marks on the five-line staff, indicating various properties of the five-line staff.

The objects of attribute action include: music score, voice part, music passage spanning multiple voice parts, music passage spanning single voice part and notes, etc. From the perspective of the method of attribute action, attributes can be divided into several categories: some attributes are reflected by the horizontal or vertical position of the symbol, and some attributes are reflected by the shape change of the symbol.

In some cases, the same attribute must appear consistently in many different places on the stave, for example, the key and time signatures of different voices must be the same when the number of measures is the same, and must be marked separately in each voice. In addition, some attributes are not directly represented in the form of symbols on the score, but act on other attributes, and people can infer them based on the changes of other attributes.

In order to describe the complex structure of the five-line staff, and considering the simplicity of the structure and the convenience of drawing this data structure on the screen, this paper establishes the following classes: Staff class describes a five-line staff, Track class describes a voice, Measure class describes a measure, Notation class is the base class of all symbols, Note, Chord, Noteblock, Rest, Tie respectively describe a single note, chord, note group, rest, tie and other symbols. Figure 2 intuitively describes the relationship between classes.

Figure 2 Organization of stave data structure

Considering that the measures with the same measure number in different parts of the stave have many consistent properties, in order to reduce redundancy and facilitate program calls, this paper sets up a virtual part without notes for the stave class to save the common measure information in the actual part. The measure in the virtual part is declared as a VMeasure class, and the Measure class of each part saves a pointer to the corresponding VMeasure class to facilitate the acquisition of measure information. Figure 3 shows the structure of the virtual part in the stave class.

3 MIDI file format analysis

MIDI (Musical Instrument Digital Interface) is an international standard for digital music. It defines the way computer music programs, synthesizers and other electronic devices exchange information and electronic signals, and solves the incompatibility problem between different electronic instruments. MIDI files contain notes, timing and performance definitions for up to 16 channels. The file includes the performance note information for each channel: key channel number, note length, volume and intensity, etc. Since MIDI files are a series of instructions rather than waveforms, they require very little disk space. In addition, the editing and modification of MIDI data is very flexible, and you can easily add or delete a note, or change the properties of a note. [page]

3.1 Format Description

The data in a MIDI file is divided into several chunks, which are composed of a chunk tag, a chunk length, and chunk data. The chunk tag is a 4-byte ACSII code, and the chunk length is a 4-byte value, indicating the length of the chunk data field, as shown in Table 1.

Table 1 MIDI file composition

3.2 Structure and parsing process of MIDI file format parsing module

Since the tasks that the MIDI file format parsing module needs to complete mainly include understanding MIDI information, analyzing MIDI information, and generating five-line score information, the MIDI file parsing can be divided into two major parts. The first part is called the file analyzer, which is mainly responsible for reading the MIDI file in sequence, separating and storing each data component separately, completing the bottom-level file-oriented data reading and error handling, and ensuring that the upper layer is provided with complete, correct, and orderly arranged note information. The second part is called the integrated analyzer, which is mainly responsible for selectively using the original information obtained from the MIDI file by the file analyzer, referring to a series of rules, finding the combination relationship between the notes, and generating the logical content of the five-line score. The overall structure and processing flow are shown in Figure 4.

3.2.1 File Analyzer

The header block indicates the MIDI file type, the number of tracks, and the number of quarter note time increments. Parsing the header block is relatively simple, but the file type and quarter note time increments have a great impact on the parsing process.

Different MIDI file types have different internal complexity. However, the three types of MIDI files have increasing complexity, and the former type can always be regarded as a special case of the latter type. Therefore, as long as various processing is done for the most complex type 2, the relatively simple types 0 and 1 can be supported with only slight modifications.

MIDI files generally set the time increment of a quarter note to 120, but MIDI files also support changing this value. Since this is rare in actual applications, the complexity of parsing can be reduced by converting it to 120 without affecting the correctness.

Reading MIDI events

There are many types of MIDI messages, and there is no unified format, which means that each message can only be processed separately. Fortunately, not all MIDI messages are related to the five-line staff, so there are actually not many MIDI messages that need to be truly understood. The most common message is the note-on message (Note-On), which actually accounts for more than 95% of the total usage of all messages. The note-off message (Note-Off) must also be processed. If this message is not processed, it will cause sound leakage (the open note has no corresponding closing signal and remains open).

Since there is no concept of notes in MIDI, a note is formed by pairing corresponding note on and off events, called a raw note. Then the note start timestamp and end timestamp need to be converted into a note start timestamp and note duration.

In order to complete the above two tasks, a large array is used to cache the status of 128 notes in 16 channels. When the note on and off messages are received, they are recorded and the start time and duration are calculated at the same time.

Reading Meta Events

The information described in the Meta event in MIDI is basically useful in the stave display, and some of it plays a vital role. For example, many explanatory text information needs to be directly added to the properties of the stave and each track. When these explanatory information appear repeatedly, the text of the two pieces of information can be connected to appear as a long message.

Key signature and time signature are two very important pieces of Meta information. Key signature determines the exact position of each note on the stave and its sharp and flat signs. Time signature determines the length of the measure and also affects the rules of synthesized note groups. These are all important information that are indispensable for integrated analyzers.

3.2.2 Integrated Analyzer

The file analyzer can only read the notes directly described in the MIDI file. If such notes are displayed directly, the resulting five-line score will be very ugly. The task of the integrated analyzer is to receive the original note table and other information such as time signature and key signature, arrange and reorganize them, and generate a correct and beautiful five-line score. Since there is a lot of information to be analyzed, this section only lists some relatively important tasks.

Determine the clef

The Meta information only provides information about the key and time signatures, but not the equally important clef information. Since many tasks in the integrated analyzer require the use of clef information, the statistical work on the notes must be completed before entering the integrated analyzer, that is, the statistical work on the notes must be inserted into the file analyzer. [page]

To determine the clef, you need to count the pitches of the highest and lowest notes in the track. Once you have these two values, you can decide whether to use the bass clef or the treble clef. If the difference between the highest and lowest notes is so great that neither the bass clef nor the treble clef can meet the requirements, you can consider splitting the track into two five-line displays.

Add a rest

Rests are as important as notes in the five-line staff, but in the original note table there are only real notes but no rests. A rest means that there is no sound on the track within a certain time range, so you can determine whether there is a rest by monitoring the sound state matrix in the file analyzer.

Measure division and note splitting and combination

The bar division in the five-line staff has two functions for display: facilitating the alignment of the upper and lower synchronous parts of the music score and keeping the end aligned when wrapping. Since the original note may belong to a bar completely or span several bars, it is necessary to split the note into multiple small notes and connect them with a tie mark, or combine several notes in a bar to form a chord or a group of co-ending notes. Figure 5 shows a relatively simple case where three notes are split and combined into two chords.

To complete this part of the work, the original note table needs to be converted into an ordered stack. The characteristics of an ordered stack ensure that although each note may be inserted repeatedly, the number of insertions has nothing to do with the overall stack size, but only with the complexity of the note. When the complexity of the note is constant, the number of times each stack element is repeatedly operated is close to a constant, so the overall function remains at the nlog(n) level, which is acceptable.

In order to reduce the amount of calculation, we can use the co-ending note group containing only one chord and the chord containing only one note to unify the comparison between various symbols, and merge the 3x3=9 steps of comparison into two steps, which reduces the cost of comparison and greatly reduces the amount of code. Another optimization is to use an ordered stack to reduce the time complexity to nlog(n).

Figure 6 shows the display effect of the MIDI file. Due to space limitations, this article will not provide a more detailed explanation of the format analysis of multiple notes, appoggiaturas, and ornaments.

4 Summary and Outlook

The embedded development platform of the electronic sheet music reader discussed in this paper adopts the ECX platform based on Celeron-M, and the display module adopts the QT development framework under the Linux platform. Practice has proved that the analysis method discussed in this paper is completely feasible and the system running speed is also satisfactory.

With the popularization of computers and embedded systems, people's lifestyles are undergoing tremendous changes. Although the embedded music score reader mentioned in this article has not yet become a product, it is bound to replace the existing paper music scores. In addition, this system currently only has a reading function, and a music playback function can be added, so that the five-line music score can be learned, which is a very good assistant for students who are in the learning stage.

Innovation of the author of this article: The research conducted in this article fills the last link of the digitalization of music scores - digital reading. Although there are various music score software, composition software, and playback software, performers currently do not have a suitable reader. This article attempts to display digital music scores to performers through embedded reading devices, replacing traditional bulky paper scores, greatly reducing the burden on performers. At the same time, there are a large number of MIDI format files on the Internet, but there are few files in the five-line format and the format is not public, which requires expensive professional software. This system can directly convert it into five-line score reading, which provides convenience for users' learning work.

References:

[1] Yuan Huimei, Song Yu. Design of MIDI music player based on CPLD[J]. Microcomputer Information, 2006, 11: 143-145

[2] Basic Music Theory, Li Chongguang, Higher Education Press, January 2000

[3]MIDITrans - A MIDI File Transform Language Roger T.Hartley,1998

[4]Standard MIDI File(SMF) Format ,MIDI Manufacturer's Association,1999

[5]MIDI Specification version1.0, MIDI Manufacturer's Association,1999

[6]General MIDI Level 1, MIDI Manufacturer's Association,1999