Invitation: Audible intersample clipping test

[bennetng]

The test signal is attached at the end of this post:

https://forum.cockos.com/showthread.php?t=201868

Basically I don't like the idea of blaming those who make music or DACs for intersample clipping since there is no absolute clipping point. My test signal is a bit more sophisticated than the one used in TC Electronic and Benchmark's article/paper. I realize members in ASR like measurements so you are also encouraged to measure your equipment with my test signal.

Thanks.

 

[amirm]

I will test later when I am in my lab. Then again, for grins i tried to play it on my laptop speakers and it created tinnitus in my ears like I have never heard! And I could hear/sense very high pitch sound. I started at low volume and went nuts after just a few seconds and at low volume no less!!!

Looking at the spectrum, I see there is a sum of three high frequency tones. I am concerned about hearing damage for members. Is there a reason you picked such high frequency components?

I am very interested in this type of test though.

 

[RayDunzl]

4.66dB over...

Nice trick...

 

[bennetng]

The test signal is aimed at adding sample points in a continuous and audible (if clipped) way after upsampling, either by a software upsampler or a hardware DAC. Here is a screenshot of original (right) and 4x upsampling (left).

Yeah. Ray's response is very fast. Thanks.

 

[RayDunzl]

I see 4.66dB overs in your test file, which seems to invalidate (maybe) this blurb about "worst case" from Benchmark:

"It is possible to build interpolators that will not clip or overload, but this is not being done by the D/A and SRC chip manufacturers. For this reason, Benchmark has moved some of the digital processing outside of the D/A chip. In the Benchmark DAC2 and DAC3 converters we have an external interpolator that has 3.5 dB of headroom above 0 dBFS. This means that the worst-case +3.01 dBFS intersample peaks can be processed without clipping."

https://benchmarkmedia.com/blogs/application_notes/intersample-overs-in-cd-recordings

 

[bennetng]

I am not a Benchmark hater (or fanboy). The reason for making this test signal is to prove that it is possible to make audible intersample peaks with relatively high values.

I know some people for example believe that replacing the CR2032 cell on a PC motherboard to another brand can improve sound quality but don't believe intersample peaks. They think reducing volume in digital domain harms bit-perfectness.

Just reduce the playback volume of your playback software then you don't need a Benchmark.

 

[Blumlein 88]

That is a potentially tweeter busting test signal.

We have discussed this some here before only using white noise. Don has shown it is possible to get intersample overs of around 10 db at times.

We used some white noise in the other thread where this was discussed. I use -4db white noise in setting levels for testing. It is around - 4db in my experience where these overs mostly go away though you still get some. At higher levels you get plenty some being rather high in level. If you run high level white noise long enough you'll have to reduce to about -10 db to get none.

Our method in the other thread was to create long files of white noise and oversample them 8 times in software. Benchmarks decision on how much to reduce the level to prevent these mirror my own idea that -4db is a good choice. 3.5 to 4 db reduction gets rid of nearly all you might encounter with synthetic signals. While it doesn't mean no natural signal couldn't cause an over at that point it becomes very, very rare. Rare enough it will not be an on going issue to cause sound quality differences listening to music.

Most IS overs in music are caused by processing usually involving limiting.

 

[bennetng]

I tried a noise-based test signal in the same forum:
https://forum.cockos.com/showthread.php?t=193559

DAW users usually don't manually upsample their files to find ISP, they use BS.1770 compliant "True Peak" meters which aimed at estimate the performance of hardware DACs rather than resamplers. Some resamplers are overly accurate at near Nyquist and result in higher peaks.

Here is my analysis of that noise signal with a resampler with different quality settings and two DACs.
https://forum.cockos.com/showpost.php?p=1863978&postcount=61

While using noise as test signal can yield higher peaks, clipping distortion cannot be measured or heard in the audible band, and that's why I made another test signal. The highest tone in my signal is lower than 18kHz, which means lower than the typical 19+20kHz test signal. Also my signal has a fade-in stage so unless the test signal is being played unattended, users have enough time to reduce the playback volume.

 

[Soniclife]

Is there software you could run your music library through to look for the max real world example?

 

[bennetng]

Is there software you could run your music library through to look for the max real world example?

Yes. foobar2000 support BS.1770 and EBU R128 standard with oversampled "true peak" and "LU" (a replacement of VU) loudness scanner. You can scan and manually edit the desired playback level and they will be saved as metadata in your audio files.

BS.1770 suggests 4x upsampling for 44/48k contents and 2x upsampling for 88/96k contents to detect "true peaks" and has a reference algorithm. 176.4/192k or above are not required to be upsampled.

To enable oversampled peak detection, go to foobar2000's preferences and set the Peak scan oversample factor to at least 2.

ReplayGain is a widely used standard in various audio players (check Wikipedia). It stores Track peak and Album peak as metadata in audio files. Track peak is the peak of individual audio file and album peak is the highest peak of an album. In this way users can maintain the relative loudness of an album during playback.

The peak values are stored as floating point numbers and 1.0 means 0dBFS or 0dBTP if oversampled scanning is enabled. For example there is a track with 1.387928 in my screenshot, copy and paste the following line in google:

20*log(1.387928)

Which means +2.847...dBTP

in foobar2000 and other ReplayGain compliant players, you can specify the audio player to reduce the playback level according to the scanned track peak or album peak.

The "Preamp" section sets a target loudness in terms of LU. By default foobar2000 uses -18LUFS as target but as you can see, there are sliders for you to adjust. With the "prevent clipping according to peak" option selected, even if you set the slider all the way to the right, files with RG info won't clip, but in this way the target loudness cannot be maintained.

 

[Soniclife]

That's great, will it sort by track peak to find the max in your collection?

 

[bennetng]

That's great, will it sort by track peak to find the max in your collection?

Select several tracks in the playlist and right-click > ReplayGain > scan selection as a single album. For example you selected 5 tracks and they have track peaks like these:

1.1
0.8
0.9
1.2
0.7

Then the album peak will be automatically 1.2. There is no need to manually find the highest peak yourself.

 

[stalepie]

Is ReplayGain any different from just turning the volume down? I mean, I'm not talking about per-album vs per-track. I don't see how it affects the peaks. Isn't (almost) the same digital data being played back, but at a lower volume? like you moved Foobar's internal volume setting to 70%?

I get confused when I try to read more about it, like here,
https://hydrogenaud.io/index.php/topic,71537.0.html

"If the volume control is in the digital domain, then whether it's ReplayGain that reduces the volume, or the user, the overall result will be identical. You will get exactly the same digital bits reaching the DAC either way."

whereas the start of the thread the answer is,
"Minimally. The idea of not implementing RG support because it 'degrades audio quality' is a pretty foolish one." (so, not the same bits)

The wiki page at Hydrogen also has a section about ReplayGain potentially causing clipping, not fixing it:
http://wiki.hydrogenaud.io/index.php?title=Replaygain#Clipping

 

[bennetng]

Is ReplayGain any different from just turning the volume down? I mean, I'm not talking about per-album vs per-track. I don't see how it affects the peaks. Isn't (almost) the same digital data being played back, but at a lower volume? like you moved Foobar's internal volume setting to 70%?

I get confused when I try to read more about it, like here,
https://hydrogenaud.io/index.php/topic,71537.0.html

"If the volume control is in the digital domain, then whether it's ReplayGain that reduces the volume, or the user, the overall result will be identical. You will get exactly the same digital bits reaching the DAC either way."

whereas the start of the thread the answer is,
"Minimally. The idea of not implementing RG support because it 'degrades audio quality' is a pretty foolish one." (so, not the same bits)

The wiki page at Hydrogen also has a section about ReplayGain potentially causing clipping, not fixing it:
http://wiki.hydrogenaud.io/index.php?title=Replaygain#Clipping

As I mentioned in reply #10, "With the "prevent clipping according to peak" option selected, even if you set the slider all the way to the right, files with RG info won't clip". I also highlighted the important parts of the screenshots in red.

RG itself only reads and writes metadata in audio files, different audio players can implement their ways of volume manipulation during playback. If the user used an incorrect setting, it can cause clipping, otherwise no. One reason that user has a choice on this option is because foobar has a file converter which supports floating point audio formats which allow audio data to go beyond +/-1.0 range. Here is an example of such a file:

https://audiosciencereview.com/foru...ume-control-in-windows.2031/page-3#post-55577

Also, foobar has a DSP section which you can apply audio effects, it is performed after RG therefore if the DSP section is not empty, depends on what is being done the processed data can exceed +/-1.0 again.

The same/different bit stuff is simple. The term "bit-perfect" in this context means the communication between the end of the playback software's processing pipeline and the audio device driver is unadulterated. It doesn't mean the bits remain unchanged within the playback software.

 

[stalepie]

But why not just reach for the volume dial and turn it down if something is too loud, then turn it up when it is too quiet? isn't that just "manual" replay gain?

 

[bennetng]

But why not just reach for the volume dial and turn it down if something is too loud, then turn it up when it is too quiet? isn't that just "manual" replay gain?

Yes you can do so if you are using WASAPI exclusive or ASIO mode which foobar's output volume control is not being hijacked by Windows CAudioLimiter, but doing so may mute the output of other programs.

https://hydrogenaud.io/index.php/topic,104051.0.html

Also, I mentioned RG in reply #10 because a member asked me how to estimate intersample overs of their audio files, since foobar's RG scanner can do this job so I wrote an introduction of RG in the reply.

 

[bennetng]

I see you wrote "volume dial". To avoid misunderstanding if you mean the physical dial on a DAC, then the DAC itself needs to have digital headroom like the benchmark which Ray mentioned in reply #5, otherwise doing so cannot avoid clipping.

 

[restorer-john]

That is a potentially tweeter busting test signal.

Agreed. This sort of messing around with HF (and inaudible to many people), high level tones is just plain stupid IMO.

Anyone can put high level, high frequency multitones on a file and call it a 'hearing test' or similar, and destroy a whole bunch of expensive tweeters for no good reason, or cause amplifiers to oscillate.

These 'tests' should only dwell in the instrumentation domain, not be reproduced by speakers or headphones. Hearing damage may result.

There's a very good reason I run an FFT on any audio file presented on the internet before listening or using it. Like a virus scanner for audio...

 

[bennetng]

Agreed. This sort of messing around with HF (and inaudible to many people), high level tones is just plain stupid IMO.

Anyone can put high level, high frequency multitones on a file and call it a 'hearing test' or similar, and destroy a whole bunch of expensive tweeters for no good reason, or cause amplifiers to oscillate.

These 'tests' should only dwell in the instrumentation domain, not be reproduced by speakers or headphones. Hearing damage may result.

There's a very good reason I run an FFT on any audio file presented on the internet before listening or using it. Like a virus scanner for audio...

In the link of the Reaper forum post I already mentioned the correct and safe way of using this test file and one member in that forum actually followed my instruction and realized that his interface has about 3dB of headroom. I myself also listened to it.

People cannot download the file without accessing the Reaper forum and read my instruction. I intentionally posted the attachment in the Reaper forum instead of here is also because of this reason. If their equipment are not suitable for performing this test (i.e. they don't have any analog means to reduce playback level) they can still record the output of their DAC using full scale output, and playback the recorded file at reduced volume in order to hear the effect. I can provide these recorded file at reduced volume if they want to evaluate them with their ears, at something like 20dB lower in volume.

 

[Wes]

Benchmark says that these are common on CDs; they give a Steely Dan track as an example, but that is only one CD.