vgmrips

Yeah, sorry. Blame my lack of GUI designing skills for that. (or let's just say I don't like making GUIs)

You can try foobar's foo_input_vgm.



BTW:The following message is displayed and you can not send the file (foo_input_vgm_v0.27.7z) to my post.

Quote:

Sorry, the board attachment quota has been reached.

Edit: I attached a file.

I noticed now that drum samples for YM2151 tracks sound a bit better in the site player and in vgmplay than in winamp, so a couple of questions:
1. Can I mute individual channels with it?
2. Can it export to wav or other formats?

You can enable WAV logging and mute channels by editing VGMPlay.ini. Just open it with notepad, every setting is commented.

VGMPlay and in_vgm should sound identical.If there are differences, you either use different versions or it is due to configuration settings. (sample rate, emulated chip sample rate, resampling mode, ...)

I updated to the latest version of in_vgm for winamp but there's no difference, it's less clear in winamp. My settings are the default: https://i.imgur.com/Jtb4kOV.png

I can't record on my PC for a direct comparison but here's a 48khz 16-bit stereo wav export from winamp of the first minute of S1 from Dragon Saber: https://ufile.io/f7j5w

Edit: Logging and muting in VGMPlay works, thanks.

The distorsion seems to be the result of overclipping. Try reducing the plugin's volume to 0 dB.

If that fails, you could maybe choose a higher sample rate (I'm using 192000 Hz) with the mode "Highest, FM Native".

_________________

Sega PCM [1985/1989] | Namco C140 [1987/1990] | Hudson HuC6280 [1987/1995] | Yamaha YM2608 [1988/1996] | Oki MSM6295 [1988/1998]

Good idea but I don't really notice a difference between 0 or even ~10 dB in terms of the distortion. Comparing just the snare (ch17) to VGMplay the samples are a bit distorted there as well, only slightly less perhaps. The main difference seems to be the amount of treble on the samples, there's quite a bit more in VGMplay and the site player than in winamp.

I'll try the other thing.

Edit: Thanks, it was the chip sample mode setting, with "highest, fm native" used the drum samples sound identical to VGMplay as far as I can tell.

Woah! I did compiled in_vgm plug-in with Visual Studio Community 2017 version 15.4.1 running on a Windows 7 64-bit machine.
Such a trip (some afternoon hours) on my seat ... so much things I lucky tried and they acted together!

Do anyone look at compiling warnings and/or some other CD/CI stuff/duties ?

Ah, yeah, I can imagine that upgrading the VC6 project to VS2017 (which is 19 years younger!) is quite a ride.
For a VC6 -> VS2010 (and higher) upgrade, I would probably just recreate the project from scratch, readd all files and port some settings from the old project.

About compiler warnings: I often ignore warnings about precision loss, because VC6 spams them everywhere. But I tried to reduce the amount of warnings GCC throws.
About CI: This might be a possibility for the libvgm-based VGMPlay rewrite. But I don't intent to do automatic releases for each commit on GitHub. Releases with a set version number make bug reporting easier.

I think CI means compile each commit, but not release each commit. I think CI and releases are two separate things IIRC.

_________________
vampi.tech

I did the same thing for VGMPlay.exe, i.e. I compiled VGMPlay.exe with Visual Studio Community 2017 version 15.4.1 running on a Windows 7 64-bit machine.
I followed the same pattern, which is not ortodox at all, but it works for me, of mixing both
Windows Kits 8.1, which i think it is main target since I set on General panel Windows SDK version 8.1 for myWindows 7 machine
and adding libraries directory search path
C:\Program Files (x86)\Windows Kits\10\Lib\10.0.16299.0\ucrt\x86
C:\Program Files (x86)\Windows Kits\10\bin\10.0.16299.0\x86\ucrt
in order to link latest ucrt.lib;vcruntime.lib;

Before that I always used VGMPlay compiling it with MinGW64 from Lavavej( https://nuwen.net/mingw.html )/MSYS on Windows boxes and GNU gcc on Ubuntu GNU/Linux boxes. Now I can try with MSYS2.

Bye!

Is it just for me or can the second chip for 2x Multi PCM soundtracks not be accessed for muting or disabling? Tried in winamp so far.

Thanks for the report. I forgot to allow the second MultiPCM to be muted in in_vgm.

I just had a few tries at compiling VGMPlay with VC2010 and VC2017 and added a VC2010 project to the GitHub repository.
In order to build with VC2010, you should just need to open the project and compile. It happily links against the static zlib libraries built with VC6.
For a x64 build you need to need to download the zlib sources and build the "zlibstat" project in contrib/vstudio/vc10. Make sure to set the character set to MBCS. You need to put the libraries in VGMPlay's zlib folder as zlibstat64d.lib (x64 debug build) and zlibstat64.lib (x64 release build).

VC2017 is where it gets a bit more difficult. It is very nitpicking about static libraries and doesn't even like the VC2010 builds.
I had to build new static versions of zlib, again with Multi-Byte Character Set setting. As "platform toolset" I chose v141_xp. You then copy the resulting files into VGMPlay's zlib folder as zlibstat32d.lib (Win32 debug), etc. (see VC2010)
Before compiling VGMPlay in Win32 debug mode you need to open the VGMPlay project settings -> Linker -> Input and swap "zlibd.lib" with "zlibstat32d.lib". You also need to ensure that the platform toolset is v141 or v141_xp to make everything work.
The process for doing x64 build is the same as with VC2010.

btw: If you're doing a 32-bit build, you can just link against zdll.lib and you won't have problems even with VC2017.

Addendum to compiling zlib with Visual Studio:
Remove ZLIB_WINAPI from the project's preprocessor definitions!
If you don't, you will get linker errors with 32-bit builds, because it makes all functions use the __stdcall calling convention (via WINAPI define, see zconf.h). However VGMPlay expects __cdecl calls (because that's what zlib1.dll uses), so it fails to find the functions.
Due to a bug in zconf.h, the ZLIB_WINAPI definition currently doesn't affect 64-bit builds, i.e. they always use __cdecl.

Just bumping this to let users know that foo_vgm has received a minor update:

https://ux.getuploader.com/foobar2000/download/209

Changes Listed:
Updating to Foobar SDK 1.4
A memory leak fix
Some minor fixes that weren't listed.

Original Japanese:
[2018-08-18 v0.28]
メモリリークなどのバグがあったのを修正。念のため古いバージョンは使用しないようにしてください。
foobar2000 SDKをv1.4用に更新。
foo_input_vgm_v0.28_for_v1.1.fb2k-componentはfoobar2000 v1.1X～v1.2X用です。
次回からはv1.4用SDKでのみビルドする予定。
使用ライブラリ(MemoryModule)を最新版に更新。
その他細かい修正。