Live data from Hacker News

New Ultra Fast Lossless Audio Codec (HALAC)

hydrogenaud.io

41–50 of 201 posts

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#41
post #36
post #31

Earlier quoted context omitted.

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?

i think they were just examples of how simply looking at imports isn't good enough, and it's true. on the plus side, by hitting HN there are more eyes on it and hopefully more consensus on how safe/interesting this is

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#42

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?

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 to invite false positives, but better than nothing).

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#43

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.

I understand a forward compatibility concern, but have you considered to put an attention-grabbing alert in the encoder and clearly state that official releases in the future won't be able to decompress the output? Also your concern may have been too overblown; there have been more than 100 PAQ versions with mutually incompatible formats but such issues didn't happen too often. (Not to say that ZPAQ was pointless, of course.)

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#44
post #15
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.

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

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#45
post #26
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…

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?

Re: New Ultra Fast Lossless Audio Codec (HALAC)

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

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

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#48

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.

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 own it (you can license the code any way you like!) and you can choose what contributions make it in to your source.

From the encode.su thread and now the HA thread, you've clearly gotten people excited, and I think that by itself means that people will be eager to try these out. Lossless codecs have a fairly low barrier for entry: you can use them without worrying about data loss by verifying that the decoder returns the original data, then just toss the originals and keep the matching decoder. So, it should be easy to get people started using the technology.

Open-sourcing your projects could lead to some really interesting applications: for example, delivering lossless images on the internet is a very common need, and a WASM build of your decoder could serve as a very convenient way to serve HALIC images to web browsers directly. Some sites are already using formats like BPG in this way.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#50
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]

Corporate? That's not a sound way to describe the totality of the world of programmers that lean towards free/open and beyond.

Sure, closed-source communities exist and have for a long age, but many folk have grown beyond the ethos or tradition of closed releases for reasons like, IDK, competitive individualism for clout or potential code quality shame that AFAICT drive such corners of the software world, especially at the level of freeware, not just for business. It's certainly a new world for younger people who skipped the era when that was more prevalent.

If people don't like corporate, there are newer source available licence options that folk to the left of free/open have been advocating more recently.

Post reply on HN