I just wanted to record some MIDI...

[MusicallyInspired]

You could just calculate the 4% difference and change the tempo to compensate.

In SCI Viewer? How?

No, in a MIDI sequencer/editor on the resulting MIDI file output. Lots of free options. Anvil Studio, MIDI Editor, and the DAW I use, Cakewalk Bandlab.

[AGKorson]

Who is Ravi Iyengar?

Looking at his comments, I see now that the data are already in MIDI format. OMG, it's been 15+ years since I studied MIDI when I was looking at AGI sounds! I didn't recognize it at first.

The actual music is stored in a series of events. The generic form for an event is:

<delta time> [byte - status] [byte - p1 [p2]]

Delta time is the number of ticks to wait after executing the previous event before executing this event. Ticks occur at 60 Hz. The delta time value is usually a single byte. However, longer delays can be produced by using F8h any number of times before the delta time value. Each F8h byte causes a delay of 240 ticks before continuing playback. For example, the sequence F8 F8 78 FC waits 600 ticks then stops the sequence because of the FCh status. The fact that F8h waits F0h ticks makes me think that E9h is the largest technically allowable delta time.

The number of ticks per second is defined by the MIDI header, and can be any number. Do all SCI MIDI sounds use the same value of 60 Hz? It sounds like that's Ravi's assumption. Unless there's a definitive specification statement from Sierra saying that's true, it's probably not wise to just assume it's so. Should be easy enough to confirm for any given sound resource though.

Also, Ravi is incorrect in how he's interpreting delta time. Delta time is passed as a 'variable-length' value, meaning it can be 1,2,3 or more bytes long depending on how large the time value is. The value is broken up into 7-bit chunks; each chunk is passed as a byte, with the most significant bit set to indicate that there is another chunk to follow. The last chunk has its most significant bit cleared. To actually get 600 ticks, the bytes passed would be  0x84, 0x58. His example of 0xF8, 0xF8, 0x78 would actually give a delta time of 1,981,560 ticks.

Again, that's assuming the data are really in true MIDI format. If so, then based on Ravi's explanation of track events, I still wonder if the tools are converting the sound data correctly.

[OmerMor]

Who is Ravi Iyengar?

Ravi is one of the pioneering SCI researchers who participated in the FreeSCI project. His main focus was SCI sound.
Here's his website: http://rarefied.org/sci/

[Kawa]

For your consideration, here's the points jingle from The Dating Pool with the SMF header removed, so starting right after the length for the MTrk:

Code: [Select]

00 FF 58 04 04 02 18 08 00 FF 59 02 00 00 00 FF
51 03 07 A1 20 00 B1 79 00 00 C1 09 00 B1 07 7F
00 0A 40 00 5B 00 00 5D 00 00 FF 21 01 00 00 91
5B 64 5F 5B 00 01 56 64 5F 56 00 01 5D 64 5F 5D
00 01 5F 64 5F 5F 00 01 FF 2F

And here's the same jingle as an SCI Sound resource, with a bunch of things at the start removed so it lines up with the SMF:

Code: [Select]

00 19 00 3A 00 FF 0C 00 00 19 00 3A 00 FF FF 01
00 00 C1 00 00 B1 07 7F 00 0A 40 00 79 00 00 C1
09 00 B1 07 7F 00 0A 40 00 5B 00 00 5D 00 00 91
5B 64 06 5B 00 00 56 64 06 56 00 00 5D 64 06 5D
00 00 5F 64 06 5F 00 00 FC

The following bytes are a match:

Code: [Select]

00 __ __ __ __ __ __ __ 00 __ _ __ 00 __ __ __
__ __ __ __ __ __ __ __ 00 __ __ __ __ __ __ __
__ __ __ __ __ 00 __ __ 00 __ __ __ __ 00 00 91
5B 64 __ 5B 00 __ 56 64 __ 56 00 __ 5D 64 __ 5D
00 __ 5F 64 __ 5F 00 __ __ __

Now, that final FF 2F/FC pair is easy: FF 2F is how SMF ends a track, and FC is how SCI stops a track. So that kinda disproves that the track data is "just" SMF with a different wrapper in my book. The first 91, at the third line, is a note on event, pitch 0x5B, velocity 0x64. Running Status means the next event is to play 0x5B with velocity 0x00, simulating a note off. Skip another delta byte, we play a running-status note-on pitch 0x56, and so on to 0x5D, 0x5F, end of track. That means the different bytes inbetween are the deltas.

Between the first note's on and off, SMF has a 0x5F byte and SCI has 0x06. Between that note-off and the next note-on, it's 0x01 in SMF and 0x00 in SCI, noting that the two events come immediately after each other.

I've attached the unaltered files in question.

[AGKorson]

Very interesting. The sound resource is certainly different from SMF. It definitely is using standard MIDI messages though.

The time differences are due to the ticks per quarter note value; for the sound resource, there are 30 ticks per quarter note (or 60 ticks per second); for the MIDI file, there are 480 ticks per quarter note (or 960 ticks per second). So 96 ticks in the MIDI is 0.1 sec; 6 ticks in the sound is 0.1 sec.

The the total sound length of both files is 0.4 seconds, but interestingly, the MIDI file plays each note for 0.99 sec(95 ticks), then has a 0.01 sec (1 tick) delay before starting next sound. The sound resource plays each note for the full 0.1 sec, with zero delay between them.

The sound resource header is not familiar at all to me (I did a cursory read of Ravi's files, but what he describes as the header doesn't seem to make sense for the resource file you posted; it looks to me like it would result in the MIDI events being completely misaligned, but again, I'm no SCI sound expert.)

The sound resource also has a couple of duplicate/unnecessary control messages (it first sets instrument to grand piano, then later sets it to glockenspiel; it calls channel volume and pan levels twice)

I'm curious, which came first here? Was the sound extracted from a game resource, and converted to MIDI? or was the MIDI file converted to a sound resource and then inserted in the game? I would have expected the conversion to duplicate all control codes exactly regardless if which direction you were going. I wonder why they are so different between the two.

(And if you're interested, I've attached annotated versions of both files breaking down exactly what each midi event does. It helped me parse through all the data.)

[Kawa]

This was the points jingle from a Sierra game, I don't recall which, that I converted to MID via I think SV, then edited to have the same four notes as the title screen for The Dating Pool in I think it was MuseScore, then imported back with SCI Companion.

At some point in that process, I suppose, extraneous commands snuck in.

Edit: also the header may not match Ravi's docs because this is not an SCI0 sound?

[AGKorson]

This was the points jingle from a Sierra game, I don't recall which, that I converted to MID via I think SV, then edited to have the same four notes as the title screen for The Dating Pool in I think it was MuseScore, then imported back with SCI Companion.

At some point in that process, I suppose, extraneous commands snuck in.

Edit: also the header may not match Ravi's docs because this is not an SCI0 sound?

So I decided to import the midi file into SCI Companion, and then save it as a sound resource. I discovered that SCI Companion is adding the extra control codes. I assume the import function adds them as default settings, even though the imported midi file already has those commands.

When it imports the file, SCI Companion keeps the original ticks per quarter note settings. But when it saves the data as a sound resource, it recalculates the time values to match 30 ticks per quarter note. That's how the 95/1 values get converted to 6/0.

I was surprised that SCI Companion will let you play the MIDI sound, adjust the tempo and add cues. But you can't edit/add MIDI notes, or change channel parameters? (i.e program/instrument, channel volume, etc). Are there editing commands that I'm not aware of? I have never used SCI Companion before.

[MusicallyInspired]

No. Companion will only let you import. It doesn't contain a MIDI sequencer/editor. It'd be pretty neat if it did. Even cooler if it supported MIDI input to record music straight in Companion with a MIDI keyboard or controller without the need of a MIDI editor/sequencer/DAW. That'd be a lot of work though I'd imagine (perhaps if some open source MIDI Editor was integrated?). It'd also be neat if Companion had built-in OPL emulation and could accurately playback with the Adlib patches from the game. And while we're at it, integrate MUNT as well and support for SoundFonts for GM.

Don't even get me started on a Patch editor.

[lskovlun]

Even cooler if it supported MIDI input to record music straight in Companion with a MIDI keyboard or controller without the need of a MIDI editor/sequencer/DAW.

There's truth in doing one thing and doing it well. I think you'd be reaching for your usual tools more often than not.

[Kawa]

Sorry, best I can offer is a raw command editor.

[shadyparadox]

I'd love to just compile my own local version with the "+1" removed, but I'm not exactly the sharpest coder. I tried but I got lost in Visual Studio land.

I just looked for void MidiPlayer::_OnStreamDone(). Here's a fresh build with the "+1" removed, just for you.

Frankly, testing this on one of the songs from The Dating Pool, it seems to loop a little bit better now? Could be placebo effect, I dunno, try it yourself.

Thank you!! That seems to resolve that particular issue.

But... 

Now as I've played around with it a little more, I've discovered that this program still doesn't reliably loop all the songs correctly, despite the fact it plays all the notes now.

Maybe the solution for my purposes is to just extract all the MIDI and import it into a proper editor and record from there. Unfortunately, that's going to present a bit of a learning curve for me.

No, in a MIDI sequencer/editor on the resulting MIDI file output. Lots of free options. Anvil Studio, MIDI Editor, and the DAW I use, Cakewalk Bandlab.

I was able to import into both MIDIEditor and Cakewalk, but regardless of which of those I should use, how do I import the loop information? Do I have to approximate it manually or is there a way to import it straight from the game resources for better authenticity? That's why I was hoping to do everything in the SCI programs in the first place.

[MusicallyInspired]

I was talking about changing the tempo. The loop cue data is SCI specific and not a standard MIDI controller...at least I don't think it is...

[shadyparadox]

I was talking about changing the tempo. The loop cue data is SCI specific and not a standard MIDI controller...at least I don't think it is...

Right, so what do you do when you want to record something from the games? I assume you've done it before, or at least whoever recorded all the Quest Studios stuff did somehow.

[Kawa]

I was talking about changing the tempo. The loop cue data is SCI specific and not a standard MIDI controller...at least I don't think it is...

You're right, it isn't. There is no standardized way to specify loop points in MIDI data.

Just looking at the MIDI plugin I have in Foobar2000, I see CC 116/117 used in XMI and EMIDI, and named markers in FF7. According to a post on VOGONS, RPG Maker uses CC 111 to specify a loop start, much like how XMI uses 116. So that's three different methods, plus SCI's.

[MusicallyInspired]

I was talking about changing the tempo. The loop cue data is SCI specific and not a standard MIDI controller...at least I don't think it is...

Right, so what do you do when you want to record something from the games? I assume you've done it before, or at least whoever recorded all the Quest Studios stuff did somehow.

Quest Studios recorded the output of the games themselves from a seperate PC. So MIDI Out from PC 1 playing the game to MIDI In on PC 2 with PC 2 MIDI Out going to the MT-32 or the SC-55 or whatever.

Me, I'm content to export the files from the games as MIDI. And if the tempo is incorrect, I can change it in a MIDI Sequencer/DAW.