Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Monkeys Audio #18

Closed
kayabe opened this issue Mar 19, 2018 · 6 comments
Closed

Monkeys Audio #18

kayabe opened this issue Mar 19, 2018 · 6 comments

Comments

@kayabe
Copy link
Contributor

kayabe commented Mar 19, 2018

would you mind adding support for ape, Monekys Audio?

@mackron
Copy link
Owner

mackron commented Mar 19, 2018

I assume you mean decoding of .ape files? So having a Monkey's Audio decoding backend which uses their official SDK? I won't be doing that because of a few reasons:

  1. I have a lot of projects I want to work on, but not enough time to work on them, yet this is the first I've even heard of Monkey's Audio. It's just not high on my priority list.
  2. Although it sounds pedantic to some, one of the big "features" (if you can call it that) of mini_al is it's clean licensing. Everything in this repository is in the public domain. When you starting mixing in projects with their own license conditions like this one it just gets messy and confusing and just adds unnecessary licensing friction.

How widely used is Monkey's Audio? As I said earlier, this is the first I've heard of it!

Thanks for your suggestion!

@kayabe
Copy link
Contributor Author

kayabe commented Mar 19, 2018

https://github.com/evpobr/libape

this project is using MIT License, does it make a difference?

@mackron
Copy link
Owner

mackron commented Mar 19, 2018

It helps. I'm not going to outright reject the idea, but there's still a few practical problems. There's still a lot to do in mini_al (not to mention in my other projects I want to get done!), and that stuff is just higher priority right now (macOS/iOS support, improved format conversion, submixing, 3D audio, optimizing, etc, etc). Also, keep in mind that decoding isn't actually the main goal of mini_al - it's mainly intended to simplify lower-level audio playback and capture across the major platforms.

For anybody out there whose listening, is there anybody else who wants/needs this?

@r-lyeh
Copy link

r-lyeh commented Mar 19, 2018

Some (personal) remarks :

  • APE is a lossless codec, about 2%/5% better than FLAC. (*)
  • APE is slower to encode/decode than FLAC, though. (*)
  • APE uses a custom license that most if not all companies should evaluate very carefully. It is one of the main reasons is banned from Linux distros IIRC.

In my opinion you could make a wrapper for the SDK and could give it some decoding support in a dr_ape.h file, but seems useless to me.

I'd better ask @kayabe why he needs APE and can't use FLAC instead :)

See: http://wiki.hydrogenaud.io/index.php?title=Lossless_comparison

@raysan5
Copy link
Sponsor Contributor

raysan5 commented Mar 19, 2018

macOS/iOS support, improved format conversion, submixing, 3D audio, optimizing, etc, etc

I think this is already a loong list...

@kayabe
Copy link
Contributor Author

kayabe commented Mar 19, 2018

i understand, i think you should prioritize optimizing then

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants