Replacements/alternatives for OpenPSF?

[Wedge009]

tl;dr: Can/should we replace OpenPSF with AOPSF?

---

Broader context: I migrated from Windows to Linux on my primary machine at the end of Windows 7's support in January 2020. I had previously been using Winamp with various plug-ins and so migrated to Audacious. Recently, I've closed a number of gaps in format support and I think the last major hurdle I have is the quality of PS2 PSF emulation in Audacious' officially supported OpenPSF vs the closed Highly Experimental in Winamp. (I believe PS1 PSFs play fine under OpenPSF.)

Over the last week or so, I've spent considerable effort with LLM assistance trying to address various issues I've found in PS2 playback. I've resolved a few and the changes are committed to my fork: https://github.com/Wedge009/audacious-plugins/commits/psf_spu/. But I still have a number of problems that are seemingly intractable, relating to scheduling fairness and the like.

I noted that the AOPSF implementation is generally very close to Highly Experimental's performance (whose renders I've used as a reference via Proton-encapsulated Winamp), and far better than OpenPSF's output in tracks where I've identified issues. As a proof-of-concept, I made a AOPSF-based plug-in for Audacious to replace OpenPSF in my personal installation, but haven't made this public because of potential licence issues. I contacted @kode54 via https://kode54.net/contact/ several days ago regarding the licence situation for that repository but have yet to receive a response.

So I'm not sure if replacing OpenPSF with AOPSF is a feasible option from a licence perspective, although it appears it's already being used in foobar2000. But here are the specific issues I've identified with current OpenPSF:

Final Fantasy IV
This is a weird set, it seems to be taking PS1 tracks (since FFIV was only released for the PS1) and stuffing it with a generic streaming driver for PS2. Largely these seem to be raw recordings of SNES FFIV output but there is a unique track in the Save File Tutorial, ff4-s-14.psf2. In OpenPSF, this just abruptly stops after a split second of output. With my working branch, there's a lot more output but it's very choppy and there are large segments of silence in the right channel. With AOPSF, this renders just fine.

Final Fantasy X
This entire set just hangs. Mentioned in #282. I understand Highly Experimental handles this because it 'cheats' by using Sony's BIOS data to produce a working driver, but neither OpenPSF nor AOPSF can process this set. #282 mentions an alternative source for the PSF set but the link is dead.

My working branch works around the hang, but renders no audio - the entire track is silent.

Final Fantasy X-2
Many tracks play okay with OpenPSF but there are a few serious issues:

• Yuna's Theme is missing some instruments. AOPSF renders this just fine. Resolved in my working branch.
• Mission Complete is notably missing a base segment in the opening few seconds. AOPSF renders this just fine. Resolved in my working branch.
• Chocobo had serious timing issues, but my working branch discards a heuristic that was skipping silent samples (of which this track has large segments) and thus plays this track well now. But a side-effect is that there is often a large (order of 1-3 seconds) start-up silence that was previously suppressed by the heuristic. It appears to be due to the VM spinning idly for no apparent reason, but this connects to incomplete analysis on the scheduler and attempts to fix it results in serious regressions across many tracks.
• Crimson Squad: like the entire FFX set, this track hangs. AOPSF renders this just fine. Resolved in my working branch.
  • Last Mission: Wind Crest turned out to be affected by the same bug causing Crimson Squad's silence. That bug just happened to be cancelled out or masked by another bug that I resolved in my working branch, which is why it still plays with the official binary but highlights the brittleness of OpenPSF's implementation.
• Vegnagun Starting: after the starting piano introduction there's supposed to be a pipe organ melody. In OpenPSF there appears to be an overflow resulting in horrible screeching. AOPSF renders this just fine. Resolved in my working branch.
• Destruction has missing instruments, similar to Yuna's Theme and Mission Complete. AOPSF renders this just fine. Resolved in my working branch.

Final Fantasy XI
I don't listen to all tracks, but of the few that I picked, there are a few issues I found with OpenPSF:

• Rise of the Zilart - Dash de Chocobo: Many instruments are missing, and with the silence suppression of unmodified OpenPSF, just starts with a ukelele(?) solo. Similar problem with the 'missing instruments' tracks of FFX-2. AOPSF renders this just fine, and resolved in my working branch.
• Treasures of Aht Urghan - Run Chocobo Run!: This one isn't too bad in OpenPSF, there's just a slight hesitation after the first note. Interestingly, this is one case I found where AOPSF wasn't a close match for Highly Experimental's performance but it's still far better than OpenPSF's. Resolved in my working branch.

Ys I, Ys II, Ys III, Ys IV, Ys V
Presumably as a simpler data set and simpler drivers, I found OpenPSF performs just fine with these sets.

---

I'm bringing this up because continuing to fight OpenPSF's implementation doesn't feel like it's going anywhere (at the time of original writing), especially when there's already a largely good, working implementation available in AOPSF. The question is whether or not it's available under a permissive licence. Any thoughts or feedback on this?

[radioactiveman]

I am not really familiar with the PSF plugin in Audacious and therefore handover to @kaniini and @jlindgren90.

My general advice would be;

• Clarify the license question.
• Finish and polish your new plugin.
• Provide it as third party plugin.
• When it met feature parity with the existing plugin and you think it is better than the current one, send a PR to replace it.

The code of the current PSF plugin is old, ugly and prone to security issues. So having a better maintained version would be of course welcome. But at first glance the code of AOPSF does not look better though, probably because they have a lot of code in common.

[Wedge009]

Thank you for taking the time to respond. I did have the impression that OpenPSF was no longer maintained on a regular basis.

• Unfortunately I think I've done as much as I can with the licence aspect for AOPSF. In lieu of getting a response from @kode54 or anyone else with authority on the matter, I have to assume AOPSF is not available for Audacious, despite its use elsewhere.
• I also don't really have much on the AOPSF-based plug-in for Audacious - I took https://gitlab.com/kode54/aopsf for the audio processing and https://github.com/kode54/psflib for the tag handling, with a lot of LLM-assistance in putting everything together, which may also disqualify it from consideration. I made it as a proof-of-concept for personal use, recognising that it's unlikely to be useful while the licence question remains unanswered.

Yeah, OpenPSF is pretty broken as it is, but at least with the patches from my working branch, it's an improvement, just not (yet?) on parity with AOPSF for the things I listen to. And they are both still hopelessly broken on Final Fantasy X.

[Wedge009]

For what it's worth, my changes are submitted in audacious-media-player/audacious-plugins#211

[kode54]

I'm not sure what the licensing should be, since I derived it from Audio Overload. I should have put Audio Overload's license in the repo, and will do so shortly if I can locate the correct license for it.

The major problem for these PSF formats is:

1. PSF1 works with minimal fuss, since the runtime is fairly generic. Alternate players have been easily developed, compared to...
2. PSF2, which requires hacks up on hacks, because a bunch of the available rips have bad crap in them that assumes the memory layout behavior of the actual console, to the T. Wherever AOPSF may still be deficient, feel free to fix it, if you can.

Yet another alternative is the Play! emulator, since it takes care of the high level emulation of the BIOS functions way better, but may still have problems, and also have the problem of how to restructure the code into a library for use as a PSF/PSF2 player.

[kode54]

I don't mind forking it, but I'd like to get the changes upstreamed. And I will stick to the license of upstream for any changes I contribute to them.

[kode54]

If you want to look into some issues upstream as well, here are some "bad" PSF files.

bad-psfs.zip

The "BAD" ones are just horrible timed, maybe badly made. The fuz-* ones are fuzzer output, and all of them crash the player.

[kode54]

Fixed the fuz-*.psf files crashing, due to missing BIOS functions, but they still don't play anything.

[Wedge009]

I was about to push my own patches. They are all on Play!'s side, so maybe they should go to the Play! repository instead?

I also separated the patches rather than trying to cram everything into one file.

I'm also finding numerous similar problems in both PS1 and PS2 code. At this point one might end up trying to patch the entire emulator for something that only bad/corrupt files will trigger.

Highly Experimental will still play these.

---

Oh I see, you've actually implemented the BIOS functions rather than just guard against the crashes. I really think something of that magnitude ought to go into Play! itself, that would be an improvement everyone can enjoy, then.

[kode54]

I'll try to slice these up and file them as commits against Play! itself.

[kaniini]

I have been working on a new PSF/PSF2 replayer in Rust as a weekend project. I would prefer we move from OpenPSF to that.

[kaniini]

it is now open sourced, and includes an audacious plugin: https://github.com/kaniini/upse-ng

[kaniini]

(also, like Play! it can play the original FFX rip just fine)

[kaniini]

regarding Square IOPSOUND driver/replayer: it uses threads for every single instrument, and synchronizes on every tick using an IOP-provided semaphore. thread scheduling must simulate PS2 behavior exactly for playback to be correct.

[kaniini]

my plan so far is to work through the entire PSF set, comparing reproduction on real hardware (digital audio captured by TOSlink mod on PS1) to emulator output. goal is for emulator output to be bit-exact to the TOSlink output on TOSlink-modded PS1 and stock PS2.

once there is enough proven conformance, i will move the audacious plugin into audacious-plugins and delete the openpsf one.

[Wedge009]

It seems like a good alternative, given that it's purpose-built specifically for audio and doesn't carry all the emulation baggage that Play! does. I went through the PS2 tracks that OpenPSF fails on, and it similarly plays them all just fine. I don't have an objective means of comparing whether it's more faithful to the real PS hardware than Play! is. If only because this is far more streamlined than the Play! hack I did, I'd recommend this project over mine.

I did have to run sudo ldconfig to get the Audacious plug-in to find the base library before it would work, however.