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

51–60 of 201 posts

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#51

Post by p-e-w »

userbinator wrote: post #42
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?

Open in hex/text editor, scroll through and look for anything suspicious like network, crypto, obfuscated sections (major red flag), strange strings, etc. The #1 most reliable sign of malware is if it's unusually large and packed/obfuscated, but this isn't. The guy even has his full name and contact info in there. This is harmless. If you don't trust me you could upload to an online malware multiscanner (which tends…

It's not about whether this particular announcement, with these particular executables, is trustworthy or not.

It's about the whole process of regularly downloading and running executables uploaded by individuals to a BBS-type forum being unimaginable in most other parts of the software world, and violating every security "best practice" written about in the past 30 years.

I know that this is how things were once done everywhere. But that was a long time ago.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#52

Post by orf »

This doesn’t seem very interesting: there’s no source, the benchmarks are self reported, and the details in the forum post (??) are light at best.

It’s basically just a forum post with a self-signed .exe download…

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#53

Post by HakanAbbas »

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

My goal is to try to do something practical just on data compression. I have neither knowledge nor experience about malicious software mentioned. You may be comfortable about this. https://www.linkedin.com/in/hakan-abbas-178b5852/

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#54

Post by sgbeal »

Dylan16807 wrote: post #45
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…

Saving a small fraction of a second millions of times over, or a handful of cycles a trillion times over, is so much more impactful than saving a dozen seconds per hour-long recording. Also your link doesn't explain what they changed?

> Saving a small fraction of a second millions of times over, or a handful of cycles a trillion times over, is so much more impactful than saving a dozen seconds per hour-long recording.

At a large-enough scale, all savings are significant.

> Also your link doesn't explain what they changed?

They changed a function signature to use an output argument instead of a return value. i don't recall the exact signature, but it was conceptually like:

    v8::Value foo(...);
to

    void foo(..., v8::Value &result);
Why? Because their measurements showed a microscopic per-call savings for the latter construct.

PS: i wasn't aware that source code for this codec is not available. That of course puts a damper on it.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#55

Post by 0xDEADFED5 »

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

Earlier quoted context omitted.

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

it was okay back then though, because the cracked copy of NOD32 on your system would totally protect you =)

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#56

Post by HakanAbbas »

fmajid wrote: post #44
p-e-w wrote: post #15

Earlier quoted context omitted.

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.

Sounds like a retronym for the author’s initials :-)

Great detection :)

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#57

Post by p-e-w »

HakanAbbas wrote: post #53
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...

My goal is to try to do something practical just on data compression. I have neither knowledge nor experience about malicious software mentioned. You may be comfortable about this. https://www.linkedin.com/in/hakan-abbas-178b5852/

I was referring to the practice of downloading executables from such forums in general, not to your post specifically. I have no reason to suspect that this particular post contains any malware. But in most parts of the software world, Open Source has been the standard for experimental publications for a long, long time, and seeing a forum depart so strongly from that standard is certainly surprising, and does of course have security implications when this practice is used at scale.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#58

Post by HakanAbbas »

lifthrasiir wrote: post #47
HakanAbbas wrote: post #40

Earlier quoted context omitted.

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.

If you need some retronym, how about "highly astute ..." or "highly apt ..."?

I will evaluate them.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#59

Post by Eisenstein »

userbinator wrote: post #42
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?

Open in hex/text editor, scroll through and look for anything suspicious like network, crypto, obfuscated sections (major red flag), strange strings, etc. The #1 most reliable sign of malware is if it's unusually large and packed/obfuscated, but this isn't. The guy even has his full name and contact info in there. This is harmless. If you don't trust me you could upload to an online malware multiscanner (which tends…

A lot of malware just waits for a while and the opens another file (or a pastebin) and downloads the payload from somewhere else. A small executable without anything dodgy in it means nothing.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#60

Post by sgbeal »

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.

> ... it is not clear to me that there would be any advantage to switching.

Indeed, getting an accurate answer would require looking at the whole constellation for a given use case.

Post reply on HN