Famicom expansion hardware recordings

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
Famicom expansion hardware recordings
by on (#90245)
I now have an A/V modded Famicom and I have begun to make reference recordings of the expansion cartridges I have. If you have any to share, let me know.

1. FDS
- [none]

2. MMC5
- http://rainwarrior.ca/projects/nes/just_breed_ref.zip Just Breed six random tracks.

3. VRC6
- http://rainwarrior.ca/projects/nes/esper_dream_2_ref.zip Esper Dream 2 six random tracks.
- http://www.mediafire.com/?8aijas3l2yoli1t Akumajou Densetsu recorded by jrlepage.

4. VRC7
- http://rainwarrior.ca/projects/nes/lagrange_point_ref.zip Lagrange Point complete Sound Check.

5. Sunsoft 5B
- http://rainwarrior.ca/projects/nes/gimmick_ref.zip Gimmick! complete Music Sampler.

6. Namco 163
- http://rainwarrior.ca/projects/nes/rolling_thunder_ref.zip Rolling Thunder title screen and first level (4 channel N163).
- http://www.mediafire.com/?lwdf8bfaoguy7e3 Final Lap (4 channel N163) recorded by jrlepage.
- http://www.mediafire.com/?vby5zhhbhh3hmaq Megami Tensei II (4 channel N163) recorded by jrlepage.
- http://rainwarrior.ca/projects/nes/erika_to_satoru_no_yumebouken_ref.zip Erika to Satoru no Yumebouken ten random tracks (8 channel N163).
- http://www.mediafire.com/?ec47t4jajbb6ywl King of Kings (8 channel N163) recorded by jrlepage.

7. PAL NES
- [none]

8. Level comparisons between different carts:
- http://rainwarrior.ca/projects/nes/famicom_cart_level_comparison.flac
- Order: SMB, Ninja Gaiden, Uchuu Keibitai SDF, Just Breed, Rolling Thunder, Erika to Satoru no Yumebouken, Esper Dream 2, Lagrange Point, Gimmick!

Edit: More recently I have been hosting hotswap test ROMs on github, including a suite of standardized mixing tests:
https://github.com/bbbradsmith/nes-audio-tests


Older news:


On a related note, I am currently doing tests by running code from RAM and hotswapping to answer the other questions I've had. So far I have verified the following things:
- 5B has the noise and envelope features of the YM2149F, and they are at the speed I expected (i.e. NSFPlay is correct).
- MMC5 square has envelope feature identical to APU.
- MMC5 square has length counter, same as APU except twice as fast.
- MMC5 $5017 does not appear to affect envelope/length counter like $4017 for APU (appears to be fixed at 240hz).
- MMC5 square does not have sweep, as was known.
- MMC5 square and PCM are reverse polarity vs APU.
- MMC5 squares do reset phase like the APU.
- MMC5 does not silence squares with frequency registers < 8, unlike the APU.
- MMC5 does not silence squares with a high frequency that would be silenced by the sweep unit, unlike the APU.
- MMC5 PCM functions as expected in both read and write modes.
- VRC7 requires delay between register writes.

Source and recordings for some of these tests is currently available here:
http://rainwarrior.ca/projects/nes/swap_tests.zip

A more updated and complete collection of swap test ROMs and sources is available here:
http://rainwarrior.ca/projects/nes/famicom_audio_swap_tests.zip


I've begun this project because I've been working on NSFPlay/NSFPlug, which I've always liked as an NSF player. I'm trying to make it as accurate as I can, while improving it in other ways as well. My current version of this player is available here:
http://rainwarrior.ca/projects/nsfplay/index.html
Re: Famicom expansion hardware recordings
by on (#90246)
rainwarrior wrote:
Additionally if anyone has modified a Gimmick cart and tested the unused AY hardware features on the 5B (e.g. envelopes), that would be helpful.
http://nesdev.com/bbs/viewtopic.php?t=8483
http://nesdev.com/bbs/viewtopic.php?t=5979
http://nesdev.com/bbs/viewtopic.php?t=3480 (stale links)

Anything kevtris says about the hardware I would trust at face value.

by on (#90248)
Thanks for the links, though all of the relevant recordings in them are actually 404 now. :(

I've seen jrlepage's NSF test, and he's explained that the envelopes play at a different speed on VirtuaNSF and NSFPlug, but I have no point of reference for which (if either) is the correct behaviour. (Also it would be nice to have a test that isolates specific features, like the envelope.)

NSFPlug uses Mitsutaka Okazaki's emu2149.c, which I'm inclined to trust since it's used elsewhere. VirtuaNES's 5B emulation seems to be custom written. Does anyone know if there's a repository for Mitsutaka Okazaki's code somewhere, so I can make sure the version with NSFPlug isn't modified? It would be great to verify though.

by on (#90249)
http://nesdev.com/bbs/viewtopic.php?t=8352
The video in that thread has part of the answer. There are hardware recordings from a crapload of different Famicom board revisions, and IMHO it seems to prove definitively that there never was an "accurate" expansion sound, at least in cases where games use the NES internal channels at the same time (so it's especially notable on FDS stuff since it doesn't stand alone very much). The balance differences are really huge.

by on (#90252)
Yeah, I did realize that different models have different sound. Even revisions of the NES have some variation (not to mention whether you take the sound from the AV out or are demodulating the RF signal, or even just resistor variation between the same model). I was hoping to at least get to a sensible set of default sound levels (people seem to complain that expansions are too loud in NSFPlug); though maybe that's doable via some consensus. The levels are easy to configure though; not a huge problem overall.

More important is actual simulation errors. Is there anything that NSFPlug is getting demonstrably wrong at this point? Effective hardware recordings can show this kind of error really well.

by on (#90689)
there may be another issue: shameless cross post I put over at famitracker forums...

Quote:
I don't really use trackers nor do I post here much, but I was talking to chibitech last night and there may be some things to watch out for with N163 emulation in the long run...

It's possible that an authentic interpolation or resolution method may need to be implemented in the future depending on the number of active channels. It's still very much up in the air, but the idea is that songs that activate more channels start to have sample interpolation issues. Well that concept along isn't up in the air, it's just that I thought all currant players were taking this into account, though it may not be the case.

I had become concerned this past famicompo when I heard a recording of my submission taken through a variant of Nezplug - nezplug++ - apparently it's considered accurate by some folks in the eastern side of things, least with N163 emulation. However, it's emulating really bad banding in various ranges depending on samples and many channels activated. Even commercial games that use all 8 channels (King of Kings, Erika to Satoru no Yumebouken, others,) have a very annoying high pitch hiss the entire time! Chibi thought that perhaps this hiss is filtered out when the signal runs through RF; but perhaps if your famicom had an AV out setup, you might get the hiss. Powerpak as well as most currant players may not emulate the banding.

The issue was brought up to the author of the Nezplay variant, that certain N163 enabled songs (such as xaimus's dendrite) have the painful hiss (not to mention another issue, later,) to which the author responded that that is the way it's supposed to sound. Take that as you will I guess.

We may ask Robokabuto in the future to confirm this since I guess he has a TNS-HFE4 set-up, but it's very likely that it's just as accurate as whatever famicom you're running off of, just like that video posted of FDS Zelda title screen audio recorded on something like 30+ different famicom & famiclone models; if it's an AV cable model, perhaps you'll have problems if it can even run expansion mappers, but again, this is all up in the air right now.

Also, I don't know if it was reported but apparently in said emulator, Chibi said the currant famitracker beta ported nsfs had a nasty buzz on the 163 channels, apparently the same as NSFs created using it2nsf with N163 enabled played on real hardware. It may be a unnecessary constant register write every single frame.

Again, sorry as this is all very vague, and sounding like it's developing for one emulator (that I don't even care for that much!) Hopefully we'll get some more solid information later.


Perhaps the nsf player author has a really crappy famicom? Who knows...

by on (#90705)
Yeah, there's all sorts of things that can go wrong on just one person's unit. I had a used genesis where the electrolytic capacitor on a power supply filter had dried out, and I could basically hear the CPU loudly through the audio output, until I figured it out and replaced it.

Also, I added PAL support to NSFPlay; see OP for link.

by on (#90746)
Thanks for taking it upon yourself to really do this! So far the player passes a lot of tests and curveballs I throw at it. Because I love it, I'm guaranteed to nitpick it, so be prepared...

First off the biggest downside I see is that Strobe's NSFs he made with a custom FamiTracker export plugin that glues FTMs together for "unlimited" bankswitched DPCM (within NSF file specs) crash and burn. Do not try them on PowerPak's NSF player since it has a 256KB NSF limit due to hardware limitations. Kev says that they work on his FPGA player and they are legal in spec.

http://lmao.rotfl.at/upload/Str0be/stro ... e_blip.nsf
http://lmao.rotfl.at/upload/Str0be/strobe-ziberia.nsf

So far it's passing most other PCM NSF tests, N163 tests, and multichip tests just fine!

On to the nitpicks and feature requests:

* I see you are concurrent with terms such as N163 and Sunsoft 5B. These could be reflected in the player. :) Also, the "DPCM" channel could be called "(D)PCM" since it's more than just a DPCM channel.

* Since the Sunsoft 5B is a clone of the AY with extra memory mapping functions, it would be nice for NSFPlay/NSFPlug to support the AY volume register "buzzer" for when FamiTracker supports Sunsoft 5B compositions!

* MMC5 PCM support would also be nice... I don't think it would be very hard to port SuperNSF to MMC5 just for proof of concepts at first.

* DPCM and PCM logging/dumping would be a very handy feature. NSF Live! by jsr is still used quite frequently to rip DPCM samples. I see PCM logging and dumping to be kind of difficult if someone is using direct $4011 writes to affect noise or triangle volume.

* N163 waveform logging to MML format. This way waveforms could be logged and copy/pasted into FamiTracker or *MCK.

* NSF2 support. If you support it, you will have the first player in the world to use it; aside from Kev's FPGA player. :) NSF2 is the next frontier in NES/Fami music composition!

Even NSF2 aside, having all noted features above would make NSFPlay/NSFPlug the only fully-featured NSF player in the world; then we can really focus on more accuracy to make it the most fully-featured and accurate player in the world. That way people could just stop arguing about which player is the best and only use one; this one. :D

Edit:

I'm also very pleased that NSFPlay works great under WINE too. :)

by on (#90780)
1. I was planning to adjust the names. No, I'm not going to put parentheses around the D. That looks silly and nobody calls it that. I was considering just calling it DMC though, since that's the actual name of the channel and not just the sample format.

2. Can you possibly get me Strobe's source code and FTMs for those NSFs you think should work but don't? It's will take a lot more time to try to debug it if I have to do it by reverse engineering.

3. What is the AY volume register buzzing, and is this something that you know NSFPlay is missing, or have you tested it? (If you do have a test for it, send it to me.)

4. I don't agree that MMC5 PCM support would be "nice", as it's an utterly useless hardware feature, but support for it is on my to-do list. Does there even exist a game that used it for musical purposes and not just game-halting sound effects? I had to hand write my own NSF just to test it.

5. If you want to rip DPCM samples, try my NSF Importer for Famitracker. http://rainwarrior.ca/projects/nsfimport.html PCMs you can rip very easily just by opening the ROM as raw data in an audio editor. I don't really intend to facilitate DPCM or PCM ripping with NSFPlay (I don't think there's a good way to generalize PCM ripping anyway), but I will probably need to implement a trace/debugging feature.

Actually, now that I think about it, if you just mute everything but the DMC and record the output that's as good as any "PCM logging" feature would do. Why don't you just do that?

6. Again, not really planning to facilitate sample dumping with this program, but my NSF Importer project is all about this kind of thing, so... there will be a solution.

7. Ha ha, NSF2. Only when I get everything else worked out.

by on (#90782)
rainwarrior wrote:
Actually, now that I think about it, if you just mute everything but the DMC and record the output that's as good as any "PCM logging" feature would do. Why don't you just do that?

That depends on how well the output sample rate lines up with the APU sample rate., along with whether the output nonlinearity can be switched on or off.

by on (#90785)
The nonlinearity can already be switched off in NSFPlug.

I don't see why the output samplerate would be a factor. The standard 44.1kHz is more than enough to capture every sample (in any practical example); you can figure out the true samplerate and resample without losing anything.

I think the options currently go to 96kHz if you really need it, but if the NES can even go that fast (not sure what the exact limit is) why would you bother storing a PCM sample that plays at an inaudibly high frequencies?

by on (#90788)
rainwarrior wrote:
The standard 44.1kHz is more than enough to capture every sample (in any practical example); you can figure out the true samplerate and resample without losing anything.

How hard it is to undo the upsampling of a 33.5 kHz DPCM kick drum sample to 44.1 kHz depends on what sort of filtering the player uses.

by on (#90789)
All the filtering as well as the nonlinearity can be turned off in NSFPlug.

At any rate less than your output samplerate you can resample without losing anything (as long as your resampler is point sampling).

Still, for PCM ripping it's far easier just to open the ROM as raw data in an audio editor. For DPCM ripping just use NSF Importer.

by on (#90801)
rainwarrior wrote:
Still, for PCM ripping it's far easier just to open the ROM as raw data in an audio editor.

Have you ever tried doing that for Big Bird's Hide and Speak?

by on (#90813)
Doesn't work for that one. Obviously there's going to be examples where they don't store them raw. Do you have a burning desire to rip the samples from this game?

Also, and I forgot about this earlier, playing raw PCM in an NSF is a really touchy operation anyway. This is why there are very few NSF rips that include PCM samples. (This big bird game might be tough to rewrite the for NSF compliance.)

So... yet another reason why PCM ripping for an NSF player isn't really in the cards. It only applies to modern music engines written specifically for NSF, and for that you can probably just ask the author for the samples.

by on (#90819)
rainwarrior wrote:
compliant NSFs need to return from the play routine before the next update, and in a game implementation you would never write your PCM routine around this limitation.
And that's one reason NSF2 was proposed.

by on (#90896)
Regarding Sunsoft 5B, its audio expansion the same as the AY.

http://www.speccy.org/hardware/datasheet/ay38910.pdf

Two things that current players do not support is the Noise Generator and Envelope Generator support of the channels. Each channel can change from pulse to noise and back. The Envelope Generator was commonly used to create basic waveforms and was used as an additional channel called the "buzzer".

Here's an example: http://www.youtube.com/watch?v=38d4rjORKgc The bassline is the "buzzer" or Envelope Generator.

Generally the Noise and Envelope were not emulated because no commercial games used the functions. With FamiTracker's active development and many musicians using it, it would be necessary to have a player. :)

by on (#90898)
B00daW have you tested these things with NSFPlay? So far as I have seen it supports both envelopes and the noise channel. If you have an example NSF that doesn't work send it to me.

by on (#90912)
Regarding this post ( http://nesdev.com/bbs/viewtopic.php?t=8483 ) it seems like there is some debate to how the envelope register should be emulated. Someone needs to actually record from a Sunsoft 5B devcart. According to BootGod's site, it seems that Gimmick! and Gremlins 2 Famicom carts are the only ones with actual Sunsoft 5B's. Strangely, enough it doesn't seem like Gremlins 2 actually used the expansion audio...

Tonight I decided I was bored and would hack up a MMC5 PCM PoC from currently available SuperNSF NSFs.

http://average.truechiptilldeath.com/nesdev/mmc5hax.zip

I have no idea how this is going to sound. It uses saturation tables for 4 channels using 7-bit samples instead of 8-bit samples. It should at least play audio out of the $5011 register though...

by on (#90920)
I've got an MMC5 PCM test of my own, but I will test this. VirtuaNSF and some emulators play $5011 writes. But I have yet to find any that will play $8000-BFFF reads in read mode. NSFPlug will do this when I get around to it.

by on (#91183)
After doing some investigating on the 5B it looks like VirtuaNSF's envelope speed is wrong. The envelope frequency should be exactly 1/16 of the equivalent tone frequency. NSFPlug seems to be correct. VirtuaNES looks mostly correct, except it masks out the high 4 bits of the envelope pitch, so it probably doesn't support very low envelope frequencies. A lot of other emulators don't even bother with noise or envelopes.

There was a lot of confusion when looking this up, I think primarily because the 5B appears to be a YM2149F running with the clock divider on, cutting the clock rate in half. So, the 5B's frequencies are unfortunately about 1/2 of what you'd get from a ZX (1/3 vs an ST)-- big loss in pitch accuracy! There may also be some confusion whether the "frequency" mentioned in the datasheets means how often the square value flips (I doubt this), or how often it completes the cycle.

I wrote a wiki page for the 5B, since we didn't have one:
http://wiki.nesdev.com/w/index.php/Sunsoft_5B_audio

Edit: also just discovered that NSFPlug's FDS modulation is half strength for some reason. Another thing to fix for the next version...

by on (#91410)
rainwarrior wrote:
2. Can you possibly get me Strobe's source code and FTMs for those NSFs you think should work but don't? It's will take a lot more time to try to debug it if I have to do it by reverse engineering.


Strobe was gracious enough to share his source for educational and development purposes.

I will message you the link on IRC. This source was also used for Ziberia.

by on (#91417)
Thanks! That will be helpful.

I've gotten NSFPlug down to a small number of known issues; this was one of them. I expect I'll be releasing version 2.1 by the end of March.

BTW in that xiamus haxus MMC5 NSF you (or whomever hacked it) forgot to set the MMC5 bit in the NSF header. Easy to fix though, and it plays just fine in my WIP version of NSFPlug now.

by on (#91420)
Ah, I've discovered the problem. The NSFs are not compliant with the spec.

The bankswitching bytes in the NSF header (70-77) are all 0. This means (according to the spec) that bankswitching is disabled.

Just put 00 01 02 03 04 05 06 07 in there and it will work as intended.

http://kevtris.org/nes/nsfspec.txt

by on (#92084)
As I create test NSFs I will archive them at: http://rainwarrior.ca/projects/nsfplay/

The current version contains a test for 5B and MMC5 PCM:
http://rainwarrior.ca/projects/nsfplay/bs_nsf_tests_10.zip

by on (#92218)
Beginning to fill my own requests, I acquired a Lagrange Point cart and recorded its entire sound test on my audio-modded NES:

http://rainwarrior.thenoos.net/projects/nes/lp_ref.zip

by on (#93139)
I've now got a Famicom running, and I have carts of all the expansions available to me now (no FDS at the moment, but that will change).

I'll be posting reference recordings, and more information later, but for now I have some info on the 5B to share:

Gimmick's 5B chip does indeed support the noise and envelope features of the YM2149F, and the envelope speed is as I expected. The envelope runs at exactly 1/16 the speed of the equivalent tone frequency (or an octave down in triangle mode). I'll share some code/ROMs/recordings later.

So, this means: Nestopia is a pretty accurate reference for the 5B sound. NSFPlay/NSFPlug is also pretty good. Most other emulators don't implement the noise/envelope features, and a few (e.g. VirtuaNSF) play envelopes incorrectly at double speed.


Edit: I've posted a soundtrack recording and the test code to my OP.

by on (#93759)
Here's some more recordings:

Namco 163:
-King of Kings (8 channels)
-Final Lap (4 channels)
-Megami Tensei II (4 channels)

VRC6:
-Akumajou Densetsu

All of these were recorded from an AV-modded Famicom (recorded from pin 46).

I hope these will be useful to someone. I realise there isn't much need for a full recording of Akumajou Densetsu, but I was bored. :) Also, the first two tracks were recorded from a different cart; I switched after those because the first one was giving me trouble. I didn't bother rerecording the first two, but found out after the fact that my two carts have different volume balance between VRC6 and 2A03... It's not very noticeable anyway.

It's worth noting that the only NSF rip of King of Kings is missing the melody in the in-game track (the frequencies are updated but the volume stays at 0 throughout the entire track).

by on (#93886)
Yep, that high pitch in King of Kings is definitely there. Bleh.

by on (#93892)
Yeah.. But it's not as bad as NEZPlug++ or FamiTracker make it sound. At least, I didn't want to murder anything after a minute of listening to King of Kings on the real Famicom, unlike those two emulators...

by on (#93920)
I've been getting around to testing out the VRC7.

I made a test of the VRC7 patch set vs the one posted by quietust a long while ago:
vrc7_patch_test.flac (dropbox link removed, file lost)

Patch set used:
http://nesdev.com/cgi-bin/wwwthreads/showpost.pl?Board=NESemdev&Number=1440

Each patch sounds 6 tones, each 2 seconds on, 1 second release, 1 second off.

1. Hard patch, low pitch, sustained release
2. Custom patch, low pitch, sustained release
3. Hard patch, medium pitch, regular release
4. Custom patch, medium pitch, regular release
5. Hard patch, high pitch, regular release
6. Custom patch, high pitch, regular release

After a full loop through all 15 at volume 0 (full volume) I run them again at volume 8 (low volume).

As you can hear, it's actually a very good guess at the patch set. All the noticeable differences are rather minor ( e.g. release on patch 8 ). I'll work on hammering out these minor differences, then I'm going to try to write an emulator that actually sounds correct.

by on (#94190)
jrlepage wrote:
Yeah.. But it's not as bad as NEZPlug++ or FamiTracker make it sound. At least, I didn't want to murder anything after a minute of listening to King of Kings on the real Famicom, unlike those two emulators...


Seems more possible between various models & clones that the output can be stronger or weaker. Great.

by on (#94296)
As I've been making these recordings I have noticed that volume levels vary over time as the machine/cartridge warms up, etc. so in addition to the difference between various models, you also have variation due to temperature on the same console. Precision simply isn't possible.

This is what I think we're looking at in the differences between systems, in decreasing order of importance.

1. The output chain after the cartridge generally contains some sort of lowpass filter, and possibly a highpass as well. This chain could include circuitry in the console (e.g. NES' mild lowpass) or in the television (RF demodulator, EQ, speaker). Some may include a significant highpass as well.

2. The actual output volume of the 2A03 may be significantly different between types of Famicom, which could consistently affect 2A03/expansion volume balance for any particular model.

3. The inaccuracy of resistors and other components in the cartridge and in the famicom will result in minor variations in volume balance from system to system, cart to cart, or time to time depending on temperature. This factor limits the precision with which we can measure the volume balance.

4. Other factors in the input or output chain. Noise from the microphone circuit, environmental noise, bad wiring, etc. These I don't think are very significant in general, and aren't normally worth modelling.

Factors 1 and 2 are already addressed fairly well by NSFPlay's settings, especially the "Easy Setup" menu which has some presets made by Brezza to simulate various models of Famicom. Factors 3 and 4 aren't really addressable, and are just an indication that there are limits to the precision in which system-to-system variation can be modelled.



As for the output of an N163, the 8-channel recordings speak for themselves, I think. I just added Erika to Satoru no Yumebouken to the list of recordings. These are recordings coming right off the cartridge's audio out, so it's about as pure an example as you can get, I think. The device used to record them from there has its own lowpass/highpass filter out of necessity, but these have a fairly minor impact.

On a television you have plenty of options to mitigate the aliasing issue for the two 8-channel games. RF demodulation generally includes a huge lowpass on the signal. Many TVs have a simple bass/treble adjustment that you can use to filter out most of the aliasing.

The really interesting thing is we can see that we have the update rates correct by the spectrum graphs. The spectrum has a natural curve down to the nyquist frequency (around 7.5kHz), and then you see it curve back up with a mirror set of aliased frequencies back up to the update frequency (~15kHz), and above there is mirrors yet again but you're starting to fight the lowpass filter in the recording device itself at that point.

NEZPlug++ does sound a little too harsh, I think, even against the relatively unfiltered output jrlepage and I have made recordings of, but it is at least getting the update rate correct. I'm still working out my own version of it, but I haven't quite nailed it down yet. I suspect there's some nonlinearity in its DAC as well that I will want to model.

by on (#94299)
rainwarrior wrote:
As I've been making these recordings I have noticed that volume levels vary over time as the machine/cartridge warms up, etc. so in addition to the difference between various models, you also have variation due to temperature on the same console. Precision simply isn't possible.
Both the NES and Famicom use a 74-series inverter as an audio amplifier. (74'04 for the NES, 74'368 for the Famicom). They are wired (by R7 here) to be functioning at their highest possible gain, but because these are digital logic parts, neither the voltage nor gain is characterized, let alone consistent. I'd expect a strong temperature dependence.

by on (#94305)
Highest possible gain? This resistor does negative feedback, which reduces the gain of any amplifier and help linearize output as well as extending the bandwidth of the amplifier and make the overall gain less affected by variations of the amplifier's gain. Of course, the amount of feedback seems low, so variations of the inverter's 'gain' could have noticeable effects on the overall gain.

by on (#94312)
You're right; the self-biasing may not even cause it to be in the highest-slope region of the transfer function depending on the function's exact shape. In any case, http://www.fairchildsemi.com/an/AN/AN-88.pdf describes the temperature dependence nicely.

by on (#94313)
Nice find!
Re: Famicom expansion hardware recordings
by on (#107363)
Added a recording of several carts at once to compare their audio level. See OP.