Make-A-Melody

From Just Solve the File Format Problem
(Difference between revisions)
Jump to: navigation, search
Line 36: Line 36:
 
== Sample files ==
 
== Sample files ==
 
* [http://www.dan.info/sampledata/TEST.MUS TEST.MUS]
 
* [http://www.dan.info/sampledata/TEST.MUS TEST.MUS]
 +
 +
[[Category:Softdisk]]

Revision as of 16:11, 20 April 2013

File Format
Name Make-A-Melody
Ontology
Extension(s) .mus

Make-A-Melody (and its companion program Play-A-Melody) was published on issue #42 of the diskmagazine Big Blue Disk (later Softdisk PC) in 1990. It let users create sequences of notes to be played on the PC's internal speaker, which was about as far from "high-fidelity" as computerized audio could get. Pretty soon afterward, sound cards started being a standard part of PCs, so this was probably one of the last music programs to use the old-fashioned PC speaker (which is still present to this day, beeping at you when you power the machine on).

Song files were saved with a .mus extension, and consisted of a series of 8-byte records which contained four 2-byte little-endian integers. The first record had the headers:

  • Song Counter (number of notes in the song)
  • Duration Counter (number of duration/tempo entries)
  • Durations(1) (first duration entry)
  • Tempos(1) (first tempo entry)

The user was able to set a duration and tempo, and all notes added to the song were stored in the current duration/tempo until it was changed. Multiple duration/tempo pairs were stored in an array, which then was supposed to be saved in successive records of the file starting with the second one (two to a record), so record #2 would be like this (records and arrays were numbered starting with 1, not 0 like in C):

  • Durations(2)
  • Tempos(2)
  • Durations(3)
  • Tempos(3)

However, due to a bug in the program, these duration/tempo entries got saved to the wrong records of the disk file (which was opened for writing/reading as random-access), so instead of records 2, 3, 4, ... they instead went to records 3, 5, 7, ... (a variable should have been divided by two when computing the record number to write; why the programmer didn't just use a sequential file and write them in order is unknown). Then the subsequent note records (noted below) were written to the record numbers they should have had if the durations/tempos were stored where they were supposed to be, meaning that many of the duration/tempo records then got overwritten and weren't retained correctly. Thus, the program really only functioned correctly if you used only one duration and tempo for the entire song.

Anyway, the rest of the file consisted of one record per note:

  • Octave
  • Note or Rest Time
  • Note
  • Index number to duration/tempo record of note

The note or rest time consisted of a number selecting between various possibilities (half note, half rest, etc.), where values over 10 corresponded to rests and lower values to notes.

The note was a number, where each of the possible notes (including sharps/flats) had a numeric value, and the octaves were also numbered.

Sample files

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox