Getting a .sfc from .rom+.pcm?

[shadelegend333]

I'm trying to see if I can match my snes and wii vc roms to the DAT but I can't figure out how people are restoring checksums with original SPC data.

[Vigi]

By taking the .spc data from other non-VC ROMs (different versions/regions of the same game) and injecting it manually with a hex editor.

[shadelegend333]

Is there documentation somewhere to learn what goes where (structure,beginning of where a certain track should be vs random data)?

(I'm not that experienced using hex other than removing/adding padding, and editing ascii...)

[pokechu22]

You can use vcromclaim to merge them (either with direct extraction from wiimetadata.py, or by using snesrestore.py). Note that this is only compatible with python 2.

[Vigi]

You can use vcromclaim to merge them (either with direct extraction from wiimetadata.py, or by using snesrestore.py). Note that this is only compatible with python 2.

That won't work I think. AFAIK it used decompressed lossy data, so you won't be able to restore the original checksum.
The script that's posted here should work however: http://forum.no-intro.org/viewtopic.php ... 9&start=15

[pokechu22]

Oh, I missed all that previous discussion. I don't know how I feel about using a different ROM to recreate one; that seems weird to me (and feels like it defeats the purpose of using the VC from in the first place. I also see this poll on whether VC dumps should even be included, but I'm not sure what the consensus on that is...)

I thought I previously did get a matching SNES dump using that tool, but it looks like that wasn't actually the case. (I haven't submitted any of my Wii VC dumps; I should probably read up on how to do that at some point)

[dreimer]

Recreate is quite the right word. What is done here is reverting one change Nintendo did for their emulation on (Wii) VC. They zeroed out all SPC data and added a pointer for the emulator knowing when to run which PCM stream.
That reverted by using a known valid ROM as base you have two ways it can end:
The already different internal checksum in header of the VC title is suddently right aka you properly created the previously used base ROM or it's still wrong...
In that case you have two ways again. SPC data was changed too in the base ROM or Nintendo didn't care at all about the internal checksum. Latter one can be nicely seen in recent SNES re-releases of Switch Online. (I ignore the script made a mistake case here )
They simply gave a f*ck about internal checksums (The ones with bad checksums are not included in no-intro yet). Not just Nintendo, Sqaure aka M² did the same for the re-released Mana ROMs. (Still not all included into no-intro as they have bad checksums too). Possibly modified SPC data making the checksum right is lost of course as we only have the data from the known valid ROM.

Now to the main point. We cannot add all and as you see they aren't. Only ROMs getting a valid checksum after treatment can be verified as being the correct base ROM Nintendo used in the VC titles. That this practice is valid can be seen on all the ROMs being 1:1 the same already found in other VC re-releases. And yes, these are important to preserve as these sometimes are ROMs meant to be sold on carts (Rev* alike updates) but never were. (Or were but were never found by now).

Still Nintendo has them in their archives and we want these hidden treasures in database too ^^

[zcal]

So my understanding of all this is that the below three key decisions are at play here. Is this correct?

1. No-Intro's goal is to include in the DoM records of ROMs that Nintendo keeps in their private archives, even if those ROMs have not been publicly released. This is why dumps from the SNES Classic, for example, that have been patched with SPC data from good cartridge dumps are listed in the DoM.
2. No-Intro is not (yet) interested in including in the DoM records of ROMs that are accurately dumped but cannot be run on the original console of release or in an emulator that has not been specifically written to accommodate them. This is why SFROMs from the VC and the SNES Classic are not listed in the DoM.
3. No-Intro is not (yet) interested in including in the DoM records of ROMs that have been modified from accurately dumped but generally non-useful formats like SFROM without using data not included in the dump itself. This is why .sfc/.smc ROMs split from VC or SNES Classic SFROMs that are missing sound data are not listed in the DoM. This is also why such ROMs that have been patched to include sound by converting and injecting PCM data from the SFROM are not listed.

[dreimer]

1. ROMs which have a valid internal checksum are accepted, yes. These are verified as being 1:1 what Nintendo had as base material before converting them to SFROM. ROMs with bad checksum are ONLY added if they were released in that rebuilt way 1:1, too. (See Switch Online threads)
2. + 3. SNES database only includes valid SFC file format. Aka ROMs which run on the real thing. If someone decides to make a SFROM database these still would not be in the main database, but only in that subdatabase. See FDS database, these are different databases for different formats.

Anything I forgot @staff?

[xuom2]

yep dreimer, thanks.

"Original format" (and "fixed" = "original" if the dump tool changes the dump in a known way and we can revert the changes) is more important than "playable" to be in DB as official item, exported to datfile. Any other format can be in DB for documentation purposes.
Any system can have its exceptions, dumps outside the ruleset but interesting to be preserved: a pirate dump or a homebrew in rare occasions could be in the set (flagged with a specific flag?).
It's interesting to have in DB any extracted ROM from other dumps. Those could be flagged as (extracted) and I could add an user-option to have them in datfile or not.
Hacks, trainers and translations will stay outside the project.

[zcal]

It's interesting to have in DB any extracted ROM from other dumps. Those could be flagged as (extracted) and I could add an user-option to have them in datfile or not.

So does that mean that it's possible we could get the sound-less ROMs split from the dumped VC or SNES Classic SFROMs included? Seems to me that there's a case for those, but maybe not for versions of those ROMs injected with the dumps' original PCM-converted-to-BRR sound data?

[dreimer]

Problem here is that there are different .SFROM formats. I stumbled upon three by now.

1. Wii VC: You have the sound stripped .ROM file, a .VAR file and a .PCM file.

2. SNES Mini: You have a .SFROM file containing the concatenated info of sound stripped .ROM, .VAR and .PCM seen above + some fine header and footer.
Exceptions are the FX titles like Star Fox 1+2 and SMW2 Yoshi's Island AND Super Formation Soccer on the Super Famicom Mini. These are unstripped SFC files in theory. Just with a Header and a Footer. So maybe you can even say that is even another file format...

3. Switch: You have a SFROM file with the ROM file including sound and a footer with additional emulation specific information about the game. This one works fine when started inside a SNES emulator as the footer is useless and unused for running that game.

(https://wiki.superfamicom.org/sfrom-file-format)

So if you really want to add information which are only useful inside the VC title / SNES Mini / Switch Online you would need at least three different format specific databases for that OR at least include all these into one.

[zcal]

Hrmm, I see the dilemma. To be clear, I'm not necessarily arguing that those dumps should be included, just trying to clarify the limits of what's "supposed" to go in the DoM.

I don't have any VC or Switch dumps, but I did extract all the SFROMs from the North American SNES Classic. Splitting those apart into separate .rom, .var, and .pcm files, I can confirm that the .roms work in at least Snes9x when renamed as .sfc, just without sound (exceptions being Yoshi's Island and Star Foxes, of course).