Difference between revisions of "MUS (Electronic Arts)"

From Video Game Music Preservation Foundation Wiki
Jump to: navigation, search
(update note on pitch-bender)
m
Line 64: Line 64:
 
* The file begins with a 16-bit integer that describes the start of the song (and also the start of loop), relative to the beginning of the file. Commonly observed values include 0x007D and 0x007F.
 
* The file begins with a 16-bit integer that describes the start of the song (and also the start of loop), relative to the beginning of the file. Commonly observed values include 0x007D and 0x007F.
 
* At offset 0x22, there is a 9-byte table that is used in AdLib playback only: It describes for each of the nine AdLib channels, which MIDI channel will be exclusively played on this channel. The value 9 indicates the MIDI percussion channel, and it may only appear in the last 5 channels.
 
* At offset 0x22, there is a 9-byte table that is used in AdLib playback only: It describes for each of the nine AdLib channels, which MIDI channel will be exclusively played on this channel. The value 9 indicates the MIDI percussion channel, and it may only appear in the last 5 channels.
* Other bytes in the file header are probably used for various purposes when playing using the other sound drivers, such as the PC speaker.
+
* Other bytes in the file header are probably used for various purposes when playing using the other sound drivers, such as the Roland MT32.
 
* Each header contains a string similar to 'rsxx}u'. The purpose of this data is unknown.
 
* Each header contains a string similar to 'rsxx}u'. The purpose of this data is unknown.
 
* The actual song data is in [[MIDI]] MTrk format, so it's easy to convert it to standard MIDI file, though it may require to set correct pitch bend sensitivity using RPM events.
 
* The actual song data is in [[MIDI]] MTrk format, so it's easy to convert it to standard MIDI file, though it may require to set correct pitch bend sensitivity using RPM events.
 
** The delta-times in the song are always shorter than 0x80 (meaning the MIDI variable-length delay is not used), and they indicate the number of frames to idle before the next event.
 
** The delta-times in the song are always shorter than 0x80 (meaning the MIDI variable-length delay is not used), and they indicate the number of frames to idle before the next event.
 
** Supported event types include 0xC0 (patch change), 0x80 (note off), 0x90 (note on), and 0xE0 (pitch bend).
 
** Supported event types include 0xC0 (patch change), 0x80 (note off), 0x90 (note on), and 0xE0 (pitch bend).
*** Running status is supported, as is the shortcut of turning note off by issuing a zero-volume note-on event, or after-touching the note volume by issuing a second note on at the same channel for the same note.
+
** Running status is supported, as is the shortcut of turning note off by issuing a zero-volume note-on event, or after-touching the note volume by issuing a second note on at the same channel for the same note.
*** Pitch-bender affects immediately all currently keyed-on notes on the specified channel, but the effect will not persist, i.e. new key-ons ignore the pitch-bender.
+
** Note touch command (0xA0), controller change command (0xB0), channel after-touch command (0xD0), and any other 0xFx commands than 0xFC are not supported. They are treated as 3-byte commands and skipped as such (which is incorrect for 0xD0).
* The last event in the file is always 'FC'. This event is followed by either byte 80 or 81. Byte 80 indicates the song restarts (loops) from beginning, and any other byte means the song ends there.
+
**
 +
 
 +
** Pitch-bender affects immediately all currently keyed-on notes on the specified channel, but the effect will not persist, i.e. new key-ons ignore the pitch-bender.
 +
* The last event in the file is always 0xFC. This event is followed by either byte 0x80 or 0x81. Byte 0x80 indicates the song restarts (loops) from beginning, and any other byte means the song ends there.
  
 
===Game Differences===
 
===Game Differences===

Revision as of 01:43, 13 July 2017

MUS (Electronic Arts)
MUS (Electronic Arts).png
Developer: Electronic Arts, Inc.
Header: Custom
Content: Notational
Instruments: Unknown
Target Output
Output - Digital Audio - No.png Output - MIDI.png Output - FM Synthesis.png Output - PSG.png
Released: 1989-??-??
First Game: Cartooners (DOS)
Extensions
  • *.mus

This music format was used by Electronic Arts form 1989 to 1992. Below is technical specs on the format so that programmers may write a player for the format.

This music format uses the extension *.mus in "Cartooners" and the "Lost Files of Sherlock Holmes", but "Ski or Die" and "The Immortal" use a generic *.bin extension.

The MT-32 driver of "Lost Files of Sherlock Holmes" actually mentions "Ski or Die", by name, inside of it, probably from reused code.


Players

It appears that Joel Yliluoma (Bisqwit) managed to figure out how to play these music files: [1]. The page containing the source for this player: [2].


EAPlay: [3]


Converters

(Category)

MUS to ?

? to MUS

Games

(Category)
Released Title Sample
1989-??-?? Cartooners (DOS)
1990-??-?? Ski or Die (DOS)
1991-??-?? The Immortal (DOS)
1992-??-?? The Lost Files of Sherlock Holmes: The Case of the Serrated Scalpel (DOS)

Technical

  • The file begins with a 16-bit integer that describes the start of the song (and also the start of loop), relative to the beginning of the file. Commonly observed values include 0x007D and 0x007F.
  • At offset 0x22, there is a 9-byte table that is used in AdLib playback only: It describes for each of the nine AdLib channels, which MIDI channel will be exclusively played on this channel. The value 9 indicates the MIDI percussion channel, and it may only appear in the last 5 channels.
  • Other bytes in the file header are probably used for various purposes when playing using the other sound drivers, such as the Roland MT32.
  • Each header contains a string similar to 'rsxx}u'. The purpose of this data is unknown.
  • The actual song data is in MIDI MTrk format, so it's easy to convert it to standard MIDI file, though it may require to set correct pitch bend sensitivity using RPM events.
    • The delta-times in the song are always shorter than 0x80 (meaning the MIDI variable-length delay is not used), and they indicate the number of frames to idle before the next event.
    • Supported event types include 0xC0 (patch change), 0x80 (note off), 0x90 (note on), and 0xE0 (pitch bend).
    • Running status is supported, as is the shortcut of turning note off by issuing a zero-volume note-on event, or after-touching the note volume by issuing a second note on at the same channel for the same note.
    • Note touch command (0xA0), controller change command (0xB0), channel after-touch command (0xD0), and any other 0xFx commands than 0xFC are not supported. They are treated as 3-byte commands and skipped as such (which is incorrect for 0xD0).
    • Pitch-bender affects immediately all currently keyed-on notes on the specified channel, but the effect will not persist, i.e. new key-ons ignore the pitch-bender.
  • The last event in the file is always 0xFC. This event is followed by either byte 0x80 or 0x81. Byte 0x80 indicates the song restarts (loops) from beginning, and any other byte means the song ends there.

Game Differences

The MUS files from The Lost Files of Sherlock Holmes begin with 12 spaces (0x20) before the '7F 00 00 01' string.

"The Immortal" has a completely different header and data style. Perhaps it's compressed?

At 0x13 a different type of header data begins.

In the Cartooners the string 'rsxx}u' starts at 0x6D. In Ski or Die and Sherlock it begins at 0x6F.

"The Immortal" begins this string at 0x49, but the 'rsx' and 'x}u' are separated with 0xE7.

There are then 10 null bytes, and then the data begins.

Once again, "The Immortal" has a different style to it. Also, "Ski or Die" is formatted a little differently.

Links