Previous Page | Next Page
- by psy_commando at 9:26 PM EDT on April 16, 2016
- Thanks! That should help a bit!
- by psy_commando at 5:21 PM EDT on April 30, 2016
- So, I found out why most other games came out wrong using my tool..
Its just because I did a very stupid assumption, and forgot that games where each SMD/SWD pair have their own samples, don't usually share any of them..
I got confused, because all chunsoft games were doing a pretty good job at having all the same size of sample table..
So, like 4 months past the time when I wanted to release this, here's the new version of my tool.
I also fixed the issue with that 999 game. It turns out that there's a single sample whose format is 0x300, which I assumed was PSG, because the format #3 in nitro composer is PSG. But looking at its entry it seems to be actually 3 bits ADPCM samples.
Anyways, to top it off, that one sample entry in 999 is length 0.. So its probably a mistake on the dev's part. But it threw an exception. I just don't process that sample type now, and just log it. I haven't found a single example of sample data for it, so I can't do anything about it, if its even used in any games at all.
I added support for ripping matched smd/swd pairs from random formats that literally are just swd and smd continers one after the other. I call those "blobs" for a lack of better terms. It can rip things from the blobs containing music in luminous arc(snd.iear), inazuma eleven(sound.pb).
It probably won't work if the game uses a main bank instead of several swd each containing their own samples. And it definitely won't work on anything compressed or encrypted. And I don't recommend using it on roms directly, because that will probably give some odd results..
I also added support for batch handling "bgm containers" which are basically just a SIR0 wrapper wrapping a smd+swd pair. That's used in 999 and zombie daisuki.
Here's the link to download it
So now I can safely say that I'm rewriting this thing from scratch, because I patched over so much, that now it takes more time to find issues than it should, and its a mess. XD
I still can't figure out the issue with PCM16 samples though, I just skip baking their envelopes, and it sounds ok-ish for more tracks. But a lot of others still sound off-pitch.
And I think in general its because I have to loop a bit some samples so that they're long enough to be loop legal in a soundfont. But, that messes with their pitch a bit, especially on very short samples.
If/when I write that foobar plugin, that probably won't be an issue since I'll be able to loop the samples however I want.
edited 5:24 PM EDT April 30, 2016
- by jimbo1qaz at 6:14 PM EDT on April 30, 2016
- What is a "loop legal" soundfont? 16 samples before and after loop point? You could just ignore that requirement. None of the software synthesizers I use care about that requirement.
Soundfonts are an outdated format, anyway.
edited 7:25 PM EDT April 30, 2016
- by AnonRunzes at 11:27 PM EDT on April 30, 2016
- Thanks for the latest version.
And good luck on rewriting everything from scratch, I guess.
- by psy_commando at 11:34 PM EDT on April 30, 2016
- @jimbo1qaz:
Its 16 samples between the loop bounds, 8 before and after loop bounds. Its in the official specs.
And I tried ignoring them, but all synths I used it on wouldn't loop. Including the bassmidi build in the foobar2000 midi plugin, coolsoft virtual midi, and the BASSMIDI software synth driver for windows. And well, viena and polyphone too.
Soo, idk what you're using for playback, but, that doesn't work on anything else I've tried it on.
EDIT: Welp,actually, I think you might be right.. Sorry.. Idk what I was doing, but this time after bypassing the check for sample lengths, it seems things still loop properly.. I have no ideas why it never worked before though.. Some PCM16 samples are still off pitch though, but there's a bit less clicking now.. :/ I'll upload a patched version soon.
EDIT2: I also realized that the export without baking the volume envelope into the samples is broken. I forgot to uncomment a line after testing... And, well, I think what got me thinking that looping didn't work might have been that the volume envelope value when converted and used as-is in the soundfont sounds as if most samples were cut abruptly. I'm not sure why exactly.. When I bake the envelopes into the samples directly, I get 0 issues with the same values. But when I put them in the soundfont's generators it just doesn't work.. I assumed this far that it was because its logarithmic and not linear, like DSE's envelopes are.
And yeah, its outdated, but there's nothing else for dealing with midi playback that's nearly as widely supported. And since this is mostly something I did for fun and for ripping midis and samples. And for eventually injecting tracks and samples back into the games. It does the job.
I also knew for a while that soundfont or DLS wouldn't cut it if I wanted perfect playback, so its mostly a proof of concept, so I didn't need to find an API just to listen to the result so I could figure out the format better.
edited 2:04 AM EDT May 1, 2016
edited 2:04 AM EDT May 1, 2016
edited 2:40 AM EDT May 1, 2016
edited 2:41 AM EDT May 1, 2016
- by psy_commando at 11:39 PM EDT on April 30, 2016
- @AnonRunzes :
You're welcome! Sorry about the delay. Stuff happened ^^;
And thanks. Though, I probably will keeps some stuff. Just everything tied to dealing with the samples and loading stuff is really in serious needs of a cleanup ^^;
- by psy_commando at 10:46 PM EDT on May 1, 2016
- Alright, so I did the quick fix for the bugs I missed:
here
Fixed the "-nobake" export as much as possible. The issue with envelope parameter durations is still there though, but at least, now samples have their rootkey properly assigned..
Also I disabled the check for loop legality. And samples are injected and looped as-is in the soundfont.
- by psy_commando at 3:28 PM EDT on May 15, 2016
- Hey!
So it turns out, there's something I'm not processing correctly about the pitch correction values used in DSE.
Samples have their pitch correction data, and so do preset splits.
They both have the same 4 bytes, which represent fine tuning(probably cents), coarse tuning(semitones probably), root key, and probably what's labelled "k.tps" on the DSE UI screenshots. (Possibly "key transpose" ? it appears to indicate the difference between the root key field, and middleC/60)
But the thing is, those are fairly redundant.
Let me lay down how it seem to work:
The samples seem to have mostly default values in those 4 fields. Its usually:
0x2A 0xF9 0x3C 0x00
Which would translate to 42 cents, -7 semitones, note 60 as root key(middle C I guess), and transposed of 0 key from middle C.
But then it gets complicated..
Each splits can refer to samples by id. And they each have their own values for those 4 fields.
Some may have exactly the same value as the sample. But in most cases they're not the same.
Here's an example from a swd file:
Sample:
0x2A 0xF9 0x3C 0x00
Split:
0x2A 0xF9 0x18 0x24
Notice here how 0x24 is 0x3C - 0x18? The difference between the root key of the sample, and the root key of the split basically. But, I'm not sure why its even needed?
Moving on, here's another example:
Sample:
0x3F 0xF9 0x3C 0x00
Split:
0x3F 0xF6 0x30 0x0C
Notice how the fine tuning value wasn't 0x2A for the sample? And notice how the coarse tuning changed from -7 to -10?
Here's another example:
Sample:
0x30 0xF9 0x3C 0x00
Split:
0xB0 0xFD 0x54 0xE8
Here, the fine tuning goes from 0x30(48), to 0xB0(-80? or 176 if not signed).. And the coarse tuning from -7 to -3.
That begs the question, are the sample and split values additive, relative, or absolute?
They don't appear to be absolute from testing.. But, my code is such a mess right now, that I don't want to say that for sure.. ^^;
And disassembly wasn't too conclusive this far.
So, I'm wondering if anyone here has any ideas?
edited 3:30 PM EDT May 15, 2016
- by psy_commando at 2:18 AM EDT on May 17, 2016
- I figured out part of it. Apparently, the pitch fine tuning parameter is an unsigned byte that goes from 0 to 255, and 255 == 1 semitone or 100 cents.
Or at least, from ear, it sounds about right.
After adding that little change in the program a lot of things began sounding like they do in the game, just slightly detuned.
Except, it doesn't work out on its own for every samples.
There's still the "coarse tuning" parameter left to figure out. And I'm begining to wonder if its not something to pitch shift the note not in semitones, but in relation to a scale/key?
Mainly because in PMD2, its usually set to -7, and its common to see scales/keys with 8 notes.
And well, in the DSE UI screenshots, there's a parameter labelled k.tps/possibly key transpose.
Its just a wild guess though.
From changing the pitch values live in an emulator while a track was playing, I noticed that, if I set all pitch parameter values to 0,0,60,0 the track sounds higher pitched than if I'd do the same and export the file with my program..
So I wonder if there isn't something else affecting the note pitch..
edited 2:21 AM EDT May 17, 2016
- by AnonRunzes at 10:18 PM EDT on July 7, 2016
- Any progress on it so far?
Previous Page | Next Page
Go to Page 0 1 2 3 4 5 6 7
Search this thread
Show all threads
Reply to this thread:
HCS Forum Index
Halley's Comet Software
forum source