... you want to measure Jitter, wich is inaccuracies in the time domain of the
digital signal. by lokking at the analog output of the dac ?? REALLY ??
...seriously... REALLY ???
that´s about just as accurate than listening tests...
you do realize that you can measure jitter directly..?
This is just ridiculous. Please go study some math, and come back when you have at least a basic understanding of how the time and frequency domains of a signal are related.... you want to measure Jitter, wich is inaccuracies in the time domain of the
digital signal. by lokking at the analog output of the dac ?? REALLY ??
...seriously... REALLY ???
that´s about just as accurate than listening tests...
you do realize that you can measure jitter directly..?
Hi HenrikEnquist,
You're awesome!
I wanted to get some advice from someone who knows a lot about math.
Nyquist-Shannon sampling theorem and A/D and D/A conversion I'd appreciate your input, as you're more familiar with the process.
The rise of a sound, that is, the moment of vocalization or the impact of an instrument, is a very natural It is commonplace.
If we try to discretize this with the sampling theorem, we find that it is difficult to reproduce the rising impulse of the sound The required frequency components would be much higher than the audible range.
The standardization was aimed at reproducing the frequency components of the audible range at the expense of accurately reproducing the extreme changes in the time domain (the moment of sound rise).
When the A/D-converted signal is converted to D/A in accordance with the sampling theorem, the rising edge of the sound Pre-ringing occurs in
A number of compromise digital filters have been devised to mitigate the problem of pre-ringing.
Please let me know if there are any errors so far.
Here's where I'd like to hear your opinion.
Could the extra bandwidth created by upsampling be used to offset the pre-ringing and reproduce a more realistic rise in sound?
For example, let's say you upsample a 44.1 KHz sound source to 96 KHz.
Then there will be a big blank band from 22.05KHz to 48KHz.
The rising part of the sound is the point at which the fundamental and its overtones rise almost simultaneously.
Find such a point and use the band from 22.05 KHz to 48 KHz. Can't we offset the major components of pre-ringing?
Whether or not it can really be implemented is not the question now.
I just want you to remind me of the fallacy and inconsistency of this idea.
I was having trouble finding someone to talk to about these things.
Thank you for your help.
You're awesome!
I wanted to get some advice from someone who knows a lot about math.
Nyquist-Shannon sampling theorem and A/D and D/A conversion I'd appreciate your input, as you're more familiar with the process.
The rise of a sound, that is, the moment of vocalization or the impact of an instrument, is a very natural It is commonplace.
If we try to discretize this with the sampling theorem, we find that it is difficult to reproduce the rising impulse of the sound The required frequency components would be much higher than the audible range.
The standardization was aimed at reproducing the frequency components of the audible range at the expense of accurately reproducing the extreme changes in the time domain (the moment of sound rise).
When the A/D-converted signal is converted to D/A in accordance with the sampling theorem, the rising edge of the sound Pre-ringing occurs in
A number of compromise digital filters have been devised to mitigate the problem of pre-ringing.
Please let me know if there are any errors so far.
Here's where I'd like to hear your opinion.
Could the extra bandwidth created by upsampling be used to offset the pre-ringing and reproduce a more realistic rise in sound?
For example, let's say you upsample a 44.1 KHz sound source to 96 KHz.
Then there will be a big blank band from 22.05KHz to 48KHz.
The rising part of the sound is the point at which the fundamental and its overtones rise almost simultaneously.
Find such a point and use the band from 22.05 KHz to 48 KHz. Can't we offset the major components of pre-ringing?
Whether or not it can really be implemented is not the question now.
I just want you to remind me of the fallacy and inconsistency of this idea.
I was having trouble finding someone to talk to about these things.
Thank you for your help.
Hi Duanbui,
We have members who have installed and are using upmpdcli and minim server.
I'll tell you how to do it later.
Hi HenrikEnquist,
I thought it was a good idea to have a third party evaluate it.
Hi Duanbui
Here is the way how to install upmpdcli in SMPD.
1. Activate port 6000
edit /lib/systemd/system/mpd.socket as follows to enable port 6600.
# for Web UI
ListenStream=%t/mpd/socket
# for Any other mpd clients
ListenStream=6600
2. Install the upmpdcli related libraries.
app install jsoncpp
app install libmicrohttpd
app install libupnpp
app install npupnp
app install upmpdcli
3. Create upmpdcli.conf.
#
# (Reference) /etc/upmpdcli.conf setting
#
#mpdhost = 127.0.0.1 (default)
#mpdport = 6600 (default)
friendlyname = SymphonicMPD (Any renderer name)
checkcontentformat = 0
openhome = 1
lumincompat = 1
ohproductroom = SymphonicMPD
ohmetapersist = 1
logfilename=/var/log/upmpdcli.log (Specifies that it should be logged)
loglevel = 3 (It won't start if you get a level 1 error)
4. Add to mpd.conf lines below.
#
# Setting of /etc/mpd.conf (Added the following)
#
input {
plugin "curl"
# proxy "127.0.0.1:8123" (No polipo in use, comment in)
}
5. Create a user named "upmpdcli" as it doesn't work as root.
useradd upmpdcli
touch /var/cache/upmpdcli
6. Confirm it's working properly.
upmpdcli -D -c /etc/upmpdcli.conf -l 1
7. Register upmpdcli to systemd.
- Cteate file
touch /lib/systemd/system/upmpdcli.service
- Edit
#
# (Reference)/lib/systemd/system/upmpdcli.service setting
#
[Unit]
Description=UPnP Renderer front-end to MPD
After=network.target mpd.service
[Service]
Type=simple
# Note: if start fails check with "systemctl status upmpdcli"
ExecStart=/usr/bin/upmpdcli -c /etc/upmpdcli.conf
Restart=always
RestartSec=1min
[Install]
WantedBy=multi-user.target
- Confirm
cat /lib/systemd/system/upmpdcli.service
8. Start and activate the upmpdcli.service
systemctl daemon-reload (Load the created umpdcli.service)
systemctl start upmpdcli.service (Simple activation, now you can use it)
systemctl enable upmpdcli.service (Activate at boot time, you can use it always)
Click here for the Japanese reference page.
ゴンザエモンのオーディオ日記 第48章 妄想と葛藤
yo
Here is the way how to install upmpdcli in SMPD.
1. Activate port 6000
edit /lib/systemd/system/mpd.socket as follows to enable port 6600.
# for Web UI
ListenStream=%t/mpd/socket
# for Any other mpd clients
ListenStream=6600
2. Install the upmpdcli related libraries.
app install jsoncpp
app install libmicrohttpd
app install libupnpp
app install npupnp
app install upmpdcli
3. Create upmpdcli.conf.
#
# (Reference) /etc/upmpdcli.conf setting
#
#mpdhost = 127.0.0.1 (default)
#mpdport = 6600 (default)
friendlyname = SymphonicMPD (Any renderer name)
checkcontentformat = 0
openhome = 1
lumincompat = 1
ohproductroom = SymphonicMPD
ohmetapersist = 1
logfilename=/var/log/upmpdcli.log (Specifies that it should be logged)
loglevel = 3 (It won't start if you get a level 1 error)
4. Add to mpd.conf lines below.
#
# Setting of /etc/mpd.conf (Added the following)
#
input {
plugin "curl"
# proxy "127.0.0.1:8123" (No polipo in use, comment in)
}
5. Create a user named "upmpdcli" as it doesn't work as root.
useradd upmpdcli
touch /var/cache/upmpdcli
6. Confirm it's working properly.
upmpdcli -D -c /etc/upmpdcli.conf -l 1
7. Register upmpdcli to systemd.
- Cteate file
touch /lib/systemd/system/upmpdcli.service
- Edit
#
# (Reference)/lib/systemd/system/upmpdcli.service setting
#
[Unit]
Description=UPnP Renderer front-end to MPD
After=network.target mpd.service
[Service]
Type=simple
# Note: if start fails check with "systemctl status upmpdcli"
ExecStart=/usr/bin/upmpdcli -c /etc/upmpdcli.conf
Restart=always
RestartSec=1min
[Install]
WantedBy=multi-user.target
- Confirm
cat /lib/systemd/system/upmpdcli.service
8. Start and activate the upmpdcli.service
systemctl daemon-reload (Load the created umpdcli.service)
systemctl start upmpdcli.service (Simple activation, now you can use it)
systemctl enable upmpdcli.service (Activate at boot time, you can use it always)
Click here for the Japanese reference page.
ゴンザエモンのオーディオ日記 第48章 妄想と葛藤
yo
Those measurements was not made on the same type hardware as I understood it. And if so, not really valid?
//
//
Hi HenrikEnquist,
There's one more thing I'd like you to tell me.
It's an idea to improve the time domain jitter that is mixed in with the A/D conversion process in the D/A process.
(Interesting, isn't it?)
I'd be happy to discuss this with you after you tell me about the first question.
There's one more thing I'd like you to tell me.
It's an idea to improve the time domain jitter that is mixed in with the A/D conversion process in the D/A process.
(Interesting, isn't it?)
I'd be happy to discuss this with you after you tell me about the first question.
... you want to measure Jitter, wich is inaccuracies in the time domain of the
digital signal. by lokking at the analog output of the dac ?? REALLY ??
...seriously... REALLY ???
that´s about just as accurate than listening tests...
you do realize that you can measure jitter directly..?
Of course we mean the consequence of clock jitter on the analog output.
C'mon...
//
You can never remove jitter induced at recording. It's there forever. Sad but true.
Re the rising edge of a transient and the sampling theorem. The theorem says that the sampling process may not be exposed to any signal content above fs/2. So input to A/D must be filtered or aliasing distorsion arrises. Not good.
So the steepness of a transient is already limited on the CD but the D/A can at least recreate the speed that is stored digitally - no problem. Introducing upsampling has no impact of the steepness whatsoever.
The steepness if the rise in a transient corresponds perfectly to the bandwidth of the system - there is nothing special about a transient.
These are basics in digital audio.
//
Re the rising edge of a transient and the sampling theorem. The theorem says that the sampling process may not be exposed to any signal content above fs/2. So input to A/D must be filtered or aliasing distorsion arrises. Not good.
So the steepness of a transient is already limited on the CD but the D/A can at least recreate the speed that is stored digitally - no problem. Introducing upsampling has no impact of the steepness whatsoever.
The steepness if the rise in a transient corresponds perfectly to the bandwidth of the system - there is nothing special about a transient.
These are basics in digital audio.
//
Yes this looks correct. The 44.1kHz standard is a compromise that keeps the data rate down, at the expense of making the reconstruction (or antialiasing) filter more difficult to build. Since the Nyquist frequency is just a little bit above what we can hear, the reconstruction filter needs to be very steep to make sure that it has very little attenuation at 20kHz and very high attenuation at 22.05 kHz and above. A higher sampling rate would increase the data rate while relaxing the requirements on the filter.
The pre-ringing is created already in the recording stage. Most A/D converters are running at a high sampling rate, and then the result is filtered down to the desired rate with a sinc antialiasing filter (either directly in the ADC, or later in the process). This step creates the pre-ringing, so it's already present in the music when we get it.
The extra bandwidth created by upsamling can't be used like this. We don't have the information needed to fill it with something useful. All the information content of let's say the 22.05 - 48 kHz range is deleted by the antialiasning filter while recordning. There is a lot of space, but we have no idea what to insert there.
Or another way of saying the same thing. A digital audio track is a series of sample points. These points are just points, they have no duration. When we play back this song, we need to fill the spaces between the points with something to make a continuous waveform. If we include only frequencies up to and including fs/2, then there is exactly one waveform that passes through all the points. This is the waveform we get by using sinc interpolation (with an infinitely long sinc). But if we allow higher frequencies to enter the waveform, then there isn't one, but an unlimited number of possible waveforms. We have no idea of knowing if any of these are a better match to the original that the others, because we lack the information that could tell us.
If we just want to get rid of the pre-ringing, we can do that by using a less steep reconstruction filter, that attenuates the highes frequencies a bit more. We already have to make some kind of compromise, since we can't have an infinitely long sinc in practice. This means we get some freedom to play. Once we have made a filter that isn't so steep, the ringing gets shorter. Then we can also play with where the ringing is, and we can move it so we get more post-ringing and less pre-ringing. But note that this actually means we lose a little more information.
The main problem is that we need information that has been lost. But what if we could make something up that is a good guess of the stuff that is missing? This could be a fun experiment for machine learning, to train an AI on how high-samplerate music sounds, and let it fill in the missing bits in standard quality material.
No idea if it would work, and if the result would sound realistic, but it's a fun though. There is a demo from Nvidia where you draw a cartoon landscape, and then the machine creates a pretty picture, replacing the cartoon trees and mountains etc with something that looks a lot like how trees and mountains usually look. It's good fun, try it here: nvidia-research-mingyuliu.com
...calling others stupid doesn´t make you look smart...
but i´m not innocent myself.
i got carried away yesterday and made fun of you,
for that i apologize.
and i promiss to not bother you again.
Hi HenrikEnquist,
Thanks so much for replying.
Your explanations are detailed and very clear, thank you.
Careful upsampling with the sinc function only relaxes the properties required of digital filters and shifts the quantization error to higher frequencies.
There is no information in the digital data to improve the preringing.
However, there is a strong constraint: "Pre-ringing is not real at the time of recording".
Wouldn't this constraint be a guideline for embedding in excess bandwidth?
Could we embed an inverse phase of the pre-ringing that cancels out some of its components?
It would be ideal if it could be reduced to the noise floor.
Don't worry. And I shouldnt have replied so late in the evening when I was tired and a little grumpy..
Anyway, just to show how this could work, I simulated some spectra with different amounts and types of jitter. It's done quickly and just to give an idea of how it works. I haven't paid any proper attention to the amounts of jitter so don't look at the levels, just the shape.
It's a 10kHz sine, sampled at 44.1 kHz. The curves are:
- blue: no jitter, this is the noise floor of 64 bit floats
- orange: white noise jitter
- green: low-pass filtered noise, so there is more low frequency than high frequency jitter. This is pretty normal behaviour for oscillators (but the actual shape is not from a real oscillator, just something I made up)
- red: with MASH mode active. It's basically switching between two sample rates. I have no idea how fast it switches in reality, so I just put 1 kHz. If someone can tell me the correct value, I can update the plot.
The "ringing" is a predicted behaviour of a correctly ideally functioning filter. The "ringing" frequency is at fs/2 so nothing a human can hear playing a red book CD.
//
//
You would need some way to tell the pre-ringing apart from the rest of the sound. In real music the actual waveform really messy and there is no way you could identify that right here, there is a pre-ringing that belongs to this transient there. It's never that clean, rather it's a mess of lots of little transients that each have both pre-and post-ringing that melds together with into something that is just impossible to separate. The easy cases that you can see only happens on synthetic wavforms, like a perfect square wave or such.
I think the only way to get rid of them, is to low-pass filter with a less steep filter, sacrificing some of the higher frequencies. As TNT wrote, adults can't hear 22.05 kHz anyway so that's probably not very useful. Maybe babies can, but I dont think they care 🙂
Yes, you're right, the difficulties are there. I'm not at all sure I can implement it well.
What you want to address is the pre-rising part of the sound.
That's where I think the fact that the fundamental and overtones rise at the same time would be a good marker.
Indeed, it may be a waste of time to tackle areas we can't hear.
But DACs, amplifiers, and speakers, whether they are in the audible range or not, and whether they are real or not, strive to be faithful to the input.
It's a waste of the amplifier's superior braking power and the speaker's superior responsiveness to be consumed by the reproduction of pre-ringing.
It makes more sense to order the DAC to play less pre-ringing waves than it does to order the DAC to play pre-ringing waves.
This would improve the quality of the audible range.
Or would it not improve the quality of the audible range?
Last edited: