PSF audio channels by Volkov73 at 4:27 AM EDT on August 29, 2017
Hi guys. I'm hoping someone can make a suggestion on how to save a lot of time.
I want to create WAV files from psf (or minipsf) files. I can do this with Audio Overload, though - this is incredibly time consuming. I would like each channel as a separate WAV file. Audio Overload is also capable of this, but in it's current form would take up to an hour or so per song (with constant human interaction).
I'm looking to generate songs in the following format:
You would think one of these Winamp plugins or foobar plugins would come with a command line output option. I don't mind some manual work, I can create scripts for mouse/keyboard automation. But I would at least like to save each WAV file near-instantly, as opposed to letting the entire song play through 24 times (takes extremely long time).
It won't be terribly useful as just audio channels, since most PSF sets cycle through the channels in an automatic fashion, for dynamic channel allocation. It would be better to mute channels based on the instruments used.
Doesn't that only work with markgrass's generic psf driver. If you have a game that uses something else, you're stuck with audio overload if you have no idea of what to do with a hex editor or psflab(maybe).
I already wrote an SPC logger that separates WAV files by instrument rather than channel. It would be easy enough to do the same for PSF or PSF2. Of course, logging them becomes somewhat slower, as each core of the host machine gets to render the whole song, but with all the other instruments muted.
@kode54 - Where would I find this SPC logger? I would be keen to try that out.
If you think you could do something for psf files that would be a godsend. Currently with Audio Overload it is taking up to 1 hour to create seperate WAV files for just 1 song.
It's the multidumper I linked to in another topic on this forum.
Oh, and as far as PSF is concerned, the unencumbered libraries used by things such as Audio Overload are actually slower than Highly Experimental, and also less compatible with a number of rips that work on actual hardware. That doesn't automatically make it better, though.
Basically, I'd have to insert hooks into a fork of the HE APU, and cache a table of sample start/loop pointers to catch unique instruments. It works in a deterministic manner:
1) Note starts on a given instrument. 2) Table of known instruments is checked for addresses for this note. 3) If it's not in the table, it's appended to the table.
And this process is repeated each time the song is logged, with an increasing part number up to maybe 20 or 30 or so, so we don't waste too much work.
The first pass through can be used to log how many unique instruments occur during the song, limiting work.
4) Based on the given part number, starting with 0, if the instrument addresses match that entry in the unique table, it is unmuted. Otherwise, it is muted.
Being the multidumper design, it will run a full song conversion on each CPU core for each of these potential instrument combinations, until it exhausts the possibilities for the given track time limit as tagged. So already, it should be 4-8 times as fast as what you're doing now, depending on how many cores you have.
You have me highly interested, though most of what you said went over my head.
One question: Let's say there are three PSF channels that play the same instrument (for instance, a chord), will they all be logged into one WAV file or will I still have three seperate WAV files - one for each of the three parts of the chord?
As Audio Overload works currently, I will get one WAV file for each channel. A three note chord will be played across three channels. This makes determining the notes of the chord 100% accurate as there is one note per channel.
The worse case scenario for me would be if this entire three-channel chord becomes one WAV file (because the instruments are the same). This is still a usable state for me, but I would definately prefer each note on a seperate WAV file.