Previous Page | Next Page

by kode54 at 8:40 PM EDT on September 14, 2015
That would require interfaces to the actual player code, which would require hooks similar to what PSFoCycle can do, except in real time. I'm not sure that's even doable.
by Nisto at 10:20 PM EDT on September 15, 2015
Yeah, I wasn't really holding my breath. I suppose I will have to rip the tracks separately (it's just one byte that needs to be changed for each track chunk). Unless someone has a better idea/solution?

How doable is it (if at all) to make a component for foobar2000 that plays multiple tracks simultaneously? I see a couple of old threads on Hydrogen Audio asking about it as well, but it doesn't seem like anyone has come up with a solution (except for the method where you open x instances of foobar2000...) If that was doable, one would at least be able to simply play the separate (modified) PSFs for each channel/track and control it dynamically that way... assuming you can control the volume individually for every track currently playing too?

edited 10:22 PM EDT September 15, 2015
by kode54 at 11:08 PM EDT on September 15, 2015
That is better served by a track mixer panel that can open multiple files at once and vary their levels in real time. Something that could support any arbitrary format decoded by foobar2000 itself.
by MarkGrass at 12:13 AM EDT on September 16, 2015
@Nisto - The Sony PlayStation does support playing multiple, separate sequence data at once, but only if they all share the same soundbank. Each sequence can even have it's own volume levels and such.

This method is accomplished easily with SEP data (container of multiple SEQ data). The original Resident Evil uses SEP data; think of the Dining Room where you simultaneously hear both music and the Grandfather clock (they're both sequences from the same SEP using a singular soundbank). I've confirmed that very PSF player supports multi SEQ playback at once (SEP data).

I'm not sure that this helps, but yeah. If possible, I would just convert the data to standard SDK stuff and use a SEP driver. I know that's not really desired, but it's certainly another way.

I personally wouldn't mind having separate tracks, at least for now. I've been waiting on a rip of SH for quite awhile.
by 47iscool at 2:52 PM EDT on September 17, 2015
2extreme and 3extreme's sequenced music can be ripped and put together with vgmt just in case anyone was looking for more ps1 games that can ripped.
by Nisto at 6:23 PM EDT on October 2, 2015
I'm not sure if there is a more appropriate thread to ask this, and I didn't want to start a whole new thread, because it might ignite a bigger discussion than I personally want. :P

Anyway! When ripping any xSF driver, what exactly should we and should we not remove/modify/tweak? I have followed someone42's guide (where any of it has been applicable) as best as I remember it from my first rip I did last year. I remember they mention changing the driver to directly set the channel configuration to stereo instead of having the code going through some conditions which might end up setting it to mono.

So, suppose I don't know every possible setting a driver might have (number of enabled voices, tracks, reverb stuff, who knows) that could potentially affect the "accuracy" of the final rip. Would it be the end of the world if something I didn't know about that preferrably should have been changed was left untouched? Should I assume everything is good if it.. sounds good by ear?

To be more specific here, I am working on a PSF set with a custom driver. And yes, in this case, I have actually found and made sure channels are set to stereo and that as many voices as possible are enabled (24) - in fact, these are the original driver settings, so I don't really need to change anything. But I honestly really don't know what a lot of the other variables are, even with the help of emulators with SPU debugging capabilities or when trying to compare changes by ear.

My ultimate reason for my concern though is I notice the volume in the driver I ripped is surprisingly low compared to a different driver that supports the same sequence format. Of course I have tried cranking up the main volume on my system as high as it goes (and these are pretty loud headphones I'm using, which are well driven by my computer alone at measly 32 Ohms) and it's still not very loud. So I tried increasing the driver's volume as much as I could and it's not that loud at all - it sounds quite "balanced" in fact (it basically matches the volume of the game's OST CD release based on waveforms). I also know there is a volume tag I could supposedly use instead, but it seems like that doesn't affect anything - at least not with this driver (nor the aforementioned one), neither in PSFLab nor foobar2000 (PSF Decoder). And then there's ReplayGain, sure, but not everyone has ReplayGain available.

So are there any strict guidelines on this stuff? Can we/should we (not) change driver settings (like in this case, the volume)? Should I leave everything untouched? What would pro xSF rippers do? Or for that matter, what do "consumers" think? Anyone?

edited 6:56 PM EDT October 2, 2015
by MarkGrass at 10:30 PM EDT on October 2, 2015
There really aren't any guidelines, so far as quality is concerned. Hell, there aren't really any guidelines at all, in fact, just so long that it works. People used to find errors and update their sets with missing data often.

CaitSith2's "Chocobo Dungeon 2" rip was bugged for a 12 years and no one even noticed until kode54 just recently upgraded old PSF plugin code with care. Specifically, CaitSith2 put a jump opcode in a delay load slot which was never caught because old PSF plugin r3000a code allowed it without crashing. This stuff happens and no one is gong to hate you if a set needs to be updated later.

Volume output from PSF is never quite what you'd expect (loud), no matter the driver/game or data. I think this is because PSF plugins do not have an output gain/amplification routine <--- I could be wrong about this.

When creating an original driver, if it works with the newest PSF plugins, it's acceptable. Really, all you should be doing is removing calls to CD/GPU/related functionality and ensuring it's ready for audio playback. At this point, it's expecting data to be in RAM and the SPU code will fetch any necessary values elsewhere in the exe or ram.

Really, though, I think people are ready for the Silent Hill rip :P

edited 11:00 AM EDT October 3, 2015
by kode54 at 4:27 AM EDT on October 3, 2015
It was the Chocobo's Dungeon 2 set, which this player had a hack for, but it was dependent on reading the tags within the emulator setup code, and I didn't want to do that, so I wrote a tool to patch the set instead. The tool is in my gist repository on Github.

As for loud or not, it depends on the set, but the volume the emulator outputs is as the digital part of the SPU produces. The analog response of the hardware is then simulated on top of that, optionally.

Good job on contributing more rips, though! I'm still waiting on a brave soul to make use of the information I tried to glean from Mega Man Legends 2, as I eventually grew tired of playing through and logging the song numbers and such. I still have the save states for PCSX-R, though.
by MarkGrass at 11:18 AM EDT on October 3, 2015
Ah, I knew it was one of the Chocobo games; updated my post. Just out of random curiosity, I suppose the patch is still included in the latest plugin source code?



EDIT:

I had another look at MML2 and reconfirmed what I had figured years ago: The data is standard SDK format, just simplified to use less space. In fact, it's very similar to what was used in Resident Evil 3.

A converter can be written...

edited 7:23 PM EDT October 3, 2015
by RB at 5:48 PM EDT on October 3, 2015
I publicized the Chocobo's problem back in 2005 when I first encountered it. Because MAMEdev runs everything into the ground, we even loaded it on real hardware and watched it crash.

There's a reference here:
http://rbelmont.mameworld.info/?p=40

And here:
http://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=21786

People had noticed that e.g. SexyPSF also didn't play it before AOPSF existed, but nobody had debugged it before me.

So either way, it certainly wasn't unnoticed for 12 years :)

Previous Page | Next Page
Go to Page 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220

Search this thread

Show all threads

Reply to this thread:

User Name Tags:

bold: [b]bold[/b]
italics: [i]italics[/i]
emphasis: [em]emphasis[/em]
underline: [u]underline[/u]
small: [small]small[/small]
Link: [url=http://www.google.com]Link[/url]

[img=https://www.hcs64.com/images/mm1.png]
Password
Subject
Message

HCS Forum Index
Halley's Comet Software
forum source