Audio distortion in PCM files

[edale2]

I'm playing this on a Raspberry Pi 3b with RetroPie, using the lr-snes9x emulator core (it's the more current version of snes9x that has MSU-1 support).

I've been using the higan setting in the installer, and renaming the files to match SNES9x's standards (same as SD2SNES) because with MSU-1 mods that have both a "for emulators" and a "for SD2SNES" ips file, SNES9x (at least the version ported to RetroPie) needs the "for emulators" ips to not have sound problems.

While playtesting the mod (I've downloaded and tested all of the music options available) I noticed a fair amount of crackling on the louder parts, I figured this was because of the platform I'm playing it on atm, and didn't give it much thought,

However, I am currently going through all of the PCM files comparing each track, and picking the ones I prefer for a custom setup, and I noticed a problem.

I'm loading the PCM audio in Audacity to listen to it with the following settings:

Encoding: signed 16-bit PCM Byte order: Little-endian Channels: 2 channel (stereo) Sample rate: 44100 Hz (please tell me if any of these settings are wrong, because that could be the source of the problem, sounds perfect except for the mentioned distortion)

And on a lot of the tracks, even on my computer (which is not a cheap one, high-end gaming PC), I'm hearing a decent amount of cracking on the louder parts, and it's obvious looking at the sound graph in audacity that parts of the louder parts have an amplitude that goes outside the scan range (not sure the proper term) of what can be played back clearly.

I've run across similar audio distortion before when editing some music files (thankfully I had batch files that I only needed to adjust a few variables in, no clue how to do that normally), and it's a relatively simple problem to fix.

What you need to do is basically re-encoding the PCM audio from the source audio while applying a 10-15% reduction in volume to the resulting PCM files (across the board, because I'm hearing it in almost every track), This should clear up most, if not all, of the crackling audio distortion.

[edale2]

In this screenshot, which of track 5 from the OCR remix, you can see several points where the audio clearly goes outside the scan range, to provide an example of what I'm talking about.

I don't know if your installer is downloading PCM audio directly, or downloading the FLAC/WAV/etc. files and converting them, but if it's converting them on my PC, then there should be a setting I can change in one of the scripts to accomplish this, but I wouldn't know where to look for that setting... (no real programming experience, other than a firm grasp on the logic involved, and I've only needed to do this type of audio editing before by modifying a .BAT file that used sox)

[Dizzy611]

Interesting. Is the issue only present in the OCRemix tracks? I was not personally involved in trimming and looping those, is why I ask. I know clipping is an issue in the source tracks in some of the FFT PCMs due partially to them only having been released as slightly low quality MP3s. The installer downloads PCM audio directly with preset trimming and loop points, and this is how I have the files stored, this is due to some serious audio editing that was necessary to get some of the tracks, especially the OCRemix tracks, looping properly.

If the issue is mostly contained to the OCRemix tracks I will have to get Covarr (the person who did most of the OCRemix work) to take a look at them. If I can not, I will have to attempt to reduce the amplitude of the PCMs themselves as raw files in audacity, preserving the loop point and re-adding it to the header, as working with the raw files myself I am not sure I would be able to make the same edits Covarr did (we did not document the process particularly well I'm afraid)

It's somewhat notable that I did not notice any similar issues myself when testing the hack on Higan.

[edale2]

It's not in every PMC, but it is in most of them, across all 4 filesets, even the OST. Though I'll mention in theOCR it's harder to notice the crackling, because the distortion that's supposed to be a part of those songs frequently covers it up.

Honestly, I just used that particular track because I was on track 5 in sorting through them, and I would have chosen OCR for track 5 if the distortion wasn't as bad as it is, ended up going with the SSC track instead.

Do you know which track number plays in Narshe Cave when you first enter it after Figaro Castle buries itself in the sand about an hour into the game? The crackling was particularly bad on that track in-game, but haven't had a chance to see the PCM to see if the problem is there or not.

I'll try a bit in higan and see if I notice the crackling on there.

[edale2]

Using higan v1.02, can't get the MSU-1 sound to load no matter what I do, what version are you using?

I'm gonna try and grab .0.97 from somewhere and try on that.

[edale2]

Yea, i'm an idiot. I was naming it "msu.rom"instead of "msu1.rom".

The crackling is happening in higan as well. It's possible the crackling is just outside your range of hearing, I do have really sensitive ears (I can hear dog whistles...), but all signs point to the problem being the PCM files themselves.

[edale2]

Not being able to edit these posts is kinda annoying, sorry for so many posts in a row.

I have no clue how the looping and such works, so I wouldn't be able to edit the files in audacity and then reencode to the proper PCM format, but if you want to try it to a track or two and post a download link, I'll check them out and see if the problem is fixed.

OCR track 5 (because I really would like that one in the custom setup I'm making) and FFT track 2 would be good ones to test on from the small chunk I've gotten through so far.

---

I went ahead and got as far as I could go, which was basically only finding out the amplification setting needed.

After a lot of testing, the sweet spot for both files turned out to be an amplification setting of -7.5.

At -7, even though all of the data looked back in the scan range there was still a good deal of crackling (though a good deal less than the original audio).

At -7.5 around 90% of the crackling disappeared, and the small bit that remained was much quieter and easier to ignore.

Any higher (lower?) than that and the decrease in crackling is negligible, and not worth the decrease in volume.

I'd wager the -7.5db amplification (deamplification?) is gonna be the sweet spot for pretty much all the tracks.

I don't suppose you know a way to craft a batch process to apply that -7.5db amplification to a whole mess of PCM files, while preserving its loop (and header?) data? I'm gonna see if I can find a sox thread somewhere and ask there, I'd be surprised of sox couldn't do it, seems to be able to do just about anything with any type of audio file. Too bad it's command-line only

[Dizzy611]

It's been a while since I worked directly with the .pcm files so I'll have to refresh my mind on how they're constructed but iirc it's just a matter of a tiny (like 4 bytes or something?) header with the point where the loop starts listed by sample number. It'd likely be possible to seperate this header from the rest of the file, run it through Sox as raw pcm audio, then reattach the header afterwards and preserve the data that way, as changing amplification shouldn't affect the timing whatsoever. I'll look into this some time in the next few weeks when I have time.

On Oct 2, 2017 9:49 PM, "edale2" notifications@github.com wrote:

Not being able to edit these posts is kinda annoying, sorry for so many posts in a row.

I have no clue how the looping and such works, so I wouldn't be able to edit the files in audacity and then reencode to the proper PCM format, but if you want to try it to a track or two and post a download link, I'll check them out and see if the problem is fixed.

OCR track 5 (because I really would like that one in the custom setup I'm making) and FFT track 2 would be good ones to test on from the small chunk I've gotten through so far.

I went ahead and got as far as I could go, which was basically only finding out the amplification setting needed.

After a lot of testing, the sweet spot for both files turned out to be an amplification setting of -7.5.

At -7, even though all of the data looked back in the scan range there was still a good deal of crackling (though a good deal less than the original audio).

At -7.5 around 90% of the crackling disappeared, and the small bit that remained was much quieter and easier to ignore.

Any higher (lower?) than that and the decrease in crackling is negligible, and not worth the decrease in volume.

I'd wager the -7.5db amplification (deamplification?) is gonna be the sweet spot for pretty much all the tracks.

I don't suppose you know a way to craft a batch process to apply that -7.5db amplification to a whole mess of PCM files, while preserving its loop (and header?) data? I'm gonna see if I can find a sox thread somewhere and ask there, I'd be surprised of sox couldn't do it, seems to be able to do just about anything with any type of audio file. Too bad it's command-line only

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Insidious611/DancingMadFF6/issues/10#issuecomment-333715789, or mute the thread https://github.com/notifications/unsubscribe-auth/AASag-XGdLKiZwM-fsBLqark8Jw_Pzolks5soZKegaJpZM4PqYoQ .

[edale2]

I posted a question over on stacked overflow: https://stackoverflow.com/questions/46536351/batch-amplification-of-pcm-audio-using-sox

So hopefully I'll get a quick and easy way to do it before too long.

[edale2]

Managed to track down the formatting of the PCM audio for MSU-1 tracks:

The audio tracks are 44.1 kilohertz, 16-bit stereo uncompressed unsigned PCM files in little-endian order, left channel first, with a simple eight-byte header. The first four bytes spell out “MSU1” in ASCII. This is followed by a 32-bit unsigned integer used as the loop point, measured in samples (a sample being four bytes) – if the repeat bit is set in the audio state register, this value is used to determine where to seek the audio track

From http://helmet.kafuka.org/msu1.htm

Should help get things fixed.

[edale2]

"Please fix me" lol.

OCR track 8. Sadly it's the only version that's not the OST.

It does look like OCR does have some of the worst cases of the problem, but as I said before, it's not the only one, With track 7 (shadow's theme) the OST had the worst case of the 4.

[edale2]

spent the last few hours doing everything I can think of to try and convert just one of these files.

I'm a novice with sox, but every time it makes even the tiniest change to the audio, the audio completely breaks.

I tried exporting the adjusted audio in audacity... it doesn't support 16-bit unsigned PCM, only 8-bit unsigned PCM, so I exported as signed, then used a hexeditor to write in the first 8 bytes of the new track with the first 8 bits from the old track.

Won't load in the emulator, defaults to the built-in audio.

Tried using sox to convert from signed to unsigned, no other changes... broke the audio...

I... don't know any programs that can handle 16-bit unsigned PCM audio......

[edale2]

Would you believe the fixed copy of the file I uploaded to test...Yea, I uploaded a copy that hadn't had the header data restored...

So yea, 16-bit signed PCM audio works, And it takes a few minutes per track, but I can adjust the audio levels easily enough now. no way to do it as a batch though, and I don't know how to test if the looping still works, the track I did this to to test isn't a looping one...

[edale2]

OK, tested on a different track, looping is preserved,

[edale2]

I've figured out my problems with sox, the audio was actually 16-bit Signed PSM, not unsigned.

Sox command to deamplify the PCM tracks:

sox -t raw -e signed -b 16 -r 44100 -c 2 -L [filename].pcm -t raw -L [filename].raw vol -7.5dB

And with that, I was able to edit the example batch command included with sox to convert all the PCM tracks. the bat is a drag-and-drop bat command, so you take the PCM files, and drag them onto the .bat command, and it'll take care of the rest. Obviously, you need sox for it t work.

batch-deamplifyPCM.zip

I'll still need to hex-edit the header data back in manually though,

[Dizzy611]

Thanks for all your work on this. I think with this as a basis I should be able to whip up a python script that'll pull the header data from the existing PCMs, back them up, edit them, then put the header back on the edited file. I'll have to try it myself and test the results, but this looks really promising.

Some of these tracks are unfortunately kind of pushed to the edge as far as amplification just from the source file, I don't think much was done to amplify or deamplify them when we were first editing this stuff for the early alphas. The OST is pulled from CDs and the OCRemix tracks are made in a similar style to commercial releases and it's a common thing for many years for commercial CD releases to be as "loud" as possible, to the detriment of the music on them sometimes.

That said, I'm thinking in case some people prefer the old volume I might provide deamplification as an option in the installer rather than making it standard. I need to rewrite the installer a bit in order to provide people the ability to choose a template and then modify it, in any case, so this is just another reason to do that :P

[edale2]

I was looking around for a hex editor that could copy/paste the header data from the original files to the new ones, so I wouldn't have to manually edit the header data in and do the entire process through 2 quick batch processes.

Sadly the only batch hex editor I could find (named Batch Hex Editor, lol) can't do this. I had to email their tech support dept to ask if it was possible, after describing what I needed done. They said they could program a custom script to do it by Friday for $200, lol. Though I do have to admit, if I was a business looking to do something like this, it would actually be a good deal.

Oh, once, I'm done going through all the files, I found a video on using Audacity to make MSU-1 PCM files, including looping and everything. I'm gonna try my hand at converting The Black Mages' version of The Decisive Battle, it's even better than the OCR one (sadly they've only done 4 FFVI tracks, and one is a fully vocalized Opera, if you check them out, be sure to look up their version of Matoya's Cave, it's amazing when you consider how short the in-game version is in FF1). I'll be sure to share it with you if I succeed. I'll make both a normal and a deamplified one, I already have the FLAC file. Give you another song for the OTH folder. ;)

I just realized I've put in something like 8 hours playtesting, and 30ish hours sorting through music and working on fixing the audio problem I found... Just so I can have a better experience when replaying the game for the 200th or so time, and to help others have a better experience when playing it as well... Can you tell I'm passionate about this game? lol.

Oh, be sure you use different filenames for the input and output in sox (that's why I output to .raw rather than .pcm in the script, the batch actually can, and does, use the same name, because it saves the new file in a subfolder).

And I figure it's be easier to script "copy the first 8 bytes of data from file.pcm and paste it over the first 8 bytes of file.raw" than if the filename itself was different.

[edale2]

Oh, and i'm not done going through the audio files yet, but so far there are a few tracks that don't need -7.5dB amplification:

SSC track 29 - amplification of -4dB needed OTH track 34 - no deamplification needed, the only thing needing fixing is the extra track data I posted about. FFT track 46 - amplification of -6.5dB needed SSC track 46 - amplification of -4dB needed OCR track 47 - amplification of -8dB needed - sounds like it's from FFXIII-3: Lightning Returns, lol. SSC track 50 - amplification of -6dB needed OCR track 62 - amplification of -5dB needed OCR track 78 - amplification of -4dB needed - EPIC OST track 82 - amplification of -5dB needed OST track 83 - amplification of -6.5dB needed (Why does OCR 83 have the ending theme for FFXII for the last 3 minutes? granted the basic theme of the music fits, but it's a straight ripoff of FFXII's music) OST track 101 - amplification of -6.5dB needed OST track 102 - amplification of -6.5dB needed OST track 103 - amplification of -6dB needed

I'll post any more exceptions as I come across them.

Oh, and I can update my posts now for some reason, maybe I just didn't see the icon before...

[Dizzy611]

Not closing this yet as I've not run the script on all my files nor tested them ingame yet, but as you can see in the commit above, I've made a script that will automatically create directories full of deamplified PCMs for each directory of tracks. It even takes into account the exceptions listed above. :)

Also, completely unrelatedly, I just re-read the first post and realized you're running this on a raspberry pi. That is awesome, I didn't even know you could do that! Use MSU-1 audio on a pi at all, I mean (well, unless you were to use higan which would run terribly). I use one as an emulation box myself, I will have to try that out.

[edale2]

I don't know if it's in the "official" release just yet (I think it is), but there is now MSU-1 support in SNES9x.

Qwertymodo added it: http://www.romhacking.net/forum/index.php?topic=23063.0

Turns out he's the same guy that made the video I learned how to make MSU-1 audio with, as well as the author of the Zelda:LttP DX mod (of which MSU-1 support is just one of the selling points).

---

Oh, and by any chance could your script be altered to just copy the header data from one file and paste it onto another? (basically header data from [filename.pcm] applied to [filename].raw) So I could combine it with the sox batch script I made to alter a bunch of files as a simple 2-step process? A script like that'd be helpful to me for several things, some outside of this project (though still MSU-1 related).

[Dizzy611]

I could write something to do that, yeah. I'm not going to alter the script I put in the git/am using locally because imo this is cleaner, but I'll write you a script to just copy the MSU-1 header from one file to another (overwriting the first 8 bytes, as if you're running a PCM directly through SoX that'll still be there, just mangled) and put it in a gist, linking it here when I'm done.

https://gist.github.com/Insidious611/9c3239e3d3894dda1792b05a5aa99057 EDIT: Done. The above linked gist should have what you need, the python script and a modified version of the batch file you linked. Note you'll need python 3.x installed and on your PATH for this to work.

[Dizzy611]

Also, fwiw, the BSNES option in the installer should be the equivalent of the higan option without the track renaming. I'll probably rename that to "BSNES/Snes9x" in the next version of the installer now that Snes9x has MSU-1 support. I'm also getting ready to do some testing using the deamplified tracks (and the fixed missing wild west/veldt track) and snes9x.

[Dizzy611]

Have successfully tested using Snes9x and the deamplified tracks. :) Leaving this issue open until I've modified the installer to provide deamplification/volume reduction as an option and uploaded the deamplified versions to my server, but it is complete and working on my local copy.

[edale2]

SNES9x uses SD2SNES's file naming scheme (including no manifest.bml), so you might consider making it SD2SNES/Snes9x instead.

A lot of the earlier tracks I wasn't paying much attention to if they needed more/less than -7.5 amplification, so there might be a few more tracks that need different amplification levels, but -7.5 does seem to cover ~90% of the tracks. I'll give them a quick go-over in the next day or two to check for more special cases (I have off of work tomorrow, so I'll probably get most of it done then).

When I was first trying to figure out MSU-1 support on my Raspberry Pi, it took several hours of research to find all the info I needed to get it working, so I wrote up a guide over on the RetroPie forums (https://retropie.org.uk/forum/topic/13144/snes-msu-1-guide), and one of the users was having problems with audio distortion in a really old Zelda:LttP MSU-1 mod, pretty sure the problem is the same as these PCM files had and deamplification will fix them. With your script to run after the sox batch I made I should be able to fix the audio for him in like 5 minutes. It'll also make me able to fix the PCM audio in pretty much all the older MSU-1 mods (they had louder PCM audio because of a bug in the chip of SD2SNES's prior to v1.7), really opening up the MSU-1 modded games I can comfortably play.

[edale2]

SSC 32 - amplification of -4dB needed - which I only found so soon because #16.

[Dizzy611]

Added to the script.

On the mention of MSU-1 things to try on your Pi, give mlarouche's chrono trigger project a try. His work inspired mine.

[edale2]

You know how I said Zelda:LttP DX was my second MSU-1 mod? Chrono Trigger was my first. :)

And given it wants you to buy the symphonic tracks for the mod, I think it was his that I played, lol. Not the FMV version though.

[edale2]

OK, I've got a MUCH better ear for where the volume needs to be to not drown out the game's sound effects, and I'm trying to normalize everything to around the same level, so there are going to be a bit more changes than the few I've listed, because I'm going over every track with a much better ear, and higher standards. If I put a different value for a track before, go with this value.

ALL of FFT (if a track isn't listed, it's at -7.5dB): track 2: -6dB track 10: -8dB track 12: -8dB track 13: -8.5dB track 24: -8.5dB track 28: -9dB track 32: -8.5dB track 35: -8dB track 36: -8.5dB track 46: -8dB track 50: -8.5dB

I'm still going to have to see how they sound in-game to be 100% sure, but if any more adjustments are needed, it should be a blanket adjustment across all files.

I can't believe I'm actually manually normalizing these...I must be nuts, lol.

I'll probably make it through SSC and OTH tonight, and work on OST/OCR tomorrow.

Yea, OTH was fast, lol. Only 2 track to check:

OTH track 70: -8dB track 34's good at -7.5dB

[edale2]

SSC normalization (again, unlisted tracks are -7.5 dB): track 2 : -8dB track 5 : -8dB track 9 : -8.5dB track 10 : -10.5dB track 12 : -8.5dB track 13 : -9dB track 18 : -8dB track 20 : -9.5dB track 22 : -9.5dB track 23 : -9dB track 25 : -11dB track 26 : -10.5dB track 29 : -8.5dB track 31 : -9.5dB track 32 : -4dB track 35 : -9dB track 36 : -9dB track 42 : -8dB track 46 : -8dB track 47 : -8.5dB track 50 : -8.5dB

Like I said, higher standards. you may just end up individually marking more than 1/2 the tracks in your script. End product should be worth it though.

Only got OST and OCR left to go through (so only about 80% left, lol). I'm done for the night though.

[edale2]

It occurs to me that with your script, you could set the base -7.5 value, for most tracks as a variable. Then when one of the tracks that needs a different amplification comes up, you could copy that value to a new variable, and adds or subtracts the difference (so for SSC track 50 at -8.5, you subtract 1 from the base -7.5), and use that new variable to set the amplification.

If things are setup like that, and it turns out we do need a different base amplification level for the mod, you'll just need to adjust the base value, and it'll automatically keep all of the tracks normalized to each other, since they'll base their amplifications off that base number.

This way you'd be able to make a new deamped set of tracks off the originals, rather than applying another deamp to the already deamped tracks (which would lower the end-product sound quality)

Yea, I may not be able to code, but I do have a firm grasp of programming logic. ;)

[Dizzy611]

Not a bad idea, and not particularly difficult to pull off. I've noticed you contradicted yourself on a number of earlier suggestions though, any particular reason? Or does that just fall under "better ear"

---

Have implemented that system and your changes so far.

[edale2]

Partly better ear, partly me not thinking normalization earlier, and partly I'm actually applying the -7.5 dB amplification to each track and listening to them all at a consistent volume to see if further adjustment is needed.

I was just trying to get rid of the audio distortion at first, now I'm trying to balance the volume of each song, while keeping it at a point that it should work with the in-game sound effects.

[edale2]

• ("OTH", 34, 7.5), (line 71)

If I'm reading the code right, that'll do a 0dB amplification, I know I said it didn't need deamplification before (when I was just trying to get rid of the distortion), but when I was going over it recently for normalization, I changed my mind: "track 34's good at -7.5dB"

If no deamplification's done to the file, it'll be too loud compared to the other tracks.

God it's weird looking at a commit on GitHub and actually understand what I'm seeing, lol.

[edale2]

Just found on the Zeldix site: https://www.zeldix.net/t1265-fixing-all-of-the-too-loud-audio-packs-for-good?highlight=fixed+audio

Final Fantasy III/VI [Balance and Ruin, Covarr's Loops] (-18dB): CODE: http://www.mediafire.com/?kovoi54dbzoitt0

Final Fantasy III/VI* [Balance and Ruin, qwertymodo's Loops] (-18dB): CODE: http://www.mediafire.com/?wfe7e2n86b3mf78

[edale2]

Thankfully I'm working on the OST atm, and haven't started OCR, now I don't have to, lol.

Frankly a trust Qwertymodo far more than myself for judging these things, he's one of the leading experts on MSU-1 mods (he's the guy that coded MSU-1 support into Snes9x, amongst other MSU-1 related things).

Also, he has a script that strips the PCM's MSU-1 header, adds a valid WAV header, runs the audio through an actual normalization program (so a bit better than just deamplifying, and no need to modify specific tracks differently), and then strips the WAV header and puts the PCM's MSU-1 header (including loop data) back on. So very similar to your script.

Now that I think on it, he probably can help you with your fading issue, or at least point you in the right direction.

[Dizzy611]

He's been active on the qhimm thread on occasion as well, I was already planning on adding the alternate loops he mentions there (he posted non-normalized ones to the qhimm thread) in the next version of the installer.

---

On that note, I've been working on the next version of the installer, no binaries yet, but it's in this branch, and appears to be working well so far, though I've not yet uploaded the alternate OCR tracks so that bit will likely crash. This supports downloading deamplified/normalized tracks automatically, and has support in it for downloading from alternate directory trees (am currently using it to test the new tracks in a "new" directory under ff6data so as not to impact people downloading/installing with the current installer)

[Dizzy611]

I just posted in the thread to make sure we have permission to distribute his renormalized packs. I'm not expecting a no, since he already gave me permission to distribute his alternate OCR loops, but I'm waiting for confirmation before uploading them.

[qwertymodo]

Just chiming in here, you should really be using RMS normalization, not peak normalization. Then, you can use one consistent value across all tracks. Specifically, for FFVI, -18dB RMS seems to be about right. Unfortunately, a lot of audio tools, including SoX, don't do RMS, but the program I use is really simple: http://normalize.nongnu.org/ you just need to replace the MSU-1 header with a valid WAV header (the actual sample data doesn't need to be modified at all), then you can run it through that program to do the normalization, then just swap the header back.

Once you've normalized the volume, it should work everywhere. There is no need to keep both the normalized and the loud versions. The only implementation that had issues with the audio being too quiet was the SD2SNES, but there is an audio boost option in the v1.7 firmware that fixes it, and the Rev.H hardware fixes the underlying hardware issue that caused it in the first place.

Also, absolutely yes, go ahead and use the files I've already normalized.

[edale2]

And the man himself comments.

Not really doing peak normalization, I was individually judging each file by ear. Problem is I'm not really playtesting them in-game yet to really try and balance the music vs the in-game sound, just getting it to a point all the SPC sound will still be hearable. I actually suggested the change to Insidious661's conversion script earlier because I'm pretty sure more changes for balancing were gonna be needed (which your value of -18dB definitely suggests).

@Insidious611 Should I keep going over the OST tracks (I'm about 1/3 of the way done atm), or are you going to try that normalization program?

[edale2]

Ah, just realized that OCR pack doesn't have the edit I did to Covar's track 76, removing that useless chunk of the intro...

[qwertymodo]

Even though you're doing it by ear, you're still using peak levels if you're coming up with values like -8dB. I'll look into track 76 and see what you're referring to. If it's really an issue, I can definitely re-do it.

[edale2]

Oh, i just removed the first half of the intro and relooped it, you can see it, and my new PCM here: #13

It was my first foray into MSU-1 PCM audio coding before converting my first track from scratch. From what I've seen of your how-to videos it's something you would have removed from your version already.

[edale2]

Going through the "fixing too loud audio packs for good" thread, I found the post where @qwertymodo uploaded his edits:

*I did not include the Overture, Opera Sequence, Aria, Dancing Mad, or the Ending Theme, as I'm not sure how those are handled. Once I figure those out, I will add them to the pack and re-upload. Also, some songs may need minor volume adjustment.

Not sure about the Overture, Aria, or Ending Theme, but the Opera was disabled due to a bug (#3).

As for Dancing Mad I was just asking @Insidious611 about that a few days ago, it's split into 4 parts, each looped individually. Dancing Mad part 1: ff101.pcm Dancing Mad part 2: ff102.pcm Dancing Mad part 3: ff103.pcm Dancing Mad part 4: ff82.pcm

I'm actually about to try and convert a version of Dancing Mad to MSU-1 PCM myself (The Black Mages' cover), I was waiting until I was done going over the tracks for the deamplification, but if @Insidious611 uses that normalization program, I won't have to finish that, and can jump right into editing Dancing Mad.

[Dizzy611]

As to how those tracks are handled... surely you can figure that out by listening to the .pcms for the OST? :P I can't really say much more, not for wanting to be cryptic or anything but because it's kind of hard to explain in words especially since I'm not the one who did the editing. They're handled the way they're handled.

If you need track numbers, the opera songs (including overture and aria) are, in track number order (which isn't much of an order at all in practice): 38, 39, 65, 66, 67, 68, 69, and 70. All of these are currently stubbed out in the installer due to the aforementioned bug #3, which can be summed up as "I can't figure out how the heck to get the game to not crash when it tries to cue up individual notes during Celes bits in the opera"

70 is an odd one in that afaict Covarr apparently never found an equivalent until we looped the Tokyo Symphony Orchestra tracks used in the "OTH" selection.

edale2 gave the Dancing Mad tracks above, though technically I'm using track 82 as part 4 and 5.

The ending theme is simply track 83. There's nothing special about it that I'm aware of.

With the exception of having to part out Dancing Mad specially due to the subsong nonsense, everything follows the way the SPCs are numbered by the game's own music routines.

[Dizzy611]

Didn't want to add this to the last bit because it's not too related. I've begun work on a script to basically do what sox-deamp.py did, but using the nongnu normalizer qwertymodo recommended. I ran into some difficulty due to Python not really having a way to handle structs of structs of structs the way qwertymodo's MSU-to-WAV code he linked does.

The way I did it is a tad messy, probably not very "pythonic", but it works and makes a modicum of sense. I confirmed it was functioning properly by importing a PCM in Audacity (with offset of 8 bytes to skip the MSU header), exporting it as a 16-bit signed WAV without changing it, then comparing the headers between what my python script generated and what Audacity did. They were identical, so it seems to work.

---

And done! The changed (much shorter!) scripts are in utils, replacing "sox-deamp.py". "msu_normalize.py" is usable as a general purpose msu normalizing module (still uses nongnu normalize, but wraps around it in a pretty "one and done" way). "dancing-mad-normalize.py" is a heavily edited "sox-deamp.py" which does what its predecessor used to (creates directories full of edited versions of tracks).

Given what qwertymodo said, I'll probably move to just offering the normalized tracks in the new installer, instead of offering a checkbox.

I ran the script on my server. If you take a look in http://www.somebodyelsesproblem.org/ff6data/new/ you'll see the original tracks, the old deamplified tracks, and the new normalized tracks side by side. I encourage edale2 to take a listen to all 3 and tell me what he thinks. :P

[edale2]

Great, another 10ish GB of stuff to download, lol.

I'll grab a few tracks from each and compare them in-game tomorrow.

[edale2]

@Insidious611 Did you run the normalize program at -18dB RMS normalization as @qwertymodo suggested? Because they appear to have been normalized at -7.5 dB.

new/deamp-SSC/ folder has all the other deamp folders inside it (so all the other deamp folders got copied into there by mistake).

[qwertymodo]

@edale2 you seem to be confusing RMS and peak. They might be -7.5dB peak, but there's no way they're -7.5dB RMS (a bunch of the tracks would be horribly clipped at that level). A quick glance over the first couple of tracks from each pack looks good to me level-wise.

[Dizzy611]

Yeah, it's using -18dBFS, I'm sure. Also, the deamp-SSC folder containing the other folders explains why I ran out of space and had to move them to another partition... :P Well, if this is all good then I can delete those entirely anyway. I'm uploading the alternate OCR loops now and will then simplify the folder. Am also working further on the installer, if I don't find any major bugs a new full on release could be soon.

---

Rather off-topic, but if you check the README.md I've opened a Discord where we can have more in depth conversations if needbe, since the ones we're having in the GitHub issues tend to go on a bit long.

[edale2]

@qwertymodo I'm looking at the volume level of the stuff in the deamp folder vs the stuff in the normalized folder, I could see a slight difference in the waveforms, but the volume levels were about the same.

I'm still testing though, and it seems to be balanced in-game so far. Maybe my ear was just that good while going over them. ;)

[edale2]

@Insidious611 From one of @qwertymodo's posts:

---

So, with all of that said, we need 2 things, non-boosted audio files and proper full-volume code. In the case of hacks with "emulator" and "sd2snes" versions, that means that the "sd2snes" version is correct, because those hacks used scenario 3/4, and we want the full $FF volume. In the case where you're not sure which is used, there's a fairly simple way to determine that. Open the game in bsnes-plus (you'll need a proper .xml manifest, the higan .bml manifests won't work, and the files utilize the SD2SNES/Snes9x naming format gamename.sfc/gamename.msu/gamename-#.pcm). Once you've confirmed that the game is loading with MSU-1 audio, open Tools>Debugger>Tools (in the Debugger window)>Breakpoint Editor

In this window, under Address Range, type 2006 into one of the boxes and check the "W" box for than row. Now play the game and it should break the next time the game tries to set the MSU-1 audio. You should get a message like this in the debugger:

CODE: Breakpoint 0 hit (1). a1f9d7 sta $2006 [802006] A:31ff X:0001 Y:0000 S:01f2 D:0000 DB:80 NvMXdIzC V:225 H:253 F:43

Two things to note here, first, it starts out with sta $2006. If it's stz $2006, ignore it, hit Run in the Debugger window, and continue to the next one. Second, the information we're after is the low byte of the accumulator, in this case that's where it says A:31ff, and the low byte is the rightmost 2 digits. Here we see ff, which means we are setting the volume to 255, we have a full-volume patch, that's all you need to know, done. If the line starts with stx $2006, check the X: value instead, same for sty and Y: (stz means store zero, so it doesn't matter what the values are which is why we skipped it). Now, if the value is less than ff, that doesn't automatically prove that we have scenario 2/4, because it's possible that maybe the game is fading out, or setting half volume for some other reason, so you'll want to Run a few breakpoints to establish a pattern, but once you see ff even once, that's enough to confirm scenario 1/3.

---

Using those directions, I checked the volume value of the patch. I played through until the end of the beginning Narshe section.

The highest value I got was DF (fairly consistently). Apparently things like fading can affect this, but since you don't have fading implemented...