vgmrips

The forum about vgm files
It is currently 2021-08-04, 21:14:12

All times are UTC + 1 hour [ DST ]




Post new topic Reply to topic  [ 339 posts ]  Go to page Previous  1 ... 19, 20, 21, 22, 23
Author Message
 Post subject:
PostPosted: 2021-01-16, 23:48:31 

Staff Staff
Programmers Programmers
Musicians Musicians
Contributors Contributors
Reverse engineers Reverse engineers
Online
User avatar

Joined: 2011-12-01, 20:20:07
Posts: 3588
Location: Germany
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.)


Top
 Profile  
 
 Post subject:
PostPosted: 2021-01-22, 22:08:04 
Offline

Joined: 2021-01-06, 5:20:01
Posts: 12
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!


Top
 Profile  
 
 Post subject:
PostPosted: 2021-02-22, 4:18:45 
Offline

Joined: 2018-10-25, 23:31:30
Posts: 4
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.


Top
 Profile  
 
 Post subject:
PostPosted: 2021-03-13, 16:46:21 
Offline

Joined: 2016-08-03, 22:36:09
Posts: 29
Location: Italy
Hi, today I updated my cloned libvgm repository and compiled again on Windows 10.
Driver problem activation is solved.

Code:
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:
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


Last edited by lo zaffo on 2021-03-13, 23:38:28, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: 2021-03-13, 19:43:50 

Staff Staff
Programmers Programmers
Musicians Musicians
Contributors Contributors
Reverse engineers Reverse engineers
Online
User avatar

Joined: 2011-12-01, 20:20:07
Posts: 3588
Location: Germany
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.


Top
 Profile  
 
 Post subject:
PostPosted: 2021-07-03, 1:56:07 
Offline

Joined: 2017-07-31, 2:36:01
Posts: 4
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!


Attachments:
report.zip [45.22 KiB]
Downloaded 21 times
testQSound.vgm [52.42 KiB]
Downloaded 26 times
Top
 Profile  
 
 Post subject:
PostPosted: 2021-07-03, 2:50:36 

Contributors Contributors
Staff Staff
Reverse engineers Reverse engineers
Offline
User avatar

Joined: 2013-07-17, 23:32:39
Posts: 468
musicalman wrote:
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.


Top
 Profile  
 
 Post subject:
PostPosted: 2021-07-03, 6:16:50 
Offline

Joined: 2017-07-31, 2:36:01
Posts: 4
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


Top
 Profile  
 
 Post subject:
PostPosted: 2021-07-03, 11:59:14 

Staff Staff
Programmers Programmers
Musicians Musicians
Contributors Contributors
Reverse engineers Reverse engineers
Online
User avatar

Joined: 2011-12-01, 20:20:07
Posts: 3588
Location: Germany
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!


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 339 posts ]  Go to page Previous  1 ... 19, 20, 21, 22, 23

All times are UTC + 1 hour [ DST ]


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
[ Time : 0.024s | 18 Queries | GZIP : On ]