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
21
Support - (fb2k) / Re: Newer foobar2000 Versions and 'fact' Chunks
Last post by Porcus -
https://www.mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/WAVE.html points out some ambiguity on when it should/must be present. But from the spec 3.0, page 12:

The fact chunk will be expanded to include any other information required by future WAVE
formats. Added fields will appear following the <dwSampleLength> field. Applications can use
the chunk size field to determine which fields are present.

So it seems you should have had a <dwSampleLength> field first, and then an added field?
22
3rd Party Plugins - (fb2k) / Re: foo_truepeak True Peak Scanner
Last post by Defender -
Quote from: Case on
@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.
Fine. You checked what you are publishing and it is correct.

I will still be displaying the negated version of LUFS because of esthetics and the idea that values are "better" the larger the positive values are. Just like the LRA, PLR and DR values that sit next to LUFS-I in my display. No confusion also because I display them as Li16, so without the units.

Not an issue, but an observation:
I checked the PLR values I calculate with yours and in some cases they differ by either -0.01 or +0.01. In the calculations I don't use $div or $mod and the precision of the peak and gain tags is 2, and since our LUFS values are always the same (negated that is) the difference can only be explained if you calculate PLR with values with a higher precision than 2.

Thx for the swift PLR decimal fix.
24
Support - (fb2k) / Re: Newer foobar2000 Versions and 'fact' Chunks
Last post by Nick.C -
Indeed it is, but given that lossyWAV only processes PCM, I "appropriated" the chunk (in a context where it would not be used) to store the processing settings, e.g. "lossyWAV beta 1.4.3c @ 22/05/2024 16:06:41, --quality standard". While this is not particularly needed when correction files are not created, other than to indicate that the file has already been processed and to issue a warning if the file is reprocessed, it's needed when correction files are created - specifically to allow checks to be performed to see if two files should be merged.

While bughunting I also noticed that later versions of foobar2000 do handle / ignore 'FACT' chunks, but don't ignore 'fact' chunks.

25
foobar2000 for Mac / Re: foobar2000 for Mac: bugs & wishes
Last post by Peter -
Column width bug, fixed for the next update, thanks for reporting.

Quote from: Guildencrantz on
Another problem is that now there are two menu items both called Album List: one shows it in a separate window (naturally, I created a shortcut for it) and the other is responsible for the one living in the side bar. Now my shortcut only shows me the Album List in a separate window but does nothing to the one in the side bar (though it is shown in the corresponding menu item). I think that something should be done with this, though I’m not sure what exactly (renaming menu items probably? but how?).
Not sure what you mean two menu items, there's no menu item for showing the embedded Album List.
Ideally I'd like the "Album List" menu item to highlight the embedded Album List if present, cycling tabs if necessary, but I haven't gotten to implementing that yet.
28
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?
30
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.