MID vs MOD - WAS : Re: [linux-audio-dev] ".mid" files playing in Linux games

[Dave Phillips]

Dominic Genest wrote:

>I compare MIDI to the WYMIWYG (what you MEAN is what you get), and MOD or 
>other formats alike to WYSIWYG (what you SEE is what you get).
>
I would say instead that MODs are WYHIWYG (what you HEAR is what you 
get), i.e., it *always* sounds the same because there's no dependency 
upon an external synth and/or patch set.

To me, the great trade-off between MIDI and MOD files has to with space. 
It's not so big a deal anymore if we're talking about net transfers, but 
embedding MOD music might be too weighty for an app (though it certainly 
doesn't have to be: 8-bit samples at 22050 Hz SR might do fine in even a 
lighter weight game). MIDI files are of course extremely light and 
compact, but they are absolutely dependent upon external sound sources.

> It's a bit 
>like the difference between LaTeX and Word. Midi files describe the intention 
>of the composer, not the extension. The one who listens to the music will 
>choose to pay or not for a quality playback. And he might even be able to 
>make it sound better than the composer has ever heard it.
>
I'm not sure MIDI or MOD makes any difference to the composer's 
intention, but the issue of playback quality is crucial here. The MOD 
file includes its sound sources, so it will sound the same every time. 
If the sound quality is critical to an app I'd go with the MOD file. If 
the sound is utterly incidental and can be rendered as well  by an OPL3 
as by TiMidity (and I don't mean "sounds as good as", I'm merely 
referencing implementation), then MIDI is the way to go. However, it's 
also worth noting that in either instance an embedded player is 
required, which in Linux is typically playmidi or TiMidity for MIDI, 
MikMod for MOD files (though there are alternative MOD player libs now).

>I also think MOD files would be better if they were MIDI standards plus 
>patches or something, but I think that MIDI is too much associated, in the 
>minds of people, to cheap FM chips like Yamaha OPL3.
>
I suppose this is true for late-comers to electroacoustic music. Those 
of us "persons of a certain age group" who own a considerable amount of 
external MIDI gear would heartily disagree with your assessment. ;) 
 Btw, you can certainly use a GM patch set as sound sources for MOD, but 
again, the quality of your patch set will be a permanent aspect of the 
audio output.

Another consideration: If the designer wants to use MIDI he must probe 
for either an existing patch set or a hardware MIDI synthesizer, then 
configure itself accordingly (or be configured by a dialog when setting 
up the app).

Someone else wrote:

>>> .mod seems a bit limiting to me... If your samples are too large they
>>>drag a bit, files get huge, etc. I don't think I've actually played one
>>>since about 1994 or so though and that was on my 486/25. :} I could very
>>>well be mistaken.
>>>      
>>>
Umm, yes, considerable innovation throughout the computer industry has 
occurred since then... ;-)

But that message does raise the point: higher quality samples almost 
inevitably require more storage space, so again the question of weight 
is raised. In the end, the real issue is the relative importance of the 
music in the app. If it's incidental tunes or riffs, then it's no big 
deal. Anything more important may in fact run the risk of 
misrepresentation via someone's sub-par MIDI system.

Btw, I find it interesting that so many users identify MIDI with a 
soundcard capability. Of course the spec was designed originally for 
external gear, and that's still my first association. Don't get me 
wrong, I *like* having a MIDI-aware synth on-board my soundcard, but 
I've yet to hear one that can compete with the gear in my rack. 
Processing helps a lot, but it's still tough for a single chip to beat 
what amounts to an entire machine dedicated to digital sound synthesis.

Best,

dp