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
- NewRisingSun2 Offline
- Posts: 54
- Joined: 2016-12-27, 3:21:40
VGM 2.0 suggestions / ideas
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.
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.
- ValleyBell Offline
- Posts: 4791
- Joined: 2011-12-01, 20:20:07
- Location: Germany
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.
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.
- NewRisingSun2 Offline
- Posts: 54
- Joined: 2016-12-27, 3:21:40
- ValleyBell Offline
- Posts: 4791
- Joined: 2011-12-01, 20:20:07
- Location: Germany
- NewRisingSun2 Offline
- Posts: 54
- Joined: 2016-12-27, 3:21:40
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?
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?
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...
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...
- NewRisingSun2 Offline
- Posts: 54
- Joined: 2016-12-27, 3:21:40
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 ... )
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 ... )
- ValleyBell Offline
- Posts: 4791
- Joined: 2011-12-01, 20:20:07
- Location: Germany
- NewRisingSun Offline
- Posts: 62
- Joined: 2016-11-04, 14:15:48
- ValleyBell Offline
- Posts: 4791
- Joined: 2011-12-01, 20:20:07
- Location: Germany
- ValleyBell Offline
- Posts: 4791
- Joined: 2011-12-01, 20:20:07
- Location: Germany
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)
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)
- NewRisingSun Offline
- Posts: 62
- Joined: 2016-11-04, 14:15:48
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 499 times
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.
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.
- ValleyBell Offline
- Posts: 4791
- Joined: 2011-12-01, 20:20:07
- Location: Germany
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.
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.