What do you people think?

I'm working on converting/ripping the song "Dancing Mad" from Final Fantasy 6.

The most unique element of that song is Kefka's laugh. This is created through pitch modulation. The SPC sounds very different when played back through SNESAPU (SPC player) vs. GEP (foobar2000 foo_gep).

I assume that GEP is more accurate (something about being cycle-accurate and ridiculously CPU-intensive). Is that correct? Can anyone confirm on hardware?

Does anyone know how to rip Kefka's laugh accurately without background audio?

(My research): Sonic.exe contains a sample of Kefka's laugh. Unfortunately, extracting the audio data using 7-Zip and Audacity reveals that it's severely clipped. Additionally, there appears to be some remnants of background audio, since the audio before the laugh is not completely zeroed out.

No, Kefka's laugh is generated not through a BRR sample, but through pitch modulation. The flute waveform is given a very fast "vibrato" corresponding to the value of another waveform.

I think the problem is that SNESAPU handles pitch modulation very differently from GEP.

Your download sounds more like SNESAPU, which may be less accurate? I'm not entirely sure, though.

EDIT: Snes9X produces the same sound as GEP. Sadly, I still can't rip the samples for a soundfont, due to echo.

EDIT: Where did you get the samples from?

Does Kefka's laugh during cutscenes use separate samples, as opposed to the pitch modulation from Dancing Mad?

My goal is to rip the sound accurately and without background interference. GEP won't remove background, SNESAPU/SPCPLAY is inaccurate, and Snes9x can't disable echo to isolate the notes.

bazz at (S)Nesdev managed to record the sound accurately, using some custom software.

http://forums.nesdev.com/viewtopic.php?f=12&t=14013#p167221

I'll contact dgrfactory about this emulation error.

After studying SNES docs, Anomie's docs, and Higan/Game-Music-Emu source code for days, I wrote up a flowchart for the structure of the SNES echo and FIR filter system. Can anyone verify that it's correct? Especially the FIR filter part?

http://bin.smwcentral.net/u/22354/snes-echo2.out.png

Note that _echoPointer, echoOffset, echoHistory, and calculateFir are references to Higan source code. EON is a flag (bits), EFB, EDL, and ESA are mono, and MVOL and EVOL are stereo registers.

EDIT: Note that ECEN flag must be enabled in order to write to the echo buffer.

Source material:

Nintendo docs: http://pikensoft.com/old/docs/Super_Famicomm_sound_manual_%28Ledi%29.txt
Anomie docs: https://37.muncher.se/bot/apudsp.txt
Higan source: https://gitlab.com/higan/higan

IIRC, pitch bends can cause crashing if the next note triggers before the pitch bend starts. Or you schedule two pitch bends in a row, and the first one can't finish before the note ends. Or the next note starts. I don't remember exactly, it's been a while.

I reposted this thread in SNESDEV http://forums.nesdev.com/viewtopic.php?f=12&t=14230 . As far as I can tell, this diagram is correct.

EDIT: Note that ECEN flag must be enabled in order to write to the echo buffer.

I'm not working on AMK/NSPC porting (the current workflow is too low-level, "hard-coded", and "messy"). This is more to develop a VST.

So just to make sure, the FIR filter coefficients correspond to the oldest to newest echo history?

Higan uses a fixed-size ring buffer, where the elements are read from old to new, then the old is overwritten. People in the Snesdev thread claim that the real SNES uses a shift register.

If this is correct, this introduces an unexpected 7-sample delay in the echo.

----

EDIT: On the other hand, I finished my own echo implementation, and "without 7-sample delay" sounds better in FF6. Though they're all pretty bad.

I managed to get one perfect run out of my filter, I even recorded it. I've never been able to replicate it again.

(I don't have a real FIR filter, just a 7-sample delay.)

https://github.com/jimbo1qaz/snes-echo

----

EDIT: I just realized another problem: If the FIR filter adds an extra delay, SNES FIR filter runs at 32000hz and delays for 7/32000th of a second. My JACK server runs at 48000hz and delays for 7/48000th of a second, potentially resulting in an audible difference.

Oh well, time to get out AMK and create some test SPCs...

----

EDIT: I found the damn bug. My "echo buffer size" slider puts out values with slight floating-point rounding errors, and the int() function rounded "5 blocks" to "4 blocks", destroying the sound.

Also, I can confirm that "default FIR = 7-sample delay" is probably accurate (it sounds closer to the real thing). Although after the struggles I've been through, I'm still doubting everything.

https://sourceforge.net/p/faudiostream/mailman/message/35105932/

The graphics have a kind of NES feel to them. You use the black color quite a lot, for outlines and backgrounds. Most objects are brightly colored. The player, enemies, and a few of the levels also look quite flat.

Never mind.

welp, this gives me an idea:

I could organize upload some graphics I drew years ago, that never made it onto the site!

(yep, I found my files on a flash drive, they weren't lost after all)

----

sadly, my "universal video game music sequence interchange, transformation, instrumentation, and composition framework" won't be ready by then.

I'm kindly donating this *new and improved* Trash Can icon to SMWC. (under the CC-BY 4.0 International license, for public use)

I spent around an hour redrawing all the widgets, with the help of Wikipedia images, to remove JPEG artifacts. I now know more about the exact appearance of Windows XP widgets than anyone else outside of Microsoft!

Who's the trash can moderator?

As you may not know, I've been working on a cross-compatible video game sequence format and conversion tool. Unlike MIDI files, it will be designed for software (not old hardware), and contain jump, call, looping, and possibly segment structures, to preserve the structure of video game music.

https://github.com/jimbo1qaz/bms-format

I started with a Gamecube BMS file decoder. Right now, there's no good BMS to MIDI converter yet, so I'm creating something new and useful, even before I build the entire format, conversion, and synthesis ecosystem.

However, I'm going to expand to SNES, PSF, and possibly DS SSEQ formats. As a result, my current name, "bms-format" or "bms-sequencer" will not represent my project well.

Does anyone have any name suggestions? This tool will also need scripts, which need their own file extension. (My existing MIDI processor is called msh, or MIDI shell.)

Beyond MIDI (.bmid)

• Beyond msh (.bmsh) (nobody knows what msh is, and this is easily confused with .bms)
• BMID script (.bsh)

.jseq (hmmm... I'm totally not a jimbo1qaz rereg...) (already used by a Coffeescript test suite)

• .js (already used by Javascript)
• .jscript (sounds like JScript)
• .jsh ("The Christian Science Journal"... wtf?)

jseq is a good file format, but not a good program name.

What about Video Game Sequence (.vgs)? (already used for Connectix Virtual Game Station, PS1 emulator)

Not really a site redesign, but this makes SMWC prettier:

https://userstyles.org/styles/124003/noir-2

Modification of Noir by Wuthering (who still has yet to respond to my licensing inquiry).

I'm not sure what's more interesting, the fact that I found you on this site, what you're releasing here, or the number of replies so far.

Why is the Song of Healing piano better than every other SNES song I've ever heard? As if none of the composers knew how to make a good piano? Or does it just take up too much space?