You are not logged in.
You can play square waves through your DAC, if you want.
But it has nothing to do with the topic.
It is off-topic again.
The topic is about "resampling and the Gibbs phenomenon with Audacity".
It is about how resamplers work, it is about math.
It is not about playing square waves though a sound card.
In a word, "384kHz" of DXD is sample rate. It is not frequency.
Resampling is performed in software.
And you are trying to explain how hardware works.
It is very interesting, but it is off-topic.
NOTE: In mathematics, square waves are used to visualize the effect of "jump discontinuities", and you can find them in many text books on Fourier series.
Just imagine what would've happened if the Crowdstrike outage was malicious. I.e., malicious code was pushed to all these servers. Worldwide chaos would ensue.
If it can happen, it will happen sooner or later.
Thanks for answering. It seems that your are satisfied with sound quality.
However, the topic is about "resampling and the Gibbs phenomenon".
If you want to discuss something else, you may start a new topic.
You did not answer my question. May I ask it again?
Do you think that youtube sound quality (through pulseaudio) is good enough?
Recorded over 50 years ago... Without any bells and whistles.
℗ 1967 - It was, perhaps, analogue recording. Without any sort of pulseaudio and without Gibbs.
The World We Knew (Over And Over) · Frank Sinatra
The World We Knew
℗ 1967 Frank Sinatra Enterprises, LLC
Discover the Hi-Res Masters: Frank Sinatra playlist containing all the essential tracks in Hi-Res 24-bit for an unequalled sound quality (FLAC 24-Bit / 192kHz)
It may sound better, perhaps.
Do you think that youtube sound quality (through pulseaudio) is good enough?
The Gibbs phenomenon was observed by experimental physicists and was believed to be due to imperfections in the measuring apparatus, but it is in fact a mathematical result. It is one cause of ringing artifacts in signal processing. It is named after Josiah Willard Gibbs.
_https://en.wikipedia.org/wiki/Gibbs_phenomenon
Square wave
_https://en.wikipedia.org/wiki/Square_wave
Analogue signal is continuous, and digital signal is discrete.
The simplest example of discrete signals is, perhaps, square waves.
Because of "jump discontinuity", square waves don't like resampling.
It doesn't matter which resampler was used, the result is always a sort of Gibbs phenomenon.
![]()
Functional approximation of square wave using 25 harmonics
_https://en.wikipedia.org/wiki/File:Gibbs_phenomenon_50.svg
_https://en.wikipedia.org/wiki/Gibbs_phenomenon
Square waves can be easily created with Audacity.
sudo apt install audacity
1. Open Audacity.
2. Go to Edit > Preferences > Quality
3. Set the project defaults:
Default Sample Rate: 384000 Hz
Default Sample Format: 32-bit float
Sample Rate Converter: Best Quality (Slowest)
And click "OK".
On the bottom left corner of Audacity's main window, you will see Project Rate (Hz) menu. It should be "384000". If not, click on it and select "384000".
Go to Generate > Tone
Waveform: Square
Frequency (Hz): 440
Amplitude: 0.8
Duration: 000,040,000 samples
Click "Generate", and you will see a nice square wave.
On the left side of the audio track, you should see:
Mono, 384000Hz
32-bit float
Now, we can downsample the square wave to 48kHz 16bit (default).
It seems that, in Audacity, the standard Linux resampler (libsamplerate) was already replaced with SoX resampler. Therefore, the result might be a nice Gibbs phenomenon, and not a kind of strange artefact.
Downsampling:
1. Change the sample rate of the project to 48000 Hz (on the bottom left corner of Audacity's main window).
2. Go to File > Export > Export as WAV
Click "Save", then click "OK".
It will be downsampled to 48kHz 16bit (default) and exported as wave.
Check it with "file" command:
$ file 16bit_48kHz.wav
16bit_48kHz.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, mono 48000 Hz
Now, you can open this wave with Audacity and see a sort of Gibbs phenomenon.
You can zoom into it:
Go to View > Zoom > "Zoom in"
Since the public has already complained that all this is "not even remotely scientific", it makes sense, perhaps, to make it more scientific with math.
sudo apt install maxima gnuplot
Let us take a very simple mathematical function
tanh(20*sin(x))
If you plot it with Maxima
$ maxima
(%i1) plot2d([tanh(20*sin(x))], [x,-10*%pi,10*%pi], [y,-1.1,1.1], [plot_format, gnuplot])$
you will see a square wave with "jump discontinuities".
If you zoom into it
$ maxima
(%i2) plot2d([tanh(20*sin(x))], [x,-1.2*%pi,1.2*%pi], [y,-1.1,1.1], [plot_format, gnuplot])$
you will see a continuous function.
It depends on the resolution (that is, sample rate).
If the original wave is 32bit Float 384kHz DXD, and it is a sort of music recording, it is not likely to have very big "jump discontinuities", and, therefore, the Gibbs phenomenon may not produce audible sound distortions with downsampling. It depends, of course, on the quality of resampler as well.
EDIT: To avoid confusion, it might be necessary to provide a sort of mathematical explanation.
Because of "jump discontinuities", Fourier series cannot converge uniformly
_https://en.wikipedia.org/wiki/Convergence_of_Fourier_series
It should be obvious that a series of continuous functions cannot converge uniformly to a function with "jump discontinuities". This is the reason why any sort of interpolation (and any sort of resamplers) fails. That is why you get the Gibbs phenomenon, and, that is why the square wave is not a sum of harmonics (in terms of physics).
_https://en.wikipedia.org/wiki/Harmonic
Digital to audio conversion (DAC) means that a digital signal (that is, a discrete signal of finite sample rate) is converted to analog signal (that is, a continuous signal of infinite sample rate). It might be obvious, therefore, that, when you are playing a square wave through your DAC, you get the same Gibbs phenomenon.
Notice that "the Gibbs phenomenon was observed by experimental physicists and was believed to be due to imperfections in the measuring apparatus, but it is in fact a mathematical result."
_https://en.wikipedia.org/wiki/Gibbs_phenomenon
This also means sound distortions, when you are playing a digital music crap of CD format through your DAC.
If you do not believe that your DAC is playing crap, you can create a square wave of 48kHz 16bit format with Audacity, upsample it to 384kHz 32bit Float DXD format, zoom into it, and you will see the same Gibbs phenomenon.
It doesn't matter whether resampling of a square wave is performed in software or in hardware. The result is always a sort of Gibbs phenomenon. You cannot fool the nature, as it was discovered by experimental physicists and explained by mathematicians.
In short, square waves are used to visualize the effect of "jump discontinuities". It helps to understand why and how resampling produces sound distortions. Since "jump discontinuities" are a natural feature of low resolution formats, such as 48kHz 16bit, it does not make much sense to measure sound quality of this particular sort of digital crap in "blind tests".
NOTE: If it is not obvious that the square wave is not a sum of harmonics, you may try a very simple "imaginary experiment".
Since harmonics, or sinusoidal waves, are continuous functions, you may try to imagine a continuous function.
The sum of two continuous functions is a continuous function. This can be taken for granted.
3 = 2 + 1
4 = 3 + 1
...
100 = 99 + 1
Thus the sum of 100 continuous functions is also a continuous function.
However, the square wave is not a continuous function. It has "jump discontinuities".
What is more, the square wave is not even approximately equal to a sum of harmonics. That is why you get the Gibbs phenomenon, when you are trying to approximate it with a sum of harmonics.
Method 1: Right mouse click on a pdf file > Select "Properties" in a drop-down menu > "Open With"
Method 2: "Preferred Applications"
mate-default-applications-properties
If you open a document file with a sort of vim, it may become a default for all documents.
If, for example, you open a wxMaxima worksheet *.wxmx with wxMaxima, then it is a default for all archives.
It seems to be a standard behaviour for all Linux Desktops (freedesktop.org)
program that handles the mouse click...
$ cat /usr/share/applications/atril.desktop | grep Exec
TryExec=atril
Exec=atril %U
Is it "Open in Terminal"?
$ cat /usr/share/applications/atril.desktop | grep Terminal=
Terminal=false
ls ~/.local/share/applications | grep atr
Mozo - Mate Menu Editor
_https://wiki.mate-desktop.org/mate-desktop/applications/mozo/
mozo
EDIT:
Right mouse click on a pdf file > Select "Properties" in a drop-down menu > "Open With"
MATE 1.26.0
$ atril --version
MATE Document Viewer 1.26.0
Atril opens PDFs without problems.
Check your pdf with mediainfo
mediainfo *.pdf
$ file *.pdf
Graphics_with_Maxima.pdf: PDF document, version 1.4, 6 pages
Try to open the pdf file with Firefox.
Do you think that "Caruso" may sound better with MPD-8 DAC, when it is downsampled to 48kHz?
The assumption is that Rushton Paul is using Mac for playing 32bit Float DXDs with the Playback Designs MPD-8 DAC (which cannot play 32bit Float DXDs).
Audio Device Setup for Mac
_https://www.sweetwater.com/sweetcare/articles/audio-midi-setup-for-mac/
MacBook Pro (2023)
Applications > Utilities > Audio MIDI Setup
MacBook Pro Microphone (built-in)
1 channel
Bit rate: 32bit Float
Default sample rate: 48kHz
Maximum sample rate: 96kHz
MacBook Pro Speakers (built-in)
2 channels
Bit rate: 32bit Float
Default sample rate: 48kHz
Maximum sample rate: 96kHz
32-bit float audio can capture the absolutely ludicrous range of up to 1,528 dB. That’s not only massively beyond the scope of 24-bit audio, but it’s beyond the scale of what even counts as a sound on Earth.
_https://www.wired.com/story/32-bit-float-audio-explained/
It means, perhaps, that might be possible to record "The Year 1812, Solemn Overture, Op. 49"
The 1812 Overture is scored for an orchestra that consists of the following:
Brass band: "Open" instrumentation consisting of "any extra brass instruments" available. In some indoor performances, the part may be played on an organ. Military or marching bands also play this part. Note: the brass band or its substitute is meant to play during the finale only.
Woodwinds: 1 piccolo, 2 flutes, 2 oboes, 1 cor anglais, 2 clarinets in B♭ and 2 bassoons
Brass: 4 horns in F, 2 cornets in B♭, 2 trumpets in E♭, 3 trombones (2 tenor, 1 bass) and 1 tuba
Percussion: timpani, orchestral bass drum, snare drum, cymbals, tambourine, triangle, carillon
Strings: violins I & II, violas, cellos and double basses.
Artillery: one battery of cannon, or even ceremonial field artillery.
_https://en.wikipedia.org/wiki/1812_Overture#Instrumentation
I can play them with MPlayer (Devuan) on Intel HDA (see my previous post).
You can download free samples here:
_https://positive-feedback.com/reviews/music-reviews/what-we-hear-with-dxd-32-bit-files/
You can play them with MPlayer
sudo apt install mplayer
$ mplayer "08-Faust - Funeral March Of A Marionette - 32bit.wav"
MPlayer UNKNOWN-12 (C) 2000-2023 MPlayer Team
do_connect: could not connect to socket
connect: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.
Playing 08-Faust - Funeral March Of A Marionette - 32bit.wav.
libavformat version 59.27.100 (external)
libavformat file format detected.
[wav @ 0x7fab12c87d00]Discarding ID3 tags because more suitable tags were found.
[lavf] stream 0: audio (pcm_f32le), -aid 0
[lavf] stream 1: video (png), -vid 0, Picture
VIDEO: [MPNG] 607x603 0bpp 90000.000 fps 0.0 kbps ( 0.0 kbyte/s)
libva info: VA-API version 1.17.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_17
libva error: /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so init failed
libva info: va_openDriver() returns 1
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_8
libva info: va_openDriver() returns 0
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
libavcodec version 59.37.100 (external)
[png @ 0x7fab121fdd20]Requested frame threading with a custom get_buffer2() implementation which is not marked as thread safe. This is not supported anymore, make your callback thread-safe.
Selected video codec: [ffpng] vfm: ffmpeg (FFmpeg PNG)
==========================================================================
Clip info:
artist: Alexander Gibson -RPHO
date: 2024-01-15
album: Gounod - Bizet - Alexander Gibson Royal Opera House Orchestra
encoder: Merging Technologies Album Publishing
title: Faust - Funeral March Of A Marionette
track: 8/9
Load subtitles in ./
==========================================================================
Opening audio decoder: [pcm] Uncompressed PCM audio decoder
AUDIO: 352800 Hz, 2 ch, floatle, 22579.2 kbit/100.00% (ratio: 2822400->2822400)
Selected audio codec: [pcm] afm: pcm (Uncompressed PCM)
==========================================================================
AO: [oss] 192000Hz 2ch s16le (2 bytes per sample)
Starting playback...
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
Movie-Aspect is 1.01:1 - prescaling to correct movie aspect.
[swscaler @ 0x7fab12e13f20]bicubic scaler, from rgba to yuv420p using MMXEXT
VO: [vdpau] 608x604 => 609x604 Planar YV12
Movie-Aspect is 1.01:1 - prescaling to correct movie aspect.
VO: [vdpau] 608x604 => 609x604 Planar YV12
No pts value from demuxer to use for frame!
pts after filters MISSING
A: 0.0 V:-9223372036854775808.0 A-V: 0.000 ct: 0.000 0/ 0 ??% ??% ??,?% 0 0 0.54x
Possibly bad interleaving detected.
Use -ni option if this causes playback issues and avoid or fix the program that created the file.
A: 3.0 V:-9223372036854775808.0 A-V: 0.000 ct:19449.693 0/ 0 0% 0% 0.0% 0 0 0.54x
Exiting... (Quit)
It does play DXDs (with downsampling and format conversion):
==========================================================================
Opening audio decoder: [pcm] Uncompressed PCM audio decoder
AUDIO: 352800 Hz, 2 ch, floatle, 22579.2 kbit/100.00% (ratio: 2822400->2822400)
Selected audio codec: [pcm] afm: pcm (Uncompressed PCM)
==========================================================================
AO: [oss] 192000Hz 2ch s16le (2 bytes per sample)
Starting playback...
OK, let us put it as simple as possible.
Can your DAC play 32bit float audio files (which it should not play)?
Have you tried?
If everything has already been clarified, then, perhaps, you may answer my question.
May I ask it again?
My hypothesis is that the Playback Designs MPD-8 DAC is playing 32bit float DXDs (which it should not play), because a sound system, or a player "performs the necessary format conversions in software".
Would you agree that it might be the case?
CONNECTING THE MPD-8 TO A WINDOWS BASED PC or APPLE MAC
Supported resolutions: PCM: all sample rates up to 384kHz and word lengths up to 24 bits.
DSD: native up to 11.2MHz and DoP up to 5.6MHz
Connection protocol and method: USB 2.0 / Audio class 2.0 compliant, asynchronous mode where MPD-
8 generates high precision clock master and computer is clock slaved.
PC requirements: Windows 7 or later, ASIO compatible player software such as JRiver
etc.
Mac requirements: OS X (10.6.6 or later)
If your computer is a Mac running OSX 10.6.6 or later you don’t need any driver software as OSX already supports all PCM formats up to 384kHz sample rate.
_http://playbackdesigns.com/docs/manuals/PlaybackDesigns_MPD-8_Manual1v1.pdf
$ mediainfo "08-Faust - Funeral March Of A Marionette - 32bit.wav" | grep Audio -A11
Audio
Format : PCM
Format profile : Float
Codec ID : 3
Codec ID/Hint : IEEE
Duration : 4 min 35 s
Bit rate mode : Constant
Bit rate : 22.6 Mb/s
Channel(s) : 2 channels
Sampling rate : 352.8 kHz
Bit depth : 32 bits
Stream size : 743 MiB (100%)
I've written here and there about my preference for listening to 32-bit PCM versus 24-bit PCM files (either 352.8kHz or 384kHz)...
But wait, you say... The Playback Designs MPD-8 accepts only 24-bit input files, so how can this be?
_https://positive-feedback.com/reviews/music-reviews/what-we-hear-with-dxd-32-bit-files/
If he is using MAC, DXD waves and flacs are likely to be downsampled to 48kHz (default) . OSX resamplers can do the work.
If "OSX already supports all PCM formats up to 384kHz sample rate", it does not mean that the OSX driver for MPD-8 DAC supports 384kHz sample rate. It may simply mean that OSX resamplers support 384kHz sample rate.
In this case, Foobar2000 may fail to play DXDs in "exclusive mode".
_https://support.apple.com/en-gb/108326
Play high sample rate audio on your Mac
The hardware digital-to-analogue converter (DAC) built into compatible Mac computers supports sample rates of up to 96 kHz.
The result of downsampling depends on the quality of the resampler and resolution of the original file.
If the original DXD wave is 32bit Float, downsampling to 48kHz (or 96kHz) may produce a better sound quality.
That is why, perhaps, Rushton Paul claims that 32bit DXDs are better than 24bit DXDs.
Would you agree with this?
I use audigy2, 24 bit, 195 kHz
Perhaps, it is Audigy2, 24 bit, 192 kHz.
There are many possibilities, for example, by recording a pure sinusodal signal from a generator with a frequency of 1 kHz and measuring the distortion when it is played back in different versions of the system, we can objectively evaluate the comparison of alsa vs pipeware vs pulseaudio. Or various resamplers.
It seems that your experiments can be simplified and made more exact.
All sorts of sinusoidal signals can be easily created with Audacity (with mathematical exactitude).
sudo apt install audacity
Audacity → Generate → Tone → select frequency and amplitude
You can also change resolution:
Audacity → Edit → Preferences → Quality → "Default Sample Rate" and "Default Sample Format"
Then you may try to measure the distortions in playback. It might be very interesting.
But you may better start a new topic for this.
Yes, it was not a scientific experiment, and it was not intended.
The fft resampler was tested several years. Then it was replaced with dct in an OSS4 plugin.
One user noticed the difference and began to complain about the sound quality and some unwanted effects, such as "fatigue".
Yes, a blind test might be very useful, but the problem is that you may not know what you are actually testing.
If, for example. a sound system performs resampling and format conversions in software, you may not know what you are actually playing with your DAC, or soundcard. That is why, perhaps, some users want to know how to enable "exclusive mode".
Trivial differences in resampling are irrelevant, and unless you are doing digital mastering, so are bit depths >16 and sampling rates significantly above the Nyquist limit. Fight me.
Although the difference between Petrov's dct and fft seems insignificant, I would strongly recommend to use fft instead of dct (default). The reason is the results of an unintended blind test with OSS4 users.
Again, my hypothesis is that the Playback Designs MPD-8 DAC is playing 32bit float DXDs (which it should not play), because a sound system, or a player "performs the necessary format conversions in software".
Would you agree that it might be the case?
Can you honestly say why you are raising these questions?
I asked the question about the Playback Designs MPD-8 DAC, because you seems to be an expert on DACs.
The Playback Designs MPD-8 accepts only 24-bit input files, so how can this be?
_https://positive-feedback.com/reviews/music-reviews/what-we-hear-with-dxd-32-bit-files/
Instead of answering the question, you are trying to sell me a very old theory that people do not need high resolution audio, because they cannot hear the difference.
I've talked with the Playback Design's Andreas Koch about this and he has a theory but no firm answer.
_https://positive-feedback.com/reviews/music-reviews/what-we-hear-with-dxd-32-bit-files/
It seems that you also have theories but no firm answer.
Perhaps, you may try to help us to find out how it can be that the Playback Designs MPD-8 DAC is playing 32bit float DXDs, which it should not play.
With OSS4, one may suspect the COOKEDMODE:
$ cat /usr/lib/oss/conf/osscore.conf | grep sampling -A9
# By default OSS will let applications use sampling rates and formats that
# are not supported by the hardware. Instead OSS performs the necessary
# format conversions in software. Applications that don't tolerate these
# kind of conversions usually disable them by using features of the OSS API
# (SNDCTL_DSP_COOKEDMODE). If this option is set to 0 then the format
# conversions will be disabled for all applications and devices unless the
# application explicitly enables them. This option should not be changed
# without wery strong reason.
#
#cooked_enable=1
What do you think about such hypothesis?
Yes, it is very interesting.
But we still have a question to answer:
But wait, you say... The Playback Designs MPD-8 accepts only 24-bit input files, so how can this be?
_https://positive-feedback.com/reviews/music-reviews/what-we-hear-with-dxd-32-bit-files/
The DXD wave is 32bit Float. What do you think about this?
If you cannot hear the difference between Petrov's dct and fft resamplers, you may try to measure it with exact scientific instruments.
The method is very simple:
1. downsample a DXD wave,
2. upsample the result to DXD format,
3. measure the difference with the original DXD wave,
4. compare the results of measurement for different resamplers.
Perhaps, you noticed that Petrov's pcm-utils package provides a sort of toolbox:
- pcm_info: information of the data format in 'wav' file
- pcm_conv: standalone PCM converter
- pcm_mse: computing of the Mean Squared Error (MSE) between two 'wav' files in PCM format
Free DXD samples are available here:
What We Hear With DXD 32-bit Files (Free Sample Downloads)
_https://positive-feedback.com/reviews/music-reviews/what-we-hear-with-dxd-32-bit-files/
[FFT] Downsampling:
$ pcm_conv -f 192000 -b 32 -T fft -v *32bit.wav Faust_192kHz_32bit_downfft.wav
Input file : 08-Faust - Funeral March Of A Marionette - 32bit.wav
Samples rate = 352800 Hz
Channels = 2
Bits per sample = 32 (actual: 32, float)
Output file: Faust_192kHz_32bit_downfft.wav
Samples rate = 192000 Hz
Channels = 2
Bits per sample = 32 (actual: 32, fixed)
FL FR
FL 1.000 -----
FR ----- 1.000
Windows : "Vorbis" (37632 => 20480)
Delay : 107 ms
Sync. : ON
Trans. : "FFT"
[|||||||||||||||||||||||||||||||||||||||||||||||||||] 99.0 %
Ok.
File duration : 275.906667 sec
Processing time: 13.305000 sec ( 4.82% of real time)
[FFT] Upsampling:
$ pcm_conv -f 352800 -b 32f -T fft -v *downfft.wav Faust_DXD_32bit_downupfft.wav
Input file : Faust_192kHz_32bit_downfft.wav
Samples rate = 192000 Hz
Channels = 2
Bits per sample = 32 (actual: 32, fixed)
Output file: Faust_DXD_32bit_downupfft.wav
Samples rate = 352800 Hz
Channels = 2
Bits per sample = 32 (actual: 32, float)
FL FR
FL 1.000 -----
FR ----- 1.000
Windows : "Vorbis" (20480 => 37632)
Delay : 107 ms
Sync. : ON
Trans. : "FFT"
[|||||||||||||||||||||||||||||||||||||||||||||||||||] 99.0 %
Ok.
File duration : 275.786667 sec
Processing time: 12.539000 sec ( 4.55% of real time)
[FFT] Measuring the difference:
$ pcm_mse *32bit.wav *upfft.wav -b 10 -e 10000000000
Opening file '08-Faust - Funeral March Of A Marionette - 32bit.wav' ... Ok.
Samples rate = 352800 Hz
Channels = 2
Bits per sample = 32 (actual: 32, float)
Opening file 'Faust_DXD_32bit_downupfft.wav' ... Ok.
Samples rate = 352800 Hz
Channels = 2
Bits per sample = 32 (actual: 32, float)
Processing format:
Samples rate = 352800 Hz
Channels = 2
Bits per sample = 64 (actual: 64, float)
File '08-Faust - Funeral March Of A Marionette - 32bit.wav' is longer than 'Faust_DXD_32bit_downupfft.wav'
[|||||||||||||||||||||||||||||||||||||||||||||||||||] 99.0 %
Ok.
Fragment form 10 to 97259904 (97259894 samples)
Front Left:
~~~~~~~~~~~
Dynamic range: from -0.92281 to 0.792051
MSE = 0.0001395137
SNR = 38.5538 dB
First diff.: 0.000288079 on position 10 (0 in fragment)
Max diff. : 0.00377898 on position 81946564 (81946554 in fragment)
Number of different samples: 97259747 ( 100.0% )
Front Right:
~~~~~~~~~~~~
Dynamic range: from -0.984298 to 1.04113
MSE = 0.0001161680
SNR = 39.3491 dB
First diff.: 0.000536871 on position 10 (0 in fragment)
Max diff. : 0.0408844 on position 66347702 (66347692 in fragment)
Number of different samples: 97259754 ( 100.0% )
[DCT] Downsampling:
$ pcm_conv -f 192000 -b 32 -T dct -v *32bit.wav Faust_192kHz_32bit_downdct.wav
Input file : 08-Faust - Funeral March Of A Marionette - 32bit.wav
Samples rate = 352800 Hz
Channels = 2
Bits per sample = 32 (actual: 32, float)
Output file: Faust_192kHz_32bit_downdct.wav
Samples rate = 192000 Hz
Channels = 2
Bits per sample = 32 (actual: 32, fixed)
FL FR
FL 1.000 -----
FR ----- 1.000
Windows : "Vorbis" (37632 => 20480)
Delay : 53 ms
Sync. : ON
Trans. : "DCT"
[|||||||||||||||||||||||||||||||||||||||||||||||||||] 99.0 %
Ok.
File duration : 275.906667 sec
Processing time: 7.655000 sec ( 2.77% of real time)
[DCT] Upsampling:
$ pcm_conv -f 352800 -b 32f -T dct -v *downdct.wav Faust_DXD_32bit_downupdct.wav
Input file : Faust_192kHz_32bit_downdct.wav
Samples rate = 192000 Hz
Channels = 2
Bits per sample = 32 (actual: 32, fixed)
Output file: Faust_DXD_32bit_downupdct.wav
Samples rate = 352800 Hz
Channels = 2
Bits per sample = 32 (actual: 32, float)
FL FR
FL 1.000 -----
FR ----- 1.000
Windows : "Vorbis" (20480 => 37632)
Delay : 53 ms
Sync. : ON
Trans. : "DCT"
[|||||||||||||||||||||||||||||||||||||||||||||||||||] 99.0 %
Ok.
File duration : 275.840000 sec
Processing time: 7.881000 sec ( 2.86% of real time)
[DCT] Measuring the difference:
$ pcm_mse *32bit.wav *updct.wav -b 10 -e 10000000000
Opening file '08-Faust - Funeral March Of A Marionette - 32bit.wav' ... Ok.
Samples rate = 352800 Hz
Channels = 2
Bits per sample = 32 (actual: 32, float)
Opening file 'Faust_DXD_32bit_downupdct.wav' ... Ok.
Samples rate = 352800 Hz
Channels = 2
Bits per sample = 32 (actual: 32, float)
Processing format:
Samples rate = 352800 Hz
Channels = 2
Bits per sample = 64 (actual: 64, float)
File '08-Faust - Funeral March Of A Marionette - 32bit.wav' is longer than 'Faust_DXD_32bit_downupdct.wav'
[|||||||||||||||||||||||||||||||||||||||||||||||||||] 99.0 %
Ok.
Fragment form 10 to 97297536 (97297526 samples)
Front Left:
~~~~~~~~~~~
Dynamic range: from -0.92281 to 0.792051
MSE = 0.0001395591
SNR = 38.5524 dB
First diff.: 0.000289127 on position 10 (0 in fragment)
Max diff. : 0.0037787 on position 81946564 (81946554 in fragment)
Number of different samples: 97297377 ( 100.0% )
Front Right:
~~~~~~~~~~~~
Dynamic range: from -0.984298 to 1.04113
MSE = 0.0001162062
SNR = 39.3477 dB
First diff.: 0.000540629 on position 10 (0 in fragment)
Max diff. : 0.0409828 on position 66347702 (66347692 in fragment)
Number of different samples: 97297363 ( 100.0% )
Results of measurement:
[FFT] Front Left: MSE = 0.0001395137
[DCT] Front Left: MSE = 0.0001395591
[FFT] Front Right: MSE = 0.0001161680
[DCT] Front Right: MSE = 0.0001162062
MSE is the Mean Squared Error
[FFT downsampling] Processing time: 13.305000 sec ( 4.82% of real time)
[DCT downsampling] Processing time: 7.655000 sec ( 2.77% of real time)
You can see that DCT is faster than FFT (13.305/7.655 ≈ 1.738).
FFT is more exact, although the difference is insignificant.
Petrov claimed that the difference is not audible, but it was detected by an OSS4/Gentoo user in a "blind test".
If you are using ALSA, you may not hear the difference between 192kHz/32bit and 48kHz/16bit formats of the same audio file (if the DXD wave was downsampled with the FFT resampler).
You may also try to measure the Secret Rabbit Code of ALSA (libsamplerate)
_https://libsndfile.github.io/libsamplerate/
_https://github.com/libsndfile/libsamplerate
sudo apt install sndfile-programs
man sndfile-convert
An ordinary computer is not suitable as a playback source.
I can agree with this. The same is for recording. A sort of portable HiRes audio recorders, such as Olympus or Zoom, might be a much more reasonable solution.
But, it we take this for granted, then, perhaps, Petrov's fftrate ALSA plugin with Audacious (without pulseaudio or pipewire) might be a practical solutions for notebooks.
Today I heard wonderful sound “out of the box” only from my son’s Mac, both desktop and laptop.
This is exactly the case. Kids are perfectly happy with Mac. Then they want to have the same sound quality with Fedora on a cheap notebook. It seems that fftrate plugin and apulse fixed the problem.
Notice, however, that MacOS sound system does not support 192kHz sample rate. But you can downsample DXD waves to 96kHz with Petrov's pcm_conv. Then you can play them with foobar2000. It can be installed with Homebrew
_https://formulae.brew.sh/cask/foobar2000#default
Foobar2000 "exclusive mode" is now supported for MAC. It may work, if the audio device supports the bit rate and sample rate of your audio file. There might be other problems as well
_https://forum.rme-audio.de/viewtopic.php?id=37063
_https://support.apple.com/en-gb/108326
Play high sample rate audio on your Mac
The hardware digital-to-analogue converter (DAC) built into compatible Mac computers supports sample rates of up to 96 kHz.
Compatible Mac computers feature a high-quality, built-in hardware DAC that can convert up to 96 kHz digital audio to analogue audio. You can connect analogue devices such as headphones or speakers directly to the headphone jack on your Mac and monitor your audio at full resolution without needing an external DAC.
To set the sample rate for the headphone jack, use the Audio Midi Setup app, which is located in the Utilities folder of your Applications folder.
_https://support.apple.com/en-gb/guide/audio-midi-setup/ams59f301fda/mac
By default the sample rate is 48000hz. There are several conditions in which you may want to change this. This all depends on your usage patterns. You want the sample rate you are using to match the media you use the most. If your computer has to change the sampling rate of the media to suit the hardware it is likely, though not guaranteed, that you will have a loss in audio quality. This is most noticeable in down sampling (ie. 96000hz → 48000hz). There is an article about this issue in Stereophile which was discussed on Apple's CoreAudio API mailing list if you wish to learn more about this issue.
_https://wiki.archlinux.org/title/Open_Sound_System#Changing_the_sample_rate
_https://www.stereophile.com/news/121707lucky/
_https://lists.apple.com/archives/coreaudio-api/2008/Jan/msg00272.html
This was a quote from ArchWiki manual on OSS4. All this does not apply to Petrov's fftrate resampler. Regardless of your usage patterns, you can safely configure fftrate for the highest sample rate supported by your sound card. Some users even claimed that Petrov's fftrate resampler somehow improves sound quality of audio files. I cannot dismiss their claims, because one of them detected the difference between Petrov's dct and fft resamplers in a "blind test" (he noticed the difference and began to complain). However, you have to dismiss such claims, if you know what the Gibbs phenomenon is. The problem is knowledge, of course. It always restricts our freedom of thinking.
In a word, you can easily switch between resamplers in /etc/fftrate.conf
$ cat /etc/fftrate.conf | grep Transform -A3
# Transform type
# Available: dct, fft (default: dct)
#transform = dct
transform = fft
The problem seems be that ALSA does not permit "exclusive mode", and, therefore, it may not make much sense to use a very expensive DAC with ALSA.
Thank you for the information. Have you tried it?