S98 tools

[ValleyBell]

No, we don't accept rips created with pmd2s98.
There are a few packs created with pmd2s98 that slipped though, but we usually insist on emulator logs unless the source format itself is VGM-like.

[Basillica]

I'm trying to do a rip of a game (Highly Responsive to Prayers) because the existing pack is missing some channels, but when I convert the log with S982.exe, the resulting vgms are also missing channels.

I used tails_'s version, because Ancient's builds require the debug versions of the Visual Studio runtime dlls.

The S98 files were logged with Neko Project II.

[Basillica]

I've converted the song from the existing pack to s98 with s98conv.exe, and the missing channels are audible, meaning that the data is there, but it isn't being played back for some reason.

(The VGMs were tested with both foo_input_vgm 0.29 and VGMPlay 0.40.9.)

[ValleyBell]

If you want to do a rerip, then please use the Neko Project 21 VGM mod.
S98 logs are often done with 100 or 1000 Hz. VGM logs are 44100 Hz, so the timing information is more accurate than when using an S98 conversion.

Aside from that, I assume that the S98 logs didn't record the "6ch enable" register state. (register 029h, value 80h)
The YM2608 defaults to YM2203 mode and it needs that command in order to enable YM2608 mode.
You can test this by hex-editing the VGM file. At offset 00E0h, overwrite the first command (56 30 xx) with 56 29 80 (YM2608 mode) or 56 29 00 (YM2203 mode).
I think S98 logs often don't have that command and the player automatically enforces YM2608 mode by itself.

[Ancient]

For Hoot 2019/12/31 Version.

fc /b hoot.exe hoot_65536.exe

00300D2F: 64 00
00300D31: 00 01
0052DCA0: 7B 00
0052DCA1: 14 00
0052DCA2: AE 00
0052DCA3: 47 00
0052DCA4: E1 00
0052DCA5: 7A 00
0052DCA6: 84 F0
0052DCA7: 3F 3E

S98toVGM sources are always open.
https://github.com/Lutepatious/S98toVGM

[Ancient]

hoot.exe (2019/12/31)

300D23h 01 00 00 00 (32bit integer 1)
300D2Fh 64 00 00 00 (32bit integer 100)
-> 1/100

052DCA0 7B 14 AE 47 E1 7A 84 3F (64bit double float 0.01)
-> 0.01 = 1/100

[MaliceX]

hoot.exe (2019/12/31)

300D23h 01 00 00 00 (32bit integer 1)
300D2Fh 64 00 00 00 (32bit integer 100)
-> 1/100

052DCA0 7B 14 AE 47 E1 7A 84 3F (64bit double float 0.01)
-> 0.01 = 1/100

Not sure I understand the last two posts, but the original patch doesn't seem to work anymore for the current exe. And the hex offsets in the past two posts don't appear to match the current binary.

[Ancient]

I'm changed interest to sound conversion.
I've made AliceConv graphics and music conversion tools.

https://github.com/Lutepatious/AliceConv

These sound tools can convert almost all old Alicesoft sounds to VGM.

[ValleyBell]

really cool stuff!

[Knurek]

For Hoot 2023/12/31 Version.

000E29C7: 64 00
000E29C9: 00 01
004FDEE8: 7B 00
004FDEE9: 14 00
004FDEEA: AE 00
004FDEEB: 47 00
004FDEEC: E1 00
004FDEED: 7A 00
004FDEEE: 84 F0
004FDEEF: 3F 3E

I've attached a BPS patch that changes that. Keep the original exe, the logging patch makes the playback that's outputted to the soundcard slower (the generated S98 files play at correct speed though).