ANNUNCIO: C-3PO 1.0.10 rilasciato in beta

[marcoc1712]

Ciao,

una nuova versione di C-3PO è disponibile in beta.

Per utilizzarla è necessario cambiare l'indirizzo del repository in plugin manager: http://www.marcoc1712.it/downloads/repository_beta.xml

E' nata per coreggere alcune impostazini per ALAC, ma è evoluta in una completa riscrittura della sezione di conversione. Non cambia nulla nelle impostazioni e nell'utilizzo, ma alcune combinazioni vengono rese in modo diverso, cercando di evitare il più possibile catene che possono provocare errori o situazioni di 'congestione'.

L'utilizzo di FFMPEG risulta ampliato e quello di FLAC ulteiromente diminuito, mentre ho introdotto una prima 'ottimizzazione' nel buffer di SOX, mirata a scongiurare il rischio di interruzioni occasionali nel flusso, specie quando usato in 'pipe' con flac, ffmpeg o faad.

Ho cercato di ondurre tutti i test di regressione e più di 200 sono andati a buon fine, ma ormai le combinazioni di parametris ono talmente tante che avere la certezza su tutto è imposibile, lascerò quindi 'sedimentare' questa versione in beta prima di promuoverla per l'utilizzo generale.

Vi prego di segnalare qualsiasi errore o malfunzionamento.

EDIT: per favore segnalate anche se la avete provata con esito positivo ed in quali combinazioni, così da sapere quando potrò considerarla stabile.

Grazie.


Grazie.

[marcoc1712]

Ho trovato io steso un 'baco' reintrodotto rispetto alla versione precedente, nella 'foga' della semplificazione.

Almeno in windows Qobuz intrfacciato direttamente con SOX non funziona con le playlist, cioè non è possibile selezionare un album e mandarlo in esecuzione gapeless, nella precedente versione interponevo flac, da verificare se funziona anche con FFMPEG.

Corrego e rilascio una nuova versione, sempre in beta.

[marcoc1712]

Rilasciata in beta la versione 1.0.11.

[UnixMan]

una nuova versione di C-3PO è disponibile in beta.

installata.

L'utilizzo di FFMPEG risulta ampliato e quello di FLAC ulteiromente diminuito, mentre ho introdotto una prima 'ottimizzazione' nel buffer di SOX, mirata a scongiurare il rischio di interruzioni occasionali nel flusso, specie quando usato in 'pipe' con flac, ffmpeg o faad.
[...]
Vi prego di segnalare qualsiasi errore o malfunzionamento.

nel mio caso pare funzionare bene; ho provato ad abilitare i "cue" (per poter scorrere nel brano): continua ad utilizzare flac+sox, non ffmpeg+sox. È previsto così?

BTW: lo sai vero che puoi utilizzare direttamente (solo) ffmpeg anche per fare resampling? (usa libsox internamente).

Un'altra cosa che volevo dirti: sarebbe simpatico aggiungere alle opzioni di sox una più ampia possibilità di configurazione del dithering (dither "-s" o "-S", oppure -f ..., ecc), vedi: SoX - Sound eXchange | NoiseShaping

Purtroppo attualmente il noise-shaping è supportato solo per stream di uscita a 44.1K, quindi per i nostri scopi sfortunatamente non è quasi mai applicabile. Sarebbe da chiedere agli sviluppatori di implementarlo anche per s/r maggiori: all'ascolto la differenza tra un semplice dithering TPDF ed e.g. un noise-shaping "shibata" è notevolissima...

[marcoc1712]

installata.

nel mio caso pare funzionare bene; ho provato ad abilitare i "cue" (per poter scorrere nel brano): continua ad utilizzare flac+sox, non ffmpeg+sox. È previsto così?

Dipende dall'input, con FLAC si. Chi meglio di Flac può fare il decoding di flac?

BTW: lo sai vero che puoi utilizzare direttamente (solo) ffmpeg anche per fare resampling? (usa libsox internamente).

Si. ma una delle cose che - ricordo - mossero a C-3PO era l'utilizzo di SOX e non di libsox, io sostenevo (e sostengo) che sarebbe incomprensibile che SOX al suo interno non usi libSOX, ma altri sostenevano il contrario.

Un'altra cosa che volevo dirti: sarebbe simpatico aggiungere alle opzioni di sox una più ampia possibilità di configurazione del dithering (dither "-s" o "-S", oppure -f ..., ecc), vedi: SoX - Sound eXchange | NoiseShaping

Purtroppo attualmente il noise-shaping è supportato solo per stream di uscita a 44.1K, quindi per i nostri scopi sfortunatamente non è quasi mai applicabile. Sarebbe da chiedere agli sviluppatori di implementarlo anche per s/r maggiori: all'ascolto la differenza tra un semplice dithering TPDF ed e.g. un noise-shaping "shibata" è notevolissima...

[/QUOTE]

Tutte cose che varrebbe al pena (insieme ad altre) aggiungere a C-3PO mediante opportuna parametrizzazione., ma ci sono tre aspetti:

a. tempo
b. complessità ed onerosità dei test.
c. complessità dell'interfaccia utente risultante (so che non te ne curi, ma c'è...).

il punto c. richiede 'solo' una corretta progettazione e relizzazione, quindi una preventiva conoscenza delle possibilità e dei casi d'uso, che non ho pienamente, ma si tratta di raccogliere le idee, sempre disponibile ad approfondire compatibilmente con a.

Il vero problema è b. Attualmente ho disegnato 200 casi di test che coprono solo una parte dei casi reali di utilizzo. E' totalmente escluso ALAC e tutte le modalità che non fanno uso di C-3PO ma direttamente di LMS, che sono la maggioranza e comunque NON coprono tutte le combinazioni di parametri, ma solo dei 'meta' casi.

Es. Ci sono diverse combinazioni di parametri che portano ad escludere il resampling anche se è richiesto, ai fini del test ho semplificato: testo resampling si o resampling no, indipendentemente da come il si ed il no vengono originati.

le 'meta' variabili sono:

a. splitting (cue) si/no
b. resampling si/no
d. massima/sincrona
e. sempre/eccezione
c. ffmpeg installato si/no
d. in codec
e. out codec + flac compresso si/no (non testo i valori di compressione, solo richiesta/non richiesta).

2*2*2*2*2*4*4 = 1024

Escludendo i singoli 'valori' dei parametri, il che comporta qui un'enorme semplificazione, ma di contro la necessità di 'validarli' singolarmente e manualmente.

La combinazione di questi 'meta' casi origina 1024 casi specifici, per ognuno dei quali viene generata una riga di comando che una volta provata e validata registro come 'termine di confronto', dopo di che tutte le volte che rilascio lancio l'esecuzione dei test e verifico solo le difformità, ma testare quelle 824 combinazioni mancanti è un lavoraccio. Se aggiungo un parametro binario, un nuovo codec in ingresso o in uscita, raddoppio i casi di test, ogni volta che aggiungo qualcosa alla riga di comando devo rivedere i 'metacasi' (semplice) ma anche tutte le righe 'riscontro' (lungo e noioso). O trovo il modo per automatizzare anche la generazione e validazione dei test o questo diventa un impedimento forte per le future evoluzioni.

Ci sto lavorando, ma non è semplice. Qui qualsiasi esperienza/suggerimento è bene accetto, il punto è che LMS non ha mecanismi diagnostici per validare le righe, semplicemte suona o no, ...testarlo da programma è difficile, mentre realizzare un 'compilatore' sarebbe un reverse di quello che fa C-3PO, non è significativo, la verità è che almeno una volta la singola combinazione va provata.

[UnixMan]

Dipende dall'input, con FLAC si. Chi meglio di Flac può fare il decoding di flac?

in teoria, nessuno. Per altro, tutti (incluso flac) usano la libflac, quindi dovrebbe essere esattamente la stessa cosa.

Ma non eri tu (ricordo male?) che dicevi che -per motivi imperscrutabili- flac+sox suonano peggio di sox da solo? Se è così, potrebbe valere la pena di provare a vedere come si comportano (all'ascolto...) ffmpeg+sox ed ffmpeg da solo (facendo fare a lui anche l'eventuale upsampling).

Si. ma una delle cose che - ricordo - mossero a C-3PO era l'utilizzo di SOX e non di libsox, io sostenevo (e sostengo) che sarebbe incomprensibile che SOX al suo interno non usi libSOX, ma altri sostenevano il contrario.

Sox usa libsox, su questo non ci piove.

$ apt-cache show sox
Package: sox
Version: 14.4.1-5
Installed-Size: 224
Maintainer: Pascal Giard <pascal@debian.org>
Architecture: amd64
Depends: libsox-fmt-alsa (= 14.4.1-5) | libsox-fmt-ao (= 14.4.1-5) | libsox-fmt-oss (= 14.4.1-5) | libsox-fmt-pulse (= 14.4.1-5), libsox-fmt-base (= 14.4.1-5), libsox2 (= 14.4.1-5), libc6 (>= 2.15), libgomp1 (>= 4.2.1)
Suggests: libsox-fmt-all
Description-en: Swiss army knife of sound processing
...

nonché:

$ ldd /usr/bin/sox
linux-vdso.so.1 (0x00007ffdb7cbf000)
libsox.so.2 => /usr/lib/x86_64-linux-gnu/libsox.so.2 (0x00007f27d773e000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f27d743d000)
libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007f27d7226000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f27d7009000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f27d6c5e000)
libltdl.so.7 => /usr/lib/x86_64-linux-gnu/libltdl.so.7 (0x00007f27d6a53000)
libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007f27d682c000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f27d6611000)
libmagic.so.1 => /usr/lib/x86_64-linux-gnu/libmagic.so.1 (0x00007f27d63f0000)
libgsm.so.1 => /usr/lib/x86_64-linux-gnu/libgsm.so.1 (0x00007f27d61e3000)
/lib64/ld-linux-x86-64.so.2 (0x00005607ca177000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f27d5fde000)

inoltre:

$ ls -lahF /usr/bin/sox /usr/lib/x86_64-linux-gnu/libsox.so.2.0.1
-rwxr-xr-x 1 root root 68K Dec 24 2014 /usr/bin/sox*
-rw-r--r-- 1 root root 603K Dec 24 2014 /usr/lib/x86_64-linux-gnu/libsox.so.2.0.1

...ma, quello che taglia la testa al toro:

https://sourceforge.net/p/sox/code/ci/master/tree/

https://sourceforge.net/p/sox/code/c...tree/src/sox.h
https://sourceforge.net/p/sox/code/c...tree/src/sox.c

BTW, se ben ricordo, la questione non era tra sox e libsox, ma tra sox e libsoxr:

https://sourceforge.net/p/soxr/code/ci/master/tree/

In pratica libsoxr (Lib SOX Resampling) è uno "spin-off" di libsox, una sua versione "alleggerita", epurata di tutto tranne che degli algoritmi di resampling (contiene solo quelli).

In teoria (e per ovvi motivi) dovrebbe essere basata sullo stesso codice, quindi usare sox (libsox) o libsoxr non dovrebbe fare alcuna differenza. Però, se non ricordo male, fui proprio io a notare che, a parità di "impostazioni", l'upsampling fatto con libsoxr (ad es. da squeezelite, o da MPD) sembra utilizzare sensibilmente meno risorse (CPU) che non facendolo con sox.

A livello di qualità sonora non mi esprimo (in condizioni comparabili ed a parità di impostazioni non mi pare di aver notato differenze significative tra l'uno e l'altro... però non ci metterei la mano sul fuoco).

P.S.: però c'è qualcosa che non mi torna. Avevo letto (IIRC nella documentazione di MinimServer) che ffmpeg usa (può usare?) libsox (o libsoxr?) per fare resampling ma, da un veloce indagine sul mio sistema, in ffmpeg non ho trovato traccia di dipendenze verso libsox né libsoxr. Boh.

c. complessità dell'interfaccia utente risultante (so che non te ne curi, ma c'è...).

per inciso: devi avermi frainteso. È vero che in generale amo poco GUI ed interfacce web e che di solito / per molte applicazioni gli preferisco di gran lunga una buona CLI, ma questo non vuol dire affatto che "non me ne curo". Al contrario: la "qualità" (in termini di praticità, funzionalità, ergonomia, ecc) dell'interfaccia utente (che sia GUI, CLI o altro) è fondamentale.

Per altro, qui stiamo parlando di qualcosa che vede proprio nell'interfaccia utente una delle sue principali raison d'être, quindi è ovvio che la cosa ha la sua importanza.

Il vero problema è b. Attualmente ho disegnato 200 casi di test [...] 2*2*2*2*2*4*4 = 1024 [...]

auguri. :-)

Comunque, quello che intendevo non è nulla di complicato. Si tratterebbe di sostituire una checkbox, quella relativa al "Dithering" (che -se non ho visto male- attualmente controlla solo l'eventuale l'aggiunta dell'opzione "-D" alias "--no-dither") con un menù a tendina dove scegliere:

1) default/auto (nessuna opzione aggiunta)
2) disable dithering (aggiunge "--no-dither", come l'attuale checkbox)
3) manual setup

se viene selezionata quest'ultima opzione devono apparire / essere abilitati altri due menù:

Dithering type:
1) default/TPDF (aggiunge soltanto "dither")
2) sloped TPDF (aggiunge "dither -S")
3) noise-shaped (aggiunge "dither -s")
4) lipshitz (aggiunge "dither -f lipshitz")
5) f-weighted (aggiunge "dither -f f-weighted")
... ecc.
(lipshitz, f-weighted, modified-e-weighted, improved-e-weighted, gesemann, shibata, low-shibata, high-shibata).

dithering to (precision, target bit-depth):
1) default
2) 16
3) 18
4) 20
5) 24
6) 32

che, tranne nel primo caso (in cui non fa nulla) aggiunge l'opzione "-p <valore selezionato>". Questo è particolarmente utile specie con alcuni vecchi DAC che hanno risoluzioni di 18 o 20 bit (ma potrebbe essere utile/vantaggioso usarlo anche in altri casi).

N.B.: "l'effetto" dither (seguito dalle sue eventuali opzioni) va aggiunto sempre per ultimo, in fondo alla riga di comando di sox.

P.S.: avere i menù dedicati rende tutto più comodo, ma si può "giocare" con il dithering anche con la versione attuale di C-3PO, sfruttando la comodissima opzione "Additional effects (sperimental)"(*). Basta scrivere nella apposita casella "dither", oppure "dither -S", "dither -f shibata", ecc, ecc.

Provate (e con diverse opzioni): il risultato potrebbe stupirvi!

(*) A proposito di quella opzione: è troppo utile, non toglierla! (però, se aggiungi le opzioni di dithering, ricordati di fare in modo che quanto scritto nella relativa casella sia inserito prima di quelle). Ah, c'è un piccolo "bug": "sperimentale" si scrive "experimental", non "sperimental".

Altra cosa che dovreste provare (ma qui abbandoniamo le semplici ottimizzazioni per entrare nel campo minato del DSP vero e proprio...) è "contrast". Aggiungetelo nella casella (prima di dither, se mettete anche quello), seguito da un numero compreso tra 0 e 100, ad es.:

contrast 0 dither -f shibata

Provate e fatemi sapere...

[marcoc1712]

in teoria, nessuno. Per altro, tutti (incluso flac) usano la libflac, quindi dovrebbe essere esattamente la stessa cosa.

Ma non eri tu (ricordo male?) che dicevi che -per motivi imperscrutabili- flac+sox suonano peggio di sox da solo? Se è così, potrebbe valere la pena di provare a vedere come si comportano (all'ascolto...) ffmpeg+sox ed ffmpeg da solo (facendo fare a lui anche l'eventuale upsampling).


Sox usa libsox, su questo non ci piove.

nonché:

inoltre:

...ma, quello che taglia la testa al toro:

https://sourceforge.net/p/sox/code/ci/master/tree/

https://sourceforge.net/p/sox/code/c...tree/src/sox.h
https://sourceforge.net/p/sox/code/c...tree/src/sox.c

BTW, se ben ricordo, la questione non era tra sox e libsox, ma tra sox e libsoxr:

https://sourceforge.net/p/soxr/code/ci/master/tree/

In pratica libsoxr (Lib SOX Resampling) è uno "spin-off" di libsox, una sua versione "alleggerita", epurata di tutto tranne che degli algoritmi di resampling (contiene solo quelli).

In teoria (e per ovvi motivi) dovrebbe essere basata sullo stesso codice, quindi usare sox (libsox) o libsoxr non dovrebbe fare alcuna differenza. Però, se non ricordo male, fui proprio io a notare che, a parità di "impostazioni", l'upsampling fatto con libsoxr (ad es. da squeezelite, o da MPD) sembra utilizzare sensibilmente meno risorse (CPU) che non facendolo con sox.

A livello di qualità sonora non mi esprimo (in condizioni comparabili ed a parità di impostazioni non mi pare di aver notato differenze significative tra l'uno e l'altro... però non ci metterei la mano sul fuoco)....

Hai ragione, mi sono confuso io, si trattava di libsoxr, ma mi riferivo a questa, non a libsox. Continuo a pensare che sia una follia avere e manutenere sia la libreia che il codicie in sox, ma tant'è.

P.S.: però c'è qualcosa che non mi torna. Avevo letto (IIRC nella documentazione di MinimServer) che ffmpeg usa (può usare?) libsox (o libsoxr?) per fare resampling ma, da un veloce indagine sul mio sistema, in ffmpeg non ho trovato traccia di dipendenze verso libsox né libsoxr. Boh..

.

Nei sorgenti e negli include di FFMPEG NON usa lisox o libsoxr ma libwresample.

Comunque, quello che intendevo non è nulla di complicato. Si tratterebbe di sostituire una checkbox, quella relativa al "Dithering" (che -se non ho visto male- attualmente controlla solo l'eventuale l'aggiunta dell'opzione "-D" alias "--no-dither") con un menù a tendina dove scegliere:

1) default/auto (nessuna opzione aggiunta)
2) disable dithering (aggiunge "--no-dither", come l'attuale checkbox)
3) manual setup

se viene selezionata quest'ultima opzione devono apparire / essere abilitati altri due menù:

Dithering type:
1) default/TPDF (aggiunge soltanto "dither")
2) sloped TPDF (aggiunge "dither -S")
3) noise-shaped (aggiunge "dither -s")
4) lipshitz (aggiunge "dither -f lipshitz")
5) f-weighted (aggiunge "dither -f f-weighted")
... ecc.
(lipshitz, f-weighted, modified-e-weighted, improved-e-weighted, gesemann, shibata, low-shibata, high-shibata).

dithering to (precision, target bit-depth):
1) default
2) 16
3) 18
4) 20
5) 24
6) 32

che, tranne nel primo caso (in cui non fa nulla) aggiunge l'opzione "-p <valore selezionato>". Questo è particolarmente utile specie con alcuni vecchi DAC che hanno risoluzioni di 18 o 20 bit (ma potrebbe essere utile/vantaggioso usarlo anche in altri casi).

N.B.: "l'effetto" dither (seguito dalle sue eventuali opzioni) va aggiunto sempre per ultimo, in fondo alla riga di comando di sox..

Grazie per le precise indicazioni, non appena riesco vedo quello che riesco a fare senza scardinare tutto.

P.S.: avere i menù dedicati rende tutto più comodo, ma si può "giocare" con il dithering anche con la versione attuale di C-3PO, sfruttando la comodissima opzione "Additional effects (sperimental)"(*). Basta scrivere nella apposita casella "dither", oppure "dither -S", "dither -f shibata", ecc, ecc.

Provate (e con diverse opzioni): il risultato potrebbe stupirvi!

(*) A proposito di quella opzione: è troppo utile, non toglierla! (però, se aggiungi le opzioni di dithering, ricordati di fare in modo che quanto scritto nella relativa casella sia inserito prima di quelle). Ah, c'è un piccolo "bug": "sperimentale" si scrive "experimental", non "sperimental".

Altra cosa che dovreste provare (ma qui abbandoniamo le semplici ottimizzazioni per entrare nel campo minato del DSP vero e proprio...) è "contrast". Aggiungetelo nella casella (prima di dither, se mettete anche quello), seguito da un numero compreso tra 0 e 100, ad es.:

contrast 0 dither -f shibata

Provate e fatemi sapere...

Il maccheronico... lo correggo, lo avevo già in programma da 3 releases, ma mi sono sempre dimenticato....

Se 'apri' al DSP non ci sono limiti, io già uso il renix per 'limare' il balance con ottimi risultati, ho provato il loudness (al posto del gain) e se ascolti a basso volume aiuta. C-3PO è e rimarra limitato in merito, ma per DSP 'evoluto' e DRC c'è Inguz plugin.

[UnixMan]

note ed errata corrige:

1) avevo fatto le prove con sox da riga di comando (utilizzando quello fornito dalla distribuzione) e, quando ho provato ad utilizzare "-p XX" da C-3PO, ho avuto la brutta sorpresa di constatare che... non funzionava più nulla. Da una rapida verifica è uscito fuori che LMS stava utilizzando la "sua" copia di SOX, che (almeno nella versione che ho io) risulta essere meno recente rispetto a quella fornita da Debian Jessie (v14.3.1 vs. v14.4.1) e, incidentalmente, non supporta l'opzione "-p" di dither.

Pertanto, per poter utilizzare l'opzione "-p" è necessario assicurarsi di avere (e far usare ad LMS) una versione aggiornata di SOX(*).

2) sempre a proposito di "-p", ho notato che questa non accetta valori superiori a 24 (bit), quindi rispetto a quanto scritto nel post precedente il valore max deve essere 24 e non 32.

3) mi ero poi dimenticato che sono ancora diffusi ed apprezzati anche i vecchi 1540, che sono a 14bit...

4) anziché utilizzare un menù a tendina, per il parametro di "-p" penso convenga utilizzare invece uno "slider" che permetta di settare qualsiasi valore intero compreso tra 12 e 24. Serve però sempre un modo per dirgli di non includere affatto l'opzione "-p", ad es. una checkbox che abilita/disabilita lo slider (e quindi l'aggiunta di "-p XX").


(*) Marco, come si fa a dire ad LMS di utilizzare i software "di sistema" anziché quelli che include lui? Ieri ho risolto brutalmente cancellando la directory "/usr/share/squeezeboxserver/Bin"... ma è un metodo barbaro, e per giunta bisogna ricordarsi di farlo ogni volta che si aggiorna (il pacchetto di) LMS. Non c'è un modo (=configurazione) per cambiare l'ordine nel suo "path" di ricerca dei binari, in modo da fargli "preferire" quelli di sistema?

[marcoc1712]

note ed errata corrige:

1) avevo fatto le prove con sox da riga di comando (utilizzando quello fornito dalla distribuzione) e, quando ho provato ad utilizzare "-p XX" da C-3PO, ho avuto la brutta sorpresa di constatare che... non funzionava più nulla. Da una rapida verifica è uscito fuori che LMS stava utilizzando la "sua" copia di SOX, che (almeno nella versione che ho io) risulta essere meno recente rispetto a quella fornita da Debian Jessie (v14.3.1 vs. v14.4.1) e, incidentalmente, non supporta l'opzione "-p" di dither.

Pertanto, per poter utilizzare l'opzione "-p" è necessario assicurarsi di avere (e far usare ad LMS) una versione aggiornata di SOX(*).

(*) Marco, come si fa a dire ad LMS di utilizzare i software "di sistema" anziché quelli che include lui? Ieri ho risolto brutalmente cancellando la directory "/usr/share/squeezeboxserver/Bin"... ma è un metodo barbaro, e per giunta bisogna ricordarsi di farlo ogni volta che si aggiorna (il pacchetto di) LMS. Non c'è un modo (=configurazione) per cambiare l'ordine nel suo "path" di ricerca dei binari, in modo da fargli "preferire" quelli di sistema?

La risposta breve è: non c'è modo, ed occhio che le versioni distribuite spesso sono 'speciali per' LMS, non vorrei che poi non funzionasse più qualcos'altro, bisognerebbe testare BENE tutto.


la 'catena' di ricerca è questa.

plugin/Bin
Server/Bin
path

Puoi provare a:

1. Non cancellare la directory, bensì sostituire SOX. Non sono certo - bisogna provare - ma secondo me se metti una versione più recente di SOX nella cartella Bin del server NON la sostituisce agli upgrade (nel caso, forse basta un symlink), se lo cancelli solo, ovviamente si.

2. Volendo, potresti scaricare in C-3PO/Bin (o in altro plugin) la versione di SOX da usare, ma non sono certo che la userebbe quando C-3PO crea solo il comando poi esguito da LMS.

3. In windows (ma non so in Linux) la cosa più semplice è nominare il nuovo SOX come 'sox2' o simile ed usare quello nelle catene di conversione, prealtro salvaguardando così gli altri usi. Puoi usare anche un alias/symlink. Bisogna comunque mettere mano a C-3PO per dirgli di usare SOX2.

Patchare LMS per cambiare la catena di ricerca degli eseguibil non è proponibile, troppo invasivo ed oneroso da testare e mantenere.

note ed errata corrige:
4) anziché utilizzare un menù a tendina, per il parametro di "-p" penso convenga utilizzare invece uno "slider" che permetta di settare qualsiasi valore intero compreso tra 12 e 24. Serve però sempre un modo per dirgli di non includere affatto l'opzione "-p", ad es. una checkbox che abilita/disabilita lo slider (e quindi l'aggiunta di "-p XX").

Per rendere due settaggi interdipendenti serve JS, che nelle form di LMS non è abilitato a standard, puoi farlo ma si complica non poco, l'alternativa (v. show/hide o usa parametri generali) è obbligare il salvataggio ad ogni cambiamento con apposito pulsante, in questo caso - credo - inadeguato.

In casi come questi, meglio una tendina con valore 'nessuno' come default, mettendo una breve descrizione significativa (che io non so), risulta molto più semplice anche la logica seguente.

NOn ci h ancora guardato, ma non è possibile 'accorpare' la prima e la seconda tendina? o sono 3 opzioni nominate separatamente?

[UnixMan]

La risposta breve è: non c'è modo, ed occhio che le versioni distribuite spesso sono 'speciali per' LMS, non vorrei che poi non funzionasse più qualcos'altro, bisognerebbe testare BENE tutto.

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...

1. Non cancellare la directory, bensì sostituire SOX. Non sono certo - bisogna provare - ma secondo me se metti una versione più recente di SOX nella cartella Bin del server NON la sostituisce agli upgrade (nel caso, forse basta un symlink),

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

Patchare LMS per cambiare la catena di ricerca degli eseguibil non è proponibile, troppo invasivo ed oneroso da testare e mantenere.

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

Per rendere due settaggi interdipendenti serve JS, che nelle form di LMS non è abilitato a standard, puoi farlo ma si complica non poco, l'alternativa (v. show/hide o usa parametri generali) è obbligare il salvataggio ad ogni cambiamento con apposito pulsante, in questo caso - credo - inadeguato.

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...

In casi come questi, meglio una tendina con valore 'nessuno' come default, mettendo una breve descrizione significativa (che io non so), risulta molto più semplice anche la logica seguente.

NOn ci h ancora guardato, ma non è possibile 'accorpare' la prima e la seconda tendina? o sono 3 opzioni nominate separatamente?

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

Fondamentalmente, l'opzione da gestire è questa:

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.

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.

If the SoX global option -R option is not given, then the pseudo-random number generator used to generate the white noise will be `reseeded', i.e. the generated noise will be different between invocations.

This effect should not be followed by any other effect that affects the audio.

See also the `Dithering' section above.

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.