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?