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

21–30 of 201 posts

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#21

Post by userbinator »

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

[flagged]

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#22

Post by adzm »

prvc wrote: post #9
sgbeal wrote: post #2

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's a minimum of 3x faster than its contemporaries. Ok, but what would make that useful?

Lower latency for real time streaming over the Internet, for one

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#24

Post by piecerough »

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]

Tell us more about "I don't aee anything suspicious". How exactly do you know it's not a binary that hashes all your files using a key and asks for btc to revert?

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#25

Post by p-e-w »

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]

Yeah, I too was using the web in the late 90s. I remember countless programming and "hacking" forums where .exes were shared, and I downloaded and ran anything and everything that had a download link.

It was a fun time, and I do harbor some nostalgia for it. But I can't imagine going back.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#26

Post by sgbeal »

prvc wrote: post #20
sgbeal wrote: post #13

Earlier quoted context omitted.

> Ok, but what would make that useful? Lower run-time means less electricity and less tying up of the CPU, making it available for other things. As a real-life example: i frequently use my Raspberry Pi 4 to convert videos from one format to another. This past week i got a Pi 5 and moved the conversion to that machine: it takes maybe 1/4th as much time. The principle with a faster converter, as opposed to faster hardw…

Yes, but there's a threshold for effective improvements. If the more compatible and more efficient format only uses 16 seconds to encode 1 hour of audio, it's hard to imagine this making a big difference in any real use case, offline or real-time.

> ... 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 needed /months/ to adapt to that change.

Why would they cause such disruption for a handful of CPU instructions?

Because at "Google Scale" those few instructions add up to a tremendous amount of electricity. Saving even 1 second per request or offline job, when your service handles thousands or millions of requests/jobs per day, adds up to a considerable amount of CPU time, i.e. to a considerable amount of electricity, i.e. to considerable electricity cost savings.

[1]: https://groups.google.com/g/v8-users/c/MUq5WrC2kcE

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#27

Post by peddling-brink »

piecerough wrote: post #24
userbinator wrote: post #21

Earlier quoted context omitted.

[flagged]

Tell us more about "I don't aee anything suspicious". How exactly do you know it's not a binary that hashes all your files using a key and asks for btc to revert?

There are libraries that would be useful for cryptography that you wouldn’t likely need in an audio codec. If the binary imports those libraries, it may be visible with a bit of prodding.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#28

Post by HakanAbbas »

bsder wrote: post #10
sgbeal wrote: post #2

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.

FLAC level 5 encode times should be WAY longer than decode times. FLAC level 0 to FLAC level 5 is a huge step up and encoding should be way longer (like factor of 3). Under no circumstances should FLAC level 5 decode be faster than FLAC level 0 decode. These are basic sanity checks. Something is wrong in the benchmark.

I was very surprised to this situation, but Flac Level 5 (Default mode) results gave quick results in all my tests. I've tried this hundreds of times. You can try it with any converter and see it. I think much more improvements have been made on this mode.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#29

Post by sgbeal »

userbinator wrote: post #16
sgbeal wrote: post #2

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.

IMHO that's still a "so what?". I see audio compression as having two primary purposes: realtime and archival, and speed is only vaguely relevant for the former. In realtime applications, any processor within the last decade is far more than powerful enough to encode and decode in realtime. The first set of tracks in the results is 2862s long and even the slowest WAVPACK manages to encode it in >113x realtime and clo…

> IMHO that's still a "so what?"

This is addressed in another response in this same thread regarding electricity usage.

Post reply on HN