Many of you have read my lamentations over the .vgm file format. It's both bloated and somewhat limited as to what chips (or how many of each chip) it supports. I spent a lot of time daydreaming about of a better .vgm file format including rewriting the header spec and support for pattern data.

...and then somewhat recently I realized that the furnace file format, .fur, does all of this already. It doesn't make any sense to me for n00bs to be rendering their furnace projects to .vgm if they could simply share their work for all to see.

So, before we go ahead and replace .vgm with .fur in many chiptune formats, I thought I'd run it by y'all since we're a community!

Not too sure which formats would benefit from the ongoing inclusion of .vgm, but am I excited to reduce the amount of .vgm coming into the archive. :D

As a big fan of source modules from the standpoint of community sharing, I'm a fan. It would be interesting because people in some cases could share the source if they'd like or a hardware-ready export if preferred. Any downsides apart from Furnace's existing limitations with specific chips on vgm export (which is a valid concern)?

Couple of other thoughts - does this impact the VGM format? Also, what about considering allowing both .vgm and .fur rather than swapping out in these cases for folks who would rather not share source if given the choice?

From the lyceum, here's the list of formats this could potentially apply to. Unless I'm missing some:

-AYM
-PC engine
-Atari Pokey - puke already updated this one per discussion today
-Atari Pokey x2 - also updated
-Genesis/MegaDrive
-SMS
-YM2151 / OPM

Other possibilities?
-AdLib - doesn't currently allow .vgm but would make sense since we allow .mptm and .a2m, .rad, etc., and I think we've already been using furnace in some cases
-NEC PC-x801? I'm guessing this one's trickier because according to the article VGMs > 128KB are not hardware playable, so I'm guessing this one wouldn't make much sense

I'm cool with this, but food for thought:

* Some .fur features cannot be exported to vgm, even for supported formats. For example, YM2612 sample volume commands can be done in the software but are ignored on VGM export.

* Even though hardware playback for the VGM format is mostly nonexistent, there are exceptions, like for Genesis. No such luck for .fur; you'd have to convert to VGM first which would defeat the whole point.

* On the other hand, the VGM spec supports some features that would be practically impossible to play back on hardware anyway, because it would be too much for the target platform's CPU to handle (think of sample streaming on chips that don't normally support samples). Tildearrow has tried to spec Furnace such that everything could theoretically be played back on HW but he's kinda just taking a guess at it.

Ultimately, though, I think my concerns are offset by the fact that everyone would be sharing their source modules, which is always cool. And theoretically Furnace will eventually let you export fur files to hardware-compatible formats, but this will inevitably take forever. While I would never make VGM submissions illegal (not that that's what you're suggesting), I think more Furnace support on BotB would be cool, and would maybe even encourage more people to write hardware playback engines for it??? Please???

Also: What about formats that don't currently accept VGM or .fur but are covered by Furnace? Like NSF for example? Okay maybe that's a bad example because the format is named after the exported filetype (nsf) but I figured I'd throw it out there

Edit: C64 is a better example. No VGM support, but Furnace supports it... without hardware export. Probably not a good idea?

i'm generally in favor of the .fur support, though i think it's best to take this consideration on a format-by-format basis

a) because of how messy/spotty hardware support is for .vgm, and
b) because some botb formats that accept .vgm can get their exports from other programs like deflemask - and we can't really take .dmf source because of it being paid now lmao, what a mess

sega genesis/megadrive:
- .vgms can also come from deflemask, so methinks .vgm needs to stay, at the least
- one thing to consider about .fur here is that Furnace has that fancy Dual-PCM mode that software mixes two audio streams for ch6 sampling. for .vgm export, that requires an intensely bloated filesize, but for .fur this wouldn't be a problem. perhaps that's a bit larger-than-life
- also, using a tool that converts the .vgm to ROM, .vgms of a certain size can be made hardware playable

sega master system:
- .vgms can also come from defle or sneventracker, so .vgm should stay, at least
- also hardware playable via conversion tool
- i don't see anything wrong with also allowing .fur here though

pc-engine:
- .vgms can also come from defle, likewise worth keeping on the list because of that
- furnace's sampler here is pretty wild. it tends to sound better/more powerful in the tracker vs in .vgm export where some things stop working
- fuck it tho imo let's do it. this format is already kinda scuffed lol...

ym2151:
- .vgms can also come from defle, so i think it should stay
- .fur seems totally fine tho

sap/sapx2:
- would rather see the source here especially since afaik furnace is the only .vgm generator here; but this raises a good question about whether the raster music tracker modules should also be allowed?

pc98:
- .vgm is *not* allowed in this format already because it has a pretty limited hardware playability due to filesize. but it's worth considering whether .fur ought to be allowed. i could really see this going either way; it would open the door for "why not also allow .btm bambootracker modules", at least. i'm not personally offended by that but it's a good question

aym:
- afaik furnace is the only .vgm creator here, so why not .fur instead? why not indeed. .fur at all costs.

adlib:
- .vgm isn't allowed here already either, but .fur should totally be in the list of supported filetypes. actually, technically there isn't a list of supported filetypes here, maybe because there's so many options

gameboy:
- i am truly not sure what else can generate .vgm for this format besides furnace, but i'm pretty sure there's something. are they hardware playable ever? i don't know that either! why not add .fur to the already preposterously long list of options. sure
- furnace does have some sort of fancy instrument envelopes for this format though which apparently aren't supported by the .vgm spec (yet?); someone else will know more about this than me

vgm:
- probably a no-brainer but this one makes sense to leave as only .vgm lol

are there others? probably?

One other consideration for gameboy in furnace is the use of software envelopes utilizes a hack. I don’t see anything about zombie mode being considered illegal in the lyceum, but gb experts may know more on that one

Zombie mode works in BGB if I use an external tool to convert vgm to gb. It's not the format itself that's the issue, it's that no VGM player uses a GB core that supports it. However, that converter tool also breaks using the softsynth on the wave channel (or that sounds scuffed in BGB, hard to tell) so it's a net neutral

sorry about commenting here after all these months of absense, but i couldn't resist about this one... :)

imho, .vgm and .fur are totally different formats, and i think we should keep both, in the same way we have .nsf and .ftm, for example

also, there are chips that are supported in .fur that aren't yet on .vgm (like that one used in Casio PV-1000 game console, i forgot its name - among a few dozen), and vice-versa (like ymf278b, used in several arcade machines, and msx community calls it as "moonsound" - among a few dozen too) - meanwhile both vgmtools and furnace projects might help each other support all formats that are not supported yet, but this will take some more time and development/research/testing effort/synergy for sure

.vgm is a cool format that we can create even from a hex editor, hexdumps, generative scripts, converters, etc. (like what i shared at https://notabug.org/nitrofurano/vgm2vortextracker )

and .fur is also a cool format - as if we have deflemask battle format, why not furnace as well, since that furnace is way incomparably more stable, better featured, more flexible and usable, and productive?

and about some .vgm being bloated, i guess that it is related to the file size on submissions, so that could be limited when submitting - the limit now seems to be over 12mb, when, for example, at websites like vgmrips (as reference, to compare) we rarely find vgm files larger than 1mb ( like this one, https://vgmrips.net/packs/pack/daytona-usa-sega-model-2#01-let-s-go-away-advertisement , expanding that .vgz (.vgm.gz) to .vgm, is 1.1mb )

I see multiple points of discussion here:

- .vgm vs .fur as a file format
- source file submissions for entries
- whether a file type appropriately represents a format (to be considered on a case-by-case basis)

My 2c on the matter:

In terms of the file format itself, I see .vgm and .fur as two distinct format types. I will refer to Exhibit B of jaxcheese's blog post on preservation

, which is an excellent read I highly recommend. .fur is like a manuscript whereas .vgm is at least one level of abstraction closer to a performance. To that point, I think it makes more sense to accept .vgm (*with a caveat I'll get to soon) over .fur for hardware based formats. Not only is it closer to the performance level of abstraction, it also allows for more flexibility in terms of what tools/software can be used to produce an entry for a format.

Another point for accepting .vgm over .fur (or other source files) is stability. Furnace is still being developed, including the file format spec, and the spec is going to include a bunch of tracker specific details, whereas .vgm is a spec about chip register writes (not tracker specific, targets hardware) and we can expect .vgm files to be relatively "shelf stable".

There is a practicality aspect to consider too, i.e. are people universally using Furnace to produce .vgm files, and if so would it make more sense to say, well everyone is using Furnace already so let's accept .fur? My gut feeling is this is not the case yet, as I've seen a few entries somewhat recently that still use e.g. Deflemask (particularly the mobile version).

In terms of submitting source files, ideally I think this could be a separate optional upload on entries. But outside of that, in general I think anything should be acceptable so long as there is a well understood path to go from uploaded file to playable on hardware (and this path should ideally be relatively stable and deterministic). Getting into specific format cases with .vgm:

- I think adlib should allow .vgm and I'm somewhat surprised the answer was no last time I asked, given that SBVGM exists to play .vgm on hardware. Although the format already accepts a wide range of file types already, so for this case it might be a moot point.
- I'm also somewhat surprised sap(x2) allows .vgm given that there isn't a hardware player, at least not that I know of. As precedence, it's not allowed for pc-x801 because they're not always hardware compatible. It might be nice to have someone more familiar with the Atari 8-bit scene chime in here.
- Tangentially, SnoozeTracker is not allowed for sms even though it exports to .vgm which is generally allowed for the format and it still targets the SN chip, since there is no viable hardware playback mechanism for it yet.

Also, to stretch the argument further, is there a case for accepting source files for all formats? There's been plenty a "don't submit .ftm/.0cc to nsf", should that rule change if .fur takes over .vgm?

(thanks <3)

The thing is you cannot in most instances use a .fur file to play a song in hardware

whereas most accepted chip format file types do have hardware playback functionality. To let fur and even vgm in where it cannot play back muddies what we need a file type for

oh boy I opened a tin can of worms here

there's a lot to respond to

One thing that's weird about .vgm is that beyond emulations its supposedly nice for hooking a microcontroller up to an SD reader and an audio chip for listening on hardware. You can't exactly simply do this tho with audio chips that are actually embedded inside the console's custom CPU package. This is true of the nes, gameboy, and pce at least.

On the topic of modules/submission formats:

I've already said it in another thread, but I think the submitted format for hardware-focused formats should be a playable format. So it's guarranteed what is played both in hardware and in player emulation is the same. I think having an "upload module" option to the website, in the same way there is does for MP3 renders would be the best of both worlds, so people who want to share the original modules can do it too.

On the topic of VGM being accepted for more formats:

VGM walks the fine line here that support for the chips doesn't necessarily mean they can actually be played in the original consoles the chips were on, but at the same time we're always only a programmer away from doing so, or at least being able to hook the target chip to a PC and playing it that way, and there are many projects who already do just that.

But for information on what ones that do have hardware playback and I think would be fine to submit a VGM:

Platform formats:
- sgen - there are vgm2rom converters
- sms - there are vgm2rom converters.
- gameboy - there are vgm2rom converters
- adlib - there are VGM players for DOS

On chip-specific formats:
- aym - MSX can play VGMs on AYM.
- ym2151 - MSX can play VGMs with an expansion

But the ones that would need further discussion:
- hes - only vgm player available only plays SMS vgms. also the format is named after a file format.
- pcx801 - VGM players are very limited, be it through size limitation or not being able to play ADPCM. Not reliable unless the song is made targetting these limitations.*

Personally I think it's pointless to allow VGMs for platform-targetting formats that don't have support for them. In a way this also encourages the use of different tools for them. People here don't have a problem with NSF not accepting VGMs even though there are VGM players for the NES, as one can "just use famitracker for it", but not apply the same logic to other platforms. And less for .FUR submission when the VGM export doesn't exist at all, like c64 and sap/sapx2.

* OPNA VGMs can be more reliably played on MSX with an expansion given enough RAM.

+1 to the idea of an "upload module" button, feels like that should be a thing regardless of the outcome of this discussion

not wanna talk too much here, but if we get fur in sap, then i can also submit ftm to nsf, ya? ^.~

I don't really have a horse in the .fur/.vgm race, but hell yes to a separate "module upload". Maybe call it something like "source upload", that's a bit more general and would let you do stuff like attach a .psd to a visuall. Sharing source be good.

As I see it, there are two questions here:

1. Should the "vgm" battle type be depreciated? (This question may not actually be being asked here, so forgive me if I read incorrectly!)
2. Should .vgm be allowed as a format option for various formats?

#1 seems pretty straight-forward: Yes, I'd say continue it as a battle format, for the same basic reason there's "bytebeat [vanilla]", the size-limited s3xmodit options, and the ten zillion different variations of NES formats. It's not 1:1 the same as furnace battle format, both because .fur can support a wider range of chips and a greater amount of them at once, and also because there are tools for .vgm that aren't available for .fur.

#2 is a bit murkier and I think it has to be case-by-case. For instance, .vgm has a history of being "the" format for Genesis/Megadrive songs. If someone wants to listen to the Streets of Rage songs, they grab Project2612, and that's .vgm. Same with Master System. For those formats, I think .vgm should absolutely continue to be supported. For everything else, I wouldn't really lose sleep if .vgm was deprecated in favor of .fur.

Rewording the last section of what I wrote, I think it was too harsh. I bring up the hardware playability thing more for making a more consistent ruleset than "no, .FUR bad". More consistent ruling reduces the questioning of "what abouts"?

Like what about NSFs should VGM be allowed since there are VGM players for the NES? The NSF format targets specifically that format so it's easier to consent that it's not allowed.

When .FUR, which is solely the project file targetting a soundchip, is allowed, what would separate it from the other source file projects? Taking it to an extreme, should a Renoise project targetting a VST with accurate synthesis, or a MIDI-out for hardware like MAmidiMEmo or Super MIDI Pak be allowed?

I think "submission should be a playable format", and using current hardware playability to determine what formats should allow VGM in it (and updating as more players are made) would make a consistent ruleset that also is consistent with how botb has operated for the most part

i usually prefer formats with little different filetypes mainly for ohb voting purposes. it's just so much easier to open your playback setup once and then go through every entry.
if you need to have two or three tools for playback open all the time, it doesn't necessarily makes ohb voting more accessible

> if you need to have two or three tools for playback open all the time, it doesn't necessarily makes ohb voting more accessible

For the most part, this isn't an issue with foobar2000 - these days the foo_input plugins are pretty faithful (as long as you don't use foo_input_zxtune for Amiga stuff, haha). You can even drag-drop the votepack.zip straight into the playlist. About the only issue is having to remember to reconfigure bassmidi for msgs/mt32/xg - I just use standalone players for the latter two.

I can't think of any formats which foobar either doesn't handle or doesn't handle properly, which also aren't locked down to one particular filetype (snibbe or pxtone, for example)

I think .fur should be the standard provided that users can still use other tooling to create their stuff other than furnace. Probably a tool could be written/already exists to convert VGM to furnace? The good thing about VGM is the diverse support it has from different software, the bad thing about VGM is literally everything else.

I guess what I'm saying is that a good standard is better than the best format. But that's how you end up with 6 competing formats!! I'm for .fur and I hope that tooling exists for its adoption as a ligua franca to dethrone .vgm

Thinking about the archive side problem of .vgm though... can't something be done on the server to compress the vgms uploaded to the site into .vgz? Wouldn't make miracles but certainly could help reduce the size

.vgz are .vgm files compressed as .gz (as .vgz is the same as .vgm.gz) - i usually use engrampa or file-roller on gnu/linux for compressing files to .gz format, perhaps lots of compressing software (like 7z?) can do that, just needing to try if vgmplay can play them - so perhaps vgm battles could accept .vgz files as well?

it seems like n00bs are already confused by it :o
(see here)

.fur allowed in sap format?
obviously .fur has to be allowed in nsf format too then

and i cant rly blame them

voting on chip formats that allow .fur is going to be problematic. I can't downvote them because they're an allowed format, but at the same time a .fur based on pokey cant be played back on the target machine . So what next, I don't vote on them?

@lint_huffer Foobar just doesn't feel like a solution to me. Just a few days ago someone submitted an NSF that broke in Foobar. Unlike specialized playback tools, where you can be reasonably certain that the tool will perform admirably at playing back the chips it claims to support, you already mentioned a foobar plugin that breaks that rule. And besides, there's no .fur player for Foobar yet, so it doesn't solve that problem.

@gotoandplay No, I would hope you would vote on them normally, because they would be legal entries (in this hypothetical scenario). I don't think this is a situation that would benefit from protest voting. When dami submitted a massive sgen VGM with vocals that was too big for any existing flashcart, I just swallowed my pride and gave it a fair score.

@kleeder I think this confusion will go away once a final decision is made and the lyceum is updated. But that means a decision should be made soon.

My own perspective has shifted a bit as I've thought about it. It seems like the rules get a lot less consistent when Furnace is added to a ton of formats. It can do things that have not been demonstrably proved to be possible on the target hardware. And, in the here and now, it can't be played back on *anything* without going to VGM first, which defeats the whole point of adding it to BotB. It moves the focus of the formats away from hardware playback. It would make a lot of formats with shit tools more accessible, but I'm not entirely convinced that's worth muddying the rules so much.


I do think a something could be done to preemptively prepare BotB for the eventual expansion of real Furnace exports, though: explicitly allow ROM exports and VGM for formats that don't explicitly support them currently. In my ideal world, this means genericizing NSF to accept ROM files and VGM's (There's a VGM player for real NES hardware, though it doesn't support expansion chips and I have no idea how good it is). But I feel like that's not going to happen, since we already have three NSF formats solely for legacy reasons. Maybe we need a fifth NES format (nsfc, nsf, nsf+, ntrq, generic nes)?


in any case I hope "upload source file" becomes a thing

mp3 at all costs

yeah, my opinion has also shifted over the course of this thread and some time to think. i still think it's entirely format-specific, mind you. but if we want to continue placing a focus on hardware-playable stuff -- and the sentiment of this thread seems to support that -- it kinda makes sense to stick with .vgm in places where .vgm is already allowed (which is primarily places it's hardware playable somehow), even though generally it's just an export away... and it doesn't make much sense to add either in places where there's no hardware .vgm player.

this once again raises annoying, format-specific questions:

1) is there a hardware .vgm player for sap? if so, great! ideally let's test it! if not, neither .vgm nor .fur should be legal here.
------> HOWEVER, for sapx2, which is already not a hardware playable thing unless you have some cool frankenstein physical setup, i wouldn't find .vgm offensive; i think that was the original convo sparked by this post in Summer Chip XIII. supporting the .fur module though only makes sense if you also support .rmt
------------> HOWEVER 2, there's also plenty of "hardware unplayable unless you have a crazy setup" nsfs in the nsfplus format, and we are cool with that as it is. i think.

2) adlib. yes it's back on the table. here .vgm makes more sense from a "hardware playable" stand point, yet supporting the module types that render .vgm (.fur and .mptm) matches better with all the other filetypes being DOS modules. a .vgm file is but an export away from either of those, but it still kinda walks over the line -- in basically all the other formats, presenting a working export is a way of proving your work & showing that it runs properly.
------> that said, i haven't heard any .vgm exports from either .mptm or .fur that sound substantially different than the module... or seen issues with exporting. it's a weird precedent, but i think it might be ok here.

3) re: genesis, i'm leaning towards not allowing .fur because of the Dual PCM mode thing. it hugely bloats .vgm exports in exchange for additional sampling capabilities, but i think this is an acceptable tradeoff, whereas if you submitted a .fur you'd just get that "for free". doesn't seem fair. also, allowing that one module type while disallowing the others doesn't make sense (which gets extra messy with deflemask being paid software now)
------> tangentially, if people have issues with 8mb .vgms being submitted to this format, please change the max filesize to something hardware playable (4mb i think right?). nobody should be punished for working within the rules set forth in the format on this web site.

4) what to do about the NES format trio? well, we should test the .vgm player, first of all. if it sucks, maybe we pass on adding it. the annoying thing here, though, is that the formats are named "NSF". we could think about either changing it or keeping it as a "historical thing but now a misnomer". i'm not saying the name, of all things, has to hold us back from fair representation of hardware playable filetypes. NES ROMs seem like they should be totally fine, for example! but it should be considered.
------> going off what Blast_Brothers said about the NES .vgm player not supporting expansions, an extra layer of confusion could potentially be added by supporting .vgm in nsf & nsf_classic but NOT nsfplus. that seems difficult to deal with.

5) this is not a very fun suggestion, but what about pc-engine/tg16? if you can't even play .vgms targeting this machine on hardware... does it need to be in the list at all? is it too harsh to remove it? nearly everyone submits .vgm to this format nowadays
------> similarly to the NES formats, this one is also named "hes" after a filetype. is this an argument in favor of expanding the NSF formats' offerings? maybe.

everything else i think is fine the way it is, in the spirit of "proving the export works" and in the name of general consistency across our formats:
- sms stays .vgm
- gameboy stays .vgm
- ym2151 stays .vgm
- pc98 stays no .vgm or .fur or .btm

a separate source upload would be awesome. best not to dilute other formats with modules where exports have traditionally been expected in the many years of this site; it's too weird a precedent and it doesn't make sense to support one (.fur) but not all the others. that's too messy.

yes, let's all become furries

a related thought -- i mentioned this briefly in my feature request thread about a filetype checker on uploads, but it'd be so so helpful for the little "about the format blurb" -- as in the space where you submit your entry or read the format description -- to list all the valid filetypes for the format.

i think this would also help point people in the right directions and not end up in a situation where they wrote for the wrong filetype and are screwed. right now, the valid filetype list is hidden behind viewing the lyceum. that's one click away, sure, but it's still a barrier (esp for new folks). it'd be cool to see that listed with the max filesize on the format info blurb.

VGM is a recording, and as such has conceptually more in common with MP3 than e.g. tracker formats. I'd say it shouldn't be a primary format in any of the chipist categories, except maybe wildchip, although it's fine as a secondary format that optionally can be rendered when supported.

Somewhat related to the VGM issue, there's often no clear division between platform and format in the categories, so you can for example submit a SNES cartridge that executes whatever code you want in the spc category, while for you're limited to a VGM recording with no code in the sgen category. For Amiga, neither of those options (program or recording) are available; instead there are several categories where you can submit formats that are only compatible with specific Amiga software (Soundtracker variants and AHX).

I'm sure the categories have evolved organically, but maybe it's time to ponder a few more questions along with the VGM one: Why aren't cartridges allowed for sgen like for spc? Why aren't executables allowed for adlib like for sid? Why isn't there an Amiga/Paula category like there are for most other platforms?

> VGM is a recording, and as such has conceptually more in common with MP3 than e.g. tracker formats. I'd say it shouldn't be a primary format in any of the chipist categories.

This line of analogy gets a bit murky, because (unless I'm missing something obvious) at the level that VGM is like MP3 (a set of instructions that, when executed under the proper framework, produce sound), every format is like MP3.

While there's cases to be made for and against widening the base of formats that allow .VGM (/.FUR), there's no reason whatsoever to forbid it for sms/sgen, at bare minimum.

> you can for example submit a SNES cartridge that executes whatever code you want in the spc category

And if voters take the non-musical content into consideration, they are violating the rules. The Lyceum is pretty clear about this:

". . . anything containing visuals should be judged solely on the music".

> Why aren't cartridges allowed for sgen like for spc?

Because there's no point. The .VGM format is robust enough. The SPC has the pretty infamous 64k limitation, and the .spc format does not allow for streaming fresh data into the chip - it's basically Thunderdome. Programmers during the SNES's lifespan were routinely pushing data into the spc700 in mid-song (the Clayfighters opening comes to mind), so allowing a .smc isn't really breaking the spirit of the format.

> Why aren't executables allowed for adlib like for sid?

Hardware compatibility. The tools people used decades ago to write SID music on actual C64s would often save as .PRG, because that makes sense in a C64 context. Conversely, I'm unaware of any AdLib tool that would generate an .exe, because that doesn't make sense in the context of a late-80s PC.

> Why isn't there an Amiga/Paula category like there are for most other platforms?

There was nothing particularly special about Paula aside from the stereo configuration (which sadly isn't really enforced for voting purposes here, but that's a rant nobody wants to hear). Save a .wav file as 8bit, 24kHz, and that's Paula. Add a component to trigger a global 12dB lowpass and that's Amiga. Amiga audio was limited by the amount of memory and storage space available at the time, not by sound chipset. These days you can even play mp3 and ogg on an Amiga with AmigaAMP.

A Paula format would be like having formats for Sound Blaster, Sound Blaster Pro, and Sound Blaster 16.

On the note of sgen, there are other specs outside of .vgm that target it like xgm from SGDK

, and there are drivers (the XGM driver in SGDK, MDSDRV

, Echo

, Fractal Sound) that can support features that the Deadfish Genesis VGM player that is mainly used doesn't support, like multiple PCM pseudo-channels.

Also, worth noting that especially with Furnace exports using DualPCM that are currently relying on Direct PCM Stream, it's possible for the .vgm to go over 4MB which the Deadfish VGM Player doesn't support. At some point Furnace is supposed to get ROM export support which I assume will include support for DualPCM tracks. So we're weirdly in a situation where a) .vgm technically puts extra limitations on the format, and b) allowing .bin submissions would bypass that limitation while still staying in spirit of hardware compatibility, but c) there aren't really any good workflows for non-vgm based ROM exports today other than maybe XGM (but then nothing exports directly to XGM), at least not that I know of.

I think the same technically goes for the sms format too and this thing for overclocked .vgm's

, although that's more of a bespoke approach. We've also had people submit SnoozeTracker entries which have not been proven to be actually hardware compatible.

> at the level that VGM is like MP3 [...], every format is like MP3.

VGM is like MP3 in the way that it lacks the structure of the original format, so you typically can't open it in the editor again after exporting it.

> there's no reason whatsoever to forbid it for sms/sgen

What is special about sms and sgen, compared to other platforms?

> And if voters take the non-musical content into consideration, they are violating the rules.

I'm not sure what the argument is. Like you say, this is covered by the rules.

> The .VGM format is robust enough.

That depends on the definition of "robust". If I understand correctly, you can make VGM files that can't be played back on the actual hardware.

> I'm unaware of any AdLib tool that would generate an .exe

Would there have to be one? If someone is able to write a replayer that exploits a sound chip in ways that none of the existing formats allow, why are they allowed to do that for SNES and C64, but not Megadrive, Adlib, or Amiga?

> There was nothing particularly special about Paula [..] A Paula format would be like having formats for Sound Blaster, Sound Blaster Pro, and Sound Blaster 16.

Conceptually, Paula is similar to SPC in SNES, GF1 in Gravis Ultrasound, or SPU in Playstation. Each of them mixes multiple channels in a way that gives them a distinct sound. The Sound Blasters you mention don't perform hardware mixing, so they aren't directly comparable.

to more specifically answer the question you posed about "why are these not allowed", i think it's mostly that there haven't been extant tools to produce something like that, so it's never really come up. as you say, the formats evolved organically. for example, the ROM option was only added to the SNES format a couple years ago because someone brought up the possibility of producing them with C700 VST. i wouldn't see any issue with ROM submissions for e.g. genesis that are playable on hardware and contain no copyrighted content, either. sounds totally fine to me. i just doubt it's been brought up before. if someone did this somehow (likely via being a homebrew dev of some kind) i imagine it'd be allowed; the list of valid filetypes doesn't have to be the 100% final answer and exact list forever

(please correct me if i'm wrong: from the 41 chips supported from .vgm format, furnace now supports 31 of them - and among the 10 missing ones, opl4 (ymf278b) is about to be included soon (thanks grauw, from msx scene!) )

idea: remove all formats. add new ones. then go through the process of assigning new formats for all 60k+ entries manually :DD

> VGM is like MP3 in the way that it lacks the structure of the original format, so you typically can't open it in the editor again after exporting it.

Which is in line with most formats. The exceptions are when the software itself is the format (pxtone, jummbox, panda, renoise, etc) or where the format was designed to be played from the development enviornment (s3xmodit, midi).

> What is special about sms and sgen, compared to other platforms?

Long-standing tradition of the respective soundtrack sets being archived and distributed in that specific format, plus hardware playback. For better or for worse, if you want the "canonical library soundtrack" of all games released for the system during its lifetime, the files will be .vgm.

> I'm not sure what the argument is. Like you say, this is covered by the rules.

The argument is that there is, simply put, no benefit to executing whatever code you want in an .smc file, because that code cannot be considered when evaluating the entry.

> That depends on the definition of "robust". If I understand correctly, you can make VGM files that can't be played back on the actual hardware.

"Robust" is a pretty simple definition. The .vgm format is equipped to handle anything that developers created during the system's lifespan. This is different from an .spc, which cannot handle certain commonly-used techniques. The fact that it's possible to create a .vgm that cannot be played back on hardware is irrelevent to whether the format is "robust". The 4MB limitation is primarily down to the software engine used to play back on hardware, not the format itself.

> Would there have to be one? If someone is able to write a replayer that exploits a sound chip in ways that none of the existing formats allow, why are they allowed to do that for SNES and C64, but not Megadrive, Adlib, or Amiga?

There's nothing an .exe could send an AdLib that can't be handled by the various AdLib formats, and there's no magic replayer which is going to add a fourth channel to a MOS-6581. It's literally not something that can happen.

In a very simplified sense (less simplified for VGM though!), the formats are the stream of data that the soundchip receives from the main executable. All a hypothetical AdLib .exe could do would be to, practically speaking, create a different .a2m.

The excess data in an .smc is strictly a place to store excess sequence data (and, theoretically, sample data, though the current version of the SPC700 vst does not yet allow for this), and in a C64 is essentially just a bootstrapper that contextualizes the data, which is why .PRG > .SID converters exist.

> Conceptually, Paula is similar to SPC in SNES, GF1 in Gravis Ultrasound, or SPU in Playstation. Each of them mixes multiple channels in a way that gives them a distinct sound. The Sound Blasters you mention don't perform hardware mixing, so they aren't directly comparable.

The comparison to an SPC isn't really accurate, the SPC is a full-fledged processor which can sequence data and add certain DSP effects. The "distinct sound" of an SPC stems largely from the gaussian filter applied to all samples and the on-board echo/reverb effect, and doesn't have anything to do with channel mixing. Again, the filter is not part of Paula, it's a completely separate part of the Amiga architecture. Aside from certain primitive cross-mod effects which are extremely rare in practice, the "distinct sound" of a Paula is simply a certain bit depth and sampling frequency, there's no "magic atoms" going on.

> no benefit to executing whatever code you want in an .smc file,

> There's nothing an .exe could send an AdLib that can't be handled by the various AdLib formats

> the "distinct sound" of a Paula is simply a certain bit depth and sampling frequency

It sounds like we have different technical backgrounds, so let's agree to disagree.

By all means, feel free to point out any mistakes I made. I think that would be a bit more productive than asking why people can't submit ROM binaries to Genesis battles and then snarking about "technical backgrounds" when someone says "because that would be pointless".

And even more productive than that would be actually putting that technical background of yours to work and submitting something to a battle (or, uh, even listening to what other people have made, tbh - you've been here 18 months, man!), but...

I think we can definitively answer the title of this thread - .fur is not the new .vgm. What that means for BotB continues to be an open question.

This is about to fall off the front page, so I'm bumping it

It feels like the consensus is that this needs to be a case-by-case thing, depending on how easy it is to get from VGM/fur to something hardware-compatible.

Source upload would be cool
Filetype checker would also be cool
(Personally) we should allow ROMs in things like NSF, because it seems intuitive that if something can be turned into a ROM, then it's a legal entry, so the ROMs themselves should be legal entries

> Also, worth noting that especially with Furnace exports using DualPCM that are currently relying on Direct PCM Stream, it's possible for the .vgm to go over 4MB which the Deadfish VGM Player doesn't support.

I just want to shed a bit of light to this, because while this IS true, you can absolutely optimize it for size.

ValleyBell's VGM Tools suite includes a program called "dacopt". The name is self-explanatory, it undoes the direct DAC stream and finds ways to optimize it into a sample map of sorts. All Good Times required Direct streaming to be enabled, which resulted in a 12MB VGM. After using dacopt, it was compressed to 400kb (and gzipped, it was reduced to a further 123kb)

Only downside is that doing this takes long, and your mileage may vary depending on how heavily you use Dual PCM (in All Good Times, I actually don't use dual PCM, I had to use it because I was changing the volume of the PCM samples via the volume column, which requires that to be enabled, lest I wanted my samples to sound garbled)

yeah
so I started this thread and then was quickly overwhelmed by it

there are so many great points

i guess going on a case by case basis is best

.fur has been added to adlib for example

I think furnace should be added to nsf+ for like 1 reason

MMC5 PCM
this is probably like really dumb but idk any other software that supports this pcm channel besides furnace, so I think it being added to at least this would kinda make sense

(this argument could also be really dumb depending on how you look at it aswell, though)

can we finally remove .fur from sap formats please?
unless someone can verify that a furnace vgm export of a pokey-track can be played back on hardware...

i think that anyone that can code (6502 assembly for example) a rom file or image tape for atari 400/800/5200/xegs/etc. can code a pokey vgm player that could run on hardware - as coding a vgm player for colecovision/ is so simple from the z80/sn76489 side - i really wonder why no one coded anything for that yet....

cool, then do that and as soon as you're done with it, i see no issue with re-adding .vgm or .fur to sap formats again!

i started this thread at atariage forum, very probably people can help us are there: https://forums.atariage.com/topic/361580-pokey-vgm-hardware-player-needed/