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

31–40 of 201 posts

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#31

Post by p-e-w »

peddling-brink wrote: post #27
piecerough wrote: post #24

Earlier quoted context omitted.

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.

Unless they are statically linked.

Or the binary uses executable compression.

Or obfuscated dynamic loading.

Or about a million other techniques that can thwart dependency analysis, and which have been well-known for decades.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#32

Post by prvc »

sgbeal wrote: post #26
prvc wrote: post #20

Earlier quoted context omitted.

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…

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.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#33

Post by [deleted] »

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…

[deleted]

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#34

Post by lifthrasiir »

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…

> The fact that "encode.su" uses the world's most notorious domain extension doesn't inspire confidence, to put it mildly.

Encode.su (formerly encode.ru) is indeed the most known forum dedicated for data compression in general. So much that many if not most notable data compression projects posted to HN are often first advertised to that forum first (for example, Zstandard [1]).

[1] https://encode.su/threads/2119-Zstandard

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#35

Post by p-e-w »

system2 wrote: post #30
andrewinardeer wrote: post #23

I'd like to test this but mum said not to download unknown .exe files from the internet.

Honestly, if they provided 100mb source code, would you read it and then compile it? Source code alone doesn't make it secure.

Something like this doesn't require 100 MB of source code. I'd expect a few thousand LoC at most.

And I absolutely do at least a quick visual "sanity check" of the code before compiling and running newly announced software.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#36

Post by TylerE »

p-e-w wrote: post #31
peddling-brink wrote: post #27

Earlier quoted context omitted.

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.

Unless they are statically linked. Or the binary uses executable compression. Or obfuscated dynamic loading. Or about a million other techniques that can thwart dependency analysis, and which have been well-known for decades.

And precense of those things is basically the first thing any malware heuristic looks at. Why are you so emphatically stating them as if they are news?

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#37

Post by lifthrasiir »

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

You can always use a sandbox if that's the most concern. A bigger issue is that, as like other established forums, enough many people don't know much about data compression and contribute to the noise.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#38

Post by HakanAbbas »

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.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#39

Post by exe34 »

sgbeal wrote: post #26
prvc wrote: post #20

Earlier quoted context omitted.

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…

Nobody is going to use this at Google scale without source code! However knowing that something exists elsewhere can push somebody to re-invent it locally.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#40

Post by HakanAbbas »

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.

I wasn't really careful when making this naming. I just tried to make it a little different. I can't say that I'm successful in nomenclature.
Post reply on HN