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
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).
22
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?
23
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.
26
Recycle Bin / Re: [NecroPost] Best practive to reeendoce previously 64k speech/music audiobook (Audi
Last post by MihaiPopa12346 -
Quote from: encoder on
I can legally extract the audio out of it by various means; I get a WAV. What is the best method to reencode this WAV not to waste that much space on my MP3 player but also does not sound like cr*p?
Try MP3enc 3.1 (by Fraunhofer) because I just made a post: https://hydrogenaud.io/index.php/topic,125973.html and it's true that MP3enc is good for your project and beats LAME in my tests I did. LAME is meh (fair, crap)...
Download MP3enc: https://www.rarewares.org/rrw/mp3enc.php
30
3rd Party Plugins - (fb2k) / Re: foo_truepeak True Peak Scanner
Last post by Case -
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...