Live data from Hacker News

New Ultra Fast Lossless Audio Codec (HALAC)

hydrogenaud.io

151–160 of 201 posts

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#151

Earlier quoted context omitted.

> MS Windows, MS Office, Adobe, Autodesk, Oracle, Winrar and thousands of more wonderful software should not be taken seriously. Apples and oranges. I don't need word processing software to be open source to understand how it works. A proportedly novel compression algorithm is a different story... I can be totally honest with you: FLAC being open source is more valuable to me than any performance benefit you could ev…

Hmm. Of course, we don't need to know how Oracle is fast and secure, why Autodesk is a monopoly in the industry, winrar is still used a lot despite being paid, and how Adobe's artificial intelligence-powered filters work. I am developing HALAC and HALIC as a hobby and I don't expect everyone to use them. I'm happy when I can get good results, and it's bad when I can't. I say this as someone who has been dealing with…

I think the results are very interesting: just to reiterate, I would love to see what you've done here, and I hope you publish it.

Obviously, it's your right to decide... but especially if you think of it as a hobby, why not release the source? It would make your work much more valuable for a lot more people.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#152

Earlier quoted context omitted.

Hmm. Of course, we don't need to know how Oracle is fast and secure, why Autodesk is a monopoly in the industry, winrar is still used a lot despite being paid, and how Adobe's artificial intelligence-powered filters work. I am developing HALAC and HALIC as a hobby and I don't expect everyone to use them. I'm happy when I can get good results, and it's bad when I can't. I say this as someone who has been dealing with…

I think the results are very interesting: just to reiterate, I would love to see what you've done here, and I hope you publish it. Obviously, it's your right to decide... but especially if you think of it as a hobby, why not release the source? It would make your work much more valuable for a lot more people.

Frankly, if I publish open sources now, I can't take care of them again. Because there will be no excitement. I say this because I know myself very well.

When I bring my work to a certain stage, I would like to deliver it to a team that can claim it. However, I want to see how much I can improve my work alone.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#153

Earlier quoted context omitted.

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.

> When I complete them and realize that it will really be used by someones, it will of course be open source There is a chicken and egg problem with this strategy: Few people will want to, or even be able to, use this unless it’s open source and freely licensed. The alternatives are mature, open or mostly open, and widely implemented. Minor improvements in speed aren’t enough to get everyone to put up with any diffic…

When I bring my work to a certain stage, I would like to deliver it to a team that can claim it. However, I want to see how much I can improve my work alone.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#154

Novel, but until it's open source, it will never be taken seriously.

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.

What most people do is they trademark the name, that way even though someone might fork, they have to use a different name.

Something else you can do is use (A)GPL3. This means you automatically grant patent licenses, and anyone building on your work also has to release their source. You can then separately sell proprietary licenses without any of these restrictions.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#155

Earlier quoted context omitted.

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.

FWIW: I support your position and wish that there was more trust on the internet. I’m happy that some of these old-school forums still have that level of trust.

But, from a technical perspective, I think it’s naive to assume that you can easily spot obfuscation that’s trying to stay hidden. If I understood your analysis model (open in a hex viewer and scroll around), then it is quite trivial to just add a few normal-looking functions that happen do things like manually load socket DLLs and make network requests without the API names being visible.

I could even, say, hide the code or data in a table of opaque filter constants or lookup tables, and it wouldn’t have to be much: you can implement a very dumb PE parser and function loader in a couple dozen lines of C, and an IP address target is just 4 bytes which can be smuggled into anything. Open up a socket, read everything from it into an RWX buffer, jump to it and voila, a programmable backdoor. Make the trigger something random so dynamic analysis doesn’t find it immediately.

The Underhanded C Code Contest demonstrates that even with source you can hide malicious behaviour; how are you going to detect malicious behaviour in a binary that’s trying to evade manual detection?

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#156

Earlier quoted context omitted.

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.

What most people do is they trademark the name, that way even though someone might fork, they have to use a different name. Something else you can do is use (A)GPL3. This means you automatically grant patent licenses, and anyone building on your work also has to release their source. You can then separately sell proprietary licenses without any of these restrictions.

Thank you very much for valuable information.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#157

Earlier quoted context omitted.

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

Hence I said my/our primary fork, not the primary fork. If I were in the position of releasing something⁰: the community, should one or more coalesce around a work, can do/say what it likes, but my primary fork is what I say it is¹. It might be theirs, it might be not. I might consider myself part of that community, or not. It should be noted that possibility of “the community” or other individual/team/etc taking a “…

Whatever position you are trying to argue seems to be so antithetical to Free Software, I'd say those sharing this view are completely missing the point of openness and would be better off by keeping all their work closed instead.

> other individual/team/etc taking a “we are the captain now” position rather than “this is great, look what we've done with it too”

The scenario is that someone opens up a project but says "I am not going to take any external contribution". Then someone else finds it interesting, forks it, that fork starts receiving attention and the original developer thinks to be entitled to control the direction of the fork? Is this really about "scratching your own itch" or is this some thinly-veiled control issue?

I'm sorry, after you open it up you can't have it both ways. Either it is open and other people are free to do whatever they want with it, or you say "it's mine!" and people will have to respect whatever conditions you impose to access/use/modify it.

> if the creator is particularly concerned about acknowledgement of their position as the originator.

That is what copyright is for and the patent system are for those who worry about being rewarded by their initial idea and creation.

If one is keeping their work to themselves out of fear of losing "recognition", they should look into the guarantees and rights given by their legal systems, because "feelings on this matter" are not going to save them from anything.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#158

Earlier quoted context omitted.

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.

I am happy to hear everyone has plenty of free time to check all random internet open-source projects.

Citation needed. No one said that, and so if you heard it, then you should see a therapist about your hallucinations.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#159

There's no source? It's very hard to take this seriously without source code... He explicitly says it's not SIMD, which is nice because it rules out a way of cheesing it, but still...

Yeah, I was about to click and read and it occurred to me that this is only of possibly theoretical interest and I'll know about later if it comes to matter. There are some areas that I follow as-it-develops, but codecs and data compression is one that I'll use when ready. Still awaiting widespread av1 support/adoption. The area most needing improvements IMO is with Bluetooth, especially Apple's support of codecs (wh…

Pretty much any low level tech is at most a theoretical curiosity to me. I'll use it when it works in every browser and OS and average people recognize the file extension. Unusual tech seems to attract unusual bugs!

Still really really impressive to beat an established standard as an individual, that doesn't happen much.

Re: New Ultra Fast Lossless Audio Codec (HALAC)

#160

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.

Don't let perfect be the enemy of good. If Linus didn't open source Linux until it was "complete", it wouldn't be anywhere near as popular as it is.
Post reply on HN