Skip to main content ↑ ↓

Notice

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.
Recent Posts
91
Opus / Opus use more bits to encode a 8KHz track, is this normal?
Last post by fa2_l -
Hello HA, this is my first time posting, hopefully I'm not violating any ToS.

I encoded my small library (~100 albums) to Opus at 160kbps, and one of them caught my attention. It's a homemade metal album, and while most of it average around ~120-140kbps (expected for this genre as other albums I have also average around this), the last track, which is a low quality demo with most signals topping out at ~7-8khz (below I included the spectrogram) and completely out at 16khz, averages at ~170kbps. I then tried with qaac -V100 and Musepack Q5; they both average around 60-70kbps.

I know Opus is pretty generous when it comes to more ambient tracks, but this isn't one of them. A few megabytes isn't a problem but I still wonder why it had happened. Is this normal behaviour for Opus?
92
3rd Party Plugins - (fb2k) / Re: Remastero's foo_pggb_rt, a 64 bit Foobar2000 component for resampling
Last post by fenacer -
Quote from: ZB on
Quote from: fenacer on
Yes, the previous result was converted using Foobar's built-in “Convert,” with pggb-rt set to the best quality, and the converted format is flac.

If you try playing the file to a different device (even your PC /laptop speakers), using Windows Media Player, does it work? Windows will still simply down sample and play at the supported rate, but that will confirm that the flac file is ok.
Yes, it will work, but I'm not sure if the bit rate of the output and the original file have changed.
93
General - (fb2k) / Re: New VST adapter for foobar2000
Last post by wojak -
Quote from: Peter on
Quote from: wojak on
I am afraid there is something wrong with FB2.24 as stated in other topic - my VST visualisations also are very (realy very) choppy. Up til 2.1.16 it was OK.
Problem confirmed, thanks for reporting. There will be a 2.24.1 with a fix for this before the end of the year.

I am not sure if it is related to the above problem but lately I found out that when playing .m2ts files in FB (with ffmpeg decoder wrapper) and watching video part of the file with either mpv or youtube plugin the video gets desynchronized from the audio (but not always, rather the later the more or get desynchronized at some point and stay like that to the end). It is not choppy like vst, it looks ok but is just out of sync which is very annoying especially when you see someone talking or playing drums and the moves are "in wrong time". WIN10/64, FB2.24/64. All plugins at newest versions. It didn't happen with previous FB versions.
94
3rd Party Plugins - (fb2k) / Re: foo_uie_webview
Last post by ApacheReal -
From alpha 4 to alpha 5 I no longer update anything, I don't update images, data or who knows what else. Since I broke myself profusely, because it involves editing over 10 scripts. I greet you, it was a pleasure. Two months of work wasted. Thank you very much.
95
3rd Party Plugins - (fb2k) / Re: foo_uie_webview
Last post by ApacheReal -
Quote from: ApacheReal on
Quote from: yeyo on
Quote from: ApacheReal on
@ yeyo

I made the changes to the spin disc of your version and they are now compatible with the latest version of the foo_uie_webview plugin.

I didn't post it out of fairness to you.
Feel free to share, I'd love to!

Ok tell me if it's okay. I changed the background color, image path and icon management beyond opening the container box.

Do not download this version because it does not update the images.

@ yeyo if you can post your updated version, without runservice and info track, which I'm not interested in, and I really don't understand it, you'll do me a favor.

Thank you.
96
3rd Party Plugins - (fb2k) / Re: foo_uie_webview
Last post by ApacheReal -
There are huge problems it doesn't update the images it wants forced refreshes return to alpha 4.

Thank goodness for the back-ups of the spin disc modules.

My tools are also affected, I don't intend to go crazy changing all the codes again, I'll stick with alpha 4.
98
Lossless / Other Codecs / Re: HALAC (High Availability Lossless Audio Compression)
Last post by Hakan Abbas -
Quote from: Porcus on
Quote from: genuine on
Can't the crazy Rice encoder and decoder that you used in HALAC also be used in FLAC?
That is kinda what I suggested above. A credit for speeding up FLAC by xx percent, would make more waves than a proof-of-concept codec.
Those who pay attention know that FLAC is fast already and has been honed well over > two decades.

But ... developer's choice.
I really don't know how the things you're describing are going to happen and what's going to happen in the end. I don't know what a "credit" is and what it is useful for.
However, I think what I understand in a nutshell is to leave HALAC and support FLAC.
99
Lossless / Other Codecs / Re: HALAC (High Availability Lossless Audio Compression)
Last post by Hakan Abbas -
Quote from: genuine on
I've heard about the success of the HALIC image compression codec. But then it feels a little strange to see such a success in the audio codec as well. Because these are quite different areas.
According to the current results, the critical level has been exceeded. I think the results are excellent. So I don't know how much more compression can be done by processing so quickly. Not to mention multithread encode and decode. Theoretically, more is always possible, but practically it is not.
Can't the crazy Rice encoder and decoder that you used in HALAC also be used in FLAC? Is there such a compatibility?
Thank you for your good thoughts. Since the first version of HALAC, an average of 2 percent compression has been obtained. Without compromising the speed. My guesses were in this direction. However, I think a little more improvement can be done without compromising speed.
X
I can't say that I finished exactly my Rice Coder. In fact, it needs to work a little faster. Especially the Decoder part. Dealing with the Coder can sometimes be badly annoying.

I don't know the Rice Coder used by FLAC. However, they should be quite different structurally with mine. Entropy coder change can cause back compatibility problems. We don't know that. My own Rice coder is now embedded in HALAC. It needs to be abstracted in a good way. I mean, I've never thought of anything like this before.
100
Polls / Re: 2023 Lossless format poll
Last post by Hakan Abbas -
Quote from: Porcus on
HALAC attempted ANS residual compression, but reverted to Rice.
Actually, I could continue with ANS. However, the main problem here is to create certain lice groups properly according to the bit depth and to perform multiple ANS processes. Of course, predictions and transformations have to be a little different. So the code complexity is a bit more. In addition, there are other reasons that are not technical.

I just wanted to make a new experiment with Rice. I continued because the results were better than I expected. So the selection of Entropy coder for HALAC is not a problem.