Independency (to NAudio) request on both documentation and interface

[Blealtan]

As this project (NLayer) is a fully managed implementation of MPEG decoder, I tried to use it in a .Net Standard project, but soon find no documents presented for NLayer itself, only a small sample showing how it works with NAudio. That's not what I want, so I looked into the source code, trying to figure out how itself works; but later I find that to use the PCM data decoded by NLayer, I have to manually separate stereo channels, while the backing decoder is all internal which I can't directly use.

The reason I came to this project is that I need a platform independent MP3 decoder; but the only "expected" way to use this is through NAudioSupport. So if I can make use of NAudio, which is Windows only, WHY take the trouble use NLayer? Ridiculous. This project, as an fully managed library, should work well by itself; but there are few interfaces and runtime configurations for me to use it directly, as well as few explanation on the interface.

I hope this platform independent project will become "independent" (at least be able to use by itself) to the platform dependent NAudio; in the meantime, may anyone figure out how may I use NLayer itself to decode a single stereo mp3 to two separate channels? If currently no way, it seems I'll have to use mono samples for my audio analysis.

[ioctlLR]

Such hostility! It's ridiculous you'd make such claims when NLayer supports stand-alone use via the MpegFile type. Maybe next time you should ask questions instead of taking out your frustration on those that can help.

As an aside, you should always expect to separate stereo channels manually from the PCM data returned by any decoder. That's how PCM data is encoded, per the standards.

[Blealtan]

Of course I know what MpegFile type is doing. I've looked into the source code and even compared the full implementation with other libraries, including libmad, mpeg123 and which you're porting, JavaLayer (ioctlLR says: NLayer was completely re-written a few years ago and no longer has any JavaLayer code in it).

I'm complaining about the API design and documentation. You provided PCM data in only single precision floating point numbers, only with stereo channels mixed up which is NOT "any decoder" doing (EDIT: to be clear, not every decoder provides final PCM only), and make everything behind the MpegFrameDecoder internal. I bet why you only provide standard floating-point PCM is that, NAudio needs this only, right? As to documentation, go through the source code, tell me is there any document provided?

By the way, I think I should clarify that my last paragraph in my issue is just complaining, not asking for help; perhaps I'd better make a fork by myself to serve my need, since you think only floating-point standard PCM is enough, I assume from your words.

Sorry for taking your time.

[ioctlLR]

If you'd like to submit a pull request to add discrete channel output and/or 16-bit sample support to MpegFile, please do so. We can certainly take a look and try to have a constructive conversation about it.

For the record, aside from the fixed-point decoders (primarily libmad; note that they still have to convert to the output sample format), all MP3 decoders use single-precision float samples internally. NLayer just leaves the conversion to the caller, while the others do it for you.

Likewise on the "stereo channels mixed up" item, PCM data always has that format when sent to an output device. NLayer was really meant to provide audio for playback, so that format made the most sense. Getting discrete channels is possible, so I look forward to seeing what you come up with.

Given your hostile tone, I don't think further commentary is appropriate. If you'd like to continue the conversation, please do so via a pull request that makes the changes you would like to see. I'm now locking this thread.