ANNUNCIO: C-3PO 1.0.10 rilasciato in beta

[marcoc1712]

boh, nel mio caso finora non ho riscontrato problemi.

BTW: sicuro si tratti di versioni "speciali", nel senso di modificate? mi sembra più verosimile che si tratti semplicemente di versioni "note", per prevenire eventuali incompatibilità che ovviamente potrebbero esserci qualora cambi "l'interfaccia" (le opzioni e/o la relativa sintassi) di uno dei comandi...


temo proprio di no, il pacchetto sovrascrive tutto. Se metti un (sym)link, rischi che venga sovrascritto il file della versione "ufficiale".


no, ovviamente. Pensavo/speravo che fosse già prevista la possibilità di configurarlo.


no, non è proprio il massimo. Però, per cambiare lo stato di quella opzione, anziché una checkbox forse potresti utilizzare un pulsante che, oltre a cambiare l'opzione, ricarica la pagina. Oppure...


era solo una proposta indicativa... vedi tu come ti "esce" meglio. :-)

Fondamentalmente, l'opzione da gestire è questa:


Si tratta quindi di scegliere se:

1) non aggiungere nulla (lasciare che sox decida da solo se e come eventualmente applicare il dithering)

2) forzare la non-applicazione del dithering (aggiungere -D o --no-dither)

3) aggiungere o meno "l'effetto" dither, senza opzioni (default) oppure con le opzioni "-S", "-s" o "-f <tipo_di_ns>"; in quest'ultimo caso è necessario scegliere il tipo di noise-shaping.

Poiché i casi 1) e 2) nonché le diverse opzioni di 3) sono tutti mutualmente esclusivi, ovviamente si può fare tutto anche con un unico menù a tendina:

* auto/default
* force disable dithering
* default dithering (aggiunge solo dither senza opzioni)
* sloped TPDS (dither -S)
... ecc.

5) specificare o meno la precisione, cioè il numero di bit effettivi che saranno utilizzati dopo il dithering (a prescindere dal formato di uscita), opzione "-p" di "dither". Potresti implementarlo anche banalmente con un menù a tendina la cui prima opzione è "default" (e non fa niente, cioè non aggiunge l'opzione "-p") mentre le altre sono tutti i numeri compresi tra 12 e 24.

In linea di principio questo menù dovrebbe essere mostrato solo se è attivata una delle opzioni di dithering "manuale"... ma dopo tutto nulla vieta di mostrarla sempre, specificando nell'help che tale impostazione sarà utilizzata (e significativa) solo in quel caso.

...quindi in definitiva potresti cavartela semplicemente togliendo una checkbox ed aggiungendo due menù a tendina.

LLMS/SOX: Non so SOX, ma FAAD per esempio è così. Ma come aggiorni? se lo fai usando l'aggiornamento automatico in LMS è differenziale, qundi mi pare strano sovrascriva qualcosa di più recente, hai verificato e fa davvero così?

Sono di coccio, ma non ho ancora capito se -P si applica a qualsiasi opzione trane il no dither o meno.

Sempre per capire:

Note that most filter types are available only with 44100Hz sample rate.

significa che (come sapevo io) nel caso 'normale' di upsampling da 44100/16 superiori è sempre preferiile NON applicare dithering e, comunque, queste opzioni sono in pratica limitate/inutili?

[UnixMan]

Ma come aggiorni? se lo fai usando l'aggiornamento automatico in LMS è differenziale,

ovviamente no. Se installi LMS con i pacchetti deb, l'aggiornamento automatico è (giustamente) disabilitato. Gli aggiornamenti vengono fatti installando il pacchetto deb della versione aggiornata (che sostituisce il precedente).

Sono di coccio, ma non ho ancora capito se -P si applica a qualsiasi opzione trane il no dither o meno.

Quella ("-p", minuscolo) è una opzione "dell'effetto" dither, ed ovviamente si applica solo a quella (una opzione omonima potrebbe anche esistere in altri contesti ma ovviamente con sintassi, significati ed effetti diversi).

Sempre per capire:
“Note that most filter types are available only with 44100Hz sample rate.”

significa che (come sapevo io) nel caso 'normale' di upsampling da 44100/16 superiori è sempre preferiile NON applicare dithering

assolutamente NO!

Significa solo che (purtroppo...) gli sviluppatori di SOX non hanno pensato al nostro impiego (upsampling) ma solo al caso contrario (downsampling), in particolare per il "mastering" dei CD. Quindi hanno sviluppato soprattutto le opzioni dedicate al formato CDDA (16/44.1), trascurando le altre.

Al contrario, un buon "noise-shaping" sarebbe quanto mai utile e vantaggioso proprio per le nostre applicazioni!

(probabilmente è proprio per quello che HQPlayer risulta vincente: dithering e noise-shaping sono le cose che hanno il maggiore impatto in assoluto sulla qualità percepita... e guarda caso sono anche i fondamenti stessi del "DSD").

e, comunque, queste opzioni sono in pratica limitate/inutili?

Ni.

Purtroppo, per s/r diversi da 44100 non sono (attualmente) disponibili le opzioni di noise shaping (l'opzione generica "-s" nonché i vari filtri selezionabili specificatamente con "-f"). Sono disponibili soltanto TPDF (default) e "sloped TPDF" ("-S").

Scegliendo un filtro diverso ("-f <...>") con s/r non supportati va in fall-back su sloped TPDF (cioè specificare "-f ..." per s/r non supportati è equivalente a specificare "-S").

Comunque, sul mio sistema (con il DAC AK4490), aver aggiunto "dither -S -p 24" (con upsamplig fisso a 384K, VHQ, 90.7% BW, filtro minimum phase, no alias ed uscita a 32bit) ha fatto una differenza a dir poco ABISSALE, dal giorno alla notte. E non certo in peggio...

[marcoc1712]

Quella ("-p", minuscolo) è una opzione "dell'effetto" dither, ed ovviamente si applica solo a quella (una opzione omonima potrebbe anche esistere in altri contesti ma ovviamente con sintassi, significati ed effetti diversi).

Questo lo avevo capito, mi chiedevo se si applica a TUTTE le scelte (-s -S -f) ed a tutti i noise shape type se usi -f o se ci sono 'conrolli incorciati' di esclusione da fare (non tanto nell'interfaccia, quanto nella costruzione della riga di comando).

assolutamente NO!

Significa solo che (purtroppo...) gli sviluppatori di SOX non hanno pensato al nostro impiego (upsampling) ma solo al caso contrario (downsampling), in particolare per il "mastering" dei CD. Quindi hanno sviluppato soprattutto le opzioni dedicate al formato CDDA (16/44.1), trascurando le altre.

Al contrario, un buon "noise-shaping" sarebbe quanto mai utile e vantaggioso proprio per le nostre applicazioni!

(probabilmente è proprio per quello che HQPlayer risulta vincente: dithering e noise-shaping sono le cose che hanno il maggiore impatto in assoluto sulla qualità percepita... e guarda caso sono anche i fondamenti stessi del "DSD").


Ni.

Purtroppo, per s/r diversi da 44100 non sono (attualmente) disponibili le opzioni di noise shaping (l'opzione generica "-s" nonché i vari filtri selezionabili specificatamente con "-f"). Sono disponibili soltanto TPDF (default) e "sloped TPDF" ("-S").

Scegliendo un filtro diverso ("-f <...>") con s/r non supportati va in fall-back su sloped TPDF (cioè specificare "-f ..." per s/r non supportati è equivalente a specificare "-S").

Comunque, sul mio sistema (con il DAC AK4490), aver aggiunto "dither -S -p 24" (con upsamplig fisso a 384K, VHQ, 90.7% BW, filtro minimum phase, no alias ed uscita a 32bit) ha fatto una differenza a dir poco ABISSALE, dal giorno alla notte. E non certo in peggio...

Mi sfugge una cosa,: specificare -p 24 significa richiedere una 'precisione' in uscita di 24bit, se hai un bitdepth a 32, a cosa serve? Probabilmente mi sto perdendo in un biccher d'acqua, ma io sapevo che uscire a 24 (o 32) facendo upsampling, serviva appunto ad evitare (o meglio minimizzare) la perdita di precisione che interviene in corso di conversione e correlate riduzioni di guadagno, filtri,... Se applichi il dithering 'approssimando' a 24 bit che vantaggio ne trai? Capirei perfettamente un -p 32...

[UnixMan]

Questo lo avevo capito, mi chiedevo se si applica a TUTTE le scelte (-s -S -f) ed a tutti i noise shape type se usi -f o se ci sono 'conrolli incorciati' di esclusione da fare (non tanto nell'interfaccia, quanto nella costruzione della riga di comando).

ah, sorry... non avevo capito cos'è che non avevi capito!

Comunque, sì, è applicabile a tutte le possibili scelte. In sostanza indica quale deve essere la "precisione" effettiva prodotta in uscita dall'effetto dither (a prescindere da quello che sarà il "formato" finale in uscita da SOX). Per quanto riguarda la sintassi della riga di comando, a giudicare da quanto scritto nella man page direi che vada eventualmente aggiunto come ultima opzione di dither (e quindi come ultima opzione tout-court nella riga di comando di sox).

Mi sfugge una cosa,: specificare -p 24 significa richiedere una 'precisione' in uscita di 24bit, se hai un bitdepth a 32, a cosa serve? Probabilmente mi sto perdendo in un biccher d'acqua, ma io sapevo che uscire a 24 (o 32) facendo upsampling, serviva appunto ad evitare (o meglio minimizzare) la perdita di precisione che interviene in corso di conversione e correlate riduzioni di guadagno, filtri,... Se applichi il dithering 'approssimando' a 24 bit che vantaggio ne trai?

forse è il caso di spendere due parole su cosa sono, come funzionano e perché si usano dithering e noise-shaping? (non che possa definirmi un esperto in materia, ma posso provare a spiegare meglio che posso quel che ho capito...).

Tornando alle tue domande, credo che la questione verta su tre punti:

1) differenza tra "necessità" ed opportunità/utilità del dithering;

2) differenza tra precisione/risoluzione "nominale" ed "effettiva" dei DAC reali;

3) questioni psicoacustiche (percezione).

Credo che in questo caso il punto cruciale potrebbe essere il secondo: per quanto alcuni DAC moderni hanno una risoluzione "nominale" di 32bit (supportano stream di ingresso con tale precisione), in realtà la loro risoluzione effettiva, reale, è di gran lunga inferiore (è pressoché fisicamente impossibile arrivare a 24bit effettivi, figuriamoci a 32!).

Comunque sia, il punto veramente fondamentale è che... all'ascolto suona nettamente meglio!

Poi ci sono i casi dei vecchi DAC a 14, 18 o 20 bit, la cui risoluzione non corrisponde (mai) al formato dei dati in ingresso all'interfaccia informatica (che è codificata sempre su 16, 24 o 32 bit), nonché anche di quelli a 24 o (più raramente) 16 bit laddove l'interfaccia informatica utilizzi comunque un formato diverso (ad es. 32bit) rispetto a quello nativo del DAC.

In tutti questi casi è ovviamente opportuno applicare il dithering con la precisione corrispondente alla risoluzione effettiva del DAC e non a quella dello stream che va all'interfaccia (e che successivamente viene "troncato" quando arriva al DAC...).

Capirei perfettamente un -p 32...

che infatti è esattamente la prima cosa cui avevo pensato anche io... e che avrei voluto fare salvo che, purtroppo (o forse per fortuna? chissà...), SOX non prevede tale possibilità (non è prevista la possibilità di fare dithering con "precisioni" superiori ai 24bit).

P.S.: in teoria(*) uscire a 32bit aggiungendo "dither -p 24" dovrebbe essere perfettamente equivalente a selezionare il formato di uscita a 24bit: infatti in tal caso SOX aggiunge automaticamente il dithering per passare dai 32bit del formato interno (interamente sfruttati per l'elaborazione del resampling) ai 24bit di uscita.

Però in tal caso viene utilizzato il default, cioè il TPDF semplice (non-sloped), mentre è preferibile utilizzare (quanto meno, in mancanza di meglio) la versione "sloped" ("-S"), quindi anche in questo caso (cioè, uscendo a <32bit) è meglio richiedere esplicitamente il dithering con le opzioni desiderate (NB: se viene richiesto esplicitamente, SOX non lo aggiunge in automatico... non c'è il rischio che venga applicato due volte).

(*) dico "in teoria" perché poi bisognerebbe vedere come questi 24bit vengano successivamente "rimappati" sui 32 che di solito sono richiesti dall'interfaccia al DAC e quindi anche dal corrispondente "raw device" di ALSA; uscendo direttamente a 32bit da SOX (ed utilizzando "dither -p XX") si dovrebbe avere la certezza che questi siano mappati "in cima" (nei 24 bit più significativi).

[marcoc1712]

ah, sorry... non avevo capito cos'è che non avevi capito!

Comunque, sì, è applicabile a tutte le possibili scelte. In sostanza indica quale deve essere la "precisione" effettiva prodotta in uscita dall'effetto dither (a prescindere da quello che sarà il "formato" finale in uscita da SOX). Per quanto riguarda la sintassi della riga di comando, a giudicare da quanto scritto nella man page direi che vada eventualmente aggiunto come ultima opzione di dither (e quindi come ultima opzione tout-court nella riga di comando di sox).

OK

forse è il caso di spendere due parole su cosa sono, come funzionano e perché si usano dithering e noise-shaping? (non che possa definirmi un esperto in materia, ma posso provare a spiegare meglio che posso quel che ho capito...).

Tornando alle tue domande, credo che la questione verta su tre punti:

1) differenza tra "necessità" ed opportunità/utilità del dithering;

2) differenza tra precisione/risoluzione "nominale" ed "effettiva" dei DAC reali;

3) questioni psicoacustiche (percezione).

Credo che in questo caso il punto cruciale potrebbe essere il secondo: per quanto alcuni DAC moderni hanno una risoluzione "nominale" di 32bit (supportano stream di ingresso con tale precisione), in realtà la loro risoluzione effettiva, reale, è di gran lunga inferiore (è pressoché fisicamente impossibile arrivare a 24bit effettivi, figuriamoci a 32!).

Questo non lo sapevo ed è il pezzo che mi mancava, se è così capisco.

Comunque sia, il punto veramente fondamentale è che... all'ascolto suona nettamente meglio!

Poi ci sono i casi dei vecchi DAC a 14, 18 o 20 bit, la cui risoluzione non corrisponde (mai) al formato dei dati in ingresso all'interfaccia informatica (che è codificata sempre su 16, 24 o 32 bit), nonché anche di quelli a 24 o (più raramente) 16 bit laddove l'interfaccia informatica utilizzi comunque un formato diverso (ad es. 32bit) rispetto a quello nativo del DAC.

In tutti questi casi è ovviamente opportuno applicare il dithering con la precisione corrispondente alla risoluzione effettiva del DAC e non a quella dello stream che va all'interfaccia (e che successivamente viene "troncato" quando arriva al DAC...).

Non fa una piega.

(*) dico "in teoria" perché poi bisognerebbe vedere come questi 24bit vengano successivamente "rimappati" sui 32 che di solito sono richiesti dall'interfaccia al DAC e quindi anche dal corrispondente "raw device" di ALSA; uscendo direttamente a 32bit da SOX (ed utilizzando "dither -p XX") si dovrebbe avere la certezza che questi siano mappati "in cima" (nei 24 bit più significativi).

Direi proprio di sì, altrimenti non ascolteremmo più o meno bene, ma proprio un'altra cosa, con ogni probabilità molto simile al rumore bianco, come aspettarsi di ricevere 1000.0091 Euro e riceverne 1000.00 nel primo caso o 00.0091 nel secondo. Il"-p 6" (nell'esempio) te ne fa ricevere 1000.01...

[UnixMan]

Direi proprio di sì, altrimenti non ascolteremmo più o meno bene, ma proprio un'altra cosa, con ogni probabilità molto simile al rumore bianco, come aspettarsi di ricevere 1000.0091 Euro e riceverne 1000.00 nel primo caso o 00.0091 nel secondo. Il"-p 6" (nell'esempio) te ne fa ricevere 1000.01...

ehm... NO. Mai sentito parlare di controlli di volume digitali? L'effetto di uno "shift" dei bit all'interno di una parola (che codifica un campione PCM sotto forma di numero intero) è esattamente quello...

...se "shifti" 24 bit di dati effettivi (gli altri sono a zero) all'interno di una parola di 32 (senza "sconfinare") non c'è alcuna perdita di informazione e, con un DAC che (teoricamente) utilizza tutti e 32 i bit otterresti (nominalmente...) un controllo di volume digitale perfettamente "lossless".

[marcoc1712]

ehm... NO. Mai sentito parlare di controlli di volume digitali? L'effetto di uno "shift" dei bit all'interno di una parola (che codifica un campione PCM sotto forma di numero intero) è esattamente quello...

Certo che puoi fare <<, ma nel farlo devi assicurarti di non perdere il valore più significativo (i moderni compilatori avvisano), altrimenti succede ESATTAMENTE quello che ho descritto, solo che avviene in valori binari e non decimali, ma il risultato non cambia.

Se hai un registro a 8 bit contenenti 01000001 e fai left shift ottieni : 10000010 e va bene, ma se lo ripeti ottieni 00000100 e non va bene...
l'operazione contraria è sempre lossy, ma con effetti molto più moderati (se provi a ripristinare, capisci perchè).

Motivo per cui passando da 24 a 32 si passsa da 00000000 00000000 00000001 a 00000000 00000000 00000001 0000000 e viceversa.

[UnixMan]

Certo che puoi fare <<, ma nel farlo devi assicurarti di non perdere il valore più significativo [...]

Ovvio.

Ma, dato che parlavamo semplicemente della possibilità che un software ha di "mappare" (o, se preferisci, "allineare") diversamente i 24 bit "in ingresso" su una parola di 32 (ovviamente senza errori, quindi senza "sconfinamenti"), ad esempio (nel caso di una codifica "unsigned") scrivendo i 24 bit partendo "dal basso" e mettendo a zero gli ultimi 8bit o viceversa mettendo a zero i primi 8bit e poi inserendo i 24bit di dati, oppure ancora mettendo 4bit a zero, poi i 24bit di dati ed infine altri 4bit a zero, ecc, questo problema non era neanche in questione.

[UnixMan]

Se non mi mandi a farmi un giro, ci sarebbero un altro paio di cosette... altro lavoro per te.

1) una banalità, che potrebbe tornare utile: aggiungere un filtro subsonico tramite l'effetto "highpass" di SOX.

highpass|lowpass [-1|-2] frequency[k] [width[q|o|h|k]]
Apply a high-pass or low-pass filter with 3dB point frequency. The filter can be either single-pole (with -1), or double-pole (the default, or with -2). width applies only to double-pole filters; the default is Q = 0.707 and gives a Butterworth response. The filters roll off at 6dB per pole per octave (20dB per pole per decade).

In pratica si tratterebbe di aggiungere uno "slider", ad es. da 0 a 20 (o anche più); su "0" il filtro è disabilitato (non aggiungi niente alla riga di comando di sox), mentre per valori > 0 aggiungi "highpass n", dove "n" è il valore selezionato (frequenza di taglio in Hz), alla riga di comando di SOX (conviene aggiungerla prima del resampling, ma dopo "gain").

2) questo invece è molto più interessante: ho "scoperto" l'effetto "trim", che potrebbe essere utilizzato per la gestione dei "cue sheet" (cioè, del "seek") direttamente da SOX, senza dover passare per flac o altro! (...per tutti gli innumerevoli formati supportati direttamente da SOX)

trim {[=|-]position}
Cuts portions out of the audio. Any number of positions may be given; audio is not sent to the output until the first position is reached. The effect then alternates between copying and discarding audio at each position.
If a position is preceded by an equals or minus sign, it is interpreted relative to the beginning or the end of the audio, respectively. (The audio length must be known for end-relative locations to work.) Otherwise, it is considered an offset from the last position, or from the start of audio for the first parameter.
Using a value of 0 for the first position parameter allows copying from the beginning of the audio.

All parameters can be specified using either an amount of time or an exact count of samples. The format for specifying lengths in time is hh:mm:ss.frac. A value of 1:30.5 for the first parameter will not start until 1 minute, thirty and ½ seconds into the audio. The format for specifying sample counts is the number of samples with the letter `s' appended to it. A value of 8000s for the first parameter will wait until 8000 samples are read before starting to process audio.

For example,
sox infile outfile trim 0 10
will copy the first ten seconds, while
play infile trim 12:34 =15:00 -2:00
will play from 12 minutes 34 seconds into the audio up to 15 minutes into the audio (i.e. 2 minutes and 26 seconds long), then resume playing two minutes before the end of audio.

In altre parole, se ad es. vuoi cominciare a suonare un brano a partire da 1:30 (un minuto e mezzo dall'inizio), basta dare il comando:

play file_audio trim 1:30

("play" è sempre sox).

Quindi, nel caso di C-3PO, ti basta aggiungere "trim" (come primo effetto, subito dopo la dichiarazione dei files in e out), fornirgli il "tempo" da cui vuoi far (ri)partire la riproduzione (in uno dei formati supportati) ed il gioco è fatto!


Edit: prevengo l'eventuale domanda: no, sox non "aspetta" in silenzio per tutto il tempo specificato, salta "immediatamente" alla posizione richiesta (quindi è perfetto per quello che ci serve).

[marcoc1712]

Se non mi mandi a farmi un giro, ci sarebbero un altro paio di cosette... altro lavoro per te.

1) una banalità, che potrebbe tornare utile: aggiungere un filtro subsonico tramite l'effetto "highpass" di SOX.



In pratica si tratterebbe di aggiungere uno "slider", ad es. da 0 a 20 (o anche più); su "0" il filtro è disabilitato (non aggiungi niente alla riga di comando di sox), mentre per valori > 0 aggiungi "highpass n", dove "n" è il valore selezionato (frequenza di taglio in Hz), alla riga di comando di SOX (conviene aggiungerla prima del resampling, ma dopo "gain").

2) questo invece è molto più interessante: ho "scoperto" l'effetto "trim", che potrebbe essere utilizzato per la gestione dei "cue sheet" (cioè, del "seek") direttamente da SOX, senza dover passare per flac o altro! (...per tutti gli innumerevoli formati supportati direttamente da SOX)



In altre parole, se ad es. vuoi cominciare a suonare un brano a partire da 1:30 (un minuto e mezzo dall'inizio), basta dare il comando:

play file_audio trim 1:30

("play" è sempre sox).

Quindi, nel caso di C-3PO, ti basta aggiungere "trim" (come primo effetto, subito dopo la dichiarazione dei files in e out), fornirgli il "tempo" da cui vuoi far (ri)partire la riproduzione (in uno dei formati supportati) ed il gioco è fatto!


Edit: prevengo l'eventuale domanda: no, sox non "aspetta" in silenzio per tutto il tempo specificato, salta "immediatamente" alla posizione richiesta (quindi è perfetto per quello che ci serve).

trim è interessante, sicuramente da provare.

Per le varie richieste, continua pure a segnalare, ma tieni presente che io sono un 'animale' stagionale, con la bella stagione cambiano completamente gli hobiies, direi che se ne riparla a settembre...