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
23
3rd Party Plugins - (fb2k) / Re: Dynamic Range plugin
Last post by omasciarotte -
Quote from: foobrik on
It does not support wavpack and ape formats.

Indeed. If we do add those features, we know where to look for beta testers! I have to ask…both of those formats are not as widely adopted as FLAC, so why use them? They offer no particular advantage and, in the case of Monkey’s Audio, the decoder has a relatively high CPU utilization. Higher utilization usually translates into higher output jitter. Has it become a legacy choice, where you started with those formats and stuck with them due to inertia? Or was it something else? Also, would you find a background lossless–to–lossless batch transcoder useful? APE to FLAC, for instance?
25
3rd Party Plugins - (fb2k) / Re: foo_truepeak True Peak Scanner
Last post by Case -
Uploaded a new version with PLR restored to two decimal accuracy. I also changed the unit from dB to LU as it's mostly dealing with EBU loudness terminology, where the preferred unit is LU.
@Defender : LUFS-I has seen no changes. It's still negative for most if not all sane tracks. You need to boost loudness so high that almost all content is beyond full scale to make things so loud that LUFS-I turns positive. And of course peaks are still higher than the loudness, so PLR will remain positive.
26
General Audio / Re: Album Art Downloader XUI
Last post by bigi -
thank you for the super quick reply - and answers - brilliant to see i can do everything i need :)

I worked out the confused window problem this morning - nothing like a fresh pair of eyes on a problem!

I have got some basic knowledge of api calls and network inspector, so i will try and work out whats wrong with beatport myself and let you know if i work out the problem before you do!
27
foobar2000 mobile / [Bug report] ios internet radio stuttering after playing a while
Last post by meow_ -
i don't really know to write about this but basically every time i listen to an internet radio channel for around 1 hour and 30-35 minutes the audio starts stuttering really badly. the phone is still responsive and not even running warm and has plenty of charge left, i even tested this with it plugged in to the charger and there are no errors in the foobar console so i never managed to figure out what exactly happened. oh and its playing through the internal speaker so there should be any connectivity issues there.
if helpful im running the latest version of ios foobar on ios 15.8 that runs on iphone se and the channel i have these problems with is https://jarviradio.radiotaajuus.fi:9000/jr

also is there any way to enable a proper debug log output so the console would provide more useful information about issues like this?
28
3rd Party Plugins - (fb2k) / Re: foo_truepeak True Peak Scanner
Last post by wojak -
Quote from: Case on
I initially had two decimals but I changed it to integer right before release. I'll change it back if that's what people want.

How about the tag field names, does anyone know if some tool already uses some tag field names for these things? I'd like to utilize common tags.
And this worries me a bit, I have been using the latest compiler for about 24 hours now. Any stability issues? I can revert to older toolchain.

And of course I want to know what Defender's comment about negated PLR was about...

Yes, please bring back the decimals.
External meters show PLR as positive values. If PLR=TP-LUFS and LUFS are negative, PLR must be positive and more or less PLR=-LUFS (assuming peaks being close to 0).
29
Support - (fb2k) / Newer foobar2000 Versions and 'fact' Chunks
Last post by Nick.C -
While attending to a bug report for lossyWAV I dropped some lossyWAV v1.4.2 processed WAV files into foobar2000 v2.1.4 (and v1.6.13) and was surprised to see that the stated duration for each of the files was of the order of 233,031,623 weeks, instead of less than a minute for each. Each processed WAV file contains a new 'fact' chunk, immediately after the 'fmt ' chunk, which stores a null terminated string relating to the processing parameters and when the file was processed. Per the RIFF specification the 'fact' chunk is zero padded to even length as required.

When developing the previous release version of lossyWAV (v1.4.2, released in September 2016) I used foobar2000 in the development process, often dropping lossyWAV processed WAV files and FLAC files containing processed WAV data. At that time the file durations were correctly displayed even with the 'fact' chunk in place.

To double check that this was actually the case, and not the result of faulty memory, I checked today with foobar2000 v1.1.5 and the durations are correctly shown, see attached image.

Has foobar2000 changed in some way in the intervening period such that it no longer tolerates 'fact' chunks?
30
3rd Party Plugins - (fb2k) / Re: foo_truepeak True Peak Scanner
Last post by Defender -
Quote from: Case on
And of course I want to know what Defender's comment about negated PLR was about...
Originally I used the oneliners I found somewhere on Regor's site to determine LUFS and PLR. So far for all the tracks in my playlist as a result of these oneliners the values have been positive.
When you came up earlier with the formula for LUFS I've written my own code for LUFS and PLR calculation, and backtested them with the original oneliners. All results are the same except for the rounding glitch of 0.1 that exists in the original oneliners.

Then you came up publishing LUFS-I and those values were always negative. Hence my question about that earlier.
In your answer you made a remark that LUFS-I becomes positive when gain is for instance -19 dB.
I decided I still want to see rounded positive integers like before (for tracks with normal gain values) so I had to negate (change the sign of) your values. Your negated value is always the same as my calculated one and after changing my code I now also handle the gain -19dB values.

The PLR I calculate takes peak_db into account and also results in positive values which I display rounded to the nearest integer.
So my code always shows positive values for LUFS and PLR unless crazy tracks appear with gains like -19 dB (or crazy peak_db).

Today 0.6.9 pops up and shows a rounded value for PLR that has the opposite sign of LUFS-I.
The fact that it is rounded makes that I cannot be sure your values and my calculated value match. When I round my PLR value so far they are always the same as yours.

Maybe the confusion comes because of different units (gain and PLR in dB and LUFS-I/S/M in LUFS (and LRA in LU)).
LUFS calculation takes place with a value in dB, but the result is in LUFS.
PLR calculation takes place with values in dB, and the result is in dB.

Anyway, I'd like your tool to publish PLR with two decimals as well.