Live data from Hacker News

New Ultra Fast Lossless Audio Codec (HALAC)

hydrogenaud.io

131–140 of 201 posts

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#131
post #105

Earlier quoted context omitted.

Doesn't Windows come with a sandbox built-in nowadays?

No

It does so long as you have Pro or higher: https://learn.microsoft.com/en-us/windows/security/applicati...

It's actually decently handy. Just keep in mind no sandbox is perfect.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#132

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.

FLAC’s compression algorithm was pretty much garbage when it came out, and is much worse now compared to the state of the art. Even mp3 + gzip residuals would probably compress better.

FLAC doesn’t support more modern sampling formats (e.g. floating point for mastering), or complex multi channel compression for surround sound formats.

There just isn’t something better (and free) to replace it yet.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#133

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…

You are right about this. But there are things I should add to Halic and Halac. When I complete them and realize that it will really be used by someones, it will of course be open source.

You got that backwards buddy. Nobody will use them so long as they remain closed source like this.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#134
post #5

I love how some announcements of developments still occur in good old-fashioned forums; it really warms my heart to see that. Kudos to the author for the hard work!

Honestly this is one of the best technical audio forums. I always really appreciated how they take their rules seriously, like

> TOS 8. All members that put forth a statement concerning subjective sound quality, must - to the best of their ability - provide objective support for their claims. Acceptable means of support are double blind listening tests (ABX or ABC/HR) demonstrating that the member can discern a difference perceptually, together with a test sample to allow others to reproduce their findings. Graphs, non-blind listening tests, waveform difference comparisons, and so on, are not acceptable means of providing support.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#135

Earlier quoted context omitted.

> I/we want to keep my/our primary fork fully ours The "primary" fork is the one that the community decides it to be, not what the authors "wants". Does it really matter what is the "primary fork" for those working on something to "scratch their own itch"?

Hence I said my/our primary fork, not the primary fork. If I were in the position of releasing something⁰: the community, should one or more coalesce around a work, can do/say what it likes, but my primary fork is what I say it is¹. It might be theirs, it might be not. I might consider myself part of that community, or not. It should be noted that possibility of “the community” or other individual/team/etc taking a “…

I don’t get it. What the community does has no bearing on your fork, so why do you care? You can open source it and just not accept patches. Community development will end up happening somewhere else, but who cares?

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#136

[flagged]

My works are fully cross-platform. There is no restrictive situation. I also prepared Linux and ARM versions for HALIC, but I didn't compile new versions because it didn't get much attention. When my Linux test machine is ready(crashed), I compile the Linux version of HALAC.

> When my Linux test machine is ready(crashed)

In 2024, you don't need a separate machine to run different OSes

qemu is your friend

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#137

Earlier quoted context omitted.

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.

FLAC’s compression algorithm was pretty much garbage when it came out, and is much worse now compared to the state of the art. Even mp3 + gzip residuals would probably compress better. FLAC doesn’t support more modern sampling formats (e.g. floating point for mastering), or complex multi channel compression for surround sound formats. There just isn’t something better (and free) to replace it yet.

> There just isn’t something better (and free) to replace it yet.

Apple's ALAC (Apple Lossless Audio Codec) format is an open-source and patent-free alternative. I believe both ALAC and FLAC support up to 8 channels of audio, which allows them to support 5.1 and 7.1 surround. https://en.wikipedia.org/wiki/Apple_Lossless_Audio_Codec#His...

These are distribution formats, so I'd be surprised if there were demand for floating-point audio support. And in contexts where floating point audio is used, audio size is not really a problem.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#138

Earlier quoted context omitted.

This argument comes up reasonably regularly. No, the majority of the world does not download and run binaries from non-reputable sources. The distinction between reputable and non-reputable varies, but broadly easily spoofable user uploaded content falls into the non-reputable. Most people download software from trust worthy websites like the official chrome website. Indeed, the fact that people are continually scamm…

You are simply toeing the line of corporate propaganda, that says people must always submit to centralised authority instead of exercising their own judgement. That is what is leading us to dystopia. We are not "pretending", we are simply stating that the magnitude of risk is absolutely tiny. Insecurity is freedom. Don't let them take away the latter in the name of security. "There is nothing to fear but fear itself.…

How is sharing source "submitting to a centralized authority"

I don't run any binaries if i can help it

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#140

Earlier quoted context omitted.

Hence I said my/our primary fork, not the primary fork. If I were in the position of releasing something⁰: the community, should one or more coalesce around a work, can do/say what it likes, but my primary fork is what I say it is¹. It might be theirs, it might be not. I might consider myself part of that community, or not. It should be noted that possibility of “the community” or other individual/team/etc taking a “…

I don’t get it. What the community does has no bearing on your fork, so why do you care? You can open source it and just not accept patches. Community development will end up happening somewhere else, but who cares?

> I don’t get it.

Don't worry. You don't have to.

If you want a more specific response than that, what part of the post do you not get?

Post reply on HN