-
|
I've been trying to figure out whether I can do things like get metadata for and convert audio files between different formats in my C# project and frankly I've found it difficult to find any recent information - most Q&A is from years ago and things have moved on. CSCore wants to use .NET Frameworks and NAudio seems very Windows-specific. Is there any kind of audio library built into .NET itself yet, say in .NET 9? Like, can I somehow open an MP3, get its metadata, and save it out as a WAV without using NAudio? And is it possible to do it in a cross-platform way? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 6 replies
-
|
No. Audio is relatively a high-level and mixture of area. The built-in libraries doesn't have any functionality or media processing. System.Drawing is a wrapper of OS functionality and outdated. |
Beta Was this translation helpful? Give feedback.
-
|
And why don't MS provide this high-level library, then? I mean .NET is meant to be a general purpose framework and it basically has no good, maintained audio library now (NAudio is pretty much unmaintained as is everything else). I'd say it's a pretty big gap in .NET's functionality. |
Beta Was this translation helpful? Give feedback.
-
|
Why isn't library X part of .NET is a really long generic answer that involves how .NET came to be, what it's primary purpose was, how it evolved, and where it's most used. That combination of history, customer base and usage hasn't led to a path where audio processing was deemed to be an important first-class citizen. If there aren't many audio libraries in the ecosystem (like NAudio) then it might mean the ecosystem hasn't deemed it important enough to be a first-class feature. We don't build libraries just because there's a gap. There needs to be evidence and demand that it makes sense to do so at the cost of not doing other features. PS: I don't know of any other language ecosystem that has audio built in. If there are rich libraries for doing audio in python (as an example), then it might mean lots of devs are using that ecosystem for audio processing. |
Beta Was this translation helpful? Give feedback.
-
|
It's not at the cost of not doing other features, though. That's what annoys me about the modern world. Microsoft had an operating income of $109.4 billion in 2024. They could just hire another 100 devs to work on audio in .NET and barely notice the difference. It really sucks that everything has to be purely "maximize profit for shareholders". And yeah I know we've moved on to politics here. But whatever. 😄 |
Beta Was this translation helpful? Give feedback.
-
|
I wish that's how big companies worked! |
Beta Was this translation helpful? Give feedback.
-
That's not how things work, at the small or large scale and in software development or otherwise. If it takes 10 people 1 month to build a house, you can't just hire 30 more people and get it done in a week. It also doesn't mean that you can now build 4 houses in 1 month instead. There are fundamental issues with logistics, scaling, various bottlenecks that start to show as you try to expand, etc. In many cases, trying to throw more money, people, and/or resources at a problem can actually cause it to slow down because of these issues and the increased complexity of keeping everyone up to date and in the loop. Audio, graphics, and other similar things are also areas that are very hard to do "correctly". The landscapes are often rapidly evolving/shifting and there is a whole lot of specialization and unique considerations to handle, especially as you compare the very broad range of scenarios that such support might get used. Trying to make it cross platform (Windows, MacOS, WASM, Android, iOS, Linux; not to mention the various unique differences across Linux distributions as it doesn't have its own "stable" foundational API to build on top of itself) adds an entirely new set of complexities; and gets into much the same reason you don't end up with unified graphics stacks for DirectX vs Vulkan; you rather instead get some more limited and specifically designed engine built on top that has its own opinions an limitations (with many different competing variants, with there not being one true or clear "winner"). You then often lose stability over time and many of the other base guarantees that APIs .NET ships as built-in try to strive for It's not a simple problem, there is no simple solution even if you have and are willing to spend money. It's one of the many scenarios where it is likely best left to the experts already trying to build and support such libraries, and for the binding authors that provide .NET wrappers over such libraries when they aren't written for .NET directly. |
Beta Was this translation helpful? Give feedback.
-
|
That's as maybe but when you already have something like NAudio which is a decent library that works (at least for somethings) cross-platform and a guy saying he'd like to maintain it but he isn't being paid to do so, it wouldn't hurt if MS could just offer to pay him a wage and give him a few devs to help .NET be better in general. |
Beta Was this translation helpful? Give feedback.
Why isn't library X part of .NET is a really long generic answer that involves how .NET came to be, what it's primary purpose was, how it evolved, and where it's most used. That combination of history, customer base and usage hasn't led to a path where audio processing was deemed to be an important first-class citizen. If there aren't many audio libraries in the ecosystem (like NAudio) then it might mean the ecosystem hasn't deemed it important enough to be a first-class feature.
We don't build libraries just because there's a gap. There needs to be evidence and demand that it makes sense to do so at the cost of not doing other features.
PS: I don't know of any other language ecosystem th…