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

[marcoc1712]

Si, infatti...

Flac

ULTIMO COMANDO ESEGUITO
 
At: 2017/04/27 19:56:24
 
Profile:
 
flc-dsf-*-00:e0:4c:68:d1:46
 
Command:
 
[C-3PO] -c $CLIENTID$ -p "C:\ProgramData\Squeezebox\prefs\plugin\C3PO.prefs" -l "C:\ProgramData\Squeezebox\Logs" -x "C:/PROGRA~2/SQUEEZ~1/server" -i flc -o dsf $START$ $END$ $RESAMPLE$ $FILE$ --nodebuglog
 
Tokenized command:
 
"C:\ProgramData\Squeezebox\Cache\InstalledPlugins\Plugins\C3PO\Bin\MSWin32-x86-multi-thread\C-3PO.exe" -c 00-e0-4c-68-d1-46 -p "C:\ProgramData\Squeezebox\prefs\plugin\C3PO.prefs" -l "C:\ProgramData\Squeezebox\Logs" -x "C:/PROGRA~2/SQUEEZ~1/server" -i flc -o dsf "H:\Music\Lossless_OK\Artist\Erik Truffaz - 2002 - Mantis - 1415\01 - The Point.flac" --nodebuglog |
 
Trasformed by C-3PO in:
 
C":\PROGRA~2\SQUEEZ~1\server\Bin\MSWin32-x86-multi-thread\sox.exe" -q -t flac "H:\Music\Lossless_OK\Artist\Erik Truffaz - 2002 - Mantis - 1415\01 - The Point.flac" -t dsf -b 1 --buffer 8192 - gain -h rate -v -L -a -b 96.5 -f 11289600 sdm -f sdm-8

dsf

At: 2017/04/27 19:58:28
 
Profile:
 
dsf-dsf-*-00:e0:4c:68:d1:46
 
Command:
 
[C-3PO] -c $CLIENTID$ -p "C:\ProgramData\Squeezebox\prefs\plugin\C3PO.prefs" -l "C:\ProgramData\Squeezebox\Logs" -x "C:/PROGRA~2/SQUEEZ~1/server" -i dsf -o dsf $START$ $END$ $RESAMPLE$ $FILE$ --nodebuglog
 
Tokenized command:
 
"C:\ProgramData\Squeezebox\Cache\InstalledPlugins\Plugins\C3PO\Bin\MSWin32-x86-multi-thread\C-3PO.exe" -c 00-e0-4c-68-d1-46 -p "C:\ProgramData\Squeezebox\prefs\plugin\C3PO.prefs" -l "C:\ProgramData\Squeezebox\Logs" -x "C:/PROGRA~2/SQUEEZ~1/server" -i dsf -o dsf -r 352800 "D:\Musica\01 - David Elias - The Window - Vision of Her (DSD64).dsf" --nodebuglog |
 
Trasformed by C-3PO in:
 
C":\PROGRA~2\SQUEEZ~1\server\Bin\MSWin32-x86-multi-thread\sox.exe" -q -t dsf "D:\Musica\01 - David Elias - The Window - Vision of Her (DSD64).dsf" -t dsf -b 1 --buffer 8192 - lowpass -2 22000 gain -h rate -v -L -a -b 96.5 -f 256 sdm -f sdm-8

c'è un buco...

rate -v -L -a -b 96.5 -f 256 sdm.

deve usare 256* non 256..., si è perso nell'ultima modifica? Strano non si sia lamentato nessuno...

Verifico, grazie.

[UnixMan]

non so...a Paolo va?

ehm... non lo so, il resampling DSD->DSD non l'ho mai testato.

( ...ma visto che poi Marco ha individuato un piccolo errore, presumo di no :-) ).

[marcoc1712]

Abilitando solo 64 anche qui la riga mi sembra giusta

At: 2017/04/27 20:02:49
 
Profile:
 
dsf-dsf-*-00:e0:4c:68:d1:46
 
Command:
 
[C-3PO] -c $CLIENTID$ -p "C:\ProgramData\Squeezebox\prefs\plugin\C3PO.prefs" -l "C:\ProgramData\Squeezebox\Logs" -x "C:/PROGRA~2/SQUEEZ~1/server" -i dsf -o dsf $START$ $END$ $RESAMPLE$ $FILE$ --nodebuglog
 
Tokenized command:
 
"C:\ProgramData\Squeezebox\Cache\InstalledPlugins\Plugins\C3PO\Bin\MSWin32-x86-multi-thread\C-3PO.exe" -c 00-e0-4c-68-d1-46 -p "C:\ProgramData\Squeezebox\prefs\plugin\C3PO.prefs" -l "C:\ProgramData\Squeezebox\Logs" -x "C:/PROGRA~2/SQUEEZ~1/server" -i dsf -o dsf -r 352800 "H:\Music\DSD\Pink Floyd - 2003 - The Dark Side Of The Moon - 5645\02 - Breathe.dsf" --nodebuglog |
 
Trasformed by C-3PO in:
 
C":\PROGRA~2\SQUEEZ~1\server\Bin\MSWin32-x86-multi-thread\sox.exe" -q -t dsf "H:\Music\DSD\Pink Floyd - 2003 - The Dark Side Of The Moon - 5645\02 - Breathe.dsf" -t dsf -b 1 --buffer 8192 - gain -h

Ma orecchio si sente che il gain non lo applica

PS: come sarebbe il comando da dare a sox per verificare che faccia la conversione del file?

In nessuno dei tuoi comandi viene applicata una riduzione/aumento di guadagno manuale, ma sempre e solo l'headroom automatico. Quello che senti 'ad orecchio' è che nei primi due casi c'è un resampling con conversione a DSD che comporta, usualmente, -xdb di guadagno per se, mentre l'ultimo è un 'nativo', senza nessun resampling o conversione, quindi non c'è la riduzione di guadagno automatica.

Tutto qui.

Non ho capito la domanda nel PS.

[UnixMan]

Premesso - a scanso equivoci - che l'intento è sempre quello di cercare di migliorare quanto più possibile le cose e che in quanto segue non c'è assolutamente alcuna vena polemica, ma soltanto un tentativo di presentare un punto di vista diverso, rispondo in ritardo (mi ci è voluto un po' di tempo per elaborare alcune idee...) alla questione dell'interfaccia di cui parlavamo qualche giorno addietro.

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

quello è probabile... ed è tutt'altro che sorprendente. La percezione di maggiore o minore "chiarezza" o "difficoltà" di un dato compito è fortemente soggettiva. Tra le altre cose, dipende fortemente dal "background culturale" del soggetto.

Ad es., pensa alla difficoltà nell'imparare a guidare un ciclomotore: se fin da bambino hai imparato ad andare in bicicletta ed hai visto altri guidare ogni genere di veicoli a motore, per te il passo è ovvio e banale. La difficoltà pressoché inesistente. Ma se al contrario sei cresciuto senza aver mai visto né una bicicletta né tanto meno un veicolo a motore, verosimilmente non sapresti neanche da che parte cominciare...

Nel caso specifico quindi non solo non mi sorprende, ma è quasi inevitabile che alcune cose che a te possono sembrare assolutamente banali, ovvie e scontate, ad altri potrebbero invece apparire complesse o incomprensibili.

N.B.: non è certo una tua mancanza: è solo uno dei tanti, usuali problemi di percezione che spesso è difficile se non impossibile evitare.

Francamente non capisco cosa ci sia di non chiaro.

fondamentalmente il meccanismo di selezione dei s/r e del resampling... è soprattutto di quello che stavamo parlando.

IMO non appare per nulla evidente come (e perché) si debba impostare la tabella dei s/r e le altre opzioni relative per ottenere determinati risultati. Anzi, dal punto di vista di un utente ignaro, non è neanche ovvio che quella tabella vada utilizzata a tal fine. Inoltre, posto che ciò sia appurato, non è affatto evidente quali risultati sia possibile ottenere e quali no (se non lo sapessi a priori, credo che avrei difficoltà a capirlo anche io).

Con un minimo di background, l'aiuto delle "info" ed un po' di fantasia magari ci si può arrivare... ma resta comunque un meccanismo che IMHO appare complesso, "contorto" e tutt'altro che intuitivo. Certo, se hai capito il meccanismo (almeno per i casi più semplici) è banale. Ma se al contrario non hai conoscenze a priori e non hai ben chiaro come funziona, l'impatto è...

Tornando allo specifico, la tabella che poi deve essere combinata con diverse altre opzioni per ottenere un dato risultato a mio modesto avviso rende tutto estremamente criptico: la maggior parte degli utenti non sono programmatori, non sono minimamente abituati a pensare in termini algoritmici, di logica combinatoria, di lookup tables, ecc.
Al contrario sono abituati a ragionare in modo semplice, diretto, lineare, progressivo e circoscritto: "per accendere quella luce, premi questo tasto"; "se vuoi accendere quell'altra, premi l'altro tasto"; "se vuoi regolare l'intensità, gira quella manopola", ecc. L'idea di dover azionare un certo numero di interruttori e commutatori e manopole in un certo modo per accendere una luce ed in un modo diverso per accenderne un'altra è qualcosa che non rientra nella loro esperienza, nel loro modo di pensare: non gli passa neanche per l'anticamera del cervello. Di fronte ad una cosa del genere restano confusi e sconcertati, non sanno che pesci prendere...

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

è proprio questo il problema. La difficoltà (tua/nostra) è tutta qui: trovare il modo di presentare le innumerevoli opzioni e combinazioni possibili in una forma che (dal punto di vista dell'utente, cioè a livello di WebUI) non richieda combinazioni di controlli diversi o quanto meno che ne richieda il minor numero possibile, presentati in modo che appaiano evidentemente legati e "consequenziali" l'uno all'altro.

Provo a spiegarmi con un esempio, seguendo un ipotetico ragionamento di un novellino che vede per la prima volta l'interfaccia di configurazione - non quella attuale, ma una ipotetica interfaccia fatta come penso che dovrebbe essere fatta affinché risulti comoda, versatile ed intuitiva:

Cosa abbiamo qui? Ah, una tabella dei s/r supportati dal mio DAC. OK. Questo sì, questo no, ... quest'altro sì, ... uffa, ma quanti sono!? ... c'è pure il DSD ... sì, questo va bene, ... no, questo non va ... ok, finito.

< aggiungi qui la purtroppo tanto inevitabile quanto incomprensibile opzione relativa a cue sheet ed stdin >

"Considera 'HD' gli stream PCM con s/r >= [XXXXX] e DSD >= [nnn]"

e questo a che serve? ah, bene, se sposto il mouse sulla "i" me lo spiega...

info: "è possibile decidere che gli stream di ingresso che hanno un sample rate maggiore o uguale a quanto qui indicato siano considerati ad 'alta definizione' e trattati in modo diverso dagli altri (vedi opzioni successive)."

fico!

"s/r preferiti: PCM XXXXX, DSD YYY"
info: "s/r di uscita utilizzati in caso di resamplig o conversione PCM->DSD e viceversa. Selezionate i valori che producono le prestazioni migliori con il Vs. sistema."

Perfetto. Cominciamo con questo e quello, poi ne proverò altri e sentiremo come suona meglio.
Avanti il prossimo...

Tipo di ricampionamento
per uscita PCM:
- fisso (al s/r preferito)
- usa sempre multiplo intero
- evita multiplo intero
per uscita DSD:
- fisso (al s/r preferito)
- usa sempre multiplo intero
- evita multiplo intero

e questo che diamine significa?! ah, ok, me lo spiega:

info: "scegliere se ricampionare sempre al s/r preferito a prescindere dal s/r in ingresso oppure utilizzare il valore più vicino possibile (a quello preferito) che sia sempre / non sia mai un multiplo intero del s/r di partenza. Ad es., se il s/r preferito è impostato a 192K (posto che anche 176.4K sia supportato), in uscita si otterrà:
* fisso: sempre 192k
* usa sempre multiplo intero: 192K se in ingresso ho 48K o suoi multipli, altrimenti 176.4K;
* evita multiplo intero: 192K se in ingresso ho 44.1K o suoi multipli, altrimenti 176.4K;
qualora 176.4K non sia supportato (fa fede la tabella qui sopra) si utilizzerà invece [...]
".

Elaborazione PCM:
- nessuna
- upsampling
- ricampiona sempre
- converti in DSD
[] non processare se HD
se s/r non supportato: () ricampiona PCM () converti in DSD

Elaborazione DSD:
- nessuna
- upsampling
- ricampiona sempre
- converti in PCM
[] non processare se HD
se s/r non supportato: () ricampiona DSD () converti in PCM

info: "
* nessuna: ricampiona o converte solo se inevitabile (s/r non supportato);
* upsampling: ricampiona solo se il s/r è inferiore a quello preferito;
* ricampiona sempre: anche quando il s/r è maggiore di quello preferito;
* converti in XXX: converte da YYY a XXX.
"

info: "se abilitato, nel caso di stream HD ricampiona o converte solo se inevitabile (s/r non supportato)."

info: "definisce il comportamento nel caso si sia scelto di non effettuare alcuna elaborazione ma il s/r di ingresso non è supportato".

OK, fai questo, quello e quest'altro...

Qui invece cosa abbiamo? Ah, bene, le impostazioni del resampler.

[...]

Effetti aggiuntivi
Applica a: []PCM []DSD
Quando:
- sempre
- solo in caso di elaborazione (resampling o conversione)
- mai
[]escludi sempre HD
[...]

ecc, ecc.

Ecco, una cosa così a me pare semplice, chiara e lineare. Pure una nonna audiofila capirebbe subito che cosa può fare e come può ottenere ciò che vuole.

Inoltre la maggior parte delle cose che si potrebbe desiderare di poter cambiare al volo... si possono cambiare al volo, con un solo click (ad es. A/B tra diversi s/r, PCM->PCM vs. PCM->DSD, con o senza effetti aggiuntivi, ecc).

Ci sono duplicazioni e ridondanza, risultati che si possono ottenere in modi diversi?

A carrettate... “there's more than one way to skin a cat”.

Ma c'è per caso ambiguità? No, e questo è ciò che conta. Per sbagliare o ottenere un risultato diverso da quello che si desidera bisognerebbe mettercisi proprio d'impegno.

BTW: distinzioni tra formati diversi? A parte quella tra PCM e DSD, che sono sostanzialmente diversi e vanno necessariamente trattati in modo diverso, per il resto (tranne che per i soliti cue/stdin che usi tu come workaround) non ne vedo proprio l'utilità.

My 2¢.

[marcoc1712]

In Beta la versione corretta.

[marcoc1712]

Premesso - a scanso equivoci - che l'intento è sempre quello di cercare di migliorare quanto più possibile le cose e che in quanto segue non c'è assolutamente alcuna vena polemica, ma soltanto un tentativo di presentare un punto di vista diverso, rispondo in ritardo (mi ci è voluto un po' di tempo per elaborare alcune idee...) alla questione dell'interfaccia di cui parlavamo qualche giorno addietro.


quello è probabile... ed è tutt'altro che sorprendente. La percezione di maggiore o minore "chiarezza" o "difficoltà" di un dato compito è fortemente soggettiva. Tra le altre cose, dipende fortemente dal "background culturale" del soggetto.

Ad es., pensa alla difficoltà nell'imparare a guidare un ciclomotore: se fin da bambino hai imparato ad andare in bicicletta ed hai visto altri guidare ogni genere di veicoli a motore, per te il passo è ovvio e banale. La difficoltà pressoché inesistente. Ma se al contrario sei cresciuto senza aver mai visto né una bicicletta né tanto meno un veicolo a motore, verosimilmente non sapresti neanche da che parte cominciare...

Nel caso specifico quindi non solo non mi sorprende, ma è quasi inevitabile che alcune cose che a te possono sembrare assolutamente banali, ovvie e scontate, ad altri potrebbero invece apparire complesse o incomprensibili.

N.B.: non è certo una tua mancanza: è solo uno dei tanti, usuali problemi di percezione che spesso è difficile se non impossibile evitare.


fondamentalmente il meccanismo di selezione dei s/r e del resampling... è soprattutto di quello che stavamo parlando.

IMO non appare per nulla evidente come (e perché) si debba impostare la tabella dei s/r e le altre opzioni relative per ottenere determinati risultati. Anzi, dal punto di vista di un utente ignaro, non è neanche ovvio che quella tabella vada utilizzata a tal fine. Inoltre, posto che ciò sia appurato, non è affatto evidente quali risultati sia possibile ottenere e quali no (se non lo sapessi a priori, credo che avrei difficoltà a capirlo anche io).

Con un minimo di background, l'aiuto delle "info" ed un po' di fantasia magari ci si può arrivare... ma resta comunque un meccanismo che IMHO appare complesso, "contorto" e tutt'altro che intuitivo. Certo, se hai capito il meccanismo (almeno per i casi più semplici) è banale. Ma se al contrario non hai conoscenze a priori e non hai ben chiaro come funziona, l'impatto è...

Tornando allo specifico, la tabella che poi deve essere combinata con diverse altre opzioni per ottenere un dato risultato a mio modesto avviso rende tutto estremamente criptico: la maggior parte degli utenti non sono programmatori, non sono minimamente abituati a pensare in termini algoritmici, di logica combinatoria, di lookup tables, ecc.
Al contrario sono abituati a ragionare in modo semplice, diretto, lineare, progressivo e circoscritto: "per accendere quella luce, premi questo tasto"; "se vuoi accendere quell'altra, premi l'altro tasto"; "se vuoi regolare l'intensità, gira quella manopola", ecc. L'idea di dover azionare un certo numero di interruttori e commutatori e manopole in un certo modo per accendere una luce ed in un modo diverso per accenderne un'altra è qualcosa che non rientra nella loro esperienza, nel loro modo di pensare: non gli passa neanche per l'anticamera del cervello. Di fronte ad una cosa del genere restano confusi e sconcertati, non sanno che pesci prendere...


è proprio questo il problema. La difficoltà (tua/nostra) è tutta qui: trovare il modo di presentare le innumerevoli opzioni e combinazioni possibili in una forma che (dal punto di vista dell'utente, cioè a livello di WebUI) non richieda combinazioni di controlli diversi o quanto meno che ne richieda il minor numero possibile, presentati in modo che appaiano evidentemente legati e "consequenziali" l'uno all'altro.

Provo a spiegarmi con un esempio, seguendo un ipotetico ragionamento di un novellino che vede per la prima volta l'interfaccia di configurazione - non quella attuale, ma una ipotetica interfaccia fatta come penso che dovrebbe essere fatta affinché risulti comoda, versatile ed intuitiva:

Cosa abbiamo qui? Ah, una tabella dei s/r supportati dal mio DAC. OK. Questo sì, questo no, ... quest'altro sì, ... uffa, ma quanti sono!? ... c'è pure il DSD ... sì, questo va bene, ... no, questo non va ... ok, finito.

< aggiungi qui la purtroppo tanto inevitabile quanto incomprensibile opzione relativa a cue sheet ed stdin >

"Considera 'HD' gli stream PCM con s/r >= [XXXXX] e DSD >= [nnn]"

e questo a che serve? ah, bene, se sposto il mouse sulla "i" me lo spiega...

info: "è possibile decidere che gli stream di ingresso che hanno un sample rate maggiore o uguale a quanto qui indicato siano considerati ad 'alta definizione' e trattati in modo diverso dagli altri (vedi opzioni successive)."

fico!

"s/r preferiti: PCM XXXXX, DSD YYY"
info: "s/r di uscita utilizzati in caso di resamplig o conversione PCM->DSD e viceversa. Selezionate i valori che producono le prestazioni migliori con il Vs. sistema."

Perfetto. Cominciamo con questo e quello, poi ne proverò altri e sentiremo come suona meglio.
Avanti il prossimo...

Tipo di ricampionamento
per uscita PCM:
- fisso (al s/r preferito)
- usa sempre multiplo intero
- evita multiplo intero
per uscita DSD:
- fisso (al s/r preferito)
- usa sempre multiplo intero
- evita multiplo intero

e questo che diamine significa?! ah, ok, me lo spiega:

info: "scegliere se ricampionare sempre al s/r preferito a prescindere dal s/r in ingresso oppure utilizzare il valore più vicino possibile (a quello preferito) che sia sempre / non sia mai un multiplo intero del s/r di partenza. Ad es., se il s/r preferito è impostato a 192K (posto che anche 176.4K sia supportato), in uscita si otterrà:
* fisso: sempre 192k
* usa sempre multiplo intero: 192K se in ingresso ho 48K o suoi multipli, altrimenti 176.4K;
* evita multiplo intero: 192K se in ingresso ho 44.1K o suoi multipli, altrimenti 176.4K;
qualora 176.4K non sia supportato (fa fede la tabella qui sopra) si utilizzerà invece [...]
".

Elaborazione PCM:
- nessuna
- upsampling
- ricampiona sempre
- converti in DSD
[] non processare se HD
se s/r non supportato: () ricampiona PCM () converti in DSD

Elaborazione DSD:
- nessuna
- upsampling
- ricampiona sempre
- converti in PCM
[] non processare se HD
se s/r non supportato: () ricampiona DSD () converti in PCM

info: "
* nessuna: ricampiona o converte solo se inevitabile (s/r non supportato);
* upsampling: ricampiona solo se il s/r è inferiore a quello preferito;
* ricampiona sempre: anche quando il s/r è maggiore di quello preferito;
* converti in XXX: converte da YYY a XXX.
"

info: "se abilitato, nel caso di stream HD ricampiona o converte solo se inevitabile (s/r non supportato)."

info: "definisce il comportamento nel caso si sia scelto di non effettuare alcuna elaborazione ma il s/r di ingresso non è supportato".

OK, fai questo, quello e quest'altro...

Qui invece cosa abbiamo? Ah, bene, le impostazioni del resampler.

[...]

Effetti aggiuntivi
Applica a: []PCM []DSD
Quando:
- sempre
- solo in caso di elaborazione (resampling o conversione)
- mai
[]escludi sempre HD
[...]

ecc, ecc.

Ecco, una cosa così a me pare semplice, chiara e lineare. Pure una nonna audiofila capirebbe subito che cosa può fare e come può ottenere ciò che vuole.

Inoltre la maggior parte delle cose che si potrebbe desiderare di poter cambiare al volo... si possono cambiare al volo, con un solo click (ad es. A/B tra diversi s/r, PCM->PCM vs. PCM->DSD, con o senza effetti aggiuntivi, ecc).

Ci sono duplicazioni e ridondanza, risultati che si possono ottenere in modi diversi?

A carrettate... “there's more than one way to skin a cat”.

Ma c'è per caso ambiguità? No, e questo è ciò che conta. Per sbagliare o ottenere un risultato diverso da quello che si desidera bisognerebbe mettercisi proprio d'impegno.

BTW: distinzioni tra formati diversi? A parte quella tra PCM e DSD, che sono sostanzialmente diversi e vanno necessariamente trattati in modo diverso, per il resto (tranne che per i soliti cue/stdin che usi tu come workaround) non ne vedo proprio l'utilità.

My 2¢.

Posto che le cose i possono progettare e realizzare in modi diversi ed ogni progettista ha il suo punto di vista, la realizzazione di una interfaccia è una tecnica che ha regole e fondamenti teorici ben precisi. Puoi fare riferimento ad una scuola o all'altra, ma poi è bene rimanerci attaccato.

Spero non si stia discutendo sull'utilizzo dei diversi widget, questo è uno standard dettato dalla natura e dal 'dominio' del dato, in gioco, piuttosto, c'è la corretta definizione della realtà che si vuole rappresentare e dei relativi casi d'uso.

Es.

SE devo rappresentare un insieme di valori DISCRETI dai quali posso selezionare NESSUNO, UNO o PIU, lo strumento corretto è una serie di check box o, al limite, la selezione multipla di elementi in una tabella, che ne rappresenta una versione sofisticata.

Il punto è: Devo rappresentare un insiemi di valori discreti e consentire la selezione multipla? Se cambia il modello, cambiano le regole e cambia l'applicazione.

ESEMPIO CONCRETO: Sample rate in uscita:

OBIETTIVO:

Raccogliere le indicazione necessarie e sufficienti per determinare il sample rate in uscita dal decoder a fronte di un ipotetico sample rate di riferimento (quando possibile quello del file/stream in ingresso).

Elementi noti a priori:

a. min (8000/64) fissato da LMS.
b max, fissato dal player o forzato in avanzate.
c. insieme discreto dei valori compresi tra min e max.

NON noto a priori:

d. frequenza di riferimento.

OPZIONI:

e. sincronia richiesta.

CASI D'USO:

1. 1 frequenza, normalmente la massima ammessa, cui TUTTI gli stream vengono ricondotti
1.1 1 come sopra, ma per 'famiglia' di sample rate in sincrono o non sincrono.

2. 'gruppi' di frequenze adiacenti: es. 44100 e 88200 escono a 88200, 176.4 esce a 176.4 , 352.8 e 705.6 escono a 352.8.
2.1 come sopra, ma per 'famiglia' di sample rate in sincrono o non sincrono:


Posto che questi siano i termini del problema, altrimenti stiamo parlando di applicazioni diverse, mi rappresenti per cortesia come lo realizzeresti IN CONCRETO e COMPLETO?

Quanto hai proposto NON comprende tutti i casi d'uso ed introduce dei concetti aggiuntivi (HD) a mio avviso non indispensabili, quindi superflui, quindi dannosi.

Non è questione di polemica o critica, il punto è che anche in questa sede presento come VARIAZIONI DI RAPPRESENTAZIONE (che sarebbero errori belli e buoni) quelle che in realtà sono VARIAZIONI DI DOMINIO o di casi d'uso. Fossi un cliente, ti presenterei un salatissimo conto per change request...

Detto questo, e posto che mancano use cases oggi coperti, mentre ne sono presenti altri mai citati prima, francamente non mi trovi d'accordo sul fatto che un numero n di controlli:

Elaborazione PCM:
- nessuna
- upsampling
- ricampiona sempre
- converti in DSD
[] non processare se HD
se s/r non supportato: () ricampiona PCM () converti in DSD

Elaborazione DSD:
- nessuna
- upsampling
- ricampiona sempre
- converti in PCM
[] non processare se HD
se s/r non supportato: () ricampiona DSD () converti in PCM


Effetti aggiuntivi
Applica a: []PCM []DSD
Quando:
- sempre
- solo in caso di elaborazione (resampling o conversione)
- mai
[]escludi sempre HD
[...]

ecc, ecc.

sia più semplice ed intuitivo di una tabella 'atomica', dove se vuoi fare resampling di FLAC metti si, altrimenti metti no. (sempre al netto di seek/stdin che però vanno rappresentati, altrimenti ci giochiamo QOBUZ o i CUE SHEETS..., tu come faresti?)

Però stiamo cadendo nello stesso errore:

Qual'è il dominio rappresentato e quali sono gli use case da soddisfare? Quelli di C-3PO oggi o quelli che presenti oggi tu?

p.s.

Cosa abbiamo qui? Ah, una tabella dei s/r supportati dal mio DAC. OK. Questo sì, questo no, ... quest'altro sì, ... uffa, ma quanti sono!? ... c'è pure il DSD ... sì, questo va bene, ... no, questo non va ... ok, finito

NON è mai stato così (il dac non è mai stato parte dell'equazione), era il player, ma adesso - anche su tua richiesta - ho diviso i concetti, evidenziando le capacità DICHIARATE dal PLAYER (non dal DAC) dalle impostazioni del TRANSCODER.

La tabella dei sample rates è relativa all'uscita del TRANSCODER. Se la vedi così è semplice.

p.p.s.

Prima era il command line, adesso è la tabella... per il computer norvegese (così lo chiamano gli svedesi, la cui tastiera ha un solo tasto con la dicitura 'desiderare ardentemente e premere') aspettiamo la prossima release.

[antonellocaroli]

In Beta la versione corretta.

Adesso é OK!!!

[marcoc1712]

Ecco la considerazione che hanno di noi...

Help on Audio::Scan 0.9.5

[antonellocaroli]

Ecco la considerazione che hanno di noi...

Help on Audio::Scan 0.9.5

Il fatto é che il 99.999% che USA LMS lo fa perché ha la sveglia e altre cazzate come plugin...

tu li vuoi modernizzare....

[UnixMan]

Ecco la considerazione che hanno di noi...

Help on Audio::Scan 0.9.5

fantastico.

Sarà mica il caso di mandarli a ca**re e cominciare a pensare di abbandonare LMS in favore di qualche altra soluzione?

Magari qualcosa basato su uno standard tipo DLNA?