logging sound output to uncompressed wav file

[WhiteMagicRaven]

as title says logging sound output to uncompressed wav file

I mean emulator to be able to write uncompressed wav file in exact output quality (parameters) of specific console output sound format. if console output audio at 22khz write 22khz audio. I wanted it mainly for sega saturn

see also devmiyax/yabause#862, shimazzz/SEGASaturnEmulator-SSF#22

[CasualPokePlayer]

I'm not sure what you're exactly asking for. Are you asking for sound before it's resampled to 44.1KHz? Note that just resampling wouldn't affect the quality of the audio noticeably. And if that is what you are asking for, that probably isn't going to happen any time soon outside of maybe some core specific hacky tool.

[WhiteMagicRaven]

i mean write audio to wav file in format that emulator outputs

[shenef]

I'm pretty sure you can already do that using a custom ffmpeg command while recording. But if BizHawk resamples it automatically for output on your PC, you will probably have to overwrite the sample rate via that custom ffmpeg command.

[CasualPokePlayer]

You can just use the provided WAV writer.

[Morilli]

I'm pretty sure bizhawk will force a samplerate of 44.1khz for that as well. I would also like to see core samplerates not get changed for recording at the very least.

[CasualPokePlayer]

The frontend actually doesn't do any sort of "forcing" of sample rate per se but rather it will expect cores to resample to 44.1khz and the frontend will make the assumption that is being done. Every core will need modifications if you want a way to obtain the pre-resampled audio (which can be messy often times, especially for cores which do all resampling on unmanaged side or might have that integrated within their sound emulation).

Also this would be useless half the time given a lot of older consoles have extremely high sample rates which would likely be internally resampled (with questionable quality) by whatever audio player you use if it's even able to play back the audio.

[Morilli]

The frontend actually doesn't do any sort of "forcing" of sample rate per se but rather it will expect cores to resample to 44.1khz

That is pretty much the definition of forcing; the frontend will not function if the sample rate is not correct, thereby effectively forcing the samplerate to be 44.1khz.

Every core will need modifications if you want a way to obtain the pre-resampled audio

That may be true and in my opinion and unfortunate cause of samplerates being enforced per-core instead of there being a system that either takes whatever sample rate it is given or resamples for audio output only.

Also this would be useless half the time given a lot of older consoles have extremely high sample rates which would likely be internally resampled (with questionable quality) by whatever audio player you use if it's even able to play back the audio.

I don't see how providing original sound samples can be considered useless. Why is video provided completely unmodified, but audio isn't? fwiw I'm not aware of consoles with very high samplerate, but especially in those cases resampling to a lower samplerate will lose information, no?

[CasualPokePlayer]

Right, I just mean that the frontend isn't doing any resampling.

Which even so, the frontend probably shouldn't be for a multisystem emulator, different consoles need different resampling methods for optimal quality. Older consoles would fare much better with band-limited synthesis blip_buf provides. New consoles would fare much better with speex's resampler. Consoles might even have multiple audio sources with different rates or changing sample rates within a frame, giving more reason for cores to do resampling.

Video isn't always spared from modification to be fair. Under audio sync you will get video frames skipped/duped to match up with audio in order to pertain a constant framerate. If you disable audio sync, you will have audio stretched/shrunk to try to fit into every video frame. BizHawk in general does not like variable framerates, and isn't properly equipped to handle them.

Losing information due to downsampling is subjective. Perhaps you could make some case we should be resampling to 96KHz (which is "the best" quality audio), or better yet 48KHz as that's more common, but even so it's a miniscule difference. Human ears are limited, we can't hear past ~20 KHz (and due to Nyquist theorum you need to record double that). And accordingly actual speakers typically output at best at 48KHz. Going to pure console sample rates for older consoles like the NES's ~1.79MHz sample rate or the GB's 2MiHz sample rate goes way past those limits, audio players will refuse to play them or internally resample (with questionable quality) anyways.

Only real use I can see is some sort of analysis of samples outputted by the console? Perhaps nice but that might be better off as per core tools.

[Meerkov]

If I understand the reason behind the request, it's probably to rip high-quality music files from the disk... In which case, I'd suggest a workaround of finding a utility that can rip the original files from the disk, so you know you're getting the exact original quality.

I agree with casualPokePlayer here. If the audio doesn't sound right at 44.1khz, getting the original sample rate is not going to fix that. The original files almost certainly were recorded/stored at 44.1khz or half that. In my experience with Playstation 1 music files, the original files are likely lower fidelity than the forced output anyway.