Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Opus 1.5 has a stellar post-processing filters for low-bitrate streams, but basically remains unchanged otherwise apart from some bug fixes.
Exhale ist now at 1.2.1, and FgG at 4.4.0 (latest EZ CDDA) - does anyone happen to know or are there even tests if there's any significant enhancements with these xHE-AAC encoders for voice or music?
Last post by Case -
Hmm. The kbhit check for encoding canceling actually slows the encoding down a lot. That was the reason my clang compile didn't reach JoshuaChang's speeds. The abort-by-key-press check makes encoding take about 22% longer here.
I wonder if anyone would mind if it was nuked entirely. I know it isn't even implemented for linux and without the patch I attached earlier it only worked on Visual Studio compiles.
Last post by Swi -
Hello Peter and Womans or Mans. Excuse me for absence. Please, make dubliring(s) (dublicate(s) with an auto counter at the ends of track position names (example: namepostrack# i.e. namepostrack№) tracks by ratings in playlist at yours component.
Last post by Klymins - @Heliologue Thanks. Of course it's subjective, but it even does not sound better than MP3 for music to me. @saratoga Looks like you're wrong. I did the decoding speed test myself and MP3 was way faster than Opus.
Last post by Hakan Abbas -
The comment of everyone who comments is valuable to me. @mudlord , @Kraeved As of now, HALAC is still in the development phase. The newest of other lossless codec except HALAC is close to 20 years of age. As I find time now, I try to establish the compression ratio/speed balance. I can see that there is a gap here. When my improvements are over, it can be a codec that everyone can use. However, there is a lot of structural changes at the moment. And this is not very suitable for general use. However, 0.2.7 can now be encoded, decoded and listened to, albeit experimentally.
@Case Thank you so much for foobar2000, Case. I have no desire to develop a new player. I just wanted to show that HALAC files can be listened to. So I prepared a very simple DLL.
I usually work as ANSI. Yes, Unicode support can also be added. I will have to make some change for this.
Decoded data in terms of convenience are returned as a single WAV. However, I can do this in the form of frames (up to 1 MB). However, in this case, the relevant Players should also use the data in pieces. I did not want to deal with it in the Player I have developed for now.
Since the maximum size of the WAV files was u32 bit, I didn't need more. This can be increased, no problem.
I need to add error controls, especially version control. It is true that I have ignored this stage a little.
I added the SSE2 version of DLL to Github. However, I have never needed 32 bit until now. If necessary, I can also compile 32 bit. But considering the whole structure, of course, there will be things I need to change. Therefore, the subject of 32 bit is less priority for me for now.
Last post by Case -
To my knowledge there are no harmful side effects from it. You could verify that it fixes the insane slowdown when using a GCC compile through wine. If it does, I think it may be worth including.
