Deprecated: mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead in /storage/content/49/145849/famitracker.com/public_html/forum/classes/dbHandler.php on line 29
FamiTracker
I've been fiddling around with PAL NSFs, and I've noticed the following:
0.3.7b exports with the pitch sounding lower than in FamiTracker when played in NotSo Fatso, Nestopia, Nintendulator, and FCEUXDSP. (Probably others, these are all the ones I've tried.)
0.3.6 exports with the pitch sounding as in FamiTracker in all players I've tried.
These sound the same in NSFPlug, which I believe doesn't account for the different clock speeds. The difference in pitch is the same as the difference in clock speeds between 2A03 and 2A07 (i.e. ~1.07 or a little more than a semitone). All players are rhythmically correct at 50hz.
Both of these NSFs have the exact same header (PAL flag, speed settings); I am not sure how they manage to behave differently. I guess it's something in the NSF driver? Does it try to detect CPU speed and choose a PAL or NTSC pitch table appropriately?
Anyhow, this is just something weird I've noticed. It's not really a personal concern, since I'll probably never have a PAL NES. Just pointing it out because I saw it happening.
Another thing I noticed that is weird: if I export a PAL NSF at higher than possible tempo/speed (specifically I tried 150/1 instead of 125/1 by accident) when it plays back in NotSo Fatso or an NES Emulator it has periodic gaps where it kind of halts, but this problem doesn't appear in NSFPlug. I know that tempo/speed is technially impossible, but you might want to warn or fix this on export, since it plays fine in FamiTracker (well, plays at 125/1 speed despite the setting).
Now THAT is weird. I know that FamiTracker 0.3.0 & 0.3.5 export PAL NSFs as 0.3.7 beta would (i.e.: with a lower pitch when played in cycle-accurate emulators,) yet neither FamiTracker itself nor NSFPlug play the NSFs detuned; they seem to play them as though they were running at 60 Hz.
There's also another thing I've noticed; in all the NSFs I've ever created, both the NTSC & PAL flags are turned on in the NSF's header. I've tried it in Nestopia, NotSo Fatso, VirtuaNSF & FCEUX.
I've actually seen a PAL NES & TV in action & know for a fact that PAL games naturally sound detuned as a result of the CPU's clock speed matching the TV's frequency. Yet, it's as though NSFPlug doesn't recognize the NTSC/PAL flags in the NSF ROM & reverts to playing the file as an NTSC ROM.
_______________________
Technology: the one thing that's hated & cursed at by all engineers, technologists, scientists & technicians!
It recognizes the setting, otherwise it wouldn't be correctly playing at 50hz rhythm/speed. It's only the pitch that's off in NSFPlug. None of the players I've tried were playing back a PAL NSF at 60hz.
An NTSC cart playing on a PAL system should be slow (50hz rhythm/speed) and down a semitone (slower clock)... but it should not be detuned if you were working in PAL mode and made a PAL NSF/ROM.
The video poster played the European releases of Shadow Warriors, Battle Toads & Return Of The Joker on an NTSC NES with a modded lock-out chip; Shadow Warriors was detuned by +1 semitones & was playing faster than normal. Battle Toads was detuned -1 semitones & playing slower than normal. Return Of The Joker played at nearly the correct speed & tone.
I've just checked out Return Of The Joker in both NES & NSF formats, for both TV systems.
The only version of the NSF I was able to find only have the NTSC flag set. The game itself only has either the NTSC or PAL flag set, not both. Here's the header data for both PAL & NTSC games as seen in Nestopia:
File: Batman - Return of the Joker (E) [!].nes
Soft-patched: No
CRC: BA327FD9
SHA-1: 3F46FA8DF32CD8B790523B485444A342A84194B9
System: PAL-B
Board: NES-JSROM, Mapper 69
PRG-ROM: 128k
CHR-ROM: 256k
W-RAM: 8k
Battery: No
Dump: OK
File: Batman - Return of the Joker (U) [!].nes
Soft-patched: No
CRC: 03EC46AF
SHA-1: 14289A6DFA8B85EF2C06FA81D6ED61AE7C2868D1
System: NES-NTSC
Board: NES-BTR, Mapper 69
PRG-ROM: 128k
CHR-ROM: 256k
W-RAM: 8k
Battery: No
Dump: OK
In Nestopia, I've played both games according to their correct TV system; they both played at the same, correct frequency & tone. I've then played each game using the exact opposite TV system setting in the emulator; the PAL game plays faster & at +1 semitones under NTSC settings, while the NTSC game plays slower & at -1 semitones under PAL settings.
And as the YouTube video shows, the PAL game actually plays at the correct speed & tone in an NTSC console.
Conclusion; cycle accurate emulation doesn't necessarily mean accurate emulation. It appears to me that FamiTracker 0.3.0, 0.3.5. & 0.3.7 beta all export NSFs correctly & that emulators/players don't play them correctly, while FamiTracker 0.3.6 exports NSFs incorrectly & gives the illusion of sounding proper under emulated conditions. If only I could find a PAL NSF of Return Of The Joker to compare.
_______________________
Technology: the one thing that's hated & cursed at by all engineers, technologists, scientists & technicians!
I disagree with your assessment. As I said earlier:
0.3.6 exports PAL NSFs correctly, as on a correct emulator they will sound at the same pitch you heard in FamiTracker.
0.3.7b exports PAL NSFs incorrectly, as they will sound at lower pitch in a correct emulator than what you heard in FamiTracker.
NSFPlug does not account for the different CPU clock speed on a PAL NES; I have verified this by looking at the source. (All it does it set the refresh rate to 50hz, or whatever the file's speed setting it, there is no CPU clock adjustment.)
In the video you posted [i]every[/i] game was playing at +1 semitones from its normal PAL pitch. He thinks Return of the Joker is playing fine, but it is not. Listen to the video and you will hear that the DPCM bass samples are playing at the wrong pitch, clashing with the rest of the music; proof that it's not playing at its correct pitch.
Battletoads and Star Wars are interesting if you compare their PAL and NTSC versions because they are both using the same pitch tables; i.e. the PAL version sounds at -1 semitones relative to the NTSC version when played on their respective system, but if you put the PAL cart in the NTSC system it'll still play the same pitch as the NTSC cart did.
I just tested every PAL ROM shown in the video in Nestopia with NTSC mode turned on, and it played at the exact same speed and pitch as every one of his demos, even the very glitchy Battletoads. The emulation is [i]very[/i] good. (I happen to keep every NES ROM I know of on hand, just in case I need them, so doing this test was pretty easy.)
So what I'm saying is that the video [i]does[/i] show that in every case he tested, the PAL cart was playing up a semitone on the NTSC system, which is consistent with every emulator I've tried except NSFPlug (and SlickNES, but does anyone use that?).
Now, it is actually possible to detect whether the system is PAL or NTSC in your NES code with some timing, and then set up or jump to appropriate code for that system, making a region-agnostic ROM. I don't know if any original NES games did this, but you can see it in action with Super Bat Puncher; in PAL mode it still plays at the same pitch (he switches the pitch tables!) but the music runs at a slower 50hz framerate.
Interesting... I've learned something new now thanks to your explanation on Battletoads & Star Wars.
And all this time, I also misunderstood your saying that the other versions of FamiTracker were exporting incorrectly (I interpreted it as the reverse). I also messed up with my first response big time; I just double-checked & found you're totally right (plus the fact that all tracker versions up to 0.3.6 output audio & NSFs the same way as 0.3.6 would; correctly).
You're really on to something here; Nestopia does play PAL games/audio correctly in PAL mode &, seeing that your 0.3.7 PAL track doesn't play correctly, there actually could be something drastically different with the beta's NSF driver source. I don't remember if the beta's source code was released, but maybe it would be good to test with the current NSF driver source instead of its own driver source.
And if the beta's driver source also controls playback from the tracker, it could be that the source is programmed to output NTSC-only code & audio at NTSC-only frequency. What I mean to say is that the driver source is missing something to allow for proper PAL export/playback.
_______________________
Technology: the one thing that's hated & cursed at by all engineers, technologists, scientists & technicians!
I can't test it with a different driver, the driver is hard-compiled into the executable. Playback in FamiTracker is unrelated to the driver though; the driver is just 6502 code for building the NSF.
What I find totally bizarre is that somehow NSFPlug also plays 0.3.6 back at the correct pitch. I think it is using the NTSC pitch tables somehow, but I am not sure how this is accomplished.
Edit: Nestopia forced into NTSC mode will also play 0.3.6 back at correct pitch, so at this point I have to assume that the NSF driver in 0.3.6 is auto-detecting CPU speed and choosing an appropriate pitch table (I didn't see any code in there to do that though...).
) 