[VGMplay] Weird playback issue with a CPS-2 title

[Epictyphlosion]

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.

[MooglyGuy]

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.

[Tafoid]

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).

[Epictyphlosion]

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.

[Epictyphlosion]

Here's a screenshot of the CPU usage. Red line indicates when VGMplay was started.

[Caedhros]

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.

[angelosa]

I'm been aware that several CPS1/2 VGM dumps don't play correctly with our LLE, Slam Masters 008 Moscow and Cadillacs & Dinosaurs 015 boss 2 comes into mind (which also reports bad rip detected, correcting qsound clock in terminal) Given the context once I start overhauling the DB I'm gonna mark these as bad_dump .

[Epictyphlosion]

Good thinking, @Caedhros. Turns out it wasn't utilizing all the cores, and the second one was getting maxed out for some reason. Might be causing a bottleneck.

Sounds good, @angelosa.

[superctr]

I'm not sure if this has been fixed at this point, but I recall that the vgmplay driver doesn't honor the required wait time between writes to the QSound chip. Since VGM files can't detect how long the chip will be busy after each write, it is expected that if the chip requires a wait between writes, the player should buffer those if needed.

[superctr]

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. This affects both the new HLE and the LLE. See here.

[smf-]

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.

[superctr]

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.

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.

[angelosa]

For all purposes and intents the CPS2 (actually QSound) current dumps are considered _baddumps. Just the same as any other romset that internally sports bitrot or whatever really.

[smf-]

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?

[superctr]

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:

1. The busy wait intervals were not considered when the VGM file format was created. One of the reasons why the format was created in order to replay music on real hardware. Originally, only 8-bit Sega consoles were supported. The CPU couldn't support such fine intervals, so the timings would be quantized in the player. Since the sound chips (especially Yamaha FM chips) still required a minimum wait interval, this wait would be ensured by the player, since any fine timing intervals would have been stripped. You'll also see that many VGM files hosted by smspower.org have all waits shorter than 1/60 seconds stripped, for those reasons. Newer hardware can supporter finer timing intervals, however they will still buffer writes in order to not overload the sound chip.

2. The minimal delay in a VGM file is 1/44100 second (22 microseconds). This isn't precise enough for the actual busy wait required by many sound chips. Especially Yamaha chips will actually usually become ready much faster than the busy flag tells you. For example, the YM2612 may actually require between 47 and 83 cycles after a write. Considering a Mega Drive's clock speed, this corresponds to 5-10 microseconds. This means that a logged VGM from an accurate emulator could have 2 YM2612 writes in the same 44100 Hz "sample". Obviously the chip will drop one of the writes if you do them at the exact same time, so you will need to buffer the writes.

3. VGMs generated by trackers and tools or converters other than emulators often don't take into account the busy time at all, and will put all writes for a frame in the same VGM sample. Although this shouldn't apply to Project2612 and vgmrips packs, this does apply to the SMSPower packs, as I have mentioned.

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.

[smf-]

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.

[MooglyGuy]

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.

[smf-]

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 https://github.com/mamedev/mame/issues/6824#issuecomment-665834662, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACGVYYVD6JKZI3PZNAI2BALR6BUMTANCNFSM4N5A3BVA.