What the hell are this packs? http://vgmrips.net/packs/chip/dac
I assume that they simply send to the speakers some ROM information directly from CPU, I've noticed that .vgm files wrongly are categorized as using a YM2612 (6th channel's dac?). That's not actually true, right? or I'm missing something?
DAC packs
Technical discussion about the VGM format, and all the software you need to handle VGM files.
Moderator: Staff
In these games the audio CPU can latch data directly into a DAC on the sound board (similar to the DAC channel on the YM2612). In order to log this, I modified MAME to log these writes as DAC writes to a YM2612. The YM2612 is not actually present on the real arcade PCB. While I could have used the PWM, at the time I chose not due to simplicity reasons. However, I used both the YM2612 DAC and the PWM for a submitted pack (Black Knight 2000).
An example: The original Mortal Kombat.
Listen to the percussion (EXCEPTING THE GONG).
Notice how it sounds slightly non-FM-ish? Williams (and later, Midway, as evidenced by this and later releases) relied on a DAC to overcome the 4-voice low-fidelity limit of the OKI chip, heck, worse, the one-voice UBER-low-fidelity limit of the CVSD chip that powered earlier games, in their music engine!
And years later, they created DCS, the Digitally Compressed Sound system, but that's a whole other story.
Listen to the percussion (EXCEPTING THE GONG).
Notice how it sounds slightly non-FM-ish? Williams (and later, Midway, as evidenced by this and later releases) relied on a DAC to overcome the 4-voice low-fidelity limit of the OKI chip, heck, worse, the one-voice UBER-low-fidelity limit of the CVSD chip that powered earlier games, in their music engine!
And years later, they created DCS, the Digitally Compressed Sound system, but that's a whole other story.
Until next post...
I'm personally a bit worried about having a generic DAC tied to a specific sound chip like the YM2612, especially when playing VGMs on real hardware, like the MSX computer. To be fair, VGMPlay for MSX doesn't currently support any kind of DAC and I'm not sure if it would be possible in the future, but it might.
Well, if VGMPlay for MSX ever gets support for DAC, i think all of them could be implemented regardless. You only have to catch the data block play commands... The YM2612's DAC is also as close to a generic DAC as it can be, since it takes regular 8-bit unsigned samples in mono. The PWM is stereo, takes 12 bit signed samples and has a maximum sampling rate of 22020 hz. Now if you can't parse the VGM commands at 44100 hz, then DAC would be an issue...
You mean the player should analyse the VGM file in order to determine playability? I don't think that's ideal, but it could be done. Regarding 44100Hz playback in the MSX, I suspect it isn't really possible, but it wouldn't be the first "impossible" thing to be done with the MSX. Of course, MSX isn't the only hardware platform for VGM files, just the one I'm most familiar with.
No need to analyze, as soon as you encounter a YM2612 DAC enable command, you can basically start sending the YM2612 DAC commands you get to your DAC of choice without really doing any processing.
The 44100 hz playback isn't an issue if you use the DAC stream and datablocks. While this is what my optimization tool does, it also adds some raw DAC writes inbetween DAC stream commands.
The 44100 hz playback isn't an issue if you use the DAC stream and datablocks. While this is what my optimization tool does, it also adds some raw DAC writes inbetween DAC stream commands.
I see.
According to the VGM format spec, YM2612 clock rate should be set to zero if there is no YM2612 chip used. Do you think the spec should be amended to cover such cases? I'm worried that it could have unintended consequences down the road. Wouldn't it be safer if the format were extended to support generic DACs?
According to the VGM format spec, YM2612 clock rate should be set to zero if there is no YM2612 chip used. Do you think the spec should be amended to cover such cases? I'm worried that it could have unintended consequences down the road. Wouldn't it be safer if the format were extended to support generic DACs?
The clock rate is used for emulation and as a reference. Yes, it has to be set, and it means the YM2612 will be emulated on "regular" VGMPlay. Setting it to the usual value will provide a high enough DAC sample rate (higher than VGM's 44100hz sample rate) and there will not be any unintended consequences apart from the fact that the YM2612 is now emulated, which could mean a little higher CPU usage than normal (probably insignificant on any computer released in the last 15 years though). Since all registers are initialized to 0, it won't make any noise. And as for the PWM, it requires a clock rate too.
Honestly I can't really say whether a generic DAC will be added into VGMPlay in the future, but in the case that happens, the existing VGMs using the YM2612 dac could be modified without any problems to use this instead. Of course at the cost of breaking compatibility with prior VGMPlay versions.
Honestly I can't really say whether a generic DAC will be added into VGMPlay in the future, but in the case that happens, the existing VGMs using the YM2612 dac could be modified without any problems to use this instead. Of course at the cost of breaking compatibility with prior VGMPlay versions.