ANNUNCIO: C-3PO v2.2 disponibile in ALFA TEST

[antonellocaroli]

In BETA una nuova versione con la gestione completament erivista dei parametri di resample.

funziona così:

1. Tabella dei sample rate supportati in uscita > selezionare SOLO i sample rate che volete che vengano prodotti da C-3PO.
2. Resample when è stato eliminato, è sempre per eccezione, salvo quando non è possibile (viene segnalato nei warnings), nel qual caso è come se "sempre" ed "alla massima".
3. Resample to serve solo per restringere la selezione ai s/r sincorni o non sincroni.

Per fare SEMPRE upsampling ad una solo frequenza... selezionare solo quella.
Per fare upsampling ad una frequenza, non toccarne altre e downsample ad una seconda:

es.

44100 [ ] 88200 [x] 176400 [x] 352800 [ ]
48800 [ ] 96000 [x] 192000 [x] 384000 [ ]

produce, sincrono:

44100 e 88200 -> 88200, 176400 e 352800 -> 176400

non sincrono:

44100 e 88200 -> 96000, 176400 e 352800 -> 384000

mentre

44100 [ ] 88200 [ ] 176400 [x] 352800 [ ]
48800 [ ] 96000 [x] 192000 [ ] 384000 [ ]


sincrono:

44100, 88200, 176400 e 352800 -> 176400
48000 , 96000 , 192000 e 384000 -> 96000

asincrono

44100, 88200, 176400 e 352800-> 96000
48000 , 96000 , 192000 e 384000 -> 176400

indifferente:

44100, 48000, 88200, 96000 -> 96000
176400, 192000 , 352800 e 384000 -> 176400

E' più semplice farlo che spiegarlo.

In questo modo considero chiuse le due richieste ancora pendenti.

Non l ho capito molto....
Mi piaceva piú prima...

[UnixMan]

Ciao Marco,

vedi il post nell'altro topic, c'è una descrizione un po' più accurata del problema.

Dici C-3PO? SOX mansr è installato?

sì, e C3PO (in advanced/global) lo conferma.

IL player non invia NULLA in merito a DSD

neanche se in qualche modo lo supporta (tipo se supporta DSF/DFF) oppure no?

[marcoc1712]

neanche se in qualche modo lo supporta (tipo se supporta DSF/DFF) oppure no?

Si, quello si, comunque di la ti ho descritto i sintomi dei vari casi.

[marcoc1712]

Non l ho capito molto.....

In pratica, nell'uso comune, metti solo la frequenza a cui vuoi che tutto venga ricampionato. Altrimenti quelle disabilitate vengono portate alla prima superiore abilitata, se c'è, altrimenti inferiore, eventualmente sincrona o non sincrona in base all'indicatore.

Mi piaceva piú prima..

Non sapevo chi, ma ero certo che qualcuno lo avrebbe detto...

Per ottenere quello che è stato richiesto (upsampling fino a X, lasciare intoccato X, Y e Z, downsampling a Z oltre) è il modo di sicuro più semplice a livello di modifiche da apportare alla logica interna al programma e - mi pare - anche il più chiaro come resa e coerenza, molto più dell'aggiunta di un ulteriore campo scollegato, come era stato richiesto.

Comunque, rispetto a prima, cambia solo che se lasci dei buchi intermedi questi NON vengono portati sempre al massimo, ma al primo valore successivo supportato, quindi puoi facilmente ottenere lo stesso risultato abilitando solo il massimo, ma lasci aperte più possibilità.

Tu come avresti risolto?

[UnixMan]

In pratica, nell'uso comune, metti solo la frequenza a cui vuoi che tutto venga ricampionato. Altrimenti quelle disabilitate vengono portate alla prima superiore abilitata, se c'è, altrimenti inferiore, eventualmente sincrona o non sincrona in base all'indicatore.

Non l ho capito molto....
Mi piaceva piú prima...

Non sapevo chi, ma ero certo che qualcuno lo avrebbe detto...

temo di dover dire lo stesso. Ovviamente mi piace molto il fatto che così facendo la gestione diventa più flessibile ed è possibile fare quello che chiedevamo ma, purtroppo, per contro IMHO l'interfaccia diventa meno chiara ed intuitiva. Se il meccanismo è risultato poco chiaro perfino a Filippo, non oso pensare la reazione di un utente ignaro.

Ho visto che hai anche tolto il "never" tra le opzioni per gli effetti aggiuntivi. Indubbiamente (dato che hai aggiunto l'opzione per formato sopra) era diventato un duplicato superfluo... ma a me piaceva. Sempre per il medesimo motivo: anche in questo caso, rendeva tutto più chiaro. Mettendomi nei panni di un utente, magari un po' imbranato, se non voglio che ci siano effetti e lì vedo scritto "never"... sono più tranquillo.

[marcoc1712]

temo di dover dire lo stesso. Ovviamente mi piace molto il fatto che così facendo la gestione diventa più flessibile ed è possibile fare quello che chiedevamo ma, purtroppo, per contro IMHO l'interfaccia diventa meno chiara ed intuitiva. Se il meccanismo è risultato poco chiaro perfino a Filippo, non oso pensare la reazione di un utente ignaro.

Ho visto che hai anche tolto il "never" tra le opzioni per gli effetti aggiuntivi. Indubbiamente (dato che hai aggiunto l'opzione per formato sopra) era diventato un duplicato superfluo... ma a me piaceva. Sempre per il medesimo motivo: anche in questo caso, rendeva tutto più chiaro. Mettendomi nei panni di un utente, magari un po' imbranato, se non voglio che ci siano effetti e lì vedo scritto "never"... sono più tranquillo.

Ragazzi,...io alzo le mani. Evidentemente abbiamo idee diverse di chiarezza.

Francamente non capisco cosa ci sia di non chiaro.

Vuoi suonare 44100 ? lo selezioni, altrimenti no.
Vuoi fare upsampling di Flac? lo selezioni, altrimenti no.

Nei modi proposti, la scelta non è mai così semplice e sono coinvolti sempre più controlli il cui effetto non è circoscritto alla singola scelta.

L'unica 'complicazione' è sincrono/ non sincrono, aggiunto su tua richiesta, altrimenti metterei solo una cb "preferisci frequenze sincrone, quando possibile", il cui significato sarebbe ancora più chiaro.

L'alternativa del campo aggiuntivo, come proponevi, prevede la presenza dei controlli "A" con max o fissa, quindi mentre compili la griglia, devi chiederti che valore ha/avrà il campo ed il significato della griglia stessa cambia se metti max o fissa, tra l'altro in modo ridondante, dato che se vuoi max basta che selezioni SOLO la massima.

il doppio controllo non è mai "chiaro":

es.

Se parti con ricampiona: flac no, wav no, aiff si...
e RICAMPIONA: Quando -> mai.

se vuoi ricampionare flac cosa devi fare?

a. ricampiona: flac si
b. RICAMPIONA Quando -> sempre.

però cosa succede ad Aiff? adesso diventa attivo il ricampionamento, è quello che volevi ottenere o dovresti disabilitarlo?

Per me non è 'chiaro'.

[marcoc1712]

In BETA la gestione dei parametri per la gestione dei filtri Trellis aggiuntivi a SDM.

Per attivarli occore prima di tutto attivare l'opzione in Avanzate, quindi vengono presentati impostati al valore di default ma disattivi, si possono attivare individualmente. Verificato nel codice che quando non impostati assumono il valore di default assegnato ed indicato nell'help.

Io non riesco a verificare se suonano e come, ma sintatticamente funzionano.

Penso che con questa release chiuderò la stagione 2016-17, salvo il supporto e la correzione di bugs, ... se ne riparla a settembre con nuovi obiettivi.

[UnixMan]

grande!

Per attivarli occore prima di tutto attivare l'opzione in Avanzate,

mmmh. C'è un bachetto: se non sono abilitati DSF e/o DFF negli "Input formats" (sopra), non permette di attivare le opzioni avanzate (nessuna delle due, neanche quella relativa al max s/r DSD). Immagino tu lo abbia fatto di proposito, ma è sbagliato: quelle opzioni servono anche se disabiliti DSD in ingresso (ma poi usi la conversione PCM->DSD in uscita).

BTW: sembra funzionare... ma forse c'è qualche problemino: abilitando il "trellis order" mi funziona a singhiozzo o smette di funzionare del tutto. Il che non mi sorprenderebbe se accadesse solo per valori diversi dal default... ma la cosa strana è che accade anche se lo imposto al valore che dici essere il default (13).

Per il resto, funziona e suona.

La prima, velocissima impressione è che l'impatto sul suono del "no. of paths" sia sensibile (un audiofilo probabilmente lo definirebbe "enorme").

Non ho notato invece differenze macroscopiche(*) raddoppiando la latenza (cioè la dimensione di qualche buffer?).

(*) non escludo che ce ne possano essere di più sottili, ma il rapidissimo test non mi consente di apprezzare eventuali sfumature.

[marcoc1712]

grande!


mmmh. C'è un bachetto: se non sono abilitati DSF e/o DFF negli "Input formats" (sopra), non permette di attivare le opzioni avanzate (nessuna delle due, neanche quella relativa al max s/r DSD). Immagino tu lo abbia fatto di proposito, ma è sbagliato: quelle opzioni servono anche se disabiliti DSD in ingresso (ma poi usi la conversione PCM->DSD in uscita).

Non se non sono abilitati, ma se non sono gestibili da SOX, o almeno così dovrebbe essere. Verifico.

EDIT: E' come pensavo. Se SOX non gestisce DSD non puoi usare NESSUNA conversione e tutto quanto in merito a DSD è disabilitato. DSD non è supportato in ingresso, nemmeno per il playback nativo, devi usare LMS o dsdPlay.

EDIT2: però hai ragione, se sox non è dsd capable non li espongo, ma li disabilito quando i formati DSD sono disabilitati, lasciando per altro il valore corrente. Questo è un errore, risolto nel prossimo rilascio correttivo, aspetto qualche altro giorno di test.

Grazie.

BTW: sembra funzionare... ma forse c'è qualche problemino: abilitando il "trellis order" mi funziona a singhiozzo o smette di funzionare del tutto. Il che non mi sorprenderebbe se accadesse solo per valori diversi dal default... ma la cosa strana è che accade anche se lo imposto al valore che dici essere il default (13).

Per il resto, funziona e suona.

La prima, velocissima impressione è che l'impatto sul suono del "no. of paths" sia sensibile (un audiofilo probabilmente lo definirebbe "enorme").

Non ho notato invece differenze macroscopiche(*) raddoppiando la latenza (cioè la dimensione di qualche buffer?).

(*) non escludo che ce ne possano essere di più sottili, ma il rapidissimo test non mi consente di apprezzare eventuali sfumature.

Come sai, non riesco a provare, ma nel codice leggo quello, almeno nella parte che legge i parametri, se poi li cambia in seguito non ho verificato.

if (trellis_order || f->trellis_order) {
    if (trellis_order < 1)
      trellis_order = f->trellis_order ? f->trellis_order : 13;


    if (trellis_num)
      p->trellis_num = trellis_num;
    else
      p->trellis_num = f->trellis_num ? f->trellis_num : 8;


    if (trellis_latency)
      p->trellis_lat = trellis_latency;
    else
      p->trellis_lat = f->trellis_lat ? f->trellis_lat : 1024;

dove trellis_xxx è il parametro in ingresso, f->trellis_xxx è il valore impostato nel filtro sdm selezionato, quindi - in realtà - i valori che ho messo sono si il default, ma se il filtro ne ha di suoi diversi, impostandoli ottieni un funzionamenti diverso rispetto al non impostarli.

Per renderli 'innocui' dovresti sapere i valori impostati nel filtro stesso e replicarli.

[UnixMan]

[...] quindi - in realtà - i valori che ho messo sono si il default, ma se il filtro ne ha di suoi diversi, impostandoli ottieni un funzionamenti diverso rispetto al non impostarli.

ah, ok. Quindi non c'è nessun problema strano, C3PO fa quel che deve fare.

Magari però sarebbe il caso di aggiungere questa spiegazione nelle info (filtri diversi = default diversi, se volete il default del filtro non abilitate l'opzione), e forse toglierei anche l'indicazione "default=13" per quella opzione. Altrimenti un utente potrebbe essere portato a pensare ad un bug di C3PO.

BTW: per caso sai quale filtro (sdm) viene utilizzato da sox quando si usa l'impostazione "default/auto" (cioè non si specifica quale usare)? È sempre lo stesso o ne sceglie uno diverso a seconda di ... qualcosa? (ed, eventualmente, cosa?)