Skip to content

OPL2 channel remapping

Technical discussion about the VGM format, and all the software you need to handle VGM files.

Moderator: Staff

OPL2 channel remapping

Post by NewRisingSun »

It is almost impossible to make .VGM files with clean-sounding loops when logging frmo sound drivers that allocate channels dynamically.

One remedy would be to specify how the channel allocation differs after the loop end compared to the loop start. As an example, for the nine OPL channels, the player would be remapping channel and operator writes according to a channel remap table. The initial state of that table would simply be { 0, 1, 2, 3, 4, 5, 6, 7, 8 }. At the loop end, the channel remap table is filled with values specified in the file. Those values are not directly copied into the table, but are themselves considered indices into the current table, so that the remap procedure works even on subsequent iterations of the loop. The values to be specified in the file at the loop end are obtained by comparing, for every note after the loop end, the channel on which it appears compared to the channel on which it appears after the loop start. This should be quite trivial to do if the loop points have been set correctly.

Attached find a simple proof-of-concept, using a Monkey Island 2 music file. UNTRIMMED.VGM is as the name implies the straight recording with several iterations of the loop. UNMAPPED.VGM is a normally-trimmed file, which at the loop point makes the flute sound very clicky because the channel allocation changed. Use any VGM player for playback. MAPPED.VGM, when played back with the include PLAYVGM.EXE in DOSBox (and not with any VGM player), will remap the channels at the loop end to produce the same channel allocation as the untrimmed file after the loop end, even on second and third loops. The channel remap information is included as nine data bytes following the $66 command in MAPPED.VGM. An actual implementation would assign a new command for this. CHANMAP.TXT shows the channel mapping after the loop start and after the loop end, deduced from looking at the UNTRIMMED.txt file. PLAYVGM.ASM is the x86 assembler source code, so you can see how it's done. (Note that the second note after the loop sounds clicky even in the untrimmed file.)

A VGM 2 format (or even VGM 1.80) could include such a channel remapping command, for any sound chip, to allow clean loops when logging from dynamically-allocating sound drivers.
Attachments
remap.zip
(129.81 KiB) Downloaded 231 times
  • ctr Offline
  • Posts: 492
  • Joined: 2013-07-17, 23:32:39

Post by ctr »

Not a bad idea, and I think it is pretty much required if we want to properly support newer sound chips like SCSP or PSX SPU in the future. However, I think it is also required to write programs that can find these channel maps automatically as well. I think the point of VGM is to make it easy to create rips and finding channel maps manually (for chips with 24 or 32 channels or more) sounds like it could be a hard or laborious process at best.

Post by NewRisingSun »

Yes, but that should be simple to do, unless I am missing something. If the loop points have been correctly set, then the note-on commands past the loop end are exactly the same as the note-on commands past the loop start except for the channel allocation, and timing jitter. Other commands would be irrelevant. The tool would then derive the channel map by simply comparing the first note-on command after the loop end with the first note-on command after the loop start, and the same with the second, third and further note-on commands.

Post by NewRisingSun »

Here's a shot at such a utility. Run "vgm_remap vgmfile loopstart loopend", with vgmfile being an untrimmed file containing OPL2 commands, and loopstart and loopend being correct loop start/end points. The program outputs a list indicating which channel after the loop start corresponds to which channel after the loop end. I tried with four files (two iMuse, two Origin F/X Sound System), and it worked great on all four on conjunction with the above DOS player. Still, it's just something a quickly threw together, so I'm sure there are bugs and all, but it shows the basic idea.
Attachments
vgm_remap.c
(8.98 KiB) Downloaded 223 times
  • Tom Offline
  • Ragequit Member
    Ragequit Member
  • Posts: 496
  • Joined: 2011-11-30, 17:26:44
  • Location: Italy
  • Contact:

Post by Tom »

You know, I once encountered this issue when I tried to make a rip of Neo Turf Master, and I soon dismissed it because of my proverbial lazyness. A Neo Turf Master pack was created by someone else eventually, with overabundant loops, e.g. the actual loop in the VGM file is actually the second loop of the song, while the first loop is all treated as introduction. That made me think about a different approach: since (at least in Neo Turf Master) the channel layout doesn't change anymore after the second loop, it might be worth to hex edit the first loop to use the "correct" instruments from the starts, to properly trim the loop in the VGM file itself. Of course this isn't always true for other songs, which might have different instruments in every subsequent loop, but it wouldn't require any edit to the VGM standard, such as new commands, it would only require a new tool which would "cheat" and "fix" the first loop. The caveat here is that both our ideas would alter the VGM data, going against the spirit of preservation which should be behind it in the first place. Still, brainstorming!
Also known as nineko.
Post Reply