VGMPlay / in_vgm

[ValleyBell]

Time for some updates - and new releases.

Today: VGMPlay 0.50.1 (Win32 and Win64 binary) and in_vgm 0.50.1 (Win32 DLL, ANSI and Unicode version).
Source code can be obtained from GitHub: libvgm, VGMPlay, in_vgm

The VGMPlay updates fixes the file name codepage issue. Now it can finally open and play "スペースハリアー - 03 - Main BGM.vgm".
It also fixes the volume balance of the C140 and C219 chips, which was off in v0.50.0.
All in all it's mostly a bugfix release.

We also now finally have an up-to-date version of in_vgm. Much thanks to ctr to the extensive testing during the last few weeks.
Most things should work just the same as with the old version. But there are a few things to note:

• I merged RF5C68 and RF5C164, as they are basically the same chip, so the RF5C164 is now controlled with the RF5C68 settings.
• YM2612 users: Nuked OPN2 now defaults to unfiltered output. If you want to have the MegaDrive filter back, you need to edit in_vgm.ini and change the "YM2612 NukedType" to 3.
• You can do per-channel panning to the AY8910 and OPNx SSG.
• There is a button "Open INI" in the options dialog now that opens in_vgm.ini in an editor. (The file can be hard to find.)
  Note: Only make changes while Winamp is closed. (Else the plugin will overwrite your changes.)
• You can enable S98 and DRO playback by editing the .ini file.

...oh, and you can select the Nuked OPM core for YM2151 in both players now.

Enjoy!

P.S.: And for the next release, I want to build VGMPlay 32-bit and in_vgm ANSI with Visual C++ 6 again, so that they work under Windows 2000. (Current builds use with Visual Studio 2010, so at least they work on WinXP SP3.)

[cmccaff1]

I'm surprised there haven't been any replies yet!
Thank you very much for sharing this update with us...after more than a year, it is wonderful that VGMPlay and in_vgm are still being updated.
It's ESPECIALLY wonderful that support is being maintained for XP, and that 2000 support may be restored in the future.
I still use XP for many reasons, the number one reason being 'it just works - and works great.'

It is great to see VGMRips still around, and I look forward to seeing what happens with the site and its members going forward.
If I can be of assistance, even if it's not much, I'll definitely try to help when and where possible with anything I can.

Thanks for all of your efforts!

[RingoStarr39]

Does anyone know if the foobar plugin will be updated at some point?
I don't use Winamp anymore and it's much more convenient to load VGM files into foobar than the standalone program.

[lo zaffo]

Hi, today I updated my cloned libvgm repository and compiled again on Windows 10.
Driver problem activation is solved.

Code: Select all

C:\Users\gzaff\Devs\libvgm\build>bin\Release\player.exe ".\..\..\..\Music\BotB 32055 JonKaruzu - Be Worst Game Cheat-litchy.vgz"
Opening Audio Device ...
Using driver DirectSound.
Opening Device 0 ...
Loading BotB 32055 JonKaruzu - Be Worst Game Cheat-litchy.vgz ...  VGM v161, Total Length: 138.78 s, Loop Length: 0.00 s
Song Title: Be Worst Game Cheat-litchy
Song End.38.73 / 138.78 ...
Done.

Previously I needed to manually disable some drivers selection, now disabling is not required.

Code: Select all

C:\Users\gzaff\Devs\libvgm\build>cmake -D AUDIODRV_WASAPI=OFF -D AUDIODRV_XAUDIO2=OFF ..
C:\Users\gzaff\Devs\libvgm\build>cmake --build . --config Release

I would like to know, if possible, did somebody work on this issue?

Thank You for keeping libvgm moving fast!

Giangiacomo

[Some years later comment] Now that I'm aware of CMake CACHE variables, I get a different sense out of it and I'm okay.

[ValleyBell]

IIRC I made the "player" application use the first device on Windows (usually WinMM) and the last device on Linux (PulseAudio or libao).
It is still a hack, but that is what works best.
(ALSA is not always the optimal solution on Linux. WASAPI under Windows requires a certain output sample rate.)

Keep in mind that just updating the cloned repository keeps the CMake config intact.
So XAudio2 and WASAPI are probably still disabled for you.

[musicalman]

Hi,
I'm about to give an error report but I'm out of my element here, so apologies in advance if I'm saying a bunch of stuff that isn't helpful.

My VGMPlay version is 0.50.1.

I've been messing with mml2vgm (https://github.com/kuma4649/mml2vgm/releases)

When I try to use QSound, I run into trouble. Sometimes the vgm file plays fine, but often these files crash VGMPlay, giving a "The instruction referenced memory which cannot be read" error. If I recall, this also happened with version 0.40.8.

I've tried the in_vgm plug-in for Winamp which similarly crashes and generates a Winamp error report. I've attached it in case it would be helpful.

The crash only occurs with the superctr core; if I switch to mame it seems to resolve, but then you lose all the QSound processing goodness.

Also, the crash does not occur on the files I've downloaded from vgmrips with either core. Maybe i just got lucky, but they seem to be a lot more stable.

I'm fairly convinced this is an mml2vgm issue, but I'm nowhere near well-informed enough to be certain, or to communicate with the dev about it. The language barrier would make this challenging even if I did know what I was talking about. But I've attached a vgm file to this post which causes a crash (it's just the included QSound test file so it's nothing special). Hopefully that will be a good start to working out whether mml2vgm or VGMPlay should take more of the blame lol. From the limited understanding I have, QSound is a bit finicky to work with and emulate in the VGM format, so perhaps this is a symptom of that?

If anything else would be useful, please let me know. Otherwise, Any insight would be greatly welcome.
Thanks!

[ctr]

Hi,
I'm about to give an error report but I'm out of my element here, so apologies in advance if I'm saying a bunch of stuff that isn't helpful.

I looked at your VGM file. What causes VGMPlay to crash is that the emulated QSound attempts to read beyond the length of the datablock.

Obviously it's bad that it crashes, but I wouldn't say it's an issue in the QSound emulation. Rather, I think it's an unfortunate combination of VGMPlay/libvgm's datablock handling and an issue in the VGM file.

The QSound chip has three ADPCM channels. They were not emulated by the old HLE. When the chip powers on, the ADPCM logic will continuously read samples from the first 64KB of the ROM. This is normal behavior, even if nothing is playing on ADPCM (i.e. they're muted).

The issue is that the VGM file has a datablock that's smaller than 64 KB. Specifically, the "ROM Size" is set to 48768 bytes (0xBE80). This will cause the ADPCM logic to eventually read past the allocated size of the datablock, causing the crash.

To fix, the ROM size should always be set to a value greater than 0x10000. I tried hex-editing the VGM file (setting the bytes at 0x107-0x10A to 00 00 01 00) and that prevented the crash.

[musicalman]

Hi, thanks for the reply!
Yeah, that makes sense. I can confirm that the fix works on my end. I tried it on my wip QSound files and so far am successful.

I hope including other chips in a file along with qSound won't complicate this too much, because right now, this is as simple a fix as I could hope for lol

[ValleyBell]

I actually consider that a bug of the QSound emulator - or rather the libvgm version of ctr's QSound emulator.
In any case, the bug is fixed in libvgm commit 95c6697.

Thanks for reporting!

[Yntec]

Neither in_vgm 0.50.1 nor in_vgmW 0.50.1 are detected by my Winamp 5.51 (they don't appear on the Input plug-ins list.) in_vgm_w 0.40.9 is working great, so that's what I'm using.

[ValleyBell]

Do you have the "Microsoft Visual C++ 2010 Redistributable Package (x86)" installed? (SP1 or not shouldn't matter, but I'd install the SP1 version just to be sure)

v0.50 was compiled with Visual Studio 2010, so it needs its runtime DLLs (MSVCP100.DLL and MSVCR100.DLL) to work properly.
v0.40 was compilied using Visual C++ 6 (from 1998), which may be the reason the older DLLs work. (They want MSVCRT.DLL instead.)

VGMPlay v0.50 needs the same DLLs, so you could also try to run VGMPlay in order to test whether or not the runtime is installed.

[ValleyBell]

And here we have a new release:

VGMPlay 0.51.0 (Win32 and Win64 binary) and in_vgm 0.51.0 (Win32 DLL, ANSI and Unicode version).
Source code can be obtained from GitHub: VGMPlay, in_vgm

I'll summarize the important improvements first:

• emulation fixes and improvements for OPN series (YM2203, YM2608, YM2610, YM2612) and HuC6280
• fixed a few broken ADPCM sounds in S98 files
• The files are now not locked while being played back.
• added support for GYM files (yes, there is no real reason for it, but it was fun to do)
• [VGMPlay] now supports Media Keys and tells the system where to find album art
• [VGMPlay] added volume control (cursor up/down)
• [VGMPlay] added keys: Ctrl+P (pause after current song), Ctrl+X (close after current song)
• [VGMPlay] show warnings and errors from VGM parser

System requirements:

• 32-bit VGMPlay: Windows 2000 (compiled it with MS VC++6, so Windows 9x may work or not)
  Note: Supports Media Keys, but does NOT support the SMTC media framework.
• 64-bit VGMPlay: Windows Vista (compiled with MS VC2017)
  Supports Windows SMTC (Windows 8 and later), which features display of track title and album art when pressing media keys.
• in_vgm: Windows XP SP3 (compiled with MS VC2010)

Happy listening!

[kyusawamura]

Hi ValleyBell!

I'm experiencing a small problem with in_vgm (ANSI) for Winamp. I installed the ANSI version because I gave up on the Unicode one working, but it seems like that might not be the issue.

I have tried changing the YM2612 NukedTYpe value many different times, to values like:

Code: Select all

YM2612 NukedType=0x01
YM2612 NukedType=0x10
YM2612 NukedType=0x11
YM2612 NukedType=1x01
YM2612 NukedType=1x10
YM2612 NukedType=1x11

And unlike in foo_input_vgm for foobar2000, I'm not getting any different types of emulation. I have tried your suggestion to enable the Mega Drive filtering like this:

Code: Select all

YM2612 NukedType=3x00

but apparently, at least on Winamp, this is the only setting that will work. Everything else does nothing. Assuming that the first number is the MSB and the second 2-digit number is the LSB, I have tried changing the LSB values with the MSB set to 3, like so:

Code: Select all

YM2612 NukedType=3x10
YM2612 NukedType=3x11
YM2612 NukedType=3x01

and still nothing changes. The filter is there because the first number is set to 3, but the chip type never changes. I wanted to try replacing foobar with Winamp, and in this case it would be better since Winamp is ahead of foobar on VGM version support, but with Winamp's in_vgm having less UI components to configure than its foobar2000 counterpart, and the .ini file not working properly, I'll have to resort to foobar2000 if I for any reason want to do exports or just listen to Mega Drive music with the sound of the model 2 instead of the model 1, for example.

Thanks in advance for reading this. Have a great day everyone! ^^/

[ValleyBell]

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.

[Gnome]

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