Problem #1.
CPUs have Branch Prediction algorithms, and Speculative Execution Algorithms....
that means:
CPU double Guess the result, before result is actually computed,,,
that does Not affect simple things, like counting from 0 to 1000 in C++
but does affect Audio plugins.
Prediction can Never bee 100% accurate,
CPUs will never sound like real analog,
unless you make a CPU without Prediction algorithms..
DSP like ProTools HD or HDX,
dont have that problem.
plugins if done properly sound almost the same as analog.
and even if you make a CPU without prediction algorithms in FPGA,
still wont sound the same....
because CPUs also have 10 Million interrupts per second.
digital audio is serial, algorithms does Not like to be paused 10 Million times per
second.
creates another sample and hold over, digitized audio "sample & hold"
using buffer size of 32 or less, minimize that problem, does sound a bit better,
at least on ProTools, but CPU goes crazy...
1x or 2x plugins consume 100% CPU load.
while a 1024 or 2048 buffer size allow 1000x of plugins.
Problem #2.
Nyquist limit vs. Clock Jitter,
Audio at 44.1KHz, gets totally distorted over 5.5KHz,
because Digital Audio was designed for Pure Sine Waves Only,
Real Audio like Square waves, have many harmonics over the fundamental Frequency,
a Square wave over 5.5Khz has total distortion at 44.1KHz.
using a higher sampling frequency like 48Khz, 96Khz, 192Khz, 384KHz
moves the problem to a higher frequency 10Khz, 15Khz, 20KHz.
but creates another problem... Clock Jitter..
because Digital Audio is Serial, requires a very fast clock signal,
faster than the speed of sound,
so it can be perceived simultaneously, both cannels and all frequencies at same time,
but that requires a super high precision low jitter clock signal
clock jitter will create aperture errors in the ADC,
and harmonic Phase cancelations in the DAC.
there is a formula,
bits x channels x sample rate = minimum jitter for Aperture error free signal,
Clock signal must be 1pico second jitter for 192Khz 24-Bits.
that is super high end, expensive clock generator.
ultra low phase noise clock, etc...
most audio sound cards/interfaces do Not have that level of precision.
its similar to photography,
digital sensors have Pixel Shift technology to increase resolution,
they use a Quartz oscillator to move all pixels by microns,
but....
using small pixels, and small sensors does Not work as good,
as using large sensors with larger pixels.
digital vs. analog,
audio or photography is very similar.
Problem #3
Most Audio plugin developers,
when Emulate Tubes, are like taking a photo,
but Real Tubes breath, have life, movement of electrons, thermal noise, is never the same,
most Tube emulator plugins fail to replicate that.
tape is similar, even using solid state amplifiers,
iron particles or CrO2 particles are similar to Silver particles in Analog Film
Photography.
Head Magnetic Fields, core saturation characteristics, etc...
same as photography:
CMOS sensor looks like plastic,
vs. Real Analog Film.
Scanning Film with CCD sensor or Photo Multiplier Tube is better
vs. Taking a Photo of a Film.
Dmax, and RGB is better,
but Taking a Photo is Faster & cheaper.
same dilemas.
________________________________________
From: Fons Adriaensen <fons(a)linuxaudio.org>
Sent: Wednesday, October 16, 2024 8:23 AM
To: Linux Audio Developers; Linux Audio Users
Subject: [LAD] Tape emulation - is it worth the effort ?
Hello all,
The purpose of this post is to gather some opinions on the
use of 'tape distortion' plugins.
The way an analog magnetic tape recorder distorts the signal
is quite complicated. The non-linear response is mainly due
to the hysteresis of the magnetisation process, and how this
interacts with the HF bias added to the recorded signal.
Simplifying things a bit, as the tape moves past the recording
head and away from it, it goes through several cycles of an
hysteresis loop with decreasing amplitude, and it finally
converges to some value more or less proportional to the signal.
The bias signal itself does not remain on the tape, or at most
at a very low level.
The same process but with just a very high level HF bias is
used to erase the tape.
Simulating this accurately is quite complicated, and very CPU
intensive. The sample rate must be at least twice the bias
frequency (around 100 kHz for 'pro' equipment) and for each
sample you need to evaluate the hysteresis loop up to a hundred
times (depending on tape speed) to simulate the convergence.
Over the past few months I've written the code to do this,
with the aim to present a useful 'tape emulation' plugin
at the next LAC. It uses a somewhat simplified form of the
Preisach algorithm for the hysteresis.
<http://kokkinizita.linuxaudio.org/linuxaudio/downloads/preisach-model.pdf>
But the first results are somewhat sobering.
Have a look at
<http://kokkinizita.linuxaudio.org/linuxaudio/downloads/tapesaturation.png>
This shows the tranfer function (recorded magnetic signal as
a function of the input) for three values of the HF bias.
The blue line is what you get without bias. It result in a
very smooth saturation for high level signals, but a low
amplitude signal will be severly distorted due to the flat
region around zero.
As bias level is increased, this effect is reduced and the
low level gain increases up to some maximum. This is shown
by the orange curve.
The recommended way to set the correct bias level is to
further increase it until the small signal gain is reduced
by a few dB (typically 1 or 2 dB, depending on tape type).
This is shown by the green curve.
The central part of this is very linear (less than 1% THD).
But now the smooth saturation is almost transformed into
hard clipping. The sharp bend in the curve occurs when the
signal amplitude is higher than the bias amplitude.
The only effect that remains in a complete simulation is
the result of the EQ applied to the signal to be recorded.
Higher frequencies have a 'self erasure' effect (which is
nicely reproduced by the simulation) and so need to be
amplified. The net result is that they will saturate at
a lower input level.
How much EQ is required depends mainly on tape speed, higher
speeds need less. At the most popular 'pro' speed (381 mm/s)
this would be something around 10 dB at 10 kHz. At the higher
(762 mm/s) speed typically used for 'master tapes' it's just
a few dB.
So what does effectively remain of the 'smooth saturation
and compression' that is claimed to give tape recording its
magical 'warm' character ? Is it just a myth ?
I also simulated the green curve directly without going
through the complicated full simulation, and honestly,
to me that sounds just the same. And unless you really
use very high levels (much more than would actually be
used) the net effect is marginal. Maybe the hard clipping
can be useful when applied to individual tracks (e.g.
drums or bass), but then there are much simpler ways
to do this than 'tape emulation'.
Comments invited !!
_______________________________________________
Linux-audio-dev mailing list -- linux-audio-dev(a)lists.linuxaudio.org
To unsubscribe send an email to linux-audio-dev-leave(a)lists.linuxaudio.org