After browsing the SNESmod portion of Damifortune's guide for a refresher, I had a couple ideas randomly pop into my head on how SNESmod and SPC music in general could be optimized.

NOTE: this is just theory. I know just enough about programming to know what measures need to be taken to optimize a given software but too little to actually properly fork and optimize someone else's project. Also, SNES assembly gives me a heart attack weekly

Anyway, all SNESmod users can agree that SCx (x = song speed - 1) is basically required in order to prevent the goofy popping noises in SPC music. However, having the effect column being taken up by a note cut for the last 16th note of any given tone is problematic to say the least. So... what if built into the note conversion script was a method that checks if a note's length is equal to the song speed, and if it is, automatically truncates the note? that would free up the effects column for whatever shenanigans you want to do.

How easy would this be? I don't know. SNESmod is a black box to me. Because I've only glanced at the source code, I can only sort of guess how it works. If I had to guess, sussing out whether a note should be truncated or not would be pretty difficult, but the truncating itself wouldn't be as difficult.

Now, notice that I said ideas PLURAL. That's right, I'm rambling more.

HOT TAKE: ROM files and song files should be separate formats. This isn't unique to SNES music, but it is easily most apparent in the format. Like seriously, they're practically entirely different formats. ROMs should be under different formats than song files. I'm just gonna throw it out there.

But seriously, imagine you worked on a super crazy SPC entry, using pattern jumps and pattern breaks to save an ungodly amount of space, just to have Charles Chiptune throw out some random unoptimized .smc in the same battle.

How would this be implemented? That's for you to figure out. This isn't really a major gripe for me. It's just kind of annoying. C'mon guys, it's basically different formats

i absolutely can't speak to the first point; however, i think the second take is indeed hot and relies on a pretty uncharitable view of what i'm kind of seeing as "our cultured tracker optimisation vs their barbaric DAW scribbles". i frankly do not view them as separate formats, they rely on usage of the same hardware, and i do not believe usage of C700 offers any materially significant advantage over SNESMOD unless you just really really want that extra space for samples. if i submit a .spc i'm really proud of and someone wins with a .smc, that's fair, they presumably submitted something that sounded better to voters and used a tool fit for their purposes.

n.b. i personally use SNESMOD because i find it easier; i think it's less fiddly than poking at a VST interface and it doesn't require messing with MIDI channels or anything

there was a whole thread about the option to add .smc/.sfc ROM filetypes to the SNES format, which you can read here: https://battleofthebits.com/academy/GroupThread/30545/ perhaps obviously, the conclusion was that they were good to be added, with the primary reasoning being "they play on the SNES". and they do, extremely accurately!

i don't disagree that the C700 ROM export is more powerful and much more forgiving about space (you can even see in the thread i was concerned about it three years ago), although as a counterpoint, you can write a great song in any tool, and it has not stopped people from writing great SNES music in their tools of choice.

SNESMod is merely one sound driver. There's a bunch of others out there these days, and I myself have been fiddling around with Terrific Audio Driver.

C700 is the most common sound driver that I've seen that uses the ROM these days, but it actually comes in a completely separate build SPC-side compared to the built-in player. However, as a counterpoint, I also know of its inefficiencies in its music format... and it reminds me of Eastridge Technology in a few ways.

However, there is a second, less common case, courtesy of AugustusBlkheart. https://battleofthebits.com/arena/Entry/The+Darkness+of+December/27464/ , for example, submitted under Wildchip, instead uses SNESMod's sample streaming feature. Yes, the author also sometimes submits song compilations... and he's actually the first one that actually submitted SNES ROMs. The first ROM entry, made with SNESMod, dates back from 2017, and the first C700 ROM ended up coming out shortly after that particular discussion.

Yeah you basically confirmed what I already knew. The .SPC format has sort of drifted to become a general SNES format, along with other console based ones, so I guess I just have to throw hands with an entire cartridge whenever composing for consoles and deal.

However, let it be known that I consider "inconvenience caused by tools" when voting on entries. It is a statement of fact that making ROM entries is leagues easier than creating song entries. Combine that with the fact that before the chiptune scene, only song formats played on consoles, and it is plain as day that if 2 entries of near equal composition are submitted, the song format wins. Would I call this bias? I don't know, but I am more inclined to vote for song format entries than ROM format ones

It's a fault of the .SPC file format itself being bad as a chiptune format, similar to .VGM it was only popularized because it was an easy way to dump the majority of game music files from the console, but whereas .VGM's problem lies when it comes to playing it back on that hardware, .SPC's lie on the SPC memory limitation restricting how much you can do.

The ability to do more than what the SPC RAM allows has been always there on the SNES since its years, Square's AKAO driver itself allowed for sequence streaming though it wasn't needed often and we see Tales of Phantasia's driver using sample swapping in its opening for vocals https://youtu.be/W3SA9LuqQgA.

In an ideal world the SNSF

format would have been the standard but it requires 65816 emulation for play back so very few players support it, and I've only heard of SuperC

supporting it as far as drivers go.

But I digress. I agree with the others that the last point is cheeky. If you want to do more within the SPC file constraints to feel good about how optimized your song is and not have the SNESMOD issues, I advise you to learn MML. The above mentioned SuperC has optimization as one of its main focuses and has sequence streaming and sample swapping, TAD

has support for some really cool effects and an easy visual reference for memory usage

I thought about mentioning Square's driver, but I decided against it because I didn't want to longpost. I've been trying to get into MML, but I'm already finding myself taking shortcuts with trackers. I keep plaicing all the notes in my DAW and then transcribing it to .it for effects. It works, but it's not as quick of a process as I'd like. I'm worried that if I pick up MML, I'll make my habits even worse.

.smc vs .spc isn't different botb formats, it's "snes music format" vs "snes music format with some arbitrary legacy restrictions", there's nothing virtuous about using the more restricted one. fair to think it's cool but that's orthogonal to the actual content, i don't think we generally give bonus points here if you played the guitar only with your feet or something

the nomenclature of the format is admittedly confusing - its format token is "spc" but that does not refer to the .spc filetype, it refers to the soundchip, SPC700 - the format is intended to encompass audio produced by that chip, not a single filetype

i do also think it's in bad faith to downvote a legal entry that followed all the rules of the format, broadly speaking

also i've never used snesmod but the note cut issue does sound like something that could be handled automatically by the converter! altho there could be caveats depending on how the song data is stored in the .spc

TAD looks super cool and i would love to get into it tbh.

also i'm absolutely taking the bait here but it feels strange to assert that creating ROM entries is just categorically easier than .spc entries.. that's a broad generalization that simply must fail to apply to a statistically significant enough amount of people to be reasonable. personally? SNESMOD is so much easier than C700 for me, and i very much hesitate to characterize any given approach as the easy way out or to assign value to the arbitrary decision to use a tool that one finds more difficult to use than another.

remember, everything we do here we do for fun!

I'll reply to this one specifically: https://battleofthebits.com/academy/GroupThread/42943/Random+SPC+ideas+I+had+today/#post212809

Yes, I can also play SNSF files, but interestingly, I have even less of a clue on what custom music tool generates those kind of files these days. I've heard of SuperC, though, and I've even used it as an entry, but always in SPC format... because of a lack of interest.

There are two examples I know of with regards to streaming musical data outright into a ring buffer for playback on the SPC side...

One of them was used solely in California Games II, and otherwise has a music player on the SPC side with timers and all.

The other one, used in the Mario's Early Years series, also has a buffer, but also requires a clock pulse-like signal, with the signal itself also transferring a variable number of bytes.

I also know of a couple of sample swapping and sample streaming cases each song-wise. The Lion King uses sample swapping in a few songs, and Captain Tsubasa V's opening sequence also has sample swapping. In both cases, they also have SFX samples stored in there, hence the swapping. And for the streaming case, yes, Tales of Phantasia qualifies, but what I was thinking about was ClayFighter's opening vocal song.

I will agree that sometimes the same tool can run both ROMs and SPC files (bsnes-plus and Mesen 2 qualifying, with me additionally knowing that bsnes-plus at the absolute least also supports SNSF), and that the main thing running through my head is that sometimes the players end up a bit separated because of the ROM/SPC difference. I also know of a tool that compiles a SPC file to a ROM to bridge the gap to some extent... and I actually made a Python script to quickly make one

, templating off of mic's SPC Player version 1.4.

Plus, the SPC and ROM formats implies that custom music is not limited to pre-existing tools: you may very well conjure up your own custom one for the occasion! And I've seen custom stuff both here and Super Famicompo, including some that I've made with my own sound driver, of which I've made multiple different ones over the years.

@kff interesting I didn't know bnes could play SNSF, that's good to know!

but yeah when I said "ideal world" I meant it, it would be if the format was more widely used, more games ripped using it, so new tools targetting it would be as common as targetting NSF for the famicom, but alas we're not there

I think it would be cool if was accepted as a submission format because of being a playable chiptune format, but since only SuperC (or someone using Chrono Trigger music hacking tools?) can export it, and it already exports the other formats it doesn't matter that much...

Maybe if Furnace supports it when it gets its driver built, or if TAD supports it once sample swapping is implemented... for now it's just a personal longing

Furnace to me is like Famitracker... it can be a lot harder to match playback to the SPC file or something else than you expect it to be. And I even think this was a problem during the commercial era in at least one case. That, and Plogue's Chipsynth SFC (a commercial product, I might add), of which I won it as a prize and did absolutely nothing with it because I entered the contest out of fandom, rather than for that... and I didn't see the point in it.

Thank God I did not buy chipsynth SFC