Skip to content

VGM 2.0 suggestions / ideas

orig. title: Multiple AY chips with stereo

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

Moderator: Staff

VGM 2.0 suggestions / ideas

Post by NewRisingSun2 »

All .VGM players I have tried play both chips in the center even as the .VGM files in this pack (edit: deleted) all have the "hard pan" flag set in the AY chip clock field (0x80000000). The first chip is supposed to be heard on the left, and the second chip is supposed to be heard on the right. Is this a limitation of the players, or am I doing something wrong?

Also, if I understand the .VGM specification v1.71 correctly, only two AY-3-8910 chips are supported by the format. This means that the music of this game cannot be supported properly, as it is composed for nine voices. Optimal would be to use two Mockingboards type A/C or a Phasor board in the game, providing four AY-3-8913 chips for a total of twelve voices. MAME supports that configuration and will even output two .VGM files that when converted to .WAV and mixed together in Audacity sound right, apart from the missing stereo effect. Four chips could easily be supported by using Bit 6 (0x40) of the second byte of the A0h command as a second chip select bit. I could immediately provide a pack of this game using that configuration, so it's not like it would not ever be used.
Last edited by NewRisingSun2 on 2017-04-30, 17:14:30, edited 1 time in total.
  • User avatar
  • ValleyBell Offline
  • Posts: 4768
  • Joined: 2011-12-01, 20:20:07
  • Location: Germany

Post by ValleyBell »

Yes, only 2 instances of each chip are supported. This is due to a series of limitations, partly of the VGM format and partly of VGMPlay itself.
There are existing workarounds though - some Arcade packs use an additional YM2203 to provide the 3rd AY chip. (It's technically an YM2149, but it works.)

The VGM format probably won't see support for 3+ chips very soon. I might try to come up with something for VGM v1.80, but since even dual chip support is very, very hackish I'm not really sure.
(For dual chip support I use clock bit 30 in the main header, bit 7 of the "chip ID" in the extra header, bit 31 of the data block length in 67 66 commands, random bits in the sound commands, ... It's really a mess.)
It's more likely that there might be a new format (VGM v2?) that allows 3+ chips. (I would also try to get away from the 44.1 KHz tick rate then.)


About hard panning - bit 31 of the clock is just a "special flag" in general and has different meanings depending on the sound chip. It's not a general hard pan flag. It is unused by most sound chips (like the AY8910). In some cases it selects certain chip modes (YM2610 vs. YM2610B) or clock dividers (OKIM6295).
The VGM spec. is a bit lacking in that regard (I forgot to mention some of the special flags), but it's documented in the VGMPlay source code - just search for AllowBit31.

Post by NewRisingSun2 »

I thought about the YM2203 route, but thought it used the A0 command for the AY interface? I'll take a look at Bomb Jack, then.

Panning could be added to the Extra Header, though. ;)
  • User avatar
  • ValleyBell Offline
  • Posts: 4768
  • Joined: 2011-12-01, 20:20:07
  • Location: Germany

Post by ValleyBell »

No, the YM2203's SSG is part of the actual YM2203 commands, so it uses 55 rr dd (rr = register, dd = data).

About panning via extra header - that needs to wait until libvgm-VGMPlay is done. Right now it's hardcoded for OPL2.

Post by NewRisingSun2 »

What can I say --- changing all AY to YM2203 writes in the second .VGM that MAME outputs does work. I had to double the chip clock, though.

And the volume isn't right either. I guess I need to use the extra header's volume fields again in the merged .VGM. Can you say from the top of your head what the volume modification should be? I assume that if one YM2203 has a total of six channels channels while the AY has three, I need a relative volume of 200% for each YM2203 to get its AY part to sound just as loud as each of the two pure AYs, right?
  • ctr Offline
  • Posts: 492
  • Joined: 2013-07-17, 23:32:39

Post by ctr »

The way the AY chips and the OPN chips are currently implemented really leaves a lot to be desired. Unfortunately there isn't much that could be done apart from creating a new VGM format.

Currently, i think that 200% should be enough to compensate for the lower SSG volume on the OPNs.

But to understand it really works, you have to make the distinction between channels and voices. The YM2203 has six voices, but only 4 channels (FM out and SSG channels 1-3).
Currently we treat SSG (and AY) channels as 1-3 as just one. This isn't really great since some arcade games filter, pan or attenuate only a few channels and not the whole chip...

Post by NewRisingSun2 »

I set the two YM2203s to 200% in the extra header (value 0x8200) of my work .VGM and converted to wav. I compared this to what I get when I convert the two raw .VGM files that MAME outputs to .WAV and mix them together in Audacity. I still have to double the final volume in the work .VGM file, but when doing so (and setting AY type to YM2149 at offset 0x78; apparently the YM2149 has a slightly different volume curve than the AY-9-8913.), mixing the two waves out-of-phase results in residue at a level of -60 dB, which could come from anything.

Thanks for the input. I guess I'll submit the pack then in this configuration, updating it with the panning information when the ability to do so is implemented. (I assume that any VGM2 format specification will come with a VGM->VGM2 converter ... :D )
  • User avatar
  • ValleyBell Offline
  • Posts: 4768
  • Joined: 2011-12-01, 20:20:07
  • Location: Germany

Post by ValleyBell »

For that case, I recommend to set the volume of all 4 chips (2x AY8910 and 2x YM2203-SSG) to 0x100 (absolute 100%).
(AY8910 #1: 12 00 00 01, AY8910 #2: 12 01 00 01, YM2203-SSG #1: 92 00 00 01, YM2203-SSG #2: 92 01 00 01)

And yes, there probably will be a VGM v1 to VGM v2 converter.

Post by NewRisingSun »

ValleyBell wrote:It's more likely that there might be a new format (VGM v2?) that allows 3+ chips. (I would also try to get away from the 44.1 KHz tick rate then.)
Does a draft VGM v2 specification exist?
  • User avatar
  • ValleyBell Offline
  • Posts: 4768
  • Joined: 2011-12-01, 20:20:07
  • Location: Germany

Post by ValleyBell »

No, I haven't started a draft yet. Right now VGM v2 is just an "idea".

Post by NewRisingSun »

Mind if I write one?
  • User avatar
  • ValleyBell Offline
  • Posts: 4768
  • Joined: 2011-12-01, 20:20:07
  • Location: Germany

Post by ValleyBell »

Feel free to do so.
I recommend to have a look at the S98 file format. I wanted to take some ideas from it. (namely timing defined in the file header and like being able assign devices to commands)

Post by NewRisingSun »

Attached. Consider everything a mere suggestion, including the chip types not supported in VGM v1.71. The Notes and Open Questions sections would not be in any final document, of course. I have not yet bothered to think about the DAC stream control stuff, since I have rarely used it myself so far.
Attachments
vgmspec200-2017-09-17-NRS.txt
(16.88 KiB) Downloaded 467 times
  • ctr Offline
  • Posts: 492
  • Joined: 2013-07-17, 23:32:39

Post by ctr »

You will still need datablocks as chips using RAM is still able to rewrite the contents during playback.

A feature that I think will be essential to VGM 2 is the ability to set panning and volume for each channel (output) of a sound chip separately. For example, the AY-3-8910 has three outputs and it should be possible to set volume and panning for each. It would also make it easy to swap left/right outputs for some sound chips with stereo output, for example SegaPCM and YM2151. Also it would allow for some tweaking, for example the 2A03 has two channels but they would all be set to mono. For homebrew VGMs or simply as an override option in the vgm player config It would then be possible to override or modify this setting, to match "your" NES/FC system more closely.
  • User avatar
  • ValleyBell Offline
  • Posts: 4768
  • Joined: 2011-12-01, 20:20:07
  • Location: Germany

Post by ValleyBell »

Instead of encoding the "chip number" into the chip command, we can just define the same chip multiple times.
That might reduce the total number of chip that can be used in one file, but the limit defined by available CPU power (for emulation) is way lower anyway.

Also, I'd like to have at least 3 different delay commands: "wait ll clock", "wait mmll clock" and "wait hhmmll clock".

I think that one "master" clock rate for the whole file is enough. (I'd prefer the more general term "tick", btw.) You usually have one CPU doing all sound processing and not one CPU for each sound chip.
If you want to go with a per-track clock rate, please include additional "total length" and "loop length" fields for the overall song. Else the amount of work for doing a simple song length display might explode.

A value that stores the size of the whole file would be useful. Especially if you're dealing with gzip compressed data. (i.e. something similar to the current VGM EOF offset)

I really like how you use "size arrays" instead of "offset arrays". I always found those VGM offsets to be a pain to work with and would've preferred absolute file offsets or structure sizes.

really nitpicking, but: Virtual Boy VSU and WonderSwan are WSG-type sound chips.
Post Reply