I just wanted to record some MIDI...

[shadyparadox]

As it says in the title, all I'm trying to do is record some audio of the MIDI sounds of some old Sierra classics using a couple Rolands I have sitting on my desk. I feel like the task shouldn't be that difficult so I'm kind of embarrassed I can't figure it out on my own, but I'm having technical issues at every turn.

I could try to record while they're playing in the game, but I need more control than that. There's often other stuff going on in the game at the same time, and sometimes it cuts off early if the scene changes. Some sounds don't even play in the game. So I need some kind of tool.

I would just extract the MIDI files and play them under any interpreter, but I need the loop information as well.

So it makes sense to play the files directly within one of the SCI resource tools. However, each one has a silly problem that prevents me from recording it accurately.

I started recording using SCI Viewer, but it turns out it plays the MIDI files about 4% faster than intended. Someone explained the reason to me once but I forgot what it was. The important thing is that I don't see a way to play MIDI files using SCI Viewer at the correct speed.

I was going to switch to SCI Companion, but that has an even dumber problem. The MIDI playback tool has a very silly bug in it. It plays at the right speed, but it only plays notes AFTER the loop point, and not the ones ON the loop point like it should. This results in a lot of sound cutting out.

I would try SCI Studio, but it doesn't load any game I've thrown at it. It just always gives the same error, "Resource package/map file identifier mismatch! The game you are trying to open is incomplete, corrupt, or not the correct version!"

So what do I need to do? Program a whole new "game" in SCI Companion just to play MIDI files? This was not supposed to be a big deal.

[Kawa]

I was going to switch to SCI Companion, but that has an even dumber problem. The MIDI playback tool has a very silly bug in it. It plays at the right speed, but it only plays notes AFTER the loop point, and not the ones ON the loop point like it should. This results in a lot of sound cutting out.

This part gets me. I've been wondering about that myself and I really should check to see if it's just a bug in SCI Companion's player that doesn't reflect what the actual game does.

I would try SCI Studio, but it doesn't load any game I've thrown at it. It just always gives the same error, "Resource package/map file identifier mismatch! The game you are trying to open is incomplete, corrupt, or not the correct version!"

SCI Studio only really works on old SCI0 games, the ones in 16 colors with the text parser.

I started recording using SCI Viewer, but it turns out it plays the MIDI files about 4% faster than intended. Someone explained the reason to me once but I forgot what it was. The important thing is that I don't see a way to play MIDI files using SCI Viewer at the correct speed.

First I've heard of that issue 🤔

So what do I need to do? Program a whole new "game" in SCI Companion just to play MIDI files? This was not supposed to be a big deal.

You'd have to make sure to grab the right patches as well, depending on the source game.

[MusicallyInspired]

It doesn't play faster for me in SCI Viewer that I've noticed...I suppose it might be possible that I just haven't noticed. What version of SCI Viewer are you using?

SCI Studio doesn't have a sound player. It depended on a separate tool, Ravi's SoundBox, which also only works with SCI0 sounds.

[shadyparadox]

This part gets me. I've been wondering about that myself and I really should check to see if it's just a bug in SCI Companion's player that doesn't reflect what the actual game does.

Having no idea how the code works, it sounds to me like a one-keystroke bug, like ">" vs. ">=" or something.

SCI Studio only really works on old SCI0 games, the ones in 16 colors with the text parser.

OK. I only opened it briefly because I was getting frustrated with the other tools, but good to know, I won't bark up that tree anymore.

You'd have to make sure to grab the right patches as well, depending on the source game.

I mean, I'll do it if I have to (I'd have to learn how), but I really hope it doesn't come down to this.

[shadyparadox]

It doesn't play faster for me in SCI Viewer that I've noticed...I suppose it might be possible that I just haven't noticed. What version of SCI Viewer are you using?

It doesn't tell me a version, it just says Copyright 2007.

Considering it's MIDI that's playing, it's understandable that a 4% speed boost would go undetected. It was kind of surreal how I found it. I placed my recording side-by-side with a recording from Quest Studios and noticed theirs was slightly slower. As I was calculating the difference, one of my viewers (I was streaming at the time) pointed out that movies made in the U.S. played 4% faster in his region due to NTSC and PAL differences. It turned out that was exactly the difference in the two recordings, so I'd be curious if there's a connection there.

[Kawa]

movies made in the U.S. played 4% faster in his region due to NTSC and PAL differences.

An interesting coincidence, but I don't buy it: NTSC/PAL framerate differences aren't a thing when you're talking about MS-DOS PC games, nor MIDI timing.

[shadyparadox]

movies made in the U.S. played 4% faster in his region due to NTSC and PAL differences.

An interesting coincidence, but I don't buy it: NTSC/PAL framerate differences aren't a thing when you're talking about MS-DOS PC games, nor MIDI timing.

Perhaps it doesn't literally use the same units, but is there any chance something could happen while converting units in a similar fashion?

[Kawa]

There shouldn't really be any framerate-related issues when converting from one MIDI-based format to another.

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.

Seems straightforward enough to convert to standard MIDI format.

[MusicallyInspired]

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

[AGKorson]

it's well known that the original tools used to convert AGI sounds to MIDI had a timing issue as well. They used a tick duration of 1/64 sec instead of the correct value of 1/60 sec. Is it possible that a similar error exists in the SCI tools? That equates to an error rate closer to 6%.  IDK how sounds are stored in SCI resources, and/or converted to MIDI so this might not be relevant.

[Kawa]

IDK how sounds are stored in SCI resources, and/or converted to MIDI so this might not be relevant.

Resource-wise, I already posted the part of the actual track data format that's relevant to timing.

Tool-wise, I know of four different tools for SCI: a command-line MID-to-SND converter, a slightly more visual MID-to-SND converter, some sort of header editor I think, and a weird kind of piano roll editor with only four voices.

[troflip]

I was going to switch to SCI Companion, but that has an even dumber problem. The MIDI playback tool has a very silly bug in it. It plays at the right speed, but it only plays notes AFTER the loop point, and not the ones ON the loop point like it should. This results in a lot of sound cutting out.

Looking at the code, it seems this is quite explicit, I even added a comment to that effect:

Code: [Select]

void MidiPlayer::_OnStreamDone()
{
    if (!_fStoppingStream)
    {
        // There is more to this stream... keep going.
        if (_cRemainingStreamEvents)
        {
            _CuePosition(_cTotalStreamEvents - _cRemainingStreamEvents);
        }
        else
        {
            if (_dwLoopPoint != SoundComponent::LoopPointNone)
            {
                // Cue the loop point. We start playing events *after* the loop point, not at the loop point.
                CueTickPosition(_dwLoopPoint + 1);
            }
            else
            {
                Stop();
            }
        }
    }
}

I'm not sure why I thought that though. Maybe it's true for some SCI versions and not others? I wonder what ScummVM does.

[Kawa]

The actual time of the loop point is better explained with a short diagram:

0x10 0x91 0x20 0x20 play a note on channel 1
0x05 0x91 0x20 0x00 stop the previous note
0x00 0x92 0x30 0x10 play a note on channel 2
[restart here]
0x00 0xCF 0x7F set loop point
0x00 0xC8 0x05 change to program 5 on channel 8
0x00 0xCF 0x13 set signal to 19
0x20 0xFC end of file, loop to marked location

🤔

[shadyparadox]

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

In SCI Viewer? How?

it's well known that the original tools used to convert AGI sounds to MIDI had a timing issue as well. They used a tick duration of 1/64 sec instead of the correct value of 1/60 sec. Is it possible that a similar error exists in the SCI tools? That equates to an error rate closer to 6%.  IDK how sounds are stored in SCI resources, and/or converted to MIDI so this might not be relevant.

I just compared the files again to be sure, and I'm getting a difference of about 4.03%.

I was going to switch to SCI Companion, but that has an even dumber problem. The MIDI playback tool has a very silly bug in it. It plays at the right speed, but it only plays notes AFTER the loop point, and not the ones ON the loop point like it should. This results in a lot of sound cutting out.

Looking at the code, it seems this is quite explicit, I even added a comment to that effect:

Code: [Select]

void MidiPlayer::_OnStreamDone()
{
    if (!_fStoppingStream)
    {
        // There is more to this stream... keep going.
        if (_cRemainingStreamEvents)
        {
            _CuePosition(_cTotalStreamEvents - _cRemainingStreamEvents);
        }
        else
        {
            if (_dwLoopPoint != SoundComponent::LoopPointNone)
            {
                // Cue the loop point. We start playing events *after* the loop point, not at the loop point.
                CueTickPosition(_dwLoopPoint + 1);
            }
            else
            {
                Stop();
            }
        }
    }
}

I'm not sure why I thought that though. Maybe it's true for some SCI versions and not others? I wonder what ScummVM does.

Oh wow. I just assumed it was due to someone not paying attention, but if it is deliberately coded like that, I'm sure you had a reason.

However, for the games I'm loading (KQ6, SQ4), it's definitely not correct. 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.

[Kawa]

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.