Hi there guys, this is a bit of an odd question but actually it is very relevant and myself and some others have been wondering about this for some time.
Firstly, let me say how much I love ZSNES! It seems to receive a lot of negative comments from emulator purists these days, about how it pales in comparison to newer, more accurate emulators such as bsnes/higan, and even Snes9x. I personally can't find anything that would make me want to change from my favorite emulator (ZSNES) especially because of my topic question that I will be going into now...
Just going to start right off and say that there is an issue with most emulators that the music/songs will experience a bunch of "popping" and "glitchy" sounds IF the ROM has been expanded to 6mb (ExHiROM), at least for SPC700 music engine-related games, such is FF6 and CT. Could be more games but these are all I work with. Yet, ZSNES and a very few select other emulators that I've tested play the songs fine. Why is this? What is ZSNES doing right with preventing these song glitches that so many of these newer, more "accurate" emulators are not?
The reason behind my question, is I have a FF6 hack out, and for the latest versions I've expanded it to 6MB in order to add a bunch of more songs, and I have this horrible issue which many people complain about, the people that refuse to play on ZSNES or are playing on a Retron 5, SNES9x, or portable emulators, etc. So my question to basically sum this up, is why ZSNES does not share this issue like so many of the more accurate emulators, what allows it to read and play the songs correctly while others don't...and I wonder why can't the developers cure this for their newer more accurate emulators. Is it some fluke? Or did you the developers take this issue into account when developing the emulator?
And furthermore, for all the other emulators that experience this issue, I'm wondering how come some songs work while other's have these music glitches for these other emulators? Meaning some of the songs play fine still, while some do not... I thought it might be due to something extra I've done with the hack, but after various tests it's not that, besides the obvious fact of expanding it to ExHiROM. What I mean is it's not nothing in the channel header data, song location, imported instruments/samples used, so what the hell could it be I wonder.
I've noticed for instance in a random example, Secret of the Forest remains untouched in the CT Flames of Eternity/Crimson Echoes hack which is also expanded to 6mb, yet it is experiencing these pops I've noticed for the same emulators - so why is it picking on that song and not others? What is it about expanding the ROM to 6mb that is causing the music core to decide not to play some songs right, yet others play fine. And how is ZSNES playing ALL the songs perfect? My best guess for FF6 at least, and CT, is that once the ROM has been expanded to 6MB, most emulators do not agree for some reason in the song department due to the particular music engine that FF6 and Chrono Trigger use (SPC700). But then I return to my question of why and how does ZSNES remedy this while others do not.
Thank you for your time.
ZSNES ExHirom support and music issues for other emulators
Moderator: ZSNES Mods
ZSNES ExHirom support and music issues for other emulators
Last edited by Gi Nattak on Sat Jun 20, 2015 7:07 pm, edited 2 times in total.
-
- ZSNES Shake Shake Prinny
- Posts: 5632
- Joined: Wed Jul 28, 2004 4:15 pm
- Location: PAL50, dood !
Re: ZSNES ExHirom support and music issues for other emulato
The current ZSNES release uses dark magics and various tricks to do its thing. It's not a good reference, especially regarding music (which leads to some unfortunate decisions, creating hacks that cannot run anywhere else). There are several sound glitches that anyone can notice when comparing to real hardware.
However, sometimes due to the way it's done it can do better than it should have. It may be such a case.
That said, I'm not exactly sure why expanding a rom (which is essentially just remapping it) would cause specific glitches. If the behaviour is consistent across all emulators using Blargg's core, there may be an issue somewhere. Or it could just be system libraries acting up for some reason. Or just plain bad enveloppe code in those romhacks causing the DSP to clip samples.
However, sometimes due to the way it's done it can do better than it should have. It may be such a case.
That said, I'm not exactly sure why expanding a rom (which is essentially just remapping it) would cause specific glitches. If the behaviour is consistent across all emulators using Blargg's core, there may be an issue somewhere. Or it could just be system libraries acting up for some reason. Or just plain bad enveloppe code in those romhacks causing the DSP to clip samples.
皆黙って俺について来い!!
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
Code: Select all
<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
-
- Buzzkill Gil
- Posts: 4295
- Joined: Wed Jan 12, 2005 7:14 pm
Re: ZSNES ExHirom support and music issues for other emulato
KHDownloadsSquall_Leonhart wrote:DirectInput represents all bits, not just powers of 2 in an axis.You have your 2s, 4s, 8s, 16s, 32s, 64s, and 128s(crash course in binary counting!). But no 1s.
-
- ZSNES Shake Shake Prinny
- Posts: 5632
- Joined: Wed Jul 28, 2004 4:15 pm
- Location: PAL50, dood !
Re: ZSNES ExHirom support and music issues for other emulato
I'll never get why you guys keep jumping names like that. CONFUZZLING !
皆黙って俺について来い!!
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
Code: Select all
<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
Re: ZSNES ExHirom support and music issues for other emulato
Hello again indeed! I figured this might happen once I posted on the higan board right after here...
I'll just say that since I posted here first and was waiting for the post to be approved I've learned much more and I would have edited a few various statements in this post here to not sound like I'm bashing on higan, but it's a bit too late for that. My bad for that. Anyways everything I was wondering on higan's side got answered as the link shows.
Thank you for the response, I appreciate it and helps me further to try and understand what may be going on here. And yes it does seem like this is such a case! But I do have some tests to run now before I can be sure what it is and then go from there.grinvader wrote:The current ZSNES release uses dark magics and various tricks to do its thing. It's not a good reference, especially regarding music (which leads to some unfortunate decisions, creating hacks that cannot run anywhere else). There are several sound glitches that anyone can notice when comparing to real hardware.
However, sometimes due to the way it's done it can do better than it should have. It may be such a case.
That said, I'm not exactly sure why expanding a rom (which is essentially just remapping it) would cause specific glitches. If the behaviour is consistent across all emulators using Blargg's core, there may be an issue somewhere. Or it could just be system libraries acting up for some reason. Or just plain bad enveloppe code in those romhacks causing the DSP to clip samples.
-
- Buzzkill Gil
- Posts: 4295
- Joined: Wed Jan 12, 2005 7:14 pm
Re: ZSNES ExHirom support and music issues for other emulato
Hey, I do it very rarely.grinvader wrote:I'll never get why you guys keep jumping names like that. CONFUZZLING !
(Trufax: I recently changed my name in two places to "a wealthy nigerian prince", because it made me smile. It will change back soon enough.)
Ahhhh. I forgot zBoard has such heavy spammer protections.Gi Nattak wrote:Hello again indeed! I figured this might happen once I posted on the higan board right after here...
I'll just say that since I posted here first and was waiting for the post to be approved I've learned much more and I would have edited a few various statements in this post here to not sound like I'm bashing on higan, but it's a bit too late for that. My bad for that. Anyways everything I was wondering on higan's side got answered as the link shows.
That explains much.
KHDownloadsSquall_Leonhart wrote:DirectInput represents all bits, not just powers of 2 in an axis.You have your 2s, 4s, 8s, 16s, 32s, 64s, and 128s(crash course in binary counting!). But no 1s.