• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

Digital filter "game"

mansr

Major Contributor
Joined
Oct 5, 2018
Messages
4,685
Likes
10,703
Location
Hampshire
Also, if 24-bit dither is useless, than rate -u is useless as well. The added filter length and attenuation are placebo anyway.
When downsampling, the stopband attenuation should be strong enough that any aliased content ends up well below the passband noise level. Since DSD has lots of ultrasonic noise and the downsampling factor is fairly large, to ensure all of it ends up below the 20-bit level, an attenuation of 140 dB or so is required in order to be safe. The SoX rate -v exceeds this, so you're right, there is no need for -u here.
 
OP
B

bennetng

Major Contributor
Joined
Nov 15, 2017
Messages
1,634
Likes
1,693
One of those things is a matter of mathematics, the other about an ill-defined file format. Only the latter is really up for debate.
An example that in fact I actually don't care so much about dither, even at 16-bit, but since I got replies above then I just added dither in the command, for my own safety, even at 24-bit.
The comment about extensible format is not targeted at SoX though, as I was referring how people criticized formats like Monkey's Audio, flac, TTA and such handle file formats in another forum.
 

hyperknot

Active Member
Joined
Aug 17, 2019
Messages
260
Likes
166
I did DeltaWave testing on a real world DSD file. All apps used 24/88, no dither.

Saracon
saracon.png


Sox soxdsd -SV4 sample.dsf --bits 24 sox/sox.flac rate -uL 88200[B]
sox.png

sox-delta.png


Sox -b74 soxdsd -SV4 sample.dsf --bits 24 sox/sox_b74.flac rate -uL -b74 88200
soxb74.png

soxb74-delta.png



What could be the difference? Should we add an additional low-pass filter around 30k?
 
OP
B

bennetng

Major Contributor
Joined
Nov 15, 2017
Messages
1,634
Likes
1,693
IMO just stay with -b74 to minimize the steps. Think in another way, playing DSD64 files directly for example, on a hardware DAC chip, the filter is even weaker than Audiogate and it is still not going to blow up people's playback equipment.

Nothing wrong with Saracon as well of course, just not free software. Make sure nothing is clipped and everything will be fine.
 
OP
B

bennetng

Major Contributor
Joined
Nov 15, 2017
Messages
1,634
Likes
1,693
The reality is if you don't apply dither on a 24-bit output, then your precision is already limited at non-dithered 24-bit performance. In this case, any filter with any attenuation depth (e.g. rate -u) will also be limited by this value. As for the so-called brickwall filter, since the noise floor of DSD is always a sloping one, for example starting at 20kHz or so and peaking at something like 60-70kHz for DSD64, a very steep brickwall filter is useless if you are using 88.2k target. A steeper filter is useful only when your target is something like 44.1kHz to avoid trimming some potentially audible frequency contents.

You can actually let SoX to use a steeper filter for your subjective taste, but it is really a waste of time to talk about these things in great detail so I am reluctant to answer this, if you are clever or if mansr or others are willing to continue then it is up to them. You can find some hints on the posts on the first page of this thread, though.

Also, RMAA's analyzing precision is actually kind of limited to differentiate the quality of for example, SoX vs Saracon conversion in digital domain.
 
OP
B

bennetng

Major Contributor
Joined
Nov 15, 2017
Messages
1,634
Likes
1,693
An example of why RMAA can be unreliable for these kinds of tests. In fact, I had some discussions with Archimago about these things last year (and therefore not in 2015) and he changed his test approach to avoid these issues. It doesn't mean RMAA is useless, but extra care should be taken when doing some specific tests.

...and why rate -v is enough for 24-bit output, dithered or not.
 

hyperknot

Active Member
Joined
Aug 17, 2019
Messages
260
Likes
166
It's not about bit depth, its simply about getting rid of DSD64 noise. If there is high frequency noise by definition in the format, we should get rid of it. It's unrelated if the target is 88k or 96k or 172k, we have to do something with the noise after the decoding step. Weiss seems to do a low-pass at 30k. Some implementations do 25k. Some do brickwall at 20k. All I'm saying is that -b74 starts at a much higher frequency, so instead of -b74 we should be using a separate effect which starts lower.
 
OP
B

bennetng

Major Contributor
Joined
Nov 15, 2017
Messages
1,634
Likes
1,693
At this point I suppose you already know how to do what you wanted to to by reading the first page of this thread, right? If you are brickwalling at 20kHz, why don't simply use 44.1k target, or somthing like 64kHz and let the playback software to do the resampling? You don't trust playback-side resampling of what you are using?

Different modulators (ADC chips or DSD encoders) have different specs, and some music genres don't even have that much high frequency content. If you are so pedantic about these things, you may consider using different filters on different genres, if not individual album or even individual tracks.
 

hyperknot

Active Member
Joined
Aug 17, 2019
Messages
260
Likes
166
I'm trying to get as close to the reference implementation (Saracon) as possible using free tools. Call it pedantic if you want, but getting as close to the reference as possible is a noble goal of open source tools.
 
OP
B

bennetng

Major Contributor
Joined
Nov 15, 2017
Messages
1,634
Likes
1,693
Looks like you are moving your target in different replies.
Hi, I'm planning to convert my whole SACD / DSD library to FLAC 24/88. What is the "ultimate" archival quality setting for this? I'm happy to trim frequencies over 30kHz.
By reading this, I could not exactly get what you wanted to do because even Saracon don't do that. Sure, it will cut some 30kHz content, but not completely (i.e. down to 24-bit limit regardless of what modulator was used in the DSD source). What I got was you simply want to cut something beyond 30kHz.

I did not even know in your mind, you consider Saracon as a reference. If what you said was you wanted to mimic Saracon then I would have talked about something different. But anyway, I suppose you already know how to do it at this point.
 

hyperknot

Active Member
Joined
Aug 17, 2019
Messages
260
Likes
166
@bennetng I'm looking for the highest quality (to 88.2k) which I thought would be Saracon. Are you on the opinion that sox -b74 will be higher quality than Saracon on real world music?
 
OP
B

bennetng

Major Contributor
Joined
Nov 15, 2017
Messages
1,634
Likes
1,693
-b74 itself does not have any inherent quality meaning. To begin with, you used "rate -uL -b74". Now -u and -v have a meaning of quality: -u has higher noise attenuaton than -v, but as you can see it is already bottlenecked by the 24-bit quantization limit. "L" means linear phase, but by default SoX use linear phase, so it is redundant. -b74 is not an additonal step as SoX by default uses -b95, so there is no extra processing. Therefore you can see that I originally use -vb74.

It really depends on what you considered as important. For example, the reason I used the Mahler file among others is mainly because it has some high frequency content blended with the rising DSD noise, while other files essentially have no musical content above 20kHz, so it makes no sense to even use 88.2k target.

If you are doing batch conversion without inspecting every single file, and consider these ultrasonic musical content as important in the sense of archiving, -vb74 will give some leeway about these uncertainties if you leave some frequency headroom. If you are really afraid of noise, you can trim it in real time during playback with appropriate plugins. On the other hand, if you cut too much on the converted flac files, you can't really boost the lost frequency. Also, since it is a forum thread, everyone can read it and different people have different opinions, some may think that leaving it as is (-b95) is the way to go as well, so I can't be so specific about what is "the best".
 
Last edited:

hyperknot

Active Member
Joined
Aug 17, 2019
Messages
260
Likes
166
OK, I went ahead and converted my whole collection with rate -ub74 88200 gain 6 sinc -25k. I'm not saying these are the "best" settings, but for me personally these made the most sense. Also in RMAA these generated very high quality results.

Made a Python script which batch-converts and find the best gain (+6, +5, +4, etc.) for each directory.
 
OP
B

bennetng

Major Contributor
Joined
Nov 15, 2017
Messages
1,634
Likes
1,693
RMAA does not seem to able to plot frequency response correctly at 88.2kHz, but this can be checked by other tools.

Also, RMAA's generator and analyzer is limited at 32-bit float. While it is possible to select 32-bit integer in the UI, if you for example, use a 64-bit float capable tool like DeltaWave to compare the 32-bit integer vs float reference RMAA signals, they will both have similar amount of inherent distortion. Ideally, 32-bit interger should have lower distortion than float in this regard. SoX's intermediate format is 32-bit integer, so the RMAA signal itself is already a bottleneck. Some DSD encoders can have very low noise floor in the non-shaped passband (below 20kHz) so these artifacts can still be identifed in a round trip PCM-DSD-PCM digital domain signal chain when using an appropriate analyzing tool.

Speaking of intermediate format, for example, foobar is using 32-bit float too, but the SACD plugin is capable of 64-bit float operation. In foobar's architecture, individual plugin can operate in arbitrary precision, but the link between different plugins and the rest of foobar's engine is still limited at 32-bit float. Considering foobar supports a wide spectrum of formats from the typical lossless/lossy ones, to synthesized game rips, VSTi and such, float is indeed a much safer format.

These may not be what you cared or interested about in the regard of converting your DSD files, but RMAA cannot fully reveal SoX's quality.

However you seemed to pay more attention on the attenuation of the DSD sloping noise from about 30k up to 44.1k.
 

Garrincha

Addicted to Fun and Learning
Joined
Jan 11, 2022
Messages
659
Likes
816
It's a fun game.
A good web site to design your FIR filter online :
http://t-filter.engineerjs.com/
I use it often for fast design.
An example of what you can get for the first stage :View attachment 158105
I know this is an older post, but still, I though it is interesting, after all the measurement of the Chord DACs and the tap talk of Rob Watts. I played around as well with this tool and got something like this. Am I missing something or would this be the almost perfect filter? No ripples up to 20kHz (0.0001 dB), down -160dB above Nyquist 22.05kHz, and 375 taps used.
 

Attachments

  • 1662134954191.jpeg
    1662134954191.jpeg
    219.9 KB · Views: 75
OP
B

bennetng

Major Contributor
Joined
Nov 15, 2017
Messages
1,634
Likes
1,693
Am I missing something
Yes. Because tcli's reply followed the rule of the game in my first post that the first stage of the filter has a length of 135, but yours is much longer.

So while it is true that a filter length of 375 can indeed produce the result you posted, it is not a realistic figure for typical DAC chip built-in filters without additional FPGA and such. I have to make this point clear so that others (not necessarily you) don't assume typical DAC chips have such a filter. This thread is for those who are curious about the choice of filters on typical chips (e.g. AKM, Cirrus, ESS...)

There are other more appropriate threads for Chord and / or other products with very long filters, just a few examples:
 

Garrincha

Addicted to Fun and Learning
Joined
Jan 11, 2022
Messages
659
Likes
816
Yes. Because tcli's reply followed the rule of the game in my first post that the first stage of the filter has a length of 135, but yours is much longer.

So while it is true that a filter length of 375 can indeed produce the result you posted, it is not a realistic figure for typical DAC chip built-in filters without additional FPGA and such. I have to make this point clear so that others (not necessarily you) don't assume typical DAC chips have such a filter. This thread is for those who are curious about the choice of filters on typical chips (e.g. AKM, Cirrus, ESS...)

There are other more appropriate threads for Chord and / or other products with very long filters, just a few examples:
Ok, so I really wasn´t aware of the n = 135 constraint, I think it has not been stated clearly in the OP. So when typical DAc chips don´t have more taps, one has to live with that. But still, 375 is well below 16k or 4mm. Thus if DAC chip manufacturers might augment their taps a little bit in the future I think it is interesting to know that with a few hundred taps a perfect filter might be achieved and no 4mm Bob Watts crazyness is necessary.
 

pkane

Master Contributor
Forum Donor
Joined
Aug 18, 2017
Messages
5,667
Likes
10,299
Location
North-East
Yes. Because tcli's reply followed the rule of the game in my first post that the first stage of the filter has a length of 135, but yours is much longer.

So while it is true that a filter length of 375 can indeed produce the result you posted, it is not a realistic figure for typical DAC chip built-in filters without additional FPGA and such. I have to make this point clear so that others (not necessarily you) don't assume typical DAC chips have such a filter. This thread is for those who are curious about the choice of filters on typical chips (e.g. AKM, Cirrus, ESS...)

There are other more appropriate threads for Chord and / or other products with very long filters, just a few examples:

Are 64-bit floating point filters allowed in the game? I assume not, but even a 128 tap filter with 64 bit coefficients can be pretty amazing.
 
Top Bottom