16 o 24 bit?
@ Animapone
OT.
Ho ascoltato anche "Blue Sky"....
....COMPLIMENTI
Grazie losfogos ha scritto:
Questa è la registrazione, usai un MKS20, un vecchio Clavinova, e un D550. Comunque una roba velocissima, premixata in un un'oretta e così è rimasta, senza automazioni maniacali, e senza compressori, tutto bagnato da un rev Lexicon PCM70...altro che plug-in....
Questa è la registrazione, usai un MKS20, un vecchio Clavinova, e un D550. Comunque una roba velocissima, premixata in un un'oretta e così è rimasta, senza automazioni maniacali, e senza compressori, tutto bagnato da un rev Lexicon PCM70...altro che plug-in....
OT.
Ho ascoltato anche "Blue Sky"....
....COMPLIMENTI
Un OT, non era un mio pezzo ma fui chiamato oltre che per registrare e mixare anche per fare il tastierista.
Comunque ho postato la demo per dimostrare che anche a 16 bit si poteva avere un bel suono. Gli Adat a 16 bit secondo me suonavano un pò meglio delle odierne schede audio diciamo "commerciali". Non per una questione di supporto come detto da Mima 85, magari per i convertitori migliori, non so.
losfogos ha scritto:
Non per una questione di supporto come detto da Mima 85, magari per i convertitori migliori, non so.
Non per una questione di supporto come detto da Mima 85, magari per i convertitori migliori, non so.
Ma il succo del mio discorso è proprio quello che hai detto tu, a fare la differenza è il convertitore
Edited 21 Apr. 2011 23:40
anonimo 22-04-11 13.11
@ carmol
Azz uno perde 10 preziosi minuti della sua vita a dare una
risposta, e il risultato è che "la risposta non è ancora venuta fuori" ?
Pensavo di essere stato chiaro ...
Vabeh perdo altri 10 minuti, gli ultimi però:
la compressione digitale implica perdita di qualità,
cioè perdita di dinamica e di informazione.
su questo ci siamo ? ok, andiamo avanti.
per miscelare 2 tracce da 16 bit senza compressione digitale,
occorrono 17 bit. Se uso un progetto a 16 bit le due tracce,
se normalizzate, subiranno una compressione in 15 bit.
E' chiaro questo ?
Mi si dirà "ok, comunque alla fine però ci sarà una compressione
digitale per portare il progetto da 24 bit a 16".
E' vero, ma, come dicevo prima, la compressione digitale
sulla somma delle tracce comporta meno perdite rispetto alla compressione
delle singole tracce prima del mix.
Devo dimostrarlo ? Però ci vuole un pò di matematica.
Se mi seguite ok, altrimenti fidatevi.
Supponiamo di dover mixare due tracce;
nel digitale, mixare significa sommare numeri interi.
Per non perdere troppe nuances degli strumenti, utilizzo
due tracce a 16 bit, e faccio in modo che siano normalizzate.
In 16 bit, le mie tracce avranno valori che vanno
da -32767 a +32768. Anche la traccia mix, essendo a 16 bit, non potrà avere valori
al di fuori di questo intervallo
Supponiamo che, caso tutt'altro che bislacco,
ad un certo istante entrambe le tracce fanno una ampia escursione
e raggiungono il massimo e il minimo, cioè -32767 e 32768;
la somma è -32767+ (-32767)= -65534 e 32768+32768=+65536,
per rappresentare questi valori 16 bit non mi basterebbero, avrei
bisogno di 17 bit. Ma non sono stato ad ascoltare CARMOL,
per cui ho usato un progetto a 16 bit, ed ora il software,
per far rientrare i valori in quelli consentiti COMPRIME digitalmente le due tracce.
Compressione digitale significa DIVISIONE,
in questo caso per far rientrare 65536 in 32768 devo dividere per 2.
Ciascuna traccia, per mantenere le proporzioni, verrà scalata,
cioè divisa interamente per due.
Rappresento il caso peggiore:
in un certo istante le due tracce originarie assumono valore 1.
diviso per 2, 1/2=0.5; si possono rappresentare solo valori interi,
quindi il valore verrà arrotondato a 0.
la somma delle due tracce viene 0+0 = ZERO.
Perdo COMPLETAMENTE quella informazione.
Se avessi ascoltato CARMOL, utilizzando un progetto a 24 bit, 17 bit rientrano
tranquillamente in 24, non ci sarebbe stata
compressione a monte, per cui le due tracce mixate in quel punto mi avrebbero
dato 1+1= 2; comprimendo successivamente a VALLE, cioè comprimendo la traccia
da 24 bit per farla entrare nei 16 canonici dei cd,
sarebbe venuto 2/2=1 <--- risultato ESATTO, nessuna perdita di informazione.
Spero di essere stato chiaro...
scusa,ma a mio avviso questa è teoria rasenta l'emisfero della sega mentale pura....ed inoltre bisognerebbe spiegarala tenendo presente la risposta dei motori audio dei vari software, dove al momento nelle ultime versioni non ESISTE compressione di nessun tipo nei dati audio. Se vai a sommare 2 tracce a 16bit in ITB non si comprime assolutamente nulla.
Q4bert ha scritto:
Beh... che 24 sia meglio di 16 non è in sè una grande scoperta. Così che 32 sia ancora meglio e così via. Il punto sarebbe capire il perchè e non credo che la risposta sia ancora venuta fuori. Secondo me la differenza sta sulla frequenza di campionamento (i famosi 44, 48, 96.... kHz) più che sui bit.
Beh... che 24 sia meglio di 16 non è in sè una grande scoperta. Così che 32 sia ancora meglio e così via. Il punto sarebbe capire il perchè e non credo che la risposta sia ancora venuta fuori. Secondo me la differenza sta sulla frequenza di campionamento (i famosi 44, 48, 96.... kHz) più che sui bit.
Azz uno perde 10 preziosi minuti della sua vita a dare una
risposta, e il risultato è che "la risposta non è ancora venuta fuori" ?
Pensavo di essere stato chiaro ...
Vabeh perdo altri 10 minuti, gli ultimi però:
la compressione digitale implica perdita di qualità,
cioè perdita di dinamica e di informazione.
su questo ci siamo ? ok, andiamo avanti.
per miscelare 2 tracce da 16 bit senza compressione digitale,
occorrono 17 bit. Se uso un progetto a 16 bit le due tracce,
se normalizzate, subiranno una compressione in 15 bit.
E' chiaro questo ?
Mi si dirà "ok, comunque alla fine però ci sarà una compressione
digitale per portare il progetto da 24 bit a 16".
E' vero, ma, come dicevo prima, la compressione digitale
sulla somma delle tracce comporta meno perdite rispetto alla compressione
delle singole tracce prima del mix.
Devo dimostrarlo ? Però ci vuole un pò di matematica.
Se mi seguite ok, altrimenti fidatevi.
Supponiamo di dover mixare due tracce;
nel digitale, mixare significa sommare numeri interi.
Per non perdere troppe nuances degli strumenti, utilizzo
due tracce a 16 bit, e faccio in modo che siano normalizzate.
In 16 bit, le mie tracce avranno valori che vanno
da -32767 a +32768. Anche la traccia mix, essendo a 16 bit, non potrà avere valori
al di fuori di questo intervallo
Supponiamo che, caso tutt'altro che bislacco,
ad un certo istante entrambe le tracce fanno una ampia escursione
e raggiungono il massimo e il minimo, cioè -32767 e 32768;
la somma è -32767+ (-32767)= -65534 e 32768+32768=+65536,
per rappresentare questi valori 16 bit non mi basterebbero, avrei
bisogno di 17 bit. Ma non sono stato ad ascoltare CARMOL,
per cui ho usato un progetto a 16 bit, ed ora il software,
per far rientrare i valori in quelli consentiti COMPRIME digitalmente le due tracce.
Compressione digitale significa DIVISIONE,
in questo caso per far rientrare 65536 in 32768 devo dividere per 2.
Ciascuna traccia, per mantenere le proporzioni, verrà scalata,
cioè divisa interamente per due.
Rappresento il caso peggiore:
in un certo istante le due tracce originarie assumono valore 1.
diviso per 2, 1/2=0.5; si possono rappresentare solo valori interi,
quindi il valore verrà arrotondato a 0.
la somma delle due tracce viene 0+0 = ZERO.
Perdo COMPLETAMENTE quella informazione.
Se avessi ascoltato CARMOL, utilizzando un progetto a 24 bit, 17 bit rientrano
tranquillamente in 24, non ci sarebbe stata
compressione a monte, per cui le due tracce mixate in quel punto mi avrebbero
dato 1+1= 2; comprimendo successivamente a VALLE, cioè comprimendo la traccia
da 24 bit per farla entrare nei 16 canonici dei cd,
sarebbe venuto 2/2=1 <--- risultato ESATTO, nessuna perdita di informazione.
Spero di essere stato chiaro...
Edited 21 Apr. 2011 12:04
In applicazioni normali (non da produzione di un disco professionale) è preferibile restare a 16bit 44,1Khz perchè l'unica vera perdita di dati e di segnale che hai sarà solo e solamente durante il downsampling dove i vari motori audio possono fallire.
In applicazioni di Pre-produzione o orchestrazione virtuale ad esempio si predilige il sample rate 24bit 44,1Khz dove appunto il range consente ad ogni tipologia di strumento virtuale o PLG di esprimersi al meglio per poi non passare affatto peril downsampling e approdare su sistemi di registrazione professionali dove tutta la produzione sarà adeguatamente trattata con hardware apposito e via discorrendo.
In applicazioni di Tracking professionale dedicato al video o all'udio PRO dove gli strumenti hardware lo permettono e dove poi già si sà a monte che il lavoro formato da una miriade di take ecc ecc.... sarà finito e finalizzato in strutture dove il segnale sarà trattato in una certa maniera, li si che ci si può permettere di arrivare a 24/32bit fino a 192Khz. In tutte le altre applicazioni è solo spazio sprecato.
Edited 22 Apr. 2011 11:15
anonimo 22-04-11 13.12
@ giomusic
io per registrare con la mia scheda audio una M-Audio ProFire 610 ho impostato a 24 bit e 192 Khz è troppo? oppure devo diminuire i Khz a 96?
non è troppo, è inutile.... io per registrare con la mia scheda audio una M-Audio ProFire 610 ho impostato a 24 bit e 192 Khz è troppo? oppure devo diminuire i Khz a 96?
Edited 22 Apr. 2011 11:21
anonimo 22-04-11 13.21
@ carmol
Non ricordo benissimo cubase,
il discorso che ho fatto vale in generale,
ma mi pare che sia proprio quello il modo
Si lo puoi fare traquillmante e puoi farlo in due modi :
mr_verb ha scritto:
Non posso, da un progetto a 24 bit, esportare il tutto in 16 bit direttamente da Cubase (Esporta->Missaggio audio)?
Non posso, da un progetto a 24 bit, esportare il tutto in 16 bit direttamente da Cubase (Esporta->Missaggio audio)?
Non ricordo benissimo cubase,
il discorso che ho fatto vale in generale,
ma mi pare che sia proprio quello il modo
1) Facendo il Mix di tutto il materiale
2) Esportando traccia per traccia
in entrambi i casi devi fare un downsampling del samplerate quindi devi inserire sul bus Master un plug-in
apposito che ti aiuta nel processo di Dithenring. In base alla versione di cubase che hai ce ne sono di vari tipi basta inserirlo nell'insert 7 o 8 del bus master.
@ mima85
Ma il succo del mio discorso è proprio quello che hai detto tu, a fare la differenza è il convertitore
Certo, ma anche l'acquisizione delle tracce. Se riesco metto un altro esempio di registrazione a 16 bit con i Tascam DA88 e un banco Soundtracs. Un suono da paura....
losfogos ha scritto:
Non per una questione di supporto come detto da Mima 85, magari per i convertitori migliori, non so.
Non per una questione di supporto come detto da Mima 85, magari per i convertitori migliori, non so.
Ma il succo del mio discorso è proprio quello che hai detto tu, a fare la differenza è il convertitore
Edited 21 Apr. 2011 23:40
anonimo 22-04-11 13.38
ecco spiegate le cose in diue parole.
le teorie contano poco, il risultato finale è quello che conta.
le teorie contano poco, il risultato finale è quello che conta.
carmol 22-04-11 15.12
Erresound ha scritto:
scusa,ma a mio avviso questa è teoria rasenta l'emisfero della sega mentale pura....ed inoltre bisognerebbe spiegarala tenendo presente la risposta dei motori audio dei vari software, dove al momento nelle ultime versioni non ESISTE compressione di nessun tipo nei dati audio. Se vai a sommare 2 tracce a 16bit in ITB non si comprime assolutamente nulla.
scusa,ma a mio avviso questa è teoria rasenta l'emisfero della sega mentale pura....ed inoltre bisognerebbe spiegarala tenendo presente la risposta dei motori audio dei vari software, dove al momento nelle ultime versioni non ESISTE compressione di nessun tipo nei dati audio. Se vai a sommare 2 tracce a 16bit in ITB non si comprime assolutamente nulla.
Mi spieghi come viene trattato il caso pratico che ho esposto da questi motori?
E' vero, ma, come dicevo prima, la compressione digitale
sulla somma delle tracce comporta meno perdite rispetto alla compressione
delle singole tracce prima del mix.
Devo dimostrarlo ? Però ci vuole un pò di matematica.
sulla somma delle tracce comporta meno perdite rispetto alla compressione
delle singole tracce prima del mix.
Devo dimostrarlo ? Però ci vuole un pò di matematica.
Questo, scusami, è matematicamente sbagliato.
A questo punto mi interessa la dimostrazione matematica.
carmol 22-04-11 17.40
thermidor ha scritto:
Questo, scusami, è matematicamente sbagliato.
A questo punto mi interessa la dimostrazione matematica.
Questo, scusami, è matematicamente sbagliato.
A questo punto mi interessa la dimostrazione matematica.
Pffffff ma l'hai letto tutto il post !?!?
carmol 22-04-11 17.52
thermidor ha scritto:
Quasi tutto ma ripeto, senza polemica, che matematicamente non è corretta questa affermazione.
Quasi tutto ma ripeto, senza polemica, che matematicamente non è corretta questa affermazione.
E leggilo tutto che ho proprio dimostrato questo.
Ripeto non voglio fare polemiche, ma se io ho: A+B=C
ora divido C per 2 (C/2), è o non è come dire che:
C/2=A/2+B/2 oppue (A+B)/2 ?
Forse non ho capito io il senso del tuo discorso.
ora divido C per 2 (C/2), è o non è come dire che:
C/2=A/2+B/2 oppue (A+B)/2 ?
Forse non ho capito io il senso del tuo discorso.
Considera di prendere solo l'intero e capirai perchè la somma di due divisioni è "più sbagliata" della divisione di due somme
@ thermidor
Ripeto non voglio fare polemiche, ma se io ho: A+B=C
ora divido C per 2 (C/2), è o non è come dire che:
C/2=A/2+B/2 oppue (A+B)/2 ?
Forse non ho capito io il senso del tuo discorso.
Ti sei perso il problema "dell'arrotondamento all'intero"
Ripeto non voglio fare polemiche, ma se io ho: A+B=C
ora divido C per 2 (C/2), è o non è come dire che:
C/2=A/2+B/2 oppue (A+B)/2 ?
Forse non ho capito io il senso del tuo discorso.
Non so se il discorso di carmol sia "vero" ma è sicuramente "logico".
Esempio:
A = 5
B = 7
ipotesi carmol
5+7 = 12 | 12/2 = 6 (carmol)
ipotesi thermidor
5/2 = 2,5 (ma prendo solo l'intero, quindi 2)
7/2 = 3,5 (ma prendo solo l'intero, quindi 3)
totale 5
5 è "diverso" da 6
carmol 22-04-11 18.11
stiamo parlando di compressione digitale,
c'è l'arrotondamento al numero intero più vicino,
ad esempio 0.4 diventa 0 e 0.6 diventa 1.
Se indichiamo con [] l'arrotondamento,
[(a+b)/n] è più vicino a (a+b)/n rispetto
a [a/n]+[b/n]
Non è una "mia" ipotesi, è dimostrato!
c'è l'arrotondamento al numero intero più vicino,
ad esempio 0.4 diventa 0 e 0.6 diventa 1.
Se indichiamo con [] l'arrotondamento,
[(a+b)/n] è più vicino a (a+b)/n rispetto
a [a/n]+[b/n]
Non è una "mia" ipotesi, è dimostrato!
Edited 22 Apr. 2011 16:14
Anche su questo ci sarebbe da ridire, perchè i calcoli non vengono fatti sull' intero ma in floating-point, e poi comunque interverrebbe su 1bit, e nella distribuzione temporale del segnale avresti comunque la media.
Riprendiamo l' esempio:
o,4 diventa 0
0,6 diventa 1
n supponiamo sia 2
allora 0+1 = 1
1/n = 1/2= 0,5
adesso coi valori reali:
0,4+0,6=1
1/n = 1/2 = 0,5
o,4 diventa 0
0,6 diventa 1
n supponiamo sia 2
allora 0+1 = 1
1/n = 1/2= 0,5
adesso coi valori reali:
0,4+0,6=1
1/n = 1/2 = 0,5
carmol 22-04-11 18.31
thermidor ha scritto:
Anche su questo ci sarebbe da ridire, perchè i calcoli non vengono fatti sull' intero ma in floating-point
Anche su questo ci sarebbe da ridire, perchè i calcoli non vengono fatti sull' intero ma in floating-point
la divisione a/n viene fatta in floating point ma il risultato
viene memorizzato in bit quindi viene applicato l'arrotondamento
thermidor ha scritto:
e poi comunque interverrebbe su 1bit, e nella distribuzione temporale del segnale avresti comunque la media.
e poi comunque interverrebbe su 1bit, e nella distribuzione temporale del segnale avresti comunque la media.
Non capisco cosa intendi;
Comunque, sull'intero segnale,
l'arrotondamento sul totale diviso comporta
meno errore della somma dei segnali divisi arrotondati.
Anche se l'errore massimo è comunque di 1 bit,
considerando più tracce tale errore si accumula e può diventare significativo.
Edited 22 Apr. 2011 16:46