Skip to content
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

MSU-1 audio crackling in many games #513

Closed
ToniBC opened this issue Mar 12, 2019 · 6 comments
Closed

MSU-1 audio crackling in many games #513

ToniBC opened this issue Mar 12, 2019 · 6 comments

Comments

@ToniBC
Copy link

ToniBC commented Mar 12, 2019

I put it separately as you told me.

In the emulation of sound with the Chip MSU-1 presents Crackling problems in all versions. Recently in Bsnes v107 (creator of the chip), it supports loading with the same method as Snes9x, but it does not present those problems.

They are present in almost all the games of MSU-1, some are noticed more than others, and not in the tracks of PCM, but in the effects of sound of the game, as if the volume was very high and distorted some effects.

They are quite remarkable in games like Battletoads MSU-1. The same game in Bsnes v107 does not present any error.

Example:

The first rom in the normal, works perfectly, then the same with MSU-1, when the frog appears, the sound effect becomes distorted. So that same MSU rom in Bsnes v107 does not present that problem.
It seems like an overlay of sound by the volume, but I tried to reduce the audio tracks in half and nothing, remains the same. If you remove the audio track the sound of the effects works correctly.

https://www.youtube.com/watch?v=G-tvmWXUfNs

It also happens in Battletoads & Double Dragon and in others, but not all are noticed so much. Some explosion or effect.

@qwertymodo That recording sounds like the pcm files are way too loud, which would definitely cause clipping when mixed with sound effects. However, that's completely unrelated to the original issue for this particular thread, it probably would have been better as a separate issue report. Can you try one of the packs listed in this thread to test out my suspicion that the pcm normalization is at fault?

I have done several tests, reducing the volume of the PCM in half and nothing, it seems that it is reduced a little, but the problems continue. If you remove the PCM track, the problem is solved, but without the music. It seems to be a problem of the volumes when the music is played as you comment, but the same files do not present problems in Higan or Bsnes.

@bearoso
Copy link
Collaborator

bearoso commented Mar 12, 2019

Can you try one of the packs listed in this thread to test out my suspicion that the pcm normalization is at fault?

There is no pcm normalization. That's why the volume can't be too high. The SNES doesn't normally do above 8000 at full amplitude, so half-volume should be adequate. Otherwise we're going to have to average the samples instead, reducing volume by 50% whenever MSU is running, and users will complain again.

@ToniBC
Copy link
Author

ToniBC commented Mar 12, 2019

Also normalize the tracks, but it is not solved. I use the fixed versions of the forum and the latest patches always.

But if it were a problem of the PCM or the volume, in Bsnes it would have to fail also, but no, there they work correctly and with the suitable volume.

In the last Bsnes v107 the manifest is no longer used, it uses the same file structure as Snes9x, and if in an emulator like Bsnes it works well and in Snes9x it works badly, the same file, means that one does something wrong or not It is quite well implemented.

It is also normal for Bsnes to work well, he was the creator of the MSU.

@qwertymodo
Copy link
Collaborator

@bearoso My mention of PCM normalization referred to normalization applied to the files themselves during the conversion process, not anything we're doing during playback and mixing. I agree that averaging would draw complaints, as it did in higan, which is why byuu removed averaging and switched to direct summing somewhere around v100.

@bearoso
Copy link
Collaborator

bearoso commented Mar 12, 2019

The only difference I see is that bsnes clamps the addition while we let it overflow. I've changed that, so see if it is "fixed" now. Either way, you're clipping the audio.

@qwertymodo
Copy link
Collaborator

Yeah, that sounds like a better solution. Wrapping around could definitely cause much more noticeable pops than clamping.

@ToniBC
Copy link
Author

ToniBC commented Mar 15, 2019

Sorry to take a while to respond, I was waiting for you to compile the version. Yes, now that annoying crackling disappeared and everything is heard well. Thank you.

@bearoso bearoso closed this as completed Mar 17, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants