Community

General and Everything Else => The Games and other Sierra Adventure stuff => Topic started by: shadyparadox on September 27, 2020, 10:11:41 AM

Title: I just wanted to record some MIDI...
Post by: shadyparadox on September 27, 2020, 10:11:41 AM
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.
Title: Re: I just wanted to record some MIDI...
Post by: Kawa on September 27, 2020, 03:03:54 PM
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.

Quote
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.

Quote
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 🤔

Quote
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.
Title: Re: I just wanted to record some MIDI...
Post by: MusicallyInspired on September 27, 2020, 03:51:20 PM
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.
Title: Re: I just wanted to record some MIDI...
Post by: shadyparadox on September 28, 2020, 01:16:12 PM
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.

Quote
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.

Quote
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.
Title: Re: I just wanted to record some MIDI...
Post by: shadyparadox on September 28, 2020, 01:21:50 PM
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.
Title: Re: I just wanted to record some MIDI...
Post by: Kawa on September 28, 2020, 01:59:05 PM
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.
Title: Re: I just wanted to record some MIDI...
Post by: shadyparadox on September 28, 2020, 02:24:13 PM
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?
Title: Re: I just wanted to record some MIDI...
Post by: Kawa on September 28, 2020, 03:31:06 PM
There shouldn't really be any framerate-related issues when converting from one MIDI-based format to another.

Quote from: Ravi Iyengar
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.
Title: Re: I just wanted to record some MIDI...
Post by: MusicallyInspired on September 28, 2020, 07:36:27 PM
You could just calculate the 4% difference and change the tempo to compensate.
Title: Re: I just wanted to record some MIDI...
Post by: AGKorson on September 29, 2020, 10:37:54 AM
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.
Title: Re: I just wanted to record some MIDI...
Post by: Kawa on September 29, 2020, 11:28:32 AM
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.
Title: Re: I just wanted to record some MIDI...
Post by: troflip on September 29, 2020, 11:48:30 AM
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.
Title: Re: I just wanted to record some MIDI...
Post by: Kawa on September 29, 2020, 03:18:45 PM
Quote from: Ravi Iyengar
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

🤔
Title: Re: I just wanted to record some MIDI...
Post by: shadyparadox on September 29, 2020, 03:21:45 PM
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.
Title: Re: I just wanted to record some MIDI...
Post by: Kawa on September 29, 2020, 04:26:57 PM
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. (http://helmet.kafuka.org/sci/SCICompanion-loopchange.rar)

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.
Title: Re: I just wanted to record some MIDI...
Post by: MusicallyInspired on September 29, 2020, 05:41:10 PM
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.

Title: Re: I just wanted to record some MIDI...
Post by: AGKorson on September 29, 2020, 06:51:01 PM
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.

Quote
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.

Title: Re: I just wanted to record some MIDI...
Post by: OmerMor on September 30, 2020, 02:17:15 AM
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/
Title: Re: I just wanted to record some MIDI...
Post by: Kawa on September 30, 2020, 07:55:58 AM
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.
Title: Re: I just wanted to record some MIDI...
Post by: AGKorson on September 30, 2020, 03:55:45 PM
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.)
Title: Re: I just wanted to record some MIDI...
Post by: Kawa on September 30, 2020, 04:42:41 PM
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?
Title: Re: I just wanted to record some MIDI...
Post by: AGKorson on September 30, 2020, 10:04:10 PM
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.
Title: Re: I just wanted to record some MIDI...
Post by: MusicallyInspired on October 01, 2020, 01:02:47 AM
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. ;)
Title: Re: I just wanted to record some MIDI...
Post by: lskovlun on October 01, 2020, 02:58:59 AM
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.
Title: Re: I just wanted to record some MIDI...
Post by: Kawa on October 01, 2020, 05:43:37 AM
Sorry, best I can offer is a raw command editor.
Title: Re: I just wanted to record some MIDI...
Post by: shadyparadox on October 30, 2020, 04:37:56 PM
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. (http://helmet.kafuka.org/sci/SCICompanion-loopchange.rar)

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. Sometimes the timing is off. (https://youtu.be/ofJFIVDLUvE)

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.
Title: Re: I just wanted to record some MIDI...
Post by: MusicallyInspired on October 30, 2020, 11:20:09 PM
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...
Title: Re: I just wanted to record some MIDI...
Post by: shadyparadox on October 31, 2020, 03:42:40 AM
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.
Title: Re: I just wanted to record some MIDI...
Post by: Kawa on October 31, 2020, 12:15:50 PM
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.
Title: Re: I just wanted to record some MIDI...
Post by: MusicallyInspired on October 31, 2020, 12:43:08 PM
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.
Title: Re: I just wanted to record some MIDI...
Post by: ZvikaZ on October 31, 2020, 02:45:23 PM
If you want to just record the MIDI, a simple option might be using the 'dump-midi' flag that I've added to ScummVM - it dumps all MIDI commands that the game creates during play, including SysEx.

Instructions:

Code: [Select]
scummvm --dump-midi
This will create a 'dump.mid' file in the local directory.
- If there is already such file, it will be overwritten
- The file will be created when quitting from the game, either from the game's menu, or from ScummVM's Global Menu (and not when quitting by clicking 'X' to close the window)

It will not automatically rip all sound tracks at once, as you might prefer, but it will create an exact recording of all MIDI commands created as you play.

Note however, that it will record only midi, and not other sounds such as digitized effects or voices, so it might be better to turn off options like "prefer digital sound effects", or "Mixed AdLib/MIDI mode".
Title: Re: I just wanted to record some MIDI...
Post by: shadyparadox on November 01, 2020, 08:03:17 PM
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.

This would be my preference as well. But the exported MIDI doesn't have any loop information. So how do you get accurate loop information into the project?
Title: Re: I just wanted to record some MIDI...
Post by: shadyparadox on November 01, 2020, 08:05:56 PM
If you want to just record the MIDI, a simple option might be using the 'dump-midi' flag that I've added to ScummVM - it dumps all MIDI commands that the game creates during play, including SysEx.

Instructions:

Code: [Select]
scummvm --dump-midi
This will create a 'dump.mid' file in the local directory.
- If there is already such file, it will be overwritten
- The file will be created when quitting from the game, either from the game's menu, or from ScummVM's Global Menu (and not when quitting by clicking 'X' to close the window)

It will not automatically rip all sound tracks at once, as you might prefer, but it will create an exact recording of all MIDI commands created as you play.

Note however, that it will record only midi, and not other sounds such as digitized effects or voices, so it might be better to turn off options like "prefer digital sound effects", or "Mixed AdLib/MIDI mode".

Thanks, I'll keep it in mind if the direct method fails. It sounds similar to the first method I tried, which was to use the MIDI recorder in DOSBox. The problem there was that the files didn't seem to quite import properly, as some notes sustained instead of turning off when they were supposed to.

The other problem with recording in-game is that some sounds aren't easily accessible in the game, if they're even available at all.
Title: Re: I just wanted to record some MIDI...
Post by: Kawa on November 01, 2020, 09:04:36 PM
This would be my preference as well. But the exported MIDI doesn't have any loop information. So how do you get accurate loop information into the project?
And exactly what would that loop information be? There's at least four different ways to include it.
Title: Re: I just wanted to record some MIDI...
Post by: ZvikaZ on November 02, 2020, 03:23:06 AM
Thanks, I'll keep it in mind if the direct method fails. It sounds similar to the first method I tried, which was to use the MIDI recorder in DOSBox.
Can you please elaborate? How did you record MIDI in DOSBox?
It could help me when debugging occasionally sound-related bug reports in ScummVM.

The problem there was that the files didn't seem to quite import properly, as some notes sustained instead of turning off when they were supposed to.
That's strange. I could think of few issues that might cause such mess:
- The initial SysEx commands weren't recorded
- You're trying to play a midi recording of MT32, in a "regular" (=GM) MIDI player instead through a real MT32, or Munt; or maybe vice-versa - DosBOX played a GM midi, and it's played now in Munt
- Bug in the DosBOX recording mechanism

Anyway, when recording with my method, I (and few others who told me that they used it) haven't encountered any such errors. (just to make sure to play through Munt, if the Audio is configured to MT32)
If there will be errors in the recording - I'd be glad to hear about it. (maybe as a bug report in ScummVM...)

The other problem with recording in-game is that some sounds aren't easily accessible in the game, if they're even available at all.
Well, that's indeed a problem.
However, if you'd like to, it's possible to trigger the missing sounds from ScummVM's debugger, during the game.
Title: Re: I just wanted to record some MIDI...
Post by: MusicallyInspired on November 02, 2020, 12:13:09 PM
The loop information is not a MIDI command. The aforementioned MIDI loop controllers that Kawa mentioned are for customized versions of MIDI. EMIDI, for instance, is only used for 3D Realms' Build game engines (Duke3D, Shadow Warrior). The others would also be proprietary. There wouldn't be any way to implement it for everything to understand. If you want it to loop, you have to program in the loop functionality yourself in whatever your project is (that's what game developers did, and that's why the SCI developers made it a specialized data cue entry specifically for SCI sound resources and not a standard MIDI controller event). If you want it to loop in some other kind of project, you could open it in a DAW like Cakewalk (free) and set loop points yourself at the proper MIDI events or just copy and paste the selection of MIDI events and repeat it manually. There is no one consistent universal MIDI loop command so as I see it this is not feasible to implement nor is it within the scope of what should be implemented IMO.

ZvikaZ, DOSBox has a built-in function to capture MIDI data into an outputted .MID file in the CAPTURE directory similar to its screenshot, audio, raw OPL, and video capture functions.
Title: Re: I just wanted to record some MIDI...
Post by: shadyparadox on November 09, 2020, 10:01:08 PM
The loop information is not a MIDI command. The aforementioned MIDI loop controllers that Kawa mentioned are for customized versions of MIDI. EMIDI, for instance, is only used for 3D Realms' Build game engines (Duke3D, Shadow Warrior). The others would also be proprietary. There wouldn't be any way to implement it for everything to understand. If you want it to loop, you have to program in the loop functionality yourself in whatever your project is (that's what game developers did, and that's why the SCI developers made it a specialized data cue entry specifically for SCI sound resources and not a standard MIDI controller event). If you want it to loop in some other kind of project, you could open it in a DAW like Cakewalk (free) and set loop points yourself at the proper MIDI events or just copy and paste the selection of MIDI events and repeat it manually. There is no one consistent universal MIDI loop command so as I see it this is not feasible to implement nor is it within the scope of what should be implemented IMO.

OK, I'm willing to do that manually. Is there a way to extract the loop information from the snd file just so I have an idea where to put the loop in my MIDI project? I'd prefer to have a way to get some technical information on it rather than solely guessing.
Title: Re: I just wanted to record some MIDI...
Post by: MusicallyInspired on November 09, 2020, 11:18:46 PM
I don't think it's really that much guesswork involved. Most loop points land right on a measure, or at least a beat, or a note. If it's an "atmospheric" sound with no perceptible tempo, time signature, or BPM then I feel like a close enough guess is warranted. You can playback sounds in SCI Viewer WITH the loop points so in my feeling guestimating the loop point for these tracks is alright and close enough. In proper musical themes it's really no guess. It'll all land on at least a note event if nothing else. That's for all intents and purposes pretty exact.