... 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.