Code: Select all
[EmuCore]
YM2612=1
Last update: 2023-12-31 (v0.51.1)
Moderator: Staff
Code: Select all
[EmuCore]
YM2612=1
The core is set to NukedOPN2, what I'm saying is that it always sounds like the MD Model 1 YM2612. I want to change it into, say, the Model 2 ASIC YM3438 and that's something I could do in foo_input_vgm for foobar, but couldn't find how to do in in_vgm for Winamp.Gnome wrote:Make sure that your sound core type is set to "NUKE" in the .ini file. It should look like this:Code: Select all
Core = NUKE
I will try this, thank you!ValleyBell wrote:Which value is what is (sort of) documented in VGMPlay.ini.
It should be noted that "0x" is a prefix and the digits after it form the actual number.
i.e. 0x00, 0x01, 0x02, 0x03
You can also just write 0, 1, 2 or 3 in that case.
You may want to reword this, the foobar2000 component hasn't been updated in three years, and is increasingly displaying signs of incompatibility (e.g. OutRunners Arcade, and no doubt much else.)ValleyBell wrote:Comment: not part of the official release, but always up-to-date
I don't know the head from the ass of coding up winamp plugins so I don't know what to make of this, but it sounds like there's a way for in_vgmw.dll to make itself the handler for .vgm files in winamp that it isn't doing, leading in_vgmstream to be used incorrectly to play the files. It's not the end of the world as I can simply rename the plugin to get around this clashing issue, but I think this might be something to look into for future releases.Aha, if you rename in_vgmW.dll to in_vgm.dll, or in_vgmstream.dll to in_zvgmstream.dll (or anything, as long as vgmstream's .dll goes after in_vgm's dll in the plugin folder) that should fix the issue.
Here is what's going on:
Winamp first loads plugins as found in the plugin folder (ordered by filename), and asks every plugin if it supports the file (checking the contents). If nobody "claims" it, then it'll pass it to the first .dll that reports accepting the extension (without looking at the contents).
vgmstream now ignores non-streamed .vgm (used to "claim" it before), but in_vgm doesn't directly "claim" .vgm by content (it's common for most plugins to just leave it to the extension matching). Both .dll report accepting .vgm, so which plugin gets the .vgm is decided by the filename order.
This would be your order:
in_vgmstream.dll
in_vgmW.dll
But I had this, so the issue didn't trigger for me:
in_vgm.dll
in_vgmstream.dll
So basically renaming either would work as long as vgmstream goes after.
Can't really fix this, other than setting an option to not to report any extensions or something. That affects the open dialog and file types associations though. For now will write some info in the guide. Maybe you can bring it up to the in_vgmW.dll's author to just call it in_vgm.dll, or "claim" the file during IsOurFile to avoid these clashes.
Code: Select all
VGMPLAY caused an invalid page fault in module MSVCP60.DLL at 167:780c865a