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.
We at MAAT GmbH make digital audio products mostly used by mastering engineers. We also make a few products, like DRMeter, DROffline MkII, MAATgo, and our equalizers, that are also loved by audio enthusiasts worldwide.
This is a pitch to all you connoisseurs out there who are curious about:
adding pristine tone control or system voicing to your signal chain
adding what pros call “monitor controls”
All our plug–ins are delivered in the cross–platform VST 2 & 3 formats, along with AU and AAX. That implies you already are using a plug–in host that recognizes one of those formats…
Interested? Give me a shout at oliver at our maat dot digital domain.
P.S. — Sorry about the woefully out of date signature. No matter what I’ve tried, I cannot get signature updates to “stick.”
Last post by AlexVallat -
I've updated beatport.boo, should be working now. I'm not going to start dealing with OAuth, it's a total pain, so I'll just use public endpoints.
@Porcus (I) At lower sampling rates, noise shaping can't push the noise into the inaudible frequencies because they are above the Nyquist limit. (I) I don't know the ideal values.
Last post by Klymins - @Porcus (I) At lower sampling rates, noise shaping can't push the noise into the inaudible frequencies because they are above the Nyquist limit. (I) I don't know the ideal values.
Would you be interested in more statistics in the output? Just knowing that samples clip doesn't yet tell how bad it is. Exceeding the full scale by 0.1 dB would not matter at all, but exceeding it by 3 dB could be a problem. I could for example log how large percentage of clipping exceeded full scale by 1 dB, how much by 2 dB, etc.
After reading this, it got me thinking of what the "Clipping Samples" or "Album Clipping" actually tells us. I have some tracks that show thousands of clips and I have only scanned a handful of tracks, are the clips only 0.1 dB over, hard to say... Understanding how far the clip exceeds full scale by % of clips makes sense. Similar to what you described. % clips >1dB, % clips >2dB, % clips >3dB, etc., would give a user an understating of the impact of the clipping.
I spent some time today to think about what kind of statistics to gather from clipping, here's an experimental implementation: https://foobar.hyv.fi/foo_truepeak_clip_report_testing.fb2k-component I hope people don't quote this link as the component will be nuked once testing is done, leaving quotes with bad links behind.
The new experimental statistics aren't shown on the result dialog or tagged, they are only printed to foobar's console. So it's best to test that with only one track.
True Peak Scanning track: G:\Music\Lossless\Metallica\(2008) Death Magnetic\05. All Nightmare Long.flac Oversampling to 352800 Hz with Resampler (SoX) Clip stats: ch0: peak: 1.3002197 (2.2803346 dB), pos: 0:30.708, max clip rms: 1.2160325 dB, pos: 0:30.708, max consecutive clipping samples: 16.0000000 (0:00.000 s), total clipping samples: 377258 (0:01.069 s) Clip stats: ch1: peak: 1.2273319 (1.7792406 dB), pos: 0:19.988, max clip rms: 1.0105605 dB, pos: 1:01.660, max consecutive clipping samples: 17.0000000 (0:00.000 s), total clipping samples: 781139 (0:02.214 s) Clip stats track:: peak: 1.3002197 (2.2803346 dB), pos: 0:30.708, max clip rms: 1.2160325 dB, pos: 0:30.708, max consecutive clipping samples: 17 (0:00.000 s), total clipping: 1158397 (0:03.283 s) Clip histogram: peak at 0.0 - 0.1 dB: 1038987 samples (89.69 %) peak at 0.1 - 0.2 dB: 78387 samples (6.77 %) peak at 0.2 - 0.3 dB: 21630 samples (1.87 %) peak at 0.3 - 0.4 dB: 8597 samples (0.74 %) peak at 0.4 - 0.5 dB: 4253 samples (0.37 %) peak at 0.5 - 0.6 dB: 2362 samples (0.20 %) peak at 0.6 - 0.7 dB: 1473 samples (0.13 %) peak at 0.7 - 0.8 dB: 910 samples (0.08 %) peak at 0.8 - 0.9 dB: 605 samples (0.05 %) peak at 0.9 - 1.0 dB: 394 samples (0.03 %) peak at 1.0 - 1.1 dB: 293 samples (0.03 %) peak at 1.1 - 1.2 dB: 188 samples (0.02 %) peak at 1.2 - 1.3 dB: 138 samples (0.01 %) peak at 1.3 - 1.4 dB: 76 samples (0.01 %) peak at 1.4 - 1.5 dB: 49 samples (0.00 %) peak at 1.5 - 1.6 dB: 23 samples (0.00 %) peak at 1.6 - 1.7 dB: 13 samples (0.00 %) peak at 1.7 - 1.8 dB: 5 samples (0.00 %) peak at 1.8 - 1.9 dB: 4 samples (0.00 %) peak at 2.0 - 2.1 dB: 4 samples (0.00 %) peak at 2.1 - 2.2 dB: 3 samples (0.00 %) peak at 2.2 - 2.3 dB: 2 samples (0.00 %) peak at 1.9 - 2.0 dB: 1 samples (0.00 %)
I think you are on to something. How granular the histogram has to be is a good question. Do we need it by 0.1? Is sure does show that your file have a ton of clips, but approx 90% are 0.1 or lower. I think this helps explain the impact of the clip result.
Oversampling to 192000 Hz with Resampler (SoX) Clip stats: ch0: peak: 1.0216434 (0.1859869 dB), pos: 0:34.500, max clip rms: -0.0615525 dB, pos: 0:32.646, max consecutive clipping samples: 1.0000000 (0:00.000 s), total clipping samples: 3 (0:00.000 s) Clip stats: ch1: peak: 1.0251275 (0.2155575 dB), pos: 0:34.500, max clip rms: -0.0170493 dB, pos: 0:26.200, max consecutive clipping samples: 1.0000000 (0:00.000 s), total clipping samples: 2 (0:00.000 s) Clip stats track:: peak: 1.0251275 (0.2155575 dB), pos: 0:34.500, max clip rms: -0.0170493 dB, pos: 0:26.200, max consecutive clipping samples: 1 (0:00.000 s), total clipping: 5 (0:00.000 s) Clip histogram: peak at 0.0 - 0.1 dB: 2 samples (40.00 %) peak at 0.1 - 0.2 dB: 2 samples (40.00 %) peak at 0.2 - 0.3 dB: 1 samples (20.00 %) True Peaks calculated in: 0:01.280, speed: 31.15x
How this is presented is another story. You can't write 20 tag values for this.. Output .txt file? That would get to be a lot of data. I like what you have here. Thanks for spending time on it.
I see you are Oversampling to 352800. I left mine at the default of 192000. Higher the more accurate and most of my files are 44100, so I could probably look to change it to 352800.... Factor of 8. I thought it would pick an even factor when oversampling. My 44.1k resampled to 192k.
Last post by Porcus -
First, QOA wasn't constructed to be transparent. It was intended to be "Quite OK" at very light decoding load. But I guess you know.
"Obviously" such a quantization calls for a noise shaping algorithm. How to round off each sample residual to one of the values implied by the dequant table. Given that the format has been published and frozen - a decoder has found its way into ffmpeg too - then if you want a revision you probably need to (I) give a case for the need for it and (II) what does actually improve. For (I), not only "but it could sound better" but also why that cannot be solved by noise shaping upon encoding; for (II), not only "I want another bit in the dequant table and I'm willing to reduce the 8 bytes slice coverage to only 15 samples", but what values for the new table.