Just aquick question. I notice that almost all of the presets now have chip volumes all at volume=128, except the default, where the vrc7 is lower, volume=96. Is there a reason for this? Also, I remember in beta3, the n163 had different volumes for some of the presets, but now doesn't. Also, has consensus been reached as to relative volumes of expansions to each other and to the internal appu?

Just aquick question. I notice that almost all of the presets now have chip volumes all at volume=128, except the default, where the vrc7 is lower, volume=96. Is there a reason for this? Also, I remember in beta3, the n163 had different volumes for some of the presets, but now doesn't. Also, has consensus been reached as to relative volumes of expansions to each other and to the internal appu?

The 2nd line onward are all part of PRESETxxxx sections, while the first line is part of the NSFplug section. The 2nd line is part of PRESET0000, which is also known as "Default". You'll need to go through the ini yourself by hand to see what I'm talking about. I tend to use the "NES" preset, but the point here is that each of the sections can have a different adjustable volume (for example the ones with 167 are "Bad Analog Circuit" and "TV Speaker").

There are other threads here on this forum rainwarrior is taking part in to try and figure out what the "ideal" default volume is for some chips, particularly the N163. Stuff like this takes time and lots of feedback from folks who have the time/interest/equipment. Please be patient.

VRC7 should not be default to 96 anymore. That was a mistake that I missed while editing the presets by hand. I'll fix it in the zip.

I have rewritten the balance for every chip in this version, so at the same time I made the default balance in the options "128" so it's easy to see as the default.

Also, this version marks the first time I have written tests and measured the output for all chips. Before this the balances used were done "by ear" from available recordings of existing soundtracks. Now they are based on the output of test programs instead. In some cases I've gathered a small consensus from people who have responded to my requests for recordings, but some of it is only measurements made by me on my Famicom. So far I have only had responses from original AV-modded famicoms, including my own, but where I do have multiple points of data they have been pretty consistent, so I have a moderate amount of confidence in it.

I'm sure different models of Famicom like the Twin or the AV Famicom have different tendencies, which is what the preset system is supposed to address, but the presets are really just leftover from the previous maintainer. I did not create any of them myself, and do not know if they are accurate at all.

@koitsu: Thanks for that. Yeah, I was aware of the differences in the bad analog and tv presets, but wasn't including those as I see them as more toy presets, although tv speaker could be useful I guess. As for figuring out volumes between chips, I'll gladly wait as long as it takes to be as accurate as possible, but was just wondering if things were pretty much decided now or if work's still being done.

@Rainwarrior: I suspected this was the case re, different balance of vrc7 in default preset vs everything else. I do find for a lot of older nsf's written with vrc7, that I end up turning it down, because to my ears, it sounds better. of course given that only one actual game ever used the vrc7 as far as we know... enough said.

Lagrange Point has the 2A03 attenuated a lot compared to the VRC7, and appropriately in its music the VRC7 channels are not playing at full volume. The VRC7 has logarithmic volume control, so it's actually very dynamic, so it can go quite loud relative to 2A03. The problem is that a lot of people who write NSFs just leave the VRC7 at full volume in their music instead of using a more appropriate lower setting.

Similarly, 5B can be very loud. N163 is also extremely loud if you put it in 1-channel mode, which I was surprised to see several people doing this year in Famicompo.

Now, possible bug. I just discovered NSFe files. Unfortunately, when I play them in NSFPlay/NSFPlug the track titles are often mismatched to the tunes.

For example, I download the Mega Man IV NSFe from http://slickproductions.org/nsfe.php. I play it and Winamp/NSFPlay reports that the first song is Bright Man, when it's clearly something else (probably the intro). The second is mislabeled Toad Man, and so on.

Also tried that site's Milon's Secret Castle NSFe. The first two tracks are labeled correctly, but it diverges from then on.

I have tried updating from Winamp 5.63 -> 5.65, NSFPlug 2.2 -> 2.3, and also using a fresh Winamp install with no other plugins. The mislabeling persists, and also occurs in NSFPlay 2.3.

Any thoughts? It would be pretty rotten luck if I just happened to download two badly ripped NSFes in a row.

Apparently between 2.3 beta 3 and 2.3 final there was some sort of change to N163 output that causes it to fail on this particular track. To my knowledge this track is not susceptible to the ppMCK output bug described here. I believe were that bug the culprit all versions back to 2.0 would be affected. Taking a look at the Google Code changelog, I'd guess revision r96 introduced the behavior change.

I have attached the NSF in question. The original may be obtained from Famicompo Mini vol.6, Original set, entry 21. SHA-1: 22F0628C3895918638715F5C0306E8BD784C337D

Additionally, I have uploaded two videos demonstrating the difference:

The N163 has 3 registers per channel that can be written to set the channel's 24-bit phase counter. Very few N163 emulations implement this behaviour, but it is how the hardware performs. The only other emulator that I know of which implements this correctly is NEZPlug++.

Dendrite writes all 8 bytes of each channel each frame, which unfortunately causes the phase to be reset at a rate of 60Hz. I'm not sure what engine is uses for playback, but it is broken in this regard, and will only run "correctly" on emulators which ignore this behaviour of the hardware.

Hmm, after looking at it in a debugger, unfortunately it's not a trivial patch, like the other problem which could be solved by changing a single ORA mask. This engine attempts to write all 8 bytes consecutively by using the N163's address increment on write, something which is very appropriate for uploading waveform data, but as you can hear, doesn't work out well for the channel updates.

Last edited by rainwarrior on Sat May 03, 2014 8:03 pm, edited 1 time in total.

Edit: I didn't see your 3rd paragraph when replying. Knowing that the fault lie in the NSF and not in NSFPlay 2.3 final, I am satisfied with using 2.3 beta 3 for dendrite playback. Seeing how the core is in active development and optimization has not yet been performed, a dendrite-specific patch likely isn't the best use of your time, especially since I haven't come across other NSFs with this behavior. If I do, I will post them here for reference. Cheers.

That reminds me -- there are some Famicompo tracks I've heard which sound like bad N163 emulation but can't really discern what the heck is going on, plus I don't have a point of reference/comparison. Ones to check out, if interested:

FCM8_Entries/Cover/Entry41.nsfFCM9_Entries/Cover/Entry39.nsf

And I have not the slightest idea what's wrong with these (I'm guessing some actual sequencer/engine problem and probably not NSFPlay-related):

FCM10_Entries/Cover/Entry009.nsfFCM10_Entries/Cover/Entry017.nsfFCM10_Entries/Cover/Entry035.nsf (starts at about 00:11)FCM10_Entries/Cover/Entry148.nsf

Who is online

Users browsing this forum: No registered users and 3 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum