Language…
10 users online: Abstract, Alucard648, Alyssa, DeGezondeRoker, DerKorkin, Nitrogen,  Ringo, Sarcose, Stivi, Ziz - Guests: 73 - Bots: 341
Users: 66,008 (2,163 active)
Latest user: chiefrunningwolf2001

ripping brr samples from Snes roms (sfc)

Hi all,
This may be a somewhat unusual request, but I was wondering if there are any utilities to rip brr samples from Snes roms (sfc files) instead of SPC700 dumps.

The only way I've found to do this is to use a program like split700 to rip the BRr samples from each individual SPC file, then remove duplicates and go through BRR Player and remove the false positives. With as many samples as a game like say, Tales of Fantasia, Secret of Evermore, etc. might have, who knows how long I'd be spending sorting the mess of dozens of SPC dumps? If I was working on a specific port, this method would be fine, as I could just find a song that uses all the samples I need and extract them. But I'm going for just extracting stuff for future use here and trying to build an archive of brrs, and want to find the most efficient way of doing it. An added bonus is if I forgo the SPC dumps and just extract from roms directly, I'll have every sample the game uses, not just those used in the music or are included in the SPC dump. To a lot of people this may not be important but I like seeing those more hidden things.

I found a program called snessor95, I believe. It can see brrs in roms, but unless I am missing something, it can only convert to wav, not export brr. That program also seems to be a lot older than many of the brr decoders that are now used, I'd be hesitant to trust its decoding.
Does anyone have suggestions?
Thanks.
Make more of less, that way you won't make less of more!
I still use split, what you're not doing is checking the sample source through SPC Player.

When playing a SPC file, press the arrow keys until you see this (my SPC Player is in japanese, that's why it looks like shit). The first number of each channel is the sample slot, when an instrument you want to rip is playing on a specific channel, pause the SPC and go there, check the src (source) number and that's the sample slot where the current playing sample is, so when you export samples through split, check the two last numbers of the .brr, that's the slot. This makes sample ripping a lot faster and easier.

For example if you noticed the sample you want was in slot 3B, then open the .brr file named SPCNAME_3B.brr

I don't know any way to rip every sample from a a single rom though.
Yeah, I knew about that feature but am having trouble using it. Perhaps me being visually impaired is making it difficult since my screen reader program may not be able to see the SPC info displays. I'll play with it a bit more and see if I can get it to work, since that would be useful.

The main reason why I was asking about extracting samples from a rom instead of from spc dumps though is for archival purposes. So I can take a game I know I'll be using samples from, for no real purpose yet other than just to have them, and rather than go through the trouble of doing it through a myriad of spcs, I could just get all of its samples from a rom instead.
Make more of less, that way you won't make less of more!
If you have a musical program that supports VSTs (FL Studio, Anvil Studio, OpenMPT, etc.) you can download C700. This tool is able to playback samples of the SNES on your music program and also has a nice GUI. It allows you to imports SPCs as well and save the BRR files individually, so I hope this might help.
Thanks for the advice, but I don't know if this will help in this case because so far as I know, that VST only supports extractions from spcs, not roms.
Make more of less, that way you won't make less of more!
Sadly though, when ripping anything from SPCs with C700, it actually exports pretty large samples depending on the sample`s effects. Like, its definitely good if you want to get the exact effect the game used as a sample, but its often more trouble than its worth. Really, Split700 is actually the best for ripping or mass-ripping one/several BRRs, and they`re all with their loop points and not extremely oversized. I actually used it to get a lot of my WAV samples, and its just amazing IMO. lol
Layout by Mathos
Originally posted by Theultimate12
Sadly though, when ripping anything from SPCs with C700, it actually exports pretty large samples depending on the sample`s effects.

What do you mean? It literally does the same thing Split700 does.

Oh and musicalman, I'm afraid there's no easy way to rip directly from a ROM (there are ways but you'll have to look up the internal BRR table and it's a bit of a mess and different per game). If you want to use a game without any SPCs of it available, you'll have to make your own SPC using the SPC snapshot function most emulators have.
Originally posted by Torchkas
Originally posted by Theultimate12
Sadly though, when ripping anything from SPCs with C700, it actually exports pretty large samples depending on the sample`s effects.

What do you mean? It literally does the same thing Split700 does.


Well, to be honest, I`m only saying this because I have a few samples ripped with C700 that I found on the internet, and they are very large (and some of them dont even have the actual loop points, and its just a mess IMO). Here`s a example of what I`m talking about:

https://www.dropbox.com/home?preview=longOD.wav

As you can see, its not looped at all, and is awfully large for some reason. Definitely not fit for the SPC700 at all (unless you manage to get the loop points right and crop/trim the sample). I`m not quite sure why that sample is like that, though. Maybe it was the ripper`s choice?
Layout by Mathos
That link doesn't work, but if you're talking about C700's wav conversion, that's a different feature altogether. I'm talking about its SPC ripping feature, which just takes the BRR straight from the SPC just like split700 does.
SPCtoMML does a good job of ripping all samples in an SPC, and you don't need to header them so they're immediately ready to be used in a port. However, ADSR/Tuning is another story, as it isn't always accurate.
Originally posted by Torchkas
I'm afraid there's no easy way to rip directly from a ROM (there are ways but you'll have to look up the internal BRR table and it's a bit of a mess and different per game).

This was my initial impression, that every game was different and needed to be done individually, but the old Snessor95 program seems to rip from roms. It can probably do spcs too, but I tested it with a couple roms and it seemed to get the samples out. Only trouble is it can't export BRR, only wav. So that's why I was asking if there was a way to just export brr, since Snessor seems to be able to see the samples in a rom somehow.
Make more of less, that way you won't make less of more!
Originally posted by musicalman
The only way I've found to do this is to use a program like split700 to rip the BRr samples from each individual SPC file, then remove duplicates and go through BRR Player and remove the false positives. With as many samples as a game like say, Tales of Fantasia, Secret of Evermore, etc. might have, who knows how long I'd be spending sorting the mess of dozens of SPC dumps?


I would like to fix split700 so that it no longer generates duplicates and false positives. Does anyone have an example SPC file where it produces a lot of these so that I can step through it in a debugger?
I found a good example of an SPC file that produces "false positives" (still looking for a good example of one that produces "duplicate" brr files). It's the "item get" sound effect from Secret of Mana. This command:

Code
./split700.exe item_get.spc


produces 22 .brr files for me. The ones with _00 through _06 at the end of the basename are strange buzzing noises, which I do not hear when the whole SPC file plays. It's easy for me to just delete these if I only want to convert one SPC file, but if anyone is going to do a massive music REing effort where they really want split700 to not produce these, let me know.
Hey jeffythedragonslayer, thanks for your interest!

Originally I asked about this because I wanted to extract all the samples from a game, whether they were used in music, sfx or otherwise. Also, I thought I might eventually make some brr sample packs of games. But I kinda realized that's not my thing, so I probably haven't touched split700 since I last posted in this thread 6 years ago. So, I can't provide super specific information, but I can show a case where things go wrong.

Apparently, the last thing I tried to run through split700 was this. I grabbed the latest split700 from here.

I used the following options: -M --force. This produced 256 files. I ran the folder through a duplicate file checker and it removed I think 65 files, amounting to about 5 kb of data. I can't remember exact figures here. While I'd like to conclude that my duplicate sample complaint is based on cases like these, where the duplicates are false positives, I can't be certain of that.

Even after killing duplicates, the samples which are left are full of false positives and legitimate samples gone wrong. wawo-07_cd.brr for instance sounds like a fragment of the lead melody instrument, but the sample is incomplete. In BRR Player it cuts and then starts clicking, maybe because of trying to loop the wrong data?

A few other samples get the same treatment, and tbh I can't tell what most of them are supposed to be, but there is definitely legit content it's trying to pull out. The only proper samples I could get were 00 (a bass/guitar mix), 02 (a bass), and possibly 7e (a hi hat), and a few other odds and ends, probably fragments of sfx.

I next tried omitting --force from the command line. This only exported 4 samples, two of which are aforementioned sfx fragments. Many legitimate samples are missed.

That's all I got. Hopefully it can help shed some light on what's going on, whether it be with split700 or something I could be doing wrong.
Make more of less, that way you won't make less of more!
Originally posted by musicalman
Hey jeffythedragonslayer, thanks for your interest!

Originally I asked about this because I wanted to extract all the samples from a game, whether they were used in music, sfx or otherwise. Also, I thought I might eventually make some brr sample packs of games. But I kinda realized that's not my thing, so I probably haven't touched split700 since I last posted in this thread 6 years ago.

I just hope the reason you feel that way isn't because of bugs in split700.
If split700 is holding the snes scene back, then it should be fixed.

Originally posted by musicalman
Apparently, the last thing I tried to run through split700 was this. I grabbed the latest split700 from here.

I used the following options: -M --force. This produced 256 files. I ran the folder through a duplicate file checker and it removed I think 65 files, amounting to about 5 kb of data. I can't remember exact figures here. While I'd like to conclude that my duplicate sample complaint is based on cases like these, where the duplicates are false positives, I can't be certain of that.

Even after killing duplicates, the samples which are left are full of false positives and legitimate samples gone wrong. wawo-07_cd.brr for instance sounds like a fragment of the lead melody instrument, but the sample is incomplete. In BRR Player it cuts and then starts clicking, maybe because of trying to loop the wrong data?

A few other samples get the same treatment, and tbh I can't tell what most of them are supposed to be, but there is definitely legit content it's trying to pull out. The only proper samples I could get were 00 (a bass/guitar mix), 02 (a bass), and possibly 7e (a hi hat), and a few other odds and ends, probably fragments of sfx.

I next tried omitting --force from the command line. This only exported 4 samples, two of which are aforementioned sfx fragments. Many legitimate samples are missed.

That's all I got. Hopefully it can help shed some light on what's going on, whether it be with split700 or something I could be doing wrong.


I don't think it's something you're doing wrong - I also see only 4 samples without --force (too lazy to check all 256). Because it's omitting many legitimate samples in that case, it sounds to me like the way split700 decides whether a sample is corrupted is bugged. I count no less than 10 "return false" statement in Split700::IsValidSample, and only one "return true," so it may be too aggressive. This one in particular caught my eye:

Code
	if (sample.start_address < 0x200) {
		// usually, samples should not be in direct pages
		return false;
	}


Calling the sample "invalid" if it's in the direct page (there is only one, but it can move) sounds like a hypothesis to me, not a conclusion. Maybe having a configurable "confidence threshold" and outputting the samples in order of how likely they are to be real samples would be better. What do you think about that?
Originally posted by jeffythedragonslayer
I just hope the reason you feel that way isn't because of bugs in split700.
If split700 is holding the snes scene back, then it should be fixed.

I'll admit I steered away from sample ripping partially because of this, but that wasn't the full reason. I just enjoy making my own samples more. Besides, spc2mml is a working alternative for extracting samples. It hasn't failed me yet in that department. However, it only grabs samples which are actively being used, not any extra sample data stored in the spc. Also, it only supports one spc at a time. So it's most useful for porting, and not for making sample collections/packs. That said, I am fully in favor of improving Split700! The more I delve into music porting (for any soundchip really), the more I see bugs in the tools, so I'll never discourage anyone from trying to make improvements and or fix issues.

Originally posted by jeffythedragonslayer
Calling the sample "invalid" if it's in the direct page (there is only one, but it can move) sounds like a hypothesis to me, not a conclusion. Maybe having a configurable "confidence threshold" and outputting the samples in order of how likely they are to be real samples would be better. What do you think about that?

It sounds like it could be a viable option, especially the bit about outputting samples in confidence order. But I'm afraid that most snes musicians, myself included, would only have a vague understanding of the confidence metric, so setting a threshold would be akin to looking for a magic number. Not a huge deal if the confidence order works and is reliable, but I personally would be tempted to just export everything and work from there. In this case though, i'm not sure that would work, since as I said some samples seem to be partial exports. Unless setting a correct confidence threshold could somehow remedy that. Not trying to discourage the idea, just a little concerned about how it would play out.
Make more of less, that way you won't make less of more!
Originally posted by Samantha
SPCtoMML does a good job of ripping all samples in an SPC, and you don't need to header them so they're immediately ready to be used in a port. However, ADSR/Tuning is another story, as it isn't always accurate.


Thank you for recommending this Samantha. I opened wawo-07.spc in SPCtoMML and clicked "Export Samples" and 11 brr files were dumped. I don't hear any duplicates or false positives. The fact that this tool can dump BRR files from SPC files isn't well advertised, but it does a good job. (The tile bar being "Super SPC Dumper 1000" makes it sound like something that extracts SPC files from ROMs.) I'll be adding it to my toolset.

Originally posted by musicalman
Besides, spc2mml is a working alternative for extracting samples. It hasn't failed me yet in that department. However, it only grabs samples which are actively being used, not any extra sample data stored in the spc. Also, it only supports one spc at a time. So it's most useful for porting, and not for making sample collections/packs. That said, I am fully in favor of improving Split700! The more I delve into music porting (for any soundchip really), the more I see bugs in the tools, so I'll never discourage anyone from trying to make improvements and or fix issues.


SPCtoMML seems to fit my needs better, so I'll more likely focus on using its techniques in a new command line tool. Not many people are familiar with what unused game samples sound like, so learning about them is not a priority for me as a composer who wants to emulate Kikuta.

Originally posted by musicalman
It sounds like it could be a viable option, especially the bit about outputting samples in confidence order. But I'm afraid that most snes musicians, myself included, would only have a vague understanding of the confidence metric, so setting a threshold would be akin to looking for a magic number. Not a huge deal if the confidence order works and is reliable, but I personally would be tempted to just export everything and work from there. In this case though, i'm not sure that would work, since as I said some samples seem to be partial exports. Unless setting a correct confidence threshold could somehow remedy that. Not trying to discourage the idea, just a little concerned about how it would play out.


Yeah, it sounds like a huge research undertaking, doing it this way. I also think this is an example of Rice's theorem and not easy in general to dump all the samples without actually running the SPC file - who knows what kind of synthesis the SPC700 could be doing at runtime.
I use a far more detailed approach than just using a program on the ROM or a series of SPC files. My method tends to use the hex editor directly, and I do lots of 65816 ASM lookups depending on the game I'm working with.

In some cases, all it takes is just a single SPC file and I have the entire thing. Vanilla Super Mario World is an excellent example of this.

In other cases, I can rely on the internal VxSRCN IDs, but I have to track down which ones load what individually. The earliest ones don't apply (they instead have VxSRCN IDs that overlap depending on the add-on pack used), but the versions along the middle of the life of the Sculpture Software sound driver are my citation: they have a special 65816-side structure that they use that is assigned to each VxSRCN ID. Certain bank IDs load only certain samples, and I have to track them down accordingly.

And in a third case, the internal VxSRCN ID is no good and I have to use a different method. Sometimes the program helps me out and gives me an internal ID that is converted.

The best case scenario where the VxSRCN ID is not consistent in the SPC files is Donkey Kong Country: Diddy's Kong Quest and Donkey Kong Country: Dixie Kong's Double Trouble! They have a special system that auto-converts an external sample ID to an internal VxSRCN ID right in the SPC700 program.

The worst case scenario where the VxSRCN ID is not consistent in the SPC files, but at least it stays in one place is when either raw pointers are involved for individual samples or there is BRR data duplicated in the ROM because they're not really sorted by raw ID. The raw pointer case is doubly so if I have to use it just to find all of the music and SFX packs, which I have also done before hunting down all of the music, including unused songs, SFX, samples, or all of the above.

For the raw pointer method, I cite Time Cop and Super Dany because I had to use the pointer method for each individual sample. This means that I have to sort out all of the pointers for duplicates.

For the other case with duplicate BRR data... Mother 2/Earthbound. It has a lot of sample pack IDs, but there seems to be the occasional duplicate in some of the packs.

And then we have the cases where the sample directory itself is being modified on the fly, which renders automated extractions to be far more complicated. I'll start with these, which are more minor:
  • Nintendo/Akihide Inano (Super Punch-Out!!)
  • N-SPC/Ocean
  • Ocean/Jonathan Dunn


Nintendo/Akihide Inano (Super Punch-Out!!) can modify the sample pointer through a VCMD. It's generally not used in most cases, but there are some cases where it is used, usually with sound instances being swapped in and out (I think Bald Bull's winning laugh is one of them). This will have few complications on extraction, if any.

The other two, N-SPC/Ocean (I don't know how far back this occurs versioning-wise, but it does exist past a certain point) and Ocean/Jonathan Dunn, update the sample directory the first time the sample is played from a different internal directory. This means that extraction can be done normally, but the entire song must loop at least once. More critically is that this affects properly extracting the sound effect samples, since they are in the same situation as the music in that they will not extract properly without playback.

The third-to-worst case scenario period for ripping is when the sample directory itself is constantly being modified in the middle of playback, which renders automated extractions to be far more complicated. This is a small list of sound drivers that I know have this situation. One game cases are noted in parenthesis.
  • Later Sculptured Software (earlier ones don't have this problem)
  • TROET SoundSystem
  • Chris Hüelsbeck
  • Haus Teknikka (Frantic Flea)
  • Norse (Dorque and Imp/Dorke and Ymp)


In the later cases of Sculptured Software, I discovered a loophole in how they're handled: they're actually stored like a standard sample directory somewhere else. The other cases I can't do this, so I have to do some other kind of reverse engineering.

The second-to-worst case scenario period doesn't affect the sample directory... but it does affect the ability to extract one or more BRR samples. These cases are impossible to extract unless you want to record exactly what the SPC700 is playing in its BRR data (I'm not talking about the raw sample output, rather I'm talking about what the SPC700 is actually processing in its BRR data) and manually loop it yourself, because the BRR data is being generated on the fly.
  • N-SPC/Nintendo/F-Zero
  • N-SPC/Koji Kondo
  • AddmusicM
  • Square/Minoru Akao
  • Allister Brimble

Note that in most of the above cases it isn't found in every single build (and game), except for the ones I marked under Allister Brimble. The only two types of generations I know of are PWM and a kind of noise BRR that isn't the internal noise generator.

The worst case scenario period? Well... I actually have one, and only one, that I know of. It's Williams' Arcade's Greatest Hits. Except for Sinistar's voice (which is stored as standard BRR samples), all of the samples are dynamically generated on the fly as a series of writes to the VxGAIN DSP register. The BRR sample is merely effectively silent except for being off-center, resulting it in being audible when VxGAIN is constantly written to.