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

181–190 of 201 posts

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#181

Post by rglullis »

dspillett wrote: post #180
rglullis wrote: post #177

Earlier quoted context omitted.

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

I don't want to keep this conversation going in circles, but to me it seems like you are trying to explain a behavior (some people do not want to release source before conditions X, Y and Z are met) and I am arguing that the behavior itself is antithetical to FOSS.

From the top of the thread: "it is difficult to take it seriously if you refuse to offer source code or a implementable specification.". If OP has reservations about building it the open, I'd rather hear "I am not going to open it because I want to keep full control over it" then some vague "I will open it after I complete some other stuff".

You mention the concern about "getting a reputation for not listening". To me, this has already happened. The moment I saw "when I realize it can be used by someone, it will be of course be open source", I'm already doubting his ability to collaborate, I already put him in the "does not understand how FOSS work" box and I completely lost interest in the project.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#182

Post by HakanAbbas »

rglullis wrote: post #181
dspillett wrote: post #180

Earlier quoted context omitted.

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

I don't want to keep this conversation going in circles, but to me it seems like you are trying to explain a behavior (some people do not want to release source before conditions X, Y and Z are met) and I am arguing that the behavior itself is antithetical to FOSS. From the top of the thread: "it is difficult to take it seriously if you refuse to offer source code or a implementable specification.". If OP has reserva…

> Frankly, if I publish open sources now, I can't take care of them again. Because there will be no excitement. I say this because I know myself very well.

> When I bring my work to a certain stage, I would like to deliver it to a team that can claim it. However, I want to see how much I can improve my work alone.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#183

Post by shdh »

adastra22 wrote: post #179
joshspankit wrote: post #178

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

> FLAC works by running a lossy compression pass, and then LZ encoding the residual.

Since when does FLAC run a lossy pass? You can recover the original soundwave from a FLAC file, you can't do the same with an MP3.

I'm pretty sure FLAC does not run a lossy compression pass.

Flickering textures in game engines are likely due to z-fighting, unless you're referring to some other type of flickering.

If you're looking to preserving as much detail as possible from your masters then floating points make sense. But its really overkill.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#184

Post by shdh »

irh wrote: post #147
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.

Support for >8 channels led me to use WavPack instead of FLAC.

What's the use case?

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#185

Post by kazinator »

HakanAbbas wrote: post #174
kazinator wrote: post #168

Earlier quoted context omitted.

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.

No reasoning process rooted in reading comprehension can come to the conclusion that I wrote such a thing.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#186

Post by rglullis »

HakanAbbas wrote: post #182
rglullis wrote: post #181

Earlier quoted context omitted.

I don't want to keep this conversation going in circles, but to me it seems like you are trying to explain a behavior (some people do not want to release source before conditions X, Y and Z are met) and I am arguing that the behavior itself is antithetical to FOSS. From the top of the thread: "it is difficult to take it seriously if you refuse to offer source code or a implementable specification.". If OP has reserva…

> Frankly, if I publish open sources now, I can't take care of them again. Because there will be no excitement. I say this because I know myself very well. > When I bring my work to a certain stage, I would like to deliver it to a team that can claim it. However, I want to see how much I can improve my work alone.

Sorry, this is exactly why it seems that you don't understand FOSS.

1) Publishing the code does not mean that it is done. Software development is a continuous effort.

2) There is no "delivering it to a team that can claim it". When (if?) you release your code, you will see the possible outcomes:

- the worst case scenario, someone will find an issue on your design and point to a better alternative and you will be left alone with your project.

- The best case scenario, your work brings some fundamental breakthrough and you will have to spend a good amount of time with people trying to figure it out or asking for assistance on how to make changes or improvements for their use case.

- The most likely scenario, your work will get its 15 minutes of fame, people are going to be taking a look at it, maybe star at Github and then completely leave it up to you to keep working on the project until it satisfies their needs.

Like "everythingctl" said, you will see that few people will take you seriously until you actually show source code or an reproducible specification. But you will also see that is a "required but not sufficient condition" for you to be taken seriously. And while I completely understand the fear of putting yourself out there and the possibility of having your work scrutinized and criticized for things you know need improvement, I think that this mentality is incompatible with the ethos of Open Source development and I wish more people can help you overcome this fear than tried to excuse or defend it.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#187

Post by dang »

userbinator wrote: post #21
p-e-w wrote: post #18

Earlier quoted context omitted.

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

[flagged]

Hey, could you please edit out swipes and/or name-calling from your HN posts? This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html.

Your comment would be just fine without the (first clause of the) second sentence.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#188

Post by joshspankit »

shdh wrote: post #183
adastra22 wrote: post #179

Earlier quoted context omitted.

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

> FLAC works by running a lossy compression pass, and then LZ encoding the residual. Since when does FLAC run a lossy pass? You can recover the original soundwave from a FLAC file, you can't do the same with an MP3. I'm pretty sure FLAC does not run a lossy compression pass. Flickering textures in game engines are likely due to z-fighting, unless you're referring to some other type of flickering. If you're looking to…

Yes exactly. What you’re saying lines up with what I’ve learned through experience.

> If you're looking to preserving as much detail as possible from your masters then floating points make sense.

I’ve been searching for hours and gotten nothing more than the classic floats vs ints handwaving. Can you explain what you know about why using floats preserves detail?

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#189

Post by adastra22 »

shdh wrote: post #183
adastra22 wrote: post #179

Earlier quoted context omitted.

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

> FLAC works by running a lossy compression pass, and then LZ encoding the residual. Since when does FLAC run a lossy pass? You can recover the original soundwave from a FLAC file, you can't do the same with an MP3. I'm pretty sure FLAC does not run a lossy compression pass. Flickering textures in game engines are likely due to z-fighting, unless you're referring to some other type of flickering. If you're looking to…

> The FLAC encoding algorithm consists of multiple stages. In the first stage, the input audio is split into blocks. If the audio contains multiple channels, each channel is encoded separately as a subblock. The encoder then tries to find a good mathematical approximation of the block, either by fitting a simple polynomial, or through general linear predictive coding. A description of the approximation, which is only a few bytes in length, is then written. Finally, the difference between the approximation and the input, called residual, is encoded using Rice coding.

Linear predictor is a form of lossy encoding.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#190

Post by adastra22 »

joshspankit wrote: post #188
shdh wrote: post #183

Earlier quoted context omitted.

> FLAC works by running a lossy compression pass, and then LZ encoding the residual. Since when does FLAC run a lossy pass? You can recover the original soundwave from a FLAC file, you can't do the same with an MP3. I'm pretty sure FLAC does not run a lossy compression pass. Flickering textures in game engines are likely due to z-fighting, unless you're referring to some other type of flickering. If you're looking to…

Yes exactly. What you’re saying lines up with what I’ve learned through experience. > If you're looking to preserving as much detail as possible from your masters then floating points make sense. I’ve been searching for hours and gotten nothing more than the classic floats vs ints handwaving. Can you explain what you know about why using floats preserves detail?

Do you actually have experience writing a FLAC encoder/decoder? I do. Go read the format specification. There is a lossy compression pass, then it uses a general compressor on the residual after you subtract out the lossy signal. The two combined allow you to reconstruct the original signal losslessly.
Post reply on HN