AuraEngine Converter

[ToxaDev]

What about the low-frequency range? With CDs, you very often see "Himalayas" below 20 Hz. I know it’s inaudible. My speakers don't need it. Couldn't AE filter that out?

View attachment 558888

@Erogen That "Himalaya" is a DC offset, not infrasound. Audacity doesn't remove the mean before the FFT, so an offset leaks into the first bins through the Blackman-Harris window. The dip at 10 Hz is the window's first null: 4 bins × 2.7 Hz = 10.8 Hz. Easy check: set the size to 65536 and the hump and the dip move four times closer to 0 Hz. On Audacity's scale, −40 dB in the first bin is an offset of about −43 dBFS, roughly 0.7 % of full scale.

The converter already takes that out: the first thing it does is subtract each channel's mean. Nothing else below 20 Hz is touched, there's no high-pass in the chain. On a disc I have here (Mal Bicho) the rip and the converted file agree within 0.13 dB from 2.7 to 100 Hz, picture attached.

(Tip: on a 352.8 kHz file, size 16384 starts the plot at 21.5 Hz. Use 131072.)

A subsonic filter I'd leave to the playback chain. Where to cut and how steep depends on the speaker, and there it protects them from every source, not just from my files.

 

[Erogen]

I chose 65,536. It didn't disappear; it's still there.
I checked in Adobe Audition. It's there too.
When I use a high-pass filter at 12 Hz / -24 dB, it's gone.

This "Himalayas" effect appears on early albums from the 80s—basically on most of them.

 

[Erogen]

[AE · 44.1k→352.8k · Kaiser 30M · f64 · AA · HP]

It's still there.

 

[formdissolve]

@ToxaDev What's the point of doing this on MP3s? I am going to try it on some wav/flac later, but was curious why MP3 is there since it's compressed and usually cuts off the highs.

 

[Erogen]

Time: 3179s (14 track)
Intel Ultra 7+ GPU RTX 5060TI (C: 3008MHz/ M: 1788MHz)
Memory 16GB (available 11 GB)
The configuration of available options is the same in each case.
ALL DSP: ON / FS Multiper: FS 8x
30M Taps: 10.15x
10M Taps: 13.76x
1M Taps : 19.38x

In the 30M and 10M cases, there are momentary pauses in CPU processing due to waiting for system memory to be freed.
Version 1.26 processes up to two threads simultaneously. Another test after increasing system memory by an additional 16 GB.

Time: 3179s (14 track)
Intel Ultra 7+ GPU RTX 5060TI (C: 3008MHz/ M: 1788MHz)
Memory 32GB (available 25 GB)
The configuration of available options is the same in each case.
ALL DSP: ON / FS Multiper: FS 8x
30M Taps: 15.07x Increase in speed + 48,5%
10M Taps: 17.07x Increase in speed+ 24,05%
1M Taps : Increase in speed 23.59x + 21,71 %

ONLY CPU 30 Taps: 5.72x

 

[ToxaDev]

I chose 65,536. It didn't disappear; it's still there.
I checked in Adobe Audition. It's there too.
When I use a high-pass filter at 12 Hz / -24 dB, it's gone.

This "Himalayas" effect appears on early albums from the 80s—basically on most of them.

View attachment 558898

View attachment 558899

View attachment 558900

@Erogen You were right, and I was too quick with "the converter takes that out". At 65536 your hump sits at 0.7–1.3 Hz: that's a component near 1 Hz at about 1 % of full scale, different in each channel, not an offset. Subtracting the mean removes nothing from it.

Your file is a real case, so 1.2.8 has a switch for it: https://github.com/ToxaDev/aura-engine/releases/tag/v1.2.8

Subsonic Filter, off by default. A linear-phase high-pass at the source rate, so nothing above the corner moves in level or in timing: flat within 0.01 dB from the corner up, at least 100 dB down from half the corner to DC. The corner is 20, 15 or 10 Hz (click the chip on the SUB row), and the file name says SUB20. It's there for the speakers, not for the sound.

To check it on your disc: the output is 352.8 kHz, so use size 131072 (2.7 Hz per bin). Without the filter the first bins still show the hump at about −40 dB; with SUB20 they should drop to the floor. The picture is a test file built like yours (1 Hz at 0.94 % under noise and a 40 Hz tone) through 1.2.8 both ways.

 

[ToxaDev]

@ToxaDev What's the point of doing this on MP3s? I am going to try it on some wav/flac later, but was curious why MP3 is there since it's compressed and usually cuts off the

Because that's where it started for me: MP3s through PGGB, and I liked what I heard. Some tracks only exist that way (the Rich Girl leak from my first post never had a proper master), and I listen across a wide range of tracks and genres, so a lossy source doesn't bother me; often there's no other choice. The converter doesn't bring back what the codec cut, the highs stay where they are. What I hear is the opposite of what you'd expect, though: on lossless sources the change is subtle, on MP3s it's large. Sighted, my own ears, no ABX, and I don't claim it as evidence. But that's the point for me: the tracks that never got a lossless release are the ones where doing the reconstruction once, properly, matters most.

 

[Erogen]

Time: 3179s (14 track)
Intel Ultra 7+ GPU RTX 5060TI (C: 3008MHz/ M: 1788MHz)
Memory 32GB (available 25 GB)
The configuration of available options is the same in each case.
ALL DSP: ON / FS Multiper: FS 8x
30M Taps: 15.07x Increase in speed + 48,5%
10M Taps: 17.07x Increase in speed+ 24,05%
1M Taps : Increase in speed 23.59x + 21,71 %

ONLY CPU 30 Taps: 5.72x

Time: 3179s (14 track)
Intel Ultra 7+ GPU RTX 5060TI (C: 3008MHz/ M: 1788MHz)
Memory 32GB (available 25 GB)
The configuration of available options is the same in each case.
ALL DSP: ON / FS Multiper: FS 8x

The experiments continue.
This time, two copies of the program were launched almost simultaneously (with a 3-second interval):
1. Tracks 1–7
2. Tracks 8–14
Processing time:
135 seconds – 23.59x

The program's author needs to work on optimization.

 

[Erogen]

@Erogen You were right, and I was too quick with "the converter takes that out". At 65536 your hump sits at 0.7–1.3 Hz: that's a component near 1 Hz at about 1 % of full scale, different in each channel, not an offset. Subtracting the mean removes nothing from it.

Your file is a real case, so 1.2.8 has a switch for it: https://github.com/ToxaDev/aura-engine/releases/tag/v1.2.8

Subsonic Filter, off by default. A linear-phase high-pass at the source rate, so nothing above the corner moves in level or in timing: flat within 0.01 dB from the corner up, at least 100 dB down from half the corner to DC. The corner is 20, 15 or 10 Hz (click the chip on the SUB row), and the file name says SUB20. It's there for the speakers, not for the sound.

To check it on your disc: the output is 352.8 kHz, so use size 131072 (2.7 Hz per bin). Without the filter the first bins still show the hump at about −40 dB; with SUB20 they should drop to the floor. The picture is a test file built like yours (1 Hz at 0.94 % under noise and a 40 Hz tone) through 1.2.8 both ways.

View attachment 558965

It works. It’s great. The option to choose is also great. Hats off. Many CDs from the 80s have a problem with this. Very useful for vinyl records.

 

[Erogen]

However, another problem arose.
The 352 kHz version disables the audio controls on my RME 2/4 SE.

 

[ToxaDev]

However, another problem arose.
The 352 kHz version disables the audio controls on my RME 2/4 SE.View attachment 558974


View attachment 558975

That one isn't the converter, it's the RME. Its DSP runs out of room at high sample rates, and the manual says it plainly: "At sample rates 352.8 kHz and up the Bass, Treble and Loudness function is deactivated" (ADI-2/4 Pro SE User's Guide, 8.8 DSP Limitations). Your two screenshots show exactly that: Bass/Treble and Loudness grey at 352.8k, live at 44.1k, while volume and the parametric EQ keep working. Any 352.8k or 384k file does the same, so this isn't new in 1.2.8. The 1.2.7 files would have switched them off too.

Worth knowing if you compare the two: on this box the 44.1k original plays with your +4 dB bass shelf at 85 Hz, +2 dB treble at 6.5 kHz and part of the Loudness boost (at -14 dB with Vol-Ref -20 it isn't zero yet). The 352.8k file plays with none of that.

Two ways around it:

- The parametric EQ still runs at 352.8k, and your bands 1 and 5 are already set to Low Shelf and High Shelf. Band 1 at +4.0 dB / 85 Hz / Q 0.9 and band 5 at +2.0 dB / 6500 Hz / Q 0.7 should get you close to your Bass/Treble. Loudness has no stand-in there, because it follows the volume knob.
- Or convert at FS 4x (176.4k), where the RME keeps everything. The 10M and 30M bundles only carry the 8x filters; the 4x ones are in the filter packs on the release page.

 

[Erogen]

- Or convert at FS 4x (176.4k), where the RME keeps everything. The 10M and 30M bundles only carry the 8x filters; the 4x ones are in the filter packs on the release page.

Yes

 

[Erogen]

View attachment 558970

Time: 3179s (14 track)
Intel Ultra 7+ GPU RTX 5060TI (C: 3008MHz/ M: 1788MHz)
Memory 32GB (available 25 GB)
The configuration of available options is the same in each case.
ALL DSP: ON / FS Multiper: FS 8x

The experiments continue.
This time, two copies of the program were launched almost simultaneously (with a 3-second interval):
1. Tracks 1–7
2. Tracks 8–14
Processing time:
135 seconds – 23.59x

The program's author needs to work on optimization.

AE 1.28
AE · 44.1k→176.4k · Kaiser 30M · f64 · SUB20 · AA · HP

Time: 3179s (14 track)
Intel Ultra 7+ GPU RTX 5060TI (C: 3008MHz/ M: 1788MHz)

1 program instance processing speed: 26.49x
2 program instances processing speed: 34.55x

That is really good.

 

[Erogen]

Before and after.
AE · 44.1k→176.4k · Kaiser 30M · f64 · SUB20 · AA · HP

As is well known, recordings vary in loudness—specifically, in terms of RMS.
This can be inconvenient at times, requiring volume adjustments during playback.
In this case, the difference is 3.96 dB.
After using AU, the difference is 3.12 dB.

 

[formdissolve]

Because that's where it started for me: MP3s through PGGB, and I liked what I heard. Some tracks only exist that way (the Rich Girl leak from my first post never had a proper master), and I listen across a wide range of tracks and genres, so a lossy source doesn't bother me; often there's no other choice. The converter doesn't bring back what the codec cut, the highs stay where they are. What I hear is the opposite of what you'd expect, though: on lossless sources the change is subtle, on MP3s it's large. Sighted, my own ears, no ABX, and I don't claim it as evidence. But that's the point for me: the tracks that never got a lossless release are the ones where doing the reconstruction once, properly, matters most.

Right, but GIGO (Garbage In Garbage Out) - how does this software do anything to MP3 if there is nothing there that it can "reveal" if MP3 cuts off all the highs? I see @Erogen shows positive results for FLAC or WAV, but I am very scepital over anything it can do for compressed and cut MP3.

 

[ToxaDev]

Right, but GIGO (Garbage In Garbage Out) - how does this software do anything to MP3 if there is nothing there that it can "reveal" if MP3 cuts off all the highs? I see @Erogen shows positive results for FLAC or WAV, but I am very scepital over anything it can do for compressed and cut MP3.

On the band you're right, and I'm not arguing: nothing above the codec's cutoff comes back, and nothing is "revealed".

So the point isn't to add anything back. It's to not lose what's there. The one MP3-specific thing is at the top of the scale: I decoded 58 random MP3s from my library to float this morning, and 40 have samples above 0 dBFS, median peak +0.5 dB, one in ten above +1 dB, the worst +2 dB with 1.5 % of its samples over. A CD rip can't do that; a decoded MP3 does it routinely. The link to a DAC is integer PCM, so the player either attenuates those overs or clips them, and most clip. The converter keeps them, scales the file once to −0.5 dBTP and writes 24 bit. That's true as of 1.2.9, released last night: earlier versions clipped those overs on the way in, which was the decoder bug from my first post, now closed. A −3 dB preamp in the player gets most of that, as Mnyb said upthread. The rest is what it does to any file: the reconstruction runs once, in the file, instead of in the DAC. The adaptive apodizer doesn't touch a lossy source at all: it sees the codec's wall and leaves it alone.

What I hear on MP3s is most likely mostly that: a dB or two quieter and no clipped peaks. No level-matched ABX, and I'm not claiming one. The overs you can check in a minute: decode any MP3 to float and count the samples above 1.0.

 

[Erogen]

AE 1.28
AE · 44.1k→176.4k · Kaiser 30M · f64 · SUB20 · AA · HP

Time: 3179s (14 track)
Intel Ultra 7+ GPU RTX 5060TI (C: 3008MHz/ M: 1788MHz)

1 program instance processing speed: 26.49x
2 program instances processing speed: 34.55x

That is really good.

AE 1.29
AE · 44.1k→176.4k · Kaiser 30M · f64 · SUB20 · AA · HP

Time: 3179s (14 track)
Intel Ultra 7+ GPU RTX 5060TI (C: 3008MHz/ M: 1788MHz)
Memory 32GB (available 25 GB)

1 program instance processing speed: 28.13x + 6.02%
2 program instances processing speed: 31.47x - 9,18%
Two instances of the program mean 2 × 4 active threads. The program reports waiting for available memory, causing momentary pauses. It therefore seems that a single instance with 5 or 6 threads would be optimal.
However, I believe that two instances with (2 ×) 3 active threads will yield the best result. – 34.55x
[Edit]

Test number 1
2 copies of the program.
First copy: files 1 through 7; second copy (launched approximately 4 seconds later): files 8 through 14.
Processing speed: 31.47x (- 9,18%)

Test number 2

2 copies of the program.
First copy: files 8 through 14; second copy (launched approximately 4 seconds later): files 1 through 7.
Processing speed: 36.96x (+6.97%)

7 + 7 doesn't always equal 14

It seems, then, that the problem is the amount of available system memory.

 

[Erogen]

AE 1.29
Time: 4114s (18 track)
Intel Ultra 7+ GPU RTX 5060TI (C: 3008MHz/ M: 1788MHz)
Memory 32GB (available 25 GB)
[AE · 96k→192k · Kaiser 30M · f64 · SUB20 · HP]
2 program instances (2 x 4 threads) processing speed (1 to 9 track+10 to 18 track) - 26,71 x
2 program instances (2 x 4 threads) processing speed (18 to 10 track+ 9 to 1 track) - 31,40 x

 

[Erogen]

Before.

After.

 

[formdissolve]

@Erogen what are you using for that spectrum analyzer?