141–150 of 201 posts
Tip for those who are looking at the compression ratios thinking "so what?": look at the run-times. It's a minimum of 3x faster than its contemporaries.
It seems the world made a collective yawn about flac. Hard to imagine that would change much with a new format. I personally keep everything in flac, but Bandcamp is seemingly the only service where that is a given.
There's no source? It's very hard to take this seriously without source code... He explicitly says it's not SIMD, which is nice because it rules out a way of cheesing it, but still...
There are some areas that I follow as-it-develops, but codecs and data compression is one that I'll use when ready. Still awaiting widespread av1 support/adoption.
The area most needing improvements IMO is with Bluetooth, especially Apple's support of codecs (where they're dropping support that worked in older macOS versions).
There's no source? It's very hard to take this seriously without source code... He explicitly says it's not SIMD, which is nice because it rules out a way of cheesing it, but still...
Some of the SIMD optimization make compilers automatically. The others can be manually. These speeds can be obtained without using SIMD. Then there may be more with manual SIMD. I think this is what should be loved.
There's no source? It's very hard to take this seriously without source code... He explicitly says it's not SIMD, which is nice because it rules out a way of cheesing it, but still...
At this stage, what is taken seriously is quite personal. If the source code is a requirement to take it seriously; MS Windows, MS Office, Adobe, Autodesk, Oracle, Winrar and thousands of more wonderful software should not be taken seriously. Some of the SIMD optimization make compilers automatically. The others can be manually. These speeds can be obtained without using SIMD. Then there may be more with manual SIMD.…
Apples and oranges. I don't need word processing software to be open source to understand how it works. A proportedly novel compression algorithm is a different story...
I can be totally honest with you: FLAC being open source is more valuable to me than any performance benefit you could ever possibly offer over it. It only becomes interesting if I can actually read the code and see what you did.
I am genuinely interested in what you've done here, and I sincerely hope you publish it.
Earlier quoted context omitted.
Honestly, if they provided 100mb source code, would you read it and then compile it? Source code alone doesn't make it secure.
Irrelevant. Convenient or probable doesn't matter. What matters is possible vs not possible. All it takes is one person somewhere who wants to look something over, and they heads-up the rest, and then many others do verify. And that initial one does exist even though it's not you or me, the same way the author exists, the same way that at least once in a while for some things it is you or me.
Yall should really have a look at his lossless image format. That has a spectacular compression:speed ratio. https://encode.su/threads/4025-HALIC-(High-Availability-Loss... What interests me the most is the memory usage.
Cool toy and a nice piece for the CV perhaps, but it is difficult to take it seriously if you refuse to offer source code or a implementable specification. I would give you the benefit of the doubt that it might just be code shyness or perfectionism about something in its early stages, but it looks like the last codec you developed (“HALIC”) is still only available as Windows binaries after a year. I struggle to see…
Maybe it’s just me, but every lossless codec that’s: 1. Not FLAC 2. Not as open-source as FLAC comes across as a patent play. FLAC is excellent and widely supported (and where it’s not supported some new at-least-open-enough codec will also not be supported). I have yet to see a compelling argument for lossless audio encoders that are not FLAC.
Earlier quoted context omitted.
At this stage, what is taken seriously is quite personal. If the source code is a requirement to take it seriously; MS Windows, MS Office, Adobe, Autodesk, Oracle, Winrar and thousands of more wonderful software should not be taken seriously. Some of the SIMD optimization make compilers automatically. The others can be manually. These speeds can be obtained without using SIMD. Then there may be more with manual SIMD.…
> MS Windows, MS Office, Adobe, Autodesk, Oracle, Winrar and thousands of more wonderful software should not be taken seriously. Apples and oranges. I don't need word processing software to be open source to understand how it works. A proportedly novel compression algorithm is a different story... I can be totally honest with you: FLAC being open source is more valuable to me than any performance benefit you could ev…
I am developing HALAC and HALIC as a hobby and I don't expect everyone to use them. I'm happy when I can get good results, and it's bad when I can't. I say this as someone who has been dealing with data compression for 9 years.
Tip for those who are looking at the compression ratios thinking "so what?": look at the run-times. It's a minimum of 3x faster than its contemporaries.
It seems the world made a collective yawn about flac. Hard to imagine that would change much with a new format. I personally keep everything in flac, but Bandcamp is seemingly the only service where that is a given.
Yall should really have a look at his lossless image format. That has a spectacular compression:speed ratio. https://encode.su/threads/4025-HALIC-(High-Availability-Loss... What interests me the most is the memory usage.
[flagged]
Not everyone supports their political representatives.