Marco qual é il buffer giusto per un resample a 384 ?
384000* 8 *10 /1024
30000:30000 ???
o
2048:30000?
PS: come si fa a sostituire sox in windows?
Marco qual é il buffer giusto per un resample a 384 ?
384000* 8 *10 /1024
30000:30000 ???
o
2048:30000?
PS: come si fa a sostituire sox in windows?
Ultima modifica di antonellocaroli : 22-04-2016 a 06:19
Mi auto-quoto, perché qui:
ci vuole una precisazione. In effetti il risultato potrebbe/dovrebbe essere identico (a quello ottenibile con l'opzione "-p 24" di "dither") da un punto di vista numerico (cioè, del valore dei campioni che arrivano al DAC), ma di certo non lo è sotto altri punti di vista.
Infatti, con la mia attuale configurazione LMS trasferisce verso squeezelite uno stream a 32bit (di cui solo 24 contengono effettivamente dati significativi, i restanti 8 verosimilmente sono a zero), mentre nell'altro caso viene trasferito uno stream a 24bit. Va da sé che quindi cambia il traffico sulla rete e numerosi altri piccoli dettagli (uso di memoria, buffer, CPU, IRQ, ecc). In linea di principio la cosa dovrebbe essere irrilevante ma, a voler dar credito agli (ex-) "cmp-quadristi" (ed oggi "piramidisti"), potrebbe anche avere delle subdole conseguenze indirette.
Quindi non è detto che le due configurazioni "equivalenti" siano effettivamente tali anche all'ascolto.
quelli in realtà li fa LMS (ed il relativo pacchetto), installando le sue copie di sox, ecc...(cosa che viola gli standard e non dovrebbe fare).
sì, ovviamente. Stesso problema con il file dell'init script (modifica per "nice"). Al momento era solo una prova veloce, ma c'è modo di rimediare... utilizzando il meccanismo delle "diversion" (vedi anche "man dpkg-divert", nonché qui).
se non sono specificati diversamente, squeezelite non si calcola automaticamente il buffer in funzione del s/r?
Quale dovrebbero essere i valori più appropriati per 384K?
non ho ancora aggiornato i pacchetti, ma ovviamente prevedevo di farlo non appena lo farò.
confermo la maggiore "pulizia"; mi sembra invece strano che tu percepisca (forse) meno dettaglio. In teoria, a 24bit il dithering dovrebbe essere irrilevante (vedi sotto) o, al più, dovrebbe essere vero esattamente il contrario: una maggiore / migliore percezione dei dettagli. Che poi in effetti è quello che credo di aver percepito io nel mio sistema, unitamente ad un miglioramento anche in termini di "ariosità", "immagine", ed altro ancora... ci sono stati dei (piccoli) miglioramenti praticamente su tutti i parametri.
Wikipedia: Dither (versione in italiano).
Gli esempi visivi (applicati alla fotografia digitale, che ha comunque problematiche analoghe a quelle dell'audio digitale) sono impressionanti. Guardate questa foto (con una "bit-depth" volutamente ridotta per evidenziare il problema) "prima" (senza dithering):
...e la stessa foto "dopo" l'applicazione del dithering:
è più che evidente come, anche e soprattutto da un punto di vista squisitamente percettivo, il dithering migliori le cose in modo enorme. Anche per l'audio è la stessa cosa...
idem per i DAC, che hanno un DR (reale/effettivo) che, in pratica, anche nei casi migliori raramente supera i 100dB o poco più (ad es. l'AK4490 dichiara un DR di 120dB, che però in effetti si riduce già a causa della sua THD+N dichiarata di -112dB; le implementazioni pratiche poi raramente raggiungono quei livelli ottimali). Ulteriori riduzioni della "risoluzione" / range dinamico effettivi si hanno inoltre a causa del resto della catena di riproduzione...24-bit audio does not require dithering, as the noise level of the digital converter is always louder than the required level of any dither that might be applied. 24-bit audio could theoretically encode 144 dB of dynamic range, but based on manufacturer's datasheets no ADCs exist that can provide higher than ~125 dB.
e questo IMHO è probabilmente il punto cruciale.Dither can also be used to increase the effective dynamic range. The perceived dynamic range of 16-bit audio can be 120 dB or more with noise-shaped dither, taking advantage of the frequency response of the human ear.
Pensa al DSD: con una "bit-depth" pari ad un solo bit, proprio (e solo) grazie all'oversampling, al dithering ed al noise-shaping riesce a garantire "risoluzioni" e dinamiche effettive superiori a quelle del PCM 16/44.1 (CD).
Con l'upsampling del PCM (specie se lo uniamo a dithering e noise-shaping, che poi è quello che fa ad es. HQPlayer) facciamo sostanzialmente la stessa cosa: guadagniamo cioè "risoluzione" e dinamica "in banda" (laddove conta di più) spostando il rumore (di quantizzazione) verso frequenze sempre più alte (poco o per nulla udibili e/o eliminate dai filtri analogici a valle del DAC).
Riferimenti:
Audacity Manual: Digital Audio Fundamentals
Audacity Wiki: Bit Depth
Wikipedia: Dynamic range
Wikipedia: Audio bit depth
+1 :-)
immagino banalmente cancellando/rinominando il file eseguibile installato da LMS e copiando al suo posto quello della versione aggiornata...
Ultima modifica di UnixMan : 22-04-2016 a 12:59
Ciao, Paolo.
«Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»
Ciao, Paolo.
«Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»
'giusto' è relativo.
Squeezelite per default utilizza:
1024*2 : 44100 *8* 10/1024 quindi :
2048: 3445
Nel caso di resample -sempre per default - , moltiplica la dimensione dell'OUTPUT per il fattore di resample, al massimo 8 e minimo 1 (non diminuisce il buffer nel caso di downsample), quindi:
2048: 27563
A mio avviso però è bene aggiungere qualche considerazione:
44100/16 -> frame 4 Bytes -> 176,4 KB/sec
384000/32 -> frame 8 Bytes -> 3072 KB/sec
da cui
2048 bit in ingresso = 11.7 sec.
27563 bit in uscita = 8.96 sec.
sono asimmetrici, il che non mi piace (non che si senta, però) e correggerei a 2048 : 35869, così da avere la stessa 'durata' dei due buffer, anche se il collo di bottiglia non è certo il buffer di output (da cui preleva ALSA per alimentare il suo buffer, che è nell'ordine dei millisecondi).
Che il buffer di output rischi l'underrun indipendentemente da quello di input mi pare un'ipotesi inverosimile, pertanto se proprio di deve 'risparmiare' sui buffer, farei come fa squeezelite, cioè ridurrei la durata di quello di output senza abbassare quello di input, che è quello FONDAMENTALE per evitare i drop outs dovuti alla rete, cercando di mantenere un rapporto sensato tra i due (ma è una fisima).
Io approccio così:
Che durata di buffer in ingresso voglio? Poniamo 10 sec.
10*176,4 : 10 * 3072 -> 1764 : 30072
Sono valori certamente NON preoccupanti per nessun hw e 10 secondi dovrebbero certamente essere sufficienti a coprire ogni problema di rete in situazioni prive di gravi difetti o guasti, arrotondare a 2048 : 30720 (o 28672) è un'altra cosa che farei, ma sempre come fisima informatica.
quindi, per rispondere alla tua domanda, ev. 2048:30000, ricevendo PCM 44100/16 ed uscendo in PCM 384/32.
Considera però che entrando FLAC, in realtà, la durata del buffer in ingresso è maggiore in ragione del rapporto di compressione, ma a questi valori non me ne preoccuperei.
Fino a qui si fa lavorare squeezelite per come è stato pensato, cioè con buffer applicativi nell'ordine dei 10s che alimentano il DAC via un buffer di sistema nell'ordine dei ms, poniamo 10 o 100, con period count 2, per semplicità.
se 10, la CPU viene interrotta ogni 5 ms (200 volte in un secondo) per spostare dal buffer di output a quello di alsa 30 Kb.
se 100, ogni 50ms (20 volte al secondo) per spostare 300 Kb.
con un buffer di output di 30072 Kb, ponendo che la soglia di attivazione sia stata posta al 50%, in entrambi i casi lo spostamento (e la transcodifica) tra in ed out si attiverà ogni 5 sec, quindi il processo di transcodifica (SOX) sarà normalmente inattivo per t < 5 sec ed attivo con picchi ogni 5 secondi, lo stesso profilo - più o meno - terrà anche l'utilizzo della rete, dato che di certo non servono 5 secondi per trasportare un Mb in nessuna rete IP.
E' difficile pensare che possano verificarsi XRUN in queste condizioni, di certo NON tra il buffer OUT ed ALSA ed avremo il 'classico' profilo con bassissima attività.
Abassando molto i buffer applicativi e portandoli nell'ordine di grandezza dei 100 ms, è ovvio che il rischio di XRUN aumenta, dato che l'attivazione del processo di trascodifica avverrebbe ogni 50 ms, quindi sincrono o quasi al processo di output. Già di per se questa è una situazione critica, qualsiasi minimo ritardo nel processo di transcodfica si traduce probabilmente in xrun del buffer di output, che di suo richiede ogni 50ms di essere riempito al buffer di imput, che ogni 50 ms richiederà alla rete di ricevere circa 3 Kb (in formato 'nativo').
Molto dipende da hw e - soprattuto - rete, ma se in reti non efficientissime come la mia l'effetto è immediato: drop outs, quello che avviene quando la rete 'regge il ritmo' è più subdolo, tutto il sistema rincorrerà il processo di output, cercando di prevenire e risolvere gli XRUN, non potendo utilizzare i buffer in modo efficiente.
Dipendentemente da come sono scritti i diversi applicativi, si utilizzeranno buffer intermedi (es. quando FLAC decodifica x bytes, produce y frames, che passa sox, che ne fa l'upsampling e produce il risultato. Tutte queste operazioni avvengano - di necesità - utilizando dei buffer applicativi intermedi, altrimenti si avrebbe perdita di dati, se il buffer di output è più piccolo della minima quantità di dati prodota da SOX, allora necessariamente SOX alimenterà il suo buffer e rimarrà in attessa, prima di iniziare la conversione di un nuovo chunk di dati, che il suo buffer venga svuotato e così a catena) alla 'rincorsa' del sincronismo.
Tutto questo provoca continue gestioni di errori di XRUN, che costituiscono se va bene overhead, oppure la 'correzione di errore' senza chiedere la ritrasmissione (che provocherebbe la ripetizione di un ciclo e quindi - in queste condizioni - il dropouts), come succede nei sistemi real time dedicati all'audio a bassissima latenza (acquisizione), non so se ALSA lo preveda o meno.
Al contrario, usando buffers molto grandi si avrà un lavoro iniziale elevato, ma ottimizzato per tutti gli anelli della catena, con il classico profilo di carico iniziale elevato e quindi scarico completo fino a poco prima dell'inizio della nuova traccia.
Sono tre filosofie diverse, in merito ai risultati sonori è indubbio - a mio avviso - che la prima condizione suoni più brillante ed aggressiva, mentre l'ultima sia la più smooth. Ovviamente per alcuni la prima è 'faticosa' e la terza 'attufata', ognuno decida per se, di certo la prima è ARTIFICIALMENTE prodotta per tutta la durata del brano, mentre la terza può - in teoria - risentire del carico nei primi secondi di riproduzione, ma da li in poi è certamente quanto di più incontaminato si possa produrre da un PC.
La seconda è un compromesso tra le due, a mio avviso accettabilissimo, specie non facendo fare nessuna transcode a squeezelite.
P.s.
Per sostituire SOX in windows basta rinominare (o cancellare) la versione in <server folder>/Bin/Ms.../ (vedi in info) e sostituirla con quella che vuoi, Se fai gli aggiornamenti usando la funzionalità di LMS, non dovrebbe sostituirtela, ma bisogna verificare. Io eseguo da codice in Win e sarei costretto a ripetere l'operazione ogni volta, a meno di configurazioni manuali.
A mio avviso l'opzione più semplice (ovunque) è di rinominare la nuova versione come sox2 (o pippo) ed inserire [sox2] in convert.conf ed altrove al posto di [sox], questo è fattibilissimo anche in C-3PO, è quello che ho fatto per ffmpeg. se pensate che serva e sia fattibile ovunque in questo modo posso programmarlo, ma mi pareva che Paolo non fosse daccordo per Linux.
Ovviamente si può inserire anche sox3 con la conversione a dsd allo stesso modo, che è quello che ha fatto Daphile.
Fatemi sapere.
Ciao, Marco.
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
— E. F. Schumacher (mis-attributed to A. Einstein)
________________________________________________________________________________
Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE
Per il buffer in relazione al s/r e cosa fa squeezelite ho gia risposto sopra, credo. Per il nice, aspetto la modifica.Mi auto-quoto, perché qui:
ci vuole una precisazione. In effetti il risultato potrebbe/dovrebbe essere identico (a quello ottenibile con l'opzione "-p 24" di "dither") da un punto di vista numerico (cioè, del valore dei campioni che arrivano al DAC), ma di certo non lo è sotto altri punti di vista.
Infatti, con la mia attuale configurazione LMS trasferisce verso squeezelite uno stream a 32bit (di cui solo 24 contengono effettivamente dati significativi, i restanti 8 verosimilmente sono a zero), mentre nell'altro caso viene trasferito uno stream a 24bit. Va da sé che quindi cambia il traffico sulla rete e numerosi altri piccoli dettagli (uso di memoria, buffer, CPU, IRQ, ecc). In linea di principio la cosa dovrebbe essere irrilevante ma, a voler dar credito agli (ex-) "cmp-quadristi" (ed oggi "piramidisti"), potrebbe anche avere delle subdole conseguenze indirette.
Quindi non è detto che le due configurazioni "equivalenti" siano effettivamente tali anche all'ascolto.
quelli in realtà li fa LMS (ed il relativo pacchetto), installando le sue copie di sox, ecc...
sì, ovviamente. Stesso problema con il file dell'init script (modifica per "nice"). Al momento era solo una prova veloce, ma c'è modo di rimediare... utilizzando il meccanismo delle "diversion" (vedi anche "man dpkg-divert", nonché qui).
se non sono specificati diversamente, squeezelite non si calcola automaticamente il buffer in funzione del s/r?
Quale dovrebbero essere i valori più appropriati per 384K?
non ho ancora aggiornato i pacchetti, ma ovviamente prevedevo di farlo non appena lo farò.
confermo la maggiore "pulizia"; mi sembra invece strano che tu percepisca (forse) meno dettaglio. In teoria, a 24bit il dithering dovrebbe essere irrilevante (vedi sotto) o, al più, dovrebbe essere vero esattamente il contrario: una maggiore / migliore percezione dei dettagli. Che poi in effetti è quello che credo di aver percepito io nel mio sistema, unitamente ad un miglioramento anche in termini di "ariosità", "immagine", ed altro ancora... ci sono stati dei (piccoli) miglioramenti praticamente su tutti i parametri.
Wikipedia: Dither (versione in italiano).
Gli esempi visivi (applicati alla fotografia digitale, che ha comunque problematiche analoghe a quelle dell'audio digitale) sono impressionanti. Guardate questa foto (con una "bit-depth" volutamente ridotta per evidenziare il problema) "prima" (senza dithering):
...e la stessa foto "dopo" l'applicazione del dithering:
è più che evidente come, anche e soprattutto da un punto di vista squisitamente percettivo, il dithering migliori le cose in modo enorme. Anche per l'audio è la stessa cosa...
idem per i DAC, che hanno un DR (reale/effettivo) che, in pratica, anche nei casi migliori raramente supera i 100dB o poco più (ad es. l'AK4490 dichiara un DR di 120dB, che però in effetti si riduce già a causa della sua THD+N dichiarata di -112dB; le implementazioni pratiche poi raramente raggiungono quei livelli ottimali). Ulteriori riduzioni della "risoluzione" / range dinamico effettivi si hanno inoltre a causa del resto della catena di riproduzione...
e questo IMHO è probabilmente il punto cruciale.
Pensa al DSD: con una "bit-depth" pari ad un solo bit, proprio (e solo) grazie all'oversampling, al dithering ed al noise-shaping riesce a garantire "risoluzioni" e dinamiche effettive superiori a quelle del PCM 16/44.1 (CD).
Con l'upsampling del PCM (specie se lo uniamo a dithering e noise-shaping, che poi è quello che fa ad es. HQPlayer) facciamo sostanzialmente la stessa cosa: guadagniamo cioè "risoluzione" e dinamica "in banda" (laddove conta di più) spostando il rumore (di quantizzazione) verso frequenze sempre più alte (poco o per nulla udibili e/o eliminate dai filtri analogici a valle del DAC).
Riferimenti:
Audacity Manual: Digital Audio Fundamentals
Audacity Wiki: Bit Depth
Wikipedia: Dynamic range
Wikipedia: Audio bit depth
+1 :-)
immagino banalmente cancellando/rinominando il file eseguibile installato da LMS e copiando al suo posto quello della versione aggiornata...
La differenza 24/32 assomiglia tanto al problema dei formati 24 e 24_3, provato a mettere -p 24_3? (semplice associazione d'idee, non ho provato).
Per il dithering ed i 24 bit, premettendo che non ho ancora chiarissimo il funzionamento del tutto (diciamo che ho inquadrato i singoli elementi, ma non le diverse combinazioni) mi rimane sempre questo fortissimo dubbio:
a. se parti da 16 bit e 'converti' con sox a 24 (o 32) (senza nessun altro effetto, ovvio) hai un vantaggio applicando il dithering (che immagino fosse stato a suo tempo applicato)? Se si, questo dovrebbe tradursi in una diversa valorizzazione dei bit del(i) byte(s) meno significativo(i) aggiunto(i), se 'toccasse' anche i due originari, sarebbe come dire che avremmo un 'beneficio' anche solo applicando il dithering sullo stream originale. Dove sbaglio?
b. se fai l'operazione inversa, mi è chiara l'utilità: in un processo lossy 'arrotondi' con senso invece che sempicemente troncare.
c. con upsampling e noise shaping mi è chairo cosa succede, se ho capito bene, dithering -S fa esattamente questo, vero?
Le sensazioni.
Non ci giuro, ho inserito il comando e provato mentre ascoltavo Ophélie Gaillard, Carl Philipp Emanuel Bach, Vol. 2 via Qobuz, è un disco stupendo ed adattissimo per verificare la resa del dettaglio, lei gioca con i polpastrelli e l'archetto producendo diverse sonorità, mentre il clavicembalo ed i violini dietro costruiscono il 'tappeto'. Mi è parso, ma è un'impressione, che la resa dei polpastrelli sulle corde fosse meno evidente con dithering -S rispetto a senza, mentre l'ariosità generale e la 'discriminazione' dei diversi strumenti dietro è di certo migliorata.
Però occhio, per mia esperienza a volte alcuni dettagli risultano enfatizzati artificiosamente, spesso come conseguenza di un mascheramento di altre informazioni, è sempre una sottile alchimia e ricerca del giusto compromesso, iniseme a quello sono sparite le asperità sui violini ed il clavicembalo sembra meno impastato. Meglio adesso o prima?
Per stabilirlo devo ascoltare più a lungo, se qualcosa mi disturba mi toglie la voglia di stare li e me ne accorgo, altrimenti la musica scorre...
EDIT: Aggiungo una similitudine con le immagini che hai postato: Se ti focalizzi sulla resa dell'ombra nell'orecchio sinistro del gatto, è senza dubbio più presente (meglio percepibile) nella foto originaria che non in quella che ha subito il dithering. E' però ovvio che l'equilibrio generale, la 'naturalezza' è migliore nella seconda, anche se l'orecchio sinistro appare 'piatto' e senza ombreggiatura.
Sono certo che se si trattasse di audio, avresti 'partigiani' della foto senza dithering perchè più viva e dettagliata ed altrettanti della seconda perchè più naturale e smooth, tenedo presente che l'effetto mostrato è volutamente esagerato.
Ultima modifica di marcoc1712 : 22-04-2016 a 14:44
Ciao, Marco.
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
— E. F. Schumacher (mis-attributed to A. Einstein)
________________________________________________________________________________
Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE
é quello che ho fatto....er sostituire SOX in windows basta rinominare (o cancellare) la versione in <server folder>/Bin/Ms.../ (vedi in info) e sostituirla con quella che vuoi, Se fai gli aggiornamenti usando la funzionalità di LMS, non dovrebbe sostituirtela, ma bisogna verificare. Io eseguo da codice in Win e sarei costretto a ripetere l'operazione ogni volta, a meno di configurazioni manuali.
appena avviavo una song...mi diceva che mancava una libreria...quindi mi sono copiato pure le librerie...non mi dava piú errore...ma niente suono....
cmnq verificheró meglio...
tutto è relativo...
quindi, riassumendo, nella mia condizione (stream wav 384K da LMS, nessuna elaborazione da parte di SL), quali opzioni/parametri metteresti sulla riga di comando di squeezelite? "-b 30720:2048" ? o ti riferivi ai parametri dell'opzione "-a"?
mmh, in verità non è che fossi contrario, stavo solo valutando le varie possibilità.
In generale, volendo/dovendo "rimpiazzare" un file installato da un pacchetto, nei sistemi Debian (e derivati, incluse Ubuntu e Mint) la soluzione "standard" è quella di usare una "diversion" (vedi post precedenti). Questo rende la modifica "permanente" ed impedisce al package manager di sostituire il file in caso di aggiornamenti/re-installazioni.
Però, se puoi modificare C-3PO in modo che questo utilizzi un binario diverso a tua scelta, non potresti banalmente fornirgli direttamente il path completo dell'eseguibile? (ad es. in questo caso "/usr/bin/sox").
In questo modo si eviterebbe la necessità di dover fare qualsivoglia modifica al sistema; per giunta, rendendo la cosa configurabile dall'utente, si potrebbe utilizzare lo stesso "meccanismo" su tutti i SO supportati. Ad es. potresti aggiungere una opzione (checkbox) "use custom sox binary", seguita da un input field dove specificare il path dell'eseguibile...
Ciao, Paolo.
«Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»
Ciao, Marco.
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
— E. F. Schumacher (mis-attributed to A. Einstein)
________________________________________________________________________________
Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE
ehm... non proprio... (vedi post precedente). Ancora non ho troppo ben chiaro - non mi sono mai preso la briga di approfondire in dettaglio - significato e funzionamento delle opzioni/parametri relativi di SL.
ti riferisci ad LMS o a SL?
No.
(al contrario: se il file di ingresso era già stato opportunamente "ditherato", in un caso del genere rischi solo di peggiorare le cose).
Non per caso, se non fai nessuna operazione che cambia (internamente) la "precisione" dello stream, in realtà SOX non te lo fa fare proprio. Cioè, se ad es. dai un comando del genere:
(dove "pippo16.wav" è un file o uno stream con un bit-depth<=24), SoX ti risponde picche:codice:sox -V3 pippo16.wav -b24 pippo24.flac dither -S
cioè si accorge che non c'è motivo di fare dithering e quindi non aggiunge affatto l'effetto "dither" alla sua catena di esecuzione (come puoi vedere vengono eseguiti soltanto le funzioni "input" e "output", non è presente nessuna riga: "effects chain: dither").codice:sox: SoX v14.4.1 sox INFO formats: detected file format type `wav' Input File : 'pippo16.wav' Channels : 2 Sample Rate : 44100 Precision : 16-bit Duration : 00:04:20.12 = 11471193 samples = 19508.8 CDDA sectors File Size : 45.9M Bit Rate : 1.41M Sample Encoding: 16-bit Signed Integer PCM Endian Type : little Reverse Nibbles: no Reverse Bits : no sox INFO flac: encoding at 24 bits per sample Output File : 'pippo24.flac' Channels : 2 Sample Rate : 44100 Precision : 24-bit Duration : 00:04:20.12 = 11471193 samples = 19508.8 CDDA sectors Sample Encoding: 24-bit FLAC Endian Type : little Reverse Nibbles: no Reverse Bits : no Comment : 'Processed by SoX' sox INFO dither: has no effect in this configuration sox INFO sox: effects chain: input 44100Hz 2 channels sox INFO sox: effects chain: output 44100Hz 2 channels
Premessa. Facciamo un passo indietro: "internamente" SoX usa sempre un suo formato a 32bit.
*) la funzione "input" converte qualsiasi formato di ingresso nel suo formato interno (a 32bit);
*) la funzione "output" converte dal suo formato interno (a 32bit) a quello richiesto in uscita.
Se non fai nessuna operazione che implica una alterazione dei dati (il processo è "bit perfect"), la precisione in uscita è ovviamente uguale a quella in ingresso. Se in ingresso avevi 16bit, ne hai altrettanti in uscita... ed anche internamente (quelli "extra" sono e restano a zero).
Se però aggiungi un qualsiasi "effetto" che esegue delle elaborazioni (ad es. "rate" per l'upsampling), poiché i calcoli vengono effettuati con una precisione maggiore, tutti e 32 i bit del formato interno vengono utilizzati e sono significativi.
(ovviamente la "risoluzione effettiva" in uscita non è e non può essere maggiore di quella in ingresso, ma questo è un altro discorso).
Ad es., dato il comando:
ottengo questo output:codice:sox -V3 pippo16.wav -b24 pippo24.flac rate 48000 dither -S
in questo caso il dithering viene eseguito in quanto è necessario per passare da 32bit (formato interno) a 24bit (uscita richiesta).codice:sox: SoX v14.4.1 sox INFO formats: detected file format type `wav' Input File : 'pippo16.wav' Channels : 2 Sample Rate : 44100 Precision : 16-bit Duration : 00:04:20.12 = 11471193 samples = 19508.8 CDDA sectors File Size : 45.9M Bit Rate : 1.41M Sample Encoding: 16-bit Signed Integer PCM Endian Type : little Reverse Nibbles: no Reverse Bits : no sox INFO flac: encoding at 24 bits per sample Output File : 'pippo24.flac' Channels : 2 Sample Rate : 48000 Precision : 24-bit Duration : 00:04:20.12 = 12485652 samples ~ 19508.8 CDDA sectors Sample Encoding: 24-bit FLAC Endian Type : little Reverse Nibbles: no Reverse Bits : no Comment : 'Processed by SoX' sox INFO sox: effects chain: input 44100Hz 2 channels sox INFO sox: effects chain: rate 48000Hz 2 channels sox INFO sox: effects chain: dither 48000Hz 2 channels sox INFO sox: effects chain: output 48000Hz 2 channels
Ni.
L'opzione "-s" (s minuscola) e le varie "-f xxx" fanno propriamente dithering con noise-shaping; l'opzione "-S" (S maiuscola) si limita a fare dithering con una "sloped TPDF" (cioè fa anche lei una sorta di noise-shaping, ma alquanto blando e primitivo).
Purtroppo le funzioni corrispondenti a "-s" e "-f" non sono state implementate per sample/rate diversi da 44.1 (e forse 48k).
...devo aggiungere almeno un paio di entries alla loro "whish list"!
ah, verissimo...
sottoscrivo.
Ciao, Paolo.
«Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»
Ci sono attualmente 1 utenti che stanno visualizzando questa discussione. (0 utenti e 1 ospiti)
|
nexthardware.com - © 2002-2022 |
Rispondi quotando
