DjLc wrote:

I've some troubles with the Flashback's rip. […]
Show full quote

I've some troubles with the Flashback's rip.

SBVGM version 1.14
MSDOS 6.22 386DX40 with real AdLib (original not clone) card (port 388).

Logo and Introduction tunes are randomly out of tune/wrong speed/missing instruments. I've the game installed on the same machine to compare.
Sometime the tune start wrong, but after a couple of notes, instruments become right, as if instrument initialization sometime failed to load. Maybe it's a problem with the rip and not with sbvgm. I didn't test the rest of the tunes.

Thanks.

Thank you for the feedback. I tried those two VGMs on my Sound Blaster and there are some issues with the songs. Off the top of my head it could be tied to the optimizations that I did with the reducing the delay times between address and data register writes; I'll have to tweak those delay values to be sure. I also have a real Adlib card so I will check with that one as well. Thank you for letting me know. Hopefully I can give you some feedback soon.

[Edit]
It turns out that the problem was that the VGM does not initialize the hardware to a proper state (in this case, all registers set to 0).
I've updated SBVGM to take this into account and you can download the latest version here: SBVGM115.ZIP.
Thank you again for bringing this to my attention.

Wow 1.15 already! Gotta upgrade all my computers from 1.11 to 1.15 and stop idling around 🤣
I am very glad to see development on your player and I was hoping that the new init routine in the 1.15 would somewhat fix a strange problem with one of my favorite soundtrack. But no 😢 it's even the same with 1.08 where you found a bug that prevent this soundtrack to play (remember castle.vgm 😊).

So I will take the liberty to express what I think is a problem, I'm not sure we talked about it already. What I think is the snare on the opll version of the miracle warrior (bad_opll.vgm) is really annoying, way too loud and/or distinct... I dont know but it waste that otherwise correct music. The PSG (sn76489.vgm) version sound correct, I just added those two examples but this snare thing address the whole soundtrack. I attached another music from an other game that is heavy on the rythm and the snare sound ok (ok_opll.vgm). I guess you know about webvgm, you can see there that bad_opll.vgm and ok_opll.vgm seem to use the same snare. It's odd that there is that problem only on the miracle warrior soundtrack.

:edit: hehe that was my 386'th post ! and a good one unlike my 256th one 😁

ElBrunzy wrote:

Wow 1.15 already! Gotta upgrade all my computers from 1.11 to 1.15 and stop idling around 🤣
I am very glad to see development on your player and I was hoping that the new init routine in the 1.15 would somewhat fix a strange problem with one of my favorite soundtrack. But no 😢 it's even the same with 1.08 where you found a bug that prevent this soundtrack to play (remember castle.vgm 😊).

Yes! The player has been worked on a little here and there as bugs show up.

ElBrunzy wrote:

So I will take the liberty to express what I think is a problem, I'm not sure we talked about it already. What I think is the snare on the opll version of the miracle warrior (bad_opll.vgm) is really annoying, way too loud and/or distinct... I dont know but it waste that otherwise correct music. The PSG (sn76489.vgm) version sound correct, I just added those two examples but this snare thing address the whole soundtrack. I attached another music from an other game that is heavy on the rythm and the snare sound ok (ok_opll.vgm). I guess you know about webvgm, you can see there that bad_opll.vgm and ok_opll.vgm seem to use the same snare. It's odd that there is that problem only on the miracle warrior soundtrack.

Well, in regards to this issue I have some good news: I have known that the OPLL implementation in SBVGM likely has some bugs. One of the things I had hoped to be able to do was get a hold of an actual OPLL chip to do some tests with as I have discovered that sometimes even though the Yamaha chips are in the same family there might be subtle timing differences or behaviors. For example, I found out that there are quite a number of games that change the OPLL's state from rhythmic mode (6 melodic, 5 percussive channels) to melodic mode (9 melodic channels) while the music is playing and (so far) I have not seen this usage pattern with any of the VGM's that use the OPL2. Having the actual hardware on hand makes it easier to verify certain things.

Hopefully the problem that you are hearing is simply a bug and not how the OPLL and OPL2 handle switching between rhythmic and melodic mode on the fly. I am a bit pressed for time at the moment, but I will take a look at the OPLL specifications again and see where the bug likely is.

Thx for the update and goodjob for finding the problem. Flashback's vgm are properly played now.

Keep up the good work !

Great a music player that supports my T1000RL 😀
Where can I get suitable soundfiles for it?

Thx

dr.zeissler wrote:

Great a music player that supports my T1000RL 😀
Where can I get suitable soundfiles for it?

Thx

I found this site to have many : http://vgmrips.net/packs/
this site seem to have many too : https://www.zophar.net/music/sega-master-system-vgm
I found some on aminet and other demoscene dump as some artist made music out of this format. Oplx posted this great archive http://opl.wafflenet.com/ and you better check it out as I had to re-read the whole thread to find it back on page 5 🤣
Oplx made a table on the readme of this player and I made another when I was searching the vgmrip site to keep track of my scraping, I posted it in the hope to help someone else, here is my chance 😉 : SBVGM (DOS) VGM Player

Version 1.16 is released with some improvements for YM2413 support: SBVGM116.ZIP

OPLx wrote:

Version 1.16 is released with some improvements for YM2413 support: SBVGM116.ZIP

Yeah great that fixed it -- many thanks !

ElBrunzy wrote:

OPLx wrote:

Version 1.16 is released with some improvements for YM2413 support: SBVGM116.ZIP

Yeah great that fixed it -- many thanks !

Awesome! 😀

vibrants.dk down for everyone or just me? Thanks for the new version!!

pred wrote:

vibrants.dk down for everyone or just me? Thanks for the new version!!

You're welcome! 😀
I believe vibrants.dk is gone forever, but Miscellaneous Files at Chordian.net might have want you are looking for.

Very interesting project ! Will give it a try. I'm now searching for a long time for DOS based music players, that support OPL2 for different music files ..

Can I force playback on OPL2 ?
Will you support POKEY ? Love that tunes but didn't find any Adlib DOS player for it ..

TheMechanist wrote:

Can I force playback on OPL2 ?

you can use -a to force adlib, see -h for some help, maybe oplx could add the usage text into the sbvgm.txt? To force playback on the opl2 with unsuported chip, I asked about it before but I cannot find the page, not very conclusive...

Hi, OPLx!

It seems that SBVGM does not yet support VGM stream commands. They can be very useful for some songs; I have attached one of them. It's the title screen music from the 1989 Electronic Arts game "688 Attack Sub", played on the Tandy 1000. The game plays PCM samples by manipulating the volume register of one the SN76489's square wave channels. The "688 Attack Sub Title Screen (PCM as track data version)" would be compatible with SBVGM if it were not for the excessive memory usage --- all the PCM data is just included in the form of individual register writes --- making it impossible to play the file on a Tandy 1000, which does not have XMS memory. The "stream command version" saves space by including each PCM instrument only once, and by having the VGM player send the PCM data bytes to the chip at appropriate intervals. At 140 KB size, the file can easily fit into the Tandy 1000's memory.

NewRisingSun wrote:

It seems that SBVGM does not yet support VGM stream commands. They can be very useful for some songs; I have attached one of them. It's the title screen music from the 1989 Electronic Arts game "688 Attack Sub", played on the Tandy 1000. The game plays PCM samples by manipulating the volume register of one the SN76489's square wave channels. The "688 Attack Sub Title Screen (PCM as track data version)" would be compatible with SBVGM if it were not for the excessive memory usage --- all the PCM data is just included in the form of individual register writes --- making it impossible to play the file on a Tandy 1000, which does not have XMS memory. The "stream command version" saves space by including each PCM instrument only once, and by having the VGM player send the PCM data bytes to the chip at appropriate intervals. At 140 KB size, the file can easily fit into the Tandy 1000's memory.

We've already solved the memory issue in another way, we stream the VGM data from disk, instead of requiring it to be entirely in memory:
https://youtu.be/ARE6Bzs7Aj4

It does require a system with a DMA-enabled HDD controller though.

Implementing stream commands would complete the VGM format implementation and is the more elegant solution, elegant as in being entirely software-based. 😀

In other words, I don't have a DMA-enabled HDD controller. 🙁

NewRisingSun wrote:

Implementing stream commands would complete the VGM format implementation and is the more elegant solution, elegant as in being entirely software-based. 😀

But can you reliably capture VGMs that way?
I mean, Rob Hubbard's music system is basically a single-channel mod player, and it uses all sorts of effects like portamento, volume changes etc to play the samples. I don't see how VGM's stream command can be deduced from the register writes when capturing.

Sure, by hacking the player code, naturally. I've already finished Skate or Die, 688 Attack Sub, Jordan vs. Bird, and Kings of the Beach (attached). It's basically the same code, with only minor differences between games. And the MOD player only supports portamento, not volume changes. There are only four hooks necessary for complete VGM capture: normal (non-PCM) TI write, PCM start, PCM stop, and PCM change rate.

Note that VGMPlay-based players so far have a bug when changing the sample rate while a PCM stream is already playing. That bug is fixed in libvgm.

Well, that's my point... you can't capture such VGMs directly from an emulator.
Not that it would matter much in this case, since there are only 4 games that I know of, which are the aforementioned ones.

I'm pretty sure the player does support volume changes though. Not sure if they're actually used... But I've reverse-engineered the routines as well, and it's basically split up in two parts:
1) The mainloop, which is synced to VBL (which is why there's only a static image on screen, no animation), which plays the 'regular' SN76489 music on 3 of the 4 channels at 60 Hz. It could perform volume changes on the 4th channel as well, where the samples are played. It also controls the speed of the timer interrupt, which is effectively the sample rate of the current sample playing.
2) The 'PCM' handler, which is hooked into the timer interrupt. This plays one sample everytime it fires, and also takes care of looping and such.

Mind you, I suppose the volume changes wouldn't even have to be done in the PCM part. If they are just captured as register writes, it would work fine. They'd only change at 60 Hz at most, so much lower data rate than the PCM data.

I'll have to think about how to integrate the stream command with the current replay routine. The current replay routine pre-processes the entire stream of VGM-data to a list of PIT counts and data bytes. This optimization was necessary to make realtime sample playback possible on an 8088 at 4.77 Mhz.
With the introduction of streams, the data now needs to come from some sample buffer, instead of directly from the pre-processed stream. For this specific case, assuming there is only one sample channel, it may be possible to do it realtime on an 8088, with a routine similar to Hubbard's own. But in the general case, you can neither assume that the regular song logic runs at 60 Hz (and can therefore be timed to VBL), nor can you assume that there is only one PCM channel, so only one active sample pointer at any time. Trying to make that work on an 8088 at 4.77 MHz seems impossible at first sight.

I think it sort of defeats the point of VGM to make a player that can ONLY play the 4 Hubbard songs in realtime. If that's what you want, you might as well rip the original code out of the game directly.

Scali wrote:

Mind you, I suppose the volume changes wouldn't even have to be done in the PCM part. If they are just captured as register writes, it would work fine. They'd only change at 60 Hz at most, so much lower data rate than the PCM data.

How would you do volume changes as register writes if the PCM data itself is written as a volume change on channel 0?

One way to support streams on 8088 would be to pre-process by expanding the VGM file with stream commands into the original simple register log upon loading. But then we're back to the huge memory requirements. It could be done piece-by-piece though --- expanding 10 seconds ahead at a time, or so.

I didn't know that you took over SBVGM from OPLx. 😀