upsampling (universo LMS/Squeezelite/Squeezeplay)

[antonellocaroli]

Grazie per i link, approfondirò. Ma sei riuscito a fare conversione PCM -> DSD con LMS/squeezelite? Sempre con il convert.conf?

No Marco non é possibile, attualmente é possibile solo con Hqplayer, foobar e Jriver...che io sappia...chiaramente a mio avviso Hqplayer é il meglio in questo senso.

[marcoc1712]

No Marco non é possibile, attualmente é possibile solo con Hqplayer, foobar e Jriver...che io sappia...chiaramente a mio avviso Hqplayer é il meglio in questo senso.

Mi pareva...

Non c'è nessun PCM to DSD converter funzionante da riga di comando?

[antonellocaroli]

Mi pareva...

Non c'è nessun PCM to DSD converter funzionante da riga di comando?

Mhh che io sappia no....bisognerebbe parlare con chi ha fatto la dll per foobar...

[UnixMan]

dato che alcuni miei commenti sembrano aver generato alcuni malintesi, a scanso di equivoci sarà bene che chiarisca subito un paio di cose:

1) il commento negativo si riferiva ad una situazione particolare, non a tutto il sistema in generale (per il quale, non essendomi preso la briga di leggere i sorgenti, non ho elementi di giudizio).

2) tanto il giudizio su quel particolare quanto i dubbi generali erano espressi dal punto di vista di un informatico, non da quello di un audiofilo.

Da un punto di vista audiofilo (laddove ciò che ci interessa è pressoché esclusivamente la qualità del suono che si può trarre dal sistema e non come questo è fatto), la cosa è del tutto irrilevante.

LMS infatti ha ben poco -anzi, proprio nulla- a che spartire con la qualità dell'audio. La sua funzione è unicamente quella di fornire i dati ai player (ad es. squeezelite). Così come sono ("bit perfect") oppure attraverso elaborazioni prodotte da comandi esterni. In entrambi i casi, la qualità del suono non dipende in alcun modo da LMS. In pratica, la funzione di LMS non è dissimile da quella di un server HTTP: la qualità dei contenuti pubblicati da un sito web non dipende certo dalla qualità del software che si limita a trasferirli da una parte all'altra.

Da un punto di vista audiofilo quindi basta che LMS faccia ciò che deve fare... come faccia a farlo è sostanzialmente irrilevante. Al contrario, l'informatico che è in me tende a considerare anche altri aspetti. :-)

Mah, mi sembri un po troppo tranchant con i commenti sul lavoro di altri, certamente l'utilizzo di convert.conf non è elegantissimo e nemmeno di facile comprensione, ma da qui all'indecenza... è un file di configurazione, puoi modifcarlo come vuoi, nion è 'il codice'.

non ci siamo capiti: non è l'uso del "convert.conf" a non piacermi (anzi, al contrario, quella è un'idea che trovo comoda ed intelligente). Ad essere "indecente" è il fatto che in quel file ci siano delle entries che dichiarano una cosa ma ne fanno un'altra!

Le entries che citavo dichiarano di uscire in un formato (aif) mentre invece escono in un altro (raw PCM):

flc aif * *
        # FT:{START=--skip=%t}U:{END=--until=%v}
        [flac] -dcs --force-raw-format --endian=little --sign=signed $START$ $END$ -- $FILE$

Ora, ci sono due possibilità:

1) quelle entries sono sbagliate e NON funzionano;

2) quelle entries sono lecite e funzionano.

Il caso 1) sarebbe il male minore. Ancorché sarebbe piuttosto imbarazzante che la configurazione di default distribuita con il programma contenga degli errori così grossolani, ciò implicherebbe soltanto una banale svista nel file di configurazione stesso. Solo un minor bug, facilmente risolvibile.

Il caso 2) sarebbe invece ben più grave: di fatto è un errore logico. Che non riguarda solo il file di configurazione, ma il codice del software (LMS), che accetta (o addirittura "si aspetta") uno stream PCM raw quando nel file di configurazione è scritto invece "AIFF". Sempre che non sia addirittura la stessa architettura di riferimento del sistema a richiedere una cosa simile!

Le righe che riporti sono quello cui mi riferivo io, l'unica differenza rispetto ai corrispondenti wav è l'endian. Dal punto di vista di LMS puoi fare quello che vuoi in quei comandi, diversamente dal caso di di xxx-> wav (che non è ammesso) e xxx -> PCM, lui nel transcoder segnala che il formato richiesto è AIF, questo è quello che non mi spiegavo e mi hai spiegato tu. Il player decide come trattare lo stream che riceve e Squeezelite attiva lo stesso meccanismo usato per il pcm, che di conseguenza non funziona, se ne attivasse uno dedicato 'stile' flac, potrebbe funzionare.

idem con il WAV.

Comunque, a mio avviso i player c'entrano poco o nulla: il problema è legato ad LMS e/o all'architettura stessa del sistema (al "protocollo" di comunicazione tra LMS e players).

In particolare, dipende da "cosa si aspetta" LMS come formato dei dati di uscita dei comandi di conversione quando come "formato di destinazione" sono specificati wav, aif o pcm. Nonché cosa LMS "comunica" al player in tali casi.

Se come formato di destinazione c'è "aif" ed il comando ritorna invece PCM raw, cosa dice LMS ai player? "pcm" o "aif"?

E cosa gli manda in effetti, aiff o raw?


BTW: in pratica, l'unico problema con i wav (e temo anche con AIFF) che li rende "non streamable" credo sia il fatto che la lunghezza dello stream (la durata del brano...) è scritta nell'header (e non puoi "appendere" un altro stream a quello precedente). Questo potrebbe essere un problema ad es. per il playback "gapless", nel caso questo sia gestito direttamente da LMS e non dai player.

D'altro canto, quando LMS manda al player un file WAV (od AIFF) senza modificarlo, di fatto sta facendo streaming...

...oppure ciò non accade mai, ed LMS converte sempre in "raw" qualsiasi stream PCM (wav o aif) prima di mandarlo ai players?

Non va, perchè squeezelite usa lo stesso modulo per raw pcm e aif...

quello non sarebbe un problema, in quanto i player potrebbero facilmente riconoscere la natura dello stream (wav, aiff o "raw") semplicemente verificando l'eventuale presenza (o assenza) dei relativi "magic number" all'inizio dello stream...

No, sono solo in parte meta variabili usate per le sostituzioni di valori al runtime, altre servono anche per informare LMS di particolari richieste (es T = può cercare nel file, quindi LMS si deve aspettare un inizio ed una fine ed attivare lo specifico pezzo di codice,...).

quelle se non erro le chiama "capabilities"... ed ovviamente non era ciò a cui mi riferivo.

Il valore di %d è frutto dell'algoritmo di ricerca del 'transcoder' migliore da parte di LMS, a fronte della richiesta del client, delle sue capacità e delle opzioni disponibili, non è fissato con una costante proprio per questo, è il player - sostanzialmente - a richiedere a LMS di fare downsampling prima di passargli lo stream,

e qui casca l'asino. In effetti, dato che LMS è pensato per soddisfare le richieste dei client e NON per imporre lui modifiche degli stream, temo che non se ne esca. Quanto meno, non banalmente agendo solo sulla configurazione.

Di fatto (come mi pare avevo già accennato), più capisco la "logica" di LMS e più sospetto che l'upsampling attraverso flac funzioni solo... per sbaglio.

Non sono daccordo, anche perchè - se leggi il codice - ti accorgi che è altamente modulare, quindi - volendo - potresti riscriverti lo specifico modulo o crearne di nuovi (come è stato fatto per il DSD).

quello forse è possibile

Esistono già plugin che fanno DSP e DRC, quindi non è impossibile,

purtroppo questo vuol dire poco. Bisogna vedere se/come l'interfaccia con i plugin prevede la possibilità di "cambiare formato" dei dati -ed in particolare il S/R dello stream- all'interno di un plugin (cosa che tipicamente i plugin DSP e DRC non fanno).

Facendolo come plugin sei libero, ma ci sono cose che verrebbero molto più semplici agendo sullo standard, anche per questo ho tentato di coinvolgere Michael.

senza dubbio sarebbe auspicabile. I "plugin" possono essere una bella cosa ma, quando si esagera con ciò che gli si fa fare, si rischia che alla fine ne venga fuori una accozzaglia non proprio elegante ed ordinata...

Però considere che il server (LMS) è solo la metà della mela, molto dipende anche dal player (squeezelite) che è di una terza parte (pur se molto integrata nella community).

...e bisogna tenere conto anche dei vecchi player "hardware", le cui "specifiche" non possono essere cambiate.

Ad esempio, se esci AIF AIF e non AIF PCM, LMS informa correttamente il player che il fomato è AIF, ma squeezelite lo tratta come se fosse PCM...

ne dubito.

Se lo facesse, come minimo sentiresti uno spernacchiamento all'inizio del file, quando i dati che precedono lo stream vero e proprio verrebbero interpretati come campioni PCM... e se la lunghezza di quel blocco dati non è (per un caso fortuito) un multiplo esatto di quella di un campione, i campioni dello stream PCM che segue non potrebbero essere interpretati correttamente... e quindi non uscirebbe fuori niente altro che rumore.

NO: squeezelite (e compari) NON possono trattare WAV ed AIFF come se fossero PCM (o viceversa).

Le cose possibili sono soltanto due:

1) LMS manda i file così come sono (informando i player del relativo formato, oppure lasciando che siano questi a sbrigarsela da soli sfruttando magic number ed header)

2) LMS converte sempre in PCM "raw" qualsiasi file WAV od AIFF (anche in corrispondenza di entries "wav wav * *" ed "aif aif * *").

Attualmente ho risultati soddisfacenti, ma è un bene "abbracciare" questa soluzione che, forse, è troppo legata al passato?

fin tanto che fa quel che ti serve (a partire dal suonare bene), non vedo perché no.

Un media server tutto fare o qualcosa di più (o almeno anche) HI-FI?

che differenza c'è (ci dovrebbe essere?) tra un "media server tutto fare" e "qualcosa di più HiFi"?

In ogni caso mi sembra che LMS abbia bisogno di una grande operazione di "svevcchiamento".

Più che di "svecchiamento", casomai forse potrebbe avere bisogno di una "ripulita", una riscrittura per riorganizzare ed integrare meglio le innumerevoli aggiunte e modifiche che gli sono state fatte nel corso del tempo. Ma, non avendo visto il codice, non posso escludere che sia già stato fatto e vada bene così com'è (anche se personalmente vedo alcune cose che non mi piacciono).

D'altro canto, quello che deve fare lo fa. Siamo noi che vorremmo che faccia anche altre cose che non è stato pensato per fare... ma questo non significa certo che sia "vecchio" o scritto male.

[marcoc1712]

...non ci siamo capiti: non è l'uso del "convert.conf" a non piacermi (anzi, al contrario, quella è un'idea che trovo comoda ed intelligente). Ad essere "indecente" è il fatto che in quel file ci siano delle entries che dichiarano una cosa ma ne fanno un'altra!

Le entries che citavo dichiarano di uscire in un formato (aif) mentre invece escono in un altro (raw PCM):

flc aif * *
        # FT:{START=--skip=%t}U:{END=--until=%v}
        [flac] -dcs --force-raw-format --endian=little --sign=signed $START$ $END$ -- $FILE$

Ora, ci sono due possibilità:

1) quelle entries sono sbagliate e NON funzionano;

2) quelle entries sono lecite e funzionano.

Il caso 1) sarebbe il male minore. Ancorché sarebbe piuttosto imbarazzante che la configurazione di default distribuita con il programma contenga degli errori così grossolani, ciò implicherebbe soltanto una banale svista nel file di configurazione stesso. Solo un minor bug, facilmente risolvibile.

Il caso 2) sarebbe invece ben più grave: di fatto è un errore logico. Che non riguarda solo il file di configurazione, ma il codice del software (LMS), che accetta (o addirittura "si aspetta") uno stream PCM raw quando nel file di configurazione è scritto invece "AIFF". Sempre che non sia addirittura la stessa architettura di riferimento del sistema a richiedere una cosa simile!

Allora, LMS non converte mai nulla di suo, lo lascia fare ai binari esterni mediante i comandi in convert.conf

Quello che forse non sono capace di spiegarti bene è che LMS può applicare 4 diversi "stream mode":

1. File (F)
2. StdIn (I), il vero e proprio stream
3. Url remoto (R)
4. File virtuale (V) (usato da SL quando è in locale).

Ancora una volta la richiesta del player e le 'capability' del transcoder dichiarate in convert.conf determinano la modalità applicata.

Le uniche 'forzature' sono che WAV e AIF vengono sempre passati come pcm (l'header viene saltata), dato che WAV non è ammesso come formato target mentre AIF si, nel secondo caso l'informazione 'di origine' viene passata ai player, ma come ho già scritto Suqeezelite comunque attiva pcm, come nel caso di WAV.

Comunque, a mio avviso i player c'entrano poco o nulla: il problema è legato ad LMS e/o all'architettura stessa del sistema (al "protocollo" di comunicazione tra LMS e players).

In particolare, dipende da "cosa si aspetta" LMS come formato dei dati di uscita dei comandi di conversione quando come "formato di destinazione" sono specificati wav, aif o pcm. Nonché cosa LMS "comunica" al player in tali casi.

Se come formato di destinazione c'è "aif" ed il comando ritorna invece PCM raw, cosa dice LMS ai player? "pcm" o "aif"?

E cosa gli manda in effetti, aiff o raw?

V. sopra: WAV non è ammesso come formato target, PCM non è ammesso come formato di input.

Nei comandi "-" LMS elimina l'header dallo stream e lo passa così com'è, negli altri nello stream c'è il risultato del comando di conversione. Come 'informazione' sul contenuto del file viene passato il formato target dichiarato (quindi pcm o aif). Questa informazione è a disposzione del player, Squeezelite non la usa ed applica sempre pcm, anche per AIF, ...nonostante tu ne dubiti...

BTW: in pratica, l'unico problema con i wav (e temo anche con AIFF) che li rende "non streamable" credo sia il fatto che la lunghezza dello stream (la durata del brano...) è scritta nell'header (e non puoi "appendere" un altro stream a quello precedente). Questo potrebbe essere un problema ad es. per il playback "gapless", nel caso questo sia gestito direttamente da LMS e non dai player.

D'altro canto, quando LMS manda al player un file WAV (od AIFF) senza modificarlo, di fatto sta facendo streaming...

...oppure ciò non accade mai, ed LMS converte sempre in "raw" qualsiasi stream PCM (wav o aif) prima di mandarlo ai players?

Ti sei focalizzato sul fatto che LMS 'tratti' in qualche modo lo stream prodotto dai comandi di conversione prima di passarlo ai players, non è così.

WAV PCM * * - -> viene inviato il contenuto del file saltando l'header (così non si ha il glitch iniziale) e/o impostando inizio e fine del brano. viene usato un transcoder con streaming mode "F" (file) quindi il player riceve l'informazione che il content type è PCM ed accede all'header del file per il formato (origine del problema).

AIF PCM * * - -> esattamente come sopra.

AIF AIF * * -> come sopra, ma il content type è AIF, squeezelite lo ignora ed attiva comunque il decoder pcm, che come prima cosa accede al file e legge l'header.

Ove ci sia una trascodifica esterna (comando <> "-") come per esempio

flc flc * *
#IFB...
[flac]...|[sox]...


LMS determina il 'modo' di streaming in base alle capacità del lettore e le caratteristiche del formato target DICHIARATO, quindi passa lo stream in uscita così com'è (l'eventuale posizionamento di inizio e fine DEVE avvenire nel comando).

Il content type è il formato target, il lettore lo interpreta e decide come trattare lo stream in ingresso.

Flac funziona, tu dici per sbaglio, perchè squeezelite NON accede all'header del file originale, ma direttamente a quello dello stream, dato che il decoder flac lo consente, mentre quello pcm no.

Hai qualche esempio di come altri sistemi fanno a comunicare il formato dello stream al player quando è pcm?

[marcoc1712]

Mhh che io sappia no....bisognerebbe parlare con chi ha fatto la dll per foobar...

foo_dsd_asio is very auxiliary part of the project and I decided not to share source code....

L'open source è una gran cosa...

[bigtube]

Aggiungo un altro tassello intorno ai miei confronti di sistema :
Come gia' riferito ho installato LMS che effettua il resampling sia su Windows che su Mint ( ovviamente con il medesimo samplerate : 352800 k ).
Sempre Voyage+Squeezelite sul miniPC player (su S. è ovviamente disabilitato il resampling ).
Ebbene non saprei spiegare perchè ma con Mint l'ascolto è di sicuro piu' appagante, sopratutto manca completamente qualsiasi accenno di asprezza digitale.
Ergo nel mio sistema tutto Linux e non se ne parli piu'.

[marcoc1712]

Aggiungo un altro tassello intorno ai miei confronti di sistema :
Come gia' riferito ho installato LMS che effettua il resampling sia su Windows che su Mint ( ovviamente con il medesimo samplerate : 352800 k ).
Sempre Voyage+Squeezelite sul miniPC player (su S. è ovviamente disabilitato il resampling ).
Ebbene non saprei spiegare perchè ma con Mint l'ascolto è di sicuro piu' appagante, sopratutto manca completamente qualsiasi accenno di asprezza digitale.
Ergo nel mio sistema tutto Linux e non se ne parli piu'.

Cioè server Win <> server Linux Mint? Se è vero - e non dubito che tu lo percepisca davvero, ma un bricilolo di scetticismo bisogna pur tenerlo vivo... - è un argomento che non saprei da che parte rigirare.

L'hw è paragonabile e comunque puoi escludere problemi di 'fluida' trasmissione e buffer underrun in entrambi i casi? I files sono locali al server? (è noto che Win 'fatica' a trattare files su file server linux, in più di un caso questo ha provocato problemi di buffer underrun ed è una configurazione sconsigliata per LMS, se necessario, comunque, ci sono parametri sui quali intervenire - non chederli a me però -).

Se è così, La prima prova che mi verrebbe in mente di fare è quella di produrre i file upsamplati con il comando in convert.conf nei due ambienti e:

a. confrontartli per verificare siano esattamente uguali al bit.
b. suonarli in modo 'incrociato (ma se sono uguali e non ci sono problemi di latenza/buffer...).

Escludendo problemi di rete e verificato che i files siano effettivamente uguali, a parità di buffer di SL (ma se è lo stesso lo sono per forza) faccio realmente fatica ad ipotizzare un motivo, non che questo sposti molto però.

[bigtube]

esatto .....Win contro Mint

[marcoc1712]

esatto .....Win contro Mint

Ho editato il messaggio di prima, vedi sopra se vuoi.