The quest for perfect VRC7 audio
Moderator: Moderators
The quest for perfect VRC7 audio
I'm working on a bit-accurate VRC7 audio emulator. It's already feature-complete, and Lagrange Point's NSF sounds indistiguishable from the reference recordings provided by rainwarrior in this topic, at least to my hearing. <plug>You can check it out in the latest release of my NSF player (no source yet, but there soon will be, especially if I turn out to be right about the next two paragraphs).</plug>
Many homebrew NSFs, however, sound off. And when I say off, I mean way off, up to and including completely garbled. I've dissected one of them, FCP2015 cover 069 (On the Floor by DJ Dimeback), and traced its problem down to the cause - modulator envelope quantization. The stepping in the opening chord comes from limited precision, which the documentation I can find tells me is true of real hardware.
In other words, one of the following appears to be true:
1) The OPLL documentation I found (MAME source code mostly) is wrong.
2) The VRC7 is not just an OPLL with 6 channels and a different patch set.
3) FCEUX, mednafen and NSFPlay are all inaccurate.
The only real way to answer the question is testing on an actual VRC7. I suspect the same will prove true of the other half-dozen broken VRC7 NSFs I've found.
TL;DR: is there anyone here who can play NSFs, or at least test custom patches, on an actual VRC7 donor? Flash carts like the PowerPak and Everdrive also emulate expansion audio so that's not good enough here; it has to be the real deal.
Many homebrew NSFs, however, sound off. And when I say off, I mean way off, up to and including completely garbled. I've dissected one of them, FCP2015 cover 069 (On the Floor by DJ Dimeback), and traced its problem down to the cause - modulator envelope quantization. The stepping in the opening chord comes from limited precision, which the documentation I can find tells me is true of real hardware.
In other words, one of the following appears to be true:
1) The OPLL documentation I found (MAME source code mostly) is wrong.
2) The VRC7 is not just an OPLL with 6 channels and a different patch set.
3) FCEUX, mednafen and NSFPlay are all inaccurate.
The only real way to answer the question is testing on an actual VRC7. I suspect the same will prove true of the other half-dozen broken VRC7 NSFs I've found.
TL;DR: is there anyone here who can play NSFs, or at least test custom patches, on an actual VRC7 donor? Flash carts like the PowerPak and Everdrive also emulate expansion audio so that's not good enough here; it has to be the real deal.
Re: The quest for perfect VRC7 audio
Out of curiosity, where have you gotten your information about the VRC7 to make it "bit-accurate"?
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
P.S. If you don't get this note, let me know and I'll write you another.
- rainwarrior
- Posts: 8734
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: The quest for perfect VRC7 audio
Very few homebrew VRC7 tunes have been tested outside of emulators. A lot of them don't even implement a delay between writes to prevent a loss (there is a speed limit), and any NSF that does this is guaranteed to have never been played on the real thing.Rahsennor wrote:Many homebrew NSFs, however, sound off. And when I say off, I mean way off, up to and including completely garbled.
I've never found any good documentation on it aside from its datasheet, which is quite limited.Rahsennor wrote:1) The OPLL documentation I found (MAME source code mostly) is wrong.
I do not yet know of any way in which it's different from an OPLL except the ways listed on the wiki.Rahsennor wrote:2) The VRC7 is not just an OPLL with 6 channels and a different patch set.
l_oliveira did some side by side tests with YM2143 and VRC7 with a bunch of tunes. There was never any difference that didn't seem to be completely due to the patch set change. A few of them here: thread
So far I haven't seen anything to suggest there's an underlying difference, at least not one that would cause anything but a timbre change. I don't have a YM2143 of my own, and I'm only interested in emulating VRC7 better, so I have only done direct tests with a VRC7, myself.
NSFPlay's is currently a slightly modified version of a 2143 emulation by Mitsutaka Okazaki.Rahsennor wrote:3) FCEUX, mednafen and NSFPlay are all inaccurate.
In the tests I have done, I have found there are some timbre differences still. Some of it due to the patch set, which is still not 100% accurate, but there's some other things that sound slightly different, like the bass patch in sound test 10, which might be due to difference is bit depth somewhere in the emulation, or it could be something else.
As far as I've tested it, though, it is functionally correct. I do plan to rewrite it in the next version, after I finish my current project and have some time to do some extensive VRC7 tests, but from my experience so far I don't expect a rewrite to improve anything but those minor timbre differences. Mitsutaka Okazaki's YM2413 emulator seems to do the job pretty well.
I can't vouch for MAME or FCEUX's emulation. I don't usually try to compare my own emulator against other emulators except when people submit bug reports to me that say it works on emulator XXX. To verify I test on hardware, because I don't care what XXX does, usually.
The one thing I know for sure the hardware does that I don't is that speed limit I mentioned before. If you write too fast, the write might get missed or only partially take effect. I do not emulate this, and I have not spent much time trying to figure out the precise timing of this or what exactly happens when the writes are "partial" (very hard to tell from just the sound alone, if only it could be read back ).
If you want to make a better emulation than other emulators, you have to own the hardware and test it yourself. You'll need the ability to iterate on your own tests.Rahsennor wrote:The only real way to answer the question is testing on an actual VRC7. I suspect the same will prove true of the other half-dozen broken VRC7 NSFs I've found.
Those flash carts do not emulate VRC7. Kevtris' HD NES does, though. I have no idea how accurate it is, and it's not open source.Rahsennor wrote:TL;DR: is there anyone here who can play NSFs, or at least test custom patches, on an actual VRC7 donor? Flash carts like the PowerPak and Everdrive also emulate expansion audio so that's not good enough here; it has to be the real deal.
If you can write a test that runs in RAM that can be tested with Lagrange point by hotswapping (example), I can record some for you from my Famicom. Anything other than a hotswap test is much more of a hassle to set up, and I probably wouldn't get to any time soon. (If I owned a TNS HFC cart it would be really easy to do NSFs, but I can't afford it at the moment. There might be others around here that own one though that could do that?)
Re: The quest for perfect VRC7 audio
I started from the assumption that it's identical to the OPLL (YM2413) unless otherwise noted, and pulled most of the details out of the MAME implementation, cross-referenced with a bunch of other sources.Quietust wrote:Out of curiosity, where have you gotten your information about the VRC7 to make it "bit-accurate"?
From my notes:
https://docs.google.com/document/d/18IG ... n1rIm42nwo
http://gendev.spritesmind.net/forum/viewtopic.php?t=386
https://github.com/mamedev/mame/blob/ma ... /fmopl.cpp
https://github.com/mamedev/mame/blob/ma ... ym2413.cpp
I'm pretty sure it's not "bit-accurate" yet, and I'm not even sure it's possible with only the data available on the internet, but that's the end goal, and if I can at least get close I'll be happy.
Same goes for every other expansion audio chip out there.rainwarrior wrote:Very few homebrew VRC7 tunes have been tested outside of emulators. A lot of them don't even implement a delay between writes to prevent a loss (there is a speed limit), and any NSF that does this is guaranteed to have never been played on the real thing.
I haven't implemented the speed limit, since that would probably break every single homebrew NSF I have, but I plan to make it an option eventually. Might be useful for someone.
Linked a bunch of relevant stuff above. Only one is specific to the OPLL, but it at least seems to cover the ways it differs from the popular chips, like the OPL2. It takes a lot of searching around to find everything.rainwarrior wrote:I've never found any good documentation on it aside from its datasheet, which is quite limited.
Maybe I should write up what I've found so far?
Looks like a high-level emulation. I don't see any of the tables or bit-bashing that goes on in hardware.rainwarrior wrote:NSFPlay's is currently a slightly modified version of a 2143 emulation by Mitsutaka Okazaki.
Not that there's anything wrong with that, it's just that nobody seems to have made a high-accuracy VRC7 emulator before, and I thought I'd give it a shot.
Agree 100%, but not really feasible for me right now. I'd need a CRT, Famicom, Lagrange Point and somwhere to put them all and/or solder safely. Plus I haven't soldered since grade school.rainwarrior wrote:If you want to make a better emulation than other emulators, you have to own the hardware and test it yourself. You'll need the ability to iterate on your own tests.
Anything in particular I should be mindful of when coding for a hotswap?rainwarrior wrote:If you can write a test that runs in RAM that can be tested with Lagrange point by hotswapping (example), I can record some for you from my Famicom. Anything other than a hotswap test is much more of a hassle to set up, and I probably wouldn't get to any time soon. (If I owned a TNS HFC cart it would be really easy to do NSFs, but I can't afford it at the moment. There might be others around here that own one though that could do that?)
- rainwarrior
- Posts: 8734
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: The quest for perfect VRC7 audio
Not to the same extent.Rahsennor wrote:Same goes for every other expansion audio chip out there.rainwarrior wrote:Very few homebrew VRC7 tunes have been tested outside of emulators. A lot of them don't even implement a delay between writes to prevent a loss (there is a speed limit), and any NSF that does this is guaranteed to have never been played on the real thing.
VRC6 and N163 have had a lot of play on real hardware in the past few years, and a lot of emulators get them pretty well down (they are way simpler than VRC7). At some point MML/PPMCK was updated because it started happening and they realized N163 wasn't working on it.
MMC5 is almost totally ignored by homebrew NSF. Maybe because the VRC6 does all it does and more. Maybe because the PowerPak doesn't emulate it?
5B is also mostly ignored. Partly because VRC6/N163 do more interesting things, but also 'cause Gimmick is an expensive cart.
FDS and VRC7 are less ignored, but still kind of obscure. Until last year the only ready-made interface for FDS data was parallel port software you had to run in DOS. I can't vouch for any FDS emulator but my own.
jrlepage and ImATrackMan in particular has done a lot of hardware recordings for people (they might help you too):
http://www.famitracker.com/forum/posts.php?id=3633
http://forums.famitracker.com/viewtopic.php?f=4&t=2
http://forums.famitracker.com/viewtopic.php?f=4&t=1377
Well, I dunno how many people are trying to implement VRC7 right now. If you're still sifting through information, maybe wait until you've been through it all and come up with an implementation you think is good, first? (I'm not ready to dig through any documents you share at this point. Not until I get back to it a little while from now.)Rahsennor wrote:Maybe I should write up what I've found so far?
A CRT isn't necessary. Well, even the Famicom can be substituted with an adapter if you only have an NES.Rahsennor wrote:I'd need a CRT, Famicom, Lagrange Point and somwhere to put them all and/or solder safely. Plus I haven't soldered since grade school.
It's best to modify a Famicom to output composite video, and direct audio, rather than running it through RF. (This will require soldering, but it's a relatively minor modification. I had a lot of trouble with soldering when I was younger, but years later I found the Pace company tutorials on YouTube and they really set me straight.)
Umm, well the ROM should use NROM, it should have audio cues to tell me what's happening (before and after the swap) and make sure there's a few seconds between cues so that I can do the actual swap.rainwarrior wrote:Anything in particular I should be mindful of when coding for a hotswap?
Re: The quest for perfect VRC7 audio
Looks interesting. They seem to have recorded a few VRC7 tracks already; I'll try checking my player against them first. Thanks for the links.rainwarrior wrote:jrlepage and ImATrackMan in particular has done a lot of hardware recordings for people (they might help you too)
Well, I started this thread because I've digested all the information I can find and written an implementation that's more or less complete, modulo bugs. Which may or may not actually be bugs.rainwarrior wrote:Well, I dunno how many people are trying to implement VRC7 right now. If you're still sifting through information, maybe wait until you've been through it all and come up with an implementation you think is good, first?
But if nobody cares then I guess there's no point. Anyone who wants it, just holler. I'll get around to it eventually.
I have a PAL NES.rainwarrior wrote:Well, even the Famicom can be substituted with an adapter if you only have an NES.
Re: The quest for perfect VRC7 audio
Entertainingly, the VRC7 would still work on a PAL NES, and even with unchanged pitches, because it operates on its own clock.
Unfortunately, (as you know) the PAL NES itself has changed pitches, so NSFs that use both internal audio and the VRC7 would be out of tune with themselves. But that might not affect its utility to you...
edit: affect/effect
Unfortunately, (as you know) the PAL NES itself has changed pitches, so NSFs that use both internal audio and the VRC7 would be out of tune with themselves. But that might not affect its utility to you...
edit: affect/effect
Last edited by lidnariq on Mon Nov 14, 2016 6:58 am, edited 1 time in total.
- mikejmoffitt
- Posts: 1353
- Joined: Sun May 27, 2012 8:43 pm
Re: The quest for perfect VRC7 audio
How many of the VRC7 instruments are OPLL instruments, but assigned a different patch number? A side-note is that a "reasonable" VRC7 repro could maybe be made with a small VRC7-->OPLL translation table involved.
-
- Posts: 780
- Joined: Tue Nov 23, 2004 9:35 pm
Re: The quest for perfect VRC7 audio
Unless the OPLL instruments are essentially VRC7 instruments scrambled, I don't think this would work well for existing software.mikejmoffitt wrote:How many of the VRC7 instruments are OPLL instruments, but assigned a different patch number? A side-note is that a "reasonable" VRC7 repro could maybe be made with a small VRC7-->OPLL translation table involved.
I would think that you could use a (fairly common) YM3812 combined with logic and some ROM to make the chip look like a VRC7. Essentially the ROM values would preconfigure the configurable channels in the YM3812 to the VRC7 instruments and the remainder of the chip would replicate VRC7 bankswitching and interrupt functions.
Moreover, whatever happened to the project to decapsulate a VRC7 to find out its exact instrument settings?
Re: The quest for perfect VRC7 audio
IIRC, it got stalled after the first lightfield images, and so the ROM can't be read yet:Great Hierophant wrote:Moreover, whatever happened to the project to decapsulate a VRC7 to find out its exact instrument settings?
See also https://forums.nesdev.com/viewtopic.php?f=9&t=12260 and http://siliconpr0n.org/archive/doku.php ... vii_053982Quietust on his web site wrote: March 22, 2015
VRC-VII clarifications have been acquired and several fixes have been incorporated into its Metal layer image.
At this point, further work on the VRC-VII and RP2C33 will require the chips to be delayered, which is not expected to happen at any point in the near future. As with the RP2C02G, I'll continue work on these projects once more images are available.
Re: The quest for perfect VRC7 audio
The YM3812 has very different envelope behaviour from theYM2413 (no 'reset' phase, 9 bits of precision instead of 8 etc.), so it wouldn't be useful for anyone wanting 100% accuracy. And that's exactly what I'm trying to test right now.Great Hierophant wrote:I would think that you could use a (fairly common) YM3812 combined with logic and some ROM to make the chip look like a VRC7. Essentially the ROM values would preconfigure the configurable channels in the YM3812 to the VRC7 instruments and the remainder of the chip would replicate VRC7 bankswitching and interrupt functions.
Would be more interesting to give the NES full access to the OPL2's features IMO.
Re: The quest for perfect VRC7 audio
Basically, siliconpr0n.org has more important chips to process than the VRC7 and RP2C33, and since I'm not the one who donated the chips (or the $$$ to have them processed), my only choice is to wait.lidnariq wrote:IIRC, it got stalled after the first lightfield images, and so the ROM can't be read yetGreat Hierophant wrote:Moreover, whatever happened to the project to decapsulate a VRC7 to find out its exact instrument settings?
Fortunately, I have a lot of patience (which was very helpful when making the Visual 2A03 and 2C02), so a few years of delay isn't that big of a deal to me.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
P.S. If you don't get this note, let me know and I'll write you another.
Re: The quest for perfect VRC7 audio
Is this prioritized list of "important chips" published anywhere, or are there good reasons for keeping it secret?
Re: The quest for perfect VRC7 audio
When I said "more important chips", I meant "ones that other people actually donated $$$ to have processed", which is probably growing faster than the chips can actually be processed - depackaging and delayering chips requires hazardous chemicals and a lot of time, so it's not cheap.tepples wrote:Is this prioritized list of "important chips" published anywhere, or are there good reasons for keeping it secret?
The closest thing to an actual list can be found here by sorting by date.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
P.S. If you don't get this note, let me know and I'll write you another.