... I'm using an interrupt 'cause it's a player routine for background sound ... at least it even works when DOSBox is set to 50 cycles fixed 😀 which is a computer about 0.28 MHz (Landmark says) 😀) ...

btw. seems, that there are some interesting VGM Tools:

Conversion (looks promising, tried a AY8910 VGM to YM3812 Conversion, not perfect but works!)
https://github.com/digital-sound-antiques/vgm-conv

VGM Packer (for 8 bit systems) which is interesting, 'cause it reduces the VGM "sample rate" from 44100 Hz to 60 Hz (chip tunes delays I guess) .. must try it for YM3812
https://github.com/simondotm/vgm-packer

Oh my god, I'm just a dumb as***** .. I've been racking my brains for ages about the delays in the VGM file and didn't realize, that there are a lot of FM commands in line without any delays - that I forced to wait with my interrupt routine for some ms *facepalm* ... now FM replay with 172 Hz is no problem, maybe lower too, but still thinking about advantages betweend 1000 Hz (nice time / speed calc as a side effect) or 60 Hz (like a frame counter) ...

bakemono wrote on 2024-06-22, 14:32:

My player doesn't use interrupts at all. It does count the 44KHz samples for each VGM wait. After a certain number of samples have passed (IIRC I had it set to 1/180 of a second) then it watches the PIT counter until the required time has passed. When the CPU is too slow, the PIT counter will have already passed the target so there is no waiting, and ultimately the music just plays more slowly. (There is also a remote possibility that we are SO slow that the PIT counter has overflowed more than once since the last time it was polled, making it uncertain whether we are 'early' or 'late', but this would only lead to an unnecessary additional delay, and shouldn't happen in practice.)

I haven't had and probably won't have the time, but I've wondered how much using assembly language would help when using this particular approach with the "raw" (i.e. not pre-processed) data; there's a lot of overhead introduced by the compiler.

TheMechanist wrote on 2024-06-23, 10:43:

Oh my god, I'm just a dumb as***** .. I've been racking my brains for ages about the delays in the VGM file and didn't realize, that there are a lot of FM commands in line without any delays - that I forced to wait with my interrupt routine for some ms *facepalm* ... now FM replay with 172 Hz is no problem, maybe lower too, but still thinking about advantages betweend 1000 Hz (nice time / speed calc as a side effect) or 60 Hz (like a frame counter) ...

vgm2txt is a great tool to see what's contained in the VGM data. The format is essentially: "keep sending data to the audio chip until a delay is encountered". Depending on what's in the VGM data, 60Hz can be adequate.

Actually I'm using SBVGM a lot with OPL3Lpt. I know that we are talking about analogue equipment and that sound can changes... but what I've noticed seems to me more like a pattern so I'll try to write about this here.
I'm doing all recordings with -r2 Option. Analyzing all recording with reaper, it seems like that Lufs-M always get higher during the 3rd loops, with a differences of about 0.4.
Maybe this could help. There's no significative differences in peak.
Thank you. Aldo

RetroGC wrote on 2025-01-31, 10:12:

Actually I'm using SBVGM a lot with OPL3Lpt. I know that we are talking about analogue equipment and that sound can changes... b […]
Show full quote

Actually I'm using SBVGM a lot with OPL3Lpt. I know that we are talking about analogue equipment and that sound can changes... but what I've noticed seems to me more like a pattern so I'll try to write about this here.
I'm doing all recordings with -r2 Option. Analyzing all recording with reaper, it seems like that Lufs-M always get higher during the 3rd loops, with a differences of about 0.4.
Maybe this could help. There's no significative differences in peak.
Thank you. Aldo

I can't say for certain, but it's possible that the designated loop position in the VGM file is incorrect which could cause the pitch to be higher. If you could point me to the VGM that exhibits the problem I can take a look at it when I have a large enough block of time to take a look.

I've noticed this while editing heretic OST, track 10.
Aldo

RetroGC wrote on 2025-02-05, 14:14:

I've noticed this while editing heretic OST, track 10.
Aldo

Thank you. I just realized that I misread your original message and thought the issue was with the pitch and not the volume levels. I'm not all too familiar with Lufs-M, but hopefully my ears are still good, but when I get some time I can examine the VGM data to see what could be going on.

Out of curiosity, does the recorded Heretic: The Crypts on VGMRips.net exhibit the same issue?

HI,
I've used that VGM on OPL3Lpt, i can try to record that VGM not on real hardware but on somethinkg like ChipSynth PortaFM in case.

SBVGM v1.46 is available from http://www.oplx.com/code/

This update includes:

• Added support for Mindscape Music Board.
• Fixed latent dual AY-3-8910 bug that could cause crash on start up.

Thanks to @FreddyV for adding in Mindscape Music Board support to PICOMEM!

Hi guys! someone knows if exist a frontend for SBVGM? like support for m3u, etc thanks

Can you please change the frequency in software for OPL1 from 4Mhz to 3.58Mhz just like OPL2 as it's supposed to be? Thanks

BlackVega wrote on 2025-07-02, 19:28:

Can you please change the frequency in software for OPL1 from 4Mhz to 3.58Mhz just like OPL2 as it's supposed to be? Thanks

SBVGM only displays the noted clock frequency of the chip's VGM data.
Some arcade games used a 4MHz clock for the OPL1; this is likely why it's at 4MHz which is within the 2MHz to 4MHz input clock frequency range as mentioned in datasheet.

OPLx wrote on 2025-07-02, 22:27:

BlackVega wrote on 2025-07-02, 19:28:

Can you please change the frequency in software for OPL1 from 4Mhz to 3.58Mhz just like OPL2 as it's supposed to be? Thanks

SBVGM only displays the noted clock frequency of the chip's VGM data.
Some arcade games used a 4MHz clock for the OPL1; this is likely why it's at 4MHz which is within the 2MHz to 4MHz input clock frequency range as mentioned in datasheet.

Aha so does that mean SBVGM simply cannot reproduce sound correctly for chips using frequencies other than 3.58Mhz?

BlackVega wrote on 2025-07-03, 21:05:

OPLx wrote on 2025-07-02, 22:27:

BlackVega wrote on 2025-07-02, 19:28:

Can you please change the frequency in software for OPL1 from 4Mhz to 3.58Mhz just like OPL2 as it's supposed to be? Thanks

SBVGM only displays the noted clock frequency of the chip's VGM data.
Some arcade games used a 4MHz clock for the OPL1; this is likely why it's at 4MHz which is within the 2MHz to 4MHz input clock frequency range as mentioned in datasheet.

Aha so does that mean SBVGM simply cannot reproduce sound correctly for chips using frequencies other than 3.58Mhz?

Real-time clock conversion takes a lot of processing power. Best to adjust your vgm files on a modern rig with vgm-conv to match the speed your chips actually run at:
https://github.com/digital-sound-antiques/vgm-conv

BlackVega wrote on 2025-07-03, 21:05:

OPLx wrote on 2025-07-02, 22:27:

BlackVega wrote on 2025-07-02, 19:28:

Can you please change the frequency in software for OPL1 from 4Mhz to 3.58Mhz just like OPL2 as it's supposed to be? Thanks

SBVGM only displays the noted clock frequency of the chip's VGM data.
Some arcade games used a 4MHz clock for the OPL1; this is likely why it's at 4MHz which is within the 2MHz to 4MHz input clock frequency range as mentioned in datasheet.

Aha so does that mean SBVGM simply cannot reproduce sound correctly for chips using frequencies other than 3.58Mhz?

SBVGM can reproduce the sound correctly.

SuperDeadite wrote on 2025-07-03, 23:53:

BlackVega wrote on 2025-07-03, 21:05:

OPLx wrote on 2025-07-02, 22:27:

SBVGM only displays the noted clock frequency of the chip's VGM data.
Some arcade games used a 4MHz clock for the OPL1; this is likely why it's at 4MHz which is within the 2MHz to 4MHz input clock frequency range as mentioned in datasheet.

Aha so does that mean SBVGM simply cannot reproduce sound correctly for chips using frequencies other than 3.58Mhz?

Real-time clock conversion takes a lot of processing power. Best to adjust your vgm files on a modern rig with vgm-conv to match the speed your chips actually run at:
https://github.com/digital-sound-antiques/vgm-conv

In the case of SBVGM, the cost is primarily memory since the necessary frequency conversion tables are generated at start up. It doesn't do the chip-to-chip (like YM2612 to YM2413) conversions though; that's just too high of a runtime cost.

OPLx wrote on Yesterday, 02:20:

SBVGM can reproduce the sound correctly.

Nope not really. It's close but it doesn't quite reproduce some arcade OPL audio files perfectly. It's decent but some notes are off or wacky but maybe it's a matter of constantly perfecting the software over time

BlackVega wrote on Yesterday, 13:46:

OPLx wrote on Yesterday, 02:20:

SBVGM can reproduce the sound correctly.

Nope not really. It's close but it doesn't quite reproduce some arcade OPL audio files perfectly. It's decent but some notes are off or wacky but maybe it's a matter of constantly perfecting the software over time

Could you point me to the VGM data does it not work correctly on? That way I'll have something to validate against when I have a large block of time to look into the issue. Thank you.

OPLx wrote on Yesterday, 14:34:

Could you point me to the VGM data does it not work correctly on? That way I'll have something to validate against when I have a large block of time to look into the issue. Thank you.

Please see Cosmo Police Galivan:
https://vgmrips.net/packs/pack/cosmo-police-g … -police-galivan

All tracks sound a little off at times. I suspect other tracks from games from the same developer will do the same. Also some tracks from Duke Nukem 2 hang the system completely