Home Page Forums Other Emulator Message Boards Audio Overload Not quite AO, but...

I've ported vio2sf to a very bare-bones Linux commandline app (some here will recognize that it's AOSDK with the serial numbers filed off). This means you can now play 2SF rips on Linux (woo hoo!). It's a sucky user experience but it sounds great. Patches to improve usability or whatnot are welcome. Operation is certified only on little-endian, although it doesn't seem like it would be too bad to make work on BE also in case you want your PS3 to sound like a 66 MHz handheld ;-) License is GPLv2 as inherited from Desume.

Get the goods here.

haha! for once TuneNet had it first!

But hey, great work!

The hell is TuneNet?

ETA: Oh, the Amiga player, gotcha.

Well, technically they were playable earlier with a Wine+Winamp combo. Still, good job!

Few answers before anyone asks (I really, really need to make a Manly FAQ section).

1. Many NDS games use streaming music (sometimes exclusively). This player won't handle them, Windows users can play them with either in_cube (http://hcs64.com/in_cube.html) or VGMStream (http://sourceforge.net/projects/vgmstream). The latter is supposed to be portable to hell and back, so I'm sure someone will have a linux port in a jiffy.

2. Almost all sequenced rips *don't* use orignal game driver. This shouldn't be much of a problem, though there can be minute differences in effect handling between driver versions (similar to, say, Saturn driver or Protracker versions). Also, some games simple don't play well with the driver used (seemingly at random, though I'm 100% sure a song that uses more than 450kB of samples won't play). This won't be fixed in any way unless someone can devise a multigame patcher, similar to Saptapper.

3. Few games (of the top of my head: Animal Crossing, Tetris DS, Metroid Prime: Hunters) use dynamic music, meaning they have two or more songs in one sequence data. Original game driver dynamically silences select channels, something that can't be replicated using current rip methods. Vio2SF has a channel mute option, though this won't help you, as the music driver allocates hardware channels dynamically (meaning if there are three trumpet notes that shouldn't be there, each of them will be played on a different channel). Once again, nothing that I can do about this.

BTW, SpotUP, the Hoot sources you've linked to... elsewhere are severly outdated (like, 7-8 years old). They won't help you much, and no, the current sourcebase is unfortunately available only to Hoot devs.

Why the hell do people do this? What's so hard about ripping the correct driver? Why has "kludge things to hell and back so that they work, even if only barely" become an acceptable practice in the last 6 or 7 years or so in the emulation community? First N64, now it's making its way to audio formats, too? Come on, guys.

Look at it this way - If you'd want to listen to the music from Unreal Tournament game would you waste dozens of hours of your life on hacking the main game exe, looking for song load/select procedures, noping the other, unnecessary threads, yanking at least a few hairs from the resulting frustration...
Or would you rather just play the game sound files in any module player? I mean, the game just uses Impulse Tracker modules, standard format, supported by a slew of players.

Same thing here, really.

Sure, the game music driver might have some effect commands supported a bit differently, but really, does this matter this much (given that sound has usually the lowest priority when it comes to CPU utilization, so the files are deliberately kept simple and that the modules themselves weren't made with the game driver but with a tracker which would had the same specs as the *good* standalone players)? We're past the 8-bit systems, the game developers started using middleware and standard libraries ages ago. This is especially noticable on DS - roughly 90% of the games use the same sound code.

Sure, I'd prefer to use original driver in all cases, but I really don't see anyone volunteering to do the hacking work required.

The funny thing is that kludging is *not* acceptable outside of hcs/UF's rip formats, and I daresay it's even lost some popularity for N64 emulation. The stock driver, like sound drivers throughout time, is a standalone piece of code. Once you find it's init, load/select, play, and service-per-frame routines you can just write a self-booting rip that will continue to work for reasonable future versions of the driver, as was done with GSF. USF should have been done that way (although at least there it's somewhat understandable why it wasn't), and 2SF definitely should have.

Uhh, roughly 80% of PSF rips use generic drivers (Mark Grass, davironica's, Neill PSF2 rip kit doesn't really count) as well, you know. At least a quarter of SSF rips don't use the original driver as well.

Unknownfile said that a 2SF mass patcher isn't really doable (due to exe encryption and what not). Finding load/play addreses and patching the rest of the code might be easy for you guys, heck I should be able to do that given a few weeks of training... But during those few weeks I could do, dunno, 100 or so generic rips.

I'm not stoping anyone wanting to do them the 'proper' way, in fact I'll welcome them with open arms.

I was more referring to SSF / 2SF. Regarding USF, I was to understand that each game uses the appropriate sound driver, and it's only a hack in the same way that an NSF or GBS dump is a hack: It's a cut-down version of the ROM (or in USF's case, a saved state) such that only the audio-playback code is still active.

[Remainder axed. This is why we can't have nice things - RB]

That's quite enough children. I've deleted the flame war that just popped up, and I'm going to have a less than zero tolerance for attempts to bring it back up.

K: my understanding is that most current PSF1s are *not* generic driver, or were re-ripped to no longer use one (e.g. Castlevania was a generic driver and missing reverb originally, but the new rips use the correct one). One of the archives used to indicate generic rips and they were always marked for re-ripping.

For PSF2s there's no reason not to use the original driver in games that use the Sony driver since it's always a separate .IRX file on the disc. And of course custom-driver games are always using the correct one.

SSFs largely are using the correct driver unless there's been a great flood of poor quality non-kingshriek rips that nobody told me about.