Ciao, Marco.
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
— E. F. Schumacher (mis-attributed to A. Einstein)
________________________________________________________________________________
Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE
Ciao, Paolo.
«Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»
Ciao, Marco.
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
— E. F. Schumacher (mis-attributed to A. Einstein)
________________________________________________________________________________
Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE
2.01.06 in beta, con slider funzionante.
Ciao, Marco.
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
— E. F. Schumacher (mis-attributed to A. Einstein)
________________________________________________________________________________
Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE
Le novità mi piacciono molto e sono decisamente comode. Funzionalmente direi che ora c'è praticamente tutto quel che può servire. Direi anche che sei riuscito a risolvere brillantemente i problemi di "rendering" di alcune opzioni, che ora (almeno nella maggior parte dei casi) hanno un aspetto decisamente più "pulito" ed ordinato.
Insomma, di bene in meglio. Ancora una volta hai fatto un gran bel lavoro.
Se proprio vogliamo trovare un appunto, alcune delle possibilità -che ci sono già- forse non risultano così evidenti ed immediate. Mi riferisco in particolare ad alcune delle possibili funzionalità che per essere implementate richiedono di modificare il range di s/r supportati in combinazione con altri settings.
IMHO tutto risulterebbe ancora più comprensibile ed intuitivo se la "tabella" che definisce i s/r supportati dal player fosse usata soltanto per la sua funzione più ovvia ed "esplicita", cioè per definire i "limiti invalicabili" e le altre possibilità offerte dal player (nonché eventualmente per escludere quelle possibilità che ci sono ma non si desidera siano mai usate), mentre la scelta del s/r da usare in caso di resampling (o conversione / elaborazione con uscita DSD) fosse distinta e (parzialmente) "indipendente" rispetto a quella tabella.
(come side-effect -benvenuto- la cosa permetterebbe anche di ottenere alcune "combinazioni" in più nella rosa dei possibili comportamenti).
In pratica C3PO continuerebbe ad usare (come ora) quella tabella per determinare se/quando è necessario ricampionare (s/r non supportati), ma non per determinare il s/r di uscita da usare quando (per necessità o per scelta) applica un ricampionamento.
Per quello dovrebbe invece utilizzare il valore impostato in un apposito menù dedicato (anzi, forse meglio due menù dedicati: uno per il PCM ed uno per il DSD) che contiene (contengono) una lista dei possibili s/r di uscita (lista ovviamente ottenuta proprio dalla "tabella" dei s/r supportati).
Ovviamente per applicare questa soluzione sarebbero necessarie anche delle modifiche ad alcuni degli altri menù attualmente presenti. In particolare, ovviamente la scelta se/quando ricampionare andrebbe separata da quella del target s/r.
Inoltre, in luogo delle opzioni "max supported", "max synchronous", ecc., ci vorrebbe invece qualcosa del genere:
"exact / fixed"
"nearest (supported) multiple"
"nearest (supported) irrational ratio"
La prima opzione è ovvia (=ricampiona sempre all'esatto valore richiesto, a prescindere dal s/r in ingresso);
La seconda è equivalente all'attuale "max synchronous" (ma con riferimento al valore richiesto, che potrebbe essere inferiore al massimo supportato): "ricampiona sempre al s/r supportato più vicino a quello richiesto che sia un multiplo intero del s/r originario dello stream".
La terza sarebbe una (interessante) novità. In pratica è l'inverso della precedente. Significa: "ricampiona sempre al s/r supportato più vicino a quello richiesto che non sia un multiplo intero del s/r originario dello stream".
In altre parole, se in ingresso ho un s/r multiplo di 44.1K in uscita produco sempre un s/r multiplo di 48K e viceversa.
Ovvero, se ad es. imposto un target s/r di 192K ed ingresso ho uno stream a 44.1K, in uscita ottengo proprio 192K. Ma se invece lo stream di partenza è a 48K o 96K, in uscita ottengo invece 176.4K. Analogamente negli altri casi. Ad es.: target=176.4K, in=48K -> out=176.4K; se invece in=44.1 -> out=192K (o 96K, ecc, in funzione di ciò ce è supportato).
(ovviamente tanto la seconda quanto la terza opzione perdono di significato -e diventano equivalenti alla prima- nel caso "patologico" in cui una delle due "serie" non è supportata affatto, o quando addirittura è supportato un unico s/r fisso... come per altro già accade per l'attuale opzione "max synchronous").
Ciao, Paolo.
«Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»
I limiti invalicabili non sono una tabella, ma SOLO il max sample rate restituito dal player, che poi è invalicabile fino a lì, infatti mi hai fatto inserire l'opzione per poterlo valicare con il DSD.Le novità mi piacciono molto e sono decisamente comode. Funzionalmente direi che ora c'è praticamente tutto quel che può servire. Direi anche che sei riuscito a risolvere brillantemente i problemi di "rendering" di alcune opzioni, che ora (almeno nella maggior parte dei casi) hanno un aspetto decisamente più "pulito" ed ordinato.
Insomma, di bene in meglio. Ancora una volta hai fatto un gran bel lavoro.
Se proprio vogliamo trovare un appunto, alcune delle possibilità -che ci sono già- forse non risultano così evidenti ed immediate. Mi riferisco in particolare ad alcune delle possibili funzionalità che per essere implementate richiedono di modificare il range di s/r supportati in combinazione con altri settings.
IMHO tutto risulterebbe ancora più comprensibile ed intuitivo se la "tabella" che definisce i s/r supportati dal player fosse usata soltanto per la sua funzione più ovvia ed "esplicita", cioè per definire i "limiti invalicabili" e le altre possibilità offerte dal player (nonché eventualmente per escludere quelle possibilità che ci sono ma non si desidera siano mai usate), mentre la scelta del s/r da usare in caso di resampling (o conversione / elaborazione con uscita DSD) fosse distinta e (parzialmente) "indipendente" rispetto a quella tabella.
(come side-effect -benvenuto- la cosa permetterebbe anche di ottenere alcune "combinazioni" in più nella rosa dei possibili comportamenti).
In pratica C3PO continuerebbe ad usare (come ora) quella tabella per determinare se/quando è necessario ricampionare (s/r non supportati), ma non per determinare il s/r di uscita da usare quando (per necessità o per scelta) applica un ricampionamento.
Per quello dovrebbe invece utilizzare il valore impostato in un apposito menù dedicato (anzi, forse meglio due menù dedicati: uno per il PCM ed uno per il DSD) che contiene (contengono) una lista dei possibili s/r di uscita (lista ovviamente ottenuta proprio dalla "tabella" dei s/r supportati).
Ovviamente per applicare questa soluzione sarebbero necessarie anche delle modifiche ad alcuni degli altri menù attualmente presenti. In particolare, ovviamente la scelta se/quando ricampionare andrebbe separata da quella del target s/r.
Inoltre, in luogo delle opzioni "max supported", "max synchronous", ecc., ci vorrebbe invece qualcosa del genere:
"exact / fixed"
"nearest (supported) multiple"
"nearest (supported) irrational ratio"
La prima opzione è ovvia (=ricampiona sempre all'esatto valore richiesto, a prescindere dal s/r in ingresso);
La seconda è equivalente all'attuale "max synchronous" (ma con riferimento al valore richiesto, che potrebbe essere inferiore al massimo supportato): "ricampiona sempre al s/r supportato più vicino a quello richiesto che sia un multiplo intero del s/r originario dello stream".
La terza sarebbe una (interessante) novità. In pratica è l'inverso della precedente. Significa: "ricampiona sempre al s/r supportato più vicino a quello richiesto che non sia un multiplo intero del s/r originario dello stream".
In altre parole, se in ingresso ho un s/r multiplo di 44.1K in uscita produco sempre un s/r multiplo di 48K e viceversa.
Ovvero, se ad es. imposto un target s/r di 192K ed ingresso ho uno stream a 44.1K, in uscita ottengo proprio 192K. Ma se invece lo stream di partenza è a 48K o 96K, in uscita ottengo invece 176.4K. Analogamente negli altri casi. Ad es.: target=176.4K, in=48K -> out=176.4K; se invece in=44.1 -> out=192K (o 96K, ecc, in funzione di ciò ce è supportato).
(ovviamente tanto la seconda quanto la terza opzione perdono di significato -e diventano equivalenti alla prima- nel caso "patologico" in cui una delle due "serie" non è supportata affatto, o quando addirittura è supportato un unico s/r fisso... come per altro già accade per l'attuale opzione "max synchronous").
Quella informazione è data dal MASSIMO valore selezionabile nelle due tabelle, la selezione EFFETTIVA o meno 'apre' la rispetiva porta del player per il transcoder, l'alternativa è fare come ho fatto per i codecs, cioè riportare l'informazione proveniente dal player (con tutti i problemi relativi) di max sample rate ed in una tabella separata la selezione dei quelli da ricampionare o meno, ma è solo una questione estetica opinabile, non aggiunge nulla di per se.
"exact / fixed" è meglio evitarlo, dato che può succedere che diventi indisponibile per il player (se cambi le capacità di squeezelite con -r), quindi tutte le scelte devono ammettere una approssimazione, da qui le attuali sincrona/massima, possiamo aggiungere asincrona (o irrazionale), non è un grosso problema.
Il 'target' sample rate che c'era ma abbiamo tolto nelle primissime versioni, non riesco a capire cosa aggiungerebbe:
Es. se imposti 192 come target, di 384 cosa te ne fai? lo mandi così com'è (allora basta selezionare anche lui) o ne fai il downsample (allora basta non selezionarlo) non vedo altre alternative francamente, ma se me lo spieghi con un esempio concreto forse capisco
lo so, ma stiamo parlando di cose diverse. Soprattutto, stiamo guardando la cosa da due punti di vista completamente diversi. Tu ovviamente vedi la cosa "dall'interno", seguendo la logica di come funzionano le cose a livello del codice. Al contrario, con la libertà che mi è consentita dal non essere coinvolto direttamente nello sviluppo del codice e dalla quasi completa ignoranza dei dettagli "interni" del sistema, io sto invece cercando di guardare le cose "dall'esterno", dal punto di vista dell'utente (di un utente che non sa nulla di come funzionino le cose "dentro", e vorrebbe che le cose appaiano come se le aspetta lui, a prescindere da ciò che accade realmente dietro le quinte).
In questo senso, per l'utente, il significato intuitivo di quella "tabella" (cioè, delle checkbox relative ai diversi s/r) appare proprio come quello di dichiarare -definire una volta per tutte- le caratteristiche "fisiche" dell'hardware: il mio DAC supporta questo e quello, ma quell'altro no (oppure anche: questo sarebbe supportato, ma per motivi miei non voglio che sia mai usato).
In sostanza, per un utente ignaro, appare un po' come il menù delle impostazioni iniziali di una TV (tipo sintonia/ricerca dei canali): una impostazione propedeutica, una tantum, "set and forget".
Dopo di che mi aspetterei di trovare una serie di opzioni "operative", su cui eventualmente agire di volta in volta per ottenere determinati risultati. Non con combinazioni più o meno complesse di opzioni diverse (tipo "abbassa qui per cambiare li"), ma quanto più possibile attraverso impostazioni mirate e dirette, dal significato ovvio.
Come ad es. i controlli di luminosità, contrasto e colore della TV, o ancora più banalmente quelli di tono e volume, per intenderci.
Fuor di metafora, così come ad es. trovo un menù dove posso scegliere se uscire a 16, 24 o 32 bit, se ad es. voglio ricampionare tutto a X Kb/s mi aspetterei di trovare un menù dove impostare quella frequenza, dove mi si chiede proprio (e solo) quello.
Non so se sono riuscito a spiegarmi...
non ti seguo: (esternamente) non si tratterebbe di aggiungere un'altra tabella (che non avrebbe molto senso: anziché rendere le cose più chiare, così facendo tempo che si renderebbe di renderle più confuse) ma solo un menù a tendina, che permette di scegliere un solo valore: quello del s/r che si vuole ottenere in uscita se e quando (in base alle caratteristiche del player ed alle altre opzioni) C3PO stabilisce che deve essere effettuato un resampling.
Infatti l'ho detto: dal punto di vista delle "funzionalità" la cosa aggiunge poco o nulla. Ma (IMO) rende tutto più chiaro ed intuitivo per l'utente ignaro.
come dicevo, la lista dei s/r selezionabili nel menù del "target s/r" dovrebbe essere generata a partire dalle impostazioni della tabella dei s/r supportati. In linea di principio le impostazioni di SL/R2 dovrebbero rispecchiare le caratteristiche (max) effettive dell'hardware e tali dovrebbero restare, almeno finché non si cambia hardware.
Non di meno, se dovesse verificarsi una cosa del genere, C3PO dovrebbe reagire banalmente cambiando automaticamente quella impostazione (dal valore precedente non più valido al più vicino valore attualmente supportato). D'altro canto, in un caso del genere già ora devi fare la stessa cosa con la tabella dei s/r supportati, quindi si tratterebbe solo di aggiornare una impostazione in più.
Oltre tutto in questo modo l'effetto delle eventuali modifiche alle impostazioni di SL/R2 diventa immediatamente evidente anche da una semplice occhiata alle impostazioni di C3PO, anziché rischiare di passare inosservata se viene gestita in modo automatico e trasparente (e non è detto che la modifica al limite max di SL sia intenzionale...).
Non dimentichiamo che lo scopo per cui è stato pensato LMS è sensibilmente diverso dal nostro. Laddove in origine una delle priorità di slimdevices (e poi logitech) era senza dubbio quella di garantire un sistema quanto più possibile "plug&play", che in qualche modo "suonasse" sempre e comunque qualsiasi cosa gli si desse in pasto (senza che l'utente dovesse necessariamente preoccuparsi del "come"), nel nostro caso è (quasi) il contrario: ai nostri utenti interessa soprattutto sapere -e poter controllare- esattamente come vengono trattati i files o gli stream che gli danno in pasto. Nonché poter "giocare" facilmente, velocemente ed intuitivamente con le impostazioni che gli interessano di più (quelle che hanno influenza sul suono, tra cui senz'altro il s/r in uscita).
esatto, proprio questa potrebbe essere una delle possibilità: se ho uno stream con s/r < 192 lo ricampiono a 192, altrimenti (se è >=192) lo mando così com'è.
In alcuni casi può avere senso: se ad es. avessi un DAC che supporta fino a 384K (o più) ma ha uno "sweet spot" (suona leggermente meglio) ad un certo s/r più basso, ad es. 96 o 192, probabilmente sarebbe vantaggioso ricampionare proprio a quella frequenza tutto il materiale con s/r inferiori. Però, se ho del materiale nativo a s/r più alto, è possibile per non dire probabile che non mi convenga "downsamplarlo": facile che quello che guadagnerei per via dello "sweet spot" del DAC lo perderei con gli interessi a causa del downsampling.
La cosa poi è particolarmente importante con il DSD. Prendi il mio caso (che non è poi così atipico): ho un DAC che supporta fino a DSD512 (teoricamente addirittura 1024), ma il PC che fa da server non è in grado di convertire da PCM (e tanto meno "upsamplare" DSD) oltre DSD128. Ora, di files DSD nativi a 512 ed oltre non ne ho mai visti (e considerati i pochissimi sistemi audio in grado di supportarli e le dimensioni folli, dubito ce ne siano...), ma DSD256 sì.
Va da sé che, in simili condizioni, idealmente ciò che vorrei ottenere è che (ad es.) PCM e DSD64 siano convertiti in DSD128 (di più non posso), mentre DSD128 e superiori siano inviati in uscita così come sono.
Ma come faccio? Se imposto il limite a quello max reale del DAC, poi C3PO tenterebbe di convertire/upsamplare tutto a quello. Però il sistema non ce la fa, e non funziona più niente. D'altro canto, se imposto il limite max a 128 poi mi ritrovo C3PO che tenta di downsamplare qualsiasi eventuale stream DSD256 o superiore (cosa che tra l'altro richiederebbe un mare di risorse, quindi non solo -se funzionasse- causerebbe un peggioramento della qualità, ma non funzionerebbe proprio).
Certo stiamo parlando di casi particolari, di un "valore aggiunto" marginale... ma visto che l'implementazione non dovrebbe presentare particolari difficoltà e che così facendo (IMHO) si ottiene anche una interfaccia più intuitiva per l'utente, che si trova davanti una scelta ovvia e non è costretto a pensare a quello che ai suoi occhi potrebbe apparire come una sorta di "workaround" (abbassare il max s/r supportato per ottenere di ricampionare ad una freq. inferiore), può valere la pena di farlo. Poi ovviamente vedi tu...
Ultima modifica di UnixMan : 13-04-2017 a 02:14
Ciao, Paolo.
«Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»
Certo che rispetto a quando mi contestavi che i fliles di configurazione erano più chiari ne hai fatta di strada...
Comunque NON sono completamente d'accordo.
Lo scopo di C-3PO è sostituirsi a tipi files e convert.conf, fornendo un ausilio e semplificando il compito, ma NON di istituire un metodo alternativo per chi ignora i principi di funzionamento di LMS in questo ambito, ma si comporta piuttosto come un'interfaccia su SOX.
Devi sapere COSA fare, C-3PO ti aiuta a farlo.
Per questo ho inserito la visualizzazione dei risultati in termini di tabella di conversione dei tipi di file, comandi generati ed ultimo comando eseguito, che sono utili SOLO SE sai come funziona LMS.
Quello che simulano NON è il processo interno del MIO codice, ma il funzionamento di LMS, che io non miro a rimpiazzare o mascherare, ma solo a rendere meno ostico rispetto a formulette magiche in un file, oltre ad aggiungere funzionalità che in LMS non sono previste, quali la determinazione dell'output in funzione delle 'reali' caratteristiche dell'input, ma ricondotte al principio di funzionamento già noto (es. ricampiona su eccezione è identico a quello di squeezelite).
sarò 'tonto' ma non ho ancora capito cosa vorresti fosse fatto con le CB dei sample rates, un disegno rende più di mille parole.
NON sono le caratteristiche del player hw, ma quelle 'viste' e considerate SOLO e SOLTANTO da C-3PO per quel player, puoi decidere di non usarlo e quindi non avranno validità, ma C-3PO ha bisogno di quelle informazioni per lavorare e quindi le genera e le espone per conferma.
Sei dentro ai settings di C-3PO per il player, quelle del Player, le 'regoli' sul player, usando la riga di comando o falcon se squeezelite, altro se uno SB 'vero' o chissà cosa.
Ribadisco che l'alternativa è esporre il max sample rate come ho fatto per i codecs, ma - a mjo avviso - non aggiunge nulla.
Sempre a mio parere, questo è chiarito bene dall'help on line, ma magari si può rendere ancora meglio.
Dopo di che mi aspetterei di trovare una serie di opzioni "operative", su cui eventualmente agire di volta in volta per ottenere determinati risultati. Non con combinazioni più o meno complesse di opzioni diverse (tipo "abbassa qui per cambiare li"), ma quanto più possibile attraverso impostazioni mirate e dirette, dal significato ovvio.
Come ad es. i controlli di luminosità, contrasto e colore della TV, o ancora più banalmente quelli di tono e volume, per intenderci.
Fuor di metafora, così come ad es. trovo un menù dove posso scegliere se uscire a 16, 24 o 32 bit, se ad es. voglio ricampionare tutto a X Kb/s mi aspetterei di trovare un menù dove impostare quella frequenza, dove mi si chiede proprio (e solo) quello.
Non so se sono riuscito a spiegarmi...
Certo che si, ma qualsiasi scelta è arbitraria, perchéé un solo limite e non soglie diverse? perché valido per tutti i codecs?
...
fino al limite in cui replichi la complessità del custom-convert.conf , anzi, l'aumenti, dato che il test sul S/r li non lo puoi fare.
Ti ho già spiegato perché non riesco a farlo.
Questa è la tua interpretazione, il significato non è quello, v,. sopra.
Per questo non ho il FIXED ma il max sync o max, così si adattano dinamicamente al cambiamento, come ti ho spiegato sopra. Anche inserendo il concetto di 'target' manterrei questo approccio proprio per evitare il problema.
Lo vedi come un trucco (o workaround) solo perchè continui ad attribuire un significato improprio ai sample rates supportati, se pensi a loro come ai sample rate supportati da C-3PO per il player, è del tutto naturale che se togli il supporto a 384 e lo lasci a 192, tutto venga ricampionato a 192, in specie se selezioni "quando non supportato".esatto, proprio questa potrebbe essere una delle possibilità: se ho uno stream con s/r < 192 lo ricampiono a 192, altrimenti (se è >=192) lo mando così com'è.
In alcuni casi può avere senso: se ad es. avessi un DAC che supporta fino a 384K (o più) ma ha uno "sweet spot" (suona leggermente meglio) ad un certo s/r più basso, ad es. 96 o 192, probabilmente sarebbe vantaggioso ricampionare proprio a quella frequenza tutto il materiale con s/r inferiori. Però, se ho del materiale nativo a s/r più alto, è possibile per non dire probabile che non mi convenga "downsamplarlo": facile che quello che guadagnerei per via dello "sweet spot" del DAC lo perderei con gli interessi a causa del downsampling.
La cosa poi è particolarmente importante con il DSD. Prendi il mio caso (che non è poi così atipico): ho un DAC che supporta fino a DSD512 (teoricamente addirittura 1024), ma il PC che fa da server non è in grado di convertire da PCM (e tanto meno "upsamplare" DSD) oltre DSD128. Ora, di files DSD nativi a 512 ed oltre non ne ho mai visti (e considerati i pochissimi sistemi audio in grado di supportarli e le dimensioni folli, dubito ce ne siano...), ma DSD256 sì.
Va da sé che, in simili condizioni, idealmente ciò che vorrei ottenere è che (ad es.) PCM e DSD64 siano convertiti in DSD128 (di più non posso), mentre DSD128 e superiori siano inviati in uscita così come sono.
Ma come faccio? Se imposto il limite a quello max reale del DAC, poi C3PO tenterebbe di convertire/upsamplare tutto a quello. Però il sistema non ce la fa, e non funziona più niente. D'altro canto, se imposto il limite max a 128 poi mi ritrovo C3PO che tenta di downsamplare qualsiasi eventuale stream DSD256 o superiore (cosa che tra l'altro richiederebbe un mare di risorse, quindi non solo -se funzionasse- causerebbe un peggioramento della qualità, ma non funzionerebbe proprio).
Certo stiamo parlando di casi particolari, di un "valore aggiunto" marginale... ma visto che l'implementazione non dovrebbe presentare particolari difficoltà e che così facendo (IMHO) si ottiene anche una interfaccia più intuitiva per l'utente, che si trova davanti una scelta ovvia e non è costretto a pensare a quello che ai suoi occhi potrebbe apparire come una sorta di "workaround" (abbassare il max s/r supportato per ottenere di ricampionare ad una freq. inferiore), può valere la pena di farlo. Poi ovviamente vedi tu...
però sono opinioni, sono certo che se facessi come dici, qualcuno me ne segnalerebbe l'inutile prolissità...
Detto questo, forse finalmente capito a cosa servirebbe il 'target': a consentire di ricampionare ad una frequenza diversa dalla massima (o massima sincrona) ammessa, senza provocare il downsampling di quelle superiori ammesse, corretto?
Cioè ricampiono 64 a 128, non tocco 128 e 256, ma faccio downsample del 512. Corretto?
Per pcm, analogamente, potrei ricampionare tutto fino a 96K a 96K, non toccare 96 e 192, ma fare downsampling oltre.
DOMANDA sibillina:
perché solo una soglia?
La cosa sarebbe meglio resa da una tabella simile a questa:
44.1 [ ] 96000
48 [ ] 96000
88.2 [ ] 96000
96 [x] _____
...
176.4 [] 384000
192 [] 384000
352.8 [] 384000
384 [x] _____
...
768 [] 384000
quindi qualcuno potrebbe opinare: perché uguale per tutti i formati di ingresso?
quindi dovrei mettere una cosa di questo tipo:
[incodec] [inSR] out s/r
ma avrebbe molto senso poter differenziare tra file locali, remoti o stream, quindi:
{[F] [R] [I]} [incodec] [inSR] out s/r
a quel punto, sarebbe comodo poter differenziare anche il formato di uscita
{[F] [R] [I]} [incodec] [inSR] outcodec out s/r
Ci sono poi in C-3PO scelte arbitrarie sull'usare o meno certi strumenti come i cue sheets, flac o FFMPEG per separare i brani, FAAD o FMPEG per AIFF ed ALAC, FLAC/SOX per FLAC,... si potrebbero esporre le scelte così:
{[F] [R] [I/T]} [incodec] [outcodec] [inSR] out s/r [SPLITTER] [CONVERTER] [RESAMPLER]
che guarda caso è molto simile alla definizione di un comando di custom convert.conf. Era ESATTAMENTE la prima idea di C-3PO che mi ero fatto.
A tempo, voglia e capacità infinite potrei inventare un sistema di settaggi a più livelli (semplice, avanzato, esperto, guru) che via via espone diverse possibilità di scelta, ma bisogna anche fare i conti con lo strumento che si ha a disposizione, che non è certo nato per questo. La complessità (anche grafica) di C-3PO è già oggi molto superiore a quella di qualsiasi altro plugin di LMS.
Prendo nota della richiesta, ma - francamente . la considero meno importante rispetto alla soluzione del problema stdin/cuesheet per formato in ingresso, che non consente l'utilizzo di files flac, nemmeno in alta definizione, con cue sheet se si ascolta Qobuz.
Ciao, Marco.
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
— E. F. Schumacher (mis-attributed to A. Einstein)
________________________________________________________________________________
Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE
Segnalo che seguendo le istruzioni per fare conversione in DSD solo con formati a 44/48 Khz una volta mandato in play il file SOX spara al 100% di cpu e si blocca tutto, tanto da dover terminare manualmente LMS.
C-3PO log:
Segnalo anche che nell'ultima beta non vanno gli slider per la regolazione dei tagli low pass nella sezione DSDcodice:[Wed Apr 5 00:02:20 2017] ERROR: Problem writing body from STDIN: Pipe interrotta
Riesci per cortesia a postarmi il comando che viene generato e che impalla LMS? Sei su Mac vero? Hai provato il comando SOX da terminale? funziona? Non prende il 100% di CPU?
A me gli slider funzionano sia in Win che in Linux, cosa intendi per 'non vanno'?
sono visualizzati?
sono abilitati (modificabili anche nella casella di testo)?
sono accessibili ma disabilitati (non cambiano il valore nella casella di testo)?
sono abilitati, ma non mantengono il valore se modificato ?
grazie-
Ciao, Marco.
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
— E. F. Schumacher (mis-attributed to A. Einstein)
________________________________________________________________________________
Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE
Ci sono attualmente 1 utenti che stanno visualizzando questa discussione. (0 utenti e 1 ospiti)
|
nexthardware.com - © 2002-2022 |
Rispondi quotando
