New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[VGMplay] Weird playback issue with a CPS-2 title #6824
Comments
If you hit F11 to show the current frame rate, does it show that you're running at 100% of full speed, or some value less than that? What you describe seems similar to how the audio of an emulated machine sounds if the system isn't running at full speed. |
AFAIK most (all?) of the QSound related rips were hand crafted and some data may not be present/stripped from the data, only covering known registers back before actual emulation of QSound, not using HLE. Outside of that, the QSound emulation is activated for vgmplay and requires a decently beefy CPU to keep in the 100% speed during playback and I agree with @MooglyGuy that it sounds like your CPU may not be up to snuff. With my i5 4570 (3.2ghz) I don't get 100% without some frameskip (using AUTO seems to get there eventually). |
The computer I'm running this on has an i7-9750H (2.6Ghz base, 4.5Ghz turbo), should be more than enough as far as I'm aware. The framerate shows 100% for a majority of the time, but for some reason it randomly dips down to ~90%, then up to around ~105%, and then back to 100% again, which must be causing some desyncing. Though task manager showed that the CPU wasn't even at 25% utilization when music was being played, so I wouldn't blame it just yet. I didn't blow a thousand dollars on a gaming laptop for nothing, lol. |
If you switch to a per cpu core usage display instead of overall, that is likely maxing out 1 core and that's what is causing the problem. |
I'm been aware that several CPS1/2 VGM dumps don't play correctly with our LLE, Slam Masters |
I'm not sure if this has been fixed at this point, but I recall that the |
Also, since I just remembered. There's a hack that needs to be added to properly play back some old VGMs since the old |
I think we're hoping that the files get re-ripped, so they don't have
have too much removed and also with correct write timing.
…On 15/07/2020 11:37, superctr wrote:
Also, since I just remembered. There's a hack that needs to be added
to properly play back some old VGMs since the old |vgm_cmp|
optimization tool removed too many register writes. See here
<https://github.com/ValleyBell/libvgm/blob/master/player/vgmplayer_cmdhandler.cpp#L1158>.
|
I'm afraid that won't happen, as the correct write timing is not possible for the reasons I just mentioned. Also some of the people who made the CPS2 packs on vgmrips.net have simply left or don't have the original files, so it's not possible to re-optimize. |
For all purposes and intents the CPS2 (actually QSound) current dumps are considered bad_dumps. Just the same as any other romset that internally sports bitrot or whatever really. |
On 19/07/2020 19:49, superctr wrote:
I'm afraid that won't happen, as the correct write timing is not
possible for the reasons I just mentioned.
Your reasoning seems circular.
vgm is literally a set of writes and how much time to wait between them.
If it can't store the correct timing, then the format needs fixing.
But is it that it can't store the correct time, or nobody can be bothered?
Sound chips are sensitive to write timing, so if the vgm are wrong and
will never be fixed then maybe it should just be abandoned?
|
Ok, sorry for this wall of text. If anything is unclear, just let me know. There are a few legacy reasons to why the busy wait needs to be done inside the player:
And finally, one thing to mention. Currently QSound is the only chip supported by the MAME vgm player that actually cares about the wait interval between writes, but most Yamaha FM chips (and possibly other chips) will also have a similar wait interval, even if this behavior currently isn't emulated in MAME. As the emulation of those chips improve, more and more VGM files will become broken, and at some point you would question why the VGM files play back correctly in any other player, and even on real hardware, but not in MAME. You could argue that the VGM logs are bad, but in that case they will simply stay broken forever as no one will have the incentive to re-log a VGM that works fine on every other player, including real hardware. I suggest reserving the "bad dump" keyword for VGM files that actually are unplayable on real hardware, disregarding the timing issue. The QSound packs that used the old optimization tool would be an example for that, even if they could be fixed using a hack. Another example is the Project2612 Rocket Knight Adventures pack, since it does a lot of nasty stuff, including garbage writes to the test register. |
On 19/07/2020 23:41, superctr wrote:
You could argue that the VGM logs are bad, but in that case they will
simply stay broken forever as no one will have the incentive to re-log
a VGM that works fine on every other player, including real hardware.
There is little incentive to make complex changes to vgmplay.cpp to cope
with files that are by it's very definition, innaccurate. I think we
actually did quite well considering
I personally don't understand the reason for using the LLE qsound core
in vgmplay and the HLE qsound core for game play, I think I did all my
vgmplay testing on the HLE core as my machine wasn't fast enough at the
time to run the LLE core anyway.
|
Due to the Covid situation, I'm stuck using my work PC at home, and as beastly as it is, it can't cope with the LLE core either. I understand the desire to prevent code rot by having the LLE core present and accounted for in builds, but it might be better to make the HLE/LLE switch a runtime flag (similar to -drc/-nodrc) and have vgmplay default to HLE. |
A way of being able to add a list of possible devices (which could share
the same base/interface) that the user could select between at
boot/runtime would be quite useful.
…On 29/07/2020 19:41, MooglyGuy wrote:
Due to the Covid situation, I'm stuck using my work PC at home, and as
beastly as it is, it can't cope with the LLE core either. I understand
the desire to prevent code rot by having the LLE core present and
accounted for in builds, but it might be better to make the HLE/LLE
switch a runtime flag (similar to -drc/-nodrc) and have vgmplay
default to HLE.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#6824 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACGVYYVD6JKZI3PZNAI2BALR6BUMTANCNFSM4N5A3BVA>.
|
Not sure if anyone has reported this before or not, but when playing back some music from 1944: The Loop Master, they end up sounding very off. I did get an error saying that it had detected a bad rip, but the music plays just fine when running the game itself.
For example, when playing the third song (Deep Blue), the guitar randomly stops playing in-between each beat, as well as the drums a little. Same thing happens when trying to play the opening music. Funnily enough, the instrument cutting out in that one is also the guitar. I'd assume every song has the same or similar issue when playing them back, but I haven't had time to test them all.
Still, there may have been some incorrect settings that I missed, or I didn't have something in order... or it could be that I really do have a bad rip after all.
The text was updated successfully, but these errors were encountered: