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
12
3rd Party Plugins - (fb2k) / Re: Dynamic Range plugin
Last post by darkflame23 -
Quote from: omasciarotte on
Quote from: darkflame23 on
We now have DR built into Foobar natively, with this component (and the True Peak Scanner), so can use what we need. It's brilliant for mastering as I can get an instant readout of many different variables, track to track.

Since you’re a mastering engineer, I have to remind you that foobar’s “DR” plug–in is an approximation.

Yeah, it's not a problem for me as I've never taken much notice of DR. I mostly use LUFS-I and peak LUFS-S to give me a quick idea of how loud a track is likely to be before listening. As I said above, those figures have documentation and standardisation, and are widely used in the audio industry, unlike DR which I've rarely heard an engineer refer to.
13
Support - (fb2k) / Re: Newer foobar2000 Versions and 'fact' Chunks
Last post by Porcus -
Yeah, so Microsoft being Microsoft being unclear, but just indicating that if it is there, you got to have the sample count and currently they haven't thought of more ... but no definite MUST, and not even specifying completely clearly whether it is sample count per channel although it doesn't make sense otherwise.

Checked the BWF spec from 2011. It doesn't say anything more.
15
Lossless / Other Codecs / Re: HALAC (High Availability Lossless Audio Compression)
Last post by Hakan Abbas -
Thank you for the valuable information you gave, Porcus.
Since Flac or some other codecs act according to Rice encoding, there may be such exceptions based on block size. however, HALAC may act structurally more flexible. Rice coding definitely has strengths on audio data. Actually, I was thinking of partially using Rice coding in the next versions, but right now I'm trying to complete the DLL and Player issue in detail with 0.2.8 (as long as I can find the opportunity and concentrate).
16
Support - (fb2k) / Re: Newer foobar2000 Versions and 'fact' Chunks
Last post by Nick.C -
Thanks *very* much for a link to that specification, as I've never encountered it before and have relied on the Wikipedia pages.

From the same document:

"This chunk is required for all WAVE formats other than WAVE_FORMAT_PCM. It stores file
dependent information about the contents of the WAVE data. It currently specifies the time length of the
data in samples."

Which, to my reading, can be read as the chunk not being needed for PCM at all and that its contents are not fixed (noting the use of "currently" in relation to what is contained in the chunk).
18
General - (fb2k) / DSD settings in foobar
Last post by Madmo -
Hey, I'm relatively new to using foobar. I downloaded a DSD file and it plays but the volume is really low and seems out of phase. I think I have the components needed to play. But I can't seem to get this file to play properly.

Does anyone have any ideas?
19
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?
20
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.