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 &lt;fons(a)linuxaudio.org&gt; 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

Le 2024-10-16 à 09 h 23, Fons Adriaensen a écrit : Tape distortion used to be bad; something happened... Technostalgia is valued, but emulation of non-linearities is difficult. I suggest to not give a fig. Marc

On Wed, Oct 16, 2024 at 03:23:44PM +0200, Fons Adriaensen wrote: As a former long-term user of professional multitrack tape recorders, I say good riddance to tape. I think it makes more sense to use separate plugins to emulate individual elements of the tape sound if that's what's required. Interesting research project though. John