I just need PCM data out of those to feed it to OpenAL
I just need PCM data out of those to feed it to OpenAL
RThat's just stupid
Aah. i'm not aware of a single library to do that, but it depends what you need. if you want vorbis, i can recommend
StbVorbisSharp
NI guess my route is writing my own
Ayou could do that, but best of luck implementing MP3.
that's a treasure trove of hell
that's a treasure trove of hell
NNAudio luckily has NLayer which can decode Mpeg Layers 1 to 3
RNVorbis is one I've used in the past, plus a little helper function to convert the samples to PCM data
Nand yeah NVorbis as well
NWAV files seem to be the easiest since I only need to worry about encoding
Aehh, personally i can recommend
StbVorbisSharp over nvorbisNI'll check that out
Nalthough it would probably be cool if .NET actually had libraries 
Atechpizza will disagree i'm sure but it just has a very simple to use api
NI noticed stride just uses ffmpeg and converts audio to PCM during their build step
Awell at some point in the future i plan to add vorbis and mp3 streaming to mixr.
mixr is written in rust but I wrote a c# wrapper for it
mixr is written in rust but I wrote a c# wrapper for it
Agood lord. there are 1000 better ways to do that, lol
Nthere are
RThere is also midisharp if you're looking for MIDI files
RWhat would be really nice is if .NET had a standard API for showing message boxes and file dialogs
Rinstead of having to reach out to platform-specific APIs directly
Ait does. you just have to use ETO.Forms
RI believe you can also convert MUS files from doom to C#
A
RAccessibility requirements
NI guess I have to push my engine without audio for now 
Nseems daunting to add audio support and I don't want to duck tape some old library
RIt's probably more worth it to them for them to use the inbuilt ones for accessibility reasons which would be significantly easier and more consistent and reliable for them
RI hate apps that don't use platform-native dialogs
RGIMP is really annoying for me on Windows since it uses the GTK file picker instead of the Win32 one
RI hate ones that use the windows dialog
REspecially that folder browser one
Nthe really old one?
Nthats just a square window?
RYes
Noh man I feel you
RThat you just can't paste a path into
RThe Windows one is really elegant for me since I can always type in the file name I want to open and it auto-completes
Rinstead of needing to read through the list of existing files (which the gtk one makes you do in some cases)
NI feel like that thing existed way back in the DOS era of windows
NI also don't like non-native looking dialogs
RMe neither
RI like apps being consistent with the OS's theme
RBut anything is better than that dialogue
Ntrue
Nthats why I had Windows App SDK support on my engine
RAnd I don't like writing my own dialog systems (especially file pickers), that's a lot of needless work when your OS has an API for that.
RI actually hate the modern windows win32 theming
Nas for Linux, I had my friend make bindings for
nativefiledialogs-extended https://github.com/Speykious/NativeFileDialogs.NETGitHub
Full .NET wrapper for NativeFileDialogs (Extended). - GitHub - Speykious/NativeFileDialogs.NET: Full .NET wrapper for NativeFileDialogs (Extended).
ROh I do too
RThey removed context menu item highlights in Windows 11