Correct MSU-1 Volume Levels

Hello everyone,
I'm new to this board.

As many of you would know, the SD2SNES firmware has been patched to enable boosting volume and a new hardware revision has been planned. So this means that all patches and soundtracks can be corrected to be used in the same fashion as in bsnes/higan.

I have been working on a script to convert any pack to the latest higan format:
https://board.byuu.org/phpbb3/viewtopic.php?f=7&t=1244
I have also been compiling my own list of MSU-1 packs:
https://board.byuu.org/phpbb3/viewtopic.php?f=8&t=1254
Lastly, I have attempted to compile all patch sources:
https://board.byuu.org/phpbb3/viewtopic.php?f=8&t=1259

At this juncture, I would like to update the source of each patch. This involves changing any writes of 0x66 to the $2006 register to 0xFF.
However, I'm curious as to how I should approach the fading routines. Is it just a matter of calculating percentages?

Also, does anyone have a copy of the Super Mario World 1.5 source? The link has gone down.

Thanks,
Kakashi

Rule of thumb, the games you need to correct will use a value somewhere near $60-$80 for full volume, change that to $FF, somewhere close to $30-$40 for half volume, change to $7F, fades are tricky because it might have some constant value like $02 or $04 added/subtracted from the current value, in which case double it, or it might use inc/dec instructions, in which case you'd need to recode it to add more inc/dec instructions or replace with adc/sbc. Have you done any asm coding before or do you need a full ELI5?

I haven't coded ASM in over 10 years, so an ELI5 would be very helpful.

What a coincidence you started this thread, I was gonna ask about this. I just recently put all the MSU-1 packs on my sd2snes and am noticing some issues with -db boosting. I have my SNES hooked up to nice stereo speakers, not professional or anything, but nice.

I was playing Chrono Trigger with the it boosted +6db (the pcm's are a little low compared to the SPC sound effects) and noticed some songs have a noticeable dip in quality. Hard to explain the bad sound. Sort of like if you play a low quality file loud and can tell it just sounds a little cruddy. Odd though it's only been on 2 or 3 songs where it's really noticeable. One in particular in the Proto Dome area is really bad. Had to knock it down to 3.5db.

F-Zero with +12db boost setting makes the SPC sound effects have a loud distorted sound sometimes. For instance, when you get bumped in the back by a car or run into the rails the noise is very loud and unpleasant. Very odd SPC sound. I had to go into the hex and change the 60 to FF like it was in the old patch. Then set the db boost back to 0.
Conn's 1.6 compatibility patch wasn't working for me. No MSU-1 recognition on sd2snes so it fell back to SPC.

I recall playing a little bit of Map 1 of BS Zelda and noticing some odd sounds or distortion too at +12db. Need to play it some more though.

As a result, I've been doing the opposite of you and looking for all the pre-amplified packs.
Are you guys not having any problems with boosting?
I wonder if it's just my sd2snes or something? How is your guys speaker setup to test this?

I wonder if this has to do with the very recent sd2snes board Revision G. I thought ikari had said that there would be no more board revisions after F and that it'd be the last one, but recently in June new boards popped up with Revision G. Ikari posted this over at krikzz's forum:

The difference from Rev.F is that the DAC runs at 5V to improve on the MSU1 volume issue. See also http://forums.nesdev.com/viewtopic.php?p=155367#p155367
Rev.G is otherwise identical in capabilities and compatibility as no core hardware has been altered.

I unfortunately have a Revision F so I wonder if this is really affecting the volume that much. I wouldn't think it would. Really wish there had been a volume standardization from the start.

In terms of the pcm files, I'm simply looking for a one size fits all solution. It would be too much effort to work out which were too quiet and which were too loud. The only thing remaining is fixing the patches themselves.

The pre amplified files will sound worse than fixing the code because the level you have to amplify them to often leads to clipping. I found that out the hard way doing the files for Conker. Thankfully, Conn was able to give me the corrected code so that one is fine. Kakashi, I can help you out some more later next week once I get home, I'm out of town at the moment. For now, you should at least be able to separate out the hacks that you know use the correct full volume (use bsnes-plus, set a write breakpoint on $2006, with the value field set to $FF and if it triggers, then that one is correct). Once you know which ones need fixing, it'll be a lot easier to walk you through the how, using one of the actual games as an example.

My mistake, I should have said non-bsnes patches instead of pre-amplified files. To my knowledge, they're are no pre-amplified pcm's. Just the music packs (pcm's) that go with them. For example, your DX patch has one music pack or Chrono Trigger has one music pack. What I meant was that with the bsnes patches applied to the roms (puts the music register to $60 in hex) that with the sd2snes at 0db boost (aka no boost) the music is too low and the spc's too loud.

The problems I was writing about above were occurring because this meant that the volume cnofiguration in the sd2snes menu had to be boosted to match bsnes or even sound about eqaul with the spc's. This resulted in the problems above, which seem to me like clipping or distortion. So what I did was look for the old patches Conn had that set the music register to $FF (his F-Zero and LOZ compatibility IPS's weren't working for me, and the BS Zelda one's remove features) or change if $FF in hex myself as I did in the case of F-Zero.

If you read the thread I linked to over at krikzz's forum other people were writing that this new revision board G makes the MSU-1 louder because the DAC is running at 5V instead of 3.5V. So if you combine a louder MSU-1 because of higher voltage and the db boost in the sd2snes menu, what results is music that is: a. too loud and b.sounds bad on my end and I don't even have the DAC running at a higher voltage, just the db boost is causing issues.

I'm confused qwertymodo, are you saying that $FF should be what is written to the MSU-1 register at $2006? Because $60 is what it is set at for most bsnes patches (and Conn's updated patches) and this results in the db boost in sd2snes. I thought you were advocating boosting around 10db or 12db? If you are boosting and have MSU-1 set to $FF I imagine that would be much too loud.

I'm also confused by your first post Kakashi. You want to patches and music to be corrected in the same fashion as bsnes. Wouldn't this mean changing all writes to $60 or $66, and not $FF? For example, check Conn's F-Zero patch that has been updated to play at the same volume in both bsnes and sd2snes (with the 12db boost as Conn writes in the readme). Check 0x014272 in hex and you will see the volume set to $60. Here's is what Conn used to have written in the readme under the bsnes patch:

Conn wrote:Optional adjustment (decrease volume, bsnes/higan):
If the audio volume is too loud in bsnes or higan, apply the dec_vol_bsnes.ips. You can also adjust it manually by opening the rom in a hex editor and change at pc address at
0x0014272: FF -> 60 (00= mute, FF max volume, 60 is maybe the best value)

The issue is that there are two ways to get the same volume, either record the track louder or turn up the "volume knob". The problem initially was that the sd2snes "volume knob" only went up to 6 out of 10, so the only solution was to record the tracks way loude. The only problem with that is that the "volume knob" in higan/bsnes went all the way up to 10 like it was supposed to. Now the sd2snes can go up to 10, but some patches already recorded their tracks at the loud level and decided it was easier to just go into the code and set the volume knob to 6, because now the sd2snes and higan matched, so it didn't really matter, EXCEPT that recording tracks at the high volume often introduced clipping so the real solution is quieter tracks with the volume all the way up to 10, which is what we're talking about here. Unfortunately, this won't fix tracks that are already clipped, but for hacks like PW or Conker, where I'm working off of the original, unclipped files, I'm able to normalize them properly without introducing any clipping.

However, it's also possible that some of the tracks you're experiencing poor sound on were just low-quality recordings in the first place. You have to understand that these new pcm tracks are almost always sourced from several different places, since it's rare to find a single source that has created high quality reproductions of entire soundtracks. Even A Link Between Worlds only includes about 80% of the original A Link to the Past OST tracks. Sometimes a good version of a track doesn't exist and you have to settle for something mediocre.

So, my project involves a cover-all solution for the pcm files in which we normalize to a certain level and then fix the patch sources' volume adjustments.
I have sources for everything except the BSZelda projects, which Conn will have to fix himself.

Kakashi wrote:which Conn will have to fix himself.

Not gonna happen unless he already has the separate patches made. I got lucky on Conker and he had one, but other than that I know he's not going to go revisit his code. I can help if it comes to that, but I really need to get PW v1.2 done :/

qwertymodo wrote:The issue is that there are two ways to get the same volume, either record the track louder or turn up the "volume knob". The problem initially was that the sd2snes "volume knob" only went up to 6 out of 10, so the only solution was to record the tracks way loude. The only problem with that is that the "volume knob" in higan/bsnes went all the way up to 10 like it was supposed to. Now the sd2snes can go up to 10, but some patches already recorded their tracks at the loud level and decided it was easier to just go into the code and set the volume knob to 6, because now the sd2snes and higan matched, so it didn't really matter, EXCEPT that recording tracks at the high volume often introduced clipping so the real solution is quieter tracks with the volume all the way up to 10, which is what we're talking about here. Unfortunately, this won't fix tracks that are already clipped, but for hacks like PW or Conker, where I'm working off of the original, unclipped files, I'm able to normalize them properly without introducing any clipping.

However, it's also possible that some of the tracks you're experiencing poor sound on were just low-quality recordings in the first place. You have to understand that these new pcm tracks are almost always sourced from several different places, since it's rare to find a single source that has created high quality reproductions of entire soundtracks. Even A Link Between Worlds only includes about 80% of the original A Link to the Past OST tracks. Sometimes a good version of a track doesn't exist and you have to settle for something mediocre.

I see what you're saying qwertymodo about some of the tracks not being sourced from lossless sources, but the game I'm having the worst clipping/bad sound from (apart from the very strange F-Zero spc effects from boosting) is Chrono Trigger, which is sourced directly from the FLAC files. At +6dB it's noticeably bad on some tracks, but at +3.5dB it's not too bad. I will try to record some of this to let you guys here.

Just to make it clear, when you say we should have quieter tracks with the MSU-1 volume set to 10, are you saying that this requires dB boosting in the sd2snes configuration or no boosting (0 dB)? Because the revision board G switch from 3.3V to 5V for the DAC is supposed to bring sd2snes volume up to bsnes/higan's level.

So that would mean the best option would be: have quieter pcm's, no dB boosting in sd2snes (0 dB), and 5V for the DAC on the sd2snes board (which is a simple soldering job as seen in this thread :Krikzz's forum This is what ikari himself recommends in the quote below.

Just like we don't boost MSU-1 tracks in bsnes, tracks on the sd2snes shouldn't need boosting either if the DAC is getting 5V. Here's is what ikari had to say over at Snesdev,

ikari wrote:"About volume - the sd2snes audio output is rather quiet when compared to bsnes which mixes in MSU audio at full level. It is probably an oversight on my part. A possible hardware mod would be to run the DAC at 5V instead of 3.3V. I recommend normalizing all audio files to 0dB for use with sd2snes, ideally after decompression to avoid clipping in case they are to be shipped in a lossy compression format. That is the most you can get out of the sd2snes without the help of a soldering iron".

He also said over at krikzz's forum,

ikari wrote:"With the mod the volume should be closer to higan (MSU/S-DSP volume equality at full amplitude)."

Sorry if it seems I'm being a pain everyone. Just want to make sure that the MSU-1 doesn't head towards the wrong path in the future and all patches are like Conn's recent BS Zelda patches and need dB boosting (which I'm having sound quality problems with).

So, my project involves a cover-all solution for the pcm files in which we normalize to a certain level and then fix the patch sources' volume adjustments.

My bad Kakashi, I didn't know lowering the pcm's were part of your solution. Now it makes more sense that you would be tweaking all patches to be at $FF then.

I've been thinking it would really be nice to have a devoted MSU-1 site or forum site. The MSU-1 folk are way too scattered about. There's this forum, byuu's, snesdev forum, bszelda forum, etc. I've been reading up on how to insert MSU-1 and it would be so much easier if all the information was contained in one spot. It would be great to have people like DarkShock, Conn, ikari, byuu, and others all on the same page on the same site.

By the way, thanks qwertymodo for the ASM you did based off of Conn's work on Zelda. Studying it has been helping me a lot to learn how to code for MSU-1.

There might be two MSU-1 projects you guys aren't aware of. One is a near complete MSU-1 project for Final Fantasy VI (currently in Open Beta at this site).
The other is an extensive romhack of Super Mario World called Yoshi's Strange Quest. This one is a little different when it comes to MSU-1. Instead of using MSU-1 for songs, he did for the sound effects and gave Yoshi little speaking parts where he says "Yoshi!" and whatnot. The music in the game is different however, but it uses new SPCs. Yoshi's Strange Quest (v1.3.1 Beta 4.5).

By the way, does anyone have a copy of Colines homebrew MSU-1 game (the link is no longer working)?

In addition to the +5V mod, rev H (I think) of the SD2SNES also includes a unity-gain op-amp on the output of the DAC to fix the impedance mismatch, which could also be part of the problem of poor audio quality.

As for the current situation with rev F and earlier, the "Right Way" to do this is to have your PCM's normalized to ~-20dBFS RMS (though it may vary slightly from game to game, depending on how loud the native soundtrack and SFX are, I came to settle on -20dB based on LoZ3), and have the game code set $2006 (the "volume knob") to $FF for full volume (aka "10" in my simplified analogy, it's actually 255), then on the SD2SNES, you should be enabling the boost to +12.5dBFS or whatever one step below that is, I think it's +10.5dBFS or something like that.  In rev H going forward, the only difference is that you WON'T have to enable any boost in the SD2SNES firmware, it will just natively output at the correct volume level.

This may seem complicated, but really it's just a matter of cleaning up the mess created by the incorrect volume in the first place.  Now that it's fixed, moving forward, authors should just use that normalization level and volume value, and to the end user, all you should have to know is that if you have an older SD2SNES, turn on the boost and you're done, if you have a new one, you don't have to do anything special at all, just load the game and play.

By the way, thanks qwertymodo for the ASM you did based off of Conn's work on Zelda. Studying it has been helping me a lot to learn how to code for MSU-1.

If you want to actually learn what you're doing, that code on github is pretty hard to read. I actually did a complete, from-scratch rewrite of my own that should be much easier to understand if you're still trying to learn how it works. I'll eventually get it committed, but here it is: http://pastebin.com/raw/DyH41gAv

Ahh, thanks for the clarification. Yeah in your earlier post when you said "volume knob to 10", I wasn't sure if you meant volume at $2006 or sd2snes boosting. Now I know which.

qwertymodo wrote:I think it's +10.5dBFS or something like that

Actually it's +9.5dB (Goes 0, +3.5, +6, +9,5, +12). Also I'm pretty sure it's still at Revision G.

qwertymodo wrote:
"As for the current situation with rev F and earlier.....you should be enabling the boost to +12.5dBFS or whatever one step below that is"

Another option is to just to solder a simple connection, which will effectively give the DAC 5V like the Revision G board. Here are some pics from krikzz's forum.





Dreimer, who made the DKC2 music pack and Secret of Mana alternative music pack said this in the thread,

dreimer wrote:"I use the boost feature @minimal, but the sound becomes distorted by that in my case"

So it seems I'm not the only one experiencing these issues. Kind of a bummer that people who don't want to upgrade their board (either by buying a new one or soldering connections) are stuck with dB boosting. Oh well. Everyone's readmes will probably need to be updated to instruct those with a Revision G board not to boost. Kakashi, once you're done with your project you should get in touch with all of the authors and see if they will update their patches so there can be one standard from here on.

suFami wrote:Dreimer, who made the DKC2 music pack and Secret of Mana alternative music pack said this in the thread,

dreimer wrote:"I use the boost feature @minimal, but the sound becomes distorted by that in my case"

So it seems I'm not the only one experiencing these issues. Kind of a bummer that people who don't want to upgrade their board (either by buying a new one or soldering connections) are stuck with dB boosting. Oh well. Everyone's readmes will probably need to be updated to instruct those with a Revision G board not to boost. Kakashi, once you're done with your project you should get in touch with all of the authors and see if they will update their patches so there can be one standard from here on.

dB boosting only sounds bad on PCM tracks that were recorded too loud to begin with, because they've already removed all of the headroom, and boosting the volume further just kills it.  That's why I keep making a big deal about correcting this.  If the track packs were normalized to -20dBFS RMS, there would be a ton of headroom, and you wouldn't have this issue.  That's why I'm pushing everyone to fix this The Right Way instead of continuing to let the old volume hack keep hanging around to bite us.

qwertymodo wrote:I actually did a complete, from-scratch rewrite of my own that should be much easier to understand if you're still trying to learn how it works.

Thanks for this, I'll take a look.

Using advice Conn gave in a thread about using snes9x debugber and the trace function, I was able to find the music register where Lupin the III, Dragon Quest I+II, and Dragon Quest III read the track # to play.
I wanted to try adding MSU-1 to Lupin the III just as a sample exercise to see if I could write the code and inject into the rom. For Lupin I just wanted to change one song, the SPC-version of the theme song that plays at intro screen (replace it with the actual theme song). I wrote up code based on ASM from Conn, DarkShock, and the Zelda ASM you posted. However, no matter how many times I rewrote it I couldn't get it to work. I had trouble using bass, and xkas kept bugging the games so I even tried inputting the code straight into hex like Conn and that still didn't work. Granted this was all before I owned a sd2snes and was just testing on bsnes.

For the Dragon Quest games I wanted to replace all the tracks with orchestrated versions that were conducted by the composer himself. Dragon Quest III (my personal vote for best DQ music in the series) for instance has a terrific Symphonic Suite album that was recorded with the London Philharmonic back in 1996 for the release of the SNES remake.
I lost motivation to work on Dragon Quest when I realized I couldn't distribute a music pack because it's copyrighted material.

qwertymodo wrote:
dB boosting only sounds bad on PCM tracks that were recorded too loud to begin with, because they've already removed all of the headroom, and boosting the volume further just kills it.  That's why I keep making a big deal about correcting this.  If the track packs were normalized to -20dBFS RMS, there would be a ton of headroom, and you wouldn't have this issue.  That's why I'm pushing everyone to fix this The Right Way instead of continuing to let the old volume hack keep hanging around to bite us.

Hmmm, you're right, boosting probably would sound better if the pcm's were lowered. I wonder what the deal is with Chrono Trigger though. Maybe DarkShock's bat files increases the volume or something. Those are from FLAC files so they shouldn't be having these issues unless they are mixed too loud in the pcm conversion phase. I need to take a look at his bat files.

Ok, so Kakashi, I promised more info, so here it is.  I'll try to be as thorough and simple as possible, so bear with me if you already know some of this.

The code you're interested centers around writes to address $2006.  This is the MSU-1 volume control.  It's an 8-bit register, so it can accept values from $00 to $FF, with $00 being muted and $FF being full volume.  Hacks that use the full $FF volume range are already correct, and don't need to be changed, so the first thing you should do is check if the game does that.  It's really simple, load the game in bsnes-plus and set a write breakpoint on $2006 with a data value $FF, then reset the game (since by the time you get the breakpoint set, the game has probably already started playing audio).  The breakpoint window is opened via Tools>Debugger, then Tools (in the debugger window)>Breakpoint Editor, and your settings should look like this:



One thing to note is that bsnes-plus uses the SD2SNES naming format instead of the higan format, so you need romname.sfc, romname.msu (even if it's just a blank file, it needs to exist), and romname-1.pcm, romname-n.pcm, etc.  Now, assuming you've loaded the game correctly and it actually loads the MSU-1 audio instead of falling back to SPC, you should hit this breakpoint almost immediately.  If you do, the game is good, check it off and move on to the next one.

If you don't hit that breakpoint, that doesn't automatically mean you need to fix the game, but it's pretty likely, especially if the music is playing at what you would expect to be "full volume" (i.e. it's not fading in or "ducked", it's just playing the song).  To check this, delete the Data field in the breakpoint editor and reset the game.  You should hit the breakpoint this time, and it will tell you what value is being written.  In this example, it's writing $FF.  Also, note that in this case, the instruction is sta $2006 (store the value in the a register to address $2006), if the instruction was stx $2006, you'd want to look at the value of the x register instead, same for sty $2006 and the y register.



Now, it's possible that the first breakpoint you hit might be initializing the register to $00, or possibly fading in, so you might have to hit run a few times to see where the value settles.  If the final value ends up somewhere around half volume (technically half would be $7F, but Conn used $60, and technically it could be anything), then you have some work on your hands.  Your first order of business is to play the game with the breakpoint set (without anything in the Data field) in order to log all of the code addresses where the game writes to $2006.  Then, you need to backtrace those addresses (or just open up the game in a disassembler at those addresses and step backwards) to find where the value is loaded from.  In many cases, it might be very simple, for example:

Code:

lda #$60
sta $2006

Well, that's pretty obvious, it's loading the literal value #$60 and storing it.  All you need to do here is replace #$60 with #$FF and you're good to go.  Now, if we assume that the hack is using $60 to represent "full volume", and elsewhere you see

Code:

lda #$30
sta $2006

you can assume that the game is setting the volume to half, such as the case with walking indoors in LoZ3.  In this case, you'd change #$30 to #$7F.

Now, that takes care of the basics, but the other case you need to deal with is fade in/out, which is a bit less straightforward.  The way this is typically done is by incrementing/decrementing the volume register within the NMI routine.  If you double the volume range, now your fades take twice as long to reach the target volume.  So, you probably need to fix that.  In this case, it might or might not be as simple as just overwriting a constant value.  If the code does something like this (from my LoZ3 code):

Code:

   lda {REG_CURRENT_VOLUME} // scratchpad variable
    cmp {REG_TARGET_VOLUME} // scratchpad variable
    bne +
    jml spc_skip
+;  bcc +
    sbc #$02
    bcs ++
    stz {REG_CURRENT_VOLUME}
    stz {REG_MSU_CONTROL}
    stz {REG_MUSIC_CONTROL}
    stz {REG_CURRENT_TRACK}
    stz {REG_CURRENT_COMMAND}
    stz {REG_CURRENT_MSU_TRACK}
    bra ++
+;  adc #$02
    bcc +
    lda {VAL_VOLUME_FULL}
+;  sta {REG_CURRENT_VOLUME}
    sta {REG_MSU_VOLUME}
    jml spc_continue

See those sbc and adc instructions?  That's where I'm incrementing/decrementing.  You can just adjust those values accordingly (i.e. probably just double them).  However, it's possible that the code uses inc and dec instructions instead, in which case, you'll need to add more of them (in which case, be sure to check that the additional instructions aren't overwriting anything), or replace the inc/dec with adc/sbc.

The main difficulty here is that there are probably several places in the ROM that you need to make the same changes.  Conn's patches, for instance, tend to contain quite a lot of redundant code, and I think Conker had 20+ instances that needed to be changed.  Thankfully, he already had the patch made, so I didn't have to track them all down myself.  If you happen to have the source code, that can help immensely, or else another way I would suggest if all you have is an IPS would be to make a binary diff between the unpatched and patched ROMs in order to isolate the new code (yeah, I know, an IPS is technically already a binary diff, but I find it's easier to apply the patch and use a hex editor to do the diff rather than trying to parse the IPS file), and disassemble that, which would then give you the code which you can modify.

If you have any other questions, feel free to ask.

suFami wrote:

qwertymodo wrote:
dB boosting only sounds bad on PCM tracks that were recorded too loud to begin with, because they've already removed all of the headroom, and boosting the volume further just kills it.  That's why I keep making a big deal about correcting this.  If the track packs were normalized to -20dBFS RMS, there would be a ton of headroom, and you wouldn't have this issue.  That's why I'm pushing everyone to fix this The Right Way instead of continuing to let the old volume hack keep hanging around to bite us.

Hmmm, you're right, boosting probably would sound better if the pcm's were lowered. I wonder what the deal is with Chrono Trigger though. Maybe DarkShock's bat files increases the volume or something. Those are from FLAC files so they shouldn't be having these issues unless they are mixed too loud in the pcm conversion phase. I need to take a look at his bat files.

See edit_audio.bat:

sox chrono_1_01_raw.wav -b 16 chrono_1_01.wav trim 1100160s gain -n -1 silence 1 .01 1% rate 44100 dither -s

I'd have to check the manual, but I'm pretty sure gain -n -1 is the same as -norm=-1, which is normalizing the track to -1dBFS peak, which is almost no headroom for boosting.

Edit: Oddly, his asm is using $FF for the max volume, so I don't know why he's normalizing the tracks so loudly.

https://github.com/mlarouche/ChronoTrigger-MSU1/blob/master/chrono_msu1_music.asm#L36

Yeah, I just tested out Chrono Trigger, and the PCM's are just way too loud. I'm not surprised it sounds like garbage with boost enabled, it almost sounds like garbage just as-is. I almost have a fixed script for generating the PCM's at the correct levels directly from the original FLAC source.

qwertymodo wrote:

suFami wrote:

qwertymodo wrote:
dB boosting only sounds bad on PCM tracks that were recorded too loud to begin with, because they've already removed all of the headroom, and boosting the volume further just kills it.  That's why I keep making a big deal about correcting this.  If the track packs were normalized to -20dBFS RMS, there would be a ton of headroom, and you wouldn't have this issue.  That's why I'm pushing everyone to fix this The Right Way instead of continuing to let the old volume hack keep hanging around to bite us.

Hmmm, you're right, boosting probably would sound better if the pcm's were lowered. I wonder what the deal is with Chrono Trigger though. Maybe DarkShock's bat files increases the volume or something. Those are from FLAC files so they shouldn't be having these issues unless they are mixed too loud in the pcm conversion phase. I need to take a look at his bat files.

See edit_audio.bat:

sox chrono_1_01_raw.wav -b 16 chrono_1_01.wav trim 1100160s gain -n -1 silence 1 .01 1% rate 44100 dither -s

I'd have to check the manual, but I'm pretty sure gain -n -1 is the same as -norm=-1, which is normalizing the track to -1dBFS peak, which is almost no headroom for boosting.

Edit: Oddly, his asm is using $FF for the max volume, so I don't know why he's normalizing the tracks so loudly.

https://github.com/mlarouche/ChronoTrigger-MSU1/blob/master/chrono_msu1_music.asm#L36

I did the Chrono Trigger patch before the MSU-1 volume option was available on the SD2SNES, the song wasn't loud enough on a real SNES

That makes sense. If you're interested, I could send you my script with the updated volume levels, as well as a few minor fixes, like a better loop point on the final battle track.

I'd also like a copy of those scripts, please!

Also, thank you very much for the tutorial. It was very thorough.

Right now I only want to give them to people willing to test and report back, but I'll eventually post it publicly (and DS is absolutely free to use and release it if he wants). The script itself is up on byuu's board, and the config was generated from DS's script and then some manual changes were made to a few songs (mostly just early game tracks, I don't have any saves to test later stuff). So yeah, I'll send it your way when I get the chance

I was actually thinking about it and DS's pcm's actually aren't that loud that compared to almost every other music pack, that's why I am boosting them to +3.5dB in the first place. Taking into account that DS has the $2006 register at $FF and that these pcm's were made for the sd2snes before boosting was an option, they shouldn't need boosting. Maybe I'm just being picky or CT just has really loud SPC effects though. All of the other music packs I've been playing at 0dB (with $2006 at $FF). Some of those packs don't clip as bad or at all when boosted, so maybe it's a pack by pack basis or something. I was playing CT at +6dB for a while until I noticed only particular songs sounding odd (there was one in the 2300 AD Proto Dome area in particular that was bad).

Actually if the DAC getting 5V on the new Revision G board is supposed to bring the sound (at the base 0dB) to BSNES levels then that would mean all of the music packs at $FF would be too loud. Because that would be like the equivalent of being +12dB (since people are saying boosting an old board to +12dB brings it to BSNES levels which is why Conn's new patches recommend that and so he brought the $2006 register down to $60).
So if you boosted a Revision G board to +12dB, then theoretically that would be around +24dB boosted from what the Revision F is at 0dB. So yeah the pcm's in all packs will need to be made softer.

Dreimer posted on krikzz's board that his revision G board is louder so he keeps it at 0dB (or the equivalent of an old board at +12dB). He also said, "I am close to say that DKC2 MSU1 is a bit too loud I put quite some effort in getting it as loud as possible when I made it." This would be because it's an $FF rom with music mixed for the older revision boards being boosted +12dB not from the menu, but from the DAC 5V mod.

I'm still on a Revision F, since I'm waiting on a game bit thing to come in the mail so I can open the cartridge and solder to the DAC to see how much a difference revision G is going to be.

Ok, just to clarify, all of the following should be roughly equivalent in terms of volume, and should be considered "correct" volume-wise:

higan (all versions, but if you're going to do side-by-side listening tests with MSU-1 vs SPC you'll want >= v100)
bsnes-plus (all versions, but side-by-side tests should be done with higan >= v100 instead)
SD2SNES rev. >= G with 0 boost
SD2SNES rev. <= F with op-amp mod and 0 boost
SD2SNES rev. <= F with firmware >= 0.1.7b @ +12dBFS boost
*SD2SNES rev. <= F with +5V mod (*this one's iffy, I tried it and couldn't get it to work on a rev. E1, really if you're going to bust out the soldering iron, just install the op amp instead, it's not that much more work).

Track pack authors should use one of these options, along with using $2006=$FF when mastering/normalizing their audio tracks.  Using anything else will continue to cause problems.  End users should also be using one of these options.  Suggesting any other boost value will only continue to perpetuate the issue.  If you need a different boost level, the track pack author needs to fix their track pack (which is exactly what Kakashi is doing here, and I'm glad that he is).

My work is going to be on hold until I am able to fix a hard disk.