How can I get all channels to actually produce any sound?

[Theultimate12]

Here's a quick attempt. The samples are very short and of low quality, so finding suitable loop points (let alone loop points that are divisible by 16) is pretty hard. If they are ripped from SNES songs, then keep in mind that it's not only the sample itself which defines the sound but also how it's used. Clever swapping between several small, bad-sounding samples can often create the illusion of something that sounds much better in sum.

All right, then, gonna try and see if they work. Thanks again! XD

[Brozilla]

Here's a quick attempt. The samples are very short and of low quality, so finding suitable loop points (let alone loop points that are divisible by 16) is pretty hard. If they are ripped from SNES songs, then keep in mind that it's not only the sample itself which defines the sound but also how it's used. Clever swapping between several small, bad-sounding samples can often create the illusion of something that sounds much better in sum.

You actually cheated on some sample loops
The sample is to be played until the very last sample slice, that is loop end is identical to the last point in the sample. Example being the strings. The total sample length is 6786 which isn't divisible by 16. For trackers the details are trivial but when it comes to SPCs that is a different story.

In ARAM the sample is ultimately stored in a BRR format and failure to adhere to the previous means you're NOT guaranteed the prescribed sample loop and may likely become a bad loop. That is why "accurate" loops are important unless you got a clever programmer.

The technique you're referring to may require swapping samples from ROM into RAM. I assume that'd be some MML equivalent function-call command. Without a ROM it'd be next to impossible to do that since an SPC is audio state from the SNES ARAM. If you mean having let's say 2 string samples, mid & high strings then "swapping" (instrument change) between the two based on octave/pitch then yes that'll create a more believable sound.


BTW: I know you're just trying to help lol so don't take me too seriously xD
A little tidbit as to why the samples sound bad is in part because a lot of the instruments come from synthesizers around that time. Examples being Roland U-110, Roland SC-55, Korg M1, which I THINK the sample library the Snes dev-kits came with were from the SC-55 but it might be too recent. So basically you're taking a "not really" believable sample set and making it worse by compressing it more. The reverberation on the synthesizers are more powerful, otherwise it's very tricky to get decent reverb on the SNES.
To be honest, if you have time SagaX, I'd like to here you make something SNES.

[Saga Musix]

The sample is to be played until the very last sample slice, that is loop end is identical to the last point in the sample. Example being the strings. The total sample length is 6786 which isn't divisible by 16. For trackers the details are trivial but when it comes to SPCs that is a different story.

Or in other words, I simply forgot to trim the sample. Which I would hope would be done automatically by a decent conversion tool anyway.

And btw, it's either Saga or Saga Musix, nothing inbetween. And no, the nick has nothing to do with any RPG Sagas or whatever, before the next person asks.

[Brozilla]

I believe most BRR conversion tools disregard the loop end instead of trimming it since it's usually assumed (AFAIK) you want as much of the sample as possible. In my early attempts there would sometimes be garbled data at the end of my sample (had a loop end before, garble was small too) and it made it impossible to loop properly. If you simply forgot to trim though then yes you're fine.

And sorry for calling you something else (that is SagaX.) Didn't want to always type Saga Musix but also wanted to acknowledge the clever 'x' at the end of the string so tacked it on to Saga instead. If Saga is fine I'll presumably use that instead

And no, the nick has nothing to do with any RPG Sagas or whatever, before the next person asks.

Doubt it did but that's kinda what imagination told me.

[Saga Musix]

I believe most BRR conversion tools disregard the loop end instead of trimming it since it's usually assumed (AFAIK) you want as much of the sample as possible.

If you directly convert your modules to SNES files, this is not relevant though since you cannot jump beyond the loop end. So I'd hope that e.g. SNESMOD would take this into consideration. If not, these tools clearly need to be improved.
If they are pure WAV files, on the other hand, the authors of those conversion tools probably just didn't bother reading the loop information chunk from WAV files.

[Theultimate12]

Here's a quick attempt. The samples are very short and of low quality, so finding suitable loop points (let alone loop points that are divisible by 16) is pretty hard. If they are ripped from SNES songs, then keep in mind that it's not only the sample itself which defines the sound but also how it's used. Clever swapping between several small, bad-sounding samples can often create the illusion of something that sounds much better in sum.

You actually cheated on some sample loops
The sample is to be played until the very last sample slice, that is loop end is identical to the last point in the sample. Example being the strings. The total sample length is 6786 which isn't divisible by 16. For trackers the details are trivial but when it comes to SPCs that is a different story.

In ARAM the sample is ultimately stored in a BRR format and failure to adhere to the previous means you're NOT guaranteed the prescribed sample loop and may likely become a bad loop. That is why "accurate" loops are important unless you got a clever programmer.

The technique you're referring to may require swapping samples from ROM into RAM. I assume that'd be some MML equivalent function-call command. Without a ROM it'd be next to impossible to do that since an SPC is audio state from the SNES ARAM. If you mean having let's say 2 string samples, mid & high strings then "swapping" (instrument change) between the two based on octave/pitch then yes that'll create a more believable sound.


BTW: I know you're just trying to help lol so don't take me too seriously xD
A little tidbit as to why the samples sound bad is in part because a lot of the instruments come from synthesizers around that time. Examples being Roland U-110, Roland SC-55, Korg M1, which I THINK the sample library the Snes dev-kits came with were from the SC-55 but it might be too recent. So basically you're taking a "not really" believable sample set and making it worse by compressing it more. The reverberation on the synthesizers are more powerful, otherwise it's very tricky to get decent reverb on the SNES.
To be honest, if you have time SagaX, I'd like to here you make something SNES.

Hmm, so, will I have to get/rip different samples than those that I have so I can get a more accurate loop? Or can that still be done with the samples I have right now? I am kinda confused tbh. XD

[FreezeFlame(Alchemy)]

Joining the conversation.

Hmm, so, will I have to get/rip different samples than those that I have so I can get a more accurate loop? Or can that still be done with the samples I have right now? I am kinda confused tbh. XD

It can be done with the samples you have. Just reorder the loop points and make sure they are divisible by 16.

[Theultimate12]

Joining the conversation.

Hmm, so, will I have to get/rip different samples than those that I have so I can get a more accurate loop? Or can that still be done with the samples I have right now? I am kinda confused tbh. XD

It can be done with the samples you have. Just reorder the loop points and make sure they are divisible by 16.

Well, the samples that Saga modified are already in that way you just said, but they arent really looping the way they are supposed to (along with having a lot of crackling, but I manually took them out so its not that big a deal). Like for example, I am trying to make a cover of Megaman Zero 3`s Trail on Powdery Snow, but the synth brass lead on that sample set isnt looping properly. It might be because of the sample being too short, but still. XD

[Brozilla]

If you directly convert your modules to SNES files, this is not relevant though since you cannot jump beyond the loop end. So I'd hope that e.g. SNESMOD would take this into consideration. If not, these tools clearly need to be improved.
If they are pure WAV files, on the other hand, the authors of those conversion tools probably just didn't bother reading the loop information chunk from WAV files.

I never tested SNESBRR (think that's the tools name) with a "bad loop" but what's certain is without doing it yourself there is no guarantee of your loop. I've had sample loops that sound good/acceptable in MPT/Milky and turn bad using SNESMOD or the C700 vst (emulates SPC700 chip) because I did not take into consideration some of these things. So while it could work, just for consistency, it's best to do as much upfront as possible that way you're guaranteed the smallest file size with the BRR data.

Well, the samples that Saga modified are already in that way you just said, but they arent really looping the way they are supposed to (along with having a lot of crackling, but I manually took them out so its not that big a deal). Like for example, I am trying to make a cover of Megaman Zero 3`s Trail on Powdery Snow, but the synth brass lead on that sample set isnt looping properly. It might be because of the sample being too short, but still. XD

Those samples are honestly a lot shorter than expected but I'll see if I can get them to loop a bit nicer.

[Theultimate12]

If you directly convert your modules to SNES files, this is not relevant though since you cannot jump beyond the loop end. So I'd hope that e.g. SNESMOD would take this into consideration. If not, these tools clearly need to be improved.
If they are pure WAV files, on the other hand, the authors of those conversion tools probably just didn't bother reading the loop information chunk from WAV files.

I never tested SNESBRR (think that's the tools name) with a "bad loop" but what's certain is without doing it yourself there is no guarantee of your loop. I've had sample loops that sound good/acceptable in MPT/Milky and turn bad using SNESMOD or the C700 vst (emulates SPC700 chip) because I did not take into consideration some of these things. So while it could work, just for consistency, it's best to do as much upfront as possible that way you're guaranteed the smallest file size with the BRR data.

Well, the samples that Saga modified are already in that way you just said, but they arent really looping the way they are supposed to (along with having a lot of crackling, but I manually took them out so its not that big a deal). Like for example, I am trying to make a cover of Megaman Zero 3`s Trail on Powdery Snow, but the synth brass lead on that sample set isnt looping properly. It might be because of the sample being too short, but still. XD

Those samples are honestly a lot shorter than expected but I'll see if I can get them to loop a bit nicer.

Oh yeah, I actually forgot to upload the updated samples, along with the MMX2 overdrive guitar one (since that was also supposed to be on the .zip file, but I forgot to put it in the pack). Here is the revised sample pack:

https://www.dropbox.com/s/vkfd7ptzrcau2c1/MMX%20Sample%20Pack%20V.2.rar?dl=0

[Brozilla]

The thing is whoever ripped those samples or the utility they used is what created the problem. I tried looping the samples myself and the fact some weren't  [x =16 + 16n] is already enough to spell disaster. If you convert from BRR -> WAV then there is no reason to end up with an arbitrary sample length as 16 is the smallest BRR block size. Obvious enough when the person who ripped it couldn't loop it properly. This section explains the BRR format and it is why I stress 16 samples so much. http://problemkaputt.de/fullsnes.htm#snesapudspbrrsamples

Long story short is wherever you got those samples I can't vouch for it's "goodness." You are probably better off ripping the files from the rom/SPC which is what I did. Didn't get all but most of the instruments from your file. They are .xi or Fast Tracker II instruments.

[Theultimate12]

Well, I have converted the samples Enumerating (can I call you that?) gave me to a WAV format, gotten the missing sample I needed (the X2/X3 distortion guitar) and changed the frequency of all of them, along with trying to find a great loop point in all of them. The problem is, though, is that I dunno if these are good enough loops or not (probably not, but ehh), so I`ll send these samples again for you guys. Thanks so much for helping me do this, btw! XD

https://www.dropbox.com/s/ptt6b73utn65qhk/MMX%20Sample%20Pack%20V.3.rar?dl=0

[Brozilla]

I'm not sure what you did but a lot of those samples wound up as stereo and the loop points seem worse than before. You should avoid changing the sample rate whenever possible because that affects sample size/length and may screw with delicate loops. If you exported the sample from the .xi properly you should end up with accurate instruments. The attachment contains the .xi instruments as a wav file. If a sample is too high/low in pitch then all you need to do is transpose it, otherwise avoid changing the sample rate.

If you need a specific sample/instrument looped properly I'd recommend ripping it from an .spc file. If you rip it from a ROM and the frequency is incorrect/untuned then you'll end up with a non 16 divisible sample (like the pack you sent us) and it'll cause nightmares unless math is done to adjust sample frequency but why do all that when the SPC already gives you the loop points? For a tracker forum we're almost going out of scope

[Theultimate12]

I'm not sure what you did but a lot of those samples wound up as stereo and the loop points seem worse than before. You should avoid changing the sample rate whenever possible because that affects sample size/length and may screw with delicate loops. If you exported the sample from the .xi properly you should end up with accurate instruments. The attachment contains the .xi instruments as a wav file. If a sample is too high/low in pitch then all you need to do is transpose it, otherwise avoid changing the sample rate.

If you need a specific sample/instrument looped properly I'd recommend ripping it from an .spc file. If you rip it from a ROM and the frequency is incorrect/untuned then you'll end up with a non 16 divisible sample (like the pack you sent us) and it'll cause nightmares unless math is done to adjust sample frequency but why do all that when the SPC already gives you the loop points? For a tracker forum we're almost going out of scope

Well, I have actualy converted the .xi file with this: https://www.coolutils.com/online/XI-to-WAV#, but it isnt really working as expected. Which converter would be best to use?

Also, how do I make so the samples produced in the .spc file are actually like the ones you sent me? I have been trying to rip some Seiken Densetsu 3 samples (along with getting the X2/X3`s distorted guitar that was missing from the samples you sent me), but the samples I am getting in the .spc file arent looping like you said they would. Do I have to do this manually or...?

[Brozilla]

First off is you don't need to convert .xi files with openmpt. You could load it right in. When you are ripping, are you doing it from the SPC or ROM? Also are you getting a .brr file or a .wav file? Ideally it should be a BRR file. As a last resort you can loop them yourself but it all depends on HOW you rip it.