marcoc1712 / C-3PO

Squeezebox server plugin that handles server side file type conversion and resampling. Replace custom-convert.conf.
14 stars 3 forks source link

Nuove opzioni di ricampionamento #8

Closed marcoc1712 closed 7 years ago

marcoc1712 commented 7 years ago

Da SimoneFil #5

Ciao Marco; ti suggerisco due features da aggiungere per la prossima release che a mio parere possono essere molto utili:

1- Menu "Ricampiona:"; insieme a "Sempre", "Mai", "Solo se la frequenza di campionamento non è supportata" aggiungere "Solo per file 16bit 44.1Khz". Fare upsampling a file già in Hi-Res a poco senso e a volte ho pure notato una degradazione sonora; mentre se si limitasse ai 16/44.1 sarebbe ottimo!

  1. 7

marcoc1712 commented 7 years ago

si può fare, con alcune limitazioni in windows, purtroppo. #5

EDIT: Se l'obiettivo è escludere dal resampling i files con sample rate > di una certa soglia, allora conviene impostare il resampling when a: solo se non supportata e disabilitare le frequenze inferiori a tale soglia.

Considero chiusa qusta specifica richiesta.

marcoc1712 commented 7 years ago

Da SimoneFil #5

Sarebbe comunque un'ottima feature!

marcoc1712 commented 7 years ago

Da pms967 #5

Sarebbe simpatica. Però piuttosto che una rate fissa, metterei la possibilità di scegliere. Cioè, qualcosa del tipo: "ricampiona solo se s/r < XX", con XX configurabile.

Una cosa analoga sarebbe utilissima anche (e soprattutto) per gli stream DSD, così da poter evitare di ri-processare ad es. quelli che sono già DSD128 o superiori.

marcoc1712 commented 7 years ago

5

...rognosa ed impatta in modo significativo sulla struttura di C.3PO. vi chiedo di specificare meglio cosa dovrebbe fare ed in che condizioni.

pms967 commented 7 years ago

In linea di principio l'idea è semplice: decidere cosa fare non solo in base alle capacità del player, ma anche in base al formato dello stream di ingresso.

Ad. es., come diceva Simone, potrei voler fare upsampling al max s/r supportato (e.g. 384K) se sto suonando un file 16/44, ma al contrario non fare nulla (lasciare lo stream inalterato, bit-perfect) se invece ho a che fare con un 24/96 o superiore.

Simone si limitava alla possibilità di escludere un solo caso (16/44), io suggerivo una soluzione più generale, dove l'utente può decidere "la soglia" al di sopra della quale escludere il resampling.

Analogamente per il DSD: se il mio DAC supporta e.g. fino a 256, potrei voler fare upsampling a 128 (o 256) se ho uno stream di ingresso DSD64, ma lasciare inalterati quelli che sono già 128 o superiori.

marcoc1712 commented 7 years ago

Il principio mi è chiaro, anche il come realizzare la parte di 'attuazione', che comunque avrà limitazioni almeno in windows, lo è.

Non ho capito come ritieni debba essere realizzata l'interfaccia, se con un numero fisso di opzioni fisse (quali) o altro, tenendo presente che non riesco a condizionare i valori di un controllo in funzione di quelli assunti da un altro.

La richiesta di Simone è chiara, anche se mi lascia dubbioso;

48000/24 sarebbe da escludere dal resampling? 44100/20? DSD?

Altro punto:

Oggi qualsiasi effetto impostato provoca il resampling, secondo questa logica dovrei escluderlo quando il sample rate è uguale o quando sono uguali il sample rate ed il bith depth?

pms967 commented 7 years ago

Direi che basta il solo s/r.

Come interfaccia, ad es. potresti aggiungere una checkbox del tipo:

"non ricampionare se s/r >= soglia (e s/r < max supportato)"

e di fianco (o subito sotto) mettere un controllo (e.g., uno slider) con cui selezionare la soglia (cioè il s/r al di sopra del quale non si vuole che venga effettuato il resampling . Se possibile, per mera questione "estetica" e di chiarezza, tale controllo dovrebbe essere disabilitato ("greyed-out") se nel menù è selezionata una voce diversa.

Idem per il DSD.

In alternativa potresti aggiungere un menù del tipo: "ricambiona sempre" "non ricampionare se >=48"(*) "non ricampionare se >=96"(*) "non ricampionare se >=192"(*) "non ricampionare mai"(*)

(*) se supportato dal player

Ed analogamente per il DSD.

Per quanto riguarda gli effetti, in PCM puoi applicarli anche senza fare necessariamente resampling.

In DSD invece non è possibile... ed in tal caso basta cambiare la dicitura: anziché mettere "ricampiona/non ricampionare" si potrebbe dire qualcosa del tipo: "play as-is (bit perfect, no effects)":

"non processare mai"(*) "non processare se >=DSD256"(*) "non processare se >=DSD128"(*) "processa sempre"

Volendo, se implementi con checkbox+slider, per il PCM si potrebbe mettere la doppia opzione con un "radio-button" (o un menù) aggiuntivo: (checkbox) "se s/r >= soglia escludi"(*): "resampling" "tutto (bit-perfect)"(*)

marcoc1712 commented 7 years ago

Per quanto riguarda l'opzione '"in alternativa" il problema è che dovrei mettere tante voci quante sono le combinazioni di limiti per PDM e DSD (non è possibile selezionare 2 voci) o 2 serie di controlli, uno per il PCM e l'altro per il DSD.

Gli effetti potrei applicarli anche senza fare resampling, vero, anche per DSD, perchè dici di no?, Il fatto è che dovrei ristrutturare completamente il programma per gestirli separatamente, nel caso come interfaccia, aggiungerei una o più CB per formato in ingresso, analogamente a decodifica, ricampiona ecc.

Ammesso di gestire due diverse opzioni di ricampiona, con annesso limite di S/R per PCM e DSD, la questione rimane:

devo sottoporre anche gli effetti al limite di Samplerate come il resampling? E' sempre lo stesso limite per TUTTI gli effetti o può essere diverso?

Non vorrei doverci tornare sopra...

pms967 commented 7 years ago

Gli effetti potrei applicarli anche senza fare resampling, vero, anche per DSD, perchè dici di no?

no, di fatto non puoi applicare nessun "effetto" di SoX al DSD senza prima convertire in PCM e poi riconvertire in DSD. Qualsiasi elaborazione applichi ti fa perdere la natura "DSD" (single bit) dello stream, per cui poi sei costretto a (ri)convertire in DSD con "sdm"... quindi in pratica prima devi sempre convertire in PCM (ricampionando e/o quanto meno filtrando opportunamente il rumore), altrimenti fai solo un pasticcio.

Il fatto è che dovrei ristrutturare completamente il programma per gestirli separatamente

quella IMHO sarebbe comunque una buona idea, che non per caso avevo suggerito fin dal principio: PCM e DSD rappresentano due situazioni sensibilmente diverse, che vanno trattate in modo diverso (anche per quanto riguarda alcune delle opzioni potenzialmente comuni, quali quelle del resampler). Questo in modo particolare ove caso l'utente voglia utilizzare formati di uscita diversi a seconda di quello in ingresso (tip. PCM se PCM, DSD se DSD): per avere settings ottimizzati per entrambi i casi sarebbe bene che le opzioni siano distinte: non è detto che ciò che va meglio per il PCM sia ottimale anche per il DSD e viceversa.

Ammesso di gestire due diverse opzioni di ricampiona, con annesso limite di S/R per PCM e DSD, la questione rimane: devo sottoporre anche gli effetti al limite di Samplerate come il resampling? E' sempre lo stesso limite per TUTTI gli effetti o può essere diverso?

Per quanto riguarda il DSD (da file "nativi" DSD) il problema IMHO non si pone proprio: l'opzione può essere (solo) del tipo "o tutto o niente" (processa / non processare).

Per quanto riguarda il PCM, l'esclusione può riguardare il solo resampling oppure tutto quanto (opzione "bit-perfect / pass-through", come per il DSD), a discrezione dell'utente. Altre "esclusioni parziali" invece mi sembrano inutili.

P.S. per il DSD (ma in effetti anche per il PCM) si pone un problema:

non è detto che il s/r desiderato in uscita quando lo stream viene processato (e.g. "upsampling" o conversione PCM->DSD) coincida con quello max supportato dalla scheda.

Ad es., mentre il s/r desiderato/utilizzato in caso di upsampling potrebbe essere inferiore a quello max supportato dal DAC (ad es. a causa di limiti del server, o per altri motivi), nel caso di stream "nativi" con s/r elevati potrebbe invece essere (tipicamente è) desiderabile inviarli in uscita così come sono, senza fare downsampling fino a quello che è invece il s/r desiderato in altri casi.

Fino ad ora, per selezionare un s/r diverso dal max supportato (reale), la soluzione è stata di fatto un "workaround": modificare la lista dei s/r supportati dal player, escludendo quelli superiori a quello desiderato.

Solo che questa soluzione è limitante, in quanto crea dei limiti artificiali inferiori a quelli reali e porterebbe inevitabilmente ad imporre un downsampling anche quando non ce ne sarebbe affatto bisogno.

(ad esempio, se ho dei files "nativi" DSD512 o PCM768k ed il mio DAC può gestirli as-is, l'ultima cosa al mondo che vorrei fare è farne un downsampling... solo perché quando tratto files a risoluzione CD devo/voglio invece limitare il s/r di uscita a DSD128 o PCM 384k).

In altre parole (come suggerivo a suo tempo nella bozza di interfaccia), è necessario separare il concetto di "limite max" (invalicabile, imposto dal player) da quello del s/r desiderato laddove invece venga (intenzionalmente) effettuato un resampling (o una conversione di formato, PCM->DSD o viceversa).

marcoc1712 commented 7 years ago

Vero che devo SEMPRE passare per una conversine in PCM (decode), ma non necessariamente ciò comporta il cambio di sample rate (resampling).

In base alle opzioni selezionate potrei partire da es. DSD64, convertire in PCM, applicare gli effetti e quindi tornare a DSD64 o es. DSD128. Nel primo caso non c'è resampling, nel secondo si, per come sono intesi i parametri. Dal tutto analogamente a quanto avviene per 'spezzare' un file wav usando FLAC: devi necessariamente passare per una doppia conversione WAV->FLAC->WAV, ma NON per questo la presenti come una conversione.

I parametri presentano gli EFFETTI non il percorso per ottenerli, che può variare in funzione degli strumenti disponibili.

Riscrivere il tutto non è (per me) un'opzione.

In quest'ottica, per ottenere quanto chiedi, cosa doveri fare di preciso?

Tutto il rest di quanto scrivi è probabilmente vero, ma troppo 'fumoso' per ppoter essere trattato come una segnalazione di errore o una richiesta di modifica. In questa sede devono essere 'atomiche' e ben congetturate in funzione di un obiettivo (o caso d'uso) precso ed individuato, altrimenti non posso gestilre come tali e doveri dividerle...

Questo tipo di discussioni lasciamole al forum, qui magari riportiamo le conclusioni, meglio se in bervi formulazioni in Inglese.

Grazie.

marcoc1712 commented 7 years ago

Al momento - concretamente - io ho capito questo:

... decode [] [] [] [] resample [] [] [] [] effects(?) [] [] [] []

Resample when

- never
- always
- only if sample rate is not supported 
- only if sample rate is lesser than (see below)

PCM sample rate limit DSD rate limit

DOMANDE:

effect(?) è il termine giusto? comprende in se tutto quanto dopo il resampling, compreso il dither/sdm? Se no, come temo, mi indicate quali effetti seguono il resampling e quali sono invece compresi nel gruppo indipendente?

Questo gruppo indipendente è' sottoposto alle stesse regole del resampling o serve un controllo ulteriore (Apply effects when...)? Servono i limiti? se si, sono diversi?

E' sufficiente un solo gruppo indipendente o è necessario prevedere diverse voci?

La risposta puntuale alle domande di cui sopra mi permette di valutarne la fattibilità, se non sono a tono e la richiesta verte su altri aspetti, allora ho bisogno che me li chiariate in termini più precisi, di cui lo schema sopra è un esempio.

pms967 commented 7 years ago

Questo tipo di discussioni lasciamole al forum

OK. Per evitare confusione rispondo comunque qui alle domande che hai posto sopra.

effect(?) è il termine giusto? comprende in se tutto quanto dopo il resampling, compreso il dither/sdm? [...]

non ti seguo: l'idea era di aggiungere una opzione per poter escludere completamente (in determinati casi) qualsiasi tipo di elaborazione (a prescindere dagli altri settings). Quindi proprio tutto (incluso il resampling e qualsiasi altra cosa, tranne il solo decoding).

In sostanza si tratta di un "by-pass": quando quell'opzione si attiva, C3PO deve limitarsi al solo decoding e niente altro.

Ovviamente, prima di attivare tale modalità "by-pass" C3PO deve verificare che lo stream sia compatibile con il dispositivo di uscita: se lo è si limita all'eventuale decoding e poi invia lo stream in uscita così com'è, in caso contrario procede come se quella opzione non ci fosse affatto.

Il termine più appropriato direi sia: "bit-perfect (nessuna elaborazione)".

Oppure per l'appunto "pass-through" o "by-pass".

Questo gruppo indipendente è' sottoposto alle stesse regole del resampling o serve un controllo ulteriore (Apply effects when...)? Servono i limiti? se si, sono diversi?

mah... direi che basti un unico limite. Presumo che l'utente possa voler decidere se trattare tutto allo stesso modo, escludere il solo resampling o escludere tutto, ma non credo possa esserci l'esigenza di utilizzare entrambe le cose (disabilitazione del solo resamplig e by-pass totale) su "soglie" diverse. Comunque se vuoi puoi farlo.

Viceversa, potrebbe esserci l'esigenza di trattare diversamente PCM e DSD: ad es., nel caso del PCM si potrebbe voler escludere il solo resampling, mentre nel caso del DSD (a causa della necessaria doppia conversione) è più probabile che si voglia escludere tutto e mandare al player il file as-is.

In questo senso, non so se lo schema che hai proposto (includere il controllo all'interno del menù di resampling) sia il più adatto. Anzi, forse quel menù lo eliminerei proprio: ad es., che senso ha l'opzione "never"? Se il s/r non è supportato dal player non mi pare ci siano molte alternative: o ricampioni o non lo riproduci affatto, il che (dato che non puoi mostrare un msg di errore all'utente) non mi sembra una bella cosa: l'utente penserebbe che il software non funziona. Se invece lo mandi comunque in play (senza ricampionare) o non suona (e ricadi nel caso precedente) o, peggio, produce solo rumore... (rischiando di far danni ai diffusori e/o all'udito del malcapitato). Anche in questo caso, l'utente se la prenderebbe col software. Non mi sembra che nessuna di queste opzioni possa essere desiderabile.

Perciò IMHO non restano che due sole opzioni possibili: ricampiona "sempre" o "solo se inevitabile". Che forse potrebbero essere gestite meglio con una coppia di "radio button".

A questo potresti far seguire qualcosa del genere:

[x] Se PCM con s/r > di (menù): 
   (o) Escludi resampling (se possibile)
   () Escludi qualsiasi elaborazione (bit-perfect pass-through)

[x] Se DSD con s/r > di (menù): 
   (o) Escludi resampling (se possibile)
   () Escludi qualsiasi elaborazione (bit-perfect pass-through)

dove con '[x]' indico una checkbox, che esclude per intero l'opzione (="non trattare in modo diverso"). In realtà la checkbox è ridondante, in quanto il medesimo risultato lo si può ottenere banalmente impostando la soglia al valore max supportato... ma metterla aggiunge chiarezza.

In alternativa, potresti mettere (prima) una cosa del tipo:

considera uno stream "HD" se:
PCM con s/r > (menù)
DSD con s/r > (menù)

e mettere nel menù ricampiona "except when stream is HD", nonché aggiungere poi una checkbox tipo:

[x] exclude all processing (bit-perfect pass-through) if stream is HD

Cioè più o meno come volevi fare tu, credo... :-) però così facendo perdi la possibilità di gestire diversamente PCM e DSD.

Un'altra alternativa chiara, semplice e compatta (e che al tempo stesso consente la max versatilità, rendendo possibile la doppia soglia) potrebbe essere l'aggiunta di una cosa del genere:

[x] escludi resample se PCM con s/r > (menù) o DSD > (menù)
[x] escludi tutte le elaborazioni se PCM con s/r > (menù) o DSD > (menù)
marcoc1712 commented 7 years ago

intendevo in riferimento alla proposta d cui sopra, che non prevede il 'bypass' ma la separazione tra resampling ed effects(?).

ma parlarne qui è scomodo e fuorviante. La richiesta in oggetto è quella di introdurre una nuova voce nel menu ricampiona. quello che tratteggi tu è molto più elaborato e complesso, ripeto, discutiamone nel forum e poi eventualmente apri una richiesta 'conclusa' e dedicata.

Io qui non so come rispondere alla richiesta specifica.

pms967 commented 7 years ago

intendevo in riferimento alla proposta d cui sopra, che non prevede il 'bypass' ma la separazione tra resampling ed effects(?).

boh, non ho capito bene cosa vorresti fare.

discutiamone nel forum

ok.

marcoc1712 commented 7 years ago

ok. Comunque qualcosa in merito è già compreso nell'ultima versione rilasciata in beta, quindi chiudo la richiesta ed eventualmente la riapri in modo più selettivo.

marcoc1712 commented 7 years ago

IN merito alla richiesta originaria è possibile escludere dal resampling i files con sample rate > di una certa soglia impostando il resampling when a: "solo se non supportata" e disabilitare le frequenze inferiori a tale soglia (es 48KHz).

Non è necessario aggiungere ulteriori controlli allo scopo.