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?
Printable View
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?
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.Quote:
Originariamente inviato da UnixMan
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).Quote:
Originariamente inviato da marcoc1712
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). ;)Quote:
Originariamente inviato da marcoc1712
se non sono specificati diversamente, squeezelite non si calcola automaticamente il buffer in funzione del s/r?Quote:
Originariamente inviato da marcoc1712
Quale dovrebbero essere i valori più appropriati per 384K?
non ho ancora aggiornato i pacchetti, ma ovviamente prevedevo di farlo non appena lo farò. ;)Quote:
Originariamente inviato da marcoc1712
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.Quote:
Originariamente inviato da marcoc1712
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):
Allegato 16971
...e la stessa foto "dopo" l'applicazione del dithering:
Allegato 16972
è 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...Quote:
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.Quote:
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 :-)Quote:
Originariamente inviato da antonellocaroli
immagino banalmente cancellando/rinominando il file eseguibile installato da LMS e copiando al suo posto quello della versione aggiornata... ;-)Quote:
Originariamente inviato da antonellocaroli
ci avevo provato....ma senza risultati...nel senso che non funge....ma sicuro sbaglio in qualcosa....Quote:
Originariamente inviato da UnixMan
non funge... in che senso? che metti una versione nuova ma ti ritrovi di nuovo quella vecchia? che sia a causa del meccanismo di aggiornamento automatico di LMS? (oppure che sia forse in azione uno dei meccanismi di "protezione" dei files di windoze?)Quote:
Originariamente inviato da antonellocaroli
'giusto' è relativo.Quote:
Originariamente inviato da antonellocaroli
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/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.
Per il buffer in relazione al s/r e cosa fa squeezelite ho gia risposto sopra, credo. Per il nice, aspetto la modifica.Quote:
Originariamente inviato da UnixMan
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.
é quello che ho fatto....Quote:
er sostituire SOX in windows basta rinominare (o cancellare) la versione in/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... :ppQuote:
Originariamente inviato da marcoc1712
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"? :lokaro
mmh, in verità non è che fossi contrario, stavo solo valutando le varie possibilità.Quote:
Originariamente inviato da marcoc1712
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... :mmmm
Prova a lancaire la riga di comando togliendo l'opzione silenziosa (a memoria -q) Ricorda di mettere 'output su file, altrimenti hai la sagra di paese in casa!Quote:
Originariamente inviato da antonellocaroli
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. :ehhQuote:
Originariamente inviato da marcoc1712
ti riferisci ad LMS o a SL?Quote:
Originariamente inviato da marcoc1712
No.Quote:
Originariamente inviato da marcoc1712
(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.Quote:
Originariamente inviato da marcoc1712
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...Quote:
Originariamente inviato da marcoc1712
sottoscrivo. :)Quote:
Originariamente inviato da marcoc1712
NO!Quote:
Originariamente inviato da UnixMan
io metterei
-a 40:2::0 -b 30720:30720.
30720:30720 (o qualiasi altro valore) sono uguali proprio perchè non c'è conversione di formato ne resampling, questo è il cardine del ragionamento: tenere uguali (o simili) le 'durate' dei buffer. In pratica, dato il formato, l'unica variabile è la durata che desideri.
Nello specifico dei valori:
-a 40:2::0
40 ms è il default ed a me pare tutto sommato un buon compromesso, 2 - sempre secondo me - migliora leggermente rispetto a valori superiori, se non manda in crisi la CPU lo terrei fisso, MMAP, almeno in assenza di conversioni, è certamente inutile.
-b 30720:30720.
equivale a 10 sec. per il formato 384/32 (3072 KB/sec). Diversi formati o divere durate originano diversi valori.
No, non riesco, o almeno non per i casi in cui non uso l'eseguibile C-3PO ma LMS nativo. In quei casi nella riga di configurazione C-3PO scrive [SOX] (o qualsiasi altra cosa) ed è LMS che recupera il binario da utilizzare in base ai suoi algoritmi di ricerca, come ti ho già detto, dovrei patchare LMS e non voglio farlo.Quote:
Originariamente inviato da UnixMan
Comunque io continuo a non capire come si dovrebbe fare in Linux per avere due versioni dello stesso eseguibile, ad esempio per gestire la transizione negli upgrade di sistema, a scopo di test... Come fai a gestire un cambio di release graduale (con parallelo) in produzione, ad esempio?
"-q" si limita a disabilitare quella sorta di "Vu-meter"/progress bar:Quote:
Originariamente inviato da marcoc1712
che di solito aggiunge automaticamente ad es. quando lo chiami con "play" (ed in alcuni altri casi), o che puoi (sempre) abilitare manualmente con l'opzione (globale) "-S".codice:In:41.3% 00:01:47.46 [00:02:32.66] Out:4.74M [ -===|==- ] Hd:0.4 Clip:0
Per vedere invece in dettaglio che cosa succede, abilita l'opzione "verbose", "-Vn", dove "n" è un intero... di solito conviene usare "-V3" (valori maggiori sono per il debugging di sox stesso).
mmmh... Secondo me viene eseguito perchè l'input è 44100 e l'output è 48000, anche nel caso precedente c'era il passaggio a 32, ma NON lo eseguiva perchè non c'è stato resampling. Se qui esci a 44100 (24) a mio avviso non dovrebbe farlo in quanto non necessario.Quote:
Originariamente inviato da UnixMan
- sempre con un resampling.
- sempre con una riduzione di profondità.
mai altrimenti. Io l'ho capita così, non ho capito una beata angelica?
Per il 24_3 mi riferivo all'opzione di sox per il noise shaping, che a tuo avviso può provocare differenze in quanto 32 e non 24.
OK. Quindi, se ad es. volessi un buffer di 1s, dovrei mettere "-b 3072:3072", mentre per "-a" non cambia nulla, giusto?Quote:
Originariamente inviato da marcoc1712
che c'entrano le conversioni? se non ho capito male, quella dovrebbe essere la modalità di accesso (per l'output) al device ALSA che (per i dispositivi per i quali è possibile) può utilizzare la modalità "memory mapped" (che è molto più veloce, "leggera" ed efficiente... e, almeno in teoria, sempre preferibile ove possa essere utilizzata).Quote:
Originariamente inviato da marcoc1712
ovviamente no. Ma quali sono i casi nei quali usi LMS?Quote:
Originariamente inviato da marcoc1712
Non puoi by-passarlo sempre, gestendo tutte le diverse modalità supportate direttamente da C-3PO?
In caso contrario, anche se non è proprio il massimo, al limite nulla vieterebbe di utilizzare due versioni diverse di sox nei due casi...
con i pacchetti, normalmente... non si fa. Quelli sono pensati per fare upgrade completi ed "immediati": in sostanza è un sistema basato su transazioni, "o tutto o niente", un po' come nei DBMS (per contro, in linea di principio sono già testati e verificati, per cui degli eventuali problemi se ne sono già occupati i "maintainers" della distribuzione / dei pacchetti stessi).Quote:
Originariamente inviato da marcoc1712
Diversamente devi installare (a mano) in posti diversi e/o con nomi diversi.
BTW: le sostituzioni "graduali" dei sistemi in produzione tipicamente si fanno "affiancando" macchine (reali o -oggi più spesso- virtuali) con il nuovo sistema a quelle vecchie. ;)
No. Non lo eseguiva perché i dati non erano stati modificati e quindi, anche se rappresentati con "parole" di 32bit, continuavano ad essere quelli originali. Lo dice abbastanza chiaramente anche nella man page:Quote:
Originariamente inviato da marcoc1712
In buona sostanza, puoi/devi aggiungere il dithering se hai alterato i dati (in un qualsiasi modo tale da "aggiungere" bit significativi).codice:Dithering
Dithering is a technique used to maximise the dynamic range of audio
stored at a particular bit-depth. Any distortion introduced by
quantisation is decorrelated by adding a small amount of white noise to
the signal. In most cases, SoX can determine whether the selected
processing requires dither and will add it during output formatting if
appropriate.
Specifically, by default, SoX automatically adds TPDF dither when the
output bit-depth is less than 24 and any of the following are true:
· bit-depth reduction has been specified explicitly using a command-
line option
· the output file format supports only bit-depths lower than that of
the input file format
· an effect has increased effective bit-depth within the internal
processing chain
For example, adjusting volume with vol 0.25 requires two additional
bits in which to losslessly store its results (since 0.25 decimal
equals 0.01 binary). So if the input file bit-depth is 16, then SoX's
internal representation will utilise 18 bits after processing this
volume change. In order to store the output at the same depth as the
input, dithering is used to remove the additional bits.
Use the -V option to see what processing SoX has automatically added.
The -D option may be given to override automatic dithering. To invoke
dithering manually (e.g. to select a noise-shaping curve), see the
dither effect.
BTW: da sostanziale ignorante in materia di DSP e affini, stavo riflettendo... dato che per l'informazione valgono principi analoghi ai tre principi della termodinamica e quindi è fuor di dubbio che, qualsiasi cosa io faccia, non posso ottenere in uscita da un qualsivoglia processo una quanità di informazione maggiore di quella che avevo in origine (anzi, sicuramente ne perderò almeno un po' per strada), se parto da uno stream a 16bit (quindi con max 96dB di dinamica...) ed esco con uno a 24 (o più) bit (dinamica >= 144dB), "cosa c'è" realmente in quei bit in più? che significato fisico hanno? Sarà mica che alla fine non è nient'altro che rumore (verosimilmente correlato...) e che quindi se entro con "n" bit è bene che non esca mai con più di "n" bit? Cioè che in pratica sarebbe bene utilizzare il dithering per eliminare tutti i bit "extra" e "decorrelare" così il rumore?
Questa IMO è una prova da fare (cioè, uscire -con dithering- a 16bit con materiale a 16 bit, a 24 con materiale a 24, ecc). Se all'ascolto la cosa dovesse risultare positiva (possibile, per non dire addirittura probabile), ci sarebbe altro lavoro per te... ;)
(C-3PO infatti dovrebbe diventare abbastanza "furbo" da cambiare formato di uscita o quanto meno "precisione" effettiva ottenuta con "-p" in modo da uscire con una risoluzione sempre minore o uguale a quella di ingresso, in funzione di questa e della risoluzione/dinamica effettiva del DAC utilizzato).
Questo direi che non è in discussione, nè per la profondità nè per la frequenza di campionamento. Puoi usare algoritmi complicati fin che vuoi, ma l'informazione in se è persa, andata, stai solo cercando di ricostruirla matematicamente ed applicando correzioni psicoacustiche.Quote:
Originariamente inviato da UnixMan
Se nel farlo usi mantisse più ampie hai - matematicamente - un risultato più preciso, quanto questo poi sia 'reale' o 'rumore' è tutto un'altro discorso, da qui i processi psicoaucustici, tra cui il dithering.
Non ho capito come riportare 'indietro' la precisione potrebbe risultare benefico. Secondo me non consideri che il ditering viene applicato SOLO se la precisione risultante è minore di 24 bit. A 24 bit ed oltre, la precisione è talmente alta da NON richiedere l'applicazione del dithering ANCHE quando sia stata modificata la porzione significatva dei dati e/o si sia incrementata la profondità tramite un effetto. Questo, almeno, è quello che sostengono.
Se invece il tuo dubbio è: faccio resampling ed aumento (fittiziamente) la precisone, quindi cosa finisce nel byte meno significativo se non lo 'sterile' risulato di un calcolo? Non può essere che questo calcolo reintroduca patterns che risultano in distorsione?
Nel caso la risposta è: Bella domanda! Ma non so che dirti...
Lo spieghi tu ai clienti che devono 'raddoppiare' la potenza di calcolo? L'ho visto succedere solo nei progetti SAP e solo lato server, MAI lato client, non è sostenibile SE in alternativa puoi usare il vecchio hw semplicemente rinominando l'eseguibile...Quote:
Originariamente inviato da UnixMan
aggiunto "dither -S" .....devo dire che mi piace...mi convince.....buona drittaQuote:
Originariamente inviato da marcoc1712
Per Squeezelite uso solo opzioni "default" e sto benissimo
-b corretto, per -a:Quote:
Originariamente inviato da UnixMan
il buffer size è già espresso in ms (se usi valori inferiori a 500) , per questo non cambia, in realtà la dimensione del buffer in bytes cambia 'dinamicamente' in funzione del formato e del samplerate.
il period count (se usi valori inferiori a 50) è espresso in numero di periodi nel buffer, quindi il period size diventa buffer size/period count.
In questo modo rimani INDIPENDENTE dal reale formato e sample rate utilizzato, fatti un favore e NON complicarti la vita usando valori espressi in bytes...
MMAP è relativo alla chiamata di pcm_writeI o a quella analoga ma che usa MMAP, più leggera per accessi random perchè non richiede il carimanento preventivo in memoria, ma solo a richiesta (lazy load). Ma nel nostro caso, la lettura dal buffer di output è SEMPRE da memoria precaricata, quindi MMAP è inutile, ciòè a maggior ragione vero quando l'input e l'output sono 'sincroni', avendo lo stesso formato. (stiamo parlando del formato di output e di quello della scheda audio).Quote:
Originariamente inviato da UnixMan
The only case where there is a separate buffer is when the data written
by the application is not the same as the data to be written to the
hardware, i.e., when using dmix or sample format conversion.
IO francamente dubito ci sia un vantaggio anche nel secondo caso, comunque, di certo non c'è quando i formati sono gli stessi.
sì. Questo, presumo, in base al fatto che l'intervallo dinamico dell'orecchio umano si stima essere intorno ai 120 -:- 140 dB circa(*); poiché 24 bit corrispondono a circa 144dB, a livello di LSB dovremmo essere già abbondantemente oltre la max "risoluzione" dell'orecchio umano, per cui qualsiasi effetto a quei livelli dovrebbe risultare già di per sé stesso del tutto inaudibile (e quindi con bit-depth>=24bit applicare il dithering dovrebbe essere superfluo).Quote:
Originariamente inviato da marcoc1712
(*) per altro si tratta di un range dinamico per certi versi fittizio, in quanto ottenuto grazie ai meccanismi dell'orecchio medio che si comportano come una sorta di "amplificatore" (meccanico) dotato di "AGC" (controllo automatico del guadagno), ovvero come un compressore della dinamica. In sostanza l'orecchio si adatta all'intensità dei suoni cui è esposto, diminuendo progressivamente la sua sensibilità all'aumentare della pressione acustica e viceversa (con tutti i fenomeni di mascheramento che ne conseguono...).
esattamente, il dubbio era proprio questo!Quote:
Originariamente inviato da marcoc1712
(ovviamente, intendendo "distorsione" in senso lato; penso che nel caso sarebbe più corretto parlare di "rumore correlato" o di "modulazione del rumore", che sono comunque fenomeni che rivestono una importanza tutt'altro che trascurabile a livello di percezione/psicoacustica).
Comunque il play parte...ma niente suono
Questo il log di LMS
Allegato 16975
Stesso risultato se disattivo C-3PO e cambio il custom-convert a mano
Ragazzi, anche se non scrivo per mancanza di tempo e materia prima (sono momentaneamente senza impianto causa trasferimento più o meno imminente) vi seguo assiduamente. Non mi sono perso!! :-)
Ps attualmente "ascolto" con un sinto ampli pioneer e cassettine 5.1 Canton :-D :-D ...almeno c'è un futro+dac come sorgente ehehe
[16-04-23 07:29:33.5185] Slim::Player::Source::playmode (96) 50:e5:49:cc:b4:29: Current playmode: pauseQuote:
Originariamente inviato da antonellocaroli
Sei in pausa, non so perchè.
Prima però hai un errore di end of stream, che potrebbe indicare un errore della riga di comando (qualche opzione che la nuova versione di sox non accetta?)
[16-04-23 07:29:19.2269] Slim::Player::Source::_readNextChunk (373) end of file or error on socket, song pos: 5609
Io farei una prova lanciando SOX da riga di comando:
"C:\PROGRA~2\SQUEEZ~1\server\Bin\MSWin32-x86-multi-thread\flac.exe" -dcs -- "C:\Users\filippo\Desktop\Music\FLAC\02 Michel Godard & Le Miroir Du Temps - Days of Weeping Delights.flac" | "C:\PROGRA~2\SQUEEZ~1\server\Bin\MSWin32-x86-multi-thread\sox.exe" -t wav - -t wav -r 384000 -3 --buffer=8192 - gain -1 rate -v -M -a -b 90.7 384000 remix -m 1p-0.5 2 dither -S prova.wav
per capire cosa non gli piace.
Dovrebbe segnalarti gli errrori, se no aggiungi -V alle opzioni di sox, come suggeriva Paolo.
Unico consiglio, prova a ridurre il period count a 2 (-a :2:: ), a mio avviso - ma anche di Fabrizio - qualcosa migliora.Quote:
Originariamente inviato da bigtube
Comunque, bisogna sempre considerare che quello che noi scriviamo sono solo 'indicazioni' per ALSA, che in realtà determina i valori reali della dimensione del buffer (quindi del periodo) in funzione delle caratteristiche 'fisiche dell' hw vero e proprio. Squeezelite fornisce feedback dei valori utilizzati nel log.
Probabilmente l'effetto più certo lo si ottiene con il period count, in quanto indipendentemente dalla 'reale' dimensione del buffer, provoca la definizione del period size come buffer size/period count.
2 è il minimo per evitare XRUN sistematici, valori superiori comportano maggiore utilizzo di CPU, ma anche maggiore sicurezza di non intercorrere in errori a causa di 'ritardi' del sistema nel rispondere all'interrupt.
In sistemi minimamente moderni 2 è un valore sicuro e - rispetto al default di 4 - dimezza gli interrupt e quindi il lavoro della CPU, aumentando - però - di conseguenza la latenza, ininfluente ai nostri fini.
Il fatto che la modifica sia 'sensibile' in diversi sistemi è un' altra piccola conferma di quanto questo fattore sia importante.
quel -3 me lo da come errore...lo tolgo e tolgo anche dither -S che mi sembra sia per la vecchia versione e anche remix che me lo da come erroreQuote:
Originariamente inviato da marcoc1712
risultato questo:
codice:C:\Users\filippo>"C:\PROGRA~2\SQUEEZ~1\server\Bin\MSWin32-x86-multi-thread\flac.exe" -dcs -- "C:\Users\filippo\Desktop\Music\FLAC\02 Michel Godard & Le Miroir Du Temps - Days of Weeping Delights.flac" | "C:\PROGRA~2\SQUEEZ~1\server\Bin\MSWin32-x86-multi-thread\sox.exe" -t wav - -t wav -r 384000 --buffer=8192 - gain -1 rate -v -M -a -b 90.7 384000 prova.wav
C:\PROGRA~2\SQUEEZ~1\server\Bin\MSWin32-x86-multi-thread\sox.exe FAIL rate: usage: [-q|-l|-m|-h|-v] [override-options] RATE[k]
BAND-
QUALITY WIDTH REJ dB TYPICAL USE
-q quick n/a ~30 @ Fs/4 playback on ancient hardware
-l low 80% 100 playback on old hardware
-m medium 95% 100 audio playback
-h high (default) 95% 125 16-bit mastering (use with dither)
-v very high 95% 175 24-bit mastering
OVERRIDE OPTIONS (only with -m, -h, -v)
-M/-I/-L Phase response = minimum/intermediate/linear(default)
-s Steep filter (band-width = 99%)
-a Allow aliasing above the pass-band
-b 74-99.7 Any band-width %
-p 0-100 Any phase response (0 = minimum, 25 = intermediate,
50 = linear, 100 = maximum)
mmhhh forse ho sbagliato io.. il file di out (prova.wav) prova a metterlo dopo --buffer=8192 al posto del "-" prima di gain.Quote:
Originariamente inviato da antonellocaroli
p.s. gain -1 è ad alto rischio clipping, dopo aver provato diversi files 'campione' della mia libreria, ho verificato che -6 è il valore 'sicuro', l'unica implicazione è ...che devo alzare il volume.
cosi non mi da errore
e cosicodice:C:\Users\filippo>"C:\PROGRA~2\SQUEEZ~1\server\Bin\MSWin32-x86-multi-thread\flac.exe" -dcs -- "C:\Users\filippo\Desktop\Music\FLAC\02 Michel Godard & Le Miroir Du Temps - Days of Weeping Delights.flac" | "C:\PROGRA~2\SQUEEZ~1\server\Bin\MSWin32-x86-multi-thread\sox.exe" -t wav - -t wav -r 384000 --buffer=8192 prova.wav gain -1 rate -v -M -a -b 90.7 384000 remix -m 1p-0.5 2
ma comunque finisce il processo...codice:C:\Users\filippo>"C:\PROGRA~2\SQUEEZ~1\server\Bin\MSWin32-x86-multi-thread\flac.exe" -dcs -- "C:\Users\filippo\Desktop\Music\FLAC\02 Michel Godard & Le Miroir Du Temps - Days of Weeping Delights.flac" | "C:\PROGRA~2\SQUEEZ~1\server\Bin\MSWin32-x86-multi-thread\sox.exe" -t wav - -t wav -r 384000 --buffer=8192 prova.wav gain -1 rate -v -M -a -b 90.7 384000 remix -m 1p-0.5 2 dither -f shibata -p 24
C:\PROGRA~2\SQUEEZ~1\server\Bin\MSWin32-x86-multi-thread\sox.exe WARN dither: no `shibata' filter is available for rate 384000; using sloped TPDF
@Paolo:
casualmente, verificando l'erore di Filippo, mi è uscito questo:
Pare che sia possibile quello che dici anche nella versione in LMS, almeno in windows, usando il 'nome' del filtro.Hai provato l'help di sox in linux con la versione in LMS? Mi sembrerebbe strano non fossero allineate.codice:
/cygdrive/g/Sviluppo/slimserver/Bin/MSWin32-x86-multi-thread/sox FAIL dither: us
age: [-a] [-S|-s|-f filter]
(none) Use TPDF
-a Automatically turn on & off dithering as needed (use with caution!)
-S Use sloped TPDF (without noise shaping)
-s Shape noise (with shibata filter)
-f name Set shaping filter to one of: lipshitz, f-weighted,
modified-e-weighted, improved-e-weighted, gesemann,
shibata, low-shibata, high-shibata.
stando a quello che dice Paolo, i filtri sono disponibili solo a 44100, non ho capito cosa vuol dire che 'finisce il proceso', crea il file prova.wav? Se si, vuol dire che funziona, quindi bisogna capire perchè non funziona in LMS, molto strano.Quote:
Originariamente inviato da antonellocaroli
Io ho provato con la vecchia versione di sox a mettere dither -f shibata -p 24Quote:
Originariamente inviato da marcoc1712
il play va subito in pausa
sto provando con una via di mezzo... "-a 100:3" e "-b 10240:10240" (non ho una LAN di mezzo, quindi dovrebbe essere più che abbondante...).Quote:
Originariamente inviato da marcoc1712
Questo il log (che ho riattivato per l'occasione):
Non ci giurerei, ma forse qualche minimo cambiamento c'è stato.codice:[12:25:34.934604] stream_thread:176 headers: len: 115
HTTP/1.1 200 OK
Server: Logitech Media Server (7.9.0 - 1456927571)
Connection: close
Content-Type: audio/L16
[12:25:34.951485] output_thread:638 open output device: hw:CARD=D20,DEV=0
[12:25:34.951985] alsa_open:355 opening device at: 44100
[12:25:34.952212] alsa_open:406 opened device hw:CARD=D20,DEV=0 using format: S32_LE sample rate: 44100 mmap: 1
[12:25:34.952235] alsa_open:485 buffer: 100 period: 3 -> buffer size: 4410 period size: 1470
[12:25:34.977855] _check_header:77 WAVE
[12:25:34.978107] _check_header:101 header: fmt len: 40
[12:25:34.978115] _check_header:129 pcm size: 4 rate: 384000 chan: 2 bigendian: 0
[12:25:34.978122] _check_header:101 header: fact len: 4
[12:25:34.978128] _check_header:101 header: data len: 1446789120
[12:25:34.978134] _check_header:107 audio size: 1446789120
[12:25:34.978141] pcm_decode:200 setting track_start
[12:25:35.014581] _output_frames:61 start buffer frames: 135158
[12:25:35.014638] _output_frames:146 track start sample rate: 384000 replay_gain: 0
[12:25:35.024656] output_thread:638 open output device: hw:CARD=D20,DEV=0
[12:25:35.034495] alsa_open:355 opening device at: 384000
[12:25:35.034755] alsa_open:406 opened device hw:CARD=D20,DEV=0 using format: S32_LE sample rate: 384000 mmap: 1
[12:25:35.034781] alsa_open:485 buffer: 100 period: 3 -> buffer size: 38400 period size: 12800
[12:25:41.345843] decode_flush:190 decode flush
[12:25:41.345895] output_flush:423 flush output buffer
[12:25:41.659311] codec_open:218 codec open: 'p'
[12:25:41.659371] pcm_open:373 pcm size: 2 rate: 44100 chan: 2 bigendian: 0
[12:25:41.659407] stream_sock:384 connecting to 127.0.0.1:9000
[12:25:41.659524] stream_sock:413 header: GET /stream.mp3?player=00:1c:c0:37:22:73 HTTP/1.0
che versione di sox hai? Dai il comando [path\]sox --versionQuote:
Originariamente inviato da antonellocaroli
N.B.: Marco, attento che le opzioni "-" ("-2", "-3", ecc.) che stai utilizzando per specificare il bit depth degli stream sono dei vecchi alias deprecati: nella v14.4.1 fornita con Debian Jessie ancora funzionano, ma in versioni successive potrebbero essere stati / venire eliminati! Usa "-b "!
codice:-1/-2/-3/-4/-8
The number of bytes in each encoded sample. Deprecated aliases for -b 8, -b 16, -b 24, -b 32, -b 64 respectively.
"dither" (inclusa l'opzione "-S" per lo shaped TPDF) c'è su tutte le versioni.Quote:
Originariamente inviato da antonellocaroli
che lo avevi messo a fare?! Quello lo usa Marco come controllo di bilanciamento, è una opzione specifica solo per il suo sistema!Quote:
Originariamente inviato da antonellocaroli
err... NON puoi mettere il file di uscita lì in fondo!!Quote:
Originariamente inviato da antonellocaroli
Il nome del file file lo devi mettere dove specifichi il file/stream di uscita e le sue caratteristiche... cioè subito dopo "-t wav -b 24 -r 384000", e PRIMA della catena degli "effetti" (gain, rate, dither, ecc), AL POSTO di quel " - ", che rappresenta IL NOME DEL FILE DI USCITA ("-" significa "standard output").
si crea il file...Quote:
Originariamente inviato da marcoc1712
nella prima riga provata é inserito il remix
C:\Program Files (x86)\sox-14-4-2>sox --version
sox: SoX v14.4.2
C:\Program Files (x86)\sox-14-4-2>
L'opzione che manca è la "-p XX", che serve a forzare il dithering ad una "precisione" diversa da (minore di) quella dello stream di uscita:Quote:
Originariamente inviato da marcoc1712
Le varie opzioni di dithering/noise shaping ci sono "da sempre" (da un bel po' di tempo).Quote:
dither [-S|-s|-f filter] [-a] [-p precision]
Apply dithering to the audio. Dithering deliberately adds a small amount of noise to the signal in order to mask audible quantization effects that can occur if the output sample size is less than 24 bits. With no options, this effect will add triangular (TPDF) white noise. Noise-shaping (only for certain sample rates) can be selected with -s. With the -f option, it is possible to select a particular noise-shaping filter from the following list: lipshitz, f-weighted, modified-e-weighted, improved-e-weighted, gesemann, shibata, low-shibata, high-shibata. Note that most filter types are available only with 44100Hz sample rate.
The filter types are distinguished by the following properties: audibility of noise, level of (inaudible, but in some circumstances, otherwise problematic) shaped high frequency noise, and processing speed.
See SoX - Sound eXchange | NoiseShaping for graphs of the different noise-shaping curves.
The -S option selects a slightly `sloped' TPDF, biased towards higher frequencies. It can be used at any sampling rate but below ≈22k, plain TPDF is probably better, and above ≈ 37k, noise-shaped is probably better.
The -a option enables a mode where dithering (and noise-shaping if applicable) are automatically enabled only when needed. The most likely use for this is when applying fade in or out to an already dithered file, so that the redithering applies only to the faded portions. However, auto dithering is not fool-proof, so the fades should be carefully checked for any noise modulation; if this occurs, then either re-dither the whole file, or use trim, fade, and concatencate.
The -p option allows overriding the target precision.
Per quanto riguarda il noise-shaping, purtroppo è implementato solo per s/r di 44.1K e (forse, se non sbaglio) 48K. Se viene richiesto con s/r non supportati SoX va in "fall-back" su "sloped TPDF" (è come se si fosse specificato "-S" anziché "-s" o "-f ...": utilizza cioè una forma di dithering che migliora leggermente le prestazioni alle frequenze più basse a discapito di quelle più alte, insomma una specie di noise-shaping primordiale... che è sempre meglio di niente).
P.S.: Marco, hai visto questo post? ( #670 )
(non vorrei che nel "burst" di post che sono seguiti ti sia sfuggito... occhio al problema con l'opzione per il bit-depth, rischia di far smettere di funzionare C-3PO quando meno te lo aspetti, sistemala appena puoi!).
Potrebbe essere questo il problema....che non funziona con la versione recente di sox in windows???Quote:
Originariamente inviato da UnixMan
EDIT: non é quello il problema...messo la stringa nel conver-custo
La cosa non cambia...codice:flc pcm * *
# FT:{START=--skip=%t}U:{END=--until=%v}
[flac] -dcs $START$ $END$ -- $FILE$ | [sox] -q -t wav - -t wav -r 352800 -c 2 -b 24 -s -L - gain -3 rate -v -M -a -b 90.7 352800
con il vecchio sox va con il nuovo no
Stiamo incrociando troppo...
a. Si l'errore del nome file è stato mio, ...la memoria...
b. -3 = -b 24, probabilmente la nuova versione vuole la seconda forma,... devo modificare C-3PO e tutti i test... Non sarà per domani.
c. sox che manda in pausa il playback non l'avevo mai visto, non so che dire. Da linea di comando cosa fa, arriva in fondo e crea il file o si ferma?
Cambiamenti:
100:3 rispetto a 40:4 (default) = period 'leggermente' più lunghi -> meno uso di CPU. Prova a passare a 2, eventualmente diminuendo il buffer size e vedi se migliori ancora, per me lo ha fatto.
-b più che adeguato, ma l'unico giudice è l'orecchio...
A mio aviso, posto che -b sia su valori 'decenti' (min 1s), la differenza la il period size che deriva da -a, in pratica ...il carico di CPU. Su una macchina comune al server... non saprei.
è possibile.Quote:
Originariamente inviato da antonellocaroli
Per prima cosa, se non lo hai già fatto, proverei ad utilizzare la nuova versione di SoX eliminando tutte le altre opzioni "extra" per escludere altri errori...
Si, Crea il File in tutti e due i casi citati sopraQuote:
Originariamente inviato da marcoc1712
http://www.nexthardware.com/forum/pc...tml#post956777
@Paolo
Il post di sopra l´ho editato...
http://www.nexthardware.com/forum/pc...tml#post956786
Sox preso da qua
https://sourceforge.net/projects/sox/files/sox/14.4.2/
mmh, occhio anche a "-s", anche quella è una abbreviazione deprecata!Quote:
Originariamente inviato da antonellocaroli
@Marco et all: usate esclusivamente le OPZIONI LUNGHE, preferibilmente quelle nella forma "--nome_opzione".codice:-s/-u/-f/-A/-U/-o/-i/-a/-g
Deprecated aliases for specifying the encoding types signed-integer, unsigned-integer, floating-point, a-law, mu-law, oki-adpcm, ima-adpcm, ms-adpcm, gsm-full-rate respectively (see -e above).
Le forme abbreviate sono solo per l'uso in interattivo, non vanno mai utilizzate in script e affini.
Svelato l arcano!!! Bravo Paolo!Quote:
Originariamente inviato da UnixMan
questa va:
:complimenticodice:flc pcm * *
# FT:{START=--skip=%t}U:{END=--until=%v}
[flac] -dcs $START$ $END$ -- $FILE$ | [sox] -q -t wav - -t wav -r 352800 -c 2 -b 24 -L - gain -3 rate -v -M -a -b 90.7 352800 dither -f shibata -p 24