Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New Ultra Fast Lossless Audio Codec (HALAC)

hydrogenaud.io

Post reply on HN
Print view View original

171–180 of 201 posts

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#171

Post by adastra22 »

redeeman wrote: post #163
adastra22 wrote: post #132

Earlier quoted context omitted.

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.

what do you suggest instead?

I suggest that people who care enough about these things (not me, I’m just informed about it), come together and make a new lossless encoder format that has feature parity with the proprietary/“professional” codecs.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#172

Post by Brian_K_White »

system2 wrote: post #165
Brian_K_White wrote: post #158

Earlier quoted context omitted.

Citation needed. No one said that, and so if you heard it, then you should see a therapist about your hallucinations.

It is a new year, maybe you should try to be happy and calm this year.

And yet still no one said that.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#173

Post by wokwokwok »

userbinator wrote: post #96
wokwokwok wrote: post #73

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.…

you think the risk is tiny, but:

A) the risk exists.

B) you’ve taken no steps to verify that it’s tiny

C) you’re trusting new users just as much as well established users

D) your community is not as obscure and tiny as you imagine when it floats to the top of HN.

It’s not corporate dictatorship to say “there are bad actors out there looking to take advantage of naive users”; it’s reality.

You can refuse to acknowledge that reality, that’s your choice.

However, it’s probably irresponsible to encourage other people to do so.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#174

Post by HakanAbbas »

kazinator wrote: post #168
HakanAbbas wrote: post #148

Earlier quoted context omitted.

Hmm. Of course, we don't need to know how Oracle is fast and secure, why Autodesk is a monopoly in the industry, winrar is still used a lot despite being paid, and how Adobe's artificial intelligence-powered filters work. 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…

Autodesk has a monopoly because, oh, web browsers don't have to open Autocad drawings. The amount of media playback and serving software out there is innumerable. If most of it doesn't handle some obscure format, that format is screwed. Getting a new format everywhere is a difficult battle; the adoption barriers are high. Even if the thing is completely royalty free, and comes with a great, open source reference impl…

You say it's not worth spending time on such work, discovering new things and pondering. I understand.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#175

Post by dspillett »

rglullis wrote: post #157
dspillett wrote: post #108

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 “…

Whatever position you are trying to argue seems to be so antithetical to Free Software, I'd say those sharing this view are completely missing the point of openness and would be better off by keeping all their work closed instead. > other individual/team/etc taking a “we are the captain now” position rather than “this is great, look what we've done with it too” The scenario is that someone opens up a project but says…

> Is this really about "scratching your own itch" or is this some thinly-veiled control issue?

I wasn't attempting to veil it at all. It is a control issue for some.

Sometimes someone is happy to share their project, but wants to keep some hold on the core direction.

> > other individual/team/etc taking a “we are the captain now” position rather than “this is great, look what we've done with it too”

The scenario is that someone opens up a project but says "I am not going to take any external contribution". Then someone else finds it interesting, forks it, that fork starts receiving attention and the original developer thinks to be entitled to control the direction of the fork?

You are missing a step. I said that if someone has this concern then they might not open the project at all, until they feel ready to let go a bit. At that point “open source but not open contribution” and control over forks are not issues at all because the source isn't open and forking isn't possible.

> That is what copyright is for and the patent system are for

I don't know about you, but playing in those minefields is not at all attractive to me, and I expect many feel the same. If I had those concerns, and legal redress is the solution, I now have two problems and the new one is a particularly complex beast, it would be much easier to just not open up.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#176

Post by matheusmoreira »

p-e-w wrote: post #18
brnt wrote: post #14

Earlier quoted context omitted.

Hydrogenaudio is well known in this area and many new prototype codecs are announced there first. Also, the lack of source control and Windows-only binaries are very much congruent to the style of development there. See it as your confrontation with a new world, because small it is not! And later, you will learn to understand the depth of the contribution that the ffmpeg project provides :)

So people just download .exe files that they see in those forum posts and run them on their machines? New world indeed...

There are open source developers out there who literally write installation instructions like these in their READMEs:

  curl http://example.com/script.sh | bash

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#177

Post by rglullis »

dspillett wrote: post #175
rglullis wrote: post #157

Earlier quoted context omitted.

Whatever position you are trying to argue seems to be so antithetical to Free Software, I'd say those sharing this view are completely missing the point of openness and would be better off by keeping all their work closed instead. > other individual/team/etc taking a “we are the captain now” position rather than “this is great, look what we've done with it too” The scenario is that someone opens up a project but says…

> Is this really about "scratching your own itch" or is this some thinly-veiled control issue? I wasn't attempting to veil it at all. It is a control issue for some. Sometimes someone is happy to share their project, but wants to keep some hold on the core direction. > > other individual/team/etc taking a “we are the captain now” position rather than “this is great, look what we've done with it too” The scenario is t…

> I wasn't attempting to veil it at all. It is a control issue.

Then do not hide it behind the "people just want to scratch their own itch". It is a bad rationalization for a much deeper issue and the way to overcome this is by bringing awareness to it, not by finding excuses.

> wants to keep some hold on the core direction.

You are really losing me here. The point from the beginning is that the idea of "direction" is relative to a certain frame of reference. There is no "core" direction when things are open. The very idea of "fork" should be a hint that it is okay to have people taking a project in different directions.

> it would be much easier to just not open up.

Agreed. But like I said: you can not have both ways. If you want to "keep control" and prevent others from taking the things in a different direction, then keep it close but be honest to yourself and others and don't say things like "it's not ready to be open yet" or "I want to share it with others but I worry about losing recognition".

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#178

Post by joshspankit »

adastra22 wrote: post #132
joshspankit wrote: post #111

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.

> 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.

MP3 is a lossy format so I would practically guarantee that you’d end up with a smaller file but that’s not the purpose of FLAC. Lossless encoding makes a file smaller than WAV while still being the same data.

> e.g. floating point for mastering

I’m 0% sold on floating point for mastering. 32bit yes, but anyone who’s played a video game can tell you about those flickering textures and those are caused not by bad floating point calculations, but by good floating point calculations (the bad part is putting textures “on top” of each other at the same coordinates) . Floating point math is “fast” but not accurate. Why would anyone want that for audio (not trying to bash here, I’m genuinely puzzled and would love some knowledgeable insight)

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#179

Post by adastra22 »

joshspankit wrote: post #178
adastra22 wrote: post #132

Earlier quoted context omitted.

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.

> 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. MP3 is a lossy format so I would practically guarantee that you’d end up with a smaller file but that’s not the purpose of FLAC. Lossless encoding makes a file smaller than WAV while still being the same data. > e.g. floating point f…

> MP3 is a lossy format so I would practically guarantee that you’d end up with a smaller file but that’s not the purpose of FLAC. Lossless encoding makes a file smaller than WAV while still being the same data.

You misunderstood what you are replying to. FLAC works by running a lossy compression pass, and then LZ encoding the residual. The better the lossy pass, the less entropy in the residual and the smaller it compresses. FLAC’s lossy compressor pass was shit when it came out, and hasn’t gotten any better.

Flickering textures is caused by truncation and wouldn’t be any better with integer math. The same issues apply (and are solved the same way, with explicit biases; flickering shouldn’t be a thing in any quality game engine).

Floating point math is largely desired for mastering because compression (technical term overloaded meaning! Compression here means something totally different than above) results in samples having vastly different dynamic ranges. If rescaled onto the same basis, one would necessarily lose a lot of precision to truncation in intermediate calculations. Using floating point with sufficient precision makes this a non-concern.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#180

Post by dspillett »

rglullis wrote: post #177
dspillett wrote: post #175

Earlier quoted context omitted.

> Is this really about "scratching your own itch" or is this some thinly-veiled control issue? I wasn't attempting to veil it at all. It is a control issue for some. Sometimes someone is happy to share their project, but wants to keep some hold on the core direction. > > other individual/team/etc taking a “we are the captain now” position rather than “this is great, look what we've done with it too” The scenario is t…

> I wasn't attempting to veil it at all. It is a control issue. Then do not hide it behind the "people just want to scratch their own itch". It is a bad rationalization for a much deeper issue and the way to overcome this is by bringing awareness to it, not by finding excuses. > wants to keep some hold on the core direction. You are really losing me here. The point from the beginning is that the idea of "direction" i…

> Then do not hide it behind the "people just want to scratch their own itch"

You seem to be latching on to individual sentences in individual posts rather than understanding the thread from my initial post downwards. Start from the top and see if that changes.

Right from the beginning I was walking about people not releasing source for this reason, not releasing with expectations of control – while quoting more of the preceding thread might have made that sentence look less like an attempt to hide as you see it, that would bulk out the thread necessarily IMO (and I'm already being too wordy) given that the context is already readily available nearby (as the thread is hardly a long one).

> > it would be much easier to just not open up.

> Agreed. But like I said: you can not have both ways. If you want to "keep control" and prevent …

No, but the other end of the equation often wants the source irrespective of the project creator not being ready to let go of fuller control just yet (for whatever reason, including wanting to get to a certain point their way to stamp their intended direction on it). And they will nag, and the author will either spend time replying to re-explain their (possibly already well documented) position or get a reputation for not listening which might harm them later.

Post reply on HN