Live data from Hacker News

New Ultra Fast Lossless Audio Codec (HALAC)

hydrogenaud.io

91–100 of 201 posts

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#91
post #35
post #30

Earlier quoted context omitted.

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.

You can do a sanity check on exe files with VirusTotal and other tools. And if it’s just for testing, you can use a throw-away VM.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#93
post #30

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.

Irrelevant. Convenient or probable doesn't matter. What matters is possible vs not possible.

All it takes is one person somewhere who wants to look something over, and they heads-up the rest, and then many others do verify.

And that initial one does exist even though it's not you or me, the same way the author exists, the same way that at least once in a while for some things it is you or me.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#94

Earlier quoted context omitted.

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 is still possible that the author's machine had a virus and the executable got infected without the author's knowledge. I too trust the author in that matter, but that's irrelevant here.

That's precisely why you look at the binary and not the source...

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#95

Earlier quoted context omitted.

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.

without anything dodgy

I said there weren't any network APIs either (whose presence in an application like this would definitely be a red flag.)

If you say their presence can be obfuscated, then let it be known that obfuscation is also very obvious in a binary and another red flag.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#96
post #68

Earlier quoted context omitted.

Are we even in the same universe? The vast majority of the world still downloads and runs executables uploaded by individuals, albeit perhaps not on a bulletin board or forum (most of those have been killed and replaced by social media).

This argument comes up reasonably regularly. No, the majority of the world does not download and run binaries from non-reputable sources. The distinction between reputable and non-reputable varies, but broadly easily spoofable user uploaded content falls into the non-reputable. Most people download software from trust worthy websites like the official chrome website. Indeed, the fact that people are continually scamm…

You are simply toeing the line of corporate propaganda, that says people must always submit to centralised authority instead of exercising their own judgement.

That is what is leading us to dystopia.

We are not "pretending", we are simply stating that the magnitude of risk is absolutely tiny.

Insecurity is freedom. Don't let them take away the latter in the name of security.

"There is nothing to fear but fear itself."

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#97
post #90
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.

It uses less resources, so the resource retains higher availability?

HALAC and HALIC really consume very little memory. The process speed is high at the same rate. And they offer a reasonable compression rate. Therefore, they can be used at high level and different areas.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#98

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…

This. It's almost ragebait posting this: "I'm better but I won't show you."

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#100

Earlier quoted context omitted.

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

> I/we want to keep my/our primary fork fully ours

The "primary" fork is the one that the community decides it to be, not what the authors "wants". Does it really matter what is the "primary fork" for those working on something to "scratch their own itch"?

Post reply on HN