IPB

Welcome Guest ( Log In | Register )

2 Pages V  < 1 2  
Reply to this topicStart new topic
Pathological example of a intersample peak, 11dB, discussion.
2Bdecided
post Jan 14 2013, 13:00
Post #26


ReplayGain developer


Group: Developer
Posts: 5062
Joined: 5-November 01
From: Yorkshire, UK
Member No.: 409



QUOTE (Rescator @ Jan 13 2013, 23:51) *
bandpass, 2bdecided, saratoga and John Siau will hopefully find this interesting.

4th post here http://www.hydrogenaudio.org/forums/index....st&p=820447
has a .CSV with the raw data from a scan.

Thanks for this.

Are you seeing what I'm seeing? i.e. do an X-Y plot of column B against column D.

I see two series emerge - one effectively a Y=X line, but another a Y=X+8dB line. What's that? Am I doing something wrong, or not thinking, or is there an error in some of the data (maybe in the decoding of one format)?

From the X=Y line, and where the points start to depart from it (i.e. where inter-sample peaks start to become significantly higher than on-sample peak values), it seems that inter-sample peaks are (mostly) only a problem for tracks in your collection with on-sample peaks above -1dB. i.e. it's only tracks that were (nearly) clipped which generate intersample overs (with a small handful of exceptions).

Cheers,
David.

This post has been edited by 2Bdecided: Jan 14 2013, 13:01
Go to the top of the page
+Quote Post
Rescator
post Jan 14 2013, 16:49
Post #27





Group: Members
Posts: 73
Joined: 13-January 09
From: Trondheim
Member No.: 65515



QUOTE (2Bdecided @ Jan 14 2013, 13:00) *
Are you seeing what I'm seeing? i.e. do an X-Y plot of column B against column D.

No! I Do not have MatLAB or whatever. (can't afford to pay thousands).
A quick search for tools on the net turned up nothing for windows. (and I'm not keen to start compiling gnuplot, or doing CSV to JSON conversion to use Googles API etc.)
So if you could point me to a tool for windows, or show an image that would be helpful smile.gif

As to the anomalies you seem to point out. Sox just processed whatever foobar gave it.
It is possible that either foobar passed bad audio/wav data to sox (my code did not alter any data at all, clean passtrough), or that Sox choked on some bitdepth/frequency/channel combo.
I probably won't rerun this test anytime soon (6 cores at 100% for 4 hours is a little on the heavy side) until a proper toolset is available. Maybe the R128 gain tool could be modified to append csv data lines to a file.

Scanning for "true peaks" the way that EBU R128 recommend is of particular interest obviously.
I could make a tool myself, but I have not found any example codes on upsampling and peak scanning, and I don't really read "math" equations.
The tiny tool I made and hooking it up between foobar and sox and the scanning took me a day. If I'm to spend any more time then it's better to do it right, read up and code a program program, and then it's suddenly about a week (or more) of work involved, (modifying an existing tool might be easier for existing maintainers, for me it would probably take me a week or so if unlucky, to learn/read the existing code enough to modify it).

I'd love to see hundreds of people on HA scan their collections, provide the csv and then someone can do some serious number crunching and present the results.
Depending on how many would do the scan and the size of peoples collection/test size the resulting data could number anywhere from a hundred thousand to a million tracks, which is defiantly statistically significant.


This post has been edited by Rescator: Jan 14 2013, 17:05


--------------------
"Normality exist in the minds of others, not mine!" - Rescator
Go to the top of the page
+Quote Post
bandpass
post Jan 14 2013, 17:06
Post #28





Group: Members
Posts: 326
Joined: 3-August 08
From: UK
Member No.: 56644



Using LibreOffice (free and available on Windows):

Go to the top of the page
+Quote Post
2Bdecided
post Jan 14 2013, 17:20
Post #29


ReplayGain developer


Group: Developer
Posts: 5062
Joined: 5-November 01
From: Yorkshire, UK
Member No.: 409



Yep, that's exactly it.

(I just used Excel).

That upper "series" (Y=X+8dB) must be wrong, and is contaminating your results for the number of intersample overs above 0dB FS.


I'm coming at this from the other direction - I suspect that, in the context of EBU R128, consideration of intersample peak is irrelevant for content that reaches the consumer. Any consumer-targeted audio track that is loudness matched to -23LUFS is very unlikely to have any content near clipping, and as long as the actual samples sit below 0dB FS I bet the intersample peaks are safe too (except on a track intentionally created to disprove this statement!).

For pop CDs, which are often 10-15dB louder than EBU R128 requires, and often smashed/clipressed to be as loud as possible, then of course intersample overs are a real issue.

Cheers,
David.

This post has been edited by 2Bdecided: Jan 14 2013, 17:21
Go to the top of the page
+Quote Post
John_Siau
post Jan 14 2013, 18:22
Post #30





Group: Members
Posts: 84
Joined: 28-July 09
From: Syracuse, NY USA
Member No.: 71848



QUOTE (Rescator @ Jan 13 2013, 18:51) *
bandpass, 2bdecided, saratoga and John Siau will hopefully find this interesting.

The 3.71% in the +1 to +2 range and the 0.79% in the +2 to +3 range is very worrying, but a DAC like that mentioned by John Siau should handle this fine.

Where it really gets creepy is the >3dBFS ISPs, 3.62% total in the +3 to >+9 dBFS range.

Hopefully you guys find the .csv interesting, 5824 tracks is a rather large sample of data and thus hopefully useful.

Wow, nice work. I am somewhat surprised to see anything over +3.1 dB. It would be very nice to take a closer look at the tracks that exceed +3 dB. It would also be interesting to compare raw tracks to mp3 versions of the same track. I suspect that mp3 compression and reconstruction may increase the occurence of inter-sample overs (due to phase distortions in the mp3 compression process).

The Benchmark DAC2 HGC can handle a +3.5 dB inter-sample peak without clipping while the gain control is fully clockwise. It can tolerate higher levels when the gain control is rotated to a lower gain setting.


--------------------
John Siau
Vice President
Benchmark Media Systems, Inc.
Go to the top of the page
+Quote Post
John_Siau
post Jan 14 2013, 18:40
Post #31





Group: Members
Posts: 84
Joined: 28-July 09
From: Syracuse, NY USA
Member No.: 71848



The "+11 dB" test signal (that started this thread) is proving very useful for testing the overload characteristics of DSP code. If the DSP process is working properly, the inter-sample peak should pass at full amplitude (when there is sufficient headroom), or should be clipped when there is insufficient headroom. The ES9018 D/A conversion IC seems to invert the inter-sample peak in some modes of operation.


--------------------
John Siau
Vice President
Benchmark Media Systems, Inc.
Go to the top of the page
+Quote Post
Rescator
post Jan 14 2013, 19:37
Post #32





Group: Members
Posts: 73
Joined: 13-January 09
From: Trondheim
Member No.: 65515



QUOTE (John_Siau @ Jan 14 2013, 18:40) *
The "+11 dB" test signal (that started this thread) is proving very useful for testing the overload characteristics of DSP code. If the DSP process is working properly, the inter-sample peak should pass at full amplitude (when there is sufficient headroom), or should be clipped when there is insufficient headroom. The ES9018 D/A conversion IC seems to invert the inter-sample peak in some modes of operation.

Cool to hear, although it's rare to see such in normal music, I guess it's nice to be able to test how software/hardware handles the outliers (where usually odd things can occur).


--------------------
"Normality exist in the minds of others, not mine!" - Rescator
Go to the top of the page
+Quote Post
Rescator
post Jan 14 2013, 20:29
Post #33





Group: Members
Posts: 73
Joined: 13-January 09
From: Trondheim
Member No.: 65515



(@bandpass Darn you, stop teaching me new tricks. PS! Libre crashed 3 times trying to plot this stuff. Heh! and thanks, had no idea Libre or OO could do that...)

QUOTE (2Bdecided @ Jan 14 2013, 17:20) *
I'm coming at this from the other direction - I suspect that, in the context of EBU R128, consideration of intersample peak is irrelevant for content that reaches the consumer. Any consumer-targeted audio track that is loudness matched to -23LUFS is very unlikely to have any content near clipping, and as long as the actual samples sit below 0dB FS I bet the intersample peaks are safe too (except on a track intentionally created to disprove this statement!).

For pop CDs, which are often 10-15dB louder than EBU R128 requires, and often smashed/clipressed to be as loud as possible, then of course intersample overs are a real issue.

*nod* My last 3 albums released has an RMS of around -23 dBFS, future projects of mine will "target" around RMS -26 dBFS as that seems to be close to EBU R128's -23 LUFS pretty close.

QUOTE (2Bdecided @ Jan 14 2013, 17:20) *
That upper "series" (Y=X+8dB) must be wrong, and is contaminating your results for the number of intersample overs above 0dB FS.


Yeah! *sigh* Looks like I have to revisit this later as this is really irking me now.
Check this out: http://imageshack.us/photo/my-images/688/scanuy.jpg/
Sorted by peak from lowest to highest.

Top left are peaks, bottom left is RMS, and the right/big one is the intersample peaks.
Both the Peak and RMS seem to correlate as expected, and even as the peaks max out (at 0.0 dBFS) the RMS shows the continued squashing going on.
And the ISP seems to match (if we ignore that "shadow" hanging over it there for a moment), and it's not until the very last ~0.70% of tracks that the ISP's go above 3.5 dBFS.

But back to that shadow (or cloud is perhaps more appropriate) hanging there, if one assumes they are 8dB "off" and adjust them "down" then they seem to match with the rest of the curve. Which is most likely correct.

Then again something else may be going on, I'll defiantly get back to this again later (with a updated/corrected csv for you guys) I just do not know when, I'f I'm going to waste a day on this again I might as well make sure it's correct, and that any sox errors/failures or foobar2000 issues can be handled, I'll also grab more data (like channels, codec (mp3 flac, wav, ogg, m4a, etc), bitdepth, frequency, and anything else I can think of/grab at the same time.
And if that anomaly rears it's head again, I'll make sure I track the filepaths so I can check the offenders if it's either damaged files/bad encodings or something else. (my guess is it was weird output from sox that my tool wasn't programmed to parse).

For those curious, it looked for "Pk lev dB" and "RMS lev dB" from the first stat and just "Pk lev dB" from the second stat. And only the first number was grabbed (for multichannel 2 or more numbers would be presented and intentionally ignored), any sox output that did not contain this info would get ignored.
Also if any Pk or RMS was NOT grabbed properly but still went into the csv then those will show up as either -999 or +999 values, and I see no such values, so it was either the wav passed to sox or sox itself that provided dodgy data.

But I will revisit this, I can not promise when though, I need to set aside a day, and if possible use a different tool than Sox (using foobar2000 as the "decoder" is very practical), peak, rms and some way to get ISP's or upsample and gather the peaks is all I need. Heck, even a upsampler with support for piping is all I need, I can code a peak scanner that do 32bit or even 64bit float peak scanner myself fairly quickly.

I could probably code something similar to sox's "upsample 4 sinc -a 40 -t 8k -24k" if I got some pointers/help though. (no idea how/where to start making a upsampler at all, any ANSI C code out there?).


--------------------
"Normality exist in the minds of others, not mine!" - Rescator
Go to the top of the page
+Quote Post
Wombat
post Jan 14 2013, 22:31
Post #34





Group: Members
Posts: 985
Joined: 7-October 01
Member No.: 235



After reading about that topic a bit i found that iZotope offers a feature build into their limiter that has intersample detection for "True Peaks"
Since Alexej Lukin is member here and to my understanding is part of the iZozope team he may give us some idea how they reched their conclusion of the peaks in music hitting above 3dB. Interesting is their limiter now seems to be able to prevent this directly while mixing it hot.
http://www.izotope.com/support/help/ozone/...s_maximizer.htm
Go to the top of the page
+Quote Post
bandpass
post Jan 15 2013, 09:57
Post #35





Group: Members
Posts: 326
Joined: 3-August 08
From: UK
Member No.: 56644



QUOTE (Rescator @ Jan 14 2013, 19:29) *
if that anomaly rears it's head again, I'll make sure I track the filepaths so I can check the offenders if it's either damaged files/bad encodings or something else.

I'd do this as a matter of course as it's needed to further investigate this anomaly, any other anomaly that might occur in future, and any track with an otherwise interesting result.

QUOTE (Rescator @ Jan 14 2013, 19:29) *
I could probably code something similar to sox's "upsample 4 sinc -a 40 -t 8k -24k" if I got some pointers/help though.

With the above in place I don't think it will be difficult to find and fix the problem, but otherwise see http://www.dspguru.com/dsp/faqs/multirate/interpolation (includes c-source) and http://www.itu.int/dms_pubrec/itu-r/rec/bs...;!PDF-E.pdf for the filter coefs.
Go to the top of the page
+Quote Post
knutinh
post Feb 4 2013, 09:20
Post #36





Group: Members
Posts: 569
Joined: 1-November 06
Member No.: 37047



Since inter-sample overshoot is a problem for the analog stage of a DAC, what would happen at the corresponding stage in an ADC, assuming the same analog/digital waveform? Would it clip (producing different digital samples, implying that the samples can only be greated digitally), or would it just pick non-clipped samples? I guess that depends on if the ADC is essentially a text-book passive analog filter hooked up to a point-sampler, or if it is a multirate (digitally filtered using fixed-point arithmetics) design.

It seems that inter-sample over values are quoted with great accuracy and confidence, even though the exact reconstruction filter is not specified. Are you using an accurate approximation of the ideal sinc filter when discussing this? I guess that a different filter (e.g. lower bandwidth, non-linear phase) could produce fairly different results.

-h
Go to the top of the page
+Quote Post
bug80
post Feb 4 2013, 12:45
Post #37





Group: Members
Posts: 398
Joined: 23-January 05
From: The Netherlands
Member No.: 19254



QUOTE (Rescator @ Jan 14 2013, 16:49) *
QUOTE (2Bdecided @ Jan 14 2013, 13:00) *
Are you seeing what I'm seeing? i.e. do an X-Y plot of column B against column D.

No! I Do not have MatLAB or whatever. (can't afford to pay thousands).

Off-topic, but take a look at GNU Octave. It's a free Matlab-clone, with the same syntax (so your old .m scripts still work).
Go to the top of the page
+Quote Post
2Bdecided
post Feb 4 2013, 13:08
Post #38


ReplayGain developer


Group: Developer
Posts: 5062
Joined: 5-November 01
From: Yorkshire, UK
Member No.: 409



QUOTE (knutinh @ Feb 4 2013, 08:20) *
Since inter-sample overshoot is a problem for the analog stage of a DAC...
It's also a problem for the digital section, i.e. the over sampling + reconstruction filter.
QUOTE
...what would happen at the corresponding stage in an ADC, assuming the same analog/digital waveform?
No sane person digitally samples at levels near clipping - they leave sufficient headroom. Insane people who push the levels like that will probably get clipping, either due to the analogue electronics, the digital processing (oversampling ADC and digital anti-alias filter), or the fact that the peak happens to occur on-sample rather than between samples.

The concern is almost completely with audio that has been processed after the ADC to increase the apparent loudness.

QUOTE
It seems that inter-sample over values are quoted with great accuracy and confidence, even though the exact reconstruction filter is not specified.
The EBU R128 definition is pretty strict, though it doesn't necessarily give the absolute highest possible true peak.

Cheers,
David.
Go to the top of the page
+Quote Post
John_Siau
post Feb 4 2013, 18:08
Post #39





Group: Members
Posts: 84
Joined: 28-July 09
From: Syracuse, NY USA
Member No.: 71848



QUOTE (2Bdecided @ Feb 4 2013, 07:08) *
QUOTE (knutinh @ Feb 4 2013, 08:20) *
Since inter-sample overshoot is a problem for the analog stage of a DAC...
It's also a problem for the digital section, i.e. the over sampling + reconstruction filter.


Inter-sample overs are also a problem for any sample-rate conversion process. ASRC devices will produce many spurious tones when inter-sample clipping occurs. The solution is to reduce the signal level before executing the SRC process. In our DAC2 HGC converter, we reduce the signal level by 3.5 dB before the upsampling.


--------------------
John Siau
Vice President
Benchmark Media Systems, Inc.
Go to the top of the page
+Quote Post
Alexey Lukin
post Feb 4 2013, 19:49
Post #40





Group: Members
Posts: 191
Joined: 31-July 08
Member No.: 56508



QUOTE (Wombat @ Jan 14 2013, 17:31) *
After reading about that topic a bit i found that iZotope offers a feature build into their limiter that has intersample detection for "True Peaks"
Since Alexey Lukin is member here and to my understanding is part of the iZotope team he may give us some idea how they reached their conclusion of the peaks in music hitting above 3dB. Interesting is their limiter now seems to be able to prevent this directly while mixing it hot.
http://www.izotope.com/support/help/ozone/...s_maximizer.htm

This +3 dB figure is pretty arbitrary. I think that in practice maybe some 1% of mastered records will show this true peak level. The absolute maximally possible true peak overshoot cannot be specified precisely because it depends on the length and phase response of the DAC's reconstruction filter. If filters are long enough and the signal is specially crafted, there's no theoretic limit for the level of TP overshoot.
Go to the top of the page
+Quote Post
knutinh
post Mar 4 2013, 13:58
Post #41





Group: Members
Posts: 569
Joined: 1-November 06
Member No.: 37047



QUOTE (2Bdecided @ Feb 4 2013, 13:08) *
QUOTE (knutinh @ Feb 4 2013, 08:20) *

It seems that inter-sample over values are quoted with great accuracy and confidence, even though the exact reconstruction filter is not specified.
The EBU R128 definition is pretty strict, though it doesn't necessarily give the absolute highest possible true peak.

Cheers,
David.


I vaguely remember something about "phase scrabling" peaks in radio transmission - i.e. messing with the phase so as to minimize peaks while keeping the average levels (or, effectively maximizing the average levels with minimal audible distortion).

Could this be done in a DAC/SRC application? If complexity/delay was of no concern, one could choose between a set of prototype filters that sounded equally good, selecting the filter that minimized intersample overs? Is not this a neater (although certainly overkill) solution than throwing away a few dB of SNR for all material?

Or, one could have a two-path filtering, switching to a cruder interpolation in those few segments where intersample overs are an issue (linear interpolation?)

-k
Go to the top of the page
+Quote Post
John_Siau
post Mar 4 2013, 17:51
Post #42





Group: Members
Posts: 84
Joined: 28-July 09
From: Syracuse, NY USA
Member No.: 71848



QUOTE (knutinh @ Mar 4 2013, 07:58) *
I vaguely remember something about "phase scrabling" peaks in radio transmission - i.e. messing with the phase so as to minimize peaks while keeping the average levels (or, effectively maximizing the average levels with minimal audible distortion).

Could this be done in a DAC/SRC application? If complexity/delay was of no concern, one could choose between a set of prototype filters that sounded equally good, selecting the filter that minimized intersample overs? Is not this a neater (although certainly overkill) solution than throwing away a few dB of SNR for all material?


The simple solution is to reduce the signal amplitude prior to the SRC and DAC. With a 24-bit data path, a 3 to 6 dB reduction in gain is of little consequence. The 24-bit data path has a dynamic range of approximately 144 dB, and a loss of 3 to 6 dB should be insignificant. Please note that this digital gain reduction must be made up after the DAC to achieve the same playback levels. This means that there are higher demands on the performance of the DAC.

Throwing away 3 to 6 dB of SNR is probably the best choice give the fact that DAC ICs are available with very good SNR specifications.


--------------------
John Siau
Vice President
Benchmark Media Systems, Inc.
Go to the top of the page
+Quote Post
2Bdecided
post Mar 4 2013, 18:21
Post #43


ReplayGain developer


Group: Developer
Posts: 5062
Joined: 5-November 01
From: Yorkshire, UK
Member No.: 409



QUOTE (knutinh @ Mar 4 2013, 12:58) *
I vaguely remember something about "phase scrabling" peaks in radio transmission
Yes. It's also sometimes called Phase Rotation. It's in Optimods and the like. It helps to make asymmetric waveform more symmetric.

One problem is that real-world clipressed audio has probably already been through one. Using this technique again might not generate lower peaks.

QUOTE
- i.e. messing with the phase so as to minimize peaks while keeping the average levels (or, effectively maximizing the average levels with minimal audible distortion).

Could this be done in a DAC/SRC application? If complexity/delay was of no concern, one could choose between a set of prototype filters that sounded equally good, selecting the filter that minimized intersample overs? Is not this a neater (although certainly overkill) solution than throwing away a few dB of SNR for all material?
I don't think any one would want it in-circuit all the time, and switching could introduce audible transients. There might be a way around it.

QUOTE
Or, one could have a two-path filtering, switching to a cruder interpolation in those few segments where intersample overs are an issue (linear interpolation?)
If you have no headroom, and it clips, the only choice is to clip it. There is no room even for linear interpolation.

You can use soft or hard limiting, or even a gentle AGC that only acts in the presence of inter-sample overs. I think this would sound worse than just clipping. Anything you do in a typical DAC will be very fast acting (not always desirable) because they introduce so little delay.

Like John, I think the better choice is simple to "throw away" a little headroom. I have never heard of the DAC noise floor being a practical problem (except in older systems without an analogue volume control - i.e. all digital volume control).

Cheers,
David.
Go to the top of the page
+Quote Post

2 Pages V  < 1 2
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 29th July 2014 - 23:08