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

81–90 of 201 posts

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#81

Post by sitkack »

HakanAbbas wrote: post #38
everythingctl wrote: post #12

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.

When you do decide to open the codec, you should talk to xiph.org about patent defensibility. If you want it open, but don’t build a large enough moat (multichannel, other bitrates, bit depth, echo and phase control, etc then the licensing org will offensively patent or extend your creation.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#82

Post by HakanAbbas »

sitkack wrote: post #81
HakanAbbas wrote: post #38

Earlier quoted context omitted.

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.

When you do decide to open the codec, you should talk to xiph.org about patent defensibility. If you want it open, but don’t build a large enough moat (multichannel, other bitrates, bit depth, echo and phase control, etc then the licensing org will offensively patent or extend your creation.

Thanks for the information about the license and patent. It can work with any bitrates for Halac. However, more than 2 channels and 24/32 bit support outside 16 can be added.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#84

Post by HakanAbbas »

prvc wrote: post #32
sgbeal wrote: post #26

Earlier quoted context omitted.

> ... it's hard to imagine this making a big difference in any real use case, offline or real-time. Google once, back in 2013, made an API change to their v8 engine because it saved a small handful of CPU instructions on each call into client-defined extension functions[^1]. That change broke literally every single v8 client in the world, including thousands of lines of my own code, and i'm told that the Chrome team…

Yes, but this must be weighed against increased storage costs, not to mention the computational cost of transcoding (and others to do with the proliferation of formats). Within the parameters of this application and taking into account the relative costs of compute and storage (in money or energy), it is not clear to me that there would be any advantage to switching.

The compression rate in audio compression is really limited. In most cases it is difficult to decrease below 50 percent.

Therefore, it is not a logical choice to increase the process rate in order to provide a few percent more compression between audio codecs. As a result, high processing times are high energy.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#85

Post by prvc »

HakanAbbas wrote: post #84
prvc wrote: post #32

Earlier quoted context omitted.

Yes, but this must be weighed against increased storage costs, not to mention the computational cost of transcoding (and others to do with the proliferation of formats). Within the parameters of this application and taking into account the relative costs of compute and storage (in money or energy), it is not clear to me that there would be any advantage to switching.

The compression rate in audio compression is really limited. In most cases it is difficult to decrease below 50 percent. Therefore, it is not a logical choice to increase the process rate in order to provide a few percent more compression between audio codecs. As a result, high processing times are high energy.

>Therefore, it is not a logical choice to increase the process rate in order to provide a few percent more compression between audio codecs.

Why not? And for what applications? Example: for a media streaming service, where each file is transferred many times, the bandwidth costs dominate, so it is worthwhile to spend a great deal of time on encoding to maximize efficiency. In the case of an archive, where a large amount of information is stored, accessed infrequently, storage space becomes the constraint, once again. In general, 1 marginal second of CPU time is usually cheaper than 10Mib of marginal storage (or whatever the figure works out to be). Finally, why not just write a fast FLAC encoder?

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#87

Post by dspillett »

nneonneo wrote: post #48
HakanAbbas wrote: post #38

Earlier quoted context omitted.

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.

One of the cool things about open source is that other people can do that for you! I've released a few bits of (rarely-used) software to open-source and been pleasantly surprised when people contribute. It helps to have a visible todo list so that new contributors know what to aim for. By the way, there will always be things to add! That feeling should not stop you from putting the source out there - you will still o…

> One of the cool things about open source is that other people can do that for you!

This is a very valid point, but we should all recognise that some people⁰ explicitly don't want that for various reasons, at least not until they've got the project to a certain point in their own plans. Even some who have released other projects already prefer to keep their new toy more to themselves and only want more open discourse once they are satisfied their core itch is sufficiently scratched. Open source is usually a great answer/solution, but it is not always the best one for some people/projects.

Even once open, “open source not open contribution”¹ seems to be becoming more popular as a stated position² for projects, sometimes for much the same reasons, sometimes for (future) licensing control, sometimes both.

--

[0] I'm talking about individual people specifically here, not groups, especially not commercial entities: the reasons for staying closed initially/forever can be very different away from an individual's passion project.

[1] “you are free to do what you want, but I/we want to keep my/our primary fork fully ours”.

[2] it has been the defacto position for many projects since a long time before this phrase was coined.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#89

Post by HakanAbbas »

prvc wrote: post #85
HakanAbbas wrote: post #84

Earlier quoted context omitted.

The compression rate in audio compression is really limited. In most cases it is difficult to decrease below 50 percent. Therefore, it is not a logical choice to increase the process rate in order to provide a few percent more compression between audio codecs. As a result, high processing times are high energy.

>Therefore, it is not a logical choice to increase the process rate in order to provide a few percent more compression between audio codecs. Why not? And for what applications? Example: for a media streaming service, where each file is transferred many times, the bandwidth costs dominate, so it is worthwhile to spend a great deal of time on encoding to maximize efficiency. In the case of an archive, where a large amo…

The only reason Flac is the most popular sound code is that both compression and code -solving is faster than others. The same applies to many formats such as JPEG, MP4, MP3, Rar, Zstandart. What is fast is always advantageous and is a reason for preference. Even if they are not free. As you mentioned, of course, it does not apply to every situation.

Flac is already existing. There are also a lot of workers on it. I always want to try independent and different things.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#90

Post by layer8 »

p-e-w wrote: post #15
p-e-w wrote: post #8

For what looks at first glance to be a potentially impactful development, this post and the "encode.su" one linked from it are extremely sparse on details. Where is the source code? A detailed description of what the codec actually does? References to relevant publications? All I see are two mystery Windows binaries, hosted on a forum I've never heard about. The fact that "encode.su" uses the world's most notorious d…

Also, what does the High Availability in the name of the codec refer to? I've searched the web and found not a single mention of "high availability" in the context of audio codecs. In fact, the top-ranked result was this very post, which doesn't explain what the term is intended to mean.

It uses less resources, so the resource retains higher availability?
Post reply on HN