Alternate CD player software for PSX

[djfreethrow909]

Hey everyone, please redirect me if this is the wrong place for this question. Is anyone aware of alternate CD player software for PSX (i.e. besides the built-in CD player capability)? I'm looking for something that can increase or decrease the playback speed (pitch up/down).

I'm new to PSX dev and what got me interested is the feature of Music 2000 where the disc can be taken out such that an audio CD can be loaded.

[gwald]

I don't know of any.
But I think it wouldn't be that hard to code that feature, to speed it up, you just remove samples, to slow it down you just duplicated them. I'm not 100% sure that's correct I've never done it.

[djfreethrow909]

Thanks for your responses. Ideally, I'd like to increase/decrease playback speed as the CD audio streams though, instead of using Audacity before burning my CDs.

I'm still getting up to speed here with PsyQ and some of the examples shown in https://github.com/ABelliqueux/nolibgs_hello_worlds, but I'm not sure that libcd would suit my use case, due to the limitation described in LibOver47 page 173 (Ch.11-3): "An audio sector may be played by the CdlPlay command and cannot be read as user data."

However, I'm also not sure libspu would work either: the docs only describe working with VAG encoded files, as I understand are used for in-game audio.

I'd like to use the libspu processing flow described in Ch.16, but with streaming CD audio instead of VAG encoded audio. Is this possible? Maybe I'm missing something.

The SCPH-101 (PSone) model CD player let you apply reverb when playing back audio CDs, so I'm hopeful there's a way to implement something like what I'm describing.

[gwald]

I'm not familiar with pysq's low level libraries, but I guess you would be managing everything yourself.

So, I would guess you would read the CDROM, as in low level data ie raw data bytes from sectors.
You would then maintain a circular array or list, a buffer to store the data. I don't think there would be any conversion involve or very little.
Then you would set up a callback function which populates the hardware audio buffer with what's in your audio buffer.

I would imagine it's a similar process to how SDL does it anyway.. ie like this:

Not sure how help that was, but that's what I would be looking at.

[nocash]

Are you sure that the SDL thing works on PSX? I have never heard of PSX software that could support long filenames, or play uncompressed wav files. The traditional PSX libraries certainly can't do such things.

Hardware-wise, without libraries and SDK's, it should be all very easy, with some quality tradeoffs and some fairly obvious issues to be taken care of. Reading audio data as normal binary sectors actually doesn't work (or at least not from unlicensed discs, and I think a modchip won't help either), but it should be possible to DMA the CD-DA audio capture from SPU to main ram, and then inject it back to the SPU reverb memory with added/removed samples to match the desired pitch. That with the disc spinning at double speed, and issuing play/pause whenever the memory buffer gets full/empty. But there aren't so many PSX devrs who know how to do low-level stuff (and most of them are unlikely to be interested in pitch changes).

Coincidentally, I am currently actually working on stuff like that. My mp3 player for GBA has an optional PITCH constant in the source code, and the (yet unreleased) next version does also have GUI with some simple pitch control settings. After finishing the GBA version, plans are to port it to NDS, DSi, 3DS, and finally to also make a MIPS version for PSX, which would be supposed to support mp3 files from CDROM, and certainly also to play normal CD-DA audio tracks. If there's enough spare CPU time, then I might implement the mp3 pitch change feature on PSX, too. And maybe also try to implement it for CD-DA discs, just for fun.

Now my questions: What is a pitch change feature good for in practice, and how should it be implemented to be useful?

Playing a record at double speed, I think that does just sound silly in most or all cases (especially if it has lyrics).

More moderate minor changes to the tempo might be good for tuning the mood of the recording. I don't know if that's a common practice, with people like DJs actually doing such things, and if yes, I guess that might vary per genre?

And finally, there seems to be something called beat matching, ie. to play two records at same speed, either for fadeover purposes, or for longer periods.

What I have currently implemented is changing the pitch via up/down buttons, in 1% steps, ranging from 92% to 108%.
While that's working as a neat gimmick, I haven't yet talked about that with other people, and I don't know if anybody would consider it as a useful feature...?

And for beat matching, I don't really know what requirements that'd envolve. The stepping might require a much finer precision than 1%, and the range might be required to be wider than +/-8% ...?

[djfreethrow909]

Hey nocash, thanks for your reply. You’re exactly right: this kind of feature is useful for DJing, which is my intended use case. It's cool to hear you were coincidentally working on something similar!

Looking at the Pioneer CDJ-2000NXS2 (a standard DJ CD player), there are a few Tempo controls of interest:

• Reset Button: return audio to its original, unmodified tempo
• Slider: changes speed of currently-playing audio in real time. The slider's scale and precision change depending on the state of the Mode button described below.
• Mode Button: changes the scale of the tempo slider, in units of ±%. Different states are ±6%, ±10%, ±16%, and WIDE (±100%). The precision (step change %) varies depending on the current mode as follows:

Tempo Modes:

• ±6%: steps of 0.02%
• ±10% and ±16%: steps of 0.05%
• WIDE: steps of 0.5%

Even just to be able to have ±6% in steps of 0.02% would be great. A few additional notes:

• the classic "pitch adjust" on a record player affects both pitch and tempo. It sounds like this is what you've already implemented for GBA.
• an ideal tempo control is a time stretch which maintains the original pitch
• separate from tempo, a DJ would also be interested to have separate pitch control (in units of semitones) to change the key of a song while maintaining the original tempo.

ffmpeg actually implements a tempo scaling audio filter in C: https://ffmpeg.org/doxygen/7.0/af__atempo_8c.html. However, it makes use of floats and doubles, which I understand is difficult for PSX based on what I've read so far in the forums, so it would have to be reworked quite a bit.

Obviously there's a lot here and I'm completely new to PSX, but I'd be eager to work on something like this. I'll probably get started with some of the examples and then looking into DMAing the SPU for transfer to the main memory as you suggested.

[nocash]

Thanks! Having the +/-6% with 0.02% stepping specs is very good to know to get an idea how it should work. The Mode button does also sound like a useful addition.

My current GUI is simply using a text based list with 17 pitch settings. For the 0.02% example, I would need to expand that to 600 settings, and use some kind of on-screen slider or dial instead of the text based list. And I am not too sure if would be possible to comfortably control the slider with the DPAD, a touchscreen or analog joysticks might be more suitable for that, but the GBA doesn't have that.

Yes, the way how I am doing it does change both pitch and tempo.

I had never thought about the possibility to change them separately - that would somehow require to split the audio signal into separate frequencies, and then rebuild the audio signal from scratch up - I am definetely not familar with the mathematics for such things. And even with existing source code, it would be probably an extreme challenge to implement that on a 32MHz CPU, especially on one with limited caching and not-too-fast multipliers.

If you are lookig for hardware specs, I have that stuff described here https://problemkaputt.de/psxspx-contents.htm with info on SPU, DMA, and CDROM. From what I remember, the CDROM audio seek isn't too accurate (audio has no sector headers, only the subchannel data, which may or may not exist on all sectors). So, if you alternate between play/pause, that might require some creative workarounds to ensure that play resumes on the correct sector : )