[GB Audio] crackly instruments in Adventures of Lolo music

[bryc]

I've noticed the title screen music of Adventures of Lolo (SGB) sounds noticeably scratchy/crackly in mGBA compared to other emulators.

It's hard to explain the issue in words, so here is an audio comparison between mGBA, NEZplug (dedicated .GBS player) and VBA-M. I would've included SameBoy and Gambatte, but can't seem to mute channels in there, but they sound fine. This is just Pulse 1&2.

Here: lolo_compare_flac.zip, contains mgba.flac, nezplug.flac, vbam.flac.

Basically, everything except mGBA sounds 'smoother' in this song and generally more pleasant. And I don't mean that it's less "clicky", but it seems the transition between volume levels in the instrument envelope itself is much harsher or less smooth in mGBA.

[ahigerd]

Has this been tested on hardware? The GB audio hardware has surprisingly coarse instrument envelopes. This may be a case of mGBA being more accurate.

[bryc]

@ahigerd I don't have any hardware to test :( . but if someone could get a decent audio recording it would be pretty easy to compare. But if true, then SameBoy and Gambatte would be inaccurate as well.

SameBoy wont let me mute individual channels, but the first note of the melody is isolated and can be compared for a short duration:

wave_env.mp4

This shows mGBA has highly noticeable stepping in the volume envelope, whereas SameBoy's stepping is more smooth. 4-bit volume levels would have to somewhat coarse, but not to the extent mGBA is.

Correction: They have the same amount of stepping, but there is a short burst of a 'click' each time a volume step occurs in the envelope, and this can create artifacts, which is more pronounced in mGBA than Sameboy.

[endrift]

I'm not entirely sure why but you don't appear to be comparing apples to oranges here--if you look closely you can see that the sameboy clip has a hard cut off before the weird steps at the end of the mGBA clip--and further they're not normalized in comparison to each other (the mGBA clip is slightly louder)

[endrift]

Further, BGB's envelope looks very similar (although it does sound very different so I'm not 100% sure what's going on there), and VBA-M's GB emulation is uh...lackluster at best. I would not trust it for audio comparisons, and nor would I trust NEZplug which seems to be...quite ancient.

I would trust Sameboy's audio though.

[bryc]

Dunno if it helps, but here's some more observations from my limited ability:

mGBA

Notice that the signal strength in the lower end doesn't seem to drop between each discrete step, as compared to the higher end, which shows the steps more clearly.

BGB

Side note: Apparently BGB's timing of the envelope volume changes is slightly different than mGBA or Sameboy, which both seem to have the same timing, whereas BGB appears to 'snap' or 'quantize', causing certain volume change events to be closer than others.

There appears to be 9 discrete steps in the instrument envelope. Each time a volume level changes, there is a boost of volume (or signal strength), which would sound like a very fast 'click', or otherwise sound like a distortion. This seems normal across all emulators and part of the audio hardware.

But in this case, mGBA appears to be boosting some of these artifacts, which sound most noticeable in the 200-220 hz range.

Here is an audio comparison of mGBA and BGB, both were slowed down to 20 fps so the artifacting is easier to hear:

mgba_bgb.mp4

If I had to take a wild guess what it might be:

• Zero-crossing or DC offset interference occurring when volume levels change
• A de-click algorithm may be causing artifacts

I would test SameBoy, but it has no ability to set the emulation speed, or mute any audio channels. So I can't get any clean audio except from specific parts where only 1&2 are active.

VBA-M and NEZPlug happen to be the only emulations available where I can mute channels. Couldn't seem to do it in Gambatte either. I assumed its hard to screw up simple square waves and that their emulation was acceptable, but perhaps there are more subtle aspects to the APU than I realize.

[ahigerd]

I think you may be onto something with the DC offset issue -- the Game Boy's sound hardware is entirely DC, and looking at the actual waveform instead of the spectrogram shows some pretty dramatic DC drifting instead of a pure DC waveform or a rectified AC waveform. Regardless of whether or not the oscillators or the envelopes are being emulated correctly, this is definitely not what the output waveform should look like.

I'm going to go focus my attention on the output side of mGBA's audio pipeline. I may have an idea. Stay tuned!

[ahigerd]

As an aside: I would still greatly appreciate some recordings from various Game Boy hardware revisions. The audio is significantly different from revision to revision even within the same model, so while I'm pretty sure I can get rid of the clicks so that it sounds better, there are some considerations that I'll want to take into account for accuracy in the long run.

[endrift]

Now that I think about it, the DC offset may be being applied at the wrong part of the audio processing. I apply it before the simulated capacitor charging, but perhaps it needs to be done after?

[ahigerd]

That's unrelated. The fact that the GB audio hardware has a DC bias is separate from the fact that it has a DC audio signal -- that is to say, it generates unsigned samples, but the code is feeding those samples into a signed output buffer. This results in a massive DC offset.

[ahigerd]

I've poked at this some more and I've identified that the DC offset is a red herring -- that is, after fixing the DC offset, the noise doesn't go away. The zero crossing theory is also wrong, but it's closer: it's actually a lack of an appropriate zero crossing:

I spoke with endrift and it looks like the root of the issue is that the game code is explicitly retriggering the note, and mGBA's implementation details aren't matching how the original hardware handles that. We've got a lead on where the discrepancy might be.

[ahigerd]

Also on the subject of DC: Turns out that while the PSG code IS generating a massive DC offset, the band-limited output buffer cleans it up already. You can still see a little bit of it in the waveform but the effect is inaudible.