Newsgroup: it.comp.musica
Titolo: Variare il volume "rovina" il segnale digitale?

Sì. Però ci ho la spiegazione con tanto di screenshot ;-)
Mettetevi comodi e seguitemi
Per comodità mi riferirò ad un segnale mono 16 bit.
Cosa succede quando amplifichiamo un segnale digitale?
Succede che le ampiezze di ogni sample di questo segnale vengono
moltiplicate (o divise nel caso si debba abbassare il volume) per un
fattore.
Nell'esempio, l'ampiezza del segnale può essere rappresentata al massimo da
16 bit... cosa vuol dire? Vuol dire che il valore di ogni suo sample potrà
variare da -32768 a +32768.
Quindi, se volessimo *raddoppiare* la grandezza di un segnale, basterà
moltiplicare per 2 tutte le ampiezze dei sample. Già, ma questo non avviene
quasi mai! Nel senso che normalizzando un wave il fattore raramente è un
numero intero, l'operazione eseguita dall'editor sarà:
-ricerca del sample con ampiezza maggiore(picco)
-ricerca del fattore di normalizzazione (32768/valore picco)
-moltiplicazione dell'ampiezza di ogni sample per il fattore di
normalizzazione
La prova pratica
Con una vecchia versione di Cool Edit ho fatto alcune prove, e cioè
ho letto il valore iniziale di 4 samples, ho normalizzato l'onda, ho riletto
le ampiezze e...
questa è l'onda, in rosso sono indicati i punti presi in esame
http://utenti.lycos.it/coltrumfunk/waveform.JPG
questi sono i valori dei 4 punti
http://utenti.lycos.it/coltrumfunk/primosmp.JPG
http://utenti.lycos.it/coltrumfunk/secondosmp.JPG
http://utenti.lycos.it/coltrumfunk/terzosmp.JPG
 (picco)
http://utenti.lycos.it/coltrumfunk/quartosmp.JPG
questa la normalizzazione
http://utenti.lycos.it/coltrumfunk/normaliz.JPG
http://utenti.lycos.it/coltrumfunk/wfn.JPG
ok ora facciamo 2 calcoli
fattore di normalizzazione
32768/ 22480(picco) = 1,4576512455516014234875444839858
normalizzazione primo sample:
12656*1,4576512455516014234875444839858
=
18448,034163701067615658362989314
primo sample normalizzato
http://utenti.lycos.it/coltrumfunk/primosmpnorm.JPG
normalizzazione secondo sample:
-88*1,4576512455516014234875444839858
=
-128,27330960854092526690391459068
secondo sample normalizzato
http://utenti.lycos.it/coltrumfunk/secondosmpnorm.JPG
normalizzazione terzo sample(picco):
22480*1,4576512455516014234875444839858
=
32767,999999999999999999999999983
terzo sample normalizzato
http://utenti.lycos.it/coltrumfunk/terzosmpnorm.JPG
 (picco)
normalizzazione quarto sample:
17943*1,4576512455516014234875444839858
=
26154,636298932384341637010676143
quarto sample normalizzato
http://utenti.lycos.it/coltrumfunk/quartosmpnorm.JPG
e i numeri dopo la virgola??? Troncati di netto! Questo non perchè è il
programma che è così, semplicemente perchè i famosi 16 bit devono
rappresentare un numero INTERO. Da qui, la necessaria perdita di
informazione
Ora, magari non si nota, però la perdita di informazione c'è
Andrea

 Andrea
In ascolto si sente la differenza?
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 In ascolto si sente la differenza?
Io non la sento ;-) (non provo neanche a testare, non ho questa sensibilità)
Però la "ditriba" vedeva da una parte chi diceva che il segnale NON SI
DETERIORA, e chi diceva di Sì, e in effetti qualcosa succede, sei d'accordo?

 Ora, magari non si nota, però la perdita di informazione c'è
Evvai! Finalmente qualcuno ha provato!... :)

 wrote in message
news:2gem42F...@uni-berlin.de

Voi altri la sentite?...
Certo, son d'accordo, qualcosa succede!
Ma i numeri a questi livelli non dicono nulla.
Se non siete di questa idea, fatemi sapere con prove alla mano
prima del prossimo TOP AUDIO, si può organizzare
una piccola conferenza. ;-DD


 Sě. Perň ci ho la spiegazione con tanto di screenshot ;-)
clap clap clap clap
Applausi e sentiti ringraziamenti.
Adesso abbiamo la certezza matematica che Ritide aveva ragione, per cui 
tanto di cappello.
Resta da fare la considerazione che probabilmente nemeno un pipistrello 
sarebbe in grado di sentire la differenza tra il primo ed il secondo 
segnale, ma comunque poco importa, le cose stanno cosi', un deterioramento 
del segnale, seppur minimale, c'e'!
Ringrazio tutti i partecipanti alla discussione per il vivace scambio di 
idee e la tenacia mostrata. Oggi molti di noi hanno imparato qualcosa in 
piu', e credo non sia cosa da poco ;-)
A Riptide porgo i miei piu' sentiti ringraziamenti ed una piccola 
"bacchettatina".. magari per il futuro (se possibile, se ne hai voglia e se 
hai tempo) potresti spiegare un po' meglio i concetti e non limitarti ad un 
laconico "e' cosi'".
Comunque grazie a tutti, e grazie di scrivere su ICM. ;-)
-- 
ciao
SdS
http://stage.vitaminic.it/main/riquadro/all_tracks/

> Sì. Però ci ho la spiegazione con tanto di screenshot ;-)
[cut]
Bravo Billo. Inconfutabile.
Resta comunque il fatto che la modifica non è avveribile e non capisco come
uno possa affermare di accorgersi di tali differenze.
O forse uno dovrebbe normalizzare/denormalizzare un migliaio di volte per
accorgersi di qualcosa.
E poi i tuoi calcoli sono relativi ai 16 bit. Credo che la stragrande
maggioranza di quelli che lavorano sull'audio sia in possesso di una scheda
24 bit che rende assolutamente trascurabile (ma già lo era....)
l'approssimazione effettuata dall'operazione.
Ciao, J.

informazione
in un precedente post dicevo che (copy/paste):
ho anche letto che utilizzare mixer nativi (sonar, cubase, etc)
piuttosto che mixer che sfruttano dei DSP dedicati (mixer digitali
esterni, i DSP di pulsar o altre schede audio...) da risultati
diversi, perchè di fatto l'operazione che compi sul volume della
traccia (in fase di mixing) non è una semplice "moltiplicazione" di
numeri, ma probabilmente adotta degli artifici per cercare di
compensare la perdita che ho tentato di spiegare nella prima parte del
messaggio. e i DSP dedicati e la CPU del computer sfruttano tecnoche
diverse per raggiugnere lo stesso risultato
a questo punto mi viene da pensare che ci sia davvero un fondo di
verità in questa leggenda metropolitana... :-)
quando si sente parlare di software che lavorano in "virgola mobile",
(32 bit floating point)  significa che, in fase di calcolo, tengono
conto alle virgole? 
(siamo al delirio matematico, ma dal punto di vista "scolastico" è
interessante... almeno per me! )
********************
Visita il mio sito
www.alchemystudio.it
 
************

 laconico "e' cosi'".
Ma č cosi'! Hai visto o no?? LOL :)
Comunque, e lo dico per tutti, avrei anche altre cosine da dire che in
confronto questo thread non č nulla.
Ma non so se č il caso, se no ci si scanna per davvero! LOL :)
  Ciao

 wrote in message
news:cCqoc.49710$
Qc.20...@twister1.libero.it

Già provato con un test su uno stereo daaa....
15.000 euro di un audiofilo DOC.
La differenza tra 24 bit, 16 bit ed mp3 a 192
si sente con molta fatica. A volte non c'è.


Ma non so se è il caso, se no ci si scanna per davvero! LOL :)
siamo qui apposta!! :-D
dai, spara!!!


 Ma non so se č il caso, se no ci si scanna per davvero! LOL :)
Manda manda, e' sicuramente il caso. Siamo qui apposta per discutere, per 
confrontarci, per imparare. Devo dire con piacere che il thread, nonostante 
sia stato a tratti ai limiti del flame, non e' mai scaduto in basso, e si e' 
mantenuto sempre su toni abbastanza corretti e civili anche se in alcuni 
limitati punti e' magari sembrato un po'.. come dire.. "spigoloso" :)
E poi scusa, discutere e' l'essenza stessa di un newsgroup, no?


   Ciao
Ciao, J.

 si sente con molta fatica. A volte non c'è.
Appunto.
Fermo restando che io oltretutto parlavo di un wav e non di un mp3.
Ciao.

 una piccola conferenza. ;-DD
eheheh :-) ok, mettiamola cosě:
se mai ti venisse in mente di alzare ed abbassare il volume qualche
centinaio(migliaio?) di volte, ricordati di questo post!! :-D

 E poi scusa, discutere e' l'essenza stessa di un newsgroup, no?
Si, ma tu non lo sai le battaglie che ho fatto io sui forum di tutto il
mondo!! :) Te lo lascio immaginare lo stress!
Ogni volta che inizia il thread "giusto" sono decine di messaggi [una volta
c'è stato un mio thread su un forum americano che ha generato centinaia di
risposte ed è stato visto, secondo il contatore, intorno alle 30.000 volte.
Naturalmente (scherzo, eh:) ne sono uscito vincitore ma non ti dico le
bestemmie che mi sono preso! :) L'aspetto positivo è che alla fine un utente
che seguiva il thread mi ha invitato sul suo sito per una "conferenza" :) ]
     Ciao ciao

 dai, spara!!!
No no... :)

 Ti prego: dille.
Ssssshh... Piano piano... ho trovato un sistema per registrare con un
rapporto segnale/rumore intorno ai -130db capace di eliminare completamente
la sporcizia inutile (fruscio, rumore, artefatti nella banda alta) dalla
registrazione DURANTE la registrazione... Iniziamo un altro thread!? :)
   Ciao ciao Jaco...

    Ciao ciao Jaco...
Ciao Ciao Riptide....

 registrazione DURANTE la registrazione... Iniziamo un altro thread!? :)
Yum.
Sembra interessante.
;-P


 Sě. Vai.
Ah ah ah!! Ma guarda che č proprio vero! Non voglio provocare...

> Ah ah ah!! Ma guarda che è proprio vero! Non voglio provocare...
Non era ironico: vai.

 l'approssimazione effettuata dall'operazione.
Verissimo, inoltre la prova è stata fatta con un editor, quindi salvi il
file e basta, ti rimane così com'è. Però penso, come dice anche Bosone, che
i mixer digitali o software prevedano questa "distorsione" e quindi che il
valore con relativa virgola venga elaborato fino alla fine, dai volumi sul
mixer, agli effetti, al volume master per poi ritornare numero intero solo
alla fine, mantenendo quindi una certa precisione. Poi magari è una cazzata,
non lo so. Vedrò di documentarmi :-)
Ciao!

 usano internamente da 24 a 56bit, percui....
...quindi fra normalizzare a priori tutte le tracce con un editor e mixarle
oppure amplificarle direttamente dal mixer si dovrebbe sentire la
differenza, giusto? se la risposta č sě(come a questo punto penso che sia)
tutto il discorso di Riptide risulterebbe corretto


sarebbe carino rifare il test con un programma + nuovo e professionale, tipo
WaveLab4, Spark o Peak.
resto dell'idea che non serve normalizzare affatto tutte le tracce.
ciao
stef

 stef
Ok grazie.
Ciao

> Ora, magari non si nota, però la perdita di informazione c'è
direi di no.
perdi informazione rispetto ad un valore numerico precedente frutto
anch'esso un'approssimazione, in quanto segnale quantizzato. A priori non si
può sapere se il troncamento avvenuto in fase di registrazione fosse più o
meno vicino alla soglia e potrebbe anche essere che dopo una moltiplicazione
e relativo troncamento il campione risultante sia addirittura più vicino al
valore che avrebbe avuto se registrato ad ampiezza già di suo più elevata.
Inoltre è bene ricordare che il rumore di quantizzazione (che è proprio
frutto di questo troncamento) è *uniforme* su tutta la dinamica del segnale,
per cui amplificato o ridotto che sia il segnale, il suo rumore di
quantizzazione rimane costante.
 Quello che cambia è SNR (rapporto segnale rumore) che penalizza i segnali
che sfruttano poca dinamica, ovvero che oscillano a cavallo di pochi
intervalli di quantizzazione, producendo quindi risultati poco accurati.
Non a caso infatti per certe applicazioni sono stati inventati gli adc con
quantizzazione non uniforme (vedi u-law e a-law).. proprio per migliorare
SNR..
Ciao
Daniele
--
http://tastiere.altervista.org
 - THE resource for Synthesizers !
                       Free patches and sounds


Estremizzavo.


 quantizzazione rimane costante.
Anche se di poco(e come abbiamo già detto, in maniera assolutamente
impercettibile all'orecchio), aumenta. Bisognerebbe fare una prova con 2
file: uno si normalizza, si salva, si diminuisce il volume, si salva ,si
normalizza, si salva, si diminuisce il volume, si salva, ecc ecc ecc :-) per
un po' di volte, poi si fa ritornare al volume iniziale. Scommettiamo che
confrontandolo con il file originale qualcosa è cambiato?
Ciao

 sono stati persi dei dati
è questo il punto: anche i dati che chiamiamo "originali" sono frutto di un
troncamento, che arrotonda il valore del segnale con una precisione di 1 LSB
(=Ampiezza/2^#bit). Il fatto che si moltiplichi per un coefficiente ogni
campione non cambia questa situazione: ogni valore numerico infatti porta
con sè un errore di quantizzazione casuale che ha una distribuzione di
ampiezza uniforme. Per cui il campione che subisce una moltiplicazione non
porterà con sè un errore statisticamente maggiore o minore di quello di
partenza.
La condizione per evitare incrementi dell'errore è preservare la dinamica
del segnale: ovvero, se tu denormalizzi a -90dB (è un'attenuazione
spaventosa!) ottieni un segnale che non è più ottimamente descritto da
intervalli di quantizzazione pari a 1/2^16 ad esempio (per 16 bit); ho
appena provato con soundforge: il risultato è che se dopo aver abbattuto di
90dB rinormalizzo a 0dB ottengo una schifezza perchè la il segnale è andato
sotto dinamica minima, ovvero le variazioni erano talmente piccole da non
poter essere ben descritte solo con 16 bit.
Ma quindi non è vero che il segnale quantizzato è indipendente dalla
dinamica! Sì e no. Nel senso che il numero di bit, che determina la
precisione di rappresentazione del livello, è un parametro che si imposta
traendo informazioni da altri parametri del sistema (ad esempio la potenza
del rumore termico di fondo), perchè è inutile avere un quantizzatore a
128bit se poi l'hardware fornisce una potenza di rumore ampiamente
superiore.
A questo punto quindi la risposta più corretta al problema "variare il
volume rovina il segnale digitale" è, tanto per cambiare, "dipende". Se le
variazioni rimangono in un range simile a quello di partenza no, non c'è
problema, SNR non cambia. Se invece si fanno operazioni estreme di
normalizzazione *verso i basso*, ovvero verso le zone in cui la
quantizzazione fa sentire sempre di più i suoi effetti (ma si tratta di SNR,
non di rumore in sè), il segnale si deteriora.


 non di rumore in sè), il segnale si deteriora.
mmm... non mi hai convinto! :-D
quindi mi stai dicendo che se aumentassi gradualmente il volume non ci
sarebbero perdite di definizione *nonostante il continuo troncamento*? E'
una cosa che va oltre logica. Ora provo

 una cosa che va oltre logica. Ora provo
Perfetto, prova te. Crea un file abbastanza pulito, magari con un vst. Lo
devi creare con un volume basso. Ora crei una copia. La prima copia la
normalizzi, e stop. Nella seconda copia invece aumenti il volume poco alla
volta, lo fai 4 o 5 volte, poi alla fine normalizzi. Confronta adesso i 2
file, magari con l'aiuto anche di uno spettro. Incredibile ma vero, il file
su cui hai fatto più variazioni di volume *VERSO L'ALTO*, risulterà una
ciofeca

 Cosa succede quando amplifichiamo un segnale digitale?
Hai scoperto l'acqua calda! ;-)
Questo è il motivo per il quale i mixer virtuali e gli effetti digitali
utilizzano una rappresentazione con un numero di bit superiore alla
quantizzazione originale, proprio per minimizzare gli errori numerici di
troncamento.
Ciao, Sandro.
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

Ho fatto un po' di prove e il si riesce a far deteriorare il segnale
velocemente.
L'effetto è molto più presente di quanto credessi.. comunque non sparavo
cazzate, sono cose che si raccontano nei corsi di elaborazione di segnali e
che si fanno i teoria; in pratica però questi effetti non li avevo mai
testati :)


 troncamento.
Dillo dillo, che ancora non mi si crede! :-))

E' ovvio che ha ragione!
Nel campo digitale la musica è un numero.
Qualcuno di voi si è mai divertito a vedere la propagazione degli
errori in una semplice calcolatrice??
Se ci pensate bene un mixer digitale è in parte composto da una
calcolatrice.
Se per esempio fate la radice quadrata di tre e poi elevate al
quadrato noterete:
- che le calcolatrici economiche e quelle di una volta non tornano più
a al valore 3 , non solo ma rifacendo più volte l'operazione l'errore
aumenta.
- che le calcolatrici moderne invece restituiscono perfettamente il 3
Questo perchè le moderne all'interno hanno un'approssimazione in cifre
maggiore di quella del display e quindi l'errore c'è ancora ma per
vederlo sul display dovreste fare tante tante volte avanti e indietro
dall'operazione di radice quadrata (e qualche volta non la vedreste
nemmeno se hanno usato un firmware furbo a compensazione di errore).
Nel settore musica digitale su PC è avvenuta la stessa cosa.
Le prime versioni di Wavelab e cool edit  e quant'altro lavoravano a
16 bit.
Quindi facendo normalizzazione in su e in giù si produceva una
differenza nell'ambito dei 16 bit utili.
Oggi questi programmi lavorano a 24 o addirittura a 32 bit e quindi
per far apparire un errore nel campo dei 16 bit dovete fare un numero
elevatissimo di modifiche.
Con queste premesse oggi si possono applicare filtri e altre
diavolerie senza paura di deteriorare il segnale originale.
Ovviamente se ogni volta che fate una modifica poi salvate il
risultato a 16 bit vi mettete nella "vecchia condizione" della vecchia
calcolatrice: è come se sulla calcolatrice moderna qualcuno scrivesse
il risultato della radice di 3 su carta e poi lo reintroducesse a mano
prima di fare l'elevazione al quadrato.
Quindi chi deve modificare un file audio digitale a 16 bit è bene che
faccia tutte le modifiche in una sola sessione; oppure se il lavoro è
troppo lungo occorre salvare il lavoro intermedio con una risoluzione
di almeno 24 bit.
Questo è anche il motivo per cui nelle sale di registrazione si usano
i 24 bit (abbastanza inutili da un punto di vista S/N) ma sicuramente
utili, per mantenere gli errori sotto la soglia di udibilità. quando
si prevede di manipolare a lungo i vari segnali e le varie piste prima
di produrre il master originale.
Chiunque può provare quanto sopra proseguendo negli esperimenti (gia
fatti in altri thread sullo stesso argomento) e facendo le prove con
wavelab a 24 bit; il confronto vi dirà sempre che il file normalizzato
e poi riportato al livello di prima è differente da quello non
elaborato ma la differenza per vederla la dovrete amplificare di
almeno 60 db (e sarà ancora infinitesimale).
Se invece salvate a 16 bit i passaggi intermedi la differenza sarà
visibile amplificando di soli 30 db.
Parliamo sempre e comunque di differenze inudibili.
E' ovvio che se invece di fare una sola normalizzazione ...applicate
filtri e fate tante altre cose allora, lavorando solo a 16 bit, potete
anche rovinare un brano.
saluti

 saluti
Ciao, J.

 calcolatrice.
Si e no, ni ... ;-)
Le calcolatrici lavorano in virgola mobile, rappresentando sotto forma di
mantissa ed esponente un numero normalizzato con la virgola subito a
sinistra della prima cifra significativa.
In tali condizioni si verifica una cosa banale ma molto deleteria. Facendo
la differenza fra numeri molto vicini fra loro, che magari differiscono
giusto di pochissimo molto in la fra le cifre non significative, si ha
l'effetto, nel risultato, di veder azzerata la parte significativa.
Ma quella non significa viene normalizzata nella mantissa e diviene
significativa nella prossima operazione, ma in realtà prima della differenza
era trascurabile ...
Nello scenario dei mixer digitali, invece, si tratta di rappresentazioni
intere, quindi a precisione fissa, nelle quali tutto il numero è
significativo, rappresentate in fp all'interno della catena mix ed effetti.
Una differenza ha al massimo uno scarto di una unità, che nella
rappresentazione fp effettuata nel mixer diventa 0.1*10^1, che è
larghissimamente significativo per tutte le rielaborazioni successive. A
maggior ragione se la rappresentazione interna è a 32 bit.
Insomma, credo che stiamo facendo un po di confusione. Un conto è fare:
f(g(h(x))) (caso del mixer digitale)
ed un altro è fare
f(round(g(round(h(x)))) (caso dell'applicazione e salvataggio)
perchè nel primo caso f g ed h (che sono le nostre ipotetiche
funzioni/effetti) sono applicate nel dominio reale, nel secondo in quello
intero a 16 bit.


 valore che avrebbe avuto se registrato ad ampiezza già di suo più elevata.
Ma infatti non credo che sia in discussione l'aderenza della
rappresentazione rispetto all'originale. Credo che il punto sia che una
funzione che arrotonda non è iniettiva. Pertanto ogni volta che la applichi
ti sei allontanato definitivamente da quella di partenza, non fosse altro
che per il fatto che ti è impossibile, con un passaggio deterministico,
ritornare indietro sui tuoi passi.
Che poi questo questa continua perdita informativa non significhi che ad
ogni iterazione l'errore si *aggiunga*, visto che può anche sottrarsi ...


 
Questo è verissimo e ho anche io detto la stessa cosa.
Fintanto che si rimane all'interno di Wavelab con il file aperto in
precisione 24 bit gli errori sono ben sotto l'udibile. Quando si salva
bisogna stare attennti; il programma di default se si è aperto un file
a 16 bit lo salva a 16 bit anche se ci ha lavorato sopra a 24. Quindi
o si fanno tutte le operazioni in una sola sessione o si salva
ESPRESSAMENTE a 24 bit; evitando quello che tu giustamente in
notazione chiami (round); o meglio facendolo 8 bit più in là.
Le prove pratiche, giocando con una sinusoide e le utiliti sempre di
wavelab, confermano l'ipotesi

informazione
Più che un numero intero, il problema è il limite
dell'approssimazione. La perdita di informazione ma più la risoluzione
che stiamo usando per elaborare il segnale è alta, più questa perdita
sarà bassa e insignificante a livello udibile.
Un conto è incapsulare i valori di ampiezza del segnale (propri o
ottenuti dopo un'elaborazione) in una griglia divisa in 65.536
quadretti (16bit), un conto è poterla incapsulare, ad esempio,  in una
griglia divisa in oltre 16 milioni di quadretti (24bit).. é ovvio che
il valore d'ampiezza del campione verrà rappresentato con più
precisione nel secondo caso.. e la perdita di informazione dovuta
all'elaborazione sarà "trascurabile".
E' proprio per questo motivo che è preferibile campionare ed elaborare
il segnale ad alte risoluzioni.. anche se alla fine lo si porterà a 16
bit per creare il prodotto finito.
Ramesse


Concordo. é relativo alla risoluzione, qualche motivo l'ho scritto in
un altro post. 
I 192khz, al massimo, si usano per minimizzare il rientro, nel campo
dell'udibile, di frequenze alias eventualmente generate da strumenti
(sintetici o non) con estensione spettrale che va ben oltre il nostro
campo dell'udibile.
E cmq, la definizione data da Jaco, era IMHO piuttosto esatta anche se
non tecnica: risoluzione e frequenze elevate, alla fine, servono a
ottenere un segnale campionato quanto più possibile fedele
all'originale. Non fa una grinza.
Ramesse


Stavo rileggendo, tra le 200 cose che stavo facendo mentre scrivevo, è
venuto fuori un post un pò impreciso.
Pià precisamente, non è l'alta frequenza che evita la comparsa di
alias, infatti a quello pensa il filtro antialias. Frequenze di
campionamento così alte però garantiscono un campionamento adeguato
per una banda di frequenza che supera di parecchio il nostro limite
dei 20khz... (non solo di qualche Khz come nei 44.100) questo ci
permette di usare un filtro antialias con pendenza molto dolce
evitando alcune distorsioni del segnale sulle alte frequenze come
fischi o traslazioni di fase che un filtro con pendenza troppo rigida
(come quello che saremmo costretti a mettere con un samplerate di
44.1Khz) potrebbe creare.
L'ho scritto in 2 righe ma spero sia abbastanza chiaro.
Ramesse