Re: Dolby A example (was Re: Has anyone ever used `echos` or `chorus`?)
John Dyson via Sox-users <[email protected]> Thu, 13 Feb 2025 02:04:42 +0000 (UTC)
| Newsgroups | gmane.comp.audio.sox |
|---|---|
| Message-ID | <[email protected]> |
--===============7942366548487799523==
Content-Type: multipart/alternative;
boundary="----=_Part_6531511_1687930738.1739412282060"
Content-Length: 19980
------=_Part_6531511_1687930738.1739412282060
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
About the DolbyA thing...(Please ignore the continual run-on sentences!!!=
=C2=A0 My composition skills suck.)
The magic in DolbyA is about how the attack/release conforms to the wavefor=
m.If you want to emulate a DolbyA unit, and it's *really good* behavior, lo=
ok carefully at the attack/release circuit.
The general compressor design as in R. Dolby's patents does produce GOOD re=
sults for general use (beyond DolbyA applications.)=C2=A0=C2=A0 I have play=
ed with reasonably precise SW emulators for GP compression, and they seem t=
o work very cleanly.=C2=A0 My current project UTILIZES the DolbyA emulation=
, but the emulator works well enough for now.=C2=A0=C2=A0 The current 'chal=
lenge' is the dispersive compressor/expander that is also part of the proje=
ct.
Referring to the Dolby compressor circuit, those diodes in the circuit are =
NOT simple rectifiers, but the I/V diode log curves are a critical part of =
the proper behavior.=C2=A0 Early on,In an attempt to 'improve' the design,=
=C2=A0 I designed all kinds of poorly working 'superior' detectors with oth=
erwise similar attack/release, with pretty terrible results decoding real D=
olbyA materials.=C2=A0=C2=A0=C2=A0 This need for compliance is especially i=
mportant below about 600Hz so that the waveform and envelope contours are p=
recisely the same for encoding/decoding.=C2=A0=C2=A0 If the attack/release =
behavior below about 600Hz isn't correct, then there will be distortion in =
the audio.=C2=A0=C2=A0 (The attack/release times on DolbyA generally comply=
with the envelope 600Hz, and waveform sensitive below that frequency, but =
especially below the 100Hz range.)=C2=A0=C2=A0 Also, the 'compliant' attack=
/release is layered in two phases.=C2=A0=C2=A0 Incorrect attack times are e=
specially egregious with serious amounts of harshness if too fast.=C2=A0 Th=
ere is also a propagation delay between the 3k-20k+ range and the 9k-20k+ r=
ange compressors/expanders (because of the competitive feedback scheme.)=C2=
=A0 With an incorrect propagation though the software compressor emulator, =
the HF edges can be obliterated or overly enhanced.
I have a decoder that has been iteratively optimized over the years, and ha=
s recently become fairly good at decoding ripped DolbyA materials.=C2=A0 Un=
til the software closely emulated the DolbyA HW behavior, including the FET=
circuit VGA, then the results were much worse.=C2=A0=C2=A0 The software de=
coder source is ugly because I never cared about sanitizing it, however I d=
o use it every day as a part of another application.=C2=A0 The decoder is c=
omprised of a fitted curve for the FET circuit gain, and an iteratively twe=
aked emulation of the diode curves.
I do suggest that a compressor with general DolbyA characteristics might be=
reasonable to do with SoX. Truly encoding/decoding DolbyA materials is a t=
otally different world.(Also, the Q values for the band splitter are approx=
0.42 for 8.8kHz, 0.45 for 2.7kHz and apprx 1 or 1.2 for somewhere around 7=
5-80Hz?? (I forget the exact numbers).=C2=A0=C2=A0 I emulated the bandpasse=
s with a 'tweaked' set of FIR filters, and unfolded the compressors into ac=
tual expanders (along with a bit of other math tweaks.)
Doing it again, I would have implemented my decoder in a slightly more clea=
n way and done a little more professional job of writing it.Currently, the =
decoder is not normally used all by itself, but is used in an array of deco=
ders cobbled together to created a wider range expander.
Anyone really interested in emulating DolbyA behavior, feel free to contact=
me, I lurk on Hoffman and Audiophile Style, where I blather about my crazy=
processing project.=C2=A0 It is probably very off topic for this mailing l=
ist...
Have fun!!!John
On Wednesday, February 12, 2025 at 06:01:43 PM EST, SoX NG <sox_ng@fast=
mail.com> wrote: =20
=20
On 12/02/25 20:56, Doug Lee wrote:
> Off-list communication on this one welcome so we don't stray too far. :-)
Me, I tend to write off-list messages and then sent to the list by mistake.
Fortunately I seldom say anything too outrageous :-)
However, as long as it's relevant to anyone interested in precise low-level
audio processing...
> On Wed, Feb 12, 2025 at 08:21:34PM +0100, Martin Guy wrote:
>> Do the flow diagrams work for you
> On paper yes those can work if brailled right; but on a computer, at leas=
t I personally don't usually follow those.
Thanks, I'll keep that in mind.
> I understand compand and mcompand fairly well but am not an expert at cra=
fting effects for specific
> purposes with them.
For that I had to dig out Ray Dolby's original paper plus a few other=20
descriptions
and measure his hand-drawn graphs with a ruler to figure out the curves'=20
coordinates
but was happy when one followed by the other produced something that=20
sounded the same.
The --plot output was very similar to the original diagrams so it went=20
fairly well.
Dolby B and C instead have a single sliding frequency band, not=20
something I think SoX can do,
but they are worse cheap versions for consumer boxes.
>>=C2=A0 A recent example where I did not succeed was a recording someone s=
ent me where the
>> volume cut way down at a certain point.
The new "softvol" effect may help here. It's a simple volume multiplier tha=
t
immediately reduces the volume when a sample would have clipped and
optionally increases the volume continuously so that it doubles every N=20
seconds.
I use it all the time to blast the quartiere with nonstop music as it=20
makes the
audibility of the result independent of the original recording volume
and stuff in the quiet passages as audible as in the loud ones.
Since I start at volume *=3D 400 (!) the very start of each track is=20
always interesting.
There's an extreme example of it at work under http://martinwguy.net/test -
the long filename full of sox effect names.
However, I'm not sure you *can* restore something like what you describe
to its original dynamics because information has been lost.
> I did, though, just write a small Python utility for scanning files via s=
ound very fast
> using a two-stage SoX pipe and 1-10ms tones on a 256-frequency range to r=
epresent bytes
Do you mean a single tone that blips at one of 256 frequencies according=20
to its value and
recognizing certain characteristic sequences? Interesting.
One of my passions is for log-frequency-axis spectrograms, which=20
translate sound from
the audio domain to the visual one - not a lot of use to you but maybe=20
for deaf people to
let them see speech and music - however there are inverse techniques to=20
turn a spectrogram
back into the original sound, or a best effort at it. Peter Zinovieff's=20
tried this in the 1960s
and in one of his notebooks describes scanning a picture of a flower and=20
converting it into
sound as a particularly fascinating experiment. My own efforts in this=20
direction are documented
at https://wikidelia.net/wiki/Spectrograms#Inverse_spectrograms
That suggests adding JPG and PNG as input and output formats to SoX
as synonyms for spectrograms without axes, presumably with the lower and
upper frequencies and the pixel-columns-per-second and dynamic range
in image comments or as format parameters.
One thing at a time though...
M
_______________________________________________
Sox-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sox-users
=20
------=_Part_6531511_1687930738.1739412282060
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head></head><body><div class=3D"ydp689b5f84yahoo-style-wrap" style=
=3D"font-family:lucida console, sans-serif;font-size:16px;"><div></div>
<div dir=3D"ltr" data-setdir=3D"false">About the DolbyA thing...</d=
iv><div dir=3D"ltr" data-setdir=3D"false">(Please ignore the continual run-=
on sentences!!! My composition skills suck.)</div><div dir=3D"ltr" da=
ta-setdir=3D"false"><br></div><div dir=3D"ltr" data-setdir=3D"false">The ma=
gic in DolbyA is about how the attack/release conforms to the waveform.</di=
v><div dir=3D"ltr" data-setdir=3D"false">If you want to emulate a DolbyA un=
it, and it's *really good* behavior, look carefully at the attack/release c=
ircuit.</div><div dir=3D"ltr" data-setdir=3D"false"><br></div><div dir=3D"l=
tr" data-setdir=3D"false">The general compressor design as in R. Dolby's pa=
tents does produce GOOD results for general use (beyond DolbyA applications=
.) I have played with reasonably precise SW emulators for GP co=
mpression, and they seem to work very cleanly. My current project UTI=
LIZES the DolbyA emulation, but the emulator works well enough for now.&nbs=
p; The current 'challenge' is the dispersive compressor/expander that=
is also part of the project.<br></div><div dir=3D"ltr" data-setdir=3D"fals=
e"><br></div><div dir=3D"ltr" data-setdir=3D"false">Referring to the Dolby =
compressor circuit, those diodes in the circuit are NOT simple rectifiers, =
but the I/V diode log curves are a critical part of the proper behavior.&nb=
sp; Early on,In an attempt to 'improve' the design, I designed all ki=
nds of poorly working 'superior' detectors with otherwise similar attack/re=
lease, with pretty terrible results decoding real DolbyA materials. &n=
bsp; This need for compliance is especially important below about 600=
Hz so that the waveform and envelope contours are precisely the same for en=
coding/decoding. If the attack/release behavior below about 600=
Hz isn't correct, then there will be distortion in the audio. (=
The attack/release times on DolbyA generally comply with the envelope 600Hz=
, and waveform sensitive below that frequency, but especially below the 100=
Hz range.) Also, the 'compliant' attack/release is layered in t=
wo phases. Incorrect attack times are especially egregious with=
serious amounts of harshness if too fast. There is also a propagatio=
n delay between the 3k-20k+ range and the 9k-20k+ range compressors/expande=
rs (because of the competitive feedback scheme.) With an incorrect pr=
opagation though the software compressor emulator, the HF edges can be obli=
terated or overly enhanced.<br></div><div dir=3D"ltr" data-setdir=3D"false"=
><br></div><div dir=3D"ltr" data-setdir=3D"false">I have a decoder that has=
been iteratively optimized over the years, and has recently become fairly =
good at decoding ripped DolbyA materials. Until the software closely =
emulated the DolbyA HW behavior, including the FET circuit VGA, then the re=
sults were much worse. The software decoder source is ugly beca=
use I never cared about sanitizing it, however I do use it every day as a p=
art of another application. The decoder is comprised of a fitted curv=
e for the FET circuit gain, and an iteratively tweaked emulation of the dio=
de curves.</div><div dir=3D"ltr" data-setdir=3D"false"><br></div><div dir=
=3D"ltr" data-setdir=3D"false">I do suggest that a compressor with general =
DolbyA characteristics might be reasonable to do with SoX. Truly encoding/d=
ecoding DolbyA materials is a totally different world.</div><div dir=3D"ltr=
" data-setdir=3D"false">(Also, the Q values for the band splitter are appro=
x 0.42 for 8.8kHz, 0.45 for 2.7kHz and apprx 1 or 1.2 for somewhere around =
75-80Hz?? (I forget the exact numbers). I emulated the bandpass=
es with a 'tweaked' set of FIR filters, and unfolded the compressors into a=
ctual expanders (along with a bit of other math tweaks.)</div><div dir=3D"l=
tr" data-setdir=3D"false"><br></div><div dir=3D"ltr" data-setdir=3D"false">=
<i>Doing it again, I would have implemented my decoder in a slightly more c=
lean way and done a little more professional job of writing it.</i></div><d=
iv dir=3D"ltr" data-setdir=3D"false">Currently, the decoder is not normally=
used all by itself, but is used in an array of decoders cobbled together t=
o created a wider range expander.</div><div dir=3D"ltr" data-setdir=3D"fals=
e"><br></div><div dir=3D"ltr" data-setdir=3D"false">Anyone really intereste=
d in emulating DolbyA behavior, feel free to contact me, I lurk on Hoffman =
and Audiophile Style, where I blather about my crazy processing project.&nb=
sp; It is probably very off topic for this mailing list...</div><div dir=3D=
"ltr" data-setdir=3D"false"><br></div><div dir=3D"ltr" data-setdir=3D"false=
">Have fun!!!</div><div dir=3D"ltr" data-setdir=3D"false">John</div><div di=
r=3D"ltr" data-setdir=3D"false"><br></div><div dir=3D"ltr" data-setdir=3D"f=
alse"><br></div><div dir=3D"ltr" data-setdir=3D"false"><br></div><div dir=
=3D"ltr" data-setdir=3D"false"><br></div><div dir=3D"ltr" data-setdir=3D"fa=
lse"><br></div><div><br></div>
=20
</div><div id=3D"yahoo_quoted_0337867140" class=3D"yahoo_quoted">
<div style=3D"font-family:'Helvetica Neue', Helvetica, Arial, s=
ans-serif;font-size:13px;color:#26282a;">
=20
<div>
On Wednesday, February 12, 2025 at 06:01:43 PM EST,=
SoX NG <[email protected]> wrote:
</div>
<div><br></div>
<div><br></div>
=20
=20
<div><div dir=3D"ltr">On 12/02/25 20:56, Doug Lee wrote:<br=
clear=3D"none">> Off-list communication on this one welcome so we don't=
stray too far. :-)<br clear=3D"none"><br clear=3D"none">Me, I tend to writ=
e off-list messages and then sent to the list by mistake.<br clear=3D"none"=
><br clear=3D"none">Fortunately I seldom say anything too outrageous :-)<br=
clear=3D"none"><br clear=3D"none">However, as long as it's relevant to any=
one interested in precise low-level<br clear=3D"none"><br clear=3D"none">au=
dio processing...<br clear=3D"none"><br clear=3D"none"><br clear=3D"none">&=
gt; On Wed, Feb 12, 2025 at 08:21:34PM +0100, Martin Guy wrote:<br clear=3D=
"none">>> Do the flow diagrams work for you<br clear=3D"none">> On=
paper yes those can work if brailled right; but on a computer, at least I =
personally don't usually follow those.<br clear=3D"none"><br clear=3D"none"=
>Thanks, I'll keep that in mind.<br clear=3D"none"><br clear=3D"none">> =
I understand compand and mcompand fairly well but am not an expert at craft=
ing effects for specific<br clear=3D"none"><br clear=3D"none"> > purpose=
s with them.<br clear=3D"none"><br clear=3D"none">For that I had to dig out=
Ray Dolby's original paper plus a few other <br clear=3D"none">description=
s<br clear=3D"none"><br clear=3D"none">and measure his hand-drawn graphs wi=
th a ruler to figure out the curves' <br clear=3D"none">coordinates<br clea=
r=3D"none"><br clear=3D"none">but was happy when one followed by the other =
produced something that <br clear=3D"none">sounded the same.<br clear=3D"no=
ne"><br clear=3D"none">The --plot output was very similar to the original d=
iagrams so it went <br clear=3D"none">fairly well.<br clear=3D"none"><br cl=
ear=3D"none">Dolby B and C instead have a single sliding frequency band, no=
t <br clear=3D"none">something I think SoX can do,<br clear=3D"none"><br cl=
ear=3D"none">but they are worse cheap versions for consumer boxes.<br clear=
=3D"none"><br clear=3D"none"><br clear=3D"none">>> A recent ex=
ample where I did not succeed was a recording someone sent me where the<br =
clear=3D"none">>> volume cut way down at a certain point.<br clear=3D=
"none"><br clear=3D"none">The new "softvol" effect may help here. It's a si=
mple volume multiplier that<br clear=3D"none"><br clear=3D"none">immediatel=
y reduces the volume when a sample would have clipped and<br clear=3D"none"=
><br clear=3D"none">optionally increases the volume continuously so that it=
doubles every N <br clear=3D"none">seconds.<br clear=3D"none"><br clear=3D=
"none">I use it all the time to blast the quartiere with nonstop music as i=
t <br clear=3D"none">makes the<br clear=3D"none"><br clear=3D"none">audibil=
ity of the result independent of the original recording volume<br clear=3D"=
none"><br clear=3D"none">and stuff in the quiet passages as audible as in t=
he loud ones.<br clear=3D"none"><br clear=3D"none">Since I start at volume =
*=3D 400 (!) the very start of each track is <br clear=3D"none">always inte=
resting.<br clear=3D"none"><br clear=3D"none">There's an extreme example of=
it at work under <a shape=3D"rect" href=3D"http://martinwguy.net/test" tar=
get=3D"_blank">http://martinwguy.net/test</a> -<br clear=3D"none"><br clear=
=3D"none">the long filename full of sox effect names.<br clear=3D"none"><br=
clear=3D"none"><br clear=3D"none">However, I'm not sure you *can* restore =
something like what you describe<br clear=3D"none"><br clear=3D"none">to it=
s original dynamics because information has been lost.<br clear=3D"none"><b=
r clear=3D"none">> I did, though, just write a small Python utility for =
scanning files via sound very fast<br clear=3D"none"><br clear=3D"none">>=
; using a two-stage SoX pipe and 1-10ms tones on a 256-frequency range to r=
epresent bytes<br clear=3D"none"><br clear=3D"none">Do you mean a single to=
ne that blips at one of 256 frequencies according <br clear=3D"none">to its=
value and<br clear=3D"none"><br clear=3D"none">recognizing certain charact=
eristic sequences? Interesting.<br clear=3D"none"><br clear=3D"none">One of=
my passions is for log-frequency-axis spectrograms, which <br clear=3D"non=
e">translate sound from<br clear=3D"none"><br clear=3D"none">the audio doma=
in to the visual one - not a lot of use to you but maybe <br clear=3D"none"=
>for deaf people to<br clear=3D"none"><br clear=3D"none">let them see speec=
h and music - however there are inverse techniques to <br clear=3D"none">tu=
rn a spectrogram<br clear=3D"none"><br clear=3D"none">back into the origina=
l sound, or a best effort at it. Peter Zinovieff's <br clear=3D"none">tried=
this in the 1960s<br clear=3D"none"><br clear=3D"none">and in one of his n=
otebooks describes scanning a picture of a flower and <br clear=3D"none">co=
nverting it into<br clear=3D"none"><br clear=3D"none">sound as a particular=
ly fascinating experiment. My own efforts in this <br clear=3D"none">direct=
ion are documented<br clear=3D"none"><br clear=3D"none">at <a shape=3D"rect=
" href=3D"https://wikidelia.net/wiki/Spectrograms#Inverse_spectrograms" tar=
get=3D"_blank">https://wikidelia.net/wiki/Spectrograms#Inverse_spectrograms=
</a><br clear=3D"none"><br clear=3D"none">That suggests adding JPG and PNG =
as input and output formats to SoX<br clear=3D"none"><br clear=3D"none">as =
synonyms for spectrograms without axes, presumably with the lower and<br cl=
ear=3D"none"><br clear=3D"none">upper frequencies and the pixel-columns-per=
-second and dynamic range<br clear=3D"none"><br clear=3D"none">in image com=
ments or as format parameters.<br clear=3D"none"><br clear=3D"none">One thi=
ng at a time though...<div class=3D"yqt3712767700" id=3D"yqtfd76429"><br cl=
ear=3D"none"><br clear=3D"none">M<br clear=3D"none"><br clear=3D"none"><br =
clear=3D"none"><br clear=3D"none">_________________________________________=
______<br clear=3D"none">Sox-users mailing list<br clear=3D"none"><a shape=
=3D"rect" ymailto=3D"mailto:[email protected]" href=3D"mailto=
:[email protected]">[email protected]</a><br cl=
ear=3D"none"><a shape=3D"rect" href=3D"https://lists.sourceforge.net/lists/=
listinfo/sox-users" target=3D"_blank">https://lists.sourceforge.net/lists/l=
istinfo/sox-users</a><br clear=3D"none"></div></div></div>
</div>
</div></body></html>
------=_Part_6531511_1687930738.1739412282060--
--===============7942366548487799523==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
--===============7942366548487799523==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Sox-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sox-users
--===============7942366548487799523==--