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
2
Support - (fb2k) / Re: BUG - FB Preview 2.24 (both last at least) - Crashes on file renaming
Last post by Case -
I'm of course not an expert, but the crash seems to happen because foobar2000 can't allocate memory. Peter will know if there's any ways to reduce memory use with this operation, but there may be ways you can help the situation yourself.

I see you have Spider Monkey Panel installed. My understanding is that it can easily eat a lot of memory. If you can live without it, you could test if removing the component is enough to give foobar2000 some breathing room.

I also wonder about that foo_sqlite component. If it handles another database of foobar2000 library data I'd expect it to also need about the same amount of extra memory as foobar2000 library needs. I hope I'm mistaken and it uses some tricks without eating away your precious address space.
3
Lossless / Other Codecs / Re: HALAC (High Availability Lossless Audio Compression)
Last post by Hakan Abbas -
Yes, HALAC fast mode is currently 2048 samples and parameter changes are made every 512 samples. The choice of 1152/144 for FLAC seems really good. In the many tests I have done before, changes in block size or number of parameters did not make a significant difference. Obviously there are some points I have missed. This will require more experimentation.

If ALAC does adaptive parameterisation, this is one of the main reasons why it is slow. For example, JPEG LS also works this way.
I haven't really looked at the codecs of ALAC/FLAC or other codecs because it's really boring and difficult for me to try to understand the codecs I haven't written myself. I prefer to concentrate on general principles instead. Also, I can work much more freely this way. That's why I had to re-develop a Rice Coder, I couldn't even focus on the Coder I was using before.

Isn't Linear Prediction used at higher FLAC levels? Because although the encoding times change, this is not reflected in the decode times.
4
Support - (fb2k) / Re: foobar2000.exe doesn't close
Last post by Case -
The foo_input_ds component definitely seems to be the cause of the hang. It is very safe to remove. It has been dead and abandoned for nearly two decades.
The second foobar2000 instance is stuck because it's trying to communicate with the bugged instance. So the extra stuck processes are normal. Memory dump shouldn't be needed as the stuck instance didn't implicate an issue with the player core.

Not related to the hang, so feel free to ignore, but I see you have quite a few older and abandoned components installed. For example the original Dynamic Range Meter is one of the crashiest components in existence according to crash logger. If you have crashes or just want to do maintenance, you can find newer versions to some of the components. For example foo_dr_meter is a new custom implementation of Dynamic Range Meter. And I'll link this foo_dsp_resampler too as it's based on latest version but combines the features of _mod and _mod2 into one without breaking any services that depend on "SoX resampler" having its original name. But that's enough with unwanted suggestions.
6
General - (fb2k) / Re: Playlist view sorting by encoding type since update
Last post by Case -
Note that this isn't sorting related. The built-in "By artist/date/album/codec" grouping seems to use the more detailed %codec_long% titleformat field instead of just basic %codec% in its pattern. The %codec_long% field was enhanced in a recent update to provide additional information with more formats.

You can create a new grouping pattern with the information you want. Right click on any playlist column header and select 'Groups' -> 'More...'. Click 'Add new' under the 'Custom grouping schemes' and give your grouping pattern a name. Then type or copy/paste this into the pattern field:
[%album artist% - ]['['$year(%date%)']' ][%album%][ '('%codec%')']

Come out of Preferences with OK, right click the header line again and now under 'Groups' menu select the pattern you just created.
8
General - (fb2k) / Playlist view sorting by encoding type since update
Last post by spaghetti -
What's happening forum =3

Ever since I updated to the newest foobar version my playlist view grouping has been behaving like so:



How can I fix this? I don't care to see the file type and encoding. I've searched through the advanced settings and I can't find anything relating to this sorting behaviour.

Any help would be most appreciated.
10
Lossless / Other Codecs / Re: HALAC (High Availability Lossless Audio Compression)
Last post by Porcus -
So the fast mode fixes block size to 2048, and switches Rice parameter every 512?
For comparison, FLAC presets -0, -1, -2 (the ones which use fixed predictors and 1152 samples in a block) switch up to every 144. The reference encoder can also enforce a minimum partitioning, and thus an exact partitioning: -r n,N for at least n and at most N; -r N is synonymous to -r 0,N. Higher presets use a block size of 4096 and max partitioning of 2^4 to 2^6. It isn't hard to get out stats on what partitioning it actually uses. I remember when was struggling to learn this, a lot of classical pieces would be bit-identical from -r4 to -r5, meaning that not a single block would be partitioned into 2^5 (a Rice parameter could live for 256 samples and the encoder would never during an entire track want to switch twice as often). More abrasive music can sometimes want to switch after 32 rather than after 64. Extremely noisy music even more.


IIRC, ALAC calculates the Rice parameter from past samples, and that seems to be one reason ALAC doesn't hit FLAC speeds. But if you have studied the code, you know better than I do. (ALAC can also do run-length, which is good in those few test cases where the predictor hits exact.)