Newsgroup: it.comp.musica.mp3
Titolo: Normalizzazione e bitrate: aiuto!

Ho una domanda per voi che mi assilla da un paio di giorni: la
normalizzazione di un brano audio dopo l'estrazione influisce sulla
qualità dell'encoding? Mi spiego.
Usando il LAME in vbr, ottengo bitrate medie diverse per ogni brano
(ovvio!) ma mi sono accorto che con cd registrati a basso volume
ottengo bitrate notevolmente più basse del solito. Mi sono spiegato
questo fatto con l'introduzione dell'ATH (absolute treshold of hearing
o qualcosa del genere) nell'algoritmo di compressione, cioè al di
sotto di un certo volume l'orecchio non capta e quindi il lame taglia.
Corretto fin qui? Quindi un cd basso ha meno "picchi" di decibel e
quindi ci vuole meno spazio per encodare ciò che rimane.
Ma poi sono stato folgorato da un bel dubbio: ma se io normalizzo
verso l'alto questi cd prima di encodare, aumento il volume, quindi
vado "a salvare" una buona parte di dati che prima stavano sotto la
soglia uditiva. Normalizzare un mp3 (oppure il relativo wav se lo
decodifico in un secondo tempo) solo dopo l'encoding non mi aiuterebbe
perchè quello che è stato tagliato non sarebbe più recuperabile, anzi
probabilmente non farei altro che evidenziare il mio errore iniziale
portandolo ad un livello più che percettibile. E' vero questo, e se
sì, in che misura? In questo caso normalizzare prima di encodare
sarebbe doveroso, da cui si deduce che io, finora, sarei anche stato
un bel pirla! ;)
Chi se la sente di insultarmi per primo? Grazie e ciao!
Crux

 un bel pirla! ;)
Invece sei stato... sagace!:-))
Normalizzare un singolo brano da un CD serve a ben poco. Non fai che
manipolare una edizione "ufficiale" in base ai tuoi gusti.
Alzare di un paio di db il volume di un brano non aiuta poi tanto a
raggiungere l'effetto sperato. Anzi mi stupirei se riuscissi veramente a
cogliere la differenza (normalizzando per picchi).
Non mi stupisce il fatto che l'encoder invece sprechi piu' bits ad encodare
un wav apparentemente piu' "corposo" (il wav in fondo e' sempre quello,
l'effetto ottenuto e' uguale a quello che ottieni alzando il volume, a meno
che non ricorri ad una compressione sonora).
Non credo cmq che la differenza di bit sia enorme (almeno mi auguro,
altrimenti tutti normalizzerebbero con l'intento di abbassare la percentuale
di saturazione e poi rinormalizzerebbero al 100% quando e' il momento di
passare i brani compressi su CD Audio.... insomma la cosa, mi sa, non fa che
prendere per il cxlx l'encoder che quindi utilizza piu' bits ed in cambio ti
da un MP3 migliore: ma se e' vero che i bits in piu' danno maggiore
qualita', e' pur vero che esistono metodi meno artificiosi per far lavorare
un po' piu' duramente un encoder :-))   ).
Invece vorrei tornare ancora una volta al motivo primario per cui sconsiglio
di normalizzare i brani:
Se vai in cerca di una canzone perche' vuoi copilarti un CD come CDDB
comanda e trovi 10 canzoni encodate come Dio comanda e che rispecchiano il
wav d'origine, non vedo perche' qualcuno debba manomettere l'11esima e
sfalsare tutto il tuo lavoro di ricerca etc etc etc.
Credo invece che sia meglio perdere piu' tempo ad estrarre la traccia in
secure mode ed ad encodare il wav con un encoder valido piuttosto che
giocare a normalizzare i wav.
Normalizzate solo per le vostre compilation fai da te, al momento di passare
i frutti delle vostre ricerche su CD Audio e fatelo ricorrendo a strumenti
adatti (pare che la normalizzazione RMS di sound forge faccia ricorso al
limiting, questo sebbene io mi trovi a meraviglia con l'hard limiting di
cool pro). Ricordate invece che normalizzare per picchi serve a poco.
Tutto questo a mio modestissimo avviso :-))
w

sarebbe doveroso,
e` doveroso con gli encoders freeware o shareware.
Gli encoders destinati ad un utilizzo pro se ne fregano che la traccia sia
normalizzata o meno. E la differenza l'orecchio la sente.
AB
--------------------------------
Inviato via 
http://usenet.iol.it
 

 Ricordate invece che normalizzare per picchi serve a poco.
C'e' un caso particolare dove e' consigliabile non usare i vari programmi 
di editing (CoolEdit, SoundForge, ecc.), o la normalizzazione dei ripper 
come Eac, ecc., ed e' quando si parla di clipping.
Quando rippando un brano ci viene riportato un peak level del 100% ed 
anche analizzando successivamente il wav ottenuto non viene rivelata la 
presenza di clipping, una volta che il wav sara' processato da un encoder 
lossy quasi sicuramente ci ritroveremo con un bel po' di campioni 
"clippati", proprio perche' gli encoder incrementano leggermente il peak 
level.
Questo lo si puo' vedere anche usando Winamp utilizzando come decoder mp3 
il plugin MAD (che uso sempre, sia per il dither che per le info sul 
clipping e opzioni per "Attenuazione"); quando l'mp3 e' in riproduzione, 
digitare Alt+3 e spostarsi in "Statistics": in caso di clipping vedremo 
la voce "Clipped Samples" piu' o meno numericamente "agitata" 
(naturalmente in questo caso non va fatto click su "Attenuate").
L'ultima versione di Mad ha un bug che causa la comparsa in fase di 
decodifica di un numero maggiore di Clipped samples (questo e' causato 
dal dither, ma ci stanno gia' lavorando e la prossima versione dovrebbe 
essere a posto).
Per questo discorso di non completa affidabilita' e visto che queste info 
fornite dal decoder MAD valgono solo per mp3 (essendo un decoder mp3), 
utilizzo con Winamp un plugin (un DSP) che si chiama "Spectrum Tool": 
http://divamm.virtualave.net/spectool/
lo consiglio a tutti (la sua rappresentazione dello spettro e' ampiamente 
modificabile) e io lo uso spesso per rilevare l'eventuale clipping su mpc 
scaricati, anche se per quelli che encodano con mpc ci sono meno rischi 
di farsi fregare in tal senso (leggi sotto).
Dunque, qual'e' la maniera piu' appropriata per evitare il clipping in 
song che hanno un peak level attorno al 100% e che devono essere 
codificate con encoder lossy? La soluzione migliore e' usare 
l'impostazione --scale (che non e' proprio normalizzazione, visto che 
questa richiede un processo in due fasi) di alcuni encoder lossy (
--scale nel caso di Lame, -scale nel caso di MPC), sia perche' in questo 
caso fanno un lavoro piu' preciso dei programmi di audio editing, sia 
perche' si lascia inalterato il wav originale fino alla fase della 
codifica vera e propria.
Parlando di Lame, di solito un --scale di 0.97 e' l'ideale, ma non e' da 
prendere come valore per tutte "le stagioni". A questa pagina si sono 
fatte alcune verifiche con --scale di Lame e riscontri con il Mad plugin:
http://home.wanadoo.nl/~w.speek/scale.htm
Una nota su MPC e sul fatto di come anche in questo caso si differenzi 
(in meglio) da tutti gli altri: se dopo la codifica di un brano originale 
in un file mpc quest'ultimo presentasse porzioni "clippate", il simpatico 
encoder MPC avvertirebbe immediatamente con:
WARNING: There occured 8 internal clippings!
Re-encode with "-scale 0.985" or normalize input file to 98.5%
Ricordo inoltre che anche l'MPC plugin dispone di una feature come 
l'"Attenuate" del plugin MAD, che nel suo caso si chiama "Clipping 
Prevention" (da non abilitare nell'uso comune).
Ultima nota: se un file lossy ha del clipping non c'e' niente da fare, 
bisogna re-encodare dall'originale (con l'appropriato valore di
--scale), intervenire direttamente sul file lossy non aiutera' a 
sbarazzarsi del clip, oppure si puo' lasciare quel file cosi' com'e' e 
usare la funzione di attenuazione (nel caso che il clip causi fastidio 
nell'ascolto tipico) presente in alcuni decoder (di cui ho parlato 
sopra).
Questi i link a pagine (postati gia' piu' volte) che affrontano in modo 
piuttosto esaustivo i discorsi su MAD, dither, clipping, ecc.:
http://fastforward.iwarp.com/mad.html
http://fastforward.iwarp.com/madchallenge.html
http://privatewww.essex.ac.uk/~djmrob/mp3decoders/24bit.html
http://privatewww.essex.ac.uk/~djmrob/mp3decoders/24bit2.html
http://fastforward.iwarp.com/dither.html
http://fastforward.iwarp.com/clipping.html
http://fastforward.iwarp.com/norm.html
Cia', mumble

Cia', mumble
Ciao, [proxima]


Il buon mumble ha gia' risposto alla domanda. La sua nota sul clipping era
appunto una risposta ad una domanda/dubbio di questo tipo, anticipandola.
Nella sua nota, ff123 non fa che affermare che se non occorrono clipping i
due file (l'originale normalizzato e quello compresso originato dal wav
normalizzato) sono del tutto simili o addirittura indistinguibili
all'ascolto, e che e' dunque il nocciolo su cui fondare i test d'ascolto per
i files normalizzati. Il problema e' dunque tutto da imputare a problemi di
clipping. La domanda di crux invece verteva sulla necessita' di normalizzare
i wav prima della fase di encoding per aumentare la qualita' del file
compresso. Qua torniamo al discorso gia' fatto. Tanto vale tenersi il file
come da originale ed usare un buon VBR magari con specifiche ad hoc per
migliorane la qualita'. Agli esperti commenti, precisazioni e/o smentite e
sopratutto pareri personali. :-))
w

 Vorrei inoltre, se possibile che tu rispondessi alla domanda di Crux,
Non l'ho fatto perche' il discorso Normalizzazione (piu' complesso dello 
scale e clipping) non e' il mio forte, sicuramente Walter, AB o altri 
sono piu' indicati.
Ritengo che ff123 abbia ragione, ma anche Crux, infatti va tenuto conto 
del tipo di normalizzazione applicata (se non ricordo male ff123 ha 
parlato di peak) e del modello di riferimento di un dato codec (non so 
che approccio segui in questo senso il GPSYCHO di Lame, dunque i 
risultati potrebbero cambiare da codec a codec).
Per il resto non ho mai fatto prove in tal senso, anche perche' non 
normalizzo mai (uso solo lo --scale per evitare il clipping).
Cia', mumble