lyra VS elasticsearch-py

Since Ballard's codec is "AI" based, can you add google's lyrav2 ( https://github.com/google/lyra ) and Facebook's/meta EnCodec ( https://github.com/facebookresearch/encodec ).

Also I don't seem to be able to access your page, so there might be error.

Finally, when doing opus comparison it's good now to denote if it is using Lace or NoLace decoder post processing filters that became available in opus 1.5 (note, this feature need to be enabled at compile time, and defying decode a new API call needs to be made to force higher complexity decoder) . See https://opus-codec.org/demo/opus-1.5/

I've thought about doing something similar for google's voice compression lyra https://github.com/google/lyra

edit: It seems Lyra is opensource https://github.com/google/lyra

1) https://github.com/google/lyra/releases/tag/v1.3.0

Very impressive.

It'd be interesting to see what the lift would be to get encoding & decoding running in webassembly/wasm. Further, it'd be really neat to try to take something like the tflife_model_wrapper[1] and to get it backed by something like tsjs-tflite[2] perhaps even atop for example tfjs-backend-webgpu[3].

Longer run, the web-nn[4] spec should hopefully simplify/bake-in some of these libraries to the web platform, make running inference much easier. But there's still an interesting challenge & question, that I'm not sure how to tackle; how to take native code, compile it to wasm, but to have some of the implementation provided else-where.

[1] https://github.com/google/lyra/pull/89/files#diff-ed2f131a63...

[2] https://www.npmjs.com/package/@tensorflow/tfjs-tflite

[3] https://www.npmjs.com/package/@tensorflow/tfjs-backend-webgp...

[4] https://www.w3.org/TR/webnn/

You can find an Android, Linux and macOS app here: https://github.com/google/lyra/actions/runs/3156735950

Here's the repository: https://github.com/google/lyra and it's licensed under Apache.

FD: I have a friend who works at Elastic, though he doesn't really colour my opinions of things.

> Firstly, dick moves like this: https://github.com/elastic/elasticsearch-py/pull/1623

I understand that this is unpopular, but you can make a very strong argument that it's to prevent weird errors in the future. I'm also guilty of littering my code with Asserts to ensure the universe is working fine.

The alternative is to allow it to work and then you end up with weird issues like when you connect mysql client to mariadb server (and vice-versa): https://stackoverflow.com/questions/50169576/mysql-8-0-11-er...

> Secondly, I don't buy the argument from Elastic any more. Yes, the ethical thing to do when you're making money from someone's work is at least contribute back. At the same time though, they're making money from packaging it up and selling it _as a service_. That "as a service" part is where they're making the bucks.

That's just an opinion, yes they have a service, and yes it competes with Amazon. Is it cool for Amazon to take a body of work and sell it without supporting it? Are amazon actually supporting it? Is it the same as Elastic using Lucene? (not really because Elastic submits a the majority of fixes to Lucene, but, you get it).

it's kinda gray, I'm sure Amazon thinks they're the good guy, but it's hard for me to look at Elastic as the bad guy in all this.

Oh man, https://github.com/elastic/elasticsearch-py/issues/1734 is a disappointing read. I know ES wants to save their business, but alienating users isn't exactly the path to success.